A018 - CDRL Metrics.docx
DOCX document 19 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 A018. Contractor format may be used so long as all information required is provided.
| Measure |
| Purpose |
| Sample Questions Addressed |
| CDRL |
Milestone Dates
| The Milestone Dates measure consists of the start and end dates for software activities and events. The measure provides an easy to understand view of the status of scheduled software activities and events. Comparison of planned and actual milestone dates provides useful insight into both significant and repetitive schedule slips at the activity level. |
| - Is/Was the schedule realistic? |
- How often is/was the schedule changed?
- Are critical tasks or delivery dates slipping?
- CSPEI
Requirements Traced
| The Requirements Traced measure counts the percentage of SCRs that have been successfully traced to software design components. The measure addresses the degree to which specified requirements have been incorporated in the software design. |
| - Have all SCRs been traced to software design components? |
- CSPEI
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?
- CSPEI
| Effort |
| The Effort measure counts the number of hours of effort applied to software tasks. This measure should include both estimated and actual hours for every SCR included in a given release. This measure usually correlates directly with software cost, but can also be used to address other common information categories including Schedule and Progress. |
| - Is/Was effort expended according to plan? |
- Do/Did certain tasks or activities taking more/less effort than expected?
- Is/Was the effort profile realistic?
- CSPEI
SCR Baseline
| The SCR Baseline measure enumerates the number of SCRs in the baseline for a given delivery, and the number of these SCRs that were added, modified, or deleted during the delivery cycle. The measure provides information on the total number of requirements and the development risk due to volatility in requirements or functional growth. |
| - Have the SCRs allocated to each delivery cycle changed? |
- Are SCRs being deferred to later builds?
- How much has software functionality changed? What components have been affected the most?
- CSPEI
| Source Lines of Code |
| The Source Lines of Code measure counts the number of lines of code in the software. The number of lines of code is not in itself a particularly useful metric. What is useful is the trend analysis that can be performed using lines of code. The measure shall include a breakdown of lines added, modified, and deleted. The measure shall also include auto generated code, scripts, and configuration files required for product operation. |
| - Is the product code base growing or shrinking? |
- Is the rate of change consistent and predictable?
- Is there a correlation between requirements growth, lines of code growth, and defect rates?
- 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? |
| - CSPEI |
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?
- CSPEI
Deficiency Report Aging
| The Deficiency Report Aging measure reports the length of time that each deficiency report has remained open. The measure is used to determine whether progress is being made in fixing deficiencies. It helps assess whether or not software rework is being deferred. |
| - How long does it take to close a deficiency report? |
- Is the developer closing known deficiencies in a timely manner?
- Are the deficiencies that are more difficult to fix being deferred?
- CSPEI
| Defect Density |
| The Defect Density measure is a ratio of the number of defects written against a component relative to the size of that component. Either a product or function oriented size measure can be used. The measure helps identify components with the highest concentration of defects. These components often become candidates for additional reviews or testing, or may need to be re-written. Trends in the overall quality of a system can also be monitored with this measure. |
| - What is the quality of the software? |
- What components have a disproportionate amount of defects?
- What components require additional testing or review?
- What components are candidates for rework?
- CSPEI
File details come from the government source that posted it. Updated .