Ad
More Related Content
Similar to Software Engineering Chapter-3 Process Models (20)
Recently uploaded (20)
Ad
Software Engineering Chapter-3 Process Models
- 1. Chapter 3 These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/ e (McGraw-Hill, 2009) Slides copyright 2009 by Roger Pressman. 1 ■ Agile Development Slide Set to accompany Software Engineering: A Practitioner’s Approach, 7/e by Roger S. Pressman Slides copyright © 1996, 2001, 2005, 2009 by Roger S. Pressman For non-profit educational use only May be reproduced ONLY for student use at the university level when used in conjunction with Software Engineering: A Practitioner's Approach, 7/e. Any other reproduction or use is prohibited without the express written permission of the author. All copyright information MUST appear if these slides are posted on a website for student use.
- 2. The Manifesto for Agile Software Development These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/ e (McGraw-Hill, 2009) Slides copyright 2009 by Roger Pressman. 2 “We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: • Individuals and interactions over processes and tools • Working software over comprehensive documentation • Customer collaboration over contract negotiation •Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more.” Kent Beck et al
- 3. What is “Agility”? These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/ e (McGraw-Hill, 2009) Slides copyright 2009 by Roger Pressman. 3 ■ ■ ■ ■ Effective (rapid and adaptive) response to change Effective communnication among all stakseholders Drawing the cunstomer onto the team Organizing a team so that it is in control of the works performed Yielding … ■ Rapid, incremental delivery of software
- 4. Agility and the Cost of Change These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/ e (McGraw-Hill, 2009) Slides copyright 2009 by Roger Pressman. 4
- 5. An Agile Process These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/ e (McGraw-Hill, 2009) Slides copyright 2009 by Roger Pressman. 5 ■ ■ ■ ■ ■ Is driven by cunstomer descriptions of what is requnired (scenarios) Recognizes that plans are short-lived Develops software iteratively with a heavy emphasis on construnction activities Delivers munltiple ‘software increments’ Adapts as changes occunr
- 6. Agility Principles - I These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/ e (McGraw-Hill, 2009) Slides copyright 2009 by Roger Pressman. 6 1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. 2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. 3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. 4. Business people and developers must work together daily throughout the project. 5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. 6. The most efcient and efective method of conveying information to and within a development team is face–to–face conversation.
- 7. Agility Principles - I I These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/ e (McGraw-Hill, 2009) Slides copyright 2009 by Roger Pressman. 7 7. Working software is the primary measure of progress. 8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. 9. Continuous attention to technical excellence and good design enhances agility. 10. Simplicity – the art of maximizing the amount of work not done – is essential. 11. The best architectures, requirements, and designs emerge from self–organizing teams. 12. At regular intervals, the team reflects on how to become more efective, then tunes and adjusts its behavior accordingly.
- 8. Hunman Factors These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/ e (McGraw-Hill, 2009) Slides copyright 2009 by Roger Pressman. 8 ■ ■ the process molds to the needs ofthe people and team, not the other way around key traits must exist among the people on an agile team and the team itself: ■ ■ ■ ■ ■ ■ ■ Competence. Common focus. Collaboration. Decision-making ability. Fuzzy problem-solving ability. Mutual trust and respect. Self-organization.
- 9. Extreme Programming (XP) These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/ e (McGraw-Hill, 2009) Slides copyright 2009 by Roger Pressman. 9 ■ ■ The most widely unsed agile process, originally proposed by Kent Becks XP Planning ■ ■ ■ ■ ■ Begins with the creation of “unser stories” Agile team assesses each story and assigns a cost Stories are grounped to for a deliverable increment A commitment is made on delivery date After the first increment “project velocity” is unsed to help define sunbsequnent delivery dates for other increments
- 10. Extreme Programming (XP) These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/ e (McGraw-Hill, 2009) Slides copyright 2009 by Roger Pressman. 10 ■ XP Design ■ ■ ■ ■ Follows the KI S principle Encounrage the unse of CRC cards (see Chapter 8) For difcunlt design problems, sunggests the creation of “spikse soluntions”—a design prototype Encounrages “refactoring”—an iterative refinement of the internal program design ■ ■ XP Coding ■ Recommends the construnction of a unnit test for a store before coding commences ■Encounrages “pair programming” XP Testing ■ All unnit tests are execunted daily ■ “Acceptance tests” are defined by the cunstomer and excunted to assess cunstomer visible funnctionality
- 11. Extreme Programming (XP) unit test continuous integration These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/ e (McGraw-Hill, 2009) Slides copyright 2009 by Roger Pressman. 11 acceptance testing user stories values acceptance test criteria iteration plan simple design CRC cards spike solutions prototypes refactoring pair programming Release softwareincremen t project velocitycomput ed
- 12. Adaptive Software Development These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/ e (McGraw-Hill, 2009) Slides copyright 2009 by Roger Pressman. 12 ■ Originally proposed by Jim Highsmith ■ ASD — distingunishing featunres ■ ■ ■ ■ ■ ■ Mission-driven planning Component- based focuns Uses “time-boxing” (See Chapter 24) Explicit consideration of riskss Emphasizes collaboration for requnirements gathering Emphasizes “learning” throunghount the process
- 13. Adaptive Software Development adaptive cycle planning uses mission statement project constraints basic requirements time-boxed release plan Requirements gathering J AD mini-specs components implemented/ tested focus groups for feedback formal technical reviews postmortems softwareincrement adjustmentsfor subsequent cycles Release These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/ e (McGraw-Hill, 2009) Slides copyright 2009 by Roger Pressman. 13
- 14. Dynamic Systems Development Method These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/ e (McGraw-Hill, 2009) Slides copyright 2009 by Roger Pressman. 14 ■ ■ Promoted by the DSDM Consortiunm ( www.dsdm.org) DSDM—distingunishing featunres ■ ■ Similar in most respects to XP and/or ASD Nine guniding principles • Active unser involvement is imperative. • DSDM teams m u n s t be empowered to makse decisions. • The focuns is on frequnent delivery of produncts. • Fitness for bunsiness punrpose is the essential criterion for acceptance of deliverables. • I terative and incremental development is necessary to converge on an accunrate bunsiness soluntion. • All changes dunring development are reversible. • Requnirements are baselined at a high level • Testing is integrated throunghount the life-cycle.
- 15. Dynamic Systems Development Method DSDM Life Cycle (with permission of the DSDM consortium) These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/ e (McGraw-Hill, 2009) Slides copyright 2009 by Roger Pressman. 15
- 16. Scrunm These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/ e (McGraw-Hill, 2009) Slides copyright 2009 by Roger Pressman. 16 ■ Originally proposed by Schwaber and Beedle ■ Scrunm—distingunishing featunres ■ Development works is partitioned into “packsets” ■ Testing and docunmentation are on-going as the produnct is construncted ■ Works occunrs in “sprints” and is derived from a “backslog” of existing requnirements ■ Meetings are very short and sometimes conduncted withount chairs ■ “demos” are delivered to the cunstomer with the time- box allocated
- 17. Scrunm ScrumProcessFlow(usedwithp ermission) These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/ e (McGraw-Hill, 2009) Slides copyright 2009 by Roger Pressman. 17
- 18. Crysta l These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/ e (McGraw-Hill, 2009) Slides copyright 2009 by Roger Pressman. 18 ■ ■ Proposed by Cocksbunrn and Highsmith Crystal—distingunishing featunres ■ ■ ■ Actunally a family of process models that allow “maneunverability” based on problem characteristics Face-to-face communnication is emphasized Sunggests the unse of “reflection worksshops” to review the works habits of the team
- 19. Featunre Driven Development These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/ e (McGraw-Hill, 2009) Slides copyright 2009 by Roger Pressman. 19 ■ ■ Originally proposed by Peter Coad et al FDD—distingunishing featunres ■ Emphasis is on defining “featunres” • a feature “is a client-valuned funnction that can be implemented in two weekss or less.” ■ Uses a featunre template • <action> the <resunlt> <by | for | of | to> a(n) <object> ■ ■ A featunres list is created and “plan by featunre” is conduncted Design and construnction merge in FDD
- 20. Featunre Driven Development Reprinted with permission of Peter Coad These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/ e (McGraw-Hill, 2009) Slides copyright 2009 by Roger Pressman. 20
- 21. Agile Modeling These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/ e (McGraw-Hill, 2009) Slides copyright 2009 by Roger Pressman. 21 ■ ■ Originally proposed by Scott Ambler Sunggests a set of agile modeling principles ■ ■ ■ ■ ■ ■ Model with a punrpose Use munltiple models Travel light Content is more important than representation Know the models and the tools youn unse to create them Adapt locally