Gestion des configurations et contrôle de changements GEF Référence: [HvV ch. 4] Capt Vincent Roberge Collège Militaire Royal du Canada Génie électrique et génie informatique roberge.segfaults.net PPL08-GestionConfigurationChangements.pdf

Aperçu Gestion des configurations Définition Besoins du système de gestion des configurations Processus de gestion des configurations Fonctions du système de gestion des configurations Contrôle Révisions Versions Deltas Le plan de gestion des configurations Contrôle des changements Attribution de modules Conseil de contrôle de changements 2 Automne 2014GEF492

Le génie logiciel Définition de David Parnas « La production multipersonne de logiciel à multiversions » Qu'est-ce que ceci concerne? 3 Automne 2014GEF492

Problèmes potentiels Un bogue difficile qui fut très dispendieux à réparer réapparaît Une entité développée et testée est tout à coup « manquante » Un programme pleinement testé cesse de fonctionner Deux programmeurs travaillent simultanément sur un programme; le second fait des changements qui détruisent le travail du premier Un bogue est réparé dans du code partagé par plusieurs programmeurs; certains ne le savent pas Un programme est développé en plusieurs versions concurrentes (utilisation, test, et développement); un bogue est réparé dans une version, mais pas dans les autres 4 Automne 2014GEF492

Gestion des configurations L'art de coordonner le développement logiciel afin de minimiser la confusion s'appelle la gestion des configurations (GC). La gestion des configurations se concentre sur l'identification, l'organisation et le contrôle des modifications au logiciel développé par une équipe de programmeurs. Le but est de maximiser la productivité en minimisant les erreurs. - Babitch Automne 2014GEF492

Besoins principaux d'un système de GC Dois permettre de répondre aux questions suivantes Quelle est ma configuration courante? Quel est son état? Comment est-ce que les changements sont contrôlés? Requête de changement (RC) Comment informer tout le personnel des changements? Quels autres changements ont été apportés à ma configuration? Est-ce que les changements de quelqu'un d'autre affectent ma configuration? 6 Automne 2014GEF492

Fonctions de GC de base Contrôle de la configuration s’assurer qu'il n'y a qu'une seule configuration, et qu'elle est connue à tous les développeurs Révision Pistage et habilité de reproduire tout changement amené à un produit Versions Pister les relations entre les différentes versions d'un même système (Eg: la version « normale » et la version pour système à mémoire réduite) Implémentation des deltas Stockage efficace des révisions et diverses versions d'un système 7 Automne 2014GEF492

Contrôle de configuration - Ligne de base Une spécification ou un produit qui ont été formellement révisés et pour lequel il y a entente, qui sert ensuite comme base de développement, et qui ne peut être changé que par des procédures de contrôle de changement formelles. -IEEE Standard 620 -Concepts clés: -Une ligne de base représente la seule copie officielle -Une fois qu'une spécification ou un produit a été accepté à la ligne de base, un changement n'est possible qu'avec l'approbation formelle des parties prenantes -L'autorité d'approbation dépendra de la culture du projet, de la phase de développement et de la maturité du produit. 8 Automne 2014GEF492

Processus GC 9 Automne 2014GEF492 Change- ments Établir/mettre à jour la ligne de base Développement Initial Valider la Ligne de base Autoriser le changement Implémenter Le changement Valider le changement Approuver le changement Besoins/ Conception/ Utilisation Ligne de base

Révisions Dois être en mesure de reconstruire le niveau de révision exact d'un produit, n'importe quand Considérez un test échoué. Pour recréer le système, on doit avoir révision exacte de: Matériel Système d'exploitation Produit sous test Échafauds et pilots de tests Procédures de tests … Aide également à répondre à de simples problèmes Changement inopportun qui détruit de la fonctionnalité existante; on doit pouvoir revenir à la version précédente 10 Automne 2014GEF492

Différences "Ça marchait hier! » Dois être en mesure d'identifier les différences entre les révisions Quel est le changement Qui a fait le changement Quand le changement fut fait La raison du changement Aide à l'efficacité du débogage Donne une piste de vérification et imputabilité 11 Automne 2014GEF492

Versions Il y a souvent plus d'une version d'un même produit Production, développement et conception Windows, Mac, Solaris, Linux à grande mémoire, à mémoire restreinte Pour modifier avec efficacité, on doit comprendre: Quels produits sont communs entre les versions Quels produits sont uniques à chaque version Comment ils sont reliés (Eg: débogage multiversion) 12 Automne 2014GEF492

Deltas Garder des copies complètes de chaque version et révision serait trop volumineux Quand les révisions/versions sont similaires, on peut stocker uniquement les deltas (changements) Cette technique est souvent utilisée dans les outils de GC pour réduire les demandes en stockage Fonctionne habituellement bien uniquement pour l'information textuelle Il est désirable, à l'occasion, « d'aplatir » les deltas et de stocker les produits eux-mêmes 13 Automne 2014GEF492

Le plan de GC Contiens les procédures et les politiques à suivre pour la GC du projet Section de gestion: Organisation du projet (surtout pour la GC) Responsabilités internes et externes Comment sont manipulés les changements et comment est maintenu l'état Comment sont identifiées les interfaces entre les composantes Section d'activités: Comment sont identifiées et contrôlées les configurations Comment piste-t-on et rapporte les RC Quelles données sont collectées 14 Automne 2014GEF492

Rappel: Gestion des configurations L'art de coordonner le développement logiciel afin de minimiser la confusion s'appelle la gestion des configurations (GC). La gestion des configurations se [préoccupe de] l'identification, l'organisation et le contrôle des modifications au logiciel développer par une équipe de programmeur. Le but est de maximiser la productivité en minimisant les erreurs. - Babitch Automne 2014GEF492

Est-ce qu'on a vraiment besoin de GC? 16 Automne 2014GEF492

Pourquoi le contrôle de changements On doit contrôler le changement d’artefact clés du projet durant le processus de développement plans documents de besoins documents de conception code source du produit code et environnement de test etc. Pourquoi? Les fonctions de contrôle de changement sont intimement associés à gestion des configurations pourquoi? 17 Automne 2014GEF492

Quand doit-on « contrôler » le développement initial n’est typiquement pas contrôlé Une fois l’artefact accepté dans la ligne de base, il est habituellement placé sous: gestion des configurations (pister les éléments) contrôle des changements (seulement les changements approuvés ont lieu) Le niveau de contrôle de la configuration d’un item (CAD, l’autorité requise pour un changement) peut évoluer (devenant typiquement plus stricte) quand le projet progresse. Pourquoi? 18 Automne 2014GEF492

Rappel: Processus GC 19 Automne 2014GEF492 Change- ments Établir/mettre à jour la ligne de base Développement Initial Valider la Ligne de base Autoriser le changement Implémenter Le changement Valider le changement Approuver le changement Besoins/ Conception/ Utilisation Ligne de base

Attribution du module chaque « artefact » (produit de travail important, incluant documents et modules code) a un propriétaire le propriétaire doit: connaître et comprendre le design du module donner conseils à tout ceux/celles qui travaillent sur le module, ou qui doivent y interfacer sert comme point de contrôle pour toute modification au module, incluant réparations et améliorations assure l’intégrité du module en révisant tous les changements et faisant des inspections/révisions/audits périodiques 20 Automne 2014GEF492

Attribution du module Avantages assure la continuité en donnant un point central pour les changements utiles pour les petits et les grands projets désavantages dépendants de l’habilité du propriétaire du module requiert que le propriétaire soit disponible quand le changement est requit donne seulement le contrôle au niveau détaillé; on n’a pas de vue d’ensemble on peut mitiger les désavantages en: à l’aide de pairage en nommant un propriétaire de la « vue d’ensemble », c.-à- d. design au niveau du système 21 Automne 2014GEF492

Conseil de contrôle de changements les projets, des moyens aux très grands, requièrent un mécanisme central pour s’assurer que chaque changement important est bien considéré et coordonné avant que celui-ci prenne place on réfère normalement à ce mécanisme comme le Conseil de contrôle de changements (CCC), ou parfois Conseil de contrôle des configurations typiquement comprend du personnel de: gestion développement documentation tests assurance de qualité maintenance publication 22 Automne 2014GEF492

Structure du CCC Il peut y avoir un ou plusieurs CCC S’il y en a plusieurs, ils sont normalement structurés selon les lignes de fonction d’affaires si un changement: affecte seulement un segment/sous-système, le CCC du segment/sous-système peut autoriser le changement. affecte plusieurs segments, l’autorité d’un CCC qui exerce contrôle sur tous les segments 23 Automne 2014GEF492 CCC Système CCC IU CCC Base de données CCC logique d’application CCC outils de soutien

Information requise Grandeur. Combien de lignes de codes doivent être ajoutées/changées? Alternatives. Quelles sont-elles, et pourquoi une particulière est choisie? Horaire. Quelles sont les dates planifiées et de tombée? Impact. Quelles seront les conséquences du changement? Coûts. Quels sont les coûts du changement? Sévérité. À quel point le changement est-il critique? Relations. Est-ce que d’autres changements annuleront celui-ci? Dépend-il d’autres changements? Tests. Est-ce qu’il y a des besoins de tests spéciaux? Ressources. Est-ce que le personnel requis est disponible? Impact au système. Quel sont les conséquences en mémoire/performance/autres? Bénéfices. Est-ce qu’il y a des avantages particuliers découlant du changement? Politique. Qui a demandé le changement? Qui sera affecté? Est-ce que ceci créer des considérations spéciales? Maturité. À quel point est-ce que le changement a été étudié. 24 Automne 2014GEF492

Scénario d’exemple Utilisation du progiciel de communication réseau(UNAS) sous licence d’un autre vendeur depuis 3 ans le progiciel est embarqué sur plateforme Ada (par une équipe de développement) et fonctionne sur plateforme Unix (par une autre équipe) les deux versions doivent communiquer entre elles le code source de UNAS n’est pas disponible; on doit dépendre du vendeur pour les nouvelles versions et pour supporter les changements environnement la version embarquée de UNAS prend du retard sur la version Unix; il y a problèmes de compatibilité à chaque fois que le SE Unix ou Ada est mis à jour on a identifié des bogues subtils dans UNAS; ceux-ci furent mentionnés au vendeur, mais il est lent à répondre Changement proposé: on se débarrasse de UNAS, et on développe une capacité équivalente sur place 25 Automne 2014GEF492

Qu’est-ce qui affecte un système CCC le volume d’information requis par le CCC peut embourber les développeurs, causant des distractions hors la tâche principale on regroupe habituellement les changements ensemble pour réduire le fardeau le travail requis du CCC peut devenir excessive motivation pour plusieurs CCC n’est pas une raison valide pour omettre le contrôle des changements les taux de test et de changements les plus élevés coïncident avec le moment où le contrôle est le plus important et la probabilité de perte de contrôle est la plus haute le personnel du CCC peut bloquer les changements Ils/elles doivent être choisis avec soin le président du CCC à chaque niveau est habituellement le gérant responsable 26 Automne 2014GEF492

ESTIMATION DE PROJETS LOGICIELS Prochaine séance: 27 Automne 2014GEF492