G.

L Iset Sousse

Chapitre 1
Processus de développement logiciel

I. Le cycle de vie d’un 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.

Analyse des besoins

Specifications

Analyse et
Conception
Implémentation

Validation et
vérification
Maintenance

Figure 2.1 : Processus de développement d’un logiciel

Belarbi K.Manel
G.L Iset Sousse

I.1 Analyse des besoins

C’est l’étape préalable si le client n’a qu’une idée peu précise du système à réaliser. C’est une
étude informelle des fonctionnalités externes du système sans considération technique (de
point de vue métier/utilisateur). Cette étape se base sur le dialogue entre informaticien et
client afin de définir le cahier de charge.

I.2 Spécification

Ce que doit faire le système (coté client).

Dans cette étape, un document doit être produit spécifiant les fonctionnalités attendues du
système. Ce dernier est considéré comme la base du contrat commercial avec le client. Ce
document va définir les frontières du système, la description des fonctionnalités du système
avec des scénarios, interaction et enchaînement d’écran.

Dans le méta-modèle UML, le diagramme « cas utilisation » (Use Case) présente un schéma
simplifié et un support intéressant pour la discussion avec le client.

Remarque : Les spécifications ne sont jamais complète et définitives car les domaines
évoluent rapidement les besoins s’accroient.

I.3 Analyse et conception

Comment faire le système? (choix technique)

C’est l’expertise informatique qui intervient dans cette étape (hors compréhension du client).
Après avoir identifier les élément intervenant dans le système (fonctionnalités, structure et
relation), il faut choisir l’architecture technique (matériel et logiciel) toute en respectant les
critères choisit du système (robustesse, efficacité, portabilité, fiabilité…). Généralement, pour
développer un système assez compliqué, il préférable de le décomposer en plusieurs modules
(qui présentent des fonctionnalités différentes) à savoir l’interface, partie métier (ou
traitement), gestion des données, etc.

Belarbi K.Manel
G.L Iset Sousse

I.4 Codage ou implémentation

C’est l’étape de la création du système proprement dit. Apres avoir choisit l’architecture
technique (langage de programmation, plateforme et logiciels), nous passons au codage.

Souvent trop de temps consacré au codage au détriment des phases de spécification et de

conception (mauvaise pratique parfois très coûteuse) alors que il y a des modèle de
conception qui vous permet de générer le code avec un seul click (si nous choisissons bien
notre méthodologie de conception)!

Le plus important dans cette phase est de réutilisé des composantes existant qui ont été testé et
recommander par d’autre développeur.

I.5 Test, validation et vérification

Test

Le test est une activité importante dont le but est d’arriver à un produit « zéro défaut ».

C'est la limite idéaliste vers laquelle la qualité du logiciel tend. Généralement 40% du Budget
global est consacrée à l’effort de test. Par ailleurs, on distingue différents niveaux de test :

 les tests unitaires pour les composants isolés ;

 les tests d'intégration pour un assemblage de composants ;

Validation

La validation a pour but de répondre à la délicate question : a-t-on décrit le bon système, celui
qui répond à l'attente des utilisateurs ? Elle consiste essentiellement en des revues et
inspections de spécifications ou de manuels et du prototypage rapide.

Belarbi K.Manel
G.L Iset Sousse

Vérification

La vérification répond à la question : le développement est-il correct par rapport à la

spécification globale ? Ce qui consiste à s'assurer les fonctionnalités du logiciel produit
satisfait la spécification globale. Elle inclut des inspections de spécifications et de
programmes ainsi que de la preuve et du test.

I.6 Maintenance

C’est une étape longue (dépend de la période d’utilisation de l’application), critique

(application en plein exploitation) et coûteuse (dépasse parfois le coût de la production) .

Il existe deux types de maintenance:

 La correction des erreurs de système.

 L’évolution du système suite à la modification de l’environnement technique ou
l’ajout de nouvelles fonctionnalités.

II. Modèles de cycle de vie

Afin d'être en mesure d'avoir une méthodologie commune entre le client et la société de
service réalisant le développement, des modèles de cycle de vie ont été mis au point
définissant les étapes du développement ainsi que les documents à produire permettant de
valider chacune des étapes avant de passer à la suivante.

Nous allons présenter deux familles de modèle de cycle de vie. La famille linéaire avec le
modèle de cycle de vie en cascade et le modèle de cycle de vie en « V ». Et la famille cycle de
vie itératif avec le modèle de cycle de vie incrémental (ou spiral).

II.1 Le cycle de vie en cascade (Famille linéaire)

Le style en cascade décompose un projet en fonction des activités inhérentes au
développement logiciel : analyse des besoins, conception, codage et tests (voir Figure II.1).
Dans le processus en cascade, il y a généralement une sorte de barrière formelle entre chaque
phase, mais il n’est pas rare de revenir sur la phase précédente. Durant le codage, un problème
peut surgir qui vous oblige à revoir l’analyse et la conception. Les décisions prises en phase

Belarbi K.Manel
G.L Iset Sousse

d’analyse et de conception seront inévitablement dans les phases ultérieures. Toutefois, ces
retours constituent des exceptions et doivent être évités dans toute la mesure du possible.

Le grand inconvénient de ce modèle de cycle de vie, c’est que il y a aucune validation

intermédiaire après chaque étape et cela augmente le risque de détecter les erreurs de
conception ou spécification tardivement (dans la phase de validation).Cependant ce modèle
reste le plus utilisé pour des petits projets !

Spécification

Conception

Codage

Validation

Maintenance

Figure 2.2 : Modèle en cascade

Avantages Inconvénients
 Production de documentation  Pas prévu de remettre une autre étape que
 Contrôle celle qui la précède
 Validation  Adaptée pour des projets des projets de
 Maintenance facilitée par la petite taille
documentation  La spécification doit être complète dés le
 Largement utilisée début
 Retarde la prise en considération du
facteur risque

Belarbi K.Manel
G.L Iset Sousse

II.2 cycle de vie en « V » (Famille linéaire)

L’objectif de ce modèle est de mieux gérer le risque et de faciliter la planification. C’est un
processus linéaire comme celui du modèle cascade sauf que pour prévenir les erreurs détecter
tardivement une validation est ajouté à chaque sortie d’une étape. C’est l’analyse descendante
de cycle de vie en « V ». Une fois le produit est réalisé un processus de validation final
montant est lancé

Figure 2.3 : Analyse descendante et validation intermédiaire

Figure 2.4 : Validation montante de cycle de vie « V »

Belarbi K.Manel
G.L Iset Sousse

Les avantages de ce modèle sont la validation intermédiaire et la décomposition fonctionnelle

de l’activité. Cependant validation intermédiaire n’empêche pas la transmission des
insuffisances de étapes précédentes ! En plus la maintenance n’est pas intégrée dans ce
processus comme si le produit est un logiciel jetable.

Avantages Inconvénients
 On anticipe les étapes suivantes  On ne voit pas toujours de retour sur les
 Rend explicite la préparation des dernières phases précédentes
phases (validation) par les premières  Adaptée pour des projets des projets dont
(construction) le domaine est maitrisé
 Obligation de concevoir ces jeux de tests  La spécification doit être complète dés le
et leurs résultats début
 Meilleure préparation de la branche droite
du V
 Contrôle de qualité sur chaque phase du
processus

II.3 cycle de vie spirale (famille itératif)

L’idée est de fournir le plus rapidement possible un prototype exécutable permettant une
validation concrète et non sur document. Ainsi au lieu de développer le projet en entier d’un
seul coup, nous développerons une première version du produit, en passant par toutes les
étapes d’un cycle de vie, qui contiendra les fonctionnalités les plus simples demandé par le
client. Ensuite nous itérerons ainsi jusqu'à la dernière version qui contiendra toutes les
fonctionnalités demandés par le client.

Belarbi K.Manel
G.L Iset Sousse

Figure 2.5 : Modèle spirale

Avantages Inconvénients
 Meilleure maitrise des risques  Nécessite une très grande expérience
 Phase de prototypage très importante  Réservée aux grands projets

IV. Insérer UML dans un projet

L’emploi d’UML n’implique pas nécessairement de produire des documents ni d’utiliser un

atelier de génie logiciel complexe. De nombreux informaticiens tracent des diagrammes UML
uniquement lors de réunion, afin de communiquer leurs idées. C’est un langage universel pour
modélisé un système, à base du concept orienté objet, en suivant le cycle de vie du logiciel et
ces différentes étape.

V. Conclusion

Dans ce chapitre nous avons vu la notion de cycle de vie d’un logiciel et l’importance chaque
étape de ce cycle afin de produire un logiciel de qualité et minimiser les risques des erreurs

Belarbi K.Manel
G.L Iset Sousse

qui peuvent augmenter les coûts de production du logiciel. Nous allons voir dans les chapitres
suivants UML qui va nous aider à décrire les étapes de spécification et la conception.

Belarbi K.Manel