- La plage d'examen est de 1 à 9, 11, 14 à 17 chapitres, donc une grande partie de l'ensemble d'exercices doit être supprimée
- L'enseignant a dit que les chapitres 1 à 4, le chapitre 6, le chapitre 7 et le chapitre 8 ont chacun une question à réponse courte
- J'ai simplement trié le ppt enseigné par l'enseignant en classe et les questions à réponse courte sur l'ensemble d'exercices (version tronquée). Chaque question a été considérablement réduite, ne laissant que les points principaux. Vous devez choisir la banque de questions non coupées : https : / /pan.baidu.com/s/1cwoqIml3BYHhrdU4hTKH5A?pwd=1234 Code d'extraction : 1234
- Il est recommandé aux élèves qui n'ont pas le temps de mémoriser les questions marquées en rouge , à ceux qui manquent de temps de mémoriser toutes les questions des chapitres 6, 7 et 8 , et à ceux qui ont beaucoup de temps de mémoriser toutes les questions
- Remarque : Bien que l'enseignant ait dit que les chapitres 1 à 4, le chapitre 6, le chapitre 7 et le chapitre 8 ont chacun une question à réponse courte, mais j'ai observé les examens précédents, et la portée des questions à réponse courte ne se limite pas à ces quatre chapitres, et il est plus sûr de tous les mémoriser.
- La version Word de ce blog ( version supprimée à réponse courte ) auto-collection : https://pan.baidu.com/s/1mwVUjbU88AOzIZRPIfxdmQ?pwd=1234
Code d'extraction : 1234
Chapitres 1 à 4
1. Décrire brièvement les principales tâches de l'ingénierie des exigences
(1) L'ingénierie des exigences doit expliquer à la fois « quoi » et « pourquoi » le logiciel doit faire.
(2) L'ingénierie des exigences doit refléter les objectifs, les fonctions et les contraintes dans le système logiciel, les mapper en comportements logiciels réalisables et les spécifier.
(3) L'ingénierie des exigences doit gérer correctement l'évolution des objectifs, des fonctions et des contraintes dans le temps
2. Décrire brièvement les erreurs courantes de définition des exigences
(1) La demande ne reflète pas les besoins réels des utilisateurs
(2) Exigences vagues et ambiguës
(3) Omission d'informations
(4) demande inutile
(5) Attentes irréalistes
3. Décrivez brièvement le processus des activités d'élicitation des exigences.
(1) Recueillir des informations générales
(2) Obtenir les problèmes et les objectifs, définir les perspectives et la portée du projet
(3) Identifier les parties prenantes et sélectionner les sources d'information
(4) Sélectionner la méthode d'acquisition, exécuter l'acquisition et acquérir les exigences fonctionnelles et non fonctionnelles
(5) Enregistrer le résultat de l'acquisition
Chapitre six
1. Quatre types de systèmes d'information
Petits systèmes (systèmes départementaux), systèmes organisationnels (systèmes d'entreprise), systèmes inter-organisationnels (systèmes inter-entreprises), systèmes d'information stratégique
2. La tâche de l'analyse des parties prenantes
(1) Identification des parties prenantes : trouvez les catégories de parties prenantes du système logiciel et découvrez les principales parties prenantes.
(2) Description des parties prenantes : décrire les caractéristiques simples et complexes des différentes catégories de parties prenantes
(3) Évaluation des parties prenantes : hiérarchisation, évaluation des risques et analyse des conflits entre les parties prenantes
(4) Sélection des représentants des parties prenantes : sélectionner des représentants de chaque catégorie de parties prenantes
(5) Formulation de la stratégie de participation des parties prenantes : formuler des stratégies de participation pour que les représentants des parties prenantes participent à l'élaboration des exigences et même au développement du système logiciel
3. Méthodes d'identification des parties prenantes
Approche simple : gonfler puis rétrécir ; Approche empirique : liste de contrôle ; Approche classique : réseau de parties prenantes
4. Le processus de base d'identification des parties prenantes
(1) Rassemblez les premières parties prenantes pour un brainstorming et obtenez une liste des catégories de parties prenantes
(2) Analyser la corrélation entre le jugement de la liste des catégories de parties prenantes et le système logiciel, et la réduire à une liste de catégories de parties prenantes clés
(3) Sélectionner des représentants pour la liste des catégories de parties prenantes clés et réfléchir intensément pour arriver à une nouvelle liste de catégories de parties prenantes
(4) Lorsque la liste des nouvelles catégories de parties prenantes tend à être stable, terminer l'identification des parties prenantes ; s'il y a de nouvelles découvertes, passer à l'étape (2)
Chapitre VII
1. Quel est le rôle du "modèle de cas d'utilisation/scénario" dans les "activités d'élicitation des exigences" ? Pourquoi?
a l'indice principal
Raison : Le modèle de cas d'utilisation/scénario peut organiser la progression de chaque activité d'acquisition d'exigences en temps opportun, la présenter et la fournir à l'activité d'analyse, et guider davantage les activités d'acquisition ultérieures une fois les résultats de l'analyse obtenus.
chapitre huit
1. Que dois-je faire pour me préparer à l'entretien ?
(1) Lire les informations générales
(2) Déterminer le sujet et les objectifs de l'entretien
(3) Sélectionnez la personne à interroger
(4) Aviser la personne interrogée de préparer
(5) Déterminer le problème et le type
2. Types d'entretiens
(1) Entretien structuré : contrôlez l'entretien en toute sécurité en fonction des questions et de la structure à l'avance
(2) Entretien semi-structuré : pendant le processus d'entretien, adoptez des stratégies flexibles en fonction de la situation réelle
(3) Entretien non structuré : pas d'ordre du jour préétabli
3. Essayez de comparer les trois structures d'organisation des questions d'entretien
(1) Structure pyramidale : commencez par des questions spécifiques, puis augmentez progressivement l'ouverture des questions. La structure pyramidale est adoptée lorsque les personnes interrogées ont besoin d'échauffer le sujet, ne veulent pas discuter d'un certain sujet et ont un grand écart dans la confirmation des faits à l'avance.
(2) Structure en entonnoir : Commencez par des questions ouvertes, puis utilisez des questions fermées pour affiner les réponses possibles. La structure en entonnoir est utilisée lorsque la personne interrogée est émotive sur le sujet et ne sait pas grand-chose des faits à l'avance.
(3) Structure en diamant : commencer d'une manière très précise, puis examiner les questions générales et enfin tirer une conclusion très précise. La structure en losange a pris plus de temps que toutes les autres.
Chapitre neuf
1. Expliquez brièvement pourquoi les outils de prototypage sont utilisés dans le développement de logiciels
Un prototype est une représentation réelle partielle avant que le système final ne soit produit. Il permet aux gens de communiquer efficacement sur certaines questions spécifiques dans le processus de développement du système et aide les gens à résoudre le plus tôt possible diverses incertitudes dans le processus de développement logiciel.
2. Le processus de base d'acquisition des exigences par la méthode du prototype
(1) Déterminer les exigences du prototype : déterminer les raisons du développement du prototype, les points de départ et d'arrivée et les critères de fin attendus
(2) Développement de prototype : selon les caractéristiques de la demande et l'objectif de développement du prototype, établir le prototype initial au moindre coût
(3) Évaluation du prototype : pour l'évaluation du prototype de l'étape précédente, jugez si le prototype répond aux critères finaux en fonction du retour d'évaluation
(4) Correction du prototype : ajustez le prototype en fonction du manque de rétroaction et réévaluez une fois l'ajustement terminé.
3. Comparaison des trois types de méthodes de prototypage
(1) Méthode exploratoire : une méthode de développement de prototypes qui commence par les exigences relatives aux défauts, puis ajuste et corrige continuellement les exigences
(2) Style expérimental : il y a des besoins clairs pour les utilisateurs au début, mais il n'y a pas beaucoup de confiance dans les méthodes de réalisation, les effets et la faisabilité des besoins
(3) Évolutif : Le développement du prototype n'est pas une activité indépendante, mais une partie du processus de développement continu de l'ensemble du projet
(4) Les produits prototypes produits par des méthodes de prototypes exploratoires et expérimentaux sont appelés prototypes jetables. Lors de la construction d'un prototype jetable, le code doit être jeté, essayer de dépenser le moins possible et viser la vitesse la plus rapide. Pour cette raison, les développeurs utiliseront des outils de développement simples et des techniques de construction immatures, et négligeront de simplifier certaines caractéristiques fonctionnelles qui ne sont pas liées à l'objectif du prototype.
(5) Lors de la construction d'un prototype évolutif, la qualité doit répondre aux exigences finales du système dès le début, et il doit être facile de l'étendre et de l'améliorer fréquemment pour faire face à des exigences, des spécifications et des solutions techniques claires.
4. Les principaux risques de la démarche de prototypage
(1) Coût hors de contrôle (risque le plus élevé)
(2) Créer une mauvaise impression sur les parties prenantes
(3) Les utilisateurs peuvent être aveuglés par les caractéristiques non fonctionnelles présentées par le prototype
(4) Tout en clarifiant l'incertitude de la demande, cela peut également dissimuler certaines hypothèses des utilisateurs, qui ne seront pas découvertes
Chapitre onze
1. Limites des méthodes d'analyse structurée
(1) Le lien entre les exigences en matière de données et les exigences en matière de traitement n'est pas facile
(2) Il n'est pas facile de passer de l'analyse structurée à la conception structurée
(3) L'analyse structurelle accorde trop d'attention à la modélisation des systèmes existants
2. Pourquoi devrions-nous déterminer la priorité des besoins
(1) Les ressources du projet sont limitées et ne peuvent répondre à tous les besoins des utilisateurs
(2) Le projet adopte une méthode de développement par étapes, et les besoins les plus importants et les plus urgents des utilisateurs doivent être satisfaits en premier
(3) Au début du projet, tous les besoins des utilisateurs ne peuvent pas être clarifiés
3. Trois principes de négociation de la demande pour les analystes de la demande
(1) Clarifier les facteurs de conflit et éviter les conflits émotionnels
(2) Effacer l'espace de résolution des conflits
(3) Déterminer la meilleure solution
Chapitre quinze
1. Pourquoi rédiger un cahier des charges
(1) Il peut être la base d'un accord entre les parties concernant le système logiciel
(2) Il peut être une base importante pour les activités de développement de projet
(3) Au cours de son processus d'écriture, les éventuelles erreurs d'exigence peuvent être découvertes et réduites le plus tôt possible, réduisant ainsi la reprise du projet et la charge de travail du projet
(4) Cela peut être un atout intellectuel efficace
2. Décrivez les trois langues utilisées dans le document
(1) Langage informel : c'est-à-dire le langage naturel.
(2) Langage semi-formel : le langage naturel a une sémantique plus riche et une grammaire plus stricte, mais n'est pas strictement basé sur des méthodes mathématiques, telles que ERD, DFD, UML et d'autres langages graphiques.
(3) Langage formel : langage basé sur les mathématiques, tel que VDM, langage Z
Chapitre seize
1. Décrivez brièvement le processus d'examen
Phase de planification, phase de déploiement général, phase de préparation, phase de réunion de revue, phase de retravail, phase de suivi
2. Décrire brièvement la méthode de vérification des exigences
Examen des exigences, prototype et simulation, développement de cas de test, compilation de manuels d'utilisation, relation de suivi d'utilisation, analyse automatisée
Chapitre dix-sept
1. Décrivez brièvement les tâches importantes de la gestion de la demande
① Communiquer les besoins des parties prenantes.
② Appliquer et implémenter les exigences de la solution.
③ Conduire les travaux de conception et de mise en œuvre.
④ Changement de contrôle.
⑤ Attribuez des exigences aux sous-systèmes.
⑥ Testez et vérifiez le produit final.
⑦ Contrôler les changements dans le développement itératif.
⑧Gestion de projet auxiliaire.
2. Quelles sont les évolutions de la demande ?
① Le problème a changé
②L'environnement a changé
③ Défauts dans la ligne de base de la demande
④Changement d'utilisateur
⑤ Changements dans la connaissance des logiciels par les utilisateurs
⑥ Apparition des produits associés