SOFTWARE DEVELOPMENT METHODS IN SOFTWARE ENGINEERING

Software Development Methods in Software Engineering

Joshua M. Avalos

The Pennsylvania State University

Author Note

Joshua M. Avalos, Undergraduate Student in the College of Engineering, The

Pennsylvania State University.

This research is being conducted as a special honors assignment with CMPSC 200 in

association with the Schreyer Honors College.

Communication regarding this paper should be addressed to Joshua Avalos at 028

Atherton Hall, University Park, PA 16802. Contact: jqa5409@psu.edu.

SOFTWARE DEVELOPMENT METHODS IN SOFTWARE ENGINEERING
2

Abstract

This paper explores three software

development cycles: the V-Model, the
Iterative Model, and the Spiral Model. The
following research aims to explain these
cycles to beginner-level Computer Science
students. While many engineers have never
heard of it, the V-Model is extremely
profitable and constructive. Its modeling
allows software engineers to use its
chronological path of process execution in
order to appropriately make a functioning
operation. The Iterative Model and the Spiral
Model are similar in terms of their
path-making. Among other things, the
V-Model, the Iterative Model, and the Spiral
Model’s strengths, weaknesses, and various
uses and abilities are each discussed in this
paper. Additionally, this paper reflects on
various experiences in a MATLAB Computer
Science class and analyzes a 2018
Pennsylvania State University Capstone
Project.

Keywords: ​v model, integration,

verification, validation, iterative, spiral, risk,
programming, penn state, computer science,
capstone.
SOFTWARE DEVELOPMENT METHODS IN SOFTWARE ENGINEERING
3

Table of Contents:
1. V-Model
1.1. Definition
1.2. Applications
2. Iterative Model
2.1. Definition
2.2. Applications
3. Spiral Model
3.1. Definition
3.2. Applications
4. Experiences in Computer Science 200
5. Computer Science Capstone Analysis
6. Conclusion
SOFTWARE DEVELOPMENT METHODS IN SOFTWARE ENGINEERING
1. The V-Model
In this section, the V-Model is defined and
analyzed for its various applications.
1.1 Definition
The V-Model is an alternative form of the
traditional Waterfall Model used for software
development processes. Originally, the
Waterfall Model, introduced by computer
scientist Winston W. Royce in 1970, was
made as a developmental process that
emphasized a steady progression through the
maturation of a software. This process aids
software engineers to develop dependable
code for their customers to ensure the least
amount of instability. As shown in Figure 1,
the Waterfall Model forms its software by
moving down cascading steps.
Figure 1. Progression of Waterfall Model
(Powell-Morse, 2017)
The sequence is as follows: system
engineering, analysis, design, code, testing,
and maintenance. Likewise, the V-Model
follows a similar path: it initially requires
elicitation. Once this is complete, the software
is designed and coded. It is then tested,
verified, and validated, and it is then used and
maintenance is done on it as needed.
The main objective of all of these
stages (which, in theory, are meant to be
followed semi-strictly) in this model is to
4
itemize specific details of each part of a
software project using both verification stages
and validation stages to create a well-founded
software unit. Ultimately, the end user set
defines the products termination and if it
satisfactorily meets all of its needs. Finally, a
distinction must be made between verification
and validation. Verification is evaluating the
process at a certain phase to observe if it
meets the specified design requirements, while
validation is evaluating the entire project to
determine if it meets business requirements
(Halpin, 2003).
The following stages are under the
verification unit of the model. It is interesting
to note that after each of these stages,
programmers using the V-Model create the
corresponding tests for that part of the
program that are found in the validation unit
to implement them later in the process.
Figure 2.​ The V-Model (Powell-Morse, 2017)
Concept of Operations is a foundational
document that describes the main purpose of
the software by using interviews from
potential and trial users. This document is
drafted to analyze the needs of the user with
the purpose of shaping a quintessential picture
of what the program should turn out to be.
Ultimately, this requires excellent requirement
elicitation: a true engineer knows exactly what
to ask in order to lure out the important details
of the project. One of the benefits of this
system is that it makes the end goal of the
SOFTWARE DEVELOPMENT METHODS IN SOFTWARE ENGINEERING
program extremely clear. It specifies all of the
details of the project before it progresses into
a design stage in any way. This leaves little
leeway for creative inspirations (that could
potentially cause disruptions) along the way.
The Requirements and Architecture
does not determine how the software is going
to be constructed, but instead documents the
initial needs mentioned in the Concept of
Operations and analyzes what is required to
help eliminate the needs. This list will include
more detailed information such as data layers,
business logic, technical hardware, and
software components. Finally, the Detailed
Design, often referred to as the high- and
low-level design phases, links up all of the
components and ties together all of the
technical loose ends that exist with the code.
This often includes writing up integration and
unit tests to use after the implementation and
writing. The step-by-step writing of the
instruction manual and the code itself does not
allow for any creative liberty or shortcuts, in
turn allowing a possibly slower but
better-quality result (Mohammed, Munassar,
& Gorvardhan, 2010).
The validation unit of the model
consists of three additional stages to test the
product. First comes the unit testing which
eliminates the majority of issues that the
program can run into: logic and syntax errors.
Of course, with more complex projects, it
takes a long time to test all scenarios for a
perfectly running program. Next, the System
Testing ensures that the program can work
across all intended platforms and with all
intended third-party associations. After being
verified and validated, the program is then put
into operation where the program is deployed
to the intended users. This is where it is
supposed to work flawlessly towards whatever
goals it is told to accomplish.
5
1.2 The Value of the V: Applications
For exceptionally-disciplined work, the
V-Model is the ideal solution. Of course, it
does depend on project size and its original
specifications. It offers a small, step-by-step
concept for everyone involved in the process
to reference and understand. Even in terms of
a program such as MATLAB, the V-Model
can manage a coder’s every action when
dealing with a specific project. For example,
using its stage-by-stage testing in MATLAB
would allow the programmer to understand
where possible errors might happen in the
broader spectrum before they happen in the
specificities of the code.
Additionally, the model’s clear outline
allows bigger companies the chance to use the
different stages as milestones for due dates or
process markers. This can be viewed as a
differently formatted Gantt chart (a bar chart
that shows a project schedule). Conversely,
the V-Model is a substandard fit in some
circumstances. For example, the biggest
complaint about the model is that a simple
change to one of the Requirements and
Architecture analyses could ruin the entire
process. The model does not fluidly work with
dynamic changes to the beginning stages. If
the process adapted more easily to new
advancements in the desires of a certain
customer, the model would be more readily
utilized than it currently is.
This model works within the medical
industry. The Food and Drug Administration
(FDA) even recommends the use of the
Verification and Validation documentation
model (also known as the V-Model), stating,
“this section recommends the type of testing
documentation you should include in a
premarket submission for a Software Device”
(Center for Devices and Radiological Health,
Center for Biologics Evaluation and Research,
2005). The reason that this governmental
SOFTWARE DEVELOPMENT METHODS IN SOFTWARE ENGINEERING
entity advocates for the use of the V-Model is
specifically to address the level of concern for
the case. The FDA defines ​Level of Concern
as “an estimate of the severity of injury that a
device could permit or inflict, either directly
or indirectly, on a patient or operator as a
result of device failures, design flaws, or
simply by virtue of employing the device for
its intended use.” The FDA’s job is to control
and to mitigate hazards in its respective field,
and by using the V-Model, they are able to
oversee every step of each of their processes
to completion in order to verify and validate
its quality (Center for Devices and
Radiological Health, Center for Biologics
Evaluation and Research).
In the Institute of Medicine’s
November 1999 issue, To Err Is Human was
the highlight of the journal. This article
discussed building a safer health system in the
United States, specifically regarding systems
and software equipment. It states that “care in
the United States is not as safe as it should be
‑ and can be. At least 44,000 people, and
perhaps as many as 98,000 people, die in
hospitals each year as a result of medical
errors that could have been prevented” (Kohn,
Corrigan, & Donaldson, 2000). McCaffery,
Donnelly, Darling, and Wilkie, authors of A
Software Process Development, Assessment
and Improvement Framework, for the Medical
Device Industry believe that the reasoning
behind this is the lack of process
implementation in modern healthcare
facilities.
The authors see that the complexities
of internal and external medical devices are
almost incomprehensible. Half way through
the article, the V-Model is mentioned as a
possible remedy for these types of problems.
They state that, “the framework [of the
V-Model] will… ensure that developed,
reused, or off-the-shelf software satisfies
functional, operational, and regulatory
requirements throughout the system life cycle.
6
As each stage of the life cycle can be
performed using various methodologies and
project management processes, the model will
be flexible to support the implementation and
integration of preferred methodologies into the
framework” (McCaffery, Donnelly, Dorling,
& Wilkie, 2004).
The V-Model is a useful organizational
tool that helps anyone from small-scale coders
to large medical device manufacturers avoid
obstructions in their overall creation process.
The gradual climb down the verification
stages and back up the validation stages
allows for a slow, controlled molding of
extremely specific code, typically ending up
with a perfected result. As a result of this,
however, many find it excessively slow and
choose to incorporate different methods. This
lack of speed deters both small and large
groups from using it. Just like other fields of
business, coding is no different: some groups
want the job done yesterday, so any process
that does not completely guarantee the success
of their system and slows it down in the
process is vetoed from the creation process
immediately. In fact, the V- Model is not a
complete warranty for any system to work
perfectly. As Robert O’Keefe states in his
article on verification and validation in expert
systems, “verity, validity, and credibility does
not guarantee a useable, let alone useful,
system. A system may be unusable, for
example, because its response time is too slow
or the interface is too complex.” Overall, the
V-Model can be used well in some
circumstances, but it surely is not suitable for
all problems in software engineering.
2. The Iterative Model
In this section, the Iterative Model is defined
and analyzed for its various applications.
SOFTWARE DEVELOPMENT METHODS IN SOFTWARE ENGINEERING
2.1 Definition
The Iterative Model is much different from
both the V-Model and the Waterfall Model in
both its organization and its intended use. One
main difference between this model and other
models is that it does not start with a full list
of specifications or requirements for the
project it is intended for.
Figure 3. The Iterative Model (Powell-Morse,
2017)
Instead, the process starts with a small portion
of the project already in mind and arranges it
in such a way that it is easy to build upon the
idea. It is almost like painting a picture: one
starts with rough sketches, then moves on to
filling in your picture with color, and finally,
erases the rough marks and edges to complete
the painting and sell it or display it. The
Iterative model works the same way; it starts
with initialization and planning, and after a
few cycles of rebuilding and refining the idea,
it will be ready to deploy from the
initialization and planning stages to the
implementation stage. The requirements phase
follows the initialization and planning stages
and allows the specifications to be roughly
gathered for the first part of the project. This
could be known as the outline of the “rough
draft” for one’s software. Following this, the
design stage regulates the existing draft; this is
where business logistics that are required to
complete the project are contemplated and
7
executed. Once specifics are properly
designed via the end user’s desires, they are
inserted into the project. This creates a rough
sketch of what the entire system will look like
when it is complete. After implementation, the
system is then run through a series of
operations to verify and test its progress.
These operations can vary from project to
project; the tests depend on what that part of
the program was intended to do. Finally, it is
evaluated by the creators, business partners,
and any stakeholders. This allows those
involved to analyze where the project should
be and to compare it to its current situation,
targeting specific goals for the next time
around the loop to make the system better and
stronger the more times it completes loops
around the model. After it has completed
enough loops around the model and has
reached its pinnacle of success, able to
execute all operations it was designed to
perform, it will be implemented and deployed
into its intended field to be used appropriately.
2.2 Integrating the Iterative Model:
Applications
Project Mercury was the first human
spaceflight program started by the United
States. The main goal was to safely send a
man into space before any other country.
While the U.S. was not the first, America
achieved their goal of sending a man into
space and bringing him back in good
condition. This task was accomplished using
the Iterative Model. Craig Larman, a Canadian
computer science specialist, wrote about the
project, saying, “Project Mercury ran with
very short (half-day) iterations that were time
boxed. The development team conducted a
technical review of all changes, and,
interestingly, applied the Extreme
Programming practice of test-first
development, planning, and writing tests
SOFTWARE DEVELOPMENT METHODS IN SOFTWARE ENGINEERING
8

before each micro-increment” (Larman &
Basili, 2003).
As seen here, the U.S.-run project used
the model in an extreme way, completing
entire loops of the model in half of a day.
Humorously enough, NASA did not realize
they were using this model. Gerald M.
Weinberg, a scientist who worked as a team
member for Project Mercury, said this about
the model, “all of us, as far as I can remember,
thought waterfalling of a huge project was
rather stupid, or at least ignorant of the
realities... I think what the waterfall
description did for us was make us realize that
we were doing something else, something
unnamed except for ‘software development’”
(Larman & Basili, 2003).
This method is useful in the sense that
it is continually improving on an old design.
When flaws are spotted in programming errors
or when the final product does not match the
original project description, the development
is easy to reestablish at equilibrium before
continuing to work on it (Kruchten, 2002). It
is also incredibly useful because smaller
iterations and changes to different parts of the
system are more cost effective than large
changes in the plans later on in development.
However, this can be a downfall for
projects that require purchasing equipment,
tools, or resources because the software
engineers are not able to plan accordingly and
buy in bulk. Instead, they may run out of
supplies and are forced to spend money more
regularly buying parts a few at a time in order
to meet the demand as needed. Its agile
adaptation allows for better communication
among smaller teams, especially when under
time crunches like NASA’s “half day”
iterations. Finally, another aspect to the model
is that it openly accepts user feedback during
every phase. Sometimes this can lead to a
slower development because different parts of
each process are being refined during every
phase. Simultaneously, this can be beneficial
in making the ultimate product. Project size
does not matter in this model as much as it did
in the V-Model because it is much easier to
split up separate tasks for different groups
with the intention of completing a loop at a
quicker, productive rate.
3. The Spiral Model
In this section, the Spiral Model is defined and
analyzed for its various applications.
3.1 Definition
The Spiral Model is an amalgamation of
iterative development and the waterfall model.
It places a large emphasis on risk analysis,
allowing for continuous enhancements
throughout the process. As the name implies,
the model works in a spiral-like pattern. A
project is run through each of its four stages,
and once one spiral is completed, it repeats the
stages again in a way that reflects the cardinal
concepts yet evolves it into a more substantial
entity.
Figure 4.​ The Spiral Model (Font, 2015)
Planning is the first stage in The Spiral
Model. In this increment, the requirements for
the project are analyzed and retrieved.
Additionally, a feasibility study is run to
ensure all of the requirements can be met. At
SOFTWARE DEVELOPMENT METHODS IN SOFTWARE ENGINEERING
the end of this stage, a finalized list of
requirements is published; workers should
abide by this list until the next spiral can be
made. The next phase is risk analysis. Risks
are simply situations that could threaten the
success of the project. Now that the
requirements are noted, they are studied and
examined in order to identify potential risks
that might threaten the stability of the project.
If risks are detected, risk mitigation strategy is
implemented to minimize the threat while also
attempting to prevent any impairment of the
requirements. After this, the developmental
stage is activated. The software is engineered
and tested. In the next stage, the evaluation,
summary and defect reports are reviewed and
showed to the end-user to analyze the rough
draft of the project and change any of the
necessary requirements in the project before
starting a new spiral iteration.
Unlike the iterative model, the next
spiral iteration is a complete expansion on the
last one. All of the requirements are built upon
a larger scale, risk analysis is performed with
a larger product in mind, and design and
evaluation are performed with a greater
attention to detail.
3.2 The Spiral Model: Applications
This model is best effectuated in large projects
because of its ability to begin small and
controllably grow into a larger product.
Current Department of Defense (DoD)
acquisition policy in Directive 5000.1 states
that “advanced technology shall be integrated
into producible systems and deployed in the
shortest time practicable. Approved,
time-phased capability needs matched with
available technology and resources enable
evolutionary acquisition strategies.
Evolutionary acquisition strategies are the
preferred approach to satisfying operational
needs. Spiral Incremental development is the
preferred process for executing such
9
strategies.” ("Directive Number 5000.01",
2003, p. 3) The DoD’s main goal is to
integrate new technology into current systems
as efficiently as possible. They recognize that
an evolutionary strategy is the best approach
for this, reconstructing a new program from an
old or current one, spiraling through the
construction phases to ultimately reach the
final product. DoD Instruction 5000.2 states
that “technical risk management should
address risk identification, analysis, mitigation
planning, mitigation implementation, and
tracking.” ("Instruction Number 5000.02",
2015, p. 88) With extremely large projects like
those handled by the DoD, they need to be
cautious when sharing information. They
thoroughly implement the model and take full
advantage of the risk analysis portion of the
spiral. By doing this, they are able to handle
information securely but efficiently.
This method is useful for larger
projects because it incorporates the multi-step
process of the Iterative Model. Especially for
larger projects, the outcomes are much better
if the Spiral Model is used because the
Iterative Model starts with a partial list of
requirements and edits them as needed,
ultimately transforming it into what is needed.
This gives the project a two-dimensional
quality; it simply changes what needs to be
changed in order to fit the final specifications.
The Spiral Model continuously adds to its list
of specifications as the project grows, giving it
a three-dimensional quality and allowing the
smaller foundations of the project to be built
and assessed, turning them into a large
foundation. At the same time, the other
aspects of the project are growing at the same
rate, ultimately allowing an impressive
software package to be created.
The Spiral Model also has its
downsides. While it is beneficial for larger
projects, it takes too much time and resources
to implement for smaller projects. Smaller
projects are better off with the V-Model,
SOFTWARE DEVELOPMENT METHODS IN SOFTWARE ENGINEERING
Waterfall Model, or perhaps the Iterative
Model. Additionally, this model may go on
infinitely for large projects. Not only do all of
the intermediate phases require more
documentation, causing more time to be spent
on composition, but the spiral may never
reach a status where the end-user is happy
with the project, thus trapping the Spiral
Model in an endless loop (Vijay, "Spiral
Model").
4. Experiences in Computer Science 200
Computer Science 200 is a beginner-level
coding course offered at Penn State. In this
class, students learn the programming
language MATLAB, which stands for Matrix
Laboratory. This programming language is
used often in science and engineering fields.
Before this course, I had never taken a coding
course before. As one could imagine, I was
worried and unsure of how well I would
comprehend the material. After each week of
the course, I became less worried and more
confident in my ability to code in MATLAB.
This confidence in coding has improved my
other academic skills as well. This course
taught me to take a step back and to recall the
basics of the material. This newfound learning
technique directly applied to my Calculus 2
class that I took concurrently with this course.
By going back to the basics on the calculus
quiz problems I was able to solve the
problems given to me and to achieve higher
grades. Returning to the basics will ultimately
land one at the solution to their problem, no
matter its level of difficulty.
Every week Computer Science 200
students are given a Problem Set that they are
expected to complete during the first class
session of the week. On this day prior to the
Problem Set working-time, however, there
was also a quiz that tested if the student had
learned the basics from the lecture. I would
suggest for future students to do this Problem
10
Set ahead of time before the quiz. Statistically,
when I did this, I scored an average of 30%
higher on my quizzes. This is because I not
only listened to the lectures, but I applied the
lessons directly afterwards by working ahead
on the Problem Set. This solidified the
information in my brain and allowed me to
fully comprehend the concepts. One of my
biggest mistakes in this course was not doing
this for every quiz to aid my understanding of
the course.
Regarding problem solving approaches
in the course, it is easy to over-complicate the
program that one is trying to create. The best
method of problem solving is to return to the
basics of the code and to add one line at a
time. If one attempts to process every single
line of code in their mind at once, it often
becomes confusing and hard to keep track of,
even for a 10 line program. No matter how big
or small the project, it is typically useful to
review the basics of the program before
starting. Additionally, it is also beneficial to
create pseudocode for the program one wants
to write, effectively planning ahead for your
code. Pseudocode is a verbal description of
code; it is the bridge in between verbal
language and programming language. It
allows a software engineer to have an outline
of the code in bullet point or paragraph form,
and to use that outline as a reference when
writing the code. As aforementioned, it is
difficult to keep track of more than a few lines
of code, so doing this helps to summarize
every step so that the programmer does not
need to keep track of everything at once
Moreover, the level of difficulty for
writing computer code does not depend on its
length. For example, the code below solves a
differential equation in just five lines, yet the
formatting is involved and it may take a few
moments to understand what is occurring. The
formatting requires single quotes around the
‘Dy’ and ‘Dx’ equations, as well as single
quotes around the y(0) and x(0) variables and
SOFTWARE DEVELOPMENT METHODS IN SOFTWARE ENGINEERING
their corresponding values. The programmer
also has to remember to declare the variables
‘x’ and ‘y’ as symbols prior to utilizing them.
syms ​x​ ​y
one = ​'Dy == -y + 3*x'​;
two = ​'Dx == 4*x - 2*y'​;
[sys1, sys2] = dsolve(one, two,
'y(0) = 2'​, ​'x(0) = 1'​)
Other code can be much longer than
this, but at the same time it can be extremely
simple. Note the simplicity in the nine lines of
code illustrated below. The first four lines
describe the ‘A’ and ‘b’ variables, the fifth
and sixth lines find the inverse from these two
values in different ways, and the seventh line
prints the conclusion for the problem (this one
was about shipping packages). While it is
longer than the last one, it is relatively simple
in both formatting and content.
A = [10 25 50
10 -1 0
0 25 -500];
b = [5700; 0; 0];
x1 = inv(A)*b;
x2 = A\b;
fprintf('There were %i light,
%i medium, and %i heavy
packages shipped.\n', x2)
One software development
methodology that I most closely identify with
is the Spiral Model. In my professional life, I
tend to work on projects in small increments
until I know what I am doing and how I can
best dedicate myself to it. Once I am able to
contrive a decent plan, I then foresee the risks,
develop my plan further to suit those risks,
and finally plan for what I am going to do next
for the project on a larger scale. This follows
the Spiral method, and thus I enjoy using it in
many aspects of my life.
11
5. Computer Science Capstone Analysis
Logan Stack is a Junior studying Computer
Science at Pennsylvania State University. He
proactively enrolled in a required senior
capstone course, Computer Science 483W.
The client that he and four seniors were
assigned to was named Brian Shippert, a State
College intensivist (a doctor specializing in
emergency medicine). After he and his group
of physicians are done with procedures, they
typically write their working hours on a
scheduling sheet in pencil. Of course, fatigue,
human error, and recall bias all play a role in
potential faulty memory of the times worked.
Additionally, the government requires a more
concrete timestamping system as evidence that
their hours were accurate. As their capstone
project, Logan’s team was asked to develop an
iPhone app to solve these problems.
While developing this app, the team
didn’t necessarily aim to use a specific
software development model. Instead, they
started where they felt was best, with the
project’s requirements. Ultimately, they ended
up ascribing to the Waterfall Model. Logan
describes it as more of “an instinct rather than
a distinct following of guidelines.” The model
worked very well for the team, but not without
the help of a Gantt chart to organize all of the
project information. This included project start
times, finishing deadlines, progress
percentages, weekly reports, and presentation
schedules. Due to the fact that they are all
busy students, the group also added leeway
into their chart to give them flexibility in the
creation of their app.
While there was a $1000 budget from
the Penn State Computer Science Capstone
department, they didn’t use any money thus
far for the project, because all of the work has
been done via free editing software. The
project itself was written in Swift, which is
SOFTWARE DEVELOPMENT METHODS IN SOFTWARE ENGINEERING
Apple’s specialized programming language.
The visual aspects of the app were presented
to the client using a program called Marvel.
The team used this program’s drag-and-drop
interface to show the client what his app
would look like once they coded it. They met
with him once a week for an entire semester to
show him what they had worked on and ask
for his input on what was developed so far.
Figure 5.​ Completed Timer Page
While the visual part of the app was
relatively basic, the coding part was where his
team ran into problems. None of them knew
how to code in Swift. Fortunately, Logan and
his team of expert student programmers found
the language to be docile and easy to work
12
with. They learned it as they went until they
fully understood the language and could write
the rest of the app in it fluently.
The app is currently near completion.
The only thing that Logan is still working on
is implementing the app with a secure server
in order to abide by HIPAA and other health
confidentiality restrictions. Their biggest
problem is finding a cheap yet reliable
database to store the client’s information on.
Throughout the process, Logan states that he
learned how to effectively work and
communicate in a professional environment,
especially in speaking with Dr. Shipman.
Moreover, Dr. Shipman expresses regularly
how satisfied he is with the work that has
been completed.
6. Conclusion
In this deliverable, the V-Model, the Iterative
Model, and the Spiral Model were all
analyzed using their definitions and their
applications. Then, the author’s experience in
Computer Science 200 was discussed. Finally,
a Penn State Computer Science Capstone
Project was explained using the terminology
and techniques discussed in this deliverable as
guidelines for a fair assessment.
SOFTWARE DEVELOPMENT METHODS IN SOFTWARE ENGINEERING
References
Boehm, B., Brown, W., & Turner, R. (2005).
Spiral development of
software-intensive systems of systems.
Proceedings of the 27th international
conference on Software engineering -
ICSE 05​.
doi:10.1145/1062455.1062628
Center for Devices and Radiological Health,
Center for Biologics Evaluation and
Research. (2005, May 11). Guidance
Documents (Medical Devices and
Radiation-Emitting Products) - McCaffery, F., Donnelly, P. K., Dorling, A.,
Guidance for the Content of Premarket
Submissions for Software Contained in
Medical Devices. Retrieved January
26, 2018, from
https://www.fda.gov/MedicalDevices/
DeviceRegulationandGuidance/Guidan
ceDocuments/ucm089543.htm.
Completed Timer Page [Personal photograph
taken on Logan's iPhone]. (2018, April
13).
United States of America, Department of
Defense. (2003). ​Directive Number
5000.01. ​Retrieved March 16, 2018,
from
www.esd.whs.mil/Portals/54/Documen
ts/DD/issuances/dodd/500001p.pdf.
Font, V. M., Jr. (2014, December 26). Spiral
Model. Retrieved March 16, 2018,
from
http://ultimatesdlc.com/spiral-model/.
Halpin, V. (n.d.). Verification vs. Validation.
Retrieved from
www.iigsystems.com/pdf/Verification
%20vs%20Validation.pdf.
United States of America, Department of
Defense. (2015). ​Instruction Number
5000.02. ​Retrieved March 16, 2018,
from
www.esd.whs.mil/Portals/54/Documen
ts/DD/issuances/dodi/500002_dodi_20
15.pdf.
13
Kohn, L., Corrigan, J., & M. D. (2000). To Err
Is Human. National Academy Press.
doi:10.17226/9728
Kruchten, P. (2002, October 15). Planning an
Iterative Project. Retrieved February
14, 2018, from
https://www.ibm.com/developerworks/
rational/library/2831.html.
Larman, C., & Basili, V. (2003). Iterative and
incremental developments. a brief
history. ​Computer,36​(6), 47-56.
doi:10.1109/mc.2003.1204375
& Wilkie, F. G. (2004). A Software
Process Development, Assessment and
Improvement Framework, for the
Medical Device Industry. IQ
Solutions. Retrieved January 26, 2018,
from
https://ulir.ul.ie/bitstream/handle/1034
4/2153/2004_mccaffery.pdf?sequence
=2.
Mohammed, N., Munassar, A., & Gorvardhan,
A. (2010). A Comparison Between
Five Models Of Software Engineering.
International Journal of Computer
Science Issues, 7(5). Retrieved January
23, 2018, from
http://ijcsi.org/papers/7-5-94-101.pdf.
O'Keefe, R. M., & O'Leary, D. E. (1993).
Expert system verification and
validation: a survey and tutorial.
Artificial Intelligence Review, 7.
Retrieved February 13, 2018, from
https://msbfile03.usc.edu/digitalmeasu
res/oleary/intellcont/ES-Verification-v
alidation-2.pdf.
Powell-Morse, A. (2016, December 08).
Waterfall Model: What Is It and When
Should You Use It? Retrieved January
25, 2018, from
https://airbrake.io/blog/sdlc/waterfall-
model.
Powell-Morse, A. (2016, December 15).
Iterative Model: What Is It And When
SOFTWARE DEVELOPMENT METHODS IN SOFTWARE ENGINEERING
14

Should You Use It? Retrieved

February 14, 2018, from
https://airbrake.io/blog/sdlc/iterative-m
odel.
Powell-Morse, A. (2016, December 26).
V-Model: What Is It And How Do
You Use It? Retrieved January 24,
2018, from
https://airbrake.io/blog/sdlc/v-model​.
SDLC Spiral Model. (2018, January 08).
Retrieved March 16, 2018, from
https://www.tutorialspoint.com/sdlc/sd
lc_spiral_model.htm.
SDLC V-Model. (n.d.). Retrieved January 26,
2018, from
https://www.tutorialspoint.com/sdlc/sd
lc_v_model.htm.
V. (n.d.). Spiral Model. Retrieved March 16,
2018, from
http://www.softwaretestinghelp.com/s
piral-model-what-is-sdlc-spiral-model.
V-Model. (n.d.). Retrieved January 26, 2018,
from
http://www.onestoptesting.com/sdlc-m
odels/v-model.asp.
V-Model (Software Development Life Cycle).
(2014, November 29). Retrieved
January 26, 2018, from
http://www.softwaretestingclass.com/v
-model/.