MANAGEMENT DE PROJET INFORMATIQUE : PROPOSITION COMMERCIALE AKALYS Proposition commerciale

Dimension: px
Commencer à balayer dès la page:

Download "MANAGEMENT DE PROJET INFORMATIQUE : PROPOSITION COMMERCIALE AKALYS Proposition commerciale"

Transcription

1 2009 MANAGEMENT DE PROJET INFORMATIQUE : PROPOSITION COMMERCIALE AKALYS Proposition commerciale Proposition commerciale sur le développement d un outil intranet de gestion de projet. ASSY BIANCHERI MARTIN - SAVARY AKALYS 07/01/2009

2 Sommaire Sommaire Les atouts de la proposition Introduction L appel d offre L organisation du projet Processus Organisation structurelle Technologies utilisées La solution proposée Description formelle Authentification / autorisation par LDAP Gestion des projets Gestion des besoins Gestion optimisée des projets Gestion d une version Gestion des catégories Gestion des versions de référentiel projet Rechercher (mot clé) Gestion des droits Architecture technique & web Démarche de développement Les différentes phases du projet Les activités par phase: Phase 1 : Analyse des besoins et de la faisabilité

3 4.2.2 Phase 2 : Spécification Phase 3 : Conception architecturale Phase 4 : Conception détaillée Phase 5 : Codage Phase 6 : Tests unitaires Phase 7 : Tests d'intégration Phase 8 : tests de validation Phase 9 : Recette Les intervenants Documentation Documentation Interne Etat d'avancement du projet La liste des tâches Comptes-rendus de réunions Documents de test Plan de test Validation de test Cahier de recette Documentation Externe Manuel d'utilisation Manuel de maintenance Manuel de sécurité Charte Informatique Manuel Développeur... 23

4 6 Gestion des risques Process de gestion des risques Risques identifiés Estimations des charges Planning de réalisation Diagramme de Gantt Proposition financière... 37

5 1 Les atouts de la proposition Forte de ses 5 années d'expérience qui ont fait sa notoriété, l'entreprise AKALYS est devenue un incontournable dans le secteur de l'ingénierie et des services informatiques. La société conçoit et développe des solutions logicielles pour les entreprise et institutions désireuses de moderniser leur système d'information ou d'adopter un nouvel outil informatique. Suite à votre appel d'offre, nous avons imaginé la solution idéale pour votre entreprise. Conçu selon une organisation au forfait, le logiciel de gestion et de suivi de projet que nous vous proposons vous permettra d'accroitre votre productivité et d'améliorer votre activité au quotidien. Simple et complet, ce logiciel convient à vos attentes et satisfait vos exigences. Nous mettons a votre disposition tous les facteurs clé qui ont fait notre succès : - communication claire et précise avant un intervenant unique durant toute la durée du projet - une analyse exhaustive de vos besoins ainsi qu'un suivi régulier - une équipe de professionnels maitrisant les technologies employées dans le projet - une formation complète de tous vos collaborateurs amenés a utilisé le logiciel - une garantie sans failles Nous tenons à remercier tous les membres de WINTER.CORP de l aide qu ils nous ont apporté lors de la définition du projet ainsi que lors de toutes les étapes de notre collaboration.

6 2 Introduction 2.1 L appel d offre L'entreprise X désire optimiser l'organisation et la réalisation de leurs projets. Pour cela, elle souhaite intégrer une application Intranet spécifique. Cette dernière aura pour but de gérer les besoins pour chaque projet. L entreprise WINTER.CORP fait donc un appel d'offre afin qu'un prestataire de service réalise ce projet. 2.2 L organisation du projet Processus Le cycle de vie d'un logiciel est une phase importante lors du projet car il désigne toutes les étapes du développement d'un logiciel, de sa conception à son déploiement. Toutes les étapes de ce processus ont pour objectifs de permettre la validation du développement logiciel, c'est-à-dire la conformité de ce dernier avec les besoins exprimés, mais également la vérification du processus de développement, c'est-à-dire l'adéquation des méthodes mises en œuvre. Mais chaque projet est en adéquation avec un cycle de vie, et celui que nous avons estimé être le meilleur pour ce dernier est le modèle en V. Ce genre de modèle est tout d'abord adapté aux projets de taille et de complexité moyenne. Ensuite il respecte un certain processus qui permet de vérifier en continu la qualité du produit au fur et à mesure de sa fabrication. Et enfin Il permet d'identifier et d'anticiper très tôt les éventuelles évolutions des besoins.

7 2.2.2 Organisation structurelle Directeur informatique: Le rôle du Directeur informatique consistera à gérer, organiser et coordonner tous les aspects de notre service et à assurer le déploiement efficace des ressources disponibles (budget, main d œuvre, par exemple) afin de répondre aux besoins du projet. En bref il a pour but de piloter le projet et donc d'en assurer le suivi. Chefs de projet: Le chef de projet informatique a pour mission de développer une solution spécifique adaptée à la demande du client et d'intégrer le logiciel tout en respectant les conditions fixées par le directeur informatique. Il doit assurer la gestion du projet en respectant les coûts, veiller au respect du planning, des délais, du cahier des charges et des contraintes techniques. Son intervention commence dès la phase d'étude, puis c'est la mise en route du projet, la coordination commence. En phase finale, après avoir supervisé la mise au point de la solution informatique, le chef de projet participe à la mise en place de l'outil et recueille, si nécessaire, les améliorations à envisager. Equipe d'analyse et de conception: Cette équipe, composée de chef de projet et d'un analyste programmeur, a pour but de permettre de formaliser les étapes préliminaires du développement du système informatique afin de rendre ce développement plus fidèle aux besoins du client. Pour se faire, on part d'un énoncé informel (le besoin qui est exprimé par le client, complété par des recherches d'informations auprès des experts du domaine fonctionnel, dans notre projet, les futurs utilisateurs du système informatique), ainsi que de l'analyse de l'existant éventuel. La phase d'analyse permet de lister les résultats attendus, en termes de fonctionnalités, de performance, de robustesse, de maintenance, de sécurité, d'extensibilité. La phase de conception permet de décrire de manière non ambiguë, le plus souvent en utilisant un langage de modélisation, le fonctionnement futur du système, afin d'en faciliter la réalisation.

8 Equipe de développement: Cette équipe réalise des logiciels en créant des algorithmes et en les mettant en œuvre dans un langage de programmation. La notion de développement inclut : - Un travail d'équipe : les projets sont en général une collaboration entre plusieurs développeurs sous la responsabilité d'un chef de projet, qui traitent chacun une partie du programme, mais aussi d'autres collaborateurs tels que des concepteurs graphiques qui définissent l'aspect et l'ergonomie. - La conception (design) : à partir d'un cahier des charges, définir les spécifications techniques (structures de données, communications entre les modules,...). - La maintenance : la correction des erreurs après la sortie du logiciel, et l'amélioration pour faire évoluer le produit. Equipe de test: Cette équipe doit avoir, bien entendu, des connaissances en informatique afin de détecter les erreurs qui auraient pu apparaitre durant la phase de développement. Ils ont pour mission de réaliser tous les tests concernant le projet: - Tests unitaires : Equipe informatique. - Tests d'intégration : le MOE accompagné d'un analyste programmeur. - Tests de validation : MOE. Equipe d'installation: Cette équipe a de grandes connaissances dans le milieu informatique : matériels, réseaux, serveurs, logiciels, langage SGBD (Système de Gestion de Base de Donnée) : - Bases de données : définir et élaborer l'architecture des bases de données. (un administrateur de base de données). - Système : installation de l'application, tout en vérifiant que les connexions avec le serveur fonctionnent correctement. (1 ingénieurs systèmes).

9 Equipe de formation: L'installation d'un nouveau système dans une entreprise doit tenir compte d'un élément important : l'engagement de tout le personnel concerné, étant donné que ce système va modifier les processus existants et les responsabilités de chacun. Ainsi cette équipe aura la charge de former le personnel aux différentes fonctionnalités proposées par l'application. Bien entendu un employé ayant énormément de responsabilités aura une formation différente de celle d'un employé qui en a moins (1 formateurs) Technologies utilisées Dans un projet tel que celui-ci, il faut se pencher sur, les technologies émergentes, les technologies d'actualité. Dans un souci d'ergonomie, afin de rendre uns solution dont l'utilisation sera optimale, il faut se référer aux futurs utilisateurs. Ces futurs utilisateur son souvent habitués à un mode d'utilisation d'un ordinateur. Ils sont souvent habitués à travailler sur plusieurs logiciels différents. Il est donc préférable de les faire évoluer sur un logiciel facile d'utilisation, comme l'utilisation d'internet. Nous allons donc opter pour une application de type web s'exécutant dans un navigateur, en Intranet, et pour cela nous avons choisit une solution développée en J2EE. 3 La solution proposée 3.1 Description formelle L'application que nous proposons sera divisée en plusieurs modules interdépendants. En effet, l'outil devant servir à la gestion de projet, il sera équipé de plusieurs fonctionnalités. Tout d'abord, pour l'aspect sécurité, il sera équipé d'une identification par LDAP, qui aura pour but de vérifier les droits et l'identité de l'utilisateur dès qu'il souhaitera intervenir sur l'outil. Le logiciel permettra également de crée des liste de projets. Pour chaque projet seront associé des listes de

10 fonctionnalités. Ces listes de fonctionnalités représenteront la liste des besoins spécifiés par l'ensemble des collaborateurs du projet, du chef de projet au client en passant par les concepteurs. Pour chaque projet nous aurons donc différentes catégories de fonctionnalités et de besoins. Ces listes de besoins devront être particulièrement bien structurées. En effet, nous mettrons en place un module de gestion des versions permettant de conserver chaque version des besoins au cas où ceux-ci changent en cours de route. Un module de recherche sera également mis en place pour des recherches variées (projet, besoin, etc...) Authentification / autorisation par LDAP Afin de garantir l'aspect sécurité et intégrité des données, l'identification des utilisateurs se fera par un annuaire électronique, selon le protocole LDAP. Les annuaires électroniques sont un type de base de données spécialisées permettant de stocker des informations de manière hiérarchique et offrant des mécanismes simples pour rechercher l'information, la trier, l'organiser selon un nombre limité de critères. Ainsi le but d'un annuaire électronique est approximativement le même que celui d'un annuaire papier, si ce n'est qu'il offre une grande panoplie de possibilités que les annuaires papier ne sauraient donner. L'utilisation d'annuaire ne se limite pas à la recherche de personnes ou de ressources. En effet, un annuaire peut servir à : - constituer un carnet d'adresse - authentifier des utilisateurs (grâce à un mot de passe) - définir les droits de chaque utilisateur - recenser des informations sur un parc matériel (ordinateurs, serveurs, leurs adresses IP et adresses MAC,...) - décrire les applications disponibles

11 Un annuaire est donc un type de base de données spécifique, c'est-à-dire qu'il s'agit d'une sorte de base de données ayant des caractéristiques particulières : - un annuaire est prévu pour être plus sollicité en lecture qu'en écriture. Cela signifie qu'un annuaire est conçu pour être plus souvent consulté que mis à jour. - les annuaires doivent être compacts et reposer sur un protocole réseau léger - Un annuaire doit comporter des mécanismes permettant de rechercher facilement une information et d'organiser les résultats - Un annuaire doit être capable de gérer l'authentification des utilisateurs ainsi que les droits de ceux-ci pour la consultation ou la modification de données (voir ci-dessous la gestion des droits utilisateur). Dans notre cas, il servira à authentifier les utilisateurs et décrire leurs droits.

12 3.1.2 Gestion des projets Ce module permettra la création d'un projet et d'y associer plusieurs informations capitales. - Création d un projet (assignation d'id) : Cette fonctionnalité a pour but de permettre la création d'un nouveau projet. Un numéro unique d'identification lui sera attribué afin de permettre de lui associer les différentes options vu précédemment et ci-après (liste de besoins, personnel etc...). - Modification d un projet : Cette fonctionnalité permettra de modifier les informations primaires d'un projet (le nom etc...) - Suppression d un projet : Cette fonctionnalité nous permettra de supprimer un projet si celui - ci est abandonné. - Assignation des rôles (participants) : Ce module doit permettre de créer une liste de participant ainsi qu'une "mailing-list" afin de favoriser la communication entre les membres participants aux projets. Il sera également possible de rappeler leur poste, fonction, et le motif de leur intervention dans le projet Gestion des besoins Ce module est indirectement associé a un projet en effet il s'agit ici de créer soit une liste des besoins soit un cahier de spécifications qui sera associé à un projet. - Création d une liste de besoin : Ces besoins seront donc matérialisés sous forme de liste o Liste des besoins (paginée, par ordre des IDs, regroupés par catégorie) : Cette liste comprendra tous les besoins répertoriés. Elle aura elle aussi un numéro unique d'identification et sera paginée. Cette liste pourra être mise à jour par l'intermédiaire d un formulaire HTML. o Association à un projet (id) : Cette liste devra être associée à un projet. Liste déroulante d'association aux projets répertoriés. o Ajout d un besoin : Un bouton d'ajout permettra d'ajouter un besoin

13 o Modification d un besoin : Un bouton de modification permettre la modification d'un besoin o Suppression d un besoin : Enfin nous pourrons également supprimer un besoin le cas échéant Gestion optimisée des projets Pour chaque projet, nous devons toujours bien définir qui intervient. Du directeur de projet aux commerciaux, chaque personne intervenant sur le projet doit être répertoriée dans un souci d'estimation du budget, de planification, et de communication afin de limiter les différents risques liés à une mauvaise organisation. Pour cela nous avons mis en place plusieurs fonctionnalités permettant la simplification du travail du chef de projet. - Liste des participants : Cette étape va permettre de créer une liste de participants. Chaque personne intervenant à un moment donné sur le projet sera inscrite dans une liste de participants. Ceci permettra une meilleure organisation et une meilleure communication au niveau d'un projet. Pour chaque personne, nous inscrirons son nom, sa fonction, pour qui il travail (nous, le client ou s'il est libéral), et le nombre heures ou Jour-Homme passés sur le projet. - Planning : Ce module a été mis en place afin de rester en adéquation avec notre proposition qui est de gérer chaque aspect de la gestion de projet. En effet, cette partie permet au chef de projet de définir son planning et de le représenter sous la forme souhaitée (Gantt ou PERT). Il sera ensuite affecté au projet tout en ayant la possibilité de le modifier à chaque instant. - Etablissement du Budget : Ce module va permettre au chef de projet d'associer un budget à un projet. Ce budget sera établit à partir des différentes informations recueillies dans les modules précédents. Il pourra également être géré en temps réel Gestion d une version - Liste paginée des besoins par ordre des IDs, regroupés par catégorie. Une version est une liste paginée des besoins, ou fonctionnalités de l'outil final. Lorsque les

14 besoins changent, une nouvelle version est créée à partir de l'ancienne. Cette option permettra au chef de projet de prendre en compte les modifications des spécifications afin d'en tenir copte par la suite dans l'estimation des charges, du budget et du planning, en cas de gros changement. - Ajout d une catégorie. Dans un projet, tous les besoins peuvent être regroupés sous forme de catégories afin d'optimiser l'organisation de ce dernier. Il est donc possible à tout moment d'ajouter une catégorie. - Ajout d un besoin, modification, suppression. Un besoin peut être rajouté à tout moment et cela générera automatiquement une nouvelle version pour le projet Gestion des catégories - Liste des besoins : Comme dit précédemment, pour une meilleure organisation dans la liste des besoins, ces derniers peuvent être regroupés sous forme de catégories, ce qui pourrait par exemple faciliter la réalisation d'un projet en créant des modules visant un travail qui satisferait tous les besoins liés à une catégorie - Ajout/modification/suppression d une catégorie : Le logiciel donnera la possibilité de rajouter, de modifier ou de supprimer une catégorie dans une liste de besoins, ce qui entrainera automatiquement la création d'une nouvelle version du projet où l'action se fait Gestion des versions de référentiel projet - Affichage de la liste des versions du référentiel : Chaque projet aura une sorte d'historique permettant ainsi de lister et par la même occasion de consulter chaque version d'un projet en indiquant la date de création de cette dernière - Ajout d une version (par recopie de la version précédente, on fige la précédente) : Quand une action bien spécifique change le contenu du projet, une nouvelle version du projet est créée tout en mémorisant le projet avant toutes modifications apportées.

15 - Suppression de la dernière version : Bien entendu la possibilité d'effacer une version est une fonctionnalité du logiciel. - Affichage des différences entre 2 versions : Si l'utilisateur le désire il peut voir la différence entre deux versions d'un même projet. L'écran se divisera afin d'avoir sous les yeux ces projets, et toutes différences seront distinguées par une couleur afin de faciliter l'analyse de ces versions Rechercher (mot clé) Ce module permettra d'accéder directement au projet souhaité. En effet, la recherche par mot clés permettra de choisir (par une liste box) si le mot clés porte sur un projet ou une source de données etc... - recherche d un projet : En sélectionnant dans la liste box l'option Projet, l'utilisateur fera une recherche par mot clés sur les noms accordés aux différents projets. - Rechercher d une catégorie dans un projet : En sélectionnant dans la liste box l'option catégorie, le logiciel renverra n'importe quel type de résultat sur la recherche effectuée. - Recherche d une liste des besoins : En sélectionnant dans la liste box l'option Liste des besoins, l'utilisateur fera une recherche sur une version ou sur une liste de besoins. Le nom du projet y sera associé. - Recherche d un besoin Gestion des droits La gestion des droits utilisateur est au cœur du problème de confidentialité et de sécurité du système, qui reste toujours l'un des principaux risques. Un système de gestion des droits devra donc être mis en place afin de définir, pour chaque utilisateur, un profil particulier. Nous distingueront donc trois catégories d'utilisateurs. - Administrateur : La catégorie administrateur sera attribuée au minimum d utilisateurs possibles: le chef de projet, le directeur de projet, les responsables du fonctionnement du logiciel.

16 - Utilisateur Simple : Cette catégorie sera attribuée aux utilisateurs secondaires. Ces utilisateur auront accès qu'à certaines données et n'auront qu'un droit de lecture sur les fichiers sélectionnés. - Super utilisateur : Ces utilisateurs auront des droits spécifiques, ils auront accès aux données mais ne pourront pas modifier toutes les informations auxquelles ils ont accès. La gestion des droits reposera elle aussi sur le protocole LDAP vu précédemment. 3.2 Architecture technique & web Suite à l'audit réalisé par nos soins sur l'organisation technique de votre entreprise, nous en avons déduit que celle - ci était parfaitement apte à recevoir notre application, à savoir: - un serveur web, - un serveur de base de données MySQL, - un serveur LDAP. Concernant l'environnement technique il est donc opérationnel, nous n'interviendrons pas a ce niveau là.

17 4 Démarche de développement 4.1 Les différentes phases du projet - Phase 1 : Analyse des besoins et de la faisabilité. - Phase 2 : Spécification. - Phase 3 : Conception architecturale. - Phase 4 : Conception détaillée. - Phase 5 : Codage. - Phase 6 : Tests unitaires. - Phase 7 : Tests d'intégration. - Phase 8 : tests de validation. - Phase 9 : Recette. 4.2 Les activités par phase: Phase 1 : Analyse des besoins et de la faisabilité. Pour établir les besoins décrits dans le cahier des charges fournies par le client, Il faut avant tout étudier le domaine d'application, l'état actuel de l'environnement du futur système, le rôle du système, les ressources disponibles et requises, les contraintes d'utilisation, les performances attendues,.... Il faut également établir un dialogue avec les experts du domaine (le client), qui ne sont pas forcément des informaticiens, et s'informer avec diverses méthodes : entretiens, questionnaires, observation de l'existant et étude de situations similaires.

18 4.2.2 Phase 2 : Spécification. Dossier entrant : Cahier des charges. Cette phase peut être vue comme la première étape du développement représentée sous forme d'un ensemble de document qui décrit de manière formelle et exhaustive le produit informatique à réaliser. Ces documents peuvent être classés en deux parties: - Spécification fonctionnelle: Documents rédigé par un analyste fonctionnel, ils décrivent toutes les activités (processus métier) dans lesquels le produit informatique devra intervenir. - Spécification d'architecture : Documents rédigée par un architecte, la spécification d'architecture décris le système informatique dans lequel le produit sera implanté, son interaction avec les autres composants du système informatique. En résumé la spécification est utile pour: - Expliquer en détail les attentes du futur utilisateur, le produit qu'il espère voir être construit. - Le budget et le planning, elle sert de base pour calculer le coût de réalisation et la durée, informations clé pour le établir le budget et le planning. - Le développeur, qui lui sert à expliquer le but à atteindre et les moyens techniques à mettre en œuvre pour y parvenir. Dossier sortant : Dossier de spécifications du logiciel Phase 3 : Conception architecturale. Dossier entrant : Dossier de spécifications Elle décrit l'organisation du produit informatique. Elle permet de découper le travail, en regroupant toutes les fonctionnalités décrites dans le dossier de spécification, en modules plus simples, définis par leurs interfaces et leurs fonctions. Ce qui facilite le travail et l'élaboration du planning. Dossier sortant : Dossier de conception générale, dossier provisoire de tests/validation.

19 4.2.4 Phase 4 : Conception détaillée. Dossier entrant : Dossier de conception générale. Après le découpage, viens la phase d'approfondissement. Chaque module est détaillé afin d'avoir une meilleure précision sur les fonctionnalités que doit remplir l'objet ainsi que la modélisation fonctionnelle du besoin, mais également une meilleure précision sur les principes physiques qui vont être utilisés afin de remplir les exigences fonctionnelles Dossier sortant : Dossier de conception détaillée, dossier provisoire de tests unitaires Phase 5 : Codage. Dossier entrant : Dossier de conception détaillée La programmation représente l'ensemble des activités qui permettent l'écriture des programmes informatique. C'est une étape importante de la conception du logiciel Dossier sortant : Dossier des tests unitaires.

20 4.2.6 Phase 6 : Tests unitaires. Dossier entrant : Dossier de conception détaillée, dossier des tests unitaires. C'est un procédé permettant de s'assurer du fonctionnement correct d'une partie déterminée d'un logiciel ou d'une portion d'un programme. Il s'agit pour le programmeur de tester un module, indépendamment du reste du programme, ceci afin de s'assurer qu'il répond aux spécifications fonctionnelles et qu'il fonctionne correctement en toutes circonstances. Cette vérification est considérée comme essentielle, en particulier dans les applications critiques. Elle s'accompagne couramment d'une vérification de la couverture de code, qui consiste à s'assurer que le test conduit à exécuter l'ensemble des instructions présentes dans le code à tester. Dossier sortant : Dossier des tests d'intégration Phase 7 : Tests d'intégration. Dossier entrant : Dossier de conception générale, dossier des tests d'intégration. Les tests d'intégration ont pour but de valider le fait que toutes les parties développées indépendamment fonctionnent bien ensemble de façon cohérente dans le cadre d'une livraison Dossier sortant : Dossier des tests de validation Phase 8 : tests de validation. Dossier entrant : Dossier de spécifications, dossier des tests de validation. Le test de validation permet de vérifier si toutes les exigences client décrites dans le document de spécification d'un logiciel, écrit à partir de la spécification des besoins, sont respectées. Les tests de validation se décomposent généralement en plusieurs phases: - Validation fonctionnelle : Les tests fonctionnels vérifient que les différents modules ou composants implémentent correctement les exigences client.

21 - Validation solution : L'intérêt est de valider la stabilité d'une solution par rapport aux différents modules qui la composent, en soumettant cette solution à un ensemble d'actions représentatif de ce qui sera fait en production. Dossier sortant : Dossier des tests de validation complet, Manuel d'utilisation et d'installation, Dossier de livraison Phase 9 : Recette Cette partie corresponds aux tests de validation, mais réalisés par notre client. Lors de cette étape (aptitude à répondre aux besoins exprimés dans le cahier des charges initial), le client réalise deux catégories de tests différentes. D'un côté, une recette technique est effectuée afin de vérifier que le produit livré est techniquement conforme sur toute la chaîne de processus. De l'autre, la maitrise d'ouvrage contrôle l'aspect fonctionnel du produit lors de la recette fonctionnelle. 4.3 Les intervenants - Phase 1 + phase 9 : Analyse des besoins et de la faisabilité + recette. MOA - Phase 2 + phase 8 : Spécification + tests de validation. MOE - Phase 3 + phase 7 : Conception architecturale + tests d'intégration. Équipe Architecturale (MOE + Analyste programmeur). - Phase 4 + phase 5 + phase 6 : Conception détaillée + codage + tests unitaires. Équipe de développement.

22 5 Documentation La documentation va permettre au projet d être structuré. Chaque décision prise, chaque modification apportée sera listée afin de favoriser une bonne organisation du projet et une bonne communication entre les personnes impliquées. 5.1 Documentation Interne Cette documentation est composée de plusieurs documents internes au projet. Elle concerne le bon déroulement du développement du projet Etat d'avancement du projet Cette partie fait office de carnet de bord. C est un document qui sera mis à jour quotidiennement afin que chaque personne se tienne au courant de l avancement général du projet La liste des tâches Ce document permettra à chaque personne impliqué dans le projet de suivre une ligne de conduite précise par rapport au développement de ce dernier. Ce document est une reformulation du cahier des spécifications et servira de liste des tâches Comptes-rendus de réunions Après chaque réunion, un compte rendu daté et signé par les membres y ayant pris part sera rédigé afin de conserver une trace écrite des décisions ou des modifications apportées au projet. 5.2 Documents de test Ces documents prennent en compte l avancement des tests Plan de test Ce document est une liste des tests à réaliser afin de bien redéfinir chaque module de l application et ses fonctionnalités Validation de test Ce document est une liste des tests réalisés avec succès. Il va permettre de vérifier les résultats attendus et les éventuelles modifications apportées au projet Cahier de recette Ce document va permettre de mettre en évidences les tests de validation effectués et permettra de réaliser toutes les fonctionnalités de l application.

23 5.3 Documentation Externe La documentation externe est axée sur la bonne utilisation et la bonne maintenance de l application. Des versions papier et des versions CD-ROM seront fournies aux exploitants du système. Une aide en ligne pourra également être développée Manuel d'utilisation Ce manuel sera remis à chaque exploitant de l application afin de décrire chaque fonctionnalité du système et leurs options. Ce manuel a pour but d optimiser l utilisation de l application Manuel de maintenance Ce manuel sera remis aux techniciens de l entreprise. Il contient une liste complète des problèmes qui peuvent être rencontrés au cours de l installation ou de l utilisation de l application. Les coordonnées de nos techniciens seront communiquées dans ce document pour toutes difficultés rencontrées ou pour des questions relatives à des pannes ou des dysfonctionnements de l application Manuel de sécurité La mise en place d une politique de sécurité semble indispensable afin de sensibiliser le personnel aux risques encourus et leurs implications. Un manuel spécifique sera fourni avec l application. Une affiche sera à disposer dans chaque bureau du siège Charte Informatique Enfin, une charte informatique devra être remplie par chaque exploitant afin de freiner toutes utilisations frauduleuses et/ou néfastes du système Manuel Développeur Ce document représentera une description du codage de l application et une aide en cas d erreur ou de bug.

24 6 Gestion des risques 6.1 Process de gestion des risques Pour ce projet, notre identification des risques se fera par la méthode imposée. Cette méthode consistera à se poser le maximum de questions concernant l'ensemble du projet de la phase d'analyse à sa mise en production. Ce procédé nous permettra d'identifier les risques du projet, leur impacte éventuel, ainsi que les solutions envisagées ou prédispositions effectuées pour contrer ces risques. 6.2 Risques identifiés Type de risque Financiers Technologiques Contraintes Ressources Méthode Qualité Fonctionnelle Qualité Technique Secteur(s) de risque Développement exploitation émergence obsolescence matériel étude de l'existant délais / planning budget visibilité Adéquation offre / demande nombre compétences motivation par phases / lots adéquation couverture évolution Prise en charge budget / délai Compétences interruption

25 reprises sur pannes sauvegardes sécurité Qualité Documentation Qualité Tests Qualité Formation Déploiement Codage fonctionnalités limites interfaces manuels utilisateurs ressources suivi impact validation permanente intégration au planning / budget Compatibilités ressources matérielles Evolution organisationnelle Fiabilité de l exploitation Sécurité des données Juridique Qualité Sauvegardes et backups Contacter la CNIL Tableau d'identification des risques: identification du risque, de leurs conséquences et les solutions proposées pour gérer ces risques. Ce processus d'identification des risques à été mis en place pour la gestion de projet générale de notre société. En effet, ce processus est chacun de nos projets afin de diminuer les risques inhérents à ces projets. Nous fonctionnons également en Validation Permanente. A la fin de chaque phase, les responsables projet interviennent afin de procéder à une vérification du travail effectué (Au moins le Chef de projet). Il(s) valide(nt) l'avancement du projet et le transmet(tent) au client qui le valide à son tour, avant de passer à la phase suivante.

26 Phase Identification du risque Type de risque Répercutions possibles Solution (s) Proposée(s) Analyse Initialisation La mise en service de l application aura-t-elle un impact organisationnel? Organisationnel Modification organisationnelle Les structures projet sont-elles clairement définies? Comités, acteurs, locaux Mauvaise organisation du projet Réunion commune avec tous les acteurs du projet pour définir les structures projet. Les objectifs sont-ils connus de tous et diffusés à tous les acteurs concernés? Mauvaise Communication Méconnaissance des objectifs par l ensemble des acteurs Réunion de lancement du projet commune avec tous les acteurs du projet pour définir les objectifs. La planification de la phase Cadrage est-elle approuvée? Communication Validation planning Retard du début du projet Demander la confirmation de l planification à l ensemble des responsables Les participants de la phase Cadrage sont-ils identifiés et disponibles? Communication Indisponibilité des acteurs Réunion et prise de connaissance du planning avec le personnel concerné Le pilote et les coordinateurs MOA sont-ils Compétences Mauvaise gestion du projet Etude de leur passé professionnel.

27 suffisamment expérimentés? -> retards Recommandations. Les calculs de budget et de délais sont-ils réalistes dans le contexte du projet? Planning / budget Sous estimation budget et planning Revoir le budget avant sa validation en fonction de la dernière version du cahier des charges et des spécifications. Les performances attendues sont-elles réalistes en regard de la solution envisagée? Adéquation offre demande Mauvais cadrage des besoins Etude approfondi des besoins et capacités de la solution avec les développeurs et architectes logiciels, et le client. Cadrage Les acteurs ont-ils les compétences et l expérience requises pour un Cadrage? Compétences Les acteurs ne sont pas compétant Etude de leurs antécédents. Les concepteurs ont-ils une bonne pratique de l identification des exigences? Compétences Mauvaise organisation conceptuelle Valider les propositions faites. L existant (organisation, éléments techniques, etc.) est-il répertorié? Moyens Matériel manquant ou doublon Un audit devra être effectué chez le client et au sein de l entreprise de développement afin de s assurer que tout est

28 bon de se coté là. Le volume des données à traiter est-il estimé? Sécurité des données Données trop importantes Les exigences sontelles clairement définies et validées? Validation demande Exigences non validées Réunion avant le lancement du projet avec le client pour valider les spécifications. La conception technique garantiet-elle l obtention des résultats escomptés? Validation Specs Conception inadéquate Validation de la solution par le client et le chef de projet. Les choix d environnement technique sont-ils compatibles avec le budget? Moyens / Budget Environnement technique trop cher -> dépassement du budget Une estimation précise des charges devra être réalisée. Les techniques et outils de développement prévus sont-ils maîtrisés? Compétences Matériel et technos non maitrisées -> retard Audit auprès de chaque développeur, formation éventuelle à prendre en compte dans le planning et dans le budget. Les choix fonctionnels sont-ils compatibles avec le budget et les délais? Validation specs planning et budget Budget & planning non optimisés par rapport aux nombre de spécifications

29 Conception L ergonomie du poste est-elle acceptée par les utilisateurs? Non validation Prototype / Ergonomie non optimisée Ergonomie non optimisée / adéquate Livraison d un prototype avant le développement final du projet, validation du prototype par le client et les utilisateurs finaux. La mise en place de l environnement technique est-elle compatible avec le planning? Phase non planifiée Non planification de la mise en place de l env. technique. Prendre en compte toutes les taches annexes lors de l élaboration du planning. Elargir le planning afin de ne pas être trop juste question délai. Développement L environnement de développement estil opérationnel? Environnement non opérationnel Retard planning Audit auprès de notre entreprise afin de vérifier si nous avons la technologie utile et si elle est opérationnelle. La compatibilité des versions de logiciels est-elle garantie? Incompatibilité matériel Retard planning augmentation des couts Etude préalable afin de vérifier la compatibilité des logiciels et technologies utilisées. L environnement de développement estil maîtrisé par les développeurs? Incompétence des développeurs Retard Audit auprès des développeurs et des participants au projet afin de définir s ils ont besoin d une formation ou s ils sont à l aise avec leur environnement de développement. La Construction se réalise-t-elle en Accumulation de problèmes Retard important Augmentation Effectuer l ensemble du projet en Validation

30 "validation permanente"? techniques budget permanente afin de suivre au mieux les évolutions du logiciel et éviter tout problème de compréhension des besoins. L évolution des fonctionnalités estelle évaluée? Modification de la demande Retard A prendre en compte dans l élaboration du planning, prendre quelques marges concernant l imprévu. La sécurité des données est-elle garantie en terme de reprises sur pannes, sauvegardes, interruption? Problème de sécurité Non intégrité et sécurité des données Assurer un module de gestion des données optimisé (serveurs doubles, sauvegardes etc...) Dev / Tests L avancement des tests est-il connu et satisfaisant? Retard planning / budget en hausse Mauvais planning de test / dépassement délai & budget Mise en place d un rapport interne des tests effectués. Les contraintes de délai n ont-elles pas entraîné d impasses sur les tests? Mauvaise Planification Tests non optimisés / Produit défectueux Les tests ne devront pas être négligés. Prévoir cette étape lors de l élaboration du planning. La documentation de réalisation estelle suffisante et intégrée au code? Qualité doc Non intégration de la doc codage La documentation devra être intégrée au code. Les défauts relevés Gestion des Erreurs en cascade Mise en place d un

31 en tests unitaires sont-ils corrigés en " validation permanente "? Tests rapport de tests reprenant les étapes, les teste effectués, leurs résultats et les éventuelles modifications apportées. La couverture des tests unitaires estelle jugée comme suffisante (MOE et MOA)? Qualité tests Risque de passer à coté d erreurs logiciels Chaque module devra être testé seul, et associé aux autre module lors des teste de validation. Les scénarios des tests d intégration ont-ils une couverture fonctionnelle complète? Qualité tests Risque d erreurs logicielles L ensemble des possibilités du logiciel devront être testé. Des scénarios seront mis en place afin d optimiser les tests. Finalisation Formation Le Plan de formation est-il compatible avec le planning du projet? Pas de prise en considération de la formation Retard, augmentation des coûts Le planning devra prendre en compte la phase de formation des utilisateurs finaux. Il en sera de même au niveau du budget. Les moyens de formation sont-ils disponibles (salle, matériels, supports)? Indisponibilité des locaux Retard, mauvaise formation Gérer cette contrainte lors du développement du projet afin d être certain des disponibilités lors de la livraison Le Manuel Utilisateur recense- Qualité doc Incompréhension Chaque erreur ou exception du logiciel

32 t-il les messages d erreur prévus? utilisateur des utilisateurs devront être consignées dans le manuel utilisateur. Juridique Sommes-nous en droit de manipuler les informations? Droits Poursuites Déclaration du système à la CNIL

33 7 Estimations des charges Pour l estimation des charges inhérentes au projet, nous avons procédé par méthode d évaluation analytique (méthode DELPHI). Le projet est divisé en plusieurs phases (voir 4) auxquelles ont affecte une charge notée en jour/homme. PHASE TITRE CHARGE EN J/H 1 Analyse 1 Réunion de présentation 1 2 DEFINITION DES BESOINS 5 Définition des besoins 2 Elaboration du cahier des spécifications 2 Livraison du cahier & Validation 1 3 CONCEPTION 7,5 Analyse de conception de la solution (architecturale et détaillée) 2 Définition de la charte graphique & ergonomie 0,5 Développement Prototype 4 Livraison Prototype & Validation 1 4 DEVELOPPEMENT 20 Module 1 : Module d identification & Tests 1 Module 2 : Module de gestion des besoins & Tests 1 Module 3 : Module de gestion des catégories & Tests 1 Module 4.1 : Module de planning & Tests 3 Module 4.2 : Module de Gestion des participants & Tests 1 Module 4.3 : Module d estimation des charges & Tests 2 Module 4.4 : Module de définition du Budget & Tests 2

34 Module 5 : Module de versionning des documents & Tests 2 Module 6 : Module de gestion des référentiels projets & Tests 1 Module 7 : Module de recherche par mots clès & Tests 2 Module 8 : Module de gestion des droits utilisateurs & Tests 1 Module 9 : Export 2 Validation de la solution 1 5 TESTS D'INTEGRATION 2 Tests d intégration internes 2 Validation des tests 0 6 TESTS DE RECETTE 4 Tests de recette 3 Correction des bugs 1 Validation 0 7 INSTALLATION 2 Configuration de l'environnement de production 1 Installation solution client et mise en production 1 Livraison client 0 PV de recette 0 8 FORMATION DES UTILISATEURS 4 Formation des utilisateurs Simples 2 Formation des super utilisateurs 1 Formation des administrateurs 1 TOTAL 45,5

35 8 Planning de réalisation 8.1 Diagramme de Gantt

36

37 9 Proposition financière Ressources Cout journaliers en Nombre de jours travaillés Prix de vente en MOA 600,00 1,0 600,00 Chef de projet 500,00 12, ,00 Développeur 1 380,00 19, ,00 Développeur 2 300,00 10, ,00 Développeur 3 300,00 9, ,00 Administrateur base de données 200,00 1,0 200,00 Ingénieur système 200,00 1,0 200,00 Formateur 500,00 4, ,00 TOTAL 2 980,00 58, ,00 Au final, la réalisation complète du projet se chiffre à ,00