Glossaire - Université de Sherbrooke

Glossaire Version préliminaire, pour révision et commentaires. - 1.3.1b (2016-01-14) 1 / 31

Glossaire Émetteur

Luc Lavoie Dates

dernière modification : 2016-01-14 dernière impression : 2016-01-14

Version et statut 1.3.1b – Version préliminaire, pour révision et commentaires.

Glossaire .......................................................................................................................................... 1Données de publication ........................................................................................................................................ 1Historique des révisions ....................................................................................................................................... 1

1 Introduction .............................................................................................................................. 21.1 Objet et portée du document ....................................................................................................................... 2

2 Références .................................................................................................................................. 22.1 Références sur la langue française .............................................................................................................. 22.2 Autres références ........................................................................................................................................... 3

3 Définitions des termes, sigles et acronymes ....................................................................... 33.1 Section générale ............................................................................................................................................. 33.2 Section propre à la vérification-validation .............................................................................................. 233.3 Section propre au Cocomo ......................................................................................................................... 24

4 Décomposition hiérarchique d’un système ...................................................................... 305 Cheminement d’un objectif ................................................................................................. 31

Données de publication Historique des révisions version date rédacteurs description 1.3.1 2015-01-19 LL Début d’harmonisation 1.3.0 2011-04-01 LL Amélioration de la bibliographie 1.2.0 2011-02-19 LL Ajout de la section 4, plusieurs corrections de mise en forme 1.1.1 2010-12-18 LL Normalisation des termes essai, test, épreuve 1.1.0 2010-06-16 LL Ajout des acronymes du Cocomo 1.0.0 2008-02-22 SD Première version.


1 Introduction 1.1 Objet et portée du document Ce document dresse l’inventaire des termes, sigles et acronymes relatifs à l’ingénierie des exigences et la gestion de projets. Veuillez prendre note que le glossaire est en cours de développement et que cette version est un document de travail.

2 Références 2.1 Références sur la langue française Cette section présente la liste des références sur la langue française utilisées pour développer le glossaire. [deVILLERS2003]

Marie-Éva DE VILLERS. Multi dictionnaire de la langue française. 4e édition, Québec Amérique, coll. Langue et culture, 2003. ISBN : 2-7644-0203-1.

[FaB2005] Noëlle GUILLOTON et Hélène CAJOLET-LAGANIÈRE. Le français au bureau. 6e édition, revue et augmentée par Noëlle Guilloton et Martine Germain. Office québécois de la langue française, Les Publications du Québec, 2005. ISBN 2-551-19684-1.

[FaB2005EX] Élaine LAJOIE et Esther POISSON. Le français au bureau en exercices. Office québécois de la langue française, Les Publications du Québec, 2005. ISBN 2-551-19690-6.

[GDT] OFFICE QUÉBÉCOIS DE LA LANGUE FRANÇAISE (OQLF) ; Grand dictionnaire terminologique. http://www.granddictionnaire.com/

[RTAS1997] Hélène CAJOLET-LAGANIÈRE et coll. Rédaction technique, administrative et scientifique. 3e édition, revue et augmentée, Sherbrooke, Éditions Laganière, 1997, 468 p. ISBN 2-98000-272-7.


2.2 Autres références [Lalande]

André LALANDE. Vocabulaire technique et critique de la philosophie. Presses universitaires de France, 1926. ISBN : 2-13-055383-4. http://readerv3.numilog.com/numilogreaderv3.aspx?id=9782130553830&cr=corneille (2008-04-10)

Les descriptions des autres références utilisées pour développer le glossaire sont recensées dans le document suivant : Bibliographie de GLOGUS (http://pages.usherbrooke.ca/llavoie/projets/GLOGUS/). en particulier :

[IEEE 1044-1993] [IEEE 1058-1998] [IEEE 1074-1997] [IEEE 1233-1998] [PMBoK_F]

3 Définitions des termes, sigles et acronymes 3.1 Section générale ACM

Association for Computing Machinery. Association pour la promotion de l'informatique, éditeur de nombreux journaux scientifiques.

activité activity. Collection de tâches interreliées à laquelle sont associés des intrants, des extrants, un préalable (condition de démarrage) et une condition d’arrêt.

AEF Automate d’états finis.

agrégation Une association qui représente des relations de tout à partie. Quand on a une agrégation, on ne met pas le nom de l’association, car il est indiqué par le symbole d’agrégation. Une agrégation indiquant qu’un seul composé est constitué des éléments de l’agrégat est représentée par un losange plein (c’est-à-dire qu’un élément appartient à au plus un composé et non qu’il appartient à un et un seul composé – ce qui est cependant nécessairement le cas des agrégats physiques). Un losange vide indique qu’il y a plusieurs composés qui ont les mêmes éléments (impossible dans des agrégats physiques).


anomalie [IEEE 1044-1993] : « Any condition that deviates from expectations based on requirements specifications, design documents, user documents, standards, etc. or from someone’s perceptions or experiences. Anomalies may be found during, but not limited to, the review, test, analysis, compilation, or use of software products or applicable documentation. »

antécédent Condition préalable à l’exécution d’une routine.

aptitude à l'emploi [GDT] : Aptitude d'un produit, d'un procédé ou d'un service à remplir, dans des conditions spécifiées, un emploi (ou une fonction) défini.

architecture voir conception.

artefact work product. [IEEE 1058-1998] : Résultat d'une activité ; peut être un document, un logiciel, un matériel, un service, un processus ou une combinaison de ceux-ci ; il peut entrer dans la constitution d'un produit ou constituer un produit fini en lui-même.

association Relation entre concepts. Dans UML est représentée comme une ligne entre les concepts. À la fin d’une association, on peut avoir un indicateur de multiplicité. La convention de lecture par défaut est de gauche à droite et du haut vers le bas. Une flèche peut indiquer le sens de lecture.

association avec qualification Une association peut avoir un qualificateur qui permet d’identifier un ensemble d’objet en fonction du qualificateur. Souvent (ou toujours, voir Rumbaugh91 : 3.3.5, pp 35-36, en fait le qualificateur est un déterminant unique de l’autre objet, attendu le premier objet) pour réduire la multiplicité à 1.

BNF Formes de Backus-Naur ; comprend un DD, si nécessaire.

but Fin poursuivie par l'organisation ou par une de ses fonctions et découlant des objectifs fixés [inspiré de GDT].


calendrier schedule. [GDT] : Suite chronologique d'un programme d'activités ou des phases d'exécution d'un travail pour une période donnée. Quasi-synonyme : échéancier. Terme à éviter : cédule. Note(s) : En ce sens, le terme calendrier est généralement suivi d'un complément ou d'un adjectif, par exemple : calendrier de travail, calendrier de production, calendrier universitaire, etc. Par extension de sens, calendrier désigne également le tableau ou le document qui présente cet emploi du temps déterminé à l'avance. Au Québec, on l'appelle parfois échéancier. Toutefois, dans le domaine de la gestion, il est préférable de réserver le terme échéancier pour désigner le document où figurent, par ordre chronologique des échéances, les règlements à effectuer ou à recevoir. En France, le terme cédule est réservé au domaine de la fiscalité et il désigne une catégorie d'impôt ; de plus, ce sens est vieilli. Le terme cédule est à éviter dans tous les autres sens, dont « horaire », « programme », « calendrier » et « plan de travail », puisqu'il s'agit d'un calque sémantique de l'anglais schedule, qui ne vient combler aucune lacune lexicale en français.

capacité Service (fonction) dont le système est redevable.

catégorie [IEEE 1044-1993] : « An attribute of an anomaly to which a group of classifications belongs. »

catégorie facultative optional category. [IEEE 1044-1993] : « A category that provides additional details that are not essential but may be useful in particular situations. »

catégorie obligatoire mandatory category. [IEEE 1044-1993] : « A category that is essential to establish a common definition and to provide common terminology and concepts for communication among projects, business environments, and personnel. »

cause à venir

chaîne critique Une chaîne est un ensemble d’activités liées, utilisant une même ressource, comprises entre deux jalons. Une chaîne est critique si elle détermine la durée écoulée entre les deux jalons. L’analyse des chaînes critiques permet d’éviter les dépassements de capacité d’une ressource et de concentrer les efforts d’optimisation sur les ressources qui ont un impact effectif sur la durée du projet.

charte de projet project charter.

chemin critique Ensemble minimal d’activités liées déterminant la durée écoulée entre deux jalons. L’analyse des chemins critiques permet de concentrer les efforts d’optimisation sur les activités qui ont un impact effectif sur la durée du projet.


chien de garde watch-dog.

classe Description d’un ensemble d’objets qui partagent attributs, opérations et sémantique. Représentée par un rectangle.

classification [IEEE 1044-1993] : « A choice within a category. »

CLE Composant logiciel exécutable.

compatibilité avec d’autres systèmes La compatibilité est souvent une contrainte très forte qui peut obliger le concepteur à d’énormes tours de force, surtout si les autres systèmes évoluent, car dans ce cas il faut les suivre !

complexité complexité des données : des données complexes impliquent, bien sûr, des difficultés de conception (et normalement des systèmes plus difficilement lisibles). complexité des algorithmes : même chose que pour la complexité des données. Parfois, des données complexes peuvent impliquer des algorithmes simples et vice-versa. complexité des spécifications : des spécifications complexes ont sûrement un impact sur la conception : il faut les comprendre ! Des spécifications complexes (si leur complexité ne provient pas du fait qu’elles ont été mal conçues) impliquent un problème complexe et donc souvent (pas toujours) une solution complexe.

comportement à venir (comportement ne répondant pas aux : attentes, spécifications, exigences, contraintes, critères)

conception Dans le cadre de ce document, nous distinguerons trois types de conception : design, architecture et conception détaillée. Seul le design fait partie de l’ingénierie des exigences. design : la conception des interactions entre un système et les agents externes humains (acteurs) par le biais d’une interface personne-machine. La conception des interconnexions (protocoles) avec les agents externes non humains relève de l’architecture. architecture (conception globale) : la conception du découpage, de l’interconnexion et de l’agencement des composants au sein d’un système ou d’un sous-système. conception détaillée : la conception des composants. [GDT] (conception) : Activité créatrice qui consiste à élaborer un projet, ou une partie des éléments le constituant, en partant des besoins exprimés, des moyens existants et des possibilités technologiques dans le but de créer un bien ou un service. [GDT] (design) : En français, le mot design est réservé aux activités qui visent une harmonisation esthétique de l'environnement humain à partir des formes données aux productions industrielles. Il ne faut pas l'étendre à toutes les activités créatrices.


conséquence à venir

conséquent Condition assurée par l’exécution d’une routine dans la mesure où son antécédent était respecté.

contexte à venir

contrainte Condition sur la façon dont une capacité (fonction) doit être assurée. La différence essentielle entre une contrainte et une exigence est que la satisfaction de la dernière est nécessaire à l’atteinte d’au moins un objectif du projet. Autre distinction (équivalente ?), l’ensemble des contraintes permet de classer les (multiples) solutions respectant les exigences, éventuellement des les ordonner. L’ensemble des contraintes réduit l’espace des solutions admissibles. [GDT] (gestion de projet) : Terme général désignant tout élément susceptible de conditionner la réalisation des tâches, et leur position dans le temps : contraintes logiques, contraintes de charges, contraintes de dates, contraintes de ressources. [GDT] (stratégie de gestion) : En matière d'analyse d'un problème, désigne une règle de conduite que l'on est obligé de respecter, et caractérise en outre une situation déterminée, en indiquant les limites à ne pas dépasser si l'on désire respecter cette situation . [PMBoK_F] : Restriction ou limitation, interne ou externe au projet, affectant les performances du projet ou d’un processus.

contrat [GDT] : Accord de volonté par lequel une ou plusieurs personnes s'obligent envers une ou plusieurs autres à exécuter une prestation de service. Note : Dans certains cas, un protocole d'entente est également considéré comme un contrat.

contrôler [GDT] : [1] control, to. Exercer une surveillance. [2] check, to. Effectuer un examen en vue de s'assurer de l'exactitude d'un registre, du bon fonctionnement d'un service, etc. Synonymes : vérifier, surveiller, superviser.

coûts de développement Cet attribut ne nécessite pas beaucoup de commentaires, car il est plus qu’évident. C’est aussi un attribut qui cause, parfois, des mauvaises conceptions. (Attention, il ne faut pas nécessairement faire un lien direct entre coûts et qualité, surtout quand on parle de conception !) Parfois il y a des idées « géniales » qui permettent d’avoir un système pas coûteux, simple, lisible, etc.


critère Métrique associée à une capacité ; le critère permet donc de comparer deux solutions en regard d'un critère d'une exigence et de déterminer laquelle des solutions la rencontre le mieux ; un seuil, en deçà duquel une solution ne rencontre pas l'exigence, est souvent associé au critère.

CRR Compte rendu de réunion.

CU Cas d’utilisation (peu importe la notation).

cycle de vie d’un projet project life cycle. [GDT] : En gestion de projet, période de temps qui s'écoule entre la naissance de l'idée d'un projet et sa pleine exploitation.

cycle de vie du logiciel « Ensemble des phases du cycle de développement du logiciel précédé par la phase de spécification du logiciel et suivi par la phase d'exploitation » [OLF-GT/informatique] ; distinguer « cycle de vie du logiciel » du « cycle de développement logiciel »

DD Dictionnaire de données

dérivation Obtention d’une classe par spécialisation en partant d’une surclasse (super-classe). La surclasse étant l’équivalent d’un concept général et la classe obtenue par héritage étant le concept spécialisé ou sous-type.

design voir conception

DFD Diagramme de flux de données

disponibilité La disponibilité indique le pourcentage de temps pendant lequel le système est disponible : disponibilité = MTBF/(MTBF+MTTR) où MTBF est la fiabilité, la moyenne des temps de bon fonctionnement (Mean Time Between Failures) et MTTR est le temps de relève, la moyenne des temps de réparation (Mean Time To Repair).

DOD Department of Defence. Ministère de la défense des États-Unis d’Amérique.

domaine de connaissance à venir

domaine de l’application Union du domaine du problème et du domaine de la solution.


domaine de la solution à venir

domaine du problème à venir

DP Domaine du problème : aussi appelé contexte du problème.

DS Diagramme structurel (ERE, UML, etc.)

EBE Étude des besoins.

échéancier schedule. [deVILLERS2003] : Tableau des échéances à respecter, des activités prévues. Synonyme : calendrier.

EER Extended Entity-Relationship (model) ; modèle entité-relation étendu.

EFA Étude de faisabilité.

éléments de données de support supporting data item. [IEEE 1044-1993]: « Data used to describe an anomaly and the environment in which it was encountered. »

élicitation Calque de l’anglais elicitation, voir exploration.

environnement cible L’environnement cible a une énorme importance pour la conception : il est clair que c’est très différent de concevoir un système pour le pilote automatique d’un avion ou un générateur de rapports sur un ordinateur central. L’environnement cible peut parfois être très pauvre et donc même si on emploie un langage très évolué on peut être obligé à développer des procédures de bases qui dans des environnements « normaux » sont déjà disponibles.

environnement de développement – Le choix d’un environnement de développement à la place d’un autre peut avoir des impacts énormes. Le choix est très complexe et parfois le désir d’avoir le meilleur environnement possible (ou le plus d’avant-garde) ça se paye très cher. – Exemple C++ en 1986.

EOP Étude d'opportunité.

épreuve – Opération unitaire destinée à vérifier le bon fonctionnement d’un artefact (logiciel, matériel, hybride) en regard d’un ensemble de critères et de conditions précises. – Voir aussi essai, test.


ER Expression régulière

ER(M) Entity-relationship (model). Modèle entité-relation.

ERE Diagramme entité-relation étendu, comprend les éventuels DD et HEE nécessaires

essai – Opération destinée à vérifier qu’un système répond aux exigences et à détecter les erreurs. Généralement, un essai comprend plusieurs tests. – Collection de tests ayant pour but d’évaluer un artefact ou un processus en regard d’un ensemble de propriétés définies – Voir aussi test, épreuve.

essai d’acceptation Essai de système développé dans le but d’accepter ou non une livraison.

essai de livraison Essai de système développé dans le but d’autoriser ou non une livraison.

essai de système – Essai développé afin d’évaluer l’adéquation d’un système (ou de toute autre entité considérée comme un produit). Les obligations de test sont constituées à partir d’un sous-ensemble convenu d’exigences. Les critères spécifiques représentent les seuils minimaux acceptables. Des critères globaux sont souvent établis sur la base d’un pointage attribué à chacune des obligations de tests. Note : il est fréquent d’adjoindre des obligations de tests issues directement de besoins et d’attentes, indépendamment des exigences, ce qui n’est pas sans comporter des risques techniques, méhodologiues et contractuels.

estimation estimation. [GDT] : Technique de modélisation dans laquelle des hypothèses sont formulées en fonction d'un scénario donné. Note : Il s'agit de la technique de modélisation la plus économique, mais la moins précise.

étape [GDT] : [1] step. C'est le point de liaison entre des activités amont et des activités aval, où le début de chaque activité aval est conditionné par l'achèvement de toutes les activités amont. Note : Le nombre de liaisons que contient une étape est égal au produit du nombre de ses activités amont par le nombre de ses activités aval. Ne pas confondre étape et événement. [2] project stage. Subdivision d'une phase d'un projet.

état Une condition significative et stable d’un objet.


évaluation évaluation. [GDT] : Technique apparentée à l'analyse et destinée à l'étude systématique des programmes. Note(s) : On opère parfois une distinction entre « analyse » et « évaluation » ; le premier terme étant compris au sens de l'examen des nouveaux programmes d'action destinés à rencontrer des besoins stratégiques, l'autre expression désignant le contrôle et l'examen des programmes en vigueur aux fins d'en mesurer les résultats. Les analyses sont des méthodes d'évaluation, l'estimation détermine l'utilité.

événement Un changement digne d’être considéré.

exigence Énoncé d’une capacité (service, fonction) dont le système est redevable. Une exigence doit être mesurable selon certains critères et peut être soumise à certaines contraintes. Une exigence est adéquatement formulée (well-formed) si et seulement si elle peut être déduite des besoins et respecte les règles du domaine d’application. Les cinq propriétés suivantes seront donc recherchées lors de la formulation d’une exigence : abstraction (pour ne pas imposer une solution particulière), cohérence (ne pas entrer en contraction avec une autre), non-ambigüité (une seule interprétation possible), traçabilité (origine des besoins dont elle est issue), testabilité (capacité de constater sa satisfaction). Une exigence, en regard de la norme IEEE 1233-1998, est décrite par les sept attributs suivants : identification, priorité, criticité, faisabilité, risque, source, type. Elle est classée par son type (entrée, sortie, fiabilité, disponibilité, maintenabilité, performance, accessibilité, environnement, ergonomie, sûreté, sécurité, etc.). [GDT] : Disposition formulant les critères à remplir pour les produits achetés et les produits fournis. Notes : Le terme clause est parfois employé en ce sens. On parle fréquemment d'exigences pour préciser ce que l'utilisateur réclame comme nécessaire à la satisfaction de ses besoins, de ses désirs ou de ses aspirations. [PMBoK_F] : Condition ou capacité qu’un système, un produit, un service, un résultat ou un composant doit satisfaire ou présenter pour être conforme à un contrat, une norme, une spécification ou tout autre document imposé formellement. Les exigences comprennent les besoins, les demandes et les attentes, quantifiés et documentés, que le commanditaire, le client et d’autres parties prenantes font valoir.

exploration Activité consistant à circonscrire le domaine, déterminer l’information à obtenir, déterminer les sources de l’information, déterminer les techniques d'acquisition et finalement acquérir l’information proprement dite ; activité initiale de l’ingénierie des exigences qui consiste à découvrir et réunion l’information relative à un problème et son contexte.

extensibilité Permettre un ajout « facile » de fonctionnalités de manière à pouvoir livrer un noyau fonctionnel et ensuite ajouter le reste.

fait Assertion (axiome, affirmation, qualification) relative au contexte au sein duquel le problème et sa solution sont définis.


FDT Tme sheet. Feuille de temps.

fiabilité Le logiciel livre toujours un résultat dans un temps raisonnable (ne plante pas, ne boucle pas).

GA Grammaire (de constituants) attribuée.

GC Grammaires de constituants attribuées ou non ; comprend un DD, si nécessaire

généralisation Activité de trouver un concept qui représente ce qui est commun à un certain nombre de concepts (et seulement ce qui est commun). Les concepts moins généraux sont des sous-types du concept général.

génie logiciel [GDT] : Ensemble des connaissances, des procédés et des acquis scientifiques et techniques mis en application pour la conception, le développement, la vérification et la documentation de logiciels, dans le but d'en optimaliser la production, le support et la qualité. Synonyme(s) : génie du logiciel, ingénierie logicielle, ingénierie du logiciel.

groupe de processus Ensemble de processus réunis pour des fins de présentation, la norme [IEEE 1074-1997] utilise les groupes suivants : gestion de projet (Project Management), pré-développement (Pre-Development), développement (Development), post-développement (Post-Development), logistique (Integral Activity Group).

GUI IEEE User manual. Guide d'utilisation

HEE Historiques des états d’entités (ELH – entity life sequence, ESH – entity state history)

Hypothèse [GDT] (gestion) : Prévision ou extrapolation fondées sur des données précises et qui permettent de bien orienter le plan. [Lalande] : Conjecture douteuse, mais vraisemblable, par laquelle l'imagination anticipe sur la connaissance, et qui est destinée à être ultérieurement vérifiée, soit par une observation directe, soit par l'accord de toutes ses conséquences avec l'observation. [PMBoK_F] : Dans un but de planification, les hypothèses sont des facteurs considérés vrais, réels ou certains sans preuve ni démonstration. Elles ont un impact sur tous les aspects de la planification du projet et font partie de son élaboration progressive. Les équipes de projets émettent, documentent et confirment souvent des hypothèses lors du processus de planification. Les hypothèses comportent en général un degré de risque.

IE Ingénierie des exigences


IEEE The Institute of Electrical and Electronics Engineers, inc.

IND Index de la documentation.

ingénierie [GDT] : Conception, étude globale d'un projet industriel sous tous ses aspects techniques, économiques, financiers et sociaux, coordonnant les études particulières des spécialistes. Terme(s) non retenu(s) :ingénieurie, ingénieurerie. Note(s) : (1) Par analogie, le terme ingénierie désigne également le savoir-faire propre aux différentes spécialités du génie. (2) Au Québec, les formes ingénieurie et ingénieurerie semblent ne plus être utilisées.

instance Un des éléments d’une classe (syn. objet).

INV Inventaire des éléments de configuration.

invariant Condition assurée sur une durant une période temps délimitée par deux événements convenus. Invariant de boucle, d’objet, de classe.

jalon milestone. Événement planifié permettant de mesurer l’état d’accomplissement d’un projet ; on distingue des jalons internes et externes relativement à l’équipe de projet de même que des jalons mineurs et majeurs relativement aux processus d’une phase. [GDT] : Événement fixé à l'avance et parfaitement défini dans le cycle de vie du logiciel. Notes : Ces événements peuvent être fixés en fin de phase du cycle de vie du logiciel ou en cours d'une phase. Ils permettent de s'assurer qu'une tâche, un document, un produit, une fourniture correspond bien à ce qui a été préalablement défini.

jalonnement sequencing. [GDT] : Mode de détermination des dates d'exécution prévisionnelles des tâches qui rendent optimale l'utilisation des ressources (moyens, stocks, etc.). Prévision dans le temps des dates des réalisations d'un produit et de ses composants, en tenant compte des temps opératoires et des contraintes de liaison entre les différentes opérations. Synonyme : séquencement des opérations.

lien Instance d’une association. Relation entre objets.

lisibilité Il faut qu’il soit facile comprendre, non seulement le système dans son ensemble, mais aussi chacun de ses composants. Voici donc l’importance de la normalisation des interfaces, de l’emploi d’un langage que tous les participants peuvent comprendre, de ne pas mélanger la définition avec la mise en œuvre, etc.

livrable Un artefact soumis à une approbation externe.


lot de planification à venir

lot de travaux work package. [GDT] : Tâches obtenues à la suite d'un découpage des travaux et regroupées en vue de répondre à des exigences administratives.

maîtriser [deVILLERS2003] : Avoir une bonne connaissance de quelque chose.

MAN Manuel de formation.

mandat terms of references. [GDT] : Description de la mission confiée à un comité ou à un autre groupe, précisant notamment les objectifs des travaux à exécuter et délimitant les sujets qui seront abordés. Note(s) : Le « groupe » qui accepte le mandat peut être une entreprise, un cabinet d'avocats, d'ingénieurs, etc. On entend plus particulièrement par attributions les pouvoirs conférés au titulaire d'une fonction, à un corps constitué ou à un service. Dans terms of reference, le mot anglais term désigne des conditions, des stipulations qui sont énoncées dans un contrat auquel on peut se référer. Il faut éviter de traduire cette expression par termes de références parce que le mot terme n'a pas ce sens en français. On parlera plutôt des stipulations du contrat.

MDC Modèle conceptuel de données (BNF, GC, DS, etc.)

menace threat. [GDT] : Circonstance inopportune [irruption des concurrents sur le marché, évolution des goûts des consommateurs, nouvelle loi, etc.] à prendre en compte dans la définition d'une stratégie.

module Mot galvaudé, mais auquel il est assez difficile de renoncer. Nous considérerons la définition de Yourdon : une séquence d’énoncés contigus au point de vue lexical, délimitée par des éléments clairement repérables, et ayant un identificateur d’agrégat. La puissance du module et sa présence presque ennuyante en informatique est due au fait qu’en ingénierie (et, en général, dans tout ce qui touche de manière plus ou moins proche à la technique — et donc qui concerne des opérations avec des résultats tangibles), le concept de boîte fermé (black box) est d’une importance énorme. On pourrait dire que la conception est le processus de trouver les bonnes boîtes dont l’étiquette explique les fonctionnalités la plus clairement possible.


monitorer [GDT] : monitor, to. terme à éviter. Voir surveiller, contrôler. Note(s) : Bien qu'on trouve un certain nombre d'attestations de monitorer dans les sources électroniques, le fait qu'il soit souvent cité entre guillemets rend compte de l'hésitation à le considérer comme un terme appartenant au système lexical français. Équivalant littéralement à l'expression descriptive surveiller automatiquement en continu, le terme anglais to monitor sera adéquatement rendu, dans la plupart des cas, par le verbe surveiller ; le verbe contrôler peut aussi convenir dans certains contextes.

MTBF voir disponibilité

MTTR voir disponibilité

multiplicité d’une association La multiplicité définit combien d’instances d’un concept sont associées aux instances d’un autre.

niveau de risque Dans un projet, il y a toujours plusieurs types de risques et, en fonction des risques pris, des conceptions différentes peuvent voir le jour. Une conception d’un nouveau style est toujours plus risquée qu’une à laquelle on est habitué !

Note(s) : [1] La vérification informatique vise principalement à détecter les erreurs de fonctionnement, les comportements frauduleux, les tentatives non autorisées de créer des fichiers ou des répertoires, d'en supprimer ou d'y accéder, etc. [2] Les enregistrements des événements sont stockés dans un fichier de vérification, dont le contenu est accessible uniquement à ceux qui en ont l'autorisation. Vérification informatique et audit de sécurité informatique diffèrent quant au sens et ne doivent donc pas être confondus. Lors d'une vérification informatique, une partie seulement des événements informatiques font l'objet d'un examen critique dans le but de détecter les erreurs et les irrégularités commises. Au contraire, l'audit de sécurité informatique revoit toutes les activités informatiques afin de produire une analyse indépendante de l'efficacité des contrôles et de la qualité de la sécurité informatique en général. De plus, la vérification informatique décrit ce qui s'est passé, tandis que l'audit de sécurité informatique évalue ce qui pourrait arriver. On évitera donc d'employer le terme audit pour désigner la vérification informatique.

opportunité opportunity. [GDT] : Conséquence probable positive attribuable à un événement incertain. Note(s) : Il peut s'agir, par exemple, d'une innovation technologique, d'une nouvelle perception du comportement des consommateurs, du développement d'une application nouvelle pour un produit existant. Même si le terme opportunité est répandu en français au sens d' « occasion favorable », il n'a pas été retenu pour désigner la possibilité, la conséquence probable. Le terme « possibilité » est généralement utilisé lorsqu'il s'agit de conséquences probables positives. S'il existe au moins la possibilité de conséquences négatives, on parlera plutôt de risque.


ordonnancement voir programmation.

PAQ IEEE SQAP software quality assurance plan. Plan d'assurance qualité

PDA Plan de dotation et d’acquisition.

PDO Plan documentaire.

performance Les performances peuvent être classées en deux grandes catégories : performances concernant l’occupation de mémoire (de travail ou de masse) et performances concernant les temps d’exécution. Actuellement on ne donne pas trop d’importance à la mémoire (surtout de masse) et voilà donc qu’on demande souvent des centaines de Mo (tout cela fait bien l’affaire des entreprises produisant du matériel électronique).

PFO Plan de formation.

PGC IEEE SCMP software configuration management plan. Plan de gestion de configuration

PGP IEEE SPMP software project management plan. Plan de gestion de projet.

phase Ensemble d’activités et de jalons issus de processus préalablement identifiés compris entre deux jalons majeurs : le jalon initial et le jalon final. Les activités contribuent toutes à la production d’un ensemble de livrables déterminant un état clairement défini dans le cycle de vie du projet. Chacun des jalons externes de la phase représente un état d’un cycle de vie. Les phases sont généralement obtenues par segmentation et itération des activités prévues au cycle de vie en fonction de critères de gestion de projet (par exemple : minimisation des risques, étalement du financement, etc.). [GDT] : Chacune des périodes successives qu'un projet doit franchir durant son cycle de vie. Note : Certains auteurs confondent les termes « étape » et « phase ». Dans la documentation consultée, les phases les plus courantes sont la phase d'identification, la phase de planification, la phase de mise en œuvre et la clôture du projet. [PMBoK_F] : La phase « identification » s'appelle « démarrage », les groupes de processus « exécution » et « surveillance et maîtrise » forment la phase de « mise en œuvre ». Par ailleurs, un chargé de projet a toujours le loisir de découper son cycle de vie autrement (le plus souvent en subdivisant les grandes phases « classiques »). Les phases sont subdivisibles et forment ainsi le premier niveau de la structure de découpage du projet. Une phase est une « transition » entre deux états (jalons) du cycle de vie du projet.


PMS Plan de mesure et support logistique.

procédé process. [GDT] : « Méthode employée pour produire un effet déterminé ou parvenir à un certain résultat ». Plus spécifiquement, en génie logiciel, méthode d’organisation des processus pour produire un ensemble de livrables (logiciels). Note : procédé et processus se disent tous deux « process » en anglais d’où, parfois, une certaine confusion !

procédure à venir

processus process. Ensemble d’activités logiquement interreliées permettant d’élaborer un ensemble de produits déterminés (la définition générale étant : ensemble d'activités logiquement interreliées produisant un résultat déterminé). Une unité exécutable gérée par l’ordonnanceur (scheduler) du système d’exploitation. [IEEE 1074-1997], « Une séquence d’activités dans la production du logiciel (la conception, par exemple) ». [GDT] : Ensemble d'activités logiquement interreliées qui produisent un résultat déterminé.

processus de classification [IEEE 1044-1993] : classification process. « The classification process is a series of activities, starting with the recognition of an anomaly through to its closure. The process is divided into four sequential steps interspersed with three administrative activities. The sequential steps are as follows: Step 1: Recognition, Step 2: Investigation, Step 3: Action, Step 4: Disposition. The three administrative activities applied to each sequential step are as follows: Recording, Classifying, Identifying impact ».

produit voir artefact.

programmation [GDT] : [1] programming. Organisation systématique des actions à entreprendre ou des étapes à franchir en vue d'atteindre des objectifs déterminés. [2] scheduling. Établissement d'un calendrier pour le déroulement d'une activité. Synonyme : ordonnancement

projet project. [GDT] : Réalisation unique, limitée dans le temps et comportant un ensemble de tâches cohérentes, utilisant des ressources humaines, matérielles et financières en vue d'atteindre les objectifs prévus au mandat, tout en respectant des contraintes particulières.

propriété Une caractéristique, un attribut que le système doit satisfaire.


PVV IEEE SVVP software validation and verification plan. Plan validation et vérification.

qualité [GDT] : Ensemble des caractéristiques d'un bien ou d'un service qui lui confèrent l'aptitude à satisfaire de manière continue les besoins et les attentes des utilisateurs ou des usagers. Notes : La qualité peut être définie par plusieurs critères : la fiabilité, la disponibilité, la durabilité, la sécurité de fonctionnement, le coût d'utilisation, etc. La qualité se mesure à l'aide d'indicateurs, par exemple : le taux de rebuts, le coût du retour en fabrication, le coût de l'échange d'un article, la perte de clientèle, le nombre de plaintes, etc. [PMBoK_F] : Pour un élément donné, degré de conformité aux exigences présenté par l’ensemble de ses caractéristiques.

réfutabilité Falsifiability.

respect des normes Le respect des normes implique bien sûr une limitation à la liberté du concepteur, mais, en même temps, peut être un élément qui facilite la créativité, car le concepteur peut se concentrer sur les éléments nouveaux en oubliant certains détails. Il suffit de penser aux règles pour les interfaces des modules

réutilisation (du code ou de la conception) On a deux possibilités de réutilisation : concevoir en réutilisant ce qui a déjà été réalisé ou concevoir afin que les autres puissent réutiliser ce que nous concevons. Quand on veut réutiliser ce qui existe déjà, on doit généralement renoncer à certaines « belles » idées de conception, car la nouvelle idée impliquerait, peut-être, des coûts, de l’apprentissage, etc. La difficulté énorme qui existe est de savoir quand la récupération devient négative, car elle empêche l’évolution (exemple très connu dans le matériel : 8080, 8085, 8088, 8086, 80289, 80386…). Concevoir afin qu’on puisse réutiliser implique prévoir du temps et des $ et donc il faut bien prévoir dans la gestion de projet. Attention à la manie de faire les choses trop générales pour pouvoir les récupérer partout !


risque [GDT] (gestion de projet) : Caractérisation d'un événement nuisible pendant une période donnée de la vie d'un produit, par sa probabilité d'occurrence et par la gravité du préjudice consécutif. Notes : Son acceptation implique celle du coût de la situation la plus favorable si elle se réalise, avec pour limite maximum le risque dit de ruine. Aussi un risque n'est-il pris que si l'espérance du gain lui est proportionnée. C'est un élément à évaluer lors de la préparation d'une décision. Les risques d'une entreprise sont essentiellement commerciaux, économiques et financiers. [GDT] (gestion de la sécurité informatique) : Probabilité plus ou moins grande de voir une menace informatique se transformer en événement réel entraînant une perte. Notes : Les risques informatiques peuvent être d'origine naturelle ou humaine, accidentelle ou intentionnelle. Le risque informatique se mesure à la fois par la probabilité d'occurrence d'une menace et par le montant de la perte consécutive à sa réalisation. [GDT] (gestion du risque) : Probabilité que survienne un événement nuisible et éventualité qu'existe une menace plus ou moins prévisible pouvant influer sur la réalisation des objectifs d'une organisation. Notes : Le risque doit être distingué de l'incertitude, qui se rapporte à un événement dont la probabilité n'est pas mesurable et qui, par conséquent, est imprévisible. Les risques d'une organisation sont aussi bien politiques, économiques, financiers, sociaux, technologiques et stratégiques qu'informatiques, opérationnels ou organisationnels. Le terme risque est généralement utilisé lorsqu'il existe au moins la possibilité de conséquences négatives. S'il ne s'agit que de conséquences probables positives, on parlera plutôt de possibilités. [PMBoK_F] : Événement ou situation dont la concrétisation, incertaine, aurait un impact positif ou négatif sur les objectifs du projet.

robustesse Indique la capacité d’un système à continuer à fonctionner même quand il reçoit des mauvaises données en entrée ou dans des conditions environnementales non normales. Robustesse par rapport à une IPM implique considérer que l’utilisateur… ne se trompe jamais (c’est-à-dire que ses actions ne sont jamais des erreurs et que donc…).

rôle Le nom d’une extrémité (dans le cas orienté, le rôle peut être au début ; en fait, il peut y avoir un rôle, généralement différent, à chaque extrémité) d’une association qui indique le rôle joué par les objets.

RP Réseau de Petri.

SA Spécification d’architecture de l’entité.

SAS Spécification d'architecture du système.

SC Spécification de conception de l'entité.


SCL EEE SDD software design document. Spécification de conception du logiciel.

SE Spécification des exigences de l'entité.

service Ensemble de capacités nécessaires (permettant) la mise en oeuvre d’un ou plusieurs processus.

SES IEEE SRS software requirements specification. Spécification des exigences du système.

SI Spécification des interfaces externes de l'entité.

simplicité L’organisation des modules et de leurs liens doit être simple au point de vue conceptuel. En regardant des représentations graphiques du système, on peut déjà donner de bonnes indications sur la simplicité. Lorsqu’on a besoin de plusieurs pages pour expliquer un échange entre des modules on peut être sûr qu’il ne s’agit pas d’un système simple. Attention, il y a des systèmes qui ont une complexité propre qui ne peut pas être réduite en dessous d’un certain seuil. Il faut aussi ajouter qu’il y a des facteurs subjectifs. Mais, le mec brillant qui fait une conception comprise de lui seul est un individu très dangereux dans une entreprise !

solution à venir.

sous-système assemblage, normalement stable, de composants réunis en fonction de critères architecturaux visant à en assurer le fonctionnement autonome.

spécification Une collection d’exigences forme une spécification si et seulement si elle répond aux neuf conditions suivantes : unicité, normalisation, inférabilité, complétude, consistance, circonscription, modifiabilité, configurabilité, granularité.

SQL Structured query language. Langage de définition, d'interrogation et de manipulation de bases de données relationnelles normalisé par l'ISO.

superviser supervise, to. [deVILLERS2003] : Contrôler, surveiller l’ensemble d’un travail.

surveiller verify, to ; monitor, to. [GDT] : Vérifier le bon déroulement d'une opération ou le fonctionnement d'un appareil d'après les activités enregistrées. Synonyme : contrôler.

système un assemblage, potentiellement éphémère, de sous-systèmes réunis en vue de l’atteinte d’un objectif opérationnel déterminé.


TA Plan de test d'architecture de l'entité.

tâche task.Travail susceptible d’être réalisé par une même personne au cours d'une période donnée. Corollaire : les compétences requises doivent pouvoir être acquises par une seule et même personne. Remarque : une tâche peut toutefois être divisée et répartie entre plusieurs personnes (chacune devant vraisemblablement réunir toutes les compétences requises) ; une telle division n’est généralement pas sans coût. [GDT] : Travail déterminé que le titulaire d'un poste doit exécuter et qui correspond à la division d'une activité spécifique. Note(s) : La tâche est habituellement considérée comme la plus petite division du travail à effectuer. Toutefois, celle-ci est elle-même constituée d'un ensemble de séquences manuelles ou intellectuelles qui forment un tout spécifique. Un même poste peut comporter plusieurs tâches. Il peut également s'agir d'un ensemble de tâches indépendantes, par exemple en vue de fabriquer un produit. La date de début et la durée de la tâche étant habituellement connues, l'exécution de cet ensemble de tâches sera organisée dans le temps par l’ordonnancement (la programmation). Ensemble d'activités logiquement interreliées qui produisent un résultat déterminé.

TC Plan de test de conception de l'entité.

TCL IEEE STD software test documentation. Plan de test de conception du logiciel

TD Table de décision

TE Plan de test des exigences de l'entité.

temps de développement Un attribut qui, comme les coûts, est une contrainte souvent très dure. Le problème avec le temps de développement est que lorsqu’on coupe trop, on risque énormément en terme de faisabilité. Ici les problèmes liés à la gestion de projet et à la conception sont terriblement reliés.

test – Opération destinée à évaluer le bon fonctionnement d'un logiciel (matériel, hybride). Généralement, un test comprend plusieurs épreuves. – Voir aussi essai, épreuve. Note : en vertu du principe d’inadéquation, un test (une épreuve ou un essai), ne peut montrer (encore moins démontrer) de façon générale le bon fonctionnement, il peut cependant montrer (démontrer) la présence d’une anomalie, d’une erreur. Un test (une épreuve ou un essai)

TI Technologies de l'information.

TIC Technologies de l'information et des communications.


tolérance aux pannes et tolérance aux défauts (défauts) ... propriété très difficile à obtenir, notamment parce qu’il est impossible de prévoir toutes les pannes (de détecter tous les défauts).

transportabilité Lorsqu’on conçoit pour la transportabilité, on doit souvent définir des couches d’interface pour séparer de l’environnement. Exemple : OS/2 et Windows : une couche basée sur OS/2, sur Windows ou différente des deux ?

UdeS Université de Sherbrooke.

UML Diagramme de classe UML, comprend les éventuels autres diagrammes nécessaires

UML Unified Modeling Language.

vague Ensemble d’activités, appartenant à des phases adjacentes, jugées suffisantes pour permettre de réunir les informations nécessaires à la planification de la prochaine période (phase ou vague) du cycle de vie du projet. Ainsi, certains jalons peuvent être atteints plus rapidement et permettre d’anticiper certaines décisions sans pour autant que toutes les activités des phases concernées soient terminées.

validation S’assurer de l’adéquation par rapport au domaine d’application compte tenu d’objectifs (de critères) connus.

validité Lorsque le logiciel livre un résultat, celui-ci est juste.

vérification S’assurer de la conformité par rapport à la spécification.

vérification informatique Examen périodique effectué à partir de certains postes d'utilisateur dans une organisation, qui consiste à détecter et à enregistrer les événements informatiques pouvant nuire à la sécurité des données.

vérifier voir contrôler.

WWWC World Wide Web Consortium.

X1 (anomalie, erreur, bogue, défaillance) Comportement perçu comme ne répondant pas aux attentes.

X2 (défaut, erreur, bogue...) Cause perçue de X1, cause de X1.

X3 Conséquence de X1.


X4 Procédure permettant de mettre en évidence X1 ; procédure permettant de vérifier la conformité aux : attentes, spécifications, exigences, contraintes, critères.

XAC Plan d’essais d’acceptation.

XFO Plan d'essais fonctionnels.

XIN Plan d’essais d’intégration.

XML Extensible Markup Language. Langage de balisage extensible normalisé par la WWWC.

3.2 Section propre à la vérification-validationAnomalie (« anomaly ») : écart constaté entre le comportement effectif et le comportement attendu.

Banc d’essai (« test bed ») : réunion d’un essai (suite de tests) et d’un environnement d’essai (matériel et logiciel).

Caractéristique d’un logiciel (« software characteristic ») : Un trait, une qualité ou une propriété inhérente, possiblement accidentelle, du logiciel.

Cas de test (« test case ») : un ensemble de données, de conditions d’exécution et de critères (de passage ou d’échec).

Cohérence (« coherence ») : Propriété d'un système logique caractérisé par une absence, apparente ou réelle, de contradictions.

Cohérence des données (« data concistency ») : Propriété selon laquelle les données contenues dans la base de données reflètent bien la réalité qu'elles représentent.

Complexité (« complexity ») : La mesure dans laquelle un composant a une conception ou une implémentation difficile à comprendre et à vérifier.

Critère (« condition ») : Mesure qualitative ou quantitative d’une caractéristique ou d’un attribut qui spécifie une capacité requise. Par exemple, le système doit être redevable d’un débit de 400 transactions à la minute.

Défaillance (« failure ») : incapacité constatée de réaliser une fonction à un moment et dans des conditions documentées.

Défaut (« fault ») : cause de l’erreur.

Disponibilité (« availability ») : La capacité d’un composant à être accessible lorsque l’on en a besoin.

Efficience (« efficiency ») : La capacité d’un composant à accomplir sa fonction en consommant un minimum de ressources.

Erreur (« error ») : écart constaté entre la spécification et la mise en œuvre (conception ou mise en exploitation).


Essai (« test suite ») : un ensemble (généralement ordonné) de cas de tests.

Expressivité (« expressive power ») : caractérise la capacité à pouvoir s’exprimer aisément dans un langage.

Fiabilité (« reliability ») : Le logiciel livre toujours un résultat dans un temps raisonnable (ne plante pas, ne boucle pas).

Performance (« performance ») : La capacité d’un composant à accomplir sa fonction selon des contraintes établies sur la consommation des ressources.

Propriété (« attribute ») : La caractéristique d’un objet, par exemple sa couleur, sa taille, son type.

Robustesse (« robustness ») : Capacité d’un composant à continuer de fonctionner même quand il reçoit de mauvaises données en entrée ou dans des conditions environnementales anormales.

Séance d’essai (« test execution ») : l’activité qui consiste à exécuter un essai et en consigner les résultats; pour certains, la séance comprend également l’interprétation des résultats.

Sécurité (« security ») : Fonction qui permet de s'assurer que les services sont employés de façon adéquate par les clients appropriés.

Seuil (« bound ») : Limite au-dessus ou au-dessous de laquelle une caractéristique est applicable.

Tolérance aux pannes (« fault tolerance ») : Capacité d’un composant à continuer de fonctionner malgré la défaillance de sous-composants (matériels ou logiciels). Très complexe non seulement parce qu’il est impossible de prévoir toutes les fautes, mais aussi parce qu’elles peuvent avoir été introduites très tôt dans le cycle de vie du logiciel.

Tolérance aux erreurs (« error tolerance ») : Capacité d’un composant à continuer de fonctionner malgré la présence de données erronées.

Traçabilité (« traceability ») : La mesure dans laquelle la raison d’être de chaque composant du système est motivée. C’est aussi la capacité à pouvoir identifier facilement leur évolution et les liens entre les composants.

Utilisabilité (« usability ») : Caractérise l’aisance avec laquelle un utilisateur peut se servir d’un composant (exécution, préparation des entrées, interprétation des sorties).

Validation (« validation ») : S’assurer de l’adéquation par rapport au domaine d’application compte tenu d’objectifs (de critères) connus.

Vérification (« verification ») : S’assurer de la conformité par rapport à la spécification.

Validité (« validity ») : Lorsque le logiciel livre un résultat, celui-ci est juste.

3.3 Section propre au Cocomo3GL (Cocomo) : Third Generation Language. ...

4GL (Cocomo) : Fourth Generation Language.


A (Cocomo) : Effort coefficient that can be calibrated.

ATPROD (Cocomo) : Automatic translation productivity.

AA (Cocomo) : Percentage of reuse effort due to assessment and assimilation.

AAF (Cocomo) : Adaptation Adjustment Factor, a component of the overall Adaptation Adjustment Multiplier for reuse sizing, including the effects of Design Modified, Code Modified, and Integration Modified factors (COCOMO Reuse model).

AAM (Cocomo) : Adaptation Adjustment Multiplier for reuse sizing (COCOMO Reuse model).

ACAP (Cocomo) : Analyst Capability Cost Driver.

APEX (Cocomo) : Applications Experience Cost Driver.

API (Cocomo) : Application Program Interface.

ASLOC (Cocomo) : Adapted Source Lines of Code, used in reuse sizing (COCOMO Reuse model).

AT (Cocomo) : Automated Translation.

B (Cocomo) : The scaling base-exponent for the effort equation that can be calibrated.

C (Cocomo) : Coefficient that can be calibrated

CASE (Cocomo) : Computer Aided Software Engineering

CCB (Cocomo) : Change Control Board

CD (Cocomo) : Commercial technology and DoD general practice

CDR (Cocomo) : Critical Design Review milestone (Waterfall development process)

CII (Cocomo) : COCOMO II.2000

CM (Cocomo) : Percentage of code modified during reuse (COCOMO Reuse model)

CM (Cocomo) : Configuration Management

CMM (Cocomo) : Capability Maturity Model

COCOMO (Cocomo) : Constructive Cost Model; refers collectively to COCOMO 81 and COCOMO II.

COCOMO 81 (Cocomo) : The original version of the Constructive Cost Model, published in 1981

COCOMO II (Cocomo) : The revised version of the Constructive Cost Model, first released in 1997

COCOMO II.1997 (Cocomo) : The original year 1997 calibration of the revised Constructive Cost Model

COCOMO II.2000 (Cocomo) : The year 2000 calibration of the revised Constructive Cost Model


COCOTS (Cocomo) : Constructive COTS cost model

COPROMO (Cocomo) : Constructive Productivity improvement Model

COPSEMO (Cocomo) : Constructive Phased Schedule & Effort Model

COQUALMO (Cocomo) : Constructive Quality Model

CORADMO (Cocomo) : Constructive RAD cost model

Cost Driver (Cocomo) : A particular characteristic of the software development that has a multiplicative effect of increasing or decreasing the amount of development effort, e.g. required product reliability, execution time constraints, project team application experience.

COTS (Cocomo) : Commercial-off-the-shelf

CPLX (Cocomo) : Product Complexity Cost Driver

D (Cocomo) : The scaling base-exponent for the schedule equation that can be calibrated

DATA (Cocomo) : Database Size Cost Driver

DBMS (Cocomo) : Database Management System

DM (Cocomo) : Percentage of design modified during reuse (COCOMO Reuse model)

DOCU (Cocomo) : Documentation Match to Lifecycle Needs Cost Driver

E (Cocomo) : The scaling exponent for the schedule equation that can be calibrated

EAF (Cocomo) : Effort Adjustment Factor – product of Cost Drivers

EM (Cocomo) : Effort Multiplier ; a value associated with a specific Cost Driver rating

ESLOC (Cocomo) : Equivalent Source Lines of Code for reuse software (COCOMO Reuse model)

F (Cocomo) : Scaling exponent for the schedule equation

FCIL (Cocomo) : Facilities

FLEX (Cocomo.SF) Development Flexibility scale factor. Facteur d’échelle prenant en compte la flexibilité des exigences (soit la capacité de faire varier celles-ci dans la mesure où les objectifs du projet sont atteints).

FP (Cocomo) : Function Points

FSP (Cocomo) : Full-time Software Personnel

GUI (Cocomo) : Graphical User Interface

H High driver rating

IFPUG International Function Point Users Group

IM Integration Modified: percentage of integration and test redone during


reuse (COCOMO Reuse model)

IOC Initial Operational Capability milestone (MBASE/RUP development

process)

IECT Inception, Elaboration, Construction, and Transition phases for the

MBASE/RUP lifecycle model

IRR Initial Readiness Review milestone (MBASE/RUP development process)

KASLOC Thousands of Adapted Source Lines of Code (COCOMO Reuse model)

KESLOC Thousands of Equivalent Source Lines of Code (COCOMO Reuse model)

KNCSS Thousands of Non-Commented Source Statements

KSLOC Thousands (K) of Source Lines of Code

L Low driver rating

LCA Life cycle Architecture milestone (MBASE/RUP development process)

LCO Life cycle Objectives milestone (MBASE/RUP development process)

LCR Life cycle Concept Review milestone (MBASE/RUP development process)

LEXP Programming Language Experience, used in COCOMO 81

LOC Lines of Code

LTEX Language and Tool Experience Cost Driver

MAF Maintenance Adjustment Factor ; used to account for software understanding and unfamiliarity effects (COCOMO Reuse and Maintenance models)

MBASE Model-Based (System) Architecting and Software Engineering

MCF Maintenance Change Factor: fraction of legacy code modified or added

(COCOMO Maintenance model)

Mo Months

N Nominal driver rating

Version 2.1 83

© 1995 – 2000 Center for Software Engineering, USC

NIST National Institute of Standards and Technology

PCAP Programmer Capability Cost Driver

PCON Personnel continuity Cost Driver

PDIF Platform Difficulty: composite Cost Driver for Early Design model

PDR Product Design Review milestone (Waterfall development process)


PERS Personnel Capability: composite Cost Driver for Early Design model

PLEX Platform Experience Cost Driver

PM Person-Months ; a person month is the amount of time one person spends

working on the software development project for one month; in

COCOMO normally assumed to be 152 person-hours.

PMAUTO Person-months effort from automatic translation activities

PMNS Person-months estimated without the SCED cost driver (Nominal

Schedule)

PMAT (Cocomo.SF) Process Maturity scale factor. Facteur d’écehelle associé au niveau de maturité du processus de développement loficiel selon la grille du CMM (CMMI).

PR Productivity Range

PREC (Cocomo.SF) Precedentedness scale factor. Facteur d’échelle prenant en compte l’exérience de l’équipe relativement à des projets similaires (tant celle des membres que de l’organasitation)

PRED(X) Prediction Accuracy: percentage of estimates within X% of the actuals

PREX Personnel Experience: composite Cost Driver for Early Design model

PROD Productivity rate

PVOL Platform Volatility Cost Driver

RAD Rapid Application Development; applies to both schedule and effort

RCPX Product Reliability and Complexity: composite Cost Driver for Early

Design model

RELY Required Software Reliability Cost Driver

RESL (Cocomo.SF) Architecture and Risk Resolution scale factor. Facteur d’échelle prenant en compte la capacité de traiter la complexité de l’architecture du produit et les autres risques techniques de projet.

REVL (Cocomo.AF) Requirements Evolution and Volatility: size adjustment factor. Facteur d’ajustement prenant en compte l’évlution et la volatilité des exigences.

ROI Return on Investment

RUP Rational Software Corporation’s Unified Process

RUSE Developed for Reusability Cost Driver


RVOL Requirements Volatility, used in COCOMO 81

SAR Software Acceptance Review milestone (Waterfall development process) Scale Factor A particular characteristic of the software development that has an exponential effect of increasing or decreasing the amount of development effort, e.g. precedentedness, process maturity.

SCED Required Development Schedule: project-level Cost Driver

SCED% Required Schedule Compression percentage

SECU Classified Security Application, used in Ada COCOMO

SEI Software Engineering Institute

SF Scale Factor; a value for a specific rating of a Scale Factor

SITE Multi-site Development Cost Driver

SLOC Source Lines of Code

SRR Software Requirements Review milestone (Waterfall development process)

STOR Main Storage Constraint Cost Driver

SU Percentage of reuse effort due to software understanding (COCOMO Reuse model)

SW-CMM Software Capability Maturity Model T&E Test and Evaluation

TCR Transition Completion Review milestone (MBASE/RUP developmentprocess)

TDEV Time to Develop (in months)

TEAM (Cocomo.SF) Team Cohesion scale factor. Facteur de cohésion de l’équipe prenant principalement en compte la qualité et la faiclité de communication entre les membres de l’équipe.

TIME Execution Time Constraint Cost Driver

TOOL Use of Software Tools Cost Driver

UNFM Programmer Unfamiliarity ; factor used in reuse and maintenance estimation (COCOMO Reuse and Maintenance models)

USAF/ESD U.S. Air Force Electronic Systems Division

UTC Unit Test Completion milestone (Waterfall development process)

VH Very High driver rating

VL Very Low driver rating

XH Extra High driver rating


4 Décomposition hiérarchique d’un système Un système est un assemblage, potentiellement éphémère, de sous-systèmes réunis en vue de l’atteinte d’un objectif opérationnel déterminé. Le sous-système est un assemblage, normalement stable, de composants réunis en fonction de critères architecturaux visant à en assurer le fonctionnement autonome.

Définition 1 – Décomposition hiérarchique d’un système.

système ::= { sous-système }* sous-système ::= { composant }* composant ::= logiciel | matériel | hybride logiciel ::= { composant logiciel }* matériel ::= { composant matériel }* hybride ::= { composant hybride }* composant logiciel ::= { composant logiciel | unité logicielle }* composant matériel ::= { composant matériel | unité matérielle}* composant hybride ::= logiciel | matériel | hybride Note : un hybride comprend nécessairement au moins un logiciel et un matériel. La topologie de l’arborescence de décomposition d’un système

Tableau 1 – Inventaire des entités constitutives d’un système.

Nom Code Topologie Dénomination DOD système SY sommet System

sous-système S nœud interne Segment

logiciel L nœud interne CSCI - computer software configuration item

composant logiciel

CL nœud interne CSC - computer software component

unité logicielle

UL feuille CSU - computer software unit

hybride H noeud interne CECI - computer embedded configuration item

composant hybride

CH noeud interne CEC - computer embedded component

matériel M noeud interne CHCI - computer hardware configuration item

composant matériel

CM noeud interne CHC - computer hardware component

unité matérielle

UM feuille CHU - computer hardware unit


5 Cheminement d’un objectif Tableau 2 – Cheminements d’un objectf.

terme formulé par en fonction de consigné par approuvé / validé par

objectif commanditaire domaine/problème commanditaire commanditaire besoin client problème client/analyste commanditaire exigence analyste, client solution analyste fc contrainte analyste, client solution analyste fc hypothèse analyste dps+contexte cp fc risque analyste dps+contexte cp fc imprévu so contexte

cp : chargé de projet. dps : définition du problème et de la solution. fc : fournisseur et commanditaire. so : sans objet.

Documents

Glossaire - Université de Sherbrooke