Upload
others
View
4
Download
0
Embed Size (px)
Citation preview
Projet de développementGénie logiciel
n Philippe Collet
n Master 1 Informatique – 2018-19n https://wiki.unice.fr/pages/viewpage.action?pageId=289482168
n Avec certains slides de Sébastien Mosser et Guilhem Molines
P. Collet 1
P. Collet 2
PROJETTechnique
Expertise
Acceptation
Client
Notion de cycle de vie
• Description d’un processus pour :– la création d ’un produit– sa distribution sur un marché– son retrait
• Cycle de vie et assurance qualité– Validation : le bon produit ?– Vérification : le produit correct ?
P. Collet 3
Les phases du cycle de vie
P. Collet 4
Objectifs
Définition des besoins
Analyse des besoins
Planification
Maintenance
Mise en exploitation
Qualification
Validation et Intégration
Implémentation et tests unitaires
Conception
Retrait ou remplacement
Modèle en cascade (1970)
P. Collet 5
Analyse des besoinsvérificationSpecif. fonctionnelles
vérificationPlanification
vérificationConceptionvérification
Implémentationtests unitaires
IntégrationtestsQualification
testsExploitation
Retrait
Changementdans l’expression
des besoins
vérification
Problèmes du modèle en cascade• Les vrais projets suivent rarement un développement
séquentiel• Établir tous les besoins au début d’un projet est difficile• Le produit apparaît tard• Seulement applicable pour les projets qui sont bien compris
et maîtrisés
P. Collet 6
Modèle en V
P. Collet 7
Qualification
F Gestion des configurations, de projet, plan assurance qualité
Conception globale
Intégration
Conceptiondétaillée
Testsunitaires
Programmation
Définition des tests
Définition du plan d ’intégration
Spécifications fonctionnelles& planification
Comparaison
• Le cycle en V–permet une meilleure anticipation–évite les retours en arrière
• Mais– le cadre de développement est rigide– la durée est souvent trop longue– le produit apparaît très tard
P. Collet 8
Prototypage
P. Collet 9
construire /améliorer
la maquetteÉcoute du
client
Le clientessaie
la maquette
Prototypage• 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
P. Collet 10
Prototypage (suite)
• Mais :– Les objectifs sont uniquement généraux– Prototyper n’est pas spécifier– Les décisions rapides sont rarement de bonnes
décisions– Le prototype évolutif donne-t-il le produit demandé ?– Les générateurs de code produisent-ils du code assez
efficace ?
F Projets petits ou à courte durée de vieP. Collet 11
Modèle incrémental
P. Collet 12
Analyse des besoinsvérificationSpécif. & Planification
vérificationConcept. globale
vérification
Exploitation
Retrait
Incrément Nconception détaillée, codage, tests uni., intégration, livraison
Le développement incrémental• 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
FLe premier incrément est souvent le noyauFLes incréments aident à gérer les risques
techniques (matériel non disponible)P. Collet 13
Modèle en spirale (Boehm, 1988)
P. Collet 14
Modèle en spirale (suite)
• Spécification : communiquer avec le client• Analyse de risque : évaluation des risques
techniques et des risques de gestion• Implémentation et vérification : construire,
tester, installer et fournir un support utilisateur• Validation: obtenir des retours• Planification : définir les ressources, la répartition
dans le temps
P. Collet 15
Modèle en spirale (suite)
• Couplage de la nature itérative du prototypage avec les aspects systématiques et contrôlés du modèle en cascade
• Les premières itérations peuvent être des modèles sur papier ou des prototypes
• Utilisation possible tout au long de la vie du produit
FRéduit les risques si bien appliquéFLes augmentent considérablement si le contrôle
faiblitP. Collet 16
2TUP : Two Track Unified Process
P. Collet 17
§ S’articule autour de l’architecture§ Propose un cycle de développement en Y§ Détaillé dans « UML en action »§ pour des projets de toutes tailles
Développement :Agilité ?
P. Collet 18
Ce qui NE marche PAS
• Des spécifications complètes en premier
• Commencer par coder sans aucune conception
19
Ce qui MARCHE
• Principe KISS: Keep It Simple, Stupid !– Procéder par incrément
• Impliquer le client• Classer les tâches par priorité• Faire des itérations courtes• Utiliser des tests unitaires
20
Simplicité, de bout en bout
P. Collet 21
Manifeste agile…• Idées de base
– Un produit ne peut pas être entièrement spécifié au départ– L’économie est trop dynamique: l’adaptation du processus s’impose.– Accepter les changements d’exigences, c’est donner un avantage
compétitif au client
• Privilégier :– L’interaction entre les personnes plutôt que les processus et les outils– le logiciel fonctionnel plutôt que la documentation pléthorique– la collaboration avec le client plutôt que la négociation de contrats– la réaction au changement plutôt que le suivi d’un plan
22
Plusieurs méthodes agiles
• XP : eXtreme Programming– Kent Beck, 1999 : focus sur la construction
• SCRUM : mêlée en rugby– Met l’accent sur la pratique des réunions
quotidiennes
• LEAN• ….
P. Collet 23
eXtreme Programming• Maximiser les activités qui apportent une réelle
valeur au logiciel
• Problèmes ciblés :– Défauts– Travail non terminé– Dérives
• (fonctionnalités jamais utilisées)– Multiplicité des tâches– Documentation pas à jour– Obsolescence
P. Collet 24
eXtreme Programming (XP…) : mise en oeuvre…
§ Ensemble de « Bests Practices » de développement(travail en équipes, transfert de compétences…)
§ plutôt pour des projets de moins de 10 personnes
4 Valeurs§ Communication§ Simplicité§ Feedback§ Courage
Scrum• Scrum est un processus agile qui vise à produire la plus grande
valeur métier dans la durée la plus courte. • Un logiciel qui fonctionne est produit à chaque sprint (toutes les 2 à
4 semaines).
• Le métier définit les priorités. • L'équipe s'organise elle-même pour déterminer la meilleure façon
de répondre aux exigences les plus prioritaires.
• A chaque fin de sprint, tout le monde peut voir fonctionner le produit courant et décider soit de le livrer dans l'état, soit de continuer à l'améliorer pendant un sprint supplémentaire.
26
Processus Scrum
27
Backlog du produit
• Les exigences du produit• Toutes (Idées, fonctionnalités, Epic, Thème,
etc.)• Exprimées en User Stories • Le Product Owner le maintient organisé• Toujours estimé et avec les priorités
28
User Stories, Epic…
29
SPRINT
RELEASE
FUTUR
User story et tâche ???
• Système
30
Une tâche ?
• Une tâche -> heure(s)• Un commit -> minute(s)
31
Le découpage ?
• Interface graphique / interface externe
• Client
• Back-end
32
Un système bien intégré ? Complet ?
33
Vraiment ?
34
User Story
• Une ou deux phrases résument ce que veut l’utilisateur
• Décrit comment le système est sensé travailler• Ecrite sur une carte• Contient suffisamment de détails pour
pouvoir être estimée
35
User story : en fiche
• Au Recto : – Fonctionnalité exigée
sous la forme d’un «récit utilisateur»,
– Sa priorité attribuée par l’utilisateur et
– Le temps estimé par l’équipe pour sa réalisation.
36
User story : en fiche• Au Verso : – conditions
d’acceptation définies par l’utilisateur
– niveau de risque (optionnel)
– modifications de la demande (optionnel)
37
Bonne « story » : testable ?Principe SMART• Spécifique - défini et explicite• Mesurable - quantifiable et mesurable• Atteignable - qui peut être réalisé et validé• Relevant - pertinent pour la story• Temporaire - limité dans le temps
• Facilite la rédaction des critères d’acceptation
38
Découpage vertical idéal
• Interface graphique / interface externe
• Client
• Back-end
39
Comment ?…
40
Attention, faites simple mais pas simpliste
Verticalité : 1. Epics
41
Verticalité : 2. Stories / features
42
Bonne « story » : quelle taille ?
• Des petites user stories pour un futur proche• Macro (Epic) pour les prochaines
• Les user stories sont progressivement affinées dans le temps, plus elles s’approchent de la fin
• Deux types de grandes user stories– Les user stories complexes : intrinsèquement grande et sans
possibilités de les réduire
– Les user stories combinées : Plusieurs user stories combinées en une seule
P. Collet 43
On essaye ?• Description du problème Comparer deux mains de poker saisie sur l’entrée standard, déterminer laquelle est la plus forte et afficher ce résultat. • Description des règlesUne main de poker comprend 5 cartes tirées d’un seul jeu de 52 cartes. Chaque carte à une couleur, Trèfle, Carreau, Coeur, Pique (dénotée Tr, Ca, Co, Pi) et une valeur parmi 2, 3, 4, 5, 6, 7, 8, 9, 10, valet, dame, roi, as (dénotée 2, 3, 4, 5, 6, 7, 8, 9, 10, V, D, R, A). Pour le calcul du score, toutes les couleurs ont le même niveau, par exemple l’as de carreau n’est pas battu par l’as de pique, ils sont égaux. Les valeurs sont ordonnées comme définies précédemment, le 2 étant la plus petite valeur et l’as la plus grande.
Plus haute carte : les mains qui ne correspondent à aucune autre catégorie sont classées par la valeur de leur plus haute carte. Si les plus hautes cartes ont la même valeur, les mains sont classées par la plus haute suivante et ainsi de suite.Paire : 2 des 5 cartes de la main ont la même valeur. Deux mains qui contiennent une paire sont classées par la valeur des cartes formant la paire. Si les valeurs sont les mêmes, les mains sont classées par les cartes hors de la paire, en ordre décroissant.Deux paires : La main contient deux paires différentes. Les mains qui contiennent deux paires sont classées par la valeur de la paire la plus élevée. Deux mains avec la paire la plus élevée de même valeur sont classées par l’autre paire. Si ces valeurs sont les mêmes, les mains sont classées par la valeur de la carte restante.Brelan, Suite , Couleur, Full, Carré, Quinte Flush…
P. Collet 44
Valeur cumulée d’intégration et livraison continues
45
petites stories
grosses stories
Incréments sans intégration verticale
Attention à maîtriser le développement de la dette technique…
46
Comment s’organiser ?• Maximiser le
minimalisme…• Kanban
– Mot japonais signifiant étiquette (ou petite fiche)
– Pratique basée sur l’utilisation d’étiquette (post-it) pour matérialiser les informations sur le processus
47
Kanban : historique• Méthode inventée à la fin des années 1950 dans les usines
Toyota– Mise en place entre deux postes de travail– Une simple fiche cartonnée fixée sur les bacs de pièces dans une
ligne d'assemblage ou une zone de stockage• Intérêts chez Toyota
– Limite la production du poste amont aux besoins exacts du poste aval
– Le nombre de kanban en circulation doit être limité pour éviter la constitution d'en-cours trop importants
• Cette méthode est au départ adaptée aux entreprises ayant une production répétitive et relativement régulière
48
Kanban : premiers principes• Le problème à résoudre est un workflow
– La solution consiste à le visualiser• Diviser le travail (comme dans Scrum…)
– Décrire chaque élément sur une fiche et la mettre au mur (tableau, board)
– Tracer des colonnes, donnez leur le nom des étapes du workflow– Placer les éléments du travail
• En tant que développeur– Choisir ce qui est à faire en fonction de ses compétences ou missions– Faire ce qui est « en cours »– Mettre à jour le tableau Kanban
49
Kanban: exemples d’étapes• Au minimum
– ToDo In Progress Done
• Plus Fin– ToDo Chosen Development– Tests Delivery Done
50http://www.modalisa-technology.com/
Kanban sur très gros projets : github.com
51
Kanban : autres principes
• Et si j’ai 12000 fiches dans « In Progress », ou « TODO », je fais quoi ?
• Limiter le TAF (Travail A Faire / WIP : Work in Progress)– Fixer des bornes au nombre d’éléments dans chaque étape
• Mesurer le temps de cycle (lead time)– C’est le temps moyen pour traiter complètement un élément,
c’est à dire le faire passer par toutes les étapes du workflow– Optimiser le processus en réduisant le temps de cycle et en le
rendant prévisible
– No silver bullet : pas de borne fixe, ca dépend…
52
Mesurer…
53
y = a.x + ba = velocity / vitesse
Kanban(project board dans github)
54
Estimer la durée des tâches
• Une activité extrêmement complexe– Seule l’expérience permet de réaliser des
estimations avec une marge d’erreur acceptable
• Méthodes « classique » d’estimation– Plein de formules mathématiques– Utilisation de plusieurs « experts »– Plus ou moins coûteuses et très peu précises
Planning Poker : Rappel
• Utilisé dans les méthodes agiles– Livraison incrémentale– Correction de « trajectoire » fréquente
• Auteur : J. Grenning (2002)– Popularisé par M. Cohn (Agile Estimating and Planning)
• Avantage : expression libre de tous sur l’estimation
Planning Poker : déroulement• Tous les développeurs sont impliqués
– Ils estiment l’ensemble de la tâche, pas uniquement leur partie– Un des développeurs est le modérateur
• Le product owner peut être la, mais ne participe pas– Il obtiendra des estimations sur l’ensemble des « stories »– Les estimations seront en « story points », une unité
permettant de comparer les stories entre elles, pas une valeur en heures ou jours !
• Chaque développeur reçoit un paquet de cartes
57
Les cartes
58
Plus c’est gros, plus l’estimation est grossière
Planning Poker : déroulement• Pour chaque « user story » ou activité à évaluer
– Le modérateur lit la description– Le product owner répond aux éventuelles questions– Chaque développeur choisit ensuite une carte pour cette
estimation, la carte reste cachée• Ensuite, les cartes sont retournées
– Les estimations vont différer, la plus grande et la plus petite explique leur point de vue
– On discute– On repart
Planning Poker : déroulement• Le product owner utilise les résultats pour fixer les
priorités• A la fin de l’itération, on compare l’estimation aux
nombre de jours réel :– On obtient la vélocité de l’équipe
• Au début, il faut bien choisir la première story qui va servir à l’estimation– Trop grande : on va se retrouver avec des fractions– Trop petite : l’estimation sera trop facile
60
Pourquoi ça marche ?• Plusieurs « experts » donnent leur opinion sans
s’influencer– On ne parle pas– On n’influence pas par le langage du corps
• Cela améliore la qualité de l’estimation– On doit justifier ses estimations– Moyenner les estimations des personnes donne de meilleurs
résultats
• Google « free planning poker online »…
61
Livraison ?Intégration continue(petite introduction)
P. Collet 62
Livraison…
• 1995: Ms Windows 95 : 2 service packs– 1 après 6 mois– 1 après 12 mois
• 2015: Ms Windows 10 : – 4 éditions– Updates en continu et forcées– Impossible de compter les « service packs » : 1 Go
d’update le premier jour !
P. Collet 63
Livraison chaque jour
• Quelle est la propriété la plus importante pour livrer en continu ?
LA CONFIANCE
P. Collet 64
Chaîne d’outillage pour développement et intégration
• Niveau 1 : 1 projet pour un groupe d’étudiants– Compilation automatique : maven– Versioning : github– Gestion des fonctionnalités : ticketing (sur github)– Code, compilation par clic– Construction sur la machine locale, mais portable
• C’est ce que vous allez faire en projet !
P. Collet 65
Chaîne d’outillage pour développement et intégration
• Niveau 2 : projet industriel complexe– 20 à 200 contributeurs– 1 release par an, 1 patch par mois– Plus de 20 Millions de ligne de code
• Besoins (second semestre) :– Développement par composants– Indépendance des constructions– Indicateurs de qualité (test)– Automatisation complète
• -> SECOND SEMESTRE
P. Collet 66
Intégration
• C’est complexe• Donc :– On intègre au plus tôt– On intègre des éléments pour lesquels on a confiance• Ils sont de bonne « qualité »
P. Collet 67
Qualité ?• Pas de défaut ?
• Ou défauts connus ?
• Objectifs :– Connaître et documenter les bugs– Les vérifier pour être sur qu’il n’y a pas de régression– Trouver éventuellement des contournements– Faire émerger de nouveaux besoins
P. Collet 68
Types de tests• Unit Tests • Integration Tests • GUI Tests • Non-regression Tests • Coverage Tests • Load Tests • Stress Tests • Performance Tests • Scalability Tests • Reliability Tests • Volume Tests
• Usability Tests • Security Tests • Recovery Tests • L10N/I18N Tests • Accessibility Tests • Installation/Configuration
Tests • Documentation Tests• Platform testing• Samples/Tutorials Testing• Code inspections
P. Collet 69
Types de tests en M1
• Unit tests : tests unitaires (1er semestre)– JUnit– Mocking– Adaptation à Spring
• Functional and Integration tests (2nd semestre)
P. Collet 70
P. Collet 71
Etape 1: github up• Créer un compte github avec un nom bien identifiable (idéalement
vos noms et prénoms)• Activer le student pack https://education.github.com/pack en
utilisant votre adresse email unice.fr au lieu de univ-cotedazur(même identifiant), car la nouvelle entité n'est pas encore connue de github
• Conseil: il y aura un cours dédié sur la gestion de versions, l’utilisation des branches, etc. Si certains n'ont jamais utilisé cet outil, un excellent tutoriel interactif est https://learngitbranching.js.org/)
P. Collet 72
Etape 2 : team up
• Formation des équipes (4 par équipes, 3 sinon)• Un des membres de l'équipe crée un repository privé
(c'est justement gratuit avec le student pack) et invite les autres membres de l'équipe
• Inviter ensuite les facilitateurs sur le même repository(logins: collet et PhilippeRenevierGonin)
• Mail à [email protected] avec rappel des noms/prénoms/login-github des membres de l’équipe et nom du repository de projet
P. Collet 73
Etape 3: play Takenoko
P. Collet 74
Etape 4: slice
• Projet:– Pas de version graphique– Des Bots plus ou moins intelligents qui jouent– Livraison en intégration continue, tous les jours (ou il y
a cours), une version intégrée le soir
• TODO:– Epics– Architecture du Produit Minimum viable – Slices sur les deux premières livraisons
P. Collet 75