140 likes | 330 Views
Code 300 Overview Code 320: Software Assurance (soon to be Software Assurance Office – 320.1). Susan Sekira Software Assurance Lead 301-286-6160 Susan.J.Sekira@nasa.gov. Software Assurance Overview.
E N D
Code 300 OverviewCode 320: Software Assurance(soon to be Software Assurance Office – 320.1) Susan Sekira Software Assurance Lead 301-286-6160 Susan.J.Sekira@nasa.gov
Software Assurance Overview Software Assurance is an umbrella risk identification and mitigation strategy for safety and mission assurance of all NASA’s software mission of all NASA’s software * Software Quality (SQ) * Software Reliability Verification & Validation (V&V) * Software Safety ** Independent Verification & Validation (IV&V) * Code 300 Disciplines ** Code 180 Discipline
Software Assurance Disciplines • Software Quality: set of activities to assure that quality is built into the software. Assures that the standards, processes, and procedures are appropriate for the project and are correctly implemented • Software Safety:systematic approach to identifying, analyzing, and tracking software mitigation and control or hazards and hazardous function to ensure safer software operation within a system • Software Reliability: derives fault and failure management requirements from software subsystem and component/task level FTA and FMEAs. Optimizes software by requiring and building in software error prevention, fault detection, isolation, and recovery • Verification and Validation: verification ensures that “you built it right” and validation ensures that “you built the right thing” • Independent Verification and Validation: Verification and validation performed by an organization that is technically, managerially, and financially independent. Provides in-depth evaluations of life cycle products that have the highest risk
Benefits of Software Assurance • Strives to improve the quality, safety, and reliability of the product • Focuses on opportunities for early error detection, problem prevention, and risk identification and mitigation • Assures that software meets its specified requirements and conforms to software standards, procedures, and quality requirements • Provides project management insight into the software development processes and products throughout the life cycle Software Assurance The level of Software Assurance should be tailored commensurate with the software classification as well as software size, complexity, criticality, and risk
Core Requirements & Documentation • NPR 7150.2, Software Engineering Requirements • NASA-STD-8739.8, NASA Software Assurance Standard • NASA-STD-8719.13, NASA Software Safety Standard • 320-PG-7120.2.1., Procedure for Developing and Implementing Software Assurance Programs • 320-PLAN-1001, SMA Software Quality Assurance (SQA) Data Management Plan (DMP) • GPR 7150.4, Software Safety and Software Reliability Process • 321-WI-8750.0.1, Software Safety Assessment Process • Software Assurance Work Breakdown Schedule (WBS) • Software Assurance Plan (SAP) Template
Software Assurance Staffing • Code 300 Software Assurance (SA) is performed by Software Assurance Engineers (SAEs), Project Safety Managers (PSMs), and Software Reliability Engineers in the Mission Assurance Division • SA personnel are matrixed to projects and maintain a level of independence • Software Assurance follows the CMMI model • The Chief Safety and Mission Assurance Officers (CSOs) and/or SA Lead determine the amount of software assurance to be applied to each project commensurate with the software’s size, complexity, classification and safety criticality assessment • Currently 23 Software Assurance personnel supporting 20 GSFC projects with Class B software • 4 Civil Servants – includes a Software Assurance Lead and Software Reliability Lead • 19 Contractors
Key Software Quality Activities Software Quality • Conduct an Independent Software Classification • Perform periodic audits of the Provider’s processes to the Provider’s process requirements (e.g., CMMI focus areas such as configuration management, requirements management, project planning) • Perform periodic audits of the Provider’s products to the Provider’s requirements (e.g., Software Management Plan, requirements traceability matrix, version description document) • Review test plans and test procedures; witness qualification and acceptance tests • Ensure that test suites, simulators, models, and test data are ready for use and under configuration control • Evaluate tools and facilities for adequacy and feasibility • Review software nonconformances, issues, and risks
Key Software Safety Activities Software Safety • Identify safety critical software • Evaluate identified hazards associated with a specific requirement, design concept and/or operation to determine if software is a contributor to hazard causes, controls, or mitigations • Integrate software hazard analyses into system safety analyses • Trace software safety requirements to system safety requirements and hazards • Assure that all software safety requirements, design features, and methods have been correctly implemented into the design and code • Verify that the design and code prevents, controls, or mitigates identified hazards
Key Software Reliability Activities Software Reliability – a Qualitative Approach • Understand how mission critical software is allocated to flight and ground systems • Review software architecture and design documentation for details related to Hardware/Software interfaces and software workflows related to mission critical functions • Evaluate system specifications for reliability requirements, as derived by the Fault Tree Analysis (FTA) and Failure Modes and Effects Analysis (FMEA) • Review reliability analyses to ensure that software is accounted for and that faults and failures are accurately characterized • Support verification and validation of mission critical software through software peer reviews and witnessing test execution
Key Software V&V Activities Software V&V • Ensure preparation, maintenance, and implementation of the SW V&V Plan • Ensure test plans and reports are correct and complete (e.g., includes goals, scope, processes used, test facilities, resources, and regression testing) • Verify that requirements are valid, unambiguous, correct, complete, consistent, operationally and technically feasible, and verifiable • Verify that nonconformances/deficiencies occurring during testing are recorded, tracked, and closed • Ensure software meets the requirements through test, analysis, and/or inspection • Verify that safety-critical software nonconformances are traced back to the system-level hazards
SummaryKeys to Success • Securing sufficient funding from projects to successfully implement software assurance • Supporting projects early on in the life cycle (i.e., Phase A) • Ensuring flow-down of software assurance requirements in proposals • Ensuring consistency in software assurance activities and their implementation across all projects • Educating the GSFC community on SA roles, responsibilities, and customer expectations • Maintaining a collaborative and ongoing relationship with Software Engineering and mission projects - COMMUNICATION
Software Classification Summary Class A Human Rated Space Software Systems Class B Non-Human Space Rated Software Systems Class C Mission Support Software or Major Engineering/Research Facility Software Class D Basic Science/Engineering Design and Research and Technology Software Class E Small Light Weight Design Concept and Research and Technology Software Class F General Purpose Computing Software (Multi-Center or Multi-Program/Project) Class G General Purpose Computing Software (Single Center or Project) Class H General Purpose Desktop Software GSFC Software Assurance focuses on Classes A through C software
Safety-Critical Software Criteria(via the Litmus Test) • Resides in a safety-critical system (as determined by a hazard analysis) AND at least one of the following apply: (1) Causes or contributes to a hazard (2) Provides control or mitigation for hazards (3) Controls safety-critical functions (4) Processes safety-critical commands or data (5) Detects and reports, or takes corrective action, if the system reaches a specific hazardous state (6) Mitigates damage if a hazard occurs (7) Resides on the same system (processor) as safety-critical software • Processes data or analyzes trends that lead directly to safety decisions • Provides full or partial verification or validation of safety-critical systems, including hardware or software subsystems