1. Systems Engineering Simulation Modeling Maintenance Analysis Availability Research Repair Testing Training Copyright © 2009, David Emery & D&S Consultants, inc. See title page for copyright info The Metamodel

2. Systems Engineering Simulation Modeling Maintenance Analysis Availability Research Repair Testing Training -2 Copyright © 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 architecture 2. 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 Kruchten’s “4+1” - Ensures consistency and repeatability, particularly when evaluating alternative architectures

3. Systems Engineering Simulation Modeling Maintenance Analysis Availability Research Repair Testing Training -3 Copyright © 2009, David Emery & D&S Consultants, inc. See title page for copyright info Irrelevant architecture  Common problems - Architecture effort focused on the wrong problems - Architecture effort producing the wrong information - Architecture arriving too late  Applying the Standard - Use Stakeholders and Concerns to identify the most critical problems Hold a Stakeholders & Concerns review early, to get buy-in (e.g. Software Engineering Institute’s “Quality Attribute Workshop”) - Use Viewpoints to make sure the architecture products meet stakeholder expectations Ensure the Viewpoint has the right notations and content Ensure the Viewpoint supports analysis and reviews - Consider 2 ‘quality gate’ reviews Stakeholders, Concerns, Frameworks, Viewpoints, Tools, Schedule, etc View/Model Content

4. Systems Engineering Simulation Modeling Maintenance Analysis Availability Research Repair Testing Training -4 Copyright © 2009, David Emery & D&S Consultants, inc. See title page for copyright info D oing ‘too much architecture’ - Focusing an architecture effort  Common problems - Architecture content not relevant (see previous solutions) - Architecture deliveries poorly understood - Architecture deliveries have wrong content - Architecture content not integrated into other project life cycle activities and repositories  Applying the Standard - Viewpoints provide the ‘document descriptions’ for architecture content Viewpoints should trace to identified Stakeholder Concerns (relevance) Viewpoints should define model content and modeling techniques, including tool usage and evaluation/review/qualification - Views and Models provide a basis for estimating architecture effort Viewpoint tells you what will be in the View and how to produce it This facilitates planning the effort - Prioritizing Stakeholder Concerns and Models help size the architecture effort

5. Systems Engineering Simulation Modeling Maintenance Analysis Availability Research Repair Testing Training -5 Copyright © 2009, David Emery & D&S Consultants, inc. See title page for copyright info Making the (architecture) solution ‘fit for purpose’  Common problems - Requirements and operational context/environment for the system not understood or captured - No early representation of the entire system to use for analysis, review or even ‘walkthroughs’ - Non-functional requirements not considered/not considered early enough  Applying the Standard - Stakeholder Concerns should include ‘how does the system fit in its environment?’ Includes identifying driving non-functional requirements Viewpoints should define appropriate analysis/review of non-functional aspects of the architecture, e.g. end-to-end performance models as part of a Performance Viewpoint - Scenario-based evaluation methods such as SEI’s Architecture Trade-Off Assessment Method (ATAM tm ) should be part of the architecture process Viewpoint/Model content should include enough detail for informal walkthroughs of system functions - Connect View content to formal requirements/specifications - Provide appropriate View Correspondence Rules to integrate architecture content

6. Systems Engineering Simulation Modeling Maintenance Analysis Availability Research Repair Testing Training -6 Copyright © 2009, David Emery & D&S Consultants, inc. See title page for copyright info Using the Standard to improve architecture practices  Define an Architecture Framework - Capture typical Stakeholders and Concerns in its domain - Identify Viewpoints against those concerns - Identify Models, including content, tool support, evaluation approaches - Identify cross-Model linkages, including how these links are established and maintained - Provide training and maintenance for the organization’s Architecture Framework  Tie the Architecture Framework into the overall development process - Establish an architecture planning process based on Prioritizing Stakeholders & Concerns Estimating resources for producing Views, given Viewpoint descriptions and an understanding of the system of interest - Establish architecture reviews - Establish linkages (including tool support) between architecture work products and other process artifacts/deliverables  Provide for maintenance of the architecture over the system life-cycle

7. Systems Engineering Simulation Modeling Maintenance Analysis Availability Research Repair Testing Training -7 Copyright © 2009, David Emery & D&S Consultants, inc. See title page for copyright info Sample application of the Standard: 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 among all product line instances  The conformance points in the standard are defined in terms of a ‘single system in a point in time when conformance is claimed ’ -Consider the ‘architecture’ of each vehicle (built on a common chassis):