Projet de développement Génie logiciel

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 à Philippe.Collet@unice.fr 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