IFT3902 Développement, maintenance de logiciels

Département d informatique et de recherche opérationnelle IFT3902 Développement, maintenance de logiciels François Lustman professeur titulaire François Lustman, 2000 1-1

Plan du cours Ch. 1 Concepts avancés du génie logiciel Ch. 2 Introduction à la notion de projet logiciel Ch. 3 Organisation du développement Ch. 4 Planification Ch. 5 Contrôle Ch. 6 Organisation de la maintenance 1-2

1 Concepts avancés du génie logiciel Chapitre 1 Concepts avancés du génie logiciel 1.1 Métriques 1.2 Qualité du logiciel 1.3 Risque 1-3

1.1 Métriques 1.1 Métriques Définitions Différents types de métriques Rôle des métriques en gestion de projet Exemples de métriques 1-4

Définitions IFT3902 Développement, maintenance de logiciels 1.1 Métriques Lorsque vous pouvez mesurer ce dont vous parlez et l exprimer en nombres, vous savez quelque chose à son sujet; mais lorsque vous ne pouvez l exprimer en nombres, votre connaissance est maigre et peu satisfaisante: c est peut-être le début de la connaissance mais dans vos pensées, vous avez à peine progressé jusqu au stade de la science Lord Kelvin (traduction approximative) Mesure logicielle Mesure logicielle: application d un aspect du monde logiciel dans un ensemble, habituellement, un ensemble de nombres. Exemples: KLOC, # erreurs, complexité cyclomatique. Métrique Petit Robert: théorie de la mesure dans un espace. Métrique du logiciel: mesure logicielle + théorie de la mesure sur l espace dans lequel on mesure. Exemple: KLOC: spécifier le langage, quelles lignes compter, ne pas compter A quoi sert une métrique du logiciel A quantifier une propriété du monde logiciel. Exemple: nombre d erreurs dans un programme: permet de quantifier la qualité du programme. 1-5

1.1 Métriques Différentes classifications des métriques Métriques directes/métriques indirectes Métrique directe: Résultat direct de l observation. Exemple: KLOC. Métrique indirecte Résulte d une transformation des résultats de l observation. Exemple: nombre de complexité cyclomatique. Métriques de produit/métriques de processus Métriques de produit Décrivent une propriété du logiciel lui-même. Exemples: KLOC, complexité cyclomatique. Métriques de processus Décrivent une propriété du processus relatif au logiciel (développement, maintenance, tests, etc). Exemples: effort de développement, productivité. 1-6

1.1 Métriques Rôle des métriques en gestion de projet Savoir où on en est (temps, coût, risque). Evaluer le travail effectué (pertinence, quantité, productivité). Evaluer le produit (pertinence, qualité). Détecter des problèmes imminents ou potentiels. Faire des prévisions. L utilisation des métriques est une nécessité pour un chef de projet logiciel. L utilisation de métriques dans un projet doit être prévue à l avance. 1-7

Exemples de métriques Lignes de code (KLOC) Justification existe pour tout projet logiciel, tout le monde connaît, métrique directe, facile à compter. Problèmes IFT3902 Développement, maintenance de logiciels 1.1 Métriques quelles lignes de code (commentaires, lignes blanches, échafaudage)? langage, type de langage? effets pervers. Réalité: métrique très utilisée commentaires, lignes blanches, échafaudages exclus, code réutilisé compté. Exemples d utilisation en gestion de projet estimation d effort, expression de la productivité, mesure de complexité. 1-8

Exemples de métriques Points de fonction (FP) IFT3902 Développement, maintenance de logiciels 1.1 Métriques Proposé par Albrecht et Gafney vers 1980 pour contourner le problème de non-disponibilité des KLOCs au début du projet. Les FPs tentent de compter les fonctionalités attendues du logiciel. Prévus à l origine pour les applications de gestion. Choses à mesurer 1. Type d entrée externe 2. Type de sortie externe 3. Fichier logique 4. Type de fichier d interface externe vers d autres systèmes 5. Type de requète externe Chaque item peut être considéré comme simple, moyen, complexe. Les entreprises ont développé des heuristiques pour classer un type. Habituellement, basé sur le nombre d éléments de données du type considéré. 1-9

1.1 Métriques Points de fonction: grille de calcul Type d'item Nombre Simple Moyen Complexe Résultat Entrées externes * 3 * 4 * 6 Sorties externes * 4 * 5 * 7 Fichiers logiques * 7 * 10 * 15 Interfaces vers d'autres systèmes * 5 * 7 * 10 requètes externes * 3 * 4 * 6 Total des points de fonction non ajustés 1-10

1.1 Métriques Points de fonction: Facteurs d'influence 0: absent ou sans influence 1: influence insignifiante 2: influence modérée 3: influence moyenne 4: influence notable 5: influence très forte 1 Communication de donnée 8 Mise à jour en ligne: 2 Fonctions distribuées: 9 Traitements complexes: 3 Exigences de performance 10 Réutilisation: 4 Configuration très utilisée: 11 Facilité d'installation: 5 Taux de transactions: 12 Facilité d'opération: 6 Saisie de données en ligne 13 Sites multiples: 7 Efficacité pour l'usager: 14 Facilité de changement: TOTAL: 1-11

Points de fonction: Valeur finale IFT3902 Développement, maintenance de logiciels 1.1 Métriques Facteur d ajustement = 0.65 + 0.01* total facteurs d influence FPs = FPs non ajustés * Facteur d ajustement 1-12

1.1 Métriques Métriques orientées-objet (Chidamber et Kemerer) Métrique WMC DIT NOC CBO RFC LCOM Définition Weighted Methods per Class : Somme pondérée de toutes les méthodes de la classe. Pondération : compléxité de la méthode. Si pondération = 1, WMC = nombre de méthodes de la classe. Depth of Inheritance Tree : longueur du chemin le plus long, de la classe à la racine de l arbre d héritage. Number of Children : nombre de classes immédiatement sous la classe dans l arbre d héritage. Coupling Between Object Classes : nombre de classes auquelles la classe considérée est couplée. Deux classes sont couplées si les méthodes de l une utilisent des méthodes ou des variables d instance de l autre. Response for a Class : nombre de méthodes qui peuvent être éxécutées en réponse à un message reçu par la classe, pour tous les messages qu un objet de la classe peut recevoir. Lack of Cohesion of a Class : différence entre le nombre de paires de méthodes ne partageant aucune variable d instance et le nombre de paires de méthodes partageant une ou plusieurs variables d instance. 1-13

1.2 Qualité du logiciel 1.2 Qualité du logiciel Définitions Approches de qualité Le modèle de maturité de processus 1-14

1.2 Qualité du logiciel Définitions de la qualité du logiciel 1 Conformité à des besoins fonctionnels et de performance explicités, à des standards professionnels de développement explicitement documentés, à des caractéristiques implicites attendues de tout logiciel développé de manière professionnelle (traduit de Pressman). Des aspects absents; des aspects pas très clairs. 2 La totalité des caractéristiques d un produit ou service, qui influent sur sa capacité à satisfaire des besoins explicites ou implicites (Sanders et Curran). Ce sont les besoins des usagers qui déterminent les caractérisrtiques importantes de la qualité. Elles peuvent donc varier d un cas à l autre. Tentative de synthèse: Conformité aux besoins qualité du processus de développement conformité à des critères explicités de qualité prise en compte de l après-vente 1-15

1.2 Qualité du logiciel Caractéristiques de qualité Conformité: conforme à la spécification et permet à l usager de remplir sa mission. Fiabilité: aptitude à fonctionner sans pannes. Efficacité: quantité de ressources ordinateur et assimilées requises par le fonctionnement opérationnel. Intégrité: Protection contre les accès non autorisés. Usabilité: facilité d apprentissage, de mémorisation, d emploi. Maintenabilité: Facilité de correction et de modification. Testabilité: facilité de test. Portabilité: facilité de changement de plate-forme. Réutilisabilité: aptitude du logiciel ou de certaines parties à être réutilisées pour d autres applications. Inter-opérabilité: facilité de couplage avec d autres systèmes. 1-16

1.2 Qualité du logiciel Qualité produit/qualité processus Qualité produit: exemples nombre d erreurs résiduelles par unité de temps, temps d attente moyen par transaction Qualité processus: exemples utilisation UML, plan de tests d intégration dérivé de conception générale. Hypothèse implicite à l approche qualité: La qualité d un logiciel est en grande partie déterminée par la qualité du processus utilisé pour le produire et le maintenir. 1-17

Approches de qualité: IFT3902 Développement, maintenance de logiciels 1.2 Qualité du logiciel prévention, détection et correction précoce des erreurs, élimination des causes d erreurs. Pratiques: injection de qualité dans toutes les activités, ajout d activités dédiées à l amélioration de qualité, ajout d activités de contrôle de qualité, évaluation quantitative si possible. 1-18

1.2 Qualité du logiciel Assurance de la qualité du logiciel Définition L assurance de la qualité du logiciel est une approche systématique adoptée par une entreprise afin d obtenir de la qualité dans les logiciels. Organisation Grande entreprise: Groupe AQL. PME: une personne (?) Projet informatique: une personne, une équipe, le chef de projet, suivant la taille du projet. Principales activités Méthodes et techniques. Normes et mise en œuvre. Tests. Mesures. Revues, inspections etc. 1-19

1.2 Qualité du logiciel Le modèle des niveaux de maturité (CMM) Origine SEI (Université Carnégie Mellon). Objectifs évaluer le niveau d aptitude d un centre informatique à produire des logiciels de qualité. Idées sous-jacentes au modèle La qualité d un produit dépend surtout du processus de fabrication. Notion de contrôle statistique: un processus est sous contrôle statistique si sa performance est prévisible dans des limites pré-établies. Principe de base pour contrôle statistique: mesure. Rôle primordial de la gestion. Potentiel d amélioration. Notion de niveau de maturité. 1-20

1.2 Qualité du logiciel Le modèle des niveaux de maturité: description générale du modèle Initial (1) Répétable (2) Défini (3) Géré (4) Optimisé (5) 1-21

1.2 Qualité du logiciel Le modèle des niveaux de maturité: explication des niveaux (1-3) Niveau 1 (initial) Peu de processus, tant du point vue technique que de gestion. Processus ad-hoc, parfois chaotique. Si processus, abandonné en cas de crise. Succès rares, imprévisibles, dûs aux individus. Niveau 2 (répétable) Processus de projet sous contrôle d un système de gestion de projet. Politiques de gestion de projet et procédures d implantation en place. Planification et gestion de projet basées sur expérience. Standards définis et effort suivi. Niveau 3 (défini) Processus standardisé, documenté, intégré dans l entreprise. Caractéristiques d un processus bien définies. Utilisation version adaptée mais approuvée du processus standard. Utilisation de pratiques de génie logiciel. Groupe responsable du processus génie logiciel. Programme de formation à l échelle de l entreprise. 1-22

1.2 Qualité du logiciel Le modèle des niveaux de maturité: explication des niveaux (4,5) Niveau 4 (géré) Processus prévisible car fonctionnant dans limites mesurables. Objectifs quantitatifs de qualité pour produit et processus. Programme de mesures (productivité et qualité) à l échelle de l entreprise. Mesures mises dans BD et analysées. Au niveau projet, contrôle obtenu en diminuant les variations de performance de processus. Niveau 5 (optimisé) Amélioration continuelle du processus (toute l entreprise). Rendue possible par données quantitatives. Les données d efficacité utilisées pour effectuer des analyses coûts-bénéfices des nouvelles technologies. Analyse des fautes pour déterminer leurs causes. 1-23

1.2 Qualité du logiciel Le modèle des niveaux de maturité: discussion Aspects positifs cadre exceptionnel, cadre intégrateur, idées sous-jacentes saines et éprouvées. Aspects discutables trop d emphase sur gestion, absence totale de rôle pour la technique absence totale de considération du rôle de la compétence des humains, taille unique. Et la PME? Lent et cher: environ 2 ans par niveau. Le jeu en vaut-il la chandelle? 1-24

1.3 Risque 1.3 Risque Concept de risque Gestion de risque Analyse de risque Contrôle de risque 1-25

1.3 Risque Concept de risque Concept intuitif Risque: de faire échouer un projet. Idée de risque à priori. Facteur majeur de risque en développement informatique: incertitude. Définition Eventualité d un événement ne dépendant pas exclusivement de la volonté des parties et pouvant causer la perte d un objet ou tout autre dommage. Événement possible. En partie indépendant de la volonté des participants. Conséquences défavorables. 1-26

1.3 Risque Catégories de risques Catégorie Éléments à risque Exemple Risque projet côut, échéance dépassement de délais Risque technique facettes techniques convivialité Risque d'affaires viabilité, réception, succès produit concurrent 1-27

1.3 Risque Gestion de risque Analyse de risque Contrôle de risque Identification Estimation Planification Contrôle Evaluation Suivi 1-28

1.3 Risque Analyse de risque: identification Identifier les risques potentiels. Sources: folklore/traditions, analogies avec cas bien connus, bon sens, tests, expériences, données statistiques. Approche pratique: concept des top ten. 1-29

1.3 Risque Exemple de candidats pour une liste de top ten calendrier trop ambitieux performances trop ambitieuses budget trop optimiste exigences de fiabilité trop ambitieuses exigences d interface usager trop ambitieuses exigences d interopérabilité problèmes de compréhension avec l usager changements continuels de spécifications spécifications inadéquates, incomplètes, etc direction de projet mal formée, inexpérimentée personnel mal formé, inexpérimenté niveau de maturité incompatible avec exigences méthodes, techniques de génie logiciel, inadéquates ou absentes modèle de processus de développement absent ou inadéquat absence de soutien politique absence de besoin de l usager (ou absence de marché) obolescence précoce scientifiquement au-delà des possibilités 1-30

Estimation Avoir une estimation quantitative Concept de Risk Exposure (RE) RE = P*D P = probabilité du risque D = dommage Evaluation IFT3902 Développement, maintenance de logiciels 1.3 Risque Théorie: définir un niveau de risque acceptable, pour chaque risque, pour le projet. Pratique: sélectionner et ordonner les top ten. 1-31

1.3 Risque Contrôle de risque: Planification Trouver des approches de résolution de risque et planifier leur mise en œuvre. Stratégies de résolution de risque Réduction de risque Objectifs: diminuer la probabilité du risque ou l ampleur de ses conséquences. Protection Limiter l effet du risque. Transfert Partager les conséquences du risque avec quelqu un d autre. Epargne Financer le risque soit constituer une réserve, un fonds de contingence. 1-32