Chapitre 2

Description des différentes

phases du cycle de vie du logiciel
 Description des phases

• Analyse
– étude de marché
– étude de faisabilité
– identification des besoins
– modélisation
– prototypage
– rédaction des spécifications
– validation des spécifications
• Conception (design)
– de données
– d’architecture
d’interfaces
– de fonctions
 Description des phases (suite)
• Programmation (codage)
– traduction de la conception du logiciel dans un
langage de programmation
• Tests
– unitaires
– d’intégration
– de système
• fonctionnels et de performance
 Description des phases (suite)

• Intégration (mise en production)

– intégration du logiciel dans son environnement
réel (autres logiciels, autres systèmes)
• Maintenance
– corrective
– évolutive
– préventive ( ré-ingénierie du logiciel)
Principales méthodes de développement

de logiciels
• Méthode structurée (fonctionnelle)
– Centrée fonctions
• Méthode orientée objet
– Centrée objets
 Caractéristiques des méthodes de
développement
• Méthode structurée (fonctionnelle)
– Au centre du modèle de développement se trouvent
les
fonctions
• Avantages:
– Simplicit
é
– Réutilisat
ion du
code
• Domaines
d’applicati
on:
– Applications scientifiques, systèmes temps réel,
 Caractéristiques des méthodes de
développement (suite)
• Méthode orientée objet
– Au centre du modèle de développement se trouvent
les
objets
• Un objet informatique est une abstraction d'un objet
du monde réel
– L’abstraction réduit la complexité en mettant l'accent sur les
caractéristiques importantes de l’objet
– Les objets qui ont exactement les mêmes propriétés et le même
comportement sont regroupés dans des classes.
• Avantages:
– Représentation plus proche du monde réel, qui est
formé d’objets
– Réutilisation du code et de données (au moyen de
bibliothèques de classes réutilisables)
 Première phase de développement:
Analyse
• Dans le cadre du cycle de développement d’un
logiciel, l’analyse sert à bien
comprendre et représenter:
• L’information sur le domaine du problème à
résoudre (l’environnement du logiciel)
• Les fonctions que le logiciel devrait accomplir
• Le comportement du logiciel en
présence d’événements externes
 Principes de l’analyse
1. Raffinement successif :
• Les modèles de l’analyse doivent être
continuellement raffinés (il faut réaliser plusieurs
itérations, de plus en plus détaillées)
2. Abstraction :
• Le processus d’analyse doit se concentrer sur les
informations essentielles caractérisant le problème
à résoudre
3. Décomposition (« diviser pour régner »)
• Le problème doit être divisé en plusieurs sous-
problèmes, plus faciles à analyser et
développer
 Étapes de l’analyse
• Analyse préliminaire
– Étude d’opportunité du logiciel sur le marché
– Étude de faisabilité du logiciel
• Analyse des besoins
– Travailler avec le client et les utilisateurs pour
définir les besoins (requis) fonctionnels et de
performance du logiciel, sans donner aucun détail
de structure interne du logiciel (définition type
boîte noire)
 Étapes de l’analyse (suite)
• Analyse
– Description du problème
• Définir les données que le logiciel devrait utiliser
• Définir les fonctions principales du logiciel
• Définir le comportement du logiciel par rapport aux
événements externes
• Identifier les contraintes de design (temporelles, de taille,
etc.)
– Synthèse d’éléments de solution
• Proposer une architecture d’implantation (exemple:
architecture client-serveur)
 Étapes de l’analyse (suite)
– Modélisation du logiciel
• Modèle de données
• Modèle de fonctions
• Modèle de comportement
– Prototypage des aspects incertains
– Rédaction du document d’analyse (spécifications)
qui guidera le design
– Validation du document d’analyse dans le cadre
d’une Revue Technique Formelle (RTF)
• Vérifier si le document d’analyse est correct, complet
et
consistant
 Revue technique formelle
d’analyse
• C’est un filtre de qualité
– Peut avoir une efficacité plus grande que les tests
• Objectif:
– Valider le résultat de l’étape d’analyse (les
spécifications)
• Règles:
– Protagonistes: analyste(s), concepteur, gestionnaire de
projet, client, membres du groupe d’assurance qualité
– Les participants doivent assister à toute la réunion
– Tous les participants sont égaux
 Revue technique formelle de
l’analyse (suite)
• Règles (suite):
– La préparation est aussi importante que la réunion
– Établir un ordre du jour et le maintenir (médiateur)
– Éviter de sombrer dans des détails techniques
• Les éventuelles erreurs détectées durant la réunion
doivent être consignées dans un rapport
• L’analyste se charge d’opérer les modifications
nécessaires dans les spécifications, après la
réunion.
 Analyse préliminaire
• Analyse d’opportunité sur le marché
– Suite à l’analyse d’opportunité, le projet pourrait être
accepté ou rejeté
– Cette analyse est réalisée par une équipe
(client, analyste, gestionnaire de projet,
spécialistes en marketing)
• Analyse du système actuel ou de la situation
actuelle
• Description du système proposé
• Analyse du système proposé
– Analyse de faisabilité
 Analyse préliminaire (suite)
• Analyse de faisabilité
– Suite à l’analyse de faisabilité, le projet pourrait être
accepté ou rejeté
– L’analyse de faisabilité est réalisée par une équipe
pluridisciplinaire (analyste, gestionnaire de projet,
gestionnaires fonctionnels, client, utilisateurs
courants ou potentiels)
 Analyse de faisabilité du logiciel

• L’analyse de faisabilité fait l’objet « d’un document,

premier livrable d’un projet, contenant une analyse
de la valeur qui sera créée par le projet: coûts,
bénéfices, faisabilité, alternatives, recommandations »
• Ce document fournit à la haute direction et au client
les informations nécessaires pour prendre une
décision correcte concernant le démarrage du projet:
– Suite à l’analyse de faisabilité, le projet pourrait
être accepté ou rejeté
 Analyse de faisabilité du logiciel (suite)

• Il n’y a pas de format standard pour ce document.

• Il doit contenir:
– Les coûts et les bénéfices associés au projet (des
estimations initiales, basée sur l’expérience des
gestionnaires de projet)
– Plusieurs alternatives possibles :
• Développer un tout nouveau logiciel
• Acheter un logiciel existant
• Acheter un logiciel existant et l’adapter aux besoins
des utilisateurs
• Modifier le logiciel actuel
• Modifier la manière d’utiliser le logiciel actuel
Analyse de faisabilité du logiciel (suite)
– Une comparaison de rentabilité (bénéfices) des
alternatives possibles
– Étude de la faisabilité, sous plusieurs volets:
• Faisabilité économique (financière)
• Faisabilité technique
• Faisabilité temporelle
• Faisabilité organisationnelle
– Recommandations aux décideurs :
• Une des alternatives sera sélectionnée et proposée au
client
 Exemple d’analyse de faisabilité
• Projet: Logiciel de contrôle du système d’alarme
d’une station de service
• Organisation: BdeBExperts
• Client: Essence 2020
• Point de départ: La description informelle du
système d’alarme
Description du système d’alarme
Afin de respecter les normes environnementales sur la
contamination des sols, les stations de service doivent se doter
de systèmes automatiques capables de détecter et signaler les
fuites et les débordements de carburant ainsi que les risques
d’explosion.
Un tel système comporte une console de commande localisée
à l’intérieur de la station et des capteurs de température,
niveau et pression installés à chaque réservoir de carburant.
La console de commande est munie d’une alarme, d’un
clavier et d’un écran.
Les problèmes pouvant survenir à la station de service
sont nombreux : débordements, fuites, explosions.
 Schéma structurel du système
d’alarme réel
Réservoir 1 Réservoir N
Capteur C ap te ur Capteur
… Capteur C ap teu r Capteur
tem p ératu re niveau tem p éra tu re niveau
p ression p ressio n

Système d’alarme

Contrôleur des réservoirs (Logiciel)

Alarme Clavier Écran

Console
 Fuites
Les fuites sont dues à la corrosion et au vieillissement des
réservoirs. Un réservoir qui fuit doit être remplacé. On considère
qu’un réservoir fuit lorsque le volume de carburant dans le
réservoir baisse lentement et uniformément pendant des heures.

La fuite doit être signalée aux autorités compétentes dans un

délai de 24 heures et les opérateurs doivent s’assurer que la
procédure de fermeture soit bien suivie.

En cas de fuite, l’alarme doit s’activer à l’intérieur d’une

minute.
 Débordements
Le débordement est dû à la négligence humaine lors du remplissage
d’un réservoir. Les débordements se produisent souvent lorsqu’un
camion citerne remplit un réservoir souterrain et le système doit être
en mesure de réagir promptement afin de prévenir ces débordements.

L’opérateur doit être averti d’un débordement à l’intérieur de 10

secondes.

L’alarme doit s’activer lorsque le niveau d’un réservoir approche la

limite de 90% de la hauteur du réservoir, tandis que le niveau monte
toujours.
 Risques d’explosion
L’explosion est un événement assez rare, mais très dangereux. Il est
dû à la montée rapide de la pression dans un réservoir, au delà d’une
valeur de danger.
En cas d’explosion, l’alarme doit s’activer à l’intérieur de 2
secondes.

En tout temps, le système vérifie si tous les capteurs

fonctionnent correctement.

Dans le cas où le système détecte un événement critique (fuite,

débordement ou risque d’explosion), il doit afficher des messages
d'avertissement par dessus tout autre message.
 Description du système d’alarme (suite)
Le système doit surveiller 4 réservoirs souterrains de
carburant en analysant les données provenant périodiquement
des thermomètres (capteurs de température), des flotteurs de
niveau (capteurs de niveau) et des capteurs de pression.

Le système doit enregistrer tous les événements critiques

dans une base de données.

En tout temps, le préposé peut demander l’affichage des

données (températures, niveaux, pressions) ou l’affichage de
rapports, contenant, pour chaque événement, la date et l’heure,
la nature (fuite, débordement, explosion) et le numéro du
réservoir.
 Exemple d’analyse de faisabilité
1. Motivation :
La station de service Essence 2020 ne possède pas de
système d’alarme pour garantir la sécurité de la station.
Les débordements et fuites de carburant sont croissants et la
protection contre le risque d’explosion, même s’il est faible, ne
doit pas être negligée.

De plus, l’opérateur ne dispose pas de moyens fiables pour

connaître l’état des réservoirs en temps réel, ni d’historique
sur les événements critiques passés.
 Exemple (suite)
• Ainsi, Essence 2020 souhaite se doter d’un système
d’alarme dans le but :
– de réduire le temps de détection de tout événement
critique (fuite, débordement, explosion, panne)
– d’augmenter la fiabilité et la sécurité des réservoirs
– de contrôler en temps réel l’état des réservoirs
– de mémoriser les événements critiques détectés
– de produire des rapports à la demande contenant les
détails des événements critiques, à savoir:
• la date et l’heure, la nature de l’événement (fuite, débordement,
explosion) et le numéro du réservoir.
 Exemple (suite)
2. Évaluation de la faisabilité:
Nous étudierons la faisabilité selon quatre
perspectives :
1) organisationnelle
2) technique
3) financière
4) temporelle
 Exemple (suite)
2. 1. Faisabilité organisationnelle:
L’organisation d’Essence 2020 favorable
est l’implantation du nouveau à d’alarme,
n’impliquera aucune mise à pied.
système qui

Le personnel d’Essence 2020 devra suivre une formation

spéciale sur les procédures à effectuer en cas d’incident.

L’ensemble du personnel est prêt à suivre des stages de

sensibilisation dans la mesure où le nouveau système
d’alarme permettra d’accroître grandement la sécurité du
personnel.
 Exemple (suite)
2.2. Faisabilité technique:
• Deux alternatives sont proposées:
– Alternative 1: Développer un nouveau système
– Alternative 2: Acheter un système existant et
l’adapter aux besoins du client
 Alternative 1: Développer un nouveau
système matériel - logiciel
• La mise en place d’un tel système requiert
l’utilisation de matériel fiable et résistant:
• Pour la sonde de niveau nous utilisons un capteur dit à
« flotteur », qui fonctionne de la manière suivante : le
flotteur se maintient à la surface du liquide. Il est solidaire
d'un capteur de position qui délivre un signal électrique
correspondant au niveau.
• La mesure de la pression se fera à l’aide d’un
transmetteur de pression.
• Pour la mesure de la température, nous utilisons des
résistances détectrices de température (RTD) qui ont la
particularité de fonctionner avec des plages de température
très élevées (-50°C à +200°C) et possèdent un seuil de
tolérance très bas.
 Alternative 1 (suite)
• Les capteurs seront reliés à un serveur principal qui
traitera les données. Parallèlement ces données seront
sauvegardées sur un second serveur dans lequel sera
stocké l’historique des mesures. De plus cette machine
pourra également servir de serveur de secours en cas de
panne du serveur principal.
• Le système sera relié directement au service de police et
’d incendie par l’ intermédiaire d ’ une ligne de
communication dédiée.
 Alternative 1 (suite)
• Notre organisation dispose de ressources humaines
compétentes qui pourront mener à terme ce projet.
• Le pompiste devra recevoir une formation sur
l’utilisation du système. Cette formation aura pour
but de lui permettre d’interpréter les mesures et de
déclencher une alerte en cas de fuite, de
débordement ou d’incendie.
• Un manuel contenant toutes les procédures
d’urgence et l’explication de chaque mesure sera
également fourni.
 Alternative 2: Acheter un système existant
et l’adapter aux besoins du client

• Le système FDEDetect est disponible sur le marché.

– Prix:
• 64 000 $.
– Temps nécessaire pour l’adaptation:
• 10 jours/homme.
– Coût estimé pour l’adaptation:
• 3 360 $
– Coût estimé pour l’adaptation plus profits:
• 3 360 * 1.15 = 3 864$
 Exemple (suite)
2.3. Faisabilité financière:
Le gouvernement ayant rendu obligatoire la mise
d’un système d’alarme aux nouvelles normes des
stations services, la compagnie pétrolière a signé
un accord avec les stations qui sont sous sa
franchise pour prendre en charge une partie des
coûts.
Alternative 1: Développer un nouveau
système
L’investissement initial (I0) estimé est d’environ
42 715$ (voir détails coûts matériel et
main d’œuvre sur les acétates suivants).
– On estime des coûts récurrents annuels dus
à la maintenance d’environ 3 000 $
– On estime des économies annuelles (revenus) d’environ
17 000 $ sur une période de 5 ans
– Le taux de rendement minimal requis par la
haute direction est de 15%.
 Coût du matériel nécessaire
Produit Coût Quantité Coût
unitaire
total
Capteur de pression 700 $ 4 2800 $
Capteur de niveau 1200 $ 4 4800 $
Capteur de température 700 $ 4 2800 $
Serveur informatique 1600 $ 2 3200 $
Moniteur 400 $ 2 800 $
Ensemble clavier et souris 70 $ 2 140 $
Imprimante 200 $ 1 200 $
Liaison avec les services de police 700 $
et d’incendie 700 $ 1

Câblage divers 1200 $ 1 1200 $

Fournitures diverses 200 $ 1 200 $
 Coût de la main d’œuvre (MDO)
Prestation Coût/heure Temp Coût total
s
requis
Analyse du système 43 $ 4 semaines 6 000 $
Design et codage 43 $ 8 semaines 12 000 $
Tests 43 $ 1 semaine 1 500 $
Installation des capteurs 43 $ 1 semaine 1 500 $
Installation de
43 $ 1 semaine 1 500 $
l’informatique
Coûts plus profits
22 * 1.15 =
500$
25875$ 39
 Analyse de rentabilité
• Alternative 1: Développer un nouveau système
• Délai de récupération de l’investissement
initial: DR = I0 / (Revenus - Dépenses) =
= 42 715 / (17 000 – 3 000) = 3.05 ans
• Valeur actuelle nette du projet (VAN):
– I0 = 42 715$ (investissement initial)
– Ft = Revenust – Dépensest = 17 000 – 3 000 = 14 000$ (où
Ft est le flux monétaire annuel)
VAN = -42 715 + 14 000 * (1.155 -1)/0.15 /1.155 = 4 215 $

40
 Calcul de la rentabilité financière d’un
projet individuel
Valeur actuelle nette: n
Ft
VAN  I 0   1 t
où I 0 = investissement initial, t
 
1
k
Ft = flux de trésorerie net pour la période t,
k = taux de rendement minimal requis par la haute direction (TRAM)
• Si tous les Ft=A (une annuité),

VAN = I 0  A (1+ k ) - 1n 
n

 k(1+k ) 
• Respecter le signe des flux monétaires!
Un projet est rentable si sa VAN est positive. Tous les projets qui satisfont à ce
critère sont donc jugés acceptables financièrement.
 Analyse de rentabilité (suite)
• Alternative 2: Acheter un système existant
et l’adapter aux besoins du client
• Délai de récupération de l’investissement
initial: DR = I0 / (Revenus - Dépenses) =
= 67 864 / (17 000 – 3 000) = 4.85 ans
• Valeur actuelle nette du projet (VAN):
– I0 = 67 864 $ (investissement initial)
– Ft = Revenust – Dépensest = 17 000 – 3
000 = 14 000$
– VAN = -67 864 + 14 000 * (1.155
-1)/0.15 /1.155 = -20 934 $
 Analyse de rentabilité (suite)
• Conclusion:
– L’alternative 1: Développer un nouveau système s’avère
plus rentable que l’alternative 2: Acheter un système
existant et l’adapter aux besoins des clients:
• Délai de récupération plus court
• Valeur actuelle nette du projet positive
 Exemple (suite)
2.4. Faisabilité temporelle
Le développement et le déploiement du système
doivent se faire le plus rapidement possible afin
que la station service soit aux normes le plus tôt.

• Alternative 1: Développer un nouveau système:

• Temps nécessaire: 85 jours/homme (voir
détails sur l’acétate suivant).

• Alternative 2: Acheter un système existant

et l’adapter aux besoins du client:
• Temps nécessaire: 10 jours/homme
 Faisabilité temporelle
Prestation Temps requis
Analyse du système 20 jours / homme
Design et codage du système 40 jours / homme
Installation des capteurs et du système informatique
10 jours / homme

Tests et corrections
5 jours / homme

Formation du personnel
10 jours / homme
 3. Recommandations aux décideurs
• Résumé des alternatives proposées:
– Alternative 1: Développer un nouveau système:
• Délai de récupération: 3.05 ans
• VAN : 4 215 $
• Temps nécessaire: 85 jours/homme

– Alternative 2: Acheter un système

existant et l’adapter aux besoins du
client:
• Délai de récupération: 4.85 ans
• VAN : -20 934 $
• Temps nécessaire: 10 jours/homme
 Recommandations aux décideurs
(suite)
• En analysant la rentabilité et la faisabilité des deux
alternatives proposées pour le système d’alarme de la
station de service Essence 2012:
– Alternative 1: Développer un nouveau système
– et
– Alternative 2: Acheter un système existant et l’adapter
aux besoins du client
• Nous recommandons aux décideurs de poursuivre
l’exécution de l’alternative 1 du projet qui s’avère
faisable et plus rentable que l’alternative 2.
 Exercice
• Réaliser une analyse de rentabilité pour un projet
de développement d’un logiciel de gestion de
bibliothèque dont les données financières sont
présentées ci-après:
• Alternative 1:
– On développe un nouveau logiciel de gestion:
• Investissement initial: 75 000 $ (profits inclus)
• On estime des coûts récurrents annuels (dus à la maintenance)
d’environ 2 000 $
• On estime des économies annuelles (revenus) d’environ
20000
$, sur une période de 7 ans
• Le taux de rendement minimal requis par la haute direction est
de 15%
 Exercice (suite)
• Alternative 2:
On achète le logiciel de gestion GBIB disponible sur le
marché:
• Prix: 35 000 $
• Temps nécessaire pour l’adaptation: 40 heures/homme
• Taux horaire adaptation: 35 $ (profits inclus)
• On estime des coûts récurrents annuels (dus à la maintenance)
d’environ 2 000 $
• On estime des économies annuelles (revenus) d’environ 20
000
$, sur une période de 7 ans
• Le taux de rendement minimal requis par la haute direction est
de 15%
Analyse de rentabilité
logiciel de gestion de bibliothèque
• Alternative 1: Développer un nouveau système
• Délai de récupération de l’investissement initial: DR
= I0 / (Revenus - Dépenses) =
= 75 000 / (20 000 – 2 000) = 4.16 ans
• Valeur actuelle nette du projet (VAN):
– I0 = 75 000$ (investissement initial)
– Ft = Revenust – Dépensest = 20 000 – 2 000 = 18 000$ (où Ft
est le flux monétaire annuel)
VAN = -75 000 + 18 000 * (1.157 -1)/(0.15 *1.157 ) = -112.44 $
 Analyse de rentabilité (suite)
logiciel de gestion de bibliothèque
• Alternative 2: Acheter un système existant et
l’adapter aux besoins du client
• Délai de récupération de l’investissement initial: DR
= I0 / (Revenus - Dépenses) =
= 36 400 / (20 000 – 2 000) = 2.02 ans
• Valeur actuelle nette du projet (VAN):
– I0 = 35 000 + 40*35* = 36 400 $
(investissement initial)
– Ft = Revenust – Dépensest = 20 000 – 2 000
= 18 000$
– VAN = -36 400 + 18 000 * (1.157 -1)/(0.15
*1.157 ) = 38 487.55 $
Analyse de rentabilité (suite)
logiciel de gestion de bibliothèque

• Conclusion:
– L’alternative 2: Acheter un système existant
et l’adapter aux besoins des clients s’avère
plus rentable que l’alternative 1: Développer
un nouveau système :
• Délai de récupération plus court
• Valeur actuelle nette du projet positive
 3. Recommandations aux décideurs
logiciel de gestion de bibliothèque
• Résumé des alternatives proposées:
– Alternative 1: Développer un nouveau système:
• Délai de récupération: 4.16 ans
• VAN : -112.44 $
• Temps nécessaire: ??
– Alternative 2: Acheter un système
existant et l’adapter aux besoins du
client:
• Délai de récupération: 2.02 ans
• VAN : 38 487.55 $
• Temps nécessaire: ??