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

Génie logiciel Anne-Marie Hugues © 19/12/02 1-1

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é .

Nouveau système ou système modifié

Processus de production de logiciels

Nouveaux besoins

ou besoinschangés

composantsSystèmeexistant

cahier des charges ou prototype

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.

1-2 Anne-Marie Hugues © 19/12/02 Génie logiciel

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 programme3 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


PROGRAMME

PROGRAMMEINTEGREDANS UN SYSTEME(Interfaces, Intégration, ...)

PRODUITLOGICIEL

(Généralisation, Tests,

Documentation, Maintenance)

PRODUITLOGICIEL

INTEGREDANS 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).


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.

1945

Logicielssur mesurecalculscientifique

AssembleurENIAC

1958 1990

FORTRANCOBOLmulti-utilisateurssystèmes propriétairessystèmes de fichiersbatch, temps réel

Logicielsscientifiqueset de gestion Micro informatique

pucessystèmes distribuésclient-serveurBases de donnéesUnixpuces

Logiciels scientifiquesTemps réel,progiciels ERPembarqués,

2000

Réseaux,InternetIntranet3 tiersserveursd ’applications

1970

Informatique partoutfiabilitésécuritéaide à la décisione-business

crise

Figure 1.2 : 50 ans d'informatique 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 (e-commerce) 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


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


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

solde

solde

retraitdépot

compte compte

message

message message

Approche structurée Approche objets Figure 1. 3 : Introduction à l'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


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

1970

la crise:coûtsdélaisqualité

Modèles decycles dedéveloppement

1980 1990

Micro informatiqueBases de donnéesTemps réel, systèmesembarqués

Politique qualité,méthodes structuréesoutils GL :environnements CASElangages (ADA…)

Réseaux,client/serveurhétérogénéitéAide à la décisiondatawarehouse

Paradigme objetsoutils GL:langages C++, JavaORB (CORBA)

2000

ApprochecomposantsJava beansActive Xserveursd ’applications

Réseaux,Internet3 tierse-businessRéutilisation

Figure 1.4 : 30 ans d’avancées technologiques et méthodologiques

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….


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

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.

Retardement de la disparition par la maintenance évolutive


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.

processus

tâches

Productionsintermédiaires

outils

méthodes

équipiersEstresponsable

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 à


− 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


SpécifierSupporter

Distribuer

Qualifier

validerDévelopper

Définir les besoins

planifier

concevoir

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)


400

300

200

100

0besoins

specificationplanification

conceptioncodage

intégrationmaintenance

Projets 74-80

IBM AS /400 (94)

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:


- 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 : International Standardization Organization ISO 9000 ensemble de recommandations et standards pour la garantie de

la qualité dans les relations clients-fournisseurs (pas spécialement logiciel)

ISO 9000-1 recommandations pour l’utilisation de ces standards ISO 9001 : le standard à utiliser pour la fourniture de logiciels, la référence

en matière de certification pour le logiciel ISO 9003 : guide pour l’utilisation des standards ISO 9001 pour la

fourniture de logiciels


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.


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.


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 …)


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 Model4 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.


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ères5 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


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 turn-over. 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 le développement

Fautes détectées chez le client

Coût total de 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)


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.LA PROBLEMATIQUE DU LOGICIEL

Documents

Transcript of 1.LA PROBLEMATIQUE DU LOGICIEL