1. Software Supportability Analysis
Lesson 7
Software Supportability Analysis

2. 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.

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

4. 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

5. 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

6. 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

7. Topic 2: Overview of
Software Supportability Analysis

8. Everything is Connected
OPERATING
SOFTWARE
HARDWARE
APPLICATIONS
NETWORKS

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

10. Topic 3: Issues Unique to Software

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

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

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

14. The Software Support Activity
Technology Maturation & Risk Reduction  SW
Releases

15. Topic 4: Software Reliability

16. 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

17. 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

18. 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

19. 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

20. 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

21. 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

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

23. 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

24. 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

25. 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

26. 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

27. 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.

28. 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

29. 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?

30. 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

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

32. 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 %: 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% % % % % % % % % %
Percent Funding

33. Topic 5: Exercise

34. 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

35. Topic 6: Summary

36. 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

37. 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