Software Development Lifecycle

offbeatnothingSoftware and s/w Development

Dec 2, 2013 (3 years and 11 months ago)

84 views

Software Development Lifecycle
Models

Fall 2009

Question:


We know that we have to do some things in order
to get a software product completed:


Gather requirements


Design


Implement


Test





How do you order these activities so that you are
most productive?

What is a lifecycle model?


Phase
: activities to accomplish goals.


Lifecycle model:
A model of the phases
that start when the project is conceived and
ends when the product is retired.


Depicts the relationships between the major
milestones, reviews, deliverables.


Determines the order of activities.


A lifecycle model ...


Not a definition of the process an
organization follows.


Does not provide rules or representations
for development.


Is reference used to discuss the
development of software.


Some Models



Code and fix


Waterfall


Prototyping


RAD


Incremental/evolutionary


Reusable components


Automated synthesis


Spiral


XP

0. Code and Fix (aka “cowboy”)


Repeat


write code


fix it


Until code is good enough or resources
exhausted

In class


What are the pros and cons of this
approach?


(2 minutes)

1. Waterfall (traditional)


First systematic approach, best studied.


Winston Royce


Some aerospace and government agencies
mandate some form of this model.


Must be adapted to a particular situation or
organization.





Waterfall Phases

Feasibility

Specify
Requirements

Design

Implement

Test

Deliver

Maintain

Feasibility Study




feasibility study



Requirements




requirements specification document (SRS)


states what qualities software must exhibit.


needs to be understandable, precise, complete,
consistent, unambiguous, modifiable


preliminary user manual?


system test plan?


functional requirements


non
-
functional requirements


Design


design (preliminary and detailed)


decompose system into modules, selection of a
software architecture


top
-
down, iterative




Code, Test, Deliver


coding and unit testing


create code (aka “programming”)


integration and system testing


this might be combined with the previous, done
in incremental fashion


alpha testing


delivery


beta testing


acceptance testing





Maintain
(evolution?)

Corrective: (fix bugs)


12% = “emergency fixes”


9% = routine debugging

Adaptive: (secondary changes)


17% = change data formats


6% = hardware changes

Perfective (improve)



5% = improvements in documentation


4% = improvements in efficiency



42% = change user requirements

Preventive (form of Perfective)


Advantages of Waterfall


Shows that software can be disciplined.


Forces attention on requirements and design
before code.


Encourages planning.


Provides documents that can be used for
testing.


Documents become part of legacy of
system.

In Class


Clearly, waterfall has advantages over code
and fix.


There are many criticisms of waterfall: what
are they?


(3 minutes)

2. Rapid Prototypes


Gomaa and Scott (early 80s)


Prototypes are throwaway.


Build prototype


User feedback drives correction of
requirements


Toss the prototype


Build system in traditional way

In Class


How is this better than waterfall?


What are the costs?

3. RAD


Rapid application development:


short development cycle based on components and
4GLs.


Used for


Modeling: business, data, and process


Application generation


Testing/installation

3. RAD


Difficult to scale to large projects.


Works best when system can be modularized and
is well understood (eg business apps).


Does not work well when technical risks are high,
system cannot be modularized, or interfaces to
other systems are an issue.

4. Incremental/Evolutionary


Recognized as desirable by government


Incremental:


Design is totally laid out first


Functionality is provided in stages


Evolutionary: prototype evolves into final version



Goal: get feedback earlier in process


repeat



give user something



evaluate/measure



adjust design and objectives

Iteration No.

Incremental Development

Analyze

requirements

Test whole

Implement

Design

Test units

Integrate

1

2

3

867

868

Update SRS
3

Update SDD
2

Update source code

Update Test documentation

Update SPMP
1

1
Software Project Mangement Plan (chapter 2);
2
Software Design Document (chapter 5);

3
Software Requirements Specification (chapter 3);

Adapted from
Software Engineering: An Object
-
Oriented Perspective
by Eric J. Braude (Wiley 2001), with permission.

In Class


What problems are we trying to fix with this
method?


What pitfalls arise?

5. Reusable software:


build it from parts.


this is the goal of the Ada project.


need to have parts, specs for parts, and tools
for accessing them.


there are several methods of automating the
lookup of parts.


specify as pre and post conditions.


6. Automated Synthesis


Transformations: KIDS, SPECWARE,
HATS


Start with a formal specification
(mathematical)


successively refine this (formally) until code


may entail theorem proving


may entail computer assisted software
engineering environment


Pre and post conditions


First order specifications, etc


6. Automated Synthesis


Programmer can no longer fix the code
directly.


Code is not result of coding, but of
transforming.


Change the specs and the code changes.


Also correct by construction, proofs as
programs

7. Spiral


Barry Boehm
(see
IEEE Computer
, vol 21, no
5, may 1988, pp61
-
72.)


meta
-
model


4 stages in each cycle


identify objectives and alternatives


evaluate alternatives, identify risk, deal with
risks


develop, verify, prototype,
use any model



evaluate and plan next cycle



starts with hypothesis that something can be
improved


ends with product


Spiral Model

1.
Objective setting: for
each phase
--
identify
constraints, risk,
management plan

2.
Risk Assessment and
reduction

3.
Develop and Validate

4.
Planning: review project
and decide whether to
continue further in loop.

Rapid prototype

Specification

Planning

Design

Implementation

Integration

Verify

Test

Risk

Analysis

Spiral Model


Focus on eliminating errors early


Look at level of effort


Accommodates growth and change
(evolution)


Restrictions


In
-
house development (not contracted)


Good for large
-
scale systems


Requires training in risk analysis and resolution

Driving Forces


waterfall: documentation driven


evolutionary: increment driven


transformational: specification driven


spiral: risk driven


Elaboration

Inception

Construction

Transition


Requirements




Analysis

Iter.

#1

Iter.

#n

Iter.

#n+1

Iter.

#m

Iter.

#m+1

Iter.

#k

…..



..

Prelim.

iterations

USDP vs. Standard Terminology (Booch, Jacobson &
Rumbaugh)


Design




Implementation




Test

USDP calls these

“core workflows”


(Classically called
“phases”)

Classification of iterations

Individual iteration


Requirements




Analysis

USDP vs. Standard Terminology
2 of 2


Design




Implementation




Test

Requirements analysis

Implementation

USDP

Terminology

Classical

Terminology

Integration

Design

Test

Adapted from
Software Engineering: An Object
-
Oriented Perspective
by Eric J. Braude (Wiley 2001), with permission.

Elaboration

Unified Process Matrix

Inception

Construction

Transition


Requirements




Analysis

Jacobson
et al
: USDP

Prelim.

iterations

Iter.

#1

Iter.

#n

Iter.

#n+1

Iter.

#m

Iter.

#m+1

Iter.

#k

…..

…..


Design



Implementation




Test

..

Amount of effort expended

on the requirements phase

during the first Construction

iteration

Agile

(1) moving quickly and lightly;

(2) mentally quick; "an agile mind";

(3) Refers to the speed of operations within an
organization and speed in responding to
customers (reduced cycle times).

Agile Methods

Agile is an iterative and incremental
(evolutionary) approach to software
development which [sic] is performed in a
highly collaborative manner with "just
enough" ceremony that produces high
quality software

which meets the
changing needs of its stakeholders.

»
http://www.agilemodeling.com/essays/agileSoftwar
eDevelopment.htm

Values of Agile


Individuals and interactions over processes and
tools


Working software over comprehensive
documentation


Customer collaboration over contract negotiation


Responding to change over following a plan


Outline of Agile Methods


Minimize risk by developing software in short
cycles


iterations


typically last one to four weeks


An iteration


like a miniature software project


includes planning, requirements analysis, design,
coding, testing, and documentation.


At the end of each iteration, the team re
-
evaluates
project priorities

Communications


Emphasize real time communication


face
-
to
-
face rather than written documents


All team members are co
-
located


programmers, testers, techwriters


managers


"customers" who define the product

In class


What are the advantages and disadvantages
of having everyone at one site?

Software


Working software is the primary measure of
progress


Very little written documentation relative to
other methods


Criticism of agile methods: undisciplined


May or may not be true

History


Evolved in the mid 1990s


Reaction against "heavyweight" methods such as waterfall


Waterfall


Regimented and micromanaged


Bureaucratic, slow


Contradicts way SEs actually perform effective
work


Agile is a return to practices seen early in software
development


Is this good? Bad?


2001 meeting at Snowbird adopted name “agile” over
“lightweight”

History


Extreme Programming (XP)


Not first, but most popular


Established in 1966 by Kent Beck


Tried to save the Chrysler C3 project (but
didn’t)


1999
Elements of Extreme Programming

Different Agile Methods


Created prior to 2000


Scrum


Crystal Clear (1986)


XP (1996)


Adaptive Software Development


Feature Driven Development


DSDM (1885)

Some of the principles behind the
Agile Manifesto


Customer satisfaction by rapid (two weeks?), continuous
delivery of useful software.


Working software is the principal measure of progress.


Late changes in requirements are welcomed.


Daily, face
-
to
-
face conversation is the best form of
communication.


Projects are built around motivated individuals, who should
be trusted.


Continuous attention to technical excellence and good design


Simplicity.


Self
-
organizing teams


Regular adaptation to changing circumstances


Adaptive vs Predictive Methods


Adaptive methods


focus on adapting quickly to changing realities


difficulty describing exactly what will happen in the future


The further away a date is, the more vague an adaptive method will
be.


Team can report what tasks will be complete next week


Team can report what features will be worked on next month


Team cannot predict what features will be in the release 6 months out


Predictive methods


focus on planning the future in detail


difficulty changing direction


A predictive team can report exactly what features and tasks are
planned for the entire length of the development process.


The plan is typically optimized for the original destination and
changing direction can cause completed work to be thrown away and
done over differently.

In class


List several characteristics of projects
suitable for predictive methods and several
characteristics of projects suitable for
adaptive methods.

Agile Contrasted with Iterative


Iterative


Build releasable software in short time periods


Iterative time frames measured in months


Agile


Build releasable software in short time periods


Time frame in weeks


Time frame is strict


Agile Contrasted with Waterfall


Waterfall


Most predictive of methods: sequence of steps is highly planned


Document driven: progress is based on delivery of documents
after each stage


Lengthy testing and integration phase at end of project


Delivers fully implemented software at the end of the project


Some agile teams use the waterfall model on a small scale,
repeating the entire waterfall cycle in every iteration


Agile


Least predictive methods


Feature driven: progress based on delivery of features


Testing is part of feature development: no significant
integration problems


Delivers fully developed features (but small subset of them)
each development cycle

Agile Contrasted with Cowboy


"cowboy coding“


Cowboy coding is the absence of a defined method:
team members do whatever they feel is right


Success depends on heroics


Agile


Agile may be confused with cowboy


Agile teams follow defined (and often very
disciplined and rigorous) processes

Suitability of Agile Methods


Organization must support negotiation


People must be trusted


Requires higher competence


Organizations must live with the decisions
developers make


Organizations must support rapid communication


Suitable for projects with small teams, with fewer
than 20 to 40 people.

Agile vs Plan
-
driven

Agile


Low criticality


Senior developers


Requirements change very
often


Small number of developers


Culture that thrives on chaos


Plan
-
driven


High criticality


Junior developers


Low requirements change


Large number of developers


Culture that demands order


Problems with Agile


Push to get initial software working may result in
poor architecture, which is difficult to change


Client may be talked into poor choices by
developers


Single "dominant" developer may exert undo
influence


Depends on the ability of the customer to provide
negative feedback when necessary


In theory, the rapidly iterative nature should limit
problems, but it assumes that there's a negative
feedback, or even appropriate feedback. If not, errors
could be magnified rapidly.


Criticisms include:


lack of structure and necessary
documentation


only works with senior
-
level developers


incorporates insufficient software design


requires too much cultural change to adopt


can lead to more difficult contractual
negotiations


Some of the well
-
known agile
software development methods:


Extreme Programming (XP)


Scrum


Agile Modeling


Adaptive Software Development (ASD)


Crystal Clear and Other Crystal Methodologies


Dynamic Systems Development Method (DSDM)


Feature Driven Development (FDD)


Lean software development


Agile Unified Process (AUP)


XP


The main aim of XP is to reduce the cost of
change.

XP


Extreme Programming Explained

describes
Extreme Programming as being:


An attempt to reconcile humanity and
productivity


A mechanism for social change


A path to improvement


A style of development


A software development discipline


Five Values of XP


Communication


Simplicity


Feedback


Courage


Respect

Activities


Coding


Testing


Listening


Designing

12 XP Practices


Fine scale feedback


Pair programming


Planning Game


Test drive
development


Whole team


Continuous process


Continuous
integration


Design improvement


Small releases


Shared understanding


Coding Standards


Collective code
ownership


Simple design


System metaphor


Programmer welfare


Sustainable pace


In class: Choose Development
Model


Student Information System for UTEP


Autonomous Network of Mobile Robots for
Asteroid Exploration


Web
-
based Purchasing System for Car parts


Airborne Navigation System for
Commercial Aircraft


Data
-
mining System for Human Genome