Glossaire Flashcards

(88 cards)

1
Q

Architecture logicielle

A

Description symbolique et schématique des différents éléments d’un ou de plusieurs systèmes informatiques, de leurs interrelations et de leurs interactions.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
2
Q

Base de données (BD)

A

Ensemble structuré de données stockées de manière à être facilement accessibles, gérées et mises à jour.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
3
Q

Conception détaillée

A

Étape de la réalisation technique qui consiste à spécifier en détail les composantes (modules) du logiciel.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
4
Q

Conception physique de la BD

A

Implantation concrète de la structure de la base de données, en tenant compte des performances et des contraintes techniques.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
5
Q

Conception physique des traitements

A

Description précise de la logique interne de chaque module de traitement, souvent à l’aide de pseudo-code ou de diagrammes.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
6
Q

Couplage

A

Mesure de l’interdépendance entre les modules d’un logiciel. Un faible couplage est généralement souhaitable.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
7
Q

Débogage (Debugging)

A

Processus d’identification, d’analyse et de correction des erreurs (bugs) dans un programme informatique.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
8
Q

Livrable

A

Tout produit tangible ou intangible résultant d’une phase ou d’une tâche d’un projet, par exemple le logiciel, la documentation, les manuels.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
9
Q

Module

A

Composante autonome et identifiable d’un logiciel, conçue pour accomplir une fonction spécifique. En orienté-objet, on parle souvent de ‘package’.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
10
Q

Test d’acceptation

A

Niveau de test effectué par l’utilisateur final pour vérifier si le système répond à ses besoins et est prêt à être utilisé.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
11
Q

Test d’intégration

A

Niveau de test qui vise à vérifier l’interaction et la communication entre les différents modules d’un logiciel une fois qu’ils ont été développés individuellement.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
12
Q

Test de boîte blanche

A

Méthode de test qui examine la structure interne et le code source d’un logiciel pour concevoir les cas de test, en s’assurant que tous les chemins d’exécution sont testés.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
13
Q

Test de boîte noire

A

Méthode de test qui se concentre sur les fonctionnalités externes d’un logiciel sans examiner sa structure interne. Les cas de test sont basés sur les spécifications des entrées et des sorties.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
14
Q

Test de validation

A

Niveau de test qui vérifie si le logiciel développé correspond aux besoins et aux spécifications définis lors de la phase d’analyse.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
15
Q

Test unitaire

A

Niveau de test qui porte sur le test individuel des plus petites unités de code (fonctions, procédures, méthodes, modules).

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
16
Q

Tests sélectifs

A

Stratégie de test qui consiste à choisir un sous-ensemble de tous les chemins d’exécution possibles pour tester un programme, en se basant sur des critères spécifiques.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
17
Q

Tests exhaustifs

A

Stratégie de test qui tente d’exécuter tous les chemins d’exécution possibles d’un programme, ce qui est souvent impraticable en raison du nombre potentiellement élevé de chemins.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
18
Q

Architecture Logicielle

A

Description symbolique et schématique des différents éléments d’un ou plusieurs systèmes informatiques, de leurs interrelations et de leurs interactions.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
19
Q

Approche Modulaire

A

Stratégie de conception consistant à diviser un système en unités indépendantes et interchangeables appelées modules, chacun ayant une fonction spécifique et des interfaces bien définies.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
20
Q

Architecture Fonctionnelle

A

Type d’architecture basé sur la décomposition d’une fonctionnalité en sous-fonctionnalités de manière hiérarchique (en appels et retours).

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
21
Q

Architecture Centrée sur les Données

A

Type d’architecture où un composant central (serveur de données) gère les données et est utilisé par des modules clients pour y accéder. Également appelée architecture client-serveur.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
22
Q

Architecture en Couches

A

Type d’architecture où les composants logiciels sont organisés en un empilement de couches, chaque couche offrant des services à la couche supérieure et utilisant les services de la couche inférieure via des interfaces.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
23
Q

Couplage

A

Mesure du degré d’interdépendance entre les modules d’un système. Un faible couplage est généralement souhaitable.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
24
Q

Cohésion

A

Mesure du degré de relation fonctionnelle entre les éléments à l’intérieur d’un module. Une forte cohésion est généralement souhaitable.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
25
Interopérabilité Extrinsèque
Capacité d'un logiciel à communiquer et à utiliser les ressources d'autres logiciels.
26
Interopérabilité Intrinsèque
Degré de cohérence entre le fonctionnement des commandes et des modules à l'intérieur d'un même système ou logiciel.
27
Réutilisation
Capacité de concevoir un logiciel avec des composants existants et de rendre ses propres composants facilement utilisables dans d'autres développements.
28
DFD (Diagramme de Flux de Données)
Représentation graphique du flux de données à travers un système, mettant en évidence les processus, les entités externes et les stockages de données.
29
Modèle Conventionnel d'Architecture
Modèle architectural qui impose une séparation claire entre les données, les traitements et la présentation.
30
Mise en place
La phase du cycle de vie d'un système d'information qui consiste à installer et à rendre opérationnel le nouveau système ou le progiciel choisi au sein de l'organisation.
31
Exploitation
La phase durant laquelle le système d'information est utilisé quotidiennement par les utilisateurs pour réaliser les activités de l'entreprise. Cette phase inclut également l'entretien du système.
32
Évaluation
Le processus d'analyse et de mesure de l'efficacité et de l'impact du système d'information après sa mise en place, en comparant les résultats obtenus aux objectifs initiaux.
33
Conversion des données
Le processus de transfert des données de l'ancien système vers le nouveau système. Cela peut inclure la restructuration, le nettoyage et la validation des données.
34
Formation des utilisateurs
L'ensemble des activités visant à enseigner aux utilisateurs comment utiliser le nouveau système d'information de manière efficace et efficiente.
35
Approche directe
Une méthode de passage de l'ancien au nouveau système où l'ancien système est arrêté et le nouveau système est mis en service simultanément.
36
Approche par traitement parallèle
Une méthode où l'ancien et le nouveau système fonctionnent en même temps pendant une période donnée pour permettre la comparaison et la validation.
37
Approche par centres pilotes
Une méthode où le nouveau système est d'abord déployé dans un ou plusieurs départements ou groupes d'utilisateurs spécifiques avant d'être étendu à toute l'organisation.
38
Approche par livraisons successives
Une méthode où le nouveau système est déployé en plusieurs étapes ou modules, permettant une introduction progressive du changement.
39
Entretien
L'ensemble des activités visant à assurer le bon fonctionnement continu du système d'information, incluant la correction d'erreurs, l'adaptation aux changements et l'amélioration des performances.
40
Gestion du changement
L'ensemble des processus et des techniques utilisés pour préparer, soutenir et aider les individus, les équipes et les organisations à faire face aux changements et à les adopter avec succès.
41
Système d'information (SI)
Un ensemble organisé d'éléments (personnel, matériel, logiciel, données, procédures) interagissant pour collecter, traiter, stocker et distribuer de l'information afin de soutenir la prise de décision et le contrôle dans une organisation.
42
Progiciel
Un logiciel standardisé, conçu pour répondre aux besoins d'un ensemble d'organisations ayant des besoins similaires (ex : un ERP, un CRM). Sa mise en place implique souvent une paramétrisation plutôt qu'un développement complet.
43
BD (Base de données)
Un ensemble structuré de données stockées sur un support informatique, organisé de manière à faciliter son accès, sa gestion et sa mise à jour.
44
Maintenance logicielle
L'ensemble des activités effectuées pour modifier un logiciel après sa mise en opération, incluant la correction d'erreurs, l'adaptation à l'environnement, l'amélioration et la modernisation.
45
Maintenabilité
La facilité avec laquelle un logiciel peut être corrigé en cas d'erreurs et modifié ou étendu pour répondre à de nouveaux besoins. C'est une caractéristique importante de la qualité du logiciel.
46
Réingénierie logicielle
Le processus de réalisation d'une nouvelle implémentation d'un logiciel existant, visant à restructurer ou réécrire le système sans changer significativement ses fonctionnalités, afin de faciliter la maintenance future.
47
Système patrimonial (legacy system)
Un système d'information ancien qui est toujours essentiel pour l'entreprise mais qui est difficile à maintenir en raison de son âge, de sa technologie obsolète, du manque de documentation ou de l'absence des concepteurs originaux.
48
Maintenance corrective
Le type de maintenance visant à réparer les erreurs et les défauts découverts dans le logiciel après sa mise en production.
49
Maintenance adaptative
Le type de maintenance nécessaire pour modifier un logiciel en réponse à des changements dans son environnement technique, comme une mise à jour du système d'exploitation ou l'introduction de nouveaux matériels.
50
Maintenance perfective
Le type de maintenance qui implique des modifications ou des ajouts au logiciel basés sur les nouveaux besoins des utilisateurs ou pour améliorer les performances et la conception du système.
51
Modèle de maintenance
Un cadre structuré décrivant les étapes et les activités impliquées dans la gestion et l'évolution d'un logiciel après sa livraison.
52
Complexité cyclomatique
Une métrique logicielle indiquant la complexité d'un programme en mesurant le nombre de chemins indépendants dans son code. Une complexité élevée peut rendre le code difficile à comprendre et à maintenir.
53
Couplage (en programmation)
Le degré d'interdépendance entre différents modules d'un logiciel. Un couplage élevé signifie que les modules sont fortement dépendants les uns des autres, ce qui peut compliquer la maintenance et les modifications.
54
COTS (Commercial Off-The-Shelf)
Composants logiciels commerciaux disponibles sur le marché et qui peuvent être intégrés dans un système.
55
Reverse Engineering (rétro-ingénierie)
Le processus d'analyse d'un logiciel existant pour en déduire ses spécifications, sa conception et ses détails d'implémentation, souvent utilisé en l'absence de documentation adéquate.
56
Forward Engineering (développement de logiciel)
Le processus traditionnel de développement de logiciel à partir de spécifications et de modèles de conception, aboutissant à la création d'un nouveau système ou d'une version restructurée d'un système existant (dans le contexte de la réingénierie).
57
Cycle de développement logiciel
L'ensemble des étapes planifiées et structurées suivies pour développer un logiciel, depuis la conception initiale jusqu'à la livraison et la maintenance.
58
Méthode en cascade
Une approche séquentielle du développement logiciel où chaque phase (analyse, conception, développement, tests, livraison) est complétée avant de passer à la suivante, sans retour en arrière prévu.
59
Approche itérative
Une approche de développement où le logiciel est construit par cycles (itérations) successifs, chaque itération raffinant la version précédente et intégrant de nouvelles fonctionnalités.
60
Approche incrémentale
Une approche de développement où le logiciel est livré en parties fonctionnelles (incréments), chaque incrément s'appuyant sur les précédents pour former un système complet.
61
Développement par prototypage
Une approche qui consiste à créer des versions préliminaires (prototypes) du logiciel pour recueillir les besoins des utilisateurs, explorer des options de conception ou valider des idées avant le développement complet.
62
Prototype exploratoire
Un type de prototype utilisé pour clarifier les besoins et les spécifications, souvent une maquette de l'interface utilisateur qui est généralement jetée après sa fonction.
63
Prototype évolutif
Un type de prototype développé avec l'intention de le faire évoluer et de l'intégrer progressivement au système final.
64
Développement par composantes
Une approche basée sur l'assemblage d'applications à partir de modules logiciels préexistants et testés (composantes).
65
Approche de réutilisation
Une approche qui met l'accent sur l'utilisation de composants logiciels existants (développés en interne ou acquis) pour réduire les coûts et les délais de développement.
66
Méthodes agiles
Un ensemble d'approches de développement itératives et incrémentales qui mettent l'accent sur la collaboration, la flexibilité, la réponse rapide au changement et la livraison fréquente de logiciels fonctionnels.
67
Programmation Extrême (PE)
Une méthode agile qui se concentre sur un développement rapide et une forte implication des utilisateurs, en utilisant des pratiques comme la programmation en binômes, les tests continus et l'intégration continue.
68
Approche en spirale
Un modèle de cycle de développement piloté par les risques, combinant des éléments des approches en cascade et de prototypage, avec une analyse des risques effectuée à chaque itération.
69
BPMN (Business Process Model Notation)
Norme de notation graphique pour la modélisation des processus métiers, visant à fournir un standard compréhensible par tous les utilisateurs.
70
Processus métier (Business Process)
Ensemble d'activités effectuées par une entreprise dans le but d'accomplir un objectif précis.
71
Orchestration
Processus interne et privé à une seule organisation, décrivant les échanges d'activités au sein de celle-ci.
72
Chorégraphie
Collaboration et échanges externes entre deux ou plusieurs entités d'affaire (participants).
73
Objet de flux (Flow Object)
Élément fondamental de BPMN représentant le déroulement du processus (activité, événement, branchement).
74
Activité
Un traitement ou une tâche effectué dans le processus métier, représenté par un rectangle aux coins arrondis. Peut être atomique (tâche) ou composite (sous-processus).
75
Tâche
Une activité élémentaire et indivisible dans un processus.
76
Sous-processus
Une activité composite qui peut contenir un niveau de détail supplémentaire, permettant de structurer et de simplifier les diagrammes.
77
Événement
Quelque chose qui se produit et qui affecte le déroulement d'un processus (début, intermédiaire, fin).
78
Branchement (Gateway)
Point de contrôle dans un processus qui détermine le routage des flux en fonction de conditions ou d'événements (exclusif, parallèle, inclusif, complexe).
79
Objet de connexion (Connecting Object)
Élément de BPMN utilisé pour relier les objets de flux (flux de séquence, flux de message, association).
80
Flux de séquence (Sequence Flow)
Flèche pleine indiquant l'ordre d'exécution des activités dans un processus.
81
Flux de message (Message Flow)
Ligne pointillée avec une flèche indiquant l'échange de messages entre deux participants (pools).
82
Couloir (Swimlane)
Conteneur graphique dans un diagramme BPMN utilisé pour organiser les activités et montrer les responsabilités (pool et lane).
83
Pool
Un couloir représentant un participant majeur dans un processus (une organisation ou un système).
84
Lane
Une sous-partition à l'intérieur d'un pool, généralement utilisée pour représenter des rôles ou des départements.
85
Artefact
Élément qui fournit des informations supplémentaires sur le processus sans affecter directement le flux d'exécution (objet de données, groupe, annotation textuelle).
86
Objet de données (Data Object)
Représentation de la manière dont les données et les documents sont utilisés dans un processus.
87
BPMS (Business Process Management Suite)
Ensemble de logiciels destinés à capturer, automatiser, contrôler et optimiser les processus métiers.
88
BPEL (Business Process Execution Language)
Langage de programmation basé sur XML utilisé pour définir et exécuter des processus métiers, notamment en orchestrant des services web.