G

1
Génie logicielet Gestion de projet
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

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

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 dexpérimentation
  météorologique à cause dun bug logiciel
• panne, en 1990, du réseau téléphonique de la cote
  Est des USA suite à un changement de version dun
  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 dARIANE 501 suite à un bug logiciel
• Invalidation de version de Windows suite au
  changement de version du Windows Genuine
  Advantage

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

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)
• gt comment être sûrs que ces spécifications sont
  complètes ?
• gt comment être sûrs que ces spécification sont
  cohérentes ?
• valider/vérifier toutes les étapes du
  développements
• gt 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)
• gt a-t-on des règles, des outils pour aider à la
  réutilisation ?
• nécessité dune base théorique et dune approche
  ingénierie (science de lingé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.

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
12
Le modèle en cascade
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 danalyse préliminaire ou schéma
  directeur
• Principalement guidé par lexpérience

14
Analyse des besoins

• qualités fonctionnelles attendues en termes des
  services offerts
• qualités non fonctionnelles attendues
  efficacité, sûreté, sécurité, facilité
  dutilisation, 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)

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)

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

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

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.

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

20
Analyse du système

• modélisation
• du domaine
• de lexistant (éventuellement)
• définition dun modèle conceptuel (ou
  spécification conceptuelle),
• plan de validation.
• dossier danalyse plan de validation

21
Conception

• proposition de solution au problème spécifié dans
  lanalyse
• organisation de lapplication 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

22
Programmation et testsunitaires

• traduction dans un langage de programmation,
• tests avec les jeux dessais par module selon le
  plan de test.
• dossiers de programmation et codes sources

23
Intégration et test dinté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)

24
Installation

• Mise en fonctionnement opérationnel chez les
  utilisateurs.
• Parfois restreint dans un premier temps à des
  utilisateurs sélectionnés ( beta testing ).

25
Maintenance

• maintenance corrective (ou curative)
• Dans le contrat
• maintenance adaptative
• Mises à jour
• maintenance perfective
• Nouvelles versions

26
Activités transversales

• Spécification
• Documentation
• validation et vérification
• Management

27
Le modèle en V
28
Principe du modèle en V

• démarche reste linéaire
• mais fait mieux apparaître
• les produits intermédiaires à des niveaux
  dabstraction et de formalité différents
• et les procédures dacceptation (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 lacceptation 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.

29
Modèle incrémental
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, cest à dire en le
  complétant au fur et à mesure et en profitant de
  lexpé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 sil sagit 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 ny 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

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 quune entreprise suit un processus
  orienté qualité
• Qualité
• Définition donnée par la Norme ISO 90002000  
  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

33
La spécification
34
Définition

• Tout produit complexe à construire doit dabord
  ê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)

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 dun 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 dune architecture de système
  (contrat entre les concepteurs et les
  réalisateurs) définit larchitecture en modules
  de lapplication à réaliser
• La spécification technique dun module, dun
  programme, dune structure de données ou dun
  type de données (contrat entre le programmeur qui
  limplante et les programmeurs qui lutilisent)
  défini la technologie à utiliser.

36
conclusion

• Différentes techniques et styles existent
• Souvent les techniques de spécifications se
  complètent, en décrivant des vues complémentaires
  dun système
• Parler des techniques de spécification est comme
  parler des langages de programmation Il ny a
  ni langage ni technique idéale, ni langage ni
  technique permettant de tout faire.
• Linformaticien doit avoir une culture assez
  étendue des diverses techniques comme des divers
  langages

37
La conception
38
Définition

• La conception propose une solution (le comment)
  au problème spécifié lors de lanalyse
• architecture de lapplication (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 larchitecture 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

39
Modules et relation

• Un module est un composant dune 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

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

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 cest
  son interface
• La manière dont ces services sont réalisés ne
  doit pas apparaitre cest son implémentation
• On sépare ainsi
• la vue abstraite dun module nécessaire par ses
  clients (le contrat passé entre le module et
  ses clients)
• la vue de son implémentation.

42
Interface et encapsulation

• On peut programmer un module en ne connaissant
  que les interfaces des autres modules
• En pratique, en conception objet, linterface
  décrit principalement les objets du module, leurs
  attributs publics et leurs méthodes publics
• Le reste de linformation doit être caché
  (encapsulé) dans limplémentation.
• La partie encapsulée peut être modifiée, sans
  aucun impact sur les modules clients à partir du
  moment où linterface ne change pas

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

44
La vérification
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 nest 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 lapplication (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)

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 dessais)
• 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 derreurs
  mais ne peuvent pas prouver leur absence

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é à laide des
  interfaces de la spécification ou du programme
• Pas une bonne couverture de lensemble des
  entrées
• Ne traite pas des cas limites ou exceptionnels
• efficacité très variable

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

49
Construction des jeux de tests

• Approche structurelle (boîte blanche)
• on tient compte de la structure interne du module
• On peut sappuyer sur différents critères pour
  conduire le test (couverture des instructions,
  graphe de contrôle, couverture des conditions)

50
Types de tests

• Test unitaires de programmes ou de modules
• test dun programme isolé ou dun module
• Pour tester un module, il faut simuler le
  comportement des modules appelés et simuler les
  appels du module
• Tests dintégration
• Après Tests unitaires
• tester leur intégration progressive jusquau
  système complet
• Test alpha lapplication est mise dans des
  conditions réelles dutilisation, au sein de
  léquipe de développement (simulation de
  lutilisateur 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

51
Vérifications statiques

• Techniques informelles
• activités réalisées par un groupe dinspecteurs
  qui examinent un document à la recherche
  derreurs
• 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 saidant dune
  liste des défauts les plus courants
• Techniques formelles
• prouver formellement la correction dun 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

52
Méthodes danalyse et de conception
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, lorganisation et la vérification

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 -gt 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, ...

55
Principaux objectifs des méthodes objets

• regrouper lanalyse 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 limplantation

56
Et UML dans tout ça ?
57
Les vues dUML
58
Démarche naturelle
59
Diagrammes et phases

• Analyse des besoins cas dutilisation
• Analyse du système diagrammes de classes, de
  collaboration, dactivités (enchaînement des cas)
• Conception diagrammes de classes, de séquences,
  dactivités (conception des méthodes), détats,
  de composants, de déploiement.

60
Outils, aspects organisationnelset humains
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)

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

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 lordonnancement des projets
• suivi et lévaluation des projets
• Sélection et évaluation des personnels et
  lorganisation des équipes
• rédaction des rapports de gestion
• 3 grands tâches
• Organisation des équipes
• Planification
• Estimation des coûts

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 gt 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

65
Diagramme de GANTT