Object Oriented Analysis and Design: Anmol Bilal Shiekh
Object Oriented Analysis and Design: Anmol Bilal Shiekh
Object Oriented Analysis and Design: Anmol Bilal Shiekh
ANALYSIS AND
DESIGN
Anmol Bilal Shiekh
WEEK 5
Best Practices in UP
Quality Requirement
Early Iterations
Assurance Management
Architecture Change
Development Use Cases Request
Handling
Unified Process
◦ The leading object-oriented methodology for the development
of large-scale software
◦ Maps out when and how to use the various UML techniques
◦ Develop high-risk elements in early iterations
◦ Deliver value to customer
Unified Process
◦ The Unified Process is an adaptable methodology.
◦ The Unified Process is a modeling technique.
◦ UML stands for unified modeling language.
◦ The object-oriented paradigm is iterative and incremental in nature
Phases of UP
Inception
Define Scope of
Elaboration
the Project
•Plan Project
Construction
•Specify Features
Build the Product
Transition
•Baseline
Architecture Deployment/Transit
Product to end-
user
UP Life Cycle
Inception
•Vision Document Elaboration
•Business Cases
•Scope •Refined Vision Construction
•Vague Budget
Estimates
•Development/Implem
entation of Core •Iterative Transition
Architecture Implementation of
•Resolution of High Risks elements • Testing & Deployment
•Requirement •Deployment
Identification Preparations
•Scope
•More Realistic
Estimates
Unified Process Phases
◦ Inception
◦ Establish the business case for the system, define risks, obtain 10% of the
requirements, estimate next phase effort.
◦ Elaboration
◦ Develop an understanding of the problem domain and the system architecture,
risk significant portions may be coded/tested, 80% major requirements identified.
◦ Construction
◦ Programming and testing. Building the remaining system in short iterations.
◦ Transition
◦ Starts when beta testing is completed, Deploy the system in its operating
environment. Deliver releases for feedback and deployment
Workflow of UP
UP VS Waterfall & Incremental
◦ This is not the old "waterfall" or sequential lifecycle of first defining all the
requirements, and then doing all or most of the design.
◦ Inception is not a requirements phase; rather, it is a kind of 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 s a
phase where the core architecture is iteratively implemented, and high risk
issues are mitigated.
Iterative Development
Iteration Length
◦ The UP (and experienced iterative developers) recommends an iteration
length between two and six weeks.
◦ Small steps, rapid feedback, and adaptation are central ideas in iterative
development;
◦ Long iterations subvert the core motivation for iterative development and
increase project risk.
◦ Much less than two weeks, and it is difficult to complete sufficient work to
get meaningful throughput and feedback; much more than six or eight
weeks, and the complexity becomes rather overwhelming, and feedback
is delayed.
UP PHASES
Inception
◦ Define project scope. This includes defining, at a high level, what the system will do and will not
do. This establishes the team. This usually tales the form of a list of high-level features and/or
point form use cases.
◦ Estimate cost and schedule. At a high level, the schedule and cost for the project are
estimated. General estimates are used for iterations in later phases, more specificity is used for
the early iterations in Elaboration.
◦ Define risks. Risk management is important an AUP project. The list of risks is a living compilation
that will change over time as risks are identified, mitigated, avoided and/or materialize and
dealt with.
◦ Determine project feasibility. Your project must make sense from technical, operational, and
business perspectives. In other words, you should be able to build it, once it's deployed you
should be able to run it, and it should make economic sense to do these things..
◦ Prepare the project environment. This includes reserving workspace for the team, requesting
the people that will be needed, obtaining hardware and software that are needed
immediately, and compiling a list of anticipated hardware and software that will be needed
later
Elaboration
◦ The primary goal of the Elaboration phase is to prove the architecture for
the system to be developed. The point is to ensure that the team can
actually develop a system that satisfies the requirements, and the best
way to do that is to build a end-to-end, working skeleton of the system
called an "architectural prototype".
◦ It is important to note that the requirements are not specified completely
at this point. They are detailed only enough to understand architectural
risks and to ensure that there is an understanding of the scope of each
requirement so that subsequent planning can be carried out. Architectural
risks are identified and prioritized; the significant ones are addressed during
Elaboration.
Construction
◦ The focus of the Construction phase is to develop the system to the point
where it is ready for pre-production testing.
◦ Emphasis shifts now to prioritizing and understanding the requirements,
model storming a solution, and then coding and testing the software.
Transition
◦ The Transition phase focuses on delivering the system into production.
There may be extensive testing that takes place during this phase.
◦ Fine-tuning of the product takes place here as well as rework to address
significant defects.
Roles in UP
◦ Stake Holder customer, product manager, etc.
◦ For example, if the next iteration is chosen to be four weeks long, then the
partial system should be integrated, tested, and stabilized by the
scheduled date—date slippage is discouraged.