Software Process PDF

Software Process Chap. 2 Integrated Approach to SE Pankaj Jalote Sofware Process 1  Software Process Process is distinct from product – products are outcomes of executing a process on a project Software Engineering focuses on process...

Software Process Chap. 2 Integrated Approach to SE Pankaj Jalote Sofware Process 1  Software Process 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 Sofware Process 2  Software Process… Process: A particular method, generally involving a number of steps Software Process: A set of steps, along with ordering constraints on execution, to produce software with desired outcome Many types of activities performed by different people in a software project Better to view software process as comprising of many component processes Sofware Process 3  Software Processes Software Process Product Process Engineering Management Process Process Development … Project Configuration Process Management Management Process Process Sofware Process 4  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 Programmers, testers execute development process Project manager executes the management process Sofware Process 5  Component Processes… Other processes Configuration management process: manages the evolution of artifacts Requirements management process: how changes in requirements are incorporated Review process: How inspections are conducted on artifacts Process management process: management of processes themselves Sofware Process 6  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 / artifacts At top level, typically few phases in a process How to perform a particular phase – methodologies have been proposed Sofware Process 7  ETVX Specification ETVX approach to specify a step Entry criteria: what conditions must be satisfied before 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 management Sofware Process 8 ETVX approach Sofware Process 9  Desired Process Properties Provide high Q&P Support testability as testing is the most expensive task; testing can consume 30 to 50% of total development effort Support maintainability as maintenance can be more expensive than development; over life up to 80% of total cost Remove defects early, as cost of removing defects increases with latency Sofware Process 10  High Q&P: Early Defect Removal… Cost of a defect increases with latency Hence, for high Q&P, the process must support early defect removal That is why there is a V in ETVX, and quality control tasks in the software process Sofware Process 11 Early Defect Removal… Sofware Process 12  Desired Properties… Predictability and repeatability Process should repeat its performance when used on different projects i.e. outcome of using a process should be predictable Without predictability, one cannot estimate, or say anything about quality or productivity With predictability, past performance can be used to predict future performance Sofware Process 13  Predictability… Predictable process is said to be under statistical control Repeatedly using the process produces similar results Results – properties of interest like quality, productivity, … To consistently develop software with high Q&P, process must be in control Sofware Process 14 Predictability… Sofware Process 15  Support Change Software changes for various reasons Requirements change is a key reason Requirement changes cannot be wished away or treated as “bad” They must be accommodated in the process for software development Sofware Process 16  Summary Process – method for doing something Process typically has stages, each stage focusing on an identifiable task Stages have methodologies Software process can be viewed as comprising of multiple processes Goal is to produce software with high quality and productivity Process is the means Sofware Process 17 Development Process and Process Models Chap. 2 Integrated Approach to SE Panakj Jalote Sofware Process 18  Software Project Project – Temporary endeavor undertaken to accomplish a unique purpose Software Project – to build a software system within cost and schedule with high quality which satisfies the customer Project goals – high Q and high P Suitable process needed to reach goals For a project, the process to be followed is specified during planning Sofware Process 19  Development Process 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 (manage complexity) Each phase handles a different part of the problem Helps in continuous verification Sofware Process 20  Development Process Commonly has these activities: Requirements analysis, architecture, design, coding, testing, delivery Different models perform them in different manner Sofware Process 21  Requirement Analysis To understand and state the problem precisely Forms the basis of agreement between user and developer Specifies “ what “ , not “ how “ Not an easy task, as needs are often misunderstood Requirement specifications of even medium systems can be many hundreds of pages Output is the software requirement specifications (SRS) document Sofware Process 22  Design A major step in moving from problem domain to solution domain; three main tasks Architecture design – components and connectors that should be there in the system High level design – modules and data structures needed to implement the architecture Detailed design – logic of modules Most methodologies focus on architecture or high level design Outputs are architectural/high/logic design docs Sofware Process 23  Coding Converts design into code in specific language Goal: Implement the design with simple and easy to understand code. Code should be simple and readable. The coding phase affects both testing and maintenance. Well written code can reduce the testing and maintenance effort. Output is code Sofware Process 24  Testing Defects are introduced in each phase They have to be found and removed to achieve high quality Testing plays this important role Goal: Identify most of defects Is a very expensive task; has to be properly planned and executed. Outputs are Test plans/results, and the final tested (hopefully reliable) code Sofware Process 25  Effort Distribution Distribution of effort : Req. - 10-20% Design - 10-20% Coding - 20-30% Testing - 30-50% Coding is not the most expensive. Sofware Process 26  Distribution of effort… How programmers spend their time Writing programs - 13% Reading programs and manuals - 16% Job communication - 32% Others - 39% Programmers spend more time in reading programs than in writing them Writing programs is a small part of their lives Sofware Process 27  Defects Distribution of error occurrences by phase is Req. - 20% Design - 30% Coding - 50% Defects can be injected at any of the major phases Cheapest way to detect and remove defects close to where it is injected. Hence must check for defects after every phase Sofware Process 28  Process Models A process model specifies a general process, usually as a set of stages This model will be suitable for a class of projects i.e. a model provides generic structure of the process that can be followed by some projects to achieve their goals Sofware Process 29  Projects Process If a project chooses a model, it will generally tailor it to suit the project This produces the spec for the projects process This process can then be followed in the project i.e. process is what is actually executed; process spec is plan about what should be executed; process model is a generic process spec Many models have been proposed for the development process Sofware Process 30  SDLC Models Waterfall Model Prototyping / RAD Iterative / Incremental Model Spiral Model / Evolutionary Model Time-box model Component Based model 4th Generation Techniques Formal Methods Agile Methodologies Sofware Process 31 Classical Waterfall model Sofware Process 32 Waterfall model with iteration Requirements definition System and software design Implementation and unit testing Integr ation and system testing Operation and maintenance Sofware Process 33  Waterfall Model Linear sequence of stages/phases Requirements – HLD – DD – Code – Test – Deploy A phase starts only when the previous has completed The phases partition the project, each addressing a separate concern Sofware Process 34  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 Sofware Process 35  Waterfall Advantages Conceptually simple, cleanly divides the problem into distinct phases that can be performed independently Natural approach for problem solving Easy to administer in a contractual setup – each phase is a milestone Sofware Process 36  Waterfall disadvantages Assumes that requirements can be specified and frozen early May fix hardware and other technologies too early Follows the “big bang” approach – all or nothing delivery; too risky Very document oriented, requiring docs at the end of each phase Sofware Process 37  Waterfall Usage Has been used widely Well suited for projects where requirements can be understood easily and technology decisions are easy i.e. for familiar type of projects it still may be the most optimum Sofware Process 38  V-Model It is a variation of Waterfall model with strong emphasis on Testability Model encourages test activities beginning in parallel with corresponding development activities Early verification & validation helps in mitigating risk Excellent for system requiring high reliability Works well when requirements are well understood Suffers from problems similar to waterfall model Sofware Process 39  V-Model… User requirements Acceptance and acceptance testing test planning Functional System requirements and testing system test planning Verification Validation Architecture Integration and integration testing test planning Detailed design Unit and unit testing test planning Time Coding Sofware Process 40  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 Sofware Process 41  Throwaway - Prototype Development of prototype Starts with initial requirements Only key features which need better understanding are included in prototype No point in including those features that are well understood Feedback from users taken to improve the understanding of the requirements Once the requirements are understood, throwaway the prototype and start all over again Sofware Process 42  Prototyping Cost can be kept low Build only features needing clarification “quick and dirty” – quality not important, scripting etc can be used Things like exception handling, recovery, standards are omitted Cost can be a few % of the total Learning in prototype building will help in building, besides improved requirements Sofware Process 43  Prototyping- pros & cons Pros generally, reduces cost of development reduces risks associated with projects Cons customer wants the “prototype” as final system implementation level compromises are made Sofware Process 44  Prototyping Problems Lack of process visibility Systems are often poorly structured Special skills (e.g. in languages for rapid prototyping) may be required Applicability For small or medium-size interactive systems For parts of large systems (e.g. the user interface) For short-lifetime systems Sofware Process 45  Iterative Development Counters the “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 mini waterfalls Feedback from one iteration is used in the future iterations Sofware Process 46 Iterative Enhancement Sofware Process 47  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 Newer approaches like XP, Agile,… all rely on iterative development Sofware Process 48 Unified Process – Structure Business Modeling Requirements Analysis & Design Implementation Test Deployment Config. & Chg. Mgt. Project Management Environment Mgt. Sofware Process 49  Unified Process – Structure What the phases are NOT: Inception ≠ Requirements Phase Elaboration ≠ Design Phase Construction ≠ Implementation Phase Transition ≠ Integration/QA Phase There are multiple iterations inside of each phase (especially in elaboration and construction) Requirements analysis, design, coding, integration and testing are all activities that are done within every iteration of elaboration and construction Sofware Process 50  Unified Process – Structure Inception Phase Activities: Goal: Define the product Define vision/scope. vision and business case. Develop business case. Effort - ~5% of Gather broad development cycle requirements (20%). Sample artifacts: Identify candidate Use Case Diagram. architecture Some High-Level Use Plan and estimate for first Cases. Elaboration iteration. Glossary. Sofware Process 51  Unified Process – Structure Elaboration Phase: Activities: Goal: Build the core Refine and validate architecture and define functional baseline most requirements architecture. Effort - ~20% of Build high-risk development cycle requirements Sample artifacts: Gather and state detailed Domain model. requirements (80%) Collaboration Diagrams. Design Class Diagram. Implementation (source code). Sofware Process 52  Unified Process – Structure Construction Phase: Activities: Goal: Build the features that Design and build are not part of operational elements the core architecture and prepare for deployment. Prepare for beta test Effort - ~65% of development cycle Sample artifacts: Domain model. Collaboration Diagrams. Design Class Diagram. Implementation (source code) Sofware Process 53  Unified Process – Structure Transition Phase: Activities: Goal: Move system from Beta test development to production Data conversion. Effort - ~10% of Training Deployment development cycle. Sample artifacts: Component Diagram Deployment Diagram Sofware Process 54  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, risk of long projects cannot be taken, all requirements not known Sofware Process 55  Timeboxing Iterative is linear sequence of iterations Each iteration is a mini waterfall – decide the specs, then plan the iteration Time boxing – fix an iteration duration, then determine the specs Divide iteration in a few equal stages Use pipelining concepts to execute iterations in parallel Sofware Process 56  Time Boxed Iterations General iterative development – fix the functionality for each iteration, then plan and execute it In time boxed iterations – fix the duration of iteration and adjust the functionality to fit it Completion time is fixed, the functionality to be delivered is flexible Sofware Process 57  UP-Time Boxed Iterations Iteration Iteration... 1 2 Ana- De- Ana- De- Code+Design+Test+Integrate Code+Design+Test+Integrate lyze sign lyze sign 2 or 4 weeks 2 or 4 weeks Sofware Process 58  Time boxed Iteration This itself very useful in many situations Has predictable delivery times Overall product release and marketing can be better planned Makes time a non-negotiable parameter and helps focus attention on schedule Prevents requirements bloating Overall development time is still unchanged Sofware Process 59  Timeboxing – Taking Time Boxed Iterations Further What if we have multiple iterations executing in parallel Can reduce the average completion time by exploiting parallelism For parallel execution, can borrow pipelining concepts from hardware This leads to Timeboxing Process Model Sofware Process 60  Timeboxing Model – Basics Development is done iteratively in fixed duration time boxes Each time box divided in fixed stages Each stage performs a clearly defined task that can be done independently Each stage approximately equal in duration There is a dedicated team for each stage When one stage team finishes, it hands over the project to the next team Sofware Process 61  Timeboxing With this type of time boxes, can use pipelining to reduce cycle time Like hardware pipelining – view each iteration as an instruction As stages have dedicated teams, simultaneous execution of different iterations is possible Sofware Process 62  Timeboxing Execution Software Requirements Build Deploy TB1 Requirements Build Deploy TB2 Requirements Build Deploy TB3 Requirements Build Deploy TB4 Sofware Process 63  Timeboxing execution First iteration finishes at time T Second finishes at T+T/3; third at T+2 T/3, and so on In steady state, delivery every T/3 time If T is 3 weeks, first delivery after 3 wks, 2nd after 4 wks, 3rd after 5 wks,… In linear execution, delivery times will be 3 wks, 6 wks, 9 wks,… Sofware Process 64  Timeboxing execution Duration of each iteration still the same Total work done in a time box is also the same Productivity of a time box is same Yet, average cycle time or delivery time has reduced to a third Sofware Process 65  Team Size In linear execution of iterations, the same team performs all stages If each stage has a team of S, in linear execution the team size is S In pipelined execution, the team size is three times (one for each stage) i.e. the total team size in timeboxing is larger; and this reduces cycle time Sofware Process 66  Team Size Merely by increasing the team size we cannot reduce cycle time - Brook’s law Timeboxing allows structured way to add manpower to reduce cycle time Note that we cannot change the time of an iteration – Brook’s law still holds Work allocation different to allow larger team to function properly Sofware Process 67  Timeboxing Pros and Cons Pros: Shortened delivery times, iterative, distributed execution Cons: Larger teams, project management is harder, high synchronization needed, CM is harder Sofware Process 68 Spiral model of the software process Determine objectives Evaluate alternatives alternatives and identify, resolve risks constraints Risk analysis Risk analysis Risk analysis Opera- Prototype 3 tional Prototype 2 protoype Risk REVIEW analysis Proto- type 1 Requirements plan Simulations, models, benchmarks Life-cycle plan Concept of Operation S/W requirements Product design Detailed Requirement design Development plan validation Code Design Unit test Integration and test plan V&V Integr ation Plan next phase test Acceptance Service test Develop, verify next-level product Sofware Process 69  Spiral Model by Boehm Activities are organized in a spiral with many cycles Radial dimension represents cumulative cost in accomplishing the tasks done so far Angular dimension represents the progress made in completing each cycle. Development step depends on risk and allows any mixture of approaches Each cycle completed by review for planning the next cycle. Sofware Process 70  Phases of the spiral model Objective setting, alternatives and constraints Specific objectives for the project phase are identified Risk assessment and reduction Key risks are identified, analyzed and information is sought to reduce these risks Development and validation An appropriate model is chosen for the next phase of development. Planning The project is reviewed and plans drawn up for the next round of the spiral Sofware Process 71  Spiral model flexibility Well-understood systems (low technical risk) - Waterfall model. Risk analysis phase is relatively cheap Stable requirements and formal specification. Safety criticality - Formal transformation model High UI risk, incomplete specification - prototyping model Hybrid models accommodated for different parts of the project Sofware Process 72  Spiral model Pros and Cons Pros Focuses attention on early error elimination Puts quality objectives up front Integrates development and maintenance Cons Contractual development often specifies process model and deliverables in advance Requires risk assessment expertise Sofware Process 73  Component Based Development OO technologies provides framework for CBSE Reusability across applications Encourages use of third party components Framework exists for building / sharing components Incorporates spiral model characteristics Evolutionary, Iterative Ex. Unified software development process Sofware Process 74  Fourth Generation Techniques Broad array of tools Tool enables software specification at high level Allows automatic generation of source code Uses specialized language forms or graphic notations Sofware Process 75  4GT tools Non-procedural languages Report generation, data manipulation Screen interaction and definition Automated generation of HTML and similar languages used for web site creation Sofware Process 76  4GT advantages, disadvantages Dramatic reduction in software development time Improved productivity Current tools are not easy to use Resultant code is often inefficient Poor maintainability for large systems Sofware Process 77  The Formal Methods Model Formal mathematical specification of computer system Specify, develop, verify computer system by rigorous, mathematical notations Eliminate many of the problems of conventional software engineering ambiguity, incompleteness, inconsistency Leads to defect free software ex. Cleanroom software engineering Sofware Process 78  Formal Methods concerns Time consuming and expensive Extensive training is required Difficult to use for communicating with the customer Useful for safety critical software Sofware Process 79  Agile Methodologies “Agile” is an umbrella term used to describe a variety of methods that encourage continual alignment of development with the needs and expectations of the customer Agile process: Should be “lightweight” Should be “fast” Should be quick in “response” to change Sofware Process 80  Agile Methodologies Extreme Programming (XP) Scrum Development Crystal Methodologies Feature Driven Development (FDD) Dynamic Systems Development Method (DSDM) Sofware Process 81  Agile Manifesto Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan Sofware Process 82  Agile Method Best Practices Backlog Management Team Planning Test Driven Development Continuous Integration SCRUM meetings Agile Modeling Caves & Common Refactoring Pair Programming Sofware Process 83  Summary Process models define generic process, which can form basis of project process Process typically has phases, each phase focusing on an identifiable task Many models for development process have been proposed Sofware Process 84