02 different approaches

Download 02 different approaches

Post on 14-Jan-2015




2 download

Embed Size (px)




  • 1. Approaches to the SDLC

2. Software Methodology is themachine we use to makesoftware Structured programming Cap Gemini SDM SSADM RAD Scrum XP USDP 3. Essential Activities Regardless of the process, method or lifecycle, thefollowing activities are performed in creating qualityrequirements: Gather includes activities associated with the collectionof the requirements from the various sources includingdocument and stakeholders. Analyze includes activities associated with thenegotiation and determination of what therequirements actually mean and which stakeholdersrequirements take priority. It determines whichrequirements should be addressed in this project. Organize is the documentation and organizing of therequirements. Normally requirements can be classifiedinto functional and non-functional requirements. Approve is the confirmation and signoff from thestakeholders that these are the requirements they wantto be addressed in this project. 4. But there are different waysto put these activitiestogether Three main SDLC methods Waterfall Iterative Any combination of the above 5. Waterfall processes arehighly structured Projects with very well defined and stablerequirements should consider selecting thewaterfall lifecycle. Some problems with the waterfall: Late validation means mistakes cost more. The customer does not see the product until the projects end during user acceptance tests. If requirements were incorrect, the wrong product may have been built, requiring costly rework. Errors are not found in the phase where generated. The waterfall does not reflect the way systems are really developed. Frequent iterations are often necessary. 6. Incremental development The system as specified in the requirements documents is partitioned into subsystems by functionality. Each release adds a new functionality to the system. Iterative development Delivers a full system at the very beginning and then changes the functionality of each subsystem with each new release. Iterative processes are flexible 7. Combinations can combinethe best of both Tune it to your organization 8. Lets look at two examples SSADM is a waterfall methodology USDP is an iterative methodology 9. SSADM is one of the originals Developed for the UK Central Computer andTelecommunications Agency starting in 1980 Made mandatory in 1983 Revamped and renamed Business SystemDevelopment in 2000 10. The feel of SSADM High structure High ceremony High accountability Deep reach 11. SSADM has seven stages Feasibility study Investigation of the currentenvironment Business system options Requirements specification Technical systems options Logical design Physical design 12. Stage 0: Feasibility Study Product: a decision should we even do this? Sometimes it is a no-brainer. We must do it. Questions we ask: What else will have to change? Is it worth the investment? Is it the right thing to do? Is it ethical? Can we get the talent and equipment? 13. Stage 1: Investigation of theCurrent Environment Product: An analysis of where we are vs. where we need to be 14. Stage 2: Business SystemOptions Product: List of top 2-3 options to make theoutput of Stage 1 happen. All options are entertained. Criteria Costs vs. Benefits Ease of implementation Data: Logical data structure is documented 15. Stage 3: RequirementsSpecification Product: A full logistical spec document for thenew system. Must be free from: error ambiguity inconsistency Most difficult stage Data: ERDs and Data flow diagrams 16. Stage 4: Technical SystemOptionsOptions on: Product: Again, 2-3 options on bigpicture tech specifications Hardware This is after considering all options Software Data: Which RDBMS Staffing Physical space Power needs Deployment UX 17. Stage 5: Logical Design Product: A design document including userinterface screens, Step-by-step flow, and datadesigns We now know what every screen looks like Data: The full data catalog 18. Stage 6: Physical Design Product: Design document tells developers howto write the software and engineers how to puttogether the system Final stage Logical design is translated into real-world Logical data -> ERD Logical needs of the system -> machine, network, software specs 19. Why use SSADM? Established Well-defined Higher focus on data Sometimes you have no choice 20. Why not use SSADM? Expensive Slow Rigid 21. Structured Software Analysisand Design Methodology A well-established and proven methodology Highly structured Creates accountability and thoroughness Creates friction to progress Does not lend itself to agile development 22. Now lets lookat an iterativemethodology,USDP 23. USDP Phases and Iterations 24. Use casesdrive USDP 25. The Iterative Life Cycle is is not Planned Hacking away at code Managed A playpen for Predictable developers Change-tolerant Redesigning the same Inclusive - It involves thing over and overthe user/customer until it is perfectthroughout the An excuse for notprocess planning and Risk driven managing a project Something that affectsonly the developers ona project 26. Iterative developmentshould have Frequent releases of genuine functionality Continuous integration Not done in one lump near the delivery date Early and continual reduced risks 27. Regular releasesforce the team toclosure We have freedom to postponeissues to near future iterations,giving us time to solve them Non-developer support teammembers can schedule No 80/20 situation 28. Some risks are eliminatedalmost immediatelyInceptionWaterfall Elaboration Risk Construction TransitionPreliminary Architect. Architect. Devel.Devel.Devel.TransitionTransition Post-Iteration IterationIterationIteration Iteration Iteration Iteration IterationdeploymentTime 29. Use Cases Drive the IterationProcessInceptionElaborationConstruction TransitionIteration 1 Iteration 2Iteration 3 Mini-Waterfall ProcessIteration Planning Rqmts Capture Analysis & Design Implementation TestPrepare Release 30. The Iteration Life Cycle: AMini-WaterfallSelected scenarios Results of previous iterations Up-to-date risk assessment Controlled libraries of models, code, and tests Iteration Planning Requirements CaptureAnalysis & Design Implementation TestPrepare ReleaseRelease descriptionUpdated risk assessmentControlled libraries 31. Iteration Life Cycle Activities Iteration planning Before the iteration begins, the general objectives ofthe iteration should be established based on Results of previous iterations ( if any) Up-to-date risk assessment for the project Determine the evaluation criteria for this iteration Prepare detailed iteration plan for inclusion in thedevelopment plan Include intermediate milestones to monitor progress Include walkthroughs and reviews 32. Iteration Life Cycle Activities Requirements Capture Select/define the use cases to be implemented in this iteration Update the object model to reflect additional domain classes and associations discovered Develop a test plan for the iteration 33. Iteration Life Cycle Activities Analysis & Design Determine the classes to be developed or updatedin this iteration Update the object model to reflect additionaldesign classes and associations discovered Update the architecture document if needed Begin development of test procedures Implementation Automatically generate code from the designmodel Manually generate code for operations Complete test procedures Conduct unit and integration tests 34. Iteration Life Cycle Activities Test Integrate and test thedeveloped code with the rest ofthe system (previous releases) Capture and review test results Evaluate test results relative tothe evaluation criteria Conduct an iteration assessment Prepare the release description Synchronize code and designmodels Place products of the iteration incontrolled libraries 35. Work Allocation Within anIteration Work to be accomplished within an iteration isdetermined by The (new) use cases to be implemented The rework to be done Packages make convenient work packages fordevelopers High-level packages can be assigned to teams Lower-level packages can be assigned to individualdevelopers Use Cases make convenient work packages for testand assessment teams Packages are also useful in determining thegranularity at which configuration management willbe applied For example, check-in and check-out of individualpackages 36. Iteration Assessment Assess iteration results relative to the evaluationcriteria established during iteration planning: Functionality Performance Capacity Quality measures Consider external changes that have occurredduring this iteration For example, changes to requirements, user needs,competitors plans Determine what rework, if any, is required andassign it to the remaining iterations 37. How many iterations should I have? There is no right answer Typically, the more the better The shorter the iterations the better 38. Make your first iterationsuper-easy to hit It sets the tone for subsequent iterations The first iteration contains the highest learningcurve Implementation errors happen here So, put a small number of features in the firstiteration 39. Conclusion Every methodology contains these stages Analysis Design Coding Testing Implementation You can do them serially (waterfall - SSADM, eg.)or iteratively (agile USDP, eg.) or somecombination of the two Waterfall is more structured but agile reduces riskof all kinds Use cases form the basis of an agile project