- Диапазон экзамена составляет 1-9, 11, 14-17 главы, поэтому большую часть набора упражнений необходимо удалить.
- Учитель сказал, что в главах 1–4, главах 6, главах 7 и главах 8 есть вопрос с кратким ответом.
- Я просто разобрал п.п., прочитанный учителем в классе, и вопросы с краткими ответами по набору упражнений (усеченная версия).Каждый вопрос был сильно урезан, оставлены только основные моменты.Вам нужно забрать неразрезанный банк вопросов : https : / /pan.baidu.com/s/1cwoqIml3BYHhrdU4hTKH5A?pwd=1234 Код извлечения: 1234
- Учащимся, у которых нет времени, рекомендуется запомнить вопросы , отмеченные красным цветом , тем, у кого мало времени, рекомендуется запомнить все вопросы Главы 6, Главы 7 и Главы 8 , а тем, у кого достаточно времени, запомнить все вопросы
- Примечание. Хотя учитель сказал, что в главах 1–4, главе 6, главе 7 и главе 8 есть по одному вопросу с кратким ответом, я наблюдал за предыдущими экзаменами, и объем вопросов с кратким ответом не ограничивается этими четырьмя. главы, и безопаснее запомнить их все.
- Текстовая версия этого блога ( версия с кратким ответом ) для самостоятельного сбора: https://pan.baidu.com/s/1mwVUjbU88AOzIZRPIfxdmQ?pwd=1234
Код извлечения: 1234
Главы с 1 по 4
1. Кратко опишите основные задачи инженерии требований
(1) Разработка требований должна объяснять как «что», так и «почему» программное обеспечение должно делать.
(2) Разработка требований должна отражать цели, функции и ограничения в программной системе, преобразовывать их в допустимое поведение программного обеспечения и специфицировать их.
(3) Инженерия требований должна правильно справляться с эволюцией целей, функций и ограничений с течением времени.
2. Кратко опишите распространенные ошибки определения требований
(1) Спрос не отражает реальных потребностей пользователей
(2) Расплывчатые и неоднозначные требования
(3) Отсутствие информации
(4) ненужный спрос
(5) Нереалистичные ожидания
3. Кратко опишите процесс выявления требований.
(1) Соберите справочную информацию
(2) Получить проблемы и цели, определить перспективы и объем проекта
(3) Определите заинтересованные стороны и выберите источники информации
(4) Выберите метод приобретения, выполните приобретение и получите функциональные и нефункциональные требования.
(5) Запишите результат приобретения
Глава шестая
1. Четыре типа информационных систем
Малые системы (ведомственные системы), организационные системы (корпоративные системы), межорганизационные системы (межкорпоративные системы), стратегические информационные системы
2. Задача анализа заинтересованных сторон
(1) Идентификация заинтересованных сторон: найдите категории заинтересованных сторон программной системы и найдите ключевых заинтересованных сторон.
(2) Описание заинтересованных сторон: опишите простые и сложные характеристики различных категорий заинтересованных сторон.
(3) Оценка заинтересованных сторон: определение приоритетов, оценка рисков и анализ конфликтов заинтересованных сторон.
(4) Выбор представителей заинтересованных сторон: выберите представителей из каждой категории заинтересованных сторон.
(5) Формулировка стратегии участия заинтересованных сторон: сформулируйте стратегии участия представителей заинтересованных сторон для участия в разработке требований и даже в разработке программных систем.
3. Методы выявления заинтересованных сторон
Простой подход: раздуть, а затем уменьшить; эмпирический подход: контрольный список; классический подход: сеть заинтересованных сторон
4. Основной процесс идентификации заинтересованных сторон
(1) Соберите первоначальные заинтересованные стороны для мозгового штурма и получите список категорий заинтересованных сторон.
(2) Проанализируйте корреляцию между оценкой списка категорий заинтересованных сторон и программной системой и сведите ее к списку ключевых категорий заинтересованных сторон.
(3) Выберите представителей для списка ключевых категорий заинтересованных сторон и проведите интенсивный мозговой штурм, чтобы составить новый список категорий заинтересованных сторон.
(4) Когда список новых категорий заинтересованных сторон станет стабильным, завершите идентификацию заинтересованных сторон; если есть новые открытия, перейдите к шагу (2)
Глава VII
1. Какова роль «модели варианта использования/сценария» в «деятельности по выявлению требований»? Почему?
имеет главный ключ
Причина: Модель варианта использования/сценария может своевременно организовать ход каждого действия по сбору требований, представить и предоставить его для действия по анализу, а также дополнительно направлять последующие действия по сбору после получения результатов анализа.
глава восьмая
1. Что мне нужно сделать, чтобы подготовиться к собеседованию?
(1) Прочтите справочную информацию
(2) Определите тему и цели интервью
(3) Выберите человека для интервью
(4) Сообщите опрашиваемому лицу подготовиться
(5) Определите проблему и тип
2. Виды интервью
(1) Структурированное интервью: безопасно контролируйте интервью в соответствии с вопросами и структурой заранее.
(2) Полуструктурированное интервью: в процессе интервью используйте несколько гибких стратегий в зависимости от реальной ситуации.
(3) Неструктурированное интервью: нет заранее запланированной повестки дня
3. Попробуйте сравнить три структуры организации вопросов интервью.
(1) Пирамидальная структура: начните с конкретных вопросов, а затем постепенно повышайте открытость вопросов. Пирамидальная структура принимается, когда интервьюируемым нужно разогреть тему, они не желают обсуждать какую-то тему и имеют большое отклонение в подтверждении фактов заранее.
(2) Структура воронки: начните с открытых вопросов, затем используйте закрытые вопросы, чтобы сузить возможные ответы. Структура воронки используется, когда интервьюируемый эмоционально относится к теме и мало знает о фактах заранее.
(3) Ромбовидная структура: начните очень определенным образом, затем исследуйте общие вопросы и, наконец, сделайте очень определенный вывод. Структура ромба заняла больше времени, чем любая другая.
Глава девятая
1. Кратко объясните, почему инструменты прототипирования используются при разработке программного обеспечения.
Прототип — это частичное реальное представление до того, как будет произведена окончательная система, что позволяет людям эффективно общаться по некоторым конкретным вопросам в процессе разработки системы и помогает людям решать различные неопределенности в процессе разработки программного обеспечения как можно раньше.
2. Базовый процесс получения требований методом прототипа
(1) Определить требования к прототипу: определить причины разработки прототипа, начальную и конечную точки, а также ожидаемые конечные критерии.
(2) Разработка прототипа: в соответствии с характеристиками спроса и целью разработки прототипа создать первоначальный прототип с наименьшими затратами.
(3) Оценка прототипа: для оценки прототипа на предыдущем этапе оцените, соответствует ли прототип конечным критериям, в соответствии с отзывами об оценке.
(4) Исправление прототипа: откорректируйте прототип в соответствии с отсутствием обратной связи и повторите оценку после завершения корректировки.
3. Сравнение трех типов методов прототипирования
(1) Исследовательский метод: метод разработки прототипа, который начинается с требований к дефектам, а затем постоянно корректирует и исправляет требования.
(2) Экспериментальный стиль: вначале есть четкие потребности пользователей, но нет большой уверенности в методах реализации, эффектах и осуществимости потребностей.
(3) Эволюционный: разработка прототипа — это не самостоятельная деятельность, а часть непрерывного процесса разработки всего проекта.
(4) Продукты-прототипы, произведенные методами исследовательских и экспериментальных прототипов, называются одноразовыми прототипами. При создании одноразового прототипа следует отказаться от кода, постараться потратить наименьшие затраты и стремиться к максимальной скорости. По этой причине разработчики будут использовать простые инструменты разработки и незрелые методы построения и пренебрегать упрощением некоторых функциональных возможностей, не связанных с целью создания прототипа.
(5) При создании эволюционного прототипа качество должно с самого начала соответствовать окончательным системным требованиям, и его должно быть легко расширять и часто улучшать, чтобы иметь дело с четкими требованиями, спецификациями и техническими решениями.
4. Основные риски подхода прототипирования
(1) Стоимость выходит из-под контроля (самый большой риск)
(2) Создать неправильное впечатление у заинтересованных сторон
(3) Пользователи могут быть ослеплены нефункциональными характеристиками прототипа.
(4) Проясняя неопределенность спроса, он также может скрывать некоторые предположения пользователей, которые не будут обнаружены.
Глава одиннадцатая
1. Ограничения методов структурного анализа
(1) Связь между требованиями к данным и требованиями к обработке непроста.
(2) Нелегко перейти от структурированного анализа к структурированному проектированию.
(3) Структурный анализ уделяет слишком много внимания моделированию существующих систем.
2. Зачем нам определять приоритет потребностей
(1) Ресурсы проекта ограничены и не могут удовлетворить все потребности пользователей
(2) В проекте используется поэтапный метод разработки, и в первую очередь должны быть удовлетворены самые важные и насущные потребности пользователей.
(3) В начале проекта не все потребности пользователей могут быть выяснены
3. Три принципа переговоров о спросе для аналитиков спроса
(1) Уточните факторы конфликта и избегайте эмоционального конфликта
(2) Очистить пространство для разрешения конфликтов
(3) Определить лучшее решение
Глава пятнадцатая
1. Зачем писать документ со спецификацией требований
(1) Это может быть основанием для соглашения между сторонами в отношении системы программного обеспечения.
(2) Это может стать важной основой для деятельности по разработке проекта.
(3) В процессе написания возможные ошибки в требованиях могут быть обнаружены и уменьшены как можно раньше, тем самым уменьшая доработку проекта и рабочую нагрузку проекта.
(4) Может быть эффективным интеллектуальным активом
2. Опишите три языка, использованные в документе
(1) Неформальный язык: то есть естественный язык.
(2) Полуформальный язык: естественный язык имеет более богатую семантику и более строгую грамматику, но не основан строго на математических методах, таких как ERD, DFD, UML и другие графические языки.
(3) Формальный язык: язык, основанный на математике, такой как VDM, язык Z.
Глава шестнадцатая
1. Кратко опишите процесс проверки
Этап планирования, этап общего развертывания, этап подготовки, этап обзорного совещания, этап доработки, этап последующих действий
2. Кратко опишите метод проверки требований
Обзор требований, прототип и моделирование, разработка тестового примера, составление руководства пользователя, отслеживание использования, автоматический анализ
Глава семнадцатая
1. Кратко опишите важные задачи управления спросом
① Сообщите о потребностях заинтересованных сторон.
② Применить и внедрить требования к решению.
③ Начать работу по проектированию и внедрению.
④ Смена управления.
⑤ Назначьте требования к подсистемам.
⑥ Протестируйте и проверьте конечный продукт.
⑦ Контролируйте изменения в итеративной разработке.
⑧Вспомогательное управление проектами.
2. Как изменился спрос?
① Проблема изменилась
② Окружающая среда изменилась
③ Дефекты базового уровня спроса
④Изменение пользователя
⑤ Изменения в осведомленности пользователей о программном обеспечении
⑥ Внешний вид сопутствующих товаров