Le génie logiciel

Cycle de développement
Les processus de développement
standards
 Programming in the small
 Cycle en V
 Prototypage
 Itératif
 R(UP)
 Agile (SCRUM, XP, etc.)

2
Programming in the small

3
Cycle en V

4
Cycle en V (documents 1/3)
 MAÎTRISE DU PROJET
 PQ (PMP et clauses qualité)
 ANALYSE DES EXIGENCES
 Spécifications techniques (compléments à / ou
spécifications détaillées + modèles d’analyse)
 Documentation utilisateur (*)
 Description, procédures de tests de l’application (*)
 CONCEPTION
 Architecture de l’application (métier, fonctionnelle,
applicative, technique, logicielle)
 Conception détaillée
 Description et procédures de tests d’intégration

PMP : https://fr.wikipedia.org/wiki/Project_Management_Professional
(*) peut être reportée à une autre phase

5
Cycle en V (documents 2/3)
 IMPLEMENTATION / TESTS UNITAIRES
 Règles de conception et de développement
 Code et documentation de codage
 Rapport de tests unitaires
 INTEGRATION (ET TESTS)
 Rapport de tests d’intégration
 TEST DE L’APPLICATION
 Rapports de tests de l’application
 RECETTE / VALIDATION
 Dossier et rapport de tests de recette (VAF, VAT, VSR)
détaillée
 Description et procédures de tests d’intégration

6
Cycle en V (documents 3/3)
 LIVRAISON ET MAINTENANCE
 Bons de livraisons, documentation du contenu
des versions
 Rapports d’anomalies
 PRODUCTION / UTILISATION
 Manuel de mise en production
 Manuel d’exploitation
 Manuel de surveillance applicative
 Plan de continuité

7
Prototypage

Le prototypage est la démarche qui consiste à réaliser un prototype. Ce

prototype est un exemplaire incomplet et non définitif de ce que pourra être le
8
produit ou l'objet final.
Développement itératif

Le développement itératif implique de découper un projet en un certain nombre de

cycles, ou itérations, au cours desquelles on prévoit de répéter les mêmes activités.
9
Développement itératif en pratique

 Premières itérations : squelette architecture / problèmes /

risques / IHM /fonctionnalités importantes
 Chaque itération produit un livrable exécutable
 Chaque itération comporte l’intégration et les tests
10
Développement R(up)
•RUP est l’une des plus célèbres implémentations de la méthode
PU (Processus Unifié), livrée clés en main, permettant de
donner un cadre au développement logiciel, répondant aux
exigences fondamentales préconisées par les créateurs d’UML :
•une méthode de développement doit être guidée par les
besoins des utilisateurs
•elle doit être centrée sur l’architecture logicielle
•elle doit être itérative et incrémentale

•Exemple : UML

UML : Unified Modeling Language (UML), est un langage de modélisation graphique à base de
pictogrammes conçu pour fournir une méthode normalisée pour visualiser la conception d'un système. Il est
couramment utilisé en développement logiciel et en conception orientée objet.

11
Développement R(up)
 Méthode de développement logiciel
 itérative,
 Incrémentale
 pilotée par les cas d’utilisation.
 centrée sur l’architecture et la réduction des risques
 Produit de qualité
 Construction d’un système à base de composants
 Adaptable aux changements
 Livraison de qualité
 Concentrée sur le code exécutable
 Basé sur le travail en équipe

12
Schéma de synthèse R(up)

Présentation Rup Cours démarche 13

plus complète objet
Développement Agile (Scrum, Xp, etc.)
Le développement Agile implique au maximum le demandeur (client) et permet une grande réactivité à ses
demandes. Il vise la satisfaction réelle du client en priorité aux termes d'un contrat de développement.
Exemple : RAD

14
Développement Agile
 Les valeurs communes de la méthode:
 Les personnes et leurs interactions, plutôt
que les processus et les outils
 Un logiciel opérationnel, plutôt que des
documentations exhaustives
 La collaboration effective avec le Client,
plutôt que les négociations de contrats
 Répondre et accueillir les changements,
plutôt que suivre le plan projet.

15
Développement Agile
 les méthodes Agiles prônent donc les quatre valeurs suivantes :
 L’équipe (« Les personnes et leurs interactions, plutôt que les processus et les
outils ») :
 Dans l’optique agile, l’équipe est bien plus importante que les moyens matériels ou les
procédures. Il est préférable d’avoir une équipe soudée et qui communique composée de
développeurs moyens plutôt qu’une équipe composée d’individualistes, même brillants.
La communication est une notion fondamentale.
 L’application (« Un logiciel opérationnel, plutôt que des documentations
exhaustives ») :
 Il est vital que l’application fonctionne. Le reste, et notamment la documentation
technique, est secondaire, même si une documentation succincte et précise est utile
comme moyen de communication. La documentation représente une charge de travail
importante, mais peut pourtant être néfaste si elle n’est pas à jour. Il est préférable de
commenter abondamment le code lui-même, et surtout de transférer les compétences au
sein de l’équipe (on en revient à l’importance de la communication).
 La collaboration (« La collaboration effective avec le Client, plutôt que les
négociations de contrats ») :
 Le client doit être impliqué dans le développement. On ne peut se contenter de négocier
un contrat au début du projet, puis de négliger les demandes du client. Le client doit
collaborer avec l’équipe et fournir un feed-back continu sur l’adaptation du logiciel à ses
attentes.
 L’acceptation du changement (« Répondre et accueillir les changements,
plutôt que suivre le plan projet ») :
 La planification initiale et la structure du logiciel doivent être flexibles afin de permettre
l’évolution de la demande du client tout au long du projet. Les premières releases du
logiciel vont souvent provoquer des demandes d’évolutions.

16
Développement Agile
 Ces 4 valeurs se déclinent en 12 principes généraux communs à toutes les méthodes
agiles :
1. Notre première priorité est de satisfaire le client en livrant tôt et régulièrement des
logiciels utiles.
2. Le changement est bienvenu, même tardivement dans le développement. Les
processus agiles exploitent le changement comme avantage compétitif pour le
client.
3. Livrer fréquemment une application fonctionnelle, toutes les deux semaines à deux
mois, avec une tendance pour la période la plus courte.
4. Les gens de l’art et les développeurs doivent collaborer quotidiennement au projet.
5. Bâtissez le projet autour de personnes motivées. Donnez-leur l’environnement et
le soutien dont elles ont besoin, et croyez en leur capacité à faire le travail.
6. La méthode la plus efficace pour transmettre l’information est une conversation en
face à face.
7. Un logiciel fonctionnel est la meilleure unité de mesure de la progression du projet.
8. Les processus agiles promeuvent un rythme de développement soutenable.
Commanditaires, développeurs et utilisateurs devraient pouvoir maintenir le
rythme indéfiniment.
9. Une attention continue à l’excellence technique et à la qualité de la conception
améliore l’agilité.
10. La simplicité – l’art de maximiser la quantité de travail à ne pas faire – est
essentielle.
11. Les meilleures architectures, spécifications et conceptions sont issues d’équipes qui
s’auto-organisent.
12. À intervalle régulier, l’équipe réfléchit aux moyens de devenir plus efficace, puis17
accorde et ajuste son comportement dans ce sens.
Focus sur Scrum (Agile)
 Définitions
 Sprint : bloc de temps d’un mois ou moins durant lequel un incrément du produit « terminé »,
utilisable et potentiellement livrable est réalisé. Les sprints ont une durée constante durant
l’effort de développement. Un nouveau sprint démarre dès que le sprint précédent est terminé
 Mêlée quotidienne (nom usuel : scrum) : réunion limitée à un bloc de temps de 15
minutes et destinée à permettre à l’équipe de développement de synchroniser ses activités et
planifier les prochaines 24 heures. Pour ce faire, le travail réalisé depuis la dernière mêlée
quotidienne est inspecté et une prévision du travail qui pourra être réalisé avant la prochaine
mêlée est énoncée
 Revue de sprint : réunion tenue à la fin du sprint pour inspecter l’incrément du produit et
adapter le carnet de produit si nécessaire. Pendant la revue de sprint, l'équipe Scrum et les
parties prenantes échangent sur ce qui a été fait durant le sprint. Basé sur cette analyse, et en
considérant les changements au carnet de produit effectués durant le sprint, les participants
collaborent pour déterminer les prochains items qui pourraient être faits. Cette réunion se
veut informelle, la présentation de l'incrément est destinée à susciter des réactions et à
favoriser la collaboration.
 Carnet du produit (backlog produit) : liste ordonnée de tout ce qui est pourrait être requis
dans le produit, et source unique des besoins pour tous les changements à effectuer sur le
produit. Le propriétaire de produit est responsable de ce carnet, de son contenu, de sa
publication ainsi que de l’ordonnancement des items qu’il contient.
 Carnet de sprint (backlog de sprint) : ensemble des items choisis pour le sprint en plus
d’un plan pour les réaliser dans le cadre d’un incrément de produit qui concrétisera l’objectif
du sprint. Le carnet est une prévision de ce que l’équipe de développement croit être en
mesure de livrer dans le prochain incrément de produit ainsi que le détail du travail qui devra
être fait pour y arriver.
 Artefact : produit ayant subit une transformation même minime

Guide Scrum

18
Les trois piliers de Scrum
Scrum est un processus empirique : il se base sur l'expérience du terrain,, nécessite une
bonne visibilité, des inspections fréquentes et des adaptations aux plans. Cela se
décline dans Scrum par les 2 cycles de régulation :
 lors de mêlées quotidiennes, on s'appuie sur l'expérience du jour passé pour
adapter le planning des jours restant dans le sprint
 lors des revues de sprint, on tient compte de l'expérience du sprint passé pour
adapter le planning de la release, portant sur les sprints à venir.

Il s'appuie sur trois piliers et suit les principes des méthodes agiles :

 La transparence : Scrum met l'accent sur le fait d'avoir un langage commun entre
l'équipe et le management. Ce langage commun doit permettre à tout observateur
d'obtenir rapidement une bonne compréhension du projet.
 L'inspection À intervalle régulier, Scrum propose de faire le point sur les différents
artéfacts produits, afin de détecter toute variation indésirable. Ces inspections ne
doivent pas être faites trop fréquemment, ou par un inspecteur mal formé : cela
nuirait à l'avancement du projet.
 L'adaptation : Si une dérive est constatée pendant l'inspection, le processus doit
alors être adapté. Scrum fournit des rituels, durant lesquels cette adaptation est
possible. Il s'agit de la réunion de planification de sprint, de la mêlée quotidienne, de
la revue de sprint ainsi que de la rétrospective de sprint.

19
Focus sur Xp alias Extrem
programming
 Extreme Programming (XP) est une méthode agile plus particulièrement orientée
sur l'aspect réalisation d'une application, sans pour autant négliger l'aspect gestion
de projet. XP est adapté aux équipes réduites avec des besoins changeants. XP
pousse à l'extrême des principes simples.
 La méthode reposent sur les principes suivants :
 puisque la revue de code est une bonne pratique, elle sera faite en permanence
(par un binôme)
 puisque les tests sont utiles, ils seront faits systématiquement avant chaque
mise en œuvre
 puisque la conception est importante, elle sera faite tout au long du projet
(refactoring : retravailler le code source d'un code informatique sans ajouter
de fonctionnalité au logiciel ni corriger de bogues, mais en améliorant sa lisibilité
pour simplifier sa maintenance, ou le rendre plus générique (on parle aussi de
remaniement du code)
 puisque la simplicité permet d'avancer plus vite, nous choisirons toujours la
solution la plus simple
 puisque la compréhension est importante, nous définirons et ferons évoluer
ensemble des métaphores
 puisque l'intégration des modifications est cruciale, nous l'effectuerons plusieurs
fois par jour
 puisque les besoins évoluent vite, nous ferons des cycles de développement très
rapides pour nous adapter au changement

20
Cycle de développement de l’Xp
 L'Extreme Programming repose sur des cycles rapides de développement
(des itérations de quelques semaines) dont les étapes sont les suivantes :
 une phase d'exploration détermine les scénarii client qui seront fournis pendant
cette itération
 l'équipe transforme les scénarii en tâches à réaliser et en tests fonctionnels
 chaque développeur s'attribue des tâches et les réalise avec un binôme
 lorsque tous les tests fonctionnels passent, le produit est livré
 Le cycle se répète tant que le client peut fournir des scénarii à livrer.
Généralement le cycle de la première livraison se caractérise par sa durée
et le volume important de fonctionnalités embarquées. Après la première
mise en production, les itérations peuvent devenir plus courtes (une
semaine par exemple).

Guide XP 21
Choix du cycle de développement
 Linéaire (cascade, en V)
 rigoureux et standardisé
 risque élevé pour les systèmes mal connus et complexes
 Prototypage
 faible risque car la spécification évolue
 absence de visibilité, conception spaghetti
 Itératif
 combine les avantages des deux modèles précédents
 planification souvent délicate
 R(UP)
 complexe
 mise en œuvre peut être lourde par rapport à l’itératif
 Agile (Scrum, XP, …)
 plus souple que l’itératif
 planification problématique dans un contexte contractuel
 XP : un peu utopique, résistance culturelle, difficile à implémenter en situation
contractuelle

Adapter le cycle de vie pour chaque phase ou sous-système !

22