Remerciez-le!

Remerciez @Admin pour avoir partagé cet document gratuitement, de la manière la plus simple, en partageant sur les réseaux sociaux.

Chapitre 2 Les activités du développement Quelle que soit la manière de dévelop

Chapitre 2 Les activités du développement Quelle que soit la manière de développer du logiciel, un ensemble d’activités sont nécessaires au cours du processus. Les caractérisations et dénominations de ces activités ne sont pas normalisées, ou plus exactement il existe une pléthore de normes produites par des organismes tels que l’ISO (International Organization for Standardization), l’AFNOR (Association française de normalisation), l’IEEE (Institute of Electrical and Electronics Engineers), le DoD (Department of Defense) pour les applications militaires aux USA, ou l’ESA (European Space Agency), chacune avec ses nuances propres. Le statut de ces activités dans le processus de développement peut beaucoup varier. Dans les processus classiques (en cascade ou en V, cf. paragraphe 4.1) certaines de ces activités s’enchaînent logiquement et constituent des « stades du développement ». D’autres se retrouvent incluses dans différents stades, comme la vériﬁcation, voire dans tous les stades, comme la documentation. Dans les processus agiles (cf. paragraphe 4.4) certaines activités sont entremêlées, comme le recueil des besoins et l’analyse et spéciﬁcation des besoins, car elles sont pratiquées par des équipes pluridisciplinaires mêlant clients et informaticiens. Alors que dans les approches classiques, les client (MOA) et les informaticiens (MOE) les réalisent séparément et successivement en s’échangeant des documents. Ce chapitre décrit ces différentes activités en restant aussi indépendant que possible des processus de développement. Celles qui relèvent de l’ingénierie des besoins en amont de la conception, qui sont au cœur de l’ouvrage, sont présentées plus en détail que celles en aval du développement. 18 Partie 1. Le développement logiciel 2.1 LE RECUEIL DES BESOINS Synonymes : capture, élucidation, « élicitation », identiﬁcation, expression des besoins (ou exigences). 2.1.1. La notion de besoin Au démarrage d’un projet, le client (qui demande et souvent paye le développement) et les futurs utilisateurs ﬁnaux ont une idée brute de ce qu’ils souhaitent qui peut mêler des attentes plus ou moins précises avec des idées de conception. On parle souvent de besoins bruts ou besoins client. Les architectes décrivent le même phénomène avec leurs clients qui expriment spontanément plutôt des détails de conception (ex. : une maison avec une tour, une véranda, un toit végétalisé, etc.) que de véritables besoins liés à leur âge, au nombre et à l’âge de leurs enfants, à leur style de vie et loisirs favoris, etc. Pour établir et documenter les véritables besoins d’une application, il faut étudier son contexte métier (processus, règles, standards, etc.), l’état actuel de son environnement (l’existant), son rôle attendu, les ressources disponibles et requises, les performances espérées, les contraintes d’utilisation, etc. Dans un premier temps, l’application est vue « de l’extérieur », du point de vue de l’utilisateur (MOA), comme une boîte noire dont seul le comportement externe importe. Dans un second temps, l’analyse approfondie des besoins conduit la MOE à « ouvrir la boîte noire » pour caractériser plus précisément les besoins de l’application (besoins produit). Ces deux temps peuvent être soit distincts, soit entremêlés si les parties (MOA et MOE) sont réunies dans une même équipe. Les besoins analysés décrivent ce que l’application doit faire dans l’environnement qui est le sien (ses buts), les principaux services qu’elle doit rendre (besoins fonctionnels), les exigences qualitatives souhaitées (cf. paragraphe 1.3) et les contraintes sous lesquelles l’application doit s’exécuter et être développée. Ces deux dernières catégories sont souvent regroupées sous la dénomination de « besoins non fonctionnels ». Les exigences de qualité doivent être mesurables et vériﬁables contrairement aux autres besoins et contraintes. FIGURE 2.1 Classiﬁcation des besoins 2 • Les activités du développement 19 Remarque : Le terme « exigence » est parfois considéré comme un simple synonyme de « besoin » et parfois réservé, comme ici, aux besoins non fonctionnels vériﬁables. 2.1.2. Déﬁnition de l’activité L’activité de recueil des besoins recouvre la réﬂexion conduite pour bien appréhender le problème, construire et formuler les besoins bruts. La collecte des informations peut se faire par des entretiens, des questionnaires, des groupes de travail, des brainstormings, la lecture de documentations, l’observation in situ des utilisateurs, la collecte d’exemples (scénarios), etc. Dans tous les cas, il faut se méﬁer des connaissances tacites, souvent non explicitées par ceux qui y sont accoutumés, et des différences ou conﬂits entre points de vue différents. Le terme « recueil » a été retenu ici parmi tous ceux proposés pour traduire le terme anglais elicit car il a plusieurs sens tous pertinents qui incluent la cueillette, le rassemblement de choses éparses et l’enregistrement par écrit de quelque chose. Entrée : L’idée brute d’une nouvelle application. Principales questions à se poser [BR05] : – À qui l’application est-elle destinée ? – Pourquoi est-elle attendue ? – Quels problèmes doit-elle résoudre ? Quel est son périmètre ? – Quelles seront ses conditions d’utilisation ? – Quand est-elle attendue ? – Comment fonctionnera-t-elle ? Sortie : Il n’y a de sortie matérialisée par un document que si l’activité de recueil constitue une phase isolée. C’est le cas dans les processus classiques en cascade ou en V (cf. paragraphe 4.1), où l’activité de recueil des besoins est sous le contrôle de la maîtrise d’ouvrage (MOA), bien séparée de la maîtrise d’œuvre (MOE). Le document d’expression des besoins (ou cahier des charges client) assure l’interface entre MOA et MOE. Il constitue le point de départ de la phase ultérieure d’analyse et spéciﬁcation des besoins par la MOE. Dans les approches agiles (cf. paragraphe 4.4), toute la réﬂexion sur les besoins est effectuée au sein d’une équipe mixte MOA+MOE. Il n’y a pas nécessité de sortie formalisée à l’activité de recueil. La compréhension partagée des besoins bruts résultant des discussions entre toutes les parties prenantes permet d’enchaîner immédiatement la suite du processus. Difﬁcultés : « The hardest single part of building a software system is deciding precisely what to build » (« La partie la plus difﬁcile de la construction d’un logiciel consiste à déﬁnir précisément quoi construire ») [Bro87]. Cela résulte entre autres choses : – De problèmes de compréhension : les développeurs et le client ne parlent pas le même langage. Les utilisateurs ne connaissent pas vraiment leurs besoins. Les développeurs connaissent mal le domaine de l’application. – De problèmes humains : conﬂits, rétention d’information, etc. – De problèmes de volatilité des besoins. 20 Partie 1. Le développement logiciel 2.1.3. Le document d’expression des besoins Quand il existe, ce document n’est pas contractuel. Il décrit succinctement les besoins essentiels, sans donner d’indications sur la manière dont il vont être satisfaits. Le document d’expression des besoins contient souvent les rubriques suivantes : Positionnement stratégique de l’application~: importance, bénéfices attendus, conséquences d’une non réalisation, etc. Utilisateurs~: destinataires, nombre (total, en simultanéité), localisation (locale, distante), compétences, etc. Services attendus~: principaux services attendus, priorités (avec 2 ou 3 niveaux). Evolutions prévisibles~: du périmètre fonctionnel, du périmètre d’utilisation, etc. Contexte technique~: matériel et logiciel. Contraintes d’exploitation~: plages horaires, tolérances d’interruption, temps de réponse, etc. Echéances~: démarrage possible, date de terminaison souhaitée, disponibilité des personnes concernées, etc. Les besoins bruts sont répertoriés de manière informelle (en langue naturelle) ou parfois semi-formelle, sous une forme compréhensible par des non informaticiens. Dans la catégorie semi-formelle, les arbres de buts décrits au paragraphe suivant, les textes structurés et les scénarios sont souvent utilisés à ce stade. Le document d’expression des besoins peut inclure également des ébauches ou maquettes des interfaces homme-machine (IHM) et un glossaire pour ﬁxer le vocabulaire du projet. 2.1.4. Les réﬂexions en amont des besoins Il faut souligner que la réﬂexion sur un projet démarre souvent très en amont du recueil des besoins. Un projet d’informatisation s’inscrit en général dans une stratégie de développement technologique qui s’inscrit elle-même dans la stratégie générale de l’organisation. Ces deux stratégies doivent être « alignées », c’est-à-dire mises en cohérence. Ce processus d’alignement stratégique, conduit par la maîtrise d’ouvrage stratégique (MOAS), c’est-à- dire les dirigeants et décideurs au plus haut niveau, peut fonctionner dans les deux sens. Classiquement c’est la stratégie de développement technologique qui s’aligne sur la stratégie globale de l’organisation. Mais les technologies Web et Web 2.0 par exemple peuvent devenir le fondement de nouvelles stratégies et de nouveaux avantages concurrentiels pour les organisations. À l’occasion d’un projet d’informatisation, la stratégie globale peut être inﬂéchie. Cet ouvrage n’explore pas plus avant ces questions de stratégie globale des organisations. À un niveau plus opérationnel, de plus en plus d’approches d’ingénierie des besoins, dites « GORE » pour Goal-Oriented Requirements Engineering [DLF93], donnent la priorité à la question du « pourquoi ? » (déﬁnir les buts ou objectifs) sur les questions du « quoi ? » (déﬁnir les besoins fonctionnels) et du « comment ? » (déﬁnir les besoins non fonctionnels). En explicitant le pourquoi on peut espérer développer des applications plus pertinentes 2 • Les activités du développement 21 pour l’organisation, avec des fonctionnalités qui concrétisent réellement la satisfaction des objectifs retenus. Les buts aident à se focaliser sur l’essentiel et évitent de se perdre dans les détails. Ils peuvent être exprimés à différents niveaux d’abstraction dans des arbres de décomposition de buts (souvent des arbres ET/OU). Cette représentation permet de mettre en uploads/Sante/ chapitre-ii-ingenierie-logiciel.pdf