Ch 3: Unified Process
CSCI 4320: Software Engineering
Unified Process
• Adaptable methodology for ObjectOriented Software production
• Iterative and Incremental
• UML diagrams
– Unified Modeling Language (UML)
– Redrawn as more knowledge about system is
gained (more accurate, extended)
UML Class Diagram
• Models the classes needed and relationship
associations, inheritance, compositions and
dependencies
Iteration and Incrementation
The basic software development process is
Iterative
– Each successive version is intended to be
closer to its target than its predecessor
An Incremental Process
– Miller’s Law : concentrate on ~ 7 chunks
– Use stepwise refinement
– handle in order of current importance
Waterfall vs. Unified Process
Waterfall
• One dimensional
• Each phase must be
completed before you
begin the next phase.
•
•
•
•
•
Unified Process
Incremental and
Iterative
Two dimensional
Task is divided into
increments (phases)
Within each increment
the developers have
to iterate (workflows)
until task is complete
Consecutive series of
waterfall models
Waterfall vs. Unified Process
Waterfall
Iterative and Incremental Model: Unified Process
Phases of the Unified Process
• Inception :
– Determine whether it is worthwhile to develop product
– Initial scope and financial details
• Elaboration:
– Refine requirements, produce software management
plan
• Construction
– Produce beta-release, initial user manual
• Transition
– Client feedback, correct faults, complete manuals
Workflows in the Unified Process
• Different workflows (activities) are
performed over the entire life cycle
• However, there are times when one
workflow may be dominant
• Core Workflows
– Requirements
– Analysis
– Design
– Implementation
– Test
Requirements Workflow
1. Acquire basic understanding of the application
domain (banking, automobile manufacturing)
2. Identify Customer Impact
3. Identify Constraints (deadlines, costs, existing
hardware, software)
•
•
Written in Language of Client
Problem: Sometimes the client does not know
what is going on in his organization.
GOAL: Assist client in gaining understanding of
system
Analysis Workflow
• Analyze and refine requirements for detailed
understanding
• Written in language of developer – more precise.
• Specifications produced are essential for testing
and maintenance
• OO Architectural Design: UML diagrams and
descriptions are given to client for confirmation
(Use Cases and Class Diagrams)
• Detailed planning and estimating: Software
Project Management Plan with deliverables,
milestones and budget
GOAL: Spell out what the project is to do
Design Workflow
• Refine analysis artifacts until it is a form that
can be implemented by programmers
• OO Detailed Design: For each class select
algorithms and data structures
• Have a written record of why specific
decisions were made
• Design to allow for future enhancements
GOAL: Show how the product will complete
specifications
Implementation Workflow
• Code in the chosen language(s)
• Each programmer is only given the
detailed design of his module
• Only during integration will individual
programmer know if architectural design
is correct
GOAL: Code and Integrate modules
Test Workflow
• Carried out in parallel with all other workflows
• Artifacts should be properly numbered, crossreferenced and index for traceability
 Requirements:
– SQA group review requirements
 Analysis:
– Representatives of SQA, analysis team and clients
walkthrough and inspect artifacts
– Obtain additional independent estimates of cost and
duration
GOAL: Find Faults Early!
Test Workflow (cont)
 Design
– Client is not usually present
– Look for logic faults, interface faults, error handling,
conformance to specifications
– Every aspect of design is linked with an analysis artifact
 Implementation
– Desk check each component as you code
– Code review – programmer guides members through
listing
– SQA performs unit, integration and product (comparison
against specifications) testing
– Client performs acceptance testing
GOAL: Find Faults Early!
PostDelivery Maintenance
• Common problem: Lack of existing
documentation
• A proper record must be kept of all
changes made and reasons for the
change.
• Testing ensures that:
– Required changes have been made
– No faults have been introduce