Dois-je écouter mon employeur et utiliser les outils CASE?

Mon employeur (pas un développeur) pense que les outils CASE nous aideront à améliorer notre processus de développement et notre documentation. Je ne suis pas sûr de cela, nous sommes une petite équipe de 5 développeurs qui construisent des solutions bancaires mobiles pour les clients locaux. Je pense que les outils CASE seront une perte de temps et d'argent car ils doivent être achetés et nous aurons besoin de temps avant de nous habituer à eux et d'être efficaces avec eux pour la modélisation et d'autres choses. La génération de code est un autre problème, je pense vraiment que le code généré par CASE ne sera pas aussi bon que le code écrit par de bons développeurs.

Je pense que si nous respectons les principes agiles, les modèles de conception, utilisons TDD et gardons notre code propre. nous devrions être bons. Et en ce qui concerne l'analyse et la conception, je pense que de simples diagrammes UML sur tableau blanc devraient faire l'affaire. La documentation est bonne et importante, mais doit être faite le moins possible et nous ne devons pas nous concentrer sur les documents et oublier le code. C'est ce que je pense.

Ai-je raison? ou devrais-je écouter mon employeur et commencer à rechercher un outil CASE approprié?

La situation justifie une approche analytique de la décision. L'essentiel sera "L'outil CASE apporte-t-il une valeur à l'entreprise?" Souvent, la direction voudra que les développeurs adoptent une méthodologie ou un outil car ils ont entendu de bonnes choses à ce sujet, quelle que soit leur adéquation avec les processus et la culture actuels de l'organisation.

Si votre employeur vous a demandé de vous pencher sur les outils CASE, comme le souligne ChrisF, vous devriez obliger (il s'agit d'un problème en milieu de travail, pas de programmation). Certains facteurs qui pourraient affecter l'adoption d'un outil CASE comprennent:

• Pour quels processus existe-t-il des outils CASE,
• Une estimation du nombre d'heures-personnes nécessaires pour adopter le ou les nouveaux outils,
• Comment le ou les processus évolueraient-ils avec l'adoption du ou des nouveaux outils,
• ou Quel type d'impact positif (ou négatif) serait mesurable en adoptant le ou les nouveaux outils

Considérez cela comme une opportunité de mettre à niveau votre environnement et vos processus de développement. Il se peut que vos processus actuels correspondent parfaitement à la culture de votre organisation, mais vous devez à votre employeur et à votre équipe de faire les recherches appropriées.

Oui, vous devriez commencer à rechercher des outils CASE.

1. Parce que vous avez besoin de preuves pour étayer votre affirmation selon laquelle elles n'aideront pas. Vous ne savez jamais, vous pourriez trouver qu'ils vous aideront.
2. Parce que votre employeur vous l'a dit.

Je ne répéterai pas les points exposés par David Kaczynski dans son excellente réponse car ce sont exactement les étapes que vous devez suivre.

Cela semble être un grand changement de paradigme en effet de Agile vers un développement orienté CASE / MDA avec génération de code. Pas nécessairement du point de vue de la gestion de projet (une approche CASE n'entrera pas en conflit avec les concepts d'itérations, de témoignages d'utilisateurs, de rétroaction rapide ou d'amélioration continue), mais certainement du point de vue de "l'artisanat logiciel" - cela signifie moins de contrôle sur le code produit, du code généré qui sera probablement illisible, rigide, plus difficile à tester, nécessitant constamment une synchronisation avec le modèle, etc.

D'après ce que vous décrivez, ce dont votre employeur a besoin est facilement compréhensible:

• Meilleure documentation afin d'éviter la perte de connaissances si un développeur devait quitter l'équipe.
• Un processus de développement plus rapide.

En tant que professionnel du logiciel, vous pouvez (et devriez) certainement lui faire part de vos doutes sur la capacité de l'approche CASE à répondre à ces attentes. Il est également de votre devoir de commencer à regarder les outils CASE s'il le demande. Le simple fait d'essayer l'un d'entre eux ne signifie pas 1 / que les résultats seront satisfaisants (je pense en particulier aux frais généraux potentiellement importants de génération de code qui entrent en conflit avec la nécessité de se développer plus rapidement) et 2 / que vous ne pouvez pas trouver un compromis où certaines fonctionnalités de l'outil CASE (diagrammes, génération de documentation) seront utilisées tout en préservant le contexte agile existant.

Voici un article intéressant sur les outils CASE dans un environnement Agile et leurs avantages / inconvénients possibles: http://www.agilemodeling.com/essays/simpleTools.htm

Mon employeur (pas un développeur) pense que les outils CASE nous aideront à améliorer notre processus de développement et notre documentation. "

Si je devais agir en tant que consultant pour votre employeur, je serais obligé de tenter de les dissuader de ce genre de chose. Tout d'abord, c'est une erreur de gestion majeure que des personnes non impliquées dans le travail choisissent des outils pour les développeurs. Cela ne se passe presque jamais bien. C'est au moins deux fois plus mauvais lorsque les personnes qui font le choix n'ont pas une solide formation technique. Et s'ils n'ont aucune expérience avec les outils qu'ils poussent, ce sera probablement une débâcle totale.

La raison la plus probable pour laquelle ce genre de chose est suggéré par la direction non technique est que quelqu'un essaie de leur vendre quelque chose. Une grande entreprise qui vend ce genre de choses a des revenus qui tombent comme un zeppelin en plomb dans l'air raréfié. Les vendeurs (alias revendeurs, consultants) qui ne sont pas passés à autre chose essaient follement de trouver de nouvelles marques, euh ... des clients. L'une des principales raisons pour lesquelles ces entreprises éprouvent des difficultés est qu'il n'y a plus beaucoup de demande pour ce type d'outils. Par «ce genre d'outils», j'entends des outils qui promettent «d'éliminer l'écriture de code». Il n'y a rien de mal avec le code, selon la langue. Le code écrit a des abstractions beaucoup plus puissantes que ce que ces outils offrent.

L'une des principales raisons pour lesquelles c'est une si mauvaise façon de gérer le développement est qu'il réduira considérablement le bassin de personnes dont vous pourrez vous servir pour doter votre équipe. D'une part, ils doivent apprendre ces outils rares et, d'autre part, la plupart des développeurs expérimentés ne veulent pas travailler avec ces choses. Souvent, l'argument autour de ces types d'outils est que vous n'avez pas vraiment besoin de bons développeurs, car ces outils font la plupart des tâches lourdes. C'est complètement faux. C'est le contraire. Ils font toutes les choses triviales et rendent souvent plus difficile la réalisation des parties non triviales. Ils n'éliminent également jamais vraiment le besoin d'écrire du code.

Plus précisément avec les outils CASE, j'ai travaillé dans trois endroits différents qui possédaient ces packages. Dans chacun d'eux, cela se passait comme suit:

1. Le modèle a été minutieusement conçu dans l'outil. Cela a pris beaucoup plus de temps que la normale et aucun produit livrable utilisable n'a été produit jusqu'à très tard dans l'effort.
2. Le modèle devait être complété par une logique métier. Le modèle était erroné et a dû être modifié manuellement pendant les dernières phases du projet car l'effort était tellement en retard.
3. La resynchronisation du modèle et du code était tellement coûteuse que l'outil CASE était abandonné, pour ne plus jamais être utilisé.

En un mot, c'était un échec total à 100% et un gaspillage d'argent dans chaque cas. Lorsque j'ai parlé à d'autres personnes qui ont utilisé les outils CASE dans d'autres organisations, l'histoire est toujours la même. Je n'ai pas utilisé tous ces outils et il est possible que certaines personnes en aient fait bon usage mais je suis assez certain que la plupart des équipes qui les ont utilisées ont cessé de les utiliser depuis longtemps.

L'un des avantages que vous retireriez de l'étude / de la mise en œuvre des outils CASE est que vous aurez acquis un ensemble de compétences plus commercialisables pour un emploi futur. Je pense que bon nombre de vos préoccupations sont importantes, mais, comme l'a souligné David Kaczynski, il ne s'agit pas tant d'une question de programmation que d'une question de relation employeur-employé. Un autre avantage des outils CASE est qu'une fois appris, votre entreprise sera en mesure de prendre en charge un éventail plus large de projets de plus grande complexité. Il se peut très bien qu'un contrat que votre employeur cherche à obtenir nécessite ou privilégie l'utilisation des outils CASE.

Vous mélangez le problème et la solution et votre patron essaie d'aider, avec plus ou moins de succès. Pour défier votre patron, vous devez savoir clairement quel est votre rôle dans l'organisation. S'il est le PDG et que vous êtes le CTO, la décision vous appartient et le PDG devrait simplement indiquer quels aspects commerciaux sont affectés par le manque de documentation. Votre obligation sera alors de résoudre le problème métier, avec un outil CASE ou toute autre solution que vous en sortirez.

En ce qui concerne la suggestion spécifique d'utiliser les outils CASE, je pense que vous devez la choisir correctement afin d'atteindre votre objectif sans surcharger votre équipe de travail supplémentaire. Si vous voulez améliorer la documentation, vous en aurez peut-être assez avec un outil capable de générer des diagrammes à partir du code, pas nécessairement de générer le code à partir du diagramme graphique. Un exemple d'un tel outil est Codelogic . J'ai utilisé il y a quelques années pour m'assurer que nos conceptions étaient propres et claires pour être comprises et qu'elles étaient assez faciles à utiliser. Si comme vous exprimez de l'argent est une autre préoccupation, vous pouvez probablement regarder dans l'open source (je ne peux pas aider ici mais je serais intéressé par le résultat de toute recherche).

L'alternative aux outils CASE peut également aider. Mesurer des choses comme des mesures cyclomatiques ou d'autres mesures de complexité gardera votre conception bien structurée et les développeurs concentrés sur le code. De meilleurs commentaires sur votre code, de type Javacode, peuvent également aider à améliorer la documentation.

Honnêtement, je pense que si vous considérez que les outils CASE n'aident pas, votre patron doit le savoir. S'il est un bon patron, il appréciera votre opinion. Je n'ai jamais aimé un employé qui fait juste ce qu'on lui dit sans analyse critique. Mais bien sûr, comme le suggère David, toute discussion doit se tenir sur des arguments solides et objectifs.

J'essaierais de faire comprendre à votre employeur qu'il / elle a fait reculer les choses. S'il y a une marge d'investissement pour l'équipe logicielle, vous devez identifier vos goulots d'étranglement ou vos problèmes de qualité. S'il s'avère que vous avez le plus de marge d'amélioration dans les domaines du processus de documentation et de développement, vous devez identifier les changements qui ont le plus grand retour sur investissement en ce qui concerne l'amélioration de ces domaines. Cela pourrait ou non se révéler commencer à utiliser les outils CASE.

Aidez votre patron, aidez-vous

Vous pouvez réagir ou agir sur cette demande.

Vous vous souvenez de toutes les questions «Déplacer le mont Fuji»? Si vous étiez dans une interview pour un emploi que vous vouliez vraiment, vous ne diriez pas à l'enquêteur à quel point la question était stupide, mais vous continueriez à poser des questions et à exprimer vos meilleures idées pour la résoudre. Dans certaines cultures, vous ne diriez jamais non à un boss qui vous a réellement demandé de déplacer le mont Fuji, mais trouveriez un moyen pour vous de sauver la face.

Recadrage de la question

Si vous deviez recadrer la question en quelque chose comme,

"Puis-je acheter ou acquérir une suite d'outils qui automatisent autant de tâches à faible productivité liées aux logiciels que possible?"

cette affectation devient beaucoup plus agréable au goût. Aidez votre patron (et vous-même) en lui donnant une option avec une traçabilité claire vers CASE, et une ou deux options basées sur le Agile / open source / cloud.

CAS REVISITÉ

Dans les années 90, les outils CASE pouvaient prendre la forme d'une suite d'outils de Rational qui comprenait probablement Requisite Pro, Rational Rose, Clear Case, Rational Robot (un testeur), Purify, Pure Coverage et Quantify, et plusieurs autres outils qui ont été intégrés ensemble. Si vous étiez un magasin MAD (médical, avionique, défense), vous pourriez utiliser des versions mises à jour de ces outils pour produire une documentation et des artefacts étendus et traçables qui sont souvent requis par les clients de ces marchés.

Contactez IBM et demandez à un vendeur de fournir un devis pour cinq licences (ou une seule licence flottante). Ajoutez également une formation. Partager cette citation avec votre responsable peut mettre fin aux discussions sur les outils CASE. Mais ne vous méprenez pas. J'aime Rational, leurs chefs scientifiques et leurs produits, mais je les ai principalement consultés via des licences de site universitaire parce que leur prix était trop élevé pour les entreprises dans lesquelles j'ai travaillé. Si vous êtes approuvé, du moins d'après mon expérience, ils traiteront votre droit avec un bon soutien, une formation de qualité (généralement dans un hôtel de premier ordre avec une excellente cuisine).

Outils à vendre

Vous avez toujours une excellente occasion de faire des achats d'outils. Les développeurs agiles ont également besoin d'outils. Vous pouvez acheter une suite qui vous offre un support de documentation pour les cartes d'histoires en ligne, les cas d'utilisation, les cas d'utilisation et d'autres types de diagrammes UML. Atlassian a ce que je pense être une belle suite d'outils - Jira pour le suivi des tâches et des bogues, Green Hopper pour ce qu'ils décrivent comme la gestion de projet Agile, Confluence pour un wiki intranet, Crucible pour la révision de code en ligne et Bamboo pour un serveur d'intégration continue. Il existe des licences de logiciel en tant que service pour ces suites d'outils et d'autres destinées à vos besoins si vous êtes Agile.

L'intégration IDE est un autre moyen d'obtenir un équivalent CASE pour l'année 2012. Si vous êtes une maison de développement Microsoft, Visual Team Studio dispose d'outils de portée similaire à celle créée par Rational. Ils ont une ingénierie logicielle aller-retour, la génération de talons de test unitaires à partir des classes, l'intégration avec les systèmes de contrôle de source et un tas d'outils pour la collaboration d'équipe.

Outils Open Source

Côté open source, Eclipse et ses nombreux plug-ins essaient d'intégrer un tas d'outils open source. Je ne sais pas si Eclipse Modeling Framework est mature ou s'il existe d'autres outils qui donnent un ingénieur logiciel aller-retour efficace, mais la dernière fois que j'ai regardé, cela ne semblait pas très facile à réaliser. L'environnement Qt Creator s'intègre au contrôle de code source et possède certaines fonctionnalités pour vous aider à effectuer une vérification ponctuelle à partir de la couverture du code des modifications lorsque vous êtes dans l'éditeur.

Adoption d'outils incrémentiels itératifs

Une approche itérative / incrémentielle de la sélection d'outils peut également être très efficace. Les projets open source prennent souvent en charge des environnements uniques ou multiples. Vos choix d'outils peuvent être influencés par les piles que vous utilisez. Il n'y a jamais de bon moment pour arrêter complètement le développement, donc ajouter et former l'équipe à quelques petits outils par trimestre peut être mieux qu'une approche big bang qui change tout à la fois.

Solutions d'outils cloud

La plupart des solutions répertoriées peuvent nécessiter des serveurs et une configuration relativement complexe. Il existe de nombreuses options sur le marché qui sont basées sur le cloud et fournissent un logiciel en tant que service hébergé par un fournisseur moyennant des frais mensuels. Cela peut avoir du sens pour votre équipe, à court ou à long terme. Certains peuvent avoir une solution hébergée que vous pouvez utiliser pour un démarrage rapide, avec la possibilité d'acheter des licences plus tard.

Aucune de ces suggestions n'est un moyen facile et peu coûteux d'améliorer instantanément la productivité, mais si vous pouvez trouver certains des outils indispensables une fois que vous les avez essayés.

Une chose que j'ajouterais aux excellentes réponses ici est que vous pourriez gagner à comprendre comment vous voulez "améliorer votre processus de développement".

La tendance écrasante au cours des 20 dernières années a été d'optimiser le développement de logiciels pour le temps de mise sur le marché. "Agile", "lean", DevOps, TDD, BDD - il s'agit de faire sortir un logiciel de qualité le plus rapidement possible.

Les outils CASE ne sont pas une question de délai de commercialisation. Ils se concentrent sur la traçabilité, la cohérence de la conception, l'exhaustivité du modèle, etc. Ce sont tous des aspects précieux - en particulier dans les systèmes bancaires - mais ils se font au détriment du temps de mise sur le marché.

Alors, demandez peut-être à votre patron exactement ce qu'il essaie d'optimiser.

Par expérience, travailler avec les outils CASE devient rapidement plus difficile que de travailler avec du code - en particulier lorsque vous travaillez avec des domaines problématiques qui sont plus que moyennement complexes. Le projet cesse d'être un projet "bancaire" et devient un projet "insert-name-of-CASE-tool-here".