openchain:proposed-draft
Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
openchain:proposed-draft [2015/02/02 23:49] Kellyw [Section 1] |
openchain:proposed-draft [2016/08/11 12:12] (current) AliceSmith [Software Engineering Institute (SEI)] |
||
|---|---|---|---|
| Line 50: | Line 50: | ||
| The compliance reference model will consist of a set of goals and supporting practices. In appraising whether the goals have been met, auditors typically look at the supporting practices to see whether they have been performed or instantiated. Six goals and their supporting practices are outlined below. The complete reference model will define additional levels of detail and alternative supporting practices, while the appraisal methodology will guide auditors in what to look for and how to determine whether or not a goal has been met. __Part of the certification includes the requirement that those employees who need to adhere to the process be trained on it. Additionally, as the process is dependent on such employees’ ability to know when the process is triggered (e.g., when certain open source software is used) such employees need to be trained on a consistent set of topical areas that are incorporated into the educational materials, that we propose also form part of the certification criteria.__ | The compliance reference model will consist of a set of goals and supporting practices. In appraising whether the goals have been met, auditors typically look at the supporting practices to see whether they have been performed or instantiated. Six goals and their supporting practices are outlined below. The complete reference model will define additional levels of detail and alternative supporting practices, while the appraisal methodology will guide auditors in what to look for and how to determine whether or not a goal has been met. __Part of the certification includes the requirement that those employees who need to adhere to the process be trained on it. Additionally, as the process is dependent on such employees’ ability to know when the process is triggered (e.g., when certain open source software is used) such employees need to be trained on a consistent set of topical areas that are incorporated into the educational materials, that we propose also form part of the certification criteria.__ | ||
| - | ===== Section 1 ===== | + | ===== Outline of Compliance Reference Model ===== |
| - | G1: Everyone knows their FOSS responsibilities\\ | + | G = Goal\\ |
| - | Supporting Practices:\\ | + | SP = Supporting Practices\\ |
| - | SP1.1 FOSS policy exists\\ | + | C = Criteria for supporting practices\\ |
| + | (see charts below for original version) | ||
| - | __Criteria:__\\ | + | - **G1: Everyone knows their FOSS responsibilities** |
| - | __C1.1.1 Written__\\ | + | - SP1.1 FOSS policy exists |
| - | __C1.1.2 Internally available__\\ | + | * C1.1.1 Written |
| - | __C1.1.3 Content must include:__\\ | + | * C1.1.2 Internally available |
| - | __-distribution of open source__\\ | + | * C1.1.3 Content must include: |
| - | __-internal use for code generation__\\ | + | * distribution of open source |
| - | __-requirement to comply with licenses__\\ | + | * internal use for code generation |
| - | __-utilization of a FOSS approval process__\\ | + | * requirement to comply with licenses |
| - | + | * utilization of a FOSS approval process | |
| - | SP1.2 FOSS compliance training program actively used\\ | + | - SP1.2 FOSS compliance training program actively used |
| - | + | * C1.2.1 Required for all relevant employees, including: | |
| - | __Criteria:__\\ | + | * software developers |
| - | __C1.2.1 Required for all relevant employees, including:__ | + | * software program managers |
| - | * __software developers__ | + | * software procurement roles |
| - | * __software program managers__ | + | * C1.2.2 Content: |
| - | * __software procurement roles__ | + | * Identify FOSS |
| - | __C1.2.2 Content:__\\ | + | * FOSS concepts and obligations |
| - | * __Identify FOSS__\\ | + | * How to adhere to FOSS approval process |
| - | * __FOSS concepts and obligations__\\ | + | * C1.2.3 Delivery method\\ |
| - | * __How to adhere to FOSS approval process__\\ | + | * In-person, online //(JL: should we dictate what format the training delivery method should be? Is this to mean it can be in either in-person or online - or needs to be in both formats?)// |
| - | __C1.2.3 Delivery method__\\ | + | * C1.2.4 Compliance and attendance //(JL: compliance with the training? might not want to use the word "compliance" here as it is more associated with license compliance?)// |
| - | * __In-person, online__\\ | + | * Recordkeeping |
| - | __C1.2.4 Compliance and attendance__\\ | + | * Reoccurring training |
| - | * __Recordkeeping__\\ | + | - **G2: Responsibility for achieving compliance is assigned** |
| - | * __Reoccurring training__\\ | + | - SP2.1 FOSS Compliance Officer exists |
| - | + | - SP2.2 Compliance management activity is resourced | |
| - | G2: Responsibility for achieving compliance is assigned\\ | + | * SP2.2.1 Processes, procedures, templates, forms, etc. are developed |
| - | Supporting practices:\\ | + | * SP2.2.2 Compliance tool needs are identified //(JL: do we want to specifically say "tools"? Are tools always required, e.g. small companies who still want to use these guidelines?)// |
| - | SP2.1 FOSS Compliance Officer exists\\ | + | * SP2.2.3 Compliance tools are evaluated, developed or acquired, and deployed |
| - | SP2.2 Compliance management activity is resourced\\ | + | - SP2.3 Licensing expertise is available //(JL: recommend putting this as first SP here)// |
| - | -SP2.2.1 Processes, procedures, templates, forms, etc. are developed\\ | + | - **G3: FOSS content (packages/license) is known** //consider making this G2?// |
| - | -SP2.2.2 Compliance tool needs are identified\\ | + | - SP3.1 Code audits/scans are conducted |
| - | -SP2.2.3 Compliance tools are evaluated, developed or acquired, and deployed\\ | + | - SP3.2 Supplier compliance is managed //(JL: define who a supplier is; what if the company in question is situated to not really have suppliers, do they still have to comply with these goals?)// |
| - | SP2.3 Licensing expertise is available\\ | + | * SP3.2.1 Supplier compliance practices are assessed |
| - | + | * SP3.2.2 Supplier FOSS disclosures are made and reviewed | |
| - | G3: FOSS content (packages/license) is known\\ | + | * SP3.2.3 Supplier FOSS obligations are satisfied |
| - | Supporting practices:\\ | + | - SP3.3 FOSS records are maintained //(JL: move up in list here)// |
| - | SP3.1 Code audits/scans are conducted\\ | + | - **G4: FOSS content is reviewed and approved** |
| - | SP3.2 Supplier compliance is managed\\ | + | - SP4.1 OSRB exists and is staffed appropriately |
| - | -SP3.2.1 Supplier compliance practices are assessed\\ | + | - SP4.2 Planned FOSS use is reviewed in context |
| - | -SP3.2.2 Supplier FOSS disclosures are made and reviewed\\ | + | - SP4.3 License obligations are identified, understood, and documented |
| - | -SP3.2.3 Supplier FOSS obligations are satisfied\\ | + | - SP4.4 Issues are resolved and approval decisions are followed |
| - | SP3.3 FOSS records are maintained\\ | + | - **G5: FOSS obligations are satisfied** |
| - | + | - SP5.1 Documentation obligations are met | |
| - | G4: FOSS content is reviewed and approved\\ | + | - SP5.2 Source code obligations are met |
| - | Supporting practices:\\ | + | - SP5.3 Community interface exists |
| - | SP4.1 OSRB exists and is staffed appropriately\\ | + | * SP5.3.1 Email and postal addresses work |
| - | SP4.2 Planned FOSS use is reviewed in context | + | * SP5.3.2 Web portal works |
| - | SP4.3 License obligations are identified, understood, and documented\\ | + | * SP5.3.3 Community requests and inquiries are satisfied |
| - | SP4.4 Issues are resolved and approval decisions are followed\\ | + | - **G6: Community <del>contributions are encouraged</del> engagement is understood** |
| - | + | - <del>SP6.1: Individual contributions are reviewed and approved</del> | |
| - | G5: FOSS obligations are satisfied\\ | + | - <del>SP6.2: Company contributions are reviewed and approved</del> |
| - | Supporting practices:\\ | + | - __SP6.1: Community participation is reviewed and approved.__ |
| - | SP5.1 Documentation obligations are met\\ | + | |
| - | SP5.2 Source code obligations are met\\ | + | |
| - | SP5.3 Community interface exists\\ | + | |
| - | -SP5.3.1 Email and postal addresses work\\ | + | |
| - | -SP5.3.2 Web portal works\\ | + | |
| - | -SP5.3.3 Community requests and inquiries are satisfied\\ | + | |
| - | + | ||
| - | G6: Community <del>contributions are encouraged</del> engagement is understood\\ | + | |
| - | Supporting Practices:\\ | + | |
| - | <del>SP6.1: Individual contributions are reviewed and approved</del>\\ | + | |
| - | <del>SP6.2: Company contributions are reviewed and approved</del>\\ | + | |
| - | __SP6.1: Community participation is reviewed and approved.__ | + | |
| {{:openchain:g1.jpg|}} | {{:openchain:g1.jpg|}} | ||
| Line 132: | Line 121: | ||
| {{:openchain:g6.jpg|}} | {{:openchain:g6.jpg|}} | ||
| - | |||
| - | |||
| - | |||
| - | |||
| - | |||
| ====== Appendix B ====== | ====== Appendix B ====== | ||
| Line 179: | Line 163: | ||
| Although the SEI originally focused on self-appraisals to encourage frank and confidential internal discussions about improvement needs, eventually many DoD contract sponsors required that bidders provide evidence of (at least) Level 3 maturity. These funding agencies required an appraisal, conducted by a government-approved appraisal team, as part of the award process. | Although the SEI originally focused on self-appraisals to encourage frank and confidential internal discussions about improvement needs, eventually many DoD contract sponsors required that bidders provide evidence of (at least) Level 3 maturity. These funding agencies required an appraisal, conducted by a government-approved appraisal team, as part of the award process. | ||
| - | Over time, the SEI’s model was recognized for the soundness of its software engineering principles and its ability to drive process improvements. A large community of industry and government people coalesced around its guidance. The model itself has continued to evolve and has spawned additional maturity models, as well as a cottage industry of consultants offering appraisal and training services. | + | Over time, the SEI’s model was recognized for the soundness of its software engineering principles and its ability to drive process improvements. A large community of industry and government people coalesced around its guidance. The model itself has continued to evolve and has spawned additional maturity models, as well as a cottage industry of consultants offering appraisal and training [[https://www.linkedin.com/company/redgage-llc | services]]. |
| ==== ISO 9001 ==== | ==== ISO 9001 ==== | ||
openchain/proposed-draft.1422920972.txt.gz · Last modified: 2015/02/02 23:49 by Kellyw
Page Tools
Except where otherwise noted, content on this wiki is licensed under the following license: CC Attribution-Noncommercial-Share Alike 4.0 International
