Chapitre 1 - Ingénierie Du Logiciel

Cours d’Ingénierie du Logiciel
Chapitre 1. Concepts du Génie Logiciel
« Le logiciel est l'ensemble des programmes, procédés et règles, et

éventuellement de la documentation, relatifs au fonctionnement d'un
ensemble de traitements de l'information' »
Un logiciel pourra donc être considéré comme un ensemble de programmes

informatiques (codes sources, éditables, exécutables), mais également les
données qu’ils utilisent et les différents documents se rapportant à ces
programmes et nécessaires à leur installation, utilisation, développement et
maintenance : spécifications, schémas conceptuels, jeux de tests, mode
d'emploi, etc.
1.1. Un peu d’historique
 En 1936, Alan Turing (un brillant étudiant en mathématiques à Cambridge

en Angleterre, âgé de 24 ans qui cherchera à construire un cerveau
artificiel), propose dans un article, tout d'abord de formaliser la notion
d'algorithme grâce à la définition d'un dispositif abstrait que depuis on
appelle « machine de Turing ». Ce sera le modèle de base qui fonde
l'informatique moderne. Une machine de Turing sera vue comme une
méthode de calcul, un programme.
Programmer (écrire un programme) consiste à écrire une suite
d'instructions pour réaliser un traitement sur des données.
 Les langages de programmation (« intermédiaire » entre le «

programmeur » et la « machine ») vont évoluer dans le temps, au fur et à
mesure des besoins en termes de qualité, et pour pouvoir faire face aux
problèmes de plus en plus complexes.
- Langages de 1ère génération (1954 – 1958 : Fortran I, Algol 58, …)
Elvis Noël IRAMBONA, MSc.
1
- Langages de 2ème génération (1959 – 1961 : Fortran II, Algol60, Cobol,

Lisp, …)
- Langages de 3ème génération (1962 – 1970 : PL1, Algol68, Pascal, Simula,
…)
- Langages de 4ème génération (1970 – 1980 : Smaltalk, Ada, C++)
- Langages de 5ème génération (année 80 et 90 : Eiffel, Yafool,
Objloo, Art, Ulysse, NewFlavors, Neon, Java, …)
 La Complexité du développement des Logiciels étant également liée au

matériel, on note également une évolution des systèmes matériels :
Après l’architecture de Von Neumann, à la base de toutes les architectures

modernes, les systèmes matériels vont également évoluer rapidement
dans le temps, pour permettre de développer des solutions de plus en plus
performantes ; avec au centre le processeur (entité capable d’interpréter
et exécuter un traitement ou processus).
Au cours des années 70, on observe une révolution avec la création des
microprocesseurs (1974 = Intel, 1982 = RISC, 1984 = 88020, etc.).
L’explosion qui va suivre dans les années 80 entraînera une baisse
permanente des coûts du matériel.
1.2. Temps de Crises :
 Malgré les évolutions citées plus haut, on note qu’au fur et à mesure que
les coûts du matériel diminuent, les coûts des programmes informatiques
(curieusement) augmentent !
La diminution des coûts du matériel (hardware) a conduit à associer
l’ordinateur à de plus en plus de produits. Les coûts des logiciels
connaissent une très forte croissance, dominant maintenant le coût du

2
matériel et peuvent représenter plus de 80 % du coût total d’un système

informatique.
 A la fin des années 70, on ne sait pas « faire » des logiciels (plusieurs
tentatives de logiciels vont échouer)
- Les besoins et contraintes de l’utilisateur ne sont pas respectés (pas de
facilité d’emploi, interfaces homme/machine inexistantes)
- Les coûts ne sont pas maîtrisés
- On relève régulièrement des retards dans la livraison des produits (non
maîtrise du temps)
- On note une grande rigidité dans les solutions mises en place
- Quelque fois on arrive à des incohérences pendant l’utilisation
- On est aussi confronté au manque de performance et de robustesse
(fiabilité)
- Les codes sont difficiles à maintenir
- On arrive parfois à des logiciels non utilisables
 En 1983, on se rend compte que :

- 43% des logiciels sont livrés et non utilisés
- 28% payés et non livrés
- 19% utilisés tels quels
- 3% utilisés sans modification (échec de tentative)
- 2% utilisés avec modifications (réussite de tentative)
 Les coûts de maintenance (lorsque cela se fait) dépassent ceux du

développement
 Le coût d’une erreur parfois dépasse le coût du système
 Les pannes causées par le « bug de l’an 2000 » ont coûté environ 175
milliards de dollars aux entreprises du monde, (Le Monde – 23 oct. 2001).

3
 D’une étude sur 487 sites de toutes sortes de développement de

logiciels, il ressort que :
- 70% du coût du logiciel est consacré à sa maintenance
- 42% des modifications sont dues à des demandes de l’utilisateur
- 30% des exigences de spécification changent entre la 1ère édition d’une
documentation et la première sortie du produit
- 17% à des changements de format des données
- 12% problèmes d’urgence résolus à la hâte
- 9% débogages de programmes
- 6% à des changements de matériel
- 6% problèmes de documentation
- 4% améliorations de l’efficacité
- 3% autres…
Ces différents problèmes vont conduire à la création du Génie Logiciel.
1.3. Le Génie Logiciel
Le Génie Logiciel est défini le 30 décembre 1983 comme étant « l’ensemble des
activités de conception et de mise en œuvre des produits et des procédures
tendant à rationnaliser la production du logiciel et son suivi ».
 Objectifs :
- Maîtriser les coûts et les délais de développement
- Améliorer la productivité (de l’équipe de développement)
- Fournir une assurance qualité du produit livré
Le génie logiciel s’intéresse :

- aux différentes théories
- aux méthodologies : (techniques, méthodes)
4
- aux outils
- à l’organisation générale
- à la gestion de projets
En bref, le Génie Logiciel c’est l’ensemble des méthodes, outils et techniques

utilisées pour développer et maintenir du logiciel dans le but d’assurer la
qualité et la productivité. C’est donc l’art de la construction du logiciel.
Le génie logiciel est basé sur des méthodologies et des outils qui permettent de
formaliser et même d'automatiser partiellement la production de logiciels, mais
il est également basé sur des concepts plus informels, et demande des capacités
de communication, d'interprétation et d'anticipation. De fait, la « crise du logiciel
» n'est pas complètement résolue aujourd’hui. Le génie logiciel reste un « art »
qui demande de la part de l'informaticien une bonne formation aux différentes
techniques (le savoir), mais également un certain entrainement et de
l'expérience (le savoir-faire).
1.4. Le processus logiciel, ou cycle de vie du logiciel
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.
L'objectif d'un tel découpage est de permettre de définir des jalons
intermédiaires permettant la validation du développement logiciel, c'est-à-dire
la conformité du logiciel avec les besoins exprimés, et la vérification du
processus de développement, c'est-à-dire l'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.

5
Historiquement, le premier modèle de développement proposé (1966) est celui

dit en ``cascade'', formalisé en 1970. Ce modèle a été assez largement mis en
œuvre, mais on s'est rapidement aperçu qu'il n'est pas toujours approprié. Sa
vision simpliste du processus sous-estime le coût des retours en arrière dans le
cycle de vie. Ainsi, plusieurs alternatives au modèle en cascade ont été
proposées, basées notamment sur le prototypage et l'assemblage de
composants réutilisables.
Le cycle de vie du logiciel comprend généralement au minima les activités

suivantes :
 Définition des objectifs, consistant à définir la finalité du projet et son

inscription dans une stratégie globale.
 Analyse des besoins et faisabilité, exprimer, recueillir et formaliser les
besoins du demandeur (le client) et de l'ensemble des contraintes.
 Spécification, définir le quoi du logiciel après dialogue avec le client. On
donne ici les contraintes de temps, etc. Cette phase débouche
généralement sur un document de spécification (Software Requirement
Analysis - SRA). Le SRA doit dégager clairement les fonctions, les interfaces
(machines, utilisateurs, environnement), les contraintes (performance,
mémoires, logiciels, machine).
 Conception générale. formaliser les spécifications élaborées de
l'architecture générale du logiciel.
 Conception détaillée, indiquer le comment, définir de façon précise
chaque sous-ensemble du logiciel. Ces deux phases débouchent
généralement sur un document de conception (Software Design Report -
SDR).

6
 Codage, réaliser (programmer) ou codifier dans un langage de

programmation des fonctionnalités définies lors de phases de conception.
Cette phase débouche sur un ensemble de codes (Programme).
 Tests unitaires, vérifier individuellement que chaque sous-ensemble du
logiciel est implémenté conformément aux spécifications.
 Intégration, s'assurer de l'interfaçage des différents éléments (modules)
du logiciel. Les tests d'intégration (et même parfois unitaires) seront
consignés dans un document rapport (Software Test Report – STR).
 Qualification, vérifier la conformité du logiciel aux spécifications initiales,
procéder aux tests (on teste à l’atelier, puis par la suite chez le client -
livraison).
 Documentation, produire les informations nécessaires pour l'utilisation
du logiciel et pour des éventuelles évolutions futures.
 Mise en production, livrer et valider le produit.
 Maintenance, entreprendre des actions correctives (maintenance
corrective) et évolutives (maintenance évolutive) sur le logiciel.
En fonction du choix d'un modèle de cycle de vie entre le client et l'équipe de

développement, on aura un séquencement ou la présence de chacune de ces
activités dans le cycle de vie correspondant.
Par exemple, dans le modèle en V, les procédures de vérification de la

conformité du logiciel aux spécifications sont supposées être élaborées dès les
phases de conception.

7
1.5. Représentations des modèles de développement
1.5.1. Modèle Exploratoire
Cette approche est essentiellement informelle.
Figure : Modèle exploratoire
1.5.2. Modèle Cascade
Le modèle en cascade est présenté ci-dessous. Il faut noter que dans ce modèle,
une modification dans une étape « N » ne remet en cause que l’étape « N-1 ».
Figure : Modèle Cascade
1.5.3. Modèle en V
Le Schéma du modèle en V est présenté ci-dessous.

8
Figure : Modèle en V
Dans le modèle en cascade, chaque spécification faite aux étapes de gauche doit
correspondre à une procédure de test (jeu de test à décrire) pour s’assurer que
le composant correspond à la description faite aux étapes de droite.
1.5.4. Modèle en spirale
Ce modèle propose de généraliser les deux précédents. Il a été proposé par B.

Boehem en 1988.
- Dans le premier tour, on détermine les objectifs du cycle, les alternatives, les
contraintes en s’appuyant sur les cycles précédents, ou sur une analyse primaire.
- Dans le premier tour : analyser les risques, évaluer les alternatives, proposer
un maquettage.
- Dans le deuxième tour : s’occuper du développement et de la vérification de la
solution retenue en cours.
- Dans le troisième tour : passer en revue les résultats du cycle précédent et
planifier le cycle suivant.

9
Figure : Modèle en spirale
1.5.5. Modèle Incrémental
Dans cette méthode, on évolue par incréments, en partant d’un noyau de base
qui est par la suite complété progressivement. Généralement, une bonne
planification et une spécification rigoureuse sont nécessaires, ainsi qu’une
bonne planification et une forte indépendance au niveau fonctionnel et au
niveau du calendrier.

10
Figure : Modèle Incrémental
1.6. Méthodes
Dans l’Ingénierie d’un système logiciel, on retrouve les méthodes et outils

servant tout au long du processus de développement.
On peut y retrouver au moins 4 types de méthodes :
 Méthodes de planification stratégique du développement des systèmes

applicatifs.
Il s’agira de définir un processus décisionnel en se basant sur :
- Une politique informatique (mission ? objectifs ? règles ?)
- Une stratégie informatique (projets ? budgets ?)
- Une tactique informatique (faire plus avec moins)
- Une action informatique (exploitation courante)
 Méthodes de développement proprement dit.

- Spécification des besoins
- Conception générale et détaillée
- Réalisation
- Installation : mise en exploitation, gestion des versions, apprentissage,
suivi de fonctionnement et d’utilisation

11
- Maintenance
 Méthode de conduite des projets.

Il s’agit d’estimer les moyens prévisionnels, les délais et les coûts
- planification
- évaluation des charges, coûts et moyens
- animation et conduite des travaux lors des étapes du cycle de
développement
- choix des méthodes à utiliser
- contrôle d’avancement et d’exécution de tâches
- organisation générale du projet
- gestion des relations contractuelles avec les utilisateurs
- définition des profils des participants au projet
- gestion et formalisation des dossiers
- gestion des relations contractuelles avec les fournisseurs
- suivi analytique des projets
 Méthodes d’assurance qualité

D’après l’AFNOR (Association française de normalisation), c’est « l’attitude
du produit à satisfaire les besoins (exprimés) des utilisateurs ».
Comment peut-on obtenir la qualité ?

- Définir clairement des exigences de sortie
- Mesurer la conformité à chaque phase
Cela implique 4 grands temps :
- Définition du processus et orientation de l’action qualité

o Diagnostic de la non qualité : problèmes, causes, poids, coûts, gain
attendu de son éradication
o Manuel qualité (spécifique au logiciel à réaliser)
12
o Plan qualité : politique, priorités, action, budgets, plannings,

stratégies de conduite (pourrait servir pour n’importe quelle
entreprise)
o Fonction qualité
- Mise en œuvre du processus et Action qualité (qui ?, comment ?, quand

?)
o Définition des normes de qualité (par thème, type de projet, secteur
d’activité)
o Cahier de charges qualité : par projet
o Plan d’assurance qualité du projet selon les aptitudes requises
(fiabilité, temps de réponse, …)
o Contrat client-fournisseurs
o Maquettage, prototype et simulation
o Revues et inspection des étapes de l’analyse des besoins au codage
o Règles et procédures de tests : étapes de test, construction des jeux
d’essai, outils et méthodes de tests, délais, niveau de test à atteindre
o Qualimétrie du logiciel : évaluation de la complexité du logiciel,
difficulté de maintenance, risques
o Recette de qualification : inspection par le client, conformité par
rapport au cahier de charges fonctionnel, au cahier de charges qualité
o Gestion opérationnelle de la qualité : suivi périodique des actions
qualité, des fournisseurs de l’application des plans d’assurance
qualité, de l’évolution de la non qualité
- Mesure de conformité et Animation de l’action qualité. Il s’agit

beaucoup plus de mobiliser des informations et les partenaires,
notamment :
o En créant les événements spécifiques
13
o En amenant le maximum d’acteurs à participer

o En respectant les valeurs individuelles et la confiance
- Amélioration par des moyens divers pouvant contribuer à la réussite

des trois autres volets
o Financiers
o Humains
o Techniques (logiciels, matériels, documentation)
En définitive, il s’agit de satisfaire les besoins de l’utilisateur au sens large.
La qualité peut être « prouvée » en maîtrisant les paramètres tels que les coûts,
les délais. On doit pouvoir la mesurer ou tout au moins la quantifier.
1.7. La Spécification
La phase la plus délicate dans le processus de développement du logiciel, c’est

celle des spécifications.
Bertrand Meyer a défini les 7 pièges qui guettent lors d’un processus de
spécification, mais également les 7 mots clés de réussite.
1.7.1. Les 7 pièges :
- Bruit : élément qui n’apporte aucune information (!) / redondance (!)
- Silence : caractéristique d’un problème auquel ne correspond aucune

partie du texte
- Sur spécification : lorsqu’on se lance dans un développement qui donne

des détails inutiles (par exemple anticiper sur les tables de la BD…)
- Contradiction : dans les séquences de spécification

14
- Ambiguïtés : une phrase peut avoir 2 ou plusieurs sens
- Référence en avant : étant à une page, vous faites allusion à un concept

qui sera présenté plus loin
- Vœu pieux : attention à des éléments non vérifiables (!)
1.7.2. Les 7 caractéristiques d’une bonne spécification :
- Conformité (aux besoins réels et non aux besoins supposés exprimés,

souvent limités)
- Communicable
- Faisable
- Modifiables
- Validable
- Complète
- Cohérente
1.7.3. Les méthodes
Lors de la phase de spécification, nous avons besoin au départ d’interviews bien

faites, pouvant déboucher sur une bonne documentation.
Les méthodes de spécification de logiciels seront de trois catégories :
- Informelle (structurée)
- Semi-formelle
- Formelle (mathématique)

15
Les méthodes de spécification intègrent :
- Modèle
- Démarche
- Langage
- Outils
On pourrait donc très bien leur associer des environnements textuels,

graphiques ou mixtes facilitant la compréhension et l’expression.
 Méthodes Informelles
Elles n’ont pas un formalisme supportant une vérification, une validation

(informatique ou simulation mathématique)
Cas de SADT (dans son approche fonctionnelle), BOOCH (dans son approche
objet initiale), MERISE…
 Méthodes Semi-formelles
Elles permettent des vérifications, mais pas sur tous les aspects.
Cas de SADT avec SART, Réseaux de Petri, …
 Méthodes Formelles
Elles intègrent des langages permettant de définir toutes les contraintes et de

garantir les vérifications et la validation complète. Ces langages basés sur les
mathématiques vont pouvoir prendre en compte n’importe quel concept
abstrait ou logique. Les outils sont :
- Logique
- Algèbre

16
- Mixte, ….
Un exemple : VDM (Vienna Description Method) : il utilise la théorie des

ensembles pour décrire les entités et les objets ; mais aussi les formules de la
logique de prédicats pour spécifier les propriétés (classes, etc.)
1.7.4. Les démarches d’analyse
Lorsqu’on veut modéliser un système, il faut modéliser trois catégories d’entités

:
o Données : aspects statiques, objets

o Fonctions : transformations des données dans le système
o Dynamique : changements dans le temps, contrôles (ex : modéliser les
données en fonction du temps)
La démarche peut être fonctionnelle, objet, modèles, mixte, etc.
 Approche Fonctionnelle
Les données et les fonctions sont modélisées séparément.
Exemples: SADT-SART, etc.
 Approche Objet
Les données et les fonctions sont encapsulées dans les mêmes « boites » qui
dialoguent entre elles (les objets) par envoi de messages.
Exemples: Booch, HOOD, OOA, OMT, UP, etc.
 Approche Modèles
MDE (Model Driven Engineering).
 Approche Agiles

17
Voir méthodes Agiles plus loin.
Dans tous les cas, lors de votre démarche essayez toujours de prendre en compte
:
- Un maximum de modèles de besoins

- Des modèles d’analyse suffisants
- Une représentation des processus (fonctions + données)
- Des modèles de contrôle suffisants
- Une lisibilité claire du dictionnaire de données
- Une bonne illustration des entrées et sorties (éventuellement les temps
de réponse)
1.8. Techniques de Tests
Les chiffres montrent que dans un processus de développement, la phase de test

coute 40% de l’ensemble (avec 40% pour l’analyse et 20% pour le codage). Les
programmes de tests peuvent parfois être plus longs que le programme à tester.
Le concepteur devrait donc y penser dès le départ.
Durant les étapes du cycle de vie, on pourra retrouver des tests aux principales
étapes :
- tests d’unités (centrés sur les composants)
- tests d’intégration (centrés sur les modules)
- tests de validation (vérification des fonctionnalités, performances, …)
- tests de réception (« in situ » avec le personnel)
- tests de régression (suite à des modifications)

18
Les tests doivent permettre de détecter des erreurs ou des insuffisances dans un
logiciel, en se basant sur un référentiel défini au préalable. On retrouve :
- les tests de vérification : il s’agit de s’assurer que le système est conforme aux
spécifications définies initialement.
- les tests de correction : il s’agit de s’assurer que le système fournit des résultats
exacts.
- les tests de validation : il s’agit de s’assurer que le système répond aux attentes
de l’utilisateur et aux contraintes de l’environnement.
Les tests effectués pourront être statiques (porter sur des textes, des
spécifications ou des modules programmes sans les exécuter) ou dynamiques
(porter sur des programmes à exécuter ou sur des séries de données entrées).
 Dans une approche statique, il est recommandé une vérification par

plusieurs personnes (relecture des acteurs de différents niveaux et parfois
même extérieurs au projet) des différents documents d’analyse, de
codage (types de variables, initialisation, portabilité, branchement de
code, incohérences, contraintes sur les attributs d’une table ou d’un
fichier…), les modèles de BD, finition, etc.
 Un gros projet doit absolument avoir un responsable des tests.
 Dans une approche dynamique, il est important d’élaborer un « plan de
tests » et un « dossier de justification » de ceux-ci (choix des tests,
résultats attendus, résultats obtenus, tests exclus pour certaines raisons
telles que le coût ou l’impossibilité physique…)
 Durant les tests, les procédures doivent permettre d’augmenter les
chances de détection de problèmes.
 Dans une approche fonctionnelle :
- Procéder à des tests aléatoires
19
- Les données de test doivent être choisies judicieusement !

- Ne pas se limiter uniquement aux données « normales » ! mais prévoir
des données sensibles pouvant entraîner des exceptions.
 Dans une approche orientée objet par exemple, il est préférable de
décrire les méthodes de test en même temps que les autres méthodes de
la classe, et les encapsuler directement, en indiquant les valeurs attendues
à chaque fois.
 Autres Recommandations :
- Les méthodes de test ne doivent pas être longues et doivent être au
mieux simplifiées. Elles doivent être bien commentées.
- Les jeux de tests doivent être définis clairement et justifiés
- N’hésitez pas à effectuer certains tests au fur et à mesure de la mise en
œuvre
- Certaines méthodes doivent illustrer clairement les modes d’utilisation
des autres méthodes jugées importantes
- En cas de nécessité, faire appel à des générateurs (aléatoires…) de tests
et contrôle de tests automatiques (ex. JTests)
1.9. Processus de test de codes
1.9.1. Problématique :
Beaucoup de langages, à l’instar de PHP sont flexibles, permissifs et faciles à

appréhender. Malheureusement, certains principes qui font la force de certains
langages ne sont pas implémentés dans d’autres langages. Par exemple, la
rigueur et les contraintes de conception généralement imposées dans les
langages à vocation industrielle (C/C++, Java, etc.) ne s'appliquent pas
nécessairement avec des langages comme PHP.

20
Finalement, le programmeur est seul maître à bord, il choisit la précision avec

laquelle il souhaite intégrer un paradigme, tout comme il décide de structurer
ou non son développement par rapport à des processus éprouvés. Cette grande
liberté est à l'origine du succès du langage, mais c'est également son plus grand
défaut.
Beaucoup de développeurs (PHP…) qui n'ont pas de formation spécifique en
programmation ou qui sont peu expérimentés ne perçoivent pas l'importance
d'un processus de développement, et de test en particulier.
L'absence d'une forme structurée de tests engendre notamment les

problématiques suivantes :
Le code source n'est pas testé en profondeur : cela a pour conséquence des
aléas de « post-publication », plus ou moins critiques. Le plus souvent il s'agit
d'instabilités dans l'application ou des problèmes de sécurité classiques.
Le code source n'est pas robuste : toute modification du code source

(refactorisation, ajout de fonctionnalités) est susceptible d'engendrer des
régressions.
Le code source n'est pas réutilisable, pas transmissible : si un autre développeur

doit vous assister ou reprendre votre travail, il sera confronté d'une part à votre
code source et d'autre part à l'absence d'un protocole de test uniformisé.
Le code source n'est pas évolutif : plus votre application aura une structure
complexe plus vous peinerez à déceler des erreurs et problèmes de conception
de manière empirique. Vous serez contraint à moyen terme, de reprogrammer
entièrement votre application.
Tout ceci aura non seulement un impact sur la fiabilité de votre programme (et
vos prestations de service), mais également sur le temps alloué pour le

21
développement et la maintenance du projet, avec les tracas que cela implique

pour vous et vos utilisateurs finaux.
1.9.2. Processus de test :
Nous présentons ci-après un processus et quelques conseils vous permettant

d'utiliser les tests unitaires dans vos projets PHP.
Figure : processus de de développement dirigé par les tests
Le processus qui vous est proposé ci-dessus fait abstraction des contraintes liées
à la gestion de projet (cahier des charges, organisation interne, etc.) ainsi que de
la phase d'analyse. Il est basé sur le développement piloté par les tests (TDD) et
s'adresse particulièrement aux développeurs PHP autonomes.
Si vous développez en équipe, la base restera sensiblement la même mais vous

devrez fournir des précisions au niveau de l'organisation et du partage des
tâches, notamment.

22
Le développement piloté par les tests (Test-Driven Development, ou TDD) est

une méthode de développement mettant les tests unitaires au premier plan, on
peut résumer son processus en cinq étapes :
1 Ajouter un test,
2 vérifier qu'il ne passe pas,
3 implémenter la fonctionnalité,
4 exécuter les tests unitaires - déboguer en cas d'échec,
5 refactoriser le code source - exécuter à nouveau les tests unitaires, passer à
l'objectif suivant...
En reprenant le processus ci-dessus, vous observerez que l'approche TDD débute

dès la phase de conception.
Dans l'idéal, la structure de votre application devrait être modélisée dans un

éditeur UML puis son squelette généré directement dans des fichiers PHP.

23

Chapitre 1 - Ingénierie Du 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 - Ingénierie Du Logiciel

Transféré par

Droits d'auteur :

Formats disponibles

Cours d’Ingénierie du Logiciel

Chapitre 1. Concepts du Génie Logiciel

« Le logiciel est l'ensemble des programmes, procédés et règles, et

Un logiciel pourra donc être considéré comme un ensemble de programmes

1.1. Un peu d’historique

 En 1936, Alan Turing (un brillant étudiant en mathématiques à Cambridge

 Les langages de programmation (« intermédiaire » entre le «

- Langages de 2ème génération (1959 – 1961 : Fortran II, Algol60, Cobol,

 La Complexité du développement des Logiciels étant également liée au

Après l’architecture de Von Neumann, à la base de toutes les architectures

1.2. Temps de Crises :

Elvis Noël IRAMBONA, MSc.

matériel et peuvent représenter plus de 80 % du coût total d’un système

 En 1983, on se rend compte que :

 Les coûts de maintenance (lorsque cela se fait) dépassent ceux du

Elvis Noël IRAMBONA, MSc.

 D’une étude sur 487 sites de toutes sortes de développement de

Ces différents problèmes vont conduire à la création du Génie Logiciel.

1.3. Le Génie Logiciel

Le génie logiciel s’intéresse :

En bref, le Génie Logiciel c’est l’ensemble des méthodes, outils et techniques

1.4. Le processus logiciel, ou cycle de vie du logiciel

Elvis Noël IRAMBONA, MSc.

Historiquement, le premier modèle de développement proposé (1966) est celui

Le cycle de vie du logiciel comprend généralement au minima les activités

 Définition des objectifs, consistant à définir la finalité du projet et son

Elvis Noël IRAMBONA, MSc.

 Codage, réaliser (programmer) ou codifier dans un langage de

En fonction du choix d'un modèle de cycle de vie entre le client et l'équipe de

Par exemple, dans le modèle en V, les procédures de vérification de la

Elvis Noël IRAMBONA, MSc.

1.5. Représentations des modèles de développement

1.5.1. Modèle Exploratoire

Cette approche est essentiellement informelle.

Figure : Modèle exploratoire

1.5.2. Modèle Cascade

Figure : Modèle Cascade

Le Schéma du modèle en V est présenté ci-dessous.

Elvis Noël IRAMBONA, MSc.

1.5.4. Modèle en spirale

Ce modèle propose de généraliser les deux précédents. Il a été proposé par B.

Elvis Noël IRAMBONA, MSc.

Figure : Modèle en spirale

1.5.5. Modèle Incrémental

Elvis Noël IRAMBONA, MSc.

Figure : Modèle Incrémental

Dans l’Ingénierie d’un système logiciel, on retrouve les méthodes et outils

On peut y retrouver au moins 4 types de méthodes :

 Méthodes de planification stratégique du développement des systèmes

 Méthodes de développement proprement dit.

Elvis Noël IRAMBONA, MSc.

 Méthode de conduite des projets.

 Méthodes d’assurance qualité

Comment peut-on obtenir la qualité ?

Cela implique 4 grands temps :

- Définition du processus et orientation de l’action qualité

o Plan qualité : politique, priorités, action, budgets, plannings,

- Mise en œuvre du processus et Action qualité (qui ?, comment ?, quand

- Mesure de conformité et Animation de l’action qualité. Il s’agit

o En amenant le maximum d’acteurs à participer

- Amélioration par des moyens divers pouvant contribuer à la réussite

La phase la plus délicate dans le processus de développement du logiciel, c’est

1.7.1. Les 7 pièges :