Process Models Projects Process Typical Student Process Model Common Process Models Waterfall Model
Total Page：16
File Type：pdf, Size：1020Kb
Process Models Projects Process If a project chooses a model, it will generally tailor it A process model specifies a general to suit the project process, usually as a set of stages This produces the spec for the projects process This model will be suitable for a class of This process can then be followed in the project i.e. process is what is actually executed; process spec projects is plan about what should be executed; process i.e. a model provides generic structure model is a generic process spec Many models have been proposed for the of the process that can be followed by development process some projects to achieve their goals CSIS0521 Process Models 1 CSIS0521 Process Models 2 Typical Student Process Model Common Process Models Get problem statement – code – do Waterfall – the oldest and widely used some testing – deliver/demo Prototyping Why this process model cannot be used Iterative – currently used widely for commercial projects? Timeboxing Cannot ensure desired quality for industrial-strength software CSIS0521 Process Models 3 CSIS0521 Process Models 4 Waterfall Model Linear sequence of stages/phases Requirements – System Design – Detailed Design – Code – Test – Deploy A phase starts only when the previous has completed; no feedback The phases partition the project, each addressing a separate concern CSIS0521 Process Models 5 CSIS0521 Process Models 6 1 Waterfall… Waterfall Advantages Linear ordering implies each phase should Conceptually simple, cleanly divides the have some output problem into distinct phases that can be The output must be validated/certified performed independently Outputs of earlier phases: work products Natural approach for problem solving Common outputs of a waterfall: SRS Easy to administer in a contractual (Software Requirement Specification), setup – each phase is a milestone project plan, design docs, test plan and reports, final code, supporting docs CSIS0521 Process Models 7 CSIS0521 Process Models 8 Waterfall disadvantages Waterfall Usage Assumes that requirements can be Has been used widely specified and frozen early Well suited for projects where May fix hardware and other requirements can be understood easily technologies too early and technology decisions are easy all or nothing delivery; too risky i.e. for familiar type of projects it still Very document oriented, requiring docs may be the most optimum at the end of each phase CSIS0521 Process Models 9 CSIS0521 Process Models 10 Prototyping Prototyping Prototyping addresses the requirement specification limitation of waterfall Instead of freezing requirements only by discussions, a prototype is built to understand the requirements Helps alleviate the requirements risk A small waterfall model replaces the requirements stage CSIS0521 Process Models 11 CSIS0521 Process Models 12 2 Prototyping Prototyping Development of prototype Cost can be kept low Starts with initial requirements Build only features needing clarification “quick and dirty” – quality not important, Only key features which need better understanding are included in prototype scripting etc can be used Things like exception handling, recovery, No point in including those features that standards are omitted are well understood Cost can be a few % of the total Feedback from users taken to improve the Learning in prototype building will help in understanding of the requirements building, besides improved requirements CSIS0521 Process Models 13 CSIS0521 Process Models 14 Prototyping Iterative Development Advantages: requirements will be more stable Counters the “all or nothing” drawback of the and frozen later, experience helps in the main waterfall model development Combines benefit of prototyping and waterfall Disadvantages: Potential hit on cost and Develop and deliver software in increments schedule Each increment is complete in itself Applicability: When requirements are hard to Can be viewed as a sequence of waterfalls elicit and confidence in requirements is low; i.e. where requirements are not well Feedback from one iteration is used in the understood future iterations CSIS0521 Process Models 15 CSIS0521 Process Models 16 Iterative Enhancement Iterative Development Products almost always follow it Used commonly in customized development also Businesses want quick response for sw Cannot afford the risk of all-or-nothing CSIS0521 Process Models 17 CSIS0521 Process Models 18 3 Iterative Development Timeboxing Benefits: Get-as-you-pay, feedback for Iterative is linear sequence of iterations improvement, Each iteration is a mini waterfall – Drawbacks: Architecture/design may decide the specs, then plan the iteration not be optimal, rework may increase, Time boxing – fix an iteration duration, total cost may be more then determine the specs Applicability: where response time is Divide iteration in a few equal stages important, risk of long projects cannot Use pipelining concepts to execute be taken, all requirements not known iterations in parallel CSIS0521 Process Models 19 CSIS0521 Process Models 20 Time Boxed Iterations Time boxed Iteration General iterative development – fix the This itself very useful in many situations functionality for each iteration, then Has predictable delivery times plan and execute it Overall product release and marketing In time boxed iterations – fix the can be better planned duration of iteration and adjust the Makes time a non-negotiable parameter functionality to fit it and helps focus attention on schedule Completion time is fixed, the Prevents requirements bloating functionality to be delivered is flexible Overall dev time is still unchanged CSIS0521 Process Models 21 CSIS0521 Process Models 22 Timeboxing – Taking Time Boxed Iterations Further Timeboxing Model – Basics What if we have multiple iterations Development is done iteratively in fixed executing in parallel duration time boxes Each time box divided in fixed stages Can reduce the average completion Each stage performs a clearly defined task time by exploiting parallelism that can be done independently For parallel execution, can borrow Each stage approximately equal in duration pipelining concepts from hardware There is a dedicated team for each stage When one stage team finishes, it hands over This leads to Timeboxing Process Model the project to the next team CSIS0521 Process Models 23 CSIS0521 Process Models 24 4 Timeboxing Example With this type of time boxes, can use An iteration with three stages – Analysis, pipelining to reduce cycle time Build, Deploy These stages are approximately equal in Like hardware pipelining – view each many situations iteration as an instruction Can adjust durations by determining the As stages have dedicated teams, boudaries suitably simultaneous execution of different Can adjust duration by adjusting the team iterations is possible size for each stage Have separate teams for A, B, and D CSIS0521 Process Models 25 CSIS0521 Process Models 26 Pipelined Execution Timeboxing Execution AT starts executing it-1 Software AT finishes, hands over it-1 to BT, Requirements Build Deploy starts executing it-2 TB1 AT finishes it-2, hands over to BT; BT Requirements Build Deploy TB2 finishes it-1, hands over to DT; AT Requirements Build Deploy starts it-3, BT starts it-2 (and DT, it-1) TB3 Requirements Build Deploy … TB4 CSIS0521 Process Models 27 CSIS0521 Process Models 28 Timeboxing execution Timeboxing execution First iteration finishes at time T Duration of each iteration still the same Second finishes at T+T/3; third at T+2 Total work done in a time box is also T/3, and so on the same In steady state, delivery every T/3 time Productivity of a time box is same If T is 3 weeks, first delivery after 3 wks, 2nd after 4 wks, 3rd after 5 wks,… Yet, average cycle time or delivery time has reduced to a third In linear execution, delivery times will be 3 wks, 6 wks, 9 wks,… CSIS0521 Process Models 29 CSIS0521 Process Models 30 5 Team Size Team Size In linear execution of iterations, the Merely by increasing the team size we cannot same team performs all stages reduce cycle time - Brook’s law Adding manpower to a late software project If each stage has a team of S, in linear makes it later. execution the team size is S Timeboxing allows structured way to add In pipelined execution, the team size is manpower to reduce cycle time three times (one for each stage) Note that we cannot change the time of an i.e. the total team size in timeboxing is iteration – Brook’s law still holds larger; and this reduces cycle time CSIS0521 Process Models 31 CSIS0521 Process Models 32 Work Allocation of Teams Timeboxing Advantages: Shortened delivery times, other Requirements Requirements Requirements Requirements Requirements adv of iterative, distributive execution Team Analysis for TB1 Analysis for TB2 Analysis for TB3 Analysis for TB4 Disadvantages: Larger teams, proj mgmt is Build Team Build for TB1 Build for TB2 Build for TB3 Build for TB4 harder, high synchronization needed Applicability: When short delivery times very Deployment Deployment for TB1Deployment for TB2Deployment for TB3 Team important; architecture is stable; flexibility in feature grouping CSIS0521 Process Models 33 CSIS0521 Process Models 34 Summary Summary – waterfall Process is a means to achieve project Strength Weakness Types of Projects objectives of high quality and productivity Simple All or nothing – too Well understood Easy to execute risky problems, short Process models define