intra Flashcards
1
Q
Avantages de la programmation orientée objet
A
Modularité, réutilisabilité, maintenance, adaptabilité
2
Q
Problèmes du génie logiciel
A
Taille et complexité des logiciels
Grandes équipes
Évolution rapide des app
Spécifications peu précises
3
Q
Solution à taille et complexité des logiciels
A
Décomposer le processus de dév, découper en sous-syst
4
Q
Solution à taille croissante des équipes
A
Vocabulaire unifié, organisation du travail
5
Q
Solution à évolution rapide des app
A
Cycle de vie itératif et incrémental (comme cycle de vie objet)
6
Q
Solution à spécifications peu précises
A
Modèle pour éclairer, récapituler et montrer points clés des spécifications
7
Q
Quels sont les étapes de l’analyse des besoins
A
- analyse des exigences
- reformulation des exigences sous une forme plus rigoureuse
- construction d’un premier modèle
8
Q
Techniques pour l’analyse des exigences
A
Entrevue, questionnaire, observation, documentation
9
Q
Pourquoi l’entrevue est pertinente
A
Car les documents ne sont pas toujours fiables
10
Q
Pourquoi un questionnaire est pertinent
A
Quand veut données précises aupres d’un grand nombre de personnes
11
Q
Un désavantage du questionnaire
A
Faible taux de participation
12
Q
Pourquoi observation est pertinente
A
Pour immersion directe dans les activités des employés, mieux comprendre culture
13
Q
Limites de l’observation ?
A
Identifier période représentative, effet Hawthorne
14
Q
Pourquoi documentation pertinente (dans analyse des exigences)
A
Gain de temps, moins couteux, infos structurées
15
Q
Exemples de documentation dans analyse des exigences
A
Rapports annuel, planification, règlements au travail, énoncé de mission
16
Q
Pourquoi construire un premier modèle ?
A
Traduire les exigences en vision concrète, faciliter compréhension et validation, guide de développement
17
Q
Quels sont les modèles complémentaires
A
Modélisation du domaine d’information (entités et relations) et du domaine de la fonctionnalité (cas d’utilisation)
18
Q
Processus d’affaire, c’est quoi
A
Série d’activités organisés pour atteindre objectif spécifique ou résultat de valeur (inputs -> outputs)
19
Q
En entreprise, les systèmes d’information appuient…
A
leur processus d’affaire
20
Q
Comment un système d’information peut appuyer un processus d’affaire ?
A
Automatisation minimale: enregistrer les infos sur le processus
Automatisation partielle: autom certaines étapes du processus, connaissances et règles dans syst
Automatisation totale
21
Q
Caractéristiques d’un processus d’affaire
A
Clarté (départ et arrivée définis)
Répétabilité
Orienté valeur
22
Q
Composantes d’un processus d’affaire
A
Entrée (ressources)
Activités (étapes pour transformer entrée)
Sorties (résultat)
Visuel (illustration)
23
Q
Types de processus d’affaire
A
Processus clé : apport valeur direct
Processus de support : facilite processus clé
Processus de gestion: supervise
24
Q
Aspects qui rendent importants les processus d’affaire
A
- Efficacité (temps, ressources)
- Qualité et cohérence (résultats prévisibles et fiables)
- Satisf client (rép rapide adaptée aux besoins)
25
Comment analyser et améliorer un processus d'affaire
- Identifier processus à analyser
- Cartographier étapes
- Identifier les goulots
- Proposer améliorations
26
Processus d'affaire vs cas d'utilisation
processus: représentation générale, pas concret
CU: scénarios précis, concret, interaction avec système
27
Quels sont les langages de modélisation à différents niveaux de formalisation
Langages formels (maths, preuves, ..)
Langages semi-formels (UML, graphique)
28
Modélisation par décomposition fonctionnelle
Décomposer la fonction globale en fonctions simples (à coder)
29
Concept clé de la modélisation de conception orientée objet
données encapsulées dans objets et méthodes modulaires
30
UML stands for
Unified Modeling Langage
Langage de modélisation unifié
31
UML est né quand
années 90
32
UML sous entend quoi
orienté objet
33
OMG stands for
Object Management Group
organisme international ayant publié UML
34
Objectif du UML
fournir une notation graphique pour modéliser les systèmes logiciels complexes
35
Cas d'utilisation fait quoi
Raconte sous forme de texte comment acteur interagit avec un système pour atteindre un objectif (mesurable)
36
Utilités des cas d'utilisation
1. clarté des besoins (vue claire interactions)
2. Centré sur utilisateur (objectifs et attentes utilisateur)
3. Communication efficace
4. Détection scénarios
37
Documentation des cas d'utilisation
Description textuelle
Diagramme de CU (acteurs, liens entre CU, moins détaillé)
38
Formats des cas d'utilisation
1. Abrégé : un paragraphe, le scénario succès
2. Informal : semi-élaboré, différents scénarios, plusieurs paragraphes
3. Détaillé: complet, toutes les étapes et variantes, détaillé
39
Cas d'utilisation..
collection de scénarios réussite ou échec
décrivant façon dont acteur.s utilise syst pour atteindre un but
40
Composantes d'un CU
1. Nom de CU
2. Objectif
3. Acteurs
4. Scénario principal
5. Flux alternatifs
6. Préconditions
7. Postconditions
41
Acteurs d'un CU
- acteur primaire (permet id buts utilisateurs)
- acteur auxiliaire (offre service, info au syst)
- acteur hors champ (interagit indirectement avec le syst)
42
Scénario
suite spécifiques d'actions, étapes, et interactions entre acteur et syst
flux principal ou alternatif
un CU comprend plusieurs scénarios
43
Scénario alternatif couvre..
scénario d'échec
cas traitement spécial VIP
cas exceptionnel
what if
44
L'annotation de scénario principal en scénario alternatif suit ...
une organisation hiérarchique
45
Les préconditions décrivent..
l'état initial requis
46
Les postconditions décrivent ...
l'état final attendu et reflètent les changements effectués
47
La rédaction des CU doit se faire en..
boîte noire
48
Les CU sont conçus à quelle étape du cycle de vie logiciel ?
Spécification logicielle / conception ??
49
Étapes de découverte des CU
1. Choisir les limites du syst (extérieur au syst: acteurs)
2. Id acteurs principaux et le but de chacun
3. Définir un CU pour chaque but utilisateur
50
CU et fonctions système
Pour une fonction système, il y a plusieurs CU
Un CU entre dans une fonction syst
51
Composantes d'un diagramme de CU
- Acteur (bonhomme)
- CU (ellipse)
- Système (carré)
52
Quelle est la relation entre un CU et un acteur
Association (ligne pleine)
53
Quelles sont les relations entre les CU
Inclusion
Extension
Généralisation
54
Relation d'inclusion ..
A -----> B
ligne pointillée entre CU
B est obligatoire à A
55
Relation d'extension...
A <----- B
ligne pointillée entre CU
B est optionnel à A
56
Relation de généralisation...
A <---------- B
ligne pleine
[CU] flèche pointe élément général
[acteur] B accès à tous les CU de A
57
Approche orientée objet s'est propagée à deux étapes à deux moments
Approche OO s'est propagée à la conception (milieu 80) et à l'analyse (fin 80)
58
Objectif de la programmation orientée objet
Modéliser des syst complexes en utilisant objets représentants éléments du monde réel
59
Concepts de la programmations orientée objet
Classe, objet, encapsulation, héritage, polymorphisme
60
Quels sont les étapes de cycle de vie logiciel
1. analyse des besoins
2. analyse et spécification logicielle
3. conception
4. codage, implémentation, réalisation
5. tests
6. installation, déploiement
7. maintenance
61
Quels sont les besoins exigences
Exigences d'affaires
Exigences fonctionnelles
Exigences non fonctionnelles
61
Quelles sont les parties prenantes dans l'analyse des besoins
Gestionnaires, représentants commerciaux, développeurs, testeurs, clients
62
Exigences d'affaires
Pourquoi construire/mettre à jour le système ?
63
Besoins exigences fonctionnelles
Comportement que système doit avoir pour que les usagers puissent réaliser leurs objectifs/taches
64
Types d'exigences non fonctionnelles
Qualités d'exploitation
exactitude, fiabilité, efficacité, intégrité, commodité, sécurité
Qualités de révision
maintenabilité, testabilité, flexibilité
Qualités de transition
portabilité, réutilisabilité, interfaçabilité
65
Fiabilité
ecq système fait ce que je veux à CHAQUE fois
66
Besoins exigences système
exigence de haut niveau pur un système complexe intégrant sous systèmes logiciels et matériels, besoins généraux du système dans son ensemble
67
Documentation des exigences des systèmes permettant de traduire besoins identifiés en spécifications
Document du concept d'opération (CONOPS)
Document de vision
68
Étape d'analyse et spécification logicielle
traduit exigences en spécifications (fonctionnalités et contraintes)
69
Activités de l'étape d'analyse et spécification logicielle
- produire modèle de classe (entités)
- produire modèle détaillé de CU
- modulariser CU et classes en modules d'analyse
- produire première architecture fonctionnelle
70
Objectif de l'étape de conception
Fournir plan clair et structuré pour guider implémentation, définir architecture globale
71
Quelles sont les activités de l'étape de conception (2)
Conception architecturale
Conception détaillée
72
En quoi consiste la conception architecturale
Choisir style architecture
id composantes (modules, BD)
spécifier interfaces des composantes
73
En quoi consiste la conception détaillée
modèle de classe
modèle comportemental
modèle de CU
74
Activités de l'étape de l'implémentation (codage)
- implémentation de l'architecture
- implémentation classe
- tests unitaires
- implémenter sous-syst
- intégration sous-syst
75
Quels sont les type de tests
Tests fonctionnels
Tests de performance
Tests de sécurité
Tests de régression
Tests d'acceptation
76
Quels sont les activités dans l'étape de test
Planifier les tests
concevoir les tests
implémenter tests
effectuer tests d'intégration
effectuer tests système
évaluer tests
77
Activités de l'étape de déploiement
configuration environnement
déploiement binairies
tests préliminaires
tests d'acceptation (UAT et de capacité)
Mise en production
78
Types de maintenance
perfective (faire changements demandés par users)
adaptative (adapter logiciel aux changement de l'environnement)
corrective
79
incrément vs itératif
incrémente : ajout fonctionnalité
itératif : amélioration
80
étapes modèle cascade
séquentiel
1. besoins
2. conception
3. implémentation
4. vérification
5. maintenance
81
Où sont fait les tests pendants cascade
tests unitaires et d'intégration pendant l'implémentation
tests système (exigences non fonctionnelles) pendant vérification (test)
82
RAD stands for
Rapid Application Development
83
Étapes de RAD
itératif
1. analyse exigences
2. développer prototype
3. évaluer prototype par client
-> 2 -> 3 -> 2 -> 3 ..
84
inconvénients de RAD
limité projets moyen
implication utilisateurs dépendance
manque documentation détaillée pour maintenance long terme
85
Étapes d'un modèle incémental
1. analyse besoins
2. spécifications logicielles
3. conception (architecture)
4. découpage en module (prioriser)
5. implémenter et intégrer module
6. démontrer version au client
-> 4 ou 7. mise ne production
86
avantages développement incrémental
permet mise en oeuvre partielle et prise en compte des retours users dès le début
(1er incrément = fonctionalités essentielles)
87
inconvénient développement incrémental
intégration multiples incréments complexe
88
développement incrémental idéal pour..
grands projets où exigences évoluent au fil du temps
89
approche itérative vs incrémentale
itérative: répétition des cycles de dév pour affiner le produit
incrémental: construction du produit par petites portions livrables
90
étapes de développement Agile
1. brainstorm
2. conception
3. implémentation
4. QA (resolve issues)
5. deploiement
-> itération suivante ou delivery
91
Emphase d'Agile
pragmatisme (vs dogmatisme)
réactivité aux changements
implication constante du client
feedback fréquent à tous les niveaux
92
Objectif Agile
Livrer petites portions fonctionnelles du logiciel à intervalles réguliers (sprint)
93
Choix du modèle de cycle de vie dépend de..
caractéristiques spécifiques du projet
contraintes particulières
94
Quel est le meilleur modèle de développement pour un projet complexe, changeant avec besoin de collaboration continue
Agile
95
Quel est le meilleur modèle de développement pour un projet où des fonctionnalités claires doivent êtres livrées progressivement avec une planification initiale pus rigide
Incrémental
96
Quel est le meilleur modèle de développement pour un projet nécessitant un développement rapide avec des exigences bien définies
RAD
97
La collecte des exigences se fait quand avec le développement en cascade
Au début, collecte détaillée et formelle, peu flexible
98
La collecte des exigences se fait quand avec le développement incrémental
Collecte initiale suivie de raffinement à chaque itération
99
La collecte des exigences se fait quand avec le développement RAD
Collecte rapide au début, prototypage rapide pour valider exigences avec users
100
La collecte des exigences se fait quand avec le développement Agile
Collecte continue tout au long du projet
101
Def méthodologie
ensemble de
pratiques
procédures
règles
heuristiques
pour produire des livrables
102
Def processus
Outil de gestion qui
- prescrit une division de travail
- id et standardise les livrables intermédiaires
- id et standardise les critères pour la revue et éval des livrables
102
Quelles sont les activités de gestion du développement
1- Planification
2- Exécution
3- Suivi
4- Clôture
103
def Notation
façons d'exprimer les livrables
syntaxe
sémantique
104
Lien entre processus et méthodologie
Processus identifie les étapes
Méthodologie s'intéresse au passage entre les étapes (comment)
