Cours AGL 2020

2020/2021
Cours Ateliers Génie

logiciel
Notions de base sur le GL et
Applications
Dr. Aymen LOUATI

Aymen.louati@live.fr
(+216) 95 33 53 75
Avant-propos
Ce cours concerne le module « Ateliers GL". Il s'adresse aux étudiants des
3ème années LA (réseaux - Multimédia) et 2ème Années LFSI. La finalié est
de se familiariser au domaine du génie logiciel, ses enjeux et ses
applications.
Des méthodes et des techniques permettant d’assurer le développement et

la maintenance des systèmes logiciels sûrs et de qualités seront
introduites, pour les phases du cycle de vie du logiciel.
1. Définir ce qu’est le génie logiciel, son application (AGL +

exemple) et en comprendre les enjeux requis.
2. Expliquer le cycle de vie d’un logiciel, décrire et comparer
certains processus de développement.
3. Décrire les qualités d’un logiciel et ses principes de base.
Plan
Chapitre1: Introduction au Génie Logiciel (AGL)

Chapitre2: Fonctionnalités de base pour le
management d’un projet
Chapitre3: Processus de développement – Exemple
d’une démarche de développement objets basée UML
Chapitre4: Les découpages et les modèles de
développement
Chapitre5: Facteurs et Critères de Qualité du logiciel
20/10/2020 Dr. Aymen LOUATI 3

Plan

Chapitre2: Fonctionnalités de base pour le management
d’un projet
Chapitre3: Processus de développement – Exemple d’une
démarche de développement objet basée UML
développement

Définition du « logiciel »
Un logiciel est :
1) L’ensemble des instructions qui après leurs exécutions nous

fournissent la fonction et la performance désirée,
2) Les structures de données qui permettent aux programmes

de manipuler adéquatement l’information,
3) Des documents qui décrivent les opérations et l’utilisation

des programmes.

La nature du logiciel
 Facilité à reproduire
 Tout le coût se trouve dans son développement
 Pour d’autres produits, la fabrication est souvent le processus le plus coûteux
 Intangibilité
 Il est difficile d'estimer l’effort de développement
 Difficulté à automatiser le processus de développement

 L’industrie du logiciel exige beaucoup de main d’œuvre

Utilité du logiciel
En dépit des énormes succès, la réputation de l’industrie du logiciel

n’est pas si glorieuse que cela:
 Dépassement de budget,
 Dépassement d’échéance,
 Mauvaises fonctions livrées,
 Erreurs (bugs) et autres problèmes,

Source d’échec (1)
Raisons pour lesquelles le logiciel vieillit

 maintenance (e.g., bug fixes)
 inflexibilité dès le début
 documentation insuffisante ou inconsistante
 manque de modularité
 complexité croissante
 ...

Quelques statistiques

Source d’échec (2)
• Beaucoup de logiciels sont mal conçus et se détériorent

rapidement
• La demande du logiciel est toujours croissante
L’ingénierie du logiciel est une nécessité

(un processus systématique au lieu d’un bricolage)

Génie Logiciel: Définition

 Autrement dit:
C’est « l'art » de produire de bons logiciels, au meilleur rapport
qualité/prix.

Atelier Génie Logiciel (AGL): Définition
• Objectifs? • Comment ?
– Améliorer la – En faisant le suivi des
productivité, différentes phases du
– Améliorer le suivi, processus logiciel,
– Améliorer la qualité – En offrant un cadre
• fiabilité, cohérent et uniforme de
• maintenance, production.
• évolutivité.
Adaptation et Exploitation des outils CASE

(Computer Aided Software Engineering)
Un peu d’histoire …
• Années 50 et 60 : programmation empirique

– production "artisanale" de logiciels scientifiques
– royaume des "codeurs" et les "grands gourous"
• Fin des années 60 : la "crise du logiciel"

– difficulté de décrire de grands programmes
– difficulté de les utiliser, difficulté de les faire évoluer
– de nombreux projets échouent

Quelques statistiques
Étude du gouvernement américain en 1979
– Payés mais jamais livrés $3.2M 45%

– Livrés mais jamais utilisés $2.0M 30%
– Abandonnés ou refaits $1.3M 20%
– Utilisés après modification $0.2M 3%
– Utilisés tel quel $0.1M 2%

Exemples: Pannes logicielles
 La sonde vers Vénus s'est perdue dans l'espace.

Cause : une erreur de programme FORTRAN, virgule remplacée par
un point.
 Au passage de l'équateur un F16 ...

Cause : changement de signe de la latitude mal pris en compte.
 La lutte contre le bogue de l'an 2000 a coûté à la France 500 milliards

de francs.
Cause : la donnée "année" était codée sur deux caractères pour
gagner un peu de place.

Approches Méthodologiques
Crise de l'industrie du logiciel à la fin des années 60 :

– augmentation des coûts
– difficultés d'évolution
– non fiabilité
– non respect des spécifications
– non respect des délais
Importance d'approches méthodologiques
Apparition et développement du Génie Logiciel

Génie Logiciel: Objectifs
 Les coûts restent dans les limites prévues

au départ.
 Les délais restent dans les limites prévues

au départ.

Principes fondamentaux du GL
 Séparation des problèmes

 Modularité
 Abstraction (complexité)
 Anticipation du changement
 Construction incrémentale
 …

Plan

d’une démarche de développement objet basée UML
développement

Le déroulement d’un projet
1. Les intervenants
1.1. Le promoteur
1.2. Le mandataire
2. Les contraintes d’un projet
3. Le groupe de processus et le cycle de vie d’un
projet
3.1. La définition
3.2. La planification
3.3. L’exécution
3.4. La clôture

1. Les intervenants
1.1 Le promoteur (1)
 Qui est le promoteur ?

o L’organisation qui constate un besoin,
o L’organisation qui désire réaliser un projet pour
répondre au besoin,

1. Les intervenants
 Responsabilités avant le projet

o Sélection du projet
o Étude de faisabilité
o Décision de réaliser

1. Les intervenants
 Responsabilités pendant le/la:

o Choix du mandataire
o Approbation des plans d’exécution
o Surveillance de l’exécution
 Responsabilité après
o Évaluation

1. Les intervenants
 Risques et profits du promoteur

o Investit les fonds requis pour la réalisation
o Assume les risques
o Tire son profit de l’exploitation de l’extrant du
projet

1. Les intervenants
1.2 Le mandataire (1)

 Qui est le mandataire ?
o L’organisation qui exécute le projet
o Le promoteur peut agir à titre de mandataire

1. Les intervenants
 Responsabilités avant
o Planifier le projet en détail
o Créer la liste des tâches
o Établir l’échéancier
o Répartir le budget
o Vérifier la disponibilité des ressources

1. Les intervenants
 Responsabilités pendant
o Exécuter le projet
o Produire et livrer l’extrant
o Respecter les termes du mandat
 Responsabilité après
o Préparer un rapport de clôture

1. Les intervenants
 Risques et profits du mandataire

o Tire ses revenus et ses profits de l’exécution efficace
du mandat
o Assume les risques prévus au contrat

Résumons (1):
 Le promoteur
o Veut que le projet se réalise,
o Investit ($ ou ressources) dans le projet,
o Reçoit l’extrant du projet et l’exploite,
 Le mandataire
o Reçoit son mandat du promoteur,
o Fournit les ressources, est rémunéré,
o Produit l’extrant en respectant les contraintes ($, T, Q)

Résumons (2):
 Le chargé de projet (Chef d’orchestre)

o Planifie, dirige, contrôle, ajuste,
o Employé par le mandataire,
o Lien entre les autres intervenants,
 L’équipe de projet réalise les tâches
 Les utilisateurs
o Bénéficiaires de l’extrant du projet,
o Déterminent la réussite ou l’échec,
o Devraient être impliqués dès le début,

Résumons (3):
Le chargé de projet
Le mandataire
Le promoteur
Réalise le
projet
Lance un appel
d’offres Approuve les Livre l’extrant
plans du projet
Analyse de la Répond à l’appel Planifie le Approuve
faisabilité d’offres projet l’extrant
Identifie un Sélectionne le
projet mandataire
Constate un
Les utilisateurs
besoin
Début Fin
2. Les contraintes d’un projet (1)
 Coût
o Réaliser le projet en respectant le budget
 Temps
o Réaliser le projet dans les délais prescrits
 Qualité
o Livrer l’extrant selon les spécifications du
promoteur

2. Les contraintes d’un projet (2)
La gestion de projet :
une question
d’équilibre !

3. Le cycle de vie d’un projet (1)
 La définition,
 La planification,
 L’exécution,
 Le suivi et contrôle,
 La clôture,

3. Le cycle de vie d’un projet (2)

3.1 Le cycle de vie d’un projet: Définition (1)
 But
o Prendre une décision relative à la réalisation d’un
projet
 Activités
o Identification d’un besoin
o Identification d’un projet comme réponse au
besoin
o Définition du projet : paramètres clés
o Analyse de faisabilité
 Sous la responsabilité du promoteur

3.1 Le cycle de vie d’un projet: Définition (2)
 À la fin de la définition
o Décision du promoteur de réaliser le projet
o Choix du mandataire par le promoteur
o Recherche de financement

3.2 Le cycle de vie d’un projet: Planification (1)
 But
o Planifier l’affectation des ressources au calendrier
d’exécution du projet
 Activités
o Déterminer le travail à faire
o Établir l’échéancier
o Répartir le budget
o Affecter les ressources
 Sous la responsabilité du mandataire

3.2 Le cycle de vie d’un projet: Planification (2)
 À la fin de la planification
o Approbation du plan d’exécution par le promoteur
o Mise en route du projet par le mandataire

3.3 Le cycle de vie d’un projet: Exécution (1)
 Buts
o Produire l’extrant et le livrer au promoteur
o Respecter les contraintes ($, T, Q)
 Activités
o Direction et coordination
o Contrôle de l’avancement (T)
o Contrôle des coûts ($)
o Contrôle de la qualité (Q)
o Gestion des changements
 Sous la responsabilité du mandataire

3.3 Le cycle de vie d’un projet: Exécution (2)
 À la fin de l’exécution
o Approbation de l’extrant par le promoteur
o Fin du projet par le mandataire

3.4 Le cycle de vie d’un projet: Clôture (1)
 But
o Dégager les leçons techniques et de gestion que l’on
peut tirer du projet complété
 Pour le promoteur
o Choix du projet et du mandataire
o Exploitation de l’extrant
o Rentabilité du projet
 Pour le mandataire
o Planification
o Choix et affectation des ressources
o Rentabilité du mandat
3.4 Le cycle de vie d’un projet: Clôture (2)
 Activités du promoteur
o Clore tous les dossiers en cours
o Archiver les documents importants
 Activités du mandataire
o Clore tous les dossiers en cours
o Archiver les documents importants
o Libérer et réaffecter les ressources

Plan

développement

Étapes du processus de développement
Analyse des
Spécifications
besoins
Analyse du
Maintenance système
Validation Conception
Implémentation

Analyse des besoins
Étape préalable si le client n’a pas une idée précise

du système à réaliser
o Étude informelle des fonctionnalités (externes) du

système sans considération technique: Point de vue
métier / utilisateur
o Aide au formalisme du problème à résoudre
o Production de documents textuels avec schémas,

graphes, etc.

Spécifications
Ce que doit faire le système côté client

o Document précis spécifiant les fonctionnalités
attendues (contour fonctionnel)
o Base du contrat commercial avec le client
o Document facile à comprendre par le client / utilisateur
o (scénarios, interactions, enchaînement d’écrans)
Les spécifications ne sont jamais complètes et définitives

(évolution du domaine, besoins supplémentaires, …)

Analyse du système
Quoi faire ? : comprendre et modéliser le métier

o Réflexion métier hors de toute considération technique
o Reste un support de discussion avec le client/utilisateur
(questions/réponses)
o Premier modèle du système (niveau métier)
o Identifier les éléments intervenant (acteurs) hors et
dans le système: fonctionnalités, structure et
relations, états par lesquels ils passent suivant
certains événements
L’analyse n’est jamais complète, mais elle doit être juste
Établissement du cahier des charges
et des contraintes du système
Conception
Comment faire le système: choix techniques

 Choix d’une architecture technique (matérielle,
logicielle) suivant certaines contraintes (robustesse,
efficacité, performances, portabilité …)
 Expertise informatique: hors compréhension du client
 Modèle de l’architecture logicielle du système
• Décomposition en sous systèmes: application
(interfaces), domaine (métier) et infrastructure
(implémentation)
• Permet la définition des phases d’implémentions,
de validation et de maintenances
Production d’un modèle du système final
en cohérence avec les choix d’architecture
Implémentation
 Trop de temps consacré à cette phase au détriment

d’analyse et de conception: mauvaise pratique, parfois
très coûteuse …
 Nécessite un savoir de la réutilisabilité des

composants, voir d’outils de génération de code (voir
MDA)
 L’activité sera de plus en plus tournée vers la

réutilisation des composants existants

Validation
 Tests de vérification
o Vérification de la robustesse et cohérence du système,
en particulier dans les cas d’exceptions
o Testeur est différent du concepteur ou du développeur
o Logiciels de tests: toute ligne de code doit être testée
o Différentes méthodes de validation (voir cours
méthodes formelles)
 Recette
o Validation client: accord avec les besoins
o Planification dès spécifications: cahier de recettes
 Activité souvent sous estimée

Maintenance
 Deux types de maintenance

o Correction des erreurs du système
o Demande d’évolution (modification de l’environnement
technique, nouvelle fonctionnalités …)
 Facteurs da qualité essentiels
o Corrections: robustesse
o Évolution: modificabilité, portabilité
 Étape longue, critique et coûteuse

o Une enquête effectuée aux USA en 1986 auprès de 55
entreprises a révélé que 53% du budget total d'un
logiciel est affecté à la maintenance

Exemple d’une
démarche Orientée
objets Basée sur le
langage UML

1. Avoir la discipline d’appliquer une bonne
démarche de développement de logiciel.
2. Réaliser son application utilisant le formalisme

UML et le bon outil CASE (Computer-Aided
Software Engineering).
3. Arriver à visualiser les problèmes, préciser les

comportements et les structures, fournir un
guide pour la réalisation, documenter les
décisions.

Modélisation: Contexte et Objectifs
 Complexité croissante des systèmes de plus en plus.
 Coût élevé de l’échec dans les systèmes critiques.
 Besoins de:
o Réutilisation
o Modélisation
o Abstraction
 Une production fiable et une conformité des

besoins.
 Une bonne démarche de modélisation.
 Une Sécurité de communication et une
rapidité d’exécution.
20/10/2020 ISI Kef Workshop 57

Modélisation
 Satisfaction du client.
 Production d’applications de qualité.
 Simplification de la réalité.
 Mieux appréhender le système.
Utiliser les bon outils de communication
 Le choix des modèles simplifie la manière d’aborder le
problème et sa solution.
 Décomposer le système en un ensemble de modèles pour en
améliorer la compréhension.
La modélisation est une des caractéristiques d’un

projet qui réussi
Pourquoi modéliser
 Fournir des spécifications claires : produire, exploiter, etc.
 Clarifier les objets, les concepts, les référentiels, les
processus.
Réponses possibles aux questions suivantes

o Pour quel processus je travaille?
o Quel rôle j’ai dans ce processus?
o Quel est l’ensemble des processus de mon entreprise?
Modéliser  Générer des modèles

 Abstraction de la réalité.
 Vue subjective mais pertinente de la réalité.

Modèle: Exemple
1er modèle
proposé
Système
= Réalité
3ème modèle
2ème modèle proposé
proposé

 Unified Modeling Language (uniquement un
langage et pas une méthode).
 Un fruit d’une évolution des méthodes orientées
objet.
 Une notation de plus en plus répandue (connue,
enseignée, supportée par les outils…).
 Pas de nécessité d’avoir des compétences métier:
fonctionnels et développeurs ont un langage commun.

Les diagrammes UML2.5
Vue statique Vue dynamique
Diagramme Diagramme
Diagramme Machine Diagramme de
de classe d’objets
d’activité d’états UML cas d’utilisation
Diagramme de Diagramme de Diagrammes

composants déploiement d’interaction
Diagramme de Diagramme de
séquence communication
Diagramme de Diagramme de Diagramme de Diagramme global Diagramme

profile structure composite paquetages d’interaction de timing
Nouveaux sous UML2
 Représentation
Possibilité
Diversité dede diagrammes
visualiser
graphiqueet pour
d’une
manipuler
séquence
une des éléments
d’opérations
modélisation de
sous
modélisation
ou de la structure
plusieurs angles d’un système
Domaine d’application
– Les systèmes informatiques d’entreprise,

– Les banques,
– Les télécoms,
– Les transports,
– La défense,
– Le web et etc.
– Même les plus gros projets peuvent être spécifiés et
maintenus en UML.
Quelques problèmes de communication

 Diagrammes complexes: difficiles à comprendre.
 Panoplie de diagrammes: perdre la direction.
Modélisation et Démarche
Un
 UMLbon
est-il Informaticien
la bonne solution? est un bon
 Comment appliquer la bonne démarche?
développeur,
 UML est unOUI c’est vrai
avantage pourmais ?????
la modélisation
ouTrès
une bon
 Comment ANALYSTE
générer
perte delestemps –pour
Trèslivrer
bon modèles? bon un
produit? CONCEPTEUR
1. Echanger avec son client
– Définir ensemble un diagramme de cas d’utilisation.
– Valider ensemble les scénarios.
2. Analyser et concevoir le système

– A partir des Uses Cases et des scénarios, définir le
diagramme de classe.
– A partir des scénarios, définir les diagrammes de
séquence et de collaboration (et enrichir les classes).
– Définir si besoins les diagrammes d’états…..
 Démarche linéaire (Modèle de la cascade),
 Processus Unifié (UP) (Modèle itératif),
 2Truck UP (Modèle en Y),
 Etc.… (panoplie de démarches et de modèles),
Simplifier une démarche

Proposition d’une démarche de
développement itérative et incrémentale par
activités s’inspirant du UP.

Démarche de développement Objet
Nécessité d’un outil de modélisation (CASE) + Sélection
de l’environnement de développement du projet
pivot à toute la conception.

Suite
Diagrammes de séquences
Diagrammes de classes (Modélisation de scénarios par
(Modélisation du domaine) échanges de messages)
Diagrammes d’activités Diagrammes de classe de

(Modélisation de processus conception
d’affaires ou autres) (objets, encapsulation, etc.)
Un même type de diagramme peut :
 Modéliser des concepts différents,
 Être utilisé à des moments différents du processus de
développement,
 Être à différents niveaux d’abstraction,
 Ne pas être utilisé,

Plan

développement

Découpage Temporel du Projet
Permet de répartir le travail dans le temps:

Étapes, Phases, Tâches, Livrables
Livrable
1..*
1..* 1..* 1..*

1 1 1 1
Projet Étape Phase Tâche
1 * 1 * 1 *
* *
*
*
2 2 2
Date

Découpage Structurel du Projet
Permet d’organiser le travail en se basant sur la structure du produit final.
Projet Module
est découpé en se décompose en
1 1..*
0..1
*
Avantages
 Maîtriser le projet
 Répartir les responsabilités
 Réduire les délais planifiés
 Avoir un développement incrémental
 Découpage statique (niveau 1)
 Découpage dynamique (niveau 2)
Les modèles de développement: le cycle de vie
 Définition d’un modèle de développement

 modèle temporel générique.
 Comprend des étapes et des phases
 n’est pas obligatoirement linéaire.
 Il existe plusieurs types de modèles de développement

Cycle de Vie
Temps qui mène du point de départ à l'exploitation du

système en passant par:
Sa naissance
Sa maturité
sa maintenance
Parcours allant de l'étude de l'objet naturel à l'intégration

du système artificiel à cet objet naturel

Les Modèles de Développement
1. Le modèle de la cascade
2. Le modèle de développement évolutif
3. Le modèle spécifique RUP
4. Le modèle du code-and-Fix
5. Le modèle en V
6. Le modèle en W
7. Le modèle de la spirale
8. Le modèle spécifique RAD
9. Etc …

1. Le Modèle de la Cascade
Validation
Faisabilité
Validation
Spécification
Vérification
Conception Générale
Vérification
Conception détaillée
Test Unitaires
Codage
Les phases sont séquentielles et obligatoires Test

Intégration d’intégration
Vérification = contrôle de conformité des travaux de la
phase / cahier des charges
Validation = contrôler que les travaux de la phase sont Exploitation et
correctement faits. maintenance
Utilisation des bonnes méthodes, des normes, nouvelles

technologies …)

 Démarche de réduction des risques

 Modèle orienté document
 Modèle suppose que CC est stable et prédéfini à l’avance
 Minimiser au fur et à mesure l’impact des incertitudes
 Exclusion des utilisateurs dès les phases de conception
« phases techniques »
 Contrôle qualitatif à la fin du projet
 Risque de refus du système par les utilisateurs

Cycle de vie séquentiel ou approche descendante

Adapté au projet simple et court (< 1an)
Validation ou vérification officielle à chaque étape
Toutes les étapes sont nécessaires et suffisantes
Effet ‘Tunnel’: Perte de visibilité

2. Le Modèle de développement évolutif
Détermination des Besoins
Programmation
Expérimentation
Version n

2. Le Modèle de développement évolutif
 Construction progressive du système de façon participative

 Complexité ou absence de spécifications claires et bien définies
 Obtention d’une nouvelle version à chaque cycle
 Arrêt du processus itératif quand le client est satisfait
 Contourner les difficultés
 Permet de tester les incertitudes très tôt dans le développement
 Simplifie l’élaboration des spécifications IHM. Les spécifications ne sont plus
écrites mais montrées
 Problèmes relatifs à la conduite du développement
 Problèmes relatifs à la gestion de projets
 Plusieurs itérations(spécifications, interfaces, choix techniques, …)

3. Le Modèle spécifique RUP
Combine plusieurs modèles

4 phases: incubation, élaboration, construction,
transition
6 activités: étude des besoins, analyse, conception,
implémentation, tests, déploiement présentent dans
toutes les étapes mais à des degrés différents
Plusieurs itérations: une itération correspond à un cycle
qui réunit les activités dans une étape

3. Le Modèle spécifique RUP (voir EUP, 2TUP)

4. Le Modèle du Code-and-Fix
Compréhension du problème
Programmation
Si Non Satisfaisant
Mise au point
Fin
Adapté pour les projets simples,

Itératif pour la mise au point jusqu’à satisfaction,
Collaboration avec les futurs utilisateurs,
Absence d’étape de conception,

5. Le Modèle en V

5. Le Modèle en V
 Amélioration du modèle de la cascade

 Nécessité de décomposition du système en sous-ensembles:
composants avec un maximum d’autonomie pour favoriser la
programmation (évaluation et validation par composant)
 Adapté pour les logiciels d’une certaine taille (5 à 7
personnes)
 Fractionnement du sous-système en éléments si la taille du
système dépasse la capacité d’une équipe

6. Le Modèle en W
 Enrichissement du modèle en V
 Identification des orientations solides pour la conception
 Exploration d’une nouvelle technique
 Validation et expérimentation de plusieurs prototypes ou maquettes
7. Modèle de la spirale
 Modèle non linéaire, orienté risque

 Nécessité d’une relation contractuelle entre le développeur et l’utilisateur
 Chaque cycle donne lieu à une contractualisation préalable s’appuyant sur les
besoins exprimés à l’étape précédente
 Développement de la version finale au dernier cycle

7. Modèle de la spirale
 Chaque cycle de la spirale est composé de:

1. Analyse du risque
2. Développement d ’un prototype
3. Simulation et essais du prototype
4. Détermination des besoins, à partir des résultats des essais
5. Validation des besoins par un comité de pilotage
6. Planification du cycle suivant
 Le dernier cycle comprend:
 en phase 2 développement de la version finale
 en phase 3 tests et installation
 et s ’arrête là.

8. Modèle Spécifique RAD
 Méthode de Développement Rapide: RAD,

 Combine les modèles en Cascade et en Spirale,
 Objectif: Développer une application de qualité et dans des délais réduits,
Initialisation
Expression des Besoins
Conception Le cycle RAD
Construction
Mise en œuvre

Plan

développement

Introduction

Qualité du logiciel : Définition
Aptitude d’un produit ou service à satisfaire les

AFNOR besoins d’un utilisateur
Aptitude d’un ensemble de caractéristiques

ISO 9001 intrinsèques à satisfaire des exigences.
Le degré avec lequel un système, un composant ou

IEEE un processus satisfait à ses exigences spécifiées et
répond aux besoins ou attentes de ses
clients/usagers.
Qualité du logiciel : Concepts
Moyens (procédures,
Vérification du respect des Assurance outils, critères) mis à
procédures et critères de Qualité disposition pour obtenir
qualité à des points un logiciel de qualité.
intermédiaires identifiés et
établis à l’avance.
Contrôle Plan
Qualité Qualité d’assurance
Qualité
Document associé à un
La politique de la qualité
projet qui définit les
de l’entreprise (méthodes,
méthodes, procédures et
procédures et outils à Manuel outils utilisés par le projet
utiliser ou à éliminer) Qualité

Qualité du logiciel : Composants
• un ensemble de vues concernant le produit.

Modèle • Une vue est décomposée en plusieurs facteurs.
• Ensemble d’attributs internes et externes.

Facteurs • qualité du point de vue du client (vision externe).
• S’obtient par des critères.
• Ensemble de métriques.
Critères • Qualité du point de vue du réalisateur(vision interne).
• Conditionnent des facteurs.
• Servent à quantifier un aspect d'un système

Métriques • Qualité du point de vue du contrôleur

Qualité du logiciel : Modèles
 McCall: (1977)
 Premier modèle de qualité logicielle.

 Définit une approche de la qualité à partir de la
définition de caractéristiques externes
(facteurs de qualité), internes (critères de
qualité), mesurables (métriques).
 Définit 23 critères sur 11 facteurs
 Différencie utilisateur et réalisateur.
ISO 9126 : (1991) dernière version 2001
• Standard dérivé du modèle de McCall

• Évaluation de produits logiciels (27 critères sur
6 facteurs)
• Exigences décrites sous forme de
caractéristiques et sous-caractéristiques qualité

ISO 25000 : SQuaRE (2005)

Software Product Quality Requirements and Evaluation
• Fusion de ISO 9126 et ISO 14598

• Organisation des facteurs par
domaines
• Définit 27 critères sur 6 facteurs.

Le logiciel est-il facile à demandées sont-elles
Les fonctionnalités
ISO 25000: Facteurs
transposer dansdans
présentes
environnements ?
d’autres
le logiciel ?
Peut-on faire confiance au

logiciel ?
Capacité
fonctionnelle
Portabilité
Fiabilité
Le logiciel est-il
facile à modifier ? ISO Le logiciel est-il
SQuaRE facile à utiliser ?
Maintenabilité
Utilisabilité
Rendement
Le logiciel est-il
performant ?
ISO 25000: (Facteurs, Critères)
•Validité Interopérabilité
Fonctionnalité •Précision Conformité règlementaire
•Sécurité
•Maturité
Fiabilité •Tolérance aux fautes
•Capacité de récupération
•Facilité de compréhension attractivité

Utilisabilité •Facilité d’apprentissage
•Facilité d’exploitation

Iso 25000: (Facteurs, Critères)
•Comportement vis-à-vis du temps

Rendement
•Comportement vis-à-vis des ressources
•Analysabilité Stabilité
Maintenabilité •Changeabilité Testabilité
•Installabilité Co-existance
Portabilité •compatibilité
•Adaptabilité

Fonctionnalité (fonctionality)
Fonctions du logiciel qui répondent à des besoins

explicites ou implicites des utilisateurs,
déclenchés par les événements d’affaires.

Fonctionnalité (fonctionality)
Critères
Validité(suitability)
Aptitude Précision(accuracy)
d’un produit logiciel de remplir
exactement ses fonctions définis par le cahier des
charges
Protection Interopérabilité(interoperability)
etdu
La précision sesest
spécifications.
système de données
un attribut contre
du logiciel quilaporte
divulgation,
lasurmodification ou de
la fourniture destruction
résultats ou et la protection
d’effets justesdes
et
systèmes
convenus. informatiques.
Conformité
la capacité de deux ouRéglementaire(compliance)
plusieurs systèmes ou
composants à échanger des informations et les
Attributs Sécurité(security)
utiliser. du logiciel selon lesquels ils respectent
l’application des ( normes, conventions,
règlementations, droits,
20/10/2020
prescriptions similaires).
Dr. Aymen LOUATI 105
Fiabilité (Reliability)
C’est probabilité d'un logiciel à accomplir

l’ensemble des fonctions spécifiées dans son
document de référence, dans un
environnement donné et pour un temps de
fonctionnement donné.
•C’est la capacité d’un logiciel à fonctionné avec

le minimum d’interruptions et d’erreurs
•aptitude d'un produit logiciel à fonctionner
dans des conditions anormales.

Critères
Se réfère à une méthode de conception d'un
système de telle façon qu'il puisse continuer à
fonctionner, potentiellement de manière réduite,
Maturité
au lieu de tomber complètement en panne dès
que l'un de ses composants ne fonctionne plus
•La fréquence des défaillances dues à
correctement.
des défauts intrinsèques du logiciel
•Nombre
Tolérance de défaut
aux fautes en exploitation sur
Capacité d’un
une logiciel dans un temps fixé à
période
rétablir son niveau de service et à restaurer
les données en cas de défaillance
Capacité de récupération
Mesures
• Le comptage des défauts dans le code : nombre de

défauts mis en évidence en relecture, en test unitaire,
etc.
• Temps moyen de réparation
• Temps moyen entre deux pannes
• Taux de disponibilité : une mesure de qualité de logiciel
permettant d’évaluer la tolérance aux fautes
• La densité du nombre de défauts détectés : une mesure
de qualité externe du produit logiciel permettant
d’évaluer la sous caractéristique « Maturité »
• La Densité et couverture des tests : une mesure de
qualité de logiciel permettant d’évaluer la sous
caractéristique tolérance aux fautes
Utilisabilité (Usability)
Aptitude du programme à piloter l’installation

conformément
au besoin exprimé, en satisfaisant l’utilisateur,
dans un environnement donné.
La qualité de l’expression du besoin,
 L’analyse fonctionnelle
 La rigueur des essais et vérifications effectuées

dans le cadre des réceptions.

Utilisabilité (Usability)
Critères
Facilité de
Effort que doit faire l’utilisateur
compréhension
pour exploiter et contrôler
(Understandability)
l’exploitation
quede son application
FacilitéEffort doit
d’apprentissage faire l’utilisateur
pour reconnaître la logique et sa
(Learnability)
mise en oeuvre
Effort
Facilité que doit faire l’utilisateur
d’opération
pour apprendre son application
(Operability)
Interface conviviales
Attractivité (Attractiveness)

Rendement (Efficiency)
Définition et Critères
Ensemble d'attributs portant sur le rapport existant entre le

niveau de service d’un logiciel et la quantité de ressources
utilisées, dans des conditions déterminées
Temps de réponses et de traitement ;
débits lors de l’exécution de sa fonction.
Comportement vis-à-vis du temps
Comportement vis-à-vis des ressources
Quantité de ressources utilisées ; durée de leur

utilisation lorsqu'il exécute
20/10/2020
sa fonction.
Dr. Aymen LOUATI 111
Maintenabilité (Maintenability)
•L’effort nécessaire pour modifier le logiciel

(corrections, améliorations, adaptation).
•Minimiser l’effort pour localiser, corriger les fautes et

évoluer le logiciel.
•Cette caractéristique intéressera plus particulièrement

le client lorsqu'il s'agira d'une mise à jour ou d'une
nouvelle version d'un logiciel.

Critères
Analysabilité(Analyzability )
Changeabilité(Changeability)
Diagnostiquer les déficiences, les causes de
pannes, identifier les parties à modifier.
Stabilité(stability)
Aptitude à être changer en partie avec le
moindre effort
Testabilité(testability
Pas )
d'effets imprévus après modification
préparation et exécution des tests

unitaires et d’intégration.

Mesures
 Délai moyen de clôture des problèmes =

 Temps total de résolution des problèmes /
nb de problèmes identifiés
 Risque d’effets imprévus après modification ,
nombre d'erreurs en stress test= nombre de
bugs présents/corrigés sur le tracker
 Pérennité des fonctions.

Portabilité (portability)
C’est la facilité de transférer le logiciel d’un

environnement à un autre.
Ce facteur est important pour les utilisateurs qui

auront besoin de créer et de partager des
dictionnaires personnels ou des lexiques
spécialisés dans des environnements différents.

Critères
Installabilité ( installability)
La capacité
La d’exister
capacité avec d’autres
d’être logiciels,
installer dans un qui lui sont
indépendants, Compatibilité
partageant le même (environnement
replaceability) et les
environnement donné.
Lamême ressources.
capacité d’être
conforme aux Adaptabilité ( adaptability)
La capacité de substituer facilement un autre
normes et standars
logiciel similaire tout en assurant les mêmes
de portabilité. Co-existance
fonctionnalités et opérant (dans
co-existence)
le même
La capacité de fonctionner
environnement dans
de que différents
l’ancien logiciel.
environnements Conformance
sans avoir recours à des procédures
( compliance)
supplémentaires pour le modifier et le faire adapter.
Mesures
 Ratio de changement
Plus le ratio est petit plus le logiciel

est portable

Conclusion (1/2)
 La qualité du logiciel est fondamentale :

 Profitabilité du logiciel à court et long termes
 Facilité du développement et maintenance
 Satisfaction du client
 Pour l’atteindre, on adopte des facteurs et des mesures.
 Ces facteurs n’ont pas le même poids d’un métier à un autre.
 Certains facteurs peuvent être antagonistes entre eux : Il faut donc
trouver un point d’équilibre acceptable.
 Parfois, il est difficile d’évaluer certains facteurs par des mesures
explicites.
 Ces facteurs ne sont perçus de la même façon selon les acteurs du
projet. Ce sont des principes totalement objectives.

Conclusion (2/2)
 Grand nombre de modèles de qualité proposé dans la

littérature
o Pas de modèle universel
o Certains types de modèle viennent palier aux problèmes
spécifiques des autres types.
o Résoudre les problèmes généraux comme la rareté de données,
la prise en compte de l’aspect des données (incertitude,
manque, distribution…), l’adéquation du modèles à un contexte
particulier, sont sujets de recherches.

Références
 https://www.omg.org/uml/ (UML Source officielle)
 http://www.uml-diagrams.org (Documentation des diagrammes)
 http://lil.univ-littoral.fr/
 GABAY, J. – GABAY, D. UML 2 Analyse et conception – Dunod – 2008
 ROQUES P. – UML 2 par la pratique - Etude de cas et exercices corrigés
– Editions Eyrolles – 2011
 C. Force, «Méthodes et outils de développement du logiciel», ISIMA 3.
 ISO 9126. Information technology. Software product evaluation. Quality
characteristics and guidelines for their use. 1991 (révisée en 1994).
 Qualité logicielle , V. Baudin , consulté le 13 Avril 2009.

Cours AGL 2020

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Cours AGL 2020

Transféré par

Droits d'auteur :

Formats disponibles

2020/2021

Cours Ateliers Génie

Dr. Aymen LOUATI

Des méthodes et des techniques permettant d’assurer le développement et

1. Définir ce qu’est le génie logiciel, son application (AGL +

Chapitre1: Introduction au Génie Logiciel (AGL)

20/10/2020 Dr. Aymen LOUATI 3

Chapitre1: Introduction au Génie Logiciel (AGL)

20/10/2020 Dr. Aymen LOUATI 4

1) L’ensemble des instructions qui après leurs exécutions nous

2) Les structures de données qui permettent aux programmes

3) Des documents qui décrivent les opérations et l’utilisation

20/10/2020 Dr. Aymen LOUATI 5

 Difficulté à automatiser le processus de développement

20/10/2020 Dr. Aymen LOUATI 6

En dépit des énormes succès, la réputation de l’industrie du logiciel

20/10/2020 Dr. Aymen LOUATI 7

Raisons pour lesquelles le logiciel vieillit

20/10/2020 Dr. Aymen LOUATI 8

20/10/2020 Dr. Aymen LOUATI 9

• Beaucoup de logiciels sont mal conçus et se détériorent

• La demande du logiciel est toujours croissante

L’ingénierie du logiciel est une nécessité

20/10/2020 Dr. Aymen LOUATI 10

20/10/2020 Dr. Aymen LOUATI 11

20/10/2020 Dr. Aymen LOUATI 13

Adaptation et Exploitation des outils CASE

• Années 50 et 60 : programmation empirique

• Fin des années 60 : la "crise du logiciel"

20/10/2020 Dr. Aymen LOUATI 15

Étude du gouvernement américain en 1979

– Payés mais jamais livrés $3.2M 45%

20/10/2020 Dr. Aymen LOUATI 16

 La sonde vers Vénus s'est perdue dans l'espace.

 Au passage de l'équateur un F16 ...

 La lutte contre le bogue de l'an 2000 a coûté à la France 500 milliards

20/10/2020 Dr. Aymen LOUATI 17

Crise de l'industrie du logiciel à la fin des années 60 :

Importance d'approches méthodologiques

Apparition et développement du Génie Logiciel

20/10/2020 Dr. Aymen LOUATI 18

 Les coûts restent dans les limites prévues

 Les délais restent dans les limites prévues

20/10/2020 Dr. Aymen LOUATI 19

 Séparation des problèmes

20/10/2020 Dr. Aymen LOUATI 20

Chapitre1: Introduction au Génie Logiciel (AGL)

20/10/2020 Dr. Aymen LOUATI 21

20/10/2020 Dr. Aymen LOUATI 22

1.1 Le promoteur (1)

 Qui est le promoteur ?

20/10/2020 Dr. Aymen LOUATI 23

1.1 Le promoteur (2)

 Responsabilités avant le projet

20/10/2020 Dr. Aymen LOUATI 24

1.1 Le promoteur (3)

 Responsabilités pendant le/la:

20/10/2020 Dr. Aymen LOUATI 25

1.1 Le promoteur (4)

 Risques et profits du promoteur

20/10/2020 Dr. Aymen LOUATI 26

1.2 Le mandataire (1)

20/10/2020 Dr. Aymen LOUATI 27

1.2 Le mandataire (2)