Главная / Программирование / Технологии программирования на базе Microsoft Solutions Framework

Технологии программирования на базе Microsoft Solutions Framework - ответы на тесты Интуит

Правильные ответы выделены зелёным цветом.
Все ответы: В рамках данного курса рассмотрены технологические основы процесса разработки программного обеспечения. В качестве базовой методологии разработки программного продукта выбрана методология MSF.

Какая программа считается простой?

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

(2) несложная в усвоении

(3) хорошо структурированная

Программная инженерия -

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

(2) несложная в усвоении профессия

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

UML - это

(1) набор структур и методик для моделирования и проектирования объектно-ориентированных программ и приложений

(2) набор структур и методик для моделирования и проектирования программ

(3) Universal Markup Language - универсальный язык разметки

Microsoft Operations Framework (MOF) предлагает рекомендации помогающие обеспечеть

(1) надежность решений

(2) доступность решений

(3) удобство в сопровождении

(4) управляемость

Дисциплина управления рисками в MSF for Agile Software Development это

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

(2) дисциплина, используемая на стадии проектирования проекта

(3) дисциплина, используемая на стадии сдачи проекта

Главной вехой фазы выработки концепции является

(1) веха "Концепция утверждена"

(2) веха "Концепция намечена"

(3) веха "Концепция определена"

Основные задачи и сферы ответственности ролевого кластера управление продуктом во время фазы разработки -

(1) ожидания заказчика

(2) управление функциональной спецификацией; мониторинг проекта; доработка планов

(3) разработка программного кода и инфраструктуры; документирование конфигураций

Для того чтобы IT-проекты были успешными, необходимо:

(1) чтобы продукт вышел на рынок надлежащего качества

(2) чтобы продукт вышел на рынок вовремя

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

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

Предметная область computer science это

(1) теория и основы разработки ПО

(2) вопросы разработки систем с участием компьютеров

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

Открытые атрибуты отмечаются

(1) "+"

(2) "#"

(3) "-"

Минимально допустимое количество человек задействованных в проектной группе

(1) 6 человек

(2) 4 человека

(3) 3 человека

Цель управления рисками -

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

(2) избежать рисков

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

Основные задачи и сферы ответственности ролевого кластера управление программой, во время фазы выбора концепции -

(1) цели дизайна; концепция решения; структура проекта

(2) прототипирование; анализ технологических возможностей; анализ осуществимости

(3) необходимые эксплуатационные характеристики решения и их влияние на его разработку

Основные задачи и сферы ответственности ролевого кластера удовлетворение потребителя во время фазы разработки -

(1) обучение; доработка плана обучения; тестирование удобства эксплуатации (usability testing); графический дизайн

(2) чеклисты развертывания (rollout checklists); доработка планов внедрения (включая пилотное внедрение); чеклисты подготовки к внедрению (site preparation checklists)

(3) функциональное тестирование; выявление проблем; тестирование документации; доработка плана тестирования

Подразумевает ли схема возвраты назад (циклы)

(1) да, но только в случает т.н. "пробуксовки цикла по Ритону"

(2) нет

(3) да

Почему операционная система FreeBSD менее популярна на домашних ПК, чем Windows

(1) значительно меньший выбор игр

(2) менее удобный в освоении интерфейс

(3) большее количество ошибок

Объектно-ориентированное проектирование - это

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

(2) проектирование средствами UML 2.0

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

Важные нововведения в MSF 4.0:

(1) MSF - это образ мыслей

(2) MSF разделилась на два направления MSF for Agile Software Development и MSF for CMMI Process Improvement

(3) важных нововведений не было - были исправлены некоторые недочеты

Дисциплина управления рисками MSF представляет собой

(1) процесс из шести шагов: выявление, анализ и приоритезация, планирование, мониторинг и отчетность, корректирование, извлечение уроков, выявление

(2) процесс из 3-х шагов: анализ, мониторинг, выявление

(3) процесс из 3-х шагов: мониторинг, анализ, выявление

Основные задачи и сферы ответственности ролевого кластера тестирование, во время фазы выбора концепции -

(1) стратегии тестирования; критерии приемлемости, их влияние на разработку решения

(2) цели дизайна; концепция решения; структура проекта

(3) необходимые эксплуатационные характеристики решения и их влияние на его разработку

Фаза разработки

(1) подразумевает создание проектной группой компонент решения

(2) включает в себя разработку инфраструктуры

(3) не включает в себя разработку инфраструктуры

Блок схема это:

(1) графическое представление программы или алгоритма с использованием стандартных графических элементов

(2) технология описания программы

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

Расходы на создании По чаще всего состоят (разработка/тестирование):

(1) 60/40

(2) 50/50

(3) 90/10

Диаграмма кооперации -

(1) показывает структурную организацию участвующих во взаимодействии объектов

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

(3) диаграмма связана с временными рамками проекта

Концепции MSF при построении команды

(1) нацеленность на конечный результат

(2) установка на отсутствие дефектов

(3) "проектная группа - команда равных"

Планирование рисков (risk planning) -

(1) имеет целью выработку стратегий

(2) предшествует этапу извлечения уроков

(3) выполняется исходя из информации полученной на этапе анализа рисков

Рамки (scope) -

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

(2) ограничения на проект по времени

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

Во время фазы разработки возможно выделения промежуточных вех

(1) концепция подтверждена

(2) алгоритм отлажен

(3) билд за номером № завершен

Прямоугольник в блок-схеме обозначает:

(1) обобщенное действие

(2) условие

(3) ожидание ввода данных пользователя

Эволюционная модель это

(1) смесь каскадной и спиральной модели

(2) процесс становления человеком из обезьяны

(3) генетическое видоизменение амебы

Диаграмма компонентов -

(1) показывает компоненты и связи между ними

(2) показывает внутреннюю структуру классов и связи с внешним миром

(3) показывает классы, их атрибуты и связи между классами

Зона ответственности управления командой, в MSF 4.0 -

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

(2) система в целом

(3) понимание потребностей пользователей, их реализация

Корректирование ситуации (risk control) -

(1) включает в себя инициирование изменений всего проекта

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

(3) предшествует этапу мониторинга

Рамки решения (solution scope) -

(1) определяют функциональность решения и его возможности

(2) определяют время отведенное на решения

(3) тоже что и рамки (scope)

Результаты фазы стабилизации -

(1) окончательный продукт

(2) документации выпуска

(3) проект в стадии "Каппа"

В блок-схеме связи обозначаются:

(1) стрелками

(2) линиями

(3) тонкими линиями

Эволюционная модель приемлема для

(1) для малых и средних

(2) для больших

(3) для сверх больших

Стандарт UML 2.0 был принят в

(1) марте 2006

(2) октябре 2004

(3) марте 2003

Зона ответственности группы тестирования, в MSF 4.0 -

(1) гладкое внедрение решения в инфраструктуру заказчика

(2) разработка системы в целом

(3) качество решения с точки зрения заказчика и будущих пользователей

Модель процессов MSF (MSF process model) сочетает в себе

(1) свойства каскадной и итерационной моделей

(2) свойства спиральной и итерционной моделей

(3) свойства каскадной и спиральной моделей

Фаза планирования (planning) -

(1) необязательная для малых коллективов фаза

(2) оценивает необходимые время затраты

(3) содержит основную работу по составлению планов проекта

Основные задачи и сферы ответственности ролевого кластера управление продуктом, в модели MSF, во время фазы стабилизации

(1) мониторинг проекта; приоритезация ошибок

(2) устранение ошибок; оптимизация программного кода

(3) исполнение коммуникационного плана; планирование премьеры продукта

В основе технологии объектно-ориентированного программирования лежат:

(1) объектная модель

(2) объектное моделирование

(3) объектная декомпозиция

Для каждого шага модели пошаговой разработки можно применять

(1) каскадную модуль

(2) объектную модель

(3) эволюционную модель

Интерфейс - это

(1) согласующая система

(2) часть ПО, видимая конечному пользователю

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

Ролевая группа управление программой, в MSF 4.0, выполняет задачи:

(1) разрабатывает, поддерживает и исполняет сводный план и календарный график проекта

(2) регулирует взаимоотношения и коммуникацию внутри проектной группы

(3) организует управление рисками

Треугольник компромиссов образуют

(1) ресурсы, время, возможности

(2) грамотное управление, ресурсы, время

(3) время, возможности, грамотное управление

Основные задачи и сферы ответственности ролевого кластера разработка -

(1) оценка технологий; логический и физический дизайн; план и календарный график разработки; смета разработки (development estimates)

(2) оценка дизайна; требования тестирования; план и календарный график тестирования

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

Основные задачи и сферы ответственности ролевого кластера удовлетворение потребителя, в модели MSF, во время фазы стабилизации

(1) тестирование; сообщение об ошибках и их статусе; тестирование конфигурации

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

(3) развертывание и поддержка пилотного внедрения; планирование внедрения; обучение персонала сопровождения

Компонентное программирование это развитие идеологии:

(1) нейропрограммирования

(2) програмирования компонента

(3) объектно-ориентированной технологии

Суть каскадной модели:

(1) определение требования к системе определяются на начальном этапе и далее не меняются

(2) создание надежного кода

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

Кардинальность 0..* говорит о том, что

(1) возможно от 0 до бесконечности сущностей

(2) сущность отсутствует до перегрузки

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

Ролевая группа разработка, в MSF 4.0, выполняет задачи:

(1) определяет детали физического дизайна

(2) разрабатывает или контролирует разработку элементов

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

Принципы модели процессов:

(1) взаимодействуйте с заказчиками

(2) поощряйте свободный обмен информацией в проекте

(3) устраивайте корпоративный вечеринки

Основные задачи и сферы ответственности ролевого кластера управление выпуском -

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

(2) оценка дизайна; эксплуатационные требования; план и календарный график пилотного и окончательного внедрения

(3) оценка дизайна; требования тестирования; план и календарный график тестирования

Стандартом MSF, предусмотрены следующие промежуточные вехи в фазе стабилизации:

(1) точка конвергенции

(2) точка достижения нуля

(3) точка бифуркации

Абстрагирование -

(1) ранжированная система абстракций

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

(3) процесс выделения абстракций в предметной области

Спиральная модель -

(1) выполняет итерации с обратной связью

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

(3) выполняет итерации без обратной связи

Зависимость между сущностями графически оформляется как

(1) пунктирная линия со стрелкой

(2) ненаправленная линия

(3) пунктирная ненаправленная линия

Ролевая группа управление выпуском, в MSF 4.0, выполняет задачи:

(1) представляет интересы отделов поставки и обслуживания продукта

(2) организует снабжение проектной группы

(3) организует сопровождение и инфраструктуру поставки

Матрица компромиссов проекта:

(1) полезное средство управления проектными компромиссами

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

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

Результаты фазы выработки концепции:

(1) общее описание и рамки проекта (vision/scope document)

(2) описание структуры проекта (project structure document)

(3) функциональная спецификация

Веха "Внедрение завершено" -

(1) кульминация фазы внедрения

(2) кульминация жизненного цикла проекта

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

Могут ли компоненты быть написаны на различных языках?

(1) да, т.к. компонент своего рода "черный ящик"

(2) нет

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

Модель процесса создания ПО -

(1) представление процесса, рассматривающее состав этапов и способы их претворения в жизнь

(2) описание тех или иных программных решений

(3) модель на языке ассемблер

Ассоциация

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

(2) это не структурная связь

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

Ролевая группа удовлетворение потребителя, в MSF 4.0, выполняет задачи:

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

(2) определяет требования к системе помощи и ее содержание

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

Фраза "Зафиксировав ресурсы, мы согласовываем календарный график и принимаем результирующий объем функциональности решения", говорит о том, что

(1) влиять на ресурсы невозможно

(2) наиболее изменяемы ресурсы

(3) наиболее изменяем функционал

Промежуточная веха - верификация технологий -

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

(2) не рекомендуемая веха

(3) рекомендуемая стандартом MSF веха

Результаты фазы внедрения включают:

(1) версии проектных документов, массивы данных (load sets) и программный код, разработанные во время проекта

(2) отчет о завершении проекта (project close-out report)

(3) наиболее изменяемый функционал

В иерархическом дереве класса по мере удаления от корня встречаются

(1) все более сложные классы

(2) все более специфичные классы

(3) все более простые классы

Аттестация, как стадия процесса создания ПО:

(1) проверка ПО на соответсвие потребностям заказчика

(2) подтверждение класса ПП

(3) развитие в соответствии с изменившимися потребностями заказчика

Компонент -

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

(2) это двоичный файл

(3) файл PE формата

Решение о бюджете принимает

(1) ролевая группа управление продуктом

(2) заказчик или спонсор проекта

(3) менеджер группы управление продуктом

Особенности модели MSF -

(1) итеративный подход

(2) подход, основанный на фазах и вехах

(3) интегрированный подход к созданию и внедрению решений

Промежуточная веха - средства разработки и тестирования развернуты -

(1) настроено необходимое для разработки аппаратно-программное обеспечение

(2) веха не рекомендуется стандартом MSF

(3) веха рекомендуется стандартом MSF

Основные задачи проектной группы на фазе внедрения, ролевого кластера разработка

(1) получение отзывов и оценок заказчика; акт о приеме выполненной работы

(2) разрешение проблем; поддержка эскалации

(3) сопоставление рамок проекта с поставленным решением; управление стабилизацией

Технология модульного программирования сформировалась в

(1) 70-х годах

(2) 60-х годах

(3) 90-х годах

Модульное программирование относится к стадии

(1) реализации

(2) аттестации

(3) спецификации

Смысл полиморфизма в объектном подходе -

(1) выбор метода родительского класса

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

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

MSF основывается на утверждении

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

(2) каждый ролевой кластер представляет уникальную точку зрения на проект

(3) каждый ролевой кластер имеет равные права

Особенности "вех":

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

(2) в MSF используются обобщенные главные вехи, большинство из которых применимо к любому типу IT проектов

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

Проектные требования разделяются на:

(1) требования соответствия

(2) эксплуатационные требования (operational requirements)

(3) системные требования, относящиеся к решению в целом (system requirements)

Основные задачи проектной группы на фазе внедрения, ролевого кластера тестирование

(1) управление внедрением; одобрение изменений

(2) тестирование производительности

(3) обучение; управление календарным графиком обучения

Программный продукт это:

(1) программа без руководства пользователя

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

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

Программный продукт это:

(1) программа без руководства пользователя

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

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

Структурная диаграмма UML содержит

(1) имя сущности, имена атрибутов сущности, ограничения и методы

(2) имя сущности, имена атрибутов сущности, ограничения и методы, связи между сущностями

(3) имя сущности и имена атрибутов

Microsoft Operations Framework MOF затрагивает вопросы, относящиеся к управлению

(1) простыми проектами

(2) сложными IT-системами

(3) распределенными IT-системами

(4) разнородными IT-системами

Основные характеристики дисциплины управления рисками в MSF:

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

(2) она вовлекает всю проектную группу в непрерывное извлечение уроков из полученного опыта

(3) она превентивна и не исходит из идеологии действия по факту случившегося

Основными задачами фазы выработки концепции являются

(1) оценить объем работ

(2) создание ядра проектной группы

(3) подготовка документа общего описания и рамок проекта

Основные задачи и сферы ответственности ролевого кластера управление программой во время фазы разработки -

(1) ожидания заказчика

(2) управление функциональной спецификацией; мониторинг проекта; доработка планов

Определению технологии соответствует:

(1) совокупность производственных процессов в определенной отрасли производства, а также научное описание способов производства

(2) наука изучающая технику

(3) качественный подход к принятию решения в сложной обстановке

Предметная область system engineering

(1) вопросы разработки систем с участием компьютеров

(2) наука изучающая технику

(3) теория и основы разработки ПО

Защищенные атрибуты обозначаются

(1) "#"

(2) "-"

(3) "+"

Microsoft Solutions Framework (MSF) это

(1) методология разработки программного обеспечения (ПО) от компании Microsoft

(2) описания технологий применяемых при создании ПО

(3) соглашения о процессе моделирования жизненного цикла ПО

Риск проекта (project risk) - это

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

(2) риск это не проблема

(3) риск это проблема

Основные задачи и сферы ответственности ролевого кластера разработка, во время фазы выбора концепции -

(1) цели дизайна; концепция решения; структура проекта

(2) прототипирование; анализ технологических возможностей; анализ осуществимости

(3) необходимые эксплуатационные характеристики решения и их влияние на его разработку

Основные задачи и сферы ответственности ролевого кластера тестирование во время фазы разработки -

(1) обучение; доработка плана обучения; тестирование удобства эксплуатации (usability testing); графический дизайн

(2) функциональное тестирование; выявление проблем; тестирование документации; доработка плана тестирования

(3) чеклисты развертывания (rollout checklists); доработка планов внедрения (включая пилотное внедрение); чеклисты подготовки к внедрению (site preparation checklists)

Определение структурного программирования:

(1) методология предложенная Э. Дейкстром

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

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

Почему ПО должно эффективно использовать ресурсы ПК

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

(2) для повышения надежности

(3) для повышения юзабилити

Объектно-ориентированное программирование - это

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

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

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

MSF for Agile Software Development - это

(1) строгий, документированный процесс, рассчитанный на большие команды и длительный процесс разработки

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

(3) это Extreme Programming

Выявление рисков (risk identification) -

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

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

(3) этап, предшествующий анализу рисков

Основные задачи и сферы ответственности ролевого управление выпуском, во время фазы выбора концепции -

(1) цели дизайна; концепция решения; структура проекта

(2) требования внедрения и их влияние на разработку решения; требования сопровождения

(3) необходимые эксплуатационные характеристики решения и их влияние на его разработку

Результаты фазы разработки

(1) исходный и исполнительный код приложений

(2) скрипты установки и конфигурирования

(3) окончательная функциональная спецификация

Причины неудачи IT-проектов:

(1) недостаток средств

(2) нехватка квалифицированных кадров

(3) нереалистичные временные рамки

(4) недостаток количества исполнителей

(5) размытые границы проекта

Формализация процесса создания ПО оправдана для коллектива

(1) более 20-ти человек

(2) 5-6-ти человек

(3) 2-3 человек

Диаграмма состояния -

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

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

(3) показывает потоки информации в системе

Концепции MSF при построении команды

(1) концентрация на нуждах заказчика

(2) стремление к самосовершенствованию

(3) строгая иерархичность

Календарное планирование рисков (risk scheduling) -

(1) составление календарного графика прошедших рисков

(2) составление календарного графика будущих рисков

(3) интегрирует планы в повседневный процесс управления проектом

Рамки (scope) -

(1) наложение на календарный график ограничений

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

(3) создаются на основе единого видения

Фаза стабилизации отвечает за

(1) наладку решения

(2) тестирование решения

(3) переподсчет бюджета проекта

Ромб в блок-схеме обозначает:

(1) проверку условия

(2) нехватку данных

(3) ожидание ввода данных пользователя

Принципы создания ПО:

(1) грамотное планирование

(2) анализ рисков, способов реагирования

(3) определения четких границ проекта

(4) мотивирование сотрудников

Диаграмма классов -

(1) показывает классы, их атрибуты и связи между классами

(2) показывает, как система раскладывается на крупные составные части и связи между этими частями

(3) показывает структуру системы в конкретный момент времени, объекты, их атрибуты...

Зона ответственности архитектуры проекта, в MSF 4.0 -

(1) проектирование и осуществление реализации

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

(3) качество решения с точки зрения заказчика

Извлечение уроков (risk learning) -

(1) предшествует этапу мониторинга

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

(3) следует за этапом мониторинга

Рамки проекта (project scope) определяют -

(1) тоже что и рамки (scope)

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

(3) определяют функциональность решения и его возможности

Результаты фазы стабилизации -

(1) материалы поддержки решения

(2) результаты и инструментарий тестирования

(3) исходный и исполнимый код приложения

Модульное программирование

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

(2) состоит в замене блок-схем, блок-модулями

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

Одно из ответвлений модели пошаговой разработки

(1) экстремальное программирование

(2) каскадная модель

(3) водопадная модель

Актер (actor) -

(1) человек

(2) управляющий функционал

(3) пользователь или машина или другая программа

Зона ответственности группы управления выпуском, в MSF 4.0 -

(1) проектирование и осуществление реализации

(2) понимание потребностей пользователей и их надлежащую реализацию в решении

(3) гладкое внедрение решения в инфраструктуру заказчика

Процесс MSF ориентирован на

(1) бизнес-отдаче (business value) решения

(2) понимание потребностей пользователей

(3) "вехи" (milestones) - ключевые точки проекта

Основные задачи и сферы ответственности ролевого кластера управление продуктом -

(1) концептуальный дизайн; анализ бизнес-требований; коммуникационный план

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

(3) оценка технологий; логический и физический дизайн; план и календарный график разработки; смета разработки (development estimates)

Основные задачи и сферы ответственности ролевого кластера управление программой, в модели MSF, во время фазы стабилизации

(1) мониторинг проекта; приоритезация ошибок

(2) исполнение коммуникационного плана; планирование премьеры продукта

(3) устранение ошибок; оптимизация программного кода

Основные принципы объектной модели:

(1) абстракция

(2) инкапсуляция

(3) иерархия

(4) модульность

(5) размножимость

(6) полиморфизм

Особенность модели пошаговой разработки -

(1) наиболее важные для заказчика компоненты разрабатываются в самом начале

(2) для шага можно использовать каскадную или эволюционную модель

(3) возможность "прыжков" через шаги

Комментарий в UML оформляется как

(1) надпись на сером фоне над связью

(2) символы после двух косых линий

(3) символы после символа "#"

Ролевая группа управление программой, в MSF 4.0, выполняет задачи:

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

(2) следит за временным графиком проекта и готовит отчетность о его состоянии

(3) определяет структуру развертывания (внедрения) решения

Треугольник компромиссов имеет свойство:

(1) при изменении одного из показателя, две другие требуют модификации для достижения баланса

(2) при изменении одного из показателя, две другие не требуют модификации

(3) изменение ни одного из показателей после установления значений запрещено концепцией модели MSF

Основные задачи и сферы ответственности ролевого кластера удовлетворение потребителя -

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

(3) оценка дизайна; требования тестирования; план и календарный график тестирования

Основные задачи и сферы ответственности ролевого кластера тестирование, в модели MSF, во время фазы стабилизации

(1) доработка эксплуатационных руководств; учебные материалыя

(2) развертывание и поддержка пилотного внедрения; планирование внедрения; обучение персонала сопровождения

(3) тестирование; сообщение об ошибках и их статусе; тестирование конфигурации

Отличие компонентного от объектно-ориентированного программирования:

(1) введен следующий уровень абстракции - классы объединяются в компоненты

(2) отменена иерархия

(3) поддерживается спиральная модель

Достоинства каскадной модели

(1) простота

(2) хорошая структурированность

(3) большая гибкость

Кардинальность 1..* говорит о том, что

(1) сущность может находится в связи с 1 или более сущностями

(2) требуется одна сущность, а допускается неограниченное количество

(3) данная сущность может быть представлена кардинальностью 1:N если существует сущность с кардинальностью 0..1 связанная с сущностью 1..*

Ролевая группа разработка, в MSF 4.0, выполняет задачи:

(1) обеспечивает обнаружение всех дефектов

(2) подготавливает продукт к внедрению

(3) консультирует команду по технологическим вопросам

Принципы модели процессов:

(1) уменьшайте количество "вех"

(2) создавайте "единое видение проекта"

(3) следите за качеством продукта

На вехе "Планы утверждены" проектная группа

(1) пьет кофе, т.к. свою работу она выполнила

(2) уточняет/корректирует оценки рисков

(3) оценивает требуемые ресурсы

Стандартом MSF, предусмотрены следующие промежуточные вехи в фазе стабилизации:

(1) "версии-кандидаты"

(2) "единое видение проекта"

(3) контрольное тестирование завершено

Модульность -

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

(2) ранжированная система абстракций

(3) процесс выделения абстракций в предметной области

Спиральная модель предполагает

(1) возможность использовать на каждом витке разные модели

(2) ранжированная система абстракций

(3) процесс выделения абстракций в предметной области

Зависимость

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

(2) выражают отношение одной сущности к другой

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

Ролевая группа управление выпуском, в MSF 4.0, выполняет задачи:

(1) организует внедрение продукта

(2) вырабатывает компромиссы в управляемости и удобстве сопровождения продукта

(3) представляет интересы потребителя в команде

Фраза "Зафиксировав объем функциональности решения, мы согласовываем затрачиваемые ресурсы и принимаем результирующие сроки", говорит о

(1) том, что функциональность наиболее приоритетна

(2) том, что сроки наименее приоритетны

(3) том, ресурсы наиболее приоритетны

Цели функциональной спецификации:

(1) проработанное планирование

(2) инструкции команде разработчиков о том, что они должны будут создать

(3) основа для оценивания объема работы

Во время фазы внедрения проектная группа

(1) внедряет и стабилизирует решение

(2) передает работы персоналу поддержки и сопровождения

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

Под классом в ООП подразумевается:

(1) особая переменная отвечающая за инициализацию

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

(3) набор именованных алгоритмов

Спецификация, как стадия процесса создания ПО:

(1) отметка об правильности и соответствии спецификациям

(2) то, что должна делать система

(3) создание ПО в соответствии со спецификациями

Кратность это

(1) возможность отношения

(2) способ конкретизации характера отношения. Показывает тип отношения 1:1, 1:M, N:1, N:M

(3) обособленный тип связи

Ролевая группа управление продуктом, в MSF 4.0, выполняет задачи:

(1) выступает в роли представителя заказчика

(2) организует работу с требованиями заказчика

(3) формирует ожидания заказчика

Фраза "Зафиксировав ресурсы, мы согласовываем функциональность решения и принимаем результирующие сроки", говорит о том, что

(1) наиболее изменяемы ресурсы

(2) влиять на ресурсы невозможно

(3) наиболее изменяем функционал

Промежуточная веха - базовая версия функциональной спецификации создана -

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

(2) рекомендуемая веха

(3) нерекомендуемая веха

Результаты фазы внедрения включают:

(1) окончательные версии всех проектных документов

(2) показатели удовлетворенности заказчика и потребителей

(3) описание последующих шагов

Полиморфизм бывает:

(1) сложный обособленный

(2) чистый

(3) перегрузка

(4) простой (переопределение)

Модернизация, как стадия процесса создания ПО:

(1) развитие, улучшение алгоритма, интерфейса

(2) развитие ПО в соответствии с изменившимися потребностями заказчика

(3) выпуск новой версии

(4) простой (переопределение)

Пакет это

(1) единица сущностей пакетного программирования

(2) структурная единица для группировки элементов модели, в частности, классов

(3) способ организации модели в более крупные блоки

Решение о сроках реализации принимает

(1) ролевая группа управление выпуском

(2) менеджер ролевой группы управление выпуском

(3) спонсор проекта

Типы "вехи"

(1) главные (major)

(2) конечные (finite)

(3) промежуточные (interim)

Промежуточная веха - базовая версия сводного календарного проекта создана -

(1) по достижении данной вехи готово календарное планирование каждого ролевого кластера

(2) не рекомендуется стандартом MSF

(3) помогает адекватно оценивать риски

Основные задачи проектной группы на фазе внедрения, ролевого кластера управление программой

(1) сопоставление рамок проекта с поставленным решением; управление стабилизацией

(2) разрешение проблем; поддержка эскалации

(3) получение отзывов и оценок заказчика; акт о приеме выполненной работы

Компонентное программирование

(1) менее ресурсоемкое, чем структурное

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

(3) более ресурсоемкое, чем структурное

Компонентное программирование относится к стадии

(1) спецификации

(2) реализации

(3) аттестации

Смысл иерархии в объектном подходе -

(1) повышает читабельность кода

(2) разбивает задачу на подзадачи, увеличивая постепенно детализацию рассмотрения

(3) позволяет более дальним от корня методам перекрывать методы родителя

MSF отстаивает необходимость выработки единого видения (shared vision) проекта, что подразумевает:

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

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

(3) каждый член ролевой группы руководствуется только теми данными которые выдаются ему по принципу "need to know"

Особенности "вех":

(1) промежуточные вехи определенные стандртом MSF нет возможности переопределять

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

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

Процесс проектирования начинается с

(1) с написания сценариев использования

(2) c написания рабочих сценариев

(3) с методичного анализа профилей пользователей

Основные задачи проектной группы на фазе внедрения, ролевого кластера управление выпуском

(1) обучение; управление календарным графиком обучения

(2) тестирование производительности

(3) управление внедрением; одобрение изменений

Программное обеспечение это:

(1) набор компьютерных программ, процедур и связанной с ними документации и данных (ISO/IEC 12207)

(2) программа на языке программирования Basic

(3) программа с пользовательским интерфейсом, и файлом справки

Программное обеспечение это:

(1) набор компьютерных программ, процедур и связанной с ними документации и данных (ISO/IEC 12207)

(2) программа на языке программирования Basic

(3) программа с пользовательским интерфейсом, и файлом справки

Объектно-ориентированный анализ - это

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

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

(3) анализ подготовленный по стандарту UML

Последняя версия Microsoft Solutions Framework (MSF) датируется

(1) 2005 г

(2) 2003 г

(3) 2002 г

Основные характеристики дисциплины управления рисками в MSF:

(1) она всеобъемлюща и принимает во внимание все составляющие проекта: людей, бизнес-процессы, технологические элементы и т.д.

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

(3) ее использование непрерывно на протяжении всего жизненного цикла проекта

Основные задачи и сферы ответственности ролевого кластера управление продуктом, во время фазы выбора концепции -

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

(2) цели дизайна; концепция решения; структура проекта

(3) прототипирование; анализ технологических возможностей; анализ осуществимости

Основные задачи и сферы ответственности ролевого кластера разработка во время фазы разработки -

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

(2) ожидания заказчика

(3) управление функциональной спецификацией; мониторинг проекта; доработка планов

Схема создания программной системы выглядит так:

(1) анализ→проектирование→разработка→тестирование→модификация

(2) анализ→проектирование→разработка→модификация→тестирование

(3) анализ→проектирование→тестирование→разработка→модификация

Предметная область software engineering:

(1) часть system engineering, имеющая дело с разработкой ПО

(2) теория и основы разработки ПО

(3) вопросы разработки систем с участием компьютеров

Закрытые атрибуты обозначаются

(1) "-"

(2) "#"

(3) "+"

Microsoft Solutions Framework (MSF) состоит

(1) из двух моделей

(2) из трех дисциплин

(3) из 5-ти "белых книг": 2-х моделей и 3-х дисциплин

Ключевые концепции дисциплины управления рисками MSF -

(1) риск - неотъемлемая часть всякого проекта или процесса

(2) выявление рисков нужно всячески одобрять

(3) оценка рисков должна вестись постоянно

(4) риск - это проблема требующая решения, во время возникновения

Основные задачи и сферы ответственности ролевого кластера удовлетворение потребителя, во время фазы выбора концепции -

(1) цели дизайна; концепция решения; структура проекта

(2) стратегии тестирования; критерии приемлемости, их влияние на разработку решения

(3) необходимые эксплуатационные характеристики решения и их влияние на его разработку

Основные задачи и сферы ответственности ролевого кластера управление выпуском во время фазы разработки -

(1) функциональное тестирование; выявление проблем; тестирование документации; доработка плана тестирования

(2) обучение; доработка плана обучения; тестирование удобства эксплуатации (usability testing); графический дизайн

Сколько входов в цикл возможно при написании блок схемы?

(1) два и более

(2) два

(3) один

Цели программных инженеров, это

(1) создать программу

(2) написать программу и документацию к ней

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

Диаграмма действия -

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

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

(3) показывает потоки информации в системе

MSF for CMMI Process Improvement - это

(1) процесс написания программных продуктов в сжатые сроки

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

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

Анализ рисков (risk analysis) -

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

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

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

В течение фазы MSF рекомендует выделить промежуточные вехи:

(1) ядро проектной группы сформировано

(2) рекомендуется оставить для этой фазы только главную веху

(3) черновой вариант концепции проекта составлен

Результаты фазы разработки

(1) материалы поддержки решения

(2) стабильная версия решения

(3) спецификации тестов

Центральный технологический принцип структурного программирования:

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

(2) рисование блок-схем программы на этапе проектирования

(3) применение алгоритмических языков программирования

Для каскадной модели верно:

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

(2) следующий этап может начаться когда угодно

(3) каждый этап может начинаться когда угодно

Диаграмма вариантов использования -

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

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

(3) показывает потоки информации в системе

Концепции MSF при построении команды

(1) нацеленность на конечный результат

(2) подчиненность членов команды выделенному менеджеру

(3) строго разграничение потоков информации

Мониторинг рисков (risk tracking) -

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

(2) этап, предшествующий анализу рисков

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

Рамки (scope) -

(1) вынесение менее важных задач на позднее время

(2) определение времени нужного на решение различных задач

(3) разграничение проекта по критериям различных ролевых кластеров

Прохождение вехи "Готовность решения утверждена", в модели MSF, целесообразно

(1) когда все известные проблемы разрешены

(2) когда проект получает статус "бета"

(3) когда проект получает статус "каппа"

Трапеция в блок-схеме обозначает:

(1) ввод/вывод пользовательских данных

(2) синоним прямоугольника

(3) синоним ромба

Каскадная модель приемлема

(1) для очень больших команд

(2) для малых и средних

(3) для малых групп разработчиков

Диаграмма развертывания -

(1) показывает, как ПО размещается на аппаратуре (серверах, рабочих станциях...)

(2) показывает компоненты и связи между ними

(3) показывает, как система раскладывается на крупные составные части и связи между этими частями

Зона ответственности разработки, в MSF 4.0 -

(1) отвечает за проектирование и осуществление реализации

(2) качественные показатели решения

(3) система в целом, выработка архитектуры

Этапы процесса управления рисками модели MSF

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

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

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

Рамки решения (solution scope) -

(1) определяют функциональность решения и его требуемые или желаемые аспекты

(2) тоже что и рамки (scope)

(3) тоже что и рамки решения (solution scope)

Результаты фазы стабилизации -

(1) анализ пройденной фазы

(2) Программный продукт в первом приближении, с функциональностью близкой к итоговой

(3) проектная документация

Применение модульного программирования позволяет:

(1) разработку программ как набора "независимых" частей

(2) последовательно уменьшать сложность, путем разбиения задачи на более простые

(3) использовать возможности повторного использования кода

Модель пошаговой разработки требует

(1) в итоге каждого шага - работающий прототип

(2) использовать для каждого шага каскадную модель

(3) использовать для каждого шага эволюционную модель

Вариант использования -

(1) одно из возможных решений

(2) модель того, как воздействие приводит к результату

(3) управляющий функционал

"Вехи" (milestones) -

(1) точка этапа каскадной модели

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

(3) конечная точка этапа - та точка возвращение к которой не требуется

Основные задачи и сферы ответственности ролевого кластера управление программой -

(1) концептуальный дизайн; анализ бизнес-требований; коммуникационный план

Основные задачи и сферы ответственности ролевого кластера разработка, в модели MSF, во время фазы стабилизации

(1) исполнение коммуникационного плана; планирование премьеры продукта

(2) устранение ошибок; оптимизация программного кода

(3) мониторинг проекта; приоритезация ошибок

Определение объектно-ориентированного программирования:

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

(2) технология программирования больших программных компонентов

(3) программирование сложных модулей

Итерационный подход включает

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

(2) каскадную модель

(3) водопадную модель

Закрашенный ромб в нотации UML говорит о

(1) том, что сущность к нему прилегающая - условная

(2) том, что сущность рядом с ромбом является родителем слабой сущности

(3) том, что сущность рядом с ромбом является виртуальной

Ролевая группа архитектура проекта, в MSF 4.0, выполняет задачи:

(1) формулирует спецификацию решения и разрабатывает его архитектуру

(2) определяет структуру развертывания (внедрения) решения

(3) определяет детали физического дизайна

Треугольник компромиссов - это

(1) взаимосвязь любых трех ключевых моментов выработанных в процессе работы над проектом

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

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

Основные задачи и сферы ответственности ролевого кластера тестирование -

(2) оценка дизайна; требования тестирования; план и календарный график тестирования

(3) оценка дизайна; эксплуатационные требования; план и календарный график пилотного и окончательного внедрения

Основные задачи и сферы ответственности ролевого кластера управление выпуском, в модели MSF, во время фазы стабилизации

(1) тестирование; сообщение об ошибках и их статусе; тестирование конфигурации

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

(3) развертывание и поддержка пилотного внедрения; планирование внедрения; обучение персонала сопровождения

Компонент это

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

(2) объединения классов

(3) абстрактное несуществующее понятие

Достоинства каскадной модели

(1) простота

(2) большая гибкость

(3) хорошая структурированность

Кардинальность N:M

(1) неявляется кординальностью вообще

(2) нет такой кардинальности

(3) может быть представлена связью 0..* с 0..*

Ролевая группа тестирования, в MSF 4.0, выполняет задачи:

(1) определяет детали физического дизайна

(2) разрабатывает или контролирует разработку элементов

(3) осуществляет тестирование

Принципы модели процессов:

(1) будьте готовы к внедрению сегодня

(2) будьте готовы к внедрению сегодня

(3) ставьте "вехи"

Результаты фазы выработки концепции:

(1) общее описание и рамки проекта (vision/scope document)

(2) документ оценки рисков (risk assessment document)

(3) функциональная спецификация

Иерархия -

(1) ранжированная система абстракций

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

(3) процесс выделения абстракций в предметной области

Процесс создания программного обеспечения -

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

(2) написание кода на каком-либо языке программирования

(3) процесс выделения абстракций в предметной области

Зависимость

(1) возникает через локальную, глобальную переменные или параметр метода

(2) это структурная связь

(3) реализуется через поле класса

Ролевая группа удовлетворение потребителя, в MSF 4.0, выполняет задачи:

(1) выступает в роли представителя заказчика

(2) организует работу с требованиями пользователя

(3) представляет интересы потребителя в команде

Фраза "Зафиксировав календарный график, мы согласовываем затраты ресурсов и принимаем результирующую функциональность решения", говорит о том, что

(1) ресурсы наиболее приоритетны

(2) наиболее приоритетно уложиться в календарный график

(3) наименее приоритетно работать над функциональностью

Цели функциональной спецификации:

(1) четкое соглашение с заказчиком о том, что должно быть сделано

(2) детальное планирование

(3) синхронизация работы всей проектной команды

Результаты фазы внедрения включают:

(1) базы знаний, отчеты, журналы протоколов (logbooks)

(2) информационные системы эксплуатации и поддержки

(3) процедуры и процессы

Объект это

(1) переменная типа класса

(2) противоположность субъекту

(3) сущность сущностей ООП

Разработка, как стадия процесса создания ПО:

(1) создание ПО в соответствии со спецификациями

(2) модернизация алгоритмов

(3) выработка алгоритмов

Агрегация это

(1) предположение о том, что 0 или более объектов включены в 1 и более объектов другого типа

(2) каждый объект второго типа может быть включен ровно в 1 объект первого типа

(3) соединение выборок

Ролевая группа управление продуктом, в MSF 4.0, выполняет задачи:

(1) формирует общее видение и рамки проекта

(2) организует маркетинг

(3) разрабатывает стратегию и планы тестирования

(4) организует внедрение продукта

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

Фраза "Зафиксировав сроки, мы согласовываем объем функциональности решения и принимаем результирующие затраты ресурсов", говорит о том, что

(1) в данном проекте менять сроки практически невозможно

(2) затраты ресурсов - это то, что варьируется в больших пределах

(3) затраты ресурсов строго фиксированы

Промежуточная веха - базовая версия сводного плана создана -

(1) создана совокупность планов различных ролевых кластеров

(2) рекомендуемая стандартом MSF веха

(3) не рекомендуемая стандартом MSF веха

Основные задачи проектной группы на фазе внедрения, ролевого кластера управление продуктом

(1) получение отзывов и оценок заказчика; акт о приеме выполненной работы

(2) сопоставление рамок проекта с поставленным решением; управление стабилизацией

(3) разрешение проблем; поддержка эскалации

В 60-х годах голландский ученый Дейкстра сформулировал основные положения

(1) структурного программирования

(2) логического программирования

(3) сущность ООП

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

(1) проходит от момента принятия решения о создании ПО, до выведения из эксплуатации ПО

(2) проходит от момента принятия решения о создании ПО, до внедрения конечному пользователю

(3) полностью описывается в 4-х стадиях: спецификация, разработка, аттестация, модернизация

Суть инкапсуляции в объектном подходе -

(1) скрытие деталей внутренней реализации

(2) вложенность меньшего в большее

(3) сложность при соединении большего с меньшим классом

Решение о объеме работ принимает

(1) заказчик

(2) ролевая группа разработка

(3) ролевая группа архитектура

Итеративными методами как правило создаются

(1) программный код

(2) документация

(3) дизайн

Проектные требования разделяются на:

(1) бизнес-требования (business requirements)

(2) требования соответствия

(3) потребительские требования (user requirements)

Основные задачи проектной группы на фазе внедрения, ролевого кластера удовлетворение потребителя

(1) управление внедрением; одобрение изменений

(2) тестирование производительности

(3) обучение; управление календарным графиком обучения

Объектно-ориентированная технология работает на стадиях

(1) анализа

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

(3) программирования

Объектное программирование относится к стадии

(1) аттестации

(2) разработки

(3) спецификации

Идея повторного использования состоит в

(1) уменьшении трудозатрат на уже решенную задачу

(2) применение в использование тех компонент которые уже используются

(3) упрощение ведения документации

Модель проектной группы MSF

(1) является ключевой для виртуальных команд

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

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

Особенности "вех":

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

(2) промежуточные вехи могут варьироваться от проекта к проекту

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

Профили пользователей -

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

(2) это описания различных типов пользователей (исключая персонал сопровождения) и их рабочие функции

(3) это файл по адресу: %SystemDrive%\Documents and Settings\%UserName%.%UserDomain%\NTUSER.DAT

Стандартом MSF, для фазы внедрения предусмотрены промежуточные вехи:

(1) внедрение на местах завершено

(2) ключевые компоненты развернуты

(3) внедренное решение стабилизировано