introduction requirements and the software lifecycle (3)

26
Introduction Requirements and the Software Lifecycle (3)

Upload: angelica-harris

Post on 19-Jan-2018

221 views

Category:

Documents


0 download

DESCRIPTION

Different Types of Lifecycles Code and Fix Stepwise Process Waterfall Method Spiral Method Iterative Method Agile Method Copyright Leffingwell, Widrig, & SIS Faculty

TRANSCRIPT

Page 1: Introduction Requirements and the Software Lifecycle (3)

IntroductionRequirements and the Software Lifecycle (3)

Page 2: Introduction Requirements and the Software Lifecycle (3)

Software Lifecycle•What is the software lifecycle

▫Who (is doing what task)▫What (is the task they are doing)▫When (is the task being performed)▫How (is the task being performed)

What are all the steps

Copyright Leffingwell, Widrig, & SIS Faculty

Page 3: Introduction Requirements and the Software Lifecycle (3)

Different Types of Lifecycles•Code and Fix•Stepwise Process•Waterfall Method•Spiral Method•Iterative Method•Agile Method

Copyright Leffingwell, Widrig, & SIS Faculty

Page 4: Introduction Requirements and the Software Lifecycle (3)

Code and Fix •The original software design process•Start coding your product •Correct until the product is complete•Works for very simple projects

▫Sufficient for the type of projects of the time

•Problems ▫Major limitations to small projects ▫Could run into major design issues as you

are coding •Still used in some capacity during the

development phaseCopyright Leffingwell, Widrig, & SIS Faculty

Page 5: Introduction Requirements and the Software Lifecycle (3)

Stepwise Process•Dates back to as early as the 1950’s•Provided the necessary steps to design

software

•Problem is ▫It was unidirectional▫Define all the requirements upfront▫Complete every step in its entirety ▫No feedback built in

Copyright Leffingwell, Widrig, & SIS Faculty

Page 6: Introduction Requirements and the Software Lifecycle (3)

Waterfall Method•Formally introduced in 1970’s by Royce•Included feedback loops to the stepwise

process•Recognized the fact that lessons learned

should be used to fix future problems•Not included in the figure is prototyping

which Royce introduced

Copyright Leffingwell, Widrig, & SIS Faculty

Page 7: Introduction Requirements and the Software Lifecycle (3)

Waterfall Method•Figure 3-1

Copyright Leffingwell, Widrig, & SIS Faculty

Page 8: Introduction Requirements and the Software Lifecycle (3)

Waterfall Method•Delayed easily by rigid company guidelines

•Requirements are frozen so they cannot be changed

•Loose touch with the real world in which they are building the application for

•As projects reach budget limits some latter steps might be shortened to produce an on time and on budget project

Copyright Leffingwell, Widrig, & SIS Faculty

Page 9: Introduction Requirements and the Software Lifecycle (3)

Waterfall Method• Why did it come about

▫ Discovered the rework from fixing bugs later in the cycle was more costly.

• Why wasn’t it ideal?▫ Still a linear process▫ Requires Complete system definition ▫ Typically produced software that is

Low quality Over budget and past deadlines

• What was the result?▫ Regression to coding first▫ Agile methods

Copyright Leffingwell, Widrig, & SIS Faculty

Page 10: Introduction Requirements and the Software Lifecycle (3)

Requirements Handling

0

5

10

15

20

25

30

35

40

10 100 1000 10000Project Size in Function Points

Req

uire

men

ts c

hang

e

Changing increases with project sizeOne reason why the waterfall process is not effective

Copyright Craig Larman & SIS Faculty

Page 11: Introduction Requirements and the Software Lifecycle (3)

Spiral Method•Introduced by Boehm in 1988

•This was more of a risk driven and incremental development path▫Starts with risk-driven prototypes▫Then follows a waterfall type process

Copyright Leffingwell, Widrig, & SIS Faculty

Page 12: Introduction Requirements and the Software Lifecycle (3)

Spiral Method•Benefits

▫Feedback right away with your designs This is also referred to today as rapid

prototyping▫Receive quality feedback from the User early ▫Starts with requirement and concept

validation▫Has multiple feedback opportunities early on

Get out all the “Yes, buts”

Copyright Leffingwell, Widrig, & SIS Faculty

Page 13: Introduction Requirements and the Software Lifecycle (3)

Spiral Method•Issues

▫Can create different code streams/branches from the very beginning

▫Rapid prototypes can lead the user believe that the system is almost complete

▫Very time and resource heavy of creating prototypes and following the waterfall process

Copyright Leffingwell, Widrig, & SIS Faculty

Page 14: Introduction Requirements and the Software Lifecycle (3)

Spiral Method•Figure 3-2

Copyright Leffingwell, Widrig, & SIS Faculty

Page 15: Introduction Requirements and the Software Lifecycle (3)

Iterative Process•Introduced in 1990s•Is like doing numerous mini-waterfalls•Lifecycle

▫Inception = Analysis▫Elaboration = Design▫Construction = Code▫Transition = Test, Implement, …

Copyright Leffingwell, Widrig, & SIS Faculty

Page 16: Introduction Requirements and the Software Lifecycle (3)

Iterative Process

inc. elaboration construction transition

iteration phase

development cycle

release

A stable executable subset of the final product. The end of each iteration is a minor release.

increment

The difference (delta) between the releases of 2 subsequent iterations.

final production release

At this point, the system is released for production use.

milestone

An iteration end-point when some significant decision or evaluation occurs.

Copyright Craig Larman & SIS Faculty

Page 17: Introduction Requirements and the Software Lifecycle (3)

Iterative Software Development Process

Requirements

Design

Implementation &Test & Integration

& More Design

Final Integration & System Test

Requirements

Design

3 weeks (for example)The system grows incrementally.

Feedback from iteration N leads to refinement and adaptation of the requirements and design in iteration N+1.

Iterations are fixed in length, or timeboxed.

TimeImplementation &Test & Integration

& More Design

Final Integration & System Test

Each Iteration is a min-waterfall processCopyright Craig Larman & SIS Faculty

Page 18: Introduction Requirements and the Software Lifecycle (3)

Timeline

Iterations

SampleUP Disciplines

Business Modeling

Requirements

Design

Implementation

Test

Deployment

Configuration & Change Management

Project Management

Environment

Focus of this book

Note that although an iteration includes work in most disciplines, the relative effort and emphasis change over time.

This example is suggestive, not literal.

A four-week iteration (for example). A mini-project that includes work in most disciplines, ending in a stable executable.

Copyright Craig Larman & SIS Faculty

Page 19: Introduction Requirements and the Software Lifecycle (3)

Timeline

SampleUP Disciplines

Business Modeling

Requirements

Design

Implementation

...

The relative effort in disciplines shifts across the phases.

This example is suggestive, not literal.

incep-tion elaboration construction transi-

tion

...

Copyright Craig Larman & SIS Faculty

Page 20: Introduction Requirements and the Software Lifecycle (3)

Requirements Definition

Iteration 1 Iteration 2 Iteration 3 Iteration 4 Iteration 5

20%2%

requ

irem

ents

softw

are

30%

5%

requ

irem

ents

softw

are

50%

8%

90% 90%

20%10%

requirements workshops

Imagine this will ultimately be a 20-iteration project.

In evolutionary iterative development, the requirements evolve over a set of the early iterations, through a series of requirements workshops (for example). Perhaps after four iterations and workshops, 90% of the requirements are defined and refined. Nevertheless, only 10% of the software is built.

1 2 3 4 5 ... 20

week 1

M T W Th F

week 2

M T W Th F

week 3

M T W Th F

kickoff meeting clarifying iteration goals with the team. 1 hour

team agile modeling & design, UML whiteboard sketching.5 hours

start coding & testing

a 3-week iteration

de-scope iteration goals if too much work

final check-in and code-freeze for the iteration baseline

demo and 2-day requirements workshop

next iteration planning meeting;2 hours

Most OOA/D and applying UML during this period

Use-case modeling during the workshop

Copyright Craig Larman & SIS Faculty

Page 21: Introduction Requirements and the Software Lifecycle (3)

Iterative Process•Creating or modifying an existing module

•Creating the systems piece by piece over time

•The users will see new functionality after each iteration

Copyright Craig Larman & SIS Faculty

Page 22: Introduction Requirements and the Software Lifecycle (3)

Iterative SW Success•What are the factors that lead to success

with the Iterative Process▫Good initial architecture▫Library of units tests▫Refactoring▫Automated tools

Copyright Craig Larman & SIS Faculty

Page 23: Introduction Requirements and the Software Lifecycle (3)

Refactoring Early iterations are farther from the "truepath" of the system. Via feedback andadaptation, the system converges towardsthe most appropriate requirements anddesign.

In late iterations, a significant change inrequirements is rare, but can occur. Suchlate changes may give an organization acompetitive business advantage.

one iteration of design,implement, integrate, and test

Copyright Craig Larman & SIS Faculty

Page 24: Introduction Requirements and the Software Lifecycle (3)

Benefits of the Iterative Process

•Higher project success rate▫Easier to manage complexity▫Better mitigation of high risks▫Easier adaptation to changing requirements

•Lower defect rates•Higher productivity•Increased visibility (Management, Client)•Knowledge from previous iterations

applied to future iterations•No code is thrown away in prototypes

Copyright Craig Larman & SIS Faculty

Page 25: Introduction Requirements and the Software Lifecycle (3)

Important Practices•Tackle hi-risk/hi-priority early•Continuously engage users•Build core early•Test throughout to ensure quality•Focus on essential models using UML•Manage reqs. using Use Cases•Implement sound change &

configuration management

Copyright Craig Larman & SIS Faculty

Page 26: Introduction Requirements and the Software Lifecycle (3)

Agile Methodology•Eliminate as many unnecessary processes as

possible

•Believes in Verbalize instead of documenting▫Usually only with small teams▫Usually only with small projects

•There are versions for larger more complex projects and project teams ▫Starts to look like the iterative process