Démarche d’un Projet

Informatique
Ecole des Hautes Etudes Commerciales
Master 1 : Tronc commun
2021 – 2022
Plan
Introduction
Les acteurs
Documents rédigés durant un projet informatique
Interaction
Les testes
Après délivrance ​
Méthode Agile
Scrum

Here is where your

presentation begins
Introduction
La démarche de projet informatique est
un ensemble d’activités et d’actions
coordonnées, qui mobilisent des
ressources dans un intervalle de temps
précis, afin de répondre à un besoin
clairement identifié.

Ce besoin est soit le développement d’un

nouveau logiciel ou l’installation d’une
solution SI
Introduction
Activité

Action
Id Besoin Coordonnée Résultat

Ressource

Temps
Introduction
Tout projet info passe par les même
grandes étapes,
S'appuyant sur un pilotage bicéphale,
guidé par deux acteurs principaux
: MOA (maitrise d’ouvrage) et MOE Évaluation

(maitrise d’œuvre). Réalisation

Conception/
specification

Définitions des
objectifs

Préparation/
analyse des
MOE MOA
besoins
Priorités
Pour piloter son projet informatique, le chef de projet assure le respect
des attentes sur différents plans :

Cout
Mars Délai
Jupiter Saturn
Qualité
Toute action entreprise La conduite du projet doit La garantie de la qualité
doit respecter le budget respecter les délais est permise par la
défini au lancement du annoncés au client, en vérification de la
projet.​ suivant des jalons conformité aux exigences
intermédiaires.​ convenues.
Les acteurs
Maître d’ouvrage MOA
Maître d’œuvre MOE
Complémentaires
MOA
Maître d’ouvrage
Définition de l'equipe MOA
Constitution de l'equipe MOA
Rôle de l'equipe MOA
Définition de la MOA
Elle est orientée vers les aspects
fonctionnels, la formalisation du besoin
et le suivi au cours du déroulement de
l'adéquation entre le réalisé et le désiré.​
Constitution de la
MOA
Cette équipe est constituée de:
• un chef de projet MOA (CPMOA)
• un assistant MOA (AMOA).​
Rôle de la MOA
● Représenter le client,
● Fournir le cahier de charges
fonctionnels, conjointement avec
l'équipe MOE,
● Veiller à la conformité du produit, en
faisant des tests de validation et en
s'appuyant sur l'aide du AMOA,
● Piloter le projet tout au long de sa
durée: ​
• Valider les sessions de développement,​
• Valider les sprints (Product Owner).
● participer aux sessions de test,
Rôle de la MOA
● Assure :
• La détermination des objectifs du projet.

• L'estimation du budget.

• La détermination du délai de livraison,.

• L'animation des différentes réunions.

• La validation des étapes de développement.

• La participation au recettage.​
MOE
Maître d’œuvre
Définition de l'equipe MOE
Constitution de l'equipe MOE
Rôle de l'equipe MOE
Définition de la MOE
L'équipe MOE est chargée de la
réalisation proprement dite.
Constitution de la
MOE
Constituée de:

Chef de projet CPMOE

Un assistant MOE (AMOE).
Rôle de la MOE
● Rendre compte de la qualité du produit livré.​ ​
● Manager les collaborateur pour respecter les spécifications
fonctionnelles du produit.​
● Manager auprès des techniciens, en même temps référent technique:
compétences techniques et qualité humaine​ ​
● Communiquer régulièrement avec la MOA pour le bon
déroulement du projet, en passant par AMOA.
Rôle de la MOE
● Assure :
• L'Assistance de la MOA (conception du cahier des charges et suivi technique).
• La Sélection des prestataires nécessaires.
• ​Le Management de l’équipe de développement.
• La Réalisation du produit.
• L'Assurance de la bonne qualité du produit.
• La Remise des comptes des avancements à la MOA.
• Le respect des délais et du budget.
Complémentaires

L’organisation entre MOA et MOE est donc la clé

d’un projet de développement réussi.

Il est essentiel que chacun des acteurs du projet

comprenne la spécificité de leur rôle et le
périmètre de compétence de chacun.

Par exemple, il n’est pas du devoir de la MOA

d’imposer une solution technique.
De la même façon, la MOE n’a pas à ajouter,
modifier ou annuler une fonctionnalité sans
consulter la MOA.
Documents rédigés durant un
projet informatique
Cahier des charges​
Spécifications Fonctionnelles Générales
Spécifications Fonctionnelles Détaillées
Spécifications Techniques Détaillées
 Cahier des charges​
Un cahier des charges est un document
créé pour décrire un projet informatique
de manière technique et exhaustive.​
Contenu du Cahier des charges

Le calcul des délais L'estimation des charges L'attribution des

de travail​ fonctions

La description générale Le type de

des besoins, des objectifs contractualisation pour
et des avantages​ lequel le client opte.​
Spécifications Fonctionnelles
Générales
Les spécifications fonctionnelles
générales « SFG » comprennent:​

• Les tâches prises en

charge par le logiciel.
• Les interactions de
l’application avec les
intervenants (utilisateurs
ou autre).
• Les règles et contraintes
des interactions avec les
intervenants .
Spécifications Fonctionnelles
Détaillées
Les spécifications fonctionnelles
détaillées « SFD » comprennent:​

• La description détaillée
de chaque fonctionnalité
décrite dans SFG,​
• la description de la
source d'information,​
• la description du
traitement concernant
chaque table de la BD.
• La description de la
structure des données,​
Spécifications Techniques
Détaillées
Les spécifications techniques détaillées
« SFD » contiennent:
• Le choix des technologies
à utiliser,​
• les bouts de codes à
utiliser.​
Interaction
Interaction entre les différents acteurs
Interaction entre les différents acteurs

Client : CPMOA :
désigne son expert métier. • rédige le cahier des charges.
• constitue l'équipe MOA.
• manage les AMOA.
Expert métier : • valide les SFG
Répond aux interrogations des AMOA. • Fait l'Intermédiaire entre l'expert
métier et l'AMOA.
AMOA : • Fait l'Intermédiaire entre l'équipe
• Rédige les SFG. MOA et MOE.
• Teste le recettage.
• Former les utilisateurs finaux.
Interaction entre les différents acteurs

CPMOE :
• Il constitue l'équipe MOE. AMOE :
• Il fait le point sur l'avancement de • Il rédige les SFD.
l'ingénieur du développement. • Il suit la rédaction des STD.
• Il interagit dans l'environnement • Il donne le "GO" pour installer
de développement et de l'application.
l'intégration. • Il apporte le support technique au
AMOA pendant le recettage.
• Il fait part de son avancement au
Intégrateur : CPMOE.
Il installe les différentes versions en • Il qualifie les anomalies et évolutions.
intégration.
Interaction entre les différents acteurs

Administrateur des Base Ingénieur de développement :

de Données : • Il rédige les normes de développement.
• Il informe l'AMOE de la volumétrie • Il élabore les STD à partir des SFD.
et du comportement des Bases en • Il apporte un support technique à AMOE.
environnement d'intégration. • Il développe les modules de chaque
• Il Maintient la base de données et fonctionnalité.
gère les accès. • Il fait les tests unitaires de chaque module
développé.
• Il qualifie et corrige les anomalies.
Les testes
Les Différents Tests
Les Différents Tests​
Tests Environnement Description

Tests unitaires Développement (par le Le développeur teste les fonctionnalités

développeur).​ au fur et à mesure du développement.

Tests d'intégration Intégration (par le Après la validation des tests unitaires, l'AMOE
AMOE).​ choisit un échantillon de données pour
chaque scenario et procède à faire les tests
d'intégration.
Tests fonctionnels Recette (par le AMOA).​ Assure le respects ou non des spécifications
décrites.

Tests de Intégration et recette Permettent de voir le comportement de

performance (par la AMOE et AMOA).​ l'application avec un volume de données
important.
Après délivrance
Gestion des anomalies​ ​
Gestion des évolutions
Gestion des anomalies​ ​
Suite aux tests de recette l'AMOA peut détecter une anomalie.

Lors de la découverte de l'anomalie, il crée une fiche d'anomalies sur un outil de gestion
d'anomalies et met son statut à "ouverte"
L'anomalie est ensuite envoyée à l'équipe MOE à travers son chef d'équipe qui, à son
tour, l'envoie à un AMOE pour la qualifier.

Nous distinguons deux situations:

• Le module ou fonctionnalité respecte toutes les règles définies dans les SFD, dans ce cas
l'AMOE met à jours le statut d'anomalies à "rejetée".

• Le module ou fonctionnalité ne respecte pas toutes les règles définies dans les SFD, dans
ce cas elle est réaffectée à l'ingénieur de développement.
Gestion des anomalies​ ​
Dans une anomalie, nous distinguons deux degrés de criticité:

• Anomalie Mineure : généralement elle survient suite au non-respect de la charte

graphique ou aux fautes d'orthographe.
• Anomalie majeure : soit elle est bloquante et donc pas moyen de la contourner, soit non
bloquante.

L'ingénieur du développement procède à la correction et met le statut de la fiche anomalie à

"En cours de correction".

Une fois corrigée, il met le statut de la fiche anomalie à "Corrigée" avec un commentaire
explicatif, en envoyant un mail à l'AMOE et son chef de projet.

À la fin, l'AMOA se charge de "Re-tester" ce correctif et une fois l'anomalie est entièrement
corrigée son statut devient "Fermée".
Gestion des anomalies​ ​

Pas
"Rejetée"
d'anomalie
Création fiche anomalie:
"Ouverte" Anomalie En cours de
Fermée
mineure correction
Anomalie
Anomalie En cours de
Fermée
majeure correction

• Bloquante​ Non
• Bloquante
Gestion des évolutions ​
Nous distinguons deux types d'évolution: mineure et majeure
• Mineure: en relation avec l'IHM ou d'une règle de gestion,
• Majeure: fait l'objet d'un nouveau projet qu'on appelle lot.

• Les évolutions viennent de la MOA, si elles viennent de la MOE, elles doivent

obligatoirement prévenir la MOE.
• Les évolutions surviennent lorsqu'une règle est oubliée dans les SFG et non SFD.

Remarque : Tout le monde est responsable de cette erreur puisque les SFG et
SFD ont été validées
Gestion des évolutions ​

Mise à jour de l'IHM ou

Mineure RG
Évolution
Majeure Un nouveau projet
Les grandes étapes
Les étapes d’un projet informatique​ ​
Les étapes d’un projet informatique
1. Expression des besoins et rédaction du cahier des charges : Avant de concevoir
un projet, il est nécessaire de s'assurer qu’il répond effectivement à un besoin. C'est
à dire qu'il a une fonction précise à remplir. La détermination de cette fonction est
indispensable. Le besoin, clairement défini, ainsi que les différentes caractéristiques
souhaitées pour le produit doivent être précisés dans le Cahier Des Charges.
2. Rédaction de la SFG : Après le déroulement et la validation des différentes
réunions entre l'expert métier et l'AMOA, l'AMOA rédige la SFG qui sera par la suite
validée par le CPMOA.
3. Rédaction des SFD : A l'issue de l'étape de la validation des SFG, l'AMOE procède à
l'écriture des SFD.
4. La rédaction des STD : se fait par le développeur en parallèle avec le plan test.
Les étapes d’un projet informatique
5. Rédaction des normes de développement et développement : Avant de commencer le
développement de l’application, il faut avoir en tête mais aussi sur papier les règles à
respecter pour optimiser les performances de l’application et pour améliorer la lisibilité du
code
6. Rédaction du plan test : se fait par l'AMOA en deux parties:
• Rédaction des RG et échantillon de données;
• La rédaction des résultats théoriques obtenus, et ensuite la rédaction des résultats
pratiques

7. Signature du Procès-verbal : Après avoir effectué tous les tests de recettes l’AMOA rédige
un procès-verbal de recette (PV Recette). Si la MOA constate qu’il y a eu un grand nombre
de turn-over dans l’équipe de la MOE, ils vont considérer que les nouvelles ressources qui
composent l’équipe de la MOE n’auront pas la capacité de maintenir les fonctionnalités
validées après les tests de recette s'ils décident de la livrer en production. Si les
conclusions sont positives et que les fonctionnalités testées peuvent être livrées en
production, alors le chef de projet MOA et le Client signeront le PV de recette. Cela signifie
que le client donne son accord pour livrer l'application.
Cycle en V
Introduction
Inconvénient du cycle en V
Cycle en V: Introduction

Méthode de gestion de Opposé aux méthodes Mise au point dans les

projet classique.​ Agiles.​ années 80.​

Implique toutes les V: la branche Chaque étape de

étapes de mise en œuvre descendante contient conception correspond à
d'un produit toutes les étapes de la une étape de test.​
informatique. réalisation et la branche
montante contient toutes
les étapes de tests.
Quant à la pointe,
elle représente
concrètement la
réalisation.​
 Introduction

Expression de besoins Recette

Spécifications Validation

Conception générale Tests d’intégration

Conception détaillée Tests unitaires

Détail Réalisation | Développement

Temps
Inconvénient du cycle en V
Le cycle en « V », est une « Structure décrivant les activités du cycle de développement
d’un projet informatique, depuis la spécification des exigences jusqu’à la
maintenance. Le modèle en V illustre comment les activités de test peuvent être
intégrées dans chaque phase du cycle de développement ».

Il est représenté par un V dont la branche descendante contient toutes les étapes de
la réalisation du projet, et la branche montante toutes les étapes de tests du logiciel,
la pointe du V, quant à elle, représente la réalisation concrète du logiciel, le codage :

Chaque étape de conception correspond une étape de test. Les tests peuvent
intervenir tout au long du processus de développement du logiciel.
Inconvénient du cycle en V
• Manque de communication : du fait que
chaque acteur joue son rôle séparément des
autres et la communication se fait à travers
des documents.
• Manque de souplesse : pour passer à
l’étape suivante, il est important de terminer
la précédente.
• Péremption du produit : la durée de ce
type de projet est potentiellement longue et
le résultat final peine souvent à s’adapter
aux évolutions du besoin.
• Manque de feedback : la méthode ne
prévoit pas de vérification intermédiaire,
donc si la documentation liée à la
conception du produit est imparfaite, le
produit final ne répondra pas aux besoins
du client.
Méthode Agile
Définition d'agile​ ​
4 valeurs fondamentales
Principe
Méthodes
Définition d'agile
Une méthode agile est une approche
itérative et incrémentale pour le
développement de logiciel, réalisé de
manière très collaborative par des
équipes responsabilisées appliquant un
cérémonial minimal qui produisent, dans
un délai contraint, un logiciel de grande
qualité répondant aux besoins
changeants des utilisateurs.
 4 valeurs fondamentales

L'équipe L'application
Une équipe soudée de Favoriser le coté
développeurs de applicatif
différents niveaux est
meilleure qu'une équipe
d'experts isolés.
L'acceptation
La collaboration du changement
Le client doit être La planification
impliqué dans le initiale permet
développement. l'évolution à
la demande du
client.
Principe
Ces quatre valeurs se déclinent en 12 principes généraux communs à toutes les méthodes
agiles :

1. La plus haute priorité est de satisfaire le client en livrant rapidement et régulièrement

des fonctionnalités à forte valeur ajoutée.
2. Le changement est accepté, même tardivement dans le développement, car les
processus agiles exploitent le changement comme avantage concurrentiel pour le
client.
3. La livraison s’applique à une application fonctionnelle, toutes les deux semaines à
deux mois, avec une préférence pour la période la plus courte.
4. Le client et les développeurs doivent collaborer régulièrement et de préférence
quotidiennement au projet.
5. Le projet doit impliquer des personnes motivées. Donnez-leur l'environnement et le
soutien dont elles ont besoin et faites leur confiance quant au respect des objectifs.
Principe
6. La méthode la plus efficace pour transmettre l'information est une conversation en
face à face.
7. L’unité de mesure de la progression du projet est un logiciel fonctionnel (ce qui exclut
de comptabiliser les fonctions non formellement achevées).
8. Les processus agiles promeuvent un rythme de développement soutenable (afin
d’éviter la non qualité découlant de la fatigue).
9. Les processus agiles recommandent une attention continue à l'excellence technique et
à la qualité de la conception.
10. La simplicité et l'art de minimiser les tâches parasites, sont appliqués comme principes
essentiels.
11. Les équipes s’autoorganisent afin de faire émerger les meilleures architectures,
spécifications et conceptions.
12. À intervalle régulier, l'équipe réfléchit aux moyens de devenir plus efficace, puis
accorde et ajuste son processus de travail en conséquence.
Agile : Méthodes
1. Scrum : (qui signifie mêlée au rugby) est
aujourd’hui la méthode agile la plus populaire.
2. Extreme Programming (XP) : L’objectif
principal de cette méthode est de réduire les
coûts du changement. Elle est souvent
pratiquée conjointement avec Scrum.
3. Rational Unified Process (RUP) : Elle est
considérée comme la moins agile des méthodes
présentées ici, c'est un mélange des pratiques
issues des méthodes traditionnelles et des
méthodes agiles. Le principe est de parcourir un
cycle de vie durant une itération. Chaque phase
du cycle de vie est très précisément détaillée.
Agile : Méthodes
4. Feature Driven Development (FDD) : Elle est
essentiellement axée sur le design et le
développement. Elle s’appuie sur une
formalisation du modèle objet à l’aide de
diagrammes UML, un découpage par fonctions
qui seront développés par des petites équipes
responsables d’une ou deux fonctions. Elle
accorde un aspect très important à la qualité du
produit fini, et s’aide d’outils pour suivre le
déroulement du projet.
Agile : Méthodes
5. Rapid Application Development (RAD) : C’est
la méthode agile la plus ancienne et celle qui a
été la première à être en rupture avec les
méthodes traditionnelles. Elle a introduit les
notions d’itération et d’incrément. Elle vise à
adopter la solution la plus stratégique (en
termes de délais), la moins risquée, la plus fiable
et la moins coûteuse, en respectant une durée
comprise entre 90 et 120 jours.
6. Dynamic systems development method
(DSDM) : Elle reprend les principes déjà vus
dans les autres méthodes (implication des
utilisateurs, autonomie de l’équipe, visibilité et
adéquation du résultat, développement itératif
et incrémental, réversibilité des modifications,
tests continus, coopération des acteurs).
Scrum
Scrum
Interaction entre les différents acteurs
Déroulement
Scrum
Scrum propose un ensemble réduit de
pratiques concentrées sur le
développement de l'adaptabilité par
l'apprentissage et l'auto-organisation.
Scrum détient les mêmes 12 principes du
concept agile​
Interaction entre les différents acteurs

Product owner :
• Il représente le client.
Scrum master :
• C'est l'Interlocuteur officiel du • Il est garant de l'application.
scrum master et de la team • Il est chargé de lever tous les
members. obstacles qui empêcheraient
• Il définit les besoins et rédige les l'avancement.
spécifications.
• Il priorise les user stories pour Team members :
chaque sprint. Personnes chargées de la réalisation
des sprint et du développement aux
tests.
Déroulement

Au lancement du projet, le product backlog est créé pour regrouper l’ensemble des Users
Stories décrites, ce product backlog évolue selon les désirs du client.

En suivant la méthode scrum, le projet progresse à travers des itérations qui s'appellent "les
sprints", durant 2 à 6 semaines.

Au lancement de chaque sprint, une réunion de planification est organisée, afin de

sélectionner les Users Stories qui seront réalisées durant le sprint, composant ce qu'on
appelle sprint backlog.
Déroulement
Lors du déroulement des sprint, une réunion quotidienne d'une quinzaine de minutes est
organisée avec l'intégralité de l'équipe. Elle permet aux membres de l’équipe de partager avec
les autres ce qu’ils ont fait la veille, ce sur quoi ils travaillent le jour même, ainsi que
l’identification de tout problème pouvant entraver le bon déroulement du sprint. Cette
réunion permet ainsi de synchroniser tous les membres de l’équipe.

Lors du daily scrum meeting chacun peut s’exprimer sur le fonctionnement de l’équipe,
mettre en avant ce qui va bien, ce qui va moins bien et proposer des axes
d’améliorations. L’équipe peut alors s’adapter, s’améliorer et augmenter sa productivité.

La fin d’un sprint est marquée par une session de débriefing qui permet de valider la
correspondance entre les besoins exprimés et les fonctionnalités réalisées. Un bilan est fait
également, lors du Sprint Review Meeting.

A la fin du dernier sprint, le produit final est remis au client.

.
Imput from Executives,
Team, Stakeholders, Daily scrum
Customers, Users
Meeting

Scrum master
Every
24 Hours

Team members Sprint Review

Product Owner 2–4
Week Sprint

Team selects Task Breakout

Renked list Starting at top as
of what much as it can
required commit to deliver Sprint and date
Sprint Backlog and team delivrable
by end of sprint
Finished Work
do not change

Sprint Planning
Product Backlog
meeting

Sprint
retrospective
Conclusion générale
Conclusion générale