Embed Size (px)
Citation preview
Modélisation Orientée Objet Conception de S.I.
Master MIAGE M1 parcours SIGS
V. Deslandres, Univ. [email protected]
PLANNING séance 1
• Cours « Rappel de Génie Logiciel »
• Fiche TD1• Exercice de sensibilisation sur la capture des Besoins, le vocabulaire
• Cours « Pourquoi la Modélisation OO »
• Suite TD1 : illustration méthode itérative et incrémentale
• Place de la modélisation dans un cadre Agile
2
Le génie LogicielIntroduction générale
V. DESLANDRESMaster MIAGE parcours SIGS (Gestion de la Santé)
POLYTECH LYON
Objectifs de ce chapitre
• Dresser une typologie des logiciels• Savoir ce qu’est le Génie Logiciel• Le définir, en comprendre les enjeux• Savoir qui sont les acteurs impliqués
• Connaître les étapes d’une démarche de GL
• Réf.: « Object-Oriented Software Engineering: Practical Software Development using UML and Java » 2nd Edition, Timothy C. Lethbridge and Robert Laganière - McGraw Hill, 2001
4
La nature du Logiciel...• Le logiciel est intangible• Il est difficile de gérer l’effort de développement
• Le logiciel est facile à reproduire• Le coût se trouve dans son développement et sa maintenance
• Pour d’autres produits, la fabrication est souvent le processus le plus coûteux
• L’industrie du logiciel exige beaucoup de main d’œuvre – artisanat• … à l’opposé de la production en série• Implication d’humains à gestion des relations, soft skills, etc.• Néanmoins, le processus de développement commence à être
automatisé5
La nature du logiciel• Même des informaticiens peu qualifiés peuvent arriver à bricoler
quelque chose qui semble fonctionner• La qualité d’un logiciel n’est pas apparente
• Un logiciel est facile à modifier• La tentation est forte d’effectuer des changements rapides sans
vraiment en mesurer la portée
• Un logiciel ne s’use pas mais se détériore• à mesure que les technologies évoluent, que des changements sont
effectués• introduction d’erreurs • complexification progressive
6
• En conséquence
• Beaucoup de logiciels sont mal conçus et leur maintenance est difficile• La demande de logiciels est toujours croissante• L’ingénierie du logiciel est une nécessité
7
Le génie logiciel ?...• DEF « Le processus visant la résolution de problèmes posés par un client
par le développement systématique et l’évolution de systèmes logiciels de grande taille
et de haute qualité, en respectant les contraintes de coûts, de temps, et autres »
• Autres définitions:
• IEEE: l’application d’une approche de développement, d’utilisation et
de maintenance logicielle systématique, disciplinée, quantifiable
8
• « …la résolution de problèmes posés par un client… »
• Voilà le but essentiel du génie logiciel
• Ajouter des options non requises par le client ne rend pas le logiciel plus satisfaisant
• L’équipe de dév. logiciel doit établir une bonne communication afin de bien identifier
et comprendre le besoin (le problème à résoudre)
• « …par le développement systématique et l’évolution… »
9
Qu’est-ce que ça signifie pour vous :
« développement systématique » ?
• …par le « développement systématique » et l’évolution…
• C’est l’application de techniques maîtrisées (voire automatisées) dans une organisation limpide et disciplinée
• Plusieurs pratiques reconnues ont maintenant été standardisées• e.g. ITIL ou CMMI, RUP, le processus unifié de modélisation, les tests unitaires automatisés,
l’intégration continue, etc.
10
ITIL
11
• Référentiel métier international (Information Technology Infrastructure Library)• Né en Europe années 90 (UK)• Approche processus, « bonnes pratiques »
• Cible très large, orienté gouvernance des S.I. :• Comment organiser un système d'information ?• Comment améliorer l'efficacité du système d'information ?• Comment réduire les risques ?• Comment augmenter la qualité des services informatiques ?
CMMI• Référentiel métier international (Capability Maturity Model Integration)
• USA années 1980 (Université Carnegie Mellon, pour la Défense)
• Approche processus et notion d'amélioration continue
• Propose une évaluation, qui permet de se situer et de ‘définir des voies de progrès’
• CMMI-DEV : orienté développement de systèmes (logiciels) • Mesure la maturité sur une échelle à 5 niveaux
• De ’initial’ à ‘en optimisation’
• Fournit les indicateurs nécessaires pour évaluer les activités
• Modèle de processus accepté par la norme ISO 15504
12
L’intégration continue• Pratique issue d’XP (eXtreme Programming)• OBJ.: automatiser le processus de dév logiciel• Repose sur :• Un logiciel de gestion de versions (VCS)• Des tests automatisés nombreux
• Tests unitaires :Junit, Cactus• Audit de code source, test IHM, tests fonctionnels
• Un serveur d’intégration (ex. Cruise Control, Hudson, Jenkins)
• Permet d’avoir un exécutable à chaque nouvelle version (‘incrément’)
13
L’intégration continue
14
L’intégration continue
Vérifie que la mise à jour ne génère pas de régressions et/ou d’anomalies
Permet de donner au développeur une vision générale de l’application puisque les tests de l’application se font sur un environnement clone de production
DEF génie logiciel...
• « …par le développement systématique et l’évolution… »
15
L’évolution de logiciel…ça concerne quel pourcentage de l’activité par rapport à la création ?
La plupart des projets logiciels consiste à faire évoluer un logiciel existant (80/20)
« …systèmes logiciels de grande taille et de haute qualité… »
• Un logiciel ‘de grande taille’ = qui ne peut être compris par une seule personne
• Le travail en équipe et une bonne coordination sont essentielsè subdiviser le travail à accomplirès’assurer que les parties fonctionneront harmonieusement
ensemble
« de haute qualité… »• Le produit final doit rencontrer des critères de qualité établis
16
DEF génie logiciel...
« …en respectant les contraintes de coûts , de temps, et autres »
• Les ressources sont limitées• Le bénéfice résultant doit être supérieur aux coûts • La productivité de l’équipe doit demeurer concurrentielle• Une mauvaise estimation des coûts et de la durée du projet peut mener à l’
échec du projet
17
DEF génie logiciel...
Taux réussite des projets
• Etude du Standish Group (US) sur 50 000 projets
18
Challenged: budget ou délai dépassé, client satisfaitFailed: abandonné ou client non satisfait
• Plus la complexité et la taille sont importantes, plus le risque d'échec est fort
• On observe d’autre part que « les projets ayant des objectifs plus flexibles ont plus de chance de réussite que ceux avec des objectifs précis »
19
Principales causes d’échec1. Manque d’implication du Client / Utilisateurs : 12,8%
2. Exigences et spécifications incomplètes : 12,3%
3. Changement des exigences et spécifications : 11,8%
• La capture du besoin est la cause de presque 37% des cas
• Le SG préconise un développement « itératif et incrémental, avec de fréquents retours utilisateurs »• Processus flexible et ouvert : mode agile
20
Le métier d’ingénieur logiciel
• Le terme Génie Logiciel a été introduit en 1968• Reconnaître que les principes du « génie » peuvent s’appliquer au
développement du logiciel
• Le « génie » est une pratique régulée par une corporation professionnelleè Protection du public• Application de principes scientifiques et économiques• Pratiques conformes à une éthique établie
21
Organisation
• Pour le dév. Logiciel, il y a 2 organisations possibles :• L’équipe projet : équipe spécifique, vision projet ; dispersion en fin
de projet• Une équipe de développement produit impliquée dans différents
projets (successivement, ce qui se pratique bcp en Agile) : stabilité, soft skills
• Importance de ‘l’Emotionnal Maturity’: la capacité à savoir travailler ensemble• Facteur de succès identifié par le Standish Group
22
Les parties impliquées dans le génie du logiciel
23
Indice : 5
Lesquelles citeriez-vous ?
Software Engineering
Les parties impliquées dans le génie du logiciel
• Utilisateurs• Ceux qui se servent du logiciel
• Clients• Ceux qui paient pour le logiciel
• Développeurs (les Dev)• Ceux qui conçoivent et implémentent le logiciel
• Exploitants (les Ops en Anglais)• Ceux qui exploitent le logiciel (mise en production, maintenance,
évolution)• Managers• Ceux qui supervisent la production du logiciel
(Certains rôles peuvent être remplis par la même personne)24
La qualité du logiciel...
• Conviviabilité• Apprentissage aisé, facilité d’utilisation
• Efficacité• Aucun gaspillage de ressources (mémoire, temps de calcul, …)
• Fiabilité• Les tâches sont effectuées sans problème
• Facilité de maintenance• Aisé à modifier, à faire évoluer
• Réutilisabilité• Des composants peuvent être réutilisés facilement
25
La notion de qualité varie selon le point de vue...
26
Perception dela qualité du
logiciel DéveloppeurFacile et rapide à concevoir,À développer et à tester
UtilisateurFacile à apprendre,utile et efficace
ClientRésoudre le problèmeà un coût acceptable
ManagerSe vend bien,satisfait les clients,peu coûteux à développerExploitant
Facile à maintenir,à réutiliser
La qualité du logiciel...
• Accroître l’efficacité peut rendre le logiciel plus difficile
à maintenir et à réutiliser
• Vouloir « fabriquer la Lune » peut demander du temps
• Livrer vite (et vendre rapidement) peut se faire au
détriment de certaines fonctionnalités
• Telle fonctionnalité demanderait un traitement
spécifique pour la mise en prod, il vaudrait mieux
l’abandonner
• Rentrer ‘dans les standards’ plus ou moins figés
27
Ces différents critères peuvent être en conflit, par ex.
• Définir des critères de qualité constitue un élément clé du génie du logiciel• La conception a alors pour objectif de faire rencontrer ces
critères• Trop en faire est une perte de temps et de ressources
• L’optimisation du logiciel peut ensuite être nécessaire• Recherche de performance, ex. en embarqué
• Il faut atteindre un niveau de performance optimal en fonction des coûts budgétés
28
29
Critères de qualité internes
• Ce sont par exemple: • la généricité du code• le style de programmation• la quantité et la qualité des commentaires,• la complexité du programme produit
• Caractérisent certains aspect de la conception du logiciel• Ont un effet direct sur la qualité externe du produit
30
Qualité du code
• Il en existe un grand nb d’indicateurs en POO• Le nb de classes• La complexité cyclomatique• Etc.
• Ces critères sont aujourd’hui utilisés dans les chaînes de développement automatisées• Outil Sonar• Hudson, outil d’intégration continue
• On fera un topo sur ces indicateurs
31
Risques associés à une mauvaise qualité
• Des bugs subsistent• Peuvent pénaliser plus ou moins fortement son
utilisation
• Client non satisfait• Ne fera plus appel à nous comme développeurs• Refuse de payer le montant fixé• Diffuse son mécontentement sur les réseaux
32
Lesquels voyez-vous ?
Risques associés à une sur-qualité ?
• Délai dépassé, ce qui induit :• Client insatisfait• Coûts plus élevés (durée)• Pénalités de retard
• Risque « d’erreur de focus » : les dév peuvent avoir travaillé un aspect jugé non prioritaire pour les utilisateur• Perte de temps et d’argent• Mauvaise image pour le client
33
Lesquels voyez-vous ?
Activités communes aux projets de génie logiciel
• Définition et spécification des exigencesCe qui inclut• Analyse du domaine• Description du problème• Recueil des besoins• Analyse des besoins• Spécification approfondie des exigences
34Quel est l’interlocuteur privilégié de cette étape ?
•Modélisation•Créer des représentations du logiciel et de son
domaine d’application•Modélisation de l’utilisation envisagée•Modélisation de sa structure•Modélisation de sa dynamique (son
comportement)
35
Activités communes aux projets de génie logiciel
Activités communes aux projets de génie logiciel
• Conception• Faire les choix technologiques pour répondre aux besoins
• Ce qui inclut:• Déterminer ce qui sera réalisé par le logiciel et par le matériel• Mettre au point l’architecture du système, la définition des sous-systèmes et leurs
interactions• Élaboration des éléments internes des sous-systèmes• Conception des interfaces utilisateurs et des bases de données
• Programmation• « Programming is easy, it is just like math. In math, 1 + 2 = 3 always.• Your program is either right or wrong. And you have metrics about
performance, program size, etc. » 36
Activités communes aux projets de génie logiciel
• Assurance qualité (QA)•Mettre en place les tests qui vont garantir la ‘non
régression’ en cas de révisions•Mise à l’épreuve (phase de tests et recette d’application
sur l’environnement de production)• Déploiement / Formation• Gestion du projet (activités supports)
37
Activités du GL : je retiens
1. ______________________2. ______________________3. ______________________4. ______________________5. ______________________6. ______________________7. ______________________
38
Attention, ces activités ne sont pas
nécessairement séquentielles !
(notamment la GP)
Risques et difficultés en génie du logiciel
• Complexité et quantité des éléments à tenir en compte• Incertitude concernant la technologie• Incertitude concernant les exigences• Incertitude concernant les compétences• Adaptation face aux changements• Acceptation des utilisateurs• Risques politiques
39
UML vs. Agilité, BPMPositionnement actuel
40
Cadre Agile : place de la modélisation ?
41
42
En Agilité : UML light
• Avec les méthodes agiles, seul le code compte• (« le code EST le modèle de la réalité »)
• Mais les modèles sont utiles pour communiquer, discuter, avancer dans la compréhension du domaine et des besoins• Ainsi une modélisation « light » est utilisée• Les Cas d'utilisation détaillent des « user stories » • Avec le client, on discute la modélisation métier avec des
diagrammes d'activité, des diagrammes de classes
43
• Prouver les modèles avec du code• Obj.: montrer que ses idées marchent vraiment
• Utiliser des notations simples• afin que le contenu des modèles soit facile à valider
• Se focaliser uniquement sur les aspects qu’on doit modéliser• Ne pas chercher à créer à tout prix un modèle très détaillé• Ne modéliser que ce qui ajoute de la plus value
• Modéliser à plusieurs• Principe de « propriété collective »
44
important
Modèle vs. Documentation
• Les modèles ne sont pas de la documentation !• On modélise pour échanger et développer une compréhension
commune• Ne pas chercher à terminer proprement un modèle : reconnaître leur
aspect provisoire• Un modèle complet n’existe pas• Il doit rester aussi simple que possible mais procurer une valeur claire• Une fois la valeur acquise, on la code
• Et si on a besoin de documentation ?• Reverse engineering sur le code, stable, validé
45
Le BPM
• Business Process Modelling• BPMN (Notation) : norme de l’OMG• Obj.: Réconcilier MOA et MOE• Démarche d'urbanisation SI : progressive• Les techniques utilisées s'applique au SI, puis aux projets,
aux composants, et en final aux objets des applications• UML à composants et objets de l‘application• BPM à S.I., projets
46
47
Lien BPM à UML• Les processus métier BPMN sont le point d'entrée de la phase
‘Expression des besoins’
• Un BPM décrit toutes les activités (manuelles et automatisées), et les flux de données
• Les activités à automatiser deviennent les cas d’utilisation qui représentent les comportements attendus du futur système
48
Pro / cons BPM
• BPMN est plus convivial, voc. Métier, plus facilement accepté
• Traçabilité délicate• Un AGL UML permet la traçabilité des docs• Ex. Matrice Exigences / Diagrammes d’un AGL• Permet d’associer les docs (fiches descriptives des éléments par ex.), et donc
tracer leur évolution
49
Cours1 : je m’évalue…
50
• Citer 2 référentiels normalisant l’activité logicielle ?
• Quelles sont les principales causes d’échec de la production de logiciels selon l’étude du Standish Group ?
• Quels acteurs participent aux étapes du GL ?
• Rappeler les 7 activités du GL
• Modéliser en Agile, ça signifie quoi ?• UML vs. BPMN
