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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Introduction à la conduite de projet "systèmes d'information"

Introduction à la conduite de projet systèmes d'information Centre national de la recherche scientifique Direction des systèmes d'information REFERENTIEL QUALITE Guide méthodologique Introduction à la conduite de projet "systèmes d'information" Référence : CNRS/DSI/conduite-projet/principes/guide-introduction

Plus en détail

Pré-requis. Objectifs. Préparation à la certification ITIL Foundation V3

Pré-requis. Objectifs. Préparation à la certification ITIL Foundation V3 La phase de stratégie de services Page 83 ITIL Pré-requis V3-2011 et objectifs Pré-requis La phase de stratégie de services Maîtriser le chapitre Introduction et généralités d'itil V3. Avoir appréhendé

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

Les expériences d ERNI dans l univers du management, des processus et des technologies. Experience N 52. Mars 2012 Pas à pas vers de bonnes exigences

Les expériences d ERNI dans l univers du management, des processus et des technologies. Experience N 52. Mars 2012 Pas à pas vers de bonnes exigences Les expériences d ERNI dans l univers du management, des processus et des technologies Experience N 52 Mars 2012 OutsourcINg Pas à pas vers de bonnes exigences Outsourcing 10 11 Pas à pas vers de bonnes

Plus en détail

CHARTE DE L AUDIT INTERNE DU CMF

CHARTE DE L AUDIT INTERNE DU CMF CHARTE DE L AUDIT INTERNE DU CMF Approuvée par le Collège du CMF en date du 3 juillet 2013 1 La présente charte définit officiellement les missions, les pouvoirs et les responsabilités de la structure

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

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

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

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

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

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

ECOLE CONDUITE DE PROJET Présenter un dossier compétitif auprès d une agence

ECOLE CONDUITE DE PROJET Présenter un dossier compétitif auprès d une agence ECOLE CONDUITE DE PROJET Présenter un dossier compétitif auprès d une agence Paris, le 10-03-2010 Le Plan Qualité et le montage de projet Corinne JUFFROY Ecole Conduite de Projet - Paris - 10 mars 2010

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

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

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

Les principes et les thèmes PRINCE2

Les principes et les thèmes PRINCE2 31 Chapitre 3 Les principes et les thèmes PRINCE2 1. Les principes de la méthode PRINCE2 Les principes et les thèmes PRINCE2 Les principes de la méthode PRINCE2 définissent un cadre de bonnes pratiques

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

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

IFT3913 Qualité du logiciel et métriques. Chapitre 2

IFT3913 Qualité du logiciel et métriques. Chapitre 2 IFT3913 Qualité du logiciel et métriques Chapitre 2 Qualité du produit logiciel Plan du cours Introduction Qualité du logiciel Théorie de la mesure Mesure de la qualité du logiciel Études empiriques Mesure

Plus en détail

Principes de management de la qualité

Principes de management de la qualité Principes de management de la qualité Hassen Ammar, consultant formateur en management PLUS CONSEIL: www.plusconseil.net PLUS CONSEIL ISO 9000 Les 8 huit principes de management Principe 1 Orientation

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

Planifier & Organiser

Planifier & Organiser Planifier & Organiser Introduction Cette introduction (en ligne) vous propose un bref aperçu des tâches principales à prendre en compte lorsque vous planifiez & organisez votre projet européen. L introduction

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

INFORMATIQUE - ANALYSE ET CONCEPTION D APPLICATIONS

INFORMATIQUE - ANALYSE ET CONCEPTION D APPLICATIONS MINISTERE DE LA COMMUNAUTE FRANCAISE ADMINISTRATION GENERALE DE L ENSEIGNEMENT ET DE LA RECHERCHE SCIENTIFIQUE ENSEIGNEMENT DE PROMOTION SOCIALE DE REGIME 1 DOSSIER PEDAGOGIQUE UNITE DE FORMATION INFORMATIQUE

Plus en détail

CATALOGUE DE PRESTATIONS 2014

CATALOGUE DE PRESTATIONS 2014 CATALOGUE DE PRESTATIONS 2014 La Formation Professionnelle Management Relationnel Les Fondamentaux du Management Animation d équipe, Manager Coach Développer son assertivité Communiquer efficacement avec

Plus en détail

Licence en Informatique à Horraire Décalé. Cours Gestion de projet informatique Première partie

Licence en Informatique à Horraire Décalé. Cours Gestion de projet informatique Première partie Licence en Informatique à Horraire Décalé Cours Gestion de projet informatique Première partie 1 PLAN Introduction 1. Les concepts de base en management de projet : 3-33 2 Les processus du management de

Plus en détail

Agilitéet qualité logicielle: une mutation enmarche

Agilitéet qualité logicielle: une mutation enmarche Agilitéet qualité logicielle: une mutation enmarche Jean-Paul SUBRA Introduction : le manifeste Agile Manifeste pour le développement Agile de logiciels Nous découvrons comment mieux développer des logiciels

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

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

Forum AMOA ADN Ouest. Présentation du BABOK. 31 Mars 2013 Nadia Nadah

Forum AMOA ADN Ouest. Présentation du BABOK. 31 Mars 2013 Nadia Nadah Forum AMOA ADN Ouest Présentation du BABOK 31 Mars 2013 Nadia Nadah Ce qu est le BABOK Ce que n est pas le BABOK Définition de la BA - BABOK version 2 Le processus de Business Analysis La structure du

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

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

INDICATIONS DE CORRECTION

INDICATIONS DE CORRECTION SUJET NATIONAL POUR L'ENSEMBLE DES CENTRES DE GESTION ORGANISATEURS CONCOURS INTERNE ET TROISIÈME VOIE DE TECHNICIEN TERRITORIAL PRINCIPAL DE 2 ème CLASSE SESSION 2014 SPÉCIALITÉ : INGENIERIE, INFORMATIQUE

Plus en détail

ECOLE DU MANAGEMENT - Niveau 3 Cycle Supérieur Industriel

ECOLE DU MANAGEMENT - Niveau 3 Cycle Supérieur Industriel Responsables opérationnels débutants ou expérimentés en lien direct avec le comité de direction. Responsables d unités de production. Responsables de projet (technique, organisation, industrialisation).

Plus en détail

Performance et valorisation RH

Performance et valorisation RH Performance et valorisation RH Document téléchargeable à des fins de consultation. Toute utilisation à des fins commerciales proscrite sans autorisation expresse de l auteur. 1 La fonction «Ressources

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

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

INFORMATIQUE - PROJET DE DEVELOPPEMENT INTERNET/INTRANET

INFORMATIQUE - PROJET DE DEVELOPPEMENT INTERNET/INTRANET MINISTERE DE LA COMMUNAUTE FRANCAISE ADMINISTRATION GENERALE DE L ENSEIGNEMENT ET DE LA RECHERCHE SCIENTIFIQUE ENSEIGNEMENT DE PROMOTION SOCIALE DE REGIME 1 DOSSIER PEDAGOGIQUE UNITE DE FORMATION INFORMATIQUE

Plus en détail

Gestion du risque d entreprise : solutions pratiques. Anne M. Marchetti

Gestion du risque d entreprise : solutions pratiques. Anne M. Marchetti Gestion du risque d entreprise : solutions pratiques Anne M. Marchetti Programme Aperçu général de la gestion des risques, de l évaluation des risques et du contrôle interne Contexte actuel Contrôle interne

Plus en détail

Cours de Gestion de projet

Cours de Gestion de projet Cours de Gestion de projet Plan des cours Cours 1 : Vision Générale Cours 2 : Les différents types de projets Informatiques/Urbanisation d un SI Cours 2 : Les cycles de vie Cours 3 : Focus sur «Le suivi

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

Management par les processus les éléments structurants. Lionel Di Maggio Master 1 MIAGE

Management par les processus les éléments structurants. Lionel Di Maggio Master 1 MIAGE Management par les processus les éléments structurants Lionel Di Maggio Master 1 MIAGE 1 1. Objectifs et définitions 2. Le retour sur investissement des démarches 3. Les éléments structurants 4. Mise en

Plus en détail

ITIL FOUNDATION 2011 & PREPARATION A LA CERTIFICATION

ITIL FOUNDATION 2011 & PREPARATION A LA CERTIFICATION SEMINAIRE DE FORMATION ITIL FOUNDATION 2011 & PREPARATION A LA CERTIFICATION Management des services informatiques Objectifs de la formation Cette formation est destinée aux personnes qui aimeraient gagner

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

Management - Ressources humaines Exemples de formations

Management - Ressources humaines Exemples de formations Management - Ressources humaines Exemples de formations Management - Ressources humaines - Animation d'équipes - Les entretiens professionnels d'évaluation - L'intégration de nouveaux salariés - Anticiper

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

ITIL V3 Intermediate - Release, Control and Validation (RCV) Mettre en production, contrôler et valider des processus (3ITMG186)

ITIL V3 Intermediate - Release, Control and Validation (RCV) Mettre en production, contrôler et valider des processus (3ITMG186) ITIL V3 Intermediate - Release, Control and Validation (RCV) Mettre en production, contrôler et valider des processus (3ITMG186) Durée 5 Jours / 35 Heures de formation Objectifs Savoir planifier les activités

Plus en détail

Professeur superviseur ALAIN APRIL

Professeur superviseur ALAIN APRIL RAPPORT TECHNIQUE PRÉSENTÉ À L ÉCOLE DE TECHNOLOGIE SUPÉRIEURE DANS LE CADRE DU COURS MGL804 REALISATION ET MAINTENANCE DE LOGICIELS TRAVAIL DE SESSION N12 EVALUATION D UN CONTRAT DE MAINTENANCE DU LOGICIEL

Plus en détail

Comment assurer le plein potentiel de votre solution analytique. Guillaume Bédard, Directeur des Solutions d Affaires Odesia

Comment assurer le plein potentiel de votre solution analytique. Guillaume Bédard, Directeur des Solutions d Affaires Odesia L Comment assurer le plein potentiel de votre solution analytique ODESIA 1155 University suite 800 Montreal, Qc, Canada H3B 3A7 Phone: (514) 876-1155 Fax: (514) 876-1153 www.odesia.com Guillaume Bédard,

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

Démarche qualité. Responsabilité individuelle

Démarche qualité. Responsabilité individuelle Démarche qualité Réussite collective Basée sur la Responsabilité individuelle Les prophètes Taylor (1919) L inspection doit garantir la conformité 2 Les prophètes W. A. Shewhart (1931) Le contrôle statistique

Plus en détail

Le génie Logiciel (suite)

Le génie Logiciel (suite) Le génie Logiciel (suite) Lors du cours précédent, on a étudié différents cycles de vie, dont la cascade, ou la spirale. Analyse des besoins L analyse des besoins est une étape menant à l élaboration de

Plus en détail

Les exigences de la norme ISO 9001:2008

Les exigences de la norme ISO 9001:2008 Les exigences de la norme ISO 9001:2008! Nouvelle version en 2015! 1 Exigences du client Satisfaction du client Le SMQ selon ISO 9001:2008 Obligations légales Collectivité Responsabilité de la direction

Plus en détail

Introduction à la norme ISO 27001. Eric Lachapelle

Introduction à la norme ISO 27001. Eric Lachapelle Introduction à la norme ISO 27001 Eric Lachapelle Introduction à ISO 27001 Contenu de la présentation 1. Famille ISO 27000 2. La norme ISO 27001 Implémentation 3. La certification 4. ISO 27001:2014? 2

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

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

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

ITIL V2 Processus : La Gestion des Configurations

ITIL V2 Processus : La Gestion des Configurations ITIL V2 Processus : La Gestion des Configurations Auteur: Fabian PIAU, Master 2 MIAGE, Nantes La Gestion des Configurations est un processus issu d ITIL version 2 qui aide au soutien du service («Service

Plus en détail

Gestion Projet. Cours 3. Le cycle de vie

Gestion Projet. Cours 3. Le cycle de vie Gestion Projet Cours 3 Le cycle de vie Sommaire Généralités 3 Séquentiel 7 Itératif/Incrémental 17 Extreme Programming 22 Que choisir? 29 Etats Transverse 33 Cours 3 2006-2007 2 Généralités Cours 3 2006-2007

Plus en détail

ECOLE DU MANAGEMENT - Niveau 3 Cycle Supérieur Industriel

ECOLE DU MANAGEMENT - Niveau 3 Cycle Supérieur Industriel Responsables opérationnels débutants ou expérimentés en lien direct avec le comité de direction. Responsables d unités de production. Responsables de projet (technique, organisation, industrialisation).

Plus en détail

Migration d un logiciel de gestion

Migration d un logiciel de gestion Auteur : David PERRET Publication : 01/11/2015 Toute société utilisatrice de logiciel de gestion est inéluctablement confrontée à des migrations de données. Ces migrations représentent des risques et un

Plus en détail

MAINTENANCE INDUSTRIELLE

MAINTENANCE INDUSTRIELLE Fiche Pratique MAINTENANCE INDUSTRIELLE Comment évaluer la performance d une prestation sur site? UNE METHODE D ANALYSE Juin 2006 MAINTENANCE INDUSTRIELLE ET DEMARCHES DE PROGRES CONTEXTE L optimisation

Plus en détail

IFT3913 Qualité du logiciel et métriques. Chapitre 2 Modèles de processus du développement du logiciel. Plan du cours

IFT3913 Qualité du logiciel et métriques. Chapitre 2 Modèles de processus du développement du logiciel. Plan du cours IFT3913 Qualité du logiciel et métriques Chapitre 2 Modèles de processus du développement du logiciel Plan du cours Introduction Modèles de processus du développement du logiciel Qualité du logiciel Théorie

Plus en détail

FINANCE CRITÈRES D ÉVALUATION (Les critères d évaluation doivent être pris en compte de pair avec le Cadre de surveillance du BSIF)

FINANCE CRITÈRES D ÉVALUATION (Les critères d évaluation doivent être pris en compte de pair avec le Cadre de surveillance du BSIF) RÔLE DE LA FONCTION Finance est une fonction autonome qui rend compte avec exactitude et en temps utile du rendement des unités opérationnelles (y compris les secteurs d activité) de l institution financière

Plus en détail

IFT3903 Qualité du logiciel et métriques

IFT3903 Qualité du logiciel et métriques IFT3903 Qualité du logiciel et métriques Yann-Gaël Guéhéneuc Hiver 2006 Chapitre 2 Développement logiciel (Tiré du cours de Houari Sahraoui) GEODES Ptidej Team OO Programs Quality Evaluation and Enhancement

Plus en détail

pratiques. Nous avons abondamment illustré l'application correcte et efficace des nombreuses pratiques en assurance qualité par des cas pratiques.

pratiques. Nous avons abondamment illustré l'application correcte et efficace des nombreuses pratiques en assurance qualité par des cas pratiques. Cet ouvrage s inscrit dans le cadre d une problématique globale portant sur l amélioration de la qualité du logiciel pour des organismes qui ont atteint un certain niveau de maturité. Il cherche à rapprocher

Plus en détail

MEILLEURE PRATIQUE EN GRECE CAS No 1 CENTRE NATIONAL DE L ADMINISTRATION PUBLIQUE. 1. Structure et fonctionnement

MEILLEURE PRATIQUE EN GRECE CAS No 1 CENTRE NATIONAL DE L ADMINISTRATION PUBLIQUE. 1. Structure et fonctionnement MEILLEURE PRATIQUE EN GRECE CAS No 1 CENTRE NATIONAL DE L ADMINISTRATION PUBLIQUE 1. Structure et fonctionnement Le Centre National d Administration Publique (National Center of Public Administration,

Plus en détail

Mener des entretiens professionnels

Mener des entretiens professionnels Formations Mener des entretiens professionnels Durée :... 2,5 jours - 18 heures Personnel concerné :... tout responsable hiérarchique ayant à mener des entretiens d évaluation Méthode pédagogique :...

Plus en détail