Processus Logiciel

METHODES D’ANALYSE
&
CONCEPTION ORIENTEE OBJET
Processus logiciel
2020-2021
Objectifs du cours
2
 Introduire le génie logiciel

 Comprendre le cycle de vie de logiciel
 Maîtriser les processus classiques
 Maitriser les processus agiles
Nidal LAMGHARI
Plan
3
 1. Introduction
 2. Motivations
 3. Cycle de vie d’un logiciel
 4. Composantes du cycle de vie d’un logiciel
 5. Documents courants
 6. Modèles de cycles de vie
◼ Méthodes classiques
◼ Méthodes agiles
Nidal LAMGHARI
1.Introduction
4
 Logiciel: définition
 Le Logiciel se trouve quasiment « partout »
 Plusieurs choses de notre quotidien sont inconcevables
sans la notion du logiciel
 Bureautique, voyages aériens, scolarité, recherche
scientifique, loisirs,…
 On dépend très fortement de la qualité des logiciels
qui gèrent notre vie
Nidal LAMGHARI
1.Introduction
5
 Un logiciel un ensemble d’entités nécessaires au
fonctionnement d’un processus de traitement automatique
de l’information.
 Exemple d’entités:
◼ programmes (en format code source ou exécutables) ;
◼ documentations d’utilisation ;
◼ informations de configuration.
 Un logiciel est un « transformateur » d’information .

 Cette information peut être aussi simple qu’un bit de
données ou aussi complexe qu’une présentation multimédia
Nidal LAMGHARI
1.Introduction
6
 Un logiciel un sous-système d’un système englobant.
 Il peut interagir avec des clients, qui peuvent être :
◼ des opérateurs humains (utilisateurs, administrateurs, . . . ) ;
◼ d’autres logiciels ;
◼ des contrôleurs matériels.
 Il réalise une spécification : son comportement vérifie un

ensemble de critères qui régissent ses interactions avec
son environnement.
Nidal LAMGHARI
1.Introduction
7
 Le « software » et le « hardware » sont indissociables :
◼ Le « hardware » a besoin du « software » pour être piloté
◼ Le « software » a besoin du hardware pour être exécuté
 L’évolution phénoménale des capacités des logiciels est
intimement liée à l’évolution du hardware et aussi d’autres
facteurs
◼ Amélioration de la puissance du processeur
◼ Amélioration des capacités de stockages
◼ Changement des dispositifs d’entrée ou de sortie (Ecran tactile, stylo
optique, …etc.)
◼ Augmentation de la mobilité et des unités mobiles (Smartphones,
tablettes, notebooks,…etc.)
Nidal LAMGHARI
1.Introduction
8
 Développement logiciel: définition

 Un ensemble d’activités
 Plusieurs façons de développer un logiciel
 Un projet de développement est souvent long et

coûteux
◼ 50% des coûts sont des coûts de maintenance
 Un projet de développement fait intervenir
généralement plusieurs personnes de différentes
spécialités et compétences
Nidal LAMGHARI
1.Introduction
9
 Développement logiciel: définition

 Transformation d’une idée ou d’un besoin
 Production de l’idée par un client et son développement
par un spécialiste
 Le client et le spécialiste peuvent être les mêmes.
Nidal LAMGHARI
1.Introduction
10
 Développement logiciel: définition N’est pas uniquement

composée de
Chefs de projets, programmeurs
analystes, concepteurs, Équipe
testeurs.
communication Projet de Procédé

développement
Outils
Nidal LAMGHARI
1.Introduction
11
 Génie logiciel: Contexte

 Introduit à la fin des années soixante lors d’une
conférence sur la crise du logiciel «software crisis».
 Les coûts du matériel et les coûts du logiciel
 Il fallait de nouvelles techniques et méthodes pour
contrôler la complexité liée aux grands systèmes
logiciels
Nidal LAMGHARI
1.Introduction
12
 Génie logiciel: Crise du logiciel

 Logicielde qualité déficiente
 Performances médiocres
 Délais non respectés
 Non compatibilité avec le cahier des charges
 Coûts de développement excessifs
 Maintenance difficile et coûteuse
Émergence du génie logiciel
Nidal LAMGHARI
1.Introduction
13
 Génie logiciel: Crise du logiciel

 Le développement ne se réduit pas à la
programmation
 Nécessite d’adopter une méthode de développement
 Une méthode de développement a pour but de:

◼ faciliterla communication avec les utilisateurs,
◼ réduire la complexité
◼ guider la construction du logiciel
◼ documenter les différents choix de conception.
Nidal LAMGHARI
1.Introduction
14
 Génie logiciel: définition

 Le génie logiciel (software engineering) consiste à
identifier et à utiliser des méthodes, des pratiques et
des outils qui permettent de maximiser les chances de
réussite d'un projet logiciel.
 Une nouvelle science apparue dans les années 70.
 Présente une réponse aux défis relatifs à la

complexification des logiciels et de l'activité qui vise à
les produire.
Nidal LAMGHARI
1.Introduction
15
 Génie logiciel: définition Spécification
Maintenance Conception
Déploiement Implantation
Tâches du
génie logiciel
Validation
Intégration
Vérification Documentation
Nidal LAMGHARI
2.Motivations
16
 Qualités attendues d’un logiciel

 Principes du Génie logiciel
 Maturité du processus de développement logiciel
Nidal LAMGHARI
2.Motivations
17
 2.1Qualités attendues d’un logiciel

 Utilité
 Utilisabilité
 Fiabilité
 Interopérabilité
 Performance
 Portabilité
 Réutilisabilité
 Facilité de maintenance
Nidal LAMGHARI
2.Motivations
18

 Utilité
◼ Adéquation entre
◼ Le besoin effectif de l'utilisateur
◼ Les fonctions offertes par le logiciel
◼ Comment assurer cette qualité :
◼ Emphase sur l'analyse des besoins
◼ Améliorer la communication (langage commun, démarche
participative)
◼ Travailler avec rigueur
Nidal LAMGHARI
2.Motivations
19

 Utilisabilité
◼ Effectivité, efficacité et satisfaction avec laquelle des
utilisateurs spécifiés accomplissent des objectifs spécifiés dans
un environnement particulier
◼ Facilité d'apprentissage : comprendre ce que l'on peut faire avec
le logiciel, et savoir comment le faire
◼ Facilité d'utilisation : importance de l'effort nécessaire pour
utiliser le logiciel à des fins données
◼ Analyse du mode opératoire des utilisateurs
◼ Adapter l'ergonomie des logiciels aux utilisateurs
Nidal LAMGHARI
2.Motivations
20

 Fiabilité
◼ Correction, justesse, conformité aux spécifications:
◼ les résultats sont ceux attendus
◼ Robustesse, sureté :
◼ le logiciel fonctionne normalement en toutes circonstances,
◼ rien de catastrophique ne peut survenir, même en dehors des
conditions d'utilisation prévues
Nidal LAMGHARI
2.Motivations
21

 Fiabilité
◼ Mesures :
◼ MTBF : Mean Time Between Failures= temps moyen entre pannes
◼ Disponibilité (pourcentage du temps pendant lequel le système
est utilisable) et Taux d'erreur
◼ Utiliser des méthodes formelles, des langages et des méthodes
de programmation de haut niveau
◼ Vérifications, tests
Nidal LAMGHARI
2.Motivations
22

 Intéropérabilité
◼ Interactions couplabilité avec d'autres logiciels ;
◼ Un logiciel doit pouvoir interagir en alliance avec d'autres
logiciels
◼ Bases de données (découplage données/traitements)
◼ < Externaliser > certaines fonctions en utilisant des <Middleware
> avec une API (Application Program Interface) bien définie
◼ Standardisation des formats des fichiers (XML...) et des
protocoles de communication (CORBA...)
Nidal LAMGHARI
2.Motivations
23

 Performance
◼ Les logiciels doivent être performants et répondre aux contraintes
de temps d’exécution.
◼ Logiciels plus simples
◼ Veiller à la complexité des algorithmes
◼ Machines plus performantes
Nidal LAMGHARI
2.Motivations
24

 Portabilité
◼ Un même logiciel doit pouvoir fonctionner sur plusieurs
machines
◼ Comment assurer cette qualité:
◼ Rendre le logiciel indépendant de son environnement d'exécution
◼ Machines virtuelles
Nidal LAMGHARI
2.Motivations
25

 Réutilisabilité
◼ Dans la plupart des logiciels :
◼ 80% du code on le retrouve partout
◼ 20% du code est spécifique
◼ Abstraction, généricité
◼ Utiliser des composants prêts à l’emploi
◼ Design Patterns
Nidal LAMGHARI
2.Motivations
26

 Maintenance
◼ Un logiciel ne s'use pas
◼ Pourtant, la maintenance absorbe une très grosse partie des
efforts de développement
Nidal LAMGHARI
2.Motivations
27

 Maintenance corrective
◼ Correction des erreurs : (défauts d'utilité, d'utilisabilité, de
fiabilité...)
◼ Identifier la défaillance
◼ Localiser la partie du code responsable
◼ Corriger et estimer l'impact d'une modification
◼ Attention
◼ La plupart des corrections introduisent de nouvelles erreurs
◼ Les coûts de correction augmentent exponentiellement avec le délai
de détection
◼ La maintenance corrective donne lieu à de nouvelles livraisons
(release)
Nidal LAMGHARI
2.Motivations
28

 Maintenance adaptative
◼ Ajuster le logiciel pour qu'il continue à remplir son rôle
compte tenu de l'évolution des:
◼ Environnements d’exécution
◼ Fonctions à satisfaire
◼ Conditions d'utilisation
Nidal LAMGHARI
2.Motivations
29

 Maintenance évolutive
◼ Accroître/améliorer les possibilités du logiciel
◼ Ex : les services offerts, l'interface utilisateur, les
performances...
◼ Donne lieu à de nouvelles versions
Nidal LAMGHARI
2.Motivations
30

 Facilité de maintenance
◼ Objectifs
◼ Réduire la quantité de maintenance corrective (zéro défaut)
◼ Rendre moins coûteuses les autres maintenances
◼ Enjeux
◼ Les coûts de maintenance se jouent très tôt dans le processus d’élaboration
du logiciel
◼ Au fur et à mesure de la dégradation de la structure, la maintenance
devient de plus en plus difficile
◼ Réutilisabilité, modularité
◼ Vérifier, tester
◼ Structures de données complexes et algorithmes simples
◼ Anticiper les changements à venir
Nidal LAMGHARI
2.Motivations
31
 2.2 Principes du Génie Logiciel

 Généralisation : regrouper un ensemble de
fonctionnalités semblables en une fonctionnalité
paramétrable (généricité, héritage)
 Abstraction : permet de présenter un contexte en
exprimant les éléments pertinents et en omettant ceux
qui ne le sont pas
Nidal LAMGHARI
2.Motivations
32
 2.2 Principes du Génie Logiciel

 Modularité : décomposition d'un logiciel en composants
discrets
 Documentation : gestion des documents incluant leur
identification, acquisition, production, stockage et
distribution
 Vérification : détermination du respect des
spécifications établies sur la base des besoins identifiés
dans la phase précédente du cycle de vie
Nidal LAMGHARI
2.Motivations
33
 2.3 Maturité du Processus de développement

Logiciel
 CMM (Capabilitiy Maturity Model) standard de
mesurer l’ (les) amélioration (s) des PDL
 Modèle de maturité applicable à tout organisme
impliqué dans le développement de logiciel.
Nidal LAMGHARI
2.Motivations
34
 2.3 Maturité du Processus de développement Logiciel

 CMM décrit 5 niveaux de maturité des processus:
◼ Le niveau 1 est le niveau le plus bas (aucune amélioration n’a
encore commencé).
◼ Le niveau 5 est le plus élevé.
◼ Chaque niveau, supérieur au premier, porte son effort sur
l’amélioration de quelques thèmes majeurs.
 L’amélioration de la maturité d’un organisme se caractérise
par :
◼ la réduction des délais de développement ;
◼ la réduction des coûts ;
◼ l’utilisation plus efficace des ressources.
Nidal LAMGHARI
2.Motivations
35

Logiciel
 Les niveaux de maturité CMM
◼ Niveau 1:Initial
◼ Pas de méthode formelle, ni de cohérence, ni de standard, sur la
base desquels les systèmes seraient construits.
◼ Le processus de développement n'est pas maîtrisé
◼ Pas de volonté ferme de gérer le processus de développement.
◼ Le succès dépend essentiellement des efforts individuels et des
compétences des développeurs.
◼ Les exigences de qualité, les plannings et les budgets sont en
général, difficilement respectés
Nidal LAMGHARI
2.Motivations
36

Logiciel
◼ Niveau 2: Répétitif
◼ Consentement dans l'organisme sur la manière de gérer les
choses, sans que ça soit formalisé ou écrit.
◼ Mise en place d’un management de projet, fondé sur la réussite
des projets précédents.
◼ Le processus de développement est stabilisé, sous le contrôle
d'une gestion rigoureuse des coûts et des délais
Nidal LAMGHARI
2.Motivations
37

Logiciel
◼ Niveau 3: Défini
◼ Le processus de développement est formalisé, documenté et
appliqué.
◼ Les revues sont menées avec rigueur et les configurations sont
convenablement gérées.
◼ Une structure Qualité &Méthodes précise
◼ Mise à jour régulière des procédures de l'organisme
Nidal LAMGHARI
2.Motivations
38

Logiciel
◼ Niveau 4: Géré
◼ Processus formel de collecte d'informations métriques pour suivre
et gérer les systèmes résultants.
◼ Indicateurs contrôlant le bon déroulement des projets et le
respect des objectifs de qualité.
Nidal LAMGHARI
2.Motivations
39

Logiciel
◼ Niveau 5: Optimisé
◼ Exploitation des mesures pour optimiser en permanence le
processus de développement.
◼ L'organisme maîtrise un processus de correction des aspects qui
seraient jugés insuffisants, à la lecture des indicateurs.
Nidal LAMGHARI
3.Cycle de vie d’un logiciel
40
 La vie d’un logiciel est composée de cycles

 Le Cycle de vie du développement d’un logiciel
 Un ensemble d’étapes de la réalisation, de l’énoncé
des besoins à la maintenance au retrait du logiciel sur
le marché informatique.
 La période de temps s’étalant du début à la fin du
processus du logiciel.
 Il commence avec la proposition ou la décision de
développer un logiciel et se termine avec sa mise hors
service.
Nidal LAMGHARI
41
 Le Cycle de vie du développement d’un logiciel

 Procédé logiciel ou processus logiciel (software
process)
 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)
Nidal LAMGHARI
42
 La qualité du processus de fabrication garantit la

qualité du produit
 Pour obtenir un logiciel de qualité, il faut en
maîtriser le processus d’élaboration
 Il faut contrôler le cycle de vie
Nidal LAMGHARI
4.Composantes du cycle de vie
43
 Étude de faisabilité
 Spécification
 Organisation du projet
 Conception
 Implémentation
 Tests
 Maintenance
Nidal LAMGHARI
44
 Étude de faisabilité
 Déterminer si le développement proposé vaut la peine
d’être mis en œuvre, tenant compte des attentes et de
la difficulté de développement
 Etude de marché : existe-t-il un marché potentiel pour
le produit?
Nidal LAMGHARI
45
 Spécification
 Déterminer les fonctionnalités que doit posséder le
logiciel
◼ Collecte des exigences de l'utilisateur pour le logiciel
◼ Analyse du domaine : déterminer les tâches et les structures
qui se répètent dans le problème
Nidal LAMGHARI
46
 Organisation du projet
 Déterminer comment on va développer le logiciel
◼ Analyse des coûts : estimer le prix du projet
◼ Planification : établir un calendrier de développement
◼ Assurance qualité du logiciel : déterminer les actions qui
permettront de s'assurer de la qualité du produit fini
◼ Répartition des tâches : hiérarchiser les tâches et sous-tâches
nécessaires au développement du logiciel
Nidal LAMGHARI
47
 Conception
 Déterminer la façon dont le logiciel fournit les différentes
fonctionnalités recherchées.
 Conception générale:
◼ Conception architecturale : déterminer la structure du système
◼ Conception des interfaces : déterminer la façon dont les différentes
parties du système agissent entre elles
 Conception détaillée :
◼ Les algorithmes pour les différentes parties du système
 Implémentation (construction, réalisation, codage..):
 Écriture du logiciel
 Traduction de la conception détaillée dans un langage de
programmation
Nidal LAMGHARI
48
 Tests
 Essayer le logiciel sur des données d'exemple pour
s'assurer qu'il fonctionne correctement
◼ Tests unitaires : tester les parties du logiciel par leurs développeurs
◼ Tests d'intégration : tester pendant l'intégration
◼ Tests de validation : tester pour acceptation par l'acheteur
◼ Tests système : tester dans un environnement proche de l'environnement de
production
◼ Tests Alpha : faire tester par le client sur le site de développement
◼ Tests Bêta : faire tester par le client sur le site de production
◼ Tests de régression : enregistrer les résultats des tests et les comparer à ceux
des anciennes versions pour vérifier si la nouvelle version n’a pas dégradé
d'autres
Nidal LAMGHARI
49
 Livraison
 Fournir au client une solution logicielle qui fonctionne
correctement
◼ Installation : rendre le logiciel opérationnel sur le site du
client
◼ Formation : enseigner aux utilisateurs à se servir du logiciel
◼ Assistance : répondre aux questions des utilisateurs
Nidal LAMGHARI
50
 Maintenance
 Mettre à jour et améliorer le logiciel pour assurer sa
pérennité
 Pour limiter le temps et les coûts de maintenance, il
faut porter ses efforts sur les étapes antérieures
Nidal LAMGHARI
51
 Ces étapes ne se succèdent pas les unes aux autres

de façon linéaire.
 Il y a des retours sur les phases précédentes, en
particulier si les tests ne réussissent pas ou si les
besoins évoluent.
Nidal LAMGHARI
52
Nidal LAMGHARI
5. Documents courants
53
Documents Cycle de vie

Cahier de charge Faisabilité
Plan de test
Manuel d'utilisateur Spécification
préliminaire
Pan d’assurance qualité
Estimation des coûts Planification
Calendrier du projet
Conception Architecturale Conception
Conception détaillée
Documentation
Manuel utilisateur final Implémentation
Code source
Nidal LAMGHARI
Rapport des tests Test
54
 Cahier de charge:
 Décritinitialement les fonctionnalités désirées
 Généralement écrit par l'utilisateur
 Document contractuel entre le maître d'ouvrage est le

maître d'œuvre
 Version de base livrée lors de l’étude de faisabilité
Nidal LAMGHARI
55
 Dossier de spécification:
 Décrit précisément les conditions que doit remplir le
logiciel et non comment il est fait
 Scenarios des cas d'utilisation qui indiquent les
différents enchaînements possibles du point de vue de
l'utilisateur
 Plan de test
 Parfois le manuel d’utilisation préliminaire
Nidal LAMGHARI
56
 Dossier de spécification:
 Plan de test:
◼ Livré lors de la spécification
◼ Décrit l’étendue, l’approche, les ressources et le planning des
activités de test prévues.
◼ Identifie entre autres les éléments et caractéristiques à
tester,
◼ Précise les testeurs, leur degré d’indépendance
◼ Décrit l’environnement de test, les techniques de conception
des tests et les techniques de mesure des tests à utiliser, et
tout risque nécessitant des plans de contingence.
◼ Reprend les processus de planification des tests [IEEE 829].
Nidal LAMGHARI
57
 Dossier de planification:
 Plan d’assurance qualité:
◼ Décrit les activités mises en œuvre pour garantir la qualité
du logiciel
 Estimationdes coûts
 Calendrier du projet :
◼ Ordre des différentes tâches
◼ Détails et ressources qu'elles demandent
Nidal LAMGHARI
58
 Dossier de conception:
 Conception générale: description fonctionnelle complète du futur
système
◼ Décrire l’architecture de la solution, c’est-à-dire son organisation
en entités, les interfaces de ces entités et les interactions entre ces
entités
◼ Processus de structuration poursuivi jusqu’à ce que tous les éléments
du document de spécification soient pris en compte
◼ Document de conception générale
 Conception détaillée: description complète du futur système dans
l’environnement cible
◼ Affine la conception générale
◼ Décomposer les entités découvertes lors de la conception générale en
entités plus élémentaires
◼ Dossier de conception détaillée
Nidal LAMGHARI
59
 Dossier d’implémentation:
 Documentation
 Manuel utilisateur final

◼ Document structuré qui permet aux utilisateurs de retrouver
les informations recherchées.
◼ Intègre très souvent des captures d'écran
 Code source
Nidal LAMGHARI
60
 Dossier des tests:

 Rapport des tests
◼ Décrit les tests effectués et les réactions du système
 Rapport des défauts
◼ Décrit généralement les défaillances et erreurs du système
après test
Nidal LAMGHARI
6. Modèles de cycle de vie
61
 Pourquoi avons-nous besoin d’un modèle de cycle

de vie?
 Pour maîtriser les gros projets
 Pour découper le projet et affecter correctement les
tâches
 Pour anticiper et gérer les risques
 ∃ deux types de modèles:

 Classiques
 Agiles
Nidal LAMGHARI
62
 Modèles classiques
 Aspect séquentiel
 Relation « client/fournisseur » entre la maîtrise
d’ouvrage (MOA) et la maîtrise d’œuvre (MOE).
 Rigidité dans la conduite du projet.
 Chaque étape doit être validée avant de passer à la

suivante.
 Les retours en arrière sont très coûteux et quasiment
impossibles.
Nidal LAMGHARI
63
 Modèles classiques
 Effet « tunnel »:
◼ Le paramétrage peut durer plusieurs mois
◼ MOA ne peur vérifier son adéquation qu’à la fin du projet
◼ Entre le début et la fin du projet, on ne peut pas détecter si
les exigences fonctionnelles ont été mal comprises.
 Risque d’échec
◼ Généralement, le périmètre et les besoins fonctionnels ne
sont pas stables pendant toute la durée d’un projet SI.
Nidal LAMGHARI
64
 Modèles agiles
 Les personnes et les interactions plus que les processus
et les outils
 Les logiciels opérationnels, plus qu’une documentation
complète
 La collaboration avec le client
 L’adaptation au changement, davantage que le suivi

d’un plan
Nidal LAMGHARI
65
 Modèles agiles
 Développement itératif
 Privilégient les besoins des utilisateurs pouvant évoluer
en cours du projet.
 Consistent à diviser le projet en plusieurs mini projets
(itérations) définis avec les utilisateurs
 MOA et MOE deviennent des partenaires de travail
avec des objectifs communs.
Nidal LAMGHARI
66
 Modèles classiques vs agiles

Modèle Caractéristiques
Classique ✓Strict
✓Etapes très clairement définies
✓Documentation très fournie
✓Fonctionne bien avec les gros projets
Agile ✓Incrémental et itératif
✓Petites et fréquentes livraisons
✓Accent sur le code et moins sur la
documentation
✓Convient aux projets de petite et
moyenne taille
Nidal LAMGHARI
67
Nidal LAMGHARI
68

Modèles classiques Modèles agiles
Modèle cascade Modèle XP
Modèle en V Méthode Scrum
Modèle incrémental Adaptive Software Development (ASD)
Modèle en spirale Feature Driven Development (FDD)
Prototypage Rapid Application Development (RAD)
… Dynamic Software Development
Method (DSDM)
…..
Nidal LAMGHARI
69
 6.1 Méthodes classiques

 6.1.1 Modèle en cascade
◼ Mis au point dès 1966, puis formalisé aux alentours de
1970
◼ L’un des premiers modèles proposés, inspiré du modèle de
Royce (1970)
◼ Appelé aussi modèle linéaire
◼ Le résultat de chaque phase est un ensemble de livrables,
◼ Une phase ne peut démarrer que si la précédente est finie
◼ Un modèle académique par excellence
Nidal LAMGHARI
70

A l'issue de chacune des phases des
documents sont produits pour en vérifier la
conformité avant de passer à la suivante
Nidal LAMGHARI
71

 6.1.1Modèle en cascade
◼ Quand l’utiliser ?
◼ Quand les besoins sont connus et stables
◼ Quand 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
Nidal LAMGHARI
72

Avantages Inconvénients
➢Facile à utiliser et à comprendre ➢Sensibilité aux nouveaux besoins :
➢Un procédé structuré pour une refaire tout le procédé
équipe inexpérimentée ➢Une phase ne peut démarrer que si
➢Bien adapté pour des petits systèmes l’étape précédente est finie
➢Idéal pour la gestion et le suivi de ➢Mal adapté aux systèmes complexes
projets ➢Le produit n’est visible qu’à la fin
➢Approprié aux projets dont la ➢Les risques se décalent vers la fin
qualité est plus importante que les ➢Très faible implication du client…..
coûts et les délais
Nidal LAMGHARI
73

 6.1.2 Modèle en V
◼ Variante du modèle en cascade qui fait l’accent sur la
vérification et la validation
◼ Le test du produit se fait en parallèle par rapport aux
autres activités
◼ La première branche correspond à un modèle en cascade
◼ La seconde branche correspond à des tests effectifs
◼ Chaque étape est accompagnée d’un test
Nidal LAMGHARI
74

Toute description d’un composant est
complétée par des tests
Nidal LAMGHARI
75

◼ Quand le logiciel à développer a de très hautes exigences de
qualité
◼ Quand les besoins sont connus à l’avance
◼ Quand on connait les technologies à utiliser à l’avance
Nidal LAMGHARI
76

➢Met l’accent sur les tests et la ➢Ne gère pas les activités parallèles
validation ce qui accroît la qualité du ➢Ne gère pas explicitement les
logiciel changements des spécifications
➢Facile à planifier dans une gestion ➢Ne contient pas des activités
de projets d’analyse de risque
➢Facile à utiliser ➢Difficile de l’appliquer à des projets
➢Bien adapté au partage des tâches complexes ou trop techniques ou
entre clients et prestataires évolutifs
➢définit parfaitement les rôles du
partenariat
Nidal LAMGHARI
77

 6.1.3 Prototypage
◼ Le projet se fait sur plusieurs itérations
◼ Les développeurs construisent un prototype selon les attentes du
client
◼ Le prototype est évalué par le client
◼ Le client donne son feedback
◼ Les développeurs adaptent le prototype selon les besoins du client
◼ Quand le prototype satisfait le client, le code est normalisé selon
les standards et les bonnes pratiques
◼ Écriture d’une première spécification et réalisation d’un sous-
ensemble du produit logiciel final
◼ Le sous ensemble est ensuite raffiné d’une façon incrémentale et
évalué jusqu’à obtenir le produit final.
Nidal LAMGHARI
78

Nidal LAMGHARI
79

◼ Quand les besoins sont instables et/ou nécessitent des clarifications
◼ Quand des livraisons rapides sont exigées
◼ Peut être combiné avec le modèle en cascade pour clarifier les
besoins
Nidal LAMGHARI
80

➢Implication active du client ➢Le prototypage implique un code
➢Le développeur apprend faiblement structuré
directement du client ➢Degré très faible de maintenabilité
➢S’adapte rapidement aux ➢Le processus peut ne jamais s’arrêter
changements des besoins ➢Très difficile d’établir un planning
➢Progrès constant et visible
➢Une grande interaction avec le
produit
Nidal LAMGHARI
81

 6.1.4 Modèle incrémental
◼ Chaque incrément est une construction partielle du logiciel
◼ Trie les spécifications par priorités et les regroupent dans
des groupes de spécifications
◼ Chaque incrément implémente un ou plusieurs groupes
jusqu’à ce que la totalité du produit soit finie
Nidal LAMGHARI
82

Nidal LAMGHARI
83

Nidal LAMGHARI
84

◼ Quand la plupart des spécifications sont connues à l’avance et vont
être sujettes à de faibles évolutions
◼ Quand on veut rapidement un produit fonctionnel
◼ Quand on a des projets de longues durées
◼ Quand on a des projets impliquant de nouvelles technologies
Nidal LAMGHARI
85

➢Développement de fonctionnalités à ➢Exige une bonne planification et une
risque en premier bonne conception
➢Chaque incrément donne un produit ➢Exige une vision sur le produit fini
fonctionnel pour pouvoir le diviser en incréments
➢Le client intervient à la fin de chaque ➢Le coût total du système peut être
incrément cher
➢Le client entre en relation avec le
produit très tôt
Nidal LAMGHARI
86

 6.1.5 Modèle en spirale
◼ Modèle itératif
◼ Des incréments sous forme de cycle
◼ À la fin de chaque cycle on détermine les objectifs du cycle
suivant
◼ Chaque cycle est composé des même activités que du modèle en
cascade
◼ Inclut l’analyse de risque et le prototypage
◼ Un cycle de la spirale commence par l’expression d’objectifs tels
que la performance, la fonctionnalité…
◼ On identifie ensuite les différentes manières de parvenir à ces
objectifs ainsi que les contraintes.
◼ Puis on évalue chaque alternative en fonction de l’objectif
Nidal LAMGHARI
87

Nidal LAMGHARI
88

◼ Chaque spire confirme et affine les spires précédentes en
mettant des activités de même nature successivement.
◼ L’analyse ou la conception ne sont plus effectuées dans une
seule phase ou étape mais sont conduites en tant qu’activités
qui se déroulent sur de multiples phases.
◼ A chaque étape, après avoir défini les objectifs et les
alternatives, celles-ci sont évaluées par différentes
techniques (prototypage, simulation,..;)
◼ Le nombre de cycles est variable selon que le
développement est classique ou incrémental
Nidal LAMGHARI
89

◼ Quand on exige le prototypage
◼ Quand le risque du projet est considérable
◼ Quand les spécifications ne sont pas stables
◼ Quand le produit est nouveau
◼ Quand le projet implique de la recherche et de l’investigation
Nidal LAMGHARI
90

➢Identification rapide des risques ➢L’évaluation des risques peut prendre
➢Impacts minimaux des risques sur le beaucoup de temps
projet ➢L’évaluation des risques génère une
➢Fonctions critiques développées en augmentation des coûts
premier ➢Le modèle est très complexe
➢Feedback rapide du client ➢La spirale peut s’éterniser
➢Une évaluation continue du procédé ➢Les développeurs doivent être réaffectés
pendant les phases de non-
développement
➢Les objectifs ne sont pas souvent faciles à
formuler
Nidal LAMGHARI
91
 6.2 Méthodes agiles

 Concepts
◼ Agilité:
« L’agilité est la capacité d’une organisation à ravir ses Clients et ses
Employés, tout en s’adaptant -à temps- aux changements de son
environnement »
(Grosjean, 2016)
◼ Méthode agiles
« Une méthode agile est une approche itérative et incrémentale, qui
est menée dans un esprit collaboratif avec juste ce qu’il faut de
formalisme. Elle génère un produit de haute qualité tout en prenant
en compte l’évolution des besoins des clients»
Veronique Messager Rota
Nidal LAMGHARI
92

 Concepts
◼ Le Manifeste:
« Le Manifeste pour le développement agile de logiciels est un texte
rédigé aux États-Unis en 2001 par dix-sept experts du développement
logiciels. Ils estimaient que le taux important d'échecs des projets de
développements logiciels était dû à la lourdeur des méthodes
traditionnelles inspirées du génie civil et s'appuyant sur un cycle de
développement en cascade ou en V. Chacun d'entre eux avait déjà mis au
point et expérimenté de nouvelles méthodes plus légères. »
◼ Le site du manifeste:
http://agilemanifesto.org/iso/fr/manifesto.html
◼ Le manifeste agile: c’est 4 valeurs et 12 principes
Nidal LAMGHARI
93

 Les 4 valeurs:
Nidal LAMGHARI
94

 Les 4 valeurs:
Un bon collaborateur
Les collaborateurs n’est pas forcément un
sont la clé du bon programmeur. C’est
succès quelqu’un qui travaille
bien en équipe.
Une surabondance Construire l’équipe

d’outils est aussi c’est plus important
mauvaise que le que construire
manque d’outils l’environnement.
Nidal LAMGHARI
95

 Les 4 valeurs: Très difficile de décrire
la totalité du logiciel
depuis le début
Le client doit avoir un Les projets réussis

contact direct avec impliquent les clients
l’équipe de d’une manière
développement fréquente et régulière
Nidal LAMGHARI
96

 Les 4 valeurs:
Etre capable de Adapter les processus

s’adapter au moindre par rapport au besoin
changement
Adapter le scope selon

les feedbacks et les
besoins
Nidal LAMGHARI
97

 Les 4 valeurs:
Souvent les documents Produire toujours des

sont des « mensonges » documents aussi courts
formels que possible
Le code ne ment jamais
sur lui-même
Fournir le minimum de
documentation requis
en amont pour réaliser
les développements.
Nidal LAMGHARI
98

 Les 12 principes:
◼ Satisfaire le client
◼ Accepter le changement du besoin
◼ Produire des livraisons fréquentes
◼ Assurer un travail collaboratif entre les clients et les
développeurs
◼ Conduire le projet autour d’équipes motivées
◼ Faire circuler l’information à l’aide d’un contact direct entre
collaborateurs
Nidal LAMGHARI
99

 Les 12 principes:
◼ Un logiciel opérationnel est la principale mesure d’avancement
◼ Avoir la capacité de maintenir indéfiniment un rythme constant de
développement.
◼ Augmenter l’agilité grâce à une bonne conception et une
excellence technique
◼ Simplifier au maximum en minimisant la quantité de travail inutile
◼ Préconiser des équipes auto organisées (qui s’organisent d’elles
mêmes)
◼ Insister sur l’amélioration continue (autonome et régulière)
Nidal LAMGHARI
100

 L’eXtrême Programming (XP),
 Scrum,
 Feature Driven Development (FDD),
 Lean Software Development,
 Agile Unified Process (Agile UP ou AUP),
 Crystal
 Dynamic Systems Development Method (DSDM) .
Nidal LAMGHARI
101

 6.2.1 XP
◼ eXtreme Programming
◼ Créée en 1995 par Kent Beck and Ward Cunningham
◼ Moyen léger, efficace, à bas risques, flexible, scientifique et
amusant pour développer des logiciels
◼ Destinée à des équipes de moyenne taille avec des
spécifications incomplètes et/ou vagues
◼ Le codage est le noyau de XP
◼
Nidal LAMGHARI
102

 6.2.1 XP: Principes
◼ Le client pilote lui-même le projet grâce à des cycles itératifs très
courts (1 ou 2 semaines)
◼ Une première version du logiciel est livrée très tôt
◼ Un feedback maximal sur l’avancement est obtenu en assurant de
nouvelles versions (qui s’enchainent après la première)
◼ L'équipe s'organise elle-même pour atteindre ses objectifs, en
favorisant une collaboration maximale entre ses membres.
Nidal LAMGHARI
103

◼ On met en place des tests automatiques pour garantir un
produit robuste
◼ La structure interne du logiciel est améliorée pour assurer la
facilité et la rapidité des évolutions
Nidal LAMGHARI
104

 6.2.1 XP: Cycle de vie
Détermine les
scénarios « client »
qui seront fournis Le client exprime ses
pendant tte besoins sous forme de
itération user stories ≈ uses
cases + DS
Nidal LAMGHARI
105

 6.2.1 XP: Cycle de vie (exemple de user stories)
Nidal LAMGHARI
106

 6.2.1XP: Cycle de vie
Planning de la
première release: Durée du planning=1
que les ou 2 jours
fonctionnalités La première version= 2
essentielles à 6 mois
Nidal LAMGHARI
107

Itérations courtes pour
 6.2.1 XP: Cycle de vie identifier très tôt des
déviations par
rapport au planning
Itérations (de 1 Mettre toute l’équipe

Chaque itération
à 4 semaines) au courant de
produit un sous
jusqu’à la l’avancement du
ensemble de
première version projet grâce à des
fonctionnalités
principales réunions quotidiennes
Nidal LAMGHARI
108

Réglages affinés pour
 6.2.1 XP: Cycle de vie améliorer les
performances du
logiciel
Produit logiciel
qui offre toutes
les fonctionnalités
indispensables
Itérations très
courtes et des tests
constants en
parallèle du
développement
Nidal LAMGHARI
109
 3.3.2 Méthodes agiles

Le système ne
 3.3.2.1 XP: Cycle de vie supporte plus de
nouvelles
modifications
Plus de nouveaux
besoins Tous les besoins
possibles sont
remplis
Nidal LAMGHARI
110

◼ 1. Le client écrit ses besoins sous forme de scénarios.
◼ 2. Les développeurs évaluent le coût de chaque scénario, en
collaboration avec le client.
◼ 3. Le client choisit les scénarios à intégrer à la prochaine
livraison.
◼ 4. Chaque développeur prend la responsabilité d’une tâche
pour la réalisation d’un scénario.
Nidal LAMGHARI
111

◼ 5. Le développeur choisit un partenaire
◼ 6. Le binôme écrit les tests unitaires correspondant au scénario à
implémenter.
◼ 7. Le binôme prépare l’implémentation en réorganisant le code
existant, puis il procède à l’implémentation proprement dite.
◼ 8. Le binôme intègre ses développements à la version
d’intégration.
Nidal LAMGHARI
112

 6.2.1 XP: équipe & rôles
◼ Programmeur
◼ Client
◼ Testeur
◼ Tracker
◼ Manager
◼ Coach
Nidal LAMGHARI
113

◼ Programmeur
◼ Double responsabilité de conception technique et de codage.
◼ Construction de programme de façon à évoluer facilement par
modification ou ajout de spécifications.
Nidal LAMGHARI
114

 6.2.1XP: équipe & rôles
◼ Client
◼ Exprimer les exigences (user stories)
◼ Communiquer avec les développeurs
◼ Écrire des jeux de tests fonctionnels pour la recette.
◼ Pas nécessairement le client contractuel
◼ Assistant à la MOA
◼ Représentant des utilisateurs
◼ Personne qui peut agir comme client « artificiel »

◼ Chef de projet
◼ Ingénieur chargé des spécifications
Nidal LAMGHARI
115

◼ Testeur
◼ Aider le client à préparer les jeux de test (bras droit du client)
◼ Intervenir dans les choix de conception afin d’éviter des options
qui engendrent des difficultés de test
Nidal LAMGHARI
116

◼ Tracker
◼ Gestionnaire du temps
◼ Intervenir en début de chaque itération (lors de l’estimation)
◼ Contrôler la progression en communiquant avec les développeurs
◼ Détecter les problèmes assez tôt et alerter le manager ou le
coach
◼ Animer une brève réunion (standup meeting) chaque matin pour
faire le point avec les développeurs
Nidal LAMGHARI
117

◼ Coach
◼ Rôle de soutien technique des membres de l’équipe
◼ Garant du processus
◼ Recadrer certaines options de conception technique ou de
codage
Nidal LAMGHARI
118

◼ Manager
◼ Chef de projet
◼ Responsable des développeurs
◼ Rendre des comptes au client sur la base des informations reçues
du coach et du tracker.
Nidal LAMGHARI
119

 6.2.1 XP: Pratiques
Nidal LAMGHARI
120

◼ 1- jeu de planning
◼ L’estimation est la responsabilité du développeur (pas du chef de
projet ou du client)
◼ Le client et les développeurs trient les spécifications par priorité
◼ 2- petites et fréquentes livraisons
◼ L’objectif est livrer un petit système et de le faire évoluer en
livrant de nouvelles versions à des délais très courts.
Nidal LAMGHARI
121

◼ 3- Métaphores
◼ Exprimer de manière naturelle et très simples des fonctions du
système
◼ Le client et les développeurs doivent s’accorder sur les métaphores
◼ 4- Conception simple
◼ Concevoir de la manière la plus simple possible
◼ 5- tests
◼ Tests unitaires rédigés par les développeurs d’une manière continue
◼ Tests d’acceptation rédigés par le client
Nidal LAMGHARI
122

◼ 6- Refactoring
◼ Code amélioré quotidiennement par les développeurs
◼ Veiller à garder le système fonctionnel
◼ 7- Programmation en binômes
◼ Toujours deux développeurs devant une machine
◼ Pilote (conducteur ou driver) : Ecriture du code, manipulation des
outils...
◼ Co-Pilote (naviguateur) : Relecture continue du code, propositions...
◼ Dialogue permanent pour réaliser la tâche en cours
◼ 8- Propriété et responsabilité collective
◼ Code appartenant à toute l’équipe et à personne à la fois
◼ Tout le monde peut modifier l’application selon les besoins
Nidal LAMGHARI
123

◼ 9- Pas de surcharge de travail
◼ Ne pas dépasser 40 h de travail par semaine pour les
développeurs
◼ 10- Intégration continue
◼ A chaque fin de tâche le nouveau code doit intégré au système
◼ 11- Client sur site
◼ Intégrer le client à l’équipe pour définir précisément les besoins et
visualiser en direct les résultats.
◼ 12- Standards de code
◼ Disposer de normes et standards de nommage et programmation
pour faciliter la lecture et la compréhension du code
Nidal LAMGHARI
124

 6.2.1 XP: Avantages & inconvénients
Implication active du client Demande une certaine maturité des
développeurs
Forte réactivité des développeurs La programmation par paires n’est
toujours pas applicable
Responsabilisation et solidarité de Difficulté de planifier et de budgétiser
l’équipe un projet
Appel aux meilleurs pratiques de Stress dû aux devoir de l’intégration
développement continue et des livraisons fréquentes
Souplesse extrême La faible documentation peut nuire en
cas de départ des développeurs
Nidal LAMGHARI
125

 6.2.2 Scrum
◼ Inspirée par une approche développée en 1986 par H. Takeuchii
et II.. Nonaka, le terme « Scrum » utilisé dans « Wiicked Problems,
Rightteous Solutions » par DeGrace et Stahl en 1991.
◼ Utilisée comme méthodologie dans le livre : « Agile Software

Developmentt with SCRUM” par K. Schwaber et M.. Beedlle en
2001.
◼ Une des méthodes de gestion de projets agiles.
◼ Améliorer la productivité des équipes, tout en permettant

une optimisation du produit grâce à des feedbacks réguliers avec
les utilisateurs finaux.
Nidal LAMGHARI
126

 6.2.2 Scrum
◼ Tire son nom du monde du rugby (scrum = mêlée)
◼ Utilise les valeurs et l’esprit du rugby et les adapte aux
projets de développement
◼ Approche dynamique et participative de la conduite du
projet
Nidal LAMGHARI
127

 6.2.2 Scrum: Principes
Simple Empirique
•Peut être combinée avec d’autres méthodes •Itérations courtes (sprints)
•Compatible avec les best practices •Feedback continu
Techniques simples
•Sprints de 2 à 4 semaines
•Besoins capturés en tant que user stories
Optimisation
Equipes
•Détection rapide des anomalies
•Auto-organisation
•Organisation simple
•Multi-compétences
•Requiert l’ouverture et la visibilité
Nidal LAMGHARI
128
 6.2 Méthodes agiles •Transformer

•Garantir l’application
les besoinsdeen
•Faire le pont entre la partie
 6.2.1 Scrum: Principes fonctionnalités
l’approcheutilisables
métier et la partie technique
•Développeurs,
•Aider à comprendre
architectes
la
du projet
logiciel,
théorie,analystes,
les pratiques,
ingénieurs
les
•Rédiger les user stories
règles et système,
les valeurs etcde Scrum
Nidal LAMGHARI
129

 6.2.2 Scrum: Cycle de vie
Nidal LAMGHARI
130

 6.2.2 Scrum: Cycle de vie
Nidal LAMGHARI
131

 6.2.2 Scrum: Cycle de développement scrum
Nidal LAMGHARI
132

 6.2.2 Scrum: Concepts
◼ Sprint= un bloc de temps fixé qui aboutit à créer un
incrément du produit livrable
◼ Release = version
◼ Release = période de temps
Nidal LAMGHARI
133

 6.2.2 Scrum: Concepts
Nidal LAMGHARI
134

 6.2.2 Scrum: Outils (artefacts)
◼ User stories:
◼ explication non formelle d’une fonctionnalité du point de vue de
l’utilisateur final
◼ Product Backlog:
◼ Recueillir tous les besoins du client.
◼ Contient la liste des fonctionnalités auxquelles doit répondre le
produit
◼ Contient tous les éléments nécessitant l’intervention de l’équipe
projet.
◼ Plan de release, plan de sprint, burndown de release, burndown
de sprint..
Nidal LAMGHARI
135
 3.3.2 Méthodes agiles

 3.3.2.2 Scrum: Rôles
◼ Le Product Owner
◼ Le Scrum Master
◼ L’équipe de développement
Nidal LAMGHARI
136

 6.2.2 Scrum: Rôles/Product owner
Nidal LAMGHARI
137

 6.2.2 Scrum: Rôles/Scrum Master
Nidal LAMGHARI
138

 6.2.2 Scrum: Rôles/équipe de développement
◼ Chargée de transformer les besoins en fonctionnalités
utilisables
◼ L’équipe Scrum doit contenir 2 à 5 développeurs
◼ Répondre à tous les besoins techniques nécessaires pour
livrer le produit ou le service.
Nidal LAMGHARI
139

 6.2.2 Scrum: Cérémonies
◼ Planification du sprint
◼ Le daily stand-up ou la mêlée quotidienne
◼ Revue d'itération
◼ Rétrospective
Nidal LAMGHARI
140

◼ Planification du sprint
◼ Participants: équipe de développement, Scrum Master, responsable
produit
◼ Quand: au début du sprint
◼ Durée: une heure par semaine d’itération
◼ Objectif: l’équipe de développement sélectionne les éléments
prioritaires du Product Backlog. La réunion aboutit à la création d’un
plan de sprint
Nidal LAMGHARI
141

◼ Daily stand-up
◼ Participants: équipe de développement, Scrum Master,
responsable produit
◼ Quand: une fois par jour, généralement le matin
◼ Durée: pas plus de 15 min
◼ Objectif: Informer rapidement les participants de l’état
d’avancement et de ce qui se passe.
Nidal LAMGHARI
142

◼ Revue d’itération
◼ Participants: équipe de développement, Scrum Master, responsable
produit, parties prenantes du projets (facultatif)
◼ Quand: à la fin d’un sprint ou d’une étape importante
◼ Durée: entre 30 et 60 min
◼ Objectif: célébrer les réussites, présenter les tâches terminées et

obtenir un feedback immédiat de la part des parties prenantes.
Nidal LAMGHARI
143

◼ Rétrospective
◼ Participants : équipe de développement, Scrum Master, responsable
produit.
◼ Quand : à la fin d'une itération.
◼ Durée : 60 min.
◼ Objectif: permet aux membres d'une équipe d'échanger sur le vécu

du dernier sprint afin de pouvoir s'améliorer sur les suivants.
Nidal LAMGHARI
144

◼ Rétrospective
◼ Participants : équipe de développement, Scrum Master, responsable
produit.
◼ Quand : à la fin d'une itération.
◼ Durée : 60 min.
◼ Objectif: permet aux membres d'une équipe d'échanger sur le vécu

du dernier sprint afin de pouvoir s'améliorer sur les suivants.
Nidal LAMGHARI
Synthèse
145
 Un cycle de vie = stabilité, contrôle et organisation à

une activité
 Meilleure estimation des coûts et besoins
 Meilleure coordination
 Meilleure productivité
 Meilleure visibilité et compréhension
 Signe de maturité pour une entreprise
Nidal LAMGHARI
Synthèse
146
 Il n’existe pas de modèle idéal

 Cascade : risqué pour les projets innovants
 Evolutif : coûteux pour les projets clairs dès le début
 Pour les projets de taille petite ou moyenne

◼ Une approche agile est souvent plus appropriée
 Pour les grands projets (multi-sites, multi-équipes)
◼ Approche hybride intégrant des aspects des modèles
évolutifs et des modèles en cascade
◼ Exemple : utilisation d’un prototype pour stabiliser les
exigences et développement en V
Nidal LAMGHARI
Synthèse
147
 Les managers exigent les modèles de cycles de

vie
 Définir les activités et les livrables
 Marquer la réussite et l’achèvement d’une phase
 Rendus obligatoires par de nombreux clients
 Les ingénieurs ne les aiment pas trop

 Ne représentent pas ce qui se passe
 Ne règlent jamais complètement le problème des évolutions
 Les phases sont toujours mêlées

 En général c’est imbriqué et itératif
Nidal LAMGHARI

Processus Logiciel

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Processus Logiciel

Transféré par

Droits d'auteur :

Formats disponibles

METHODES D’ANALYSE

 Introduire le génie logiciel

 Un logiciel est un « transformateur » d’information .

 Il réalise une spécification : son comportement vérifie un

 Développement logiciel: définition

 Un projet de développement est souvent long et

 Développement logiciel: définition

 Développement logiciel: définition N’est pas uniquement

communication Projet de Procédé

 Génie logiciel: Contexte

 Génie logiciel: Crise du logiciel

 Délais non respectés

 Non compatibilité avec le cahier des charges

 Coûts de développement excessifs

 Maintenance difficile et coûteuse

Émergence du génie logiciel

 Génie logiciel: Crise du logiciel

 Une méthode de développement a pour but de:

 Génie logiciel: définition

 Présente une réponse aux défis relatifs à la

 Génie logiciel: définition Spécification

 Qualités attendues d’un logiciel

 2.1Qualités attendues d’un logiciel

 2.1Qualités attendues d’un logiciel

 2.1Qualités attendues d’un logiciel

 2.1Qualités attendues d’un logiciel

 2.1Qualités attendues d’un logiciel

 2.1Qualités attendues d’un logiciel

 2.1Qualités attendues d’un logiciel

 2.1Qualités attendues d’un logiciel

 2.1Qualités attendues d’un logiciel

 2.1Qualités attendues d’un logiciel

 2.1Qualités attendues d’un logiciel

 2.1Qualités attendues d’un logiciel

 2.1Qualités attendues d’un logiciel

 2.1Qualités attendues d’un logiciel

 2.2 Principes du Génie Logiciel

 2.2 Principes du Génie Logiciel

 2.3 Maturité du Processus de développement

 2.3 Maturité du Processus de développement Logiciel

 2.3 Maturité du Processus de développement

 2.3 Maturité du Processus de développement

 2.3 Maturité du Processus de développement

 2.3 Maturité du Processus de développement

 2.3 Maturité du Processus de développement

 La vie d’un logiciel est composée de cycles

 Le Cycle de vie du développement d’un logiciel

 La qualité du processus de fabrication garantit la

 Ces étapes ne se succèdent pas les unes aux autres

Documents Cycle de vie

 Document contractuel entre le maître d'ouvrage est le

 Parfois le manuel d’utilisation préliminaire

 Manuel utilisateur final

 Dossier des tests:

 Pourquoi avons-nous besoin d’un modèle de cycle

 ∃ deux types de modèles:

 Chaque étape doit être validée avant de passer à la

 L’adaptation au changement, davantage que le suivi

 Modèles classiques vs agiles

 Modèles classiques vs agiles

 Modèles classiques vs agiles

 6.1 Méthodes classiques

 6.1 Méthodes classiques