chapter2-softwareprocessmodels-190805164811.pptx
- 1. SOFTWARE PROCESS MODELS PROCESS CHARACTERISTICS OF SOFTWARE PROCESS PROCESS MODELS PROTOTYPING
- 2. “You’ve got to be very careful if you don’t know where you’re going, because you might not get there.” - Berra
- 3. CMM (Capability Maturity Model) ⚫ A bench-mark for measuring the maturity of an organization’s software process ⚫ CMM defines 5 levels of process maturity based on certain Key Process Areas (KPA) ⚫ Level 5 – Optimizing (< 1%) ◦ -- process change management ◦ -- technology change management ◦ -- defect prevention ⚫ Level 4 – Managed (< 5%) ◦ -- software quality management ◦ -- quantitative process management
- 4. Level 3 – Defined (< 10%) -- peer reviews -- intergroup coordination -- software product engineering -- integrated software management -- training program -- organization process definition -- organization process focus Level 2 – Repeatable (~ 15%) -- software configuration management -- software quality assurance -- software project tracking and oversight -- software project planning -- requirements management Level 1 – Initial (~ 70%)
- 5. Sofware Process 5 The software Development Problem
- 6. Sofware Process 6 Project and Process ⚫ A software project is one instance of the development problem ⚫ Development process takes the project from user and develops software needed by user ⚫ There are other goals: cost schedule and quality, besides delivering software
- 7. Sofware Process 7 Software Process… ⚫ Process: A sequence of steps performed to achieve some goal ⚫ Software Process: The sequence of steps performed to produce software with high quality, within budget and schedule ⚫ Many types of activities performed by different people in a software project ⚫ Better to view software process as comprising of many component processes
- 8. Software Process ⚫ A framework for the activities, actions, and tasks that are required to build high-quality software. ⚫ A process: a series of steps involving activities, constraints, and resources that produce an intended output of some kind ⚫ Software process is a method of developing a software ⚫ Process is distinct from product – products are outcomes of executing a process on a project ⚫ Software Engineering focuses on process ⚫ Premise: Proper processes will help achieve project objectives of high QP
- 9. Sofware Process 9 Component Software Processes ⚫ Two major processes ◦ Development – focuses on development and quality steps needed to engineer the software ◦ Project management – focuses on planning and controlling the development process ⚫ Development process is the heart of software process; other processes revolve around it ⚫ These are executed by different people ◦ developers execute engg. Process ◦ project manager executes the mgmt proces
- 10. Sofware Process 10 Component Processes… ⚫Other processes ◦ Configuration management process: manages the evolution of artifacts ◦ Change management process: how changes are incorporated ◦ Process management process: management of processes themselves ◦ Inspection process: How inspections are conducted on artifacts
- 11. 11 Process Specification ⚫Process is generally a set of phases ⚫Each phase performs a well defined task and generally produces an output ⚫Intermediate outputs – work products ⚫At top level, typically few phases in a process ⚫How to perform a particular phase – methodologies have been p S r of o wa p re P o roc s es e s d
- 12. Sofware Process 12 ETVX Specification ⚫ ETVX approach to specify a step ◦ Entry criteria: what conditions must be satisfied for initiating this phase ◦ Task: what is to be done in this phase ◦ Verification: the checks done on the outputs of this phase ◦ eXit criteria: when can this phase be considered done successfully ⚫ A phase also produces info for mgmt
- 13. Sofware Process 13 ETVX approach
- 14. Characteristics of Software Process ⚫Predictability ⚫Support Testability & Maintainability ⚫Support Change ⚫Early defect removal ⚫Process improvement and feedback
- 15. 1) Predictability ⚫ Fundamental property of any process ⚫ Predictability determines how accurately the outcome of process can be predicted before project is completed ⚫ It is achieved from past experiences and failures from the similar projects ⚫ It increases Q & P. Decreases C & T ⚫ Predictable process is under statistical control ⚫ Predictable property is within the bound around the expected value of property of interest
- 16. 2) Support Change ⚫Changes due to: ◦ Requirements change ◦ Organization and business change – leads to software supports has to change ⚫Changes during development also ◦ Customer needs change ◦ Long duration projects needs to be changed ⚫Process should support healthy
- 17. 3) Support testability and Maintainability ⚫ Maintenance cost > Development ⚫ To reduce overall cost, development should reduce maintenance cost Process includes Effort R 10% D 10% C 30% T 50% ⚫ How programmers spend their time? Writing Programs 13% Reading Programs and Manuals 16% Job Communication Others 32% 39% ⚫ Testing takes more resources during development ⚫ If testing as side activity or underestimating the testing efforts - >unreliable software
- 18. 4) Early Defect Removal ⚫ Errors occur during programming ⚫ Correction & Detection -> Hardest activity ⚫ Errors occurs at any stage during dev. Error occurrence distributions: 20% 30% R D C 50% ⚫ Cost of correcting errors of different phases -> not the same, depends on when the error is detected and corrected ⚫ Greater the delay in error detection -> more expensive to correct ⚫ Quality control in each phase -> identify, detect, prevent and remove defects
- 19. 5) Process Improvement and Feedback ⚫ Fundamental goal -> high Q product with low C ⚫ Software process be a closed-loop process (feedback control system) ⚫ Process improvement based on previous experiences, feedback from early parts(last iterations) used to improve execution of rest of the part(later iterations)
- 21. Sofware Process 21 Development Process & Process Model ⚫ A set of phases and each phase being a sequence of steps ⚫ Sequence of steps for a phase - methodologies for that phase ⚫ Why have phases? ◦ To employ divide and conquer ◦ each phase handles a different part of the problem ◦ helps in continuous validation ⚫ A process model provides generic structure of the process that can be followed by some projects to achieve their goals
- 22. Process Models - SDLC ⚫Major activities in SDLC (Software Development Life Cycle) ◦ Planning ◦ Requirements Analysis ◦ Design ◦ Coding ◦ Testing ◦ Implementation ◦ Maintenance
- 23. SDLC PHASE ACTIVITIES 1. Planning •Define the system to be developed •Set the project scope •Develop the project plan 2. Requirements Analysis •Gather business requirements and documented in SRS 3. Design •Design the technical architecture based on SRS •Design overall system structure 4. Development •Build technical architecture, databases and programs • Build programs in small units and integrated in next phase 5. Testing •Write test conditions •Perform testing 6. Implementation/ Deployment •Write user documentation •Provide training •Product is deployed in customer environment or released to market 7. Maintenance •Build a help desk • Support Corrections, improvements and adaptations •Support system changes
- 24. 24 Waterfall Model ⚫ One of the first process development models proposed ⚫ Linear sequence of stages/phases ⚫ Requirements – HLD – DD – Code – Test – Deploy ⚫ A phase starts only when the previous has completed; no feedback ⚫ Works for well understood problems with minimal or no changes in the requirements ⚫ Each major phase is marked by milestones and deliverables (artifacts) Sofware Process
- 27. Sofware Process 27 Waterfall… ⚫ Linear ordering implies each phase should have some output ⚫ The output must be validated/certified ⚫ Outputs of earlier phases: work products ⚫ Common outputs of a waterfall: SRS, project plan, design docs, test plan and reports, final code, supporting docs
- 28. Sofware Process 28 Waterfall Advantages ⚫ Easy to understand, easy to use ⚫ Provides structure to inexperienced staff ⚫ Milestones are well understood ⚫ Sets requirements stability ⚫ Good for management control (plan, staff, track) ⚫ Works well when quality is more important than cost or schedule
- 29. Sofware Process 29 Waterfall disadvantages ⚫ All requirements must be known upfront ⚫ Follows the “big bang” approach – all or nothing delivery; too risky ⚫ Very document oriented, requiring docs at the end of each phase ⚫ Views software development as manufacturing process rather than as creative process ⚫ No iterative activities and Change Management that lead to creating a final product ⚫ Long wait before a final product
- 30. Sofware Process 30 Waterfall Usage ⚫ Has been used widely ⚫ Well suited for projects where requirements can be understood easily and technology decisions are easy ⚫ For familiar type of projects with well known requirements
- 31. V Model ⚫ A variation of the waterfall model ⚫ Uses unit testing to verify procedural design ⚫ Uses integration testing to verify architectural (system) design ⚫ Uses acceptance testing to validate the requirements ⚫ If problems are found during verification and validation, the left side of the V can be re-executed before testing on the right side is re-enacted
- 33. V-Shaped Strengths ⚫ Emphasize planning for verification and validation of the product in early stages of product development ⚫ Each deliverable must be testable ⚫ Project management can track progress by milestones ⚫ Easy to use
- 34. V-Shaped Weaknesses ⚫ Does not easily handle concurrent events ⚫ Does not handle iterations or phases ⚫ Does not easily handle dynamic changes in requirements ⚫ Does not contain risk analysis activities
- 35. When to use the V-Shaped Model ⚫ Excellent choice for systems requiring high reliability – hospital patient control applications ⚫ All requirements are known up-front ⚫ When it can be modified to handle changing requirements beyond analysis phase ⚫ Solution and technology are known
- 36. Sofware Process 36 Prototyping ⚫ Prototyping addresses the requirement specification limitation of waterfall & V-model ⚫ Instead of freezing requirements only by discussions, a prototype is built to understand the requirements ⚫ Helps lessen the requirements risk ⚫ Focus is on quickly developing the model not on good programming practices ⚫ After preliminary requirements gathering, it visually show the users what their requirements may look like when implemented
- 38. Prototyping: Basic Steps Identify basic requirements Including input and output info Details (e.g., security) generally ignored Develop initial prototype UI first Review Customers/end –users review and give feedback Revise and enhance the prototype & specs
- 39. Prototyping ⚫ Allows repeated investigation of the requirements or design ⚫ Reduces risk and uncertainty in the development
- 40. Sofware Process 40 Prototyping ⚫ Cost can be kept low ◦ Build only features needs clarification ◦ “quick and dirty” – quality not important ◦ Things like exception handling, recovery, standards are omitted ◦ Cost can be a few % of the total ◦ Learning in prototype building will help in building, the improved requirements
- 41. 41 Prototyping ⚫ Advantages: ◦ Req. will be more stable, ◦ Req. frozen later, ◦ Experience helps in the main development ⚫ Disadvantages: ◦ Potential hit on cost and schedule ⚫ Applicability: ◦ When req. are hard to elicit and confidence in reqs. is low; ◦ Reqs. are not well understood Sofware Process
- 42. Throwaway Prototyping ⚫ Write preliminary requirements ⚫ Design the prototype ⚫ User experiences/uses the prototype, ⚫ Specifies new requirements ⚫ Repeat if necessary ⚫ Write the final requirements ⚫ Develop the real products
- 43. Evolutionary Prototyping Model ⚫ Goal is to build a very robust prototype in a structured manner and constantly refine it ⚫ Developers build a prototype during the requirements phase ⚫ Prototype is evaluated by end users ⚫ Users give corrective feedback ⚫ Developers further refine the prototype ⚫ When the user is satisfied, the prototype code is brought up to the standards needed for a final product.
- 44. Incremental prototyping ⚫ Final product built as separate prototypes ⚫ At the end, the prototypes are merged into a final design Often used for web applications Development broken down into 3 phases, each based on the preceding 1 1. Static prototype consisting of HTML pages 2. Screen are programmed and fully functional using a simulated services layer 3. Services are implemented
- 45. Phased Development: Increments and Iterations ⚫ Incremental development: starts with small functional subsystem and adds functionality with each new release ⚫ Iterative development: starts with full system, then changes functionality of each subsystem with each new release
- 46. Increments and Iterations Model ⚫ System delivered in pieces ◦ enables customers to have some functionality while the rest is being developed ⚫ Allows two systems functioning in parallel ◦ the production system (release n): currently being used ◦ the development system (release n+1): the next version
- 47. Sofware Process 47 Iterative Development ⚫ Solves “all or nothing” drawback of the waterfall model ⚫ Combines benefit of prototyping and waterfall ⚫ Develop and deliver software in increments ⚫ Each increment is complete in itself ⚫ Can be viewed as a sequence of waterfalls ⚫ Feedback from one iteration is used in the future iterations
- 48. Sofware Process 48 Iterative Enhancement
- 49. Sofware Process 49 Iterative Development ⚫ Products almost always follow it ⚫ Used commonly in customized development: ◦ Businesses want quick response for s/w ◦ Cannot afford the risk of all-or-nothing ⚫ Newer approaches like XP,Agile,… all rely on iterative development
- 50. Sofware Process 50 Iterative Development ⚫ Benefits: Get-as-you-pay, feedback for improvement ⚫ Drawbacks: Architecture/design may not be optimal, rework may increase, total cost may be more ⚫ Applicability: where response time is important, all req. not known
- 51. Sofware Process 51 Another form of Iteration… •The first iteration does the requirements and architecture in the waterfall way •The development and delivery is done incrementally in iterations
- 52. Spiral Model ⚫ Suggested by Boehm (1988) ⚫ Combines development activities with risk management to minimize and control risks ⚫ The model is presented as a spiral in which each iteration is represented by a circuit around four major activities ◦ Plan ◦ Determine goals, alternatives and constraints ◦ Evaluate alternatives and risks ◦ Develop and test
- 54. ⚫ Spiral Quadrant: Determine objectives, alternatives and constraints ◦ Objectives: functionality, performance, hardware/software interface, critical success factors, etc. ◦ Alternatives: build, reuse, buy, sub-contract, etc. ◦ Constraints: cost, schedule, interface, etc. ⚫ Spiral Quadrant: Evaluate alternatives, identify and resolve risks ◦ Study alternatives relative to objectives and constraints ◦ Identify risks (lack of experience, new technology, tight schedules, poor process, etc.) ◦ Resolve risks (evaluate if money could be lost by continuing system development)
- 55. ⚫ Spiral Quadrant: Develop next-level product ◦ Create a design ◦ Review design ◦ Develop code ◦ Inspect code ◦ Test product ⚫ Spiral Quadrant: Plan next phase ◦ Develop project plan ◦ Develop configuration management plan ◦ Develop a test plan ◦ Develop an installation plan
- 56. Spiral Model Strengths ⚫ Changing requirements can be accommodated. ⚫ Allows extensive use of prototypes. ⚫ Requirements can be captured more accurately. ⚫ Users see the system early. ⚫ Development can be divided into smaller parts and the risky parts can be developed earlier which helps in better risk management.
- 57. Spiral Model Weaknesses ⚫ The model is complex ⚫ Risk assessment expertise is required ⚫ Spiral may continue indefinitely ⚫ Developers must be reassigned during non- development phase activities ⚫ Management is more complex. ⚫ End of the project may not be known early. ⚫ Not suitable for small or low risk projects and could be expensive for small projects.
- 58. When to use Spiral Model When creation of a prototype is appropriate When costs and risk evaluation is important For medium to high-risk projects Long-term project commitment is risky because of potential changes to economic priorities Users are unsure of their needs Requirements are complex Significant changes are expected (research and exploration)