Atelier Génie Logiciel 1 - Polytech Paris XI - 2018 2019- Génie Logiciel-Frédéric Voisin - Valérie GUIMARD - RAPPELS

 
CONTINUER À LIRE
Atelier Génie Logiciel 1 - Polytech Paris XI - 2018 2019- Génie Logiciel-Frédéric Voisin - Valérie GUIMARD - RAPPELS
Atelier Génie Logiciel
                                                         1

                                                  RAPPELS

Polytech Paris XI – 2018 2019– Génie Logiciel- Frédéric Voisin - Valérie GUIMARD - RAPPELS
Atelier Génie Logiciel 1 - Polytech Paris XI - 2018 2019- Génie Logiciel-Frédéric Voisin - Valérie GUIMARD - RAPPELS
AGL
                                                         2

Polytech Paris XI – 2018 2019– Génie Logiciel- Frédéric Voisin - Valérie GUIMARD - RAPPELS
Atelier Génie Logiciel 1 - Polytech Paris XI - 2018 2019- Génie Logiciel-Frédéric Voisin - Valérie GUIMARD - RAPPELS
AGL
                                                         3

Polytech Paris XI – 2018 2019– Génie Logiciel- Frédéric Voisin - Valérie GUIMARD - RAPPELS
Atelier Génie Logiciel 1 - Polytech Paris XI - 2018 2019- Génie Logiciel-Frédéric Voisin - Valérie GUIMARD - RAPPELS
AGL
                                                               4

    En effet, il faut s’assurer
    -   d’avoir bien compris le besoin
    -   D’avoir réalisé un lotissement efficace permettant d’assurer des livraisons cohérentes et d’optimiser les temps de
        développement
    -   D’avoir réaliser un code facilement modifiable pour les prochaines évolutions

    Mais aussi réaliser :
    -  l’architecture
    -  La définition des composants et comprendre les relations entre eux
    -  Les tests unitaires, d’intégrations et de montée en charge

    Et effectuer :
    -   Le suivi des besoins utilisateurs pour intégrer les améliorations
    -   La corrections des anomalies
    -   La documentation utilisateur
    -   La documentation d’installation de l’application
    -   La documentation du code pour la reprise

Polytech Paris XI – 2018 2019– Génie Logiciel- Frédéric Voisin - Valérie GUIMARD - RAPPELS
Atelier Génie Logiciel 1 - Polytech Paris XI - 2018 2019- Génie Logiciel-Frédéric Voisin - Valérie GUIMARD - RAPPELS
AGL
                                                         5

     Pourquoi documenter ?

     ● Pour définir le contenu du projet et s’assurer de l’accord de toutes
     les parties prenantes et des membres de l’équipe

     ● Pour établir une référence qui permettra de résoudre des différends
     entre les parties prenantes si nécessaire

     ● Pour garder une référence historique fournissant des informations
     détaillées sur le projet

Polytech Paris XI – 2018 2019– Génie Logiciel- Frédéric Voisin - Valérie GUIMARD - RAPPELS
Atelier Génie Logiciel 1 - Polytech Paris XI - 2018 2019- Génie Logiciel-Frédéric Voisin - Valérie GUIMARD - RAPPELS
AGL
                                                         6
  Documentation

Polytech Paris XI – 2018 2019– Génie Logiciel- Frédéric Voisin - Valérie GUIMARD - RAPPELS
Atelier Génie Logiciel 1 - Polytech Paris XI - 2018 2019- Génie Logiciel-Frédéric Voisin - Valérie GUIMARD - RAPPELS
AGL
                                                              7

                                  Analyse des besoins et spécifications

   Objectif Fournir une vue claire de ce que doit faire le logiciel :
   le cahier des charges fonctionnel
       ● Définir les fonctionnalités du produit
       ● Déterminer les contraintes de conception du logiciel

       ● Clarifier le cahier des charges (ambiguïtés, contradictions)

   Enjeu Contrat entre le client et le fournisseur :
       ● Pour le client : tous les besoins sont exprimés
       ● Pour le fournisseur : tous les besoins exprimés sont réalisables

   Méthode Affiner le cahier des charges initial validé par des aller-retours avec le client

Polytech Paris XI – 2018 2019– Génie Logiciel- Frédéric Voisin - Valérie GUIMARD - RAPPELS
Atelier Génie Logiciel 1 - Polytech Paris XI - 2018 2019- Génie Logiciel-Frédéric Voisin - Valérie GUIMARD - RAPPELS
AGL
                                                         8

Polytech Paris XI – 2018 2019– Génie Logiciel- Frédéric Voisin - Valérie GUIMARD - RAPPELS
Atelier Génie Logiciel 1 - Polytech Paris XI - 2018 2019- Génie Logiciel-Frédéric Voisin - Valérie GUIMARD - RAPPELS
AGL
                                                              9

          Contenu du cahier des charges fonctionnel

      Description générale
              ● Contexte d'utilisation (utilisateurs, environnement)
              ● Fonctionnalités
              ● Interface utilisateur
              ● Contraintes matérielles, de performance, de sécurité...

      Spécification des exigences
              ● Exigences fonctionnelles : spécification des cas d'utilisation,
              scénarios d'utilisation
              ● Interface : prototype, storyboard, lien avec les fonctionnalités
              ● Exigences non fonctionnelles : utilisabilité, performance,
              sécurité...

Polytech Paris XI – 2018 2019– Génie Logiciel- Frédéric Voisin - Valérie GUIMARD - RAPPELS
Atelier Génie Logiciel 1 - Polytech Paris XI - 2018 2019- Génie Logiciel-Frédéric Voisin - Valérie GUIMARD - RAPPELS
AGL
                                                          10

      Contexte d'utilisation
      Contexte d'utilisation
          ● Utilisateurs : expérience, compétences, connaissance du système
          ● Utilisation : fréquence, durée d'utilisation

          ● Environnement technique : matériel, ressources, réseau

      Permet de spécifier les contraintes de qualité en termes de
          ● facilité d'utilisation
          ● efficacité

          ● fiabilité, portabilité

Polytech Paris XI – 2018 2019– Génie Logiciel- Frédéric Voisin - Valérie GUIMARD - RAPPELS
AGL
                                                         11

      Cas et scénarios d'utilisation
      Cas d'utilisation
      ● Fonctions principales du logiciel

      ● Ensemble de scénarios réalisant un objectif de l'utilisateur

      Scénarios d'utilisation Séquence d'interactions entre l'utilisateur et le logiciel dont le résultat est
      observable au moins un scénario par cas d'utilisation + variantes et scénarios d'erreur

      Objectif Base pour les échanges avec le client pour la validation des besoins identifiés

Polytech Paris XI – 2018 2019– Génie Logiciel- Frédéric Voisin - Valérie GUIMARD - RAPPELS
AGL
                                                             12

  Spécification d'un cas d'utilisation
  Spécification détaillée
      ● Nom  du cas d'utilisation
      ● Brève description
      ● Acteurs
      ● Contexte
      ● Données en entrée et pré-conditions
      ● Données en sortie et post-conditions
      ● Scénario principal pour ce cas d'utilisation (texte + diagramme)
      ● Variantes, cas d'erreur
      ● Exigences non fonctionnelles liées

Polytech Paris XI – 2018 2019– Génie Logiciel- Frédéric Voisin - Valérie GUIMARD - RAPPELS
AGL
                                                         13

   Pourquoi Modéliser ?

       Pour mieux comprendre le fonctionnement du système.
       Pour maîtriser sa complexité
       Pour assurer sa cohérence.
       Pour définir un langage commun, précis, qui est connu par tous les membres de l’équipe
       Pour communiquer.

            Cette communication est essentielle pour aboutir à une compréhension
                         commune aux différentes parties prenantes
       (notamment entre la maîtrise d’ouvrage et la maîtrise d’œuvre informatique)
                            et précise d’un problème donné.

Polytech Paris XI – 2018 2019– Génie Logiciel- Frédéric Voisin - Valérie GUIMARD - RAPPELS
AGL
                                                         14

   Dans le domaine de l’ingénierie du logiciel, le modèle permet
      de mieux répartir les tâches
      d’automatiser certaines d’entre elles.
      De réduire les coûts
      De réduire les délais.

   Le modèle est indispensable pour assurer un bon niveau de qualité mais aussi une maintenance
   efficace.

   En effet, une fois mise en production, l’application va devoir être maintenue, probablement par une
   autre équipe et, qui plus est, pas nécessairement de la même société que celle ayant créée l’application.

                Le choix du modèle a donc une influence capitale sur les solutions obtenues.
                Selon les modèles employés, la démarche de modélisation n’est pas la même.

Polytech Paris XI – 2018 2019– Génie Logiciel- Frédéric Voisin - Valérie GUIMARD - RAPPELS
AGL
                                                         15

Règles d’échanges entre la MOE et la MOA

   Le MOA est client du MOE à qui il passe commande d’un produit nécessaire à son activité.

   Le MOE fournit ce produit ; soit il le réalise lui-même, soit il passe commande à un ou plusieurs
   fournisseurs (« entreprises ») qui élaborent le produit sous sa direction.

   La relation MOA et MOE est définie par un contrat qui précise leurs engagements mutuels.

   Lorsque le produit est compliqué, il peut être nécessaire de faire appel à plusieurs fournisseurs. Le
   MOE assure leur coordination ; il veille à la cohérence des fournitures et à leur compatibilité. Il
   coordonne l’action des fournisseurs en contrôlant la qualité technique, en assurant le respect des délais
   fixés par le MOA et en minimisant les risques.

   Le MOE est responsable de la qualité technique de la solution. Il doit, avant toute livraison au MOA,
   procéder aux vérifications nécessaires

Polytech Paris XI – 2018 2019– Génie Logiciel- Frédéric Voisin - Valérie GUIMARD - RAPPELS
AGL
                                                                 16

En génie logiciel, divers travaux ont mené à la définition de la qualité du logiciel en termes de facteurs, qui dépendent, entre
autres, du domaine de l’application et des outils utilisés. Parmi ces derniers nous pouvons citer :
Critères de qualité

       Validité : aptitude d’un produit logiciel à remplir exactement ses fonctions, définies par le cahier des charges et les
        spécifications.
       Fiabilité ou robustesse : aptitude d’un produit logiciel à fonctionner dans des conditions anormales.
       Extensibilité (maintenance) : facilité avec laquelle un logiciel se prête à sa maintenance, c’est-à-dire à une modification
        ou à une extension des fonctions qui lui sont demandées.
       Réutilisabilité : aptitude d’un logiciel à être réutilisé, en tout ou en partie, dans de nouvelles applications.
       Compatibilité : facilité avec laquelle un logiciel peut être combiné avec d’autres logiciels.
       Efficacité : Utilisation optimales des ressources matérielles.
       Portabilité : facilité avec laquelle un logiciel peut être transféré sous différents environnements matériels et logiciels.
       Vérifiabilité : facilité de préparation des procédures de test.
       Intégrité : aptitude d’un logiciel à protéger son code et ses données contre des accès non autorisés.
       Facilité d’emploi : facilité d’apprentissage, d’utilisation, de préparation des données, d’interprétation des erreurs et de
        rattrapage en cas d’erreur d’utilisation.
        Ces facteurs sont parfois contradictoires, le choix des compromis doit s’effectuer en fonction du contexte.

Polytech Paris XI – 2018 2019– Génie Logiciel- Frédéric Voisin - Valérie GUIMARD - RAPPELS
Introduction
                                                         17

Notions de Cycle de vie

Le cycle de vie d’un logiciel désigne toutes les étapes du développement d’un logiciel, de
sa conception à sa disparition.
L’objectif d’un tel découpage est de permettre de définir des jalons intermédiaires
permettant la validation du développement logiciel, c’est-à-dire la conformité du logiciel
avec les besoins exprimés, et la vérification du processus de développement, c’est-à-dire
l’adéquation des méthodes mises en œuvre.

    L’origine de ce découpage provient du constat que les erreurs ont un coût d’autant
    plus élevé qu’elles sont détectées tardivement dans le processus de
    réalisation.

Polytech Paris XI – 2018 2019– Génie Logiciel- Frédéric Voisin - Valérie GUIMARD - RAPPELS
AGL
                                                                    18

   Le cycle de vie du logiciel comprend généralement au minimum les étapes suivantes :
      Définition des objectifs – Cet étape consiste à définir la finalité du projet et son inscription dans une stratégie globale.
      Analyse des besoins et faisabilité – c’est-à-dire l’expression, le recueil et la formalisation des besoins du demandeur
       (le client) et de l’ensemble des contraintes, puis l’estimation de la faisabilité de ces besoins.
      Spécifications ou conception générale – Il s’agit de l’élaboration des spécifications de l’architecture générale du
       logiciel.
      Conception détaillée – Cette étape consiste à définir précisément chaque sous-ensemble du logiciel.
      Codage (Implémentation ou programmation) – c’est la traduction dans un langage de programmation des
       fonctionnalités définies lors de phases de conception.
      Tests unitaires – Ils permettent de vérifier individuellement que chaque sous-ensemble du logiciel est implémenté
       conformément aux spécifications.
      Intégration – L’objectif est de s’assurer de l’interfaçage des différents éléments (modules) du logiciel. Elle fait l’objet de
       tests d’intégration consignés dans un document.
      Qualification (ou recette) – C’est-à-dire la vérification de la conformité du logiciel aux spécifications initiales.
      Documentation – Elle vise à produire les informations nécessaires pour l’utilisation du logiciel et pour des
       développements ultérieurs.
      Mise en production – C’est le déploiement sur site du logiciel.
      Maintenance – Elle comprend toutes les actions correctives (maintenance corrective) et évolutives (maintenance
       évolutive) sur le logiciel.

Polytech Paris XI – 2018 2019– Génie Logiciel- Frédéric Voisin - Valérie GUIMARD - RAPPELS
AGL : quelques causes d’échecs des projets
                                                         19

Polytech Paris XI – 2018 2019– Génie Logiciel- Frédéric Voisin - Valérie GUIMARD - RAPPELS
AGL – cycle en V
                                                         20

Polytech Paris XI – 2018 2019– Génie Logiciel- Frédéric Voisin - Valérie GUIMARD - RAPPELS
AGL – Méthode Agile
                                                            21

       Dans le secteur technologique, la méthode Agile est une nouvelle approche adoptée par les entreprises pour
       introduire les nouvelles applications de l'ère numérique.

       Elle consiste à étudier et évaluer rapidement si une solution convient ou non à l'organisation, à concevoir la
       solution, puis à vérifier si elle est vouée à l'échec ou, au succès

       Mettre en œuvre cette méthode pour la conception de nouveaux systèmes d’informations et leur adoption à
       l'échelle de l'entreprise diminue considérablement le risque ainsi que le temps et les ressources investis.

       Le principal défi est le consensus sachant les besoins de personnalisations varient en fonction des activités et
       qu’ils deviennent plus spécifiques à mesure que l’on descend dans l’organisation.

       Il devient possible de concevoir la bonne solution pour la bonne équipe et de limiter le risque de faire fausse
       route

Polytech Paris XI – 2018 2019– Génie Logiciel- Frédéric Voisin - Valérie GUIMARD - RAPPELS
AGL : Méthode Agile

       Les méthodes agiles partent du principe que spécifier et planifier dans les détails l'intégralité d'un
       produit avant de le développer (approche prédictive) est contre productif.

       Explications
       Cela revient à planifier dans les détails un trajet "Paris - Barcelone" en voiture par les petites routes.
       Spécifiant chaque villes et villages traversés, l'heure de passage associée, chaque rue empruntée dans
       les agglomérations, litres d'essence consommés, kilomètres parcourus, etc.

                                   Les imprévus ne manqueront pas d'arriver : embouteillages, déviations,
                                   travaux, sens de circulation inversés, voire la panne, etc. Rendant votre
                                   planification et vos spécifications très vite obsolètes.

       Le temps passé à planifier cet itinéraire semble perdu et on ressent une grande frustration de ne pas
       pouvoir appliquer notre plan à la lettre. Si l’on revient sur le projet informatique, il y a une incertitude
       inévitable, et le besoin ne peut pas être complètement connu tant que les utilisateurs ne l’ont pas utilisé

       L'idée consiste donc, à se fixer un premier objectif à court terme (une grande ville par exemple) et se
       lancer sur la route sans tarder.

                                   Une fois ce premier objectif atteint, on marque une courte pause et on adapte
                                   son itinéraire en fonction de la situation du moment.

       A coupler impérativement avec une approche globale car sinon on risque de se retrouver à Rome
       ….

Polytech Paris XI – 2018 2019– Génie Logiciel- Frédéric Voisin - Valérie GUIMARD - RAPPELS
AGL : Méthode Agile

                    Principe SCRUM

Polytech Paris XI – 2018 2019– Génie Logiciel- Frédéric Voisin - Valérie GUIMARD - RAPPELS
AGL : Rôles Scrum

        Le Scrum Master
        •    S’assure que les principes et les valeurs de Scrum sont respectés

        •    Facilite la communication au sein de l’équipe

        •    Cherche à améliorer la productivité et le savoir faire de son équipe

        L’équipe
        •    Pas de rôle bien déterminé : architecte, développeur, testeur
        •    Tous les membres de l’équipe apportent leur savoir faire pour accomplir les tâches

        •    Taille de 6 à 10 personnes en général et pouvant aller jusqu’à 200 personnes

        Le Product Owner
        •    Expert métier, définit les spécifications fonctionnelles
        •    Etablit la priorité des fonctionnalités à développer ou corriger

        •    Valide les fonctionnalités développées

        •    Joue le rôle du client

                                                                                                  Source : www.thierry-pigot.fr

Polytech Paris XI – 2018 2019– Génie Logiciel- Frédéric Voisin - Valérie GUIMARD - RAPPELS
AGL : Déroulé Scrum

Les sprints
Le cycle de vie Scrum est rythmé par des itérations de quelques heures à quelques semaines, les sprints.

Le product backlog
Le référentiel des exigences initiales est dressé et hiérarchisé avec le client. Il constitue ce que l’on nomme le product backlog. Il ne doit pas
nécessairement contenir toutes les fonctionnalités attendues dès le début du projet, il va évoluer durant le projet en parallèle des besoins du client.

User Story
Les fonctionnalités décrites portent le nom de User Stories et sont décrites en employant la terminologie utilisée par le client.

Une User Story ou Story contient généralement les informations suivantes :

•     ID – un identifiant unique

•     Nom – un nom court (entre 2 et 10 mots), descriptif de la fonctionnalité attendue par le client (ex. Export / Import Standard Sales Item). Le
      nom doit être suffisamment clair pour que les membres de l’équipe et le Product Owner comprennent de quelle fonction il s’agit. Le nom ne
      doit pas introduire d’ambigüités.

•     Importance – un entier qui fixe la priorité des Stories. La priorité d’une story peut être changée en cours de réalisation du projet.

•     Estimation – La quantité de travail nécessaire pour développer, tester, et valider cette fonctionnalité. L’unité de mesure peut être un nombre
      de jours idéaux (jours à 100% dédiés à la fonctionnalité) ou un nombre de points. Les estimations se font en relatif en comparant les
      estimations des stories terminées avec la story à estimer.

•     Demo – Un test relativement simple (ex : exporter un objet en XML puis l’effacer de la base, l’importer depuis le XML, à la fin l’objet doit être
      dans la base). Ce test constitue un test de validation.

•     Notes – toute autre information : clarifications, références documentaires…

                                                                                                                                    Source : www.thierry-pigot.fr

Polytech Paris XI – 2018 2019– Génie Logiciel- Frédéric Voisin - Valérie GUIMARD - RAPPELS
AGL : Déroulé Scrum

 le sprint planning meeting
 On organise, avant chaque sprint, une réunion de planification, le sprint planning meeting. Ce planning sélectionne dans le product
 backlog les exigences les plus prioritaires pour le client. Elles seront développées, testées et livrées au client à la fin du sprint.
 Elles constituent le sprint backlog, un sous ensemble du product backlog.

 La mêlée
 Au cours du sprint, il est organisé, chaque jour, une réunion d’avancement (environ 15 min) avec tous les membres de l’équipe afin
 de s’assurer que les objectifs du sprint seront tenus, c’est le Scrum ou mêlée. Chaque jour, après la réunion Scrum, le Scrum Master
 maintient un graphique appelé sprint burndown chart. Ce graphique donne une très bonne vision de ce qui a été fait et du rythme de
 travail de l’équipe. Il permet également d’anticiper si toutes les stories du Sprint Backlog seront terminées à la fin de l’itération ou non.

                                                                                                                      Source : www.thierry-pigot.fr

Polytech Paris XI – 2018 2019– Génie Logiciel- Frédéric Voisin - Valérie GUIMARD - RAPPELS
AGL : Déroulé Scrum

 Cette réunion n’a pas seulement un but purement informatif, mais aussi de stimuler l’esprit travail en équipe et le
 niveau d’engagement de chaque membre de l’équipe dans le projet. Durant la réunion chaque membre de l’équipe doit
 prendre la parole et présenter principalement les choses suivantes :
 •    Ce que j’ai fait hier et les éventuels problèmes rencontrés
 •    Ce que je vais faire aujourd’hui
 •    Est ce que j’ai des difficultés pour continuer mon travail.
 •    En faisant cet exercice quotidiennement chaque membre de l’équipe est au courant de ce que font ses collègues et il
      peut coordonner son travail et aider ou se faire aider en cas de difficultés.
 Le Scrum Meeting n’est pas une réunion pendant laquelle on cherche à résoudre les problèmes, mais uniquement à les
 identifier et les exprimer.

 Le Scrum Master a pour rôle d’apporter des solutions ou de déléguer à un autre membre de l’équipe la résolution des
 problèmes soulevés durant le Scrum Meeting. A la suite de cette réunion le Scrum Master met à jour le burndown chart.

                                                                                                      Source : www.thierry-pigot.fr

Polytech Paris XI – 2018 2019– Génie Logiciel- Frédéric Voisin - Valérie GUIMARD - RAPPELS
AGL : Déroulé Scrum

 A la fin d’un sprint, on fait une démonstration au client des derniers développements, le Sprint Review Meeting. C’est
 aussi l’occasion de faire un bilan, sur le fonctionnement de l’équipe et de trouver des points d’amélioration.
 De part ses valeurs, Scrum prône
 - l’adaptabilité, sous l’effet de l’expérience acquise et des spécificités du projet ce qui le rapproche de la méthode de
   production de Toyota.

 - La visibilité, pour évaluer les résultats du processus.

 - L’inspection, qui consiste à vérifier les écarts par rapport à l’objectif initial.

 Proposition de méthode

 Fusion des méthodes en cycle V et Agile pour ne garder que le meilleur des deux

 Maitrise des jalons et des engagements avec le cycle en V (suivi de planning, réunions
 d’avancement…)

 Agilité et visualisation rapide qui permet de se rendre compte très tôt du travail réalisé, et de son
 alignement sur le besoin avec la méthode Agile                                       Source : www.thierry-pigot.fr

Polytech Paris XI – 2018 2019– Génie Logiciel- Frédéric Voisin - Valérie GUIMARD - RAPPELS
UML
                                                         29

    Eléments des diagrammes d’utilisateurs
      L’acteur représente
          Une personne
          Un processus                                                                      ou
          Une chose
                  qui interagit avec le système

       Le cas d’utilisation représente
        une fonctionnalité visible de l’extérieur qui réalise un service de bout en bout, avec un
          déclenchement, un déroulement et une fin, pour l’acteur qui l’initie.
       Un cas d’utilisation modélise donc un service rendu par le système, sans imposer le mode de
       réalisation de ce service.

       Nom du cas : Verbe à l’infinitif

Polytech Paris XI – 2018 2019– Génie Logiciel- Frédéric Voisin - Valérie GUIMARD - RAPPELS
UML
                                                                 30
Comment identifier les acteurs ?

   Chaque acteur doit être nommé. Ce nom doit refléter sont rôle car un acteur représente un ensemble cohérent de rôles joués vis-
   à-vis du système.
   Pour trouver les acteurs d’un système, il faut identifier
       quels sont les différents rôles que vont devoir jouer ses utilisateurs (ex : responsable clientèle, responsable d’agence,
        administrateur, approbateur, …).
       Il faut également s’intéresser aux autres systèmes avec lesquels le système va devoir communiquer comme :
              les périphériques manipulés par le système (imprimantes, hardware d’un distributeur de billet, …) ;
              des logiciels déjà disponibles à intégrer dans le projet ;
              des systèmes informatiques externes au système mais qui interagissent avec lui, etc.

   Pour faciliter la recherche des acteurs, on peut imaginer les frontières du système.
              Tout ce qui est à l’extérieur et qui interagit avec le système est un acteur,
              Tout ce qui est à l’intérieur est une fonctionnalité à réaliser.

   Vérifiez que les acteurs communiquent bien directement avec le système par émission ou réception de messages. Une erreur
   fréquente consiste à répertorier en tant qu’acteur des entités externes qui n’interagissent pas directement avec le système, mais
   uniquement par le biais d’un des véritables acteurs.
      Par exemple, l’hôtesse de caisse d’un magasin de grande distribution est un acteur pour la caisse enregistreuse, par contre,
       les clients du magasins ne correspondent pas à un acteur car ils n’interagissent pas directement avec la caisse.

Polytech Paris XI – 2018 2019– Génie Logiciel- Frédéric Voisin - Valérie GUIMARD - RAPPELS
UML
                                                                    31

  Comment recenser les cas d’utilisation
  Chaque cas d’utilisation correspond à une fonction métier du système, selon le point de vue d’un de ses acteurs.

  Il faut se placer du point de vue de chaque acteur et déterminer comment et surtout pourquoi il se sert du système.

  Il faut éviter les redondances et limiter le nombre de cas en se situant à un bon niveau d’abstraction. Trouver le bon niveau de
  détail pour les cas d’utilisation est un problème difficile qui nécessite de l’expérience.

  les cas d’utilisation avec un verbe à l’infinitif suivi d’un complément en vous plaçant du point de vue de l’acteur et non pas de
  celui du système.

         Par exemple, un distributeur de billets aura probablement un cas d’utilisation Retirer de l’argent et non pas Distribuer de
         l’argent.

                    Attention à ne pas retomber dans une décomposition fonctionnelle descendante hiérarchique. Un trop grand
                    nombre de cas d’utilisations est en général source d’erreurs
                    Dans tous les cas, il faut bien garder à l’esprit qu’il n’y a pas de notion temporelle dans un diagramme de cas
                    d’utilisation.

Polytech Paris XI – 2018 2019– Génie Logiciel- Frédéric Voisin - Valérie GUIMARD - RAPPELS
AGL
                                                        32

           Gestion des Risques

    1.     Identifier (identification)

    2.     Prioriser (assesment)

    3.     Prévenir (safety measures)

    4.     Suivre les risques (follow-up)

Polytech Paris XI – 2018 2019– Génie Logiciel- Frédéric Voisin - Valérie GUIMARD - RAPPELS
AGL
                                                        33

           Gestion des Risques

   Attention : les risques sont des menaces sur les ressources et non sur les
       objectifs

Polytech Paris XI – 2018 2019– Génie Logiciel- Frédéric Voisin - Valérie GUIMARD - RAPPELS
AGL
                                                        34

                      Gravité       Fréquence        Criticité      Prévention     Réparation   Responsable
    Risques           (G : 1-4)      (F : 1-4)        (GxF)

Polytech Paris XI – 2018 2019– Génie Logiciel- Frédéric Voisin - Valérie GUIMARD - RAPPELS
AGL
                                                        35

Polytech Paris XI – 2018 2019– Génie Logiciel- Frédéric Voisin - Valérie GUIMARD - RAPPELS
AGL
                                                        36

Polytech Paris XI – 2018 2019– Génie Logiciel- Frédéric Voisin - Valérie GUIMARD - RAPPELS
AGL
                                                         37

        N°     Libellé Tâche                        Pierre      Paul       Jacques Alex      Georges
        G1     Tâche 1                              R                      A       C         I
        D2     Tâche 2                                          RA
        S4     Tâche 3                              R           R          C          A
        V4     Tâche 4                              RA                                       C

Polytech Paris XI – 2018 2019– Génie Logiciel- Frédéric Voisin - Valérie GUIMARD - RAPPELS
AGL
                                                            38

  Identifier les différents acteurs du projet pour chaque tâche élémentaire et les
  personnes affectées au pilotage des différents lots

  Ordonnancer et évaluer les actions : décrire les liens de dépendance chronologique
  entre les actions et estimer le temps nécessaire à leur réalisation (durée) ainsi que les
  dépenses à engager (charges).

  Intégrer la notion de risque dans le planning prévisionnel :
          Les risques techniques qui ont un impact sur la durée et donc le coût de l’action (ex : le contenu des tâches n’est
          pas totalement figé car il dépend de décisions à prendre pendant la phase précédente ou des résultats de cette
          phase, la technicité du produit est complexe)

           Les risques liés aux moyens ou à la planification : incertitude des données ou de disponibilités de moyens
          (personnel performant et adaptés). La simultanéité de certaines actions peut entraîner des conflits de ressources.

Polytech Paris XI – 2018 2019– Génie Logiciel- Frédéric Voisin - Valérie GUIMARD - RAPPELS
AGL
                                                        39

       Estimer le temps des tâches

           Plusieurs Méthodes
              Avis d’expert
                   Basé sur un projet équivalent

              Analytique : Basé sur la charge unitaire et démultiplié
                   Ex : programme : 1 fichier en entrée 2 Maj de base ….
                   Ex : Surface pour 1 M² cela met x temps donc pour n m²…

Polytech Paris XI – 2018 2019– Génie Logiciel- Frédéric Voisin - Valérie GUIMARD - RAPPELS
AGL
                                                        40

 Ratio fonctionnel

Polytech Paris XI – 2018 2019– Génie Logiciel- Frédéric Voisin - Valérie GUIMARD - RAPPELS
AGL
                                                        41

               Ordonnancer les tâches

            Lot       Tâche (N°)                                       Tps j/h           Prédécesseur

                    Ne pas oublier les tâches de pilotage formation attente etc….

Polytech Paris XI – 2018 2019– Génie Logiciel- Frédéric Voisin - Valérie GUIMARD - RAPPELS
AGL
                                                        42
          Gantt et Ms project

Polytech Paris XI – 2018 2019– Génie Logiciel- Frédéric Voisin - Valérie GUIMARD - RAPPELS
AGL
                                                        43

Polytech Paris XI – 2018 2019– Génie Logiciel- Frédéric Voisin - Valérie GUIMARD - RAPPELS
AGL
                                                         44

   RAPPELS UML

Polytech Paris XI – 2018 2019– Génie Logiciel- Frédéric Voisin - Valérie GUIMARD - RAPPELS
AGL
                                                         45

Polytech Paris XI – 2018 2019– Génie Logiciel- Frédéric Voisin - Valérie GUIMARD - RAPPELS
AGL
                                                                    46

Relation d’association

Une relation d’association est chemin de communication entre un acteur et un cas d’utilisation et est représenté un trait continu
Multiplicité
   Lorsqu’un acteur peut interagir plusieurs fois avec un cas d’utilisation, il est possible d’ajouter une multiplicité sur l’association
   du côté du cas d’utilisation. Le symbole * signifie plusieurs, exactement n s’écrit tout simplement n, n..m signifie entre n et m, etc.
   Préciser une multiplicité sur une relation n’implique pas nécessairement que les cas sont utilisés en même temps.

Acteurs principaux et secondaires
   Principal : Un acteur est qualifié de principal pour un cas d’utilisation lorsque ce cas rend service à cet acteur. L’acteur principal
   obtient un résultat observable du système. Un cas d’utilisation a au plus un acteur principal. En général, l’acteur principal initie le
   cas d’utilisation par ses sollicitations
   Secondaire : Les autres acteurs sont alors qualifiés de secondaires. Un acteur secondaire est sollicité pour des informations
   complémentaires.
   Le stéréotype > vient orner l’association reliant un cas d’utilisation à son acteur principal, le stéréotype
   > est utilisé pour les acteurs secondaires
Quand un cas n’est pas directement relié à un acteur, il est qualifié de cas d’utilisation interne.

Polytech Paris XI – 2018 2019– Génie Logiciel- Frédéric Voisin - Valérie GUIMARD - RAPPELS
AGL
                                                                    47
Relation d’inclusion
   Un cas A inclut un cas B si le comportement décrit par le cas A inclut le comportement du cas B : le cas A dépend de B. Lorsque A est
   sollicité, B l’est obligatoirement
   Les inclusions permettent essentiellement de factoriser une partie de la description d’un cas d’utilisation qui serait commune à d’autres
   cas d’utilisation (1)

                                                          (1) Par exemple, l’accès aux informations d’un compte bancaire inclut
                                                          nécessairement une phase d’authentification avec un identifiant et un mot
                                                          de passe que ce soit pour consulter les comptes ou retirer de l’argent

  Polytech Paris XI – 2018 2019– Génie Logiciel- Frédéric Voisin - Valérie GUIMARD - RAPPELS
AGL
                                                                  48

Relation d’inclusion

   Les inclusions permettent également de décomposer un cas complexe en sous-cas plus simples. Cependant, il ne faut surtout pas
   abuser de ce type de décomposition : il faut éviter de réaliser du découpage fonctionnel d’un cas d’utilisation en plusieurs sous-cas
   d’utilisation pour ne pas retomber dans le travers de la décomposition fonctionnelle.
   Attention également au fait que, les cas d’utilisation ne s’enchaînent pas, puisqu’il n’y a aucune représentation temporelle dans un
   diagramme de cas d’utilisation

Polytech Paris XI – 2018 2019– Génie Logiciel- Frédéric Voisin - Valérie GUIMARD - RAPPELS
AGL
                                                                  49
Relation d’extension

    A étend un cas d’utilisation B lorsque le cas d’utilisation A peut être appelé au cours de l’exécution du cas d’utilisation B. Exécuter
    B peut éventuellement entraîner l’exécution de A : contrairement à l’inclusion, l’extension est optionnelle. L’extension peut
    intervenir à un point précis du cas étendu. Ce point s’appelle le point d’extension. Il porte un nom, qui figure dans un
    compartiment du cas étendu sous la rubrique point d’extension, et est éventuellement associé à une contrainte indiquant le
    moment où l’extension intervient. Une extension est souvent soumise à condition.

Graphiquement, la condition est exprimée sous la forme d’une note.
Exemple d’une banque où la vérification du solde
du compte n’intervient que si la demande de retrait dépasse 20 euros.

La relation d’extension est probablement la plus utile car elle a une
sémantique qui a un sens du point de vue métier au contraire des deux
autres qui sont plus des artifices d’informaticiens.

Polytech Paris XI – 2018 2019– Génie Logiciel- Frédéric Voisin - Valérie GUIMARD - RAPPELS
50

Relation de généralisation

    La seule relation possible entre deux acteurs est la généralisation
    un acteur A est une généralisation d’un acteur B si l’acteur A peut être substitué par l’acteur B. Dans ce cas, tous les cas d’utilisation
    accessibles à A le sont aussi à B, mais l’inverse n’est pas vrai.

Le préposé aux commandes peut être
Remplacé par le directeur des ventes mais
Pas l’inverse.
De plus le directeur des ventes
Peut gérer le stock ce que ne peut pas
Faire le préposé aux commandes

 Polytech Paris XI – 2018 2019– Génie Logiciel- Frédéric Voisin - Valérie GUIMARD - RAPPELS
Vous pouvez aussi lire