Budzinski 1
Analysis of Various Software Development Practices
Steven Budzinski
Abstract
This paper explores three different types of software
development cycles: the traditional V model, the more
recent Agile Software Development Life Cycle (SDLC),
and the classical Spiral SDLC. The V model is a specific
SDLC that is heavily reliant on planning and then
executing certain tests to be carried out after the code is
written. The development starts with broad analysis of
requirements, trickles down into a system analysis, is
coded, and then is unit tested, system tested, and finally
user tested. A more contemporary type of software
development cycle is the Agile SDLC which is based on
the concept of producing multiple iterations of the
software until the customer is satisfied with the result. It
is developed by individuals who take on multiple roles
(coding, testing, infrastructure etc.) and who work
closely with the customer to delineate exactly what the
customer wants. A third type of software development
methodology is the Spiral SDLC, which acts as a
medium between the two aforementioned Software
Development Strategies. In this risk driven type of
software development, the developers seek to first look
for pre-existing software to use, and then move into
coding and testing after calculating the risk of various
facets of the software. It, like the Agile SDLC, is an
iterative process in which customer feedback is utilized.
This paper also includes a personal reflection on gained
confidence, advice for future students, SDLCs the author
most closely relates to, a discussion regarding
complexity and lines of code, and how the author views
problems in other courses. Finally, this paper analyzes
one particular Capstone project that was centered on
updating the outdated scoring system used at the
Capstone design fair.
I. Introduction
Software development cycles are set processes software
developers use to create software. While there are many
ways to develop software, both planned and unplanned,
this essay explores several methods of specific software
developments. Section II is one particular model of
software development called the V software
development cycle, named not only after its shape (a V
shape) but also after the V in verification, and the V in
validation. Stephen A. Jacklin of the NASA Ames
Research Center defines software verification to be “the
testing done to make sure the software code performs the
functions it was designed to perform” [13]. Validation
on the other hand is “the testing performed to prove that
the verified code meets all of its requirements in the
target system or platform” [13]. The V is split into two
different branches with verification techniques occurring
on the left branch of the V and the validation techniques
used on the right branch of the V. As can be seen in Fig.
1, a more detailed layout of the design is depicted, with
events proceeding along the bolded arrows to the right in
chronological order [1]. Although not particularly
included in either the V model, the Agile Software
Development Life Cycle (SDLC) or in the Spiral SDLC,
software maintenance “forms an essential component of
software development” as there is a constant “demand of
users to ensure that existing software products run on
newer platforms, run on newer environments, and [run]
with enhanced features” [10]. Described in Section III is
the Agile SDLC which is based off of the principle that
the customer is likely to change their requirements
throughout development, and thus multiple iterations are
produced, so that the customer can tailor the software to
their exact needs. Described in Section IV is the Spiral
SDLC which is named after the spiral shaped path that
the development takes. It, like the Agile SDLC, works as
an iterative process and is flexible to changes in
customer needs and budget changes. Stated in Section V
is a personal reflection on the author’s preference to the
Agile SDLC, along with with other advice and insight to
CMPSC 200 students, based off of the author’s personal
expierences. Section VI includes an analysis of a
capstone project tasked with updating the website based
syestem used by judges during the actual Capstone
design showcase.
II. The V Model
A) Verification
The verification half of the V is split into several
different steps and acts as the path from customer needs
to actual coding. Software verification is defined as the
“testing performed to check that the progressive
decomposition of requirements to code has been done
correctly” [13].
1) Requirements Definition Phase: In the requirements
stage, the user needs of the project are delineated.
Typically, this is done by directly interviewing the
stakeholders of the project, which typically consist of

users and the employing party, to find the system’s
“functional, physical, interface, performance data, and
security requirements” [1]. In essence, the requirements
definition phase is preliminary to all other steps to
ensure that the project meets the requirements and
ensures that the development team has a clear idea of the
goals and expectations for the final product.
Figure 1: A Visual Representation of the V Model [1]
2) System Design/ Architecture Design Phase: In this
next phase, the user requirements are refined into broad
ideas of how the coding will take shape and look.
Mohammed Darwish from Cranefield University states
that systems architecture “provides the strategies and
modelling approaches to ensure that adequate resources
are spent in developing the possible software” [2].
Basically, software developers use this phase to map out
how they want to approach coding the project and ensure
that the structure is logical and visually appealing.
During this phase lists of graphs, variables, and other
software specific data is compiled so that they can be
directly implemented into the coding stage. Here, what is
called the software specification document (information
containing the general system organization) is drafted,
and acts as a visual idea of what the software will look
like [2].
3) Coding Phase: In this middle phase, the code is
finally written. Now that the project has been broken
down from the two previous stages, the software
developer can readily develop “low level design” codes
that each pertain to a different part of the software; some
examples may include database tables (matrices of
information), interface tables (tables in which the user
inputs information), error messages, and input and
output modules [2]. Now that the code is written, testing
can begin.
Budzinski 2
B) Validation
Software validation is defined as the testing of a piece of
integrated software code that proves that it meets the
system requirements [13]. In other words, in the
validation phase the software is tested and goes from
small unit testing to make its way up to a polished
product that correctly interacts with the user.
1) Unit Testing: In this low-level stage of testing, basic
algorithms in the code are evaluated and bugs are fixed,
albeit, not all bugs can be completely ironed out for
certainty as a software may appear to preform
proficiently through testing, but users may find errors
later on [10]. In other words, the software developer can
never fully demonstrate that the software is free of bugs.
As software development expert Barry Boehm states, “a
fault discovered and corrected in the unit testing phase is
more than a hundred times cheaper than if it is done after
customer delivery” [3]. The tester also verifies that the
code is efficient, and is typically done in a “white box
fashion which typically consists of the software
developer having knowledge of which internal structure,
design, or implementation of the item is being tested [4].
By using this testing method, the tester(s) can directly
find the root of any problems and quickly resolve them.
2) System Testing: In this penultimate step, the
software is tested to see if the different modules
communicate effectively with each other, and how the
overall system interacts with the user. System testing is
done to compare the system specifications to the system
itself, meaning that testing is done to make sure that the
actual software is holistically polished and finished [1].
3) User Acceptance Test: In this stage, final checks are
done on the software to determine acceptance by the
customer. Initial requirements are revisited, and some
procedural examples including reviewing interface
quality and software quality requirements, along with
user and customer expectations are reviewed [1].
C) Maintenance of the Software
After the release of the software, work is still done on
the actual software. Dr. Edward Ogheneovo of the
Department of Computer Science at the University of
Port Harcourt, Nigeria describes software maintenance
as “the process of modifying existing operational
software by correcting errors, migration of the software
to new technologies and platforms, and adapting it to
deal with new environmental requirements” [10]. In
essence, it includes any changes made to a software
product before (if the timeline of development is long
enough in which already written code needs to be
adjusted to contemporary operating systems) or after

delivery to the customer or user. As software products
are used, faults must be discovered, operating
environments may change, and new user requirements
will surface. In fact, most maintenance processes are
often requested by software users themselves [10].
Software maintenance, although dependent on what
needs to be fixed (specified by either a complaint or a
noted problem), can be divided into four distinctions:
1) Corrective Maintenance: This type of maintenance
involves the software product after delivery to correct
errors or to fix bugs in the software. Usually, in
corrective maintenance, errors are corrected, and the cost
of corrective maintenance is taken on by the developer
[10]. Typically, if a user were to request maintenance on
the system, corrective maintenance is normally required.
2) Adaptive Maintenance: Modifications to the
software as a result of changes in operating
environments falls under adaptive maintenance, to
ensure that the software is still applicable to its
environment after delivery. Such changes may include
“result[s] of database upgrades, operating system
upgrade[s], changes in compiler version, etc.” [10].
Usually, the organization requesting for adaptive
maintenance bears the costs as the software developer
was originally only responsible for the environment,
they created the software in [10].
3) Perfective Maintenance: Perfective maintenance
often involves alterations in the code that still allow for
the code to meet the same requirements, but in a
significantly more acceptable manner. While the product
may be deemed functional, perfective maintenance is
down to increase the performance of a software [10].
4) Preventive Maintenance: In preventive maintenance,
software is usually modified after the delivery to detect
and correct latent faults before they become effective
faults [10]. Latent faults are errors that have not
presented themselves yet. Active faults are errors whose
faults are openly displayed and seen by the user. In this
last type of maintenance, developers try to fix the
problems before they surface by looking into
problematic conditions that could breed bugs.
D) Analysis of the V Model
1) Advantages of the V Model: Since this model is so
test heavy, defects in the software are fixed in a narrow
to broad fashion. In other words, since the coding testing
occurs before the systems testing, the systems testing
strictly looks at systems requirements rather than
worrying about defects in the code [10]. As such, the V
Budzinski 3
model avoids the negative effects of an early stage
problem and reduces cost for fixing the defect in
question [3].
2) Disadvantages of the V Model: While the V model’s
rigid design may make finding defects easy, the model is
very inflexible when it comes to changes in
requirements. For large scale operations that use a
plethora of documentation, “if any changes happen
midway, not only the requirements documents but also
the test documentation need to be updated” which could
result in loss of time and/or money [1].
3) When Should the V Model be Used? Since the V
Model is so rigid in it its development ideology, it likely
should not be used for any type of project in which the
customer needs are likely to change [1]. That being said,
a project in which the requirements are set in stone and
outlined from the start of the project are likely to use the
V model. Also, since the process is typically done by a
variety of engineers (for example a system engineer for
the systems design) with their particular contributions
being separated, it can be done in projects in which the
particular developers are not physically collocated.
III. Agile SDLC
A) Agile SDLC Origin and Basis
Contrary to the V model development, the Agile SDLC
does not focus on a strict plan. Rather than adhering to a
more traditional style of development, the Agile SDLC
places lesser emphasis on process and documentation
and pays more emphasis on quickly developing products
and satisfying customers by incorporating their changing
needs [3]. The SDLC is built on the 12 principles of the
Agile Manifesto and was created by a group of 17
software practitioners in 2001 to scribe their common
ideology [5]. Their main philosophy can be designated
into the ideas of
1) Individuals and interactions over processes and
tools
2) Working software over comprehensive
documentation
3) Customer collaboration over contract negotiation
4) Responding to change over following a plan. [5]
These pillars can also be further broken down into the 12
principles of the Agile Manifesto which include:

1) Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software.
2) Welcome changing requirements, even late in
development. Agile processes harness change for
the customer's competitive advantage.
3) Deliver working software frequently, from a
couple of weeks to a couple of months, with a
preference to the shorter timescale.
4) Business people and developers must work
together daily throughout the project.
5) Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done.
6) The most efficient and effective method of
conveying information to and within a development
team is face-to-face conversation.
7) Working software is the primary measure of
progress.
8) Agile processes promote sustainable
development. The sponsors, developers, and users
should be able to maintain a constant pace
indefinitely.
9) Continuous attention to technical excellence
and good design enhances agility.
10) Simplicity is the art of maximizing the amount
of work not done is essential.
11) The best architectures, requirements, and
designs emerge from self-organizing teams.
12) At regular intervals, the team reflects on how
to become more effective, then tunes and adjusts
its behavior accordingly” [6].
The Agile philosophy can be visualized in Fig. 2 [6].
B) Agile Software Development Process
In Manish Sethi’s textbook Cloud Native Python, he
describes the Agile SDLC as “different phases, all
modules or features [which] are delivered in iterations,
and cross-functional teams from various areas such as
planning, unit testing, design, requirement analysis,
Budzinski 4
coding, and so on work simultaneously” [7]. The design
process can be viewed in Fig. 3, where requirements
analysis and design phases, are accumulated into the
high-level planning bubble.
Figure 2: Visual Representation of the 12 Agile
Principles [6]
The cycle begins with an initial planning stage, which
locates the details about the software features, and which
defines the goals in high-level planning. Once the
project goals are set, the developers start coding for the
required feature, and when the developers are finished,
the testing team (also known as the QA team) starts
executing both unit and integration testing. From there,
if any bugs are found, they are fixed immediately, and
then the code is delivered for client testing (that is, on
stage or the pre-production environment) [7]. It is an
important distinction to make that at this stage, the code
is not released yet; the code is only delivered to the
client for feedback, so that the developers can make
changes to the software before it is fully released. As
Gerry Coleman, Software Engineering Professor at the
Dundalk Institute of Technology, states, “Agile
development focuses on early delivery of working
software and aims to get the product into the hands of
the customer as quickly as possible” [8]. This iterative
process of producing a working copy for the customer to
interact with, not only increases customer satisfaction,
but also results in a software that more closely aligns
with what the customer wants. Should the customer want
to alter the produced software, the Agile process simply
runs another cycle of the above steps until the customer
is satisfied with the end result. Should the code pass all
client-based testing, such as UI based testing, then the
code is pushed to production [7]. UI is an abbreviation
for User Interface, and consists of everything (the
mouse, keyboard, desktop, and screen) that the user can

interact with. After, the code is created maintenance may
be done on it, but Agile software maintenance can be
generalized under the general code maintenance above in
Section 2, Part C.
Figure 3: A Visual Representation of the Agile Software
Devlopment Life Cycle [7]
C) Analysis of the Agile SDLC
1) Advantages of the Agile SDLC: In the Agile SDLC
each functionality is developed and demonstrated
quickly and frequently in order to produce features with
minimal bugs until its deployment [9]. Instead of the
traditional method of software development (such as
what can be found in the V Model), the actual testing for
bugs is done during all throughout the Agile SDLC to
ensure that the product can be created as fast as possible.
This method differs from the traditional V Model
approach of assigning a particular stage during the
Software Development Cycle to test for bugs. Thus, this
bug fix requires minimal documentation as the bugs do
not have to be recorded for a later phase that is devoted
to bug testing [9].
There does not exist a separate team for development,
testing, etc.; instead, there exists a single team, which
consists of 8-10 members (based on the requirements),
and each member is capable of doing everything [7].
Some skills that team members may have include
“programming, testing, analysis, database
administration, user experience, and infrastructure,
among others” [8]. Again, the Agile SDLC’s third
philosophical point is to prioritize “customer
collaboration over contract negotiation”; to best increase
customer feedback (and eventual satisfaction), the Agile
SDLC, needs to be iterative, and output many variations,
in their development window [6]. It is of note, that
Budzinski 5
although the Agile ideology may increase customer
satisfaction due to lack of contract, the same lack of set
requirements and goals of a contract, may make
companies wary to use the Agile SDLC.
2) Disadvantages of the Agile SDLC: One of the
requirements for cycle functionality is to periodically
interact with the customer; although it may be
advantageous for the customer to personally decide what
software they want the most, a customer may not want
the time commitment that comes with periodic review of
iterations [9]. Also, since each software developer is
responsible for virtually all steps of a traditional
development life cycle (programming, testing, analysis,
database administration, user experience, and
infrastructure), oftentimes testing can become a
bottleneck of sorts for Agile projects developing safety
critical systems; the reason being that testing has to be
done very often and at the same time exhaustively
because each iteration needs to be safe enough to
interact with [9].
3) When Should the Agile SDLC be Used? Since the
Agile SDLC is pillared by customer interaction, it
should be used when a customer is willing to actively
take part in the software development [11]. Should the
customer want to give a contractual set of requirements
at the beginning of development cycle, and leave the
developers to complete it, the Agile SDLC should not be
used, as the customer will only receive one iteration of
the software, instead of the many iterations prescribed
by the Agile method. Software developers with
diversified abilities are also emphasized in the Agile
SDLC, as they must take on a variety of responsibilities.
As such when a cross-functional team is employed for
an Agile project, collaboration is fundamental for
success and is a necessary component of the whole-team
approach [8]. On that, the Agile Software Development
Process dictates that collaboration is done with
collocation to allow for increased efficiency of the
development process. When workers share the same
workspace, informal contact becomes more
straightforward and efficient [8]. Should a development
team be spread apart, the collocation aspect may be loss,
and a more traditional method (like the V Model) may
be better suited.
IV. Spiral SDLC
A) Spiral SDLC Origin and Background
Barry Boehm is credited for first writing a formal paper,
Spiral Model of Software Development and
Enhancement on the Spiral Software, on the Spiral

SDLC, however he writes that the Spiral Method has
been “evolving for several years, based on experience
with various refinements of the waterfall model” [14]. In
his paper, Boehm first described the flaws of four
existing SDLC: the Code and Fix Model, the Stage-Wise
and Waterfall models, the Evolutionary Development
Model, and the Transform model. Boehm then proposes
the Spiral Model as a solution for the weaknesses of the
previous four approaches while simultaneously utilizing
the strengths of each of the other models [17].
According to Dr. João M. Fernandes from the
Universidade do Minho, the Spiral SDLC is a system
“based on a risk-driven approach” where a risk is
defined as a potentially adverse circumstance that can
have negative or perverse effects in the development
process and on the final quality of the system [15]. In
other words, a risk is a measurement of the uncertainty
in achieving the desired objective or meeting project
requirements. As can be seen in Fig. 4, the Spiral Model
gets its name from the spiral shape of its development,
with the radial dimension representing the cumulative
cost of the project up to that point, and the angular
dimension representing the progress of the entire project.
It should be noted that some of the lines representing the
increasing cumulative cost dimension are drawn with
larger spacing than normal to increase legibility,
meaning that a normal spiral mapping of a project would
have a line with a strictly increasing radius [14].
Figure 4: A Visual Representation of the Spiral Software
Devlopment Life Cycle [14]
Budzinski 6
B) Spiral Software Development Process
1) Objective Identification: In this first stage of the
Spiral SDLC the objectives of the project being
developed are determined, with “the performance,
functionality, and ability to accommodate change being
evaluated” [14]. Developers also look into potential
alternates to the current means of implementation, such
as looking into reusing old software, or buying new
software. The cost of the project and other constraints
(e.g. time) are also analyzed during this phase. At the
end of this quadrant, alternative solutions are proposed.
2) Risk Evaluation: In this second stage of the Spiral
SDLC, the alternative solutions of the first step are
evaluated and the best is chosen [15]. Once chosen, the
best solution will be evaluated for various risks
(measurements of the uncertainty in achieving the
desired objective or meeting project requirements). Once
the risks are identified, the risks are resolved through
“prototyping, simulation, benchmarking, reference
checking, administering user questionnaires, analytic
modeling,” or any combination of these risk mediating
methods [14]. At the end of this quadrant, a prototype
should be created.
3) Development and Testing: Once the risks have been
identified and resolved, the development of the software
begins. Based off the previous step of risk analysis, the
developers work towards a new, successful prototype in
a method similar to both the V model, and the Waterfall
Model. In this stage “design, coding, testing, delivery,
and evaluation” are all completed [15]. At the end of this
stage a working iteration of the software should be
finished, and ready to be presented and reviewed in the
next phase
4) Next Iteration Planning: In this final stage of the
Spiral SDLC, the software is reviewed. This review
covers all products developed during the previous cycle;
this step also includes plans for the next product cycle
and predicts the resources required to carry the next
cycle out [15]. The primary objective of the review is to
ensure that all parties involved (the customer, the
developers, and the project manager) are mutually
committed to the approach for the next phase. The plans
for succeeding phases may also divide the product into
separate increments to be developed by other individuals
or other groups of individuals [15]. Continuing on the
idea of risk, the Spiral SDLC is terminated when the
developers deem the risk for the next iteration of the
product as too costly to carry out for either funding
reasons or for the sake of time [15]. For example, if the
developers determined that the current form of the

product would require too much time for refinement, and
risk a competitor releasing the software first, they may
decide to terminate the Spiral SDLC and release the
software. It is also of note that once the project is
deemed finished and no other iterations are to be
completed, the completed software may undergo
software maintenance previously described in Section
II.C.
C) Analysis of the Spiral SDLC
1) Advantages of the Spiral SDLC: Since the Spiral
SDLC is made up of multiple iterations, data from early
iterations can be used as inputs into later model, and the
model can be used to estimate the time and cost of
project completion while decreasing the development
time through utilization of previous prototypes [16]. The
Spiral SDLC also focuses on the early removal of errors
and poor alternatives early in the development as the
iterative nature of the process forces the developers to
analyze their prototypes constantly [15].
2) Disadvantages of the Spiral SDLC: Since the model
also represents multiple iterations of the same product,
customer satisfaction is increased, as the customer can
better delineate exactly what end product he or she
wants. It is of note that - like the Agile SDLC - because
there are multiple iterations of the product, the company
may not want to implement the Spiral SDLC due to the
flexible nature of the Spiral method in contrast to a rigid
contract [15]. The Spiral SDLC is also heavily reliant on
developers’ ability to successfully analyze risk; for
example, if a development team is too inexperienced to
properly assess how much risk is associated within the
next cycle, the project may appear to be more advanced
than it actually is. The Spiral SDLC is also considered to
be one of the more complex SDLCs, making it harder to
implement among inexperienced software developers
[17]. It is also of note that if the developers are not
adequately experienced in the Spiral SDLC, the cycle
could go on for longer than necessary, potentially
draining precious time and money.
3) When should the Spiral SDLC be used? As
articulated in Section IV.C.2., the Spiral SDLC has a
large learning curve, and as such may not be suitable for
large software projects that need a large amount of
developers, since some developers may not be
experienced in the Spiral SDLC [15]. However, with an
adequate number of experts developing the software, this
project may be suitable for projects that have flexible or
changing project requirements, as each iteration may
better help the customer to decide on exactly what it is
that they want for the end product. Since the model is a
Budzinski 7
“risk driven” approach, the Spiral SDLC is also useful
for high risk software such as rocket propulsion, where
numerous variables could cause the project to fail. The
Spiral SDLC should also be used in scenarios where the
developers are in close contact with the customers and
those authorizing the project due to the need to end each
successive cycle with approval of those funding and
sponsoring the project [15]. In tandem with a changing
requirements list, the Spiral SDLC should be used when
there is a possibility for funding changing. Again, since
each iteration requires more money, if a project manager
were to cut funding after a certain iteration, the then
prototype could become the final product.
V. Personal Reflection
Coming into my first college Computer Science class, I
would say that my confidence in my programming skills
was near nothing. Previously, I had taken a rather basic
high school programming class (Microsoft Visual
Basic), however, it was more centered on aesthesis
rather than the logical arguments that exist within a
complex computer language. Thus, I was apprehensive
to learn my first computer language at a college level.
However, through intensive study, practice, and failure, I
continue to become more confident in my programming
skills. Primarily, I was worried about the extensive list
of commands and syntax that I thought I had to
memorize. I learned quite quickly though that since the
assessments allowed for cheat sheets and access to the
MATLAB database, I did not have to memorize the
extensive encyclopedia of commands used throughout
the class. Yes, it did save precious time on assessments
to know the commands off of the top of my hand, but it
was not a necessity. Rather, I found it to be much more
important to understand the program’s flow and logic, as
minor typos in computer code can be readily detected by
the internal error detection system while a logic-oriented
problem may not be detected and will be harder to find
and correct. Furthermore, I would recommend to
incoming students to be sure to study the logic of the
examples, and to practice the examples on their own
time. In my own experience, I could get through the
earlier assignments simply by memorizing and
regurgitating the simple examples done during the
recitation; during the later assessments though, I noticed
an increased need to fully understand the “why” instead
of the “what” for coding.
From this ideology, I have begun to develop an intuition,
although imperfect, on how to solve the assessments. In
my experience, I have begun to realize that the
assessments typically asked for multiple parts, and as
such, were reliant on previous answers. Thus, I will
typically write out a pseudocode first to see where and
 Budzinski 8

when I want to implement lines of code, so that I can multiply the inverse by another vector; ultimately, this
visually see the connections between the input variables was a fairly straightforward task.
and the later steps. Furthermore, I find it more efficient
to fix any problems in the code with the pseudocode
method, as I can visualize what output should be
produced at the different steps of the code. It is of note
that the size of the code also impacts my intuition. If
given a problem with multiple parts (or even multiple
problems within the assessment) I will always write out
all of the pseudocode first, so that I can navigate the
different parts of the problem. Often, the night before the
assessment I will outline the major programming
features or new functions, and then I will connect them
to my pseudocode during the assessment. However, if
the assessment asks for a quick function that I can
quickly recall from my mind, I will quickly code it while
the question is still fresh in my mind.

In regard to the SDLC that I most closely relate to, I

would say that during my early programming
assessments I would normally use the Code and Fix
method, or in other words, I would simply code out what
I thought the question was asking for, and then click the
run button to see what went wrong. From there, I would
only recode the wrong line and then run the program
again. I would then tediously continue this process until
I had an error-free code that fulfilled the program
requirements.
As the programs grew to be more time constraining and
complex, I began to switch my ideology to align more
closely with the Spiral SDLC. Typically, I will begin my
development by outlining the problem needs and
prioritizing problem sections (if there are multiple parts
to the problem, or if there are multiple questions).
Instead of building models, I will then write some lines
of pseudocode to help me to better assess what needs to
be done during coding. From there, I code a section of
my program, and analyze the importance (or the risk
when considering the Spiral SDLC) of the next sections
of the program. Depending on what I deem most
important to work on next, I will either test my code just
written or move onto the next part of the problem set. If
I have decided to move onto the next section of the
problem, I will repeat my steps until I judge that the full
project is ready to submit.
Fig. 5: Code Taken from a MATLAB Script File
However, since the variable labeled M is an 8 x 8
matrix, the actual code of the program looks much more
complex then something seen in Fig. 6. In Fig. 6,
commands were nested twice, and used to create the
“X”-like shape found in Fig. 7. Again, there are four
more lines of code found in Fig. 5, however the
operations performed in Fig.6 are much more complex
due to the forethought necessary to plan out the nested
for loops and if statements. In my opinion, difficulty of
code is less about how many lines of code there are, or
even how many operations are carried out by the script.
If a student only had to preform simple operations such
as multiplication or sine determinations, it would hardly
matter how many times they had to do it, or how many
lines of code there were, as it would be a repetitive and
simple task to carry out. On the other hand, if a student
had to use several different commands that each relied
on each other, and required forethought dependent on
computer logic, then the code would become much more
difficult to develop.

The lines of code (LOC) does not necessarily correlate

with the difficulty of the code nor does it directly affect
the complexity of the code. For example, as shown in
Fig. 5, multiple lines of code are used to simply create a
sparse matrix used later in the problem. The initial
question asked for the inverse of the matrix, and then to

Fig. 6: Code Taken from a MATLAB Script File
Surprisingly, learning to program has changed how I
view problems presented from my English courses more
than my core STEM courses. Before I learned how to
program, I typically solved problems in my English class
(writing essays for a specific prompt) in a similar way
that I initially wrote code: I wrote without a clear
intention, and after I wrote the complete essay, I would
go back and fix all of the glaring issues. After learning to
program though, I have gained a new perspective on
how an early problem, or a repetitive problem can
quickly diminish the final product. Continuing with the
essay example, if I were utilizing a specific piece of
evidence all throughout the essay, and only in the later
stages of editing realized that it did not match what the
essay was looking for, I would have to overhaul the
entire piece. Similarly, if I were to read the problem
statement incorrectly, and only discovered that I was
coding for the wrong task when I reached testing, I
would have to rework the entire program. Now that I
have learned to program, I have realized the importance
of outlining and ensuring that I fully understand the
problem statement so as to save time later.
VI. Senior Capstone Analysis
Since 2010, the senior Capstone design competition
utilized a website-based software to aid in the judging
process of the competition. The old system was limited
in its capabilities in that the scoring data only displayed
the total votes cast for each group, which led to a need
for hand calculations to break ties. Thus, the host of the
event, the Learning Factory, requested for an overhaul of
the judging system which was tasked to this Capstone
group. Some of the requirements for the project included
creating a website-based software that could intake data
from both judges and the public, computing winners in a
manner expected from the Learning Factory, and then
presenting it in an easy to read output. The current
system also had eight sets of judges, and another
requirement was to add two additional sets of judges.
The Learning Factory also wanted the software to
operate on its own network on iPads and laptops.
Taken from Castle Leonard, one of the developers of the
software, the project was satisfactorily completed, but
she still wished they had more time to plan, or had used
their time more efficiently. Regardless, she said she was
very happy with their final product. She also stated that
she wished some other group members had pulled their
weight more during coding, but that they made up for it
in the poster presentation. Although satisfactory, Castle
is still looking to iron out more bugs, which seems to
follow the normal maintenance of software, as it is
Budzinski 9
impossible to determine exactly if the program is bug
free.
When Castle and her group were planning and
developing the program, they met with their sponsors
frequently along with a retired software engineer.
According to Castle, the retired software engineer
heavily advised the grouped to use the Waterfall SDLC,
but in practice the group hardly ascribed to it. Instead,
Castle said she would have rather developed the
software in a more Agile way, as it fit their process
closer; the group often met with their customer, and had
to make many iterations of the program, which closely
aligns with the Agile SDLC. Indeed, their product was
successful, but Castle was skeptic that it was due to their
SDLC. Instead, she stated that she thought that a SDLC
was impractical for a Capstone project and was more
applicable to a group of developers who worked with
each other over the span of multiple projects.
On the idea of development, Castle said her team
managed their time, costs, and information using their
“triple constraints”. First off, she said that the group
managed their time by creating a development time line
which set deadlines for the group to follow. From there,
the group spent about two months planning out what
would be done to implement the software and then one
month executing the code and bug fixes. Castle also said
that her group was used to pouring a great deal of time
into projects, which meant that the group often stayed
ahead of schedule and did not fall behind on deadlines.
The one exception fell on the day of the presentation in
which Castle still made bug fixes in the hours prior to
the competition. For money, the group, like every other
Capstone group, received $1000 for their project. Castle
said that they hardly needed that much and used their
surplus to buy a router in which the website could run
on. They did in fact have to buy a card swiper along with
a poster board, but since most of their work was done
digitally (contrary to other Capstones that produced
physical projects), money was not an issue. For
managing information, the group often had to meet with
their customers to delineate exactly what they wanted, as
the group often disagreed on interpretations. Overall
though, they managed their information as they planned
it out; in other words they would approach a particular
customer need when they reached that step in planning.
When asked about the project holistically, Castle said
she was glad she had the experience as it cemented what
she wanted to do in the future, while offering her lessons
outside of the classroom. Only one group member had
ever had experience with implementing software for a
real-world application, so she said the group learned a
 Budzinski 10

variety of lessons in translating classroom knowledge how learning to program has affected his other classes.
into the real world. Regarding development, she said that Specifically, lines of code on a program do not directly
she learned lessons in both teamwork and customer translate to the difficulty of the code, and that it is
interaction, specifically that sometimes the customer always advisable to understand the logic and “why”
does not know exactly what they want. To highlight this behind a piece of computer code rather than being able
lesson, Castle gave the example of how the original to regurgitate commands and syntax. Through his
judging system was reliant on a color-coded system that studies, the author also felt confident enough to analyze
made the hand calculations easier to keep track of. When a Capstone project (in which he, its judges, and one of
this was translated to a digital system there was no the developers found to be a success) and comment on
longer a need for color association, the customer still the development process of the Capstone project.
wanted to have it, even though there was no need for it
anymore. For teamwork, she spoke to how she learned VIII. Acknowledgements
that sometimes it was better to mark out certain I would like to foremost thank Brad Sottile for his
“territory” that members would stick to and to let them several reviews of this document, along with his
run their course, instead of trying to collaborate on every guidance and wisdom regarding software development
single section of the project. Too much collaboration and how to conduct in depth and credible research. I
would have used up too much time, she said. would also like to thank Castle Leonard for meeting with
me to discus her Capstone project, and answer questions
Overall, the sponsor was exceptionally happy with the regarding the success of it.
final product evident by the $100 gift each group
member got for their hard work. Castle and another
group member were also asked to upkeep and improve
upon the software so that it could be utilized for future
Capstone fairs. Castle’s group also added on two other
features that were not required – data tracking and
reminders for judges – that were widely appreciated by
the sponsor. Based off of the sponsor’s reaction, and the
judges awarding second place to this Capstone, the
project was a success. Not only did the project exceed
expectations but is expected to continue working well in
the future.

VII. Conclusion
Although the V model is older than the Agile SDLC,
they each still have their merits and applications [13].
While the V model is better suited for more rigid
projects with a customer more inclined to only focus on
the final design, the Agile SDLC is better for changing
requirements, and is better for closely working with a
customer throughout the software development process.
Similarly, the Spiral SDLC implements a risk driven
approach that acts as a hybrid of sorts between the V
model and the Agile SDLC. While the Spiral SDLC does
involve customer interaction after each iteration, giving
it flexibility, it also invokes a more rigid style of
development in testing like the V model. All three
models, however, still require maintenance after release,
on the grounds that not all bugs may not be caught
before release, and because the software may need to be
altered to better fit new operating systems or platforms
[10]. Through his study of various SDLCs the author has
learned what SDLC he most closely relates to (the Agile
SDLC) and is confident enough in his own skills to give
tidbits of advice pertaining to programming and to share
 Budzinski 11

IX. References
[1] Regulwar, Ganesh B. et al. “Variations in V Model
for Software Development.” International Journal of
Advanced Research in Computer Science, vol. 1, no. 2,
2010, pp. 1–3.
[12] Patanakul, Peerasit, and Renee Rufo-McCarron.
“Transitioning to Agile Software Development: Lessons
Learned from a Government-Contracted Software.” The
Journal of High Technology Management Research, vol.
29, no. 2, Nov. 2018, pp. 181–192.

[2] Darwish, Mohamed, and Essam Shehab.
“Framework for Engineering Design Systems
Architectures Evaluation and Selection: Case
Study.” Procedia CIRP, vol. 60, 2017, pp. 128–132.,
doi:10.1016/j.procir.2017.01.058.
[3] Stecklein, Jonette M. “Error Cost Escalation Through
the Project Life Cycle.” NASA Technical Reports Server,
NASA, 19 June 2004,
ntrs.nasa.gov/search.jsp?R=20100036670.
[4] “White Box Testing.” Software Testing
Fundamentals, Software Testing Fundamentals, 3 Mar.
2018, softwaretestingfundamentals.com/white-box-
testing/.
[5] Misra, Subhas. “Agile Software Development
Practices: Evolution, Principles, and Criticisms.” The
International Journal of Quality & Reliability
Management; vol. 29, no. 9, 2012.
[6] “Agile Principles.” Template -
Kleo.wagenaardentistry.com,
kleo.wagenaardentistry.com/agile-principles/.
[13] Jacklin, Stephen A. “Survey of Verification and
Validation Techniques for Small Satellite Software
Development.” NASA, NASA, 19 May 2015,
ntrs.nasa.gov/search.jsp?R=20150010982.
[14] Boehm, B. W. “A Spiral Model of Software
Development and Enhancement.” Computer, vol. 21, no.
5, 1988, pp. 61–72., doi:10.1109/2.59.
[15] “Spiral.” Requirements in Engineering Projects, by
João M. Fernandes and Ricardo J. Machado, Springer,
2016, pp. 41–42.
(16) Mizell, Carolyn, et al. “Model for Simulating a
Spiral Software-Development Process.” NASA Technical
Reports Server, 1 July 2010,
ntrs.nasa.gov/search.jsp?R=20100024427.
[17] Nilsson, Andreas, and Timothy L
Wilson. Reflections on Barry W. Boehm's "A Spiral
Model of Software Development and Enhancement", vol.
5, no. 4, 2012, doi:10.1108/17538371211269031.

[7] “How Does the Agile Software Development Process

Work?” CLOUD NATIVE PYTHON, by MANISH
SETHI, PACKT Publishing Limited, 2017.

[8] Coleman, Gerry. “Agile Software

Development.” Software Quality Professional, vol. 19,
no. 1, Dec. 2016, pp. 23–29.

[9] Petersen, Kai, and Claes Wohlin. “The Effect of

Moving from a Plan-Driven to an Incremental Software
Development Approach with Agile Practices.” Empirical
Software Engineering, vol. 15, no. 6, 2010, pp. 654–
693., doi:10.1007/s10664-010-9136-6.

[10] Ogheneovo, Edward Erhieyovwe. “Software

Maintenance and Evolution: The Implication for
Software Development.” West African Journal of
Industrial and Academic Research, vol. 7, no. 1, June
2013, pp. 81–92.

[11] History: The Agile Manifesto, Ward Cunningham,

2001, agilemanifesto.org/principles.html.