Tu as perdu quoi ?
Tu as perdu la possibilité de prouver quoique ce soit, puisque sur un OS non temps-réel tu n'as strictement aucune garantie sur la disponibilité des ressources.
Pourquoi tu sous entends que la solution formelle serait moins bonne alors ?
J'ai jamais dis ca, je dis juste que la solution formelle a trop de contraintes fortes et qu'elle n'est pas applicable dans certains cas, auquel cas il faut bien faire une autre forme de test.
Bien sur qu'elle valide les specs !
Si la spec contient une erreur, le fait de formaliser la spec va peut être t'aider à trouver l'erreur, mais en aucun cas la méthode formelle en soit ne garantie que tu vas trouver ces erreurs.
C'est pas parcque tu as réussi à formaliser les specs que les specs sont valides. Ca veut juste dire que l'humain qui les as interprétés n'a pas trouver de problème lors de la formalisation. Si ca se trouve le client c'est mal exprimé et ton logiciel vas pas faire ce qui est prévu, va savoir !
En rédigeant la spec formelle tu identifies immédiatement tous les manques et précision à demander à ton client !
N'importe quoi. Tu peux identifier certains manques et certaines imprécisions, mais tu ne peux pas identifier toutes les erreurs dans les specs. Si la spec dit que le volant doit être dans le coffre de la voiture, c'est peut être tout à fait valide techniquement mais totalement abhérent du point de vue utilisateur. Et là si tu fais pas des tests d'ergonomie...
Quand à demander au client, c'est un doux rêve, souvent le client il veut pas tout formaliser, parcque ca supposerait qu'il réfléchisse sur ses besoins... hors il a en parti fait appel à tes services pour que tu l'aide dans cette tâche de formalisation. C'est con mais c'est comme ca dans la vraie vie, souvent tu te buttes face à un client qui ne veut pas répondre (pas le temps ou ne sais pas trancher) et tu dois faire des choix.
[^] # Re: Se passer des tests ...
Posté par TImaniac (site web personnel) . En réponse au journal La preuve de programme : où en est-on ?. Évalué à 2.
Tu as perdu la possibilité de prouver quoique ce soit, puisque sur un OS non temps-réel tu n'as strictement aucune garantie sur la disponibilité des ressources.
Pourquoi tu sous entends que la solution formelle serait moins bonne alors ?
J'ai jamais dis ca, je dis juste que la solution formelle a trop de contraintes fortes et qu'elle n'est pas applicable dans certains cas, auquel cas il faut bien faire une autre forme de test.
Bien sur qu'elle valide les specs !
Si la spec contient une erreur, le fait de formaliser la spec va peut être t'aider à trouver l'erreur, mais en aucun cas la méthode formelle en soit ne garantie que tu vas trouver ces erreurs.
C'est pas parcque tu as réussi à formaliser les specs que les specs sont valides. Ca veut juste dire que l'humain qui les as interprétés n'a pas trouver de problème lors de la formalisation. Si ca se trouve le client c'est mal exprimé et ton logiciel vas pas faire ce qui est prévu, va savoir !
En rédigeant la spec formelle tu identifies immédiatement tous les manques et précision à demander à ton client !
N'importe quoi. Tu peux identifier certains manques et certaines imprécisions, mais tu ne peux pas identifier toutes les erreurs dans les specs. Si la spec dit que le volant doit être dans le coffre de la voiture, c'est peut être tout à fait valide techniquement mais totalement abhérent du point de vue utilisateur. Et là si tu fais pas des tests d'ergonomie...
Quand à demander au client, c'est un doux rêve, souvent le client il veut pas tout formaliser, parcque ca supposerait qu'il réfléchisse sur ses besoins... hors il a en parti fait appel à tes services pour que tu l'aide dans cette tâche de formalisation. C'est con mais c'est comme ca dans la vraie vie, souvent tu te buttes face à un client qui ne veut pas répondre (pas le temps ou ne sais pas trancher) et tu dois faire des choix.