Ingo Arnold
Department Computer Science
University of Basel
Introduction
Software Life-Cycle Management
OpenUP and Architecture Handbook Overview
What is OpenUP?
Process with its roots in (R)UP
An iterative software development process that is minimal,
complete, and extensible:
Minimal contains vital roles, tasks and guidance
Complete complete for small co-located teams
Extensible serves as a foundation that can be extended and tailored
Department of Computer Sciences University of Basel 2
What is the Architecture Handbook?
Lecture-specific extension to OpenUP
The Architecture Handbook
solution architecture development method & description standard
comprised of ...
- a process description document
- an architecture description template
- many complementary documents (e.g. checklists, guidelines, models)
integral part of OpenUP even though it can be used also outside of it
based on solution architecture best practices
includes a view model which spans core views and cross-cutting
persp.
- Application Architecture
- Data Architecture
- Technology Architecture
Does not replace a highly skilled solution architect
Department of Computer Sciences University of Basel 3
What is the Architecture Handbook?
Principles
The Architecture development process is iterative and agile
As such the Handbook is supporting this iterative and agile nature, accordingly
This means that all chapters are revisited over and over again while evolving the
solution architecture steadily rather than 100% completing one chapter after the other
in a sequential manner
The AH underpins a solutions whole life cycle
As a consequence it must be used to support the creation as well as all operational
changes to the solution in order to always reflect this solutions architecture.
The AH does not replace an IT Architect
The Architecture Handbook does by no means replace a well-educated IT Architect.
Rather think of it as a tool-box that makes the IT Architects work more standardized,
and highly efficient.
The AH is THE reference for architecture related information
Thereby it provides crucial information for a broad range of stakeholder groups
beyond just the IT Architects (e.g. Project Manager, Project Quality Manager,
Business Analyst, Requirements Engineer, Service Manager).
Department of Computer Sciences University of Basel 4
What is the Architecture Handbook?
Principles
The AH supports all types of IT engagements
Examples are (e.g. package customization, infrastructure service, application
integration)
It is a clear misperception that proper architecture work and documentation only
needs to be performed in the context of custom application development
engagements!
The AH systematically includes the solutions context
This means that any work that is performed by the IT Architect takes into account the
broader business-, services-, information-, application-, and technology-landscapes.
The AH is scalable vertically as well as horizontally
Vertical scalability of the AH means that within each engagement the concrete set of
process steps to focus on (as opposed to the ones not as relevant) can fully be
adapted to the problem at hand. For example, one can focus on non-functional
requirements, only.
Horizontal scalability refers back to iterative, incremental, agile-development. It
means that the level of detail into which a concrete engagement needs to zoom over
time is up the team to decide.
Department of Computer Sciences University of Basel 5
What is the Architecture Handbook?
End-2-End Architecture Process
Plan
Q&C
PPM
APM
Build
Run
Project
EA/DA
CM
PM
CP
SM
Architecture Handbook Development Process
Step 1 Define Enterprise Architecture Context
Step 2 Refine Principles and Requirements
Step 3 Develop Alternatives
Step 4 Evaluate Alternatives
Step 5 Elaborate System Context
Step 6 Elaborate Architecture Vision
Step 7 Elaborate Application Architecture
Step 8 Elaborate Data Architecture
Step 9 Elaborate Technology Architecture
Step 10 Elaborate cross-cutting Architecture Perspective
Step 11 Document Architecture Assumptions
Step 12 Document Architecture Decisions
Step 13 Review Architecture
EA/DA = Enterprise & Domain Architecture
PPM = Project Portfolio Management
APM = Application Portfolio Management
Q&C = Quality & Compliance
CM = Change Management
PM = Problem Management
CP = Capacity Planning
SM = Service Management
Department of Computer Sciences University of Basel 6
What is the Architecture Handbook?
Iterative Approach to Architecture Development
Plan
Build
Inception
Elaboration
Run
Construction
Transition
Architecture Handbook TOC
Conceptual
Solution Outline
(High-Level
Architecture)
4. Principles and Requirements
5. Architecture Alternatives
6. Architecture Elaboration
6.1 System Context
6.2 Architecture Vision
6.3 Application Architecture
6.4 Data Architecture
6.5 Technology Architecture
6.6 Cross-cutting Architecture Perspetives
7. Architecture Assumptions
8. Architecture Decisions
Detailed Solution
Design
(Detailed
Architecture)
Solution
Implementation &
Testing
(Detailed
Design)
Solution evolves from abstract to concrete
3. Enterprise Architecture Context
Department of Computer Sciences University of Basel 7
What is the Architecture Handbook?
Activities / Tasks (High-Level Overview)
Build
Inception
Initiate Project
Elaboration
Develop Architecture
Construction
Develop Solution Incr.
Transition
Develop Solution Incr.
Develop Technical Vision
Develop Solution Increment
Design Solution
Design Solution
Plan Project
Refine Architecture
Implement solution
Implement solution
Identify & Refine Requirements
Identify & Outline Req.
Detail UC Scenarios
Detail sys-wide Req.
Detail Test Cases
Agree on Technical
Approach
Envision the Architecture
Test Solution
Test Solution
Test Solution
Implement Tests
Implement Tests
Implement Tests
Run Tests
Run Tests
Run Tests
Plan and Manage Iteration
Plan Iteration
Manage Iteration
Assess Results
Department of Computer Sciences University of Basel 8
What is the Architecture Handbook?
Deliverables (High-Level Overview)
Build
Inception
Elaboration
Construction
Transition
Glossary
Vision
Project Plan
Work Items List
Iteration Plan
System-wide Requirements
Use Case(s)
Use Case Model
Risk List
Test Case, Developer Test, Test Script, etc.
Architecture Handbook
Design, Implementation, Built
Department of Computer Sciences University of Basel 9
What is the Architecture Handbook?
Architecture Handbook Core Components
Department of Computer Sciences University of Basel 10
What is the Architecture Handbook?
Enterprise
Architecture
Relationship between AH and OpenUP
Enterprise & Domain
Architectures
(Repositories &
Inventories)
- Stakeholders
- High-level Business Need
Vision
Solution
Architecture
- Principles
- Constraints
- Standards
- Baseline Business Architecture
- Baseline Application Architecture
- Baseline Data Architecture
- Baseline Technology Architecture
Architecture
Handbook
High-level solution
Factors driving costs
Milestones for implementation
Dependencies / Linkages
Input regarding the compliance
Positioning information
Costs
Technical Risk
Effort Estimations
Use-Case Model
Vision
Project Plan
Risk List
Use-Case(s)
Use-Case Model
System-wide Req.
- Functional Requirements
- Non-functional Requirements
- Non-functional Requirements
- Architecture significant
functional requirements
Use-Case(s)
System-wide Req.
Project-centric document
System-centric document
Department of Computer Sciences University of Basel 11
What is the Architecture Handbook?
Relationship between AH and OpenUP
Glossary
Iteration Plan
- Terminology
- Appropriate updates
- Iteration Miilestones
- Work Items
- Assigned responsibles
- Appropriate updates
- Project Milestones, etc.
- Appropriate updates
Glossary
Iteration Plan
Solution
Architecture
Work Items List
Project Plan
Risk List
<checklists>
Project-centric document
- Identified Risks and
Constraints
Architecture
Handbook
Project Plan
- Appropriate updates
Risk List
- input to be considered at certain
process steps
System-centric document
Department of Computer Sciences University of Basel 12
Core Principles
Overview
OpenUP is based on a set of mutually supporting core
principles
Collaborate to align interests and share understanding
Evolve to continuously obtain feedback and improve
Balance competing priorities to maximize stakeholder value
Focus on articulating the architecture
Department of Computer Sciences University of Basel 13
Core Principles
Collaboration
Maintain a common understanding
Key artifacts: Vision, requirements, architecture handbook, iteration
plan
Share responsibility
Everybody owns the product, help each other
Learn continuously
Develop technical and interpersonal skills, be a student and a teacher
Organize around the architecture
The architecture provides a shared understanding of the solution and
forms the basis for partitioning work.
Department of Computer Sciences University of Basel 14
Core Principles
Evolve
Develop your project in iterations
Use time-boxed iterations that deliver incremental value and provide
frequent feedback.
Focus iterations on meeting the next management
milestone
Divide the project into phases with clear goals and focus iterations on
meeting those goals.
Embrace and manage change
Adapt to changes.
Continuously re-evaluate what you do
Department of Computer Sciences University of Basel 15
Core Principles
Balance
Know your audience & create a shared understanding of
the domain.
Identify stakeholders early and establish a common language
Separate the problem from the solution
Understand the problem before rushing into a solution.
Use scenarios and use cases to capture requirements
Capture requirements in a form that stakeholders understand
Establish and maintain agreement on priorities
Prioritize work to maximize value and minimize risk early
Manage scope
Department of Computer Sciences University of Basel 16
Core Principles
Focus
Create the architecture for what you know today
Keep it as simple as possible and anticipate change
Leverage the architecture as a collaborative tool
A good architecture facilitates collaboration by communicating the
big-picture and enabling parallelism in development.
Cope with complexity by raising the level of abstraction
Use models to raise the level of abstraction to focus on important
high-level decisions.
Organize the architecture into loosely coupled, highly
cohesive components
Department of Computer Sciences University of Basel 17
Governance Model
Balancing Agility and Discipline
OpenUP incorporates a three-tiered governance model to
plan, execute, and monitor progress.
These tiers correspond
to personal, team and
stakeholder concerns
and each operates at a
different time scale and
level of detail.
Department of Computer Sciences University of Basel 18
Governance Model
Remember this ...
Iterative and incremental Models
Phase
Department of Computer Sciences University of Basel 19
Governance Model
Project Life-Cycle
OpenUP uses an iterative, incremental lifecycle.
Proper application of this lifecycle directly addresses the
first core principle (Evolve).
The lifecycle is divided into 4 phases, each with a particular
purpose and milestone criteria to exit the phase
Department of Computer Sciences University of Basel 20
Governance Model
Project Life-Cycle
Inception: To understand the problem.
Elaboration: To validate the solution architecture.
Construction: To build and verify the solution in increments.
Transition: To transition the solution to the operational
environment and validate the solution.
Department of Computer Sciences University of Basel 21
Governance Model
Remember this ...
Iterative and incremental Models
Iteration
Phase
Department of Computer Sciences University of Basel 22
Governance Model
Iteration Life-Cycle
Phases are further decomposed into a number of
iterations.
At the end of each iteration a verified build of the system
increment is available.
Each iteration has its own
lifecycle, beginning with
planning and ending in a
stable system increment,
Iteration Review (did we
achieve the iteration objectives) and a Retrospective (is there a better
process).
Department of Computer Sciences University of Basel 23
Governance Model
Remember this ...
Iterative and incremental Models
Iteration
Phase
Micro-Increment
Department of Computer Sciences University of Basel 24
Governance Model
Micro-Increments
Micro-increments are small steps towards the goals of the
iteration.
Should be small enough to be completed in a day or two
Identify Stakeholders is a micro-increment (one step of a task).
Determine Technical Approach for Persistency is a micro-increment
(a task with a specific focus)
Develop Solution Increment for UC 1 Main Flow is a micro-increment
(a task with a specific focus)
Micro-increments are defined and tracked via the work
items list.
Work items reference requirements and process tasks as
needed to provide required inputs to complete the microincrement.
Department of Computer Sciences University of Basel 25
OpenUP Life-Cycle
WBS
Department of Computer Sciences University of Basel 26
OpenUP Life-Cycle
Inception Phase
The primary purpose of the Inception Phase is to understand the scope of the problem and feasibility of a solution.
More specifically, the objectives and associated process
activities are:
Phase objectives
Activities that address objectives
Define a Vision
Initiate Project
Identify key system functionality
Identify and Refine Requirements
Determine at least one possible solution
Agree on Technical Approach
Understand the cost, schedule, and risks
associated with the project
Initiate Project
Plan and Manage Iteration
Department of Computer Sciences University of Basel 27
OpenUP Life-Cycle
Inception Phase
At the Lifecycle Objectives Milestone, a decision to
proceed with the same scope, change the scope, or
terminate the project is made.
Inception Phase Workflow:
Department of Computer Sciences University of Basel 28
OpenUP Life-Cycle
Elaboration Phase
The primary purpose of the Elaboration Phase is to
validate the solution architecture (feasibility and trade-offs).
More specifically, the objectives and associated process
activities are:
Phase objectives
Activities that address objectives
Get a more detailed understanding of the
requirements
Identify and Refine Requirements
Design, implement, validate, and baseline an Develop the Architecture
architecture
Develop Solution Increment
Test Solution
Mitigate essential risks, and produce
accurate schedule and cost estimates
Plan and Manage Iteration
Ongoing Tasks
Department of Computer Sciences University of Basel 29
OpenUP Life-Cycle
Elaboration Phase
At the Lifecycle Architecture Milestone, a decision to
proceed with the same scope, change the scope, or
terminate the project is made.
Elaboration Phase Workflow:
Department of Computer Sciences University of Basel 30
OpenUP Life-Cycle
Construction Phase
The primary purpose of the Construction Phase is to
develop and verify the solution incrementally.
More specifically, the objectives and associated process
activities are:
Phase objectives
Activities that address objectives
Iteratively develop a complete product that is
ready to transition to the user community
Identify and Refine Requirements
Develop Solution Increment
Test Solution
Minimize development costs and achieve
some degree of parallelism
Plan and Manage Iteration
Ongoing Tasks
Department of Computer Sciences University of Basel 31
OpenUP Life-Cycle
Construction Phase
At the Initial Operational Capability Milestone, a decision to
deploy the solution to the operation environment is made.
Construction Phase Workflow:
Department of Computer Sciences University of Basel 32
OpenUP Life-Cycle
Transition Phase
The primary purpose of the Transition Phase is to deploy
the solution to the operational environment and validate it.
More specifically, the objectives and associated process
activities are:
Phase objectives
Activities that address objectives
Beta test to validate that user expectations
are met
Ongoing Tasks
Develop Solution Increment
Test Solution
Achieve stakeholder concurrence that
deployment is complete
Plan and Manage Iteration
Test Solution
Improve future project performance through
lessons learned
Plan and Manage Iteration
Department of Computer Sciences University of Basel 33
OpenUP Life-Cycle
Transition Phase
At the Product Release Milestone, a decision to make the
product generally available is made.
Transition Phase Workflow:
Department of Computer Sciences University of Basel 34
OpenUP Disciplines
Remember this ...
Iterative and incremental Models
Discipline
Department of Computer Sciences University of Basel 35
OpenUP Disciplines
Overview
A discipline is a collection of tasks that are related to a
major "area of concern" within the overall project.
Within the lifecycle, tasks are performed concurrently
across several disciplines.
Separating tasks into distinct disciplines is simply an
effective way to organize content that makes
comprehension easier.
Department of Computer Sciences University of Basel 36
OpenUP Disciplines
Overview
OpenUP defines the following Disciplines:
Department of Computer Sciences University of Basel 37
OpenUP Disciplines
Requirements Discipline
Associated Tasks:
Define Vision
Detail Requirements
Find and Outline Requirements
Primary Role(s): Analyst
Associated Work Products:
Glossary
Supporting Requirements Specification
Use Case
Use-Case Model
Vision
Department of Computer Sciences University of Basel 38
OpenUP Disciplines
Architecture Discipline
Consists 17 guidance elements.
Associated Tasks:
Outline the Architecture
Demonstrate the Architecture
Primary Role(s): Architect
Associated Work Products:
Architecture Handbook (replaces the OpenUp Architecture Notebook)
Department of Computer Sciences University of Basel 39
OpenUP Disciplines
Development Discipline
Associated Tasks:
Implement Developer Tests
Implement the Solution
Run Developer Tests
Design the Solution
Primary Role(s): Developer
Associated Work Products:
Build
Design
Developer Test
Implementation
Department of Computer Sciences University of Basel 40
OpenUP Disciplines
Test Discipline
Consists 7 guidance elements.
Associated Tasks:
Create Test Cases
Run Tests
Primary Role(s): Tester
Associated Work Products:
Test Case
Test Log
Test Script
Department of Computer Sciences University of Basel 41
OpenUP Disciplines
Project Management Discipline
Associated Tasks:
Plan the Project
Plan Iteration
Assess Results
Manage Iteration
Primary Role(s): Project Manager
Associated Work Products:
Iteration Plan
Project Plan
Risk List
Work Items List
Department of Computer Sciences University of Basel 42
OpenUP Disciplines
Configuration & Change Management Discipline
Consists 7 guidance elements.
Associated Tasks:
Request Change
Integrate and Create Build
Primary Role(s):
Any Role
Developer
Associated Work Products:
None
Department of Computer Sciences University of Basel 43
OpenUP Roles
Overview
Roles do not represent individual responsibilities over tasks
or deliverables but are instead hats that people can put
on when working together.
OpenUP Roles are described by the following attributes:
Primary relationships to
- Tasks
- Workproducts
Secondary relationships
- Additionally Performs
- Modifies
Main Description
Skills
More Information and Concepts
Department of Computer Sciences University of Basel 44
OpenUP Roles
Overview
These are the Roles, which OpenUP distinguishes:
Architect
Project Manager
Analyst
Tester
Any Role
Developer
Stakeholder
Department of Computer Sciences University of Basel 45
OpenUP Roles
Role Example: Architect
This role is responsible for defining the software
architecture, which includes making the key technical
decisions that constrain the overall design and
implementation of the project.
Department of Computer Sciences University of Basel 46
OpenUP Tasks
Overview
Tasks typically have an associated concept, guideline and
checklist.
If one needs to perform a task
one reads the concept to understand the context,
reads the steps to determine what needs to be done,
reads the guideline to determine how to do it,
then reads the checklist to validate completion.
Department of Computer Sciences University of Basel 47
OpenUP Artifacts
Overview
Typically artifacts have associated templates and
checklists.
The template provides additional guidance on completing
the artifact.
The checklist helps check the quality of the resulting
artifact.
Department of Computer Sciences University of Basel 48
OpenUP 3 Levels of Planning
Overview
Department of Computer Sciences University of Basel 49
OpenUP 3 Levels of Planning
Level 1 Project Plan
The Project Plan provides a coarse-grain plan to complete.
Time-scale of months.
Defines number of iterations (initial estimate) and major
milestones
Main artifacts: Project Plan
Vision
Project Starting Point
Stakeholder
Satisfaction Space
Department of Computer Sciences University of Basel 50
OpenUP 3 Levels of Planning
Level 1 Project Plan
Divide One Big Problem into a Series of Smaller Problems
(Iterations)
Iteration(s)
Planned
Completion
1
Project Plan
Planned
Path
Department of Computer Sciences University of Basel 51
OpenUP 3 Levels of Planning
Level 2 Iteration Plan
The Iteration Plan provides a fine grain plan for an
iteration.
Time-scale of weeks.
Defines number of work items to complete in this iteration.
Main artifacts: Iteration Plan, Work Item List
Department of Computer Sciences University of Basel 52
OpenUP 3 Levels of Planning
Level 2 Iteration Plan
Agile Estimation
Size (points):
- For each work item, we estimate how big it is.
Velocity
Effort (days or hours):
High
- A measurement of how many points are delivered in each iteration
High-priority work items
should be well-defined
Priority
- Estimate of actual effort.
Low-priority work items
can be vague
Each iteration implements the
highest-priority work items
New work items can be
added at any time
Work items can be
reprioritized at any time
Low
Work items can be
removed at any time
Work Item List
Department of Computer Sciences University of Basel 53
OpenUP 3 Levels of Planning
Level 2 Iteration Plan
Plan your iteration
Specify target velocity and outline iteration objectives in iteration plan
Analyze top priority Work Item
-
Estimate effort in hours
If too big to fit within iteration, break down into smaller work items
Add to Iteration Plan
Analyze next work item in priority order until Iteration Plan is full
Specify test and other assessment criteria
Estimate and add
to iteration plan
Iteration Plan
Iteration objectives
Iteration Work Item List
Measure / test results
Work Item List
Department of Computer Sciences University of Basel 54
OpenUP 3 Levels of Planning
Level 3 Creating Solution for Work Item
Select a work item assigned to the current iteration
Collaborate with team if it needs breakdown
Time-scale of days
Identify requirements closure
Attachments: use case, supporting requirement, bug information, test
case
Gather additional information
Repeat until complete
Build a small solution verified with developer tests
Verify completion with system tests
Department of Computer Sciences University of Basel 55
OpenUP Iteration Assessments
Overview
Use Iteration Assessments to Change Direction
Planned
Path
Planned
Completion
2
4
5
Project Plan
(updated)
Iteration
Assessments
Actual
Completion
Actual
Path
Department of Computer Sciences University of Basel 56
OpenUP Requirements
Iterative Requirements Development
Overview
Vision defines product
Use-case identification scopes release
Use-case detail drives work in an iteration
Supporting requirements are managed across the lifecycle
OpenUP promotes a breadth-before-depth approach to
requirements development:
Identify use cases (name and brief desc only).
Prioritize use cases
Detail main scenario of high priority use case
Implement and verify
Detail alternate scenarios of same use case or main scenario of
Department of Computer Sciences University of Basel 57
another use case
Questions?
Department of Computer Sciences University of Basel 58
