Sa.architecting process

Content
1 The Architecting Process
Introduction
Architecting in RUP
Agile Processes
Conclusions
Tuheirwe-Mukasa (Makerere University) BSE 3201 2011/2012 1 / 64

The Architecting Process Introduction
Role of the Architect
A good process needs somebody that takes initiative and acts as
inspirator and ambassador
This is the role of the architect during all phases of the product creation
process:
Requirements engineering and architecting
Coaching of implementation, maintenance and roll-out

Introduction
Ensure a proper balance between architecture design and architecting
process

Architecting Workﬂow
Dependencies (not precedence or timing)

Architecting Workﬂow 2

Architecting Workﬂow 3

When to Stop Architecting
When all requirements are covered,
The architecture is as simple as possible,
Detailed enough to be unambiguously implemented by another team
and,
All risks are covered

When to Stop Architecting

The Devil’s Triangle
Discover where the stakeholder emphasis lies and act accordingly

Risk Management Plan

Hints
Failures caused by sloppy work and processes are NOT risks
Consider not only risks for the architecting phase, but for the
complete product creation process
For each risk, deﬁne:
the priority (e.g. derived from probability * severity),
the owner (the person that is responsible for taking action),
the indicators (thresholds for the occurrence of the risk)
the preventive & corrective action
Risks associated with key-drivers have a high severity
Make the risk descriptions SMART, that is, Speciﬁc, Measurable,
Agreed, Realizable, Timed

Heuristics
Risks drive the architecting process: If you don’t actively attack the
risks, the risks will attack you!
Risks can be a hint for strengthening the requirements
Also the risk management plan evolves during a project
Initially the uncertainties result in many risks
As the project evolves, risks are closer investigated and hopefully
resolved
Finally, the risks will mainly be related to aspects that can not be
directly inﬂuenced by the architect

The Architecting Process Architecting in RUP
Architecting in RUP
Deﬁnition
RUP is a description of process families that are architecture-centric,
emphasize best-practices and work incremental and iterative
Best practices are commercially proven approaches to development
Ensure success of project by addressing root causes of typical
problems

RUP Best Practices
Develop iteratively: successive series of releases of increasing
completeness (iterations)
Manage requirements: systematic approach to elicit, document,
manage changes, assess
Use component architectures: reduce complexity, give robust,
resilient, re-usable architecture
Assignment: Identify and explain the other three RUP best practices

THE RUP CORE WORKFLOWS

RUP Phases
Inception
Focus is on establishing product vision and business case
Definition of use-cases, requirementss and candidate architectures
Primarily meant for new development efforts that have significant
business and requirements risks

Elaboration
Focus is on discovery of the architecture
Considers signiﬁcant functional and non-functional requirements
Provides a stable basis for further design and implementation
Evaluation of architectural prototypes
Establishment of an architectural baseline

Construction
Architecture and requirements have been baselined,
Changes are controlled by a strict change management process
Focus is on ﬂeshing-out the remaining requirements
By the end of the construction phase, all relevant requirements have
been analyzed, designed, built and tested

Transition
Focus is on operation of the system in user environment
Meet requirements to the satisfaction of stakeholders
Low and stable failure rate
Good user documentation and education

Major & Minor Milestones

Initial: Life Cycle Objectives (LCO) milestone
Elaboration: Life Cycyle Architecture (LCA) milestone
Construction: Initial Operational Capability (IOC) milestone
Transition: Product Release (REL) milestone

Example
Cycle 0: Develop business- and domain model
Cycle 1: Develop the objectives and verify the existence of at least
one feasible architecture by an initial model, if necessary for each
subsystem LCO
Cycle 2: Design a detailed architecture, verify its feasibility and
ensure that there are no major risks in satisfying the speciﬁcations
and plans LCA
Cycle 3: Implement a workable initial system, including support for
system preparation, training and use IOP
Cycle 4: Develop next increment ...

RUP iterations are based on THE WIN-WIN SPIRAL MODEL:

Iterate Quickly!
Uncertainty and vagueness are major problems for an architect,
especially during the early project phases
In order to tackle them, quick iterations are essential in order
To investigate all architectural signiﬁcant aspects,
To get fast feedback and
To avoiding hurring along dead-end streets

Iterating and Probing

W6H2 Checklist
Before each step/iteration ask yourself:
Objectives: What do I or we want to achieve?
Milestones & schedules: What needs to be done when?
Responsibilities:
Who is responsible for what?
Where are people organizationally located?
Approach: How will the job be done, technically and managerially?
Resources: How much of each resource is needed?
After each step/iteration reﬂect on how things were going and how well
the objectives were met ⇒ Learning on the job

RUP Milestones
Major milestones after each phase
Synchronization points where managerial and technical realms meet
Important business decisions about proceeding (or not!),
requirements, budget and schedule
Minor milestones after each iteration
Technical managers and developers evaluate deliverables and decide
how to proceed

Major Milestones
Essential process anchors that are critical for success or failure
Life Cycle Objectives (LCO) (key-drivers): focus is on establishing
a sound business case and requirements for building the system
Life Cycle Architecture (LCA): purpose is to commit on a single
architecture and to elaborate it to the point of covering all major
risks
Initial Operational Capabilities (IOC): implementation of an
operational system (1st increment)
Release (REL): preparations for achieving a smooth introduction &
operation

Milestone Objectives
Risk-driven: The focus is on the most critical issues and serious risks
are attacked early
Serious misunderstandings are made evident early
Feedback (on early increments) is encouraged
Continuous iterative testing and releasing supports objective
assessment of the project status
The workload of the team is spread out more evenly
The team can leverage the lessons learned

LCO Key Elements
Top-level system objectives (key-drivers): Business objectives,
boundaries, environment & evolution parameters
Operational concept (operational drivers): Operation & maintenance
scenarios, use-cases, product life-cycle
System requirements: Goals & requirements, growth vectors and
priorities
Initial system/software architecture options: Elements & relations,
COTS components, infeasible solutions
Life-cycle plan: Stakeholders per phase, process model, top-level
increments
Feasibility rationale
Compatibility and conceptual integrity of all parts is essential

LCA Key Elements
Most are extensions of LCO elements
System- and/or software architecture: Elaborate definition of
components, interfaces, connectors, behavior, styles, constraints,
configurations, ...
Component specifics: COTS components often drive requirements
and architecture
Quality attribute specifics & views: Dependability and other
X-abilities
Architectural evolution: Identification of likely evolution directions
Full-scale development only if all LCA-Milestone criteria are met,
the architecture is stable and all major risks have been resolved!

IOC & REL key Elements
The IOC comprises a reﬁnement and implementation of the
architecture in order to achieve an operational system
For the REL the following additional activities are necessary:
Software preparation
Operational & support SW with suﬃcient documentation
Data preparation and conversion
Rights and licenses for COTS components
Appropriate operational readiness testing

REL Key Elements
Transition preparation
Facilities, supplies and COTS support arrangements
Training and team-building
Sales people, users, operators, maintainers, ...

Model Evolution in RUP
During the four RUP phase, the various models grow gradually to
completion
The principles of the architecture, do not change signiﬁcantly after the
elaboration phase (LCA milestone)

Architecture Description in RUP

Artifacts
Deﬁnition
A piece of information that is produced and/or used during the execution
of the process
Tangible by-product of process
Deliverables are subset of artifacts

Artifact Examples
Artifacts take various shapes or forms
Model e.g., use-case model, with model elements
Model element e.g., use case, which is part of a model
Document e.g., Software Architecture Document
Source code
Project plan

Roles
Artifacts are responsibility of single role
Use artifacts as input to activities, produce, modify artifacts
Role performs set of activities
Role deﬁnes behaviour, responsibilities of individual(s), working as
team in development organization
Note: Roles are not individuals

RUP Summary
RUP provides a disciplined approach that emphasizes the adoption of
best practices and risk reduction
RUP should be tailored to ones needs:
Roadmaps for diﬀerent types of software projects
Adaptation of process and artifacts
RUP tailoring is mainly w.r.t. the level of reﬁnement

RUP Summary 2
Keep it simple
Produce a working version early
Do not produce too many documents
Be goal oriented: Know why to perform certain activities
Introducing RUP is an organization change process that costs a lot of
eﬀort and time

The Architecting Process Agile Processes
Agile Processes
Problems with traditional heavy-weight processes:
The project will produce the wrong product
The project will produce a product of inferior quality
The project will be late
We’ll have to work 80 hours a week
We’ll have to break commitments
We won’t be having fun

Rationale
Businesses now operate in a global, rapidly changing environment
Respond to:
New opportunities and markets,
Changing economic conditions, and the
emergence of competing products and services
Software is part of almost all business operations, therefore rapid
software development and delivery are essential

Characteristics of Rapid Software Development
Specification, design, and implementation are interleaved
No detailed system specification, design documentation is minimized or
generated automatically
User requirements document only defines the most important
characteristics of the system
System is developed in a series of versions
End-users, other system stakeholders specify, evaluate each version,
propose changes, new requirements for later versions
System user interfaces are often developed using an interactive
development

Agile Manifesto
Value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
While there is value in the items on the right, the items on the left
are valued more

Agile Values
Individuals and interactions over processes and tools
Start small and upgrade only if the necessity is proven
Working software over comprehensive documentation
Produce no document unless its need is immediately and signiﬁcant
Customer collaboration over contract negotiation
Successful projects involve regular & frequent customer feedback
Responding to change over following a plan
The ability to respond to change determines success/failure of projects

Agile Approaches
Extreme programming
Scrum
Crystal
Adaptive Software Development
Dynamic Systems Development Method (DSDM)
Feature Driven Development

Useful for
Product development where a software company is developing a small
or medium-sized product for sale
Custom system development within an organization, clear
commitment from the customer to become involved in the
development process

Difficulties
Customer involvement depends on having a willing customer who is
able to spend time with the development team and can represent all
system stakeholders
Individual team members may not have suitable personalities for the
intense involvement
Prioritizing changes can be extremely difficult, especially in systems
for which there are many stakeholders.
Maintaining simplicity requires extra work - pressure from delivery
schedules
organizations have defined processes that they follow, difficult for
them to move to a working model in which processes are informal and
defined by development teams

Extreme Programming
Developed by pushing recognized good practice, such as iterative
development, to ’extreme’ levels
Several new versions of a system may be developed by diﬀerent
programmers, integrated and tested in a day
Requirements are expressed as scenarios (called user stories), which
are implemented directly as a series of tasks

Extreme Programming Release Cycle

Example

Task Cards

Conditions for Using XP
Small project team: max. 10 people
The team is co-located
The team is willing and able to do pair programming
There is a commitment for an (on-site) customer
There is considerable domain knowledge

Release deadlines are never slipped; if there are development
problems, the customer is consulted and functionality is removed from
the planned release
The new build of the software is accepted only if all tests execute
successfully (all existing automated tests as well as the tests for the
new functionality)

Assignment
1 Identify atleast 3 advantages of pair programming
2 Brieﬂy explain the Scrum process

12 Principles of Agile Processes
1 The highest priority is to satisfy the customer through early and
continuous delivery of valuable software
2 Welcome changing requirements, even late in the development; agile
processes harness change for the customers competitive advantage
3 Deliver working software frequently, from a couple of weeks to a
couple of months, with a preference of the shorter time scale
Continuous refactoring, integration and testing resulting in small
releases
4 Business people and developers must work together daily throughout
the project

12 Principles of Agile Processes (2)
5 Build projects around motivated individuals; give them the
environment and support they need, and trust them to get the job
done
6 The most efficient and effective method of conveying information to
and within a development team is face-to-face communication
7 Working software is the primary measure of progress
8 Agile processes promote sustainable development; sponsors,
developers & users should be able to maintain a constant pace
indefinitely

12 Principles of Agile Processes (3)
9 Continuous attention to technical excellence and good design
enhances agility
10 Simplicity - the art of maximizing the amount of work not done - is
essential
11 The best requirements, architectures and designs emerge from
self-organizing teams
12 At regular intervals, the team reﬂects on how to become more
eﬀective, then tunes and adjusts its behavior accordingly

RUP versus Agile Processes

The Architecting Process Conclusions
Driving Forces

Architecture, Architect, Architecting

Important Process Heuristics
First things first ⇒ What is architectural significant and risky?
Do the risky parts first ⇒ You can’t do it all!
⇒ They might doom your project!
- If resources are severely constrained, dependability and resource
management are the hardest parts
- If user acceptance is critical, make a prototype early
Simplify, simplify, simplify, but don’t oversimplify

Be Considerate
Before each step, ask yourself
Is it essential?
Does it support the key-drivers and requirements?
Is it architectural significant?
What are the risks?
Am I following the most effective way (method)?
After each step reflect on the way things were going
Learning by doing

Pointers
3 milestones can anchor the early project phases
The architecture establishes the most important milestone and is the
basis for all subsequent activities
Architecting is much more than a technical activity
The proﬁle of architects needs to be extended from technology- to
stakeholder-centered
Communication with the stakeholders and stakeholder agreement
are(is) essential

Summary
The principles of agile processes can be used to enhance RUP
Process principles, criteria, patterns and antipatterns help to make
the architecting process tangible
Architecting is an ongoing activity
Deviations during the implementation and changes can easily
undermine the advantages of a good architecture
An architecture must be maintained

References
1 Building J2EE Applications with the RUP (Addison Wesley, 2002)
2 Software Engineering by Ian Sommerville, 9th Edition

Sa.architecting process

Recommended

Recommended

More Related Content

Similar to Sa.architecting process

Similar to Sa.architecting process (20)

Sa.architecting process