sw life -cycle models

3.1/65

SWLIFE

-CYCLE MODELS

3.2/65Overview

The Product Progresses Steps, Build-and-fix (model?), Waterfall model, Rapid prototyping model, Incremental model, Synchronize-and-stabilize model, Spiral model, Object-oriented life-cycle models, Comparison of life-cycle models,

Open Source , Extreme Programming.

3.3/65


Open Source, Extreme Programming.

3.4/65The Product Progresses Phases:

כל דבר חי גדל או קמל(...וגם מוצרי תכנה, גם קבוצות עבודה...)

Requirements, Specification, Design, Implementation, Integration, Maintenance, Retirement ,

3.5/65



3.6/65Build and Fix (Model?) – בנה ותקן …

גרסה בנהראשונה

, שינויים ערוךשהלקוח עד

מרוצה

הפעלה מבצעית

פרישה

פיתוחאחזקה

3.7/65Build and Fix (Model?) …

3.8/65Build and Fix (Model?) (Cont’d)

Problems:– No specifications,– No design,

Totally unsatisfactory, Need life-cycle model:

– “Game plan”, – Phases,– Milestones,

Good for:– Tiny programs! ,

3.9/65


!Open Source, !Extreme Programming.

3.10/65Waterfall Model …

3.11/65Waterfall Model – מודל מפל המים …


פרישה

אימותדרישות

אימותאפיון

אימותתכן

אימותמימוש

אישורשילוב

אימותבדרישות שינוי


אימותתכנון

3.12/65Waterfall Model (Cont’d) …

Until the early 1980s, the waterfall model was the only widely accepted life-cycle model,

Characterized by:– Feedback loops,– Documentation-driven ,

Advantages: – Documentation, a lot of documentation,– Maintenance is much easier, – Clear milestones.

3.13/65Waterfall Model (Cont’d)

Disadvantages:– Specification documents are long, detailed, and boring,– Specifications, no prototype!. – Words VS picture,– The first time that the client sees a working product is

only after the entire product has been coded,

Will you buy a product by its detailed specification?– What about a suit?– What about a house?– What about an ice-cream?

3.14/65



3.15/65Rapid Prototyping Model …

Planning

3.16/65Three Key Points …

Do not turn prototype into product,demonstration only!,

Rapid prototyping may replace specification phase — never the design phase,

Comparison:– Waterfall model — try to get it right first time,– Rapid prototyping — frequent change, then discard!

3.17/65Rapid Prototype – מודל אב טיפוס מהיר …


אימותטיפוס- אב


פרישה


אימותתכן

אימותמימוש

שוראישילוב


אימות

בדרישות שינוי

3.18/65Rapid Prototyping Model (Cont’d) …

Linear model,

“Rapid”,

Phases shift is more smooth ,

The existence of the rapid prototype can help the team throughout the whole development process (even gaining the “how not to do it” insight.)

3.19/65Rapid Prototyping Model (Cont’d)

Will you live in a rapid prototyping model?,

3.20/65Waterfall VS Rapid Prototyping Models

Waterfall model:– Many successes,– Client needs,

Rapid prototyping model:– Not proved,– Has own problems,

Suggestion:– Rapid prototyping for requirements phase,– Waterfall for rest of life cycle ,

In waterfall, rapid prototyping models:– Operational quality complete product at end.

3.21/65



3.22/65Incremental Model …

3.23/65Incremental Model – מודל הדרגתי א' …



פרישה

מבנההקמת מימושמימושמימוש( build)

1,2,...,n

תכן מפורט

מימוש

שילוב

בדיקות

מסירה

אימותדרישות



מערכת מערכת הנדסת הנדסת

אימותארכיטקטורה

3.24/65Incremental Model (Cont’d) …

Divide project into: builds_01,

build_02,

…build_n,

For example, the first build of a nuclear submarine control system, can be the navigation system, the second will include weapons control system and so on ,


The developer is free to break up the target product into builds as he or she sees fit, subject only to the constraint that as each build is integrated into the existing SW, the resulting product must be testable.


Advantages: Operational quality portion of product within weeks, Less disappointment, Provides time for the client to adjust to the new

product, No difference between development and maintenance

phase, Smaller capital outlay, rapid return on investment , No need to complete the product in order to get ROI.


Problems: Need open architecture — maintenance

implications, Each new build is to be integrated into a working

model, Build-and-fix danger , Vague terms: whole product VS. Build

sequences.


More risky version — pieces may not fit.

3.29/65

אפיון

תכן

מימושושילוב

מסירה

2מבנה

ב אינקרמנטלי … 'מודל

אפיון

תכן


מסירה

אפיון אפיון קבוצת קבוצת

תכן תכן קבוצת קבוצת

מימוש מימוש קבוצת קבוצת

1מבנה

אפיון

תכן


מסירה

nמבנה

3.30/65Incremental Model (Cont’d)

Advantages:– One may start implementation before system

engineering is over,– Parallel teamwork ,

Problems:– Risky,– Harder to manage and synchronize,– Degradation into Build-and-fix.

3.31/65



3.32/65Synchronize-and Stabilize Model …

Microsoft’s life-cycle model,

Requirements analysis — interview potential customers,

Draw up specifications,

Divide project into 3 or 4 builds ,

Each build is carried out by small teams working in parallel.

3.33/65Synchronize-and Stabilize Model (Cont’d) …

At the end of the day — synchronize (test and debug),

At the end of the build — stabilize (freeze build),

Components always work together ,

Developers get early insights into operation of product and might change the requirements.

3.34/65



3.35/65Spiral Model …

Motivation – reduce risks ,

Possible risks:– Employees turnover,– Dependency upon HW delivery ,– Lower-priced product might appear.

3.36/65Spiral Model (Cont’d) …

Simplified form:– Waterfall model plus risk analysis,

Precede each phase by:– Define alternatives,– Risk analysis ,

Follow each phase by:– Evaluation,– Planning of next phase.

3.37/65Spiral Model (Cont’d) …

3.38/65Simplified Spiral Model …

Address the top risks at each phase (VS “solve what we already know” approach) ,

If risks cannot be resolved, project is immediately terminated.

3.39/65Spiral Model – מודל הספירלה …

תכנון תכנון planningplanning

סיכונים סיכונים ניתוח ניתוחrisk analysisrisk analysis

הנדסההנדסהengineeringengineering

לקוח לקוח הערכת הערכתcustomer evaluationcustomer evaluation

תוצרים

3.40/65Full Spiral Model (Next Slide) …

Radial dimension: cumulative cost to date,(L),

Angular dimension: progress through the spiral (,

L

3.41/65Full Spiral Model (Cont'd) …

3.42/65Analysis of the Spiral Model

Strengths:– Risk driven – “Tackle the worst first”,– Emphasis on alternatives and constrains,– Easy to judge how much to test,– No distinction between development, maintenance –

maintenance is simply another cycle of the spiral ,

Weaknesses:– For large-scale software only (how much does it cost to

perform risk analysis?),– For internal (in-house) software only (what if risk-

analysis shows that project should be terminated…).

3.43/65



3.44/65Object-Oriented Life-Cycle Models

Need for iteration within and between phases:– Fountain model,– Recursive/parallel life cycle,– Round-trip gestalt,

All incorporate some form of:– Iteration,– Parallelism,– Incremental development,

Danger:– CABTAB – Code A Bit Test A Bit ,

3.45/65Fountain Model …

3.46/65Fountain model – המזרקה … מודל

דרישות

- עצמים מונחה ניתוח

- עצמים מונחה תכן

מימוששילוב

מבצעית הפעלה

תחזוקההמשך פיתוח

” התוכנה“ ” מאגר התוכנה“ מאגר

הוא שלב כלבעצמו איטרטיבי

מכל התוצריםניתנים שלב

חוזר- לשימוש(reuse )בכל

השלבים

התחזוקה מאמץיותר קטן

3.47/65



3.48/65Life-Cycle Models Comparison

Model Strengths Weaknesses

Build & Fix Fine for short programs that willnot require any maintenance

Totally unsatisfactory fornontrivial projects

Waterfall Discipline approachDocument Driven

Product may not meet client’s needs

Ensures that delivered product

meet client’s needs

Requires focus-orientationprogrammers

Increment. Maximizes early ROIPromotes maintainability

Requires open architectureMay fall into build-and-fix

Synch. & Stabilize

Future users’ needs are metEnsures components can besuccessfully integrated

Lack of wide experience

SpiralIncorporate features ofall the above models

can be used only for large-scale,in house products, Developers have to be competent in risk analysis and risk resolution

Object

OrientedSupports iteration within phases,Parallelism between phases

May degenerate into CABTAB

RapidPrototype

3.49/65Conclusions

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,– Budget ,

Best suggestion:– “Mix-and-match” life-cycle model.

3.50/65



3.51/65Open Source …

The basic idea behind open source is very simple: When programmers can read, redistribute, and modify the source code, the SW evolves. People improve it, people adapt it, people fix bugs. And this can happen at a speed that, if one is used to the slow pace of conventional SW development, seems astonishing.

3.52/65Open Source Products (Cont’d) …

Building and porting more and better applications all the time at a pace closed developers cannot match,

The open source community have learned that this rapid evolutionary process produces better SW than the traditional closed model, in which only a very few programmers can see the source and everybody else must blindly use an opaque block of bits ,

Oracle, Informix, and InterBase databases. Word Perfect and the Corel office suite, ApplixWare and StarOffice suites.

3.53/65Open Source Products (Cont’d)

Go to the Linux Mall, for example, to learn about the wide selection of office suites and productivity tools now available under Linux ,

The Linux Business Solutions Project maintains a list of mainstream business applications available under Linux.

3.54/65



3.55/65Extreme Programming – XP …

XP has four main strands: listening, testing, coding, and designing, in no special order for they all happen in parallel,

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 task are drawn up first, Pair programming , Continuous integration of tasks.

3.56/65XP (Cont’d) …

"Find the essential elements of creating good software,do them all of the time, and discard everything else."

3.57/65XP Practices …

Planning Game:– Customers decide the scope and timing of releases based

on estimates provided by programmers. Programmers implement only the functionality demanded by the stories in this iteration,

Small releases:– The system is put into production in a few months, before

solving the whole problem. New releases are made often-anywhere from daily to monthly ,

Metaphor:– The shape of the system is defined by a metaphor or set of

metaphors shared between the customer and programmers. For example the Chrysler payroll system was built as a production line.

3.58/65XP Practices (Cont’d) …

Simple design:– At every moment, the design runs all the tests,

communicates everything the programmers want to communicate, contains no duplicate code, and has the fewest possible classes and methods. This rule can be summarized as, “Say everything once and only once.” ,

Tests:– Programmers write unit tests minute by minute.

These tests are collected and they must all run correctly. Customers write functional tests for the stories in an iteration. These tests should also all run, although practically speaking, sometimes a business decision must be made comparing the cost of shipping a known defect and the cost of delay.


Re-factoring: (פירוק לגורמים חוזר)– The design of the system is evolved through transformations

of the existing design that keep all the tests running,

Pair programming:– All production code is written by two people at one

screen/keyboard/mouse ,

Continuous integration:– New code is integrated with the current system after no

more than a few hours. When integrating, the system is built from scratch and all tests must pass or the changes are discarded.


Collective ownership:– Every programmer improves any code anywhere in the

system at any time if they see the opportunity, On-site customer:

– customer sits with the team full-time, 40-hour weeks:

– No one can work a second consecutive week of over-time. Even isolated overtime used too frequently is a sign of deeper problems that must be addressed ,

Open workspace:– The team works in a large room with small

cubicles around the periphery. Pair programmers work on computers set up in the center.

3.61/65XP Practices (Cont’d)

Just rules: – By being part of an Extreme team, you sign up to

follow the rules. But they're just the rules. The team can change the rules at any time as long as they agree on how they will assess the effects of the change.

3.62/65Evaluating XP

XP has had some successes,

Risky projects with dynamic requirements are perfect for XP ,

Too soon to evaluate XP.

3.63/65Summary



3.64/65

SWLIFE-CYCLE

MODELS

The End

3.65/65Disappointment…

sw life -cycle models

Documents