Cycle en v, Study notes of Economics

cycle v - cycle v

Typology: Study notes

2014/2015

Uploaded on 04/23/2015

a-kaki
a-kaki 🇩🇿

5

(1)

5 documents

1 / 3

Toggle sidebar

This page cannot be seen from the preview

Don't miss anything!

bg1
Cycle en V
Analyse des besoins
et faisabilité
Spécications
Conception
Architecturale
Conception détaillée
Codage
Tests unitaires
Tests d'intégration
Tests
de validation
Recette
Les phases du cycle en V
Le modèle du cycle en V (en comparaison avec les mé-
thodes dites Agile) est un modèle conceptuel de gestion
de projet imaginé suite au problème de réactivité du
modèle en cascade. Il permet, en cas d'anomalie, de li-
miter un retour aux étapes précédentes. Les phases de la
partie montante doivent renvoyer de l'information sur les
phases en vis-à-vis lorsque des défauts sont détectés, afin
d'améliorer le logiciel.
Issu du monde de l'industrie, le cycle en V est devenu un
standard de l'industrie logicielle depuis les années 1980.
Depuis, l'apparition de l'ingénierie des systèmes est de-
venu un standard conceptuel dans tous les domaines de
l'Industrie. Le monde du logiciel ayant de fait pris un peu
d'avance en termes de maturité, on trouvera dans la bi-
bliographie courante souvent des références au monde du
logiciel qui pourront s’appliquer au système.
Les phases à travers le temps et le niveau de détails
Les étapes :
Analyse des besoins et faisabilité
Spécification fonctionnelle
Conception architecturale
Conception détaillée
Codage
Test unitaire
Test d'intégration
Test de validation : recette usine, validation usine,
VAU
Test d'Acceptation : vérification d'aptitude au bon
fonctionnement, VABF
Une des différences entre la recette usine et la recette fi-
nale est essentiellement contractuelle. Aussi, il n'est pas
rare que le MOA (maître d'ouvrage) délègue la valida-
tion auprès d'un organisme de validation, cet organisme
étant bien souvent constitué d'experts afinde diminuer les
erreurs de validation.
1 Rôles
Dans le contexte des projets de grande envergure ont
émergé des rôles pour partager et désigner les responsa-
bilités :
Maîtrise d'ouvrage (MOA) qui regroupe les
fonctions suivantes :
le maître d’ouvrage stratégique (MOAS);
le maître d’ouvrage légué (MOAD) ;
le maître d’ouvrage opérationnel (MOAO);
l’assistant à maîtrise d’ouvrage (AMOA ou
AMO) ;
l’expert métier ;
enfin l’utilisateur, auservice duquel se trouvent
toutes les autres fonctions.
Maîtrise d'œuvre (MOE)
Maîtrise d'œuvre déléguée (MOED)
l'Équipe Architecturale
l'Équipe de développement
Titulaire de marché
On retrouve dans ce découpage le V, d'où le nom de ce
modèle.
1
pf3

Partial preview of the text

Download Cycle en v and more Study notes Economics in PDF only on Docsity!

Cycle en V

Analyse des besoinset faisabilité

Spécifications

ArchitecturaleConception

Conception détaillée

Codage

Tests unitaires

Tests d'intégration

de validationTests

Recette

Les phases du cycle en V

Le modèle du cycle en V (en comparaison avec les mé- thodes dites Agile) est un modèle conceptuel de gestion de projet imaginé suite au problème de réactivité du modèle en cascade. Il permet, en cas d'anomalie, de li- miter un retour aux étapes précédentes. Les phases de la partie montante doivent renvoyer de l'information sur les phases en vis-à-vis lorsque des défauts sont détectés, afin d'améliorer le logiciel.

Issu du monde de l'industrie, le cycle en V est devenu un standard de l'industrie logicielle depuis les années 1980. Depuis, l'apparition de l'ingénierie des systèmes est de- venu un standard conceptuel dans tous les domaines de l'Industrie. Le monde du logiciel ayant de fait pris un peu d'avance en termes de maturité, on trouvera dans la bi- bliographie courante souvent des références au monde du logiciel qui pourront s’appliquer au système.

Les phases à travers le temps et le niveau de détails

Les étapes :

  • Analyse des besoins et faisabilité
  • Spécification fonctionnelle
  • Conception architecturale
    • Conception détaillée
    • Codage
    • Test unitaire
    • Test d'intégration
    • Test de validation : recette usine, validation usine, VAU
    • Test d'Acceptation : vérification d'aptitude au bon fonctionnement, VABF

Une des différences entre la recette usine et la recette fi- nale est essentiellement contractuelle. Aussi, il n'est pas rare que le MOA (maître d'ouvrage) délègue la valida- tion auprès d'un organisme de validation, cet organisme étant bien souvent constitué d'experts afin de diminuer les erreurs de validation.

1 Rôles

Dans le contexte des projets de grande envergure ont émergé des rôles pour partager et désigner les responsa- bilités :

  • Maîtrise d'ouvrage (MOA) qui regroupe les fonctions suivantes : - le maître d’ouvrage stratégique (MOAS) ; - le maître d’ouvrage délégué (MOAD) ; - le maître d’ouvrage opérationnel (MOAO) ; - l’assistant à maîtrise d’ouvrage (AMOA ou AMO) ; - l’expert métier ; - enfin l’utilisateur, au service duquel se trouvent toutes les autres fonctions.
  • Maîtrise d'œuvre (MOE)
    • Maîtrise d'œuvre déléguée (MOED)
    • l'Équipe Architecturale
    • l'Équipe de développement
    • Titulaire de marché

On retrouve dans ce découpage le V , d'où le nom de ce modèle.

2 5 ARTICLES CONNEXES

2 Documents par phase

Pour une bonne communication entre les différents parte- naires du projet, il est nécessaire d'établir des documents de référence.

3 Risques inhérents au Cycle en V

Différence entre la théorie (les spécifications) et la pratique (ce qui a été produit)

Une fois l'ensemble des besoins capturés et les spécifica- tions établies, il arrive que dès le niveau de l'architecture, voire en phase de conception détaillée ou de codage, des difficultés d'ordre de cohérence, technique et humain in- terviennent. C'est la fameuse différence entre la théorie et la pratique : en théorie il n'y en a pas!

En pratique, il est difficile voire impossible de totalement détacher la phase de conception d'un projet de sa phase de réalisation. C'est souvent au cours de l'implémentation qu'on se rend compte que les spécifications initiales étaient incomplètes, fausses, ou irréalisables, sans comp- ter les ajouts de nouvelles fonctionnalités par les clients (scope creep). Lire à ce sujet Le Mythe du mois-homme. C'est principalement pour cette raison que le Cycle en V n'est pas toujours adapté à un développement logiciel. La problématique des projets longue durée qui sont adaptés sur ce mode de gestion de projet est aussi souvent qu'ils risquent de ne plus « coller » aux besoins qui évoluent dans le temps.

D'autres modèles permettent plus facilement des mo- difications (parfois radicales) de la conception ini- tiale à la suite d'une première implémentation ou sé- rie d'implémentations. Voir par exemple à ce sujet : Développement rapide d'applications ou Méthode agile de gestion de projet. Par contre, ces méthodes manquent parfois de traçabilité, ce qui nécessite d'impliquer le client à la fois en termes de conception et également en termes juridiques (avec un cycle en V le client est censé recevoir

ce qu'il a commandé, alors qu'avec des méthodes “agiles” le client devient co-développeur et intervient donc au ni- veau du projet). En cas de problèmes, devant les tribu- naux, cette nuance fait la différence entre un cycle en V et une méthode “agile”. Un compromis consiste à appliquer un cycle en V le plus court possible et de faire évoluer le projet sous forme de versions, prenant ainsi en compte le fait que le pro- jet ne sera pas parfait et qu'il sera amélioré au fil des versions. Cela permet également de bénéficier du retour d'expérience des versions précédentes. Ce compromis est particulièrement formateur au sein d'un projet, pour les équipes des phases “amont” dédiées à l'étude du besoin, aux spécifications et à la conception (la “théorie”), qui seront ainsi confrontées aux résultats concrets (la “pra- tique”). A noter que la société Microsoft pratique ce com- promis avec art depuis plusieurs décennies : maîtriser la traçabilité et les délais à l'aide d'une succession de cycle en V les plus courts possibles, quitte à diffuser ul- térieurement les mises à jour ... (ex : tous les systèmes d'exploitation Microsoft depuis Windows 2000).

4 Comité de pilotage

Pour améliorer le suivi du projet sur le plan de l'observation et des choix à effectuer, il se constitue géné- ralement une équipe transversale au projet : le comité de pilotage. Ce comité de pilotage est généralement consti- tué d'un membre de chaque catégorie de rôle. Ce comité joue en quelque sorte le rôle de gaine de protection autour du V. Ce comité analyse les métriques issues des activités de chaque phase afin de réaliser la jonction entre la MOE et la MOA.

5 Articles connexes

  • Cycle de développement
  • Cycle en Y
  • Ingénierie des systèmes
  • Portail de l’informatique