MASTER,

MANAGEMENT DES SYSTEMS D’INFORMATION

Rapport management de projet

Sujet : la méthode en Cascade

( Waterfall model)

Encadrée par : PR AHAROUAY Soumaya

Réaliser par :
- CHEDDADI Mohamed-Yassine
- EL JABRI Zakariae
- HBYAJ Amine
 SOMMAIRE

1- Qu'est-ce qu'un modèle de développement en cascade ?

2- Description du modèle en cascade.

3- Critique du modèle en cascade.

4- Avantages et inconvénients du modèle en cascade.

5- Étape de discussion des exigences.

6- Comment fonctionne le modèle en Cascade ?

7- Alternatives au modèle en cascade.

8- La méthode de gestion de projet en cascade peut-elle correspondre à mon entreprise

9- Les méthodes en Cascade et Scrum : différences et impact sur les tests,

10- Etude de cas (gestion des cartes d’étudiantes cas de facultés des sciences Juridique,
Economique et sociales de Tétouan)
 La méthodologie dans sa forme traditionnelle ne laisse presque aucune place aux changements
inattendus. Si l'équipe de développement n'est pas trop nombreuse et que les projets sont prévisibles, alors
Waterfall peut en assurer la mise en œuvre dans un laps de temps donné.

Le modèle de développement en cascade existe depuis plus de quarante ans. Il a été décrit pour la première
fois en 1970 dans un article de W. Royce comme l’un des tout premiers modèles officiels du processus de
développement. Il a été décrit comme inefficace pour les grands projets de développement de logiciels, mais
personne n’a interdit son utilisation pour les petits. Près d'un demi-siècle après sa découverte, cette
technique est toujours d'actualité dans le monde des affaires moderne.
Nommé aussi un modèle obsolète et est traité avec un certain dédain en raison de l’obsolescence de la
méthode de gestion de projet traditionnelle.
Par contre Waterfall est une approche utile et prévisible, si les exigences sont fixes, bien documentée et
claire, si la technologie est claire et lorsque la mise en œuvre du projet ne prend pas beaucoup de temps.
Dans ce cas, un modèle en cascade du cycle de vie du logiciel peut fournir un résultat final plus prévisible
pour un budget, un calendrier et une quantité de travail spécifiques.

Nous présentons le modèle de développement en cascade, ces limites et avantages ainsi dans quelles
circonstances peut-on utiliser la méthode en cascade.
Finalement nous présentons un exemple concret de l’utilisation de cette méthode.

1- Qu'est-ce qu'un modèle de développement en cascade ?

Le principe de la méthode en cascade est simple. On découpe le projet en plusieurs phases. L’équipe
projet doit terminer une phase avant de pouvoir passer à la suivante. Ce qui fait sa différence avec d’autres
méthodologies, c’est qu’il n’est plus possible de revenir sur une phase lorsque celle-ci est terminée et bien
évidemment, validée par le client.

Le modèle Waterfall peut être décrit comme un développement linéaire et séquentiel d'un projet, dans lequel
les processus évoluent constamment des exigences de conception, puis à la mise en œuvre, aux tests et au
déploiement, suivis d'une maintenance continue. On pense que le modèle de cycle de vie en cascade a été
créé grâce à W. Royce, bien qu'il ait lui-même utilisé un modèle de développement itératif.
Lors de l’élaboration du modèle Waterfall, l’accent est mis sur la planification, le calendrier, les objectifs,
les budgets et, finalement, sur la mise en œuvre de l’ensemble du système en une seule entité. Les
principaux avantages ici sont une planification et une mise en œuvre simples en aval et en amont.

2- Description du modèle en cascade :

Par rapport à d’autres méthodologies, Waterfall se concentre davantage sur un ensemble d’étapes claires et
définies. Le modèle original était composé de cinq étapes. Il est souvent décrit comme un modèle linéaire-
séquentiel du cycle de vie. Cela signifie qu'il suit une structure de phase simple, où les résultats de chaque
phase vont au prochain niveau de développement. Les principales étapes sont :

 Collecte des exigences et création de documentation.

 Conception et conception du système.
 Mise en œuvre.
 Test et déploiement.
 Soutien
Les équipes doivent terminer l’étape complète avant de passer à la suivante. Si un élément n’est pas prêt à
une date donnée, il devient immédiatement perceptible. De plus, contrairement à Six Sigma ou à Scrum,
Waterfall n’a pas besoin de certification ni de formation spéciale pour les chefs de projet ou les employés.

3- Critique du modèle en cascade :

Le modèle en cascade du cycle de vie d'un système d'information a été critiqué en raison de son manque de
souplesse après l'achèvement de chaque étape et du retard pris par la capacité du client à fournir des
informations en retour. Cependant, cette méthodologie peut bien fonctionner dans de petits projets avec un
budget limité. Elle est souvent comparée à une méthodologie bien connue du cycle de vie d'un projet,
PRINCE2, créée par le gouvernement britannique. Cette méthodologie est toujours utilisée dans le secteur
public. L'une des principales différences entre PRINCE2 et le modèle de cycle de vie en cascade réside dans
le fait que ce dernier requiert une description écrite de toutes les exigences dès le départ, car il sera difficile
de les réexaminer ultérieurement. Avant que la création d’un code quelconque ne commence, ceux-ci
doivent être définis et fixés avec précision. C'est un avantage important du modèle de cycle de vie en
cascade.
 4- Avantages et inconvénients du modèle en cascade :

Avantages Inconvénients

Une structure simple grâce à des phases de Les projets complexes ou à plusieurs niveaux ne
projet clairement délimitées peuvent que rarement être divisés en phases de
projet clairement définies.

Une bonne documentation du processus de Une faible marge pour les ajustements du
développement par des étapes clairement déroulement du projet en raison d’exigences
définies. modifiées.

Les coûts et la charge de travail peuvent être L’utilisateur final est uniquement intégré dans le
estimés dès le début du projet. processus de production après la
programmation.

Les projets structurés d’après le modèle en Les erreurs sont parfois détectées uniquement à
cascade peuvent être représentés facilement sur la fin du processus de développement.
un axe temporel.

Le modèle en cascade est principalement utilisé dans les projets pour lesquels les besoins et les processus
peuvent être définis de façon précise dès la phase de planification et pour lesquels on peut supposer que les
hypothèses changeront peu tout au long du déroulement du projet

5- Étape de discussion des exigences :

Un autre avantage du modèle de cycle de vie en cascade est que les coûts peuvent être estimés avec un degré
de précision assez élevé, après avoir déterminé toutes les exigences. Si elle est appliquée, cela signifie qu'à
la première étape, tous les scénarios de test sont déjà décrits en détail dans la spécification fonctionnelle, ce
qui simplifie et simplifie le processus de test. Et aussi, même avant le début du développement logiciel, la
conception est élaborée en détail, ce qui rend les besoins et les résultats compréhensibles pour tous.

L'un des principaux avantages de l'utilisation de Waterfall est la recherche du produit final, ou du résultat
final, dès le début. Par conséquent, les équipes doivent éviter les déviations par rapport à l'objectif. Pour les
petits projets où les intentions sont suffisamment claires, cette étape permet à l'équipe de prendre conscience
dès le départ d'un objectif commun, ce qui réduit les risques de perte de détails au fur et à mesure de
l'avancement du projet. L’approche de Waterfall est très méthodique, elle souligne donc l’importance d’un
transfert d’information propre à chaque étape. Lors du développement de logiciels, de nouvelles personnes
apparaissent à chaque nouvelle étape. Il est donc important de s’efforcer de documenter les informations tout
au long du cycle de vie du projet.

6- Comment fonctionne le modèle en Cascade ?

On doit le développement du modèle en cascade classique à l’informaticien Winston Walker Royce. Royce
n’en est toutefois pas l’inventeur. En effet, son essai publié en 1970 sous le titre « Managing the
Development of Large Software Systems » présente plutôt une analyse critique des modèles linéaires. Royce
proposait comme alternative un modèle itératif et incrémental dans lequel chaque phase reposerait sur la
précédente et en vérifierait les résultats.

Il recommandait un modèle en sept phases qui se déroulaient en plusieurs étapes (itérations) :

1. Exigences système
2. Exigences logicielles
3. Analyse
4. Conception
5. Implémentation
6. Test
7. Exploitation

Le modèle de gestion que l’on appelle modèle en cascade est fondé sur les phases définies par Royce, mais
prévoit une seule itération.

Dans son essai, Royce n’évoque pas une seule fois le terme cascade (waterfall).

En pratique, plusieurs versions du modèle en cascade sont utilisées. Les modèles les plus courants divisent
les processus de développement en cinq phases. Les phases 1, 2 et 3 définies par Royce sont parfois
regroupées en une seule et même phase, qualifiée d’analyse des besoins.

1. Analyse : planification, analyse et spécification des besoins

2. Conception : conception et spécification du système
3. Implémentation : programmation et tests des modules
4. Test : intégration du système, tests du système et de l’intégration
5. Exploitation : livraison, maintenance, amélioration

Le schéma suivant illustre pourquoi le modèle de gestion linéaire est qualifié de « modèle en cascade ».
 Le modèle en cascade présenté schématiquement

Le modèle en cascade reposant sur les exigences de Winston Walter Royce divise les processus de
développement en cinq phases de projet, qui sont les suivantes : analyse, conception, implémentation, test et
exploitation. Le schéma présente déjà l’une des extensions du modèle recommandé par Royce : la
vérification des résultats de chaque phase en tenant compte des exigences et des spécifications élaborées au
préalable.

Des extensions du modèle en cascade simple viennent compléter le modèle de base avec des fonctions
itératives, par exemple avec des retours en arrière permettant de comparer les résultats de chaque phase avec
les hypothèses tirées de la phase précédente et ainsi de les vérifier.

Les phases du modèle en cascade,

Dans le modèle en cascade, les différentes phases d’un processus de développement s’enchaînent. Chaque
phase se termine par un résultat intermédiaire (étape), par exemple avec un catalogue d’exigences sous la
forme d’un cahier des charges, avec la spécification d’une architecture logicielle ou avec une application au
stade alpha ou bêta.

ANALYSE :

Chaque projet logiciel commence par une phase d’analyse comprenant une étude de faisabilité et une
définition des besoins. Les coûts, le rendement et la faisabilité du projet logiciel sont estimés lors de l’étude
de faisabilité. Celle-ci permet de créer un cahier des charges (une description grossière des besoins), un plan
de projet, une budgétisation du projet et, le cas échéant, un devis pour le client.

Les besoins sont ensuite définis de façon détaillée. Cette définition comprend une analyse réelle et un
concept cible. Alors que les analyses réelles décrivent les problèmes, le concept cible permet de définir
quelles fonctionnalités et quelles propriétés le produit logiciel doit offrir afin de répondre aux besoins. La
définition des besoins permet notamment d’obtenir un cahier des charges, une description détaillée de la
façon dont les exigences du projet doivent être remplies ainsi qu’un plan pour le test d’acceptation.
Enfin, la première phase du modèle en cascade prévoit une analyse de la définition des besoins, au cours de
laquelle les problèmes complexes sont décomposés en sous-tâches de moindre ampleur et des stratégies de
résolution correspondantes sont élaborées.

CONCEPTION :

La phase de conception sert à l’élaboration d’un concept de résolution concret sur la base des besoins, des
tâches et des stratégies déterminées au préalable. Au cours de cette phase, les développeurs élaborent
l’architecture logicielle ainsi qu’un plan de construction détaillé du logiciel et se concentrent ainsi sur les
éléments concrets tels que les interfaces, les frameworks ou les bibliothèques. Le résultat de la phase de
conception inclut un document de conception avec un plan de construction logicielle, ainsi que des plans de
test pour les différents éléments.
IMPLEMENTATION :

L’architecture logicielle élaborée pendant la phase de conception est réalisée lors de la phase
d’implémentation qui comprend la programmation du logiciel, la recherche d’erreurs et les tests de modules.
Lors de la phase d’implémentation, le projet de logiciel est transposé dans la langue de programmation
souhaitée. Les différents composants logiciels sont développés séparément, contrôlés dans le cadre de tests
de modules et intégrés étape par étape dans le produit global. Le résultat de la phase d’implémentation est un
produit logiciel qui sera testé pour la première fois en tant que produit global lors de la phase suivante (test
alpha).

TEST :

La phase de test comprend l’intégration du logiciel dans l’environnement cible souhaité. En règle générale,
les produits logiciels sont tout d’abord livrés à une sélection d’utilisateurs finaux sous la forme
d’une version bêta (bêta-tests). Il est alors déterminé si le logiciel répond aux besoins préalablement définis
à l’aide des tests d’acceptation développés lors de la phase d’analyse. Un produit logiciel ayant passé avec
succès les bêta-tests est prêt pour la mise à disposition.

Après avoir réussi la phase de tests, le logiciel est mis en production pour exploitation. La dernière phase du
modèle en cascade inclut la livraison, la maintenance et l’amélioration du logiciel.

Évaluation du modèle en cascade,

Le modèle en cascade offre une structure hiérarchique claire pour les projets de développement dans
laquelle les différentes phases du projet sont clairement délimitées. Étant donné que chaque phase se termine
par une étape, le processus de développement peut être suivi facilement. Le point fort du modèle se trouve
dans la documentation des étapes du processus. Les connaissances acquises sont consignées dans les
documents d’exigences et de conception.

En théorie, le modèle en cascade doit créer les conditions pour une réalisation rapide et peu coûteuse des
projets par une planification minutieusement élaborée au préalable. Toutefois, les avantages du modèle en
cascade sont sujets à controverse dans la pratique. D’une part, les phases du projet sont rarement délimitées
clairement dans le développement logiciel. Pour les projets logiciels complexes notamment, les
développeurs sont souvent confrontés au fait que les différents composants d’une application se trouvent
dans différentes phases de développement au même moment. D’autre part, le déroulement linéaire du
modèle en cascade ne correspond souvent pas aux conditions réelles.

Le modèle en cascade ne prévoit pas à proprement parler des adaptations en cours de projet. Un projet de
logiciel, dans lequel l’ensemble des détails du développement sont déjà définis au début du projet, peut
toutefois uniquement aboutir lorsque beaucoup de temps et d’argent ont été investis dès le départ dans
l’analyse et la conception. S’y ajoute le fait que les projets logiciels plus vastes s’étendent parfois sur
plusieurs années et sans un ajustement régulier aux développements actuels, ils fourniraient des
résultats déjà obsolètes lors de leur introduction.
 7- Alternatives au modèle en cascade.

En raison du déroulement strictement linéaire des phases de projet qui se suivent de façon
séquentielle, le modèle en cascade convient uniquement à de petits projets logiciels, si tant est qu’il
convienne à un quelconque projet. En revanche, les processus complexes et à plusieurs niveaux ne sauraient
être représentés avec ce modèle. C’est la raison pour laquelle différentes approches alternatives ont été
développées au fil du temps.

Alors que des modèles comme le modèle en spirale ou le modèle du cycle en V sont considérés comme des
améliorations du modèle en cascade classique, des concepts tels que l’« extreme programming », le
développement logiciel agile ou le prototypage itératif reposent sur une tout autre approche et permettent
généralement une adaptation flexible aux modifications actuelles et aux nouveaux besoins.

8- La méthode de gestion de projet en cascade peut-elle correspondre à mon entreprise ?

Les entreprises qui choisissent la méthodologie en cascade sont celles qui ont besoin d’une phase de
conception avant de passer à la phase de production. Si votre entreprise est dans ce cas, nous vous
recommandons de vous intéresser de près à la méthode en cascade. Bien que celle-ci ne soit pas la plus
flexible, elle reste très efficace pour mener de front des projets de conception et de réalisation.

Si par contre, votre entreprise est à la recherche d’un process plus souple, le plus judicieux sera de laisser de
côté cette approche traditionnelle et de plutôt miser sur une méthode Agile. En effet, les méthodes Agile
permettent le retour sur une phase précédente, même lorsque celle-ci était déjà validée par le client. En effet,
il arrive que certains clients se rendent compte d’un nouveau besoin en cours de projet. Si vous avez
remarqué que cela se produit régulièrement lorsque vous travaillez en mode projet, le plus pertinent sera de
privilégier une méthode Agile, réputée pour être plus flexible.

9-. Les méthodes en Cascade et Scrum : différences et impact sur les tests,

L'approche Scrum (littéralement : mêlée au

rugby) est tout à fait différente en ce sens où il ya
un ajustement continu du processus de
développement. Fidèle à sa nature agile, Scrum
comprend les exigences et l'interaction continue
entre les groupes autonomes créés selon les
compétences. Contrairement à l’approche en
Cascade, Scrum se développe par sprint au lieu
d'un processus continu, défini par Scrum
Alliance :

« Scrum est un ensemble de principes et de

pratiques simples mais incroyablement puissants
qui aident les équipes à livrer des produits en
cycles courts, ce qui permet une rétroaction rapide,
une amélioration continue et une adaptation
 Une introduction à SCRUM : rapide aux changements. Comme le premier cadre
de développement Agile, Scrum a principalement
été utilisé pour le développement de logiciels, mais
il se révèle également efficace pour le
développement dans d'autres secteurs aussi. »

Scrum se concentre sur la performance

individuelle de chaque développeur au lieu de la
fonctionnalité du processus de développement.
En mettant l'accent sur l'autonomie, la méthode
Scrum n'inclut pas souvent un chef d'équipe et le
développement reste flexible. Cette flexibilité est
très recherchée et, par conséquent, la méthode
Scrum a été adoptée par de grandes entreprises
bien connues dont Salesforce, Accenture,
Vendesk, AutoZone, Wells Fargo, Walmart et
Symantec (Source: Canvas Info Tech).

Il existe également de nombreux avantages pour la

méthode Scrum lors du développement.
Contrairement à la méthode en Cascade, Scrum ne
nécessite pas de planification significative et le
développement peut commencer très rapidement.
Avec Scrum, les exigences sont créées grâce à des
histoires d'utilisateurs qui contiennent des
descriptions des résultats escomptés liés aux critères
d'acceptation des utilisateurs et au comportement de
l'utilisateur. De plus, Scrum est beaucoup plus
flexible que l’approche en Cascade et est conçu pour
traiter l'ambiguïté confortablement. Avec Scrum, les
développeurs travaillent avec les storytellings
d'utilisateurs et ne reçoivent pas de tâches rigides.
De plus, les storytellings d'utilisateurs diminuent
l'impact que les scénarii imprévus peuvent avoir sur
le projet, car les développeurs peuvent facilement
pivoter et continuer vers leur objectif.
Force et faiblesses de l’approche SCRUM :

Les inconvénients de Scrum sont faciles à voir. Si

une équipe ne peut pas détecter les risques potentiels
lors de leur planification de sprint, si un testeur n'est
pas impliqué dans les processus de développement

Le test pour les deux méthodes :
dès le début, si une équipe manque de
communication ou de responsabilité, cela entraînera
inévitablement des problèmes. En ce qui concerne
ces problèmes, il n'y a pas de chef de projet pour
gérer l'équipe de développement. En outre, le
manque de planification peut entraîner des goulets
d'étranglement imprévus par rapport à la méthode en
Cascade. Les développeurs Scrum peuvent être plus
efficaces pour faire face aux goulots d'étranglement
que leurs homologues en Cascade, mais cette
flexibilité peut perdre son avantage s'il y a beaucoup
plus de défis à surmonter. (Source : 4xxi Blog)
En ce qui concerne les tests, les deux méthodes
reconnaissent l'importance que l'assurance qualité
peut avoir sur le produit fini. Dans l'approche en
Cascade, les tests d'acceptation des utilisateurs
(UAT) sont effectués après l'intégration. Les tests
QA mènent à un produit final fonctionnel sans bugs
majeurs. En Scrum, les tests et l'intégration se
produisent simultanément. Cela économise du temps
précieux si les développeurs essaient d'accélérer le
processus de développement. Cependant, les tests en
Scrum ont un challenge évident : il existe
considérablement plus d'erreurs critiques dans le
produit final. Avec la méthode en Cascade, vous
avez des tests d'acceptation d'un utilisateur à la fin
de la phase de développement. Avec Scrum, vous
pouvez planifier une phase UAT après chaque sprint
ou après un certain nombre de sprints, en fonction
de la complexité et de la longueur de chaque sprint.
Par conséquent, il est important d'allouer le temps de
test à l'avance selon le modèle de développement.
Indépendamment de la méthode, les tests
d’assurance qualité ont une partie essentielle de tout
développement de produit et ne doivent jamais être
négligés.
 10- Etude de cas : (gestion des cartes d’étudiantes cas de facultés des sciences Juridique,
Economique et sociales de Tétouan)

La digitalisation des différents services de la faculté devient une priorité depuis l’année universitaire
2018/2019, la transformation des cartes cartonnées en modèles RFID, l’une des taches primordiales et
constitue la base de plusieurs processus à savoir la gestion des absences dans la période des examens.

Le processus de préparation des cartes est départi en un certain nombre de taches. Plusieurs équipes étaient
intervenues afin de faciliter le travail, et aussi pour atteindre l’objectif, à savoir l’effectif de la faculté est de
plus de 20000 étudiants.

A quoi on a besoin pour produire une carte d’étudiant ? Les cartes RFID vierges accompagnés des
informations des étudiants (CIN, CNE, APOGEE, PHOTO).

Le processus ne peut être assez simple :

1- La numérotation des dossiers d’inscriptions avec leurs baccalauréats en même numéro pour éviter
la perte d’un document.
2- Scanne de la carte nationale et la photo de chaque étudiant.
3- Le traitement des photos : assurer un background transparent et l’enregistrer sous nom de leur
CIN.
4- La création d’une base de données qui contient les différentes informations des étudiants dont on
a besoin pour identifier les étudiants (Massar, apogée, nom, prénom, Cin, Elp) puis on réalise et
on fait une concaténation d’une photo avec la base de données partir de CIN.
5- L’impression des cartes.