Анализ и оценка методов разработки программного обеспечения (Agile)

Упражнение 1:

Номер 1

"Предваряющий анализ" - это:

Ответ:

(1) Анализ кода, предваряющий включение кода в работающую программную систему

(2) Анализ, предваряющий разработку каждого программного модуля

(3) Начальный этап проектирования программной системы, предваряющий разработку кода и заканчивающийся созданием "документа требований"

(4) Начальный этап проектирования программной системы, предваряющий разработку кода и заканчивающийся выработкой основных архитектурных решений

Номер 2

Какие доводы приводят сторонники Agile, критикуя "Предваряющий анализ":

Ответ:

(1) Принципиально невозможно сформулировать требования к еще не созданной системе

(2) Требования меняются в ходе разработки и потому "документ требований", создаваемый в начале работы, является бесполезным

(3) Следование первоначальному плану, который задается статическим документом требований, не соответствует изменяющимся запросам пользователей

(4) Архитектурные решения следует принимать в тот момент, когда появляется проблема, но не раньше

(5) Не следует слушать пользователей. Все решения принимают разработчики

Номер 3

Какие доводы приводит автор книги, настаивая на необходимости проведения "Предваряющего анализа":

Ответ:

(1) Архитектурные ошибки являются самыми дорогостоящими ошибками. Если такая ошибка обнаруживается на поздних этапах, то приходится переделывать большую часть уже выполненной работы. Поэтому основные решения следует тщательно готовить на этапе предваряющего анализа

(2) Документ требований не является догмой, это динамический документ, являющийся частью проекта и изменяющийся в ходе выполнения проекта

(3) Документ требований должен быть всеобъемлющим, учитывающим все возможные ситуации, возникающие в ходе выполнения проекта

(4) Архитектура проекта должна быть полностью спроектирована до начала работы над кодом

(5) Инженерии программ следует учитывать опыт инженерной деятельности, при которой ни одна серьезная разработка не начинается без проведения этапа проектирования

Упражнение 2:

Номер 1

Что понимается под термином "водопад":

Ответ:

(1) Непрерывный процесс разработки программного проекта

(2) Процесс разработки, завершающийся падением проекта с большой высоты

(3) Модель разработки, предложенную в учебных целях, включающую последовательность этапов разработки проекта, когда следующий этап начинается после завершения предыдущего этапа

(4) Модель этапов разработки проекта, не содержащая циклов

Номер 2

Сторонники Agile отождествляют "прогнозируемый процесс" с "водопадом", поскольку:

Ответ:

(1) Модель "водопада" является "прогнозируемым процессом". Отождествляя прогнозируемый процесс с водопадом, можно приписать прогнозируемому процессу все недостатки, присущие модели водопада

(2) Модели "жизненного цикла" у водопада и прогнозируемого процесса совпадают

(3) В модели водопада и в прогнозируемом процессе начальным этапом является этап "предваряющего анализа", критикуемый в Agile

Номер 3

Автор книги считает, что прогнозируемый процесс не является водопадом, поскольку:

Ответ:

(1) Модель "водопада" является "прогнозируемым процессом", но отсюда не следует обратное утверждение. Отождествлять прогнозируемый процесс с водопадом некорректно

(2) У прогнозируемого процесса и водопада этапы разработки различаются

(3) Прогнозируемый процесс является моделью "жизненного цикла" с циклическим повторением этапов разработки, в отличие от классического водопада, не предусматривающего циклов

Упражнение 3:

Номер 1

Какие утверждения справедливы по отношению к документу требований:

Ответ:

(1) Целью документа является выявление требований, позволяющих определить, правильно ли работает программная система

(2) Целью документа является выявление требований, позволяющих определить, разрабатывается ли правильная программная система, отвечающая потребностям сопричастников системы

(3) При построении программной системы в конкретной проблемной области важнейшей задачей является выявление потребностей сопричастников, - всех тех, кто заинтересован в решении стоящих проблем. Эти потребности отражаются в документе требований

(4) Главной целью документа требований является формулировка требований к разработчикам программной системы

(5) Требования, описывающие свойства предметной области, остаются неизменными в отличие от требований к создаваемой "машине" - внутренних свойств программной системы

Номер 2

Какие утверждения справедливы по отношению к документу требований:

Ответ:

(1) Ошибки в документе требований легко исправимы. Эти исправления могут быть сделаны на любом этапе работы над программной системой, что никак не отражается на самой системе

(2) Одним из основных приемов при создании документа требований является опрос сопричастников будущей системы

(3) Одним из основных приемов при создании документа требований является опрос программистов – разработчиков системы

(4) Одной из современных форм документа требований является документ, размещаемый в облаке, доступный для совместного редактирования

Номер 3

Какие утверждения справедливы по отношению к документу требований:

Ответ:

(1) Документ требований позволяет построить правильную систему

(2) Формы представления документа требований могут быть различными – текстовый документ, документ Вики, совместно редактируемый документ, размещаемый в облаке

(3) Документ требований после его создания и утверждения замораживается и не может быть изменен в ходе работы над проектом

(4) Одной из форм создания документа является семинар сопричастников проекта

Упражнение 4:

Номер 1

Сторонники Agile отрицают необходимость создания документа требований. Какие доводы они приводят в защиту такого подхода:

Ответ:

(1) Сбор требований не является предваряющей фазой, создающей статический документ, это деятельность, проясняющая детали в тот самый момент, когда они становятся необходимыми в процессе разработки

(2) Разработка системы выполняется Agile командой. Это демократический процесс, не признающий ограничений, задаваемых требованиями

(3) Документ требований бесполезен при поставке продукта, поскольку он не является частью того, что передается клиентам

(4) Документ требований быстро устаревает

(5) Создание прототипа системы важнее документа требований

Номер 2

Сторонники Agile отрицают необходимость создания документа требований по причине затратности и изменчивости этого документа. Какие аргументы приводит автор книги, оспаривая тезис "затратности":

Ответ:

(1) Пусть в документ требований включена некоторая функция math

, в ходе работы над системой может выясниться, что функция math

не требуется в системе и может быть удалена. Включение и удаление math

требует определенных затрат. При построении прототипа системы, включающего реализацию math

, также потребуются затраты, которые могут превзойти затраты в сравнении с подходом, предлагаемым документом требований

(2) Документ требований и построение прототипа системы являются дополняющими подходами

(3) Документ требований и построение прототипа системы являются альтернативными подходами, исключающими друг друга

Номер 3

Сторонники Agile отрицают необходимость создания документа требований по причине затратности и изменчивости этого документа. Какие аргументы приводит автор книги, оспаривая тезис "изменчивости":

Ответ:

(1) Для построения системы необходим план, которому необходимо строго следовать

(2) Никто в программной инженерии не требует замораживания требований, выработанных в начале проекта

(3) Требования являются частью программного проекта и могут изменяться подобно остальным компонентам проекта

(4) Наблюдение Agile об изменчивости требований является ошибочным. Требования остаются неизменными

Упражнение 5:

Номер 1

Предваряющий анализ помимо создания документа требований включает этап проектирования, на котором принимаются базисные архитектурные решения. Какие утверждения по мнению автора книги справедливы относительно процесса проектирования:

Ответ:

(1) Решения, принятые на этапе предваряющего анализа, являются окончательными и должны строго выполняться

(2) Проектирование и реализация два тесно связанных процесса. Решения, принимаемые на этапе реализации, влияют на проектные решения

(3) Возможность изменений проектных решений в ходе реализации не означает, что следует отказаться от этапа проектирования при проведении предваряющего анализа

Номер 2

Сторонники Agileотрицают необходимость предваряющего анализа, включающего этап первоначального проектирования. Каковы их доводы:

Ответ:

(1) Деятельность по проектированию должна применяться на уровне индивидуальной итерации системы, чередуясь с фазой реализации

(2) Основным способом улучшения архитектуры системы является рефакторинг, который следует выполнять, когда действующая архитектура перестает удовлетворять потребностям системы

(3) Перед выполнением каждой итерации следует пересматривать архитектурные решения

(4) Проблемы нужно решать не тогда, когда они проявляются, а заранее, прогнозируя их появление

Номер 3

На этапе предваряющего анализа не следует делать "слишком много". Какие решения следует принимать на этом этапе:

Ответ:

(1) Проектирование абстракций - абстрактных классов в терминах ООП

(2) Выбор образцов проектирования (паттернов) для решения ключевых проблем

(3) Проектирование спецификаций интерфейса (взаимодействия) между модулями

(4) Проектирование таксономии – семейств классов, связанных отношениями наследования и вложенности

(5) Проектирование и реализация динамических библиотек классов, допускающих повторное использование

Упражнение 6:

Номер 1

Какие утверждения справедливы для понятия "модель жизненного цикла":

Ответ:

(1) Модель жизненного цикла определяет и стандартизует последовательность этапов разработки программной системы

(2) Современные модели жизненного цикла носят итеративный характер

(3) При разработке программных систем Agile не использует модели жизненного цикла

(4) Модель жизненного цикла играет как декларативную (описательную) роль, так и дескриптивную (предписывающую) роль

Номер 2

Какие этапы характерны для моделей жизненного цикла:

Ответ:

(1) Анализ требований

(2) Проектирование

(3) Реализация

(4) Ранжирование

(5) Чистка

(6) Верификация и проверка правильности

Номер 3

Какие практики характерны для модели жизненного цикла RUP (Рациональный Унифицированный Процесс):

Ответ:

(1) Итеративная разработка

(2) Визуализация архитектуры

(3) Анализ проектных ошибок

(4) Непрерывная проверка качества

(5) Непрерывный анализ требований

Упражнение 7:

Номер 1

Какие утверждения справедливы по отношению к понятию "Модели зрелости":

Ответ:

(1) Понятие "Модель зрелости" является развитием понятия "Модель жизненного цикла"

(2) Интеграционная Модель Технологической Зрелости (CMMI) позволяет оценить профессиональный уровень разработки программных систем в конкретной организации

(3) Каждая организация, разрабатывающая программные продукты, сама определяет свой уровень зрелости

(4) Применяемые практики, цели и оценки в процессе разработки программного продукта определяют уровень зрелости CMMI

Номер 2

На каком из пяти уровней CMMI требуется, чтобы процессы разработки программной системы были строго определены соответствующими документами, процедурами и инструментарием:

Ответ:

(1) Начальный

(2) Управляемый

(3) Определенный

(4) Управляемый на основе количественных данных

(5) Оптимизируемый

Номер 3

Методы Agile имеют собственную трехуровневую шкалу зрелости – Shu – Ha – Ri. Что должна делать команда, достигшая высшего уровня зрелости:

Ответ:

(1) Применять стандартные рецепты

(2) Комбинировать существующие рецепты и правила

(3) Уметь превзойти достигнутое

(4) Создавать собственные правила и рецепты

Анализ и оценка методов разработки программного обеспечения (Agile) - тест 3