© 2009 carnegie mellon university 1

The Method Framework for Engineering System Architectures (MFESA) Donald Firesmith, 5 March 2009
3/4/09
3/4/09
3/4/09
© 2009 Carnegie Mellon University 5
The fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution. From ANSI/IEEE 1471-2000. The composite of the design architectures for products and their life cycle processes. From IEEE 1220-1998 as found at their glossary. A representation of a system in which there is a mapping of functionality onto hardware and software components, a mapping of the software architecture onto the hardware architecture, and human interaction with these components. From the Carnegie Mellon University's Software Engineering Institute as found at its glossary. An architecture is the most important, pervasive, top-level, strategic inventions, decisions, and their associated rationales about the overall structure (i.e., essential elements and their relationships) and associated characteristics and behavior. From OPEN Process Framework (OPF) Repository. A description of the design and contents of a computer system. If documented, it may include information such as a detailed inventory of current hardware, software and networking capabilities; a description of long-range plans and priorities for future purchases, and a plan for upgrading and/or replacing dated equipment and software. From The National Center for Education Statistics glossary. A formal description of a system, or a detailed plan of the system at component level to guide its implementation. TOGAF The structure of components, their interrelationships, and the principles and guidelines governing their design and evolution over time. TOGAF
3/4/09
Note that the architecture is not just the physical aggregation structure. Note that architecture is implicit while its representations are explicit. Example design-level decision is the use of object-oriented design (OOD) for subsystem and software components. Example implementation-level decision is the use of a safe subset of C++ for the software components or carbon-fiber for an aircraft fuselage.
3/4/09
3/4/09
Architectural capabilities were estimated based on the answer to a set of architecture- related questions. The higher the organization’s architectural capabilities, the more of there projects have higher performance.
3/4/09
Types of architectural components include software, hardware, data, manual procedures, roles played by people, facilities, and materials.
3/4/09
Note the difference between architecting a small simple system and architecting an ultra-large-scale system of independently governed systems.
Examples of size (and complexity) differences are the following systems: jet engine, individual aircraft, fleet of aircraft, aircraft with ground-based support (maintenance, training, and mission planning), air traffic, national traffic system, and global traffic system.
3/4/09
3/4/09
3/4/09
3/4/09
3/4/09
3/4/09
3/4/09
This is not the only distinction possible between method and process. Some people equate method and process as synonyms. Others consider processes to be large scale activities while methods are small scale implementations.
3/4/09
The MFESA interpretation is more consistent with the ISO methodology standard than the OMG methodology standard.
Actually, specification is really classification and instantiation using clabjects, but unnecessarily complex for most architects.
Metamethod components are the abstract foundational classes of method components (work products, work units, and workers).
The process layer consists of actual, as-performed, project-specific architecture engineering process components and processes. In other words, real people performing real tasks to produce real work products on real projects. These process components are instances (enactments) of method components at the next level up.
The method level consists of as intended architecture engineering methods and standards (and the method components they consist of). Note the difference between as-intended methods and as-performed processes; methods are models of processes. Different architecture engineering methods and standards consist of different method components (descriptions of producers, work units, and work products). When performed on real projects, the method components are instantiated (enacted) as the performance of different work units and production of different work products, possibly by different workers. The arcs in this diagram mean that method components in the system-specific method are classes of the process components in the process level.
MFESA is a method framework that can be used to produce any reasonable system architecture engineering method. However, MFESA is described with a common standard terminology that may not exactly match the terminology of various methods and standards.
The lower arcs in this diagram mean that method components in the system-specific method are classes of the process components in the process level. The upper arcs mean that the methods and standards in the method level can be constructed from the method framework in the metamethod level.
MFESA ontology of concepts and terminology: an information model defining a consistent set of interrelated concepts and terms underlying system architecture engineering
MFESA metamodel: a model of the types of method components in the repository of reusable method components (i.e., architectural work products, architectural work units, and architectural workers)
MFESA repository: a repository containing (1) a consistent class library of reusable method components for creating situation-specific methods for engineering system architectures, and (2) a set of reusable methods constructed out of the reusable method components
MFESA metamethod: a method for creating effective and efficient project-specific methods for engineering system architectures (i.e., a method for creating methods)
3/4/09
3/4/09
3/4/09
3/4/09
3/4/09
Note that this is just one illustrative example of how effort on the ten MFESA tasks could be allocated to life-cycle phases. However, the recommendation is not to use a strict waterfall development cycle, but rather an iterative, incremental, concurrent, and time- boxed life cycle. Note that some tasks continue until the system is retired.
3/4/09
3/4/09
3/4/09
An architectural model is an architectural representation that models of a single (logical or physical, static or dynamic) system structure in terms of the structure’s elements and the relationships between them. An architectural view is any architectural representation describing a single architectural structure that consists of one or more related models of that structure An architectural focus area is the cohesive set of all architectural decisions, inventions, and tradeoffs related to a specific architectural concern, regardless of the architectural view, model, or structure where they are documented or found
3/4/09
Architecture elements are logical parts of the architecture.
3/4/09
3/4/09
Architectural components are major physical parts of the system.
3/4/09
3/4/09
3/4/09
3/4/09
3/4/09
3/4/09
The primary steps are to select the appropriate method components, tailor them (primarily by removing unnecessary parts), and then integrating them together to form the situation-specific system architecture engineering method. The metamethod is typically performed in an iterative, incremental, concurrent, and time-boxed manner.
3/4/09
3/4/09
Name Program Name

© 2009 carnegie mellon university 1

Documents