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.

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

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

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

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

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

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

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

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

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

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

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

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

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

GESTION DE PROJET SÉANCE 2 : LES CYCLE DE VIE D'UN PROJET

GESTION DE PROJET SÉANCE 2 : LES CYCLE DE VIE D'UN PROJET GESTION DE PROJET SÉANCE 2 : LES CYCLE DE VIE D'UN PROJET 1 Tianxiao LIU Licence Professionnelle Réseaux & Sécurité Université de Cergy-Pontoise http://depinfo.u-cergy.fr/~tliu/lpg.php PLAN Objectif et

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

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

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

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

Systèmes de transport public guidés urbains de personnes

Systèmes de transport public guidés urbains de personnes service technique des Remontées mécaniques et des Transports guidés Systèmes de transport public guidés urbains de personnes Principe «GAME» (Globalement Au Moins Équivalent) Méthodologie de démonstration

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

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

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

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

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

Génie logiciel. Concepts fondamentaux. Bruno MERMET, Université du Havre 1

Génie logiciel. Concepts fondamentaux. Bruno MERMET, Université du Havre 1 Génie logiciel Concepts fondamentaux Bruno MERMET, Université du Havre 1 Nécessité du Génie Logiciel Bruno MERMET, Université du Havre 2 Développement d un logiciel Caractéristiques souhaitées : Adéquation

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

URBANISME DES SYSTÈMES D INFORMATION

URBANISME DES SYSTÈMES D INFORMATION FAYCAL AYECH GL2. INSAT 2010/2011 INTRODUCTION AUX SYSTÈMES D INFORMATIONS URBANISME DES SYSTÈMES D INFORMATION De l Urbanisme à L Urbanisation des SI Urbanisme : Mise en œuvre des politiques urbaines

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

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

Développement d'un projet informatique

Développement d'un projet informatique Développement d'un projet informatique par Emmanuel Delahaye (Espace personnel d'emmanuel Delahaye) Date de publication : 27 janvier 2008 Dernière mise à jour : 25 avril 2009 Cet article présente un certain

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

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

MODALITES DE SUIVI DU PROJET ANNUEL DU MASTER 2 SOLUTIONS INFORMATIQUES LIBRES

MODALITES DE SUIVI DU PROJET ANNUEL DU MASTER 2 SOLUTIONS INFORMATIQUES LIBRES MODALITES DE SUIVI DU PROJET ANNUEL DU MASTER 2 SOLUTIONS INFORMATIQUES LIBRES Département Informatique UFR Sciences 2 Boulevard Lavoisier 49045 Angers Cedex 01 Auteur : Jean-Michel Richer Email : jean-michel.richer@univ-angers.fr

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

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

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

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

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

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

Chapitre I : le langage UML et le processus unifié

Chapitre I : le langage UML et le processus unifié I. Introduction Les méthodes d analyse orientées objet sont initialement issues des milieux industriels. La préoccupation dominante de leurs auteurs est le génie logiciel, c est-àdire les principes et

Plus en détail

UNITE U 6.2 : PROJET TECHNIQUE OBJET DE L'EPREUVE.

UNITE U 6.2 : PROJET TECHNIQUE OBJET DE L'EPREUVE. UNITE U 6.2 : PROJET TECHNIQUE OBJET DE L'EPREUVE. Cette épreuve permet de valider les compétences C1, C2, C3 et T2 du référentiel au travers de la démarche de projet 15 que le candidat aura mis en œuvre.

Plus en détail

Informatiques. Module : Outils RAD

Informatiques. Module : Outils RAD Management de Projets Informatiques Module : Outils RAD Niveau : S4 du L2/ISIL Génie Logiciel Le terme génie logiciel (en anglais software engineering) désigne l'ensemble des méthodes, des techniques et

Plus en détail

Concepteur Développeur Informatique

Concepteur Développeur Informatique Référentiel de Certification UNION EUROPEENNE Fonds Social Européen DSP REAC RC RF CDC Concepteur Développeur Informatique Libellé réduit: CDI Code titre: TP-01281 Type de document: Guide RC Version: 1

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

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

Conduite de projets informatiques Développement, analyse et pilotage (2ième édition)

Conduite de projets informatiques Développement, analyse et pilotage (2ième édition) Avant-propos 1. Objectifs du livre 13 2. Structure du livre 14 Un projet informatique 1. Les enjeux 17 1.1 Les buts d'un projet 17 1.2 Les protagonistes d'un projet 18 1.3 Exemples de projets 19 2. Les

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

claroline classroom online

claroline classroom online de la plate-forme libre d'apprentissage en ligne Claroline 1.4 Manuel Révision du manuel: 06/2003 Créé le 07/09/2003 12:02 Page 1 Table des matières 1) INTRODUCTION...3 2) AFFICHER LA PAGE DE DEMARRAGE...3

Plus en détail

TRAAM STI 2013-2014 Acquisition et exploitations pédagogiques des données sur un système pédagogique

TRAAM STI 2013-2014 Acquisition et exploitations pédagogiques des données sur un système pédagogique TRAAM STI 2013-2014 Acquisition et exploitations pédagogiques des données sur un système pédagogique Bilan technique et éléments de développement Fonctionnalités attendues Une vingtaine d établissements

Plus en détail

Business Project Management : Cycle de vie des documents et workflow

Business Project Management : Cycle de vie des documents et workflow Business Project Management : Cycle de vie des documents et workflow Iut de Tours Département Information-Communication Option Gestion de l Information et du Document dans les Organisations Page 1 sur

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

PTSI PT ÉTUDE DES SYSTEMES

PTSI PT ÉTUDE DES SYSTEMES PTSI PT ÉTUDE DES SYSTEMES Table des matières 1 - PRESENTATION GENERALE... 1 1.1 - Définition d'un système... 1 1.2 - Exemples... 1 1.3 - Cycle de vie d'un système... 1 1.4 Langage de description SysML...

Plus en détail

LES INTERFACES HOMME-MACHINE

LES INTERFACES HOMME-MACHINE LES INTERFACES HOMME-MACHINE 1 ère Partie : Introduction aux Interfaces Homme-Machine 2 ème Partie : Notions de base sur les Sciences Cognitives 3 ème Partie : Recommandations ergonomiques 4 ème Partie

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

ISTA H.H www.developpez.c.la Diagramme d activité SOMMAIRE

ISTA H.H www.developpez.c.la Diagramme d activité SOMMAIRE SOMMAIRE I. Définition... 2 II. Intérêts des diagrammes d activité... 5 III. Quand employer le diagramme d activité?... 5 IV. Avantage et Inconvénient... 6 V. Les étapes de constructions... 7 VI. Comment

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

Projet d Appui à la Réforme de l Enseignement Supérieur (PARES II) Termes de référence

Projet d Appui à la Réforme de l Enseignement Supérieur (PARES II) Termes de référence Projet d Appui à la Réforme de l Enseignement Supérieur (PARES II) Termes de référence Titre du projet : Co-construction des licences appliquées et des mastères professionnels Titre de la mission : Mise

Plus en détail

CONFÉRENCE EUROPÉENNE DES MINISTRES DES TRANSPORTS EUROPEAN CONFERENCE OF MINISTERS OF TRANSPORT

CONFÉRENCE EUROPÉENNE DES MINISTRES DES TRANSPORTS EUROPEAN CONFERENCE OF MINISTERS OF TRANSPORT CONFÉRENCE EUROPÉENNE DES MINISTRES DES TRANSPORTS EUROPEAN CONFERENCE OF MINISTERS OF TRANSPORT DÉCLARATION DE PRINCIPES CONCERNANT L'ERGONOMIE ET LA SÉCURITÉ DES SYSTÈMES D'INFORMATION EMBARQUÉS Introduction

Plus en détail

M E S. Organiser et suivre la performance de ses ateliers

M E S. Organiser et suivre la performance de ses ateliers M E S. Organiser et suivre la performance de ses ateliers Lorraine La nécessité de «piloter au plus juste» les équipements et les ateliers est à l origine de la naissance des logiciel de Manufacturing

Plus en détail

Rapport d'audit. «Librairie Informatique»

Rapport d'audit. «Librairie Informatique» GL51 Rapport d'audit «Librairie Informatique» Code : BATSPETA-000 Maîtrise d'oeuvre Maîtrise d'ouvrage Responsables de l'audit M. Fischer M. Petrequin Melle Bats, M. Petazzoni Date rédaction : 05/01/04

Plus en détail

JDEV 2013 : atelier T1.A1. Spécification des besoins avec UML. Michel Lemoine michel.lemoine@gmail.com

JDEV 2013 : atelier T1.A1. Spécification des besoins avec UML. Michel Lemoine michel.lemoine@gmail.com JDEV 2013 : atelier T1.A1 Spécification des besoins avec UML michel.lemoine@gmail.com 1 Plan Rappels Rôle des "cas d'utilisation" dans UML 2.0 Notation des cas d'utilisation Un exemple de cahier des charges

Plus en détail

Programme «Analyste Programmeur» Diplôme d état : «Développeur Informatique» Homologué au niveau III (Bac+2) (JO N 176 du 1 août 2003) (34 semaines)

Programme «Analyste Programmeur» Diplôme d état : «Développeur Informatique» Homologué au niveau III (Bac+2) (JO N 176 du 1 août 2003) (34 semaines) Programme «Analyste Programmeur» Diplôme d état : «Développeur Informatique» Homologué au niveau III (Bac+2) (JO N 176 du 1 août 2003) (34 semaines) Module 1 : Programmer une application informatique Durée

Plus en détail

LOGICIEL DE GESTION DE DOCUMENTS PDF : PROJET INFO 1

LOGICIEL DE GESTION DE DOCUMENTS PDF : PROJET INFO 1 LOGICIEL DE GESTION DE DOCUMENTS PDF : PROJET INFO 1 L. POINSOT Contact client : Laurent Poinsot (laurent.poinsot@lipn.univ-paris13.fr) Résumé : Ce document est le cahier des charges du projet INFO 1.

Plus en détail

TIERCE MAINTENANCE APPLICATIVE

TIERCE MAINTENANCE APPLICATIVE Notre expertise au cœur de vos projets TIERCE MAINTENANCE APPLICATIVE SERVICE LEVEL AGREEMENT Sommaire 1. Terminologie...4 1.1. Définitions...4 1.2. Abréviations...5 2. Missions & Objectifs...5 2.1. Missions...5

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

Fiche conseil n 16 Audit

Fiche conseil n 16 Audit AUDIT 1. Ce qu exigent les référentiels Environnement ISO 14001 4.5.5 : Audit interne EMAS Article 3 : Participation à l'emas, 2.b Annexe I.-A.5.4 : Audit du système de management environnemental SST OHSAS

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

Principes de Paquetage. Packaging et Marketing

Principes de Paquetage. Packaging et Marketing Génie Logiciel Conception Principes de Paquetage Packaging et Marketing La conception Définition Générale : Activité créatrice qui consiste à élaborer un projet, ou une partie des éléments le constituant,

Plus en détail

NOUVEAUTES de Microsoft Dynamics CRM 2011 REF FR 80342A

NOUVEAUTES de Microsoft Dynamics CRM 2011 REF FR 80342A NOUVEAUTES de Microsoft Dynamics CRM 2011 REF FR 80342A Durée : 1 jour A propos de ce cours Cette formation d'un jour, Nouveautés de Microsoft Dynamics CRM 2011, fournit aux étudiants les outils et informations

Plus en détail

INF2015 Développement de logiciels dans un environnement Agile. Examen intra 20 février 2014 17:30 à 20:30

INF2015 Développement de logiciels dans un environnement Agile. Examen intra 20 février 2014 17:30 à 20:30 Examen intra 20 février 2014 17:30 à 20:30 Nom, prénom : Code permanent : Répondez directement sur le questionnaire. Question #1 5% Quelle influence peut avoir le typage dynamique sur la maintenabilité

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

Analyse,, Conception des Systèmes Informatiques

Analyse,, Conception des Systèmes Informatiques Analyse,, Conception des Systèmes Informatiques Méthode Analyse Conception Introduction à UML Génie logiciel Définition «Ensemble de méthodes, techniques et outils pour la production et la maintenance

Plus en détail

Le génie logiciel. maintenance de logiciels.

Le génie logiciel. maintenance de logiciels. Le génie logiciel Définition de l IEEE (IEEE 1990): L application d une approche systématique, disciplinée et quantifiable pour le développement, l opération et la maintenance de logiciels. Introduction

Plus en détail

METHODOLOGIE : INGENIERIE DES SYSTEMES

METHODOLOGIE : INGENIERIE DES SYSTEMES METHODOLOGIE : INGENIERIE DES SYSTEMES L ingénierie de systèmes regroupe l ensemble des activités de pilotage des projets de construction effective d un système en s appuyant sur sa décomposition architecturale

Plus en détail

Expression des besoins

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

Plus en détail

Service d'installation et de démarrage de la solution de stockage réseau HP StoreEasy 1000/3000

Service d'installation et de démarrage de la solution de stockage réseau HP StoreEasy 1000/3000 Service d'installation et de démarrage de la solution de stockage réseau Services HP Données techniques Le service d'installation et de démarrage de la solution de stockage réseau offre l'installation

Plus en détail

Anticiper pour avoir une innovation d'avance : le leitmotiv de Pierre Jouniaux, entrepreneur du big data!

Anticiper pour avoir une innovation d'avance : le leitmotiv de Pierre Jouniaux, entrepreneur du big data! Anticiper pour avoir une innovation d'avance : le leitmotiv de Pierre Jouniaux, entrepreneur du big data! Pierre Jouniaux http://www.safety line.fr CV : Pierre Jouniaux, ingénieur aéronautique, pilote

Plus en détail

GOL-502 Industrie de services. Travaux Pratique / Devoir #7

GOL-502 Industrie de services. Travaux Pratique / Devoir #7 GOL-502 Industrie de services Travaux Pratique / Devoir #7 Version 2012 Modélisation à l'aide du langage UML 1) Diagramme de cas d'utilisation 2) Diagramme de classes 3) Diagramme de séquence 4) Diagramme

Plus en détail

CAHIER DES CHARGES POUR APPLICATION MOBILE SAMSUNG SUR OS BADA. Gestionnaire de Mots de Passe Par Anis Safine. Page n 1

CAHIER DES CHARGES POUR APPLICATION MOBILE SAMSUNG SUR OS BADA. Gestionnaire de Mots de Passe Par Anis Safine. Page n 1 CAHIER DES CHARGES POUR APPLICATION MOBILE SAMSUNG SUR OS BADA Par Anis Safine Page n 1 Sommaire I. Descriptif général de l'application...2 1. Problème et solution proposée...2 2. Question de sécurité...2

Plus en détail

Programme de formation

Programme de formation INSCRIVEZ VOUS Formations sélectionnées et financées par le FAFIEC Programme de formation mardi 16 septembre 2014 Les Métiers du Test Module 5.2 - Automatisation des tests fonctionnels : HP Unified Functional

Plus en détail

CINEMATIQUE DE FICHIERS

CINEMATIQUE DE FICHIERS ANDRE ANTHONY BRUNEAU Vincent JOUANNIN ROMAIN MAZEAUD MARINE RIOCHET Tony Groupe 609 CINEMATIQUE DE FICHIERS Mini-projet: Gestion de Ventes d'articles Enseignant: MONCEAUX Laura Année 2011 / 2012 TABLE

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é Introduction Delphine Longuet delphine.longuet@lri.fr Logiciel : définitions Ensemble d'entités nécessaires au fonctionnement

Plus en détail

LO21 : QCalculator. Calculatrice en notation polonaise inversée. Johan Soulet & Jonathan Jehanne Université de Technologie de Compiègne

LO21 : QCalculator. Calculatrice en notation polonaise inversée. Johan Soulet & Jonathan Jehanne Université de Technologie de Compiègne LO21 : QCalculator Calculatrice en notation polonaise inversée Johan Soulet & Jonathan Jehanne Université de Technologie de Compiègne Printemps 2012 Introduction Ce document présente le résultat du projet

Plus en détail

ToutelaQualite. FAQ Rechercher S enregistrer Profil Membres Groupes Se connecter pour vérifier ses messages privés Connexion

ToutelaQualite. FAQ Rechercher S enregistrer Profil Membres Groupes Se connecter pour vérifier ses messages privés Connexion creer un forum supprimer les publicites ToutelaQualite FAQ Rechercher S enregistrer Profil Membres Groupes Se connecter pour vérifier ses messages privés Connexion ISO 9001 V2008 ToutelaQualite Index du

Plus en détail

Nom de l application

Nom de l application Ministère de l Enseignement Supérieur et de la Recherche Scientifique Direction Générale des Etudes Technologiques Institut Supérieur des Etudes Technologiques de Gafsa Département Technologies de l Informatique

Plus en détail

Chapitre 1 : Introduction aux bases de données

Chapitre 1 : Introduction aux bases de données Chapitre 1 : Introduction aux bases de données Les Bases de Données occupent aujourd'hui une place de plus en plus importante dans les systèmes informatiques. Les Systèmes de Gestion de Bases de Données

Plus en détail

FOIRE AUX QUESTIONS PAIEMENT PAR INTERNET. Nom de fichier : Monetico_Paiement_Foire_aux_Questions_v1.7 Numéro de version : 1.7 Date : 2014-05-29

FOIRE AUX QUESTIONS PAIEMENT PAR INTERNET. Nom de fichier : Monetico_Paiement_Foire_aux_Questions_v1.7 Numéro de version : 1.7 Date : 2014-05-29 FOIRE AUX QUESTIONS PAIEMENT PAR INTERNET Nom de fichier : Monetico_Paiement_Foire_aux_Questions_v1.7 Numéro de version : 1.7 Date : 2014-05-29 FOIRE AUX QUESTIONS Confidentiel Titre du document : Monetico

Plus en détail

MEGA ITSM Accelerator. Guide de Démarrage

MEGA ITSM Accelerator. Guide de Démarrage MEGA ITSM Accelerator Guide de Démarrage MEGA 2009 SP4 1ère édition (juin 2010) Les informations contenues dans ce document pourront faire l objet de modifications sans préavis et ne sauraient en aucune

Plus en détail

COMMISSION EUROPÉENNE Direction générale Marché intérieur et Services. Table des matières

COMMISSION EUROPÉENNE Direction générale Marché intérieur et Services. Table des matières COMMISSION EUROPÉENNE Direction générale Marché intérieur et Services POLITIQUE DES MARCHÉS PUBLICS FICHE EXPLICATIVE ACCORDS CADRES DIRECTIVE CLASSIQUE 1 Table des matières 1. INTRODUCTION ET DEFINITIONS...1

Plus en détail

LA COMPTABILITÉ DU COMITÉ D ENTREPRISE : DE NOUVELLES OBLIGATIONS DE TRANSPARENCE À PARTIR DU 1 er JANVIER 2015

LA COMPTABILITÉ DU COMITÉ D ENTREPRISE : DE NOUVELLES OBLIGATIONS DE TRANSPARENCE À PARTIR DU 1 er JANVIER 2015 Groupement des Métiers de l Imprimerie -------------------------------------------------------------------------------------------------------------------------------------- DÉCEMBRE 2014 NOTE N 24 LA

Plus en détail

1. Considérations sur le développement rapide d'application et les méthodes agiles

1. Considérations sur le développement rapide d'application et les méthodes agiles Chapitre 1 Introduction 1. Considérations sur le développement rapide d'application et les méthodes agiles 1.1 Rappel Longtemps les méthodes en cascade ou en V ont été opposées aux démarches empiriques

Plus en détail

UML : Modéliser la Dynamique

UML : Modéliser la Dynamique MAI NFE103 Année 2013-2014 UML : Modéliser la Dynamique F.-Y. Villemin (f-yv@cnam.fr) Plan! Introduction! Cas d'utilisation: Diagramme des Cas d'utilisation! Evènements! Scénario: Diagrammes de Séquence

Plus en détail

ERP5. Gestion des Services Techniques des Collectivités Locales

ERP5. Gestion des Services Techniques des Collectivités Locales Gestion des Services Techniques des Collectivités Locales Cte 1 2 P 3 s tio T 4 m ilg h trc c n p.o 5 re u fe ro a le tio c M S tw u aa c e O 2 Relation Citoyen Interventions Patrimoine Core Ressources

Plus en détail

Présentation générale. Data & Information System

Présentation générale. Data & Information System Présentation générale Data & Information System SOMMAIRE Rédacteurs : Réf.: F. Barthelemy AXIO_EXAGIS_V1 POSITIONNEMENT INTERFACE UTILISATEUR FONCTIONNALITES TRAÇABILITE MODELE ECONOMIQUE AUTRES EXAGIS

Plus en détail

Architecture Logicielle

Architecture Logicielle Architecture Logicielle Chapitre 3: UML pour la description et la documentation d une architecture logicielle Année universitaire 2013/2014 Semestre 1 Rappel L architecture d un programme ou d un système

Plus en détail

BOC/PP 31 juillet 2006 Nº17 texte 11

BOC/PP 31 juillet 2006 Nº17 texte 11 texte 11 CONTRÔLE GÉNÉRAL DES ARMÉES. NOTE-CIRCULAIRE N 1993/DEF/CGA/CRM relative au cahier des clauses administratives particulières communes relatives au traitement d une non conformité, à l émission

Plus en détail

Brevet de technicien supérieur Conception et Réalisation en Chaudronnerie Industrielle

Brevet de technicien supérieur Conception et Réalisation en Chaudronnerie Industrielle Brevet de technicien supérieur Conception et Réalisation en Chaudronnerie Industrielle ACTIVITÉS ET TÂCHES PROFESSIONNELLES Les activités professionnelles décrites ci-après, déclinées à partir des fonctions

Plus en détail

1..LOGICIEL ATAL... 3

1..LOGICIEL ATAL... 3 Gestion des Demandes & Interventions des Services Techniques GGEESSTTI IONN DDEESS DDEEMAA NNDDEESS && I NNTTEERRVVEENNTTI IONNSS 1..LOGICIEL ATAL... 3 2. MODULARITE ET INTEGRATION... 4 2.1. E-ATAL...

Plus en détail

EXAMEN PROFESSIONNEL DE VERIFICATION D APTITUDE AUX FONCTIONS D ANALYSTE-DEVELOPPEUR SESSION 2009

EXAMEN PROFESSIONNEL DE VERIFICATION D APTITUDE AUX FONCTIONS D ANALYSTE-DEVELOPPEUR SESSION 2009 EXAMEN PROFESSIONNEL DE VERIFICATION D APTITUDE AUX FONCTIONS D ANALYSTE-DEVELOPPEUR SESSION 2009 EPREUVE ECRITE D ADMISSIBILITE DU 14 MAI 2009 ETUDE D UN CAS D AUTOMATISATION PERMETTANT D APPRECIER LA

Plus en détail