Assignment 4: There is No Universal Software Process, Soh Wei Yu, 43036024

Introduction
Each of the software projects developed across the world are built with very different context,
circumstances and requirements. Each of these situations call for different software development
methodologies and come with different sets of challenges and issues. It is through these varying
problems, factors and considerations that different kinds of software processes have been
developed and evolved through the years in order to address these considerations. Software
developers have to weigh in all the factors in order to decide which is the software development
process that fits their project most.

This essay discusses what some of these processes in depth and how each processes addresses the
various considerations and concerns of software developers, taking into account some of the
examples of real life software projects. This will in turn show that there is not one universal software
process in which all software development will go through, but many different processes, each
suitable for certain contexts, with its pros and cons.

Factors Affecting Software Projects
The basic requirement of a software development process is that it has to cater to the necessities of
the project. Therefore, the suitable software development process for a project always depends on
the context, factors and considerations surrounding the software project. When this principle is
understood, it becomes very clear that the idea of a universal software process which fits all is in fact
a myth. (Clarke, 2012)

Before commencing on development, software development and process managers will need to
look into a list of factors before choosing the software process which they deem to be most suitable
given the particular context or situation surrounding the software project.

Some of the factors affecting software process and projects include:
- Clarity of initial requirements: whether the developers are able to get hold of very clearly
defined software requirements right at the beginning, which could influence the necessity
for agile methodologies
- Accurate initial estimation of costs and development time: certain methodologies are able to
allow more accurate estimation of costs and development time, however, usually it is
difficult to have a clear estimation with agile methodologies due to lack of clarity of
requirements at the initial phase
- Incorporation of requirements changes during the development process: another
consideration is whether it is important in ones context to be able to make changes to
adapt to new requirements in the middle of the development process. Different
methodologies provide different levels of flexibility or dynamicity
- Obtaining functional versions of the system during the development process: certain
methodologies are more able to allow users to interact with prototypes before the final
version, which lets users be in the know of any developments and offer valuable feedback
- Software criticality: different methodologies have different ways of ensuring that the project
is fully functional, including project management and testing
- Development costs: different methodologies have different financial requirements due to
factors such as varying development time and development cycles
- Length of the delivery time of the final system: different methodologies require different
amount of time to complete its tasks, as some methodologies may involve in large number
of activities which could lead to extended delivery time, while others may allow reduction of
requirements in order to meet deadlines
Assignment 4: There is No Universal Software Process, Soh Wei Yu, 43036024
- System complexity: certain methodologies are more suitable for large projects with complex
technicalities and project management involved, whereas some methodologies do not work
well with complex systems
- Communication between customers and developers: some methodologies only require
customers to provide requirements at an initial phase while some methodologies require
customers to be actively involved in the developmental process throughout the cycles.
- Size of the development team: some methodologies are suitable for small teams, some are
suitable for large teams
- Flexibility in timetable or setting of datelines: some methodologies require strict following of
time tables to the effect of reducing functionalities in order to meet datelines, while others
allow schedule to be adjusted
(Cristina Venera GEAMBAU, 2011)

When choosing the right software process for a project, one should carefully consider these various
considerations, and find a process that best suits the various factors and context one is working
with, or helps in addressing some of those factors and considerations.

Waterfall

Most software projects follow either one of the major software development methodologies: the
Waterfall methodology, or the Agile methodology, and most of the methodologies used today are
variants of the waterfall and agile methods. As such, the whole issue of waterfall vs agile is a very
common and hot subject of debate and discussion among software developers. (Ross, 2014) Based
on various sources, it can be observed that although waterfall is seen as a more traditional form of
software process in contrast to agile methodology, many software projects these days are still
developed with waterfall methodology for good reasons.
The waterfall methodology approaches software implementation systematically in linear stages, in
which the system is built through a cycle of predictable stages such as planning and analyzing
business and system requirements, designing IT solutions, building, and testing, and then the
process is repeated to refine the system until completion. (WATERFALL vs. AGILE METHODOLOGY,
2008) The benefits of this approach is its predictability, and a clear vision of the developmental
process being carefully planned out. Waterfall methodology tends to allow projects to be developed
rather quickly, allowing better estimation of timetable and budgets, and development processes can
be more secure due to planning. However, the waterfall method does not allow changes to
requirements to be adapted easily during its developmental process. This approach may be suitable
for projects that have very static, well-understood requirements that are not expected to evolve too
much during the development process. (Mikoluk, 2013)

There are many cases where waterfall is more suitable for development of certain projects than
using agile software process. For example, companies like Accenture, IBM, etc, that deals with
custom development and services, typically tend to use traditional waterfall approach. The reason
for this is because these companies tend to deliver projects based on contract. Or, these projects
may have a fixed scope for a fixed price. (Pincus, 2014) Waterfall methodology is more suitable for
this as waterfall software development hinges on detailed and fixed requirements right from the
beginning of the process. Also, in cases where software systems may be used in environments that
can endanger lives and has to be bug free, it is advisable to use software development process that
are similar to waterfall method instead of agile methodology. In such situations, a list of safety
standards must be followed so that ones actions can be defensible in the court of law, and all of the
Assignment 4: There is No Universal Software Process, Soh Wei Yu, 43036024
safety standards recommend following a developmental process similar to the waterfall method. It is
not easy to defend ones choice in applying an agile development process in a safety critical setting
may not be easily defensible or justifiable in a court if there is an incident. Furthermore, detailed
documentation and specifications must be produced, otherwise one cannot take credit for the
product later in a court of law. (McComb, 2014)

Another good point about waterfall methodology is that it allows for accurate estimation of costs
and development time right from the beginning of the project, because generally all the
requirements for a waterfall project are already known at an initial phase.

For all these reasons, software that is contract based, or require high degree of safety standards, or
may face scrutiny by a court of law, or require clearly stated documents and specifications would do
well to be implemented through waterfall method instead of agile method.
Examples of other forms of waterfall-based methodologies discussed in this paper includes V-Model.

Although the traditional waterfall methods suit many software projects even today, it has its down
sides and limitations. Waterfall-based methodologies lack the ability to deal with the dynamic nature
of software requirements, wherein requirements are hard to establish all at once. Due to the
dynamic nature of software development, many software projects may not have clearly delineated
requirements right at the beginning, which would be expected of projects undertaken with waterfall
software process. As such, agile methods offer an alternative solution.

Agile

In contrast to the waterfall method, the agile methodology approaches software implementation
without relying on predictable, planned or defined methods or steps, but instead the developers
regularly reevaluate and changes their priorities at the end of each cycle, which can happen weekly
or monthly. (WATERFALL vs. AGILE METHODOLOGY, 2008)

Due to its flexibility, this approach is more suitable for projects that have requirements which are
not completely understood yet, or which may be subject to changes throughout development.
Customers feedback and software testing occurring simultaneously with software development
means that problems with the software will not be discovered only in a late phase of software
development. Agile approaches are generally considered more suitable for projects with high degree
of uncertainty (Emam Hossain, 2009).

Although agile approaches are great for supporting the needs of dynamic software development, it
is also not without criticism. For example, criticisms against agile include that they are only suitable
for small software development teams, or that they may require premium software engineers.
(Clarke, 2012)

Variants of Agile methodologies discussed in this paper include Extreme Programming, Scrum and
Kanban.

V-Model
The V-model is a software development process that is considered to be an extension of the
waterfall model. It is in many ways similar to waterfall method as the process still deals with the
various steps like system requirements, coding, to testing, etc. However, instead of following a
strictly linear path such as the waterfall method, the V models process steps bend upwards after the
coding phase to form a typical V shape. The V model is designed for concurrent relationships
Assignment 4: There is No Universal Software Process, Soh Wei Yu, 43036024
between development steps and related testing phases. ( V-Model Software Development Life
Cycle Model, n.d.)

(Cornish, 2014)

V-model software development model was used in the development of projects like the OneSchool
(Cornish, 2014), which is an education software used by thousands of teachers and states schools
throughout Queensland. In the V-model software process, instead of proceeding through a series of
steps in a totally linear manner, each of the steps are co-related to an associated phase of testing.
Under such a software process, they undergo a V and V (validation and verification) process, where
written requirements are used for testing purposes. The validation part corresponds to the left hand
side of the V diagram, whereas the verification part corresponds to the right hand side. Validation
and testing are performed throughout the software process in order to ensure that the software
meets the user requirements. The test cases on the right hand side of the V diagram is populated as
they go along the trajectory on the left hand side. As such, they can start iteratively developing the
solution and exposing the functionalities to the users in an early phase so that the software does not
turn out to be surprising to the users at the end of the development process. Thus, verification and
validation is very important in the V model. This helps saving costs potentially amounting to millions
by correcting problems at an early stage of the development. (Rice, 2013)

The main benefits of the V-model over the traditional waterfall model is that because the various
forms of testing are done concurrently with the designing and coding of the system, the number of
defects that occur are less than in the normal waterfall methodology. This is because due to
concurrent testing and designing/coding, defects are fixed before proceeding onto the next stage.
(Satalkar, 2011) On the other hand, for the traditional waterfall model, the testing phase occurs at a
very late phase, therefore errors may proliferate incrementally throughout the development cycle as
they were not detected and remedied earlier.

Extreme Programming
Customers may not always have a very clear and precise picture of what they want on their software
during the first meeting. Furthermore, one may be developing a system whose functionality is
Assignment 4: There is No Universal Software Process, Soh Wei Yu, 43036024
subject to frequent changes. In such circumstances, only Extreme Programming is able to solve these
developmental issues. The aim of XP is to deliver functionalities required by users as and when they
are needed. (Wells, 1999)

Extreme programming (XP) is an agile software process that emphasizes responding to changing
customers requirements by following a principle of excellent application of programming
techniques, clear communication and teamwork. This process encourages communication and
customer feedback throughout its development. In fact, a representative of the future user must be
present throughout development to answer questions to the developers. It is characterized by short
development cycles, an incremental planning approach that evolves gradually, and flexible schedule
to implement functionalities and changes to requirements along the way of development. A
software life cycle of Extreme Programming has six phases: exploration, planning, iterations to
release, production, maintenance and death.


(Cristina Venera GEAMBAU, 2011)

Planning involves customers meeting with development team to create stories, which are user
requirements. Stories are then converted into iterations that deals with small portions of the
functionalities, which does not amount to much individually but when combined together becomes
the full package. This is followed by designing, which emphasizes simplicity, expressing each design
only once and not anticipating functionalities, using system metaphors or standards on naming,
allowing for all members of the project teams to contribute ideas, and creating solutions to mitigate
problems and concerns.

The coding phase involves developing code based on agreed standards, using a policy of collective
code ownership. Coding is done with pair programming, which involves developing code by two
programmers working collaboratively on a single machine in order to produce higher quality code at
similar or less cost. There is also a standard to strictly adhere to 40-hour workweeks with no
overtime, which ensures that developers work with good mental and physical wellness. There is also
frequent integration of code to the dedicate repository. After coding, there is testing with unit and
customer acceptance test to ensure the system is free from bugs and satisfies the customers
specifications and expectations. (Nayab, 2011) This is then followed by incremental releases.

As can be seen, there is emphasis throughout the process on teamwork between programmers,
Assignment 4: There is No Universal Software Process, Soh Wei Yu, 43036024
clear communication with users and application of programming techniques in order to achieve
optimal performance during the software development.

Automated tests are used to monitor progress and catch errors early in development. (Kent Beck,
2004) Working versions of developed system are frequently obtained, allowing customers to know
the progress of development and even stop the project if he is out of funds. Furthermore, due to
short development cycles, lower costs are required to adapt to changes in requirements. (Cristina
Venera GEAMBAU, 2011)

Apart from its main goal, XP projects also unanimously report higher levels of productivity in
comparison to other projects. A case study conducted with an industrial team from Sabre Airlines
Solution indicates that using XP practices result in better post-release quality than average, as well
as similar or better productivity than average. (Lucas Layman, 2006)

In a another case study during adoption of XP methodology for software development in an eleven-
week long course projects, it is found that the majority found XP process favorable, furthermore
they produced more functionalities with less work, response to changes in requirements were more
successful when applying XP methodology over Waterfall methodology. (Ghazy Assassa)

Although Extreme Programming is suitable for situations which call for heavy involvement and
collaboration between user and developer, there are also drawbacks to this approach. For example,
it may be difficult to come up with an initial estimate on the effort, development time and costs
required for the software project in Extreme Programming, as not all requirements are known at the
beginning of the project. Furthermore, Extreme Programming is not recommended for large projects
due to difficulty in communications when dealing with large groups, and complications that arise
due to complex interdependencies. Extreme Programming is meant for small development team of
between 2 to 10 people. (Cristina Venera GEAMBAU, 2011)

Scrum
Scrum is a form of agile software development process that is iterative and incremental. (What is
Agile? What is Scrum?, n.d.) The scrum methodology is generally designed for small teams, however,
some argue that Scrum can also be used for large and distributed teams. (Emam Hossain, 2009) It
consists of an initial phase whereby the team creates an architecture and selects a chief architect.
After which, a series of short development phases called sprints are carried out in order to produce
regular releases, and one sprint usually lasts between one to four weeks. Each sprint builds on
previous increments to deliver valuable functionalities within a fixed delivery timeframe. The team
may reduce deliverables during the sprint but cannot change the delivery date. Finally there is the
closure phase which usually means the finishing of product development. A Scrum master frequently
leads Scrum meetings to identify an initial backlog, which is a list of identified tasks to be completed
in the sprint. (Janoff, 2000)
Assignment 4: There is No Universal Software Process, Soh Wei Yu, 43036024

Case studies on scrum have shown that projects implementing scrum results in positive impacts. For
example, Intel Corporation have transitioned from a waterfall-based software process to scrum and
noted that it resulted in positive impacts in four ways: major reduction in cycle time, increased
performance and better ability to meet schedules and commitments, improved morale due to better
communication and job satisfaction, as well as increased transparency, adoption of formal
standards, and uncovering of various bugs and problems.

Most of the observed impacts were very positive, with the exception of a few issues that did not
went too well. For example, Product Owners are allowed to participate in the team to facilitate
communication, which worked quite well in some cases. However in other cases the POs
micromanaged the teams, preventing honest communication between team members, resulting in
secret meetings to discuss real organizational impediments outside the view of their PO. This
prevented self-organization. Another con is managing a huge backlog that can be overwhelming if it
is not managed well. Therefore, they segmented and differentiated the new sprints from the
accepted sprints, and implemented a freezer for user stories that they will only get to a few
sprints down the road. (Elwer, 2008)

Kanban

Although scrum has many benefits as listed above, it also has its own cons, which is why some
companies chose an alternative software process that is quite similar to scrum but improves on
some of the flaws of scrum. For example, a scrum project has regular releases every few weeks, and
those sprints are of fixed length. As such, in order to meet those imposed false datelines, developers
may rush for datelines which leads to a substandard product. This happens to be the biggest
criticism of scrum.

Kanban is able to solve this problem, as the length of the sprint is not fixed, and the team puts
together a best estimate to come up with the length of the next sprint. A Kanban software process
still consists of datelines, but makes datelines more realistic. (Escott, 2014) Furthermore, Kanban
does not have prescribed roles like scrum masters, and changes can be made at any time in contrast
to no changes being allowed in mid-sprint in scrum projects. (What is Kanban? Kanban Software
Tools , n.d.)

Assignment 4: There is No Universal Software Process, Soh Wei Yu, 43036024
Kanban is a software process that derived from Lean Manufacturing based on Just-in-Time
production, a process developed by Toyota in the 1950s. In a Kanban process, one first visualizes the
flow of work before implementing the plan. Unlike sprint approach, one does not need to spend
time at the beginning of every sprint to estimate and plan another batch of work, and although one
can still deploy completed code every few weeks, one simply move work through the system
without needing to arrange weeks of work at a time. Planning and estimating, designing, building
and testing can occur whenever an item becomes top of the priority in the backlog. Kanban
encourages members of team to take each item to its completion by allowing them to submit
whatever is ready to be delivered, therefore there is no over emphasis on meeting arbitrary
datelines. (Kanban and Agile , n.d.)

Hence, another factor that software developers consider is flexibility in its timetable or setting of
datelines, and avoiding the problems that arise from setting arbitrary datelines, and Kanban allows
such flexibility.

Conclusion

The suitability of a software development process to a project is highly dependent on the contextual
situation and considerations surrounding the software project. Different software projects have
different requirements and circumstances that favours different software processes. For example,
waterfall methodologies are more suitable for projects with static and well understood
requirements, or projects that are contract based, requires high safety standards or clearly written
documentation. Agile methodologies on the other hand require flexibility and ability to adapt to
changing requirements, thus is more suited to situations where requirements are not yet set in
stone. Many variants of the waterfall and agile methodologies have been developed to suit various
needs.

From all the different kinds of software process methodologies and the various examples, we can
conclude that there is indeed no universal software process meant for all and every software
projects. Instead, what we find is that every company and every software project utilizes different
kinds of software processes that suits their particular purposes and solve their problems or
addresses various factors and considerations they may have. We also find that no software process
is perfect or flawless that although each software process has its pros and benefits, each of them
also have different cons or flaws, and from these flaws comes further evolutions to the software
processes, resulting in newer and improved software methodologies. On the other hand, pros and
cons can be interchangeable, what may be a con for one context may not be an issue in another. In
the end it all depends on the users context, requirements and the various factors to be considered
for software development. Depending on the various considerations one may have, it is also possible
that one could mix and match aspects of the different software processes in order to suit ones
requirements.






Assignment 4: There is No Universal Software Process, Soh Wei Yu, 43036024
Bibliography
V-Model Software Development Life Cycle Model. (n.d.). Retrieved from http://qeworks.com/v-
model-software-development-life-cycle-model/
Clarke, P. (2012). The situational factors that affect the software development process: Towards a
comprehensive reference framework.
Cornish, C. (2014, March 20). Guest Lecture (Week 3 Lecture 3). Seddon D Building 82D, University of
Queensland, Brisbane.
Cristina Venera GEAMBAU, I. J. (2011). Influence Factors for the Choice of Software Development
Methodology.
Elwer, P. (2008). Agile Project Development at Intel: A Scrum Odyssey.
Emam Hossain, M. A.-y. (2009). Using Scrum in Global Software Development: A Systematic
Literature Review.
Escott, E. (2014, April 10). Guest Lecture (Week 6 Lecture 3), Software Methadologies. Seddon D
Building 82D, University of Queensland, Brisbane.
Ghazy Assassa, H. M. (n.d.). Extreme Programming: A Case Study in Software Engineering.
Janoff, L. R. (2000). The Scrum Software Development Process for Small Teams.
Kanban and Agile . (n.d.). Retrieved from http://leankit.com/kanban/kanban-agile/
Kent Beck, C. A. (2004). Extreme Programming Explained: Embrace Change.
Lucas Layman, L. W. (2006). Motivations and measurements in an agile case study.
McComb, D. T. (2014, March 27). Guest Lecture (Week 4 Lecture 3), Software Safety Engineering.
Seddon D Building 82D, University of Queensland, Brisbane.
Mikoluk, K. (2013, September 9). Agile Vs. Waterfall: Evaluating The Pros And Cons. Retrieved from
https://www.udemy.com/blog/agile-vs-waterfall/
Nayab, N. (2011). The Extreme Programming Life Cycle. Retrieved from
http://www.brighthubpm.com/methods-strategies/88996-the-extreme-programming-life-
cycle/
Pincus, S. (2014, April 3). Guest Lecture (Week 5 Lecture 3). Seddon D Building 82D, University of
Queensland, Brisbane.
Rice, R. (2013, October 9). Software Testing Training - V Model. Retrieved from
https://www.youtube.com/watch?v=zzPDHqR2qhU
Ross, D. K. (2014, March 13). Guest Lecture (Week 2 Lecture 3), Why didn't they test it? Seddon D
82D, University of Queensland, Brisbane.
Satalkar, B. (2011, June 28). Waterfall Model Vs. V Model. Retrieved from
http://www.buzzle.com/articles/waterfall-model-vs-v-model.html
WATERFALL vs. AGILE METHODOLOGY. (2008, January 4). Retrieved from
http://agileintro.wordpress.com/2008/01/04/waterfall-vs-agile-methodology/
Assignment 4: There is No Universal Software Process, Soh Wei Yu, 43036024
Wells, D. (1999). When should Extreme Programming be used? Retrieved from
http://www.extremeprogramming.org/when.html
What is Agile? What is Scrum? (n.d.). Retrieved from https://www.cprime.com/resources/what-is-
agile-what-is-scrum/
What is Kanban? Kanban Software Tools . (n.d.). Retrieved from http://www.versionone.com/what-
is-kanban/