Difference between revisions of "Verification Planning"
(New page: == What == ''Verification Planning'' - to plan when, where, by whom and to what extent the developed product should be verified in each timebox Image:Tx_oodocs_3da61a486d.gif =...) |
(→Why) |
||
| (23 intermediate revisions by 2 users not shown) | |||
| Line 2: | Line 2: | ||
== What == | == What == | ||
| − | + | Verification Planning - to plan when, where, by whom and to what extent the developed product should be verified in each timebox. | |
| − | + | ||
| − | - to plan when, where, by whom and to what extent the developed product should be verified in each timebox | + | |
| − | + | ||
| − | + | ||
| − | + | ||
| + | [[Image:VerificationPlanning.png|300px]] | ||
== How == | == How == | ||
| Line 19: | Line 15: | ||
'''Ingredients''' | '''Ingredients''' | ||
| − | * | + | * Development strategy |
| − | * | + | * Test specifications |
| − | * | + | * Verification and acceptance specifications |
* Risk management documents | * Risk management documents | ||
| − | '''Output | + | '''Output artefacts''' |
Test and verification plan | Test and verification plan | ||
| Line 32: | Line 28: | ||
'''Process''' | '''Process''' | ||
| − | When planning the verification activities, you need | + | When planning the verification activities, you need to: |
| − | * | + | * Base the extent of the verification activities on the development strategy and the verification tests |
| − | * | + | * Determine if special activities/tests are required based on the customer's implicit safety requirements or government regulations |
| − | + | * Decide when, where and by whom the different verification disciplines should be performed according to the product verification specification (inspections, reviews and tests) | |
| − | * | + | ** Consider the order of the tests; the order is important as some tests can have a destructive impact on the system if not passed |
| − | * | + | * Book in-house or out-of-house test facilities |
| − | * | + | * Make a detailed test and verification plan for the present timebox as well as a rough plan for the rest of the timeboxes until project completion |
| − | * | + | ** Include the construction of testing facilities (hardware and/or software) in your development plan |
| − | + | * Construct a compliance matrix (a simple table) in which you can easily state compliance (or not) with all the specific requirements, one by one, during your subsequent verification activities. | |
| − | + | ||
| − | + | ||
| − | + | ||
== Why == | == Why == | ||
| − | In each timebox, during and after the implementation of the product features, it is mandatory to verify that the requirements stated in the Product Accept Specifications document are met. Otherwise, there is no guarantee or documentation | + | In each timebox, during and after the implementation of the product features, it is mandatory to verify that the requirements stated in the [[Product Accept]] Specifications document are met. Otherwise, there is no guarantee or documentation that the product meets the customer's requirements. |
The degree of verification depends on what level of completion the product has. During the implementation of the product, the developer will typically verify important parameters or features several times in each timebox. If the product is a combination of more subsystems (software, hardware and/or mechanics), this continuous verification might be done separately for each subsystem. | The degree of verification depends on what level of completion the product has. During the implementation of the product, the developer will typically verify important parameters or features several times in each timebox. If the product is a combination of more subsystems (software, hardware and/or mechanics), this continuous verification might be done separately for each subsystem. | ||
| Line 54: | Line 47: | ||
After the integration of the subsystems, the developed system should be tested as one unit. | After the integration of the subsystems, the developed system should be tested as one unit. | ||
| − | The degree of the verification is usually large during the final timebox, but much smaller during the earlier timeboxes. | + | The degree of the verification is usually large during the final timebox, but much smaller during the earlier timeboxes. |
| + | |||
| + | |||
| + | For hardware, this is a typical test sequence: | ||
| + | |||
| + | [[Image:HardwareTestSequence.png]] | ||
| + | |||
| + | '''Hardware test sequence''' | ||
| + | |||
| + | |||
| + | For software, the typical sequence looks like this: | ||
| + | |||
| + | [[Image:SoftwareTestSequence.png]] | ||
| + | |||
| + | '''Software test sequence''' | ||
| + | |||
| + | |||
| + | When integrating hardware and software, the typical flow will be like this: | ||
| + | |||
| + | [[Image:VerificationProcess.png]] | ||
| + | |||
| + | |||
| + | '''Hardware and software integration test sequence''' | ||
| + | |||
| + | Note that partially integrated parts may become subject to more integration and subsequently tests as development progress. This is indicated by the dashed arc in the figure above. | ||
| + | |||
| + | The figure is also valid for integration of several hardware parts or several software parts into a more complex part. | ||
== Example == | == Example == | ||
| − | + | [[Image:VerificationPlan.png|600px]] | |
| + | |||
| + | '''Example of an incomplete Verification Plan''' | ||
| + | |||
| + | |||
| + | [[Image:RVTM.png|600px]] | ||
| + | |||
| + | '''Example of a Requirements Verification Traceability Matrix:''' | ||
| − | [[ | + | [[Deployment Planning]] might be the next natural step to take. |
Latest revision as of 09:32, 21 January 2016
What
Verification Planning - to plan when, where, by whom and to what extent the developed product should be verified in each timebox.
How
The dish
Verification Planning
Ingredients
- Development strategy
- Test specifications
- Verification and acceptance specifications
- Risk management documents
Output artefacts
Test and verification plan
Compliance matrix
Process
When planning the verification activities, you need to:
- Base the extent of the verification activities on the development strategy and the verification tests
- Determine if special activities/tests are required based on the customer's implicit safety requirements or government regulations
- Decide when, where and by whom the different verification disciplines should be performed according to the product verification specification (inspections, reviews and tests)
- Consider the order of the tests; the order is important as some tests can have a destructive impact on the system if not passed
- Book in-house or out-of-house test facilities
- Make a detailed test and verification plan for the present timebox as well as a rough plan for the rest of the timeboxes until project completion
- Include the construction of testing facilities (hardware and/or software) in your development plan
- Construct a compliance matrix (a simple table) in which you can easily state compliance (or not) with all the specific requirements, one by one, during your subsequent verification activities.
Why
In each timebox, during and after the implementation of the product features, it is mandatory to verify that the requirements stated in the Product Accept Specifications document are met. Otherwise, there is no guarantee or documentation that the product meets the customer's requirements.
The degree of verification depends on what level of completion the product has. During the implementation of the product, the developer will typically verify important parameters or features several times in each timebox. If the product is a combination of more subsystems (software, hardware and/or mechanics), this continuous verification might be done separately for each subsystem.
After the integration of the subsystems, the developed system should be tested as one unit.
The degree of the verification is usually large during the final timebox, but much smaller during the earlier timeboxes.
For hardware, this is a typical test sequence:
Hardware test sequence
For software, the typical sequence looks like this:
Software test sequence
When integrating hardware and software, the typical flow will be like this:
Hardware and software integration test sequence
Note that partially integrated parts may become subject to more integration and subsequently tests as development progress. This is indicated by the dashed arc in the figure above.
The figure is also valid for integration of several hardware parts or several software parts into a more complex part.
Example
Example of an incomplete Verification Plan
Example of a Requirements Verification Traceability Matrix:
Deployment Planning might be the next natural step to take.
