SDLC Models Bessy Charles & Meera Vijayaraghavan Cognizant Technology Solutions

1. SDLC ModelsBessy Charles & Meera VijayaraghavanCognizant Technology Solutions

2. Software Development Life Cycle • A series of steps that organizes the development of a software product • Duration can take several days or years • Phases provide manageability & organization. At a bare minimum, a development life cycle should have the following phases & their respective outputs: • Requirements - Software Requirements Specification • System Design - Design Document • Program Implementation - Code • Testing - Test Report, Change Requests • Life cycle components are the 4Ps - People, Process, Product, Phases

3. Life Cycle Models • Life cycle models make software development predictable, repeatable, measurable & efficient • A high-quality model based on the life cycle increases the chance of a high-quality deliverable • Provides framework for a standard set of terminology, activities & deliverables • Increases ease of tracking project progress by all stake holders • Provides a formal basis for planning, estimating & scheduling

4. Definitions • METHODOLOGY = MODEL + TECHNIQUE • A methodology is composed of 1 or more models used in conjunction with 1 or more techniques • Model identifies the various phases & inter-connections that the life cycle will have • A technique is a way to implement the model • A model dictates that the requirements should be collected. If the JAD technique is applied, the requirements would be collected over a series of face to face sessions with all the key stake holders • A model dictates that defects should be removed. If the Clean Room technique is applied, it achieves this through formal inspections & automated syntax checks

5. Models Common Models • Waterfall • Incremental • Incremental/Iterative - Design to Schedule • Spiral Model • Rapid Application Development – RAD • Evolutionary Prototyping

6. Waterfall

7. What is Waterfall? • Origins • Proposed in the early 70s & widely used even today • Based strongly on the way hardware systems are designed & implemented • A model of the software development process in which the constituent activities - concept, requirements, design, development, testing & installation- are performed in a linear order. • There is a single pass through each phase. Overlap between these phases is neither precluded nor mandated. • There is little or no iterative development • Ergo, each phase “pours over” to the next.

8. Planning & Definition Requirements Analysis Design Code & Unit Test Formal Test Implement TIME Model Schematic • Embark on a life cycle phase. • Conduct formal reviews with the client after completing a phase. Check progress made. Incorporate review comments. • Freeze the deliverables from the phase • Start the next phase.

9. Requirements Req. Change Verify Design Verify Implementation Operations Test Retirement Waterfall with Back-flow • Modification an attempt to make the linear model more flexible to change. • If a problem is detected/scope is changed in 1 phase, corresponding changes should be made to the previous phase.

10. Constraints • No phase is complete until the documentation for that phase has been completed& the products of that phase have been approved by the SQA • A formal change control procedure is needed to address changes that might arise in any of the prior deliverables • Once the product has been accepted, any change constitutes maintenance • Software configuration consists of specification, design, code, user manual, operations manual, test procedure & results • In the pure waterfall, each major phase begins only after the previous phase has finished. In the modified waterfall a feedback loop permits modifications to the previous phase(s)

11. Candidate Projects • Requirements are stable, clear & unambiguous. Customers know what they want & they are ready to commit. • Technology & methodology are well understood by the development team. This is crucial, as Waterfall does not tolerate reopening prior baselines • Problem is complex (so, it warrants a heavy methodology) & well understood (so there will not be many regrettable mistakes) • When smaller software applications are being developed (so scope change will not occur)

12. Advantages • Enforces a disciplined, engineering approach • A formal process makes progress measurable • Produces software artifacts that can be reused in other projects • Experience in applying steps in past projects can be used in estimating the duration of steps in future projects • Discourages jumping ahead • Emphasizes planning and good requirements. • It is possible to create a clean design from the requirements • Verification is done after each phase • Increases visibility of the process through increased documentation • Documentation produced can reduce maintenance costs

13. Disadvantages • Requirements must be fully specified up front • Product is not delivered till the end • It is difficult & expensive to repeat phases • Sequential process means certain parts may be stalled while waiting for upstream parts to complete • Generates few visible signs of progress until the very end. Feedback happens too late in the life-cycle. • Since the Waterfall model prevents iterative development, it suffers from the following problems: • Inflexible. Every phase creates a deliverable, which is frozen at the end of the phase. • Requirements change over time. A model which relies on frozen baselines has little tolerance for scope creep. • A linear project is long drawn. The business objectives of an organization might have changed in the mean time.

14. Incremental Model

15. What is an Incremental Model? • Also called Staged Delivery Model • Performs the waterfall in overlapping sections, attempting to compensate for the length of projects by producing usable functionality earlier • All the requirements are collected in one-shot. The technical architecture is finalized up-front • The objectives are divided into several increments or builds. • The 1st build is developed & delivered. This is followed by the next portion till all the objectives have been met.

16. Planning & Definition Know what is going to be built Requirements Analysis Architectural Design Detailed Design Release 1 Detailed Design Code ….. ….. Code Test Test Deliver Deliver in stages or increments Release N Deliver Model Schematic • Plan the project, finalize objectives • Requirements Collection • Technical architecture • Divide the objectives into increments For each increment: • High level & Detailed Design • Implementation in Code & Unit testing • System & Integration testing • Deliver the build

17. Design to Schedule

18. What is Design to Schedule? • Also called Iterative/Incremental. • Very similar to the incremental model: • The full product is planned up-front. • All the requirements are collected • The technical architecture is finalized • Delivery is staged • The differences are: • Staged delivery is based on priority. Features with the highest priority are implemented first. • All the stages or increments may not be delivered. Features with the lowest priority may never be developed. • Every increment is iterative - the build is divided into several pieces & developed 1 by one. Iterations are delivered together, in 1 final build

19. What is Design to Schedule? Summing up, the fundamental differences between an “iteration” & an “increment” are: • Each iteration implements a subset of requirements through the test phase • Each iteration adds new functionality and/or refines existing functionality • Each increment corresponds to a release with new functionality • Each increment has gone through several iterations • Note that iterations need neither involve nor preclude prototypes

20. Planning & Definition Requirements Analysis High priority features Architectural Design Detailed Design Code Test Medium priority features Detailed Design Code Delivery Date Detailed Design Low priority features Test Code Test Deliver Model Schematic • Plan the project, finalize objectives • Requirements Collection • Technical architecture • Divide the objectives into increments For each increment: • Divide the increment into iterations • For each iteration • High level & Detailed Design • Implementation in Code & Unit testing • System & Integration testing • Consolidate all iterations & deliver the build

21. Constraints • The system must enable splitting an increment into smaller modules • There must be few inter-dependent modules & interfaces with other applications • Iterative development of non-trivial systems is not easy. A lot of planning is needed to split a build into components • It requires a lot of coordination if multiple iterations are carried out in parallel • The design of the higher priority items must be air-tight. Otherwise, it would conflict later with the later iterations • The stake holders should decide the overall priorities - not the development team • The organization has good change control, configuration management & integration plans • Objective measures of tracking progress are needed • An overall architecture team which stresses on reuse, defines the architecture & ensures clear understanding of the high level design

22. Candidate Projects • Clients are sure of the priority of their objectives • Clients need feedback after deployment to decide when to stop development • Clients are unsure of the ROI for each set of priorities • Ideally suited for mass market products - such as web browsers or B2C sites, where early, high priority features could be introduced • Any experimental market, where the ROI is not guaranteed • Application can be fabricated as a series of fairly independent modules • Clients are willing to participate full fledged in the testing & deployment of the iterations • Infrastructure changes can not be developed in this model in a cost effective manner

23. Sample Methodologies based on these models Industry Methodologies based on (some of) these models • Rational Unified Process – RUP • SUMMIT • Agile Methodologies etc.

24. Sample Case Study • Today’s Business Need • Speed • Agility • No compromise with quality • Client’s Situation • A web-based reporting tool for generating / viewing web based reports for Sales, Labor, Profit and Loss, Sales Items figures and 52 week trend for their respective stores and roll-ups • 14 person month project needed to be executed within in 3 month • Objective : to deliver business results in the right cycle time • Expected Outcome : • Shortened turnaround time • Increased productivity

25. Results- highlights of implementation • The project was executed in 11 cycles • Original plan : 7 cycles • 39 % change in effort • Initial effort 14.1 Person Month (PM) & final effort 19.6 PM • 56 % addition in requirement • 9 new requirements were added to the originally foreseen 16 requirements Contd.

26. Results- highlights of implementation • The Quality of software delivered was high. The proportion of defects reported in the cycle end QA feedback from the client was only 10%. The rest were all change requests and went as high as 90+ items. • The net effort and schedule variation at the end of cycle 11 was 6% (well within the Control Limit of 10%) • The average productivity for the project stood at 12.6 FP/PM.

27. Results Cycle Effort variation

28. Results Cycle Schedule variation

29. Results Cycle Defect Density Trend

30. Results Productivity

31. Rational Unified Process The basic tenets of RUP are: • Develop Software in an iterative & Incremental mode • See the advantages of the “iterative model” (Design to schedule) & the advantages of the “Incremental model” • Manage Requirements • All the stake holders must have the same expectations, to avoid scope creep • Use component based architecture • Use prototypes that evolve into the final system • Approach the architecture methodically • To reduce the development time, buy & integrate

32. Problems Addressed by RUP • Visually model software • UML does not describe how to develop software • RUP describes how to use UML effectively for modeling • It describes the models needed, why they are needed & how to construct them • Continuously verify software quality • RUP stresses on process quality & product quality • RUP does not predicate how this should be done, though • Control changes to software • This is crucial in an iterative development environment, to keep everything in sync. • RUP suggests a robust configuration management, change control, issue tracking & metrics collection to accomplish ultimate control over an iterative project

33. What is RUP? • RUP is a Software Engineering Framework that can be customized & tailored to suit the needs of an organization. • It is an object oriented Process Product that is integrated with the Rational suite of products • It captures many of the best practices harvested by Rational over the years • It is tightly integrated with UML. RUP itself was designed & documented using UML • It is delivered online using web technology. Regular upgrades are released by Rational approximately twice a year

34. Principles of Operation In RUP, the development lifecycle is presented from 2 perspectives: • Management Perspective or the Horizontal Dimension • This indicates changes that happen to the project over time • System development goes through 4 lifecycle phases - Inception, Elaboration, construction & Transition • Shows the dynamic aspect of the process expressed in terms of cycles, phases, iterations or milestones

35. Principles of Operation • Development Perspective or the Vertical Dimension • This shows the unwavering project management principles that should be applied throughout the life cycle • Iterative versions of the system are built in increments. • The activities performed during an iteration have are grouped into a set of 5 core work-flows - Business Modeling, Requirements, Analysis & Design, Implementation & Test • Each core workflow describes some aspect of the system, resulting in a model of the system, or a set of documents • Shows the static aspect of the process components in terms of activities, disciplines, artifacts & roles

36. Work Flow Details • Business engineering • The purpose is to assess the organization in which the system will be used, to understand the needs and problems that is to be solved by the system. • The result is a business use-case model and a business object model. • This workflow is optional for simplistic organizations. • Requirements • The purpose is to capture and evaluate the requirements, placing usability in focus. • This results in a use-case model, with actors representing external units communicating with the system, and use cases representing transaction sequences. • Analysis & Design • The purpose is to investigate the implementation environment and the effect it will have on the construction of the system.

37. Work Flow Details • This results in an object model (the design model), including use-case realizations that show how the objects communicate to perform the flow of the use cases. This might include interface definitions for classes and subsystems, specifying their responsibilities in terms of provided operations. • Implementation • The purpose is to implement the system in the prescribed implementation environment. • This results in source code, executables, and files. • Test • The purpose is to ensure that the system is the one intended, and that there are no errors. • This results in a certified system that is ready for delivery.

38. Model Schematic Source :http://www-306.ibm.com/software/rational

39. Understand Stakeholder Needs Define the System Manage Scope of the System Refine System Definition Architectural Analysis Manage changing requirement Architectural Design Plan and Design Test Database Design Plan Integration Structure the implementation Model Implement Classes Integrate each subsystem Execute Integration test Evaluate test Integrate the System Execute System Test Model Schematic

40. Workflow Schematic

41. Agile Methodology Agile is the label given to a growing number of methodologies with names like Scrum, Crystal, Adaptive, Feature-Driven Development and Dynamic Systems Development Method (DSDM). These new development approaches are based on the premise that if you hire competent developers, presumably they know how to write code. Any problems your developers encounter, therefore, aren't coding issues but organizational and communications ones, and those are what the agile approaches attempt to address.

42. Agile Programming Systems Extreme Programming Built around 12 basic practices ranging from pair programming to frequent refactoring, this approach is more prescriptive than the others. For more information, visit www.extremeprogramming.org and www.xprogramming.com or read Extreme Programming Explained: Embrace Change, by Kent Beck (Addison Wesley Longman Inc., 1999). Scrum Based on the empirical process control model, Scrum programming relies on self-directed teams and dispenses with much advanced planning, task definition and management reporting. To learn more, visit www.controlchaos.com or read Agile Software Development with Scrum, by Ken Schwaber and Mike Beedle (Prentice Hall PTR, 2001). Crystal This approach empowers the team to define the development process and refine it in subsequent iterations until it's stable. To learn more, visit crystalmethodologies.org/ or read Agile Software Development: Software Through People, by Alistair Cockburn (Addison Wesley Longman, 2001).

43. Agile Programming Systems…Contd. Adaptive: Based on adaptive rather than deterministic theories, this approach offers a series of frameworks to apply adaptive principles and encourage collaboration. For more information, visit www.adaptivesd.com or read Adaptive Software Development: A Collaborative Approach to Managing Complex Systems, by James A. Highsmith III (Dorset House Publishing, 2000). Dynamic Systems Development Method Conceived as a methodology for rapid application development, DSDM relies on a set of principles that include empowered teams, frequent deliverables, incremental development and integrated testing. For more information, visit www.dsdm.org or read DSDM: The Method in Practice, by Jennifer Stapleton (Addison Wesley Longman, 1997).

44. Sample Agile MethodologyFeature Driven development - History FDD was initially devised by Jeff De Luca to meet the specific needs of a 15 month, 50 person software development project at a large Singapore bank in 1997. What Jeff De Luca delivered was a set of five processes that covered the development of an overall model and the listing, planning, design and building of features. The first process is heavily influenced by Peter Coad´s approach to object modeling. The second process incorporates Peter Coad´s ideas of using a feature list to manage functional requirements and development tasks. The other processes and the blending of the processes into a cohesive whole is a result of Jeff De Luca´s experience. Since its successful use on the Singapore project there have been several implementations of FDD.

45. Feature Driven development- Overview • FDD is a model-driven short-iteration process that consists of five basic activities. For accurate state reporting and keeping track of the software development project milestones that mark the progress made on each feature are defined. This section gives a high level overview of the activities. • FDD describes five basic activities that are performed within the software development process. • Develop Overall Model • Build Feature List • Plan By Feature • Design By Feature • Build By Feature

46. Feature-Driven Development-Activities -Develop Overall Model • The project starts with a high-level walkthrough of the scope of the system and its context is performed. Next, detailed domain walkthroughs are held for each modeling area. In support of each domain, walkthrough models are then composed by small groups which are presented for peer review and discussion. One of the proposed models or a merge of them is selected which becomes the model for that particular domain area. Domain area models are merged into an overall model, the overall model shape being adjusted along the way. • Form modeling Team • Conduct Domain walkthrough • If requirements not clear, study the documentation • Develop small group models • Develop team models • Refine overall object model • View Models

47. Feature-Driven Development-Activities -Build Feature List The knowledge that is gathered during the initial modeling is used to identify a list of features. This is done by functionally decomposing the domain into subject areas. Subject areas each contain business activities, the steps within each business activity form the categorized feature list. Features in this respect are small pieces of client-valued functions expressed in the form <action> <result> <object>, for example: ´Calculate the total of a sale´ or ´Validate the password of a user´. Features should not take more than two weeks to complete, else they should be broken down into smaller pieces. • Form feature list teams • Build feature list

48. Feature-Driven Development-Activities -Plan by feature Now that the feature list is complete, the next step is to produce the development plan. Class ownership is done by ordering and assigning features (or feature sets) as classes to chief programmers. • Form planning team • Design Development Sequence • Assign business activities to chief programmers • Assign classes to developers

49. Feature-Driven Development-Activities -Design by feature A design package is produced for each feature. A chief programmer selects a small group of features that are to be developed within two weeks. Together with the corresponding class owners, the chief programmer works out detailed sequence diagrams for each feature and refines the overall model. Next, the class and method prologues are written and finally a design inspection is held. • Form feature team • Conduct domain walkthrough • Study referenced documents • Develop sequence diagrams • Refine object model • Write class and method overview • Design Inspection

50. Feature-Driven Development-Activities -Build by Feature After a successful design inspection a per feature activity to produce a completed client-valued function (feature) is being produced. The class owners develop the actual code for their classes. After a unit test and a successful code inspection, the completed feature is promoted to the main build. • Implement classes and methods • Inspect code • Conduct Unit Test • Promote to build