Choosing the Development Strategy;

offbeatnothingΛογισμικό & κατασκευή λογ/κού

2 Δεκ 2013 (πριν από 3 χρόνια και 6 μήνες)

59 εμφανίσεις

Choosing the Development Strategy;

Defining the Requirements

for Your Project

Lecture Packet 6


©
John W. Brackett

Getting from Project Startup to Delivery:

the Software Development Lifecycle Model


A “lifecycle model” specifies the order of the
phases (stages) of development:


Requirements definition, prototyping, design,
reviews, testing, release


Based upon assumptions about where the
“known unknowns” (risks) are in the project


The project’s risks drive selection of the lifecycle
model


Lifecycle model is reflected in the WBS


Sequential Lifecycle Model

Vintage 1970’s

Software

Requirements

Definition

Architectural

Design

Detailed

Design

Coding

Unit

Testing

Integration

Testing

System &

Acceptance

Testing

Sequential activities performed


to create the software system

Software Requirements are assumed


to be complete and correct

The major problems are expected

to be in design and coding

Result: Little visibility into working software

until late in the project

Iterating Software Requirements

Can Consume 30% of a Project’s Schedule

Specific Requirements

Description

External interfaces

Inputs to and outputs from the software system

Functional requirements

Actions taken in accepting and processing of inputs and
generating of outputs

Performance requirements

Static and dynamic numerical requirements

Logical database requirements

Requirements for information to be placed into a database

Software design constraints

Constraints imposed by conformance to system design
decisions, standards, hardware limitations

System/software attributes

Reliability; availability; security; maintainability;
portability

Comparison of Life Cycle Models

Process Model

Sequential

Works with poorly
understood
requirements

Poor

Works with poorly
understood
architecture

Poor

Provides customer
with progress
visibility

Poor

Allows for changes
to product during
development

Minimal

changes

Can produce highly
reliable system

Excellent

A BIG problem in most projects

A problem in most projects

Getting Stakeholder Agreement


on the Requirements


Many project managers act as if there is a complete
and well
-
defined set of requirements waiting to be
discovered


Communication is the key to learning stakeholder
requirements and negotiating reasonable expectations




Problems with Specifying Requirements


Customer may not adequately convey the real user needs


Developer may not be an expert in the application domain,
which inhibits communications


Developer's requirements specifications typically focus on
software
-
related attributes such as


functions


performance requirements


design constraints


Users and customers may not understand the requirements
produced by the developer and may have unreasonable
expectations

The Staged Delivery Lifecycle Model Delivers
Functionality Incrementally

Requirements

Definition

Architectural

Design

Build 1: Detailed design,

construction and release

Build N: Detailed design,

construction and release

Goal:
Software

Release



Key risk addressed: stakeholders


concern about lack of project visibility



Staged delivery of functionality

in builds of the deliverables



Each build is fully tested


Build Completion = Project Milestone


Staged Delivery Life Cycle Model

Concept of

Operations

Requirements

Definition

Architectural

Design

Build 1: Detailed design,

construction and release

Build N: Detailed design,

construction and release

Goal: full

functionality
available



Incremental functionality added in each release



Requirements are assumed “largely” defined



Architectural Design is “largely” complete



Limited modifications to requirements and


design in Builds 2
-
N


Advantages and Risks of Staged Delivery


Advantages


Progress more visible to stakeholders than with
the Sequential Delivery lifecycle model


Early warning of technical problems


Reduced risk of schedule slippage


Disadvantages


Requires well understood requirements


Requires architectural framework into which
functionality can be added incrementally


User
-
driven feature creep as they see each build
and understand what isn’t included



Comparison of Life Cycle Models

Process Model

Sequential

Staged
Delivery

Works with poorly
understood
requirements

Poor

Poor

Works with poorly
understood
architecture

Poor

Poor

Provides customer
with progress
visibility

Poor

Good

Allows for changes
to product during
development

Poor

Fair

Can produce highly
reliable system

Excellent

Excellent


The Challenge of Delivering

Business Value Quickly


Staged Delivery may be planned to provide incremental
delivery of the product features most valued by
stakeholders, but can’t cope with changing requirements


Other incremental delivery strategies emphasize a
stepwise approach to requirements discovery


Users often are not able to state what will provide
business value (“I will know it when I see it” user)


Goal: Build a subset of the desired system, show it to
stakeholders who can give feedback, refine the feature
set (requirements), and build the next piece





Assume your project will change, and may change often, to
reflect changes in the project environment


Neither

a sequential lifecycle or a staged
-
delivery lifecycle is
applicable in such an environment






The success with which you deliver satisfaction to your
stakeholders depends upon managing change in
requirements during product development

Change Drives Many Projects

Project

Company

Market

Evolutionary Delivery Lifecycle Model


Develop a

Version


Deliver the

Version


Prioritize

Requirements

Elicit

Stakeholder

Feedback

Project Goal

Preliminary

Requirements

Definition

Design of

Architecture

And Infrastructure

Parallel and iterative definition of requirements and


architecture to create a foundations for versions

A version

ready to deploy

after each cycle

Preparing for the First Delivery Phase



Project Goal

Preliminary

Requirements

Definition

Design of

Architecture

And Infrastructure

Project Initiation

Phase

Startup

Phase

Typical length: < 90 days

Results of the Startup Phase


Startup Phase provides
an initial
estimate of the
functionality to be delivered by each phase


At
end of Startup
Phase we should define the milestones
and deliverables for complete project


Architectural
design must support logical groupings of
user
-
visible functionality


Architecture must be largely unchanged to enable 90
-
120 day
development phases


Functions may be disabled prior to a delivery if testing is
incomplete







Typical EDL Project Time Line

Develop

Version
1

Develop

Version

2

Develop

Version

3

Deliver
Version

3


Deliver

Version

2


Prioritize

Based on
Feedback


Incorporate

Stakeholder
Feedback


Deliver

Version

1

Prioritize

Based on
Feedback


Incorporate

Stakeholder
Feedback

Startup Phase

90 days

Phase 1

90 days

Phase 2


90 days

Phase 3


90 days

Goal to Design

in < 3 months

EDL is Based on

“Time Box” Development


Key time box ideas:


Redefine the product to fit the schedule


Stakeholders must be willing to cut features for
a phase rather than stretch the schedule


Don’t sacrifice quality to reduce the schedule



Timebox

development is a …practice that helps to infuse
a development team with a sense of urgency and … keeps
the project’s focus on the most important features.”



Steve McConnell

Rationale for the

Evolutionary Delivery Life Cycle


Focuses on incremental development and delivery
of project functionality (“business value”)


Requirements details and priority are refined
based upon a major investment in learning from
the stakeholders



Forces stakeholder prioritization of required
features




Comparison of Life Cycle Models

Process Model

Sequential

Staged
Delivery

Evolutionary
Delivery

Works with poorly
understood
requirements

Poor

Poor

Good

Works with poorly
understood architecture

Poor

Poor

Poor

Provides customer with
progress visibility

Poor

Good

Excellent

Allows for changes to
product during
development

Poor

Fair

Fair to
Excellent
(depends on
architecture impact)

Can produce highly
reliable system

Excellent

Excellent


Good

(depends on QA of
versions)


Evolutionary Prototyping Lifecycle Model

Project Goal

Preliminary

Requirements

Definition

Design and

Implement

Initial Prototype

Refine

Prototype

Until Acceptable

Complete

and Release

Prototype



Design and

prototype

first the most


user
-
important parts of the software




Add to prototype and refine until done


Lessons Learned about Prototyping


Don’t prototype what you can’t deliver in a
reliable, usable form


Don’t deliver an early prototype for operational
use unless the user knows the impact of what is
missing


An early prototype can be a success even if it
demonstrates a desired approach is not feasible


Michael Dell: “Learn to make mistakes fast”

Comparison of Life Cycle Models

Process Model

Sequential

Staged
Delivery

Evolutionary
Delivery

Evolutionary
Prototyping

Works with poorly
understood
requirements

Poor

Poor

Good

Excellent

Works with poorly
understood
architecture

Poor

Poor

Poor

Poor to Fair

(depends on initial
design)


Provides customer
with progress
visibility

Poor

Good

Excellent

Excellent

Allows for changes
to product during
development

Poor

Fair

Fair to
Excellent

Excellent

Can produce highly
reliable system

Excellent

Excellent


Good

Fair

One Lifecycle Model


Doesn’t Fit All Projects


Projects differ greatly


Need to cope with unknown requirements?


Quick deployment of basic functionality?


Minimum cost?


High reliability?


Lifecycle model should be selected in order to
reduce the major project risks