"Qu'est ce qu'un spec (bon, ça je sais, mais ça fait pas de mal de le rappeler)"
Un ensemble de paragraphe avec parfois, plusieurs couches, pour "raffiner" les exigences. Dans la pratique, les exigences sont très bas niveau pour faciliter la traçabilité avec le code. Vu que les traçabilités multiples sont interdites (on peut lié plusieurs requirement à un même bout de code, un bout de code à plusieurs requirement, mais pas plusieurs bout de code à plusieurs requirement, car les matrices de traçabilité qui servent à vérifier que l'on n'oublie rien, deviennent inutile).
"À quoi ça ressemble (idem)"
[PLOP_123]
blablabla shall blablabla
"Comment vérifier qu'une spec est complète (si possible?)"
A la main, avec des fiches de relecture prévu par un plan (document également à écrire).
"Comment vérifier qu'un code correspond à la spec"
Avec les tests, qui sont censé être écrit uniquement par rapport à la spec, en utilisant le code comme une boite noire. On vérifie aussi la traçabilité du code avec la spec : rien ne doit venir de null part, aucune spec doit être oublié.
"Comment générer des tests qui vérifient la spec"
En général, les tests générés sont interdis. Le but est de faire de la vérification croisé, si c'est généré, il n'y a rien de vérifié de façon croisé.
La façon la plus simple de faire les tests est de faire un modèle de tests (oui on recode une 2ième fois tout, plus le programme est gros et plus on gagne du temps au final). Le modèle de test et le code doivent avoir les mêmes sorties. En théorie, on doit pouvoir générer les entrées automatiquement en utilisant la couverture de code du modèle de teste. La comparaison des sorties peut aussi être automatique.
Dans la pratique, on écrit tout à la main, avec des bout de modèle pour générer les sorties attendues.
"Quels sont les outils utilisés"
Un peu de tout :) On peut aussi utiliser des outils qualifié pour la vérification. L'idée est de pouvoir se passe d'étape de revu manuel. Un outil de vérification est plus facile à qualifier car il ne génère rien pour le projet. Cela peut être très utile.
"Des exemples"
http://dnlcenter.esterel-technologies.com/index.php cf les handbook/white paper de ma boite ? :) Oui, c'est un peu de pub et oui, il demande de créer un compte pour y avoir accès, mais il n'y a pas de confirmation.
[^] # Re: Dépêche ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Reqflow. Évalué à 1.
"Qu'est ce qu'un spec (bon, ça je sais, mais ça fait pas de mal de le rappeler)"
Un ensemble de paragraphe avec parfois, plusieurs couches, pour "raffiner" les exigences. Dans la pratique, les exigences sont très bas niveau pour faciliter la traçabilité avec le code. Vu que les traçabilités multiples sont interdites (on peut lié plusieurs requirement à un même bout de code, un bout de code à plusieurs requirement, mais pas plusieurs bout de code à plusieurs requirement, car les matrices de traçabilité qui servent à vérifier que l'on n'oublie rien, deviennent inutile).
"À quoi ça ressemble (idem)"
[PLOP_123]
blablabla shall blablabla
"Comment vérifier qu'une spec est complète (si possible?)"
A la main, avec des fiches de relecture prévu par un plan (document également à écrire).
"Comment vérifier qu'un code correspond à la spec"
Avec les tests, qui sont censé être écrit uniquement par rapport à la spec, en utilisant le code comme une boite noire. On vérifie aussi la traçabilité du code avec la spec : rien ne doit venir de null part, aucune spec doit être oublié.
"Comment générer des tests qui vérifient la spec"
En général, les tests générés sont interdis. Le but est de faire de la vérification croisé, si c'est généré, il n'y a rien de vérifié de façon croisé.
La façon la plus simple de faire les tests est de faire un modèle de tests (oui on recode une 2ième fois tout, plus le programme est gros et plus on gagne du temps au final). Le modèle de test et le code doivent avoir les mêmes sorties. En théorie, on doit pouvoir générer les entrées automatiquement en utilisant la couverture de code du modèle de teste. La comparaison des sorties peut aussi être automatique.
Dans la pratique, on écrit tout à la main, avec des bout de modèle pour générer les sorties attendues.
"Quels sont les outils utilisés"
Un peu de tout :) On peut aussi utiliser des outils qualifié pour la vérification. L'idée est de pouvoir se passe d'étape de revu manuel. Un outil de vérification est plus facile à qualifier car il ne génère rien pour le projet. Cela peut être très utile.
"Des exemples"
http://dnlcenter.esterel-technologies.com/index.php cf les handbook/white paper de ma boite ? :) Oui, c'est un peu de pub et oui, il demande de créer un compte pour y avoir accès, mais il n'y a pas de confirmation.
"La première sécurité est la liberté"