Génie Logiciel

Pr Hassan SILKAN
Silkan_h@yahoo.fr
Objectifs du Cours
 Connaître les principes du Génie Logiciel et leurs intérêts.
 Connaître les méthodes et techniques qui permettent de
développer et de maintenir des systèmes logiciels complexes,
sûrs et de qualité.

Utilisation de méthodes pour une bonne organisation

 Maîtriser le processus de fabrication d’un système

 Garantir la qualité et la fiabilité du logiciel
 Assurer la gestion et la conduite de Projet Informatique en
respectant les COUTS et DELAIS
I. Introduction au Génie Logiciel
I.1. Qu’est-ce que le génie logiciel ?

Définition ‘officielle’ ( A.M. 1983)

« L’ensemble des activités de conception et de mise en oeuvre des produits et
des procédures tendant à rationaliser la production du logiciel Software
Engineering »
«Software Engineering »

B. W. Boehm, 1976
« Application pratique de la connaissance scientifique dans la conception et
l'élaboration de programmes informatiques et de la documentation associée
nécessaire pour les développer, les mettre en oeuvre et les maintenir »
I.1. Qu’est-ce que le génie logiciel ?
Faire du Génie Logiciel
= utiliser les techniques d’ingénierie du logiciel
Bénéfices attendus :
maîtrise du temps de développement, assurance de la qualité,
maintenance facilitée,…

Logiciel

Structuré (propriétés logiques et fonctionnels)

Créé et maintenu sous forme variées durant son cycle de vie
Conçu pour une machine
Composé de données
Composé d’un ‘système test’
I.2. Caractéristiques souhaitées du logiciel

Caractéristiques souhaitées :
 Adéquation avec les besoins
 Maintenance aisée
 Bon marché
 Rapidement développé
 Souple : facile à modifier
Historique du développement logiciel
7

 1945 : La programmation s'effectue en code binaire et ensuite en

assembleur mais seul celui qui développe est capable de comprendre
et de maintenir son projet . Les projets sont alors de petite taille,
calculateur
 1965 : Crise du logiciel : On se rend compte que l'intuition ne suffit
plus pour développer correctement du logiciel
 1968 : Première conférence sur le GL
 1970 : Définition de la notion de programmation structurée,
apparition des langages évolués.
 1975 : On se rend compte que développer un projet ne consiste pas
seulement à le coder mais à le comprendre, le spécifier et le concevoir
en des étapes successives, d'où l’apparition de la notion de cycle de
vie et essais de développement de méthodes adaptées à ces étapes.
Historique du développement logiciel
8

 1990 : C'est la décennie de la programmation Orientée Objets, avec

comme objectifs, d'une part, la réutilisation des logiciels, l’unification
de la notation et, d'autre part, le passage aussi naturel que possible pour
l'utilisateur d'une application à une autre (de Word à Excel par
exemple).
 Après 2000 :
approches orientées modèles (MDA)
 Multitude de langages de programmation
 Multitude des plateformes
 Génération de code multi source
 Réutilisation de l’existant : patrons d’analyse, de conception, d’implémentation
Constats dans le développement logiciel
9

 Le cout de développement d’un logiciel est presque impossible

à prévoir.
 Les coûts dans le développement du logiciel :
 20% pour le codage et la mise au point individuelle,
 30% pour la conception,
 50% pour les tests d'intégration,
 Le délai de livraison n’est que rarement respecté
 Durée de vie d'un logiciel de 7 à 15 ans,
 Le coût de la maintenance évolutive et corrective constitue la
part prépondérante du coût total ,
 Plus de la moitié des erreurs découvertes en phases de tests
proviennent d'erreurs introduites dans les premières étapes,
 La maintenance du logiciel est difficile et coûteuse
 La qualité du logiciel livré est souvent déficiente.
II.2. Quelques exemples de Bugs célèbres
 Echec du 1er lancement d’Ariane V (4 juin 1996) suite à une erreur de
programmation dans un programme Fortran ( problème au niveau de la
validation (tests d’intégration))
 Mission Venus
 Passage à 5 000 000 de Km de la planète, au lieu de 5 000 Km prévus
 Cause : remplacement d'une virgule par un point (au format US des nombres)
 abandon d'un projet d'informatisation de la City après 4 ans de travail
et 100 M£ de perte

 Etude sur 8 380 projets (Standish Group, 1995) :

16% : succès (conformes aux prévisions initiales);
53% : problématique (budget ou délais non respectés, défaut de fonctionnalités);
31% : échec (abandonnés)
Le taux de succès décroît avec la taille des
projets et la taille des entreprises.
II.3. Risques majeurs du développement du logiciel

 défaillance du personnel
 calendrier et budget irréalistes
 développement de fonctions inadaptées
 Développement d'interfaces utilisateurs inadaptées
 validité des besoins
 composants externes manquants
 tâches externes défaillantes
 problèmes de performance
 exigences démesurées par rapport à la technologie.
II.3. Risques majeurs du développement du logiciel

Les plaintes classiques des clients

 Non respect du cahier des charges,
 Délais et coûts dépassant les prévisions,
 Maintenance corrective et évolutive difficiles,
 Non respect des performances,
 Documentations absentes ou peu claires,
 Fiabilité discutable.

 Qualité du logiciel, Génie logiciel

Réponse aux problèmes : génie logiciel

Génie Logiciel (Software Engineering) :

Comment faire des logiciels de qualité ?

 Qu'attend-on d'un logiciel ?
 Quels sont les critères de qualité ?

L'objectif du G.L est d'optimiser le coût de développement des

logiciels (conception, implémentation et maintenance).
Réponse aux problèmes : génie logiciel

Pour obtenir un logiciel de qualité, il faut maîtriser le processus

d'élaboration
 La vie d'un logiciel est composée de différentes étapes
 La succession de ces étapes forme le cycle de vie du
logiciel
 Il faut contrôler la succession de ces différentes étapes

La qualité du processus de fabrication est garante de

la qualité du produit
III.1.Cycle de vie du Logiciel
Cycle de vie du logiciel
Ensemble des phases (ou étapes) par lesquels passe un logiciel
entre le moment où on a l’idée de le construire et le moment où
on le retire de l’exploitation.

Phase (ou étape) du cycle de vie

Caractérise l’état d’un projet logiciel. Différentes parties d’un
même projet
peuvent être engagées dans des phases différentes
III.1.Cycle de vie du Logiciel
Le cycle de vie est en général défini afin de limiter les dérives de
l’élaboration :
Faisabilité Avant-projet
planification Spécifications fonctionnelles

Conception
produit Spécifications détaillées

réalisati
on corrections
version
révisions tests

exploitation & maintenance

Mais comment tout cela doit il être enchaîné ?
III.1.Cycle de vie du Logiciel
Analyse des besoins
établir les besoins (le cahier des charges) il faut étudier :
 le domaine d'application
 l'état actuel de l'environnement du futur système
 le rôle du système
 les ressources disponibles et requises
 les contraintes d'utilisation
 les performances attendues
 ...

Spécification globale
Cette activité utilise les résultats de l'analyse des besoins, les
considérations techniques et la faisabilité informatique pour produire une
description de ce que doit faire le système mais sans préciser comment il le
fait (on précise le quoi mais pas le comment)
III.1.Cycle de vie du Logiciel
Conception architecturale et détaillée
Enrichir la description du logiciel de détails d'implémentation afin
d'aboutir à une description très proche d'un programme (décrire le
comment).
La conception architecturale (ou conception globale) a pour but de
décomposer le logiciel en composants plus simples
La conception détaillée: fournit pour chaque composant une
description de la manière dont les fonctions ou les services sont
réalisés

Programmation
Réalisation, à partir de la conception détaillée, d'un ensemble de
programme ou de composants de programmes.
III.1.Cycle de vie du Logiciel
Gestion de configurations et intégration
La gestion de configurations a pour but de maîtriser l'évolution et la
mise à jour des composants tout au long du processus de
développement.
L'intégration a pour but de réaliser un ou plusieurs systèmes
exécutables à partir des composants.

Validation et vérification
Validation : a-t-on décrit le bon système, celui qui répond à l'attente
des utilisateurs ?
Vérification : le développement est-il correct par rapport à la
spécification globale ?
III.1.Cycle de vie du Logiciel

Processus de développement

Modèle spécifiant l’enchaînement des activités à mettre en

œuvre pour réaliser un logiciel. Ce modèle tient compte des
aspects techniques, organisationnels et humains.
III.1.Cycle de vie du Logiciel
Comment choisir un modelés?
 clarté et stabilité des besoins
 taille de l’équipe
 L’expérience de l’équipe
 budgets en temps et en argent imparti au projet
 qualité exigée / criticité du projet
 taille et complexité du projet (unité de mesure ?)

Parmi les processus célèbres (liste non exhaustive)

 Cycle en cascade (linéaire)
 Cycle en V (linéaire)
 Cycle en spirale (itératif ou incrémental : prototypes)
 Cycle en Y….
III.2.Le modèle en tunnel
Un jour, peut-
être ...

Le départ est
connu

 Aucune information n’est disponible au cours du développement ni sur

l’état d’avancement, ni sur la qualité des éléments déjà développées.
 Inadapté pour les applications complexes
 Inadapté si le nombre de participant est grand.
III.3.Le modèle en cascade
Analyse

Conception

Programmation

Test

Maintenance

 Il présente le développement logiciel comme une suite de phases qui

s’enchaînent dans un déroulement linéaire.
 Le développement en cascade est en général rythmé par la génération
de documents qui servent de validation pour le passage d’une phase à
l’autre.
 Les résultats de chaque étape sont soumis à une revue approfondie.
 Chaque phase est donc achevée avant que ne débute la suivante.

Exemple : Merise (MCT,MCD,MOT,MLD)

III.3.Le modèle en cascade
Points forts
 Distingue clairement les phases projet
 Définition des tâches à accomplir
 Augmente la visibilité sur l’état d’avancement.
 Séparation des problématiques (métier / technique)
 Détermination des livrables à fournir

Inconvénients
Obligation de définir la totalité des besoins au départ
La notion de système n’est pas prise en compte
Passage brusque d’une étape de spécification des besoins à une phase de
spécification détaillé trop techniques.
La phase de test ne concerne que le bon fonctionnement du système,
Code disponible tardivement dans le projet
Aucune préparation des phases de vérification
III.3.Le modèle en cascade (Waterfall Model)
Remarque : ce n’est pas parce qu’un document passe avec succès d’une
étape de validation sur papier que le logiciel qu’il décrit ne donnera pas
forcement des résultats convaincants.
 des retours d’information entre les phases sont nécessaires pour
incorporer des corrections.
 Années 65-75
 Identification des entrées, transformations et sorties.

Analyse

Conception

Programmation

Test

Maintenance
III.4.Le modèle en V
Validé par
Analyse Tests fonctionnels

Conception Tests d’intégration

Implantation Tests unitaires

Programme

Le principe de ce modèle, est que chaque étape de décomposition du système

possède une phase de test.
Chaque phase du projet à une phase de test qui lui est associé.
Beaucoup de tests sont ainsi créés, ce qui implique une réflexion.
III.4.Le modèle en V
27

Le principe est de faire apparaître la validation et vérification à

chaque étape :
 faisabilité et analyse des besoins + validation
 conception du produit, conception détaillée + vérification
 codage + test unitaire
 intégration + test d'intégration + test d'acceptation
 installation + test du système
III.4.Le modèle en V
28

 On retrouve les caractéristiques du cycle en cascade

 Phases successives
 Une activité principale et des livrables par phase
 Des activités transverses
 Remise en cause de la phase précédente
 Chaque phase en amont de la production du logiciel prépare la
phase correspondante de vérification en aval de la production
du logiciel
III.4.Le modèle en V
29

 Le principe de ce modèle en V, est qu'avec toute décomposition

doit être décrire la recomposition et que toute description d'un
composant est accompagnée de ses tests (correspondance avec sa
spécification) permettant sa vérification et validation.
 Le modèle en V rend explicite le fait que les premières étapes
préparent les dernières faisant intervenir, essentiellement,
vérification et validation.
III.4.Le modèle en V
Avantages
 Tests bien structurés, donc « simple » à organiser, expliquer, suivre,
prédire
 Bon suivi de projet : points de mesure concrets de l’avancement
du travail avec étapes clés
 Préparation des phases de vérification au moment de l’Analyse et de la
Conception
 Limitations des risques en cascade par validation de chaque étape
Inconvénients
 Les cycles de vie sont trop longs.
 Les relations entre les clients et les fournisseurs ne sont pas
suffisamment formalisées.
 L’intégration est trop tardive dans le cycle de vie.
 pas adaptatif (les retours en arrière sont très coûteux)
 projet et outils, ne tient pas compte de l’équipe.
Bons modèles en théorie, difficiles à utiliser en pratique
III.4.Le modèle en Y
 Cette démarche itérative (à tout point de vue) distingue l’étude des
aspects globaux du SI de l’entreprise de ceux spécifiques à chaque
application.
 La démarche préconise deux activités d’ingénierie transverses :
 l’analyse métier qui correspond à l’étude fonctionnelle
 l’architecture technique, qui correspond à l’étude technique.
 Ces deux activités enrichissent respectivement un référentiel des
processus métier de l’entreprise tenant compte de l’urbanisme du SI et
un référentiel de solutions techniques.
III.4.Le modèle en Y
32

Cahier des charges Cahier des charges

Analyse métier Conception

Spécifi- Dossiers
cations de
Gestion Simulation Prototypage Conception
de projet des
+ spécifications
Mécanismes +
Gestion Design Patterns
du changement Codage
+
Gestion
Code +Tests unitaires
de l’environ-
nement Sources +
Objets Exploitation
+ Librairies
Maintenance

Réutilisation
Composants métier
III.4.Le modèle en Y
Avantages :
 Utilisation immédiate de toutes les compétences
 Meilleure traçabilité sur l’ensemble du développement (réutilisation des
modèles d’Analyse + règles de passage)
 Validation précoce des besoins
 Possibilité de générer le code automatiquement
 Industrialisation de la réutilisation

Inconvénients :
 Obligation de définir la totalité des besoins au départ
III.5.Le modèle itératif
Il est basé sur l’évolution de prototypes exécutables, mesurables et donc sur
l’évolution d’éléments concrets.

Le déroulement régulier des itérations facilite la prise en compte des

problèmes
Spécifications détaillées Spécifications détaillées Spécifications détaillées

Amélioration
Amélioration
Amélioration

Tests
Tests

Tests

Construction Construction
Construction
III.5.Le modèle itératif
Intérêts
 Prise en compte des changements du cahier des charges
 Intégrations successives
 Dilution des risques
 Changement de stratégie
 Meilleure conception
 Amélioration du processus lui-même
III.5.Le modèle itératif
Modèle de « prototypage »
Consulter Construire ou
Client modifier prototype

Tester le
prototype

 Jetable 
 Son but est d’assurer de la faisabilité et vérifier les exigences
 Le produit est reconstruit en tenant compte du feed-back de l’utilisateur
 la nouvelle version est développé en utilisant le modèle en cascade
 Evolutif 
 Plusieurs prototypes sont développés (avec minimum de fonctionnalités)
 Seul le prototype retenu par l’usager est évolué en un produit final
III.5.Le modèle itératif
Maquette ou prototype rapide
Analyse préliminaire Analyse et sélection de
des besoins nouvelles fonctions

Etat non satisfait

Construction du
prototype

Analyse des Evaluation

expérimentation
besoins,
Etat non satisfait
Spécifications
fonctionnelles. Expression claire
des besoins réels

Spécification
définitives
III.5.Le modèle itératif
prototype expérimentale
Utilisé au niveau de la conception pour : S'assurer de la faisabilité de parties
critiques et Valider des options de conception
Spécification Approfondissement
Initiale
Sélections d’un
point ou d’une
caractéristique Construction
du prototype
Evaluation
Confirmation ou affinement
prototype évolutif des spécifications

Etude préalable
Spécification de base
Première Identification
Conception et 1er version
réalisation
Evaluation
Mise en ouvre et
utilisation
Corrections et
Nouvelle version
améliorations
Version finale
III.5.Le modèle itératif
 L’ordonnancement des itérations est basée sur les priorités entre cas
d’utilisation et sur l’étude du risque
 Chaque prototype réduit une part du risque
 Un prototype donné est construit avec des buts précis et clairement
exprimés
 L’évaluation du prototype est effectuée par rapports à ces buts
 L’enchaînement des prototypes est décrit dans le plan des prototypes
 Les priorités et l’ordonnancement de construction des prototypes
peuvent changer avec le déroulement du plan
III.5.Le modèle itératif
Avantages
 Au cours de développement, certains prototypes sont montrés aux
utilisateurs.
 L’utilisateur est placé devant des situations concrètes lui
permettant de mieux structurer ses désirs et de les communiquer à
l’équipe de développement.
 L’utilisateur est totalement impliqué, prend sa part de
responsabilité
 accepte facilement le nouveau système.
 L’équipe de développement est plus motivé du fait de la proximité
de l’objectif.
III.5.Le modèle itératif
Avantages
 L’intégration de différents composants des logiciels est réalisée de
manière progressive durant sa construction.
 Les progrès se mesurent par des programmes mesurables plutôt
que par des documents ou des estimations comme dans le cas de
modèle en cascade.
 L’encadrement dispose ainsi d’éléments objectifs pour évaluer les
progrès et l’état d’avancement avec plus de fiabilité.
III.6.Le modèle incrémentale
Principe
découper l’expression des besoins en sous-parties (lots ou
incréments). Chaque lot sera réalisé successivement ou en se
chevauchant selon un modèle en cascade ou en V.
III.6.Le modèle incrémentale
Incréments
délivrés Produit opérationnel :
incréments livrables

Le premier incrément est

souvent le noyau

temps  Les incréments aident à gérer

les risques techniques (matériel
non disponible)

 combine des éléments des modèles linéaires et du prototypage

 produit des incréments livrables
 se concentre sur un produit opérationnel (pas de prototype jetable)
 peut être utilisé quand il n’y a pas assez de ressources disponibles
pour une livraison à temps
III.6.Le modèle incrémentale
Avantages
 Tout le monde participe pour diviser la masse de travail de chacun
→ Projet réalisable en un minimum de temps
 Correspondance entre groupe et éléments du projet

Inconvénients
 Nécessité d’avoir des développeurs qualifiés, qui connaissent le
langage
 Difficile de mettre en place des tests intermédiaires : les groupes
étaient autonomes mais pas indépendants !!!
III.7.Le modèle en spirale ( Boehm, 86)
Idée
 fournir le plus rapidement possible un prototype exécutable
permettant une validation concrète et non sur document.
 Progression du projet par incrémentations successives de versions
du prototype : itérations.
 Certains prototypes peuvent être montrés au client. Par ailleurs, une
maquette peut être réalisable préalablement au premier prototype.
 La validation par prototype ne justifie pas l’absence de recours à la
documentation!
III.7.Le modèle en spirale ( Boehm, 86)
 Le projet est découpé en N phases successives suivies d’une dernière
phase où le logiciel est intégralement développé
 Chaque phase a pour objectif la validation d’un point technique ou
fonctionnel particulier pouvant donner lieu au développement d’une
maquette
 Chaque phase peut donner lieu à l’utilisation d’un cycle en V ou en Y
 Chaque phase permet d’affiner les besoins de l’utilisateur
 A chaque phase est associée une analyse de risques pouvant remettre en
cause le développement
III.7.Le modèle en spirale ( Boehm, 86)
Réduit les
risques si bien
communiquer avec le client
risques techniques et de gestion
appliqué

définir les ressources,

la répartition dans le temps
construire, tester,
installer
III.7.Le modèle en spirale ( Boehm, 86)
 Chaque cycle de la spirale est composé de
 Analyse du risque
 Développement d ’un prototype
 Simulation et essais du prototype
 Détermination des besoins, à partir des résultats des essais
 Validation des besoins par un comité de pilotage
 Planification du cycle suivant
 Le dernier cycle comprend :
 en phase 2 développement de la version finale
 en phase 3 tests et installation
III.7.Le modèle en spirale ( Boehm, 86)
Avantages
 Planification renforcée
 Validation concrète et non sur documents
 Limitation du risque à chaque itération
 Client partenaire: retour rapide sur ses attentes
 Progressions : pas d’explosion des besoins à l’approche de la livraison : pas de«
n’importe quoi pourvu que ça marche »
 Flexibilité :
 Modification des spécifications = nouvelle itération
 Maintenance = forme d’itération
 Il est plus particulièrement adapté aux projets innovants, à risques et dont les enjeux
sont importants.
 Un des intérêts du modèle en spirale est de fournir la liste des risques majeurs
encourus dans le cadre du développement d'un système informatique.
III.7.Le modèle en spirale ( Boehm, 86)
Inconvénients
 Pas de processus idéal
 Cycle itératif : planification très attentive et rigoureuse
 Cycle en « V » : processus éprouvé le plus répandu surtout pour les
systèmes connus
Cycle itératif : peut dérouter au premier abord
 Processus adapté à la modélisation objet
 Modèle objet : se prête parfaitement à une démarche incrémentale
 Le cycle en spirale a cependant une portée générale
 Chaque cycle produit un composant du système intégré en phase finale
 Les maquettes développées à chaque cycle ne sont pas obligatoirement
réutilisables
 Risque de « spiralisation » des besoins
 Nécessite une plus grande participation de la part des utilisateurs
III.8. Méthodes agiles
Problématiques du développement logiciel

Modèle utilisé en pratique

 La plupart du temps il n’y a aucune distinction entre l’expression

des besoins et les spécifications.
 la conception est souvent réalisée par les développeurs en même
temps que le développement.
 les clients ont de grandes difficultés à exprimer leurs besoins sous
une forme exploitable par les équipes de développement
III.8. Méthodes agiles
Quelques méthodes agiles :
UP(Unified Process),RUP(Rational Unified Process), 2TUP(Two
Dynamic Software Development Method
Adaptative Software Development
Rapid Application Development
XP(eXtreme Programming)
SCRUM (mêlée au rugby)
Tracks Unified Process)
Crystal Clear…
III.8. Méthodes agiles
Les valeurs des méthodologies agiles
Les méthodologies agiles prônent quatre valeurs fondamentales :
 Communication : personnes et interactions plutôt que
procédures et outils.
 Simplicité : applications fonctionnelles plutôt que documentation
complète.
 Feedback : Collaboration avec le client plutôt que négociation de
contrat.
 Courage : Acceptation du changement plutôt que suivi d’un plan.
III.8. Méthodes agiles
et 12 principes
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. «Le client et les développeurs doivent collaborer quotidiennement
au projet ».
III.8. Méthodes agiles

et 12 principes
5. « Bâtissez le projet autour de personnes motivées. Donnez leur
l'environnement et le soutien dont elles ont besoin, et croyez en
leurs capacités à faire le travail ».
6. « La méthode la plus efficace de transmettre l'information est une
conversation en face à face ».
7. « Un logiciel fonctionnel est la meilleure unité de mesure de
progression d’un projet ».
8. « Les processus agiles incitent à un rythme de développement
soutenable. Sponsors, développeurs et utilisateurs devraient
pouvoir maintenir le rythme indéfiniment ».
III.8. Méthodes agiles

et 12 principes
9. « Porter 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. « À intervalles réguliers, l'équipe réfléchit aux moyens de devenir
plus efficace, puis accorde et ajuste son comportement dans ce sens
».
III.8. Méthodes agiles
Avantages
 Elles intègrent le client pour être plus proches de ses besoins.
 Elles sont adaptives plutôt que prédictives.
 Elles sont orientées vers l’humain, plutôt que vers les processus et outils
 minimiser le coût d’un changement au travers du temps contrairement à une
méthodologie classique

Analyse du coût d'un changement en fonction de son moment d'apparition

III.8. Méthodes agiles
Rapid Application Development
 Discuter et interagir avec l’utilisateur
 Vérifier l ’efficacité réelle d’un algorithme
 Vérifier des choix spécifiques d ’IHM
 Souvent utilisé pour identifier les besoins
 Prototype jetable (moins de risque ?)
 Souvent implémenté par des
générateurs de code
 Prototype évolutif
III.8. Méthodes agiles
Rapid Application Development
Principe n°1
Utilisation d’outils performants d’aide au développement

 AGL de conception
 AGL de réalisation
 L4G, langages de haut niveau, générateurs de code
 Outils de tests
 Poste individuel de travail
 Réseau et travail de groupe
III.8. Méthodes agiles
Rapid Application Development
Principe n°2
Forte implication des utilisateurs
 Les utilisateurs ont la responsabilité de la production de certaines
tâches Exemple : expression des besoins
 Comportement "positif" des utilisateurs participatifs, disponibles,
engagés
 Utilisateurs centrés sur :
 les besoins strictement nécessaires
 la simplicité des règles de gestion
 l'approche "délai »
III.8. Méthodes agiles
Rapid Application Development
Principe n°3
Equipe informatique de gagneurs

 L’équipe doit être :

 Réduite

 Compétente

 Soudée

 Motivée

 Outillée
III.8. Méthodes agiles
Rapid Application Development

Principe n°4
Cycle de vie raccourci
 Approche de prototypage
 Parallélisation
 de la conception
 de la réalisation
 Livraison par versions successives
III.8. Méthodes agiles
Rapid Application Development
Principe n°5
Pilotage centré sur l’obtention de résultats rapides

 Arbitrage systématique délais / fonctions à développer

 Cycle rapide de décisions
 décideurs impliqués
 décideurs sachant comprendre les impacts des décisions à
court et moyen terme
 Suivi de projets efficace
 Outils
 organisation
III.8. Méthodes agiles
Rapid Application Development
Les difficultés du RAD
 Pas aisément reproductible
 Approche plus que méthode
 Nécessité d’une équipe de "gagneurs"
 Fort outillage nécessaire
 Approprié pour les systèmes dont la modularité est évidente
III.8. Méthodes agiles
Unified Process (UP)
 Développé à l’origine par Philippe Kruchten et Ivar Jacobson sous la
coupe de la société Rational
 Le processus unifié est un ensemble structuré de "bonnes pratique"
issues de l’expérience
 Le terme Unifié fait d’ailleurs référence à cet aspect fusion entre les
pratiques issues de méthodes antérieures.
III.8. Méthodes agiles
UP et Rational Unified Process (RUP)
III.8. Méthodes agiles
Unified Process (UP)
1. Proximité avec les utilisateurs et pilotage par les cas d’utilisation
2. Pratique de la modélisation graphique des exigences
3. Centré sur l’architecture
4. Fondé sur la production et l’assemblage de composants
5. Développement itératif et incrémental du logiciel (chaque fin
d’itération doit générer un prototype exécutable)
6. Gestion des besoins et des exigences (traçabilité)
7. Souci permanent de la qualité (recettes fréquentes de versions
intermédiaires, automatisation des tests, revus par les pairs)
8. Gestion des risques permanente
9. Gestion des demandes de changement
III.8. Méthodes agiles
UP et Rational Unified Process (RUP)
 UP est à base de composants.
 UP utilise UML.
 UP est piloté par les cas d’utilisation.
 UP est centré sur l’architecture.
 UP est itératif et incrémental.
III.8. Méthodes agiles
UP et Rational Unified Process (RUP)
III.8. Méthodes agiles
UP et Rational Unified Process (RUP)
 Inception : L’inspection (initialisation) détermine en quelque sorte la
« vision » du projet afin de décider de sa poursuite ou de son arrêt.
 Elaboration : Description plus détaillé et complète des cas
d’utilisation et de l’architecture du système (premier squelette ou
prototype).
 Construction : Cette phase vise à développer le logiciel, à
métamorphoser l’architecture en un système complet en concevant, en
implémentant et en testant l’ensemble des éléments.
 Transition : Cette phase permet le passage de l’application des mains
des développeurs aux utilisateurs finaux en mettant en place la
formation des utilisateurs, le déploiement ainsi que les béta-tests.
III.8. Méthodes agiles
Extreme Programming (XP)
La méthode XP (pour eXtreme Programming) définit un certain
nombre de bonnes pratiques permettant de développer un logiciel
dans des conditions optimales en plaçant le client au cœur du
processus de développement, en relation étroite avec le client.
III.8. Méthodes agiles
Les pratiques XP
1. Client sur le Site (Whole Team)
2. Séance de Planification (Planning Game): le client définit les scénarios
utilisateurs.
3. Intégration Continue (Continuous Integration)
4. Livraisons Fréquentes (Small Releases)
5. Rythme Soutenable (Sustainable Pace)
6. Tests de Recette (Customer Tests)
7. Basé sur les tests (Test-Driven Development)
8. Conception Simple (Simple Design)
9. Métaphore (Metaphor)
10. Remaniement Continu de Codage (Refractoring)
11. Convention de Code (Coding Standard)
12. Programmation En Binôme (Pair Programming)
III.8. Méthodes agiles
Extreme Programming (XP)
« Comment mieux travailler avec le client pour nous
focaliser sur ses besoins les plus prioritaires et être aussi
réactifs que possible ? »
Pour des petits projets (moins de 10 personnes)
Valeurs d’XP :
1. Communication
2. Feedback
3. Simplicité
4. Courage

Inconvénients :
- Phase d’analyse pas assez couverte
- Manque de contrôle et de structuration
III.8. Méthodes agiles
Avantages
 Propose des modèles Spécifie le dialogue entre les différents intervenants
du projet : les livrables, les plannings, les prototypes…
 de documents et des canevas pour des projets types.
 Gestion des risques dans le projet (risque financier et de retard limité).
Inconvénients
 Lourd, bureautique (mise à jour des schémas), rigoureux et couteux.
 Très axé processus, au détriment du développement : peu de place pour le code et
la technologie.
 Vision non évidente ni immédiate.
 Projet de plus de dix personnes.
VI. Qualité Logiciel
Qualité
Aptitude d’un produit ou d’un service (d’un système) à
satisfaire les besoins des utilisateurs.

Besoins
Exprimés et doivent être traduits ou formulés

Utilisateurs
Particuliers, entreprises ou services publics
VI. Qualité Logiciel
Les besoins et les facteurs de qualité
Les critères de qualité :
 Simplicité d’utilisation
 Portabilités des outils d’un environnement vers un autre
 adaptabilité de l’environnement aux besoins particuliers d’un site et des
utilisateurs avant le démarrage d’un développement
 l’évolutivité de l’environnement pour la prise en compte de de nouvelles
fonctionnalités
 Capacité d’intégration d’outils au sein d’une méthode de
développement
 Sécurité du développement (protection des différentes composantes(Pg,
D, Doc) contre des accès ou modifications non autorisés.
VI. Qualité Logiciel
Facteurs externes de la qualité (utilisateurs du produit)
 Validité : l ’aptitude d’un produit logiciel à réaliser exactement les
tâches définies par sa spécification.
 Robustesse : l’aptitude d’un logiciel à fonctionner même dans des
conditions anormales.
 Extensibilité : la facilité d’adaptation d’un logiciel aux changements de
spécification.
 Réutilisabilité : l’aptitude d’un logiciel à être réutilisé en tout ou en
partie pour de nouvelles applications.
 Compatibilité : l’aptitude des logiciels à pouvoir être combinés les uns
avec les autres.
VI. Qualité Logiciel
Concepts de la qualité
la qualité est aussi la recherche du compromis

 Délais et couts
 Maintenance difficile
 Absence de documentation ou peu claire
VI. Qualité Logiciel
La qualité pour les dirigeants
 coûts et délais
 évolutibilité
 maintenabilité
 rigidité des systèmes conçus
 indépendance données/programmes
 retour sur investissement
 rentabilité du processus de développement
 rentabilité de l'informatique
VI. Qualité Logiciel
La qualité pour les informaticiens
 Inadéquation entre besoins et produits finis
 Sécurité
 Intégrité des données
 Sauvegarde
 Rapidité
 Robustesse
 Évolutivité du produit
 Documentation
 Évolutivité de la documentation
 Compromis coût délais
 Meilleure productivité
 Meilleure gestion de projet
 Meilleure maintanabilité,…
VI. Qualité Logiciel
Difficultés
 Inadéquation entre besoins et produits finis
 Coût
 Absence de schéma directeur
 Complexité de la logique à développer
 Manque de visibilité totale de l’application
(chacun développe dans son coin)
 Absence de cadre méthodologique
 Pas de vision claire
 Mauvaise formulation des besoins
 Absence de modélisation
 Mauvaise utilisation des outils
 Personnel insuffisant…