ELEMENTS D’ELABORATION D’UN MODELE DE TESTS DE VERIFICATION ET DE VALIDATION DANS UN PROJET DE DEVELOPPEMENT MIXTE : L’EXEMPLE DE PAYMENT MANAGER 1.0.

Dodi Alphonse Mbuta Ikoko

Description

Les tests logiciels restent une approche incontournable dans le développement logiciel, surtout avant la mise en production du produit – logiciel développé.
En RD Congo, la pratique de tests semble n’est pas encore du tout formalisée dans la personne des professionnels TI congolais. Ceux qui s’aventurent la réalisent sans le respect des référentiels normatifs applicables. C’est pourquoi, avec notre retour d’expérience de chef de projet Ident – ITS à l’UEPN – DDR, dans le cadre d’un développement en impartition, avec la firme BIO – ID Technologies SA, du logiciel « Payment Manager », nous avons jugé bon de fournir à notre communauté des éléments adaptés aidant à l’élaboration d’un modèle de tests logiciels sous la forme d’une ébauche unifiée et simpliste. Elle est produite à partir à partir de l’expression de besoins des utilisateurs, des processus et/ou règles métiers de l’UEPN – DDR, etc. qui ont été, par la suite, formalisés en modèle d’exigences fonctionnelles. Utilisant une démarche de modélisation empruntée à l’IDM, cette ébauche a donc pour but de faciliter la réalisation et l’exécution de tests logiciels de niveau supérieur (système et validation) par une équipe de développement logiciel suivant les conditions contractuelles et environnementales. C’est donc un élément d’entrée de jeux à produire par les acteurs impliqués dans un projet de développement lors de la remise en question ou pas du produit – logiciel attendu des utilisateurs.

Informations

• Publié par: admik
• Publié le: 23 mars 2015
• Nombre de lectures: 31
• Licence : En savoir +
  Paternité, partage des conditions initiales à l'identique
• Langue: Français
• Poids de l'ouvrage: 2 Mo

Extrait

Les cahiers de BSD Congo n°4, mai 2011 ELEMENTS D’ELABORATION D’UN MODELE DE TESTS DE VERIFICATION ET DE VALIDATION DANS UN PROJET DE DEVELOPPEMENT MIXTE : L’EXEMPLE DE PAYMENT MANAGER 1.0. 1 Contribution de MBUTA IKOKO Dodi Alphonse Spécialiste MIS et Chargé de Projet Ident et ITS à l’UEPN-DDR Conseiller TI et Responsable de la cellule Recherche et Développement de BSD Congo, Assistant d’enseignement et de recherche en informatique et MIS Département d’Informatique de Gestion, Université Libre de Kinshasa, RD Congo & Section Informatique, Institut Supérieur de Commerce de Kinshasa, RD Congo Email:[e-mail]/[e-mail] Mai 2011 Contact, « Les cahiers de BSD Congo » Téléphone : [phone] / [phone] Email :[e-mail] Site Internet :http://www.bsdcongo.org Dans le cadre de sa politique de vulgarisation des méthodes et outils TI et pour un meilleur partage du savoir libre en RD Congo, l’Association BSD Congo a créé depuis 2009, via la cellule « recherche et développement » qui œuvre au sein de son équipe technique, une note de communication et de partage d’expérience dans le domaine des TI, appelée « Les cahiers de BSD Congo », documents de travail ou de pré - publications n'excédant pas quarante pages. Ils sont diffusés et mis à la disposition des membres/partenaires de BSD Congo et du public, via Internet, dans une perspective d’échanges et de partage du savoir TI. Ces échanges se réalisent dans un souci de réciprocité et de libre circulation de préoccupations professionnelles ou scientifiques. Leur contenu n'est pas définitif et peut être sujet à discussion. Ils ne constituent donc qu'une étape dans la démarche scientifique. Résumé Les tests logiciels restent une approche incontournable dans le développement logiciel, surtout avant la mise en production du produit – logiciel développé. En RD Congo, la pratique de tests semble n’est pas encore du tout formalisée dans la personne des professionnels TI congolais. Ceux qui s’aventurent la réalisent sans le respect des référentiels normatifs applicables. C’est pourquoi, avec notre retour d’expérience de chef de projet Ident – ITS à l’UEPN – DDR, dans le cadre d’un développement en impartition, avec la firme BIO – ID Technologies SA, du logiciel « Payment Manager », nous avons jugé bon de fournir à notre communauté des éléments adaptés aidant à l’élaboration d’un modèle de tests logiciels sous la forme d’une ébauche unifiée et simpliste. Elle est produite à partir à partir de l’expression de besoins des utilisateurs, des processus et/ou règles métiers de l’UEPN – DDR, etc. qui ont été, par la suite, formalisés en modèle d’exigences fonctionnelles. Utilisant une démarche de modélisation empruntée à l’IDM, cette ébauche a donc pour but de faciliter la réalisation et l’exécution de tests logiciels de niveau supérieur (système et validation) par une équipe de développement logiciel suivant les conditions contractuelles et environnementales.C’est donc un élément d’entrée de jeux à produire par les acteurs impliqués dans un projet de développement lors de la remise en question ou pas du produit – logiciel attendu des utilisateurs. 1 L’auteur de cette contribution remercie les lecteurs pour leurs judicieuses remarques et suggestions. Il tient aussi à les signifier qu’une partie de ce texte a fait l’objet d’une présentation lors d’un « atelier de BSD Congo » sur le développement informatique avec un groupe d’étudiants du Département des Mathématiques et Informatique de l’Université de Kinshasa, au mois de Juin 2010.

Mots clés : Projet de développement logiciel mixte – Tests logiciels – Méthodes et outils de gestion de tests – Exigences pour la vérification et la validation – Modèle de tests système. I.INTRODUCTION Dans le domaine de développement et/ou de construction des logiciels (intangibilité), appelé « Génie logiciel », mais aussi celui de conception des systèmes d’information (complexité), classiquement, une fois les premières phases de développement terminées (l’analyse des besoins, la spécification globale, la conception détaillée et la programmation), les activités les plus visibles et les plus décisives qui permettent à l’équipe de développement et/ou de projet TI de pouvoir autoriser la phase d’installation ou de déploiement du produit – logiciel développé (déterminisme) sont celles detests logiciels. Ces activités visibles de vérification mais aussi de validation, orientées mode projet, sont menées dans le seul but de s’assurer que le produit – logiciel développé est correct et répond aux exigences formulées ou convenues au départ par le maître d’ouvrage et le maître d’œuvre. Elles offrent donc, ces activités de tests, une approche expérimentale de résolution de problèmes de conception logicielle par des méthodes et des outils de génie logiciel (Luc Lavoie, 2007). Elles font donc partie des gages de succès, surtout pour des projets informatiques de développement logiciel exécutés en impartition et/ou en partenariat (mixte). En RD Congo, la plupart des développements informatiques sont actuellement réalisés en impartition et/ou en partenariat, mais toujours de manière brute, et n’admet presque pas la nécessité de tester (vérifier) et/ou de valider un produit - logiciel développé de façon systématique. Dans pas mal d’entreprises, les activités requises pour tester et valider un logiciel ne sont parfois admises que pour des logiciels standards acquis et sûrs de fonctionnement (Ivinza Lepapa A. C. et Mbuta Ikoko D. A., 2006). Or logiquement, un logiciel développé ne peut pas être mis en service si la démonstration de sa fiabilité (qualité et sécurité) n’est pas effectuée par le maître d’ouvrage ou son délégué. La fiabilité est alors une part cruciale dans le développement 2 logiciel. Dans la littérature, plusieurs études ont déjà rapporté que près de 40 % des projets de développement des logiciels et/ou d’intégration des modules progiciels dans les entreprises n’atteignent pas les objectifs fixés au départ soit en termes de manque de qualité d'exigences, de faible implication des utilisateurs, de budget, d’échéancier ou de résultats à livrer (Songini M., 2005, Vital Roy et alii, 2007). D’autres ont mentionné voire que 15 % des projets de développement des logiciels informatiques sont annulés avant leur fin avec des effets souvent désastreux pour l’entreprise et pour les ressources affectées par manque de leur maturité, etc. (Iacovou C.L. et Dexter A.S., 2005, cité par Vital Roy et alii, 2007). Ces taux d’échecs, selon moi, risquent d’être trop élevés en RD Congo suite à certaines pratiques malgré la tentative d’une professionnalisation sans un corpus de connaissances clair (manque d’études ou recherches locales en matière de conduite des activités de développement logiciel mais aussi les dangers que pourraient présenter cette conduite pour nos entreprises, etc.). Nous imaginons à propos que la réponse critique aux différents éléments évoqués se trouve donc situer dans l’adoption d’un 3 management plus large, qui couple les valeurs agiles aux techniques de l’amélioration continue de la qualité et/ou à celles basées sur le processus ou la maîtrise documentaire. 2  Lors de la phase de réalisation, en rapport avec le domaine auquel le logiciel en développement sera exploité (gestion, télécommunications, etc.), plusieurs complexités apparaissent. Elles sont parfois simples, difficiles ou très difficiles selon qu’il s’agit des structures organisationnelles différentes. La notion de tests mais aussi de la qualité logiciels sont alors très essentielles pour que le produit logiciel à implémenter puisse contribuer à la réalisation de la mission même de l’organisation face à l’adéquation aux objectifs Q, C, D, P (Qualité, Coûts, Délais et Prestations). 3 Les techniques de l’amélioration continue sont basées sur le cycle « PDCA : Plan, Do, Check and Act », dit modèle de Deming (1986), qui s’applique presqu’à tout système de management de la qualité. Dans un projet informatique de développement logiciel, le référentiel CMMI – DEV (2006) de Humphrey W. de Carnegie Mellon, dédié à la 2

Cette résolution associée est d’autant plus exigée qu’elle devrait être recommandée aux équipes formelles de développement logiciel en RD Congo pour pouvoir leur permettre de livrer un bon produit, qui respecterait voire les règles de l’art ou métier, et qui leur éviterait de dénaturer les procédures et les procédés qui sont en principe connus et définis, à partir des besoins initiaux ou quotidiens (exprimés par le maître d’ouvrage ou par les utilisateurs). Cet aspect hypothétique d’améliorer les pratiques TI congolaises dans l’accomplissement, avec succès, de certains projets informatiques de développement logiciel rend alors intéressant la compréhension et l’importance de disposer, avant chaque activité de vérification et de validation, un modèle de tests logiciels (de niveau de supérieur) produit sur base des référentiels existants. Cette contribution, qui rentre dans la perspective d’amélioration des pratiques TI congolaises poursuivie par la structure BSD Congo, particulièrement en matière de développement logiciels, s’inscrit dans le cadre des ateliers pratiques que sa cellule « Recherche et Développement » a organisé et continuerait à organiser avec certains étudiants informaticiens sur la modélisation de tests logiciels dans les milieux universitaires congolais (UNIKIN, ULK, ISTA, etc.). Elle s’organise alors comme suit : Au point II, nous présenterons l’état de l’art et les grandes lignes sur lesquels cette contribution s’appuie. Il résume donc, dans une première phase, quelques prérequis pour la gestion d’un projet informatique de développement logiciel. Dans une seconde phase seront présentés de façon globale les concepts de programmation et de tests logiciels. Cette deuxième phase passera aussi en revue les niveaux, méthodes et outils de tests qui seront complétés à leur tour des lignes essentielles (exigences dans les activités de vérification et de validation, modélisation comportementale des exigences dans l’UML pour les tests, efficacité de tests, etc.) aidant à l’élaboration de notre modèle de tests. Le point III présentera notre démarche d’élaboration du modèle de tests qui, sur base des processus et règles métiers décrits (processus de paiement dans le cadre de DDR), va produire et détailler l’ensemble des exigences à aligner dans les activités de tests logiciels. Ces exigences, seront donc vus, ensemble avec les cas et les résultats de tests à concevoir, comme base de notre ébauche de modèle de tests dans le cadre de vérification et de validation du produit – logiciel « Payment Manager ». Une conclusion et quelques perspectives terminent cette contribution. II.APPROCHES SUR LE DEVELOPPEMENT INFORMATIQUE Section I. L’univers de développement informatique dans les entreprises : contour managérial et organisationnel a)Le développement informatique dans les entreprises : Considérations générales Le développement informatique est une activité intensément collaborative. Il consiste à analyser ou étudier les besoins de gestion optimisée d’une organisation, à concevoir des solutions sur la base de ces besoins, à modéliser informatiquement ces solutions, c’est-à-dire les transcrire dans un langage informatique, les implémenter sur une machine ou un système et les maintenir ou les 4 faire évoluer. Pour ce faire, le génie logiciel » , qui s’occupe de la fabrication des systèmes informatisés, c.à.d. des logiciels dans notre cas, traite cette réalisation informatique dans le but d’atteindre un objectif spécifique. C’est donc le domaine de l’informatique qui allie les capacités d'analyse et d’adaptation à un esprit de synthèse, tout en mettant en œuvre les techniques (outils

conception et au développement des logiciels, s’associe à ce modèle de Deming pour tenter d’aider les organismes d’ingénierie à améliorer la capacité de leurs processus à travers 5 niveaux dit de maturité (initial, reproductible, défini, géré et optimisé). 4 Selon la norme IEEE 610.12, le génie logiciel est l’application d’une approche systématique, disciplinée et quantifiable au développement, à l’exploitation et à la maintenance du logiciel. C’est-à-dire, l’application de l’ingénierie au logiciel. 3

et méthodes) et le sens de créativité. Orienté vers le management de projet, il est défini comme un ensemble d’activités informatiques à effectuer pour atteindre un but unique défini de façon spécifique. Cette spécificité de but unique à atteindre est très importante dans les faits, car elle délimite voire le champ d’action des acteurs clés, dans un projet, qui utilisent ces techniques dites d’ingénierie des exigences (une des parties du génie logiciel qui permet de déterminer quel système sera développé, sa sécurité et sa durabilité), et un management plus large, qui couple à 5 leur tour les valeurs des techniques agiles de l’amélioration continue de la qualité. Pour avancer dans ce raisonnement, il conviendrait de rappeler quelques considérations. En effet, dans une entreprise, le sommet stratégique vise globalement deux finalités : (1) satisfaire les besoins et les attentes des utilisateurs de ses produits et/ou de ses services et (2) contribuer au bien être, au développement et à l’épanouissement de tous ceux qui y travaillent. Cet ensemble des caractéristiques intrinsèques à satisfaire des exigences est une aptitude de la qualité repris 6 dans un système d’information manuel qualité d’une entreprise. Elle est ainsi managée, cette aptitude, par un système de management axé sur la définition des objectifs qualité et sur la spécification des processus opérationnels et des ressources afférentes, nécessaires pour atteindre les objectifs qualité (NF EN ISO 9000 : 2000). Ce système est donc le système de management de la qualité. Comme c'est une activité qui exige une vision et un engagement à long terme, les risques et les limites associées à l'amélioration des processus définis sont donc à prendre en compte et/ou à considérer. Il est alors très difficile de retrouver la dynamique nécessaire pour le succès d’une telle opération dans une entreprise sans avoir une équipe dédiée, un budget alloué et un plan avec des objectifs raisonnables. Cette méthodologie mais aussi les méthodes et outils, destinés à soutenir l’évolution des systèmes d’information dans l’entreprise, peut se démarquer des autres domaines stratégiques, mais ne peut et ne doit en aucun cas en être dissocié, puisque leurs rôles sont parfaitement identifiés par les différents processus d'une organisation et s’appuie sur des moyens de développement, d’intégration et de production dédiés. Ils impactent donc de manière déterminante l’implémentation de la stratégie de l’entreprise. Le génie logiciel, comme dit au début, n’échappe donc pas à cette règle, car son problème fondamental est celui de construire, pour un système d’information existant dans une entreprise, 7 des logiciels qui soient ergonomiques, fiables, évolutifs et économiques c.à.d. garantissant le contrat de service requis par les usagers (ISO IEC 9126) et satisfaisant aux critères coûts et qualité. Il est donc possible de distinguer les référentiels « produit » qui permettent de fixer les caractéristiques que doivent avoir les composants d’un système d’information (matériel, logiciel,...) et les référentiels « management » qui introduisent à un niveau organisationnel les aspects techniquesdéjà̀pris en compte. Ici, le système logiciel à développer devient une variété du système d’information dans lequel l’ordinateur est au centre de son traitement de l’information (système informatique) et soutient voire son évolution, l’implémenter, c’est donc se poser des questions relatives sur son rôle dans l’organisation et les hommes qui l’utilisent (Dupuy et Alii, 1993, cité par Ivinza Lepapa A. C., 2007). Cette approche systémique le fait apparaître, de manière récursive et dynamique lors de son implémentation dans l’organisation, à la fois comme un moyen essentiel et un objet principal du management au-delà de l’ordinateur et de la

5  La qualité, dans le domaine de développement et de conception, est vue comme le but ou l’exigence ultime à atteindre car elle se retrouve étroitement liée à la réalisation au point qu’il est très difficile de partager distinctement les activités de développement des celles de qualité. 6 Le système d’information, abrégé SI, est une représentation systémique de l’entreprise et de ses activités. En grande partie immatériel, il est donc complexe (Lemoigne, 1994) et est organisé autour des ressources, sous diverses dimensions (organisationnelle, managériale et technologique) (Reix R., 2004 et Laudon et Alii, 2006). 7 Actuellement, trois types de logiciels existent. Il s’agit des logiciels constructeurs, qui sont très dépendants du matériel ; des progiciels, développés par les éditeurs de logiciel, des boîtes noires, généralement paramétrables, assurant telles ou telles fonctions précise ; et des logiciels propriétaires, développés pour les besoins spécifiques de l’entreprise ou de l’organisation, soit par elle même ou soit par l’intermédiaire de sociétés de services. 4

technologie. Ce résultat provenant d’une organisation et/ou d’une modélisation permet au système d’information de l’entreprise de fournir et de disposer des outils permettant « … de garder en mémoire une représentation de l’activité du système opérant au sein de l’environnement afin de le mettre à la disposition des acteurs de décision pour qu’ils puissent 8 piloter, coordonner et finaliser le comportement du système opérant ». C’est donc une implémentation, sous forme de processus en interaction et non de services, qui implique de la compétence aux acteurs de l’équipe du projet tout en prenant en compte les aspects dynamique et l’adoption des méthodes et outils pour minimiser ou maîtriser les facteurs susceptibles de compromettre un projet de développement. Ici, l’on devra par exemple tenir compte de la qualité des spécifications produites en amont (spécifications des besoins et spécifications des exigences qui doivent être adéquates, non-ambiguës, cohérentes, vérifiables, modifiables, traçables, etc.), et en aval, des erreurs sur les artefacts produits durant l’implémentation, qui ne reflètent toujours pas les besoins réels et ne satisfont presque pas in fine les exigences fournies, pour ne pas connaître un échec. Dans ce contexte, le sommet stratégique de l’entreprise ou le maître d’ouvrage (MOA) qui met sur pied une organisation, sous forme de projet, et des moyens sûrs pour le pilotage des processus ou des activités liées, va alors confier à sa fonction systèmes d'information (maître d’œuvre, MOE, qui apporte alors ses connaissances de l'environnement technique et financière puis son expérience sur des solutions technologiques au sein de l’entreprise), la mission d’élaboration en amont d’un document qui spécifie les besoins fonctionnels du produit – logiciel à acquérir et/ou à développer et, en aval, de développement et/ou d’acquisition, soit partiellement ou totalement, de ce produit – logiciel sur la base d’un mode de gestion choisi et/ou décidé. Néanmoins, « au regard de la politique de rationalisation des coûts mis en place, la fonction financière et la fonction des approvisionnements de l’entreprise, auront aussi leur mot à dire sur les budgets à allouer » (Antoine Crochet D., 2011). On se retrouve alors face à un projet informatique de développement ou un projet système d’information dont les ressources humaines, techniques, procédurales et méthodologiques à mettre en œuvre doivent être orientées vers l’amélioration continue et vers la livraison d’un produit logiciel fiable. Cette vision commune de gestion des systèmes d’information et de gestion de la qualité dans un développement informatique s’appuie sur la vision globale de l’entreprise, mais aussi à la nature de l’activité de l’entreprise, sur la décomposition par processus, à la taille de l’entreprise et aux méthodes de gestion que les dirigeants veulent mettre en œuvre. b)Les projets informatiques ou TI : composants et limites Types et modes d’approvisionnement de projets informatiques Les projets informatiques construisent des logiciels mais aussi gèrent les matériels et tout type de dispositif de communication numérique, qui ne représentant que la partie technologique du SI, les 9 TI. Ils soutiennent alors l’évolution du système d’information dans une entreprise et font partie, de manière générale, des projets « systèmes d’information ». Leurs objectifs ne sont pas seulement ceux qui sont rattachés à la gestion des difficultés (pas seulement techniques) de conception et de réalisation des logiciels mais aussi celles de la mise en œuvre, exploitation et au

8 TARDIEU Hubert, NANCI D., PASCOT Daniel, Conception d’un système d’information : Construction de la Base des données, Edition d’organisation, Gaëtan Morin Editeur, Paris, Québec, 1980 pages 30-31. 9  Les TI (Technologies de l’information), en anglais Information Technology, sont des composantes de nature technique que les organisations ou les entreprises achètent, développent ou combinent pour constituer l’infrastructure technologique qui permet, par la suite, à leur SI de fonctionner. 5

maintien des services du système d'information d'une entreprise en s’appuyant sur les architectures informatiques et les réseaux de communications. Ils sont alors complétés, ces objectifs, des plusieurs propriétés telles que la sécurité des données (protection, confidentialité, intégrité), la sécurité des traitements (disponibilité, sûreté) et la qualité de service (disponibilité des services, pérennité, relation avec les utilisateurs). Généralement, il existe deux types de projets informatiques, à savoir : « les projets d’exploitation informatique » et « les projets de développement et/ou de maintenance logiciels ». Ces deux types de projets informatiques tournent autour de cinq dimensions fondamentales, à savoir : (1) sa 10 mission, (2) ses activités critiques, (3) les compétences et connaissances de ses membres , (4) sa relation avec le reste des unités d’affaires de l’organisation où il s’exécute et (5) sa gouvernance. Ainsi, les projets de développement, qui concernent l’évolution et l’entretien des plateformes technologiques, sont souvent réalisés à l’externe d’une organisation pour des raisons de productivité et de performance (approche « outsourcing »). En faisant l’objet de développement d’un système logiciel à intégrer au sein d’un système d’information existant, les acteurs de l’organisation partenaire auront à partager par exemple les responsabilités, les risques et les bénéfices éventuels du projet avec les acteurs de l’organisation interne en plus de l’obligation de transfert d’expertises. Vital Roy et alii (2007) alignent, selon la disponibilité de acteurs compétents et la valeur stratégique de l’informatique dans une entreprise, quatre modes d’approvisionnement distincts pour répondre aux besoins de développement logiciels. Il s’agit des modes d’approvisionnement 11 à l’interne, en partenariat, en impartition et en récupération ». Ces modes sont constitués selon qu’il s’agisse d’une vision informatique de développement à forte ou à faible transformation organisationnelle. Les modes en partenariat et en impartition constituent tous deux un projet informatique de développement de type mixte. C’est une structure organisationnelle temporaire orientée vers l’accomplissement d’un objectif, le développement du système logiciel, par le partenaire technologique interne de l’organisation, c.à.d. sa fonction système d’information (maître d’œuvre technologique de l’organisation), et un sous – traitant (partenaire externe). Ici, les acteurs impliqués, experts métier et informaticiens de différentes spécialités (concepteurs, développeurs, designers, testeurs, administrateurs de bases de données, etc.), qui unissent et harmonisent leurs efforts pour faire aboutir ces projets logiciels, ne doivent pas seulement se 12 préoccuper des différents processus et procédés qui s’y rattachent [procédés prédictifs (V, W, cascade, …) ou procédés synthétiques ou agiles (RAD, XP, Scrum, …)], mais aussi de la gestion des coûts, des délais, du temps, des ressources et des communications suivant les cahier des charges définis. Organisation et moyens de pilotage d’un projet de développement logiciel mixte En cherchant d’élaborer des dispositifs pour conduire un projet de développement logiciel mixte, basés sur le concept de contrôle et de la régulation qui guide son fonctionnement et son évolution, on aboutit alors à la définition et au dimensionnement des moyens à mettre en œuvre. Dans cette

10 Celles - ci sont vues à la fois sous l’angle d’un savoir tacite(compétences des acteurs TI dans l’utilisation des TI ou dans la gestion des projets TI mais aussi leur vision à retirer du rôle des TI dans les processus à gérer)et d’un savoir explicite(connaissances technologique des acteurs et sur les applications et le développement des SI mais aussi sur leur gestion). 11  Ce mode d’approvisionnement est parfois appelé mixte dans le cas des entreprises de taille moyenne ayant une valeur stratégique et pour lesquels les ressources et les compétences requises sont en partie disponibles à l’interne. Il associe alors, dans ses activités de conception, de réalisation et d’implémentation, le transfert, l’acquisition et l’échange d’expertises entre les ressources du projet. 12  Un procédé est cet ensemble des moyens et des méthodes permettant d’accomplir une activité. En fixant les procédés (quand ceci est nécessaire), on prescrit le comment faire. Ne confondons jamais les mots procédé et processus qui se disent tous deux en anglais « process ». 6

foulée mais aussi avec la logique évoquée dans le point précédant, le chef de projet à qui on confie la destinée d’un projet informatique devra avoir besoin des variables essentielles, par exemple un tableau de bord, pour pouvoir de détecter le plus rapidement possible d’éventuels problèmes et éviter ainsi des situations irrémédiables, et des variables d’actions. Ceux - ci vont lui permettre de pouvoir disposer d’un style de gestion comparable à celui de leader transactionnel, orienté vers le contrôle dans un objectif de maximisation des résultats et de stabilité des processus, ou à celui de leader transformationnel, orienté vers la flexibilité dans un objectif d’adaptation au changement et de partage des connaissances. Pour le profil de leader transactionnel, Vital Roy et alii (2007) en exploitant les travaux de Aaron J. Shenhar (2001) et de Gottschalk Peter et Karlsen Jan T. (2005), qui utilisent la typologie des six rôles de gestion de Mintzberg H. (1994), et de Quinn Robert E. (1988), sur les divers rôles de gestion pour la recherche de performance dans des contextes organisationnels spécifiques, recommandent aux chefs de projet les rôles de producteur, de directeur, de coordonnateur et de contrôleur. Par contre, pour le profil de leadership transformationnel, ils alignent les rôles d’agent de liaison, d’innovateur, de mentor et de facilitateur. Toutefois, lorsqu’on se retrouve face à une impartition (développement mixte), le chef de projet client devra ajouter le rôle de« spokesman »que celui de l’impartiteur, le rôle de tandis 13 « resources allocator », le. Dans ce mode d’approvisionnement, c’est donc la communication suivi et la coordination, qui constituent voire le gage de succès du projet piloté. Ainsi, manager un projet informatique de développement mixte est une opération complexe car il comporte une part importante d’incertitude, et la nature du système d’information de l’entreprise en accroît les risques.14plusieurs référentiels sont mis en place dont le corpus de Ici, formalisation est en cours pour certains [des méthodes et des outils (CMMI, COBIT, ITIL, EBIOS, PMI, ...), au niveau inférieur, et des normes de management (ISO 9001, ISO 10006, ISO 27001, ISO 25000, …), au niveau supérieur]. D’ailleurs, pour Frederick P. Brooks (2001), les projets informatiques de développement logiciel sont incomparables aux autres en raison de l’importance qu’occupent voire le produit – logiciel et ses processus. Ils sont et restent toujours difficiles à conduire. Néanmoins, les référentiels classiques de niveau inférieur mis en place, qui prônent un enchaînement séquentiel (parfois lourd) des processus, depuis l’étude de faisabilité jusqu’à la mise en œuvre complète du système ou du produit – logiciel, et les pratiques complémentaires, dites « agiles » – une contribution professionnelle évolutionniste –, permettent actuellement aux équipes de projets de produire, dans un contexte de réactivité, de réduction des délais et de livraison, un système logiciel dont l’utilisateur participe totalement à sa conception (Valtech, 2008, Véronique Messager Rota, 2009, …). Notons que l’adoption de ces pratiques complémentaires (développement dirigé par les tests, programmation itérative, réunions quotidiennes, etc.), dans une approche d’amélioration continue, est une conséquence positive pour le management de projets informatiques dans son ensemble. Elles ont pour principal objectif, sans pour autant rejeter les valeurs clés de l’approche classique qui doivent encore rester omniprésentes, l’implication au quotidien du client au sein de l’équipe du projet afin d’éviter des incohérences entre le besoin initial et le produit à livrer. Pour cela, elles valorisent « les individus et les interactions plutôt que les processus et les outils méthodologiques, les logiciels

13  Le manque d’une communication dans un projet de développement logiciel peut amener à une différence de compréhension entre les différents acteurs. En gérant l’ensemble de la communication du projet, le chef de projet TI devra ainsi informer de manière régulière et efficace les différents acteurs des évolutions fonctionnelles (rendre compte de la performance par exemple) sur chaque processus défini dans le cadre du projet et pouvoir réfléchir sur une option à prendre. 14  Ici, le profil de la fonction SI est très important et devra être connu d’avance. Guy Paré et Guillemette Manon (2007) en propose cinq, à savoir : le partenaire, le fournisseur de systèmes, le concepteur d'infrastructures, le leader technologique et coordonnateur de projets TI dans une entreprise. 7

opérationnels plutôt que les documentations exhaustives, la collaboration avec les clients plutôt que la négociation contractuelle et l’adaptation au changement plutôt que le suivi d’un plan ». Les processus et les activités dans un projet informatique de développement logiciel Un processus, de manière générale, représente un ensemble d’activités effectué par une ou plusieurs personnes dans le but de créer un produit, avec un coût et des moyens matériels. Il est souvent constitué de sous processus, ou tâches, selon une décomposition hiérarchique dont l’activité est l’élément du plus bas niveau. L’activité est donc un processus qui tente de transformer des entrées en sortie. Les activités se définissent alors comme un ensemble homogènes d’actions, concourant à un même objectif, et nécessitant les mêmes compétences, et analysant les types de travaux et les responsabilités opérationnelles. En les décrivant, on définit le quoi faire. Elles possèdent alors des points d’ancrage ou d’interaction entre eux qui renvoient à l’articulation des phases dans un projet. Ainsi, dans une gestion globale de développement logiciel, plusieurs processus peuvent exister [processus de vérification et de validation (tests, contrôles, preuves, etc.), processus de gestion des anomalies, etc.] et peuvent s’interférer avec celui de gestion de projet suivant une approche d’amélioration continue (figure 1). Ici, la notion d’activités suit donc les mêmes principes que les processus dans le cycle de développement, et leur maîtrise, comme nous avons dit précédemment concernant les procédés, est très essentielle dans l’exécution du projet. Elles englobent ainsi des phases d’analyse, de conception, de programmation, de tests logiciels, d’installation, etc. et permettent une prise en compte des exigences du MOA par le MOE pour la réalisation d’un produit – logiciel.  "  
! ( $! %             $       !   !         & ! '    $

!$  

  $  

 #  $ 

$   !  

   

     

$!     

 

#  $!  

     

$ ( 

#  !   Fig.1. Cycle de vie du logiciel inspiré de l’IEEE intégrant le cycle de développement du logiciel (source : Luc Lavoie, 2007). En somme, la réalisation de toutes ces activités ou de différents processus dans un cycle de vie du logiciel matérialisent le plan qualité, qui essaie de donner à son tour une vision globale et complète du projet en permettant des effets zoom sur le développement du logiciel mais aussi sur la manière dont la qualité devra être assurée tout au long de la réalisation du logiciel. Quant à une procédure, elle est définie par la norme NF EN ISO 9000 : 2000 comme une manière d’accomplir une activité et traite de son aspect organisationnel en répondant aux questions dequi fait?Etquand le fait-il?

8

c)Autres éléments à considérer dans un projet informatique de développement logiciel. Plan et clauses qualité dans le développement logiciel Dans un projet informatique de développement logiciel, le plan qualité logiciel, ou plan d’assurance qualité (PAQ), définit les mesures d’assurance de la qualité du logiciel pris en s’inscrivant dans la politique globale du MOA en matière de qualité. Il fait donc le suivi de la mise en œuvre de l’assurance qualité et la gestion des risques devant être appliquée tout au long du projet. Les recommandations sur le produit – logiciel souhaité marque alors une problématique sur sa 15 fiabilité. Il s’agit en fait d’une priorité pour un projet donné de développement informatique et constitue son outil de communication de référence, pour le management de la qualité, validé par les parties, où chaque intervenant trouve exposer sa place et son rôle, tout en spécifiant quelles procédures doivent être appliquées pour réaliser une tâche ou un processus ? Le PAQ fait mention aux caractéristiques logicielles au sein duquel s’instancie la stratégie de test en rapport avec la qualité. Ces caractéristiques forment donc des exigences qualité logicielle et peuvent se mesurer à l'aide des indicateurs ou métriques ci – après : -la maniabilité (communicabilité, exploitabilité et facilité d’apprentissage), -la fiabilité (complexité, tolérance aux fautes ou pannes et auditabilité), -l’efficience (consommation en place mémoire, taille des périphériques et leur vitesse d’accès et temps d’exécution des programmes), -la confidentialité (protection du code et des données et mémorisation des accès), -la couplabilité (standardisation des données et standardisation des interfaces), -la maintenabilité (lisibilité, modularité, traçabilité et adaptabilité), -l’adaptabilité (évolution facile du logiciel), -la portabilité (banalité d’emploi, indépendance et qualité de documentation), et -l’efficacité (coûts et gains dus au logiciel). Ce sont donc des clauses qualité (contractuelles ou non). Dans cette perspective, la version 1.2 du référentiel CMMI – DEV de Humphrey W., développé par Software Engineering Institute de l’université de Carnegie Mellon, ira même à déterminer que la qualité d’un logiciel devra être en relation directe avec la qualité du processus utilisé pour son développement. Ainsi, actuellement, pour développer par exemple un logiciel de qualité, un programmeur procède par la création de 16 composants qui permet de construire par la suite le logiciel. Pour cela, il explore des bibliothèques logicielles antérieures pour trouver et constituer des composants logiciels appropriés pour une nouvelle bibliothèque. Cette réutilisation de composants ou des briques logicielles est une des approches de maturité ou d’amélioration dans le domaine de développement dite framework (COM et ses dérivés), issu de OLE (Object Linking & Embedding) de Microsoft car on n’écrit presque plus des logiciels à partir du néant. Avec cette approche amélioration continue, le programmeur a seulement l’obligation de proposer une architecture logicielle harmonieuse aidant voire à palier plus tard à une dégradation logicielle [cfr. modèle d’architecture des 4+1 vues (Philippe Kruchten, 2000)

15  Un logiciel est un produit immatériel, reproductible, maintenable et subjectif dont les seules représentations observables sont le code source, l'interface utilisateur et la documentation (spécification d’exigences de système, documents de tests, manuels utilisateur, etc.). Pour être considéré comme un produit de qualité, le logiciel doit donc répondre aux besoins exprimés explicitement par l'utilisateur aussi bien qu'aux besoins implicites ou non exprimés. 16 L’usage de cette approche modulaire, par une équipe de développement informatique, permet d'assurer au logiciel une meilleure lisibilité et une meilleure maintenance. Cette approche est voire en phase d’émergence et porte le nom de la programmation orientée composant. L’on doit noter que dans cette approche de développement par et pour la réutilisation logicielle, un cycle de production - réutilisation perpétuel (intégration continue) et une architecture logicielle normalisée est imposé. 9

et modèle d’architecture de 4 niveaux de MDA – Model Driven Architecture ou architecture basée sur les modèles en français (Xavier Blanc, 2005)]. Gestion des risques Un projet informatique de développement logiciel, comme dit au début de notre document, présente des risques que l’on doit maîtriser lors de son exécution. Pour Chantal Morley (2004), cette maîtrise ou gestion des risques « consiste à réduire l’incertitude par une analyse approfondie des caractéristiques internes et environnementales du projet et à élaborer des stratégies pour faire face aux risques plus graves et/ou plus probables ». Pour ce faire, il faudra alors utiliser la démarche générale qui comprend (1) l’identification des risques, (2) l’évaluation de leur impact possible sur les coûts, le délai et la qualité, (3) la définition des actions ou la prise des dispositions aptes à réduire les risques jugés inacceptables, (4) le suivi de ces actions et (5) la capitalisation de l’expérience. Ainsi, lors des activités de tests par exemple, l’identification des risques sera réalisée voire à partir des différents éléments analytique du logiciel ou système sous test (cas d’utilisation, processus métiers, caractéristiques qualité, etc.), en anglais System Under Test (SUT). Plan de développement logiciel C’est un document qui décrit, pour une réalisation logicielle, la décomposition en produits (l’architecture du logiciel, les choix technologiques, les modules ou les composants logiciels - entrées, sorties et traitement -, la conception des interfaces du logiciel avec l’extérieur - description des données échangées, de leur organisation en messages, des protocoles d’échanges - et la conception des bases de données)et en fournitures, les moyens à mettre enœuvre, les tâches nécessaireset les délais à respecter.Le plan de développement logiciel (PDL), suivant les recommandations de la norme NF EN ISO 9000-3 qu’on fait appliquer aux activités informatiques de la norme NF EN ISO 9001, inclut la définition et les objectifs d’un projet, l’organisation d’un projet et les moyens en personnel, la méthodologie et les phases d’un projet, la gestion d’un projet et la vérification logiciel. Section II. La réalisation de logiciels et les exigences de vérification et de validation a)Activités clés et leurs considérations La programmation ou l’écriture des codes dans un cycle de développement du logiciel La programmation constitue l’activité la plus connue et cruciale dans la phase de réalisation. Elle est appelée voire par certains développeurs ou ingénieurs logiciels « la phase de développement ». Le Professeur Printz Jacques (2002), en définissant la programmation, parle voirede l’âme du système informatique ou du logiciel en développement.C’est donc une activité qui, dans le cycle de développement, incorpore d’autres autres activités qui sont essentielles pour l’implantation du produit – logiciel à configurer et/ou à installer. Elle est bâtie sur des éléments ci – après : -une documentation, basée sur l’expression des besoins, l’exigence des utilisateurs et la conception détaillée aidant au déploiement et à la maintenance du logiciel ; -un programme ou module de programme, contenant une suite d’instructions (algorithmes, structure des données en entrée et en sortie, codes, etc.) exécutables par la machine ; -des tests et résultats de série des tests ; et enfin 17 -un environnement intégré d’exécution ou de développement (IDE ), 17  Environnement de Développement Intégré, ensemble d'outils intégrés (éditeur de texte, compilateur et débogueur) dédiés aux langages de programmation pour augmenter la productivité des programmeurs qui développent des logiciels. 10

et permet, soit de façon récursive ou itérative, les tests des programmes informatiques qui, une fois déployé, assureraient au sein d’un système d’information les fonctions nécessaires face au traitement et au stockage de l’information. Les différents programmes informatiques sont écrits avec l’aide des L4G (Visual Basic, C#, Java, Delphi, Python, Turbo Pascal, etc.) et font parfois apparaître des erreurs, dues essentiellement au caractère humain et à la nature profonde du logiciel lui – même. Ils sont souvent payants ou gratuits/libres après compilation. Ici, le seul effort à fournir par les acteurs clés du projet, pour pouvoir obtenir un produit – logiciel fiable et de meilleure qualité, serait de pouvoir corriger ces 18 erreurs par la mise sur pied d’une série d’activités de vérification et de validation bien ficelées. Ces activités doivent être au service d’une stratégie qui, dans un environnement de développement logiciel, constitue voire la base d’un processus de tests, c.à.d. la façon dont ses activités de tests devront être mises en œuvre (figure 2). Le manque de ces activités dans un projet, surtout de type mixte, peuvent s’avérer coûteux et parfois même dangereux. Il risque même au bout du compte d’accroître le niveau d’incertitude dans le développement, surtout si l’on décide encore de se lancer dans les tests sans pouvoir élaborer un modèle de tests. Objectifs Spécification du test Scénario Résultats et comportements attendus Exécution et mise au point du test Résultats et comportements observés lors de l’exécution Analyse / Comparaison Analyse et explication des résultats des différences Incorrecte Correcte Modifications Archivage du scénario et des résultats induites Etat d’avancement Dans le programme Dans le test des scénarios de tests Gestion de configuration (sources, tests et documentation) Fig.2 : Exemple d’un processus simple des tests logiciels incluant certaines procédures (source : Printz Jacques, 2002). L’implémentation de ces activités de vérification et de validation, depuis l’expression des exigences jusqu'à la mise en œuvre d’un référentiel normatif de tests, permet d’assurer à la fois la productibilité des scénarios de test, de mesurer leur qualité et de mieux maîtriser leurs coûts. Elle rentre donc dans

18 La vérification logicielle est formelle ou semi formelle, c.à.d. mathématique ou « exhaustive ». On cherche donc à prouver au sens mathématique que le logiciel (vue comme un modèle logique) satisfait à sa spécification (vue comme un ensemble de formules logiques). Cette activité complexe se matérialise soit par des sous approximations (tests) ou soit par des sur approximations (abstractions). Actuellement, les preuves assistées l’accompagnent aussi. 11