Conception et adaptation de

solutions applicatives I
Les problèmes et principes du génie logiciel ;
- La qualité du logiciel ;
- La conduite de projet informatique ;
- Les phases de développement ou les 7 étapes de la vie d’un logiciel.

CHAHIE THOMAS PAULIN i

SOMMAIRE
CHAPITRE I Généralités sur le Génie Logiciel ............................................................................... 1
I Définition ................................................................................................................................. 1
II Etat des lieux du développement logiciel ............................................................................. 1
III Le génie logiciel ....................................................................................................................... 2
III.1 Critères Qualité d’un logiciel ........................................................................................ 2
III.1.1 Capacité fonctionnelle(Functionality ) ................................................................. 2
III.1.2 Fiabilité (Reliability ) .............................................................................................. 3
III.1.3 Facilité d'utilisation(Usability ).............................................................................. 3
III.1.4 Rendement(Efficiency )......................................................................................... 4
III.1.5 Maintenabilité(Maintainability ) ........................................................................... 4
III.1.6 Portabilité(Portability ).......................................................................................... 4
III.1.7 Compromis de qualité ........................................................................................... 5
III.1.8 Résumé ................................................................................................................... 5
III.2 Principes ........................................................................................................................ 6
III.2.1 Rigueur ................................................................................................................... 6
III.2.2 Séparation des problèmes .................................................................................... 6
III.2.3 Modularité .............................................................................................................. 6
III.2.4 Abstraction............................................................................................................. 7
III.2.5 Anticipation du changement ................................................................................ 7
III.2.6 Généricité ............................................................................................................... 7
III.2.7 Construction incrémentale.................................................................................... 7
IV Retard du Génie logiciel .......................................................................................................... 7
CHAPITRE II Cycle de vie logiciel ................................................................................................ 9
I Notion de cycle de vie d’un logiciel ........................................................................................ 9
I.1 Définition ........................................................................................................................... 9
I.2 Activités du cycle de vie ................................................................................................... 9
I.2.1 Définition des objectifs : ........................................................................................... 9
I.2.2 Analyse des besoins et faisabilité ............................................................................. 9
I.2.3 Spécification ou conception générale ..................................................................... 9
I.2.4 Réalisation (Implémentation ou programmation) .................................................. 9
I.2.5 Mise en production ................................................................................................. 10
I.2.6 Maintenance ............................................................................................................ 10
II Modèle de cycle de vie.......................................................................................................... 10
II.1 Cycle de vie en cascade .................................................................................................. 10
II.2 Modèle de cycle de vie en V ............................................................................................ 11
II.3 Modèle itératif .................................................................................................................12
II.3.1 Modèle par prototype ..............................................................................................12
II.3.2 Modèle de cycle de vie en spirale ............................................................................12
II.4 Modèle par incrément .....................................................................................................12

CHAHIE THOMAS PAULIN ii

 III Choix d’un Processus .............................................................................................................13
CHAPITRE III SUIVIE D’UN PROJET INFORMATIQUE ................................................................15
I Les projets informatiques ......................................................................................................15
II Les acteurs d’un projet informatique ...................................................................................15
III Le cahier de charges ............................................................................................................. 16
III.1 Type de cahier de charges .......................................................................................... 16
III.2 Spécification logicielle ................................................................................................ 16
IV Des techniques de spécification pour les phases d’analyse ................................................17
IV.1 Les spécifications en langue naturelle ........................................................................17
IV.2 Les spécifications techniques dans des langages spécialisés ou des langages
informatiques de haut niveau ...................................................................................................17
V ESTIMATION DE CHARGE ......................................................................................................17
V.1 La non méthode .............................................................................................................. 18
V.2 Méthode Delphi .............................................................................................................. 18
V.3 Méthode de répartitions proportionnelle..................................................................... 18
VI Les méthodes d’analyse et de conception .......................................................................... 19
CHAPITRE IV Les AGL ..................................................................................................................21
I Catégories d’AGL....................................................................................................................21
II AGL orientée conception .......................................................................................................21
III AGL orientée Réalisation ...................................................................................................... 22

CHAHIE THOMAS PAULIN iii

 Généralités sur le Génie Logiciel
L’informatisation est le phénomène le plus important de notre époque. Elle s’immisce
maintenant dans la plupart des objets de la vie courante et ce, que ce soit dans l’objet1
proprement dit, ou bien dans le processus de conception ou de fabrication de cet objet. Pourtant
le développement d’un logiciel, élément principal (au moins en terme de d’investissement)2 du
système informatique n’est pas aisé. Sa réalisation est encadré par une science appelée Génie
Logiciel.

I Définition
Système : Un système est un ensemble d’éléments interagissant entre eux suivant un
certains nombres de principes et de règles dans le but de réaliser un objectif.
La frontière d’un système est le critère d’appartenance au système. L’environnement est la
partie du monde extérieure au système. Un système est souvent hiérarchisé à l’aide de sous-
systèmes.
Un logiciel est un ensemble d’entités nécessaires au fonctionnement d’un processus de
traitement automatique de l’information. Il est composé de :
 des programmes (en format code source ou exécutables) ;
 des documentations d’utilisation ;
 des informations de configuration.
Un logiciel est en général un sous-système d’un système englobant. Il peut interagir avec
des clients, qui peuvent être :
 des opérateurs humains (utilisateurs, administrateurs, . . . ) ;
 d’autres logiciels ;
 des contrôleurs matériels.
 Il réalise une spécification : son comportement vérifie un ensemble de critères qui
régissent ses interactions avec son environnement.

Un logiciel est composé :

• Des documents de gestion de projet,
• Une Spécifications décrivant la liste des fonctions à remplir par le logiciel, les facteurs
qualité du logiciel (portabilité, évolutivité, robustesse, . . .), les contraintes (performances
temporelles et spatiales, . . .) et les interfaces avec son environnement
• Une conception décrivant la découpe de la spécification en modules (ou objets),
la description les interfaces entre ces modules (ou objets) et la description des algorithmes mis
en place
• Un code source et un exécutable

II Etat des lieux du développement logiciel

Dans les années 70 des constats ont été faits sur l’activité de développement logiciel. Ces
constats concernent notamment :
 Le coût du développement du logiciel dépasse souvent celui du matériel ;
 La non qualité des systèmes ;
i32
1
Par exemple, aujourd’hui, 90% des nouvelles fonctionnalités des automobiles sont apportées par l’électronique et
l’informatique embarquées. Il y a, ou aura à terme, du logiciel partout : ampoules électriques, four à micro-ondes, tissus
des vêtements, stylos, livres, etc
2 Les investissements d’un S.I se répartissent en 20% pour le matériel et 80% pour le logiciel
CHAHIE THOMAS PAULIN Page 1
Ces chiffres sont d’ailleurs confirmé par une étude menée en 1995 par le Standish Group et
montrant que :
 16, 2% seulement des projets étaient conformes aux prévisions initiales ;
 52, 7% avaient subi des dépassements en coût et délai d’un facteur 2 à 3 avec
diminution du nombre des fonctions offertes ;
 31, 1% ont été purement abandonnés durant leur développement.
Comme exemple des échecs du logiciel, on peut citer :
 1988, abattage d'un Airbus 320 par l'USS Vincennes: affichage cryptique et confusion du
logiciel de détection
 1991, échec de missile patriot: calcul imprécis de temps dû à des erreurs arithmétiques
 London Ambulance Service Computer Aided Despatch System: plusieurs décès
 Le 3 Juin 1980, North American Aerospace Defense Command (NORAD) rapporta que les
U.S. étaient sous attaque de missiles
 Echec du premier lancement opérationnel de la navette spatiale dont le logiciel
d'exploitation temps réel consiste en environ 500,000 LOC: problème de synchronisation
entre les ordinateurs de contrôle de vol
 Réseau téléphonique longue distance d'AT&T: Panne de 9 heures provoqué par un patch
de code non testé
Pour ces raisons, le développement du logiciel suit un ensemble de règles permettant de faciliter
le processus de développement. Ces règles sont encadrées par le génie logiciel.

III Le génie logiciel

Le génie logiciel est une science qui voit le jour en 1965 et fait suite à la crise du logiciel. Elle
se fixe comme objectif de produire des logiciels de Qualité, remplissant les fonctionnalités de
l’utilisateur dans les limites et coût et de Délai prévue au départ (CQFD).

III.1 Critères Qualité d’un logiciel

ISO/IEC 9126 propose 6 caractéristiques de qualité du produit logiciel. Pour chaque facteur
ou critère de qualité, il faut connaître sa définition son importance et comment l'évaluer
du point de vue du fournisseur (évaluation en amont) et du point de vue du client (évaluation
en aval) et savoir comment l'améliorer ou l'optimiser
III.1.1 Capacité fonctionnelle (Functionality )
Ensemble d'attributs portant sur l'existence d'un ensemble de fonctions et leurs
propriétés. Les fonctions sont celles qui satisfont aux besoins exprimés ou implicites.
Ce critère possède les sous caractéristiques :
 Aptitude : présence et adéquation d’une série de fonctions pour des tâches
données
 Exactitude : fourniture de résultats ou d’effets justes ou convenus
 Interopérabilité : capacité à interagir avec des systèmes donnés
 Sécurité : aptitude à empêcher tout accès non autorisé (accidentel ou délibéré)
aux programmes et données
Ce critère est plus important des critères de qualité on souhaite développer des
logiciels qui répondent aux besoin de l’utilisateur tout en faisant un bon usage de ses ressources.
Il est capital pour l'utilisateur final et le client.

CHAHIE THOMAS PAULIN Page 2

 La détermination de la capacité fonctionnelle du système sera fortement influencée par le
rédacteur du texte original. En ce qui concerne le client, c'est le lecteur qui déterminera
l'importance de la capacité fonctionnelle. Le rédacteur et le lecteur ne sont concernés que par
cette caractéristique.
III.1.2 Fiabilité (Reliability )
Ensemble d'attributs portant sur l'aptitude du logiciel à maintenir son niveau de service
dans des conditions précises et pendant une période déterminée.
Ce critère possède les sous caractéristiques :
 Maturité : fréquence des défaillances dues à des défauts du logiciel
 Tolérance aux fautes : aptitude à maintenir un niveau de service donné en cas de
défaut du logiciel ou de violation de son interface
 Possibilité de récupération : capacité à rétablir son niveau de service et de restaurer
les informations directement affectées en cas de défaillance ; temps et effort
nécessaire pour le faire
Ce critère correspond à l'aptitude d’un logiciel à fournir des résultats voulus dans les
conditions normales d’utilisation selon deux point de vue : qualité de la conception et qualité de
la réalisation.
Un logiciel fiable doit répondre aux spécifications, ne jamais produire de résultats faux ou
être dans un état incohérent, il doit aussi réagir utilement dans une situation inattendue et ne
jamais être en défaut qu’en cas extrême
La fiabilité est subjective : elle dépend de l’utilisateur et du contexte d’utilisation. Elle
donne une mesure du degré de confiance et des conséquences d’une faute. Le but est de fournir
les services attendus par les utilisateurs sachant que certains services sont extrêmement
importants (une seule erreur peut être fatale ex: avionique) tout en réduisant la probabilité des
pannes sur une durée fixée

III.1.3 Facilité d’utilisation (Usability )

Ensemble d'attributs portant sur l'effort nécessaire pour l’utilisation et l'évaluation
individuelle de cette utilisation par un ensemble défini ou implicite d’utilisateurs.
Ce critère possède les sous caractéristiques :
 Facilité de compréhension : effort que doit faire l’utilisateur pour reconnaître la
logique et sa mise en œuvre
 Facilité d’apprentissage : effort que doit faire l’utilisateur pour apprendre son
application, il doit comprendre ce que l'on peut faire avec le logiciel, et savoir
comment le faire
 Facilité d’exploitation : effort que doit faire l’utilisateur pour exploiter et
contrôler l’exploitation de son application
Ce critère concerne l'effectivité, l'efficacité et la satisfaction avec lesquelles des
utilisateurs spécifiés accomplissent des objectifs bien définis dans un environnement particulier.
Avant de réaliser un logiciel il faut analyser le mode opératoire des utilisateurs, ensuite adapter
l'ergonomie des logiciels aux utilisateurs. Ce critère comprend la façon dont l'information et les
suggestions sont présentées à l'utilisateur final, et aussi la documentation disponible, et l'effort
nécessaire pour apprendre à se servir du système.

CHAHIE THOMAS PAULIN Page 3

 III.1.4 Rendement (Efficiency )
Ensemble d'attributs portant sur le rapport existant entre le niveau de service d’un logiciel
et la quantité de ressources utilisées, dans des conditions déterminées.
Ce critère possède les sous caractéristiques :
 Comportement vis-à-vis du temps : temps de réponses et de traitement ; débits lors
de l’exécution de sa fonction
 Comportement vis-à-vis des ressources : quantité de ressources utilisées ; durée de
leur utilisation lorsqu'il exécute sa fonction
Les logiciels doivent satisfaire aux contraintes de temps d'exécution en développant des
produits plus simples tout en veillant à la complexité des algorithmes et en utilisant des
machines plus performantes.
III.1.5 Maintenabilité (Maintainability )
Ensemble d'attributs portant sur l'effort nécessaire pour faire des modifications
données.
Ce critère possède les sous caractéristiques :
 Facilité d’analyse : effort nécessaire pour diagnostiquer les déficiences et causes
de défaillance ou pour identifier les parties à modifier
 Facilité de modification : effort nécessaire pour modifier, remédier aux défauts ou
changer d’environnement
 Stabilité : risque des effets inattendus des modifications
 Facilité de test : effort nécessaire pour valider le logiciel modifié
Ce critère concerne la gestion du processus de modification pour éviter que des
corrections partielles soient faites en dehors du processus d’itérations.
Il existe trois types de maintenance
 Maintenance perfective (évolutive)qui consiste à maintenir les fonctionnalités
antérieures tout en ajoutant des nouvelles fonctionnalités qui modifient
profondément l'architecture comme le changement de SGBD…
 Maintenance adaptative qui correspond à l'ajout de petites fonctionnalités qui ne
modifie pas l'architecture comme passage de données par fichiers…
 Maintenance corrective qui permet la correction des anomalies ou des erreurs
mises à jour par le client et non pas lors des tests de vérification et de validation.
Le coût de la maintenance est influencé par l’âge du logiciel, l'importance des
modifications, la stabilité de l’équipe, la qualité de la documentation technique ou de document
de maintenance
III.1.6 Portabilité (Portability )
Ensemble d'attributs portant sur l'aptitude du logiciel à être transféré d’un
environnement à l’autre.
Ce critère possède les sous caractéristiques :
 Facilité d’adaptation :possibilité d’adaptation à différents environnements donnés
sans que l’on ait recours à d’autres actions ou moyens que ceux prévus à cet effet
pour le logiciel considéré

CHAHIE THOMAS PAULIN Page 4

  Facilité d’installation : effort nécessaire pour installer le logiciel dans un
environnement donné
 Conformité aux règles de portabilité : conformité aux normes et aux conventions
ayant trait à la portabilité
 Interchangeabilité : possibilité et effort d’utilisation du logiciel à la place d’un
autre logiciel donné dans le même environnement
Ce critère est aussi très important car il faut toujours essayer de développer un logiciel
portable d’une plate-forme à une autre, d’un site à un autre ; sachant que les architectures
machines sont diffèrent, les systèmes d’exploitation, les performances aussi… de plus il
faut prendre en considération qu’un logiciel vit et dure dans le temps et que l’environnement
humain et matériel évolue.
III.1.7 Compromis de qualité
Les critère de qualité peuvent être contradictoires, pour chaque, le choix des
compromis doit s’effectuer en fonction du contexte.
• Facilité d’emploi vs maintenabilité
• Fiabilité vs portabilité
• Capacité vs rendement
La qualité s’obtient par la mise en place de procédure et des méthodes de phase de
spécification tout en prenant en compte que la démarche qualité ne consiste pas à corriger les
défauts mais à les prévenir et pour un contexte donné.
III.1.8 Résumé
La qualité d’un logiciel est notion multiforme regroupant :
 Validité : aptitude d’un produit logiciel à remplir exactement ses fonctions, définies
par le cahier des charges et les spécifications.
 Fiabilité ou robustesse : aptitude d’un produit logiciel à fonctionner dans des
conditions anormales.
 Extensibilité (maintenance) : facilité avec laquelle un logiciel se prête à sa
maintenance, c’est-à-dire à une modification ou à une extension des fonctions qui
lui sont demandées.
 Réutilisabilité : aptitude d’un logiciel à être réutilisé, en tout ou en partie, dans de
nouvelles applications.
 Compatibilité : facilité avec laquelle un logiciel peut être combiné avec d’autres
logiciels.
 Efficacité : Utilisation optimales des ressources matérielles.
 Portabilité : facilité avec laquelle un logiciel peut être transféré sous différents
environnements matériels et logiciels.
 Vérifiabilité : facilité de préparation des procédures de test.
 Intégrité : aptitude d’un logiciel à protéger son code et ses données contre des
accès non autorisés.
 Facilité d’emploi : facilité d’apprentissage, d’utilisation, de préparation des
données, d’interprétationdes erreurs et de rattrapage en cas d’erreur d’utilisation.

CHAHIE THOMAS PAULIN Page 5

 Ces facteurs sont parfois contradictoires, le choix des compromis doit s’effectuer en
fonction du contexte.

III.2 Principes
Le génie logiciel repose sur 7 principes fondamentaux (proposés par Carlo Ghezzi):
 rigueur,
 séparation des problèmes (« separation of concerns »),
 modularité,
 abstraction,
 anticipation du changement,
 généricité,
 construction incrémentale.
III.2.1 Rigueur
La production de logiciel est une activité créative, mais qui doit se conduire avec une
certaine rigueur. Certains opposent parfois créativité et rigueur.
Le niveau maximum de rigueur est la formalité, c’est à dire le cas où les descriptions et les
validations s’appuient sur des notations et lois mathématiques. Il n’est pas possible d’être formel
tout le temps : il faut bien construire la première description formelle à partir de connaissances
non formalisées.
III.2.2 Séparation des problèmes
C’est une règle de bons sens qui consiste à considérer séparément différents aspects d’un
problème afin d’en maîtriser la complexité. C’est un aspect de la stratégie générale du « diviser
pour régner ».
Elle prend une multitude de formes :
 séparation dans le temps (les différents aspects sont abordés successivement),
avec la notion de cycle de vie du logiciel que nous étudierons en détail,
 séparation des qualités que l’on cherche à optimiser à un stade donné (ex :
assurer la correction avant de se préoccuper de l’efficacité),
 séparations des ‘vues’ que l’on peut avoir d’un système (ex : se concentrer sur
l’aspect ‘flots de données’ avant de considérer l’aspect ordonnancement des
opérations ou ‘flot de contrôle’),
 séparation du système en parties (un noyau, des extensions, …),
Les méthodes aident à organiser le travail en guidant dans la séparation et
l’ordonnancement des questions à traiter.
III.2.3 Modularité
Un système est modulaire s’il est composé de sous-systèmes plus simples, ou modules. La
modularité est une propriété importante de tous les procédés et produits industriels. La
modularité permet de considérer séparément le contenu du module et les relations entre
modules. Elle facilite également la réutilisation de composants biens délimités.
Un bon découpage modulaire se caractérise par une forte cohésion interne des modules
et un faible couplage entre les modules (relations inter modulaires en nombre limité et
clairement décrites).

CHAHIE THOMAS PAULIN Page 6

 Toute l’évolution des langages de programmation vise à rendre plus facile une
programmation modulaire, appelée aujourd’hui ‘programmation par composants’.
III.2.4 Abstraction
L’abstraction est le principe fondamental du génie logiciel. L’abstraction consiste à ne
considérer que les aspects jugés importants d’un système à un moment donné (niveau de
décomposition), en faisant abstraction des autres aspects (c’est encore un exemple de
séparation des problèmes). L’abstraction permet une meilleure maîtrise de la complexité.
III.2.5 Anticipation du changement
La caractéristique essentielle du logiciel, par rapport à d’autres produits, est qu’il est
presque toujours soumis à des changements continuels (corrections d'imperfections et
évolutions en fonctions des besoins qui changent).
Ceci requiert des efforts particuliers pour prévoir, faciliter et gérer ces évolutions
inévitables. Il faut par exemple faire usage de:
 localité: faire en sorte que les changements soient les plus localisés possibles
 être capable de gérer les multiples versions des modules et configurations des
versions des modules, constituant des versions du produit complet.
 Uniformité: S’assurer que les modules utilisent des notations cohérentes et sont
débarrassés de toutes notations inutiles.
III.2.6 Généricité
Il est parfois avantageux de remplacer la résolution d’un problème spécifique par la
résolution d’un problème plus général. Cette solution générique (paramétrable ou adaptable)
pourra être réutilisée plus facilement.
III.2.7 Construction incrémentale
Un procédé incrémental atteint son but par étapes en s’en approchant de plus en plus ;
chaque résultat est construit en étendant le précédent.

IV Retard du Génie logiciel

Malgré tout le GL reste aujourd’hui moins avancé (formalisé, mathématique) et moins bien
codifié que d’autres ‘sciences de l’ingénieur’, comme le génie civil, ou le génie chimique. Une
des raisons est la nature même du logiciel :
 le logiciel est un objet immatériel (pendant son développement), très malléable
au sens de facile à modifier (cf. « hardware/software »),
 ses caractéristiques attendues sont difficiles à figer au départ et souvent remises
en cause en cours de développement,
 les défaillances et erreurs ne proviennent ni de défauts dans les matériaux ni de
phénomènes d’usure dont on connaît les lois mais d’erreurs humaines,
inhérentes à l’activité de développement,
 le logiciel ne s’use pas, il devient obsolète (par rapport aux concurrents, par
rapport au contexte technique, par rapport aux autres logiciels, ...),
 le développement par assemblage de composants est encore balbutiant dans le
domaine logiciel (beans, EJB, composants CORBA, ...).

CHAHIE THOMAS PAULIN Page 7

 Cependant, grâce au GL des progrès ont été réalisés. Mais la complexité des systèmes ne
cesse de s’accroître.
Exemple :
 Compilateur C : 10 HA (Homme/années), 20 à 30 KLS (milliers de lignes source)
 Compilateur Ada : 120 à 150 HA
 SGBD (Oracle, DB2) : 300 à 500 HA
 Navette spatiale : > 1000 HA, 2 200 KLS, 6 an

CHAHIE THOMAS PAULIN Page 8

 Cycle de vie logiciel
I Notion de cycle de vie d’un logiciel

I.1 Définition
Comme pour toutes les fabrications, il est important d’avoir un procédé de fabrication du
logiciel bien défini et explicitement décrit et documenté. En GL, il s’agit d’un type de fabrication
un peu particulier : en un seul exemplaire, car la production en série est triviale (recopie).
Le « cycle de vie d'un logiciel » (software lifecycle ), désigne toutes les étapes du
développement d'un logiciel, de sa conception à sa disparition. Ce découpage permet de définir
des jalons intermédiaires permettant la validation du développement logiciel (conformité
du logiciel avec les besoins exprimés), et la vérification du processus de développement
(adéquation des méthodes mises en œuvre).
L'origine de ce découpage provient du constat que les erreurs ont un coût d'autant plus
élevé qu'elles sont détectées tardivement dans le processus de réalisation.
Le cycle de vie permet de détecter les erreurs au plus tôt et ainsi de maîtriser la qualité du
logiciel, les délais de sa réalisation et les coûts associés.

I.2 Activités du cycle de vie

Le cycle de vie du logiciel comprend généralement à minima les étapes suivantes :
I.2.1 Définition des objectifs :
Cette étape consiste à définir la finalité du projet et son inscription dans une stratégie
globale. La stratégie globale est généralement décrite dans le schéma directeur ou plan
stratégique d’informatisation.
I.2.2 Analyse des besoins et faisabilité
On procède à l’expression, le recueil et la formalisation des besoins (fonctionnels et non
fonctionnels) du demandeur (le client) et de l’ensemble des contraintes puis l’estimation de la
faisabilité de ces besoins. Pour recueillir les besoins l’analyste a recours aux interviews des postes
de travail, à la documentation existante, à l’auto-analyse. La production attendue est le cahier
de charges contenant :
• Fonctionnalités attendues
• Contraintes non fonctionnelles
• Qualité, précision, optimalité, ...
• temps de réponse, contraintes de taille, de volume de traitement, ...
I.2.3 Spécification ou conception générale
Il s’agit de l’élaboration des spécifications de l’architecture du logiciel. On s’intéressera au
modèle de données et de traitement. Par la suite il sera question de définir précisément chaque
sous-ensemble du logiciel. A ce niveau on conçoit particulièrement les écrans, on s’intéressera à
la codification des données.
I.2.4 Réalisation (Implémentation ou programmation)
Il est question de réaliser le logiciel. Les principales étapes sont :

CHAHIE THOMAS PAULIN Page 9

  Codage unitaires : (Implémentation ou programmation) – c’est la traduction dans
un langage de programmation des fonctionnalités définies lors de phases de
conception.
 Tests unitaires Ils permettent de vérifier individuellement que chaque sous-
ensemble du logiciel est implémenté conformément aux spécifications.
 Intégration L’objectif est de s’assurer de l’interfaçage des différents éléments
(modules) du logiciel. Elle fait l’objet de tests d’intégration consignés dans un
document.
 Documentation – Elle vise à produire les informations nécessaires pour
l’utilisation du logiciel et pour des développements ultérieurs.
I.2.5 Mise en production
Déploiement du logiciel chez le client et tests avec des sous ensemble d’usager choisi. Dans
cette étape il faut réaliser les tests en vraie grandeur dans les conditions normales d'utilisation
et intégrer le logiciel dans l'environnement extérieur (autres logiciels, utilisateurs), ensuite
vérifier que le logiciel développé répond aux besoins exprimés dans la phase de spécifications
des besoins.
I.2.6 Maintenance
Elle comprend toutes les actions correctives (maintenance corrective) et évolutives
(maintenance évolutive) sur le logiciel.
La séquence et la présence de chacune de ces activités dans le cycle de vie dépend du choix
d’un modèle de cycle de vie entre le client et l’équipe de développement. Le cycle de vie permet
de prendre en compte, en plus des aspects techniques, l’organisation et les aspects humains.

II Modèle de cycle de vie

On en distingue plusieurs, toutefois le GL définit les caractéristiques que doit avoir un bon
modèle. On note que celui doit être :
 Clairement définie
 Observable (évolution visible de l’extérieur)
 Implémenté (gérable par les AGL ou les CASE)
 Accepté par les acteurs du projet
 Robuste
 Maintenable(Le processus évolue en fonction des changements de
l’organisation)
Les principaux cycles de développement logiciel sont entre autre le cycle en cascade, V, en spirale
et incrémental.

II.1 Cycle de vie en cascade

Le modèle de cycle de vie en cascade a été mis au point dès 1966, puis formalisé aux
alentours de 1970. Dans ce modèle le principe est très simple : chaque phase se termine à une
date précise par la production de certains documents ou logiciels. Les résultats sont définis sur
la base des interactions entre étapes, ils sont soumis à une revue approfondie et on ne passe à
la phase suivante que s’ils sont jugés satisfaisants.

CHAHIE THOMAS PAULIN Page 10

 Le modèle original ne comportait pas de possibilité de retour en arrière. Celle-ci a été
rajoutée ultérieurement sur la base qu’une étape ne remet en cause que l’étape précédente, ce
qui, dans la pratique, s’avère insuffisant.

Les inconvénients sont :

• Entraîne des relations conflictuelles avec les parties prenantes en raison :
o Du manque de clarté de la définition des exigences
o D’engagements importants dans un contexte de profonde incertitude
o D’un désir inévitable de procéder à des changements
• Entraîne une identification tardive de la conception, et un démarrage tardif du codage
• Retarde la résolution des facteurs de risque (intégration tardive dans le cycle de vie)
• Exige d’accorder une attention très importante aux documents

II.2 Modèle de cycle de vie en V

Le modèle en V demeure actuellement le cycle de vie le plus connu et certainement le plus
utilisé. Il s’agit d’un modèle en cascade dans lequel le développement des tests et du logiciel sont
effectués de manière synchrone.
Le principe de ce modèle est qu’avec toute décomposition doit être décrite la
recomposition et que toute description d’un composant est accompagnée de tests qui
permettront de s’assurer qu’il correspond à sa description.

Ceci rend explicite la préparation des dernières phases (validation-vérification) par les
premières (construction du logiciel), et permet ainsi d’éviter un écueil bien connu de la

CHAHIE THOMAS PAULIN Page 11

spécification du logiciel : énoncer une propriété qu’il est impossible de vérifier objectivement
après la réalisation. La conséquence est une obligation de concevoir les jeux de test et leurs
résultats, réflexion et retour sur la description encours et meilleure préparation de la branche
droite du V.
• Maintenance non intégrée : logiciels à vocation temporaire
• Validations intermédiaires non formelles : aucune garantie sur la non
transmission d’erreurs

II.3 Modèle itératif

II.3.1 Modèle par prototype
Modèle valable dans le cas où les besoins ne sont pas clairement définis ou ils changent au
cours de temps. Il permet le développement rapide d’une ébauche du futur logiciel avec le client
afin de fournir rapidement un prototype exécutable pour permettre une validation concrète
(ici expérimentale) et non sur papier (document) avec moins de risque de spécifications. Des
versions successives du prototype (itérations) sont réalisées avec écriture de la spécification à
partir du prototype puis processus de développement linéaire.

II.3.2 Modèle de cycle de vie en spirale

Proposé par B. Boëhm en 1988, ce modèle général met l'accent sur l’évaluation des risques.
A chaque étape, après avoir défini les objectifs et les alternatives, celles-ci sont évaluées
par différentes techniques (prototypage, simulation, ...). L’étape est réalisée et la suite est
planifiée. Le nombre de cycles est variable selon que le développement est classique ou
incrémental

II.4 Modèle par incrément

Dans les modèles précédents un logiciel est décomposé en composants développés
séparément et intégrés à la fin du processus. Dans les modèles par incrément un seul ensemble

CHAHIE THOMAS PAULIN Page 12

de composants est développé à la fois : des incréments viennent s’intégrer à un noyau de logiciel
développé au préalable. Chaque incrément est développé selon l’un des modèles précédents.

Les avantages de ce type de modèle sont les suivants :

 chaque développement est moins complexe;
 les intégrations sont progressives;
 il est ainsi possible de livrer et de mettre en service chaque incrément;
 il permet un meilleur lissage du temps et de l’effort de développement grâce à la
possibilité de recouvrement (parallélisassions) des différentes phases.
Les risques de ce type de modèle sont les suivants :
 remettre en cause les incréments précédents ou pire le noyau;
 ne pas pouvoir intégrer de nouveaux incréments.
Les noyaux, les incréments ainsi que leurs interactions doivent donc être spécifiés
globalement, au début du projet. Les incréments doivent être aussi indépendants que possibles,
fonctionnellement mais aussi sur le plan du calendrier du développement. Extreme
Programming est un exemple de processus incrémental.

III Choix d’un Processus

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équate 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.

CHAHIE THOMAS PAULIN Page 13

 Il faut toutefois noter qu’il existe d’autres concepts liés au processus logiciel. C’est le cas
de la réingénierie logicielle. Il s’agit de “retraiter” ou de recycler des logiciels en fin de vie. Les
“vieux” logiciels sont un capital fonctionnel qui peut être de grande valeur par leur conception
et leur architecture prouvées. Le code source est adaptable aux nouvelles technologies :
 migration de chaînes de traitements batch vers du transactionnel,
 fichiers à bases de données,
 intégration de composants standards (progiciels),
 migration de transactionnel vers du client-serveur ;
 migration du client-serveur vers des architectures à 3 niveaux (ex : clients légers sur
le Web),
Il existe des outils (traducteurs de code source, fichiers à BD, réorganisation de BD, etc.)

CHAHIE THOMAS PAULIN Page 14

 SUIVIE D’UN PROJET INFORMATIQUE
Il est question dans cette section de :
 Présenter les principaux acteurs d’un projet et leurs rôles
 Présenter les techniques de spécification d’un logiciel
 Classifier les méthodes d’analyse et de conception des S.I
 De présenter les méthodes permettant d’évaluer la charge d’un projet.

I Les projets informatiques

Le projet est un ensemble de travaux coordonnés, sous contrainte de coût, délimités dans
le temps et ayant comme objectif la satisfaction de besoins précis des utilisateurs de
l’informatique. Dans le domaine des systèmes d’information, on peut distinguer deux types de
projets :
• le projet du domaine des technologies informatiques (mise en place d’ordinateurs, de
réseaux, d’équipements de sécurité…) ;
• le projet système d’information, qui modifie le comportement du SI et s’inscrit dans un
contexte global (stratégie, fusion, réorganisation…). Ce type de projet touche une partie
déterminée du SI (le périmètre fonctionnel du projet) et c’est généralement un projet
d’application des technologies informatiques, ou projet d’informatisation.
Plus généralement, un projet informatique (qui concerne le système informatique) peut se
rattacher aux catégories suivantes :
• Projet d’amélioration de l’existant : Retouche, évolution de logiciel, renforcement des
capacités de traitement sans modifier l’architecture applicative
• Projet de développement : Ajout d’une nouvelle fonctionnalité au SI ou remplacement
d’une fonction existante ;
• Projet d’intégration : Vise à rendre les applications interopérables2 (mise en place d’un PGI
ou d’interfaçages divers)
• Projet de rationalisation : Refonte du SI, plan d’évolution progressive
• Projet de migration : Changement de système d’exploitation ou de système applicatif

II Les acteurs d’un projet informatique

Un projet informatique met en jeu deux principaux acteurs ou protagonistes :
 Maître d’ouvrage (MOA) : c’est une personne morale (entreprise, direction etc.), une
entité de l’organisation. Ce n’est jamais une personne.
 Maître d’œuvre (MOE) est une personne morale (entreprise, direction etc.) garante de la
bonne réalisation technique des solutions. Il a, lors de la conception du SI, un devoir de
conseil vis-à-vis du MOA, car le SI doit tirer le meilleur parti des possibilités techniques.
Le MOA est client du MOE à qui il passe commande d’un produit nécessaire à son activité.
Le MOE fournit ce produit ; soit il le réalise lui-même, soit il passe commande à un ou
plusieurs fournisseurs (« entreprises ») qui élaborent le produit sous sa direction.
La relation MOA et MOE est définie par un contrat précisant leurs engagements mutuels.
Lorsque le produit est compliqué, il peut être nécessaire de faire appel à plusieurs
fournisseurs. Le MOE assure leur coordination ; il veille à la cohérence des fournitures et à leur
CHAHIE THOMAS PAULIN Page 15
compatibilité. Il coordonne l’action des fournisseurs en contrôlant la qualité technique, en
assurant le respect des délais fixés par le MOA et en minimisant les risques.
Le MOE est responsable de la qualité technique de la solution. Il doit, avant toute livraison
au MOA, procéder aux vérifications nécessaires (« recette usine »).
Les interactions entre les différents acteurs a pour base contractuelle le cahier de charge.

III Le cahier de charges

III.1 Type de cahier de charges

Dans le domaine du développement logiciel, il existe deux principaux cahiers de charges :
 Le cahier de charges fonctionnelle: qui permet de définir l'ensemble des
fonctionnalités que le logiciel doit posséder., les conditions qu'il doit remplir
(système(s) d'exploitation visé(s)), les écueils à éviter, ainsi que les délais impartis,
éventuellement des clauses sur le coût, les langages à utiliser, ... . Ce cahier est ainsi
distribué à différentes sociétés de services (dans le cas d'une sous-traitance) sous
forme d'un appel d'offre, auquel les sociétés vont répondre par un coût, un délai, ...).
Il importe de souligner que ce dernier doit être construit prioritairement par le
client(MOA)
 Le cahier de charges utilisateur : encore appelé document de conception qui contient
le modèle du système à réaliser. Ce modèle permet de :
 de présenter au client la façon de laquelle elle compte développer le logiciel
 d'accorder tous les acteurs du projet

III.2 Spécification logicielle

De manière générale une spécification décrit les caractéristiques attendues (le quoi), d’une
implantation (le comment). Les spécifications interviennent à plusieurs niveaux :
 La spécification des besoins ou spécification des exigences (‘requirements’) : est un
contrat entre les futurs utilisateurs et les concepteurs. Elle concerne les
caractéristiques attendues (exigences fonctionnelles et non fonctionnelles :
efficacité, taille, sûreté, sécurité, portabilité, etc.). Elle intervient pendant la phase
d’Analyse des besoins et se rédige en langue naturelle.
 La spécification d’un système est un contrat entre les futurs utilisateurs et les
concepteurs. Elle concerne la nature des fonctions offertes, les comportements
souhaités, les données nécessaires, etc. Elle intervient pendant la phase d’Analyse du
système.
 La spécification d’une architecture de système est un contrat entre les concepteurs et
les réalisateurs. Elle intervient pendant la phase de Conception générale. Elle définit
l’architecture en modules de l’application à réaliser.
 La spécification technique d’un module, d’un programme, d’une structure de
données ou d’un type de données est un contrat entre le programmeur qui l’implante
et les programmeurs qui l’utilisent. Elle intervient pendant la phase de Conception
détaillée.
Il est souhaitable que le document de spécification respecte les conditions suivantes :
 Chaque spécification est claire, non ambiguë et compréhensible.

CHAHIE THOMAS PAULIN Page 16

  Les spécifications doivent aussi être cohérentes (pas de contradictions) et complètes.
La complétude peut prendre deux formes:
 ‘interne’, c’est à dire que tous les concepts utilisés sont clairement spécifiés,
 ‘externe’, par rapport à la réalité décrite. Cette seconde forme est quelque peu
illusoire dans la pratique. On ne peut pas en général spécifier tous les détails ou tout
le ‘monde’ qui entoure un système.
Il y a deux critères de classification orthogonaux :
 La formalité : on distingue des spécifications informelles (en langue naturelle), semi
formelles (souvent graphiques, dont la sémantique est plus ou moins précise),
formelles (quand la syntaxe et la sémantiques sont définies formellement par des
outils mathématiques).
 Le caractère opérationnel ou déclaratif : les spécifications opérationnelles décrivent
le comportement désiré par un modèle qui permet d’une certaine manière de le
simuler; par opposition, les spécifications déclaratives décrivent seulement les
propriétés désirées.

IV Des techniques de spécification pour les phases d’analyse

IV.1 Les spécifications en langue naturelle
Elles sont très souples, conviennent pour tous les aspects, sont très facilement
communicables à des non spécialistes. Mais elles manquent de structuration, de précision et sont
difficiles à analyser.
Des efforts peuvent être faits pour les structurer (spécifications standardisées) : chapitres,
sections, items, justifications (‘rational’), etc.

IV.2 Les spécifications techniques dans des langages spécialisés ou des

langages informatiques de haut niveau
Des langages semi formels spécialisés pour spécifier des systèmes ont été proposés. Ils
comportent des sections et champs prédéfinis, ce qui force à une certaine structuration.
Certains utilisent aussi des langages de haut niveau comme des ‘pseudo codes’ pour
décrire les fonctionnalités attendues.
Il existe d’autres techniques de spécification tel que :
 Les diagrammes à flots de données
 Les machines à états finis
 Les schémas entité/Association
 Les spécifications formelles.

V ESTIMATION DE CHARGE
La charge d’un logiciel se définit comme étant la quantité de travail qu'une personne peut
réaliser. Elle s’exprime en jour / homme, mois / homme, année / homme.
Remarque: Un mois vaut en général 20 jours.
La Taille du projet: la taille du projet se mesure à sa charge.

CHAHIE THOMAS PAULIN Page 17

 Ordre de grandeur Type de projet
Charge < 6 M/h très petit projet
6 M/h ≤ charge ≤ 12 M/h petit projet
12 M/h ≤ charge ≤ 30 M/h projet moyen
30 M/h ≤ charge ≤ 100 M/h grand projet
100 M/h ≤ charge très grand projet
Figure 1: Ordre de grandeur selon les normes ISO

La durée dépend de la charge et du nombre de personnes infectées.

Exemple: 60 M/h peut être 1 personne pendant 5 ans ou 10 personnes pendant 6 mois ou
60 personnes pendant 1 mois.
Il existe différentes méthodes d'estimation de charge

V.1 La non méthode

Exemple: répondre à une offre avec un prix bas pour être sûr de l'avoir, mais sans être sûr d'y
gagner quelque chose en définitive (au point de vue financier).

V.2 Méthode Delphi

Elle est basée sur l'expérience des experts du domaine. Le Principe est:
 Chaque expert propose une estimation basée sur son expérience.
 On publie le résultat (anonyme).
 Les experts sont invités à modifier ou à maintenir leurs estimations.
 On publie les résultats nominaux.
 Les experts refont la troisième étape.
 On analyse les disparités, on calcule la moyenne.

V.3 Méthode de répartitions proportionnelle

Elle s'appuie sur le découpage du projet en différentes phases. On commence par faire
l'estimation de la charge globale. Ensuite, on détermine la charge pour chaque phase du cycle de
vie.
Etape Ratio
Etude préalable 10 % de la charge totale
Etude détaillée 20 à 30 % de la charge totale
Etude technique 5 à 15 % de la charge "réalisation"
Réalisation 2 fois la charge "étude détaillé"
Mise en œuvre 30 à 40 % de la charge "réalisation"
1) Méthode COCOMO
Elle a été Proposée par B.W. Boehm en 1981 (Construct Cost Model)" et est fonction des
hypothèses:
 Il est facile à un informaticien d'estimé le nombre de lignes source.
 La complexité d'écriture d'un programme est la même quel que soit le langage de
programmation.
Il propose une méthode basée sur la corrélation entre la taille d'un projet et sa charge. Cette
formule est:
CHAHIE THOMAS PAULIN Page 18
  Charge = a . (K isl)b
 Délai = c . (Charge)d
 Taille moyenne d'équipe = Charge / Délai
Avec: K isl nombre de milliers de lignes sources. Les paramètres a, b, c et d qui dépendent de
la catégorie du projet.
Type de projet Charge en M/h Délai en M
Simple (< 50 000 lignes) a = 3.2 c = 2.5
b = 1.05 d = 0.38
Moyen (50 000 ≤ lignes ≤ 300 000) a=3 c = 2.5
b = 1.12 d = 0.35
Complexe (> 300 000 lignes) a = 2.8 c = 2.5
b = 1.2 d = 0.32

VI Les méthodes d’analyse et de conception

Les méthodes d’analyse et de conception fournissent une méthodologie et des notations
standards qui aident à concevoir des logiciels de qualité. Il existe différentes manières pour classer
ces méthodes, dont :
La distinction entre composition et décomposition : Elle met en opposition d’une part les
méthodes ascendantes qui consistent à construire un logiciel par composition à partir de modules
existants et, d’autre part, les méthodes descendantes qui décomposent récursivement le système
jusqu’à arriver à des modules programmables simplement.
La distinction entre fonctionnel (dirigée par le traitement) et orientée objet : Dans la
stratégie fonctionnelle (également qualifiée de structurée) un système est vu comme un ensemble
hiérarchique d’unités en interaction, ayant chacune une fonction clairement définie. Les fonctions
disposent d’un état local, mais le système a un état partagé, qui est centralisé et accessible par
l’ensemble des fonctions. Les stratégies orientées objet considèrent qu’un système est un
ensemble d’objets inter-agissants. Chaque objet dispose d’un ensemble d’attributs décrivant son
état et l’état du système est décrit (de façon décentralisée) par l’état de l’ensemble. Cette approche
rapproche étude de données et de traitements. Un objet est caractérisé par plusieurs notions :
L’identité – L’objet possède une identité, qui permet de le distinguer des autres objets,
indépendamment de son état. On construit généralement cette identité grâce à un identifiant
découlant naturellement du problème (par exemple un produit pourra être repéré par un code, une
voiture par un numéro de série, etc.)
Les attributs – Il s’agit des données caractérisant l’objet. Ce sont des variables stockant des
informations sur l’état de l’objet.
Les méthodes – Les méthodes d’un objet caractérisent son comportement, c’est-à-dire
l’ensemble des actions (appelées opérations) que l’objet est à même de réaliser. Ces opérations
permettent de faire réagir l’objet aux sollicitations extérieures (ou d’agir sur les autres objets). De
plus, les opérations sont étroitement liées aux attributs, car leurs actions peuvent dépendre des
valeurs des attributs, ou bien les modifier.
La Conception Orientée Objet (COO) est la méthode qui conduit à des architectures
logicielles fondées sur les objets du système, plutôt que sur la fonction qu’il est censé réaliser.

CHAHIE THOMAS PAULIN Page 19

 Quel que soit la méthode utilisée, les AGL peuvent être utilisé efficacement pour la réalisation
du système.

CHAHIE THOMAS PAULIN Page 20

 Les AGL
Un Atelier de Génie Logiciel (AGL) est un outil informatique aidant à la production d'un
logiciel. Il assiste la démarche de Génie Logiciel poursuivie. Le terme anglais est plus explicite CASE
tools (Computer Aided Software Engineering). L’objectif d’un AGL est l’automatisation maximale
du processus d’une partie ou tout le processus de développement du logiciel.

I Catégories d’AGL
Les AGL peuvent être classés selon plusieurs aspects :
 richesse du support : ensemble d'outils, outils intégrés, aide à la démarche.
 type de problèmes : logiciels embarqués, temps réel, "business applications", applications
métiers …
 „type de projet d’ingénierie logicielle : développement logiciel (cf. cycle de vie), intégration
de systèmes, système à base de connaissance.
 „Ampleur du projet : complexité, nombres de participants, durée ...
 „Gestion des ressources du projet : les considérations managériales des ressources mises
en œuvre dans le projet sont elles prises en compte ? (planification, ordonnancement, …).
 Phase du cycle de développement prises en compte : conception et/ou développement.
La classification basée sur le cycle de développement pris en compte distingue deux types
d’AGL comme le montre la figure ci-dessous :

II AGL orientée conception

Les principales caractéristiques des AGL orientées conception sont entre autres :
 Assistent la phase initiale du projet de développement.
 Fortement basé sur des paradigmes (Orienté Objet), des méthodes de conception et les
formalismes associés (ex : RUP/UML, Merise/E-R, ...).
 Proposent des outils d'éditions graphiques de ces formalismes.
 Proposent une assistance pour la génération de documentation.

CHAHIE THOMAS PAULIN Page 21

  Peuvent proposer un outil de prototypage (génération automatique partielle de code)„ et
éventuellement de reverse engineering (création de représentations graphique dans un
formalisme donné à partir de code source existant).
 Participent à toutes les phases de développement et maintiennent la cohérence entre les
phases.

Exemple: Win design, Power Designer, Power AMC, Rational Rose, Argo UML

III AGL orientée Réalisation

Le niveau d’assistance des outils dans le développement des logiciels se situe à plusieurs
niveaux:
 Outils de développement : éditeur, compilateur, debugger, profiler, gestion de version,
multi-utilisateurs.
 „Environnements de Développement Intégré : idem mais regroupés au sein d'une seule
interface et intégrés entre eux. Ex : Turbo C++.
 „Environnement de Développement Rapide : idem avec facilité d'automatisation de
certaines tâches de programmation (e.g. interfaces graphiques). Ex : Visual x, JBuilder,
NetBeans, Eclipse ...
 „Atelier de Génie Logiciel : idem avec support étendu aux autres phases du cycle de
développement du logiciel (spécification, conception, déploiement …). Ex: WinDe

CHAHIE THOMAS PAULIN Page 22

 Exercice

A- Définition: Génie Logiciel, cycle de vie d'un logiciel, abstraction, prototypage, maquettage.

Le génie logiciel est l’art de spécifier, de concevoir, de réaliser et de faire évoluer, avec des
moyens et dans un délai raisonnable, des programmes, des documents et des procédures de
qualité en vue d’utiliser un ordinateur pour résoudre certains problèmes du monde réel.

L'abstraction signifie que l'on se concentre sur ce qu'est un objet et ce qu'il fait en mettant
l'accent sur ses propriétés essentielles, inhérentes (dans le domaine d'application), et en
ignorant les propriétés accidentelles (ce qui relève des détails d'implantation).

Le cycle de vie du logiciel

Le cycle de vie du logiciel passe par les phases (ou étapes) suivantes :

 Étude de faisabilité ;
 Spécifications ;
 Production ;
 Contrôles ;
 Essais ;
 Contrôle de la production ;
 Vente/utilisation/entretien ;

Pour mieux maîtriser le processus développement on se réfère à des modèles de cycle de vie,
permettant de prendre en compte, en plus des aspects techniques, l'organisation et les aspects
humains.

Le maquettage est une technique qui permet de surmonter la difficulté de spécification du

logiciel due à la différence de terminologie et au manque de précision dans l'expression des
besoins.

Le prototypage rapide, connu également sous le nom de STÉRÉOLITHOGRAPHIE, est une

technique qui permet de construire physiquement un objet 3D à partir d'un fichier numérique
CAO 3D. Le prototype obtenu est fidèle au modèle numérique peu importe sa complexité.

La maquette : elle est considérée comme exploratoire si elle est utilisée pour préciser les besoins
des utilisateurs, ou expérimentale si elle intervient lors de la conception pour aider à
expérimenter différents choix.

B-)
1 Ecriture d’un rapport au directeur de la société, lui expliquant pourquoi son entreprise
doit basculer au modèle « rapid prototyping ». Notre rapport doit être succinct et attirer
l’attention du directeur quant au changement de modèle de développement.
CHAHIE THOMAS PAULIN Page 23
A Monsieur le Directeur de la Société

Monsieur, je viens respectueusement auprès de votre bienveillance, vous faire une proposition
dans le but d’améliorer le modèle de développement de la société qui actuellement est le modèle
« waterfall » par le modèle « rapid prototyping » pour la raison suivante:
le modèle « rapid prototyping permet d'obtenir, au cours du cycle de développement de
produit, dans des délais très courts, à moindre coût et avec le minimum d'outillage, un modèle
qui servira à la validation de la conception d'un point de vue esthétique, géométrique,
fonctionnel ou technologique.

Les avantages dudit modèle sont les suivants :

L'avantage du « rapid prototyping » est la réduction des délais de fabrication. Plus la pièce est
complexe et plus la différence avec une fabrication traditionnelle s'accroît. De plus, le
prototypage rapide apporte de nouvelles possibilités de fabrication et de mise en forme des
matériaux en réalisant des pièces sans moule ni matrice. Cette technique intègre trois notions
fondamentales : temps, coûts et complexité des formes.

• Temps : réaliser rapidement dans un délai très court des modèles physiques, permettant ainsi
la réduction du temps de développement de produit.

• Coût : réaliser des modèles physiques sans avoir la nécessité d’utiliser des moyens coûteux.
Autrement, utiliser un minimum d’outillage dans les étapes intermédiaires de développement de
produit.
• Complexité des formes : réaliser des modèles physiques peu importe leur complexité qui
pourront parfois être irréalisables par l’usinage.

Avantages productifs :

• Détecter des problèmes de conception,

• Tester des solutions alternatives,
• Valider la faisabilité industrielle,
• Optimiser les formes et le coût d’outillage,
• Minimiser les risques de modification,
• Affiner les caractéristiques opérationnelles,
• Disposer d'un objet support,
• Réaliser des tests mécaniques et thermiques, etc.
• Disposer d'un objet support et éviter ainsi des éventuels conflits.

Avantages commerciaux :

• Permet de faciliter le processus de mise en marché,

• Sert à l’élaboration des documents promotionnels,
• Expositions et foires commerciales (trade shows),
• Tests en situations réelles par des clients potentiels,
• Peut faire patienter certains clients pressés, etc.

CHAHIE THOMAS PAULIN Page 24

Après tous ces avantages cités ci-dessus, j’ose croire que votre décision sera la bonne, que vous
accepteriez quele modèle « waterfall » soit remplacer par le modèle « rapid prototyping ».

2) Description du type de situation dans laquelle nous pensons que le modèle « waterfall » peut
être source de problèmes

 Bien que dans une étape les activités peuvent être conduites en parallèle, le
modèle waterfall est fondamentalement séquentielle. Quelques experts en matière
d'innovation croient que le développement de produit devrait être organisé réellement
en parallèle, utilisant des boucles.
 Le cadre originel de Passage d'Etape n'a pas traité le procédé de découverte et les
activités pour créer de nouvelles idées.
 Une tension existe entre l'organisation et la créativité. Tous les deux sont très
importants dans l'innovation.

Exercice 1

Donner une spécification :

1) d’une liste
2) d’une pile
3) d’un vecteur

LISTE : Structure de données classiques composée d'une tête de liste et d'une queue de liste.
Elle est dite " chainée" lorsqu'elle renferme des pointeurs vers d'autres listes.

PILE : Désigne une architecture fréquente d'informations, dans laquelle les informations les plus
récentes sont les premières à sortir.

VECTEUR : Un vecteur AB va correspondre à tous les bipoints qui sont équivalents au bipoint (A,
B). Désigne également un tableau n'ayant qu'une dimension.

Exercice 2
En génie logiciel, plusieurs travaux ont mené à la définition de la qualité du logiciel en termes de
facteurs, qui dépendent entre autres, du domaine d’application et des outils utilisés.

1. Quelles sont les différentes vues ou classes que peuvent avoir ces facteurs et de qui
dépendent-ils ?

Facteurs de qualité du logiciel

 Qualité externe

CHAHIE THOMAS PAULIN Page 25

 - complétude fonctionnelle: réalise les tâches attendues
- maniabilité : facilité d’utilisation
 Interface utilisateur appropriée
 Documentation complète et précise
 Documentation complète et précise
- fiabilité :
 fonctionne même dans des cas atypiques
 Il ne doit pas causer de dommages physiques ou économiques en cas de défaillance
- adaptabilité: adaptation aux modifications
- Qualité interne
- réutilisation: il doit être possible de faire évoluer le logiciel pour répondre à de nouveaux
besoin
- traçabilité : suivi précis de l’analyse à l’implantation
- efficience : bonne utilisation des ressources matérielles
- portabilité : adaptation à de nouveaux environnements

2. Définir les facteurs suivants et donner leur classe :

a. validité, Extensibilité, réutilisation, compatibilité, efficacité, vérifiabilité,
intégrité, facilité d’emploi, interopérabilité, portabilité.

Validité : aptitude d'un produit logiciel à remplir exactement ses fonctions, définies par le cahier
des charges et les spécifications.

Extensibilité : facilité avec laquelle un logiciel se prête à une modification ou à une extension des
fonctions qui lui sont demandées.

Réutilisation : aptitude d'un logiciel à être réutilisé, en tout ou en partie, dans de nouvelles
applications.

Compatibilité : facilité avec laquelle un logiciel peut être combiné avec d'autres logiciels.

Efficacité : Utilisation optimales des ressources matérielles.

Portabilité : facilité avec laquelle un logiciel peut être transféré sous différents environnements
matériels et logiciels.

Vérifiabilité : facilité de préparation des procédures de test.

Intégrité : aptitude d'un logiciel à protéger son code et ses données contre des accès non
autorisés.

Facilité d'emploi : facilité d'apprentissage, d'utilisation, de préparation des données,

d'interprétation des erreurs et de rattrapage en cas d'erreur d'utilisation.

3. Les facteurs de qualité de logiciel sont parfois contradictoires, Expliquer cette assertion
et donner un exemple.

CHAHIE THOMAS PAULIN Page 26

 Ces facteurs sont parfois contradictoires parce que : le choix des compromis doit s'effectuer
en fonction du contexte. Par exemple, la facilité d'emploi et la fiabilité peuvent être
contradictoires. Dans une application du type « traitement de texte » (resp. pilotage d'usine)
c'est le premier (resp. le deuxième) de ces deux facteurs qui sera favorisé.

4. Que faut il faire pour développer un logiciel ayant les qualités désirés ?

Questions de cours

Répondre de façon claire et concise aux questions suivantes :

a) Le génie logiciel est un domaine de recherche qui a été défini (fait rare) du 7 au 11 octobre
1968, à Garmisch-Partenkirchen, sous le parrainage de l'OTAN. Il a pour objectif de répondre à
un problème qui s'énonçait en deux constatations : d'une part le logiciel n'était pas faible, d'autre
part, il était incroyablement difficile de réaliser dans des délais prévus des logiciels satisfaisant
leur cahier des charges.

b) Le génie logiciel est il une science ? expliquer

Oui le génie logiciel est une science car elle promet de meilleurs logiciels moins chers et sans
erreur, de bonnes raisons pour l’adopter. De plus elle a un cycle de vie.

c) Quelle est la différence entre le développement d’un logiciel et la construction d’un

pont ? y a-t-il des similitudes dans les deux processus ?

Le développement d’un logiciel est abstrait, alors que la construction d’un pont est concrète
.
 Oui il y’a des similitudes dans les deux processus, les deux processus ont les
mêmes étapes de réalisation

d) Quelle est selon vous l’étape la plus importante dans le processus de développement
d’un logiciel ?

Généralement on décompose le projet en 4 grandes étapes à savoir :

 L'analyse de l'existant
 Les choix techniques
 La modélisation
 Le codage du logiciel

L’étape la plus importante dans le processus de développement d’un logiciel est la

MODELISATION puisqu'elle consiste à créer le cœur de l’application.

e) Quelles sont les différentes méthodes de spécification de logiciel que tu connais ?

Donner à chaque fois leurs avantages et inconvénients.

CHAHIE THOMAS PAULIN Page 27

 f) Méthode de spécification

Le terme « méthode de spécification » recouvre :

 une méthode (ordre des tâches préconisé pour réaliser une spécification)
 un langage pour écrire la spécification. Ce langage peut être informel ou formel. Dans ce
dernier cas, on distingue :
o les langages avec une syntaxe formelle
o les langages avec une syntaxe et une sémantique formelles
o des outils d'aide :
 éditeurs
 vérificateurs de syntaxe
 vérificateurs de typage
 prouveurs (en général, la logique sous-jacente au langage de spécification
n'est pas décidable. On est en semi-décidable. Le spécifieur doit intervenir
dans le processus de preuve)
 des « contrôleurs de modèles » (model-checkers)
 des animateurs de spécification

g) Donner les différents types de test d’un logiciel

On distingue, entre autres, les différentes formes de tests suivants :

* Tests d'intégration
* Tests de non-régression
* Tests de performance
* Tests de réception
* Tests de validation
* Tests unitaires

h) Donner les différentes méthodes de développement d’un logiciel

La « méthode de développement rapide d'applications » (en anglais Rapid Application

Development, notée RAD), définie par James Martin au début des années 80, consiste en un
cycle de développement court basé sur 3 phases (Cadrage, Design et Construction) dans un
délai idéal de 90 jours et de 120 jours au maximum.

La méthode DSDM (Dynamic Software Development Method) a été mise au point en s'appuyant
sur la méthode RAD afin de combler certaines de ses lacunes, notamment en offrant un canevas
prenant en compte l'ensemble du cycle de développement.

Les principes fondateurs de la méthode DSDM sont les suivants :

 Une implication des utilisateurs

 Un développement itératif et incrémental
CHAHIE THOMAS PAULIN Page 28
  Une fréquence de livraison élevée
 L'intégration des tests au sein de chaque étape
 L'acceptation des produits livrés dépend directement de la satisfaction des besoins

La méthode du Processus Unifié (UP pour Unified Process) est un processus de développement
itératif et incrémental, ce qui signifie que le projet est découpé en phases très courtes à l'issue
de chacune desquelles une nouvelle version incrémentée est livrée. Il s'agit d'une démarche
s'appuyant sur la modélisation UML pour la description de l'architecture du logiciel
(fonctionnelle, logicielle et physique) et la mise au point de cas d'utilisation permettant de
décrire les besoins et exigences des utilisateurs.

RUP (Rational Unified Process) est une méthode de développement par itérations promue par la
société Rational Software, rachetée par IBM. RUP propose une méthode spécifiant notamment
la composition des équipes et le calendrier ainsi qu'un certain nombre de modèles de
documents.

La méthode XP (pour eXtreme Programming) définit un certain nombre de bonnes pratiques

permettant de développer un logiciel dans des conditions optimales en plaçant le client au cœur
du processus de développement, en relation étroite avec le client.

L' eXtrême Programming est notamment basé sur les concepts suivants :

 Les équipes de développement travaillent directement avec le client sur des cycles très
courts d'une à deux semaines maximum.
 Les livraisons de versions du logiciel interviennent très tôt et à une fréquence élevée pour
maximiser l'impact des retours utilisateurs.
 L'équipe de développement travaille en collaboration totale sur la base de binômes.
 Le code est testé et nettoyé tout au long du processus de développement.
 Des indicateurs permettent de mesurer l'avancement du projet afin de permettre de
mettre à jour le plan de développement.

CHAHIE THOMAS PAULIN Page 29