Cours de Genie Logicielle (Chap.

6)

Prof. Dr Jean-Pepe BUANGA

Plan du Cours
Introduction
 Les entreprises évoluent désormais dans un
environnement mondial en évolution rapide.
Ils doivent répondre aux nouvelles
opportunités et marchés, aux conditions
économiques changeantes et à l'émergence
de produits et services concurrents. Les
logiciels font partie de presque toutes les
opérations commerciales.
 Un développement et une livraison rapides

sont donc désormais souvent l'exigence la

plus critique pour les systèmes logiciels.
Introduction
 Les processus de développement logiciel qui
prévoient de spécifier complètement les
exigences, puis de concevoir, construire et
tester le système ne sont pas adaptés au
développement logiciel rapide.
 Le logiciel n'est pas développé comme une

seule unité mais comme une série

d'incréments, chaque incrément incluant de
nouvelles fonctionnalités système.
Introduction
 Bien qu'il existe de nombreuses approches
pour le développement rapide de logiciels,
elles partagent certaines caractéristiques
fondamentales :
 1. Les processus de spécification, de
conception et d’implementation sont
imbriqués. Il n'y a pas de spécification détaillée
du système et la documentation de conception
est minimisée. Le document des exigences de
l'utilisateur ne définit que les caractéristiques
les plus importantes du système.
Introduction
 2. Le système est développé dans une série
de versions. Les utilisateurs finaux et autres
parties prenantes du système sont impliqués
dans la spécification et l'évaluation de chaque
version.
 3. Les interfaces utilisateur du système sont

souvent développées à l'aide d'un système de

développement interactif qui permet de créer
rapidement la conception de l'interface en
dessinant et en plaçant des icônes sur
l'interface.
Introduction
 Les méthodes agiles sont des méthodes
incrémentales de développement dans lesquelles
les incréments sont petits et, généralement, de
nouvelles versions du système sont créées et
mises à la disposition des clients toutes les deux
ou trois semaines.
 Ils impliquent les clients dans le processus de
développement pour obtenir un retour rapide sur
l'évolution des besoins. Ils minimisent la
documentation en utilisant des communications
informelles plutôt que des réunions formelles avec
des documents écrits.
Introduction
 Les méthodes agiles reposent universellement sur
une approche incrémentielle de la spécification,
du développement et de la livraison des logiciels.
 Ils sont les mieux adaptés au développement
d'applications où les exigences du système
changent généralement rapidement au cours du
processus de développement.
 Ils sont destinés à fournir rapidement un logiciel
fonctionnel aux clients, qui peuvent ensuite
proposer des exigences nouvelles et modifiées à
inclure dans les itérations ultérieures du système.
Introduction
 Ils visent à réduire la bureaucratie des
processus en évitant les travaux dont la
valeur à long terme est douteuse et en
éliminant la documentation qui ne sera
probablement jamais utilisée.
Introduction
 Bien que ces méthodes agiles soient toutes basées
sur la notion de développement et de livraison
incrémentaux, elles proposent différents
processus pour y parvenir.
 Cependant, ils partagent un ensemble de
principes, basés sur le agile manifesto.
 Ces principes sont les suivants:
 Implication du client: les clients doivent être
étroitement impliqués tout au long du processus
de développement. Leur rôle est de fournir et de
hiérarchiser les nouvelles exigences du système et
d'évaluer les itérations du système.
 Livraison incrémentielle: Le logiciel est
développé par incréments, le client spécifiant
les exigences à inclure dans chaque
incrément.
 Travail d’equipe : les compétences de l'équipe

de développement doivent être reconnues et

exploitées. Il faut laisser les membres de
l'équipe développer leurs propres méthodes
de travail sans processus normatifs.
 Adoption du changement : attendez-vous à
ce que les exigences du système changent et
concevez donc le système pour s'adapter à
ces changements.
 Maintien de la simplicité: concentrez-vous

sur la simplicité à la fois dans le logiciel en

cours de développement et dans le processus
de développement. Dans la mesure du
possible, travaillez activement pour éliminer
la complexité du système.
Plan-driven et Développement agile
 Les approches agiles du développement logiciel
considèrent la conception et la mise en œuvre
comme les activités centrales du processus logiciel.
Ils intègrent d'autres activités, telles que
l'élicitation des exigences et les tests, dans la
conception et la mise en œuvre.
 En revanche, une approche de l'ingénierie logicielle
basée sur un plan, identifie des étapes distinctes
du processus logiciel avec des sorties associées à
chaque étape. Les sorties d'une étape sont utilisées
comme base pour planifier l'activité de processus
suivante.
Plan-driven et Développement agile
 La figure 6.1 montre les distinctions entre les
approches axées sur le plan et les approches
agiles de la spécification du système.
Plan-driven et Développement agile
 Dans une approche axée sur le plan,
l'itération se produit au sein des activités avec
des documents formels utilisés pour
communiquer entre les étapes du processus.
Il s'agit alors d'une contribution au processus
de conception et de mise en œuvre.
 Dans une approche agile, l'itération se
produit à travers les activités. Par
conséquent, les exigences et la conception
sont développées ensemble plutôt que
séparément.
Plan-driven et Développement agile
 En fait, la plupart des projets logiciels
incluent des pratiques issues d'approches
agiles et pilotées par plan. Pour décider de
l'équilibre entre une approche planifiée et une
approche agile, vous devez répondre à un
ensemble de questions techniques, humaines
et organisationnelles :
Plan-driven et Développement agile
 1. Est-il important d'avoir une spécification et
une conception très détaillées avant de
passer à la mise en œuvre ? Si tel est le cas,
vous devrez probablement utiliser une
approche axée sur un plan.
 2. Une stratégie de livraison incrémentielle,

où vous livrez le logiciel aux clients et

obtenez un retour rapide de leur part, est-
elle réaliste ? Si c'est le cas, envisagez
d'utiliser des méthodes agiles.
Plan-driven et Développement agile
 3. Quelle est la taille du système en cours de
développement ? Les méthodes agiles sont
plus efficaces lorsque le système peut être
développé avec une petite équipe colocalisée
qui peut communiquer de manière informelle.
Cela peut ne pas être possible pour les
grands systèmes qui nécessitent des équipes
de développement plus importantes; il peut
donc être nécessaire d'utiliser une approche
basée sur un plan.
Plan-driven et Développement agile
 4. Quel type de système est développé ? Les
systèmes qui nécessitent beaucoup
d'analyses avant la mise en œuvre (par
exemple, un système en temps réel avec des
exigences de synchronisation complexes) ont
généralement besoin d'une conception assez
détaillée pour effectuer cette analyse. Une
approche axée sur un plan peut être la
meilleure dans ces circonstances.
Plan-driven et Développement agile
 5. Quelle est la durée de vie prévue du
système ? Les systèmes à longue durée de vie
peuvent nécessiter plus de documentation de
conception pour communiquer les intentions
originales des développeurs de systèmes à
l'équipe de support. Cependant, les partisans
des méthodes agiles soutiennent à juste titre
que la documentation n'est souvent pas tenue
à jour et qu'elle n'est pas d'une grande utilité
pour la maintenance du système à long
terme.
Plan-driven et Développement agile
 7. Comment l'équipe de développement est-
elle organisée ? Si l'équipe de développement
est distribuée ou si une partie du
développement est sous-traitée, vous devrez
peut-être développer des documents de
conception pour communiquer entre les
équipes de développement. Vous devrez
peut-être planifier à l'avance de quoi il s'agit.
Plan-driven et Développement agile
 8. Y a-t-il des problèmes culturels qui
peuvent affecter le développement du
système ? Les organisations d'ingénierie
traditionnelles ont une culture de
développement basé sur des plans, car c'est
la norme en ingénierie. Cela nécessite
généralement une documentation complète
de conception, plutôt que les connaissances
informelles utilisées dans les processus
agiles.
Plan-driven et Développement agile
 9. Quelle est la qualité des concepteurs et des
programmeurs de l'équipe de développement ? Il
est parfois avancé que les méthodes agiles
nécessitent des niveaux de compétences plus
élevés que les approches basées sur des plans
dans lesquelles les programmeurs traduisent
simplement une conception détaillée en code. Si
vous avez une équipe avec des niveaux de
compétences relativement faibles, vous devrez
peut-être utiliser les meilleures personnes pour
développer la conception, avec d'autres
responsables de la programmation.
 10. Le système est-il soumis à une
réglementation externe ? Si un système doit
être approuvé par un organisme de
réglementation externe, vous devrez
probablement produire une documentation
détaillée dans le cadre du dossier de sécurité
du système.
Plan-driven et Développement agile
 En réalité, la question de savoir si un projet peut
être qualifié de plan-driven ou agile n'est pas très
importante. La principale préoccupation des
acheteurs d'un système logiciel est de savoir s'ils
disposent ou non d'un système logiciel
exécutable qui répond à leurs besoins et fait des
choses utiles pour l'utilisateur individuel ou
l'organisation.
 Dans la pratique, de nombreuses entreprises qui
prétendent avoir utilisé des méthodes agiles ont
adopté certaines pratiques agiles et les ont
intégrées à leurs processus pilotés par des plans.
Programmation extrême
 Le nom a été inventé par Beck (2000) parce
que l'approche a été développée en poussant
les bonnes pratiques reconnues, telles que le
développement itératif, à des niveaux
« extrêmes ». Par exemple, sous XP, plusieurs
nouvelles versions d'un système peuvent être
développées par différents programmeurs,
intégrées et testées en une journée.
 Dans la programmation extrême, les
exigences sont exprimées sous forme de
scénarios (appelés user stories), qui sont
implémentés directement sous forme d'une
série de tâches. Les programmeurs travaillent
en binôme et développent des tests pour
chaque tâche avant d'écrire le code. Tous les
tests doivent être exécutés avec succès
lorsqu'un nouveau code est intégré dans le
système. Il y a un court intervalle de temps
entre les versions du système.
 La figure 6.2 illustre le processus XP pour
produire un incrément du système en cours
de développement.
 La programmation extrême implique un
certain nombre de pratiques:
 Planification incrémentielle: les exigences
sont enregistrées sur les cartes d'histoire et
les histoires à inclure dans une version sont
déterminées par le temps disponible et leur
priorité relative. Les développeurs divisent
ces histoires en « tâches » de développement.
 Petites versions : l'ensemble minimal de
fonctionnalités utiles qui fournit une valeur
commerciale est développé en premier. Les versions
du système sont fréquentes et ajoutent
progressivement des fonctionnalités à la première
version.
 Conception simple : suffisamment de conception est
réalisée pour répondre aux exigences courantes et pas
plus.
 Le développement First-Test. Un cadre de test unitaire
automatisé est utilisé pour écrire des tests pour une
nouvelle fonctionnalité avant que cette fonctionnalité
elle-même ne soit implémentée.
 Refactorisation. Tous les développeurs sont
censés refactoriser le code en permanence dès
que des améliorations de code possibles sont
trouvées. Cela permet de garder le code simple
et maintenable.
 Programmation en binôme. Les développeurs
travaillent par paires, vérifiant le travail de
chacun et fournissant le soutien nécessaire
pour toujours faire du bon travail.
 Propriété collective. Les paires de
développeurs travaillent sur tous les
domaines du système, de sorte qu'aucun îlot
d'expertise ne se développe et que tous les
développeurs assument la responsabilité de
l'ensemble du code. N'importe qui peut
changer n'importe quoi.
 Intégration continue. Dès que le travail sur
une tâche est terminé, elle est intégrée à
l'ensemble du système. Après une telle
intégration, tous les tests unitaires du
système doivent réussir.
 Rythme soutenable. De grandes quantités

d'heures supplémentaires ne sont pas

considérées comme acceptables car l'effet net
est souvent de réduire la qualité du code et la
productivité à moyen terme.
 Client sur place. Un représentant de
l'utilisateur final du système (le Client) doit
être disponible à temps plein pour
l'utilisation de l'équipe XP. Dans un processus
de programmation extrême, le client est un
membre de l'équipe de développement et est
responsable d'apporter les exigences système
à l'équipe pour la mise en œuvre.
 Ces pratiques reflètent les principes des
méthodes agiles:
 1. Le développement incrémentiel est pris en

charge par de petites versions fréquentes du

système. Les exigences sont basées sur des
histoires de clients simples ou des scénarios
qui sont utilisés comme base pour décider
quelle fonctionnalité doit être incluse dans un
incrément système.
 2. L'implication du client est soutenue par
l'engagement continu du client dans l'équipe de
développement. Le représentant client participe
au développement et est responsable de la
définition des tests de réception du système.
 3. Les personnes, et non les processus, sont
soutenues par une programmation en binôme,
la propriété collective du code du système et un
processus de développement durable qui
n'implique pas des heures de travail
excessivement longues.
 4. Le changement est adopté par le biais de
versions régulières du système pour les clients,
d'un développement de test d'abord, d'une
refactorisation pour éviter la dégénérescence du
code et de l'intégration continue de nouvelles
fonctionnalités.
 5. Le maintien de la simplicité est soutenu par
une refactorisation constante qui améliore la
qualité du code et par l'utilisation de conceptions
simples qui n'anticipent pas inutilement les
modifications futures du système.
 Dans un processus XP, les clients sont
intimement impliqués dans la spécification et
la hiérarchisation des exigences du système.
Les exigences ne sont pas spécifiées sous
forme de listes de fonctions système
requises. Le client du système fait plutôt
partie de l'équipe de développement et
discute des scénarios avec les autres
membres de l'équipe. L'équipe de
développement vise ensuite à implémenter ce
scénario dans une future version du logiciel.
 Un exemple de carte d'histoire pour le
système de gestion des patients en soins de
santé mentale est presente ci-bas. Il s'agit
d'une brève description d'un scénario de
prescription de médicaments à un patient.
 Kate est un médecin qui souhaite prescrire des médicaments
à un patient fréquentant une clinique. Le dossier du patient
est déjà affiché sur son ordinateur, elle clique donc sur le
champ médicament et peut sélectionner le médicament en
cours », « nouveau médicament » ou « formulaire ».
 Si elle sélectionne « médication actuelle », le système lui
demande de vérifier la dose. Si elle souhaite modifier la dose,
elle saisit la dose puis confirme la prescription.
 Si elle choisit un « nouveau médicament », le système
suppose qu'elle sait quel médicament prescrire. Elle tape les
premières lettres du nom du médicament. Le système affiche
une liste de médicaments possibles commençant par ces
lettres. Elle choisit le médicament requis et le système répond
en lui demandant de vérifier que le médicament sélectionné
est correct. Elle saisit la dose puis confirme la prescription.
 .
 Si elle choisit « formulaire », le système affiche une zone de
recherche pour le formulaire approuvé. Elle peut alors
rechercher le médicament requis. Elle sélectionne un
médicament et est invitée à vérifier que le médicament est
correct. Elle saisit la dose puis confirme la prescription.
 Le système vérifie toujours que la dose est dans la plage
approuvée. Si ce n'est pas le cas, Kate est invitée à modifier la
dose.
 Une fois que Kate a confirmé la prescription, elle sera affichée
pour vérification. Elle clique soit sur « OK » ou sur
« Modifier ». Si elle clique sur « OK », la prescription est
enregistrée dans la base de données d'audit. Si elle clique sur
« Modifier », elle entre à nouveau dans le processus
« Prescription de médicaments »
 Les cartes d'histoire sont les principales
entrées du processus de planification XP ou
du « jeu de planification ». Une fois que les
cartes d'histoire ont été développées, l'équipe
de développement les divise en tâches (Figure
6.3) et estime l'effort et les ressources
nécessaires pour mettre en œuvre chaque
tâche. Cela implique généralement des
discussions avec le client pour affiner les
exigences.
 Le client priorise ensuite les histoires à mettre
en œuvre, en choisissant celles qui peuvent
être utilisées immédiatement pour fournir un
support commercial utile.
 L'intention est d'identifier les fonctionnalités
utiles qui peuvent être mises en œuvre dans
environ deux semaines, lorsque la prochaine
version du système sera mise à la disposition
du client.
 Figure 6.3 Examples of task cards for
prescribing medication.
 Dans la pratique, de nombreuses entreprises
qui ont adopté XP n'utilisent pas toutes les
pratiques de programmation extrêmes.
 Ils choisissent en fonction de leurs méthodes

de travail locales. Par exemple, certaines

entreprises trouvent que la programmation
en binôme est utile ; d'autres préfèrent
utiliser une programmation et des évaluations
individuelles.
Tests sous XP
 Pour éviter certains des problèmes de test et
de validation du système, XP met l'accent sur
l'importance des tests de programme.
 XP inclut une approche de test qui réduit les

chances d'introduire des erreurs non

découvertes dans la version actuelle du
système.
 Les principales caractéristiques des tests sous
XP sont :
 1. Le développement du 1er test(First-test);
 2. Le développement de tests incrémentiels à

partir de scénarios;
 3. L'implication des utilisateurs dans le

développement et la validation des tests;

 4. L'utilisation de cadres de tests

automatisés.
 Le développement first-test est l'une des
innovations les plus importantes de XP. Au lieu
d'écrire du code puis écrire des tests pour ce
code, vous écrivez les tests avant d'écrire le code.
 Cela signifie que vous pouvez exécuter le test
pendant l'écriture du code et découvrir des
problèmes au cours du développement.
 L'écriture de tests définit implicitement à la fois
une interface et une spécification de
comportement pour la fonctionnalité en cours de
développement.
 Les implémenteurs de tâches doivent bien
comprendre la spécification afin de pouvoir
écrire des tests pour le système. Cela signifie
que les ambiguïtés et les omissions dans la
spécification doivent être clarifiées avant le
début de la mise en œuvre.
Programmation en binôme
(Pair)
 Une autre pratique innovante qui a été
introduite dans XP est que les programmeurs
travaillent en binôme pour développer le
logiciel. En fait, ils s'assoient ensemble sur le
même poste de travail pour développer le
logiciel. Cependant, les mêmes paires ne
programment pas toujours ensemble. Au
contraire, les paires sont créées
dynamiquement afin que tous les membres
de l'équipe travaillent ensemble pendant le
processus de développement.
 L'utilisation de la programmation par paires
présente un certain nombre d'avantages :
 1. Il soutient l'idée d'appropriation et de
responsabilité collectives du système. L'équipe a
la responsabilité collective de résoudre ces
problèmes.
 2. Il s'agit d'un processus de révision informel
car chaque ligne de code est examinée par au
moins deux personnes.
 3.Il aide à prendre en charge la refactorisation,
qui est un processus d'amélioration du logiciel.
Gestion de projet agile
 La principale responsabilité des chefs de
projet logiciel est de gérer le projet afin que
le logiciel soit livré à temps et dans les limites
du budget prévu pour le projet.
 Ils supervisent le travail des ingénieurs
logiciels et surveillent la progression du
développement logiciel.
 L'approche standard de la gestion de projet
est axée sur le plan.
 Les gestionnaires établissent un plan pour le

projet indiquant ce qui doit être livré, quand

il doit être livré et qui travaillera à
l'élaboration des livrables du projet.
 Une approche basée sur des plans exige

vraiment qu'un gestionnaire ait une vision

stable de tout ce qui doit être développé et
des processus de développement.
 Cependant, cela ne fonctionne pas bien avec
les méthodes agiles où les exigences sont
développées de manière incrémentielle ; où le
logiciel est livré par incréments courts et
rapides ; et où les modifications des
exigences et du logiciel sont la norme.
 Comme tout autre processus de
développement logiciel professionnel, le
développement agile doit être géré de
manière à utiliser au mieux le temps et les
ressources disponibles pour l'équipe.
 Cela nécessite une approche différente de la

gestion de projet, adaptée au développement

incrémental et aux atouts particuliers des
méthodes agiles.
 L'approche Scrum est une méthode agile générale mais elle se
concentre sur la gestion du développement itératif plutôt que
sur des approches techniques spécifiques à l'ingénierie
logicielle agile.
 La figure 6.3 est un schéma du processus de gestion Scrum.
Scrum ne prescrit pas l'utilisation de pratiques de
programmation telles que la programmation en binôme et le
développement test-first.
 Il peut donc être utilisé avec des approches agiles plus
techniques, telles que XP, pour fournir un cadre de gestion pour
le projet.
 Il y a trois phases dans Scrum:
 La première est une phase de planification générale où vous
établissez les objectifs généraux du projet et concevez
l'architecture logicielle.
 Ceci est suivi d'une série de cycles de sprint,
où chaque cycle développe un incrément du
système.
 Enfin, la phase de clôture du projet conclut le

projet, complète la documentation requise

telle que les cadres d'aide du système et les
manuels d'utilisation, et évalue les
enseignements tirés du projet.
 La caractéristique innovante de Scrum est sa
phase centrale, à savoir les cycles de sprint.
 Un sprint Scrum est une unité de planification

dans laquelle le travail à faire est évalué, les

fonctionnalités sont sélectionnées pour le
développement et le logiciel est implémenté.
 À la fin d'un sprint, la fonctionnalité terminée

est livrée aux parties prenantes.

 Les principales caractéristiques de ce processus sont
les suivantes :
 1. Les sprints sont de durée fixe, normalement de 2 à
4 semaines. Ils correspondent au développement
d'une version du système sous XP.
 2. Le point de départ de la planification est le backlog
du produit, qui est la liste des travaux à effectuer sur
le projet. Au cours de la phase d'évaluation du sprint,
cela est examiné et les priorités et les risques sont
attribués. Le client est étroitement impliqué dans ce
processus et peut introduire de nouvelles exigences
ou tâches au début de chaque sprint.
 3. La phase de sélection implique toute
l'équipe de projet qui travaille avec le client
pour sélectionner les fonctionnalités et
fonctionnalités à développer pendant le
sprint.
 4. Une fois celles-ci acceptées, l'équipe

s'organise pour développer le logiciel. De

courtes réunions quotidiennes impliquant
tous les membres de l'équipe sont organisées
pour examiner les progrès et, si nécessaire,
redéfinir les priorités du travail.
 Au cours de cette étape, l'équipe est isolée
du client et de l'organisation, toutes les
communications passant par le « Scrum
master ». Le rôle du Scrum master est de
protéger l'équipe de développement des
distractions externes.
 5. À la fin du sprint, le travail effectué est

examiné et présenté aux parties prenantes.

Le cycle de sprint suivant commence alors.
 L'idée derrière Scrum est que toute l'équipe
devrait être habilitée à prendre des décisions,
de sorte que le terme « chef de projet » a été
délibérément évité.
 Le « Scrum master » est plutôt un facilitateur

qui organise des réunions quotidiennes, suit

l'arriéré de travail à effectuer, enregistre les
décisions, mesure les progrès par rapport à
l'arriéré et communique avec les clients et la
direction en dehors de l'équipe.
Mise à l'échelle des méthodes agiles
 Les méthodes agiles ont donc été
principalement utilisées pour le développement
de systèmes de petite et moyenne taille.
 La nécessité d'une livraison plus rapide des
logiciels qui soient plus adaptés aux besoins
des clients, s'applique également aux systèmes
plus importants.
 Par conséquent, il y a eu un grand intérêt pour
la mise à l'échelle des méthodes agiles pour
faire face à des systèmes plus grands,
développés par de grandes organisations.
 Le développement de grands systèmes
logiciels diffère du développement de petits
systèmes à plusieurs égards :
 1. Les grands systèmes sont généralement

des ensembles de systèmes distincts et

communicants, où des équipes distinctes
développent chaque système. Fréquemment,
ces équipes travaillent dans des endroits
différents, parfois dans des fuseaux horaires
différents.
 2. Les grands systèmes sont des « systèmes
de friches industrielles », c'est-à-dire qu'ils
incluent et interagissent avec un certain
nombre de systèmes existants.
 De nombreuses exigences système sont
concernées par cette interaction et ne se
prêtent donc pas vraiment à la flexibilité et au
développement incrémentiel.
 la solution la plus simple à un problème
consiste à modifier un système existant.
Cependant, cela nécessite une négociation
avec les gestionnaires de ce système pour les
convaincre que les changements peuvent être
mis en œuvre sans risque pour le
fonctionnement du système.
 3. Lorsque plusieurs systèmes sont intégrés
pour créer un système, une fraction
importante du développement concerne la
configuration du système plutôt que le
développement du code original.
 Ceci n'est pas nécessairement compatible

avec un développement incrémental et une

intégration fréquente du système.
 4. Les grands systèmes et leurs processus de
développement sont souvent contraints par des
règles et réglementations externes limitant la
manière dont ils peuvent être développés,
nécessitant la production de certains types de
documentation du système, etc.
 5. Les grands systèmes ont un long temps
d'approvisionnement et de développement. Il est
difficile de maintenir des équipes cohérentes qui
connaissent le système sur cette période car,
inévitablement, les gens passent à d'autres
emplois et projets.
 6. Les grands systèmes ont généralement un
ensemble diversifié de parties prenantes. Par
exemple, les infirmières et les
administrateurs peuvent être les utilisateurs
finaux d'un système médical, mais le
personnel médical supérieur, les directeurs
d'hôpitaux, etc. sont également des parties
prenantes du système.
 Il est pratiquement impossible d'impliquer

tous ces différents acteurs dans le processus

de développement.
 Il existe deux perspectives sur la mise à l’échelle
des méthodes agiles :
 1. Une perspective de « mise à l'échelle », qui
concerne l'utilisation de ces méthodes pour
développer de grands systèmes logiciels qui ne
peuvent pas être développés par une petite
équipe.
 2. Une perspective de « mise à l'échelle », qui
concerne la manière dont les méthodes agiles
peuvent être introduites dans une grande
organisation avec de nombreuses années
d'expérience en développement de logiciels.
 Bien que les méthodes agiles doivent être
adaptées pour faire face à l'ingénierie des
grands systèmes, il est essentiel de maintenir
les principes fondamentaux des méthodes
agiles: planification flexible, versions
fréquentes du système, intégration continue,
développement piloté par les tests et bonnes
communications d'équipe.
 Les adaptations critiques à introduire sont les
suivantes :
 1. Pour le développement de grands systèmes, il
n'est pas possible de se concentrer uniquement
sur le code du système. Vous devez faire plus de
conception initiale et de documentation du
système.
 L'architecture logicielle doit être conçue et une
documentation doit être produite pour décrire les
aspects critiques du système, tels que les schémas
de base de données, la répartition du travail entre
les équipes, etc.
 2. Des mécanismes de communication entre les
équipes doivent être conçus et utilisés. Cela
devrait impliquer des conférences téléphoniques
et vidéo régulières entre les membres de l'équipe
et des réunions électroniques fréquentes et
courtes où les équipes se tiennent mutuellement
au courant des progrès.
 Une gamme de canaux de communication tels que
le courrier électronique, la messagerie
instantanée, les wikis et les systèmes de réseaux
sociaux doivent être fournis pour faciliter les
communications.
 3. L'intégration continue, où l'ensemble du
système est construit à chaque fois qu'un
développeur vérifie un changement, est
pratiquement impossible lorsque plusieurs
programmes distincts doivent être intégrés pour
créer le système. Cependant, il est essentiel de
maintenir des versions fréquentes du système et
des versions régulières du système. Cela peut
signifier que de nouveaux outils de gestion de
configuration prenant en charge le
développement de logiciels multi-équipes doivent
être introduits.