Life-cycle model (formerly, process model)

The steps through which the product progresses◦ Requirements phase◦ Specification phase◦ Design phase◦ Implementation phase◦ Integration phase◦ Maintenance phase◦ Retirement

Build-and-fix model Waterfall model Rapid prototyping model Incremental model Extreme programming Synchronize-and-stabilize model Spiral model V model Object-oriented life-cycle models Comparison of life-cycle models

Product is constructed with no specifications

Problems◦ No specifications◦ No design

Totally unsatisfactory Need life-cycle model

◦ “Game plan” ◦ Phases◦ Milestones

Disadvantages◦ Cost: changes are made in the later phases of

software development life cycle◦ Maintenance is difficult

Requirements determined and checked by the client and SQA group.

Specifications drawn Specification checked by

the SQA group and shown to the client.

Sign off the specification document,

Software project management plan - checked by SQA group

Design -“how to do”. If some problems in specification (Incomplete, contradictory and ambiguous.)◦ Incomplete-: some features of the

product have been omitted.◦ Contradictory-: two or more

statements in the specification document differ.

◦ Ambiguous-: the specification document has more than one possible interpretation.

Implementation:If flaws-- Feedback loops permits modification to be made to design document, specification document and requirement if needed.

Documentation :No phase without documentation Also approved by SQA group.

Acceptance Testing: when the product is completed it is given to the client for testing. Deliverables at this stage include the user manual and other documentation listed in the contract. When the client agrees that that the product is as per the specification document, the product is installed on the client’s machine.

Installation Maintenance- changes made

after the installation of the product are handled in this phase.

Characterized by◦ Feedback loops◦ Documentation-driven

Advantages ◦ Enforce the documentation after every phase ◦ Products of each phase checked by SQA.◦ Testing is Inherent in every phase ◦ Dynamic model-feedback loops◦ Maintenance easier

Disadvantages◦ Specification documents are long, detailed and

very boring to read.◦ Client is inexperienced in reading software

specification document because the specification document is written in the style client won’t understand.

◦ The first time the client see a working product is only after the entire product has been coded.

Build a rapid prototype The client and future users interact and experiment with it. Once the client is satisfied, the developer can draw up

specification document. The feedback loops are not required in this model as the

working prototype has been validated by the client, it is reasonable to expect that the resulting specification document will be correct.

.

In the rapid prototyping model, the fact that a preliminary working model has been built tends to lessen the need to repair the design during or after the implementation.

Rapid◦ Construct the prototype as rapidly as possible ◦ The developers should develop the rapid prototype as

rapidly as possible the speed up the software development process.

◦ Use of rapid prototype - determine what the client’s real needs are;

◦ Rapid prototype implementation is discarded ◦ Internal structure of rapid prototype is not relevant.◦ Prototype is modified rapidly to reflect client need.

Waterfall model◦ Many successes◦ Client needs

Rapid prototyping model◦ Not proved ◦ Has own problems

Solution◦ Rapid prototyping for requirements

phase◦ Waterfall for rest of life cycle

Advantages As compared to waterfall model –

◦ Development of the process is linear preceding from rapid prototype to delivered product.

◦ Feedback loops are less likely to be (needed) in this case.

Disadvantages ◦ If user cannot be involved throughout the life cycle

this model is not useful.◦ Development time may not be reduced if reusable

components are not available.◦ Highly specialized and skilled developers are

expected and such developers may not be available easily.

◦ Client expects changes to made as rapidly as the rapid prototype

The product is designed, implemented, integrated and tested as a series of incremental builds, where a build consist of code pieces from various modules interacting to provide a specific functional capability.

At each stage- a new build is coded and then integrated and tested as a whole.

Break up the target product into builds subject to constraint that each build is integrated into existing software, the resulting product must be testable.

If a product has too many builds, then at each stage, considerable time is spent in the integration testing of only a small amount of additional functionality. On the other hand, if a product has too few build then the incremental model degenerated into build and fix model.

Analysis – In waterfall and rapid prototyping model –

◦ deliver to client a complete product ◦ There is project delivery date

Incremented Model – It deliver an operational quality product at each stage

Advantages◦ Gradual introduction of the product via this

model provides time for the client to adjust to the new product.

◦ Change and Adoptions are natural

Disadvantages ◦ Each additional build has to be incorporated into existing

structure without destroying what has been made till date.

◦ Addition of new build should be simple and straightforward.

◦ Incremental model does not distinguish between developing a product and maintaining it.

◦ Begin with a design that support entire product◦ View product as a sequence of builds, each independent

of next.

More risky concurrent version—pieces may not fit

Somewhat controversial new approach Software development team determines the

various features (Stories) Estimate duration and cost of each feature Client select features for next build using cost

benefit analysis Each build is divided into tasks Test cases for task are drawn up first Pair programming (working with a partner on

one screen) Continuous integration of tasks

Tasks are integrated into the current version of the product

Test cases used for the tasks are retained and utilized in all further integration testing

Computers are put in center of large room lined with small cubicles

Client representative is always present No individual can work overtime for 2 successive weeks No specialization. All members of XP team work on

specifications, design, code and testing There is no overall design is modified while the product

is being built. The design is modified while product is being built. This procedure is known as refactoring

XP has had some successes on small and medium sized projects

Good when requirements are vague or changing

Too soon to evaluate XP

Microsoft’s life-cycle model Requirements analysis—interview potential

customers and extract a list of features with priorities set up by the customers

Draw up specifications Divide project into 3 or 4 builds First build consists of the most critical features,

the second build consists of the next most critical features and so on.

Each build is carried out by small teams working in parallel

At the end of the day all the teams—put together the partially completed components and synchronize (test and debug)

At the end of the build—stabilize (freeze build i.e. any remaining faults that have been detected are fixed).

Repeated synchronization steps ensure that the components always work together◦ Developers get early insights into operation of product and

can modify the requirements

Simplified form◦ Waterfall model

plus risk analysis Precede each

phase by◦ Alternatives◦ Risk analysis

Follow each phase by◦ Evaluation◦ Planning of next

phase

If risks cannot be resolved, project is immediately terminated

Prototypes can be effectively used to provide information about certain classes of risks

Represents cumulative cost to date and progress through the spiral Each cycle of the spiral corresponds to a phase Phase begins by determining objectives of that phase, alternatives

for achieving those objectives, and constraints imposed on these alternatives

Strategy is analyzed from view point of risk If all risks are successfully resolved development starts Then the results of the phase are evaluated

Strengths◦ Incorporation of software quality◦ Easy to judge how much to test as risks for too

much and too low testing are analyzed◦ No distinction between development,

maintenance i.e. maintenance is treated same way as development

Weaknesses◦ For large-scale software only. In case of contract

all risk analysis should be made before the contract is signed.

◦ Skilled developers are required for analyzing and detecting potential risks

◦ For internal (in-house) software only

Need for iteration within and between phases◦ Fountain model◦ Recursive/parallel life cycle◦ Round-trip gestalt◦ Unified software development process

All incorporate some form of◦ Iteration◦ Parallelism◦ Incremental development

Features Overlap

(parallelism) Arrows (iteration) Smaller

maintenance circle

37

V Shaped Software Life V Shaped Software Life cycle Modelcycle Model• There is a shift in testing activities from validation to verification where

we want to review/inspect every activity of software development life cycle.

• These verification activities are treated as error preventive exercises and are applied at requirements analysis and specification phase, high level design, detailed design phase, implementation phase.

• We not only want to improve the quality of end products of all phases but also want to design test cases and test plans during these phases.

V shaped model is the modified form of waterfall model with a special focus on testing activities at every phase.

38

V Shaped Software Life V Shaped Software Life cycle Modelcycle Model

Requirements Analysis and Specification

Acceptance Testing

High level design System testing

Detailed design Unit and Integration testing

Implementation

A

B

CDevelopmen

t Part

Testing Part

A: Acceptance test cases design and planningB: System test cases design and planningC: Unit and integration test cases design and planning

39

V Shaped Software Life V Shaped Software Life cycle Modelcycle Model• The model brings the quality into the development of our products

• The encouragement of writing test cases and test plans in the early phases of software development life cycle is the real strength of this model.

• We require more resources to implement this model as compared to waterfall model.

LIMITATIONS

• This model suffers from many disadvantages of waterfall model like non availability of working version of the product until late in the life cycle, difficult to accommodate any change etc. this model has also limited applications in today’s iterative software processes

Different life-cycle models Each with own strengths Each with own weaknesses Criteria for deciding on a model

include◦ The organization◦ Its management◦ Skills of the employees◦ The nature of the product

Best suggestion◦ “Mix-and-match” life-cycle model

Life cycle model Strengths Weaknesses

Build and fix Fine for short programs that will not require any maintenance

Totally unsatisfactory for nontrivial programs

Waterfall model Disciplined approach Document driven

Delivered product may not meet client’s needs

Rapid prototype model

Ensure that delivered product meets client’s needs

Not yet proven beyond all doubt

Incremental model Maximizes early return on investmentPromotes maintainability

Requires open architectureMay degenerate into build-and-fix

Life cycle model Strengths Weaknesses

Extreme programming

Maximizes early return on investmentWorks well when client’s requirement are vague

Has not yet been widely used

Synchronize and stablize model

Future user’s needs are metEnsures components can be successfully integrated

Has not been widely used other than Microsoft

Spiral model Incorporates features of all the models

Can be used only for large scale in-house productsDevelopers have to be competent in risk analysis and risk resolution

Life cycle model Strengths Weaknesses

V shaped model Incorporates testing at each phase

Usable product will be deliver very late

Object-oriented models

Support iteration within phases, parallelism between phases

May degenerate into code a bit test a bit (CABTAB)