====== 1. Risk of a Software Crisis ====== |< 100% >| | [[cbdc:public:cbdc_omg:04_doc:20_comments:brp:q11:start| Return to Question 11]] | Provide Feedback | For these reasons, the [[https://www.omg.org/ | Object Management Group's (OMG) ]] CBDC WG recommends the adoption of a systematic effort for the development of an SoS identified as a [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:m:missioncritical | Mission-Critical SoS]]. The CBDC also has a potential [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:s:syslifecycle | 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 [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:s:sw_crisis | Software Crisis]]. A **Software Crisis** occurs on projects for many reasons, but the [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:i:infotech | Information Technology (IT)]] industry has focused on a shortlist, which is provided in summary form in Table {{ref>swCrisis}}. Any particular project suffering a **Software Crisis** may have any number of these issues and unfortunately, some projects might have all of these issues. - Projects are running over budget - Projects are running behind schedule - Poor quality of the delivered software - Poor definition of requirements - Poor adherence to the requirements - Poor management of the entire project throughout its lifecycle - Poor communications between the Stakeholders, Systems Engineers, and Software Engineers - Poor documentation of Policies and Procedures for the project - Poor enforcement of Policies and Procedures for the project - Poor training of Stakeholders, Systems Engineers, and Software Engineers on Policies and Procedures. - Increase in System and Software complexity - Increase in Software costs compared to Hardware
Issues causing a Project to have a **Software Crisis**.
However, all is not lost for the CBDC. There is a way to prevent a future CBDC **Software Crisis** by applying sound [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:s:se | Systems Engineering]] practices throughout the CBDC lifecycle, starting immediately. The OMG has a rich history of working in Systems and Software Engineering. Table {{ref>omgStds}} provides a list of OMG standards covering [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:s:sw_engineering | Systems Engineering]] and [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:s:sw_engineering | Software Engineering]]. * [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.b_stds:tech:omg:bmn | Business Motivation Model (BMM)]] * [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:b:bpmn | Business Process Model and Notation (BPMN) ]] * [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:c:cwm | Common Warehouse Metamodel (CWM) ]] * [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.b_stds:tech:omg:dol | Distributed Ontology, Model, and Specification Language (DOL)]] * [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.b_stds:tech:omg:fibo | Financial Industry Business Ontology (FIBO) ]] * [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.b_stds:tech:omg:figi | Financial Instrument Global Identifier (FIGI)]] * [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:m:mof | MetaObject Facility (MOF) ]] * [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:m:mbse | Model Based Systems Engineering (MBSE) ]] * [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:m:mda | Model Driven Architecture (MDA) ]] * [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.b_stds:tech:omg:odm | Ontology Definition Metamodel (ODM) ]] * [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.b_stds:tech:omg:sbvr | Semantics Of Business Vocabulary And Business Rules (SBVR) ]] * [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.b_stds:tech:omg:sacm | Structured Assurance Case Metamodel (SACM) ]] * [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:s:sysml | Systems Modeling Language (SysML) ]] * [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.b_stds:tech:omg:uaf | Unified Architecture Framework (UAF)]] * [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:u:uml | Unified Modeling Language (UML)]] * [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.b_stds:tech:omg:xmi | XML Metadata Interchange (XMI) ]]
The Object Management Group's list of System and Software Engineering Standards.
* [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.b_stds:tech:iso:syseng | Systems and software engineering -- System life cycle processes]] * [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.b_stds:tech:iso:square_measure_product | Measurement of System and Software Product Quality]]
The International Organization for Standardization (ISO) list of System and Software Engineering Standards.
The Systems Engineering process as described by the Department of Energy (DOE) is to develop, manage, and implement large programs (( National Academy of Sciences, __Systems Analysis and Systems Engineering in Environmental Remediation Programs at the Department of Energy Hanford Site__, National Research Council 1998. Systems Analysis and Systems Engineering in Environmental Remediation Programs at the Department of Energy Hanford Site. Washington, DC: The National Academies Press. [[https://doi.org/10.17226/6224]] )). The following is a modified version of the DOE process tweaked to differentiate the Water Fall Model versus the Agile Model. 1. Orderly definition of the **System** through top-down development of **System Functions** and **System Requirements**. This is an iterative process with each iteration providing further decomposition of the System Level Requirments as needed. **Note:** These Systems-level definition iterations should not be confused with the [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:a:agile | Agile Sprints]] used during development. See the OMG DIDO-RA section on [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:1.4_req:00_aboutreq:05_currstate | The Current State of DIDO Requirements]]. 2. Clear distinction between: a. External driven **System** requirements and constraints, which are by intent not easy to modify. In other words, the identification of System Functional and Non-Functional Requirements. b. Internal driven **Design** (i.e., implementation) requirements developed by the project, which are potentially modifiable and evolutionary with new requirements added as the system is developed. In other words, Derived Requirements. 3. Top-down consideration and evaluation of alternative solutions and designs based on the System [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:1.4_req:1_func | Functional]] and [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:1.4_req:2_nonfunc | Non-Functional Requirements]] 4. Completeness and traceability for the design of System Components and System Interfaces, for configuration and change control, and for the system verification and validation plan(s). In other words, the SoS must come together as a cohesive, solitary group of capabilities that synergize the system to deliver the desired effects. All the Systems within the SoS must have a single, cohesive, unified understanding of the other Systems within the SoS and must be able to use standardized Application Programming Interfaces (APIs). DOE goes on to describe the value of the Systems Engineering Process realization in a number of ways, including: - Increased ability to estimate system life-cycle costs - Reduced redesign due to consideration of the entire system throughout its development - Increased ability to affect design changes and retrofits due to clear traceability of requirements, design features, and configuration control - Increased probability of achieving the best technical design and operational concept through the iterative consideration of design alternatives, where **//best//** is defined through decision criteria such as cost, risk, and use. See the OMG DIDO-RA section on [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:1.4_req:3_assessment | Assessing Requirements]] Figure {{ref>sysProcOverview}} 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 {{ref>sysProcSteps}}
{{ cbdc:04_doc:20_comments:brp:q11:screen_shot_2022-04-22_at_3.52.14_pm.png?800 |}} Simplified high-level Systems Engineering Process as defined by the U.S. Department of Energy.
The steps in the Simplified high-level Systems Engineering Process as defined by the U.S. Department of Energy: : 1. A high-level statement of system needs. In this discussion, the Mission needs are referred to as "Desirements". The current "Desirements" from the [[https://www.federalreserve.gov/publications/files/money-and-payments-20220120.pdf | White Paper]] are identified in the section called CBDC WG [[cbdc:public:cbdc_omg:04_doc:12_summary:start | White Paper Analysis]] and is a good starting point for these. : 2. The //"Mission Needs"// are analyzed and transformed into //"Mission Statements"// (i.e., Systems Requirements). For example, the **White Paper** desirement of: : The Federal Reserve does not intend to proceed with the issuance of a CBDC without clear support from the Executive Branch, the Legislative Branch, and also ideally in the form of a specific authorizing law would be transformed into: * U.S. CBDC shall be authorized by a specific U.S. Law * U.S. CBDC Authorizing Law shall be approved by the Legislative Branch * U.S. CBDC Authorizing Law shall be approved by the Executive Branch : 3. The //"Mission Statements"// are transformed into [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:1.4_req:1_func | Functional]] (i.e, performance, interfaces)and [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:1.4_req:2_nonfunc | Non-Functional]] Requirements (i.e., constraints), see OMG DIDO-RA [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:1.4_req:00_aboutreq:07_reqspec | Specifying Requirements]]. Also, see the OMG DIDO-RA section on Testability and especially the subsection on [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:s:swassurance | Software Assurance (SwA)]]. If the requirements are not testable, then they serve little purpose. : 4. The //"Requirements"// are allocated to Systems, or components (i.e., elements) and added to a formal System Description and Systems Analysis. Table {{ref>reqDocTable}} captures the documents called out in the [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.b_stds:tech:omg:uaf | Unified Architecture Framework (UAF)]]. These documents can be tailored for the U.S. CBDC, but many of the documents are useful for [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:m:missioncritical | Mission Critical Systems. ]]
high-level Systems Engineering Process as defined by the U.S. Department of Energy
|< 100% 15% 5% >| ^ Viewpoint ^ Acronym ^ Description | ^ 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. |
The kinds of documents that can be used to define the system.
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. /**=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- /* To add a discussion page to this page, comment out the line that says ~~DISCUSSION:off~~ */ ~~DISCUSSION:on|Outstanding Issues~~ ~~DISCUSSION:off~~