La présentation est en train de télécharger. S'il vous plaît, attendez

La présentation est en train de télécharger. S'il vous plaît, attendez

GENIE LOGICIEL § CONDUITE DE PROJETS

Présentations similaires


Présentation au sujet: "GENIE LOGICIEL § CONDUITE DE PROJETS"— Transcription de la présentation:

1 GENIE LOGICIEL § CONDUITE DE PROJETS
ISEFC 2010/2011 UV 243 GENIE LOGICIEL § CONDUITE DE PROJETS R. Marouane

2 Introduction Générale
ISEFC 2009/ 2010 Introduction Générale R. Marouane

3 Introduction Le processus d ’informatisation d ’un système
de gestion est très complexe Intervention de plusieurs acteurs : Informaticien, utilisateur, organisateur… Intégration de chaque sous-système dans le système global => Interactions * Multiplicité et variété des :événements, données, procédures, règles de gestion Maintenance régulière des applications et de la documentation.` Pour maîtriser ces difficultés et permettre aux membres d'une équipe de concourir efficacement à la réalisation des phases d'un projet d'une Méthodologie et des normes de conception, de développement. de test et de mise en place Nécessité Organisation R. Marouane

4 Les Systèmes *Définitions
Un système est un tout constitué d'ELEMENTS unis par des RELATIONS, les éléments et les relations étant munis de PROPRIETES Décrire un système Déterminer ses éléments (objets, entité, individus) et ses relations (association). ses propriétés (attributs) ses activités et l'organisation qui en découle. R. Marouane

5 Les Systèmes Ent. Etat 1 Ent. Etat 2 Réaction Entreprise
Un système est caractérisé par : * son état : défini par la valeur des propriétés caractérisant les éléments et les relations. Exp: nombre de commande, total commission,... * son environnement : le système subit les contraintes de son environnement. Ent. Etat 2 Réaction Entreprise Ent. Etat 1 Commande Client Produit livré Rejet R. Marouane

6 Les Systèmes Décomposition en sous-systèmes SYSTEME ENSEMBLE COMPLEXE
Gestion Client Expédition Gest. Commande Sys.Entreprise Gest. Stock Magasin Facturation R. Marouane

7 Le système OPERANT transforme :
Les Systèmes Le système OPERANT transforme : Système OPERANT Flux Financiers Matière 1ère Produit finis Flux Entrants Flux Sortants R. Marouane

8 * Autres définitions d ’un système:
Les Systèmes * Autres définitions d ’un système: -"Ensemble d'éléments en INTERACTION DYNAMIQUE, organisés en fonction d'un BUT«  -"Un SI est constitué de l'ensemble des moyens humains & matériels et des méthodes se rapportant au traitement des différentes formes d'informations d'une organisation" * Fonctionnement d'une organisation La représentation du fonctionnement d'une organisation se fait par trois notions : Système OPERANT Système de PILOTAGE Système D'INFORMATION R. Marouane

9 Les Systèmes Système PILOTAGE S I Système OPERANT F.Sortants
F. Entrants F.Sortants R. Marouane

10 Système d’Information
Système d’Information: Ensemble organisé de ressources: matériel, logiciel, personnel, données, procédures… permettant d’acquérir, de traiter, stocker, communiquer des informations (sous formes données, textes, images, sons…) dans des organisations. Système d’Information Acteurs Informations Processus R. Marouane

11 Système Informatique Système d’Informations Système Informatique
S’appuie sur Permet Système Informatique Matériels Logiciels Applicatifs R. Marouane

12 Relation entre les Systèmes
Système d'Information Système Informatisé Système Informatique R. Marouane

13 Les Découpages et Modèles de Développement
ISEFC 2009/2010 Les Découpages et Modèles de Développement R. Marouane

14 GESTION DE PROJET Informatique: Méthodologie, Concepts, Techniques, Technologies, Langages, Environnements, Outils, Plates-formes,… Organisationnel:Assistance, Planification, Estimation de charge, Surveillance des délais et des coûts, Gestion de la qualité,… Normalisation par: AFITEP, PMI, IPMA, ICEC R. Marouane

15 PROJET Projet nécessite 3 composantes: Objectif Moyens Délai Objectif
Projet est la situation contrainte par les 3 sommets du triangle: Solidarité des Sommets. Si l’un des sommets bouge, le triangle est modifié et aura une influence sur le délai ou sur les ressources à mettre en œuvre. R. Marouane

16 PROJET ISO: « Processus unique, qui consiste en un ensemble d’activités coordonnées et maîtrisées comportant des dates de début et de fin, entrepris dans le but d’atteindre un objectif conforme à des exigences spécifiques telles que les contraintes de délais, de coûts et de ressources » PMI: « Entreprise temporaire décidée pour obtenir un produit ou un service unique » AFITEP: « Ensemble d’actions à réaliser pour satisfaire un objectif défini, dans le cadre d’une mission précise, et pour la réalisation desquelles on a identifié non seulement un début, mais aussi une fin » R. Marouane

17 Management de Projet Analyser Organiser Produire Piloter
Management de Projet: consiste à planifier, organiser, suivre, et maîtriser tous les aspects d’un projet, ainsi que la motivation de tous ceux qui sont impliqués dans le projet de façon à atteindre les objectifs de façon sûre et dans les critères de coûts, délais et performance. Cela inclut les tâches de direction nécessaires aux performances de projet. R. Marouane

18 Découpage Temporel du Projet
Permet de répartir le travail dans le temps: Étapes, Phases, Tâches, Livrables Livrable 1..* 1..* 1..* 1..* 1 1 1 1 Projet Étape Phase Tâche 1 * 1 * 1 * * * * * 2 2 2 Date 2 R. Marouane

19 Découpage Structurel du Projet
Permet d’organiser le travail en se basant sur la structure du produit final. AVANTAGES Maîtriser le projet Répartir les responsabilités Réduire les délais planifiés Avoir un développement incrémental Découpage statique (niveau 1) Découpage dynamique (niveau 2) Projet Module est découpé en se décompose en 1 1..* 0..1 * R. Marouane

20 Découpages Normalisés
PBS: Structure de décomposition du produit Différents composants du produit final Découpage en modules (arborescence) « Représentation des liens de composition entre les divers constituants d’un produit complexe » WBS: Structure de décomposition du travail Représentation de la façon de parvenir au résultat Organigramme des tâches « OT » « Découpage hiérarchisé et arborescent du processus de réalisation en éléments plus faciles à analyser et à maîtriser,appelés lots de travaux ou tâches » OBS: Structure de décomposition de l’Organisation Apparition des noms des personnes responsables de la production des différents éléments Organigramme fonctionnel « OF » « Structure des différents niveaux de responsabilités de réalisation de l’ensemble des lots de travaux d’un même organigramme des tâches » R. Marouane

21 Les Cycles et Cycle de Vie
Cycle d'abstraction Cycle de décision Cycle de vie Temps Niveau d'abstraction Hiérarchie des décisions R. Marouane

22 Les Cycles et Cycle de Vie
Temps qui mène du point de départ à l'exploitation du système en passant par : Sa naissance sa maturité et sa maintenance Parcours allant de l'étude de l'objet naturel à l'intégration du système artificiel à cet objet naturel R. Marouane

23 Les Modèles de Développement
Le modèle du code-and-fix Le modèle de la transformation automatique Le modèle de la cascade Le modèle en V Le modèle en W Le modèle de développement évolutif Le modèle de la spirale R. Marouane

24 Compréhension du Problème
1. Le Modèle du Code-and-Fixt Compréhension du Problème Programmation Mise au Point Si non satisfaisant FIN R. Marouane

25 1. Le Modèle du Code-and-Fixt
Adapté pour les projets simples Itératif pour la mise au point jusqu’à satisfaction Collaboration avec les futurs utilisateurs Absence d’étape de conception R. Marouane

26 2. Le Modèle de Transformation Automatique
Spécifications Validation Transformation R. Marouane

27 2. Le Modèle de Transformation Automatique
Transformation automatique des spécifications en programmes Nécessité de spécifications complètes, claires et validées Itératif au niveau des spécifications / validations Génération automatique de codes R. Marouane

28 3. Le Modèle de la Cascade Faisabilité Spécification Conception
Validation Spécification Validation Conception Générale Vérification Conception Détaillée Vérification Codage Tests Unitaires Tests d’In- tégration Les phases sont séquentielles et obligatoires Vérification = contrôle de conformité des travaux de la phase / cahier des charges Validation = contrôler que les travaux de la phase sont correctement fait (Utilisation des bonnes méthodes, des normes , nouvelles technologies) Intégration Implémentation Recette R. Marouane

29 3. Le Modèle de la Cascade Démarche de réduction des risques
Minimiser au fur et à mesure l’impact des incertitudes Exclusion des utilisateurs dès les phases de conception « phases techniques » Contrôle qualitatif à la fin du projet Risque de refus du système par les utilisateurs R. Marouane

30 3. Le Modèle de la Cascade Cycle de vie séquentiel ou approche descendante Validation ou vérification officielle à chaque étape Toutes les étapes sont nécessaires et suffisantes Effet ‘Tunnel’: Perte de visibilité R. Marouane

31 Définition Fonctionnelle du besoin Recette Fonctionnelle
4. Le Modèle en V Étude d’Opportunité Bilan du Projet Étude de Faisabilité Bilan Généralisation Définition Fonctionnelle du besoin Bilan Site Pilote Étude Détaillée Recette Fonctionnelle Étude Technique Test d’Intégration Réalisation R. Marouane

32 4. Le Modèle en V Amélioration du modèle en cascade
Réduction de l’effet ‘Tunnel’ Nécessité de décomposition du système en sous-ensembles: composants Évaluation et validation par composant puis pour un site pilote et enfin pour le projet R. Marouane

33 Scénarii de tests du système
4. Le Modèle en V Scénarii de tests du système Système Intégration du système Scénarii de tests des sous-systèmes Sous-systèmes Intégration des sous-systèmes Scénarii tests Éléments Eléments Intégration des éléments Modules ANALYSE PROGRAMMATION ET TEST UNITAIRE SYNTHESE Analyse : Fractionnement (résultat de la conception) * Synthèse : Assemblage (résultat de l’intégration) R. Marouane

34 4. Le Modèle en V Cycle de vie en V Produit risque de devenir complexe
* Adapté pour les logiciels d’une certaine taille (5 à 7 personnes) * Pour augmenter le débit et réduire les délais Équipes de quelques individus Répartition de tâches en fonction de leurs talents et de leurs expériences Coopération * Découpage du système en sous-systèmes avec un maximum d’autonomie * Fractionnement du sous-système en éléments si la taille du sous-système dépasse la capacité d’une équipe * L’élément est découpé en modules pour la programmation Produit risque de devenir complexe Maintenance difficile R. Marouane

35 5. Le Modèle en W R. Marouane Définition des Besoins Bruts
Orientation pour les Spécifications Conception de Haut Niveau Maquettes ou Prototypes Vérification des Flux Logiques R. Marouane

36 5. Le Modèle en W Enrichissement du modèle en V
Identification des orientations solides pour la conception Exploration d’une nouvelle technique Validation et expérimentation de plusieurs prototypes ou maquettes R. Marouane

37 6. Le Modèle de Développement Évolutif
Détermination des Besoins Programmation Expérimentation R. Marouane Version n

38 6. Le Modèle de Développement Évolutif
Construction progressive du système de façon participative Complexité ou absence de spécifications claires et bien définies Obtention d’une nouvelle version à chaque cycle Arrêt du processus itératif quand le client est satisfait R. Marouane

39 6. Le Modèle de Développement Évolutif
Prototypage... Modèle réduit d'un système, partiellement réalisé et fonctionnel, pas robuste et lent, destiné à montrer ce qu'on va faire aux clients et à expliquer aux développeurs les problèmes qu'on rencontre. développement itératif Développement dans lequel on crée rapidement un prototype de l'application destiné aux utilisateurs, pour qu'ils puissent préciser les spécifications, ce qui permet de fournir un prototype plus élaboré, pour converger ainsi vers l'application finale. R. Marouane

40 6. Le Modèle de Développement Évolutif
Identification des besoins Construction d’un prototype Prototype initial Utilisation du prototype (analyse des besoins) Oui Utilisateur satisfait Non Prototype opérationnel Prototype amélioré REVISION ET AMELIORATION R. Marouane

41 7. Le Modèle de la Spirale R. Marouane …dernier cycle cycle2 6 cycle1
installation Test et 2 5 4 3 Développement de la version finale R. Marouane

42 7. Le Modèle de la Spirale Même principe que le modèle itératif
Nécessité d’une relation contractuelle entre le développeur et l’utilisateur Chaque cycle donne lieu à une contractualisation préalable s’appuyant sur les besoins exprimés à l’étape précédente Développement de la version finale au dernier cycle R. Marouane

43 Découpage Temporel Spécifique
Le Cycle RAD Méthode de Développement Rapide: RAD Objectif: Développer une application de qualité et dans des délais réduits Travaux Préparatoires Session Participative Structure d’une phase Travaux de Conclusion R. Marouane

44 Découpage Temporel Spécifique
Le Cycle RAD Combine les modèles en Cascade et en Spirale Initialisation Expression des Besoins Conception Le Cycle RAD Construction n fois (sous time box): Limite le nombre de Cycles dans une Enveloppe temps à ne pas dépasser Mise en œuvre R. Marouane

45 Découpage Temporel Spécifique
Le Cycle ERP Initialisation Description des Processus Formation aux Progiciels Analyse Processus/Progiciel Paramétrage Processus/Progiciel Prototypage Processus/Progiciel validation Simulation en grandeur réelle R. Marouane Fermeture des Trous Fonctionnels

46 Découpage Temporel Spécifique
Le Cycle ERP Mise en place d’un progiciel de gestion intégré (Enterprise Resource Planning) Découpage spécifique Construction d’un système en tirant le meilleur parti du progiciel Le système doit améliorer la performation de l’entreprise Validation par le comité de pilotage par une simulation en grandeur réelle R. Marouane

47 Découpage Temporel Spécifique
Le Modèle RUP Combine plusieurs modèles 4 étapes: incubation, élaboration, construction, transition 6 activités: étude des besoins, analyse, conception, implémentation, tests, déploiement présentent dans toutes les étapes mais à des degrés différents Plusieurs itérations: une itération correspond à un cycle qui réunit les activités dans une étape R. Marouane

48 Phases, Activités,Itérations
Création Élaboration Construction Transition Besoins Analyse Conception Implémt. Tests R. Marouane ……… ……… Ité 1 Ité 2 ………… Ité i Ité n Itérations

49 Cycle par rétro ingénierie
Évaluation des Éléments en stock Éléments à remplacer ou nouveaux Éléments à retraiter Retraitement manuel Retraitement automatique Cycle nominal Cycle nominal Intégration R. Marouane

50 Cycle par rétro ingénierie
Cycle de développement par Rétro-ingénierie du logiciel * Sachant que le coût moyen des modifications apportées au logiciel pendant toute la période de maintenance augmente avec l’âge du logiciel * Architecture et Interface se saturent * Documentation technique se délite * Équipes de développement et de maintenance ont été renouvelées plusieurs fois Récupérer une partie de ce qui a été fait en le modernisant Politique de réutilisation Produit risque de devenir complexe Maintenance difficile R. Marouane

51 L’Estimation des Charges
ISEFC 2009/2010 L’Estimation des Charges R. Marouane

52 L’estimation des Charges Définitions
Charge: Quantité de travail nécessaire indépendamment du nombre de personnes qui vont réaliser ce travail Coût Prévisionnel Jour- Personne: JP Mois- Personne: MP Année- Personne: AP 1MP représente l’équivalent du travail d’une personne pendant un mois, en général 20 jours R. Marouane

53 L’estimation des Charges Taille - Durée
Petit C < 6MP Moyen 12 < C < 30MP Grand 30 < C < 100MP Très Grand C > 100MP Durée: Elle dépend du nombre de personnes. 60 MP P pendant 60 Mois (5ans) 5 P pendant 12 Mois 10 P pendant 6 Mois 60 P pendant 1 Mois R. Marouane

54 L’estimation des Charges Niveaux d’estimation
Niveau Projet Projet : charge complète (MP ou AP) Déterminer une enveloppe budgétaire Voir l’importance du projet Faire une estimation de la rentabilité de l’investissement Évaluer une durée vraisemblable du projet R. Marouane

55 L’estimation des Charges Niveaux d’estimation
Niveau Étape Étape : charge spécifique (MP ou SP) Ajuster le découpage : parties indépendantes Sous- traiter des parties Prévoir des délais (ordonnancement) Prévoir des ressources (planification) Niveau Phase Planifier précisément Calendrier de remise des livrables Suivre le projet et surveiller les écarts Affecter les ressources Niveau Tâche Indispensable pour le suivi du travail de l’équipe R. Marouane

56 METHODES D’ESTIMATION Les Non- Méthodes
Parkinson Sans évaluation Aléatoire Consomme toutes les ressources disponibles Temps et Hommes 2. Compétitive Diminuer les prix pour remporter le marché Utilisé dans les Appels d’Offre Non réaliste et subjective Grand risque de pertes R. Marouane

57 METHODES D’ESTIMATION Les Méthodes
Il existe 3 familles de méthodes fondées sur: le jugement d’experts la répartition proportionnelle l’utilisation d’un modèle économétrique Les modèles sont basés sur une unité d’œuvre qui permet de répartir des coûts simplement: le m2 , la commande, la pièce, la ligne, la taille,le nombre de fonctions, les entrées…. R. Marouane

58 Schéma Général de l’Estimation des charges
METHODES D’ESTIMATION Les Modèles Schéma Général de l’Estimation des charges à base de modèles Dénombrement des Unités d’oeuvres Application des Poids Standards Application des Facteurs Correcteurs Charge Ajustée R. Marouane

59 METHODES D’ESTIMATION Jugement d’Experts
Baptisée Delphi (1948) Utilisée dans plusieurs domaines Adaptée au niveau projet Analogie avec des projets antérieurs (internes et externes) Influence de l’environnement du projet taille de l’entreprise, nombre de décideurs, organisation,… R. Marouane

60 METHODES D’ESTIMATION Jugement d’Experts
ETAPES Chaque expert propose une estimation en utilisant sa propre expérience Tous les jugements sont rendus publics mais restent anonymes Réflexion individuelle en fonction des différentes valeurs (confirmation ou modification) Affichage des nouvelles estimations et justification de chaque expert Révision d’estimation Itération jusqu’au consensus R. Marouane

61 METHODES D’ESTIMATION Jugement d’Experts
Variantes de DELPHI Mode de communication entre experts (oral, écrit, rapproché, à distance) Nombre de cycles de prévision Conduite de la discussion (avec ou sans animateur) Dimension individuelle dépassée Confrontation collective donc objective R. Marouane

62 METHODES D’ESTIMATION Répartition Proportionnelle
Approches Approche descendant Estimation de la charge globale Répartition dans le temps Approche ascendante Évaluation d’une étape Déduction de la charge des autres étapes Approche dynamique Déroulement du projet Évaluation du temps consommé en amont Estimation des étapes suivantes R. Marouane

63 METHODES D’ESTIMATION Répartition Proportionnelle
Principe: Charge est proportionnelle à la taille du logiciel Charge est proportionnelle aux étapes et aux phases Charge est fonction: Nombre de sites Complexité des programmes Caractéristiques techniques Caractéristiques organisationnelles Caractéristiques humaines R. Marouane

64 METHODES D’ESTIMATION Répartition Proportionnelle
Calcul des charges: N = nombre d’interlocuteurs i = {1..N} Poids d’un interlocuteur Pi = {0,5..3} Charge de l’étude de l’existant Somme = { Pi } Étude Préalable Étude de l’existant 30% - 40% Conception 50% - 60% Appréciation 10% R. Marouane

65 2 fois l’étude détaillée
METHODES D’ESTIMATION Répartition Proportionnelle Exemple: Nombre d’interlocuteurs N=13 3 personnes [0.5 jour] 5 personnes [2 jours] 5 personnes [3 jours] Somme des poids = (3*0,5)+(5*2)+(5*3) = 26,5 jours =1Mois P É R T É U L D A E B L E Étude de l’existant 30% - 40% Conception 50% - 60% Appréciation 10% Étude Détaillée 25% Étude Technique 15% Réalisation 2 fois l’étude détaillée PROJET R. Marouane

66 2 fois l’étude détaillée
METHODES D’ESTIMATION Répartition Proportionnelle Exemple: Nombre d’interlocuteurs N=13 3 personnes [0.5 jour] 5 personnes [2 jours] 5 personnes [3 jours] Somme des poids = (3*0,5)+(5*2)+(5*3) = 26,5 jours =1Mois P É R T É U L D A E B L E Étude de l’existant 30% - 40% 1Mois Conception 50% - 60% 1Mois 1/2 Appréciation 10% 1Semaine Étude Détaillée 25% 7Mois1/2 Étude Technique 15% 4Mois 1/2 Réalisation 2 fois l’étude détaillée 15 Mois PROJET 30Mois 3M R. Marouane

67 METHODES D’ESTIMATION Répartition Proportionnelle
Étape Charge Durée Incubation 5% 10% Élaboration 20% 30% Construction 65% 50% Transition Étape Ratio Étude Préalable 10% du total du projet Étude Détaillée 20% à 30% du total du projet Étude Technique 5% à 15% de la charge de réalisation Réalisation Deux fois la charge d’étude détaillée R. Marouane

68 METHODES D’ESTIMATION COCOMO
COnstructive COst MOdel: B. Boehm (1981) Unité d’œuvre: Nombre de Milliers d’Instructions Sources Livrées (KISL) a,b,c,d sont générées à partir de l’expérience Mode: Catégorie du projet Charge en MP = a (KISL) b Délai normal en M = c (Charge) d R. Marouane

69 METHODES D’ESTIMATION COCOMO
MODES SIMPLE: - Taille ~ 50 KISL - Spécifications stables - Équipe réduite - Domaine classique MOYEN: - Taille entre 50 et 300 KISL - Intermédiaire en simple et complexe COMPLEXE: - Taille > 300 KISL - Spécifications instables - Grande équipe - Domaine nouveau R. Marouane

70 METHODES D’ESTIMATION COCOMO
Type de Projet Charge en MP Délai en M Simple Charge=2,4(KISL)1,05 D=2,5(Charge)0,38 Moyen Charge=3(KISL)1,12 D=2,5(Charge)0,35 Complexe Charge=3,6(KISL)1,2 D=2,5(Charge)0,32 EXEMPLE: Un projet simple visant à développer un logiciel estimé à instructions sources: Charge = 2,4 (40)1, = 116 MP Délai = 2,5 (116)0,38 = 12 Mois Taille moyenne de l’équipe = 116/12 = 9 personnes R. Marouane

71 METHODES D’ESTIMATION COCOMO
Économie d’échelle: Exposant < 1 (Industrie manufacturière) Plus on produit, plus le coût unitaire d’un produit diminue Dés économie d’échelle: Exposant >1 (Industrie du Logiciel) Plus on produit, plus le coût unitaire d’une ligne augmente (Loi des rendements décroissants) R. Marouane

72 Influence des caractéristiques
METHODES D’ESTIMATION COCOMO Influence des caractéristiques Chaque projet se distingue par des caractéristiques qui influencent la charge Chaque caractéristique se traduit par un coefficient de pondération appelé: facteur correcteur Le facteur est obtenu de façon statistique Classes de Facteurs: PRODUIT PERSONNEL MATERIEL PROJET R. Marouane

73 METHODES D’ESTIMATION COCOMO
PRODUIT Fiabilité (RELY) Degré de régularité exigé Base de Données (DATA) Volume de données en octets Taille du produit en lignes Complexité (CPLX) Algorithmes complexes Temps d’Exécution (TIME) Temps de réponse exigé R. Marouane

74 METHODES D’ESTIMATION COCOMO
PESONNEL Compétence des Concepteurs (ACAP) Degré de savoir-faire des concepteurs Expérience des Concepteurs (AEXP) Nombre d’années d’expérience dans la conception Compétence des Développeurs (PCAP) Degré de savoir-faire des développeurs Connaissance de l’Environ. (VEXP) Degré de savoir-faire dans l’environnement technique Expérience dans le Langage (LEXP) Nombre d’années de connais- sance du lg. de programmation R. Marouane

75 METHODES D’ESTIMATION COCOMO
MATERIEL Taille Mémoire (STOR) Besoin d’optimiser la mémoire Stabilité de l’E (VIRT) Logiciels de Base stables DispMach.Test(TURN) Degré de disponibilité Matériel PROJET Uti. d’une Méthode (MODP) Degré d’adaptation à une Méthode Uti. d’un AGL (TOOL) Degré d’adaptation à un AGL Contr. Délai (SCED) Relatif au délai normal R. Marouane

76 METHODES D’ESTIMATION COCOMO
Type de Projet Charge en MP Nominale Délai en M Simple ChargeN=3,2(KISL)1,05 D=2,5(ChargeD)0,38 Moyen ChargeN=3(KISL)1,12 D=2,5(ChargeD)0,35 Complexe ChargeN=2,8(KISL)1,2 D=2,5(ChargeD)0,32 Charge pondérée Charge de Maintenance ChargeD=ChargeN*FAE ChargeM = ACT * ChargeD FAE= π fi i={1..15} NBP = ChargeM / 12 R. Marouane ACT= Annuel Change Traffic

77 METHODES D’ESTIMATION COCOMO
ETAPES Estimation du nombre d’instructions sources Calcul de la charge nominale ou brute Sélection des facteurs correcteurs Application des facteurs correcteurs à la charge nominale Évaluation du délai Déduction du nombre de personnes Répartition par phase et par activité R. Marouane

78 METHODES D’ESTIMATION COCOMO
Exercice Soit un Projet de ISL en mode complexe RELY, STOR, TURN sont très faibles DATA, TIME, VEXP sont faibles CPLX, TOOL, SCED sont forts AEXP, MODP, ACAP sont très forts Les autres facteurs sont moyens ACT=20% R. Marouane

79 METHODES D’ESTIMATION COCOMO
Très Faible Faible Moyen Fort Très Fort Exceptionnel RELY 0,75 0,88 1 1,15 1,40 DATA 0,94 1,08 1,16 CPLX 0,70 0,85 1,30 1,65 TIME 1,11 1,66 STOR 1,06 1,21 1,56 VIRT 0,87 TURN 1,07 ACAP 1,46 1,19 0,86 0,71 AEXP 1,29 1,13 0,91 0,82 PCAP 1,42 1,17 VEXP 1,10 0,90 LEXP 1,14 0,95 MODP 1,24 TOOL 0,83 SCED 1,23 1,04 R. Marouane

80 METHODES D’ESTIMATION Méthode des Points de Fonction
A. Albrecht (1979) (IBM) 5 Unités d’œuvre: Les fonctions du futur système ou composants fonctionnels Aspect Statique d’un SI GDI Groupe de Données Interne (Entités, Associations,…) GDE Groupe de Données Externes (Autres Domaine, Application) Aspect Dynamique d’un SI Entrées Déclencheur de traitements (écran de saisie, données externes,…) Sorties Données visualisées, imprimées, envoyées à d’autres applications Interrogations Demandes d’interrogation saisies ou provenant d’une autre application R. Marouane

81 METHODES D’ESTIMATION Méthode des Points de Fonction
Évaluation de la complexité de chaque composant Calcul des Points de Fonctions Bruts PFB Détermination des Caractéristiques Générales du Système: CGS Déduction du Degré d’Influence Total: DIT Génération du Facteur d’Ajustement: FA Calcul des Points de Fonctions Ajustées: PFA Déduction de la taille du projet en ISL R. Marouane

82 METHODES D’ESTIMATION Méthode des Points de Fonction
Complexité et Points de Fonctions Bruts Évaluation de la complexité de chaque composant en utilisation les tableaux (XXIII-XXVII) PFi où i={1..5} Génération du total PFB à l’aide du tableau (XXVIII) PFB=∑ PFi i={1..5} Détermination des CGS Inexistante ou sans influence 3 Influence moyenne 1 Influence secondaire 4 Influence importante 2 Influence restreinte 5 Influence intensive partout R. Marouane

83 METHODES D’ESTIMATION Méthode des Points de Fonction
Caractéristiques Générales du Système Communication des données Aucune communication: 0 Plusieurs protocoles de communication: 5 Distribution des données ou des traitements Pas de répartition: 0 Répartition dynamique: 5 Contrainte de performance Aucune exigence: 0 Performance élevée est exigée: 5 Intensité d’utilisation de la configuration matérielle Installation pas très utilisée: 0 Contraintes d’utilisation du matériel variées: 5 Taux de transaction Aucune période de pointe: 0 Plusieurs périodes de pointe: 5 Saisie interactive Traitements par lots: 0 Plus de 30% des transactions sont interactives: 5 Convivialité Aucune fonction de convivialité: 0 Plus de six fonctions sont demandées: 5 R. Marouane

84 METHODES D’ESTIMATION Méthode des Points de Fonction
Caractéristiques Générales du Système Mise à jour en temps réel des GDI Aucune: 0 Tous les principaux GDI avec des mécanismes de protection et de restauration: 5 Complexité des traitements Aucun traitement: 0 Tous les types de traitement sont complexes: 5 Réutilisation Aucune réutilisation: 0 Application est conçue multi utilisation, la personnalisation est paramétrée: 5 Facilité d’installation Aucune exigence particulière: 0 Outils automatisés de conversion et d’installation sont nécessaires: 5 Facilité d’exploitation Exploitation totalement autonome sans aucune intervention: 5 Portabilité Plans de maintenance multi site sont exigés pour des environnements différents: 5 Facilité d’adaptation Cinq points: 5 R. Marouane

85 METHODES D’ESTIMATION Méthode des Points de Fonction
Procédures de génération de la taille DIT = ∑ DIi avec i={1..14} Projet sans contrainte: DIT=0 Projet complexe : DIT=5*14=70 FA = 0,65 + DIT/100 PFA = FA * PFB Points de Fonction Ajustés Tableau (XXIX) permet de générer la taille du projet en ISL Utilisation d’une méthode d’estimation de charge (par exemple COCOMO) R. Marouane

86 METHODES D’ESTIMATION Méthode des Points de Fonction
Procédures de génération de la charge A partir des PFA, on obtient la taille Puis utilisation d’une méthode d’estimation de charge (par exemple COCOMOII) Détermination de la charge en convertissant directement les PFA. Étude préalable: 2, 3 ou 4 jours par PFA selon importance projet Étude détaillée: 1 à 2 jours par PFA selon l’environnement Si L4G 1JP / 10PFA Si RAD 0,5 JP / PFA Exemple: EP: Un projet de 90 PFA JP en environnement grand système et 80 JP en environnement C/S R. Marouane

87 METHODES D’ESTIMATION Méthode des Points de Fonction
Exercice Soit un projet ayant les spécifications suivantes: Ces valeurs correspondent à des moyennes extraites du cahier de charge Complexité des GDE: 8 types et 70 champs Complexité des GDI: 5 types et 40 champs Complexité des ENT: 5 tables et 15 champs en entrée Complexité des SOR: 3 tables et 35 champs en sortie Complexité des INT: 2 tables et 14 données interrogées Les Caractéristiques Générales du Système: DI Inexistant DI Secondaire 3, 10,13 DI Restreint DI Moyen 11, 4, 7 DI Important , 8, 9, DI Intensif R. Marouane

88 METHODES D’ESTIMATION Méthode des Points de Fonction
Correction Exercice GDE: Complexe PF1=10 GDI: Moyen PF2=10 ENT: Complexe PF3=6 SOR: Complexe PF4=7 INT: Moyen PF5=4 PFB=∑ PFi = 37 DIT = ∑ DIi =(1*0)+(1*1)+(3*2)+(1*3)+(3*4)+(5*5) =47 FA = 0,65 + DIT/100 = 0, /100=1.12 PFA = FA * PFB = 1.12*37=41,44 En utilisant le tableau XXIX: En C : taille = 150*41,44 = 6216 ISL En ADA : taille = 71*41,44 = 2942 ISL Charge de l’étude détaillée = 41,5 JP et 83 JP en fonction de l’environnement. Si L4G : JP Si RAD: JP R. Marouane

89 La Gestion de la Qualité
ISEFC 2009/2010 La Gestion de la Qualité R. Marouane

90 Approche Qualité Définitions
Manière d’être d’un logiciel. Ce terme est applicable à un ensemble d’attributs distinctifs qui indiquent le degré d’excellence d’un aspect du logiciel. Chacun de ces attributs est reconnu au moyen de ses caractéristiques. Métrique Mesure qualitative ou quantitative d’une caractéristique d’un logiciel. R. Marouane

91 Approche Qualité Démarche suivie
L ’étude de la qualité du logiciel doit être envisagée selon trois aspects :  Les attributs qui la qualifient  Les caractéristiques qui identifient ces attributs  Les points vérifiables qui évaluent d ’une manière subjective ces caractéristiques R. Marouane

92 Approche Qualité Les attributs d’un logiciel
Compréhensibilité Facilité avec laquelle on peut comprendre la fonction d’un programme et la façon de la réaliser en lisant le programme source et sa documentation. Fiabilité Capacité qu’a un programme d’exécuter correctement toutes ses structures, pour répondre aux besoins de l’usager et être compris par le concepteur. Commodité Facilité d’utilisation d’un logiciel. Pour qu’un logiciel soit commode ou facile à utiliser, il faut qu’il soit : résistant à toute tentative de mauvaise utilisation accessible à l’usager (bonne interaction homme/ machine) Rapide à l’exécution R. Marouane

93 Approche Qualité Les attributs d’un logiciel
Portabilité Facilité avec laquelle un programme peut s’adapter à un nouvel environnement. Flexibilité Facilité avec laquelle on peut modifier correctement un programme. Testabilité Facilité avec laquelle on peut démontrer l’exactitude d’un programme au moyen d’un test. Efficacité Capacité d’exécution des structures qui composent un programme, sans gaspillage des ressources de la machine (mémoire centrale, mémoire secondaire, canaux de communication, temps d’exécution, etc.) R. Marouane

94 Approche Qualité Les caractéristiques d’un logiciel
Lisibilité Facilité pour l’usager à reconnaître les structures d’un programme, à l’aide de la documentation interne. Un programme lisible peut être lu sans fatigue et sans ennui. Modularité Pertinence de la fonction de chaque module ainsi que de ses interactions avec les autres modules. Concision Caractéristique d’un programme ou d’un module ne contenant que les informations nécessaires et suffisantes (absence d ’excès d’informations). R. Marouane

95 Approche Qualité Les caractéristiques d’un logiciel
Cohérence Interne: Uniformité d’un programme dans sa notation, sa terminologie et son symbolisme. Externe: Correspondance entre le contenu d’un programme d’une part, et les spécifications et la documentation d’autre part. Intégrité Caractéristique d’un programme dont toutes les composantes sont présentes, et dont chacune est entièrement développée. Résistance Caractéristique qui permet au programme de pouvoir continuer son traitement malgré quelques violations des hypothèses de ses spécifications. R. Marouane

96 Approche Qualité Les caractéristiques d’un logiciel
Exactitude Précision que doivent avoir les sorties du programme pour correspondre aux résultats attendus. Simplicité Caractéristique qui permet après lecture des énoncés d’un programme, de comprendre et d’en retracer mentalement la logique du programme, la structure des données et les interactions modulaires. Interactivité Caractéristique qui permet au programme de faciliter la spécification des entrées et de fournir des sorties dont la forme et le contenu sont utiles et faciles à saisir. R. Marouane

97 Approche Qualité Les caractéristiques d’un logiciel
Efficience Caractéristique par laquelle le programme peut effectuer sa tâche sans gaspillage de ressources (mémoire centrale, mémoires secondaires, canaux de communication et temps d’exécution). Universalité Transparence d’un programme à son environnement matériel; en d’autres termes, l’universalité suppose que le programme soit le plus indépendant possible des environnements matériels où il est susceptible d’être exécuté. R. Marouane

98 Caractéristiques Attributs Attributs Lisibilité Compréhensibilité
Modularité Concision Flexibilité Fiabilité Cohérence Intégrité Testabilité Résistance Commodité Exactitude Efficacité Simplicité Portabilité Interactivité Efficience Attributs Attributs R. Marouane Universalité

99 Répondre à une demande d’intervention
Conduire un Projet C L I E N T Demande Répondre à une demande d’intervention Proposition Définir et Contrôler la qualité Développer et/ou Exploiter Planifier et Suivre Accord Normes Planning Besoin du client Plan qualité Réali- sations Suivi Réalisations R. Marouane

100 Approche Qualité Définition Générale de la Qualité AFNOR
«La qualité est l’ensemble des propriétés et caractéristiques d’un produit ou d’un service qui lui confère l’aptitude à satisfaire un besoin exprimé ou implicite » Besoins exprimés : Produit conforme aux spécifications Délais respectés Utilisateur satisfait Besoins implicites : Produit fiable Documentation claire Objectif Identifier et « expliciter » les besoins implicites du client. R. Marouane

101 Approche Qualité Les documents de la qualité
Le Manuel Qualité: recense les dispositions générales prises par l’entreprise pour assurer la qualité de ses prestations. Le Plan Qualité Standard: précise les dispositions décrites dans le manuel Qualité par secteur d’activité de l’entreprise Le Plan Qualité: est une adaptation du Plan Qualité Standard aux spécificités d’un projet. R. Marouane

102 Spécification projet Plan qualité standard Besoins exprimés
par le client * Plan Qualité  décrivant les engagements des différentes parties (Clients et prestataires) en matière de qualité * Plan de contrôle  Planning des actions qualité à mener * Liste de contrôle  Liste des points à contrôler pour chaque élément du projet soumis à un contrôle qualité Définir la Qualité R. Marouane

103 Définir la Qualité Besoins Adapter le plan qualité standard
Spécifications projet Valider ébauches DP CP Rédiger le PQ Valider le PQ IQ Plan Qualité client équipes R. Marouane

104 Définir la Qualité But: Intervenant: Démarche 1er temps:
Adapter le plan qualité standard But: Fournir les ébauches du PQ (selon exigences clients et de l’équipe de développement) Intervenant: Ingénieur qualité avec éventuellement : D.P, C.P Démarche 1er temps: 1) Standard de présentation des documents 2) Liste exhaustive de toutes les réalisations de la phase à venir. Exemple: dossier d’étude technique 3) Liste indicative des réalisations des phases ultérieures. Exemple: programme, manuel utilisateur,.. R. Marouane

105 ... Définir la Qualité Démarche 2ème temps : Résultat :
Adapter le plan qualité standard ... Définir la Qualité Démarche 2ème temps : Pour (2) - Plan type s’il s’agit de document - Liste des points à contrôler Pour (3) - Plan type (éventuellement) - Point à contrôler (d’une manière générale) Résultat : - Ebauches du plan de contrôle - Ebauches de listes de contrôles R. Marouane

106 Définir la Qualité But : Intervenant : Démarche : Résultat :
Valider ébauches But : S’assurer que les contrôles par l’IQ sont compatibles avec le plan développement Intervenant : Directeur de projet, Chef de projet, Ingénieur qualité. Démarche : - Présentation par l’IQ des ébauches du P.C et des L.C - Correction éventuelle - Estimation de la charge des actions de qualité - Mise à jour du planning du projet - Conditions matérielles : locaux, matériel, logiciel Résultat : - Ebauches validées - Planning prévisionnel des actions de qualité R. Marouane

107 Définir la Qualité But : Intervenant : Démarche : Résultat :
Rédiger le PQ But : Affiner les ébauches du PQ et rédiger un document complet, validé par le client. Intervenant : Ingénieur qualité. Démarche : - Intégration des corrections (suite validation) au P.C et aux L.C - Spécifications : actions qualité pour le suivi du projet, procédures d’évolution du PQ, dispositions à prendre concernant le contrôle fournisseur, procédures détaillées de contrôle qualité - Adaptation du plan qualité Résultat : - Plan qualité R. Marouane

108 Définir la Qualité But : Intervenant : Démarche : Résultat :
Valider le PQ But : Valider les engagements contractuels du PQ Intervenant : Directeur de Projet Démarche : - Vérifier que les engagements du PQ ne s ’opposent pas à d ’autres engagements - Evaluation du coût des actions de qualité - Inclure les actions qualité dans le planning détaillé du projet Résultat : - Plan qualité validé et prêt à être remis au client R. Marouane

109 * Vérifier l’application du plan Qualité
Contrôler la Qualité Plan de contrôle Liste des contrôles * Vérifier l’application du plan Qualité * Contrôler la qualité des réalisations Objet: * S’assurer que les dispositions du PQ sont appliquées et comprises par l’équipe de développement * Assister les intervenants en leur fournissant les explications nécessaires à la bonne application du PQ. Objet: * S’assurer que les réalisations respectent les dispositions du PQ R. Marouane

110 Contrôler la Qualité Plan de contrôle Préparer le contrôle Contrôler
Réalisation Contrôler la Qualité Plan de contrôle Préparer le contrôle Contrôler Application PQ Contrôler l’application du plan Liste des contrôles réalisés Liste des contrôles Réalisation Plan de contrôle Réalisation Préparer le contrôle Contrôler la qualité Contrôler la qualité Liste des contrôles IQ Préparer recette Liste des contrôles réalisés R. Marouane CP

111 Contrôler l’application du PQ
Préparer le contrôle Contrôler l’application du PQ But - Mettre les éléments à contrôler à la disposition de l’IQ Intervenant: - Bibliothécaire Démarche: - S’assurer de l ’avancement des réalisations pour lesquels contrôle est prévu. Identifier les éléments à contrôler (programme, documents, dossier,..) et les mettre à la disposition de l’I.Q - Informer l’IQ des éventuels retards pour MAJ du P.Q Résultat: - Elément à contrôler remis à l’IQ. R. Marouane

112 Contrôler l’application du PQ
du plan But: Vérifier l’application des dispositions du PQ. Intervenant: I.Q Démarche : A partir de la L.C et des éléments à contrôler il s’agit : - de mettre à jour la L.C :Résultat du contrôle de chaque point, Résultat global du contrôle (positif, négatif), Annotations et Obs. - de proposer évent. des modifications dans la gestion du projet Résultat : - Réalisations contrôlées conformément au PQ - Liste des contrôles mises à jour - Résultats du contrôle transmis aux intéressés R. Marouane

113 Plan Type de Plan Qualité
1) But, Domaine d’Application et Responsabilité 2) Documents applicables et documents de référence 3) Terminologie 4) Organisation 5) Démarche de développement 6) Documentation 7) Gestion de la configuration 8) Gestion des modifications 9) Méthodes, outils et règles 10) Contrôle des fournisseurs 11) Reproduction, Protection, Livraison 12) Suivi de l’application du plan qualité Plan Type de Plan Qualité R. Marouane

114 Contrôler la Qualité But : Intervenant : Démarche : Résultat :
Préparer le contrôle But : - Mettre les éléments à contrôler à la disposition de l’IQ Intervenant : - Bibliothécaire Démarche : - S’assurer de l ’avancement des réalisations pour lesquels un contrôle est prévu. - Identifier les éléments à contrôler (programme, documents, dossier,..) et les mettre à la disposition de l’I.Q - Informer l’IQ des éventuels retards pour MAJ du P.Q Résultat : - Elément à contrôler remis à l’IQ. R. Marouane

115 Contrôler la Qualité But: Intervenant: Démarche: Résultat :
- Contrôler la qualité des réalisations conformément au P.Q et L.C Intervenant: - I.Q Démarche: - Mise à jour de la L.C: Résultat de contrôle (par point et global) et observations et annotations - Proposition des modifications dans la gestion du projet - Mise à jour du plan de contrôle * Reprise du contrôle (si résultat négatif) Résultat : - les réalisations respectant les dispositions du PQ - P.C et L.C MAJ R. Marouane

116 Exemple : dossier de programmation
Document établi au début du projet et peut être complété au fur et à mesure de l’avancement des réalisations : Le Plan de Contrôle Plan de contrôle Entreprise X Projet :...…. Date:…/…/... DP :……………… CP : ……………... Client Page Phase : ………………… Etape : ………………… Date Numéro de contrôle Elément à contrôler Visa IQ Prév Réal Exemple : dossier de programmation R. Marouane

117 * Numéro du contrôle : donné sur le plan de contrôle
La liste de Contrôle Document détaillant les contrôles à réaliser pour chaque élément du P.C : * Numéro du contrôle : donné sur le plan de contrôle * Phase, étape et tâche : selon guide méthodologique adopté * Elément contrôlé : nom figurant sur le plan de contrôle * Point contrôlé : liste des vérifications à faire (respect des normes de programmation, respect du plan type pour un document,..) * +/- : résultat pour chaque point contrôlé * Résultat du contrôle : - positif, - positif avec réserve (contrôle jugé positif après modification décrite dans « observation et réserves »), - négatif : les raisons du refus et les actions à entreprendre sont indiquées dans le cadre « observation et réserves » * Visa contrôle qualité : Signature de l’IQ après contrôle R. Marouane

118 - N° + Liste de contrôle Date Entreprise X Projet :…...…. DP :……………...
CP : ……………... Page Client Identification de contrôle Phase : ………………… Etape : ………………… Tâche :…………….. Elément contrôlé : ………………………………. - Point contrôlé + Résultat du contrôle positif positif avec réserve négatif Observations et réserves : R. Marouane Visa contrôle qualité Visa directeur du projet

119 Le Management des Risques
ISEFC 2009/2010 Le Management des Risques R. Marouane

120 Management des Risques Définitions
Probabilité qu’un évènement indésirable ait lieu. Conséquences financières d’un évènement redouté et sa fréquence probable. Gestion proactive des risques Minimiser les effets négatifs des événements Risque = Coût des conséquences d’un évènement x fréquence de cet évènement R. Marouane

121 Management des Risques Définitions
Risque dans le développement des systèmes d’informations C’est la possibilité qu’un projet ne s’exécute pas conformément aux prévisions: de dates d’achèvement, de coût, de spécifications. Ces écarts par rapport aux prévisions étant considérés comme difficilement acceptables voire inacceptables. Processus Projet R. Marouane

122 Management des Risques Définitions
Processus - n’aboutit pas - a consommé trop de ressources - a duré trop longtemps Projet - ne remplit pas les fonctions attendues - n’est pas accepté par l’utilisateur - son fonctionnement coûte cher R. Marouane

123 Management des Risques Les différentes d’Approche
Les 3 sources d’échec: Mauvaise définition des besoins Mauvaise estimation des charges Présence de nombreux aléas Approches d’Analyse de Risques Approche Généralisée Approche par les Risques Approche par le Profil des Risques R. Marouane

124 Management des Risques Approche Généralisée
Application de la démarche d’Analyse de Risques utilisée dans d’autres domaines Identification des risques Évaluation de l’impact sur les coûts et le délai Définition des actions de réduction des risques Suivi des actions Capitalisation d’expérience Importance du rôle du chef du projet et du manager des risques R. Marouane

125 Management des Risques Approche Généralisée
AUDIT EN COURS DE PROJET: Prévision des Risques Critères de Réussite Poids du critère Implication des utilisateurs 19 Soutien de la hiérarchie 16 Définition claire des besoins 15 Plan de développement correct 11 Attentes réalistes 10 Découpage du projet en petites étapes 9 Compétences dans l’équipe de projet 8 Appropriation du projet par les acteurs du projet 6 Vision claire de la raison d’être et des objectifs 3 Productivité et motivation de l’équipe de projet 100 R. Marouane

126 Management des Risques Approche par les Risques
Critères Exemples Objectif Stratégie Commerce Électronique, GPAO,… Efficience Mise en place d’un Work-flow, paie,… Obligation Projet An 2000, Euro, Fusion Entrep.,… Cible Client Commande sur Internet, CRM,… Support Progiciel comptable,… Transversal Messagerie, Intranet, Syst. Bureautique.. Type solution Progiciel Applicatif CAO, Gestion Intégrée, GDE,… Développement Applicatif Site Web commercial, Gestion des Bourses,... Intégration Système Assemblage d’interfaces, de composants,.. Maintenance Evolut. Nouvelle version d’un logiciel interne,… Infrastructures Tech. Déploiement de réseau, sécurité,… R. Marouane

127 Management des Risques Approche par les Risques
Critères Risques Objectif Stratégie Faible implication de la DG, Changement de l’environnement Efficience Dérive technol., minimisation des coûts,… Obligation CC incomplet, non respect des délais,… Cible Client Mauvaise perception des attentes client,… Support Non remise en cause de l’existant, … Transversal Structuration inadéquate du projet, … Type solution Progiciel Applicatif Non pérennité du produit sélectionné, … Développement Applicatif Insuffisance du CC, manque de compétence ou de pérennité du prestataire Intégration Système Erreurs dans le choix des composants,… Maintenance Evolut. Absence ou indisponibilité des ressources humaines et documentaires Infrastructures Tech. Technologie incompatible avec la maturité technologique de l’entreprise,… R. Marouane

128 Management des Risques Approche par le Profil des Risques
Basée sur les facteurs de risque La taille du projet Perte de maîtrise du processus de production Équipe de taille élevée La difficulté technique Nouveauté technologique Contraintes de performance Le degré d’intégration Degré de dépendance et d’autonomie Implication de plusieurs projets, équipes, entités, acteurs,.. La configuration organisationnelle Étendue de l’entreprise Lourdeur des procédures et multiplicité des acteurs Le changement Risque de rejet du futur système Mauvaise définition du changement L’instabilité de l’équipe de projet Problème de transfert de connaissance Erreurs d’interprétation R. Marouane

129 Degré du Risque pour le Projet
Management des Risques Approche par le Profil des Risques Nature des Risques Degré du Risque pour le Projet Taille du projet Difficulté technique Degré d’intégration Configuration organisationnelle Changement Instabilité de l’équipe R. Marouane

130 L’Organisation des Projets
ISEFC 2009/2010 L’Organisation des Projets R. Marouane

131 Le périmètre du projet correspond à la délimitation précise du projet.
L’organisation des Projets 1. Périmètre du projet Le périmètre du projet correspond à la délimitation précise du projet. Pourqoui le périmètre du projet doit être délimité ? Délimiter les responsabilités Préciser l’engagement avec le client Eviter les risques de dérapage (délais & charges) Entretenir une bonne relation avec le client Exemple Pour un projet de Mise en place d'un ERP ou d’évolution d'un SI en fonction d'une nouvelle organisation: Périmètre total = identification et recensement des appl /mod. impactés par le projet. Pour un projet de développement : Périmètre total est défini par les specifications “Générales et particulières”. R. Marouane

132 L’organisation des Projets
1. Périmètre du projet Le projet peut être ensuite sub-divisé en sous projets possédant chacun son propre périmètre. Le lotissement du projet est le regroupement de sous projets entre eux. Chaque regroupement est un lot du projet. Les lots peuvent parfois se chevaucher dans le temps ou se paralléliser partiellement. S/P 3 S/P 4 LO1 Projet S/P 2 S/P 5 S/P 1 L’objectif d’un lot est de relier les modules/applications qui ont les interdépendances les plus fortes. R. Marouane

133 L’organisation des Projets
2. Equipe de Projet La réussite d’un projet passe par une organisation rigoureuse et efficace de l’équipe projet. ACTEURS DE L’EQUIPE PROJET SI MOA: C'est la maîtrise d'ouvrage, à l'origine de l'expression d'un besoin qui est l'objectif du projet à atteindre. Décrire le besoin dans un document (Cahier des Charges Fonctionnel ou spécifications Fonctionnelles). Préparer des cas de tests fonctionnels pour vérifier que les développements/paramétrages effectués par la MOE fonctionnent (réceptionner le produit) R. Marouane

134 L’organisation des Projets
2. Equipe de Projet MOE: C'est la maîtrise d'oeuvre, qui prend connaissance du besoin exprimé et qui tâche d'y répondre informatiquement. La MOE rédige un dossier de réponse au besoin, nommé parfois CDC technique (cahier des charges technique) ou dossier de paramétrage ou encore dossier de conception générale. La MOE se charge aussi de faire les développements/paramétrages nécessaires. R. Marouane

135 L’organisation des Projets
2. Equipe de Projet Acteurs: Responsable du projet: (MOA) Choisir en interne dans sa société les personnes adéquates au projet Recruter à l’extérieur si les ressources humaines en interne ne sont pas disponibles ou ne répondent pas aux exigences de compétence liées à la nature du projet Motiver son équipe en expliquant clairement les objectifs et l’importance du projet et en valorisant chaque membre de l’équipe Suivre les travaux et leurs avancements Chef de Projet: (MOE) Même rôle et même responsabilités auprès de son équipe que le responsable MAO Une collaboration efficace entre MOA et MOE est le gage de la réussite d'un projet R. Marouane

136 L’organisation des Projets
2. Equipe de Projet ETAPES: Déterminer le périmètre du projet Estimer la taille de l’équipe à impliquer dans le projet, c’est à dire déterminer une enveloppe de ressources Choisir les profils adéquats :l’équipe doit correspondre aux besoins du projet et doit être qualifiée. Necessité de complémentarité et d’équilibre des équipes projet entre : Les ressources dont les qualifications sont plutôt de nature fonctionnelles ou métier (MOA) Les ressources qui sont de nature techniques (MOE) R. Marouane

137 L’organisation des Projets
2. Equipe de Projet Equipe Externe Appeler des ressources extérieures dans le cadre d'un projet informatique Compléter les ressources internes et se doter de compétences complémentaires Les ressources externes sont 100% orientées projet Les ressources internes doivent souvent s'occuper en plus, de la gestion courante de l'entreprise Cabinet de Conseil Sociétés généralistes ou spécialisées (cabinets de conseil en organisation spécialisés dans la gestion de projet) En général : Profils des employés des cabinets de conseil sont plus fonctionnels qu'en SSI Ils peuvent fournir des équipes en AMOA (Assistance à Maîtrise d'ouvrage) sur un projet Ces sociétés apportent une assistance méthodologique dans la rédaction des livrables, dans le suivi des projets, dans la proposition de solutions alternatives en cas de difficultés (plans de secours) R. Marouane

138 L’organisation des Projets
2. Equipe de Projet Les SSII Ces entreprises ont des employés essentiellement avec des profils techniques ayant des spécialités (développeurs JAVA, développeurs PHP...) Ils peuvent fournir des équipes en AMOE (Assistance à Maîtrise d'oeuvre) sur un projet Les éditeurs de logiciels Il s’agit souvent d'anciens employés de cabinets de conseil qui décident de se lancer avec le statut d'indépendant Les Développeurs Indépendants Ce sont souvent d'anciens développeurs de SSI qui adoptent le statut d'indépendant Dans le cas du recours à des ressources extérieures et afin d'assurer des équipes homogènes, il faut assurer l’équilibre entre les ressources intérieures à l’entreprise et les ressources extérieures R. Marouane

139 L’organisation des Projets
3. Tâche, Jalon, Livrable Tâche Une tâche est une action à mener pour aboutir à un résultat Une tâche doit être assez courte (< ou = à 15 jours) A chaque tâche définie, il faut associer: Un objectif précis et mesurable Des ressources humaines, matérielles et financières adaptées Une charge de travail exprimée en nombre de journées homme Une durée ainsi qu’une date de début et une date de fin s peuvent fournir des équipes en AMOE (Assistance à Maîtrise d'oeuvre) sur un projet Dans le cadre du planning, les tâches sont reliées entre elles par des relations de dépendance Livrable : Un livrable est tout résultat, document mesurable, tangible ou vérifiable, qui résulte de l’achèvement d’une partie de projet ou du projet Exemples: Un cahier des charges , Une étude de faisabilité R. Marouane

140 L’organisation des Projets
3. Tâche, Jalon, Livrable Jalon Les jalons d’un projet se définissent comme : Des événements clé d’un projet, montrant une certaine progression du projet Des dates importantes de réalisation d’un projet Une réalisation concrète (production de livrables) Dans le cadre du planning, les jalons: limitent le début et la fin de chaque phase et servent de point de synchronisation Sur les diagrammes de GANTT, les jalons sont représentés par des losanges. R. Marouane

141 L’organisation des Projets
4. Planification d’un Projet Définition C’est l’activité qui consiste à : Déterminer et ordonnancer les tâches du projet Estimer leurs charges Et à déterminer les profils nécessaires à leur réalisation L’outil requis est le planning Les objectifs du planning sont les suivants : Déterminer des actions si les objectifs sont réalisés ou dépassés Suivre l’avancement du projet Affecter les ressources aux tâches R. Marouane

142 L’organisation des Projets
4. Planification d’un Projet L’Ordonnancement des Tâches: C’est l’élaboration d’un plan d’action permettant de déterminer : les séquencements ou au contraire les parallélismes possibles entre l’exécution des tâches précédemment identifiées Dans certains projets, une marge de flexibilité peut être aménagée par le chef de projet pour l’ordonnancement des tâches.  le chef de projet peut prévoir plusieurs scénarios possibles concernant l’ordonnancement des tâches En fonction de l’évolution du projet, un scénario d’ordonnancement des tâches peut être privilégié par rapport à un autre scénario Pour procéder à l’ordonnancement des tâches, il faut, pour chaque tâche élémentaire, lister les tâches antérieures, au vu des informations collectées sur le terrain et sélectionner les seules tâches immédiatement antérieures Le planning doit permettre l’identification de l’ordonnancement des tâches du projet R. Marouane

143 L’organisation des Projets
4. Planification d’un Projet Le Planning: Le planning correspond aux dates pour: réaliser les activités identifier les jalons atteindre les objectifs du projet Exemple: Le planning correspond aux dates pour: Elles dépendent du projet à entreprendre: Les étapes de mise en place d’un ERP sont : Étude préalable détaillée (définition du périmètre, cahier des charges fonctionnel ...) Dossier de Paramétrage Réalisation du paramétrage et/ou Programmation Conception des Jeux d’essai pour préparer la recette de l'application/du module Recette (Réalisation des tests informatiques) Rédaction des Manuels utilisateurs Mise en production R. Marouane

144 L’organisation des Projets
4. Planification d’un Projet Le Planning: Pour bâtir un planning, il faut associer à chaque tâche : Les dates au plus tôt (Début au plus tôt et Fin au plus tôt de l’exécution de la tâche) Les dates au plus tard (Début au plus tard et Fin au plus tard de l’exécution de la tâche) La durée de la tâche est le temps utilisé qui s’écoule entre le début et la fin de la tâche Chemin Critique: Le chemin critique correspond à la séquence de tâches qui détermine la durée totale du projet Tout retard affectant une tâche du chemin critique est intégralement répercuté sur la durée du projet et donc sa date de fin La tâche critique est une tâche du chemin critique. Toute modification sur la durée d’une de ces tâches critiques impacte d’autant plus la durée totale du projet. R. Marouane

145 L’organisation des Projets
4. Planification d’un Projet Les Marges: La marge est la possibilité qu’à une tâche d’être retardée sans impacter le projet. Les tâches qui sont sur le chemin critique ont une marge nulle. Estimation: Les estimations se font au niveau: Projet Phase Tâche Au niveau projet, il faut estimer la charge du projet complet par la détermination d’une enveloppe budgétaire Au niveau phase, il faut estimer la charge d’une phase spécifique, ajuster le découpage du projet et prévoir des ressources pour planifier l’affectation des intervenants Au niveau tâche, il faut estimer chacune des tâches qui font généralement l’objet d’une affectation individuelle R. Marouane

146 L’organisation des Projets
4. Planification d’un Projet Coût et Délai du Projet: Les coûts du projet doivent être évalués en fonction de leur nature : Coûts en matériel (locaux, ordinateurs, serveurs, logiciels ...) Coûts en ressources humaines internes Frais de déplacement Coûts personnel interne Coûts de prestataires extérieursBesoins en locaux, en ordinateurs, serveurs, logiciels ... Définition des besoins Définition des processus d’approvisionnement Etablissement des délais d’approvisionnement en fonction des fournisseurs Evaluation du temps de recrutement des ressources humaines Evaluation du temps nécessaire pour choisir le prestataire éventuel L’évaluation de ces durées est importante dans le calcul total de la durée du projet R. Marouane

147 L’organisation des Projets
5. Identification des Risques Evaluer les risques liés au projet Anticiper les dérapages et réagir au plus tôt Degré d’importance des risques Ceux qui pourraient entraîner de légers retards dans le planning Ceux qui bloquent la continuation du projet car appartenant au chemin critique Différents types de risque peuvent être identifiés : Humains (absence, décès d’une ressource importante sur le projet), Coûts cachés (découverte de coûts qui grèvent l’enveloppe budgétaire dédiée au projet), Retard dans les approvisionnements en matériaux indispensables au projet (risque de changement de la durée totale du projet), Retard dans la livraison des livrables, Technologiques (évolution de la technologie en cours de projet), Manque de communication et de coordination, Inadéquation des développements informatiques aux besoins exprimés R. Marouane

148 L’organisation des Projets
Les risques doivent être classés par ordre d’importance. Il faut déterminer les conséquences potentielles liées à ces risques en terme : d’impact financier d’impact de délai ou d’impact sur la qualité. En cas de soucis importants mettant en péril le projet, un plan de secours peut être appliqué. Ce dernier est établit lors de l’étude préalable et lorsque les risques majeurs ont été identifiés. R. Marouane


Télécharger ppt "GENIE LOGICIEL § CONDUITE DE PROJETS"

Présentations similaires


Annonces Google