MANAGEMENT DE PROJET INFORMATIQUE : …s1.e-monsite.com/2009/01/31/23046688propal-projet-management-info... · MANAGEMENT DE PROJET INFORMATIQUE : PROPOSITION COMMERCIALE AKALYS®

MANAGEMENT DE PROJET INFORMATIQUE : PROPOSITION

COMMERCIALE AKALYS® Proposition commerciale

Proposition commerciale sur le

développement d’un outil intranet de gestion de projet.

2009

ASSY – BIANCHERI – MARTIN - SAVARY AKALYS®

07/01/2009

[MANAGEMENT DE PROJET INFORMATIQUE : PROPOSITION

COMMERCIALE AKALYS®] 7 janvier 2009

AKALYS® | ASSY – BIANCHERI – MARTIN – SAVARY

AKALYS® 2009

Sommaire

Sommaire ........................................................................................................................................... 2

1 Les atouts de la proposition ........................................................................................................ 5

2 Introduction ................................................................................................................................ 6

2.1 L’appel d’offre ..................................................................................................................... 6

2.2 L’organisation du projet....................................................................................................... 6

2.2.1 Processus ..................................................................................................................... 6

2.2.2 Organisation structurelle ............................................................................................. 7

2.2.3 Technologies utilisées .................................................................................................. 9

3 La solution proposée ................................................................................................................... 9

3.1 Description formelle ............................................................................................................ 9

3.1.1 Authentification / autorisation par LDAP .................................................................... 10

3.1.2 Gestion des projets .................................................................................................... 12

3.1.3 Gestion des besoins ................................................................................................... 12

3.1.4 Gestion optimisée des projets .................................................................................... 13

3.1.5 Gestion d’une version ................................................................................................ 13

3.1.6 Gestion des catégories ............................................................................................... 14

3.1.7 Gestion des versions de référentiel projet .................................................................. 14

3.1.8 Rechercher (mot clé).................................................................................................. 15

3.1.9 Gestion des droits ...................................................................................................... 15

3.2 Architecture technique & web ........................................................................................... 16

4 Démarche de développement ................................................................................................... 17

4.1 Les différentes phases du projet ........................................................................................ 17

4.2 Les activités par phase: ...................................................................................................... 17

4.2.1 Phase 1 : Analyse des besoins et de la faisabilité. ....................................................... 17




AKALYS® 2009

4.2.2 Phase 2 : Spécification. .............................................................................................. 18

4.2.3 Phase 3 : Conception architecturale. .......................................................................... 18

4.2.4 Phase 4 : Conception détaillée. .................................................................................. 19

4.2.5 Phase 5 : Codage. ....................................................................................................... 19

4.2.6 Phase 6 : Tests unitaires. ............................................................................................ 20

4.2.7 Phase 7 : Tests d'intégration. ..................................................................................... 20

4.2.8 Phase 8 : tests de validation. ...................................................................................... 20

4.2.9 Phase 9 : Recette ....................................................................................................... 21

4.3 Les intervenants ................................................................................................................ 21

5 Documentation ......................................................................................................................... 22

5.1 Documentation Interne ..................................................................................................... 22

5.1.1 Etat d'avancement du projet ...................................................................................... 22

5.1.2 La liste des tâches ...................................................................................................... 22

5.1.3 Comptes-rendus de réunions ..................................................................................... 22

5.2 Documents de test ............................................................................................................ 22

5.2.1 Plan de test ................................................................................................................ 22

5.2.2 Validation de test ....................................................................................................... 22

5.2.3 Cahier de recette ....................................................................................................... 22

5.3 Documentation Externe ..................................................................................................... 23

5.3.1 Manuel d'utilisation ................................................................................................... 23

5.3.2 Manuel de maintenance ............................................................................................ 23

5.3.3 Manuel de sécurité .................................................................................................... 23

5.3.4 Charte Informatique .................................................................................................. 23

5.3.5 Manuel Développeur ................................................................................................. 23




AKALYS® 2009

6 Gestion des risques ................................................................................................................... 24

6.1 Process de gestion des risques........................................................................................... 24

6.2 Risques identifiés............................................................................................................... 24

7 Estimations des charges ............................................................................................................ 33

8 Planning de réalisation .............................................................................................................. 35

8.1 Diagramme de Gantt ......................................................................................................... 35

9 Proposition financière ............................................................................................................... 37




AKALYS® 2009

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.




AKALYS® 2009

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

2.2.1 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.




AKALYS® 2009

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.




AKALYS® 2009

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).




AKALYS® 2009

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).

2.2.3 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




AKALYS® 2009

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...)

3.1.1 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




AKALYS® 2009

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.




AKALYS® 2009

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.

3.1.3 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




AKALYS® 2009

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.

3.1.4 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.

3.1.5 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




AKALYS® 2009

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.

3.1.6 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.

3.1.7 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.




AKALYS® 2009

- 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.

3.1.8 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.

3.1.9 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.




AKALYS® 2009

- 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à.




AKALYS® 2009

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:

4.2.1 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.




AKALYS® 2009

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.

4.2.3 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.




AKALYS® 2009

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.

4.2.5 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.




AKALYS® 2009

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.

4.2.7 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.

4.2.8 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.




AKALYS® 2009

- 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.

4.2.9 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.




AKALYS® 2009

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.

5.1.1 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.

5.1.2 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.

5.1.3 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

5.2.1 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.

5.2.2 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.

5.2.3 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.




AKALYS® 2009

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.

5.3.1 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.

5.3.2 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.

5.3.3 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.

5.3.4 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.

5.3.5 Manuel Développeur

Ce document représentera une description du codage de l’application et une aide en cas d’erreur

ou de bug.




AKALYS® 2009

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 Secteur(s) de risque

Financiers Développement

exploitation

Technologiques émergence

obsolescence

matériel

étude de l'existant

Contraintes délais / planning

budget

visibilité

Adéquation offre / demande

Ressources nombre

compétences

motivation

Méthode par phases / lots

Qualité Fonctionnelle adéquation

couverture

évolution

Prise en charge budget / délai

Qualité Technique Compétences

interruption




AKALYS® 2009

reprises sur pannes

sauvegardes

sécurité

Qualité Documentation Codage

fonctionnalités

limites

interfaces

manuels utilisateurs

Qualité Tests ressources

suivi

impact

validation permanente

Qualité Formation intégration au planning / budget

Déploiement Compatibilités

ressources matérielles

Evolution organisationnelle

Fiabilité de l’exploitation

Sécurité des données Qualité

Sauvegardes et backups

Juridique 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.




AKALYS® 2009

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.




AKALYS® 2009

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




AKALYS® 2009

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 sont-

elles 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 garantie-

t-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




AKALYS® 2009

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 est-

il 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 est-

il 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




AKALYS® 2009

"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 est-

elle é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 est-

elle 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




AKALYS® 2009

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 est-

elle 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




AKALYS® 2009

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




AKALYS® 2009

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




AKALYS® 2009

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




AKALYS® 2009

8 Planning de réalisation

8.1 Diagramme de Gantt




AKALYS® 2009




AKALYS® 2009

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,5 6 250,00 €

Développeur 1 380,00 € 19,5 7 410,00 €

Développeur 2 300,00 € 10,0 3 000,00 €

Développeur 3 300,00 € 9,0 2 700,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,0 2 000,00 €

TOTAL 2 980,00 € 58,0 22 360,00 €

Au final, la réalisation complète du projet se chiffre à 22 360,00 €