Il s'agit d'un processus qui consiste à appliquer des procédures administratives
et techniques tout au long du cycle de vie du logiciel.
Un plan de gestion de configuration doit être développé (activités de gestion de
configuration, procédures, responsabilités).
Les procédures et outils de gestion de configuration permettent :
- D'identifier de façon précise un composant ou un produit logiciel.
- D'identifier les versions de chacun des composants logiciels qui constituent un
produit livrable, de connaître les liens entre les versions des composants logiciels,
des produits livrables, des spécifications techniques et des documentations.
- D'identifier l'état de construction du logiciel en cours de développement, livré
ou installé.
- De réaliser des développements parallèles (mise à jour simultanée par plusieurs
personnes).
- De coordonner la mise à jour de plusieurs produits en plusieurs lieux.
- D'identifier et suivre toutes les actions et modifications et de fournir un historique
des différentes évolutions du logiciel, de fournir pour chaque modification les
raisons de la modification, les incidences, la liste des autorisations, les vérifications
effectuées.
- D'éviter l'utilisation de programmes sources périmés ou non-conformes.
- De réaliser l'archivage des sources et des produits logiciels.
- De gérer l'existence et le maintien de versions plus anciennes.
Un outil de gestion de configuration doit être utilisé afin de permettre l'archivage
et l'utilisation des programmes de base dans les meilleures conditions de sécurité
et de disponibilité pour les développeurs.
Ces outils assurent la duplication des programmes sources archivés vers le poste
du développeur tout en protégeant la version originelle, et, lorsqu'un programme
modifié est exploitable, permettent la sauvegarde de la nouvelle version dans l'archive.
Le numéro de version est géré par cet outil et un historique des évolutions est
mémorisé.
D'autre part, certains de ces outils avertissent, à l'aide d'une messagerie, les
autres développeurs concernés par une modification afin de leur faire profiter d'une
version toujours à jour. Il est possible avec certains outils de gestion de configuration
de recréer une version antérieure, à l'aide de l'historique, dans un but de test
par exemple.
L'arborescence du disque dur de backup (réseau) est conçue en fonction de la gestion
de configuration (logiciels de base) et de la mise à disposition des produits livrables
en production.
Les programmes de base suivent une numérotation de type XX.YY.ZZ :
- XX = indice d'évolution majeure du logiciel (nouvelles fonctionnalités, refonte
complète).
- YY = indice d'évolution mineure (ajouts mineurs à partir des fonctions existantes).
- ZZ = indice de correction (correction de fautes).
Chaque modification d'un programme entraîne obligatoirement un changement du numéro
de version, même s'il s'agit d'une modification temporaire ou d'une version bêta.
Il est souhaitable d'intégrer en tête du programme, dans le code, un drapeau de
reconnaissance de l'en-tête du programme (recherche), suivi de l'en-tête comprenant
:
- Nom du programme.
- Date de mise à jour.
- Propriétaire du code.
- Version du programme : XX.YY.ZZ
- Version de la spécification technique associée : XX.YY
- Checksum éventuel.
Exemple :
- __FLAG__ = drapeau (recherche de l'en-tête dans le code objet).
- PROGRAMM = nom, 8 caractères, complété par des espaces (correspond obligatoirement
au nom du programme exécutable).
- ENTREPRISE = propriétaire ou auteur, 16 caractères, complété par des espaces.
- 01.01.08 = version du programme, 8 caractères.
- 29/12/99 = date de mise à jour, 8 caractères.
- 01.00 = version de la spécification technique associée, 5 caractères.
- FFFF = checksum 16 bits, 4 caractères.
Les versions de produits livrables suivent une numérotation de type XX.YY et chaque
modification de l'un des composants entraîne l'évolution du numéro de version.
Le numéro de version sera suivi de la lettre « b » s'il s'agit d'une version bêta
mais ce numéro de version sera tout de même incrémenté. Ce numéro de version sera
généralement affiché au démarrage de la machine (menus) et sera obligatoirement
présent dans le fichier historique du livrable (fourni avec le livrable).
En résumé, la mise à jour de nouvelles versions entraîne :
- Un agrément acheteur / fournisseur.
- La documentation des procédures.
- La préservation des performances et une compatibilité ascendante.
- Une définition des règles de base (retouches limitées ou mise à jour complète).
- La connaissance des incidences sur l'exploitation.
- Un moyen d'annonce et de planification des mises à jour.
- Une assurance que de nouveaux problèmes ne sont pas générés.
- Un enregistrement précis des modifications mises en œuvre et des sites concernés.
Les documents doivent correspondre aux normes en application (format, description
du contenu, numérotation des pages, présentation des tableaux et des illustrations,
indication de propriété et niveau de confidentialité, conditionnement).
Les numéros de version des documents doivent être uniques et progresser en fonction
des révisions effectuées. Il doit en permanence exister un lien entre le numéro
de version d'un programme, le numéro de version d'un produit livrable et les numéros
de version des documents associés (spécification technique, manuel d'installation,
manuel de maintenance de premier niveau, manuel utilisateur, etc.'). Ces liens sont
gérés par les outils de gestion de configuration.
Les évolutions des documents donnent lieu à des revues de documentation et le développeur
est amené à participer à ces revues.
Le développement d'un logiciel en version bêta (s'il s'agit d'une modification ou
d'une correction) n'entraîne pas de modification d'une documentation utilisateur
existante, mais peut faire l'objet d'un additif à cette documentation.
Le processus de maintenance est mis en œuvre lorsque le système subit des modifications
relatives aux codes et à la documentation correspondante.
Ces modifications peuvent être dues à des erreurs, des défauts, des problèmes, des
spécifications des besoins trop sommaires ou incomplètes ou encore à des besoins
d'amélioration ou d'adaptation du système.
L'objectif est de modifier un système existant tout en préservant son intégrité.
Ce processus inclut la migration et le retrait du logiciel (dernière étape). Les
activités liées à ce processus sont les suivantes :
- Indication du mode et des conditions de détection du problème.
Le développeur doit reproduire et vérifier l'existence du problème lorsqu'il s'agit
d'une correction du logiciel.
A partir de cette analyse, les actions seront menées pour la mise en œuvre des modifications.
- Listage des constituants logiciels touchés par les modifications (programme de base,
données, structures, éléments de configuration).
- Mise en œuvre du processus de maintenance (développement, documentation, mise en
œuvre, établissement des procédures permettant de recevoir et suivre les rapports
d'anomalies et les demandes de modification des utilisateurs, enregistrement des
problèmes pour des actions correctives, gestion de configuration, documents de suivi).
- Analyse des problèmes et des modifications : impact sur l'organisme et le système
ou les interfaces existants (étendue des modifications, coût impliqué, délais de
modification), type de modification (correction, amélioration, prévention, adaptation
à un nouvel environnement), criticité (impact sur les performances, sûreté, sécurité).
- Le problème ou la demande de modification, les résultats de l'analyse, les options
de mise en œuvre doivent être documentés.
- L'option de modification choisie devra être approuvée après détermination des codes
et de la documentation à modifier.
- Mise en œuvre des modifications après analyse détaillée : le processus de développement
doit être respecté, les critères de test et d'évaluation des éléments modifiés et
non modifiées doivent être définis et documentés (composants logiciels, unités logicielles,
éléments de configuration), la mise en œuvre complète et correcte des exigences
nouvelles et modifiées doit être garantie (les exigences d'origine non modifiées
ne doivent pas être affectées), les tests doivent être documentés.
- Des revues doivent être organisées afin de garantir que le système modifié est conforme
et pourra être validé.
- Un plan de migration sera développé (analyse des exigences et définition de la migration,
développement des outils de migration, conversion des logiciels et des données,
exécution de la migration, vérification de la migration, support de l'ancien environnement
dans le futur).
- Les utilisateurs du système doivent être avisés des plans et des activités de migration
(raison de la migration, description du nouvel environnement et date de disponibilité,
description des autres options de support disponibles, une fois que le support aura
été retiré).
- Exploitation parallèle dans les environnements anciens et nouveaux en vue d'une
transition douce, avec une formation utilisateur.
- Au moment de la migration, une notification est envoyée à toutes les personnes concernées,
la documentation et les anciens codes et enregistrements sont mis en archives.
- Une revue après migration permettra d'évaluer l'impact des changements (les résultats
seront envoyés aux autorités concernées).
- Les données utilisées ou associées à l'ancien environnement resteront accessibles
(protection des données, audit applicable aux données).
- Le logiciel sera retiré à la demande du propriétaire, un plan de retrait sera fourni
pour arrêter l'assistance effective (exploitation, maintenance) : interruption partielle
ou totale de l'assistance après une période déterminée, archivage du logiciel et
de sa documentation, responsabilité concernant les futurs problèmes résiduels d'assistance,
transition éventuelle vers le nouveau projet.
Il est souhaitable de préparer un plan de maintenance (approuvé par le client et
le fournisseur) qui :
- précise le champ d'application de la maintenance,
- identifie l'état initial du produit,
- met en place une organisation de soutien (identification des installations et ressources,
gestion des problèmes imprévus, priorités'), · indique les procédures de modification
(les mêmes que celles utilisées pendant le développement),
- permet d'enregistrer toutes les activités de maintenance (liste des incidents, demandes
d'assistance, actions correctives, responsabilités, priorités, résultats',
- définit les procédures applicables aux nouvelles versions (remise à jour complète
ou « patches », incidence des nouvelles versions sur l'exploitation, annonce des
mises à jour de nouvelles versions, sites et produits mis à jour, etc.).
Les étapes administratives normalisées de l'évolution du logiciel sont les suivantes
:
- Création d'une fiche d'incident précise dans lequel l'auteur décrit le problème
rencontré, la solution de secours éventuelle, la solution envisagée. Cette fiche
est close au moment de la validation d'une solution définitive.
- Création d'une demande de modification ou d'évolution du produit. Cette demande
est approuvée ou rejetée en réunion.
- Ordre de modification du logiciel lorsque les demandes de modifications en attente
permettent un traitement global d'un logiciel ou lorsque la modification justifie
à elle seule la reprise du logiciel.
- Ordre de mise en production du logiciel et des produits livrables associés.
La mesure de la qualité du développement est un moyen d'évaluer la capacité à réaliser
un développement de qualité dans le respect des exigences de coût.
Les éléments qui caractérisent la qualité dans le développement d'un logiciel sont
directement dépendants de la gestion du projet :
- Lecture critique du cahier des charges.
- Analyse approfondie.
- Conception détaillée.
- Vérification du codage.
- Intégration planifiée correctement.
- Procédures de test complètes.
Une bonne préparation du projet sera donc la condition sine qua non d'un développement
de qualité.
Un processus de développement efficace permet de réduire la probabilité d'introduction
de défauts et d'empêcher que des défauts restent cachés.
Un logiciel de qualité sera réalisé dans les temps estimés et les retours pour non-conformité
ou anomalie seront nuls.
Le moyen d'évaluer la qualité globale du développement réalisé, bien qu'imparfait,
consiste à comparer la quantité de travail estimée à la quantité de travail nécessaire.
Les demandes de modification ou d'évolution des logiciels pourront parfaitement
s'intégrer à ce mode de calcul, dans la mesure ou la demande de modification sera
gérée comme un projet à part entière. Les temps de développements complémentaires
liés à des imperfections du logiciel seront pris en compte, mais pendant une période
de trois mois seulement, ce qui correspond à une période raisonnable de réception
du logiciel.
L'indice de qualité du développement, propre à chaque projet, est un pourcentage
(100% correspond à l'indice qualité maximum) :
- Qualité = durée planifiée / (durée développement + durées modifications)
- Durée planifiée = durée estimée du développement (planification détaillée estimée
après la validation du concept)
- Durée développement = durée effective du développement (dès la validation du concept,
jusqu'à la livraison)
- Durée modifications = cumul des temps passés en développements complémentaires consécutifs
à des demandes de modification dues à des non-conformités au cahier des charges
ou à des anomalies. La période d'application de ces modifications est de trois mois
après la mise en service.
Cette méthode implique des contraintes :
- Le planning doit être réalisé avec précision et objectivement.
- Les temps passés sur le projet doivent être renseignés avec exactitude.
- L'indice de qualité ne peut être connu que trois mois après la mise en service du
produit. Chaque mois, la moyenne des indices de qualité des projets achevés du service
R&D logiciel sera calculée.
La moyenne sera effectuée de façon continue, d'année en année et publiée dans un
but de stimulation et de motivation.
Cette méthode de calcul pourra faire l'objet de modifications et d'adaptations.
Les informations fournies permettront néanmoins de procéder à des corrections concernant
les processus de développement utilisés.
