1.LA PROBLEMATIQUE DU LOGICIEL

1.LA PROBLEMATIQUE DU LOGICIEL 1 LA PROBLEMATIQUE DU LOGICIEL...1 1.1. GENIE LOGICIEL OU L'ART DE PRODUIRE DU LOGICIEL...1 1.2. ASPECTS HISTORIQUES : EVOLUTION DE L'INFORMATIQUE...3 1.3. LA CRISE DU LOGICIEL...5 1.4 LES REPONSES A LA CRISE:...5 La maîtrise du processus de développement... 5 Développement de méthodes structurées et d'outils CASE... 5 Le paradigme objet... 6 L'approche composants... 7 1.5 LES MOTEURS DE LA QUALITE...8 Objectifs8 Organiser le processus : cycle de vie, responsabilités, rôles... 8 Gestion des ressources : gestion de projet, gestion des configurations... 9 Méthodes, techniques et outils de production et de mesure... 10 1.6 ASSURANCE QUALITE...10 Définition... 10 Organisation... 10 Contrôle 11 Communication... 12 1.7 NORMES QUALITE...13 La norme ISO 9001... 13 Le Capability Maturity Model... 17 Comparaison Iso9000 - CMM... 19 Le projet SPICE... 20 1.8 REFERENCES...20

1 LA PROBLEMATIQUE DU LOGICIEL 1.1. GENIE LOGICIEL OU L'ART DE PRODUIRE DU LOGICIEL La production de logiciel tout comme celle de n'importe quel autre bien nécessite la mise en œuvre de méthodes, techniques et outils dépassant largement le cadre de la seule programmation, regroupés sous le vocable général de Génie Logiciel.. Le terme est apparu pour la première fois lors d'une conférence de l'otan à Garmisch en 1969, a commencé à se répandre dans les années 80, notamment avec l'arrivée sur le marché d'ateliers de génie logiciel (AGL). Il faut attendre le milieu des années 70 pour que le terme émerge : la première conférence sur le génie logiciel a lieu en 1973 et la revue IEEE Transactions on Software Engineering existe depuis 1975. Le Génie Logiciel est à rapprocher du Génie civil, Génie mécanique ou Génie chimique. La réalisation d'un pont ne peut être menée sans de méthodologie, de même la réalisation d'un logiciel nécessite un minimum de précautions qui garantissent sa faisabilité, sa qualité et sa fiabilité. Nouveaux besoins ou besoins changés cahier des charges ou prototype Système existant Processus de production de logiciels composants Nouveau système ou système modifié Génie logiciel = Méthodes, techniques, outils Figure 1.0 : La production de logiciel sous contrôle du génie logiciel La programmation est une discipline récente purement intellectuelle, certains la qualifiaient même d'art [Knuth, The art of software programming] ; pour ces raisons, on y trouve des attitudes et des habitudes qui paraîtraient étranges dans d'autres disciplines plus mures. Notamment le syndrome du "not invented here" ; on n'imagine pas un ingénieur mécanicien réinventer la roue ou fabriquer ses propres vis et boulons alors qu'un programmeur préfère souvent réécrire ses propres lignes de code plutôt que réutiliser un code développé par d'autres. La lutte contre cette tendance naturelle est un défi majeur de l'industrie informatique d'aujourd'hui connu sous le vocable réutilisation. L'aspect ludique de la discipline renforce la dérive vers les comportements individualistes. Génie logiciel Anne-Marie Hugues 19/12/02 1-1

La programmation est une activité immatérielle : pour un néophyte, il peut sembler peu dispendieux de démolir et reconstruire une architecture logicielle alors que l'on réfléchirait à deux fois avant d'agir de même concernant une autoroute ou un bâtiment. Le logiciel modifie l'environnement de celui qui l'utilise dans des proportions telles que l'on a du mal à définir précisément et durablement des spécifications stables. La maintenance occupe une part importante du budget et du temps consacré au développement d'un logiciel. Elle peut revêtir différentes formes : maintenance corrective: destinée à corriger des "bugs" maintenance évolutive: adaptative ou perfective Il est important de prendre conscience des enjeux majeurs représentés par la maintenance 67% du coût total est consacré à la maintenance dont 48% consacrés à réparer des défauts 60% des défauts correspondent à des erreurs de spécification et de conception D'un point de vue économique, tout comme il convient de distinguer Chimie et Génie Chimique, il faut différencier programmation et génie logiciel. En chimie si deux réactions différentes conduisent au même produit on n'a aucune raison de préférer l'une à l'autre. Alors que le génie chimique différenciera parmi ces deux réactions celle qui met en jeu les produits de base les moins chers par exemple. De même le Génie Logiciel tiendra compte en particulier des coûts de formation et des implications à long terme lors de l'introduction de nouvelles techniques de programmation. Au début des années 80 deux livres marquent la prise de conscience de la nécessité de rationaliser les développements informatiques et de les inscrire dans un contexte économique général. B. Boehm dans Software Economics à partir d'une analyse des données menée sur les projets informatiques de la firme TRW, définit une méthode de régression permettant d'évaluer le coût d'un projet logiciel (COCOMO) 1 en se basant sur le nombre de lignes de code source estimées. C'est une des premières démarches en faveur de la mesure d'effort. La méthode a été mise à jour en 2000 pour tenir compte de l'aspect réutilisation dans les projets logiciels. Frédéric BROOKS, dans "The Mythical Man Month" 2 analyse les principaux échecs du développement de l'os/360. Malgré le succès relatif du projet, on constate: - la présence de nombreuses erreurs résiduelles dans les premières versions, - un retard important dans la livraison du produit - que la place mémoire occupée est plus importante que prévu, - que le coût réel est plusieurs fois celui estimé initialement. Ce livre vient d'être réédité sans grands changements Nous en retenons les différences essentielles entre un programme 3 et un produit logiciel intégré dans un système. Un produit peut être utilisé, testé, maintenu, étendu, généralisé par une autre personne que le programmeur initial. Un produit doit être suffisamment testé, documenté. Coût estimé par Brooks pour développer un produit: Coût du programme x 3 On s'intéresse ensuite à la différence entre un programme et un programme intégré dans un système, il s'agit d'une collection de plusieurs programmes qui interagissent. Il en résulte un besoin de coordination, la nécessité d'établir des interfaces, de gérer la consommation des ressources, une plus grande difficulté à organiser les tests. Le coût estimé par Brooks est alors supérieur ou égal au Coût du programme x 3.D'où le coût estimé pour un produit logiciel intégré: Coût du programme x 9 1 Cf chapitre 3 2 L'unité de calcul de la taille d'un projet est l'homme x mois (man month) 3 typiquement un programme fabriqué par un étudiant lors d'une séance de travaux pratiques 1-2 Anne-Marie Hugues 19/12/02 Génie logiciel

PROGRAMME PROGRAMME INTEGRE DANS UN SYSTEME (Interfaces, Intégration,...) PRODUIT LOGICIEL (Généralisation, Tests, Documentation, Maintenance) PRODUIT LOGICIEL INTEGRE DANS UN SYSTEME Figure 1.1 : Comparaison Produit/Programme (d'après F Brooks) Dans son livre, Frédéric Brooks met également en garde contre l'effet deuxième système. Le développement de la deuxième version d'un produit ne prend pas forcément beaucoup moins de temps que la première; il faut apprendre à se méfier de l'"optimisme" des ingénieurs logiciels. L'exemple cité est celui de la release 1.0 d' OS/360. Dans la première version un temps considérable a été passé à automatiser la création d'overlays par l'éditeur de liens alors que dans la version suivante, l'introduction de la pagination rendait les overlays inutiles...aujourd'hui les avancées technologiques de plus en plus rapides font de l'obsolescence du savoir un élément critique de la gestion de projet informatiques. Cette rapidité d'évolution des technologies explique que la crise du logiciel découverte dans les années 80 ne soit qu'imparfaitement vaincue aujourd'hui: dès qu'un remède est trouvé, l'évolution de la technique le rend partiellement obsolète. 1.2. ASPECTS HISTORIQUES : EVOLUTION DE L'INFORMATIQUE L'informatique est une discipline jeune, l'industrie informatique s'est organisée en 20 ans là où d'autres industries ont mis plus d'un siècle La programmation apparue dans les années 45-58 était alors le domaine réservé de quelques ingénieurs mathématiciens qui programmaient en assembleur des programmes de calcul scientifique sur mesure, à distribution limitée sur des machines volumineuses de puissance inférieure à celle d'une calculette actuelle; machines expérimentales d'abord ( ENIAC, EDVAC ) puis commerciales SEA CAB500, BULL GAMMA3, UNIVAC, IBM 701. Dans les années 58-75 l'informatique se développe considérablement à la fois côté scientifique (langages FORTRAN) et dans le domaine de la gestion (langage COBOL). Les premiers systèmes d'exploitation Multi-Utilisateurs apparaissent (IBM 360, Vax VMS, Bull Gecos ) systèmes propriétaires qui lient l'utilisateur au constructeur. Les programmes peuvent être activés en batch (l'un à la suite de l'autre) sur des architectures centralisées, les premiers systèmes temps réel font leur apparition en informatique industrielle. Dans les entreprises, on assiste à une main mise de la Direction Informatique sur l'ensemble de l'entreprise. Les investissements matériels pèsent très lourd à cette époque, beaucoup plus que le temps passé à développer les programmes. Nombre de programmes développés à cette époque ont été concernés par le fameux bug du passage à l'an 2000.Parmi les entreprises les plus avancées (DOD, NASA, constructeurs informatiques..) certaines perçoivent la crise du logiciel qui va se faire jour (1969). Génie logiciel Anne-Marie Hugues 19/12/02 2-3

Pendant les années 75-90, l'innovation apportée par les bases de données relationnelles concomitante au déferlement de la micro informatique et à l'avènement des réseaux, a sorti les Directions Informatiques de leur tour d'ivoire, en mettant l'informatique à la portée des utilisateurs. On prend progressivement conscience de la nécessité de maîtriser le développement de logiciels alors que le prix du hardware diminue et que le coût de l'informatique doit prendre en compte non seulement les coûts de développement mais aussi les coûts de maintenance (corrective et évolutive). Le système ouvert Unix a libéré les informaticiens du joug des constructeurs, désormais tout système vise à l'hétérogénéité et à la portabilité, l'informatique embarquée temps réel envahit peu à peu le quotidien (transactions bancaires, réservations, électroménager, véhicules ). On passe des systèmes centralisés aux systèmes distribués. L'industrie du logiciel se complique vite alors qu'elle n'en est qu'à ses balbutiements. Avec la prise de conscience de la crise du logiciel et de l'importance stratégique des systèmes d'information, la Direction Informatique cède progressivement la place à une Direction de l'informatique et de l'organisation (début des années 80) dans les grandes entreprises. On constate l'avènement de nombreux consultants en organisation. Logiciels sur mesure calcul scientifique Assembleur ENIAC 1945 Logiciels scientifiques et de gestion crise FORTRAN COBOL multi-utilisateurs systèmes propriétaires systèmes de fichiers batch, temps réel Figure 1.2 : 50 ans d'informatique Logiciels scientifiques Temps réel, progiciels ERP embarqués, Micro informatique puces systèmes distribués client-serveur Bases de données Unix puces 1958 1970 1990 Informatique partout fiabilité sécurité aide à la décision e-business Réseaux, Internet Intranet 3 tiers serveurs d applications 2000 Durant les années 90 l'omniprésence d'internet ou d'intranet dans les applications oblige à reconsidérer les architectures client-serveur établies quelques années plus tôt au profit d'architectures 3 tiers prenant en compte des serveurs d'applications et non plus seulement des serveurs de données. Au niveau des applications, les exigences s'accroissent : l'informatique de gestion se dote de progiciels de gestion ERP (Enterprise Resource Planning, cf SAP/R3) qui intègrent les opérations les plus courantes et offrent à leurs clients des produits standardisés à 80% et facilement (!?) paramétrables pour les 20% restant. Les outils d'aide à la décision (datawarehouse, data mining) font leur apparition. En matière de commerce électronique (ecommerce) les contraintes de sécurité et de fiabilité sont pratiquement aussi fortes qu'en informatique temps réel (logiciels embarqués dans satellites, logiciels de contrôle de centrale nucléaires.) alors que les budgets consacrés et les temps de développement se veulent radicalement inférieurs En conclusion le logiciel est aujourd'hui présent partout, sa taille et sa complexité augmentent de façon exponentielle, les exigences de qualité sont de plus en plus sévères la 1-4 Anne-Marie Hugues 19/12/02 Génie logiciel

crise du logiciel apparue dans les années 70 n'est toujours pas franchement résolue même si de grands progrès ont été réalisés dans de nombreux domaines 1.3. LA CRISE DU LOGICIEL Mise en évidence au début des années 70, la crise se caractérise par l'absence de maîtrise des projets, au niveau des coûts et des délais, la mauvaise qualité des produits: les produits ne répondent pas aux besoins définis et des erreurs résiduelles persistent dans le produit final un stock important de projets en attente faute d'une gestion rigoureuse Quelques exemples de logiciels défaillants: La facture de 0F (juste pour rire) La fausse attaque de missiles (Novembre 1979) Les anti-missiles Patriotes (Guerre du Golfe 1991) Les sondes perdues vers Vénus( années 60) vers Mars (99) La panne ATT (1990) L échec d Ariane 5 (1996) La poste (1998) Et les erreurs que l'on ignore : logiciels de surveillance médicale défaillants.et l an 2000 (qui a fait dépenser des millions de $ pour des logiciels développés pour la plupart en pleine crise du logiciel) qui a finalement été bien absorbée sans provoquer trop de défaillances. 1.4 LES REPONSES A LA CRISE: La maîtrise du processus de développement Pour maîtriser le développement, une organisation doit choisir et appliquer un modèle de processus définissant: - Les phases du développement: définitions des besoins, spécifications, planification, conception, codage, tests... - Les produits intermédiaires: prototype, documentations... - Les critères de changement de phase, - Un cadre pour la gestion de projet. L'accent est mis sur les phases amont : analyse, conception et non plus seulement sur la programmation. Nous étudions différents modèles de cycle de vie au chapitre 2. Développement de méthodes structurées et d'outils CASE Dans les années 75-90 les méthodes structurées se développent (SA/RT, SADT, Ward et Mellor, modèle entités-relations...) ainsi que les métriques et outils permettant de les mettre en œuvre. (ateliers de Génie Logiciel ou outils CASE Computer.Aided.Software.Engineering). A cette époque, au sein des directions informatiques (et de l'organisation), de nouveaux services apparaissent : "méthodes et qualité", chargés de définir les bonnes pratiques en matière de développement logiciel, de choisir les bons outils CASE. Le langage ADA (83) développé à la demande du DOD (Department of Defense américain) est le fer de lance de cette rationalisation qui passe par un développement systématique et contrôlé par le Génie logiciel Anne-Marie Hugues 19/12/02 2-5

compilateur, ce langage est le premier à mettre à l'ordre du jour la réutilisation systématique d'éléments de bibliothèques ("packages") fournis avec le compilateur. De grands programmes de recherche sont lancés : Europe: ESPRIT, ALVEY, Software Factory Etats-Unis: ADA, STARS, SDI, Japon: 5ième Génération (ICOT) Le paradigme objet Dans les années 90 la crise n'est toujours pas résolue. Si les méthodes structurées s'avéraient efficaces pour traiter des programmes de 5000 à 50000 lignes, elles ne le sont plus pour des produits de 500.000 voire 5.000.000 lignes. Or les développements sont de plus en plus complexes, de plus en plus longs et l'obsolescence est de plus en plus rapide! Il y a donc une nécessité à réutiliser les connaissances et à les partager. Dans le domaine de la maintenance également, les méthodes structurées n'ont pas fait leurs preuves. Le problème vient du fait que les méthodes structurées sont soit orientées données soit orientées actions et que la modification d'un élément du logiciel impacte d'autres éléments de manière relativement imprévisible. Un nouveau paradigme voit le jour en 80 (Smalltalk) et devient très populaire dans les années 90, c'est le paradigme objets qui encapsule actions et données. Ceci facilite la maintenance car la localisation de l'erreur se fait plus facilement. L'objet masque la structure interne des données qui sont accédées uniquement à travers des messages. Chaque objet est autonome. En outre la définition de l'héritage et de la généricité permet la réutilisation d'objets déjà développés dans un autre contexte. dépôt retrait message message compte retrait dépot compte solde solde Approche structurée Figure 1. 3 : Introduction à l'approche objets message Approche objets Les années 90 ont ainsi vu l'avènement de nombreuses techniques visant à rationaliser le processus de développement : approche objets, normalisation des interfaces et des langages, définition d'orb (Object Request Broker) facilitant l'échange entre les différents objets composant un logiciel. Un écrémage au niveau des AGL s'est opéré. Des outils d'aide à la programmation rapide (?) utilisant des langages de 4ème génération permettent à des non informaticiens de définir rapidement leurs propres applications. La réutilisation systématique de biens logiciels oblige l'entreprise à revoir son processus de développement logiciel et vraisemblablement à se 1-6 Anne-Marie Hugues 19/12/02 Génie logiciel

réorganiser. Les environnements de programmation autour des langages objets Java ou C++ facilitent la réutilisation de bibliothèques de classes prédéfinies Modèles de cycles de développement la crise: coûts délais qualité 1970 Politique qualité, méthodes structurées outils GL : environnements CASE langages (ADA ) Micro informatique Bases de données Temps réel, systèmes embarqués 1980 1990 Paradigme objets outils GL: langages C++, Java ORB (CORBA) Réseaux, client/serveur hétérogénéité Aide à la décision datawarehouse Figure 1.4 : 30 ans d avancées technologiques et méthodologiques Approche composants Java beans Active X serveurs d applications Réseaux, Internet 3 tiers e-business Réutilisation 2000 L'approche composants Les années 2000 seront placées sous le signe de la programmation à base de composants réutilisables. Cette approche peut être vue comme une forme ultime de la programmation par objets, ou plus simplement comme un assemblage de briques logicielles prédéfinies, orientés techniques ou métiers, et conçues dans le but d'être réutilisées (ce qui n'est pas forcément le cas d'objets définis dans un contexte particulier et réutilisés par hasard). Cette démarche s'appuie sur les technologies Java Beans, active X mais nécessite une réorganisation du processus de développement logiciel. En conclusion, on peut dire que si la crise du logiciel est aujourd'hui résorbée parce que mieux connue, elle est loin d'être terminée même si les services méthodes et qualité ont disparu de la plupart des entreprises et que la direction de l'organisation n'est souvent plus qu'un vieux souvenir dans les organigrammes. C'est que les avancées rapides de la technologie rendent possibles des applications jusqu'alors inenvisageables et obligent sans cesse à reconsidérer les vérités que l'ont croyait acquises. L'informatique est aujourd'hui une industrie mure pour laquelle des éléments d'assurance qualité peuvent être mis en place et qui diffèrent selon le type de produit à fabriquer et le contexte dans lequel le produit sera utilisé : les contraintes seront différentes selon que l'on fabrique un logiciel amateur ou un logiciel professionnel, selon que le logiciel est stratégique pour une entreprise ou vital pour une population. Génie logiciel Anne-Marie Hugues 19/12/02 2-7

1.5 LES MOTEURS DE LA QUALITE Objectifs Les objectifs de qualité rejoignent bien souvent les objectifs de productivité - Adéquation aux besoins Efficacité temps/espace Fiabilité Sécurité, Intégrité Testabilité, Traçabilité Adaptabilité, Maintenabilité, Convivialité (interface, aide et documentation) Pérennité (facilité de la maintenance) L'assurance qualité vise à atteindre les objectifs de qualité, réduire le nombre d'erreurs résiduelles, maîtriser les coûts et la durée du développement sans nuire à l innovation et à la créativité. Les moteurs de l'assurance qualité sont multiples : on peut citer L'organisation du processus : découper le processus pour le maîtriser Les ressources humaines : les équipes doivent être motivées pour mettre en place des procédures qualité L'utilisation de techniques, méthodes, outils Les considérations managériales, politiques et économiques : considérer le retour sur investissement de la mise en place de procédures qualité par une analyse coûts bénéfices. Nous revenons sur chacun de ces aspects dans les chapitres concernés. Organiser le processus : cycle de vie, responsabilités, rôles Comme tout produit, un logiciel a un cycle de vie, il naît, vit et meurt ; autrement dit, il est créé, distribué sur un marché ou bien mis en exploitation et disparaît pour cause d'obsolescence. La phase de maintenance évolutive a pour objectif de retarder la phase de disparition. Le cycle de développement des logiciels s'insère dans le cycle de vie global du produit, on l'appelle souvent abusivement cycle de vie des logiciels. Figure 1.5 Cycle de vie d'un produit Retardement de la disparition par la maintenance évolutive La maîtrise du processus de développement passe par un découpage en activités - Séquentielles (verticales) : Spécifications, Conception, - Permanentes (horizontales) : Gestion de projet, Gestion des configurations Chaque activité sera validée avant de passer à la suivante. Chaque projet est découpé en éléments maîtrisables. Par exemple au niveau de la conception globale on essaiera de décomposer en modules aussi indépendants que possible, ce qui facilitera le codage, l'intégration et la maintenance. 1-8 Anne-Marie Hugues 19/12/02 Génie logiciel

Ce découpage est garant d'efficacité et de motivation des équipes : il est plus facile de respecter un objectif à court terme qu'à moyen ou long terme Chaque activité élémentaire, chaque phase est placée sous la responsabilité d'un acteur, les recommandations pour l'assurance qualité insistent toutes sur la notion rôle, il faut définir - Qui fait, - Qui approuve, - Qui vérifie, - Qui valide, - Qui est consulté. L'enchaînement des activités est défini à l'avance selon l'un des modèles de processus qui sera vu au chapitre 2. tâches Est responsable équipiers processus Productions intermédiaires outils méthodes Figure 1.6 : Organiser le processus Gestion des ressources : gestion de projet, gestion des configurations Comme tout projet industriel, un projet logiciel nécessite une gestion stricte des ressources tant humaines que matérielles et logicielles. Cette activité est transversale au projet et met en œuvre des techniques communes à tout type de projet ainsi que d'autres plus spécifiques que nous étudierons au chapitre 3. Il s'agit ici de savoir évaluer coûts et délais définir et ordonnancer les tâches, planifier la réalisation, l'intégration, la validation établir un système de contrôle pour tous les produits intermédiaires du cycle de vie, dans le but de détecter le plus tôt possible: défauts, erreurs, omissions, ambiguïtés, incohérences, hypothèses incorrectes,. organiser la formation sur les méthodes, les outils, les nouvelles technologies motiver les équipes, anticiper les problèmes, ne pas brider la créativité, détecter la résistance au changement La gestion de configurations est spécifique aux projets logiciels. Les produits logiciels sont constitués de différents éléments qui évoluent au cours du temps et qui peuvent différer d'une installation à l'autre. La gestion des configurations est activité transversale essentielle qui consiste à Génie logiciel Anne-Marie Hugues 19/12/02 2-9

contrôler l'ensemble des données constituant le système: documents sources jeux de tests plans d'intégration. assurer la cohérence des divers composants construire/reconstruire un système pendant tout le cycle de vie (développement et maintenance). De nombreux outils existent qui facilitent cette tâche, sous Unix la conjonction de make/rcs permet de gérer les versions et la reconstruction du système. Méthodes, techniques et outils de production et de mesure L'analyse, la conception, le développement et le test du produit constituent le cœur de la production logicielle. Depuis les années 80, de gros efforts ont été faits sur les outils permettant de rationaliser et/ou automatiser ces tâches. Dans la suite du cours on insistera particulièrement sur - les méthodes de spécification et de conception qu'elles soient structurées ou orientées objets - les méthodes de validation et vérification - l'outillage : le poste de travail de l'ingénieur logiciel les ateliers de génie logiciel incluant outils d'analyse, générateur de code, environnement de développement et de mise au point, outils de tests, outils de mesures de performances L'amélioration d'un processus passe par sa connaissance précise, il est nécessaire d'organiser des collectes de données pour mesurer: - Coûts, - Délais, - Qualité.(taille, temps, complexité) Actuellement de nombreux outils sont disponibles sur le marché pour aider à ces mesures (outils de planification, outils d'analyse statique de code ) 1.6 ASSURANCE QUALITE Définition Assurance qualité : "Mise en œuvre d'un ensemble approprié de dispositions préétablies et systématiques destinées à donner confiance en l'obtention de la qualité requise." (AFNOR) Plus précisément toutes les normes qualité insistent sur trois aspects essentiels : communication, contrôle, organisation. Organisation Le processus de développement est classiquement organisé en différentes phases conformément à la figure 1.7 1-10 Anne-Marie Hugues 19/12/02 Génie logiciel

planifier Spécifier Définir les besoins Supporter concevoir Distribuer Développer valider Qualifier Figure 1.7 : Les phases du cycle de vie d'un produit logiciel Une tâche essentielle du chef de projet est d'organiser ces différentes phases et de les lier à des activités en y affectant les ressources nécessaires tant humaines que logicielles ou matérielles. L'enchaînement des activités constituera le workflow du projet.. Chaque activité débouche sur un produit intermédiaire dont la production détermine la fin de l'activité et qui devra être contrôlé avant de passer à l'activité suivante. Contrôle L'assurance qualité passe par des contrôles réguliers et inclut - la validation(du latin "VALIDARE", déclarer valide) permet de répondre à la question "sommes nous en train de faire le bon produit? " - la vérification(du latin "VERITAS ", la vérité): répond à la question "est ce que nous faisons le produit correctement" Comme le montre la figure 1.8 les erreurs sont de plus en plus coûteuses à réparer lorsqu'elles sont découvertes tard dans le cycle de vie: d'où le rôle primordial de contrôles intermédiaires. La validation et la vérification sont en partie garanties par la mise en place des d'inspections, revues, relectures pour tous les produits intermédiaires du développement (prototypes/ maquettes, documents de spécification, de conception, code, jeux de tests) Génie logiciel Anne-Marie Hugues 19/12/02 2-11

400 300 Projets 74-80 IBM AS /400 (94) 200 100 0 besoins planification codage specification conception maintenance intégration Figure 1.8 coût relatif de correction des erreurs en fonction de leur découverte, source IBM L'inspection est une lecture critique d'un document (spécification, conception, code, plan d'intégration...); elle est destinée à améliorer la qualité d'un document. De manière générale, l'inspection est faite par une équipe indépendante du projet constituée par: un Modérateur, un Experts(s), Secrétaire, le client, éventuellement un banquier, un représentant du service qualité... Pour qu'elle puisse être profitable, une inspection doit donner lieu à la rédaction de fiches de défauts avec une échelle de gravité et la définition des responsabilités concernant la correction des défauts. Les inspections sont à la base des décisions prises en revues. Une revue est une réunion permettant de valider une des phases du cycle de vie. On distingue - les revues produits: état d'un projet sous ses différents aspects: Techniques, Financiers, Commerciaux, Calendrier,... - les revues techniques (celles qui nous intéressent le plus dans le cadre de ce cours): elles permettent de fournir au marketing et à l'unité de développement une évaluation des aspects techniques du projet et des coûts de réalisation - les réunions de décision: elles valident le passage à la phase suivante et font bien souvent suite à l'une des deux précédentes. Exemple d'après Boehm Un logiciel de réservation aérienne (Univac-United Airlines) d'un coût de 56 millions de dollars a été jugé inutilisable par manque d'analyse des besoins et d'étude de faisabilité: - 146 000 instructions par transaction, - au lieu de 9 000 prévues. Ceci aurait pu être évité par des inspections et des revues intermédiaires et l'analyse d'un prototype Communication Même si l'assurance qualité ne doit pas être confondue avec une production intensive et bureaucratique de documentation, elle insiste sur la nécessité de communiquer à différents niveaux: 1-12 Anne-Marie Hugues 19/12/02 Génie logiciel

- entre développeurs et environnement, (clients avant le développement, support pendant la phase de maintenance) : cahier des charges, dossier d'analyse, manuel d'installation, dossier de conception, plan projet, plan qualité - entre les développeurs. (dossier d'analyse, dossier de conception, plan qualité, commentaires du code, résultats de tests ) Certains documents sont plus spécifiquement dédiés à la gestion de la qualité, il s'agit du manuel qualité de l'entreprise et du plan qualité du projet. Manuel qualité Le manuel qualité décrit les procédures définies par une entreprise ou une organisation pour atteindre ses objectifs de qualité. Il répertorie les méthodes et procédures à utiliser pour: - Gestion de projets - Réalisation, Vérification, Validation, - Evaluation de la Qualité (Mesures). en s'appuyant sur: - Rédaction de standards, normes (ISO, DOD..), conventions, guides, - Expérience acquise des projets, pour améliorer le processus. Plan qualité Le plan qualité logiciel définit, pour un projet donné, en accord avec le manuel qualité de l'entreprise, les méthodes techniques et outils permettant d'atteindre les objectifs de qualité pour un coût donné. Le plan qualité fait partie des éléments contractuels liant un client et son fournisseur de logiciels. Il est établi lors de la phase de planification. Des exemples de plan qualité sont fournis au chapitre 3. 1.7 NORMES QUALITE Les procédures qualité s'appuient sur la rédaction de normes et de standards, on citera particulièrement : la norme DOD 2167 A pour les applications militaires, la norme ISO 9001 (ISO 9000-3 ) pour les applications civiles adoptée par 60 pays (USA, Europe, Japon...). C'est aujourd'hui un passage quasi obligé pour une SSII d'être estampillée ISO 9001 pour pouvoir répondre à un appel d'offres. Il est à noter que la certification est payante et valable 3 ans. La norme ISO 9000 devrait être remplacée en 2001. La grille CMM n est pas une norme, elle peut toutefois servir de référence pour une exigence de qualité. La norme ISO 9001 ISO : ISO 9000 ISO 9000-1 ISO 9001 : ISO 9003 : International Standardization Organization ensemble de recommandations et standards pour la garantie de la qualité dans les relations clients-fournisseurs (pas spécialement logiciel) recommandations pour l utilisation de ces standards le standard à utiliser pour la fourniture de logiciels, la référence en matière de certification pour le logiciel guide pour l utilisation des standards ISO 9001 pour la fourniture de logiciels Génie logiciel Anne-Marie Hugues 19/12/02 2-13

Philosophie ISO 9001 : Toute opération influençant la qualité doit être sous contrôle. Le contrôle doit être visible Le chapitre 4 de la norme définit les 20 éléments de qualité à respecter Responsabilités du management Définition d un système de qualité Analyse du contrat entre client et fournisseur Contrôle de la conception Documentation et contrôle des données Spécification des achats et fournitures Contrôle des produits fournis par le client Identification des produits et traçabilité Contrôle du processus Nécessité de mettre en œuvre des tests et inspections Contrôle des inspections et tests, mesures des outils de tests Statut des tests et inspections Contrôle des produits non conformes Actions correctives et préventives Emballage, stockage, livraison, Contrôle des enregistrements concernant la qualité Audit qualité internes Organiser la formation Service après vente Techniques statistiques On voit bien sur cette liste que ISO 9001 ne vise pas spécialement la fourniture de logiciels et doit être adaptée dans le cadre d une assurance qualité en logiciel. Recommandations ISO 90003 pour la fourniture de logiciels : Il s'agit d'un guide de recommandations équivalent à un standard (lors de toute certification, il faudra justifier tout manquement à ces recommandations). Définir le cadre de l assurance qualité Responsabilités du management Les responsabilités du management recouvrent : la définition d une politique qualité, la mise en place d une organisation et la validation périodique du système qualité. Définition d un système qualité La politique qualité doit être documentée dans un manuel qualité conforme aux normes en vigueur et aux habitudes de l entreprise. Il est important que les procédures qualité mises en place trouvent l agrément des développeurs et ne soient pas perçues comme un frein à leur créativité mais plutôt comme un cadre rassurant dans lequel ils pourront évoluer et produire un travail de qualité. Evaluation du contrat Il est tout à fait indispensable de ne pas s engager sur un contrat irréaliste. Contrôler le développement Ce paragraphe vise à encourager le fournisseur à documenter et contrôler le processus de développement. 1-14 Anne-Marie Hugues 19/12/02 Génie logiciel

Planification du développement et de la qualité Définition du calendrier, des différentes phases du projet, des critères qualité Organisation du travail En particulier organisation des espaces de travail Contrôle des Spécifications (Design input) ISO 9000 requiert des spécifications rigoureuses et complètes. En logiciel tout le monde sait que ceci est en général un vœu pieux. Un autre paragraphe des recommandations prévoit donc les procédures de prise en compte de changements dans les spécifications. Afin de définir ces spécifications, des outils peuvent être utilisés (en particulier tous les outils d aide à l analyse tels que AMC Designor, Rational Rose Sortie de la conception (Design output) La conception peut être réalisée à la main, elle peut également être générée plus ou moins automatiquement. Dans tous les cas, la phase de conception doit produire une architecture logicielle et de la documentation Contrôle de la Conception (Design review), Dans tous les cas la conception nécessite un contrôle rigoureux par des inspections qui peuvent être réalisées au moyen de listes de défauts typiques. Pour moi ces trois subtilités des recommandations sont redondantes entre elles et je les ai réunies dans un même paragraphe. Validation vérification ( Design verification, Design validation) Il s agit ici des procédures de validation/ vérification du code. Elles sont classiquement réalisées à base d analyse statique, de tests fonctionnels et de tests structurels. Le Béta test pris en charge par le client doit explicitement figurer dans le contrat si une telle décision de qualification est adoptée. Il est tout à fait fondamental d être capable de rendre compte des résultats des tests et des jeux de tests qui ont été effectués. Les critères d arrêt doivent être définis dans un plan de tests, on doit pouvoir prouver qu on les a atteints. Modification de la conception et des spécifications Il faut vérifier la cohérence des changements demandés avec le développement déjà réalisé. ISO9000 requiert une procédure rigoureuse d acceptation des modifications Gérer les activités de support Gestion des configurations : Déjà vu. Gestion de la documentation et des données Le standard demande que quiconque a besoin des documents puisse y accéder. Le standard demande que tout document soit approuvé et que les versions des documents soient cohérentes entre elles et cohérentes avec le code qu elles documente. Contrôle des Achats, de la sous-traitance, et des fournitures procurées par le client Les recommandations de la norme dans ces domaines tout à fait fondamentaux ne concernent pas vraiment ce cours. Traçabilité Cette rubrique concerne le suivi tout au long du cycle de développement des liens qui peuvent exister entre cahier des charges et spécifications, spécifications et conception, conception et codage. Génie logiciel Anne-Marie Hugues 19/12/02 2-15

La norme impose de savoir répondre aux questions suivantes De quel document initial cette spécification s inspire-t-elle? A quelle spécification, à quel document de conception ce bout de code est il relié? Quelles sont les corrections ou améliorations qui ont été réalisées dans tel module? A partir de quel code source cet exécutable a-t-il été généré A partir de quel outil cet exécutable a-t-il été généré? Qu est il advenu de chaque rapport d incident? A t il été pris en compte, corrigé? la nouvelle version a-t-elle été distribuée? C est souvent à cause de ce chapitre que les impétrants à la certification se font rejeter. Voici quelques exemples La mauvaise version d un fichier source a été cataloguée Un erreur est répertoriée comme réparée et ne l est pas Un manager ou un chef de projet a été incapable de montrer quelles versions des sources étaient utilisées au moment des tests Incapacité de montrer les différentes demandes de modifications ou rapports d incidents Contrôle de production (process control) Il s agit ici du contrôle de la production des disquettes, CD ou tout autre media sur lequel le produit final sera livré. Le contrôle de production du développement a été vu précédemment. A vérifier également que la bonne version soit livrée en ce qui concerne les bibliothèques, jeux de tests, documentation Inspection et tests Là encore il s agit d inspecter le matériel livré (disquettes.. ), la validation du code ayant été vue précédemment. Contrôle des équipements de tests Peu applicable en informatique. On peut par exemple tester les horloges pour les programmes temps réel Statut des Inspections et tests ( Inspection and tests status) On doit pouvoir à tout moment savoir si un document, un code source a été inspecté, validé ou est en attente de validation. En aucun cas un document non validé ne doit servir de base à de nouveaux développements. Les documents inspectés et validés doivent être conservés dans un espace différent de ceux qui ne le sont pas. Contrôle des produits non conformes Les produits non conformes doivent être identifiés. On doit pouvoir fournir une procédure qui permet de corriger rapidement les erreurs et de valider les modules ainsi corrigés. Actions correctives et préventives La norme est assez floue à ce propos car elle ne prévoyait pas l amélioration des produits ; alors qu en informatique les produits évoluent dans le temps. Le paragraphe 4.14 donne quelques indications qui de mon point de vue sont redondantes avec les notions de traçabilité vues précédemment S assurer qu il existe une procédure de report des erreurs, s assurer que toute erreur reportée est un jour corrigée, pouvoir répondre sans hésiter à la question «telle erreur a t elle été corrigée. Stockage, livraison, emballage Une fois les produits développés, il faut les stocker, les emballer et les acheminer vers le client, cette étape a peu de rapports avec le cours mais doit être envisagée avec attention ( par exemple étiqueter les CD rom peut prendre un certain temps ) 1-16 Anne-Marie Hugues 19/12/02 Génie logiciel

Contrôle des enregistrements qualité On veillera à garder trace de tous les enregistrements qualité effectués en interne (inspection, tests..) et chez les clients (mesures statistiques en particulier, erreurs reportées et le sort qui leur a été réservé ) Audit qualité interne Il s agit de vérifier que les plans qualité sont respectés dans l entreprise de manière générale. On pourra le prouver si on a fait une procédure sérieuse de collecte de données. Il faut pouvoir produire une procédure d audit lors de la certification ou de son renouvellement. Formation La norme encourage la formation programmée à tous les niveaux: - Nouvelles techniques, nouveaux langages - Formation aux méthodes qualité - Formation aux méthodes de gestion de projet Service après vente Prévoir un contrat de maintenance. On a déjà abordé le fond du problème précédemment. Les critiques qui sont émises en général par rapport à ce paragraphe : - Pas de contrat de maintenance - Méthode de maintenance spécifiques pour un vieux produit non documentée - Pas de procédures de maintenance - Rien de prévu pour tester après une activité de maintenance (en général on peut au moins repasser et mettre à jour les tests de non régression) Méthodes statistiques Dans une industrie de production il est important de pouvoir prélever des échantillons au hasard et de les tester. En logiciel rien de commun. Les tests statistiques consistent à faire des mesures a posteriori en phase d exploitation: - Nombre de pannes - Nombre d erreurs découvertes (par le client, par le fournisseur) - Temps moyen entre deux pannes - Durée moyenne d indisponibilité. Le Capability Maturity Model La grille de maturité du Software Engeering Institute de Carnegie mellon University (SEI) aujourd hui appelée Capability Maturity Model 4 est certainement une rivale de la norme ISO 9000 (ou plus exactement des recommandations ISO 9000-3) en matière de qualité de développement de produits logiciels. Développé dès les années 70 pour le compte du DOD qui souhaitait évaluer ses sous traitants, ce modèle a été largement adopté dans le civil. Le SEI est encore aujourd hui largement soutenu par le DOD. Le principal intérêt que ses promoteurs et ses adeptes voient au modèle CMM est son élaboration en vue d une utilisation dans un contexte de développement logiciel et non pas, comme c est le cas pour ISO 9000, une adaptation d une norme multi-domaines au cas particulier du génie logiciel. 4 Le CMM a été introduit en 1986, il s'appelait alors Process maturity model. Aujourd hui un autre modèle voit le jour : le Personnal Software Process qui permet à chaque ingénieur de s améliorer personnellement contrastant en cela avec le CMM qui vise lui à l amélioration globale de l organisation. Des résultats récents prouvent que l utilisation du PSP contribue à l amélioration de la qualité et de la productivité globale. Génie logiciel Anne-Marie Hugues 19/12/02 2-17

Par ailleurs, le CMM permet à ses utilisateurs de se positionner dans une grille sur laquelle ils pourront évoluer et progresser, ce qui n est pas prévu dans la norme ISO 9000. Toutefois étant donnée la popularisation de la norme ISO 9000 en Europe et dans le Monde, il est indéniable qu une certification ISO 9000 permet de remporter un certain nombre de marchés et cet aspect ne doit pas être négligé. Nous verrons qu il peut éventuellement en être de même avec CMM. Philosophie CMM : La grille CMM permet de classifier une organisation (SSII ou service informatique d une entreprise) qui développe du logiciel selon sa compétence. Cette grille identifie 5 niveaux de maturité (d où son nom) pour ces organisations 1 niveau initial : le logiciel est développé sans méthode prédéfinie. Le développement repose sur la compétence de quelques personnes, il est impossible de récupérer l expérience acquise dans un projet lors du développement d un autre projet, on ne peut prédire en terme de gestion de projet des éléments aussi importants que la taille ou le coût d un projet. Les réactions se font essentiellement en fonction des crises et non pas de façon systématique et planifiée. Beaucoup d organisations sont malheureusement encore aujourd hui assez proches du niveau 1 2 niveau reproductible (repeatable) : il existe un système commun de management de projet et des techniques de contrôle. La gestion de projet et la planification sont faites sur des bases reproductibles. Des activités de mesures commencent à être mises en place, en particulier au niveau des coûts et des délais. On réagit de façon planifiée et non plus en fonction des crises. Les problèmes sont traités au fur et à mesure qu ils arrivent et ne sont pas accumulés jusqu à provoquer une crise majeure. Les mesures utilisées pendant un projet permettent de prévoir ce qui sera susceptible de se passer pour les projets futurs. 3 défini : il existe un système commun pour toutes les activités de développement de logiciel à la fois du point de vue managérial et technique. Des mesures sont faites régulièrement pour améliorer le processus. Des revues sont mises en place afin de garantir la qualité du logiciel. 4 géré (managed) : le procédé de développement logiciel est stable et permet de garantir un niveau constant de qualité. Des objectifs précis de qualité et de productivité sont affectés à chaque projet. Des mesures régulières 5 permettent de garder sous contrôle ces deux indicateurs, et des actions correctrices sont prises dès qu une divergence par rapport aux objectifs est constatée. Des procédés de mesure statistiques sont mis en place afin de déterminer s il s agit d un manquement passager aux objectifs ou bien s il s agit d une divergence grave par rapport aux standards de productivité et de qualité. Bien que de nombreuses entreprises aient atteint les niveaux 2 et 3, pratiquement aucune n est encore arrivée aux niveaux 4 et 5 qui sont donc des objectifs pour les prochaines années. 5 Par exemple le nombre de fautes détectées sur 1000 lignes de code, l objectif correspondant peut être de diminuer ce chiffre 1-18 Anne-Marie Hugues 19/12/02 Génie logiciel

5 en optimisation constante (optimizing) : le processus de développement porte en lui les moyens de réaliser sa propre optimisation. Des contrôles statistiques sur le processus sont utilisés pour guider l organisation. Le processus intègre un feed back provenant de ces mesures. Pour pouvoir s améliorer l organisation doit avoir connaissance de son niveau de maturité actuel et définir celui auquel elle souhaite arriver. Le CMM lui donne des indications sur les actions à entreprendre, c est à dire une liste d objectifs intermédiaires qui lorsqu ils seront tous atteints conféreront à l organisation le niveau qu elle vise. 6 Elle fixe elle-même les priorités et définit un plan d action. Le SEI produit des questionnaires que les organisations remplissent et qui servent de base à un audit réalisé par des équipes du SEI. Le but est de mettre en évidence les lacunes de l organisation et de l aider à établir son plan d action pour atteindre le niveau souhaité. Les expériences montrent que le passage d un niveau à un autre peut durer de 18 mois à 3 ans. Mais le passage du niveau 1 au niveau 2 dure en général de 3 à 5 ans. Les apports du CMM Des résultats publiés montrent que se positionner dans la grille CMM permet d accroître la rentabilité. Par exemple le département Logiciel de Hughes Air Craft à Fullerton Californie a dépensé environ 500.000$ entre 87 et 90 pour améliorer son processus de production de logiciels. Pendant cette période ils sont passés du niveau 2 au niveau 3, avec de bons espoirs d atteindre les niveaux 4 et 5. Ils estiment qu aujourd hui ils économisent 2 millions de $ par an, ces économies proviennent de la diminution du nombre de crises, du nombre d heures supplémentaires, de l amélioration de la compétence des employés et la diminution du turnover. Ceci n est qu un exemple pris parmi tant d autres. Une entreprise qui est passée du niveau 1 au niveau 3 en 1993 a constaté un retour sur investissement de 7.70 pour 1. Un article fait état de résultats constatés sur 1300 projets et compare les durées, coûts et qualité suivant le niveau de l entreprise dans la grille CMM. Les chiffres sont particulièrement éloquents, mais il faut tout de même souligner qu il ne s agit que de résultats obtenus par modélisation pour les niveaux 4 et 5. CMM Durée En mois calendaires Effort En hommes mois. Fautes détectées pendant Fautes détectées chez le client Coût total de développement le développement Niveau 1 29.8 593.5 1348 61 5 440 000$ Niveau 2 18.5 143 328 12 1 311 000$ Niveau 3 15.2 79.5 182 7 728 000$ Niveau 4 12.5 42.8 97 5 392 000$ Niveau 5 9.0 16 37 1 146 000$ Comparaison Iso9000 - CMM ISO 9000 est une norme, CMM n en est pas une CMM est dédié à l industrie du logiciel, ISO 9000 définit un cadre pour les rapports clients fournisseurs. 6 Par exemple pour atteindre le niveau 2, l organisation devra mettre en œuvre des procédures d assurance qualité (en particulier détection et correction des défauts), une gestion de configurations sérieuse, des méthodes de gestion de projet. Au niveau 5, les prérequis sont plutôt la prévention des défauts (et non plus leur correction comme au niveau 2) et l assurance zéro défaut (par la mise en œuvre de techniques de preuves par exemple) Génie logiciel Anne-Marie Hugues 19/12/02 2-19

CMM est plus détaillé et spécifique. ISO 9000 établit un niveau acceptable de management de projet auquel le fournisseur doit souscrire pour que les relations client-fournisseur puissent s établir avec certaines garanties de qualité pour le client ; alors que CMM permet au fournisseur de s auto-évaluer et de progresser sur une grille allant de 1 à 5. Plusieurs articles sont parus qui établissent qu une entreprise de logiciel certifiée ISO 9000 atteint à peu près le niveau 2 et réciproquement. Certaines exigences d ISO 9000 et en particulier toutes celles faisant référence au client, ne sont absolument pas couvertes par CMM (par exemple la notion de contract review, la notion d actions correctives et préventives ) Il semble plus facile d atteindre le niveau 2 en CMM que la certification ISO 9000. Toutefois cette dernière étant parfois vitale pour une entreprise on pourrait conseiller de se servir de la grille CMM pour progresser en vue d une certification ISO 9000. Il est à noter que le CMM prend de plus en plus d importance, en particulier, Le département de l US Air Force a stipulé que toute entreprise souhaitant répondre à l un de ses appels d offres doit avoir atteint le niveau 3 du CMM en 1998, ceci devrait s étendre à l ensemble du DOD. Le projet SPICE Le projet SPICE (Software Process Improvement and Capability determination) est un effort conjoint de l'iso et de l'iec pour créer un standard international d'amélioration du processus de production du logiciel. Il s'appuie sur les recommandations du SEI et l'auto évaluation sur la grille CMM et s'inspire des recommandations ISO 9000 en matière de rapports clients/fournisseurs. La grille SPICE comporte 10 niveaux, les méthodes d'évaluation ont une granularité plus fine. La norme SPICE devrait entrer en vigueur en 2001. 1.8 REFERENCES F. BROOKS The Mythical Man-Month Addison-Wesley, 1982 B. BOEHM Software Engineering Economics Prentice-Hall, 1981 1-20 Anne-Marie Hugues 19/12/02 Génie logiciel