Version 1.0

1
GENIE LOGICIEL Préambule, acteurs, normes et
cycles de vie

• Hervé DOMALAIN
• ENSEIRB 2004 / 2005

2
Planning prévisionnel
3
Sommaire

1. Préambule
2. Les acteurs
3. Les normes applicables
4. Définitions
5. Norme ISO 90002000
6. Norme ISO 9126
7. Norme ISO 12207
8. Les cycles de vie types
9. Les cycles de vie linéaires
10. Les cycles de vie en  V 
11. Les cycles de vie itératifs et incrémentaux
12. La mise en œuvre de ces cycles types dans la
    réalité du projet

4
La crise du logiciel (1/3)

• Les échecs de grands projets durant les années 60
  et au début des années 70 ont mis en évidence les
  problèmes de la gestion de projet.
• Ces projets n'ont pas échoué parce que les
  programmeurs étaient incompétents. La faute
  incombait en fait aux techniques de gestion des
  projets mises en oeuvre.

5
La crise du logiciel (2/3)

• En 1979, le gouvernement américain estimait que
  la plupart des grands projets avaient échoué
• Payés mais jamais livrés 47
• Livrés mais jamais utilisés 30
• Abandonnés ou refaits 20
• Utilisés après modifications 3
• Utilisés en létat 2

6
La crise du logiciel (3/3)

• Les symptômes les plus caractéristiques de cette
  crise sont décrits par Booch en 1983
• Les logiciels réalisés ne correspondent souvent
  pas aux besoins des utilisateurs,
• Les logiciels contiennent trop d'erreurs (la
  qualité du logiciel est insuffisante),
• Les coûts du développement sont rarement
  prévisibles et sont généralement prohibitifs,
• La maintenance des logiciels est une tâche
  complexe et coûteuse,
• Les délais de réalisation sont généralement
  dépassés,
• Les logiciels sont rarement portables.

7
Naissance du génie logiciel

• Le génie logiciel existe depuis une trentaine
  d'années seulement.
• Il est né en 1968 à Garmisch (Allemagne) ( 1st
  conference on software engineering  sous le
  parrainage de l'OTAN).
• Il a été défini de toutes pièces par un groupe de
  scientifiques pour répondre à la crise du
  logiciel avec quelques idées émergentes
• La production de logiciel doit être organisée,
• Contrôle des coûts et de la qualité, etc ...

8
Génie et génie logiciel

• Génie ensemble des connaissances et des
  techniques concernant la conception, la mise en
  œuvre et les applications de procédés, de
  dispositifs, de machines propres à un domaine
  donné (Petit Larousse Illustré).
• Génie logiciel ensemble des activités de
  conception et de mise en œuvre des produits et
  des procédurestendant à rationaliser la
  production du logiciel et son suivi.

9
Définition du génie logiciel

• Le génie logiciel est lensemble des moyens
  techniques, industriels et humains quil faut
  réunir pour spécifier, construire, distribuer et
  maintenir des logiciels qui soient sûrs,
  conviviaux, évolutifs et économiques.
• Le but est donc daméliorer la qualité et la
  productivité.

10
Contexte actuel et perspectives (1/2)

• Les applications sont de plus en plus complexes
  (besoins fonctionnels, environnements
  distribués),
• Les solutions techniques doivent sadapter et
  sont donc elles aussi de plus en plus complexes,
• Exigences croissantes des clients,
• Exigences croissantes des responsables de SSII.

11
Contexte actuel et perspectives (2/2)

• La mise au point des logiciels est lente et
  chaotique.
• Le coût de la maintenance est disproportionné.
• Globalement, il nous est très difficile de
  maîtriser les défauts des logiciels, les
  échéances de livraison et les coûts quand ils
  sont complexes.

12
Passer de lartisanat à lindustrialisation

• Actuellement, le génie logiciel ressemble plus à
  de lartisanat organisé quà une activité
  industrielle !
• Il faut maintenant rentrer dans laire de
  lindustrialisation, ce qui signifie la mise en
  œuvre de processus de production, de
  lautomatisation et de normes pour les outils et
  les composants qui entrent dans la fabrication
  des produits.

13
Sommaire

1. Préambule
2. Les acteurs
3. Les normes applicables
4. Définitions
5. Norme ISO 90002000
6. Norme ISO 9126
7. Norme ISO 12207
8. Les cycles de vie types
9. Les cycles de vie linéaires
10. Les cycles de vie en  V 
11. Les cycles de vie itératifs et incrémentaux
12. La mise en œuvre de ces cycles types dans la
    réalité du projet

14
La structure organisationnelledun projet
Les instances du projet
15
La maîtrise douvrage

• Elle est le client du projet dinformatisation.
• Cest au sein de la maîtrise douvrage que lon
  trouve les experts métier et les groupes de
  validation.
• Elle regroupe les acteurs suivants
• Le maître douvrage,
• Le représentant de la maîtrise douvrage
• Les utilisateurs,
• Etc ...

16
Le maître douvrage

• Il est le commanditaire de lopération et, à ce
  titre, il doit en définir les enjeux, les
  objectifs et les exigences qualité (avec laide
  de son représentant et de la maîtrise dœuvre le
  cas échéant).
• Il est le propriétaire de lapplication qui est
  réalisée.
• Il est le donneur dordre et met en place les
  financements nécessaires.
• Il décide du déploiement ou non de lapplication.

17
Le représentant de la maîtrise douvrage

• Il représente le maître douvrage tout au long du
  projet.
• Il a pour rôle 
• Dassurer la conduite générale du projet,
• De veiller au respect des objectifs généraux du
  projet,
• De produire l'expression des besoins,
• De gérer les enveloppes financières,
• De valider les documents relatifs au projet ainsi
  que les maquettes et les prototypes,
• De préparer et exécuter la recette de
  lapplication,
• De mettre en place les mesures daccompagnement
  du changement.

18
Les utilisateurs

• Les utilisateurs ne participent pas au management
  de projet mais il paraît néanmoins important de
  rappeler que ce sont les bénéficiaires de
  lapplication et, quà ce titre, ils sont
  finalement les vrais juges de la qualité des
  produits livrés.
• Plusieurs niveaux dutilisateurs interviennent
  dans lélaboration des produits 
• Lutilisateur final utilise lapplication
  quotidiennement. Il apporte les besoins
  dergonomie et dorganisation de son poste de
  travail,
• Le responsable du service utilisateur donne son
  avis sur les choix organisationnels,
• Les utilisateurs de niveau hiérarchique supérieur
  définissent les objectifs stratégiques.

19
La maîtrise dœuvre

• Elle est responsable de la réalisation de
  lapplication pour la maîtrise douvrage.
• Cest le prestataire du projet choisi par la
  maîtrise douvrage.
• Elle regroupe les acteurs suivants
• Le maître dœuvre,
• Léquipe projet qui peut regrouper de nombreuses
  compétences si le projet est complexe et sil
  sagit dun développement objet le chef de
  projet, le spécificateur, larchitecte, le
  développeur fonctionnel, le développeur
  technique, le qualiticien, ...

20
Le maître dœuvre

• Il est garant de la qualité des produits finis.
• Il affecte les moyens sur le projet.
• Il est responsable du suivi contractuel avec le
  maître douvrage et, le cas échéant, avec les
  sous-traitants.

21
Le chef de projet

• Le chef de projet est responsable de la mise en
  œuvre du projet en respectant les délais, les
  coûts et les exigences de qualité, fixés dans le
  cadre dun engagement de résultat contractualisé
  avec la maîtrise douvrage.
• Il doit gérer au mieux les ressources humaines et
  matérielles qui sont affectées sur le projet.

22
Lanalyste

• Il détermine le périmètre fonctionnel et les
  acteurs (au sens UML) de la future application.
• Il rédige les spécifications fonctionnelles
  générales et détaillées.
• Il identifie les flux de données à gérer.

23
Larchitecte

• Il recense les besoins techniques.
• Il élabore les architectures logicielle et
  applicative.
• Il identifie les besoins en produits tiers
  (composants techniques et fonctionnels) et
  frameworks techniques.

24
Le développeur fonctionnel

• Il réalise les applications décrites dans les
  spécifications fonctionnelles, en tenant compte
  de larchitecture applicative, des frameworks
  techniques et des règles de développement.
• Il développe donc les classes métier dans un
  développement objet.

25
Le développeur technique

• Il réalise les bibliothèques de composants et les
  frameworks techniques en collaboration avec
  larchitecte.
• Il développe donc les classes techniques de bas
  niveau dans un développement objet.

26
Le qualiticien

• Il définit les dispositions dassurance qualité
  formalisées dans le plan dassurance qualité.
• Il veille à la mise en application de ces
  dispositions.
• Il définit les actions correctives si les
  dispositions ne sont pas appliquées.
• Il vérifie et rend compte de la mise en
  application de ces actions.

27
Le comité de pilotage

• Il est constitué
• Du maître douvrage qui en assure la présidence
  et de son représentant,
• Des représentants des utilisateurs de
  lapplication,
• Du maître dœuvre et du chef de projet,
• Des maîtres douvrage des applications
  communicantes.
• Il lance officiellement le projet et valide les
  livrables stratégiques du projet (analyse et
  conception fonctionnelles, conception technique).
  Il valide le produit final sur la base de la
  recette et de lexpérimentation en site pilote et
  autorise la mise en exploitation.

28
Le comité de suivi

• Il est composé au minimum du représentant de la
  maîtrise douvrage et du chef de projet.
• Il est en charge du pilotage opérationnel du
  projet, sassure que le projet poursuit les
  objectifs initiaux et détecte les dérives
  éventuelles.
• Il analyse périodiquement les livrables et, en
  fonction des résultats, met à jour le planning de
  suivi.

29
Sommaire

1. Préambule
2. Les acteurs
3. Les normes applicables
4. Définitions
5. Norme ISO 90002000
6. Norme ISO 9126
7. Norme ISO 12207
8. Les cycles de vie types
9. Les cycles de vie linéaires
10. Les cycles de vie en  V 
11. Les cycles de vie itératifs et incrémentaux
12. La mise en œuvre de ces cycles types dans la
    réalité du projet

30
Le besoin de qualité
Produit inutile
Satisfaction nombrilique
Qualité
Satisfaction hasardeuse
Spécifications inutiles
Insatisfaction du client
A améliorer en priorité
31
Lévolution du concept de qualité
Niveau de qualité
Management total de la qualité
Assurance qualité
Contrôle qualité
1930
1940
1950
1960
1970
1980
1990
2000
32
Assurance qualité

•  Mise en œuvre d'un ensemble approprié de
  dispositions pré-établies et systématiques
  destinées à donner confiance en l'obtention d'une
  qualité requise. 

Objectif client Concerne Finalité
Qualité Satisfaction Produit Zéro défaut
Assurance qualité Confiance Organisation Zéro impasse (couverture totale)
33
Plan qualité

• Le plan qualité est un document qui présente
• le produit, le projet et/ou le contrat auquel il
  sapplique,
• les objectifs relatifs à la qualité du projet, du
  produit et/ou du contrat exprimés en termes
  mesurables chaque fois que cela est possible,
• les exclusions spécifiques,
• la période de validité,
• Etc ...

34
Quest-ce quune norme ?

•  Document établi par consensus et approuvé par
  un organisme reconnu, qui fournit, pour des
  usages communs et répétés, des règles, des lignes
  directrices ou des caractéristiques, pour des
  activités ou leurs résultats, garantissant un
  niveau dordre optimal dans un contexte donné. 

35
Les instances de normalisation

• Il y a de nombreuses instances de normalisation
  qui ont des compétences géographiques différentes
  
• 2 organisations de normalisation de niveau
  international la CEI (Commission
  Electrotechnique Internationale) et l'ISO
  (Organisation Internationale de Normalisation),
• Quelques organisations de normalisation de niveau
  régional le CENELEC (Comité Européen de
  Normalisation Electrotechnique), le COPANT (Pan
  American Standards Commission), ...
• Quelques organisations de normalisation de niveau
  national lAFNOR (Association Française de
  Normalisation), lANSI (American National
  Standards Institute), ...

36
Les contributeurs

• Les contributeurs cités dans le cours sont
• Le SEI qui est le  Software Engineering
  Institute  ( Institut dIngénierie du
  Logiciel ) créé par le Ministère de la Défense
  Américaine (DoD).
• LIEEE (Eye-triple-E) qui est l Institute of
  Electrical and Electronics Engineers 
  ( Institut dIngénieurs en Electricité et en
  Electronique ) qui regroupe 380 000 membres de
  150 pays différents.

37
Sommaire

1. Préambule
2. Les acteurs
3. Les normes applicables
4. Définitions
5. Norme ISO 90002000
6. Norme ISO 9126
7. Norme ISO 12207
8. Les cycles de vie types
9. Les cycles de vie linéaires
10. Les cycles de vie en  V 
11. Les cycles de vie itératifs et incrémentaux
12. La mise en œuvre de ces cycles types dans la
    réalité du projet

38
Composition de la norme ISO 90002000
ISO 9001Norme de spécifications (emploie le terme  doit ) ISO 9004Norme de recommandations (emploie le terme  convient )
Quel est le champ d'application ? Les processus ayant un impact sur la qualité du produit/service Tous les processus et activités (techniques, administratifs ... )
Quel est l'objectif à atteindre ? La maîtrise des processus et lefficacité La performance de l'organisme et l'efficience
Quelle est la cible visée ? Le client Les parties prenantes (clients, actionnaires, personnels ... )
Quelle est la finalité ? La confiance La satisfaction durable
39
Lapproche processus
40
Les points fortsdes normes ISO 90002000

• Le client fait une entrée en force on passe
  d'une notion de conformité aux procédures à une
  recherche de performance des processus avec la
  mesure de la satisfaction des clients et un
  impératif de communication continue avec ceux-ci.
• La maîtrise et l'amélioration des processus
  centrage sur les processus de biens et de
  services et non plus sur les structures.
• Le progrès continue (boucle PDCA) apparition
  dactions préventives et non plus seulement
  correctives (voire curatives).
• Le management des ressources (y compris humaines)
  sans commune mesure avec les préconisations très
  formelles de la version 1994.
• La simplification du vocabulaire, en utilisant
  des termes de langage courant.
• La réduction du nombre de documents normatifs (de
  15 à 4).
• Des compétences dauditeur qualité
  considérablement remaniées.

41
Sommaire

1. Préambule
2. Les acteurs
3. Les normes applicables
4. Définitions
5. Norme ISO 90002000
6. Norme ISO 9126
7. Norme ISO 12207
8. Les cycles de vie types
9. Les cycles de vie linéaires
10. Les cycles de vie en  V 
11. Les cycles de vie itératifs et incrémentaux
12. La mise en œuvre de ces cycles types dans la
    réalité du projet

42
Caractérisation et norme ISO 9126

• Le modèle dévaluation de MacCall sest avéré
  difficile à mettre en oeuvre.
• Ses 11 facteurs et 23 critères le rendent
  complexe.
• Létablissement de la norme ISO 9126 sest fait à
  partir des travaux de MacCall, mais en ramenant
  son modèle à 6 caractéristiques.
• La norme ISO 9126, à la différence des travaux de
  MacCall ne fait pas de différences entre
  caractéristiques internes et externes.

43
Norme ISO 9126

• Objet évaluation des produits logiciels -
  caractéristiques qualité et directives pour leur
  utilisation - parue en octobre 1992 (amendée par
  une norme équivalente en septembre 2002).
• Cette norme recense six "caractéristiques
  qualité" normalisées capacité fonctionnelle,
  fiabilité, facilité d'utilisation, rendement,
  maintenabilité et portabilité.
• Ces caractéristiques comprennent notamment la
  capacité dintégration de lexistant,
  lergonomie, lévolutivité fonctionnelle,
  dimensionnelle (nombre de personnes) et
  matérielle (nombre de serveurs).

44
Capacité fonctionnelle (functionality)

• Ensemble d'attributs portant sur l'existence
  d'un ensemble de fonctions et leurs propriétés
  données. Les fonctions sont celles qui satisfont
  aux besoins exprimés ou implicites
• Aptitude (... à la tâche),
• Exactitude (précision),
• Interopérabilité (possibilités dinteraction avec
  dautres systèmes),
• Conformité réglementaire (... aux lois, aux
  normes),
• Sécurité (daccès).

45
Fiabilité (reliability)

• Ensemble d'attributs portant sur l'aptitude du
  logiciel à maintenir son niveau de service dans
  des conditions précises et pendant une période
  déterminée
• Maturité (fréquence des défaillances, densité des
  défauts),
• Tolérance aux fautes (... aux défaillances,
  stabilité du produit),
• Possibilité de récupération (en cas de
  défaillance).

46
Facilité d'utilisation (usability)

• Ensemble d'attributs portant sur l'effort
  nécessaire pour l'utilisation et l'évaluation
  individuelle de cette utilisation par un ensemble
  défini ou implicite d'utilisateurs
• Facilité de compréhension,
• Facilité d'apprentissage,
• Facilité d'exploitation (trouver de nouvelles
  fonctions).

47
Rendement (efficiency)

• Ensemble d'attributs portant sur le rapport
  existant entre le niveau de service d'un logiciel
  et la quantité de ressources utilisées, dans des
  conditions déterminées
• Comportement par rapport au temps (temps de
  réponse),
• Comportement par rapport aux ressources (mémoire,
  stockage des données en persistance).

48
Maintenabilité (maintenability)

• Ensemble d'attributs portant sur l'effort
  nécessaire pour faire des modifications données
• Facilité d'analyse (trouver la source derreurs),
• Facilité de modification,
• Stabilité (risque deffets imprévus après
  modification),
• Facilité de validation (... après modification).

49
Portabilité (portability)

• Ensemble d'attributs portant sur l'aptitude du
  logiciel à être transféré d'un environnement à
  l'autre
• Facilité d'adaptation (... à différents
  environnements),
• Facilité d'installation,
• Conformité aux règles de portabilité,
• Interchangeabilité (substitution par un autre
  logiciel similaire).

50
Sommaire

1. Préambule
2. Les acteurs
3. Les normes applicables
4. Définitions
5. Norme ISO 90002000
6. Norme ISO 9126
7. Norme ISO 12207
8. Les cycles de vie types
9. Les cycles de vie linéaires
10. Les cycles de vie en  V 
11. Les cycles de vie itératifs et incrémentaux
12. La mise en œuvre de ces cycles types dans la
    réalité du projet

51
Architecture de la norme ISO 12207
52
Les processus de base (1/2)

• Processus dacquisition
• Il définit les activités de lacquéreur,
  cest-à-dire de lorganisme qui acquiert un
  système, un logiciel ou une prestation logicielle
  initialisation, préparation de la consultation,
  préparation et mise à jour du contrat, suivi du
  fournisseur, acceptation et achèvement du
  processus.
• Processus de fourniture
• Il définit les activités du fournisseur,
  cest-à-dire de lorganisme qui fournit le
  système, le logiciel ou la prestation logicielle
  à lacquéreur initialisation, préparation de
  loffre, contrat, planification, exécution et
  maîtrise, revue et évaluation, fourniture et
  achèvement.
• Processus de développement
• Il définit les activités de léquipe de
  développement, cest-à-dire de lorganisme qui
  définit et développe le logiciel mise en œuvre
  du processus, analyse des exigences du système,
  conception de larchitecture du système, analyse
  des exigences du logiciel, conception de
  larchitecture du logiciel, conception détaillée
  du logiciel, codage et essai du logiciel,
  intégration du logiciel, essais de qualification
  du logiciel, intégration du système, essais de
  qualification du système, installation du
  logiciel, assistance à lacceptation du logiciel.

53
Les processus de base (2/2)

• Processus dexploitation
• Il définit les activités de léquipe
  dexploitation, cest-à-dire de lorganisme qui
  fournit les services relatifs à lexploitation
  dun système informatique dans son environnement
  réel, pour les utilisateurs mise en œuvre du
  processus, essais de fonctionnement, exploitation
  du système, assistance à lutilisateur.
• Processus de maintenance
• Il définit les activités de léquipe de
  maintenance, cest-à-dire de lorganisme qui
  fournit les services de gestion des modifications
  apportées au logiciel pour le maintenir en
  service et en état de fonctionner. Ce processus
  inclut la migration et le retrait du logiciel
  mise en œuvre du processus, analyse des problèmes
  et des modifications, mise en œuvre des
  modifications, revues et acceptation de la
  maintenance, migration du système, retrait du
  logiciel

54
Les processus de support (1/3)

• Processus de documentation
• Il définit les activités destinées à enregistrer
  les informations produites par un processus du
  cycle de vie du logiciel mise en œuvre du
  processus, conception et développement,
  production, maintenance.
• Processus de gestion de configuration
• Il définit les activités de gestion de
  configuration mise en œuvre du processus,
  identification de la configuration, maîtrise de
  la configuration, rapport de létat de la
  configuration, évaluation de la configuration,
  gestion de livraison et distribution.
• Processus dassurance qualité
• Il définit les activités permettant de garantir
  objectivement que les logiciels et les processus
  sont en conformité avec les exigences spécifiées
  et respectent les plans établis. Revues
  conjointes, audits, vérification et validation
  sont des techniques qui peuvent être utilisées
  pour lassurance de la qualité mise en œuvre du
  processus, assurance du produit, assurance du
  processus, assurance des systèmes qualité.

55
Les processus de support (2/3)

• Processus de contrôle
• Il définit les activités (pour lacquéreur ou le
  fournisseur par exemple) consistant à vérifier le
  logiciel de façon plus ou moins approfondie selon
  le projet mise en œuvre du processus, contrôle.
• Processus de validation
• Il définit les activités (pour lacquéreur ou
  le fournisseur par exemple) permettant de valider
  les logiciels du projet mise en œuvre du
  processus, vérification.
• Processus de revue conjointe
• Il définit les activités permettant dévaluer
  létat des produits dune activité mise en
  œuvre du processus, revues de gestion de projet,
  revues techniques.

56
Les processus de support (3/3)

• Processus daudit
• Il définit les activités permettant de
  déterminer la conformité aux exigences, aux plans
  et au contrat mise en œuvre du processus,
  audit.
• Processus de résolution de problèmes
• Il définit le processus permettant danalyser et
  de supprimer les problèmes (y compris les
  non-conformités), quels que soient leur nature ou
  leur origine, qui ont été découverts pendant
  lexécution du développement, de lexploitation,
  de la maintenance ou de tout autre processus
  mise en œuvre du processus, résolution de
  problèmes.

57
Les processus organisationnels (1/2)

• Processus de management
• Il définit les activités de base du management,
  y compris la gestion de projet, pendant un
  processus du cycle de vie mise en œuvre du
  processus et définition du domaine,
  planification, exécution et maîtrise, revue et
  évaluation, clôture.
• Processus dinfrastructure
• Il définit les activités de base pour la mise en
  place de lenvironnement nécessaire à un
  processus mise en œuvre du processus, mise en
  place de linfrastructure, maintenance de
  linfrastructure.

58
Les processus organisationnels (2/2)

• Processus damélioration
• Il définit les activités de base à mettre en
  œuvre par un organisme pour mettre en place,
  évaluer, piloter, et améliorer les processus du
  cycle de vie mise en œuvre du processus et
  définition du domaine, planification, exécution
  et maîtrise, revue et évaluation, clôture.
• Processus de formation
• Il définit les activités nécessaires à la
  formation adéquate du personnel.

59
Sommaire

1. Préambule
2. Les acteurs
3. Les normes applicables
4. Définitions
5. Norme ISO 90002000
6. Norme ISO 9126
7. Norme ISO 12207
8. Les cycles de vie types
9. Les cycles de vie linéaires
10. Les cycles de vie en  V 
11. Les cycles de vie itératifs et incrémentaux
12. La mise en œuvre de ces cycles types dans la
    réalité du projet

60
Préambule

• Le cycle de vie du logiciel débute par la
  décision de réaliser le logiciel et se termine
  par la décision de ne plus le garder en
  exploitation.
• Il y a trois principaux modèles de cycle de vie
  (des plus anciens aux plus récents)
• Les cycles de vie linéaires,
• Les cycles de vie en  V ,
• Les cycles de vie itératifs et incrémentaux.

61
Sommaire

1. Préambule
2. Les acteurs
3. Les normes applicables
4. Définitions
5. Norme ISO 90002000
6. Norme ISO 9126
7. Norme ISO 12207
8. Les cycles de vie types
9. Les cycles de vie linéaires
10. Les cycles de vie en  V 
11. Les cycles de vie itératifs et incrémentaux
12. La mise en œuvre de ces cycles types dans la
    réalité du projet

62
Leffet tunnel
Un jour, peut-être ...
Le départ est connu

• Le modèle de développement en tunnel noffre
  aucune visibilité sur létat davancement du
  logiciel.

63
Le modèle en cascade (1/2)

• Le cycle de vie en cascade a été décrit par Royce
  dès 1970.
• Il présente le développement logiciel comme une
  suite de phases qui senchaînent dans un
  déroulement linéaire, depuis lanalyse des
  besoins jusquà la livraison du produit au
  client.
• Le développement en cascade est en général rythmé
  par la génération de documents qui servent de
  validation pour le passage dune phase à lautre
  ce sont les livrables ou produits finis
  documentaires.
• Chaque phase est donc achevée avant que ne débute
  la suivante.

64
Le modèle en cascade (2/2)
65
Le modèle en fontaine

• Il sagit dune visualisation plus élaborée du
  modèle en cascade, dans laquelle est représenté
  le retour sur une des phases antérieures (et pas
  seulement la phase directement en-dessous) en cas
  de non validation du livrable par exemple.

66
Les limites des cycles de vie linéaires

• Des difficultés surviennent sil est impossible
  dobtenir de lutilisateur un énoncé complet et
  cohérent de ses besoins.
• Lenvironnement du logiciel peut être tellement
  mouvant quil est difficile de construire le
  logiciel sur des spécifications figées.

67
Sommaire

1. Préambule
2. Les acteurs
3. Les normes applicables
4. Définitions
5. Norme ISO 90002000
6. Norme ISO 9126
7. Norme ISO 12207
8. Les cycles de vie types
9. Les cycles de vie linéaires
10. Les cycles de vie en  V 
11. Les cycles de vie itératifs et incrémentaux
12. La mise en œuvre de ces cycles types dans la
    réalité du projet

68
Le modèle en  V  (1/7)

•  V  signifie que le développement du logiciel
  et le développement des tests sont directement
  corrélés.
• Cette approche permet de vérifier la conformité à
  ce qui devrait être fait et non ce qui a été
  fait.
• Les tests fonctionnels sont donc spécifiés lors
  de lanalyse, les tests dintégration lors de la
  conception et les tests unitaires pendant la
  phase de codage.

69
Le modèle en  V  (2/7)
Scenarii de tests du système
Spécifications du système
Validation via les tests dacceptation
Scenarii de tests des sous-systèmes
Conception préliminaire (sous-systèmes)
Intégration des sous-systèmes et modules, tests
correspondants
Scenarii de tests des modules
Conception détaillée (modules)
Tests unitaires des modules
Codage des modules
70
Le modèle en  V  (3/7)
Spécification du système, par exemple via des
diagrammes de flots de données. Ce niveau de
spécifications permet de préparer la phase de
validation du système via des tests de
validation. En effet, tous les scenarii de tests
du système sont déjà décrits.
71
Le modèle en  V  (4/7)
Conception préliminaire avec les choix de
découpage en sous-systèmes et la description des
principales fonctions (modules) de ces
sous-systèmes. Ce niveau de conception permet de
préparer les tests dintégration des
sous-systèmes. En effet, tous les scenarii de
tests correspondants sont cohérents avec les
principes dutilisation de ressources entre
sous-systèmes .
72
Le modèle en  V  (5/7)
Conception préliminaire, sur la base des choix
amont de découpage en sous-systèmes, avec les
choix de découpage en modules et la description
des principaux traitements de ces modules. Ce
niveau de conception permet de préparer les tests
dintégration des modules. En effet, tous les
scenarii de tests correspondants sont cohérents
avec les principes dutilisation de ressources
entre modules .
73
Le modèle en  V  (6/7)
Conception détaillée, sur la base des choix amont
de découpage en modules, avec la description des
traitements desdits modules. Ce niveau de
conception permet de préparer les tests unitaires
de chaque module. En effet, tous les scenarii de
tests des modules sont cohérents avec les
algorithmes prédéfinis.
74
Le modèle en  V  (7/7)
Codage des modules
75
Le modèle en  W  (1/2)

• Ce modèle est une variante du modèle en  V .
• Le cycle de développement ne commence que quand
  les problèmes ou les besoins sont parfaitement
  connus (cf. module de communication selon la
  méthode Merise).
• Un cycle en  W  peut être couplé à un cycle en
   V , quand il est nécessaire de décomposer le
  système en sous-systèmes.

76
Le modèle en  W  (2/2)
Spécification des IHM du système
Validation ou tests dacceptation
Exigences brutes
Conception des sous-systèmes
Intégration et tests des sous-systèmes
Vérification des flux logiques
Conception des modules
Intégration et tests des modules
2ème cycle de Goldberg
Codage et tests unitaires
77
Les limites des cycles de vie en  V 

• Les cycles de vie sont trop longs.
• Les relations entre les clients et les
  fournisseurs ne sont pas suffisamment
  formalisées.
• Ils ne gèrent pas les risques.
• Lintégration est trop tardive dans le cycle de
  vie.
• La documentation est réalisée dabord et le
  logiciel après

78
Sommaire

1. Préambule
2. Les acteurs
3. Les normes applicables
4. Définitions
5. Norme ISO 90002000
6. Norme ISO 9126
7. Norme ISO 12207
8. Les cycles de vie types
9. Les cycles de vie linéaires
10. Les cycles de vie en  V 
11. Les cycles de vie itératifs et incrémentaux
12. La mise en œuvre de ces cycles types dans la
    réalité du projet

79
Le modèle incrémental (1/2)

• Il est adapté à un développement et à une mise en
  production par lots.
• Les phases sachèvent par une activité de
  contrôle ou de test.

80
Le modèle incrémental (2/2)
Incrément 1 (noyau)
Incrément 2
Incrément 3
81
Le modèle en spirale (1/3)

• Ce modèle complexe est dû à Boehm.
• Il apporte une vue évolutive au modèle en cascade
  au travers dune approche fondée sur lanalyse et
  la gestion des risques, puis la conception et la
  réalisation de prototypes évolutifs en fonction
  de lavancement du projet.
• Le développement présente quatre grandes phases
  qui se succèdent au fur et à mesure de la
  construction de la spirale,
• Au dernier tour de la spirale, le produit est
  totalement défini, les risques résolus et le
  produit développé.

82
Le modèle en spirale (2/3)
83
Le modèle en spirale (3/3)

• Premier cycle Analyse du risque ? Prototype 1 ?
  Simulations et/ou modélisations et/ou bancs
  d'essais ? Définition de la mission (par la MO) ?
  Planification de l'analyse (c'est-à-dire du cycle
  suivant, portant principalement sur un travail
  d'analyse)
• Second cycle Analyse du risque ? Prototype 2 ?
  Simulations et/ou modélisations et/ou bancs
  d'essais ? Définition (par la ME) et validation
  (par la MO) des besoins ? Définition du plan de
  développement (c'est-à-dire des deux cycles
  suivants, consacrés à la conception, au codage,
  aux tests et à la mise en oeuvre du logiciel)
• Troisième cycle Analyse du risque ? Prototype 3
  ? Simulations et/ou modélisations et/ou bancs
  d'essais ? Définition (par la ME), vérification
  (par la ME) et validation (par la MO) de la
  conception générale ? Réajustement, le cas
  échéant, du plan de développement (ne concerne
  que la conception détaillée, le codage, les tests
  et la mise en oeuvre du logiciel)
• Quatrième cycle Analyse du risque ? Prototype 4
  ? Simulations et/ou modélisations et/ou bancs
  d'essais ? Conception détaillée, codage, tests
  divers et mise en oeuvre du logiciel

84
Déclinaison dun cycle de vie en modèle itératif
85
Déclinaison dun cycle de vie en modèle
incrémental
Incréments parallélisés
Incréments séquentiels
86
Itératif ou incrémental ?
sous-système (plus la couleur est foncée et
plus les fonctionnalités sont complètes)
87
Les avantages des cycles de vieitératifs et
incrémentaux

• Ces processus sont basés sur lévolution de
  prototypes exécutables
• Lutilisateur est placé devant des situations
  dutilisation concrètes. Il est partenaire du
  projet.
• Lintégration est progressive et permet déviter
  leffet  big bang  à lapproche de la date de
  livraison.
• Les progrès se mesurent par des programmes
  démontrables et non par des documents ou
  estimations.
• Le découpage par incréments permet de réduire la
  complexité du système en la ventilant dans les
  incréments.

88
Sommaire

1. Préambule
2. Les acteurs
3. Les normes applicables
4. Définitions
5. Norme ISO 90002000
6. Norme ISO 9126
7. Norme ISO 12207
8. Les cycles de vie types
9. Les cycles de vie linéaires
10. Les cycles de vie en  V 
11. Les cycles de vie itératifs et incrémentaux
12. La mise en œuvre de ces cycles types dans la
    réalité du projet

89
Conclusion

• Il ny a pas de modèle idéal car tout dépend des
  circonstances.
• Le modèle en cascade ou en V est risqué pour les
  développements innovants car les spécifications
  et la conception risquent dêtre inadéquats et
  souvent remis en cause.
• Le modèle incrémental est risqué car il ne donne
  pas beaucoup de visibilité sur le processus
  complet.
• Le modèle en spirale est un canevas plus général
  qui inclut lévaluation des risques.
• Souvent, un même projet peut mêler différentes
  approches, comme le prototypage pour les
  sous-systèmes à haut risque et la cascade pour
  les sous systèmes bien connus et à faible risque.