Chapitre 1 Introduction Au Génie Logiciel

Université Hassan 1er
Faculté des Sciences et Techniques

-Settat-
Département : Mathématiques & Informatique

Filière : Licence Génie Informatique
Module : Génie logiciel et UML
Chapitre 1 : Introduction au génie logiciel
Prof. Said El Kafhali
Département Mathématiques & Informatique

Faculté des Sciences et Techniques, Settat
Université Hassan 1er
Année Universitaire : 2018/2019

Année Universitaire : 2018/2019 1
Prof. Said El Kafhali Chapitre 1 : Introduction au génie logiciel / 59
Plan
1 Qu’est-ce que le génie logiciel ?

Motivations
Les critères de qualité pour un logiciel
Principes généraux en Génie Logiciel
2 Cycle de vie d’un logiciel
La crise du logiciel
Cycle de vie d’un logiciel
Les livrables
3 Modèles de développement logiciel
Introduction au modèles de développement
Modèles de développement logiciel
4 Références

Qu’est-ce que le génie logiciel ? Motivations
Plan

Motivations
Les livrables
4 Références

Définitions
Définition 1 :
Un logiciel est un programme ou un ensemble de programmes qui, quand
il(s) s’exécute(nt) réalise(nt) la (les) fonction(s) demandée(s) dans les
conditions prescrites.
Définition 2 :
Un logiciel est un ensemble des documents qui permettent l’installation,
l’opération, la réparation et l’évolution des programmes.
Définition 3 :
Un logiciel est un ensemble d’entités (des programmes exécutables, des
documentations d’utilisation, des informations de configuration...)
nécessaires au fonctionnement d’un processus de traitement automatique
de l’information.
Produits logiciels
Définition :
Conformité à des besoins fonctionnels et de performance explicités, à des
standards professionnels de développement explicitement documentés, à
des caractéristiques implicites attendues de tout logiciel développé de
manière professionnelle.
Types de produits logiciels :

Produit générique : système autonome produit par une société de
développement et vendu au public.
Produit sur mesure : système commandé par un client spécifique et
développé par un contracteur.

Les facteurs clés en génie logiciel

Trois facteurs clés en génie logiciel :
Personnel : nombre, habiletés, moral
Processus: procédures d’accomplissement de travail
Technologie: plateforme et domaine
Les bons processus aident le personnel à appliquer la technologie
De façon efficiente : sans perte de temps, ni effort, ni ressources
De façon efficace : tout en obtenant le résultat désiré
Qu’est-ce qu’un processus?

Un processus est une suite d’étapes impliquant des activités, des acteurs,
des ressources, et des contraintes pour produire un résultat escompté.
Génie Logiciel (SoftwareEngineering)

Comment faire des logiciels de qualité ?
Qu’attend-on d’un logiciel ?
Quels sont les critères de qualité pour un logiciel ?
Pourquoi le génie logiciel ?

Systèmes informatiques : 80% de logiciel et 20% de matériel.
Depuis quelques années, la fabrication du matériel est assurée
seulement par quelques fabricants.
Le matériel est relativement fiable et le marché est standardisé.
Les problèmes sont essentiellement des problèmes de logiciel.
Exemple
Etude sur un échantillon de 8 380 projets (Standish Group, 1995)
(http://www.volle.com/travaux/methodesprojet.htm).
16% sont un succès.
53% sont arrêtés en cours de réalisation.
31% aboutissent mais au prix d’un accroissement du délai et du coût
tout en offrant moins de fonctionnalités que prévu.
Succès : implication des utilisateurs, des dirigeants et exigences claires.
Echec : manque de clarté des besoins et évolution des spécifications
en cours de réalisation.
Qu’est-ce que le génie logiciel ? Les critères de qualité pour un logiciel
Plan

Motivations
Les livrables
4 Références

Critères de qualité pour un logiciel
Pour savoir comment améliorer la qualité d’un logiciel,

il faut tout d’abord se fixer des critères de qualité.
Ensuite il faut savoir comment mesurer la qualité.
Finalement, la question est : qu’est-ce qu’un logiciel de bonne qualité ?
Une fois les critères fixés, il faudra agir pour les améliorer. Voici les
critères de mettre en place (ils sont issus de la norme ISO 9126) :
1 Utilité,
2 Utilisabilité,
3 Fiabilité,
4 Interopérabilité, couplabilité,
5 Performance,
6 Portabilité,
7 Réutilisabilté,
8 Facilité de maintenance,

Utilité
Le besoin effectif de l’utilisateur = les fonctions offertes par le logiciel.
Solutions : Emphase sur l’analyse des besoins et améliorer la

communication (langage commun, démarche participative).
Utilisabilité
Facilité d’apprentissage : comprendre ce que l’on peut faire avec le
logiciel, et savoir comment le faire.
Facilité d’utilisation : importance de l’effort nécessaire pour utiliser le
logiciel à des fins données.
Solutions : Analyse du mode opératoire des utilisateurs et adapter

l’ergonomie des logiciels aux utilisateurs.

Fiabilité
Correction, justesse, conformité : le logiciel est conforme à ses
spécifications, les résultats sont ceux attendus.
Robustesse, sûreté : le logiciel fonctionne raisonnablement en toutes
circonstances, rien de catastrophique ne peut survenir, même en
dehors des conditions d’utilisation prévues.
Solutions
Utiliser des méthodes formelles, des langages et des méthodes de
programmation de haut niveau.
Vérifications, tests...

Critères de fiabilité
C’est la probabilité de faire une opération sans panne sur une durée
fixée et pour un contexte donné.
La fiabilité est subjective : elle dépend de l’utilisateur et du contexte
d’utilisation.
Elle donne une mesure du degré de confiance et elle mesure les
conséquences d’une faute.
Exemple
Pour un logiciel de saisie, une faute serait de ne pas vérifier la mauvaise
saisie. Un défaut serait que le logiciel plante suite à la mauvaise saisie.

Critères de qualité pour un logiciel : Métriques de la fiabilité
Taux de panne
C’est la fréquence d’apparition d’un défaut.
Temps moyen entre deux pannes

C’est la mesure de temps entre deux apparitions de défauts.
Disponibilité
C’est la probabilité que le système soit opérationnel. Elle prend en compte
le temps de réparation éventuel.
Probabilité d’une panne

C’est la probabilité que le système se comporte de manière non prévue (non
souhaitée) lorsqu’une requête est effectuée.

Interopérabilité, couplabilité
Un logiciel doit pouvoir interagir en synergie avec d’autres logiciels.
Solutions
Bases de données (découplage données/traitements),
Standardisation des formats de fichiers (XML...) et des protocoles de
communication (CORBA...).
Performance
Les logiciels doivent satisfaire aux contraintes de temps d’exécution.
Solutions
Veiller à la complexité des algorithmes.
Utiliser des machines plus performantes.

Portabilité
Un même logiciel doit pouvoir fonctionner sur plusieurs machines.
Solutions
Rendre le logiciel indépendant de son environnement d’exécution.
Utiliser des machines virtuelles.
Réutilisabilité
On peut espérer des gains considérables, dans la plupart des logiciels :
80% du code est du “tout venant“ qu’on retrouve à peu près partout.
20% du code est spécifique.
Solutions
Abstraction, généricité, et construction d’un logiciel à partir de
composants prêts à l’emploi ”Design Patterns“.
Facilité de maintenance
La maintenance absorbe une très grosse partie des efforts de
développement.
Solutions
Réutilisabilité, modularité
Vérifier, tester
Structures de données complexes et algorithmes simples
Anticiper les changements à venir
Progiciels

Qu’est-ce que le génie logiciel ? Principes généraux en Génie Logiciel
Plan

Motivations
Les livrables
4 Références

Un certain nombre de grands principes (de bon sens) se retrouvent

dans toutes ces méthodes. En voici une liste proposée par C. Ghezzi
(Fundamentals of Software Engineering, Prentice Hall, 2nd edition,
2002) :
1 La rigueur,
2 La décomposition des problèmes en sous problèmes indépendants,
3 La modularité,
4 L’abstraction,
5 L’anticipation des évolutions,
6 La généricité,
7 La construction incrémentale.
Vous devez avoir en tête ces principes : ils se retrouvent dans toutes
les méthodes et outils de génie logiciel.

La rigueur
Les principales sources de défaillances d’un logiciel sont d’origine
humaine.
A tout moment, il faut se questionner sur la validité de son action.
Des outils de vérification accompagnant le développement peuvent
aider à réduire les erreurs.
Cette famille d’outils s’appelle CASE (Computer Aided Software
Engineering).
Exemples
Typeurs, assistants de preuves, générateurs de code, générateurs de tests. .
.

La décomposition des problèmes en sous-problèmes indépendants

Décorréler les problèmes pour n’en traiter qu’un seul à la fois.
Simplifier les problèmes (temporairement) pour aborder leur
complexité progressivement.
Exemples
Comment acheminer un email de façon sûr à travers un réseau ?
Comment créer dynamiquement une page internet pour visualiser et
modifier le contenu d’une base donnée sans la corrompre ?

La modularité
Il s’agit de partitionner le logiciel en modules qui :
ont une cohérence interne (des invariants) ;
possèdent une interface ne divulguant sur le contenu du module que ce
qui est strictement nécessaire aux modules clients.
L’évolution de l’interface est indépendante de celle de
l’implémentation du module.
Les choix d’implémentation sont indépendants de l’utilisation du
module.
Ce mécanisme s’appelle le camouflage de l’information (information
hiding).

L’abstraction
Mécanisme qui permet de présenter un contexte en exprimant les
éléments pertinents et en omettant ceux qui ne le sont pas.
Il s’agit d’exhiber des concepts généraux regroupant un certain nombre
de cas particuliers et de raisonner sur ces concepts généraux plutôt
que sur chacun des cas particuliers.
Le fait de fixer la bonne granularité de détails permet :
de raisonner plus efficacement;
de factoriser le travail en instanciant le raisonnement général sur
chaque cas particulier.
Exemples
Les classes abstraites dans les langages à objets, le polymorphisme, les
fonctions d’ordre supérieur...
L’anticipation des évolutions

Un logiciel a un cycle de vie plus complexe que l’habituel cycle
”commande-spécification-production-livraison“.
La maintenance est la gestion des évolutions du logiciel.
Il est primordial de prévoir les évolutions possibles d’un logiciel pour
que la maintenance soit la plus efficace possible.
Ces modifications ne devraient pas être intrusives car les modifications
du produit existant remettent en cause ses précédentes validations.
Concevoir un système suffisamment riche pour que l’on puisse le
modifier incrémentalement est l’idéal.

La généricité
Un logiciel réutilisable a beaucoup plus de valeurs qu’un composant
dédié.
Un composant est générique lorsqu’il est adaptable.
regroupement d’un ensemble de fonctionnalités semblables en une
fonctionnalité paramétrable.

La construction incrémentale
Un développement logiciel a plus de chances d’aboutir si il suit une
cheminement incrémental (baby-steps).
Exemple
Laquelle de ses deux méthodes de programmation est la plus efficace ?
Écrire l’ensemble du code source d’un programme et compiler.

Écrire le code source d’une fonction ou module, le compiler, et passer à
la suivante.
Pourquoi ?

Cycle de vie d’un logiciel La crise du logiciel
Plan

Motivations
Les livrables
4 Références

Cycle de vie d’un logiciel La crise du logiciel
Les échecs de grands projets durant les années 60 et au début des
années 70 ont mis en évidence les problèmes de la gestion de projet.
Ces projets n’ont pas échoué parce que le programmeurs étaient
incompétents.
La faute incombait en fait aux techniques de gestion des projets mises
en œuvre.
Exemple
En 1979, le gouvernement américain estimait que la plupart des
grands projets avaient échoué :
Payés mais jamais livrés 47%,
Livrés mais jamais utilisés 30%,
Abandonnés ou refaits 20%,
Utilisés après modifications 3%,
Utilisés en l’état 2%.
Cycle de vie d’un logiciel Cycle de vie d’un logiciel
Plan

Motivations
Les livrables
4 Références

Le cycle de vie d’un logiciel (en anglais software lifecycle), désigne

toutes les étapes du développement d’un logiciel, de sa conception à
sa disparition.
Le cycle de vie du logiciel comprend généralement différentes activités,
en particulier :
1 Etude de faisabilité,
2 Spécification,
3 Organisation du projets,
4 Conception,
5 Implémentation,
6 Tests,
7 Livraison,
8 Maintenance.
L’objectif de ces activités est de permettre de définir des jalons
intermédiaires permettant la validation du développement logiciel.
Etude de faisabilité & Spécification
Etude de faisabilité
Déterminer si le développement proposé vaut la peine d’être mis en
œuvre, compte tenu des attentes et de la difficulté de développement.
Etude de marché : déterminer s’il existe un marché potentiel pour le
produit.
Spécification
Déterminer les fonctionnalités que doit posséder le logiciel.
Collecte des exigences : obtenir de l’utilisateur ses exigences pour le
logiciel. Expliquer brièvement ce qu’il doit faire et ne pas faire.
Analyse du domaine : déterminer les tâches et les structures qui se
répètent dans le problème.
Décrire le contexte de l’application dans lequel le produit s’intègre,
incluant les objectifs, les bénéfices et retombées du projet.

Organisation du projet & conception

Organisation du projet
Déterminer comment on va développer le logiciel :
Analyse des coûts : établir une estimation du prix du projet.
Planification : établir un calendrier de développement.
Assurance qualité du logiciel : déterminer les actions qui permettront
de s’assurer de la qualité du produit fini.
Répartition des tâches : hiérarchiser les tâches et sous-tâches
nécessaires au développement du logiciel.
Conception
Déterminer les différentes fonctionnalités recherchées.
Conception générale et architecturale : la structure du système.
Conception des interfaces : la façon dont les différentes parties du
système agissent entre elles.
Conception détaillée : les algorithmes pour les différentes parties du
système, description de la banque de données, description des E/S.
Implémentation
Ecrire le logiciel

Tests
Test de logiciel
Essayer le logiciel sur des données d’exemple pour s’assurer qu’il
fonctionne correctement.
Tests unitaires : faire tester les parties du logiciel par leurs
développeurs.
Tests d’intégration : tester pendant l’intégration. C’est simplement le
fait d’assembler plusieurs composants logiciels élémentaires pour
réaliser un composant de plus haut niveau.
Tests de validation : pour acceptation par l’acheteur.
Tests système : tester dans un environnement proche de
l’environnement de production.
Tests Alpha : faire tester par le client sur le site de développement.
Tests Bêta : faire tester par le client sur le site de production.
Tests de régression : enregistrer les résultats des tests et les comparer à
ceux des anciennes versions pour vérifier si la nouvelle n’en a pas
dégradé d’autres.
Livraison & Maintenance
Livraison
Fournir au client une solution logicielle qui fonctionne correctement.
Installation : rendre le logiciel opérationnel sur le site du clients.
Formation : enseigner aux utilisateurs à se servir du logicielle.
Assistance : répondre aux questions des utilisateurs.
Maintenance
La Les modifications apportées à un logiciel, après sa mise en œuvre,
pour en corriger les fautes, en améliorer l’efficacité ou autres
caractéristiques, ou encore adapter celui-ci à un environnement
modifié.
Mettre à jour et améliorer le logiciel pour assurer sa pérennité.
Pour limiter le temps et les coûts de maintenance, il faut, porter ses
efforts sur les étapes antérieures.

Cycle de vie d’un logiciel Les livrables
Plan

Motivations
Les livrables
4 Références

Qu’est-ce qu’un livrable ?

Un livrable est un produit ou un service donné au client.
Il s’agit de l’achèvement d’un processus, d’une tâche, d’une partie du
projet ou de l’aboutissement de la totalité du projet.
Généralement, un livrable est tangible, mesurable et spécifique et il
possède une date butoir.
Un livrable est le résultat d’un jalon ou d’une échéance inscrit dans le
planning du projet.
Un projet peut donc avoir plusieurs livrables.
1 Cahier des charges,
2 Spécifications,
3 Calendrier du projet,
4 Plan de test du logiciel,
5 Manuel utilisateur,
6 Code source,
7 Plan d’assurance qualité,
8 Rapport des tests,
9 Rapport des défauts.
Livrables
Cahier des charges

Description initiale des fonctionnalités désirées, généralement écrite
par l’utilisateur en collaboration avec le développeur.
Enoncé officiel de ce qui est requis des développeurs du système.

Livrables
Spécifications
Décrit précisément les conditions que doit remplir le logiciel.
Document de spécification des besoins qui décrit les données, les
fonctions, les performances, les conditions d’opération.
Modèle objet : indique les classes et les documents principaux.
Scénarios des cas d’utilisation : indique les différents enchaînement
Scénarios des cas d’utilisation.
Calendrier du projet
Ordre des différentes tâches, détails et ressources qu’elles demandent.
Plan de test du logiciel

Décrit les procédures de tests appliquées au logiciel.
Tests de validation : tests choisis par le client pour déterminer s’il peut
accepter le logiciel.
Livrables
Manuel utilisateur
Mode d’emploi pour le logiciel dans sa version finale.

Livrables
Code source
Code complet du produit fini.

Livrables
Plan d’assurance qualité

Décrit les activités mises en œuvre pour garantir la qualité du logiciel.
Définir les différentes méthodes et outils utilisés par le projet, ainsi que
les mesures à prendre et les étapes pour contrôler et assurer la qualité
du projet.
Rapport des tests

Décrit les tests effectués et les réactions du système.
Rapport des défauts

Décrit les comportements du système qui n’ont pas satisfait le client.
Il s’agit le plus souvent de défaillances du logiciel ou d’erreurs.

Modèles de développement logiciel Introduction au modèles de développement
Plan

Motivations
Les livrables
4 Références

Modèles de développement logiciel Introduction au modèles de développement
Introduction
Un modèle de processus de développement logiciels met en relief :
les activités de travail à accomplir pour produire le produit logiciel,
l’ordre dans lequel les activités de travail et les tâches doivent être
effectuées,
les façons dont les activités de travail et les tâches peuvent être
superposées et réitérées, et
les produits de travail résultants, et les flux entre diverses activités de
travail.
Différents modèles de développement logiciel :
1 Le modèle en cascade,
2 Le modèle en V,
3 Le développement incrémental (prototypage),
4 Le modèle évolutif,
5 La modèle orienté réutilisation,
6 Le modèle en spirale,
7 Les méthode Agile : Extreme Programming (XP), RUP (Rational
Unified Process),
8 ... Année Universitaire : 2018/2019 43
Modèles de développement logiciel Modèles de développement logiciel
Plan

Motivations
Les livrables
4 Références

Modèle en cascade

Le modèle en cascade
Le cycle de vie cascade en a été décrit par Royce dès 1970.

Il présente le développement logiciel comme une suite de phases qui
s’enchaînent dans un déroulement linéaire, depuis l’analyse des besoins
jusqu’à la livraison du produit au client.
Il est en général rythmé par la génération de documents qui servent de
validation pour le passage d’une phase à l’autre : ce sont les livrables
ou produits finis documentaires.
Chaque phase est donc achevée avant que ne débute la suivante.
On convient d’un certain nombre d’étapes, se terminant à des dates
précises par la production de documents ou logiciels.
Les résultats de l’étape sont examinés attentivement avant de passer à
l’étape suivante.

Le modèle en cascade
Avantages
Le SI (Système d’Information) est vu dans sa globalité.
Les utilisateurs et les financeurs ont une vision globale du projet.
Critique du modèle
Modèle trop séquentiel–>dure trop longtemps.
Validation trop tardive et remise en question coûteuse des phases
précédentes.
Sensibilité à l’arrivée de nouvelles exigences—>refaire toutes les
étapes.

Le modèle en V
«V» signifie que le développement du logiciel et le développement des
tests sont directement corrélés.

Le modèle en V
Les phases sont échelonnées dans le temps.

Une phase se termine par la remise d’un (ou plusieurs) document(s)
validé(s) conjointement par l’utilisateur et le développeur.
Une phase de développement se termine lorsque la revue de cette
phase est faite.
Une phase ne peut commencer que lorsque la précédente est terminée.
A la fin de chaque phase, l’utilisateur et le développeur sont d’accord.
La décomposition en phases de développement permet donc le suivi du
projet par l’utilisateur.
Les tests fonctionnels sont donc spécifiés lors de l’analyse, les tests
d’intégration lors de la conception et les tests unitaires pendant la
phase de codage.

Le modèle en V
Avantages
Limitation des risques en cascade par validation de chaque étape.
Prévention des erreurs : validations des produits à chaque sortie
d’étape descendante.
Validation finale montante : confirmation de la pertinence de
l’analyse descendante.
Limites
Les cycles de vie sont trop longs.
Les relations entre les clients et les fournisseurs ne sont pas
suffisamment formalisées.
L’intégration est trop tardive dans le cycle de vie.
La documentation est réalisée d’abord et le logiciel après.
Le modèle incrémentale
Plusieurs versions avant d’obtenir toutes les spécifications, Chaque

version est testée, reçue par un utilisateur.
Il est adapté à un développement et à une mise en production par lots.
Les phases s’achèvent par une activité de contrôle ou de test.
Plus d’interactions avec les utilisateurs : plus d’adaptations aux
changement des besoins.
Au lieu de juger sur des documents, les utilisateurs jugent sur une
version qu’ils peuvent tester.
Même si toutes les fonctionnalités ne sont pas réalisées, on peut
déployer une version intermédiaire.
/ŶĐƌĠŵĞŶƚ
sĞƌƐŝŽŶϭ sĞƌƐŝŽŶϮ sĞƌƐŝŽŶϯ sĞƌƐŝŽŶϰ sĞƌƐŝŽŶϱ sĞƌƐŝŽŶϲ

Développement itératif
&ĞĞĚͲďĂĐŬ
͙ ͙ ͙
/ƚĠƌĂƚŝŽŶϭ /ƚĠƌĂƚŝŽŶϮ /ƚĠƌĂƚŝŽŶϯ /ƚĠƌĂƚŝŽŶŶ
/ŵƉůĠŵĞŶƚĂƚŝŽŶ
ŽŶĐĞƉƚŝŽŶ
ŽŶĐĞƉƚŝŽŶ
ŽŶĐĞƉƚŝŽŶ
ŽŶĐĞƉƚŝŽŶ
/ŶĐĞƉƚŝŽŶ
ŶĂůǇƐĞ
ŶĂůǇƐĞ
ŶĂůǇƐĞ
ŶĂůǇƐĞ
ĂŚŝĞƌ
dĞƐƚ
dĞƐƚ
dĞƐƚ
dĞƐƚ
ĚĞƐĐŚĂƌŐĞƐ ͙
͙ ͙ ͙ ͙ ͙ dĞŵƉƐ
>ŝǀƌĂŝƐŽŶƐŝŶƚĞƌŵĠĚŝĂŝƌĞƐ
>ŝǀƌĂŝƐŽŶĨŝŶĂůĞ

Développement itératif
L’itération est le processus par lequel le résultat souhaité est développé

par des cycles répétés.
En génie logiciel, une approche itérative permet la révision et l’ajout,
étape par étape, des produits de travail.
Différents types de modèles itératifs supportent :
La révision et l’ajout des exigences.
La révision et l’ajout de design.
La révision et l’ajout du code.
Le test d’une partie du système.
et ainsi de suite.

Le modèle en spirale
ĠƚĞƌŵŝŶĂƚŝŽŶĚĞƐ
/ĚĞŶƚŝĨŝĐĂƚŝŽŶĞƚ
ŽďũĞĐƚŝĨƐ͕ĚĞƐ
ƌĠƐŽůƵƚŝŽŶĚĞƐ
ĂůƚĞƌŶĂƚŝǀĞƐ͕ĚĞƐ
ƌŝƐƋƵĞƐ
ĐŽŶƚƌĂŝŶƚĞƐ ĂŶĂůǇƐĞ
ĚĞƐƌŝƐƋƵĞƐ
ƐĠƌŝĞĚĞƐƉƌŽƚŽƚǇƉĞƐ
ƉůĂŶĚĞ ĐŽŶĐĞƉƚŝŽŶ ďĞƐŽŝŶƐ ĐŽŶĐĞƉƚŝŽŶ
ĐǇĐůĞĚĞ ĚĠƚĂŝůůĠĞ
ǀŝĞ
ƉůĂŶĚĞ ƚĞƐƚĞƐ
ĚĠǀĞůŽƉƉĞŵĞŶƚ ƵŶŝƚĂŝƌĞƐ
ǀĂůŝĚĂƚŝŽŶ ĐŽŶĐĞƉƚŝŽŶ
ƉůĂŶĚĞƐ
ƚĞƐƚƐĞƚĚĞ ǀĂůŝĚĂƚŝŽŶĞƚ ĐŽĚŝĨŝĐĂƚŝŽŶ
ů͛ŝŶƚĠŐƌĂƚŝŽŶ ǀĠƌŝĨŝĐĂƚŝŽŶ
ŝŶƚĠŐƌĂƚŝŽŶ
ĂĐĐĞƉƚĂƚŝŽŶ
WůĂŶŝĨŝĐĂƚŝŽŶĚĞƐ ĠƉůŽŝĞŵĞŶƚĞƚ
ƉŚĂƐĞƐƐƵŝǀĂŶƚĞƐ ǀĠƌŝĨŝĐĂƚŝŽŶͬǀĂůŝĚĂƚŝŽŶ
^ƉŝƌĂůĞƐƐƵƉƉůĠŵĞŶƚĂŝƌĞƐ
ĠǀĞŶƚƵĞůůĞŵĞŶƚ;ŝŶĐƌĠŵĞŶƚƐͿ

Il apporte une vue évolutive au modèle en cascade au travers d’une

approche fondée sur l’analyse et la gestion des risques, puis la
conception et la réalisation de prototypes évolutifs en fonction de
l’avancement du projet.
Le développement présente quatre grandes phases qui se succèdent au
fur et à mesure de la construction de la spirale.
Phase d’Identification,
Phase d’évaluation,
Phase de réalisation,
Phase de Vérification.
Au dernier tour de la spirale, le produit est totalement défini, les
risques résolus et le produit développé.

Le prototypage
Prototype : version d’essai du logiciel.
Pour tester les différents concepts et exigences.
Pour montrer aux clients les fonctions que l’on veut mettre en œuvre.
Lorsque le client a donné son accord, le développement suit souvent
un cycle de vie linéaire.
Avantages
Les efforts consacrés au développement d’un prototype sont le plus
souvent compensés par ceux gagnés à ne pas développer de fonctions
inutiles.

Phase d’Identification
Identification des besoins, Détermination des objectifs, Détermination des
alternatives pour atteindre les objectifs, Détermination des contraintes ...
Phase d’évaluation
Analyse des risques, Evaluation des alternatives, Identification et résolution
des risques. ...
Phase de réalisation
Développement et vérification de la solution retenue à l’issue de la phase
précédente, la phase d’évaluation.
Phase de Vérification
Vérification et validation du produit élaboré dans la phase de réalisation.
Planification de la prochaine phase.
Conclusion
Il n’y a pas de modèle idéal car tout dépend des circonstances.

Le modèle en cascade ou en V est risqué pour les développements
innovants car les spécifications et la conception risquent d’être
inadéquats et souvent remis en cause.
Le modèle incrémental est risqué car il ne donne pas beaucoup de
visibilité sur le processus complet.
Le modèle en spirale est un canevas plus général qui inclut l’évaluation
des risques.
Souvent, un même projet peut mêler différentes approches, comme le
prototypage pour les soussystèmes à haut risque et la cascade pour les
sous systèmes bien connus et à faible risque.

Références
Références
1 Jacques Printz, Jean-Francois Pradat-Peyre, "Pratique des tests

logiciels : Concevoir et mettre en oeuvre une stratégie de tests-
Préparer la certification ISTQB ", Dunod, InfoPro, 2014.
2 Jacques Lonchamp, "Analyse des besoins pour le développement
logiciel : Recueil et spécification, démarches itératives et agiles",
Dunod, Sciences sup, 2015.
3 Abdelhak-Djamel Seriai, "Evolution et maintenance des systèmes
logiciels", Hermès - Lavoisier, Traité IC2 - Informatique et systèmes
d’information, 2014.
4 André Pascal, Alain Vailly, "Développement de logiciels avec UML 2 et
OCL - Génie logiciel : Cours, études de cas et exercices corrigés",
Ellipses, Technosup, 2013.


Chapitre 1 Introduction Au Génie Logiciel

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Chapitre 1 Introduction Au Génie Logiciel

Transféré par

Droits d'auteur :

Formats disponibles

Université Hassan 1er

Faculté des Sciences et Techniques

Département : Mathématiques & Informatique

Chapitre 1 : Introduction au génie logiciel

Prof. Said El Kafhali

Département Mathématiques & Informatique

Année Universitaire : 2018/2019

1 Qu’est-ce que le génie logiciel ?

Année Universitaire : 2018/2019 2

1 Qu’est-ce que le génie logiciel ?

Année Universitaire : 2018/2019 3

Types de produits logiciels :

Année Universitaire : 2018/2019 5

Les facteurs clés en génie logiciel

Qu’est-ce qu’un processus?

Génie Logiciel (SoftwareEngineering)

Pourquoi le génie logiciel ?

1 Qu’est-ce que le génie logiciel ?

Année Universitaire : 2018/2019 8

Critères de qualité pour un logiciel

Pour savoir comment améliorer la qualité d’un logiciel,

Année Universitaire : 2018/2019 9

Critères de qualité pour un logiciel

Solutions : Emphase sur l’analyse des besoins et améliorer la

Solutions : Analyse du mode opératoire des utilisateurs et adapter

Année Universitaire : 2018/2019 10

Critères de qualité pour un logiciel

Année Universitaire : 2018/2019 11

Critères de qualité pour un logiciel

Année Universitaire : 2018/2019 12

Critères de qualité pour un logiciel : Métriques de la fiabilité

Temps moyen entre deux pannes

Probabilité d’une panne

Critères de qualité pour un logiciel

Critères de qualité pour un logiciel

Critères de qualité pour un logiciel

Année Universitaire : 2018/2019 16

1 Qu’est-ce que le génie logiciel ?

Année Universitaire : 2018/2019 17

Principes généraux en Génie Logiciel

Un certain nombre de grands principes (de bon sens) se retrouvent

Année Universitaire : 2018/2019 18

Principes généraux en Génie Logiciel

Année Universitaire : 2018/2019 19

Principes généraux en Génie Logiciel

La décomposition des problèmes en sous-problèmes indépendants

Année Universitaire : 2018/2019 20

Principes généraux en Génie Logiciel

Année Universitaire : 2018/2019 21

Principes généraux en Génie Logiciel

Principes généraux en Génie Logiciel

L’anticipation des évolutions

Année Universitaire : 2018/2019 23

Principes généraux en Génie Logiciel

Année Universitaire : 2018/2019 24

Principes généraux en Génie Logiciel

Écrire l’ensemble du code source d’un programme et compiler.

Année Universitaire : 2018/2019 25

1 Qu’est-ce que le génie logiciel ?

Année Universitaire : 2018/2019 26

1 Qu’est-ce que le génie logiciel ?

Année Universitaire : 2018/2019 28

Cycle de vie d’un logiciel