A008 - CDRL Metrics.docx
DOCX document 16 KB Posted
- Attached to
- Missile Applications Software Support II (MASS II) Federal contract opportunity
- Solicitation number
- FA4600-11-R-0009
About this file
CDRL
View the file
Other files for this federal contract opportunity
Show all 50
Missile Applications Software Support II (MASS II) has more files on GovTribe.
On GovTribe
Work with this file on GovTribe
- Download the original file
- Contacts named in this file
- Similar government files
- Ask GovTribe AI about this file
Text version
Metrics The following table enumerates the set of metrics that shall be delivered as part of the CDRL A008. Contractor format may be used so long as all information required is provided.
| Measure |
| Purpose |
| Sample Questions Addressed |
| CDRL |
Requirements Tested
| The SCRs Tested measure counts the number of SCRs that have been successfully tested. The measure addresses the degree to which required functionality has been successfully demonstrated against the specified requirements as well as the amount of testing that has been performed. This measure provides an excellent measure of test progress. This measure is also known as “Breadth of Testing”. |
| - What SCRs are/were validated by what tests? |
- How many SCRs are/were directly testable?
- Are/Were the SCRs being tested as scheduled?
- Has the testing been successful?
- What requirements (functions) are behind schedule?
- How much of the functionality has been tested?
- Software Test Report (STR)
- CSPEI
Automated Unit Test Coverage
| The Automated Unit Test Coverage measures the percentage of executable code exercised by automated unit test tools. Unit testing is critical to findings defects early in the development cycle. A nonexistent or lightly used unit test regime is indicative of immature software development practices and will likely result in defects being undetected until product integration or deployment. |
| - Are unit tests being developed along with source code? |
| - Software Test Report (STR) |
Deficiency Report Trends
| The Deficiency Report Trends measure quantifies the number, status, and priority of deficiencies reported. For each deficiency identified, the report should indicate at what phase in the development cycle (e.g. code and unit test, integration test) the deficiency was found. It provides very useful information on the ability of a developer to find and fix defects. The quantity of deficiencies reported reflects the amount of development rework (quality). Arrival rates can indicate product maturity (a decrease should occur as testing is completed). Closure rates are an indication of progress and can be used to predict test completion. |
| - How many (critical) deficiency reports have been written? |
- Do deficiency report arrival and closure rates support the scheduled completion date of integration and test?
- How many deficiency reports are open? What are their priorities?
- Software Test Report (STR)
File details come from the government source that posted it. Updated .