2012-05-21

Software Development
Life Cycle (SDLC)
CDT413 – Advanced Software  Traditional SDLC’s

Engineering 


Iterative and incremental SDLC’s
Agile SDLC’s

Software Development Life Cycle

Slides by Per Branger, ABB

Many Life Cycle Models

 Traditional
Waterfall
Part 1


 V-model
 Iterative and Incremental
 Spiral Model
 Rational Unified Process (RUP)
 … Traditional SDLC’s
 Agile
 eXtreme Programming (XP)
 Scrum
 Crystal Clear
 SDLC
 …

Waterfall Model Waterfall Steps

 Sequential model of the
software life cycle
Can have iterations

backwards in the flow
 Royce 1970
 Requirements – defines needed information, function,
behavior, performance and interfaces
Design – data structures, software architecture,

interface representations, algorithmic details
 Implementation – source code, databases, user
documentation
 Test – unit testing, module testing, system testing,
beta-testing, detecting bugs
 Installation - deployment at customer site
 Maintenance – upgrading, support, service

1
 2012-05-21

Waterfall Strengths Waterfall Weakness

 Easy to understand, easy to use
 Provides structure for inexperienced staff
 Easy to identify milestones and deliverables
 Strives for early requirement stability
 Good for management control (plan, track,
resources)
 Works well when quality is more important than cost
or schedule
 All requirements must be known upfront
 Deliverables created for each phase are considered
frozen - inhibits flexibility
 Can give a false impression of progress
 Does not reflect the problem solving nature of
software development – iterations of phases
 Software is delivered late in the project, integration
as big-bang at the end
 Little opportunity for the customer to preview the
system (until it is too late ?!)

When to use Waterfall Model V-Model

 Requirements are well known  A variant of the
 Product definition is stable Waterfall model that
 Technology is understood emphasizes the
verification and
 New version of existing product validation of the
 Porting an existing product to a new platform product
 Testing of the product
is planned in parallel
with a corresponding
phase of development

V-Model Steps V-Model Strength

 Project and Requirement
Planning – allocate resources
 Product Requirement and
Specification Analysis –
complete specification of the
software system
 Architecture and high-level
design – defines how software
functions fulfill the design
 Detailed Design – develop
algorithms for each architectural
component
 Production, operation and  Emphasized planning for verification and validation of
maintenance – provide for
enhancements and corrections the product in early stages of the product
 System and acceptance testing development
– check the entire software  Each deliverable must be testable
system in its environment
 Integration and testing – check  Project management can track progress by
that modules interconnect milestones
correctly
 Unit testing – check that each
 Easy to understand and use
module acts as expected

• Coding – transform
algorithms into software

2
 2012-05-21

V-model Weaknesses When to use V-model

 Does not handle concurrent events
 Does not handle iterations or phases
 Does not easily handle dynamic changes in
requirements
 Can be difficult to identify risks early
 For systems requiring high reliability – e.g. safety
control applications
 When the requirements are known up-front
 When it can be modified to handle changing
requirements beyond analysis phase
 Solution and technology are known

Incremental SDLC Model

 Construct a partial
implementation of a total
Part 2 
system
Then slowly add increase
functionality
 The incremental model
prioritizes requirements from
the system and then
Iterative and Incremental SDLC’s implements them in groups
 Each subsequent release of
the system adds functions to
the previous release , until
all functionality has been
implemented

Incremental Model Strengths
 Develop high risk or major functions first
 Each release delivers an operational product
 Customer can response to each build
 Lowers initial delivery costs
 Initial product delivery is faster
 Customers gets important functionality early
 Requirements can be changed for following
increments
Incremental Model
Weaknesses
 Requires good planning and design
 Requires early definition of a complete and fully
functional system to allow for the definition of
increments
 Well defined module interfaces are required (some
will be developed long before others)
 Total cost of the complete system is not lower

3
 2012-05-21

When to use the Incremental

Model Spiral SLDC Model
 Risk, funding, schedule, program complexity, or need  Since end-user requirements
for an early realization of benefits are hard to obtain/define, it
is natural to develop
 Most of the requirements are known up-front, but
software in an experimental
are expected to evolve over time way
 A need to get basic functionality to the market early  Each cycle involves the same
 On project which have lengthy development sequence of steps as the
schedules waterfall process model
 On a project with new technology  Focus on reducing risk:
On each iteration identify
and solve the sub-problems
with the highest risk

Determine objectives, Evaluate alternatives, identify and

alternatives and constraints
 Objectives – functionality, performance,
hardware/software interfaces, critical success factors
etc.
 Alternatives – build, reuse, buy, sub-contract, etc.
 Constraints – cost, schedule, interface etc.
resolve risks
 Study alternatives relative to objectives and
constraints
 Identify risks (lack of experience, new technology,
tight schedules, poor process etc.)
 Resolve risks (evaluate if money could be lost by
continuing system development)

Define the experiment: Evaluate different solutions, resolve and reduce

Formulate the problem, identify alternative risks, make experiments (prototypes)
solutions, identify constraints

Develop next-level product Plan next phase

 Typical activities  Typical activities
 Create a design  Develop a project plan
 Review the design  Develop configuration management plan
 Develop code  Develop test plan
 Inspect code  Develop installation plan
 Test product

Verify the selected solution Plan for the next experiment

4
 2012-05-21

Spiral Model Strengths Spiral Model Weaknesses

 Provides an early indication of high risks, without
much cost
 Users “see” the system early because of rapid
prototyping tools
 Critical high-risk functions are developed first
 The design does not have to be perfect
 Users can be closely tied to all lifecycle steps
 Early and frequent feedback from users
 Cumulative costs assessed frequently
 Time spent for evaluating risks too large for small or
low-risk projects
 Time spent planning, resetting objectives, doing risk
analysis, and prototyping may be excessive
 The model is complex
 Risk assessment expertise is needed
 Spiral may continue indefinitely
 Developers must be reassigned during non-
development phase activities
 May be hard to define objective, verifiable milestones
that indicate readiness to proceed through the next
iteration

When to use Spiral Model Rational Unified Process (RUP)

 When creation of prototype is appropriate  An iterative software development process
 When costs and risk evaluation is important framework
intended to be tailored by development organizations and
 For medium to high-risks projects 
software project teams
 Long-term project commitment unwise because of  Developed by Rational Software (now IBM)
potential changes to economic priorities
 Roots in the spiral model and the Rational approach
 Users are unsure of their needs
 Requirements are complex
 New product line
 Significant changes are expected (research and
exploration)

RUP Key Principles RUP Disciplines

 Advocates software development that is:  Software Engineering Disciplines
 iterative and incremental;
 model-driven; and  Business Modeling
 architecture-centric  Requirements
 The “ABCDEF” Principles  Analysis and Design
 Adapt the process
 Balance stakeholder priorities  Implementation
 Collaborate across teams  Test
Demonstrate value iteratively

 Deployment
 Elevate the level of abstraction
 Focus continuously on quality

5
 2012-05-21

RUP Disciplines contd. RUP Phases and Milestones

 Supporting Disciplines  Inception phase
 Lifecycle objective milestone
 Configuration and Change Management  Elaboration phase
 Project Management  Use case model 80 % complete
 Environment  Architectural description and development plan complete
 Executable architecture that realizes architecturally significant use
 RUP defines workflows for each discipline cases
…
 Repeated in each iteration 

 Lifecycle architecture milestone

 Focus on different software engineering disciplines change
between different phases
 Construction phase
 Incremental realization of all use cases
 Initial operational capability milestone
 Transition phase
 Product moves from the development organization to the end user
 Product release milestone

RUP Lifecycle Model RUP Summary

 Planned iterations organized in phases
 Should ensure that the spiral terminates
 Often seen as “heavy” and expensive
 Defenders claim it is only a matter of achieving the right level of
formality by tailoring
 Must be tailored to each project by a RUP specialist
 Advocates the use of modern tools
 E.g. those marketed by IBM ;)

Agile Software Development (1)

 Lighter weight empirical approach for software

Part 3 development
 Lighter weight
 Less documentation
 Less formal process

Agile SDLC’s  Empirical

 No defined inputs and outputs from the process
 Expect the unexpected
 Exercises control through frequent inspection and adaptation

6
 2012-05-21

Agile Software Development (2) Agile Software Development (3)

 Core of the agile software development is the use of  Successful alternative to the traditional approaches
 Light but sufficient rules of project behavior when applied in:
 AND  Highly dynamic business environment
 Human- and communication oriented rules  Changing and/or unclear requirements
 Short time-to-market intervals
 Limitations
 Large complex projects
A. Cockburn
 Distributed development environment
 Contracts based on requirements
 Safety-critical systems

Agile Software Development (4)

 Several methodologies appeared in the late 1990’s

 Each method has a different combination of old ideas, new
ideas, and transmuted old ideas.
 Emphasizes:
 Close collaboration between the programmer team and business
experts
 Face-to-face communication
 Tight, self-organizing teams
 Frequent delivery of new deployable business value
 Find ways to craft the code and the team such that the inevitable
requirements churn is not a crisis.

Agile Principles (1) Agile Principles (2)

7
 2012-05-21

Agile Principles (3) Agile Principles (4)

Agile Processes (1) Agile Processes (2)

 Based on the assumptions that: Adaptation

 Requirements and their priorities change during the process Achieved by

 Design and implementation are interleaved Customer Feedback

 From a planning point of view, process activities are not Achieved by
predictable
Operational System
(part of)

 Q: How the unpredictability is managed? Achieved by

 A: By adaptability Software Increments

 The shorter the increments are, the more timely feedback is

received
 Customer involvement is essential

Examples of Agile Methods eXtreme Programming (XP)

 Adaptive Software Development (ASD)  Kent Beck, 1999
 Feature Driven Development (FDD)  Common sense practices to an extreme level
 Crystal Clear  Characteristics
 Dynamic Software Development Method (DSDM)  For small to medium sized teams developing software with vague
 Rapid Application Development (RAD) or rapidly changing requirements
 Scrum  Coding is the key activity throughout a software project
 eXtreme me Programming (XP)  Communication among teammates is done with code
 Lean  Life cycle and behavior of complex objects defined in test cases –
 Agile Modeling again in code (heavy emphasis on unit testing)
 Stories
 1-3 week iterations
 Do the simplest thing possible & You Aren’t Gonna Need It
(YAGNI) principle

8
 2012-05-21

XP is “extreme” because XP Core Values

 Commonsense practices taken to extreme levels
 If code reviews are good, review all the code all the time (pair
programming)
 If testing is good, everybody will test all the time
 If simplicity is good, keep the system in the simplest design that
supports its current functionality (simplest thing that works)
 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 and testing is important, build and integrate test
several times a day (continuous integration)
 If short iterations are good, make iterations really, really short
(hours rather than weeks)
 Communication
 Many problems can be traced back to communications
 Simplicity
 What is the simplest [design/code/test/etc.] that will work in this
situation?
 Focus on known needs of today instead of planning for hypothetical
future needs
 Feedback
 From the system through tests and continuously integrated code
 From customers through frequent iterations
 Courage
 Courage to openly say what you believe
 Courage to pursue design and code changes

XP Practices Practice 1: Whole Team / On-site customer

 1. Whole Team (On- site
customer)
 2. Small releases
 3. The Planning Game
 4. Simple design
 5. Pair programming
 6. Test Driven Development
 7. Customer Tests
 8. Refactoring (Design
Improvement)
 9. Collective code ownership
 10. Coding standard
 11.Continuous integration
 12. Metaphor
 13. Sustainable Pace
 Everyone sits together in one room
 A real customer sits with the development team
 May be a customer proxy when a real customer isn’t
available
 The customer
 Writes stories
 Business value functionalities
 Analogous to uses cases or requirements
 Writes acceptance tests

Practice 2: Small releases Practice 3: The Planning Game

 Plan only as far in advance as you can see  Release and Iteration Planning
 Adjust the plan as necessary  Customer is (main) part of the process
 Each release is as small as possible to actually deliver  Separation between technical and business decisions
something of value  Business decisions
 Typically 1-3 weeks  Scope
Priority
 Do not need to deploy 

 Release planning / Dates of releases

 Technical Decisions
 Estimates difficulty (efforts & risks)
 Detailed scheduling / Plan Iterations

9
 2012-05-21

Practice 4: Simple design Practice 5: Pair programming

 Design only for today  Two programmers at one computer

 If the future is uncertain, don’t code for it today  The driver
 Do not add infrastructure in this iteration for stories  has the keyboard
focuses on the tactical aspects of writing the code
coming in future iterations 

 Upcoming stories could be cancelled or lowered in priority
 You Aren’t Gonna Need It (YAGNI) principle
 Do the simplest thing that can possibly work
 Partner
 Watches the forest, not the trees
 Thinks about missing tests, integration issues, etc.
 Programming is far more than typing
 Pairs constantly shift

Practice 6: Test-Driven Development (TDD) Practice 7: Customer tests

 Write the unit tests first, then write the code  While programmers are programming:
 “Any program feature without an automated test  Customer writes an acceptance test for each story
simply doesn’t exist.”  Ideally, a tester is available to automate the test
—Kent Beck

Practice 8: Refactoring (Design Improvement) Practice 9-11

 Refactoring  Collective code ownership

 Simplifying or improving the code without changing its
behavior
 Automated unit tests ensure nothing breaks
 Allows programmers to refactor with confidence
 “Always leave the code cleaner than you found it.”
 Anyone can change any code
 In fact, you’re required to if you see a better way
 Coding standards
 Are necessary to support collective ownership and
refactoring
 Continuous integration
 Integration builds happen at least daily
 Ideally (and usually) continuously

10
 2012-05-21

Practice 12-13 Scrum

 Metaphor
 Establish a metaphor for the system
 Helps establish a common lexicon and vision
 Replaces “architecture” descriptions
 Sustainable Pace
 Teams work at a pace they can sustain for a long time
 Work overtime only when needed and effective
 The term for a strategy in the rugby game that means ‘getting
out-of play ball back into the game’ with team work
 Management methodology by Schwaber and Beedle, 2001
 Assumes that development process is unpredictable and
complex, requiring flexibility and responsiveness to change
 Characteristics:
 Self-organizing teams
 Product progresses in a series of month-long “sprints”
 Requirements are captured as items in a list of “product backlog”
 No specific engineering practices prescribed

Scrum - Sprint Scrum - Roles

 Scrum projects make progress in a series of “sprints”
 Development iterations  Scrum Master
 Represents management to the project
 Target duration is one month  Main job is to remove impediments
 +/- a week or two  Product Owner
 Product is designed, coded, and tested during the  Manage the vision
Manage the ROI
sprint


 Manage the release

 Team
 Self-organizing
 Cross-functional
 5-10 people

Scrum Life Cycle Product Backlog (1)

 A list of all desired work on the project
 Usually a combination of
 story-based work (“let user search and replace”)
 task-based work (“improve exception handling”)
 List is prioritized by the Product Owner
 Typically a Product Manager, Marketing, Customer, etc.

11
 2012-05-21

Product Backlog (2) Sprint Planning Meeting

 Contains:  Sprint Goal
 ID  High-priority functionality
 Name  Defined by the Product Owner
 Importance/ Priority  Scrum team takes the Sprint Goal and decides what
 Implementation / tasks are necessary
Development Efforts
 Description / How to demo  Team self-organizes around how they’ll meet the
 (Optional) Notes, Component, Sprint Goal
Requestor, Bug Tracking ID  Manager doesn’t assign tasks to individuals
 Managers don’t make decisions for the team
 Business oriented!  Sprint Backlog is created
 Plan & track activities

Sprint Backlog Sprint Backlog Example (1)

 Requirements for the Sprint / the Sprint Goal / are
frozen
 Changes
 Team adds new tasks whenever they need to in order to
meet the Sprint Goal
 Team can remove unnecessary tasks
 But: Sprint Backlog can only be updated by the team
 Estimates are updated whenever there’s new
information

Sprint Backlog Example (2) Sprint Backlog Example (3)

Post-its on a
whiteboard

12
 2012-05-21

Daily Scrum Meeting Burndown chart

 Parameters
 Daily
 15-minutes
 Stand-up
 Not for problem solving

 Three questions:
 1. What did you do yesterday
 2. What will you do today?
 3. What obstacles are in your way?

Sprint Backlog- Traceability Sprint Backlog - Traceability

Sprint Review Meeting Sprint Retrospective Meeting

 Team presents what it accomplished during the sprint  Retrospective of the sprint
 Typically takes the form of a demo of new features or  What has been good?
underlying architecture
 What can be improved?
 Informal  Improvement actions for next sprint
 2-hour preparation time rule
 High priority improvement actions are moved over to
 Participants
the next sprint
 Product Owner
 Scrum master
 Customers
 Management
 Other engineers

13