book

Improving Product Reliability and Software Quality, 2nd Edition

by Mark A. Levin, Ted T. Kalal, Jonathan Rodin

May 2019

Intermediate to advanced

456 pages

14h 27m

English

Wiley

Read now

Unlock full access

Quality versus ReliabilityGaining Competitive Advantage

1.1 Rapidly Shifting Challenges for Hardware Reliability and Software Quality1.2 Gaining Competitive Advantage1.3 Competing in the Next Decade – Winners Will Compete on Reliability1.4 Concurrent Engineering1.5 Reducing the Number of Engineering Change Orders at Product Release1.6 Time‐to‐Market Advantage1.7 Accelerating Product Development1.8 Identifying and Managing Risks1.9 ICM, a Process to Mitigate Risk1.10 Software Quality OverviewReferencesFurther Reading
2.1 Lack of Understanding2.2 Internal Barriers2.3 Implementing Change and Change Agents2.4 Building Credibility2.5 Perceived External Barriers2.6 Time to Gain Acceptance2.7 External Barrier2.8 Barriers to Software Process Improvement
3.1 Why Things Fail3.2 Parts Have Improved, Everyone Can Build Quality Products3.3 Hardware Reliability and Software Quality – The New Paradigm3.4 Reliability vs. Quality Escapes3.5 Why Software Quality Improvement Programs Are UnsuccessfulFurther Reading
4.1 Hiring Consultants for HALT Testing4.2 Outsourcing Reliability Testing4.3 Using Consultants to Develop and Implement a Reliability Program4.4 Hiring Reliability Engineers
5.1 Six Phases of the Product Life Cycle5.2 Risk Mitigation5.3 The ICM Process for a Small Company5.4 Design Guidelines5.5 WarrantyFurther Reading
6.1 The Bathtub Curve6.2 Mean Time between Failure6.3 Warranty Costs6.4 Availability6.5 Reliability Growth6.6 Reliability Demonstration Testing6.7 Maintenance and Availability6.8 Component Derating6.9 Component UpratingReferenceFurther Reading
7.1 Benefits of FMEA7.2 Components of FMEA7.3 Preparing for the FMEA7.4 Barriers to the FMEA Process7.5 FMEA Ground Rules7.6 Using Macros to Improve FMEA Efficiency and Effectiveness7.7 Software FMEA7.8 Software Fault Tree Analysis (SFTA)7.9 Process FMEAs7.10 FMMEA
8.1 The HALT Process8.2 Highly Accelerated Stress Screening (HASS)8.3 HALT and HASS Test Chambers8.4 Accelerated Reliability Growth (ARG)8.5 Accelerated Early Life Test (ELT)8.6 SPC Tool8.7 FIFO ToolReferencesFurther Reading
9.1 Setting Software Quality Goals9.2 Software Metrics9.3 Lines of Code (LOC)9.4 Defect Density9.5 Defect Models9.6 Defect Run Chart9.7 Escaped Defect Rate9.8 Code CoverageReferencesFurther Reading
10.1 Root Cause Analysis10.2 The 5 Whys10.3 Cause and Effect Diagrams10.4 Pareto Charts10.5 Defect Prevention, Defect Detection, and Defensive Programming10.6 Effort EstimationReferenceFurther Reading
11.1 Waterfall11.2 Agile11.3 CMMI11.4 How to Choose a Software Life CycleReferenceFurther Reading
12.1 Gathering Requirements12.2 Documenting Requirements12.3 Documentation12.4 Code Comments12.5 Reviews and Inspections12.6 Traceability12.7 Defect Tracking12.8 Software and Hardware IntegrationReferencesFurther Reading
13.1 Lack of Commitment to the Reliability Process13.2 Inability to Embrace and Mitigate Technologies Risk Issues13.3 Choosing the Wrong People for the Job13.4 Inadequate Funding13.5 Inadequate Resources13.6 MIL‐HDBK 217 – Why It Is Obsolete13.7 Finding But Not Fixing Problems13.8 Nondynamic Testing13.9 Vibration Testing Too Difficult to Implement13.10 The Impact of Late Hardware or Late Software Delivery13.11 Supplier ReliabilityReferenceFurther Reading
14.1 Purchasing Interface14.2 Identifying Your Critical Suppliers14.3 Develop a Thorough Supplier Audit Process14.4 Develop Rapid Nonconformance Feedback14.5 Develop a Materials Review Board (MRB)14.6 Counterfeit Parts and Materials
15.1 Staffing for Reliability15.2 The Reliability Lab15.3 Facility Requirements15.4 Liquid Nitrogen Requirements15.5 Air Compressor Requirements15.6 Selecting a Reliability Lab Location15.7 Selecting a Halt Test ChamberReference
16.1 Staffing for Reliability16.2 Staffing for Software Engineers16.3 Choosing the Wrong People for the Job
17.1 Reliability Is Everyone's Job17.2 Formalizing the Reliability Process17.3 Implementing the Reliability Process17.4 Rolling Out the Reliability Process17.5 Developing a Reliability Culture17.6 Setting Reliability Goals17.7 Training17.8 Product Life Cycle Defined17.9 Proactive and Reactive Reliability ActivitiesFurther Reading
18.1 Reliability Activities in the Product Concept Phase18.2 Establish the Reliability Organization18.3 Define the Reliability Process18.4 Define the Product Reliability Requirements18.5 Capture and Apply Lessons Learned18.6 Mitigate Risk
19.1 Reliability Activities in the Design Concept Phase19.2 Set Reliability Requirements and Budgets19.3 Define Reliability Design Guidelines19.4 Revise Risk Mitigation19.5 Schedule Reliability Activities and Capital Budgets19.6 Decide Risk Mitigation Sign‐off Day19.7 Reflect on What Worked Well
20.1 Product Design Phase20.2 Reliability Estimates20.3 Implementing Risk Mitigation Plans20.4 Design for Reliability Guidelines (DFR)20.5 Design FMEA20.6 Installing a Failure Reporting Analysis and Corrective Action System20.7 HALT Planning20.8 HALT Test Development20.9 Risk Mitigation MeetingFurther Reading
21.1 Design Validation21.2 Using HALT to Precipitate Failures21.3 Proof of Screen (POS)21.4 Highly Accelerated Stress Screen (HASS)21.5 Operate FRACAS21.6 Design FMEA21.7 Closure of Risk IssuesFurther Reading
22.1 Unit Tests22.2 Integration Tests22.3 System Tests22.4 Regression Tests22.5 Security Tests22.6 Guidelines for Creating Test Cases22.7 Test Plans22.8 Defect Isolation Techniques22.9 Instrumentation and LoggingFurther Reading
23.1 Using Defect Model to Create Defect Run Chart23.2 Using Defect Run Chart to Know When You Have Achieved the Quality Target23.3 Using Root Cause Analysis on Defects to Improve Organizational Quality Delivery23.4 Continuous Integration and TestFurther Reading
24.1 Accelerating Design Maturity24.2 Reliability Growth24.3 Design and Process FMEAFurther Reading
25.1 Managing Obsolescence25.2 Product Termination25.3 Project AssessmentFurther Reading
26.1 Design for Ease of Access26.2 Identify High Replacement Assemblies (FRUs)26.3 Wearout Replacement26.4 Preemptive Servicing26.5 Servicing Tools26.6 Service Loops26.7 Availability or Repair Time Turnaround26.8 Avoid System Failure Through Redundancy26.9 Random versus Wearout FailuresFurther Reading
A.1 Reliability ConsultantsA.2 Graduate Reliability Engineering Programs and Reliability Certification ProgramsA.3 Reliability Professional Organizations and SocietiesA.4 Reliability Training ClassesA.5 Environmental Testing ServicesA.6 HALT Test ChambersA.7 Reliability WebsitesA.8 Reliability SoftwareA.9 Reliability Seminars and ConferencesA.10 Reliability Journals
MTBF, FIT, and PPM ConversionsMean Time Between Failure (MTBF)Estimating Field Failures

Content preview from Improving Product Reliability and Software Quality, 2nd Edition

11Software Life Cycles

Software development is inherently iterative. Unlike hardware, software is never complete. As soon as a version of software is released, the developers start working on the new features and bug fixes for the next version of that software. All of the software development life cycles recognize this fact. The various life cycles primarily only differ in the duration of each iteration. Some life cycles favor short and frequent iterations. Other life cycles favor longer duration iterations. Within those iterations, most of the life cycles basically perform the same kinds of development and verification activities.

The following sections cover the two most common software development life cycles: waterfall and Agile. There is also a section describing Capability Maturity Model Integration (CMMI), which is a framework for determining the effectiveness of a set of processes that make up a software life cycle.

11.1 Waterfall

The waterfall model, sometimes referred to as the classic model for software development, was introduced in the 1970s. A waterfall starts at a higher level and flows downstream. The waterfall model for software development emulates a waterfall; it is a cascade of linear software processes. It starts with system‐level requirements that flow down to software requirements, followed by software design, software implementation, software integration, acceptance testing, software release, and software maintenance. A waterfall only flows down, it ...