1. SW
LIFE -CYCLE
MODELS

2. Overview 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. 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.

4. The Product Progresses Phases:
Requirements,
Specification,
Design,
Implementation,
Integration,
Maintenance,
Retirement ,
כל דבר חי גדל או קמל (...וגם מוצרי תכנה, גם קבוצות עבודה...)

5. 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.

6. Build and Fix (Model?) – בנה ותקן …
בנה גרסה ראשונה
ערוך שינויים, עד שהלקוח מרוצה
הפעלה מבצעית
פרישה
פיתוח
אחזקה

7. Build and Fix (Model?) …

8. Build and Fix (Model?) (Cont’d)
Problems:
No specifications,
No design,
Totally unsatisfactory,
Need life-cycle model:
“Game plan”,
Phases,
Milestones,
Good for:
Tiny programs! ,

9. 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.

10. Waterfall Model …

11. Waterfall Model – מודל מפל המים …
אימות
דרישות
אימות
שינוי בדרישות
אימות
אפיון
אימות
תכנון
אימות
תכן
אימות
מימוש
אישור
שילוב
פיתוח
הפעלה מבצעית
אחזקה
פרישה

12. Waterfall 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.

13. Waterfall 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?

14. 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.

15. Rapid Prototyping Model …
Planning

16. Three 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!

17. Rapid Prototype – מודל אב טיפוס מהיר …
אימות
שינוי בדרישות
אימות
אב-טיפוס
הפעלה מבצעית
פרישה
אימות
אפיון
תכן
מימוש
אישור
שילוב
תכנון
פיתוח
אחזקה

18. Rapid 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.)

19. Rapid Prototyping Model (Cont’d)
Will you live in a rapid prototyping model?,

20. Waterfall 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.

21. 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.

22. Incremental Model …

23. Incremental Model – מודל הדרגתי א' …
אימות
דרישות
אפיון
תכנון
הנדסת מערכת
ארכיטקטורה
הפעלה מבצעית
פרישה
מימוש
הקמת מבנה (build)
1,2,...,n
תכן מפורט
שילוב
בדיקות
מסירה
פיתוח
אחזקה

24. Incremental 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 ,

25. Incremental Model (Cont’d) …
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.

26. Incremental Model (Cont’d) …
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.

27. Incremental Model (Cont’d) …
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.

28. Incremental Model (Cont’d) …
More risky version — pieces may not fit.

29. מודל אינקרמנטלי ב' … מבנה 1 מבנה 2 מבנה n קבוצת אפיון קבוצת תכן
מימוש
ושילוב
מסירה
מבנה 1
אפיון
תכן
מימוש
ושילוב
מסירה
מבנה 2
אפיון
תכן
מימוש
ושילוב
מסירה
מבנה n
קבוצת אפיון
קבוצת תכן
קבוצת מימוש

30. Incremental 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.

31. 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.

32. Synchronize-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.

33. Synchronize-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.

34. 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.

35. Spiral Model … Motivation – reduce risks , Possible risks:
Employees turnover,
Dependency upon HW delivery ,
Lower-priced product might appear.

36. Spiral 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.

37. Spiral Model (Cont’d) …

38. Simplified 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.

39. Spiral Model – מודל הספירלה …
תכנון
planning
ניתוח סיכונים
risk analysis
תוצרים
הערכת לקוח
customer evaluation
הנדסה
engineering

40. Full Spiral Model (Next Slide) …
Radial dimension: cumulative cost to date, (L),
Angular dimension: progress through the spiral (a) , L a

41. Full Spiral Model (Cont'd) …

42. Analysis 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…).

43. 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.

44. Object-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 ,

45. Fountain Model …

46. Fountain model – מודל המזרקה …
תחזוקה
מאמץ התחזוקה קטן יותר
פיתוח המשך
הפעלה מבצעית
כל שלב הוא איטרטיבי בעצמו
שילוב
התוצרים מכל שלב ניתנים לשימוש-חוזר (reuse) בכל השלבים
מימוש
תכן מונחה-עצמים
ניתוח מונחה-עצמים
דרישות
“מאגר” התוכנה

47. 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.

48. Life-Cycle Models Comparison
Strengths
Weaknesses
Fine for short programs that will
not require any maintenance
Totally unsatisfactory for nontrivial projects
Build & Fix
Discipline approach Document Driven
Product may not meet client’s needs
Waterfall
Rapid Prototype
Ensures that delivered product
meet client’s needs
Requires focus-orientation
programmers
Maximizes early ROI Promotes maintainability
Increment.
Requires open architecture May fall into build-and-fix
Future users’ needs are met Ensures components can be successfully integrated
Synch. & Stabilize
Lack of wide experience
can be used only for large-scale, in house products, Developers have to be competent in risk analysis and risk resolution
Incorporate features of all the above models
Spiral
Object
Oriented
Supports iteration within phases, Parallelism between phases
May degenerate into CABTAB

49. Conclusions 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.

50. 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.

51. Open 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.

52. Open 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.

53. Open 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.

54. 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.

55. Extreme 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.

56. XP (Cont’d) … "Find the essential elements of creating good software,
do them all of the time, and discard everything else."

57. XP Practices … Planning Game: Small releases: Metaphor:
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.

58. XP 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.

59. XP Practices (Cont’d) …
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.

60. XP Practices (Cont’d) …
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.

61. XP 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.

62. Evaluating XP XP has had some successes,
Risky projects with dynamic requirements are perfect for XP ,
Too soon to evaluate XP.

63. Summary 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.

64. SW
LIFE-CYCLE
MODELS
The End

65. Disappointment…