m1 informatique module génie logiciel

M1 informatiqueModule Génie Logiciel

CM1 : Introduction au Génie Logiciel

Céline [email protected]

http://ufrsciencestech.u-bourgogne.fr/~roudet/teaching.html

http://ufrsciencestech.u-bourgogne.fr/master1/GenieLogiciel/

2

Finalité :

intégration

continue

http://fabianpiau.com/wp-content/uploads/post/00003/Dossier_CI.pdf 3


1- Introduction :– Définitions autour du logiciel– Crise du logiciel et bugs célèbres– Solutions proposées par le Génie Logiciel

2- Activités du processus / étude de cas

3- Historique des différents cycles de vie

Introduction au Génie Logiciel Céline ROUDET 4

Production de logiciels et Génie Logiciel

• Omniprésence dans les activités humaines diversifiés, complexes, ...

exigences de qualité / fiabilité

• Nécessite méthodes, techniques et outils GL Science de l’ingénieur dont la finalité est la

fabrication de systèmes informatisés complexes

Travail de groupe et non un individu isolé

Besoins techniques et non techniques


Lois de Lehman (1985)


Hypothèses dynamique d’évolution des logiciels

− Loi des modifications perpétuelles : utilisé dans un environnement réel évolution nécessaire

− Loi de complexité croissante : plus il évolue, plus sa structure a tendance à se complexifier

− Loi de stabilité organisationnelle : modifications de chaque nouvelle version à peu près constantes

Qu’est-ce qu’un logiciel ?

• Ensemble d’artéfacts : Codes : sources, binaires, tests, … Documentation pour l’utilisateur : manuel d’installation,

d’utilisation, de maintenance, tutoriels, ... Documentation interne : cas d’utilisation, modèle du

domaine, …

• Conçus par et pour différents acteurs : Utilisateurs, programmeurs, Maîtrise d’ouvrage (MOA) : commanditaire/client Maîtrise d’oeuvre (MOE) : responsable du développement Hotline, ...


Projet logiciel et schéma/comité directeur

Céline ROUDET 8

Projet : inscrit dans les objectifs généraux de l’entreprise

• Orientations stratégiques pour définir :

visibilité des ambitions de l’organisation

priorités de réalisation des objectifs (pour terminer à temps)

• Intensions de l’entreprise à moyen terme (1 à 3 ans)

• Schéma élaboré par un comité directeur (direction générale)

Introduction au Génie Logiciel

Lancement d’un projet (au niveau de la MOA)

Céline ROUDET 9

• Suivi par un comité de pilotage (responsables de la MOA)

• Désignation d’un directeur de projet (MOA)

Source : http://www.commentcamarche.net

= chef du projet au niveau MOA

= représentants de la direction générale

= responsables organisationnels de la MOA

Représentants desdifférentes entités

de l’entreprise

= intervenants ponctuels

Introduction au Génie Logiciel

Projet et processus

• Projet : ensemble d’activités organisées pour créer un produit / service avec une qualité définie dans le cadre d’un budget fixé.


Processus :

− Ensemble structuré :• d’activités pour chaque acteur (code, planification,

tests, …)• d’artefacts/livrables pour chaque activité (exécutable,

maquette, planning, doc, …) • de workflows (= enchaînement des activités)

− Un processus peut lui-même englober des sous-processus

Processus de développement de logiciels


Activités séquentielles (phases du développement) :

Capture des besoins (CdC)

Analyse (Spécification)

Conception (Architecture)

Implémentation / Réalisation (Codage et tests unitaires)

Intégration, validation et tests (Logiciel livrable)

Qualification et déploiement (Mise en exploitation)

Maintenance (Correction, adaptation)

Processus de développement de logiciels (2)

• Permet d’assurer le cycle de vie du logiciel : depuis sa création … jusqu’à son retrait

en passant par sa distribution sur un marché


• Activités Permanentes (horizontales) :

Produits intermédiaires (prototypes, maquettes, docs)

Plan/manuel qualité et d’assurance qualité

Gestion de projet, des ressources (planification, suivi et avancement du projet), des configurations, des versions, de l’environnement, ...

Vie du logiciel (et coûts engendrés côté MOE)

13

(d’après J. Printz)

67% du coût total d’un logiciel maintenance (dont 48% à réparer des défauts)

60% des défauts correspondent à des erreurs de spécification et de conception

(d’après A-M. Hugues)

La qualité logicielle

• Définitions (AFNOR) : Aptitude d’1 produit/service à satisfaire les besoins des utilisateurs Assurance qualité : manière dont on compte atteindre la qualité

• Manuel qualité / assurance qualité s’appuient sur : Rédaction de standards, normes (ISO), conventions, guides Savoir-faire, expertise de l’entreprise, expériences acquises

• Plan qualité / assurance qualité visent à : Réduire nb erreurs résiduelles

Maîtriser coûts et durée de développement Sans nuire à : innovation & créativité


Facteurs, critères et métriques (McCall – 1977)

15

Facteur Facteur

Métrique

Vue orientée "management"

de la qualité (exigences)

Vue orientée logiciel

qui détermine la qualité

Mesures quantitatives Métrique Métrique

Point de vue utilisateur

Vision externe

ex : maintenabilité

Point de vue concepteur

Vision interne

ex : cohérence, concision, simplicité, modularité …

Critère Critère Critère

QualitéTechnique

QualitéGestion

Qualité globale






La crise du logiciel

• Apparue au début des années 70

• Absence de maîtrise des projets (fiabilité, coûts, délais)


• Mauvaise qualité des produits Ne répondent pas aux besoins définis (car mal définis)

Erreurs résiduelles dans le produit final (car pas assez de tests)

Difficultés d'évolution (non prévues à l’avance)

• Projets en attente, faute d’une gestion rigoureuse

Constats en 1979

Étude du Government Accountability Office sur 163 projets :

29% des logiciels n’ont jamais été livrés

45% des logiciels ont été livrés... mais n’ont pas été

utilisés

19% des logiciels ont été livrés mais ont du être

modifiés pour être utilisés

→ 7% de logiciels livrés et utilisés en l’état


Ces projets ont tous utilisé le modèle en cascade

La crise du logiciel n’est pas terminée !


Année Succès Mitigé Echec

1995 16% 53% 31%

2000 28% 49% 23%

2004 29% 53% 18%

2009 32% 44% 24%

• Réussite des projets informatiques (études du Standish Group)

Succès : livré à temps, sans dépassement de budget et avec toutes les fonctionnalités initialement spécifiées

Mitigé : livré et opérationnel, mais avec moins de fonctionnalités que prévu et un dépassement de budget et/ou de temps

Echec : annulés ou non utilisés après livraison

Les facteurs d’échec


Raisons invoquées des projets abandonnés (études du Standish Group en 1995) :

Pb Analysedes besoins

Pb Comm.avec client

Pb Gestiondu projet

IT : Information Technology

Les facteurs de succès


Raisons invoquées des réussites projets (études du Standish Group en 1995) :

Bonne Commavec le client

Bonne gestiondu projet

Bonne Analysedes besoins

Exemples de logiciels défaillants

• Echec du 1er lancement d’Ariane 5 (4 juin 1996) : explose en vol Réutilisation dans Ariane 5 d’un composant d’Ariane 4 (contrainte

cachée) Cause : problème au niveau de la validation (tests d’intégration)

• Mission Venus : sonde Mariner Passage à 5 000 000 Km de la planète, au lieu de 5 000 Km prévus Cause : remplacement d'une virgule par un point (format US des

nombres)

• Accidents de radiothérapie à Epinal (2004 – 2005) Surdosages dus à des erreurs de paramétrage d'un logiciel Cause : mauvaise ergonomie d'un logiciel obsolète

22Plus de détails : http://www.mines.inpl-nancy.fr/~tisseran/cours/qualite-logiciel/qualite_logiciel.html






Solutions proposées par le GL

• Gérer la complexité (liée aux coûts) : Séparer besoins fonctionnels / aspects technologiques Décomposer en sous-systèmes Modéliser (UML), documenter, commenter (Javadoc), …

• Augmenter la productivité (liée à la réussite) :Génération de code, reverse engineering, gestion de versions (SVN), intégration continue (Jenkins), réutilisation de composants (Java Beans), …

• Améliorer la qualité / fiabilité : Designs patterns & Refactoring Vérification, Validation & Communication Organisation du travail en équipe


Qui fait Qui approuve Qui vérifie Qui valide Qui est consulté

Organiser le processus de développement

• Processus = enchaînement d’activités

• Pour chaque activité, on doit déterminer des rôles :


• Assurance qualité contrôles réguliers : Validation : le bon produit ? (conforme aux besoins) Vérification : le produit correct ? (sans bugs, défauts)

Activité EntréesRésultats intermédiaires

Validation / VérificationDocGestion de projet,

des versions, …



1- Introduction

2- Activités du processus / étude de cas• Capture/analyse des besoins • Spécifications fonctionnelles • Planifications et gestions• Conception détaillée• Implémentation et tests unitaires• Intégration, qualification et déploiement • Maintenance


Étude de cas : projet tutoré à 4 étudiants (2009–10)

• Sujet : Modélisation et simulation des activités d’une entreprise de

collecte, traitement, stockage et expédition de céréales (blé, orge, colza, …)

• Opérations effectuées par l’entreprise : nettoyage à la réception ou à l’expédition, ventilation lors du stockage (conservation des céréales), injection d'un produit insecticide (si insectes présents).

• Problématique : accidents dans les silos explosions (mise en suspension des poussières)

ou incendies (caractéristiques des produits / matériels).

l’entreprise souhaite se doter d’un système informatique de suivi en temps réel pour la surveillance continue des dispositifs matériels

27

Maquette 1 de l’IHM (logiciel Visio)

Fenêtre principale

28

Maquette 2 de l’IHM (logiciel Visio)

Détail des cellules

29

Synthèse des étapes/activités du processus

30

1) Analyse des besoins (le QUOI)

+ besoins non fonctionnels et architecturaux

+ précisions du rôle de chaque acteur

→ use cases

(diagramme de comportement UML) :

besoins

fonctionnels

31

2) Spécifications fonctionnelles

Diag. de séquence (Traitement du grain) : diag. d’intéraction (dynamique)

+ liste des tests envisagés pour valider les scenarii

+ contexte du système (modèle du domaine / du métier)

+ maquette, prototype : guider le choix de l’architecture32

3) Planifications et gestions

• Gestion du temps / délais : planification et maîtrise du temps ( MS Project, GantProject, TaskJuggler, … )

• Gestion de la qualité : système de contrôle pour les produits intermédiaires du cycle de vie (inspection, revue), plan/manuel qualité, normes, standards, ...


• Gestion des ressources (humaines, matérielles) budget transformé en travail, locaux, matériels, déplacements

formation sur les méthodes, outils, nouvelles technologies

• Gestion de la configuration, des versions, … cohérence des composants, différences d’une installation à une autre,

évolution au cours du temps,

outils/méthodes pour faciliter :

• gestion des versions, du travail collaboratif ( CVS, SVN, Git),

• reconstruction du système ( ant, maven, gradle, make, cmake ),

• intégration continue (CruiseControl, Hudson, Jenkins )

3.1) Diagrammes de Gantt prévisionnels

+ diagramme réel et justifications des ajustements

+ tableaux de suivi du projet, ...

34

4) Conception (choix de l’architecture technique)

4.1) MCD (Modèle Conceptuel de Données - Merise)

Dictionnaire des données + explications

35

4.2) Diagramme de classes (de structure : statique)

+ Design Patterns,

+ plan d’intégration des modules, plans de tests 36

4.3) Autres diagrammes (Merise, UML)

MCT (Merise) : enchaînement des opérations, vue globale des traitements/activités du domaine

UML :

Tiré de : http://laurent-audibert.developpez.com/Cours-UML/?page=mise-en-oeuvre-uml#L9

Structure Comportement Intéraction

37

5) Réalisation

Implémentation + documentation :

– IDE/AGL (Eclipse, Netbeans, Jbuilder, …),– documentation des classes (Javadoc), …– génération de code et rétroconception (reverse engineering),– réutilisation de composants logiciels (Java Beans), ...

38

• Restructuration et tests de vérification – refactoring (améliorer la structure du code), assertions ( JML),

debugger (IDE), robustesse du système (exceptions), ...– environnements de tests unitaires (JUnit, Mockito, EasyMock),

couverture de code, ...

5.1) Manuel utilisateur

Fenêtre principale

39

5.1) Manuel utilisateur (2)

Fenêtre de visualisation du contenu du silo

+ actualisations (diagrammes UML, Merise, tests, ...)

40

6) Intégration, validation et qualification

• Intégration matérielle et logicielle Modules intégrés avec les autres (plan d'intégration), ensemble testé conformément aux plans de tests


• Qualification (ou recettes : une fois le logiciel terminé) : Tests dans des conditions normales d'utilisation, puis logiciel prêt à la mise en exploitation

• Tests de validation (le bon produit ?) en accord avec les besoins du client conformément aux spécifications initiales

Un choix possible : les méthodes formelles

Pour traiter durant tout le processus les dysfonctionnements logiciel

Notation/modèle formel + sémantique bien définie + outillage

Exemples : automates, réseaux de Pétri, B, Z, LOTOS, SDL, CSP, CCS, ...

Analyse et spécification :- Description formelle des concepts clés du problème (domaine d’application)- Spécification formelle du comportement du système (explicites, précises, non-ambigües)- Prototypage

Conception architecturale et détaillée :- Spécification formelle de l’interface des modules- Méthode rigoureuse de raffinement

Codage :- Preuves de programmes- Synthèse automatique du code- Utilisation d’assertions : pré/post-conditions, invariants (JML)

Tests : Génération automatique des tests (base pour leur développement)42

7) Maintenance du projet

43

[selon C. Larman]

Extensions utilisateur . . . . . . . . . . . 41,8%Correction d’erreurs . . . . . . . . . . . . 21,4%Modification format de données . . . 17,4%Modification de matériel . . . . . . . . . . 6,2%Documentation . . . . . . . . . . . . . . . . . 5,5%Efficacité . . . . . . . . . . . . . . . . . . . . . . 4%

Maintenance, évolution : correction des erreurs (robustesse)

demandes d’évolution (nouvelles fonctionnalités, portabilité, …)

étape longue, critique et coûteuse (80% de l’effort)

CM1 : Intro au Génie Logiciel

1- Introduction


3- Historique des différents cycles de vie• Modèles séquentiels• Modèles itératifs et incrémentaux


Modèle en cascade (1970)

45

Spécificationgénérale

Spécificationdétaillée

Implémentation

Intégration

Déploiement

Maintenance

Document formalisé

Architecture du système

Modules et interactions

Code et tests unitaires

Première version livrable

Livraison et installation

Erreur de spécification trouvée en maintenance :

+ de 100 fois plus cher

Définition des exigences Séquentiel linéaire (un des premiers modèles proposés)

Ex : Merise

Mises à jour

Problèmes du modèle en cascade


• Difficile de gérer les changements en cours de projet

• Applicable pour les projets bien compris et maîtrisés

• Le produit apparaît à la fin : risques élevés / non contrôlés• identification tardive des problèmes

• preuve tardive de bon fonctionnement

Utilisation des fonctionnalités spécifiées [selon C. Larman]

Jamais. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45%Rarement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19%Parfois . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16%Souvent. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13%Toujours. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7%

Modèle en V (1979)


Définition des exigences

Spécifications détaillées

Spécifications générales

Codage Tests unitaires

Tests systèmes

Tests d’acceptation

Gestion des configurations

Gestion de projet

Plan assurance qualité

Horizontal : préparation de la vérification

Vertic

al : déve

lop

pem

ent d

es activ

ités

Tests d’intégration

Validé par

Avantages et inconvénients du cycle en V


• Avantages : Associe à chaque activité de conception une activité de

test Validations intermédiaires meilleure anticipation Évite les retours en arrière

• Inconvénients : Modèle toujours séquentiel : peu d’adaptabilité Tests commencent après le développement Preuve toujours tardive du bon fonctionnement


1- Introduction


3- Historique des différents cycles de vie− Modèles séquentiels− Modèles itératifs et incrémentaux


Modèle itératif

• But : améliorer les modèles séquentiels (+ de flexibilité)

• Gestion des risques fait partie du modèle :– Minimisation grâce à 1 analyse régulière (client)

• A chaque nouvelle itération :

– Maîtrise d'une partie des risques (+ importants d’abord)

– Preuve de faisabilité / adéquation avec les objectifs (maquette, prototype)

– Nouvelles fonctionnalités (produit de plus en plus complet)

50Introduction au Génie Logiciel Céline ROUDET

Modèle itératif (2)

51Schéma tiré du cours de P.-A. Muller

Modèle en spirale (1986)

52

Source : Wikipedia

Analyse des risques

Avantages et inconvénients du modèle en spirale


• Avantages : Prise de décision managériale et non purement technique

Bilans réguliers : faisabilité, satisfaction client

Divise le traitement de la complexité de l’application

Rectifier au plus tôt les erreurs et prendre en compte l’évolution des besoins

• Inconvénients : Qualité des prototypes développés souvent faible

Le client ne voit le système réalisé qu’à la fin !

Modèle incrémental

54

Produits opérationnels :incréments livrables

- Logiciel construit par incréments de fonctionnalités

- Premier incrément = noyau

- Chaque incrément aide à gérer les risques techniques

Schéma tiré du cours de P. Collet

Modèle incrémental et itératif

55

• Incrémental : parties planifiées, développées au fil du temps et intégrées dès qu’elles sont terminées

• chaque incrément fonctionnel :– donne lieu à un produit fini (exécutable testé et intégré)

– est à taille humaine (un besoin du client)

• Itératif : une partie est remaniée et améliorée plusieurs fois avant d’atteindre son état définitif

• Utilisé par les méthodes suivantes :

– UP ou USDP (Unified Software Development Process)

– XP (eXtreme Programming) : méthode agile

• Le client peut influencer le développement

Un système complexe qui fonctionne a toujours évolué à partir d’un système simple qui a fonctionné … (John Gall)

UP/USDP : répartition des phases, disciplines et itérations

56

Itérations :

Phases :

Vie d’un logiciel avec UP/USDP (1997)

• Composée de cycles (de développement)– 1 cycle = 1 nouvelle version du logiciel

– chaque cycle est composé de 4 phases

• Chaque phase d’un cycle est composée d’itérations

– chaque itération : composée d’activités/disciplines Modélisation métier, capture des besoins

Analyse, conception

Réalisation, test, déploiement …

– ... en proportions variables en fonction du temps

57 58Tiré du cours d’E. Chenu

Différents cycles de vie : cascade vs iter. & incr.

Introduction au Génie Logiciel Céline ROUDET

Tiré du cours d’E. ChenuCycles de vie (2)

59

Liens : processus de développement et qualité

– Cours d’A. M. Hugues : http://users.polytech.unice.fr/~hugues/GL/qualite.html– Cours de P. Collet : http://deptinfo.unice.fr/twiki/bin/view/Minfo05/GLOO– Cours d’E. Lefrançois : http://homepage.hispeed.ch/e.lefrancois/heig/files/Download/GL.pdf– Cours de M. Amiguet : http://www.matthieuamiguet.ch/media/documents/MA-QLOGI-02-Normes.pdf

Livres :

– Quality factors. J.A. McCall, in Encyclopædia of Software Engineering, J.Wiley & Sons - 1994– Le génie logiciel. J. Printz. Eyrolles - 2005– Object-Oriented Analysis and Design with applications, 3rd ed. G. Booch et al. – 2007– Programmation en C++ et génie logiciel. V. T'kindt. Dunod – 2007– Software Engineering - 9th ed. I. Sommerville. Addison-Wesley – 2010– Mémento - Cahier des charges informatique. Y. Constantinidis. Eyrolles – 2011– Tout sur le développement logiciel - Ecrire du code efficace, Jean-François Pillou,

Christine Eberhardt, Dunod, 2011– Architecture logicielle. Concevoir des applications simples, sûres et adaptables. J.

Printz. Dunod – 2012– Architecture logicielle - Pour une approche organisationnelle, fonctionnelle et

technique. T. Bailet. Editions ENI – 2012– Expression du besoin et cahier des charges fonctionnel. Élaboration et rédaction –

3rd éd. J. Bernard-Bouissières. Editions AFNOR – 2013– Design Patterns en Java. Les 23 modèles de conception - Descriptions et solutions

illustrées en UML2 et Java, Laurent Debrauwer, Eni, 2013

60Introduction au Génie Logiciel Céline ROUDET

m1 informatique module génie logiciel

Documents