160 likes | 434 Views
Code 300 Overview Code 320: Software Assurance. 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 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) Verification & Validation (V&V) IV&V * Software Reliability * Software Safety * Code 300 Disciplines
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 through 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 Quality Programs • 320-PLAN-1001, SMA Software Quality Assurance (SQA) Data Management Plan (DMP) • 320-PG-7120.2.1C, Overview of Systems Safety Engineering Support to GSFC Greenbelt Flight Projects • 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 • IV&V is performed by personnel from the NASA IV&V Facility (Code 180) in Fairmont, WV • 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 22 Software Assurance personnel supporting 26 GSFC projects with Class B software • 6 Civil Servants – includes a Software Safety Lead and Software Reliability Lead • 17 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., requirements traceability matrix, version description document) • Approve formal test procedures to ensure compliance to the Provider's test plans; witness the qualification and acceptance tests • Ensure that test suites, simulators, models, and test data are ready for use and under configuration control • Identify standards used and verify that standards are being followed • Evaluate tools and facilities for adequacy and feasibility • Review software nonconformances, issues, and risks
Key Software Safety Activities Software Safety • Identify safety critical software via the Litmus test • 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 • Identify safety design features and methods (e.g., inhibits, failure detection and recovery, interlocks, assertions, and partitions) that will be used to implement the software safety requirements • 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 • Perform assurance on the reliability analyses to identify, characterize, and analyze potential faults and failures in the design • Identify methods to detect those faults and failures including the use of redundancy and fault tolerance • Evaluate the software requirements and design to ensure reliability will be built in to the system • Assess project metrics and problem reports for trend/root cause analysis
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