Exh C CDRL Matrix.docx
DOCX document 20 KB Posted
- Attached to
- FA4600-11-R-0012 NIDS III A011
- Solicitation number
- FA4600-11-R-0012
About this file
NIDS III Exhibit C CDRL Matrix
View the file
Other files
Show 40 more
Latest 50 of 61 listed here. See the rest on GovTribe.
On GovTribe
Work with this file
- Download the original file
- Contacts named in this file
- Similar government files
- Ask GovTribe AI about this file
Text version
Exhibit C: Metrics The following table enumerates the set of metrics that shall be delivered as part of the listed CDRLs. Contractor format may be used so long as all information required is provided.
| CDRL |
| Measure |
| Purpose |
| Sample Questions Addressed |
| CDRL |
| A002 |
| 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?
- Integrated Master Schedule (IMS)
| A006 |
| 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 Plan (STP)
| A006 |
| 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 Plan (STP) |
| A008 |
| 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
| A008 |
| 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) |
| A008 |
| 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)
| A009 |
| 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. Specifically, break out the estimate/actual hours to be used/used for coding. 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?
- Software Version Description (SVD)
| A012 |
| 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?
- Monthly Report
| A015 |
| 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? |
- Software Design Description (SDD)
| A018 |
| 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
| A018 |
| 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
| A018 |
| 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
| A018 |
| 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
Sec J, Exh C
File details come from the government source that posted it. Updated .