Name: Qasim Ali

Roll No: 8954

Semester: 3rd
Section: B.S Software Engineering Eve(A)

Submitted To:

Dr.Khurram
 Software Process Model

1. Introduction:
The process of creating software is similar to the process of making any other products that involves
many components and factors. Only when the components are well designed and fit together, the
product can have a better chance to be successful. Software processes, however, differ quite
significantly from product processes in other industries. Product processes in other industries (auto
industry, for example) are often stable, have long-term product design and development strategies with
anticipated customer expectations that do not change frequently in any significant way. Software
processes, however, are more likely conducted under dynamically changing environments, from product
requirements and functionality, time and cost constraints, to users’ satisfaction. Methodologies to
address the problems specific to software development started in 1960’s but only quite primitive at the
beginning and became somewhat mature in the last 30 years. The evolution of software development
methodologies can be roughly divided into two periods with traditional or plan-driven models in the first
period and agile models in the second. As agile models are getting more and more acceptance,
traditional models continue to be modified, improved, and used today. All the software process models
are based on the concept of software development life cycle (SDLC), but traditional models interpret
SDLC in a much narrow sense. They divides the “life” of software development process into well defined
Phases and specifies the activities in each phase and the process flows between the phases. The most
influential traditional model is the waterfall model proposed by Winston Royce in 1970 [25]. Many
variations of the waterfall model were proposed during that period, such as spiral model [6], V-shaped
model [12] and W model [13]. There are clear limitations and weaknesses of traditional models
particularly for complex and large software projects, as reported in many publications in the literature.
Agile methodologies started gaining momentum in early 2000’s, particularly when the Agile Alliance
published The Agile Manifesto in 2001 [1].

2.Traditional Software Process Models:

The process of creating a software contains these essential building blocks regardless of what model is
used: Functional and non-functional requirements, time and cost constraints, design of the software
product, implementation, testing, delivery, and maintenance. Software development models differ in
the ways these building blocks are structured and how they are related in the process. Traditional
models are basically follow the idea of process flow between these components (called stages or
phases), like a finite state machine [35], to form what is called the software life cycle (SLC). The most
basic and influential SLC development model is the waterfall model. There are many traditional models,
but we only briefly discuss the three classical and representative models in this section: waterfall, V-
shaped, and spiral.

2.1 Waterfall model:

Winston Royce proposed waterfall model in 1970 [25]. In this model, the components in the software
process are arranged as a linear sequence, with the flow from the first component “down” to the last
one, like waterfalls, as depicted in Fig. 1. The solid-arrow flow is the basic model and the dashed-arrow
flow indicates iterative feedback.

The waterfall model has been perceived as an one-way flow of control in the software development
process, where the process is denoted S = (s1; s2; ; sm), in which stage sk starts only after stage sk 1 is
complete. All the system and software requirements must be well specified at the beginning before
analysis and design of the software product can begin, and cannot be changed during the entire process.
In fact, the original waterfall model described in [25] had feedback loops as well as break-downs of
these stages. Nevertheless, the one-way linear flow of the development process has been considered
the main characteristics of the waterfall model. In this model, everything is well planned, the software
product blueprint (design) strictly reflects the analysis of the requirements, and the blueprint is
vigorously followed during implementation and testing to ensure the requirements are met. The 7-stage
waterfall in the original model has been massaged and adjusted into 5-stage, 6-stage, revised 7-stage
and even more-stage waterfalls. Most noticeable revisions include combination of system requirements
and and software requirements in to a single “Requirements” stage, and the addition of a “Maintenance
and Support” stage at the end of the process. These revisions share the common strengths and
weaknesses. The primary strength of the waterfall model is the predictability of the product quality
because “things are precise as planned.” The main drawback of this model is its inflexibility of adapting
changes while changes are the game in software development. More often than not, even the
customers are not sure about their needs at the beginning, hence the system and software
requirements would change that have ripple effect on the later stages of the process. Because of this
inflexibility, risk (project may fail) remains high throughout most of the development cycle until at the
later stages (coding and integration) when problems are uncovered but it is “too late” while the
functionality of the project is expected to rise, as illustrated in Fig. [2] given in [3]. This is also the main
criticism of the waterfall model that led to the rise of agile models.

2.2 Spiral model Barry Boehm introduced the spiral model in 1988 that was applied to the TRW
Software Productivity System [6]. The model takes the waterfall stages into repetitive loops with the
prototypes of the software design refined and improved in each loop, like the process going into a
spiral, as shown in Fig. 3. A distinctive feature of the spiral model is the added risk analysis into the
loops. Here risk means the conditions and events that may make it harder for the development
team to achieve its goals. In each iteration, the prototype of the project is evaluated and risk is
assessed for the next iteration in the process. Sometimes the spiral model is categorized as a risk-
driven model. The product prototype is iteratively updated (and hopefully improved) as the spiral
spins outward and ends up with an operational prototype for implementation. A more detailed
description
 Spiral model with enhancement was published in 2014 by the originator of the mode [7], that provided
principles and guidelines of using spiral model for software projects to be successful. The spiral model
provides some flexibility to the process, such as allowing additional functionality to be added at the later
stage of the development. However, the model is not widely used mainly because it is quite costly to use
that requires skilled risk assessment professionals throughout the process and the model does not work
well for small projects.

1.1 V-shaped model:

The “Vee” model was introduced by Kevin Forsberg and Harold Mooz in 1991 [12] that followed the
basic outlines of the “Vee” charts developed by NASA. The model emphasizes on integration and
verification (testing). Just like the waterfall model, the software development life cycle is also a
sequential process, but envisions the cycle as a V. The left side consists of the earlier phases of the cycle
(requirement, specification, analysis, design) and descents just like in the waterfall model, while later
phases (integration and verification) of the project cycle ascent on the right side of the V. In this model,
detailed work can start early and even in parallel. For example, testing procedures can be developed
early in the life cycle before coding is done. A V-shaped model is shown in Fig. 4 that is from [11] but
with the dashed lines added to indicate the relationships of the phases in the planning. Researchers
have proposed and developed some extensions of the V-shaped models, such as the W model [13, 29].
In W model, a second V is added to have the two V’s intertwining together to allow parallel execution of
the phases of the project cycle. The second V emphasizes on testing that is integrated into the model. A
W model for component-based development (CBD) was proposed by Kung-Kiu Lau et al. in 2011 [16]. In
their model, one V is defined for the component development process and the other V is defined for
system development process, and the two processes are conjoined into a single CBD process.
2. Agile software process model:
The waterfall model and other traditional models were considered too rigid in practice. People
started to realize that more flexible and practical models are needed. Quite a few software
professionals put into practice in the 1990’s the idea of Agile. In 2001, 17 agile practitioners
gathered in Utah trying to find common goals. The Agile Software Development Alliance was formed
at the meeting and all the participants signed the Manifesto for Agile Software Development [1] that
has become the guiding principles for agile development models. At the core, “Agile Methodologies
is about the mushy stuff of values and culture” to deliver good products to the customers in an
environment that the acts of people are most important [14]. In this section, we review the basic
characteristics of agile development and four agile models: Extreme Programming (XP), Scrum, Lean,
and Kanban.

3.1. Agile Characteristics and Life Cycle:

There are long and short definitions for agile development, and all share these points [21]:

• Requirements are assumed to change.

• Systems evolve during a series of short iterations.

• Customers participate during each iteration.

• Documentation is developed only as needed.

The key characteristics of agile can be summarized into three phrases: adapting change, rapid
delivery, constant user involvement. The process in the agile life cycle is illustrated in Fig. 5 adapted
from [20]. The product goes through a series of short iterations (Development i; i = one; n) with new
functionality added in each iteration. During each iteration, design, coding, integration and testing
are carried out to achieve incremental improvements. The client then releases the product for
approval. If not accepted (client may request changes, for example), the development team will
incorporate changes, adjust and track system features, and start the next cycle. The system is
continuously visible to all stakeholders who are closely participating in the process for the entire
development period. Agile is now the dominating method used today for software development.
3.2. Extreme programming (XP):
Extreme programming (XP) model was created by Kent Beck in 1996 when he was working on the
Chrysler Corp.’s payroll application. The methodology was further defined and explained in a book [4].
Extreme programming is a “lightweight discipline of software development” methodology that
emphasizes on customer satisfaction by delivering software as the customer needs it rather than
delivering the software far in the future that satisfies all the requirements planned in advance. XP model
recognizes five values: communication, simplicity, feedback, courage, and respect. A set of rules was
established as the guide for software development using XP to reflect these values. Those rules [36] that
are the most critical are summarized in Table 1

3.3. Scrum Hirotaka Takeuchi and Ikujiro Monika first used the term Scrum in 1986 to explain the need
for new approaches for product development [32]. They argued that a fast and flexible process is
needed rather than sticking with the old sequential approach to developing new products, as they were
calling for “stop running the relay race and take up rugby.” Scrum as a software development
methodology was first introduced in 1995 by Ken Schwaber [27]. According to [27], Scrum is a loose set
of activities going through an unpredictable system development process. Being flexible to respond to
the unpredictability and incorporate controls and risk management can significantly increase the
probability of system success. Scrum is a framework within which various processes and techniques can
be employed [28]. In the Scrum framework, three key roles (product owner, development team, Scrum
master) closely work together to go through the process. The life cycle of the project consists of these
steps: 1) Product backlog: documents about all the features to be developed with priority order. 2)
Sprint backlog: list of things the team thinks can be done in the current sprint. 3) Sprint: project is
divided into a series of 1-to-4-week periods (sprints), with design, coding, testing, and documentation in
each sprint. No changes are allowed mid-sprint. 4) Scrum meeting: 15-minute daily meeting to review
what was done yesterday, brainstorm what to do today and what are the blocking factors.