Planification et

Gestion de projets
Plan du cours
 Définition et terminologie
 Le découpage d ’un projet
 L ’estimation des charges
 Les techniques de planification
 L ’organisation du travail
 Le pilotage du projet
 La maîtrise de la qualité
 Quelques exemples d’interfaces
Définition et terminologie
 Logiciel : Ensemble des programmes, procédés
et règles et éventuellement de la
documentation, relatifs au fonctionnement d'un
ensemble de traitement de l'information
 Produit : Programmes sources et machines,
des procédures et des ensembles de données
enregistrées.
 Client et Fournisseur : Le client commande
un logiciel, le fournisseur le réalise.

3
Définition et terminologie
 Maîtrise d’ouvrage
◦ C’est une personne ou une entreprise qui a un besoin et qui
consulte des entreprises pour trouver une solution.
 Maîtrise d’œuvre
◦ C’est une personne ou plus généralement une société qui va
être chargée de réaliser les travaux que le cahier des charges
a fixés.
◦ Elle va assurer des prestations techniques, qui aboutiront à la
mise en œuvre de la solution acceptée par la maîtrise
d'ouvrage.
 Sous-traitance
◦ appel à une ou plusieurs entreprises externes pour la
réalisation de certaines tâches du projet,
◦ Chaque sous-traitant réalise un sous-ensemble du projet
directement avec le maître d'œuvre mais n'a aucune
responsabilité directe avec la maîtrise d'ouvrage, même si
celle-ci a un " droit de regard " sur sa façon de travailler.

4
Définition et terminologie

ENS C1A3 GL Hayatou Oumarou 5

 Le projet
 Définition
◦ Un projet est un ensemble de tâches indissociables
permettant de répondre à un besoin exprimé

◦ Il comprend également les ressources nécessaires à sa

réalisation

◦ Il a une durée finie, caractérisée par une date de

début et une date de fin

◦ Il peut être multitechnique, monotechnique, collectif ou

individuel
Définition et terminologie
 Un projet (informatique)
◦ un objectif
Objectif
◦ des moyens
◦ des contraintes

Espace défini
par le projet
moyens contraintes

7
Définition et terminologie
 Etudier un projet c ’est
◦ recenser et/ou définir les moyens
◦ recenser les contraintes
◦ définir un plan de développement du
processus
 Gérer un projet c ’est
◦ contrôler moyens, contraintes et plan de
développement . PLANIFICATION,
ORGANISATION, SUIVI.

8
Définition et terminologie
 Piloter/conduire un projet c ’est
◦ comprendre les exigences stratégiques
◦ gérer le projet
◦ animer (une équipe)
◦ concevoir (un produit)
◦ communiquer et transférer son savoir
◦ vérifier la qualité

ENS C1A3 GL Hayatou Oumarou 9

Définition et terminologie
 Quelques propriétés problématiques des
projets
◦ il y a interaction entre l ’objectif et les
contraintes et moyens (sommets non
indépendants)
◦ l ’objectif du projet n ’est totalement défini
qu’à l ’achèvement du projet
◦ le développement se déroule au sein d ’un
environnement agissant.

ENS C1A3 GL Hayatou Oumarou 10

 Les acteurs : le chef de projet
 Un animateur
◦ Il fédère l'équipe projet
 Un Communicateur
◦ Il est en mesure à tous les stades d'informer le comité de
pilotage
◦ Il informe également ses partenaires
 Un responsable
◦ Il dispose de moyens et d'obligations
◦ Il doit tenir ses objectifs
Il ne porte pas tout sur
ses épaules...
Les acteurs : le chef de projet
 Les missions du Chef de projet
◦ Définition du projet
◦ Planification du projet
◦ Pilotage du projet
◦ Négociations internes et externes au projet
◦ Animation des équipes
◦ Reporting interne et externe
◦ Gestion du fond documentaire
 Les qualités d'un chef de projet
Qualités d'un chef de projet

Comprendre Obtenir l'adhésion Savoir produire Vaincre les obstacles

Imagination Communication Efficacité Confiance

Raisonnement Relationnel Délégation Créativité
Savoir-faire Motivation Direction Méthodologie
Expertise Influence Mobilisation Initiative
Curiosité Solidarité Autonomie Capacité à défendre
Sensibilité Responsabilité une idée
Ecoute Synthèse Capacité d'interpellation
Ouverture d'esprit
Les acteurs : la structure de pilotage
 Un élément indispensable au déroulement du
processus
◦ Prises de décisions
◦ Arbitrage
 Un élément indispensable à la pérennisation de la
démarche
◦ Sollicitation de la Direction
◦ Facilitation auprès des autres services (transversalités)
◦ Soutien au chef de projet
 Un garant
◦ De la cohérence du projet avec la stratégie et les
objectifs de l'entité
Sélectionner le personnel

 En cohérence avec la politique de gestion

du personnel (projet de carrière,
formation continue, sous-traitement, . . . ),
 le chef de projet doit affecter des activités
et des rôles aux différentes personnes
impliquées dans le projet.
 ⇒ Des qualités relationnelles sont donc
utiles. . .

15
 Les acteurs : l'équipe projet
 La créativité permanente
◦ L'innovation et l'optimisation doivent rester un souci
permanent

 Des partenaires
◦ En considérant le projet dans sa globalité et non
exclusivement au niveau de la tâche

 La transparence
◦ Par la communication
◦ Plus tôt une dérive est connue, mieux elle se gère
Difficultés liées aux personnes
 ne savent pas toujours ce qu'elles veulent,
ou ne savent pas bien l'exprimer
 communication difficile entre personnes
de métiers différents (jargons)
 l'informaticien est souvent perçu comme
introverti, peu solidaire du groupe
 beaucoup d ’autodidactes qui croient
savoir...

17
Des vertus d’une communication précise...

18
Des vertus d’une communication précise...

19
Des vertus de l’organisation...

20
Cahier des Charges

21
Cahier des Charges
 Le Cahier des Charges Fonctionnel (CdCF) d'un
projet est un document par lequel la maîtrise
d'ouvrage exprime son besoin pour le projet.

 Définition AFNOR :
◦ Document par lequel le demandeur exprime son
besoin (ou celui qu'il est chargé de traduire) en terme
de fonctions de services et de contraintes.

 Le CdCF constitue une référence contractuelle

entre les parties.

22
Cahier des Charges
 Objet du CdC
◦ Définir les fonctionnalités du système à
concevoir.
◦ Les domaines d'application.
◦ Les personnes impliquées dans le projet.
◦ Les exigences du client dans la forme et le
fond.
◦ Base contractuelle entre le client et le
fournisseur

23
D’autres standard CdC
NASA-STANDARD SMAP-DID-P200-SW
I- Introduction
II- Documentation relative au sujet
III-Ebauche préliminaires et discussion des choix
IV- Exigences aux interfaces externes
V- Spécification des besoins
processus de données
comportement en exécution et qualité requise
sécurité
sécurité et protection des données
limitation d’implémentation
exigences d’installation
buts conceptuels
VI- Répartition pour une liaison étape par étape
VII-Abréviations acronymes et grossière
VIII-Notes
IX-Annexes

24
D’autres standard CdC
STANDARD ANSI-IEEE STD-830-1984 (abrégé)
Chap 1 : Introduction
a. but de la description des besoins
b. grandeur estimée du produit
c. définition acronyque et abréviations
d. références
e. aperçu sur le reste de la description des besoins
Chap 2 : Description Générale
a. perspective du produit
b. fonction du produit
c. caractéristique des utilisateurs
d. limitation et limites générales
e. pré requis et dépendance
Chap 3 : Besoins Spécifiques
Chap 4 : Annexes
Chap 5 : Indexes

25
Planifier un projet
 Le chef de projet doit établir un jalonnement
◦ une répartition des activités dans le temps en
fonction de leurs dépendances et des ressources
disponibles et
◦ d’une évaluation des risques liés à leur
réalisation.
 ⇒ Il s’agit d’un travail d’ordonnancement qui
nécessite encore une connaissance très
précise du domaine, des équipes de
développement, etc. . . .

ENS C1A3 GL Hayatou Oumarou 26

Organisation d’un projet
 WBS
• Structure de découpage du projet en français – SDP
• Faciliter la planification
• Estimer la durée totale

 PBS
• Structure de découpage du produit
• Identifier les fonctions
• Préciser les livrables
• un schéma qui représente l'enchaînement de tous les produits à
réaliser pour un projet

 OBS
◦ Structure organisationnelle (du projet) en français
◦ Déterminer le rôle des membres

ENS C1A3 GL Hayatou Oumarou 27

 Work Breakdown Structure (WBS)
Objectif : Diviser les taches principales en taches plus
petites
Nécessite de :
• Pouvoir identifier leurs différentes parties
• Trouver des livrables et des jalons qui permettront
de mesurer l'avancement du projet
WBS Work Breakdown Structure : organigramme
technique
• Structure arborescente
• Le premier niveau de décomposition correspond
souvent au modèle de cycle de vie adopté

28
Work Breakdown Structure

29
 Utiliser la planification
PERT : Program Evaluation and Review Technique
◦ Après un découpage WBS avec une liste de couples
(tâche, durée estimée)

Durée minimale
Tâche, durée PERT
Latitude entre
Deux tâches
◦ Contraintes d ’ordonnancement et parallélisme =>
Durée minimale du projet
Exemple de planification
Tâche Durée Precedence
A 1 -
B 2 A
C 3 A
D 1 B
E 1 C
F 3 C
G 2 D,E
H 1 F
I 2 F
J 2 H,G
K 2 I,J

31
 Calculer un PERT
marge libre = délai
de retard à la mise
en route d'une Quel est son intérêt ?
tâche

Au plus
tôt!

Dates au plus tôt →

Dates au plus tard

Le chemin critique est

le chemin où …
date au plus tôt = date au
Au plus
plus tard. … tard !
http://www004.upp.so-net.ne.jp/s_honma/schedule
 Organiser les tâches, déterminer le chemin
critique.. PERT
Quel est son intérêt ? …

.. un retard sur le
chemin critique retarde
la date de fin du projet
.. Accélérer le chemin
critique permet de
terminer le projet plus
vite
Dates au plus tôt →
Dates au plus tard

Le chemin critique est

le chemin où …
date au plus tôt = date au
plus tard. …
http://www004.upp.so-net.ne.jp/s_honma/schedule
Extensions des réseaux PERT
 PERT Charge pour prendre en compte
les ressources affectées au projet
◦ Ressource : moyen nécessaire au déroulement
et a l'aboutissement d'une tâche
◦ Les tâches sont caractérisées par des durées
et des intensités de ressources
 PERT Cost pour gérer les coûts
◦ Permet d'optimiser l'échéancier des
paiements en
 Jouant sur les surcoûts affectant les tâches critiques
 Jouant sur les économies possibles sur les tâches
non critiques

34
Diagrammes de Gantt
 Utilise les dates au plus tôt et des dates au plus tard
 Permet d’établir un planning en fonction des ressources
 Mis au point en 1917 par H. GANTT
 Cette méthode est simple mais elle ne présente pas les
précédences entre les opérations directement

35
Veiller sur un projet

 De façon continue, le chef de projet s’assure

du progrès des tâches et du respect des
délais.
 En cas de retard, il doit réévaluer la
planification et éventuellement renégocier
les ressources et les contraintes du projet.
 ⇒ La visibilité de la progression des activités
est ici essentielle.
 Un chef de projet doit donc savoir se doter
d’indicateurs révélateurs sur l’état du
développement.

36
Le modèle COCOMO

37
Le modèle COCOMO
 COnstructive COst MOdel
◦ Développé a la firme TRW (organisme du DoD,
USA) par B.W. Boehm et son équipe
◦ Fondé sur une base de données de plus de 60
projets différents
 Modèle d'estimation
◦ du cout de développement d'un logiciel en
nombre de mois-hommes (E : effort)
◦ du temps de développement en mois (TDEV) en
fonction du nombre de lignes de codes en
milliers (KLOC)

38
Introduction COCOMO
 Cocomo81 ou COCOMO de Base
◦ Développé par Barry Boehm (1981)
◦ Estimation de la taille du produit et du nombre de mois-hommes
◦ Trois modèles : de Base, Intermédiaire, et Détaillé
◦ Estime l’effort à partir des SLOC (Source Line of Code)
 Ada Cocomo (1987)
◦ Spécialisation du modèle Cocomo
◦ Permet l’estimation des coûts et des horaires pour des
développements incrémentaux des logiciel
 Cocomo II
◦ Adaptation du modèle original
◦ 3 modèles utilisés dépendamment du degré de définition des
composantes : Composition de l’Application, Conception Initiale,
Post-Architecture
◦ Estime l’effort à partir des SLOC ou FP

39
COCOMO81
 Le modèle simple (de base)
◦ Il estimation simple de l'effort (MH) et de la durée en fonction du
nombre de lignes de code et de la taille du développement

 Le modèle intermédiaire
◦ introduit 15 facteurs d’ajustement regroupés selon 4 catégories :
Attributs du produit, du matériel, du personnel, et du projet

 Le modèle détaillé
◦ Permet d’attribuer un multiplicateur d’effort pour les facteurs
d’ajustement à chaque phase du projet
◦ Projet est analysé en terme d'une hiérarchie : module, sous système et
système

40
COCOMO81: le modèle de base
Trois types de projets
 Mode organique
◦ Petites équipes
◦ Applications maitrisées et problèmes bien compris
◦ Pas de besoins non fonctionnels difficiles
◦ ex : système de notes dans une école)
 Mode semi-détaché
◦ Expérience variée des membres de l'équipe de projet
◦ Possibilité l'avoir des contraintes non fonctionnelles importantes
◦ Type l'application non maitrisée par l'organisation
◦ ex : système bancaire interactif
 Mode embarqué
◦ Contraintes serrées
◦ L'équipe de projet a, en général, peu l'expérience de l'application
◦ Problèmes complexes
◦ Ex: système de transfert de fonds électronique

41
COCOMO81: Modèle de base
◦ Identifier le mode de développement - organique, semi-détaché ou
imbriqué
◦ 4 coefficients au modèle :
 a (constante de productivité)
 b (échelle appliquée à la taille du logiciel)
basé sur l’historique
 c (constante du modèle)
 d (échelle appliquée au temps de développement)

◦ Effort : HM = a x (SLOC)^b
◦ Durée: TDEV = c x (HM)^d (durée en nombre
de mois)
◦ Effectif : Effort / Durée
◦ Productivité : SLOC / HM

Valeurs attribuées par Boehm (1981)

Organique : MH = 2.4 x (SLOC)1.05 TDEV = 2.5 x (MH)0.38
Semi-détaché : MH = 3.0 x (SLOC)1.12 TDEV = 2.5 x (MH)0.35
Imbrique : MH = 3.6 x (SLOC)1.20 TDEV = 2.5 x (MH)0.32
42
COCOMO81: Modèle intermédiaire

Estimation modifiant l'estimation

brute fournie par le modèle de base
du COCOMO81 en se servant des
attributs
 Logiciel
 Matériel
 Projet
 Personnel

43 ENS C1A3 GL Hayatou Oumarou

 Modèle Intermédiaire
◦ Déterminer l’effort nominal HM = a x (SLOC)b
Valeurs attribuées par Boehm (1981)
Organique : HM = 3.2 x (SLOC)1.05 TDEV = 2.5 x (MH)0.38
Semi-détaché : HM = 3.0 x (SLOC)1.12 TDEV = 2.5 x (MH)0.35
Imbrique : HM = 2.8 x (SLOC)1.20 TDEV = 2.5 x (MH)0.32

◦ Déterminer le niveau de chacun des 15 facteurs d’ajustement et

attribuer le multiplicateur correspondant
 Si le multiplicateur < 1, contribue à diminuer la taille de l’effort
 Si le multiplicateur > 1, contribue à augmenter la taille de l’effort

◦ Calculer le multiplicateur d’effort (EM) en multipliant les facteurs

◦ Effort : HM = HM base x EM
= a x (SLOC)bx EM

◦ Temps de Développement : TDEV = c(HM)^d

44 ENS C1A3 GL Hayatou Oumarou

Facteurs d’ajustement
 Attributs du Produit
◦ RELY Fiabilité requise du produit
◦ DATA Taille de la base de données
◦ CPLX Complexité du produit
 Attributs Informatiques
◦ TIME temps d’exécution requis
◦ STOR Contraintes sur la mémoire
◦ VIRT Volatilité de la machine virtuelle (composantes matériel et logiciel) –
fréquence des changements majeurs
◦ TURN: délai d’exécution
 Attributs du Personnel
◦ ACAP Capacité des analystes
◦ AEXP Expérience en développement de l’application
◦ LEXP Expérience dans le langage de programmation
◦ PCAP Capacité des programmeurs
◦ VEXP Expérience avec la machine virtuelle (composantes matériel et
logiciel)
 Attributs du Projet
◦ MODP Pratiques de programmation modernes
◦ TOOL Utilisation d’outils logiciel
◦ SCED Contrainte sur le temps de développement

ENS C1A3 GL Hayatou Oumarou 45

Facteurs d’ajustement

ENS C1A3 GL Hayatou Oumarou 46

Modèle Détaillé

 Introduit des multiplicateurs d’effort qui reflètent la

distribution de l’effort à travers les phases de développement

 Décomposition hiérarchique du produit

◦ Système
◦ Sous-système
◦ Module

 Utilisé surtout pour les grands projets

ENS C1A3 GL Hayatou Oumarou 47

COCOMOII
 Modèles De Base, Intermédiaire, et Détaillé remplacés par les
modèles de Composition d’Application, de Conception Initiale,
et Post-Architecture qui permettent une estimation plus précise
lors de l’avancement du développement

 Remplacement des trois catégories de taille du projet

(Organique, Semi-Détaché, Imbriqué) par une mesure composée
de cinq facteurs

 Changement dans les facteurs d’ajustement et la valeur des

multiplicateurs d’effort

 Permet le calcul de l’effort lorsqu’il y a réutilisation ou

réingénierie

ENS C1A3 GL Hayatou Oumarou 48

COCOMOII
◦ Modèle de Composition d’Applications
 Utilisé lors des premières phases de développement qui impliquent
le prototypage
 Basé sur les Object Points (écrans, rapports, et langages de
troisième génération) à l’aide de prototypes
 Multiplié par un facteur de complexité (simple, moyen, difficile)
◦ Modèle Conception Initiale
 Spécifications du produit peu connues
 Utilise les LOC ou Points de Fonction
 Sept facteurs d’ajustement
 Estimation Approximative
◦ Modèle Post-Architecture
 Architecture du produit définie
 Utilise les LOC ou Points de Fonction
 Dix-sept facteurs d’ajustement
 Cinq facteurs exponentiels de mesure de l’ampleur du projet

ENS C1A3 GL Hayatou Oumarou 49

 COCOMOII
Nouveaux Facteurs d’Ajustement
 Attributs du Produits
◦ RELY Réutilisation requise
◦ DOCU Documentation relative aux besoins du cycle de vie

 Attributs Informatiques/ Plate-forme

◦ PVOL Volatilité de la Plate-forme

 Attributs du Personnel
◦ PEXP Expérience avec la Plate-forme
◦ LTEX Expérience avec le langage de développement et les outils
◦ PCON Continuité du Personnel

 Attributs du Projet
◦ SITE Développement Multi-site

ENS C1A3 GL Hayatou Oumarou 50

Facteurs exponentiels de mesure
de l’ampleur du projet
 Cinq Facteurs
◦ Flexibilité de développement
◦ Cohésion de l’équipe
◦ Précédence
◦ Architecture et résolution des risques
◦ Maturité du processus

 Calcul de l’ampleur du projet

◦ Une valeur entre 0 et 5 est attribuée à chaque facteur, 0 pour un
niveau faible et 5 pour un niveau élevé
◦ Somme des valeurs des cinq facteurs exponentiels

ENS C1A3 GL Hayatou Oumarou 51

COCOMOII
◦ Coefficients au modèle :
 a (constante, dépend de la taille du logiciel)
 b (échelle appliquée à la taille du logiciel, indique les économies ou dés
économies d’échelle)
 c (constante du modèle)
 d (échelle appliquée au temps de développement)
 w (ampleur du projet)

◦ b = 1.01 + 0.01 w

◦ Effort : HM nominal = a (taille)^b

HM ajusté = HM nominal x EM

◦ Durée:

52 ENS C1A3 GL Hayatou Oumarou

Autres métriques
Métrique de Mc Cabe
◦ Métrique la plus utilisée après les lignes de
code
◦ Met en évidence la complexité structurelle du
code
 On produit un graphe de contrôle qui représente
un code
 Le nombre de faces du graphe donne la complexité
structurelle du code

ENS C1A3 GL Hayatou Oumarou 53

Autres métriques
Métrique de Halstead
 Métriques pour la complexité d'un
programme
◦ Fondées empiriquement
◦ Toujours considérées comme valides,
contrairement a ses formules complexes de
prédiction
 Entités de base
◦ Opérandes : jetons qui contiennent une valeur
◦ Opérateurs : tout le reste (virgules, parenthèses,
opérateurs arithmétiques...)

ENS C1A3 GL Hayatou Oumarou 54

Autres métriques
Métrique d'Henry-Kafura
 Mesurer la complexité des modules d'un
programme en fonction des liens qu'ils
entretiennent
 On utilise pour chaque module i :
◦ Le nombre de flux d'information entrant noté ini
◦ Le nombre de flux d'information sortant noté outi
◦ Le poids du module noté poidsi calculé en fonction de
son nombre de LOC et de sa complexité

 La mesure totale HK correspond a la somme des

HKi

ENS C1A3 GL Hayatou Oumarou 55

Autres métriques
Métriques MOOD
 Ensemble de métriques pour mesurer les attributs des
propriétés suivantes :
◦ Encapsulation
◦ Héritage
◦ Couplage
◦ Polymorphisme
Métriques Objet de Chidamber
 Ensemble de métriques (Metric Suite for Object Oriented
Design)
◦ Evaluation des classes d'un système
◦ La plupart des métriques sont calculées classe par classe
◦ Le passage au global n'est pas clair, une moyenne n'étant pas tres
satisfaisante

ENS C1A3 GL Hayatou Oumarou 56

Qualité logicielle

ENS C1A3 GL Hayatou Oumarou 57

Les spécificités de la qualité pour les
logiciels
QUALITE D'UN LOGICIEL :
Toujours "satisfaire les besoins (explicites + implicites) du
client"
Mais besoins rarement bien formalisés, parfois
insaisissables
…et caractéristiques qualitatives d'un logiciel non
mesurables.

 Garde-fous : un certain nombre de critères, parfois

contradictoires
+ des contraintes de coûts et de délais….

Hayatou Oumarou
58
Les facteurs de qualité logiciel 1/4
La conformité Respect des besoins formulés en temps de réponse, en volumes de
(Correctness) données à traiter, en transmissions, en accès, en affichages, en
impressions,..

La fiabilité Capacité d'un logiciel à fonctionner avec le minimum d'interruptions

(Reliability) et d'erreurs.
Utilisateur très sensible à ce point.
Indicateur : MTBF.
Facteur est prépondérant pour certains logiciels temps réel (conduite d'avion,
systèmes militaires, financiers, conduite de certains processus)
Un logiciel de gestion, lui, ne présente pas de danger immédiat pour la vie
humaine, en cas de panne. Mais une panne coûte parfois cher.

L'efficacité Optimisation des ressources disponibles du point de vue unités de

(Efficiency) calcul, mémoire vive et mémoire morte, disques durs, liaisons,..
Facteur important si peu de place disponible (satellites, avions)

Critères de Walter / Mc Call

Hayatou Oumarou 59
 Les facteurs de qualité logiciel 2/4

L'intégrité Résistance aux tentatives d'accès par des personnes non autorisées.
(Integrity) Facteur précisé avec les niveaux de protection nécessaires, les autorisations d'accès, les
codes de protection, les différents systèmes de cryptage,..
(applications financières ou militaires)

L'utilisabilité Effort nécessaire pour l'apprentissage, l'utilisation, et l'arrêt du programme.

(Usability) Facteur dépendant de la conception des interfaces-utilisateurs et documentation.
(attention : bon techniquement mais trop difficile à utiliser !!!!)

Hayatou Oumarou
60
 Les facteurs de qualité logiciel 3/4
La maintenabilité Effort nécessaire pour localiser et corriger une erreur dans un
(Maintainability) programme opérationnel.
Cette définition vaut également pour les corrections d'erreurs.

La testabilité Effort nécessaire pour réaliser les tests permettant de s'assurer que le
(testability) système (ou une partie du système) répond aux spécifications.
Valable pour les tests de réception. Facteur très utile pour la maintenance, pas
directement pour l'utilisateur.

La flexibilité Effort nécessaire pour modifier le logiciel.

(Flexibility) Valable pour les évolutions, améliorations, ajouts de nouvelles fonctions…
Facteur très proche de la maintenabilité.

Hayatou Oumarou 61
Les facteurs de qualité logiciel 4/4
La portabilité Effort nécessaire pour pouvoir exécuter des programmes sur différentes
(Portability) configurations matérielles et logicielles.

La réutilisabilité Aptitude de certains éléments du logiciel à pouvoir être réutilisés.

(reusability)

L'interopérabilité Effort nécessaire pour faire fonctionner du logiciel conjointement avec un

(interoperability). ou plusieurs autres logiciels.

Un autre facteur d'importance croissante : l'ergonomie.

Hayatou Oumarou 62
Quel progrès?

© Hayatou O umarou INL53 63

Maintenant, Ceci est-il un progrès!

© Hayatou O umarou INL53 64

I veux toutes les options!

© Hayatou O umarou INL53 65

Oui, je veux Imprimer ce truc aussi

© Hayatou O umarou INL53 66

Dans Excel, “couper” ne signifie pas
couper

© Hayatou O umarou INL53 67

S’amusez avec les ascenseurs!

© Hayatou O umarou INL53 68

Encore plus d’onglets SVP!

© Hayatou O umarou INL53 69

Sans onglets

© Hayatou O umarou INL53 70

Info bulle utile!

© Hayatou O umarou INL53.71

Arretez, SVP!

© Hayatou O umarou INL53 72

Je ne peux pas me décider !

© Hayatou O umarou INL53 73

© Hayatou O umarou INL53 74
Vert bien — rouge mauvais

© Hayatou O umarou INL53 75

Was that an error?

© Hayatou O umarou 76
Uh … ok

© Hayatou O umarou 77
Oui — je veux dire, non

© Hayatou O umarou 78
MERCI
ENS C1A3 GL Hayatou Oumarou 79