1 / 22

TRANSITION OF SOFTWARE TO A HIGHER CLASSIFICATION PROCESS TRAINING

TRANSITION OF SOFTWARE TO A HIGHER CLASSIFICATION PROCESS TRAINING. Process for incorporating existing software products that were developed at a given classification into systems that require a higher classification. Agenda. Software Processes. The SEPG has developed the following processes:

Gabriel
Download Presentation

TRANSITION OF SOFTWARE TO A HIGHER CLASSIFICATION PROCESS TRAINING

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. TRANSITION OF SOFTWARE TO A HIGHER CLASSIFICATION PROCESS TRAINING Process for incorporating existing software products that were developed at a given classification into systems that require a higher classification

  2. Agenda

  3. Software Processes The SEPG has developed the following processes: • GRC-SW-7150.3 - Software Project Planning • GRC-SW-7150.4 - Software Project Monitoring and Control • GRC-SW-7150.5 - Requirements Development • GRC-SW-7150.6 - Requirements Management • GRC-SW-7150.7 - Managing the Measurement of Software Process and Product • GRC-SW-7150.8 - Performing the Measurement of Software Process and Product • GRC-SW-7150.9 - Software Configuration Management • GRC-SW-7150.10 - Transition SW to a Higher Class • GRC-SW-7150.12 - Formal Inspection and Peer Review • GRC-SW-7150.13 - Process and Product Quality Assurance • GRC-SW-7150.14 - Software Acquisition SOW Guideline • GRC-SW-7150.15 - Software Acquisition Planning • GRC-SW-7150.16 - Software Estimating • GRC-SW-7150.17 - Software Safety Planning These are available on Software@Glenn.

  4. Planning and Monitoring Formal Inspection and Peer Review may be used on the Software Management Plan, the NPR 7150.2A Compliance matrix, and the Monthly Master Spreadsheet. Project planning also invokes Software Assurance activities.

  5. Software Documentation Templates The SEPG has developed the following document templates: • GRC-SW-TPLT-SMP - Software Management Plan Template • GRC-SW-TPLT-SRS - Software Requirements Specification Template • GRC-SW-TPLT-RTM - Requirements Traceability Matrix Template • GRC-SW-TPLT-SCMP - Software Configuration Management Plan Template • Software Change Request/Problem Report (needs updating) • GRC-SW-TPLT-MMMS - Master Monthly Metrics Spreadsheet • GRC-SW-TPLT-SDD - Software Design Description Template • GRC-SW-TPLT-IDD - Interface Design Description Template • GRC-SW-TPLT-STP - Software Test Plan Template • GRC-SW-TPLT-STPr - Software Test Procedure Template • GRC-SW-TPLT-STR - Software Test Report Template • GRC-SW-TPLT-SVD - Software Version Description Template • GRC-SW-TPLT-SUM - Software Users Manual Template • GRC-SW-TPLT-SMntP - Software Maintenance Plan Template (needs updating) • GRC-SW-TPLT-SAP - Software Assurance Plan Template • GRC-SW-TPLT-SSP - Software Safety Plan Template These are available on Software@Glenn. They are Word documents except for the Master Monthly Metrics SS.

  6. Transition of Software to a Higher Classification Purpose This process was developed to assist projects that are considering incorporating software products that were developed with a certain classification into systems that require a higher classification They are intended to assist the project in determining whether to use previously developed software, and if so, to provide steps to take to ensure that software and its documentation conform to the requirements of the higher classification Use this process in the software project planning phase when a project may benefit by reusing previously developed software products

  7. Using the Transition of Software to a Higher Classification Process Usage (1 of 2) This process applies to open source, reuse, legacy, and heritage software products. • Open source software excluded This process does not apply to the release of software. This process applies to software developed on another project as well as the current project. If the classification of the transitioning software is unknown, it must still meet the project’s classification requirements. This process assumes that the project has already defined its requirements and plans to a sufficient level to allow a software product to be considered for use at a higher classification.

  8. Using the Transition of Software to a Higher Classification Process Usage (2 of 2) Classifications are per NPR 7150.2A • A, B, C, D, E – Scientific and Engineering • F, G, H – Business and Desktop This process assists a project in meeting SWE-021 of NPR 7150.2A: • If a system or subsystem evolves to a higher software classification as defined in Appendix E, then the project shall update its plan to fulfill the added requirements per the Requirements Mapping Matrix in Appendix D.

  9. Transition of Software to a Higher Classification Process Flow Risks too high? No Yes No Yes Risks too high? No Yes

  10. Transition of Software to a Higher Classification Process Overview (1 of 5) • 6.1 Software proposed for reuse • The Software Project Lead may consider assessing the software product against the Reuse Readiness Levels • 6.2 Recover artifacts of the software • Implements SWE-027 b (COTS, GOTS, MOTS, reused, or open source software component includes documentation to fulfill its intended purpose) • 6.3 Determine additional NPR 7150.2A requirements • This applies to the software proposed in 6.1 • The project has NPR 7150.2A requirements levied on it based on the software classification • 6.4 Determine documentation needed • Evaluate the state of the artifacts from 6.2

  11. REUSE READINESS LEVELS

  12. Transition of Software to a Higher Classification Process Overview (3 of 5) • 6.5 Evaluate the software’s ability to meet the project’s technical requirements • 6.6 Determine risk to project • If the risk is too great, stop this process, don’t use the software • If the risk is acceptable, continue with the process • Consider maintainability, reliability, tool availability, compilers, licenses, operating system requirements, amount of changes needed • 6.7 Document requirements and code performance. Test code and evaluate test results. • Implements SWE-027 a (COTS, GOTS, MOTS, reused, or open source software component requirements are identified)

  13. Transition of Software to a Higher Classification Process Overview (4 of 5) • 6.8 Determine risk to project based on test results • If the risk is too great, stop this process, don’t use the software • If the risk is acceptable, continue with this process • 6.9 Enter software code and artifacts into Configuration Management (CM) system • 6.10 Ensure project addresses transition and integration of software • Plan for usage, integration, future support • Implements SWE-027 d (future support for COTS, GOTS, MOTS, reused, or open source software component is planned) • 6.11 Develop required documentation • Both technical and non-technical documentation • May use existing documentation; update as necessary

  14. TRANSITION OF SOFTWARE TO A HIGHER CLASSIFICATION PROCESS Overview (5 of 5) • 6.12 Determine if software to be used as is • If so, skip to 6.14 • If not, continue with the next step • 6.13 Modify software per project needs • Also perform unit tests • 6.14 Perform integration testing • Ensure the code works according to project needs • Implements SWE-027 e (COTS, GOTS, MOTS, reused, or open source software component verified and validated to the same level as developed software)

  15. TRANSITION OF SW TO A HIGHER CLASSIFICATION NPR 7150.2A REQS SWE-013: The project shall develop software plan(s). Note: The requirement for the content of each software plan (whether stand-alone or condensed into one or more project level or software documents) is defined in Chapter 5. These include, but are not limited to: • Software development or management plan. • Software configuration management plan. • Software test plans. • Software maintenance plans. • Software assurance plans. Note: Software engineering and the software assurance disciplines are integrally related and yet each has its own responsibilities. Jointly they are responsible for providing project management with the optimal solution for software to meet the engineering, safety, quality, and reliability needs of the project. This necessitates a close working relationship to assure the appropriate levels of effort for both. See NASA-STD-8739.8 for more details on development of a software assurance plan.

  16. TRANSITION OF SW TO A HIGHER CLASSIFICATION NPR 7150.2A REQS SWE-021: If a system or subsystem evolves to a higher software classification as defined in Appendix E, then the project shall update its plan to fulfill the added requirements per the Requirements Mapping Matrix in Appendix D.

  17. TRANSITION OF SW TO A HIGHER CLASSIFICATION NPR 7150.2A REQS SWE-027(1 of 3): The project shall ensure that when a COTS, GOTS, MOTS, reused, or open source software component is to be acquired or used, the following conditions are satisfied: • The requirements that are to be met by the software component are identified. • The software component includes documentation to fulfill its intended purpose (e.g., usage instructions). • Proprietary, usage, ownership, warranty, licensing rights, and transfer rights have been addressed. • Future support for the software product is planned. • The software component is verified and validated to the same level of confidence as would be required of the developed software component.

  18. TRANSITION OF SW TO A HIGHER CLASSIFICATION NPR 7150.2A REQS SWE-027(2 of 3): Note: The project responsible for procuring off-the-shelf software is responsible for documenting, prior to procurement, a plan for verifying and validating the off-the-shelf software to the same level of confidence that would be needed for an equivalent class of software if obtained through a "development" process. The project ensures that the COTS, GOTS, MOTS, reused, and open source software components and data meet the applicable requirements in this NPR assigned to its software classification as shown in Appendix D.

  19. TRANSITION OF SW TO A HIGHER CLASSIFICATION NPR 7150.2A REQS SWE-027(3 of 3): Note: For these types of software components consider the following: a. Supplier agreement to deliver or escrow source code or third party maintenance agreement is in place. b. A risk mitigation plan to cover the following cases is available: • Loss of supplier or third party support for the product. • Loss of maintenance for the product (or product version). • Loss of the product (e.g., license revoked, recall of product, etc.). c. Agreement that the project has access to defects discovered by the community of users has been obtained. When available, the project can consider joining a product users group to obtain this information. d. A plan to provide adequate support is in place; the plan needs to include maintenance planning and the cost of maintenance. e. Documentation changes to the software management, development, operations, or maintenance plans that are affected by the use or incorporation of COTS, GOTS, MOTS, reused, and legacy\heritage software. f. Open source software licenses review by the Center Counsel.

  20. Transition of Software to a Higher Classification Tools and Forms Available from Software@Glenn • GRC-SW-7150.10 Transition of Software to a Higher Classification Proces • Reuse Readiness Levels (coming soon) • GLPR 7150.1A GRC Software Engineering Requirements Available from NASA Engineering Network • https://nen.nasa.gov/web/nen/home • Click on Communities->Software Engineering • NPR 7150.2A Handbook • https://nasa7150.onconfluence.com/display/7150/Home • See topic 7.14, Transitioning to a Higher Class 10/21/2019 20

  21. Feedback on Transition of Software to a Higher Classification Processes, checklists, templates and forms available at Software@Glenn: http://software.grc.nasa.gov To ask questions • Joe Ponyik, x8592 We value your feedback • The feedback form is on the Feedback page of Software@Glenn. • Send the feedback form to grc-sepg-lead@lists.nasa.gov. • Group feedback sessions available upon request. • Based on feedback, the process will be updated. • The updated process will be made available on Software@Glenn. Share your products as examples for future projects! Post them on 21

  22. Questions???

More Related