Corrigé de l’examen Cours Génie Logiciel glg105 Année universitaire 2006-2007 – Deuxième session : 21 avril 2007





télécharger 89.53 Kb.
titreCorrigé de l’examen Cours Génie Logiciel glg105 Année universitaire 2006-2007 – Deuxième session : 21 avril 2007
date de publication11.02.2018
taille89.53 Kb.
typeExam
e.20-bal.com > documents > Exam

Corrigé de l’examen Cours Génie Logiciel GLG105

Année universitaire 2006-2007 – Deuxième session : 21 avril 2007

Etude de cas 12 points ( + 4 points de bonus)



Voir également le corrigé de la 1ère session.
Question N°1 (3 points) : Justification économique d’une saisie élaborée

Pour justifier le choix d’une solution élaborée, le MOA a proposé à sa direction générale de raisonner comme suit :

Un écran ergonomique, avec une saisie souple et des messages d’aide appropriés permet à l’agent de comprendre l’interface sans difficulté. Si ce n’est pas le cas, l’agent doit disposer de documentation en ligne et/ou papier, il doit pouvoir faire appel à un référent du service support (centre d’appels, courrier électronique, etc.), ou encore demander des explications à ses collègues de l’agence plus expérimentés que lui (dans ce cas l’agent en formation fait perdre du temps à ses collègues).

Dans tous les cas de figure le MOA estime le coût de ce support comme suit : 1 référent par agence pendant un temps significatif pour former sur place les agents : 3 mois, 6 mois, x mois.
1.1) Sachant qu’il y a 20 à 50 agents par agence, quelle est la durée que vous recommandez ? Justifier votre réponse par un raisonnement et un calcul.

Exemple de calcul : si le référent consacre ¼ d’heure par intervention pour un agent, en une journée de 7 heures, il pourra effectuer interventions, en moyenne, par jour.

Faites un calcul avec 5 minutes, avec 10 minutes, avec 20 minutes.
Sur la base de ce calcul, en 3 mois, soit 60 jours, le référent d’une agence pourra effectuer 1800 interventions de ¼ d’heure chacune. En 6 mois, 3600 interventions.
Faisons une estimation moyenne en prenant le même nombre d’agents par agence, soit : agents par agence. Dans un projet réel le MOA disposerait de toutes les données des ressources humaines (RH) permettant un calcul précis.

Dans un premier temps, le référent peut regrouper les agents en petits groupes de 8-10 personnes pour une formation générale, puis dans un deuxième temps répondre au cas par cas, agent par agent. Avec 35 agents le référent peut constituer 4 groupes de 8-9 personnes.

En prenant 3 jours de formation par groupe, cela fait 12 jours de formation pour les 4 groupes ; si l’on ajoute un temps de préparation pour le référent, plus un bilan par groupe, cela fait déjà 1 mois de présence (20 jours ouvrés). Ce faisant le référent peut espérer que les agents poseront moins de questions, mais que celles-ci nécessiteront des réponses un peu plus longues.

Dans un second temps, le référent répond au cas par cas, en fonction des difficultés rencontrées par les agents. Ces difficultés sont de deux ordres :

1) Celles qui concernent les écrans et les champs de saisie, soit 120 écrans  10-15 champs par écran = 1440 informations élémentaires ; arrondissons à 1500.

2) Celles qui concernent les 50 workflows, chaque workflow mettant en œuvre plusieurs écrans qui s’enchaînent selon une logique que l’agent doit comprendre (NB : dans le langage du MOE, un workflow est représenté par un ou plusieurs diagrammes d’activités, de séquences et/ou d’états - transitions).

Selon la durée des interventions (5, 10, 20, 30 min), le nombre d’interventions que le référent peut faire par jour est de :


Durée

Jour ouvré théorique de 7 h = 420min

Jour ouvré réel de 6 h (+1h repos) = 360min

Remarques

5 min

84

72

Très court = questions précises et brèves + réponses idem (20%)

10 min

42

36

Questions simples (30%)

20 min

21

18

Questions nécessitant une explication sérieuse (30%)

30 min

14

12

Questions complexes nécessitant une analyse complète de la question et une explication détaillée (20%)


Si l’on fait une moyenne pondérée, cela fait, pour 100 interventions, une durée moyenne de , soit 16 min par intervention et par jour ouvré, soit : interventions du référent par jour.

Le nombre d’interventions demandées par les agents dépend : a) de la complexité des écrans (120 écrans ; 10-15 champs par écrans) et de la complexité des workflows (50 workflows + qq. workflows spécifiques à définir par l’agent) ; et b) de la compétence et du sérieux de l’agent.

Un calcul simple serait : 1 intervention par écran et par agent,

soit :

Ce calcul est certainement pessimiste pour ce qui concerne les interventions du référent, car on peut supposer que les connaissances vont se diffuser chez les agents et que ceux-ci (si l’ambiance et les relations humaines sont bonnes) vont s’entre aider, ce qui diminuera les interventions à la charge du référent. On peut diviser ces 9 mois par 2 ou 3 (dans le meilleur des cas), mais certainement pas plus ; soit une présence de l’ordre de 3 à 4 mois par agence ; soit pour l’ensemble des agences un coût de l’ordre de :

.

A l’inverse, si le niveau de formation des agents est faible (ou s’ils sont peu motivés), et/ou si l’interface IHM est mal conçue, il peut y avoir plusieurs questions par écran et une pondération différente pour le calcul de la durée moyenne des interventions du référent, par exemple : 5%, 20%, 25%, 50% (les agents passent sans transition d’un travail sur papier à un travail sur écran avec dématérialisation complète). Le coût évoluera en conséquence.

A ce calcul, il faudrait ajouter les workflows.
1.2) Sachant qu’il y a 120 écrans, et que tous les écrans doivent au final être connus de tous les agents de l’agence, peut-on en déduire une durée moyenne de séjour du référent dans l’agence ?

Exemple de calcul : 1 mois calendaire = 20 jours ouvrés = 600 interventions de ¼ d’heure.
Voir ci-dessus. Au calcul précédent, il faudra rajouter les workflows. Pour l’assimilation d’une procédure de gestion, i.e. un workflow particulier, il faut que la procédure métier ait été formalisée, par exemple sous la forme d’un cas d’emploi en UML, sous une forme compréhensible par l’agent (ce qui n’est certainement pas le cas du langage UML fait pour les informaticiens chevronnés). C’est un travail qui doit être fait par les référents, avant leur intervention dans les agences. Pour un workflow particulier, la durée d’une intervention sera de l’ordre de 30 à 45 min, soit pour 50 wrkfl 1500 à 2250 min, soit 25 à 38 h, soit 4 à 6 jours ouvrés par agents. Soit pour une agence, en moyenne (35 agents), 140 à 210 jours ouvrés ; soit  300 à 400 pour l’ensemble des agences. NB : on peut appliquer les mêmes règles de réduction que ci-dessus, avec les mêmes conditions restrictives.
1.3) Au final, quel va être le coût de mise en place de ce support ?

Exemple de calcul : 1 référent par agence pendant 3 mois va coûter pour 300/400 agences .
On voit que le coût humain de ce changement est très important, au minimum 100 ha ; ce qui en utilisant le barème du vade-mecum du chef de projet permettrait, en théorie, de fabriquer 400 KLS (avec la productivité de base du vade-mecum, soit 4 KLS par ha). Ce qui montre que le MOA a vraiment intérêt à investir dans l’IHM de cette nouvelle application. En ne prenant que 50% de ce coût, on voit que le MOA peut financer sans problème la réalisation d’une IHM ergonomique (qui est l’interface fondamentale pour la qualité telle que perçue par les agents, mais pas nécessairement celle que perçoivent les programmeurs), en étant toutefois très vigilant sur la compétence et l’expérience de l’architecte et des programmeurs du serveur PT.
Question N°2 (Bonus 2 points) : Suite de la question N°1 ; le coût complet du projet.

Si l’on raisonne en coût complet (ce que le MOA doit évidemment faire), il faut intégrer d’autres coûts au calcul précédent, en particulier :

  • Le coût de formation des référents par l’équipe MOE en charge de la réalisation.

  • Le coût de la perte de temps au niveau de chaque agent (pendant qu’il se fait expliquer les écrans ou les workflow, il ne fait pas son travail).

  • Le coût d’attente et de la perte de temps des usagers clients des agences (Si 1000 personnes sur 3 mois ont perdu en moyenne ¼ d’heure, cela fait 250 heures !!!), donc de la mauvaise qualité de service (i.e. l’administration transfère ses coûts chez ses usagers).

en plus du coût de support aux agents que l’on vient de calculer.

Faites une estimation de ce coût complet, en expliquant votre raisonnement et vos calculs de coûts.
Avec 1 référent par agence, il faut 300 à 400 référents pour toutes les agences. Faisons un raisonnement avec 300 référents.

Par définition, un référent doit connaître à fond chacun des écrans et chacun des workflows. Soit pour 200 écrans et 1h de formation par écran, 200h de formation ; et pour 50 wrkfl à 2h chacun, 100h de formation. Au total 300h, soit 50 jours ouvrés. Si l’on prend en compte que les référents sont bons et que la vitesse d’acquisition des connaissances augmente régulièrement avec le temps (par exemple, selon une progression géométrique), on peut diviser ce chiffre par 2, ce qui fait encore 25 jours, soit, en gros, un mois complet de formation (ce qui n’est pas du tout excessif pour ce type de système).

Pour l’efficacité de la formation des 300 référents on ne peut évidemment pas tous les réunir et les former en une fois. Il faut procéder par étape, par exemple comme suit :

  • Etape N°1 : préparation du kit de formation des référents par l’équipe MOE (sur la base 1 jour de formation = 2 à 3 jours de préparation).

  • Etape N°2 : formation d’un premier groupe de référents (NB : on sélectionne les meilleurs pédagogues) qui vont former leurs collègues. Ce 1er groupe ne doit pas faire plus de 20 à 25 personnes.

  • Etape N°3 : les référents « formateurs » forment leurs collègues, soit 20 groupes de 10 à 15 personnes, en parallèle dans chacune des régions. Les formateurs MOE restent en support de ces groupes pour répondre aux questions difficiles. A l’issue de l’étape N°3, tous les référents sont formés et peuvent se préparer à aller dans les agences.

  • Etape N°4 : les formateurs MOE et les formateurs référents du 1er groupe définissent les documents qui serviront aux référents et aux agents, ainsi qu’une première liste de FAQ (Frequently Asked Questions) pour aider les agents.

Le coût de ces 4 étapes peut s’établir comme suit :

Etape

Coût


Remarques

E1

25j 2 = 50j de préparation

Il faut additionner le coût de préparation et le coût du 1er cours

E2

+ coût du 1er cours (20 personnes) = 25j (avec les formateurs MOE) + bilan (5 hj) ; soit 30 hj.

au total pour E1+E2 = 80 hj.

+ faire un bilan et modifier si nécessaire les supports pour préparer l’étape E3.

Le bilan est compté à 5hj, ce qui est peu, mais c’est la MOE qui fait le travail.

E3

20 groupes de 10 à 15 personnes pendant 25 jours, cela fait 30025 = 7500 journées de formation.

On aura a l’issue de E3, 1 formateur référent par région.

E4

Un séminaire final pour les formateurs référents, avec les formateurs MOE, et validation des kits de formation ; soit 30 personnes pendant 5 jours = 150 hj

Les référents agence doivent être autonomes, et ne remonter aux référents régions que de façon exceptionnelle.

La MOE aura été remplacée en fin de projet par un support + une équipe de maintenance (éventuellement en TMA offshore).

Total :

7730 hj ; soit  35 ha





NB : on voit que si ce travail de formation n’a pas été comptabilisé dans les coûts projet du MOE, le MOA va être dans une situation très difficile lors du déploiement du système.
12 à 15000 agents mal formés vont générer des pertes de temps considérables et générer des temps d’attente et des erreurs insupportables pour les usagers.

Un calcul simple, sur 1 mois, permet d’estimer la productivité des agents comme suit : 12000 agents  20 jours ouvrés = 240.000 journées-agent. Si la perte de productivité imputable à un manque de formation est de 30% (c’est à dire que ce que l’on pourrait faire en 20 min, est fait en 30 min !!! ), cela fait une « perte » (ou un non gain) de 72.000 heures, soit 12.000 journées (comptées à 6 heures).

En coût complet, l’intérêt de l’IHM ergonomique est encore plus évident.
Question N°3 (3 points) : Analyse du coût du serveur d’agence et du PT.

La programmation a été estimée à 130 KLS par les experts qui ont fait le devis.

Faites un calcul d’effort et de durée en utilisant COCOMO, avec comme hypothèses : 1) le code est de type S ; et 2) le code est de type P. Faites ces deux calculs.

Le coût probable sera entre les deux.

Les experts ont fait une première estimation avec une pondération de 80% de code S et 20% de code P. Faire le calcul de l’effort correspondant.

Dans une seconde estimation ils ont rectifié l’équation d’effort comme suit  ; faites le calcul de l’effort correspondant.

En fonction de la maturité et de l’expérience des programmeurs, quelle est la marge d’erreur de ces estimations (cf. le tableau COCOMO en annexe).
Effort pour type S :

Effort pour type P : , soit 75% de plus que S

Effort avec pondération S et P :

Effort avec équation ajustée :

Entre ces deux valeurs, l’écart n’est que de 4ha, soit 10%, ce qui est dans l’incertitude du modèle COCOMO.

L’incertitude liée à la maturité de l’équipe est estimée à partir du tableau des facteurs de coût en annexe, soit :

a) en prenant les facteurs ACAP, AEXP et PCAP, dans la colonne « low », soit : , soit 60%.

b) en prenant seulement les facteurs ACAP et AEXP (i.e. facteurs concernant l’architecte), soit : , soit 35%.

Sur une base de 40 ha l’incertitude est de 15 à 20 ha en plus.
Question N°4 (3 points) : Impact de l’inexpérience de l’équipe sur les coûts, qualité, délai du logiciel du serveur agence PT.

Du fait de son inexpérience, l’équipe en charge du développement du PT a mal factorisé le code de l’IHM, en particulier pour tout ce qui concerne les messages pour les aides en lignes, les méthodes d’affichage à l’écran (interface graphique), l’envoi et la réception des messages vers les autres serveurs (départemental et/ou régional, national).

En pensant gagner du temps l’équipe n’a pas géré son code avec un outil de gestion de configuration, ; chacun a créé ses propres bibliothèques.

Par contre, l’équipe qui connaît bien UML et l’environnement JAVA, a trouvé en « OPEN Source » un outil qui permet de générer du code source JAVA à partir des descriptions des écrans d’affichage réalisés à l’aide de diagrammes UML. Le code source fabriqué à partir de cet outil a une taille d’environ 250 KLS, mais compte tenu des limitations de l’outil que les programmeurs découvrent en l’utilisant (comme beaucoup de logiciel en Open Source, la documentation est succincte), ceux-ci sont obligés de faire des retouches à la main pour incorporer le code qui n’a pas été généré par cet outil. C’est ce code final, avec ses retouches qui est utilisé pour les tests unitaires, ainsi que pour les tests d’intégration et de recette.

4.1) Selon vous, l’absence d’outil de gestion de configuration a t-il un impact : a) sur le facteur de coût de l’équation d’effort ; b) sur le facteur d’échelle ; c) sur les deux à la fois. Répondez par OUI ou par NON, en justifiant votre réponse.

Choisissez les valeurs de ces deux coefficients qui vous paraissent le mieux exprimer cet impact.

4.2) Comment calculer l’effort de développement de ces 250 KLS sachant qu’une partie de ce code a été généré automatiquement par l’outil Open Source trouvé par les programmeurs ? Vous ferez l’hypothèse que la taille de ce qu’ont réellement écrit les programmeurs est 130 KLS.

4.3) Quelle erreur commet le responsable de l’équipe s’il applique COCOMO uniquement sur les 130 KLS programmées par l’équipe ?

Conseils : Faites d’abord un calcul avec 250 KLS et les coefficients que vous avez choisis. Le coût réel est forcément inférieur. Faites ensuite l’ajustage en utilisant au choix la règle 40-20-40 du Vade-mecum, ou les tableaux COCOMO de ventilation des efforts par phase.
4.1 a) OUI – Faible influence sur le facteur de coût. L’absence de GC ralentit les phases de TU et d’intégration car le diagnostic des défaillances et la correction des défauts prend plus de temps. Les références croisées entre les données et le code source sont gérées à la main, à partir des tables produites par le compilateur, mais celles-ci sont insuffisantes pour ce qui concerne les relations entre les classes ; le travail se fait plus lentement et la fiabilité est moindre. Pour se faire une idée de l’impact possible, on peut utiliser les facteurs de coût MODP et TOOL dans l’annexe, soit , soit 20%. Le facteur nominal 2,4 est à augmenter de 10 à 20%, soit 2,6 à 2,9.

4.1 b) OUI – Influence certaine sur le facteur d’échelle, car l’absence de GC oblige les programmeurs à communiquer entre eux, 2 à 2, 3 à 3, etc. (cf. le chapitre GC du cours) pour gérer les interfaces et les données partagées ; ceci étant, cela ne justifie pas de prendre le facteur d’échelle P à 1,12, car l’algorithmique reste simple. Il faut choisir une valeur entre 1,05 et 1,12, soit une écart de 0,07. Si l’on considère que les relations entre les programmeurs jouent pour moitié dans ce coefficient (soit 0,035), on peut ajuster à 1,085 ; si on considère que c’est plutôt 1/3 (soit 0,023), on peut ajuster à 1,073.

NB : compte tenu de l’incertitude du modèle les 3èmes décimales n’ont pas grand sens ; on peut simplifier en prenant 1,07 ou 1,08. Le modèle COCOMO II, mis a jour en 2001, donne des moyens de faire ces ajustages en fonction d’un paramètre de maturité des équipes basé sur le modèle CMM.

Au final, on choisira une équation ajustée :

4.2 – Il faut partir de l’estimation faite par les experts MOA à 130 KLS qui a permis d’organiser le projet au démarrage, sachant que, compte tenu des choix de l’équipe, l’hypothèse 130 va devenir, en cours de projet, une réalité de 250 KLS.

Nous allons utiliser le modèle COCOMO avec les phases, car la précision sera meilleure qu’avec le vade-mecum (cf. la table 6.8 dans le polycopié, Tome 2) ; on prend la colonne « large » en pondérant les lignes S et P.

L’effort, avec notre équation rectifiée est :

  • Pour H-130

  • Pour H-250

On peut raisonner comme suit :


Phase

%

H-130

H-250

Réel

Remarques

CG

16

86

174

86

Le projet part sur l’hypothèse des experts H-130

CD

24

129

261

65

On utilise la CG pour générer le code avec l’outil Open Source. L’effort CD sera moindre (prenons 50%), mais on ne fera pas la factorisation du code, d’où inflation du code. Gain apparent de 215-151=65hm.

P-TU

32

172

349

1720,5+

3490,5

=260

En faisant une répartition 50-50 entre P et TU, on a en réel l’intégralité TU de H-250 et la programmation de H-130.

IVVT

28

150

305

305

On a l’intégralité de H-250.

Total :




537

1089

716

La sous-estimation est de 179hm, soit 15ha


Moralité : L’équipe est passée, sans s’en rendre compte, d’un projet calibré initialement à 130 KLS, mais qui va se terminer dans un projet qu’il aurait fallu calibrer à 250 KLS. Le paradoxe de la situation est que l’équipe, à l’issue de la phase CD, va même paraître en avance sur les prévisions ; le MOE peut à juste titre, sur la foi de son équipe, réduire les ressources car il va penser que l’avance va continuer !!! ce serait une erreur absolument fatale au projet (151 hm ont été consommés au lieu des 215 prévus par les experts, soit une économie de 40%), car elle entraînerait une réduction d’effectif de l’équipe qu’il faudra renforcer en catastrophe un peu plus tard avec des nouveaux arrivants ne connaissant pas l’application. Cette avance apparente est le résultat du remplacement d’une partie de la CD par un outil de génération (c’est un simple traducteur sans intelligence qui ne fait que transcrire les diagrammes) ; donc le travail de factorisation et de modularité n’a pas été fait. La conséquence est qu’au final, les programmeurs vont se retrouver avec :

  • Plus de code, donc plus d’erreurs,

  • Plus de tests,

  • Une intégration plus complexe, car plus de modules à intégrer.

Il aurait donc été plus judicieux de choisir des outils de tests (moniteur de tests, analyseur de complexité, mesure de couverture, etc.) et de GC qu’un outil de génération de code qui a donné l’impression d’une fausse sécurité. L’erreur des programmeurs débutants a été de ne porter leur attention que sur la partie programmation du projet, en sacrifiant de surcroît une partie de la conception.

C’est malheureusement une situation classique que l’on rencontre dans de nombreux projets.

4.3 – L’impasse du responsable de l’équipe PT est, selon nos calculs, au mieux de 179hm, soit 15ha, soit une dérive de 35%, ce qui est quasiment irrattrapable, même en faisant de nombreuses heures supplémentaires. La situation sera catastrophique si l’effectif a été réduit.
Question N°5 (3 points) : Impact sur les tests.

Les experts qui ont estimé le code JAVA du PT à 130 KLS ont raisonné sur la base de 10 erreurs par KLS dont 2/3 doivent être découvertes dans la phase programmation-tests unitaires, et 1/3 en phase d’intégration.

5.1) Calculer le nombre d’erreurs à découvrir dans chacune de ces phases ?

5.2) Que deviennent ces chiffres quand le code passe de 130 à 250 KLS, sachant que le code généré par l’outil est syntaxiquement correct, mais que la vérification et la validation restent à faire ?

5.3) La stratégie de tests choisie par le responsable de l’équipe est la suivante :

  • Un scénario de test par écran avec différents jeux de données pour les tests unitaires.

  • Un scénario de test par workflow pour les tests d’intégration, avec différents jeux de données.

Dans les deux cas, la validation est faite en analysant le ou les messages générés par le PT vers les autres serveurs.

Que pensez-vous de cette stratégie ? Est-elle suffisante, ou insuffisante ? Comment choisir les jeux de données pour obtenir une bonne couverture ? Justifier votre analyse.

5.4) Combien de fois faut-il exécuter les tests pour faire correctement la non régression du serveur PT avant de passer en phase d’intégration.
5.1 – 130 KLS  1300 erreurs, dont 870 découvertes en PTU et 430 en IVVT. Le responsable de l’équipe Serveur PT et le chef de projet MOE devront tenir une comptabilité des erreurs découvertes.

5.2 – Avec hypothèse à 250 KLS  2500 erreurs, dont 1650 découvertes en PTU et 850 en IVVT. En toute logique, le générateur évitera qq. erreurs de type syntaxique, mais c’est loin d’être la majorité des erreurs (il faudrait rectifier en fonction des 120 KLS générées sans erreur de syntaxe ; voir les statistiques données dans le cours).

5.3 – Cette stratégie est correcte, mais le facteur déterminant est le choix des données à injecter dans les tests. Pour cela il faut disposer des contraintes sur les données saisies et la façon dont ces données sont manipulées dans les programmes, au moyen des instructions de contrôles IF … ELSE, SWITCH, WHILE, etc. du langage (cf. méthode des couvertures dans le cours). Avec le code généré, il y aura une difficulté additionnelle car le programmeur devra analyser et comprendre ce code pour produire les TU, donc productivité moindre.

5.4 – Les 120 écrans sont à priori indépendants (ils fonctionnent comme des transactions) ; ils peuvent être testés séparément. Le problème va venir des workflows qui enchaînent les écrans. Les programmeurs doivent construire une table de croisement (i.e. le produit cartésien) de l’ensemble {workflow (50), écrans (120)}, soit 6.000 éléments, afin de savoir quels écrans sont utilisés dans quels workflows, soit un matrice comme suit :



Liste des écrans

Liste des workflows

E1

E2



E120

W1













W2





























W50













Si l’on a 50 scénarios de tests de workflows, un calcul « brutal » conduirait à penser que le nombre d’exécutions des scénarios serait , soit un coût de non régression très élevé. Ce calcul pessimiste fait l’hypothèse d’une interdépendance totale. En fait les écrans et les scénarios de workflows sont très probablement structurés (bien qu’il n’y ait pas d’information dans ce sens dans l’énoncé de l’étude de cas).

En faisant jouer ces relations de connexité, dont la connaissance seraient grandement facilitée par un outil de GC, on peut ne travailler que sur des ensembles de 10 à 15 scénarios, soit une combinatoire qui devient raisonnable : ou

Là encore on voit toute l’importance d’une bonne structuration (c’est le rôle de la CD) et de la GC qui documentent cette structuration (matrice de traçabilité) et permet une analyse d’impact fine permettant de savoir qui modifie quoi !!!
Question N°6 (Bonus 2 points) : Impact d’une initiative contestable des programmeurs.

Pour compenser le retard occasionné par l’inflation des lignes de code, l’équipe PT n’a pas fait tous les tests qu’elle aurait dus faire. En conséquence, moins d’erreurs ont été corrigées, et de nombreux défauts qui auraient dû être découverts sont restés dans le code qui va aller en intégration, puis être installé.

6.1) Calculer le nombre d’erreurs découvertes si l’effort de test est réduit de 50%. Justifier votre réponse.

6.2) Quel est l’impact sur le nombre d’erreurs à découvrir en intégration et sur la suite du projet en termes de coût, délai et qualité ? Peut-on faire une estimation du nombre d’erreurs qui seront découvertes par les agents en exploitation ? Expliquer votre réponse.
Une réduction de l’effort de tests va laisser filer beaucoup d’erreurs vers les phases aval, et finalement chez les agents qui vont avoir une très mauvaise surprise (mauvaise qualité, contrat de service dégradé, nombreuses erreurs de données, perte de temps et perte de confiance dans l’application, etc.) et vers les équipes support et maintenance qui vont devoir intervenir avec une grande fréquence, qu’il faudra redimensionner si l’on veut préserver la qualité du service rendu aux agents. Sur une base de 2500 erreurs, on risque d’en avoir 1000 résiduelles, soit un taux de 4 erreur par KLS très mauvais.

ANNEXE COCOMO (Facteurs de coût)


Ratings/Niveaux

Facteurs de Coûts

Cost Drivers

Very

Low

Low

Nominal

High


Very

High

Extra

High

Product Attributes (Complexité de l’application et/ou du produit à réaliser

RELY Required software reliability

DATA Data base size

CPLX Product complexity

.75
.70

.88

.94

.85

1.00

1.00

1.00

1.15

1.08

1.15

1.40

1.16

1.30



1.65

Computer Attributes (Qualité de service du centre de calcul et de l’ordinateur cible)

TIME Execution time constraint

STOR Main storage constraint

VIRT Virtual machine volatility 1

TURN Computer turnaround time






.87

.87

1.00

1.00

1.00

1.00

1.11

1.06

1.15

1.07

1.30

1.21

1.30

1.15

1.66

1.56

Personnel Attributes (Expérience et/ou maturité des programmeurs, individuellement et collectivement)

ACAP Analyst capability

AEXP Applications experience

PCAP Programmer capability

VEXP Virtual machine experience

LEXP Programming language experience

1.46

1.29

1.42

1.21

1.14

1.19

1.13

1.17

1.10

1.07

1.00

1.00

1.00

1.00

1.00

.86

.91

.86

.90

.95

.71

.82

.70




Project Attributes (Processus et/ou méthodes de développement adoptés par le projet)

MODP Use of modern programming practices

TOOL Use of software tools

SCED Required development schedule

1.24
1.24

1.23

1.10
1.10

1.08

1.00
1.00

1.00

.91
.91

1.04

.82
.83

1.10







1 Pour un logiciel donné, la machine virtuelle sous-jacente est la combinaison matérielle et logiciel (OS, SGBD, etc.) nécessaire pour accomplir son exécution.

___________________________________________________________________________

CORRIGE de l’Examen de Génie logiciel – cours GLG105 - deuxième session : 21 avril 2007

similaire:

Corrigé de l’examen Cours Génie Logiciel glg105 Année universitaire 2006-2007 – Deuxième session : 21 avril 2007 iconUniversité de Caen Année universitaire 2006/2007
«La bce aura de plus en plus de mal à justifier des hausses de taux d'intérêt en 2007»

Corrigé de l’examen Cours Génie Logiciel glg105 Année universitaire 2006-2007 – Deuxième session : 21 avril 2007 iconCalendrier universitaire annee 2006-2007

Corrigé de l’examen Cours Génie Logiciel glg105 Année universitaire 2006-2007 – Deuxième session : 21 avril 2007 iconAnnée universitaire 2014–2015 ( Deuxième session )

Corrigé de l’examen Cours Génie Logiciel glg105 Année universitaire 2006-2007 – Deuxième session : 21 avril 2007 iconAnnée universitaire 2007-2008 dedicace

Corrigé de l’examen Cours Génie Logiciel glg105 Année universitaire 2006-2007 – Deuxième session : 21 avril 2007 iconFiche methode n°5- euros courants et euros constants
«comme si» les prix n’avaient pas bougé entre 2006 et 2007. Nous allons donc «tricher» et poser en 2007 le même prix qu’en 2006

Corrigé de l’examen Cours Génie Logiciel glg105 Année universitaire 2006-2007 – Deuxième session : 21 avril 2007 iconAu cours de l’année de la session d’examen (= avant la fin du premier...

Corrigé de l’examen Cours Génie Logiciel glg105 Année universitaire 2006-2007 – Deuxième session : 21 avril 2007 iconLe cours 2006/2007

Corrigé de l’examen Cours Génie Logiciel glg105 Année universitaire 2006-2007 – Deuxième session : 21 avril 2007 iconProfesseur des universités, première classe
«Guerre conflit, société, xvie-xviiie siècles» pour les années 2006-2007, 2007-2008, Paris I

Corrigé de l’examen Cours Génie Logiciel glg105 Année universitaire 2006-2007 – Deuxième session : 21 avril 2007 iconCours de droit administratif (2006-2007)

Corrigé de l’examen Cours Génie Logiciel glg105 Année universitaire 2006-2007 – Deuxième session : 21 avril 2007 iconCompte rendu de la session de qualifications, du lundi 5 février 2007 au jeudi 8 février 2007






Tous droits réservés. Copyright © 2016
contacts
e.20-bal.com