[PDF](+76👁️) Télécharger La Gestion De Projet Informatique ( Livre Blanc De Stéphane Grare) pdf

Gestion de projet

informatique




Gestion de projet

informatique


Stéphane Grare




Le code de la propriété intellectuelle du 1er juillet 1992 interdit en
effet expressément la photocopie à usage collectif sans autorisation
des ayants droit. Or, cette pratique s'est généralisée notamment dans
les établissements d'enseignement, provoquant une baisse brutale des
achats de livres, au point que la possibilité même pour les auteurs de
créer des œuvres nouvelles et de les faire éditer correctement est
aujourd'hui menacée.

En application de la loi du 11 mars 1957, il est interdit de reproduire intégralement
ou partiellement le présent ouvrage, sur quelque support que ce soit, sans
autorisation de l'éditeur ou du Centre Français d'Exploitation du Droit de Copie, 20,
rue des Grands-Augustins, 75006 Paris.


DANGER



PHCTXOPILLAGE
'.ELELIV 3 : .



PREFACE


On parle tous de projets dans la vie de tous les jours : nos projets de vacances, projets de
carrière, projets d'avoir des enfants... Le terme projet est donc un terme du vocabulaire
courant, auquel on associe une signification relativement claire et précise : c'est un ensemble
d’actions que nous souhaitons entreprendre, pour atteindre un but (devenir parent,
embrasser une nouvelle carrière...). En ce sens, le projet est bien « le brouillon de l’avenir » :
une ébauche, mais pas encore une réalisation.

Cette notion de projet nous vient du latin « projectum de projicere », qui signifie littéralement
« jeter quelque chose vers l’avant ».

Au premier abord, un projet est une chose ou un ensemble de choses que l’on se propose de
faire, une intention, une ébauche.

Latins et Anglo-saxons accordent un sens assez différent à la notion de projet. Si pour nous le
projet n’est qu’une action ou un ensemble d’actions que l’on projette de réaliser, dans la
culture anglo-saxonne le projet désigne une notion concrète, incluant la planification,
l’anticipation des risques, les acteurs impliqués... Bref, cette notion recouvre un concept plus
précis, concret et pragmatique, qui appelle l’action. Nous parlerons, par la suite, de projet en
ce sens.

On dénote, de manière assez intuitive, une notion forte de temporalité dans la notion de
projet : un projet est généralement une aventure temporaire (ayant à ce titre un début et une
fin). Il ne s'agit donc pas d'un processus répétitif : un projet est unique.

Outre les projets personnels, la majorité des projets impliquent plusieurs personnes (une
compagne ou un compagnon pour devenir parent, éventuellement une famille pour partir en
vacances...). On parle alors d'acteurs du projet. Ces acteurs constituent autant de ressources
du projet.

En plus de ces ressources « humaines », un projet peut nécessiter, dans sa réalisation, des
ressources matérielles : une voiture pour partir en vacances, une robe de mariée, des
bouteilles de champagne...

L'ensemble de ces ressources représente un coût : Salaires et rémunérations pour les
ressources humaines, prix d'achat ou de location pour les ressources matérielles. Un projet
fait donc généralement l'objet d'une budgétisation.

Enfin, le projet aboutit, normalement, à la production de résultats matériels et immatériels.
On appelle ces résultats des livrables, qui représentent les résultats attendus du projet.

Un projet est une chose ou un ensemble de choses que l'on se propose de faire en un temps
donné, mettant en œuvre des ressources humaines et matérielles faisant l'objet d'une
budgétisation, et aboutissant à un ensemble de livrables.




TABLE DES MATIÈRES


Préface.4

Le cycle de vie d'un projet.8

Modèles de développement.9

Modèle en cascade.12

Modèle en V.15

Modèle en W.15

Modèle incrémental. 16

Modèle évolutif.17

Modèle de cycle RAD.17

Modèle en spirale.19

UP.21

RUP.25

Le cycle de l'Extreme Programming.26

Répondre à un appel d'offre décisionnel.30

Appel d'offre décisionnel.30

La réponse.30

Facteurs clés du succès.31

Facteurs clés en mode liste.33

Recueil de besoins.34

Objectifs.34

Méthodologie.34

Démarche de la conception cible.43

Guide d'entretiens.45

CMMI (Capability Maturity Model Intégration).48

Le modèle CMMI.48

Maturité.48


Historique


49































Descriptif du modèle


49


Le niveau 1.50

Le niveau 2 (managed / discipliné).50

Le niveau 3 (Defined / ajusté).51

Le niveau 4 (Quantitatively managed / Géré quantitativement).52

Le niveau 5 (optimizing / en optimisation).52

Les autres composants.53

La planification.54

Solutions décisionnelles.62

Technique et maîtrise d'œuvre.62

Projet décisionnel.62

Spécifications.64

Définition des indicateurs.65

Philosophie générale des restitutions.66

Modes de restitution proposés.67

Facteurs de succès.70

Factures de succès en terme décisionnel.70

Les caractéristiques d'un projet décisionnel.70

Facteurs de succès et risques du projet.72

Les facteurs clés de succès.72

La maîtrise des risques intrinsèques à la mise en place d'un système d'information
décionnel.72

Logiciel décisionnel.74

Business Objects.74

Installation Business Objects sur Linux.74

Installation BusinessObjects.78

Documentation du projet.90

Spécifications fonctionnelles.90


Architecture applicative


90































Architecture technique


90


Justification.91

Le dossier de réalisation. 91

Le référentiel fonctionnel. 91

Le référentiel technique. 92

Plan des tests unitaires.92

Le dossier de recette. 92

Le Dossier technique.93

Manuel d'installation et de désinstallation. 93

Manuel d'exploitation. 93

Guides d'exploitation. 94

Documents d'utilisation. 94

Le dossier de maintenance.95

Rapport des actions correctives.95

Rapport des actions évolutives et adaptatives.95

Le dossier de pilotage. 95

Compte-rendu de réunion.95

Rapport d'avancement (ou synthèse de projet). 95


Bilan de projet


96






















LE CYCLE DE VIE D'UN PROJET


Un projet est une opération dans laquelle des ressources humaines, financières et matérielles
sont organisées d’une façon originale, pour réaliser un ensemble de fournitures, selon des
spécifications définies, avec des contraintes de coûts et délais, de façon à obtenir un
changement bénéfique défini par des objectifs quantitatifs et qualitatifs.

Un projet est un ensemble unique d’actions coordonnées, avec des dates définies de début et
de fin, entreprises par un individu ou une entité pour atteindre des objectifs spécifiés en
respectant des paramètres de coûts, délais et performances.

Définition de l'AFNOR : "Un projet est un ensemble d’actions à réaliser pour satisfaire un
objectif défini, dans le cadre d’une mission précise, et pour la réalisation desquelles on a
identifié non seulement un début, mais aussi une fin".

Définition de l'AFNOR : "La gestion de projet est l'ensemble des méthodes, outils
d'évaluation, de planification et d'organisation permettant d'atteindre ses objectifs en
respectant les contraintes de performance, de délais, et de coûts."

Le management de projet consiste à planifier, organiser, piloter et maîtriser tous les aspects
d’un projet, ainsi que la motivation de tous ceux qui sont impliqués dans le projet et la
maîtrise de la relation client, de façon à atteindre les objectifs de façon sûre et dans les
critères définis de coûts, délais et performances. Cela inclut les tâches de direction
nécessaires aux performances du projet.

Un objectif est une contrainte qui va être « imposée » au système projet afin qu'il se réalise
dans un cadre. Ce cadre est imposé par le commanditaire.

Un projet comporte 3 niveaux d'objectifs :

-> Les objectifs de qualité.

-> Les objectifs de temps.

-> Les objectifs de coût.

Objectifs de qualité : Ce sont tous les éléments qui vont « qualifier » le produit qui va sortir
du projet. Ces éléments vont constituer les performances du produit ; ce sont ces
performances qui vont satisfaire le besoin.

Objectifs de temps : C'est le calendrier dans lequel le projet doit se réaliser. Ce calendrier
comporte une date de début du projet, une date de fin du projet, des échéances
intermédiaires éventuelles.

Objectifs de coût : C'est la somme du coût des ressources nécessaires à la mise en oeuvre
du projet.

Un objectif doit répondre à un certain nombre de critères :

-> Il doit être mesurable : car il faut pouvoir le visualiser et le comprendre, il doit donc être
quantifié. Cela permettra par ailleurs de savoir si l'objectif a été atteint par la mesure des
résultats à la fin du projet.




-> Il doit être réalisable : car il faut pouvoir atteindre l'objectif. L'objectif impliquera un
engagement du chef de projet ; et pour que celui-ci s'engage sur les objectifs, il faut bien sûr
que l'objectif soit atteignable.

-> Il doit pouvoir être négocié : afin d'obtenir un engagement mutuel entre celui qui fixe
l'objectif et celui qui se propose de l'atteindre, la négociation s'engage afin d'avoir un accord
mutuel qui donne toutes les chances au projet d'aboutir.

-> Il doit être partagé : si l'objectif va être réalisé par un groupe de personnes il faut que cet
objectif soit compris par toutes afin qu'il n'y ait aucune ambiguïté entre elles et sur le but à
atteindre.

-> Il doit être individualisé : on ne fixe pas un objectif directement à un groupe de personnes.
On s'assure que l'objectif a été réparti entre ces personnes et que chacune connaisse sa part
d'objectif à atteindre.

Les 3 objectifs Coût/Qualité/Temps sont interdépendants entre eux et interagissent pendant
le projet. Si on modifie un seul des objectifs en cours de projet, les deux autres objectifs vont
être modifiés.



Le cycle de vie d’un projet informatique est composé des étapes et des enchaînements
nécessaires pour réaliser le produit ou le service qui font l’objet du projet. Le cycle de vie doit
être adapté, en fonction de la complexité du produit à fabriquer. Généralement, il a pour but
de participer à la maîtrise les risques de fabrication, ainsi que d’assurer la qualité du produit
fini.


MODELES DE DÉVELOPPEMENT

Il existe des "modèles de développement" pour le découpage des projets SI. Un modèle est
une abstraction de quelque chose de réel qui permet de comprendre avant de construire ou


de retrouver les informations nécessaires pour effectuer des modifications et extensions. Le
modèle simplifie la gestion de la complexité en offrant des points de vue et niveaux
d'abstraction plus ou moins détaillés selon les besoins. Il facilite la communication entre les
différents intervenants sur le projet. Il supporte la conduite et la gestion des processus de
développement et de maintenance.


1. Opportunité

2 . Faisabilité

3. Conception

4. Réalisation
5 Recette

6 Mise en production

7 Maintenance


Les modèles de cycle de vie du logiciel décrivent à un niveau très abstrait et idéalisé les
différentes manières d'organiser la production. Les étapes, leur ordonnancement, et parfois
les critères pour passer d'une étape à une autre sont explicitées (critères de terminaison
d'une étape - revue de documents -, critères de choix de l'étape suivante, critères de
démarrage d'une étape).

Le cycle de vie d’un projet informatique est composé des étapes et des enchaînements
nécessaires pour réaliser le produit ou le service qui font l’objet du projet. Le cycle de vie doit
être adapté, en fonction de la complexité du produit à fabriquer. Généralement, il a pour but
de participer à la maîtrise les risques de fabrication, ainsi que d’assurer la qualité du produit
fini.

On appelle "cycle de vie canonique" le cycle de vie de base d’un projet informatique. En
fonction de l’enchaînement des phases de projet, on débouche sur un cycle de vie en cascade,
en V, ou évolutif. D’autre part, en fonction de la complexité du résultat à produire, s’il s'agit
d'un projet ou d'un programme, le cycle de vie sera une combinaison adaptée des phases
canoniques. Le cycle de vie canonique ne décrit pas les processus de support de projet tels le
processus de management, l'assurance qualité, la logistique.

L'étude d'opportunité permet de définir et d'évaluer les objectifs tangibles et intangibles du
projet :

-> Définir les objectifs, le périmètre et les grandes lignes de la solution
-> Vérifier qu'ils sont alignés avec la stratégie de l'entreprise
-> Identifier les risques et les moyens de les contenir
-> Définir les gains attendus
-> Définir les coûts maximaux













L'étude de faisabilité permet d'établir la faisabilité du projet, c'est-à-dire d'établir s'il existe
une solution technique optimale répondant aux exigences techno-économiques identifiées lors
de la phase précédente :

-> Établir l'expression des besoins

-> Identifier les solutions possibles

-> Identifier les risques techniques, financiers et projet

-> Préconiser la solution optimale

-> Faire une estimation détaillée du projet

-> Faire un planning

-> Rédiger un cahier des charges

La phase de conception définit le processus de réalisation. Elle comprend :

-> La conception de l'architecture générale du système
-> La conception de l'architecture détaillée

-> La conception détaillée de chaque composant (interfaces, services, base de données)

-> La conception des plans de tests

La phase de réalisation est la phase où est produit l'objet du projet. Elle comprend :

-> La programmation des composants
-> Les tests unitaires
-> La réalisation des jeux d'essai
-> Les tests d'interface

-> Les tests d'intégration (reprises, performance...)

La phase de recette est la phase de contrôle qualité, où l'on s'assure que le produit fini
répond bien à la demande initiale, à l'intérieur des contraintes posées :

-> Les tests de validation

-> Les tests en parallèle

-> Les tests de non régression

-> Les tests de réception ou recette

La phase de mise en production s'achève par la mise en production.

-> Les tests de mise en production

La phase de maintenance est la phase qui permet à l'objet du projet de se maintenir au
cours du temps.

-> La gestion du changement et des évolutions
Il existe plusieurs types de modèles :

-> Les modèles de cycle de vie linéaire

• Modèle en cascade

• Modèle en V

• Modèle en W



Chaque phase du cycle de vie doit être réalisée avec tous les détails requis avant de passer à
la phase suivante. Il y a en particulier un effort important à fournir pour la documentation.

Il n'existe pas de version du logiciel exécutable avant la fin du développement. Toute reprise,
en cas d'écart entre la compréhension des besoins et le besoin réel, est coûteuse.

-> Les modèles de cycle de vie non linéaire

Les logiciels réalisés suivant ces modèles sont complétés par itérations ou incréments
successifs. Les détails de réalisation peuvent être reportés afin de produire une version
opérationnelle du logiciel au plus tôt. Ce type de modèles semble plus approprié pour prendre
en compte le caractère évolutif des besoins des utilisateurs.

• Modèle incrémental

• Modèle évolutif

• Modèle en spirale

• Modèle de cycle RAD

• ...

Il faut souligner la différence entre étapes (découpage temporel) et activités (découpage
selon la nature du travail). Il y a des activités qui se déroulent dans plusieurs étapes (ex : La
spécification, la validation et la vérification), voire dans toutes les étapes (ex : La
documentation).


MODELE EN CASCADE

Dans ce modèle, les étapes sont réalisées de façon séquentielle. Chaque étape donne lieu à
l'établissement d'un document.

Analyse des besoins ou analyse préalable :

Document final : Cahier des charges + plan qualité

-> Qualités fonctionnelles attendues en termes des services offerts,

-> Qualités non fonctionnelles attendues : Efficacité, sûreté, sécurité, facilité d'utilisation,
portabilité...

-> Qualités attendues du procédé de développement (ex : Procédures de contrôle qualité).

Le cahier des charges peut inclure une partie destinée aux clients (définition de ce que
peuvent attendre les clients) et une partie destinée aux concepteurs (spécification des
besoins).

Étude préliminaire ou étude de faisabilité ou planification :

Document final : Rapport d'analyse préliminaire ou schéma directeur
-> Définition globale du problème,

-> Différentes stratégies possibles avec avantages/inconvénients,

-> Ressources, coûts, délais.


Analyse du système :


Analyse détaillée de toutes les fonctions et autres caractéristiques que le logiciel devra
réaliser pour l'usager, tel que vu par l'usager.

Résultat : Document de spécifications qui définit le « quoi » du logiciel. Ce document doit être
rédigé dans un langage aussi formel que possible.

-> Modélisation du domaine,

-> Modélisation de l'existant (éventuellement),

-> Définition d'un modèle conceptuel (ou spécification conceptuelle),

-> Plan de validation.

Conception générale :

Définition de l'architecture générale du logiciel. Pas de détails sur la manière dont les
éléments composant le système seront implantés.

-> Résultat : Document de conception générale

Conception détaillée :

Spécification de la manière dont chacun des composants du logiciel sera réalisé et dont ils
interagiront.

-> Résultat : Documents de conception détaillée.

Codage et tests unitaires :

Document final : Dossiers de programmation et codes sources

-> Traduction dans un langage de programmation,

-> Tests avec les jeux d'essais par module selon le plan de test.

Intégration et tests de qualification :

-> Composition progressive des modules,

-> Tests des regroupements de modules,

-> Test en vraie grandeur du système complet selon le plan de test global (« alpha testing »).

Installation :

Mise en fonctionnement opérationnel chez les utilisateurs. Parfois restreint dans un premier
temps à des utilisateurs sélectionnés (« beta testing »).

Maintenance :

-> Maintenance corrective (ou curative),

-> Maintenance adaptative,

-> Maintenance perfective.



Activités transversales à tout le cycle de vie :


-> Spécification, documentation, validation et vérification, management.

Des études ont été menées pour évaluer le coût des différentes étapes du développement:


Type de système

Conception

Implantation

Test

Gestion

44%

28%

28%

Scientifique

44%

26%

30%

Industriel

46%

20%

34%



Mais c'est la maintenance qui coûte le plus cher.



Coûts relatifs de correction des exigences, lorsque découvertes à différents stades

Les avantages du modèle en cascade

-> On a une idée claire de ce qu’il y a à faire.

-> Il est simple à comprendre.

-> Il permet une normalisation des cadres conceptuels et terminologiques des différentes
activités.

Inconvénients :

-> Il ne reflète pas la façon dont le code est réellement développé.

-> Il manque de flexibilité en cas d’imprévus.

-> Il n’y a pas de retour avant la livraison chez le client.



































MODELE EN V


Le modèle en V est une autre façon de présenter une démarche qui reste linéaire, mais qui
fait mieux apparaître les produits intermédiaires à des niveaux d'abstraction et de formalité
différents et les procédures d'acceptation (validation et vérification) de ces produits
intermédiaires.

Le V est parcouru de gauche à droite en suivant la forme de la lettre : les activités de
construction précèdent les activités de validation et vérification. Mais l'acceptation est
préparée dès la construction (flèche de gauche à droite). Cela permet de mieux approfondir la
construction et de mieux planifier la 'remontée' d'abstraction et de formalité différentes et les
procédures d'acceptation (validation et vérification) de ces produits intermédiaires.



-► enchaînement


lien de validation lemps


Il a pour avantage de montrer comment les activités de "tests" sont liées à celles d'analyse et
de conception. Comme pour le modèle en cascade, il y a un manque de retour, pas de
résultats intermédiaires servant de base à la discussion avec le client.


MODÈLE EN W



































MODELE INCREMENTAL


-> Division du logiciel en sous-systèmes (un par fonctionnalité)

-> Première version : Logiciel partiel

-> Chaque nouvelle version ajoute un nouveau sous-système

Ce modèle consiste à développer le futur logiciel par lots et à établir un planning de
réalisation de ces lots avant le démarrage du processus de développement. Chaque lot doit
fournir un produit qui sera immédiatement mis en exploitation dans un environnement
opérationnel.

L'ensemble des produits en exploitation à un moment donné constitue une version provisoire
du logiciel dont la durée de vie s'étend jusqu'à la livraison du prochain lot.

Les avantages d'un tel modèle :

-> Les efforts de maintenance d'une version provisoire sont faibles.

-> Chaque nouvelle version améliorant la précédente, il y a une meilleure adéquation entre
les besoins des utilisateurs et les besoins couverts par le logiciel.

Les inconvénients :

-> Il faut spécifier dès le début du développement l'architecture globale du logiciel et définir
les lots qui seront développés : le noyau, les incréments qui doivent être fonctionnellement
indépendants, leur intégration.

-> L'intégration de nouveaux composants est de plus en plus complexe.


Expression
du besoin


J

Spécifications

Ê ■

Conception


/

incrément


Conception
du système


Développement


'

1


Tests


Conception


Conception

incrément

f

incrément

Vv j

Maintenance

' A

Tfc- Développement

Développement

~T



Tests


Tests


L


Maintenance


Maintenance


C'est un modèle adapté aux grands projets. Néanmoins, l'architecture du système doit
permettre de définir des domaines suffisamment découplés. Dans le cas contraire, certains
incréments doivent attendre que les incréments avec lesquels ils sont liés soient suffisamment
développés. Lorsqu'on leur propose un développement par lot, les Maîtrises d'Ouvrage doivent
vérifier le couplage des domaines.








MODELE EVOLUTIF
-> Approche itérative

-> Division du logiciel en sous-systèmes (un par fonctionnalité)

-> Première version : Coquille complète du logiciel

-> Chaque nouvelle version apporte une modification / amélioration à un sous-système

Version n

T

Détermination des besoins


Programmation


Expérimentation


Version n +1


Avantages

-> Formation précoce des utilisateurs, retours rapides.

-> Création précoce de nouveaux marchés pour les nouvelles fonctionnalités.

-> Focalisation sur le nouveau domaine d'expertise à chaque étape (version).

-> Détection précoce des problèmes imprévus (correction immédiate du système en
développement).

Inconvénients

-> Risque de la remise en cause du noyau (fonctionnalités de base) au cours du
développement.


MODÈLE DE CYCLE RAD



Cycles de
prototypage





















Structure d'une phase dans le cycle RAD


Travaux préparatoires


Session participative


Travaux de
conclusion


Approche de construction de systèmes d'information qui combine l'utilisation d'outils CASE,
du prototypage itératif et de l'observation d'échéanciers rigoureux dans une méthodologie
efficace visant à réduire les coûts de développement tout en assurant une qualité raisonnable
du produit.

Constat fréquent

-> Une solution qui satisfait 4/5 des exigences peut être produite dans le Va du temps requis
pour développer une solution complète.

-> Les exigences de rentabilité d'un logiciel peuvent être entièrement satisfaites même si
certaines exigences fonctionnelles ne le sont pas encore tout à fait.

-> L'acceptabilité d'un logiciel peut être déterminée sur la base convenue sous-ensemble
minimum d'exigences utiles plutôt que sur toutes les exigences définies.

Objectifs

-> Réduire le temps de développement (quitte à faire certains compromis sur les coûts et les
exigences de qualité).

-> Permettre au client de juger le plus tôt possible.

-> Mise en marché rapide d'un sous-ensemble utile du logiciel.

-> Pour satisfaire les exigences de rentabilité exprimées par le client.

-> Pour limiter les menaces de changements tardifs auxquelles le projet s'expose N itérations
Une question de compromis.

-> Temps / coûts / qualité.

Les compromis déterminent le rythme du développement
-> Développement efficace : Équilibre entre coût, temps et qualité.

• RAD normal : Compromit au niveau des coûts et de la qualité pour favoriser la réduction du
temps de développement.

• RAD extrême : Codage intensif!! (Coûts plus élevés, qualité moindre).

Contraintes du processus

-> Le projet ne doit pas durer plus de 6 mois.

-> Le développement itératif doit converger vers une solution rentable et acceptable pour
l'entreprise.

-> Pour être accepté, chaque livrable (version du logiciel, documents, etc.) doit répondre à un
besoin de l'entreprise.

-> Toute partie pouvant influencer la définition des exigences doit être représentée dans
l'équipe de développement tout au long du processus.

-> Les clients, les développeurs et gestionnaires doivent accepter des documents informels








-> L'équipe de développement doit avoir l'autorisation de prendre des décisions généralement
réservées aux gestionnaires.

Caractéristiques

-> Équipes hybrides.

-> Environ six personnes incluant développeurs, utilisateurs, personnes impliquées dans la
définition des exigences du projet (client).

-> Les développeurs choisis devront être flexibles et polyvalents de façon à pouvoir assumer
à la fois les rôles d'analyse, de concepteurs et de programmeurs.

-> Utilisation d'outils spécialisés supportant.

-> Développement visuel, création de prototypes (jetables et incrémentales), langages
multiples, planification, travail d'équipe et en collaboration, utilisation de composants
réutilisables, utilisation de bibliothèques, gestion de versions.

-> Encadrement strict du temps (timeboxing).

-> Élimination des aspects secondaires (définitivement ou temporairement) afin de respecter
des échéanciers fixes.

Développement par prototypage itératif et incrémental

À chaque itération :

-> Développement d'une version du logiciel.

-> La durée de chaque itération varie entre une journée et trois semaines.

-> Session de groupe (focus group) pour la mise au point.

-> Environ 2 heures.

-> Évaluation de la dernière version.

-> Planification de la prochaine version : on priorise les exigences et on élimine celles qui ne
pourront être réalisées dans le temps prévu alloué.

Le RAD n'est pas approprié :

-> Pour les applications nécessitant d'interagir avec d'autres.

-> Pour des applications critiques.

-> Lorsqu'une performance optimale est requise.

-> Lorsqu'une grande fiabilité est exigée.

-> Lorsque la technologie requise n'est pas bien maîtrisée.


MODELE EN SPIRALE

Enfin le modèle en spirale, de Boehm (88), met l'accent sur l'évaluation des risques. À chaque
étape, après avoir défini les objectifs et les alternatives, celles-ci sont évaluées par différentes
techniques (prototypage, simulation...), l'étape est réalisée et la suite est planifiée. Le
nombre de cycles est variable selon que le développement est classique ou incrémental.

La démarche à suivre est :

-> Développement de sous-ensembles représentatifs du logiciel

-> Validation des composantes en fonction des besoins fonctionnels, des contraintes
matérielles/logicielles...


Le déroulement à suivre est : composé d'une suite de cycles de développement de 4 phases
dont le nombre n'est pas déterminé à l'avance et qui dépend de l'approche de développement
choisie pour réaliser le produit issu de chaque phase ou cycle.

Chaque cycle de la spirale se déroule en 4 phases :

-> Phase d'identification : Identification des besoins, détermination des objectifs, des
alternatives pour les atteindre et des contraintes.

-> Phase d'évaluation : Analyse des risques, évaluation des alternatives, identifier et résoudre
les risques.

-> Phase de réalisation : Développement et vérification de la solution à l'issue de la phase
précédente.

-> Phase de vérification et validation du produit élaboré dans la phase précédente, planifier la
prochaine phase.


Analyse des besoins




Prototype


_ï _

Conception

H - » Prototype


Codage


Prototype




Tests et installation

















Points forts :


-> Produire rapidement un logiciel opérationnel minimal. Permets de se concentrer sur les
aspects les plus incertains du développement.

-> Suppose une discipline stricte pour éviter de « coder/finaliser ». Il faut accepter les
remises en cause de la part du client à chaque nouvelle évaluation.

-> Son ouverture à l'ensemble des approches et technologies de développement existantes
-> son caractère itératif. L'intégration d'une approche orientée - risque : Les risques peuvent
être appréhendés dès le début du projet, lors de la réalisation/livraison de la première
version/composante du logiciel et permettre de réviser les choix effectués au cours des
différents cycles en fonction de l'avancement du projet.

-> Évite d'approfondir la spécification trop tôt. Seules les spécifications de la première
version/composante sont définies, les autres le seront plus tard.

Points faibles :

-> Difficultés pour mener à bien les premiers cycles de la spirale.

-> Risque de remise en cause des spécifications des modules/versions déjà réalisé(e)s lors de
l'analyse de nouveaux modules/versions.

-> Difficultés de contrôle du processus.

-> Organisation du développement souvent modifiée pour le client.


UP


Le processus unifié est un processus de développement logiciel itératif, centré sur
l’architecture, piloté par des cas d’utilisation et orienté vers la diminution des risques. C’est un
patron de processus pouvant être adapté à une large classe de systèmes logiciels, à différents
domaines d’application, à différents types d’entreprises, à différents niveaux de compétences
et à différentes tailles de l’entreprise.

UP est itératif

L’itération est une répétition d’une séquence d’instructions ou d’une partie de programme un
nombre de fois fixé à l’avance ou tant qu’une condition définie n’est pas remplie, dans le but
de reprendre un traitement sur des données différentes. Elle qualifie un traitement ou une
procédure qui exécute un groupe d’opérations de façon répétitive jusqu'à ce qu'une condition
bien définie soit remplie.


Exigences


Planning initial


Plar


Évi




Une itération prend en compte un certain nombre de cas d'utilisation et traite en priorité les
risques majeurs.

UP est centré sur l'architecture

Ph. Kruchten propose différentes perspectives, indépendantes et complémentaires, qui
permettent de définir un modèle d'architecture (publication IEEE, 1995).


Vue logique


Vue des composants



UP est piloté par les cas d'utilisation d'UML

Le but principal d'un système informatique est de satisfaire les besoins du client. Le processus
de développement sera donc accès sur l'utilisateur. Les cas d'utilisation permettent d'illustrer
ces besoins. Ils détectent puis décrivent les besoins fonctionnels (du point de vue de
l'utilisateur), et leur ensemble constitue le modèle de cas d'utilisation qui dicte les
fonctionnalités complètes du système.



«interne»
Comité de validation


Vie du processus unifié

L'objectif d'un processus unifié est de maîtriser la complexité des projets informatiques en
diminuant les risques. UP est un ensemble de principes génériques adapté en fonction des
spécificités des projets. UP répond aux préoccupations suivantes :

- QUI participe au projet ?

- QUOI, qu'est-ce qui est produit durant le projet ?























- COMMENT doit-il être réalisé ?

- QUAND est réalisé chaque livrable ?

L'architecture bidirectionnelle

IIP gère le processus de développement par deux axes.

L'axe vertical représente les principaux enchaînements d'activités, qui regroupent les
activités selon leur nature. Cette dimension rend compte l'aspect statique du processus qui
s'exprime en terme décomposant, de processus, d'activités, d'enchaînements, d'artefacts et
de travailleurs.

L'axe horizontal représente le temps et montre le déroulement du cycle de vie du
processus. Cette dimension rend compte de l'aspect dynamique du processus qui s'exprime
en termes de cycles, de phases, d'itérations et de jalons.


Analyse Elaboration Construction Transition

des besoins


Expression des besoins
Analyse
Conception
Implémentation

Test



IIP répète un certain nombre de fois une série de cycle qui s'articule autour de 4 phases :

- Analyse des besoins

- Élaboration

- Construction

- Transition

Pour mener efficacement un tel cycle, les développeurs ont besoin de toutes les
représentations du produit logiciel.

- Un modèle de cas d'utilisation.

- Un modèle d'analyse : Détailler les cas d'utilisation et procéder à une première répartition
du comportement.

- Un modèle de conception : Finissant la structure statique du système sous forme de sous-
systèmes, de classes et interfaces.

- Un modèle d'implémentation : Intégrant les composants.

- Un modèle de déploiement : Définissant les nœuds physiques des ordinateurs.

- Un modèle de test : Décrivant les cas de test vérifiant les cas d'utilisation.

- Une représentation de l'architecture.












Les activités


Expression des besoins : L'expression des besoins comme son nom l'indiquent, permettent
de définir les différents besoins :

- Inventorier les besoins principaux et fournir une liste de leurs fonctions.

- Recenser les besoins fonctionnels (du point de vue de l'utilisateur) qui conduisent à
l'élaboration des modèles de cas d'utilisation.

- Appréhender les besoins non fonctionnels (technique) et livrer une liste des exigences.

Le modèle de cas d'utilisation présente le système du point de vue de l'utilisateur et
représente sous forme de cas d'utilisation et d'acteur, les besoins du client.

Analyse : L'objectif de l'analyse est d'accéder à une compréhension des besoins et des
exigences du client. Il s'agit de livrer des spécifications pour permettre de choisir la
conception de la solution. Un modèle d'analyse livre une spécification complète des besoins
issus des cas d'utilisation et les structures sous une forme qui facilitent la compréhension
(scénarios), la préparation (définition de l'architecture), la modification et la maintenance du
futur système.

Il s'écrit dans le langage des développeurs et peut être considéré comme une première
ébauche du modèle de conception.

Conception : La conception permet d'acquérir une compréhension approfondie des
contraintes liées au langage de programmation, à l'utilisation des composants et au système
d'exploitation.

Elle détermine les principales interfaces et les transcrit à l'aide d'une notation commune. Elle
constitue un point de départ à l'implémentation :

- Elle décompose le travail d'implémentation en sous-système.

- Elle crée une abstraction transparente de l'implémentation.

Implémentation : L'implémentation est le résultat de la conception pour implémenter le
système sous forme de composants, c'est-à-dire, de code source, de scripts, de binaires,
d'exécutables et d'autres éléments du même type.

Les objectifs principaux de l'implémentation sont de planifier les intégrations des composants
pour chaque itération, et de produire les classes et les sous-systèmes sous forme de codes
sources.

Test : Les tests permettent de vérifier des résultats de l'implémentation en testant la
construction. Pour mener à bien ces tests, il faut les planifier pour chaque itération, les
implémenter en créant des cas de tests, effectuer ces tests et prendre en compte le résultat
de chacun.

Les phases

Analyse des besoins : L'analyse des besoins donne une vue du projet sous forme de produit
fini. Cette phase porte essentiellement sur les besoins principaux (du point de vue de
l'utilisateur), l'architecture générale du système, les risques majeurs, les délais et les coûts.



On met en place le projet. Elle répond aux questions suivantes :


- Que va faire le système ? Par rapport aux utilisateurs principaux, quels services va-t-il
render ?

- Quelle va être l'architecture générale (cible) de ce système

- Qu'elles vont être : les délais, les coûts, les ressources, les moyens à déployer ?

Élaboration : L'élaboration reprend les éléments de la phase d'analyse des besoins et les
précise pour arriver à une spécification détaillée de la solution à mettre en œuvre.
L'élaboration permet de préciser la plupart des cas d'utilisation, de concevoir l'architecture du
système et surtout de déterminer l’architecture de référence. Au terme de cette phase, les
chefs de projet doivent être en mesure de prévoir les activités et d'estimer les ressources
nécessaires à l'achèvement du projet. Les tâches à effectuer dans la phase élaboration sont
les suivantes :

- Créer une architecture de référence.

- Identifier les risques, ceux qui sont de nature à bouleverser le plan, le coût et le calendrier

- Définir les niveaux de qualité à atteindre.

- Formuler les cas d’utilisation pour couvrir les besoins fonctionnels et planifier la phase de
construction.

- Élaborer une offre abordant les questions de calendrier, de personnel et de budget.

Construction : La construction est le moment où l'on construit le produit. L'architecture de
référence se métamorphose en produit complet. Le produit contient tous les cas d'utilisation
que les chefs de projet en accord avec les utilisateurs ont décidé de mettre au point pour
cette version.

Transition : Le produit est en version bêta. Un groupe d'utilisateurs essaye le produit et
détecte les anomalies et défauts. Cette phase suppose des activités comme la formation des
utilisateurs clients, la mise en œuvre d'un service d'assistance et la correction des anomalies
constatées.


RUP

"Rational Unified Process" est une méthode développement propriété de la société Rational et
basé sur l’utilisation de l’atelier Rational. Elle est vendue sous la forme d’une documentation
hypertexte et d’outils incorporables à chaque composant de l’AGL de Rational. C’est une
méthode évolutive, qui met en œuvre les mêmes principes que le RAD ou le développement
en spirale.

Elle est composée de 4 phases :

-> Inception : Initial "use case", coût/bénéfice, risques, planification
-> Élaboration : "use case" à 80% terminés, architecture logicielle, prototype
-> Construction : Développement
-> Transition : Tests, conversion et déploiement

RUP utilise le niveau élevé d’automatisation que lui procure l’AGL Rational. Il permet :


-> D’une part de planifier des itérations à l’intérieur de chaque phase,



-> De paralléliser les processus au maximum : ainsi la définition d'architecture peut
commencer tandis que les spécifications ne sont pas terminées.

Le résultat peut être impressionnant, si l'équipe projet est composée d'experts, maîtrisant
parfaitement les risques projet. C'est probablement une voie très intéressante, lorsque des
standards multi-fournisseurs seront adoptés. En effet, les maîtrises d'ouvrage devront être
attentives à ne pas s'enfermer dans méthodes qui lient trop la compétence de développement
des systèmes d'information au savoir-faire d'un fournisseur.


Incaptlon Elaboration Construction


Transition


Expression des besoins
Spécifications
Analyse & Conception
Mise en oeuvre
Test
Déploiement
rocessus de support
Gestion de configuration
Conduite de projet
Logistique



;






i





Iteration(si I lier. I iter I itei
Prêliminaire(s! #1 1 U2 " &n


#r*1 'tttH

Itérations


lier. J Iter | ter. | ter




LE CYCLE DE L'EXTREME PROGRAMMING


.ji r-imni ut- K-ji



Appiobaton client


♦


Une méthode agile

Comme toutes les méthodes de développement, l'Extreme Programming propose un cadre
pour l'ensemble des aspects du projet logiciel, depuis l'analyse des besoins jusqu'aux tests,
en passant par la conception. Mais à la différence des processus prédictifs, recourant
généralement à UML (même si XP utilise aussi parfois UML comme support de
communication), XP ne se fonde pas sur la définition exhaustive et précoce des besoins ; elle
parie plutôt, à partir d'un ensemble de règles strictes, sur la souplesse et la mise en valeur du
"capital humain".








































La programmation comme discipline collectiv
Lire la suite

• Taille
  2.82 MB
• Nombre de pages
  15