Successfully reported this slideshow.

Agile Software Development


Published on

  • Be the first to comment

  • Be the first to like this

Agile Software Development

  1. 1. Agile Software Development
  2. 2. Traditional Software Development 1. Initiation (RFP) 2. Feasibility study • Technical – can we build it? • Economic – should we build it? • Operational – if we build it, will it be used? • Schedule – will it be ready in time? 3. Requirements definition 4. Specifications 5. Project plan
  3. 3. Traditional Software Development 6. Logical design (external view) 7. Physical design (internal view) 8. Coding (or code acquisition) 9. Testing 10.Maintenance SDLC – Investigate, Analyze, Design, Implement and Maintain
  4. 4. Plan Driven Approach • Roots may be traced to engineering concepts • Standards and well-defined processes – process discipline • Adherence to processes • Completeness of documentation • Traceability across requirements, design, and code is mandatory
  5. 5. Plan driven Approach • Processes are defined, standardized, and incrementally improved • Standardization allows for comparisons and repeatability • Training, getting information, and estimating are supposedly easier • Less need for retraining • People can be replaced! Loss of key personnel does not doom a project!
  6. 6. Advantages • Easy to understand, easy to use • Provides structure to inexperienced staff • Milestones are well understood • Sets requirements stability • Good for management control (plan, staff, track) • Aim for predictability and stability • Plan extensively at the outset to anticipate changes/variations • They try to tame change • Emphasis on quality of software and predictability • Exemplified by the Capability Maturity Model
  7. 7. Capability Maturity Model • A bench-mark for measuring the maturity of an organization’s software process • CMM defines 5 levels of process maturity based on certain Key Process Areas (KPA) • SEI rates organization on their maturity levels.
  8. 8. Capability Maturity Model Level Focus Key Process Area Defect Prevention, Technology Change Management, Process 5 – Optimizing (1%) Continual process improvement Change Management Quantitative process and 4 – Managed (5%) Product and process quality software quality management Organizational process focus, organizational process definition, training program, integrated software management, software Engineering processes and product engineering, inter-group 3 – Defined (10%) organizational support coordination, peer reviews Requirements management, software project planning, sw project tracking & oversight, sw 2 – Repeatable (15%) Project management processes subcontract management, 1 – Initial (a little less than 70%) Competent people & heroics - ad hoc
  9. 9. Disadvantages However • All requirements must be known upfront • Deliverables created for each phase are considered frozen – inhibits flexibility • Can give a false impression of progress • Does not reflect problem-solving nature of software development – iterations of phases • Integration is one big bang at the end • Little opportunity for customer to preview the system (until it may be too late)
  10. 10. Challenges Standish Group: > 50% of software projects fail to meet their productivity, cost or functionality goals • Changing requirements (25%?) • User involvement (13%?) • Executive Support (7.5%?) • Lack of skills/technical incompetence (7%) • Lack of resources (6.4%) • Unrealistic expectations (6%?) • Unclear objectives (5.3%) • Unrealistic deadlines/time-frames (4.3%)
  11. 11. Discipline vs Agility • Discipline creates well-organized memories, history, and experience • Agility makes use of memory and history to adapt, react, and to be opportunistic • What do you think is more important? Why?
  12. 12. Agile Manifesto Value: • Individuals and their interactions over processes and tools • Working software over comprehensive documentation • Customer collaboration over contract negotiation • Responding to change over following a plan
  13. 13. Agile Methods • Agile software development is a conceptual framework for undertaking software engineering projects. • Most agile methods attempt to minimize risk by developing software in short timeboxes, called iterations, which may typically last one to four weeks. • Each iteration is like a miniature software project of its own, and includes all of the tasks necessary to release the mini-increment of new functionality. • Agile methods emphasize realtime communication, preferably face-to-face, over written documents. • Agile methods rely on the close collaboration of activity engaged individuals with ordinary talents and has the ability to flexibly schedule the implementation of functionality, responding to changing business needs.
  14. 14. Examples • Extreme Programming ( X P) • Adaptive Software Development • Crystal • Scrum • Feature-Driven Development
  15. 15. Extreme programming Practices 1. Planning game – 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 cycle 3. Metaphor – all development is guided by a simple shared story of how the whole system works 4. Simple design – system is designed as simply as possible (extra complexity removed as soon as found) 5. Testing – programmers continuously write unit tests; customers write tests for features 6. Refactoring – programmers continuously restructure the system without changing its behavior to remove duplication and simplify
  16. 16. Extreme programming Practices 7. Pair-programming -- all production code is written with two programmers at one machine 8. Collective ownership – anyone can change any code anywhere in the system at any time. 9. Continuous integration – integrate and build the system many times a day – every time a task is completed. 10. 40-hour week – work no more than 40 hours a week as a rule 11. On-site customer – a user is on the team and available full-time to answer questions 12. Coding standards – programmers write all code in accordance with rules emphasizing communication through the code