1. 1 COSC 4406 Software Engineering COSC 4406 Software Engineering Haibin Zhu, Ph.D. Dept. of Computer Science and mathematics, Nipissing University, 100 College Dr., North Bay, ON P1B 8L7, Canada, haibinz@nipissingu.ca, http://www.nipissingu.ca/faculty/haibinz haibinz@nipissingu.ca

2. 2 Lecture 2 Process Models and Agile Development

3. 3 Prescriptive Models They define a distinct set of activities, actions, tasks, milestones, and work products that are required to engineering high-quality software. They are not perfect, but they do provide a useful roadmap for software engineering work. They define a distinct set of activities, actions, tasks, milestones, and work products that are required to engineering high-quality software. They are not perfect, but they do provide a useful roadmap for software engineering work.

4. 4 Prescriptive Models Prescriptive process models advocate an orderly approach to software engineering Prescriptive process models advocate an orderly approach to software engineering That leads to a few questions … If prescriptive process models strive for structure and order, are they inappropriate for a software world that thrives on change? If prescriptive process models strive for structure and order, are they inappropriate for a software world that thrives on change? Yet, if we reject traditional process models (and the order they imply) and replace them with something less structured, do we make it impossible to achieve coordination and coherence in software work? Yet, if we reject traditional process models (and the order they imply) and replace them with something less structured, do we make it impossible to achieve coordination and coherence in software work?

5. 5 The Waterfall Model http://www.stsc.hill.af.mil/crosstalk/1995/01/Comparis.asp

6. 6 The Incremental Model Communication Planning Modeling (analysis, design) Construction Deployment (deliver, feedback)

7. 7 The RAD Model It is an incremental model that emphasizes a short development cycle by using component-based approach.

8. 8 Evolutionary Models: Prototyping communication Quick plan Modeling Quick design Construction of prototype Deployment delivery & feedback

9. 9 Strengths and Weaknesses of Prototyping Strengths of Prototyping Strengths of Prototyping Early functionality. Early functionality. Provides a process to perfect the requirements definition. Provides a process to perfect the requirements definition. Provides risk control. Provides risk control. Documentation focuses on the end product not the evolution of the product. Documentation focuses on the end product not the evolution of the product. Provides a formal specification embodied in an operating replica. Provides a formal specification embodied in an operating replica. Weaknesses of Prototyping Weaknesses of Prototyping Less applicable to existing systems than to new, original development. Less applicable to existing systems than to new, original development. Bad reputation among conservatives as a "quick and dirty" method. Bad reputation among conservatives as a "quick and dirty" method. Suffers from bad documentation. Suffers from bad documentation. Sometimes produces a system with poor performance. Sometimes produces a system with poor performance. Tendency for difficult problems to be pushed to the future so that the initial promise of the prototype is not met by subsequent products. Tendency for difficult problems to be pushed to the future so that the initial promise of the prototype is not met by subsequent products.

10. 10 Comparing the incremental model and the prototyping model Same: Same: They are iterative They are iterative Difference: Difference: The former focuses on the delivery of an operational product with each increment. The former focuses on the delivery of an operational product with each increment. The latter focuses on a representation of those aspects of the software that will be visible to the customer/end-user. The latter focuses on a representation of those aspects of the software that will be visible to the customer/end-user.

11. 11 Evolutionary Models: The Spiral It couples the iterative nature of prototyping with the controlled and systematic aspects of the waterfall model.

12. 12 STRENGTHS Water- fall Increme ntal Spiral Allows for work force specializationXXX Orderliness appeals to managementXXX Can be reported aboutXXX Facilitates allocation of resourcesXXX Early functionalityXX Does not require a complete set of requirements at the onsetX*X Resources can be held constantX Control costs and risk through prototypingX * The incremental model may be used with a complete set of requirements or with less defined general objectives.

13. 13 WEAKNESSES Water fall Incre mental Spiral Requires a complete set of requirements at the onset X Enforcement of non-implementation attitude hampers analyst/designer communications X Beginning with less defined general objectives may be uncomfortable for management XX Requires clean interfaces between modules X Incompatibility with a formal review and audit procedure XX Tendency for difficult problems to be pushed to the future so that the initial promise of the first increment is not met by subsequent products XX

14. 14 Evolutionary Models: Concurrent For each framework activity of the waterfall model, there is a state transition diagram. Each activity follows the diagram. Therefore, all these activities are in concurrency.

15. 15 Still Other Process Models Component based development—the process to apply when reuse is a development objective Component based development—the process to apply when reuse is a development objective Formal methods—emphasizes the mathematical specification of requirements Formal methods—emphasizes the mathematical specification of requirements AOSD—provides a process and methodological approach for defining, specifying, designing, and constructing aspects AOSD—provides a process and methodological approach for defining, specifying, designing, and constructing aspects Unified Process—a “use-case driven, architecture- centric, iterative and incremental” software process closely aligned with the Unified Modeling Language (UML) Unified Process—a “use-case driven, architecture- centric, iterative and incremental” software process closely aligned with the Unified Modeling Language (UML)

16. 16 inception The Unified Process (UP) inception elaboration Introduce agile features into The activities of the waterfall model. Iterative, incremental.

17. 17 UP Phases

18. 18 UP Work Products

19. 19 Agile Software Engineering It combines a philosophy and a set of development guidelines. It combines a philosophy and a set of development guidelines. The philosophy encourages The philosophy encourages customer satisfaction and early incremental delivery of software; customer satisfaction and early incremental delivery of software; small, highly motivated project teams; small, highly motivated project teams; informal methods; informal methods; minimal software engineering products; and minimal software engineering products; and overall development simplicity. overall development simplicity. The development guidelines stress delivery over analysis and design and active and continuous communication between developers and customers. The development guidelines stress delivery over analysis and design and active and continuous communication between developers and customers.

20. 20 The Manifesto for Agile Software Development 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 / processes and toolsIndividuals and interactions / processes and tools Working software / comprehensive documentationWorking software / comprehensive documentation Customer collaboration / contract negotiationCustomer collaboration / contract negotiation Responding to change / following a planResponding to change / 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

21. 21 Human Factors Competence Competence Common Focus Common Focus Collaboration Collaboration Decision-making ability Decision-making ability Fuzzy problem-solving ability Fuzzy problem-solving ability Mutual trust and respect Mutual trust and respect Self-organization Self-organization

22. 22 What is “Agility”? Effective (rapid and adaptive) response to change Effective (rapid and adaptive) response to change Effective communication among all stakeholders Effective communication among all stakeholders Drawing the customer onto the team Drawing the customer onto the team Organizing a team so that it is in control of the work performed Organizing a team so that it is in control of the work performed Yielding … Rapid, incremental delivery of software Rapid, incremental delivery of software

23. 23 An Agile Process Is driven by customer descriptions of what is required (scenarios) Is driven by customer descriptions of what is required (scenarios) Recognizes that plans are short-lived Recognizes that plans are short-lived Develops software iteratively with a heavy emphasis on construction activities Develops software iteratively with a heavy emphasis on construction activities Delivers multiple ‘software increments’ Delivers multiple ‘software increments’ Adapts as changes occur Adapts as changes occur Assumptions: 1.It is difficult to predict in advance the requirements; 2.Phases are interleaved. 3.All the phases are not predictable.

24. 24 Extreme Programming (XP) The most widely used agile process, originally proposed by Kent Beck The most widely used agile process, originally proposed by Kent Beck XP Planning XP Planning Begins with the creation of “user stories” Begins with the creation of “user stories” Agile team assesses each story and assigns a cost Agile team assesses each story and assigns a cost Stories are grouped for a deliverable increment Stories are grouped for a deliverable increment A commitment is made on delivery date A commitment is made on delivery date After the first increment “project velocity” is used to help define subsequent delivery dates for other increments After the first increment “project velocity” is used to help define subsequent delivery dates for other increments

25. 25 Extreme Programming (XP) XP Design XP Design Follows the KIS principle Follows the KIS principle Encourage the use of CRC cards (see Chapter 8) Encourage the use of CRC cards (see Chapter 8) For difficult design problems, suggests the creation of “spike solutions”—a design prototype For difficult design problems, suggests the creation of “spike solutions”—a design prototype Encourages “refactoring”—an iterative refinement of the internal program design Encourages “refactoring”—an iterative refinement of the internal program design XP Coding XP Coding Recommends the construction of a unit test for a store before coding commences Recommends the construction of a unit test for a store before coding commences Encourages “pair programming” Encourages “pair programming” XP Testing XP Testing All unit tests are executed daily All unit tests are executed daily “Acceptance tests” are defined by the customer and excuted to assess customer visible functionality “Acceptance tests” are defined by the customer and excuted to assess customer visible functionality

26. 26 Extreme Programming (XP)

27. 27 Adaptive Software Development Originally proposed by Jim Highsmith Originally proposed by Jim Highsmith ASD — distinguishing features: Self-oraganisation ASD — distinguishing features: Self-oraganisation Mission-driven planning Mission-driven planning Component-based focus Component-based focus Uses “time-boxing” (See Chapter 24) Uses “time-boxing” (See Chapter 24) Explicit consideration of risks Explicit consideration of risks Emphasizes collaboration for requirements gathering Emphasizes collaboration for requirements gathering Emphasizes “learning” throughout the process Emphasizes “learning” throughout the process

28. 28 Adaptive Software Development

29. 29 Dynamic Systems Development Method Promoted by the DSDM Consortium (www.dsdm.org) Promoted by the DSDM Consortium (www.dsdm.org)www.dsdm.org Provides a framework for building systems that meet tight time constraints through the use of incremental prototyping in a controlled project environment. Provides a framework for building systems that meet tight time constraints through the use of incremental prototyping in a controlled project environment. DSDM—distinguishing features DSDM—distinguishing features Similar in most respects to XP and/or ASD Similar in most respects to XP and/or ASD Nine guiding principles Nine guiding principles Active user involvement is imperative. Active user involvement is imperative. DSDM teams must be empowered to make decisions. DSDM teams must be empowered to make decisions. The focus is on frequent delivery of products. The focus is on frequent delivery of products. Fitness for business purpose is the essential criterion for acceptance of deliverables. Fitness for business purpose is the essential criterion for acceptance of deliverables. Iterative and incremental development is necessary to converge on an accurate business solution. Iterative and incremental development is necessary to converge on an accurate business solution. All changes during development are reversible. All changes during development are reversible. Requirements are baselined at a high level Requirements are baselined at a high level Testing is integrated throughout the life-cycle. Testing is integrated throughout the life-cycle.

30. 30 Dynamic Systems Development Method

31. 31 Scrum Originally proposed by Schwaber and Beedle Originally proposed by Schwaber and Beedle Scrum—distinguishing features Scrum—distinguishing features Development work is partitioned into “packets” Development work is partitioned into “packets” Testing and documentation are on-going as the product is constructed Testing and documentation are on-going as the product is constructed Work occurs in “sprints” and is derived from a “backlog” of existing requirements Work occurs in “sprints” and is derived from a “backlog” of existing requirements Meetings are very short and sometimes conducted without chairs Meetings are very short and sometimes conducted without chairs “demos” are delivered to the customer with the time-box allocated “demos” are delivered to the customer with the time-box allocated

32. 32Scrum

33. 33 Crystal Proposed by Cockburn and Highsmith Proposed by Cockburn and Highsmith Crystal—distinguishing features Crystal—distinguishing features Actually a family of process models that allow “maneuverability” based on problem characteristics Actually a family of process models that allow “maneuverability” based on problem characteristics Face-to-face communication is emphasized Face-to-face communication is emphasized Suggests the use of “reflection workshops” to review the work habits of the team Suggests the use of “reflection workshops” to review the work habits of the team

34. 34 Feature Driven Development Originally proposed by Peter Coad et al Originally proposed by Peter Coad et al FDD—distinguishing features FDD—distinguishing features Emphasis is on defining “features” Emphasis is on defining “features” a feature “is a client-valued function that can be implemented in two weeks or less.” a feature “is a client-valued function that can be implemented in two weeks or less.” Uses a feature template Uses a feature template the a(n) the a(n) A features list is created and “plan by feature” is conducted A features list is created and “plan by feature” is conducted Design and construction merge in FDD Design and construction merge in FDD

35. 35 Feature Driven Development

36. 36 Agile Modeling Originally proposed by Scott Ambler Originally proposed by Scott Ambler Suggests a set of agile modeling principles Suggests a set of agile modeling principles Model with a purpose Model with a purpose Use multiple models Use multiple models Travel light Travel light Content is more important than representation Content is more important than representation Know the models and the tools you use to create them Know the models and the tools you use to create them Adapt locally Adapt locally

37. 37 Summary Prescriptive Models Prescriptive Models The Waterfall Model The Waterfall Model The Incremental Model The Incremental Model The RAD Model The RAD Model Evolutionary Models Evolutionary Models Prototyping Prototyping The Spiral Model The Spiral Model The Current Development Model The Current Development Model UP Phase UP Phase Agile Development Agile Development Agile processes Agile processes Agile process models Agile process models XP, ASD, DSDM, Scum, Crystal, FDD, AM XP, ASD, DSDM, Scum, Crystal, FDD, AM