software life cycle models for presentation (2010)

8/3/2019 Software Life Cycle Models for Presentation (2010)

http://slidepdf.com/reader/full/software-life-cycle-models-for-presentation-2010 1/62

Wednesday, May 02, 20SNS COLLEGE OF TECHNOLOGY



SOFTWARE LIFE CYCLE

A life cycle model defines the phases, milestones,deliverables, and evaluation criteria of the software

development process. These form the basis of the work

breakdown structure (WBS), used for project planning

and management.





Process interrelationships

IEEE 1074 standard (UML act

diagram, adapted from[IEEE

1074-1995]]. As suggested by

picture, dependencies amo

processes and activities

complex and seldom allow

sequential execution of proc

Process interrelationships

IEEE 1074 standard (UML act

diagram, adapted from [IEEE Std. 1074-1995]]. As su

by this picture, dependencies

processes and activities

complex and seldom allow

sequential execution of proc



Simple life cycles may have only three phases, Design, Development,

Maintenance; while complex life cycles may include 20 or more pha

Generally, software life cycles include the phases shown in Figure


Requirements

Design

Implementation

Testing

Deployment

Maintenan

Common Life Cycle

phases




Common Life Cycle Phases

Requirements

Design

Implementation

Testing

Deployment

Maintenance

Consists of analyzing the

problem or need for which thesoftware is being developed. This

analysis, a systems engineering

activity, develops and specifies

requirements, stating what thesoftware must do. In addition to

stated requirements,

requirements are derived from

higher-level requirements and

statements of need




The software structure is defined.

Technical approaches are chosen aproblems are solved conceptually.

phase is often divided into a

Preliminary Design Phase and a

Detailed Design Phase. In thepreliminary design the initial softw

architecture is developed. In the

detailed design, functional module

defined, along with user interfaces

interfaces between modules.


Requirements

Design

Implementation

Testing

Deployment

Maintenance




(sometimes called the Developmen

Phase) is where the programmingcoding takes place to execute the

software design. This phase is ofte

iterative, with unit and integration

testing being performed after asoftware build, and the results use

another round of programming.


Requirements

Design

Implementation

Testing

Deployment

Maintenance




Testing is often split into three sep

phases: Unit Testing, IntegrationTesting, and Acceptance Testing. T

first two may be part of a repeated

cycle of coding and testing, while

acceptance testing verifiesrequirements compliance.


Requirements

Design

Implementation

Testing

Deployment

Maintenance




The software is installed in th

intended system and users ar

trained in its operation. At th

point the software developme

effort is considered complete


Requirements

Design

Implementation

Testing

Deployment

Maintenance




1

Fixing errors and modifying or upgradin

software to provide additional functional

such as enabling the software to work wicomputing platforms. This phase costs fa

in time and effort than the original devel

Software maintainers must relearn the o

software code to understand what was do

then make changes to specific modules to

produce the desired effect without interfe

with rest of the software. It’s much easier

change requirements earlier than it is to

software code later. This also means that

software should be developed with maint

in mind


Requirements

Design

Implementation

Testing

Deployment

Maintenance



Life cycle Models

Build-and-fix modelWaterfall modelV-Shaped Model

Spiral modelSawtooth modelSharktooth Model

Unified Software Development Process

Issue-Based Life Cycle ModelThe Incremental Model


1



Build-And-Fix Model

The earliest approach

• Write code

• Fix it to eliminate any errors that have been detected, toenhance existing functionality, or to add new features

• Source of difficulties and deficiencies

• impossible to predict

•impossible to manage


1



Build-And-Fix Model Wednesday, May 02, 20SNS COLLEGE OF TECHNOLOGY

1

Build First

version

Modify until

client is satisfied

Maintenance

Phase

Retirement

Development

Maintenance

The easiest way to develop software

The most expensive way for maintena

(i.e., maintenance nightmare)



Build-And-Fix Model

• The product is implemented without requirements or specifications,or any attempt at design.

• The developers simply throw code together and rework it as manytimes as necessary to satisfy the client.

•

It is used in small project and is totally unsatisfactory for products ofany reasonable size.• It is the worst model for developing a project. The product is built

without proper specifications and design steps. In essence, theproduct is built and modified as many times as possible until itsatisfies the client.

• The cost of using this approach is greater than if specifications are

drawn up and a design is carefully developed. Software engineers arestrongly discouraged from using this development approach


1



Waterfall Model

This is the most common and classic of life cycle models, a

referred to as a linear-sequential life cycle model. It is ver

simple to understand and use. In a waterfall model, eachphase must be completed in its entirety before the next ph

can begin. At the end of each phase, a review takes place t

determine if the project is on the right path and whether o

not to continue or discard the project. Unlike what Imentioned in the general model, phases do not overlap in a

waterfall model.


1



SNS COLLEGE OF TECHNOLOGY

Waterfall

Model




1

Requirements

Phase

Specification

Phase

Design

Phase

Implementation phase

Integration phase

Maintenance

Retirement

Changed Requirem

Waterfall Model

Development

Maintenance



Advantages

• Simple and easy to use.

•Easy to manage due to the rigidity of the model – eachphase has specific deliverables and a review process.

• Phases are processed and completed one at a time.

• Works well for smaller projects where requirements

are very well understood.


1



Disadvantages

• Adjusting scope during the life cycle can kill a project

• No working software is produced until late during the

life cycle.• High amounts of risk and uncertainty.

• Poor model for complex and object-oriented projects.

• Poor model for long and ongoing projects.

•

Poor model where requirements are at a moderate tohigh risk of changing.


1



V-Shaped Model

Just like the waterfall model, the V-Shaped life cycle is a sequential path oexecution of processes. Each phase must be completed before the next phase beginsTesting is emphasized in this model more so than the waterfall model though. The tprocedures are developed early in the life cycle before any coding is done, during eathe phases preceding implementation.

Requirements begin the life cycle model just like the waterfall model. Befdevelopment is started, a system test plan is created. The test plan focuses on meetifunctionality specified in the requirements gathering.

The high-level design phase focuses on system architecture and design. Aintegration test plan is created in this phase as well in order to test the pieces of thesoftware systems ability to work together.

The low-level design phase is where the actual software components are

designed, and unit tests are created in this phase as well.The implementation phase is, again, where all coding takes place. Once c

is complete, the path of execution continues up the right side of the V where the testdeveloped earlier are now put to use.


2



V-Shaped Model Wednesday, May 02, 20SNS COLLEGE OF TECHNOLOGY

2



V-Shaped Model

In many aspects, the waterfall model and its variants aresimplistic abstractions of the software development process

The weakness of these models is that they assume that afteran activity is finished and reviewed the associated work product can be baselined. Such an idealized model is onlyappropriate if the specification of the requirements is of high level of assurance and does not change during

development. In practice, system development rarelyconforms to this ideal model.


2



Advantages

• Simple and easy to use.

• Each phase has specific deliverables.

• Higher chance of success over the waterfall model due

to the development of test plans early on during the

life cycle.

• Works well for small projects where requirements are

easily understood.


2



Disadvantages

• Very rigid, like the waterfall model.

• Little flexibility and adjusting scope is difficult and

expensive.• Software is developed during the implementation

phase, so no early prototypes of the software are

produced.

•Model doesn’t provide a clear path for problemsfound during testing phases.


2



Spiral Model

The spiral model is similar to the incremental model, with more emphasesplaced on risk analysis. The spiral model has four phases: Planning, Risk Analysis, Engineering and Evaluation. A software project repeatedly passesthrough these phases in iterations (called Spirals in this model). The baselinspiral, starting in the planning phase, requirements are gathered and risk isassessed. Each subsequent spirals builds on the baseline spiral.

Requirements are gathered during the planning phase. In the risk analysis phase, a process is undertaken to identify risk and alternate solutionA prototype is produced at the end of the risk analysis phase.

Software is produced in the engineering phase, along with testing

the end of the phase. The evaluation phase allows the customer to evaluate toutput of the project to date before the project continues to the next spiral.

In the spiral model, the angular componentrepresents progress, and the radius of the spiral represents cost.


2




2

Developers explore

alternatives, define

constraints, and

identify objectives.

Spiral Model




2

Developers manage

risks associated

with the solutions

defined

during the first

phase

Spiral Model




2

Developers realize

and

validate a prototype

or the part of the

system associated

with the risks

addressed in this

round.

Spiral Model




2Spiral Model

Focuses on the

planning of the next

round based on the

results produced inthe current round. The

last phase of the

round is usually

conducted as a

review involving the

project participants,

including developers,

clients, and users.



• The spiral model proposed by Boehm is an iterative model with th



Spiral Model

• The spiral model proposed by Boehm is an iterative model with thfollowing activities• Determine objectives and constraints

• Evaluate Alternatives

• Identify risks• Resolve risks by assigning priorities to risks

• Develop a series of prototypes for the identified risks starting with thhighest risk.

• Use a waterfall model for each prototype development (“cycle”)

• If a risk has successfully been resolved, evaluate the results of the “cyand plan the next round

• If a certain risk cannot be resolved, terminate the project immediately


3



Advantages

• 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


3



Disadvantages

• Time spent for evaluating risks too large for small or low-risk projects

• Time spent planning, resetting objectives, doing risk analysis andprototyping may be excessive

• The model is complex

• Risk assessment expertise is required

• Spiral may continue indefinitely

• Developers must be reassigned during non-development phaseactivities

•May be hard to define objective, verifiable milestones that indicatereadiness to proceed through the next iteration


4



Sawtooth Model Wednesday, May 02, 20SNS COLLEGE OF TECHNOLOGY

4

Client’s Understanding

Developer’s Understanding

RequirementsElicitation

Implementation

SystemDesign

ObjectDesign

RequirementsAnalysis

Unit Test

PrototypeDemonstration 2 A

SysteIntegra

& Te

Integration& Test

PrototypeDemonstration 1



The life cycle models we described until now emphasize themanagement of software developers. They do not address theneeds of the customer or the user. The waterfall model, the V

model and the spiral model all assume that the softwarerequirements will not change drastically during the duration of the project and that it is sufficient to show progress according tothe development plan. The drawback of this approach is that theclient and the user do not see a running system before the client

acceptance test, and thus, cannot correct any requirementproblems.


4Sawtooth Model



Sharktooth Model Wednesday, May 02, 20SNS COLLEGE OF TECHNOLOGY

4

User’s Understanding

System RequirementsElicitation

Implementation

System Design

ObjectDesign

Requirements Analysis

UnitTest

PrototypeDemo 1

PrototypeDemo 2

D

DesignReview

Cl Acc

SysteIntegr& Tes

ComponenIntegrat& Test

Manager’s Understanding

Developer’s Understanding



The shark tooth model is a refinement of the sawtooth model. Inaddition to the client demonstrations (large teeth) management reviewsand demonstrations are introduced as well (small teeth).

For example, large teeth can include a functional prototypeand a user interface mock-up. The former demonstrates the feasibility othe functions that will be implemented in the system, whereas the latterillustrates the layout (or look and feel) of the user interface. Small teethcan include a system integration prototype that demonstrates theinteraction between the components of the system. Such an integration

prototype can be built as soon as the components are selected and neednot implement any functionality


4Sharktooth Model

E tit t d lif l i f th




4

Use case model

Analysis model

Design model

Implementation

model

Deployment

model

Test model

specified by

realized by

distributed by

implemented by

verified by

Unified Software

Development Process

Entity-centered life cycle view of the

of the Unified Process (UML class d

the dependencies depict traceability. T

dependencies between all models. O

dependencies between the use case m

the other models are shown

[Jacobson et al., 1999].



The Unified Software Development Process (also called theUnified Process) is a life cycle model proposed by Booch,Jacobson, and Rumbaugh [Jacobson et al., 1999]. Similar to

Boehm’s spiral model, a project consists of several cycles, eachof which ends with the delivery of a product to the customer.Each cycle consists four phases: Inception, Elaboration,Construction, and Transition. Each phase itself consists of anumber of iterations. Each iteration addresses a set of related use

cases or mitigates some of the risks identified at the beginning ofthe iteration.


4

Unified Software

Development Process



Issue-Based Life Cycle ModelWednesday, May 02, 20SNS COLLEGE OF TECHNOLOGY

4

i1:Issue

status={Closed}

i2:Issue

status = {Open}

i3:Issue

status = {Open}

i5:Issue

status = {Open}

i5:Issue

status={Closed}

i6:Iss

status =

Snapshot o

issue base (U

diagram). Is

i5 have been

whereas all o

are stillDependenc

issues indica

resolution o

can const

alternati

dependen

In the following we describe an entity-centered life cycle model, called the



g y y

issue-based life cycle model that aims at dealing with frequent changes. This

model is based on the rationale behind the system as an issue model (see

Chapter 8, Rationale Management). Each project starts with a set of issues. If

the project starts from scratch, these issues are drawn from the project

manager’s experience or from a standard template. In a re-engineering or

interface project, issues may be available from the issue model of the previous

project. If the project has a long history, the rationale should be well populated.

Examples of issues are “How do we set up the initial teams?”, “Should the

mechanic have access to driver-specific information“, “What is the appropriate

middleware?” or “What software architecture shall we use?”, “What should weuse as implementation language”? All issues are stored in an issue base that is

accessible to all project participants


4Issue-Based Life Cycle Model

• It combines elements of the waterfall model applied in an



The Incremental Model

• It combines elements of the waterfall model applied in aniterative fashion

• It delivers a series of releases, called increments, that provideprogressively more functionality for customer as each

increment is delivered• When it is used, the first increment is often a core product.

That is, basic requirements are addressed, but manysupplementary features remain undelivered

• The core product is used by customer. As a result, a plan is

developed for next increment

Wednesday, May 02, 20SNS COLLEGE OF TECHNOLOGY4





• This model focuses on the delivery of an operational




This model focuses on the delivery of an operational

product with each increment

• Incremental development is particularly useful when

staffing is unavailable for a complete implementation bythe business deadline. Early increments can be

implemented with fewer people, and additional staff can

be added to later increments

•Increments can be planned to manage technical risks




Advantages

• It generates working software quickly and early duringthe software life cycle.

• Flexibility is more and less costly.

• Testing and debugging becomes easier during a smalleriteration.

• Risk can be managed more easily because they can beidentified easily during iteration.

• Early increments can be implemented with fewer people.




• Each phase of an iteration is rigid and do not overlap each

other.• Problems may arise pertaining to system architecture

because not all requirements are gathered up front for the

entire software life cycle.

Wednesday, May 02, 20SNS COLLEGE OF TECHNOLOGY5Disadvantages

• RAD (Rapid Application Development) is an incremental SW



The RAD Model

process model that emphasizes a short development cycle

• RAD model is a “high-speed” adaptation of the waterfallmodel, in which rapid development is achieved by using a

component-based construction approach• If a business application can be modularized in a way that

enables each major function to be completed in less than 3months, it is a candidate for RAD

• Each major function can be addressed by a separate RAD team and

then integrated to form a whole




The RAD ModelWednesday, May 02, 20SNS COLLEGE OF TECHNOLOGY

5

A il ft d l t i f ft d l t

http://en.wikipedia.org/wiki/Software_development_methodologies




Agile Software Development

Agile software development is a group of software developmentmethodologies based on iterative and incremental development,where requirements and solutions evolve through collaborationbetween self-organizing, cross-functional teams. It promotesadaptive planning, evolutionary development and delivery, atime-boxed iterative approach, and encourages rapid and flexibleresponse to change. It is a conceptual framework that promotesforeseen interactions throughout the development cycle. The Agile Manifesto[1] introduced the term in 2001. Agilemanagement methods can also be applied in other developmentprojects than software development.


Agile methods break tasks into small incremen



http://en.wikipedia.org/wiki/Iterative_and_incremental_development

http://en.wikipedia.org/wiki/Self-organization

http://en.wikipedia.org/wiki/Cross-functional_team

http://d/darwin%20fh/darwin%20fh/Agile_software_development.html

http://en.wikipedia.org/wiki/Agile_management











http://en.wikipedia.org/wiki/Iterative_and_incremental_development





Wednesday, May 02, 20SNS COLLEGE OF TECHNOLOGY5 Agile Software Development

minimal planning, and do not directly involve l

planning. Iterations are short time frames (time

that typically last from one to four weeks. Each

involves a team working through a full softwar

development cycle including planning, requirem

analysis, design, coding, unit testing, and accep

testing when a working product is demonstrated

stakeholders. This minimizes overall risk and a

project to adapt to changes quickly. Stakeholde

produce documentation as required. An iteratio

not add enough functionality to warrant a markrelease, but the goal is to have an available rele

minimal bugs) at the end of each iteration.[9] M

iterations may be required to release a product

features.

− “Spiral Model as a Tool for Evolutionary Acquisition” www.stsc.hill.af.mil/crosstalk/2001/may/boehm.asp

− “Prototypes: Tools That Can Be Used and Misused” www.stsc.hill.af.mil/crosstalk/1994/jan/xt94d01g.asp

http://en.wikipedia.org/wiki/Timeboxing

http://en.wikipedia.org/wiki/Requirements_analysis


http://en.wikipedia.org/wiki/Software_Design

http://en.wikipedia.org/wiki/Computer_programming

http://en.wikipedia.org/wiki/Unit_test

http://en.wikipedia.org/wiki/Acceptance_test


http://en.wikipedia.org/wiki/Software_bug



http://en.wikipedia.org/wiki/Software_bug



http://en.wikipedia.org/wiki/Unit_test

http://en.wikipedia.org/wiki/Computer_programming

http://en.wikipedia.org/wiki/Software_Design



http://en.wikipedia.org/wiki/Timeboxing



Reference :Wednesday, May 02, 20SNS COLLEGE OF TECHNOLOGY

5

− “Extreme Methodologies for an Extreme World” www.stsc.hill.af.mil/crosstalk/2001/jun/leishman.asp

− “Balancing Discipline and Flexibility With the Spiral Model and MBASE”

www.stsc.hill.af.mil/crosstalk/2001/dec/boehm.asp

− “Customizing the Software Process to Support Avionics Systems Enhancements”

www.stsc.hill.af.mil/crosstalk/2001/sep/donzelli.asp

− “Tailoring a Software Process for Software Project Plans Part 1: Context and Making Tailoring Decisions”

www.stsc.hill.af.mil/crosstalk/1996/apr/tailorin.asp

− “Tailoring a Software Process for Software Project Plans Part 2: Documenting the Project's Defined Software

Process” www.stsc.hill.af.mil/crosstalk/1996/may/tailorin.asp

− “MIL-STD-498: What's New and Some Real Lessons Learned”

www.stsc.hill.af.mil/crosstalk/1996/mar/lesslear.asp

DeGrace, Peter and Stahl, Leslie, Wicked Problems, Righteous Solutions: A Catalogue of Modern Software

engineering

Paradigms, Yourdon Press.Department of Energy (DOE) Software Engineering Methodology, Chapter 2:

http://cio.doe.gov/sqse/sem_toc.htm



And that’s it. If you have any input,

especially your views on advantages anddisadvantages of any particular model,

feel free to leave them in the comments

and I can add them to my copy.


5




6

software life cycle models for presentation (2010)

Documents