Software Development Models

Software Engineering (SE-)

Instructor: Abd Ullah Khan

[email protected]
 A Generic Process Model

• Recall  A process is a collection of activities, actions, and tasks that are

performed when some work product is to be created.
• Each of these activities, actions, and tasks resides within a framework or
model that defines their relationship with the process and with one another.
A Generic Process Model
 Process flow - Linear
• A process flow describes how the framework activities and the actions and
tasks that occur within each framework activity are organized with respect
to sequence and time.
• A linear process flow executes each of the five framework activities in
sequence, beginning with communication and culminating with
deployment.
 Process flow - Iterative

• An iterative process flow repeats one or more of the activities before

proceeding to the next.
 Process flow - Evolutionary
• An evolutionary process flow executes the activities in a “circular” manner.
• Each circuit through the five activities leads to a more complete version of
the software.
 Process flow - Parallel
• A parallel process flow executes one or more activities in parallel with other
activities
• For example, modeling for one aspect of the software might be executed in parallel
with the construction of another aspect of the software.
 Traditional Software Models

• Prescriptive/Traditional process models define a predefined set of process

elements and a predictable process workflow.
• Prescriptive process models emphasize structure and order in software
development.
• We call them “prescriptive” because they prescribe a set of process
elements— framework activities, actions, tasks, work products, quality
assurance, and change control mechanisms for each project.
• Each process model also prescribes a process flow (also called a workflow)—
that is, how the process elements are related to one another.
 Traditional Software Models

• Waterfall model
• Prototyping model
• Incremental model
• Spiral model
 The Waterfall Model
• The waterfall model, sometimes called the linear sequential model, uses a
sequential approach to software development.
• It begins with customer specification of requirements and progresses
through planning, modeling, construction, deployment, and maintenance.
 The Waterfall Model

• It is used when
• The requirements for a problem are well understood
• Risk is low
• Workflows from communication through deployment in a reasonably linear fashion.
• Well-defined adaptations or enhancements to an existing system must be made (e.g.,
an adaptation to accounting software because it needs to accommodate changes).
 Problems with Waterfall Model
• Real projects rarely follow the sequential workflow that the model proposes.
• It is difficult for customers to state all requirements explicitly at the start of a project.
• It doesn’t support iterations (you cannot go back). So, changes can cause confusion.
• Better to accept changes from customers up to a specified time deadline before a project starts.
• After starting the project, no more changes can be accepted.

• The customer must have patience because a working version of the program(s) will not
be available until late in the project time span.
• This may cause the customer to lose interest in the project/software

• Major blunders may not be detected until the working program is reviewed.
• Software work is now fast-paced, and a never-ending stream of changes (to features,
functions, and information content) is often required, which makes this model
inapplicable.
 Coping with Change

• Change is inevitable in all large software projects.

• The system requirements change as businesses respond to external
pressures, competition, and changing management priorities.
• As new technologies become available, new approaches to design and
implementation become possible.
• Therefore, whatever software process model is used, it is essential that it
can accommodate changes to the software being developed.
 Coping with Change
• Change adds to the costs of software development because it usually means
that work that has been completed has to be redone. This is called rework.
• Two related approaches may be used to reduce the costs of rework:
• Change anticipation, where the software process includes activities that can anticipate or
predict possible changes before significant rework is required.
• For example, a prototype system may be developed to show some key features of the system to
customers.
• They can experiment with the prototype and refine their requirements before committing to high
software production costs.
• Change tolerance, where the process and software are designed so that changes can be
easily made to the system.
• This normally involves some form of incremental development.
• Proposed changes may be implemented in increments that have not yet been developed.
 Coping with Change
• Two ways of coping with change and changing system requirements:
• System prototyping, where a version of the system or part of the system is developed
quickly to check the customer’s requirements and the feasibility of design decisions.
• This is a method of change anticipation as it allows users to experiment with the system
before delivery and refine their requirements. The number of requirements-changing
demands made after delivery is reduced.
• Incremental delivery, where system increments are delivered to the customer for
comment and experimentation.
• This supports both change avoidance and change tolerance.
• It avoids the premature commitment to requirements for the whole system and allows
changes to be incorporated into later increments at a relatively low cost.
 Prototyping Model (Evolutionary Process Model)

• The prototyping paradigm assists you and other stakeholders in better

understand what is to be built when requirements are fuzzy.
• When a customer cannot identify detailed requirements for functions and features.
• Or the developer may be unsure of the efficiency of an algorithm, the adaptability of an
operating system, or the form that human-machine interaction should take.

• In these, and many other situations, a prototyping paradigm may offer the
best approach.
Prototyping Model
 Prototyping Model
• The prototype serves as a mechanism for identifying software requirements.
• The prototyping model begins with communication with other stakeholders
• to define the objectives and requirements for the software.

• A prototyping iteration is planned quickly, and quick design or modeling occurs.

• A quick design focuses on representing those aspects of the software that will be visible
to end users (e.g., human interface layout or output display formats).
• The quick design leads to the construction of a prototype.

• The prototype is deployed and evaluated by stakeholders

• who provide feedback to further refine requirements.

• Iteration occurs as the prototype is modified to satisfy the needs of various

stakeholders
• The iterations enable the development team to better understand what needs to be done.
 Problems with Prototyping Model

• Prototyping can be problematic for the following reasons:

• Stakeholders see what appears to be a working version of the software.
• They may be unaware that the prototype architecture (program structure) is also evolving.
• This means that the developers may not have considered the overall software quality or
long-term maintainability.
• As a software engineer, you may be tempted to make implementation compromises to
get a prototype working quickly.
• If you are not careful, these less-than-ideal choices have now become an integral part of the
evolving system.
 Incremental Model (Evolutionary Process Model)

• The product is partitioned into smaller pieces which are then built and
delivered to the client in increments at regular intervals.
• Since each piece is much smaller than the whole, it can be built and sent to
the client quickly.
• This results in quick feedback from the client, and any requirement-related
errors or changes can be incorporated at a much lesser cost.
• It is, therefore, less stressful than the waterfall model.
Incremental Model
 Incremental Model

• When to use Incremental models?

• Requirements of the system are clearly understood
• When demand for an early release of a product arises
• When the software engineering team is not very well-skilled or trained
• When high-risk features and goals are involved
 Advantages and Disadvantages of Incremental Model
•Advantages
• The software will be generated quickly during the software life cycle
• It is flexible and less expensive to change requirements and scope
• Throughout the development stages, changes can be done
• This model is less costly compared to others
• A customer can respond to each building
• Errors are easily identifiable

•Disadvantages
• It may require good planning and designing
• Problems might arise due to system architecture as not all requirements are collected for the
entire software lifecycle
• Each iteration phase may be rigid and not overlap each other
• Rectifying a problem in one unit requires correction in all the units, which consumes a lot of
time
 Spiral Model (Evolutionary Process Model)
• Software evolves over time.
• Business and product requirements often change as development proceeds,
making a straight-line path to product development unrealistic.
• Tight market deadlines may make the completion of a comprehensive
software product impossible.
• It might be possible to create a limited version of a product to meet
competitive or business pressure and release a refined version once all
system features are better understood.
• In a situation like this, you need a process model that has been explicitly
designed to accommodate a product that grows and changes.
 Spiral Model
• The spiral model is an evolutionary software process model that couples
the iterative nature of prototyping with the systematic aspects of the
waterfall model.
• It provides the potential for rapid development of increasingly more
complete versions of a software.
• Using the spiral model, a software is developed in a series of evolutionary
releases.
• During early iterations, the release might be a model or prototype. During
later iterations, increasingly more complete versions of the engineered
system are produced.
 Spiral Model

• Activities in this model are represented by a

circuit around the spiral in a clockwise
direction, beginning at the center.
• Risk is considered as each revolution is
made.
• Anchor point milestones—a combination of
work products and conditions that are
attained along the path of the spiral—are
noted for each evolutionary pass.
 Spiral Model
• The first circuit around the spiral might result in the development of a
product specification or a prototype
• The subsequent spirals may lead to more sophisticated versions of the software.
• The last spiral can use the waterfall model.

• Each pass through the planning region results in adjustments to the project
plan.
• Cost and schedule are adjusted based on feedback derived from the customer after
delivery.
• In addition, the project manager adjusts the planned number of iterations required to
complete the software
 Spiral Model
• This model is used when
• A large software project is developed
• When requirements are not well-understood and risks hare high
• Operates as a risk-driven model; a go/no-go decision is made after each
complete spiral in order to react to risks.
• Requires considerable expertise in risk management
 Pitfalls in Spiral Model
• It uses prototyping as a risk reduction mechanism.
• The spiral model demands a direct consideration of technical risks at all
stages of the project and, if properly applied, should reduce risks before
they become problematic.
• But like other paradigms, the spiral model is not a panacea.
• It may be difficult to convince customers (particularly in contract situations)
that the evolutionary approach is controllable.
• It demands considerable risk assessment expertise, and its success relies on
this expertise. If a major risk is not uncovered and managed, problems will
undoubtedly occur.
 Thanks
.