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

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

2. Фазы и этапы  разработки проекта.

3. Основа деятельности  менеджера 

программного проекта.

5. Проекция пользовательского понятие

"время жизни"  на на понятие разработчика

"технологический  цикл.

Последовательное  развитие проекта- это.

2. Развитие, при котором  каждый из

этапов жизненного цикла выполняется на

базе полностью  завершенного

предыдущего этапа.

3. Организация труда,  при которой 

создаваемый продукт  передается от

разработчика к  разработчику для

выполнения очередного этапа.

5. Методика, при которой  необходимость 

возврата к работам  пройденных этапов

рассматривается как ошибка  проектирования.

Объектно- ориентированная схема

итеративного  наращивания возможностей -

это.

1. Рабочие продукты  для пользователя 

создаются и предъявляются на каждой итерации.

2. Техническое описание  продукта 

строится как документ, дополняемый на каждой итерации.

3. Осуществляется  возвратно- поступательная разработка. 
 
 
 

Контрольные точки-это.

2. Этапы жизненного  цикла программного изделия.

4. моменты разработки, когда осуществляется подведение

промежуточных итогов.

5. Моменты взаимодействия с заказчиком.

За  счет чего любая методология  старается 

повысить  производительность процесса

разработки?

1. За счет эргономичности поставляемого инструментария.

3. За счет регламентов, предписаний и соглашений, которых должны

придерживаться разработчики.

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

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

1. Имеет традиционные этапы, как при последовательном развитии проекта.

2. Для пользователя создаются рабочие продукты, предъявляемые ему.

3. Техническое описание продукта строится как документ, дополняющий описание продукта на предыдущей итерации.

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

обеспечения.

2. Это основа знания  методологий программирования и  инструментария, поддерживающего их.

3. Это помогает  построить надежные ориентиры  для планирования проекта.

4. Это позволяет  отстаивать свою точку зрения  перед заказчиком.

Итеративное развитие проекта- это.

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

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

5. Альтернатива последовательному  развитию проекта.

Возвратно- поступательная разработка- это.

1. Итеративное развитие  проекта.

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

3. Альтернатива последовательному  выполнению проекта.

Состав документов этапа Рабочее проектирование (реализация системы).

1. Программа работ  по реализации Системы.

2. Описание программно- аппаратного обеспечения.

5. Программа и  методика приемочных испытаний.

Какие этапы входят в  программу работ по реализации системы?

3. Тестирование подсистем.

4. Интеграция подсистем.

5. Документирование  Системы.

Состав документов этапа внедрения Системы.

1. Программа работ по вводу Системы в действие.

2. Протоколы испытаний  и согласований.

5. Акты завершения работ и приемки системы

Ключевые  роли.

Априорное распределение кадровых ресурсов проекта- это.

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

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

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

обеспеченности проекта

Противодействующий  лидер- это.

1. Тот, кто своим  авторитетом заставляет команду  действовать деструктивно.

3. Лидер коллектива, который фактически препятствует  действиям менеджера проекта.

5. Противник общепринятых  мнений, к которому прислушиваются  в коллективе

Где можно подбирать кандидатов для выполнения проекта?

3. Менеджер может  принять сотрудника со стороны.  Надежность варианта 

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

4. Менеджер может  заранее знать возможных кандидатов.

5. Менеджер может  подбирать кандидатов из числа  сотрудников фирмы. Надежность 

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

Ключевые  роли коллектива разработчиков- это.

1. Роли в проекте,  от которых в наибольшей степени  зависти успех или неудача  в разработке.

2. Роли, определяющие  структуру развития проекта.

4. Роли, функции которых  наиболее значимы в проекте.

Наличие единственного лидера в группе, на которого может положиться менеджер

проекта- это.

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

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

5. Возможность конфликтов  с менеджером, связанных с утверждением  лидерства.

Чем может помочь в подборе кадров сотрудник, уже принятый на ключевую

роль?

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

3. Указанием в  качестве кандидатов конкретных  персон, известных ему.

4. Проведением экспертного  собеседования с целью определения  пригодности кандидатов для работы.

Ключевой  работник- это.

1. Тот, кто занимает  в проекте ключевую роль.

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

3. Незаменимый разработчик.

Какие ключевые роли характеризуют  наиболее типичные  ситуации начала

проектирования.

1. Архитектор проекта.

2. Пректировщик подсистем.

5. Эксперт предметной  области.

График привлечения сотрудников к проекту-это.

1. План, в котором  представлены перечень работ  с указанием их продолжительности.

2. Перечень кандидатов  для приема на работу с указанием  их условий.

3. План кадровой  потребности проекта. 
 

Качества лидера для получения им признания в команде.

2. Признание его  профессиональной компетентности.

4. Полное доверие  команды.

5. Признание его  человеческих качеств.

Какими  компетенциями должен обладать эффективный  лидер?

1. Видение целей  и стратегии их достижения.

2. Глубокий анализ  проблем и поиск новых возможностей.

5. Нацеленность на  успех

Какими  компетенциями должен обладать эффективный  лидер?

3. Искренность и  открытость в общении.

4. Навыки в разрешении  конфликтов.

5. Способность сочувствия, понимания состояния участников  команды

Признаки  поведения эффективного командного игрока.

1. Занимает активную  позицию.

3. Получает удовольствие  от своей работы.

5. Четко осознает  свои личные и общие цели.

Признаки  поведения, неприемлимые в команде.

1. Непорядочность, лживость, способность на низкие поступки.

2. Завышенная самооценка, подчеркивание собственного превосходства.

3. Анархизм, безответственность.

Стадии  сплочение команды  разработчиков

2. Начальное формирование  команды.

4. Разногласия и  конфликты.

5. Становление команды

Концептуальная  база проекта

Концептуальная  база проекта это.

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

2. Совокупность всех  соглашений, направляющая развитие  проекта.

4. Деятельность, назначение  которой- предписывать и регламентировать процесс выполнения

"глобальной" деятельности  проекта.

Почему  стратегии, которые  до начала проекта  невозможно развить, следует 

рассматривать в предпроектный период?

3. Это позволит  точнее определить ресурсные  потребности.

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

которые предстоит выполнить в процессе жизненного цикла.

5. Априорные стратегии  во всех отношениях более объективны чем случайные.

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

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

2. Этот метод пригоден  только в тех случаях, когда  до начала проекта собраны  и согласованы все требования  к программе.

4. Когда выявление  операций оказывается неоднозначным.

Общий план развития проекта  строится из.

2. Концепций развития  проекта, плана поставок и релизов.

3. Поэтапного плана  работ и планов по направлениям  развития проекта.

4. Плана поставок  и релизов.

Что включает в себя часть концепций развития проекта, которая называется

"Общие  принципы и положения"?

1. Соглашения, которые  зависят от проекта лишь косвенно.

3. Решения, принимаемые  для данного проекта, которые  слабо зависят от

постановки проектных  задач.

5. Соглашения, определяющие  профиль проекта.

Разделение принципов в концепции развития проекта дает следующие преимущества.

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

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

4. Документ, в котором  общее отделено от частного, допускает  более результативное 

изучение при оценке завершенного проекта.

Метафора  рабочей книги  проекта- это.

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

3. Представление  процесса разработки как аналога  составления полной проектной  документации.

4. Проект представвляется как большая рабочая книга, вводная часть которой представляет концептуальную базу проекта.

Что включает в себя часть  концепций развития проекта, которая  называется "Специальные  принципы и положения"?

1. Соглашения, которые  определяются спецификой проектного  задания.

3. Соглашения, обусловленные  требованиями заказчика.

4. Создание глоссария  проекта.

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

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

2. Для целенаправленного  изучения требований к программному  изделию в соответствии с пользовательскими  нуждами.

3. Для определения  предпочтений при принятии проектных  решений.

Менеджмент  в разработке ПО.

Менеджмент  программных проектов-это:

1. Деятельность, организующая  развитие программного проекта  во всех его аспектах.

3. Решение задач  распределения ресурсов и контроля  их использования.

4. Управление и  руководство в проекте.

Служба  менеджера проекта-это

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

от рутины постоянного  контроля.

2. помощники менеджера,  которым в проекте выделяются  сферы ответственности.

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

Источники, из которых появляются требования, направляющие развитие проекта.

2. Конкуренты.

3. Будущие пользователи  результатов выполнения проекта.

4. Заказчик и инвестор  проекта.

Менеджер  программного проекта- это.

1. Руководитель коллектива  разработчиков проекта.

2. Административное  лицо, ответственное за отслеживание  жизненного цикла развития проекта.

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

Делегирование полномочий- это.

1. Распределение  обязанностей между сотрудниками, участвующими в реализации проекта.

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

4. Назначение ответственного  за этап проекта.

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

1. Работы проекта  взаимосвязаны и разнородны.

2. Существует объективное  требование разделения труда  разработчиков.

3. Работы проекта  растянуты во времени.

Схемы организации менеджмента  программного проекта- это.

1. Образование группы  менеджера проекта.

3. Единоличное управление  работами по развитию программного  проекта.

4. Образование службы  менеджера проекта.

Группа  менеджера проекта- это.

1. Помощники менеджера  по различным видам работ в  проекте.

3. Структура из  работников проекта с выделением  сферы ответственности.

4. Лица, ответственные  за выполнение определенных видос работ в проекте.

Что определяет жизненный  цикл в процессе производства программного обеспечения.

1. Задачи, которые  необходимо выполнить.

2. Цели и регламент  выполнения этого процесса.

3. Этапы данного  процесса.

Отличительные особенности профессионального  программирования.

2. Деятельность, направленная  на получение доходов при помощи  программирования.

4. Наличие как  минимум двух участников разработки- программиста и потребителя (заказчика).

5. Это коллективный  труд.

Основные  области знаний, на которых базируется разработка ПО.

1. Требования к ПО.

3. Конструирование  ПО.

5. Тестирование.

Основные  области знаний, на которых базируется разработка ПО.

1. Эксплуатация ПО.

2. Управление в  программной инженерии.

3. Качество ПО. 
 

Методологические  стратегии.

Конус операционных маршрутов  проектной деятельности- это.

1. Множество всех  состояний деятельности, связанных  друг с другом переходами, которые  являются элементами операционных  маршрутов.

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

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

Какая методология может  оказаться жесткой?

1. Когда она строится  без учета того, что программные  проекты объективно непредсказуемы.

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

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

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

2. Деятельность, имеющая  приказной характер методов.

3. Связка методов  и целей, которой подчинены  заданные средства и инструменты.

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

Принцип выяснения отклонений и быстрой корректировки- это концепция управленческой деятельности, согласно которой менеджер во время выполнения проекта должен.

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

2. Отслеживать выход  траектории из области допустимых  маршрутов и своевременно воздействовать  на нее для возвращения в  эту область.

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

Укажите высказывания, которые  разграничивают жесткие  и быстрые методологические стратегии.

1. Ориентация на  предсказуемые или на непредсказуемые  разработки программного обеспечения.

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

4. Заказчик в ходе  разработки выполняет только  контрольные функции или участвует  в выборе пути развития проекта. 
 

Как можно пытаться ликвидировать  недетерминизм деятельности?

3. За счет внешних  воздействий, ликвидирующих двусмысленности.

4. За счет пересмотра  целей деятельности.

5. Недетерминизм  деятельности ликвидировать невозможно.

Автокоррекция- это.

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

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

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

Технология  деятельности- это.

2. Использование  средств и инструментов для  поддержки методов.

3. Гарантия повторения  процесса выполнения деятельности.

4. Требование надлежащего  уровня квалификации исполнителя.

Agile Manifesto- это документ, который фиксирует.

2. Положения, характеризующие  стратегию  быстрого развития.

3. Основные принципы  стратегии быстрого развития .

4. Противопоставление  жестких и гибких методов.

Какие документы разрабатываются  на этапе Технического проектирования (разработка Системного проекта)?

1. Списки вопросов  для бизнес- обследования предприятий Заказчика.

3. Протоколы интервьюирования  экспертов на предприятиях Заказчика.

4. Внутрифирменная  проектная документация.

Источник  разработки бизнес- диаграмм.

3. Протоколы интервьюирования  экспертов на предприятиях Заказчика.

4. Материалы, представленные  Заказчиком.

5. Техническая литература 
 
 
 
 

Модели  жизненного цикла  в реальных методологиях

Обеспечивает  ли RUP унифицируемость любых рационально устроенных программных проектов?

1. Нет, так как  это в принципе невозможно.

4. Нет, так как  предлагаемый в RUP комплект средств  не объединен системой деятельностей.

5. RUP фактически поддерживает  только иллюстративную модель  ведения.

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

1. Поддерживают, так  как это поможет построить  объединенную методологию быстрого  развития.

3. Поддерживают, так  как это будт способствоать престижу данного направления.

4. Индифферентно,  так как этот вопрос решается  на уровне конкретной компании.

Какие методологические приемы используются менеджером для организации  проектной деятельности при экстремальном  программировании?

1. Определение этапов  проекта.

3. Определение отклонений  траектории проектной деятельности  и корректировка.

4. Распределение  ресурсов и ответственности.

Модель  жизненного цикла RUP задается в виде.

1. Последовательности  итераций, для которых задано  разбиение процесса на этапы.

2. Схемы переходов  от итерации к итерации.

3. Матрицы интенсивностей  функций, выполняемых на этапах.

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

1. Начальная фаза  и серия коротких итераций.

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

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

Адаптивная  разработка по Хайчмиту- это.

2. Принципиальнаяя методологическая основа разработок в условиях непредсказуемости развития проекта.

3. Проект, менеджер  которого не делает никаких  предположений о будущем развитии.

4. Проект, который  адаптируется к меняющимся требованиям. 
 
 

Операционные  маршруты в RUP определены для.

3. Предлагаемых инструментов.

4. В описании процесса- для шаблонных действий разработчиков в распознаваемых

ситуаций.

5. Для того, чтобы при применении RUP можно было пользоваться предлагаемыми инструментами в распознаваемых ситуациях.