Development Processes
UML just is a modeling technique, yet for using it we need
to know:
»
»
»
»
what do we model in an analysis model?
what do we model in system design / architecture model?
what do we model in a detailed design model?
how do these models relate to each other? refinement?
pure extension? mapping? tracing?
» when, in which order do we make these models?
» which techniques/diagrams do we use to which extent?
Modeling all  all on a high-level, some detailed design of complex
issues plus good code-documentation  some high-level models 
no documentation at all?
Quality assurance, prototyping, …: how do they match into the
process?
WHAT - WHY - WHO - WHEN - HOW
Process of Fusion
The Fusion process knows seven main activities:
• Requirements: use case model (actors, use cases), some highlevel use case specifications, non-functional requirements
• Analysis: system class diagram containing basic classes; system
interface with detailed use case specifications, system operations
and events, pre- and post-conditions for system operations
• GUI Design
• Architecture: technical framework of system, main components of
the system, component interfaces and interactions
• Database Design
• Design for each component: design class diagrams, object
collaboration diagrams, visibility, representation of associations,
initial object configuration, detailed class descriptions
• Implementation: code
Rational Unified Process
• A product goes through various cycles, each cycle
having the following phases:
- Inception: proof of concept, feasibility, goals
- Elaboration: detailed requirements, usage scenarios,
architecture, components, high-level interaction patterns
- Construction: refinement of architecture, risk-driven
implementation iterations
- Transition: facilitating user acceptance, ...
• Each phase is split up into various iterations.
• Each iteration has analysis, design and
implementation activities.
• Guiding principles in the Rational Unified / Objectory
process:
- Use-case driven
- Architecture-centric
- Controlled and iterative
- Risk-driven
Deliverables Inception Phase
• Project description
» about the project in general and its goals, not requirements
» “unless you write it out, you can’t be sure everyone agrees on the
same project description”
» one short paragraph to a few pages for really large projects (r)
• Risk analysis
– list of market factors (r)
– list of risk factors: list of things that can go wrong in contrast to
use cases that model expected behavior
– list of assumptions
• Use case diagram, description of actors and use cases
» determine system boundaries and project scope
» one sentence descriptions for use cases and actors
• Project proposal
– to get go / no-go decision
Scoping the project
Defines that part of the system that will be build in this
project.
Project scope is not given by system boundaries!
– prioritize requirements
– take into account
»
»
»
»
market forces
skill of developers
money and time frame
risks
– start small, grow powerful (in follow up projects)
Similar to defining iterations, yet project wide.
Helps to avoid getting stuck in requirements and use
case modeling
Scoping itself is iterative and scope must be redefined!
Deliverables Elaboration Phase
•
•
•
•
Detailed primary scenarios
Secondary scenarios
Activity diagrams
User interface diagrams or examples
» e.g. by using story boarding
• Architecture, maybe class diagrams
• Prototypes
• Project plan
» break down into iterations
» cost estimates for iterations
• Changes to boundaries, scope, list of risk factors,
list of actors, description of use cases as defined in
inception phase!
Planning Construction Iterations
What is done in the first iterations?
• core functionality
» either implemented (if high risk) or as stubs (if low risk)
• use cases that handle high risks
» update list of risks to reflect current situation (complex issues
that are crucial and for which no solution is yet known)
» prioritize risks and decide which ones need to be solved first
• primary scenarios of use cases only
» first goal is to solve high risk challenges, full functionality
comes later on
Each iteration produces an executable, testable, in later
iterations even deployable release of the system.
» stubs, simulators, additional test-components
» tested by other people than its developers
(d: What should be planned for last iteration?)
Use Cases in the Process
Inception phase:
Use cases are developed to help scope out the project.
Elaboration phase:
More detailed use cases are developed for:
» risk analysis
» baseline architecture
» plan the construction phase
Construction phase:
Uses cases are starting points for:
» design (where more detailed use cases may be developed)
» developing test plans
Use cases are part of requirements to be satisfied.
Transition phase:
Use cases can be used to develop user guides and training.
Use Case Driven
• Use cases bind all workflows together
• Use cases are the starting point for requirements
capture
• Use cases are used to define iterations
• Use cases help to structure user documentation
• Use cases help to define and structure test cases
==> advantages of use case driven approach?
==> dangers of use case driven approach ? (d)
Function versus Form
Use cases
specify function
Architecture
specifies form
==> process is use case driven (helps organizing work and models)
but architecture centric (is focus of models and work)
==> architecture and design patterns are not part of notation
but have to be designed into models
Other Elements of a Process
Definition
• Either predefined or project-specific
• Consider a process like Rational Unified just as a
framework where you plug in and derive from it the
project specific, adapted and detailed process definition
• Also project definition is created incrementally and refined
iteratively (inclusive project plan reviews) during the
project!
• Other elements? (d)