Embed Size (px)
Citation preview
Jan 7, 2009 1
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
Jan 7, 2009 2
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 phases
Jan 7, 2009 3
Jan 7, 2009 4
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
Jan 7, 2009 5
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.
The UP Disciplines
Jan 7, 2009 6
The UP Disciplines
Iterations
SampleUP Disciplines
Business Modeling
Requirements
Design
Implementation
Test
Deployment
Configuration & Change Management
Project Management
Environment
Focus of this book
Note that although an iteration includes work in most disciplines, the relative effort and emphasis change over time.
This example is suggestive, not literal.
A four-week iteration (for example). A mini-project that includes work in most disciplines, ending in a stable executable.
Jan 7, 2009 7
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
Jan 7, 2009 8
UP Disciplines and phases
Jan 7, 2009 9
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.
UP Disciplines and UP phases
Jan 7, 2009 10
UP Disciplines and phases
Overview InceptionElaborationIteration 1
ElaborationIteration 2
ElaborationIteration 3
Object-OrientedAnalysis
Object-OrientedDesign
Translating Designs to Code
The Book
Topics such as OO analysis and OO design are incrementally introduced in iteration 1, 2, and 3.
SpecialTopics
Jan 7, 2009 11
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).
Customize UP, The UP Development Case
Jan 7, 2009 12
Customize UP, The UP Development Case
Jan 7, 2009 13
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….
Jan 7, 2009 14
Chapter 3, 4, 5, prepare for chapter 6 and 7,
Jan 7, 2009 15
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
Jan 7, 2009 16
User Interface
Sale Payment
Logging ... Database Access ...
application logic layer
other layers or components
minor focus
explore how to connect to other layers
primary focus of case studies
explore how to design objects
secondary focus
Jan 7, 2009 17
Chapter 3 Case Studies
Case Study Strategy: Iterative Development + Iterative Learning.
Iteration 1
Iteration 2
Iteration 3Introduces just those analysis and design skills related to iteration one.
Additional analysis and design skills introduced.
Likewise.
Jan 7, 2009 18
Case One: The NextGen POS System.
Using an iterative development strategy, we are going to proceed through requirements, object-oriented analysis, design, and implementation.
Jan 7, 2009 19
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.
Jan 7, 2009 20
Inception is the initial short step to 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
Jan 7, 2009 21
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
Jan 7, 2009 22
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
Jan 7, 2009 23
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?
Chapter 4. Inception is Not the Requirements Phase
Jan 7, 2009 24
Artifacts in Inception
Jan 7, 2009 25
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.
Is UML involved in inception?
Jan 7, 2009 26
Objectives
– Motivate doing evolutionary requirements.
– Define the FURPS+ model.– Define the UP requirements artifacts.
Chapter 5. Evolutionary Requirements
Jan 7, 2009 27
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 Requiements
Jan 7, 2009 28
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.
Chapter 5. Evolutionary Requirements
Jan 7, 2009 29
Do an iterative and evolutionary requirement analysis, not a waterfall one. Here is the evidence:
Blame the waterfall again
Jan 7, 2009 30
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.
Blame the waterfall again
Jan 7, 2009 31
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
Jan 7, 2009 32
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
Jan 7, 2009 33
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
Types and Categories of Requirements in UP
Jan 7, 2009 34
Requirement Artifacts in UP
Iterations
SampleUP Disciplines
Business Modeling
Requirements
Design
Implementation
Test
Deployment
Configuration & Change Management
Project Management
Environment
Focus of this book
Note that although an iteration includes work in most disciplines, the relative effort and emphasis change over time.
This example is suggestive, not literal.
A four-week iteration (for example). A mini-project that includes work in most disciplines, ending in a stable executable.
Jan 7, 2009 35
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
Jan 7, 2009 36
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
Jan 7, 2009 37
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.
Requirement Artifacts in UP
Jan 7, 2009 38
Jan 7, 2009 39
Thank you and See you next time.
