cbdc:public:cbdc_omg:04_doc:20_comments:brp:q11:01_risk
Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous 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/06/17 19:01] (current) 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's CBDC WG 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'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. | 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 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: | + | : 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]]. 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. ]] | |
| - | 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.1652739503.txt.gz · Last modified: 2022/05/16 18:18 by nick
