Méthodes de développement. Analyse des exigences (spécification)

Dimension: px
Commencer à balayer dès la page:

Download "Méthodes de développement. Analyse des exigences (spécification)"

Transcription

1 1 / 16 Méthodes de développement Analyse des exigences (spécification) 1 -Objectifs de l'analyse des exigences Approfondissement et formalisation du besoin Séparation des besoins, contraintes et solutions Approfondissement des besoins Place de l'activité dans le développement Conditions de démarrage Cas du développement séquentiel Cas des méthodes itératives (hors méthodes agiles) Cas des méthodes agiles Principaux travaux Les documents d'exigence Rédaction de l'introduction d'une STB ou SGB Mission du système Liste de fonctionnalités et règles métier (SGB pour méthodes agiles) Détail des cas d'utilisation (STB UML) Les cas d'utilisation Découpage en cas d'utilisation Comment trouver les cas d'utilisation Cas d'utilisation abstraits Rédaction d'un cas d'utilisation Séquence des événements Spécifications complémentaires Exigences fonctionnelles et interfaces (STB structurée) Décomposition arborescente Description des fonctions Diagrammes type SADT Interfaces Les exigences complémentaires Environnement du système Mise en œuvre Disponibilité Dimensionnements et performances Contraintes de conception et de réalisation Validation et recette Livraison et soutien Traçabilité des exigences Adaptation des documents d'exigence à la réutilisation de logiciels La gestion des exigences La revue de spécification logiciel... 16

2 2 / Objectifs de l'analyse des exigences L'analyse des exigences est la première activité d'un développement de logiciel ou de système à logiciel prépondérant. Les objectifs de l'analyse des exigences (appelée couramment spécification) sont de : - approfondir, préciser et formaliser les besoins exprimés par le client, - se mettre d'accord avec le client sur cette formalisation, - obtenir le document de base du développement (STB spécification technique de besoins ou SGS spécification générale de besoins) permettant le démarrage de la conception de l'architecture, - préparer la validation et la recette du produit. 2 - Approfondissement et formalisation du besoin 2.1 Séparation des besoins, contraintes et solutions En principe, l'analyse du besoin est faite à partir d'un cahier des charges fourni par le client. S'il n'y en a pas, il faudra d'abord cerner le besoin et reconstituer les informations de ce cahier des charges par des interviews, l'analyse de documents Le cahier des charges peut contenir des besoins fonctionnels, des contraintes, des solutions imaginées par le client La spécification technique de besoins ne doit contenir que les exigences : besoins et contraintes, et ne pas imposer de solutions. En effet c'est au niveau de la conception que doivent être choisies les solutions, et les solutions imaginées au départ ne sont pas toujours les plus intéressantes. Il faut donc à partir du cahier des charges du client, identifier : - ce qui est un besoin du client, - ce qui est une contrainte, - ce qui est une solution possible. Exemple de définition de solution possible dans le cahier des charges " le position du mobile sera obtenue par intégration numérique des équations du mouvement par l'algorithme de Runge Kutta d'ordre 4" Obtenir la position du mobile par intégration des équations du mouvement est certes un besoin, mais le faire numériquement par l'algorithme de Runge Kutta d'ordre 4 est une solution qui n'est pas forcement la meilleure. En effet il n'est pas impossible que le système d'équations différentielles puisse être résolu de façon théorique si les équations sont simples, et parmi les méthodes numériques il en existe d'autres qui peuvent être plus simples à mettre en œuvre ou plus adaptées à la précision souhaitée telles que les algorithmes de tangente améliorée, les algorithmes à pas liés 2.2 Approfondissement des besoins Lorsqu'on a identifié un besoin, il sera en général exprimé de façon concise. Il faut l'approfondir et le préciser pour pouvoir vérifier avec le client que cela correspond bien à son besoin et préparer la conception et le codage.

3 3 / 16 Par exemple, si vous vous reportez au cahier des charges présenté dans l'introduction aux guides de rédaction, vous verrez qu'il faut définir des horaires pour des lignes de car. Il y a beaucoup de manières de définir des horaires : uniquement les heures au départ de la ligne, pour en plus le terminus et les arrêts principaux, pour tous les arrêts, en heure absolue, en relatif à l'heure de départ au début de la ligne Il va falloir choisir une solution, vérifier qu'elle convient bien au problème posé, et détailler les informations à entrer pour définir des horaires. 3 - Place de l'activité dans le développement 3.1 Conditions de démarrage L'analyse des besoins est la première activité du développement et doit être lancée au début du projet avec l'activité d'organisation du projet. Pour la démarrer il faut réunir la documentation nécessaire pour sa réalisation : - cahier des charges du client, - documentation du système (quand elle existe), - résultats d'études préliminaires qui ont pu être faites avant le projet ou lors de la préparation du projet, - spécifications des interfaces, - maquettes éventuelles déjà réalisées, - documentation technique. Il faut de plus avoir fait le choix de la méthode de développement, des techniques utilisées pour spécifier (par exemple spécification UML), et des outils employés pour rédiger ou illustrer la spécification, et éventuellement pour gérer les exigences. 3.2 Cas du développement séquentiel Dans un développement de type séquentiel, l'analyse des besoins est faite complètement et une Spécification Technique de Besoins (STB) est entièrement rédigée avant de passer à l'activité suivante de conception de l'architecture. 3.3 Cas des méthodes itératives (hors méthodes agiles) Dans une méthode itérative (non agile), on rédige une STB de façon incrémentale en la complétant à chaque itération. Dans la première version on s'attachera par exemple à faire le plan complet de la STB, rédiger en grande partie le chapitre mission, rédiger une partie du détail des fonctions ou des cas d'utilisation, et entamer la rédaction des exigences complémentaires. Dans chacune des itérations suivantes, on rédigera des fonctions ou cas d'utilisation supplémentaires en fonction des incréments fonctionnels définis pour chaque itération, et on complétera et mettra à jour les parties déjà rédigées. Il faudra faire en sorte dans la définition des objectifs des itérations que les fonctions ou cas d'utilisation soient rédigés avant de faire la conception puis le codage des parties de l'application correspondantes.

4 4 / 16 Cependant il est aussi possible dans un développement itératif de rédiger entièrement la STB à la première itération, et de ne faire lors des itérations suivantes que les mises à jour qui s'avèreraient nécessaires. 3.4 Cas des méthodes agiles Il est nécessaire de faire une analyse du besoin au début du développement pour savoir quelles seront les fonctionnalités à implémenter. A l'inverse des méthodes classiques, dans les méthodes agiles, on recommande de ne pas faire d'analyse détaillée au début du développement, mais uniquement au moment d'implémenter la fonctionnalité. Le réalisateur qui a une fonctionnalité à coder approfondira le besoin à travers le codage ou la définition des tests, présentera le résultat au client, et modifiera en fonction des remarques du client. Cela s'approche d'une démarche par approximations successives. Dans ces conditions il n'y a pas besoin de rédiger une Spécification Technique de Besoins avec tout le détail des fonctions ou cas d'utilisation. Il est cependant utile d'avoir un document de besoin pour présenter l'utilisation du produit, les contraintes à respecter et lister les fonctionnalités à implémenter. Ce document pourrait être appelé Spécification Générale de Besoins (SGB) pour le distinguer d'une Spécification Technique de Besoin classique et contenir : - la présentation de la mission du système, - une liste des fonctionnalités, - les règles métier et interfaces à respecter, - des exigences complémentaires. 4 - Principaux travaux Le travail principal est de trier, préciser et formaliser les besoins et les contraintes. On partira pour cela de la documentation disponible pour recenser les besoins et les contraintes, puis on approfondira les besoins et les contraintes. Cela pourra se faire par analyse de la documentation disponible, interviews du maître d'ouvrage, de futurs utilisateurs ou d'experts du domaine, propositions soumises au client, recherche de documents supplémentaires Il est recommandé d'établir pour chaque interview un compte rendu indiquant les informations complémentaires obtenues par rapport au cahier des charges. Ces comptes-rendus pourront être, après accord du client, considérés comme des compléments au cahier des charges. La spécification technique de besoins (STB) ou la spécification générale de besoins (SGB) sera rédigée. Les besoins et contraintes seront mis en forme pour y être intégrés. La mise en forme dépend de la technique de spécification choisie et sera présentée plus loin. Il faut de plus vérifier que toutes les exigences et contraintes exprimées dans le cahier des charges et les documents qui le complètent ont bien été prises en compte dans la STB ou la SGB. Pour cela on pourra faire une liste des exigences de besoin ou de contrainte du cahier des charges et des documents qui le complètent et montrer dans une matrice de traçabilité la correspondance avec les paragraphes de la STB ou la liste des fonctionnalités de la SGB.

5 5 / 16 Il faut aussi identifier les interfaces du logiciel ou du système, et les caractéristiques d'utilisation du logiciel ou système (par exemple la disponibilité) pour les intégrer dans la STB ou la SGB. Pour compléter, il faudra définir dans leur principe les opérations de validation et de recette : lieu des opérations, moyens nécessaires, tests à effectuer Dans le cas d'une STB, un objectif majeur est de montrer au client que l'on à bien compris son problème et se mettre d'accord avec sur les besoins et contraintes à prendre en compte. Pour cela : - la STB sera rédigée en langage clair, - le plan type imposé par la méthode sera suivi, - la STB sera fournie au client pour approbation, - une revue de spécification sera tenue avec le client (si possible). Dans le cas des méthodes agiles, le client doit en principe collaborer de façon quasi permanente au projet, et le rôle du document d'exigences (SGB) est plus limité. 5 - Les documents d'exigence Les documents d'exigence recensent tous les besoins identifiés sous forme de fonctions à remplir et de contraintes, de façon plus ou moins détaillée selon le type de document. Les documents d'exigence sont les documents de base pour la conception de l'architecture du logiciel où on recherche une solution capable de satisfaire toutes les exigences et contraintes identifiées. Ces documents seront aussi la référence pour la définition des essais de validation. Avant l'apparition des techniques UML, il était recommandé de baser une STB sur les techniques d'analyse structurée type SADT (Structured Analysis and Design Technique) avec une décomposition arborescente des fonctions. Une STB comprenait 4 grandes parties : - la mission du logiciel, - les exigences fonctionnelles (décomposition arborescente et diagrammes type SADT/SART), - les exigences d'interface, - les exigences complémentaires (environnement, mise en œuvre, disponibilité, sécurité, contraintes de conception et de réalisation ). Avec l'apparition d'uml, les méthodes de conception objet ont couvert l'aspect analyse des besoins grâce au modèle des cas d'utilisation. Dans une STB type UML, on retrouvera les parties mission du logiciel et exigences complémentaires, et les parties exigences fonctionnelles et exigences d'interface sont regroupées dans les cas d'utilisation qui définissent les services rendus aux utilisateurs et autres acteurs du système. Dans les méthodes agiles, la rédaction des exigences détaillée n'apparaît ni nécessaire ni souhaitable. On remplacera les exigences fonctionnelles ou le modèle des cas d'utilisation par une simple liste de fonctionnalités et les contraintes de type règle métier ou interface. On arrive donc pour les documents d'exigence aux parties suivantes :

6 6 / 16 STB structurée STB UML SGB (méthodes agiles) Introduction Introduction Introduction Mission du logiciel Mission du logiciel Mission du logiciel Exigences fonctionnelles Modèle des cas d'utilisation Liste des fonctionnalités Exigences d'interface Règles métier et interfaces Exigences complémentaires Exigences complémentaires Exigences complémentaires Traçabilité des exigences Traçabilité des exigences La STB type UML décrit les fonctionnalités vues par les utilisateurs à travers les cas d'utilisation. Elle est donc bien adaptée aux logiciels de type interactif où la plupart des fonctionnalités découlent d'actions opérateur. La STB structurée décrit les fonctionnalités par une décomposition arborescente de fonctions. Elle est bien adaptée aux logiciels de type scientifique ou industriel où il y a des algorithmes à définir et peu d'interaction utilisateur. La SGB ne décrit pas le détail, elle est adaptée aux méthodes agiles. Il est donc recommandé pour chaque projet de choisir le type de spécification le mieux adapté à la dominante du projet. Les rédactions d'une STB type UML ou d'une SGB font l'objet de guides détaillés avec un exemple. On se limitera donc dans la suite de ce cours à présenter les principes. 6 - Rédaction de l'introduction d'une STB ou SGB L'introduction d'une STB ou SGB précise - l'objet du document (nom du système, rôle du système, environnement d'utilisation du système, limites d'utilisation importantes), - la terminologie et sigles utilisés (abréviations employées et termes ayant un sens particulier), - les documents de référence (documents auxquels la STB ou SGB se réfère, qu'elle impose, ou qui la complètent). Le plan suivant est proposé pour cette partie : 1- Introduction 1.1 Objet 1.2 Terminologie et sigles utilisés 1.3 Documents de référence 7 - Mission du système La mission du système est la seule partie descriptive de la spécification, elle doit être suffisamment claire et détaillée pour permettre de comprendre le fonctionnement du système. Elle comprendra : - les objectifs du système et les principaux services attendus par les utilisateurs,

7 7 / 16 - la composition du système en matériels, réseaux et éventuellement logiciels et la présentation des configurations d'utilisation, - les principes de fonctionnement du système vus des utilisateurs, - les utilisateurs du système et leur rôle, - les autres acteurs (matériels, logiciels ou systèmes en interface) et leur rôle (spécification UML), - une description rapide des services offerts aux utilisateurs (et autres acteurs), - pour une spécification UML, la liste des cas d'utilisation classés par groupes avec la correspondance avec les services offerts, - pour une spécification structurée, une description de scénarios typiques d'utilisation. Nota 1 En UML les acteurs sont : - les utilisateurs du système, soit qu'ils soient directement opérateurs du système (devant un terminal ou un micro-ordinateur), soit qu'ils l'utilisent de façon moins directe (par l'intermédiaire d'éditions, par l'exploitation de fichiers générés par le système, par la fourniture de données ), - les autres systèmes, matériels ou logiciels en interface avec le système. Nota 2 Dans une spécification UML les cas d'utilisation représentent des scénarios d'utilisation qui seront présentés dans le détail des cas d'utilisation. Le plan type suivant est proposé pour cette partie : 2 -Présentation de la mission du système 2.1 Objectifs 2.2 Composition du système 2.3 Principes de fonctionnement 2.4 Utilisateurs et acteurs 2.5 Services offerts et cas d'utilisation (ou scenarios d'utilisation) 8 - Liste de fonctionnalités, règles métier et interfaces (SGB pour méthodes agiles) Dans une méthode agile, on ne rédige pas le détail des fonctions ou cas d'utilisation. Il est cependant utile d'identifier les fonctionnalités à implémenter, cela servira pour définir le contenu et les plannings des itérations, et suivre l'avancement de la réalisation. On établira donc une liste des fonctionnalités à implémenter. On pourra partir des services et cas ou scenarios d'utilisation présentés au paragraphe précédent, et décomposer chacun en fonctionnalités pour le client. On pourra les présenter dans un tableau en indiquant pour chacune une priorité de réalisation. En complément on essaiera de recenser les règles métier et interfaces que devra respecter le logiciel pour être utilisable. Ces règles peuvent provenir d'obligations légales, des usages de la profession, du référentiel de la société, des méthodes de travail du client... Elles devront être prises en compte dans la conception et le codage du logiciel et leur respect vérifié par des tests.

8 8 / 16 Par exemple dans un logiciel de facturation dans un contexte BtoB (business to business), on pourra trouver : - le respect des champs imposés par le ministère des finances dans les factures, - la facturation en prix hors taxe avec ajout de la TVA in fine, - l'application de taux de TVA différenciés selon le type de produit, et la possibilité de modifier les taux de TVA Les interfaces à respecter peuvent être des interfaces matérielles imposés (par exemple le type de réseau), ou des interfaces logiciel (par exemple l'utilisation d'une base de données existante). On pourra pour ces règles les définir dans le document ou renvoyer à un document de référence. 9- Détail des cas d'utilisation (STB UML) Cette partie spécifie de façon détaillée les cas d'utilisation (y compris les cas d'utilisation abstraits). Si les cas d'utilisation dépassent quelques unités, on les présentera groupe par groupe. On arrive alors au plan suivant pour cette partie : 3 - Détail des cas d'utilisation 3.1 Groupe de cas d'utilisationg Cas d'utilisation G i Cas d'utilisation G1.i 3.j Groupe de cas d'utilisation Gj 3.j.k Cas d'utilisation Gj.k 9.1 Les cas d'utilisation Les cas d'utilisation définissent les services rendus par le système aux différents acteurs. Un cas d'utilisation définit une séquence d'événements, du point de vue d'un (ou plusieurs) acteurs, qui aboutit à un résultat observable. Pour un acteur de type utilisateur, il définit les fonctions à assurer pour rendre les services attendus. Pour un acteur de type système, matériel ou logiciel en interface, il définit les fonctions à assurer pour l'interface. 9.2 Découpage en cas d'utilisation Les fonctionnalités du système sont réparties entre les cas d'utilisation correspondant à des séquences d'événements. Pour rendre la spécification compréhensible, il est recommandé de regrouper dans un même cas d'utilisation les événements liés entre eux et les séquences d'événements similaires. Il ne faut pas faire des cas d'utilisation trop petits, mais il faut aussi éviter l'excès inverse (ne faire qu'un seul cas d'utilisation!). 9.3 Comment trouver les cas d'utilisation La première source est l'examen de tous les services identifiés que le système doit rendre aux différents acteurs. Chaque service devra faire partie de l'un des cas d'utilisation du système.

9 9 / 16 Pour compléter le modèle, on examinera les aspects complémentaires non couverts par les services identifiés, par exemple : - démarrage et arrêt du système, - interfaces du système, - administration du système, par exemple création ou modifications de mots de passe, journal de bord - sauvegarde et restauration des données, initialisations de fichiers ou bases de données 9.4 Cas d'utilisation abstraits Pour faciliter et simplifier la rédaction, il est possible de définir des cas d'utilisation abstraits. Ces cas d'utilisation abstraits pourront définir des séquences d'événements utilisées dans un ou plusieurs autres cas d'utilisation, par exemple pour détailler un traitement ou définir une fonction commune. On peut aussi définir dans un cas d'utilisation abstrait des propriétés communes et en faire hériter d'autres cas d'utilisation (relation de type généralisation ou héritage). 9.5 Rédaction d'un cas d'utilisation Un nom doit être donné à chaque cas d'utilisation, composé de quelques mots et différent des noms de tous les autres cas d'utilisation. Il doit être significatif du contenu du cas d'utilisation. Le plan type d'un cas d'utilisation est le suivant : Brève description Références Séquence des événements Séquence nominale Séquences alternatives Spécifications complémentaires Données en entrée Données en sortie Traitements Autres exigences La brève description décrit en quelques lignes le rôle et l'objet du cas d'utilisation en se référant aux acteurs. Les références peuvent indiquer les paragraphes du cahier des charges ou de la partie mission de la spécification concernés, les autres cas d'utilisation appelés 9.6 Séquence des événements La séquence des événements décrit de façon claire et compréhensible la suite des événements (actions opérateurs, traitements faits par le système, commandes faites par le système, affichages ou éditions ). Elle doit indiquer ce que le système fait, et non comment il doit le réaliser. Les règles à respecter sont : - décrire comment le cas d'utilisation débute et finit, - décrire quelles données sont échangées entre l'acteur et le cas d'utilisation,

10 10 / 16 - ne pas décrire le détail de l'interface utilisateur, sauf si c'est nécessaire pour comprendre le comportement du système, - décrire la séquence des événements et pas seulement la fonctionnalité ; commencer chaque action par "Quand l'acteur ", - décrire seulement les événements qui appartiennent au cas d'utilisation, et pas ce qui arrive dans d'autres cas d'utilisation ou à l'extérieur du système. La séquence nominale est ce qui arrive "normalement". Les séquences alternatives couvrent ce qui arrive dans certains cas ou lors d'erreurs. Pour rendre le document lisible, il est recommandé de structurer la séquence de base et les séquences alternatives en étapes, et de faire des paragraphes numérotés avec un titre. On peut aussi illustrer la séquence de base et les séquences alternatives par des diagrammes. 9.7 Spécifications complémentaires La séquence d'évènements décrit des évènements qui peuvent nécessiter des données d'entrée, faire des traitements, générer des données en sortie Les spécifications complémentaires précisent ces données et ces traitements. On peut aussi trouver d'autres exigences pour le cas d'utilisation, on les mettra alors dans un paragraphe autres exigences, par exemple : - des contraintes de performances ou de disponibilité, - des contraintes sur l'état du système au début du cas d'utilisation et en fin de cas d'utilisation. Ces exigences ne sont à mettre ici que si elles ne se rapportent qu'à ce cas d'utilisation, si elles se rapportent à l'ensemble du système, elles sont à mettre dans les exigences complémentaires de la STB Exigences fonctionnelles et interfaces (STB structurée) 10.1 Décomposition arborescente Dans une STB structurée, les fonctionnalités sont décrites sous forme d'une décomposition arborescente de fonctions. On découpe d'abord les fonctionnalités en fonctions de premier niveau représentant les grandes fonctions du système. Chaque fonction de premier niveau est ensuite décomposée en fonction de deuxième niveau, puis on refait des décompositions jusqu'à obtenir des fonctions raisonnablement simples à définir. Le nombre de niveau dépendra de la complexité du problème et peut varier avec les fonctions. Il faut faire attention à se limiter à un nombre raisonnable de fonctions.

11 11 / 16 SYSTEME FONCTION F1 FONCTION F2 FONCTION F3 FONCTION F4 FONCTION F2.1 FONCTION F2.2 FONCTION F Description des fonctions Pour la rédaction, le plan de cette partie sera calqué sur la décomposition arborescente des fonctions. Elle sera découpée selon les fonctions de premier niveau. Pour chaque fonction de premier niveau, un paragraphe décrira cette fonction, puis les paragraphes suivants décriront les fonctions de niveau inférieur incluses dans cette fonction. La description aura la forme suivante : 3.i.1 Description de la fonction Fi 3.i.1.1 Objet et composition 3.i.1.2 Evénements déclencheurs 3.i.1.3 Données en entrée 3.i.1.4 Données en sortie 3.i.1.5 Traitements 3.i.2 Description de la fonction Fi.1 3.i.3 Description de la fonction Fi.1.1 L'objet indique le rôle de la fonction et la décomposition de la fonction au niveau suivant. Les événements déclencheurs indiquent comment est activée la fonction (commande opérateur, appel par autre fonction ) Les données en entrée et les données en sortie définissent les principales données à l'entrée dans la fonction, et à la sortie de la fonction. Les traitements détaillent la séquence des événements, en précisant les fonctions appelées lorsqu'il y en a (fonctions issues de la décomposition de la présente fonction ou autres fonctions du système), et les algorithmes de calcul pour les fonctions de dernier niveau.

12 12 / Diagrammes type SADT Il est recommandé d'appuyer la décomposition fonctionnelle sur des diagrammes fonctionnels structurés type SADT montrant les interactions entre fonctions. Exemple de diagramme type SADT : F1 FLUX k FONCTION F2.2 FLUX 21 FONCTION F2.1 F4 FLUX i FONCTION F Interfaces On complétera les exigences fonctionnelles par la définition des interfaces qu'on pourra classer par types d'interface : 4 - Interfaces 4.1 Interfaces avec des matériels 4.2 Interfaces avec d'autres produits logiciels 4.3 Interfaces avec des fichiers ou bases de données 4.4 Interfaces homme - machine 11 - Les exigences complémentaires On aborde dans cette partie les exigences qui portent sur l'ensemble du système, ces exigences dépendront du type de système, on pourra par exemple aborder les aspects suivants : 5 -Exigences complémentaires 5.1 Environnement du système 5.2 Mise en œuvre 5.3 Disponibilité 5.4 Dimensionnements et performances 5.5 Contraintes de conception et de réalisation 5.6 Validation et recette 5.7 Livraison et soutien

13 13 / Environnement du système On précisera les matériels, logiciels et systèmes en interface avec le système, s'il y en a. On indiquera leur rôle et leurs principales caractéristiques. On précisera le type d'interface, et si besoin, on définira cette interface de façon détaillée Mise en œuvre Les exigences concernant la mise en œuvre du système seront précisées, ainsi que les procédures utilisées pour l'initialisation, l'exploitation et l'arrêt du système (si elles ne sont pas définies dans les cas d'utilisation) 11.3 Disponibilité On précisera les périodes de fonctionnement du système, les objectifs de disponibilité s'il y en a, les contraintes sur les délais de réparation ou de reconfiguration et réinitialisation après incident Dimensionnements et performances On précisera les paramètres dimensionnant du système : par exemple nombre de postes, nombre d'utilisateurs simultanés, tailles des tables de base de données On précisera aussi les performances globales du système et les conditions dans les quelles elles doivent être atteintes (par exemple avec N utilisateurs simultanés) : temps de réponse à une requête, délai de recherche en base de données, nombre de transactions traitées par seconde 11.5 Contraintes de conception et de réalisation Les contraintes de conception peuvent porter sur : - l'utilisation de matériels, logiciels ou réseaux imposés, - l'utilisation de normes, de standards d'interface, - l'utilisation d'une méthode de conception objet. Les contraintes de réalisation peuvent porter sur : - le choix d'un langage de programmation, - des règles ou standards de programmation, - le traitement des erreurs, - l'utilisation d'outils d'aide au développement (compilateur, aide à la mise au point, gestionnaire de configuration ) 11.6 Validation et recette Si la validation du logiciel doit être faite, on définira tous les essais à réaliser pour pouvoir effectuer cette validation. Si le logiciel doit être recetté, on précisera les opérations à réaliser pour la recette Livraison et soutien On précisera sous quelle forme doit être livré le système et le logiciel du système, et les travaux d'installation s'ils sont prévus.

14 14 / 16 On précisera les moyens nécessaires pour assurer le soutien du système en service : maintenance matériel, maintenance logiciel, matériels et pièces de rechange, formations 12 -Traçabilité des exigences La traçabilité doit permettre de savoir dans une STB : - quelle est l'origine des exigences énoncées dans la STB, - si toutes les exigences du client ont bien été prises en compte dans la STB. Pour cela on fait une matrice indiquant pour chaque exigence : - l'intitulé de l'exigence, - la référence d'origine (nom du document, paragraphe alinéa), - la référence dans la STB (paragraphe, alinéa). Pour pouvoir répondre aux deux questions, on pourra présenter la matrice d'une part classée par référence d'origine, d'autre part classée par référence STB Adaptation des documents d'exigence à la réutilisation de logiciels. La théorie voudrait que les documents d'exigence soient rédigés sans faire d'hypothèses sur les solutions qui seront retenues pour réaliser le logiciel, et que les solutions soient ensuite choisies lors de la conception de l'architecture. La réalité est un peu différente. En effet le processus est de nature itérative. Lors de la préparation du projet il faut déjà faire une esquisse de solution pour établir le plan de développement et estimer le coût du projet. On a donc déjà une esquisse de solution lors de la rédaction du document d'exigence, et si le document d'exigence conduit à une remise en cause complète de la solution, cela va conduire à de gros problèmes au niveau des coûts et délais du projet. Si l'esquisse de solution est qu'une grande partie du logiciel doit faire l'objet d'un développement et que les logiciels réutilisés ne peuvent couvrir que des fonctions périphériques ou accessoires, on peut alors écrire le document d'exigence sans faire d'hypothèses sur les solutions, et indiquer dans le paragraphe contraintes de conception et de réalisation les logiciels à réutiliser. Cependant de nombreux logiciels sont aujourd'hui réalisés en intégrant entre eux des logiciels existants, ou en paramétrant des progiciels. Cela n'ôte pas d'intérêt à la démarche de commencer par approfondir le besoin et rédiger un document d'exigence, puis de définir l'architecture. Cependant il faudra adapter le contenu du document d'exigence pour prendre en compte le fait que des fonctions importantes seront réalisées par des logiciels existants. En effet il ne servirait à rien de décrire dans le détail des séquences d'événements qui ne seraient pas réalisables avec les logiciels existants, ni de décrire dans le détail les séquences d'événements engendrées par les logiciels existants.

15 15 / 16 On pourra donc adapter ainsi un document d'exigences : - dans la partie mission du logiciel, on présentera rapidement les fonctions des logiciels réutilisés en renvoyant à la documentation de ces logiciels qui figurera dans les documents de référence, - dans la présentation des services, on indiquera ce qui est pris en charge par les logiciels réutilisés, - pour une STB type UML, dans le détail des cas d'utilisation, on ne cherchera pas à décrire les séquences d'événements liées aux logiciels réutilisés, mais plutôt à considérer ces logiciels comme des boites noires et à décrire les enchaînements, et les entrées et sorties de ces logiciels La gestion des exigences Une STB définit un ensemble d'exigences, besoin et contraintes. Ces exigences peuvent varier au cours du développement et de la maintenance, soit suite à des demandes du client, soit à la suite de problèmes rencontrés par l'équipe de développement. Une procédure de gestion des évolutions devra être mise en place dans le cadre de la gestion de configuration pour contrôler ces évolutions. La STB est la référence du développement et la base des opérations de validation, et il faut la mettre à jour lorsque les exigences évoluent. Si les évolutions des exigences sont peu nombreuses, on peut à chaque évolution d'exigence faire une nouvelle édition de la STB ou rédiger un complément à la STB. Ce type de solution n'est pas viable pour des systèmes très volumineux ou très évolutifs, et il faut passer à la technique des bases d'exigences. Il existe des outils sur le marché (par exemple Requisite Pro de Rational) qui extraient du texte d'une STB les exigences élémentaires et constituent une base de données. Lorsque les exigences évolueront par la suite, il suffira de mettre à jour la base de données. Cette base de données pourra être utile pour établir les matrices de traçabilité, définir le plan et les procédures de qualification (où on doit s'assurer que chaque exigence de la STB est prise en compte) et suivre la prise en compte des modifications d'exigences. Cependant pour que les outils puissent travailler il faut identifier les exigences élémentaires pendant la rédaction de la STB. Une solution possible est de mettre entre crochet les exigences élémentaires en leur donnant un identificateur. Exemple de rédaction d'une séquence de cas d'utilisation Début [EX3.1 Quand l'usager sélectionne le service achat de billets au simulateur de borne, le simulateur affiche la liste des arrêts avec le numéro de zone tarifaire, et des boutons de sélection de zone tarifaire]. [EX3.2 Une touche annulation sera aussi affichée en permanence] Zone tarifaire L'usager sélectionne la zone tarifaire Nombre de billets

16 16 / 16 [EX3.3 Le simulateur affiche un clavier permettant d'entrer le nombre dans la limite de 99. L'usager entre le nombre de billets désiré] La revue de spécification logiciel Une STB est le document de référence pour le développement. Il faut s'assurer qu'elle prend bien en compte le besoin du client. Il est donc recommandé de faire dès que possible dans le développement une revue de spécifications avec le client. Cette revue pourra avoir lieu à la fin de l'activité analyse des exigences dans un développement séquentiel, et à la fin d'une itération dès que la STB sera jugée assez complète dans un développement itératif. Pour une revue, on constitue un groupe de revue avec des membres de l'équipe de projet, des représentants du client et éventuellement des experts du domaine. On fournit à tous les membres du groupe de revue les documents soumis à revue (ici la STB), les documents de référence des documents soumis à revue, et les autres documents utiles à la compréhension. Les membres du groupe de revue analysent la documentation soumise à revue et font des remarques ou demandes d'explication. L'équipe de projet analyse ces remarques et demandes et y répond. Le groupe de revue termine en faisant des recommandations au client et au fournisseur. Dans une méthode agile, le besoin est analysé tout au long du développement et le client peut alors donner son avis. La revue de spécification logiciel présente beaucoup moins d'intérêt.

Méthodes de développement

Méthodes de développement 1 / 15 Méthodes de développement Guide pour la rédaction d'une spécification générale de besoins (SGB) 1 - Objet... 2 2 - Rôle de la SGB dans une méthode agile... 2 3 - Plan type de SGB... 2 4 - Rédaction

Plus en détail

Positionnement de UP

Positionnement de UP UNIFIED PROCESS Positionnement de UP Unified Process Langage Méthode Outil logiciel UML UP RUP 6 BONNES PRATIQUES développement itératif gestion des exigences architecture basée sur des composants modélisation

Plus en détail

Méthodes de développement

Méthodes de développement 1 / 19 Méthodes de développement Préparation de projet logiciel 1 - Introduction... 2 2 - Contextes de réalisation Client Fournisseur ou Fournisseur Investisseur... 2 2.1 Principaux contextes de réalisation...

Plus en détail

touscours.net Rapport de Synthèse Cycle en V, UP et SCRUM

touscours.net Rapport de Synthèse Cycle en V, UP et SCRUM Rapport de Synthèse Cycle en V, UP et SCRUM Réalisé par : BELLINI Quentin GNANAKULENTHIRAN Anitha GOVINDEN Johana MEZINE Ahcene TIMZOUERT Chabane 19/10/2011 www.sup-galilee.univ-paris13.fr Table des matières

Plus en détail

Analyse et conception des Systèmes d Information. La démarche Merise : La Production Logicielle

Analyse et conception des Systèmes d Information. La démarche Merise : La Production Logicielle Analyse et conception des Systèmes d Information La démarche Merise : La Production Logicielle La production du logiciel Place, objectifs et principes directeurs Christophe.Nicolle@u-bourgogne.fr Introduction

Plus en détail

Méthodes de développement

Méthodes de développement 1 / 9 Méthodes de développement Méthodes agiles 1 - Introduction... 2 2 -Le manifeste agile et les méthodes agiles... 2 2.1 Le manifeste agile... 2 2.2 Les méthodes agiles... 3 3 - Caractéristiques communes

Plus en détail

Dossier d'étude technique

Dossier d'étude technique Centre national de la recherche scientifique Direction des systèmes d'information REFERENTIEL QUALITE Guide méthodologique Dossier d'étude technique Référence : CNRS/DSI/conduite-projet/developpement/technique/guide-etude-technique

Plus en détail

Projets Logiciels: Processus de développement pratiqué à TELECOM ParisTech

Projets Logiciels: Processus de développement pratiqué à TELECOM ParisTech Projets Logiciels: Processus de développement pratiqué à TELECOM ParisTech INF380-2013! Sylvie.Vignes@telecomParistech.fr Département INFRES, groupe S3 Cadre du processus 2! q Basé sur un processus incrémental:

Plus en détail

Description et illustration du processus unifié

Description et illustration du processus unifié USDP Description et illustration du processus unifié Définit un enchaînement d activités Est réalisé par un ensemble de travailleurs Avec des rôles, des métiers Avec pour objectifs de passer des besoins

Plus en détail

1 / 6. TD 1 Qualité - le plan qualité logiciel

1 / 6. TD 1 Qualité - le plan qualité logiciel / 6 TD Qualité - le plan qualité logiciel - Définitions Qualité La qualité d'un produit est l'ensemble de ses caractéristiques qui lui confèrent l'aptitude à satisfaire les besoins exprimés ou implicites

Plus en détail

Nom-Projet MODELE PLAN DE MANAGEMENT DE PROJET

Nom-Projet MODELE PLAN DE MANAGEMENT DE PROJET Nom-Projet MODELE PLAN DE MANAGEMENT DE PROJET Glossaire La terminologie propre au projet, ainsi que les abréviations et sigles utilisés sont définis dans le Glossaire. Approbation Décision formelle, donnée

Plus en détail

Projet en entreprise Cadrage du Projet de Fin d Etudes «Un projet informatique.»

Projet en entreprise Cadrage du Projet de Fin d Etudes «Un projet informatique.» Projet en entreprise Cadrage du Projet de Fin d Etudes «Un projet informatique.» Projet de fin d études 2 Sommaire OBJET DU DOCUMENT... 3 LES ETAPES DU PROJET... 4 ETUDE PREALABLE...5 1 L étude d opportunité...

Plus en détail

Projet : Plan Assurance Qualité

Projet : Plan Assurance Qualité Projet : Document : Plan Assurance Qualité 2UP_SPEC_DEV1 VERSION 1.00 Objet Ce document a pour objectif de définir la démarche d analyse et de conception objet ainsi les activités liées. Auteur Eric PAPET

Plus en détail

2. Activités et Modèles de développement en Génie Logiciel

2. Activités et Modèles de développement en Génie Logiciel 2. Activités et Modèles de développement en Génie Logiciel Bernard ESPINASSE Professeur à l'université d'aix-marseille Plan Les Activités du GL Analyse des besoins Spécification globale Conceptions architecturale

Plus en détail

0- Le langage C++ 1- Du langage C au langage C++ 2- Quelques éléments sur le langage. 3- Organisation du cours

0- Le langage C++ 1- Du langage C au langage C++ 2- Quelques éléments sur le langage. 3- Organisation du cours 0- Le langage C++ 1- Du langage C au langage C++ 2- Quelques éléments sur le langage 3- Organisation du cours Le présent cours constitue une introduction pour situer le langage C++, beaucoup des concepts

Plus en détail

Processus de développement UP

Processus de développement UP Chapitre 1 Processus de développement UP I. Pourquoi UP? II. Définition III. Activités et phases IV. Modèles mis en place 1. Pourquoi UP? Les notions de base acquises dans le module ACOO1, notamment la

Plus en détail

CONCOURS ROBAFIS 2015 Édition spéciale «10 ème anniversaire» Référentiel de Développement Plan type Lotissement des livrables documentaires

CONCOURS ROBAFIS 2015 Édition spéciale «10 ème anniversaire» Référentiel de Développement Plan type Lotissement des livrables documentaires CONCOURS ROBAFIS 2015 Édition spéciale «10 ème anniversaire» Plan type Lotissement des livrables documentaires Table des matières INTRODUCTION...2 OBJET DU DOCUMENT...2 RAPPEL DES OBJECTIFS DE LA PHASE

Plus en détail

Conditions Particulières de Maintenance. Table des matières. Ref : CPM-1.2 du 08/06/2011

Conditions Particulières de Maintenance. Table des matières. Ref : CPM-1.2 du 08/06/2011 Conditions Particulières de Maintenance Ref : Table des matières 1 CONDITIONS PARTICULIÈRES APPLICABLES AUX CONTRATS DE MAINTENANCE...2 1.1 Préambule...2 1.2 Obligations d'atreal et services rendus...2

Plus en détail

PLAN D'ASSURANCE QUALITÉ

PLAN D'ASSURANCE QUALITÉ PLAN D'ASSURANCE QUALITÉ Numéro de référence #FSSIM03 (Document de 12 pages) V ue d'ensemble : Ce document sert à décrire l'ensemble des dispositions spécifiques prises pour assurer la qualité du produit

Plus en détail

Formation projet informatique. Commander, décrire le projet, cahier des charges

Formation projet informatique. Commander, décrire le projet, cahier des charges Formation projet informatique Commander, décrire le projet, cahier des charges Cas types Cette démarche s'applique au cas ou on décide de sous-traiter le développement de l'application «au forfait» : tout

Plus en détail

Modélisation Principe Autre principe

Modélisation Principe Autre principe Modélisation Principe : un modèle est une abstraction permettant de mieux comprendre un objet complexe (bâtiment, économie, atmosphère, cellule, logiciel, ). Autre principe : un petit dessin vaut mieux

Plus en détail

Petit lexique de l'ergonomie des interfaces

Petit lexique de l'ergonomie des interfaces Petit lexique de l'ergonomie des interfaces Cet article a pour objectif de dessiner ce qu'est l'ergonomie des interfaces à travers les termes clés employés dans ce domaine. Il s'agit à la fois de donner

Plus en détail

DOCUMENTATION ASSOCIEE A UN PROJET LOGICIEL

DOCUMENTATION ASSOCIEE A UN PROJET LOGICIEL DOCUMENTATION ASSOCIEE A UN PROJET LOGICIEL 31 août 2004 Plate-Forme Opérationnelle de modélisation INRA ACTA ICTA http://www.modelia.org FICHE DU DOCUMENT 10 mai 04 N.Rousse - : Création : version de

Plus en détail

Présentation du projet:

Présentation du projet: : Le but du projet est de réaliser le fonctionnement d'un jeu d échec valide. Plus spécifiquement, il consiste à implémenter l'organisation générale du jeu, et le suivi des règles du mouvement des pièces.

Plus en détail

Génie logiciel avancé

Génie logiciel avancé Université Paris-Sud L3 MIAGE apprentissage Année 2014-2015 Génie logiciel avancé Analyse des besoins et spécification Delphine Longuet delphine.longuet@lri.fr Analyse des besoins et spécification Objectif

Plus en détail

Unité de formation 1 : Structurer une application. Durée : 3 semaines

Unité de formation 1 : Structurer une application. Durée : 3 semaines PROGRAMME «DEVELOPPEUR LOGICIEL» Titre professionnel : «Développeur Logiciel» Inscrit au RNCP de niveau III (Bac+2) (JO du 23 Octobre 2007) (32 semaines) Unité de formation 1 : Structurer une application

Plus en détail

Fiche méthodologique Rédiger un cahier des charges

Fiche méthodologique Rédiger un cahier des charges Fiche méthodologique Rédiger un cahier des charges Plan de la fiche : 1 : Présentation de la fiche 2 : Introduction : les grands principes 3 : Contenu, 1 : positionnement et objectifs du projet 4 : Contenu,

Plus en détail

La pratique de l ITSM. Définir un plan d'améliorations ITSM à partir de la situation actuelle

La pratique de l ITSM. Définir un plan d'améliorations ITSM à partir de la situation actuelle La pratique de l ITSM Définir un plan d'améliorations ITSM à partir de la situation actuelle Création : avril 2012 Mise à jour : avril 2012 A propos A propos du document Ce document pratique est le résultat

Plus en détail

Rédaction du Document de Spécifications Logiciel

Rédaction du Document de Spécifications Logiciel Rédaction du Document de Spécifications Logiciel Instruction Générale Qualité Version : 1.1 Nombre de pages : 12 Référence : referentiel_qualite/dsl.plan_type.doc UV UMLP Département ASI INSA-ROUEN BP

Plus en détail

Document de Spécifications Logiciel

Document de Spécifications Logiciel Document de Spécifications Logiciel FALLET Laurent JOUANNO Guillaume MALLET Grégory MARTEAU Sylvie MORISSET Samuel 6 juin 2003 Pour voir toutes les figures présentes dans ce document en une qualité optimum,

Plus en détail

Formation UML 2 le diagramme de cas d utilisation

Formation UML 2 le diagramme de cas d utilisation Formation UML 2 le diagramme de cas d utilisation Travaux dirigés 11 au 13 février 2014 Hervé DOMALAIN CPII/DOSO/ED FORMATION UML 2 LE DIAGRAMME DE CAS D UTILISATION Travaux dirigés 1. Enoncé du cahier

Plus en détail

Analyse et modélisation de tâches

Analyse et modélisation de tâches Analyse et modélisation de tâches 1. Introduction La conception de logiciel interactif (ou conception d'interface homme-machine [IHM], ou conception d'interface) est l'activité qui vise à définir le fonctionnement

Plus en détail

FORMATION. Connaître les exigences réglementaires appliquées aux Systèmes d Information. 1 JOUR soit 7 heures. Réf.AQ-Q1

FORMATION. Connaître les exigences réglementaires appliquées aux Systèmes d Information. 1 JOUR soit 7 heures. Réf.AQ-Q1 Réf.AQ-Q1 Les Systèmes d'information des entreprises réglementées font l'objet d'exigences spécifiques. Celles-ci sont souvent difficiles à appréhender pour les spécialistes métier de l'assurance Qualité,

Plus en détail

Etudes de cas. Etude de cas LIBENLIGNE

Etudes de cas. Etude de cas LIBENLIGNE Etudes de cas Etude de cas LIBENLIGNE 1 - Présentation générale 2 - Site marchand 3 - La phase d'initialisation 4 - La phase d'élaboration : itération n 1 5 - La phase d'élaboration : itération n 2 1 -

Plus en détail

REFERENTIEL IN2P3 CONDUITE DE PROJETS

REFERENTIEL IN2P3 CONDUITE DE PROJETS REFERENTIEL IN2P3 CONDUITE DE PROJETS Gestion de la configuration Mis à jour en mars 2008 Table des matières 1- Synthèse...3 2- Principes généraux relatifs à la gestion de configuration...5 2.1. Quelques

Plus en détail

Modélisation des Systèmes d Information Jean-Yves Antoine

Modélisation des Systèmes d Information Jean-Yves Antoine Modélisation des Systèmes d Information Jean-Yves Antoine http://www.info.univ-tours.fr/~antoine Processus de développement logiciel Jean-Yves Antoine U. Bretagne Sud - UFR SSI - IUP Vannes année 2001-2002

Plus en détail

Fiche de l'awt Rédiger un cahier des charges

Fiche de l'awt Rédiger un cahier des charges Fiche de l'awt Rédiger un cahier des charges Quels sont les éléments principaux dont il faut tenir compte pour la rédaction d'un cahier des charges dans le cadre d'un projet lié aux TIC (technologies de

Plus en détail

PLAN D'ASSURANCE QUALITE (PAQ)

PLAN D'ASSURANCE QUALITE (PAQ) PLAN D'ASSURANCE QUALITE (PAQ) Numéro de référence #UNIVPM001 (Document de 12 pages) V ue d'ensemble : Ce document sert à décrire l'ensemble des dispositions spécifiques prises pour assurer la qualité

Plus en détail

LES TESTS. Les tests. Organisation d un projet de recette Les types de tests Les outils

LES TESTS. Les tests. Organisation d un projet de recette Les types de tests Les outils Les tests Organisation d un projet de recette Les types de tests Les outils Organiser le déroulement des tests Spécifier Exécuter les Cahiers de tests les Cahiers de tests Analyser les résultats Correction

Plus en détail

SERVICES DE TELECOMMUNICATION MOBILE

SERVICES DE TELECOMMUNICATION MOBILE SERVICES DE TELECOMMUNICATION MOBILE CAHIER DES CLAUSES TECHNIQUES PARTICULIERES (C.C.T.P.) CCTP N : 07-02 du 10 mai 2007 Etabli en application du Code des Marchés Publics et relatif au service de téléphonie

Plus en détail

Brique BDL Gestion de Projet Logiciel

Brique BDL Gestion de Projet Logiciel Brique BDL Gestion de Projet Logiciel Processus de développement pratiqué à l'enst Sylvie.Vignes@enst.fr url:http://www.infres.enst.fr/~vignes/bdl Poly: Computer elective project F.Gasperoni Brique BDL

Plus en détail

Examen final LOG3000 Hiver 2014

Examen final LOG3000 Hiver 2014 Examen final LOG3000 Hiver 2014 Lundi le 28 avril 2014. Durée : 13h30 à 16h00 (total 2h30). Local : A-532. Total des points : 20. Pondération de l'examen dans la note finale : 40%. Sans documentation.

Plus en détail

Système d information VERSION : 4.00

Système d information VERSION : 4.00 METHODE ET ORGANISATION VERSION : 4.00 Jean-Michel Grandclément Confidentiel Reproduction Interdite Page 1 sur 21 Auteur Jean-Michel Grandclément Version / Date Version : 4.0 Date : 04/04/04 E-mail jean-michel.grandclement@grandclement.fr

Plus en détail

AUTOMATISATION DES TESTS FONCTIONNELS - HP UNIFIED FONCTIONAL TESTING (UFT)

AUTOMATISATION DES TESTS FONCTIONNELS - HP UNIFIED FONCTIONAL TESTING (UFT) AUTOMATISATION DES TESTS FONCTIONNELS - HP UNIFIED FONCTIONAL TESTING (UFT) REF : CQL08 DURÉE : 5 JOURS OBJECTIFS Maîtriser la démarche d automatisation des tests Savoir automatiser les tests fonctionnels

Plus en détail

O RMATION. Ingénierie Système Management de Projet Évaluation de la Maturité

O RMATION. Ingénierie Système Management de Projet Évaluation de la Maturité PLANS F de O RMATION Ingénierie Système Management de Projet Évaluation de la Maturité O R G A N I S A T I O N ACTEURS CONCERNÉS Les concepteurs de systèmes doivent détecter, analyser les besoins des utilisateurs,

Plus en détail

Développement spécifique d'un système d information

Développement spécifique d'un système d information Centre national de la recherche scientifique Direction des systèmes d'information REFERENTIEL QUALITE Procédure Qualité Développement spécifique d'un système d information Référence : CNRS/DSI/conduite-proj/developpement/proc-developpement-si

Plus en détail

ÉPREUVE OPTIONNELLE D'INFORMATIQUE AU BACCALAURÉAT (juin 1988) - suite - POLYNÉSIE -

ÉPREUVE OPTIONNELLE D'INFORMATIQUE AU BACCALAURÉAT (juin 1988) - suite - POLYNÉSIE - 62 ÉPREUVE OPTIONNELLE D'INFORMATIQUE AU BACCALAURÉAT (juin 1988) - suite - POLYNÉSIE - PREMIÈRE PARTIE (sur 6 points) Le candidat choisira l'un des deux sujets proposés, qu'il traitera en 200 à 300 mots.

Plus en détail

Conditions Particulières applicables aux Contrats de Maintenance du Logiciel

Conditions Particulières applicables aux Contrats de Maintenance du Logiciel Conditions Particulières applicables aux Contrats de Maintenance du Logiciel Ref : Table des matières 1 CONDITIONS PARTICULIÈRES APPLICABLES AUX CONTRATS DE MAINTENANCE...2 1.1 Préambule...2 1.2 Obligations

Plus en détail

GPA 789 : Analyse et Conception Orientées Objet. ETS Mickaël Gardoni Bureau A 3588 tel 84 11. Mise en Œuvre UML version du 24 avril 2009

GPA 789 : Analyse et Conception Orientées Objet. ETS Mickaël Gardoni Bureau A 3588 tel 84 11. Mise en Œuvre UML version du 24 avril 2009 GPA 789 : Analyse et Conception Orientées Objet ETS Mickaël Gardoni Bureau A 3588 tel 84 11 Mise en œuvre UML 1/ 25 Introduction Mise en œuvre d UML UML n est pas une méthode 2/ 25 1 UML n est qu un langage

Plus en détail

Formation projet Informatique. Qu'est-ce qu'un projet?

Formation projet Informatique. Qu'est-ce qu'un projet? Formation projet Informatique Qu'est-ce qu'un projet? Définition Typologie Les acteurs et les rôles Le déroulement Sommaire Définition Typologie Les acteurs et les rôles Le déroulement Sommaire Projet

Plus en détail

P R O G R A M M E E T I N S T R U C T I O N S O F F I C I E L L E S

P R O G R A M M E E T I N S T R U C T I O N S O F F I C I E L L E S P R O G R A M M E E T I N S T R U C T I O N S O F F I C I E L L E S POUR L ENSEIGNEMENT DE L INFORMATIQUE MPSI première année I. Objectifs de la formation II-1 Développement de compétences et d aptitudes

Plus en détail

Gestion de Projet Informatique

Gestion de Projet Informatique Gestion de Projet Informatique Partie 3 : Cycles de vie de projet Licence d'informatique 3 ième Année Tianxiao Liu Université de Cergy-Pontoise 1 GPI T. LIU The earliest moment is when you think it is

Plus en détail

1. INFORMATIQUE DANS LES DISCIPLINES, INFORMATIQUE DISCIPLINE

1. INFORMATIQUE DANS LES DISCIPLINES, INFORMATIQUE DISCIPLINE 29 UN PLAN DE FORMATION À L'INFORMATIQUE DE TOUS LES ÉLÈVES, DE L'ÉCOLE PRIMAIRE AU LYCÉE Note n 8 du groupe technique disciplinaire informatique - décembre 1991 - (principaux extraits) 1. INFORMATIQUE

Plus en détail

PLAN QUALITÉ élaboré par OSIRIS pour Frédéric Migeon

PLAN QUALITÉ élaboré par OSIRIS pour Frédéric Migeon PLAN QUALITÉ élaboré par OSIRIS pour Frédéric Migeon EXTENSION DU PLUGIN DE «RE-JEU» POUR JAVACT SOUS ECLIPSE Dans le cadre du module de Travail d'étude et de Recherche, master Informatique 1 ère année,

Plus en détail

Prise en Main de MS Project

Prise en Main de MS Project Prise en Main de MS Project Télécharger une version de démo valable 60 jours ici: http://www.zdnet.fr/telecharger/windows/fiche/0,39021313,39076442s,00.htm Microsoft Project vous aide à créer des prévisions

Plus en détail

1 Gestionnaire de Données WORD A4 F - USB / 2014-04-05 / 6020 Alco-Connect

1 Gestionnaire de Données WORD A4 F - USB / 2014-04-05 / 6020 Alco-Connect 1 Gestionnaire de Données WORD A4 F - USB / 2014-04-05 / 6020 Alco-Connect Introduction... 4 Comment décrire le logiciel Cosmos?... 4 Quelles sont les fonctions de ce logiciel PC?... 4 Est-il possible

Plus en détail

PRESENTATION ET SITUATION DU PROJET DANS SON ENVIRONNEMENT Contexte de réalisation

PRESENTATION ET SITUATION DU PROJET DANS SON ENVIRONNEMENT Contexte de réalisation Domotique E6 PROJET INFORMATIQUE Dossier de présentation et de validation du sujet de projet Groupement académique : Marseille Session : 2015 Lycée ou Centre de formation : LTR Dhuoda Ville : Nîmes Nom

Plus en détail

Exemple de projet. «Gestion de contacts»

Exemple de projet. «Gestion de contacts» Université Paul Valéry Montpellier 3 Antenne universitaire de Béziers L3 AES parcours MISASHS ECUE «Logiciels spécialisés» Exemple de projet «Gestion de contacts» G. Richomme Table des matières 1. Introduction...

Plus en détail

Fourniture, installation et maintenance D un système d'information Au sein du GIP LABOCEA : Logiciel de gestion des Stocks

Fourniture, installation et maintenance D un système d'information Au sein du GIP LABOCEA : Logiciel de gestion des Stocks Fourniture, installation et maintenance D un système d'information Au sein du GIP LABOCEA : Document ne pouvant être reproduit sans l'accord du GIP «LABOCEA» Page 1 sur 10 1. CONTEXTE... 3 2. OBJET...

Plus en détail

2.DIFFERENTS MODELES DE CYCLE DE VIE

2.DIFFERENTS MODELES DE CYCLE DE VIE 2.DIFFERENTS MODELES DE CYCLE DE VIE 2.1. INTRODUCTION... 1 2.1.1 Notion de cycle de vie... 1 2.1.2 Justification du cycle de vie... 1 2.2. LES DIFFERENTES PHASES DU CYCLE DE VIE... 2 2.2.1 Définition

Plus en détail

INTRODUCTION GENERALE

INTRODUCTION GENERALE INTRODUCTION GENERALE Chaque année, les entreprises ont de nombreux challenges à relever; adaptation à des contraintes légales nationales, européennes ou internationales, lancement de nouveaux services

Plus en détail

Formation projet informatique. Expression de besoins, définir un besoin informatique

Formation projet informatique. Expression de besoins, définir un besoin informatique Formation projet informatique Expression de besoins, définir un besoin informatique Enjeux L'expression de besoins est le premier document produit, avant même le commencement du projet Détermine le lancement

Plus en détail

basée sur le cours de Bertrand Legal, maître de conférences à l ENSEIRB www.enseirb.fr/~legal Olivier Augereau Formation UML

basée sur le cours de Bertrand Legal, maître de conférences à l ENSEIRB www.enseirb.fr/~legal Olivier Augereau Formation UML basée sur le cours de Bertrand Legal, maître de conférences à l ENSEIRB www.enseirb.fr/~legal Olivier Augereau Formation UML http://olivier-augereau.com Sommaire Introduction I) Les bases II) Les diagrammes

Plus en détail

SOMMAIRE. Rubrique : Audit et amélioration. Sommaire THEMATIQUE

SOMMAIRE. Rubrique : Audit et amélioration. Sommaire THEMATIQUE SOMMAIRE Rubrique : Audit et amélioration... 2 Rubrique : Divers...12 Rubrique : Maintenance...17 Rubrique : Système de management de la qualité...20 1 Rubrique : Audit et amélioration SOMMAIRE Auditer

Plus en détail

Gestion de projet - la phase de réalisation du projet

Gestion de projet - la phase de réalisation du projet Gestion de projet - la phase de réalisation du projet GÉRARD CASANOVA - DENIS ABÉCASSIS Paternité - Pas d'utilisation Commerciale - Pas de Modification : http://creativecommons.org/licenses/by-nc-nd/2.0/fr/

Plus en détail

TP-1 : Diagramme de Cas d utilisation Diagrammes d interaction

TP-1 : Diagramme de Cas d utilisation Diagrammes d interaction EFREI - L2 Année : 2013/2014 A. Lahlou TP-1 UML TP-1 : Diagramme de Cas d utilisation Diagrammes d interaction I Introduction Durant la première séance de TP, vous partez à la découverte de l AGL (Atelier

Plus en détail

GUIDE SUR L ASSISTANCE A LA MAÎTRISE D'OUVRAGE EN INFORMATIQUE

GUIDE SUR L ASSISTANCE A LA MAÎTRISE D'OUVRAGE EN INFORMATIQUE GUIDE SUR L ASSISTANCE A LA MAÎTRISE D'OUVRAGE EN INFORMATIQUE Validé par la Commission technique des marchés le 9 décembre 2004 1.1 OBJET DU GUIDE...3 1.2 LE PERIMETRE DU GUIDE...3 1.2.1 Terminologie

Plus en détail

LA DEMARCHE DE PROJET

LA DEMARCHE DE PROJET LA DEMARCHE DE PROJET Baccalauréat STI2D-SIN SIN 1.1 : La démarche de projet Objectifs o Utiliser les outils adaptés pour planifier un projet (Revue de projet, Cartes mentales, Gantt, chemin critique...

Plus en détail

Outil de gestion et de suivi des projets

Outil de gestion et de suivi des projets Outil de gestion et de suivi des projets Proposition technique et commerciale Amselem Jonathan - Corniglion Benoit - Sorine Olivier Troche Mariela - Zekri Sarah 08 Sommaire I. Les atouts de la proposition

Plus en détail

Gestion Camping Analyse

Gestion Camping Analyse Gestion de Camping - Analyse 1/27 Projet Cobol Première Partie Gestion Camping Analyse Damien Bironneau Titouan Alasseur Thomas Bechepay Jordane Goffin Le Guillou Thibaud Gestion de Camping - Analyse 2/27

Plus en détail

Le Processus RUP. H. Kadima. Tester. Analyst. Performance Engineer. Database Administrator. Release Engineer. Project Leader. Designer / Developer

Le Processus RUP. H. Kadima. Tester. Analyst. Performance Engineer. Database Administrator. Release Engineer. Project Leader. Designer / Developer Le Processus RUP Database Administrator Project Leader H. Kadima Performance Engineer Release Engineer Analyst Designer / Developer Tester Table des matières 1. De l artisanat à l industrialisation de

Plus en détail

Aide à la gestion du projet final ISN

Aide à la gestion du projet final ISN Aide à la gestion du projet final ISN 1 - La place du projet dans l ISN «Les activités des élèves sont organisées autour d une équipe de projet dont les tâches sont les suivantes : repérer le besoin ou

Plus en détail

CONCEPTS ET MISE EN PRATIQUE POUR LA VALIDATION DE GRANDS SYSTÈMES

CONCEPTS ET MISE EN PRATIQUE POUR LA VALIDATION DE GRANDS SYSTÈMES MODEL-BASED TESTING (MBT) CONCEPTS ET MISE EN PRATIQUE POUR LA VALIDATION DE GRANDS SYSTÈMES Le Model-Based Testing est une pratique de test en plein développement dans l'industrie pour accroitre l'efficacité

Plus en détail

Réorganisation du processus de transfusion sanguine au Liban

Réorganisation du processus de transfusion sanguine au Liban Réorganisation du processus de transfusion sanguine au Liban Cahier des charges du Logiciel Médico Technique Rédigé en collaboration avec Cahier des charges du Logiciel Médico Technique La procédure d

Plus en détail

Le diagramme des relations met en évidence les multiples relations entre les différents éléments, causes et effets d'un système.

Le diagramme des relations met en évidence les multiples relations entre les différents éléments, causes et effets d'un système. Sept outils du management (Les) Introduction Diagramme des relations Diagramme des affinités Diagramme en arbre Diagramme matriciel Diagramme des décisions d'action (PDPC) Diagramme sagittal (CPM) Analyse

Plus en détail

MS PROJECT 2000. Prise en main. Date: Mars 2003. Anère MSI. 12, rue Chabanais 75 002 PARIS E mail : jcrussier@anere.com Site : www.anere.

MS PROJECT 2000. Prise en main. Date: Mars 2003. Anère MSI. 12, rue Chabanais 75 002 PARIS E mail : jcrussier@anere.com Site : www.anere. DOCUMENTATION MS PROJECT 2000 Prise en main Date: Mars 2003 Anère MSI 12, rue Chabanais 75 002 PARIS E mail : jcrussier@anere.com Site : www.anere.com Le présent document est la propriété exclusive d'anère

Plus en détail

Gestion des modifications d un projet système d'information

Gestion des modifications d un projet système d'information Centre national de la recherche scientifique Direction des systèmes d'information REFERENTIEL QUALITE Procédure Qualité Gestion des modifications d un proj système d'information Référence : CNRS/DSI/conduite-proj/maintenance-evolution/proc-gestion-modification

Plus en détail

Rectorat de Grenoble

Rectorat de Grenoble MINISTERE DE L EDUCATION NATIONALE RECTORAT DE L ACADEMIE DE GRENOBLE CAHIER DES CLAUSES TECHNIQUES PARTICULIERES (CCTP) MISE EN ŒUVRE DE LA SOLUTION EASYVISTA Version 0.1-7 décembre 2011 La procédure

Plus en détail

Processus Unifié de développement de logiciel

Processus Unifié de développement de logiciel Processus Unifié de développement de logiciel Plan 1. SUP : une simplification de RUP 2. Les éléments de modélisation de SUP 3. Description de la dynamique de SUP 4. SUP sur une étude de cas 2 SUP : une

Plus en détail

2 Grad Info Soir Langage C++ Juin 2007. Projet BANQUE

2 Grad Info Soir Langage C++ Juin 2007. Projet BANQUE 2 Grad Info Soir Langage C++ Juin 2007 Projet BANQUE 1. Explications L'examen comprend un projet à réaliser à domicile et à documenter : - structure des données, - objets utilisés, - relations de dépendance

Plus en détail

LA QUALITE DU LOGICIEL

LA QUALITE DU LOGICIEL LA QUALITE DU LOGICIEL I INTRODUCTION L'information est aujourd'hui une ressource stratégique pour la plupart des entreprises, dans lesquelles de très nombreuses activités reposent sur l'exploitation d'applications

Plus en détail

Cours de Génie Logiciel

Cours de Génie Logiciel Cours de Génie Logiciel Sciences-U Lyon Diagrammes UML (2) http://www.rzo.free.fr Pierre PARREND 1 Avril 2005 Sommaire Les Diagrammes UML Diagrammes de Collaboration Diagrammes d'etats-transitions Diagrammes

Plus en détail

CAHIER DES CHARGES Création d une calculatrice vocale. Androcalc CERI 2014/2015

CAHIER DES CHARGES Création d une calculatrice vocale. Androcalc CERI 2014/2015 CAHIER DES CHARGES Création d une calculatrice vocale sous Android Androcalc CERI 2014/2015 1/13 Plan I. Etat des lieux 3 1- Le contexte..3 2- Les Objectifs 3 3- La problématique 4 4- L existant.4 II.

Plus en détail

PLANIFICATION ET SUIVI D'UN PROJET

PLANIFICATION ET SUIVI D'UN PROJET Centre national de la recherche scientifique Direction des systèmes d'information REFERENTIEL QUALITE Guide méthodologique PLANIFICATION ET SUIVI D'UN PROJET Référence : CNRS/DSI/conduite-projet/developpement/gestion-projet/guide-planfi-suivi-projet

Plus en détail

Processus de développement logiciel et AMDEC

Processus de développement logiciel et AMDEC Processus de développement logiciel et AMDEC Stéphane REY Mars 2006 Le processus de développement logiciel décrit les étapes nécessaires pour développer des fonctions logicielles en garantissant maintenabilité

Plus en détail

Épreuve E6 PARCOURS DE PROFESSIONNALISATION Coefficient 3

Épreuve E6 PARCOURS DE PROFESSIONNALISATION Coefficient 3 Épreuve E6 PARCOURS DE PROFESSIONNALISATION Coefficient 3 1. Ce que disent les textes officiels [extrait] FINALITÉS ET OBJECTIFS Cette épreuve vise à évaluer, d une part, le degré d appropriation de son

Plus en détail

Configuration Interface for MEssage ROuting

Configuration Interface for MEssage ROuting Configuration Interface for MEssage ROuting Plan d'assurance Qualité Logicielle Date : 05/04/07 Version : 1.1 Statut : diffusable Auteurs : BAGNARD Natacha FOROT Julien 1/19 Tables des révisions Version

Plus en détail

[ Hornet ] Charte de méthodologie

[ Hornet ] Charte de méthodologie [ Hornet ] Hornet Cette création est mise à disposition selon le Contrat Paternité - Pas d'utilisation Commerciale - Partage des Conditions Initiales à l'identique disponible en ligne http://creativecommons.org/licenses/by-nc-sa/2.0/fr/

Plus en détail

Processus Gestion de Projet

Processus Gestion de Projet Processus Gestion de Projet 1 / 11 Contenu 1 Introduction... 3 2 Le cycle de vie du projet... 4 2.1 Présentation... 4 2.2 Cycle de vie d un projet... 5 2.3 Les livrables... 5 3 Les étapes du management

Plus en détail

Projet Personnalisé Encadré PPE 2

Projet Personnalisé Encadré PPE 2 BTS Services Informatiques aux Organisations Session 2014 Projet Personnalisé Encadré PPE 2. GESTION D'UTILISATEURS SYSTÈMES ET BASE DE DONNÉES, INSTALLATION ET CONFIGURATION D'OUTILS DE SUPERVISION ET

Plus en détail

Le Guide Pratique des Processus Métiers

Le Guide Pratique des Processus Métiers Guides Pratiques Objecteering Le Guide Pratique des Processus Métiers Auteur : Version : 1.0 Copyright : Softeam Equipe Conseil Softeam Supervisée par Philippe Desfray Softeam 21 avenue Victor Hugo 75016

Plus en détail

Cours Gestion de projet

Cours Gestion de projet Cours Gestion de projet Méthodes de conduite de projet Version Date Auteur V1.8 Septembre 2007 Pascal HEYER 1 Méthodes de conduite de projet Ce document est publié sous la licence libre Creative Commons-BY-NC-SA

Plus en détail

Conduite et Gestion de Projet

Conduite et Gestion de Projet /43 Conduite et Gestion de Projet Thierry Hamon Bureau H202 - Institut Galilée Tél. : 33 1.49.40.35.53 Bureau 150 LIM&BIO EA 3969 Université Paris 13 - UFR Léonard de Vinci 74, rue Marcel Cachin, F-93017

Plus en détail

Cas d'étude : Puissance 4 Analyse des besoins

Cas d'étude : Puissance 4 Analyse des besoins 1 Génie Logiciel Cas d'étude : Puissance 4 Analyse des besoins Renaud Marlet LaBRI / INRIA http://www.labri.fr/~marlet màj 18/04/2007 2 Exercice Vous êtes employé(e) dans une société qui édite des jeux

Plus en détail

Cours de Génie Logiciel

Cours de Génie Logiciel Cours de Génie Logiciel Sciences-U Lyon Gestion de Projet Informatique http://www.rzo.free.fr Pierre PARREND 1 Mars 2005 Sommaire Gestion de projet informatique Cycle de vie du logiciel Modèles de Méthodes

Plus en détail

Introduction à la gestion de projets. Laurent Poinsot. Introduction. 26 janvier 2009

Introduction à la gestion de projets. Laurent Poinsot. Introduction. 26 janvier 2009 26 janvier 2009 Le modèle du est une méthodologie de développement logiciel qui est devenue un standard de l industrie logicielle. Ce modèle est constitué de deux phases : l une est dite descendante et

Plus en détail

L'audit des systèmes d'informations - Une méthode formalisée, la technique des Flow-Charts.

L'audit des systèmes d'informations - Une méthode formalisée, la technique des Flow-Charts. L'audit des systèmes d'informations - Une méthode formalisée, la technique des Flow-Charts. L'objectif de l'auditeur est de comprendre les méthodes et les systèmes employés au sein de l'organisation, ainsi

Plus en détail

Architecture d'entreprise : Guide Pratique de l'architecture Logique

Architecture d'entreprise : Guide Pratique de l'architecture Logique Guides Pratiques Objecteering Architecture d'entreprise : Guide Pratique de l'architecture Logique Auteur : Version : 1.0 Copyright : Softeam Equipe Conseil Softeam Supervisée par Philippe Desfray Softeam

Plus en détail