Vous êtes sur la page 1sur 126

Ecole Nationale des Sciences de

l’Informatique

Cours « Génie
Logiciel 1 »

CHAPITRE 2: II2
PROCESSUS LOGICIELS

Année Universitaire: 2020/2021


CHAPITRE 2: Processus
Logiciels

Plan

1. Introduction
2. Définitions
3. Activités du cycle de vie

Cours « GL-ACOO » ENSI


4. Modèles de processus
§ Modèles classiques
§ Modèle orienté réutilisation
§ Modèles Agiles
§ Modèles orientés objet

2
CHAPITRE 2: Processus
SECTION 1
Logiciels

Introduction

¡ Réalisation d'un programme simple développé par une


personne :
§ Analyse du problème;

Cours « GL-ACOO » ENSI


§ Ecriture de l’algorithme;
§ Codage;
§ Mise au point.

¡ Programmes de taille importante et développés par


plusieurs personnes :
§ Un processus de développement plus élaboré et plus
rigoureux doit être mis en place

3
CHAPITRE 2: Processus
Logiciels

Définitions

¡ Processus: un ensemble d’activités coordonnées et


contrôlées dont le but est de créer un produit.

Cours « GL-ACOO » ENS


¡ Il décrit l’ordre et la manière d’enchaîner les étapes de
développement.

¡ Il répond à deux questions importantes: I

§ Les activités (étapes) (= quoi?)


§ L’enchainement des activités (= quand?)

4
CHAPITRE 2: Processus
Logiciels

Définitions

¡ Cycle de vie d’un logiciel : processus qui démarre par


la détection d’un besoin de développement d’un
logiciel et qui se termine par la mise hors service du
logiciel.

Cours « GL-ACOO » ENSI


¡ Cycle de développement logiciel: est la partie du cycle
de vie d’un logiciel consacrée au développement.
§ Début: Décision de développer un logiciel
§ Fin: Livraison du logiciel et son installation.

5
CHAPITRE 2: Processus
Logiciels

Définitions

¡ Il existe différents modèles de cycles de vie.

Cours « GL-ACOO » ENSI


¡ Il n’existe pas de cycle de vie idéal:
§ Diversité des besoins et des contraintes de qualité.
§ Différences de contexte et d’expertise aussi bien des
organisations que des personnes.

6
CHAPITRE 2: Processus
Logiciels

Activités du cycle de vie


Exploitation &
Avant-projet Développement Maintenance Retrait
de projet
Gestion

Initiation Planification, Pilotage & Suivi


du projet Gestion de qualité Évaluation

Analyse

Cours « GL-ACOO » ENSI


Conception
Activités techniques

Implémentation
Maintenance retrait
Étude Tests &
préalable Assistance
Installation
Documentation
Vérification et Validation (V&V)
Gestion des configurations

Cycle de développement du logiciel


Cycle de vie du logiciel
7
CHAPITRE 2: Processus Activités de
Logiciels développement

Etude Préalable

¡ L’objectif est de répondre essentiellement aux questions


suivantes:
§ Pourquoi a-t-on besoin du logiciel?
§ Y a-t-il de meilleures alternatives?
§ Y a-t-il un marché pour le logiciel?

Cours « GL-ACOO » ENSI


§ Quels moyens faut-il mettre en œuvre?
¡ Les tâches effectuées:
§ Dresser un état de l’existant et analyser ses forces et faiblesses;
§ Identifier les besoins de l’utilisateur
§ Formuler des solutions potentielles et étudier la faisabilité
¡ Document produit : cahier des charges du projet

Besoins Cahier des


Etude préalable
du client charges du
projet
8
CHAPITRE 2: Processus
Logiciels

Activités du cycle de vie

Exploitation &
Avant-projet Développement Maintenance Retrait
de projet
Gestion

Initiation Planification, Pilotage & Suivi


du projet Gestion de qualité Évaluation

Cours « GL-ACOO » ENSI


Analyse

Conception
Activités techniques

Implémentation
Maintenance retrait
Étude Tests
préalable &
Assistance
Installation
Documentation
Vérification et Validation (V&V)
Gestion des configurations

9
CHAPITRE 2: Processus Activités de
Logiciels développement

Analyse des besoins

¡ Objectif
§ Répondre à la question quoi? Ce que le logiciel devra
faire?

Cours « GL-ACOO » ENSI


¡ Entrée
§ Cahier des charges du projet
¡ Tâches
§ analyse des besoins de l’utilisateur
§ spécification du logiciel à réaliser
¡ Sortie
§ Cahier des charges du logiciel
§ Document d’analyse et de spécification (Spécifications
globales du système & Spécifications des sous systèmes)
10
CHAPITRE 2: Processus Activités de
Logiciels développement

Conception

¡ Objectif : répondre à la question comment?


¡ Ebauche de plusieurs variantes de solutions,
comparaison et choix de celle qui offre le meilleur

Cours « GL-ACOO » ENSI


rapport entre coûts et avantages.
¡ A la fin de cette étape, on doit disposer d’un
modèle de solution complet, cohérent, maintenable
et testable.
¡ Se compose de deux phases:
§ Conception globale ou architecturale
§ Conception détaillée

11
CHAPITRE 2: Processus Activités de
Logiciels développement

Conception globale

¡ Processus durant lequel on doit IMAGINER, PROPOSER une


architecture pour satisfaire les spécifications (objectifs et
contraintes)
¡ Décomposition en modules, et mise en évidence des

Cours « GL-ACOO » ENSI


frontières entre ces modules, structuration de l’ensemble
¡ Recherche de plusieurs solutions, comparaison et choix entre
les différentes alternatives de conception
¡ A la fin de cette étape on doit disposer d’un modèle :
§ COMPLET
§ COHERENT
§ MAINTENABLE
§ TESTABLE

12
CHAPITRE 2: Processus Activités de
Logiciels développement

Conception globale

¡ Entrée
§ Documents de spécification
¡ Tâches

Cours « GL-ACOO » ENSI


§ Trouver une solution pour réaliser le logiciel
§ Définir l ’architecture du logiciel :
§ les composants de l ’architecture
§ les interfaces entre les composants
¡ Sortie
§ Architecture du logiciel à réaliser
¡ Document produit
§ document de conception globale

13
CHAPITRE 2: Processus Activités de
Logiciels développement

Conception détaillée

¡ Étape qui achève la conception globale, sur le plan


A L G O R I T H M I Q U E et S T R U C T U R AT I O N de
D O N N E E S , jusqu’à un niveau s a tis f a is a n t pour

Cours « GL-ACOO » ENSI


permettre le CODAGE.
¡ Les principales activités sont :
§ Description précises des traitements, des données et des
interfaces de chaque module
§ Résolution des algorithmes

14
CHAPITRE 2: Processus Activités de
Logiciels développement

Conception détaillée

¡ Entrée
§ Document de conception globale
¡ Tâches
§ raffiner la décomposition jusqu’à aboutir à des composants

Cours « GL-ACOO » ENSI


élémentaires
§ détailler chaque composant élémentaire
¡ Sortie
§ description détaillée de chaque composant :
§ interface
§ algorithmes
¡ Documents produits
§ Document de conception détaillée

15
CHAPITRE 2: Processus Activités de
Logiciels développement

Implémentation

¡ Entrée
§ Document de conception détaillée
¡ Tâches

Cours « GL-ACOO » ENSI


§ Transformation des descriptions des composants en
code, écrit dans un langage de programmation
¡ Sortie
§ composants logiciels compilés

16
CHAPITRE 2: Processus Activités de
Logiciels développement

Tests

¡ Durant cette phase, les composants du logiciel sont


évalués et intégrés ainsi que le logiciel lui-même.
¡ Phase généralement subdivisée en trois phases:

Cours « GL-ACOO » ENSI


§ Tests unitaires
§ Tests individuels des composants
§ Tests d’intégration
§ Assemblage progressif des composants
§ Tests des composants assemblés
§ Tests du système
§ Test en vraie grandeur du système complet

17
CHAPITRE 2: Processus Activités de
Logiciels développement

Installation

¡ Entrée
§ logiciel assemblé
¡ Tâches
§ Installer le logiciel chez le client, dans son environnement

Cours « GL-ACOO » ENSI


d’exploitation
§ Effectuer les tests de réception en utilisant un dossier de
validation.
§ rendre le logiciel opérationnel sur le site du client
¡ Sortie
§ logiciel installé
§ fourniture des documents suivants :
§ manuel d’installation
§ manuel d’exploitation

18
CHAPITRE 2: Processus
Logiciels

Activités du cycle de vie

Exploitation &
Avant-projet Développement Maintenance Retrait
de projet
Gestion

Initiation Planification, Pilotage & Suivi


du projet Gestion de qualité Évaluation

Cours « GL-ACOO » ENSI


Analyse

Conception
Activités techniques

Implémentation
Maintenance retrait
Étude Tests &
préalable Assistance
Installation
Documentation
Vérification et Validation (V&V)
Gestion des configurations

19
CHAPITRE 2: Processus Activités de
Logiciels développement

Vérification et Validation

¡ V&V englobe tous les processus qui permettent de


s’assurer que le logiciel correspond bien à son cahier des
charges et que ce cahier des charges répond bien aux
besoins de l’utilisateur.

Cours « GL-ACOO » ENSI


20
CHAPITRE 2: Processus Activités de
Logiciels développement

Vérification et Validation

¡ Vérification: le fait d’établir la cohérence: « Est ce que


nous construisons bien le produit? »
§ Vérification de toutes les étapes de développement et

Cours « GL-ACOO » ENSI


les éléments fournis (code, rapports, manuels,
documentation, jeux de tests, etc.).

¡ Validation: le fait d’établir l’utilité: « Est ce que nous


construisons le bon produit? »
§ Vérification du respect des spécifications du logiciel
et des besoins du client.
¡ Tester est l’activité de V&V la plus utilisée.

21
CHAPITRE 2: Processus Activités de
Logiciels développement

Documentation

¡ Enregistre tout ce qui pourrait être connu à propos d'un


système (ex: trace de toute prise de décision);

Cours « GL-ACOO » ENSI


¡ Support de communication entre les différents acteurs;

¡ Tâche consommatrice de ressources, à planifier.

¡ Quelques documents courants:


§ Cahier des charges, Calendrier du projet, Plan de test du logiciel,
Plan d'assurance qualité, Manuel utilisateur, Code source, etc.

22
CHAPITRE 2: Processus Activités de
Logiciels développement

Documentation et phases

Cours « GL-ACOO » ENSI


23
CHAPITRE 2: Processus Activités de
Logiciels développement

Gestion de la configuration

¡ La documentation du développement et le logiciel lui-même


sont constitués d’un grand nombre d’éléments qui évoluent
tout au long du cycle de vie (code, tests, documentation, etc.).
¡ Le but de la gestion de la configuration est de maîtriser cette

Cours « GL-ACOO » ENSI


évolution.
¡ Il v a u t m i e u x u t i l i s e r un o u t i l de ge s t i o n de la
configuration:
§ Identifier et archiver les éléments de la configuration;
§ Tracer et archiver les changements dans la configuration;
§ Identifier et archiver les versions de la configuration;
§ Gérer le travail concurrent à plusieurs développeurs sur les
éléments de la configuration.

24
CHAPITRE 2: Processus Activités de
Logiciels développement

Gestion de la configuration

¡ Un outil de gestion de la configuration permet de:


§ Identifier et archiver les éléments de la configuration;
§ Tracer et archiver les changements dans la

Cours « GL-ACOO » ENSI


configuration;
§ Identifier et archiver les versions de la configuration;
§ Gérer le travail concurrent à plusieurs développeurs sur
les éléments de la configuration.
¡ Exemples: CVS, SVN, Git

25
CHAPITRE 2: Processus Gestion de la
Logiciels conf iguration

Gestion de la configuration

Rôle d’un outil de gestion de la configuration

Cours « GL-ACOO » ENSI


26
CHAPITRE 2: Processus
Logiciels

Activités du cycle de vie

Exploitation &
Avant-projet Développement Maintenance Retrait
de projet
Gestion

Initiation Planification, Pilotage & Suivi


du projet Gestion de qualité Évaluation

Cours « GL-ACOO » ENSI


Analyse

Conception
Activités techniques

Implémentation
Maintenance retrait
Étude Tests &
préalable Assistance
Installation
Documentation
Vérification et Validation (V&V)
Gestion des configurations

27
CHAPITRE 2: Processus Activités de
Logiciels développement

M aintenance

¡ La maintenance du logiciel (ou maintenance logicielle)


désigne les modifications apportées à un logiciel, après
sa mise en œuvre, pour en corriger les fautes, en
améliorer l'efficacité ou autres caractéristiques, ou

Cours « GL-ACOO » ENSI


encore adapter celui-ci à un environnement modifié
(ISO/IEC 14764).

28
CHAPITRE 2: Processus Activités de
Logiciels développement

M aintenance

¡ Tâches:
§ Effectuer des d ép a n n a g es pour des c o r re c tio n s
mineures;

Cours « GL-ACOO » ENSI


§ Réappliquer le cycle de développement pour des
modifications plus importantes;
§ Distribuer les mises à jour;
§ Fournir l’assistance technique et un sup p ort d e
consultation;
§ Maintenir un journal des demandes d’assistance et de
support.

29
CHAPITRE 2: Processus Activités de
Logiciels développement

M aintenance

¡ Maintenance corrective : modification d'un logiciel afin


de corriger les défauts rencontrés.
¡ Maintenance adaptative : modification d'un logiciel

Cours « GL-ACOO » ENSI


pour qu'il reste utilisable dans un environnement qui
change ou a changé.
¡ Maintenance évolutive : mise à jour du logiciel à la suite
de modification des spécifications d’un point de vue
fonctionnel ou performance.
¡ Maintenance préventive : modification d'un logiciel pour
en déceler et corriger les défauts latents avant qu'ils ne se
manifestent.

30
CHAPITRE 2: Processus
Logiciels

Activités du cycle de vie

Exploitation &
Avant-projet Développement Maintenance Retrait
de projet
Gestion

Initiation Planification, Pilotage & Suivi


du projet Gestion de qualité Évaluation

Cours « GL-ACOO » ENSI


Analyse

Conception
Activités techniques

Implémentation
Maintenance retrait
Étude Tests &
préalable Assistance
Installation
Documentation
Vérification et Validation (V&V)
Gestion des configurations

31
CHAPITRE 2: Processus Activités de gestion
Logiciels de projet

Gestion du projet

¡ On appelle " gestion de projets " (éventuellement "


conduite de projets ") l'organisation méthodologique
mise en œuvre pour faire en sorte que l'ouvrage réalisé
par le maître d'œuvre réponde aux attentes du maître

Cours « GL-ACOO » ENSI


d'ouvrage et qu'il soit livré dans les conditions de coût et
de délai prévus initialement, indépendamment de sa "
fabrication ".

¡ La gestion de projets a pour objectifs d'assurer la


coordination des acteurs et des tâches dans un souci
d'efficacité et de rentabilité.

32
CHAPITRE 2: Processus Activités de gestion
Logiciels de projet

Avant le développement

¡ Initiation du projet: préparation de la gestion de


projet:
§ Représenter les activités à entreprendre dans un modèle

Cours « GL-ACOO » ENSI


§ Prévoir les ressources nécessaires au projet;
§ Identifier les procédures et les normes spécifiques au
projet et les mesures à mettre en place pour contrôler
leur application;
§ Planifier la gestion de projet.

33
CHAPITRE 2: Processus Activités de gestion
Logiciels de projet

Lors du développement

1. Affinement et modification de la planification du


projet
§ La planification du projet définit les tâches, le

Cours « GL-ACOO » ENSI


calendrier, les ressources, l’allocation de ces ressources
aux tâches et les procédures du projet.
2. Pilotage et suivi du projet
§ Enregistrer les faits sur l’avancement du projet et le
comparer à la planification;
§ Entreprendre, si nécessaire, des mesures correctives.

34
CHAPITRE 2: Processus Activités de gestion
Logiciels de projet

Lors du développement

3. Gestion de la qualité: l’ensemble des activités de


gestion déployées pour garantir que le processus de
développement engendre un produit de qualité.
§ Définir un programme pour mesurer la qualité;

Cours « GL-ACOO » ENSI


§ Planifier le programme de qualité;
§ Piloter et contrôler l’application du programme de
qualité;
§ Recommander des améliorations pour les programmes
de qualité futurs.
¡ La gestion de la qualité du logiciel et les activités de
vérification et de validation sont parfois regroupées
sous le nom « assurance de qualité du logiciel ».

35
Outil de gestion de projet MS Project

Cours « GL-ACOO » ENSI


36
Outil de gestion de projet Trello

C
o
u
r« s
G
L-
A

C
O
O
»
E
N
S
I

37
Outil de gestion de projet Jira

Cours « GL-ACOO » ENSI


38
CHAPITRE 2: Processus Modèles de
Logiciels processus

Aperçu

¡ Modèles c l a s s i q u e s
§ Modèles linéaires
§ modèle en cascade
§ modèle en V

Cours « GL-ACOO » ENSI


§ Modèles i t é r a t i f s
§ modèle de développement en s p i r a l e
§ modèle de développement in cré m e n t a l
§ modèle par p ro t o t y p a g e
¡ Modèles de la transformation f o r m e l l e
¡ Modèle orienté r é u t i l i s a t i o n
¡ Modèles agiles : SCRUM, RAD, XP, Kanban, ScrumBan …
¡ Modèles orientés o b j e t
§ Processus u n i f i é
§2TUP

39
CHAPITRE 2: Processus Modèles de
Logiciels processus

Aperçu

¡ Modèles c l a s s i q u e s
§ Modèles linéaires
§ modèle en cascade
§ modèle en V

Cours « GL-ACOO » ENSI


§ Modèles i t é r a t i f s
§ modèle de développement en s p i r a l e
§ modèle de développement in cré m e n t a l
§ modèle par p ro t o t y p a g e
¡ Modèles de la transformation f o r m e l l e
¡ Modèle orienté r é u t i l i s a t i o n
¡ Modèles agiles : SCRUM, RAD, XP, Kanban, ScrumBan …
¡ Modèles orientés o b j e t
§ Processus u n i f i é
§2TUP

39
CHAPITRE 2: Processus Modèles de
Logiciels processus

Modèle de la cascade

¡ Présente le développement logiciel comme une suite de


phases qui s’enchaînent dans un déroulement linéaire.
Analyse

Cours « GL-ACOO » ENSI


V&V Conception

V&V Codage

V&V Tests unitaires

[Royce70]
V&V Intégration et Tests

V&V Installation
40
CHAPITRE 2: Processus Modèles de
Logiciels processus

Modèle de la cascade

¡ Chaque étape doit être achevée avant que ne débute la


suivante.
¡ Chaque étape permet d’élaborer des produits intermédiaires.
¡ Chaque fin d’étape est matérialisée par un événement, où

Cours « GL-ACOO » ENSI


s’exerce une activité de contrôle (Vérification et Validation)
afin d’éliminer au plus tôt les anomalies des produits
réalisés.
¡ Le passage à l’étape suivante est conditionné par le résultat de
contrôle (acceptation, rejet, ajournement)
¡ Les retours en arrière sur les étapes précédentes se limitent à
un retour sur l’étape immédiatement antérieure.
¡ Adapté aux projets dont les besoins sont clairs dès le début
du projet.

41
CHAPITRE 2: Processus Modèles de
Logiciels processus

Modèle de la cascade: Bilan

¡ Avantage
§ Facile à comprendre
¡ Inconvénients

Cours « GL-ACOO » ENSI


§ Approche purement séquentielle et « simpliste »
§ Il est rare que le client puisse fournir toutes les
spécifications dès le début du projet.
§ Le client ne reçoit pas de résultats concrets pendant le
développement du logiciel (Problème de l’effet tunnel )

42
CHAPITRE 2: Processus Modèles de
Logiciels processus

Modèle en V

¡ Processus linéaire dérivé du modèle de la


cascade;
¡ Les premières étapes du cycle doivent préparer

Cours « GL-ACOO » ENSI


les d e r n i è re s é t a p e s , e s s e n t i e l l e m e n t les
activités de vérification et de validation.
¡L edéveloppementdulogicieletle
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.

43
CHAPITRE 2: Processus Modèles de
Logiciels processus

Modèle en V
Ecriture Installation et
Etude de test de
faisabilité Validation réception

V&V

Cours « GL-ACOO » ENSI


Spécification Tests système

Conception Tests
Globale D’intégration

Conception
Tests unitaires
Détaillée

Codage
44
CHAPITRE 2: Processus Modèles de
Logiciels processus

Modèle en V

¡ Deux sortes de dépendances entre étapes :


§ Traits continus : correspondent à l’enchaînement du modèle
de la cascade, les étapes se déroulent séquentiellement en
suivant le V de gauche à droite

Cours « GL-ACOO » ENSI


§ Traits non continus : Une partie des résultats de l’étape de
départ est utilisée directement par l’étape d’arrivée.
§ Par exemple : à l’issue de la conception globale, le
protocole d’intégration et les jeux de tests d’intégration
doivent être complètement décrits.

45
CHAPITRE 2: Processus Modèles de
Logiciels processus

Modèle en V: Bilan

Avantages
¡ Une meilleure spécification
§ évite d’énoncer une propriété qu’il est impossible de vérifier
objectivement une fois le logiciel réalisé.

Cours « GL-ACOO » ENSI


¡ Prévenir les erreurs
§ l’obligation de concevoir les jeux de tests et leurs résultats
oblige à une réflexion et à des retours sur la description en
cours.
¡ Une meilleure planification du projet:
§ Les étapes de la branche droite du V peuvent être mieux
préparés et planifiés.

46
CHAPITRE 2: Processus Modèles de
Logiciels processus

Modèle en V: Bilan

Inconvénients
¡ Le client ne reçoit pas de résultats concrets pendant

Cours « GL-ACOO » ENSI


le développement du logiciel
¡ Les validations intermédiaires n’empêchent pas la
t r a n sm issio n des i n s u ff i s a n c e s des étapes
précédentes.
¡ Adapté aux problèmes sans zones d’ombre
§Idéal quand les besoins sont bien connus et quand
l’analyse et la conception sont claires.

47
CHAPITRE 2: Processus Modèles de
Logiciels processus

Cycles de vie linéaires

Avantages
¡ Une meilleure solution si l’on maitrise le type de projet.
¡ Documentation abondante.
Inconvénients

Cours « GL-ACOO » ENSI


¡ Des difficultés surviennent s’il est impossible d’obtenir de
l’utilisateur un énoncé complet et cohérent de ses besoins.
§ Il est irréaliste de penser que l’on peut définir dès le départ, complètement et
dans le détail, ce que l’on veut réaliser et les résultats intermédiaires
attendus.
¡ Il n’y a pas de feedback avant la livraison au client.
¡ L’environnement du logiciel peut être tellement mouvant qu’il est
difficile de construire le logiciel sur des spécifications figées.
§ Ils ne reflètent pas la façon dont le code est développé.
¡ Manque de flexibilité pour gérer les imprévus.

48
CHAPITRE 2: Processus Modèles de
Logiciels processus

Modèle du prototypage

¡ Prototype = une version de tout ou d’une partie d’un


logiciel, facile à mettre en œuvre et à modifier.
¡ Il p e r m e t de v é r i f i e r r a p i d e m e n t c e r t a i n e s

Cours « GL-ACOO » ENSI


fonctionnalités en sacrifiant la précision des autres.
¡ Il n’est pas construit avec les mêmes contraintes de
qualité que le logiciel final.
¡ Prototypage = technique importante de validation des
besoins.

51
CHAPITRE 2: Processus Modèles de
Logiciels processus

Modèle du prototypage

¡ Technique souvent utilisé pour la validation des


spécifications MAIS Peut être aussi utilisé à différentes
étapes du cycle de vie.

Cours « GL-ACOO » ENSI


¡ Selon l’étape, les objectifs du prototype sont différents.
§ Pour montrer la faisabilité
§ Valider les interfaces utilisateurs
§ etc.

52
CHAPITRE 2: Processus Modèles de
Logiciels processus

Modèle du prototypage

Analyse
Analyse et sélection
préliminaire des nouvelles État non
des besoins fonctions satisfaisant

Cours « GL-ACOO » ENSI


Construction
du prototype
Évaluation
expérimentation
État satisfaisant
Expression claire
des besoins réels
• Initialement, les spécifications données
par le client sont d’ordre général ;
Spécifications
• Raffinement des spécifications, des fonctionnalités
définitives
et des performances par des prototypes successifs.
• Quand le client donne son accord, le développement suit souvent un
53
cycle de vie linéaire.
CHAPITRE 2: Processus Modèles de
Logiciels processus

Modèle du prototypage: Bilan

Avantages
¡ Pour le client: Une approche où domine l’écoute total
du client.
§ Le client reçoit des résultats tangibles rapidement ;

Cours « GL-ACOO » ENSI


§ Le client peut exprimer ses besoins plus facilement;
§ Le client peut changer d’avis sans conséquences
dramatiques.
¡ Pour l’utilisateur:
§ Expérimentation rapide par les utilisateurs et feedback
immédiat.
§ Former les utilisateurs avant la livraison du système
final.

54
CHAPITRE 2: Processus Modèles de
Logiciels processus

Modèle du prototypage: Bilan

Avantages
¡ Pour l’équipe de développement:
§ Meilleure clarification des spécifications

Cours « GL-ACOO » ENSI


§ Amélioration de la COMMUNICATION entre d’une part
le client et l’analyste, d’autre part l’analyste et le
concepteur
Inconvénients
¡ Impatience du client qui croit avoir un logiciel final.
¡ Problème relatif à la gestion de projet (planification,
estimation des coûts, etc.)

55
CHAPITRE 2: Processus Modèles de
Logiciels processus

Modèle incrémental

¡ A été proposé dans les années 80


¡ Propose un développement du logiciel par morceaux,
lesquels sont livrés successivement au client, en venant

Cours « GL-ACOO » ENSI


se greffer à un noyau logiciel.

62
CHAPITRE 2: Processus Modèles de
Logiciels processus

Modèle incrémental

Analyse des Conception


besoins architecturale

Cours « GL-ACOO » ENSI


Conception Codage d’un Validation de
détaillée d’un incrément l’incrément
incrément

Intégration

Validation du
système

Système final 63
CHAPITRE 2: Processus Modèles de
Logiciels processus

Modèle incrémental

¡ Un seul sous-ensemble des composants est développé à la fois


§ Un logiciel noyau est tout d’abord développé puis,
§ Des incréments sont successivement développés et intégrés
¡ Permet d’éviter de tout concevoir, de tout coder et de tout

Cours « GL-ACOO » ENSI


tester
¡ Les spécifications du logiciel sont figées et connues, l’étape de
conception globale est terminée.
¡ Certains modèles proposent de développer les différents
incréments en parallèle:

64
CHAPITRE 2: Processus Modèles de
Logiciels processus

Modèle incrémental: Bilan

Avantages
¡ Fournir des livraisons et des mises en service après chaque
intégration d’incrément ;
§ faire accepter progressivement un logiciel par les utilisateurs

Cours « GL-ACOO » ENSI


¡ Intégration allégée: les intégrations et leurs tests sont
progressifs ;
¡ Maintenance allégée (par incrément)
Inconvénients
¡ un risque majeur de ce modèle est de voir remettre en cause le
noyau ou les incréments précédents (définition globale des
incréments et de leurs interactions dès le début du projet).
¡ Complexité croissante de l’intégration de nouveaux
incrém ents;
¡ Pour chaque version à développer après la 1ère version livrée,
il faut arbitrer entre les demandes de correction et le
développement des nouvelles fonctionnalités.

65
CHAPITRE 2: Processus Modèles de
Logiciels processus

Modèles agiles

¡ Agilité = la capacité d’une organisation à créer de la


valeur et à ravir son client, tout en favorisant et en
s’adaptant -à temps- aux changements de son
environnement.

Cours «
¡ Une méthode agile est une approche itérative et incrémentale, G
L-
A
qui est menée dans un esprit collaboratif.
C
¡ Les méthodes agiles: O
O

§ se veulent plus pragmatiques que les méthodes »


E
N
classiques. S
I
§ impliquent au maximum le client et permettent une
grande réactivité à ses demandes.
§ visent la satisfaction réelle du client en priorité aux
termes d'un contrat de développement.

72
CHAPITRE 2: Processus Modèles de
Logiciels processus

Modèle agiles

Un peu d’historique
¡ Dans le début des années 1980, une méthode de développement
rapide d’application (le RAD) a été proposée. Elle a été reprise
en 1991 pour l’adapter au système français (RA D 2).
¡ En 1994, en Grande-Bretagne, DSDM, équivalente au RAD2, a

Cours « GL-ACOO » ENSI


été proposée
¡ Dans la seconde moitié des années 90, une dizaine de m éthodes
agiles ont vu le jour (exples: « Extreme programming » et
SC RU M )
¡ En 2001,17 grands noms du développement logiciel se sont
réunis aux USA et ont réussi à extraire de leurs concepts
respectifs des critères pour définir une nouvelle façon de
développer des logiciels.
¡ A l’issue de cette réunion est né le «Manifeste Agile» ( 4valeurs
fondamentales et 12 principes de fonctionnement).
http://agilemanifesto.org/iso/fr/

73
CHAPITRE 2: Processus Modèles de
Logiciels processus

Valeurs de l’agilité

Privilégier

Personnes et
Plutôt que Processus et outils
interactions

Cours « GL-ACOO » ENSI


Un produit Plutôt que
Documentation
opérationnel pléthorique

Collaboration Plutôt que


Négociation d'un
avec le client contrat

Adaptation au Plutôt que Suivi d'un plan


changement
74
CHAPITRE 2: Processus Modèles de
Logiciels processus

Valeurs de l’agilité

1.Priorité aux personnes et aux interactions par rapport aux procédures


et aux outils …

¡ Ce sont les individus, leur expertise, l’esprit d’équipe

Cours « GL-ACOO » ENSI


(plutôt que les processus et les outils) qui font la valeur
du travail accompli:
§ Les processus qui définissent ce que doit faire chaque
personne brident le potentiel caché derrière chacun.
§ Faire interagir les gens au maximum permet d'améliorer
grandement l'efficacité et la qualité du travail fourni.

75
CHAPITRE 2: Processus Modèles de
Logiciels processus

Valeurs de l’agilité

2. Priorité aux applications fonctionnelles opérationnelles par rapport


à une documentation pléthorique

¡ Dans les méthodes Agiles, un seul critère permet de

Cours « GL-ACOO » ENSI


mesurer l'avancement d'un projet : le logiciel qui
fonctionne. La documentation n'est qu'un support
concret qui aide à produire le logiciel.
¡ Les processus lourds génèrent une documentation
exhaustive avec tous ses inconvénients : ambiguïté du
langage, coût de la rédaction, coût du maintien en
accord avec la réalité, etc.

76
CHAPITRE 2: Processus Modèles de
Logiciels processus

Valeurs de l’agilité

3. Priorité à la collaboration avec le client par rapport à la négociation


de contrats

¡ Sortir de la guerre client/fournisseur et penser en

Cours « GL-ACOO » ENSI


équipe qui veut atteindre un but commun pour réussir
le projet.
¡ Le client devient un partenaire qui participe au projet
pour donner régulièrement son feedback.

77
CHAPITRE 2: Processus Modèles de
Logiciels processus

Valeurs de l’agilité

4. Priorité à l’acceptation et la réactivité au changement par rapport au


suivi d’un plan.

¡ Le planning est flexible pour accepter les modifications

Cours « GL-ACOO » ENSI


nécessaires.
§ Lorsqu’un plan est défini, l’équipe essaie de s’y tenir et
ne fait pas attention à des évènements extérieurs qui
peuvent arriver à tout moment du projet.
§ Le planning strict est à l'origine des conflits client/
fournisseur classiques sur les délais de livraison.
§ Pour le client, pouvoir adapter les besoins en cours de
projet est un atout concurrentiel.

78
CHAPITRE 2: Processus Modèles de
Logiciels processus

Principes fondateurs
Principes Traductions
Toute la création de valeur doit être justifié par la vue client. La seule vraie
Notre première priorité est de justification de valeur possible est démontrable uniquement lorsque le client se rend
satisfaire le client en livrant tôt et compte de l'utilisation réelle des produits livrés. La valeur identifiée lors de la
régulièrement des logiciels utiles. livraison apporte naturellement au client la satisfaction requise par le projet. Le cercle

Cours « GL-ACOO » ENSI


vertueux livraison/satisfaction est en place et le projet peut continuer.

La notion de cahier des charges évolutifs est ici annoncé. Il permettra au client de
préciser au cours du projet ses idées pas toujours très claires au début du projet, dans
Le changement est accepté, même le but de créer la juste valeur attendue par les utilisateurs. Le changement du cahier
tardivement dans le des charges permet d'éviter la création de fonctionnalité à faible valeur ajoutée. Pour
développement. Les processus autant, les développeurs doivent accepter ce changement qui peut être déstabilisant
agiles exploitent le changement par certains aspects. A l'inverse le client doit accepter lui aussi que les développeurs
comme un avantage compétitif refassent une partie du produit pour plus de qualité, et donc de satisfaction client. Il
pour le client. faut donc : que le client gère en permanence ses priorités, que les développeurs
acceptent les modifications des exigences et du code, que le chef de projets adapte la
façon de travailler continuellement.
Livrer fréquemment une
La livraison régulière et fréquente permet de se rendre compte du produit du point
application fonctionnelle, toutes
technique (les développeurs) et fonctionnel (le client) et donc de se remettre en
les deux semaines à deux mois,
question. Des délais courts permettent également de réduire le risque d'erreurs sur ces
avec une tendance pour la
deux aspects.
période la plus courte.
79
LES CO N CEPTS DE L’AGILITÉ
LES PRIN CIPES FONDATEURS
Principes Traductions

La collaboration quotidienne permet d'augmenter la productivité en abandonnant la création


de documents intermédiaires qui n'ont pas de valeur pour le produit final. Il faut donc : être
Les gens du métier et les
souple dans les relations contractuelles, être proche physiquement, s’assurer de la
développeurs doivent collaborer
communauté et de la compréhension des objectifs, prendre des décisions collégiales, se
quotidiennement au projet. répartir les responsabilités, s’auto-gérer, mettre en commun le travail (le code appartient à tous
les développeurs).
C
o
u
r« s
Les membres de l'équipe (client et développeurs) doivent être motivé par leur métier, car G
L-
cette motivation pousse à l'excellence, et donc à l'augmentation de la productivité. Il s'agit A
d'un pré requis fort. Mais ce n'est pas suffisant : tout ce qui peut gêner les membres de
Bâtissez le projet autour de l'équipe dans l'atteinte de leur objectif doit être levé. Enfin les membres de l'équipe doivent C
O
personnes motivées. Donnez leur O
bénéficier d'une délégation forte de la part de leur hiérarchie organisationnelle et projet, pour
l'environnement et le soutien dont décider rapidement sur des points fonctionnels (le client) ou techniques (les développeurs). »
elles ont besoin, et croyez en leur Cela passe par la confiance de cette hiérarchie. Le facteur humain est la clé du succès. Les E N
capacité à faire le travail. individus sont professionnels : disciplinés, prompts à suivre les instructions. Les individus S
sont fort : communicants, curieux, en reproduction et adaptation. Les individus sont fiers : de I
leur travail, de leur contribution, de leur réussite.

La méthode la plus efficace de Donc augmenter l'efficacité consiste au mieux à aller discuter avec la personne, au pire à
transmettre l'information est une l'appeler au téléphone. Inutile d'essayer le mail, et encore moin la rédaction d'un document
conversation en face à face. word. 80
LES CO N CEPTS DE L’AGILITÉ
LES PRIN CIPES FONDATEURS

Principes Traductions

Un logiciel fonctionnel est la


Pour réaliser le reporting du projet, nul besoin de feuilles d'activité (timesheets). Le seul
meilleure unité de mesure de la
indicateur d'avancement du projet est le nombre des fonctionnalités réalisées et/ou utilisées.
progression du projet.

C
o
Les processus agiles promeuvent un u
rythme de développement Les heures supplémentaires sont fortement déconseillées. L'équipe n'est plus performante r« s
G
soutenable. Commanditaires, au bout de huit heure de travail, qu'elle aille se reposer et se changer les idées : demain lui
donnera son efficacité. Les pressions dues au deadline projet sont également limitées : si

A
L-
développeurs et utilisateurs C
O
devraient pouvoir maintenir le certaines fonctionnalités ne sont pas développés pour la deadline, elles le seront à la
suivante, ou elles ne le seront pas, selon le choix du client.

O
rythme indéfiniment. »
E

S
N
I

L'excellence technique est également un prérequis fort. Au besoin, les ressources devront
suivre des formations. Cette excellence permet à l'équipe de se focaliser sur la qualité (le
Une attention continue à l'excellence
travail bien fait) qui est indispensable pour la satisfaction du client. Aucun compromis de ce
technique et à la qualité de la
coté-ci n'est possible. Le développement agile requiert : un code propre, un code robuste
conception améliore l'agilité. (Testé). Il faut donc : refactoriser régulièrement le code, effectuer des revues croisées de
code, tester en permanence (Ce qui n’est pas testé n’existe pas).

81
LES CO N CEPTS DE L’AGILITÉ
LES PRIN CIPES FONDATEURS

Principes Traductions

La simplicité - l'art de maximiser la Inutile de développer des lignes de code pour faire plaisir à un développeur : elles coûteront
quantité de travail à ne pas faire - est en maintenance et c'est autant de raisons supplémentaires de défaut. Par ailleurs, plus un
essentielle. code est simple, plus il est lisible

C
o
u
r« s
G
Les meilleures architectures, L-
Nul besoin d'experts dans un projet agile. La meilleure solution ne viendra pas d'une seule A
spécifications et conceptions sont
personne, mais du collectif. Nul besoin non plus de dire comment les équipes doivent
issues d'équipes qui s'auto- C
s'organiser, elles trouveront elles-mêmes l'organisation qui leur convient le mieux.. O
organisent. O
»
E
N
S
I

La vie n'est pas un long fleuve tranquille ; il faut donc en permanence s'adapter aux
À intervalle régulier, l'équipe
situations nouvelles. Cette adaptation a pour objectif d'être plus efficace et de se concentrer
réfléchit aux moyens de devenir plus
sur son propre métier qui est notre première source de motivation. Il est nécessaire de se
efficace, puis accorde et ajuste son
comportement dans ce sens. questionner en permanence sur : l’utilité d’une exigence, l’utilité de telle partie de code, la
façon de travailler, via des réunions à intervalles réguliers et un recul personnel quotidien
82
CHAPITRE 2: Processus Modèles de
Logiciels processus

Modèle agiles

¡ Parmi ces modèles, on trouve :


§ SCRUM
§ ASD (Adaptative Software Development)

Cours « GL-ACOO » ENSI


§ Crystal
§ FDD (Feature Driven Development)
§ DSDM (Dynamic Systems Development Method)
§ AM (Agile Modeling)
§ XP (eXtreme Programming)
§ Kanban
§ Ces méthodes sont regroupées par l’Agile Alliance
www.AgileAlliance.org

83
LES M É T H O D E S «AGILE»
D IS P O N IB L E S

Cours « GL-ACOO » ENSI


84
CHAPITRE 2: Processus Modèles de
Logiciels processus

Modèle agiles

¡ Parmi ces modèles, on trouve :


§ SCRUM
§ ASD (Adaptative Software Development)

Cours « GL-ACOO » ENSI


§ Crystal
§ FDD (Feature Driven Development)
§ DSDM (Dynamic Systems Development Method)
§ AM (Agile Modeling)
§ XP (eXtreme Programming)
§ Kanban
§ Ces méthodes sont regroupées par l’Agile Alliance
www.AgileAlliance.org

85
CHAPITRE 2: Processus Modèles de
Logiciels processus

Un modèle agile: SCRUM

¡ SCRUM a été formalisé en 1995 par:


¡ Jeff Sutherland http://jeffsutherland.com/
¡ Ken Schwaber

Cours « GL-ACOO » ENSI


http://kenschwaber.wordpress.com/

8
6
CHAPITRE 2: Processus Modèles de
Logiciels processus

Un modèle agile: SCRUM

¡ Le coeur de Scrum est un sprint : un


bloc de temps d’un mois ou moins
durant lequel un incrément du

Cours « GL-ACOO » ENSI


produit est réalisé.

87
CHAPITRE 2: Processus Modèles de
Logiciels processus

Un modèle agile: SCRUM

¡ Il est défini par ses créateurs comme un


« Framework » (Cadre de travail permettant de
répondre à d e s problèmes c o m p l e x e s e t

Cours « GL-ACOO » ENSI


changeants tout en livrant de manière productive
et créative des produits de la plus grande valeur
possible)
¡ Scrum est:
● Léger (Lightweight)
● Facile à comprendre (Simple to understand)
●Difficile à maîtriser (Extremely difficult to
master)
88
CHAPITRE 2: Processus Modèles de
Logiciels processus

Un modèle agile: SCRUM

Daily scrum meeting:


Mêlée quotidienne

Cours « GL-ACOO » ENSI


24 heures

2 – 4 semaines
Backlog
du sprint

Backlog Produit
du
produit
89
CHAPITRE 2: Processus Modèles de
Logiciels processus

SCRUM: Concepts

Cours « GL-ACOO » ENSI


90
CHAPITRE 2: Processus Modèles de
Logiciels processus

SCRUM: Les rôles

Cours « GL-ACOO » ENSI


91
CHAPITRE 2: Processus Modèles de
Logiciels processus

SCRUM: Les rôles

Le Scrum Master :

Cours « GL-ACOO » ENSI


92
CHAPITRE 2: Processus Modèles de
Logiciels processus

SCRUM: Les rôles

Le Product Owner:

Cours « GL-ACOO » ENSI


93
CHAPITRE 2: Processus Modèles de
Logiciels processus

SCRUM: Les rôles

L’équipe
• ne comporte pas de rôles prédéfinis pour ses

Cours « GL-ACOO » ENSI


membres
• Il n'y a pas non plus de notion de hiérarchie
interne :
§ toutes les décisions sont prises ensemble
§ personne ne donne d'ordre à l'équipe
sur sa façon de procéder.
• L'équipe s'adresse directement
au Product Owner
• La composition de l’équipe doit rester stable
durant le sprint (au minimum).
94
CHAPITRE 2: Processus Modèles de
Logiciels processus

SCRUM: Les artefacts

Cours « GL-ACOO » ENSI


95
CHAPITRE 2: Processus Modèles de
Logiciels processus

SCRUM: Backlog du produit As a « type of user »


I want « some objectives » so
that « benefits value »
¡ Le backlog du produit est une liste de
user stories. Le product owner doit
les ordonner par priorité et estimer le
temps nécessaire pour chaque user C
story en affectant des story points. o
u
rs
¡ Story point: Unité de mesure G«

exprimant une estimation de l’effort

A
L-
C
demandé pour effectuer une tâche. O

¡ Exemple

O
»
E
§ Story point = 1 >>> quelques heures

S
N
I
§ Story point = 2 >>>1 jour
§ Etc.
¡ Dans un sprint ne pas mettre les
stories points > 5 -> diviser les user
stories

96
CHAPITRE 2: Processus Modèles de
Logiciels processus

SCRUM: Backlog du produit

¡ Syntaxe de construction des User Stories :


§ User Stories :
§ En tant que <Rôle> (As a <User ro le > )

Cours « GL-ACOO » ENSI


§ Je souhaite pouvoir <Fonctionnalité> (I want to <Functionality>)
§ Afin de <Bénéfice> (so that <value>)

En tant que <Rôle>

Je souhaite <Fonctionnalité>

Afin de <Bénéfice>
Facultatif

97
CHAPITRE 2: Processus Modèles de
Logiciels processus

SCRUM: Backlog du produit

Exemples de User Stories :


En tant qu’acheteur en ligne, je En tant que client, je souhaite
souhaite pouvoir ajouter des pouvoir consulter la liste des
items à mon panier supprimer factures émises.

Cours « GL-ACOO » ENSI


les items afin de pouvoir
n’acheter que ce dont je suis
vraiment certain.

En tant que client (du projet), En tant que client, je souhaite


je souhaite pouvoir consulter la pouvoir connaître le montant
liste de mes clients total des factures impayées.

98
CHAPITRE 2: Processus Modèles de
Logiciels processus

SCRUM: User Stories

¡ Exemple: Backlog d’un sprint

Cours « GL-ACOO » ENSI


99
CHAPITRE 2: Processus Modèles de
Logiciels processus

SCRUM: BurnDown Chart

¡ Exemple

Cours « GL-ACOO » ENSI


Evolution de la quantité de
travail restante par rapport au
temps sur une période donnée.

100
CHAPITRE 2: Processus Modèles de
Logiciels processus

SCRUM plus en détail

Cours « GL-ACOO » ENSI


101
CHAPITRE 2: Processus Modèles de
Logiciels processus

Les réunions SCRUM

n La planification de sprint consiste à déterminer le


travail à effectuer durant le sprint.

Cours « GL-ACOO » ENSI


n Elle est limitée à 8 heures pour un sprint d’un
mois.
n Elle s’agit de répondre aux questions suivantes:
n Qu’est-ce qui peut être terminé au cours de
ce sprint ?
n Comment sera effectué le travail choisi ?

102
CHAPITRE 2: Processus Modèles de
Logiciels processus

Les réunions SCRUM

Mêlée quotidienne
¡ Destinée à permettre à l’équipe de développement de
synchroniser ses activités et planifier les prochaines 24
heures.

Cours « GL-ACOO » ENSI


¡ Tous les jours, 15 minutes, même heure, même endroit.
¡ Chaque membre de l’équipe de développement décrit:
§ Ce qu’il a réalisé depuis la dernière réunion ;
§ Ce qu’il réalisera avant la prochaine réunion ;
§ Les difficultés qu’il rencontre.

103
CHAPITRE 2: Processus Modèles de
Logiciels processus

Les réunions SCRUM

Revue de sprint
¡ L'équipe Scrum (PO+SM+E) et les intervenants
échangent sur ce qui a été fait durant le sprint.

Cours « GL-ACOO » ENSI


¡ Inspecter l’incrément du produit et adapter le carnet de
produit si nécessaire.
¡ Pour un sprint d’un mois, cette rencontre est limitée à
un bloc de temps de quatre heures.
§ Sprints plus courts: allouer proportionnellement moins
de temps.

104
CHAPITRE 2: Processus Modèles de
Logiciels processus

Les réunions SCRUM

Rétrospective du sprint
¡ Inspecter la manière dont le dernier sprint s'est
déroulé en ce qui concerne les personnes, les

Cours « GL-ACOO » ENSI


relations, les processus et les outils ;
¡ Identifier et ordonner les éléments majeurs qui se
sont bien déroulés et les améliorations potentielles ;
¡ Créer un plan pour améliorer les processus de
travail de l'équipe Scrum (PO+SM+E).
¡ Pour un sprint d’un mois, cette rencontre est
limitée à un bloc de de trois heures.
CHAPITRE 2: Processus Modèles de
Logiciels processus

SCRUM

Remarque: Taille de l’équipe de développement


¡ Une équipe de développement de taille optimale est
assez petite pour demeurer agile et assez grande

Cours « GL-ACOO » ENSI


pour effectuer du travail significatif.
§ Moins de trois m e m b re s dans l ' é q u i p e de
développement diminue les interactions et entraîne
des gains de productivité moindres.
§Une équipe de développement trop petite risque
de rencontrer des contraintes de compétences.
CHAPITRE 2: Processus Modèles de
Logiciels processus

SCRUM

Remarque: Taille de l’équipe de développement


§ Plus de neuf membres exige trop de coordination.
Les grandes équipes de développement génèrent

Cours « GL-ACOO » ENSI


trop de complexité pour être gérées par un
processus empirique.
§ Processus empirique : basé sur l'expérience,
nécessite une bonne visibilité, des inspections
fréquentes et des adaptations aux plans.
CHAPITRE 2: Processus Modèles de
Logiciels processus

SCRUM: Bilan

Avantages
¡ Règles définies clairement
¡ Souplesse : répondre au changement, modifier le projet

Cours « GL-ACOO » ENSI


et les livrables à tout moment
¡ Contrôle quotidien : coût; planning; fonctionnalités; et
qualité.
¡ Partage de connaissances : améliorer la productivité
¡ Résultat conforme aux attentes
Inconvénients
¡ Grande disponibilité de tous les acteurs
CHAPITRE 2: Processus Modèles de
Logiciels processus

Modèle agiles

¡ Parmi ces modèles, on trouve :


§ SCRUM
§ ASD (Adaptative Software Development)

Cours « GL-ACOO » ENSI


§ Crystal
§ FDD (Feature Driven Development)
§ DSDM (Dynamic Systems Development Method)
§ AM (Agile Modeling)
§ XP (eXtreme Programming)
§Kanban
§ Ces méthodes sont regroupées par l’Agile Alliance
www.AgileAlliance.org

85
CHAPITRE 2: Processus Modèles de
Logiciels processus

KANBAN

q Mot signifiant
étiquette (ou petite
fiche)

Cours « GL-ACOO » ENSI


q Pratique basée sur
l’utilisation
d’étiquette (post-it)
pour matérialiser les
informations sur le
processus
CHAPITRE 2: Processus Modèles de
Logiciels processus

KANBAN-Historique

q C’est une méthode inventé à la fin des années 1950 dans les
entreprises TOYOTA.
q Une bonne organisation de la chaîne de production entre deux

Cours « GL-ACOO » ENSI


postes de travail
q Une simple fiche cartonnée fixée sur les bacs de pièces dans
une ligne d'assemblage ou une zone de stockage

q Les objectifs de Toyota :


q Limite la production du poste amont aux besoins exacts du
poste aval
q Le nombre de kanban en circulation doit être limité pour éviter
la constitution d'encours trop importants
CHAPITRE 2: Processus Modèles de
Logiciels processus

KANBAN-Principes

q Le problème à résoudre est un workflow


q La solution consiste à le visualiser
q Diviser le travail (comme dans Scrum…)

Cours « GL-ACOO » ENSI


q Décrire chaque élément sur une fiche et la mettre au mur
(tableau, board)
q Tracer des colonnes, donnez leur le nom des étapes du
workflow
q Placer les éléments du travail
q En tant que développeur
q Choisir ce qui est à faire en fonction de ses compétences ou
missions
q Faire ce qui est « en cours »
q Mettre à jour le tableau Kanban
CHAPITRE 2: Processus Modèles de
Logiciels processus

KANBAN-Principes

Au minimum
• TO DO

Cours « GL-ACOO » ENSI


• IN PROGRESS
• DONE
Au maximum
• TO DO
• CHOSEN
• DEVELOPMENT
• TESTS
• DELIVERY
• DONE
CHAPITRE 2: Processus Modèles de
Logiciels processus

KANBAN-Principes

Cours « GL-ACOO » ENSI


CHAPITRE 2: Processus Modèles de
Logiciels processus

KANBAN-Principes

Cours « GL-ACOO » ENSI


CHAPITRE 2: Processus Modèles de
Logiciels processus

KANBAN-Principes

q Est ce qu’on peut avoir 500 fichiers dans « In progress » ou


« to do » ?
q Limiter le TAF (Travail A Faire / WIP : Work in Progress)

Cours « GL-ACOO » ENSI


q Fixer des bornes au nombre d’éléments dans chaque étape
q Mesurer le temps de cycle (lead time)
q C’est le temps moyen pour traiter complètement un élément,
c’est à dire le faire passer par toutes les étapes du workflow
q Optimiser le processus en réduisant le temps de cycle et en le
rendant prévisible
q Planning Poker
q Fibonacci
CHAPITRE 2: Processus Modèles de
Logiciels processus

SCRUM vs KANBAN

q Scrum est plus normatif que Kanban.


q Scrum impose des rôles.
q Scrum impose des itérations de durée fixe.

Cours « GL-ACOO » ENSI


q Kanban limite le TAF à chaque étape du workflow, Scrum limite
le TAF à chaque itération.
q Les deux sont empiriques.
q Scrum autorise peu de changement dans une itération.
q Le tableau Scrum est réinitialisé à chaque début d'itération.
q Avec Kanban, le tableau est généralement persistant : vous n’avez
donc pas besoin de le réinitialiser et de démarrer avec autre chose.
q Scrum impose des équipes multidisciplinaires
q Les deux permettent de travailler sur plusieurs produits
simultanément
q ….
CHAPITRE 2: Processus Modèles de
Logiciels processus

Modèles orientées objet

¡ Le d é v e l o p p e m e n t o r i e n t é o b j e t c o n d u i t à des
architectures logicielles fondées sur les objets (plutôt
que sur les fonctions qu'il est censé réaliser)

Cours « GL-ACOO » ENSI


¡ Pour la m odélisation orientée objet, UML est le
standard.
¡ UML n’est pas une méthode mais un langage : définit des
diagrammes et des notations mais n’impose pas de
méthode.
¡ le PU ( P ro c e s s u s U nifié) a été proposé afin de
compléter UML avec une méthode
CHAPITRE 2: Processus Modèles de
Logiciels processus

Processus unifié: un modèle OO

¡ Méthode générique de développement de logiciels


¡ Générique = pouvant être adaptée à une large classe de
systèmes logiciels.

Cours « GL-ACOO » ENSI


¡ Il couvre l’ensemble des activités d’un projet logiciel à
t r a v e r s u n e p a n o p l i e de p r i n c i p e s g é n é r i q u e s ,
adaptables en fonction des spécificités des projets.
CHAPITRE 2: Processus Modèles de
Logiciels processus

PU: caractéristiques

1. PU utilise le langage UML;


2. PU est conduit par les cas d’utilisation;
3. PU est centré sur l’architecture;

Cours « GL-ACOO » ENSI


4. PU est itératif et incrémental.
5. PU gère les risques
CHAPITRE 2: Processus Modèles de
Logiciels processus

PU: caractéristiques

PU est conduit par les cas d’utilisation


¡ Le processus de développement est centré sur
l’utilisateur.
¡ Toutes les activités, de l’analyse des besoins jusqu’aux
tests sont guidés par les cas d’utilisation

Cours « GL-ACOO » ENSI


¡ A partir des cas d’utilisation, les développeurs créent une
série de modèles UML.
CHAPITRE 2: Processus Modèles de
Logiciels processus

PU: caractéristiques

PU est itératif et incrémental


¡ Découpe du projet en “mini-projet” : des ITÉRATIONS
qui donne lieu à des INCRÉMENTS.
¡ Les itérations désignent des étapes de l’enchaînement

Cours « GL-ACOO » ENSI


des activités tandis que les incréments correspondent à
des stades de développement du produit.
¡ Une itération reprend les livrables dans l’état où les a
laissé l’itération précédente et les enrichit
progressivement (incrémental).
PU est piloté par les risques
¡ Chaque itération comprend un certain nombre de cas
d’utilisation et doit traiter en priorité les risques
majeurs.
CHAPITRE 2: Processus Modèles de
Logiciels processus

PU: caractéristiques

PU est centré sur l’architecture


¡ Tous les intervenants au projet de développement, du
chef projet au programmeur doivent s’accorder sur la
vision commune du système à produire : l’architecture.

Cours « GL-ACOO » ENSI


¡ L’architecture regroupe les différentes vues du système
qui doit être construit.
¡ Elle doit prévoir la réalisation de tous les cas
d’utilisation.
¡ Marche à suivre:
1. Créer une ébauche grossière de l’architecture.
2. Travailler sur les cas d’utilisation représentant les fonctions
essentielles.
3. Adapter l’architecture pour qu’elle prenne en compte ces cas
d’utilisation.
4. Sélectionner d’autres cas d’utilisation et refaire de même.
CHAPITRE 2: Processus Modèles de
Logiciels processus

PU en bref

Inception Élaboration Construction Transition

Capture des besoins

Cours « GL-ACOO » ENSI


Analyse

Conception

Implémentation

Tests

Déploiement

Iter. Iter. Iter. Iter. Iter. Iter. Iter.


#1 #2 #n #n+1 #n+2 #m #m+1
CHAPITRE 2: Processus Modèles de
Logiciels processus

PU en bref

Flux (workflow) du processus Inception Élaboration Construction Transition

Capture des besoins

Analyse

Cours « GL-ACOO » ENSI


Conception

Implémentation
Tests
Déploiement
Flux de gestion
Gestion de
Configuration et des
Evolutions
Gestion de projet
Environnement Iter. Iter. Iter. Iter.
Iter. Iter. Iter. 116
#1 #2 #n #n+1 #n+2 #m #m+1
CHAPITRE 2: Processus Modèles de
Logiciels processus

PU: Phases & Activités

¡ Phase d’inception: Identification des principaux cas


d’utilisation.
¡ Phase d’élaboration: l’analyse et la conception de la
plupart des fonctionnalités du système sont abordés.

Cours « GL-ACOO » ENSI


¡ Phase de construction : au cours de laquelle la
conception et la réalisation du système sont achevés.
¡ Phase de transition : est dédiée au test des
fonctionnalités du système.
¡ A chaque phase, un ensemble d’activités est réalisé:
§ Capture des besoins
§ Analyse
§ Conception
§ Implémentation
§ Tests ...
CHAPITRE 2: Processus Modèles de
Logiciels processus

PU: phases

Phase d’inception: Identification des principaux cas


d’utilisation.
¡ Traduit une idée en vision de produit fini et présente
une étude de rentabilité pour ce produit.

Cours « GL-ACOO » ENSI


§ un modèle simplifié des cas d’utilisation regroupant les
principaux cas d’utilisation est réalisé.
§ Une architecture provisoire est réalisée: une ébauche
relevant les principaux sous-systèmes.
§ Planification en détail de la phase d’élaboration et
fourniture d’une estimation du projet dans son
ensemble.
§ Identification et hiérarchisation des risques majeurs .
CHAPITRE 2: Processus Modèles de
Logiciels processus

PU: phases

Phase d’élaboration : l’analyse et la conception


de la plupart des fonctionnalités du système
sont abordés.

Cours « GL-ACOO » ENSI


¡ A l’issue de cette phase, le chef de projet doit
être en mesure de prévoir les activités et
d’estimer les ressources nécessaires à
l’achèvement du projet.
¡ Cette phase aboutit à l’émergence de la stabilité
des cas d’utilisation, d’une architecture de
référence, d’un plan de développement et la
maîtrise des risques pour permettre le respect
du contrat.
CHAPITRE 2: Processus Modèles de
Logiciels processus

PU: phases

Phase de construction : au cours de laquelle la


conception et la réalisation du système sont achevés.
¡ Moment où l’on construit le produit.
¡ Au cours de cette phase, l’architecture de référence se

Cours « GL-ACOO » ENSI


métamorphose en produit complet, elle est maintenant
stable.
¡ L’architecture peut encore avoir des anomalies qui
peuvent être en partie résolue lors de la phase de
transition.

Phase de transition : est dédiée au test des


fonctionnalités du système.
¡ La correction et l’amélioration du système sont aussi
abordées.
CHAPITRE 2: Processus Modèles de
Logiciels processus

PU: Bilan

Avantages
§ standard
§ aide à gérer la complexité

Cours « GL-ACOO » ENSI


§ permet de diminuer les risques
§ meilleure évaluation de l'évolution du
produit
Inconvénients
§ peut s’avérer lourd à mettre en place
§peu adapté au projet de petite envergure.
CHAPITRE 2: Processus Modèles de
Logiciels processus

Agile Vs UP

Points en commun Points différents

¡ Incrémental et itératif ¡ Comment appliquer le processus

Cours « GL-ACOO » ENSI


¡ Division du travail en incrémental
tâches ¡ UP est un Framework /Agile est un
¡ Test continu ensemble de principes (manifeste)
§ Se focaliser sur la ¡ Taille des projets
qualité ¡ Agile (petits et moyens projets
¡ Intégration continue à) / UP (grands projets)
§ Maîtriser les ¡ UP est plus lourd en documents et
changements en artéfacts
¡ Agile plus flexible aux changements

122
CHAPITRE 2: Processus Modèles de
Logiciels processus

Quelques Instances du PU

¡ RUP : Rational Unified Process, instanciation par Rational


des préceptes UP
¡ EUP : Enterprise Unified Process, instanciation intégrant les
phases de post-implantation.

Cours « GL-ACOO » ENSI


¡ XUP : Extreme Unified Process, instanciation hybride
intégrant UP avec Extreme Programming.
¡ AUP : Agile Unified Process, partie des préceptes UP
permettant l’agilité du développement.
¡ 2TUP : Two Tracks Unified Process, instanciation de UP
proposé par Valtech prenant en compte les aléas et
contraintes liées aux changements perpétuels et rapides des
SI des entreprises.
¡ EssUP : Essential Unified Process, instanciation de UP
proposé par Ivar Jacobson Consulting qui propose une
mouture du processus unifié qui intègre certains concepts
de l’agilité.
CHAPITRE 2: Processus Modèles de
Logiciels processus

Un modèle OO: 2TUP

¡ Pourquoi 2TUP?
§ Réponse aux contraintes de changement c o
ntinuel imposées aux systèmes

Cours « GL-ACOO » ENSI


d’information de l’entreprise.

Contraintes Contraintes
techniques fonctionnelles
CHAPITRE 2: Processus Modèles de
Logiciels processus

2TUP

Cours « GL-ACOO » ENSI


CHAPITRE 2: Processus Modèles de
Logiciels processus

2TUP et UML

• Diagramme des cas d’utilisation,


Capture des besoins • Diagrammes de séquence,
fonctionnels • Diagrammes de collaboration

Analyse • Diagramme de classes,

Cours « GL-ACOO » ENSI


• Diagrammes d’états transition

Capture des besoins


• Diagramme des cas d’utilisation
techniques
Conception
• Diagramme de déploiement
générique
Conception • Diagramme de composants,
préliminaire • Diagramme de déploiement

• Diagramme de classes, de séquence,


Conception détaillée • Diagramme de collaboration, d’états,
• Diagramme d’activités, de composants
CHAPITRE 2: Processus Modèles de
Logiciels processus

2TUP: Bilan

Avantages
¡ Itératif
¡ Cible des projets de toutes tailles

Cours « GL-ACOO » ENSI


¡ Donne une place importante à la
technologie et à la gestion des risques
Inconvénients
¡ Plutôt superficiel sur les phases situées en
aval du développement: support,
maintenance
CONCLUSION

l Quel est le meilleur cycle de vie?


l Y-a-t-il des critères de choix ?

Cours « GL-ACOO » ENSI


129
CONCLUSION

¡ Il n’y a pas de modèle idéal car tout dépend des


circonstances: type du projet, taille du projet,
taille de l’équipe,…
¡ 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

Cours « GL-ACOO » ENSI


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.
130
FIN CHAPITRE 2

131