User Tools

Site Tools


cbdc:public:cbdc_omg:04_doc:20_comments:brp:q11:01_risk

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
Last revision Both sides next revision
cbdc:public:cbdc_omg:04_doc:20_comments:brp:q11:01_risk [2022/05/16 18:18]
nick ↷ Page moved from cbdc:cbdc_omg:04_doc:20_comments:brp:q11:01_risk to cbdc:public:04_doc:20_comments:brp:q11:01_risk
cbdc:public:cbdc_omg:04_doc:20_comments:brp:q11:01_risk [2022/05/20 00:52]
terrance
Line 1: Line 1:
 ====== 1. Risk of a Software Crisis ====== ====== 1. Risk of a Software Crisis ======
-[[cbdc:​cbdc_omg:​04_doc:​20_comments:​brp:​q11:​start| Return to Question 11]]+|< 100% >| 
 +[[cbdc:public:​cbdc_omg:​04_doc:​20_comments:​brp:​q11:​start| Return to Question 11]]  ​| ​ <​WRAP>​ 
 +<​html><​b>​ 
 +<a href="​mailto:​[email protected]?​Subject=OMG CBDC Response:  
 +11.1. Risk of a Software Crisis 
 +">​Provide Feedback</​a></​b>​ 
 +</​html>​ 
 +</​WRAP> ​ |
  
-For these reasons, the [[https://​www.omg.org/​ | Object Management Group (OMG) ]] 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 ​Lifcycle]] 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]].+For these reasons, the [[https://​www.omg.org/​ | Object Management Group (OMG) ]] 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. ​ 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. ​
Line 22: Line 29:
 </​table>​ </​table>​
  
-However, all is not lost for the CBDC. There is a way to prevent a future ​CNDC **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]]. ​+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]]. ​
  
 <table omgStds> <table omgStds>
-<​caption>​The Object Management Group'​s list of System and Software Engineering ​Stadards.</​caption>​+<​caption>​The Object Management Group'​s list of System and Software Engineering ​Standards.</​caption>​
   * [[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.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:​b:​bpmn ​    | Business Process Model and Notation (BPMN) ]]
Line 41: Line 48:
   * [[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.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.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) ]] +  * [[https://​www.omgwiki.org/​dido/​doku.php?​id=dido:​public:​ra:​xapend:​xapend.b_stds:​tech:​omg:​xmi ​  | XML Metadata Interchange (XMI) ]] 
 +</​table>​ 
 + 
 +<table isoStds>​ 
 +<​caption>​The International Organization for Standardization (ISO) list of System and Software Engineering Standards.</​caption>​ 
   * [[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:​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]]   * [[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]]
- 
  
 </​table>​ </​table>​
Line 75: Line 86:
  
 <figure sysProcOverview>​ <figure sysProcOverview>​
-{{  ​:cbdc:​private:​cbdc_omg:​04_doc:​20_comments:​brp:​q11:​screen_shot_2022-04-22_at_3.52.14_pm.png?​800 ​ |}}+{{  cbdc:​04_doc:​20_comments:​brp:​q11:​screen_shot_2022-04-22_at_3.52.14_pm.png?​800 ​ |}}
 <​caption>​Simplified high-level Systems Engineering Process as defined by the U.S. Department of Energy. </​caption>​ <​caption>​Simplified high-level Systems Engineering Process as defined by the U.S. Department of Energy. </​caption>​
 </​figure>​ </​figure>​
Line 81: Line 92:
 The steps in the 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.omgwiki.org/CBDC/doku.php?​id=cbdc:​private:​cbdc_omg:​15_summary:​start ​| White Paper]] ​as identified ​by the [[https://​www.omg.org/​ | Object Management Group'​s ]] report ​called [[https://​www.omgwiki.org/​CBDC/​doku.php?​id=cbdc:private:cbdc_omg:15_summary:start | White Paper Analysis]] is a good starting point for these. +<table sysProcSteps>​ 
-  +<​caption>​high-level Systems Engineering Process as defined by the U.S. Department of Energy</​caption>​ 
-2. The //"​Mission Needs"//​ are analyzed and transformed into //"​Mission Statements"//​ (i.e., Systems Requirements). For example, the **White Paper** desirement of: +  : 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: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: +    : ​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 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 Legislative Branch +      * U.S. CBDC Authorizing Law shall be approved by the Executive 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]]. Alsosee 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. ]] 
-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. +</​table>​
- +
-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. ]]+
  
 <table reqDocTable>​ <table reqDocTable>​
cbdc/public/cbdc_omg/04_doc/20_comments/brp/q11/01_risk.txt · Last modified: 2022/06/17 19:01 by terrance