UNIVERSITE CATHOLIQUE DE LOUVAIN

Anne acadmique 2009 2010

SINF2282 : Gestion de Projets informatiques

Systme de gestion informatique de l'UCL

Mitskos Christina Spinel Jean-Denis

LING Ms/LA
1

Introduction

Le systme dinformation de lUCL possde certaines faiblesses. Le CEDITI exprime, dans un rapport, diffrentes recommandations pour son amlioration qui tend vers une gestion globale de lensemble des composantes cest--dire des systmes et de lorganisation. Les objectifs damlioration viss par la stratgie informatique concernent les diffrentes catgories dutilisateurs que sont les tudiants, le personnel administratif, le personnel acadmique et scientifique, les autorits facultaires et centrales, les intervenants externes (tudiants potentiels, alumni, entreprises, personnes la recherche de formation continue, ). Selon le CEDITI, il est indispensable de mieux prendre en compte les processus globaux et transversaux afin doffrir aux diffrents intervenants de luniversit les applications rpondant non seulement des besoins de mtier spcifiques, mais rpondant galement aux besoins des utilisateurs plus occasionnels en offrant un service cohrent, simplifi et unifi. Notre travail consiste avoir une rflexion sur larchitecture gnrale de ce rapport. Dans le premier chapitre, nous avons estim le nombre de lignes du code pour lensemble du systme informatique grce la technique unadjusted use-case points . Ensuite, grce aux nombres de lignes de code en SLOC, nous avons budgtis notre travail grce au modle COCOMO II avec le logiciel Costar. Ce modle permet aussi dvaluer leffort. Nous avons aussi valu dans les chapitres suivants les risques inhrents chaque projet et les qualits requises pour notre projet. Enfin, nous avons termin notre travail en crant un diagramme de Gantt et le profil RUP du notre projet pour une planification de celui-ci.

1. Estimation du nombre de lignes du code

Pour estimer le nombre de lignes du code, il faut quantifier les poids des Use Cases et des acteurs.

En premier lieu, les acteurs seront classifis selon trois critres : simple, moyen ou complexe. Ces derniers sont dfinis par la complexit du systme. Un systme simple correspond par exemple un API, un systme moyen correspond du TCP/IP et un systme complexe correspond un GUI ou une page Web. Un poids sera alors attribu chaque acteur selon sa complexit :

Complexit Simple Moyen Complexe

Poids 1 2 3

On calcule le unadjusted actor weights (UAW) en faisant la somme des produits du nombre des acteurs par son facteur de poids : UAW = NbSimple * 1 + NbMoyen * 2 + NbComplexe * 3

1.1. Les acteurs

Les acteurs dinformation (SI):

englobent

toutes

les

catgories

dutilisateurs

du

systme

Le personnel pour la gestion des tudiants/Programmes/Cours (EPC)

Les intervenants importants pour cette application sont nombreux : ETU, les facults et les dpartements, ENSE, SET, les cabinets, Ils doivent donner les statistiques des tudiants, sassurer que les inscriptions des tudiants sont correctement assures, soccuper de la gestion des logements tudiants et des financements des tudiants optimaux, enfin avoir des informations sur les tudiants compltes. Le personnel soccupe aussi des changes entre universit en matire denseignement facilit. Il devra donc donner aux partenaires un profil accessible sur les tudiants. 3

Enfin, les intervenants doivent fournir une informatique administrative facultaire adquate. Ils doivent, par ailleurs, grer les programmes et les cours, encoder correctement les non-membres du personnel,

Chercheur Il doit pouvoir grer ses donnes personnelles, grer son C.V., grer ses mandats. En outre, il faut quil puisse publier toutes informations utiles la recherche universitaire sur le portail internet ou intranet. Les chercheurs doivent aussi avoir les possibilits lies elearning, avoir un accs ais aux sources dinformations scientifiques et pdagogiques.

Enseignants Lenseignant pourra avoir un accs ais aux sources dinformation scientifique et pdagogique depuis nimporte quel lieu. Il aura, aussi, des outils lui facilitant le suivi de la formation des tudiants. Lenseignant se verra, en outre, offrir un environnement pour la cration et la diffusion de matriel pdagogique et qui lui permettra de grer et de publier les informations relatives aux projets de recherche, aux projets pdagogiques et au personnel acadmique et scientifique.

Etudiants Ce sont des acteurs importants du SI. Ils doivent pouvoir commander des documents administratifs et avoir accs aux informations qui les concernent cest--dire, des informations sur les formations, programmes/cours, horaire, examens, messagerie lectronique, inscription, aide financire, logement, informations culturelles et sociales. Les futurs tudiants Ils doivent avoir un accs personnalis et cibl aux informations recherches et dautres informations qui pourraient les concerner.

Les alumni Ils doivent avoir un accs personnalis et cibl aux informations recherches et dautres informations qui pourraient les concerner, avoir accs une application des suivis des sollicitations, du suivi des contacts, du suivi de mailing et de lenvoie des documents lgaux.

 Les entreprises Ils doivent avoir un accs personnalis et cibl aux informations recherches et dautres informations qui pourraient les concerner, avoir accs une application des suivis des sollicitations, du suivi des contacts, du suivi de mailing et de lenvoie des documents lgaux.

Conseil rectoral Cet organe est compos dune direction gnrale qui sera charge des dcisions et du suivi de la stratgie pour le SI sous le contrle du conseil rectoral. Il gre les ressources ainsi que le budget du SI. Il propose des nominations du personnel acadmique, des promotions des membres du personnel, des budgets annuels, des attributions des charges acadmiques et des propositions stratgiques relevant de la comptence du Conseil dadministration. La direction gnrale est compose : dun reprsentant des facults et dun reprsentant de ladministration, tous deux membres du comit de la stratgie informatique, dun pro-recteur, de ladministrateur gnral, du chef de cabinet de ladministrateur gnral et du chef de cabinet du recteur, du CIO.

Conseil acadmique De cet organe, le conseil stratgique dpend et se compose : - de plusieurs reprsentants des facults, - de plusieurs reprsentants des entits de ladministration centrale, - du CIO. Le conseil stratgique instruit les propositions de projets prsentes la direction gnrale du SI. En outre, le conseil acadmique a une comptence davis en ce qui concerne : - enseignement et formation ; - agrgation ; - recherche ; - relations internationales ; - formation continue ; - bibliothques ; - dontologie de la recherche ; - communication et culture ; - service la socit.
5

 Bibliothque La bibliothque se compose dune bibliothque informatique, darticles scientifiques scanns, dun guichet en ligne, du catalogue central UCL, de bases de donnes bibliographiques, dun accs des ressources depuis lextrieur. Personnel de ladministration financire Les intervenants humains sont les responsables et les associs de ladministration financire, les services chargs de la gestion immobilire (LOGE, DOM, ), ladministration de la recherche (gestion des contrats) et limplication des cabinets et de services tels que SET.

Les applications SAP -applications financires Les applications concernes sont diffrents modules du progiciel SAP/R3 : FI (finance), CO (comptabilit analytique), PS (suivi de projets), AA (asset accounting), FM (fund management), PCA (comptabilit des centres de profit) et REM (Real Estate Management). -applications logistiques Les applications concernes sont diffrents modules du progiciel SAP/R3 : MM (Material Management) et SD (Sales and Distribution) ainsi quARCHIBUS (la gestion de la maintenance prventive et corrective fait partie de la logistique).

Support aux utilisateurs Concerne la documentation et le reporting, la formation acadmique et administrative, ainsi que le Helpdesk acadmique et administrative.

Gestion de la production Les diffrents services fournis pour la gestion de linfrastructure sont regroups dans cet acteur qui couvre la gestion du parc de machines (les serveurs), la gestion systme, ladministration des bases de donnes, la gestion du rseau, la gestion des copies de scurit (backups) et de larchivage. Ce regroupement implique une gestion globalise du service fourni.

Administration de la recherche
6

Les responsables et les utilisateurs-cls sont les services ADRE, ADFI. Les intervenants doivent couvrir le support administratif de la recherche dans ses diffrentes phases depuis son closion jusqu son valuation et sa valorisation en passant par le suivi des activits de recherche.

Gestion du personnel Les responsables qui soccupent du personnel de lUCL et les associs appartiennent, entre autres, aux SPER et RHUM. Ils sont en collaboration avec ADFI en ce qui concerne les aspects financiers. Ils travaillent aussi avec SET et les cabinets pour les aspects de la politique universitaire. Les intervenants doivent couvrir les aspects de gestion des ressources humaines (recrutement, gestion des carrires) et de gestion du personnel (gestion des temps, des absences, de la paie, des engagements de dpenses, ...).

Responsables de la logistique Les intervenants sont les responsables et les utilisateurs-cls du service des achats, de lADST, des logements. Les responsables doivent couvrir les aspects de gestion logistique comme la gestion des stocks, les achats et les ventes.

Les applications Uportal Les applications concernes sont la gestion du contenu, le Web public, la prospection des tudiants, des entreprises et des alumni, la formation continue, le suivi des contacts, linscription aux cours et aux examens, les logements, laide aux tudiants, les cours des enseignants, le E-learning, la bibliothque, le projet de recherche, le cv, les publications des chercheurs, la prospections et laprs-recherche.

Tableau des acteurs

Acteurs

Complexit

Justification
Acteur humain qui soccupe de la gestion des tudiants (inscription, logement, financement des tudiants), des changes entre universit
7

Le personnel pour la gestion Complexe des tudiants/Programmes/Cours (EPC)

en matire denseignement facilit et fournir une informatique administrative facultaire adquate Chercheurs Complexe Acteur humain qui recherche des informations dur le web et diffuse des informations. Acteur humain (enseignants) qui diffuse des informations sur ces cours, ou recherche des informations (suivi des tudiants) via une interface. Acteur humain qui travers une interface et les pages web recherche des informations le concernant. Acteur humain qui recherche des informations via les pages web Acteur humain qui recherche des informations via les pages web Acteur humain qui recherche des informations via les pages web Acteur humain qui diffuse et contrle les informations via une interface et pages web. Acteur humain qui diffuse et contrle les informations via une interface et pages web. Utilisation dun ensemble de fonctions Acteur humain qui utilise des logiciels du SI pour un but prcis Utilisation des modules du progiciel SAP/R3 pour la gestion de la finance et
8

Enseignants

Complexe

Etudiants

Complexe

Futurs tudiants

Complexe

Alumni

Complexe

Entreprises

Complexe

Conseil rectoral

Complexe

Conseil acadmique

Complexe

Bibliothque Personnel de ladministration financire Les applications SAP

Simple Complexe

Simple

logisique Support aux utilisateurs Gestion de la production Administration recherche de Simple Moyen la Complexe Complexe Acteur humain qui gre la recherche Acteur humain qui utilise les logiciels et interface pour la gestion du personnel Acteur humain qui utilise les modules du progiciel SAP/R3 pour la gestion de la logistique Utilisation de Uportal dans diffrentes fonctionnalits du projet Utilisation dun ensemble de fonctions

gestion du personnel

Responsables de la logistique

Complexe

Les applications Uportal

Simple

Calcul du UAW : 3 *13 + 2 * 1 + 1 * 4 = 45

1.2 Les Use Cases

Comme nous lavons signal ci-dessus, pour calculer le nombre de codes de lignes, il faut aussi calculer le poids des Use Cases selon leur complexit. Ces derniers peuvent tre nomms comme simple, moyen ou complexe selon le nombre de transactions ou ditrations effectuer : Complexit Simple Moyen Complexe Poids 5 10 15 Nombre de transactions 3 ou moins 4 ou 7 Plus de 7

En donnant un poids chaque Use Case , nous pouvons finalement donner le unadjusted use case weights (UUCW). Celui-ci est calcul en faisant la somme des produits de la complexit de chaque Use Case avec son facteur poids :
9

UUCW = NbSimple * 5 + NbMoyen * 10 + NbComplexe * 15

Au final, on obtient le unadjusted Use Case Points (UUCP). Ce dernier est la somme du UAW (le rsultat de lanalyse des acteurs) et du UUCW (le rsultat de lanalyse des Use Cases ) : UUCP = UAW + UUCW

Tableau dcrivant les Use Cases

Les Use Case

1. Gestion du personnel

La complexit
Moyen

Description
Couvre les aspects de gestion des ressources humaines (recrutement, gestion des carrires) et de gestion du personnel (gestion des temps, des absences, de la paie, des engagements de dpenses, ...). Couvre la demande des documents administratifs, laccs distance des informations, linscription des tudiants correctement assure, les informations compltes sur les tudiants, la gestion des logements, la statistique des tudiants, la capacit financire des tudiants calcule. Vise mettre en place un systme permettant la gestion centralise des anciens et amis de lUCL. Les applications finance couvrent les aspects comptabilit analytique, comptabilit budgtaire,
10

2. Gestion administrative Simple des tudiants

3. Gestion administrative Simple des alumni

4. Gestion administrative Complexe des finances

gestion financire et gestion immobilire 5. Administration du Moyen service technique et du matriel Couvre les aspects de gestion logistique comme la gestion des stocks, les achats et les ventes, rservation du matriel. Installation et maintenance du parc de pc et des logiciels bureautique Centralisation de linformation entre les facults ou autres et agrgation des donnes. Avoir des informations compltes et jour sur le personnel de luniversit (le CV, les publications, poste, mandat, activit, interruption de carrire, historique barmique,) Concerne la scurit informatique (des accs, des donnes, des machines), scurit des rseaux, des applications administratives, des serveurs des courriers lectroniques, des postes de travail. Porte la fois sur la manire dont il est gr et sur le contenu de linformation que lon peut y trouver (internet, intranet). Couvre la gestion administrative des bibliothques ainsi que les accs en ligne aux ressources : bibliographie, catalogues et bibliothque
11

6. Maintenance du matriel

Simple

7. Gestion de la collecte et agrgation des informations

Complexe

8. Gestion des informations Simple relatives aux membres du personnel

9. Gestion de la scurit Moyen informatique

10. Gestion de laccs et Complexe aux informations du web

11. Gestion de la bibliothque lectronique

Moyen

digitalise. 12. Administration de la Simple recherche Suivi administratif des projets de recherche, gestion des contrats de recherche, valuation des activits de recherche. Appui financier pour la valorisation des rsultats de recherche. Inscription par les tudiants luniversit, aux programmes de cours via le Portail1 . Dveloppement et maintenance dapplication spcifique pour que les tudiants grent leur formation. Concerne les informations sur la vie universitaire (information culturelle, sociale, sur les logements, etc.). Permet laccs des formations distance grce des outils en ligne dvelopps.

13. Gestion de lapport Complexe financier la recherche 14. Inscription luniversit et aux programmes de cours Simple

15. Consulter les horaires, Simple les lieux de cours et les nouvelles relatives aux cours 16. Gestion des informations concernant la vie tudiante Moyen

17. Suivre une formation Moyen distance

18. Grer et publier des Moyen informations relatives aux projets de recherche et aux projets pdagogiques 19. Gestion administrative Moyen des contacts dentreprises Offrir un accs cibl aux intervenants externes en rapport avec les informations recherches. Permet de donner un

20. Gestion de la mobilit Simple

1

Projet nomm Portail qui permet dtre une plate-forme dintgration et dunification au sein de luniversit. Cest un Bureau de travail virtuel fournissant laccs la connaissance, aux changes, aux applications et permettant laccomplissement de processus en tout temps, en tout lieu, de faon cible et personnalise.

12

de lutilisateur

identifiant unique de lutilisateur pour lensemble de luniversit et permet duniformiser le contrle daccs des utilisateurs

21. Gestion de la formation Simple continue 22. Gestion doutils collaboratifs Simple Concerne le courriel, valves lectroniques, forum, le calendrier. les le

23. Support informatique Moyen pour le personnel et les tudiants 24. Gestion des relations Moyen interuniversitaires

Concerne les logiciels, les systmes, les formations et helpdesk. Permet laccessibilit du profil tudiant aux partenaires et autres institutions.

1.3 Estimation du projet

Calcul du UUCW : 10*5 + 10*10 + 4*15 = 210

Calcul du UUCP : 45 + 210 = 255

Pour valuer le nombre de lignes, nous pouvons utiliser le programme CostXpert o le UUCPQ est quivalent 225 lignes de codes. Cette valeur est utilise pour donner une valuation du SLOC :

SLOC : 255*225 = 57375 lignes de codes

13

14

2. Cocomo

Le modle Cocomo et le logiciel Costar vont permettre la fois destimer leffort fournir pour le dveloppement de notre projet et la dure que ce dernier prendra en fonction des ressources alloues. Pour calculer cet effort, nous utilisons la formule suivante :
Effort (E) = a * (Size)b * c

Le paramtre Size est dtermin par le KSLOC estim au chapitre prcdent (SLOC= 57375). La constante b reprsente les 5 scale factors et la constante c dtermine les 17 cost drivers

2.1Les scale factors

2.1.1 Precedentedness
La question se poser est : Le nouveau projet est-il comparable au projet que votre quipe a ralis avant ? Drivers PREC Niveau Generally Familiar (Elev) Valeur 2.48

Nous avons dcid de donner la valeur Elev , car en 1996, lUCL crait un plan informatique 2000 des outils et du support informatique pour lenvironnement direct des personnes (bureautique et outils collaboratifs) et le support lenseignement et la recherche. Donc, luniversit dj une certaine exprience avec les projets informatiques assez consquents. En outre, lUCL tente de recruter un personnel informatique comptent (cf. infra) qui devrait, selon nous, dj avoir une certaine exprience et formations pour lutilisation des outils que lUCL emploie (SAP, Uportal,).

15

2.1.2 Development Flexibility

La question pose ici est : Vos exigences sont-elles flexibles ou doivent-elles toutes tre satisfaites ? . Drivers FLEX Niveau Some Relaxation (Normal) Valeur 3.04

Actuellement, le choix de certains systmes ne se fera quaprs exprience2 . Nous pouvons donc remarquer quil y a une certaine flexibilit dans les satisfactions demandes. Celles-ci ne seront rellement concrtes quaprs exprience (choix du Uportal ou de SAP).

2.1.3 Architecture/ Risk Resolution

La question laquelle nous devons rpondre est : jusqu quelle degr a-t-on dj dfini larchitecture ? Drivers RESL Niveau Generally 75% (Elev) Valeur 2.83

Comme nous pouvons le remarquer sur le schma de SI-UCL, au moins 75% de linfrastructure de projet informatique est dfini par lUCL.

2.1.4 Team Cohesion

Cela concerne la cohsion au sein de tous les intervenants du projet. Drivers TEAM Niveau Basically (Normal) Valeur Cooperative 3.29

Le projet tant peine en cours, nous pouvons difficilement nous faire une ide sur la question. Nous savons quactuellement le systme est fort dcentralis et lun de ses points faibles est le manque de cohsion et de cohrence entre les diffrents intervenants. LUCL tente dans son nouveau projet davoir un systme unifi. Pour cette raison, nous mettons Normal qui la fois permet de mettre en avant les problmes du systme et la fois permet de mettre aussi en avant les efforts de lUCL dans ce domaine.
2

Document reu SI-UCL page 49

16

2.1.5 Process Maturity

La question laquelle rpondre est la suivante : quelle est le taux dorganisation du SEI Maturity Scale ? Drivers PMAT Niveau SEI CMM Level 2 (Normal) Valeur 4.18

Nous pensons que certains sous-projets du systme sont dj oprationnels aprs une analyse de key process . Pour cette raison, nous donnons une maturit Normal .

2.2 Cost Drivers

2.2.1 Personnel factors

2.2.1.1 Analyst Capability La question pose est : Quelle est la capacit des analystes dans ce projet ? Drivers APAC Niveau 75th-about average (Elev) Valeur 0.85

Nous pensons que lUCL a engag, pour ce projet denvergure, des analystes expriments qui ont dj particip ce genre de travaux. De nombreuses recommandations ont dj t faites par le CEDITI qui est le Centre de diffusion des technologies de l'information qui est un centre faisant partie de lUCL.

2.2.1.2 Applications Experience

17

La question laquelle nous devons rpondre est quelle est lexprience de notre quipe avec ce type dapplication ? Drivers APEX Niveau 3 years (Elev) Valeur 0.88

Ce genre dapplication a dj t dvelopp par lUCL (cf. supra). Lquipe a donc soit la documentation des expriences passes soit dj participe ce genre dapplication (ou a une certaine exprience).

2.2.1.3 Programmer Capability La question laquelle nous devons rpondre est : Quelle est la capacit des programmeurs de ce projet ? . Drivers PCAP Niveau 75th percentile (Elev) Valeur 0.88

Comme nous le signalerons plus bas, lUCL met essentiellement laccent sur la comptence pout engager les programmeurs et informaticiens. Nous avons donc mis en pourcentage lev.

2.2.1.4 Platform Experience La question laquelle nous devons rpondre est : Quelle exprience votre quipe possde-telle avec la plate-forme pour laquelle vous dveloppez votre application ? . Drivers PLEX Niveau 3 years (Elev) Valeur 0.91

Lapplication est dveloppe avec SAP et Uportal 3. SAP fait partie des fournisseurs principaux des logiciels ERP (Entreprise ressource planning). Il est donc assez actif sur le march. Uportal offre une infrastructure standard. Ces outils, selon nous, doivent donc tre connus par les quipes en charge.

Document reu SI-UCL, page 49.

18

2.2.1.5 Language and Tool Experience La question laquelle nous devons rpondre est : Quelle exprience votre quipe possde-telle avec le langage et les outils prvus pour le dveloppement de votre application ? . Drivers LTEX Niveau 3 years (Elev) Valeur 0.91

Comme nous lavons signal plus haut, lUCL emploie des outils connus et standards. Ce sont des outils avec lesquels les personnes engags et surtout lquipe mise en place doivent connatre. LUCL, selon nous, ne mettrait pas des personnes totalement ignorantes en charge de la mise en place dun systme (alors que laccent est mis sur la comptence des personnes lors du recrutement du personnel)4.

2.2.1.6 Personnel Continuity La question laquelle on doit rpondre ici est : Quel est le turnover annuel de votre socit ? . Drivers PCON Niveau 12% turnover (Nominal) per Valeur year 1.00

Ne connaissant pas en dtail le fonctionnement de lUCL, dun point de vue de la gestion du personnel, nous avons pris lhypothse que le turnover se situait dans la moyen savoir 12%.

2.2.2 Project related

2.2.2.1 Use of Software Tools La question laquelle nous devons rpondre est : quelles outils notre quipe utilisera-telle ? Drivers Niveau Valeur

Document reu SI-UCL, page 45.

19

TOOL

Basic life-cycle tools, 1.00 moderately integrated (Normal)

LUCL utilise des outils standards5 (Uportal en java et SAP connu dans le domaine financier) et pour cette raison nous avons dcid de considrer le cost driver comme Normal .

2.2.2.2 Multisite Development La question laquelle on doit rpondre ici est : Lquipe est-elle spare sur plusieurs sites ? Comment communique-t-elle ? . Drivers SITE Niveau Multi-city and company (Normal) Valeur multi- 1.00

LUCL possde trois sites Bruxelles, Louvain-la-Neuve et Charleroi. Notre cost driver est donc Normal.

2.2.2.3 Development Schedule La question laquelle on doit rpondre ici est : Le calendrier du projet est-il compress par rapport au calendrier par dfaut (Nominal) ? . Drivers SCED Niveau Valeur

100% of nominal schedule 1.00 (Normal)

Nous navons que trs peu dindications sur ce sujet. Etant donn les changements, les objectifs et le niveau de qualit atteindre, un retard nest pas impossible. Nanmoins, nous avons prfr considrer le fait que ce retard pouvait tre pris en vidence dans le planning et donc plac le cost driver sur Normal .

Document reu SI-UCL, pages 39, 40, 44.

20

2.2.3 Product related

2.2.3.1 Required Reliability La question laquelle nous devons rpondre est : quelle est la consquence dun problme (plantage) avec le programme ? Drivers RELY Niveau High financial loss (Elev) Valeur 1.10

Avoir un plantage du systme apporte, videmment, des pertes financires pour non seulement tout remettre en tat, mais aussi pour rattraper le temps perdu.

2.2.3.2 Database Size La question laquelle nous devons rpondre est : Quelle est la quantit de donnes suffisantes pour tester le logiciel ? Drivers DATA Niveau Valeur

(Database bytes /SLOC) 1.28 >=1000 (Trs lev)

LUCL existe dj depuis longtemps et possde donc une base de donnes assez importante. Nous pouvons donc utiliser un cost driver Trs lev

2.2.3.3 Product Complexity La question laquelle nous devons rpondre est quelle est la complexit du logiciel ? Drivers CPLX Niveau Valeur

Nested code, standard math 1.00 routines, multiple files (Normal)

Il sagit de systmes standards. Nous pensons que la complexit dUportal nest pas trop grande, mais demande tout de mme quelques semaines dapprentissage.
21

2.2.3.4 Required Reusability La question laquelle nous devons rpondre est : dveloppez-vous les composants de votre logiciel pour quils soient rutiliss ? Drivers RUSE Niveau Across program (Elev) Valeur 1.007

Certains programmes pourraient tre utilis par dautres universits ou tre pris comme exemple par certaines entreprises.

2.2.3.5 Documentation match to life-cycle needs La question laquelle nous devons rpondre est: quelle quantit de documentation doit-on crer ? Drivers DOCU Niveau Right-sized to needs (Normal) Valeur life-cycle 1.00

Vu la complexit du programme, une documentation standard est suffisante. En outre, le domaine est dj assez connu (pour Uportal et SAP) et possde dj une bonne documentation.

2.2.4 Platform related

2.2.4.1 Execution Time Constraint La question laquelle on doit rpondre ici est : Combien de temps CPU votre logiciel va-t-il utiliser ? . Drivers TIME Niveau Valeur

<=50% use of available 1.00 execution of time (Normal)

22

De nombreuses actions sont inities par des acteurs humains. Les logiciels ne prendront pas ou peu de dcisions sans laval humain. Pour cette raison, notre cost driver est Normal .

2.2.4.2 Main Storage Constraint La question laquelle nous devons rpondre ici est : Quelle quantit de mmoire centrale votre logiciel va-t-il utiliser ? . Drivers STOR Niveau <=50% use of storage (High) Valeur available 1.05

Notre systme a besoin de nombreuses donnes mises en mmoire centrale comme les informations sur les tudiants, les C.V., etc. Nous considrons ces donnes utilises comme High .

2.2.4.3 Platform Volatility La question laquelle nous devons rpondre est : Combien de fois la plateforme (OS, DBMS, etc.) changera ? Drivers PVOL Niveau Valeur

Major change every 12 0.87 month ; Minor change every month (Bas)

Lapplication a dvelopp doit rester stable. Lors, du changement, il faut aussi tre sr de la compatibilit avec les vieux programmes et les veilles bases de donnes. Il faut, en outre, de nombreux testes avant de changer les OS. Le budget pour changer de plateforme est norme et peut tre que lUCL a dautres priorits que de changer lOS souvent. Cest donc non productif de ce dernier.

23

2.3 Rsultats: analyses et interprtations Aprs avoir entr toute les informations ncessaires dans le logiciel, nous avons pu obtenir les rsultats que nous allons analyser dans cette partie afin d'valuer l'effort et le cot de notre projet.

L'effort en Personnes-Mois est estim selon l'EAF (Effort Adjustment Factor, qui est driv des costs drivers ) * KSLOC (nombre de ligne de code) exposant X (driv des scale factors ) La dure de ralisation du projet en Mois est calcule selon l'Effort, l'exposant est toujours driv des scale factors . La maintenance n'est donne ici qu' titre indicatif.

Nous obtenons alors les estimations suivantes:

Nous pouvons remarquer que la phase de dveloppement, qui comprend la phase d'laboration et de construction est la plus couteuse, que ce soit en terme d'effort, de staff ou d'argent brut. Vient ensuite la phase de transition et enfin la phase d'inception.
24

Nous pouvons ensuite analyser ce que nous donne le logiciel au niveau de la productivit et du cot unitaire. D'abord au niveau des quatre phases:

Puis juste au niveau de la phase de dveloppement (laboration et Construction):

Ensuite plus finement en regardant pour chaque phase la rpartition en Cot, Effort, Dure et Staffing nous obtenons les graphiques en tore suivants:

Cost (K$)

Effort (Person-Months)

Inception Elaboration Construction Transition

Inception Elaboration Construction Transition

Duation (Months)

Staffing

Inception Elaboration Construction Transition

Inception Elaboration Construction Transition

25

Intressons nous maintenant la variable Duration que nous renvoie Costar, et qui va nous servir fixer un planning:

Nous pouvons galement aller plus loin et voir comment se rpartit l'effort mois aprs mois:

Ce qui se traduit de manire plus visuelle par les graphiques suivants:

26

Effort this Month

12

10

6 Effort this Month 4

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23

Cost (K$) this Month

40 35 30 25 20 Cost (K$) this Month 15 10 5 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23

Nous pouvons ainsi bien voir qu' partir de la 10e semaine le cot et l'effort doublent presque.

27

Terminons cette partie en montrant l'effort (en Person-months) de chaque activit au total puis dans les quatre phases du dveloppement.

IN to TR Effort

Management Environment / CM Requirements Design Implementation Assessment Deployment

IN Effort

EL Effort

28

CN Effort

TR Effort

29

3. Les risques du systme dinformation

La gestion des risques est une variable du projet qui implique principalement l'identification des risques associs un projet et leur mesure, en vue de leur gestion. Les risques du projet sont des vnements non prvus, qui ont des rpercussions ngatives (ou parfois positives) sur les objectifs du projet. Nous tenterons, de ce chapitre, de les imaginer et dvaluer leur probabilit, leur impact et leur exposition sur le projet. Lexposition se calcule ainsi :

RE = P(UO) * L(UO) where: RE = Risk Exposure P(UO) = probability of UO (=likelihood) L(UO) = loss to the parties; impact; consequence UO = Unsatisfactory Outcome

3.1.

Calcul de la probabilit

Pour la probabilit (= elle exprime le degr d'ventualit de manifestation d'un risque), nous les estimons sur une chelle de 0 5 o 5 reprsente la probabilit nulle que le facteur risque survienne et 5 la probabilit trs lev que ce facteur risque apparaissent. La probabilit dapparition dun risque peut tre estime de manire qualitative ou de manire quantitative. Dans notre travail, nous utiliserons une estimation qualitative : trs faible, faible, moyen, lev, trs lev.

30

Schma de la description de la probabilit6

3.2.

Calcul de limpact

Nous calculons aussi limpact (= consquence ou effet produit par la ralisation du risque) des facteurs de risques slectionns en les estimant sur une chelle de 0 5 qui reprsente le minimum et maximum atteint par limpact sur ces facteurs risques :

Schma repris du site : http://www.its.monash.edu.au/staff/projects/project-management/risk/riskmanagement-guide.pdf

31

Schma de la description de limpact7

Nanmoins, quand le risque ne touche que certains use cases et naffecte pas tout le projet, nous avons dcid de calculer limpact, non pas de faon qualitative, mais en divisant le nombre de use cases affects par le nombre de use cases maximal et en multipliant par 5. Nous obtenons ainsi limpact :

Nb uses cases affects / Nb use cases total * 58

Les valeurs du risk exposure peuvent tre comprises entre 0 et 25 et seront divises en sous-rangs. Le rang low , moderate , high et le rang critical . Ci-dessus, nous avons tableau9 qui nous donne le rang associ chaque valeur selon limpact et la probabilit. Nous avons aussi intgr en annexe un programme excel10 qui permet lui aussi de donner le rang du risque.
Schma repris du site : http://www.its.monash.edu.au/staff/projects/project-management/risk/riskmanagement-guide.pdf .
8 7

Calcul repris du rapport des lves : Jrmie Melchior (Info 22) Florian Meulemans (Info 23) Gestion de Projet InformatiqueSystme de gestion des lits pour les cliniques St-Luc .

Schma repris du site : http://www.its.monash.edu.au/staff/projects/project-management/risk/riskmanagement-guide.pdf

32

Schma du rang selon la probabilit et limpact11

Nous avons repris ci-dessus les risques principaux et spcifiques pour le projet que nous analysons.

10

Programme repris du site : http://www.its.monash.edu.au/staff/projects/project-management/risk/riskmanagement-guide.pdf

11

Schma repris du site : http://www.its.monash.edu.au/staff/projects/project-management/risk/riskmanagement-guide.pdf

33

3.3 Risques principaux

Le SI utilisera le progiciel SAP pour la gestion financire et des ressources humaines. Nanmoins, de nombreux problmes et risques dans le projet pourraient surgir lors de lutilisation de SAP : o La difficult dutilisation du systme pour des utilisateurs occasionnels. o La non adquation de certains rapports aux besoins des utilisateurs et difficult dobtenir des rapports spcifiques la demande . Signes prcurseurs : mauvais retours des utilisateurs occasionnels. Solution pour la rduction du risque: Une formation et des outils daide la demande adapts aux diffrentes catgories dutilisateurs et lamlioration du reporting sur base dune analyse des besoins rels des utilisateurs. Use cases concerns : gestion de lapport financier la recherche , administration de la recherche , administration du service technique et du matriel , gestion du personnel .

Risques Risque 1 Risque 2

Probabilit 4 4

Use cases Impact12 UC= 4, 1 UC=4, 1

+ Exposition 4 = low 4 = low

Justification de la probabilit: Le document sur le plan dorientation de la stratgie du systme dinformation de lUCL (SI-UCL) critique lutilisation difficile du progiciel SAP ainsi que sa difficult dextraire des informations pertinentes. Le SIUCL prconise tout un systme de mise en place daide et une amlioration de linterface. Il est donc plus que probable que ce risque apparatra lors de la mise en place du SI.

La motivation du personnel informatique baisse lors du changement dorganisation. Signes prcurseurs : tension au sein du personnel, baisse de productivit, absences. Solution pour la rduction du risque: Une faon de procder pourrait prvoir douvrir tous les postes et de laisser les personnes postuler diffrents postes. Use cases concerns : concerne tous les use cases . Il sagit de la dmotivation du personnel informatique qui touche tous les use cases car ils soccupent des diffrents systmes permettant la mise en place des use cases .

12

Estimation de limpact selon le calcul prsent ci-dessus.

34

Risque Risque 3

Probabilit 3

Use cases Impact UC= 24, 5

+ Exposition 15 = High

Justification de la probabilit : Ce problme est abord dans le SI-UCL et le rapport reprend la phrase La transition entre lorganisation actuelle et la future sera particulirement critique en ce qui concerne la motivation du personnel concern 13. Il est donc plus que probable que lors de cette transition le personnel soit dsorient et perde de se motivation. Pour cette raison nous accordons un 4 pour la probabilit.

Le cot du projet dpasse le budget et les ressources fixs suite une mauvaise estimation. Signes prcurseurs : A chaque tape le budget fix est dpass. Solution pour la rduction du risque: vrifier la pertinence des cost drivers choisis. Use cases concerns : Ce risque concerne le projet dans son entiret plutt que des uses case , nous donnerons donc une estimation selon le facteur de risque considr. Il est sr que si le cot nest pas bien planifi, limpact sera assez important.

Risque Risque 4

Probabilit 3

Impact 3

Exposition 9 = medium

Justification de la probabilit : Si lon veut corriger un problme ou un risque (non prvu), cela entraine gnralement une augmentation du budget. Mme si lorganisation du systme dinformation prvoit une marge de manuvre 14 pour le cot, il y a quand mme un risque que linstitution dpasse son budget.

Les objectifs sont mal dfinis et il y a une perte de temps lors de la ralisation du projet. Signes prcurseurs : doublon, travail inutile Solution : A chaque tape atteint revoir les objectifs et les redfinir pour quils soient conforment aux attentes. Use cases concerns : Tous les use cases car chacun deux doit tre rectifi et amlior par le SI et on donc des objectifs atteindre.

Risque
13

Probabilit

Use

cases

+ Exposition

Document reu SI-UCL : page 48 Estimation rgulire du cot lors de plusieurs tapes (estimation, laboration,).

14

35

Risque 5

Impact UC=24, 5

10= high

Justification de la probabilit : Les objectifs doivent normalement tre bien dfinis avant de commencer la phase dlaboration dun projet et sont les critres de russite de ce projet. En outre, les documents SI-UCL et les besoins de lUCL dcrivent dj toute une srie dobjectifs (besoins prioritaires, mission,) atteindre. Ces derniers sont donc dj abords avec beaucoup de soin. Nous pensons que le risque dobjectifs mal dfinis soit plutt faible.

Manque de coordination dans la stratgie du systme dinformation pour les diffrents organismes de linstitution et problme de centralisation. Donc, il risque dy avoir une perte defficacit au niveau du rsultat (doublons, manque dharmonisation dans le systme et perte de productivit pour lutilisateur final). Signes prcurseurs : cas de doublons. Solution pour la rduction du risque: Dfinir une seule stratgie qui est suivie par un organe de direction agissant lchelle de toute linstitution. Use cases concerns : concerne plutt le projet et le problme qui touche toutes les institutions.

Risque Risque 6

Probabilit 3

Impact 4

Exposition 12= high

Justification de la probabilit : En 1996, le plan informatique 2000 de lUCL consacrait une stratgie de dcentralisation des outils et du support informatique pour lenvironnement direct des personnes (bureautique et outils collaboratifs) et le support lenseignement et la recherche. Cette approche a entran des inconvnients. En effet, certains organes de coordination mis en place dans le cadre de ce plan nont pas fonctionn comme prvu, ce qui a contribu au manque de cohrence de lensemble. Lobjectif recherch, pour le nouveau SI, est de corriger ce problme et dessayer de retrouver une certaine centralisation et coordination notamment au niveau du systme informatique.

Problme de scurit dans le systme dinformation. En matire de scurit du SI, labsence dune politique commune et la multiplicit des intervenants peut entraner des risques trs importants et une duplication inutile des efforts. Signes prcurseurs : signalement accru de cas dinfection de virus dans un systme informatique, vol accru de mots de passe par intrusion, pannes de systmes et mauvais fonctionnement de services aprs intrusions,

36

Solution pour la rduction du risque: La mise en place dune entit responsable spcifiquement de la scurit de lensemble du systme dinformation de luniversit est requise. Use cases concerns : Le use cases qui gre la scurit est gestion de la scurit informatique .

Risque Risque 7

Probabilit 3

Use cases Impact UC=1, 115

+ Exposition 3 = low

Justification de la probabilit : La politique de dcentralisation de le linstitution entrane des services trs divers au sein des facults et un risque augment. Lobjectif est de nouveau SI est de centraliser la scurit, mais il risque toujours dy avoir des problmes dadaptation.

Le planning respecter est mal dfini. Donc, la mauvaise gestion du temps entraine un rallongement de la dure du projet et une augmentation de son cot. En outre, une priorisation des tches doit tre planifie. En effet, les parties cls du dveloppement doivent tre directement abordes afin quelles ne rallongent pas le timing du projet. Signes prcurseurs : Certaines phases de dveloppement durent plus longtemps que prvu. Ds le dbut, le planning est dpass. Solution pour la rduction du risque: Il faut une mthodologie qui suit globalement le planning du projet. Use cases concerns : Tous les use cases sont exposs au risque de voir leur laboration et leurs objectifs atteindre mal planifis.

Risque Risque 8

Probabilit 3

Use cases Impact UC=1, 5

+ Exposition 15= high

Justification de la probabilit : Si on a mis en place les mthodes existantes pour viter ce genre de risque, normalement la survenance en est peu probable. De plus, la phase de planification est trs importante. Si elle est mal dfinie, le projet ne peut pas avancer correctement sa phase dlaboration, cest pour cette raison que le SI-UCL veut mettre en place une quipe charger du suivi global du planning16. Nanmoins, cause de risques non prvus ou mal dfinis, le planning peut trs vite tre modifi et pour cette raison, nous donnons une probabilit de 3.
15

La probabilit est proche de 0, mais nous avons tout de mme dcid de mettre 1. Document reu SI-UCL : page 19.

16

37

 Personnel pour ltude du projet demand non comptent. Luniversit doit pouvoir s'appuyer sur du personnel (notamment informatique) possdant non seulement les qualits techniques videntes, mais galement des qualits relationnelles favorisant le travail en quipe ainsi que dindispensables comptences en conduite de projets. Signes prcurseurs : non respect des consignes demands et du planning, rponse flou sur les questions poss sur ses activits. Solution pour la rduction du risque: il faut mettre laccent sur les performances et non plus principalement sur des critres tels que lanciennet et le diplme. La dmarche de lentretien professionnel priodique (EPP) est une solution que tente de mettre en place linstitution. Use cases concerns : Concerne tous les use cases . En effet, le personnel informatique, est toujours prsent derrire les outils utiliss lors des use cases .

Risque Risque 9

Probabilit 2

Use cases Impact UC=1, 5

+ Exposition 10= high

Justification de la probabilit : Les institutions tentent de plus en plus de se prmunir contre le facteur danciennet et mettent les facteurs de comptence en avant.

Manque dadhsion du systme de la part des utilisateurs. Signes prcurseurs : non emploi du systme. Solution pour la rduction du risque: feedback rgulier des utilisateurs sur la mise en place du systme. Use cases concerns : Concerne le projet et sa direction prise plutt que les use cases . Si les utilisateurs nacceptent pas le systme, il risque dy avoir un gaspillage des cots de production (systme qui ne sert rien).

Risque Risque 10

Probabilit 1

Impact 3

Exposition 3= low

Justification de la probabilit : Le manque dadhsion au systme sur le long terme est peu probable car lutilisateur naura pas dautre choix que de lemployer. En outre, le SI-UCL rapporte que le but de la mthodologie actuelle est davoir une attention particulire lanalyse des besoins devrait tre apporte en veillant une reprsentativit optimum des utilisateurs. 17.

17

Document reu SI-UCL : page 19.

38

 Projet final qui ne correspond plus aux attentes du client (institution). En effet, le projet est travaill en une seule fois et sur une longue priode par les informaticiens. Un long moment sest coul entre la collecte des attentes des utilisateurs finaux et la livraison du systme. Durant cette priode les besoins ont volus et le projet final ne correspond plus ceux-ci. Signes prcurseurs : client fait des remarques et prsente des souhaits lors des runions. Solution pour la rduction du risque: Travailler par itration. Il faut livrer tt et rgulirement des logiciels utiles. Use case concerns : concerne la finalit de projet plutt que les use cases .

Risque Risque 11

Probabilit 2

Impact 4

Exposition 8= medium

Justification de la probabilit : Il y a de nombreuses runions sur ltat davancement du projet entre les concepteurs et le client . Si le client dsire bifurquer vers une autre direction, les changements sont normalement directement oprs.

3.4 Priorit des risques

Nous avons dcid de donner une priorit aux risques selon leur degr dexposition. Nous savons que prioriser les risques nest pas ncessaire cette tape l. Nanmoins, nous souhaitions dj donner une vue densemble sur les risques qui aurait plus de probabilit de survenir.

Risques Risque 3 Risque 8 Risque 6 Risque 5 Risque 9 Risque 4 Risque 11

Description Non motivation du personnel Planning mal dfini Manque de coordination Objectifs mal dfinis Personnel non comptent Cot du projet mal dfini Attentes du client diffrentes

Exposition 15 = high 15 = high 12 = high 10 = high 10 = high 9 = medium 8 = medium

39

Risque 1 Risque 2 Risque 7 Risque 10

Difficult dutilisation Non adquation aux besoins des utilisateurs Problmes de scurit Non adhsion des utilisateurs

4 = low 4 = low 3 = low 3 = low

40

4. Les qualits du projet

Les projets lis lvolution dun SI sont souvent sujets des drives en termes de cots et dure, et recouvrent rarement le primtre initialement dfini. La dmarche Qualit est ncessaire pour fiabiliser la gestion de projet au moyen de diffrents outils de normalisation. La dmarche Qualit18 consiste trouver ladquation entre la rponse aux besoins du projet, lexpression correcte de ces besoins par des spcifications adquates qui passent par une coute attentive du client, et une ralisation rpondant lexpression des besoins. Le cycle de Deming montre comment appliquer la dmarche Qualit au processus projet, mais aussi ses taches lmentaires : Il se compose de quatre phases:

la planification ("Plan"): Phase au cours de laquelle sont formaliss les attentes, les moyens et les objectifs la ralisation ("Do"): Elle s'appuie sur les modes opratoires pralablement dfinis la vrification ("Check"): Elle doit se conformer aux processus dfinis en amont avec un souci d'exhaustivit l'action correctrice ("Act"): correction des erreurs constates et mise en place de mesures pour viter qu'elles ne se reproduisent.

Les anomalies dtectes lors des phases de test doivent donner lieu une correction en termes de dveloppement. De nouveaux tests doivent alors avoir lieu afin de s'assurer que les corrections apportes fonctionnent. Pour analyser la qualit des use cases , il faut que ceux-ci respectent certains attributs qualits . Nous avons choisi ceux du FURPS. Nous navons pas prioris les qualits car il est difficile danalyser ce niveau du projet les qualits les plus importantes.

Functionality : - La performance des diffrentes fonctionnalits doit tre acceptable selon les objectifs fixs (accs ais aux sources dinformations, inscriptions aux cours ou luniversit faciles et rapides,). - Il faut que la scurit du systme et des use cases soit adquate et, selon les recommandations du CEDITI, la globaliser pour diminuer les risques [cf. supra] (exemple de scurit : backup de donnes19, vrification des accs avec lidentifiant,).

18

Site : http://www.gestiondeprojet.net/articles/qualite.html

41

Usability: -Il faut que lutilisation des diffrentes fonctionnalits soit intuitive pour le futur utilisateur ( Look & Feel ). Les interfaces doivent, par exemple, tre faciles manier (inscription aux cours, recherches sur le site UCL, ). - Il est important de prvoir un temps de formation pour les systmes (utilisation SAP pour des utilisateurs occasionnel ou dbutant, formation dutilisation du Uportal pour les informaticiens20). -La documentation sur les diffrentes fonctionnalits doit tre complte pour pouvoir tre comprise des personnes qui suivent le projet et pouvoir tre rutilise par aprs (gain de temps). -De mme, le code doit tre correctement comment pour toute autre personne dsirant retravailler dessus (gain de temps).

Reliability : - Le systme et ses diffrents cas dutilisation doivent avoir un minimum de problmes de fonctionnements pour quil soit actif auprs des utilisateurs. Il faudra dfinir la tolrance face aux dfauts. - Il faudra aussi prendre en compte le temps ncessaire pour la remise en tat de fonctionnement du systme. Un systme de qualit est un systme qui prend le moins de temps possible. - Il faut pouvoir avoir un systme de surveillance (mettre en place des signaux) qui prvoit les erreurs possibles du systme avant son plantage. - Il faut avoir un systme de veille prcis et fiable pour surveiller lenvironnement. Il faudra choisir correctement les actes o les informaticiens vont mettre un systme de surveillance.

Performance :

19

Il est trs important quaucune donne ne soit perdue et la maintenance du systme dans son long terme est primordiale. Document reu SI-UCL : page 45.

20

42

- Il faut une vitesse raisonnable des fonctions pour ne pas frustrer les utilisateurs et ne pas diminuer la productivit dans son ensemble (exemple : tches administratives). La rponse du systme doit tre raisonnable et la plus courte possible. - Le dbit (vitesse de connections) doit tre rapide pour que lutilisateur se sente laise et pour lefficacit du systme (il ne faut pas quil rame ). Le temps de raction doit tre le plus cours possible. - Il faut que le systme rponde aux besoins que les gestionnaires de projets ont dfini (meilleures efficacits pour organiser les informations, globalisation des systmes de scurit, accs ais aux sources dinformation, faciliter le suivi des formations,). - Les pc (serveurs) mis en place doivent pouvoir faire face une consommation de ressources importantes vue la quantit de donnes et de traitements de donnes simultanes.

Supportability : - Il faut que le systme soit vrifiable pour pouvoir faire des tests rapidement et contrler sil ny a pas derreurs. - Le systme doit tre flexible pour quil puisse sadapter aux changements dorganisations, fusions, - Le systme doit pouvoir tre conforme aux diffrents standards et norme en cours. Il faudra dfinir quels standards utiliss dans les fonctionnalits du systme (Uportal et SAP). - Le systme doit pouvoir sadapter facilement environnement diffrent (exemple : OS). - La base du systme doit pouvoir tre rutilis pour dautres projets ou doit pouvoir ajouter dautres fonctionnalits (cas dutilisations) facilement selon le changement des besoins ou des objectifs (impratifs exigs par le client).

43

5. Le diagramme de gantt

Nous devons nous dcider sur le nombre ditrations par semaines pour chaque phase. Les estimations gnres par Costar nous indiquent que notre projet durera 22, 9 mois. Pour calculer le nombre de semaines par itrations, nous reprenons la formule suivante : W = (S/1000) W in weeks S in SLOC

S est gal 57 375 lignes de codes et W 7,57. Nous obtenons ainsi le nombre de semaines par itrations. Nous considrons quil 52 semaines par ans pour 12 mois. Pour connatre le nombre de semaines moyen par mois, nous divisons le nombre total de semaines quil y a dans une anne par le nombre de mois quil y a dans une anne : Nombre de semaines par mois : 52 / 12 = 4, 33 Nous devons multiplier 22, 9 mois par 4, 33 et nous obtenons la dure totale en semaine qui est 99, 16 semaines pour notre projet. Pour connaitre le nombre ditrations totales : 99, 16 / 7,57 (dure dune itration) = 13, 10 ce qui nous fera 13 itrations.

Pour connatre le nombre ditrations pour chaque phase et la dure de chaque itration, nous faisons les calculs suivant : Nombre de semaines par phases = Nombre de mois par phases * 4, 33 (nombre de semaines par mois) Nombre ditrations par phases = Nombre de semaines par phases / 7,57 (W)

Phases Inception Elaboration Construction Transition Total

Mois/ phases 2,3 6,9 11,4 2,3 22,9

Semaines/phases 10 semaines 30 semaines 49 semaines 10 semaines 99 semaines

Itrations/phases 1 4 6 1 12
44

Nous avions calcul avec la formule 13 itrations et nous nen comptons plus que 12. Nous avons, en effet, dcid de ne faire quune itration de 10 semaines au lieu des 7,57 calcul pour les phases dInception et de Transition. Nous pensons quune itration dun peu plus de 2 mois se situe dans une marge acceptable de la moyen, qui est de 7,57.

5.1 Priorit des use cases

Nous avons class par ordre dimportance les use cases pour limplmentation de ceux-ci. Nous nous sommes bas sur les documents SI-UCL et les besoins pour nous aider dans ce classement. Nanmoins, une part de lordre donn ces use cases vient de notre propre exprience et intuition. Ainsi, il nous semblait plus logique davoir en premier une administration des finances efficace plutt que amlioration de la gestion des bibliothques. Nous avons comment les use cases les plus importants pour justifier notre ordre. Nous avons prioris nos use cases pour pouvoir, dans le diagramme de gantt, montrer ceux que nous devrons implmenter dans les premires itrations.

Use cases 1. Gestion de la collecte et agrgation des informations 2. Gestion administrative des finances

Justification Le but, entre autres, du SI est une gestion des informations plus efficaces pour des prises de dcisions plus adquates. Prend en charge les dpenses et la comptabilit des diffrentes institutions. Avoir une gestion administrative efficace permet une gestion des cots prcise et moins de dpenses.

3. Gestion administrative du personnel

4. Gestion de la scurit informatique

Les documents sur le projet insistent normment sur limportance dune scurit efficace. Le CEDIDTI souhaite une organisation plus globalisante pour celle-ci (cf. supra). Les principales demandes dans le systme
45

5. Gestion administrative des tudiants

seront composes des tudiants 6. Gestion des informations relatives aux membres du personnel 7. Gestion de laccs du web et aux informations du Web Pour des raisons de scurit, il est important davoir une gestion correcte du Web pour contrler que la bande passante de laccs internet de luniversit ne soit pas majoritairement monopolis par des flux nayant aucun rapport avec les besoins scolaires des tudiants (liste des sites interdits). Contrle aussi des informations sur intranet par luniversit. Pour accder aux rseaux de luniversit, les tudiants et personnels doivent avoir un identifiant (salle informatique, internet, bibliothque, inscription aux cours,) Outil important pour les besoins scolaires des tudiants et des enseignants. Facilite les accs aux informations est un gain de temps/ressources pour les tudiants et donne une image positive luniversit.

8. Gestion de la mobilit de lutilisateur

9. Gestion de la bibliothque lectronique

10. Inscription luniversit et aux programmes de cours 11. Gestion doutils collaboratifs 12. Support informatique pour le personnel et les tudiants 13. Administration du service technique et du matriel 14. Maintenance du matriel 15. Consulter les horaires, les lieux de cours et les nouvelles relatives aux cours 17. Administration de la recherche 18. Gestion de lapport financier la recherche 19. Suivre une formation distance

46

20. Gestion des informations concernant la vie tudiante 21. Gestion administrative des alumni Use case qui se retrouve dans les derniers car ce nest pas un composant principal de luniversit linstar des tudiants Idem

22. Gestion administrative des entreprises 23. Grer et publier des informations relatives aux projets de recherche et aux projets pdagogiques 24. Gestion des relations interuniversitaires

Nous lavons mis en dernier car il est dabord important davoir une bonne gestion interne pour avoir des relations adquates avec les autres universits

5.2 Descriptions des diffrentes phases

Nous souhaitions mettre aussi la description du diagramme de gantt en plus de celui fourni dans le projet avec MS Project. Cela nous semblait plus clair et nous permettait dajouter pour chaque phase les critres dvaluation et le milstone .

Inception
Itration 1
Prise de connaissance du projet et objectifs fixs Business Modeler 1 Dlimiter ltude de cas Business Modeler 2 Dterminer les use cases et les principaux scnarios du projet Requirements analyst 1 Accord de principe sur le cahier de charge avec les clients Requirements analyst 2 Identifier les risques potentiels Requirements Analyst 3 Dterminer le planning (bauche) et prvision de lquipe Project Manager 5 Estimer les cots totaux et le temps du dveloppement Project Manager 5
47

Critre dvaluation
Les critres dvaluation pour atteindre le Lifecycle Objectives Milestone (LCO) sont : Ladhsion des participants sur la dfinition des objectifs et lestimation des cots et du planning
Accord sur les besoins du projet et comprhension de ceux-ci (use cases). Accord sur les estimations du cot et du planning, sur les priorits, les risques et le dveloppement du processus Tous les risques ont t identifis et une stratgie mitigation existe pour chacun.

Elaboration
Itration 1
Dtailler les use cases et modliser le diagramme dactivit Business Modeler 1 Ebauche de larchitecture Business Modeler 2 Dlimitation prcise du systme Business Modeler 3 Dlimitation prcise du contenu technique Requirements Analyst Cration de cas des diagrammes des cas dutilisations Designer Elaboration du plan ditration Project Manager 1 Dmontrer que larchitecture pourra supporter les cots et le planning prvue Project Manager 2

Itration 2
Cration dun planning du contenu technique Requirements Analyst Cration de diagramme de classe Designer 1 Cration dun diagramme dobjet Designer 2 Modification de diagrammes de cas dutilisation Designer 3 bauche de larchitecture globale du systme Soft. Architect Attribution des tches au personnel Project Manager

Itration 3
48

 Dfinir linterface utilisateur du systme selon les besoins des utilisateurs Requirements Analyst Critique des diagrammes Designer Fin de la cration de larchitecture du systme Soft. Architect Cration dun prototype du systme Senior Programmer Prparation de tests pour la validation du systme Tester Etablir les dlais Project Manager

Itration 4
Planification de la phase de construction Project Manager 1 Clture des cahiers de charges Requirements Analyst Architecture finale en intgrant les facteurs de risques et de qualits Project Manager 2 Tests black box Tester

Critres dvaluation
Les critres dvaluation pour atteindre le Lifecycle Architecture Milestone (LCA) sont : Les exigences et la vision sur le produit sont stables Larchitecture est stable Les risques majeurs sont dfinis Preuve des tests cls et des valuations Les plans ditration pour la phase de construction sont dtaills et sont valus selon des estimations crdibles. Respect des ressources relles par rapport aux ressources planifies

Construction
Itration 1
Modification et amlioration des diagrammes Designer Rdaction du rapport UML Soft. Architect 1
49

 Gnration du diagramme relationnel RR Soft. Architect 2 Plan du rapport Soft. Architect 3 Rdaction des spcifications des mthodes Spec. Writer Gestion du changement Project Manager

Itration 2
Modification et amlioration des diagrammes Designer Implmentation : gestion de la collecte et agrgation des donnes Programmer 1 Implmentation : gestion administrative des finances Senior Programmer 1 Implmentation : gestion administrative du personnel Programmer 2 Implmentation : gestion de la scurit informatique Programmer 3 Supervise limplmentation Senior Programmer 2 Modification des spcifications des mthodes Spec. Writer Contrle du projet et son avancement Project Manager

Itration 3
Implmentation : Gestion administrative des tudiants Senior Programmer 1 Implmentation : Gestion des informations relatives aux membres du personnel Programmer 1 Implmentation : Gestion de laccs au Web et aux informations sur le Web Programmer 2 Implmentation : Gestion de la mobilit de lutilisateur Programmer 3 Implmentation : Gestion de la bibliothque lectronique Programmer 4 Superviser limplmentation Senior Programmer 2 Cration de tests white boxTester 1 Lancement de tests black box Tester 2 Supervision du projet et des changements Project Manager

Itration 4
50

 Implmentation : Inscriptions luniversit et aux programmes de cours Programmer 1 Implmentation : Gestion des outils collaboratifs Programmer 2 Implmentation : Support informatique pour le personnel et les tudiants Programmer 3 Implmentation : Administration du service technique et du personnel Senior Programmer 1 Implmentation : Maintenance du matriel Programmer 4 Supervision de limplmentation Senior Programmer 2 Analyse sur les tests effectus Tester 1 Lancements des tests white box Tester 2 Contrle du projet Project Manager

Itration 5
Implmentation : Consulter les horaires, les lieux des cours et nouvelles relatives aux cours Senior Programmer 1 Implmentation : Administration de la recherche Programmer 1 Implmentation : Gestion de lapport financier la recherche Programmer 2 Implmentation : Suivre une formation distance Programmer 3 Implmentation : Gestion des informations concernant la vie tudiante Programmer 4 Supervision de limplmentation Senior Programmer 2 Analyse sur les tests effectus Tester 1 Validation des tests white box Tester 2 Cration de la documentation Spec. Writer Contrle du projet Project Manager

Itration 6
Implmentation : Gestion administrative des alumni Programmer 1 Implmentation : Gestion administrative des entreprises Programmer 2
51

 Implmentation : Grer et publier des informations sur les projets de recherche et projets pdagogiques Programmer 3 Implmentation : Gestion des relations interuniversitaires Programmer 4 Supervision de limplmentation et consultance Senior Programmer 1 Refactoring du code Senior Programmer 2 Validation du systme avec les tests black box Tester 1 Prparation des tests dintgration Tester 2 Faire le dossier du projet avec la documentation ncessaire Project Manager

Critres dvaluation
Les critres dvaluation pour atteindre le Initial Operational Capability Milestone (IOC) sont : Le produit doit entre mature et stable pour pouvoir tre dploy parmi les utilisateurs. Tous les participants doivent tre prts pour le dploiement du produit. Les dpenses ralises doivent tre dans les limites de celles initialement prvues.

Transition
Itration 1
Implmentation des correctifs Programmer Prvoir des correctifs Senior Programmer

beta testing pour valider le systme Reviewer 1

Opration parallle avec un systme lgale qui est le systme remplaant Reviewer 2 Dploiement du produit Integrator 1 Cration de support pour lutilisateur (entrainement des utilisateurs) Integrator 2 Mettre jour les tests et les relancer Tester Cration du manuel pour les utilisateurs Tech. Writer 1 Cration du manuel pour les administrateurs Tech. Writer 2
52

 Cot final du projet et facture Project Manager 1 Finalisation des ngociations avec le client Project Manager 2

Critres dvaluation
Les critres dvaluation pour atteindre le Product release (GA) sont :

La satisfaction de lutilisateur Les dpenses ralises doivent tre dans les limites de celles initialement prvues.

53

50 45 40 35 30 25 20 Implementation 15 10 5 0 IN Effort EL Effort CN Effort TR Effort Assessment Deployment Management Environment / CM Requirements Design

Nous voyons ainsi que la phase demandant le plus d'effort est la phase de construction, et l'activit qui demande le plus d'effort est l'implmentation.

55

Conclusion

Les documents fournis pour lanalyse du projet sont loin dtre exhaustifs. Nous avons analys de nombreux facteurs (cots, efforts, risques,) que sous la base du bon sens. Ce travail ne donne en aucun cas une analyse fine de la manire dont sera dirig le projet, mais met dj laccent sur les difficults quil rencontrera et offre dj une ide sur leffort et le budget quil faut mettre en place. Nous avons, effet, pu avec Costar donner cet effort et ce cot notre projet, mais aussi planifier ce dernier le mieux possible avec Ms Project. Nous avons pu, grce ce travail, voir limportance de grer et de planifier au mieux les projets de grande envergure. Ils ncessitent normment de management et de contrles tant sur les efforts que sur les risques et les qualits. Parmi ces derniers, il faudra faire des choix car prendre tous les risques en compte est impossible et il en va de mme pour la qualit. Nanmoins, vu lavanc de notre projet et le peu dinformations dessus, il tait difficile de choisir quelles qualits auraient convenues. Nous sommes satisfaits davoir pu mener ce projet et de connatre ainsi les problmes inhrents chaque projet en cours.

56

Table des matires

Introduction 1. Estimation du nombre de lignes du code 1.1 Les acteurs 1.2 Les Use Cases 1.3 Estimation du projet 2. Cocomo 2.1 Les scale factors 2.1.1 2.1.2 2.1.3 2.1.4 2.1.5 Precedentedness Development Flexibility Architecture/ Risk Resolution Team Cohesion Process Maturity

2.2 Cost Drivers 2.2.1 Personnel factors

2.2.1.1 Analyst Capability 2.2.1.2 Application Experience 2.2.1.3 Programmer Capability 2.2.1.4 Platform Experience 2.2.1.5 Language and Tool Experience 2.2.1.6 Personnel Continuity 2.2.2 Project related

2.2.2.1 Use of Software Tools 2.2.2.2 Multisite Development 2.2.2.3 Development Schedule 2.2.3 Product related

2.2.3.1 Required Reliability

57

2.2.3.2 Database Size 2.2.3.3 Product Complexity 2.2.3.4 Required Reusability 2.2.3.5 Documentation match to life-cycle needs 2.2.4 Platform related

2.2.4.1 Execution Time Constraint 2.2.4.2 Main Storage Constraint 2.2.4.3 Platform Volatility 2.3 Rsultat: analyses et interpretations
3. Les risques du systme dinformation

3.1 Calcul de la probabilit 3.2 Calcul de limpact 3.3 Risques principaux 4. Qualits du projet 5. Le diagramme de gantt 5.1 Priorit des use cases 5.2 Descriptions des diffrentes phases 6. Le profil RUP Conclusion Bibliographie Annexes

58

Bibliographie

Sites Internet http://www.projectperfect.com.au/info_risk_mgmt.php http://www.mindtools.com/pages/main/newMN_PPM.htm http://www.projectsmart.co.uk/10-golden-rules-of-project-risk-management.html http://www.netcomuk.co.uk/~rtusler/index.html http://www.its.monash.edu.au/staff/projects/project-management/risk/risk-managementguide.pd http://www.its.monash.edu.au/staff/projects/ http://www.its.monash.edu.au/staff/projects/project-management/ http://ddata.over-blog.com/xxxyyy/0/12/23/21/ci/risques/ci-risques-patrick-ger-risco_1_.pdf http://www.anere.com/Gestion_de_projet/GP_OUT_ils.htm http://www.tbmfconsulting.com/ http://www.heig-vd.ch/Default.aspx?tabid=1306 http://rb.ec-lille.fr/ http://objectifperformance.decideo.fr/Management-des-risques-concepts-de-base_a28.html http://www.commentcamarche.net/contents/uml/uml-use-cases.php3 http://www.ibm.com/developerworks/rational/library/content/03July/1000/1251/1251_bestpra ctices_TP026B.pdf http://qse.ifs.tuwien.ac.at/courses/SE1/archiv_WS0304/SEVO-Block2-1-2003-11-13.p http://www.manager-go.com/diagramme-de-gantt.htm http://en.wikipedia.org/wiki/FURPS http://dit.unitn.it/~tomasi/sweng/02-lab4.pd

59

Ouvrages

WEIS (J. W.), WYSOCKI (R. K.), 5-phase project management: a practical planning and implementation guide, s.l., Addison-Wesley, 4e d., 1994.

BURGES (R.A.), WHITE (G.), Building production and project management, Lancaster, Construction, 1979.

Annexes

Nom du fichier Activity.xls Projet1 Gantt.mpp Risk-management-plan-template.xls

Description Fichier exel qui montre les tableaux pour le RUP. Rpertoire contenant les tableaux du logiciel Costar. Fichier MS Project contenant le diagramme de gantt. Fichier exel qui reprend les risqu et leur risk rating .

60