Universit du Qubec Montral Norme IEEE 12191998

1
Université du Québec à MontréalNorme IEEE
1219-1998

• Présenté à M. Philippe Gabrini
• Réalisation et maintenance de logiciel MGL 7460

préparé par Réjean Nolet 20 octobre 2005
2
IEEE 1219-1998 Standard pour la maintenance du
logiciel

• Description.
• Planification de la maintenance.
• Phases du processus de maintenance du logiciel.
• Identification du problème.
• Analyse.
• Design.
• Implémentation.
• Tests de régression, de système et dacceptation.
• Livraison.

3

IEEE 1219-1998
Description

• Ce standard décrit un processus itératif pour la
  gestion et lexécution des activités de
  maintenance.
• Se décrit selon un modèle ?
• Touche chaque phase de la maintenance du
  logiciel.

4
Modèle
IEEE 1219-1998
5

IEEE 1219-1998
Définitions

• Maintenance adaptative.
• Maintenance corrective.
• Maintenance urgente.
• Tests dinteropérabilité.
• Maintenance perfective.   
• Tests de régression.

6
IEEE 1219-1998 Standard pour la maintenance du
logiciel

• Description.
• Planification de la maintenance.
• Phases du processus de maintenance du logiciel.
• Identification du problème.
• Analyse.
• Design.
• Implémentation.
• Tests de régression, de système et dacceptation.
• Livraison.

7

Planification de la maintenance
IEEE 1219-1998

• Déterminer leffort de maintenance.
• Déterminer le processus courant de maintenance.
• Quantifier leffort de maintenance.
• Définir les exigences de maintenance.
• Développer un plan de maintenance.

8

Planification de la maintenance Déterminer
leffort de la maintenance.
IEEE 1219-1998

• Analyser ce que le système fait.
• Analyser le portefeuille de maintenance existant
  et létat de chaque système dans le portefeuille.
• Lage du système.
• Nombre et le type de changements durant sa vie.
• Utilité du système.
• Nombre et le type de requêtes reçues.
• Qualité et lactualité de la documentation.
• Toutes les statistiques de performance.

9

Planification de la maintenance Déterminer
leffort de la maintenance.
IEEE 1219-1998

• Le nombre demployés affecté à la maintenance.
• Leur niveau dexpérience.
• Le taux de roulement des employés
• Les méthodes de maintenance écrites au niveau du
  système et des programmes.
• La méthode employée par le personnel.
• Les outils et comment ils sont employés.

10

Planification de la maintenance Déterminer le
processus de la maintenance courante.
IEEE 1219-1998

• Déterminer le processus de maintenance utilisé.
• Décrire chaque processus par une série
  dévènements. (diagramme de flux)

11

Planification de la maintenance Quantifier
leffort de maintenance.
IEEE 1219-1998

• Chaque étape du processus doit être décrite
  numériquement en terme de volume de temps.

12

Planification de la maintenance Développer un
plan de maintenance. Grandes lignes
IEEE 1219-1998

• Introduction.
• Références et Définitions.
• Vue densemble de la maintenance.
• Organisation.
• Les priorités.
• Sommaire des ressources.
• Responsabilités.
• Outils, techniques et méthodes.
• Processus de maintenance du logiciel.
• Exigences rapportées.
• Rapporter et résoudre les anomalies.
• Déviation au plan prévu.
• Suivit la performance dans toutes les phases.

13
IEEE 1219-1998 Standard pour la maintenance du
logiciel

• Description.
• Planification de la maintenance.
• Phases du processus de maintenance du logiciel.
• Identification du problème.
• Analyse.
• Design.
• Implémentation.
• Tests de régression, de système et dacceptation.
• Livraison.

14

IEEE 1219-1998
Modèle du processus
15
Phase Identification du problèmeentrée
IEEE 1219-1998

• Requête

16
Phase Identification du problèmeProcessus
IEEE 1219-1998

• Assigner un numéro didentification
  (traçabilité).
• Déterminer le type de maintenance. (Corrective,
  Adaptative, Perfective, Urgente).
• Analyser la requête pour déterminer si on la
  rejette, laccepte ou la reporte à plus tard.
• Faire une estimation préliminaire de lenvergure
  de la modification.
• Donner une priorité à la modification.
• Assigner une requête à lensemble des
  modifications prévu à lhoraire, pour minimiser
  limpact de limplémentation chez lusager.

17
Phase Identification du problèmeContrôle
IEEE 1219-1998

• Vérifier que la requête est uniquement
  identifiée.
• Que son entrée est faite dans le
• Référentiel. (SCM) ?

18
SCM (Software Configuration Management)

• En accord avec les normes IEEE 828-1998 et IEEE
  1042-1987.
• SCM fournit les procédures à suivre pour gérer
  la description technique d'un système (et de ses
  divers composants).
• Gérer l'ensemble des modifications apportées
  au cours de l'évolution du système
• Ces procédures doivent aussi déterminer les
  méthodes pour tracer les changements au travers
  le processus de maintenance.
• Assure lintégrité du produit.
• Informe le gestionnaire avec des rapports
  périodiques. ?

19
Phase Identification du problèmeSorties
IEEE 1219-1998

• Lénoncé du problème ou de la nouvelle exigence.
• Son évaluation.
• La classification du type de maintenance requis.
• Sa priorité initiale.
• Estimation initiale des ressources requises pour
  modifier le système existant.

20
Phase Identification du problèmemétrique
IEEE 1219-1998

• Nombre domissions sur la requête.
• Temps pris pour la validation du problème.

21

IEEE 1219-1998
Modèle du processus
22
Phase AnalyseEntrées
IEEE 1219-1998

• Requête validée.
• Information du référentiel.
• Documents du système ou du projet .

23
Phase AnalyseProcessus
IEEE 1219-1998

• Processus itératif comprenant 
• - Analyse la faisabilité ?
• - Analyse détaillée ? .

24

IEEE 1219-1998
Phase Analyse Rapport de lanalyse de
faisabilité 

• Impact des modifications.
• Solutions alternatives, les prototypes.
• Analyse des exigences de conversions.
• Sûreté et sécurité.
• Sûreté  est la capacité du système déviter un
  comportement catastrophique.
• Sécurité  est laccès contrôlé à linformation
  du système
• Facteurs humain.
• Les coûts à moyen et long terme.
• Valeur ajoutée de la modification.

25

IEEE 1219-1998
Phase Analyse Analyse détaillée

• Identifier les éléments affectés par la
  modification. (bd, doc.,spec.,logiciel) et
  estimé.
• Identifier les facteurs de sûreté et de sécurité.
• Concevoir une stratégie de tests.
• Les tests individuels, les tests dintégration
  et les tests dacceptation.
• Pour chaque niveau de tests prévoir les tests de
  régression.
• Développer un plan dimplémentation.

26

IEEE 1219-1998
Phase Analyse Contrôle

• Revoir les changements proposés et lanalyse pour
  évaluer la faisabilité technique et économique,
  et valider sa véracité.
• Identifier les facteurs de sûreté et de sécurité.
• Considérer lintégration des changements dans le
  système existant.
• Vérifier que lanalyse appropriée et que la
  documentation du projet est mise à jour et sont
  contrôlées.
• Vérifier que lorganisation a une façon de tester
  les changements, et quon peut linclure dans
  lhoraire.
• Revoir lestimation des ressources et des
  horaires, vérifier leur exactitude.
• Une décision, qui inclue le client, est prise
  avant de procéder à la phase design.
• La liste des changements doit être documentée.
• Faire une analyse de risques. Evaluer les pertes
  potentielles suite à une panne
• Vérifier et valider que les exigences de
  maintenance son rencontrées
• Norme IEEE 1012-1998 (VV)
• Assurer que la qualité est maintenu pour toutes
  les modifications.
• Norme IEEE 730-1998 (SQA) IEEE 983-1986

27

IEEE 1219-1998
Phase Analyse Sortie

• Analyse de faisabilité.
• Rapport danalyse détaillée.
• Mise à jour des exigences incluant la
  traçabilité.
• Liste des modifications préliminaires.
• Stratégie des tests.
• Plan dimplémentation.

28

IEEE 1219-1998
Phase Analyse Métriques

• Les changements dexigence.
• Taux derreurs dans la documentation
• Effort par point de fonction.
• Respect des cédules.

29

IEEE 1219-1998
Modèle du processus
30

IEEE 1219-1998
PhaseDesign Entrées

• Loutput de la phase analyse.
• La documentation système et/ou du projet.
• Le code source existant, les commentaires et les
  bases de données.

31

IEEE 1219-1998
Phase Design Processus

• Identifier les modules du logiciel affectés.
• Modifier la documentation des modules du logiciel
  (DFD, schémas, PDL).
• Créer des cas de tests pour le nouveau design,
  incluant les points de sûreté et de sécurité.
• Identifier ou créer des tests de régression.
• Mettre à jour la documentation des exigences.
• Mettre à jour la liste des modifications.

32

IEEE 1219-1998
Phase Design Contrôle

• Conduire linspection du logiciel selon la norme
  IEEE 1028-1997. ?
• Vérifier que le nouveau design/exigence est
  documenté dans le SCM.
• Vérifier linclusion de nouveau matériel design ,
  incluant les points de sûreté et de sécurité.
• Vérifier que la documentation des tests
  appropriés a été mise à jour
• Compléter la traçabilité des exigences au design.

33
Norme IEEE 1028-1997

• Ce standard définit cinq types de revue de
  logiciel, avec les procédures requises pour les
  exécutées.
• la revue de gestion
• la revue technique
• linspection
• les walk-throughs
• laudit

34

IEEE 1219-1998
Phase Design Sortie

• Liste des modifications révisées.
• Le design de base à jour
• Les plans de test à jour.
• Lanalyse détaillée à jour.
• Les exigences vérifiées.
• Le plan dimplémentation révisé.
• Une liste des contraintes et des risques.

35

IEEE 1219-1998
Phase Design Métriques

• Nombre de lignes de codes ajoutées.
• Taux derreurs générées par priorité et par type.

36

IEEE 1219-1998
Modèle du processus
37

IEEE 1219-1998
Phase Implémentation Entrées

• Résultats de la phase design.
• Code source, les commentaires et les bases de
  données.
• Documentation du système et du projet.

38

IEEE 1219-1998
Phase Implémentation Processus

• La phase dimplémentation inclut les quatre sous
  traitements suivants, qui peuvent être répétés
  dans une approche itérative ou incrémentale.
• Les changements doivent être implémentés dans le
  code.
• Les tests, le contrôle de qualité(SQA) et la
  validation et la vérification(VV) doivent être
  exécutés.
• Intégration.
• Le logiciel modifié est intégré au système et les
  tests de régression sont exécutés.
• Tous les effets de la modification du système
  doivent être évalués.
• Tous les impacts inacceptables doivent être notés
  et
• un retour au codage est fait pour faire les
  corrections.
• Analyse de risques.
• Test Readiness Review
• Cest un document de gestion qui assure que le
  logiciel a passé avec succès, tout le processus
  de tests, et que le logiciel est prêt pour la
  prochaine étape.
• Il indique la responsabilité des intervenants et
  contient des listes de contrôle.

39

IEEE 1219-1998
Phase Implémentation Contrôle

• Conduire les inspections du code du logiciel
  selon la norme IEEE 1028-1997.
• Sassurer que les tests unitaires et
  dintégration sont exécutés et documentés dans le
  référentiel.
• Sassurer que la documentation des tests est
  créée ou mise à jour.
• Résoudre tous les risques signalés durant la
  revue du logiciel et des tests.
• Vérifier que le nouveau logiciel est placé sous
  le contrôle de la gestion de la configuration du
  logiciel. (SCM)
• Vérifier que la formation et la documentation
  technique ont été mise à jour.
• Vérifier la traçabilité du design au code.

40

IEEE 1219-1998
Phase Implémentation Sortie

• Le logiciel est mise à jour.
• La documentation du design est mise à jour.
• La documentation des tests est mise à jour.
• La documentation de lusager est mise à jour.
• Le matériel de formation est mise à jour.
• Un énoncé du risque et limpact chez lusager
  sont documentés.
• Le rapport de la revue Test Readiness .

41

IEEE 1219-1998
Modèle du processus
42

IEEE 1219-1998
Phase Test du système Entrées

• Rapport des tests.
• Documents
• Plans du test de système (IEEE Std 829-1998)
• IEEE standard 829-1998 est une norme qui fournit
  un cadre pour le développement de plans de tests
  du logiciel et fournit un rapport.
• Cas du test de système (IEEE Std 829-1998)
• Procédure du test système (IEEE Std 829-1998)
• Manuel de lusager
• Design
• Système à jour.

43

IEEE 1219-1998
Phase Tests du système Processus

• Tests fonctionnels du système.
• Tests dinterface.
• Tests de régression.
• Test-readiness review pour valider la préparation
  des tests dacceptation.

44

IEEE 1219-1998
Phase Test du système Contrôle

• Les tests du système doivent être conduits par
  une organisation indépendante des développeurs.
• Le statut des tests doit être rapporté et
  satisfaire aux plans de tests.
• SCM

45

IEEE 1219-1998
Phase Test du système Sortie

• Système testé et intégré.
• Rapport des tests.
• Rapport de Test-readiness review.

46

IEEE 1219-1998
Modèle du processus
47

IEEE 1219-1998
Phase Tests dacceptation Entrées

• Rapport de Test-readiness review.
• Système pleinement intégré.
• Plans des tests dacceptation.
• Cas des tests dacceptation.
• Procédures des tests dacceptation.

48

IEEE 1219-1998
Phase Tests dacceptation Processus

• Faire les tests dacceptation au niveau
  fonctionnel.
• Faire les tests dinteropérabilité.
• Faire les tests de régression.

49

IEEE 1219-1998
Phase Tests dacceptation Contrôle

• Rapporter les résultats pour laudit
• Conduire laudit fonctionnel
• Établir les nouvelles lignes de base du système
• Placer la documentation des tests dacceptation
  sous le contrôle du SCM
• (gestion de la configuration du logiciel)

50

IEEE 1219-1998
Phase Tests dacceptation Sortie

• Les nouveaux fondements du système
• Rapport des tests dacceptation
• Norme IEEE 1042-1987
• SCA.
• FCA (Audit de la configuration fonctionnelle)
• Norme IEEE 1028-1997

51

IEEE 1219-1998
Modèle du processus
52

IEEE 1219-1998
Phase Livraison Entrées

• Le système testé.

53

IEEE 1219-1998
Phase Livraison Processus

• Conduire laudit de la configuration physique
  (PCA)
• Aviser les usagers
• Développer une version archivée du système
• Installer et former .

54

IEEE 1219-1998
Phase Livraison Contrôle

• Arranger et documenter le PCA (Physique
  Configuration Audit)
• Fournir le matériel aux usagers
• Compléter le VDD (Document décrivant la version)
• Compléter la mise à jour de la base de données
  comptable.
• Placer le contenu de la livraison sous le
  contrôle du SCM (Software Configuration
  Management)

55

IEEE 1219-1998
Phase Livraison Sorties

• Rapport PCA (Audit de la configuration physique)
• VDD. (Document décrivant la version)

56
Phase LivraisonExemple de document VDD
IEEE 1219-1998
57
Références

• IEEE Std 1219-1998 Standard for Software
  Maintenance
• IEEE Std 829-1998 Standard for Software Test
  Documentation
• IEEE Std 1028-1997 Standard for Software Review
• IEEE Std 1012-1998 Standard for Software
  Verification and Validation
• NMMSS PROJECT NMMSS Update software configuration
  management plan Septembre 2001
• Test Readiness Review http//www.defenselink.mil/d
  fas/technology/pal/SESTDS/test-read-rvw.pdf