UNIT 1

DEVELOPMENT LIFE CYCLE

PROCESSES
SDLC MODEL
A framework that describes the activities performed at each stage
of a software development project.

WATERFALL MODEL
Requirements defines needed
information, function, behavior,
performance and interfaces.
Design data structures, software
architecture, interface
representations, algorithmic details.
Implementation source code,
database, user documentation,
testing.
WATERFALL STRENGTHS
Easy to understand, easy to use
Provides structure to inexperienced staff
Milestones are well understood
Sets requirements stability
Good for management control (plan, staff, track)
Works well when quality is more important than cost or
schedule




WATERFALL DEFICIENCIES
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 problem-solving nature of software
development iterations of phases
Integration is one big bang at the end
Little opportunity for customer to preview the system (until
it may be too late)

V-SHAPED SDLC MODEL
A variant of the Waterfall that
emphasizes the verification
and validation of the product.
Testing of the product is
planned in parallel with a
corresponding phase of
development

Project and Requirements Planning
allocate resources

Product Requirements and Specification
Analysis complete specification of the
software system

Architecture or High-Level Design
defines how software functions fulfill the
design

Detailed Design develop algorithms
for each architectural component


Production, operation and maintenance
provide for enhancement and
corrections
System and acceptance testing check
the entire software system in its
environment


Integration and Testing check that
modules interconnect correctly

Unit testing check that each module
acts as expected

Coding transform algorithms into
software

V-SHAPED STEPS
V-SHAPED STRENGTHS
Emphasize planning for verification and validation of the product in early stages of
product development
Each deliverable must be testable
Project management can track progress by milestones
Easy to use
V-SHAPED WEAKNESSES
Does not easily handle concurrent events
Does not handle iterations or phases
Does not easily handle dynamic changes in requirements
Does not contain risk analysis activities
RAPID APPLICATION MODEL (RAD)
Requirements planning phase (a workshop utilizing
structured discussion of business problems)
User description phase automated tools capture
information from users
Construction phase productivity tools, such as code
generators, screen generators, etc. inside a time-box.
(Do until done)
Cutover phase -- installation of the system, user
acceptance testing and user training
RAD STRENGTHS
Reduced cycle time and improved productivity with
fewer people means lower costs
Time-box approach mitigates cost and schedule risk
Customer involved throughout the complete cycle
minimizes risk of not achieving customer satisfaction
and business needs
Focus moves from documentation to code
(WYSIWYG).
Uses modeling concepts to capture information about
business, data, and processes.

RAD WEAKNESSES
Accelerated development process must give quick
responses to the user
Risk of never achieving closure
Hard to use with legacy systems
Requires a system that can be modularized
Developers and customers must be committed to rapid-
fire activities in an abbreviated time frame.

INCREMENTAL SDLC MODEL
Construct a partial implementation
of a total system
Then slowly add increased
functionality
The incremental model prioritizes
requirements of the system and then
implements them in groups.
Each subsequent release of the
system adds function to the
previous release, until all designed
functionality has been implemented.


INCREMENTAL MODEL STRENGTHS
Develop high-risk or major functions first
Each release delivers an operational product
Customer can respond to each build
Uses divide and conquer breakdown of tasks
Lowers initial delivery cost
Initial product delivery is faster
Customers get important functionality early
Risk of changing requirements is reduced

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

SPIRAL SDLC MODEL
Adds risk analysis, and
4gl RAD prototyping to
the waterfall model
Each cycle involves the
same sequence of steps
as the waterfall process
model






SPIRAL QUADRANT
DETERMINE OBJECTIVES, ALTERNATIVES AND CONSTRAINTS

Objectives: functionality, performance, hardware/software
interface, critical success factors, etc.
Alternatives: build, reuse, buy, sub-contract, etc.
Constraints: cost, schedule, interface, etc.

SPIRAL QUADRANT
EVALUATE ALTERNATIVES, IDENTIFY AND 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
SPIRAL QUADRANT
DEVELOP NEXT-LEVEL PRODUCT
Typical activites:
Create a design
Review design
Develop code
Inspect code
Test product

SPIRAL QUADRANT
PLAN NEXT PHASE
Typical activities
Develop project plan
Develop configuration management plan
Develop a test plan
Develop an installation plan
SPIRAL MODEL STRENGTHS
Provides early indication of insurmountable 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
SPIRAL MODEL WEAKNESSES
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 required
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
PERSONAL SOFTWARE PROCESS (PSP)
The personal software process (psp) is a structured set of
process descriptions, measurements and methods that can help
engineers improve their personal performance.
The goal of the personal software process is to discipline
software process.
PERSONAL SOFTWARE PROCESS (PSP)
Planning. This activity isolates requirements and develops both size
and resource estimates. In addition, a defect estimate (the number of
defects projected for the work) is made. All metrics are recorded on
worksheets or templates. Finally, development tasks are identified and a
project schedule is created.
High-level design. External specifications for each component to be
constructed are developed and a component design is created.
Prototypes are built when uncertainty exists. All issues are recorded and
tracked.
High-level design review. Formal verification methods (Chapter 21) are
applied to uncover errors in the design. Metrics are maintained for all
important tasks and work results.
Development. The component level design is refined and reviewed.
Code is generated, reviewed, compiled, and tested. Metrics are
maintained for all important tasks and work results.
Postmortem. Using the measures and metrics collected (this is a
substantial amount of data that should be analyzed statistically), the
effectiveness of the process is determined. Measures and metrics should
provide guidance for modifying the process to improve its effectiveness.
TEAM SOFTWARE PROCESS (TSP)
Build self-directed teams that plan and track their work,
establish goals, and own their processes and plans.
These can be pure software teams or integrated product
teams (IPT) of three to about 20 engineers.
Show managers how to coach and motivate their teams
and how to help them sustain peak performance.
Accelerate software process improvement by making
CMM Level 5 behavior normal and expected.
The Capability Maturity Model (CMM), a measure of the
effectiveness of a software process, is discussed in Chapter
30.
Provide improvement guidance to high-maturity
organizations.
Facilitate university teaching of industrial -grade team
skills.
UNIFIED PROCESS MODELS
Unified Processa use-case driven, architecture-centric, iterative and incremental
software process closely aligned with the Unified Modeling Language (UML)
THE UNIFIED PROCESS (UP)
soft ware increment
Release
Incept ion
Elaborat ion
const ruct ion
t ransit ion
product ion
inception
elaboration
UP PHASES
Incept ion Elaborat ion Const ruct ion Transit ion Product ion
UP Phases
Workflows
Requirements
Analysis
Design
Implementation
Test
Iterations #1 #2 #n-1 #n
Support
UP WORK PRODUCTS
Incept ion phase
Elaborat ion phase
Const ruct ion phase
Transit ion phase
Vision document
Init ial use-case model
Init ial project glossary
Init ial business case
Init ial risk assessment .
Project plan,
phases and it erat ions.
Business model,
if necessary.
One or more prot ot ypes
I nc e pt i o
n
Use-case model
Supplement ary requirement s
including non-f unct ional
Analysis model
Sof t ware archit ect ure
Descript ion.
Execut able archit ect ural
prot ot ype.
Preliminary design model
Revised risk list
Project plan including
it erat ion plan
adapt ed workf lows
milest ones
t echnical work product s
Preliminary user manual
Design model
Sof t ware component s
Int egrat ed sof t ware
increment
Test plan and procedure
Test cases
Support document at ion
user manuals
inst allat ion manuals
descript ion of current
increment
Delivered sof t ware increment
Bet a t est report s
General user f eedback
WHAT IS AGILITY?
Effective (rapid and adaptive) response to change
Effective communication among all stakeholders
Drawing the customer onto the team
Organizing a team so that it is in control of the work performed
Yielding
Rapid, incremental delivery of software
AGILITY AND THE COST OF CHANGE
AN AGILE PROCESS
Is driven by customer descriptions of what is required (scenarios)
Recognizes that plans are short-lived
Develops software iteratively with a heavy emphasis on construction activities
Delivers multiple software increments
Adapts as changes occur
AGILITY PRINCIPLES - I
1. Our highest priority is to satisfy the customer through early and
continuous delivery of valuable software.
2. Welcome changing requirements, even late in development. Agile
processes harness change for the customer's competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a
couple of months, with a preference to the shorter timescale.
4. Business people and developers must work together daily throughout
the project.
5. Build projects around motivated individuals. Give them the
environment and support they need, and trust them to get the job
done.
6. The most efficient and effective method of conveying information to
and within a development team is facetoface conversation.
AGILITY PRINCIPLES - II
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development. The
sponsors, developers, and users should be able to maintain a
constant pace indefinitely.
9. Continuous attention to technical excellence and good design
enhances agility.
10. Simplicity the art of maximizing the amount of work not done
is essential.
11. The best architectures, requirements, and designs emerge
from selforganizing teams.
12. At regular intervals, the team reflects on how to become more
effective, then tunes and adjusts its behavior accordingly.

HUMAN FACTORS
The process molds to the needs of the people and team, not the other
way around
Key traits must exist among the people on an agile team and the team
itself:
Competence.
Common focus.
Collaboration.
Decision-making ability.
Fuzzy problem-solving ability.
Mutual trust and respect.
Self-organization.
EXTREME PROGRAMMING (XP)
The most widely used agile process, originally proposed by Kent Beck
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
After the first increment project velocity is used to help define subsequent delivery
dates for other increments
EXTREME PROGRAMMING (XP)
37
XP Design
Follows the KIS principle
Encourage the use of CRC cards (see Chapter 8)
For difficult design problems, suggests the creation of spike solutionsa design
prototype
Encourages refactoringan iterative refinement of the internal program design
XP Coding
Recommends the construction of a unit test for a store before coding commences
Encourages pair programming
XP Testing
All unit tests are executed daily
Acceptance tests are defined by the customer and excuted to assess customer
visible functionality

ADAPTIVE SOFTWARE DEVELOPMENT
Originally proposed by Jim Highsmith
ASD distinguishing features
Mission-driven planning
Component-based focus
Uses time-boxing (See Chapter 24)
Explicit consideration of risks
Emphasizes collaboration for requirements gathering
Emphasizes learning throughout the process
DYNAMIC SYSTEMS DEVELOPMENT METHOD
Promoted by the DSDM Consortium (www.dsdm.org)
DSDMdistinguishing features
Similar in most respects to XP and/or ASD
Nine guiding principles
Active user involvement is imperative.
DSDM teams must be empowered to make decisions.
The focus is on frequent delivery of products.
Fitness for business purpose is the essential criterion for acceptance of deliverables.
Iterative and incremental development is necessary to converge on an accurate business solution.
All changes during development are reversible.
Requirements are baselined at a high level
Testing is integrated throughout the life-cycle.
SCRUM
Originally proposed by Schwaber and Beedle
Scrumdistinguishing features
Development work is partitioned into packets
Testing and documentation are on-going as the product is constructed
Work occurs in sprints and is derived from a backlog of existing requirements
Meetings are very short and sometimes conducted without chairs
demos are delivered to the customer with the time-box allocated
CRYSTAL
Proposed by Cockburn and Highsmith
Crystaldistinguishing features
Actually a family of process models that allow maneuverability based
on problem characteristics
Face-to-face communication is emphasized
Suggests the use of reflection workshops to review the work habits of
the team
FEATURE DRIVEN DEVELOPMENT
Originally proposed by Peter Coad et al
FDDdistinguishing features
Emphasis is on defining features
a feature is a client-valued function that can be implemented in two
weeks or less.
Uses a feature template
<action> the <result> <by | for | of | to> a(n) <object>
A features list is created and plan by feature is conducted
Design and construction merge in FDD
AGILE MODELING
Originally proposed by Scott Ambler
Suggests a set of agile modeling principles
Model with a purpose
Use multiple models
Travel light
Content is more important than representation
Know the models and the tools you use to create them
Adapt locally

THANKS