![]() |
![]() |
![]() |
|
| Annex 1 | |||
| 5.2 Design Verification |
DVER - Designverifikation
5.2.1 Overview
These methods are presented in the following individual descriptions. In order to make it easier to distinguish between the individual methods these methods are first compared with each other.
The Classical Design Verification is to favor those cases where a refined informal specification already exists, because then it is not necessary to trace the development steps again. Within this method often it is difficult to localize or to correct an error especially in those cases when it is not possible to furnish the proof of the refinement or when it turns out that it is no refinement. Within the Formal Transformation and the Verification during Development every development step is proved immediately. Therefore, an error is easy to correct, but it may be difficult to comprehend again the design decisions of an already existing informal specification. The proof tasks within the Formal Transformation are the slightest because of the proofs having generally been proved already. On the other hand, it is difficult to provide a complete set of transformation rules necessary for the refinement step.
| Classical Design Verification | Verification during Development (Design Verification) | Formal Transformation (Design) |
|---|---|---|
| Great effort for the proof | Great effort for the proof | Comparatively small effort for the proof, because the rules have already been proven but the development may require a long time |
| Easy to achieve consistency relating to the informal specification already in existence | Comparatively difficult to achieve consistency relating to the informal specification already in existence | Difficult to achieve consistency relating to the informal specification already in existence |
| Set of rules generally sufficient | Set of rules generally sufficient | Set of rules generally only sufficient for limited problems |
| Possible to test the specification prior to the proof | Not possible to test the specification before | Not possible to test the specification before |
| Later verification possible | Later verification not possible | Later verification not possible |
| Error detection possibly difficult; possibly work has to be started again | Error detection simple, because every design step is immediately proven; possibly only the last step has to be modified | In practice errors not possible, because only correct transformations are performed |
5.2.2 Individual Descriptions
![]() |
![]() |
GDPA Online
Last Updated 01.Jan.2002
Updated by Webmaster
Last Revised 01.Jan.2002
Revised by Webmaster
![]() |