Stage de fin d’études

Intégration d’un outil de gestion de projet en entreprise

Maître de stage : M. TABARY

Rapport

Aubry Simon

Roubaix, le 27 août 2011

RemerciementsJe tiens tout d’abord à remercier Marc Tabary, qui m’a permis d’effectuer ce

stage au sein de son entreprise Salto Consulting.

Je remercie également les personnes avec lesquelles j’ai passé ces 6 mois, EtienneLoiez, Nicolas Mervaillie, Quentin Vandekerchove, Maxime Decronambourg, NicolasLedieu, Céline Malaquin, Yann Picout ainsi que les salariés d’Ubik Ingénierie.

Pour mon intégration chez Promod, je remercie Laurent Thouilliez, David Terni-sien, Johan Lhopital, Emmanuel Bernard, Manuel Robert, Audrey Cordionnie ainsique l’ensemble de mes nouveaux collègues du bureau d’étude de Promod.

Merci à l’ensemble de ces personnes qui, au fil du stage, m’ont permis de décou-vrir des notions essentielles au comportement d’un ingénieur telles que la prise deresponsabilités et la gestion de projet. Merci aussi pour leur accueil et leur gentillesse.

2

RésuméLe stage se déroule en deux parties, la première au sein de SALTO Consulting,

la seconde, chez Promod, un client de Salto. Le fil conducteur du stage est alors lacomparaison des outils de gestions de projet utilisés dans une entreprise de petitedimension face à une multinationale comme Promod.

La deuxième partie chez Promod est conséquente à une opportunité qu’il m’aété offerte de continuer ma formation dans leur bureau d’étude.

SALTO Consulting souhaite intégrer et déployer au sein de son entreprise unoutil Open Source (PROJECTOR’RIA utilisant les technologie PHP MySql Javas-cript) de :

– Planification de projet ;– Gestion de projet ;– Saisie des temps de travail ;– Gestion des incidents ;– . . .

Le stage se décompose en 4 phases :

CONCEPTION : Sur la base d’un cahier des charges et d’une application EX-CEL existante, il s’agit d’en faire l’analyse et de concevoir les extensions nécessairesdu modèle objet (Classes - Attributs - Opérations), les APIs et les IHMs.

Les compléments fonctionnels manquants concernent principalement :

les aspects financiers :– Type de services (Formations - Prestations régies - Forfaits - Distribution deproduits - etc.) ;

– Prix de vente des services ;– Prix d’achat de prestations externes ;– Coût des ressources internes ;– Production des intervenants ;– Contrat - Echéancier - Facturation - etc.

Durant cette phase de conception, une attention toute particulière est donné àla réalisation des compléments comme des modules ou Add In à l’outil Open Sourceexistant. En effet, la version actuelle du projet est déjà mise oeuvre au sein de l’en-treprise. L’ajout des nouvelles fonctionnalités doit se faire en toute transparence.

REALISATION : Il s’agit dans cette phase de réaliser les composants, les IHMSet les APIs conçus dans la phase de conception et d’en faire le recettage interne.

3

VALIDATION : Une fois les réalisations terminées (on peut envisager une inté-gration par lots),elles seront déployées sur une version Beta.

Les recetteurs sont les collaborateurs de l’entreprise (partie intégration Bug Tra-cking JIRA) et le responsable du centre de service (partie financière). Ils utiliserontl’outil de Bug Tracking JIRA de l’entreprise pour décrire les anomalies rencontréeset leur niveau de gravité.

Il est alors demandé au stagiaire de se positionner sur des releases de correctionet un calendrier de mise à disposition.

DEPLOIEMENT : Une fois la recette terminée, la nouvelle version du projet estdéployée dans l’entreprise (outil de production) mais également mise à dispositionen Open Source. Cette mise à disposition est complétée par la documentation deconception et la description des tests et résultats effectués lors de la phase de déve-loppement. Charge alors au créateur du projet de mettre à disposition les travauxpubliés à la communauté.

DEPLACEMENT CHEZ UN CLIENT : Dans le cadre d’une opportunité definir ma formation chez un client de Salto Consulting, la dernière partie du stage estconsacrée, en parallèle à une intégration dans leur infrastructure, à l’étude de leursystème de gestion de projet.

4

Table des matières

1 Introduction 8

2 Contexte 92.1 Présentation de l’entreprise : Salto Consulting . . . . . . . . . . . . . 9

2.1.1 Présentation institutionnelle . . . . . . . . . . . . . . . . . . . 92.1.2 Historique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.1.3 Les clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.1.4 Les orientations stratégiques . . . . . . . . . . . . . . . . . . . 12

2.2 Présentation du client : Promod . . . . . . . . . . . . . . . . . . . . . 122.2.1 Présentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.2.2 Promod aujourd’hui . . . . . . . . . . . . . . . . . . . . . . . 132.2.3 Le service informatique de Promod . . . . . . . . . . . . . . . 13

3 Etat de l’art 143.1 Les logiciels libre : le choix de Salto Consulting . . . . . . . . . . . . 15

3.1.1 Aperçu des différentes possibilités sur le marché . . . . . . . . 153.1.2 Pourquoi Project’Or RIA ? . . . . . . . . . . . . . . . . . . . . 16

3.2 Les logiciels propriétaires : le choix de Promod . . . . . . . . . . . . . 173.2.1 Aperçu des différentes possibilités sur le marché . . . . . . . . 173.2.2 Pourquoi Sharepoint ? . . . . . . . . . . . . . . . . . . . . . . 18

4 Project’Or RIA 194.1 Présentation de l’existant dans Project’Or RIA . . . . . . . . . . . . . 19

4.1.1 Les projets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194.1.2 Les utilisateurs . . . . . . . . . . . . . . . . . . . . . . . . . . 214.1.3 Les jalons et les tickets . . . . . . . . . . . . . . . . . . . . . . 214.1.4 La gestion des actions en projet . . . . . . . . . . . . . . . . . 214.1.5 Résumé schématique de l’application centré sur le projet . . . 224.1.6 Gestion des coûts . . . . . . . . . . . . . . . . . . . . . . . . . 22

4.2 Présentation de MVC . . . . . . . . . . . . . . . . . . . . . . . . . . . 234.2.1 Utilisation de MVC dans Project’Or RIA . . . . . . . . . . . . 234.2.2 Principes d’implémentation . . . . . . . . . . . . . . . . . . . 26

5

5 Les nouvelles fonctionnalités 275.1 Projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

5.1.1 Explication du problème . . . . . . . . . . . . . . . . . . . . . 285.1.2 Principe d’implémentation pour la typologie . . . . . . . . . . 295.1.3 Principe d’implémentation du prix de vente . . . . . . . . . . 29

5.2 Sous-traitance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315.3 Commissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315.4 Abaque . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315.5 Facturation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

5.5.1 Echéancier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335.5.2 Facture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

5.6 Les problèmes rencontrés . . . . . . . . . . . . . . . . . . . . . . . . . 37

6 Conclusion 38

6

Table des figures

4.1 Ecran de création/modification/suppresion des projets . . . . . . . . 204.2 Schéma du principe de fonctionnement pour la dimension humaine . . 224.3 Schéma du principe de fonctionnement pour le calcul du coût . . . . . 234.4 Modèle MVC global . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254.5 Diagramme de séquence d’un MVC simple . . . . . . . . . . . . . . . 25

5.1 Schématisation du concept souhaité . . . . . . . . . . . . . . . . . . . 285.2 Ecran de renseignement du prix d’un type d’activité pour un projet . 305.3 Ecran d’échéancier . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345.4 Ecran de facturation . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

7

Chapitre 1

Introduction

Les outils de gestion de projet informatisés sont actuellement incourtounablespour le bon déroulement d’un projet. Il en existe une multitulde répondant à desbesoins précis mais gardant pour la plupart une ligne directrice commune et uneaccroche centrale : le projet.

Salto Conculting a fait le choix d’une solution libre Open Source nommée Pro-ject’Or RIA. Ce logiciel est dit ALM, c’est à dire : Application Lifecycle Manage-ment. Il permet à Salto Consulting de connaitre en temps réel l’avancée de l’ensemblede ses projets.

Actuellement, Project’Or RIA ne possède qu’une dimension budgetaire très limi-tée. L’objectif principal est donc de créer des fonctionnalités supplémentaires à l’ap-plication. Il faut qu’à terme, celle-ci soit capable de gérer la facturation des projets.Pour Salto Consulting, ce projet est conidéré comme interne, il permet d’améliorerun outil afin qu’il soit au mieux adapté au besoins de l’entreprise.

Comme précisé précédemment, la seconde partie du stage s’effectue au sein dePromod, un client de Salto Consulting. Pendant cette période, l’objectif est de m’in-tégrer à leur bureau d’études pour qu’à la fin du stage je puisse continuer une missionchez eux. En parallèle, l’étude de leur système de gestion de projet sera faite, per-mettant ainsi la comparaison entre les besoins en matière de gestion de projet pourdeux entreprises de dimensions différentes.

8

Chapitre 2

Contexte

2.1 Présentation de l’entreprise : Salto Consul-ting

2.1.1 Présentation institutionnelleSALTO Consulting a été créée en février 2002 par 3 cadres originaires d’une

SSII régionale. L’idée originale de création de SALTO Consulting était fondée sur leconstat qu’il existe très peu d’offres de service régionales entre les grands cabinets deconseil institutionnel (dont le rôle est de donner les grandes orientations stratégiquesd’évolution des systèmes d’information des entreprises) et les SSII (dont la missionconsiste à développer et à maintenir les applications informatiques par rapport à cesorientations techniques).

Leur rôle est d’assurer l’interface entre ces 2 types d’acteurs et consiste à :– Étudier et concevoir les architectures logicielles ;– Mettre en place la méthodologie ;– Mettre en place la nouvelle organisation, pour que les nouvelles applicationspuissent être développées dans ces technologies.

Le savoir-faire de SALTO Consulting s’articule essentiellement autour des ar-chitectures N-Tiers et des technologies J2EE. Implantée au coeur de la MétropoleLilloise, à Roubaix, une ville au riche passé industriel, SALTO Consulting a unrayonnement régional. L’entreprise est alors reconnue comme interlocuteur privilé-gié des entreprises Nordistes tels que 3 Suisses, Décathlon et Cofidis.

2.1.2 Historique2002 - Naissance de l’entreprise : En 2002, Marc Tabary crée et présideSALTO Consulting à Roubaix (59). Son concept est totalement nouveau : Créer uneactivité intermédiaire & spécialisée entre les grands cabinets de conseil et les SSII.En février 2002, SALTO Consulting développe son propre Framework J2EE SALTO

9

v 0.5 (outil de génération de la couche de persistance).

2003 - Productions et Accords : SALTO Consulting développe la version 1.5de son Framework SALTO (mise en oeuvre d’un modèle MVC référence du marché,STRUTS, en remplacement de l’existant) et met en oeuvre un environnement in-dustrialisé des développements basés sur des souches « Open Source »& des Add OnSALTO.

Des accords sont conclus avec trois grands groupes Nordistes : Camaïeu (plate-forme d’industrialisation J2EE issue de la version 1.5 du Framework SALTO) , Dé-cathlon (console Batch Java d’industrialisation des développements Batch en Java)et 3 Suisses (projet de mise en place d’une plate-forme d’ndustrialisation des déve-loppements J2EE grâce à l’aspect novateur de son Framework).

2005 - Une SSII très présente dans le Nord : SALTO Consulting organiseune présentation du prototype d’un outil de génération de code à partir de la modé-lisation UML. Cette présentation est importante car elle reflète l’intérêt importantque portent les directions informatiques à ce type d’outil. Son objectif est d’accroîtreleur productivité. Tous les grands comptes régionaux (3 Suisses, Décathlon, Auchan,Cofidis, SeaFrance et d’autres) étaient présents.

En Juin, SALTO Consulting signe un partenariat avec Ubik-Ingenierie et dans lemême temps le Framework SALTO version 2.5 est retenu comme Framework d’in-dustrialisation des développements « IHM »chez Décathlon. La console Batch Javaest retenue par 3 Suisses.

2006 - 2007 Ouverture d’un grand compte à Paris SALTO Consulting signeun contrat cadre avec le Groupe Pierre & Vacances (leader européen du tourisme)notamment pour :

– Réaliser un outil de gestion des données techniques et commerciales non struc-turées ;

– Assister les équipes informatiques pour la mise en oeuvre d’une nouvelle versiond’un progiciel Tourisme ;

– Réaliser un logiciel « Front End Tourisme »destiné aux agents du Call Center.

2007 - 2008 SALTO devient : le partenaire d’un éditeur de progiciel pourl’élaboration de l’architecture logicielle SALTO Consulting passe un accord de par-tenariat avec ACCOVIA (éditeur de progiciel Tourisme Canadien) pour :

– Mettre en oeuvre un moteur de règle dans l’offre progicielle ;– Bâtir l’architecture logicielle (J2EE, Flex) de la nouvelle version du progicielTourisme ;

10

– Participer à la réalisation du module « Client »du progiciel.

2009 - SALTO devient « Centre de Service OfBiz » : En partenariat avecUbik Ingénierie & NEREIDE, SALTO Consulting constitue un centre de serviceautour du progiciel open source OfBiz de la fondation Apache.

Ce centre de service prend en charge pour le compte de Décathlon la réalisa-tion de leur système magasin pour leurs magasins « low cost »et pour leurs sitese-commerce Marque Passion (B’TWIN, QUECHUA, DOMYOS, . . .).

2009 - SALTO Consulting signe un accord de partenariat : avec unestart-up roubaisienne pour la réalisation d’un progiciel de eCRM (Ciblage Client,Elaboration de campagne marketing, Processus de suivi de la campagne) basé surles technologies OfBiz-Java-Flex.

2.1.3 Les clientsDepuis 2002, SALTO Consulting s’est vue confier des projets significatifs et stra-

tégiques, aussi variés que la réalisation d’un logiciel de gestion des données tech-niques et commerciales du Groupe Pierre & Vacances, le développement des sitesecommerce de 3 marques passions Décathlon.

Fort d’un indéniable savoir-faire et d’une dynamique régionale, SALTO Consul-ting a réussi à séduire des entreprises issues de secteurs différents tels que la dis-tribution (Décathlon, Auchan, Kiabi, Camaieu, etc.), la VAD (3Suisse), l’assuranceet établissement financier (La Mondiale, Cofidis), l’administration (CommunautéUrbaine de Lille, Voies navigables de France), l’industrie (Lyreco) et le tourisme(Groupe Pierre & Vacances, Accovia). Les concurrents de SALTO peuvent être ré-partis en 3 catégories :

– SSII Généralistes locales (Norsys, CYO, SYLIS, DPI, Proxiad) : elles se po-sitionnent au niveau des clients comme expertes. Cependant, leur stratégiereste de vendre de la prestation longue durée, principalement de concepteuret de développeur. De ce point de vue, SALTO Consulting se différencie auniveau de la nature des offres et du contenu : apport systématique d’outilsd’industrialisation ;

– SSII Nationales (Unilog, Sopra, Logica, IBM, Cap Gemini) : ce type de sociétéspossède en général des unités de « capitalisation »leur permettant de proposerdes offres équivalentes à celle de SALTO Consulting. Cependant, ces offres sontdes produits commerciaux permettant de vendre de la prestation d’intégration ;

– Sociétés de Conseil et expertise parisiennes (Valtech, Sysdeo, Improve) : Cesont véritablement les vrais concurrents de SALTO Consulting dans le do-maine. Cependant, leurs localisations parisiennes ne leur permettent pas de

11

connaître de façon récurrente et pertinente les véritables besoins des clients(dimensionnement, conduite du changement, spécificités techniques etc.).

2.1.4 Les orientations stratégiquesGrâce à son expérience terrain et sa connaissance du marché, SALTO Consulting

a pu identifier des manques et s’est donc lancé dans :

– L’intégration industrialisée de moteur de règles (ILOG, DROOLS) notammentpour gérer la politique tarifaire, l’assemblage dynamique dŠoffre, la distribu-tion de stock en fonction de segment client. Cette intégration est actuellementmise en oeuvre pour la création de l’ERP Tourisme ;

– L’intégration, à travers un centre de service, d’un progiciel Open Source OfBizdans un contexte d’offre e-commerce ;

– La réalisation d’un Front Office de prise de réservation en « Call-Center »surles technologies Java & Adobe Flex ;

– La réalisation d’un progiciel de e-CRM sur les technologies Java-OfBiz-Flex.

SALTO Consulting s’oriente vers une stratégie des nouveaux marchés, les »ap-plications internet riches »(RIA) et la mobilité (applications iPhone, Androïd etc.)Les facteurs d’adoption des RIA pour les entreprises portent avant tout sur l’amé-lioration de leurs processus métiers d’une amélioration du contexte de l’informationet de l’utilisation de l’application La réduction des coûts apparaît comme le 5èmefacteur d’adoption, signe que les entreprises ont bien compris que l’enjeu porte surl’efficacité de leurs processus plutôt que sur la réduction de leurs coûts. Les RIAsont en quelques sortes moteur de la croissance de l’entreprise. La crise va précipiterl’adoption de nouvelles technologies, en particulier les RIA, car elles permettent dese différencier et de mieux se préparer à la reprise de la croissance.

Les années précédentes ont vu l’apparition de smart phones offrant les mêmesservices qu’un ordinateur de bureau classique (Internet, lecture de médias, jeux).Ces technologies étant relativement jeunes, il est intéressant de les étudier dans lesmoindres détails afin d’évaluer toutes les possibilités qu’elles offrent en terme deservice (« B to B », « B to C »ou encore « B to B to C »).

2.2 Présentation du client : Promod

2.2.1 PrésentationCréée en 1975, Promod est une société familiale française spécialisée uniquement

dans la création et la vente de prêt-à-porter et accessoires féminins.

PROMOD propose une mode facile à porter, facile à acheter, un juste équilibreentre les qualités recherchées par les femmes et des prix qui leur permettent toutes

12

les libertés. Les collections Promod sont conçues par un bureau de style intégré àPROMOD.

Les collections PROMOD sont distribuées uniquement dans le réseau de maga-sins PROMOD et sur le site www.promod.fr.

Elles se renouvellent très fréquemment : PROMOD implante ainsi plus de centproduits nouveaux tous les quinze jours. PROMOD s’appuie sur un système d’in-formation très performant qui lui permet d’analyser ses ventes chaque jour magasinpar magasin et de coller au plus près aux attentes des clientes.

2.2.2 Promod aujourd’huiPROMOD s’est implantée hors de France à partir du début des années 90. Elle

dispose aujourd’hui de 757 magasins dans 44 pays. Elle réalise plus de 50% deson chiffre d’affaires hors de France et séduit chaque année près de dix millions declientes.

PROMOD regroupe 3 000 collaborateurs, dont plus de 90% sont des femmes.

2.2.3 Le service informatique de PromodLe service informatique compte dans ses rangs pas moins de 80 personnes. Une

première moitié, le service exploitation, s’occupera plutôt de la production et de lahotline magasin tandis que l’autre, le service études et organisation, a pour missionde développer les applications nécessaires à PROMOD.

PROMOD développe les applications liées à con cIJur de métier : celles utiliséesdans sa chaîne de magasins, celles concernant la logistique, son propre site Internetet enfin toutes les applications de sa centrale d’achat. C’est un groupe d’une dizainede personnes qui développe ses dernières, le service Etudes du domaine Achat. Il éga-lement pour mission d’aider tous les utilisateurs et répondre à toutes leurs questions.

Ce qui caractérise PROMOD, ce sont les valeurs qu’elle prône. PROMOD veutmettre en avant créativité et esprit dŠinitiative, professionnalisme, simplicité dansla façon d’être, enthousiasme, esprit d’équipe, respect d’autrui.

13

Chapitre 3

Etat de l’art

Les solutions libres de gestion de projet gagnent petit à petit en maturité, sou-tenues par le dynamisme des communautés de développeurs. Certaines intègrentmême des modules collaboratifs poussés. Nous allons faire un tour d’horizon desprincipales applications.

A l’instar des solutions du marché, les outils de gestion de projet Open Sourceont pour objectif d’assurer le suivi des projets et des principales échéances planifiéeset/ou réelles, les jalons. Elles permettent également d’apporter une vue synthétiquedes ressources humaines impliquées (équipes, sponsors...), et d’assurer également unsuivi des temps par tâches et par activités lié aux différents projets en cours.

Bien que souvent moins riches en fonctionnalités que les solutions propriétairesdu marché (Artemis, Microsoft, Planisware, Planview...), les solutions Open Sourcepeuvent notamment compter sur les communautés de développeurs pour mettre àdisposition des librairies de programmation spécifiques afin de faciliter leur intégra-tion avec d’autres briques du système d’information (gestion de la relation client,marketing...).

Les critères de choix :– Méthodes de planification ;– Fonctionnalités de travail collaboratif ;– Mod Web et systèmes d’exploitation supportés.

Il existe principalement trois méthodes de représentation des plannings que lessolutions de gestion de projet Open Source peuvent être en mesure de générer.Le diagramme de Gantt permet de situer dans le temps et de corréler les phasesd’activités, de ressources avec les tâches préalablement définies. La méthode PERT(Program Evaluation Research Task) consiste de son côté à déterminer un tempsoptimal de réalisation et de déroulement d’un projet. Enfin, le réseau des antécé-dents permet une visualisation des dépendances et de mesurer efficacement les écartset/ou recouvrements en termes de délais.

14

Certaines solutions se démarqueront par rapport à d’autres en intégrant native-ment des modules de gestion et de publication de contenu, un outil de forum, ainsiqu’une procédure automatique de notification par mail. Si les fonctionnalités col-laboratives apportées par les solutions concourent à optimiser la gestion de projet,toutes sont loin de les présenter par défaut (sinon sous forme additionnelle).

Le troisième critère de choix retenu est celui relatif à la diversité des modes dedisponibilité et d’accès des solutions de gestion de projet Open Source. Ainsi, uneapplication disponible en mode Web permet une grande interopérabilité avec des sys-tèmes fonctionnant sous des environnements d’exploitation hétérogènes. Cela étant,l’installation sur le poste client effectuant la requête Web de la machine virtuelleJAVA (JVM) sera nécessaire dans bien des cas.

3.1 Les logiciels libre : le choix de Salto Consul-ting

3.1.1 Aperçu des différentes possibilités sur le marchéGantt Project : est une solution de gestion de projets très prometteuse. Dé-veloppé en Java (donc multiplateformes), riche d’une très large communauté, celogiciel offre les fonctionnalités de base requises pour la gestion de projets. Il s’agitd’une solution idéale pour la gestion de projets de petites et moyennes entreprises(PME). Conçu avec une interface très simple et intuitive, il permet à un utilisateurpeu expérimenté dans la gestion de projets d’apprendre rapidement l’outil et sesfonctionnalités. Particularité de Gantt Project, celui-ci propose l’import des fichiersMS Project et l’export au format XML.

Open Workbench : est une solution de gestion de projets visant directement àconcurrencer Microsoft Project. Développé en C++ (Windows), il s’agit de la solu-tion la plus solide et la plus complète en termes de fonctionnalités et de rapports.Open Workbench peut également être utilisé dans un mode entièrement intégrée àClarity. Ce dernier offre des fonctions dépassant largement celles de gestion de pro-jets autonomes et propose des solutions de gestion d’équipe, de partenariat, d’or-ganisation ou d’entreprise. Ce système complet de gestion de projets s’intègre avecOpen Workbench pour fournir un dépôt central d’information pour les projets, pro-grammes, coûts et ressources.

Taskjuggler Pour les gestionnaires de gros projets utilisant un poste client de typeUnix, Taskjuggler se révèle être la solution idéale. Après une certaine phase d’adap-tation qui est nécessaire pour la prise en main du logiciel (et du langage associé), iloffre de très bonnes performances en terme de fonctionnalités et de rapports. Il nepermet toutefois pas actuellement l’importation de fichiers MS Project. Ce logiciel

15

depuis longtemps soutenu par Suse l’est maintenant par Novell.

On peut alors établir un tableau comparatif des différentes solutions :

Solution Gantt, PERT et réseaux d’antécédents Fonctionnalités collaborativesdotProject Diagramme de Gantt Calendrier partagé et Forum

Gantt Project Diagramme de Gantt et PERT Alertes mailGnome Planner Diagramme de Gantt -Open Workbench Tout Calendrier partagé

phpCollab - Calendrier, forum, documentairePopsiplan Diagramme de Gantt -TaskJuggler Diagramme de Gantt et PERT -

Solution Mode Web et compatibilité des OSdotProject Mode Web, Windows (NT, 2000 et XP), Linux et Unix

Gantt Project Mode Web, Windows, Mac OS X, Linux et UnixGnome Planner Linux et UnixOpen Workbench Mode Web et Windows (95, 98, NT, 2000 et XP)

phpColla b Mode Web, Linux et UnixPopsiplan Mode Web, Linux et UnixTaskJuggler Linux et Unix

3.1.2 Pourquoi Project’Or RIA ?Salto Consulting était à la recherche d’un logiciel gratuit possédant de nom-

breuses possibilités d’évolution.

Par rapport à ses concurrents présentés précédemment, Project’Or RIA permetde gérer l’ensemble de ses projets, de ses clients ainsi que de ses ressources. De plus,celui-ci inclut un générateur de diagramme de Gantt créé en temps réel par rapportà l’avancement des différents projets. L’un des avantages notables de ce logiciel estsa compatibilité avec les différents OS et son accessibilité. En effet, étant une ap-plication Web, elle est accessible à toute personne possèdant une connexion internet.

Autres facteurs importants ayant mené au choix de Project’Or RIA, c’est unlogiciel jeune, environ un an, libre, et possèdant des contributeurs actifs. Après denombreux échanges de mails avec ceux-ci, et à la vue de nombreuses mises à jour,on peut affirmer que le logiciel évolue rapidement.

Enfin, sa simplicité d’implémentation en fait un logiciel personnalisable à souhait.

16

3.2 Les logiciels propriétaires : le choix de Pro-mod

3.2.1 Aperçu des différentes possibilités sur le marchéPolarion ALM est un outil Open Source payant, pour une équipe de 10 personnessur un an, il faut compter un investissement d’environ 14 000 Ă.En tant qu’outil ALM, il couvre par définition l’ensemble du cycle de vie du projetsoit l’ensemble des besoins cités plus haut. Le côté « tout en un »est séduisant, li-mitant ainsi les coûts de mise en oeuvre et de maintenance. Programmé en J2EE,il peut être personnalisé par un bon développeur au besoin. Il repose essentielle-ment sur le gestionnaire de version SVN aussi bien pour le code source que pour lesexigences. Polarion propose même un accompagnement CMMI sous forme d’indica-teurs.

Polarion semble être le seul outil ALM Open Source du marché.

ScrumWorks : est une solution agile. L’agilité apporte une bonne contributionà l’outillage. L’un des atouts majeurs des outils agiles du marché consiste en un ac-compagnement méthodologique. Car chacun sait qu’un outil ne suffit pas à garantirla réussite d’un projet. L’autre avantage que peut présenter le choix d’un outil Agileet la légèreté native (simple et intuitif) de ce dernier, le but étant de se rapporcherau plus des valeurs Agile comme « Personnes et interaction plutôt que processus etoutils ». Danube propose deux versions de ScrumWorks, une version limitée appeléeBasic et une version complète payante appelée Pro. Pour la version payante pourune équipe de 10 personnes sur un an, il faut compter 2 050 Ă. ScrumWorks necouvre cependant pas les besoins suivants : organisation et déroulement des plansde test, suivi des anomalies, wiki (centralisation des informations du projet).

Rally : se présente sous forme de SAAS, autrement dit aucun coût d’infrastruc-ture n’est nécessaire puisque vous n’hébergez pas l’outil chez vous ou chez votreclient. Rally s’engage bien sûr à garantir performance et confidentialité. Si néces-saire, il peut cependant être vendu dans sa version d’installation sur site. En offreSAAS, il faut compter environ 2 500 Ă pour une équipe de 10 personnes pour unan. La licence se paye au mois, ce qui offre une grande souplesse en cas de turn overd’équipe. La couverture en terme de fonctionnalités est trés large et les possibilitésd’intégration avec d’autres outils sont relativement nombreuses (Gestionnaires deversion, de plan de test, outils d’intégration continue,...). Une version Communitygratuite mais limitée permet de se faire une bonne idée de l’outil. Un autre avantageavec Rally est l’accompagnement méthodologique Agile. Rally est particulièrementactif dans la communautés Agile : livres blancs, séminaires, articles, . . .

17

JIRA + GreenHopper : Une solution assez intéressante également consiste àassocier JIRA à son plugin GreenHopper (Plugin de gestion de projet Agile). Cettesolution est intéressante dans la mesure où - pour une entreprise - il n’y a pas delimite d’utilisateurs en terme de licence. Elle peut donc présenter un coût élevé àl’achat mais pour un nombre d’utilisateurs illimité ainsi qu’une utilisation illimitéedans le temps. Il faut compter environ 5 000 Ă. JIRA sait gérer plusieurs projets à lafois. Les tarifs descendent vite dans les versions plus limitées jusqu’à la gratuité pourles communautés Open Source en passant par la moitié prix pour les établissementsd’enseignement.

3.2.2 Pourquoi Sharepoint ?Le choix de Sharepoint s’incrit dans une politique d’utilisation d’outils Windows.

Ainsi, les ordinateurs de l’ensemble du personnel du siège disposent sous WindowsXP, la messagerie par défaut est Outlook, . . .

De plus, actuellement, d’autres logiciels sont utilisés au sein de Promod. On peutnoter l’utilisation de Mantis, un bug tracker, ainsi que d’un intranet possédant unWiki et une FAQ. Cette base préexistante nécessiterait de trop gros changements sielle devait être portée sur une autre application.

Le principal besoin du service informatique de Promod était un gestionnairede fichier permettant de gérer l’ensemble des cahiers des charges, des analyses dé-taillées, . . .des applications développées. De plus, un gestionnaire de projet simpleest nécessaire.

Tous ces points sont réunis dans Sharepoint. Comme son nom l’indique, cett ap-plication permet de gérer le partage de fichiers mais aussi la gestion simple de projet(possibilité de créer des taches et d’y affecter des utilisateurs). De plus son interfaceest personnalisable via un outil de gestion. Ayant nul besoin de plus, Sharepoint esten cours de déploiement au sein de Promod.

18

Chapitre 4

Project’Or RIA

4.1 Présentation de l’existant dans Project’Or RIACe paragraphe va permettre d’introduire l’utilisation de Project’Or RIA.

4.1.1 Les projetsLa première étape dans l’utilisation de Project’Or RIA est de comprendre l’arti-

culation du logiciel autour des projets. En effet, le fonctionnement de l’applicationest centré sur la notion de projet, et il est bien sûr possible de gérer autant de projetsque nécessaire via cette application. Tout d’abord, définissons le terme projet : c’estun engagement irréversible qui vise à répondre à un besoin exprimé ou à résoudreune problématique explicitée et nécessitant le concours et l’intégration d’une grandediversité de contributions. Project’Or RIA tente de répondre à cette problématiqueen hiérarchisant l’organisation d’un projet.

La hiérarchie est la suivante : un projet peut être décomposé en sous projets,ces sous projets ont les mêmes propriétés qu’un projet. En dessous de la notion deprojet, il est possible de créer des activités, correspondant à des taches précises. Parexemple, chez Salto Consulting, ces activités sont utilisées la plupart du temps pourdécrire les phases du projet : conception, développement, . . .Il est possible, par ailleurs, d’appliquer une notion de temporalité à cette hiérarchie.Pour chaque activité ou projet, nous pouvons définir des éléments successeurs et/ouprédécesseurs. Ces éléments peuvent être soit des projet, des activités ou des jalon,nous reviendrons sur cette dernière notion un peu plus tard.

19

Pour illustrer la présentation, voici l’écran de création/modification/suppressionde projet :

Figure 4.1: Ecran de création/modification/suppresion des projets

20

4.1.2 Les utilisateursIl existe plusieurs status pour les utilisateurs de l’application :– administrateur– ressource– contactChaque rôle dispose de droits clairement définis et paramétrables dans l’appli-

cation.L’administrateur a pour seul objectif de paramétrer l’application : gérer les droits,

créer des utilisateurs, . . .Les contacts sont en général des personnes d’autres entre-prises nécessitant un accès à ce portail. L’utilité de cet accès est de manière généralede leur permettre de se rendre compte de l’avancement d’un projet, de laisser desmessage à l’équipe ou encore de créer des jalons.

Les ressources sont très certainement les utilisateurs les plus importants de l’ap-plication. En effet, parmi ces ressources il est possible de différencier les chefs deprojets, les experts, les prestataires, . . .Encore une fois, il est tout à fait possible deparamètrer des droits différents pour chaque rôle. Ainsi, les chefs de projets pour-ront créer des activités, affecter des ressources et organiser des réunions alors queles simples développeurs ne pourront que consulter ses activités et rendre comptede l’avancement de leurs travaux.

4.1.3 Les jalons et les ticketsPoint important de la gestion de projet dans Project’Or RIA, l’utilisation des

jalons et tickets. Ceux-ci peuvent avoir deux utilités principales. La première est detout simplement définir des check point dans la conduite du projet, en affectant àune date précise telle ou telle action. Ensuite, grâce au système d’élément prédéces-seurs et successeurs il est possible d’utiliser ces jalon comme élément déclancheurou final d’une activité ou d’un projet.

La deuxième principale utilité de ce système, est dans le cadre de l’utilisation deProject’Or RIA en tant que bug tracker. En effet, le système de ticket permet deréférencer bug, anomalie, ou encore amélioration à faire sur telle ou telle activité ouprojet, puis de l’affecter à une ressource en choisissant une priorité, une échance. Ilest aussi possible d’y joindre des documents.

4.1.4 La gestion des actions en projetProject’Or RIA dispose d’un gestionnaire d’actions. En d’autres termes, il est

possible de gérer les problèmes, les risques, les réunions, les décisions, les questionsvia l’application. Ainsi, nous pouvons planifier une réunion en lui joignant des ques-tions et des décisions, mais aussi gérer les problèmes en lui joignant des risques etdes actions.

21

Ce module permet alors de gérer n’importe quelle situation rencontrée lors de lagestion d’un projet.

4.1.5 Résumé schématique de l’application centré sur le pro-jet

En résumé, voici un schéma permettant une vue globale du fonctionnement deProject’Or RIA.

Figure 4.2: Schéma du principe de fonctionnement pour la dimension humaine

4.1.6 Gestion des coûtsL’actuelle version de Project’Or RIA permet un calcul du coût d’un projet. Celui-

ci est basé sur différents facteurs. Pour expliciter la méthode de calcul, nous allonssimplement dérouler la vie d’un projet dans le logiciel.

Après la création d’un projet et de ses activités, il faut affecter des ressources.Pour cela, il suffit de selectionner un utilisateur avec son rôle correspondant et soncoût à la journée. Puis, pendant le déroulement du projet, chaque ressource du projet

22

va pouvoir renseigner la quantité de travail (en jour) qu’il fait. Ainsi,il est possiblede générer un diagramme de Gantt mise à jour en temps réel par rapport à l’avan-cement global.

Une fois le projet fini, la simple addition de nombre de jours passés sur le projetmultiplié par le coût permettra d’obtenir le coût global du projet.

Voici une autre façon d’illustrer les choses :

Figure 4.3: Schéma du principe de fonctionnement pour le calcul du coût

4.2 Présentation de MVCL’implémentation de Project’Or RIA se base sur une modèlisation MVC (Model-

View-Controller). Sauf exception l’éloignant de ce modèle, l’application utilise unearchitecture qui cherche à séparer nettement les couches de présentations.

4.2.1 Utilisation de MVC dans Project’Or RIALe but de MVC est de séparer les couches d’une application (en 3 couches dis-

tinctes, au minimum, et le plus souvent). On peut distinguer :

23

– Le modèle qui encapsule la logique métier et la manipulation des sources dedonnées ;

– La vue : présente les données au client demandeur (un utilisateur humain ouun autre programme) ;

– Le contrôleur : tout le reste, c’est lui qui analyse les requêtes du client, accèdeaux données, formate le tout et l’envoie à la partie vue qui va présenter l’en-semble.

Pour détailler un peu la méthode, la vue d’abord, c’est un « TemplateView ».On utilise PHP lui-même pour écrire nos variables dans du HTML. Le « Transform-View »peut aussi être utilisé en transformant les données renvoyées par les modèles.Dans notre situation une présentation JSON des données est faite, cela facilite leurstraitements par le client Javascript et Ajax. Il est très important de noter que la vuene fait que présenter des données et à aucun moment elle ne connaît leur provenance.C’est le modèle qui va fournir toutes les méthodes nécessaires à la récupération, et lecontrôleur qui se chargera de cette récupération et de sa transformation éventuelleafin de coller à la vue.

Du côté du modèle, il est très important que celui-ci ne connaisse ni les contrô-leurs, ni les vues. Les liens vont des contrôleurs vers le modèle, de temps en temps,des vues vers le modèle, mais jamais en sens inverse.

Le modèle étant totalement indépendant du reste, il pourra faire l’objet d’uneréflexion et d’un développement à part. Il pourra de même être utilisé par d’autrescomposants, tels que des webservices ou d’autres applications locales.

Les données manipulées par le modèle doivent persister entre toutes les requêtesHTTP, ainsi un support de stockage devra être utilisé. Dans notre cas, la source dedonnées est une base de données relationnelle (MySQL) et le mapping objet rela-tionnel (ORM) est utilisé.

Il est possible que la vue accède au modèle. C’est un choix architectural qui de-vra être bien réfléchi, car il impose un plus fort couplage et un mélange des couches.On appelle cela l’approche « pull ». C’est souvent réservé aux opérations légères,comme par exemple afficher une liste de catégories d’éléments quelconques ; et auxopérations de lecture uniquement.

L’approche inverse, appelée push, interdit à la vue d’accéder au modèle. En gé-néral, on utilise les 2 choix en même temps : une instruction de lecture simple (récu-pérer une liste) sera demandée directement par la vue, ou un de ses sous-composants.

En revanche une opération de modification du modèle, sera demandée par uncontrôleur.

24

Figure 4.4: Modèle MVC global

Figure 4.5: Diagramme de séquence d’un MVC simple

Et on arrive enfin au contrôleur, car c’est lui le composant principal du modèleMVC. Il agit avec le modèle, la vue et d’autres contrôleurs tout à la fois. Quel qu’ilsoit, le contrôleur reçoit et analyse la requête du client, accède au modèle, et pré-

25

sente la vue. Il est en quelque sorte le point de rencontre des autres composants, ilpermet de coordonner les communications et les actions de chaque module.

4.2.2 Principes d’implémentationComme présenté précédemment, Project’Or RIA utilise la technologie MVC dans

son implémentation. Toutefois, il existe une entorse au principe de base. En effet, unlien entre la partie « View »et la partie « Model »a été créé afin de faciliter l’aspectgraphique. La liaison est basée sur le fait que l’emplacement d’un champ de saisi surl’écran dépendra de sa position dans la liste des attributs de l’objet correspondantà l’écran. La taille et le type de champ dépendront quand à eux du type et de laplace allouée en base de données.

L’implémentation de Project’Or RIA est donc décomposée en trois parties :Controleur, Modèle des données, Vues. Notre étude est principalement centrée sur lesdeux dernières parties. Les modèles de données vont permettre de créer de nouvellesfonctionnalités pour l’application, et les vues vont permettre la personnalisation del’affichage des nouvelles fonctions créées afin d’apporter un outil répondant exacte-ment aux besoins.

Autre point important de l’implémentation, l’application utilise la technologieAjax pour remonter les données à l’utilisateur. Pour ce faire, il a été choisi parles concepteurs d’utiliser la boîte à outils « Dojo ». Ce framework permet à la foisd’utiliser des outils graphiques tels que les menus hiérarchiques ou encore de fairefacilement l’affichage de la liste des éléments d’un objet. Il permet de plus de faireremonter les données via Ajax grâce à des fonctions simples.

26

Chapitre 5

Les nouvelles fonctionnalités

L’intégration de nouvelles fonctionnalités dans Project’Or RIA s’est faite en deuxtemps. Dans une première partie, il a été question d’intégrer de petites améliorationsindispensables afin d’inclure la dimension budgetaire dans le logiciel. Cette phasefut en d’autres termes une introduction au système. En parallèle à l’implémentationdes améliorations, des tests sur des données réelles ont été effectués, et ce, pours’assurer du bon fonctionnement de l’application.

Dans un deuxième temps, l’ajout de la gestion budgetaire des projets fut la prin-cipale problèmatique. Il fut question d’utiliser les nouvelles fonctionnalités afin derendre possible les calculs de coût de fonctionnement, prix de ventes, marges, . . .desprojets.

Afin de clarifier nos démarches, voici un schéma illustratif du principe de fonc-tionnement souhaité :

27

Figure 5.1: Schématisation du concept souhaité

5.1 Projet

5.1.1 Explication du problèmeComme nous l’avons décrit précédemment, Project’Or RIA a pour objectif de

gérer des projets dans lesquels la notion d’activité permet de ségmenter ces derniers.Pour aller plus loin dans cette ségmentation, nous avons décidé d’ajouter un typagedes activités. Ce système rendra alors possible la différenciation de ces dernières.

Par exemple, une activité de développement pourra être clairement différenciéed’une activité de conception.

De plus, un autre système de typologie de projet doit être ajouté. En effet, d’unpoint de vu budgetaire, il existe plusieurs méthodes de facturation d’un projet dontvoici les principales :

– régie ;– régie plafonnée ;– forfait.

Nous reviendrons plus en détails sur le fonctionnement des ces différentes mé-thodes lors de l’analyse détaillée de l’outil de facturation.

Enfin, la notion de prix de vente d’un projet ou d’une activité doit être créée.

28

5.1.2 Principe d’implémentation pour la typologiePour la création du type de projet et du type d’activité, nous allons utiliser

une méthode générique du framework sur laquelle est basée l’application. L’objet« Type »permet actuellement de créer une caractéristique générique pour un objet.Il est utilisé de nombreuse fois pour typer les jalons, les questions, . . .Il suffit alorssimplement de créer l’objet « ProjectType »héritant de « Type »pour le créer defaçon générique. Puis, l’ajout de l’attribut « public $idProjectType ; »dans l’objet« Project »ainsi que dans la table projet va permettre la selection d’un type lors dela création ou la modification d’un projet. La même méthode est utilisée pour letypage des activités.

Pour détailler un peu plus le modèle générique de typage, nous pouvons dire quece modèle permet de joindre à un objet une caractéristique supplémentaire. De plus,outre le fait de donner un nom à cette caractéristique, chaque type possédera un« workflow »paramétrable qui lui sera propre. Pour donner un exemple concret, pourun problème posé dans Project’Or RIA, il sera possible de le régler uniquement ensuivant une suite d’étapes précise définie par ce « workflow ». Ainsi, en fonction dutype de question, le « workflow »pourra être différent.

5.1.3 Principe d’implémentation du prix de venteL’implémentation réside simplement dans la création de l’objet « activityPrice ».

Cet objet aura comme attributs un identifiant projet, un identifiant type d’activités(développement, . . .), ainsi qu’un ensemble de valeurs sur lesquelles nous revien-drons par la suite. La table « activityPrice »nous donnera alors les liens entre untype d’activité et un projet pour lui conférer un prix de vente.

Voici une image permettant d’illustrer l’amélioration :

29

Figure 5.2: Ecran de renseignement du prix d’un type d’activité pour un projet

30

5.2 Sous-traitanceLors du traitement d’un projet, Salto Consulting peut faire appel à des interve-

nants extérieurs. En utilisant ces ressources, on induit un coût de sous-traitance.

Son fonctionnement est similaire à l’utilisation du prix de vente d’une acti-vité présentée précédemment. C’est pourquoi nous utiliserons l’objet « Activity-Price »pour inclure la notion de sous-traitance et donc de coût de sous-traitance.

Bien que cette notion implique un coût, par rapport à la socièté sous-traitante,son principe de fonctionnement s’apparente au type des activités. En effet, pour untype d’activité et pour un projet précis, correspond un tarif. C’est pourquoi, l’incluredans l’objet prix de l’activité ne pose pas de problème.

5.3 CommissionsComme son nom l’indique, il est possible de verser des commissions à des tierces

entités. Pour gérer cela, nous devons l’intégrer dans Project’Or’RIA.

Exactement comme pour la sous-traitance, le coût de commission sera inclusdans le prix de l’activité. Pour le rendre utilisable, un champ va être ajouter en plusafin de spécifier à qui sera due cette commission.

5.4 AbaqueNous voulons intégrer la notion d’abaque dans le logiciel Project’Or RIA. Pour

cela, nous allons commencer par définir le terme abaque et son utilisation dans lagestion d’un projet en informatique.

Un abaque dans un projet en informatique permet d’établir une corrélation entreles différentes phases. Par exemple, pour un type de projet connu, on peut déter-miner des ratios, qui permettent par le suite de connaître le temps nécessaire àl’accomplissement de chaque phase. En d’autres termes, il est possible de chiffrer unprojet de la façon suivante :

– détermination des ratios (exemple : 50% pour le développement, 25% pourl’analyse, 10% pour l’intégration, 10% pour la conduite de projet et 5% endivers) ;

– déterminer une référence pour le projet : cette référence permet de savoir surquelle phase se baser pour les calculs du temps de réalisation.

Dans cet exemple, si on sait que la phase de conception nécessitera 2 jours, alors,l’analyse durera 5 jours, le développement 10 jours, l’intégration 2 jours et il restera

31

1 jour en divers.

L’ensemble de ces valeurs est déterminé grâce à l’expérience du chef de projet.Un bon abaque facilitera grandement le déroulement du projet.

Dans un premier temps, l’intégration de cette notion ne se fera que par l’ajoutde deux champs dans la table « activityprice » : un pourcentage et un booléen. Cesdeux attributs donneront ainsi le pourcentage dans l’abaque ainsi que le fait si ouiou non ce type d’activité, pour un projet donné, est référence pour celui-ci. Dans unsecond temps, non inclus pendant le stage, nous évaluerons la nécessité d’aller plusloin, en intégrant par exemple un calcul automatique de la durée des activités.

5.5 FacturationComme nous l’avons précisé en introduction, le développement de l’outil de fac-

turation est l’étape la plus importante en taille et en complexité. En effet, il s’agitd’utiliser toutes les données disponibles dans la base de données afin de permettreune évaluation avec précision du prix de vente d’un projet.

Pour l’implémenter, il faut définir plusieurs parties distinctes. En effet, pourmettre en place un système de facturation, il faut permettre la création d’échéancesde paiement, mais aussi l’édition de facture.

Mais avant cela, nous allons expliciter différents termes introduits précédemment,en l’occurence, les types de projet :

– la régie : un projet dit, en régie, sera facturé à la journée passée. En d’autrestermes, l’entreprise dépense dix jours pour mener à bien le projet, le clientpaiera dix jours.

– le forfait : un projet dit, au forfait, aura un prix de départ, généralementdéfini par l’entreprise puis soumis à négociations. Ce prix n’évoluera pas, saufexception, durant la totalité du projet et ce, peu importe de nombre de jourspassés.

– la régie plafonnée : est un mélange entre les deux types précédents. Un projetdit, en régie plafonnée possédera un seuil en nombre de jours, avant lequel leprojet sera facturé au jour passé mais après lequel il sera facturé comme unforfait. Ainsi, si le projet met moins de jours que prévu pour être réalisé, leclient paiera uniquement le nombre de jours utilisés, par contre, si l’entreprisedépasse son estimation, les jours supplémentaires ne seront pas facturés.

Nous allons maintenant décrire l’implémentation de l’échéancier.

32

5.5.1 EchéancierDans le cadre d’un projet dit au forfait, celui-ci est très généralement facturé à

l’échéance. C’est à dire, qu’à une date donnée, une facture est émise comportant unepartie de la somme due par le client au prestataire. Cette somme peut être calculéede deux façons différentes. Soit une valeur fixée par l’utilisateur de l’application, soitune valeur calculée par rapport aux jours consommés sur les activités du projet àfacturer.

Le premier cas est très simple, car il suffira d’intégrer la valeur enregistrée parl’utilisateur dans la future facture. Alors, un simple champ dans la base suffira àrenseigner la valeur souhaitée. Le second cas mérite plus d’attention. En effet, pourcalculer le prix de vente d’une activité, il faut attendre la clôture de celle-ci pourainsi éviter l’imputation de nouveaux jour(s) consommés pour l’activité après lafacturation.

Pour gérer cela, il suffit d’ajouter un élément déclencheur à l’échéance, ainsil’échéance ne sera pas active et donc utilisable tant que l’ensemble des activitésincluses dans cette échéance ne seront pas closes. L’objet « Dependancy »peut êtreutilisé dans cette situation. Normalement utilisé lors de la modification d’une acti-vité, « Dependancy »permet de définir un lien chronologique entre activités, jalonset projet. Chaque ligne de la table des dépendances nous donne un élément prédé-cesseur ainsi qu’un élément successeur. Ces dépendances sont utilisées dans le calculdu diagramme de Gantt.

Dans notre situation, intégrer une liste d’éléments prédécesseurs permet de gérerl’activation et le calcul des échéances.

En résumé, une échéance sera alors composée de ces différents attributs :– un nom ;– un identifiant projet ;– une date et un montant (si l’utilisateur désire forcer une valeur et une dated’activation) ;

– une liste d’éléments déclencheurs (cette liste sera présente dans la table « de-pendancy »).

33

Le principe de fonctionnement d’une échéance s’arrête là. Tous les calculs de prixde vente s’effectueront dans le module de facturation. Voici alors le résultat obtenu :

Figure 5.3: Ecran d’échéancier

34

5.5.2 FactureLe principe de fonctionnement du module facture est le suivant. Dans le cadre

d’un projet au forfait, l’utilisateur aura au préalable créé ses échéances de paiement.Puis, il suffit de créer une facture, de préciser le client, le contractant, . . .

Ainsi, tous les calculs se font automatiquement en respectant le typage du projetde la facture. Nous allons donc décrire plus en détails les trois algorithmes de calcul :

– Dans le cadre d’un projet au forfait, il n’y a aucun besoin de calculer le prix parrapport à des jours passés sur le projet. La marche à suivre est la création d’uncertain nombre d’échéances avec un tarif fixe. A la création de la facture, l’en-semble des prix des échéances du projet est récupéré donc donner un tarif total.

– Dans le cadre d’un projet en régie, le prix de vente sera calculer grâce au prixde vente par type d’activité. Cette notion a été introduite dans la série d’amé-liorations présentées précédemment. Dans les caractéristiques de la facture, ilsuffit de renseigner un intervalle de date pour un projet donné. A la validation,le logiciel va rechercher l’ensemble des jours consommés dans le projet, puis,connaissant le prix de chaque jour, nous obtenir un prix total. La difficulté surce point, est de ne pas comptabiliser le même jour sur un projet pour deuxfactures différentes. A l’affichage, pour clarifier la facture, un détail est affichépar activité, on peut y voir son prix, son nom et la ressource employée.

– Dans le cadre d’un projet en régie plafonnée, comme dans la régie, le prixde vente est calculé par rapport aux jours consommés. Mais cette fois ci, unplafond, renseigné dans les détails du projet, limite le prix de vente. Ainsi, sisur deux factures pour le même projet, le seuil est atteint pour la premièrefacture, la seconde aura pour valeur zéro.

35

Voici le résultat final :

Figure 5.4: Ecran de facturation

36

5.6 Les problèmes rencontrésLa facturation nécessite un grand nombre de modification dans la base de don-

nées. De plus, toute modification dans cette base se fait par le biais de fonctiongénérique du framework. Le problème est que ces fonctions ne sont pas adaptéesà la modification de plusieurs entrées en même temps. En effet, à l’origine, pourmodifier une entrée de la base de données, le framework doit charger entièrementl’objet de la base de données. Puis il nous est possible de le modifier. Et enfin unefonction permet de le sauvegarder. Pour plusieurs entrées à modifier, la procédureprécédente doit être répétée autant de fois que d’entrée. On peut alors comprendreaisaiment que le temps d’utilisation du serveur peut augmenter très rapidement.

Autre problème de l’application, le système d’accès à la base de données n’estpas transactionnel. C’est à dire, qu’en cas de problème, il est impossible de fairemachine arrière pour éviter de corrompre la base.

Si on relie ces deux problèmes, dans le cas d’un temps de calcul dépassant leseuil autorisé par le serveur, les modifications en base de données s’arrêtent avantd’avoir terminé le traitement. La base est corrompue.

La mise en place d’un système transactionnel nécessitant une charge temporelletrop importante, la solution est dans la simplication de la méthode de mise à jourde la base. Ainsi, des modifications dans la structure des algorithmes ont été réali-sées dans le but de regrouper l’ensemble des mises à jour de la base. Puis, au lieud’utiliser le procédé d’update du framework, les requètes ont été faites directement.Le modèle MVC est alors contourné, mais les gains en temps de calcul sont consi-dérables. Pour valider les changements, des tests ont été effectués sur un ensemblede données dépassant largement le volume d’utilisation normal.

37

Chapitre 6

Conclusion

Project’Or RIA est actuellement utilisé au sein de Salto Consulting, le modulede facturation aussi. On peut donc conclure que la démarche et le développementdes outils supplémentaires ont permis de répondre à la problèmatique posée.

Les six mois de stage de fin d’études m’ont permis d’appréhender deux visionsde la gestion projet. La première dans une entreprise de prestations en informatique,Salto Consulting, à échelle humaine. Et la seconde dans le service informatique d’ungrand nom du textile, Promod.

D’autres améliorations peuvent être mises à l’étude pour de future développe-ments. Ainsi, intégrer le transactionnel permettrait un gain considérable en sécu-risation des données. La perte de certaines données peuvent causer des dommagesnon négligeables pour l’entreprise. De plus, une liaison avec des logiciels tiers tel queJIRA peut être envisagée. En Effet JIRA dispose d’un système d’export de donnéeset Project’Or RIA possède les prémisses d’un dispositif d’importation.

38