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 ii ingenierie logiciel

Chapitre 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 certaines de ces activités s ? encha? nent logiquement et constituent des stades du développement ? D ? autres se retrouvent incluses dans di ?érents stades comme la véri ?cation voire dans tous les stades comme la documentation Dans les processus agiles cf paragraphe 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 di ?é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 C Partie Le développement logiciel LE RECUEIL DES BESOINS Synonymes capture élucidation élicitation ? identi ?cation expression des besoins ou exigences 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