Génie Logiciel 2 :

Contenu de la matière :
Chapitre 1 : Processus de développement logiciel :
1) Motivations :
• Qualités attendues d'un logiciel
• Principes du Génie Logiciel
• Maturité du processus de développement de logiciel

2) Cycle de vie d'un logiciel

• composantes du cycle de vie d'un logiciel
• Documents courants
• Modèles de cycle de vie d'un logiciel
• Modèles de processus logiciels
Chapitre 2 : Gestion et planification de projets
1) Gestion de projets
• Pratiques critiques de la gestion de projets
• Analyse de la valeur acquise
• suivi des erreurs
2) Planification de projets
• Organigramme technique
• La méthode PERT
• Autres modèles
• Estimation des couts (exemple : modèle COCOMO)
3) Assurance qualité

Chapitre 3 :
1) Métriques
• Métriques de Mac Cabe
• Métriques de Halstead
• Métriques de Henry_Kafura
• Métriques Objet de Chidamber et Kemerer
• Métriques MOOD
2) Analyse et gestion des risques
3) Tests de Logiciels
• Tests Fonctionnels
• Tests Structurels
• Tests de Flots de données
• Tests orientés objets.
Chapitre 1 : Processus de développement Logiciel :

1) Motivations :

1.1. Qualités attendues d'un logiciel :

Utilité (correspond au besoins de l'utilisateur) :
Adéquation entre Le besoin effectif de l'utilisateur et Les fonctions offertes par le logiciel
que faire pour l'assurer ?
• Assurer l'emphase sur l'analyse des besoins
• Améliorer la communication (utiliser un langage commun ainsi qu'une démarche
participative)
• Travailler avec rigueur

Utilisabilité :
Inclut deux points essentiels :
• Facilite d'apprentissage : comprendre ce que l'on peut faire avec le logiciel, et savoir
comment le faire.
• Facilite d'utilisation : importance de l'effort nécessaire pour utiliser le logiciel a des fins
données .
que faire pour l'assurer ?
• Analyse du mode opératoire des utilisateurs
• Adapter l'ergonomie des logiciels aux utilisateurs

Fiabilité :
Correction, justesse, conformité : le logiciel est conforme a ses spécifications, les résultats sont
ceux attendus.
Robustesse, sureté : le logiciel fonctionne raisonnablement en toutes circonstances, rien de
catastrophique ne peut survenir, même en dehors des conditions d'utilisation prévues .

Comment mesurer la fiabilité ?

En estimant :
• le « MTBF : Mean Time Between Failures » (littéralement le temps moyen entre deux
erreurs).
• Disponibilité : pourcentage du temps pendant lequel le système est utilisable
• le taux d'erreur :nombre d'erreurs par KLOC (Kilos line of code)

que faire pour l'assurer ?

• Utiliser des méthodes formelles,
 • Utiliser des langages et des méthodes de programmation de haut niveau,
• Vérifications, tests
• Utiliser des Progiciels

Interopérabilité : (interaction avec les autres logiciels)

Un logiciel doit pouvoir interagir en synergie avec d'autres logiciels
que faire pour l'assurer ?
• Bases de données (découplage données/traitements)
• Externaliser certaines fonctions en utilisant des < Middleware > avec une API (Application
Program Interface) bien définie
• Standardisation des formats de fichiers (XML...) et des protocoles de communication
(CORBA...)
• Utiliser des ERP (Entreprise Resources Planning)

Performance :
Les logiciels doivent satisfaire les contraintes de temps d'exécution
que faire pour l'assurer ?
• Créer des logiciels plus simples
• Veiller à la complexité des algorithmes
• Utiliser des machines performantes

Portabilité :
Un même logiciel doit pouvoir fonctionner sur plusieurs machines
que faire pour l'assurer ?
• Rendre le logiciel indépendant de son environnement d'exécution
• Utiliser des machines virtuelles

Ré-utilisabilité :
On peut espérer des gains considérables car dans la plupart des logiciels :
80 % du code est du < tout venant > qu'on retrouve à peu prés partout
20 % du code est spécifique
que faire pour l'assurer ?
• Abstraction, généricité (exemple : MCD générique de réservation)
• Construire un logiciel à partir de composants prêts à l'emploi < Design Patterns >

Facilité de maintenance :
Un logiciel ne s'use pas. Pourtant, la maintenance absorbe une très grosse partie des efforts de
développement (67%)
Objectifs :
• Réduire la quantité de maintenance corrective (zéro défaut)
• Rendre moins couteuses les autres maintenances
Enjeux :
Les couts de maintenance se jouent très tôt dans le processus d'élaboration du logiciel. Au fur et à
mesure de la dégradation de la structure, la maintenance devient de plus en plus difficile.

que faire pour l'assurer ?

• Utiliser du code réutilisable,
• Assurer la modularité lors du processus de développement
• Vérifier et tester
• Utiliser des structures de données complexes et de algorithmes simples
• Anticiper les changements à venir

Aussi, il ne faut pas oublier que la qualité du processus de fabrication est garante de la qualité du
produit final. Pour obtenir un logiciel de qualité, il faut en maitriser le processus d'élaboration. La
vie d'un logiciel est composée de différentes étapes. La succession de ces étapes forme le cycle de
vie du logiciel. Donc, il est primordial de contrôler la succession de ces différentes étapes : utiliser
une méthode décrivant clairement les étapes à suivre pour élaborer un logiciel.

1.2 . Principes du Génie Logiciel

Généralisation : regroupement d'un ensemble de fonctionnalités semblables en une fonctionnalité
paramétrable (généricité, héritage).
Structuration : façon de décomposer un logiciel (utilisation d'une méthode bottom-up ou top-
down).
Abstraction : mécanisme qui permet de présenter un contexte en exprimant les éléments pertinents
et en omettant ceux qui ne le sont pas.
Modularité : décomposition d'un logiciel en composants discrets.
Documentation : gestion des documents incluant leur identification, acquisition, production,
stockage et distribution.
Vérification : détermination du respect des spécifications établies sur la base des besoins identifies
dans la phase précédente du cycle de vie.

1.3. Maturité du processus de développement de logiciel

Aujourd’hui, de nombreux organismes s’efforcent d’améliorer leurs processus de développement de
logiciel et d’en mesurer les progrès. L’un des standards de mesure de cette amélioration est le CMM
(Capabilitiy Maturity Model) . Ce modèle a été défini par le Software Engineering Institute (SEI) de
l’Université Carnegie Mellon. Il est applicable à tout organisme impliqué dans le développement
de logiciel.
CMM décrit 5 niveaux de maturité des processus (chaque niveau est détaillé ci-après). Chaque
niveau, supérieur au premier, porte son effort sur l’amélioration de quelques thèmes majeurs.
L’amélioration de la maturité d’un organisme se caractérise par :
• la réduction des délais de développement ;
• la réduction des couts ;
• l’utilisation plus efficace des ressources.

Niveau 1 Initial :
Sans intérêt : plans et contrôles inefficaces
• Processus essentiellement non contrôlé, non défini.
• Le succès dépend des individus.
Niveau 2 Reproductible :
Intuitif : dépend encore des individus
• Procédures de gestion utilisées, gestion des configurations et assurance qualité
• Pas de modèle formel de processus
Niveau 3 Défini :
Qualitatif : institutionnalisé
• Procédures formelles pour vérifier que le processus est utilisé
Niveau 4 Maitrisé :
Quantitatif : Processus de mesures
• Gestion quantitative de la qualité
Niveau 5 Optimisé :
• Améliorations retournées dans le processus
• Stratégies d'amélioration du processus

2) Cycle de vie d'un logiciel

Le cycle de vie d'un logiciel : c'est l'ensemble des phases par lesquels un logiciel passe au cours de
sa vie, allant de sa création jusqu’à sa maintenance.
Le cycle de développement d'un logiciel : C’est l’ensemble des étapes nécessaires au bon
développement d’un logiciel.

2.1. Composants du cycle de vie d'un logiciel

Analyse des besoins :
L'analyse des besoins permet de comprendre les besoins du client (établir un cahier des charges),
ainsi que d'étudier la faisabilité du projet et déterminer si le développement proposé vaut la peine
d’être mis en œuvre, compte tenu de attentes et de la difficulté de développement.
Spécification :
Lors de l’étape de spécification, il s'agit d'établir une description claire de ce que doit faire le
logiciel et clarifier le cahier des charges. Elle consiste en :
• Collecte des exigences : obtenir de l’utilisateur ses exigences pour le logiciel
• Analyse du domaine : déterminer les tâches et les structure qui se répètent dans le
problème
Organisation du projet : Consiste en :
• Analyse des couts : établir une estimation du prix du projet
• Planification : établir un calendrier de développement
• Assurance qualité du logiciel : déterminer les actions qui permettront de s’assurer de la
qualité du produit fini
• Répartition des tâches : hiérarchiser les tâches et sous-tâches nécessaires au développement
du logiciel
Conception : Déterminer la façon dont dont le logiciel fournit les différentes fonctionnalités
recherchées. Elle composée de :
• Conception générale
Conception architecturale : déterminer la structure du système
Conception des interfaces : déterminer la façon dont les différentes parties du
système agissent entre elles
• Conception détaillée : déterminer les algorithmes pour les différentes parties du système
Réalisation : codage et programmation, traduction dans des langages exploitables par des
ordinateurs.
Tests : La phase de test permets d'essayer le logiciel sur des données d’exemple pour s’assurer
qu’il fonctionne correctement. Il existe plusieurs types de tests :
• Tests unitaires : faire tester les parties du logiciel par leurs développeurs
• Tests d’intégration : tester pendant l’intégration
• Tests de validation : tests choisis par le client pour déterminer s’il peut accepter le logiciel
• Tests système : tester dans un environnement proche de l’environnement de production.
• Tests Alpha : faire tester par le client sur le site de développement
• Tests Bêta : faire tester par le client sur le site de production
• Tests de régression : enregistrer les résultats des tests et les comparer à ceux des anciennes
versions pour vérifier si la nouvelle n’en a pas dégradé d’autres
Exploitation : (utilisation du logiciel)
Consiste à fournir au client une solution logicielle qui fonctionne correctement. Elle est composée
de :
• Installation : rendre le logiciel opérationnel sur le site du client
• Formation : enseigner aux utilisateurs à se servir du logiciel
• Assistance : répondre aux questions des utilisateur
Maintenance : correction des erreurs, améliorations des fonctions, ajout de nouvelles
fonctionnalités...

2.2. Documents courants :

Dans ce qui suit nous introduisons les documents qui interviennent lors du cycle de vie d'un
logiciel.
Cahier de charges : Description initiale des fonctionnalités désirées, parfois écrite par l’utilisateur.
Spécifications : Décrit précisément les conditions que doit remplir le logiciel. Ce document
contient :
• Le modèle objet : indique les classes et les documents principaux
• Les scénarios des cas d’utilisation : indique les différents enchainements possibles du
point de vue de l’utilisateur
Calendrier du projet : Permet de décrire l'ordre des différentes tâches, de les détailler ainsi que
les ressources qu’elles demandent
Plan de test du logiciel :Décrit les procédures de tests appliquées au logiciel pour contrôler son bon
fonctionnement
Plan d’assurance qualité :Décrit les activités mises en œuvre pour garantir la qualité du logiciel, il
intervient lors de la planification.
Manuel utilisateur final :Mode d’emploi pour le logiciel dans sa version finale. Intervient lors de
la phase de Réalisation.
Code source :Code complet du produit fini
Rapport des tests : Décrit les tests effectués et les réactions du système
Rapport des défauts : Décrit les comportements du système qui n’ont pas satisfait le client. Il
s’agit le plus souvent de défaillances du logiciel ou d’erreurs.

Document Phase de production

Manuel utilisateur final Réalisation
Conception architecturale Conception
Plan d'assurance qualité Planification
Code source Réalisation
Cahier des charges Analyse
Plan de tests Spécification
Manuel utilisateur préliminaire Spécification
Conception détaillée Conception
Estimation des couts Planification
Calendrier du projet Planification
Rapport de tests Tests
Documentation Réalisation

2.3. Modèles de cycle de vie d'un logiciel

Il n’existe pas une seule méthode ou approche pour développer un logiciel, c’est un domaine qui est
toujours en pleine évolution.
Les principales approches du développement qui seront commentées :
– Modèle en cascade et cycle en V (modèles linéaires ),
– le modèle en spirale et prototypage (modelés non linéaires)
 1) Processus de développement en Cascade :
Caractéristiques :
• Chaque étape doit être terminée avant que ne commence la suivante.
• À chaque étape, production d'un document base de l'étape suivante
• Hérité des méthodes classiques d'ingénierie

Inconvénients :
• Découverte d'une erreur entraine retour à la phase à l'origine de l'erreur et nouvelle cascade,
avec de nouveaux documents...
• Cout de modification d'une erreur important, donc choix en amont cruciaux (typique d'une
production industrielle)
• Pas toujours adapté à une production logicielle, en particulier si besoins du client changeants
ou difficiles à spécifier.

2) Pro
cessus de développement en V
Caractéristiques :
• Variante du modèle en cascade
• Mise en évidence de la complémentarité des phases menant à la réalisation et des phases de
test permettant de les valider
• Adapté pour des projets dont le domaine est bien maitrisé

Inconvénients : Hérite des inconvénients du cycle de vie en cascade

• Processus lourd, difficile de revenir en arrière
• Nécessite des spécifications précises et stables
 • Beaucoup de documentation

3) Processus de développement en Spirale

Caractéristiques :
• Le cycle se compose de plusieurs itérations.
• C’est un processus assez intéressant pour les développements objets.
• On produit d’abord un prototype qui est affiné au cours des différents tours de la spirale.
• A chaque cycle on doit reproduire les étapes : Consultation du client, Analyse des risques,
Conception, Implémentation, Tests et Planification du prochain cycle.

Avantages :
• Une plus grande attention sur la ré utilisabilité,
• Meilleure élimination des erreurs,
• Objectifs de qualité pris en compte dès le commencement du processus de développement,
• Intègre maintenance et développement dans un même contexte.

Inconvénient principal : nécessite une (très) grande expérience.

 4) Prototypage
Caractéristiques :
• Un prototype : version d’essai du logiciel pour tester les différents concepts et exigences et
montrer aux clients les fonctions que l’on veut mettre en œuvre.
• Lorsque le client a donné son accord, le développement suit souvent un cycle de vie linéaire

Avantage principal : Les efforts consacrés au développement d’un prototype sont le plus
souvent compensés par ceux gagnés à ne pas développer de fonctions inutiles

2.4. Modèles de processus logiciels

Un modèle de processus logiciels décrit :

• Les tâches
• Les artéfacts (fichiers, documents, données...) : tout produit d'un travail.
• Les auteurs
• Les décisions (facultatif)

Règles à observer
• Deux tâches doivent être séparées par un artéfacts
• Une tâche ne peut être exécutée tant que ses artéfacts d’entrée n’existent pas
• Il doit y avoir au moins une tâche de début et une tâche de fin
Il doit y avoir un trajet depuis chaque tâche jusqu’à la tâche de fin

Exemple d'un processus logiciel :

Diagrammes de flots de données (data flow diagrams)

 • utilisés pour la modélisation des traitements
• permettent de montrer comment chaque processus transforme ses entrées (flots de données
entrants) en sorties correspondantes (flots de données sortants)
• intégrés dans diverses méthodes
• peut être complété par les diagrammes de contextes (permettant de représenter le flot de
données avec les acteurs externes).
• Indique la circulation des données à travers un ensemble de composants qui peuvent être
des tâches, des composants logiciels...

Règles à observer
Les processus sont représentés par des cases qui contiennent des phrases verbales
Les flèches représentent des données et doivent être :
• accompagnées de phrases nominales
• Un processus peut être une activité ponctuelle ou continue

• Deux flèches sortant d’une case peuvent indiquer : Soit deux sorties simultanées, soit deux
sorties exclusives.

Chapitre 2 : Conduite de projets

1) Gestion de Projets :
Lors de la gestion de projet on rencontre essentiellement des problème humains. Pour maitriser ses
problème il faut correctement planifier la progression du développement du logiciel et motiver et
coordonner un groupe de professionnels.
Les techniques de gestion projets logiciels sont souvent communes à la gestion de projet en
général. La différence se présente dans le problème particulier de la visibilité :
Un projet logiciel apparaît souvent à ses développeurs comme presque achevé alors qu’il ne l’est
qu’à 90%.

1.1. Pratiques critiques de la gestion de projets

Pratiques du chef de projet :
• Opter pour une gestion des risques continue : Prévoir des étapes réparties sur l’ensemble du
cycle de vie consacrées à l’identification et à l’évaluation des risques, ainsi que des tâches
pour y remédier
 • Estimer les cout et planifier le projet à partir de données empiriques : Prévoir une étape au
début du cycle de vie pour évaluer le cout du projet et une série d’étapes ultérieures pour
raffiner cette estimation. Au cours de chaque étape, les données devront être archivées pour
les évaluations ultérieures
• Utiliser des métriques pour la gestion du projet : Choisir des métriques et prévoir des étapes
pour enregistrer les valeurs de celles-ci, et d’autres pour analyser les progrès en fonction de
ces résultats
• Suivre l’évolution de la valeur acquise
• Rechercher les défauts en fonction des objectifs de qualité : Déterminer des objectifs pour le
nombre de rapports d’erreurs et prévoir des étapes pour communiquer ces résultats
• Considérer les employés comme la ressource la plus importante : Contrôler l’ensemble du
processus logiciel pour estimer son impact sur le programmeur
• Utiliser un outil de gestion de configuration : s'assurer que les modifications du logiciel sont
effectuées de manière à minimiser les cout globaux et garder la trace des différences entre
les versions pour contrôler les nouvelles versions
• Gérer et suivre l’évolution des besoins : Prévoir des étapes pour recueillir les besoins des
utilisateurs
• Orienter la conception en fonction du système visé
• Définir et contrôler les interfaces
• Concevoir plusieurs fois pour ne coder qu’une seule :Prévoir des étapes pour contrôler la
conception
• Identifier les éléments potentiellement réutilisables
• Contrôler les spécifications
• Organiser les tests comme un processus continu : Prévoir des étapes de tests dans toutes les
phases

1.2. Analyse de la valeur acquise

La méthode de la Valeur Acquise consiste à évaluer et comparer ce qui devait être fait et ce qui a été
réellement fait, en termes d’avancement réel et de dépenses réelles.
Avant de calculer la valeur acquise, on doit prendre quelques mesures qui nous permettent d’estimer
les quantités de travail.
Ces quantités de travail sont estimés en nombre de jour-hommes.
Le nombre de jour-hommes (j.h) correspond au nombre d’hommes et de journées nécessaires pour
accomplir la charge de travail liée à une charge donnée. La charge de travail totale liée à une tâche
peut s’exprimer en ETP (Équivalent Temps Plein), c’est à dire en nombre de j.h.
Il faut évaluer les besoins en jour-hommes, c’est à dire combien de ressources humaines et de temps
sont nécessaires pour accomplir une tâche. Par exemple, la charge de travail nécessaire pour
effectuer la tâche A s’élevant à 20 j.h (ou 20 ETP) correspond à un homme travaillant à temps plein
sur vingt jours ou un homme à mi-temps pendant quarante jours ou encore deux hommes travaillant
à temps plein pendant dix jours ou deux hommes à mi-temps pendant vingt jours.
1.2.1.Mesures de base :
CBT : coût budgété du travail : quantité de travail estimée pour une tâche donnée
CBTP : coût budgété du travail prévu :Somme des quantités de travail estimées pour l’ensemble
des tâche devant être achevées à une date donnée
CBA : coût budgété à l’achèvement : Total des CBTP et donc l’estimation de la quantité de travail
pour le projet entier
VP : valeur prévue :Proportion de la quantité de travail totale estimée attribuée à une tâche donnée
VP = CBT /CBA
CBTE : coût budgété du travail effectué : Somme des quantités de travail estimées pour les tâche
achevées à une date donnée
CRTE : coût réel du travail effectué : Somme des quantités de travail réelles pour l’ensemble des
tâche du projet

1.2.2 Indicateurs :
On en déduit deux indicateurs de variance traduisant les écarts entre le réel et le planifié:
• La variance de coût : VC = CBTE − CRTE. Qu’est-ce que j’ai réellement reçu (en valeur du
travail) par rapport à ce que j’ai réellement dépensé ?
• La variance de temps (par rapport à l’échéancier) : VE = CBTE − CBTP. Qu’est-ce que j’ai
réellement fait par rapport à ce que j’avais prévu de faire?
La particularité de la variance de temps est qu’elle traduit un retard sous une échelle financière. Elle
est bien sûr à associer à une estimation temporelle du retard possible.
On associe à ces indicateurs de variance deux autres indicateurs qui traduisent le même phénomène
mais sont complémentaires pour indiquer des problèmes en relatif (%)

• Indicateur de performance coût : IC = CBTE /CRTE

• Indicateur de performance temporel : IPT = CBTE /CBTP

1.2.3.Valeur acquise :
VA : Valeur acquise : représente le rapport du coût du travail effectué au coût travail nécessaire
pour tout le projet.
VA = CBTE /CBA = somme des VP pour les tâches achevées
= PA (pourcentage achevé)

Exemple :
Tache Travail estimé (jh) Travail réel à Date Date
aujourd’hui d’achèvement d’achèvement
estimée effective
A 5 10 25/01 01/02
B 25 20 15/02 15/02
C 120 80 15/05
D 40 50 15/04 15/04
E 60 50 01/07
F 80 70 01/09

Question : calculer les indicateurs d’avancement au 01/04 ?

CBA : somme des estimations des quantités de travail : CBA = 330jh

Au 01/04, les taches 1,2 et 4 sont achevées, le CBTE est la somme des CBT pour ces taches :CBTE
= 70jh
VA = 70/330 = 21.2%
Les taches 1 et 2 devaient être achevées pour le 01/04, et pas 1,2 et 4 : CBTP = 30
IPT = 70/30 = 233%
VE = 70 − 30 = +40jh
La CRTE est la somme des quantités de travail réelles pour les taches 1,2 et 4 : CRTE = 80jh
IC = 70/80 = 87.5%
VC = 70 − 80 = −10jh

1.3 Suivi des erreurs :

Le suivi des erreurs consiste a conserver une trace des erreurs qui se sont produites en spécifiant la
durée entre deux erreurs successives. Cela permet de mieux déterminer la date de livraison ainsi
que de motiver les testeurs et les développeur.
Taux d'erreur : le taux d'erreur est l'inverse du temps qui sépare deux erreurs successives
Exemple : si une erreur se produit tous les deux jours, TE = 0.5 erreurs par jour.
Taux d’erreur instantané : permet une estimation du taux d’erreur courant
Taux d’erreur cumulé : permet une bonne estimation des taux d’erreur à venir. C'est la somme de
toutes les erreurs divisé par le temps total
Une représentation graphique permet d’estimer les tendances des taux d’erreur par régression
linéaire. Sur le graphique , l 'axe des y représente le taux d’erreurs. Pour l'axe des x, deux situations
sont possibles :
• si nous souhaitons estimer le nombre d'erreur restantes alors l'axe des x devra représenter le
nombre d'erreur
• par contre si nous souhaitons estimer le temps avant livraison il faut que l'axe des x
représente le temps.

Exemple :
Les durées entre une série d’erreurs sont les suivantes : 4, 3, 5, 6, 4, 6, 7. Calculons le taux d'erreur
instantané :
Si on prolonge cette courbe, on voit qu’elle coupe l’axe des abscisses (l'axe des x ) pour une valeur
de 11 erreurs environ. Le taux d’erreur devrait donc être nul (y = 0) après la 11eme erreur. Comme
7 erreurs ont été trouvées, il ne devrait plus en rester que 4.

2) Planification de projet :
La planification est un élément essentiel de la gestion de projets, il consiste à déterminer les taches à
accomplir ainsi que leurs ordre et décider des ressources à allouer aux différentes taches .

2.1 Organigramme technique :

Un organigramme technique permet de diviser le projet en différentes taches dans le but de
déterminer les livrables et jalons qui permettront de mesureur l'avancement du projet.
On appelle livrable tout résultat, document, mesurable, tangible ou vérifiable, qui résulte de
l 'achèvement d'une partie de projet ou du projet.
Un jalon dans la gestion de projet représente un évènement clé d'un projet. C'est un repère
permettant de déterminer de l'avancement d'un projet. Il est, en général, assimilé à la fin d'une
étape ou d'un travail.
Lorsque la notion de jalons est utilisé en combinaison avec une méthodologie de planification telle
que la méthode de PERT, ils permettent aux gestionnaires de projet de déterminer de manière plus
précise si le livrable du projet est en retard ou non.

Work Breakdown Structure (WBS) :

Le WBS est un organigramme technique ayant une structure arborescente, où le premier niveau de
décomposition correspond au modèle de cycle de vie utilisé.
Règles d’obtention d’un organigramme technique :
• Pas de boucle
• Les actions itératives apparaissent dans le modèle de processus ou dans le modèle de cycle
de vie
 • Les descriptions des taches et des livrables doivent être claires et sans ambigüité
• Chaque livrable doit être associé ́ à une tache, sans quoi il ne sera pas produit
• Chaque tache doit avoir un critère d’achèvement : Le plus souvent un livrable
• L’achèvement de toutes les sous-taches doit entrainer l’achèvement de la tache
(Exemple détaillé vu en cours).

2.2. Methode PERT :

PERT est l'acronyme de Program Evaluation and Review Technique. C'est une méthode de gestion
de projets, de planification et d'ordonnancement. elle consiste en 3 étapes :
• Identifier les taches et estimer leur dur é
• Ordonner les tâches
• Construire le réseau et l’exploiter

(Exemple détaillé vu en cours).

2.3. Estimation des couts : Modèle COCOMO :

2.3.1 . Modèle COCOMO de base :

Le modèle COCOMO (COnstructive COst Model) est un modèle d'estimation de cout de
développement ( en mois homme) et de temps de développement (en mois) en fonction du nombre
de lignes de code (en KLOC).
Il s'applique selon le type de projets, répertorié dans l'une des trois catégories :
• Mode organique :
◦ petites équipes
◦ applications bien maitrisées
◦ Pas de besoins non fonctionnels difficiles
• Mode semi- détaché :
◦ Expérience variée des membres de l’équipe
◦ application non maitrisée par l’équipe
◦ Possibilité d'avoir des contraintes non fonctionnelles importantes
• Mode embarqué :
◦ Contraintes difficiles
◦ Peu d’expérience des membres de l’équipe sur les applications de ce type
◦ Problèmes complexes
2.3.2. Calcul de l'effort

2.3.3. Calcul du temps de développement

3) Assurance qualité :
La qualité est une notion difficile à définir, selon la définition de la norme ISO 8402 c'est : «
l’ensemble des caractéristiques d’une entité qui lui confèrent l’aptitude à satisfaire des besoin
exprimés et implicites ». Un logiciel est dit de qualité lorsqu'il fonctionne correctement.
Il est plus facile de mesurer les défauts que contient un logiciel que sa qualité. Pour cela, si on
souhaite juger de la qualité d'un logiciel, on se réfère au degré de mécontentement du client ou
nombre de rapports d'erreurs. On vous propose dans cette partie du cours d'utiliser les « inspections
formelles » pour assurer la qualité du logiciel produit.

3.1 . Inspections formelles :

C'est une activité formelle et planifiée, où un concepteur présente des documents sur un projet à un
groupe d’autres concepteurs qui en évaluent les aspects techniques avec pour objectif de trouver les
erreurs. L'inspection formelle porte sur un produit fini (pas un document en cours de
développement). Les inspections formelles se font de façon périodiques au cours du processus de
développement.
L’équipe qui effectue l'inspection formelle est constituée de :
 • un modérateur : c'est celui qui dirige l'inspection et choisit les membres de l’équipe
• un lecteur : c'est celui qui guide l’équipe dans la compréhension et la structure du produit
inspecté
• un secrétaire : Il décrit en détails par écrit le déroulement de l' inspection, il note toutes les
erreurs trouvées
• L'auteur : C'est celui qui développe le produit examiné , il répond aux questionnements des
membres qui effectuent l'inspection. À la fin de l'inspection, il corrige les erreurs trouvées et
fait un rapport au modérateur.

3.1.1. Étapes de l'inspection :

• La présentation générale par l’auteur au reste de l’équipe
• La préparation : Les membres de l’ équipe étudient le produit dans la limite d’un temps
calculé en fonction du nombre de lignes de code (LOC)
• Les réunion pour l’inspection : Elles sont organisées par le modérateur. Le lecteur conduit
l’inspection. Le secrétaire consigne les problèmes dans un rapport
• L'intégration des remarques : l’auteur corrige les erreurs
• Le suivi : Le modérateur contrôle le rapport de l'auteur et les corrections. Quand toutes les
toutes les remarques ont été prises en compte, l'inspection prend fin.