You are on page 1of 4

Marcus Gonzalez

Professor Wisneski

CST 438

28 July 2020

CST 438 Exam Part 2

Question 1

The software engineering process is an in depth and carefully planned project involving a

group of engineers. Differences between software engineering and programming are fairly

extensive taking into account how much a software engineering project expands on pure

programming. While an individual programming may complete a programming project with a

very short lifespan, a true software engineering project as seen in projects like the Google search

engine will have a lifespan well beyond a programming project with many software developers

making up teams. The steps needed to accomplish a successful software engineering project are

well documented for software engineers to adhere to.

The first step in this process is gathering information about the software in need,

otherwise known as software requirements. Gathering detailed information about requirements

that need to be met is critical in knowing what capabilities a client expects of the software they

need built. Gathering requirements is also important for developers to give clients a realistic

outlook on what software can be built based on client needs in a predetermined time frame.

Moving on to the design phase, this step serves as the base for developers to brainstorm how they

will build a project using a Unified Modeling Language (UML) in addition to what services will

be required. The last two steps in completing the project involve coding and testing, and these

two steps rely heavily on each other. Coding your project is of course a necessary step, but
splitting tasks among team members in addition to multiple teams ensures that a project is

completed in a timely and cost effective manner. On the tail end of coding, testing your code

ensures that a product is shipped with little to no bugs, and that the code performs as expected.

As new code is introduced to a code base, bugs will inevitably be introduced as well. This

highlights the importance of code reviews, refactors, and defects. Before code is introduced to an

existing repository, and especially before merging a pull request, it is ideal to have a team

member go through a code review with you. This allows teams to prevent the introduction of

bugs, or perhaps provide an opportunity to refactor code in a way that is more sensible than you

originally visioned. Also, code reviews allow for multiple engineers to review code that could

introduce defects that the development team did not intend for the project as a whole. However,

the process of introducing new code should be documented in some way, and there are two

primary methods that this is done.

Agile software development and the Plan and Document (Waterfall) process are two

approaches of software development that companies employ. The agile approach is a quicker

approach that involves much lighter documentation in comparison to Waterfall, but does require

documentation nonetheless. Additionally, where Waterfall may be more strict in regard to

documentation, Agile is more flexible in its approach to documenting and developing. This

shows that while the Agile method is a quicker form of software development, the two methods

are similar in their needs for documentation, and planning in its basic form.

Question 2.1

Microservices can make large applications simpler by splitting aspects of the large

application into smaller microservices with separate teams whose work doesn’t interfere with

one another. By separating the large application each service is more focused on its task and
workflow is smoother due to the focus on smaller teams with a smaller codebase. Additionally,

in relation to databases, separating databases by services allows for databases that are more

easily maintained and able to run independently in the case of another service being down. A

service that is able to operate independently of other services is important for a robust

application and user experience.

Question 2.2

One complexity that developers have to take into account with microservices is testing

how their service interacts with other microservices. With one application no external API’s are

needed and your entire codebase is local. Developers will need to know how to properly

communicate with external API’s and develop tests accordingly. As part of Testing, Developers

of API’s in addition to developers of tests utilizing API’s should write communication messages

to let each other know what is and isn’t being sent to assist in development. This makes the use

of microservices a task that developers need to think about as both a user and provider of

services.

Question 2.3

Based on the reading, projects should be approached as a monolith application before

venturing into a microservices application later. However, based on the reading and this initial

experience building separate services for cars and flights, it seems that whether or not to go

straight into microservices depends on the initial scope of the project. Projects that are smaller in

scope from initial design make sense to go monolithic before growing into microservices later.

However, projects with known requirements that will be inherently large in scope may be better

served splitting into teams to accomplish different microservices on arrival.


1. I have received adequate feedback from the professor on assignments. I have gone to

office hours several times and was able to receive guidance on issues I was having

trouble with on assignments.

2. This textbook is a ⅘.

3. Week 1:5

Week 2:5

Week 3: 5

4. This class seems important in tying together almost everything we have learned up to this

point before going into our senior project.

You might also like