For these reasons, the Object Management Group's (OMG) CBDC WG recommends the adoption of a systematic effort for the development of an SoS identified as a Mission-Critical SoS. The CBDC also has a potential System Lifecycle that spans decades at a minimum. The need for an SoS, long-lived, Mission-Critical System sets the stage for the biggest risks for the U.S. CBDC, the potential for a looming Software Crisis.
A Software Crisis occurs on projects for many reasons, but the Information Technology (IT) industry has focused on a shortlist, which is provided in summary form in Table 1. Any particular project suffering a Software Crisis may have any number of these issues and unfortunately, some projects might have all of these issues.
However, all is not lost for the CBDC. There is a way to prevent a future CBDC Software Crisis by applying sound Systems Engineering practices throughout the CBDC lifecycle, starting immediately. The OMG has a rich history of working in Systems and Software Engineering. Table 2 provides a list of OMG standards covering Systems Engineering and Software Engineering.
The Systems Engineering process as described by the Department of Energy (DOE) is to develop, manage, and implement large programs 1). The following is a modified version of the DOE process tweaked to differentiate the Water Fall Model versus the Agile Model.
DOE goes on to describe the value of the Systems Engineering Process realization in a number of ways, including:
Figure 1 provides a simplified high-level processes flow for Systems Engineering. This process was developed by the U.S. Department of Energy and would have to be tailored to meet the needs of a U.S. CBDC. Basically, the System's process flow is captured in Table 4
The steps in the Simplified high-level Systems Engineering Process as defined by the U.S. Department of Energy:
|Architecture Management||Am||Identifies the metadata and views required to develop a suitable architecture that is fit for its purpose.|
|Strategic||St||Capability management process. Describes the capability taxonomy, composition, dependencies, and evolution.|
|Operational||Op||Illustrates the Logical Architecture of the enterprise. Describes the requirements, operational behavior, structure, and exchanges required to support (exhibit) capabilities. Defines all operational elements in an implementation/solution-independent manner.|
|Services||Sv||The Service-Orientated View (SOV) is a description of services needed to directly support the operational domain as described in the Operational View. A service within MODAF is understood in its broadest sense, as a unit of work through which a provider provides a useful result to a consumer. MODAF: The Service Views within the Services Viewpoint describe the design for service-based solutions to support operational development processes (JCIDS) and Defense Acquisition System or capability development within the Joint Capability Areas.|
|Personnel||Ps||Defines and explores organizational resource types. Shows the taxonomy of types of organizational resources as well as connections, interaction, and growth over time.|
|Resources||Rs||Captures a solution architecture consisting of resources, e.g., organizational, software, artifacts, capability configurations, and natural resources that implement the operational requirements. Further design of a resource is typically detailed in SysML or UML.|
|Security||Sc||Security assets and security enclaves. Defines the hierarchy of security assets and asset owners, security constraints (policy, laws, and guidance), and details where they are located (security enclaves).|
|Projects||Pj||Describes projects and project milestones, how those projects deliver capabilities, the organizations contributing to the projects, and dependencies between projects.|
|Standards||Sd||MODAF: Technical Standards Views are extended from the core DoDAF views to include non-technical standards such as operational doctrine, industry process standards, etc. DoDAF: The Standards Views within the Standards Viewpoint are the set of rules governing the arrangement, interaction, and interdependence of solution parts or elements.|
|Actual Resources||Ar||The analysis, e.g., evaluation of different alternatives, what-if, trade-offs, V&V on the actual resource configurations. Illustrates the expected or achieved actual resource configurations.|
|Motivation||Mv||Captures motivational elements e.g., challenges, opportunities, and concerns, that pertain to enterprise transformation efforts, and different types of requirements, e.g., operational, services, personnel, resources, or security controls.|
|Taxonomy||Tx||Presents all the elements as a standalone structure. Presents all the elements as a specialization hierarchy, provides a text definition for each one and references the source of the element|
|Structure||Sr||Describes the breakdown of structural elements e.g., logical performers, systems, projects, etc. into their smaller parts|
|Connectivity||Cn||Describes the connections, relationships, and interactions between the different elements.|
|Processes||Pr||Captures activity-based behavior and flows. It describes activities, their Inputs/Outputs, activity actions, and flows between them.|
|States||St||Captures state-based behavior of an element. It is a graphical representation of the states of a structural element and how it responds to various events and actions.|
|Sequences||Sq||Expresses a time-ordered examination of the exchanges as a result of a particular scenario. Provides a time-ordered examination of the exchanges between participating elements as a result of a particular scenario.|
|Information||If||Address the information perspective on operational, service, and resource architectures. Allows analysis of an architecture’s information and data definition aspect, without consideration of implementation-specific issues.|
|Constraints||Ct||Details the measurements that set performance requirements constraining capabilities. Also defines the rules governing behavior and structure.|
|Roadmap||Rm||Addresses how elements in the architecture change over time.|
|Traceability||Tr||Describes the mapping between elements in the architecture. This can be between different viewpoints within domains as well as between domains. It can also be between structure and behaviors.|
5. Verification of the System is progressing according to plan. This is done through Test Inspection, Demonstrations, as well as Static and Dynamic Analysis of the System. Another major tool should be the use of Modeling and testing in Virtual Environments.
6. Evaluation and Optimization occur before a release to the public. Based on the results of Trade Studies, risk analysis, performance, etc, the System Design Specifications can be updated, refined, or added to. </WRAP>