Master 2 GLRE Master 2 IT-SIGL Ingénierie des exigences : les phases amonts d'ingénierie système / logicielle. Partie 1

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

Download "Master 2 GLRE Master 2 IT-SIGL Ingénierie des exigences : les phases amonts d'ingénierie système / logicielle. Partie 1"

Transcription

1 Master 2 GLRE Master 2 IT-SIGL Ingénierie des exigences : les phases amonts d'ingénierie système / logicielle Partie 1 Pierre-Jean Charrel UTM IRIT

2 Plan Partie 1 Généralités 1. Pourquoi des exigences? 2. Que sont les exigences et pourquoi une ingénierie des exigences? 3. Qualité des exigences Partie 2 Développement des exigences 1. Vision du produit et portée du projet 2. Elicitation 3. Vérification et validation 4. Documentation 5. Analyse et négociation Partie 3 Gestion des exigences 1. Contrôle du changement 2. Contrôle de version 3. Trace de l'état des exigences 4. Traçage des exigences M2 GLRE - IT-SIGL

3 Bibliographie Karl E. Wiegers, Software Requirements, Microsoft Press, 2nd ed., 2003 (1st ed ) Gerald Kotonya, Ian Sommerville, Requirements Engineering: Processes and Techniques, John Wiley & Sons, 1998 Mark Bergman, John Leslie King, Kalle Lyytinen Large-Scale Requirements Analysis Revisited: The need for Understanding the Political Ecology of Requirements Engineering, Requirements Engineering journal 7(3): , 2002 Marjo Kauppinen, Sari Kujala, Tapani Aaltio, Laura Lehtola Introducing Requirements Engineering: How to Make a Cultural Change Happen in Practice, Proceedings of IEEE Requirements Engineering conference, pp , 2002 Boehm, B.. A spiral model for software development and enhancement. IEEE Computer, pages 61 72, 1988 Carson, R. S. Requirements completeness: A deterministic approach, Proc. 8th Annual International Symposium of the INCOSE, 1998 Glass, R. L. Facts and Fallacies of Software Engineering, Addison-Wesley, 2003 Jackson, M. Software Requirements and Specifications : a Lexicon of Practice, Principles and Prejudices. ACM Press / Addison-Wesley, 1995 Jackson, M. Seeing More of the World, IEEE Software 21(6): 83-85, 2004 Pohl, K. Process-Centered Requirements Engineering, Research Studies Press / Wiley, 1996 Preiss, O. and Wegmann, A. Stakeholder discovery and classification based on systems science principles, Proc. 2nd APQSC Asia-Pacific Conference on Quality Software, pp , IEEE, 2001 Sage, A. P. Systems Management for Information Technology and Software Engineering, John Wiley and Sons, 1995 Royce, W. Managing the development of large software systems. In Proc. IEEE Western Computer Conf., Los Alamitos, CA. IEEE Computer Society Press, 1970 Schwalbe, K. Information Technology Project Management, Course Technology; 3rd ed., 2003 M2 GLRE - IT-SIGL

4 Partie 1 Généralités 1. Pourquoi des exigences?

5 1. Pourquoi des exigences? Petit malentendu entre amis Allô Bill? Ici Marie des RH. On a un problème avec ton système de gestion de personnel. Le fils d'une employée vient de changer de nom, et on ne peut pas le dire au système. Dis plutôt que c'est sa fille et qu'elle s'est mariée! Non, c'est son fils et il est adopté. Il prend maintenant le nom de ses parents adoptifs. C'est légal, tu sais! Je savais pas qu'on pouvait changer comme ça. C'est pour ça qu'on ne peut atteindre le menu "changer de nom" que via l'écran "changement de situation maritale" Bon, tu peux corriger le bug pour vendredi? Autrement, les allocations familiales et la Sécu vont lui causer des ennuis C'es pas un bug! Tu ne m'as jamais dit que tu avais besoin de ça Ouais, bon! c'est le genre de truc qui me fait haïr l'informatique! M2 GLRE - IT-SIGL

6 Idée de base : ajouter une étape au processus de développement Test de satisfaction alpha, beta, conformité Attentes des utilisateurs du système Conception validation de la conceptionc Test unitaire et d'intégration Implémentation M2 GLRE - IT-SIGL

7 Idée de base : ajouter une étape au processus de développement Test de satisfaction alpha, beta, conformité Attentes des Acteurs du système Test du système Exigences Conception Validation des exigences validation de la conceptionc Test unitaire et d'intégration Implémentation M2 GLRE - IT-SIGL

8 Ajouter une étape : Avantages et inconvénients Avantages Pouvoir commencer le contrôle qualité plus tôt Augmenter les niveaux de contrôle Résoudre vite des conflits d'intérêt entre acteurs Amélioration : conformité aux attentes des acteurs efficacité (coût, délai, ressources humaines) du développement du système Inconvénient une étape de plus des bugs possibles en plus M2 GLRE - IT-SIGL

9 Quelques définitions (1) Acteur (stakeholder) personne, groupe, organisation impliqué dans la conception et le développement du système affecté par le système ou affectant le système Attente besoin, vœu, réclamation de l'acteur, même inconscient Exigence Système ensemble d'attentes explicité et négocié entre les acteurs M2 GLRE - IT-SIGL

10 Quelques définitions (2) Exigence IEEE 1990 Standard Glossary of Software Engineering 2. Condition ou moyen dont un utilisateur a besoin pour résoudre un problème ou atteindre un but 3. Condition ou moyen à acquérir par un composant du système pour satisfaire un contrat, une spécification ou tout document formel imposé 4. Une représentation documentée d'une condition ou d'un moyen relevant du point 1. ou du point 2. Ingénierie des exigences (IE) Requirements Engineering (RE) Domaine des activités de développement gestion d'exigences systèmes tout au long du processus de développement de la vie du système M2 GLRE - IT-SIGL

11 Erreurs d'exigences ,1 Exigences 0,2 Conception 0,5 les plus chères à corriger dans les phases de production Codage 1 Maintenance 20 Tests d'acceptation 5 Test unitaire 2 les moins chères à corriger dans les phases de développement M2 GLRE - IT-SIGL

12 Erreurs d'exigences Source la plus fréquente de problèmes Autres Interface 7% 6% Données Environnement 6% 5% Exigences 41% Humaine 5% Documentation 2% Conception 28% M2 GLRE - IT-SIGL

13 Taux de succès des projets (2004) Standish group CHAOS projets 58% réponses US 27% européennes 15% reste du monde Projets abandonnés 18 Projets réussis 29 Projets "handicapés" 53 45% grandes sociétés 35% moyennes 20% petites Projets "handicapés" challenged - en retard - en dépassement de budget - avec moins de fonctionnalités que prévu M2 GLRE - IT-SIGL

14 Projets "handicapés" (en 2000) Sous-estimation du temps % En moyenne temps : 86% de plus que prévu coût : 63% de plus que prévu moyenne 86% Dépassement du budget % moyenne 63% M2 GLRE - IT-SIGL

15 Projets "handicapés" (en 2000) Fonctionnalités planifiées à l'origine % moyenne 75% En moyenne fonctionnalités : 75% M2 GLRE - IT-SIGL

16 Propriétés des projets abandonnés, en 2000 Pourcents 14 13,1 12, ,6 9,9 10 9,3 8,7 8,1 7,5 8 6,3 6 4, Exigences incomplètes Manque de ressources Manque d'implication utilisateurs Attentes irréaliste Manque de support Modif exigences et Spéc Défaut de palnification Produit inutile Défaut d'encadrement "illétrisme" technologique Autre 9,9 M2 GLRE - IT-SIGL

17 Pourcents Implication des utilisateurs 15,9 13,9 Encadrement présent Exigences clairement énoncées Facteurs de succès 13 Planning juste 9,6 Attentes réalistes 8,2 7,7 7,2 Im plicati Personnel compétent Etapes de projet courtes 5,3 2,9 2,4 Ownership Objectif clair Equipe impliquée et "travailleurse" 13,9 Autre M2 GLRE - IT-SIGL

18 Risques d'un processus d'exigences inadéquat (Wiegers, 2003) implication insuffisante des utilisateurs produit inacceptable ignorer certains utilisateurs clients insatisfaits spécifications minimales passer à côté d'exigences clés exigences incomplètement définies problèmes de planification du projet exigences ambiguës gaspillage de temps "gold-plated" propriétés inutiles M2 GLRE - IT-SIGL

19 Profits essentiels d'un bon processus d'exigences qualités du système et satisfaction du client améliorées mise en conformité facile avec les standards et les règles réduction des coûts et délais contrôle accru sur des projets complexes meilleure communication d'équipe M2 GLRE - IT-SIGL

20 5 obstacles / réticences à l'ie (des développeurs)(1) 1. "Cela ne vaut pas la peine de découvrir directement les exigences des utilisateurs" Arguments Cela fait longtemps qu'on développe ce genre de produit et on connaît les besoins Nos développeurs utilisent aussi nos propres produits donc nous pouvons jouer le rôle d'utilisateurs Nous développons un nouveau produit donc les utilisateurs ne peuvent pas avoir d'exigences dessus Réponses Mieux les utilisateurs sont compris, plus les produits sont utiles Les utilisateurs sont les experts de leur activité, ils sont donc la source première d'exigences Les utilisateurs d'un nouveau produit savent rarement dire ce qu'ils veulent, mais sauront vite voir ce qu'ils ne veulent pas M2 GLRE - IT-SIGL

21 5 obstacles / réticences à l'ie (des développeurs) (2) 2. "Excès de confiance en soi mais peu de connaissance du domaine" M2 GLRE - IT-SIGL

22 5 obstacles / réticences à l'ie (des développeurs) (3) 3. "C'est difficile de découvrir directement les exigences des utilisateurs" Arguments "Ils" ne savent pas dire ce qu'ils veulent Il y a trop d'utilisateurs pour qu'on puisse les interroger tous Réponses Techniques d'élicitation (interviews, observations ) faciles à utiliser par les développeurs obtenir une représentation des besoins des utilisateurs sans leur demander de les expliciter C'est mieux d'interroger un petit groupe d'utilisateurs que de ne rien faire M2 GLRE - IT-SIGL

23 5 obstacles / réticences à l'ie (des développeurs) (4) 4. "C'est risqué de découvrir les exigences directement auprès des utilisateurs" Arguments On ne peut pas montrer à nos clients qu'on ne connaît rien à leur domaine Les développeurs peuvent gâcher les relations avec les clients en posant des questions stupides Réponses Des visites bien préparées améliorer l'image d'une entreprise Exigence découverte trop tard, conséquences pires M2 GLRE - IT-SIGL

24 5 obstacles / réticences à l'ie (des développeurs) (5) 5. "Cela ne vaut pas la peine d'expliciter les exigences des utilisateurs" Arguments Nos clients veulent les docs techniques du logiciel, pas des docs qui racontent ce qu'ils savent on n'a pas le temps Réponses Les exigences documentent un accord sur le système, pas seulement ce que les utilisateurs ont en tête Exigences utilisateurs bien documentées utiles à beaucoup d'équipes : concepteurs, testeurs, rédacteurs de manuels, marketing, gestion Documenter les exigences en début de développement Gain de temps Diminution des reprises en cours de projet M2 GLRE - IT-SIGL

25 Le client et un 6ème obstacle 6. "Je suis trop occupé pour perdre mon temps avec les exigences" Se rappeler des projets abandonnés et "handicapés" des coûts des changements dans les phases aval M2 GLRE - IT-SIGL

26 Partie 1 Généralités 1. Pourquoi des exigences? 2. Que sont les exigences et pourquoi une ingénierie des exigences?

27 2. Que sont les exigences? Acteur (stakeholder) personne, groupe, organisation impliquée dans la conception du système Attente affectée par le système ou affectant le système besoin, vœu, réclamation de l'acteur, même inconscient Exigence Système ensemble d'attentes explicité et négocié entre les acteurs Comment distinguer exigences et conception? M2 GLRE - IT-SIGL

28 Que sont les exigences? Vue classique les exigences définissent le problème la conception et le développement définissent la solution simpliste! En pratique, les systèmes ne sont pas développés comme un problème pour lequel il faut une solution mais sont développés pour répondre à une sollicitation "une solution qui cherche un problème" M2 GLRE - IT-SIGL

29 Le Système et son Environnement Distinguer entre Connaissances du domaine Exigences externes Exigences internes Information de conception Exemple Un système informatique qui vérifie l'orthographe d'un texte M2 GLRE - IT-SIGL

30 Le Système et son Environnement Connaissances du domaine (Domain knowledge) phénomènes d'environnements indépendants du système Ex 1 : vérifier l'orthographe d'un texte à la main prend 5 pages à l'heure Ex 2 : les nombres de mots et de citations du Grand Robert sont respectivement de et Exigences externes (Outer requirements ) effets souhaitables du système sur l'environnement Ex : l'orthographe d'un texte doit être vérifiée vite et bien M2 GLRE - IT-SIGL

31 Le Système et son Environnement Exigences internes (Inner requirements) phénomènes partagés par le système et l'environnement Ex 1 : un système informatisé doit être développé pour vérifier l'orthographe d'un document électronique Ex 2 : si on trouve un mot en dehors du dictionnaire, l'utilisateur sera invité à choisir parmi plusieurs mots corrects Information de conception (Design information) structure interne et comportement interne du système Ex : l'algorithme de vérification orthographique M2 GLRE - IT-SIGL

32 Le Système et son Environnement Phénomènes de l'environnement indépendants du système Analyse du domaine, règles de gestion Phénomènes de l'environnement à effet sur le système Exigences externes Phénomènes partagés, interface Système / Environnement Exigences internes Exigences Phénomènes du système Conception d'après Jackson 1995, 2004 M2 GLRE - IT-SIGL

33 Que sont les exigences? Description de la frontière et des effets Où est la frontière entre système et environnement? Exemple le client : "Utilisez Oracle, car nous avons une licence et un savoir-faire" Exigence ou conséquence de conception? C'est une exigence. Le type de SGBD n'est pas du côté "utilisateur" de la frontière. Mais les utilisateurs ne sont pas les seuls acteurs. Le type de SGBD est du côté "équipe de maintenance" (savoir-faire), et du côté "client" (licence) de la frontière Etablir une classification des exigences M2 GLRE - IT-SIGL

34 Exigences fonctionnelles et non fonctionnelles Exigences fonctionnelles EF : ce que le système devra faire Exigences non fonctionnelles ENF - attributs de qualité comment il devra le faire et à quel niveau il devra respecter les caractéristiques générales. M2 GLRE - IT-SIGL

35 Exigences non fonctionnelles Souvent oubliées, les acteurs se concentrent sur les fonctionnalités qu'ils attendent La perception de bon ou mauvais fonctionnement d'un systèmes se traduit par la satisfaction ou non d'exigences non fonctionnelles Traitées classiquement dans la 1ère phase de conception, dite phase de conception d'architecture Ex : décision d'une solution centralisée ou distribuée Le coût du changement dû à une ENF non satisfaite peut être énorme voire infini! M2 GLRE - IT-SIGL

36 4 ENF Effectivité (effectivity): exactitude et complétude de la réussite du système à atteindre ses objectifs Mesurée en % Efficacité (efficiency): relation entre l'effectivité et les ressources mises en œuvre pour l'atteindre; bon usage de : processeur, mémoire, bande passante Mesurée en %, MO, MO/s, Consommation de ressources (resource consumption): Mesure absolue Performances (performance) : rapidité d'exécution des fonctions. Mesurées comme un temps de réponse, un débit, une capacité M2 GLRE - IT-SIGL

37 5 ENF de plus Disponibilité (availability): prêt pour rendre un service correct, Mesuré en % de temps où le système est opérationnel Fiabilité (reliability): continuité de service Mesuré en temps moyen entre 2 pannes (MTTF Mean Time To Failure) Sûreté (safety) : absence de conséquences catastrophiques pour les utilisateurs et l'environnement, i.e. fiabilité vis-à-vis d'une liste de pannes catastrophiques Mesuré en MTTF Intégrité (integrity) : absence d'altération dans le système Difficilement mesurable probabilité? Confidentialité (confidentiality) : absence de divulgation non autorisée d'information Difficilement mesurable probabilité? M2 GLRE - IT-SIGL

38 3 de plus Confiance (dependability) : aptitude à rendre un service dont la sécurité peut être justifiée Robustesse tolérance aux pannes (robustness fault tolerance) : aptitude à maintenir sa "confiance" en présence de données incorrectes, de défauts de composants logiciels et matériels connexes, ou de conditions opératoires inattendues "tankness" (Wiegers 2003) Sécurité (security) : aptitude à éviter les utilisations ou les modifications non autorisées M2 GLRE - IT-SIGL

39 et 4 dernières Utilisabilité (utilisability): étendue des usages possibles du système avec garantie d'effectivité, d'efficacité, et de satisfaction Maintenabilité (maintenability): aptitude à corriger des défauts ou faire des modifications, avec effectivité et efficacité Flexibilité (flexibility) : aptitude à intégrer de nouvelles caractéristiques Portabilité (portability) : aptitude à faire migrer le logiciel d'un environnement M2 opérationnel GLRE - IT-SIGL à un autre 39

40 Des décisions de conception différentes peuvent avoir un effet similaire sur une ENF Compromis Une décision de conception qui améliore une ENF peut avoir un effet négatif sur une autre Ex : Portabilité et efficacité M2 GLRE - IT-SIGL

41 Dépendances entre ENF Disponibilité Fiabilité Confiance Sûreté Confidentialité Intégrité Maintenabilité Sécurité M2 GLRE - IT-SIGL

42 d'après Wiegers, 2003 M2 GLRE - IT-SIGL

43 7 Problèmes liés aux ENF Certaines ENF décrivent les performances du système, Certaines ENF décrivent un système englobant (suprasystème) utilisabilité = système + utilisateur maintenabilité = système + équipe de maintenance sécurité = système + une partie de son environnement La plupart des ENF difficiles à mesurer en pratique Certaines ENF difficiles à quantifier Beaucoup d'enf sont subjectives Pour assurer une ENF, le système doit souvent implémenter une exigence fonctionnalité Ex : ENF de confidentialité protection par un mot de passe attaché à des données sensibles. L'IE devient un processus itératif, et des exigences de niveau différent se mélangent dans un même document. M2 GLRE - IT-SIGL

44 Exigences de projet 3 ENF se rapportent au processus de développement et non au système le Temps le Coût la nécessité de développer des produits connexes, p. ex. un manuel d'utilisation M2 GLRE - IT-SIGL

45 Catégories d'informations liées aux exigences (1) Exigences "métier" Business requirements : objectifs de haut niveau Propriétés Features : ébauches de solution aux exigences "métier", élaborées plus tard en exigences spécifiques. Exigences utilisateur User requirements : activités que les utilisateurs devront être capables d'accomplir dans le futur système Exigences fonctionnelles Functional requirements : fonctionnalités du système qui permettront aux utilisateurs d'accomplir leurs activités, satisfaisant les exigences "métier" M2 GLRE - IT-SIGL

46 Catégories d'informations liées aux exigences (2) Exigences non fonctionnelles Non functional requirements quality attributes : améliorent la description des fonctionnalités du produit en décrivant ses caractéristiques selon des dimensions importantes pour les acteurs Contraintes Constraints : restrictions imposées aux concepteurs pour l'implémentation du système Interfaces externes External interfaces : interface système - environnement Règles de gestion Business rules : politique de l'entreprise, règles de gouvernance, standards industriels, pratiques comptables, algorithmes de calcul connaissance du domaine, pas des exigences Exigences système System requirements : pour les logiciels, exigences pour le système informatisé Exigences de projet Project requirements : contraintes sur le processus de développement, p.ex. budget, planning M2 GLRE - IT-SIGL

47 Catégories d'informations liées aux exigences (3) Fonctionnel Non fonctionnel Exigences métier Propriétés Document vision et portée Règles de gestion Exigences utilisateur ENF Cas d'utilisations, Scénarios Interfaces externes Exigences système Exigences fonctionnelles Contraintes Exigences projet Document de Spécification d'exigences d'après Wiegers 1999, 2OO3 1 25/09/08 13h30-15h30 Fin M2 GLRE - IT-SIGL

48 Exigences dans les modèles de génie logiciel : Modèle en cascade d'après Royce 1970 M2 GLRE - IT-SIGL

49 Cycle en V temps détails M2 GLRE - IT-SIGL

50 Modèle en spirale d'après Boehm (1988) M2 GLRE - IT-SIGL

51 Modèle par prototypage (incrémental) d'après Huet (2006) M2 GLRE - IT-SIGL

52 Activité \ Phase Processus unifié (RUP) Inception Elaboration Construction Transition Modélisation métier Exigences Analyse-conception Quantités de travail Implémentation Test Déploiement Gestion du changement et de configuration Gestion de projet Environnement Préliminaire Elab 1 Elab 2 Const 1Const 2 Const 3 Tr 1 Tr 2 Itérations Exigences = capture ce que le système devrait faire (élicitation) Analyse-conception = raffinement et structuration des exigences M2 GLRE - IT-SIGL

53 Activités de base en Ingénierie des exigences Développement des exigences 1. Elicitation 2. Analyse 3. Négociation 4. Documentation 5. Vérification et validation Gestion des exigences 1. Contrôle du changement 2. Contrôle de version 3. Historisation des états 4. Traçabilité M2 GLRE - IT-SIGL

54 Que doit-on signer? Geler des exigences irréaliste et imprudent, les changements sont inévitables Un document d'exigences signé par un client concrétise un accord ne signifie pas que les exigences ont été finalisées Toute signature d'un document d'exigences devrait être accompagné d'un texte du genre : "J'accepte que ce document représente nos exigences de projet aujourd'hui. J'accepte d'effectuer les futurs changements selon le processus défini de changement de projet. Je réalise que les changements approuvés devront requérir une renégociation des accords de coûts, ressources et plannings pour ce projet". (Wiegers, 2003) M2 GLRE - IT-SIGL

55 Frontière entre définition et gestion des exigences Exigences Marketing, Client, Direction Analyse Documentation Négociation Validation Exigences de base Développement Gestion Exigences de base courantes Exigences de base révisées Marketing Client Direction Changement (exigences) Processus de changement des exigences Changement (projet) Environnement de projet M2 GLRE - IT-SIGL

56 Développement des exigences Etablit un accord entre tous les acteurs (y compris l'équipe de développement) sur les exigences système Induit Elicitation : processus d'identification des exigences à partir de : interviews, réunions, séminaires, analyse de documents, analyse de tâches, workflow, etc. Validation & vérification : processus de test de non contradiction entre exigences entre elles, exigences et attentes des acteurs Analyse : processus d'évaluation du coût et de la valeur des exigences, d'identification de dépendances entre exigences, etc. Négociation : processus de résolution de conflits entre exigences, choix et priorités Documentation (spécification) : processus de documentation sous une forme partageable et gérable M2 GLRE - IT-SIGL

57 Gestion des exigences Maintient l'accord Induit Contrôle du changement : gestion des changements par rapport à l'accord initial, contrôlée, évaluant l'impact probable de chaque changement avant approbation, incorporant les changements approuvés Contrôle de version : gestion des versions de documentation et des révisions d'exigences Contrôle de l'état des exigences : définit un ensemble de valeurs d'état pour chaque exigence, et contrôle de ces états pendant le projet Traçage des exigences : gestion des dépendances entre exigences, et trace des traductions des exigences depuis leur origine jusqu'à la conception, codage, jeu de test M2 GLRE - IT-SIGL

58 Processus de développement des exigences Kotonya, Somerville, 1998 M2 GLRE - IT-SIGL

59 Processus de développement des exigences Kotonya, Somerville, 1998 M2 GLRE - IT-SIGL

60 Processus de développement des exigences Wiegers, 2003 M2 GLRE - IT-SIGL

61 Processus de développement des exigences Pohl, 1996 M2 GLRE - IT-SIGL

62 Processus de développement des exigences Processus unifié Similarité entre : Ingénierie logicielle définition d'exigences conception implémentation Test Ingénierie des exigences élicitation analyse, négociation documentation validation M2 GLRE - IT-SIGL

63 Processus de développement des exigences Activités indépendantes Elicitation : spécification Négociation : accord Documentation : représentation Validation : toutes les dimensions Spécification complète convenable vue commune trace du processus Accord opaque vues personnelles Représentation informel semi-formel formel M2 GLRE - IT-SIGL

64 L'analyste des exigences Un rôle, pas un travail Requiert des compétences spécifiques savoir écouter savoir interviewer et poser des questions savoir organiser un travail en groupe savoir observer qualités relationnelles (modérateur ) en plus de compétences en analyse et organisations savoir "rédiger" savoir modéliser créativité Interface entre clients et développeurs M2 GLRE - IT-SIGL

65 Partie 1 Généralités 1. Pourquoi des exigences? 2. Que sont les exigences et pourquoi une ingénierie des exigences? 3. Qualité des exigences

66 3. Qualité des exigences L'IE tente de répondre aux 2 questions : quels sont les effets que les acteurs souhaitent avoir sur l'environnement? quel pourrait être le comportement du système qui permettrait d'obtenir ces effets sur l'environnement? L'IE tente d'élaborer de "bonnes" exigences, i.e. des exigences de "bonne qualité" Les bonnes exigences répondent aux questions 1 et 2 2 niveaux de qualité : qualités d'un système / logiciel ce qui fait qu'un système est "bon" spécifié par les "exigences système" qualités des exigences ce qui fait que les exigences sont "bonnes" = exigences sur les exigences M2 GLRE - IT-SIGL

67 3 Moyens pour la qualité Exemple 2. chercher s'il y a des cafards dans la soupe. S'il y en a, les retirer ou jeter le contenu de la marmite 3. laisser le couvercle sur la marmite le plus possible, pour minimiser les occasions de chute de cafards 4. nettoyer la cuisine moyen 1 : qualité réactive avec le contrôle qualité moyen 2 : qualité intégrée avec l'assurance qualité moyen 3 : qualité proactive avec la gestion de la qualité stratégique situation M2 GLRE - IT-SIGL

68 Moyens pour la qualité Dans l'histoire de l'ingénierie, 4 niveaux de qualité "inspection" (1940) : inspection de tous les produits, avec rejet ou réparation des défauts "statistique" ( ) : utiliser des mesures de performance sur des échantillons représentatifs Moyens réactifs, contrôle qualité, contrôle de production "opérationnel" ( ) : chaque étape de production est contrôlée, au moyen de mesures contrôlables; le produit n'est plus seul contrôlé Moyen intégré, assurance qualité, contrôle du processus de production "gestion de qualité stratégique" (1970 -) : toute l'organisation (structure, processus de production, culture) impliquée pour aboutir à l'amélioration de la qualité des produits Moyen proactif, gestion de la qualité, contrôle de l'environnement de production M2 GLRE - IT-SIGL

69 Moyens pour la qualité 3 moyens complémentaires Les 2 derniers = contrôles actifs de la qualité plus d'améliorations, TQM (Total Quality Management) = les 3 moyens rassemblés : Processus de contrôle de gestion total et intégré qui se préoccupe de tous les aspects liés à la qualité du système et des produits pendant toutes les phases du cycle de vie M2 GLRE - IT-SIGL

70 Moyens pour la qualité des exigences Contrôle qualité en IE : validation & vérification des exigences (contrôle du produit de l'ie) Assurance qualité en IE : utiliser de bonnes techniques et de bons outils pour éliciter, analyser, contrôler les changements (contrôle du processus d'ie) Gestion stratégique de la qualité en IE : éduquer les analystes, les développeurs, les clients, surmonter les croyances sur les exigences (contrôle de l'environnement d'ie, au-delà des processus) M2 GLRE - IT-SIGL

71 Gestion stratégique de la qualité en IE d'après Wiegers, 2003 Bonnes pratiques en IE = formation des analystes d'exigences tous les membres de l'équipe ayant un rôle d'analyste doivent être formés à l'ie des représentants des utilisateurs et des gestionnaires aux exigences logicielles (software requirements) les utilisateurs qui vont participer au développement devraient recevoir une formation de 2 jours à l'ie des développeurs aux concepts du domaine pour aider les développeurs à atteindre un niveau de compréhension minimal, organiser un séminaire sur les activités du client, sa terminologie, et les objectifs du produit à concevoir M2 GLRE - IT-SIGL

72 Qualité des exigences (1) Niveau de satisfaction des acteurs lorsque les exigences sont respectées par le système Difficile à évaluer avant que le système existe Différents acteurs ont des vues différentes, voire contradictoires, sur le système situation encore plus délicate On se focalise sur quelques aspects de la qualité des exigences : les facteurs de qualité M2 GLRE - IT-SIGL

73 Qualité des exigences (2) Les exigences ne doivent pas être mélangées avec d'autres types d'information. Un mélange n'est pas un défaut, mais peut déclencher des défauts. Séparer exigences et connaissance du domaine : séparer la description de la partie de l'environnement indépendante du logiciel de la partie sur laquelle il a un effet Séparer les exigences et la conception éviter de présenter comme exigences ce qui relève de la conception ou du développement étudier comme exigences tout ce qui traite des effets sur l'environnement, pour ne pas les traiter dans les phases de conception et développement M2 GLRE - IT-SIGL

74 Facteurs de qualité des exigences L'énoncé d'une exigence particulière doit être complet correct non ambigu faisable nécessaire priorisé vérifiable concis La spécification globale des exigences doit être complète cohérente traçable non redondante organisée conforme aux standards M2 GLRE - IT-SIGL

75 Pas d'ambiguïté Tous les lecteurs de l'expression d'une exigence doivent parvenir à une interprétation unique et cohérente. Ambiguïtés usage incontrôlé des quantificateurs "tous" et "chaque" Ex : toutes les lumières de chaque pièce doivent avoir un seul interrupteur chaque lumière doit avoir son interrupteur toutes les lumières de chaque pièce doivent partager le même interrupteur Ambiguïté interférence entre énoncés de plusieurs exigences M2 GLRE - IT-SIGL

76 Complétude Pour les énoncés individuels chaque exigence fonctionnelle doit décrire complètement la fonctionnalité à laquelle elle est associée Pour la spécification il ne doit manquer aucune exigence M2 GLRE - IT-SIGL

77 Correction - Nécessité Correction chaque exigence fonctionnelle doit décrire précisément la fonctionnalité qu'elle induit et doit correspondre aux intentions de l'acteur qui en est le détenteur Nécessité chaque exigence doit décrire une capacité dont les clients ont vraiment besoin ou qui est requise par souci de conformité à une norme ou un système extérieur. M2 GLRE - IT-SIGL

78 Cohérence Les exigences ne doivent pas entrer en conflit avec d'autres exigences de même type, ou avec des exigences de plus haut niveau, système ou utilisateur M2 GLRE - IT-SIGL

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

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

Processus d Informatisation

Processus d Informatisation Processus d Informatisation Cheminement de la naissance d un projet jusqu à son terme, deux grandes étapes : Recherche ou étude de faisabilité (en amont) L utilisateur a une idée (plus ou moins) floue

Plus en détail

Modèle d implémentation

Modèle d implémentation Modèle d implémentation Les packages UML: Unified modeling Language Leçon 5/6-9-16/10/2008 Les packages - Modèle d implémentation - Méthodologie (RUP) Un package ou sous-système est un regroupement logique

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

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

Conduite de projets SI. Les méthodes «Agiles» N QUAL/1995/3660e ORESYS

Conduite de projets SI. Les méthodes «Agiles» N QUAL/1995/3660e ORESYS Conduite de projets SI Les méthodes «Agiles» N QUAL/1995/3660e ORESYS Agilité : de quoi parle-t-on? Agilité de l entreprise Urbanisme Architectures SOA Agilité du SI ERP Plateformes applicatives agiles

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

Méthodes Agiles et gestion de projets

Méthodes Agiles et gestion de projets Méthodes Agiles et gestion de projets Eric LELEU Consultant Solutions Collaboratives Contact ericleleu@nordnet.fr Site Personnel http://home.nordnet.fr/~ericleleu Blog http://ericleleu.spaces.live.fr La

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

vendredi 8 février 2008 QUALITÉ DU LOGICIEL

vendredi 8 février 2008 QUALITÉ DU LOGICIEL QUALITÉ DU LOGICIEL La qualité du logiciel Qualité d'un logiciel? de manière informelle : respect des spécifications. Particularités des logiciels par rapport à des produits matériels : Un logiciel a de

Plus en détail

ISO 9001:2000. CHAPITRE par CHAPITRE

ISO 9001:2000. CHAPITRE par CHAPITRE ISO 9001:2000 PARTIE 2-3 CHAPITRE par CHAPITRE 9001:2000, domaine Satisfaction du client par la prévention des N.C. (ISO 9001:1994) Appliquer efficacement le système pour répondre aux besoins du client

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

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

Génie logiciel (Un aperçu)

Génie logiciel (Un aperçu) (Un aperçu) (sommerville 2010) Laurent Pérochon INRA URH 63122 St Genès Champanelle Laurent.perochon@clermont.inra.fr Ensemble d activités conduisant à la production d un logiciel Sur un échantillon de

Plus en détail

Examen intra LOG3000 Hiver 2014

Examen intra LOG3000 Hiver 2014 Examen intra LOG3000 Hiver 2014 Vendredi le 28 février 2014. Durée : 08h30 à 10h00 (total 1h30). Local : B-415. Total des points : 20. Pondération de l'examen dans la note finale : 35%. Sans documentation,

Plus en détail

En informatique et en particulier en génie logiciel, la qualité logicielle est une appréciation globale d'un logiciel, basée sur de nombreux

En informatique et en particulier en génie logiciel, la qualité logicielle est une appréciation globale d'un logiciel, basée sur de nombreux Introduction En informatique et en particulier en génie logiciel, la qualité logicielle est une appréciation globale d'un logiciel, basée sur de nombreux indicateurs 1. La complétude des fonctionnalités,

Plus en détail

Cours de Génie Logiciel

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

Plus en détail

IFT2255 - Génie logiciel. Processus de développement

IFT2255 - Génie logiciel. Processus de développement IFT2255 - Génie logiciel Processus de développement 1 Cycle de vie du logiciel 2 Activités de développement 3 Planification du projet Analyse et spécification Conception Implémentation Vérification Installation

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

-- Séance 12 -- Traçabilité des exigences et gestion du changement

-- Séance 12 -- Traçabilité des exigences et gestion du changement -- Séance 12 -- Traçabilité des exigences et gestion du changement o Objectifs: Comprendre l importance des documents de vision et delta-vision. Comprendre la notion de la traçabilité des exigences. Savoir

Plus en détail

ITIL V3-2011 Préparation à la certification ITIL Foundation V3 (2ième édition)

ITIL V3-2011 Préparation à la certification ITIL Foundation V3 (2ième édition) Chapitre 1 Introduction et généralités d'itil V3 A. Introduction 26 1. Le contexte 26 2. Des réponses à ce contexte 27 B. Les bonnes pratiques ITIL V3 28 1. Les bonnes pratiques 28 a. Introduction 28 b.

Plus en détail

IFT3902 : (Gestion de projet pour le) développement, (et la) maintenance des logiciels

IFT3902 : (Gestion de projet pour le) développement, (et la) maintenance des logiciels IFT3902 : (Gestion de projet pour le) développement, (et la) maintenance des logiciels Yann-Gaël Guéhéneuc Professeur adjoint guehene@iro.umontreal.ca, local 2345 Département d informatique et de recherche

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

Systèmes et réseaux d information et de communication

Systèmes et réseaux d information et de communication 233 DIRECTEUR DES SYSTÈMES ET RÉSEAUX D INFORMATION ET DE COMMUNICATION Code : SIC01A Responsable des systèmes et réseaux d information FPESIC01 Il conduit la mise en œuvre des orientations stratégiques

Plus en détail

Experience N 52. Les expériences d ERNI dans l univers du management, des processus et des technologies. Mars 2012

Experience N 52. Les expériences d ERNI dans l univers du management, des processus et des technologies. Mars 2012 Les expériences d ERNI dans l univers du management, des processus et des technologies Experience N 52 Mars 2012 MIGRATIONS Garder la maîtrise lors de migrations GARdER la maîtrise LORS de migrations Lors

Plus en détail

ITIL V3-2011 Préparation à la certification ITIL Foundation V3 (3ième édition)

ITIL V3-2011 Préparation à la certification ITIL Foundation V3 (3ième édition) Chapitre 1 Introduction et généralités d'itil V3 A. Introduction 26 1. Le contexte 26 2. Des réponses à ce contexte 27 B. Les bonnes pratiques ITIL V3 28 1. Les bonnes pratiques 28 a. Introduction 28 b.

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

1. Identifier et reconnaître le potentiel et les compétences de chaque employé(e).

1. Identifier et reconnaître le potentiel et les compétences de chaque employé(e). Grille d évaluation Identification de l employé(e) Nom : Prénom : Fonction : Date de l évaluation Objectifs de l évaluation 1. Identifier et reconnaître le potentiel et les compétences de chaque employé(e).

Plus en détail

PLAN DE COURS. Session 1: Présentation de l'étude de cas Microsoft Dynamics Sure Step

PLAN DE COURS. Session 1: Présentation de l'étude de cas Microsoft Dynamics Sure Step GERER un projet pour implémenter Dynamics CRM avec Sure Step Ref : 80278 Durée : 2 jours A propos de ce cours : Ce cours de 2 jours est un atelier de formation avancée centré sur les fonctionnalités de

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

LES ORIGINES D ITIL Origine gouvernementale britannique 20 ans d existence et d expérience Les organisations gérant le référentiel :

LES ORIGINES D ITIL Origine gouvernementale britannique 20 ans d existence et d expérience Les organisations gérant le référentiel : La méthode ITIL plan Introduction C est quoi ITIL? Utilisation d ITIL Objectifs Les principes d ITIL Domaines couverts par ITIL Les trois versions d ITIL Pourquoi ITIL a-t-il tant de succès Inconvénients

Plus en détail

ANALYSE DES RISQUES ET MANAGENEMENT DES RISQUES

ANALYSE DES RISQUES ET MANAGENEMENT DES RISQUES ANALYSE DES RISQUES ET MANAGENEMENT DES RISQUES Introduction : Le management des risques est un processus qui permet au Business Manager d équilibrer les coûts économiques et opérationnels et faire du

Plus en détail

Ingénierie des Exigences

Ingénierie des Exigences Club Management des Systèmes d'information Ingénierie des Exigences Comment construire et maintenir un référentiel? 1 Qui suis-je? Stéphane BADREAU Consultant et formateur en ingénierie des exigences chez

Plus en détail

Gestion des Incidents (Incident Management)

Gestion des Incidents (Incident Management) 31/07/2004 Les concepts ITIL-Incidents 1 «Be prepared to overcome : - no visible management ou staff commitment, resulting in non-availability of resources - [ ]» «Soyez prêts a surmonter : - l absence

Plus en détail

IFT2255 - Génie logiciel. Cycle de vie du logiciel. Activités de développement. Planification (étude préliminaire) Processus de développement

IFT2255 - Génie logiciel. Cycle de vie du logiciel. Activités de développement. Planification (étude préliminaire) Processus de développement IFT2255 - Génie logiciel Processus de développement Cycle de vie du logiciel Bruno Dufour dufour@iro.umontreal.ca Activités de développement 3 Planification (étude préliminaire) 4 Planification du projet

Plus en détail

Rational Unified Process

Rational Unified Process Rational Unified Process Hafedh Mili Rational Unified Process 1. Principes de base 2. Les phases 3. Les activités (workflows) Copyright Hafedh Mili 2005 2 1 Rational Unified Process Processus de développement

Plus en détail

Comprendre ITIL 2011 Normes et meilleures pratiques pour évoluer vers ISO 20000

Comprendre ITIL 2011 Normes et meilleures pratiques pour évoluer vers ISO 20000 Avant-propos 1. Une nouvelle version de ce livre 19 2. Pourquoi ce livre? 19 ITIL et les normes 1. ITIL 21 1.1 Historique 22 1.1.1 Ce que n est pas ITIL 22 1.1.2 Ce qu est ITIL 22 1.2 Les acteurs 23 1.3

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

L application doit être validée et l infrastructure informatique doit être qualifiée.

L application doit être validée et l infrastructure informatique doit être qualifiée. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 Annexe 11: Systèmes informatisés

Plus en détail

Comprendre ITIL 2011

Comprendre ITIL 2011 Editions ENI Comprendre ITIL 2011 Normes et meilleures pratiques pour évoluer vers ISO 20000 Collection DataPro Extrait 54 Comprendre ITIL 2011 Normes et meilleures pratiques pour évoluer vers ISO 20000

Plus en détail

Fiche Contenu 18-1 : Exigences organisationnelles pour un système de gestion de la qualité

Fiche Contenu 18-1 : Exigences organisationnelles pour un système de gestion de la qualité Fiche Contenu 18-1 : Exigences organisationnelles pour un système de gestion de la qualité Définition Le terme organisation dans le contexte d un modèle de gestion de la qualité est utilisé pour indiquer

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

Gestion des services Informatiques ITIL Version 3, Les fondamentaux Conception des Services

Gestion des services Informatiques ITIL Version 3, Les fondamentaux Conception des Services Gestion des services Informatiques ITIL Version 3, Les fondamentaux Conception des Services Jaafar DEHBI 2003 Acadys - all rights reserved Conception des services Buts et objectifs Concevoir les nouveaux

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

MV Consulting. ITIL & IS02700x. Club - 27001- Toulouse Sébastien Rabaud Michel Viala. Michel Viala

MV Consulting. ITIL & IS02700x. Club - 27001- Toulouse Sébastien Rabaud Michel Viala. Michel Viala MV Consulting Michel Viala ITIL & IS02700x Club - 27001- Toulouse Sébastien Rabaud Michel Viala ITIL & ISO2700x : Présentation Intervenants Michel VIALA : Consultant ITIL confronté à la prise en compte

Plus en détail

1 La méthodologie 7 S pour conduire un projet QSE

1 La méthodologie 7 S pour conduire un projet QSE 1 La méthodologie 7 S pour conduire un projet QSE Cette méthode, fruit de retours d expériences, permet de maîtriser un projet QSE et d atteindre l objectif de certification. C est une véritable «feuille

Plus en détail

Principes de base et aspects techniques

Principes de base et aspects techniques HERVÉ SCHAUER CONSULTANTS Cabinet de Consultants en Sécurité Informatique depuis 1989 Spécialisé sur Unix, Windows, TCP/IP et Internet Normes ISO27001 / ISO27002 Principes de base et aspects techniques

Plus en détail

Bienvenue dans le monde de la construction logicielle

Bienvenue dans le monde de la construction logicielle Chapitre 1 Bienvenue dans le monde de la construction logicielle Sommaire : 1.1 La construction logicielle, qu est-ce que c est? : page 3 1.2 Pourquoi la construction logicielle est-elle importante? :

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

COMPLIANCE Consulting. Gardez la Maîtrise de vos Exigences. 18 mai 2011

COMPLIANCE Consulting. Gardez la Maîtrise de vos Exigences. 18 mai 2011 COMPLIANCE Consulting Gardez la Maîtrise de vos Exigences 18 mai 2011 Présentation Société Société Société de conseil spécialisée dans le transfert de technologies en matière de processus, de méthodes

Plus en détail

Projet Informatique. Philippe Collet. Licence 3 Informatique S5 2014-2015. http://deptinfo.unice.fr/twiki/bin/view/linfo/projetinfo201415

Projet Informatique. Philippe Collet. Licence 3 Informatique S5 2014-2015. http://deptinfo.unice.fr/twiki/bin/view/linfo/projetinfo201415 Projet Informatique Philippe Collet Licence 3 Informatique S5 2014-2015 http://deptinfo.unice.fr/twiki/bin/view/linfo/projetinfo201415 Réalisation d'un développement de taille conséquente? r Firefox? Ph.

Plus en détail

Pratique de logiciels de planification

Pratique de logiciels de planification Pratique de logiciels de planification MASTER TECHNOLOGIE & HANDICAP Université Paris 8 Sommaire Introduction Organisation d un projet Les principaux axes de la planification Gestion des tâches Gestion

Plus en détail

Les méthodes formelles dans le cycle de vie. Virginie Wiels ONERA/DTIM Virginie.Wiels@onera.fr

Les méthodes formelles dans le cycle de vie. Virginie Wiels ONERA/DTIM Virginie.Wiels@onera.fr Les méthodes formelles dans le cycle de vie Virginie Wiels ONERA/DTIM Virginie.Wiels@onera.fr Plan Introduction Différentes utilisations possibles Différentes techniques pour différentes propriétés à différents

Plus en détail

Plan d un Rapport de fin de projet

Plan d un Rapport de fin de projet Plan d un Rapport de fin de projet 1. COMMENT LE PROJET A ÉTÉ VÉCU DANS SON SUIVI 1.1. RÉALISATION DES OBJECTIFS Cette partie du document décrit la façon dont les objectifs du projet spécifiés dans le

Plus en détail

ISO/IEC 20000-1 versus ITIL

ISO/IEC 20000-1 versus ITIL ISO/IEC 20000- versus ITIL Séminaire du 6 Novembre itsmf OUEST C. LAHURE Axios Systems Ordre du jour ISO / IEC 20000- La Norme et son contexte Le référentiel La démarche d implémentation Le contexte de

Plus en détail

Introduction à l'iso 27001

Introduction à l'iso 27001 HERVÉ SCHAUER CONSULTANTS Cabinet de Consultants en Sécurité Informatique depuis 1989 Spécialisé sur Unix, Windows, TCP/IP et Internet Introduction à l'iso 27001 Séminaire sur la Sécurité Informatique

Plus en détail

PROJET DE CONCEPTION (6GIN333)

PROJET DE CONCEPTION (6GIN333) PROJET DE CONCEPTION (6GIN333) Cours #7 Hiver 2012 Ordre du jour Gestion des risques Introduction Concepts & définitions Processus d analyse Outils & méthodes Résultats Pause de 15 minutes Suivit des coûts

Plus en détail

IAM et habilitations, l'approche par les accès ou la réconciliation globale

IAM et habilitations, l'approche par les accès ou la réconciliation globale IAM et habilitations, l'approche par les accès ou la réconciliation globale 04/12/08 Page 1 Evidian 2008 1 Les couches archéologiques du Système d information: Les systèmes centraux Ventes Employés Employé

Plus en détail

eframe pour optimiser les reportings métiers et réglementaires

eframe pour optimiser les reportings métiers et réglementaires eframe pour optimiser les reportings métiers et réglementaires TIME WINDOW DRIVEN REPORTING POUR DES ANALYSES ET DES RAPPORTS COMPLETS ET EXACTS, À TEMPS TOUT LE TEMPS www.secondfloor.com eframe pour optimiser

Plus en détail

LES SOLUTIONS MES HUMAINES METTENT EN AVANT LES INDIVIDUS

LES SOLUTIONS MES HUMAINES METTENT EN AVANT LES INDIVIDUS LIVRE BLANC LES SOLUTIONS MES HUMAINES METTENT EN AVANT LES INDIVIDUS Une collaboration entre homme et machine LIVRE BLANC LES SOLUTIONS MES HUMAINES METTENT EN AVANT LES INDIVIDUS 2 A PROPOS Les hommes

Plus en détail

Projet Industriel Identification des contraintes DO 178C en implémentant l approche «Model Based Testing» avec l aide de l outil MaTeLo

Projet Industriel Identification des contraintes DO 178C en implémentant l approche «Model Based Testing» avec l aide de l outil MaTeLo Projet Industriel Identification des contraintes DO 178C en implémentant l approche «Model Based Testing» avec l aide de l outil MaTeLo Encadrement : Mihaela BARREAU Anthony FAUCOGNEY René Christian TUYISHIME

Plus en détail

MANAGEMENT DES SYSTEMES D INFORMATION

MANAGEMENT DES SYSTEMES D INFORMATION MANAGEMENT DES SYSTEMES D INFORMATION TROISIEME PARTIE LES PROGICIELS DE GESTION INTEGREE TABLE DES MATIERES Chapitre 1 : LA PLACE DES PGI... 3 Chapitre 2 : LE CYCLE DE VIE DES PGI... 6 Questions de cours...

Plus en détail

Exemple d implémentation d un. Projet SAP avec ASAP

Exemple d implémentation d un. Projet SAP avec ASAP Exemple d implémentation d un Projet SAP avec ASAP Implémentation d un ERP dans une organisation problématiques : adéquation aux besoins conduite du changement adaptation de l ERP adaptabilité aux utilisateurs

Plus en détail

Règles d affaires. éponse informatique inc. www.reponse.ca. Critères de qualité de toutes spécifications

Règles d affaires. éponse informatique inc. www.reponse.ca. Critères de qualité de toutes spécifications Règles d affaires éponse informatique inc. 1 Critères de qualité de toutes spécifications IEEE830-1998 Recommended Practice for Software Requirements Specifications Une spécification doit être: Correcte,

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

INTRODUCTION. QSC est un système référentiel de qualité pour la certification des institutions scolaires d enseignement général et professionnel.

INTRODUCTION. QSC est un système référentiel de qualité pour la certification des institutions scolaires d enseignement général et professionnel. INTRODUCTION QSC est un système référentiel de qualité pour la certification des institutions scolaires d enseignement général et professionnel. Ce certificat est destiné à toutes les écoles d enseignement

Plus en détail

METIER DU CYCLE DE VIE DES APPLICATIONS

METIER DU CYCLE DE VIE DES APPLICATIONS METIER DU CYCLE DE VIE DES APPLICATIONS Finalité : Répondre aux besoins des utilisateurs en mettant à leur disposition des solutions informatiques applicatives et techniques adaptées. Emplois génériques

Plus en détail

Objectifs et gestion de la sécurité

Objectifs et gestion de la sécurité INF4470 : Fiabilité et sécurité informatique Par Eric Gingras Hiver 2010 Objectifs et gestion de la sécurité Qu'est ce que la sécurité? «Situation où l'on a aucun danger à craindre.» (dictionnaire Larousse)

Plus en détail

Une protection antivirus pour des applications destinées aux dispositifs médicaux

Une protection antivirus pour des applications destinées aux dispositifs médicaux Une protection antivirus pour des applications destinées aux dispositifs médicaux ID de nexus est idéale pour les environnements cliniques où la qualité et la sécurité des patients sont essentielles. Les

Plus en détail

UNIVERSITE PARIS XII - ISIAG

UNIVERSITE PARIS XII - ISIAG UNIVERSITE PARIS XII - ISIAG MASTER 2 - CHAPITRE 4.b LE PILOTAGE DU PROJET ANALYSE DES RISQUES 1 LE PILOTAGE DU PROJET I. Software Development Plan II. III. IV. Risks Management Plan (Analyse des Risques)

Plus en détail

Quelques chiffres 07/11/2013

Quelques chiffres 07/11/2013 F DANEL Introduction Pourquoi les projets? Apporter du nouveau / une solution la ou on en a besoin! Le projet n est pas toujours une idée nouvelle C est la façon de réaliser (mettre en place) cette idée.

Plus en détail

ITIL Examen Fondation

ITIL Examen Fondation ITIL Examen Fondation Échantillon d examen A, version 5.1 Choix multiples Instructions 1. Essayez de répondre aux 40 questions. 2. Vos réponses doivent être inscrites sur la grille de réponses fournie.

Plus en détail

ORACLE PRIMAVERA PORTFOLIO MANAGEMENT

ORACLE PRIMAVERA PORTFOLIO MANAGEMENT ORACLE PRIMAVERA PORTFOLIO MANAGEMENT FONCTIONNALITÉS GESTION DE PORTEFEUILLE Stratégie d approche permettant de sélectionner les investissements les plus rentables et de créer de la valeur Paramètres

Plus en détail

P s a sep e o p r o t S e S r e vi v ce c s Fabrice Dubost

P s a sep e o p r o t S e S r e vi v ce c s Fabrice Dubost Passeport Services Fabrice Dubost 2.6 Gestion des Mises en Production ITIL, Soutien des services Entreprise, Clients et Utilisateurs Outil de Supervision Dysfonctionnements Questions / Renseignements Incidents

Plus en détail

IFT6803: Génie logiciel du commerce électronique. Chapitre 1: Introduction Section 3: Processus de développement

IFT6803: Génie logiciel du commerce électronique. Chapitre 1: Introduction Section 3: Processus de développement IFT6803: Génie logiciel du commerce électronique Chapitre 1: Introduction Section 3: Processus de développement Julie Vachon, Hiver 2003 Sommaire Chapitre 1, Section 3 «Processus de développement» 1.3.1

Plus en détail

Rendez-vous la liberté avec Rational Quality Manager

Rendez-vous la liberté avec Rational Quality Manager IBM Software Group RAT02 Rendez-vous la liberté avec Rational Quality Manager Bernard Dupré IBM Rational IT Specialist 2008 IBM Corporation Envisager une plateforme qui change la production de logiciels

Plus en détail

OBJECTIF PROFESSIONNEL DE LA QUALIFICATION VALIDEE

OBJECTIF PROFESSIONNEL DE LA QUALIFICATION VALIDEE Commission paritaire nationale de l'emploi de la Métallurgie Qualification : MQ 2007 10 89 0264 FICHE D IDENTITE DE LA QUALIFICATION VALIDEE TITRE DE LA QUALIFICATION : Coordonnateur (trice) du développement

Plus en détail

ISO/CEI 20000-1 NORME INTERNATIONALE. Technologies de l'information Gestion des services Partie 1: Exigences du système de management des services

ISO/CEI 20000-1 NORME INTERNATIONALE. Technologies de l'information Gestion des services Partie 1: Exigences du système de management des services NORME INTERNATIONALE ISO/CEI 20000-1 Deuxième édition 2011-04-15 Technologies de l'information Gestion des services Partie 1: Exigences du système de management des services Information technology Service

Plus en détail

ITIL 2011 Offres et accords de services (SOA) avec certification 5 jours (anglais et français)

ITIL 2011 Offres et accords de services (SOA) avec certification 5 jours (anglais et français) ITIL 2011 Offres et accords de services (SOA) avec certification 5 jours (anglais et français) Vue d ensemble de la formation ITIL est un ensemble de conseils sur les meilleures pratiques, devenu un référentiel

Plus en détail

PRINCIPES et METHODES de SPECIFICATION et de CONCEPTION GLOBALE des SYSTEMES INFORMATISES 10/20/02 1

PRINCIPES et METHODES de SPECIFICATION et de CONCEPTION GLOBALE des SYSTEMES INFORMATISES 10/20/02 1 PRINCIPES et METHODES de SPECIFICATION et de CONCEPTION GLOBALE des SYSTEMES INFORMATISES 10/20/02 1 CYCLE de VIE des SYSTEMES INFORMATISES Expression du besoin Développement du «système» Exploitation

Plus en détail

Améliorer votre approche processus

Améliorer votre approche processus Améliorer votre approche processus Décrire de manière complète les processus, Mettre en place des tableaux de bord de manière à en surveiller le fonctionnement et à en déterminer l efficacité, Réaliser

Plus en détail

FILIÈRE METHODOLOGIE & PROJET

FILIÈRE METHODOLOGIE & PROJET FILIÈRE METHODOLOGIE & PROJET 109 Gestion de projet METHODOLOGIE ET PROJET Durée 3 jours Conduite de projet COND-PRO s Intégrer les conditions de réussite d une démarche de management par projet. Impliquer

Plus en détail

Conception du projet / Management du Projet Management du produit du projet. Audit de la gestion de Projet APPROCHE MANAGGIO

Conception du projet / Management du Projet Management du produit du projet. Audit de la gestion de Projet APPROCHE MANAGGIO Conception du projet / Management du Projet Management du produit du projet Audit de la gestion de Projet APPROCHE MANAGGIO Un projet se caractérise par un contenu algorithmique d informations élevé (complexité

Plus en détail

Management des processus opérationnels

Management des processus opérationnels Ecole Nationale Supérieure de Management Master Management des organisations Management des processus opérationnels Dr TOUMI Djamila Cours n 1: La vision processus dans le management des organisations

Plus en détail

ITIL Examen Fondation

ITIL Examen Fondation ITIL Examen Fondation Échantillon d examen B, version 5.1 Choix multiples Instructions 1. Essayez de répondre aux 40 questions. 2. Vos réponses doivent être inscrites sur la grille de réponses fournie.

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

--Séance 2 Analyse du problème et élicitation des exigences

--Séance 2 Analyse du problème et élicitation des exigences --Séance 2 Analyse du problème et élicitation des exigences Objectifs: Être en mesure de comprendre le processus d élicitation des exigences. Prendre conscience des défis de l élicitation. Comprendre le

Plus en détail

La GED Fonction et processus

La GED Fonction et processus La GED Fonction et processus Le contexte Les objectifs Les conditions d'une réussite Les moyens et les fonctions : Structure de données, Coffre fort, Workflow Référencer, retrouver, approuver, distribuer

Plus en détail

IBM Tivoli Capacity Process Manager

IBM Tivoli Capacity Process Manager Optimiser l utilisation et les performances des capacités en adoptant une approche disciplinée de la gestion des capacités IBM Tivoli Capacity Process Manager Points forts Aide à améliorer la disponibilité

Plus en détail

JOURNÉE THÉMATIQUE SUR LES RISQUES

JOURNÉE THÉMATIQUE SUR LES RISQUES Survol de Risk IT UN NOUVEAU RÉFÉRENTIEL DE GESTION DES RISQUES TI GP - Québec 2010 JOURNÉE THÉMATIQUE SUR LES RISQUES 3 mars 2010 - Version 4.0 Mario Lapointe ing. MBA CISA CGEIT mario.lapointe@metastrategie.com

Plus en détail

LOG2420 Analyse et conception d interfaces utilisateur

LOG2420 Analyse et conception d interfaces utilisateur LOG2420 Analyse et conception d interfaces utilisateur Processus de développement centré utilisateur 1/36 LOG2420 Analyse et conception d interfaces utilisateur Processus de développement centré utilisateur

Plus en détail

INF2015 Développement de logiciels dans un environnement Agile. Examen final 24 avril 2014 17:30 à 20:30

INF2015 Développement de logiciels dans un environnement Agile. Examen final 24 avril 2014 17:30 à 20:30 Examen final 24 avril 2014 17:30 à 20:30 Nom, prénom : Code permanent : Répondez directement sur le questionnaire. Question #1 5% Qu'est-ce qu'un test de régression? Question #2 5% Selon extreme Programming,

Plus en détail

RESUME DES NORMES ISO

RESUME DES NORMES ISO RESUME DES NORMES ISO Travail réalisé par : Selma FERKOUS O8301 ISO 19011 : La norme internationale ISO 9011, se focalise sur le management de programmes d audit, la réalisation d audits internes ou externes

Plus en détail

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

Analyse et conception des Systèmes d Information. La démarche Merise : La Maintenance Analyse et conception des Systèmes d Information La démarche Merise : La Maintenance Place, spécificité, objectifs et principes directeurs Niveaux et catégories de maintenance Formes de maintenance Déroulement

Plus en détail

Tous droits réservés SELENIS

Tous droits réservés SELENIS 1. Objectifs 2. Etapes clefs 3. Notre proposition d accompagnement 4. Présentation de SELENIS 2 Un projet est une réalisation spécifique, dans un système de contraintes donné (organisation, ressources,

Plus en détail

Les services d implémentation de votre nouvelle solution de planification

Les services d implémentation de votre nouvelle solution de planification Les services d implémentation de votre nouvelle solution de planification Découvrez les services qui vous assureront une implémentation fructueuse de votre nouvelle solution de planification Une publication

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

Topologie du web - Valentin Bourgoin - http://www.valentinbourgoin.net. Méthodes agiles & SCRUM

Topologie du web - Valentin Bourgoin - http://www.valentinbourgoin.net. Méthodes agiles & SCRUM Méthodes agiles & SCRUM 1/ Pourquoi les méthodes agiles? Définition d une méthode agile. Fondamentaux. Quand les utiliser? 2/ SCRUM En quoi est-ce une méthode agile? Sprints et releases. Le Product Owner.

Plus en détail

Le développement des logiciels - les défis

Le développement des logiciels - les défis Le triangle de la qualité des logiciels: le personnel, le processus et le produit Claude Y Laporte Professeur Département de génie électrique Le développement des logiciels - les défis 2 1 Le triangle

Plus en détail