Software development life cycles (sdlc)


Published on

Review of Project Management Methodologies
Software Development Life Cycles
(SDLC) by Maksym Dovgopolyi, PMP

Published in: Business
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Software development life cycles (sdlc)

  1. 1. Review of Project Management Methodologies for Software Development Life Circles (SDLC) Maksym Dovgopolyi, PMP 2012
  2. 2. Waterfall 1956 Incremental 1960 Prototyping 1970 Adaptive Software 1974 Spiral 1986 Dynamic SoftwareDevelopment 1994 Scrum 1995RUP, ExtremeProgramming Feature Driven 1996 Development methodologies 1997 Crystal clear 2003 RAD 2004 Timeline of Project management
  3. 3. WaterfallPrinciples:● Set of phases that are strictly one by one Requirements Design Implementation Test Installation Maintenance
  4. 4. WaterfallStrengths:● Easy to understand and use● Provides structure to inexperienced staff● Sets requirements Stability● Good for control (plan, staff, track)● Quality more important than cost or schedule
  5. 5. WaterfallWeaknesses:● All requirements must be known upfront● Inflexible, slow, costly● Little opportunity for customers● Difficult to respond to changes● Problems often are not discovered until system testing● Written specs are often difficult for users to read
  6. 6. WaterfallWhen to use:● Requirements are very well known● Product definition is stable● Technology is understood● New version of an existing product● Integration an existing product to the new platform● Project is large, expensive, complicated
  7. 7. IncrementalPrinciples:● A series of mini-waterfall development● By module implementation of total SystemFirst prioritize requirements of the system andthen implement them in group● Each release adds functionality to the previous release, until all designed functionality has been implemented
  8. 8. IncrementalStrengths:● Risk of changes in requirements is reduced● Customer gets important functionality early● Initial product delivery is faster● Lowers initial delivery cost● Customer can respond to each build
  9. 9. IncrementalWeaknesses:● Requires good planning and design● Requires early definition of done and fully functional system to allow for the definition of increments● Total cost of the complete system is still high
  10. 10. IncrementalWhen to use:● Web Information Systems (WIS)● Leading-edge applications● Large projects where requirements are not well understood● Project where budget and technical changes are expected● A need to get basic functionality to the market earlier
  11. 11. AgileSome of the most common methods amongothers:● Adaptive Software Development (ASD)● Feature Driven Development (FDD)● Crystal Clear● Rapid Application Development (RAD)● Scrum● Extreme Programming (XP)● Lean Software Development
  12. 12. Rapid Application Development (RAD)Principles:● Fast development and delivery of high quality system with low cost● Breaking the project into small segments● To produce high quality system quickly● Users closely involved in the system design● Uses “time boxes”● Iterative software product delivery
  13. 13. Rapid Application Development (RAD)Strengths● The operational version of app is available much earlier● Provides the ability to rapidly change system design as demanded● Generally savings in time, money and human effort● Time-box approach
  14. 14. Rapid Application Development (RAD)Weaknesses:● May lead to lower overall system quality● Could be Gold-plating● Potential for design system lack of scalability● Risk of never achieving closure
  15. 15. Rapid Application Development (RAD)Where to use:● Small or medium projects with short duration● Project scope is focused, business objectives are well defined● Functionality of the system is clearly visible in the user UI● End-users are involved● Team is stable and skilled● Input data for the project already exists● Technical architecture is defined● Tech requirements are reasonable and well within the capabilities of the technology being used● Low technical risks● System can be modularized
  16. 16. Extreme Programming (XP)Principles:● Coding is the key activity throughout the project● Communication among teammates is done with code
  17. 17. Extreme Programming (XP)Practices/Strengths:● Planning game ● Pair-programming (planning poker) ● Collective ownership● Small releases ● Continuous● Metaphor integration● Simple design ● 40 hours week● Testing ● On-site customer● Refactoring ● Coding standard ● Code review
  18. 18. SpiralCycles
  19. 19. SpiralPrinciples:● Identify and resolve risks by breaking a project into small segments● Study alternatives● Begin each cycle with an identification of stakeholders and End cycle with review and commitment
  20. 20. SpiralStrengths:● Provides early indication of risks● User sees the system earlier because of rapid prototyping tools● Critical high-risk functions are developed first● User can be closely tied to all life-cycle steps● Early and frequent feedback from user● Can incorporate Waterfall, Prototyping and Incremental methodologies depending on which of these models best fits a given iteration
  21. 21. SpiralWeaknesses:● Challenging to determine the exact composition of dev. methodology to use for each iteration around the Spiral● Highly customized to each project● PM has to be skilled and experienced to determine how to apply it● Each cycle may generate more work for the next cycle● Cycle continues with no clear termination condition; there is risk of not meeting budget or schedule● May be hard to define objectives, milestones
  22. 22. SpiralWhen to use:● Users/clients are unsure of their needs● Requirements are complex● Significant changes are expected● Real-time or safety-critical system● Risk avoidance is High priority● PM is highly skilled and experienced● Project might benefit from a mix of other development methodologies
  23. 23. PrototypingCycles: 1. Requirements Implementation,4. Testing 2. Design Maintenance Delivering 3. Coding
  24. 24. PrototypingPrinciples:● User is involved throughout of process● The basic understanding of the business problem is necessary to avoid solving the wrong problem● Split the project into small segments to reduce risks
  25. 25. PrototypingStrengths:● Provides quick implementation● Encourages innovation and flexible design● Helps to easily identify confusing or difficult or missing functionality● Useful to resolve unclear objectives● Improves user and developer communication with stakeholders
  26. 26. PrototypingWeaknesses:● Approval process and control is not strict● Requirements may frequently change significantly● Identification of non-functional elements is difficult to document● Can lead to poorly designed system (quick and dirty)● Can lead to false expectations – customer believes that system is “finished”. It looks good and has adequate user UI, but not truly functional
  27. 27. PrototypingWhere to use:● Online system requiring extensive user dialoging● Project is large with many users and functions, where project risks need to be reduced● Project objectives are unclear● Pressure of immediate implementation of something● Functional requirements may change frequently and significantly● User is not fully knowledgeable● Team members are experienced● Team composition is stable● PM is experienced● Not strict requirements for approval at design milestones● Analysts assess business problems before the project start
  28. 28. Good Luck!