Développeur
8 Mai, 2020
Le responsable du développement d’applications, Darroll Walsh, partage une introduction au développement CMMI pour les développeurs.
Le modèle de maturité des capacités intégré (CMMI) est un programme d’amélioration et d’évaluation des processus qui s’intègre à d’autres programmes d’amélioration des processus tels que le Project Management Body of Knowledge (PMBOK) et Agile. Il s’agit de rationaliser et de normaliser tous les processus et de fournir un moyen d’avoir une surveillance et des mesures exploitables pour le développement, les Services, la Gestion des fournisseurs, la Cyber Maturité, etc.
Ce que je veux faire, c’est donner un aperçu du développement CMMI du point de vue d’un développeur. Nous sauterons les parties gestion de projet, analyste commercial, gestion de la configuration et test de CMMI DEV pour nous concentrer sur l’impact de CMMI sur une équipe de développement. S’il y a un intérêt pour les autres rôles ou capacités, cela peut être un bon sujet pour une entrée de blog ultérieure. Notez simplement qu’il y a beaucoup de travail qui se passe avant que les développeurs ne se lancent, même dans le développement Agile.
Commençons:
Le BRS, ou Spécification des exigences métier, est là où tout commence, c’est la source unique de vérité. C’est là que les exigences commerciales que le propriétaire du produit signe. Bien que les développeurs puissent être consultés sur la création du BRS, c’est principalement la responsabilité des BA. Cependant, c’est là qu’un développeur peut vraiment connaître l’application qu’il développe; un endroit pour avoir une vue d’ensemble.
Conceptions de haut et de bas niveau est la documentation d’architecture qui montre comment les composants de l’application sont connectés. Dans la conception de haut niveau, nous exposerions les dépendances externes et la manière dont les utilisateurs et / ou les systèmes interagiront avec notre système. La conception de bas niveau exposerait la façon dont les composants internes interagissent les uns avec les autres. L’examen de ceux-ci donnerait à un autre développeur une compréhension très rapide du fonctionnement de l’application.
Le SRS, ou Spécification des exigences logicielles, est l’endroit où le développeur documente la façon dont l’application va être construite. C’est là que les services sont documentés, que les dépendances sont définies et, en général, comment le code est censé fonctionner, en fonction du BRS créé. Cela se fait généralement avant l’écriture du code et constitue une tâche standard. Je sais que certains se demandent pourquoi nous aurions besoin de faire cela. Mon code s’auto-documente. Et même si j’en suis sûr, le code se propage à travers des centaines de fichiers et des milliers de lignes de code. Et parfois, l’intention n’est pas aussi claire que nous le souhaiterions. Le SRS nous donne un document à examiner avec un aperçu clair de ce à quoi nous pouvons nous attendre. Il décrit les cas d’utilisation et le comportement attendu dans un manoir cohérent.
Après avoir défini ce que nous allons faire, puis écrit le code, il est temps que quelqu’un revoie ce que nous avons fait. Entrez la Révision du code. Ce n’est pas seulement une bonne pratique pour détecter les erreurs et nous assurer que nous suivons les meilleures pratiques et les directives, c’est un excellent moyen de partager ce que fait l’application. Le simple fait de revoir le code par un deuxième regard nous donne une deuxième personne qui connaît le fonctionnement du code. Comme cela est devenu une pratique courante dans la plupart des équipes de développement, je ne vais pas autoriser celui-ci.
Les tests unitaires sont un autre séjour principal de la plupart des programmes de développement. Les tests unitaires, qu’ils soient effectués dans le cadre d’un développement piloté par les tests ou après l’écriture du code, sont l’un des meilleurs moyens de s’assurer que les modifications futures n’introduisent pas d’erreurs dans notre code. Dans un pipeline CI / CD, nous pouvons nous assurer que tous les tests passent avant d’autoriser l’enregistrement du code. Cela nous aide à garder le code en bon état de fonctionnement.
Individuellement, il y a de la valeur dans chaque ensemble de documents ci-dessus, cependant, les gains réels commencent lorsque vous pouvez lier toutes ces informations ensemble. Au début du processus de collecte des exigences, nous commençons une matrice de traçabilité des exigences qui nous permet de lier les exigences métier, les exigences logicielles, le code, les tests unitaires, les plans et cas de test et l’acceptation par l’utilisateur. Imaginez six mois dans un grand projet et un changement provoque l’échec d’un scénario de test. Nous pouvons maintenant revenir aux exigences, découvrir quel est le but de ce code, savoir exactement où se trouve le code pour cette logique, modifier le test unitaire pour attraper le nouveau cas et implémenter un correctif en quelques heures, pas en quelques jours.
À court terme, la CMMI peut sembler exagérée, mais même sur de petits projets, les connaissances capturées en suivant le processus raccourcissent le cycle plus vous êtes loin du projet. Sans oublier si vous n’avez jamais travaillé sur le projet auparavant.
Support développeur
Gestionnaire de compte de Réussite client de Développement d’applications, Support Développeur Microsoft
Suivre