Week 2: Life Cycle Models PDF

Life Cycle Models 1  Conceptualize Software Specify Life Cycle Retire Design Maintain Deliver Code...

Life Cycle Models 1  Conceptualize Software Specify Life Cycle Retire Design Maintain Deliver Code Test 2  Life Cycle Model A software life cycle model (also process model or SDLC): –A descriptive and diagrammatic model of software life cycle: –Identifies all the activities undertaken during product development, –Establishes a precedence ordering among the different activities, –Divides life cycle into phases. 3  Life Cycle Model (CONT.) Each life cycle phase consists of several activities. –For example, the design stage might consist of: structured analysis structured design Design review 4  Why Model Life Cycle? A graphical and written description: –Helps common understanding of activities among the software developers. –Helps to identify inconsistencies, redundancies, and omissions in the development process. –Helps in tailoring a process model for specific projects. 5  Life Cycle Model (CONT.) The development team must identify a suitable life cycle model: –and then adhere to it. –Primary advantage of adhering to a life cycle model: Helps development of software in a systematic and disciplined manner. 6  Life Cycle Model (CONT.) When a program is developed by a single programmer --- – The problem is within the grasp of an individual. – He has the freedom to decide his exact steps and still succeed --- called Exploratory model--- One can use it in many ways Fix – CodeTest Design Initial Coding Test – CodeDesign Test  Change Code  Do Until Done – Specify code Design Test  etc. 7  Life Cycle Model (CONT.) When software is being developed by a team: –There must be a precise understanding among team members as to when to do what, –Otherwise, it would lead to chaos and project failure. 8  Life Cycle Model (CONT.) A software project will never succeed if: –one engineer starts writing code, –another concentrates on writing the test document first, –yet another engineer first defines the file structure –another defines the I/O for his portion first. 9  Phase Entry and Exit Criteria A life cycle model: –defines entry and exit criteria for every phase. –A phase is considered to be complete: only when all its exit criteria are satisfied. 10  Life Cycle Model (CONT.) What is the phase exit criteria for the software requirements specification phase? –Software Requirements Specification (SRS) document is complete, reviewed, and approved by the customer. A phase can start: –Only if its phase-entry criteria have been satisfied. 11  Life Cycle Model: Milestones Milestones help software project managers: –Track the progress of the project. –Phase entry and exit are important milestones. 12  Life Cycle and Project Management When a life cycle model is followed: –The project manager can at any time fairly accurately tell, At which stage (e.g., design, code, test, etc.) the project is. 13  Project Management Without Life Cycle Model It becomes very difficult to track the progress of the project. –The project manager would have to depend on the guesses of the team members. This usually leads to a problem: –known as the 99% complete syndrome. 14  Project Deliverables: Myth and Reality Myth: The only deliverable for a successful project is the working program. Reality: Documentation of all aspects of software development are needed to help in operation and maintenance. 15  Many life cycle models have been proposed. We confine our attention to only a few commonly used models. –Waterfall –V model, Life Cycle Model (CONT.) –Evolutionary, Traditional models –Prototyping –Spiral model, –Agile models 16  Software life cycle (or software process): –Series of identifiable stages that a software product undergoes during its life time: Feasibility study Requirements analysis and specification, Design, Coding, Testing Software Life Cycle Maintenance. 17  Classical Waterfall Model Classical waterfall model divides life cycle into following phases: –Feasibility study, –Requirements analysis and specification, Conceptualize –Design, Retire Specify –Coding and unit testing, Maintain Design – Integration and system testing, Deliver Code – Maintenance. Test 18 Feasibility Study Classical Waterfall Model Req. Analysis Design Simplest and most intuitive Coding Testing Maintenance 19  Relative Effort for Phases Phases between feasibility study and 60 testing 50 – Called development phases. 40 Relative Effort Among all life cycle phases 30 20 – Maintenance phase consumes maximum 10 effort. 0 Maintnce Among development phases, Design Test Coding Req. Sp – Testing phase consumes the maximum effort.  Most organizations usually define: – Standards on the outputs (deliverables) produced at the end of every phase – Entry and exit criteria for every phase. They also prescribe methodologies for: – Specification, Process Model – Design, – Testing, – Project management, etc.  Classical Waterfall Model (CONT.) The guidelines and methodologies of an organization: –Called the organization's software development methodology. Software development organizations: – Expect fresh engineers to master the organization's software development methodology. 22 Feasibility Study Economic feasibility (also called cost/benefit feasibility) Technical Feasibility Schedule feasibility Dimensions feasibility 23  Main aim of feasibility study: determine whether developing the software is: – Financially worthwhile Feasibility Study – Technically feasible. Roughly understand what customer wants: First Step – Data which would be input to the system, – Processing needed on these data, – Output data to be produced by the system, – Various constraints on the behavior of the system. 24  SPF Scheme for CFL CFL has a large number of employees, exceeding 50,000. Majority of these are casual labourers Mining being a risky profession: – Casualties are high Case Study Though there is a PF: – But settlement time is high There is a need of SPF: – For faster disbursement of benefits 25  Feasibility: Case Study Manager visits main office, finds out the main functionalities required Visits mine site, finds out the data to be input Suggests alternate solutions Determines the best solution Presents to the CFL Officials Go/No-Go Decision 26  Activities During Feasibility Study Work out an overall understanding of the problem. Formulate different solution strategies. Examine alternate solution strategies in terms of: resources required, cost of development, and development time. 27  Perform a cost/benefit analysis: –Determine which solution is the best. –May also find that none of the solutions is feasible due to: Activities during Feasibility Study high cost, resource constraints, technical reasons. 28  Cost benefit analysis (CBA) Need to identify all costs --- these could be: – Development costs – Set-up – Operational costs Identify the value of benefits Check benefits are greater than costs 29 The business case Benefits of delivered project must outweigh costs Benefits Costs include: Costs - Development - Operation Rs Benefits: Rs – Quantifiable – Non-quantifiable 30  The business case Feasibility studies should help write a ‘business case’ Should provide a justification for starting the project Should show that the benefits of the project will exceed: – Various costs Needs to take account of business risks 31 1. Executive summary Writing an Effective Business Case 2. Project background:  The focus must be on what, exactly, the project is undertaking, and should not be confused with what might be a bigger picture. 3. Business opportunity - What difference will it make? - What if we don’t do it? 4. Costs - Should include the cost of development, implementation, training, change management, and operations. 5. Benefits  Benefits usually presented in terms of revenue generation and cost reductions. 6. Risks − Identify risks. − Explain how these will be managed. 32 Feasibility Study Req. Analysis Classical Waterfall Model Design Coding Testing Maintenance 33  Requirements Analysis and Specification Aim of this phase: –Understand the exact requirements of the customer, –Document them properly. Consists of two distinct activities: –Requirements gathering and analysis –Requirements specification. 34  Requirements Analysis and Specification Gather requirements data from the customer: Analyze the collected data to understand what customer wants Remove requirements problems: Inconsistencies Anomalies Incompleteness Organize into a Software Requirements Specification (SRS) document. 35  Requirements Gathering Gathering relevant data: –Usually collected from the end-users through interviews and discussions. –Example: for a business accounting software: Interview all the accountants of the organization to find out their requirements. 36  Requirements Analysis (Cont...) The data you initially collect from the users: –Usually contain several contradictions and ambiguities. –Why? –Each user typically has only a partial and incomplete view of the system. 37  Requirements Analysis (Cont...) Ambiguities and contradictions: –must be identified –resolved by discussions with the customers. Next, requirements are organized: –into a Software Requirements Specification (SRS) document. 38 Feasibility Study Req. Analysis Design Design Classical Waterfall Model Coding Testing Maintenance 39  Design During design phase requirements specification is transformed into : – A form suitable for implementation in some programming language. Two commonly used design approaches: –Traditional approach, –Object oriented approach 40  Traditional Design Approach Consists of two activities: –Structured analysis (typically carried out by using DFD) –Structured design 41  Structured Design root High-level design: order query indent –decompose the system into modules, Handle-order Handle-indent Handle-query –represent invocation relationships among the modules. Accept- Detailed design: Get-order order Process- order –different modules designed in greater detail: data structures and algorithms for each module are designed. 42  First identify various objects (real world entities) occurring in the problem: – Identify the relationships among the objects. – For example, the objects in a pay-roll software may be: employees, managers, Object-Oriented Design pay-roll register, Departments, etc. 43  Object Oriented Design (CONT.) Object structure: – Refined to obtain the detailed design. OOD has several advantages: – Lower development effort, – Lower development time, – Better maintainability. 44 Feasibility Study Req. Analysis Classical Waterfall Design Model Coding Testing Maintenance 45  Coding and Unit Testing During this phase: –Each module of the design is coded, –Each module is unit tested That is, tested independently as a stand alone unit, and debugged. –Each module is documented. 46 Feasibility Study Req. Analysis Classical Waterfall Design Model Coding Testing Maintenance 47  Integration and System Testing Different modules are integrated in a planned manner: –Modules are usually integrated through a number of steps. M1 M2 M5 M7 During each integration step, –the partially integrated system is tested. M3 M4 M6 M8 48  System Testing After all the modules have been successfully integrated and tested: –System testing is carried out. Goal of system testing: – Ensure that the developed system functions according to its requirements as specified in the SRS document. 49 Feasibility Study Req. Analysis Design Classical Waterfall Model Coding Testing Maintenance 50  Maintenance Maintenance of any software: –Requires much more effort than the effort to develop the product itself. –Development effort to maintenance effort is typically 40:60. 51  Types of Maintenance? Corrective maintenance: – Correct errors which were not discovered during the product development phases. Perfective maintenance: – Improve implementation of the system – enhance functionalities of the system. Adaptive maintenance: – Port software to a new environment, e.g. to a new computer or to a new operating system. 52  Iterative Waterfall Model Classical waterfall model is idealistic: –Assumes that no defect is introduced during any development activity. –In practice: Defects do get introduced in almost every phase of the life cycle. 53  Iterative Waterfall Model (CONT.) Defects usually get detected much later in the life cycle: –For example, a design defect might go unnoticed till the coding or testing phase. –The later the phase in which the defect gets detected, the more expensive is its removal --- why? 54  Iterative Waterfall Model (CONT.) Once a defect is detected: –The phase in which it occurred needs to be reworked. – Redo some of the work done during that and all subsequent phases. Therefore need feedback paths in the classical waterfall model. 55 Feasibility Study Iterative Waterfall Model (CONT.) Req. Analysis Design Coding Testing Maintenance 56  Phase Containment of Errors (Cont...) Errors should be detected:  In the same phase in which they are introduced. For example:  If a design problem is detected in the design phase itself,  The problem can be taken care of much more easily  Than say if it is identified at the end of the integration and system testing phase. 57  Phase Containment of Errors Reason: rework must be carried out not only to the design but also to code and test phases. The principle of detecting errors as close to its point of introduction as possible: – is known as phase containment of errors. Iterative waterfall model is by far the most widely used model. – Almost every other model is derived from the waterfall model. 58 Feasibility Study Iterative Waterfall Model (CONT.) Req. Analysis Design Coding Testing Maintenance 59  Waterfall Strengths Easy to understand, easy to use, especially by inexperienced staff Milestones are well understood by the team Provides requirements stability during development Facilitates strong management control (plan, staff, track) 60  Waterfall Deficiencies All requirements must be known upfront – in most projects requirement change occurs after project start Can give a false impression of progress Integration is one big bang at the end Little opportunity for customer to pre-view the system. 61  When to use the Waterfall Model? Requirements are well known and stable Technology is understood Development team have experience with similar projects 62  Classical Waterfall Model (CONT.) Irrespective of the life cycle model actually followed: –The documents should reflect a classical waterfall model of development. –Facilitates comprehension of the documents. 63  Classical Waterfall Model (CONT.) Metaphor of mathematical theorem proving: –A mathematician presents a proof as a single chain of deductions, Even though the proof might have come from a convoluted set of partial attempts, blind alleys and backtracks. 64  V Model 7/18/2020 65  V Model It is a variant of the Waterfall – emphasizes verification and validation – V&V activities are spread over the entire life cycle. In every phase of development: – Testing activities are planned in parallel with development. 66  Production, Project Planning Operation & Maintenance Requirements System Testing Specification High Level Design Integration Testing Detailed Design Unit testing Coding 67  V Model Steps Planning Requirements Analysis and System test design Specification High-level Design Integration Test dsign Detailed Design Unit test design 68  V Model: Strengths Starting from early stages of software development: – Emphasizes planning for verification and validation of the software Each deliverable is made testable Easy to use 69  V Model Weaknesses Does not support overlapping of phases Production, Project Operation & Planning Maintenance Does not handle iterations or phases Requirements Specification System Testing Does not easily accommodate later Integration High Level Design Testing Detailed Design Unit testing changes to requirements Coding Does not provide support for effective risk handling 70  When to use V Model Natural choice for systems requiring high reliability: – Embedded control applications, safety-critical software All requirements are known up-front Solution and technology are known 71  Prototyping Model 7/18/2020 72  Prototyping Model A derivative of waterfall model. Prototype Construction Design Before starting actual development, Coding – A working prototype of the system should first be built. Testing Maintenance A prototype is a toy implementation of a system: –Limited functional capabilities, –Low reliability, –Inefficient performance. 73  Reasons for prototyping Learning by doing: useful where requirements are Prototype Construction only partially known Design Improved communication Coding Improved user involvement Testing Reduced need for documentation Maintenance Reduced maintenance costs 74  Reasons for Developing a Prototype Illustrate to the customer: –input data formats, messages, reports, or interactive dialogs. Examine technical issues associated with product development: –Often major design decisions depend on issues like: Response time of a hardware controller, Efficiency of a sorting algorithm, etc. 75  Prototyping Model (CONT.) Another reason for developing a prototype: –It is impossible to “get it right” the first time, –We must plan to throw away the first version: If we want to develop a good software. 76  Prototyping Model Prototype Construction Start with approximate requirements. Design Carry out a quick design. Coding Testing Prototype is built using several short-cuts: Maintenance –Short-cuts might involve: Using inefficient, inaccurate, or dummy functions. A table look-up rather than performing the actual computations. 77  Build Prototype Prototyping Model (CONT.) Requirements Customer Customer Evaluation of Design Gathering Quick Design Prototype satisfied Refine Requirements Implement Test Maintain 78  Prototyping Model (CONT.) The developed prototype is submitted to the customer for Build Prototype his evaluation: Requirements Gathering Quick Design Customer Evaluation of Prototype Customer satisfied Design Refine Requirements Implement –Based on the user feedback, the prototype is refined. Test –This cycle continues until the user approves the Maintain prototype. The actual system is developed using the waterfall model. 79  Prototyping Model Prototype Construction (CONT.) Requirements analysis and specification Design Coding phase becomes redundant: Testing –Final working prototype (incorporating all user Maintenance feedbacks) serves as an animated requirements specification. Design and code for the prototype is usually thrown away: –However, experience gathered from developing the prototype helps a great deal while developing the actual software. 80  Prototyping Model (CONT.) Even though construction of a working prototype model involves additional cost --- overall development cost usually lower for: – Systems with unclear user requirements, – Systems with unresolved technical issues. Many user requirements get properly defined and technical issues get resolved: – These would have appeared later as change requests and resulted in incurring massive redesign costs. 81  Prototyping: advantages The resulting software is usually more usable User needs are better accommodated The design is of higher quality The resulting software is easier to maintain Overall, the development incurs less cost 82  Prototyping: disadvantages For some projects, it is expensive Susceptible to over-engineering: – Designers start to incorporate sophistications that they could not incorporate in the prototype. 83  Major difficulties of Waterfall-Based Models 1. Difficulty in accommodating change requests during development.  40% of the requirements change during development 2. High cost incurred in developing custom applications. 3. “Heavy weight processes.” 84  Major difficulties of Waterfall-Based Life Cycle Models Requirements for the system are determined at the start: – Are assumed to be fixed from that point on. – Long term planning is made based on this. 85 “… the assumption that one can specify a satisfactory system in advance, get bids for its construction, have it built, and install it. …this assumption is fundamentally wrong and many software acquisition problems spring from this…” Frederick Brooks 86  Incremental Model 7/18/2020 87  “The basic idea… take advantage of what was being learned during the development of earlier, incremental, deliverable versions of the system. Learning comes from both the development and use of the system… Start with a simple implementation of a subset of the software requirements and iteratively enhance the evolving sequence of versions. At each version design modifications are made along with adding new functional capabilities. “ Victor Basili 88  Key characteristics Incremental and Iterative –Builds system incrementally Development (IID) –Consists of a planned number of iterations –Each iteration produces a working program Benefits –Facilitates and manages changes Foundation of agile techniques and the basis for –Rational Unified Process (RUP) –Extreme Programming (XP) 89  Customer’s Perspective C A AB A B B 90  Incremental Model Requirements Split into Outline Features Design Develop Validate Integrate Validate Increment Increment Increment System Final System 91 Incremental Model: Requirements Split into Features Requirements: High Level Analysis Slice Slice Slice Slice Slice Slice Slice Slice Slice Slice Slice Slice 92  Incremental Model Waterfall: single release Iterative: many releases (increments) –First increment: core functionality –Successive increments: add/fix functionality –Final increment: the complete product Each iteration: a short mini-project with a separate lifecycle –e.g., waterfall 93  Incremental delivery increment design build Customer install 1 Feedback Customer increment design build install Feedback 2 increment design build Customer install 3 Feedback 94  The Planned Identify System Objectives incremental incremental Plan increments delivery process Incremental delivery plan Design increment Build the increment Repeat for each Feedback increment Implement the increment Evaluate the results 95  Which step first? Some steps will be pre-requisite because of physical dependencies Others may be in any order Value to cost ratios may be used – V/C where – V is a score 1-10 representing value to customer – C is a score 0-10 representing cost to developers 96  V/C ratios: an example step value cost ratio profit reports 9 2 4.5 2nd online database 1 9 0.11 5th ad hoc enquiry 5 5 1 4th purchasing plans 9 4 2.25 3rd profit-based pay for 9 1 9 1st managers 97 Evolutionary Model with Iterations 98  An Evolutionary and Iterative Development Process... Recognizes the reality of changing requirements –Capers Jones’s research on 8000 projects: 40% of final requirements arrived after development had already begun Promotes early risk mitigation: – Breaks down the system into mini-projects and focuses on the riskier issues first. – “plan a little, design a little, and code a little” Encourages all development participants to be involved earlier on,: – End users, Testers, integrators, and technical writers 99  Evolutionary Model with Iteration “A complex system will be most successful if implemented in small steps… “retreat” to a previous successful step on failure… opportunity to receive some feedback from the real world before throwing in all resources… and you can correct possible errors…” Tom Glib in Software Metrics 100  Evolutionary model with iteration Evolutionary iterative development implies that the requirements, plan, estimates, and solution evolve or are refined over the course of the iterations, rather than fully defined and “frozen” in a major up-front specification effort before the development iterations begin. Evolutionary methods are consistent with the pattern of unpredictable discovery and change in new product development.” Craig Larman 101  Evolutionary Model First develop the core modules of the software. The initial skeletal software is refined into increasing levels of capability: (Iterations) –By adding new functionalities in successive versions. 102  Activities in an Iteration Software developed over several “mini waterfalls”. The result of a single iteration: –Ends with delivery of some tangible code –An incremental improvement to the software --- leads to evolutionary development 103  Evolutionary Model with Iteration Outcome of each iteration: tested, integrated, executable system Iteration length is short and fixed – Usually between 2 and 6 weeks – Development takes many iterations (for example: 10-15) Does not “freeze” requirements and then conservatively design : – Opportunity exists to modify requirements as well as the design… 104  Evolutionary Model (CONT.) Successive versions: –Functioning systems capable of performing some useful work. –A new release may include new functionality: Also existing functionality in the current release might have been enhanced. 105  Evolutionary Model Evolves an initial implementation with user feedback: – Multiple versions until the final version. Initial Specification version Initial Rough Intermediate Requirements Development versions Final Validation version 106  Advantages of Evolutionary Model Users get a chance to experiment with a partially developed system: – Much before the full working version is released, Helps finding exact user requirements: – Software more likely to meet exact user requirements. Core modules get tested thoroughly: – Reduces chances of errors in final delivered software. 107  Advantages of evolutionary model Better management of complexity by developing one increment at a time. Better management of changing requirements. Can get customer feedback and incorporate them much more efficiently: – As compared when customer feedbacks come only after the development work is complete. 108  Advantages of Evolutionary Model with Iteration Training can start on an earlier release –customer feedback taken into account Frequent releases allow developers to fix unanticipated problems quicker. 109  Evolutionary Model: Problems The process is intangible: – No regular, well-defined deliverables. The process is unpredictable: – Hard to manage, e.g., scheduling, workforce allocation, etc. Systems are rather poorly structured: – Continual, unpredictable changes tend to degrade the software structure. Systems may not even converge to a final version. 110  RAD Model 7/18/2020 111  Rapid Application Development (RAD) Model Sometimes referred to as the rapid prototyping model. Major aims: – Decrease the time taken and the cost incurred to develop software systems. – Facilitate accommodating change requests as early as possible: Before large investments have been made in development and testing. 112  Important Underlying Principle A way to reduce development time and cost, and yet have flexibility to incorporate changes: Make only short term plans and make heavy reuse of existing code. 113  Methodology Plans are made for one increment at a time. The time planned for each iteration is called a time box. Each iteration (increment): Enhances the implemented functionality of the application a little. 114  Methodology During each iteration, A quick-and-dirty prototype-style software for some selected functionality is developed. The customer evaluates the prototype and gives his feedback. The prototype is refined based on the customer feedback. 115  How Does RAD Facilitate Faster Development? RAD achieves fast creation of working prototypes. – Through use of specialized tools. These specialized tools usually support the following features: – Visual style of development. – Use of reusable components. – Use of standard APIs (Application Program Interfaces). 116  For which Applications is RAD Suitable? Customized product developed for one or two customers only Performance and reliability are not critical. The system can be split into several independent modules. 117  For Which Applications RAD is Unsuitable? Few plug-in components are available High performance or reliability required No precedence for similar products exists The system cannot be modularized. 118  Prototyping versus RAD In prototyping model: The developed prototype is primarily used to gain insights into the solution Choose between alternatives Elicit customer feedback. The developed prototype: Usually thrown away. 119  Prototyping versus RAD In contrast: In RAD the developed prototype evolves into deliverable software. RAD leads to faster development compared to traditional models: However, the quality and reliability would possibly be poorer. 120  RAD versus Iterative Waterfall Model In the iterative waterfall model, – All product functionalities are developed together. In the RAD model on the other hand, – Product functionalities are developed incrementally through heavy code and design reuse. – Customer feedback is obtained on the developed prototype after each iteration: Based on this the prototype is refined. 121  RAD versus Iterative Waterfall Model The iterative waterfall model: – Does not facilitate accommodating requirement change requests. Iterative waterfall model does have some important advantages: – Use of the iterative waterfall model leads to production of good documentation. – Also, the developed software usually has better quality and reliability than that developed using RAD. 122  Incremental development: RAD versus – Occurs in both evolutionary and RAD models. Evolutionary However, in RAD: Model – Each increment is a quick and dirty prototype, – Whereas in the evolutionary model each increment is systematically developed using the iterative waterfall model. Also, RAD develops software in shorter increments: – The incremental functionalities are fairly large in the evolutionary model. 123  Unified Process 7/18/2020 124  Unified Process Developed Ivar Jacobson, Grady Booch and James Rumbaugh – Incremental and iterative Rational Unified Process (RUP) is version tailored by Rational Software: – Acquired by IBM in February 2003. 125 Four Phases --- and iterative Development at Every phase Inception Phase Elaboration Phase Construction Phase Transition Phase 126  Unified Process Iterations in Phases The duration of and iteration may vary from two weeks or less. Iterations Iterations Iterations Iterations Inception Elaboration Construction Transition 127  Unified process software increment Communication inception Deployment Planning transition elaboration Construction Modeling construction 128  Unified process work products Inception phase Elaboration phase Construction phase Transition phase vision document use-case model design model SW increment initial use-case model requirements SW components beta test reports initial business case analysis model test plan user feedback initial risk list preliminary model test procedure... project plan revised risk list test cases prototype(s) preliminary user manual... manual installation manual...... 129  Structure of RUP Process Two dimensions. Horizontal axis: – Represents time and shows the lifecycle aspects of the process. Vertical axis: – Represents core process workflows. 130 Two dimensions of Unified Process 131  Inception activities Formulate scope of project Risk management, staffing, project plan Synthesize a candidate architecture. 132  Initial requirements capture Cost Benefit Analysis Outcome of Inception Initial Risk Analysis Phase Project scope definition Defining a candidate architecture Development of a disposable prototype Initial Use Case Model (10% - 20% complete) First pass Domain Model 133  Spiral Model Proposed by Boehm in 1988. Each loop of the spiral represents a phase of the software process: – the innermost loop might be concerned with system feasibility, – the next loop with system requirements definition, – the next one with system design, and so on. There are no fixed phases in this model, the phases shown in the figure are just examples.  Spiral Model (CONT.) The team must decide: – how to structure the project into phases. Start work using some generic model: – add extra phases for specific projects or when problems are identified during a project. Each loop in the spiral is split into four sectors (quadrants).  Spiral Model Determine Identify & Objectives Resolve Risks Customer Evaluation of Develop Next Prototype Level of Product  Objective Setting (First Quadrant) Identify objectives of the phase, Examine the risks associated with these objectives. – Risk: Any adverse circumstance that might hamper successful completion of a software project. Find alternate solutions possible.  Risk Assessment and Reduction (Second Quadrant) For each identified project risk, – a detailed analysis is carried out. Steps are taken to reduce the risk. For example, if there is a risk that requirements are inappropriate: – A prototype system may be developed.  Spiral Model (CONT.) Development and Validation (Third quadrant): – develop and validate the next level of the product. Review and Planning (Fourth quadrant): – review the results achieved so far with the customer and plan the next iteration around the spiral. With each iteration around the spiral: – progressively more complete version of the software gets built.  Subsumes all discussed models: – a single loop spiral represents waterfall model. Spiral Model as – uses an evolutionary approach -- a Meta Model iterations over the spiral are evolutionary levels. – enables understanding and reacting to risks during each iteration along the spiral. – Uses: prototyping as a risk reduction mechanism retains the step-wise approach of the waterfall model.  Agile Models 7/18/2020 141  What is Agile Software Development? Agile: Easily moved, light, nimble, active software processes How agility achieved? – Fitting the process to the project – Avoidance of things that waste time 142  Agile Model To overcome the shortcomings of the waterfall model of development. – Proposed in mid-1990s The agile model was primarily designed: – To help projects to adapt to change requests In the agile model: – The requirements are decomposed into many small incremental parts that can be developed over one to four weeks each. 143  Ideology: Agile Manifesto Individuals and interactions over – process and tools Working Software over – comprehensive documentation Customer collaboration over – contract negotiation Responding to change over http://www.agilemanifesto.org – following a plan 144  XP Agile Methodologies Scrum Unified process Crystal DSDM Lean 145  Agile Model: Principal Techniques User stories: – Simpler than use cases. Metaphors: – Based on user stories, developers propose a common vision of what is required. Spike: – Simple program to explore potential solutions. Refactor: – Restructure code without affecting behavior, improve efficiency, structure, etc. 146  At a time, only one increment is planned, developed, deployed at the customer site. Agile Model: Nitty Gritty – No long-term plans are made. An iteration may not add significant functionality, – But still a new release is invariably made at the end of each iteration – Delivered to the customer for regular use. 147  Methodology Face-to-face communication favoured over written documents. To facilitate face-to-face communication, – Development team to share a single office space. – Team size is deliberately kept small (5-9 people) – This makes the agile model most suited to the development of small projects. 148  Face-to-face at whiteboard Effectiveness of Face-to-face conversation Communication Modes Communication Effectiveness Video conversation Modeling Phone Options conversation Videotape Email conversation Audiotape Documentation Options Paper Cold Hot Richness of Communication Channel Copyright 2002-2005 Scott W. Ambler Original Diagram Copyright 2002 Alistair Cockburn 149  Agile Model: Principles The primary measure of progress: – Incremental release of working software Important principles behind agile model: – Frequent delivery of versions --- once every few weeks. – Requirements change requests are easily accommodated. – Close cooperation between customers and developers. – Face-to-face communication among team members. 150  Travel light: Agile Documentation – You need far less documentation than you think. Agile documents: – Are concise – Describe information that is less likely to change – Describe “good things to know” – Are sufficiently accurate, consistent, and detailed Valid reasons to document: – Project stakeholders require it – To define a contract model – To support communication with an external group – To think something through 151  Agile Software Requirements Management High { Each iteration implement the highest- Priority priority requirements Each new requirement is prioritized and added to the stack Requirements may be reprioritized at any time Requirements may be removed at any time Low Priority Requirements Copyright 2004 Scott W. Ambler 152  Adoption Detractors Sketchy definitions, make it possible to have – Inconsistent and diverse definitions High quality people skills required Short iterations inhibit long-term perspective Higher risks due to feature creep: – Harder to manage feature creep and customer expectations – Difficult to quantify cost, time, quality. 153  Agile Model Shortcomings Derives agility through developing tacit knowledge within the team, rather than any formal document: – Can be misinterpreted… – External review difficult to get… – When project is complete, and team disperses, maintenance becomes difficult… 154  Agile Model versus Iterative Waterfall Model The waterfall model steps through in a planned sequence: – Requirements-capture, analysis, design, coding, and testing. Progress is measured in terms of delivered artefacts: – Requirement specifications, design documents, test plans, code reviews, etc. In contrast agile model sequences: – Delivery of working versions of a product in several increments. 155  Agile Model versus Iterative Waterfall Model As regards to similarity: – We can say that Agile teams use the waterfall model on a small scale. 156  Agile versus RAD Model Agile model does not recommend developing prototypes: – Systematic development of each incremental feature is emphasized. In contrast: – RAD is based on designing quick-and-dirty prototypes, which are then refined into production quality code. 157  Agile versus exploratory programming Similarity: – Frequent re-evaluation of plans, – Emphasis on face-to-face communication, – Relatively sparse use of documents. Agile teams, however, do follow defined and disciplined processes and carry out rigorous designs: – This is in contrast to chaotic coding in exploratory programming. 158  Extreme Programming (XP) 7/18/2020 159  Extreme Programming Model Extreme programming (XP) was proposed by Kent Beck in 1999. The methodology got its name from the fact that: – Recommends taking the best practices to extreme levels. – If something is good, why not do it all the time. 160  If code review is good: Taking Good – Always review --- pair programming Practices to Extreme If testing is good: – Continually write and execute test cases --- test-driven development If incremental development is good: – Come up with new increments every few days If simplicity is good: – Create the simplest design that will support only the currently required functionality. 161  Taking to Extreme If design is good, – everybody will design daily (refactoring) If architecture is important, – everybody will work at defining and refining the architecture (metaphor) If integration testing is important, – build and integrate test several times a day (continuous integration) 162  Communication: 4 Values – Enhance communication among team members and with the customers. Simplicity: – Build something simple that will work today rather than something that takes time and yet never used – May not pay attention for tomorrow Feedback: – System staying out of users is trouble waiting to happen Courage: – Don’t hesitate to discard code 163  Best Practices Coding: – without code it is not possible to have a working system. – Utmost attention needs to be placed on coding. Testing: – Testing is the primary means for developing a fault-free product. Listening: – Careful listening to the customers is essential to develop a good quality product. 164  Best Practices Designing: – Without proper design, a system implementation becomes too complex – The dependencies within the system become too numerous to comprehend. Feedback: – Feedback is important in learning customer requirements. 165  XP Planning Begins with the creation of “user stories” Agile team assesses each story and assigns a cost Extreme Stories are grouped to for a deliverable increment Programming A commitment is made on delivery date Activities XP Design Follows the KIS principle Encourage the use of CRC cards For difficult design problems, suggests the creation of “spike solutions”—a design prototype Encourages “refactoring”—an iterative refinement of the internal program design 166  XP Coding Recommends the construction of unit test cases before coding commences (test-driven development) Encourages “pair programming” Extreme Programming XP Testing Activities All unit tests are executed daily “Acceptance tests” are defined by the customer and executed to assess customer visible functionalities 167  Full List of XP Practices 1. Planning – determine scope of the next release by combining business priorities and technical estimates 2. Small releases – put a simple system into production, then release new versions in very short cycles 3. Metaphor – all development is guided by a simple shared story of how the whole system works 4. Simple design – system is to be designed as simple as possible 5. Testing – programmers continuously write and execute unit tests 168  Full List of XP Practices 7. Refactoring – programmers continuously restructure the system without changing its behavior to remove duplication and simplify 8. Pair-programming -- all production code is written with two programmers at one machine 9. Collective ownership – anyone can change any code anywhere in the system at any time. 10. Continuous integration – integrate and build the system many times a day – every time a task is completed. 169  Full List of XP Practices 11. 40-hour week – work no more than 40 hours a week as a rule 12. On-site customer – a user is a part of the team and available full- time to answer questions 13. Coding standards – programmers write all code in accordance with rules emphasizing communication through the code 170  Emphasizes Test-Driven Development (TDD) Based on user story develop test cases Implement a quick and dirty feature every couple of days: – Get customer feedback – Alter if necessary – Refactor Take up next feature 171  Project Characteristics that Suggest Suitability of Extreme Programming Projects involving new technology or research projects. – In this case, the requirements change rapidly and unforeseen technical problems need to be resolved. Small projects: – These are easily developed using extreme programming. 172  Practice Questions What are the stages of iterative waterfall model? What are the disadvantages of the iterative waterfall model? Why has agile model become so popular? What difficulties might be faced if no life cycle model is followed for a certain large project? 173  Suggest Suitable Life Cycle Model A software for an academic institution to automate its: – Course registration and grading – Fee collection – Staff salary – Purchase and store inventory The software would be developed by tailoring a similar software that was developed for another educational institution: – 70% reuse – 10% new code and 20% modification 174  Practice Questions Which types of risks can be better handled using the spiral model compared to the prototyping model? Which type of process model is suitable for the following projects: – A customization software – A payroll software for contract employees that would be add on to an existing payroll software 175  Practice Questions Which lifecycle model would you select for the following project which has been awarded to us by a mobile phone vendor: – A new mobile operating system by upgrading the existing operating system – Needs to work well efficiently with 4G systems – Power usage minimization – Directly upload backup data on a cloud infrastructure maintained by the mobile phone vendor 176 Scrum 177  Scrum: Characteristics Self-organizing teams Product progresses in a series of month-long sprints Requirements are captured as items in a list of product backlog One of the agile processes 178  Daily Scrum Sprint Sprint planning review Scrum Sprint Product backlog backlog Product increment 179  Sprint Scrum projects progress in a series of “sprints” – Analogous to XP iterations or time boxes – Target duration is one month Software increment is designed, coded, and tested during the sprint No changes entertained during a sprint 180  Scrum Framework Roles : Product Owner, ScrumMaster, Team Ceremonies : Sprint Planning, Sprint Review, Sprint Retrospective, and Daily Scrum Meeting Artifacts : Product Backlog, Sprint Backlog, and Burndown Chart 181  Key Roles and Responsibilities in Scrum Process Product Owner – Acts on behalf of customers to represent their interests. Development Team – Team of five-nine people with cross-functional skill sets. Scrum Master (aka Project Manager) – Facilitates scrum process and resolves impediments at the team and organization level by acting as a buffer between the team and outside interference. 182  Product Owner Defines the features of the product Decide on release date and content Prioritize features according to market value Adjust features and priority every iteration, as needed Accept or reject work results. 183  The Scrum Master Represents management to the project Removes impediments Ensure that the team is fully functional and productive Enable close cooperation across all roles and functions Shield the team from external interferences 184  Scrum Team Typically 5-10 people Cross-functional – QA, Programmers, UI Designers, etc. Teams are self-organizing Membership can change only between sprints 185  Ceremonies Sprint Planning Meeting Sprint Daily Scrum Sprint Review Meeting 186  Sprint Planning Goal is to produce Sprint Backlog Product owner works with the Team to negotiate what Backlog Items the Team will work on in order to meet Release Goals Scrum Master ensures Team agrees to realistic goals 187  Sprint Fundamental process flow of Scrum A month-long iteration, during which an incremental product functionality completed NO outside influence can interfere with the Scrum team during the Sprint Each day begins with the Daily Scrum Meeting 188  Daily 15-minutes Stand-up meeting Daily Scrum Not for problem solving Three questions: 1. What did you do yesterday 2. What will you do today? 3. What obstacles are in your way? 189  Is NOT a problem solving session Daily Scrum Is NOT a way to collect information about WHO is behind the schedule Is a meeting in which team members make commitments to each other and to the Scrum Master Is a good way for a Scrum Master to track the progress of the Team 190  Team presents what it accomplished during the sprint Typically takes the form of a demo of new features Informal – 2-hour prep time rule Sprint Review Participants Meeting – Customers – Management – Product Owner – Other engineers 191  Product Backlog A list of all desired work on the project – Usually a combination of story-based work (“let user search and replace”) task-based work (“improve exception handling”) List is prioritized by the Product Owner – Typically a Product Manager, Marketing, Internal Customer, etc. 192  Product Backlog Requirements for a system, expressed as a prioritized list of Backlog Items – Managed and owned by Product Owner – Spreadsheet (typically) – Usually is created during the Sprint Planning Meeting 193 Sample Product Backlog 194  Sprint Backlog A subset of Product Backlog Items, which define the work for a Sprint – Created by Team members – Each Item has it’s own status – Updated daily 195  Sprint Backlog during the Sprint Changes occur: – Team adds new tasks whenever they need to in order to meet the Sprint Goal – Team can remove unnecessary tasks – But: Sprint Backlog can only be updated by the team Estimates are updated whenever there’s new information 196  Burn down Charts Are used to represent “work done”. Are remarkably simple but effective Information disseminators 3 Types: – Sprint Burn down Chart (progress of the Sprint) – Release Burn down Chart (progress of release) – Product Burn down chart (progress of the Product) 197  Sprint Burn down Chart Depicts the total Sprint Backlog hours remaining per day Shows the estimated amount of time to release Ideally should burn down to zero to the end of the Sprint Actually is not a straight line 198 Sprint Burndown Chart 199  Release Burndown Chart Will the final release be done on right time? How many more sprints? X-axis: sprints Y-axis: amount of story points remaining 200  Product Burndown Chart Is a “big picture” view of project’s progress (all the releases) 201  Scalability of Scrum A typical Scrum team is 6-10 people Jeff Sutherland - up to over 800 people "Scrum of Scrums" or what called "Meta-Scrum“ Frequency of meetings is based on the degree of coupling between packets 202  Faculty Name Department Name 203  Agile vs. Plan-Driven Processes 1. Small products and teams: 1. Large products and teams;  Scalability limited  hard to scale down 2. Untested on safety-critical 2. Proven for highly critical products products; 3. Good for dynamic, but 3. Good for stable: expensive for stable  But expensive for dynamic environments. environments 4. Require experienced 4. Require only few experienced personnel throughout personnel 5. Personnel thrive on freedom 5. Personnel thrive on structure and chaos and order 204