Download
1 / 14
140 likes | 142 Vues
Chapter 8: Iteration 1 - Basics. 8.1 Introduction. We review here the requirements for first iteration of our case studies. They are a subset of the requirements as described by the use cases, the vision, and the supplementary specification;
E N D
8.1 Introduction • We review here the requirements for first iteration of our case studies. • They are a subset of the requirements as described by the use cases, the vision, and the supplementary specification; • Subsequent iterations will grow these until a full system is implemented; • The current requirements are not complete, they will evolve and benefit from feedback …
8.2 Planning the Iterations • After the initial inception phase, the most important software requirements have been identified, some of which have been detailed. • Other requirements remain to be discovered; • Most will need further analysis;
However after the inception phase we must have a basic, documented, set of requirements: • These need to be scheduled over the next few development cycles (the elaboration phase); • Only the first few cycles need to be scheduled at this stage (a very detailed schedule is not feasible at this point in time due to the fuzziness of the remaining requirements); • An iteration must be time-boxed, say between 2 weeks and 8 weeks (why?) • To decide which requirements should be tackled early in the project we can use the following criteria: • Risk : includes both technical complexity and other factors, such as uncertainty of effort or usability. • Coverage : implies that all major parts of the system are at least touched on in early iterations, perhaps a "wide and shallow" implementation across many components. • Criticality : refers to functions the client considers of high business value.
We can then rank use cases, and other high-level features, according to these criteria: • This ranking should be reviewed after each iteration as new requirements and new insights will influence it: • The schedule needs to be adaptive; • In addition, we will always consider the Start Up use case: to consider all the necessary initialisations in a systematic way.
8.3. Case Studies: Requirements for Iteration 1 • For the POS: • Implement a basic, key scenario of the Process Sale use case: entering items and receiving a cash payment. • Implement a Start Up use case as necessary to support the initialization needs of the iteration. • Nothing fancy or complex is handled, just a simple happy path scenario, and the design and implementation to support it. • There is no collaboration with external services, such as a tax calculator or product database. • No complex pricing rules are applied. • User Interface Prototyping if not done already (we will not see this)
8.3. Case Studies: Requirements for Iteration 1 (con’t) • Discussion: • Subsequent iterations will grow on these foundations; • The requirements have been simplified for the first iteration : to fit in a given time-box; • In iterative lifecycle processes (such as the UP, XP, Scrum, and so forth): We start production-quality programming and testing for a subset of the requirements, and we start that development before all the requirements analysis is complete : contrast to a waterfall process. • A use case can span more that one iteration : see Figure 8.1
8.3. Case Studies: Requirements for Iteration 1 (con’t) Figure 8.1: Spreading Use Cases
8.4 From Inception to Elaboration • The inception phase may only last 1 week (typically more) : it is not very long: • It determines basic feasibility, risk, and scope, to decide if the project is worth more serious investigation (Elaboration). • During the Inception phase the following may occur: • a short requirements workshop; • most actors, goals, and use cases named; • most use cases written in brief format; 10 to 20% of the use cases are written in fully dressed detail to improve understanding of the scope and complexity; • most influential and risky quality requirements identified; • version one of the Vision and Supplementary Specification written;
8.4 From Inception to Elaboration (con’t) • risk list; • For example, leadership really wants a demo at the POSWorld trade show in Hamburg, in 18 months. But the effort for a demo cannot yet be even roughly estimated until deeper investigation. • technical proof-of-concept prototypes and other investigations to explore the technical feasibility of special requirements; • user interface-oriented prototypes to clarify the vision of functional requirements • recommendations on what components to buy/build/reuse, to be refined in elaboration
high-level candidate architecture and components proposed • This is not a detailed architectural description, and it is not meant to be final or correct. Rather, it is brief speculation to use as a starting point of investigation in elaboration. For example, "A Java client-side application, no application server, Oracle for the database, …" In elaboration, it may be proven worthy, or discovered to be a poor idea and rejected. • plan for the first iteration; • candidate tools list; • On to the Elaboration phase: • Elaboration is the initial series of iterations during which: • the core, risky software architecture is programmed and tested • the majority of requirements are discovered and stabilized • the major risks are mitigated or retired • Elaboration often consists of two or more iterations; each iteration is recommended to be between two and six weeks; prefer the shorter versions unless the team size is massive. Each iteration is timeboxed, meaning its end date is fixed. • Build the core architecture, resolve the high-risk elements, define most requirements, and estimate the overall schedule and resources.
8.4 From Inception to Elaboration (con’t) • Key ideas during elaboration: • do short timeboxed risk-driven iterations; • start programming early; • adaptively design, implement, and test the core and risky parts of the architecture; • test early, often, realistically; • adapt based on feedback from tests, users, developers; • write most of the use cases and other requirements in detail, through a series of workshops, once per elaboration iteration; • Treat each iteration during elaboration as a mini-project;
In addition to the artifacts created during inception (and which need to be refined during elaboration) the following artefacts can be created during the iterations of the elaboration phase:
8.5 Conclusion • The elaboration phase will start before the specification is complete … • The elaboration phase will be followed by a longer Construction phase. • During several iterations, the elaboration phase, builds the core architecture, resolves the high-risk elements, defines most requirements, and estimates/refines the overall schedule and resources. • The Elaboration phase is not about requirements, nor design, nor coding : it is all of these at once for the most important (possibly simplified) aspects of the project … • During Elaboration, feedback will evolve/complete the requirements. • We must produce fully-tested, documented, production-grade code
