https://baripedia.org/api.php?action=feedcontributions&feedformat=atom&user=Sania 2026-04-18T06:20:31Z Contributions MediaWiki 1.38.6 https://baripedia.org/index.php?title=Ma%C3%AEtrise_de_la_qualit%C3%A9_dans_les_projets_SI&diff=32343 2016-06-05T11:41:31Z

<p>Sania : </p> <hr /> <div>{{Infobox Lecture<br /> | image = <br /> | cours = [[Gestion de projet]]<br /> | faculté = [[Faculté d'économie et de management]]<br /> | département = [[Services généraux GSEM]]<br /> | domaine = [[Système d'information]]<br /> | professeurs = [[Jolita Ralyte]]&lt;ref&gt;[http://cui.unige.ch/~ralyte/ Page personnelle de Jolita Ralyte sur le site du CUI]&lt;/ref&gt;<br /> | années = <br /> | code = S204033 CR &lt;ref&gt;[http://wadme.unige.ch:3149/pls/opprg/w_det_cours.debut?p_code_cours=S204033&amp;p_plan_is=0&amp;p_langue=1&amp;p_frame=N&amp;p_mode=PGC&amp;p_annee=2015&amp;p_suffixe=&amp;p_grtri= Présentation du cours sur le site du catalogue de cours wadme]&lt;/ref&gt;<br /> | enregistrement = <br /> | précédent = <br /> | suivant = [[Estimation des charges]]<br /> }}<br /> <br /> &quot;La qualité est l'ensemble des propriétés et caractéristiques d'un produit ou service qui lui confère l'aptitude à satisfaire des besoins exprimés ou implicites.&quot; (Définition proposée par l'AFNOR - Association Française de Normalisation)<br /> <br /> =Vocabulaire=<br /> <br /> '''Normes de la qualité''' : un ensemble de caractéristiques qu'un produit, service ou processus de qualité doit posséder<br /> <br /> '''Facteurs de qualité''' : servent de base à l'appréciation de la qualité<br /> <br /> '''Plan de la qualité''' : document énonçant les modes opératoires, les ressources et les séquences des activités liées à la qualité, se rapportant à un produit, service, contrat ou projet particulier.<br /> <br /> '''Maître d'ouvrage''' : définit les facteurs qualité qui caractérisent le '''produit attendu'''.<br /> <br /> '''Maître d'oeuvre''' : définit les facteurs qualité du '''processus de développement''' à mettre en oeuvre pour produire ce qui a été convenu. <br /> <br /> '''Plan d'assurance qualité (en SI)''' : négocié entre le maître d'ouvrage et le maître d'oeuvre, il contient les caractéristiques qualité du produit et les dispositions qualité portant sur le processus.<br /> <br /> =Normalisation de la qualité=<br /> <br /> ==Types de normes et leurs origines==<br /> <br /> '''Le besoin d'interchangeabilité'''<br /> *Les normes portant sur les caractéristiques des produits<br /> **''Exemple : les dimensions d'une carte mémoire; le voltage et la fréquence du courant électrique, la forme d'une prise de courant, etc.''<br /> <br /> '''Le besoin de la sécurité'''<br /> *Les normes sous forme d'un modèle pour chaque type de produit<br /> **''Exemple : les jouets pour les enfants de moins de 3 ans doivent satisfaire les exigences de sécurité et d'hygiène.''<br /> <br /> '''Le besoin de la régularité de la production'''<br /> *Les normes portant sur l'organisation et la gestion de la qualité elle-même.<br /> **''Exemple : les procédures de travail, les formulaires, les modèles de documents, etc.''<br /> <br /> ==Types de normes dans le domaine de SI==<br /> <br /> '''Les normes de type &quot;caractéristiques&quot;'''<br /> *Propriétés des SI spécifiques à une entreprise<br /> **''Exemple : présentation des écrans, plans types de documentation, utilisation d'outils spécifiques, structure des noms<br /> <br /> '''Les normes de type &quot;modèle&quot;'''<br /> *Méthodes de conception des SI, méthodes de gestion des projets, modèles de maquettes et de prototypes<br /> <br /> '''Les normes de type &quot;système qualité&quot;''' <br /> *Les normes ISO 9000 - la qualité des produits et des services<br /> *Les normes ISO 10000 - la qualité des projets (ISO 10006 - qualité en management de projet)<br /> <br /> ==Les normes ISO 9000==<br /> <br /> Les normes ISO 9000 visent à s'assurer que l'entreprise certifiée fournit des produits ou des services qui répondent aux besoins des clients sur le plan de la qualité.<br /> <br /> *'''ISO 9000 - principes essentiels et vocabulaire'''<br /> Établit un point de départ pour comprendre les normes et définit les termes et définitions fondamentaux utilisés dans la famille ISO 9000, qui permettent d'éviter tout malentendu dans leur utilisation<br /> *'''ISO 9001 - exigences'''<br /> Norme pour évaluer l'aptitude d'un fournisseur à répondre aux exigences des clients et aux exigences réglementaires applicables et, par conséquent, pour traiter de la satisfaction des clients<br /> *'''ISO 9004 - lignes directrices pour l'amélioration des performances'''<br /> Fournit des conseils pour une amélioration continue d'un système de management de la qualité qui permettra à toutes les parties d'en tirer avantage par une satisfaction continue des clients.<br /> <br /> ===Principaux concepts===<br /> <br /> '''Politique qualité''' : engagement et principes de la direction générale en matière de qualité<br /> <br /> '''Gestion de la qualité''' : ensemble des activités qualité qui relèvent de la direction générale :<br /> *la planification des actions qualité<br /> *l'allocation de ressources pour la qualité<br /> *l'organisation de la qualité<br /> *l'évaluation de la qualité<br /> <br /> '''Système qualité''' : le dispositif organisationnel (responsabilités et procédures).<br /> <br /> '''Maîtrise de la qualité''' : les activités et techniques mises en oeuvre sur un projet spécifique relevant de la maîtrise.<br /> <br /> '''Assurance qualité''' : dispositions qui visent à donner confiance dans le fait que le produit du service sera de qualité : <br /> *à la direction générale (assurance qualité interne)<br /> *au client (assurance qualité externe)<br /> <br /> =La qualité des SI=<br /> <br /> La partie logicielle d'un SI est un produit ayant des caractéristiques spécifiques : <br /> *il est immatériel : on ne perçoit le logiciel qu'à travers les représentations que sont le code et la documentation<br /> *il est reproductible<br /> *il nécessite une maintenance<br /> *il a besoin d'évoluer<br /> *il possède une dimension subjective<br /> <br /> ==Les facteurs qualité d'un SI==<br /> <br /> On peut considérer un logiciel sous deux angles :<br /> *les fonctions qu'il réaliser<br /> Exemple : calcul de paie, suivi des consommations, élaboration des factures, etc.<br /> *Les caractéristiques de son utilisation<br /> Exemple : les conditions de son exploitation, la correction des erreurs, les évolutions fonctionnelles, etc.<br /> <br /> Les exigences de qualité dépendent de :<br /> *la durée de vie du logiciel<br /> *le caractère critique ou non des erreurs<br /> *le type d'utilisateur.<br /> <br /> Première caractérisation de la qualité des logiciels par B.W. Boehm, milieu des années 70. Un logiciel doit être :<br /> *utilisable en l'état<br /> *maintenable<br /> *portable<br /> <br /> Affinement par J.McCall (1977) :<br /> *Une typologie des facteurs selon différents points de vue<br /> *Trois niveaux d'expression :<br /> **les facteurs qui correspondent à un besoin<br /> **les critères qui ont des caractéristiques du logiciel, associées aux facteurs<br /> **les métriques qui sont des variables permettant de mesurer l'atteinte d'un critère.<br /> <br /> ===Facteur Fonctionnel===<br /> *'''Pertinence'''<br /> **La capacité de répondre aux problèmes d'entreprise. L'impact du SI sur la gestion de l'entreprise<br /> *'''Adéquation'''<br /> **L'adéquation du logiciel à l'organisation et aux processus de travail<br /> *'''Généralité'''<br /> **L'aptitude de la solution à résoudre des problèmes de portée plus large que le contexte particulier du projet (en cas de conception d'un progiciel)<br /> <br /> ===Facteur Utilisation===<br /> *'''Maniabilité'''<br /> **Convivialité et facilité d'emploi pour le type d'utilisateur auquel le SI est destiné (critères : '''communicabilité, exploitabilité, facilité d'apprentissage''')<br /> *'''Fiabilité'''<br /> **L'aptitude d'un SI à accomplir sans défaillance l'ensemble des fonctions spécifiées dans un document de référence (critères : '''complexité, tolérance aux fautes, auditabilité''')<br /> **''Exemple de critère : complexité, dont les métriques sont le nombre de lignes de code, le nombre d'opérateurs, etc.''<br /> *'''Efficience'''<br /> **La capacité d'un logiciel à minimiser l'utilisation des ressources disponibles (critères : '''consommation de mémoire, taille des périphériques et leur vitesse d'accès, temps d'exécution''')<br /> *'''Confidentialité'''<br /> **La capacité d'un logiciel à être protégé contre tout accès par des personnes non autorisées (critères : '''protection du code et des données, mémorisation des accès''')<br /> *'''Interopérabilité'''<br /> **L'aptitude d'un logiciel à communiquer ou interagir avec d'autres systèmes, logiciels de base ou autres applications (critères : '''standardisation des données et des interfaces''').<br /> <br /> ===Facteur Maintenance===<br /> *'''Maintenabilité'''<br /> **Le degré de facilité avec lequel on peut localiser et corriger des erreurs (critères : '''lisibilité, modularité, traçabilité''')<br /> *'''Adaptabilité'''<br /> **L'aptitude d'un logiciel à évoluer facilement par suite d'évolution des spécifications (critères : '''lisibilité, modularité, documentation''')<br /> *'''Portabilité'''<br /> **Le degré de facilité avec lequel on peut transférer le logiciel dans un autre environnement, logiciel (système d'exploitation, SGBD) ou matériel. (critères : '''indépendance, qualité de la documentation''')<br /> <br /> ===Facteur Économique===<br /> *'''Efficacité'''<br /> **La rentabilité des applications : les coûts de développement, les coûts d'exploitation et les gains effectifs dus au logiciel.<br /> <br /> ==Les métriques==<br /> <br /> '''Produit''' : nombre d'erreurs, temps moyen entre défaillances, complexité.<br /> <br /> '''Processus''' : nombre de revues et d'inspections, capacité à estimer, mesures liées à la documentation, nombre de tests.<br /> <br /> '''Code''' : nombre de lignes de code, complexité cyclomatique, nombre d'opérateurs arithmétiques et logiques, taux de commentaires.<br /> <br /> '''Spécification''' : nombre de fonctionnalités, types d'utilisateurs, cohésion et couplage des modules, taille et fréquence de communication de données.<br /> <br /> ==Démarche facteur-critères-métriques==<br /> <br /> Cette démarche est un '''cadre pour la négociation des caractéristiques qualité''' entre le maître d'ouvrage et le maître d'oeuvre. Il fait en outre apparaître '''d'éventuelles contradictions dans les exigences''' résultant de la présence des facteurs antinomiques. Il oblige aussi de faire des choix des exigences, à hiérarchiser les facteurs et les critères.<br /> <br /> =Norme ISO 9001 et l'ingénierie des SI=<br /> <br /> Les points principaux de la norme ISO 9001 :<br /> <br /> ==Responsabilité de la direction==<br /> <br /> La direction de l'entreprise fournisseur doit :<br /> *mettre par écrit sa politique en matière de qualité<br /> *expliciter la répartition des responsabilités pour les activités liées à la qualité, aux procédures qualité, au contenu d'un manuel qualité et aux vérifications prévues.<br /> <br /> La direction de l'entreprise client doit coopérer avec le fournisseur pour lui fournir toutes les informations nécessaires en temps utile. <br /> <br /> ==Maîtrise de la conception==<br /> * constitution d'un plan de développement<br /> * établissement d'un plan qualité<br /> * identification des rôles et des responsabilités des acteurs du projet (équipe client et équipe fournisseur)<br /> * procédures de gestion de projet<br /> * méthodes et techniques utilisées<br /> * activités de vérification des produits livrés<br /> * procédure de gestion des modifications<br /> <br /> ==Maîtrise des documents et des données==<br /> Le fournisseur doit définir et mettre par écrit des procédures visant à garder la maîtrise de documents :<br /> *création des documents<br /> *approbation des documents<br /> *diffusion et remplacement des documents<br /> *etc.<br /> Les procédures s'appliquent aux documents<br /> *documents de gestion : plan de développement, plan de qualité, tableaux de bord<br /> *documents techniques<br /> *documents livrés - résultats de conception<br /> *documents de travail : manuels d'utilisation, procédures, ...<br /> <br /> ==Identification et traçabilité des produits==<br /> Définir et mettre par écrit la procédure de suivi d'un produit dans toutes les étapes de sa production<br /> <br /> Gérer des identifications pour pouvoir retrouver facilement :<br /> *chaque rapport élaboré (chaque version)<br /> * l'impact d'une modification sur les différents documents de conception<br /> * chaque programme livré et son appartenance à un lot contractuel<br /> * les différents programmes d'une version de prototype<br /> * les programmes ayant passé avec succès les tests<br /> * les programmes en cours de modification<br /> <br /> Figer progressivement des versions successives d'une application, d'un prototype, d'un document<br /> <br /> ==Maîtrise des processus==<br /> *Décrire les processus de production :<br /> les méthodes et les outils logiciels utilisés pour la conception et le développement des applications<br /> *Assurer que ces processus sont respectés<br /> *Réaliser l'approbation des nouveaux processus :<br /> mettre en place une procédure d'adoption de nouveaux éléments méthodologiques <br /> *Mettre en place un dispositif de mémorisation et d'exploitation des retours d'expérience : <br /> les projets terminés, nouvelles technologies, approche particulière,...<br /> *Former systématiquement les acteurs à l'application des processus<br /> <br /> ==Contrôles et essais==<br /> La norme exige des procédures écrites visant à vérifier que les exigences spécifiées pour le produit sont respectées. Tout contrôle ou essai d'un produit doit être consigné par écrit, ainsi que leurs résultats : <br /> *livre de bord pour les contrôles et les essais<br /> *journal de suivi des tests unitaires à réaliser<br /> *journal de suivi des tests d'intégration<br /> <br /> ==État des contrôles et des essais==<br /> *Chaque document doit comporter une indication de son état : en cours, vérifié, diffusable, etc.<br /> *Chaque programme doit comporter une indication de son état : en cours, en test unitaire, en test d'intégration, exploitable, ...<br /> *Les programmes qualifiés doivent être sauvegardés sur un support différent.<br /> <br /> =Annexes=<br /> <br /> =Références=</div>

Sania https://baripedia.org/index.php?title=Ma%C3%AEtrise_de_la_qualit%C3%A9_dans_les_projets_SI&diff=32342 2016-06-05T08:34:55Z

<p>Sania : /* Quatre points de vue */</p> <hr /> <div>{{Infobox Lecture<br /> | image = <br /> | cours = [[Gestion de projet]]<br /> | faculté = [[Faculté d'économie et de management]]<br /> | département = [[Services généraux GSEM]]<br /> | domaine = [[Système d'information]]<br /> | professeurs = [[Jolita Ralyte]]&lt;ref&gt;[http://cui.unige.ch/~ralyte/ Page personnelle de Jolita Ralyte sur le site du CUI]&lt;/ref&gt;<br /> | années = <br /> | code = S204033 CR &lt;ref&gt;[http://wadme.unige.ch:3149/pls/opprg/w_det_cours.debut?p_code_cours=S204033&amp;p_plan_is=0&amp;p_langue=1&amp;p_frame=N&amp;p_mode=PGC&amp;p_annee=2015&amp;p_suffixe=&amp;p_grtri= Présentation du cours sur le site du catalogue de cours wadme]&lt;/ref&gt;<br /> | enregistrement = <br /> | précédent = <br /> | suivant = [[Estimation des charges]]<br /> }}<br /> <br /> &quot;La qualité est l'ensemble des propriétés et caractéristiques d'un produit ou service qui lui confère l'aptitude à satisfaire des besoins exprimés ou implicites.&quot; (Définition proposée par l'AFNOR - Association Française de Normalisation)<br /> <br /> =Vocabulaire=<br /> <br /> '''Normes de la qualité''' : un ensemble de caractéristiques qu'un produit, service ou processus de qualité doit posséder<br /> <br /> '''Facteurs de qualité''' : servent de base à l'appréciation de la qualité<br /> <br /> '''Plan de la qualité''' : document énonçant les modes opératoires, les ressources et les séquences des activités liées à la qualité, se rapportant à un produit, service, contrat ou projet particulier.<br /> <br /> '''Maître d'ouvrage''' : définit les facteurs qualité qui caractérisent le '''produit attendu'''.<br /> <br /> '''Maître d'oeuvre''' : définit les facteurs qualité du '''processus de développement''' à mettre en oeuvre pour produire ce qui a été convenu. <br /> <br /> '''Plan d'assurance qualité (en SI)''' : négocié entre le maître d'ouvrage et le maître d'oeuvre, il contient les caractéristiques qualité du produit et les dispositions qualité portant sur le processus.<br /> <br /> =Normalisation de la qualité=<br /> <br /> ==Types de normes et leurs origines==<br /> <br /> '''Le besoin d'interchangeabilité'''<br /> *Les normes portant sur les caractéristiques des produits<br /> **''Exemple : les dimensions d'une carte mémoire; le voltage et la fréquence du courant électrique, la forme d'une prise de courant, etc.''<br /> <br /> '''Le besoin de la sécurité'''<br /> *Les normes sous forme d'un modèle pour chaque type de produit<br /> **''Exemple : les jouets pour les enfants de moins de 3 ans doivent satisfaire les exigences de sécurité et d'hygiène.''<br /> <br /> '''Le besoin de la régularité de la production'''<br /> *Les normes portant sur l'organisation et la gestion de la qualité elle-même.<br /> **''Exemple : les procédures de travail, les formulaires, les modèles de documents, etc.''<br /> <br /> ==Types de normes dans le domaine de SI==<br /> <br /> '''Les normes de type &quot;caractéristiques&quot;'''<br /> *Propriétés des SI spécifiques à une entreprise<br /> **''Exemple : présentation des écrans, plans types de documentation, utilisation d'outils spécifiques, structure des noms<br /> <br /> '''Les normes de type &quot;modèle&quot;'''<br /> *Méthodes de conception des SI, méthodes de gestion des projets, modèles de maquettes et de prototypes<br /> <br /> '''Les normes de type &quot;système qualité&quot;''' <br /> *Les normes ISO 9000 - la qualité des produits et des services<br /> *Les normes ISO 10000 - la qualité des projets (ISO 10006 - qualité en management de projet)<br /> <br /> ==Les normes ISO 9000==<br /> <br /> Les normes ISO 9000 visent à s'assurer que l'entreprise certifiée fournit des produits ou des services qui répondent aux besoins des clients sur le plan de la qualité.<br /> <br /> *'''ISO 9000 - principes essentiels et vocabulaire'''<br /> Établit un point de départ pour comprendre les normes et définit les termes et définitions fondamentaux utilisés dans la famille ISO 9000, qui permettent d'éviter tout malentendu dans leur utilisation<br /> *'''ISO 9001 - exigences'''<br /> Norme pour évaluer l'aptitude d'un fournisseur à répondre aux exigences des clients et aux exigences réglementaires applicables et, par conséquent, pour traiter de la satisfaction des clients<br /> *'''ISO 9004 - lignes directrices pour l'amélioration des performances'''<br /> Fournit des conseils pour une amélioration continue d'un système de management de la qualité qui permettra à toutes les parties d'en tirer avantage par une satisfaction continue des clients.<br /> <br /> ===Principaux concepts===<br /> <br /> '''Politique qualité''' : engagement et principes de la direction générale en matière de qualité<br /> <br /> '''Gestion de la qualité''' : ensemble des activités qualité qui relèvent de la direction générale :<br /> *la planification des actions qualité<br /> *l'allocation de ressources pour la qualité<br /> *l'organisation de la qualité<br /> *l'évaluation de la qualité<br /> <br /> '''Système qualité''' : le dispositif organisationnel (responsabilités et procédures).<br /> <br /> '''Maîtrise de la qualité''' : les activités et techniques mises en oeuvre sur un projet spécifique relevant de la maîtrise.<br /> <br /> '''Assurance qualité''' : dispositions qui visent à donner confiance dans le fait que le produit du service sera de qualité : <br /> *à la direction générale (assurance qualité interne)<br /> *au client (assurance qualité externe)<br /> <br /> =La qualité des SI=<br /> <br /> La partie logicielle d'un SI est un produit ayant des caractéristiques spécifiques : <br /> *il est immatériel : on ne perçoit le logiciel qu'à travers les représentations que sont le code et la documentation<br /> *il est reproductible<br /> *il nécessite une maintenance<br /> *il a besoin d'évoluer<br /> *il possède une dimension subjective<br /> <br /> ==Les facteurs qualité d'un SI==<br /> <br /> On peut considérer un logiciel sous deux angles :<br /> *les fonctions qu'il réaliser<br /> Exemple : calcul de paie, suivi des consommations, élaboration des factures, etc.<br /> *Les caractéristiques de son utilisation<br /> Exemple : les conditions de son exploitation, la correction des erreurs, les évolutions fonctionnelles, etc.<br /> <br /> Les exigences de qualité dépendent de :<br /> *la durée de vie du logiciel<br /> *le caractère critique ou non des erreurs<br /> *le type d'utilisateur.<br /> <br /> Première caractérisation de la qualité des logiciels par B.W. Boehm, milieu des années 70. Un logiciel doit être :<br /> *utilisable en l'état<br /> *maintenable<br /> *portable<br /> <br /> Affinement par J.McCall (1977) :<br /> *Une typologie des facteurs selon différents points de vue<br /> *Trois niveaux d'expression :<br /> **les facteurs qui correspondent à un besoin<br /> **les critères qui ont des caractéristiques du logiciel, associées aux facteurs<br /> **les métriques qui sont des variables permettant de mesurer l'atteinte d'un critère.<br /> <br /> ===Quatre points de vue===<br /> <br /> '''Fonctionnel'''<br /> *Pertinence<br /> **La capacité de répondre aux problèmes d'entreprise. L'impact du SI sur la gestion de l'entreprise<br /> *Adéquation<br /> **L'adéquation du logiciel à l'organisation et aux processus de travail<br /> *Généralité<br /> **L'aptitude de la solution à résoudre des problèmes de portée plus large que le contexte particulier du projet (en cas de conception d'un progiciel)<br /> <br /> <br /> '''Utilisation'''<br /> *Maniabilité<br /> **Convivialité et facilité d'emploi pour le type d'utilisateur auquel le SI est destiné (communicabilité, exploitabilité, facilité d'apprentissage)<br /> *Fiabilité<br /> **L'aptitude d'un SI à accomplir sans défaillance l'ensemble des fonctions spécifiées dans un document de référence (complexité, tolérance aux fautes, auditabilité)<br /> *Efficience<br /> **La capacité d'un logiciel à minimiser l'utilisation des ressources disponibles (consommation de mémoire, taille des périphériques et leur vitesse d'accès, temps d'exécution)<br /> *Confidentialité<br /> **La capacité d'un logiciel à être protégé contre tout accès par des personnes non autorisées (protection du code et des données, mémorisation des accès)<br /> *Interopérabilité<br /> **L'aptitude d'un logiciel à communiquer ou interagir avec d'autres systèmes, logiciels de base ou autres applications (standardisation des données et des interfaces).<br /> <br /> <br /> '''Maintenance'''<br /> *Maintenabilité<br /> **Le degré de facilité avec lequel on peut localiser et corriger des erreurs (lisibilité, modularité, traçabilité)<br /> *Adaptabilité<br /> **L'aptitude d'un logiciel à évoluer facilement par suite d'évolution des spécifications (lisibilité, modularité, documentation)<br /> *Portabilité<br /> **Le degré de facilité avec lequel on peut transférer le logiciel dans un autre environnement, logiciel (système d'exploitation, SGBD) ou matériel. (indépendance, qualité de la documentation)<br /> <br /> <br /> '''Économique'''<br /> *Efficacité<br /> **La rentabilité des applications : les coûts de développement, les coûts d'exploitation et les gains effectifs dus au logiciel.<br /> <br /> ==Les métriques==<br /> <br /> '''Produit''' : nombre d'erreurs, temps moyen entre défaillances, complexité.<br /> <br /> '''Processus''' : nombre de revues et d'inspections, capacité à estimer, mesures liées à la documentation, nombre de tests.<br /> <br /> '''Code''' : nombre de lignes de code, complexité cyclomatique, nombre d'opérateurs arithmétiques et logiques, taux de commentaires.<br /> <br /> '''Spécification''' : nombre de fonctionnalités, types d'utilisateurs, cohésion et couplage des modules, taille et fréquence de communication de données.<br /> =Annexes=<br /> <br /> =Références=</div>

Sania https://baripedia.org/index.php?title=Ma%C3%AEtrise_de_la_qualit%C3%A9_dans_les_projets_SI&diff=32341 2016-06-05T08:34:21Z

<p>Sania : </p> <hr /> <div>{{Infobox Lecture<br /> | image = <br /> | cours = [[Gestion de projet]]<br /> | faculté = [[Faculté d'économie et de management]]<br /> | département = [[Services généraux GSEM]]<br /> | domaine = [[Système d'information]]<br /> | professeurs = [[Jolita Ralyte]]&lt;ref&gt;[http://cui.unige.ch/~ralyte/ Page personnelle de Jolita Ralyte sur le site du CUI]&lt;/ref&gt;<br /> | années = <br /> | code = S204033 CR &lt;ref&gt;[http://wadme.unige.ch:3149/pls/opprg/w_det_cours.debut?p_code_cours=S204033&amp;p_plan_is=0&amp;p_langue=1&amp;p_frame=N&amp;p_mode=PGC&amp;p_annee=2015&amp;p_suffixe=&amp;p_grtri= Présentation du cours sur le site du catalogue de cours wadme]&lt;/ref&gt;<br /> | enregistrement = <br /> | précédent = <br /> | suivant = [[Estimation des charges]]<br /> }}<br /> <br /> &quot;La qualité est l'ensemble des propriétés et caractéristiques d'un produit ou service qui lui confère l'aptitude à satisfaire des besoins exprimés ou implicites.&quot; (Définition proposée par l'AFNOR - Association Française de Normalisation)<br /> <br /> =Vocabulaire=<br /> <br /> '''Normes de la qualité''' : un ensemble de caractéristiques qu'un produit, service ou processus de qualité doit posséder<br /> <br /> '''Facteurs de qualité''' : servent de base à l'appréciation de la qualité<br /> <br /> '''Plan de la qualité''' : document énonçant les modes opératoires, les ressources et les séquences des activités liées à la qualité, se rapportant à un produit, service, contrat ou projet particulier.<br /> <br /> '''Maître d'ouvrage''' : définit les facteurs qualité qui caractérisent le '''produit attendu'''.<br /> <br /> '''Maître d'oeuvre''' : définit les facteurs qualité du '''processus de développement''' à mettre en oeuvre pour produire ce qui a été convenu. <br /> <br /> '''Plan d'assurance qualité (en SI)''' : négocié entre le maître d'ouvrage et le maître d'oeuvre, il contient les caractéristiques qualité du produit et les dispositions qualité portant sur le processus.<br /> <br /> =Normalisation de la qualité=<br /> <br /> ==Types de normes et leurs origines==<br /> <br /> '''Le besoin d'interchangeabilité'''<br /> *Les normes portant sur les caractéristiques des produits<br /> **''Exemple : les dimensions d'une carte mémoire; le voltage et la fréquence du courant électrique, la forme d'une prise de courant, etc.''<br /> <br /> '''Le besoin de la sécurité'''<br /> *Les normes sous forme d'un modèle pour chaque type de produit<br /> **''Exemple : les jouets pour les enfants de moins de 3 ans doivent satisfaire les exigences de sécurité et d'hygiène.''<br /> <br /> '''Le besoin de la régularité de la production'''<br /> *Les normes portant sur l'organisation et la gestion de la qualité elle-même.<br /> **''Exemple : les procédures de travail, les formulaires, les modèles de documents, etc.''<br /> <br /> ==Types de normes dans le domaine de SI==<br /> <br /> '''Les normes de type &quot;caractéristiques&quot;'''<br /> *Propriétés des SI spécifiques à une entreprise<br /> **''Exemple : présentation des écrans, plans types de documentation, utilisation d'outils spécifiques, structure des noms<br /> <br /> '''Les normes de type &quot;modèle&quot;'''<br /> *Méthodes de conception des SI, méthodes de gestion des projets, modèles de maquettes et de prototypes<br /> <br /> '''Les normes de type &quot;système qualité&quot;''' <br /> *Les normes ISO 9000 - la qualité des produits et des services<br /> *Les normes ISO 10000 - la qualité des projets (ISO 10006 - qualité en management de projet)<br /> <br /> ==Les normes ISO 9000==<br /> <br /> Les normes ISO 9000 visent à s'assurer que l'entreprise certifiée fournit des produits ou des services qui répondent aux besoins des clients sur le plan de la qualité.<br /> <br /> *'''ISO 9000 - principes essentiels et vocabulaire'''<br /> Établit un point de départ pour comprendre les normes et définit les termes et définitions fondamentaux utilisés dans la famille ISO 9000, qui permettent d'éviter tout malentendu dans leur utilisation<br /> *'''ISO 9001 - exigences'''<br /> Norme pour évaluer l'aptitude d'un fournisseur à répondre aux exigences des clients et aux exigences réglementaires applicables et, par conséquent, pour traiter de la satisfaction des clients<br /> *'''ISO 9004 - lignes directrices pour l'amélioration des performances'''<br /> Fournit des conseils pour une amélioration continue d'un système de management de la qualité qui permettra à toutes les parties d'en tirer avantage par une satisfaction continue des clients.<br /> <br /> ===Principaux concepts===<br /> <br /> '''Politique qualité''' : engagement et principes de la direction générale en matière de qualité<br /> <br /> '''Gestion de la qualité''' : ensemble des activités qualité qui relèvent de la direction générale :<br /> *la planification des actions qualité<br /> *l'allocation de ressources pour la qualité<br /> *l'organisation de la qualité<br /> *l'évaluation de la qualité<br /> <br /> '''Système qualité''' : le dispositif organisationnel (responsabilités et procédures).<br /> <br /> '''Maîtrise de la qualité''' : les activités et techniques mises en oeuvre sur un projet spécifique relevant de la maîtrise.<br /> <br /> '''Assurance qualité''' : dispositions qui visent à donner confiance dans le fait que le produit du service sera de qualité : <br /> *à la direction générale (assurance qualité interne)<br /> *au client (assurance qualité externe)<br /> <br /> =La qualité des SI=<br /> <br /> La partie logicielle d'un SI est un produit ayant des caractéristiques spécifiques : <br /> *il est immatériel : on ne perçoit le logiciel qu'à travers les représentations que sont le code et la documentation<br /> *il est reproductible<br /> *il nécessite une maintenance<br /> *il a besoin d'évoluer<br /> *il possède une dimension subjective<br /> <br /> ==Les facteurs qualité d'un SI==<br /> <br /> On peut considérer un logiciel sous deux angles :<br /> *les fonctions qu'il réaliser<br /> Exemple : calcul de paie, suivi des consommations, élaboration des factures, etc.<br /> *Les caractéristiques de son utilisation<br /> Exemple : les conditions de son exploitation, la correction des erreurs, les évolutions fonctionnelles, etc.<br /> <br /> Les exigences de qualité dépendent de :<br /> *la durée de vie du logiciel<br /> *le caractère critique ou non des erreurs<br /> *le type d'utilisateur.<br /> <br /> Première caractérisation de la qualité des logiciels par B.W. Boehm, milieu des années 70. Un logiciel doit être :<br /> *utilisable en l'état<br /> *maintenable<br /> *portable<br /> <br /> Affinement par J.McCall (1977) :<br /> *Une typologie des facteurs selon différents points de vue<br /> *Trois niveaux d'expression :<br /> **les facteurs qui correspondent à un besoin<br /> **les critères qui ont des caractéristiques du logiciel, associées aux facteurs<br /> **les métriques qui sont des variables permettant de mesurer l'atteinte d'un critère.<br /> <br /> ===Quatre points de vue===<br /> <br /> '''Fonctionnel'''<br /> *Pertinence<br /> **La capacité de répondre aux problèmes d'entreprise. L'impact du SI sur la gestion de l'entreprise<br /> *Adéquation<br /> **L'adéquation du logiciel à l'organisation et aux processus de travail<br /> *Généralité<br /> **L'aptitude de la solution à résoudre des problèmes de portée plus large que le contexte particulier du projet (en cas de conception d'un progiciel)<br /> <br /> '''Utilisation'''<br /> *Maniabilité<br /> **Convivialité et facilité d'emploi pour le type d'utilisateur auquel le SI est destiné (communicabilité, exploitabilité, facilité d'apprentissage)<br /> *Fiabilité<br /> **L'aptitude d'un SI à accomplir sans défaillance l'ensemble des fonctions spécifiées dans un document de référence (complexité, tolérance aux fautes, auditabilité)<br /> *Efficience<br /> **La capacité d'un logiciel à minimiser l'utilisation des ressources disponibles (consommation de mémoire, taille des périphériques et leur vitesse d'accès, temps d'exécution)<br /> *Confidentialité<br /> **La capacité d'un logiciel à être protégé contre tout accès par des personnes non autorisées (protection du code et des données, mémorisation des accès)<br /> *Interopérabilité<br /> **L'aptitude d'un logiciel à communiquer ou interagir avec d'autres systèmes, logiciels de base ou autres applications (standardisation des données et des interfaces).<br /> <br /> '''Maintenance'''<br /> *Maintenabilité<br /> **Le degré de facilité avec lequel on peut localiser et corriger des erreurs (lisibilité, modularité, traçabilité)<br /> *Adaptabilité<br /> **L'aptitude d'un logiciel à évoluer facilement par suite d'évolution des spécifications (lisibilité, modularité, documentation)<br /> *Portabilité<br /> **Le degré de facilité avec lequel on peut transférer le logiciel dans un autre environnement, logiciel (système d'exploitation, SGBD) ou matériel. (indépendance, qualité de la documentation)<br /> <br /> '''Économique'''<br /> *Efficacité<br /> **La rentabilité des applications : les coûts de développement, les coûts d'exploitation et les gains effectifs dus au logiciel.<br /> <br /> ==Les métriques==<br /> <br /> '''Produit''' : nombre d'erreurs, temps moyen entre défaillances, complexité.<br /> <br /> '''Processus''' : nombre de revues et d'inspections, capacité à estimer, mesures liées à la documentation, nombre de tests.<br /> <br /> '''Code''' : nombre de lignes de code, complexité cyclomatique, nombre d'opérateurs arithmétiques et logiques, taux de commentaires.<br /> <br /> '''Spécification''' : nombre de fonctionnalités, types d'utilisateurs, cohésion et couplage des modules, taille et fréquence de communication de données.<br /> =Annexes=<br /> <br /> =Références=</div>

Sania https://baripedia.org/index.php?title=Ma%C3%AEtrise_de_la_qualit%C3%A9_dans_les_projets_SI&diff=32340 2016-06-05T03:20:06Z

<p>Sania : Page créée avec « {{Infobox Lecture | image = | cours = Gestion de projet | faculté = Faculté d'économie et de management | département = Services généraux GSEM | do... »</p> <hr /> <div>{{Infobox Lecture<br /> | image = <br /> | cours = [[Gestion de projet]]<br /> | faculté = [[Faculté d'économie et de management]]<br /> | département = [[Services généraux GSEM]]<br /> | domaine = [[Système d'information]]<br /> | professeurs = [[Jolita Ralyte]]&lt;ref&gt;[http://cui.unige.ch/~ralyte/ Page personnelle de Jolita Ralyte sur le site du CUI]&lt;/ref&gt;<br /> | années = <br /> | code = S204033 CR &lt;ref&gt;[http://wadme.unige.ch:3149/pls/opprg/w_det_cours.debut?p_code_cours=S204033&amp;p_plan_is=0&amp;p_langue=1&amp;p_frame=N&amp;p_mode=PGC&amp;p_annee=2015&amp;p_suffixe=&amp;p_grtri= Présentation du cours sur le site du catalogue de cours wadme]&lt;/ref&gt;<br /> | enregistrement = <br /> | précédent = <br /> | suivant = [[Estimation des charges]]<br /> }}<br /> <br /> &quot;La qualité est l'ensemble des propriétés et caractéristiques d'un produit ou service qui lui confère l'aptitude à satisfaire des besoins exprimés ou implicites.&quot; (Définition proposée par l'AFNOR - Association Française de Normalisation)<br /> <br /> =Vocabulaire=<br /> <br /> '''Normes de la qualité''' : un ensemble de caractéristiques qu'un produit, service ou processus de qualité doit posséder<br /> <br /> '''Facteurs de qualité''' : servent de base à l'appréciation de la qualité<br /> <br /> '''Plan de la qualité''' : document énonçant les modes opératoires, les ressources et les séquences des activités liées à la qualité, se rapportant à un produit, service, contrat ou projet particulier.<br /> <br /> '''Maître d'ouvrage''' : définit les facteurs qualité qui caractérisent le '''produit attendu'''.<br /> <br /> '''Maître d'oeuvre''' : définit les facteurs qualité du '''processus de développement''' à mettre en oeuvre pour produire ce qui a été convenu. <br /> <br /> '''Plan d'assurance qualité (en SI)''' : négocié entre le maître d'ouvrage et le maître d'oeuvre, il contient les caractéristiques qualité du produit et les dispositions qualité portant sur le processus.<br /> <br /> =Normalisation de la qualité=<br /> <br /> ==Types de normes et leurs origines==<br /> <br /> '''Le besoin d'interchangeabilité'''<br /> *Les normes portant sur les caractéristiques des produits<br /> **''Exemple : les dimensions d'une carte mémoire; le voltage et la fréquence du courant électrique, la forme d'une prise de courant, etc.''<br /> <br /> '''Le besoin de la sécurité'''<br /> *Les normes sous forme d'un modèle pour chaque type de produit<br /> **''Exemple : les jouets pour les enfants de moins de 3 ans doivent satisfaire les exigences de sécurité et d'hygiène.''<br /> <br /> '''Le besoin de la régularité de la production'''<br /> *Les normes portant sur l'organisation et la gestion de la qualité elle-même.<br /> **''Exemple : les procédures de travail, les formulaires, les modèles de documents, etc.''<br /> <br /> ==Types de normes dans le domaine de SI==<br /> <br /> '''Les normes de type &quot;caractéristiques&quot;'''<br /> *Propriétés des SI spécifiques à une entreprise<br /> **''Exemple : présentation des écrans, plans types de documentation, utilisation d'outils spécifiques, structure des noms<br /> <br /> '''Les normes de type &quot;modèle&quot;'''<br /> *Méthodes de conception des SI, méthodes de gestion des projets, modèles de maquettes et de prototypes<br /> <br /> '''Les normes de type &quot;système qualité&quot;''' <br /> *Les normes ISO 9000 - la qualité des produits et des services<br /> *Les normes ISO 10000 - la qualité des projets (ISO 10006 - qualité en management de projet)<br /> <br /> ==Les normes ISO 9000==<br /> <br /> Les normes ISO 9000 visent à s'assurer que l'entreprise certifiée fournit des produits ou des services qui répondent aux besoins des clients sur le plan de la qualité.<br /> <br /> *'''ISO 9000 - principes essentiels et vocabulaire'''<br /> Établit un point de départ pour comprendre les normes et définit les termes et définitions fondamentaux utilisés dans la famille ISO 9000, qui permettent d'éviter tout malentendu dans leur utilisation<br /> *'''ISO 9001 - exigences'''<br /> Norme pour évaluer l'aptitude d'un fournisseur à répondre aux exigences des clients et aux exigences réglementaires applicables et, par conséquent, pour traiter de la satisfaction des clients<br /> *'''ISO 9004 - lignes directrices pour l'amélioration des performances'''<br /> Fournit des conseils pour une amélioration continue d'un système de management de la qualité qui permettra à toutes les parties d'en tirer avantage par une satisfaction continue des clients.<br /> <br /> ===Principaux concepts===<br /> <br /> '''Politique qualité''' : engagement et principes de la direction générale en matière de qualité<br /> <br /> '''Gestion de la qualité''' : ensemble des activités qualité qui relèvent de la direction générale :<br /> *la planification des actions qualité<br /> *l'allocation de ressources pour la qualité<br /> *l'organisation de la qualité<br /> *l'évaluation de la qualité<br /> <br /> '''Système qualité''' : le dispositif organisationnel (responsabilités et procédures).<br /> <br /> '''Maîtrise de la qualité''' : les activités et techniques mises en oeuvre sur un projet spécifique relevant de la maîtrise.<br /> <br /> '''Assurance qualité''' : dispositions qui visent à donner confiance dans le fait que le produit du service sera de qualité : <br /> *à la direction générale (assurance qualité interne)<br /> *au client (assurance qualité externe)<br /> <br /> =La qualité des SI=<br /> <br /> La partie logicielle d'un SI est un produit ayant des caractéristiques spécifiques : <br /> *il est immatériel : on ne perçoit le logiciel qu'à travers les représentations que sont le code et la documentation<br /> *il est reproductible<br /> *il nécessite une maintenance<br /> *il a besoin d'évoluer<br /> *il possède une dimension subjective<br /> <br /> ==Les facteurs qualité d'un SI==<br /> <br /> On peut considérer un logiciel sous deux angles :<br /> *les fonctions qu'il réaliser<br /> Exemple : calcul de paie, suivi des consommations, élaboration des factures, etc.<br /> *Les caractéristiques de son utilisation<br /> Exemple : les conditions de son exploitation, la correction des erreurs, les évolutions fonctionnelles, etc.<br /> <br /> Les exigences de qualité dépendent de :<br /> *la durée de vie du logiciel<br /> *le caractère critique ou non des erreurs<br /> *le type d'utilisateur.<br /> <br /> Première caractérisation de la qualité des logiciels par B.W. Boehm, milieu des années 70. Un logiciel doit être :<br /> *utilisable en l'état<br /> *maintenable<br /> *portable<br /> <br /> Affinement par J.McCall (1977) :<br /> *Une typologie des facteurs selon différents points de vue<br /> *Trois niveaux d'expression :<br /> **les facteurs qui correspondent à un besoin<br /> **les critères qui ont des caractéristiques du logiciel, associées aux facteurs<br /> **les métriques qui sont des variables permettant de mesurer l'atteinte d'un critère.<br /> <br /> <br /> =Annexes=<br /> <br /> =Références=</div>

Sania https://baripedia.org/index.php?title=Projet_de_mise_en_place_d%27un_ERP&diff=32339 2016-06-05T02:50:50Z

<p>Sania : </p> <hr /> <div>{{Infobox Lecture<br /> | image = <br /> | cours = [[Gestion de projet]]<br /> | faculté = [[Faculté d'économie et de management]]<br /> | département = [[Services généraux GSEM]]<br /> | domaine = [[Système d'information]]<br /> | professeurs = [[Jolita Ralyte]]&lt;ref&gt;[http://cui.unige.ch/~ralyte/ Page personnelle de Jolita Ralyte sur le site du CUI]&lt;/ref&gt;<br /> | années = <br /> | code = S204033 CR &lt;ref&gt;[http://wadme.unige.ch:3149/pls/opprg/w_det_cours.debut?p_code_cours=S204033&amp;p_plan_is=0&amp;p_langue=1&amp;p_frame=N&amp;p_mode=PGC&amp;p_annee=2015&amp;p_suffixe=&amp;p_grtri= Présentation du cours sur le site du catalogue de cours wadme]&lt;/ref&gt;<br /> | enregistrement = <br /> | précédent = <br /> | suivant = [[Maîtrise de la qualité dans les projets SI]]<br /> }}<br /> <br /> Un ERP (Enterprise Resource Planning) est un PGI (Progiciel de Gestion Intégré) : il est composé d'un ensemble de modules applicatifs qui visent à couvrir l'ensemble des fonctions de l'entreprise.<br /> <br /> Il existe deux types d'ERP :<br /> <br /> '''ERP Propriétaires''' : achat d'une licence<br /> *Marché mondial :<br /> **SAP<br /> **ORACLE (PEOPLESOFT)<br /> **SAGE<br /> **MICROSOFT<br /> **INFOR ERP (BAAN, LAWSON)<br /> *En Suisse :<br /> **ProConcept ERP<br /> <br /> '''ERP open source'''<br /> *Marché mondial :<br /> **Odoo (OpenERP)<br /> **ADempierre<br /> **Compiere<br /> **ERP5<br /> **Jfire<br /> **Ofbiz<br /> **OpenBravo<br /> **Opentaps<br /> **Weberp<br /> **xTuple<br /> <br /> =Caractéristiques d'un ERP=<br /> <br /> '''Un système ERP : '''<br /> * couvre plusieurs fonctions de l'entreprise<br /> * inclut un entrepôt de données central<br /> * comporte plusieurs modules interconnectés<br /> * permet un accès direct à l'entrepôt de données<br /> * est développé et vendu par un seul fournisseur<br /> * est adaptable aux besoins spécifiques de l'entreprise<br /> <br /> '''Atouts d'un ERP :'''<br /> * On espère retirer d'un ERP une '''économie''' par rapport à une solution spécifique, généralement plus coûteuse.<br /> * On cherche à s'appuyer sur un '''schéma''' sous-jacent des flux, propre à un ERP, pour mener une opération de reconfiguration des processus.<br /> * On cherche à '''limiter la redondance des informations''' et leur gestion à de multiples endroits en visant l'unicité de l'information.<br /> * On veut généraliser les mises à jour en '''temps réel'''.<br /> * On recherche un logiciel garantissant une '''totale traçabilité des informations'''.<br /> * On attend une '''couverture fonctionnelle''' importante et cohérente.<br /> <br /> =Principales raisons de la mise en place d'un ERP=<br /> <br /> '''Intégrer toutes les informations financières'''<br /> *améliorer la gestion des finances<br /> *mieux comprendre la performance de l'entreprise<br /> <br /> '''Intégrer toutes les informations sur les commandes client'''<br /> *gérer tout le cycle de vie d'une commande<br /> *coordonner la production, l'inventaire et la livraison<br /> *améliorer la satisfaction des clients<br /> <br /> '''Standardiser et accélérer les processus de fabrication'''<br /> *augmenter la productivité<br /> *synchroniser le travail de différents départements<br /> *améliorer la visibilité des processus de fabrication<br /> <br /> '''Réduire l'inventaire'''<br /> *des matières et des composants utilisés pour la production<br /> *des produits réalisés<br /> <br /> '''Standardiser les informations RH'''<br /> *gérer les compétences et les qualifications des employés<br /> *informer les employés sur les services, les formations et les avantages<br /> *gérer les présences/absences<br /> <br /> '''Améliorer la planification'''<br /> *de l'achat du matériel, de la production, des ventes<br /> <br /> '''Assurer la qualité'''<br /> *mieux maîtriser tous les processus métier.<br /> <br /> =Projet ERP=<br /> <br /> '''Objectif :''' mettre en place un système ERP pour une partie des activités de l'entreprise<br /> <br /> '''Problème à résoudre :''' trouver une adéquation entre les fonctions proposées par les ERP et les processus métier de l'entreprise.<br /> <br /> ==Les stratégies projet ERP==<br /> <br /> '''Big Bang''' : le plus ambitieux et le plus difficile des projets ERP<br /> *l'entreprise rejette tous les systèmes existants et installe un nouveau système ERP<br /> *le projet nécessite une mobilisation de toute l'entreprise<br /> *la couverture fonctionnelle n'est pas toujours satisfaisante.<br /> <br /> '''Franchising strategy''' : concerne les grandes entreprises ayant des unités économiques relativement indépendantes<br /> *des systèmes ERP indépendants (instances d'ERP) sont installés dans chaque unité reliant seulement les processus communs tels que la gestion financière à travers toute l'entreprise<br /> *souvent, un projet pilote est réalisé dans une unité, qui est ensuite utilisé comme un exemple pour installer les instances ERP dans les autres unités.<br /> <br /> '''Slam-dunk''' : concerne les petites entreprises qui achètent seulement quelques modules d'un ERP<br /> *le projet se concentre sur quelques processus clefs d'un ERP, par exemple le processus contenu dans le module &quot;Finances&quot; ou &quot;Production&quot; d'un ERP<br /> *l'entreprise envisage d'acheter progressivement d'autres modules du même ERP si son évolution le permet<br /> <br /> '''On-Demand- Nibble''' : concerne l'achat des services en ligne (SaaS) pour différents processus d'entreprise<br /> *plus rapide à implémenter (il n'y a pas d'installation)<br /> *les mises à jour sont plus faciles et plus rapides<br /> *l'abonnement par mois et par utilisateur est moins cher que le coût d'implémentation sur place<br /> *les grandes entreprises sont encore réticentes à stocker leurs données sensibles sur les serveurs des tiers<br /> <br /> =Démarche de mise en place d'un ERP=<br /> <br /> ==Étude d'opportunité==<br /> <br /> C'est la définition des grandes lignes du projet, où on fait le choix des fonctions à couvrir. <br /> <br /> ''Exemples : ''<br /> *la gestion comptable est financière<br /> *le contrôle de la qualité<br /> * la gestion de la production<br /> * la gestion des achats<br /> * la gestion des stocks<br /> * l'administration des ventes<br /> * la gestion des ressources humaines<br /> * la paie du personnel<br /> * etc<br /> <br /> ==Choix d'un ERP==<br /> <br /> '''Étape 1 : la présélection'''<br /> <br /> Une étude du marché, fondée sur des critères de sélection préalablement établis qui déterminent le choix selon les caractéristiques de l'ERP : stratégiques, fonctionnelles, technologiques, techniques, commerciales.<br /> <br /> '''Étape 2 : la sélection'''<br /> <br /> Contacts commerciaux avec les fournisseurs des ERP présélectionnés, visites de leurs sites, analyse des solutions proposées, établissement du budget précis pour chaque offre, sélection finale.<br /> <br /> ==Implémentation d'un ERP==<br /> <br /> '''Adaptation du progiciel retenu'''<br /> *Analyse des besoins<br /> *Paramétrage du progiciel<br /> *Installation du progiciel<br /> *Formation des utilisateurs.<br /> <br /> ===Initialisation===<br /> *Constitution de l'équipe du projet<br /> * Répartition du travail au sein de l'équipe <br /> * Mise en place des moyens de coordination et de communication à l'intérieur de l'équipe<br /> * Mise en place d'un comité de pilotage<br /> <br /> ===Description des processus===<br /> Première description des besoins fonctionnels qui consiste à :<br /> *décrire les processus que l'on souhaite implémenter<br /> *réfléchir sur la configuration des processus existants<br /> <br /> ===Formation au produit===<br /> Analyse des solutions proposées par le logiciel<br /> *Présentation des solutions ERP par le fournisseur.<br /> <br /> ===Mise en place d'une solution standard===<br /> Développement/adaptation du progiciel aux besoins de l'entreprise:<br /> *analyse des processus<br /> *paramétrage des processus et des interfaces<br /> *prototypage<br /> *simulation<br /> <br /> ===Fermeture des trous fonctionnels===<br /> Recherches des solutions pour répondre aux manques du progiciel :<br /> *Définition de l'importance de chaque &quot;trou fonctionnel&quot; : <br /> **obligatoire<br /> **la mise en place peut être différée ou<br /> **la mise en place n'est pas indispensable<br /> *Étude de la solution possible :<br /> **modification du processus<br /> *attente ou<br /> **modification du progiciel<br /> *Définition des avantages et des inconvénients de chaque solution<br /> *Choix parmi les solutions proposées<br /> <br /> ===Développement des solutions spécifiques===<br /> Mise en place des solutions spécifiques : description et développement des solutions choisies<br /> <br /> ===Préparation et mise en oeuvre===<br /> *Intégration dans l'environnement existant<br /> *Préparation de la mise en exploitation<br /> *Reprise des données<br /> *Organisation de la formation des utilisateurs<br /> *Élaboration des modes opératoires et manuels utilisateurs<br /> <br /> =Les acteurs dans un projet ERP=<br /> <br /> '''Le comité de pilotage : '''<br /> *la direction générale<br /> *les directions opérationnelles<br /> *la direction informatique<br /> *la direction du projet<br /> <br /> Le rôle du comité de pilotage est à se prononcer sur chaque choix qui lui est soumis. <br /> <br /> '''Le chef de projet client''' : responsable des travaux des équipes fonctionnelles.<br /> <br /> '''Le chef de projet fournisseur''' : responsable des travaux de l'équipe technique.<br /> <br /> Les deux chefs sont responsables du pilotage du projet : <br /> *de la qualité des livrables<br /> *de l'organisation des ressources<br /> *du respect des délais<br /> <br /> '''Les équipes fonctionnelles''' : utilisateurs spécialisés et rendus disponibles.<br /> *une équipe est constituée pour chaque métier concerné par le progiciel<br /> *Le travail de chaque équipe est animé par un leader<br /> *Chaque équipe participe activement aux étapes de l'implémentation :<br /> **décrit les processus<br /> **recherche des solutions standard<br /> **comble des trous fonctionnels<br /> **participe à la mise en oeuvre<br /> <br /> '''L'équipe technique''' : consultants d'ERP<br /> *argumente les choix de composants techniques<br /> *assure le support technique auprès des équipes fonctionnelles<br /> met en place des interfaces avec d'autres applications<br /> <br /> '''L'administrateur de données''' : responsable de la description des processus et des solutions à implémenter par des travaux de synthèse et de coordination des différentes équipes qui partagent le même système d'information.<br /> <br /> '''Les consultants''' : <br /> *le consultant de pilotage : assiste le binôme chefs de projet dans les travaux de planification et de suivi<br /> *les consultants fonctionnels : spécialistes d'un ou plusieurs métiers traités, ils assistent les équipes fonctionnelles<br /> *le consultant technique : expert du progiciel choisi, il assiste l'équipe technique.<br /> <br /> '''Les assistants méthodes''' : spécialistes de la modélisation, qui assistent les équipes fonctionnelles dans leurs travaux et description des processus.<br /> <br /> =Les coûts cachés d'un projet ERP=<br /> <br /> * Formation<br /> * Intégration et implémentation<br /> * Personnalisation<br /> * Conversion de données<br /> * Analyse de données<br /> * Consultants à l'infini<br /> * Remplacement des meilleurs acteurs<br /> * Les équipes de mise en oeuvre ne peuvent jamais s'arrêter<br /> * Attente de rentabilité<br /> * Dépression post-ERP<br /> <br /> =Avantages des ERP=<br /> <br /> * Cohérence et homogénéité des informations<br /> * Intégrité et unicité du système d'information<br /> * Optimisation des processus de gestion<br /> * Partage du même système d'information facilitant la communication interne et externe<br /> * Minimisation des coûts<br /> * Diminution du nombre de salariés<br /> * Maîtrise des coûts et des délais de mise en oeuvre et de déploiement<br /> * Réutilisation de l'expérience confirmée<br /> <br /> =Inconvénients des ERP=<br /> * Mise en oeuvre pouvant être complexe si le périmètre est mal déterminé ou trop mouvant ou si le projet est mal piloté<br /> * Coût élevé (300'000€ minimum pour un bon ERP fiable)<br /> * Périmètre fonctionnel souvent plus large que les besoins de l'entreprise<br /> * Périmètre fonctionnel pouvant ne pas couvrir l'ensemble des besoins<br /> * Lourdeur et rigidité de mise en oeuvre<br /> * Difficultés d'appropriation par le personnel de l'entreprise<br /> * Nécessité parfois d'adapter certains processus de l'organisation ou de l'entreprise au progiciel<br /> * Nécessité d'une maintenance continue<br /> * Captivité vis-à-vis de l'éditeur<br /> <br /> <br /> =Annexes=<br /> <br /> =Références=</div>

Sania https://baripedia.org/index.php?title=Projet_de_mise_en_place_d%27un_ERP&diff=32338 2016-06-04T18:00:00Z

<p>Sania : </p> <hr /> <div>{{Infobox Lecture<br /> | image = <br /> | cours = [[Gestion de projet]]<br /> | faculté = [[Faculté d'économie et de management]]<br /> | département = [[Services généraux GSEM]]<br /> | domaine = [[Système d'information]]<br /> | professeurs = [[Jolita Ralyte]]&lt;ref&gt;[http://cui.unige.ch/~ralyte/ Page personnelle de Jolita Ralyte sur le site du CUI]&lt;/ref&gt;<br /> | années = <br /> | code = S204033 CR &lt;ref&gt;[http://wadme.unige.ch:3149/pls/opprg/w_det_cours.debut?p_code_cours=S204033&amp;p_plan_is=0&amp;p_langue=1&amp;p_frame=N&amp;p_mode=PGC&amp;p_annee=2015&amp;p_suffixe=&amp;p_grtri= Présentation du cours sur le site du catalogue de cours wadme]&lt;/ref&gt;<br /> | enregistrement = <br /> | précédent = <br /> | suivant = [[Maîtrise de la qualité dans les projets SI]]<br /> }}<br /> <br /> Un ERP (Enterprise Resource Planning) est un PGI (Progiciel de Gestion Intégré) : il est composé d'un ensemble de modules applicatifs qui visent à couvrir l'ensemble des fonctions de l'entreprise.<br /> <br /> Il existe deux types d'ERP :<br /> <br /> <br /> '''ERP Propriétaires''' : achat d'une licence<br /> *Marché mondial :<br /> **SAP<br /> **ORACLE (PEOPLESOFT)<br /> **SAGE<br /> **MICROSOFT<br /> **INFOR ERP (BAAN, LAWSON)<br /> *En Suisse :<br /> **ProConcept ERP<br /> <br /> '''ERP open source'''<br /> *Marché mondial :<br /> **Odoo (OpenERP)<br /> **ADempierre<br /> **Compiere<br /> **ERP5<br /> **Jfire<br /> **Ofbiz<br /> **OpenBravo<br /> **Opentaps<br /> **Weberp<br /> **xTuple</div>

Sania https://baripedia.org/index.php?title=Projet_de_mise_en_place_d%27un_ERP&diff=32337 2016-06-04T17:59:12Z

<p>Sania : </p> <hr /> <div>{{Infobox Lecture<br /> | image = <br /> | cours = [[Gestion de projet]]<br /> | faculté = [[Faculté d'économie et de management]]<br /> | département = [[Services généraux GSEM]]<br /> | domaine = [[Système d'information]]<br /> | professeurs = [[Jolita Ralyte]]&lt;ref&gt;[http://cui.unige.ch/~ralyte/ Page personnelle de Jolita Ralyte sur le site du CUI]&lt;/ref&gt;<br /> | années = <br /> | code = S204033 CR &lt;ref&gt;[http://wadme.unige.ch:3149/pls/opprg/w_det_cours.debut?p_code_cours=S204033&amp;p_plan_is=0&amp;p_langue=1&amp;p_frame=N&amp;p_mode=PGC&amp;p_annee=2015&amp;p_suffixe=&amp;p_grtri= Présentation du cours sur le site du catalogue de cours wadme]&lt;/ref&gt;<br /> | enregistrement = <br /> | précédent = <br /> | suivant = [[Maîtrise de la qualité dans les projets SI]]<br /> }}<br /> <br /> Un ERP (Enterprise Resource Planning) est un PGI (Progiciel de Gestion Intégré) : il est composé d'un ensemble de modules applicatifs qui visent à couvrir l'ensemble des fonctions de l'entreprise.<br /> <br /> Il existe deux types d'ERP :<br /> <br /> <br /> '''ERP Propriétaires''' : achat d'une licence<br /> *Marché mondial :<br /> **SAP<br /> **ORACLE (PEOPLESOFT)<br /> **SAGE<br /> **MICROSOFT<br /> **INFOR ERP (BAAN, LAWSON)<br /> *En Suisse :<br /> **ProConcept ERP<br /> <br /> '''ERP open source'''<br /> **Odoo (OpenERP)<br /> * *ADempierre<br /> **Compiere<br /> **ERP5<br /> **Jfire<br /> **Ofbiz<br /> **OpenBravo<br /> **Opentaps<br /> **Weberp<br /> **xTuple</div>

Sania https://baripedia.org/index.php?title=Projet_de_mise_en_place_d%27un_ERP&diff=32336 2016-06-04T17:37:49Z

<p>Sania : Page créée avec « {{Infobox Lecture | image = | cours = Gestion de projet | faculté = Faculté d'économie et de management | département = Services généraux GSEM | do... »</p> <hr /> <div>{{Infobox Lecture<br /> | image = <br /> | cours = [[Gestion de projet]]<br /> | faculté = [[Faculté d'économie et de management]]<br /> | département = [[Services généraux GSEM]]<br /> | domaine = [[Système d'information]]<br /> | professeurs = [[Jolita Ralyte]]&lt;ref&gt;[http://cui.unige.ch/~ralyte/ Page personnelle de Jolita Ralyte sur le site du CUI]&lt;/ref&gt;<br /> | années = <br /> | code = S204033 CR &lt;ref&gt;[http://wadme.unige.ch:3149/pls/opprg/w_det_cours.debut?p_code_cours=S204033&amp;p_plan_is=0&amp;p_langue=1&amp;p_frame=N&amp;p_mode=PGC&amp;p_annee=2015&amp;p_suffixe=&amp;p_grtri= Présentation du cours sur le site du catalogue de cours wadme]&lt;/ref&gt;<br /> | enregistrement = <br /> | précédent = <br /> | suivant = [[Maîtrise de la qualité dans les projets SI]]<br /> }}</div>

Sania https://baripedia.org/index.php?title=Techniques_de_planification&diff=32335 2016-06-04T17:37:09Z

<p>Sania : </p> <hr /> <div>{{Infobox Lecture<br /> | image = <br /> | cours = [[Gestion de projet]]<br /> | faculté = [[Faculté d'économie et de management]]<br /> | département = [[Services généraux GSEM]]<br /> | domaine = [[Système d'information]]<br /> | professeurs = [[Jolita Ralyte]]&lt;ref&gt;[http://cui.unige.ch/~ralyte/ Page personnelle de Jolita Ralyte sur le site du CUI]&lt;/ref&gt;<br /> | années = <br /> | code = S204033 CR &lt;ref&gt;[http://wadme.unige.ch:3149/pls/opprg/w_det_cours.debut?p_code_cours=S204033&amp;p_plan_is=0&amp;p_langue=1&amp;p_frame=N&amp;p_mode=PGC&amp;p_annee=2015&amp;p_suffixe=&amp;p_grtri= Présentation du cours sur le site du catalogue de cours wadme]&lt;/ref&gt;<br /> | enregistrement = <br /> | précédent = <br /> | suivant = [[Projet de mise en place d'un ERP]]<br /> }}<br /> <br /> Dans la gestion des projets SI, PERT et Gantt sont deux techniques de planification complémentaires.<br /> <br /> Avant tout, on doit faire un découpage de type WBS (voir le cours [[Découpage de projets]]) et reprendre les caractéristiques de chacun des éléments afin de construire un '''réseau PERT'''. On part d'une liste de tâches et de la durée estimée de chacune d'elles pour se concentrer sur les contraintes d'ordonnancement de ces tâches et sur les possibilités de parallélisme.<br /> <br /> Ensuite, on fait un calendrier de travail avec un '''diagramme de Gantt'''.<br /> <br /> =Réseau PERT=<br /> <br /> Program Evaluation and Review Technique, aussi dit graphe d'ordonnancement, c'est un '''graphe orienté''' qui permet de '''représenter les contraintes d'enchaînement''' entre les différentes tâches à réaliser pour mener à bien le projet.<br /> <br /> '''Cette technique permet de :'''<br /> * définir l'ordonnancement des tâches<br /> * introduire le parallélisme des tâches<br /> * définir les dates de début et de fin des tâches<br /> * identifier les tâches critiques qui pourraient retarder le projet<br /> * définir les dates de fin du projet possibles en dehors des contraintes de ressources<br /> <br /> ==Représentation==<br /> <br /> Deux formalismes de représentation : <br /> <br /> ===Graphe de potentielles tâches / Méthode des antécédents===<br /> Plus souvent utilisé par la majorité des progiciels de planification et plus simple.<br /> <br /> Les noeuds représentent les '''tâches''', et les liens représentent l''''ordre d'exécution des tâches'''.<br /> <br /> Le type de lien fin-début est le plus couramment utilisé. <br /> <br /> *'''Tâche A''' -&gt; +/- n jours -&gt; '''Tâche B'''<br /> <br /> La tâche A doit être terminée pour que la tâche B puisse commencer. La tâche A est donc le prédécesseur de la tâche B, et la tâche B est le successeur de la tâche A.<br /> <br /> ===Graphe de potentiels événements / Méthode du diagramme fléché===<br /> <br /> Les noeuds représentent les '''événements''', appelés jalons, et les liens représentent les '''tâches'''.<br /> <br /> ==Paramètres de la technique PERT==<br /> <br /> La technique PERT permet '''d'identifier les chemins qui comportent des tâches critiques''' qui peuvent retarder le projet si elles sont elles-mêmes en retard. <br /> <br /> Paramètres clés attachés à chaque tâche du réseau PERT :<br /> *'''Les dates au plus tôt''' : <br /> **Début de la tâche au plus tôt (D+tôt)<br /> **Fin de la tâche au plus tôt (F+tôt)<br /> *'''Les dates au plus tard ''': <br /> **Début de la tâche au plus tard (D+tard)<br /> **Fin de la tâche au plus tard (F+tard)<br /> *'''La marge'''<br /> **Différence entre la date au plus tard et la date au plus tôt de la tâche Ti. Elle peut être calculée sur les date de début OU sur les dates de fin. <br /> **Elle représente la latitude dont on dispose quand on élabore de planning.<br /> <br /> Le '''chemin critique''' est le chemin du graphe sur lequel les marges sont nulles ou les plus faibles. <br /> <br /> =Diagramme de GANTT=<br /> <br /> Ce diagramme permet d'établir le '''calendrier'''/planning du projet sur l'axe du '''temps''' et l'axe des '''tâches''' ou des '''ressources humaines'''. Il permet donc d'affecter les tâches à des personnes ou à des profils de personnes (ressources humaines) sur le temps. La construction du planning est basée sur le graphe de PERT, et il est possible de représenter l'ensemble du diagramme avec les dates au plus tôt ou avec les dates au plus tard.<br /> <br /> Il prend en comptes les contraintes de '''calendrier''' (jours non ouvrables, jours fériés, etc.), de '''ressources humaines''', de '''matériel'''.<br /> <br /> ==Contraintes==<br /> <br /> On prend en compte les contraintes de liens entre les tâches : <br /> *On planifie '''en premier les tâches qui sont sur le chemin critique'''<br /> *Ensuite, on planifie les tâches qui sont liées aux tâches du chemin critique par des liens du type début-début, fin-fin.<br /> *Enfin, on place les tâches qui sont des prédécesseurs des tâches critiques.<br /> <br /> On prend également en compte les contraintes temporelles : <br /> *les dates imposées pour une ou plusieurs tâches<br /> *les jours fériés, fêtes nationales, etc.<br /> <br /> Les contraintes liées à la disponibilité des ressources humaines :<br /> *disponibilité des ressources spécialisées<br /> *pénurie de ressources<br /> -&gt; Il peut être nécessaire de revoir le graphe des antécédents et d'éliminer certains parallélisme de tâches<br /> <br /> Les contraintes d'exclusion : <br /> *Certaines tâches indépendantes ne peuvent pas être planifiées simultanément, souvent pour des raisons de sécurité. <br /> <br /> ==Techniques d'amélioration==<br /> <br /> ===Nivellement===<br /> <br /> Le nivellement permet de maintenir le nombre de personnes travaillant simultanément sur le projet en-dessous d'une certaine limite '''en augmentant la durée du projet.''' <br /> <br /> L'objectif est donc de '''réduire le nombre de ressources humaines''', et la démarche à utiliser est de niveler le diagramme en affectant les tâches de R2 à R1 et '''en allongeant la durée du projet'''.<br /> <br /> ===Lissage===<br /> <br /> Le lissage permet de répartir la charge de travail de chaque ressource de telle façon qu'elle ne se trouve à aucun moment en surcharge ou en sous-charge. Cette opération peut conduire à allonger les délais. <br /> <br /> Les raisons de ce lissages : <br /> *contraintes liées à l'utilisation des ressources humaines<br /> *contraintes liées à l'utilisation du matériel<br /> <br /> <br /> = Annexes =<br /> <br /> = Références =</div>

Sania https://baripedia.org/index.php?title=Techniques_de_planification&diff=32334 2016-06-04T17:36:22Z

<p>Sania : </p> <hr /> <div>{{Infobox Lecture<br /> | image = <br /> | cours = [[Gestion de projet]]<br /> | faculté = [[Faculté d'économie et de management]]<br /> | département = [[Services généraux GSEM]]<br /> | domaine = [[Système d'information]]<br /> | professeurs = [[Jolita Ralyte]]&lt;ref&gt;[http://cui.unige.ch/~ralyte/ Page personnelle de Jolita Ralyte sur le site du CUI]&lt;/ref&gt;<br /> | années = <br /> | code = S204033 CR &lt;ref&gt;[http://wadme.unige.ch:3149/pls/opprg/w_det_cours.debut?p_code_cours=S204033&amp;p_plan_is=0&amp;p_langue=1&amp;p_frame=N&amp;p_mode=PGC&amp;p_annee=2015&amp;p_suffixe=&amp;p_grtri= Présentation du cours sur le site du catalogue de cours wadme]&lt;/ref&gt;<br /> | enregistrement = <br /> | précédent = <br /> | suivant = [[Projet de mise en place d'un ERP]]<br /> }}<br /> <br /> Dans la gestion des projets SI, PERT et GANTT sont deux techniques de planification complémentaires.<br /> <br /> Avant tout, on doit faire un découpage de type WBS (voir le cours [[Découpage de projets]]) et reprendre les caractéristiques de chacun des éléments afin de construire un '''réseau PERT'''. On part d'une liste de tâches et de la durée estimée de chacune d'elles pour se concentrer sur les contraintes d'ordonnancement de ces tâches et sur les possibilités de parallélisme.<br /> <br /> Ensuite, on fait un calendrier de travail avec un '''diagramme de Gantt'''.<br /> <br /> =Réseau PERT=<br /> <br /> Program Evaluation and Review Technique, aussi dit graphe d'ordonnancement, c'est un '''graphe orienté''' qui permet de '''représenter les contraintes d'enchaînement''' entre les différentes tâches à réaliser pour mener à bien le projet.<br /> <br /> '''Cette technique permet de :'''<br /> * définir l'ordonnancement des tâches<br /> * introduire le parallélisme des tâches<br /> * définir les dates de début et de fin des tâches<br /> * identifier les tâches critiques qui pourraient retarder le projet<br /> * définir les dates de fin du projet possibles en dehors des contraintes de ressources<br /> <br /> ==Représentation==<br /> <br /> Deux formalismes de représentation : <br /> <br /> ===Graphe de potentielles tâches / Méthode des antécédents===<br /> Plus souvent utilisé par la majorité des progiciels de planification et plus simple.<br /> <br /> Les noeuds représentent les '''tâches''', et les liens représentent l''''ordre d'exécution des tâches'''.<br /> <br /> Le type de lien fin-début est le plus couramment utilisé. <br /> <br /> *'''Tâche A''' -&gt; +/- n jours -&gt; '''Tâche B'''<br /> <br /> La tâche A doit être terminée pour que la tâche B puisse commencer. La tâche A est donc le prédécesseur de la tâche B, et la tâche B est le successeur de la tâche A.<br /> <br /> ===Graphe de potentiels événements / Méthode du diagramme fléché===<br /> <br /> Les noeuds représentent les '''événements''', appelés jalons, et les liens représentent les '''tâches'''.<br /> <br /> ==Paramètres de la technique PERT==<br /> <br /> La technique PERT permet '''d'identifier les chemins qui comportent des tâches critiques''' qui peuvent retarder le projet si elles sont elles-mêmes en retard. <br /> <br /> Paramètres clés attachés à chaque tâche du réseau PERT :<br /> *'''Les dates au plus tôt''' : <br /> **Début de la tâche au plus tôt (D+tôt)<br /> **Fin de la tâche au plus tôt (F+tôt)<br /> *'''Les dates au plus tard ''': <br /> **Début de la tâche au plus tard (D+tard)<br /> **Fin de la tâche au plus tard (F+tard)<br /> *'''La marge'''<br /> **Différence entre la date au plus tard et la date au plus tôt de la tâche Ti. Elle peut être calculée sur les date de début OU sur les dates de fin. <br /> **Elle représente la latitude dont on dispose quand on élabore de planning.<br /> <br /> Le '''chemin critique''' est le chemin du graphe sur lequel les marges sont nulles ou les plus faibles. <br /> <br /> =Diagramme de GANTT=<br /> <br /> Ce diagramme permet d'établir le '''calendrier'''/planning du projet sur l'axe du '''temps''' et l'axe des '''tâches''' ou des '''ressources humaines'''. Il permet donc d'affecter les tâches à des personnes ou à des profils de personnes (ressources humaines) sur le temps. La construction du planning est basée sur le graphe de PERT, et il est possible de représenter l'ensemble du diagramme avec les dates au plus tôt ou avec les dates au plus tard.<br /> <br /> Il prend en comptes les contraintes de '''calendrier''' (jours non ouvrables, jours fériés, etc.), de '''ressources humaines''', de '''matériel'''.<br /> <br /> ==Contraintes==<br /> <br /> On prend en compte les contraintes de liens entre les tâches : <br /> *On planifie '''en premier les tâches qui sont sur le chemin critique'''<br /> *Ensuite, on planifie les tâches qui sont liées aux tâches du chemin critique par des liens du type début-début, fin-fin.<br /> *Enfin, on place les tâches qui sont des prédécesseurs des tâches critiques.<br /> <br /> On prend également en compte les contraintes temporelles : <br /> *les dates imposées pour une ou plusieurs tâches<br /> *les jours fériés, fêtes nationales, etc.<br /> <br /> Les contraintes liées à la disponibilité des ressources humaines :<br /> *disponibilité des ressources spécialisées<br /> *pénurie de ressources<br /> -&gt; Il peut être nécessaire de revoir le graphe des antécédents et d'éliminer certains parallélisme de tâches<br /> <br /> Les contraintes d'exclusion : <br /> *Certaines tâches indépendantes ne peuvent pas être planifiées simultanément, souvent pour des raisons de sécurité. <br /> <br /> ==Techniques d'amélioration==<br /> <br /> ===Nivellement===<br /> <br /> Le nivellement permet de maintenir le nombre de personnes travaillant simultanément sur le projet en-dessous d'une certaine limite '''en augmentant la durée du projet.''' <br /> <br /> L'objectif est donc de '''réduire le nombre de ressources humaines''', et la démarche à utiliser est de niveler le diagramme en affectant les tâches de R2 à R1 et '''en allongeant la durée du projet'''.<br /> <br /> ===Lissage===<br /> <br /> Le lissage permet de répartir la charge de travail de chaque ressource de telle façon qu'elle ne se trouve à aucun moment en surcharge ou en sous-charge. Cette opération peut conduire à allonger les délais. <br /> <br /> Les raisons de ce lissages : <br /> *contraintes liées à l'utilisation des ressources humaines<br /> *contraintes liées à l'utilisation du matériel<br /> <br /> <br /> = Annexes =<br /> <br /> = Références =</div>

Sania https://baripedia.org/index.php?title=Techniques_de_planification&diff=32333 2016-06-04T17:02:12Z

<p>Sania : </p> <hr /> <div>{{Infobox Lecture<br /> | image = <br /> | cours = [[Gestion de projet]]<br /> | faculté = [[Faculté d'économie et de management]]<br /> | département = [[Services généraux GSEM]]<br /> | domaine = [[Système d'information]]<br /> | professeurs = [[Jolita Ralyte]]&lt;ref&gt;[http://cui.unige.ch/~ralyte/ Page personnelle de Jolita Ralyte sur le site du CUI]&lt;/ref&gt;<br /> | années = <br /> | code = S204033 CR &lt;ref&gt;[http://wadme.unige.ch:3149/pls/opprg/w_det_cours.debut?p_code_cours=S204033&amp;p_plan_is=0&amp;p_langue=1&amp;p_frame=N&amp;p_mode=PGC&amp;p_annee=2015&amp;p_suffixe=&amp;p_grtri= Présentation du cours sur le site du catalogue de cours wadme]&lt;/ref&gt;<br /> | enregistrement = <br /> | précédent = <br /> | suivant = [[Projet de mise en place d'un ERP]]<br /> }}<br /> <br /> Dans la gestion des projets SI, PERT et GANTT sont deux techniques de planification complémentaires.<br /> <br /> Avant tout, on doit faire un découpage de type WBS (voir le cours [[Découpage de projets]]) et reprendre les caractéristiques de chacun des éléments afin de construire un réseau PERT. On part d'une liste de tâches et de la durée estimée de chacune d'elles pour se concentrer sur les contraintes d'ordonnancement de ces tâches et sur les possibilités de parallélisme.<br /> <br /> Ensuite, on fait un calendrier de travail avec un diagramme de Gantt.<br /> <br /> =Réseau PERT=<br /> <br /> Program Evaluation and Review Technique, aussi dit graphe d'ordonnancement, c'est un '''graphe orienté''' qui permet de '''représenter les contraintes d'enchaînement''' entre les différentes tâches à réaliser pour mener à bien le projet.<br /> <br /> '''Cette technique permet de :'''<br /> * définir l'ordonnancement des tâches<br /> * introduire le parallélisme des tâches<br /> * définir les dates de début et de fin des tâches<br /> * identifier les tâches critiques qui pourraient retarder le projet<br /> * définir les dates de fin du projet possibles en dehors des contraintes de ressources<br /> <br /> ==Représentation==<br /> <br /> Deux formalismes de représentation : <br /> <br /> ===Graphe de potentielles tâches / Méthode des antécédents===<br /> Plus souvent utilisé par la majorité des progiciels de planification et plus simple.<br /> <br /> Les noeuds représentent les '''tâches''', et les liens représentent l''''ordre d'exécution des tâches'''.<br /> <br /> Le type de lien fin-début est le plus couramment utilisé. <br /> <br /> *'''Tâche A''' -&gt; +/- n jours -&gt; '''Tâche B'''<br /> <br /> La tâche A doit être terminée pour que la tâche B puisse commencer. La tâche A est donc le prédécesseur de la tâche B, et la tâche B est le successeur de la tâche A.<br /> <br /> ===Graphe de potentiels événements / Méthode du diagramme fléché===<br /> <br /> Les noeuds représentent les '''événements''', appelés jalons, et les liens représentent les '''tâches'''.<br /> <br /> ==Paramètres de la technique PERT==<br /> <br /> La technique PERT permet '''d'identifier les chemins qui comportent des tâches critiques''' qui peuvent retarder le projet si elles sont elles-mêmes en retard. <br /> <br /> Paramètres clés attachés à chaque tâche du réseau PERT :<br /> *'''Les dates au plus tôt''' : <br /> **Début de la tâche au plus tôt (D+tôt)<br /> **Fin de la tâche au plus tôt (F+tôt)<br /> *'''Les dates au plus tard ''': <br /> **Début de la tâche au plus tard (D+tard)<br /> **Fin de la tâche au plus tard (F+tard)<br /> *'''La marge'''<br /> **Différence entre la date au plus tard et la date au plus tôt de la tâche Ti. Elle peut être calculée sur les date de début OU sur les dates de fin. <br /> **Elle représente la latitude dont on dispose quand on élabore de planning.<br /> <br /> Le '''chemin critique''' est le chemin du graphe sur lequel les marges sont nulles ou les plus faibles. <br /> <br /> =Diagramme de GANTT=<br /> <br /> <br /> <br /> = Annexes =<br /> <br /> = Références =</div>

Sania https://baripedia.org/index.php?title=Techniques_de_planification&diff=32332 2016-06-04T15:59:15Z

<p>Sania : </p> <hr /> <div>{{Infobox Lecture<br /> | image = <br /> | cours = [[Gestion de projet]]<br /> | faculté = [[Faculté d'économie et de management]]<br /> | département = [[Services généraux GSEM]]<br /> | domaine = [[Système d'information]]<br /> | professeurs = [[Jolita Ralyte]]&lt;ref&gt;[http://cui.unige.ch/~ralyte/ Page personnelle de Jolita Ralyte sur le site du CUI]&lt;/ref&gt;<br /> | années = <br /> | code = S204033 CR &lt;ref&gt;[http://wadme.unige.ch:3149/pls/opprg/w_det_cours.debut?p_code_cours=S204033&amp;p_plan_is=0&amp;p_langue=1&amp;p_frame=N&amp;p_mode=PGC&amp;p_annee=2015&amp;p_suffixe=&amp;p_grtri= Présentation du cours sur le site du catalogue de cours wadme]&lt;/ref&gt;<br /> | enregistrement = <br /> | précédent = <br /> | suivant = [[Projet de mise en place d'un ERP]]<br /> }}<br /> <br /> Dans la gestion des projets SI, PERT et GANTT sont deux techniques de planification complémentaires.<br /> <br /> Avant tout, on doit faire un découpage de type WBS (voir le cours [[Découpage de projets]]) et reprendre les caractéristiques de chacun des éléments afin de construire un réseau PERT. On part d'une liste de tâches et de la durée estimée de chacune d'elles pour se concentrer sur les contraintes d'ordonnancement de ces tâches et sur les possibilités de parallélisme.<br /> <br /> Ensuite, on fait un calendrier de travail avec un diagramme de Gantt.<br /> <br /> =Réseau PERT=<br /> <br /> <br /> <br /> <br /> = Annexes =<br /> <br /> = Références =</div>

Sania https://baripedia.org/index.php?title=Techniques_de_planification&diff=32331 2016-06-04T15:48:49Z

<p>Sania : Page créée avec « {{Infobox Lecture | image = | cours = Gestion de projet | faculté = Faculté d'économie et de management | département = Services généraux GSEM | do... »</p> <hr /> <div>{{Infobox Lecture<br /> | image = <br /> | cours = [[Gestion de projet]]<br /> | faculté = [[Faculté d'économie et de management]]<br /> | département = [[Services généraux GSEM]]<br /> | domaine = [[Système d'information]]<br /> | professeurs = [[Jolita Ralyte]]&lt;ref&gt;[http://cui.unige.ch/~ralyte/ Page personnelle de Jolita Ralyte sur le site du CUI]&lt;/ref&gt;<br /> | années = <br /> | code = S204033 CR &lt;ref&gt;[http://wadme.unige.ch:3149/pls/opprg/w_det_cours.debut?p_code_cours=S204033&amp;p_plan_is=0&amp;p_langue=1&amp;p_frame=N&amp;p_mode=PGC&amp;p_annee=2015&amp;p_suffixe=&amp;p_grtri= Présentation du cours sur le site du catalogue de cours wadme]&lt;/ref&gt;<br /> | enregistrement = <br /> | précédent = <br /> | suivant = [[Projet de mise en place d'un ERP]]<br /> }}<br /> <br /> Dans la gestion des projets SI, PERT et GANTT sont deux techniques de planification complémentaires.<br /> <br /> Avant tout, on doit faire un découpage de type WBS (voir le cours [[Découpage de projets]]) et reprendre les caractéristiques de chacun des éléments afin de construire un réseau PERT. On part d'une liste de tâches et de la durée estimée de chacune d'elles pour se concentrer sur les contraintes d'ordonnancement de ces tâches et sur les possibilités de parallélisme.<br /> <br /> Ensuite, on fait un calendrier de travail avec un diagramme de Gantt.<br /> <br /> =Réseau PERT=<br /> <br /> <br /> <br /> = Annexes =<br /> <br /> = Références =</div>

Sania https://baripedia.org/index.php?title=Gestion_du_risque_des_projets_SI&diff=32330 2016-06-04T15:48:33Z

<p>Sania : </p> <hr /> <div>{{Infobox Lecture<br /> | image = <br /> | cours = [[Gestion de projet]]<br /> | faculté = [[Faculté d'économie et de management]]<br /> | département = [[Services généraux GSEM]]<br /> | domaine = [[Système d'information]]<br /> | professeurs = [[Jolita Ralyte]]&lt;ref&gt;[http://cui.unige.ch/~ralyte/ Page personnelle de Jolita Ralyte sur le site du CUI]&lt;/ref&gt;<br /> | années = <br /> | code = S204033 CR &lt;ref&gt;[http://wadme.unige.ch:3149/pls/opprg/w_det_cours.debut?p_code_cours=S204033&amp;p_plan_is=0&amp;p_langue=1&amp;p_frame=N&amp;p_mode=PGC&amp;p_annee=2015&amp;p_suffixe=&amp;p_grtri= Présentation du cours sur le site du catalogue de cours wadme]&lt;/ref&gt;<br /> | enregistrement = <br /> | précédent = <br /> | suivant = [[Techniques de planification ]]<br /> }}<br /> <br /> =Gestion du risque=<br /> <br /> La gestion du risque est d'une importance primordiale dans le développement des SI. C'est un ensemble des principes et des pratiques ayant comme objectif '''identifier, analyser, et traiter les facteurs de risque''' afin d'améliorer les chances d'obtenir avec succès le résultat attendu du projet.<br /> <br /> * '''Avant le projet''' : identification et évaluation du risque<br /> * '''Pendant le projet''' : suivi et contrôle du risque<br /> * '''Après le projet''' : capitalisation de l'expérience<br /> <br /> '''Exemples de risque dans les projets SI'''<br /> * Le projet ne débouche pas sur un résultat attendu<br /> * Le projet consomme trop de ressources<br /> * Le projet dure trop longtemps<br /> * Le système ne remplit pas la fonction attendue<br /> * Les utilisateurs n'acceptent pas le système <br /> * Le fonctionnement du système est trop coûteux<br /> <br /> ''&quot;Le taux élevé d'échec s'explique par le fait que les gestionnaires ne prennent pas des mesures afin d'évaluer et de gérer les risques impliqués dans le projet&quot;'' (Keil et al., 1998)<br /> <br /> ''&quot;Les post-mortem des projets échoués indiquent que les problèmes auraient pu être évités s'il y avait eu une identification et une résolution rapide des éléments à hauts risques.&quot;'' (Boehm, 1991)<br /> <br /> La gestion du risque permet d'éviter le désastre ainsi que le travail superflu, de régler et équilibrer les efforts et de stimuler les situations &quot;win-win&quot;.<br /> <br /> La plupart des projets SI sont à l'origine des changements organisationnels. Leur succès peut donc être crucial pour la réalisation des objectifs économiques de l'organisation.<br /> <br /> =Définitions du risque=<br /> <br /> ''Le '''risque''' est une exposition aux facteurs spécifiques qui présentent une menace pour obtenir les résultats attendus du projet.'' (Bannerman, 2008)<br /> <br /> C'est une mesure de la probabilité et de l'impact de non réalisation de l'objectif du projet.<br /> * '''R = P x I'''<br /> '''R''' = exposition à un facteur particulier du risque. '''P''' = probabilité qu'un événement indésirable arrive. '''I''' = impact ou ampleur des pertes si l'événement arrive.<br /> <br /> '''Selon la définition probabilistique : '''<br /> * tous les facteurs potentiels du risque doivent être identifiés au début du projet<br /> * l'exposition au risque est estimée pour chaque facteur<br /> * les facteurs sont classés en fonction de leur priorité afin d'identifier les facteurs les plus menaçants<br /> * focalisation sur les facteurs à haut risque pour minimiser leur probabilité d'occurrence ou l'ampleur de leur impact<br /> <br /> '''Limitations de la définition probabilistique : '''<br /> * il est difficile d'estimer la probabilité et l'impact de plusieurs facteurs<br /> * il est plus facile d'évaluer le risque sur une échelle simple (ex. : bas, moyen, haut) que de calculer sa probabilité<br /> * couplage fort entre l'événement et les conséquences du risque sans prendre en considération la vulnérabilité et les capacités de l'organisation à répondre à la menace<br /> * la définition n'inclut que les menaces connues<br /> <br /> =Démarche de gestion du risque= <br /> <br /> * '''Identifier els risques''' -&gt; facteurs de risque<br /> * '''Évaluer l'impact des risques sur les coûts, le délai, et la qualité''' -&gt; profil du risque, matrice de probabilité/impact<br /> * '''Identifier et mettre en place les actions aptes à réduire les risques inacceptables''' -&gt; stratégies de gestion du risque<br /> * '''Suivre les actions et contrôler l'état des risques'''<br /> * '''Capitaliser l'expérience'''<br /> <br /> ==Principaux facteurs de risque==<br /> <br /> * La taille du projet<br /> * La difficulté technique<br /> * Le degré d'intégration<br /> * La configuration organisationnelle<br /> * Le changement<br /> * L'instabilité de l'équipe de projet<br /> <br /> ===La taille du projet===<br /> <br /> *Le risque est lié aux limites de l'individu<br /> **Un grand projet signifie une large étendue du domaine couvert et impose un partage du travail entre un nombre important de personnes<br /> *Il est difficile à gérer le processus de la production et l'intégration des travaux de plusieurs équipes<br /> <br /> '''Critères'''<br /> *Durée du projet (en mois)<br /> *Charge du projet (en mois/personne)<br /> *Couverture fonctionnelle (nombre de processus<br /> <br /> <br /> {| class=&quot;wikitable&quot;<br /> |-<br /> ! Facteur !! Degré !! Métrique<br /> |-<br /> | '''Durée du projet''' || 1 || =&lt; 6 mois<br /> |-<br /> | || 2 || =&lt; 18 mois<br /> |-<br /> | || 3 || =&lt; 30 mois<br /> |-<br /> | || 4 || &gt; 30 mois<br /> |-<br /> | '''Charge du projet''' || 1 || =&lt; 20 mois/personne<br /> |-<br /> | || 2 || =&lt; 120 mois/personne<br /> |-<br /> | || 3 || =&lt; 300 mois/personne<br /> |-<br /> | || 4 || &gt; 300 mois/personne<br /> |-<br /> | '''Couverture fonctionnelle''' || 1 || =&lt; 2 processus<br /> |-<br /> | || 2 || =&lt; 6 processus<br /> |-<br /> | || 3 || =&lt; 10 processus<br /> |-<br /> | || 4 || &gt; 10 processus<br /> |}<br /> <br /> <br /> ===La difficulté technique===<br /> <br /> *Le risque correspond à une nouveauté technologique ou une difficulté technique provenant des contraintes imposées au projet.<br /> **''Ex. : contraintes de performance, de langage, d'architecture, ...''<br /> *Le risque est l'absence de compétences techniques nécessaires, qui pénalise la production<br /> <br /> '''Critères'''<br /> *Expérience de l'entreprise sur les techniques à utiliser (nombre de projets)<br /> **Expérience sur l'architecture, le langage de programmation, le SGBD<br /> *Expérience du marché sur les techniques à utiliser (nombre de références)<br /> **Expérience sur l'architecture, le langage de programmation, le SGBD<br /> *Contrainte de performance (de 0 à très élevée)<br /> *Responsabilité de la direction informatique (degré de responsabilité)<br /> <br /> <br /> ===Le degré d'intégration===<br /> <br /> *Le degré d'intégration mesure le degré de dépendance ou d'autonomie du futur SI<br /> **Plus le SI en construction doit collaborer avec d'autres systèmes de l'entreprise, plus il est difficile d'identifier clairement l'impact de choix de conception<br /> **D'autres entités, d'autres équipes, d'autres projets de développement peuvent être concernés, ce qui augmente le nombre d'acteurs du projet<br /> <br /> '''Critères'''<br /> *Nombre de flux avec des applications connexes<br /> *Nombre d'applications connexes en évolution<br /> <br /> ===La configuration organisationnelle===<br /> <br /> *Ce facteur correspond à l'étendue de l'entreprise qui est touchée par le projet<br /> **Le risque provient de la lourdeur des procédures de participation et de décision quand plusieurs grandes entités de l'entreprise (les directions) sont parties prenantes du projet. La production en est ralentie.<br /> *Éventuels conflits politiques et organisationnels peuvent bloquer les prises de décision et ralentir le processus de développement<br /> <br /> '''Critères'''<br /> *Nombre de directions assurant la MOA<br /> *Existence et implication d'un sponsor<br /> *Pérennité du sponsor<br /> *Appui de la direction générale<br /> <br /> ===Le changement===<br /> <br /> *Le risque de '''mauvaise définition du futur système''' à cause d'un changement métier ou organisationnel<br /> **Le changement visé par le projet signifie que le système de gestion et/ou d'organisation existants ne peuvent pas être pris comme référence stable et que l'effort de conception et d'innovation va être important.<br /> <br /> '''Critères'''<br /> *Degré d'évolution organisationnelle (écart par rapport à l'existant)<br /> *Degré d'évolution fonctionnelle (écart par rapport à l'existant)<br /> *Degré d'évolution technique (écart par rapport à l'existant)<br /> *Impact social (conséquences sur effectif et salaire)<br /> *Nombre de sites concernés<br /> <br /> ===L'instabilité de l'équipe de projet===<br /> <br /> *Le risque est lié au '''départ de certains membres de l'équipe''' durant le projet <br /> **Problème du '''transfert de connaissances''' : les concepteurs engrangent un ensemble de connaissances implicites sur le projet et son domaine que des modèles formalisés ne suffissent pas à transmettre<br /> **Risque de mauvaise interprétation de la conception faite par d'autres personnes, ce qui peut avoir des conséquences sur les délais et la cohérence de la réalisation.<br /> <br /> '''Critères'''<br /> *Durée du projet (en mois<br /> *Sous-traitance de MOA (en %)<br /> * Mobilité dans l'entreprise (degré)<br /> * Relation MOA - MOE (niveau de relations)<br /> * Techniques attrayantes (niveau d'attractivité)<br /> * Marché de l'emploi (niveau de difficulté)<br /> * Image du projet (degré de valorisation)<br /> <br /> ==Évaluation du degré de risque==<br /> <br /> Le degré de risque de chaque facteur est calculé avec la formule :<br /> <br /> Degré de risque d'un facteur = Somme (degré de chaque critère*pondération) / somme des pondérations.<br /> <br /> Une pondération peut être définie pour majorer l'importance d'un critère dans le facteur étudié. <br /> <br /> Le profil du risque permet ainsi de faire apparaître les risques majeurs qui présentent un degré élevé (si la moyenne des risques dépasse 3 sur 4, l'échec est inévitable).<br /> <br /> =Les stratégies de gestion du risque=<br /> <br /> *'''Fuite'''<br /> Recherche des moyens pour '''éviter l'effet négatif du risque''' sur le projet. <br /> <br /> ''Exemple : modification de la solution conceptuelle du projet - élimination ou modification de certaines fonctionnalités et/ou propriétés.''<br /> <br /> *'''Transfert'''<br /> '''Déplacement de la responsabilité du risque à un tiers'''; n'élimine pas la menace mais délègue la responsabilité de sa gestion à quelqu'un d'autre.<br /> <br /> ''Exemple : assurance, contrat de sous-traitance, outsourcing.''<br /> <br /> *'''Mitigation'''<br /> '''Réduction de la menace''' en réduisant la probabilité et/ou l'impact du risque.<br /> <br /> ''Exemple : amélioration de la participation des utilisateurs, formation des développeurs, choix des méthodes, etc.''<br /> <br /> *'''Acceptation''' passive ou active<br /> <br /> '''Passive''' : quand la menace n'est pas importante et/ou la source du risque est externe au projet.<br /> <br /> '''Active''' : quand le menace est réelle mais qu'il n'y a rien à faire avant son apparition; un plan de contingence peut être prévu.<br /> <br /> ''Exemple : budget et/ou ressources supplémentaires, plan d'action, etc.''<br /> <br /> =Solutions pour chaque facteur=<br /> <br /> ==La taille du projet==<br /> <br /> * Découper le projet en sous-projets<br /> * Choisir un modèle de '''développement évolutif''' et '''incrémental'''. Exemple : le modèle de la '''Spirale''' où chaque cycle permet l'analyse du risque et la redéfinition des objectifs.<br /> * Choisir un dispositif de coordination formel pour gérer l'avancement d'une équipe importante<br /> <br /> ==La difficulté technique==<br /> <br /> * Différer l'introduction d'une ou plusieurs innovations<br /> * Rechercher les compétences nécessaires<br /> * Si les besoins sont stables, le risque majeur est lié à la programmation, alors les modèles de type '''Cascade''' ou '''RAD''' permettent de se focaliser sur la programmation<br /> * Sinon, choisir le '''modèle en W''' qui insiste sur les tests systématiques<br /> <br /> ==Le degré d'intégration==<br /> <br /> * Intégrer dans le projet les acteurs qui connaissent bien les autres systèmes avec lesquels le SI doit s'intégrer<br /> * Les''' modèles en V''' et '''W''' facilitent l'intégration modulaire<br /> <br /> ==La configuration organisationnelle==<br /> <br /> *Limiter le champ de participation de chaque membre exécutif<br /> *Privilégier le '''développement évolutif''' et '''incrémental'''<br /> <br /> ==Le changement==<br /> <br /> * Réduire l'incertitude en modifiant le champ du projet ou ses caractéristiques<br /> * Intégrer des acteurs qui ont le pouvoir de prendre les décisions stratégiques <br /> * Utiliser les techniques facilitant la créativité et l'exploration<br /> * Les modèles de '''développement évolutif''' et '''RUP''' permettent de gérer les besoins qui s'éclaircissent en cours du projet.<br /> <br /> ==L'instabilité de l'équipe de projet==<br /> <br /> * Obliger la documentation détaillée de chaque produit et activité du projet - un système d'information sur le futur système (documentation du projet)<br /> * Superviser les personnes à risque, ce qui favorise la transmission des connaissances<br /> <br /> =Conclusion=<br /> <br /> *'''La gestion du risque s'attaque en premier lieu aux facteurs humains et non techniques''' : il n'y a pas de recette miracle, il faut avant tout beaucoup de jugement.<br /> (Boehm, 1991)<br /> <br /> *'''La gestion du risque doit devenir une part entière de la méthodologie de développement et non pas une activité séparée'''<br /> (Kwak &amp; Stoddard, 2002)<br /> <br /> *'''Implantation progressive dans les organisations'''<br /> (Boehm, 1991)<br /> <br /> ==Le top 10 des facteurs de risque==<br /> <br /> Selon Boehm, 1991 : <br /> *Manque de personnel compétent<br /> * Budgets et échéances irréalistes<br /> * Mauvaises fonctionnalités développées<br /> * Mauvaise interface développée<br /> * Gold plating (addition de plus de fonctionnalités/propriétés que ce qu'il est nécessaire)<br /> * Demandes de changement continuelles<br /> * Pénurie de composantes acquises à l'externe<br /> * Problèmes au niveau des tâches confiées à l'externe<br /> * Problèmes de performance en temps réel<br /> * Limite des capacités informatiques<br /> <br /> = Annexes =<br /> <br /> = Références =</div>

Sania https://baripedia.org/index.php?title=Mod%C3%A8les_de_processus_de_d%C3%A9veloppement_des_SI&diff=32329 2016-06-04T15:39:16Z

<p>Sania : </p> <hr /> <div>{{Infobox Lecture<br /> | image = <br /> | cours = [[Gestion de projet]]<br /> | faculté = [[Faculté d'économie et de management]]<br /> | département = [[Services généraux GSEM]]<br /> | domaine = [[Système d'information]]<br /> | professeurs = [[Jolita Ralyte]]&lt;ref&gt;[http://cui.unige.ch/~ralyte/ Page personnelle de Jolita Ralyte sur le site du CUI]&lt;/ref&gt;<br /> | années = <br /> | code = S204033 CR &lt;ref&gt;[http://wadme.unige.ch:3149/pls/opprg/w_det_cours.debut?p_code_cours=S204033&amp;p_plan_is=0&amp;p_langue=1&amp;p_frame=N&amp;p_mode=PGC&amp;p_annee=2015&amp;p_suffixe=&amp;p_grtri= Présentation du cours sur le site du catalogue de cours wadme]&lt;/ref&gt;<br /> | enregistrement = <br /> | précédent = <br /> | suivant = [[Gestion du risque des projets SI]]<br /> }}<br /> <br /> =Processus de Développement des SI=<br /> Ensemble structuré d'activités à réaliser pour atteindre l'objectif d'un projet SI, dont les activités varient en fonction de l'organisation, du projet, et du type de système à développer. Ce processus doit être explicitement décrit pour être adéquatement géré.<br /> <br /> Le '''cycle de vie d'un SI''' décrit succintement les phases par lesquelles passe un système d'information depuis le '''besoin initial''' jusqu'au '''retrait du système''', la documentation et les décisions qui jalonnent le cycle.<br /> <br /> =Activités de développement des SI=<br /> <br /> *'''Spécification''' des exigences et des contraintes du système, établissement du cahier des charges<br /> *'''Conception''' de la solution, production d'un modèle du système à développer<br /> *'''Implémentation''' du système<br /> *'''Test''' du système, vérification de l'adéquation entre les propriétés implémentées du système et la spécification des besoins<br /> *'''Installation''' du système chez le client et vérification de son fonctionnement<br /> *'''Maintenance''' du système, réparation des fautes<br /> <br /> =Modèles standards de développement des SI=<br /> <br /> Il existe différents types de cycles de développement entrant dans la réalisation d'un logiciel. Ces cycles prendront en compte toutes les activités/étapes de développement des SI vus dans le point précédent.<br /> <br /> <br /> ==Code-and-fix==<br /> <br /> Modèle dirigé par la programmation.<br /> <br /> '''Compréhension du problème''' -&gt; '''Programmation''' -&gt; '''Test contre spécification''' -&gt; '''Fin''' si satisfait, sinon '''Mise au point du code''' et retour au '''Test contre spécification'''<br /> <br /> ==Transformation automatique==<br /> <br /> Développement basé sur la possibilité de transformer automatiquement des spécifications validées en programmes.<br /> <br /> Ce modèle nécessite un '''outil logiciel''' qui fait de telles transformations.<br /> <br /> '''Spécification''' -&gt; '''Validation''' -&gt; '''Transformation''' si validé, sinon retour à '''Spécification'''.<br /> <br /> ==Cascade / Waterfall==<br /> [[Fichier:Processus cascade waterfall.png|cadre|centré|Processus de développement en cascade/waterfall]]<br /> <br /> Processus de nature plutôt linéaire, centré '''activités''' avec un ordonnancement prédéfini des activités, dans lequel il est toujours possible de revenir en arrière. Ce modèle est hérité de l'industrie lourde (construction de bâtiments, usines, etc.). Les phases nécessitent de plus en plus de ressources. Ce modèle est donc plus adapté aux grands projets de développement qui n'offrent que peu de possibilités d'interactions avec tous les membres de l'équipe qui dépassent la centaine.<br /> <br /> ===Initiation - Étude de faisabilité===<br /> <br /> *Analyser le problème<br /> *Définir les objectifs<br /> *Définir les frontières du système<br /> *Identifier les contraintes imposées (politiques, matériel, temps, technologies, etc.)<br /> *'''Évaluer la faisabilité technique, économique, opérationnelle.'''<br /> <br /> ===Spécification des exigences===<br /> <br /> *Définir le périmètre du SI<br /> *Analyser le domaine d'application<br /> *Identifier les exigences :<br /> **fonctionnelles : les activités de l'organisation qui devraient être couvertes par le SI<br /> **non fonctionnelles : les performances techniques, l'environnement d'utilisateur, système d'exploitation, matériel, etc.<br /> *Conceptualiser les besoins (cas d'utilisation, scénarios, objectifs, etc.)<br /> *Déterminer la priorité des besoins<br /> *Valider les exigences avec les utilisateurs<br /> *Élaborer un glossaire de termes<br /> <br /> ===Analyse===<br /> '''Exploration des solutions possibles : '''<br /> *Analyser les exigences<br /> *Proposer une ou plusieurs solutions conceptuelles <br /> **Vue structurelle du système (modèle objet)<br /> **Vue dynamique du système (cycle de vie des objets, diagrammes d'activités, etc.)<br /> *Proposer une architecture d'implémentation<br /> *Valider toutes les propositions avec les utilisateurs<br /> <br /> ===Conception===<br /> '''Spécification détaillée de la solution choisie :'''<br /> *Définir le modèle physique de la base de données<br /> *Définir les contraintes d'intégrité<br /> *Choisir le SGBD<br /> *Modéliser les interfaces utilisateur<br /> *Définir les standards de sécurité du système<br /> *Définir l'architecture du système<br /> <br /> ===Construction===<br /> '''Développement du code : '''<br /> *Créer les programmes<br /> *Créer et remplir les bases de données<br /> *Intégrer les sous-systèmes<br /> *Écrire la documentation<br /> <br /> ===Tests===<br /> *Tester les programmes<br /> *Tester le système global<br /> <br /> ===Mise en place===<br /> *S'assurer que tout le matériel et les réseaux nécessaires pour le nouveau SI sont mis en place<br /> *Installer le système<br /> *Former l'utilisateur<br /> <br /> ==Modèle en V==<br /> [[Fichier:Processus modele V.png|cadre|centré|Méthode de développement en V]]<br /> <br /> Décomposition du système en composants qui peuvent être développés de manière indépendante. Ce modèle permet d'avoir une meilleure réactivité que le modèle en cascade : il permet de limiter les retours en arrière en cas d'anomalie.<br /> <br /> ==Modèle en W==<br /> [[Fichier:Processus modele W.png|cadre|centré|Modèle de développement en W]]<br /> <br /> Ce modèle est une extension du modèle en V, qui améliore l'étape d'analyse des exigences.<br /> <br /> ===Modèle en W : accent sur les tests===<br /> [[Fichier:Processus modele W-tests.png|cadre|centré|Modèle de développement en W avec accent sur les tests]]<br /> <br /> Ce modèle est toujours une extension du modèle en V, mais avec une focalisation sur les '''tests''' à toutes les phases de développement.<br /> <br /> ==Développement évolutif==<br /> <br /> Développement de plusieurs versions d'un logiciel en l'améliorant à chaque fois.<br /> <br /> '''Détermination des besoins''' -&gt; '''Programmation''' -&gt; '''Expérimentation''' -&gt; '''Version N''' -&gt; '''Détermination des besoins''' -&gt; ...<br /> <br /> ==Spirale==<br /> [[Fichier:Processus spirale.png|cadre|centré|Modèle de développement en spirale]]<br /> <br /> Ce modèle reprend les différentes étapes du modèle en V en mettant un accent sur la gestion du risque, qui se retrouve à chaque début d'itération de la spirale.<br /> <br /> ==RAD - Rapid Application Development==<br /> <br /> [[Fichier:Processus RAD.png|vignette|droite|Modèle de développement RAD]]<br /> <br /> Le RAD est un modèle '''linéaire''' en 5 phases et '''itératif''' pour la phase de construction. Chaque phase est composée d'une ou plusieurs étapes, et chaque étape est organisée en 3 temps :<br /> #Travaux préparatoires<br /> #Session participative<br /> #Travaux de conclusion<br /> <br /> Le logiciel est construit en plusieurs modules livrés successivement, et il privilégie aussi le travail d'équipe.<br /> <br /> ===Initialisation===<br /> '''Préparation et organisation du projet'''<br /> *Répertorier l'ensemble des intervenants<br /> *Définir les objectifs stratégiques du projet<br /> * Évaluer la faisabilité du projet<br /> * Évaluer les moyens nécessaires <br /> * Établir un accord entre le client et le fournisseur<br /> * Lancement du projet<br /> <br /> ===Cadrage===<br /> '''Analyse et spécification des exigences :'''<br /> * Définir la hiérarchie des objectifs<br /> * Définir la hiérarchie des fonctions<br /> * Planifier les changements des processus &quot;métier&quot;<br /> * Définir les ressources nécessaires et le cycle de développement<br /> * Valider les objectifs et les contraintes<br /> <br /> ===Conception===<br /> '''Conception de la solution : '''<br /> *Modéliser :<br /> **Établir une liste détaillée des fonctionnalités<br /> **Créer le modèle de données exhaustif<br /> *Préparer la documentation technique<br /> * Valider la conception d'ensemble<br /> * Choisir les technologies et les valider<br /> * Valider les modèles et le prototype<br /> * Valider les charges et le planning<br /> <br /> ===Construction===<br /> '''Développement collaboratif et incrémental'''<br /> * Détailler chaque module<br /> * Réaliser (coder) les modules<br /> * Intégrer les modules<br /> * Tester les modules<br /> * Tester l'intégration<br /> * Documenter<br /> Différents modules peuvent être développés en parallèle<br /> <br /> ===Finalisation===<br /> '''Préparer la mise en oeuvre :'''<br /> * Préparer le système à l'installation<br /> * Rédiger les manuels utilisateurs<br /> * Rédiger le manuel d'exploitation<br /> * Préparer la formation<br /> * Établir le plan de formation<br /> * Établir le plan de démarrage (reprises de données, bascule technique,...)<br /> '''Tester le système'''<br /> '''Démarrer le système :'''<br /> * Établir l'environnement d'exploitation et l'infrastructure du support d'exploitation<br /> * Mettre en oeuvre le plan de démarrage<br /> * Audit du fonctionnement et évaluation des écarts<br /> * Améliorer et optimiser le système<br /> * Former les utilisateurs<br /> <br /> ==RUP - Rational Unified Process==<br /> Processus itératif et incrémental divisé en 4 phases : <br /> #Initialisation : définition de l'objectif du projet et préparation d'un contrat de réalisation<br /> #Élaboration : planification du projet, spécification de la solution proposée, proposition d'une architecture de base<br /> #Construction : développement du produit<br /> #Transition : transition du produit chez les utilisateurs.<br /> Ces 4 phases sont elles-mêmes divisées en N itération, à la fin desquelles Il y a une version du produit livrable.<br /> <br /> ===Workflows===<br /> Étapes à réaliser dans chaque itération :<br /> * Modélisation d'entreprise (entreprise/business modeling)<br /> * Analyse des besoins<br /> * Analyse et conception<br /> * Implémentation<br /> * Test<br /> * Déploiement<br /> * Gestion de changements<br /> * Gestion de projet<br /> * Préparation d'environnement<br /> <br /> ==XP - Extreme Progamming==<br /> Modèle itératif à deux niveaux :<br /> *'''Itérations de livraison''' - un plan de livraison doit être défini avec le client<br /> **une livraison - une version opérationnelle du logiciel<br /> **durée de développement - quelques mois<br /> *'''Itérations de développement''' - une fonctionnalité livrable est décomposée en plusieurs fonctions simples :<br /> **développement par binômes<br /> **les utilisateurs participent aux chois des itérations et aux tests<br /> **durée - 2-4 semaines<br /> **résultat - une ou plusieurs fonctions qui peuvent être intégrées dans la version livrable<br /> <br /> ===Rôles===<br /> *'''Programmeur''' : est responsable de la conception technique et le codage évolutif<br /> *'''Client''' : doit exprimer ses exigences sous forme de scénarios (user stories) et écrire des jeux de tests fonctionnels<br /> *'''Testeur''' : aide le client à élaborer des jeux de test et à les exécuter<br /> *'''Tracker''' : est responsable de la gestion du temps : planification et contrôle<br /> *'''Coach''' : est responsable du soutien technique des membres de l'équipe<br /> *'''Manager / chef de projet''' : les rôles peuvent être combinés : un chef de projet peut réunir les rôles de manager, tracker et coach. <br /> <br /> ==SCRUM==<br /> <br /> Développement itératif et incrémental, fait référence à l'organisation d'un jeu de rugby : <br /> * '''avant-jeu''' : préparation, conception de haut niveau du système et son architecture : le périmètre et la base du contenu du système<br /> *'''jeu''' : développement itératif organisé en sprints de 2-4 semaines<br /> *'''après-jeu''' : livraison finale du système, clôture du projet.<br /> <br /> ===Vocabulaire===<br /> *'''Product backlog'''<br /> Une liste priorisée de besoins et exigences que veut le client, exprimé dans son vocabulaire et sa terminologie métier, souvent en termes de scénarios (user stories)<br /> *'''Sprint backlog''' <br /> Une liste de tâches identifiées par l'équipe du projet à réaliser pendant un sprint afin d'implémenter les scénarios sélectionnés pour ce sprint.<br /> *'''Daily scrum'''<br /> Chaque jour on organise une courte réunion (15 minutes) pour fixer et/ou ajuster les objectifs de la journée<br /> *'''Product owner (propriétaire)'''<br /> Représente le client en ce qui concerne les spécifications des exigences et les acceptations<br /> *'''Scrum master (capitaine d'équipe)'''<br /> Anime au quotidien l'équipe de développement, recadre le projet en cas de difficulté. Ce rôle donne lieu à une certification<br /> *'''Team members (les membres d'équipe)'''<br /> Architectes, développeurs, testeurs, administrateurs de base de données, etc. Les mebres d'équipe disposent d'une certaine autonomie dans l'organisation de leurs travaux.<br /> <br /> ===User story==<br /> Le scénario est une exigence du système à développer, formulée en une ou deux phrases dans le langage de l'utilisateur. Ces user stories émergent au cours d'ateliers de travail menés avec le Métier, le Client et/ou les utilisateurs.<br /> <br /> '''Le modèle de structure d'une User Story'''<br /> <br /> * En tant tant que &lt;rôle, personne, user type&gt;<br /> * Je veux &lt;fonctionnalité, tâche, action&gt;<br /> * Afin de &lt;valeur ajoutée, résultat&gt;<br /> <br /> '''Exemples :'''<br /> <br /> * ''En tant qu'acheteur en ligne, je veux pouvoir ajouter des items à mon panier afin d'enregistrer mes achats que je ne souhaite pas acheter dans l'immédiat.''<br /> * ''En tant qu'utilisateur, je veux réserver une chambre d'hôtel afin de...''<br /> * ''En tant qu'utilisateur, je veux annuler une réservat5ion afin de...''<br /> * ''En tant que recruteur, je veux déposer des offres d'emploi afin de...''<br /> * ''En tant que je une diplômé, je veux déposer un CV afin de...''<br /> * ''En tant que jeune diplômé, je veux supprimer un CV afin de...''<br /> <br /> <br /> = Annexes =<br /> <br /> = Références =</div>

Sania https://baripedia.org/index.php?title=Gestion_du_risque_des_projets_SI&diff=32328 2016-06-04T15:39:08Z

<p>Sania : </p> <hr /> <div>{{Infobox Lecture<br /> | image = <br /> | cours = [[Gestion de projet]]<br /> | faculté = [[Faculté d'économie et de management]]<br /> | département = [[Services généraux GSEM]]<br /> | domaine = [[Système d'information]]<br /> | professeurs = [[Jolita Ralyte]]&lt;ref&gt;[http://cui.unige.ch/~ralyte/ Page personnelle de Jolita Ralyte sur le site du CUI]&lt;/ref&gt;<br /> | années = <br /> | code = S204033 CR &lt;ref&gt;[http://wadme.unige.ch:3149/pls/opprg/w_det_cours.debut?p_code_cours=S204033&amp;p_plan_is=0&amp;p_langue=1&amp;p_frame=N&amp;p_mode=PGC&amp;p_annee=2015&amp;p_suffixe=&amp;p_grtri= Présentation du cours sur le site du catalogue de cours wadme]&lt;/ref&gt;<br /> | enregistrement = <br /> | précédent = <br /> | suivant = [[Techniques de planification ]]<br /> }}<br /> <br /> =Gestion du risque=<br /> <br /> La gestion du risque est d'une importance primordiale dans le développement des SI. C'est un ensemble des principes et des pratiques ayant comme objectif '''identifier, analyser, et traiter les facteurs de risque''' afin d'améliorer les chances d'obtenir avec succès le résultat attendu du projet.<br /> <br /> * '''Avant le projet''' : identification et évaluation du risque<br /> * '''Pendant le projet''' : suivi et contrôle du risque<br /> * '''Après le projet''' : capitalisation de l'expérience<br /> <br /> '''Exemples de risque dans les projets SI'''<br /> * Le projet ne débouche pas sur un résultat attendu<br /> * Le projet consomme trop de ressources<br /> * Le projet dure trop longtemps<br /> * Le système ne remplit pas la fonction attendue<br /> * Les utilisateurs n'acceptent pas le système <br /> * Le fonctionnement du système est trop coûteux<br /> <br /> ''&quot;Le taux élevé d'échec s'explique par le fait que les gestionnaires ne prennent pas des mesures afin d'évaluer et de gérer les risques impliqués dans le projet&quot;'' (Keil et al., 1998)<br /> <br /> ''&quot;Les post-mortem des projets échoués indiquent que les problèmes auraient pu être évités s'il y avait eu une identification et une résolution rapide des éléments à hauts risques.&quot;'' (Boehm, 1991)<br /> <br /> La gestion du risque permet d'éviter le désastre ainsi que le travail superflu, de régler et équilibrer les efforts et de stimuler les situations &quot;win-win&quot;.<br /> <br /> La plupart des projets SI sont à l'origine des changements organisationnels. Leur succès peut donc être crucial pour la réalisation des objectifs économiques de l'organisation.<br /> <br /> =Définitions du risque=<br /> <br /> ''Le '''risque''' est une exposition aux facteurs spécifiques qui présentent une menace pour obtenir les résultats attendus du projet.'' (Bannerman, 2008)<br /> <br /> C'est une mesure de la probabilité et de l'impact de non réalisation de l'objectif du projet.<br /> * '''R = P x I'''<br /> '''R''' = exposition à un facteur particulier du risque. '''P''' = probabilité qu'un événement indésirable arrive. '''I''' = impact ou ampleur des pertes si l'événement arrive.<br /> <br /> '''Selon la définition probabilistique : '''<br /> * tous les facteurs potentiels du risque doivent être identifiés au début du projet<br /> * l'exposition au risque est estimée pour chaque facteur<br /> * les facteurs sont classés en fonction de leur priorité afin d'identifier les facteurs les plus menaçants<br /> * focalisation sur les facteurs à haut risque pour minimiser leur probabilité d'occurrence ou l'ampleur de leur impact<br /> <br /> '''Limitations de la définition probabilistique : '''<br /> * il est difficile d'estimer la probabilité et l'impact de plusieurs facteurs<br /> * il est plus facile d'évaluer le risque sur une échelle simple (ex. : bas, moyen, haut) que de calculer sa probabilité<br /> * couplage fort entre l'événement et les conséquences du risque sans prendre en considération la vulnérabilité et les capacités de l'organisation à répondre à la menace<br /> * la définition n'inclut que les menaces connues<br /> <br /> =Démarche de gestion du risque= <br /> <br /> * '''Identifier els risques''' -&gt; facteurs de risque<br /> * '''Évaluer l'impact des risques sur les coûts, le délai, et la qualité''' -&gt; profil du risque, matrice de probabilité/impact<br /> * '''Identifier et mettre en place les actions aptes à réduire les risques inacceptables''' -&gt; stratégies de gestion du risque<br /> * '''Suivre les actions et contrôler l'état des risques'''<br /> * '''Capitaliser l'expérience'''<br /> <br /> ==Principaux facteurs de risque==<br /> <br /> * La taille du projet<br /> * La difficulté technique<br /> * Le degré d'intégration<br /> * La configuration organisationnelle<br /> * Le changement<br /> * L'instabilité de l'équipe de projet<br /> <br /> ===La taille du projet===<br /> <br /> *Le risque est lié aux limites de l'individu<br /> **Un grand projet signifie une large étendue du domaine couvert et impose un partage du travail entre un nombre important de personnes<br /> *Il est difficile à gérer le processus de la production et l'intégration des travaux de plusieurs équipes<br /> <br /> '''Critères'''<br /> *Durée du projet (en mois)<br /> *Charge du projet (en mois/personne)<br /> *Couverture fonctionnelle (nombre de processus<br /> <br /> <br /> {| class=&quot;wikitable&quot;<br /> |-<br /> ! Facteur !! Degré !! Métrique<br /> |-<br /> | '''Durée du projet''' || 1 || =&lt; 6 mois<br /> |-<br /> | || 2 || =&lt; 18 mois<br /> |-<br /> | || 3 || =&lt; 30 mois<br /> |-<br /> | || 4 || &gt; 30 mois<br /> |-<br /> | '''Charge du projet''' || 1 || =&lt; 20 mois/personne<br /> |-<br /> | || 2 || =&lt; 120 mois/personne<br /> |-<br /> | || 3 || =&lt; 300 mois/personne<br /> |-<br /> | || 4 || &gt; 300 mois/personne<br /> |-<br /> | '''Couverture fonctionnelle''' || 1 || =&lt; 2 processus<br /> |-<br /> | || 2 || =&lt; 6 processus<br /> |-<br /> | || 3 || =&lt; 10 processus<br /> |-<br /> | || 4 || &gt; 10 processus<br /> |}<br /> <br /> <br /> ===La difficulté technique===<br /> <br /> *Le risque correspond à une nouveauté technologique ou une difficulté technique provenant des contraintes imposées au projet.<br /> **''Ex. : contraintes de performance, de langage, d'architecture, ...''<br /> *Le risque est l'absence de compétences techniques nécessaires, qui pénalise la production<br /> <br /> '''Critères'''<br /> *Expérience de l'entreprise sur les techniques à utiliser (nombre de projets)<br /> **Expérience sur l'architecture, le langage de programmation, le SGBD<br /> *Expérience du marché sur les techniques à utiliser (nombre de références)<br /> **Expérience sur l'architecture, le langage de programmation, le SGBD<br /> *Contrainte de performance (de 0 à très élevée)<br /> *Responsabilité de la direction informatique (degré de responsabilité)<br /> <br /> <br /> ===Le degré d'intégration===<br /> <br /> *Le degré d'intégration mesure le degré de dépendance ou d'autonomie du futur SI<br /> **Plus le SI en construction doit collaborer avec d'autres systèmes de l'entreprise, plus il est difficile d'identifier clairement l'impact de choix de conception<br /> **D'autres entités, d'autres équipes, d'autres projets de développement peuvent être concernés, ce qui augmente le nombre d'acteurs du projet<br /> <br /> '''Critères'''<br /> *Nombre de flux avec des applications connexes<br /> *Nombre d'applications connexes en évolution<br /> <br /> ===La configuration organisationnelle===<br /> <br /> *Ce facteur correspond à l'étendue de l'entreprise qui est touchée par le projet<br /> **Le risque provient de la lourdeur des procédures de participation et de décision quand plusieurs grandes entités de l'entreprise (les directions) sont parties prenantes du projet. La production en est ralentie.<br /> *Éventuels conflits politiques et organisationnels peuvent bloquer les prises de décision et ralentir le processus de développement<br /> <br /> '''Critères'''<br /> *Nombre de directions assurant la MOA<br /> *Existence et implication d'un sponsor<br /> *Pérennité du sponsor<br /> *Appui de la direction générale<br /> <br /> ===Le changement===<br /> <br /> *Le risque de '''mauvaise définition du futur système''' à cause d'un changement métier ou organisationnel<br /> **Le changement visé par le projet signifie que le système de gestion et/ou d'organisation existants ne peuvent pas être pris comme référence stable et que l'effort de conception et d'innovation va être important.<br /> <br /> '''Critères'''<br /> *Degré d'évolution organisationnelle (écart par rapport à l'existant)<br /> *Degré d'évolution fonctionnelle (écart par rapport à l'existant)<br /> *Degré d'évolution technique (écart par rapport à l'existant)<br /> *Impact social (conséquences sur effectif et salaire)<br /> *Nombre de sites concernés<br /> <br /> ===L'instabilité de l'équipe de projet===<br /> <br /> *Le risque est lié au '''départ de certains membres de l'équipe''' durant le projet <br /> **Problème du '''transfert de connaissances''' : les concepteurs engrangent un ensemble de connaissances implicites sur le projet et son domaine que des modèles formalisés ne suffissent pas à transmettre<br /> **Risque de mauvaise interprétation de la conception faite par d'autres personnes, ce qui peut avoir des conséquences sur les délais et la cohérence de la réalisation.<br /> <br /> '''Critères'''<br /> *Durée du projet (en mois<br /> *Sous-traitance de MOA (en %)<br /> * Mobilité dans l'entreprise (degré)<br /> * Relation MOA - MOE (niveau de relations)<br /> * Techniques attrayantes (niveau d'attractivité)<br /> * Marché de l'emploi (niveau de difficulté)<br /> * Image du projet (degré de valorisation)<br /> <br /> ==Évaluation du degré de risque==<br /> <br /> Le degré de risque de chaque facteur est calculé avec la formule :<br /> <br /> Degré de risque d'un facteur = Somme (degré de chaque critère*pondération) / somme des pondérations.<br /> <br /> Une pondération peut être définie pour majorer l'importance d'un critère dans le facteur étudié. <br /> <br /> Le profil du risque permet ainsi de faire apparaître les risques majeurs qui présentent un degré élevé (si la moyenne des risques dépasse 3 sur 4, l'échec est inévitable).<br /> <br /> =Les stratégies de gestion du risque=<br /> <br /> *'''Fuite'''<br /> Recherche des moyens pour '''éviter l'effet négatif du risque''' sur le projet. <br /> <br /> ''Exemple : modification de la solution conceptuelle du projet - élimination ou modification de certaines fonctionnalités et/ou propriétés.''<br /> <br /> *'''Transfert'''<br /> '''Déplacement de la responsabilité du risque à un tiers'''; n'élimine pas la menace mais délègue la responsabilité de sa gestion à quelqu'un d'autre.<br /> <br /> ''Exemple : assurance, contrat de sous-traitance, outsourcing.''<br /> <br /> *'''Mitigation'''<br /> '''Réduction de la menace''' en réduisant la probabilité et/ou l'impact du risque.<br /> <br /> ''Exemple : amélioration de la participation des utilisateurs, formation des développeurs, choix des méthodes, etc.''<br /> <br /> *'''Acceptation''' passive ou active<br /> <br /> '''Passive''' : quand la menace n'est pas importante et/ou la source du risque est externe au projet.<br /> <br /> '''Active''' : quand le menace est réelle mais qu'il n'y a rien à faire avant son apparition; un plan de contingence peut être prévu.<br /> <br /> ''Exemple : budget et/ou ressources supplémentaires, plan d'action, etc.''<br /> <br /> =Solutions pour chaque facteur=<br /> <br /> ==La taille du projet==<br /> <br /> * Découper le projet en sous-projets<br /> * Choisir un modèle de '''développement évolutif''' et '''incrémental'''. Exemple : le modèle de la '''Spirale''' où chaque cycle permet l'analyse du risque et la redéfinition des objectifs.<br /> * Choisir un dispositif de coordination formel pour gérer l'avancement d'une équipe importante<br /> <br /> ==La difficulté technique==<br /> <br /> * Différer l'introduction d'une ou plusieurs innovations<br /> * Rechercher les compétences nécessaires<br /> * Si les besoins sont stables, le risque majeur est lié à la programmation, alors les modèles de type '''Cascade''' ou '''RAD''' permettent de se focaliser sur la programmation<br /> * Sinon, choisir le '''modèle en W''' qui insiste sur les tests systématiques<br /> <br /> ==Le degré d'intégration==<br /> <br /> * Intégrer dans le projet les acteurs qui connaissent bien les autres systèmes avec lesquels le SI doit s'intégrer<br /> * Les''' modèles en V''' et '''W''' facilitent l'intégration modulaire<br /> <br /> ==La configuration organisationnelle=<br /> <br /> *Limiter le champ de participation de chaque membre exécutif<br /> *Privilégier le '''développement évolutif''' et '''incrémental'''<br /> <br /> ==Le changement=<br /> <br /> * Réduire l'incertitude en modifiant le champ du projet ou ses caractéristiques<br /> * Intégrer des acteurs qui ont le pouvoir de prendre les décisions stratégiques <br /> * Utiliser les techniques facilitant la créativité et l'exploration<br /> * Les modèles de '''développement évolutif''' et '''RUP''' permettent de gérer les besoins qui s'éclaircissent en cours du projet.<br /> <br /> ==L'instabilité de l'équipe de projet==<br /> <br /> * Obliger la documentation détaillée de chaque produit et activité du projet - un système d'information sur le futur système (documentation du projet)<br /> * Superviser les personnes à risque, ce qui favorise la transmission des connaissances<br /> <br /> =Conclusion=<br /> <br /> *'''La gestion du risque s'attaque en premier lieu aux facteurs humains et non techniques''' : il n'y a pas de recette miracle, il faut avant tout beaucoup de jugement.<br /> (Boehm, 1991)<br /> <br /> *'''La gestion du risque doit devenir une part entière de la méthodologie de développement et non pas une activité séparée'''<br /> (Kwak &amp; Stoddard, 2002)<br /> <br /> *'''Implantation progressive dans les organisations'''<br /> (Boehm, 1991)<br /> <br /> ==Le top 10 des facteurs de risque==<br /> <br /> Selon Boehm, 1991 : <br /> *Manque de personnel compétent<br /> * Budgets et échéances irréalistes<br /> * Mauvaises fonctionnalités développées<br /> * Mauvaise interface développée<br /> * Gold plating (addition de plus de fonctionnalités/propriétés que ce qu'il est nécessaire)<br /> * Demandes de changement continuelles<br /> * Pénurie de composantes acquises à l'externe<br /> * Problèmes au niveau des tâches confiées à l'externe<br /> * Problèmes de performance en temps réel<br /> * Limite des capacités informatiques<br /> <br /> = Annexes =<br /> <br /> = Références =</div>

Sania https://baripedia.org/index.php?title=Gestion_du_risque_des_projets_SI&diff=32327 2016-06-04T10:37:02Z

<p>Sania : </p> <hr /> <div>{{Infobox Lecture<br /> | image = <br /> | cours = [[Gestion de projet]]<br /> | faculté = [[Faculté d'économie et de management]]<br /> | département = [[Services généraux GSEM]]<br /> | domaine = [[Système d'information]]<br /> | professeurs = [[Jolita Ralyte]]&lt;ref&gt;[http://cui.unige.ch/~ralyte/ Page personnelle de Jolita Ralyte sur le site du CUI]&lt;/ref&gt;<br /> | années = <br /> | code = S204033 CR &lt;ref&gt;[http://wadme.unige.ch:3149/pls/opprg/w_det_cours.debut?p_code_cours=S204033&amp;p_plan_is=0&amp;p_langue=1&amp;p_frame=N&amp;p_mode=PGC&amp;p_annee=2015&amp;p_suffixe=&amp;p_grtri= Présentation du cours sur le site du catalogue de cours wadme]&lt;/ref&gt;<br /> | enregistrement = <br /> | précédent = <br /> | suivant = [[Techniques de planification ]]<br /> }}<br /> <br /> =Gestion du risque=<br /> <br /> La gestion du risque est d'une importance primordiale dans le développement des SI. C'est un ensemble des principes et des pratiques ayant comme objectif '''identifier, analyser, et traiter les facteurs de risque''' afin d'améliorer les chances d'obtenir avec succès le résultat attendu du projet.<br /> <br /> * '''Avant le projet''' : identification et évaluation du risque<br /> * '''Pendant le projet''' : suivi et contrôle du risque<br /> * '''Après le projet''' : capitalisation de l'expérience<br /> <br /> '''Exemples de risque dans les projets SI'''<br /> * Le projet ne débouche pas sur un résultat attendu<br /> * Le projet consomme trop de ressources<br /> * Le projet dure trop longtemps<br /> * Le système ne remplit pas la fonction attendue<br /> * Les utilisateurs n'acceptent pas le système <br /> * Le fonctionnement du système est trop coûteux<br /> <br /> ''&quot;Le taux élevé d'échec s'explique par le fait que les gestionnaires ne prennent pas des mesures afin d'évaluer et de gérer les risques impliqués dans le projet&quot;'' (Keil et al., 1998)<br /> <br /> ''&quot;Les post-mortem des projets échoués indiquent que les problèmes auraient pu être évités s'il y avait eu une identification et une résolution rapide des éléments à hauts risques.&quot;'' (Boehm, 1991)<br /> <br /> La gestion du risque permet d'éviter le désastre ainsi que le travail superflu, de régler et équilibrer les efforts et de stimuler les situations &quot;win-win&quot;.<br /> <br /> La plupart des projets SI sont à l'origine des changements organisationnels. Leur succès peut donc être crucial pour la réalisation des objectifs économiques de l'organisation.<br /> <br /> =Définitions du risque=<br /> <br /> ''Le '''risque''' est une exposition aux facteurs spécifiques qui présentent une menace pour obtenir les résultats attendus du projet.'' (Bannerman, 2008)<br /> <br /> C'est une mesure de la probabilité et de l'impact de non réalisation de l'objectif du projet.<br /> * '''R = P x I'''<br /> '''R''' = exposition à un facteur particulier du risque. '''P''' = probabilité qu'un événement indésirable arrive. '''I''' = impact ou ampleur des pertes si l'événement arrive.<br /> <br /> '''Selon la définition probabilistique : '''<br /> * tous les facteurs potentiels du risque doivent être identifiés au début du projet<br /> * l'exposition au risque est estimée pour chaque facteur<br /> * les facteurs sont classés en fonction de leur priorité afin d'identifier les facteurs les plus menaçants<br /> * focalisation sur les facteurs à haut risque pour minimiser leur probabilité d'occurrence ou l'ampleur de leur impact<br /> <br /> '''Limitations de la définition probabilistique : '''<br /> * il est difficile d'estimer la probabilité et l'impact de plusieurs facteurs<br /> * il est plus facile d'évaluer le risque sur une échelle simple (ex. : bas, moyen, haut) que de calculer sa probabilité<br /> * couplage fort entre l'événement et les conséquences du risque sans prendre en considération la vulnérabilité et les capacités de l'organisation à répondre à la menace<br /> * la définition n'inclut que les menaces connues<br /> <br /> =Démarche de gestion du risque= <br /> <br /> * '''Identifier els risques''' -&gt; facteurs de risque<br /> * '''Évaluer l'impact des risques sur les coûts, le délai, et la qualité''' -&gt; profil du risque, matrice de probabilité/impact<br /> * '''Identifier et mettre en place les actions aptes à réduire les risques inacceptables''' -&gt; stratégies de gestion du risque<br /> * '''Suivre les actions et contrôler l'état des risques'''<br /> * '''Capitaliser l'expérience'''<br /> <br /> ==Principaux facteurs de risque==<br /> <br /> * La taille du projet<br /> * La difficulté technique<br /> * Le degré d'intégration<br /> * La configuration organisationnelle<br /> * Le changement<br /> * L'instabilité de l'équipe de projet<br /> <br /> ===La taille du projet===<br /> <br /> *Le risque est lié aux limites de l'individu<br /> **Un grand projet signifie une large étendue du domaine couvert et impose un partage du travail entre un nombre important de personnes<br /> *Il est difficile à gérer le processus de la production et l'intégration des travaux de plusieurs équipes<br /> <br /> '''Critères'''<br /> *Durée du projet (en mois)<br /> *Charge du projet (en mois/personne)<br /> *Couverture fonctionnelle (nombre de processus<br /> <br /> <br /> {| class=&quot;wikitable&quot;<br /> |-<br /> ! Facteur !! Degré !! Métrique<br /> |-<br /> | '''Durée du projet''' || 1 || =&lt; 6 mois<br /> |-<br /> | || 2 || =&lt; 18 mois<br /> |-<br /> | || 3 || =&lt; 30 mois<br /> |-<br /> | || 4 || &gt; 30 mois<br /> |-<br /> | '''Charge du projet''' || 1 || =&lt; 20 mois/personne<br /> |-<br /> | || 2 || =&lt; 120 mois/personne<br /> |-<br /> | || 3 || =&lt; 300 mois/personne<br /> |-<br /> | || 4 || &gt; 300 mois/personne<br /> |-<br /> | '''Couverture fonctionnelle''' || 1 || =&lt; 2 processus<br /> |-<br /> | || 2 || =&lt; 6 processus<br /> |-<br /> | || 3 || =&lt; 10 processus<br /> |-<br /> | || 4 || &gt; 10 processus<br /> |}<br /> <br /> <br /> ===La difficulté technique===<br /> <br /> *Le risque correspond à une nouveauté technologique ou une difficulté technique provenant des contraintes imposées au projet.<br /> **''Ex. : contraintes de performance, de langage, d'architecture, ...''<br /> *Le risque est l'absence de compétences techniques nécessaires, qui pénalise la production<br /> <br /> '''Critères'''<br /> *Expérience de l'entreprise sur les techniques à utiliser (nombre de projets)<br /> **Expérience sur l'architecture, le langage de programmation, le SGBD<br /> *Expérience du marché sur les techniques à utiliser (nombre de références)<br /> **Expérience sur l'architecture, le langage de programmation, le SGBD<br /> *Contrainte de performance (de 0 à très élevée)<br /> *Responsabilité de la direction informatique (degré de responsabilité)<br /> <br /> <br /> ===Le degré d'intégration===<br /> <br /> *Le degré d'intégration mesure le degré de dépendance ou d'autonomie du futur SI<br /> **Plus le SI en construction doit collaborer avec d'autres systèmes de l'entreprise, plus il est difficile d'identifier clairement l'impact de choix de conception<br /> **D'autres entités, d'autres équipes, d'autres projets de développement peuvent être concernés, ce qui augmente le nombre d'acteurs du projet<br /> <br /> '''Critères'''<br /> *Nombre de flux avec des applications connexes<br /> *Nombre d'applications connexes en évolution<br /> <br /> ===La configuration organisationnelle===<br /> <br /> *Ce facteur correspond à l'étendue de l'entreprise qui est touchée par le projet<br /> **Le risque provient de la lourdeur des procédures de participation et de décision quand plusieurs grandes entités de l'entreprise (les directions) sont parties prenantes du projet. La production en est ralentie.<br /> *Éventuels conflits politiques et organisationnels peuvent bloquer les prises de décision et ralentir le processus de développement<br /> <br /> '''Critères'''<br /> *Nombre de directions assurant la MOA<br /> *Existence et implication d'un sponsor<br /> *Pérennité du sponsor<br /> *Appui de la direction générale<br /> <br /> ===Le changement===<br /> <br /> *Le risque de '''mauvaise définition du futur système''' à cause d'un changement métier ou organisationnel<br /> **Le changement visé par le projet signifie que le système de gestion et/ou d'organisation existants ne peuvent pas être pris comme référence stable et que l'effort de conception et d'innovation va être important.<br /> <br /> '''Critères'''<br /> *Degré d'évolution organisationnelle (écart par rapport à l'existant)<br /> *Degré d'évolution fonctionnelle (écart par rapport à l'existant)<br /> *Degré d'évolution technique (écart par rapport à l'existant)<br /> *Impact social (conséquences sur effectif et salaire)<br /> *Nombre de sites concernés<br /> <br /> ===L'instabilité de l'équipe de projet===<br /> <br /> *Le risque est lié au '''départ de certains membres de l'équipe''' durant le projet <br /> **Problème du '''transfert de connaissances''' : les concepteurs engrangent un ensemble de connaissances implicites sur le projet et son domaine que des modèles formalisés ne suffissent pas à transmettre<br /> **Risque de mauvaise interprétation de la conception faite par d'autres personnes, ce qui peut avoir des conséquences sur les délais et la cohérence de la réalisation.<br /> <br /> '''Critères'''<br /> *Durée du projet (en mois<br /> *Sous-traitance de MOA (en %)<br /> * Mobilité dans l'entreprise (degré)<br /> * Relation MOA - MOE (niveau de relations)<br /> * Techniques attrayantes (niveau d'attractivité)<br /> * Marché de l'emploi (niveau de difficulté)<br /> * Image du projet (degré de valorisation)<br /> <br /> <br /> <br /> = Annexes =<br /> <br /> = Références =</div>

Sania https://baripedia.org/index.php?title=Mod%C3%A8les_de_processus_de_d%C3%A9veloppement_des_SI&diff=32326 2016-06-03T23:33:42Z

<p>Sania : </p> <hr /> <div>{{Infobox Lecture<br /> | image = <br /> | cours = [[Gestion de projet]]<br /> | faculté = [[Faculté d'économie et de management]]<br /> | département = [[Services généraux GSEM]]<br /> | domaine = [[Système d'information]]<br /> | professeurs = [[Jolita Ralyte]]&lt;ref&gt;[http://cui.unige.ch/~ralyte/ Page personnelle de Jolita Ralyte sur le site du CUI]&lt;/ref&gt;<br /> | années = <br /> | code = S204033 CR &lt;ref&gt;[http://wadme.unige.ch:3149/pls/opprg/w_det_cours.debut?p_code_cours=S204033&amp;p_plan_is=0&amp;p_langue=1&amp;p_frame=N&amp;p_mode=PGC&amp;p_annee=2015&amp;p_suffixe=&amp;p_grtri= Présentation du cours sur le site du catalogue de cours wadme]&lt;/ref&gt;<br /> | enregistrement = <br /> | précédent = <br /> | suivant = [[Gestion du risque des projets SI]]<br /> }}<br /> <br /> =Processus de Développement des SI=<br /> Ensemble structuré d'activités à réaliser pour atteindre l'objectif d'un projet SI, dont les activités varient en fonction de l'organisation, du projet, et du type de système à développer. Ce processus doit être explicitement décrit pour être adéquatement géré.<br /> <br /> Le '''cycle de vie d'un SI''' décrit succintement les phases par lesquelles passe un système d'information depuis le '''besoin initial''' jusqu'au '''retrait du système''', la documentation et les décisions qui jalonnent le cycle.<br /> <br /> =Activités de développement des SI=<br /> <br /> *'''Spécification''' des exigences et des contraintes du système, établissement du cahier des charges<br /> *'''Conception''' de la solution, production d'un modèle du système à développer<br /> *'''Implémentation''' du système<br /> *'''Test''' du système, vérification de l'adéquation entre les propriétés implémentées du système et la spécification des besoins<br /> *'''Installation''' du système chez le client et vérification de son fonctionnement<br /> *'''Maintenance''' du système, réparation des fautes<br /> <br /> =Modèles standards de développement des SI=<br /> <br /> Il existe différents types de cycles de développement entrant dans la réalisation d'un logiciel. Ces cycles prendront en compte toutes les activités/étapes de développement des SI vus dans le point précédent.<br /> <br /> <br /> ==Code-and-fix==<br /> <br /> Modèle dirigé par la programmation.<br /> <br /> '''Compréhension du problème''' -&gt; '''Programmation''' -&gt; '''Test contre spécification''' -&gt; '''Fin''' si satisfait, sinon '''Mise au point du code''' et retour au '''Test contre spécification'''<br /> <br /> ==Transformation automatique==<br /> <br /> Développement basé sur la possibilité de transformer automatiquement des spécifications validées en programmes.<br /> <br /> Ce modèle nécessite un '''outil logiciel''' qui fait de telles transformations.<br /> <br /> '''Spécification''' -&gt; '''Validation''' -&gt; '''Transformation''' si validé, sinon retour à '''Spécification'''.<br /> <br /> ==Cascade / Waterfall==<br /> [[Fichier:Processus cascade waterfall.png|cadre|centré|Processus de développement en cascade/waterfall]]<br /> <br /> Processus de nature plutôt linéaire, centré '''activités''' avec un ordonnancement prédéfini des activités, dans lequel il est toujours possible de revenir en arrière. Ce modèle est hérité de l'industrie de la construction de bâtiments.<br /> <br /> ===Initiation - Étude de faisabilité===<br /> <br /> *Analyser le problème<br /> *Définir les objectifs<br /> *Définir les frontières du système<br /> *Identifier les contraintes imposées (politiques, matériel, temps, technologies, etc.)<br /> *'''Évaluer la faisabilité technique, économique, opérationnelle.'''<br /> <br /> ===Spécification des exigences===<br /> <br /> *Définir le périmètre du SI<br /> *Analyser le domaine d'application<br /> *Identifier les exigences :<br /> **fonctionnelles : les activités de l'organisation qui devraient être couvertes par le SI<br /> **non fonctionnelles : les performances techniques, l'environnement d'utilisateur, système d'exploitation, matériel, etc.<br /> *Conceptualiser les besoins (cas d'utilisation, scénarios, objectifs, etc.)<br /> *Déterminer la priorité des besoins<br /> *Valider les exigences avec les utilisateurs<br /> *Élaborer un glossaire de termes<br /> <br /> ===Analyse===<br /> '''Exploration des solutions possibles : '''<br /> *Analyser les exigences<br /> *Proposer une ou plusieurs solutions conceptuelles <br /> **Vue structurelle du système (modèle objet)<br /> **Vue dynamique du système (cycle de vie des objets, diagrammes d'activités, etc.)<br /> *Proposer une architecture d'implémentation<br /> *Valider toutes les propositions avec les utilisateurs<br /> <br /> ===Conception===<br /> '''Spécification détaillée de la solution choisie :'''<br /> *Définir le modèle physique de la base de données<br /> *Définir les contraintes d'intégrité<br /> *Choisir le SGBD<br /> *Modéliser les interfaces utilisateur<br /> *Définir les standards de sécurité du système<br /> *Définir l'architecture du système<br /> <br /> ===Construction===<br /> '''Développement du code : '''<br /> *Créer les programmes<br /> *Créer et remplir les bases de données<br /> *Intégrer les sous-systèmes<br /> *Écrire la documentation<br /> <br /> ===Tests===<br /> *Tester les programmes<br /> *Tester le système global<br /> <br /> ===Mise en place===<br /> *S'assurer que tout le matériel et les réseaux nécessaires pour le nouveau SI sont mis en place<br /> *Installer le système<br /> *Former l'utilisateur<br /> <br /> ==Modèle en V==<br /> [[Fichier:Processus modele V.png|cadre|centré|Méthode de développement en V]]<br /> <br /> Décomposition du système en composants qui peuvent être développés de manière indépendante. Ce modèle permet d'avoir une meilleure réactivité que le modèle en cascade : il permet de limiter les retours en arrière en cas d'anomalie.<br /> <br /> ==Modèle en W==<br /> [[Fichier:Processus modele W.png|cadre|centré|Modèle de développement en W]]<br /> <br /> Ce modèle est une extension du modèle en V, qui améliore l'étape d'analyse des exigences.<br /> <br /> ===Modèle en W : accent sur les tests===<br /> [[Fichier:Processus modele W-tests.png|cadre|centré|Modèle de développement en W avec accent sur les tests]]<br /> <br /> Ce modèle est toujours une extension du modèle en V, mais avec une focalisation sur les '''tests''' à toutes les phases de développement.<br /> <br /> ==Développement évolutif==<br /> <br /> Développement de plusieurs versions d'un logiciel en l'améliorant à chaque fois.<br /> <br /> '''Détermination des besoins''' -&gt; '''Programmation''' -&gt; '''Expérimentation''' -&gt; '''Version N''' -&gt; '''Détermination des besoins''' -&gt; ...<br /> <br /> ==Spirale==<br /> [[Fichier:Processus spirale.png|cadre|centré|Modèle de développement en spirale]]<br /> <br /> Ce modèle reprend les différentes étapes du modèle en V en mettant un accent sur la gestion du risque, qui se retrouve à chaque début d'itération de la spirale.<br /> <br /> ==RAD - Rapid Application Development==<br /> <br /> [[Fichier:Processus RAD.png|vignette|droite|Modèle de développement RAD]]<br /> <br /> Le RAD est un modèle '''linéaire''' en 5 phases et '''itératif''' pour la phase de construction. Chaque phase est composée d'une ou plusieurs étapes, et chaque étape est organisée en 3 temps :<br /> #Travaux préparatoires<br /> #Session participative<br /> #Travaux de conclusion<br /> <br /> Le logiciel est construit en plusieurs modules livrés successivement, et il privilégie aussi le travail d'équipe.<br /> <br /> ===Initialisation===<br /> '''Préparation et organisation du projet'''<br /> *Répertorier l'ensemble des intervenants<br /> *Définir les objectifs stratégiques du projet<br /> * Évaluer la faisabilité du projet<br /> * Évaluer les moyens nécessaires <br /> * Établir un accord entre le client et le fournisseur<br /> * Lancement du projet<br /> <br /> ===Cadrage===<br /> '''Analyse et spécification des exigences :'''<br /> * Définir la hiérarchie des objectifs<br /> * Définir la hiérarchie des fonctions<br /> * Planifier les changements des processus &quot;métier&quot;<br /> * Définir les ressources nécessaires et le cycle de développement<br /> * Valider les objectifs et les contraintes<br /> <br /> ===Conception===<br /> '''Conception de la solution : '''<br /> *Modéliser :<br /> **Établir une liste détaillée des fonctionnalités<br /> **Créer le modèle de données exhaustif<br /> *Préparer la documentation technique<br /> * Valider la conception d'ensemble<br /> * Choisir les technologies et les valider<br /> * Valider les modèles et le prototype<br /> * Valider les charges et le planning<br /> <br /> ===Construction===<br /> '''Développement collaboratif et incrémental'''<br /> * Détailler chaque module<br /> * Réaliser (coder) les modules<br /> * Intégrer les modules<br /> * Tester les modules<br /> * Tester l'intégration<br /> * Documenter<br /> Différents modules peuvent être développés en parallèle<br /> <br /> ===Finalisation===<br /> '''Préparer la mise en oeuvre :'''<br /> * Préparer le système à l'installation<br /> * Rédiger les manuels utilisateurs<br /> * Rédiger le manuel d'exploitation<br /> * Préparer la formation<br /> * Établir le plan de formation<br /> * Établir le plan de démarrage (reprises de données, bascule technique,...)<br /> '''Tester le système'''<br /> '''Démarrer le système :'''<br /> * Établir l'environnement d'exploitation et l'infrastructure du support d'exploitation<br /> * Mettre en oeuvre le plan de démarrage<br /> * Audit du fonctionnement et évaluation des écarts<br /> * Améliorer et optimiser le système<br /> * Former les utilisateurs<br /> <br /> ==RUP - Rational Unified Process==<br /> Processus itératif et incrémental divisé en 4 phases : <br /> #Initialisation : définition de l'objectif du projet et préparation d'un contrat de réalisation<br /> #Élaboration : planification du projet, spécification de la solution proposée, proposition d'une architecture de base<br /> #Construction : développement du produit<br /> #Transition : transition du produit chez les utilisateurs.<br /> Ces 4 phases sont elles-mêmes divisées en N itération, à la fin desquelles Il y a une version du produit livrable.<br /> <br /> ===Workflows===<br /> Étapes à réaliser dans chaque itération :<br /> * Modélisation d'entreprise (entreprise/business modeling)<br /> * Analyse des besoins<br /> * Analyse et conception<br /> * Implémentation<br /> * Test<br /> * Déploiement<br /> * Gestion de changements<br /> * Gestion de projet<br /> * Préparation d'environnement<br /> <br /> ==XP - Extreme Progamming==<br /> Modèle itératif à deux niveaux :<br /> *'''Itérations de livraison''' - un plan de livraison doit être défini avec le client<br /> **une livraison - une version opérationnelle du logiciel<br /> **durée de développement - quelques mois<br /> *'''Itérations de développement''' - une fonctionnalité livrable est décomposée en plusieurs fonctions simples :<br /> **développement par binômes<br /> **les utilisateurs participent aux chois des itérations et aux tests<br /> **durée - 2-4 semaines<br /> **résultat - une ou plusieurs fonctions qui peuvent être intégrées dans la version livrable<br /> <br /> ===Rôles===<br /> *'''Programmeur''' : est responsable de la conception technique et le codage évolutif<br /> *'''Client''' : doit exprimer ses exigences sous forme de scénarios (user stories) et écrire des jeux de tests fonctionnels<br /> *'''Testeur''' : aide le client à élaborer des jeux de test et à les exécuter<br /> *'''Tracker''' : est responsable de la gestion du temps : planification et contrôle<br /> *'''Coach''' : est responsable du soutien technique des membres de l'équipe<br /> *'''Manager / chef de projet''' : les rôles peuvent être combinés : un chef de projet peut réunir les rôles de manager, tracker et coach. <br /> <br /> ==SCRUM==<br /> <br /> Développement itératif et incrémental, fait référence à l'organisation d'un jeu de rugby : <br /> * '''avant-jeu''' : préparation, conception de haut niveau du système et son architecture : le périmètre et la base du contenu du système<br /> *'''jeu''' : développement itératif organisé en sprints de 2-4 semaines<br /> *'''après-jeu''' : livraison finale du système, clôture du projet.<br /> <br /> ===Vocabulaire===<br /> *'''Product backlog'''<br /> Une liste priorisée de besoins et exigences que veut le client, exprimé dans son vocabulaire et sa terminologie métier, souvent en termes de scénarios (user stories)<br /> *'''Sprint backlog''' <br /> Une liste de tâches identifiées par l'équipe du projet à réaliser pendant un sprint afin d'implémenter les scénarios sélectionnés pour ce sprint.<br /> *'''Daily scrum'''<br /> Chaque jour on organise une courte réunion (15 minutes) pour fixer et/ou ajuster les objectifs de la journée<br /> *'''Product owner (propriétaire)'''<br /> Représente le client en ce qui concerne les spécifications des exigences et les acceptations<br /> *'''Scrum master (capitaine d'équipe)'''<br /> Anime au quotidien l'équipe de développement, recadre le projet en cas de difficulté. Ce rôle donne lieu à une certification<br /> *'''Team members (les membres d'équipe)'''<br /> Architectes, développeurs, testeurs, administrateurs de base de données, etc. Les mebres d'équipe disposent d'une certaine autonomie dans l'organisation de leurs travaux.<br /> <br /> ===User story==<br /> Le scénario est une exigence du système à développer, formulée en une ou deux phrases dans le langage de l'utilisateur. Ces user stories émergent au cours d'ateliers de travail menés avec le Métier, le Client et/ou les utilisateurs.<br /> <br /> '''Le modèle de structure d'une User Story'''<br /> <br /> * En tant tant que &lt;rôle, personne, user type&gt;<br /> * Je veux &lt;fonctionnalité, tâche, action&gt;<br /> * Afin de &lt;valeur ajoutée, résultat&gt;<br /> <br /> '''Exemples :'''<br /> <br /> * ''En tant qu'acheteur en ligne, je veux pouvoir ajouter des items à mon panier afin d'enregistrer mes achats que je ne souhaite pas acheter dans l'immédiat.''<br /> * ''En tant qu'utilisateur, je veux réserver une chambre d'hôtel afin de...''<br /> * ''En tant qu'utilisateur, je veux annuler une réservat5ion afin de...''<br /> * ''En tant que recruteur, je veux déposer des offres d'emploi afin de...''<br /> * ''En tant que je une diplômé, je veux déposer un CV afin de...''<br /> * ''En tant que jeune diplômé, je veux supprimer un CV afin de...''<br /> <br /> <br /> = Annexes =<br /> <br /> = Références =</div>

Sania https://baripedia.org/index.php?title=Gestion_du_risque_des_projets_SI&diff=32325 2016-06-03T16:11:18Z

<p>Sania : Page créée avec « {{Infobox Lecture | image = | cours = Gestion de projet | faculté = Faculté d'économie et de management | département = Services généraux GSEM | do... »</p> <hr /> <div>{{Infobox Lecture<br /> | image = <br /> | cours = [[Gestion de projet]]<br /> | faculté = [[Faculté d'économie et de management]]<br /> | département = [[Services généraux GSEM]]<br /> | domaine = [[Système d'information]]<br /> | professeurs = [[Jolita Ralyte]]&lt;ref&gt;[http://cui.unige.ch/~ralyte/ Page personnelle de Jolita Ralyte sur le site du CUI]&lt;/ref&gt;<br /> | années = <br /> | code = S204033 CR &lt;ref&gt;[http://wadme.unige.ch:3149/pls/opprg/w_det_cours.debut?p_code_cours=S204033&amp;p_plan_is=0&amp;p_langue=1&amp;p_frame=N&amp;p_mode=PGC&amp;p_annee=2015&amp;p_suffixe=&amp;p_grtri= Présentation du cours sur le site du catalogue de cours wadme]&lt;/ref&gt;<br /> | enregistrement = <br /> | précédent = <br /> | suivant = [[Techniques de planification ]]<br /> }}<br /> <br /> ==Gestion du risque==<br /> <br /> La gestion du risque est d'une importance primordiale dans le développement des SI.<br /> <br /> '''Exemples de risque dans les projets SI'''<br /> * Le projet ne débouche pas sur un résultat attendu<br /> * Le projet consomme trop de ressources<br /> * Le projet dure trop longtemps<br /> * Le système ne remplit pas la fonction attendue<br /> * Les utilisateurs n'acceptent pas le système <br /> * Le fonctionnement du système est trop coûteux<br /> <br /> ''&quot;Le taux élevé d'échec s'explique par le fait que les gestionnaires ne prennent pas des mesures afin d'évaluer et de gérer les risques impliqués dans le projet&quot;'' (Keil et al., 1998)<br /> <br /> ''&quot;Les post-mortem des projets échoués indiquent que les problèmes auraient pu être évités s'il y avait eu une identification et une résolution rapide des éléments à hauts risques.&quot;'' (Boehm, 1991)<br /> <br /> La gestion du risque permet d'éviter le désastre ainsi que le travail superflu, de régler et équilibrer les efforts et de stimuler les situations &quot;win-win&quot;.<br /> <br /> La plupart des projets SI sont à l'origine des changements organisationnels. Leur succès peut donc être crucial pour la réalisation des objectifs économiques de l'organisation.<br /> <br /> =Définitions du risque=<br /> <br /> ''Le '''risque''' est une exposition aux facteurs spécifiques qui présentent une menace pour obtenir les résultats attendus du projet.'' (Bannerman, 2008)<br /> <br /> C'est une mesure de la probabilité et de l'impact de non réalisation de l'objectif du projet.<br /> * '''R = P x I'''<br /> '''R''' = exposition à un facteur particulier du risque. '''P''' = probabilité qu'un événement indésirable arrive. '''I''' = impact ou ampleur des pertes si l'événement arrive.<br /> <br /> '''Selon la définition probabilistique : '''<br /> * tous les facteurs potentiels du risque doivent être identifiés au début du projet<br /> * l'exposition au risque est estimée pour chaque facteur<br /> * les facteurs sont classés en fonction de leur priorité afin d'identifier les facteurs les plus menaçants<br /> * focalisation sur les facteurs à haut risque pour minimiser leur probabilité d'occurrence ou l'ampleur de leur impact<br /> <br /> '''Limitations de la définition probabilistique : '''<br /> * il est difficile d'estimer la probabilité et l'impact de plusieurs facteurs<br /> * il est plus facile d'évaluer le risque sur une échelle simple (ex. : bas, moyen, haut) que de calculer sa probabilité<br /> * couplage fort entre l'événement et les conséquences du risque sans prendre en considération la vulnérabilité et les capacités de l'organisation à répondre à la menace<br /> * la définition n'inclut que les menaces connues<br /> <br /> <br /> <br /> <br /> = Annexes =<br /> <br /> = Références =</div>

Sania https://baripedia.org/index.php?title=Mod%C3%A8les_de_processus_de_d%C3%A9veloppement_des_SI&diff=32324 2016-06-03T15:08:22Z

<p>Sania : </p> <hr /> <div>{{Infobox Lecture<br /> | image = <br /> | cours = [[Gestion de projet]]<br /> | faculté = [[Faculté d'économie et de management]]<br /> | département = [[Services généraux GSEM]]<br /> | domaine = [[Système d'information]]<br /> | professeurs = [[Jolita Ralyte]]&lt;ref&gt;[http://cui.unige.ch/~ralyte/ Page personnelle de Jolita Ralyte sur le site du CUI]&lt;/ref&gt;<br /> | années = <br /> | code = S204033 CR &lt;ref&gt;[http://wadme.unige.ch:3149/pls/opprg/w_det_cours.debut?p_code_cours=S204033&amp;p_plan_is=0&amp;p_langue=1&amp;p_frame=N&amp;p_mode=PGC&amp;p_annee=2015&amp;p_suffixe=&amp;p_grtri= Présentation du cours sur le site du catalogue de cours wadme]&lt;/ref&gt;<br /> | enregistrement = <br /> | précédent = <br /> | suivant = [[Gestion du risque des projets SI]]<br /> }}<br /> <br /> =Processus de Développement des SI=<br /> Ensemble structuré d'activités à réaliser pour atteindre l'objectif d'un projet SI, dont les activités varient en fonction de l'organisation, du projet, et du type de système à développer. Ce processus doit être explicitement décrit pour être adéquatement géré.<br /> <br /> Le '''cycle de vie d'un SI''' décrit succintement les phases par lesquelles passe un système d'information depuis le '''besoin initial''' jusqu'au '''retrait du système''', la documentation et les décisions qui jalonnent le cycle.<br /> <br /> =Activités de développement des SI=<br /> <br /> *'''Spécification''' des exigences et des contraintes du système, établissement du cahier des charges<br /> *'''Conception''' de la solution, production d'un modèle du système à développer<br /> *'''Implémentation''' du système<br /> *'''Test''' du système, vérification de l'adéquation entre les propriétés implémentées du système et la spécification des besoins<br /> *'''Installation''' du système chez le client et vérification de son fonctionnement<br /> *'''Maintenance''' du système, réparation des fautes<br /> <br /> =Modèles standards de développement des SI=<br /> <br /> Il existe différents types de cycles de développement entrant dans la réalisation d'un logiciel. Ces cycles prendront en compte toutes les activités/étapes de développement des SI vus dans le point précédent.<br /> <br /> <br /> ==Code-and-fix==<br /> <br /> Modèle dirigé par la programmation.<br /> <br /> '''Compréhension du problème''' -&gt; '''Programmation''' -&gt; '''Test contre spécification''' -&gt; '''Fin''' si satisfait, sinon '''Mise au point du code''' et retour au '''Test contre spécification'''<br /> <br /> ==Transformation automatique==<br /> <br /> Développement basé sur la possibilité de transformer automatiquement des spécifications validées en programmes.<br /> <br /> Ce modèle nécessite un '''outil logiciel''' qui fait de telles transformations.<br /> <br /> '''Spécification''' -&gt; '''Validation''' -&gt; '''Transformation''' si validé, sinon retour à '''Spécification'''.<br /> <br /> ==Cascade / Waterfall==<br /> [[Fichier:Processus cascade waterfall.png|cadre|centré|Processus de développement en cascade/waterfall]]<br /> <br /> Processus de nature plutôt linéaire, centré '''activités''' avec un ordonnancement prédéfini des activités, dans lequel il est toujours possible de revenir en arrière.<br /> <br /> ===Initiation - Étude de faisabilité===<br /> <br /> *Analyser le problème<br /> *Définir les objectifs<br /> *Définir les frontières du système<br /> *Identifier les contraintes imposées (politiques, matériel, temps, technologies, etc.)<br /> *'''Évaluer la faisabilité technique, économique, opérationnelle.'''<br /> <br /> ===Spécification des exigences===<br /> <br /> *Définir le périmètre du SI<br /> *Analyser le domaine d'application<br /> *Identifier les exigences :<br /> **fonctionnelles : les activités de l'organisation qui devraient être couvertes par le SI<br /> **non fonctionnelles : les performances techniques, l'environnement d'utilisateur, système d'exploitation, matériel, etc.<br /> *Conceptualiser les besoins (cas d'utilisation, scénarios, objectifs, etc.)<br /> *Déterminer la priorité des besoins<br /> *Valider les exigences avec les utilisateurs<br /> *Élaborer un glossaire de termes<br /> <br /> ===Analyse===<br /> '''Exploration des solutions possibles : '''<br /> *Analyser les exigences<br /> *Proposer une ou plusieurs solutions conceptuelles <br /> **Vue structurelle du système (modèle objet)<br /> **Vue dynamique du système (cycle de vie des objets, diagrammes d'activités, etc.)<br /> *Proposer une architecture d'implémentation<br /> *Valider toutes les propositions avec les utilisateurs<br /> <br /> ===Conception===<br /> '''Spécification détaillée de la solution choisie :'''<br /> *Définir le modèle physique de la base de données<br /> *Définir les contraintes d'intégrité<br /> *Choisir le SGBD<br /> *Modéliser les interfaces utilisateur<br /> *Définir les standards de sécurité du système<br /> *Définir l'architecture du système<br /> <br /> ===Construction===<br /> '''Développement du code : '''<br /> *Créer les programmes<br /> *Créer et remplir les bases de données<br /> *Intégrer les sous-systèmes<br /> *Écrire la documentation<br /> <br /> ===Tests===<br /> *Tester les programmes<br /> *Tester le système global<br /> <br /> ===Mise en place===<br /> *S'assurer que tout le matériel et les réseaux nécessaires pour le nouveau SI sont mis en place<br /> *Installer le système<br /> *Former l'utilisateur<br /> <br /> ==Modèle en V==<br /> [[Fichier:Processus modele V.png|cadre|centré|Méthode de développement en V]]<br /> <br /> Décomposition du système en composants qui peuvent être développés de manière indépendante. <br /> <br /> ==Modèle en W==<br /> [[Fichier:Processus modele W.png|cadre|centré|Modèle de développement en W]]<br /> <br /> Ce modèle est une extension du modèle en V, qui améliore l'étape d'analyse des exigences.<br /> <br /> ===Modèle en W : accent sur les tests===<br /> [[Fichier:Processus modele W-tests.png|cadre|centré|Modèle de développement en W avec accent sur les tests]]<br /> <br /> Ce modèle est toujours une extension du modèle en V, mais avec une focalisation sur les '''tests''' à toutes les phases de développement.<br /> <br /> ==Développement évolutif==<br /> <br /> Développement de plusieurs versions d'un logiciel en l'améliorant à chaque fois.<br /> <br /> '''Détermination des besoins''' -&gt; '''Programmation''' -&gt; '''Expérimentation''' -&gt; '''Version N''' -&gt; '''Détermination des besoins''' -&gt; ...<br /> <br /> ==Spirale==<br /> [[Fichier:Processus spirale.png|cadre|centré|Modèle de développement en spirale]]<br /> <br /> <br /> ==RAD - Rapid Application Development==<br /> <br /> [[Fichier:Processus RAD.png|vignette|droite|Modèle de développement RAD]]<br /> <br /> Le RAD est un modèle '''linéaire''' en 5 phases et '''itératif''' pour la phase de construction. Chaque phase est composée d'une ou plusieurs étapes, et chaque étape est organisée en 3 temps :<br /> #Travaux préparatoires<br /> #Session participative<br /> #Travaux de conclusion<br /> <br /> Le logiciel est construit en plusieurs modules livrés successivement, et il privilégie aussi le travail d'équipe.<br /> <br /> ===Initialisation===<br /> '''Préparation et organisation du projet'''<br /> *Répertorier l'ensemble des intervenants<br /> *Définir les objectifs stratégiques du projet<br /> * Évaluer la faisabilité du projet<br /> * Évaluer les moyens nécessaires <br /> * Établir un accord entre le client et le fournisseur<br /> * Lancement du projet<br /> <br /> ===Cadrage===<br /> '''Analyse et spécification des exigences :'''<br /> * Définir la hiérarchie des objectifs<br /> * Définir la hiérarchie des fonctions<br /> * Planifier les changements des processus &quot;métier&quot;<br /> * Définir les ressources nécessaires et le cycle de développement<br /> * Valider les objectifs et les contraintes<br /> <br /> ===Conception===<br /> '''Conception de la solution : '''<br /> *Modéliser :<br /> **Établir une liste détaillée des fonctionnalités<br /> **Créer le modèle de données exhaustif<br /> *Préparer la documentation technique<br /> * Valider la conception d'ensemble<br /> * Choisir les technologies et les valider<br /> * Valider les modèles et le prototype<br /> * Valider les charges et le planning<br /> <br /> ===Construction===<br /> '''Développement collaboratif et incrémental'''<br /> * Détailler chaque module<br /> * Réaliser (coder) les modules<br /> * Intégrer les modules<br /> * Tester les modules<br /> * Tester l'intégration<br /> * Documenter<br /> Différents modules peuvent être développés en parallèle<br /> <br /> ===Finalisation===<br /> '''Préparer la mise en oeuvre :'''<br /> * Préparer le système à l'installation<br /> * Rédiger les manuels utilisateurs<br /> * Rédiger le manuel d'exploitation<br /> * Préparer la formation<br /> * Établir le plan de formation<br /> * Établir le plan de démarrage (reprises de données, bascule technique,...)<br /> '''Tester le système'''<br /> '''Démarrer le système :'''<br /> * Établir l'environnement d'exploitation et l'infrastructure du support d'exploitation<br /> * Mettre en oeuvre le plan de démarrage<br /> * Audit du fonctionnement et évaluation des écarts<br /> * Améliorer et optimiser le système<br /> * Former les utilisateurs<br /> <br /> ==RUP - Rational Unified Process==<br /> Processus itératif et incrémental divisé en 4 phases : <br /> #Initialisation : définition de l'objectif du projet et préparation d'un contrat de réalisation<br /> #Élaboration : planification du projet, spécification de la solution proposée, proposition d'une architecture de base<br /> #Construction : développement du produit<br /> #Transition : transition du produit chez les utilisateurs.<br /> Ces 4 phases sont elles-mêmes divisées en N itération, à la fin desquelles Il y a une version du produit livrable.<br /> <br /> ===Workflows===<br /> Étapes à réaliser dans chaque itération :<br /> * Modélisation d'entreprise (entreprise/business modeling)<br /> * Analyse des besoins<br /> * Analyse et conception<br /> * Implémentation<br /> * Test<br /> * Déploiement<br /> * Gestion de changements<br /> * Gestion de projet<br /> * Préparation d'environnement<br /> <br /> ==XP - Extreme Progamming==<br /> Modèle itératif à deux niveaux :<br /> *'''Itérations de livraison''' - un plan de livraison doit être défini avec le client<br /> **une livraison - une version opérationnelle du logiciel<br /> **durée de développement - quelques mois<br /> *'''Itérations de développement''' - une fonctionnalité livrable est décomposée en plusieurs fonctions simples :<br /> **développement par binômes<br /> **les utilisateurs participent aux chois des itérations et aux tests<br /> **durée - 2-4 semaines<br /> **résultat - une ou plusieurs fonctions qui peuvent être intégrées dans la version livrable<br /> <br /> ===Rôles===<br /> *'''Programmeur''' : est responsable de la conception technique et le codage évolutif<br /> *'''Client''' : doit exprimer ses exigences sous forme de scénarios (user stories) et écrire des jeux de tests fonctionnels<br /> *'''Testeur''' : aide le client à élaborer des jeux de test et à les exécuter<br /> *'''Tracker''' : est responsable de la gestion du temps : planification et contrôle<br /> *'''Coach''' : est responsable du soutien technique des membres de l'équipe<br /> *'''Manager / chef de projet''' : les rôles peuvent être combinés : un chef de projet peut réunir les rôles de manager, tracker et coach. <br /> <br /> ==SCRUM==<br /> <br /> Développement itératif et incrémental, fait référence à l'organisation d'un jeu de rugby : <br /> * '''avant-jeu''' : préparation, conception de haut niveau du système et son architecture : le périmètre et la base du contenu du système<br /> *'''jeu''' : développement itératif organisé en sprints de 2-4 semaines<br /> *'''après-jeu''' : livraison finale du système, clôture du projet.<br /> <br /> ===Vocabulaire===<br /> *'''Product backlog'''<br /> Une liste priorisée de besoins et exigences que veut le client, exprimé dans son vocabulaire et sa terminologie métier, souvent en termes de scénarios (user stories)<br /> *'''Sprint backlog''' <br /> Une liste de tâches identifiées par l'équipe du projet à réaliser pendant un sprint afin d'implémenter les scénarios sélectionnés pour ce sprint.<br /> *'''Daily scrum'''<br /> Chaque jour on organise une courte réunion (15 minutes) pour fixer et/ou ajuster les objectifs de la journée<br /> *'''Product owner (propriétaire)'''<br /> Représente le client en ce qui concerne les spécifications des exigences et les acceptations<br /> *'''Scrum master (capitaine d'équipe)'''<br /> Anime au quotidien l'équipe de développement, recadre le projet en cas de difficulté. Ce rôle donne lieu à une certification<br /> *'''Team members (les membres d'équipe)'''<br /> Architectes, développeurs, testeurs, administrateurs de base de données, etc. Les mebres d'équipe disposent d'une certaine autonomie dans l'organisation de leurs travaux.<br /> <br /> ===User story==<br /> Le scénario est une exigence du système à développer, formulée en une ou deux phrases dans le langage de l'utilisateur. Ces user stories émergent au cours d'ateliers de travail menés avec le Métier, le Client et/ou les utilisateurs.<br /> <br /> '''Le modèle de structure d'une User Story'''<br /> <br /> * En tant tant que &lt;rôle, personne, user type&gt;<br /> * Je veux &lt;fonctionnalité, tâche, action&gt;<br /> * Afin de &lt;valeur ajoutée, résultat&gt;<br /> <br /> '''Exemples :'''<br /> <br /> * ''En tant qu'acheteur en ligne, je veux pouvoir ajouter des items à mon panier afin d'enregistrer mes achats que je ne souhaite pas acheter dans l'immédiat.''<br /> * ''En tant qu'utilisateur, je veux réserver une chambre d'hôtel afin de...''<br /> * ''En tant qu'utilisateur, je veux annuler une réservat5ion afin de...''<br /> * ''En tant que recruteur, je veux déposer des offres d'emploi afin de...''<br /> * ''En tant que je une diplômé, je veux déposer un CV afin de...''<br /> * ''En tant que jeune diplômé, je veux supprimer un CV afin de...''<br /> <br /> <br /> = Annexes =<br /> <br /> = Références =</div>

Sania https://baripedia.org/index.php?title=Mod%C3%A8les_de_processus_de_d%C3%A9veloppement_des_SI&diff=32323 2016-06-03T14:39:29Z

<p>Sania : </p> <hr /> <div>{{Infobox Lecture<br /> | image = <br /> | cours = [[Gestion de projet]]<br /> | faculté = [[Faculté d'économie et de management]]<br /> | département = [[Services généraux GSEM]]<br /> | domaine = [[Système d'information]]<br /> | professeurs = [[Jolita Ralyte]]&lt;ref&gt;[http://cui.unige.ch/~ralyte/ Page personnelle de Jolita Ralyte sur le site du CUI]&lt;/ref&gt;<br /> | années = <br /> | code = S204033 CR &lt;ref&gt;[http://wadme.unige.ch:3149/pls/opprg/w_det_cours.debut?p_code_cours=S204033&amp;p_plan_is=0&amp;p_langue=1&amp;p_frame=N&amp;p_mode=PGC&amp;p_annee=2015&amp;p_suffixe=&amp;p_grtri= Présentation du cours sur le site du catalogue de cours wadme]&lt;/ref&gt;<br /> | enregistrement = <br /> | précédent = <br /> | suivant = [[Gestion du risque des projets SI]]<br /> }}<br /> <br /> =Processus de Développement des SI=<br /> Ensemble structuré d'activités à réaliser pour atteindre l'objectif d'un projet SI, dont les activités varient en fonction de l'organisation, du projet, et du type de système à développer. Ce processus doit être explicitement décrit pour être adéquatement géré.<br /> <br /> Le '''cycle de vie d'un SI''' décrit succintement les phases par lesquelles passe un système d'information depuis le '''besoin initial''' jusqu'au '''retrait du système''', la documentation et les décisions qui jalonnent le cycle.<br /> <br /> =Activités de développement des SI=<br /> <br /> *'''Spécification''' des exigences et des contraintes du système, établissement du cahier des charges<br /> *'''Conception''' de la solution, production d'un modèle du système à développer<br /> *'''Implémentation''' du système<br /> *'''Test''' du système, vérification de l'adéquation entre les propriétés implémentées du système et la spécification des besoins<br /> *'''Installation''' du système chez le client et vérification de son fonctionnement<br /> *'''Maintenance''' du système, réparation des fautes<br /> <br /> =Modèles standards de développement des SI=<br /> <br /> ==Code-and-fix==<br /> <br /> Modèle dirigé par la programmation.<br /> <br /> '''Compréhension du problème''' -&gt; '''Programmation''' -&gt; '''Test contre spécification''' -&gt; '''Fin''' si satisfait, sinon '''Mise au point du code''' et retour au '''Test contre spécification'''<br /> <br /> ==Transformation automatique==<br /> <br /> Développement basé sur la possibilité de transformer automatiquement des spécifications validées en programmes.<br /> <br /> Ce modèle nécessite un '''outil logiciel''' qui fait de telles transformations.<br /> <br /> '''Spécification''' -&gt; '''Validation''' -&gt; '''Transformation''' si validé, sinon retour à '''Spécification'''.<br /> <br /> ==Cascade / Waterfall==<br /> [[Fichier:Processus cascade waterfall.png|cadre|centré|Processus de développement en cascade/waterfall]]<br /> <br /> Processus de nature plutôt linéaire, centré '''activités''' avec un ordonnancement prédéfini des activités, dans lequel il est toujours possible de revenir en arrière.<br /> <br /> ===Initiation - Étude de faisabilité===<br /> <br /> *Analyser le problème<br /> *Définir les objectifs<br /> *Définir les frontières du système<br /> *Identifier les contraintes imposées (politiques, matériel, temps, technologies, etc.)<br /> *'''Évaluer la faisabilité technique, économique, opérationnelle.'''<br /> <br /> ===Spécification des exigences===<br /> <br /> *Définir le périmètre du SI<br /> *Analyser le domaine d'application<br /> *Identifier les exigences :<br /> **fonctionnelles : les activités de l'organisation qui devraient être couvertes par le SI<br /> **non fonctionnelles : les performances techniques, l'environnement d'utilisateur, système d'exploitation, matériel, etc.<br /> *Conceptualiser les besoins (cas d'utilisation, scénarios, objectifs, etc.)<br /> *Déterminer la priorité des besoins<br /> *Valider les exigences avec les utilisateurs<br /> *Élaborer un glossaire de termes<br /> <br /> ===Analyse===<br /> '''Exploration des solutions possibles : '''<br /> *Analyser les exigences<br /> *Proposer une ou plusieurs solutions conceptuelles <br /> **Vue structurelle du système (modèle objet)<br /> **Vue dynamique du système (cycle de vie des objets, diagrammes d'activités, etc.)<br /> *Proposer une architecture d'implémentation<br /> *Valider toutes les propositions avec les utilisateurs<br /> <br /> ===Conception===<br /> '''Spécification détaillée de la solution choisie :'''<br /> *Définir le modèle physique de la base de données<br /> *Définir les contraintes d'intégrité<br /> *Choisir le SGBD<br /> *Modéliser les interfaces utilisateur<br /> *Définir les standards de sécurité du système<br /> *Définir l'architecture du système<br /> <br /> ===Construction===<br /> '''Développement du code : '''<br /> *Créer les programmes<br /> *Créer et remplir les bases de données<br /> *Intégrer les sous-systèmes<br /> *Écrire la documentation<br /> <br /> ===Tests===<br /> *Tester les programmes<br /> *Tester le système global<br /> <br /> ===Mise en place===<br /> *S'assurer que tout le matériel et les réseaux nécessaires pour le nouveau SI sont mis en place<br /> *Installer le système<br /> *Former l'utilisateur<br /> <br /> ==Modèle en V==<br /> [[Fichier:Processus modele V.png|cadre|centré|Méthode de développement en V]]<br /> <br /> Décomposition du système en composants qui peuvent être développés de manière indépendante. <br /> <br /> ==Modèle en W==<br /> [[Fichier:Processus modele W.png|cadre|centré|Modèle de développement en W]]<br /> <br /> Ce modèle est une extension du modèle en V, qui améliore l'étape d'analyse des exigences.<br /> <br /> ===Modèle en W : accent sur les tests===<br /> [[Fichier:Processus modele W-tests.png|cadre|centré|Modèle de développement en W avec accent sur les tests]]<br /> <br /> Ce modèle est toujours une extension du modèle en V, mais avec une focalisation sur les '''tests''' à toutes les phases de développement.<br /> <br /> ==Développement évolutif==<br /> <br /> Développement de plusieurs versions d'un logiciel en l'améliorant à chaque fois.<br /> <br /> '''Détermination des besoins''' -&gt; '''Programmation''' -&gt; '''Expérimentation''' -&gt; '''Version N''' -&gt; '''Détermination des besoins''' -&gt; ...<br /> <br /> ==Spirale==<br /> [[Fichier:Processus spirale.png|cadre|centré|Modèle de développement en spirale]]<br /> <br /> <br /> ==RAD - Rapid Application Development==<br /> <br /> [[Fichier:Processus RAD.png|vignette|droite|Modèle de développement RAD]]<br /> <br /> Le RAD est un modèle '''linéaire''' en 5 phases et '''itératif''' pour la phase de construction. Chaque phase est composée d'une ou plusieurs étapes, et chaque étape est organisée en 3 temps :<br /> #Travaux préparatoires<br /> #Session participative<br /> #Travaux de conclusion<br /> <br /> Le logiciel est construit en plusieurs modules livrés successivement, et il privilégie aussi le travail d'équipe.<br /> <br /> ===Initialisation===<br /> '''Préparation et organisation du projet'''<br /> *Répertorier l'ensemble des intervenants<br /> *Définir les objectifs stratégiques du projet<br /> * Évaluer la faisabilité du projet<br /> * Évaluer les moyens nécessaires <br /> * Établir un accord entre le client et le fournisseur<br /> * Lancement du projet<br /> <br /> ===Cadrage===<br /> '''Analyse et spécification des exigences :'''<br /> * Définir la hiérarchie des objectifs<br /> * Définir la hiérarchie des fonctions<br /> * Planifier les changements des processus &quot;métier&quot;<br /> * Définir les ressources nécessaires et le cycle de développement<br /> * Valider les objectifs et les contraintes<br /> <br /> ===Conception===<br /> '''Conception de la solution : '''<br /> *Modéliser :<br /> **Établir une liste détaillée des fonctionnalités<br /> **Créer le modèle de données exhaustif<br /> *Préparer la documentation technique<br /> * Valider la conception d'ensemble<br /> * Choisir les technologies et les valider<br /> * Valider les modèles et le prototype<br /> * Valider les charges et le planning<br /> <br /> ===Construction===<br /> '''Développement collaboratif et incrémental'''<br /> * Détailler chaque module<br /> * Réaliser (coder) les modules<br /> * Intégrer les modules<br /> * Tester les modules<br /> * Tester l'intégration<br /> * Documenter<br /> Différents modules peuvent être développés en parallèle<br /> <br /> ===Finalisation===<br /> '''Préparer la mise en oeuvre :'''<br /> * Préparer le système à l'installation<br /> * Rédiger les manuels utilisateurs<br /> * Rédiger le manuel d'exploitation<br /> * Préparer la formation<br /> * Établir le plan de formation<br /> * Établir le plan de démarrage (reprises de données, bascule technique,...)<br /> '''Tester le système'''<br /> '''Démarrer le système :'''<br /> * Établir l'environnement d'exploitation et l'infrastructure du support d'exploitation<br /> * Mettre en oeuvre le plan de démarrage<br /> * Audit du fonctionnement et évaluation des écarts<br /> * Améliorer et optimiser le système<br /> * Former les utilisateurs<br /> <br /> ==RUP - Rational Unified Process==<br /> Processus itératif et incrémental divisé en 4 phases : <br /> #Initialisation : définition de l'objectif du projet et préparation d'un contrat de réalisation<br /> #Élaboration : planification du projet, spécification de la solution proposée, proposition d'une architecture de base<br /> #Construction : développement du produit<br /> #Transition : transition du produit chez les utilisateurs.<br /> Ces 4 phases sont elles-mêmes divisées en N itérations, à la fin desquelles Il y a une version du produit livrable.<br /> <br /> <br /> = Annexes =<br /> <br /> = Références =</div>

Sania https://baripedia.org/index.php?title=Mod%C3%A8les_de_processus_de_d%C3%A9veloppement_des_SI&diff=32322 2016-06-02T17:59:09Z

<p>Sania : Page créée avec « {{Infobox Lecture | image = | cours = Gestion de projet | faculté = Faculté d'économie et de management | département = Services généraux GSEM | do... »</p> <hr /> <div>{{Infobox Lecture<br /> | image = <br /> | cours = [[Gestion de projet]]<br /> | faculté = [[Faculté d'économie et de management]]<br /> | département = [[Services généraux GSEM]]<br /> | domaine = [[Système d'information]]<br /> | professeurs = [[Jolita Ralyte]]&lt;ref&gt;[http://cui.unige.ch/~ralyte/ Page personnelle de Jolita Ralyte sur le site du CUI]&lt;/ref&gt;<br /> | années = <br /> | code = S204033 CR &lt;ref&gt;[http://wadme.unige.ch:3149/pls/opprg/w_det_cours.debut?p_code_cours=S204033&amp;p_plan_is=0&amp;p_langue=1&amp;p_frame=N&amp;p_mode=PGC&amp;p_annee=2015&amp;p_suffixe=&amp;p_grtri= Présentation du cours sur le site du catalogue de cours wadme]&lt;/ref&gt;<br /> | enregistrement = <br /> | précédent = <br /> | suivant = [[Gestion du risque des projets SI]]<br /> }}<br /> <br /> =Processus de Développement des SI=<br /> Ensemble structuré d'activités à réaliser pour atteindre l'objectif d'un projet SI, dont les activités varient en fonction de l'organisation, du projet, et du type de système à développer. Ce processus doit être explicitement décrit pour être adéquatement géré.<br /> <br /> Le '''cycle de vie d'un SI''' décrit succintement les phases par lesquelles passe un système d'information depuis le '''besoin initial''' jusqu'au '''retrait du système''', la documentation et les décisions qui jalonnent le cycle.<br /> <br /> =Activités de développement des SI=<br /> <br /> *'''Spécification''' des exigences et des contraintes du système, établissement du cahier des charges<br /> *'''Conception''' de la solution, production d'un modèle du système à développer<br /> *'''Implémentation''' du système<br /> *'''Test''' du système, vérification de l'adéquation entre les propriétés implémentées du système et la spécification des besoins<br /> *'''Installation''' du système chez le client et vérification de son fonctionnement<br /> *'''Maintenance''' du système, réparation des fautes<br /> <br /> =Modèles standards de développement des SI=<br /> <br /> ==Code-and-fix==<br /> <br /> Modèle dirigé par la programmation.<br /> <br /> '''Compréhension du problème''' -&gt; '''Programmation''' -&gt; '''Test contre spécification''' -&gt; '''Fin''' si satisfait, sinon '''Mise au point du code''' et retour au '''Test contre spécification'''<br /> <br /> ==Transformation automatique==<br /> <br /> Développement basé sur la possibilité de transformer automatiquement des spécifications validées en programmes.<br /> <br /> Ce modèle nécessite un '''outil logiciel''' qui fait de telles transformations.<br /> <br /> '''Spécification''' -&gt; '''Validation''' -&gt; '''Transformation''' si validé, sinon retour à '''Spécification'''.<br /> <br /> ==Cascade / Waterfall==<br /> [[Fichier:Processus cascade waterfall.png|cadre|centré|Processus de développement en cascade/waterfall]]<br /> <br /> Processus de nature plutôt linéaire, centré '''activités''' avec un ordonnancement prédéfini des activités, dans lequel il est toujours possible de revenir en arrière.<br /> <br /> ===Initiation - Étude de faisabilité===<br /> <br /> *Analyser le problème<br /> *Définir les objectifs<br /> *Définir les frontières du système<br /> *Identifier les contraintes imposées (politiques, matériel, temps, technologies, etc.)<br /> *'''Évaluer la faisabilité technique, économique, opérationnelle.'''<br /> <br /> ===Spécification des exigences===<br /> <br /> *Définir le périmètre du SI<br /> *Analyser le domaine d'application<br /> *Identifier les exigences :<br /> **fonctionnelles : les activités de l'organisation qui devraient être couvertes par le SI<br /> **non fonctionnelles : les performances techniques, l'environnement d'utilisateur, système d'exploitation, matériel, etc.<br /> *Conceptualiser les besoins (cas d'utilisation, scénarios, objectifs, etc.)<br /> *Déterminer la priorité des besoins<br /> *Valider les exigences avec les utilisateurs<br /> *Élaborer un glossaire de termes<br /> <br /> ===Analyse===<br /> '''Exploration des solutions possibles : '''<br /> *Analyser les exigences<br /> *Proposer une ou plusieurs solutions conceptuelles <br /> **Vue structurelle du système (modèle objet)<br /> **Vue dynamique du système (cycle de vie des objets, diagrammes d'activités, etc.)<br /> *Proposer une architecture d'implémentation<br /> *Valider toutes les propositions avec les utilisateurs<br /> <br /> ===Conception===<br /> '''Spécification détaillée de la solution choisie :'''<br /> *Définir le modèle physique de la base de données<br /> *Définir les contraintes d'intégrité<br /> *Choisir le SGBD<br /> *Modéliser les interfaces utilisateur<br /> *Définir les standards de sécurité du système<br /> *Définir l'architecture du système<br /> <br /> ===Construction===<br /> '''Développement du code : '''<br /> *Créer les programmes<br /> *Créer et remplir les bases de données<br /> *Intégrer les sous-systèmes<br /> *Écrire la documentation<br /> <br /> ===Tests===<br /> *Tester les programmes<br /> *Tester le système global<br /> <br /> ===Mise en place===<br /> *S'assurer que tout le matériel et les réseaux nécessaires pour le nouveau SI sont mis en place<br /> *Installer le système<br /> *Former l'utilisateur<br /> <br /> ==Modèle en V==<br /> [[Fichier:Processus modele V.png|cadre|centré|Méthode de développement en V]]<br /> <br /> Décomposition du système en composants qui peuvent être développés de manière indépendante. <br /> <br /> ==Modèle en W==<br /> [[Fichier:Processus modele W.png|cadre|centré|Modèle de développement en W]]<br /> <br /> Ce modèle est une extension du modèle en V, qui améliore l'étape d'analyse des exigences.<br /> <br /> ===Modèle en W : accent sur les tests===<br /> [[Fichier:Processus modele W-tests.png|cadre|centré|Modèle de développement en W avec accent sur les tests]]<br /> <br /> Ce modèle est toujours une extension du modèle en V, mais avec une focalisation sur les '''tests''' à toutes les phases de développement.<br /> <br /> ==Développement évolutif==<br /> <br /> Développement de plusieurs versions d'un logiciel en l'améliorant à chaque fois.<br /> <br /> '''Détermination des besoins''' -&gt; '''Programmation''' -&gt; '''Expérimentation''' -&gt; '''Version N''' -&gt; '''Détermination des besoins''' -&gt; ...<br /> <br /> ==Spirale==<br /> [[Fichier:Processus spirale.png|cadre|centré|Modèle de développement en spirale]]<br /> <br /> <br /> ==RAD - Rapid Application Development==<br /> <br /> [[Fichier:Processus RAD.png|vignette|droite|Modèle de développement RAD]]<br /> <br /> Le RAD est un modèle '''linéaire''' en 5 phases et '''itératif''' pour la phase de construction. Chaque phase est composée d'une ou plusieurs étapes, et chaque étape est organisée en 3 temps :<br /> #Travaux préparatoires<br /> #Session participative<br /> #Travaux de conclusion<br /> <br /> Le logiciel est construit en plusieurs modules livrés successivement, et il privilégie aussi le travail d'équipe.<br /> <br /> ===Initialisation===<br /> '''Préparation et organisation du projet'''<br /> *Répertorier l'ensemble des intervenants<br /> *Définir les objectifs stratégiques du projet<br /> * Évaluer la faisabilité du projet<br /> * Évaluer les moyens nécessaires <br /> * Établir un accord entre le client et le fournisseur<br /> * Lancement du projet<br /> <br /> ===Cadrage===<br /> '''Analyse et spécification des exigences :'''<br /> * Définir la hiérarchie des objectifs<br /> * Définir la hiérarchie des fonctions<br /> * Planifier les changements des processus &quot;métier&quot;<br /> * Définir les ressources nécessaires et le cycle de développement<br /> * Valider les objectifs et les contraintes<br /> <br /> ===Conception===<br /> '''Conception de la solution : '''<br /> *Modéliser :<br /> **Établir une liste détaillée des fonctionnalités<br /> **Créer le modèle de données exhaustif<br /> *Préparer la documentation technique<br /> * Valider la conception d'ensemble<br /> * Choisir les technologies et les valider<br /> * Valider les modèles et le prototype<br /> * Valider les charges et le planning<br /> <br /> ===Construction===<br /> '''Développement collaboratif et incrémental'''<br /> * Détailler chaque module<br /> * Réaliser (coder) les modules<br /> * Intégrer les modules<br /> * Tester les modules<br /> * Tester l'intégration<br /> * Documenter<br /> Différents modules peuvent être développés en parallèle<br /> <br /> ===Finalisation===<br /> '''Préparer la mise en oeuvre :'''<br /> * Préparer le système à l'installation<br /> * Rédiger les manuels utilisateurs<br /> * Rédiger le manuel d'exploitation<br /> * Préparer la formation<br /> * Établir le plan de formation<br /> * Établir le plan de démarrage (reprises de données, bascule technique,...)<br /> '''Tester le système'''<br /> '''Démarrer le système :'''<br /> * Établir l'environnement d'exploitation et l'infrastructure du support d'exploitation<br /> * Mettre en oeuvre le plan de démarrage<br /> * Audit du fonctionnement et évaluation des écarts<br /> * Améliorer et optimiser le système<br /> * Former les utilisateurs<br /> <br /> = Annexes =<br /> <br /> = Références =</div>

Sania https://baripedia.org/index.php?title=Fichier:Processus_RAD.png&diff=32321 2016-06-02T16:07:51Z

<p>Sania : Modèle de développement RAD</p> <hr /> <div>Modèle de développement RAD</div>

Sania https://baripedia.org/index.php?title=Fichier:Processus_spirale.png&diff=32320 2016-06-02T16:06:14Z

<p>Sania : Modèle de développement SI en spirale</p> <hr /> <div>Modèle de développement SI en spirale</div>

Sania https://baripedia.org/index.php?title=Fichier:Processus_modele_W-tests.png&diff=32319 2016-06-02T16:01:56Z

<p>Sania : Modèle de développement en W avec accent sur les tests</p> <hr /> <div>Modèle de développement en W avec accent sur les tests</div>

Sania https://baripedia.org/index.php?title=Fichier:Processus_modele_W.png&diff=32318 2016-06-02T16:00:17Z

<p>Sania : Modèle de développement en W</p> <hr /> <div>Modèle de développement en W</div>

Sania https://baripedia.org/index.php?title=Fichier:Processus_modele_V.png&diff=32317 2016-06-02T15:59:03Z

<p>Sania : Processus de développement de SI - Modèle en V</p> <hr /> <div>Processus de développement de SI - Modèle en V</div>

Sania https://baripedia.org/index.php?title=Fichier:Processus_cascade_waterfall.png&diff=32316 2016-06-02T15:27:42Z

<p>Sania : Processus de développement d'un SI en casacade/waterfall</p> <hr /> <div>Processus de développement d'un SI en casacade/waterfall</div>

Sania https://baripedia.org/index.php?title=D%C3%A9coupage_de_projets&diff=32270 2016-05-16T23:29:10Z

<p>Sania : </p> <hr /> <div>{{Infobox Lecture<br /> | image = <br /> | cours = [[Gestion de projet]]<br /> | faculté = [[Faculté d'économie et de management]]<br /> | département = [[Services généraux GSEM]]<br /> | domaine = [[Système d'information]]<br /> | professeurs = [[Jolita Ralyte]]&lt;ref&gt;[http://cui.unige.ch/~ralyte/ Page personnelle de Jolita Ralyte sur le site du CUI]&lt;/ref&gt;<br /> | années = <br /> | code = S204033 CR &lt;ref&gt;[http://wadme.unige.ch:3149/pls/opprg/w_det_cours.debut?p_code_cours=S204033&amp;p_plan_is=0&amp;p_langue=1&amp;p_frame=N&amp;p_mode=PGC&amp;p_annee=2015&amp;p_suffixe=&amp;p_grtri= Présentation du cours sur le site du catalogue de cours wadme]&lt;/ref&gt;<br /> | enregistrement = <br /> | précédent = <br /> | suivant = [[Modèles de processus de développement des SI]]<br /> }}<br /> <br /> =Pourquoi découper le projet=<br /> <br /> Découper un projet permet de '''mieux gérer la complexité et le risque de projets''', '''estimer le coût et la durée des projets''', répartir dans le temps la production et les ressources'''.<br /> <br /> ==Work Breakdown Structure (WBS)==<br /> <br /> Le '''WBS''' est une décomposition hiérarchique et &quot;orientée livrable&quot; du travail à réaliser par l'équipe de projet permettant d'atteindre les objectifs du projet et créer le livrable demandé.<br /> <br /> *Dépendances et enchaînement<br /> *Équipe, affectations et responsabilités<br /> *Analyse des risques<br /> *Analyse de la performance<br /> *Estimation de temps et de coût<br /> <br /> <br /> =Principes de découpage=<br /> <br /> Découper un projet consiste à identifier des composants quasi autonomes, présentant les caractéristiques suivantes :<br /> *chaque composant donne lieu à un '''résultat bien identifié'''<br /> *la '''charge propre''' à chacun peut être évaluée<br /> *les '''contraintes d'enchaînement''' de réalisation entre les composants sont repérables<br /> **certains composants peuvent être réalisées parallèlement, d'autres sont liés entre eux par des contraintes d'antériorité<br /> *le découpage est fait à des '''mailles différentes'''<br /> **un composant étant souvent à son tour décomposé<br /> <br /> Les seules relations entre les composants, en général, ne montrent pas d'autres dépendances entre les composants ni la durée des composants.<br /> <br /> '''Représentation :'''<br /> *graphique - une structure d'arbre ou un graphe<br /> *un texte structuré<br /> *utilisation d'un système de numérotation pour identifier les éléments<br /> <br /> =Typologie de découpages=<br /> <br /> *'''PBS''' - Product Breakdown Structure : découpage structurel du produit<br /> *'''WBS''' - Process/work Breakdown Structure : découpage du processus de travail<br /> **Hybrid WBS : combinaison de PBS et WBS<br /> *'''RBS''' - Resource Breakdown Structure : répartition des ressources<br /> *'''OBS''' - Organisation Breakdown Structure : découpage de l'organisation<br /> <br /> ==PBS - Product Breakdown Structure - Découpage structurel==<br /> <br /> Découpage structurel, orienté '''entité livrable'''. Le produit final est décomposé en plusieurs entités : '''composants -&gt; unités -&gt; parties.''' Ce découpage permet d'organiser le travail en se basant sur la structure du produit final.<br /> <br /> L'utilisation du découpage structurel requiert une visibilité suffisante sur le résultat à produire. Différentes perspectives :<br /> '''Découpage informationnel et/ou métier'''<br /> Critères :<br /> *Organisationnels : départements, métiers, rôles<br /> *Fonctionnels : activités, processus, tâches<br /> *Informationnels : informations, états, données<br /> '''Découpage par couches techniques du système'''<br /> *''Exemple : Système de gestion de la production -&gt; Spécifications, interface, base de données, applications -&gt; exigences, architecture / formes, charte graphique / schéma BD / procédures métier, administration''<br /> '''Combinaison des deux perspectives'''<br /> <br /> ====Avantages du découpage structurel====<br /> '''Meilleure maîtrise du projet : '''<br /> *la taille d'un composant est plus réduite et plus facile à maîtriser<br /> '''Répartition des responsabilités :'''<br /> *répartition des composants dans des sous-projets séparés<br /> *un responsable par composant<br /> *possibilité de sous-traiter la réalisation de certains composant<br /> '''Réduction des délais planifiés :'''<br /> *développement de certains composants en parallèle<br /> '''Développement incrémental :'''<br /> *essentiel pour le développement d'un SI par versions successives.<br /> <br /> ==WBS - Work Breakdown Structure - Découpage processus==<br /> <br /> Découpage orienté '''activité.''' Représente la façon de parvenir au résultat tel qu'il est décrit dans le PBS<br /> <br /> Le processus de conduit de projet est décomposé en plusieurs niveaux : '''phases -&gt; étapes -&gt; tâches.'''<br /> <br /> ''Exemple : Processus de développement du système -&gt; Analyse des besoins -&gt; Besoins fonctionnels -&gt; Identification des acteurs, identifications des fonctionnalités.''<br /> <br /> ===Découpage temporel de processus===<br /> <br /> C'est le premier pas vers la planification, et cela permet d'organiser et de répartir le travail dans le temps. On détermine les liens d'enchaînement entre les phases/étapes/tâches. <br /> <br /> *On définit les dates de chaque phase/étape/tâche :<br /> **chaque phase/étape/tâche a une '''date de début''' prévue et une '''date de fin''' visée<br /> **chaque date représente un jalon permettant de marquer les points de décision du parcours.<br /> *Le découpage temporel est souvent de type descendant (top-down), et il favorise :<br /> **une '''visibilité croissante''' : les résultats sont de plus en plus précis et la maille d'étude de plus en plus fine<br /> **une '''progression''' réelle des travaux : dans la mesure où les résultats consolidés en fin d'une étape ne sont pas remis en question dans les étapes suivantes.<br /> <br /> Les sous-projets peuvent être réalisés l'un après l'autre ou en parallèle. <br /> <br /> ==Hybrid WBS==<br /> <br /> Combinaison des deux critères : structurel et processus<br /> <br /> {| class=&quot;wikitable&quot;<br /> |-<br /> | || Étude préalable || Étude détaillée || Réalisation|| Mise en place<br /> |-<br /> | Système de gestion de la production || || || || <br /> |-<br /> | Système de gestion des ventes || || || || <br /> |-<br /> | Système de gestion de la logistique || || || || <br /> |}<br /> <br /> Deux façons de combiner les critères :<br /> *'''Processus d'abord''' : définition des phases de réalisation en précisant les composants de produit qui sont livrés dans chaque phase.<br /> *'''Livrable d'abord''' : définition des produits à livrer en précisant le processus d'élaboration.<br /> &lt;gallery&gt;<br /> hybrid_processus_dabord.png|Exemple Processus d'abord<br /> hybrid_livrable_dabord.png|Exemple Livrable d'abord<br /> &lt;/gallery&gt;<br /> <br /> ==RBS - Resource Breakdown Structure - Répartition des ressources==<br /> <br /> Ce découpage a pour objectif de '''définir et structurer les ressources humaines du projet''', les regrouper par nature ou en équipes. Il '''représente les liens hiérarchiques dans l'équipe''' du projet, et permet d'évaluer la quantification des ressources nécessaires au projet, dont la charge est issue des estimations du temps à passer par tâche et par profil.<br /> <br /> ==OBS - Organisation Breakdown Structure - Découpage de l'organisation==<br /> [[Fichier:Obs exemple.png|cadre|centré|Exemple d'Organisation Breakdown Structure]]<br /> <br /> Ce découpage reprend le WBS et fait apparaître les noms des personnes avec leurs responsabilités. Ainsi, il permet d'identifier les différents niveaux de responsabilités des acteurs du RBS :<br /> *R : responsabilité (obligatoire et unique<br /> *E : encadrement<br /> *P : production (ou participation)<br /> *V : validation<br /> *C : certification/approbation<br /> *S : support<br /> <br /> =Découpage temporel standard des projets industriels=<br /> <br /> '''Étude de faisabilité :'''<br /> *vérification si le projet est techniquement réalisable (analyse, recherche, études sur le terrain, etc.)<br /> **''Exemple : si l'on veut construire un immeuble, il faut vérifier que le terrain et le sous-sol le permettent.<br /> '''Définition des solutions : '''<br /> *une représentation précise de l'objectif à atteindre (réalisation des essaies, des maquettes, des prototypes)<br /> '''Conception détaillée :'''<br /> *préparation des contrats de réalisation (les cahiers des charges pour les sous-traitants)<br /> '''Réalisation :'''<br /> *l'exécution des contrats conformément aux cahier des charges.<br /> <br /> ==Problèmes de découpage standard dans les projets SI==<br /> <br /> Deux situations :<br /> <br /> *'''Le cahier des charges est défini en amont du projet'''<br /> <br /> Les besoins spécifiés sont rarement stables, de nouveaux besoins émergent durant le projet.<br /> <br /> Les étapes de conception sont risquées.<br /> *'''Le cahier des charges est défini durant la conception détaillée des solutions (fait partie du projet)<br /> <br /> L'élaboration d'un cahier des charges est un travail coûteux - absence de composants réutilisables.<br /> <br /> ''Exemple : la définition d'un système de gestion de clients serait allégée si l'on pouvait réutiliser des fonctions standard comme création d'un client, mise à jour d'un client, etc., sans avoir à les concevoir et les décrire intégralement.''<br /> <br /> Les ateliers de génie logiciel offrent des outils de modélisation et non des modèles concrets.<br /> <br /> =Découpage à la MERISE=</div>

Sania https://baripedia.org/index.php?title=Fichier:Obs_exemple.png&diff=32269 2016-05-16T23:20:34Z

<p>Sania : Organisation Breakdown Structure : exemple</p> <hr /> <div>Organisation Breakdown Structure : exemple</div>

Sania https://baripedia.org/index.php?title=Fichier:Hybrid_livrable_dabord.png&diff=32268 2016-05-16T23:14:11Z

<p>Sania : Hybrid WBS : exemple livrable d'abord</p> <hr /> <div>Hybrid WBS : exemple livrable d'abord</div>

Sania https://baripedia.org/index.php?title=Fichier:Hybrid_processus_dabord.png&diff=32267 2016-05-16T23:13:08Z

<p>Sania : Hybrid WBS : exemple Processus d'abord</p> <hr /> <div>Hybrid WBS : exemple Processus d'abord</div>

Sania https://baripedia.org/index.php?title=D%C3%A9coupage_de_projets&diff=32266 2016-05-16T22:59:47Z

<p>Sania : Page créée avec « {{Infobox Lecture | image = | cours = Gestion de projet | faculté = Faculté d'économie et de management | département = Services généraux GSEM | do... »</p> <hr /> <div>{{Infobox Lecture<br /> | image = <br /> | cours = [[Gestion de projet]]<br /> | faculté = [[Faculté d'économie et de management]]<br /> | département = [[Services généraux GSEM]]<br /> | domaine = [[Système d'information]]<br /> | professeurs = [[Jolita Ralyte]]&lt;ref&gt;[http://cui.unige.ch/~ralyte/ Page personnelle de Jolita Ralyte sur le site du CUI]&lt;/ref&gt;<br /> | années = <br /> | code = S204033 CR &lt;ref&gt;[http://wadme.unige.ch:3149/pls/opprg/w_det_cours.debut?p_code_cours=S204033&amp;p_plan_is=0&amp;p_langue=1&amp;p_frame=N&amp;p_mode=PGC&amp;p_annee=2015&amp;p_suffixe=&amp;p_grtri= Présentation du cours sur le site du catalogue de cours wadme]&lt;/ref&gt;<br /> | enregistrement = <br /> | précédent = <br /> | suivant = [[Modèles de processus de développement des SI]]<br /> }}<br /> <br /> =Pourquoi découper le projet=<br /> <br /> Découper un projet permet de '''mieux gérer la complexité et le risque de projets''', '''estimer le coût et la durée des projets''', répartir dans le temps la production et les ressources'''.<br /> <br /> ==Work Breakdown Structure (WBS)==<br /> <br /> Le '''WBS''' est une décomposition hiérarchique et &quot;orientée livrable&quot; du travail à réaliser par l'équipe de projet permettant d'atteindre les objectifs du projet et créer le livrable demandé.<br /> <br /> *Dépendances et enchaînement<br /> *Équipe, affectations et responsabilités<br /> *Analyse des risques<br /> *Analyse de la performance<br /> *Estimation de temps et de coût<br /> <br /> <br /> =Principes de découpage=<br /> <br /> Découper un projet consiste à identifier des composants quasi autonomes, présentant les caractéristiques suivantes :<br /> *chaque composant donne lieu à un '''résultat bien identifié'''<br /> *la '''charge propre''' à chacun peut être évaluée<br /> *les '''contraintes d'enchaînement''' de réalisation entre les composants sont repérables<br /> **certains composants peuvent être réalisées parallèlement, d'autres sont liés entre eux par des contraintes d'antériorité<br /> *le découpage est fait à des '''mailles différentes'''<br /> **un composant étant souvent à son tour décomposé<br /> <br /> Les seules relations entre les composants, en général, ne montrent pas d'autres dépendances entre les composants ni la durée des composants.<br /> <br /> '''Représentation :'''<br /> *graphique - une structure d'arbre ou un graphe<br /> *un texte structuré<br /> *utilisation d'un système de numérotation pour identifier les éléments<br /> <br /> ==Types de découpage standardisé==<br /> <br /> *'''PBS''' - Product Breakdown Structure : découpage structurel du produit<br /> *'''WBS''' - Process/work Breakdown Structure : découpage du processus de travail<br /> **Hybrid WBS : combinaison de PBS et WBS<br /> *'''RBS''' - Resource Breakdown Structure : répartition des ressources<br /> *'''OBS''' - Organisation Breakdown Structure : découpage de l'organisation<br /> <br /> ===PBS - Product Breakdown Structure - Découpage structurel===<br /> <br /> Découpage structurel, orienté '''entité livrable'''. Le produit final est décomposé en plusieurs entités : '''composants -&gt; unités -&gt; parties.''' Ce découpage permet d'organiser le travail en se basant sur la structure du produit final.<br /> <br /> L'utilisation du découpage structurel requiert une visibilité suffisante sur le résultat à produire. Différentes perspectives :<br /> '''Découpage informationnel et/ou métier'''<br /> Critères :<br /> *Organisationnels : départements, métiers, rôles<br /> *Fonctionnels : activités, processus, tâches<br /> *Informationnels : informations, états, données<br /> '''Découpage par couches techniques du système'''<br /> *''Exemple : Système de gestion de la production -&gt; Spécifications, interface, base de données, applications -&gt; exigences, architecture / formes, charte graphique / schéma BD / procédures métier, administration''<br /> '''Combinaison des deux perspectives'''<br /> <br /> ====Avantages du découpage structurel====<br /> '''Meilleure maîtrise du projet : '''<br /> *la taille d'un composant est plus réduite et plus facile à maîtriser<br /> '''Répartition des responsabilités :'''<br /> *répartition des composants dans des sous-projets séparés<br /> *un responsable par composant<br /> *possibilité de sous-traiter la réalisation de certains composant<br /> '''Réduction des délais planifiés :'''<br /> *développement de certains composants en parallèle<br /> '''Développement incrémental :'''<br /> *essentiel pour le développement d'un SI par versions successives.<br /> <br /> ==WBS - Work Breakdown Structure - Découpage processus==<br /> <br /> Découpage orienté '''activité.''' Représente la façon de parvenir au résultat tel qu'il est décrit dans le PBS<br /> <br /> Le processus de conduit de projet est décomposé en plusieurs niveaux : '''phases -&gt; étapes -&gt; tâches.'''<br /> <br /> ''Exemple : Processus de développement du système -&gt; Analyse des besoins -&gt; Besoins fonctionnels -&gt; Identification des acteurs, identifications des fonctionnalités.''<br /> <br /> =Typologie de découpages=<br /> <br /> <br /> =Découpage à la MERISE=</div>

Sania https://baripedia.org/index.php?title=Organisation_de_projets&diff=32265 2016-05-16T21:13:01Z

<p>Sania : </p> <hr /> <div>{{Infobox Lecture<br /> | image = <br /> | cours = [[Gestion de projet]]<br /> | faculté = [[Faculté d'économie et de management]]<br /> | département = [[Services généraux GSEM]]<br /> | domaine = [[Système d'information]]<br /> | professeurs = [[Jolita Ralyte]]&lt;ref&gt;[http://cui.unige.ch/~ralyte/ Page personnelle de Jolita Ralyte sur le site du CUI]&lt;/ref&gt;<br /> | années = <br /> | code = S204033 CR &lt;ref&gt;[http://wadme.unige.ch:3149/pls/opprg/w_det_cours.debut?p_code_cours=S204033&amp;p_plan_is=0&amp;p_langue=1&amp;p_frame=N&amp;p_mode=PGC&amp;p_annee=2015&amp;p_suffixe=&amp;p_grtri= Présentation du cours sur le site du catalogue de cours wadme]&lt;/ref&gt;<br /> | enregistrement = <br /> | précédent = <br /> | suivant = [[Découpage de projets]]<br /> }}<br /> <br /> =Deux rôles dans la réalisation d'un projet SI=<br /> <br /> '''Maître d'ouvrage (MOA)''' : l'entité porteuse du besoin, définissant l'objectif du projet, son calendrier et le budget consacré à ce projet.<br /> <br /> ''Le résultat attendu du projet est la réalisation d'un produit, appelé '''ouvrage'''.''<br /> <br /> '''Maître d'oeuvre (MOE)''' : l'entité retenue par le maître d'ouvrage pour réaliser le projet, dans les conditions de délais, de qualité et de coûts fixées par ce dernier conformément à un contrat.<br /> <br /> (Kueviakoe, 2004)<br /> <br /> ==Maîtrise d'ouvrage VS Maîtrise d'oeuvre==<br /> <br /> Compétences métier VS compétences techniques<br /> *Différence du langage -&gt; difficultés de communication<br /> *Différence de connaissances -&gt; difficultés de compréhension<br /> <br /> Situations de projet : <br /> *MOA et MOE appartiennent à la '''même organisation'''<br /> *MOA et MOE sont deux '''organisations différentes''', proches ou distantes géographiquement<br /> *Développement distribué : collaboration de '''plusieurs organisations.'''<br /> <br /> Le service informatique d'une entreprise peut, tour à tour, être :<br /> *le '''maître d'oeuvre''' - le fournisseur - si l'on considère qu'il a à fournir un produit logiciel<br /> *le '''maître d'ouvrage''' - le client - s'il sous-traite tout ou partie du projet à une autre société.<br /> <br /> =Maître d'ouvrage (MOA) : client=<br /> <br /> Le '''maître d'ouvrage (MOA)''' est le '''client''' pour lequel l'ouvrage (le SI) est réalisé.<br /> *Il exprime l'objectif et maîtrise l'idée de base du projet.<br /> *Il est responsable de l'expression fonctionnelle des besoins mais n'a pas forcément les compétences techniques liées à la réalisation de l'ouvrage.<br /> <br /> ==Les responsabilités du MOA==<br /> <br /> La responsabilité du client est totale du début du projet jusqu'à son déploiement. Il doit : <br /> *'''définir et exprimer les besoins''' de SI en réalisant un cahier des charges<br /> *'''valider''' l'adéquation des solutions détaillées, proposées par le maître d'oeuvre, aux besoins exprimés<br /> *'''conduire le changement''' et mettre en oeuvre le produit sur les différents sites<br /> *'''suivre''' le déroulement des travaux<br /> *'''payer''' les travaux commandés et réalisés.<br /> <br /> ==Qui peut réaliser le rôle du MOA ?==<br /> <br /> Une '''équipe interne''' à l'organisation<br /> *les usagers du futur système<br /> *les services informatique/SI de l'entreprise (s'il en existe un).<br /> <br /> Un '''prestataire externe''' à l'entreprise<br /> *maître d'ouvrage délégué, sollicité pour assurer l'interface entre l'utilisateur et le fournisseur<br /> *une assistance à maîtrise d'ouvrage, sollicité pour conseiller le MOA interne à l'organisation.<br /> <br /> ==Équipe client==<br /> <br /> ===Chef de projet côté client (chef MOA)===<br /> <br /> Les responsabilités du MOA : <br /> *diriger l'équipe des usagers sélectionnés pour participer dans le projet<br /> *gérer les ressources du projet : les finances, les ressources humaines, le matériel de l'équipe client<br /> *être en contact permanent avec l'équipe fournisseur.<br /> <br /> Le chef MOA peut être représenté par :<br /> *un membre de la direction de l'entreprise<br /> *un responsable du département informatique interne<br /> *un responsable du SI<br /> *un consultant externe.<br /> <br /> ===Sponsor===<br /> <br /> Le promoteur est une personne haut placée dans l'entreprise (de préférence) qui : <br /> *soutient le projet auprès de la direction de l'entreprise<br /> *prend des décisions stratégiques, politiques et de définition des objectifs<br /> *sélectionne les usagers les plus représentatifs de leur métier à participer dans le projet<br /> *assure que la solution proposée corresponde bien aux besoins de l'entreprise tant au niveau technique que stratégique<br /> *est crédible influent<br /> *dirige officiellement le Comité de Pilotage<br /> *est le recours ultime, quand les arbitrages sont nécessaires entre départements de l'entreprise<br /> <br /> Le sponsor peut être représenté par :<br /> *un membre de la direction de l'entreprise<br /> *un responsable du département informatique interne<br /> *un responsable du SI<br /> *un consultant externe (dans le pire des cas).<br /> <br /> '''Très souvent, le rôle de Sponsor interne n'existe pas dans les entreprises. Il faut le créer!'''<br /> <br /> ===Comité de pilotage===<br /> <br /> Le comité de pilotage :<br /> *est un donneur d'ordre du projet<br /> *prend la décision finale sur la solution proposée par le Sponsor<br /> *assure le suivi du projet<br /> *valide la solution proposée au niveau budgétaire et stratégique.<br /> <br /> ===Usagers représentatifs===<br /> <br /> Les usagers capables d'exprimer les exigences concernant leur métier :<br /> *les employés les plus représentatifs de chaque département de l'entreprise concerné par le projet SI.<br /> <br /> '''Objectifs et responsabilités des usagers : '''<br /> *Transférer à l'équipe de maîtrise d'ouvrage la connaissance sur leur domaine d'activité : <br /> **organisation<br /> **activités métier<br /> **système et règles de gestion<br /> **concepts<br /> **problèmes liés à l'utilisation des anciens systèmes<br /> **exigences pour le nouveau<br /> *Valider la bonne perception de la situation existante et des problèmes qu'elle engendre<br /> *Exprimer les besoins<br /> *Valider le réalisme des solutions globales proposées<br /> *Faire évoluer le produit<br /> <br /> ===Consultants===<br /> <br /> Les consultant externes aident à :<br /> *choisir le maître d'oeuvre ou le fournisseur ERP<br /> *réaliser la spécification des besoins<br /> *valider les solutions proposées par le maître d'oeuvre<br /> *gérer le projet<br /> *etc.<br /> <br /> ==Expression des exigences==<br /> <br /> L'expression des besoins est du ressort du client.<br /> <br /> Étapes d'expression des exigences :<br /> *Identification : établissement et choix d'un objectif global<br /> *Découverte : recueil des besoins auprès des utilisateurs et des dirigeants<br /> *Exploration : affinement et stabilisation des besoins<br /> *Formalisation : mise en forme des exigences, afin qu'elles soient suffisamment précises et compréhensibles par le maître d'oeuvre.<br /> <br /> Les exigences sont spécifiées dans un '''cahier des charges.'''<br /> <br /> ==Cahier des charges==<br /> <br /> C'est un document qui '''fixe les obligations''' réciproques du client et du fournisseur, un '''recueil de caractéristiques''' que doit présenter un produit en cours d'étude ou de réalisation. À partir de ce cahier des charges, un fournisseur doit pouvoir s'engager sur un '''budget''' et sur un '''délai'''. Les besoins sont définis, mais la manière de les satisfaire n'est pas abordée. <br /> <br /> ==Problèmes d'expression des besoins==<br /> <br /> Les problèmes liés à l'expression des besoins peuvent être des sources de litiges entre le client et le fournisseur.<br /> <br /> '''Questions à se poser :'''<br /> *Les besoins formalisés par le client sont-ils exhaustifs ?<br /> *Les besoins exprimés par le client sont-ils compréhensibles par le fournisseur ?<br /> *Le client a-t-il les moyens nécessaires pour valider la solution ?<br /> <br /> '''Solutions :'''<br /> *Utilisation des '''méthodes''' d'analyse et de spécification des besoins<br /> *Adaptation du '''cycle de développement''' du projet aux caractéristiques du domaine<br /> *Adoption d'un '''langage commun''' fondé sur des modèles<br /> *'''Participation''' accrue des deux parties.<br /> <br /> ==Rédaction du cahier des charges==<br /> <br /> '''Structure du document :'''<br /> #Introduction - description générale du projet/futur SI<br /> ##les '''objectifs''' du futur SI<br /> ##le '''périmètre''' du projet : les frontières du domaine d'étude avec d'autres domaines<br /> ##la '''collaboration''' avec d'autres domaines et systèmes existants<br /> ##la '''décomposition''' en sous-domaines (si nécessaire)<br /> ##les '''décideurs''' du projet<br /> ##les '''principes de configuration''' du SI<br /> ##la '''terminologie''' : définitions, acronymes, abréviations<br /> #Description détaillée du futur SI<br /> ##Perspective produit<br /> ###les '''composants''' du SI et les liens entre eux<br /> ###les '''interfaces''' nécessaires avec d'autres systèmes existants<br /> ###le '''modèle conceptuel du domaine''' définissant les principales entités (les concepts du domaine) : entités de gestion, entités de référence produit/service, entités de reporting, etc.<br /> ###les '''cycles de vie''' des entités de gestion (ex. diagramme d'états).<br /> ##Perspective processus<br /> ###les '''processus d'entreprise''' concernés par le futur SI<br /> ###leur '''qualification''' : métier, support, management, etc.<br /> ###leur '''description''' détaillée (ex. BPMN, cas d'utilisations, scénarios, diagrammes de séquence, diagrammes d'activité)<br /> ##Perspective utilisateurs<br /> ###la liste et les définitions des '''rôles'''/utilisateurs type du SI<br /> ###les '''profils''' des utilisateurs (ex. expérience, niveau d'éducation, formation)<br /> ##Contraintes et qualités<br /> ###les contraintes techniques (réseaux, matériel, plateformes et systèmes existants ou imposés)<br /> ###les exigences qualité (performance)<br /> ##Hypothèses et dépendances<br /> ###les facteurs ayant un impact sur les exigences (ex. hypothèse qu'un système opérationnel spécifique va être disponible)<br /> #Description détaillée des exigences spécifiques<br /> ##Interfaces<br /> ##Exigences fonctionnelles<br /> ##Exigences non fonctionnelles<br /> ###performance<br /> ###base de données<br /> ###contraintes de design (standards et normes)<br /> ###propriétés du système logiciel (disponibilité, fiabilité, sécurité, maintenance, portabilité).<br /> ##Autres exigences<br /> #Annexes<br /> <br /> <br /> =Maître d'oeuvre (MOE) : fournisseur=<br /> <br /> Le '''maître d'oeuvre (MOE)''' est le '''fournisseur''' de services qui s'engage à réaliser l'ouvrage (le SI). Il est responsable des choix techniques inhérents à la réalisation de l'ouvrage conformément aux exigences de la maîtrise d'ouvrage, et il a la responsabilité, dans le cadre de sa mission, de désigner une personne physique chargée du bon déroulement du projet - le chef de projet.<br /> <br /> Le fournisseur doit :<br /> *'''concevoir''' et réaliser le SI ou fournir une solution déjà réalisée et adéquate<br /> *'''conseiller''' techniquement le client<br /> *'''assister''' le client lors de la mise en place du produit<br /> *'''informer''' le client de l'avancement des travaux<br /> *'''former''' le futur utilisateur<br /> <br /> Le fournisseur est '''totalement autonome pour les étapes purement techniques''' (étude technique, réalisation, tests d'intégration, etc.).<br /> <br /> ==Les responsabilités du MOE==<br /> <br /> Le MOE doit fournir :<br /> *'''Plan de livraisons'''<br /> Les engagements réciproques entre le client et le fournisseur en termes de produit à livrer et/ou d'information à fournir<br /> *'''Prestations relatives au domaine cible'''<br /> pour lesquelles le client paie réellement : spécifications, études, logiciels, documentation, formation, etc.<br /> *'''Prestations relatives au domaine projet'''<br /> permettant au client d'avoir une visibilité sur l'avancement des travaux : plans, comptes rendus.<br /> <br /> ==Qui peut réaliser le rôle du MOE?==<br /> <br /> Un '''prestataire externe''' à l'entreprise : une société de service en informatique ou un fournisseur ERP<br /> <br /> Le '''service informatique/SI''' ou le '''département R&amp;D''' de l'entreprise<br /> *il doit avoir les '''compétences''' et les '''ressources''' nécessaires<br /> *il peut '''sous-traiter''' à une ou plusieurs entreprises externes la réalisation de certaines tâches du projet, lorsqu'il ne possède pas en interne les ressources nécessaires<br /> *un sous-traitant réalise une partie du projet en communicant directement avec le maître d'oeuvre. Il n'a aucune responsabilité directe avec la maîtrise d'ouvrage.<br /> <br /> ==Équipe fournisseur==<br /> <br /> *'''Chef de projet - chef de projet côté Maître d'oeuvre'''<br /> *'''Chefs des sous-équipes'''<br /> *'''Équipe de production :'''<br /> **analystes<br /> **concepteurs<br /> **administrateurs de données<br /> **développeurs<br /> **testeurs, contrôleurs de qualité<br /> **formateurs<br /> <br /> ==Plan de livraisons==<br /> <br /> *'''La démarche de construction du SI avec découpage en étapes et en phases : '''<br /> **la description du contenu de chaque étape/phase<br /> **les techniques qui vont être utilisées<br /> *'''La description des livrables'''<br /> *'''La validation des livrables :'''<br /> **les processus de validation des livrables intermédiaires et définitifs<br /> **les délais, les acteurs concernés, les méthodes, etc.<br /> *'''La normalisation qui va être appliquée'''<br /> *'''Les exigences concernant le suivi du projet'''<br /> *'''Les dispositions d'assurance qualité'''<br /> <br /> ==Prestations relatives au domaine cible==<br /> <br /> '''Spécifications du système d'information - documents décrivant :'''<br /> *Vue générale du projet<br /> **perception du domaine, description du SI, réponses aux exigences, spécifications techniques et prototypes, etc.<br /> *Vue système d'information - modèles conceptuels : <br /> **informations d'entreprise (modèle conceptuel de données)<br /> **processus d'entreprise (processus métier, règles de gestion, flux d'information)<br /> **procédures (acteurs, rôles, responsabilités, droits, etc.)<br /> *Vue système informatique - modèles techniques :<br /> **données (modèle logique de données), fonctions (procédures et transactions), architecture du système.<br /> *Manuels utilisateur/maintenance<br /> '''Éléments opérationnels - logiciels'''<br /> <br /> ==Les plans du projet==<br /> <br /> '''Plan de développement : '''<br /> *livraison des prestations prévues<br /> *réseau des tâches et leurs échéanciers<br /> *effectifs et budgets détaillés<br /> *ressources du client à impliquer<br /> *ressources du fournisseurs à impliquer<br /> *produits à utiliser en entrée de la production<br /> *infrastructure logique<br /> <br /> '''Plan d'assurance qualité :'''<br /> *ressources nécessaires pour l'établissement du PAQ<br /> *organisation de la gestion de la qualité<br /> *définition des procédures d'assurance qualité<br /> <br /> '''Plan de gestion des configurations :'''<br /> *organisation de la gestion des configurations<br /> *procédures de changement<br /> *type de contrôle des versions<br /> <br /> ==Les comptes rendus de projet==<br /> <br /> '''Sur le développement :'''<br /> *état d'avancement<br /> *effectifs utilisés et coûts<br /> *ressources du client réellement impliquées<br /> *ressources du fournisseur réellement impliquées<br /> *produits réellement utilisés en entrée de la production<br /> *'''déviations''' par rapport au plan de développement<br /> *propositions d''''actions correctives'''<br /> *propositions de modifications du plan de développement<br /> <br /> '''Sur les procédures d'assurance qualité : '''<br /> *ressources utilisées<br /> *procédures d'assurance qualité mises en place<br /> *évaluation de l'assurance qualité<br /> <br /> '''Sur la gestion des configurations :'''<br /> *procédures et outils mis en place<br /> *état de réalisation des configurations<br /> <br /> =Projet de maître d'oeuvre VS projet maître d'ouvrage=<br /> [[Fichier:Projet vu maitre oeuvre.png|cadre|centré|Projet vu par le maître d'oeuvre]]<br /> <br /> Le rôle de chef de projet client est dédoublé en :<br /> *directeur responsable des relations contractuelles avec le client<br /> *manager responsable de l'avancement du travail.<br /> <br /> <br /> [[Fichier:Projet vu maitre ouvrage.png|cadre|centré|Projet vu par le maître d'ouvrage]]<br /> <br /> Le rôle du chef de projet fournisseur se situe en-dessous du sponsor de projet et du comité de pilotage.<br /> <br /> <br /> = Annexes =<br /> <br /> = Références =<br /> &lt;references/&gt;</div>

Sania https://baripedia.org/index.php?title=Fichier:Projet_vu_maitre_ouvrage.png&diff=32264 2016-05-16T21:09:39Z

<p>Sania : Gestion de projet : vu par le maître d'ouvrage</p> <hr /> <div>Gestion de projet : vu par le maître d'ouvrage</div>

Sania https://baripedia.org/index.php?title=Fichier:Projet_vu_maitre_oeuvre.png&diff=32263 2016-05-16T21:07:36Z

<p>Sania : Gestion de projet : vu par le maître d'oeuvre</p> <hr /> <div>Gestion de projet : vu par le maître d'oeuvre</div>

Sania https://baripedia.org/index.php?title=Organisation_de_projets&diff=32262 2016-05-16T17:42:30Z

<p>Sania : </p> <hr /> <div>{{Infobox Lecture<br /> | image = <br /> | cours = [[Gestion de projet]]<br /> | faculté = [[Faculté d'économie et de management]]<br /> | département = [[Services généraux GSEM]]<br /> | domaine = [[Système d'information]]<br /> | professeurs = [[Jolita Ralyte]]&lt;ref&gt;[http://cui.unige.ch/~ralyte/ Page personnelle de Jolita Ralyte sur le site du CUI]&lt;/ref&gt;<br /> | années = <br /> | code = S204033 CR &lt;ref&gt;[http://wadme.unige.ch:3149/pls/opprg/w_det_cours.debut?p_code_cours=S204033&amp;p_plan_is=0&amp;p_langue=1&amp;p_frame=N&amp;p_mode=PGC&amp;p_annee=2015&amp;p_suffixe=&amp;p_grtri= Présentation du cours sur le site du catalogue de cours wadme]&lt;/ref&gt;<br /> | enregistrement = <br /> | précédent = <br /> | suivant = [[Découpage de projets]]<br /> }}<br /> <br /> =Deux rôles dans la réalisation d'un projet SI=<br /> <br /> '''Maître d'ouvrage (MOA)''' : l'entité porteuse du besoin, définissant l'objectif du projet, son calendrier et le budget consacré à ce projet.<br /> <br /> ''Le résultat attendu du projet est la réalisation d'un produit, appelé '''ouvrage'''.''<br /> <br /> '''Maître d'oeuvre (MOE)''' : l'entité retenue par le maître d'ouvrage pour réaliser le projet, dans les conditions de délais, de qualité et de coûts fixées par ce dernier conformément à un contrat.<br /> <br /> (Kueviakoe, 2004)<br /> <br /> ==Maîtrise d'ouvrage VS Maîtrise d'oeuvre==<br /> <br /> Compétences métier VS compétences techniques<br /> *Différence du langage -&gt; difficultés de communication<br /> *Différence de connaissances -&gt; difficultés de compréhension<br /> <br /> Situations de projet : <br /> *MOA et MOE appartiennent à la '''même organisation'''<br /> *MOA et MOE sont deux '''organisations différentes''', proches ou distantes géographiquement<br /> *Développement distribué : collaboration de '''plusieurs organisations.'''<br /> <br /> Le service informatique d'une entreprise peut, tour à tour, être :<br /> *le '''maître d'oeuvre''' - le fournisseur - si l'on considère qu'il a à fournir un produit logiciel<br /> *le '''maître d'ouvrage''' - le client - s'il sous-traite tout ou partie du projet à une autre société.<br /> <br /> =Maître d'ouvrage (MOA) : client=<br /> <br /> Le '''maître d'ouvrage (MOA)''' est le '''client''' pour lequel l'ouvrage (le SI) est réalisé.<br /> *Il exprime l'objectif et maîtrise l'idée de base du projet.<br /> *Il est responsable de l'expression fonctionnelle des besoins mais n'a pas forcément les compétences techniques liées à la réalisation de l'ouvrage.<br /> <br /> ==Les responsabilités du MOA==<br /> <br /> La responsabilité du client est totale du début du projet jusqu'à son déploiement. Il doit : <br /> *'''définir et exprimer les besoins''' de SI en réalisant un cahier des charges<br /> *'''valider''' l'adéquation des solutions détaillées, proposées par le maître d'oeuvre, aux besoins exprimés<br /> *'''conduire le changement''' et mettre en oeuvre le produit sur les différents sites<br /> *'''suivre''' le déroulement des travaux<br /> *'''payer''' les travaux commandés et réalisés.<br /> <br /> ==Qui peut réaliser le rôle du MOA ?==<br /> <br /> Une '''équipe interne''' à l'organisation<br /> *les usagers du futur système<br /> *les services informatique/SI de l'entreprise (s'il en existe un).<br /> <br /> Un '''prestataire externe''' à l'entreprise<br /> *maître d'ouvrage délégué, sollicité pour assurer l'interface entre l'utilisateur et le fournisseur<br /> *une assistance à maîtrise d'ouvrage, sollicité pour conseiller le MOA interne à l'organisation.<br /> <br /> ==Équipe client==<br /> <br /> ===Chef de projet côté client (chef MOA)===<br /> <br /> Les responsabilités du MOA : <br /> *diriger l'équipe des usagers sélectionnés pour participer dans le projet<br /> *gérer les ressources du projet : les finances, les ressources humaines, le matériel de l'équipe client<br /> *être en contact permanent avec l'équipe fournisseur.<br /> <br /> Le chef MOA peut être représenté par :<br /> *un membre de la direction de l'entreprise<br /> *un responsable du département informatique interne<br /> *un responsable du SI<br /> *un consultant externe.<br /> <br /> ===Sponsor===<br /> <br /> Le promoteur est une personne haut placée dans l'entreprise (de préférence) qui : <br /> *soutient le projet auprès de la direction de l'entreprise<br /> *prend des décisions stratégiques, politiques et de définition des objectifs<br /> *sélectionne les usagers les plus représentatifs de leur métier à participer dans le projet<br /> *assure que la solution proposée corresponde bien aux besoins de l'entreprise tant au niveau technique que stratégique<br /> *est crédible influent<br /> *dirige officiellement le Comité de Pilotage<br /> *est le recours ultime, quand les arbitrages sont nécessaires entre départements de l'entreprise<br /> <br /> Le sponsor peut être représenté par :<br /> *un membre de la direction de l'entreprise<br /> *un responsable du département informatique interne<br /> *un responsable du SI<br /> *un consultant externe (dans le pire des cas).<br /> <br /> '''Très souvent, le rôle de Sponsor interne n'existe pas dans les entreprises. Il faut le créer!'''<br /> <br /> ===Comité de pilotage===<br /> <br /> Le comité de pilotage :<br /> *est un donneur d'ordre du projet<br /> *prend la décision finale sur la solution proposée par le Sponsor<br /> *assure le suivi du projet<br /> *valide la solution proposée au niveau budgétaire et stratégique.<br /> <br /> ===Usagers représentatifs===<br /> <br /> Les usagers capables d'exprimer les exigences concernant leur métier :<br /> *les employés les plus représentatifs de chaque département de l'entreprise concerné par le projet SI.<br /> <br /> '''Objectifs et responsabilités des usagers : '''<br /> *Transférer à l'équipe de maîtrise d'ouvrage la connaissance sur leur domaine d'activité : <br /> **organisation<br /> **activités métier<br /> **système et règles de gestion<br /> **concepts<br /> **problèmes liés à l'utilisation des anciens systèmes<br /> **exigences pour le nouveau<br /> *Valider la bonne perception de la situation existante et des problèmes qu'elle engendre<br /> *Exprimer les besoins<br /> *Valider le réalisme des solutions globales proposées<br /> *Faire évoluer le produit<br /> <br /> ===Consultants===<br /> <br /> Les consultant externes aident à :<br /> *choisir le maître d'oeuvre ou le fournisseur ERP<br /> *réaliser la spécification des besoins<br /> *valider les solutions proposées par le maître d'oeuvre<br /> *gérer le projet<br /> *etc.<br /> <br /> ==Expression des exigences==<br /> <br /> L'expression des besoins est du ressort du client.<br /> <br /> Étapes d'expression des exigences :<br /> *Identification : établissement et choix d'un objectif global<br /> *Découverte : recueil des besoins auprès des utilisateurs et des dirigeants<br /> *Exploration : affinement et stabilisation des besoins<br /> *Formalisation : mise en forme des exigences, afin qu'elles soient suffisamment précises et compréhensibles par le maître d'oeuvre.<br /> <br /> Les exigences sont spécifiées dans un '''cahier des charges.'''<br /> <br /> ==Cahier des charges==<br /> <br /> C'est un document qui '''fixe les obligations''' réciproques du client et du fournisseur, un '''recueil de caractéristiques''' que doit présenter un produit en cours d'étude ou de réalisation. À partir de ce cahier des charges, un fournisseur doit pouvoir s'engager sur un '''budget''' et sur un '''délai'''. Les besoins sont définis, mais la manière de les satisfaire n'est pas abordée. <br /> <br /> ==Problèmes d'expression des besoins==<br /> <br /> Les problèmes liés à l'expression des besoins peuvent être des sources de litiges entre le client et le fournisseur.<br /> <br /> '''Questions à se poser :'''<br /> *Les besoins formalisés par le client sont-ils exhaustifs ?<br /> *Les besoins exprimés par le client sont-ils compréhensibles par le fournisseur ?<br /> *Le client a-t-il les moyens nécessaires pour valider la solution ?<br /> <br /> '''Solutions :'''<br /> *Utilisation des '''méthodes''' d'analyse et de spécification des besoins<br /> *Adaptation du '''cycle de développement''' du projet aux caractéristiques du domaine<br /> *Adoption d'un '''langage commun''' fondé sur des modèles<br /> *'''Participation''' accrue des deux parties.<br /> <br /> ==Rédaction du cahier des charges==<br /> <br /> '''Structure du document :'''<br /> #Introduction - description générale du projet/futur SI<br /> ##les '''objectifs''' du futur SI<br /> ##le '''périmètre''' du projet : les frontières du domaine d'étude avec d'autres domaines<br /> ##la '''collaboration''' avec d'autres domaines et systèmes existants<br /> ##la '''décomposition''' en sous-domaines (si nécessaire)<br /> ##les '''décideurs''' du projet<br /> ##les '''principes de configuration''' du SI<br /> ##la '''terminologie''' : définitions, acronymes, abréviations<br /> #Description détaillée du futur SI<br /> ##Perspective produit<br /> ###les '''composants''' du SI et les liens entre eux<br /> ###les '''interfaces''' nécessaires avec d'autres systèmes existants<br /> ###le '''modèle conceptuel du domaine''' définissant les principales entités (les concepts du domaine) : entités de gestion, entités de référence produit/service, entités de reporting, etc.<br /> ###les '''cycles de vie''' des entités de gestion (ex. diagramme d'états).<br /> ##Perspective processus<br /> ###les '''processus d'entreprise''' concernés par le futur SI<br /> ###leur '''qualification''' : métier, support, management, etc.<br /> ###leur '''description''' détaillée (ex. BPMN, cas d'utilisations, scénarios, diagrammes de séquence, diagrammes d'activité)<br /> ##Perspective utilisateurs<br /> ###la liste et les définitions des '''rôles'''/utilisateurs type du SI<br /> ###les '''profils''' des utilisateurs (ex. expérience, niveau d'éducation, formation)<br /> ##Contraintes et qualités<br /> ###les contraintes techniques (réseaux, matériel, plateformes et systèmes existants ou imposés)<br /> ###les exigences qualité (performance)<br /> ##Hypothèses et dépendances<br /> ###les facteurs ayant un impact sur les exigences (ex. hypothèse qu'un système opérationnel spécifique va être disponible)<br /> #Description détaillée des exigences spécifiques<br /> ##Interfaces<br /> ##Exigences fonctionnelles<br /> ##Exigences non fonctionnelles<br /> ###performance<br /> ###base de données<br /> ###contraintes de design (standards et normes)<br /> ###propriétés du système logiciel (disponibilité, fiabilité, sécurité, maintenance, portabilité).<br /> ##Autres exigences<br /> #Annexes<br /> <br /> <br /> =Maître d'oeuvre (MOE) : fournisseur=<br /> <br /> Le '''maître d'oeuvre (MOE)''' est le '''fournisseur''' de services qui s'engage à réaliser l'ouvrage (le SI). Il est responsable des choix techniques inhérents à la réalisation de l'ouvrage conformément aux exigences de la maîtrise d'ouvrage, et il a la responsabilité, dans le cadre de sa mission, de désigner une personne physique chargée du bon déroulement du projet - le chef de projet.<br /> <br /> Le fournisseur doit :<br /> *'''concevoir''' et réaliser le SI ou fournir une solution déjà réalisée et adéquate<br /> *'''conseiller''' techniquement le client<br /> *'''assister''' le client lors de la mise en place du produit<br /> *'''informer''' le client de l'avancement des travaux<br /> *'''former''' le futur utilisateur<br /> <br /> Le fournisseur est '''totalement autonome pour les étapes purement techniques''' (étude technique, réalisation, tests d'intégration, etc.).<br /> <br /> ==Les responsabilités du MOE==<br /> <br /> Le MOE doit fournir :<br /> *'''Plan de livraisons'''<br /> Les engagements réciproques entre le client et le fournisseur en termes de produit à livrer et/ou d'information à fournir<br /> *'''Prestations relatives au domaine cible'''<br /> pour lesquelles le client paie réellement : spécifications, études, logiciels, documentation, formation, etc.<br /> *'''Prestations relatives au domaine projet'''<br /> permettant au client d'avoir une visibilité sur l'avancement des travaux : plans, comptes rendus.<br /> <br /> ==Qui peut réaliser le rôle du MOE?==<br /> <br /> Un '''prestataire externe''' à l'entreprise : une société de service en informatique ou un fournisseur ERP<br /> <br /> Le '''service informatique/SI''' ou le '''département R&amp;D''' de l'entreprise<br /> *il doit avoir les '''compétences''' et les '''ressources''' nécessaires<br /> *il peut '''sous-traiter''' à une ou plusieurs entreprises externes la réalisation de certaines tâches du projet, lorsqu'il ne possède pas en interne les ressources nécessaires<br /> *un sous-traitant réalise une partie du projet en communicant directement avec le maître d'oeuvre. Il n'a aucune responsabilité directe avec la maîtrise d'ouvrage.<br /> <br /> ==Équipe fournisseur==<br /> <br /> *'''Chef de projet - chef de projet côté Maître d'oeuvre'''<br /> *'''Chefs des sous-équipes'''<br /> *'''Équipe de production :'''<br /> **analystes<br /> **concepteurs<br /> **administrateurs de données<br /> **développeurs<br /> **testeurs, contrôleurs de qualité<br /> **formateurs<br /> <br /> ==Plan de livraisons==<br /> <br /> *'''La démarche de construction du SI avec découpage en étapes et en phases : '''<br /> **la description du contenu de chaque étape/phase<br /> **les techniques qui vont être utilisées<br /> *'''La description des livrables'''<br /> *'''La validation des livrables :'''<br /> **les processus de validation des livrables intermédiaires et définitifs<br /> **les délais, les acteurs concernés, les méthodes, etc.<br /> *'''La normalisation qui va être appliquée'''<br /> *'''Les exigences concernant le suivi du projet'''<br /> *'''Les dispositions d'assurance qualité'''<br /> <br /> ==Prestations relatives au domaine cible<br /> <br /> '''Spécifications du système d'information - documents décrivant :'''<br /> *Vue générale du projet<br /> **perception du domaine, description du SI, réponses aux exigences, spécifications techniques et prototypes, etc.<br /> <br /> <br /> =Projet de maître d'oeuvre VS projet maître d'ouvrage=<br /> <br /> = Annexes =<br /> <br /> = Références =<br /> &lt;references/&gt;</div>

Sania https://baripedia.org/index.php?title=Organisation_de_projets&diff=32261 2016-05-16T16:14:19Z

<p>Sania : </p> <hr /> <div>{{Infobox Lecture<br /> | image = <br /> | cours = [[Gestion de projet]]<br /> | faculté = [[Faculté d'économie et de management]]<br /> | département = [[Services généraux GSEM]]<br /> | domaine = [[Système d'information]]<br /> | professeurs = [[Jolita Ralyte]]&lt;ref&gt;[http://cui.unige.ch/~ralyte/ Page personnelle de Jolita Ralyte sur le site du CUI]&lt;/ref&gt;<br /> | années = <br /> | code = S204033 CR &lt;ref&gt;[http://wadme.unige.ch:3149/pls/opprg/w_det_cours.debut?p_code_cours=S204033&amp;p_plan_is=0&amp;p_langue=1&amp;p_frame=N&amp;p_mode=PGC&amp;p_annee=2015&amp;p_suffixe=&amp;p_grtri= Présentation du cours sur le site du catalogue de cours wadme]&lt;/ref&gt;<br /> | enregistrement = <br /> | précédent = <br /> | suivant = [[Découpage de projets]]<br /> }}<br /> <br /> =Deux rôles dans la réalisation d'un projet SI=<br /> <br /> '''Maître d'ouvrage (MOA)''' : l'entité porteuse du besoin, définissant l'objectif du projet, son calendrier et le budget consacré à ce projet.<br /> <br /> ''Le résultat attendu du projet est la réalisation d'un produit, appelé '''ouvrage'''.''<br /> <br /> '''Maître d'oeuvre (MOE)''' : l'entité retenue par le maître d'ouvrage pour réaliser le projet, dans les conditions de délais, de qualité et de coûts fixées par ce dernier conformément à un contrat.<br /> <br /> (Kueviakoe, 2004)<br /> <br /> ==Maîtrise d'ouvrage VS Maîtrise d'oeuvre==<br /> <br /> Compétences métier VS compétences techniques<br /> *Différence du langage -&gt; difficultés de communication<br /> *Différence de connaissances -&gt; difficultés de compréhension<br /> <br /> Situations de projet : <br /> *MOA et MOE appartiennent à la '''même organisation'''<br /> *MOA et MOE sont deux '''organisations différentes''', proches ou distantes géographiquement<br /> *Développement distribué : collaboration de '''plusieurs organisations.'''<br /> <br /> <br /> =Maître d'ouvrage (MOA) : client=<br /> <br /> Le '''maître d'ouvrage (MOA)''' est le '''client''' pour lequel l'ouvrage (le SI) est réalisé.<br /> *Il exprime l'objectif et maîtrise l'idée de base du projet.<br /> *Il est responsable de l'expression fonctionnelle des besoins mais n'a pas forcément les compétences techniques liées à la réalisation de l'ouvrage.<br /> <br /> ==Les responsabilités du MOA==<br /> <br /> La responsabilité du client est totale du début du projet jusqu'à son déploiement. Il doit : <br /> *'''définir et exprimer les besoins''' de SI en réalisant un cahier des charges<br /> *'''valider''' l'adéquation des solutions détaillées, proposées par le maître d'oeuvre, aux besoins exprimés<br /> *'''conduire le changement''' et mettre en oeuvre le produit sur les différents sites<br /> *'''suivre''' le déroulement des travaux<br /> *'''payer''' les travaux commandés et réalisés.<br /> <br /> ==Qui peut réaliser le rôle du MOA ?==<br /> <br /> Une '''équipe interne''' à l'organisation<br /> *les usagers du futur système<br /> *les services informatique/SI de l'entreprise (s'il en existe un).<br /> <br /> Un '''prestataire externe''' à l'entreprise<br /> *maître d'ouvrage délégué, sollicité pour assurer l'interface entre l'utilisateur et le fournisseur<br /> *une assistance à maîtrise d'ouvrage, sollicité pour conseiller le MOA interne à l'organisation.<br /> <br /> ==Équipe client==<br /> <br /> ===Chef de projet côté client (chef MOA)===<br /> <br /> Les responsabilités du MOA : <br /> *diriger l'équipe des usagers sélectionnés pour participer dans le projet<br /> *gérer les ressources du projet : les finances, les ressources humaines, le matériel de l'équipe client<br /> *être en contact permanent avec l'équipe fournisseur.<br /> <br /> Le chef MOA peut être représenté par :<br /> *un membre de la direction de l'entreprise<br /> *un responsable du département informatique interne<br /> *un responsable du SI<br /> *un consultant externe.<br /> <br /> ===Sponsor===<br /> <br /> Le promoteur est une personne haut placée dans l'entreprise (de préférence) qui : <br /> *soutient le projet auprès de la direction de l'entreprise<br /> *prend des décisions stratégiques, politiques et de définition des objectifs<br /> *sélectionne les usagers les plus représentatifs de leur métier à participer dans le projet<br /> *assure que la solution proposée corresponde bien aux besoins de l'entreprise tant au niveau technique que stratégique<br /> *est crédible influent<br /> *dirige officiellement le Comité de Pilotage<br /> *est le recours ultime, quand les arbitrages sont nécessaires entre départements de l'entreprise<br /> <br /> Le sponsor peut être représenté par :<br /> *un membre de la direction de l'entreprise<br /> *un responsable du département informatique interne<br /> *un responsable du SI<br /> *un consultant externe (dans le pire des cas).<br /> <br /> '''Très souvent, le rôle de Sponsor interne n'existe pas dans les entreprises. Il faut le créer!'''<br /> <br /> ===Comité de pilotage===<br /> <br /> Le comité de pilotage :<br /> *est un donneur d'ordre du projet<br /> *prend la décision finale sur la solution proposée par le Sponsor<br /> *assure le suivi du projet<br /> *valide la solution proposée au niveau budgétaire et stratégique.<br /> <br /> ===Usagers représentatifs===<br /> <br /> Les usagers capables d'exprimer les exigences concernant leur métier :<br /> *les employés les plus représentatifs de chaque département de l'entreprise concerné par le projet SI.<br /> <br /> '''Objectifs et responsabilités des usagers : '''<br /> *Transférer à l'équipe de maîtrise d'ouvrage la connaissance sur leur domaine d'activité : <br /> **organisation<br /> **activités métier<br /> **système et règles de gestion<br /> **concepts<br /> **problèmes liés à l'utilisation des anciens systèmes<br /> **exigences pour le nouveau<br /> *Valider la bonne perception de la situation existante et des problèmes qu'elle engendre<br /> *Exprimer les besoins<br /> *Valider le réalisme des solutions globales proposées<br /> *Faire évoluer le produit<br /> <br /> ===Consultants===<br /> <br /> Les consultant externes aident à :<br /> *choisir le maître d'oeuvre ou le fournisseur ERP<br /> *réaliser la spécification des besoins<br /> *valider les solutions proposées par le maître d'oeuvre<br /> *gérer le projet<br /> *etc.<br /> <br /> ==Expression des exigences==<br /> <br /> L'expression des besoins est du ressort du client.<br /> <br /> Étapes d'expression des exigences :<br /> *Identification : établissement et choix d'un objectif global<br /> *Découverte : recueil des besoins auprès des utilisateurs et des dirigeants<br /> *Exploration : affinement et stabilisation des besoins<br /> *Formalisation : mise en forme des exigences, afin qu'elles soient suffisamment précises et compréhensibles par le maître d'oeuvre.<br /> <br /> Les exigences sont spécifiées dans un '''cahier des charges.'''<br /> <br /> ==Cahier des charges==<br /> <br /> C'est un document qui '''fixe les obligations''' réciproques du client et du fournisseur, un '''recueil de caractéristiques''' que doit présenter un produit en cours d'étude ou de réalisation. À partir de ce cahier des charges, un fournisseur doit pouvoir s'engager sur un '''budget''' et sur un '''délai'''. Les besoins sont définis, mais la manière de les satisfaire n'est pas abordée. <br /> <br /> ==Problèmes d'expression des besoins==<br /> <br /> Les problèmes liés à l'expression des besoins peuvent être des sources de litiges entre le client et le fournisseur.<br /> <br /> '''Questions à se poser :'''<br /> *Les besoins formalisés par le client sont-ils exhaustifs ?<br /> *Les besoins exprimés par le client sont-ils compréhensibles par le fournisseur ?<br /> *Le client a-t-il les moyens nécessaires pour valider la solution ?<br /> <br /> '''Solutions :'''<br /> *Utilisation des '''méthodes''' d'analyse et de spécification des besoins<br /> *Adaptation du '''cycle de développement''' du projet aux caractéristiques du domaine<br /> *Adoption d'un '''langage commun''' fondé sur des modèles<br /> *'''Participation''' accrue des deux parties.<br /> <br /> ==Rédaction du cahier des charges==<br /> <br /> '''Structure du document :'''<br /> #Introduction - description générale du projet/futur SI<br /> ##les '''objectifs''' du futur SI<br /> ##le '''périmètre''' du projet : les frontières du domaine d'étude avec d'autres domaines<br /> ##la '''collaboration''' avec d'autres domaines et systèmes existants<br /> ##la '''décomposition''' en sous-domaines (si nécessaire)<br /> ##les '''décideurs''' du projet<br /> ##les '''principes de configuration''' du SI<br /> ##la '''terminologie''' : définitions, acronymes, abréviations<br /> #Description détaillée du futur SI<br /> ##Perspective produit<br /> ###les '''composants''' du SI et les liens entre eux<br /> ###les '''interfaces''' nécessaires avec d'autres systèmes existants<br /> ###le '''modèle conceptuel du domaine''' définissant les principales entités (les concepts du domaine) : entités de gestion, entités de référence produit/service, entités de reporting, etc.<br /> ###les '''cycles de vie''' des entités de gestion (ex. diagramme d'états).<br /> ##Perspective processus<br /> ###les '''processus d'entreprise''' concernés par le futur SI<br /> ###leur '''qualification''' : métier, support, management, etc.<br /> ###leur '''description''' détaillée (ex. BPMN, cas d'utilisations, scénarios, diagrammes de séquence, diagrammes d'activité)<br /> ##Perspective utilisateurs<br /> ###la liste et les définitions des '''rôles'''/utilisateurs type du SI<br /> ###les '''profils''' des utilisateurs (ex. expérience, niveau d'éducation, formation)<br /> ##Contraintes et qualités<br /> ###les contraintes techniques (réseaux, matériel, plateformes et systèmes existants ou imposés)<br /> ###les exigences qualité (performance)<br /> ##Hypothèses et dépendances<br /> ###les facteurs ayant un impact sur les exigences (ex. hypothèse qu'un système opérationnel spécifique va être disponible)<br /> #Description détaillée des exigences spécifiques<br /> ##Interfaces<br /> ##Exigences fonctionnelles<br /> ##Exigences non fonctionnelles<br /> ###performance<br /> ###base de données<br /> ###contraintes de design (standards et normes)<br /> ###propriétés du système logiciel (disponibilité, fiabilité, sécurité, maintenance, portabilité).<br /> ##Autres exigences<br /> #Annexes<br /> <br /> <br /> =Maître d'oeuvre (MOE) : fournisseur=<br /> <br /> <br /> =Projet de maître d'oeuvre VS projet maître d'ouvrage=<br /> <br /> = Annexes =<br /> <br /> = Références =<br /> &lt;references/&gt;</div>

Sania https://baripedia.org/index.php?title=Organisation_de_projets&diff=32260 2016-05-16T15:01:10Z

<p>Sania : </p> <hr /> <div>{{Infobox Lecture<br /> | image = <br /> | cours = [[Gestion de projet]]<br /> | faculté = [[Faculté d'économie et de management]]<br /> | département = [[Services généraux GSEM]]<br /> | domaine = [[Système d'information]]<br /> | professeurs = [[Jolita Ralyte]]&lt;ref&gt;[http://cui.unige.ch/~ralyte/ Page personnelle de Jolita Ralyte sur le site du CUI]&lt;/ref&gt;<br /> | années = <br /> | code = S204033 CR &lt;ref&gt;[http://wadme.unige.ch:3149/pls/opprg/w_det_cours.debut?p_code_cours=S204033&amp;p_plan_is=0&amp;p_langue=1&amp;p_frame=N&amp;p_mode=PGC&amp;p_annee=2015&amp;p_suffixe=&amp;p_grtri= Présentation du cours sur le site du catalogue de cours wadme]&lt;/ref&gt;<br /> | enregistrement = <br /> | précédent = <br /> | suivant = [[Découpage de projets]]<br /> }}<br /> <br /> =Deux rôles dans la réalisation d'un projet SI=<br /> <br /> '''Maître d'ouvrage (MOA)''' : l'entité porteuse du besoin, définissant l'objectif du projet, son calendrier et le budget consacré à ce projet.<br /> <br /> ''Le résultat attendu du projet est la réalisation d'un produit, appelé '''ouvrage'''.''<br /> <br /> '''Maître d'oeuvre (MOE)''' : l'entité retenue par le maître d'ouvrage pour réaliser le projet, dans les conditions de délais, de qualité et de coûts fixées par ce dernier conformément à un contrat.<br /> <br /> (Kueviakoe, 2004)<br /> <br /> <br /> ==Maîtrise d'ouvrage VS Maîtrise d'oeuvre==<br /> <br /> Compétences métier VS compétences techniques<br /> *Différence du langage -&gt; difficultés de communication<br /> *Différence de connaissances -&gt; difficultés de compréhension<br /> <br /> Situations de projet : <br /> *MOA et MOE appartiennent à la '''même organisation'''<br /> *MOA et MOE sont deux '''organisations différentes''', proches ou distantes géographiquement<br /> *Développement distribué : collaboration de '''plusieurs organisations.'''<br /> <br /> =Maître d'ouvrage (MOA) : client=<br /> <br /> Le '''maître d'ouvrage (MOA)''' est le '''client''' pour lequel l'ouvrage (le SI) est réalisé.<br /> *Il exprime l'objectif et maîtrise l'idée de base du projet.<br /> *Il est responsable de l'expression fonctionnelle des besoins mais n'a pas forcément les compétences techniques liées à la réalisation de l'ouvrage.<br /> <br /> ==Les responsabilités du MOA==<br /> <br /> La responsabilité du client est totale du début du projet jusqu'à son déploiement. Il doit : <br /> *'''définir et exprimer les besoins''' de SI en réalisant un cahier des charges<br /> *'''valider''' l'adéquation des solutions détaillées, proposées par le maître d'oeuvre, aux besoins exprimés<br /> *'''conduire le changement''' et mettre en oeuvre le produit sur les différents sites<br /> *'''suivre''' le déroulement des travaux<br /> *'''payer''' les travaux commandés et réalisés.<br /> <br /> ==Qui peut réaliser le rôle du MOA ?==<br /> <br /> Une '''équipe interne''' à l'organisation<br /> *les usagers du futur système<br /> *les services informatique/SI de l'entreprise (s'il en existe un).<br /> <br /> Un '''prestataire externe''' à l'entreprise<br /> *maître d'ouvrage délégué, sollicité pour assurer l'interface entre l'utilisateur et le fournisseur<br /> *une assistance à maîtrise d'ouvrage, sollicité pour conseiller le MOA interne à l'organisation.<br /> <br /> ==Équipe client==<br /> <br /> ===Chef de projet côté client (chef MOA)===<br /> <br /> Les responsabilités du MOA : <br /> *diriger l'équipe des usagers sélectionnés pour participer dans le projet<br /> *gérer les ressources du projet : les finances, les ressources humaines, le matériel de l'équipe client<br /> *être en contact permanent avec l'équipe fournisseur.<br /> <br /> Le chef MOA peut être représenté par :<br /> *un membre de la direction de l'entreprise<br /> *un responsable du département informatique interne<br /> *un responsable du SI<br /> *un consultant externe.<br /> <br /> ===Sponsor===<br /> <br /> Le promoteur est une personne haut placée dans l'entreprise (de préférence) qui : <br /> *soutient le projet auprès de la direction de l'entreprise<br /> *prend des décisions stratégiques, politiques et de définition des objectifs<br /> *sélectionne les usagers les plus représentatifs de leur métier à participer dans le projet<br /> *assure que la solution proposée corresponde bien aux besoins de l'entreprise tant au niveau technique que stratégique<br /> *est crédible influent<br /> *dirige officiellement le Comité de Pilotage<br /> *est le recours ultime, quand les arbitrages sont nécessaires entre départements de l'entreprise<br /> <br /> Le sponsor peut être représenté par :<br /> *un membre de la direction de l'entreprise<br /> *un responsable du département informatique interne<br /> *un responsable du SI<br /> *un consultant externe (dans le pire des cas).<br /> <br /> '''Très souvent, le rôle de Sponsor interne n'existe pas dans les entreprises. Il faut le créer!'''<br /> <br /> ===Comité de pilotage===<br /> <br /> Le comité de pilotage :<br /> *est un donneur d'ordre du projet<br /> *prend la décision finale sur la solution proposée par le Sponsor<br /> *assure le suivi du projet<br /> *valide la solution proposée au niveau budgétaire et stratégique.<br /> <br /> ===Usagers représentatifs===<br /> <br /> Les usagers capables d'exprimer les exigences concernant leur métier :<br /> *les employés les plus représentatifs de chaque département de l'entreprise concerné par le projet SI.<br /> <br /> ===Consultants===<br /> <br /> Les consultant externes aident à :<br /> *choisir le maître d'oeuvre ou le fournisseur ERP<br /> *réaliser la spécification des besoins<br /> *valider les solutions proposées par le maître d'oeuvre<br /> *gérer le projet<br /> *etc.<br /> <br /> <br /> =Maître d'oeuvre (MOE) : fournisseur=<br /> <br /> <br /> =Projet de maître d'oeuvre VS projet maître d'ouvrage=<br /> <br /> = Annexes =<br /> <br /> = Références =<br /> &lt;references/&gt;</div>

Sania https://baripedia.org/index.php?title=Organisation_de_projets&diff=32258 2016-05-16T13:12:45Z

<p>Sania : Page créée avec « {{Infobox Lecture | image = | cours = Gestion de projet | faculté = Faculté d'économie et de management | département = Services généraux GSEM | do... »</p> <hr /> <div>{{Infobox Lecture<br /> | image = <br /> | cours = [[Gestion de projet]]<br /> | faculté = [[Faculté d'économie et de management]]<br /> | département = [[Services généraux GSEM]]<br /> | domaine = [[Système d'information]]<br /> | professeurs = [[Jolita Ralyte]]&lt;ref&gt;[http://cui.unige.ch/~ralyte/ Page personnelle de Jolita Ralyte sur le site du CUI]&lt;/ref&gt;<br /> | années = <br /> | code = S204033 CR &lt;ref&gt;[http://wadme.unige.ch:3149/pls/opprg/w_det_cours.debut?p_code_cours=S204033&amp;p_plan_is=0&amp;p_langue=1&amp;p_frame=N&amp;p_mode=PGC&amp;p_annee=2015&amp;p_suffixe=&amp;p_grtri= Présentation du cours sur le site du catalogue de cours wadme]&lt;/ref&gt;<br /> | enregistrement = <br /> | précédent = <br /> | suivant = [[Découpage de projets]]<br /> }}<br /> <br /> =Deux rôles dans la réalisation d'un projet SI=<br /> <br /> '''Maître d'ouvrage (MOA)''' : l'entité porteuse du besoin, définissant l'objectif du projet, son calendrier et le budget consacré à ce projet.<br /> <br /> ''Le résultat attendu du projet est la réalisation d'un produit, appelé '''ouvrage'''.''<br /> <br /> '''Maître d'oeuvre (MOE)''' : l'entité retenue par le maître d'ouvrage pour réaliser le projet, dans les conditions de délais, de qualité et de coûts fixées par ce dernier conformément à un contrat.<br /> <br /> (Kueviakoe, 2004)<br /> <br /> <br /> ==Maîtrise d'ouvrage VS Maîtrise d'oeuvre==<br /> <br /> Compétences métier VS compétences techniques<br /> *Différence du langage -&gt; difficultés de communication<br /> *Différence de connaissances -&gt; difficultés de compréhension<br /> <br /> Situations de projet : <br /> *MOA et MOE appartiennent à la '''même organisation'''<br /> *MOA et MOE sont deux '''organisations différentes''', proches ou distantes géographiquement<br /> *Développement distribué : collaboration de '''plusieurs organisations.'''<br /> <br /> =Maître d'ouvrage (MOA) : client=<br /> <br /> Le '''maître d'ouvrage (MOA)''' est le '''client''' pour lequel l'ouvrage (le SI) est réalisé.<br /> *Il exprime l'objectif et maîtrise l'idée de base du projet.<br /> *Il est responsable de l'expression fonctionnelle des besoins mais n'a pas forcément les compétences techniques liées à la réalisation de l'ouvrage.<br /> <br /> ==Les responsabilités du MOA==<br /> <br /> La responsabilité du client est totale du début du projet jusqu'à son déploiement. Il doit : <br /> *'''définir et exprimer les besoins''' de SI en réalisant un cahier des charges<br /> *'''valider''' l'adéquation des solutions détaillées, proposées par le maître d'oeuvre, aux besoins exprimés<br /> *'''conduire le changement''' et mettre en oeuvre le produit sur les différents sites<br /> *'''suivre''' le déroulement des travaux<br /> *'''payer''' les travaux commandés et réalisés.<br /> <br /> ==Qui peut réaliser le rôle du MOA ?==<br /> <br /> Une '''équipe interne''' à l'organisation<br /> *les usagers du futur système<br /> *les services informatique/SI de l'entreprise (s'il en existe un).<br /> <br /> Un '''prestataire externe''' à l'entreprise<br /> *maître d'ouvrage délégué, sollicité pour assurer l'interface entre l'utilisateur et le fournisseur<br /> *une assistance à maîtrise d'ouvrage, sollicité pour conseiller le MOA interne à l'organisation.<br /> <br /> =Maître d'oeuvre (MOE) : fournisseur=<br /> <br /> <br /> =Projet de maître d'oeuvre VS projet maître d'ouvrage=</div>

Sania https://baripedia.org/index.php?title=Activit%C3%A9s_et_caract%C3%A9ristiques_de_la_gestion_de_projets_SI&diff=32257 2016-05-16T12:58:03Z

<p>Sania : </p> <hr /> <div>{{Infobox Lecture<br /> | image = <br /> | cours = [[Gestion de projet]]<br /> | faculté = [[Faculté d'économie et de management]]<br /> | département = [[Services généraux GSEM]]<br /> | domaine = [[Système d'information]]<br /> | professeurs = [[Jolita Ralyte]]&lt;ref&gt;[http://cui.unige.ch/~ralyte/ Page personnelle de Jolita Ralyte sur le site du CUI]&lt;/ref&gt;<br /> | années = <br /> | code = S204033 CR &lt;ref&gt;[http://wadme.unige.ch:3149/pls/opprg/w_det_cours.debut?p_code_cours=S204033&amp;p_plan_is=0&amp;p_langue=1&amp;p_frame=N&amp;p_mode=PGC&amp;p_annee=2015&amp;p_suffixe=&amp;p_grtri= Présentation du cours sur le site du catalogue de cours wadme]&lt;/ref&gt;<br /> | enregistrement = <br /> | précédent = <br /> | suivant = [[Organisation de projets]]<br /> }}<br /> <br /> =Définition d'un projet SI=<br /> [[Fichier:Schema triangle projet.png|cadre|droite|Double-triangle d'un projet]]<br /> <br /> Un projet est une '''image''' plus ou moins précise d'un '''futur''' que l'on pense atteindre.<br /> <br /> ''Un projet correspond à la situation dans laquelle on se trouve quand on doit atteindre un '''objectif''' avec des '''moyens''' ad hoc et dans un '''délai''' donné'' (Morley, 1999).<br /> <br /> ''Un projet SI est une organisation humaine temporaire permettant de mener à bien une adaptation, c'est-à-dire toute forme de modification, amélioration, automatisation, etc. du système d'information, ce qui inclut développement, maintenance, conception, rétro-conception, installation, etc.'' (Eurométhode).<br /> <br /> *'''Objectif''' : le lancement d'un projet relève d'une décision<br /> *'''Délai''' : tout projet est temporaire. Par nature, il est destiné à s'achever à un horizon visible<br /> *'''Moyens''' : le budget affecté au projet, les ressources humaines, le matériel<br /> *'''Gestion de la production''' : suivre et diriger l'avancement vers l'objectif, assurer la qualité du résultat attendu<br /> *'''Gestion du temps''' : définir le parcours et le jalonner, établir les calendriers, maîtriser la consommation du temps<br /> *'''Gestion des ressources''' : transformer le budget affecté au projet en travail, locaux, matériel, déplacements, etc.<br /> <br /> =Activités de la gestion des projets=<br /> [[Fichier:Activites gestion projet.png|cadre|centré|Activités dans la gestion d'un projet]]<br /> <br /> *'''Analyser''' : déterminer le chemin à emprunter pour avance vers l'objectif. Faisabilité, risques, type de développement, charge.<br /> *'''Organiser''' : organiser le travail pour atteindre l'objectif. Ordonnancement des tâches, création des équipes, planification.<br /> *'''Piloter''' : suivre l'avancement du projet en quantité et en qualité. Analyse des écarts, gestion de changement, gestion des conflits. <br /> *'''Terminer''' : clôturer le projet. Décision, finances, documentation, redistribution des ressources, célébration.<br /> <br /> Le projet se gère du début à la fin.<br /> <br /> =Caractéristiques des projets SI=<br /> [[Fichier:Interactions projet SI.png|vignette|droite|Interactions entre les caractéristiques des projets SI]]<br /> <br /> Il y a une interaction constante entre '''l'objectif''' d'une part et les '''moyens/délais''' d'autre part.<br /> <br /> Une première identification de l'objectif conduit à estimer la charge globale du projet : une échéance cible théorique et des moyens à affecter. '''Design-to-cost''' : si certaines contraintes obligent à limite le délai ou le budget, on ajuste l'objectif.<br /> <br /> L'objectif du projet n'est parfaitement défini qu'à l'achèvement de celui-ci.<br /> <br /> *Un SI est un produit ayant des caractéristiques très spécifiques :<br /> **il est immatériel<br /> **il est reproductible<br /> **il nécessite une maintenance<br /> **il a besoin d'évoluer<br /> **il possède une dimension subjective.<br /> *Il n'est pas possible de donner une représentation visuelle d'un SI :<br /> **il est décrit par ses fonctions. La description n'est jamais exhaustive, et les modèles n'en donnent qu'une vue très partielle. <br /> <br /> ==Organisation==<br /> [[Fichier:Projet SI organisation.png|vignette|Organisation d'un projet SI]]<br /> <br /> Le développement d'un SI se déroule dans une '''organisation''', dont les particularités font partie de la caractérisation du projet lui-même. <br /> <br /> *'''Taille''' (objectif-budget-durée)<br /> **Quelle partie de l'organisation est concernée par le projet ?<br /> **Le nombre de décideurs<br /> **Le nombre d'utilisateurs<br /> *'''Nature de l'organisation'''<br /> **Industrielle, artistique, sportive, humanitaire,...<br /> *'''Collectif ou individuel'''<br /> **Projet '''inter-organisations''' (B2B, B2C, plateforme collaborative, réseau)<br /> **Projet '''intra-organisation'''<br /> *'''Gestion du changement'''<br /> **Raisons : survie économique, réorganisation structurelle, changement de stratégie d'entreprise, législation, etc.<br /> **Type de changement - radical vs incrémental<br /> **Résistance au changement<br /> *'''Degré d'innovation'''<br /> **'''Innovation technologique''' : mise en oeuvre de nouveaux concepts, nouvelles technologies, nouvelles méthodes, ...<br /> **'''Innovation métier''' : nouveaux processus métier, nouvelles responsabilités, nouveaux produits,...<br /> *'''Ouvert ou fermé'''<br /> **Choix de méthodes, de concepts, de technologies, ...<br /> **Contraintes de développement très précises<br /> *'''Objectif unitaire ou réutilisation'''<br /> **Produit destiné à une seule organisation<br /> **Produit destiné à plusieurs organisations et/ou à être fabriqué en série<br /> *'''Projet principal ou sous-projet'''<br /> <br /> La '''culture organisationnelle''' détermine le contexte dans lequel le projet SI doit se dérouler.<br /> <br /> Deux points de vue : <br /> *Centralisation vs Formalité<br /> *Sociabilité vs Solidarité<br /> <br /> Les deux classifications peuvent être également appliquées pour caractériser l'équipe du projet<br /> <br /> ==Centralisation vs Formalité==<br /> [[Fichier:Cultures organisationnelles harrison handy.png|cadre|centré|Classification des cultures organisationnelles. Modèle de Harrison &amp; Handy]]<br /> <br /> ===Culture de Pouvoir Autocratique===<br /> <br /> '''Culture informelle et centralisée.'''<br /> *La direction doit approuver toute décision<br /> *Il est important de trouver un sponsor du projet<br /> *Risque de mauvaise participation de la part des futurs utilisateurs.<br /> <br /> ''Exemple : entreprise privée avec un propriétaire unique ou une grande entreprise où chaque département a un leader.''<br /> <br /> ===Culture Bureaucratique===<br /> <br /> '''Culture formelle et centralisée.'''<br /> *Tous les rôles et les relations entre les rôles sont clairement définis.<br /> *'''À utiliser''' : un système formel pour les questions financières et les décisions les plus importantes.<br /> *'''À identifier''' : les contacts clé pour obtenir l'information plus rapidement qu'à travers les canaux formels.<br /> <br /> ''Exemple : secteur publique, institutions financières.''<br /> <br /> ===Culture de la Distribution des Tâches===<br /> <br /> '''Culture formelle et déléguée.'''<br /> *Organisation en équipes, délégation des tâches au niveau pratique mais dans un cadre formel pour la prise de décisions.<br /> *La plus facile des cultures pour la gestion des projets.<br /> *'''À éviter''' : une participation trop active de la part des futurs utilisateurs.<br /> <br /> ''Exemple : entreprises de construction.''<br /> <br /> ===Culture d'Anarchie Individualiste===<br /> <br /> '''Culture informelle et déléguée.'''<br /> *Chacun a une opinion qui doit être attendue et respectée.<br /> *'''À utiliser''' : des outils formels de planification, organisation et spécification du projet.<br /> *'''À gagner''' : le respect des parties prenantes en tant que professionnel en gestion de projet.<br /> <br /> ''Exemple : organisations professionnelles (cabinet d'avocats, studio de design).<br /> <br /> ==Sociabilité vs Solidarité==<br /> [[Fichier:Sociabilite vs solidarite.png|cadre|centré|Classification des cultures organisationnelles, Sociabilité vs Solidarité. Modèle de Goffee &amp; Jones]]<br /> <br /> ===Culture réseau===<br /> <br /> '''Focus sociabilité.'''<br /> *Confiance, tolérance et ouverture d'esprit.<br /> *Encouragement du développement personnel.<br /> *Complexité et incertitude sont bien supportées.<br /> *Mauvaise performance tolérée.<br /> *Focus sur le processus et la discussion plutôt que sur le résultat.<br /> <br /> ===Culture mercenaire===<br /> <br /> '''Focus solidarité.'''<br /> *Fort consensus sur la cible et les objectifs.<br /> *Focus sur le travail à réaliser.<br /> *Socialisation seulement pour parler travail.<br /> *Pas de repos ni de sympathie.<br /> *Mauvaise performance non tolérée.<br /> *Pas d'entre-aide entre les collègues.<br /> *Planification court-terme.<br /> <br /> ===Culture fragmentée===<br /> <br /> '''Ni sociabilité ni solidarité.'''<br /> *Chaque personne travaille pour elle-même plutôt que pour l'organisation.<br /> *Objectif : performance et résultats.<br /> *Beaucoup de liberté personnelle, pas de rappel des objectifs d'entreprise.<br /> *Pas d'entre-aide ni sympathie entre collègues.<br /> <br /> ===Culture communautaire===<br /> <br /> '''Sociabilité et solidarité.'''<br /> *Responsabilité élevée envers les collègues.<br /> *Amitié, énergie commune pour atteindre les objectifs.<br /> *Travail en équipe.<br /> *Il faut croire à la communauté et l'objectif commun.<br /> <br /> =Types de développement des SI=<br /> <br /> *Développement sur mesure.<br /> *Développement à base des COTS (Component Off The Shelf) et des systèmes ERP.<br /> *Développement par les futurs utilisateurs.<br /> *Développement mixte<br /> <br /> ==Développement sur mesure==<br /> <br /> Le SI est développé &quot;from scratch&quot; par des professionnels des sI en fonction des besoins d'utilisateur.<br /> <br /> Les propriétés :<br /> <br /> *'''Coût''' : le type de développement le plus cher.<br /> *'''Temps''' : le développement est très long et peut durer des mois et même des années.<br /> *'''Erreurs''' : le risque d'erreurs de programmation ou de conception est important.<br /> *'''Besoins''' : le SI résultat correspond parfaitement aux besoins d'utilisateurs.<br /> <br /> ==Développement à base des COTS / ERP==<br /> <br /> Sélection, Achat, Adaptation, Intégration des COTS (Composants logiciels) et/ou des systèmes ERP.<br /> <br /> *'''COTS''' : composant logiciel, sous-système, système standard applicable en tant que tel ou adaptable aux besoins de l'acheteur.<br /> *'''ERP''' : progiciel intégré, composé d'un ensemble de modules applicatifs qui visent à couvrir l'ensemble des fonctions de l'entreprise.<br /> <br /> ===Propriétés des COTS / ERP===<br /> <br /> COTS / ERP : applications développées qui peuvent être utilisées par plusieurs organisations.<br /> <br /> *'''Composants standards''' : peuvent être intégrés en tant que tels si les conditions d'environnement sont satisfaites.<br /> *'''Composants adaptables''' : nécessitent d'être configurés ou paramétrés en fonction des besoins de chaque organisation.<br /> <br /> '''La démarche de développement''' : sélectionner -&gt; adapter -&gt; assembler -&gt; mettre à jour.<br /> <br /> Les propriétés : <br /> *'''Coût''' : le développement de SI le moins cher.<br /> *'''Temps''' : Le temps de développement de SI est considérablement réduit.<br /> *'''Erreurs''' : il y a très peu de risques d'erreurs de programmation.<br /> *'''Besoins''' : correspond parfaitement aux processus standards. <br /> *'''Risques''' : <br /> **l'offre contient plus de fonctionnalités que l'organisation en a besoin.<br /> **ne s'adapte pas aux processus métier -&gt; c'est le métier qui doit s'adapter.<br /> **ne couvre pas toujours toutes les fonctionnalités nécessaires de l'organisation.<br /> <br /> ==Développement par les futurs utilisateurs==<br /> <br /> Développement des SI par des non-professionnels de SI - les futurs utilisateurs.<br /> *Les objectifs des applications sont plus réduits.<br /> *Les applications sont plutôt personnelles ou départementales et ont rarement un objectif plus général.<br /> *Les applications sont destinées pour récupérer l'information et générer des rapports et rarement pour la saisie des données.<br /> <br /> Les propriétés : <br /> *'''Coût''' : le coût de développement est moyen.<br /> *'''Temps''' : le temps de développement est relativement court.<br /> *'''Erreurs''' : les applications peuvent comporter beaucoup d'erreurs.<br /> *'''Besoins''' : le SI résultat correspond parfaitement aux besoins des utilisateurs.<br /> <br /> ==Développement mixte==<br /> <br /> #Achat des COTS / ERP pour les activités standards.<br /> #Développement sur mesure pour les activités spécifiques de l'organisation.<br /> <br /> Les propriétés :<br /> *'''Coût''' : le coût de développement est plus adapté.<br /> *'''Temps''' : le temps de développement du SI est réduit grâce à l'achat des COTS / ERP.<br /> *'''Erreurs''' : le risque d'erreurs de programmation est raisonnable. <br /> *'''Besoins''' : les besoins des utilisateurs sont parfaitement satisfaits.<br /> <br /> =Projet SI vs Développement d'entreprise=<br /> <br /> *Projet Si est une '''nécessité''' pour se mettre en conformité avec le développement d'entreprise.<br /> **Changement organisationnel/métier nécessite un nouveau support technologique et informationnel.<br /> *Projet SI est un '''prétexte''' pour le développement d'entreprise.<br /> **Nouveautés technologiques et informationnelles influencent les changements économiques/métier/organisationnels.<br /> *Projet SI est '''au coeur''' du développement d'entreprise.<br /> **La réorganisation d'entreprise et la réingénierie de son SI est le même projet.<br /> <br /> ==Impact d'un nouveau SI sur l'organisation==<br /> <br /> La mise en place d'un nouveau SI/service implique des changements des : <br /> *Informations (type, forme, contenu, qualité)<br /> *Activités<br /> *Responsabilités et rôles<br /> *Règles de gestion<br /> *Stratégie et processus économique.<br /> <br /> L'acceptation des changements dépend de leur importance et de la manière dont ils sont gérés. '''Il est important d'estimer cet impact dès le début du projet.'''<br /> <br /> =Causes d'échecs des projets SI=<br /> <br /> Étude réalisée en 1999 par ''Standish Group International'' sur 7400 projets : <br /> *24% des projets complétés dans les temps et budgets<br /> *34% des projets en retard et/ou dépassent les budgets<br /> *31% des projets annulés.<br /> <br /> Causes d'échec, mauvaise gestion des :<br /> *Technologies<br /> **Mauvais choix des technologies<br /> **Mauvais choix de la méthode<br /> *Données<br /> **Mauvaise conception des données<br /> **Mauvaise conception des processus<br /> **Mauvaise gestion des données<br /> **Mauvais contrôle de la qualité des données<br /> *Usagers<br /> **Mauvaise gestion des utilisateurs<br /> **Manque d'enthousiasme, réticence des utilisateurs.<br /> *Règles et processus métier<br /> **Mauvaise adaptation à l'environnement métier<br /> **Mauvais changements des processus métier<br /> *Politique et culture de l'organisation.<br /> **Mauvais choix de l'objectif global de l'organisation<br /> **Problèmes de la politique interne.<br /> <br /> = Critères d'évaluation de la situation et de la faisabilité des projets SI =<br /> <br /> '''Objectifs'''<br /> *clarté des objectifs : stratégiques (business) et SI.<br /> <br /> '''Légitimité'''<br /> *soutien de la part de la direction.<br /> <br /> '''Pertinence'''<br /> *ce que le projet va apporter à l'entreprise<br /> *le rapport objectif-moyen-délai est-il approprié?<br /> <br /> '''Degré de changement'''<br /> *innovation métier/technologique.<br /> <br /> '''Futurs utilisateurs'''<br /> *le nombre d'utilisateurs<br /> *le nombre de différentes catégories d'utilisateur,<br /> *motivation et implication des futurs utilisateurs dans le projet<br /> <br /> '''Difficultés et contraintes'''<br /> *techniques, pression du temps, budget,...<br /> <br /> '''Culture organisationnelle'''<br /> <br /> '''Compétences de l'équipe'''<br /> *expérience et connaissances requises<br /> <br /> <br /> = Annexes =<br /> <br /> = Références =<br /> &lt;references/&gt;</div>

Sania https://baripedia.org/index.php?title=Fichier:Sociabilite_vs_solidarite.png&diff=32256 2016-05-16T11:40:23Z

<p>Sania : Classification des cultures organisationnelles, sociabilité vs solidarité. Modèle de Goffee &amp; Jones</p> <hr /> <div>Classification des cultures organisationnelles, sociabilité vs solidarité. Modèle de Goffee &amp; Jones</div>

Sania https://baripedia.org/index.php?title=Fichier:Cultures_organisationnelles_harrison_handy.png&diff=32255 2016-05-16T11:29:25Z

<p>Sania : Classification des cultures organisationnelles, Modèle de Harrison &amp; Handy</p> <hr /> <div>Classification des cultures organisationnelles, Modèle de Harrison &amp; Handy</div>

Sania https://baripedia.org/index.php?title=Fichier:Projet_SI_organisation.png&diff=32254 2016-05-16T11:20:50Z

<p>Sania : Organisation d'un projet SI</p> <hr /> <div>Organisation d'un projet SI</div>

Sania https://baripedia.org/index.php?title=Activit%C3%A9s_et_caract%C3%A9ristiques_de_la_gestion_de_projets_SI&diff=32252 2016-05-16T08:23:47Z

<p>Sania : Page créée avec « {{Infobox Lecture | image = | cours = Gestion de projet | faculté = Faculté d'économie et de management | département = Services généraux GSEM | do... »</p> <hr /> <div>{{Infobox Lecture<br /> | image = <br /> | cours = [[Gestion de projet]]<br /> | faculté = [[Faculté d'économie et de management]]<br /> | département = [[Services généraux GSEM]]<br /> | domaine = [[Système d'information]]<br /> | professeurs = [[Jolita Ralyte]]&lt;ref&gt;[http://cui.unige.ch/~ralyte/ Page personnelle de Jolita Ralyte sur le site du CUI]&lt;/ref&gt;<br /> | années = <br /> | code = S204033 CR &lt;ref&gt;[http://wadme.unige.ch:3149/pls/opprg/w_det_cours.debut?p_code_cours=S204033&amp;p_plan_is=0&amp;p_langue=1&amp;p_frame=N&amp;p_mode=PGC&amp;p_annee=2015&amp;p_suffixe=&amp;p_grtri= Présentation du cours sur le site du catalogue de cours wadme]&lt;/ref&gt;<br /> | enregistrement = <br /> | précédent = <br /> | suivant = [[Organisation de projets]]<br /> }}<br /> <br /> =Définition d'un projet SI=<br /> [[Fichier:Schema triangle projet.png|cadre|droite|Double-triangle d'un projet]]<br /> <br /> Un projet est une '''image''' plus ou moins précise d'un '''futur''' que l'on pense atteindre.<br /> <br /> ''Un projet correspond à la situation dans laquelle on se trouve quand on doit atteindre un '''objectif''' avec des '''moyens''' ad hoc et dans un '''délai''' donné'' (Morley, 1999).<br /> <br /> ''Un projet SI est une organisation humaine temporaire permettant de mener à bien une adaptation, c'est-à-dire toute forme de modification, amélioration, automatisation, etc. du système d'information, ce qui inclut développement, maintenance, conception, rétro-conception, installation, etc.'' (Eurométhode).<br /> <br /> *'''Objectif''' : le lancement d'un projet relève d'une décision<br /> *'''Délai''' : tout projet est temporaire. Par nature, il est destiné à s'achever à un horizon visible<br /> *'''Moyens''' : le budget affecté au projet, les ressources humaines, le matériel<br /> *'''Gestion de la production''' : suivre et diriger l'avancement vers l'objectif, assurer la qualité du résultat attendu<br /> *'''Gestion du temps''' : définir le parcours et le jalonner, établir les calendriers, maîtriser la consommation du temps<br /> *'''Gestion des ressources''' : transformer le budget affecté au projet en travail, locaux, matériel, déplacements, etc.<br /> <br /> =Activités de la gestion des projets=<br /> [[Fichier:Activites gestion projet.png|cadre|centré|Activités dans la gestion d'un projet]]<br /> <br /> *'''Analyser''' : déterminer le chemin à emprunter pour avance vers l'objectif. Faisabilité, risques, type de développement, charge.<br /> *'''Organiser''' : organiser le travail pour atteindre l'objectif. Ordonnancement des tâches, création des équipes, planification.<br /> *'''Piloter''' : suivre l'avancement du projet en quantité et en qualité. Analyse des écarts, gestion de changement, gestion des conflits. <br /> *'''Terminer''' : clôturer le projet. Décision, finances, documentation, redistribution des ressources, célébration.<br /> <br /> Le projet se gère du début à la fin.<br /> <br /> =Caractéristiques des projets SI=<br /> [[Fichier:Interactions projet SI.png|vignette|droite|Interactions entre les caractéristiques des projets SI]]<br /> <br /> Il y a une interaction constante entre '''l'objectif''' d'une part et les '''moyens/délais''' d'autre part.<br /> <br /> Une première identification de l'objectif conduit à estimer la charge globale du projet : une échéance cible théorique et des moyens à affecter. '''Design-to-cost''' : si certaines contraintes obligent à limite le délai ou le budget, on ajuste l'objectif.<br /> <br /> L'objectif du projet n'est parfaitement défini qu'à l'achèvement de celui-ci.<br /> <br /> *Un SI est un produit ayant des caractéristiques très spécifiques :<br /> **il est immatériel<br /> **il est reproductible<br /> **il nécessite une maintenance<br /> **il a besoin d'évoluer<br /> **il possède une dimension subjective.<br /> *Il n'est pas possible de donner une représentation visuelle d'un SI :<br /> **il est décrit par ses fonctions. La description n'est jamais exhaustive, et les modèles n'en donnent qu'une vue très partielle. <br /> <br /> =Types de développement des SI=<br /> <br /> =Causes d'échecs des projets SI=<br /> <br /> =Évaluation de la situation et de la faisabilité des projets SI=</div>

Sania https://baripedia.org/index.php?title=Fichier:Interactions_projet_SI.png&diff=32251 2016-05-16T07:58:55Z

<p>Sania : Interactions entre les caractéristiques d'un projet SI</p> <hr /> <div>Interactions entre les caractéristiques d'un projet SI</div>

Sania https://baripedia.org/index.php?title=Fichier:Activites_gestion_projet.png&diff=32250 2016-05-16T07:53:02Z

<p>Sania : Activités dans la gestion d'un projet</p> <hr /> <div>Activités dans la gestion d'un projet</div>

Sania https://baripedia.org/index.php?title=Fichier:Schema_triangle_projet.png&diff=32249 2016-05-16T07:49:49Z

<p>Sania : Schéma d'un projet</p> <hr /> <div>Schéma d'un projet</div>

Sania https://baripedia.org/index.php?title=Introduction_et_typologie_des_syst%C3%A8mes_d%27information&diff=32248 2016-05-16T07:39:05Z

<p>Sania : </p> <hr /> <div>{{Infobox Lecture<br /> | image = <br /> | cours = [[Gestion de projet]]<br /> | faculté = [[Faculté d'économie et de management]]<br /> | département = [[Services généraux GSEM]]<br /> | domaine = [[Système d'information]]<br /> | professeurs = [[Jolita Ralyte]]&lt;ref&gt;[http://cui.unige.ch/~ralyte/ Page personnelle de Jolita Ralyte sur le site du CUI]&lt;/ref&gt;<br /> | années = <br /> | code = S204033 CR &lt;ref&gt;[http://wadme.unige.ch:3149/pls/opprg/w_det_cours.debut?p_code_cours=S204033&amp;p_plan_is=0&amp;p_langue=1&amp;p_frame=N&amp;p_mode=PGC&amp;p_annee=2015&amp;p_suffixe=&amp;p_grtri= Présentation du cours sur le site du catalogue de cours wadme]&lt;/ref&gt;<br /> | enregistrement = <br /> | précédent = <br /> | suivant = [[Activités et caractéristiques de la gestion de projets SI]]<br /> }}<br /> <br /> <br /> <br /> = Définitions = <br /> <br /> ==Système d'Information==<br /> <br /> *un ensemble organisé de ressources (matériels, logiciels, personnel, données et procédures) qui permet de '''collecter, regrouper, classifier, traiter et diffuser de l’information''' sur un environnement donné<br /> *un ensemble de composants permettant de recueillir, transmettre, stocker et traiter les '''données''' afin de fournir une '''information''' nécessaire pour l’administration, la communication, la production, le commerce et autres activités de l’organisation.<br /> <br /> ==Valeur de l'information==<br /> <br /> une entreprise crée de la valeur en traitant de l’information, en particulier dans le cas des sociétés de services. Ainsi, l’information possède une valeur d’autant plus grande qu’elle contribue à l’atteinte des objectifs de l’organisation.<br /> <br /> = Objectifs des SI = <br /> <br /> fournir des '''informations''' nécessaires à des '''utilisateurs''' qui en ont besoin au moment voulu sous '''forme''' convenable afin de les aider à accomplir leurs rôles respectifs au sein d’une organisation.<br /> <br /> = Données VS information = <br /> ==Données==<br /> <br /> Les données sont les faits, la matière pour obtenir l’information.<br /> <br /> ==Information==<br /> <br /> L’information est un accroissement de la connaissance que l’on a déjà : elle contribue à l’ensemble de faits et de concepts que l’on connaît et elle dépend du '''contexte''', de la question que l’on pose (réponse à une requête, résultat d’une décision, document d’une transaction, rapport).<br /> <br /> = Qualité de l'information = <br /> <br /> Les attributs permettant de mesurer la qualité de l’information : <br /> * '''Disponibilité''' : disponible toujours quand elle est nécessaire et non périmée si disponible.<br /> * '''Complétude''' : comprend tout ce que l’utilisateur doit savoir sur la situation dans laquelle elle est utilisée.<br /> * '''Brièveté''' : ne comprend pas d’éléments non nécessaires<br /> * '''Importance''' : comprend uniquement ce qui est important dans la situation en cours<br /> * '''Exactitude''' : correspond à la réalité qu’elle représente, ne comporte pas d’erreurs <br /> * '''Précision''' : offre une information quantitative avec le degré d’exactitude approprié aux données correspondantes<br /> * '''Forme''' : Comporte le niveau de détails (affichage tabulaire ou graphique, forme quantitative ou qualitative) en fonction de la situation<br /> <br /> <br /> = Types d'information = <br /> ==Information interne==<br /> <br /> Information sur les produits, les processus et les ressources internes de l’organisation. Elle est gérée par le SI de l’organisation.<br /> <br /> ==Information externe==<br /> <br /> Information sur l’environnement externe de l’organisation. Elle peut être gérée partiellement par le SI de l’organisation, mais aussi récupérée à partir des sources externes : sites web, revues spécialisées, etc. <br /> {| class=&quot;wikitable&quot;<br /> |-<br /> ! Décideurs !! Information<br /> |-<br /> | Clients || les stratégies de marketing, les ventes, les mesures de satisfaction<br /> |-<br /> | Distributeurs || le marketing et la logistique de distribution<br /> |-<br /> | Fournisseurs || les conditions de vente et la qualité des produits<br /> |-<br /> | Concurrents || le marché, les innovations, la qualité des produits<br /> |-<br /> | Syndicats || les compensations, la stabilité d'emploi<br /> |-<br /> | Actionnaires || les performances de la compagnie et leur sécurité<br /> |-<br /> | Institutions financières || les conditions de financement, les possibilités d'investissement<br /> |-<br /> | Associations commerciales || les intérêts de participation, l'information sur la concurrence<br /> |-<br /> | Gouvernement || la politique, la réglementation, la législation<br /> |}<br /> <br /> = SI dans une entreprise = <br /> <br /> L'information a plusieurs rôles dans une entreprise : <br /> * l’information est un '''support pour l’action''' : <br /> ** les informations tarifaires permettent d’établire la facturation,<br /> ** les informations sur les produits et le stock facilitent la vente,<br /> ** les informations sur les distributeurs facilitent la livraison des produits, etc.<br /> * l'information '''conserve une trace des activités'''<br /> **la tenue d'une comptabilité<br /> **le cycle de vie d'une commande<br /> ** le processus de production d'un produit, etc.<br /> *l'information apporte une '''aide à la prise de décision'''<br /> **les ventes récentes classées par catégorie de produit apportent un élément pour ajuster les tarifs et les quantités de production, etc.<br /> <br /> ==Les attentes des entreprises de la part des SI==<br /> <br /> *Renforcer la position de la '''compétitivité''' (augmenter les ventes et le profit)<br /> *Augmenter la '''productivité'''<br /> *Diminuer le '''coût''' de la production<br /> *Améliorer la '''qualité''' des produits ou des services<br /> *Améliorer la capacité de prendre les '''décisions'''<br /> *Améliorer la '''rapidité''' des réponses aux demandes des vendeurs<br /> *Augmenter la '''capacité de communication et de collaboration''' à l'intérieur de l'entreprise ainsi qu'avec les clients, les filiales et les fournisseurs<br /> *Améliorer les '''conditions de travail''' des employés.<br /> <br /> = Nouvelles influences dans la gestion de l'information =<br /> <br /> *'''La dématérialisation des objets de gestion'''<br /> **les actions et les obligations n'ont plus d'existence matérielle, leur propriété n'est plus assurée par une détention d'un certificat mais par une simple inscription dépositaire d'une ligne au compte client;<br /> **les billets d'avion, de train, de spectacle et autres sont vendus sous forme électronique.<br /> *'''La dématérialisation des produits'''<br /> **la musique, les films, les livres et autres médias ne sont plus réalisés sur un support physique (ex. disque, papier) mais sous forme électronique (ex. mp3, PDF, autres formats propriétaires et libres).<br /> *'''L'exigence de qualité'''<br /> **la norme ISO 9000 impose d'avoir un dispositif garantissant la maîtrise des documents utilisés dans l'entreprise : documents de travail, documents techniques, documents de gestion, etc.<br /> *'''La recherche d'innovation'''<br /> **les services en ligne : bancaires, réservations (hôtel, avion, voiture, train, spectacle, etc.);<br /> **les nouveaux circuits de distribution grâce à l'Internet et le développement de e-commerce,<br /> **les nouveaux types de production : le client termine la chaîne de production (copie un fichier sur un support, l'imprime, ou l'assemble, ou autre);<br /> **services informationnels sur des supports mobiles.<br /> = Composants d'un SI = <br /> [[Fichier:Schema systeme.png|vignette|droite|Fonctionnement d'un système]]<br /> [[Fichier:Schema composants systeme.png|vignette|droite|Schéma du fonctionnement d'un système et ses composants]]<br /> <br /> Un système est un ensemble de composants (de sous-systèmes ou des parties élémentaires) qui travaillent ensemble pour réaliser un ou plusieurs objectifs communs.<br /> <br /> *'''Matériel'''<br /> **serveurs, PCs, imprimantes, scanners, etc.<br /> *'''Logiciels'''<br /> **programmes système, programmes d'application, programmes sécurité, etc.<br /> *'''Bases de données'''<br /> **collections organisées de données utilisées par les logiciels d'application<br /> *'''Télécommunications'''<br /> **intranet, extranet, internet<br /> *'''Ressources humaines'''<br /> **ingénieurs informatique, responsables SI, utilisateurs du SI<br /> *'''Procédures''' <br /> **spécifications d'utilisation, opérations, maintenance, aide en ligne, manuels d'utilisateur, manuels d'opérateur, autres documents souvent sous forme électronique.<br /> <br /> <br /> = Typologie des SI =<br /> ==Commerce et finances==<br /> <br /> Il existe de nombreuses classifications des systèmes pour gérer les ressources financières. Nous citons ici les systèmes de la classification la plus souvent utilisée.<br /> <br /> ===Systèmes de traitement de transactions===<br /> [[Fichier:Schema traitement transaction.png|vignette|droite|Schéma des systèmes de traitement de transactions]]<br /> <br /> L'objectif de ces systèmes est d''''aider les entreprises dans la réalisation des opérations commerciales et logistiques'''.<br /> <br /> Une '''transaction''' est une activité élémentaire exécutée durant une opération commerciale. <br /> <br /> ''Exemples : une réservation des billets d'avion, une vente des produits, un achat des ressources, un inventaire des stocks, une livraison, etc.'' <br /> <br /> '''Modes de fonctionnement : '''<br /> *Par lot : traite en une fois toutes les transactions accumulées durant une période prédéfinie (ex. une fois par jour)<br /> *En ligne : traite chaque transaction tout de suite après son exécution<br /> ===Systèmes de gestion comptable et financière===<br /> <br /> ===Customer Relationship Management - CRM===<br /> <br /> ===Service Après-Ventre - SAV===<br /> <br /> ==Administration==<br /> <br /> Ces systèmes sont d'une précieuse aide à l'administration et à la décision.<br /> <br /> ===Systèmes d'information exécutive===<br /> [[Fichier:Schema systeme executive.png|vignette|droite|Schéma d'un système d'information exécutive]]<br /> <br /> L'objectif de ces systèmes est d''''aider les directeur et les administrateurs de haut niveau dans leur travail exécutif''' en leur proposant une large variété d'informations internes et externes présentées sous forme de résumés épurés (avec un haut niveau d'abstraction).<br /> <br /> *'''Utilisateurs''' : le PDG, les directeurs, les administrateurs de haut niveau, le conseil d'administration, etc.<br /> *'''Information''' : le résumé sur la performance de la compagnie dans différents domaines.<br /> *'''Forme d'expression''' : graphique, tabulaire<br /> <br /> ===Systèmes d'aide à la décision===<br /> [[Fichier:schema_aide_decision.png|vignette|droite|Schéma des systèmes d'aide à la décision]]<br /> <br /> L'objectif de ces systèmes est d''''aider les administrateurs des entreprises dans les processus de prise de décisions'''.<br /> <br /> Le système propose des modèles de base permettant de résoudre certains problèmes type.<br /> <br /> ''Exemples : modèle de prévision des ventes, modèle de définition des prix, modèle de planification de la production, etc.''<br /> <br /> Chaque modèle comporte un ensemble de facteurs de décision et permet d'exécuter des différents scénarios en choisissant à chaque fois des facteurs différents.<br /> <br /> Le modèle définit les indépendances entre les facteurs de décision et les conséquences possibles, et l'administrateur est demandé de faire certains jugements par la suite.<br /> <br /> ====Exemple de scénario de décision====<br /> <br /> '''Objectif''' : définir le prix d'un nouveau produit.<br /> <br /> '''Moyen''' : Système d'aide à la décision pour le marketing<br /> <br /> '''Scénario d'utilisation :''' <br /> <br /> # '''L'administrateur''' saisit les facteurs de décision :<br /> ## le coût des ressources,<br /> ## le coût du travail,<br /> ## le coût de la promotion,<br /> ## le profit prévu durant les 5 années à venir,<br /> ## le prix d'un produit similaire,<br /> ## etc.<br /> # Le '''système''' calcule le prix du produit.<br /> # '''L'administrateur''' modifie un ou plusieurs facteurs de décision.<br /> # Le '''système''' calcule le prix du produit.<br /> ...<br /> <br /> Au final, '''le système résume tous les résultat'''''', et l'administrateur compare''' les résultats '''et choisit''' le prix.<br /> <br /> ===Systèmes de rapports de gestion===<br /> [[Fichier:Systeme rapport gestion.png|vignette|droite|Schéma des systèmes de rapports de gestion]]<br /> <br /> L'objectif de ces systèmes est d''''offrir des informations aux administrateurs des entreprises sous forme de rapports''' de performance en fonction de leur domaine de responsabilité.<br /> Un rapport décrit une situation passée ou actuelle, mais il ne prévoit pas le futur.<br /> <br /> ''Exemples : toutes les ventes réalisées l'année passée, le chiffre d'affaires classé par produit vendu, le chiffre d'affaire par client, le pourcentage de livraisons en retard, etc.''<br /> <br /> Les rapports sont générés sous forme électronique, et les données sont récupérées à partir de la base de données (enregistrées par le système de traitement de transactions) ou à partir des extraits de cette base.<br /> <br /> ===Systèmes experts===<br /> [[Fichier:Schema systeme expert.png|vignette|droite|Schéma d'un SI expert]]<br /> <br /> Les systèmes experts '''utilisent une intelligence artificielle pour résoudre des problèmes dans un domaine particulier''' qui, normalement, nécessitent des experts humains dans ce domaine précis, et qui sont généralement plus durs et coûteux à trouver.<br /> <br /> '''Un système expert est un système d'aide à la décision.'''<br /> <br /> ''Exemples : systèmes de diagnostics médicaux, systèmes de diagnostics des minéraux, systèmes d'évaluation des matières de construction, etc.''<br /> <br /> Un système expert s'appuie sur : <br /> *une base de connaissance d'un domaine d'application très étroite<br /> **cette base contient l'ensemble des informations, en particulier des règles et des faits qui constituent le domaine de compétence du système. Elle est élaborée en collaborant avec des spécialistes du domaine.<br /> *un moteur d'inférences permettant de réaliser des déductions logiques. <br /> <br /> Les systèmes experts peuvent être incorporés dans tous les types de SI mais aussi utilisés comme des outils consultants. Ils sont surtout combinés avec les systèmes d'aide à la décision.<br /> <br /> ===Systèmes de gestion des ressources humaines===<br /> ===Systèmes de gestion des connaissances===<br /> ==Production==<br /> ===Systèmes d'aide professionnelle===<br /> <br /> Ces systèmes sont des postes de travail étendus dont les ressources sont essentiellement conçues pour aider une catégorie de travail professionnel.<br /> <br /> ''Exemple : système pour les concepteurs de voitures. Les postes de travail ont donc une résolution graphique très élevée, des outils de conception appropriés, ainsi que des outils de simulation d'accidents et de mesure de la résistance aux chocs des véhicules et les sécurité des passagers.''<br /> <br /> Autres exemples : <br /> *systèmes d'information géographique pour les secours, pompiers, urgence, police, etc.,<br /> *systèmes de recherche bibliographique pour les chercheurs,<br /> *systèmes de visualisation tridimensionnelle pour les scientifiques,<br /> *systèmes de mise en page pour les éditeurs,<br /> *systèmes de design pour les architectes et constructeurs,<br /> *systèmes de gestion des étudiants, des diplômes, des examens, etc.<br /> <br /> ===Systèmes de planification et de production===<br /> ===Systèmes de gestion de la qualité===<br /> ===Supplier Relationship Management - SRM===<br /> <br /> ==Communication==<br /> ===Systèmes d'information bureautique===<br /> <br /> L'objectif de ces systèmes et de faciliter la communication entre les membres d'une organisation ainsi qu'entre l'organisation elle-même et son environnement.<br /> <br /> Les SI bureautique aident à : <br /> *gérer différents moyens de communication :<br /> **les documents électroniques,<br /> **les messageries : électronique, fax, poste, etc.<br /> **les vidéoconférences,<br /> **les réunions électroniques, etc.<br /> *réaliser un objectif collaboratif : <br /> **partager l'information dans une équipe de travail,<br /> **éditer des documents ensemble,<br /> **suivre le progrès d'un projet commun, etc.<br /> <br /> = Annexes =<br /> <br /> = Références =<br /> &lt;references/&gt;<br /> <br /> [[category:2016]]</div>

Sania https://baripedia.org/index.php?title=Introduction_et_typologie_des_syst%C3%A8mes_d%27information&diff=32247 2016-05-16T07:37:00Z

<p>Sania : </p> <hr /> <div>{{Infobox Lecture<br /> | image = <br /> | cours = [[Gestion de projet]]<br /> | faculté = [[Faculté d'économie et de management]]<br /> | département = [[Services généraux GSEM]]<br /> | domaine = [[Système d'information]]<br /> | professeurs = [[Jolita Ralyte]]&lt;ref&gt;[http://cui.unige.ch/~ralyte/ Page personnelle de Jolita Ralyte sur le site du CUI]&lt;/ref&gt;<br /> | années = <br /> | code = S204033 CR &lt;ref&gt;[http://wadme.unige.ch:3149/pls/opprg/w_det_cours.debut?p_code_cours=S204033&amp;p_plan_is=0&amp;p_langue=1&amp;p_frame=N&amp;p_mode=PGC&amp;p_annee=2015&amp;p_suffixe=&amp;p_grtri= Présentation du cours sur le site du catalogue de cours wadme]&lt;/ref&gt;<br /> | enregistrement = <br /> | précédent = <br /> | suivant = [[Activités et caractéristiques de la gestion de projets SI]]<br /> }}<br /> <br /> <br /> = Définitions = <br /> ==Système d'Information==<br /> <br /> *un ensemble organisé de ressources (matériels, logiciels, personnel, données et procédures) qui permet de '''collecter, regrouper, classifier, traiter et diffuser de l’information''' sur un environnement donné<br /> *un ensemble de composants permettant de recueillir, transmettre, stocker et traiter les '''données''' afin de fournir une '''information''' nécessaire pour l’administration, la communication, la production, le commerce et autres activités de l’organisation.<br /> <br /> ==Valeur de l'information==<br /> <br /> une entreprise crée de la valeur en traitant de l’information, en particulier dans le cas des sociétés de services. Ainsi, l’information possède une valeur d’autant plus grande qu’elle contribue à l’atteinte des objectifs de l’organisation.<br /> <br /> = Objectifs des SI = <br /> <br /> fournir des '''informations''' nécessaires à des '''utilisateurs''' qui en ont besoin au moment voulu sous '''forme''' convenable afin de les aider à accomplir leurs rôles respectifs au sein d’une organisation.<br /> <br /> = Données VS information = <br /> ==Données==<br /> <br /> Les données sont les faits, la matière pour obtenir l’information.<br /> <br /> ==Information==<br /> <br /> L’information est un accroissement de la connaissance que l’on a déjà : elle contribue à l’ensemble de faits et de concepts que l’on connaît et elle dépend du '''contexte''', de la question que l’on pose (réponse à une requête, résultat d’une décision, document d’une transaction, rapport).<br /> <br /> = Qualité de l'information = <br /> <br /> Les attributs permettant de mesurer la qualité de l’information : <br /> * Disponibilité : disponible toujours quand elle est nécessaire et non périmée si disponible.<br /> * Complétude : comprend tout ce que l’utilisateur doit savoir sur la situation dans laquelle elle est utilisée.<br /> * Brièveté : ne comprend pas d’éléments non nécessaires<br /> * Importance : comprend uniquement ce qui est important dans la situation en cours<br /> * Exactitude : correspond à la réalité qu’elle représente, ne comporte pas d’erreurs <br /> * Précision : offre une information quantitative avec le degré d’exactitude approprié aux données correspondantes<br /> * Comporte le niveau de détails (affichage tabulaire ou graphique, forme quantitative ou qualitative) en fonction de la situation<br /> <br /> = Types d'information = <br /> ==Information interne==<br /> <br /> Information sur les produits, les processus et les ressources internes de l’organisation. Elle est gérée par le SI de l’organisation.<br /> <br /> ==Information externe==<br /> <br /> Information sur l’environnement externe de l’organisation. Elle peut être gérée partiellement par le SI de l’organisation, mais aussi récupérée à partir des sources externes : sites web, revues spécialisées, etc. <br /> {| class=&quot;wikitable&quot;<br /> |-<br /> ! Décideurs !! Information<br /> |-<br /> | Clients || les stratégies de marketing, les ventes, les mesures de satisfaction<br /> |-<br /> | Distributeurs || le marketing et la logistique de distribution<br /> |-<br /> | Fournisseurs || les conditions de vente et la qualité des produits<br /> |-<br /> | Concurrents || le marché, les innovations, la qualité des produits<br /> |-<br /> | Syndicats || les compensations, la stabilité d'emploi<br /> |-<br /> | Actionnaires || les performances de la compagnie et leur sécurité<br /> |-<br /> | Institutions financières || les conditions de financement, les possibilités d'investissement<br /> |-<br /> | Associations commerciales || les intérêts de participation, l'information sur la concurrence<br /> |-<br /> | Gouvernement || la politique, la réglementation, la législation<br /> |}<br /> <br /> = SI dans une entreprise = <br /> <br /> L'information a plusieurs rôles dans une entreprise : <br /> * l’information est un '''support pour l’action''' : <br /> ** les informations tarifaires permettent d’établire la facturation,<br /> ** les informations sur les produits et le stock facilitent la vente,<br /> ** les informations sur les distributeurs facilitent la livraison des produits, etc.<br /> * l'information '''conserve une trace des activités'''<br /> **la tenue d'une comptabilité<br /> **le cycle de vie d'une commande<br /> ** le processus de production d'un produit, etc.<br /> *l'information apporte une '''aide à la prise de décision'''<br /> **les ventes récentes classées par catégorie de produit apportent un élément pour ajuster les tarifs et les quantités de production, etc.<br /> <br /> ==Les attentes des entreprises de la part des SI==<br /> <br /> *Renforcer la position de la '''compétitivité''' (augmenter les ventes et le profit)<br /> *Augmenter la '''productivité'''<br /> *Diminuer le '''coût''' de la production<br /> *Améliorer la '''qualité''' des produits ou des services<br /> *Améliorer la capacité de prendre les '''décisions'''<br /> *Améliorer la '''rapidité''' des réponses aux demandes des vendeurs<br /> *Augmenter la '''capacité de communication et de collaboration''' à l'intérieur de l'entreprise ainsi qu'avec les clients, les filiales et les fournisseurs<br /> *Améliorer les '''conditions de travail''' des employés.<br /> <br /> = Nouvelles influences dans la gestion de l'information =<br /> <br /> *'''La dématérialisation des objets de gestion'''<br /> **les actions et les obligations n'ont plus d'existence matérielle, leur propriété n'est plus assurée par une détention d'un certificat mais par une simple inscription dépositaire d'une ligne au compte client;<br /> **les billets d'avion, de train, de spectacle et autres sont vendus sous forme électronique.<br /> *'''La dématérialisation des produits'''<br /> **la musique, les films, les livres et autres médias ne sont plus réalisés sur un support physique (ex. disque, papier) mais sous forme électronique (ex. mp3, PDF, autres formats propriétaires et libres).<br /> *'''L'exigence de qualité'''<br /> **la norme ISO 9000 impose d'avoir un dispositif garantissant la maîtrise des documents utilisés dans l'entreprise : documents de travail, documents techniques, documents de gestion, etc.<br /> *'''La recherche d'innovation'''<br /> **les services en ligne : bancaires, réservations (hôtel, avion, voiture, train, spectacle, etc.);<br /> **les nouveaux circuits de distribution grâce à l'Internet et le développement de e-commerce,<br /> **les nouveaux types de production : le client termine la chaîne de production (copie un fichier sur un support, l'imprime, ou l'assemble, ou autre);<br /> **services informationnels sur des supports mobiles.<br /> = Composants d'un SI = <br /> [[Fichier:Schema systeme.png|vignette|droite|Fonctionnement d'un système]]<br /> [[Fichier:Schema composants systeme.png|vignette|droite|Schéma du fonctionnement d'un système et ses composants]]<br /> <br /> Un système est un ensemble de composants (de sous-systèmes ou des parties élémentaires) qui travaillent ensemble pour réaliser un ou plusieurs objectifs communs.<br /> <br /> *'''Matériel'''<br /> **serveurs, PCs, imprimantes, scanners, etc.<br /> *'''Logiciels'''<br /> **programmes système, programmes d'application, programmes sécurité, etc.<br /> *'''Bases de données'''<br /> **collections organisées de données utilisées par les logiciels d'application<br /> *'''Télécommunications'''<br /> **intranet, extranet, internet<br /> *'''Ressources humaines'''<br /> **ingénieurs informatique, responsables SI, utilisateurs du SI<br /> *'''Procédures''' <br /> **spécifications d'utilisation, opérations, maintenance, aide en ligne, manuels d'utilisateur, manuels d'opérateur, autres documents souvent sous forme électronique.<br /> <br /> <br /> = Typologie des SI =<br /> ==Commerce et finances==<br /> <br /> Il existe de nombreuses classifications des systèmes pour gérer les ressources financières. Nous citons ici les systèmes de la classification la plus souvent utilisée.<br /> <br /> ===Systèmes de traitement de transactions===<br /> [[Fichier:Schema traitement transaction.png|vignette|droite|Schéma des systèmes de traitement de transactions]]<br /> <br /> L'objectif de ces systèmes est d''''aider les entreprises dans la réalisation des opérations commerciales et logistiques'''.<br /> <br /> Une '''transaction''' est une activité élémentaire exécutée durant une opération commerciale. <br /> <br /> ''Exemples : une réservation des billets d'avion, une vente des produits, un achat des ressources, un inventaire des stocks, une livraison, etc.'' <br /> <br /> '''Modes de fonctionnement : '''<br /> *Par lot : traite en une fois toutes les transactions accumulées durant une période prédéfinie (ex. une fois par jour)<br /> *En ligne : traite chaque transaction tout de suite après son exécution<br /> ===Systèmes de gestion comptable et financière===<br /> <br /> ===Customer Relationship Management - CRM===<br /> <br /> ===Service Après-Ventre - SAV===<br /> <br /> ==Administration==<br /> <br /> Ces systèmes sont d'une précieuse aide à l'administration et à la décision.<br /> <br /> ===Systèmes d'information exécutive===<br /> [[Fichier:Schema systeme executive.png|vignette|droite|Schéma d'un système d'information exécutive]]<br /> <br /> L'objectif de ces systèmes est d''''aider les directeur et les administrateurs de haut niveau dans leur travail exécutif''' en leur proposant une large variété d'informations internes et externes présentées sous forme de résumés épurés (avec un haut niveau d'abstraction).<br /> <br /> *'''Utilisateurs''' : le PDG, les directeurs, les administrateurs de haut niveau, le conseil d'administration, etc.<br /> *'''Information''' : le résumé sur la performance de la compagnie dans différents domaines.<br /> *'''Forme d'expression''' : graphique, tabulaire<br /> <br /> ===Systèmes d'aide à la décision===<br /> [[Fichier:schema_aide_decision.png|vignette|droite|Schéma des systèmes d'aide à la décision]]<br /> <br /> L'objectif de ces systèmes est d''''aider les administrateurs des entreprises dans les processus de prise de décisions'''.<br /> <br /> Le système propose des modèles de base permettant de résoudre certains problèmes type.<br /> <br /> ''Exemples : modèle de prévision des ventes, modèle de définition des prix, modèle de planification de la production, etc.''<br /> <br /> Chaque modèle comporte un ensemble de facteurs de décision et permet d'exécuter des différents scénarios en choisissant à chaque fois des facteurs différents.<br /> <br /> Le modèle définit les indépendances entre les facteurs de décision et les conséquences possibles, et l'administrateur est demandé de faire certains jugements par la suite.<br /> <br /> ====Exemple de scénario de décision====<br /> <br /> '''Objectif''' : définir le prix d'un nouveau produit.<br /> <br /> '''Moyen''' : Système d'aide à la décision pour le marketing<br /> <br /> '''Scénario d'utilisation :''' <br /> <br /> # '''L'administrateur''' saisit les facteurs de décision :<br /> ## le coût des ressources,<br /> ## le coût du travail,<br /> ## le coût de la promotion,<br /> ## le profit prévu durant les 5 années à venir,<br /> ## le prix d'un produit similaire,<br /> ## etc.<br /> # Le '''système''' calcule le prix du produit.<br /> # '''L'administrateur''' modifie un ou plusieurs facteurs de décision.<br /> # Le '''système''' calcule le prix du produit.<br /> ...<br /> <br /> Au final, '''le système résume tous les résultat'''''', et l'administrateur compare''' les résultats '''et choisit''' le prix.<br /> <br /> ===Systèmes de rapports de gestion===<br /> [[Fichier:Systeme rapport gestion.png|vignette|droite|Schéma des systèmes de rapports de gestion]]<br /> <br /> L'objectif de ces systèmes est d''''offrir des informations aux administrateurs des entreprises sous forme de rapports''' de performance en fonction de leur domaine de responsabilité.<br /> Un rapport décrit une situation passée ou actuelle, mais il ne prévoit pas le futur.<br /> <br /> ''Exemples : toutes les ventes réalisées l'année passée, le chiffre d'affaires classé par produit vendu, le chiffre d'affaire par client, le pourcentage de livraisons en retard, etc.''<br /> <br /> Les rapports sont générés sous forme électronique, et les données sont récupérées à partir de la base de données (enregistrées par le système de traitement de transactions) ou à partir des extraits de cette base.<br /> <br /> ===Systèmes experts===<br /> [[Fichier:Schema systeme expert.png|vignette|droite|Schéma d'un SI expert]]<br /> <br /> Les systèmes experts '''utilisent une intelligence artificielle pour résoudre des problèmes dans un domaine particulier''' qui, normalement, nécessitent des experts humains dans ce domaine précis, et qui sont généralement plus durs et coûteux à trouver.<br /> <br /> '''Un système expert est un système d'aide à la décision.'''<br /> <br /> ''Exemples : systèmes de diagnostics médicaux, systèmes de diagnostics des minéraux, systèmes d'évaluation des matières de construction, etc.''<br /> <br /> Un système expert s'appuie sur : <br /> *une base de connaissance d'un domaine d'application très étroite<br /> **cette base contient l'ensemble des informations, en particulier des règles et des faits qui constituent le domaine de compétence du système. Elle est élaborée en collaborant avec des spécialistes du domaine.<br /> *un moteur d'inférences permettant de réaliser des déductions logiques. <br /> <br /> Les systèmes experts peuvent être incorporés dans tous les types de SI mais aussi utilisés comme des outils consultants. Ils sont surtout combinés avec les systèmes d'aide à la décision.<br /> <br /> ===Systèmes de gestion des ressources humaines===<br /> ===Systèmes de gestion des connaissances===<br /> ==Production==<br /> ===Systèmes d'aide professionnelle===<br /> <br /> Ces systèmes sont des postes de travail étendus dont les ressources sont essentiellement conçues pour aider une catégorie de travail professionnel.<br /> <br /> ''Exemple : système pour les concepteurs de voitures. Les postes de travail ont donc une résolution graphique très élevée, des outils de conception appropriés, ainsi que des outils de simulation d'accidents et de mesure de la résistance aux chocs des véhicules et les sécurité des passagers.''<br /> <br /> Autres exemples : <br /> *systèmes d'information géographique pour les secours, pompiers, urgence, police, etc.,<br /> *systèmes de recherche bibliographique pour les chercheurs,<br /> *systèmes de visualisation tridimensionnelle pour les scientifiques,<br /> *systèmes de mise en page pour les éditeurs,<br /> *systèmes de design pour les architectes et constructeurs,<br /> *systèmes de gestion des étudiants, des diplômes, des examens, etc.<br /> <br /> ===Systèmes de planification et de production===<br /> ===Systèmes de gestion de la qualité===<br /> ===Supplier Relationship Management - SRM===<br /> <br /> ==Communication==<br /> ===Systèmes d'information bureautique===<br /> <br /> L'objectif de ces systèmes et de faciliter la communication entre les membres d'une organisation ainsi qu'entre l'organisation elle-même et son environnement.<br /> <br /> Les SI bureautique aident à : <br /> *gérer différents moyens de communication :<br /> **les documents électroniques,<br /> **les messageries : électronique, fax, poste, etc.<br /> **les vidéoconférences,<br /> **les réunions électroniques, etc.<br /> *réaliser un objectif collaboratif : <br /> **partager l'information dans une équipe de travail,<br /> **éditer des documents ensemble,<br /> **suivre le progrès d'un projet commun, etc.<br /> <br /> = Annexes =<br /> <br /> = Références =<br /> &lt;references/&gt;<br /> <br /> [[category:2016]]</div>

Sania