Жизненный цикл программного изделия

Задачи  начальной фазы методологии  экстремального программирования.

1. Построение единой  концепции проекта.

2. Создание условий  для выполнения проекта в рамках  методологии экстремального программирвания.

3. Построение и  внедрение первого реелиза программной системы.

Основой адаптивной разработки по Хайсмиту является.

2. Обучение как  метод, с помощью которого все  участники проекта совместными  усилиями определяют целесообразное  направление развития проекта.

4. Три нелинейные  фазы обдумывания, сотрудничества  и обучения.

5. Обеспечеие коммуникационной среды, в которой разработчики самостоятельно находят решение проблем реализации проекта.

Модели  традиционного представления. 

Общепринятая  модель жизненного цикла  состоит из следующих  этапов.

2. Определение требований, спецификации, проектирования, реализации.

3. Проектирования, реализации, тестирования, сопровождения.

4. Реализация, сопровождение,  развитие.

Фактическое начало работ над  проектом характеризуется  тем, что.

3. В проекте активизировались  роли исполнителей, выполняющих  анализ осуществимости задания.

4. В проекте появились  лица, деятельность которых подконтрольна  менеджеру проекта.

5. Активизируются  функции архитектора проекта

Какими  способами преодолевается недостаток классической итерационной модели, связанные с возвратами на предыдущие шиги?

2. Тщательно проверяются  результаты работ этапов.

3. Используются объектно- ориентированные методологии для сохранения достижений , полученных на предыдущих шагах процесса.

5. Данный недостаток  непреодолим в рамках последовательного  развития проектов.

Идентификация потребности в  новом приложении- это.

2. Определение того, какие функции нужны пользователю  при автоматизации поддержки  его деятельности.

3. Определение того, для каких пользователей разрабатывается  приложение.

5. Описание требований  к программной системе.

Проектирование  как этап в общей  модели- это.

1. Синоним слова  "конструирование".

2. Синоним слова  "Дизайн".

4. Этап проекта  декомпозиции системы.

Характерные черты каскадной  модели.

3. Завершение каждого  этапа проверкой полученных результатов.

4. Циклическое повторение  пройденных этапов.

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

Определение требований- это.

1. Определение того, какие функции нужны пользователю.

3. Описание общего  контекста задачи, ожидаемых функций  системы и ее ограничений.

5. Действия заказчика,  связанные с выяснением потребности  в разработке.

Реализация  как этап в общепринятой модели- это.

1. Синоним слова  "кодирование".

2. Кодирование и  сборка системы.

5. Кодирование и  отладка модулей

Подтверждение в каскадной модели- это.

2. То же что  тестирование.

3. то же что  верификация.

4. то же что  аттестация.

Преимущества  каскадной модели разработки ПО.

1. Хорошо работает  для проектов с хорошо определенными  требованиями.

2. Модель проста  и удобна в применении.

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

Преимущества  каскадной модели разработки ПО.

3. Отличается стабильностью  требований.

4. Позволяет разрабатывать ПО высокого качества.

5. Способствует строгому  контролю за ходом разработки

Недостатки  каскадной модели разработки ПО.

1. Затруднен возврат  на предыдущие фазы разработки  для исправления ошибок.

3. Может создавать  ошибочное представление о ходе  проекта.

5. Заказчик не  может оценить ПО в процессе его создания

Объектно-ориентированное  проектирование отличается от традиционных подходов тем, что.

1. Используется итеративность  развития и функциональность  наращивается в соответствии  со сценариями.

2. Используются традиционные  этапы, которые повторяются при  переходе от итерации к итерации.

4. Сценарии используются  как основа распределения требований  по итерациям.

Что означает критерий системной  значимости?

1. Оценка сценария  как необходимого элемента системы.

2. Оценка сценария  с точки зрения потребности  развития поекта, внутреннея по отношению к пользовательским задачам.

3. Оценка сценария  с точки зрения реализации  для него системных средств:  заготовок широкого применения, базовых и интструментальных компонентов.

Главные менеджерские обязанности  в проекте в  контрольной точке "Спецификации реализуемых сценариев  составлены" - это.

1. Руководство трансформацией  сценариев в архитектуру.

2. Инвентаризация  ресурсов и выяснение,  хватит  ли ресурсов для реализации  выбранных сценариев.

3. Оформление подготовленных  к реализации сценариев для  их утверждения.

Критерии  отбора сценариев  для реализации- это.

2. Способ упорядочить  предварительно отобранные для  реализации сценарии по степени  их важности.

3. Определение свойств сценариев, которые упорядочивают предварительно отобранные сценарии для реализации по степени их важности.

5. Показатели предпочтения  разработчиков и заказчиков. 
 

Что означает критерий демонстрационой значимости?

1. Оценка сценария  с позиций демонстрации различных  выигрышных качеств проекта.

2. Оценка интерфейсных  возможностей сценария.

3. Оценка сценаря с позиций уточения основных требований к системе на ранних этапах проектирования.

Пополнение  базового окруженя проекта- это.

1. Процедура оформления  компонента программного обеспечения,  который объявляется как переиспользуемый.

3. Этап жизненного  цикла, вложенный в этап оценки, в ходе которого выделяются  общие компоненты, оформляемые как  переиспользуемые.

5. Организация процесса  включения программного компонента  в депозитарий проекта.

Ближайшая задача проекта- это.

1. Набор сценариев,  назначенных для реализации в  текущей итерации, и проектных  условий и ограничений, которым  реализация должна удовлетворять.

2. Задача текущей  итерации.

3. Набор функций,  реализуемых в текущей итерации.

Различия  между критериями и ограничениями  с точки зрения задачи отбора сценариев.

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

4. Критерии фиксируют  параметры актуальности, а ограничения  задаюи все остальные параметры.

5.  Критерии оценивают  сценарии с разных точек зрения, а ограничения оценивают условия,  создааемые для реализации

Расщепление линии жизненного цикла при итеративном  наращивании приводит.

1. К появлению  и одновременному существованию  двух версий системы.

3. К передаче пользователю очередной версии программного обеспечения (бета-

тестирование).

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

Характерные черты метода экстремального программирования.

1. Работа с заказчиком (заказчик в команде разработчиков).

3. Написание тестов  до начала написания кода.

5. Парное программирование. 
 

Преимущества  модели экстремального программирования.

2. Существует возможность  быстрого просмотра продукта  разработки.

3. Участие заказчика  определяет его удовлетворенность  разработкой.

4. Требуется меньшее  количество специалистов.

Недостатки  модели быстрой разработки.

1. Необходимо привлечение  высококвалифицированных разработчиков.

2. Не накладывается  строгих ограничений на затраты  и срок выполнения.

3. Если заказчик  не сможет постоянно участвовать  в разработке, качество продукта  может оказаться неудовлетворительным.

Область применения модели быстрой  разработки.

3. При выполнении  небольших проектов со сроком  разработки до 2 месяцев.

4. Когда затраты  и выполнение графика не являются  главными проблемами.

5. Если заказчик  действительно принимает участие  в разработке на всем ее  протяжении.