2. Software Life Cycle Models

(1)

2. Software Life Cycle Models

(2)

Software Engineering

Overview

Software development in theory Iteration and incrementation

Risks and other aspects of iteration and incre mentation

Managing iteration and incrementation Other life-cycle models

Comparison of life-cycle models

(3)

2.1 Software Development in Theory

Ideally, software is developed as described in Chapter 1

• Linear

• Starting from scratch

(4)

Software Development in Practice

In the real world, software development is totall y different

• We make mistakes

• The client’s requirements change while the software product is being developed

(5)

Waterfall Model

The linear life cycle model with fe edback loops

• The waterfall model cannot show the order of events

(6)

Iteration and Incrementation

In real life, we cannot speak about “the analysis phase”

• Instead, the operations of the analysis phase are spr ead out over the life cycle

The basic software development process is iter ative

• Each successive version is intended to be closer to it s target than its predecessor

(7)

Miller’s Law

At any one time, we can concentrate on only ap proximately seven chunks (units of information) To handle larger amounts of information, use st epwise refinement

• Concentrate on the aspects that are currently the mo st important

• Postpone aspects that are currently less critical

• Every aspect is eventually handled, but in order of c urrent importance

This is an incremental process

(8)

Iteration and Incrementation (contd)

Figure 2.4

(9)

Iteration and incrementation are used in conjunction with o ne another

• There is no single “requirements phase” or “design phase”

• Instead, there are multiple instances of each phase

(10)

The number of increments will vary — it does n ot have to be four

(11)

Classical Phases versus Workflows

Sequential phases do not exist in the real world

Instead, the five core workflows (activities) are performed over the entire life cycle

• Requirements workflow

• Analysis workflow

• Design workflow

• Implementation workflow

• Test workflow

(12)

Workflows

All five core workflows are performed over the entire life cycle

However, at most times one workflow predominates Examples:

• At the beginning of the life cycle

• The requirements workflow predominates

• At the end of the life cycle

• The implementation and test workflows predominate

Planning and documentation activities are performe d throughout the life cycle

(13)

Iteration is performed during each incrementation

Figure 2.5

(14)

Again, the number of iterations will vary—it is n ot always three

(15)

More on Incrementation (contd)

Each episode corresponds to an increment Not every increment includes every workflow Increment B was not completed

Dashed lines denote maintenance

(16)

2.7 Risks and Other Aspects of Iter. and Increm.

We can consider the project as a whole as a set of mini projects (increments)

Each mini project extends the

• Requirements artifacts

• Analysis artifacts

• Design artifacts

• Implementation artifacts

• Testing artifacts

The final set of artifacts is the complete product

(17)

Risks and Other Aspects of Iter. and Increm. (contd) During each mini project we

• Extend the artifacts (incrementation);

• Check the artifacts (test workflow); and

• If necessary, change the relevant artifacts (iteration)

(18)

Risks and Other Aspects of Iter. and Increm. (contd) Each iteration can be viewed as a small but co

mplete waterfall life-cycle model

During each iteration we select a portion of the software product

On that portion we perform the

• Classical requirements phase

• Classical analysis phase

• Classical design phase

• Classical implementation phase

(19)

Strengths of the Iterative-and-Incremental Model There are multiple opportunities for checking th at the software product is correct

• Every iteration incorporates the test workflow

• Faults can be detected and corrected early

The robustness of the architecture can be deter mined early in the life cycle

• Architecture — the various component modules and how they fit together

• Robustness — the property of being able to handle extensions and changes without falling apart

(20)

Strengths of the Iterative-and-Incremental Model (co ntd)

We can mitigate (resolve) risks early

• Risks are invariably involved in software developme nt and maintenance

We have a working version of the software prod uct from the start

• The client and users can experiment with this versio n to determine what changes are needed

Variation: Deliver partial versions to smooth the introduction of the new product in the client orga nization

(21)

There is empirical evidence that the life-cycle m odel works

The CHAOS reports of the Standish Group (see overleaf) show that the percentage of successfu l products increases

(22)

CHAOS reports from 19 94 to 2 006

Figure 2.7

(23)

Reasons given for the decrease in successful pr ojects in 2004 include:

• More large projects in 2004 than in 2002

• Use of the waterfall model

• Lack of user involvement

• Lack of support from senior executives

(24)

Managing Iteration and Incrementation

The iterative-and-incremental life-cycle model is as regimented as the waterfall model …

… because the iterative-and-incremental life-cy cle model is the waterfall model, applied succes sively

Each increment is a waterfall mini project

(25)

Other Life-Cycle Models

The following life-cycle models are presented a nd compared:

• Code-and-fix life-cycle model

• Waterfall life-cycle model

• Rapid prototyping life-cycle model

• Open-source life-cycle model

• Agile processes

• Synchronize-and-stabilize life-cycle model

• Spiral life-cycle model

(26)

Code-and-Fix Model

No design

No specificatio ns

• Maintenance nightmare

Figure 2.8

(27)

Code-and-Fix Model (contd) The easiest way to develop software The most expensive way

(28)

Waterfall Model

Figure 2.9

(29)

Waterfall Model (contd) Characterized by

• Feedback loops

• Documentation-driven

Advantages

• Documentation

• Maintenance is easier

Disadvantages

• Specification document

• Joe and Jane Johnson

• Mark Marberry

(30)

Rapid Prototyping Model Linear m

odel

“Rapid”

Figure 2.10

(31)

Open-Source Life-Cycle Model

Two informal phases

First, one individual builds an initial version

• Made available via the Internet (e.g., SourceForge.ne t)

Then, if there is sufficient interest in the project

• The initial version is widely downloaded

• Users become co-developers

• The product is extended

Key point: Individuals generally work voluntarily on an open-source project in their spare time

(32)

The Activities of the Second Informal Phase Reporting and correcting defects

• Corrective maintenance

Adding additional functionality

• Perfective maintenance

Porting the program to a new environment

• Adaptive maintenance

The second informal phase consists solely of po stdelivery maintenance

• The word “co-developers” on the previous slide shou ld rather be “co-maintainers”

(33)

Open-Source Life-Cycle Model (contd) Postdelivery maintenance life-cycle model

Figure 2.11

(34)

Open-Source Life-Cycle Model (contd)

Closed-source software is maintained and teste d by employees

• Users can submit failure reports but never fault repor ts (the source code is not available)

Open-source software is generally maintained b y unpaid volunteers

• Users are strongly encouraged to submit defect repo rts, both failure reports and fault reports

(35)

Open-Source Life-Cycle Model (contd) Core group

• Small number of dedicated maintainers with the incli nation, the time, and the necessary skills to submit f ault reports (“fixes”)

• They take responsibility for managing the project

• They have the authority to install fixes

Peripheral group

• Users who choose to submit defect reports from tim e to time

(36)

New versions of closed-source software are typi cally released roughly once a year

• After careful testing by the SQA group

The core group releases a new version of an op en-source product as soon as it is ready

• Perhaps a month or even a day after the previous ve rsion was released

• The core group performs minimal testing

• Extensive testing is performed by the members of th e peripheral group in the course of utilizing the softw are

• “Release early and often”

(37)

An initial working version is produced when usin g

• The rapid-prototyping model;

• The code-and-fix model; and

• The open-source life-cycle model

Then:

• Rapid-prototyping model

• The initial version is discarded

• Code-and-fix model and open-source life-cycle mod el

• The initial version becomes the target product

(38)

Consequently, in an open-source project, there are generally no specifications and no design How have some open-source projects been so successful without specifications or designs?

(39)

Open-source software production has attracted some of the world’s finest software experts

• They can function effectively without specifications o r designs

However, eventually a point will be reached wh en the open-source product is no longer maintai nable

(40)

The open-source life-cycle model is restricted in its applicability

It can be extremely successful for infrastructure projects, such as

• Operating systems (Linux, OpenBSD, Mach, Darwi n)

• Web browsers (Firefox, Netscape)

• Compilers (gcc)

• Web servers (Apache)

• Database management systems (MySQL)

(41)

There cannot be open-source development of a software product to be used in just one commer cial organization

• Members of both the core group and the periphery a re invariably users of the software being developed

The open-source life-cycle model is inapplicable unless the target product is viewed by a wide ra nge of users as useful to them

(42)

About half of the open-source projects on the W eb have not attracted a team to work on the proj ect

Even where work has started, the overwhelming preponderance will never be completed

But when the open-source model has worked, it has sometimes been incredibly successful

• The open-source products previously listed have be en utilized on a regular basis by millions of users

(43)

Agile Processes

Somewhat controversial new approach Stories (features client wants)

• Estimate duration and cost of each story

• Select stories for next build

• Each build is divided into tasks

• Test cases for a task are drawn up first

Pair programming

Continuous integration of tasks

(44)

Unusual Features of XP

The computers are put in the center of a large r oom lined with cubicles

A client representative is always present

Software professionals cannot work overtime fo r 2 successive weeks

No specialization

Refactoring (design modification)

(45)

Acronyms of Extreme Programming

YAGNI (you aren’t gonna need it)

DTSTTCPW (do the simplest thing that could po ssibly work)

A principle of XP is to minimize the number of fe atures

• There is no need to build a product that does any m ore than what the client actually needs

(46)

Agile Processes

XP is one of a number of new paradigms collect ively referred to as agile processes

Seventeen software developers (later dubbed th e “Agile Alliance”) met at a Utah ski resort for tw o days in February 2001 and produced the Mani festo for Agile Software Development

The Agile Alliance did not prescribe a specific lif e-cycle model

• Instead, they laid out a group of underlying principles

(47)

Agile Processes

Agile processes are a collection of new paradig ms characterized by

• Less emphasis on analysis and design

• Earlier implementation (working software is consider ed more important than documentation)

• Responsiveness to change

• Close collaboration with the client

(48)

Agile Processes (contd) A principle in the Manifesto is

• Deliver working software frequently

• Ideally every 2 or 3 weeks

One way of achieving this is to use timeboxing

• Used for many years as a time-management techniq ue

A specific amount of time is set aside for a task

• Typically 3 weeks for each iteration

• The team members then do the best job they can du ring that time

(49)

Agile Processes (contd)

It gives the client confidence to know that a new version with additional functionality will arrive ev ery 3 weeks

The developers know that they will have 3 week s (but no more) to deliver a new iteration

• Without client interference of any kind

If it is impossible to complete the entire task in t he timebox, the work may be reduced (“descop ed”)

• Agile processes demand fixed time, not fixed feature s

(50)

Another common feature of agile processes is s tand-up meetings

• Short meetings held at a regular time each day

• Attendance is required

Participants stand in a circle

• They do not sit around a table

• To ensure the meeting lasts no more than 15 minute s

(51)

At a stand-up meeting, each team member in tu rn answers five questions:

• What have I done since yesterday’s meeting?

• What am I working on today?

• What problems are preventing me from achieving thi s?

• What have we forgotten?

• What did I learn that I would like to share with the te am?

(52)

Agile Processes (contd) The aim of a stand-up meeting is

• To raise problems

• Not solve them

Solutions are found at follow-up meetings, prefe rably held directly after the stand-up meeting

(53)

Stand-up meetings and timeboxing are both

• Successful management techniques

• Now utilized within the context of agile processes

Both techniques are instances of two basic prin ciples that underlie all agile methods:

• Communication; and

• Satisfying the client’s needs as quickly as possible

(54)

Evaluating Agile Processes

Agile processes have had some successes with s mall-scale software development

• However, medium- and large-scale software developm ent are completely different

The key decider: the impact of agile processes on postdelivery maintenance

• Refactoring is an essential component of agile process es

• Refactoring continues during maintenance

• Will refactoring increase the cost of post-delivery maint enance, as indicated by preliminary research?

(55)

Evaluating Agile Processes (contd)

Agile processes are good when requirements a re vague or changing

In 2000, Williams, Kessler, Cunningham, and J effries showed that pair programming leads to

• The development of higher-quality code,

• In a shorter time,

• With greater job satisfaction

(56)

In 2007, Arisholm, Gallis, Dybå, and Sjøberg perf ormed an extensive experiment

• To evaluate pair programming within the context of soft ware maintenance

In 2007, Dybå et al. analyzed 15 published studie s

• Comparing the effectiveness of individual and pair prog ramming

Both groups came to the same conclusion

• It depends on both the programmer's expertise and th e complexity of the software product and the tasks to b e solved

(57)

The Manifesto for Agile Software Development claims that agile processes are superior to mor e disciplined processes like the Unified Process Skeptics respond that proponents of agile proc esses are little more than hackers

However, there is a middle ground

• It is possible to incorporate proven features of agile processes within the framework of disciplined proce sses

(58)

Evaluating Agile Processes (contd) In conclusion

• Agile processes appear to be a useful approach to building small-scale software products when the clie nt’s requirements are vague

• Also, some of the proven features of agile processe s can be effectively utilized within the context of oth er life-cycle models

(59)

Spiral Model Simplified for

m

• Rapid prototy ping model pl us risk analy sis preceding each phase

Figure 2.12

(60)

A Key Point of the Spiral Model

If all risks cannot be mitigated, the project is immediately terminated

(61)

Full Spiral Model Precede each phase by

• Alternatives

• Risk analysis

Follow each phase by

• Evaluation

• Planning of the next phase

Radial dimension: cumulative cost to date

Angular dimension: progress through the spiral

(62)

Full Spiral Model (contd)

Figure 2.13

(63)

Analysis of the Spiral Model Strengths

• It is easy to judge how much to test

• No distinction is made between development an d maintenance

Weaknesses

• For large-scale software only

• For internal (in-house) software only

(64)

2.10 Comparison of Life-Cycle Models

Different life-cycle models have been presente d

• Each with its own strengths and weaknesses

Criteria for deciding on a model include:

• The organization

• Its management

• The skills of the employees

• The nature of the product

Best suggestion

• “Mix-and-match” life-cycle model

(65)

Comparison of Life-Cycle Models (contd)

(66)

Thanks

[email protected]