MANAGEMENT DE LA QUALITÉ DANS LES PROJETS INFORMATIQUES

Slides:



Advertisements
Présentations similaires
Amélioration de la qualité des forfaits
Advertisements

Processus d'expression du besoin
L'installation et la diffusion 1 LInstallation et la Diffusion.
La Recette La recette.
Les Evolutions et la Maintenance
Manuel Qualité, Structure et Contenus – optionnel
Urbanisation des Systèmes d'Information - Henry Boccon-Gibod1 Urbanisation de système d'information PLM 4 (Product Lifecycle Management) Préoccupation.
Page : 1 / 6 Conduite de projet Examen du 6 mai 1999 Durée : 4 heures Le support de cours est toléré La notation tiendra compte très significativement.
Page : 1 / 6 Conduite de projet Examen du 13 mai 2002 Durée : 3h30mn Le support de cours et les notes sont nécessaires La notation tiendra compte très.
Démarche de Projet D’après la norme X50-106, un projet est une démarche spécifique qui permet de structurer méthodiquement et progressivement une réalité.
L’utilisation des Normes ISO 9001 et ISO 9004 dans la démarche qualité
Les Ateliers de Génie Logiciel
La revue de projet.
MIAGE MASTER 1 Cours de gestion de projet
Control des objectifs des technologies de l’information COBIT
IAS 16 « Immobilisations corporelles »
Introduction au Génie Logiciel
le profil UML en temps réel MARTE
Vuibert Systèmes dinformation et management des organisations 6 e édition R. Reix – B. Fallery – M. Kalika – F. Rowe Chapitre 1 : La notion de système.
L ’approche par processus
Le Reengineering.
BPM – Processus Marc Lapraz Emilien Siegrist Christel Minguely
Interoperabilité des SI - Urbanisation
Techniques de test Boulanger Jean-Louis.
LA DEMARCHE D ’EVALUATION DE LA QUALITE DANS LE SECTEUR MEDICO SOCIAL
SemanticMediaWiki Audit de projet Antoine Gavoille Anwar Rhemimet
IGL301 - Spécification et vérification des exgiences 1 Chapitre 1 Introduction (ref : Bray chapitre 1)
Des indicateurs de performance pertinents et adéquats
© Petko ValtchevUniversité de Montréal Janvier IFT 2251 Génie Logiciel Notions de Base Hiver 2002 Petko Valtchev.
Page 1 / Titre / Auteur / Date / Confidentiel D? LA DEMARCHE COLLEGES METIER.
Conception des Réalisé par : Nassim TIGUENITINE.
Tolerance Manager Un concept métier
Systèmes d’informations : Définition, Composantes, Rôles et Approches.
Eurométhode: méthode de gestion de la relation client-fournisseur
NORMALISATION DES LANGAGES DE PROGRAMMATION des Automates Programmables Industriels CEI
E5 - MANAGEMENT ET GESTION D’ACTIVITÉS TECHNICO-COMMERCIALES (Coef. 4)
MBA HEC, simulation Netstrat, séance 7
Partie A Système d ’information et organisation
ANALYSE METHODE & OUTILS
DEMARCHE ERGONOMIQUE.
La démarche d’audit La démarche d’audit s’articule toujours en Phases : La première phase permet de planifier l’audit à partir de la définition du périmètre.
Objectif de l’IPMVP : « Mesurer et Vérifier les économies d’énergie, donner la preuve de ce que l’on annonce »
Vue d’ensemble des outils du PRISM Dakar, 3 au 21 Mai 2010
BOURDIEU Nicolas DUPONT Benjamin LUCAZEAU Claire SOURISSEAU Erick
Le management de l'IVVQ Processus techniques IVVQ
Supports de formation au SQ Unifié
GESTION des CONFIGURATIONS LOGICIELLES
Hatainville Les Moitiers d’Allonne – Tel : Website : stratic.online.com La démarche projet Mars 2001.
Institut Supérieur des Sciences Appliquées et de Technologie Sousse
La Qualité dans les Systèmes d’Information
GOUVERNANCE ET DEMARCHE QUALITE
Réalisé par : Mr IRZIM Hédi Mr JRAD Firas
Vérification dans le cycle de vie GEF492A 2014 Référence: [HvV §14.2, 14.9] Capt Vincent Roberge Collège Militaire Royal du Canada Génie électrique et.
Le contenu est basé aux transparents du 7 ème édition de «Software Engineering» de Ian Sommerville«Software Engineering» de Ian Sommerville B.Shishedjiev.
Introduction au Génie Logiciel
VALIDATION VÉRIFICATION & TESTS
Initiation à la conception des systèmes d'informations
Présentation AICHA REVEL INGENIEUR D’ÉTUDE STERIA DEPARTEMENT TRD
Management de la qualité
SYSTEMES d’INFORMATION séance 1 : Introduction et définitions
Principes et définitions
Page : 1 / 7 Conduite de projet Examen du 16 mai 2001 Durée : 3h30mn Le support de cours et les notes sont nécessaires La notation tiendra compte très.
Martine Miny - MPInstitut - Référentiels et métiers de management de projet - Mastère IESTO - 9 février 2004 Référentiels et métiers de management de projet.
Système de Management Intégré
Retour aux fondamentaux
Document de spécification d’exigences Normes IEEE et 29148:2011
ISO 9001:2000 Interprétation Article 7 Réalisation du produit
1 41Qualité d’un logiciel Référentiel Gestion Comptable.
CONTENU DE L ’ISO Définition métrologie.
Transcription de la présentation:

MANAGEMENT DE LA QUALITÉ DANS LES PROJETS INFORMATIQUES QUALITÉ et ASSURANCE QUALITÉ

Quelques définitions qualité (1/2) Conformité aux exigences La qualité est définie comme la satisfaction d'un besoin clairement et explicitement spécifié Prévention L'approche qualité est fondée sur la prévention des défauts qui doivent être détectés le plus tôt possible. Le traitement préventif s'oppose au curatif, généralement beaucoup plus coûteux et risqué Zéro défaut Relativement à un objectif qualité (raisonnable) clairement et explicitement formulé Coûts Le coût total qualité (CTQ) est la somme de : Coût de la conformité COC (c’est un actif ) + Coût de la non conformité CONC (c’est un passif)

Quelques définitions qualité (2/2) Contrôle qualité On vérifie que les normes qualité de l'entreprise ont été respectées. Ce qui devait être fait est effectivement fait Le contrôle n’implique pas de vérification du contenu (le coût est minimal, mais la garantie est plus faible) Assurance qualité Fonctionne comme une assurance : C’est une garantie de bon, ou de meilleur, fonctionnement du point de vue de l’usager C'est un surcroît d'effort qui permet d'augmenter le niveau de confiance que l'on peut avoir dans un produit, ou un système logiciel (on intègre dans la démarche le coût des conséquences d'une panne  c.a.d. perte de production, …) Essentiellement constituée par de la VV&T On vérifie le contenu de façon à donner une vraie garantie (le coût est potentiellement elevé pour les systèmes à fortes contraintes)

Maturité en qualité Rien de tout cela n'est vraiment difficile mais implique un bon niveau de maturité des acteurs Individus Sens de l'équipe et du collectif Ne pas cacher ou déplacer les problèmes Organisations Éthique, déontologie et culture d'entreprise forte La mise en œuvre de l'approche qualité est très exigeante pour le client/maître d'ouvrage et pour le fournisseur/réalisateur (maître d’œuvre) Le contrat doit être clair et explicite, le « non dit » est exclu La qualité, c'est gratuit mais cela ne va pas de soi (Ph. Crosby)

Processus qualité générique Le Modèle VEST Conformité de la fourniture Conformité de la livraison Pilote de la tâche E T Tâche projet à effectuer S Tâche(s) amont Tâche(s) aval Flux nominal et anomalies imputables à T Flux nominal et demandes de modifications V Validation, vérification, test Par rapport à la FINALITÉ

Quelques implications La mise en œuvre du zéro défaut et de la saisie des coûts (COC + CONC) implique une métrologie rigoureuse de tout le processus de développement À défaut d'une vraie mesure, on se contentera d'indicateurs La mesure ou l'indicateur doit être fidèle Il est donc essentiel que pour l'individu qui en est la source, cet indicateur soit compréhensible et utile (i.e. permettent l'action) Le cycle de développement doit être décomposé en éléments identifiables de façon à ce que les coûts élémentaires puissent être correctement ventilés Gestion de projet rigoureuse

Notion de chaîne de valeur : Productivité - Rendement Acteurs usagers du SI Chaîne de valeur : Processus métiers Acteurs développement Organisation de développement Organisation cible ACQUISITION Chaîne de valeur : Processus de développement GAIN Organisation du MCO Chaîne de valeur : Processus de modifications COÛT Acteurs exploitation/support

Objet de la qualité logicielle Macroscopiquement, le logiciel c'est: Statiquement : un référentiel documentaire Des programmes (données + algorithmes) Des tests De la documentation (papier + "aides en lignes") Dynamiquement : un comportement La façon dont le système interagit avec son environnement (cf. les caractéristiques non fonctionnelles FURPSE) Ergonomie (aspects psycho-cognitif, formation des usagers) ; Performance, (Temps de réponse) ; Sûreté de fonctionnement (MTTF / MTTR), etc. Grande variété d'usages et d'usagers Métrologie très délicate Indicateurs opératoires (permettre l'action) ET Signification de la mesure ( exp. : Que signifie un taux de commentaires ? ) Le rôle de l'homme est très difficilement séparable du produit

Facteurs et critères qualité La seule bonne façon de mesurer ou estimer la qualité d'un produit est d'adopter le point de vue de l'utilisateur Grande méfiance vis à vis des facteurs / critères «esthétiques»et/ou subjectifs Notion de facteur qualité On organise la perception de l'usager / utilisateur On cherche à rendre explicite les coûts Notion de critères qualité On cherche à caractériser ce que doit faire le producteur pour réaliser un produit qui optimise la satisfaction de l'usager / utilisateur selon les facteurs retenus Métrologie associée aux critères de façon à permettre le management Historiquement, approche Mac Call : 11 facteurs, 23 critères (en 1977)

Exemples facteurs / critères Cas du facteur ergonomie Critère N°1 : Clarté des message d’erreurs Peut s’apprécier de différente façon Enregistrement et suivi du nombre d ’erreurs commises par les usagers en fonction de la durée de la session Mesure du « think time » (temps de réflexion face à l’écran) précédant une action de l’usager etc.

NORMES ISO/CEI 9126 et IEEE Std 1061 CARACTÉRISTIQUES QUALITÉ DES PRODUITS LOGICIEL

Modèle qualité de la norme ISO 9126 (1/2) Caractéristiques qualité : FURPSE F : Functionality / fonctions offertes Ensemble des attributs caractérisant la façon dont sont satisfaits les besoins explicites et implicites exprimés par le commanditaire du logiciel. Adéquation, précision, interopérabilité, sécurité U : Usability / facilité d’utilisation Ensemble des attributs permettant de caractériser l'aptitude du logiciel à s'intégrer dans son environnement organisationnel et humain. Compréhension, facilité d'apprentissage, facilité d'installation et d'administration R : Reliability / fiabilité Ensemble des attributs permettant au logiciel de maintenir son niveau de service conformément à certaines conditions externes et pendant une certaine durée déterminées à l'avance. Résistance aux pannes, restauration, maturité

Modèle qualité de la norme ISO 9126 (2/2) P : Efficiency / performance Ensemble des attributs permettant de caractériser les ressources nécessaires au bon fonctionnement du logiciel conformément à un niveau de charge défini à l'avance. Temps de réponse du logiciel, ressources nécessaires (UC, mémoire centrale et disques, Entrées/Sorties disques et/ou réseau,… ; cf. Capacity planning). S : Maintainability / maintenabilité du niveau de service Ensemble des attributs permettant de caractériser l'aptitude du logiciel à subir toute évolution nécessitée par l'adaptation du logiciel à son environnement. Diagnostiques en cas de pannes, facilité de modifications, aptitude à la non régression, facilité de tests ; cf. System management. E : Portability / portabilité - évolutivité Ensemble des attributs permettant de caractériser l'aptitude du logiciel à être transféré d'un environnement d'exécution à un autre. Encapsulation des interfaces permettant de migrer d'une plate-forme à une autre, dépendances vis à vis de l'environnement.

Les sous-caractéristiques ISO 9126 (1/2) Fonctions offertes Suitability / adhéquation des fonctions Accuracy / précision Interopérability / interopérabilité Security / sécurité Fiabilité Maturity / période de rodage suffisante Fault tolerance / résistance aux pannes Recoverability / reconfiguration ± automatique Facilité d'emploi - d’utilisation Understandability / facilité de compréhension Learnability / formation-aides en lignes Operability / facilités de mise en œuvre

Les sous-caractéristiques ISO 9126 (2/2) Performance Time behaviour / temps de réponse - durée des traitements Resource behaviour / consommation de ressources (mémoire, E/S, …) Maintenabilité Analyzability / facilités de diagnostiques Changeability / aptitude aux changements et aux modifications Stability / non-regression et compatibilite ascendante des interfaces Testability / facilité de mise en oeuvre des tests Portabilité Adaptability / facilités d'adaptation à de nouveaux interfaces Installability / facilité d'installation Conformance / conformité des interfaces ( Exp. : API) Replaceability / facilités de remplacement des modules (intégrabilité)

Démarche d’évaluation recommandée par la norme ISO/CEI 9126 Définition de l’exigence de qualité en terme de caractéristiques Préparation de l’appréciation Choix des métriques Définition des échelles de classement par métrique niveaux de classement satisfaisants ou non Définition des critères d ’évaluation qualité globale regroupant les métriques (moyennes pondérées, tables de décision) Procédure d’appréciation mesurage classement évaluation avant livraison puis avant acceptation

Description textuelle du processus générique avec FURPSE (1/2) Informations obligatoires : Identification Description des enchaînements – caractéristiques fonctionnelles du/des fonctions (ce que ça fait dans un monde « parfait ») En particulier : interopérabilité avec d’autres systèmes ; sécurité Caractéristiques non fonctionnelle (FURPSE) – prise en comte du monde réel et des contraintes associées En particulier : pré et post-conditions conformément au processus/fonctions génériques NB : l’absence d’information sur le comportement est déjà une information !!! Évènements gérés et/ou générés par le cas d’utilisation

Description textuelle du processus générique avec FURPSE (2/2) Information complémentaire Conformément au modèle VEST : On peut rajouter des descriptifs correspondant aux conditions d’entrée et de sortie du processus ou de la fonction On peut préciser la nature des ressources utilisées par le processus ou la fonction, ainsi que les modalité d’accès à ces ressources Mise en forme finale Par exemple sous la forme d’un cas d’emploi UML (use case)

LE BON USAGE DES NORMES QUALITÉ Les normes sont un moyen, jamais une fin !

Conditions nécessaires à la qualité Rôle du processus Un processus de développement bien défini est une condition nécessaire à la métrologie des coûts COC et CONC Mise en garde : Ne pas confondre le processus et le produit issu de ce processus La qualité du produit n'est, malheureusement, pas réductible à la qualité du processus. Ne pas céder à la tentation de la bureaucratie Rôle des normes Normes générales : IEEE software engineering, ISO 9000 (inapplicable au logiciel car trop générale), ISO 12207, ISO 15504, ISO 9126, AFNOR Qualité et ingénierie du logiciel La norme définit un code de communication qui permet de parler la même langue Glossaire des termes techniques, plan type, métriques, etc. Normes de l'entreprise Définissent la culture qualité de l'entreprise (cf. Le processus en 14 étapes de Ph.Crosby ; le cercle vertueux de E.Deming, etc.)

Mise en œuvre du processus qualité Rôle des hommes À toutes les étapes du cycle de vie, le rôle des hommes est primordial Revues ; Inspections ; Audits Rôle des outils : Les outils sont un moyen, non une fin en soi Par définition, seule la structure (syntaxe) est accessible à l'outil Sémantique et pragmatique restent inaccessibles Outils de « qualitimétrie » Nombre cyclomatique (Mac Cabe), mesure de couverture, etc. Modèle qualité On essaye de relier les différents éléments du modèle par des formules : Composantes principales  facteurs  critères  métriques

Amplification - Suppression des défauts Modèle d'amplification (Cf. modèle VEST) PROCESSUS/TÂCHE DU CYCLE DE DÉVELOPPEMENT DÉFAUTS DÉTECTION ERREURS PROPAGÉES EFFICACITÉ DE LA DÉTECTION ERREURS PROVENANT DES ÉTAPES PRÉCÉDENTES ERREURS AMPLIFIÉES ERREURS TRANSMISES À L'ÉTAPE SUIVANTE ERREURS NOUVELLES COËFFICIENT D'AMPLIFICATION: #ERR   dépend de l'architecture l'efficacité de la revue dépend de la documentation, des standards, de l'organisation et du niveau de maturité (Cf. modèle CMM) du bureau de revue

Brève bibliographie qualité NORME AFNOR Z 67-150 typologie des processus du cycle de vie du logiciel (dec 93) + NORMES ISO12207 ; 9126 ; 15504 (SPICE) ; AFNOR Qualité et ingénierie du logiciel. IEEE Software engineering standards collection La qualité, c'est gratuit, Ph. Crosby ; Economica Measures for excellence, L.H.Putman W.Myers ; Prentice Hall Practical software metrics for project management and process improvement, R.B.Brady ; Prentice Hall Managing the software process, W. Humphrey, addison-wesley Quality software management, G.Weinberg, 4 vol, Dorset House.