CST438 Summer 2019b Final Exam

Name ____Blaze King____________________________

Part 1. online questions taken from quizzes 100 points. You have 2 attempts on part 1.

Part2. two essay questions 150 points (75 each).

Each question should be answered in a 300-500-word essay. typed in Times New Roman 12

points font, double space. This is approximately a 1 ½ - 2-page paper. You are encouraged to

include illustrations but then your answer will be longer than 2 pages. You must use good

grammar, punctuation, spelling and style in your answer. Take time to write your best response.

Question 1.

In your own words, discuss the activities that make up a software engineering process. Include

in your answer the phases of gathering requirements, design, coding, testing, reviews,

refactoring, defects and team and customer communication. Also discuss how an Agile process

is the same, and different from a Plan and Document Waterfall process. Use textbook

references to support your points.

ESSAY 1:

A software engineering process can take on several forms, adjusting for the size, scope,

and timeline of a project. Like any project created to produce solutions to a customer request, the

software engineering process is made up of specific and consistent steps. In answering this

question, I will review the steps involved and compare and contrast the difference between an

agile process and a more traditional “waterfall” process.

CST438 Summer 2019b Final Exam

First and most importantly, customer requirements need to be documented. If this step is

skipped or not completed thoroughly, it will be nearly impossible for the project to be a success

in the customer’s view. Next, a design is created based on the customer requirements. “Software

projects fail because they don’t do what customers want” (p. 275), so during the design phase,

customers must either be constantly engaged or user stories need to be relied upon to compare

against. The next phase of the project is the actual coding of the application. This step is often

the most difficult, but if a proper design based on customer requirements has been designed,

coding can be straightforward and consistent. This leads into the next phase of testing, where

code created in the previous phase is reviewed against the customer requirements and design.

The review stage follows testing, where it is tested against the objectives laid out in the customer

requirements and design stages. During refactoring, existing code is rewritten in a way to make it

easier to read, test, and deploy, while not actually changing the functionality. Finally, the last

step involves customer and team communication. If the team and customer are in agreement at

the success of the completed product, the project is complete.

The steps above can be done only once each or very few times, as is the case in a plan

and document (waterfall) process. Individual steps can also be repeated, as in an agile process,

where code iteration, testing, and review can happen many times as necessary. “In contrast to the

Plan-and-Document lifecycles, the Agile lifecycle works with customers to continuously add

features to working prototypes until the customer is satisfied, allowing customers to change what

they want as the project develops.” (p. 45) If building a smaller system, where the customers are

available, and the team has good coding skills, then this agile process may be better suited for the

project.
CST438 Summer 2019b Final Exam

Question 2.

Read these two articles about microservices.

• https://www.atlassian.com/continuous-delivery/microservices

• https://www.atlassian.com/continuous-delivery/microservices/building-microservices

In assignments 7 and 9 you implemented what the articles call microservcies: order, customer

and item microservices.

After studying the articles, in your own words describe advantages of implementing an

application as micro services rather than a single monolithic application.

But microservices also have certain disadvantages and they make certain tasks more difficult.

Your answer should address the additional complexities that microservices have that developers

need to be aware of.

In the end, there is no silver bullet. For certain projects, microservices can be a great solution if

done correctly. But for other projects, using a single monolithic design may be a better

alternative. It takes experience (and luck) to know when to one versus the other.

ESSAY 2:

In the last two assignments of this course, we applied our knowledge of ruby, rails, and

software engineering in a group setting. The final result application was not very complicated,

but learning the system and language was a bit of work. Since we had a partner, it made sense to

split up coding requirements. In a monolithic application, all code is kept in an accessible

location, and resources share code base. This works great for a single developer or small
CST438 Summer 2019b Final Exam

projects. Because this assignment had enough requirements and enough work for more than a

single person, splitting up efforts was necessary. While this is possible with a monolithic

application, changes to the code base can affect all parts of the application. It is difficult to

perform an agile process when any change has so many other dependencies. However, by

creating three separate microservices that we each individually worked on, it was more effort

overall. This really was an effort to create three unique programs, with the added challenge of

creating a REST API for each in order to communicate.

The positive benefits of creating microservices are quickly realized when developing

with a team that produce at different rates. By organizing teams efficiently and equally, you can

create several smaller units that have the elements of a larger group. Each small unit team can

focus on a specific section of an application, focusing on the features, speed, and reliability of

their given section. By being focused on a smaller code base and less features, the overall

objective is easier to track. This also allows the project to be in a good place to handle

infrastructure failure, since either only a small portion will go down, or a backup microsystem of

the application can be rerouted and hosted at another location. In the end, there is no right

answer, but plenty to consider.