Object oriented Analysis and Design - Description about the Unified Process Phases

1. Unified 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. In particular,
the Rational Unified Process or RUP, a detailed refinement of the Unified Process, has
been widely adopted.
The UP is very flexible and open, and encourages including skillful practices from
other iterative methods, such as from Extreme Programming (XP), Scrum, and so forth.
The UP combines commonly accepted best practices, such as an iterative lifecycle and
risk-driven development, into a cohesive and well-documented process description.
Why UP?
1. The UP is an iterative process.
2. UP practices provide an example structure for how to do and thus how to explain
OOA/D. The UP is flexible, and can be applied in a lightweight and agile
approach that includes practices from other agile methods (such as XP or Scrum)
more on this later.
The central idea to appreciate and practice in the UP is short timeboxed iterative,
evolutionary, and adaptive development. Some additional best practices and key concepts in
the UP:
 Tackle high-risk and high-value issues in early iterations
 Continuously engage users for evaluation, feedback, and requirements build a
cohesive, core architecture in early iterations
 Continuously verify quality; test early, often, and realistically apply use cases where
appropriate
 Do some visual modeling (with the UML) carefully manage requirements
 Practice change request and configuration management
Are There Benefits to Iterative Development?
Yes. Benefits include:
 less project failure, better productivity, and lower defect rates; shown by research
into iterative and evolutionary methods
 early rather than late mitigation of high risks (technical, requirements, objectives,
usability, and so forth)
 early visible progress
 early feedback, user engagement, and adaptation, leading to a refined system that
more closely meets the real needs of the stakeholders
 managed complexity; the team is not overwhelmed by "analysis paralysis" or very
long and complex steps
 the learning within an iteration can be methodically used to improve the development
process itself, iteration by iteration
UP Phases
A UP project organizes the work and iterations across four major phases:
1. Inception approximate vision, business case, scope, vague estimates.
2. Elaboration refined vision, iterative implementation of the core architecture,

2. resolution of high risks, identification of most requirements and scope, more
realistic estimates.
3. Construction iterative implementation of the remaining lower risk and easier
elements, and preparation for deployment.
4. Transition beta tests, deployment.
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.
Artifact is the general term for any work product: code, Web graphics,
database schema, text documents, diagrams, models, and so on.
The NextGen POS System
The first case study is the NextGen point-of-sale (POS) system. In this apparently
straightforward problem domain, we shall see that there are interesting requirement and
design problems to solve. In addition, it's a real problem groups really do develop POS
systems with object technologies.
A POS system is a computerized application used (in part) to record sales and handle
payments; it is typically used in a retail store. It includes hardware components such as a
computer and bar code scanner, and software to run the system. It interfaces to various service
applications, such as a third-party tax calculator and inventory control. These systems must
be relatively fault- tolerant; that is, even if remote services are temporarily unavailable (such
as the inventory system), they must still be capable of capturing sales and handling at least
cash payments (so that the business is not crippled).

3. A POS system increasingly must support multiple and varied client-side terminals and
interfaces. These include a thin-client Web browser terminal, a regular personal computer with
something like a Java Swing graphical user interface, touch screen input, wireless PDAs, and
so forth.
Furthermore, we are creating a commercial POS system that we will sell to different
clients with disparate needs in terms of business rule processing. Each client will desire a
unique set of logic to execute at certain predictable points in scenarios of using the system,
such as when a new sale is initiated or when a new line item is added. Therefore, we will need
a mechanism to provide this flexibility and customization.
Using an iterative development strategy, we are going to proceed through requirements,
object- oriented analysis, design, and implementation.
Inception
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, 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.
What is Inception?
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?
Defining the vision and obtaining an order-of-magnitude (unreliable) estimate requires
doing some requirements exploration. However, the purpose of the inception phase is not to
define all the requirements, or generate a believable estimate or project plan.
Most requirements analysis occurs during the elaboration phase, in parallel with
early production-quality programming and testing.
How long is Inception?
The intent of inception is to establish some initial common vision for the objectives
of the project, determine if it is feasible, and decide if it is worth some serious
investigation in elaboration. If it has been decided beforehand that the project will
definitely be done, and it is clearly feasible (perhaps because the team has done projects
like this before), then the inception phase will be especially brief. It may include the first
requirements workshop, planning for the first iteration, and then quickly moving forward
to elaboration.
Inception artifacts
Artifact Comment
Vision and
Business Case
Describes the high-level goals and constraints, the business
case, and provides an executive summary.

4. Use-Case Model Describes the functional requirements. During inception, the names
of most use cases will be identified, and perhaps 10% of the use
cases will be analyzed in detail.
Supplementary
Specification
Describes other requirements, mostly non-functional. During
inception, it is useful to have some idea of the key non-functional
requirements that have will have a major impact on the
architecture.
Glossary Key domain terminology, and data dictionary.
Risk List & Risk
Management Plan
Describes the risks (business, technical, resource, schedule) and
ideas for their mitigation or response.
Prototypes and
proof-of-concepts
To clarify the vision, and validate technical ideas.
Iteration Plan Describes what to do in the first elaboration iteration.
Phase Plan &
Software
Development Plan
Low-precision guess for elaboration phase duration and effort. Tools,
people, education, and other resources.
Development
Case
A description of the customized UP steps and artifacts for this project.
In the UP, one always customizes it for the project.
Since it is inception, the investigation and artifact content should be light. For example,
the Use-Case Model may list the names of most of the expected use cases and actors, but
perhaps only describe 10% of the use cases in detail done in the service of developing a rough
high-level vision of the system scope, purpose, and risks.
Note that some programming work may occur in inception in order to create "proof of
concept" prototypes, to clarify a few requirements via (typically) UI-oriented prototypes,
and to do programming experiments for key "show stopper" technical questions.
You Know You Didn't Understand Inception When...
 It is more than "a few" weeks long for most projects. There is an attempt to define most
of the requirements. Estimates or plans are expected to be reliable.
 You define the architecture (this should be done iteratively in elaboration).
 You believe that the proper sequence of work should be: 1) define the requirements; 2)
design the architecture; 3) implement.
 There is no Business Case or Vision artifact. All the use cases were written in detail.
 None of the use cases were written in detail; rather, 1020% should be written in detail to
obtain some realistic insight into the scope of the problem.
How Much UML during 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, and thus in this presentation, most UML diagramming will occur in
the next phase elaboration.