Software Life Cycle Models - 2

Yogesh Sharma, Ph.D., P.Eng.

Week 3, Lecture 2 Software Engineering

September 14, 2023 Management (ENSE 374)
Agenda
• Recap
• Agile Software Development Lifecycle Model
• Rapid Application Development (RAD) Model
• Scrum Model
• Summary
Learning Outcomes
After the lecture, students should be able to answer the following
questions
• Why the agile software development models are currently the
models of choice to develop software applications?
• What advantages the agile software development models have
over the waterfall based models?
• How the requirements and communication between the
stakeholders and development team are managed in agile
models?
Recap: Life Cycle of a Software
“Different stages over which a software evolves”

from an initial to fully developed software, finally to a stage

customer request including maintenance. of discard.

• Customers are usually not clear about all the required features and describes
vaguely what is needed.
• This stage where the customer feels a need for the software and forms rough
ideas about the required features is know as inception stage.
Recap: Software Development Life Cycle (SDLC)
Model
“A well-defined and ordered set of identifiable activities/stages for software
development.”
An SDLC graphically depicts the different phases through which a software
evolves. It is usually accompanied by a textual description of different activities
that need to carried out during each phase.

Software development organizations have realized that adherence to a suitable

life cycle model helps to produce good quality software and that helps
minimizing the chances of time and cost overruns.
Recap: Waterfall Model and its Extensions
• Waterfall model is a generic model that has been extended in many ways to
cater specific software development situations.
Recap: V-Model
It is a variant of waterfall model in which the model verification and validation activities
are carried out throughout the development life cycle.
• Chances of bugs in the work products
are considerably reduced.
• Along with development, test case
design and testing plan is developed.
• Actual testing is carried out by using the
developed test cases and plan during
validation phase.

This model is considered suitable for use in projects concerned with development of
safety-critical software systems require high reliability
Recap: Prototyping
Model
• This models suggests to build a working
prototype of the system, before development
of the actual software.
• This helps the customer to experiment with
the prototype to clear its requirements.
• Useful for specific types of projects
• GUI part of an application.
• When exact technical solutions are
unclear to the development team.
• Highly optimized and efficient software.

Prototype model is useful for the development of not only

GUI parts of a software, but also for a software project for
which certain technical issues are not clear to the
development team.
Recap: Incremental
Development Model
• After gathering the requirements, they are split
into several versions.
• The development team first develop the core
features of the system by using waterfall model.
• Customer feedback is obtained on the delivered
version.
• Obtained feedback is incorporated in the next
version.
• Each version of the software incorporates the
additional features over the previous version and
also refines the already delivered features.
Agile Development Models
Over the last two decades or so, projects using iterative waterfall-based life cycle
models are becoming rare due to the rapid shift in the characteristics of the software.
Two changes that are becoming noticeable are rapid shift from the development of rigid
software products to customized software and the increased emphasis of reuse.

Why waterfall model-based development process is becoming difficult to use in projects in recent times?

 According to Capres Jones, on the average 40% of the requirements arrive after the development has already begun.
Waterfall based models discourage to change the requirements after SRS document has been finalized.

 Customized applications/softwares (services) are trending which involves reusing most of the parts of existing
applications. Waterfall based models are not suitable for such applications.

 Waterfall based models prescribe minimal customer interactions after the requirements are specified. In fact, the
interactions are largely confined to the project initiation and completion stages.
Agile Development Models
• Was proposed in the mid-1990s to overcome the shortcoming of
waterfall model.
Major aim of agile moles is to facilitate quick project completion.

The distinguishing characteristics of the agile models is the frequent delivery of the
software increments to the customer.

Agile model is an umbrella term used to refer to a set of development processes. These
processes share certain common characteristics but do have certain subtle difference among
themselves.
Best suited
for small
projects
Agile model principles (published in agile manifesto 2011)
• Working software over comprehensive documentation.
• Frequent delivery of incremental versions of the software in intervals of few
weeks.
• Requirements changes are encouraged and efficiently incorporated.
• Face-to-face communication is preferable over the formal documents.
• Customer representatives are required to be a part of the development team, thus
facilitating close, daily co-operation between customer and developers.

Agile development projects usually deploy pair programming.

https://agilemanifesto.org/iso/en/principles.html
 Effectiveness of Face-to-face
at whiteboard
Communication Modes Face-to-face
conversation
Communication Effectiveness Video
conversation
Modeling
Phone Options
conversation

Videotape
Email
conversation

Audiotape
Documentation
Options
Paper

Cold Hot
Richness of Communication Channel
Copyright 2002-2005 Scott W. Ambler
Original Diagram Copyright 2002 Alistair Cockburn
Agile Software Requirements Management
High
{ Each iteration implement the highest-
Priority priority requirements

Each new requirement is

prioritized and added to
the stack

Requirements may be
reprioritized at any time

Requirements may be
removed at any time

Low
Priority
Requirements Copyright 2004 Scott W. Ambler
Rapid Application Development (RAD) Model
• This model is the amalgamation of both prototyping and evolution models.
• In this model
• First prototype is constructed using initial requirements and delivered to the customer.
• Then, the new features are added into the prototype, incrementally to accommodate new customer
requirements.
• Unlike prototype model, the prototype is not thrown away.
• Working of RAD
• Development takes place in a series of short cycles or iterations running for limited time called
timebox.
• During each timebox, a quick enhancement to a functionality of the prototype is performed.
• Customer evaluates the prototype and gives feedback on the enhancement.
• Development team always have a customer representative working with them.
• This model presses more on short-term planning and heavy reuse of existing code to
expedite the product development.
Suitability and Unsuitability of RAD Model
Suitability
• Customized software are developed by adapting an existing software and tailoring
requirements are obtained as customer feedback.
• Non-critical software, where focus is not to develop a performance optimal and reliable
software and scope of reusing is high.
• Highly constrained project schedule with limited development time. Hence, compromises
can be made in documentation and performance aspects.
Unsuitability
• Generic software with wide distribution where optimal performance and reliability are
imperative to sustain in a competitive market.
• Lack of similar products. If a company never developed similar software, it would hardly
be able to reuse much of existing artifacts.
• Monolithic software cannot have their components divided into parts that can be
incrementally developed and delivered.
Scrum Model
Project is divided into small parts of work that can be incrementally developed and
delivered.

Development time-boxes are called sprints

• Each sprint typically generally takes only a couple of weeks (sometime months
as well) to complete
• At the end of each sprint, stakeholder and project team members meet to assess
the progress.
• Feedback is obtained to make required changes or to add new functionality.
Scrum Model
• Requirements are captured as items in a list of product backlog.

Daily
Scrum

Sprint Sprint
planning review
Scrum
Sprint
Product backlog backlog

• Software is incrementally designed, coded and tested during the sprints.

• No changes are entertained during a sprint.
 Burn down charts are of three types
 Sprint Burn Down Chart (progress of the sprint)
Scrum Model: Framework  Release Burn Down Chart (progress of the release)
 Product Burn Down Chart (progress of the product)

Represent customer’s Developers

views and interests.

Second to the last event. Inspect the

How the just complete sprint
Project Manager outcome of the sprint and determine
went? More informal and a
future adaptations.
last event for a sprint.

Initiates a sprint by laying our the work Also know as stand-up meeting. Team
to be performed. Other people can be members provide updates on
invited to ask for advise. • What they worked on pervious day?
Used to represent work
• What they plan to do today?
List of all remaining done.
• What issues they encountered?
work for the project.
List of all remaining
work for a sprint.
Sample Product Backlog
 Sprint Burn-down Chart

• Depicts the total Sprint Backlog

hours remaining per day
• Shows the estimated amount of
time to complete.
• Ideally should burn down to zero
to the end of the Sprint
Release Burn-down Chart

• Will the release be done on right

time?

• How many more sprints?

Product Burn-down Chart
• Provides a “big picture” view of Actual
Burn down
project’s progress (all the Story
points

releases)
Expected
Burn down

Sprint
Summary
• Agile model emphasize face-to-face communication over written documents and
are suited to the development of small projects
• Unlike waterfall model, changes in the requirements are encouraged during the
development process.
• In RAD each increment is performed in much short duration to obtain the fast
prototype (or product) with new/improved feature. Whereas, the incremental
functionalities that are developed using evolutionary model are of larger
granularity.
• In Scrum model, the project is divided into small parts of work that can be
incrementally developed and delivered is small sprints.