Dois-je utiliser des méthodes formelles sur mon projet de logiciel?

Question

Notre client veut construire une application, Internet riche basé sur le Web pour la collecte des exigences logicielles. Fondamentalement, il est un outil de cas basé sur le Web qui suit un processus spécifique pour obtenir les exigences des parties prenantes. Je suis le chef de projet et nous sommes encore dans les premières phases du projet.

J'ai pensé à l'aide de méthodes formelles pour aider à clarifier les exigences de l'outil pour mon client et les développeurs. Par des méthodes formelles, je veux dire une certaine forme de modélisation, peut-être quelque chose de mathématique basée. Certaines des choses que j'ai lu et envisagent comprennent Z ( http://en.wikipedia.org / wiki / Z_notation ), machines d'état, UML 2.0 (éventuellement avec des extensions telles que OCL ), réseaux de Petri , et des trucs au niveau de codage comme les contrats et pré et conditions de poste. Y at-il autre chose que je devrais considérer?

Les développeurs sont expérimentés mais selon le formalisme utilisé, ils peuvent avoir à apprendre un peu de mathématiques.

Je suis en train de déterminer si cela vaut la peine alors que pour moi d'utiliser des méthodes formelles sur ce projet et si oui, dans quelle mesure. Je sais que « ça dépend » si les réponses les plus utiles pour moi est un oui / non et arguments à l'appui.

Voulez-vous utiliser des méthodes formelles si vous étiez sur ce projet?

Answer 1

  

J'ai pensé à l'aide de méthodes formelles pour aider à clarifier les exigences de l'outil pour mon client et les développeurs.

Les développeurs ont très peu d'expérience des méthodes formelles. La seule fois que je l'ai vu des clients avec la formation des méthodes formelles étaient membres du ZUG quand nous PORTAGE CADIX Windows.

  

Par des méthodes formelles, je veux dire une certaine forme de modélisation, peut-être quelque chose mathématiquement basé. Certaines des choses que j'ai lu et envisagent comprennent Z ( http://en.wikipedia.org/ wiki / Z_notation ), machines d'état, UML 2.0 (éventuellement avec des extensions telles que OCL), les réseaux de Petri, et quelques trucs niveau de codage comme les contrats et les conditions pré et post. Y at-il autre chose que je devrais considérer?

Il y a un écart très important entre Z, qui est une méthode formelle, en prenant sa base dans la théorie des ensembles, et UML, qui est une notation informelle avec quelques notations semi-formelles (machines d'état) marqués sur.

Certains clients techniques, comme vous vous attendez à trouver l'aide d'un outil de configuration logicielle, sont tout à fait à l'aise avec UML.

Il peut y avoir valeur la création d'un modèle Z de votre domaine, et il peut être utile dans la création d'un modèle pi-calcul de votre messagerie entre (ou petri-net client et le serveur, mais je trouve pi est à la fois plus simple et plus puissant ).

Quel modèle Z de votre domaine donnerait est une mise en œuvre ensemble indépendant des contraintes de type, exprimé plus fortement que le système de type de tout langage de mise en œuvre commune.

Quel modèle formel de votre messagerie vous donnera est la possibilité de réaliser des analyses pour vous assurer de ne pas perdre des mises à jour ou obtenez des conflits ou des blocages.

Quel modèle UML vous donne est une notation pour briser un grand système en zones de fonction (diagrammes de paquet), de montrer comment les classes dans ces domaines se rapportent les uns aux autres statiquement (diagrammes de classes), de montrer comment les instances de ces classes relier dynamiquement (séquence, l'activité et les diagrammes d'interaction), et en montrant comment les paquets sont déployés (composants et diagrammes de déploiement). Ceux-ci sont utiles pour la communication dans l'équipe, et pour obtenir des idées étoffées un peu, mais ne pas la sémantique formelle définie qui permet une analyse très sophistiquée.

Les spécialistes Z avec lesquels je travaillais dans les années 90 considéré l'idée de spécifier une interface graphique CASE dans Z ridicule. Création d'un modèle UML pour une telle interface graphique est monnaie courante.

Je n'ai pas utilisé les conditions pré et post conception par contrat formel, bien que je ne les ajouter parfois dans les commentaires, et souvent dans les assertions et les conditions de test unitaire I qui pourrait les violer.

Answer 2

La vraie question à se poser ici est pas si les utiliser ou non, mais ce qui est gagné et perdu.

Est-ce que la productivité et les résultats l'emportent sur la complexité et l'apprentissage nécessaire?

Answer 3

En général, vous devez utiliser ce que l'équipe est à l'aise avec. Avec de nouveaux éléments, il va être une courbe d'apprentissage, ce qui signifie qu'il va y avoir des questions sur le processus et des erreurs. Une partie de votre calendrier de développement sera utilisé pour corriger ces problèmes, et si vous ne prévoyez pas les utiliser avec cette équipe à l'avenir, vraiment vous n'allez avoir un gain à long terme en introduisant quelque chose de nouveau. processus de changement prend beaucoup de temps et beaucoup de travail.

Si vous avez assez de temps estimé pour gérer ces problèmes que vous pourriez être ok ..... si votre estimation est correcte. Considérant que vous n'avez pas travaillé avec ces personnes (au moins c'est ce que votre message ressemble), les chances sont de votre calendrier ne va pas être aussi précis comme il se doit ce qui signifie que vous pourriez avoir pas assez de temps alloué pour terminer le projet laisser introduire seul un nouveau processus.

L'autre question que vous devez demander à votre auto est « comment êtes-vous à l'aise avec le processus que vous voulez mettre en œuvre? » Je ne ai jamais essayer de présenter un nouveau processus sur un projet à moins que je sais que je peux tirer l'équipe à travers elle si je dois. Essayer de nouvelles choses de temps en temps est bon, mais vous devez avoir une équipe, vous êtes à l'aise avec savoir comment naviguer sur une situation tendue.

Answer 4

J'ai examiné plusieurs approches de méthodes formelles « légères », pour des applications qui peuvent être essentielles à la mission, mais pas la vie / sécurité critique. Quelques idées:

• alliage
• SysML
• SPIN
• autres ???

Answer 5

Il y a des exemples réussis d'utilisation ACSL (ANSI C Specification Language) qui a mis à maturité des outils dont la plupart sont Open Source tels que la plate-forme Pourquoi, Frama-C. Pour la technologie Java similaire appelé JML (Java Modeling Language). Je pense que les deux sont utilisés pour les petits projets de taille moyenne pour les applications embarquées et ils aident à ajouter des garanties dans votre code, mais ne visent pas à valider les spécifications. Z est absolument pas convivial et manque à mon humble avis de support d'outil adéquat.

Parmi les outils commerciaux qui peuvent être utilisés sur les étapes de spécification je regarderais dans la plate-forme Rodin qui est basée sur la méthode B.

Answer 6

En fin de match ici, mais vous pourriez envisager quelque chose comme l'architecture testable par Savara que nous utilisons pour de nombreux projets dans lesquels il y a une prédominance de la communication ou l'interaction entre les composants. Ceci est le plus souvent vu dans un back-end de SOA à une interface web.

Il est formellement fondé sur pi-calcul et vous n'avez pas besoin de comprendre pi-calcul pour l'utiliser.

Answer 7

Je suis totalement d'accord avec Tom et pose la même question,

Est-ce que la productivité et les résultats l'emportent sur la complexité et l'apprentissage nécessaire?

À mon avis, sauf si le système / logiciel peut être identifié comme « critique pour la sécurité » méthodes formelles ne sont pas nécessaires.

Que signifient de sécurité critiques:

Lorsque la défaillance d'un système informatique peut entraîner des conséquences catastrophiques, comme la perte de la vie humaine, des dommages à l'environnement, ou des dommages au système lui-même, un tel système est connu comme « critique pour la sécurité ».

Answer 8

Je suis d'accord avec Tom et Abufardeh - Est-ce que la productivité et les résultats l'emportent sur la complexité et l'apprentissage nécessaire

?

Aussi, est-ce methd mieux pour obtenir toutes les exigences avant le développement (amd assurer que ces exigences sont à la fois bien définis et testables)? Obtenir tous les requirments d'abord semble que le bon sens, mais un grand pourcentage de programmes font des choses dans la pensée parallèle, il n'y a pas de problème pour obtenir des exigences plus tard. fluage requise est un cauchemar! Le film « Le Pentagone Wars » est une révélation à quelqu'un qui est en désaccord.