Corrigé Examen (Fichier .doc)

Corrigé Examen ... B/ Exercice 1 : ... Les quatre programmeurs étant de même
niveau, la durée de réalisation (ou charge de travail) des tâches est la même
pour ...

Part of the document


Gestion de Projets ARS - 2011-2012 Corrigé Examen A/ Questions de cours : A1/ Un projet est à l'état prévu lorsque le projet est bien défini, ses
objectifs identifiés, les contraintes (coût, délais) sont estimées et
acceptées. Dans ce cadre (objectifs, coût, délais), on va pouvoir aller
plus loin, c'est à dire planifier le projet : identifier les tâches, leurs
caractéristiques et les ressources pour les réaliser. A2/ Une tâche critique est une tâche qui n'a pas de marge : tout retard
qu'elle prendrait mettrait d'autant le projet en retard. A3/ Rapports intéressants à fournir lorsque le projet est en cours de
réalisation : V Vue d'ensemble > Récapitulatif du projet (% achevé, variation de fin,
variation de coût), V Activités en cours > Tâches en glissement, V Coûts > Tâches dépassant le budget, V Affectations > Qui Fait Quoi Quand (mis à jour à partir des modifications
du projet, permet de continuer à suivre l'avancement), V Charge de travail > Utilisation des tâches, utilisation des ressources
(comme pour la planification). A4/ Par défaut dans Project, lorsqu'on augmente le nombre de ressources
affectées à une tâche de "durée fixe" : Si la tâche est "pilotée par l'effort", le pourcentage de temps que chaque
ressource affecte à la tâche (appelé aussi dans Project "Unité
d'Affectation ou UA) diminue proportionnellement aux ressources ajoutées. Si la tâche n'est pas "pilotée par l'effort", la durée de la tâche ne
change pas mais la charge de travail, et donc le coût, augmentent
proportionnellement aux ressources ajoutées. B/ Exercice 1 : Q1/ Utilisation de la méthode COCOMO, pour avoir le nombre de mois de
travail (1 mois = 160 h.) : |Tâche |MLPS |MII |CF * CC |MII * CF * CC |Nb. mois |Arrondi |
| | | |0,5*1,17 | |travail | |
| | | | | |MII*CC*CF*0,6| |
| | | | | |6 | |
|A |1 |2,8*11,10 = 2,8|0,585 |1,638 |1,081 |2 |
|B, C |1,5 |2,8*1,51,10 = |0,585 |2,556 |1,687 |2 |
| | |4,37 | | | | |
|D |2 |2,8*21,10 =6,00|0,585 |3,510 |2,317 |3 |
|E, F |3,5 |2,8*3,51,10 |0,585 |6,499 |4,289 |5 |
| | |=11,11 | | | | |
|G, H |5 |2,8*51,10 = |0,585 |9,617 |6,347 |7 |
| | |16,44 | | | | |
Les quatre programmeurs étant de même niveau, la durée de réalisation (ou
charge de travail) des tâches est la même pour tous les programmeurs (par
contre, en ce qui concerne les délais de réalisation d'une tâche, il faut
tenir compte du fait que Marie ne travaille qu'à 80%). Ainsi, la tâche B, par exemple, représente 1,687 mois de travail, soit
1,687*160 = 269,92 h. de travail (environ 270 h.). Jean ou Marie, de même
niveau, mettront normalement 270h. pour la réaliser, ce qui représente un
délai de réalisation de : 269,92 / 160 = 1,687 mois "ouvrable" [4 semaines à 40h. / semaine] si c'est
Jean qui la réalise et 269,92 / 128 = 2,109 mois "ouvrable" [4 semaines à 32h. / semaine] si c'est
Marie. Le problème se complique encore, en tenant compte du calendrier (jours
fériés, congés ...). Pour calculer le délai de réalisation (ie. date de fin
- date de début), il vaut mieux utiliser Project qui fait ça très bien.
Donc, ne pas confondre "durée" d'une tâche et "délais de réalisation" !
Dans PROJECT (diagramme de Gantt), c'est la durée qu'il faut renseigner.
Project calculera lui-même le délai de réalisation. Q2/ Voir CORR_Ex1_Q2.mpp Les tâches G et H étant les plus longues et pouvant démarrer tout de suite,
on a intérêt à les faire démarrer tout de suite et leur affecter à chacune
un programmeur à temps plein (par exemple Jean et Pierre). La durée minimum
du projet est 7 mois (durée de G ou H). Restent Abdul et Marie à répartir
sur les tâches A à F. Du fait des ressources disponibles, on ne peut pas
réaliser le projet en 7 mois, donc G et H ne sont pas critiques à priori.
C'est pourquoi j'affecte H à Marie (en raison de son travail à 80%), G à
Jean, A, B, C à Pierre, E et F à Abdul. Ainsi Jean pourra réaliser D aussi.
On obtient une fin de projet au 22/11/2012. J'ai introduit le coût de revient de chaque ressource, afin que PROJECT
calcule automatiquement le coût prévu pour le projet. Les ressources étant
cadres et payées au forfait, elles ne bénéficient pas du supplément de 25%
pour les heures supp. Inutile donc d'introduire ces valeurs. Dans la
réalité, il est même probable que ces heures ne soient pas payées du tout,
mais là, j'ai considéré qu'elles étaient payées au tarif normal (JeanHS
etc...). On remarque qu'il n'y a pas de surallocation des ressources en agissant
ainsi. PROJECT marque en rouge les ressources Boss et BossHS. C'est une
erreur de PROJECT, comme on peut s'en rendre compte en examinant
l'affichage "Utilisation des ressources". A aucun moment ces ressources ne
dépassent 8 h. par jour ! Vous avez intérêt à introduire des ressources correspondant aux HS (JeanHS
etc...), que vous affecterez aux réunions de suivi, comme précisé dans
l'énoncé. Sinon, toutes vos ressources seront "en rouge" et il faudra
vérifier, pour chacune d'elle, s'il n'y a pas de vraie surallocation. Dans l'affectation des ressources aux tâches périodiques, faire bien
attention à affecter la ressource (Boss par exemple) à chaque tâche et non
à la tâche récapitulative. Sinon, Project affectera 8 h. pour chacune des
tâches, même si elle ne dure que deux heures (erreur Project). Q3/ Tâches critiques : C, D, E, F, I d'après Project. En réalité, on peut voir que C n'est pas critique car elle termine le 20/06
et on pourrait la retarder jusqu'au 08/08. G est critique par contre, en
raison de la ressource Jean. En résumé, avec cette affectation des ressources, les tâches critiques sont
D, E, F, G et I. On voit aussi qu'on ne peut pas faire entièrement
confiance à Project pour déterminer ces tâches critiques ni les marges, car
Project ne tient pas compte de l'affectation des ressources et de leur
disponibilité. Il ne prend en compte que les relations entre tâches et les
contraintes sur les tâches qui ont été définies. Marge de A, B, C : (49 jours, desquels il faut retrancher 22 jours de congé
annuel - ie du 20/06 au 08/08 - à répartir sur ces 3 tâches, car c'est
Pierre qui les réalise). Marge de H : 3,5 mois (35 jours - ie du 27/09 au 01/11). Pour l'examen, j'ai considéré comme justes les réponses obtenues à partir
des marges indiquées par Project, car onn'a pas eu le temps de détailler ce
point. Dans la réalité, ce serait incorrect. Il faudrait raisonner ainsi : "Le projet étant planifié comme il est (ie. en tenant compte de
l'affectation des ressources et de leur disponibilité), calculer de combien
on peut retardert la tâche XX sans retarder le projet". C'st cette valeur
qui représente la marge de la tâche. Q4/ Coût de revient des programmeurs : 2*3000/0,8 = 7500 E / mois Pour Marie, il faut entrer cette valeur aussi (7500 E/mois), car dans
Project, le coût à indiquer est le coût de revient de la ressource, et pas
ce qu'il y a sur sa feuille de paie. Marie ne travaille pas le mercredi. Pour réaliser la tâche H que je lui ai
confiée, elle mettra plus de temps pour la réaliser (du 02/01 au 27/09,
pour une tâche estimée à 7 mois en charge de travail). Le coût de revient
de cette tâche vaudra 7 * 7500 = 52500 E. Coût de revient du Chef de Service : 2*5000/0,8 = 12500 E / mois Pour réaliser les tâches du projet, le coût de revient est de 408.613,15 E
(voir CORR_Ex1_Q2.mpp). Q5/ Tout se déroulant comme prévu, il suffit d'indiquer au 09/03/2012 que
ce qui était prévu à cette date a été réalisé pour connaître le pourcentage
d'avancement du projet à cette date. On aura pris soin préalablement de
définir la planification initiale (voir CORR_Ex1_Q5.mpp). On peut lire qu'au 09/03 à 18h, on aura réalisé 2095,08 heures de travail
sur les 8009,45 prévues, soit 26% du projet. On peut aussi lire ce
pourcentage dans les statistiques fournies avec les "Informations sur le
Projet" (travail : 26%, durée : 28%). Q6/ Au 12/03, outre les tâches périodiques et l'intégration, les tâches non
terminées sont les tâches B, C, D, E, F, G et H. Pour ces tâches, la charge
de travail restante au 12/03 est : tâche B : 1,5 mois (2 mois prévus initialement et réalisés à 25%, soit 0,5
mois réalisés), tâche C : 2 mois, tâche D : 3 mois, tâche E : 2,5 mois (5 mois prévus initialement et réalisés à 50%, soit 2,5
mois réalisés), tâche F : 5 mois, tâche G : 4,48 mois (7 mois prévus initialement et réalisés à 36%, soit
2,52 mois réalisés), tâche H : 4,97 mois (7 mois prévus initialement et réalisés à 29%, soit
2,03 mois réalisés). En supposant un dérapage de 20% jusqu'à la fin du projet, les durées
restantes au 12/03 devraient être 1,2 fois plus grandes, ce qui implique
que les tâches dureront : tâche B : 1,5 * 1,2 + 0,5 = 2,3 mois, tâche C : 2 * 1,2 = 2,4 mois, tâche D : 3 * 1,2 = 3,6 mois, tâche E : 2,5 * 1,2 + 2,5 = 5,5 mois, tâche F : 5 * 1,2 = 6 mois, tâche G : 4,48 * 1,2 + 2,52 = 7,90 mois, tâche H : 4,97 * 1,2 + 2,03 = 7,99 mois. En reportant ces nouvelles durées dans CORR_Ex1_Q6a.mpp et en auditant le
projet pour supprimer les surallocations, on obtient le 04/01/2013