ucs503 process models

8/3/2019 UCS503 Process Models

1/29

Introduction The Software Lifecycle

ByAshima SinghAsstt. Prof., CSED


2/29

A naive view:Problem Specification Final Program

But ... Where did the specificationcome from? How do you know the specification corresponds to the

users needs? How did you decide how to structureyour program? How do you know the program actually meets the

specification? How do you know your program will always work

correctly? What do you do if the users needs change? How do you divide tasks upif you have more than a

one-person team?

UCS503- Software Engineering

coding


3/29

RequirementsCollection

Establish customers needs

Analysis Model and specify the requirements (what)

Design Model and specify a solution (how)

Implementation Construct a solution in software

TestingValidate the solution against the

requirements

MaintenanceRepair defects and adapt the solution to newrequirements


NB: these are ongoing activities, not sequential phases!


4/29


The classicalsoftware lifecyclemodels the softwaredevelopment as a

step-by-stepwaterfall between

the variousdevelopment phases.

The waterfall model is unrealistic for many reasons: requirements must be frozen too earlyin the life-cycle requirements are validated too late

Design

Implementation

Testing

Maintenance

Analysis



5/29

1. Real projects rarely follow the sequential flow that themodel proposes. Iterationalways occurs and createsproblems in the application of the paradigm

2. It is often difficultfor the customer to state all

requirementsexplicitly. The classic life cycle requires thisand has difficulty accommodating the natural uncertaintythat exists at the beginning of many projects.

3. The customer must have patience. A working versionof theprogram(s) will not be available until late in the project

timespan. A major blunder, if undetected until the workingprogram is reviewed, can be disastrous.

Pressman, SE, p. 26



6/29


In practice, development is always iterative, and allactivities progress in parallel.


Testing

Design

AnalysisValidation through prototyping

Testing based on requirements

Testing throughout implementation

Maintenancethrough iteration

Design through refactoring

Implementation


7/29

Plan to iterateyour analysis, design andimplementation.

You wont get it right the first time, so integrate,validateand testas frequently as possible.

You should use iterative development only on

projects that you want to succeed. Martin Fowler, UML Distilled



8/29

Plan to incrementallydevelop (i.e., prototype)the system.

If possible, always have a running versionof thesystem, even if most functionality is yet to beimplemented.

Integratenew functionality as soon as possible.

Validateincremental versions against userrequirements.



9/29UCS503- Software Engineering

Validate

increment

Develop systemincrement

Design systemarchitecture

Integrateincrement

Validate

system

Define outlinerequirements

Assign requirementsto increments

System incomplete

Final

system


10/29

Development and delivery is broken down intoincrements with each increment delivering part of the

required functionality.

User requirements are prioritised and the highest

priority requirements are included in early

increments.

Is an iterative process



11/29

Customer value can be delivered with eachincrement so system functionality is availableearlier.

Early increments act as a prototype to helpelicit requirements for later increments.

Lower risk of overall project failure.

The highest priority system services tend to

receive the most testing.



12/29UCS503- Software Engineering

evolving system

initial requirements

first prototype

alpha demo

go, no-go decisioncompletion

Planning = determinationof objectives, alternativesand constraints

Risk Analysis = Analysis ofalternatives and identification/resolution of risks

Customer Evaluation =Assessment of theresults of engineering

Engineering =Development of thenext level product

Risk =something that

will delay project orincrease its cost


13/29


Riskanalysis

Riskanalysis

Riskanalysis

Riskanalysis Proto-

type 1

Prototype 2Prototype 3

Opera-

tionalprotoype

Concept ofOperation

Simulations, models, benchmarks

S/Wrequirements

Requirementvalidation

DesignV&V

Product

designDetaileddesign

Code

Unit test

IntegrationtestAcceptance

testService Develop, verifynext-level product

Evaluate alternativesidentify, resolve risks

Determine objectivesalternatives and

constraints

Plan next phase

Integrationand test plan

Developmentplan

Requirements planLife-cycle plan

REVIEW


14/29


Process is represented as a spiral rather than as asequence of activities with backtracking

Each loop in the spiral represents a phase in the process.

No fixed phases such as specification or design -- loopsin the spiral are chosen depending on what is required

Risks are explicitly assessed and resolved throughoutthe process.

Uses prototyping


15/29

User requirements are often expressedinformally: features

usage scenarios

Although requirements may be documented inwritten form, they may be incomplete,ambiguous, or even incorrect.



16/29

Requirements willchange! inadequately capturedor expressed in the first place

user and business needs may changeduring the project

Validation is needed throughoutthe softwarelifecycle, not only when the final system isdelivered! build constant feedbackinto your project plan

plan for change early prototyping[e.g., UI] can help clarify requirements



17/29

Analysis is the process of specifying whatasystem will do.

The intention is to provide a clear understanding

of what the system is about and what itsunderlying concepts are.

The result of analysis is a specification

document.


Does the requirementsspecification correspond tothe users actual needs?


18/29

An object-oriented analysisresults in models ofthe system which describe:

classesof objects that exist in the system responsibilitiesof those classes

relationshipsbetween those classes

use casesand scenariosdescribing operationsthat can be performed on the system

allowable sequencesof those operations



19/29


Implementation

Design

Testing

Design

Implementation

Testing

Maintenance

Requirements


20/29

A prototypeis a software program developed totest, explore or validate a hypothesis, i.e. toreduce risks.

An exploratory prototype, also known as athrowaway prototype, is intended to validaterequirementsor explore design choices. UI prototype validate user requirements

rapid prototype validate functional requirements experimental prototype validate technical

feasibility



21/29

An evolutionary prototypeis intended to evolvein steps into a finished product.

iteratively grow the application, redesigningand refactoringalong the way


First do it,then do it right,

then do it fast.


22/29

Designis the process of specifying howthespecified system behaviour will be realized fromsoftware components. The results arearchitectureand detailed design documents.

Object-oriented designdelivers models that describe: how system operations are implemented by

interacting objects how classes refer to one another and how they are

related by inheritance attributesand operationsassociated to classes


Design is an iterative process,proceeding in parallel withimplementation!


23/29

Organizations that design systems areconstrained to produce designs that are copies ofthe communication structures of theseorganizations



24/29

Implementationis the activity ofconstructingasoftware solution to the customersrequirements.

Testingis the process ofvalidatingthat thesolution meets the requirements.

The result of implementation and testing is a fully

documentedand validatedsolution.



25/29

Design, implementation and testing are iterativeactivities The implementation does not implement the

design, but rather the design documentdocuments the implementation!

System tests reflect the requirementsspecification

Testing and implementation go hand-in-hand Ideally, test case specification precedesdesign and

implementation



26/29

Maintenanceis the process of changing a systemafter it has been deployed.

Corrective maintenance: identifying andrepairing defects

Adaptive maintenance: adaptingthe existingsolution to new platforms Perfective maintenance: implementing new

requirements


In a spiral lifecycle, everything afterthe delivery and deployment of thefirst prototype can be considered

maintenance!


27/29

Maintenance entails: configuration and version management

reengineering (redesigning and refactoring)

updating all analysis, design and userdocumentation


Repeatable,automated testsenable evolutionand refactoring


28/29


EfficiencyImprovements

4%Documentation

6%

HardwareChanges

6%

RoutineDebugging

9%

EmergencyFixes12%

Changes inData Formats

17%

Other3%

Changes inUser

Requirements

Maintenance typicallyaccounts for 70% ofsoftware costs!

Means:mostproject costs

concern continued

development afterdeployment

Lientz 1979


29/29

First generation: Adaptation of existing notations (ER diagrams,

state diagrams ...): Booch, OMT, Shlaer and Mellor,...

Specialized design techniques: CRC cards; responsibility-driven design; design by contractSecond generation:

Fusion: Booch + OMT + CRC + formal methodsThird generation: Unified Modeling Language:

uniform notation: Booch + OMT + Use Cases + ...

various UML-based methods (e.g. Catalysis)

UCS503 S f E i i

ucs503 process models

Documents