Atelier Génie Logiciel 1 - Polytech Paris XI - 2018 2019- Génie Logiciel-Frédéric Voisin - Valérie GUIMARD - RAPPELS
←
→
Transcription du contenu de la page
Si votre navigateur ne rend pas la page correctement, lisez s'il vous plaît le contenu de la page ci-dessous
Atelier Génie Logiciel
1
RAPPELS
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
AGL
3
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
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
AGL
6
Documentation
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
AGL
8
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
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 - RAPPELSAGL
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 - RAPPELSAGL
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 - RAPPELSAGL
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 - RAPPELSAGL
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 - RAPPELSAGL
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 - RAPPELSAGL
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 - RAPPELSIntroduction
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 - RAPPELSAGL
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 - RAPPELSAGL : quelques causes d’échecs des projets
19
Polytech Paris XI – 2018 2019– Génie Logiciel- Frédéric Voisin - Valérie GUIMARD - RAPPELSAGL – cycle en V
20
Polytech Paris XI – 2018 2019– Génie Logiciel- Frédéric Voisin - Valérie GUIMARD - RAPPELSAGL – 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 - RAPPELSAGL : 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 - RAPPELSAGL : Méthode Agile
Principe SCRUM
Polytech Paris XI – 2018 2019– Génie Logiciel- Frédéric Voisin - Valérie GUIMARD - RAPPELSAGL : 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 - RAPPELSAGL : 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 - RAPPELSAGL : 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 - RAPPELSAGL : 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 - RAPPELSAGL : 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 - RAPPELSUML
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 - RAPPELSUML
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 - RAPPELSAGL
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 - RAPPELSAGL
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 - RAPPELSAGL
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 - RAPPELSAGL
35
Polytech Paris XI – 2018 2019– Génie Logiciel- Frédéric Voisin - Valérie GUIMARD - RAPPELSAGL
36
Polytech Paris XI – 2018 2019– Génie Logiciel- Frédéric Voisin - Valérie GUIMARD - RAPPELSAGL
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 - RAPPELSAGL
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 - RAPPELSAGL
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 - RAPPELSAGL
40
Ratio fonctionnel
Polytech Paris XI – 2018 2019– Génie Logiciel- Frédéric Voisin - Valérie GUIMARD - RAPPELSAGL
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 - RAPPELSAGL
42
Gantt et Ms project
Polytech Paris XI – 2018 2019– Génie Logiciel- Frédéric Voisin - Valérie GUIMARD - RAPPELSAGL
43
Polytech Paris XI – 2018 2019– Génie Logiciel- Frédéric Voisin - Valérie GUIMARD - RAPPELSAGL
44
RAPPELS UML
Polytech Paris XI – 2018 2019– Génie Logiciel- Frédéric Voisin - Valérie GUIMARD - RAPPELSAGL
45
Polytech Paris XI – 2018 2019– Génie Logiciel- Frédéric Voisin - Valérie GUIMARD - RAPPELSAGL
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 - RAPPELSAGL
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 - RAPPELSAGL
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 - RAPPELSAGL
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 - RAPPELS50
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 - RAPPELSVous pouvez aussi lire
