Gestion de configuration la CMM et Gestion de Projet

Gestion de la configuration est une discipline qui est unique à l'entreprise de développer des logiciels n'est donc pas spécifiquement adressée n'importe où dans le PMBOK. Le but de cet article est d'offrir des suggestions sur la façon dont cette discipline peut être incorporé dans vos plans de gestion d'un projet de développement de logiciels avec le moins de perturbations. Bien qu'aucun des éléments de gestion de configuration sont directement traitées dans le PMBOK, vous trouverez que le développement d'un logiciel de n'importe quelle taille est impossible sans des éléments de gestion de configuration. La bibliothèque de source utilisée pour la version du logiciel et la libération est un bon exemple. CMM précise également que l'objectif de gestion de la configuration est de maintenir l'intégrité du logiciel tout au long du cycle du projet de vie du logiciel. Gestion de la configuration sera profitable à l'organisation tout au long du cycle de vie du produit logiciel, d'une durée bien au-delà de la fin du projet qui l'introduit.

En plus d'aider à la CMM / CMMI processus de certification, en respectant les critères fixés pour le niveau 2 de certification dans le domaine de la gestion de la configuration ne sera pas seulement bénéfique à votre projet de logiciel, mais bénéficieront également de futurs projets et aider à l'organisation de soutien la maintenance des produits logiciels produits. Les points traités dans cette série précédemment (gestion des exigences, planification de projet, suivi de projet et la supervision, la gestion de sous-traitance, et l'assurance qualité) sont tous alignés sur certains domaines de connaissances du PMBOK si le respect de ces critères ne devraient pas augmenter considérablement la portée du projet. Les activités requises pour se conformer aux critères CMM CMMI / dans ce domaine pourrait ajouter les frais généraux importants à votre projet. Vous devriez comparer les besoins du projet pour le travail de gestion de configuration contre le travail requis pour répondre CMM / CMMI niveau 2 critères, d'identifier le travail et les outils nécessaires pour traiter le delta et veiller à ce que votre projet soit adéquatement financé et les ressources nécessaires pour entreprendre les travaux supplémentaires .

Comme avec les autres domaines de processus clés (KPA), Gestion de Configuration Logicielle est organisée dans les objectifs, les engagements, les capacités, les activités, mesures, contrôles et vérifications.

Objectifs

   1. activités Logiciel de gestion de configuration sont prévues.
   2. Les produits logiciels sous gestion de configuration sont identifiés, contrôlés, et disponible.
   3. Changements aux produits identifiés sont contrôlés.
   4. Les groupes et les individus soient informés de l'état et le contenu des lignes de base du logiciel.

Ces objectifs seront tous alignés ainsi avec un projet de développement logiciel bien géré. travail de gestion de configuration, comme tous les travaux du projet est prévu, de personnel, et prévu, les changements sont contrôlés par le système intégré de contrôle des changements et le contenu des lignes de base est communiquée aux parties intéressées, conformément au plan de gestion des communications. Gardez à l'esprit que le contexte dans lequel CMM / CMMI utilise le contrôle changement à long terme est spécifique aux produits logiciels sous gestion et nécessitent un outil pour gérer le contrôle de version.

Engagement de réalisation
L'engagement est démontré par la politique écrite de l'organisation pour la gestion de configuration logicielle (GCL). Cette politique doit indiquer qui est responsable de SCM, comment SMC est mis en œuvre par chaque cycle de vie du projet, un outil de la bibliothèque de source est utilisé, et que les lignes de base sont établis et vérifiés régulièrement. La politique sera en place à l'organisation de définir si elle est spécifiée dans le champ d'application de votre projet.

Aptitude à effectuer
Aptitude à effectuer est démontrée par la mise en place d'une Commission des logiciels de contrôle de la configuration (SCCB) et une gestion de configuration logicielle (SCM) du groupe. Le SCCB est chargé d'établir des lignes de base du logiciel, autorisant des modifications aux lignes de base, et de libérer le logiciel. Le groupe SMC est responsable de la mise en œuvre et la gestion de la bibliothèque source et tous les processus de SCM, procédures, normes et plans. En plus de la mise en œuvre de ces 2 groupes, l'organisation est responsable de fournir les ressources et le financement de leurs activités et pour la formation du groupe SCCB, SCM, et le groupe de génie logiciel dans les activités de SCM.

La création du groupe SCCB, SCM, et tous les processus, procédures, plans et normes dont il est ici sera en plus du travail requis pour mettre en place un outil de la bibliothèque de source et d'un bibliothécaire qui sont les besoins minimaux pour le projet de logiciel en moyenne. Ces groupes et de la documentation aura beaucoup de travail à mettre en œuvre et doivent être précisées dans le cadre de la portée du projet si elles sont à entreprendre.

Activités réalisées

   1. Un plan de SMC est préparé pour le projet (et pour chaque projet) conformément à une procédure documentée. Ce plan fera partie du plan du projet et seront utilisés dans le cadre de ce plan pour contrôler les activités SMC pour le projet.
   2. Un système de bibliothèques source est établi. Les critères CMM / CMMI a pour la bibliothèque sont à peu près ce que tout bon outil offrira, à ces exceptions possibles: qui le soutiennent d'archives et la récupération des éléments de configuration et stocker les enregistrements qu'il SMC et créer des rapports SMC.
   3. Les produits de travail logiciel à être placés sous la gestion de configuration sont identifiés. «Produits de travail logiciel" comprennent les postes auxiliaires tels que les documents les besoins d'affaires, spécifications fonctionnelles, documents de conception détaillée, des plans de test, etc identification comprend également un identifiant unique pour chaque objet (ce qui sera appliqué par l'outil de la bibliothèque), la ligne de base auquel il appartient à, et le propriétaire (développeur, analyste, ou de l'analyste).
   4. Les demandes de changement et les rapports de bogues sont enregistrées, examinées, décidée, et suivis selon une procédure documentée. Le système de contrôle intégré des changements a la responsabilité globale de gestion des modifications au projet, y compris les éléments configurables, et le système devrait être décrite dans votre plan de gestion du changement.
   5. Changements aux lignes de base sont contrôlées selon une procédure documentée. La procédure doit garantir que le logiciel est correctement testé lorsqu'il est changé, le SCCB approuve des modifications aux éléments configurables, et que le check-out et check-ins sont effectués correctement (c.-à-contrôlée par la bibliothèque source). La procédure devrait également identifier une demande de modification ou rapport de bug à chaque changement ou fixer. Une façon de faciliter cette activité est d'intégrer votre SCCB et intégrée de contrôle des changements conseils (BICE).
   6. Produits de la bibliothèque source sont créés et leur libération est contrôlée par une procédure documentée. La procédure visée ici est le processus de construction. Le bibliothécaire ou le capitaine doit établir une procédure écrite dont ils suivre pour construire et commercialiser un produit. La procédure devrait inclure des choses telles que quand et comment la bibliothèque est gelé, comment une construction est autorisée (par la SCCB), et lorsque les constructions sont de se produire.
   7. Le statut des éléments configurables sont enregistrées selon une procédure documentée. Cela signifie que l'outil de la bibliothèque de source est en mesure de déclarer la version actuelle de chaque article, récupérer les versions archivées, et la composition de chaque version est connue (les éléments inclus et la version de chaque élément). L'outil de la bibliothèque de source doivent également être capables de faire rapport sur la raison de chaque nouvelle version / mise à jour. Raisons comprendra de nouvelles fonctionnalités, les modifications approuvées, et des corrections de bugs.
   8. Les rapports standard sur les activités de SCM, le contenu de base, etc sont élaborés et mis à la disposition de tous les groupes concernés. Les rapports mentionnés sont non-technique, et comporter des informations telles que les demandes de changement, les rapports de bogues, ainsi que des rapports de synthèse des modifications à chaque base et les résultats d'audit. Ces rapports doivent être décrits dans votre plan de gestion des communications.
   9. audits de base du logiciel sont réalisées selon une procédure documentée. Les vérifications devraient inclure des évaluations de l'intégrité de base, structure de la bibliothèque source, le contenu de base (par souci d'exhaustivité et l'exactitude), et les normes et la conformité des procédures SMC. Les résultats de l'audit doivent être déclarés aux points de chef de projet et d'audit suivies à la clôture. Les vérifications devraient être effectuées par un organisme externe, mais si l'identification de cet organe est un problème; faire le SCCB responsable de l'audit.


Mesure et analyse
Vous êtes tenu de mesurer vos activités SMC. Les mesures comprennent des progrès au plan des activités de gestion de configuration, la performance au budget pour ces articles, ainsi que des indicateurs pour les demandes de changement. En attribuant les membres des différentes équipes travaillant sur les activités de SCM ou SCCB à un groupe SCM ou SCCB vous faciliter l'utilisation de votre fichier MS Project de faire rapport uniquement sur les activités. En divisant le travail dans le fichier MS Project dans différents domaines dont un pour le développement de logiciels, et d'identifier les demandes de changement avec la zone qu'ils effet, vous pouvez isoler SMC changements et de faire rapport à ce sujet.

Vérification et mise en œuvre
SMC activités devrait être revu périodiquement par la haute direction. Aux fins du projet, ces examens peuvent se produire lors des réunions d'examen Gate ou réunions du comité directeur, ou dans des réunions séparées prévue pour la fin. SMC activités devraient également être examinées avec le gestionnaire de projet. Ce critère sera respecté si vous organiser ces rencontres et sont présents. Le groupe SCM périodiquement des lignes de base de logiciels audits pour vérifier le contenu et l'exactitude. Il est clair pour moi exactement quelle est la différence entre la vérification et celle décrite dans l'activité n ° 9, à l'exception qui effectue la vérification. Vérification appelle également pour le groupe SQA pour examiner et / ou vérifier les produits de travail et présenter les résultats. La vérification SQA devrait évaluer l'adhésion du groupe SCM, SCCB, génie logiciel, et les testeurs et les procédures et les normes de SMC.

cet article est traduisé en francais
l'origine de cet article (en anglai): http://ezinearticles.com/?CMM-Configuration-Management-and-Project-Management&id=3772938