Download
1 / 39
440 likes | 652 Vues
The UP phases. A UP project organizes the work and iterations across four major phases: Inception -- approximate vision, business case, scope, vague estimates.
E N D
The UP phases • A UP project organizes the work and iterations across four major phases: • Inception -- approximate vision, business case, scope, vague estimates. • Elaboration – refined vision, iterative implementation of the core architecture, resolution of high risks, identification of most requirements and scope, more realistic estimates. • Construction -- iterative implementation of the remaining lower risk and easier elements, and preparation for deployment. • Transition -- beta tests, deployment.
The UP phases • Inception is not a requirements phase; rather, it is a feasibility phase, where just enough investigation is done to support a decision to continue or stop. • Similarly, elaboration is not the requirements or design phase; rather, it is a phase where the core architecture is iteratively implemented, and high-risk issues are mitigated.
The UP Disciplines • Discipline: • A set of activities in a subject area, such as the activities in the requirement analysis. • The UP describes work activities, such as writing a use case, within disciplines. • In the UP, an artifact is the general term for any work product: code, Web graphics, database schema, text documents, diagrams, models, and so on.
The UP Disciplines • There are several disciplines in the UP; this course focuses on some artifacts in the following three disciplines: • Business Modeling - The Domain Model artifact, to visualize noteworthy concepts in the application domain. • Requirements - The Use-Case Model and Supplementary Specification artifacts to capture functional and non-functional requirements. • Design - The Design Model artifact, to design the software objects.
UP Disciplines and UP phases • As illustrated in the figure, during one iteration, work goes on in most or all disciplines. • However, the relative effort across these disciplines changes over time. • The following figure shows the changing relative effort with respect to the phases
UP Disciplines and UP phases • The book presents two case studies. • With respect to the phases and disciplines, what is the focus of the case studies? • The case studies emphasize the inception and elaboration phase. They focus on some artifacts in the Business Modeling, Requirements, and Design disciplines, as this is where requirements analysis, OOA/D, patterns, and the UML are primarily applied.
Customize UP, The UP Development Case • All activities and artifacts (models, diagrams, documents, …) in UP are optional. • The choice of practices and UP artifacts for a project may be written up in a short document called the Development Case (an artifact in the Environment discipline).
From (last) lecture…. • UP is a software development process. • A software development process describes an approach to building, deploying, and possibly maintaining software. • The Unified Process has emerged as a popular iterative software development process for building object-oriented systems. • Small steps, rapid feedback, and adaptation are central ideas in iterative development. • A key idea is that iterations are timeboxed, or fixed in length. • Any analysis, modeling, development, or management practice based on the assumption that things are long-term stable (i.e., the waterfall) is fundamentally flawed. • A UP project organizes the work and iterations across four major phases…. • There are several disciplines in the UP; this course focuses on some artifacts in the following three disciplines….
Chapter 3 Case Studies • Generally, applications include UI elements, core application logic, database access, and collaboration with external software or hardware components. • Although OO technology can be applied at all levels, this introduction to OOA/D focuses on the core application logic layer, with some secondary discussion of the other layers.
Chapter 3 Case Studies • Case Study Strategy: Iterative Development + Iterative Learning.
Case One: The NextGen POS System. • Using an iterative development strategy, we are going to proceed through requirements, object-oriented analysis, design, and implementation.
Case Two: The Monopoly Game System • The software version of the game will run as a simulation. One person will start the game and indicate the number of simulated players, and then watch while the game runs to completion, presenting a trace of the activity during the simulated player turns.
Chapter 4. Inception is Not the Requirements Phase • Inception is the initial short stepto establish a common vision and basic scope for the project. • It will include analysis of perhaps 10% of • the use cases (?, chapter 6) • analysis of the critical non-functional requirement, • creation of a business case, and • preparation of the development environment so that programming can start in the following elaboration phase.
Chapter 4. Inception is Not the Requirements Phase • Most projects require a short initial step in which the following kinds of questions are explored: • What is the vision and business case for this project? • Feasible? • Buy and/or build? • Rough unreliable range of cost: Is it $10K100K or in the millions? • Should we proceed or stop?
Chapter 4. Inception is Not the Requirements Phase • KEEP IN MIND: • the purpose of the inception phase is not to define all the requirements, or generate a believable estimate or project plan. • Inception, is not the time do all requirements or create believable estimates or plans. That happens during elaboration. • Most requirements analysis occurs during the elaboration phase, in parallel with early production-quality programming and testing.
Chapter 4. Inception is Not the Requirements Phase • Inception phase is normally short for most projects. • It is to decide if the project is worth a serious investigation (during elaboration), not to do that investigation. • Inception In one sentence: • Envision the product scope, vision, and business case. • The main problem solved in one sentence: • Do the stakeholders have basic agreement on the vision of the project, and is it worth investing in serious investigation?
Is UML involved in inception? • The purpose of inception is to collect just enough information to establish a common vision, decide if moving forward is feasible, and if the project is worth serious investigation in the elaboration phase. • As such, perhaps beyond simple UML use case diagrams, not much diagramming is warranted. • There is more focus in inception on understanding the basic scope and 10% of the requirements, expressed mostly in text forms. • In practice, most UML diagramming will occur in the next phase---elaboration.
Chapter 5. Evolutionary Requirements • Objectives • Motivate doing evolutionary requirements. • Define the FURPS+ model. • Define the UP requirements artifacts.
Chapter 5. Evolutionary Requiements • Requirements are capabilities and conditions to which the system and more broadly, the project must conform. • One of the best practices of UP is manage requirements. • Which means • a systematic approach to finding, documenting, organizing, and tracking the changing requirements of a system.
Chapter 5. Evolutionary Requirements • How to do partial, evolutionary requirements analysis combined with early design and programming, in iterations? • In other words, UP wants to do requirements iteratively and skillfully, and not being sloppy. • The challenge in requirement analysis is to find, communicate, and remember (that usually means write down) what is really needed, in a form that clearly speaks to the client and development team members. Details in Ch 6 and 7.
Blame the waterfall again • Do an iterative and evolutionary requirement analysis, not a waterfall one. Here is the evidence:
Blame the waterfall again • Research shows on average, 25% of the requirements change on software projects. • Any method that therefore attempts to freeze or fully define requirements at the start is fundamentally flawed, based on a false assumption, and fighting or denying the inevitable change. • Do an iterative, evolutionary requirement analysis, i.e., • iterative and evolutionary requirements analysis combined with early timeboxed iterative development and frequent stakeholder participation, evaluation, and feedback on partial results.
Types and Categories of Requirements in UP • In the UP, requirements are categorized according to the FURPS+ model • Functional - features, capabilities, security. • Usability - human factors, help, documentation. • Reliability - frequency of failure, recoverability, predictability. • Performance - response times, throughput, accuracy, availability, resource usage. • Supportability - adaptability, maintainability, internationalization, configurability.
Types and Categories of Requirements in UP • The “+” sign means • Implementation - resource limitations, languages and tools, hardware, ... • Interface - constraints imposed by interfacing with external systems. • Operations - system management in its operational setting. • Packaging - for example, a physical box. • Legal - licensing and so forth.
Types and Categories of Requirements in UP • Use FURPS+ model as a checklist for requirements coverage, in order to reduce the risk of not considering some important facet of the system. • A more general categorization of requirements: • Functional requirements • Non-functional requirements
Requirement Artifacts in UP • The UP offers several requirements artifacts. As with all UP artifacts, they are optional. Key ones include: • Use-Case Model : set of typical scenarios of using a system. CAPTURE functional (behavioral) requirements. • Supplementary Specification: Basically, everything not in the use cases. CAPTURE all non-functional requirements, such as performance or licensing.
Requirement Artifacts in UP • The UP offers several requirements artifacts. As with all UP artifacts, they are optional. Key ones include: • Glossary : Glossary defines noteworthy terms. The data dictionary • Vision : Summarizes high-level requirements that are elaborated in the Use-Case Model and Supplementary Specification, and summarizes the business case for the project.
Requirement Artifacts in UP • Business Rules: Business rules (also called Domain Rules) typically describe requirements or policies that transcend one software project - they are required in the domain or business, and many applications may need to conform to them. An excellent example is government tax laws.
