Chapitre I. Generaliter sur le Genie Logiciel (G.

L)

I. Definition des concepts

L'informatique est la science du traitement automatique de l'information.

Ordinateur : Machine programmabl e capable de traiter les informations.

Systeme Informatique : Ensemble constituer de la partie materiel et de la partie logiciel.

Hardware ------> Partie Materiel.

Software --------> Parite Logiciel.

Logiciel : Ensemble de programme permetant d'utiliser le Hardware.

Systeme d'exploitation : Ensemble de programme qui jouent le role d'interface entre la partie materiel,
la partie logiciel et l'utilisateur.

Logiciel d'application : Programme informatique capable d'effctuer des taches precises.

Genie Logiciel : est une science qui etudie les methodes, les bonnes pratiques dans le devellopement des
logiciels.

Le genie logiciel s'interesse en particulier au procedure systematique qui permet d'arrive a ce que les
logiciels de grandes taille corresponde aux:

· Attentes du client

· fiable

· Qu'il soit de bonne qualiter avec de bonne performance tout en respectant les delais et les couts de
construction.

Le genie logiciel est un domaine de l'informatique dont l'objet d'etude est la conception, la
fabriquation et la maintenance des systeme informatique complexe.

Le genie logiciel est l'ensemble des activites de conception et de mise en oeuvre des produits et des
procedures tendant a rationalise la production des logiciels et le suivi.

II. Evolution du genie logiciel

A- Historique
 La notion de genie logiciel a ete propose en 1968 lors de la conference du Garnish-Partenkirchen
en Allemagne du 7 au 11 octobre 1968 pour discuter de ce qui etait alors appele la crise du logiciel. Il est
devenu claire que les approches individuel au devellopement des logiciels n'ont pas permit de cree des
systemes fiables qui satisfont leurs cahier de charge qui ont un cout reduit et qui ont ete livrer dans les
delaits, Tout au long des annees 70met des annee 80, une variete de nouvelle technique et methode de
genie logiciel ont ete developpe. Des outils et la notation standart ont ete elabore et sont largement utilise.

B- En jeux du Genie Logiciel

L'en jeux est de Bien developper le bon Logiciel :

· Bien develloper : Develloper en utilisant les procedures recommande dans le developpement

logiciel.

· Bon logiciel : Qui resoud le probleme de l'utilisateur.

C- Les principes du Genie Logiciel.

Les principes fondamentaux s'applique a tout type de systeme logiciel quelque soit les techniques de
devellopement uiliser. Les systemes doivent etre develloper en utilisant un processus de devellopement
reussi et comprehensilble a savoir :

· L'organisation qui devellope le logiciel doit planifier le processus de develloppement et avoir

une idee claire de ce qui serat prosuit et du moment ou il serat devellope.

· La fiabilite et la performance son importante pour tout types de systeme. Les logiciels doivent se
comporter comme prevu, sans defaillance et doivent etre disponible pour une utilisation en cas de
besoin.

· Comprendre et gerer les specifications logiciel et les exigences.

· Utilise le plus efficacement possible les ressources existante.

Chapitre II. Cycle de vie du logiciel (12/10/2024)

I. Generalites
Le Genie logiciel definie l'ensemble des methodes et technique pouvant faciliter la conception et la
realisation des logiciels complexe et de bonne qualiter.

L'objectif du genie logiciel est de develloper dans les delaits les logiciels de qualiter. Le genie logiciel
se preocupe des procedes de fabriquation des logiciels de facon a s'assurer que le produit qui est fabrique :
 · Reponde au besoin des utilisateurs : Fonctionnaliter

· Presque dans les limites financiere prevue au depart : Cout

· Corresponde au contrat de service initial : Qualite

· Reste dans les limites du temps prevu au depart : Delai

C'est la regle du CQFD.

L'utilisation d'une methodologie pour produire un logiciel s'est montrer incontournable par la
crise du logicel. Cette crise est apparue lorsqu'on a prit conscience de l'absence de la maitrise des
projets au niveau des couts (Cout du logiciel depassant celui du materiel), des delaits et la
mauvaise qualiter des produits (Les produits ne repondes aux besoin defini et des erreurs
persistes dans le produit final). Ces problemes sucites des risques humains et economique
comme l'illustre les celebres exemples suivants :

· TAURUS : Etait un projet d'informatisation de la bourse londoninne qui a ete

definitivement abandoner apres 4 ans de travail et 100 millions d'euro de perte.

· L'avion C17 de Mc Donnell Duglas livre avec un depassement de 500 millions de

dollard.

· En 1999 les etudiants de la faculter des Arts lettre et Science humaine de yaounde1 entre
en greve a cause d'une erreur de calcul des moyennes sur les modules.

· En 1996 le lancement d'Ariane 5 echou quelque seconde apres le lancement suite a une
exeption logiciel. Les pertes s'eleve a des centaines de millions de dollard.

· En 2007 le systeme de transfert d'Express Union est paraliser pendant plusieurs jours
suite au passage de la numerotation telephonique a 8 chiffres.

· En 2024 des millier de fonctionnaire camerounais on percue moins de 10% de leur salaire
suite a une panne logiciel.

D'apres le cabinet Standish Group qui a mene des enquetes sur des milliers de proget de toutes
tailles et de tout secteur, on a :

· 38% de proget reuissit : C'est a dire achever dans les delaits et pour le budget imparti avec toutes
les fonctionalites demander.

· 44% des progets mitiger : c'est a dire acheve et operationel mais livrer hors budget ou sans toutes
les fonctionalite demander.

· 18% de proget rate : c'est a dire abandonner avant la fin ou livrer mais jamais uttiliser.

Le meme Standish Group a realiser les meme statistiques pour petit et grand proget.
 Pour les petits proget on a :

· 76% de proget reuissi.

· 20% de proget mitige.

· 4% de proget rater.

Pour les grands proget, on a :

· 38% de proget rate.

· 52% de proget mitiger.

· 10% de proget reuissi.

Le Standish Group a aussi realiser des stats sur l'utilisation des fonctionnaliters implememter et il en
ressort que:

· 45% des fonctionaliter ne sont jamais utiliser.

· 19% des fonctionaliters sont rarement utiliser.

· 16% des fonctionaliters sont parfois utiliser.

· 13% des fonctionnaliters sont souvent utiliser

· 7% des fonctionnaliters sont toujours utiliser.

Le departement de la defense des etats unis a aussi mene une etude sur des progets militaires et il en
ressort que :

· 47% ne sont jamais utiliser.

· 29% sont payer et pas livrer.

· 19% sont utiliser apres de forte modificstions.

· 3% sont utiliser apres quelques modifications.

· 2% sont directement utiliser.

La solution imaginer pour repondre a cette crise du logiciel a ete l'industrialisation de la production
du logiciel. Ainsi, le genie logiciel a pour principale objectif la recherche permanente des moyens pour
reuissir a maitriser le devellopement, le fonctionement, et la maintenance du logiciel. Ces moyens sont
constituer de :

· Les models : Un modele est une representation simplifier d'une realiter.

· Les langages : Ils permetent de decrire les aspects pertinents du systeme. Ils peuvent etre textuel,
graphique, naturelle ou formelle.
 · La demarche : Elle decoupe le processus de conception en etape successive a enchaine.

· Les outils : Ils constituent le support automatique ou semi-automatique pour les methodes.

Malgrer les efforts menes dans le domaine du genie logiciel, il reste encore aujourd'hui moins avancer
parapport aux autres sciences de l'ingenierie (Genie civil, Genie electric...). Le genie logiciel rencontre
les difficulters suivantes :

· Le logiciel est un objet immateriel ce qui rend difficile l'appreciation de sa complexiter.

· Le logiciel est tres flexible, mallealable au sens facile a modifier( facile a modifier une ligne de
code mais infiniment difficile de garantire que le programme continura a fonctionner
normalement).

· Les besoins de l'utilisateurs sont difficiles a figer au depart et sont souvent remise en cause en
cours du devellopement.

· Le logiciel ne s'use pas mais peut devenr obselete.

· L'evolution rapide des technologies et des besoins de plus en plus complexe.

Le genie logiciel est en forte relation avec presque tout les autres domaines de l'informatique. Le genie
logiciel utilise l'informatique comme un outil pour résoudre des problèmes de traitement de l'information.
La spécialisation en genie logiciel peut se faire en suivant différents metiers :

· L'ingénierie du besoin.

· L'architecture logiciel.

· Le développement logiciel.

· Le test logiciel.

· La gestion de proget logiciel.

· La formation.

II. Etape du cycle de vie du developpement d'un logiciel

Le cycle de vie de développement d'un logiciel (SDLC[Software Development Life Cycle]) est un
ensemble d'étapes de la réalisation de l'énoncé des besoins a la maintenance et au retrait du logiciel sur le
marcher informatique. De façon générale, on peut dire que le cycle de vie du logiciel est la periode de
temps s'étalant du début à la fin du processus du logiciel.

L'origine de ce découpage provient du constat que les erreurs on un coût d'autant plus élevé qu'elle
sont détecté tardivement dans le processus de réalisation. C'est ainsi que, l'objectif principal du cycle de
vie du développement d'un logiciel est de permettre la détection des erreur au plus tôt et par conséquent
maitriser la qualiter du produit, les délais de sa realisation et les coût associés.

Le développement de logiciel impose d'effectuer un certains nombres d'etapes. Il existe de nombreux

modèle de cycle de vie du développement d'un logiciel, les plus courant comporte les phases suivantes:

a. La communication

C'est la première étape du cycle de vie de développement logiciel où l'utilisateur initie la demande du
produit logiciel souhaiter. Il soummet alors sa demande a l'entreprise du fournisseur de service par écrit.

b. La collection des exigences

A ce niveau, l'équipe de développement discute avec certain partenaires des divers problèmes du
domaine et essaie de proposer autant d'information possible sur les différentes exigences. Les exigences
sont contemplé et isolé en fonction des besoins des utilisateurs ( exigence du systeme et exigence
fonctionnelle). Les exigences sont collectée en utilisant un nombre donné des pratiques tel que :

· Étude du systeme ou logiciel existant ou obsolète.

· Conduite des interviews auprès des utilisateurs et des développeurs.

· Collection des réponses au moyens des questionnaires.

c. Étude du préalable

Le développement est précédé d'une étude d'opportunité ou étude préalable. Cette phase a pour
objectif de répondre au question suivantes:

· Pourquoi développer le logiciel ?

· Comment procéder pour faire ce développement ?

· Quel moyen faut il mettre en oeuvre ?

Elle comprend a la fois des aspet technique et de gestion. Parmit les taches technique on peut siter :

· Dressé un état de l'existance et faire une analyse de ses forces et faiblesse.

· Identifier les idées ou besoin de l'utilisateur.

· Formuler des solutions potentiels

· Planifier la transition entre l'ancien logiciel et le nouveaux s'il y a lieu.

· Affiner ou finaliser l'énoncé des besoins de l'utilisateur.

 d. Definition et analyse des besoins (Spécification des besoins)

On analyse les besoins de l'utilisateur ou du système englobant et on definit ce que le logiciel devra
faire. Le résultat de la fase d'analyse est conserver dans un document appelé cahier de charge du logiciel.
Il est essentiel qu'une specification ne définisse que les caractéristiques essentielles du logiciel pour
laisser de la place au décision de conception. Une specification comporte les éléments suivants :

· Description de l'environement du logiciel.

· Specification fonctionnelle qui defini toutes les fonctions que le logiciel doit offrir.

· Comportement en cas d'erreur.

· Performance requise.

· Les interface avec l'utilisateur.

· Interface avec d'autre logiciel et le materiel.

· Contraintes de réalisation

e. La conception du logiciel

Cette etape est generalement decompose en 02 phases successives ?

· Conception générale ou architecturale : Elle commence par l'ébauche de plusieurs variantes de

solution et choisis celle qui offre le meilleur rapport entre coût et avantages. Il faut ensuite figer la
solution retenue, la décrire et la détaillée. En particulier il faut decrire l'architecture de la solution
c'est a dire sont organisation en entité, les interfaces de ces entité et les interaction entre ces
entités. Le resultat de cette demarche est conserver dans le document de conception générale. Il
faut aussi préparer la phase d'integration durant cette étape. A cette effet, il faut élaborer un plan
d'integration et un plan de test d'integration.

· La conception détaillé : Elle affine la conception générale, elle commence par décomposé les
entité decouverte lors de la conception générale en entité plus élémentaire. C'est a cette phase que
l'on rédige les différents algorithme, on prépare aussi la phase des test unitaires et si possible on
complète le plan d'intégration.

f. Le codage

Aussi appele phase de conception, ou realisation, ou implementation. Lors de cette phase la

conception détaillé est traduite dans un langage de programmation.

g. Les test
 Durant cette phase les composants du logiciel sont evalue et integrer, et le logiciel lui même est
évaluer pour déterminer s'il satisfait la spécification élaborée.

h. Integration

A cette phase on assemble tout les composants du logiciel et on verifie egalement la bonne facture
des composant assemblés a travers des test d'intégration.

i. Installation

Dans cette phase on installe le logiciel dans son enironement d'exploitation ou dans un environement
qui simule cette environment d'exploitation et on le test pour s'assurer qu'il se comporte comme requit
dans specification élaborée.

j. Maintenance
Apres l'installation suit la phase d'exploitation et de maintenace. Il peut etre neccessaie de modifier le
logiciel pour corriger les défauts, pour améliorer ses performances ou autres caractéristiques, pour adapter
le logiciel a un nouvel environnement ou pour repondre a de nouveau besoins ou des besoins modifiée.
On distingue plusieurs formes de maintenance logiciel :

· La maintenance corrective : c'est une maintenance qui corrige les erreurs et les défauts d'utilité,
d'utilisabilite, de fiabilité... Elle identifie également les défaillance et les disfonctionements en
localisant la partie du code responsable. Elle corrige et estime l'impact d'une modification. Il faut
faire attention, car la plus part des correction introduise de nouvelles erreurs et les coût de
correction augmente exponentiellement avec le délai de détection.

· La maintenance adaptative : Elle ajuste le logiciel pour qu'il continue a remplir sont rôle conte
tenu de l'evolution des environments d'execution, des fonctions a satisfaire et des conditions
d'utilisations.

· Maintenace perfective : Elle sert a accroître et ameliorer les possibilités du logiciel afin de donner
lieu a de nouvelle version.

D'apres une etude réalisé par le Standish Group, la répartition de l'effort dans divers projet
informatique est le suivant :

· 60% pour la maintenance.

· 19% pour l'intégration et les tests.

· 8% pour la programmation.

· 7% pour la spécification.
 · 6% pour la conception.

De ces statistiques, le Standish Group a établi un rapport Effort-Erreur-Coût. Ainsi, le Standish Group
a determiner l'origine des erreurs dans divers projet informatiques :

· 58% d'erreurs vienne de la spécifications.

· 24% d'erreurs provient de la conception.

· 6% d'erreurs proviennent de la programmation.

· 12% d'erreurs proviennent de l'integration et des tests.

Le standish Group a évalué le coût de la maintenance en fonction de l'origine des erreurs:

· 81% des coût de maintenance corrige les erreurs de spécification.

· 14% des coût de maintenance corrige les erreurs de conception.

· 4% des coût de maintenance corrige les erreurs d'intégration et de test.

· 1% des coût de maintenance corrige les erreurs de programmation.

k. La disposition

Un peut subir une détérioration proportionnellement a sa performance, il peut être complètement

obsolete ou exigera une intense mise a jour. La disposition planifie les activités de fermeture et de
termimaison du système.

Chapitre III. Modelisation des processus du cycle de développement

Introduction
La modélisation de processus de développement logiciel aide les développeurs a sélectionné la
stratégie pour développer le produit logiciel. Les modèles du cycle de vie du logiciel sont des plans de
travaille qui permettent de planifier le développement. Ces modèles décrives les liens, les relations entre
les différentes étapes du cycle de vie du logiciel.

II. Modèle en cascade

 Est un modele qui a pour objectif d'echalone rigoureusement le processus de développement et de
definir de façon précise les rôles respectifs du fournisseur qui produit un livrable et du client qui accepte
ou refuse le résultat. Le cycle de vie en cascade date de 1970, il est l'œuvre de Royce.

Ce cycle de vie est linéaire sans aucune évaluation entre le début et la validation du projet. Ici, le
projet est decouper en phase successive dans le temps et a chaque phase correspond une activiter
principale bien précise produisant un certains nombre de livrables et on ne passe a l'étape suivante que si
les résultats de l'étape précédente sont jugé satisfaisantes. L'activiter d'une étape se réalise avec les
résultats fourni par l'étape précédente; Ainsi, chaque étape sert de controle du travail effectué lors de
l'étape précédente et chaque phase ne peut remetre en cause que la phase précédente.

L'élaboration des specifications est une phase particulièrement critique: Les erreurs de specification
sont généralement détecter au moment des tests. Leurs correction necessite alors de reprendre toute les
phase du processus. Ce modèle est mieux adapté au petit projet ou a ceux dont les spécifications sont bien
connu et fixe.

Chaque étape doit être terminer avant que ne commence la suivante. A chaque étape, la production
d'un document est la base de l'etape suivante:

· A l'étape de spécification, le livrable est le cahier de charge fonctionnelle.

· A l'étape de conception, le livrable est le dossier de conception détaillé.

· A l'etape de programmation et test unitaire, les livrales sont les codes sources documenter et le
rapport des test unitaires.

· A l'etape d'integration, le livrable est le rapport de validation.

1. Avantage

Le modèle en cascade represente les avantages suivants:

· une structure simple grace a des phase de projet clairement défini.

· Une bonne documentation du processus de développement par des étapes clairement défini.

· Les coûts et la charge de travail peuvent être estimé des le début du projet.
 · les projet structurer d'après le modèle en cascade peuvent être representer facilement sur un axe
temporaire.

2. Inconvenients

· Les projets complexes ou a plusieurs niveaux ne peuvent que rarement être divisé en fase de
projet clairement défini.

· Une faible marge du coût des ajustements du déroulement du projet en raison d'exigence
modifier.

· L'utilisateur final est uniquement integrer dans le processus de production qu'après la

programmation.

· Les erreurs sont parfois détecté uniquement a la fin du processus de développement.

II. Modèle en V

Le modèle en V du cycle de vie du logiciel précise la conception des test; Il est dérivé du modèle en
cascade et montre non seulement l'enchaînement des fases successives, mais aussi les relations logiques
entre les phases plus éloigné. avec les jeux de test préparé dans la première branche, les étapes de la
deuxième branche peuvet être mieux préparer et planifier.

Le modèle en V est apparue dans les années 80 etait ensuite devenu un standart dans l'univers de la
création de logiciel. La lettre V provient du fait que le modèle associe chaque phase de développement
avec la phase de validation qui lui correspond. Le modèle en V est très rependu dans le secteur industriel.
Il est presque devenu la norme dans la pluspart des appels d'offres des marchés publics relatif a
l'informatique.

Il convient au projet informatique de toute taille.

1. Avantage du modèle en V
 · Amélioration de la qualiter du produit grace a l'integration des mesures liée a l'assurance qualité.

· Reduction des coûts grace a un processus transparent de l'ensemble du cycle de vie du produit.

· Risque maîtriser et meilleur planification grâce à des fonctions et des resultats bien défini en
amont.

· Optimisation de la communication entre les parties prenant grâce à des modalité et des
responsabilité clairement défini.

2. Inconvenients du modèle en V

· Manque de flexibilité.

· L'effet tunnel c'est a dire qu'il est possible que les équipes ne voit pas les résultats de leurs efforts
avant d'avoir atteint les étapes finales du projet.

· Possibilité de détecté tardivement les erreurs.

III. Le modèle en spirale

Il met l'accent sur l'activité d'analyse des risques. Chaque cycle en spirale se déroule en 04 phases:

· Phase 1: Determination des objectifs du cycle, des alternative pour les ateindre et des contraintes.

· Phase 2: Identification et resolution des risques.

· Phase 3: Développement et vérification/validation de la solution retenue, Un modèle classique (

En cascade ou en V ) peut être utilisé.

· Phase 4: planification, revue des resultats et verification du cycle final.

Le cycle de vie en spirale est un modèle itératif et incremental.

(Schéma)
 [Link] du modèle en spirale.

· Il est approprié a des projets qui sont soumis a des risques importants. Sont avantage est de
minimise tout ces risques

· Meilleurs qualité des logiciels.

· Des fonctionnalités supplémentaires ou des modifications peuvent être apporté ultérieurement.

· L'estimation des coûts devient facile car la construction du processus est réalisé en petit fragment.

· Le développement continue ou répéter aide a la gestion des risques.

· Le développement est rapide et les fonctionnalités sont ajouter de manière systématique.

2. Les inconvénients du modèle en spirale

· Risque de ne pas respecter le calendrier ou le budjet.

· La documentation est plus volumineuses.

· Le développement logiciel en spirale n'est pas conseiller pour les petit projet car cela pourrait l'es
coûté chers.
 · Difficile de suivre strictement le protocol.

IV. Le modèle incrementable

C'est un modèle iteratif qui consiste a sélectionner successivement plusieurs incréments. Un incrément du
logiciel est un sous ensemble du logiciel complet, qui consiste a un petit nombre de fonctionnaliter.

Dans les modeles en spirale, en V ou en cascade un logiciel est décomposer en composant, developper
séparément et integrer a la fin du processus. Dans le modele par increment, seul un sous ensemble est
develloper à la fois. Dans un premier temps, un logiciel noyau est développer, puis successivement, les
incréments sont developer et integrer. Chaque incrément est developer seulont l'un des modèles
précédents. Dans ce modèle, les intégrations sont progressives et il peut y avoir des livraisons et des mises
en service après chaque intégration increment. Ce modèle présente comme avantage:

· Chaque développement est moins complexe.

· Les intégrations sont progressives.

· il y a possibiliter de livraison et de mise en service après chaque incrément.

· Ce modele présente un meilleur lissage du temps et de l'effort de développement.

Le modèle incremental présente comme risque:

· La remise en cause du noyau de départ.

· La remise en cause des incréments précédents.

· L'impossibiliter d'intégrer un nouvel incrément.

(Schema)

TD1.(2024/11/04)

Exercice 1:
1. La principale cause de l'apparition du genie ligiciel est la crise du logiciel.

2. La crise du logiciel est une periode ou les logiciels depassait les coût de depart n'etait pas livrer dans les
délais et etait de mauvaise qualiter. et le coût du materiel diminuait pendant que celui du

3. Le genie logiciel est une science qui étudie les méthodes et les bonnes pratiques dans le dévellopement
des logiciels. Elle a pour but de d'ameliorer de faciliter et de normalisé la creation des logiciels.

4. CQFD. cette règle est basé sur Fonctionnalité,Qualités,Coût et délai. Ça resume en somme les en jeux
du genie logiciel.

5. Phase de développement d'un logiciel:

· Communication.
 · Collection des exigences

· étude préalable

· spécification des besoins

· conception du logiciel

· codage

· test

· integration

· installation

· maintenance.

Exercice 2:

1. Qualité de logiciel: ensemble des caractéristiques et des attributs d'un logiciel.

2. La difference est la suivante: Les facteurs de qualiter logiciel externes sont des qualiters de logiciel du
oint de vue de l'utilisateur tandis que les facteurs de qualiter interne sont des qualiters du logiciel du point
de vue du devloppeur.

L'intérêt qu'il y a à définir les facteurs de qualiter interne est d'assurer ou ameliorer la productiviter du
developpeur.

3.

Exercice 3

Quel sont parmit ces facteurs ceux qui sont les plus importants pour les logiciels suivants:

a. Application web de transaction bancaire en ligne.

b. Système d'achat en ligne.

.c Systeme de contrôle de trafic aérien.

d. Guichets automatique de billet.

2. Il n'existe pas de relation cause a effet entre la fiabilité et l'utilisabilite

3. Les facteurs contradictoires exigeant des compromis sont :

· Utilisabiliter et fiabiliter.

· Portabiliter et efficacité.
 Chapitre IV. Methode de développement logiciel.

I. Généralité
Une méthode defini une démarche en vue de produire des résultats. Par exemple les cuisinier utilisent des
recettes de cuisine.

Une méthode permet d'assister une ou plusieurs étapes du cycle de vie logiciel. Les methodes d'analyse et
de conception fournissent des notations standard et des conseils pratiques qui permettent d'aboutir a des
conceptons raisonnable. Il existe differentes manière pour classer ces méthodes:

· La distinction compositionelle et decompositionelle : Elle met en opposition d'une part les

méthodes ascendante qui consiste a construire un logiciel par composition à partir de module
existants.

· La dispertion fonctionnelle et orienté objet : Dans la strategie fonctionnelle , un

systeme est vue comme un ensemble d'unité en interaction, ayant chacune une fonction
clairement défini. Les strategie orienté objet considère qu'un système est un ensemble d'objet
interagissent. Chaque objet dispose d'un ensemble d'attribut décrivant son état et l'état du système
est décrit par l'état de l'ensemble.

II. Les methodes fonctionnelle.

Les methodes fonctionnelle on pour ........ Cette approche consiste a decomposer une fonctionnalité du
logiciel en plusiuersous fonction plus simple. Il s'agit d'une conception

Top-Down basé sur le principe divisé pour mieux reigner. L'architecture du système est le reflet de cette
décomposition fonctionnelle. La programmation peut ensuite être réalisé à partir des fonctions de haut
niveau ( Development Top-Down ), soit a partir des fonctions de bas niveau ( development Bottom-Up )
Cette methode presente les inconvénients suivants:

· L'architecture étant basé sur la decomposition fonctionnelle, une évolution fonctionnelle peut
remettre en cause l'architecture. Cette methode ne supporte pas l'évolution des besoins.

· Cette methode ne favorise pas la réutilisation des composants.

III. Les methodes objets

Les objets sont une abstraction des entité du monde réel. De façon générale, la modélisation permet de
reduire la complexité et de communiquer avec les utilisateurs.

Dans les methodes objets, on distingue trois aspects:

· Un aspect statique: Dans le quel on identifie les objets, leurs proprieter et leurs relations.

· Un aspect dynamique: dans le quel on decrit le comportement des objets, en particulier leurs états
possible et les évènements qui déclenche les changements d'états.

· Un aspect fonctionnelle: Qui decrit les fonctionnalités du logiciel.

Les intérêts des aproches objets sont les suivants:

· Les approches objet sont souvent qualifier de naturelle car elle sont basé sur le domaine
d'application. Cela facilite en particulier la communication avec les utilisateurs.

· Ces approches supporte mieux l'évolution des besoins que les approches fonctionnelle.

· Les approches objet facilite la réutilisation des composants.

 IV. Les méthodes Agile.
Ceux sont des méthodes qui correspondent a un cycle de vie iteratif, qui concidere que les changements
sont inévitable et doivent être pris en compte par les modèles de développement. Ces methodes priviligie
la livraison de fonctionnalités utile au client a la production de documentation intermédiaire sans intérêt
pour le client. Ainsi, toute les methodes agiles prennent en compte das leurs modèles de cycle de vie 03
exigences:

· Une forte participation entre développeurs et utilisateurs 👥.

· Des livraisons fréquente de logiciel.

· Une prise en compte de possible changement dans les besoins des utilisateurs au cours du projet.

Toute les methodes agiles font appel d'une façon ou d'une autres a un modèle itératif et incremental. De
plus, elle preconise des durée de cycle de vie ne dépassant pas un ans. Parmit les methodes agiles les plus
usuelles, on peut citer:

· La methode RAD ( Rapid Application Development ).

· La methode DSDM ( Dynamic Systems Development Method ).

· La methode XP ( Extrem Programming )

· La methode SCRUM.

1. Methode RAD

Est un modèle linéaire structuré en 05 phases et dont le modèle itératif intervient a la phase construction
du logiciel en vue de la sequencer en plusieurs modulse successivement livré.
 2. Methode DSDM

La methode DSDM a évoluer au cour des années. L'actuelle version distingue le cycle de vie du système
et le cycle de vie du projet. Le cycle de vie du système comprend les phases du projet, une phase pré-
projet et une phase post-projet. Le cycle de vie du projet comprend 05 phases dont 02 sont cycliques. Les
flèche plaine indique un déroulement normale et les flèches en pointillé montre a un retour possible a une
phase antérieure.
 [Link] methode XP

Est focalisé sur la phase de programmation du projet. Elle propose un modèle itératif avec une structure
a deux niveaux d'abord avec les iterations de livraison, puis les iterations de développement. Les
iterations de livraison conduise a livrer des fonctionnalités complete, les iterations porte sur des éléments
plus fin. Chaque itération de développement commence par l'écriture des scénarios ( Users / Stories ).
Utilisateurs et développeurs détermine ensemble ce qui doit être développer dans la prochaine itération.
Les plans de test sont ecrit, les développeurs sont reparti en binôme, il code les tâches qui leurs sont
affectées puis effectue avec les utilisateurs les tests d'acceptation. Chaque livraison d'une durée de
quelques mois se termine par la fourniture d'une version opérationnelle du logiciel.
La methode strong emprunte le vocabulaire du jeu, le qualificatif des trois phases du cycle préconise. La
phase d'avant jeux concerne la conception et l'architecture du système. La phase de jeux est itérative et
qualifié d'Ampirique, dans la mesure ou le travail effectuer ne fait pas l'objet d'une planification. Une
iteraation dont la durée oscille entre une et 4 semaines est appelée sprint. Un sprint est découpé en 03
sous phases : Le développement, l'emballage et l'ajustement. La phase d'après jeu vise a livrer un produit
complet et documenter.
 V. Methode Specifiques
Certains decoupage temporelle sont lié soit a une méthode soit a un type de projet bien particulier. Nous
proposons l'exemple du decoupage préconisé pour mettre en place un progiciel de gestion intégré.

La mise en place d'un progiciels de gestion intégrer souvent appelé ERP ( Enterprise Ressource Planing )
s'appui sur un découpage. En effet il s'agit de construire en tirant le meilleur parti du progiciel, un système
ameliorant les performances de l'entreprise.

CHAPITRE 5: Test du logiciel

I. Généralité
Le test est l'execution ou l'evaluation du système ou d'un composant par de moyens automatiques ou
manuelle pour verifier qu'il repond a ses spécifications ou identifier les differences entre les resultats
attendu et les resultats obtenus.

Tester c'est exécuté le programme dans l'intension de trouver des anomalies ou des défauts. Les raisons
d'effectuer un test sont nombreuses:

· C'est le seul moyen d'éliminer les bugs: Le code 0 bug n'existe pas, sauf exception. Les bugs son
inhérent a l'activiter de codage ( Les stats rapporte qu'on a 1 a 10 bugs par KLOC [ Kilo Line Of
Code] {1 KLOC = 1000 lignes de code})

· Pour eviter les mauvaise surprise comme la découverte de bugs après la mise en production.

· Pour se prémunir contre la régression de code.

· Les tests sont des gardes four pour détecter la régression qu'un développeur peut introduire de
façon involontaire lorsqu'il modifie le code du logiciel.

· Pour rassurer le développeur: L'orsqu'un code atteint une certaine complexité, le développeur
commence à craindre les modifications.

· Pour rassurer le client: Le produit final contient des preuves de test du produit.

Un bug est un défaut de conception ou de réalisationd'un logiciel qui provoque un disfonctionement.

Il existe plusieurs types de bugs :

· Mandelbug : Inspiré des fact all de Mandel Burt. C’est un bug dont les étapes pour les
reproduire sont si complexe qu’il semble se reproduire de façon aléatoire.
 · SchrodinBug : Inspiré du char de schrodinger qui ne se révèle pas à l’exécution mais qui
est découvert lorsque quelqu’un relis le code source ou utilise le logiciel de façon inhabituel.

II. les niveaux de test

Un test est un procédé de verification et de validation. La verification consiste à se demander si le logiciel

fonctionne correctement. D'après l'ISO-9000 la vérification est la confirmation par l'examen et la
fourniture de preuves objectives que les exigences specifier ont été remplis. La validation consiste à se
demander si on a construit le bon logiciel. D'après l'ISO-9000 la validation est la confirmation par
l'examen et la fourniture de preuves objectives que les exigences pour un usage voulu ont été remplis.

En d'autres termes, la validation s'assure que les besoins du client soit satisfaits et la vérification s'assure
que le logiciel satisfait sa specification.

On distingue globalement trois niveaux de test, qui sont représenté dans la pyramide des tests suivants:

Les test unitaires on pour but de guider le développeur. se seont des tests en isolation des unités de
développement. Les erreurs recherchés sont les erreurs de codage et les erreurs fonctionnel dans les
unités.

Les test d'integration on pour but de guidé l'équipe de développement. Ils portent sur l'assemblage des
unités. Les erreurs rechercher sont des erreurs d'interface entre unité.

Les test systèmes on pour but de critiqué le produit. Ils test le système dans son ensembles en particulier
l'interaction Homme-Machine. Les erreurs recherchés sont l'absence ou la défaillance de fonctionnalité.
On distingue plusieurs niveaux de test système:

· Tests Alpha: ce sont les test auprès d'utilisateur interne au projet.

· Test Beta: ceux sont des test auprès d'utilisateur externe au projet mais avertis.

Les test unitaire sont essentiellement de l'ordre de la verification tandis que les test systèmes sont
essentiellement de l'ordre de la validation.

III. Les principes de test

Quelques principes de base des tests logiciels:

· L'indépendance: Un programmeur ne doit pas testé ses propres programmes mais il vaut mieux
faire ses tests avant de délivré.

· La paranoïa: Ne pas faire des tests avec l'hypothèse q'il n'y a pas d'erreurs.

· La prédiction: La definition des sorties et des résultats attendus doit être effectué avant l'exécution
des test.

· La vérification: Il faut inspecté minisieusement les resultats de chaque test mais aussi la
pertinence des tests.

· La robustesse: Les jeux de test doivent être écrit avec des jeux valides mais aussi invalide et
incoherent.

· La conpletibiliter: Verifier un logiciel pour vérifier qu'il ne réalise pas ce qu'il est supposé faire
n'est que la moitié du travail. Il faut aussi verifier ce que le logiciel fait lorsqu'il n'est pas supposé
le faire.

Une anomalie ou défaillance est un comportement observé différent du comportement attendu ou spécifié.
La chaine de causalité indique que les erreurs entraine des defauts qui eux entraine des anomalies.

IV. Les modalités et méthodes de tests

On a généralement deux methodes de test:

· Les tests statiques: Qui sont des test effectués par l'Homme sans l'aide d'une machine, il se fait
par lecture du code. Sont but est de trouvé des erreurs dans une ambiance de coopération. Ainsi,
les inspections ou revu de code se feront dans une reunion avec les programmeurs et
concepteurs.

· Les tests dynamiques: Ceux sont des bouts de code qui sont exécutés avec l'intention de vérifié ou
de validé un code fonctionnel. Il passe par l'execution du logiciel. Il existe deux types de test
dynamiques: - Les tests en boite noir: L'ecriure des test se fait sans connaitre la structure interne
du code a testé.Il ne s'intéresse qu'au entré et sortie.

- Les tests en boite blanche: L'ecritture des test tiens compte de la

structure interne de l'unité testé.
Il existe aussi plusieurs méthodes de test:

· Les test structurels: Ils on por objectif de detecter les fautes d'implémentation. Il repose sur les
analyse du code source par l'examen de la structure interne du programme (flot de controle ou flot
de données) ce sont des test en boîte blanche et leurs conception est réalisé uniquement l'orsque le
logiciel est déjà décrit.

· Les tests fonctionnrel: il repose sur une spécification du logiciel et le code source n'est pas utilisé.
Sont objectif est l'analyse du comportement. se sont des test en boîte noir.

· Analyse du comportement:

Methode d'estimation des coûts.

I. Généralité
L'estimation des coûts d'un projet est le chiffrage aproximarif du coût des réalisations du projet. Son
objectif est la budgétisation du projet. Le coût comprend donc les salaires, le matériel, le logiciel, la
maintenace, les stages et formation, le loyer, l'electricite, la connexion internet, le transport etc...

Le coût d'un logiciel est fonction de l'effort de développement, il inclut la specification, l'analyse, la
conception, la programmation, les tests et la maintenance.

L'effort est la quantité de travail neccessaire indépendamment du nombres de personnes qui va réalisé le
travail. Il s'exprime en Homme/Jour (HJ) ou Homme/Mois (HM) ou Homme/Année (HA).

Par exemple 60HM correspond a: - Une personne pendant 5 ans

- Cinq personnes pendant 1 ans.

- Six personnes pendant 6 mois.

- Soixante personnes pendant un mois.

L'estimation du coût total d'un projet est une étape crucial a ne pas négligé. La tendance étant la sous
estimation pour cause d'optimisme, par besoin de gagné un marché ou encore par oubli de prise en
compte d'une phase ou autre chose est très dangereuse. La sur-estimation lès autant.

Parmis les différentes étapes de gestion d'un projet, l'evaluation des coûts du projet est la plus importante
et la plus délicate. En effet, cette phase nécessite beaucoup de rigueur et doit être la plus exhaustive
possible afin de produire un chiffrage precis, fiable et pertinent. L'estimation des coûts et durée se fait en
03 étapes:

· Lors d'une réponse a un appel d'offre. Où il s'agit de fournir au plus vite une réponse adaptée au
 marché.

· Lors de la planification du projet. Où il s'agit d'établir le plans projet et le plans qualité qui
serviront de cadre contractuel au projet.

· Lors du déroulement du projet. Afin d'afiné les prévision et de les mettres a jours.

II. Les méthodes d'estimations

il n'existes pas de methoe universel en matière d'estimation des coûts. Il existe de nombreuses méthodes
que l'on peut suivre:

1. Estimation par analogie

sont principes est le suivant: le coût du projet est calculé en le comparant a d'autre projet similaires dans
le même domaine d'application.

Cette méthode a pour avantage l'estimation précise si les données concernant les projets similaires sont
disponible. ses inconvénients sont : son impossibilité si les projets similaires n'etait pas réalisé, et la
nécessité d'avoir une base de données des coût projets a jours.

2. La meilleure offre du marché où méthode du marché

Sont principe est le suivant: Le projet coûte ce que le client est prêt à payer.

Sont avantage est que le contrat sera gagné.

Ses inconvénients sont: La probabilité élevée que le client n'obtienne pas le logiciel qu'il désire et les
coûts ne reflète pas le travail requis.

3. Jugement d'expert

Sont principe est le suivant: Un ou plusieurs expert a la fois dans le domaine d'application utilise leurs
expertises pour faire des prévisions de coût. Le processus est itéré jusqu'à ce qu'un consencius sont atteint.

Son avantage est l'estimation précise si les experts on de l'expérience dans les projets similaires.

Son inconvénient est l'estimation non précise s'il y a peut d'expertise.

4. Estimation ascendante

Sont principe est le suivant: On commence au niveau le plus bas du logiciel, on estime individuellement
le coût de chaque composant du logiciel, puis ces coût sont additionné pour obtenir une estimation global
du coût du logiciel.

Son avantage est la précision si la conception a été effectué avec suffisamment de details.
Son inconvenient est la possibilité de sous estimé les activités au niveau global comme l'integration, la
documentation etc...

5. Estimation descendante

Estimé a partir du niveau global du logiciel jusqu'au niveau fonctionnel.

Sont avantage est de prendre en compte les coûts globaux comme l'integration, la documentation,
la gestion de configuration etc...

Son inconvenient est la possibilité de sous estimé le coût d'apporter des solutions a des
problèmes techniques de bas niveau.

6. La loi de Parkinson

Cette loi stipule que le travali se dilate jusqu'à remplir le temps disponible.

Dans le cadre d'un projet logiciel le principe est le suivant: Le projet utilise toute les ressources
disponibles.

Son avantage est qu'il n'y a pas d'excès dans les dépenses.

Son inconvenient est le risque élevé de ne pas achevé le projet.

7. Les methodes algorithmiques

L'effort de développement, le cout, le temps sont estimé comme une fonction mathématique des attributs
du logiciel, du projet et du processus.

Forme générale: E=A+B(EV)C avec :

· E: l'effort en Homme/Mois (HM)

· A,B,C: Constante estimé empiriquement.

· EV: variable d'estimation de la taille du logiciel (Nombre de milliers de lignes de code (KLOC),
Nombre de points de fonction, nombres de fichiers, Nombres de modules etc...)

a. La methode COCOMO (Constructive Cost Modèle)

Est une méthode qui permet d'estimer le coût, l'effort et le temps nécessaire au developpement d'un
logiciel. Elle se base sur une approche algorithmique pour determiner l'effort et le temps de
développement d'une application. Elle est basé sur le nombre de millier de ligne de code. La methode
COCOMO est en fait constitué de 03 modèles et distingue 03 types de projets. Les 03 modèles sont:

· Modèles de base

· Modèle intermédiaire
 · Modèle expert.

Les types de projet COCOMO sont:

· Les projets organics: sont des applications simples réalisé par une équipe expérimenté ayant
l'habitude de travailler ensemble maîtrisant le langage et l'environnement de développement.