Processus de Développement Cycle de vie d’un logicielimad-hafidi.com/Cours/Genie/PD2.pdfCycle de vie La qualité du processus de fabrication est garante de la qualité du produit

Processus de DéveloppementCycle de vie d’un logiciel

Deuxième partie

Cycle de vie

Processus

Hafidi Imad-ENSAK-Cours PD1

Pr Hafidi Imad [email protected]

Deuxième partie

Cycle de vieLa qualité du processus de fabrication est garante

de la qualité du produit.� Pour obtenir un logiciel de qualité, il faut en maîtriser le

processus d'élaboration.La vie d'un logiciel est composée de différentes étapes.


� 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.

Etapes de développements� Étude de faisabilité

� Spécification� Déterminer les fonctionnalités du logiciel.

� Conception� Déterminer la façon dont le logiciel fournit les différentes


� Déterminer la façon dont le logiciel fournit les différentes fonctionnalités recherchées.

� Codage

� Tests� Essayer le logiciel sur des données d'exemple pour s'assurer

qu'il fonctionne correctement.

� Maintenance

Étude de Faisabilité� Déterminer si le développement propose vaut la peine d‘être

mis en ouvre, compte tenu des attentes et de la difficulté de développement

� Etude de marche : déterminer s'il existe un marche potentiel pour le produit.


pour le produit.

Spécification� Déterminer les fonctionnalités que doit posséder le logiciel

� Collecte des exigences : obtenir de l'utilisateur ses exigences pour le logiciel

� Analyse du domaine : déterminer les tâches et les structures qui se répètent dans le problème


se répètent dans le problème

Organisation du projet� Déterminer comment on va développer le logiciel

� Analyse des coûts : établir une estimation du prix du projet� Planification : établir un calendrier de développement� Assurance qualité du logiciel : déterminer les actions qui

permettront de s'assurer de la qualité du produit fini


permettront de s'assurer de la qualité du produit fini� Répartition des tâches : hiérarchiser les tâches et sous-tâches

nécessaires au développement du logiciel

Conception� Déterminer la façon dont le logiciel fournit les différentes

fonctionnalités recherchées :

� Conception générale� Conception architecturale : déterminer la structure du système� Conception des interfaces : déterminer la façon dont les


� Conception des interfaces : déterminer la façon dont les différentes parties du système agissent entre elles

� Conception détaillée : déterminer les algorithmes pour les différentes parties du système

Implémentation� Ecrire le logiciel


Tests� Essayer le logiciel sur des données d'exemple pour s'assurer qu'il

fonctionne correctement� Tests unitaires : faire tester les parties du logiciel par leurs

développeurs� Tests d'intégration : tester pendant l'intégration� Tests de validation : pour acceptation par l'acheteur


� Tests de validation : pour acceptation par l'acheteur� Tests système : tester dans un environnement proche de

l'environnement de production� Tests Alpha : faire tester par le client sur le site de développement� Tests Bêta : faire tester par le client sur le site de production� Tests de régression : enregistrer les résultats des tests et les comparer

a ceux des anciennes versions pour vérifier si la nouvelle n'en a pas dégrade d'autres

Livraison� Fournir au client une solution logicielle qui fonctionne

correctement� Installation : rendre le logiciel opérationnel sur le site du client� Formation : enseigner aux utilisateurs a se servir du logiciel� Assistance : répondre aux questions des utilisateurs


� Assistance : répondre aux questions des utilisateurs

Maintenance� Mettre a jour et améliorer le logiciel pour assurer sa

pérennité

� Pour limiter le temps et les coûts de maintenance, il faut porter ses efforts sur les étapes antérieures


Documents courants


Cahier de charge� Description initiale des fonctionnalités désirées,

généralement écrite par l'utilisateur


spécification� Décrit précisément les conditions que doit remplir le logiciel

� Modèle objet : indique les classes et les documents principaux

� Scenarios des cas d'utilisation : indique les différents enchaînements possibles du point de vue de l'utilisateur


enchaînements possibles du point de vue de l'utilisateur

Calendrier du projet� Ordre des différentes tâches

� Détails et ressources qu'elles demandent


Plan test du logiciel� Décrit les procédures de tests appliquées au logiciel pour

contrôler son bon fonctionnement

� Tests de validation : tests choisis par le client pour déterminer s'il peut accepter le logiciel


Plan d’assurance qualité� Décrit les activités mises en ouvre pour garantir la qualité du

logiciel


Manuel d’utilisateur� Mode d'emploi pour le logiciel dans sa version finale


Code source� Code complet du produit fini


Rapport des tests� Décrit les tests effectues et les réactions du système


Rapport des défauts� Décrit les comportements du système qui n'ont pas satisfait

le client

� Il s'agit le plus souvent de défaillances du logiciel ou d'erreurs


Documents produits dans le cycle de vie

Documents Cycle de vie

Manuel utilisateur final Implémentation

Conception Architectural Conception

Pan d’assurance qualité Planification

Code source Implémentation

Cahier de charge Faisabilité


Cahier de charge Faisabilité

Plan de test Spécification

Manuel d’utilisateur préliminaire Spécification

Conception détaillé Conception

Estimation des coûts Planification

Calendrier du projet Planification

Rapport des tests Test

Documentation Implémentation

Modèles de cycle de vie d’un logiciel


Procédé logiciel� Un procédé logiciel (software process) est un ensemble

d’activités conduisant à la production d’un logiciel

� Ils sont aussi appelés cycle de vie d’un logiciel (SDLC)

� Un procédé définit les étapes qui le composent ainsi que leur enchaînement enchaînement

� Les Cycles de vie de logiciels sont complexes et dépendent fortement des acteurs qui dirigent les activités

� Les activités des procédés ne peuvent être automatisées .Il y a des outils de support, appelés outils CASE (Computer-AidedSoftware Engineering)

24 Hafidi Imad-ENSAK-Cours PD

Modèles de procédés� Un modèle de procédé est une abstraction d’un procédé

� Un modèle décrit le procédé selon une certaine perspective

� Un procédé logiciel est une application d’un modèle pour un projet spécifique, qui peut inclure une certaine adaptation


Modèles de procédés pourquoi� Pour maîtriser les gros projets

� Pour découper le projet et affecter correctement les tâches

� Pour anticiper et gérer les risques


Modèles de procédés� Il existe deux types de modèles de procédés :

Méthodes classiquesclassiques

Méthodologie Agiles


Modèles de procédés

Caractéristiques

Méthodes classiques •Modèles stricts •Etapes très clairement définies •Documentation très fournie •Fonctionne bien avec les gros projets


Méthodologie agiles •Modèles incrémentaux et itératifs •Petites et fréquentes livraisons •Accent sur le code et moins sur la documentation •Convient aux projets de petite et moyenne taille

Choix d’un modèle� Aucun modèle n’est meilleur que l’autre

� Le choix se fait selon certains critères tels que la nature du projet, sa taille, la nature du client et les compétences de l’équipe


Cycles de vie classiques


Modèle en cascade� L’un des premiers modèles proposés, inspiré du modèle de

Royce (1970)

� Aussi appelé modèle linéaire

� Le résultat de chaque phase est un ensemble de livrables,

� Une phase ne peut démarrer que si la précédente est finie


� Une phase ne peut démarrer que si la précédente est finie

� Le modèle académique par excellence


� Avantages :

� Facile à utiliser et à comprendre

� Un procédé structuré pour une équipe inexpérimentée

� Idéal pour la gestion et le suivi de projets

Fonctionne très bien quand la qualité est plus importante que


� Fonctionne très bien quand la qualité est plus importante que les coûts et les délais

� Inconvénients :

� Les besoins des clients sont très rarement stables et clairement définis

� Sensibilité aux nouveaux besoins : refaire tout le procédé

� Une phase ne peut démarrer que si l’étape précédente est


� Une phase ne peut démarrer que si l’étape précédente est finie

� Le produit n’est visible qu’à la fin

� Les risques se décalent vers la fin

� Très faible implication du client

� Quand l’utiliser ?

� Quand les besoins sont connus et stables

� Quand la technologie à utiliser est maîtrisée

� Lors de la création d’une nouvelle version d’un produit existant


existant

� Lors du portage d’un produit sur une autre plateforme

Modèle en V� Variante du modèle en cascade qui fait l’accent sur la

vérification et la validation

� Le test du produit se fait en parallèle par rapport aux autres activités



� Avantages :

� Met l’accent sur lest tests et la validation et par conséquent, ça accroît la qualité du logiciel

� Chaque livrable doit être testable

� Facile à planifier dans une gestion de projets


� Facile à planifier dans une gestion de projets

� Facile à utiliser

� Inconvénients :

� Ne gère pas les activités parallèles

� Ne gère pas explicitement les changements des spécifications

� Ne contient pas d’activités d’analyse de risque


� Quand l’utiliser:

� Quand le produit à développer à de très hautes exigences de qualité

� Quand les besoins sont connus à l’avance

� Les technologies à utiliser sont connues à l’avance


� Les technologies à utiliser sont connues à l’avance

Prototypage Prototypage Prototypage Prototypage � Le projet se fait sur plusieurs itérations

� Les développeurs construisent un prototype selon les attentes du client

� Le prototype est évalué par le client

� Le client donne son feedback


� Le client donne son feedback

� Les développeurs adaptent le prototype selon les besoins du client

� Quand le prototype satisfait le client, le code est normalisé selon les standards et les bonnes pratiques

Ecouter le client


Développer le

prototype

Evaluer le prototype

� Avantages

� Implication active du client

� Le développeur apprend directement du client

� S’adapte rapidement aux changements des besoins

Progrès constant et visible


� Progrès constant et visible

� Une grande interaction avec le produit

� Inconvénients

� Le prototypage implique un code faiblement structuré

� Degré très faible de maintenabilité

� Le processus peut ne jamais s’arrêter

Très difficile d’établir un planning


� Très difficile d’établir un planning


� Quand les besoins sont instables et/ou nécessitent des clarifications

� Peut être utilisé avec le modèle en cascade pour la clarification des besoins


clarification des besoins

� Quand des livraisons rapides sont exigées

Modèle Incrémental Modèle Incrémental Modèle Incrémental Modèle Incrémental � Chaque incrément est une construction partielle du logiciel

� Trie les spécifications par priorités et les regroupent dans des groupes de spécifications

� Chaque incrément implémente un ou plusieurs groupes jusqu’à ce que la totalité du produit soit finie


jusqu’à ce que la totalité du produit soit finie


� Avantages

� Développement de fonctionnalités à risque en premier

� Chaque incrément donne un produit fonctionnel

� Le client intervient à la fin de chaque incrément

Utiliser l’approche « diviser pour régner »


� Utiliser l’approche « diviser pour régner »

� Le client entre en relation avec le produit très tôt

� Inconvénients

� Exige une bonne planification et une bonne conception

� Exige une vision sur le produit fini pour pouvoir le diviser en incréments

� Le coût total du système peut être cher


� Le coût total du système peut être cher


� Quand la plupart des spécifications sont connues à l’avances et vont être sujettes à de faibles évolutions

� Quand on veut rapidement un produit fonctionnel

� Pour des projets de longues durées


� Pour des projets de longues durées

� Pour des projets impliquant de nouvelles technologies

Modèle en spirale Modèle en spirale Modèle en spirale Modèle en spirale � Modèle itératif

� Des incréments sous forme de cycle

� À la fin de chaque cycle on détermine les objectifs du cycle suivant

� Chaque cycle est composé des même activités que du modèle


� Chaque cycle est composé des même activités que du modèle en cascade

� Inclut l’analyse de risque et le prototypage


Détermination des objectifs

� En terme de fonctionnalité, de performance, de coût,...etc.

� Déterminer les alternatives : développer, réutiliser, acheter, sous-traiter…etc.

� Contraintes : coûts, plannings, … etc.


� Contraintes : coûts, plannings, … etc.

Identification et évaluation de risques

� Etudier les alternatives de développement

� Identification des risques : technologie non maîtrisées, équipe peu expérimentée, planning trop serré, …etc.

� Evaluation des risques : voir si les risques peuvent impacter


� Evaluation des risques : voir si les risques peuvent impacter le projet et à quel degré

Développement et test

� Contient pratiquement la plupart des activités : conception, codage, test, … etc.

Planification de la prochaine itération


Planification de la prochaine itération

� Un planning de l’itération

� Un plan de tests

� Avantages

� Identification rapide des risques

� Impacts minimaux des risques sur le projet

� Fonctions critiques développées en premier

Feedback rapide du client


� Feedback rapide du client

� Une évaluation continue du procédé

� Inconvénients

� L’évaluation des risques peut prendre beaucoup de temps

� Le modèle est très complexe

� La spirale peut s’éterniser

Les développeurs doivent être réaffectés pendant les phases


� Les développeurs doivent être réaffectés pendant les phases de non-développement

� Les objectifs ne sont pas souvent faciles à formuler

� Quand est-ce que l’utiliser ?

� Quand le prototypage est exigé

� Quand le risque du projet est considérable

� Quand les spécifications ne sont pas stables

Pour les nouveaux produits


� Pour les nouveaux produits

� Quand le projet implique de la recherche et de l’investigation

Méthodologie Agiles


Historique� Au milieu des années 90, un groupe d’expert en Cycles de

vie de logiciels voulaient proposer de nouveaux modèles

� Les nouveaux modèles sont plus « légers » : moins de documentation et moins de contrôle sur le procédé

� Ces modèles s’adresse à des projets de petite ou moyenne


� Ces modèles s’adresse à des projets de petite ou moyenne taille avec une équipe réduite

� Ces modèles permettent de s’ajuster rapidement aux changements des spécifications tout en garantissant des livraisons fréquentes

� Ces modèles sont qualifiés de « modèles agiles »

Manifeste Agile� Réunion organisée par Kent Beck en Février 2001

� 17 personnalités, dont les créateurs de Crystal, Scrum, Adaptive Software Development, etc.


http://www.agilemanifesto.org/

� Nous cherchons de meilleures manières pour développer des logiciels en aidant les autres et en développant nous mêmes. À travers ce travail nous en sommes venus à valoriser :

Personnes et interaction plutôt que processus et outils


Personnes et interaction plutôt que processus et outils

Logiciel fonctionnel plutôt que documentation complète

Collaboration avec le client plutôt que négociation de contrat

Réagir au changement plutôt que suivre un plan

� En fait, bien que les éléments de droite soient importants, nous pensons que les éléments de gauche le sont encore plus.

Définition� Une tentative de définition, pourrait être :

« Une méthode agile est une approche itérative et incrémentale pour le développement de logiciel, réalisé de manière très collaborative par des équipes responsabilisées, appliquant un cérémonial minimal, qui


responsabilisées, appliquant un cérémonial minimal, qui produisent un logiciel de grande qualité dans un délai contraint, répondant aux besoins changeants des utilisateurs. »

� Avec ses valeurs et ses principes, on peut considérer l’agilité comme une nouvelle culture du développement.

Principes Agiles

Individus et interaction au lieu de processus et

outils

Logiciel fonctionnelle au lieu de documentation

massive


Collaboration client au lieu de négociation du

contrat

Réagir au changement au lieu de suivre un plan

INDIVIDUS ET INTERACTIONS AU LIEU DE PROCESSUS ET OUTILS

� Les collaborateurs sont la clé du succès � Les « seniors » échoueront s’ils ne collaborent pas en tant

qu’équipe � Un bon collaborateur n’est pas forcément un bon programmeur.


� Un bon collaborateur n’est pas forcément un bon programmeur. C’est quelqu’un qui travaille bien en équipe

� Une surabondance d’outils est aussi mauvaise que le manque d’outils

� Démarrer petit et investir peu au démarrage � Construire l’équipe c’est plus important que construire

l’environnement

LOGICIEL FONCTIONNEL AU LIEU DE DOCUMENTATION MASSIVE

� Un code sans documentation est un désastre

� Trop de documents est pire que pas de documents

� Difficulté à produire et à synchroniser avec le code


� Difficulté à produire et à synchroniser avec le code

� Souvent les documents sont des « mensonges » formels

� Le code ne ment jamais sur lui-même

� Produire toujours des documents aussi courts que possible

COLLABORATION DU CLIENT AU LIEU DE LA NÉGOCIATION DE CONTRATS

� Très difficile de décrire la totalité du logiciel depuis le début

� Les projets réussis impliquent les clients d’une manière fréquente et régulière


fréquente et régulière

� Le client doit avoir un contact direct avec l’équipe de développement

RÉAGIR AUX CHANGEMENTS AU LIEU DE SUIVRE UN PLAN

� Un logiciel ne peut pas être planifié très loin dans le futur � Tout change : technologie, environnement et surtout les besoins � Les chefs de projets classiques fonctionnent sur la base de

GANTT, PERT et le système de tâches, avec le temps, les


GANTT, PERT et le système de tâches, avec le temps, les diagrammes se dégradent car des tâches s’ajoutent et d’autres deviennent non nécessaires

� Une meilleure stratégie est de planifier très court (2 semaines à 1 mois)

� Plannings détaillés pour la semaine à venir, rigoureux pour les trois mois et très vagues au-delà

LES DOUZE PRINCIPES AGILES LES DOUZE PRINCIPES AGILES LES DOUZE PRINCIPES AGILES LES DOUZE PRINCIPES AGILES � 1.Toujours satisfaire le client à travers des livraisons rapides

et continues

� 2.Bien accueillir tous les changements même les tardifs

� 3.Livrer fréquemment un système fonctionnel

� 4.Les clients et les développeurs doivent collaborer


� 4.Les clients et les développeurs doivent collaborer

� 5.Conduire le projet autour d’équipes motivées

� 6.La meilleure méthode de faire circuler l’information c’est le contact direct entre collaborateurs

� 7.La première mesure d’avancement c’est un logiciel fonctionnel

� 8.Le développement doit être durable et à un rythme constant

� 9.La bonne conception et l’excellence technique augmentent l’agilité

� 10.Simplifier au maximum


� 10.Simplifier au maximum

� 11.Les meilleurs architectures, besoins et conceptions proviennent d’équipes qui s’organisent d’elles-mêmes

� 12.L’équipe s’améliore d’une manière autonome et régulière

Méthodes agiles


XP


Méthodologie XP� eXtreme Programming

� Crée en 1995 Kent Beck and Ward Cunningham

� XP est un moyen léger, efficace, à bas risques, flexible, scientifique et amusant de développer des logiciels

� Destinée à des équipes de moyenne taille avec des


� Destinée à des équipes de moyenne taille avec des spécifications incomplets et/ou vagues

� Le codage est le noyau de XP

Fondamentaux

Implication Massive du

client

Test unitaire continu


Programmation par paires

Itérations courtes et livraisons rapides

Principales Activités

Codage

(Noyau XP)

Tests(Pendant le codage)


Ecoute(Le client ou le partenaire)

Conception(encore basée sur le codage)

Cycle de vie XP


Modèle XP d’une itération de développement.


Les 12 pratiques1- LE JEU DE PLANNING :

� Le client et les développeurs décident quoi mettre dans la prochaine livraison en triant les spécifications par priorité

� L’estimation est la responsabilité du développeur, pas du chef de projet ni du client


de projet ni du client

2 – DE PETITES ET FRÉQUENTES LIVRAISONS :

� D’abord livrer un système minimaliste puis le faire évoluer à travers des versions à des délais très courts

3- LES MÉTAPHORES � Exprimer de manière naturelle et très simples des fonctions du

système � Le client et les développeurs doivent s’accorder sur les

métaphores


4 – CONCEPTION SIMPLE � Le système doit être conçu de la manière la plus simple possible

5 –TESTS � Les développeurs rédigent les tests unitaires d’une manière

continue, Le client rédige les tests d’acceptation des fonctionnalités,

6 – REFACTORING � Les développeurs améliorent continuellement le code tout en

veillant à le garder fonctionnel 7 – PROGRAMMATION PAR PAIRES

� La totalité du code est écrite par deux programmeurs sur une seule machine. L’un est appelé conducteur (driver) et l’autre


seule machine. L’un est appelé conducteur (driver) et l’autre navigateur. Les rôles s’inversent régulièrement.

8 - PROPRIÉTÉ COLLECTIVE � N’importe qui peut changer le code n’importe où dans le système

à n’importe quel moment 9 - 40 HEURES LA SEMAINE

� Le travail ne doit pas dépasser 40 heures par semaine

10 – intégration continue

� Construire le système à chaque fois qu’une tâche est terminée.

11 – Le client est sur site

� Le client est tout le temps présent avec l’équipe pour


� Le client est tout le temps présent avec l’équipe pour participer et répondre aux questions

12 – Les standards de codage

� À cause de la propriété collective, des standards (une charte de codage) doivent être établis et adhérés par l’équipe de développement

Rôles dans XP� Le programmeur a une double responsabilité de

conception technique et de codage, pour des raisons de maintenabilité du code. Il doit en effet construire son programme de façon à ce qu’il puisse évoluer facilement par modification ou ajout de spécifications.


par modification ou ajout de spécifications.

� Le rôle du client consiste à exprimer ses exigences, sous forme de scénarios (user stories) et en dialoguant avec les développeurs, et à écrire des jeux de tests fonctionnels qui seront utilisés lors de la recette.


� Le testeur aide le client à élaborer des jeux de test. Il peut intervenir dans les choix de conception pour éviter des options qui augmentent les difficultés de test, donc les risques de non détection d’erreur. Ce rôle délicat nécessite une bonne connaissance du métier et des


nécessite une bonne connaissance du métier et des compétences en développement. Il s’appuie le plus souvent sur des outils automatisés.

� Le tracker est le gestionnaire du temps. Il intervient notamment en début de chaque itération, lors de l’estimation, et ensuite il contrôle la progression par des échanges avec les développeurs. Cette tâche correspond à un pilotage opérationnel et quotidien . Le tracker n’a pas d’autorité hiérarchique.

Son rôle est de maintenir le souci du respect des engagements par


� Son rôle est de maintenir le souci du respect des engagements par son activité quotidienne, mais aussi de détecter d’éventuels problèmes suffisamment tôt pour alerter le coach ou le manager.

� Chaque matin, il anime une brève réunion, appelée standupmeeting car l’on reste debout, au cours de laquelle chaque développeur annonce ce qu’il va faire durant la journée et d’éventuelles difficultés auxquelles il se heurte.

� Le coach a un rôle de soutien technique des membres de l’équipe, notamment lors des premières itérations de livraison. Il peut recadrer certaines options de conception technique ou de codage, organiser des réunions de remue-méninges pour résoudre un


réunions de remue-méninges pour résoudre un problème ou demander des changements d’un binôme, en cas de blocage ou disfonctionnement.

� Le rôle du manager correspond à un rôle de chef de projet. Il est le responsable des développeurs, qu’il soutient et encourage. Il doit rendre des comptes au client sur la base des informations fournies par le coach et le tracker.


et le tracker.

Avantages� Implication active du client

� Forte réactivité des développeurs

� Responsabilisation et solidarité de l’équipe

� Appel aux meilleurs pratiques de développement

Souplesse extrême


� Souplesse extrême

Inconvénients� Demande une certaine maturité des développeurs

� La programmation par paires n’est toujours pas applicable

� Difficulté de planifier et de budgétiser un projet

� Stress dû aux devoir de l’intégration continue et des livraisons fréquentes


livraisons fréquentes

� La faible documentation peut nuire en cas de départ des développeurs

Méthodologie Scrum


Scrum� Inspiré par une approche développée en 1986 par H.

Takeuchii et II.. Nonaka, le terme « Scrum » utilisé dans « Wiicked Problems, Rightteous Solutions » par DeGrace et Stahl en 1991

� Utilisé comme méthodologie dans le livre : « Agile Software Developmentt with SCRUM” par K. Schwaber et M.. Beedlle


Developmentt with SCRUM” par K. Schwaber et M.. Beedlleen 2001

Définition� Scrum signifie mêlée au rugby. Scrum utilise les valeurs et l’esprit du

rugby et les adapte aux projets de développement. Comme le pack lors d’un ballon porté au rugby, l’équipe chargée du développement travaille de façon collective, soudée vers un objectif précis. Comme un demi de mêlée, le ScrumMaster aiguillonne les membres de l’équipe, les repositionne dans la bonne direction et donne le temps pour assurer la


repositionne dans la bonne direction et donne le temps pour assurer la réussite du projet.

PrincipesSimple

•Peut être combiné avec d’autres méthodes•

Compatible avec les best practices

Empirique

•Itérations courtes (sprints)

•Feedback continu

Techniques simples

•Sprints de 2 à 4 semainesEquipes


•Sprints de 2 à 4 semaines

•Besoins capturés en tant que user stories

Equipes

•Auto-organisation

•Multi-compétences

Optimisation

•Détection rapide des anomalies

•Organisation simple

•Requiert l’ouverture et la visibilité

Mécanique Scrum� Scrum sert à développer des produits, généralement en

quelques mois. Les fonctionnalités souhaitées sont collectées dans le backlog de produit et classées par priorité. C’est le Product Owner qui est responsable de la gestion de ce backlog.


backlog.

� Une version (release) est produite par une série d’itérations d’un mois appelées des sprints. Le contenu d’un sprint est défini par l’équipe, avec le Product Owner, en tenant compte des priorités et de la capacité de l’équipe. À partir de ce contenu, l’équipe identifie les tâches nécessaires et s’engage pour réaliser les fonctionnalités sélectionnées pour le sprint.

� Pendant un sprint, des points de contrôle sur le déroulement des tâches sont effectués lors des mêlées quotidiennes (scrums). Cela permet au ScrumMaster, l’animateur chargé de faire appliquer Scrum, de déterminer l’avancement par rapport aux engagements et d’appliquer, avec l’équipe, des ajustements pour


et d’appliquer, avec l’équipe, des ajustements pour assurer le succès du sprint.

� À la fin de chaque sprint, l’équipe obtient un produit partiel (un incrément) qui fonctionne. Cet incrément du produit est potentiellement livrable et son évaluation permet d’ajuster le backlog pour le sprint suivant


CYCLE DE DÉVELOPPEMENT SCRUM


Éléments


TimeBoxes� Scrum utilise des blocs de temps pour créer de la régularité.

Le cœur du rythme de Scrum est le sprint, une itération d’un mois ou moins. Dans chaque sprint, le cadre est donné par un cérémonial léger mais précis basé des réunions.

� Sprint est le terme utilisé dans Scrum pour itération. Dans le


� Sprint est le terme utilisé dans Scrum pour itération. Dans le langage Scrum, un sprint est un bloc de temps fixé aboutissant à créer un incrément du produit potentiellement livrable.

� Release peut avoir plusieurs sens :� Release comme version – Le dictionnaire du jargon

informatique français définit une release comme suit : « version d’un logiciel effectivement diffusée, donc lâchée dans la nature. Synonyme de « Mise sur le marché ». Exemple : Unix system V release. Cette définition énonce clairement qu’il y a des


release. Cette définition énonce clairement qu’il y a des versions qui ne constituent pas des releases.

� Release comme période de temps – Par extension, on appelle également released une release, mais l’usage en anglais, et maintenant en français, est d’utiliser release comme période de temps, notamment dans l’expression plan de release. la période de temps qui permet de la produire. On devrait dire le cycle de production

Sprints/Releases


Les sprints sont des itérations de durées fixes de une à quatre semaines. Chaque sprint représentant des fonctions à réaliser.

Aretefacts� Scrum exige peu d’artefacts lors du développement : le plus

remarquable est le backlog de produit, pivot des différentes activités.


Backlog du produit� Une équipe Scrum ne produit pas une documentation faite au

début du projet, qui décrit en détail toutes les spécifications fonctionnelles. Elle collecte les fonctions essentielles et les raffine progressivement. L’outil de collecte s’appelle le backlog de produit, c’est une liste dont les éléments sont


backlog de produit, c’est une liste dont les éléments sont rangés par priorité.

� Le backlog produit est un catalogue de toutes les fonctionnalités.

� Les éléments (Story) ne sont pas relatives à des utilisateurs (user), certaines sont à caractère technique

Story� Une des proposition de décrire un story est :


� Le backlog sert à communiquer : il est utilisé largement, car au carrefour de plusieurs activités :� la gestion de projet, car le backlog est la base pour la

planification ;� l’ingénierie des exigences, puisqu’on y collecte ce que doit faire

le produit ;


le produit ;� la conception et le codage des stories sélectionnées pour un

sprint ;� le test, qui permettra de s’assurer que les stories sont bien finies

dans un sprint.� Le blacklog peut changer au cours du projet(Ordre,

fonctionnalités) en fonction du feedback.

Backlog du sprint� Composées des items du backlog du produit sont choisis afin

de constituer ce sprint

� Chaque item est alors divisé en petites tâches constituant ainsi le backlog du sprint.


Rôles� L’équipe a un rôle capital dans Scrum : elle est constituée

avec le but d’optimiser la flexibilité et la productivité ; pour cela, elle s’organise elle-même et doit avoir toutes les compétences nécessaires au développement du produit. Elle est investie avec le pouvoir et l’autorité pour faire ce qu’elle


est investie avec le pouvoir et l’autorité pour faire ce qu’elle à faire.

Product owner� Le propriétaire (product owner) représente le client en ce

qui concerne les spécifications et les acceptations.

� Le rôle de Product Owner varie beaucoup avec le contexte de l’organisation, cependant il est possible d’identifier ses responsabilités majeures :


responsabilités majeures :

Scrum Master� Le scrum master est un capitaine d’équipe (Pas de chef du

projet), ses responsabilités générales sont les suivantes :� veiller à la mise en application de Scrum, par exemple en faisant

en sorte que les différentes réunions aient lieu et qu’elles se fassent dans le respect des règles ;


� encourager l’équipe à apprendre, et à progresser, en fonction du contexte du projet, dans les pratiques d’ingénierie ;

� faire en sorte d’éliminer les obstacles qui pourraient freiner l’avancement, par exemple en protégeant l’équipe des interférences extérieures pendant le déroulement d’un sprint ;

� inciter l’équipe à devenir autonome.

Avantages� Méthode très simple et très efficace

� Adoptée par les géants du marche : Microsoft, Google, Nokia..

� Orientée projet contrairement a XP qui est orientée développement


développement

� Peut inclure d’autres activité venant d’autres méthodologies (surtout XP)

Inconvénients� N’est pas 100% spécifique au GL

� Difficulté de budgétiser un projet


Métriques orientés objets


Problématique� Les logiciels sont de plus en plus conséquents, ce qui

implique un coût de revient élevé.

� Ces projets doivent évaluer au mieux le rapport coût -efficacité et répondre aux besoins de leurs clients.

� Une fois les projets mis en place, l'évolution du système doit


� Une fois les projets mis en place, l'évolution du système doit être en adéquation avec les progrès technologiques.

� Pour cela, il faut analyser les méthodologies, les outils de conception et de développement, et la maintenabilité du système.

� Ces caractéristiques sont quantifiées à l'aide des métriques.

Problématique : Code complexe

"Vous ne pouvez pas gérer ce que vous ne contrôlez pas, et vous ne pouvez pas contrôler ce que vous ne mesurez pas "

Pour avoir un code de haute qualité on a besoin d’utiliser un outil de métrique de haute qualité.


outil de métrique de haute qualité.

Définition� La métrique est un élément de mesure. Elle est basée sur une

théorie ensembliste et permet d'associer une pondération à un ensemble de données.

� Les approches sont multiples et variées. Elles peuvent être purement théorique ou davantage basées sur un savoir-faire empirique mais efficace.


empirique mais efficace.� La métrique (objet ou non) peut être perçue comme un outil

pour systématiser les tâches d'un ingénieur, qui, pour un projet de taille importante, est plus adapté que des choix arbitraires.

Métriques Objet de Chidamber et Kermer

� Ensemble de métriques (Metric Suite for Object OrientedDesign)� Evaluation des classes d'un système


� Evaluation des classes d'un système� La plupart des métriques sont calculées classe par classe� Le passage au global n'est pas clair, une moyenne n‘étant pas

très satisfaisante

M1 : Méthodes pondérées par class

� WMC : Weighted Methods per Class

avec C un ensemble de n classes comportant chacune Mi


avec C un ensemble de n classes comportant chacune Mi méthodes dont la complexité (le poids) est note ci

M2 : Profondeur de l'arbre d'héritage

� DIC : Depth of Inheritance Tree� Distance maximale entre un nœud et la racine de l'arbre

d'héritage de la classe concernée


d'héritage de la classe concernée� Calculée pour chaque classe

M3 : nombre d’enfants

� NOC : Number Of Children� Nombre de sous-classes dépendant immédiatement d'une classe

donnée, par une relation d'héritage


donnée, par une relation d'héritage� Calculée pour chaque classe

M4 : couplage entre les classes� Dans un contexte OO, le couplage est l'utilisation de

méthodes ou d'attributs d'une autre classe.� Deux classes sont couplées si les méthodes déclarées dans l'une

utilisent des méthodes ou instancie des variables définies dans l'autre


� Le relation est symétrique : si la classe A est couplée a B, alors B l'est à A

� CBO : Coupling Between Object classes� Pour chaque classe, nombre de classes couplées � Calculée pour chaque classe

M5 : Réponse pour une class (RFC)

� {RS} : ensemble des méthodes qui peuvent être exécutées en réponse a un message reçu par un objet de la classe, considérée� Réunion de toutes les méthodes de la classe avec toutes les


� Réunion de toutes les méthodes de la classe avec toutes les méthodes appelées directement par celles-ci

� Calculée pour chaque classe

RFG = |RS|

M6 : Manque de cohésion des méthodes� Un module (ou une classe) est cohésif lorsque tous ses

éléments sont étroitement lies

� LCOM (Lack of COhesion in Methods) tente de mesurer l'absence de ce facteur

� Posons


� Posons� Ii l'ensemble des variables d'instance utilisées par la méthode i� P l'ensemble les paires de (Ii ; Ij ) ayant une intersection vide� Q l'ensemble des paires de (Ii ; Ij ) ayant une intersection non

vide

� LCOM peut être visualise comme un graphe bi-partite� Le premier ensemble de nœuds correspond aux n différents


� Le premier ensemble de nœuds correspond aux n différents attributs et le second aux m différentes méthodes

� Un attribut est lie a une fonction si elle y accède ou modifie sa valeur

� L'ensemble des arcs est Q

� Il y a n m arcs possibles, et |P| = n x m - |Q|

Métriques MOOD� Ensemble de métriques pour mésuser les attributs des

propriétés suivantes :

� Encapsulation

� Héritage

� Couplage


� Couplage

� Polymorphisme

Encapsulation� MHF : Method Hiding Factor (10-30%)


Avec

� Md (Ci ) le nombre de méthodes déclarées dans une classe Ci

� Mh(Ci ) le nombre de méthodes cachées

� TC le nombre total de classes.

Encapsulation� AHF : Attribute Hiding Factor (70-100%)


Avec

� Ad (Ci ) le nombre d'attributs déclares dans une classe Ci

� Ah(Ci ) le nombre d'attributs caches

Facteurs d’héritage� MIF : Method Inheritance Factor (65-80%)


Avec� Mi (Ci ) le nombre de méthodes héritées (et non

surchargées) de Ci� Ma(Ci ) le nombre de méthodes qui peuvent être appelées

depuis la classe i

Facteurs d’héritage� AIF : Attribute Inheritance Factor (50-60%)


Avec

� Ai (Ci ) le nombre d'attributs herites de Ci

� Aa(Ci ) le nombre d'attributs auxquels Ci peut acceder

Facteur de couplage� CF : Coupling Factor (5-30%)

� Mesure le couplage entre les classes sans prendre en compte celui dû a l'héritage


Avec� client(Ci ; Cj ) = 1 si la classe i a une relation avec la classe j ,

et 0 sinon� Les relations d'héritage ne sont pas prises en compte dans les

relations

Facteur de polymorphisme� PF : Polymorphism Factor (3-10%)

� Mesure le potentiel de polymorphisme d'un système


Avec� Mo(Ci ) le nombre de méthodes surchargées dans la classe i� Mn(Ci ) le nombre de nouvelles méthodes dans la classe i� DC(Ci ) le nombre de descendants de la classe i

Etat actuelle � Utilisation des métriques demeure une pratique plutôt

marginale dans l’industrie

� Durant trente ans, des milliers de métriques ont été proposées

� Tous les concepts attachés aux métriques sont soit ambigus


� Tous les concepts attachés aux métriques sont soit ambigus ou, manquent de base théorique solide

Toutes ces ambiguïtés rendent difficile voir impossible la conception d’outils qui assisteraient dans le domaine des

métriques.