Dashboard
The Dashboard shows the prediction results and predicted reliability growth, and lets you compare predicted values against test and field failure data.
The five Dashboard tabs
What each Predictions button does
Reading the growth buttons
Comparing predictions to real failure data
Import actual test failure data
Used once the software is in a testable state, to compare the machine learning model’s predicted values against actual and trended values from test failure data. The import file template must be used. Tools such as C-SFRAT can trend the actual failure data. The importestimates_template.xlsx provides the required import template. Imported data must come from a test activity, not field use — Requs AI Predict predicts both testing and operational failure rates, and this function compares data against the predicted testing failure rates. The output is an exported spreadsheet plus a predicted-versus-actual graph.
Import actual operational failure data
Works exactly like importing test failure data, but for failure data found in operation. When you click this button, predicted operational failure rates are trended against the actual/estimated operational failure rates.
Finding what’s over- or under-done
Basic sensitivity
Shows the areas — dials on the main page, or tabs on the Survey page — that are either overdone or underdone.
Advanced sensitivity (separately purchased)
A line-by-line view of the most sensitive questions answered negatively. Select a development practice to see the change in defect density — the practice is now set to affirmative in the survey; unclick it to revert. All responses highlighted in yellow have been changed to affirmative. Click a factor and the predicted defect density updates.
The table initially lists factors answered negatively in the Survey tab, and sorts them by 1) minimizing defect density, 2) minimizing development cost, 3) minimizing startup development time — the time it takes a software engineer to integrate the practice, including training and culture change.
Interactive analysis (separately purchased)
Vary defect density, effective size, corrective action hours available in operation and per cycle, cycle time in months, and test hours per cycle. A “cycle” is the time between external releases — with agile development, there may be 3–4 sprints per program increment released, and the time between increments is the cycle time. The initial analysis shows predicted escaped defects over months, contrasted with the interactive escaped-defects view. A third graph shows the interactive analysis of all defects — an estimate of where over the Rayleigh curve the software is likely to be deployed (farther right is preferred). Some sliders affect defect volume; some affect defect spacing. The pie chart shows predicted defects found-in-test-and-fixed, found-in-test-and-not-fixed, found-in-operation-and-fixed, and found-in-operation-and-not-fixed. The per-fault corrective action figure in the top right is the typical time to 1) isolate, 2) repair, 3) check out the repair.
Overkill analysis (separately purchased)
The opposite of Advanced Sensitivity — shows questions answered affirmatively that have the least effect on defect density, considering cost and startup time.