Process 3, depicted in Figure 3-6, is based on Martin’s approach (Martin 1997) and provides a more detailed explanation of the Architecture Definition process:
The first two steps may be performed in parallel.
o 3.1.1 Assess Technology Alternatives: Evaluate technologies that can be applied to solve the problem. Identify possible system concepts and options. Examine technology trends to determine appropriate level of technology at time of deployment.
o 3.1.2 Synthesize System Element Alternatives: Define and refine system element alternatives for each relevant set of functional requirements using a bottom-up approach.
3.2 Allocate Functions to System Elements: Identify which functions will be performed by which system elements or subsystems. Apportion the associated performance of each function to the appropriate system element.
3.3 Allocate Constraints to System Elements: Identify constraints that pertain directly to system elements and that do not apply to behavioral functions. These constraints should include non-functional requirements.
3.4 Define Physical Interfaces: Define electrical, data, mechanical and other interfaces between elements of the system. Identify all interfaces between the system and the external world, including the supportability domain. Document these interfaces in interface control documents.
After completion of the previous steps, proceed to the next three steps, which may be performed in parallel.
o 3.5.1 Define Platform and Architecture: Delineate the platform(s) upon which the system/product will be installed. Define the architectures in terms of product structures and interactions between the products and with elements in the environment. Map scenarios to various configurations of the system. The hierarchical relationship of the system elements should be documented in an Architecture Block Diagram (ABD) or another suitable artifact.
o 3.5.2 Refine Work Breakdown Structure (WBS): Translate the selected architecture and its decomposition into a WBS format for work planning and cost/schedule tracking and control.
o 3.5.3 Develop Lifecycle Techniques and Procedures: Develop appropriate models and parameters to support life cycle cost analysis. Define how the system will be manufactured, verified, deployed, operated, maintained and disposed of. Define training and other supportability products and procedures. Identify all required enabling products and their key characteristics.
3.6 Check Requirements Compliance: Ensure all functional and performance requirements have been mapped to the system elements and subsystems. Ensure that the system elements at each level in the architecture satisfy all requirements and constraints. Compliance may be checked using System Effectiveness Analyses, simulations, demonstrations, inspections and/or tests. Models and prototypes may also be used.
3.7 Integrate System Elements: Progressively integrate the system elements into items that provide an end-use function (bottom-up). At each level, the resulting design requirements, physical configuration and physical interfaces should be verified to ensure that functional and performance requirements are satisfied.
3.4.1 SysML Application in Architecture Development
The major structural extension in SysML is the block, which extends the UML-structured class. It is a general-purpose hierarchical structuring mechanism that abstracts away much of the software-specific detail implicit in UML-structured classes. Blocks can represent any level of the system hierarchy, including the top-level system, a subsystem, or logical or physical component of a system or environment. A SysML block describes a system as a collection of parts and connections between them that enable communication and other forms of interaction. Ports provide access to the internal structure of a block for use when the object is used within the context of a larger
structure. SysML provides standard ports that support client-server communication (e.g., required and provided interfaces) and FlowPorts that define flows in or out of a block. Two diagrams are used to describe block relationships. The Block Definition Diagram (BDD), similar to a traditional class diagram, is used to describe relationships that exist between blocks. The Internal Block Diagram (IBD) describes the internal structure of a system in terms of its parts, ports and connectors. (OMG 2009)
3.4.2 Assessment of Software Architectures
Bosch identified four methods for assessing the architecture using quality attributes during design. This project’s approach utilized all four methods based on the maturity of design. The four basic methods included scenario-based evaluation, simulation, mathematical modeling and experience-based assessment. Scenario-based evaluation utilizes the ConOps sustainment scenarios to depict the operational and sustainment concepts. This provides data points and assumptions, such as the frequency of technical refreshes for both hardware and software, which are significant drivers in estimating life cycle costs. The proposed or alternative system architectures are also evaluated using simulation. Simulation is applied to operational considerations, such as response and Human Systems Integration (HSI) considerations. Values are derived from the model to establish baseline assumptions that are input into the appropriate models, which are used in simulations. This approach also supports varying development timelines and independent development of systems and subsystems. As systems are developed, the actual values can be used to update the model supporting the simulation to determine the confidence of meeting mission requirements. Mathematical modeling is initially captured in the SysML as parametric data and provides the basis for operational factors, such as detection ranges, processing performance and other factors that can be used to compare alternative approaches. Although it is the least quantitative and explicit, experience-based assessments may provide the greatest insight based on experience vice theory. An example that illustrates this is the learning curve theory. It has been proven that experience results in increased efficiency, and this can be applied to developing architecture. (Bosch 2000)
Illustrates the architecture definition process in which functions from Process 2 are allocated to system elements. (Martin 1997)
Figure 3-6: Architecture Definition (Process 3)
3.2 Allocate Functions to System Elements 3.1.1 Assess Technology Alternatives 3.1.2 Synthesize System Element Alternatives 3.5.1 Define Platform & Architecture 3.5.3 Develop Lifecycle Techniques & Procedures 3.5.2 Refine Work Breakdown Structure 3.3 Allocate Constraints to System Elements 3.4 Define Physical Interfaces Process 4 Process 1 3.7 Integrate System Elements 3.6 Check Requirements Compliance Process 2