Iterative Project Management

1. Iterative Project Management Chapter 3.3 - Controlling an Iterative Project Modified considerably by Instructor Many notes from authors not directly found in chapters.

2. The Role of Documentation • Documentation has many roles to play on a project • Enable communication • Much documentation tends to be temporary artifacts to support development. • Generally used for communications among team members. • Explanation, education, reporting what’s going on in project… • Establish a permanent record • System’s structure and behaviors; • May provide info for maintenance / change in the future. • History, justification of decisions, description of key decisions.. • Provide evidence • Agreements among stakeholders; • Achievements; • Records of what has been done. • Results of management and technical reviews. Iterative Project Management / 02 - Controlling an Iterative Project

3. Bittner and Spence have thoughts on ‘progress:’ • Progress is NOT indicated by production of documentation in itself. • Progress is muchbetter indicated by: • Increased understanding, • shared and accepted decisions, • agreements reached between parties, and, importantly • working software Iterative Project Management / 02 - Controlling an Iterative Project

4. Documentation: How much is enough? • Enough documentation is required to • establish a shared vision, • reduce risk, • enable management control, • preserve the integrity of the design and • involve the stakeholders in the project. • GOTO 11 • You are responsible for slides in between… Iterative Project Management / 02 - Controlling an Iterative Project

5. The Role of Requirements • Goals related to requirements include, to: • Establish a shared vision • Bridge the gap between the business and the supplier • Communicate the intent of the system • Define the capabilities required of the system • Occasionally: Act as a contract between the stakeholders and the development team To establish and maintain agreement with the customers and other stakeholders on what the system should do. Iterative Project Management / 02 - Controlling an Iterative Project

6. According to the RUP: Purpose of Requirements is: • To establish and maintain agreement with the customers and other stakeholders on what the system should do. • To provide system developers with a better understanding of the system requirements. • To define the boundaries of (delimit) the system. •  To provide a basis for planning the technical contents of iterations. •  To provide a basis for estimating cost and time to develop the system. • To define a user-interface for the system, focusing on the needs and goals of the users • (Right arrows are mine. Our emphasis here…) Iterative Project Management / 02 - Controlling an Iterative Project

7. From a Management Perspective, Requirements: • Definethescope of the system • Form the basis of agreement and negotiation with the stakeholders • Define the releases • Both internal and external • Drive development activities • Particularly testing and assessment • Form the basis for estimating and measuring progress Managers need to be aware of the requirements set and how they are managed. Iterative Project Management / 02 - Controlling an Iterative Project

8. The Role of Architecture • The architecture represents the significant decisions about the organization of the system • It’s the 20% of ‘stuff’ that makes 80% of the difference • Architecture constrains Design and Implementation • We talked about this quite a bit! How so? Discuss. • Proving the architecture is a significant milestone for any technology project: • Get the architecture right • before committing significant resources to the project. Why? • before worrying about completeness and precision in the requirements, test cases, design and code • How do you ‘prove’ the architecture is correct? Managers need to be aware of the architecture and the set of components it defines. Iterative Project Management / 02 - Controlling an Iterative Project

9. Architecture continued….If you agree, HOW SO??? • Software architecture encompasses the set of significant decisions about the organization of a software system • Selection of structural elements & interfaces by which a system is composed • Behavior as specified in collaborations among those elements • Composition of these structural and behavioral elements into larger subsystems • Architectural style that guides the overall organization and communications. • Software architecture also involves • Functionality & Usability • Resilience & Performance • Reuse & Comprehensibility • Economic and technology constraints and tradeoffs • Aesthetic concerns (elegance) • Grady Booch, Philippe Kruchten, Rich Reitman, Kurt Bittner; Rational (derived from Mary Shaw) Iterative Project Management / 02 - Controlling an Iterative Project

10. Iterative Development Requires Discipline Iterative Project Management Requirements Analysis &Design Code &Unit Test ContinuousAssessment Architecture Environment / Configuration and Change Management To iterate, all of the core software development disciplines are applied every iteration to produce a release. Some of the disciplines are particularly strained by iterative and incremental development. Iterative Project Management / 02 - Controlling an Iterative Project

11. Selecting A Development Process The iterative and incremental development process you select should be based on reducing project risk. Iterative Project Management / 02 - Controlling an Iterative Project

12. There are many other iterative and incremental methods • Adaptive Software Development, • MBASE • Alistair Cockburn’s Crystal Methods • Feature Driven Development (FDD), • Lean Development (LD) • Pragmatic Programming, and more • Most methods (certainly including the UP), are compatible with, or recommend, a use-case driven approach. • Nearly all methods adopt OO / component-based development • All methods listed will work when applied by the right people to the right kind of problem. • All the methods contain good practices you could apply to your projects. • All of the methods are agile and adaptive in one way or another. GOTO 17 Iterative Project Management / 02 - Controlling an Iterative Project

13. The Unified Process’s Key Requirement Artifacts Key Requirement Artifacts Vision SupplementarySpecification Use-Case Model Iterative Project Management / 02 - Controlling an Iterative Project

14. An Introduction to Use-Case Modeling • A way to establish the requirements of the system • Use cases place requirements in context • A way to establish the system boundary • The model identifies who or what interacts with the system and what the system should do • A way to iteratively evolve the requirements • A way to communicate the requirements to all the stakeholders • The use cases provide a common thread through all project activities A planning instrument for the management of iterative and incremental development projects Iterative Project Management / 02 - Controlling an Iterative Project

15. Use-Case Modeling: Actors and Use Cases Bolding is mine. Source: Use Case Modeling, Kurt Bittner & Ian Spence, Addison Wesley 2002 Iterative Project Management / 02 - Controlling an Iterative Project

16. The two main concepts involved in use-case modeling are Actors and Use Cases. • The definitions above are taken from Use Case Modeling, Kurt Bittner & Ian Spence, Addison Wesley 2002. • The more formal UML definitions are: • Actor: A coherent set of roles that users of use cases play when interacting with these use cases. • Use Case: A description of a set of sequence of actions, including variants, that a system performs that yields an observable result of value to a particular actor. • We prefer Bittner and Spence’s more expansive, but compatible definitions, as they are less self-referential, and hopefully, more approachable. Iterative Project Management / 02 - Controlling an Iterative Project

17. Looking Inside A Use Case • Basic Flow • The normal way of attaining the value, • The expected path through the use case • Alternative Flows • Other ways of attaining the value • Exception and error conditions • Scenarios • A description of one particular path through the use case (the basic flow plus 0 or more alternative flows) Iterative Project Management / 02 - Controlling an Iterative Project

18. Use Cases: Evolving Requirement Definitions “Maturity Levels” or “Levels of Granularity.” One version is not necessarily ‘better’ than another…. Can be individually used at different times for different purposes: Briefly Discovered Described Bulleted Essential Outline Outline Detailed Fully Described Description Source: Use Case Modeling, Kurt Bittner & Ian Spence, Addison Wesley 2002 Iterative Project Management / 02 - Controlling an Iterative Project

19. Use Cases Drive Other Development Activities Adapted from: Use Case Modeling, Kurt Bittner & Ian Spence, Addison Wesley 2002 Iterative Project Management / 02 - Controlling an Iterative Project

20. IMPORTANT. • What is interesting here is how the early, less complete use-case states but still very useful can be used to identify and support a host of very important activities. • This is achieved by doing broad brush stroke use-caserealizations based upon the bulleted or essential outlines. Iterative Project Management / 02 - Controlling an Iterative Project

21. Architecture: Component Definition Sample architectural layout – layered model showing components and associations. Some components may already exist; others may require development. Components grouped into ‘layers.’ Application- specific Business- specific Middleware System-software Iterative Project Management / 02 - Controlling an Iterative Project

22. Architectural Robustness Analysis and Design Very high level interaction diagram (sequence diagram) analysis model or initialcomponent-based high level design model showing high-level responsibilities. BankCustomerManagement InvoiceManagement AccountManagement Payment Buyer Sequence diagram may be developed from less than fully developed use-cases! Get invoices Get header Schedule invoice Transfer Invoice paid Invoice paid Adapted from Software Reuse, Jacobson et al, Addison Wesley 1997 Iterative Project Management / 02 - Controlling an Iterative Project

23. Other Approaches to Requirements Iterative Project Management / 02 - Controlling an Iterative Project

24. Releases must provide a clear value. • To support iterative development we must be able to subset the requirements to produce intelligent definitions of the releases produced by each iteration. • It is important that releases provide value • This can only be achieved by implementing end-to-end threads through the system. • Use cases, user stories and scenarios allow us to do this. Declarative statements, typically, do not. • All approaches can be used for iterative and incremental development. Iterative Project Management / 02 - Controlling an Iterative Project

25. The Lifecycle of a Use Case Requirements Development Testing Verified Identified Analyzed Designed Authored Accepted Implemented Agreed Source: Use Case Modeling, Kurt Bittner & Ian Spence, Addison Wesley 2002 Iterative Project Management / 02 - Controlling an Iterative Project

26. Use Case Scenario Use Cases and Testing Follow the ‘dependency’ arrows… Test Design and Preparation Test Scenario << White Box Testing >> Use Case Realization Test Suite w. Test Cases ComponentDefinition System Design and Implementation Unit Tested Component Testable Release Iterative Project Management / 02 - Controlling an Iterative Project

27. Testing with Use Cases: Test cases; black box and white box.. • Use cases constitute the basis for identifying test cases and procedures. • System is verified by performing scenarios based on the use cases. • Black Box View of the system is provided by Use cases. • White Box View is provided by the Analysis and Design products and relate requirements to individualpiecesof the system. Iterative Project Management / 02 - Controlling an Iterative Project

28. Testing with Use Cases: Test cases; black box and white box.. • Based upon the use cases, test design and test case preparation activities can proceed in parallel with the software design and implementation. • This enables the test suite to be available when the testable release becomes available. • Test cases derived from the use cases take advantage of the way that use cases gather together the requirements to ensure good functional test coverage of the system and to produce robust, repeatable test suites. Iterative Project Management / 02 - Controlling an Iterative Project

29. Iteration 1 Iteration 2 Iteration 3 Use Case and Scenario-Based Planning • Use cases providing the end to end threads required to successfully set the objectives for the iterations • Scenarios (threads through the uses cases) drive the iterations. Out of Scope Iterative Project Management / 02 - Controlling an Iterative Project

30. Measuring Progress with Use Cases Use case ‘states’ can be used to track project progress Use Cases drive the process… Iterative Project Management / 02 - Controlling an Iterative Project

31. Summary and Review • Every iteration should produce an executable release • The release should fulfill more of the project’s requirements than the previous release (from the last iteration). • This increase in delivered requirements is called an increment. • Iterations are defined by their intended results as well as the evaluation criteria for these results. • Every iteration should actively address and reduce project risk Iterative Project Management / 02 - Controlling an Iterative Project

32. Summary and Review • Every iteration should be treated as a discrete time box. • During an iteration, the project team should focus on objectives of the current iteration – no more. • The results of every iteration should be objectively assessed; the team should be prepared to rework the solution and project plan as required. • Use ‘Anchor Point’ Milestones to provide focus to the series of iterations. • The milestones (and their phases) measure the state of the project in terms of its risk Iterative Project Management / 02 - Controlling an Iterative Project