Software Life-Cycle Management: Openup and Architecture Handbook Overview

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


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).

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.

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

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

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

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

Architecture Handbook Core Components
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

Relationship between AH and OpenUP
Glossary
Iteration Plan
- Terminology
- Appropriate updates
- Iteration Miilestones
- Work Items
- Assigned responsibles
- Project Milestones, etc.
Glossary
Iteration Plan
Solution
Architecture
Work Items List
Project Plan
Risk List
<checklists>
Project-centric document
- Identified Risks and

Constraints
Architecture
Handbook
Project Plan
Risk List
- input to be considered at certain

process steps
System-centric document
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
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.
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

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
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
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.
Governance Model
Remember this ...
Iterative and incremental Models
Phase
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
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.
Governance Model
Remember this ...
Iteration
Phase
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).
Governance Model
Remember this ...
Iteration
Phase
Micro-Increment
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.
OpenUP Life-Cycle
WBS
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
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:
OpenUP Life-Cycle
Elaboration Phase
The primary purpose of the Elaboration Phase is to
validate the solution architecture (feasibility and trade-offs).

activities are:
Phase objectives
Get a more detailed understanding of the

requirements
Design, implement, validate, and baseline an Develop the Architecture

architecture
Test Solution
Mitigate essential risks, and produce
accurate schedule and cost estimates

Ongoing Tasks
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:
OpenUP Life-Cycle
Construction Phase
The primary purpose of the Construction Phase is to
develop and verify the solution incrementally.

activities are:
Phase objectives
Iteratively develop a complete product that is

ready to transition to the user community

Test Solution
Minimize development costs and achieve

some degree of parallelism

Ongoing Tasks
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:
OpenUP Life-Cycle
Transition Phase
The primary purpose of the Transition Phase is to deploy
the solution to the operational environment and validate it.

activities are:
Phase objectives
Beta test to validate that user expectations

are met
Ongoing Tasks
Test Solution
Achieve stakeholder concurrence that

deployment is complete

Test Solution
Improve future project performance through

lessons learned
OpenUP Life-Cycle
Transition Phase
At the Product Release Milestone, a decision to make the
product generally available is made.
Transition Phase Workflow:
OpenUP Disciplines
Remember this ...
Discipline
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.
OpenUP Disciplines
Overview
OpenUP defines the following Disciplines:
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
OpenUP Disciplines
Architecture Discipline
Consists 17 guidance elements.
Associated Tasks:
Outline the Architecture
Demonstrate the Architecture
Primary Role(s): Architect

Architecture Handbook (replaces the OpenUp Architecture Notebook)
OpenUP Disciplines
Development Discipline
Associated Tasks:
Implement Developer Tests
Implement the Solution
Run Developer Tests
Design the Solution
Primary Role(s): Developer

Build
Design
Developer Test
Implementation
OpenUP Disciplines
Test Discipline
Associated Tasks:
Create Test Cases
Run Tests
Primary Role(s): Tester

Test Case
Test Log
Test Script
OpenUP Disciplines
Project Management Discipline
Associated Tasks:
Plan the Project
Plan Iteration
Assess Results
Manage Iteration
Primary Role(s): Project Manager

Iteration Plan
Project Plan
Risk List
Work Items List
OpenUP Disciplines
Configuration & Change Management Discipline
Associated Tasks:
Request Change
Integrate and Create Build
Primary Role(s):
Any Role
Developer

None
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
OpenUP Roles
Overview
These are the Roles, which OpenUP distinguishes:
Architect
Project Manager
Analyst
Tester
Any Role
Developer
Stakeholder
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.
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.
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.
OpenUP 3 Levels of Planning

Overview

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

Level 1 Project Plan
Divide One Big Problem into a Series of Smaller Problems
(Iterations)
Iteration(s)
Planned
Completion
1
Project Plan
Planned
Path

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

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

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


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

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
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
another use case
Questions?

Software Life-Cycle Management: Openup and Architecture Handbook Overview

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Software Life-Cycle Management: Openup and Architecture Handbook Overview

Diunggah oleh

Hak Cipta:

Format Tersedia

Ingo Arnold

Department Computer Science

Software Life-Cycle Management

Complete complete for small co-located teams

Department of Computer Sciences University of Basel 2

What is the Architecture Handbook?

integral part of OpenUP even though it can be used also outside of it

Does not replace a highly skilled solution architect

What is the Architecture Handbook?

The AH underpins a solutions whole life cycle

The AH does not replace an IT Architect

The AH is THE reference for architecture related information

What is the Architecture Handbook?

The AH systematically includes the solutions context

The AH is scalable vertically as well as horizontally

What is the Architecture Handbook?

Architecture Handbook Development Process

EA/DA = Enterprise & Domain Architecture

Q&C = Quality & Compliance

What is the Architecture Handbook?

Architecture Handbook TOC

4. Principles and Requirements

Solution evolves from abstract to concrete

3. Enterprise Architecture Context

Department of Computer Sciences University of Basel 7

What is the Architecture Handbook?

Develop Technical Vision

Develop Solution Increment

Identify & Refine Requirements

Plan and Manage Iteration

Department of Computer Sciences University of Basel 8

What is the Architecture Handbook?

What is the Architecture Handbook?

Department of Computer Sciences University of Basel 10

What is the Architecture Handbook?

Relationship between AH and OpenUP

Enterprise & Domain

Department of Computer Sciences University of Basel 11

What is the Architecture Handbook?

- Project Milestones, etc.

Work Items List

- Identified Risks and

- input to be considered at certain

Evolve to continuously obtain feedback and improve

Department of Computer Sciences University of Basel 13

Organize around the architecture

Department of Computer Sciences University of Basel 14

Focus iterations on meeting the next management

Embrace and manage change

Continuously re-evaluate what you do

Separate the problem from the solution

Use scenarios and use cases to capture requirements

Establish and maintain agreement on priorities

Leverage the architecture as a collaborative tool

Cope with complexity by raising the level of abstraction

Organize the architecture into loosely coupled, highly

These tiers correspond

Department of Computer Sciences University of Basel 18

Department of Computer Sciences University of Basel 19

The lifecycle is divided into 4 phases, each with a particular

Department of Computer Sciences University of Basel 20

Inception: To understand the problem.

Department of Computer Sciences University of Basel 21