Les méthodologies de conception

Une méthodologie de conception s’intègre généralement dans un modèle de processus de

développement logiciel (Software développent life cycle: SDLC)

Un SDLC est un ensemble de phases (événement), d’activités et de rôles (compétences) qui ont
comme objectif la production d’un logiciel

Plusieurs modèles de processus existent selon des approches(logiques) différentes:

Approche linéaire

Modèle en cascade(etape par etape

Le prototypage :le prototypage est très intéressant dans la collecte et l’analyse des besoins
utilisateur.Le client apportera ses critiques et suggestions par rapport au prototype jusqu’à
atteindre la stabilité des besoins du client

Approche incrémentale et itérative

Le modèle incrémental & incrémental

Il se base sur le développement d’une version initiale du système qui sera présentée
aux utilisateurs et de la faire évoluer progressivement jusqu’à atteindre la version
adéquate

Approche incrémentale :(tabda mel fekraaa wba3id tabda bel partie bel partie fi développement)

Approche itérative (n9asmou en forme de partie par example kol partie ta3mel specification
/conception w implementation wba3id déploiement )

 Activités du modèle
• Le plus prioritaire sera placé en haut et vise versaa
• La taille et la complexité des incréments dépendra du degré d’urgence pour le
client.
 Identification des besoins techniques de l’incrément N
 Développement de l’incrément

Approche Agile

Il s’agit d’un processus itératif et incrémental qui vise à éliminer les inconvénients des
approches séquentielles

 La cohésion d'une équipe est plus importante que le suivi des conventions
 Le client et le fournisseur sont des partenaires qui partagent un risque. L’agilité vise la
collaboration des deux parties pour atteindre un objectif commun.
 La planification originale ne doit pas être trop détaillée, car certains aspects ne seront
probablement jamais réalisés.
 Rational Unified Process

RUP est un processus de développement logiciel itératif et incrémental, centré sur l'architecture,
piloté par des cas d'utilisation et orienté vers la diminution des risques.

Objectif : Produire un logiciel de qualité qui satisfait les besoins des utilisateurs avec un
budget et un planning prédéfini.

Les Bonnes pratiques de RUP :

1. Développement
 Permet la prise en charge en continue des changements. L’intégration se fait
à chaque itération : pas d’effet
 Permet d’aboutir à une architecture solide puisque cette dernière est révisée
à chaque itération.
2. Management des besoins utilisateurs
 La mesure de la qualité d'un produit passe essentiellement par la question
"Est ce que le système réalise ce qui est sensé réalisé"
 Le management des besoins favorise le partage des connaissances entre les
différentes partie-prenantes.

3.Utilisation d'architecture à base de composants Méthodologie de conception

 L'architecture inclue les aspects suivants

 L'organisation du système.
 L'interface entre les éléments qui composent le système.
 Le comportement des éléments. Dans une architecture modulaire, les
composants sont identifiés, conçus, développés et testés, l'intégration des
modules se fera progressivement pour former tout le système

4.Modélisation visuelle avec UML

 La Méthodologie de conception modélisation visuelle facilite la compréhension

et la maîtrise du système. Les activités de spécification, conception et
implémentation sont simplifiés par des l’utilisation de modèles
 Class Diagrams/ use-case Diagrams…

5.Vérification continue de la qualité

 L'évaluation se fait par les tests et non à base de documents. Les défauts dont
identifiés tôt dans le projet d'où la réduction des risques.

6. Gestion des changements

 il s'agit de suivre Méthodologie de conception - S. BEJI minutieusement le

changement des spécifications, conception et implémentation.
RUP est piloté par les cas d’utilisation :
Les cas d’utilisation constituent une référence pour:

 Les unités de développement: chaque incrément doit implanter un

nombre de cas d’utilisation.
 Les unités de test
 Les unités de réutilisation.

RUP est incrémental

 Le produit final est livré en incréments
 Chaque incrément doit être de courte durée
 L’incrément doit être totalement exploitable.

Les axes de RUP  :

Axe vertical représentant les composantes, c’est l’axe statique.
Axe horizontal qui représente essentiellement les phases et les 23 itérations, c’est l’axe
dynamique
Les composantes de RUP
Rôle est le qui : Chef de projet, Analyste, Testeur, Utilisateur, etc.
Artéfact est le quoi : Document de l’architecture, Modèle des cas d’utilisation, Fichier
exécutable, etc. Méthodologie de conception
Activité est le comment : Analyse de cas d’utilisation, Conception de cas d’utilisation, etc.
Enchaînement d’activités(Workflow ) est le quand : Modélisation de métier, implémentation,
test, etc. Discipline: le containeur des éléments précédents
Les rôles de RUP

 Rôles d'analyse
 Méthodologie de conception
 Rôles de développement
 Rôles de test
 Rôles de manager
 Rôles de production et support
Les activités dans RUP
Un rôle réalise une ou plusieurs activités.
Définition Une activité est une unité de travail qu'un individu appartenant à un rôle est
sensé assurer, et qui produit un résultat significatif dans le contexte Méthodologie de
conception est sensé assurer, et qui produit un résultat significatif dans le contexte d'un
projet
Exemples
Planifier les itérations -> Project Manager
Trouver les acteurs et les cas d'utilisation Méthodologie de conception -> System analyst
Revue de la conception -> Design reviewer
Exécuter un test de performance -> Performance tester

Les artéfacts
Définition Les activités ont comme input et output des artifacts. Un artifact est un fragment
d'information qui est produit, modifié ou utilisé par un processus. Examples : Un modèle
comme un use-case diagram. Un élément de modèle comme une Méthodologie de conception
classe, un acteur etc

Les workflows
Définition Un workflow est une séquence d'activités décrivant l’interaction entre des rôles et
produisant un résultat ayant une valeur ajoutée

. Dans le langage UML, un workflow peut être décrit avec un diagramme de séquence, un diagramme
d'activités ou un diagramme de collaboration.

Chapitre 6 : Les processus Agile

1. Définition

Il s’agit d’un processus itératif et incrémental qui vise à éliminer les inconvénients des
approches séquentielles.
• Une approche Agile doit augmenter la satisfaction du client et faciliter l’activité du
développement.

2. Caractéristiques
Adaptatives

 Favorable aux changements

• Planification plus souple

Orientées personnes

• Travailler avec les spécificités de chacun

• Responsabilité
3. Fondements des méthodes Agile: manifeste Agile
 La cohésion d'une équipe est plus importante que le suivi des conventions
 Un logiciel partiellement fonctionnel, est toujours plus valable qu’une
documentation soignée
 Le client et le fournisseur sont des partenaires qui partagent un risque. L’agilité vise
la collaboration des deux parties pour atteindre un objectif commun.

Le manifeste Agile
 Notre plus haute priorité est de satisfaire le client en livrant rapidement et régulièrement
des fonctionnalités à grande valeur ajoutée.
 Accueillir positivement les changements de besoins, même tard dans le projet. Les
processus Agiles exploitent le changement pour donner un avantage compétitif au client.
 Livrer fréquemment un logiciel opérationnel avec des cycles de quelques semaines à
quelques mois Méthodes Agile et une préférence pour les plus courts.
 Réalisez les projets avec des personnes motivées.
 Fournissez-leur l’environnement et le soutien dont ils ont besoin et faites-leur confiance pour
atteindre les objectifs fixés.
 La méthode la plus simple et la plus efficace pour transmettre de l’information à l'équipe de
développement et à l’intérieur de celle-ci est le dialogue en face à face.

• Les processus Agiles encouragent un rythme de développement soutenable.

• La simplicité – c’est-à-dire l’art de minimiser la quantité de travail inutile – est essentielle

Contraintes s’opposant à l’application de l’agilité

 L’équipe est très attachée aux anciennes pratiques
 .Difficulté de collaborer avec le client.
 Projet très complexe.
 Non disponibilité de personnel avec des compétences Agile.

Conclusion
•Agile est un ensemble de recommandations visant à rendre le développement
logiciel plus efficace. Un grand projet qui va durer dans le temps sera divisé en petit s
fragments à livrer périodiquement
•L’agilité est un ensemble de techniques et de « best practises » plus qu’une
méthodologie à part entière
•Agile se base sur les valeurs telles que: communication, confiance, compétence
beaucoup plus que la documentation et les deadlines.
 Chapitre 7 :Introduction à Scrum
Scrum est :
Un cadre de travail permettant de répondre à des problèmes complexes
etchangeants, tout en livrant de manière productive et créative des produits
logiciels de la plus grande valeur possible.
Scrum n’est pas :
processus ni une méthode de développement de produit logiciel.
II. La théorie de Scrum
Transparence : Les aspects importants du processus doivent être visibles à
ceux qui sont responsables des retombées.
Inspection : Les utilisateurs Scrum doivent en permanence surveiller l’état
d’avancement par rapport à l’objectif de l’itération.
La fréquence de ces inspections ne devrait pas gêner le travail en
cours.
Adaptation
Si un inspecteur détermine qu’un ou plusieurs aspects du processus dérivent
hors des limites acceptables, un ajustement doit être fait dès que possible afin
de minimiser le risque d’autres dérives
III. Les rôles Scrum
Le Product Owner est responsable de maximiser la valeur du produit et du
travail de l’Équipe de Développement.
Le product owner représente le client et doit défendre le produit.
Définir les Ordonner les Optimiser la besoin est visible,
besoins besoins pour valeur du travail transparent, et
du produit et mieux réaliser effectué par clair pour tous, et
rédige les les l’Équipe de qu’il montre ce
spécifications objectifs et Développement sur quoi l’Équipe
missions de Développement
travaillera
prochainement
III.2 Scrum Master
C’est la personne chargée de lever tout obstacle pouvant freiner l’évolution
du travail de l’équipe de développement, il s’agit d’un facilitateur.
S’assurer de la devant l’équipe Optimiser la
bonne valeur du travail
application de de effectué par
la méthode l’Équipe de
développement Développement

III.3 Development Team.

Ce sont les personnes chargées de la réalisation du sprint et d'un produit
utilisable en fin de sprint. Il peut s'agir de développeurs, architectes,
personnes chargées de faire des tests fonctionnels etc.
IV. Fonctionnement de Scrum
Le sprint :Durant chaque sprint, une version potentiellement livrable du
produit est créée(release).
Contenu du release
 Le contenu ne doit pas changer durant l’itération.
 Les fonctionnalités reportées doivent être réinjectées dans le Product backlog
 Un release intégre des éléments hétérogénes :modules,technique,user story
 Le contenu ne doit pas changer durant l’itération.
 Les fonctionnalités reportées doivent être ré- injectées dans le Produc Backlog.


Release 0

• Sert à configurer l’environnement de développement /Choisir le socle technique

/Implémenter les tâches à automatiser /Sert à initialiser le développement / Mettre en place
une infrastructure initiale
 Durée des sprints
Short sprint

• Implique un retour rapide de la part des clients

• Peut donner lieu à des “death sprint” donc mauvaise qualité logicielle Long sprint

Long sprint

• Difficile à planifier

•Risque de changement chez le “product owner”

• Tendance à évoluer dans un modèle en cascade

V. Les événements Scrum

Le sprint planning Le daily scrum Le sprint review Le sprint retrospective

Réunion déterminante pour la
réussite du sprint
• A comme input les items du
Product Backlog.
• A comme input les items du
Product Backlog
. • Identifie les items à inclure
dans le sprint.
• Identifier l’objectif global
du sprint.
Un événement limité à 15
minutes au cours duquel Un
événement limité à 15 minutes
au cours duquel l’Équipe de
Développement synchronise ses
activités et crée un plan pour les
prochaines 24 heures
C’est la réunion tenue à la Il s’agit d’ une
fin du sprint occasion pour l'Équipe
• Son objectif est Scrum de s'inspecter
d’inspecter le sprint et et de créer un plan
d’adapter le Product d'amélioration qui
Backlog sera mis en place au
• Elle dure 4 Heures pour cours du Sprint suivant
un sprint de 1 Mois
• L’équipe Scrum et les
parties prenantes
(stakeholders) y
participent.

Le Product Backlog
 Une liste triée par ordre de priorité de tâches et/ou de besoins.
 Les bugs, améliorations, changements sont tous pris en charge comme des
éléments dans le product Backlog (pas uniquement les besoins fonctionnels).