Upload
incosewma
View
218
Download
0
Embed Size (px)
Citation preview
8/9/2019 Presentations from 2009 Dinner Meeting
1/22
Systems Engineering Simulation Modeling Maintenance Analysis Availability Research Repair Testing Training
Introducing ISO/IEC 42010:
Architecture Description
David Emery
DSCI
Copyright 2009, David Emery & D&S Consultants, IncAll rights reserved. Permission granted to INCOSE WMA members
for personal use only, providing the presentation is used intact andthis statement is included
8/9/2019 Presentations from 2009 Dinner Meeting
2/22
Systems Engineering Simulation Mode ling Maintenance Analysis Availability Research Repair Testing Training
-2Copyright 2009, David Emery & D&S Consultants, inc. See title page for copyright info
Agenda
Where did this standard come from?What is in the Standard?
-Current IEEE 1471-2000 / ISO/IEC 42010:2007-Proposed additions IEEE/ISO/IEC 42010:201x
How can it be applied (to the DoDAF)?
How to participateSummary
8/9/2019 Presentations from 2009 Dinner Meeting
3/22
Systems Engineering Simulation Mode ling Maintenance Analysis Availability Research Repair Testing Training
-3Copyright 2009, David Emery & D&S Consultants, inc. See title page for copyright info
History:Where did this standard come from?
1990-1995: multiple books/papers on software architecture (e.g. Perry & Wolf, Kruchten,Shaw), system architecture (e.g. Rechtin & Maier), enterprise architecture (e.g.Zachman)
1995: Formation of IEEE Architecture Working Group to update the IEEE standarddefinition of architecture
1996-1998: Authoring the IEEE 1471 standard 1998-1999: Balloting same 2000: Publication as IEEE Std 1471-2000 2001: Adoption as ANSI standard 2005: ISO SC7 Architecture Working Group formed 2006: ISO agreement to fast-track IEEE 1471 with immediate coordinated update
Scope to align with SC7 ISO/IEC 15288 as well as ISO/IEC 12207, software andsystems
Alignment as part of overall SC7 set of standards and related ISO work (e.g. TC184work on Enterprise Architecture)
2007: Publication of ISO/IEC 42010:2007 (cover page on IEEE 1471-2000) 2007-2009: Draft revision of ISO/IEC 42010/IEEE 1471 2009-2010(?): Balloting same 2010 or 2011(?): Publication of revised ISO/IEC 42010/IEEE 42010
8/9/2019 Presentations from 2009 Dinner Meeting
4/22
Systems Engineering Simulation Mode ling Maintenance Analysis Availability Research Repair Testing Training
-4Copyright 2009, David Emery & D&S Consultants, inc. See title page for copyright info
Whats in the 2000/2007 Standard?
Definitions (1 page)Metamodel/ontology for architecture descriptions
(ADs) (4 pages)
23 Normative requirements for ADs (4 pages)Annexes (including relationship/mapping to RM
ODP) (10 pages)
8/9/2019 Presentations from 2009 Dinner Meeting
5/22
Systems Engineering Simulation Mode ling Maintenance Analysis Availability Research Repair Testing Training
-5Copyright 2009, David Emery & D&S Consultants, inc. See title page for copyright info
Motivation: Why a standard forArchitecture Description?
Architecture is an abstract property of systems/software (I cant define it,but I know it when I see it)
Architecture works best when its written down, so we can review it, analyzeit, and build to it
Most of the papers talk to how to describe an architecture (e.g. Kruchtens4+1 views)
Thus a standard that gathers current practice on descriptions would haveboth a sound basis in practice and provide a concrete description of theconcrete artifact of an architecture
The standard for architecture description should not restrict the process/methodology or intellectual practice of architecting
- Provide constraints on describing the architecture, not on the architecture itself- Akin to standards for house blueprints as opposed to building codes
Focus on ontology for elements of architecture description (means tocompare description approaches, as well as compare descriptions) Minimal set of conformance requirements, provide flexibility for extensions
and adaptations
8/9/2019 Presentations from 2009 Dinner Meeting
6/22
Systems Engineering Simulation Mode ling Maintenance Analysis Availability Research Repair Testing Training
-6Copyright 2009, David Emery & D&S Consultants, inc. See title page for copyright info
The Metamodel
8/9/2019 Presentations from 2009 Dinner Meeting
7/22
Systems Engineering Simulation Mode ling Maintenance Analysis Availability Research Repair Testing Training
-7Copyright 2009, David Emery & D&S Consultants, inc. See title page for copyright info
Definitions*
Architecture: fundamental conception of a system in its environment embodied inelements, their relationships to each other and to the environment, and principles guidingsystem design and evolution
Architecture description: collection of work products used to describe anarchitecture
Stakeholder: individual, team, organization, or classes thereof, having concerns withrespect to a system
Concern: area of interest in a system pertaining to developmental, technological,business, operational, organizational, political, regulatory, social, or other influencesimportant to one or more of its stakeholders
Viewpoint: work product establishing the conventions for the construction, interpretationand use of architecture views and associated architecture models
View: work product representing a system from the perspective of architecture-relatedconcerns
Model: work product from which architecture views are composed* Text from the draft revised standard
8/9/2019 Presentations from 2009 Dinner Meeting
8/22
Systems Engineering Simulation Mode ling Maintenance Analysis Availability Research Repair Testing Training
-8Copyright 2009, David Emery & D&S Consultants, inc. See title page for copyright info
4 Big Ideas from the Standard
0. Architecture /= Architecture Description
1. Architectures exist for systems (including software-only systems) to
satisfy known concerns from stakeholders
- This ensures the architecture, and its description, are relevant-
Stakeholder concerns, often non-functional, drive the architecture2. Architecture Descriptions are inherently multi-view
- No single view addresses all concerns- A view should cover the entire system (with respect to the concerns of interest)
3. Viewpoints (what to describe) are separate from Views (this
description)
- Represents current practices with viewpoint sets such as Kruchtens 4+1- Ensures consistency and repeatability, particularly when evaluating alternative
architectures
8/9/2019 Presentations from 2009 Dinner Meeting
9/22
Systems Engineering Simulation Mode ling Maintenance Analysis Availability Research Repair Testing Training
-9Copyright 2009, David Emery & D&S Consultants, inc. See title page for copyright info
0. Architecture is distinct fromDescription of Architecture
The concept of architecture is a holistic notion, i.e. thetotality of the building
- That totality is not wholly captured in any individual blueprint, drawing, ormodel
- Architecture Descriptions are not uniquely defined by an Architecture. Multiplesets of (equally valid) renderings can exist for a given building/system.
- The drawings or models allow to reason about particular concerns about thebuilding or system
Center photo is of a model of Sagrada Familia, inverted with weights suspended
across the structure, used to make sure gravity loads were uniformly spread
8/9/2019 Presentations from 2009 Dinner Meeting
10/22
Systems Engineering Simulation Mode ling Maintenance Analysis Availability Research Repair Testing Training
-10Copyright 2009, David Emery & D&S Consultants, inc. See title page for copyright info
Architectures are effective when they answer relevant concerns- Difficult to answer the question if you dont know either the question or questioner- Concerns range from how the system works to can we build this architecture within
cost and schedule
Formally documenting stakeholders and concerns provides a strong basisfor ensuring the architecture description is scoped correctly- Gathering stakeholders and concerns is an implied process step by the standard- Reviewing stakeholder/concerns list with the stakeholders early prevents unpleasant
surprises later
The standard requires that architecture stakeholders and theirarchitecture-related concerns be identified- But it doesnt tell you how to determine the architecture stakeholders and architecture-
related concerns
- This can be used as a scoping mechanism for the architecture effort
1. Stakeholder Concerns should driveArchitectures and Their Descriptions
8/9/2019 Presentations from 2009 Dinner Meeting
11/22
Systems Engineering Simulation Mode ling Maintenance Analysis Availability Research Repair Testing Training
-11Copyright 2009, David Emery & D&S Consultants, inc. See title page for copyright info
2. Multiple Views Each covers theSystem for (relevant/allocated) Concerns
Architecture Descriptions are inherently multi-View- No single View addresses all concerns- This was somewhat controversial in the 90s but is generally
accepted now
A View should cover the entire system (with respect to theConcerns of interest for that view)- Thus a View has a specific set of Concerns (e.g. performance,
security, functionality)
- The View can be composed of multiple models, which together coverthe system
E.g. a network queuing Model and a CPU processing model togethercould address end-to-end performance concerns
The View aggregates Models/Model contents sufficient to to ensurecompleteness
8/9/2019 Presentations from 2009 Dinner Meeting
12/22
Systems Engineering Simulation Mode ling Maintenance Analysis Availability Research Repair Testing Training
-12Copyright 2009, David Emery & D&S Consultants, inc. See title page for copyright info
3. Viewpoints distinct from Views
Viewpoints (what to describe) are separate from Views (this description)- View is to Viewpoint as Map is to Legend- Viewpoint defines how to construct the view, e.g. modeling language(s),
contents, relationship with other viewpoints, etc.
- Views contain the content specific to This Architecture (Description) of thisparticular system
- Viewpoints ensure stakeholder concerns are identified and allocated/covered Viewpoints enable better architectural practices
- Represents current practices with viewpoint sets such as Kruchtens 4+1- Explicitly capturing Viewpoints as part of an AD ensures consistency and
repeatability, particularly when evaluating alternative architectures
- Supports development of architecture tool, techniques and methods- Akin to declaration before use ideas in software
The standard requires a 1-1 relationship between Viewpoint and View ina given AD (consequence of entire system requirement on views)
8/9/2019 Presentations from 2009 Dinner Meeting
13/22
Systems Engineering Simulation Mode ling Maintenance Analysis Availability Research Repair Testing Training
-13Copyright 2009, David Emery & D&S Consultants, inc. See title page for copyright info
Proposed Additions to the Standard:Correspondences and Architecture Frameworks
8/9/2019 Presentations from 2009 Dinner Meeting
14/22
Systems Engineering Simulation Mode ling Maintenance Analysis Availability Research Repair Testing Training
-14Copyright 2009, David Emery & D&S Consultants, inc. See title page for copyright info
New Definitions
Model Correspondence Rule: constraint on two ormore architecture models enforced on a model
correspondence
Model Correspondence: relation on two or morearchitecture modelsArchitecture Framework: conventions and common
practices for architecture description established
within a specific domain or stakeholder community
8/9/2019 Presentations from 2009 Dinner Meeting
15/22
Systems Engineering Simulation Mode ling Maintenance Analysis Availability Research Repair Testing Training
-15Copyright 2009, David Emery & D&S Consultants, inc. See title page for copyright info
Model Correspondences
Model Correspondences and Model Correspondence Rules filla hole in the current standard- Current standard provides no requirement or guidance on cross-view
consistency (other than inconsistencies should be documented)
- Many existing approaches provide such rules (e.g. RM-ODP)
Model Correspondences relate elements of an AD (Models)to each other- Model Correspondence Rules tell you what correspondences should exist in an
AD Example: Every software element in a Logical View should be allocated to at least
one processing node in the Deployment View
- Model Correspondences represent the connections within this architecture Example: A table showing CSCIs allocated to computers
Model Correspondences can exist in an AD without anassociated Correspondence Rule- Allows connections specific to the Architecture being described to be captured
8/9/2019 Presentations from 2009 Dinner Meeting
16/22
Systems Engineering Simulation Mode ling Maintenance Analysis Availability Research Repair Testing Training
-16Copyright 2009, David Emery & D&S Consultants, inc. See title page for copyright info
Architecture Frameworks
There are a lot of Architecture FrameworksE.g. DODAF, MODAF, TOGAF, RM-ODP, GERAM, 4+1, Zachman
each provide a set of reusable viewpointsClearly there is existing practice that could be codified
Architecture Frameworks can be described in terms of thestandards Metamodel/ontology (with the addition of ModelCorrespondence Rules)
Key contribution/addition: An Architecture Frameworkshould explicitly identify the stakeholders & concerns thatmotivate the Frameworks choice of Viewpoints
Revision adds new conformance pointsArchitecture Description to Architecture FrameworkArchitecture Framework to standard
8/9/2019 Presentations from 2009 Dinner Meeting
17/22
Systems Engineering Simulation Mode ling Maintenance Analysis Availability Research Repair Testing Training
-17Copyright 2009, David Emery & D&S Consultants, inc. See title page for copyright info
How can the ISO Standard beapplied to the DODAF?
Application to DODAF document itself, i.e. making theDODAF a conforming Architecture Framework
- Facilitate the description of the DODAF itself (e.g. byreusing standardized definitions)
-Support comparisons and integration with otherArchitecture Frameworks
Application to the construction of ArchitectureDescriptions governed by DODAF (and possibly otherArchitecture Frameworks)
- Common practice seems to be Do DODAF and do 4+1for software
8/9/2019 Presentations from 2009 Dinner Meeting
18/22
Systems Engineering Simulation Mode ling Maintenance Analysis Availability Research Repair Testing Training
-18Copyright 2009, David Emery & D&S Consultants, inc. See title page for copyright info
DoD should make the DODAFa conforming framework
Changes in terminologyDODAF 1.5 has 3 viewpoints (Operational, System, Technical) and
~25 Models (depends on how you count the productsSome products (e.g. SV-5 Operational Activity to System Function
matrix) are really Model Correspondence RulesAdd a metamodel/ontology that builds on the Standards model to
show relationship of concepts within the DODAF
Explicit identification of Stakeholders and Concerns Why am I doing this product? Who is going to use it, and for what purposes?
Ensure conformance with DODAF leads to (or at leastdoes not contradict) conformance to the Standard
DODAF 2.0 talks about IEEE Std 1471, but not in anyconsistent (or conforming) way
8/9/2019 Presentations from 2009 Dinner Meeting
19/22
Systems Engineering Simulation Mode ling Maintenance Analysis Availability Research Repair Testing Training
-19Copyright 2009, David Emery & D&S Consultants, inc. See title page for copyright info
Applying DODAF + ISO/IEC 42010to produce an Architecture Description
Reconcile differences in terminology, e.g. view vsviewpointClearly distinguish between the concepts in the DODAF from the
concepts in the AD for the specific system
Explicitly identify stakeholders & concerns for eachDODAF view (Viewpoint) and productE.g. through an SEI Quality Attribute WorkshopMake sure each product has a very clearly defined customer and the
right- information and the right- level of detail Include provisions for rationale capture, evaluation/review
Define the full set of Viewpoints and Models and makesure they are appropriately connected E.g. DODAF SV-4 System Functions are mapped to elements in the 4+1
Logical View(point)
8/9/2019 Presentations from 2009 Dinner Meeting
20/22
Systems Engineering Simulation Mode ling Maintenance Analysis Availability Research Repair Testing Training
-20Copyright 2009, David Emery & D&S Consultants, inc. See title page for copyright info
Another application: Product Lines
Product Lines can/should share a common Architecture Framework Each product within the Product Line should be a separate (ISO 42010
conforming) Architecture Description
The Architecture Framework can define Models that are shared amongall product line instances
The conformance points in the standard are defined in terms of a singlesystem in a point in time when conformance is claimed
- Consider the architecture of each vehicle (built on a common chassis):
8/9/2019 Presentations from 2009 Dinner Meeting
21/22
Systems Engineering Simulation Mode ling Maintenance Analysis Availability Research Repair Testing Training
-21Copyright 2009, David Emery & D&S Consultants, inc. See title page for copyright info
How to Participate
IEEE Balloting Group for P42010 closed in March, ballotingon first IEEE draft just completed- 87% response rate, 87% of those approved
US participates in ISO/IEC JTC1/SC7 through the USTechnical Activities Group (SC7 US TAG)- TAG membership is by organization/company- TAGs Technical WG 42 recommends US position to US TAG
Current plan:- Resolve ballot comments (IEEE & ISO) by early June, submit next draft for
Final Committee Draft status optimistic but achievable!
- Next ballot over the summer, hope for SC7 approval of the DIS in Nov 2009-
Final ballot should lead to ISO standardization in 2010 under this schedulehttp://www.iso-architecture.org/ieee-1471
8/9/2019 Presentations from 2009 Dinner Meeting
22/22
Systems Engineering Simulation Mode ling Maintenance Analysis Availability Research Repair Testing Training
-22Copyright 2009, David Emery & D&S Consultants, inc. See title page for copyright info
Summary
ISO/IEC 42010:2007 (nee IEEE Std 1471-2000) is a standardfor describing architectures- Does not prescribe how to do architecture- Does not prescribe any particular set of representations/renderings- Provides a metamodel/ontology for elements of an Architecture Description
Emphasizes Architectures should address (known)stakeholders & their concerns
Provides for multiple views as (usually) necessary torepresent an architecture (covering the entire system fromset of stakeholder concerns)- Views are composed of models, and models/model components can be
shared across views
Separates the Viewpoint (what to describe) from the View(description for this architecture)Proposed revision introduces a means to connect modelcomponents in views with each other
Proposed revision provides a standard definition forArchitecture Framework