Software Supportability Analysis Lesson 7 Software Supportability Analysis

Topic 1: Introduction What’s in it for me? Software Supportability Analysis reflects the unique circumstance of developing and maintaining software in the current technological environment where obsolescence drives both system hardware and software requirements, functionality and interoperability. Software is a major driver of system requirements and costs as most systems have some type of embedded software or rely on software for its functionality. Software Supportability Analysis employs many of the same tools and processes as “Hardware” Supportability Analysis, to include Reliability Modeling Allocation and Prediction, Failure Mode, Effects and Criticality Analysis (FMECA) and Fault Tree Analysis (FTA), as well as Reliability Growth. Current Reliability & Maintainability (R&M) prediction best practices combine hardware and software predictions to determine the total effect of the loss of functionality on performance, sustainment and cost.

Technology Refreshment Life Cycle Management Framework Where Are You? What Influence Do You Have? Technology Maturation & Risk Reduction  AoA TDS PDR ISD Technology Refreshment

Technical Performance Affordable System Operational Effectiveness ASOE Model 1 The ASOE model has four distinct intersections representing impacts of trade-offs on program performance and Sustainment objectives. Balancing these priorities require a series of trade-off analyses. 2 3 Technical Performance Supportability Process Efficiency Life Cycle Cost Functions Reliability Production Total Ownership Cost Capabilities Maintainability Maintenance Support Features Logistics Operations 1 Design Affordability Design Effectiveness 2 Mission Effectiveness 3 Affordable System Operational Effectiveness

Software Supportability Lesson Approach This lesson approach emphasizes the iterative nature of Software Supportability Analysis throughout the entire life cycle. Determine user requirements, obsolescence, configuration management Analyze support, manpower, maintenance, training, etc. Provide data to other reports and create Software Supportability Activity

TLO: Conduct Software Supportability Analysis Topic 1: Introduction Welcome Where Are You? What Influence Do You Have? Topic 2: Overview of Software Supportability Analysis Relate Software Supportability Analysis to Supportability and Supportability Analysis Topic 3: Issues Unique to Software Examine Software Supportability Analysis Topic 4: Software Reliability Compare the information identified through the Software Supportability Analysis with the data contained in the Logistics Product Data/Database Analyze the impact of Software Supportability Analysis on system design and Product Support Topic 5: Exercise Conduct a Software Supportability Analysis on a Strike Talon system or subsystem Topic 6: Summary

Topic 2: Overview of Software Supportability Analysis

Everything is Connected OPERATING SOFTWARE HARDWARE APPLICATIONS NETWORKS

Impacts of Changes Updates Hardware Policy Training Support Manuals Cost Schedule Support Changes to Software Update Analyze Impacts

Topic 3: Issues Unique to Software

Hardware vs. Software Change a physical component – swap out parts Change software – rewrite lines of code

Other Issues Unique to Software Who owns data rights? COTS vs GFI/GOTS vs Custom

Other Issues Unique to Software Ensure operability under limited rollouts Software life cycle is typically 6-18 months

The Software Support Activity Technology Maturation & Risk Reduction  SW Releases

Topic 4: Software Reliability

Software Reliability - Set Up 1.1 1.2 1.3 Build Plan Perform Research Define R&M Data Inputs Iterate Plan Find Similar System Data Collect /Load Tech Data Find R&M Tools Our planning considers : 1.1 Project Management – Identify milestone events, required deliverables, responsibilities and face-to-face updates 1.2 Market Research – Identifies similar system and collects their reliability & maintainability allocations; finds appropriate analysis and modeling tools 1.3 Data Management – Identifies available system design and requirements data, and priority of use

Software Reliability – Build Plan Technology Maturation & Risk Reduction  AOA TDS PDR ISD 1 Understand and Communicate User Needs & Constraints 2 Design – Test - Design . 3 Produce Affordable Operationally Effective System Grow Reliability 4 Monitor Field Performance

Software - Iterate Plan Design Test Design Hardware is developed as Test - Analyze - And - Fix (TAAF) Software is developed as a continuously iterative process: Design -Test - Design

Perform Research/Find Similar System Data Research for software can include: Reused software Reused code COTS/GOTS/NDI Customer Profile User Profile System-mode Profile Data from reused software is only valid if the component’s historical profile is consistent with the new profile. Functional Profile Operational Profile Test Selection Operational Profile Development

Find R&M Tools Some of the tools that run specific tests on software include: Automatic Test Generation Model J Unit Defect Tracking Bugzilla Test Coverage Evaluation xSuds GUI Testing WinRunner

CSCIs break down into Computer Software Units. Define R&M Data Inputs Systems break down into component units called Computer Software Configuration Items (CSCI). CSCIs are always assigned to the hardware item on which they run. Hardware Operating System CSCI COTS/Reuse CSCI Custom CSCI CSU CSU CSU CSCIs break down into Computer Software Units. CSU CSU CSU

Collect/Load Tech Data Update SAE GEIA-STD-0007 Logistics Product Data using the hardware items TPMs Hardware Testability Traceability

Software R&M Analysis Our analysis consists of four main areas: 2.1 Modeling – Create a functional representation of the system and its subsystems 2.2 R&M Allocation – Assign specific reliability goals or metrics to each hardware/software system or subsystem. 2.3 Prediction – Apply metrics to the goals of the project to predict the failure rate of the software 2.4 FTA/FMECA – Identify primary tools used in software for safety analyses 2.1 2.2 2.3 2.4 Modeling Allocation Prediction FTA/FMECA Iterative Analysis

Software Reliability Modeling Each hardware/software element is decomposed into a reliability block diagram. Software Configuration Item Hardware Configuration Item Non-Developmental Software Newly Developed Software An example reliability model structure for an Anti-lock Brake System: Brakes Decision Controls Reliability Block Diagram PROM HW Subsystem Operating System Software Pressure Sensor HW Subsystem SW Subsystem HW/SW Subsystem HW Subsystem

Software Reliability Allocation Like software design, software Reliability allocation is an iterative process. As development proceeds, more data becomes available and metrics become more accurate and meaningful. Collect Data Historical and Current Data Use Metrics Fault Content Metric Values Predict Initial Failure Rate Failure Rate Predict Growth Model Parameters Estimate time and resources

Software Reliability Prediction Total defects Time Effort Rayleigh Curve “Crash” curve Normal curve Collect Data Use Metrics Predict Initial Failure Rate Predict Growth Model Parameters The Rayleigh Curve: Each dash represents a design-test-design event Used to plot effort against time Area under the curve is total number of defects Estimate Time and Resources

Software Fault Tree Analysis/Failure Mode, Effects, and Criticality Analysis FTA precedes FMECA in software analyses. FTA focuses on functional or operational process failures and the possible CSCIs that could have caused it. FMECA looks at failure of sections of code not a physical system.

Software FTA A software FTA (SFTA) starts with a hazard or failure and traces it back to a set of possible causes. Each possible cause is a failure of a CSCI. Each CSCI is also linked with the hardware component on which it runs. Function or Process Unintended Function CSCI Reliability Block Diagram Hardware

Software Failure Mode, Effects, and Criticality Analysis FMECA Analysis Define Functions End Item Effects Define Functional Failures System Hardware CSCI Failure Mode Effects Analysis Next Level Effects Identify Failure Modes & Causes Local Effects Determine System Effects Criticality Analysis Determine Criticality How severe are the effects on the system? What is the probability of the failure - Frequency?

Update R&M Data/Report Findings Identify Design Opportunities Our analysis findings fall into two broad categories: 3.1 Update R&M Data/Report Findings – Revise/add data in R&M Table U of the Logistics Product Database, RAM-C Rationale Report, Testing and Evaluation Management Plan, Software Engineering Plan and the Life Cycle Sustainment Plan 3.2 Identify Design Opportunities – Provide investment recommendations to IPT to meet requirements, improve design and Supportability 3.1 3.2 Update R&M Data/Report Findings Identify Design Opportunities

Update Data/Report Findings IPT Communication Paths Software Supportability Analysis Product Support Package

Identify Opportunities - Trade-off AO vs. Cost Criteria 85% Availability is the knee of the curve 80% Availability is reached here Ao Availability AO vs. Cost has a steep slope between 0 - 80%: good return on investment in Availability After 85% the AO vs. Cost curve flattens out; this represents the knee of the curve - buying a single percent of Availability beyond the knee costs many times more than before this point. This knee is the point of diminishing return on Availability investment. Cost Task Duration (Min) 10% 20% 30% 40% 50% 60% 70% 80% 90% 100% Percent Funding

Topic 5: Exercise

Time: 15 minutes Group Activity What are the Software Supportability implications of implementing a software redesign for Strike Talon’s targeting and control system? In Blackboard, select the Exercise link in the Lesson 7 folder. Discuss the exercise in your group for 10 minutes Brief the class on your answers Time: 15 minutes Group Activity

Topic 6: Summary

Takeaways Software Supportability Analysis is an iterative process. It is performed through the entire Life Cycle Management Framework. Software, hardware, and networks are all interconnected. A change to one means a potential change to the rest. Software is modeled first, creating the CSCIs and RBDs, which are the basis for all software testing and metrics. Plan for obsolescence. A software life cycle is typically 6-18 months. OPERATING SOFTWARE HARDWARE APPLICATIONS

TLO: Conduct Software Supportability Analysis Topic 1: Introduction Welcome Where Are You? What Influence Do You Have? Topic 2: Overview of Software Supportability Analysis Relate Software Supportability Analysis to Supportability and Supportability Analysis Topic 3: Issues Unique to Software Examine Software Supportability Analysis Topic 4: Software Reliability Compare the information identified through the Software Supportability Analysis with the data contained in the Logistics Product Data/Database Analyze the impact of Software Supportability Analysis on system design and Product Support Topic 5: Exercise Conduct a Software Supportability Analysis on a Strike Talon system or subsystem Topic 6: Summary