Génie Logiciel
CYCLE DE VIE DU LOGICIEL( SUITE)
Vie du logiciel
(d'après J. Printz)
Cycle de vie du logiciel
 Aussi appelé procédé logiciel ou processus logiciel(software
process), le cycle de vie logiciel définit:
 Les étapes de développement
 L’enchaînement de ces dernières
 Un cycle de vie logiciel est un ensemble d’activités conduisant
à la production d’un logiciel.
 Les activités ne peuvent être automatisées, mais il y a des
outils de support, appelés outils CASE (Computer-Aided
Software Engineering)
Cycle de vie du logiciel
Pourquoi un modèle de procédé
logiciel
?
Cycle de vie du logiciel
 Pour maîtriser les gros projets
 Pour découper le projet et affecter correctement les tâches
 Pour anticiper et gérer les risques
 Il en existe deux:
Modèles de cycle de vie classiques VS
Modèles de cycle de vie agiles
Modèles classiques
 Modèles stricts
 Modèles clairement définis
 Documentation très fournie
 Fonctionne très bien avec les gros
projets, tels que les projets
gouvernementaux
Modèles agiles
 Modèles incrémentaux et itératifs
 Petites et fréquentes livraisons
 Accent sur le code et moins sur la
documentation
 Convient aux projets de petite et
moyenne tailles.
Critères de choix d’un modèle de
procédé logiciel
 Il n’y a pas de modèle meilleur que d’autres
 Le choix se fait selon certains suivant:
 la nature du projet,
 la taille du projet,
 la nature du client,
 les compétences de l’équipe,
 …
Différents modèles de Cycle de vie
 Modèle de cycle de vie en cascade
 Modèle de cycle de vie en V
 Modèle de cycle de vie en spirale
 Extreme Programming (XP)
Cycle de vie en cascade
Caractéristiques du modèle
en cascade
 mis au point dès 1966, puis formalisé aux alentours de
1970.
 Il définit des phases séquentielles à l'issue de chacune
desquelles des documents sont produits pour en vérifier
la conformité avant de passer à la suivante
 Importance du processus:
 rétroactions
 validation,
 vérification,
 tests
Cycle de vie en cascade
et assurance qualité
 Validation :
 Sommes-nous en train de faire le bon produit ?
 Vérification :
 Est-ce que nous faisons le produit correctement ?
☛ En pratique
 souvent confondus, ou pris l'un pour l'autre
 on parle de « V&V » (validation et vérification)
Cycle de vie en cascade
et assurance qualité
 Inspections
 lecture critique : spécification, conception, code, ...
(critique constructive : ne pas tout jeter)
 faite par équipes indépendantes
 rédaction de fiches de défaut
 affectation de responsabilités pour la correction des défauts
 Revues
 validation successive des phases du cycle de vie
Cycle de vie en cascade
et assurance qualité
Attention! (☹)
 Plus une erreur est découverte tard dans cycle de vie, plus la réparation
sera coûteuse
 Erreur de spécification trouvée en maintenance
☛ coûte + de 100 fois + cher que si trouvée lors des spécifications
Critique du modèle en cascade
 Modèle trop séquentiel
 dure trop longtemps
 Validation trop tardive et remise en question coûteuse des phases
précédentes
 Sensibilité à l'arrivée de nouvelles exigences
 Les besoins des clients sont très rarement stables et clairement définis
 Sensibilité aux nouveaux besoins : refaire tout le procédé
 Une phase ne peut démarrer que si l’étape précédente est finie
 Les risques se décalent vers la fin
 Très faible implication du client
Quand utiliser le modèle de cycle de
vie en cascade?
 Lorsque les besoins sont connus et stables
 Lorsque la technologie à utiliser est maîtrisée
 Lors de la création d’une nouvelle version d’un produit
existant
 Lors du portage d’un produit sur une autre plateforme
Modèle de cycle en vie en V
Modèle de cycle en vie en V
 Le modèle de cycle de vie en V part du principe que les
procédures de vérification de la conformité du logiciel aux
spécifications doivent être élaborées dès les phases de
conception
 Le modèle en V reste actuellement le cycle de vie le plus
connu et certainement le plus utilisé
 Le test du produit se fait en parallèle par rapport aux autres
activités
Caractéristiques du modèle en V
 Tâches effectuées en parallèle
 horizontalement : préparation de la vérification
 Ex. : dès que la spécification fonctionnelle est faite : (↑)
 plan de tests de qualification
 plan d'évaluation des performances
 documentation utilisateur
 verticalement : développement des modules
 Ex. : dès que la conception globale est validée : (↑)
 conception détaillée des modules
 programmation et tests unitaires
Avantages du modèle en V
 Validations intermédiaires
 Modèle encore assez populaire en industrie
 Limitations des risques en cascade par validation de
chaque étape
 Modèle très utilisé pour de grands projets
Inconvénients du modèle en V
 Plus complexe que le modèle en cascade
 On ne voit pas toujours de retour sur les phases
précédentes
 Plus difficile à mettre en œuvre
 Difficile de séparer les phases de conception et de
réalisation
 Ne contient pas d’activités d’analyse de risque (
projet, commercial, technique)
Quand utiliser le modèle en V?
 Lorsque le produit à développer à de très hautes
exigences de qualité
 Lorsque les besoins sont connus à l’avance
 Lorsque les technologies à utiliser sont connues à
l’avance
 Ce modèle demande beaucoup plus d’expertise que
le modèle en Cascade
Critique des modèles
en cascade et en V
 Modèles parfois difficiles à appliquer :
 difficile de prendre en compte des changements importants dans les
spécifications dans une phase avancée du projet
 durée parfois trop longue pour produits compétitifs
 Gestion du risque :
 trop de choses reportées à l'étape de programmation (par ex.
l'interface utilisateur)
 pas assez de résultats intermédiaires pour valider la version finale du
produit
Modèle de Cycle de vie en spirale
Modèle de Cycle de vie en spirale
 Principe :
 Identifier les risques, leur affecter une priorité
 Développer des prototypes pour réduire les risques
 Utiliser un modèle en V ou en cascade pour implémenter chaque cycle de
développement
 Contrôler :
 si un cycle concernant un risque est achevé avec succès,
 évaluer le résultat du cycle, planifier le cycle suivant
 si le risque est non résolu, interrompre le projet
Caractéristiques du modèle
de cycle de vie en spirale
(Boehm, 1988)
 Utilisation du prototypage
 Analyse (progressive) des risques
Analyse des risques
Risques technologiques :
 exigences démesurées par rapport à la technologie
 incompréhension des fondements de la technologie
 problèmes de performance
 dépendance en un produit soi-disant miracle
 changement de technologie en cours de route
 ...
Analyse des risques
Risques liés au processus :
 gestion projet mauvaise ou absente
 calendrier et budget irréalistes
 calendrier abandonné sous la pression des clients
 composants externes manquants
 tâches externes défaillantes
 insuffisance de données
 invalidité des besoins
 développement de fonctions inappropriées
 développement d'interfaces utilisateur inappropriées
 ...
Analyse des risques
Risques humains
 défaillance du personnel
 surestimation des compétences
 travailleur solitaire
 héroïsme
 manque de motivation
 ...
FIN
MERCI

3-Cours de Géniel Logiciel

  • 1.
    Génie Logiciel CYCLE DEVIE DU LOGICIEL( SUITE)
  • 2.
  • 3.
    Cycle de viedu logiciel  Aussi appelé procédé logiciel ou processus logiciel(software process), le cycle de vie logiciel définit:  Les étapes de développement  L’enchaînement de ces dernières  Un cycle de vie logiciel est un ensemble d’activités conduisant à la production d’un logiciel.  Les activités ne peuvent être automatisées, mais il y a des outils de support, appelés outils CASE (Computer-Aided Software Engineering)
  • 4.
    Cycle de viedu logiciel Pourquoi un modèle de procédé logiciel ?
  • 5.
    Cycle de viedu logiciel  Pour maîtriser les gros projets  Pour découper le projet et affecter correctement les tâches  Pour anticiper et gérer les risques  Il en existe deux:
  • 6.
    Modèles de cyclede vie classiques VS Modèles de cycle de vie agiles Modèles classiques  Modèles stricts  Modèles clairement définis  Documentation très fournie  Fonctionne très bien avec les gros projets, tels que les projets gouvernementaux Modèles agiles  Modèles incrémentaux et itératifs  Petites et fréquentes livraisons  Accent sur le code et moins sur la documentation  Convient aux projets de petite et moyenne tailles.
  • 7.
    Critères de choixd’un modèle de procédé logiciel  Il n’y a pas de modèle meilleur que d’autres  Le choix se fait selon certains suivant:  la nature du projet,  la taille du projet,  la nature du client,  les compétences de l’équipe,  …
  • 8.
    Différents modèles deCycle de vie  Modèle de cycle de vie en cascade  Modèle de cycle de vie en V  Modèle de cycle de vie en spirale  Extreme Programming (XP)
  • 9.
    Cycle de vieen cascade
  • 10.
    Caractéristiques du modèle encascade  mis au point dès 1966, puis formalisé aux alentours de 1970.  Il définit des phases séquentielles à l'issue de chacune desquelles des documents sont produits pour en vérifier la conformité avant de passer à la suivante  Importance du processus:  rétroactions  validation,  vérification,  tests
  • 11.
    Cycle de vieen cascade et assurance qualité  Validation :  Sommes-nous en train de faire le bon produit ?  Vérification :  Est-ce que nous faisons le produit correctement ? ☛ En pratique  souvent confondus, ou pris l'un pour l'autre  on parle de « V&V » (validation et vérification)
  • 12.
    Cycle de vieen cascade et assurance qualité  Inspections  lecture critique : spécification, conception, code, ... (critique constructive : ne pas tout jeter)  faite par équipes indépendantes  rédaction de fiches de défaut  affectation de responsabilités pour la correction des défauts  Revues  validation successive des phases du cycle de vie
  • 13.
    Cycle de vieen cascade et assurance qualité Attention! (☹)  Plus une erreur est découverte tard dans cycle de vie, plus la réparation sera coûteuse  Erreur de spécification trouvée en maintenance ☛ coûte + de 100 fois + cher que si trouvée lors des spécifications
  • 14.
    Critique du modèleen cascade  Modèle trop séquentiel  dure trop longtemps  Validation trop tardive et remise en question coûteuse des phases précédentes  Sensibilité à l'arrivée de nouvelles exigences  Les besoins des clients sont très rarement stables et clairement définis  Sensibilité aux nouveaux besoins : refaire tout le procédé  Une phase ne peut démarrer que si l’étape précédente est finie  Les risques se décalent vers la fin  Très faible implication du client
  • 15.
    Quand utiliser lemodèle de cycle de vie en cascade?  Lorsque les besoins sont connus et stables  Lorsque la technologie à utiliser est maîtrisée  Lors de la création d’une nouvelle version d’un produit existant  Lors du portage d’un produit sur une autre plateforme
  • 16.
    Modèle de cycleen vie en V
  • 17.
    Modèle de cycleen vie en V  Le modèle de cycle de vie en V part du principe que les procédures de vérification de la conformité du logiciel aux spécifications doivent être élaborées dès les phases de conception  Le modèle en V reste actuellement le cycle de vie le plus connu et certainement le plus utilisé  Le test du produit se fait en parallèle par rapport aux autres activités
  • 18.
    Caractéristiques du modèleen V  Tâches effectuées en parallèle  horizontalement : préparation de la vérification  Ex. : dès que la spécification fonctionnelle est faite : (↑)  plan de tests de qualification  plan d'évaluation des performances  documentation utilisateur  verticalement : développement des modules  Ex. : dès que la conception globale est validée : (↑)  conception détaillée des modules  programmation et tests unitaires
  • 19.
    Avantages du modèleen V  Validations intermédiaires  Modèle encore assez populaire en industrie  Limitations des risques en cascade par validation de chaque étape  Modèle très utilisé pour de grands projets
  • 20.
    Inconvénients du modèleen V  Plus complexe que le modèle en cascade  On ne voit pas toujours de retour sur les phases précédentes  Plus difficile à mettre en œuvre  Difficile de séparer les phases de conception et de réalisation  Ne contient pas d’activités d’analyse de risque ( projet, commercial, technique)
  • 21.
    Quand utiliser lemodèle en V?  Lorsque le produit à développer à de très hautes exigences de qualité  Lorsque les besoins sont connus à l’avance  Lorsque les technologies à utiliser sont connues à l’avance  Ce modèle demande beaucoup plus d’expertise que le modèle en Cascade
  • 22.
    Critique des modèles encascade et en V  Modèles parfois difficiles à appliquer :  difficile de prendre en compte des changements importants dans les spécifications dans une phase avancée du projet  durée parfois trop longue pour produits compétitifs  Gestion du risque :  trop de choses reportées à l'étape de programmation (par ex. l'interface utilisateur)  pas assez de résultats intermédiaires pour valider la version finale du produit
  • 23.
    Modèle de Cyclede vie en spirale
  • 24.
    Modèle de Cyclede vie en spirale  Principe :  Identifier les risques, leur affecter une priorité  Développer des prototypes pour réduire les risques  Utiliser un modèle en V ou en cascade pour implémenter chaque cycle de développement  Contrôler :  si un cycle concernant un risque est achevé avec succès,  évaluer le résultat du cycle, planifier le cycle suivant  si le risque est non résolu, interrompre le projet
  • 25.
    Caractéristiques du modèle decycle de vie en spirale (Boehm, 1988)  Utilisation du prototypage  Analyse (progressive) des risques
  • 26.
    Analyse des risques Risquestechnologiques :  exigences démesurées par rapport à la technologie  incompréhension des fondements de la technologie  problèmes de performance  dépendance en un produit soi-disant miracle  changement de technologie en cours de route  ...
  • 27.
    Analyse des risques Risquesliés au processus :  gestion projet mauvaise ou absente  calendrier et budget irréalistes  calendrier abandonné sous la pression des clients  composants externes manquants  tâches externes défaillantes  insuffisance de données  invalidité des besoins  développement de fonctions inappropriées  développement d'interfaces utilisateur inappropriées  ...
  • 28.
    Analyse des risques Risqueshumains  défaillance du personnel  surestimation des compétences  travailleur solitaire  héroïsme  manque de motivation  ...
  • 29.

Notes de l'éditeur

  • #3 Terminer l’étude de marcher
  • #7 Boehm propose 5 classes: Petits projets = 2 KDSI; Projets intermédiaires = 8 KDSI; Projets moyens = 32 KDSI; Grands projets = 128 KDSI; Très grands projets = 512 KDSI
  • #10 Modèle en cascade: élaboré par Royce en 1970
  • #11 Séquentiel: Suite ordonnée d’opérations ou d’éléments; organiser en séquences ;
  • #12 Validation/recette: vérifier que le logiciel est conforme aux spécifications théoriques définies au début du projet avant son déploiement final; vérification: respect des normes, des principes.
  • #13 Les deux outils qui permettent d’assurer la qualité du Logiciel
  • #15 Séquentiel: Suite ordonnée d’opérations ou d’éléments; organiser en séquences
  • #16 Portage=migration
  • #17 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.