Génie Logiciel & Conduite de Projet

Projet de développement

Génie logicielPhilippe Collet / Philippe Renevier Gonin

Master 1 Informatique

https://wiki.unice.fr/pages/viewpage.action?pageId=369066011

Avec certains slides de Sébastien Mosser et Guilhem Molines

P. Collet / P. R. G.

https://wiki.unice.fr/pages/viewpage.action?pageId=369066011

Avant PROPOSProgramme(s), Modalité de Contrôle des Connaissances, liens avec le TER


2

Programme

SEMESTRE 1 : GL & PD• [Projet de développement]

• Principes de développement / Approche agile et spécification des besoins, Stories

• Gestion de versions avancée : git branching

• Tests unitaires / Tests et mocking• Behavioral Driven Development

• [Génie Logiciel] • Patrons de conception• AntiPatterns• Métriques

SEMESTRE 2 : GESTION DE PROJET• Architecture Orientée

Composant / Service • Spring • Web Service

• Intégration continue• Plateforme d’intégration continue• Virtualisation (docker)• Tests de bout en bout

• Projet = Changement d’architecture


3

Couplage avec le TER

• Pour les non alternants

• Les jeudis & vendredis

• Étude, Développement et Analyse d’IA


4

MCC

• Projet de Développement (s1) - Contrôle continu, pas de contrôle terminal, 2e session = écrit de 1h30• CC (30%) : évaluation des rendus successifs de projet

(compilation, test, exécution, régularité

• CC (70%) : évaluation finale du projet (qualité du code, des tests, etc.)

• Génie Logiciel (s1) - Contrôle continu et contrôle terminal, 2e session = écrit de 1h30• CC (40%) évaluation d'un rapport de génie logiciel rendu avec

le projet : justification des choix de conception, de l'utilisation de patrons de conception

• Contrôle terminal écrit - 2h (60%)


5

KICK-OFF


6

PROJET

Technique

Expertise

Acceptation

Client


7

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 ?


8

Les phases du cycle de vie

Objectifs

Définition

des besoins

Analyse

des besoins

Planification

Maintenance

Mise en

exploitation

Qualification

Validation et

IntégrationImplémentation

et tests unitaires

Conception

Retrait ou

remplacement


9

Modèle en cascade (1970)Analyse des besoins

vérification

Specif. fonctionnellesvérification

Planificationvérification

Conceptionvérification

Implémentationtests unitaires

Intégrationtests

Qualificationtests

Exploitation

Retrait

Changementdans l’expression

des besoins

vérification


10

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


11

Modèle en VQualification

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


12

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


13

Prototypage

construire /améliorer

la maquette

Écoute duclient

Le clientessaie

la maquette


14

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


15

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 ?

• Projets petits ou à courte durée de vie


16

Modèle incrémental

Analyse des besoinsvérification

Spécif. & Planificationvérification

Concept. globalevérification

Exploitation

Retrait

Incrément Nconception détaillée, codage, tests uni., intégration, livraison


17

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

• Le premier incrément est souvent le noyau

• Les incréments aident à gérer les risques techniques (matériel non disponible)


18

Modèle en spirale (Boehm, 1988)


19

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


20

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

• Réduit les risques si bien appliqué

• Les risques augmentent considérablement si le contrôle faiblit


21

2TUP : Two Track Unified Process

▪ 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


22

Développement :Agilité ?


Ce qui NE marche PAS

• Des spécifications complètes en premier

• Commencer par coder sans aucune conception


24

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


25

Simplicité, de bout en bout


26

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


27

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

• ….


28

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


29

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


30

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.


31

Processus Scrum


32

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


33

User Stories, Epic…

SPRINT

RELEASE

FUTUR


34

User story et tâche ???

• Système


35

Une tâche ?

• Une tâche -> heure(s)

• Un commit -> minute(s)


36

Le découpage ?

• Interface graphique / interface externe

• Client

• Back-end


37

Un système bien intégré ? Complet ?


38

Vraiment ?


39

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


40

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.


41

User story : en fiche

• Au Verso : • conditions

d’acceptation définies par l’utilisateur

• niveau de risque (optionnel)

• modifications de la demande (optionnel)


42

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


43

Découpage vertical idéal

• Interface graphique / interface externe

• Client

• Back-end


44

Comment ?…

Attention, faites simple mais pas simpliste


45

Verticalité : 1. Epics


46

Verticalité : 2. Stories / features


47

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


48

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ègles

• Une 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…


49

Valeur cumulée d’intégration et livraison continues

petites stories

grosses stories

Incréments sans intégration verticale


50

Attention à maîtriser le développement de la dette technique…


51

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


52

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


53

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


54

Kanban: exemples d’étapes

• Au minimum• ToDo In Progress Done

• Plus Fin• ToDo Chosen

Development

• Tests DeliveryDone

http://www.modalisa-technology.com/


55

Kanban sur très gros projets : github.com


56

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…


57

Mesurer…

y = a.x + ba = velocity / vitesse


58

Kanban(project board dans github)


59

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


60

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


61

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


62

Les cartes

Plus c’est gros, plus l’estimation est grossière


63


• 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

64


• 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


65

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 »…


66

Livraison ?Intégration continue(petite introduction)


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 !


68

Livraison chaque jour

• Quelle est la propriété la plus importante pour livrer en continu ?

• LA CONFIANCE


69

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 !


70

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


71

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é »


72

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


73

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


74

Types de tests en M1

• Unit tests : tests unitaires (1er semestre)• JUnit

• Mocking

• Adaptation à Spring

• Functional and Integration tests (prélude)

• Functional and Integration tests (2nd semestre)


75


76

Etape 1: github up

• Créer un compte github avec un nom bien identifiable (idéalement vos noms et prénoms)

• Rejoignez l’organisation : https://classroom.github.com/g/tc0vW_R9

• 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/)


77

https://classroom.github.com/g/tc0vW_R9

https://learngitbranching.js.org/

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 l’organisation) et invite les autres membres de l'équipe

• (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


78

mailto:[email protected]

Etape 3: play Puerto Rico


79

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


80

Génie Logiciel & Conduite de Projet

Documents

Transcript of Génie Logiciel & Conduite de Projet