Portail Web Collaboratif de Gestion de Projet

B IZ | P R OJ E T IN N OVAN T - 2006

Portail Web Collaboratif de Gestion de Projet

M

Auteurs : l’équipe SoluBiz

 Florin Duca

 Duc-Ngoc Tran

 Hoang-Lan Tran

 Ioan Moraru

 Trong-Hieu Dang

 Yue Gu

Remerciements :

 David Gindis et Tanguy Risset (tuteurs phase 1)



Information du document

N° de référence du projet 2

Acronyme du projet SoluBiz

Nom complet du projet Portail Web Collaboratif de Gestion de Projet Date de remise officielle 07 avril 2006

Date de remise actuelle 07 avril 2006

Nom du délivrable Cahier ANVAR SoluBiz

Type Document

Statut & version Complet – Version finale 1.0

Nombre de pages 30

Responsable du projet Stéphane Frénot

Principaux intervenants David Gindis, Tanguy Risset

Editeur Equipe Solubiz

Mots clés Travail Collaboratif, Portail Web Historique du document

Version Date Commentaires et faits Statut

0.1 18 mars 2006 Création du document Draft

0.2 26 mars 2006 Réorganisation du document Draft

0.3 29 mars 2006 Inclusion du diagramme de Gantt et

commentaires Draft

0.4 30 mars 2006 Inclusion de l’étude financière et des

concurrents Draft

0.45 1 avril 2006 Inclusion des délivrables, diagramme de

Gantt détaillé Draft

0.5 2 avril 2006 Restructuration du document Draft 0.55 4 avril 2006 Inclusion des détails techniques Draft

0.8 6 avril 2006 Dossier quasi-complet, correction des fautes d’orthographe

Pré- version

1.0 7 avril 2006 Finalisation du document Complet

Chapitre 1 | Présentation du projet

P résentation de l’idée 5 P résentation de l’équipe S olubiz 6

Chapitre 2 | Caractéristiques techniques du projet

Langages de développement 7 Architecture physique 7 Architecture logique 8 Fonctionnalités 11

Chapitre 3 | Déroulement du projet

Répartition des tâches 12 Organisation du projet 12 Liste des délivrables 14

Chapitre 4 | Etude du marché

Analyse de la situation 15 SWOT 16 Concurrence 17 Stratégie de Marketing 18

Chapitre 5 | Analyse des risques et des coûts

Analyse des risques 20 Analyse des coûts 24

Chapitre 6 | Valorisation du produit

Logiciel à acheter 26 Service à prix forfaitaire 26 Cellule de Support technique et Service après vente 26

Chapitre 7 | Evolution et amélioration 28 Acroymes & Bibliographie 29

Table

de

matières

Résumé exécutif

L e travail d ’élabo ratio n d ’u n pro jet inno vant de gestion de projet est le résultat d’u ne in itiative co m m u ne entre l’équ ipe S o luB iz et le département Télécommunications, Services et Usages auquel appartiennent les membres de l’équ ipe.

Le financement du projet est partiellement assuré par le département. Le coût total réel de la réalisation de l’ap p licatio n est estim é à 9 1 6 5 0 € . C e m o ntant sera supporté par les contributions des entités suivantes : le département Télécom et l’équ ipe S o luB iz.

Le point le plus important concernant un logiciel pour une entreprise c’est l’accessib ilité. S ur le m arché il y a d ifférentes so lutio ns pro po sées co m m e p ar exemple application desktop ou application de type client serveur ou application web.

Les applications desktop ou de type client serveur doivent êtres installés sur la machine pour êtres utilisées et pose des problèmes du point de vue accès aux resso urces partagées. D ’un autre coté, ces deux types de so lutio ns po sent beauco up des pro blèm es po ur les accès depu is l’extérieur de l’entreprise et o nt aussi la contrainte de d evo ir in staller l’ap p licatio n en lo cal su r la m ach in e. N o u s avo ns cho isi de m ettre en œ u vre u n po rtail w eb. D e cette faço n, les clients ne so nt pas o bligés d’installer l’app licatio n en lo cal sur leurs m achines et peuvent accéder à l’app licatio n depu is n’im po rte quel po ste avec u n accès internet. E n p lus, les clients n’o nt aucu ne co ntrainte de systèm e d’o pératio n po uvant utiliser so it W indo w s so it linu x et m êm e MacOS.

Ce projet tient à répondre au besoin réel en solution de gestion du travail collaboratif sur le marché. Il existe une multitude de projets disponibles sur le marché qui ont été conçus pour répondre à ce besoin. Ces outils déjà présents sur le marché ont ciblé soit des utilisateurs expérimentés soit des utilisateurs novices. Toutefois, aucune solution ne répond aux besoins des entreprises dont les employés ont un niveau d’expertise varié. Notre solution essaie de répondre à cette variation de niveaux techniques des utilisateurs en proposant des m o d es d ’u tilisatio n configurables.

La plupart des solutions existant sur le marché sont des solutions locales, po uvant répo ndre seu lem ent aux beso ins d ’u ne seule entité d’u ne entreprise o u d’u n gro upe d’entreprises. U n des besoins réel d ’u ne entreprise potentiellement intéressée par un logiciel de gestion de projet est la possibilité d’intég rer des solutions pour gérer le travail collaboratif entre différentes succursales de l’entreprise ou ses partenaires.

Notre application pourra répondre à ce besoin en utilisant des inter-portails.

Un autre point très important pour les applications de type entreprise est la capacité de répondre à la croissance en charge, et de faire de la redondance pour pouvoir assurer un taux de disponibilité près de 100%. Notre solution répond pleinement à ces besoins en se basant sur une architecture orientée services – une technologie relativement innovante.

5

Chapitre 1

Présentation du projet

1.1 P résen tatio n d e l’id ée

Nous proposons de réaliser un produit qui facilite la collaboration entre les d ifférents m em bres d ’u ne équ ipe. N o tre solution peut servir aux entreprises de toutes les tailles, mais grâce à sa facilité d ’intég ratio n d e d ifférentes entités d ’u ne entreprise, notre solution sera très attractive pour les entreprises de taille grande et moyenne, qui constituent donc notre cible principale.

L ’app licatio n est installée sur les serveurs de l’entreprise et l’accès des clients se fait à l’aide des serveurs w eb, via notre portail web. Les administrateurs de l’entreprise peu vent cho isir de rendre le po rtail accessib le depu is l’in térieur de l’entreprise (l’intranet) o u même depu is l’extérieur via l’Internet.

Pour accéder au portail, les u tilisateu rs d o ivent s’au thentifier. T o ut le trafic entre la machine client et les serveurs web hébergeant le portail web est crypté, pour sécuriser le transfert d es in fo rm atio n s co n fid entielles d e l’entrep rise et d e ses employés.

Sur notre portail, il a différents types d’u tilisateu rs, selo n leu r rô le au sein de l’entreprise. A insi il y a le d irecteur de l’entreprise qu i a accès à tous les projets et qui peut créer un nouveau projet et choisir un chef de projet. Il peut aussi choisir les autres membres d e l’éq u ip e o u p eu t laisser ce choix au chef de projet. Le chef de projet est responsable de l’o rg an isatio n d u p ro jet. Il p eu t créer d es tâches et assigner des personnes à ces tâches. Il peut également créer un sous-projet et assigner un chef de sous-projet et les personnes impliqués dans ce sous-projet. Les utilisateurs normaux peuvent ajouter des actions pour les tâches auxquelles ils sont assignés. En utilisant des actio ns, le chef d e pro jet et les autres m em bres de l’équ ipe peu vent vo ir l’avancem ent des d ifférentes tâches d ’u n pro jet. C ’est aussi u n m o yen de vo ir le no m bre d ’heures travaillées p ar u n utilisateur et le d escriptif des tâches qu ’il a fait po ur po uvo ir "p lacer" l’utilisateur dans les tâches où il donne un maximum de rendement.

Tous les utilisateurs peuvent partager des fichiers qui vont êtres "visibles" soit po ur un gro up restreint de perso nnes de l’entreprise co m m e u ne équ ipe soit pour toute l’entreprise.

P o ur am élio rer la co m m u nicatio n au sein d ’u n pro jet o u au sein de l’entreprise, notre portail va avoir un "message board" qui est un endroit ou tous les utilisateurs peuvent écrire des m essages destinés au x autres m em bres d ’u n pro jet o u à tous les m em bres de l’entreprise et aussi lire les m essages des autres ainsi que les messages automatiques comme les dépassements de deadline ou la fin alisatio n d ’u ne tâche.

D ans le cadre de l’entreprise et m êm e dans le cadre d’un pro jet, il y a des décisions importantes à faire qui concernent tout le monde, et afin de minimiser le temps d’envo i des questio ns et de traitement des résultats, notre portail offre la possibilité de faire des enquêtes. Les enquêtes peuvent êtres très utiles par exemple lorsqu ’il faut faire un cho ix d ans le cadre d ’u n pro jet et qu’il est cho isi de faire un vote pour se décider sur la solution à adopter ou même quand on veut avoir un feedback des différents utilisateurs sur une opération ou un projet.

Les logiciels disponibles sur le marché sont difficiles à utiliser et assez lourds du po int de vu e grap hiqu e. C ’est un po int très im po rtant pour les entreprises, étant

C h ap itre 1 | P résen tatio n d e l’id ée

6

donné q u e l’ap p licatio n d o it être utilisée p ar to u s les m em bres d e l’entrep rise q u i peuvent être informaticiens ou non. Nous voulons réaliser plusieurs interfaces utilisateur, chacune avec ses fonctionnalités spécifiques adaptées au rôle de la perso nne dans l’entreprise (d irecteur, chef de pro jet o u sim p le m em bre de l’équ ipe) mais aussi adaptés aux connaissances techniques de la personne. En utilisant une nouvelle technologie, AJAX, on propose des interfaces utilisateur configurables. En fait les utilisateurs peuvent cho isir p arm i u ne g am m e d ’interfaces déjà faites mais aussi peuvent les personnaliser. Dans ce contexte de page web, on comprend par interface la m o dalité de présentatio n des do nnées à l’utilisateur m ais aussi le cho ix des données à présenter sur une page.

L e p ro jet q u ’o n p ro po se d e réaliser u tilise u ne arch itectu re o rientée services, qui est une technologie émergente. En utilisant cette architecture, on a un meilleur co ntrô le sur les d ifférentes entités de l’app licatio n, m ais au ssi u ne m o du larité fonctionnelle qui aide beaucoup dans la phase de développement et nous offre une grande facilité d’évo lutio n. Grâce à l’utilisatio n d’une architecture o riente services, o n peut réaliser la redondance et la distribution des charges des différentes entités de l’app lication. Un autre avantage qui resso rt d’une architecture o rienté services est la po ssibilité d ’utiliser les d ifférentes entités d ’une app licatio n dans u ne autre application, de cette façon on réalise l’intég ratio n d e d eu x ap p licatio ns d ifférentes o u de d eu x in stances d ifférentes d ’u ne même application.

1.2 Présentation de l’éq u ip e S o lu B iz

Les six membres d e l’éq u ip e S o lu B iz et leu rs co m p étences :

Florin DUCA C hef d’équipe

Responsable des ressources humaines Manager Commercial

Administrateur base de données Responsable Services Web Responsable des tests : Sécurité Duc Ngoc TRAN

Responsable Marketing Web Design

Pages ASP.NET

Responsable des tests : services Web

Ioan MORARU Responsable Qualité Responsable Services Web Responsable Sécurité

Responsable des tests : pages ASP Hoang Lan TRAN

Responsable Marketing

Administrateur base de données Responsable schémas

Responsable des tests : pages ASP

Yue Gu

Responsable Qualité

Administrateurs serveur fichiers Responsable sécurité

Responsable des tests : schémas

Trong Hieu DANG

Manager Finances & Budgets Web Design

Pages ASP.NET

Responsable des schémas Responsable des tests : base de données

7

Chapitre 2

Caractéristiques techniques du projet

2.1 Langages de développement

Ce projet va être réalisé sur Visual Studio 2005, dans le langage de programmation C# et ASP.NET. On va également utiliser Visual Studio Tools for Office 2005, Web Services Enhancements 2, Web Services Administration Tool.

L e systèm e d ’exp lo itatio n co nseillé po ur la m ise en œ u vre de no tre so lutio n et aussi ce q u ’o n v a u tiliser pour les tests est Windows Server 2003 R2.

Pour utiliser la technologie AJAX (Active Javascript And Xml) avec un minimum de temps de développement et d’intég ratio n, o n va u tiliser l’exten sio n d e l’A S P .N E T no m m é A tlas (qu i perm et d’utiliser A JA X dans les pages A S P .N E T ).

2.2 Architecture physique

D ans le schém a su ivant vo us po uvez rem arquer l’architecture physiqu e nécessaire po ur la m ise en œ uvre de no tre app licatio n. B ien évid em ent, c’est l’architecture po ur des entreprises qu i o nt une grande ch arge de travail et qui so uhaitent que l’app licatio n satisfasse des conditions telles qu ’u n petit délai de réponse et un très grand d éb it d ’u pload ou de download.

Figure 1 : Architecture physique

Une version réduite de cette architecture est tout à fait envisageable. Par exemple, un seul serveur web qui contient également les fichiers, la base de données, et qui so it dans le do m aine L D A P de l’entreprise o u qu’il so it un co ntrô leu r de do m aine. C ’est une so lutio n qu i nécessitais seu lem ent un seu l serveur po ur la m ise en œ uvre de no tre applicatio n, m ais qu i est déco nseillé, car, dans u n réseau, po ur des raiso ns de sécurité, c’est co nseillé de séparer les d ifférents rô les sur des m ach ines d ifférentes et m êm e d ’utiliser u ne zo ne dém ilitarisée (D M Z ). L a D M Z est en fait u ne zo ne de passage entre le réseau interne et le réseau externe (l’internet) et par defau lt, les serveurs web se trouvent dans cette zone.

Chapitre 2 | Caractéristiques techniques du projet

8

2.3 Architecture logique

Le schém a su iv ant rep résente l’arch itectu re lo g iq u e d e no tre ap p licatio n. N o u s avons choisie une architecture orienté services (SOA – Service Oriented Architecture) qui nous donne une grande flexibilité et modularité. Cette architecture nous offre aussi la possibilité de faire de la redondance des services pour faire pouvoir répondre au d isfo nctio nnem ent du serveur qu i les héberge. L ’architecture S O A no us o ffre au ssi la po ssibilité d’intégrer facilem ent des no uveau x m o du les o u de faire l’intégratio n avec d’autres services (qu i p eu vent m êm es êtres dévelo ppés en d’autres langages de programmation comme le Java) ou mémé de permettre aux autres applications d’utiliser les services o fferts par notre applicatio n.

Figure 2 : Architecture logique

Le service web «Authentification, Données Utilisateurs» réalise l’authentificatio n des utilisateurs mais aussi offre les informations liées à leurs comptes (co m m e p ar exem p le l’ad resse p o stale, l’ad resse m ail, o u la d escrip tio n d u compte). Dans les architectures de type entreprise la meilleure façon de réaliser cette fo nctio ns est d’utiliser les co m ptes utilisateurs depu is l’annuaire L D A P (A D - Active Directo ry d ans le cas M icro so ft). E n s’ap p u yant su r l’an nu aire L D A P o n p eu t bénéficier d’u n côté d’une co uche de sécurité de sto ckage des co m ptes m ais aussi d’u n autre côté, facilité d’ad m in istratio n et centralisatio n des do nnées. P o ur les utilisateurs, le fait d ’avo ir p lu sieu rs co m p tes c’est d ’u n côté difficile à maintenir à jo ur et d’un autre côté, difficile à gérer l’authentificatio n à cause de l’utilisatio n de p lusieurs m o ts de passes. L ’inco nvenant d’utiliser cette m étho de est le fait qu e les utilisateurs doiv ent avo ir u n co m p te d ans l’an nu aire L D A P . D an s le cas d e commercialisation de notre solution comme service, pour utiliser ce type de solution, o n devrait créer un co m pte dans l’annuaire L D A P po ur chaque utilisateur qui po uvait être contraignant comme approche. Une autre solution serait d ’u tiliser u n serveu r RADIUS (IAS-Internet Authentification Service dans le cas Microsoft) pour faire l’authentificatio n des utilisateurs qu i ne so nt pas dans l’annuaire L D A P . L e serveur RADIUS (Remote Authentification Dial In User Service) est en fait conçu pour faire

9

du AAA (authentification, autorisation et accounting) pas seulement depuis des co m ptes utilisateur depu is l’annuaire L D A P m ais aussi à partir des basses de do nnées ou des fichiers de texte qui contient des informations des utilisateurs. Ainsi on po urrait utiliser l’annu aire L D A P po ur authentifier les utilisateurs qu i o nt un co m pte dans le do m aine et le serveur R A D IU S po ur authentifier ceu x qu i n’o nt pas un co m pte dans le domaine. En début de projet, une réflexion va être menée pour bien considérer la m étho de d’authentificatio n qu’o n va cho isir d’utiliser.

Le service web «Données Utilisateurs» o ffre les do nnées d ’u n utilisateur de no tre applicatio n co m m e par exem p le so n rô le dans l’entreprise (so n do m ain e d’activité dans l’entreprise co m m e par exem p le D R H , m arketing, so ftw are architecte, dévelo ppeur o u desig ner graphique), les pro jets qu’il a en co urs, ses actio ns dans le cadre des projets, et le thème graphique choisie.

Une première utilisation de ce service web est d e fo u rn ir les d o nn ées d ’u n compte utilisateur (données qui sont en fait une extension de données présentes dans l’annuaire L D A P et qui vo nt être utilisées par notre app licatio n).

Une deuxième utilisation de ce service web est un rapide data-mining dans la base de données, pour pouvoir fournir des informations liées au travail de ce utilisateur dans le cadre de l’entreprise (par exem p le heures travaillées, no m bre d’actio ns faites, no m bre des pro jets do nt il a fait partie o u il fait actuellem ent partie).

Une troisième et très importante fonctionnalité offerte par ce service web est l’accès au thèm e grap hiqu e de l’utilisateur. O n utilise la techno lo g ie A JA X qu i no us perm et à l’utilisateur de cho isir les info rm atio ns qu’il veut «vo ir» sur une page et aussi de «réarranger» les informations dans la page (par exemple plus haut, au plus a droite). Pour ne pas perdre ces informations, on va les stocker dans la base de données et les récupérer plus tard, grâce à ce service web.

Le service web «Fichiers» gère les fichiers partagés dans le cadre des projets.

Pour stocker les fichiers on peut adopter plusieurs solutions allant de simple stockage des fichiers sur le d isc dur et envo ie des fichiers en utilisant un proto co le P 2P , jusqu ’à un serveur ftp classique. Le besoin d e p o u vo ir g érer les d ro its d ’accès au x fich iers, d e crypter tout le trafic qui passe sur le réseau et de gérer les accès concourants nous a poussés à adopter une solution basée sur WebDav. WebDav est un protocole conçu pour le partage des fichiers parmi plusieurs utilisateurs et il est déjà implémente dans Windows Server 2003. Le fait de pouvoir gérer les accès concurrents (si un utilisateur o uvre un do cu m ent en écriture, les autres peuvent l’o uvrir qu’en lecture seu le o u le télécharger en local), les droits des utilisateurs ainsi que le cryptage du trafic entre le client et le serveur qui héberge ce service nous offre un minimum de travail pour la m ise en œ u vre dans le cadre de no tre so lutio n. Il faut par co ntre envisager une étude minutieux en début du p ro jet p o u r être su r q u e c’est la m eilleu re so lu tio n à ad o p ter. Il faut aussi prendre en compte des solutions de type stockage dans la base de données, en considérant aussi les avantages que SQL Server 2005 peut nous offrir en ce point de vue.

Le service web «Statistiques et Schémas» offre des statistiques sur les durées des différents projets, les heures de différentes actions, les actions en cours et aussi génère les données pour les schémas (par exemples les diagrammes de Gantt). Le but de ce service est de faire des recherches sur les bases de données et de fournir des données précises qui vont êtres utilisées par les pages ASP.NET pour générer des schémas à partir de ces données. Pour générer les schémas, soit on fait le dessin direct (en dessinant des figurer géométriques du base et en écrivant du texte sur un canvas), soit on utilise un API de dessin inclus dans Visual Studio ou à inclure dans Visual Studio, soit on utilise VSTO (Visual Studio Tools for Office). La dernière solution

Chapitre 2 | Caractéristiques techniques du projet

10

nous semble la plu s ju ste et sim p le à m ettre en œ u vre m ais en d ébu t d u p ro jet, u ne réflexion va être menée pour décider la meilleure solution à utiliser.

Le service web «Message-board et Enquêtes» renvoie les messages écrits par les utilisateurs pour les autres utilisateurs qui font partie du même projet ou sous- pro jet, m ais aussi gère les enquêtes (par exem p le u ne questio n po ur toutes l’entreprise ou toutes les mem b res d ’u n p ro jet). L e "m essag e-board" est en fait un endroit dans notre portail ou les utilisateurs peuvent écrire des messages destinés aux autres gro upes d’utilisateurs o u m êm e à to ute l’entreprise et aussi lire les m essages écrits par les autres. Sur le message-board il y a aussi des messages automatiques de type projet fini ou tâche finie pour prévenir les utilisateurs des événements important qui se sont produits dans les projets mais il y aurait aussi des alertes de type dépassement de dead line po ur attentio n l’utilisateur.

Ce service offre aussi la possibilité de faire des enquêtes, qui sont en fait des sondages. Quand il faut faire une décision de commun accord, on peut procéder à un tel sondage. De cette façon le vote serra anonyme ou pas (à décider par le créateur de l’enquête) et sim p le à faire. O n peut égalem ent utiliser cette fo nctio nnalité po ur créer un sort de formulaire à remplir par les autres utilisateurs pour demander par exemple un feedback sur un projet ou une action.

Le service web «Projets» nous offre les données des projets en cous, les tâches, les actions, les délais, les ressources, en gros, toutes les informations sur un projet. Ce service w eb fo urnie u ne vu e d’u n pro jet avec to utes les détailles nécessaires.

Le service web «Administration» o ffre au x ad m in istrateu rs d e l’entrep rise d es do nnées sur l’utilisatio n de l’app licatio n o u différents services, les éventuelles erreurs o u pro blèm es renco ntrées par l’app licatio n, l’utilisatio n d es resso urces des m achines physiques qui héberge les différents services. Ce service offre aux administrateurs la possibilité de voir les logs qui contiennent les erreurs et les alertes liées à notre app licatio n. Il o ffre au ssi des statistiques qu i m o ntrent l’utilisatio n des resso urces des machines physiques comme les ressources réseau, la mémoire occupée sur le disque dur, la m ém o ire vive, l’utilisatio n des services web, pour que les administrateurs peuvent voir la charge des différents machines physiques pour pouvoir anticiper la cro issance et po ur po uvo ir prévo ir l’acqu isitio n d’un autre serveur po ur répo ndre à la croissance en charge. Le principe est de faire du Remote Monitoring des machines sur lesquelles o n a m is en œ u vre no tre applicatio n et de regarder les co m pteurs de performances.

Le service web «Intégration Inter-Portails» offre la possibilité de faire l’intégratio n avec le po rtail d’u ne autre entreprise, mais aussi gère une petite base de données. Cette petite base de données sert comme cache et contienne les données de l’entreprise d istante qu i o nt étaient récem m ent utilisées o u qui so nt d’im po rtance haute do nc utilisées fréquem m ent. L e principe est d’avoir une copie locale des in fo rm atio ns les p lu s utilisées de l’autre entreprise po ur am élio rer le tem ps de répo nse de l’app licatio n, m ais au ssi po ur ne pas o ccuper beauco up d’espace lo cal.

Pour sécuriser la communication entre les services web, on va utiliser l’encryptio ns de type S S L o u IP sec en m o de tunnel. P o ur bénéficier du p lu s haut dégrée de sécurité, il faudrait m ettre en œ uvre IP sec m ais l’inco nvénient vient du fait qu’IP sec nécessite la m ise en œ u vre d’u ne architecture de certificats. P o ur faire cela il faut utiliser un CA (Certificate Authority) qui va émettre des certificats pour les services w eb. U ne étude en début de pro jet par la gro upe qui s’o ccupe de la p artie sécurité à pour but de chercher la meilleure solution pour la sécurisation des communications entre les services web.

11

2.4 Fonctionnalités

F o n ctio n n alités d ’u sag e Fonctionnalités côté utilisateur

Voir / valider les tâches qui lui sont assignés Partager des fichiers

Modifier des documents

Ajouter des actions pour une tâche qui lui est assigné Regarder/écrire sur le « message board »

Etre responsable de sous-projets

P ossibilité de voir l’avancem ent d’un projet (sur des diagram m es de G antt) Répondre aux sondages

Besoin de login et mot de passe pour la connexion Fonctionnalités côté chef de projet

Etre un utilisateur et bénéficier des fonctionnalités côté utilisateur Ajouter une nouvelle personne et ses droits à une certaine tâche Créer des sous-projets

Assigner des tâches

Faire une arborescence des tâches

Lancer un sondage (envoyer une question à un group d’utilisateurs)

V oir des statistiques d’un projet (état avancem ent, actions, nom bre d’heures travaillées) Fonctionnalités côté d irecteu r d ’en trep rise

V ision globale sur toute l’entreprise Accès dans tous les projets Créer un nouveau projet

Possibilité de choisir les m em bres de l’équipe et le chef de projet Possibilité de choisir si un projet est public ou privé

Lancer un sondage

Fonctionnalités côté administrateur

Ajouter des serveurs pour faire de la redondance/distribution des charges Voir des informations sur les services web déployées

Contrôle du serveur

F o n ctio n n alités d ’estim e Fonctionnalités générales

Possibilité de choisir parmi plusieurs thèmes graphiques de base Possibilité de personnaliser un thème graphique

Possibilité de sauvegarder ses propres configurations Documentation technique en ligne

Agenda, calendrier

Possibilité de faire des Statistiques (heures travaillées, performances) Alerte sur les dépassements de délai des tâches assignées

Fonctionnalités côté utilisateur

Alerte sur les dépassements de délai des tâches d’un projet assigné Fonctionnalités côté chef de projet

Rétroaction des tâches

Fonctionnalités côté administrateur

V oir les m essag es d’erreurs et les alertes et sau vegarde dans un log Installation et configuration des stations à distance

P ackage d’installation pré configurée

Chapitre 3 | Déroulement du projet

12

Chapitre 3

Déroulement du projet

3.1 Répartition des tâches

La partie technique de notre projet est assez vaste et nécessite plusieurs tâches différentes pour répondre aux différentes technologies utilisées. Pour maximiser le rendem ent des m em bres de l’équ ipe S o luB iz et en mêm temps minimiser le nombre de bugs pouvant su rven ir, au cu n travail d e d évelo p p em ent ne s’effectu e p ar u ne seu le personne, mais par un groupe de plusieurs personnes.

Chaque personne sera membre de deux ou trois groupes de travail et chaque gro upe de travail est co m po sé d e deu x perso nnes. P o ur répo ndre au beso in d ’avo ir aussi des testeurs dans la co nceptio n d ’u n lo g iciel, chaque personne est assignée la responsabilité de faire les tests sur le travail fourni par un groupe dont il ne fait pas partie. Evidemment, le groupe de développement doit aussi faire des tests pendant la phase de développement. Cependant le fait q u ’u ne au tre p erso n ne q u i n ’a pas participé dans cette partie fait les derniers tests et lit la documentation apporte une autre vue sur la partie.

Table 1 : Compétence technique Duc Ngoc TRAN

Florin DUCA

Hoang Lan TRAN

Ioan MORARU

Trong Hieu

DANG Yue GU

Web design

  

Pages ASP.NET

  

Administrateur base

de données

  

Services Web

  

Schémas

  

Sécurité

  

Administrateur

serveur de fichiers

   





La base de données est un facteur très important dans le projet vu que la quasi- totalité des m o du les s’appu ie sur cette partie et une faute dans la conception peut entraîner de g raves p ertes d e tem p s d ans le reste d u p ro jet. P o u r essayer d ’év iter ce problème le mieux, la première semaine est dédiée à la conception de la base de do nnées et to us les m em bres de l’équ ipe vo nt travailler sur cette partie afin de prévoir tous les problèmes éventu els et d ’im ag in er les d ifférents scénario s d ’u tilisatio n.

13

Figure 3 : Diagramme de Gantt 1 Gestion du site web du projet 2 Documents techniques 3 Comptes rendus des réunions 4 Planification de la Base de Données 5 Gestion de la sécurité

6 Gestion pages ASP 7 Design graphique 8 Testing et Debugging

9 Création de la version beta du produit

10 Tests de sécurité

11 Création de la version finale du produit 12 Administration de la base de données 13 Gestion des Services Web

14 Gestion des fichiers

15 Création du program d'installation 16 Création maquette de présentation 17 Création manuel d'utilisation 18 Présentation Finale

Après cette phase de conception, un groupe va continuer de travailler sur la gestion des bases de données. Les autres groupes vont commencer les tâches principales avec la gestion et le design des pages web, la gestion des services web, la gestion des fichiers et la sécurité.

Des réunions successives pendant cette période vont diminuer le travail nécessaire po ur l’intero pérabilité entre différents modules, et également pour décider ensemble quand nous avons des choix importants à faire qui peuvent avoir un impact sur plusieurs modules. Chaque groupe a trois délivrables pendant cette période de cinq semaines pour assurer le bon déroulement du projet. Ces délivrables sont présentés en détail dans la partie suivante. [cf. 3.4]

U ne autre équ ipe va s’o ccuper de la partie sécurité et elle va travailler avec tous les autres gro upes afin d’assurer qu ’il n’y a pas de points faibles dans un certain module et aussi pour avoir une architecture sécurisée du point de vue globale.

A la fin des cinq semaines prévues pour ces différentes tâches, il y aura la création d’u ne versio n bêta de notre application.

Chapitre 3 | Déroulement du projet

14

Après la création de la version bêta, il y a une étape de deux semaines de tester et de débogger des différents modules ainsi que de sécurité et de pénétration.

Le vendredi 4 juin 2006 et pendant le weekend qui suit, on va créer la version finale du produit en faisant le réassemblage tous les modules avec les modifications déjà faites pendant la phase de test et débogage.

Après la création de la version finale du produit, les deux semaines qui suivent, le travail se décompose en trois parties : la création du programme d ’in stallatio n, la créatio n de la m aquette po ur la présentatio n et la créatio n du m anuel d’utilisatio n.

3.4 Liste des délivrables

La numérotation des tâches ainsi que des sous-tâches corresponde à la numérotation présentée dans le diagramme de Gantt présente dans la partie antérieure.

[cf. 3.3, Figure 3]

Conception de la Base de données 4. Première version de la base de données Gestion de la Sécurité :

5.1 Modes d ’au thentificatio n : AD, RADIUS (IAS), Base de données 5.2 Sécurisation des communications entre les services web (SSL, IPsec) 5.3 Sécurisation d u site w eb (H T T P S , q u els p ag es … )

Gestion des pages ASP & Design Graphique : 6.1 & 7.1 Travail avec AJAX (avec le api ATLAS)

6.2 & 7.2 Thèmes graphiques création/sauvegarde dans la base de données 7.3 Finalisation du design graphique

Administration de la base de données :

12.1 Scripts de création de la base de données, création des requête de base 12.2 Création des requêtes pour les graphes et schémas

12.3 Base de données dédiées à l’intég ratio n inter-portails Gestion des Services Web :

13.1 Création des services web, avec des méthodes vides

13.2 Redondance et load balancing des services web (UDDI, WSDL) 13.3 Création d u serv ice w eb d ’ad m in istratio n

Gestion des fichiers :

14.1 Recherche sur le protocole à utiliser (FTP, http, WebDav) 14.2 Mise en œ u vre d u p ro to co le cho isi

14.3 Mise en œ u vre d es d ro its d ’accès et accès co ncu rrents 9 Versions bêta d e l’ap p licatio n

11Version final du produit ////

15 Création du programme d'installation 16 Création maquette de présentation 17 Création manuel d'utilisation

15

Chapitre 4

Etude du marché

4.1 Analyse de la situation

Segmentation ciblée du marché

L e m arché étud ié se situe dans le do m aine de l’in fo rm atique et p lu s spécifiquement celui des logiciels de travail collaboratif.

La segmentation du marché révèle de groupes différenciés. Nous ciblons principalement le secteur des entreprises dont le système informatique est développé car ce sont ces entreprises qui sont disposées à investir des fonds dans une solution informatique. Toutefois, nous ne négligeons pas les sociétés peu évoluées du point de vue informatique mais qui ouvertes au développement.

Dans la segmentation d e m arché v isé, les critères p o u r le cho ix d ’u n logiciel so nt la facilité de m ise en œ uvre, la sécurité des d o nnées, la po ssib ilité d ’évo lutio n, la stabilité du pro duit (en term e de taux d e service), la facilité d ’utilisatio n m ais aussi les fonctionnalités offertes par le p ro d u it. L ’u tilisatio n d es no u v elles technologies est aussi un critère très important et quelquesfois déterminant, car la politique des entreprises est de migrer vers les solutions techniques de pointe.

Il faut aussi prendre en compte le coût du produit et aussi les types de licences disponibles. Pour le secteur du marché visé, les entreprises ont un grand nombre d’em p lo yés, l’achat d’u n grand no m bre des licences serait un investissement important et seu lem ent p eu d ’entrep rises sero nt p rêtes à le faire. Un faible prix ou même un prix fo rfaitaire d o n nerait la p o ssib ilité d ’élarg ir l’esp ace d es clients intéressés et de rendre notre offre plus attractive.

Besoins actuels et potentiels

Aujourd'hui, dans le monde des affaires, terminer un projet à l'heure et sous le budget est primordial. Perd re d u tem p s entraîne u n e p erte d ’arg ent m ais au ssi u n p o int faible par rapport à la concurrence.

Les entreprises de taille grande et moyenne utilisent fréquemment une architecture séparée en plusieurs succursales et cela entraîne un affaiblissement dans la co m m u nicatio n au sein de l’entreprise.

Le besoin de collaboratio n s’exp rim e au niveau des entreprises de toutes tailles qui fonctionnent par groupes de travail, et a tous ceux qui veulent structurer, assurer et optimiser le bon déroulement d'un projet suffisamment complexe.

La demande dans ce secteur est importante : une simple recherche sur Internet rend compte du nombre de logiciels existants destinés à la satisfaire. Ces logiciels offrent les fonctionnalités de base requises pour la gestion de projets.

Les utilisateurs actuels o nt u ne fo rte m o b ilité et o nt beso in d ’u n o u til q u i s’adapte m ieu x à leurs pro jets et surtout à leurs connaissances techniques. Les solutions disponibles sur le marché visent des utilisateurs avec un niveau précis de compétences techniques, soit novice soit expert. Le problème rencontré par les entreprises avec ce typ e d ’ap p ro che est le fait q u e les u tilisateu rs q u i se servent d ’u ne telle solution ont des compétences techniques très variées.

Chapitre 4 | Etude du marché

16

Historique de croissance du marché

Les années 80 marquent une augmentation considérable du nombre d’o rganisatio ns utilisant des lo g iciels servant à planifier, contrôler et développer des projets. En 1984, 70% des organisations disaient q u ’elles n’u tilisaient au cu n o u til d e ce genre. Ce taux a été réduit à 30% en 1988, et le sondage en 1992 a montré que le taux est d escend u à m o in s d e 1 5 % . L e no m bre d ’o u tils et d ’organisations qui les utilisent continue d ’au g m enter san s cesse. U ne étude récente su r l’évo lu tio n d u marché des logiciels de gestion de projet m o ntre q u e le m arché a au g m enté ju sq u ’à 750 millions de USD, et dépassera 1,2 billion de USD en 2006.

(D ’ap rès http://www.computing.dcu.ie/~roconnor/phd/chapter2.ps) 4.2 SWOT

Points forts

Expertise : Tous les membres de notre équipe connaissent très bien le domaine technique du projet : développement en langage C#, maîtrise es technologies comme ASP.NET, AJAX, expertise dans la programmation des applications web-based, programmation objet orientée...

Perception du point de vue du client : En effet, étant donné que nous sommes nous-même entrain de réaliser un projet, nous analysons en détails les difficultés que nos futurs clients peuvent rencontrer. En nous situant à leur place, nous comprenons ce que les clients attendent d’un tel outil de gestion de projet.

Points faibles

Marketing : E tant u n p etit g ro u p e, no u s n’avo n s p as su ffisam m ent d e ressources pour faire de grandes campagnes de marketing. Nous allons nous appuyer sur le bouche-à-oreille comme moyen essentiel pour propager notre produit et notre réputation.

Ressources humaines : Etant un groupe limité en nombre, nous aurons de difficultés en développant certaines parties, par exemple les documents et la présentatio n (m anque d’expert de desig n grap hiq ue). U ne absence im prévue po urrait aussi entraîner des problèmes

Prestige : Quelques fois, un client décid e d e cho isir u n o u til d ’u ne grande marque tel que Microsoft P ro ject, @ T ask , ...ju ste p arce q u ’il veu t être p lu s sécu risé.

Nous sommes une nouvelle entité sur le marché, notre produit séduit les clients grâce à son aspect innovant, mais les clients peuvent aussi tro u ver risq u é d ’acheter d e nouveaux produits.

Opportunités

C roissan ce d e l’Internet : La grande majorité des entreprises de nos jours utilisent Internet, et puisque notre produit est web-based, les utilisateurs se familiariseront facilement à son utilisation.

Menaces

Internet est à la fois une opportunité et une menace : Exemple spécifique : Notre objectif est de franchir les frontières et de viser le marché mondial, de telle sorte que nous voulons choisir des prix différents dépendamment du pays dans lequel le produit est vendu. Cependant, les clients pourront maintenant comparer facilement le prix et acheter le produit en ligne.

Les concurrents directs ou indirects : cf. partie suivante.

17

4.3 Concurrence

La concurrence a plusieurs formes :

a. La « concurrence » la plus signifiante est « ne pas utiliser de logiciel de gestion de projet » : L ’entrep rise cho isit de conduire elle-même le projet. Le chef de projet fait le planning, estime les ressources, organise le travail, assigne les tâches, contrôle la progression et analyse le résultat comme une part de son travail normal.

Notre atout par rapport à ce type de conduite de projet est que notre produit aide les chefs de projet déjà surchargés à simplifier leur travail, à réduire le temps et donc, à travailler de manière plus efficace. On pourrait facilement convaincre les clients en démontrant les quelques fonctionnalités les plus avantageuses que notre produit apporte.

b. Les logiciels ayant du prestige dans le monde de gestion de projets, notamment @task. Celui-ci est l’ap plication la plus appréciée par la plupart des revues grâce à sa facilité d ’usage, sa richesse en fonctionnalités et sa diversité de supports disponibles aux clients. Ce logiciel montre également une grande flexibilité grâce à la technologie Java-based – il est indépendant de la base de données, indépendant de la plateforme et du navigateur. Cependant, nous pourrons toujours concurrencer avec lui en exploitant ses points faibles. Un des points importants est que @task est p erfectio n n iste, il veu t p laire à to ut le m o nd e, et il n’a p as d e v ersion déd iée à chaque type d’entreprise. D u co up, beauco up de fo nctio nnalités avancées deviennent inutiles pour les entreprises de taille moyenne et petite, et même les fonctionnalités de base sont quelque fois trop compliquées à configurer et à utiliser correctement.

c. Le troisième type de concurrent est les logiciels libres. Ces logiciels offrent plusieurs avantages incontestables : lib erté d ’exécu ter le lo g iciel p o u r n’im p o rte q u el usage, suppression du coût direct (aucun frais relatif à la licence peu importe le nombre de postes), réduction du coût indirect (des mises à jour, correctifs de sécurité) et une communauté des clients. Nous pouvons mentionner le nom de quelques représentants de la famille freeware dans le monde des logiciels de gestion de projet : Open Workbench, dotProject, Taskjuggler...

Des logiciels libres

Gantt Project

Open Workbench

Imendio planner

Task

juggler PhpCollab dotProject TinyERP Facilité de

migration depuis MS Project

3 3 3 0 0 0 0

Fonctionnalités 3 4 3 3 3 2 3

Rapports de

contrôle 2 4 3 3 1 1 2

Ouverture du

projet 4 1 4 4 4 4 2

Communauté 4 4 1 3 3 4 3

Total 16/20 16/20 14/20 13/20 11/20 11/20 10/20

Table 2 : Comparaison des solutions open sources

Source : project-management-softwares.org/review.aspx

Chapitre 4 | Etude du marché

18

Ces logiciels sont de vrais compétiteurs, pourtant il leur manque plusieurs fonctionnalités techniques afin de devenir un logiciel complet de gestion de projet.

Nous pouvons citer quelques exemples :

Open Workbench : ne permet pas de mesurer la durée des tâches en heures, ne perm et pas l’expo rtatio n en fo rm at X M L , M S P roject ne lit pas co rrectem ent la durée des tâches

dotProject : N e p erm et p as l’assig natio n et la distribution automatique des resso urces, ne perm et pas d’im po rter o u d’exporter des bases de données, il est très difficile de v isu aliser l’in d icatio n d e resso u rces su rcharg ées

Taskjuggler : Demande un effort initial pour maîtriser le langage de pro gram m atio n de l’o util, documentation qu’en anglais

De plus, ils offrent insuffisamment de supports, ainsi les utilisateurs pourront renco ntrer des difficu ltés lo rs de l’utilisatio n.

d. Il ne faut surtout pas oublier les concurrents indirects – les solutions alternatives, notamment Microsoft Project. Ce titan dans le monde informatique met sa main sur plus de 60% des parts du marché des logiciels de gestion de projet installés directement sur les postes de travail. Microsoft Project est le plus proche du

« parfait » en ce qui concerne les fonctionnalités offertes, malgré son vieil algorithme (développée depuis les années 1950). Néanmoins, contrairement à des logiciels de type web-based , le fait d ’être installé in d ép end am m ent su r chaq u e o rdinateur lui rend im po ssible d ’effectuer le travail de manière collaborative (partager des documents, regarder la vue globale du projet,...).

4.4 Stratégie de Marketing

Mission

Notre mission est de devenir un fournisseur de solutions de haute qualité pour la gestion de projet à toutes les entreprises de tailles grandes et moyennes du monde entier. Nos solutions auront des supports inégalables assurant une flexibilité qui permettra de répondre, voire franchir toutes les espérances les plus exigeantes des clients.

Objectifs de marketing

Devenir des experts: Cela veut dire être mentionnés dans les revues du marché, être connu et reconnu par les clients.

Avoir des clients de référence : D ’ici la fin de l’année, nous avons besoin d’avoir au moins 3 noms connus afin de pouvoir les citer comme clients.

Avoir des clients étrangers : non seulement en Europe, mais aussi en Asie ou aux Etats Unis. Nous ne pouvons pas accomplir notre mission tant que nous ne sommes pas encore vraiment multi-continental.

Objectifs financiers

Croissance des ventes de plus de 10% pour les trois premières années

Récupérer un capital et commencer à faire des bénéfices après 18 mois (cf.

chapitre 5) Marketing Mix

La section suivante met en évidence les points principaux du « marketing mix » pour entrer en concurrence efficacement.

19

Produit

Le produit est la composante « clé » de notre marketing mix. En effet, l’esp rit de notre stratégie de marketing est la réalisation de ventes grâce au bouche-à-oreille.

E vudem m ent no us savo ns qu’il est ind ispensable de co m prendre le pro cessus d e m arketing, m ais en réalité, no us no us co ncentrons p lutôt sur la vente d’u n p roduit parfait que sur le marketing. Notre produit lui-même devrait être la meilleure publicité pour nous.

Prix

Déterminer le p rix d ’u n lo g iciel d e g estio n d e p ro jet est relativem ent d ifficile, car il existe p lusieurs facteurs qu i affectent le prix d’u n tel produit. Nous allons baser le prix de notre produit sur celui des logiciels déjà présents sur le marché. Le marché des logiciels de gestion de projet existe depuis plus de 20 ans, et il a développé un système de prix solide. En comparant ces prix, nous pourrons choisir le prix le plus adéquat. N o us étudio ns égalem ent l’évo lutio n du m arché po ur anticiper les prix dans le futur.

Canal de distribution

Notre produit sera vendu via deux canaux de distribution principaux : Internet et téléphone.

Promotion

Composantes principales de la promotion:

Etre reconnu et cité comme des experts dans les revues de presses concernées, telles que la Project Magazine, Project Management Today...

Bouche-à-oreille : Cela revient à augmenter notre valeur en remplissant les promesses

Internet : N o u s d evo ns d o m in er l’Internet, être bien classés dans les moteurs de recherche. Une solution est de nous inscrire sur la page du Project Management Institute (http://www.pmi.org/info/AP_Advertising.asp). Avec plus de 150 000 m em bres et de m illio ns d ’internautes, il n’y a pro bablem ent nulle part qui soit meilleur pour nous faire connaître au monde de la gestion de projet.

20

CHAPITRE 4 | Analyse fonctionnelle

Chapitre 5

Analyse des risques et des coûts

5.1 Analyse des risques

Objectif

L e principal o bjectif de l’analyse des risques est de défin ir la prio rité des pro blèm es dans le déroulement du projet. De cette façon, nous pouvons déterminer les problèmes qui m éritent que l’o n co nsacre des resso urces à leur atténuatio n .

Méthode

Un moyen pour mesurer la criticité d'un événement est d'effectuer le calcul suivant :

Criticité C = G x F x D

Critère

Valeurs de G Gravité

1 Défaillance négligeable ne provoquant aucune dégradation notable 2 Défaillance mineure ne provoquant qu’une conséquence faible 3 Défaillance moyenne nécessitant une correction

4 Défaillance critique nécessitant une grande intervention 5 Défaillance catastrophique

Valeurs de F F réq u en ce d ’ap p aritio n 1 Défaillance très rare

2 Défaillance peu probable 3 Défaillance occasionnelle 4 Défaillance fort probable 5 Défaillance certaine

Valeurs de D Détectabilité

1 S igne avant coureur de la défaillance que l’opérateur pourra éviter par une action préventive ou alerte autom atique d’incident

2 Aucun signe avant coureur de la défaillance mais on peut la constater facilem ent après qu’elle se soit produite

3 Aucun signe avant coureur de la défaillance et risque qu’elle ne soit pas perçue par l’opérateur après qu’elle se soit produite

4 Il n’existe aucun signe avant coureur de la défaillance et il est difficile de la percevoir m êm e si elle s’est produite

Evaluation de risque : 1-18 : risque faible

19-35 : risque remarquable

36 : risque à éviter à tout prix

21

N° Risque Effet Cause F D G C

Organisationnel

1

Répartition inappropriée des ressources (temps, budget, personnel...)

Plan prévu non respecté

M anque d’expérience,

méconnaissance des compétences de chaque membre.

Ex : faire des choses peu importantes de manière trop sophistiquée par les membres trop motivés

2 3 4 24

2

Tâches mal définies, Mauvaise répartition des tâches

Tâches non uniformes, Tâches surchargées, superposées, insuffisantes.

Tâches inappropriées pour certains membres

Manque de connaissances approfondies concernant le projet et la dépendance entre différentes tâches

2 3 4 24

3

Critères d'évaluation insuffisants

Estimation inexacte de la qualité

M anque d’expérience ou

d’exigence de la part de celui qui détermine les critères

3 3 2 18

4

Manque de contrôle d'avancement / de qualité

Mauvaise qualité Retard,

 Travail à refaire

Chef de projet trop confiant en ses membres ou trop laxiste

Mauvaise communication au sein du groupe

2 2 3 12

5

Produit réalisé non conforme au cahier ANVAR

Produit déformé par rapport à ce que l’on voulait

Pas de modèle – standard de communication

Cahier pas clair

1 1 5 5 Technique

6

Difficulté ou impossibilité d’assembler les parties de chaque membre

Pertes de temps à refaire des parties

Relations lâches entre les différentes parties

Bugs potentiels

3 2 5 30

7

Apparition de bugs après vente

Clients non satisfaits Perte de prestige, de temps, de travail

Tests insuffisants 3 3 3 27

8

Compatibilité entre les différents logiciels, services utilisés

Impossible de

réassembler ces parties

Utilisation de trop de logiciels, services sans les comprendre de façon approfondie

1 2 4 8

9 D ifficulté d’évolution du produit

Chute des ventes avant

d’avoir d es bénéfices Produit obsolète 2 3 1 6 10

Panne de matériel (server, ordinateur, disque dur...)

Perte de l’inform ation Mauvaise conservation et utilisation ex : Il fait trop chaud

Serveur de mauvaise qualité

1 2 2 4 Stratégie de marketing

11

Mauvaise

communication avec les clients:

Marketing

Service après-vente

Produit pas attractif à sa sortie

Clients non satisfaits quand ils rencontrent un problème

Mauvaise stratégie de marketing 2 4 4 32

12

Cible du marché mal définie

Produit ne répondant pas au besoin des clients ciblés

Mauvaise compréhension des besoins des clients

Trop de perfectionnisme

2 4 4 32

13

Prix inapproprié Prix trop élevé : produit difficile à vendre Prix trop bas : perte de profits

Sur, sous-estimation du produit 3 3 2 18

14 Budget prévu insuffisant Négociation avec le sponsor

Temps de réalisation prolongé, nécessite plus de ressources

1 2 1 2

22

CHAPITRE 4 | Analyse fonctionnelle

N° Risque Effet Cause F D G C

Humain 15

Manque de compétence de certains membres

Mauvaise qualité du travail

Délais non respectés

Causes objectives 2 2 4 16

16 Mauvaise relation entre les membres de l'équipe

Mauvaise ambiance =>

difficulté à travailler

Les m em bres entrent dans l’équipe à contrecoeur, membres irritables

2 2 4 16

17

Manque de motivation de quelques membres

Mauvaise qualité du travail

Délais non respectés

Travail inintéressant Tâche fastidieuse Peu de bénéfice / salaire Les membres ont du travail personnel

Le chef ne sait pas motiver les membres

1 3 5 15

18

Manque de charisme du chef de projet

Membres non motivés Chef pas écouté ni respecté

Choix spontané au début du projet 2 2 3 12

19

Longue absence imprévue des membres d'équipe

Refaire la répartition des charges

Manque de personnel

Maladie, accident, déménagement 1 2 3 6

Externe

20 Design pas apprécié par les clients

Mauvaise impression chez les clients

Manque de soins vis-à-vis de cet aspect

2 4 2 16 21 Apparition d'un nouveau

logiciel concurrent

Perte de parts du marché

Causes subjectives 2 3 2 12

22

Problèmes juridiques Risque de retardement du lancement du produit à cause de poursuites Risque de payer la licence ou de retirer des produits vendus

Une partie du projet ressemble à un produit existant

1 2 5 10

23

Société qui finance arrête le contrat

Travail interrompu Nécessité de trouver un autre sponsor

Le travail évolue lentement, trop de risques exposés

1 2 1 2 Divers

24

Qualité insuffisante des documents d’aide

Découragement des clients à utiliser le produit à sa pleine puissance

Mauvaise évaluation du besoin et de la compétence des clients Utilisation de structures, de vocabulaires incompréhensibles

3 4 3 36

25

Perte de dossier / secret révélé aux entreprises concurrents

Nécessité de refaire le dossier => perte de temps, démotivation de l’équipe

Les concurrents peuvent imiter et développer nos points forts, exploiter nos points faibles

Imprudence, trahison 1 3 4 12

23

Risques à éviter à tout prix

SP : Solution préventive SC : Solution curative

Qualité insuffisante des d ocu m en ts d ’aid e : 36

SP : Utiliser souvent des images, des graphes, des screenshots pour mieux illustrer.

Essayer de nous mettre à la place des clients pour voir si le document est assez bien réd igé (un m em bre lit la do cu m entatio n de l’autre)

SC : Ecouter les retours des clients pour améliorer Cible du marché est mal définie : 32

SP : Etudier le marché.(des sondages envoyés aux entreprises de toutes tailles, aux différentes organisatio ns et au x in d iv id u s p o u r co m p rend re leu rs beso in s, d ’o ù no u s pourrons choisir la segmentation du marché la plus appropriée)

SC : Redéfinir la segmentation du marché ciblée et créer une nouvelle version dédiée à cette cible (ce qui ne doit pas être très d ifficile d û à l’asp ect m o d u laire d e no tre produit)

Mauvaise communication avec les clients: Marketing, service après-vente : 32 SP : Consulter des renseignements des experts de marketings, fournir plusieurs moyens de communication aux clients, écouter souvent les feedbacks

SC : Lancer une nouvelle campagne de marketing

Impossible ou très difficile de rassembler des parties de chaque membre : 30 SP : Utiliser des diagrammes UML pour concevoir la totalité du projet avant de commencer. Créer les « ... » de chaque partie et essayer de les rassembler avant d’aller p lus lo in en détail.

SC : Rassembler p etit à p etit les p arties p o u r lo caliser l’erreu r et vérifier le d iag ram m e de UML concernant

Risques remarquables

Apparition des bugs après vente : 27

SP : Réaliser soigneusement un ensemble de tests avant le rendu du produit, permuter des rôles pour que les tests soient plus objectifs

SC : Service après-vente, maintenance continuelle Répartition des ressources : 24

SP : Créer un précis diagramme de Gantt (les tâches sont encore détaillées en sous- tâches), toujours prévoir un marge pour le temps et le budget

SC : S u rveiller rég u lièrem ent l’état d es resso u rces p o u r d étecter p lu s rap id em ent les excès ou défauts de ressources,

Les tâches ne sont pas bien définies, mauvaise répartition des tâches : 24

SP: Diviser les tâches en plusieurs sous-tâches précises pour éviter la redondance et éviter que les tâches soient trop disproportionnées. Faire un bilan de compétences et préférences afin de répartir les tâches entre les membres

S C : C o ntrô le d ’avancem ent de chaque tâche po ur lo caliser la tâche m al défin ie Critères d'évaluation insuffisants : 18

SP : Faire un brainstorming pour collecter le plus de critères possibles.

Prix inapproprié : 18

SP : Etudier bien le marché, comparer avec le prix des produits existant