Les deux révisions précédentesRévision précédenteProchaine révision | Révision précédente |
departement_info:personnels:pb:cpi4 [2022/04/21 17:09] – Brutus Philippe | departement_info:personnels:pb:cpi4 [2023/12/22 17:33] (Version actuelle) – Brutus Philippe |
---|
== Introduction == | == Introduction == |
| |
La gestion de projet est [[https://www.prodecys.com/evolution-gestion-projet/|une activité ancienne mais une discipline récente]]. | La gestion de projet est une activité ancienne mais une discipline récente. |
{{:departement_info:personnels:pb:cpi:lois.pdf|Quelques lois}} illustrent la difficulté de la conduite d'un projet.\\ | {{:departement_info:personnels:pb:cpi:lois.pdf|Quelques lois}} illustrent la difficulté de la conduite d'un projet.\\ |
Un {{:departement_info:personnels:pb:cpi:projet_info.pdf|projet informatique}} est un cas particulier de projet qui présente des {{:departement_info:personnels:pb:cpi:lois_info.pdf|difficultés}} liées à ses {{:departement_info:personnels:pb:cpi:specificites.pdf|spécificités}}. | Un {{:departement_info:personnels:pb:cpi:projet_info.pdf|projet informatique}} est un cas particulier de projet qui présente des {{:departement_info:personnels:pb:cpi:lois_info.pdf|difficultés}} liées à ses {{:departement_info:personnels:pb:cpi:specificites.pdf|spécificités}}. |
| |
Si on ne sait pas ce qu'il faut au client, démarrer le projet serait voué à l'{{:departement_info:personnels:pb:cpi:echec.pdf|échec}}. Il faut donc une expression du besoin ou {{:departement_info:personnels:pb:cpi:CdC.pdf|cahier des charges}}. Les attentes du client, exprimées {{:departement_info:personnels:pb:cpi:expr_besoin.pdf|en termes de fonctionnalités}}, peuvent être regroupées et représentées sous forme d'une {{:departement_info:personnels:pb:cpi:FBS.pdf|hiérarchie des fonctions}} ou d'un {{:departement_info:personnels:pb:cpi:cas_utilisation.pdf|diagramme de cas d'utilisation}}. La demande du client peut être complétée par la description de l'infrastructure existante, à utiliser pour la solution ou par la description de l'infrastructure préconisée. Il s'agit dans les deux cas d'une expression technique du besoin, représentée par un {{:departement_info:personnels:pb:cpi:deploiement.pdf|diagramme de déploiement}}. | Si on ne sait pas ce qu'il faut au client, démarrer le projet serait voué à l'{{:departement_info:personnels:pb:cpi:echec.pdf|échec}}. Il faut donc une expression du besoin ou {{:departement_info:personnels:pb:cpi:CdC.pdf|cahier des charges}}. Les attentes du client, exprimées {{:departement_info:personnels:pb:cpi:expr_besoin.pdf|en termes de fonctionnalités}}, peuvent être regroupées et représentées sous forme d'une {{:departement_info:personnels:pb:cpi:FBS.pdf|hiérarchie des fonctions}} ou d'un {{:departement_info:personnels:pb:cpi:cas_utilisation.pdf|diagramme de cas d'utilisation}}. La demande du client peut être complétée par la description de l'infrastructure existante, à utiliser pour la solution ou par la description de l'infrastructure préconisée. Il s'agit dans les deux cas d'une expression technique du besoin, représentée par un {{:departement_info:personnels:pb:cpi:deploiement.pdf|diagramme de déploiement}}. |
| |
| |
== Planification == | == Planification == |
Le calendrier obtenu ne tient pas compte du temps calendaire (jours travaillés et jours chômés) ni des ressources réellement disponibles. L'ordonnancement consiste à prendre en compte ces deux aspects. | Le calendrier obtenu ne tient pas compte du temps calendaire (jours travaillés et jours chômés) ni des ressources réellement disponibles. L'ordonnancement consiste à prendre en compte ces deux aspects. |
| |
Pour savoir de combien de personnes on a besoin pour mener le projet à bien, on établit une courbe qui montre comment évolue l'effectif mobilisé sur le projet en fonction du temps : {{:departement_info:personnels:pb:cpi:courbe_de_charge.pdf|la courbe de charge}}. Le maximum de cette courbe donne l'effectif minimum de l'équipe projet. On peut alors constituer une équipe et la représenter sous forme d'une hiérarchie regroupant les ressources (matérielles et humaines) en sous_ensembles : {{:departement_info:personnels:pb:cpi:RBS.pdf|l'arbre des ressources ou Resource Breakdown Structure}}. | Pour savoir de combien de personnes on a besoin pour mener le projet à bien, on établit une courbe qui montre comment évolue l'effectif mobilisé sur le projet en fonction du temps : {{:departement_info:personnels:pb:cpi:courbe_de_charge.pdf|la courbe de charge}}. Le maximum de cette courbe donne l'effectif minimum de l'équipe projet. On peut alors constituer une équipe et la représenter sous forme d'une hiérarchie regroupant les ressources (matérielles et humaines) en sous-ensembles : {{:departement_info:personnels:pb:cpi:RBS.pdf|l'arbre des ressources ou Resource Breakdown Structure}}. |
| |
On peut alors {{:departement_info:personnels:pb:cpi:affectations.pdf|affecter les ressources aux tâches}}, ce qui revient pour les personnes à préciser qui fait quoi, en veillant à une bonne occupation des ressources, c'est-à-dire sans discontinuité ni sur-utilisation.\\ Il faut alors pour chaque tâche du projet {{:departement_info:personnels:pb:cpi:responsabilités_et_rôles.pdf|désigner un responsable et préciser les autres rôles}} des acteurs du projet. On peut alors déterminer {{:departement_info:personnels:pb:cpi:contributions_et_coûts.pdf|les contributions et les coûts des ressources}}, ce qui donne une estimation du coût du projet plus précise que celle obtenue par la planification. | On peut alors {{:departement_info:personnels:pb:cpi:affectations.pdf|affecter les ressources aux tâches}}, ce qui revient pour les personnes à préciser qui fait quoi, en veillant à une bonne occupation des ressources, c'est-à-dire sans discontinuité ni sur-utilisation.\\ Il faut alors pour chaque tâche du projet {{:departement_info:personnels:pb:cpi:responsabilités_et_rôles.pdf|désigner un responsable et préciser les autres rôles}} des acteurs du projet. On peut alors déterminer {{:departement_info:personnels:pb:cpi:contributions_et_coûts.pdf|les contributions et les coûts des ressources}}, ce qui donne une estimation du coût du projet plus précise que celle obtenue par la planification. |
| |
Il existe différents modèles de processus. MERISE par exemple propose un modèle conceptuel et un modèle organisationnel des traitements. | Il existe différents modèles de processus. MERISE par exemple propose un modèle conceptuel et un modèle organisationnel des traitements. |
BPMN propose aussi une notation pour les processus métier. UML (dont on a vu le diagramme de cas d'utilisation pour l'expression fonctionnelle du besoin et le diagramme de déploiement pour l'expression du besoin technique) propose différents modèles de traitement et en particulier le {{:departement_info:personnels:pb:cpi:diagramme d'activité.pdf|diagramme d'activité}}. | BPMN propose aussi une notation pour les processus métier. UML (dont on a vu le diagramme de cas d'utilisation pour l'expression fonctionnelle du besoin et le diagramme de déploiement pour l'expression technique du besoin) propose différents modèles de traitement et en particulier le {{:departement_info:personnels:pb:cpi:diagramme d'activité.pdf|diagramme d'activité}}. |
| |
Le changement est à la fois porteur d'espoir (le projet va répondre aux attentes) et de crainte ({{:departement_info:personnels:pb:cpi:changements.pdf|de nombreux aspects peuvent être contrariés}} ou remis en cause par l'exploitation d'une solution qui n'existait pas avant le projet). Il est donc nécessaire de {{:departement_info:personnels:pb:cpi:conduite du changement.pdf|conduire le changement}}, ce qui passe par différents {{:departement_info:personnels:pb:cpi:éléments de conduite du changement.pdf|éléments}}, une personne chargée de conduire le changement, {{:departement_info:personnels:pb:cpi:manager de transition.pdf|le manager de transition}} et {{:departement_info:personnels:pb:cpi:vision du projet.pdf|une vision partagée du projet}}. | Le changement est à la fois porteur d'espoir (le projet va répondre aux attentes) et de crainte ({{:departement_info:personnels:pb:cpi:changements.pdf|de nombreux aspects peuvent être contrariés}} ou remis en cause par l'exploitation d'une solution qui n'existait pas avant le projet). Il est donc nécessaire de {{:departement_info:personnels:pb:cpi:conduite du changement.pdf|conduire le changement}}, ce qui passe par différents {{:departement_info:personnels:pb:cpi:éléments de conduite du changement.pdf|éléments}}, une personne chargée de conduire le changement, {{:departement_info:personnels:pb:cpi:manager de transition.pdf|le manager de transition}} et {{:departement_info:personnels:pb:cpi:vision du projet.pdf|une vision partagée du projet}}. |
=== Références du domaine === | === Références du domaine === |
| |
Le {{:departement_info:personnels:pb:cpi:PMBOK v3.pdf|corpus des connaissances en gestion de projet}} ou PMBOK (//Project Management Body Of Knowledge//) rassemble tout le savoir, les informations et les bonnes pratiques pour piloter tous types de projets dans les meilleures conditions en développant {{:departement_info:personnels:pb:cpi:5 groupes de processus.pdf|cinq groupes de processus}} décrits dans cette {{:departement_info:personnels:pb:cpi:synthèse PMBOK v5.pdf|synthèse}}. | Le {{:departement_info:personnels:pb:cpi:PMBOK v6.pdf|corpus des connaissances en gestion de projet}} ou PMBOK (//Project Management Body Of Knowledge//) rassemble tout le savoir, les informations et les bonnes pratiques pour piloter tous types de projets dans les meilleures conditions en développant {{:departement_info:personnels:pb:cpi:5 groupes de processus.pdf|cinq groupes de processus}} décrits dans cette {{:departement_info:personnels:pb:cpi:synthèse PMBOK v5.pdf|synthèse}}. |
| |
Le [[https://www.pmi.org/explore|Project Management Institute]] propose des formations et différentes {{:departement_info:personnels:pb:cpi:certifications PMI.pdf|certifications dans le domaine de la gestion de projet}}. | Le [[https://www.pmi.org/explore|Project Management Institute]] propose des formations et différentes {{:departement_info:personnels:pb:cpi:certifications PMI.pdf|certifications dans le domaine de la gestion de projet}}. |
== Exercices == | == Exercices == |
| |
{{:departement_info:personnels:pb:cpi3:exercice FBS.pdf|hiérarchie des fonctions (Function Breakdown Structure)}}\\ | {{:departement_info:personnels:pb:cpi4:exercice FBS.pdf|hiérarchie des fonctions (Function Breakdown Structure)}}\\ |
{{:departement_info:personnels:pb:cpi3:exercice cas d'utilisation.pdf|diagramme de cas d'utilisation}}\\ | {{:departement_info:personnels:pb:cpi4:exercice cas d'utilisation.pdf|diagramme de cas d'utilisation}}\\ |
{{:departement_info:personnels:pb:cpi3:exercice diagramme de déploiement.pdf|diagramme de déploiement}}\\ | {{:departement_info:personnels:pb:cpi4:exercice diagramme de déploiement.pdf|diagramme de déploiement}}\\ |
{{:departement_info:personnels:pb:cpi3:exercice PBS.pdf|arbre-produit (Product Breakdown Structure)}}\\ | {{:departement_info:personnels:pb:cpi4:exercice PBS.pdf|arbre-produit (Product Breakdown Structure)}}\\ |
{{:departement_info:personnels:pb:cpi3:exercices de planification et ordonnancement.pdf|planification et ordonnancement}}\\ | {{:departement_info:personnels:pb:cpi4:exercices de planification et ordonnancement.pdf|planification et ordonnancement}}\\ |
{{:departement_info:personnels:pb:cpi4:exercice developpement itératif.pdf|développement par itération}} et {{:departement_info:personnels:pb:cpi4:découpage fonctionnel fin.pdf|les conclusions à en tirer}}\\ | {{:departement_info:personnels:pb:cpi4:exercice developpement itératif.pdf|développement par itération}} et {{:departement_info:personnels:pb:cpi4:découpage fonctionnel fin.pdf|les conclusions à en tirer}}\\ |
{{:departement_info:personnels:pb:cpi:exercice estimation.pdf|réunion d'estimation}}\\ | {{:departement_info:personnels:pb:cpi:exercice estimation.pdf|réunion d'estimation}}\\ |
* analyse de l'existant (avant projet) (contexte, situation de départ) | * analyse de l'existant (avant projet) (contexte, situation de départ) |
* description du projet (travail à faire pour améliorer ou corriger l'existant = présentation du besoin) | * description du projet (travail à faire pour améliorer ou corriger l'existant = présentation du besoin) |
* objectifs (tous, pas seulement ceux qui restent à satisfaire si le projet est commencé) | * objectifs (tous, pas seulement ceux qui restent à satisfaire si le projet est commencé - diagramme de cas d'utilisation) |
* description du ou des processus concernés, voire évolution des processus (processus impacté·s et en quoi - représentation de processus par diagramme d'activité) | * description du ou des processus concernés, voire évolution des processus (processus impacté·s et en quoi - représentation de processus par diagramme d'activité) |
* contraintes | * contraintes |
* de la qualité du produit (planification des tests, recette) | * de la qualité du produit (planification des tests, recette) |
* analyse financière (estimation des coûts, retour sur investissement) | * analyse financière (estimation des coûts, retour sur investissement) |
* architecture informatique (applicatifs, serveurs, équipements et impacts du projet - suppressions, mises à jours, ajouts) | * architecture informatique (applicatifs, serveurs, équipements - diagramme de déploiement) |
| |
| |
**Les projets seront soutenus oralement le matin du 2 juin 2022 pendant 30 minutes**. Ce temps comprend la présentation du travail (avec partage du temps de parole entre les membres de l'équipe) et un échange au cours duquel l'équipe devra répondre aux questions posées. Les soutenances orales pourront être finalisées en début de matinée le 2 juin 2022 avant les soutenances proprement dites (prévues à 10h30). | |
| |
Le document projet sera finalisé l'après-midi du 2 juin 2022 (de 15h à 17h) en fonction des remarques formulées et des questions posées lors de la soutenance. | |
**Le document devra être remis pour le 2 juin 2022 à 23:59 au plus tard**, par courrier électronique intitulé "rapport projet NSY115" adressé à philippe.brutus@supavenir.fr sous forme d'un fichier joint au format de document portable d'Adobe (pdf). | |
| |
== Equipes == | |
| |
1) T² : Thomas Fontaine--Tuffery et Thomas Holley\\ | |
2) @ : Alexis Leroux et Thomas Leconte\\ | |
3) BC : Benjamin Chénegrin\\ | |
| |
== Sujets == | |
| |
1) Gestion de tickets\\ | |
2) Gestion de PEC en SAV\\ | |
3) Migration de serveurs avec virtualisation\\ | |
| |
---- | |
| |
=== Examen === | === Examen === |
| |
L'écrit surveillé comprend des exercices de gestion de projet classique (réseau des antécédents, courbe de charge, diagramme de Gantt...) et/ou agile (plan de livraison, tableau de suivi, courbe du TAF, courbe de la valeur du produit livré...). | L'écrit surveillé comprend des exercices de gestion de projet classique (réseau des antécédents, courbe de charge, diagramme de Gantt...) et/ou agile (plan de livraison, tableau de suivi, courbe du TAF, courbe de la valeur du produit livré...). |
| |
L'examen est prévu le 3 juin 2022 de 13:30 à 16:00. | |
| |