Vous êtes sur la page 1sur 23

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
Cours d’Ingénierie du Logiciel

- 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

Elvis Noël IRAMBONA, MSc.


2
Cours d’Ingénierie du Logiciel

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).

Elvis Noël IRAMBONA, MSc.


3
Cours d’Ingénierie du Logiciel

 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)
Elvis Noël IRAMBONA, MSc.
4
Cours d’Ingénierie du Logiciel

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

Elvis Noël IRAMBONA, MSc.


5
Cours d’Ingénierie du Logiciel

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).

Elvis Noël IRAMBONA, MSc.


6
Cours d’Ingénierie du Logiciel

 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.

Elvis Noël IRAMBONA, MSc.


7
Cours d’Ingénierie du Logiciel

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.

Elvis Noël IRAMBONA, MSc.


8
Cours d’Ingénierie du Logiciel

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.

Elvis Noël IRAMBONA, MSc.


9
Cours d’Ingénierie du Logiciel

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.

Elvis Noël IRAMBONA, MSc.


10
Cours d’Ingénierie du Logiciel

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

Elvis Noël IRAMBONA, MSc.


11
Cours d’Ingénierie du Logiciel

- 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)
Elvis Noël IRAMBONA, MSc.
12
Cours d’Ingénierie du Logiciel

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
Elvis Noël IRAMBONA, MSc.
13
Cours d’Ingénierie du Logiciel

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

Elvis Noël IRAMBONA, MSc.


14
Cours d’Ingénierie du Logiciel

- 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)

Elvis Noël IRAMBONA, MSc.


15
Cours d’Ingénierie du Logiciel

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

Elvis Noël IRAMBONA, MSc.


16
Cours d’Ingénierie du Logiciel

- 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

Elvis Noël IRAMBONA, MSc.


17
Cours d’Ingénierie du Logiciel

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)

Elvis Noël IRAMBONA, MSc.


18
Cours d’Ingénierie du Logiciel

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
Elvis Noël IRAMBONA, MSc.
19
Cours d’Ingénierie du Logiciel

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

Elvis Noël IRAMBONA, MSc.


20
Cours d’Ingénierie du Logiciel

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

Elvis Noël IRAMBONA, MSc.


21
Cours d’Ingénierie du Logiciel

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.

Elvis Noël IRAMBONA, MSc.


22
Cours d’Ingénierie du Logiciel

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.

Elvis Noël IRAMBONA, MSc.


23