tutorial: quality assessment of system architectures and ...€¦ · •local within individual...
TRANSCRIPT
Sponsored by the U.S. Department of Defense© 2006 by Carnegie Mellon University
Version 0.1 QUASAR Method. - page 1
Pittsburgh, PA 15213-3890
QUality Assessment ofSystem ARchitectures(QUASAR)Donald FiresmithAcquisition Support Program (ASP)
© 2006 by Carnegie Mellon University Version 0.2 QUASAR Method. - page 2
Topics
What is System Architecture?
Why is System Architecture Critical?
Why Assess the System Architecture?
QUASAR System Architecture Assessment Method:• Philosophy• Quality Cases• QUASAR Process
© 2006 by Carnegie Mellon University Version 0.2 QUASAR Method. - page 3
What is a System Architecture?
Traditional Definition:the fundamental structure of a system in terms of itsmajor components, their relationships to each other andthe system’s environment, and the principles governingthe creation and evolution of the structure
More General Definition:the most important, pervasive, top-level, strategicinventions, decisions, and their associated rationalesabout the system including its overall structure (i.e.,essential architectural elements, their relationships, andtheir associated blackbox characteristics and behavior)
© 2006 by Carnegie Mellon University Version 0.2 QUASAR Method. - page 4
Architecture vs. DesignArchitecture Decisions:• Pervasive across System Components• Strategic Decisions and Inventions• Higher-Levels of System• Huge Impact on Quality, Cost, and Schedule• Drives Design, Highest-Level Integration, and Integration
Testing• Driven by Requirements and Higher-Level Architecture• Mirrors Top-Level Organization of Development Team
Design Decisions:• Local within Individual System Components• Tactical Decisions and Inventions• Lower-Levels of System• Smaller Impact on Quality, Cost, and Schedule• Drives Implementation, Lowest-Level Integration, and Unit
Test• Driven by Requirements, Architecture, and Higher-Level
Design
© 2006 by Carnegie Mellon University Version 0.2 QUASAR Method. - page 5
Why is Architecture Critical?
Architecture Defines:• Key System Components• How Key Components Interact
Architecture Affects:• Design Decisions• Implementation Decisions• Integration Decisions• Testing Decisions
Architectural Decisions Drive:• Ultimate System Quality• Development Costs• Development Schedule• Sustainment Costs• Maintenance and Upgradeability
© 2006 by Carnegie Mellon University Version 0.2 QUASAR Method. - page 6
Why is Architectures Critical?2
The quality of the architecture drives the quality of thesystem:• Availability• Interoperability• Modifiability• Performance• Reliability• Robustness (Error, Failure, and Fault Tolerance)• Safety• Security• Scalability• Stability• Testability• …
© 2006 by Carnegie Mellon University Version 0.2 QUASAR Method. - page 7
Why Assess the Architecture?
Determine System Architecture:• Quality• Maturity and Completeness• Integrity and Consistency• Usability
Determine Compliance:• Contract Compliance• Requirements Compliance
Early Identification of System Architecture Defects:• Fix Defects Early• Decrease Costs• Decrease Schedule
© 2006 by Carnegie Mellon University Version 0.2 QUASAR Method. - page 8
Why Assess the Architecture?2
Manage Risks:• System Architecture Risks• System Risks
Provide Acquirer Oversight into System Architecture
Develop Consensus:• Among Developers• Between Acquirer and Developer Organization
Ensure Specification of Quality Requirements
Help Architects Succeed
Help Program Succeed
© 2006 by Carnegie Mellon University Version 0.2 QUASAR Method. - page 9
How to Assess the Architecture?Assessment PhilosophyQuality Cases as FoundationQUASAR Process:• Phases
- System Architecture Assessment Initiation- Subsystem Requirements Review- Subsystem Architecture Assessment- System Architecture Assessment Summary
© 2006 by Carnegie Mellon University Version 0.2 QUASAR Method. - page 10
Assessment PhilosophyQuality Requirements Drive the System Architecture.Architects should Make Case to Assessors:• Architects Know Quality Requirement Drivers• Architects Know What they Did and Why• Architects Know Where Documented
Safety Cases can Generalize into Quality Cases(a.k.a., assurance cases) consisting of:• Claims: Architecture Supports Quality Requirements• Arguments: Architects’ Architectural Decisions and
Rationales• Evidence: Architects’ Documentation and Witnessed
Demonstrations
© 2006 by Carnegie Mellon University Version 0.2 QUASAR Method. - page 11
Assessment Philosophy2
Arguments must be Clear and Compelling.Evidence must Be Credible.Architects’ Responsibilities:• Prepare Quality Cases• Provide Early Presentation Materials to Assessors• Present Quality Cases (Make Case to Assessors)• Answer Assessors’ Questions
Assessor Responsibilities:• Prepare for Assessments• Probe Quality Cases• Determine and Report Assessment Results
© 2006 by Carnegie Mellon University Version 0.2 QUASAR Method. - page 12
Quality Cases – Quality Model
Quality of a system (and system architecture) is defined interms of a quality model:
Quality Measure(Measurement Scale)
Quality Subfactor
is measured using a
definesa type of the quality of the
Quality Factor
Quality Model
System
defines the meaning of quality for the
defines a part of a type of the quality of the
1..* 1..* 1..*
1..*
0..*
1..*
1
© 2006 by Carnegie Mellon University Version 0.2 QUASAR Method. - page 13
Quality Cases – Quality Factors
Quality Factor
Development-OrientedQuality Factor
Usage-OrientedQuality Factor
Safety
Security
Survivability
Dependability
Defensibility Soundness
Correctness
Operational Availability
Predictability
Reliability
Robustness
ConfigurabilityCapacity Efficiency Interoperability
Stability
Quality Subfactor
Quality Model
Quality Measure(Measurement Scale)
is measured using a
Performance Utility
© 2006 by Carnegie Mellon University Version 0.2 QUASAR Method. - page 14
Quality Cases – Quality Subfactors
Safety SubfactorSafety
Safety Problem Type
Safety Solution Type
Accident & Safety Incident
Hazard
Safety Risk
Harm
Prevention
Detection
Reaction
Adaptation
Internal Vulnerability
Nonmalicious Agent
© 2006 by Carnegie Mellon University Version 0.2 QUASAR Method. - page 15
Quality Cases - Components
• ClaimsTheir architecture adequately supports its derived andallocated quality goals and requirements
• Clear and compelling Arguments• Architecture decisions• Associated rationales
• Supporting Evidence• Official program documentation• Witnessed demonstrations
Simplified version of safety case from safety community
© 2006 by Carnegie Mellon University Version 0.2 QUASAR Method. - page 16
Quality Cases - Relationships
Quality Case
Claim Argument Evidencejustifies belief in supports
makes the case for the quality of aSystem
Subsystem
Quality Factor
Quality Subfactor
is specific to a
defines a type of quality of a
defines a part of a type of quality of a
© 2006 by Carnegie Mellon University Version 0.2 QUASAR Method. - page 17
Architecture Quality Cases
Quality Case
Claim Argument Evidencejustifies belief in supports
ArchitectureQuality Case
makes the case for the quality of aSystem
Subsystem
Architecture
has an
makes the case for the quality of an
ArchitecturalArgument
ArchitecturalEvidence
supportsArchitecturalClaim
justifies belief in
© 2006 by Carnegie Mellon University Version 0.2 QUASAR Method. - page 18
Architecture Quality Case2ArchitectureQuality Case
Architecture Claim
Architecture Argument
Architecture Evidence
justifies belief in supports
makes architects’ case for the quality of an
Architecture
QualityGoal
Quality-RelatedRequirement
claims the architecture adequately helps the system achieve its
QualityFactorGoal
QualitySubfactor
Goal
Architecture Decision
RationalejustifiesQuality Goal
Claim
Quality Requirement
Claim
claims the architecture adequately helps the
system meet its
ensuresachieving
supports
System
Subsystem
has an
Quality FactorRequirement
Quality SubfactorRequirement
concerns
QualityConstraint
OfficialDocumentation(e.g., Diagrams,
Models, and Documents)
Witnessed Demonstrations(e.g., Scenarios,
Tests, and Simulations)
© 2006 by Carnegie Mellon University Version 0.2 QUASAR Method. - page 19
Interoperability (Quality) Case
Interoperability Case
Interoperability Claim
Interoperability Argument
Interoperability Evidence
justifies belief in supports
Quality Case
© 2006 by Carnegie Mellon University Version 0.2 QUASAR Method. - page 20
Quality Case DiagramQuality Cases contain a large amount of Information.Claims, Arguments, and a large amount of Evidence aretypically text.It is easy to get lost in a large, complex, textual quality case.A quality Case Diagram is a layered UML class diagram thatlabels and summarizes the parts of a single quality case:• Claims:
- Quality Goals- Quality Requirements
• Arguments:- Architectural Decisions- Rationale
• Evidence:- Documentation- Witnessed Demonstrations
© 2006 by Carnegie Mellon University Version 0.2 QUASAR Method. - page 21
Interoperability Quality Case DiagramG o a l :
A r c h i t e c t u r e S u p p o r t s I n t e r o p e r a b i l i t y< < c l a i m > >
G o a l :A r c h i t e c t u r e
S u p p o r t s P h y s i c a l
I n t e r o p e r a b i l i t y< < c l a i m > >
G o a l :A r c h i t e c t u r e
S u p p o r t sS y n t a x
I n t e r o p e r a b i l i t y< < c l a i m > >
A r c h i t e c t u r e D e c i s i o n :L a y e r e d
A r c h i t e c t u r e< < a r g u m e n t > >
G o a l s :A r c h i t e c t u r e
S u p p o r t s P r o t o c o l
I n t e r o p e r a b i l i t y< < c l a i m > >
j u s t i f i e s b e l i e f i n
G o a l :A r c h i t e c t u r e
S u p p o r t s E n e r g y
I n t e r o p e r a b i l i t y< < c l a i m > >
G o a l :A r c h i t e c t u r e
S u p p o r t s S e m a n t i c s
I n t e r o p e r a b i l i t y< < c l a i m > >
A r c h i t e c t u r e D e c i s i o n :M o d u l a r
A r c h i t e c t u r e< < a r g u m e n t > >
A r c h i t e c t u r e D e c i s i o n :
O p e n I n t e r f a c e S t a n d a r d s
< < a r g u m e n t > >
A r c h i t e c t u r e D e c i s i o n :
P r o x i e s a n d W r a p p e r s
< < a r g u m e n t > >
A r c h i t e c t u r e D e c i s i o n :
S e r v i c e O r i e n t e d A r c h i t e c t u r e
< < a r g u m e n t > >
R e q u i r e m e n t s :A r c h i t e c t u r e
S u p p o r t s P h y s i c a l
I n t e r o p e r a b i l i t y< < c l a i m > >
R e q u i r e m e n t s :A r c h i t e c t u r e
S u p p o r t sS y n t a x
I n t e r o p e r a b i l i t y< < c l a i m > >
R e q u i r e m e n t s :A r c h i t e c t u r e
S u p p o r t s P r o t o c o l
I n t e r o p e r a b i l i t y< < c l a i m > >
R e q u i r e m e n t s :A r c h i t e c t u r e
S u p p o r t s E n e r g y
I n t e r o p e r a b i l i t y< < c l a i m > >
R e q u i r e m e n t s :A r c h i t e c t u r e
S u p p o r t s S e m a n t i c s
I n t e r o p e r a b i l i t y< < c l a i m > >
A r c h i t e c t u r e D e c i s i o n :
F l y - B y - W i r e< < a r g u m e n t > >
A r c h i t e c t u r e D e c i s i o n :O n e - W a y
C o n n e c t i o n s< < a r g u m e n t > >
W i r i n g D i a g r a m
< < e v i d e n c e > >
H a r d w a r eS c h e m a t i c s
< < e v i d e n c e > >
C o n t e x t D i a g r a m
< < e v i d e n c e > >
C o n f i g u r a t i o n D i a g r a m
< < e v i d e n c e > >
A l l o c a t i o n D i a g r a m
< < e v i d e n c e > >
N e t w o r k D i a g r a m s
< < e v i d e n c e > >
A c t i v i t y o r C o l l a b o r a t i o n
D i a g r a m s< < e v i d e n c e > >
I n t e r o p e r a b i l i t y W h i t e p a p e r< < e v i d e n c e > >
V e n d o r - S u p p l i e d T e c h n i c a l
D o c u m e n t a t i o n< < e v i d e n c e > >
L a y e r D i a g r a m
< < e v i d e n c e > >
s u p p o r t s
© 2006 by Carnegie Mellon University Version 0.2 QUASAR Method. - page 22
Partial Performance Quality CaseDiagram Goal:
Architecture Supports Performance<<claim>>
Goal:Architecture Limits Jitter<<claim>>
Goal:Architecture
Limits Latency<<claim>>
Architecture Decision:
Real-TimeOperating System
<<argument>>
Goal:Architecture Limits
Response Time<<claim>>
justifies belief in
Goal:Architecture Supports
Schedulability<<claim>>
Goal:Architecture Supports
Throughput<<claim>>
Requirements:Architecture Limits
Response Time<<claim>>
Requirements:Architecture Supports
Schedulability<<claim>>
Requirements:Architecture Supports
Throughput<<claim>>
Requirements:Architecture Limits Jitter<<claim>>
Requirements:Architecture
Limits Latency<<claim>>
Architecture Decision:
Deterministic Scheduling
<<argument>>
Architecture Decision:Layered
Architecture<<argument>>
Architecture Decision:
Redundant Hardware
<<argument>>
Architecture Decision:
Load Balancing<<argument>>
© 2006 by Carnegie Mellon University Version 0.2 QUASAR Method. - page 23
QUASAR Assessment Process
Four Phases:1. System Architecture Assessment Initiation (SAAI)
For each Subsystem to be assessed:2. Subsystem Requirements Review (SRR)3. Subsystem Architecture Assessment (SAA)
4. System Architecture Assessment Summary (SAAS)
Each Phase consists of 3 Tasks:• Preparation• Meeting• Follow-Through
© 2006 by Carnegie Mellon University Version 0.2 QUASAR Method. - page 24
QUASAR Phases
System Architecture Assessment Initiation
Subsystem Requirements
Review
SubsystemArchitectureAssessment
System ArchitectureAssessment Summary
repeat for each subsystem being assessed
done
no
yes
© 2006 by Carnegie Mellon University Version 0.2 QUASAR Method. - page 25
QUASAR Phases and Tasks
A rch.M eeting
Prep.Follow
Through
Subsystem Architecture Assessm ent Phase
R qm ts.M eeting
Prep.Fo llow
Through
Subsystem R equirem ents Review Phase
InitialM eeting
Prep.Follow
Through
System Architecture Assessm ent In itia tion
Phase
FinalM eeting
Prep.Follow
Through
System Architecture Assessm ent Sum m ary
PhaseTim e (not to scale)
Sub
syst
em 1
Arc
hite
ctur
e A
sses
smen
t
Arch.M eeting
Prep.Follow
Through
Subsystem Architecture Assessm ent Phase
R qm ts.M eeting
Prep.Fo llow
Through
Subsystem R equirem ents Review Phase
Sub
syst
em 2
Arc
hite
ctur
e A
sses
smen
t
A rch.M eeting
Prep.Fo llow
Through
Subsystem Architecture Assessm ent Phase
Rqm ts.M eeting
Prep.Follow
Through
Subsystem Requirem ents R eview Phase
Sub
syst
em N
Arc
hite
ctur
e A
sses
smen
t
© 2006 by Carnegie Mellon University Version 0.2 QUASAR Method. - page 26
Quasar Teams
T o p -L e v e l A rc h ite c tu re
T e a m
S y s te mA rc h i te c tu re
S u b s y s te mA rc h ite c tu re s
A rc h ite c tu ra l ly-S ig n if ic a n t
(Q u a lity )R e q u ire m e n ts
Q u a lityC a s e sS u b s y s te m
A rc h ite c tu re T e a m s
A s s e s s m e n t T e a m (s )
R e q u ire m e n tsT e a m (s )
p ro d u c e th e
A rc h ite c tu re
d r iv e th e
p ro d u c e s th e
p ro d u c e th e
a s s e s s th eq u a lity o f th e
e v a lu a te th ea rc h ite c ts ’
m a k e th e ir
m a k e th e ir
le a d th e
© 2006 by Carnegie Mellon University Version 0.2 QUASAR Method. - page 27
System Architecture AssessmentInitiation (SAAI) Phase
System Architecture Assessment Initiation
Subsystem Requirements
Review
SubsystemArchitectureAssessment
System ArchitectureAssessment Summary
repeat for each subsystem being assessed
done
no
yes
© 2006 by Carnegie Mellon University Version 0.2 QUASAR Method. - page 28
SAAI Topics
SAAI Phase Objectives
SAAI Phase Principles
SAAI Phase Context
SAAI Phase Overview• SAAI Preparation Task• SAAI Meeting Task• SAAI Follow-Through Task
SAAI Roles and Responsibilities
Discussion
© 2006 by Carnegie Mellon University Version 0.2 QUASAR Method. - page 29
SAAI Phase Objectives
Prepare the teams
Develop Consensus:• Scope the Assessments• Schedule the Assessments• Tailor the Assessment Process and Training
Materials• Capture Lessons Learned
Produce and Publish Meeting Outbrief and Minutes
Manage Action Items
© 2006 by Carnegie Mellon University Version 0.2 QUASAR Method. - page 30
SAAI Phase Principles
Need to Develop Consensus between Assessors andAssesses
Need to Tailor Process to meet specific Needs of theOverall Assessment
Scope of Assessment should match Project Needs andResources
Subsystem Assessments must be scheduled to ensurerequired Resources
© 2006 by Carnegie Mellon University Version 0.2 QUASAR Method. - page 31
SAAI Phase Context
A rch.M eeting
Prep.Follow
Through
Subsystem Architecture Assessm ent Phase
R qm ts.M eeting
Prep.Fo llow
Through
Subsystem Requirem ents Review Phase
InitialM eeting
Prep.Follow
Through
System Architecture Assessm ent Initiation
Phase
FinalM eeting
Prep.Follow
Through
System Architecture Assessm ent Sum m ary
PhaseTim e (not to scale)
Sub
syst
em 1
Arc
hite
ctur
e A
sses
smen
t
Arch.M eeting
Prep.Follow
Through
Subsystem Architecture Assessm ent Phase
R qm ts.M eeting
Prep.Fo llow
Through
Subsystem Requirem ents Review Phase
Sub
syst
em 2
Arc
hite
ctur
e A
sses
smen
t
A rch.M eeting
Prep.Fo llow
Through
Subsystem Architecture Assessm ent Phase
Rqm ts.M eeting
Prep.Follow
Through
Subsystem Requirem ents Review Phase
Sub
syst
em N
Arc
hite
ctur
e A
sses
smen
t
© 2006 by Carnegie Mellon University Version 0.2 QUASAR Method. - page 32
SAAI PhaseOverview
In i t ia l K ic k - o f f M e e t in g
N o te s
S y s te mA rc h ite c tu re A s s e s s m e n t In it ia t io n
P h a s e
P re p a ra t io nT a s k
M e e t in gT a s k
A rc h ite c tu re A s s e s s m e n t
S c h e d u le
A rc h ite c tu reA s s e s s m e n t
A c t io n I te m L is t
In it ia l K ic k -o f f M e e t in g A g e n d a
A rc h ite c tu re A s s e s s m e n t
P ro c e d u re
A rc h ite c tu re A s s e s s m e n t
T ra in in g M a te r ia ls
In i t ia l K ic k -o f f M e e t in gM in u te s
F o llo w -T h ro u g hT a s k
A s s e s s m e n t T e a m
d is c u s s io n s
T o p - L e v e l R e q u ire m e n ts T e a m
d is c u s s io n s
S u b s y s te m R e q u ire m e n ts T e a m s
T o p - L e v e l A rc h ite c tu re T e a m
T o p -L e v e l D e v e lo p m e n t T e a m
d is c u s s io n s d is c u s s io n s
S u b s y s te m A rc h ite c tu re T e a m s
© 2006 by Carnegie Mellon University Version 0.2 QUASAR Method. - page 33
SAAI Preparation TaskSteps:
• Staff Assessment Team
• Train Assessment Team
• Assessment Team Identifies theTop-Level Development Team(Top-Level Requirements Engineers & Architects)
• Assessment Team Trains Top-Level DevelopmentTeam
• Teams Collaborate to Organize Meeting(attendees, time, location, agenda)
© 2006 by Carnegie Mellon University Version 0.2 QUASAR Method. - page 34
SAAI Meeting TaskSteps:
• Teams Collaborate to Determine Assessment Scope:
- Architecturally Significant Requirements
- Subsystems
- Assessment Resources
• Teams Collaborate to Develop Initial AssessmentSchedule
• Teams Collaborate to Tailor Assessment Process
• Assessment Team Manages Action Items
© 2006 by Carnegie Mellon University Version 0.2 QUASAR Method. - page 35
SAAI Follow-Through TaskSteps:• Assessment Team develops and presents Meeting
Outbrief• Assessment Team develops, reviews, and distributes
Meeting Minutes• Assessment Team tailors and distributes:
- Assessment Procedure- Assessment Training Material
• Assessment Team distributes Assessment Schedule• Teams obtain Needed Resources• Assessment Team captures Lessons Learned• Assessment Team Manages Action Items
© 2006 by Carnegie Mellon University Version 0.2 QUASAR Method. - page 36
SAAI Roles and Responsibilities
The system architecture assessment initiation phase isperformed by the following teams:• Assessment Team• Top-Level Development Team:
- Top-Level Requirements Team with input fromSubsystem Requirements Teams
- Top-Level Architecture Team with input fromSubsystem Requirements Teams
© 2006 by Carnegie Mellon University Version 0.2 QUASAR Method. - page 37
Assessment Team Membership
Assessment Team Leader
Assessors
Meeting Facilitator
Subsystem Liaison
Subject Matter Experts
Scribe
© 2006 by Carnegie Mellon University Version 0.2 QUASAR Method. - page 38
Assessment Team Responsibilities
Provide Architecture Assessment Training Materials
Provide Architecture Assessment Procedure
Collaborate to Tailor Architecture Assessment Procedure
Collaborate to provide Initial Kick-Off Meeting Agenda
Take Initial Kick-Off Meeting Notes
Collaborate to Develop Assessment Schedule
Produce Architecture Assessment Action Item List
Produce Outbrief and Meeting Minutes
© 2006 by Carnegie Mellon University Version 0.2 QUASAR Method. - page 39
Development Team Membership
Top-Level Requirements Team:
• Lead Requirements Engineer
• System Requirements Engineers
• Subsystem Requirements Engineers
Top-Level Architecture Team:
• Lead System Architect
• System Architects
• Subsystem Architects
© 2006 by Carnegie Mellon University Version 0.2 QUASAR Method. - page 40
Development Team Responsibilities
Read Architecture Assessment Training Materials
Read Architecture Assessment Procedure
Collaborate to Tailor Architecture Assessment Procedure
Collaborate to provide Initial Kick-Off Meeting Agenda
Take Initial Kick-Off Meeting Notes
Collaborate to Develop Assessment Schedule
© 2006 by Carnegie Mellon University Version 0.2 QUASAR Method. - page 41
SAAI DiscussionWhat is the main objectives of the system architectureassessment initiation phase?What are the three tasks comprising the SAAI phase?What teams are involved?What are the memberships and responsibilities of theseteams?
© 2006 by Carnegie Mellon University Version 0.2 QUASAR Method. - page 42
Subsystem Requirements Review (SRR)Phase
System Architecture Assessment Initiation
Subsystem Requirements
Review
SubsystemArchitectureAssessment
System ArchitectureAssessment Summary
repeat for each subsystem being assessed
done
no
yes
© 2006 by Carnegie Mellon University Version 0.2 QUASAR Method. - page 43
SRR Topics
SRR Questions for the Attendees
SRR Phase Objectives
SRR Phase Principles
SRR Phase Challenges
SRR Phase Context
SRR Phase Overview• SRR Preparation Task• SRR Meeting Task• SRR Follow-Through Task
SRR Roles and Responsibilities
Discussion
© 2006 by Carnegie Mellon University Version 0.2 QUASAR Method. - page 44
SRR Questions for the Attendees1
As a requirements engineer, what are your biggestproblems with respect to engineering (e.g., identifying,deriving, analyzing, specifying, and managing) system andsubsystem requirements that significantly impact thearchitecture?
As a system architect, what are your biggest problemswith respect to the system requirements that significantlyimpact the architecture?
As a subsystem architect, what are your biggest problemswith respect to the derived architecturally significantrequirements that have been allocated to your subsystem?
© 2006 by Carnegie Mellon University Version 0.2 QUASAR Method. - page 45
Key Questions for the Attendees2
How can you know the architecture is ‘goodenough’ if the requirements do not specifyexactly how good it has to be?
• How else can the architects:- Make engineering trade-offs among the different quality
factors?- Know when the architecture is done?
• How can the architecture assessors assess the quality of thearchitecture without having requirements against which tomake the assessment?
• How can testers determine success or failure withoutmeasurable test completion criteria?
• How can managers know the quality and status of thearchitecture without measurable indicators?
© 2006 by Carnegie Mellon University Version 0.2 QUASAR Method. - page 46
SRR Phase Objectives
Ensure that the:• Architecturally significant requirements are properly
engineered in time to support the engineering of thesubsystem architecture.
• Subsystem architects know how to prepare for andsupport the coming subsystem architecture qualityassessment.
© 2006 by Carnegie Mellon University Version 0.2 QUASAR Method. - page 47
Architecturally Significant Requirements
Architecturally Significant RequirementAny requirement that has a significant impact on thesystem architecture
Quality requirements are typically the most importantarchitecturally significant requirements.
DefinitionAny requirement that specifies a minimum level ofquality
© 2006 by Carnegie Mellon University Version 0.2 QUASAR Method. - page 48
Quality Requirements
FormatThe system shall do X with threshold Y undercondition(s) Z.
Bad Example(s)The system shall be highly reliable, robust, safe,secure, stable, etc.
Good Example (Stability)The system shall ensure that the mean time betweenthe failure of non-critical functionality* causing thefailure of critical functionality* is least 5,000 hours ofcontinuous operation under normal operatingconditions*.
* Must be properly defined in the project glossary.
© 2006 by Carnegie Mellon University Version 0.2 QUASAR Method. - page 49
SRR Phase Principles1
Not all requirements are architecturally significant.
Quality requirements should be major drivers of thesystem architecture.
Quality requirements should specify a minimum requiredamount of some type of quality.
Quality requirements should be:• Unambiguous• Feasible• Complete• Consistent• Mandatory• Verifiable• Validatable
© 2006 by Carnegie Mellon University Version 0.2 QUASAR Method. - page 50
SRR Phase Principles2
Quality requirements should be organized according to aquality model that defines quality factors (a.k.a., attributes,“ilities’) and their quality subfactors:
• Availability• Interoperability• Performance
- Jitter, Response Time, Schedulability, andThroughput
• Portability• Reliability• Safety• Security• Usability
© 2006 by Carnegie Mellon University Version 0.2 QUASAR Method. - page 51
SRR Phase Principles3
Different quality factors are important for differentsubsystems.
• Performance is paramount for some subsystems.• Security is more important for other subsystems.
Engineering architecturally significant requirements is theresponsibility of the requirements team, not thearchitecture team and not the assessment team.
• Architects and assessors are not qualified to engineerquality requirements.
• Many stakeholders need quality requirements.• Architecture assessment time is too late to engineer
quality requirements.
© 2006 by Carnegie Mellon University Version 0.2 QUASAR Method. - page 52
SRR Phase Challenges1
Architects are rarely given/allocated a complete set ofarchitecturally significant requirements.
These architecturally significant requirements rarelyinclude quality requirements for all of the relevant qualityfactors and subfactors.
© 2006 by Carnegie Mellon University Version 0.2 QUASAR Method. - page 53
SRR Phase Challenges2
The quality of the derived and allocated architecturallysignificant requirements are typically poor:
• Requirements are often ambiguous.- “The system shall be safe and secure.”
• Requirements rarely specify thresholds on relevantquality measurement scales.- “The system shall have adequate availability.”
• Requirements are often mutually inconsistent.- Security vs. usability, performance vs. reliability.
• Many requirements are infeasible (or at leastimpractical) if taken literally.- “The system shall have 99.99999 reliability.”
© 2006 by Carnegie Mellon University Version 0.2 QUASAR Method. - page 54
SRR Phase Challenges3
Requirements are often unstable.
Specialty engineering requirements (e.g., reliability, safety,security) are often documented separately from thefunctional requirements.
The architecturally significant requirements are oftenimproperly prioritized for implementation.
The subsystem architects often do not understand how toprepare for an architecture assessment.
• Too busy• Not trained• No standards exist• Bias against assessments/audits
© 2006 by Carnegie Mellon University Version 0.2 QUASAR Method. - page 55
SRR Phase Challenges4
The subsystem architects do not understand how to givethe assessment team the information they need to assessthe architecture:
• How good must the architecture be to sufficientlysupports its derived and allocated qualityrequirements (i.e., to ‘pass’ the assessment)?
• What architectural decisions did the architects make tosupport the quality goals and requirements?
• What were the rationales for these decisions?• What is the official documentation of actual
architectural decisions?- Not plans and procedures- Official program documentation- Not hastily produced PowerPoint slides
© 2006 by Carnegie Mellon University Version 0.2 QUASAR Method. - page 56
SRR Phase Context
A rch.M eeting
Prep.Follow
Through
Subsystem Architecture Assessm ent Phase
R qm ts.M eeting
Prep.Fo llow
Through
Subsystem Requirem ents Review Phase
InitialM eeting
Prep.Follow
Through
System Architecture Assessm ent Initiation
Phase
FinalM eeting
Prep.Follow
Through
System Architecture Assessm ent Sum m ary
PhaseTim e (not to scale)
Sub
syst
em 1
Arc
hite
ctur
e A
sses
smen
t
Arch.M eeting
Prep.Follow
Through
Subsystem Architecture Assessm ent Phase
R qm ts.M eeting
Prep.Fo llow
Through
Subsystem Requirem ents Review Phase
Sub
syst
em 2
Arc
hite
ctur
e A
sses
smen
t
A rch.M eeting
Prep.Fo llow
Through
Subsystem Architecture Assessm ent Phase
Rqm ts.M eeting
Prep.Follow
Through
Subsystem Requirem ents Review Phase
Sub
syst
em N
Arc
hite
ctur
e A
sses
smen
t
© 2006 by Carnegie Mellon University Version 0.2 QUASAR Method. - page 57
P re p a ra t io nT a s k
M e e t in gT a s k
S u b s y s te mR e q u ire m e n ts
R e v ie w M e e t in gO u tb r ie f
U p d a te dA rc h ite c tu reA s s e s s m e n tA c t io n I te m
L is t
A rc h ite c tu re A s s e s s m e n t
P ro c e d u re
A rc h ite c tu re A s s e s s m e n t
T r a in in g M a te r ia ls
S u b s y s te mR e q u ire m e n ts
R e v ie w M e e t in g M in u te s
F o llo w -T h ro u g hT a s k
S u b s y s te mR e q u ire m e n ts R e v ie w
P h a s e
S u b s y s te mR e q u ire m e n ts
R e v ie w M e e t in gA s s e s s o r N o te s
S u b s y s te mR e q u ire m e n ts
R e v ie wM e e t in gA g e n d a
S u b s y s te mR e q u ire m e n ts
R e v ie w C h e c k l is t
S u b s y s te mR e q u ire m e n ts
R e v ie w P re p a ra to r y
M a te r ia ls
S u b s y s te mR e q u ire m e n ts
R e v ie w P re s e n ta t io n
M a te r ia ls
A s s e s s m e n t T e a m
S u b s y s te m A rc h ite c tu re T e a m
S u b s y s te m R e q u ire m e n ts T e a m
S u b s y s te mD e v e lo p m e n t T e a m
SRR PhaseOverview
© 2006 by Carnegie Mellon University Version 0.2 QUASAR Method. - page 58
SRR Preparation Task
Steps:
• Subsystem Requirements Team provides access tothe architecturally significant subsystem requirementsas well as a summary of these requirements
• Subsystem Architecture Team provides sample ofplanned Quality Cases
• Subsystem Assessment Team reviews thisinformation prior to the meeting
© 2006 by Carnegie Mellon University Version 0.2 QUASAR Method. - page 59
SRR Meeting Task
Steps:
• Subsystem Requirements Team presents Summaryof the architecturally significant subsystemrequirements (organized by quality factor and qualitysubfactors)
• Subsystem Assessment Team recommendsImprovements
• Subsystem Architecture Team presents sample ofplanned Quality Cases
• Subsystem Assessment Team recommendsImprovements
• Assessment Team Manages Action Items
© 2006 by Carnegie Mellon University Version 0.2 QUASAR Method. - page 60
SRR Follow-Through Task
Steps:
• Subsystem Assessment Team presents Outbrief
• Subsystem Assessment Team develops andpublishes Meeting Minutes containingrecommendations for improving:
• Architecturally significant subsystem requirements
• Quality Cases
• Assessment Team tailors and distributes updatedAssessment Procedure and Assessment TrainingMaterial (for future requirements reviews)
• Assessment Team captures Lessons Learned
• Assessment Team Manages Action Items
© 2006 by Carnegie Mellon University Version 0.2 QUASAR Method. - page 61
SRR Roles and Responsibilities
The subsystem requirements review phase is performedby the following three teams:
• Subsystem Requirements Team• Subsystem Architecture Team• Subsystem Assessment Team
© 2006 by Carnegie Mellon University Version 0.2 QUASAR Method. - page 62
Subsystem Requirement Team
Responsibilities:• Work with specialty engineering teams to engineer the
architecturally significant subsystem requirements• Provide these requirements to the subsystem
architecture team in time to drive the subsystemarchitecture
• Provide the subsystem assessment team with accessto these requirements sufficiently prior to the meeting
• Summarize these requirements at the requirementsreview meeting
• Answer questions from the assessment team (andarchitecture team)
© 2006 by Carnegie Mellon University Version 0.2 QUASAR Method. - page 63
Subsystem Architecture TeamResponsibilities:• Develop a proposed representative sample of the
architectural information to be presented during thecoming subsystem architecture assessment meeting:- Architectural decisions and rationale- Supporting evidence
• Present this information to the subsystem assessmentteam
• Ask questions (if necessary) of the:- Subsystem requirements team (regarding
architecturally significant requirements)- Subsystem assessment team (regarding the
assessment process and adequacy of proposedsample architectural decisions, rationale, andevidence
© 2006 by Carnegie Mellon University Version 0.2 QUASAR Method. - page 64
Subsystem Assessment Team1
Responsibilities:• Review supplied information prior to the requirements
review meeting• Ensure that the architecturally significant requirements
are adequately engineered to support the subsystemarchitecture assessment.
• Ensure that the proposed architectural information towill be adequate to support the coming subsystemarchitecture assessment meeting
• Answer questions from and provide advice to the:- Requirements team regarding the architecturally
significant requirements- Architecture team regarding what will be expected of
them during the coming subsystem architectureassessment meeting
© 2006 by Carnegie Mellon University Version 0.2 QUASAR Method. - page 65
Subsystem Assessment Team2
Responsibilities:• Must include members having expertise in:
- Requirements engineering and quality requirements- The system architecture quality assessment method
(with all members having been trained in themethod)
• Should include members having experience in thesubsystem application domain(s) such as avionics,sensors, or weapons
© 2006 by Carnegie Mellon University Version 0.2 QUASAR Method. - page 66
SRR Discussion Questions
What is the two main objectives of the subsystemrequirements review?How often should subsystem requirements reviews beperformed?When should subsystem requirements reviews beperformed?What are the three tasks comprising the subsystemrequirements review?What are the objectives of these three tasks?What teams are involved?What are the responsibilities of these teams?
© 2006 by Carnegie Mellon University Version 0.2 QUASAR Method. - page 67
Subsystem Architecture Assessment(SAA)
System Architecture Assessment Initiation
Subsystem Requirements
Review
SubsystemArchitectureAssessment
System ArchitectureAssessment Summary
repeat for each subsystem being assessed
done
no
yes
© 2006 by Carnegie Mellon University Version 0.2 QUASAR Method. - page 68
SAA Topics
SAA Questions for the Attendees
SAA Phase Objectives
SAA Phase Principles
SAA Phase Challenges
SAA Phase Context
SAA Phase Overview:• SAA Preparation Task• SAA Meeting Task• SAA Follow-Through Task
SAA Roles and Responsibilities
Discussion
© 2006 by Carnegie Mellon University Version 0.2 QUASAR Method. - page 69
SAA Questions for the Attendees1
As a subsystem architect, what are your biggest problemswith respect to:
• Engineering the subsystem architecture?• Ensuring that the subsystem architecture adequately
meets its architecturally significant requirements?• Internally reviewing/evaluating the quality of the
subsystem architecture?• Supporting independent assessments of the quality of
your subsystem architecture?
As an independent assessor (e.g., PO of prime contractor,prime contractor of subcontractor), what are your biggestproblems with respect to independently assessing thequality of an acquired subsystem’s architecture?
© 2006 by Carnegie Mellon University Version 0.2 QUASAR Method. - page 70
SAA Questions for the Attendees2
Is the quality of your architectures being independentlyassessed?How are your architectures being assessed?Who is assessing your architectures?What do you see as the biggest problems with respect tohow your architectures are being assessed?
• Are your assessors using an effective and efficientprocess for assessing your architectures?
• Do you know what is expected of you during thesystem architecture assessments?
• Do you develop adequate documentation as a naturalpart of the architecture process?
• Is the architecture documentation you developadequate to support assessments?
© 2006 by Carnegie Mellon University Version 0.2 QUASAR Method. - page 71
SAA Objectives
Assess Quality of Subsystem Architecture in terms of:
• Architectures support for its derived and allocatedarchitecturally significant requirements
• Architectural Quality Cases
© 2006 by Carnegie Mellon University Version 0.2 QUASAR Method. - page 72
SAA Principles1
Quality architecture assessments should be organizedaccording to a quality model that defines quality factors(a.k.a., attributes, “ilities’) and their quality subfactors:
• Availability• Interoperability• Performance
- Jitter, Response Time, Schedulability, andThroughput
• Portability• Reliability• Safety• Security• Usability
© 2006 by Carnegie Mellon University Version 0.2 QUASAR Method. - page 73
SAA Principles2
The subsystem architects should know:• What quality goals and requirements drove the
development of their architectures.• What architectural decisions they made.• Why they made these decisions.• Where these decisions are documented.
Because the subsystem architects should already havedocumented this information as a natural part of theirarchitecting method, little new documentation should benecessary for the subsystem architects to make theircases to the subsystem assessment team.The subsystem architects are responsible for making theirown cases that their architectures adequately support theirderived and allocated quality requirements.
© 2006 by Carnegie Mellon University Version 0.2 QUASAR Method. - page 74
SAA Phase ChallengesArchitects may not have developed quality cases as anatural part of their architecting process:• Architectural documentation typically not organized by
quality factors.• Quality case evidence is often buried in and scattered
throughout massive amounts of architecturaldocumentation.
• Architectural models (e.g., UML) often do not addresssupport for quality requirements.
Architecture assessments may not be:• Mandated by contract or development process• Scheduled and funded
Managers feel schedule pressures do not allow time forassessment.
© 2006 by Carnegie Mellon University Version 0.2 QUASAR Method. - page 75
SAA Context
A rch.M eeting
Prep.Follow
Through
Subsystem Architecture Assessm ent Phase
R qm ts.M eeting
Prep.Fo llow
Through
Subsystem Requirem ents Review Phase
InitialM eeting
Prep.Follow
Through
System Architecture Assessm ent Initiation
Phase
FinalM eeting
Prep.Follow
Through
System Architecture Assessm ent Sum m ary
PhaseTim e (not to scale)
Sub
syst
em 1
Arc
hite
ctur
e A
sses
smen
t
Arch.M eeting
Prep.Follow
Through
Subsystem Architecture Assessm ent Phase
R qm ts.M eeting
Prep.Fo llow
Through
Subsystem Requirem ents Review Phase
Sub
syst
em 2
Arc
hite
ctur
e A
sses
smen
t
A rch.M eeting
Prep.Fo llow
Through
Subsystem Architecture Assessm ent Phase
Rqm ts.M eeting
Prep.Follow
Through
Subsystem Requirem ents Review Phase
Sub
syst
em N
Arc
hite
ctur
e A
sses
smen
t
© 2006 by Carnegie Mellon University Version 0.2 QUASAR Method. - page 76
SAA PhaseOverview
P repa ra tionT ask
M ee tingT ask
S ub sys te mA rch ite c tu re A sse ssm e n t
M ee tingO u tb rie f
U pd a tedA rch ite c tu reA sse ssm e ntA c tio n Item
L is t
S ub s ys te mA rch ite c tu re A sse ssm e n t
R e p o rt
F o llow -T h roughT ask
S ubsys temA rch itec tu re A ssessm en t
P hase
S u b sy s te mA rch ite c tu re A sse ssm e n t
M e e tin gA ss es so r N o te s
S u bsys temA rch itec tu re A sse ssm e n t
M e etin gA ge n d a
S u b sy s te mA rch ite c tu re A ssessm e nt
C h e ck lis t
S u b sy s te mA rch ite c tu re A ssessm e nt P rep a ra to ry
M a te ria ls
S u b sy s te mA rch ite c tu re A ssessm e nt P rese n ta tio n
M a te ria ls
A sse ssm en t T e a m
T o p -L e ve l A rch ite c tu re T ea m
A rch ite c tu reT ea m
S ub sys te mA rch ite c tu re
S u pp o rt M a trix
S u b sy s te m A rch ite c tu re T e a m
A rch ite c tu re A ss e ssm e n t
T ra in in g M ate ria ls
A rch ite c tu re A ss es sm e n t P ro ce d u re
© 2006 by Carnegie Mellon University Version 0.2 QUASAR Method. - page 77
SAA Preparation TaskSteps:• Subsystem Assessment Team Provides Assessment
Checklist• Subsystem Architecture Team Gathers (Generates) and
Makes Available Preparatory Materials:• Subsystem Architecture Overview• Updated Quality Requirements• Quality Cases including Arguments and Evidence
• Subsystem Architecture Team Gathers (Generates) andMakes Available Presentation Materials
• Subsystem Assessment Team:• Reads Materials• Generates RFIs and RFAs
• Teams Collaborate to Organize Assessment Meeting(Attendees, Time, Location, Agenda, Invitation)
© 2006 by Carnegie Mellon University Version 0.2 QUASAR Method. - page 78
SAA Meeting Task
Steps:
• Subsystem Architecture Team:• Introduces Subsystem Architecture
(purpose, location, context, functions)• Reviews Architecturally-Significant Requirements• Introduces Subsystem Architecture
(components, relationships, major decisions, trade-offs)• Present Quality Cases
(claims, arguments, and evidence)
• Subsystem Assessment Team:• Probes Architecture (quality case by quality case)• Manages Action Items
© 2006 by Carnegie Mellon University Version 0.2 QUASAR Method. - page 79
SAA Follow-Through Task
Steps:
• Subsystem Assessment Team:• Develops Consensus• Produces, Reviews, and Presents Meeting Outbrief• Produces, Reviews, and Presents Subsystem
Assessment Report• Manages Action Items• Captures Lessons Learned• Updates Assessment Method and Training
Materials
© 2006 by Carnegie Mellon University Version 0.2 QUASAR Method. - page 80
SAA Roles and Responsibilities
The Subsystem Architecture Assessment Phase isperformed by the following teams:
• Subsystem Architecture Team• Subsystem Assessment Team
© 2006 by Carnegie Mellon University Version 0.2 QUASAR Method. - page 81
Subsystem Architecture Team
Responsibilities:• Develop the architectural information to be presented
during the meeting:- Architectural decisions and rationale- Supporting evidence
• Present this information to the subsystem assessmentteam
• Answer probing questions raised by the subsystemassessment team:
© 2006 by Carnegie Mellon University Version 0.2 QUASAR Method. - page 82
Subsystem Assessment Team
Responsibilities:• Review supplied information prior to the subsystem
architecture assessment meeting• Assess the quality of the subsystem architecture:
- Actively listen to the quality cases presented by thesubsystem architecture team
- Ask probing questions of Architects
© 2006 by Carnegie Mellon University Version 0.2 QUASAR Method. - page 83
SAA Discussion
Should the quality cases be developed as a:
• Natural part of the architecting process?
• Part of the assessment process?
How does the answer to the previous question affect theamount of time needed to prepare for the assessmentmeeting?
Which team has the most work to do during each task?
How should the development of the subsystemassessment report be divided up between members of theassessment team?
© 2006 by Carnegie Mellon University Version 0.2 QUASAR Method. - page 84
System Architecture AssessmentSummary (SAAS)
System Architecture Assessment Initiation
Subsystem Requirements
Review
SubsystemArchitectureAssessment
System ArchitectureAssessment Summary
repeat for each subsystem being assessed
done
no
yes
© 2006 by Carnegie Mellon University Version 0.2 QUASAR Method. - page 85
SAAS Topics
SAAS Questions for the Attendees
SAAS Phase Objectives
SAAS Phase Principles
SAAS Phase Challenges
SAAS Phase Context
SAAS Phase Overview:• SAAS Preparation Task• SAAS Meeting Task• SAAS Follow-Through Task
SAAS Roles and Responsibilities
Discussion
© 2006 by Carnegie Mellon University Version 0.2 QUASAR Method. - page 86
SAAS Questions for the Attendees
How do you summarize the results of subsystemassessments at the system level?
Should the system architecture assessment summaryphase be performed:
• Once at the end?
• On an ongoing rolling-wave basis?
© 2006 by Carnegie Mellon University Version 0.2 QUASAR Method. - page 87
SAAS Objectives
Collect previous Subsystem Architecture AssessmentResults
Create System Architecture Assessment SummarizeResults
Capture Method Lessons Learned
Update Assessment Method and Training Materials
© 2006 by Carnegie Mellon University Version 0.2 QUASAR Method. - page 88
SAAS Principles
All subsystems are not equally important.
All quality factors are not equally important for differentsubsystems.
It is probably better to concentrate on identifyingproblem/risk areas so that they can be fixed than toprovide an overall summary assessment result.
© 2006 by Carnegie Mellon University Version 0.2 QUASAR Method. - page 89
SAAS Phase Challenges
How should subsystem findings be summarized withoutending up comparing apples and oranges?
• Average Subsystem Architecture Quality
• Worst Subsystem Architecture Quality
• Union of Subsystem Architecture Qualities
Executive management may demand simplistic singlenumber summary of system architecture.
© 2006 by Carnegie Mellon University Version 0.2 QUASAR Method. - page 90
SAAS Context
A rch.M eeting
Prep.Follow
Through
Subsystem Architecture Assessm ent Phase
R qm ts.M eeting
Prep.Fo llow
Through
Subsystem Requirem ents Review Phase
InitialM eeting
Prep.Follow
Through
System Architecture Assessm ent Initiation
Phase
FinalM eeting
Prep.Follow
Through
System Architecture Assessm ent Sum m ary
PhaseTim e (not to scale)
Sub
syst
em 1
Arc
hite
ctur
e A
sses
smen
t
Arch.M eeting
Prep.Follow
Through
Subsystem Architecture Assessm ent Phase
R qm ts.M eeting
Prep.Fo llow
Through
Subsystem Requirem ents Review Phase
Sub
syst
em 2
Arc
hite
ctur
e A
sses
smen
t
A rch.M eeting
Prep.Fo llow
Through
Subsystem Architecture Assessm ent Phase
Rqm ts.M eeting
Prep.Follow
Through
Subsystem Requirem ents Review Phase
Sub
syst
em N
Arc
hite
ctur
e A
sses
smen
t
© 2006 by Carnegie Mellon University Version 0.2 QUASAR Method. - page 91
SAAS PhaseOverview
PreparationTask
MeetingTask
Follow-ThroughTask
SystemArchitecture Summary
Phase
SubsystemArchitecture Assessment
MeetingAssessor
Notes
SystemArchitecture Assessment
SummaryMeetingAgenda
System Summary
Subsystem Matrix
System Architecture
Quality Assessment
Summary Report
System Summary Meeting
Presentation Materials
SystemArchitecture
Team
SystemAssessment
Team
UpdatedArchitectureAssessmentAction Item
List
Architecture Assessment
Training Materials
Architecture Assessment Procedure
© 2006 by Carnegie Mellon University Version 0.2 QUASAR Method. - page 92
SAAS Preparation TaskSteps:• System Assessment Team:
• Collects Subsystem Architecture Assessment Results• Summarizes Subsystem Architecture Assessment
Results• Develops Subsystem Architecture Support Matrix
• Identifies Primary Stakeholders• Produces, Reviews, and Distributes:
• System Architecture Quality Assessment SummaryReport
• Preparatory Materials• Meeting Agenda
• Organizes Meeting
© 2006 by Carnegie Mellon University Version 0.2 QUASAR Method. - page 93
SAAS Meeting Task
Steps:
• System Assessment Team:
• Restates Assessment Objectives
• Summarizes Assessment Method
• Summarizes Quality of Subsystem Architectures
• Summarizes Quality of System Architecture
• Solicits Feedback
• Captures Lessons Learned
• System Architecture Team:
• Captures Lessons Learned
© 2006 by Carnegie Mellon University Version 0.2 QUASAR Method. - page 94
SAAS Follow-Through Task
Steps:
• System Assessment Team:
• Updates and Distributes the System ArchitectureAssessment Summary Report
• Manages Action Items
• Updates Assessment Method and TrainingMaterials
• System Architecture Team:
• Updates Architecture Method and TrainingMaterials
© 2006 by Carnegie Mellon University Version 0.2 QUASAR Method. - page 95
SAAS Responsibilities
System Assessment Team:• Develop and Present System-Level Architecture
Assessment Summary Results• Capture Lessons Learned• Update Assessment Method and Training Materials
System Architecture Team:• Validate Assessment Results• Capture Lessons Learned• Update Architecture Method and Training Materials
Management Team:• Manage Architectural Risks
© 2006 by Carnegie Mellon University Version 0.2 QUASAR Method. - page 96
SAAS DiscussionFor a given quality factor, what is the best way tosummarize the quality of the system architecture in termsof the quality of the architecture of the main subsystems?• Average subsystem quality?• Worst subsystem quality?• Keep separate by listing individually?
What is the best way to summarize across all qualityfactors?• Average value?• Worst value?• Keep separate by listing individually?
© 2006 by Carnegie Mellon University Version 0.2 QUASAR Method. - page 97
QUASAR Today and Tomorrow
Today:
• In-use on massive DoD Program
• Handbook published
• Provided as SEI Service
Future Plans:
• More Conference Tutorials
• QUASAR Training Materials and Classes
• QUASAR Articles
• Use and Validation on more Programs
• QUASAR Book
© 2006 by Carnegie Mellon University Version 0.2 QUASAR Method. - page 98
QUASAR Handbook
Intended Audiences:• Acquisition Personnel• Developers (Architects and Requirements Engineers)• Subject Matter Experts (domain, specialty engineering)• Consultants• Trainers
Objectives:• Completely Document the QUASAR method• Enable Readers to start using QUASAR
Description:• Very Complete• Too comprehensive to be good first introduction
© 2006 by Carnegie Mellon University Version 0.2 QUASAR Method. - page 99
Contact Information
For more information, contact:
Donald Firesmith
Acquisition Support Program
Software Engineering Institute