11Waterfall Model – מודל מפל המים … אימותדרישותאימותשינוי בדרישותאימותאפיוןאימותתכנוןאימותתכןאימותמימושאישורשילובפיתוחהפעלה מבצעיתאחזקהפרישה
12Waterfall 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.
13Waterfall 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?
16Three 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!
17Rapid Prototype – מודל אב טיפוס מהיר … אימותשינוי בדרישותאימותאב-טיפוסהפעלה מבצעיתפרישהאימותאפיוןתכןמימושאישורשילובתכנוןפיתוחאחזקה
18Rapid 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.)
19Rapid Prototyping Model (Cont’d) Will you live in a rapid prototyping model?,
20Waterfall 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.
23Incremental Model – מודל הדרגתי א' … אימותדרישותאפיוןתכנוןהנדסת מערכתארכיטקטורההפעלה מבצעיתפרישהמימושהקמת מבנה (build)1,2,...,nתכן מפורטשילובבדיקותמסירהפיתוחאחזקה
24Incremental 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 ,
25Incremental 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.
26Incremental 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.
27Incremental 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.
28Incremental Model (Cont’d) … More risky version — pieces may not fit.
29מודל אינקרמנטלי ב' … מבנה 1 מבנה 2 מבנה n קבוצת אפיון קבוצת תכן מימושושילובמסירהמבנה 1אפיוןתכןמימושושילובמסירהמבנה 2אפיוןתכןמימושושילובמסירהמבנה nקבוצת אפיוןקבוצת תכןקבוצת מימוש
30Incremental 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.
32Synchronize-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.
33Synchronize-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.
42Analysis 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…).
44Object-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 ,
46Fountain model – מודל המזרקה … תחזוקהמאמץ התחזוקה קטן יותרפיתוח המשךהפעלה מבצעיתכל שלב הוא איטרטיבי בעצמושילובהתוצרים מכל שלב ניתנים לשימוש-חוזר (reuse) בכל השלביםמימושתכן מונחה-עצמיםניתוח מונחה-עצמיםדרישות“מאגר” התוכנה
48Life-Cycle Models Comparison StrengthsWeaknessesFine for short programs that willnot require any maintenanceTotally unsatisfactory for nontrivial projectsBuild & FixDiscipline approach Document DrivenProduct may not meet client’s needsWaterfallRapid PrototypeEnsures that delivered productmeet client’s needsRequires focus-orientationprogrammersMaximizes early ROI Promotes maintainabilityIncrement.Requires open architecture May fall into build-and-fixFuture users’ needs are met Ensures components can be successfully integratedSynch. & StabilizeLack of wide experiencecan be used only for large-scale, in house products, Developers have to be competent in risk analysis and risk resolutionIncorporate features of all the above modelsSpiralObjectOrientedSupports iteration within phases, Parallelism between phasesMay degenerate into CABTAB
49Conclusions 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.
51Open 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.
52Open 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.
53Open 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.
55Extreme 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.
56XP (Cont’d) … "Find the essential elements of creating good software, do them all of the time, and discard everything else."
57XP 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.
58XP 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.
59XP 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.
60XP 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.
61XP 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.
62Evaluating XP XP has had some successes, Risky projects with dynamic requirements are perfect for XP ,Too soon to evaluate XP.