Sommaire - iro.umontreal.ca

Sommaire

G.D.L.A. - 0 - Projet CACTUS

Sommaire

Sommaire

Définition du projet [page 05]

Les membres du groupe Le nom du projet Le nom de l'entreprise Le nom de l'entreprise cliente Les infos : sur votre entreprise vues en classes le projet demande par votre client

Les Points de Fonctions [page 11]Calcul de PF Logiciel Justifications Logiciel

Calcul des complexités de traitements Calcul des PF Matériel

Calcul des complexités de traitements COCOMO

Basique Intermédiaire

Description du WBS [page 24]Couche géographique Couche processus Matériel VS Logiciel

Matériel Couche unité administrative Couche physique

Logiciel Couche physique Couche Modules Sous projet


Sommaire

Diagramme de GANTT [page 36]

Ressources humaines Observations

Gestion et contrôle de la qualité [page 40]Pourquoi la qualité ?

Les enjeux de la qualité Les enjeux humains et sociaux Les enjeux économiques

Gestion qualité Gestion contrôle Tableau des procédures de mesures

Gestion de risques [page 45]Les Risques

Risques du projet Estimation de probabilites et dommages Dommages et risques

Choix de la valeur de coupure. Strategie d’aversion.


Sommaire

Rapports de réunions [page 53]

Année Mois Jour

2004 Septembre 20

2004 Septembre 24

2004 Octobre 15

2004 Octobre 16

2004 Octobre 18

2004 Novembre 08

2004 Novembre 12

2004 Décembre 02


Département d’Informatique et de Recherche Opérationnel

IFT3902 Automne 2004

Projet CACTUS

sur le projet CACTUS

Client La ville de SydneyReprésentant légal Sébastien Gagnon

Membres de l’équipe : Yan Bergeron [email protected] Mohammed Rabie Hadj Messaoud [email protected] Duc-Loc Huynh [email protected] Mathieu Kastlé [email protected] Chef de projet Professeur : Yann-Gaël Guéhéneuc

I - Les membres du groupe et leurs adresses électroniques

Yan Bergeron ([email protected])

Mohammed Rabie Hadj Messaoud ([email protected]) Duc-Loc Huynh ([email protected]) Mathieu Kastlé ([email protected]) Chef de projet

II - Le nom du projet

CACTUS => Contrôle Automatisé de CirculaTion Urbaine de Sydney

III - Le nom de l’entreprise

GDLA => Groupe Développement Logiciel Adapté

IV - Le nom de l'entreprise cliente

Ville de Sydney !

V - Les infos : sur votre entreprise vues en classes

Metier

Développement de logiciels

Type PME, dirigé par un groupe décisionnaire

Date de creation

14 Février 1992 à Montréal.

Chiffre d'affaire 4 million $CND

Nombre d'employes

40 collaborateurs dont une quinzaine de codeurs (programmeurs)

La duree et le budget Il s'agit du temps que vous disposeriez pour implanter le projet et du montant que l'administration de votre entreprise vous alloue pour développer votre projet, nous client pouvons revoir ce budget. Notre budget est de 7 millions pour le projet CACTUS et le temps de développement sera de un an et demi.

VI - le projet demande par votre client.

Nous avons à effectuer un projet d'ampleur municipal, visant à rendre autonome la gestion des feux de circulation en fonction des états et besoins du service routier. Le système que nous mettrons au point, pourra s'adapter en fonction des différents besoins, préétablis par la ville (statique) ainsi que de l'état courant du trafique (dynamique).

Le but primaire :

– Améliorer la fluidité du réseau routier. – Offrir une interface Web renseignant sur l’état actuel du réseau

routier (Cette fonctionnalité est optionnelle).

Les buts secondaires – Diminution de la pollution – Diminution du temps de réponse lié aux événements imprévu. – Diminution du temps d'intervention des services municipaux. – Retombées économique positives liées à la décongestion.

Les beneficiaires du systeme (en ordre de priorite)

1. Pompier 2. Ambulance 3. Police 4. Événements spéciaux (accidents, manifestation, défiler...) 5. Circulation civile

Points de Fonctions

- 1 - Projet CACTUS

Points de Fonction

Points de Fonctions

Sommaire Titre PageLes Points de Fonctions 3

Calcul de PF Logiciel 4 Justifications Logiciel 5

Calcul des complexités de traitements 6 Calcul des PF Matériel 7

Calcul des complexités de traitements 7 COCOMO 8

Basique 9 Intermédiaire 10

- 2 - Projet CACTUS

Points de Fonctions

Points De Fonctions :

Le tableau liste les différents points de fonctions utilisées dans CACTUS. Puisque le projet intègre à la fois le côté logiciel et matériel, les deux types de points de fonctions ont été classés dans des tableaux différents, afin de mieux faire ressortir la pertinence.

[Note interne : Tout les PF sont accompagné de leur justifications]

Afin d’établir une idée plus précise de l’ampleur du projet, le Génie Logiciel propose plusieurs modèle de calcule afin d’en estimer les coût, les ressources et le temps nécessaires à la réalisation du projet.

Ainsi, dans la suite du document, il sera question calcules de complexité des traitements et de COCOMO (Basique et Intermédiaire).

- 3 - Projet CACTUS

[Note interne : tout les calculs des points de fonction on été fait sur le schéma de COCOMO intermédiaire]

Points de Fonctions

Calcul des PF logiciels:

- 4 - Projet CACTUS

Point de fonction Appartenance Complexité Type 01) Historique Dépôt Interne C DONNEES 02) Liste des personnes inscrites Dépôt Interne M DONNEES 03) Carte de la ville Dépôt Externe C DONNEES 04) Code de la route Dépôt Externe C DONNEES 05) Afficher le réseau actuel Interrogation C WEB 06) Faire une requête Interrogation C WEB 07) Afficher les résultats Extrant M WEB 08) Identification Interrogation M SOFT 09) Afficher le réseau actuel Extrant C SOFT 10) Modifier le cycle d’un feu Intrant M SOFT 11) Demander la priorité sur un chemin Intrant C SOFT

12) Consulter la Base de Données historique

Extrant C SOFT

13) Ajouter des événements dans la Base de Donnée

Intrant M SOFT

14) Modifier des événements dans la Base de Donnée

Intrant C SOFT

15) Supprimer des événements dans la Base de Donnée

Intrant M SOFT

16) Mise à jour de la carte de la ville Intrant C SOFT 17) Capteurs Transmettre son état Intrant M HARDWARE18) Capteurs Répondre à des requêtes Extrant M HARDWARE19) Feux Transmettre son état Intrant M HARDWARE20) Feux Répondre à des requêtes Extrant M HARDWARE

21) Feux Faire une mise à jour de son programme

Extrant M HARDWARE

22) Feux Exécuter son programme Extrant M HARDWARE23) Routeur Transmettre son état Intrant C HARDWARE24) Routeur Répondre à des requêtes Extrant C HARDWARE25) Routeur Router Extrant C HARDWARE

Points de Fonctions

Justifications des PF logiciels:

- 5 - Projet CACTUS

Point de fonction Justificatif

01) Historique Grande base de données nécessaire, beaucoup d’éléments devrons y être ajoutés.

02) Liste des personnes inscrites Base de données moyenne contenant les informations des personnes et services ayant un compte à CACTUS (administrateurs, services municipaux, …).

03) Carte de la ville Grande Base de donnes contenant toutes les rues et tous les feux de la ville.

04) Code de la route Grande Base de données contenant le code de la route et les emplacements des signalisations.

05) Afficher le réseau actuel La requête d’afficher le réseau actuel est doit avoir un moyen d’accéder à la base de donné historique, ou du moins une partie.

06) Faire une requête Les requêtes faites sur le site nécessitent des traitements complexes. 07) Afficher les résultats L’affichage des résultats sur le site est un extrant moyen.

08) Identification L’identification est une interrogation qui utilise un nombre moyen d’attributs et de fichiers de référence.

09) Afficher le réseau actuel Le nombre de fichier de référence et d’attributs est élevé.

10) Modifier le cycle d’un feu La modification du cycle est une opération a complexité moyenne qui utilise le fichier de référence d’un feu.

11) Demander la priorité sur un chemin

La demande de priorité fait références à plusieurs fichiers de références et attributs, il ne dépend pas que du chemin sur lequel on veut avoir la priorité

12) Consulter la Base de Données historique La complexité augmente suivant la quantité de données.

13) Ajouter des événements dans la Base de Données L’ajout à la base de données n’implique pas un traitement immédiat.

14) Modifier des événements dans la Base de Données

La modification d’un événement dans la base de données implique un changement dans plusieurs fichiers et attributs.

15) Supprimer des événements dans la Base de Données

La suppression d’un événement dans la base de données n’implique que le fichier concerné.

16) Mise à jour de la carte de la ville Mise à jours de plusieurs fichiers de références et leurs attributs 17) Capteurs Transmettre son état

18) Capteurs Répondre à des requêtes

Les requêtes sont primaires, il n’y a pas de traitement entre chaque transmission.

19) Feux Transmettre son état 20) Feux Répondre à des requêtes

21) Feux Faire une mise à jour de son programme

22) Feux Exécuter son programme

Les requêtes sont primaires, il n’y a pas de traitement entre chaque transmission.

23) Routeur Transmettre son état

24) Routeur Répondre à des requêtes

25) Routeur Router

Le besoin de synchroniser les fonctions, donc d’établir des protocoles, avec le routeur rend la tâche complexe.

Points de Fonctions

Tableau de calcul : Composante Simple Moyen Complexe Résultat Intrants ..*2= 3*4=12 3*6=18 30 Extrants ..*4= 1*5=16 2*7=14 30 Dépôts Internes

..*7= 1*10=10 1*15=15 25

Dépôts Externes

..*5= *7=14 2*10=20 34

Interrogations ..*3= 1*4=4 2*6=12 16 Total 135 Complexite des traitements : ID Caractéristiques Degré D’influence 1 Communication des données 4 2 Fonctions distribuées 4 3 Exigences de performances 4 4 Taux de transaction 4 5 Efficacité pour l’usager 5 6 Mise a jour en ligne 5 7 Traitements complexes 5 8 Facilite d’installation 3 9 Facilite d’opération 5 10 Réutilisation 4 1 : sans influence 2 : insignifiante 3 : moyenne 4 : importante 5 : très forte Total des DTI = 43 Facteur d’ajustement = 0.65 + 0.01 * 43 = 1.08

- 6 - Projet CACTUS

PFA = PF * FA = 135 * 1.08 = 145.8

Points de Fonctions

Calcul des PF materielles: Composante Simple Moyen Complexe Résultat Intrants ..*2= 2*4=8 1*6=6 14 Extrants ..*4= 4*5=20 2*7=14 34 Total 48 Total des PF : 48 Complexite des traitements : ID Caractéristiques Degré D’influence 1 Communication des données 5 2 Fonctions distribuées 5 3 Exigences de performances 5 4 Taux de transaction 5 5 Efficacité pour l’usager 4 6 Mise a jour en ligne 5 7 Traitements complexes 5 8 Facilite d’installation 3 9 Facilite d’opération 3 10 Réutilisation 3 1 : sans influence 2 : insignifiante 3 : moyenne 4 : importante 5 : très forte Total des DTI = 43 Facteur d’ajustement = 0.65 + 0.01 * 43 = 1.08

- 7 - Projet CACTUS

PFA = PF * FA = 43 * 1.08 = 46.44

Points de Fonctions

COCOMO :

Hypothèse : les besoins du logiciel sont relativement stables, le projet est géré à la fois par le client et par le fournisseur

Formule d’estimation : Effort = A (KLSL)b • KISL : Kilo Lignes Sources Livrées : ligne source quelque soit le nombre d’instructions par ligne, sans tenir compte des commentaires ni du logiciel support • A et b estimées à partir de l’analyse des historiques • A et b dépendent des trois classes de projet :

• Organique : petites équipes (faible communication, distribution efficace du travail, …), environnement stable, applications bien comprises • Semi-détaché : équipe de taille moyenne (personnes expérimentées, débutants), problèmes ne sont pas tous maîtrisés • Détaché : grande équipe, répartie, nouvel environnement

Le projet est complexe, fortement connecté de matériel et logiciel et présente des contraintes fortes. On peut alors en conclure que c’est un projet de mode Embedded.

- 8 - Projet CACTUS

Points de Fonctions

Basique :

COCOMO basic nous donne les formules d’effort et de durée suivantes :

E = 3.6 * (KLOC) * 1.2 D = 2.5 * E * 0.32 En suppose que le projet sera développé en C et que ce dernier code un point de fonction en 100 linges de code.

On a calculé PF = 145.8 + 46.44 = 192.24 Alors : LOC = 192.24 * 100 = 19.24 KLOC Donc : E = 125.12 Personne Mois D = 11.72 Mois

- 9 - Projet CACTUS

Taille Équipe = 125.12 /11.72 = 11 Personnes

Points de Fonctions

Intermédiaire :

Facteurs d’ajustement :

CACTUS étant un projet de gestion d’une fonction vitale de toute une ville, il est concevable de penser que les contraintes imposé soit forte. Puisque la moindre erreur pourrait engendrer des répercussions non négligeables voir même juridique. Bien que nos équipes soient expérimentées, pour les raisons précédentes, il n’est pas suggéré de trop baisser les contraintes.

- 10 - Projet CACTUS

Attributs matériels

TIME contraintes de temps d’exécution STOR contraintes sur la mémoire de masseVIRT volatilité de la machine virtuelle TURN temps d’utilisation des machines

Attributs du personnel

ACAP capacité des analystes AEXP niveau d’expérience des équipes LEXP niveau d’expérience avec le langage PCAP capacité des programmeurs VEXP niveau d’expérience avec la machine

virtuelle

Attributs du logiciel RELY fiabilité DATA base de données CPLX complexité

Attributs du projet

MODP utilisation de pratiques modernes TOOL niveau d’utilisation d’outils SCED contraintes de temps

Points de Fonctions

ID État Valeur justification RELY Très Haut 1.40 Le système aura pour vocation de gérer, en plus de l’optimalité du

réseau urbain, indirectement la sécurité des citadins. DATA Très Haut 1.16 Le système se veut être dynamique et évolutif, pour ce faire, il

devra emmagasiner le plus d’information possible afin de les anlyser puis de les compiler.

CPLX Haut 1.15 Le système aura pour fonction de gérer divers types d’événements à divers moments et sous diverses contraintes. Les variables possibles se multipliant, cela augmente la complexité du

système. TIME Normal 1.00 Bien que le but du système est de fournir un « Feedback » rapide

des événements. Selon le cahier des charges, la contrainte de réponse en temps réel n’est pas demandée.

STOR Extra 1.56 La gestion se faisant en temps semi réel et au niveau de toute une ville, la mémoire requise au système devra être énorme pour

répondre aux besoins. VIRT Normal 1.00 La portabilité n’est pas une priorité, puisque le système sera

développé sur mesure à la ville de Sydney TURN Très Haut 1.15 Le but du système étant la gestion automatique en tout temps,

éteindre la machine n’est une option envisageable. ACAP Haut 0.86 Les analystes doivent être fiables dans leurs rapports. De

mauvaises statistiques pourraient engendrer des conséquences boules de neiges

AEXP Haut 0.91 Les équipes travaillant sur le système doivent avoir un niveau d’expérience assez important, afin de minimiser les risques

d’erreurs qui pourraient affecter le système. LEXP Haut 0.95 Le langage utiliser sera du C++, les programmeurs travaillant sur

le projet devront avoir une expérience assez haute afin de gérer toutes les exceptions que pourrait retourner un tel langage.

PCAP Haut 0.86 Dût à la grande complexité du système, la capacité des programmeurs doivent s’ajuster en conséquence.

VEXP Normal 1.00 Le langage C++ ayant la particularité d’avoir un code source extrêmement portable, l’expérience sur les spécificités de la

machine virtuelle n’est pas critique. MODP Haut 0.91 Étant toujours à la recherche d’innovations, l’entreprise accorde

une grande importance aux pratiques modernes, tel que l’implémentation des patrons de conceptions dans les codes

produits. TOOL Haut 0.91 Afin de pouvoir utiliser les pratiques modernes décrites ci-dessus,

l’utilisation d’outils adaptés est inévitable. SCED Normal 1.00 La durée du développement ayant été négocié dans le contrat, la

contrainte n’est pas extrêmement critique.


Points de Fonctions

Ces facteurs d’ajustement ont été calculés en se basant sur les échelles de Lickert. FA =1.40 * 1.16 * 1.15 * 1 * 1.56 * 1 * 1.15 * 0.86 * 0.91 * 0.95 * 0.86 * 1 * 0.91 * 0.91 * 1 = 1.94

On a : E = Enominal * FA Donc : E = 242.73 Personne Mois

D = 14.49 Mois

Taille Équipe = 17 Personnes Productivité = 0.07926 KLOC/PM = 79.26 LOC/PM


Work Breakdown Structur

Description du WBS

- 1 - Projet CACTUS


Sommaire

- 2 - Projet CACTUS

Titre PageDescription du WBS 3

Couche géographique 4 Couche processus 5 Matériel VS Logiciel 6

Matériel 7 Couche unité administrative 7 Couche physique 8

Logiciel 9 Couche physique 9 Couche Modules 10 Sous projet 11


Description du WBS :

GDLA est une entreprise spécialiser dans le développement de logiciel. Elle est, par conséquence, principalement constitué d’experts en analyse et développement de logiciel.

CACTUS est un projet qui associe à la fois un développement logiciel,

mais aussi un développement matériel. Puisque le but de ce projet étant de créer un système autonome de gestion des feux de circulation. De ce fait, l’interaction entre le matériel et le logiciel est extrêmement forte.

De plus, puisque GDLA est une entreprise Montréalaise et que le

projet CACTUS sera destiné à la ville de Sydney. Ces deux localisations étant aux antipodes. Les problèmes de coordinations seront mis au premier plan.

Ainsi, le WBS présenté a été réalisé dans l’optique de diminuer le

manque d’expérience en matériel et surtout de diminuer les problèmes inévitables de coordinations.

Le WBS a été découpé :

- Géographique - Unité administrative - Physique - Module - Sous projet

- 3 - Projet CACTUS


1) Couche Geographique :

probleme de coordinations

Géographique

Afin de diminuer au maximum les problèmes de coordination, toutes les tâches ont été localisées dans deux groupes distincts. Les critères ont été les dépendances entre elles. Si deux tâches ont de faibles dépendances, alors elles seront localisées dans des groupes différents, au contraire, lorsque deux tâches ont de fortes dépendances, elles resteront dans le même groupe. En utilisant cette logique, il est apparu que les tâches matérielles et les tâches logicielles n’ont que très peu de dépendances entre elles.

Il a donc été décidé de constituer deux groupes d’expert. Le premier sera constituer d’expert en programmation et restera à Montréal, et le second, constituer d’expert en analyse, sera envoyer à Sydney. Le groupe de programmeur aura l’avantage d’avoir tous les outils nécessaires au développement de logiciel et le groupe d’analyse pourra analyser sur le terrain les besoins et contraintes que présente la ville de Sydney.

- 4 - Projet CACTUS


2) Couche Processus :

processus Materiel vs

processus Logiciel

Comme dis précédemment, tout les processus Logiciel seront du

côté de Montréal, alors que les processus Matériel seront du côté Sydney. Remarque : du côté de Montréal, tout est parfais, tout l’équipement

nécessaire est à disposition des programmeurs. Alors que du côté Sydney, la nécessité d’engager des experts locaux est inévitable. Dans ce cas, les experts locaux travailleront sous la supervision des analystes.

Afin de limiter les dépendances, certains processus apparaissent

deux fois, l’un du côté Sydney et l’autre du côté de Montréal. Par exemple les processus :

- Développement - Tests - Qualité

- 5 - Projet CACTUS


3) Materiel VS Logiciel

La troisième couche est plus ambiguë, du fait des besoins spécifiques que l’on soit du côté matériel ou bien logiciel. En faisant ce type de découpage, le parallélisme a été favori. Puisque à part la tâche de l’intégration, les deux parties n’ont pas vraiment de liens forts entre elles.

- 6 - Projet CACTUS


- 7 - Projet CACTUS

3.a) Cote materiel 3.a.1) Couche Unites administrative

Dans cette couche, les analystes auront à écrire un cahier des charges, analyser l’environnement local et recueillir le plus de statistiques possible toujours pour des fins d’analyses. Mais surtout ils auront à garder des liens forts avec le client jusqu’à la signature du contrat

[Note interne : les relations entre le groupe situé à Sydney et le client devrons sûrement être maintenues jusqu’à la finalisation du projet]


3.a.2) Couche Physique

Pour aboutir le projet, l’aspect matériel aura besoin de trois composantes primordiales, à savoir :

- Les routeurs - Les capteurs - Les contrôleurs

Cette couche sera gérer par l’équipe d’expert locale. Ainsi les problèmes concernant la différence entre les standards matériels de Montréal et Sydney ne ce posera pas.

- 8 - Projet CACTUS


- 9 - Projet CACTUS

3.b) Cote logiciel 3.b.1) Couche Physique

Du côté logiciel, nous constatons trois composantes importantes à créer :

- Le système embarqué - Les protocoles - Le logiciel (lui-même)


3.b.1.1) Couche Module

Lorsqu’il est question de logiciel, la manière la plus courante et aussi la plus logique de détailler est bien entendue de préciser les modules.



3.b.1.2) Le Sous projet

Le client à la première rencontre, avait émis le souhait d’une page web afin que les usagers du système puissent consulter l’état du réseau. N’étant une priorité, ce sous projet a été placé au même niveau qu’un module.


ID Task Name

1 Rédiger le plan de Projet

2 Rédiger le contrat

3 Négocier le contrat

4 Signer le contrat

5 Définir les besoins en convivialité

6 Définir les besoins en robustesse

7 Définir les besoins en sécurité

8 Définir les besoins en performance

9 Définir les besoins en BD

10 Définir les besoins en qualité

11 Étudier le climat local

12 Étudier les infrastructure déjà en place

13 Recueillir des statistique du réseau

14 Écrire le cahier des charges

15 Écrire les spécification du protocole

16 Écrire la spécification du routeur

17 Écrire la spécification du capteur

18 Écrire la spécification du contrôleur

19 Valider les spécifications matériel

20 Dessiner les schémas techniques du routeur

21 Dessiner les schémas techniques du contrôleur

22 Dessiner les schémas techniques du capteur

23 Valider les schémas techniques

24 Commander le matériel

25 Recevoir les prototypes

26 Tester les prototypes

27 Recevoir le matériel

28 Implémenter les algorithmes de routage du routeur

29 Coder le logiciel embarqué du capteur

30 Coder le séquenceur de cycles du contrôleur

31 Tester le matériel (test unitaire)

32 Installer les contrôleurs de feux

33 Installer les Capteurs

34 Installer les serveurs

35 Installer les routeurs

36 Installer le noyau

37 Installer les BD

38 Installer le site Web

39 Concevoir la BD des usagers

40 Construire l'ìnterface de la BD des usagers

41 Concevoir la BD historique

42 Construire l'interface de la BD historique

43 Implémenter la gestion des anticipations d'après l'historique

44 Concevoir la BD évènements

45 Construire l'interface de la BD évènement

46 Implémenter la gestion des contraintes évènementielles

47 Programmer le serveur de communication avec les matériel

48 Implémenter la gestion de l'état actuel

49 Implémenter le parseur de la carte routière

50 Construire l'interface administrateur

51 Construire l'interface des centraux

52 Réaliser les testes unitaire de chaque module

53 Réaliser le contrôle

54 Implémenter la boucle principale du calculateur

55 Lier tous les modules logiciels

56 Tester l'intégration de tous les modules

57 Vérifier la performance du systeme principal

58 Vérifier la fiabilité du système principal

59 Vérifier la robustesse du système principal

60 Vérifier la facilité de MAJ du système principal

61 Tester le système par simulation du matériel

62 Programmer le serveur de requêtes WEB

63 Implémenter l'interface de liaison avec CATUS

64 Concevoir le site WEB

65 Implémenter l'algorithme du mini calculateur

66 Tester le mini calculateur

67 Tester le déploiement de tout le système

68 Vérifier la facilité de MAJ finale

69 Vérifier la performance finale

70 Vérifier la robustesse finale

71 Vérifier la convivialité finale

72 Vérifier la fiabilité final

Yann Bergeron;Mohammed Rabie Hadj Messaoud;Duc Loc Huynh;Mathieu KASTLÉ

Mathieu KASTLÉ

A 1

A 2;A 3

A 4

A 5;A 6

A 10

A 9;A 8

A 10

A 10

A 1;A 2;A 3;A 4;A 5;A 6;A 7;A 8;A 9;A 10;IE 1;P 1

IE 1;IE 2;IE 3;IE 4;A 1;IE 5;IE 6;IE 7;P 1;A 2;P 2

IE 1;IE 2;IE 3;P 2[20%]

IE 4;IE 5

IE 6;IE 7

IE 1;IE 2;IE 3;IE 4;IE 5;IE 6;IE 7

IE 1;IE 2;IE 3

IE 6;IE 7

IE 4;IE 5

IE 1;IE 2;IE 3;IE 4;IE5;IE 6;IE 7

07-15

09-19

IE 1;IE 2;IE 3;IE 4;IE 5;IE 6;IE 7;P 1;P 2;P 3;P 4;P 5;P 6;P 7;P 8;P 9

11-15

P 1;P 2;P 3;P 4

P 5;P 6

P 7;P 8;P 9

IE 1;IE 2;IE 3;IE 4;IE 5;IE 6;IE 7;P 1;P 2;P 3;P 4;P 5;P 6;P 7;P 8;P 9

Service de la ville[50%];P 7;E 6

Service de la ville[50%];E 4;P 6

P10;P 1;P 2

P 3;IE 1;IE 2

P 4;P 5;P 6

P 7;P 8;P 9

P 10

P 7

P 7

P 8

P 8

P 8

P 9

P 9

P 9

P 1;P 2

P 7

P 3

P 4;P 5

P 6

P 6;P 3;P 4;P 5

P 1;P 2[80%];P 3;P 4;P 5;P 6;P 7;P 8;P 9;P 10

P 1;P 2;P 3

P 4;P 5

P 6;P 7

P 8;P 9

P 1;P 2[80%];P 3;P 4;P 5;P 6;P 7;P 8;P 9

P 10

P 10

P 10

P 10

P 10

IE 1;IE 2;IE 3;IE 4;P 1;P 2;P 3;P 4;P 5;P 6;IE 5;IE 6

P 1;P 2

P 3;P 5;P 8;IE 2

P 6;P 7;IE 6;IE 5

P 4;P 6

P 1;P 2;P 3;P 5;P 7;IE 1;IE 2;IE 6

17 24 31 07 14 21 28 05 12 19 26 02 09 16 23 30 06 13 20 27 06 13 20 27 03 10 17 24 01 08 15 22 29 05 12 19 26 03 10 17 24 31 07 14 21 28 04 11 18 25 02 09 16 23 30 06 13 20 27 04 11 18 25 01 08 15 22 29 05 12 19 26 05 12 19 26 02 09 16 23 30 07 14 21 28 04 11 18 25 02 09 16 23 30 06 13 20 27 03 10 17 24 01 08 15 22 29 05 12 19 26 03'04 Nov '04 Dec '05 Jan '05 Feb '05 Mar '05 Apr '05 May '05 Jun '05 Jul '05 Aug '05 Sep '05 Oct '05 Nov '05 Dec '06 Jan '06 Feb '06 Mar '06 Apr '06 May '06 Jun '06 Jul '06 Aug '06 Sep '06 Oct '06 Nov '06

Page 1

Description du GANTT


Diagramme de GANTT


Sommaire


Titre PageDiagramme de GANTT 3

Ressources humaines 3 Observations 4


Diagramme de GANTT :

Le « Diagramme de Gantt », du nom de Henry L. Gantt, permet de représenter les besoins d'un projet en ressources en fonction du temps, par l'intermédiaire d'une liste de tâches représentées par des barres horizontales. Inventé en 1917 et très classique dans les logiciels de gestion de projet.

Ressources humaines :

Pour mener à bien le projet CACTUS, GDLA possède :

- 7 Ingénieurs électriques - 15 Programmeurs - 10 Analystes - 4 Chefs d’équipe



Observations :

Dans le diagramme de GANTT proposé, il y apparaît quatre principale bloques, correspondant :

- 1) L’analyse, l’étude, la définition et la négociation du contrat

- 2) la conception matérielle - 3) la conception logicielle - 4) l’intégration du logiciel avec le matériel

Puisque la conception matérielle et logicielle ne possède pas ou très peut de dépendance entre elles, en fait ces deux bloques ne présentent pas les même besoin et n’ont pas les mêmes affectation en ressources humaines, il est aisé de d’exécuter ces deux bloques en parallèle.

Les seuls principales contraintes, sont déterminer par les bloques 1 et 4. Le bloque 1 étant préalable aux bloques 2 et 3 du fait que la signature du contrat détermine réellement le début des opérations. De même, le bloque 4, qui est l’intégration, détermine la fin des bloques 2 et 3. C’est à se moment que les deux groupes d’équipes se rencontre réellement. Le bloque 4 représente donc la finalisation du projet.


Aussi, il est à souligner que le bloque du côté matériel dure quatre fois plus de temps que le bloque du côté logiciel. De cet inconvénient, un avantage pourrait en ressortir, celui d’avoir des programmeurs codant sans le stress engendrer par des besoins en temps trop court.

Gestion et contrôle de qualité

Gestion et contrôle de la qualité JURAN (né en 1904) souvent considère comme le père de la Qualité fixe les objectifs:

• La mission de toute entreprise humaine est de fournir des produits ou des services qui répondent aux besoins des utilisateurs.

• Ces produits doivent apporter un revenu à l'entreprise qui les produit, sans avoir des effets néfastes pour la société.



Sommaire


Titre PageGestion et contrôle de la qualité 3

Pourquoi la qualité ? 3 Les enjeux de la qualité 3 Les enjeux humains et sociaux 3 Les enjeux économiques 3

Gestion qualité 4 Gestion contrôle 4 Tableau des procédures de mesures 5


Pourquoi la qualite ? Les enjeux de la qualite :

Enjeux opérationnels ou fonctionnels

Tout défaut de conception ou de réalisation peut affecter plus ou moins gravement la fonction d'un produit ou d'un service.

La démarche qualité vise a détecter LE PLUS TOT possible de ces défauts et d'apporter un remède (formalisation des relations client/fournisseur).

ENJEUX HUMAINS et SOCIAUX

Accidents provoques par des défauts de conception, de réalisation et/ou d'utilisation.

Aspects juridiques, voire judiciaires, tensions, litiges d'ou des règlements qui contrôlent: - la sécurité, qui protège le consommateur, la nature et l'environnement.

ENJEUX ECONOMIQUES

Les coûts de la non qualité sont énormes

Ils se répercutent dans le budget des états qui sont a la fois de gros clients, de grands prestataires de services et même souvent de grands industriels.

En France on estime ce coût de 4 à 10% du CA total et même a 10 % de la VA totale

Ces ENJEUX économiques sont tels que l'on parle "d'usine fantôme" ou de "trésor caché". La non qualité se paie dans le prix des produits achetés et ceux vendus à l'exportation. Mais surtout dans la santé et l'avenir des entreprises

Référence pris d’un cours du Professeur Serge Michaud



Gestion qualite :

Application des pratiques du management industriel pour maintenir et améliorer de façon systématique la performance de toute une organisation. L'efficacité et le succés sont mesurés par des mesures quantitatives et qualitatives.

Controle qualite :

Système destiné à vérifier et à maintenir le niveau de qualité souhaité d'un produit ou d'un processus par une planification approfondie, l'utilisation d'un matériel adéquat, une inspection continue et une action corrective si besoin. (Random House Unabridged Dictionary, 2d ed).

Ainsi le tableau qui suit représente des procédures applicables sensé mettre en évidence les points faibles du produit finis, d’en déterminer le degré d’implication puis propose des solutions selon les réponses données.




Procedures de mesure

Resultatspossible

Remede en cas de mauvais resultats

Mesurer le changement de la fluidité du réseau

Favorable Défavorable

Utiliser les statistiques pour mettre à jour des algorithmes plus adapter au réseau routier.

Faire des sondages au prêt des utilisateurs du site web

Favorable Défavorable

Faire une mise à jour du site en ajoutant des fonctionnalités et rendre l’accès plus rapide.

Rapports environnementaux de la ville de Sydney

Effet positifEffet neutre

Effet négatif

Faire appel aux services d’un spécialiste de l’environnement au besoin en tant que consultant.

Sondage au prêt des services de la ville


Effet négatif

Réunir les informations et réserver quelque rues ou trajet au besoin

Sondage au prêt des utilisateurs du réseau routier


Effet négatif

Expliquer que CACTUS est un logiciel qui s’améliore avec le temps grâce à sa base de données dynamique.

Sondage au prêt des touristes


Effet négatif

Repérer les zone les plus viser et améliorer l’accès au besoin.

Formation des analystes Favorable Défavorable

Repérer les points faibles et organiser des formations intensives immédiatement.

Reunions périodique Favorable Défavorable

Prendre les décisions nécessaires pour améliorer le travail

Organiser des visites pour Sydney Favorable Défavorable

Améliorer l’échange d’information entre Montréal et Sydney et rester plus en contact.

Rapport hebdomadaire du déroulement

Favorable Défavorable Prendre les decisions necessaries.

Rapports du trafic à Sydney Favorable Défavorable

Identifier immédiatement les zones défavorisées et adapter le logiciel.

Implantation partielle de CACTUS Favorable Défavorable Faire des changements majeures voir arrêter le projet.

Gestion de risques

Gestion de risques


Gestion de risques

Sommaire


Titre PageGestion de risques 3

Les Risques 3 Risques du projet 4 Estimation de probabilites et dommages 5 Dommages et risques 6

Choix de la valeur de coupure. 7 Strategie d’aversion. 8

Gestion de risques

I – Les Risques

Qu’est-ce qu’un risque ??

Un risque est un événement qui met en péril l’atteinte de nos objectifs de :

- Coût - Echéancier - Performance

Dans l’optique d’éviter de mettre en péril l’un des trois objectifs ci-

dessus. Les tableaux qui suivent représentent une sorte de « Brainstorming » des risques potentiels.

Le tableau I.A est la première étape de la gestion de risque. Ce tableau représente le résultat du « Brainstorming ». Il y inclue aussi les justificatifs, les raisons données à la question « Pourquoi faut-il faire attention à ce risque ??»

Le tableau I.B est la deuxième étape. Ce tableau y ordonne les risques selon la probabilité qu’un risque puisse apparaître.

Le tableau I.C est la troisième étape et dernière étape de l’énumération des risques. Dans ce tableau, le niveau de dommage que pourrait engendrer un risque y est notifié. L’ordonnancement de ce dernier tableau ce fait donc en fonction du risque d’apparition et du dommage d’un risque.

Il est important de noter que chaque tableau possède une justification pour chaque risque. Puisque les valeurs données ne sont empiriques, mais plutôt des estimations données par le groupe sensé gérer les risques. Il est toujours possible d’argumenter les résultats obtenus.

Le tableau III représente des propositions pour minimiser ou bien éviter les risques trouvés dans les tableaux précédant.


Gestion de risques

I.a - Risques du Projet

ID Risque Justification

1 Une autre entreprise (ville) propose le même produit

Plusieurs villes sont exposées aux mêmes problèmes donc très probablement intéressées aux mêmes solutions

2 Nos experts non habitués aux infrastructures de Sydney

Leur infrastructures, code de la route, règlements … ne sont pas les même qu’à Montréal

3 Les coûts sont trop élevés Petite entreprise et gros projet

4 Performances ambitieuses. On n’atteint pas les améliorations escomptées

Sous estimation de la part du client sur la difficulté d’un tel projet. Il pourrait en demander trop dans une optique de « Monde Parfait »

5 Mauvaise coordination entre Montréal et Sydney Problème dût au décalage horaire

6 Spécifications imprécises Définition imprécise de la part de la bureaucratie de la ville qui parle un « langage » différent (non technique).

7 Le client abandonne le projet Abandon du projet avant la signature du contrat

8 Calendrier trop ambitieux Pression dût aux divers mouvements politiques

9 Les employés ne sont pas experts Nos employés pourraient manquer de formation sur certains sujets.

10 Changement dans la spécification en cours de route

Des bureaucrates pourraient avoir de nouvelles idées, suivant la demande des électeurs.

11 Chefs de projet/d’équipes inexpérimentés

Certains de nos chefs d’équipes sont jeunes et viennent de sortir de l’université. Bien que leur manque d’expérience est compensé par leur rapidité d’adaptation.

12 Manque (ou non validité) des statistiques sur la circulation et la ville en général

Il est peu probable que les données obtenues par des sources officielles soient erronées. Mais une erreur est toujours possible.

13 Maladie ou départ de personnel Selon nos statistiques des années passées, ce risque est jugé faible.

14 Démotivation En début de projet une démotivation est très improbable.


Gestion de risques

I.b – Estimation de probabilites (Ordonne selon le pourcentage du risque)


ID Risque (%) Justification

1 Une autre entreprise (ville) propose le même produit 80 % GDLA n’est pas la seule entreprise à pouvoir proposer un produit d’une telle

ampleur.

2 Nos experts non habitués aux infrastructures de Sydney

80 % Malgré certaine similitudes, la mentalité des gens de Sydney n’est définitivement pas la même que les Montréalais. En plus des différence naturelle. (Été chaud et humide, l’eau des toilettes qui tourne dans le sens inverse de ceux de Montréal…)

3 Les coûts sont trop élevés 65 % La ville de Sydney pourrait surestimer nos ressources disponibles, ou bien sous-estimer nos besoins matériels. Bien que nous allons traiter avec une administration gouvernementale, donc certainement, plus ou moins des besoins.

6 Spécifications imprécises 60 % Nous allons traiter avec l’administration municipale. Donc, avec des gens spécialiser dans le droit et non en technique. Mais nous parlerons tous en anglais ce qui est déjà un début.

5 Mauvaise coordination entre Montréal et Sydney 50 %

Peu de notre personnel ou bien des leurs voudraient travailler à des heures non conventionnelles afin de faciliter la synchronisation. Mais nous pourrions offrir certaine compensations (monétaire, privilège…)


40 % Le projet demander pourrait avoir de grande ambition, nous sommes déterminer à aller dans ce sens !

8 Calendrier trop ambitieux 40 % A moins d’un coup d’état ou plus raisonnablement, une élection d’un parti qui serait contre notre projet, nous n’avons rien à craindre. Mais la politique obéit à des lois non linéaires.

9 Les employés ne sont pas experts 40 % Nous pourrions avoir des employés sans expérience, nos chefs d’équipes, avec leur

décennie de pratiques feront la différance !

10 Changement dans la spécification en cours de route

40 % Nouvelles demandes de la part du client. Il ne changera pas les bases du projet, mais pourrait exiger des fonctionnalités supplémentaires ou bien un éliminer d’autres. En tout cas, ce sera nécessairement dans le même domaine.

7 Le client abandonne le projet 30 % Le risque d’un abandon de ce projet est nuancé par les apports économique et

écologique que ce projet permettra.

11 Chefs de projet/d’équipes inexpérimentés 15 %

Bien que la présence de chefs non expérimentés soit possible, le dynamisme et la convivialité au cœur de l’entreprise comblera le fausser. Et aussi, on ne devient pas chef de projet sans un minimum de compétences.

13 Maladie ou départ de personnel 15 %

Bien que le départ du personnel serait un grand mal, dût à la perte des connaissances spécifique de l’entreprise, nous avons toujours nos chefs d’équipes prêts à former la relève.

14 Démotivation 15 %

Demander à nos gens de travailler à l’étranger sur une longue période pourrait avoir des effets négatifs. Mais comme l’entreprise possède un grand pourcentage de jeunes et donc sans contraintes familiaux, les effets de risque sont minimisé au maximum.

12

Manque (ou non validité) des statistique sur la circulation et la ville en général

10 % Le system à implanter se veut être dynamique et évolutif. Les statistiques du réseau urbain ne sont là que pour nous donner une idée des améliorations que notre system fournira.

Gestion de risques

I.c – Dommages et risques. (Ordonne selon l’exposition au risque)


ID Dommages Justification Exposition

1 3,5 Perdre le contrat entraînerait la fin du projet ! Bien que nous pourrions le proposer à un autre client. 280

2 3

En se référant au défunt projet de la NASA, celui de lancer une sonde sur Mars et qui a atterrit dans la banlieue de Jupiter. Ils avaient demandé des calculs à leurs confrères européens, qui leur ont fournit des résultats corrects, mais en données métriques. Alors que les américains fonctionne un Inch…

240

3 3 Le manque d’expérience pourrait être compensé par plus d’analyses, et des mises à niveaux. Mais le manque d’argent bloquerait toutes nos possibilités de manœuvres.

195

4 3,5 Notre entreprise étant constituée de gens dynamiques et polyvalents, changer la direction du projet de quelques degrés ne constituera qu’une gène mineur.

140

5 2,5 Il est bien connu que les programmeurs travaillent à des heures insolites. 125

6 2 Une définition imprécise nous ferait partir sur un projet autre que celui demander 120

7 4 Nous perdrons le projet avec ce client, mais à ce stade, nous ne sommes encore engagé à rien. 120

8 3 Pression dût aux divers mouvements politiques. Ici, nous comptons sur les compétences de nos gens. 120

Valeur de coupure ! 9 2,5 Tout manque d’expertise peut être compensé rapidement par une mise à

niveau 100

10 2

Des pommes restent des pommes, et des poires reste des poires. Les exigences peuvent changer, mais à la fin, nous auront toujours un System de contrôle automatique des feux de circulation. Sinon, nous serons dans le risque id 7.

80

11 3 Un chef de projet incompétent entraînera indubitablement les équipes à sa charge dans sa chute. 45

12 3 Nous pourrions privilégier des artères non utilisé, et ignorer ceux dont le taux de fréquentation est important. 30

13 2 Nous aurons, bien entendu, moins de ressources à affecter. Mais en restructurant les tâches et en accordant certain privilèges, ce mal sera à peine perceptible.

30

14 2 Même démotivé, les employés devront travailler si ils veulent leur salaire !! 30

Gestion de risques II – Choix de la valeur de coupure.

Nous avons situé notre coupure à 110 de la valeur d’exposition. Explication du chois de la valeur de coupure.

Nous avons choisi d’ignorer tous les risques ne présentant qu’un ralentissement du projet. Ainsi, même avec un peu de retard, le projet aboutira.

En fait, notre stratégie est surtout basé sur la confiance que nous accordons à nos chefs d’équipes, dans leur facultés à résoudre ou bien à se conformer face aux va et viens de problèmes que pourrait rencontrer notre entreprise sur ce projet. De ce fait, nous considérons tous les risque inférieur à 110 comme des risques qui disparaîtront d’eux même au cours du projet.

Donc, dans un autre point de vue, nous pourrions dire que nous

avons jugé critique tous risques qui pourraient empêcher nos chefs d’équipes de travailler.


Gestion de risques III – Strategie d’aversion.

ID Risque Strategie d’aversion

1 Une autre entreprise (ville) propose le même produit Signature d’un contrat d’exclusivité

2 Nos experts non habitués aux infrastructures de Sydney Offrir des stages, favoriser la documentation et les recherches.

3 Les coûts sont trop élevés Définir dans une clause du contrat une avance d'argent. Cela pourrait être un tiers de au début, puis un tiers au milieu et un tiers à la fin.


Formation spécifique et obligatoire des employés concernés

5 Mauvaise coordination entre Montréal et Sydney

Réorganisation des tâches entre les deux sites et réarrangement des heures de travail des employés.

6 Spécifications imprécises Trouver un intermédiaire qui comprend les deux "langages", afin de traduire le plus fidèlement possible les propos des deux parties.

7 Le client abandonne le projet Ce serait une Rupture de contrat qui entraînera des pénalités au client

8 Calendrier trop ambitieux - Sous-traitance de certaines sous parties. - Revenir à l'ID 5. - Engager plus de monde.


Rapports de réunions du groupe GDLA sur le projet CACTUS

Année Mois Jour Page

2004 Septembre 20 ………………………………………………………………. 3

2004 Septembre 24 ………………………………………………………………. 4

2004 Octobre 15 ………………………………………………………………. 5

2004 Octobre 16 ………………………………………………………………. 6

2004 Octobre 18 ………………………………………………………………. 7

2004 Novembre 08 ………………………………………………………………. 8

2004 Novembre 12 ………………………………………………………………. 9

2004 Décembre 02 ………………………………………………………………. 10

Réunion du lundi 20 septembre 2004. Présence

- Mathieu Kastlé (Chef de Projet) - Mohammed Rabie Hadj Messaoud - Yan Bergeron - Samira Abouchikh - Latifa Senhaji - Duc-Loc Huynh

Travail effectué C’est la première réunion!

Points discutés Premier contacte avec la nouvelle équipe.

- Présentation des membres - Échange des coordonnées - Proposition du projet CACTUS

Liste des membres : Samira Abouchikh [email protected]

Yan Bergeron [email protected]

Mohammed Rabie Hadj Messaoud [email protected]

Duc-Loc Huynh [email protected]

Mathieu Kastlé [email protected]

Latifa Senhaji [email protected]

En vue de la prochaine réunion Chercher des informations sur la ville de Sydney (notamment sur le réseau routier)

Prochaine rencontre La prochaine rencontre est prévue pour le vendredi 24 septembre 2004 à 17h00

Réunion du lundi 24 septembre 2004. Présence

- Mathieu Kastlé (Chef de Projet) - Mohammed Rabie Hadj Messaoud - Yan Bergeron - Duc-Loc Huynh

Travail effectué

Recherche superficielle du réseau urbain de Sydney.

Points discutés

Restructuration du groupe : Perte de Samira Abouchikh et Latifa Senhaji.

En vue de la prochaine réunion Le travail pour aujourd’hui a été reporté à la prochaine réunion afin d’approfondir les recherches

Prochaine rencontre La prochaine rencontre est prévue pour le vendredi 15 octobre 2004 à 17h00

Réunion du lundi 15 octobre 2004. Présence


Travail effectué

Recherche approfondie du réseau de Sydney

Points discutés

- Révision du sujet - Pour et contre - Présentation des résultats des recherches

En vue de la prochaine réunion Commencer les points de fonctions




Travail effectué

Les points de fonctions

Points discutés

- Présentation des points de fonctions - Discussion sur la pertinence des points de fonctions présentées - Suggestion de nouveaux PF

En vue de la prochaine réunion Établir les frontières du système Affiner les points de fonctions Fournir un schéma des frontières du système




Travail effectué

Les points de fonctions (affiné) Schéma des frontières du système

Points discutés

- Révision des frontières du système - Précision des « acteurs » du système

En vue de la prochaine réunion Établir un diagramme de Uses Cases Établir un WBS en concordance Établir un diagramme de PERT

Prochaine rencontre La prochaine rencontre est prévue pour le vendredi 08 novembre 2004 à 17h00

Réunion du lundi 08 novembre 2004. Présence


Travail effectué

Le WBS enfin finalisé Le Diagramme de Gant avec la répartition des ressources Contrôle qualité

Points discutés

- COCOMO v2, problématique sur les données que nous possédons déjà. Il

manque les valeurs matériels et systèmes embarqués. - Tout sera calculer en fonction des valeurs logicielles, puis les mises à jour

se feront ensuite.

En vue de la prochaine réunion Établir un diagramme de Uses Cases Mettre à jour un site web de présentation du projet Demander les valeurs matériels et systèmes embarqués

Prochaine rencontre La prochaine rencontre est prévue pour le vendredi 12 novembre 2004 à 17h00

Réunion du lundi 12 novembre 2004. Présence


Travail effectué

COCOMO Intermédiaire

Points discutés

- Répartition du travail en général

En vue de la prochaine réunion Préparer la présentation

Prochaine rencontre La prochaine rencontre est prévue pour le vendredi 02 décembre 2004 par le Web

Réunion du lundi 02 décembre 2004. Présence

- Mathieu Kastlé (Chef de Projet) - Mohammed Rabie Hadj Messaoud - Duc-Loc Huynh

Travail effectué

Livrable final

Points discutés

- Présentation du plan de projet

En vue de la prochaine réunion Aucune

Prochaine rencontre Non spécifier

Documents

Sommaire - iro.umontreal.ca