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 / 23 Méthodes de développement Guide pour la rédaction d'une spécification technique de besoin UML 1 - Objet... 2 2 - Rôle de la STB et méthode itérative... 2 3 - De la STB structurée à la STB UML...

Plus en détail

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

Méthodes de développement

Méthodes de développement 1 / 19 Méthodes de développement Guide de rédaction d'un plan de développement logiciel 1 - OBJET DU GUIDE... 2 2 - OBJECTIF DU PDL... 2 3 - PLAN TYPE DU PDL... 2 4 - TRAVAUX DE PRÉPARATION DU PDL... 2

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

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

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

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

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

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

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

TD McGood 2004. McGood. Mastère 2004 1

TD McGood 2004. McGood. Mastère 2004 1 McGood Mastère 2004 1 McGood Une petite entreprise familiale de restauration rapide, avec des produits de terroir (McGood), voudrait cesser de tenir sa comptabilité à la main (écriture des opérations comptables

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

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

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

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

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

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

LES COURS ONLINE. ar des étudiants our des étudiants. Olden Fabre, Cynthia Thimon, Jakub Kaluza, Jean Desravines, Oliver Hamm

LES COURS ONLINE. ar des étudiants our des étudiants. Olden Fabre, Cynthia Thimon, Jakub Kaluza, Jean Desravines, Oliver Hamm LES COURS ONLINE P ar des étudiants our des étudiants Olden Fabre, Cynthia Thimon, Jakub Kaluza, Jean Desravines, Oliver Hamm CAHIER DES CHARGES I - Préface...4 II - Introduction...5 III - Glossaire...6

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

Gestion de projet - la phase de définition du projet

Gestion de projet - la phase de définition du projet Gestion de projet - la phase de définition 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

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

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

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

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

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

Chapitre I - Introduction et conseils au lecteur

Chapitre I - Introduction et conseils au lecteur Chapitre I - Introduction et conseils au lecteur Cette partie introductive situe la place de l'algorithmique dans le développement logiciel et fournit au lecteur des conseils : conseils pour bien analyser

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

FICHE JANVIER 2009 THÉMATIQUE. Direction de projets et programmes

FICHE JANVIER 2009 THÉMATIQUE. Direction de projets et programmes FICHE JANVIER 2009 THÉMATIQUE Direction de projets et programmes La représentation par les processus pour les projets Système d Information (SI) La modélisation de l'entreprise par les processus devient

Plus en détail

REFERENTIEL NORMATIF du CNES

REFERENTIEL NORMATIF du CNES REFERENTIEL NORMATIF du CNES Référence : Méthode et Procédure DEMARCHE D'ANALYSE DU LOGICIEL Annexe Technique de la MP RNC-CNES-Q-80-529 APPROBATION Président du CDN ; date et nom : Page i.1 PAGE D'ANALYSE

Plus en détail

Les composantes d'une application et la logique de programmation

Les composantes d'une application et la logique de programmation Chapitre 10 Les composantes d'une application et la logique de programmation Introduction La mise en situation propose d'étudier le principe de fonctionnement d'une application sous forme d'une base de

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 DES BESOINS

MODÉLISATION DES BESOINS MODÉLISATION DES BESOINS Diagrammes de cas d utilisation Cas d'utilisation : Use Case (Jacobson) Permettent déxprimer les attentes/besoins des utilisateurs Permettent de définir les limites du système

Plus en détail

Méthodes de développement. Guide pour la rédaction d'un document de définition de release

Méthodes de développement. Guide pour la rédaction d'un document de définition de release 1 / 21 Méthodes de développement Guide pour la rédaction d'un document de définition de release Sommaire 1 - Introduction... 2 1.1 Objet du guide... 2 1.2 Terminologie et sigles utilisés... 2 2 - Plan

Plus en détail

REFERENTIEL NORMATIF du CNES

REFERENTIEL NORMATIF du CNES REFERENTIEL NORMATIF du CNES Référence : Méthode et Procédure Annexe Technique à la MP RNC-CNES-Q-80-529 APPROBATION Président du CDN ; date et nom : Page i.1 PAGE D'ANALYSE DOCUMENTAIRE TITRE : MOTS

Plus en détail

UML. Cas d'utilisation. Delphine Longuet. delphine.longuet@lri.fr

UML. Cas d'utilisation. Delphine Longuet. delphine.longuet@lri.fr Polytech Paris-Sud Formation initiale 3 e année Spécialité Informatique Année 2014-2015 UML Cas d'utilisation Delphine Longuet delphine.longuet@lri.fr Processus de développement logiciel Analyse des besoins

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

PLAN CONDUITE DE PROJET

PLAN CONDUITE DE PROJET PLAN CONDUITE DE PROJET Ce guide complète le cours, il donne une marche à suivre qui peut être adaptée si vous choisissez une méthode particulière ETUDE PREALABLE ANALYSE FONCTIONNELLE ANALYSE DETAILLEE

Plus en détail

Chapitre n 3 : Présentation des méthodes agiles et Scrum

Chapitre n 3 : Présentation des méthodes agiles et Scrum Chapitre n 3 : Présentation des méthodes agiles et Scrum I. Généralités sur les méthodes agiles I-1. Définition Les méthodes agiles sont des méthodologies essentiellement dédiées à la gestion de projets

Plus en détail

REFERENTIEL NORMATIF du CNES

REFERENTIEL NORMATIF du CNES REFERENTIEL NORMATIF du CNES Référence : Méthode et Procédure SPECIFICATION TECHNIQUE DE BESOIN APPROBATION Président du CDN ; date et nom : Page i.1 PAGE D'ANALYSE DOCUMENTAIRE TITRE : MOTS CLES : STB

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

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

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

Plateforme de capture et d analyse de sites Web AspirWeb

Plateforme de capture et d analyse de sites Web AspirWeb Projet Java ESIAL 2A 2009-2010 Plateforme de capture et d analyse de sites Web AspirWeb 1. Contexte Ce projet de deuxième année permet d approfondir par la pratique les méthodes et techniques acquises

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

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

Développement itératif, évolutif et agile

Développement itératif, évolutif et agile Document Développement itératif, évolutif et agile Auteur Nicoleta SERGI Version 1.0 Date de sortie 23/11/2007 1. Processus Unifié Développement itératif, évolutif et agile Contrairement au cycle de vie

Plus en détail

Technologie Web. Conception de sites Web. Alexandre Pauchet. INSA Rouen - Département ASI. INSA - ASI TechnoWeb : Rappels UML 1/21

Technologie Web. Conception de sites Web. Alexandre Pauchet. INSA Rouen - Département ASI. INSA - ASI TechnoWeb : Rappels UML 1/21 INSA - ASI TechnoWeb : Rappels UML 1/21 Technologie Web Conception de sites Web Alexandre Pauchet INSA Rouen - Département ASI BO.B.RC.18, pauchet@insa-rouen.fr INSA - ASI TechnoWeb : Rappels UML 2/21

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

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

LES COURS ONLINE. ar des étudiants our des étudiants. Olden Fabre, Cynthia Thimon, Jakub Kaluza, Jean Desravines, Oliver Hamm

LES COURS ONLINE. ar des étudiants our des étudiants. Olden Fabre, Cynthia Thimon, Jakub Kaluza, Jean Desravines, Oliver Hamm LES COURS ONLINE P ar des étudiants our des étudiants Olden Fabre, Cynthia Thimon, Jakub Kaluza, Jean Desravines, Oliver Hamm C AHIER DES CHARGES I - Préface...4 II - Introduction...5 III - Glossaire...6

Plus en détail

DEMARCHE OU PROCESSUS LOGICIEL

DEMARCHE OU PROCESSUS LOGICIEL DEMARCHE OU PROCESSUS LOGICIEL PROCESSUS LOGICIEL Définition Un processus définit une séquence d étapes, en partie ordonnées, qui concourent à l obtention d un système logiciel ou à l évolution d un système

Plus en détail

Projet informatique «Voyageur de commerce» Résolution approchée par algorithme génétique du problème du voyageur de commerce

Projet informatique «Voyageur de commerce» Résolution approchée par algorithme génétique du problème du voyageur de commerce Année 2007-2008 Projet informatique «Voyageur de commerce» Résolution approchée par algorithme génétique du problème du voyageur de commerce B. Monsuez Projet informatique «Voyageur de commerce» Résolution

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

Etabli le : 19.12.14 Par : Hervé De Nicola Remplace la version du :

Etabli le : 19.12.14 Par : Hervé De Nicola Remplace la version du : CAHIER DES CHARGES 1. Actualisation Etabli le : 19.12.14 Par : Hervé De Nicola Remplace la version du : Motif d actualisation : Internalisation ressources 2. Identification du poste Département : INFRASTRUCTURES

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

Tobii Communicator 4. Guide de démarrage

Tobii Communicator 4. Guide de démarrage Tobii Communicator 4 Guide de démarrage BIENVENUE DANS TOBII COMMUNICATOR 4 Tobii Communicator 4 permet aux personnes souffrant de handicaps physiques ou de communication d'utiliser un ordinateur ou un

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

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

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

PROJET KAS-STORE PRESENTATION DU PROJET. KS-PRES Version 1.0. 08/09/2009 - Validé. KS-PRES - Version 1.0-08/09/2009 Validé Page 1 / 8

PROJET KAS-STORE PRESENTATION DU PROJET. KS-PRES Version 1.0. 08/09/2009 - Validé. KS-PRES - Version 1.0-08/09/2009 Validé Page 1 / 8 KS-PRES - Version 1.0-08/09/2009 Validé Page 1 / 8 PROJET KAS-STORE PRESENTATION DU PROJET KS-PRES Version 1.0 08/09/2009 - Validé Destinataire(s) Emetteur(s) Auteur(s) Vérificateur(s) Approbateur(s) Tout

Plus en détail

Gé nié Logiciél Livré Blanc

Gé nié Logiciél Livré Blanc Gé nié Logiciél Livré Blanc Version 0.2 26 Octobre 2011 Xavier Blanc Xavier.Blanc@labri.fr Partie I : Les Bases Sans donner des définitions trop rigoureuses, il faut bien commencer ce livre par énoncer

Plus en détail

Modélisation objet Le langage UML

Modélisation objet Le langage UML Modélisation objet Le langage UML Brahim HAMID La base de contrôle Robot Zone à explorer brahim.hamid@irit.fr brahim.hamid@univ-tlse2.fr http://mass-cara.univ-tlse2.fr/~brahimou/ens/uml 1 Les méthodes

Plus en détail

Présentation de la Gestion des Exigences (REQM) SopraGroup / Direction de la Transformation et de la Performance : Qualité, Méthode & Outils

Présentation de la Gestion des Exigences (REQM) SopraGroup / Direction de la Transformation et de la Performance : Qualité, Méthode & Outils emedia Présentation de la Gestion des Exigences (REQM) SopraGroup / Direction de la Transformation et de la Performance : Qualité, Méthode & Outils Unissons nos Talents T A L E N T E D T O G E T H E R

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

Cours de Génie Logiciel. David Janiszek. Le projet. En résumé. Troisième partie III. Eléments de gestion de projet

Cours de Génie Logiciel. David Janiszek. Le projet. En résumé. Troisième partie III. Eléments de gestion de projet Troisième partie III Eléments de gestion de projet Un projet informatique est l ensemble des activités et des actions à entreprendre pour répondre au besoin d informatisation d un ensemble de tâches dans

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

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

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

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

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

COMMENT DÉFINIR L ORIENTÉ OBJET

COMMENT DÉFINIR L ORIENTÉ OBJET COMMENT DÉFINIR L ORIENTÉ OBJET De manière superficielle, le terme «orienté objet», signifie que l on organise le logiciel comme une collection d objets dissociés comprenant à la fois une structure de

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

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. Technique d analyse de la demande

2. Technique d analyse de la demande 1. Recevoir et analyser une requête du client 2. Sommaire 1.... Introduction 2.... Technique d analyse de la demande 2.1.... Classification 2.2.... Test 2.3.... Transmission 2.4.... Rapport 1. Introduction

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

Fiche de lecture de PFE Guillaume HEMMERTER

Fiche de lecture de PFE Guillaume HEMMERTER 1. INTRODUCTION Les maîtres d ouvrage ou propriétaires de patrimoine immobilier qui s engagent dans la construction ou la rénovation d installations climatiques veulent avoir la certitude d obtenir le

Plus en détail

Génie logiciel avec UML. Notions sur le langage UML adapté pour les cours du programme Techniques de l informatique

Génie logiciel avec UML. Notions sur le langage UML adapté pour les cours du programme Techniques de l informatique Génie logiciel avec UML Notions sur le langage UML adapté pour les cours du programme Techniques de l informatique Claude Boutet Session hiver 2008 Modélisation de systèmes Table des matières TABLE DES

Plus en détail

Module SIN21 Pre sentation, analyse, prise en main

Module SIN21 Pre sentation, analyse, prise en main Module SIN21 Pre sentation, analyse, prise en main Temps : 3h Objectifs : Prendre connaissance du système. Lire les diagrammes UML et comprendre le fonctionnement du système. Mettre en place une maquette

Plus en détail

Les évolutions des méthodes de développement de logiciels. Depuis Merise de l'eau est passée sous les ponts

Les évolutions des méthodes de développement de logiciels. Depuis Merise de l'eau est passée sous les ponts Les évolutions des méthodes de développement de logiciels Depuis Merise de l'eau est passée sous les ponts Programmation Orientée Objets Encapsulation des données et des traitements Polymorphisme Modularité

Plus en détail

Documentation de l'application de gestion de courrier évolutive (G.E.D.) pour la Mairie de Voreppe

Documentation de l'application de gestion de courrier évolutive (G.E.D.) pour la Mairie de Voreppe Documentation de l'application de gestion de courrier évolutive (G.E.D.) pour la Mairie de Voreppe Tony Galmiche le 28 février 2011 (modifiée alb) Sommaire 1 - Accès au portail de l'application GED...3

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

Signature et chiffrement de messages

Signature et chiffrement de messages 1 sur 5 Signature et chiffrement de messages Dans cette section : À propos des signatures numériques et du chiffrement Obtenir des certificats d'autres personnes Configurer les réglages de sécurité Signer

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

C1 S informer. C1.1 Rechercher, Exploiter des documents

C1 S informer. C1.1 Rechercher, Exploiter des documents C1 S informer C1.1 Rechercher, Exploiter des documents Une commande Un besoin exprimé Expliciter le besoin*. Le service rendu, les utilisateurs, les conditions d'utilisation sont listés. Les performances

Plus en détail

Créer le modèle multidimensionnel

Créer le modèle multidimensionnel 231 Chapitre 6 Créer le modèle multidimensionnel 1. Présentation de SSAS multidimensionnel Créer le modèle multidimensionnel SSAS (SQL Server Analysis Services) multidimensionnel est un serveur de bases

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

Filtrage, Routage et Segmentation réseau Travaux pratiques

Filtrage, Routage et Segmentation réseau Travaux pratiques Filtrage, Routage et Segmentation réseau Travaux pratiques Le but est de faire l'étude, le test par simulateur et la réalisation d'une maquette complète d'infrastructure réseau routé et filtrant avec :

Plus en détail

Introduction à l'analyse et à la modélisation des processus. Eric Papet Co-fondateur SSII DEV1.0 Architecte Logiciel & Sécurité Lead Auditor 27001

Introduction à l'analyse et à la modélisation des processus. Eric Papet Co-fondateur SSII DEV1.0 Architecte Logiciel & Sécurité Lead Auditor 27001 Introduction à l'analyse et à la modélisation des processus Eric Papet Co-fondateur SSII DEV1.0 Architecte Logiciel & Sécurité Lead Auditor 27001 Les composants d'une méthode d'analyse La conception d'un

Plus en détail

Aide à la prise en charge / PEC+ Utilisation dans les logiciels Mélusine et Mélodie

Aide à la prise en charge / PEC+ Utilisation dans les logiciels Mélusine et Mélodie Aide à la prise en charge / PEC+ Utilisation dans les logiciels Mélusine et Mélodie Mélusine et Mélodie version 2014.00 Date : 16/05/2014 Table des matières. Table des matières.... 2 1 - Introduction...

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

Use Cases. Introduction

Use Cases. Introduction Use Cases Introduction Avant d aborder la définition et la conception des UC il est bon de positionner le concept du UC au sein du processus de développement. Le Processus de développement utilisé ici

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

PHASE SOUS-PHASE MOA MOE POINTS A TRAITER. besoins. charges. I.A.2 Échéances. I.A.3 Utilisateurs. I.A.4 Besoin fonctionnels. I.A.5 Évolutions à venir

PHASE SOUS-PHASE MOA MOE POINTS A TRAITER. besoins. charges. I.A.2 Échéances. I.A.3 Utilisateurs. I.A.4 Besoin fonctionnels. I.A.5 Évolutions à venir PHASE SOUS-PHASE MOA MOE POINTS A TRAITER I. La définition des I.A. L'expression des besoins Rédige (spécifie les besoins). Consulte / utilise pour rédiger le cahier des I.A.1 Positionnement stratégique

Plus en détail

JXDVDTek - UNE DVDTHEQUE EN JAVA ET XML

JXDVDTek - UNE DVDTHEQUE EN JAVA ET XML BALLOTE Nadia FRIULI Valerio GILARDI Mathieu IUT de Nice Licence Professionnelle des Métiers de l Informatique RAPPORT DU PROJET : JXDVDTek - UNE DVDTHEQUE EN JAVA ET XML Encadré par : M. CRESCENZO Pierre

Plus en détail

Méthode de tests MODE D EMPLOI POINTS IMPORTANTS

Méthode de tests MODE D EMPLOI POINTS IMPORTANTS Méthode de tests MODE D EMPLOI Cette première partie est destinée à ceux qui débutent en tests et permet une approche progressive et simple de la méthodologie des tests. L introduction vous aura permis

Plus en détail

SOFT AVOCAT Guide d utilisation

SOFT AVOCAT Guide d utilisation SOFT AVOCAT Guide d utilisation 1 SOFT AVOCAT est un logiciel de gestion automatisée des dossiers des cabinets d avocats qui facilite le suivi de leurs traitements à travers ses différentes composantes.

Plus en détail

Gestion de stock facturation : openstock 1.02 juin 2006

Gestion de stock facturation : openstock 1.02 juin 2006 Introduction Gestion de stock facturation : openstock 1.02 juin 2006 Le rapport de stage de Laurent POUCHOULOU décrivant son travail sur la période d Avril à Juin 2006 a été transformé en documentation

Plus en détail

Projets de Diplôme Bachelor (PDB) HEIG-VD

Projets de Diplôme Bachelor (PDB) HEIG-VD Projets de Diplôme Bachelor (PDB) HEIG-VD Kick-off Février 2011, v 1.6 christian.buchs@heig-vd.ch 1 Contenu 1. Gestion de projet 2. Bilans hebdomadaires 3. Le rapport 4. Activités de test 5. Évaluation

Plus en détail

L exemple d un serveur Proxy sous Windows NT 4 SERVER MICROSOFT PROXY SERVER 2 Installation et configuration Auteur : Eliane Bouillaux SERIA5

L exemple d un serveur Proxy sous Windows NT 4 SERVER MICROSOFT PROXY SERVER 2 Installation et configuration Auteur : Eliane Bouillaux SERIA5 L exemple d un serveur Proxy sous Windows NT 4 SERVER MICROSOFT PROXY SERVER 2 Installation et configuration Auteur : Eliane Bouillaux SERIA5. Préparation à l installation de MS Proxy server Ce logiciel

Plus en détail