Ex1

1) Les principaux facteurs de qualité d'un logiciel sont la conformité aux besoins, la
fiabilité, l'ergonomie (dont la facilité d'emploi), la flexibilité, la maintenabilité,
l'intégrité et la disponibilité.
2) Le modèle en cascade se base sur des exigences exprimées en début de projet.
Toutefois les exigences et besoins peuvent se montrer incomplets ou de qualité
insuffisante (ambiguïté, incohérence, etc.). De plus, le client peut ne pas être
pleinement conscient de ses exigences avant d'avoir vu le logiciel fonctionner. Ceci
peut conduire à revoir la conception, redévelopper une partie du logiciel, et retester le
produit et donc augmenter les coûts. C'est pourquoi le modèle en cascade est
particulièrement adapté à des projets dont les exigences sont bien comprises et
robustes réalisés avec une technologie bien maîtrisée.
3)

Les avantages du cycle en V

 Optimisation de la communication entre les parties prenantes grâce à des modalités et
des responsabilités clairement définies.
 Risques maîtrisés et meilleure planification grâce à des fonctions, des structures et des
résultats bien définis en amont.
 Amélioration de la qualité du produit grâce à l’intégration de mesures liées à
l’assurance qualité.
 Réduction des coûts grâce à un processus transparent de l’ensemble du cycle de vie du
produit.

Dans l’ensemble, ce modèle peut permettre d’éviter les malentendus ainsi que les tâches
inutiles. De plus, il permet de s’assurer que toutes les tâches soient exécutées en temps voulu,
dans le bon ordre en réduisant les temps morts au maximum.

Les inconvénients du cycle en V

Du point de vue des développeurs, cette démarche s’avère souvent trop simpliste, car elle ne
reflète pas intégralement le processus de développement. La gestion de projet occupe une
place de plus en plus importante. En outre, la rigidité relative de la structure ne permet guère
de réagir avec souplesse aux modifications en cours de développement et favorise donc un
déroulement relativement linéaire du projet. Pourtant, il est possible de pratiquer la méthode
agile avec le cycle en V, si le modèle a bien été compris et est correctement utilisé.

Les alternatives au cycle en V

Il existe différents types d’approches propres au secteur du développement de logiciels qui
peuvent convenir en fonction des projets et de la structure des équipes. Le choix des
approches est relativement large, même si le modèle en cascade ou le modèle en spirale sont
particulièrement répandus. Le modèle en cascade est particulièrement adapté aux projets de
petite envergure, à caractère linéaire, tandis que le modèle en spirale se prête plutôt à des
projets itératifs.
Voici ci-après les 6 constituants essentiels d'un cahier des charges.
L’exemple du cahier des charges traité dans cette section porte sur un projet informatique de
mise en place d’un nouveau système.  
Les 6 composantes sont :

 Contexte du projet
 Spécifications non fonctionnelles
 Spécifications fonctionnelles
 Ressources
 Délais
 Besoins financiers et budget

7)

CYCLE DE VIE FORCES FAIBLESSES QUAND UTILISER

·  Facile à comprendre et ·  Tous les besoins doivent ·  La phase de

à utiliser être bien spécifiés au spécification a été très
départ bien faite
·  Adapté pour une
équipe inexpérimentée ·  Donne une fausse ·  La définition du
impression de l’avancée produit est stable
·  Les limites de chaque des travaux
étape sont visibles ·  Il s’agit d’une nouvelle
·  Pas d’interaction entre version d’un produit
CASCADE ·  Facilite un les phases de existant
(WATERFALLS) management du projet développement
·  L’implantation d’un
·  La définition des ·  L’intégration n’a lieu qu’à produit existant sur une
besoins est non-évolutive la fin du cycle nouvelle plate-forme
·  La qualité prime sur le ·  Le client peut se ·  Une bonne maîtrise
coût retrouver non satisfait de la technologie
·  Pas de retour en arrière
d’une phase à l’autre

·  Facile à utiliser ·  Une mauvaise prise en ·  Les spécifications  de

compte des évènements besoins doivent être
·  Les tests sont effectués concurrents bien faites
à chaque étape
·  Le processus n’est pas ·  La solution à
·  Le contrôle se fait itératif développer et la
progressivement à technologie à utiliser
chaque étape ·  Une mauvaise prise en doivent être
EN V compte des changements parfaitement connues
·  Les phases de de la spécification des
validation sont prises en besoins ·  Les changements
main très tôt dans le doivent être faits avant
processus de ·  Ne contient pas les l’analyse
développement activités d’analyses de
risques ·  Excellent pour les
systèmes requérant une
grande sûreté

EN SPIRALE
·  Sans coût élevé, donne ·  Le temps consacré à ·  les coûts et
 des indications sur les l’évaluation des risques est l’évaluation des risques
risques majeurs trop élevé pour des petits est important
projets
·  Les fonctions critiques ·  pour des projets à
à haut risque sont ·  Le temps mis à planifier, risque au moins
développées en premier évaluer les risques, fixer les moyennement élevé
lieu objectifs, les prototypes
peut être excessif ·  pour des projets à
·  La conception ne doit long terme dont les
pas forcément être ·  Ce modèle est complexe financements peuvent
terminée varier
·  Une expertise en
·  Les utilisateurs finaux évaluation des risques est ·  les utilisateurs ne
sont intimement associés nécessaire définissent pas
à toutes les étapes du clairement leurs besoins
développement ·  La spirale peut être infinie
·  la spécification des
·  Le développement se ·  les développeurs besoins est complexe
fait en interaction avec travaillent par intermittence
les clients ·  il s’agit d’une nouvelle
·  il est difficile de définir les gamme de produits
·  L’évolution du coût de objectifs et les points de
développement est sous validation intermédiaires ·  des changements
contrôle entre les différentes étapes significatifs peuvent
intervenir à cause par
·  Les utilisateurs ont dès exemple de l’évolution
le départ une vue globale de la recherche ou de
du système l’exploration

·  Le client peut valider ·  Requière une bonne ·  Sur un projet utilisant

chaque étape du planification et une bonne de nouvelles
processus conception technologies
·  Utilise la méthode ·  Requière la définition ·  Sur des projets ayant
Diviser Pour Régner complète des une durée de
fonctionnalités du système développement assez
·  La délivrance du pour une définition des longue
produit est rapide différents incréments
·  Le besoin pour les
·  Le coût de lancement
·  Le coût total du développeurs de
du projet est moindredéveloppement du système connaître dès le départ
·  Un produit exploitable n’est pas négligeable les fonctionnalités
peut être délivré à tout majeures
PAR INCREMENT moment ·  Les différentes interfaces
doivent être bien définies ·  La plupart des
·  Les clients obtiennent fonctionnalités doivent
les fonctionnalités être connues au départ
majeures du système très mais certaines ne
tôt seront utilisées que plus
tard
·  Le risque du
changement des besoins ·  Les risques, le
est minimal financement, la
complexité du logiciel,
·  Développe les l’élaboration ou les
fonctions primordiales besoins pour les
dès le départ bénéfices maximum dès
le départ
8) La rédaction du cahier des charges fonctionnel découle de plusieurs autres processus qui
doivent être mis en oeuvre en amont.

1. L’étude d’opportunité

L’étude d’opportunité consiste à étudier le contexte du projet et à définir les principaux

besoins pour vérifier s’ils sont en phase avec les attentes de l’utilisateur. Elle permet d’évaluer
rapidement la viabilité du projet.

2. L’étude de faisabilité

L’étude de faisabilité vise à évaluer la viabilité du projet sur plusieurs plans, notamment :

 Économique ;

 Technique ;

 Organisationnel.

Elle permet d’estimer et d’anticiper les coûts, les délais et le ROI (retour sur investissement)
probable du projet. On y ajoute généralement des études de scénario afin de prévenir les
risques et menaces éventuels.

3. L’Analyse Fonctionnelle du Besoin (AFB)

L’analyse fonctionnelle vise à déterminer les « fonctions de service » du produit, en amont de

sa réalisation. Pour ce faire :

 Elle examine les points de vue des différentes parties concernées ;

 Elle se projette dans la durée, prenant en considération les différentes étapes du cycle
de vie : mise en place en amont, usage du produit, maintenance, entretien, fin de vie…

 Elle n’exprime pas les moyens à mettre en oeuvre, mais plutôt les résultats recherchés.

4. L’Expression Fonctionnelle du Besoin (EFB)

L’expression fonctionnelle du besoin exploite les résultats de l’AFB afin de :

 Structurer rigoureusement et logiquement l’information pour aider à la prise de

décision ;
  Permettre la création d’un produit performant et parfaitement adapté aux emplois et
aux services voulus ;

 Servir de référence du besoin du client durant la réalisation du produit ou service.

Elle se structure généralement en quatre grandes parties :

1. La définition globale du besoin ;

2. La consolidation des besoins et la définition des éléments stratégiques ;
3. La définition des principes et concepts retenus ;
4. La description des contraintes à respecter et des fonctions de service à assurer.
Exercice 2

Quels sont les différents risques rencontrés lors d’un projet ?

Afin d’identifier les risques inhérents à un projet, il faut se poser la question « Quels sont les
points faibles de mon projet » ? Globalement, il est possible d’identifier cinq grandes familles
de risques :

 Les risques propres à la gestion du projet

 Les risques juridiques
 Les risques concernant le respect du planning
 Les risques humains
 Les risques techniques