Life Cycle Models

cont…

1
 Unified Process

11/23/2025
2
 Unified Process
• Developed Ivar Jacobson, Grady Booch
and James Rumbaugh
– Incremental and iterative

• Rational Unified Process (RUP) is version

tailored by Rational Software:
– Acquired by IBM in February 2003.

3
 Four Phases --- and iterative Development at
Every phase

• Inception Phase
• Elaboration Phase
• Construction Phase
• Transition Phase

4
 Unified Process Iterations in Phases
The duration of and iteration may vary from two
weeks or less.

Iterations Iterations Iterations Iterations

Inception Elaboration Construction Transition

5
 Unified process work products

Inception phase Elaboration phase Construction phase Transition phase

vision document use-case model design model SW increment
initial use-case model requirements SW components beta test reports
initial business case analysis model test plan user feedback
initial risk list preliminary model test procedure ...
project plan revised risk list test cases
prototype(s) preliminary manual user manual
... ... installation manual
...

6
 Structure of RUP Process
• Two dimensions.
• Horizontal axis:
– Represents time and shows the lifecycle
aspects of the process.
• Vertical axis:
– Represents core process workflows.
7
Two dimensions of Unified Process

8
 Inception activities
• Formulate scope of project
• Risk management, staffing, project plan
• Synthesize a candidate architecture.

9
• Initial requirements capture
• Cost Benefit Analysis
• Initial Risk Analysis Outcome of Inception
Phase
• Project scope definition
• Defining a candidate architecture
• Development of a disposable prototype
• Initial Use Case Model (10% - 20% complete)
• First pass Domain Model
10
 Spiral Model
• Proposed by Boehm in 1988.
• Each loop of the spiral represents a phase of
the software process:
– the innermost loop might be concerned with system
feasibility,
– the next loop with system requirements definition,
– the next one with system design, and so on.
• There are no fixed phases in this model, the
phases shown in the figure are just examples.
 Spiral Model (CONT.)‫‏‬

• The team must decide:

– how to structure the project into phases.
• Start work using some generic model:
– add extra phases
• for specific projects or when problems are
identified during a project.
• Each loop in the spiral is split into four
sectors (quadrants).
 Spiral Model ‫‏‬

Determine Identify &

Objectives Resolve Risks

Customer
Evaluation of Develop Next
Prototype Level of Product
 Objective Setting (First Quadrant)‫‏‬
• Identify objectives of the phase,
• Examine the risks associated with these
objectives.
–Risk:
• Any adverse circumstance that might
hamper successful completion of a
software project.
• Find alternate solutions possible.
 Risk Assessment and Reduction (Second
Quadrant)‫‏‬
• For each identified project risk,
–a detailed analysis is carried out.
• Steps are taken to reduce the risk.
• For example, if there is a risk that
requirements are inappropriate:
–A prototype system may be developed.
 Spiral Model (CONT.)‫‏‬

• Development and Validation (Third quadrant):

– develop and validate the next level of the
product.
• Review and Planning (Fourth quadrant):
– review the results achieved so far with the
customer and plan the next iteration around the
spiral.
• With each iteration around the spiral:
– progressively more complete version of the
software gets built.
• Subsumes all discussed models:
– a single loop spiral represents waterfall model.
– uses an evolutionary approach --
• iterations over the spiral are evolutionary levels.
– enables understanding and reacting to risks
during each iteration along the spiral.
– Uses: Spiral Model as a
Meta Model
• prototyping as a risk reduction mechanism
• retains the step-wise approach of the waterfall model.
 Agile Models

11/23/2025
18
 What is Agile Software Development?

• Agile: Easily moved, light, nimble,

active software processes
• How agility achieved?
– Fitting the process to the project
– Avoidance of things that waste time

19
 Agile Model
• To overcome the shortcomings of the waterfall
model of development.
– Proposed in mid-1990s
• The agile model was primarily designed:
– To help projects to adapt to change requests
• In the agile model:
– The requirements are decomposed into many small
incremental parts that can be developed over one to
four weeks each.

20
 Ideology: Agile Manifesto
• Individuals and interactions over
– process and tools
[Link]
• Working Software over
g

– comprehensive documentation
• Customer collaboration over
– contract negotiation
• Responding to change over
– following a plan

21
 Agile Methodologies
• XP
• Scrum
• Unified process
• Crystal
• DSDM
• Lean
22
 Agile Model: Principal Techniques
• User stories:
– Simpler than use cases.
• Metaphors:
– Based on user stories, developers propose a common vision
of what is required.
• Spike:
– Simple program to explore potential solutions.
• Refactor:
– Restructure code without affecting behavior, improve
efficiency, structure, etc.

23
• At a time, only one increment is planned,
developed, deployed at the customer site.
– No long-term plans are made.
• An iteration may not add significant
functionality,
AgileisModel:
– But still a new release Nitty
invariably madeGritty
at
the end of each iteration
– Delivered to the customer for regular use.

24
 Methodology
• Face-to-face communication favoured
over written documents.
• To facilitate face-to-face communication,
– Development team to share a single office
space.
– Team size is deliberately kept small (5-9
people)
– This makes the agile model most suited to the
development of small projects.
25
 Effectiveness of
Communication Modes

26
 Agile Model: Principles
• The primary measure of progress:
– Incremental release of working software
• Important principles behind agile model:
– Frequent delivery of versions --- once every
few weeks.
– Requirements change requests are easily
accommodated.
– Close cooperation between customers and
developers.
– Face-to-face communication among team
members. 27
• Travel light: Agile Documentation
– You need far less documentation than you think.
• Agile documents:
– Are concise
– Describe information that is less likely to change
– Describe “good things to know”
– Are sufficiently accurate, consistent, and detailed
• Valid reasons to document:
– Project stakeholders require it
– To define a contract model
– To support communication with an external group
– To think something through
28
Agile Software Requirements Management

29
 Adoption Detractors
• Sketchy definitions, make it possible to
have
– Inconsistent and diverse definitions
• High quality people skills required
• Short iterations inhibit long-term
perspective
• Higher risks due to feature creep:
– Harder to manage feature creep and customer
expectations
30
 Agile Model Shortcomings
• Derives agility through developing tacit
knowledge within the team, rather than
any formal document:
– Can be misinterpreted…
– External review difficult to get…
– When project is complete, and team
disperses, maintenance becomes difficult…

31
• Steps of Agile Model versus Waterfall Model
Waterfall model are a planned sequence:
– Requirements-capture, analysis, design, coding,
and testing .
• Progress is measured in terms of delivered
artefacts:
– Requirement specifications, design documents,
test plans, code reviews, etc.
• In contrast agile model sequences:
– Delivery of working versions of a product in
several increments. 32
Agile Model versus Iterative Waterfall Model

• As regards to similarity:
– We can say that Agile teams use
the waterfall model on a small
scale.

33
 Agile versus RAD Model
• Agile model does not recommend
developing prototypes:
– Systematic development of each
incremental feature is emphasized.
• In contrast:
– RAD is based on designing quick-and-dirty
prototypes, which are then refined into
production quality code.
34
 Agile versus exploratory programming
• Similarity:
– Frequent re-evaluation of plans,
– Emphasis on face-to-face communication,
– Relatively sparse use of documents.
• Agile teams, however, do follow defined and
disciplined processes and carry out rigorous
designs:
– This is in contrast to chaotic coding in
exploratory programming.
35
Extreme Programming
(XP)

36
 Extreme Programming Model
• Extreme programming (XP) was
proposed by Kent Beck in 1999.
• The methodology got its name from
the fact that:
– Recommends taking the best practices
to extreme levels.
– If something is good, why not do it all
the time. 37
 Taking Good Practices to Extreme
• If code review is good:
– Always review --- pair programming
• If testing is good:
– Continually write and execute test cases ---
test-driven development
• If incremental development is good:
– Come up with new increments every few days
• If simplicity is good:
– Create the simplest design that will support
only the currently required functionality.
38
 Taking to Extreme
• If design is good,
– everybody will design daily (refactoring)
• If architecture is important,
– everybody will work at defining and refining the
architecture (metaphor)
• If integration testing is important,
– build and integrate test several times a day
(continuous integration)

39
• Communication: 4 Values
– Enhance communication among team
members and with the customers.
• Simplicity:
– Build something simple that will work today
rather than something that takes time and yet
never used
– May not pay attention for tomorrow
• Feedback:
– System staying out of users is trouble waiting to
happen
• Courage:
– Don’t hesitate to discard code 40
 Best Practices
• Coding:
– without code it is not possible to have a working
system.
– Utmost attention needs to be placed on coding.
• Testing:
– Testing is the primary means for developing a fault-
free product.
• Listening:
– Careful listening to the customers is essential to
develop a good quality product.

41
 Best Practices
• Designing:
– Without proper design, a system
implementation becomes too complex
– The dependencies within the system become
too numerous to comprehend.
• Feedback:
– Feedback is important in learning customer
requirements.
42
 Extreme Programming Activities
• XP Planning
• Begins with the creation of “user stories”
• Agile team assesses each story and assigns a cost
• Stories are grouped to for a deliverable increment
• A commitment is made on delivery date
• XP Design
• Follows the KIS principle
• Encourage the use of CRC cards
• For difficult design problems, suggests the creation of
“spike solutions”—a design prototype
• Encourages “refactoring”—an iterative refinement of the
internal program design
43
 Extreme Programming Activities
• XP Coding
• Recommends the construction of unit test cases before
coding commences (test-driven development)
• Encourages “pair programming”

• XP Testing
• All unit tests are executed daily
• “Acceptance tests” are defined by the customer and
executed to assess customer visible functionalities

44
1. Planning – determine scope of the next release by
combining business priorities and technical estimates
Full List of XP Practices
2. Small releases – put a simple system into production,
then release new versions in very short cycles

3. Metaphor – all development is guided by a simple shared

story of how the whole system works

4. Simple design – system is to be designed as simple as

possible

5. Testing – programmers continuously write and execute

unit tests 45
 Full List of XP Practices
7. Refactoring – programmers continuously
restructure the system without changing its
behavior to remove duplication and simplify
8. Pair-programming -- all production code is
written with two programmers at one machine
9. Collective ownership – anyone can change any
code anywhere in the system at any time.
10. Continuous integration – integrate and build the
system many times a day – every time a task is
completed.
46
 Full List of XP Practices
11. 40-hour week – work no more than 40 hours a
week as a rule
12. On-site customer – a user is a part of the team
and available full-time to answer questions
13. Coding standards – programmers write all code
in accordance with rules emphasizing
communication through the code

47
Emphasizes Test-Driven Development (TDD)
• Based on user story develop test cases
• Implement a quick and dirty feature every
couple of days:
– Get customer feedback
– Alter if necessary
– Refactor
• Take up next feature
48
 Project Characteristics that Suggest Suitability
of Extreme Programming
• Projects involving new technology or
research projects.
– In this case, the requirements change rapidly
and unforeseen technical problems need to be
resolved.
• Small projects:
– These are easily developed using extreme
programming.

49
Thank You!!