La présentation est en train de télécharger. S'il vous plaît, attendez

La présentation est en train de télécharger. S'il vous plaît, attendez

Génie logiciel et Gestion de projet

Présentations similaires


Présentation au sujet: "Génie logiciel et Gestion de projet"— Transcription de la présentation:

1 Génie logiciel et Gestion de projet
BTS IRIS 2 GL

2 Introduction Le génie logiciel (software engineering) existe depuis plus de 30 ans Né des constatations que les logiciels : Pas fiables Incroyablement difficiles à réaliser dans les délais Ne satisfaisaient pas le cahier des charges BTS IRIS 2 GL

3 La préhistoire du logiciel
Années 50 et 60 : programmation empirique production "artisanale" de logiciels scientifiques royaume des "codeurs" et les "grands gourous" Fin des années 60 : la "crise du logiciel" difficulté d'écrire de grands programmes difficulté de les utiliser, difficulté de les faire évoluer de nombreux projets échouent BTS IRIS 2 GL

4 Quelques erreurs célèbres
perte de la 1ère sonde Mariner vers Venus suite à une erreur de programmation dans un programme Fortran perte, en 1971, de 72 ballons d’expérimentation météorologique à cause d’un bug logiciel panne, en 1990, du réseau téléphonique de la cote Est des USA suite à un changement de version d’un des modules du système de gestion du réseau abandon d'un projet d'informatisation de la City après 4 ans de travail et 100 M£ de perte échec d’ARIANE 501 suite à un bug logiciel Invalidation de version de Windows suite au changement de version du Windows Genuine Advantage BTS IRIS 2 GL

5 La crise du logiciel Etude du gouvernement américain en 1979
Payés mais jamais livrés $3.2M 47% Livrés mais jamais utilisés $2.0M 29% Abandonnés ou refaits $1.3M 19% Utilisés après modification $0.2M 3% Utilisés tel quel $0.1M 2% BTS IRIS 2 GL

6 Pourquoi le GL? Si l'on veut maîtriser le développement de systèmes complexes, il faut : rédiger de façon claire les spécifications du système (ce que l'on attend) => comment être sûrs que ces spécifications sont complètes ? => comment être sûrs que ces spécification sont cohérentes ? valider/vérifier toutes les étapes du développements => a-t-on des moyens de validation/vérification (mathématiques) ? de réutiliser des sous-systèmes déjà réalisés (mais pas n'importe comment) => a-t-on des règles, des outils pour aider à la réutilisation ? nécessité d’une base théorique et d’une approche ingénierie (science de l’ingénieur) du logiciel

7 Définition Le génie logiciel comporte des aspects de gestion de projet et des notions de qualité (satisfaire le client) Ceci en utilisant des méthodes, des modèles, et des outils. BTS IRIS 2 GL

8 Récréation... A propos de la réutilisation et du poids du passé…
Question : la distance standard entre 2 rails de chemin de fer aux US est de 4 pieds et 8,5 pouces. C'est un chiffre particulièrement bizarre. Pourquoi cet écartement a-t-il été retenu ? Parce que les chemins de fer US ont été construit de la même façon qu'en Angleterre, par des ingénieurs anglais expatriés, qui ont pensé que c'était une bonne idée car ça permettait également d'utiliser des locomotives anglaises. Pourquoi les anglais ont construits les leurs comme cela ? Parce que les premières lignes de chemin de fer furent construites par les mêmes ingénieurs qui construisirent les tramways, et que cet écartement était alors utilisé. Pourquoi ont-ils utilisé cet écartement ?

9 Récréation... Parce que les personnes qui construisaient les tramways étaient les mêmes qui construisaient les chariots et qu'ils ont utilisé les mêmes méthodes et les mêmes outils. Pourquoi les chariots utilisent un tel écartement ? Parce que partout en Europe et en Angleterre les routes avaient déjà des ornières et un espacement différent aurait causé la rupture de l'essieu du chariot. Pourquoi ces routes présentaient elles des ornières ainsi espacées ? Parce que les premières grandes routes en Europe ont été construites par l'empire romain pour accélérer le déploiement des légions romaines. Pourquoi les romains ont ils retenu cette dimension ? Parce que les premiers chariots étaient des chariots de guerre romains. Ces chariots étaient tirés par deux chevaux. Ces chevaux galopaient cote à cote et devaient être espacés suffisamment pour ne pas se gêner. Afin d'assurer une meilleure stabilité du chariot, les roues ne devaient pas se trouver dans la continuité des empreintes de sabots laissées par les chevaux, et ne pas se trouver trop espacées pour ne pas causer d'accident lors du croisement de deux chariots.

10 Réponse à la question : l'espacement des rails US (4 pieds et 8 pouces et demi) s'explique parce que 2000 ans auparavant, sur un autre continent, les chariots romains étaient construits en fonction de la dimension de l'arrière train des chevaux de guerre. Conséquence : la navette spatiale américaine est flanquée de deux réservoirs additionnels attachés au réservoir principal. La société THIOKOL fabrique ces réservoirs additionnels dans leur usine de l'UTAH. Les ingénieurs qui les ont conçus auraient bien aimé les faire un peu plus larges, mais ces réservoirs devaient être expédiés par train jusqu'au site de lancement. La ligne de chemin de fer entre l'usine et Cap Canaveral emprunte un tunnel sous les montagnes rocheuses. Les réservoirs additionnels devaient pouvoir passer sous ce tunnel. Le tunnel est légèrement plus large que la voie de chemin de fer, et la voie de chemin de fer est à peu près aussi large que les arrières train de deux chevaux. Conclusion : une contrainte de conception du moyen de transport le plus avancé au monde est la largeur d'un cul de cheval.

11 Les modèles de développement
BTS IRIS 2 GL

12 Le modèle en cascade BTS IRIS 2 GL

13 Étude préliminaire définition globale du problème,
différentes stratégies possibles avec avantages/inconvénients, ressources, coûts, délais rapport d’analyse préliminaire ou schéma directeur Principalement guidé par l’expérience BTS IRIS 2 GL

14 Analyse des besoins qualités fonctionnelles attendues en termes des services offerts qualités non fonctionnelles attendues : efficacité, sûreté, sécurité, facilité d’utilisation, portabilité, etc. qualités attendues du procédé de développement (ex : procédures de contrôle qualité) cahier des charges + plan qualité Le cahier des charges peut inclure une partie destinée aux clients (définition de ce que peuvent attendre les clients) et une partie destinée aux concepteurs (spécification des besoins) BTS IRIS 2 GL

15 Cahier des charges document contractuel
décrit ce qui est attendu du maître d'œuvre par le maître d'ouvrage décrit de façon précise (avec un vocabulaire simple) les besoins auxquels le maître d'œuvre doit répondre fait apparaître le besoin de manière fonctionnelle (indépendamment de toute solution technique) BTS IRIS 2 GL

16 Cahier des charges But :
garantir au maître d'ouvrage que les livrables seront conformes à ce qui est écrit éviter que le souhait soit modifié au fur et à mesure du projet BTS IRIS 2 GL

17 Cahier des charges permet au maître d'œuvre de juger de la taille du projet et de sa complexité afin de proposer une offre la plus adaptée possible (coût, délai, de ressources humaines, qualité) document de référence, permettant de lever toute ambiguïté sur ce qui était attendu un outil de dialogue permettant au maître d'œuvre d'interroger le maître d'ouvrage afin d'affiner sa compréhension de la demande BTS IRIS 2 GL

18 Éléments principaux du CdC
Contexte : Un cahier des charges commence généralement par une section décrivant le contexte, c'est-à-dire notamment le positionnement politique et stratégique du projet. Objectifs : Très rapidement, le cahier des charges doit permettre de comprendre le but recherché, afin de permettre au maître d'œuvre d'en saisir le sens. Dictionnaire : Nombre de projets échouent à cause d'une mauvaise communication et en particulier à cause d'un manque de culture et de vocabulaires communs entre maîtrise d'œuvre et maîtrise d'ouvrage. En effet, là où le maître d'ouvrage croît employer un vocabulaire générique, le maître d'œuvre entend parfois un terme technique avec une signification particulière. BTS IRIS 2 GL

19 Éléments principaux du CdC
Périmètre : Le périmètre du projet permet de définir le nombre de personnes ou les ressources qui seront impactées par sa mise en place. Calendrier : Le calendrier souhaité par le maître d'ouvrage doit être très clairement explicité et faire apparaître la date à laquelle le projet devra impérativement être terminé. Idéalement des jalons seront précisés afin d'éviter un « effet tunnel ». Clauses juridiques : Un cahier des charges étant un document contractuel, cosigné par la maîtrise d'œuvre et la maîtrise d'ouvrage, possède généralement un certain nombre de clauses juridiques permettant par exemple de définir à qui revient la propriété intellectuelle de l'ouvrage, les pénalités en cas de non-respect des délais ou encore les tribunaux compétents en cas de litige BTS IRIS 2 GL

20 Analyse du système modélisation
du domaine de l’existant (éventuellement) définition d’un modèle conceptuel (ou spécification conceptuelle), plan de validation. dossier d’analyse + plan de validation BTS IRIS 2 GL

21 Conception proposition de solution au problème spécifié dans l’analyse
organisation de l’application en modules et interface des modules (architecture du logiciel), description détaillée des modules avec les algorithmes essentiels (modèle logique) structuration des données. dossier de conception + plan de test global et par module BTS IRIS 2 GL

22 Programmation et tests unitaires
traduction dans un langage de programmation, tests avec les jeux d’essais par module selon le plan de test. dossiers de programmation et codes sources BTS IRIS 2 GL

23 Intégration et test d’intégration
composition progressive des modules, tests des regroupements de modules, test en vraie grandeur du système complet selon le plan de test global (‘alpha testing’) Parfois très long (Half Life 2) BTS IRIS 2 GL

24 Installation Mise en fonctionnement opérationnel chez les utilisateurs. Parfois restreint dans un premier temps à des utilisateurs sélectionnés (« beta testing »). BTS IRIS 2 GL

25 Maintenance maintenance corrective (ou curative)
Dans le contrat maintenance adaptative Mises à jour maintenance perfective Nouvelles versions BTS IRIS 2 GL

26 Activités transversales
Spécification Documentation validation et vérification Management BTS IRIS 2 GL

27 Le modèle en V BTS IRIS 2 GL

28 Principe du modèle en V démarche reste linéaire
mais fait mieux apparaître : les produits intermédiaires à des niveaux d’abstraction et de formalité différents et les procédures d’acceptation (validation et vérification) de ces produits intermédiaires. les activités de construction précèdent les activités de validation et vérification Mais l’acceptation est préparée dès la construction (flèches de gauche à droite). Cela permet de mieux approfondir la construction et de mieux planifier la ‘remontée’. BTS IRIS 2 GL

29 Modèle incrémental BTS IRIS 2 GL

30 Principe du modèle incrémental
Ces méthodes ne sont pas parfaites Dérives bureaucratiques (on passe plus de temps à faire des documents qu’à coder…) Méthode bien sur le papier, mais dans la réalité, il est difficile de procéder de manière linéaire Modèle incrémental Le produit est délivré en plusieurs fois, de manière incrémentale, c’est à dire en le complétant au fur et à mesure et en profitant de l’expérimentation opérationnelle des incréments précédents. Chaque incrément peut donner lieu à un cycle de vie classique plus ou moins complet. Les premiers incréments peuvent être des maquettes (jetables s’il s’agit juste de comprendre les besoins des utilisateurs) ou des prototypes (réutilisables pour passer au prochain incrément en les complétant et/ou en optimisant leur implantation). Le risque de cette approche est celui de la remise en cause du noyau.

31 En réalité Il n’y a pas de modèle idéal car tout dépend des circonstances Le modèle en cascade ou en V est risqué pour les développements innovants car les spécifications et la conception risquent d’être inadéquats et souvent remis en cause Le modèle incrémental est risqué car il ne donne pas beaucoup de visibilité sur le processus complet Souvent, un même projet peut mêler différentes approches, exemple : prototypage pour les sous-systèmes à haut risque cascade pour les sous systèmes bien connus et à faible risque BTS IRIS 2 GL

32 La normalisation des processus
De nombreuses normes sont apparues dans les années 90 pour évaluer les processus en fonction de normes de qualité USA : le standard CMM du SEI (Software Engineering Institute du DoD - Department Of Defense des USA) UE : les normes ISO 9000 (9003) et ISO SPICE attestent qu’une entreprise suit un processus orienté qualité Qualité : Définition donnée par la Norme ISO 9000:2000  : Aptitude d'un ensemble de caractéristiques intrinsèques à satisfaire des exigences capacité à atteindre les objectifs opérationnels visés Les sociétés sont certifiées en fonction de leur respect de ces normes Cela ne donne pas de garantie sur la qualité du produit lui même BTS IRIS 2 GL

33 La spécification BTS IRIS 2 GL

34 Définition Tout produit complexe à construire doit d’abord être spécifié Exemple : un pont de 30 mètres de long, supportant au moins 1000 tonnes, construit en béton, etc. Ces spécifications peuvent être considérées comme un contrat entre un client et un producteur De manière générale une spécification décrit les caractéristiques attendues (le quoi) BTS IRIS 2 GL

35 Spécification et cycle de vie
La spécification des besoins (contrat entre les futurs utilisateurs et les concepteurs) concerne les caractéristiques attendues (exigences fonctionnelles et non fonctionnelles) La spécification d’un système (contrat entre les futurs utilisateurs et les concepteurs) concerne la nature des fonctions offertes, les comportements souhaités, les données nécessaires… La spécification d’une architecture de système (contrat entre les concepteurs et les réalisateurs) définit l’architecture en modules de l’application à réaliser La spécification technique d’un module, d’un programme, d’une structure de données ou d’un type de données (contrat entre le programmeur qui l’implante et les programmeurs qui l’utilisent) défini la technologie à utiliser. BTS IRIS 2 GL

36 conclusion Différentes techniques et styles existent
Souvent les techniques de spécifications se complètent, en décrivant des vues complémentaires d’un système Parler des techniques de spécification est comme parler des langages de programmation : Il n’y a ni langage ni technique idéale, ni langage ni technique permettant de tout faire. L’informaticien doit avoir une culture assez étendue des diverses techniques comme des divers langages BTS IRIS 2 GL

37 La conception BTS IRIS 2 GL

38 Définition La conception propose une solution (le comment) au problème spécifié lors de l’analyse : architecture de l’application (architecture logicielle et architecture physique) description détaillée des modules, des interfaces utilisateurs, des données Elle donne lieu à un dossier de conception avec souvent une partie destinée au client (présentation de la solution) et une partie pour les réalisateurs (conception technique) La conception de l’architecture logicielle, concerne la décomposition du système en modules, avec la description abstraite de ce que chaque module doit faire et la description des relations entre les modules La description précise du contenu des modules relève de la phase de conception détaillée BTS IRIS 2 GL

39 Modules et relation Un module est un composant d’une application, contenant des définitions de données et/ou de types de données et/ou de fonctions et constituant un tout cohérent On peut définir un module comme un fournisseur de ressources ou de services Quand on décompose un système en modules il faut décrire précisément les relations entre ces modules BTS IRIS 2 GL

40 Démarches de conception
Deux (principales) démarches de conception : l'approche fonctionnelle l'approche à objets Dans l'approche à objets, les modules principaux correspondent aux objets concrets ou abstraits du domaine de l'application Ce sont des entités autonomes qui collaborent pour réaliser le système global BTS IRIS 2 GL

41 Interface et encapsulation
Objectif : diviser un système en composants qui peuvent être conçus indépendamment la nature de la relation d'utilisation doit être explicitement et précisément spécifiée : c’est son interface La manière dont ces services sont réalisés ne doit pas apparaitre : c’est son implémentation On sépare ainsi : la vue abstraite d’un module : nécessaire par ses clients (le ‘contrat’ passé entre le module et ses clients) la vue de son implémentation. BTS IRIS 2 GL

42 Interface et encapsulation
On peut programmer un module en ne connaissant que les interfaces des autres modules En pratique, en conception objet, l’interface décrit principalement les objets du module, leurs attributs publics et leurs méthodes publics Le reste de l’information doit être caché (encapsulé) dans l’implémentation. La partie encapsulée peut être modifiée, sans aucun impact sur les modules clients à partir du moment où l’interface ne change pas BTS IRIS 2 GL

43 Autres aspects de la conception
D'autres aspects doivent être considérés par les concepteurs: conception des interfaces utilisateurs conception des algorithmes conception des bases de données etc. Les systèmes étant de plus en plus souvent distribués sur un réseau, une phase de conception de la l'architecture physique de l'application peut-être nécessaire Les différents modules (présentation, logique applicative, gestion des données…) sont répartis sur ces architectures physiques BTS IRIS 2 GL

44 La vérification BTS IRIS 2 GL

45 Définition Tous les produits du cycle de vie doivent être vérifiés (pas seulement le code) Le résultat de ces vérifications n’est pas nécessairement binaire (acceptation ou rejet du produit), des défauts peuvent être tolérés (correctifs, pack) Il existe deux approches complémentaires de la vérification: expérimenter le comportement de l’application (la tester) avec un ensemble bien choisi de données (vérification dynamique) analyser les propriétés du système, sans exécution (vérification statique) BTS IRIS 2 GL

46 Vérification dynamique : les Tests
Les tests ont pour but de mettre en évidence les erreurs se font à partir de jeux de tests (jeux d’essais) Le programme est exécuté avec un jeu de tests Les résultats obtenus sont comparés aux résultats attendus Les tests peuvent prouver la présence d’erreurs mais ne peuvent pas prouver leur absence BTS IRIS 2 GL

47 Construction des jeux de tests
Approche aléatoire : Le jeu de tests est sélectionné au hasard sur le domaine de définition des entrées Le domaine de définition déterminé à l’aide des interfaces de la spécification ou du programme Pas une bonne couverture de l’ensemble des entrées Ne traite pas des cas limites ou exceptionnels efficacité très variable BTS IRIS 2 GL

48 Construction des jeux de tests
Approche fonctionnelle (boîte noire) : considère uniquement la spécification de ce que doit faire le programme (sans considérer sa structure interne) vérifier chaque fonctionnalité décrite dans la spécification Avantage : on peut écrire ces tests très tôt, dès qu'on connaît la spécification BTS IRIS 2 GL

49 Construction des jeux de tests
Approche structurelle (boîte blanche) : on tient compte de la structure interne du module On peut s’appuyer sur différents critères pour conduire le test (couverture des instructions, graphe de contrôle, couverture des conditions…) BTS IRIS 2 GL

50 Types de tests Test unitaires de programmes ou de modules :
test d’un programme isolé ou d’un module Pour tester un module, il faut simuler le comportement des modules appelés et simuler les appels du module Tests d’intégration Après Tests unitaires tester leur intégration progressive jusqu’au système complet Test alpha : l’application est mise dans des conditions réelles d’utilisation, au sein de l’équipe de développement (simulation de l’utilisateur final) Test de réception effectué par l'acquéreur (avec la participation du fournisseur ) après installation d'un système dans ses locaux Test bêta : distribution du produit sur un groupe de clients avant la version définitive Tests de non régression suite à la modification d'un logiciel (ou d'un de ses constituants) a pour but de montrer que les autres parties du logiciel n'ont pas été affectées par cette modification BTS IRIS 2 GL

51 Vérifications statiques
Techniques informelles activités réalisées par un groupe d’inspecteurs qui examinent un document à la recherche d’erreurs Dans le cas de code, les participants peuvent ‘jouer à la machine’ (« code walk-through ») Dans le cas de code ou de documents de conception, les participants peuvent faire des « revues » ou « inspections » en s’aidant d’une liste des défauts les plus courants Techniques formelles prouver formellement la correction d’un programme Le programme est caractérisé par sa précondition (condition éventuelle à respecter par les données du programme) et sa postcondition (condition vraie à la fin du programme qui définit donc son objectif) Méthode de Hoare définit des assertions logiques intermédiaires permettant de prouver la correction en remontant de la post-condition à la pré-condition du programme BTS IRIS 2 GL

52 Méthodes d’analyse et de conception
BTS IRIS 2 GL

53 Définition propose une démarche, distinguant les étapes du développement dans le cycle de vie du logiciel et exploitant au mieux les principes fondamentaux : modularité, réduction de la complexité, réutilisation, abstraction, etc., propose des formalismes (langages) et des types de documents (modèles), qui facilitent la communication, l’organisation et la vérification BTS IRIS 2 GL

54 Différentes méthodes méthodes fonctionnelles de décomposition hiérarchique (1ère génération) : application du principe diviser pour régner (problème -> sous problèmes) SADT, SA-SD, ... méthodes systémiques (2ème génération) : séparation données/traitements, niveaux conceptuels, organisationnels, physiques MERISE, SSADM, ... méthodes objets (3ème génération) : OMT, OOSE, OOM, UML, ... BTS IRIS 2 GL

55 Principaux objectifs des méthodes objets
regrouper l’analyse des données et des traitements établir un couplage explicite entre les concepts du monde réel et les composants exécutables faciliter la réutilisation simplifier les transformations entre le niveau conceptuel et l’implantation BTS IRIS 2 GL

56 Et UML dans tout ça ? BTS IRIS 2 GL

57 Les vues d’UML BTS IRIS 2 GL

58 Démarche naturelle BTS IRIS 2 GL

59 Diagrammes et phases Analyse des besoins : cas d’utilisation
Analyse du système : diagrammes de classes, de collaboration, d’activités (enchaînement des cas) Conception : diagrammes de classes, de séquences, d’activités (conception des méthodes), d’états, de composants, de déploiement. BTS IRIS 2 GL

60 Outils, aspects organisationnels et humains
BTS IRIS 2 GL

61 Grandes catégories les outils dédiés à des tâches spécifiques
les ateliers de génie logiciel (AGL) : intègrent plusieurs outils supportant une partie des activités du développement les environnements intégrés, qui visent à supporter tout le développement (cycle de vie et activités transversales) BTS IRIS 2 GL

62 Les principaux outils Les outils d’édition outils de programmation
outils de vérification outils de gestion de version et de gestion de configurations outils de gestion de projet et de productivité individuelle ou collective BTS IRIS 2 GL

63 Aspects organisationnels et humains
La gestion de projet inclut de nombreuses activités telles que : écriture des propositions de projets estimation des coûts des projets planification et l’ordonnancement des projets suivi et l’évaluation des projets Sélection et évaluation des personnels et l’organisation des équipes rédaction des rapports de gestion 3 grands tâches : Organisation des équipes Planification Estimation des coûts BTS IRIS 2 GL

64 Diagramme de GANTT outil permettant de modéliser la planification de tâches nécessaires à la réalisation d'un projet facilité de lecture => utilisé par la quasi-totalité des chefs de projet dans tous les secteurs permet de représenter graphiquement l'avancement du projet (mais également un moyen de communication entre les différents acteurs d'un projet) facile à mettre en œuvre avec un simple tableur ou des outils spécialisés Fait apparaître : Tâches Dates Éléments supplémentaires : Tâches jalons Ressources BTS IRIS 2 GL

65 Diagramme de GANTT BTS IRIS 2 GL


Télécharger ppt "Génie logiciel et Gestion de projet"

Présentations similaires


Annonces Google