Итеративное развитие проекта — это:
Текущее наблюдение за ходом развития проекта — это …
Реализация как этап в общепринятой модели — это:
Каким элементом деятельности по разработке методики для другой деятельности является эта вторая, методически поддерживаемая деятельность?
Изменение требований в процессе разработки считается ошибкой. Так ли это?
Что описывает календарный план?
Составляющие рисков — это …
Функция называется технологической, если:
Что включает в себя часть Концепций развития проекта, которая называется «Специальные принципы и положения»?
Что означает многофункциональность требований?
Из каких этапов состоит формирование методов и методик, исходящее из опыта принятия оптимальных решений?
Что определяет жизненный цикл в процессе производства программного обеспечения:
Область возможного совмещения работ — это такие ситуации, когда:
Для хранения истории следует предусмотреть специальную организацию хранения требований, проектных связей, рабочих продуктов, в первую очередь обеспечивающую:
Критерии отбора сценариев для реализации — это:
Утверждение, что требования всегда уникальны, означает, что:
Концепции развития проекта как самостоятельный документ полезны …
Когда применяется прием использования метафор?
Процесс выполнения проекта представляется как целенаправленная динамическая система деятельностей, реализующих производственные функции исполнителями, которая развивается во времени. Что в этом определении означают целенаправленность и динамичность?
Что включает в себя определение системы?
Обслуживание по Гантеру — это:
Технология деятельности — это способ организации процесса ее выполнения, гарантирующий получение субъектом из необходимого ресурса результата, соответствующего цели деятельности, в требуемом объеме за известное время и с приемлемым уровнем качества, если:
Внешняя оценка результатов проектной деятельности характеризуется:
Как можно пытаться ликвидировать недетерминизм деятельности?
Особенности модели жизненного цикла, предложенной Гантером:
Какой результат достигается при осознанном применении метафор?
Расщепление линии жизненного цикла с приостановкой основного процесса — это:
Ключевые роли коллектива разработчиков — это:
Для чего нужно рассматривать группу рабочих продуктов, которые отражают наблюдение за проектом?
Автокоррекция — это:
Менеджер программного проекта — это:
Делегирование полномочий — это:
Источники, из которых появляются требования, регламентирующие и направляющие развитие проекта:
Поручения, выполняемые разработчиком проекта, — это:
Ролевой кластер модели MSF — это:
Не следует допускать совмещения ролей, которые имеют конфликтные или противоречивые интересы. Что делать, если такое совмещение все-таки приходится использовать?
Какие ключевые роли характеризуют наиболее типичные проектные ситуации?
График привлечения сотрудников к проекту — это:
Ресурсы деятельности — это:
Преподаватель использует при обучении иллюстрации, схемы. Какими элементами его деятельности они являются?
Когда методология может оказаться жесткой?
Детерминизм, который предписывается для технологичной деятельности, — это:
Жизненный цикл программного изделия — это:
За счет чего любая из методологий старается повысить производительность процесса разработки?
Объектно-ориентированная схема итеративного наращивания возможностей характеризуется тем, что:
Идентификация потребности в новом приложении — это:
Какими способами преодолевается недостаток классической итерационной модели, связанный с возвратами на предыдущие шаги?
Расщепление линии жизненного цикла — это:
Объектно-ориентированное проектирование отличается от традиционных подходов тем, что:
Что означает критерий демонстрационной значимости:
Расщепление линии жизненного цикла при итеративном наращивании приводит к:
Почему CASE-системы обычно не поддерживают инструментальность моделей жизненного цикла?
Основой спиральной модели Боэма является следующее:
Операционные маршруты в RUP определены для:
Как сторонники методологий быстрого развития относятся к сертификации компаний, в которых процесс производства программного обеспечения основывается на этих методологиях?
Какие методические стратегии и приемы используются менеджером для организации проектной деятельности при экстремальном программировании?
Как классифицируются требования с точки зрения их непрерывного поступления в ходе развития проекта?
Трассировка требований — это:
Укажите возможные варианты результата анализа требований.
Прием «понимание пользовательских потребностей» нужен для:
Что означает точность метафоры?
История изменения требований используется для:
Метафора Рабочей книги проекта — это …
Что включает в себя часть Концепций развития проекта, которая называется «Общие принципы и положения»?
Разделение принципов в Концепциях развития проекта дает следующие преимущества:
Верно ли утверждение, что большая доля новаций в проекте приводит к повышенным рискам?
План управления качеством — это:
Из каких предпосылок исходит план любого итеративно развивающегося проекта?
Что понимается под результативностью программистской проектной деятельности?
Для чего нужно рассматривать группу рабочих продуктов, которые отражают процесс развития проекта?
Какие варианты работы с требованиями нужно отразить в модели жизненного цикла для учета непрерывности поступления требований в проект?
Где можно подбирать кадры для выполнения проекта?
Укажите высказывания, которые не разграничивают жесткие и быстрые методологические стратегии:
Что означает метафора продвижения организации по лестнице зрелости?
Что означает критерий системной значимости:
Когда метод построения WBS сталкивается с непреодолимыми препятствиями?
Априорное распределение кадровых ресурсов проекта — это:
Из каких предпосылок исходит план последовательно развивающегося проекта?
Что такое интенсивность выполнения функции в модели Гантера:
Отдельная итерация при итеративном наращивании возможностей характеризуется тем, что:
Принцип выяснения отклонений и быстрой корректировки — это концепция управленческой деятельности, согласно которой менеджер во все время выполнения проекта должен:
Группа менеджеров проект- — это:
Какая задача решается при управлении областью применимости системы?
Необходимость понятия жизненного цикла разработки связана с тем, что:
Определение целей, альтернативных вариантов и ограничений — это:
Что такое уточненная первичная модель?
Модель жизненного цикла RUP задается в виде…
Причины необходимости моделированияжизненного цикла программного обеспечения:
Задача менеджера в части отслеживания связей — это:
Внешние функции менеджера — это:
Последовательное развитие проекта — это:
Как метафоричность способствует достижению функциональной полноты и замкнутости предлагаемых средств?
Фактическое начало работ над проектом характеризуется тем, что:
Верно ли утверждение, что последовательный проект является более рискованным, чем итеративный?
Разбиение производственной функции — это:
Допускается ли корректировка планов последовательного проекта, когда выясняется, что какой-либо из этапов не укладывается в сроки и ресурсы?
Внутренние функции менеджера — это:
Ключевой работник — это:
Наличие единственного лидера в группе, на которого может положиться менеджер проекта, это:
Чем может помочь в подборе кадров сотрудник, уже принятый на ключевую роль?
Agile Manifesto — это документ, который фиксирует:
Возвратно-поступательная разработка — это:
Общепринятая модель жизненного цикла состоит из следующих этапов:
Подтверждение в каскадной модели — это:
Фазовое измерение модели фазы — функции — это:
Планирование по Гантеру — это:
Действительное расщепление линии жизненного цикла — это:
Виды параллелизма выполнения проекта, которые выражаются в развитых моделях жизненного цикла:
Адаптивная разработка по Хайсмиту — это:
Что фиксируют требования в организации проектных работ?
Трансформация требований для трассировки — это:
Что такое многомерность требований?
Что такое модель уровня конструирования?
Общий план развития проекта строится из …
Почему стратегии, которые до начала проекта невозможно точно развить до уровня планов и задач, следует рассматривать в предпроектный период?
В чем суть плана управления рисками?
Внешние связи проекта — это:
Первоочередная работа по составлению планов проекта — это …
Внутренняя оценка результатов проектной деятельности характеризуется:
В чем состоит специфика автоматизации производства программного обеспечения?
Служба менеджера проекта — это:
В чем состоит анализ проблем?
Каким элементом (элементами) деятельности по обучению некоторой методике другой деятельности является субъект этой деятельности?
Что должен сочетать в себе правильный и хорошо сбалансированный контроль хода проектных работ со стороны менеджера?
Какие ролевые кластеры предусматривает модель проектной группы MSF:
Пополнение базового окружения проекта — это:
Характерные черты каскадной модели:
Выберите наиболее точную формулировку конуса операционных маршрутов проектной деятельности:
Какие проблемы могут возникнуть при непродуманном распространении решений по цепочке «опыт, метод, методика»?
Модель жизненного цикла является инструментальной, если:
Субъект деятельности — это:
Говорить об извлечении требований нужно, потому что:
Управление рисками — это…
Менеджмент программных проектов — это:
Характеристическое свойство рабочего продукта — это …
Допускается ли корректировка планов итеративно развиваемого проекта, когда выясняется, что очередная итерация не укладывается в сроки и ресурсы?
Что такое первичная модель?
RUP провозглашается унифицированной основой организации и ведения любых рационально устроенных программных проектов. Так ли это?
Контрольные точки — это:
Определение требований — это:
Ограничение на совмещение выполнения итераций связано с:
Задачи начальной фазы методологии экстремального программирования:
Какие фазы и этапы можно указать в жизненном цикле при любой методологии быстрого развития?
Основой адаптивной разработки по Хайсмиту является:
Проектирование как этап в общепринятой модели — это:
Главные менеджерские обязанности в проекте в контрольной точке«Спецификации реализуемых сценариев составлены» — это:
Требования часто являются взаимосвязанными, взаимозависимыми и противоречивыми, потому что:
Унифицированное представление требований — это:
Какие действия не рассматриваются как этапы обработки требований?
Концептуальная база программного проекта — это…
Ближайшая задача проекта — это:
Схемы организации менеджмента программного проекта — это:
Противодействующий лидер — это:
Оценка альтернативных вариантов, идентификация и разрешение рисков — это:
Какие требования предъявляются ко всем программным разработкам?
Верно ли утверждение, что низкая квалификация работников проекта всегда приводит к повышению риска для проекта?
Цель деятельности — это:
Функция, выполняемая разработчиком проекта, — это:
Как соотносятся друг с другом производственные функции и система деятельностей программного проекта?
Различия между критерием и ограничением с точки зрения задачи отбора сценариев для реализации состоят в том, что:
Функциональное измерение модели фазы — функции — это:
Проектная группа модели Microsoft Solution Framework —это:
Автор: Игорь Скопин | Новосибирский Государственный Университет
Форма обучения:
дистанционная
Стоимость самостоятельного обучения:
бесплатно
Качество курса:
4.01 | 3.23
Обсуждаются понятия и методы менеджмента в объеме, необходимом для общего образования программиста.
Вводится система понятий менеджмента программных проектов, достаточная для того, чтобы обучаемый смог самостоятельно осваивать существующие методы и технологии проектирования для их применения в практической деятельности. Изложение строится в привязке деятельности менеджера к этапам жизненного цикла проекта. Особое внимание обращается на разграничение аспектов руководства и управления в деятельности менеджера.
ISBN: 978-5-9556-0013-0
Теги: анализ, библиотеки, инициатор работ, итеративное наращивание, каскадная модель, методики, моделирование, моделирование жизненного цикла, модель уровня анализа, отладка, поддержка, программирование, программное обеспечение, проектная деятельность, производственная функция, рабочий продукт, разработка, руководитель команды, спецификации, теория, тестирование, экстремальное программирование, элементы
Функциональные роли в коллективе разработчиков
Определяются функции, выполняемые сотрудниками в ходе развития проекта и типичные для программных проектов роли разработчиков; указывается, какие роли могут совмещаться при выполнении проекта. Представлены решения обсуждаемых вопросов, предлагаемые компанией Microsoft и Центром объектно-ориентированных технологий IBM.
—
Ключевые роли коллектива разработчиков и задача определения кадровых ресурсов проекта
Рассматриваются вопросы кадровой политики менеджера программных проектов и задача формирования коллектива разработчиков. Обсуждается влияние лидирующей группы и лидера коллектива на эти задачи: положительные и отрицательные моменты такого влияния. Описываются ситуации, в которых приходится действовать при подборе кадров. Приводится схема решения задачи определения кадровых ресурсов проекта.
—
Принципы построения системы деятельностей программного проекта
Обсуждаются понятия теории деятельности, полезные для изучения менеджмента разработки программных изделий. На этой базе определяется место менеджмента в системе деятельностей программного проекта и задача соблюдения баланса между временем выполнения, объемом работ и расходом ресурсов при соблюдении требований к качеству.
—
Методологические стратегии
Возможные варианты развития проекта разработки программного обеспечения представляются как множество операционных маршрутов, среди которых выделена область допустимых траекторий. Управление рассматривается как деятельность, препятствующая выходу траектории из области допустимости. В рамках этих соглашений описываются стратегии управления, принятые в существующих методологиях. С позиций стратегических концепций обсуждаются жесткие и гибкие методологии.
—
Жизненный цикл программного изделия и его модели
Изучаются понятие модели жизненного цикла и подходы к их построению. Рассматриваются работы, которые выполняются при прохождении этапов жизненного цикла. Вводится понятие декомпозиции проекта. Сопоставляются схемы последовательного развития проекта и развития проекта с итеративным наращиванием возможностей.
—
Модели традиционного представления о жизненном цикле
Изучаются базовые модели жизненного цикла и работы, которые выполняются при прохождении его этапов. Последовательность рассматриваемых моделей выстроена в соответствии с ростом их адекватности реальным схемам развития проектов. Выстраивается основная линия моделирования жизненного цикла при последовательном развитии проекта.
—
Производственные функции в моделировании жизненного цикла: модель фазы—функции
Мотивируется необходимость отражения в моделях жизненного цикла
производственных функций, выполняемых разработчиками. Эти функции
должны связываться с контрольными элементами управления проектами, т.е.
этапами жизненного цикла, но тем не менее они выполняются в течение всего
периода развития проекта с разной интенсивностью. Описывается модель
Гантера фазы—функции как основа построения развитых схем жизненного
цикла, включающая отражение организационных и технических производственных
функций. Показывается, как в модели фазы—функции можно учитывать
итеративность (в традиционном понимании).
—
Моделирование
объектно-ориентированного жизненного
цикла программных проектов
Моделирование жизненного цикла при итеративном наращивании и, в частности, при объектно-ориентированном подходе к разработке проектов имеет свои особенности. Они обусловлены принципами разработки и дополнительными функциями. Тем не менее развитые модели традиционных подходов, допускающие учет итеративности, вполне можно модернизировать, приспосабливая их к новым условиям. Ниже описывается такая модернизация для модели Гантера фазы-функции.
—
Технологические аспекты развития программных систем в моделях жизненного цикла
Обсуждается возможность отражения в моделях жизненного цикла свойств процесса разработки программного обеспечения, способствующих поддержке эффективности производства. С этой точки зрения рассматривается осуществимость параллельного выполнения итераций и проводится разграничение между иллюстративными и инструментальными моделями. Рассматривается возможность инструментального применения ряда общеупотребительных моделей.
—
Модели жизненного цикла в некоторых реальных методологиях программирования
Рассматриваются модели жизненного цикла, принятые в методологиях, которые претендуют на реальную поддержку деятельности разработчиков программных проектов. Разграничивается инструментальная поддержка, которая может быть полезной для различных методологий, и комплексные средства методологического обеспечения деятельностей исполнителей проекта.
—
Проблемы оперирования требованиями
Обсуждаются проблемы проектной деятельности, связанные с необходимостью оперирования требованиями к программному изделию, которые определяют направление развития любого проекта. Делается вывод о необходимости специальных методических приемов для работы с требованиями. Приводится схема трассировки требований, отслеживание которой целесообразно при любой организации менеджмента для поддержания целостности системы требований, реализуемых в программной системе.
—
Принципы и приемы оперирования требованиями
Описывается способ учета трассировки требований в модели жизненного цикла и специальные приемы, предназначенные для оперирования требованиями. Для каждого из приемов указывается, когда целесообразно его применение и какие результаты при этом достигаются.
—
Принципы и приемы оперирования требованиями (продолжение)
В продолжение темы предыдущей лекции рассматриваются специальные приемы оперирования требованиями. Представленные приемы следует применять в течение всего развития проектов на этапах, когда закладываются реализуемые в очередном релизе возможности. Кроме того, обсуждается регламент организации работ с требованиями в проекте, связанный с установлением конструктивных деловых отношений с инициаторами работ.
—
Концептуальная база проекта как основа его развития
Вводится понятие концептуальной базы проекта, которая
формируется при развитии любого проекта. Показано, что стихийное
формирование концептуальной базы практически всегда приводит к неудаче.
Обсуждается соотношение концептуальной базы и планирования, а также то,
какие материалы обязательно должны быть представлены в концептуальной базе.
—
Концептуальная база проекта: управление рисками и качеством, отслеживание связей
Три составляющие концептуальной базы проекта, которые
рассматриваются ниже, используются в проектной деятельности, чтобы
обеспечивать устойчивость траектории развития. Стихийное их
формирование практически всегда негативно сказывается на сроках
и результатах. В качестве итога обсуждения концептуальной базы
приводится идеальная цель менеджерской работы в предпроектный
период: сведение к минимуму необходимости вмешательства в конкретные
дела исполнителей.
—
Планирование и контроль развития проекта. Цикл управления проектом
Задачи планирования и контроля развития проекта рассматриваются в качестве основы производства программной продукции. Они важны при любой методологии, но каждая из них понимает планирование и контроль по-своему. В данной лекции изучаются наиболее общие понятия, связанные с обсуждаемыми процессами, и показано, как они преломляются при следовании различным методологическим стратегиям. Планирование, наблюдение за ходом выполнения работ, их контроль и корректировка принятых решений рассматриваются как процессы, которые объединяются общим понятием цикла управления проектом.
—
Результативность программистской проектной деятельности
Для характеристики результатов проекта с точки зрения их применения вне проектной деятельности вводится понятие результативности, которая рассматривается как показатель, определяемый деятельностями, использующими продукты проекта. С этой точки зрения приводится классификация рабочих продуктов проекта, которая соотносится с уровнями зрелости организаций, занимающихся разработкой программного обеспечения. Указывается на необходимость определения границ применимости методов и методик при распространении опыта. Обсуждается соотношение между технологичным производством и автоматизированной инструментальной поддержкой методологий.
—
Главная / Программирование /
Основы менеджмента программных проектов / Тест 1
Упражнение 1:
Номер 1
Менеджмент программных проектов — это:
Ответ:
(1) отслеживание жизненного цикла развития проекта
(2) деятельность, организующая развитие программного проекта во всех его аспектах
(3) решение задач распределения ресурсов и контроля их расходования
(4) отслеживание этапов проекта
Номер 2
Менеджер программного проекта — это:
Ответ:
(1) организатор работ по развитию программного проекта и ответственный за его выполнение
(2) тот, кто заказывает разработку проекта
(3) сотрудник компании, распределяющий ресурсы для проекта
Номер 3
Схемы организации менеджмента программного проекта — это:
Ответ:
(1) образование группы менеджера проекта
(2) определение лиц, отслеживающих жизненный цикл развития проекта
(3) единоличное управление работами по развитию программного проекта
(4) образование службы менеджера проекта
Упражнение 2:
Номер 1
Служба менеджера проекта — это:
Ответ:
(1) помощники менеджера, которым в проекте выделяются сферы ответственности
(2) организационные структуры, которые создаются для помощи в выполнении задач менеджмента
(3) помощники менеджера, которым в той или иной части проекта делегируются полномочия менеджера
Номер 2
Делегирование полномочий — это:
Ответ:
(1) распределение обязанностей между сотрудниками, участвующими в реализации проекта
(2) инструмент разделения труда, когда для работника определяется ответственность за выполнение некоторых функций, работ и др.
(3) поручение работнику выполнить то или иное задание
Номер 3
Группа менеджеров проект- — это:
Ответ:
(1) помощники менеджера по различным видам работ в проекте
(2) структура, создаваемая из работников для помощи в выполнении задач менеджмента, без выделения этим работникам сферы ответственности в проекте
(3) структура, создаваемая из работников для помощи выполнения задач менеджмента, с выделением этим работникам сферы ответственности в проекте
Упражнение 3:
Номер 1
Источники, из которых появляются требования, регламентирующие и направляющие развитие проекта:
Ответ:
(1) будущие пользователи результатов выполнения проекта
(2) заказчик и инвестор проекта
(3) программисты
(4) конкуренты
(5) подрядчики
Номер 2
Необходимость понятия жизненного цикла разработки связана с тем, что:
Ответ:
(1) работы проекта взаимозависимы и разнородны
(2) существует объективное требование разделения труда разработчиков
(3) работы проекта растянуты во времени
(4) планируемые результаты выполнения проекта появляются по мере его развития
Номер 3
Что определяет жизненный цикл в процессе производства программного обеспечения:
Ответ:
(1) задачи, которые необходимо выполнить
(2) цели и регламент выполнения этого процесса
(3) обязанности разработчиков в привязке к этапам производства
(4) распределение времени на выполнение работ
Ответы на курс: Основы менеджмента программных проектов
Группа менеджеров проект- — это:
Схемы организации менеджмента программного проекта — это:
Менеджер программного проекта — это:
Служба менеджера проекта — это:
Необходимость понятия жизненного цикла разработки
связана с тем, что:
Функция называется технологической, если:
Какие ролевые кластеры предусматривает модель проектной группы MSF:
Не следует допускать совмещения ролей, которые имеют конфликтные или противоречивые интересы. Что делать,
если такое совмещение все-таки приходится использовать?
Внутренние функции менеджера — это:
Чем может помочь в подборе кадров сотрудник, уже принятый на ключевую роль?
График привлечения сотрудников к проекту — это:
Противодействующий лидер — это:
Наличие единственного лидера в группе, на которого может положиться менеджер проекта, это:
Ключевой работник — это:
Цель деятельности — это:
Субъект деятельности — это:
Ресурсы деятельности — это:
Каким элементом (элементами) деятельности по обучению некоторой методике другой деятельности является субъект этой деятельности?
Принцип выяснения отклонений и быстрой корректировки — это концепция управленческой деятельности, согласно которой менеджер во все время выполнения проекта должен:
Когда методология может оказаться жесткой?
Детерминизм, который предписывается для технологичной деятельности, — это:
Agile Manifesto — это документ, который фиксирует:
Выберите наиболее точную формулировку конуса операционных маршрутов проектной деятельности:
Последовательное развитие проекта — это:
Итеративное развитие проекта — это:
За счет чего любая из методологий старается повысить производительность процесса разработки?
Жизненный цикл программного изделия — это:
Возвратно-поступательная разработка — это:
Контрольные точки — это:
Проектирование как этап в общепринятой модели — это:
Какими способами преодолевается недостаток классической итерационной модели, связанный с возвратами на предыдущие
шаги?
Определение требований — это:
Подтверждение в каскадной модели — это:
Функциональное измерение модели фазы — функции — это:
Фазовое измерение модели фазы — функции — это:
Обслуживание по Гантеру — это:
Расщепление линии жизненного цикла — это:
Критерии отбора сценариев для реализации — это:
Что означает критерий системной значимости:
Ближайшая задача проекта — это:
Различия между критерием и ограничением с точки зрения задачи отбора сценариев для реализации состоят в том, что:
Пополнение базового окружения проекта — это:
Ограничение на совмещение выполнения итераций связано с:
Модель жизненного цикла является инструментальной, если:
Оценка альтернативных вариантов, идентификация и разрешение рисков — это:
Область возможного совмещения работ — это такие ситуации, когда:
Виды параллелизма выполнения проекта, которые выражаются в развитых моделях жизненного цикла:
Модель жизненного цикла RUP задается в виде…
Какие фазы и этапы можно указать в жизненном цикле при любой методологии быстрого развития?
Задачи начальной фазы методологии экстремального программирования:
Как сторонники методологий быстрого развития относятся к сертификации компаний, в которых процесс производства программного обеспечения основывается на этих методологиях?
RUP провозглашается унифицированной основой организации и ведения любых рационально устроенных программных проектов. Так ли это?
Какие методические стратегии и приемы используются менеджером
для организации проектной деятельности при экстремальном программировании?
Изменение требований в процессе разработки считается ошибкой. Так ли это?
Говорить об извлечении требований нужно, потому что:
Утверждение, что требования всегда уникальны, означает, что:
Требования часто являются взаимосвязанными, взаимозависимыми и противоречивыми, потому что:
Трассировка требований — это:
Что означает многофункциональность требований?
Прием «понимание пользовательских потребностей» нужен для:
Какие варианты работы с требованиями нужно отразить в модели жизненного цикла для учета непрерывности поступления требований в проект?
Какая задача решается при управлении областью применимости системы?
Что такое модель уровня конструирования?
История изменения требований используется для:
Как метафоричность способствует достижению функциональной полноты и замкнутости предлагаемых средств?
Что такое первичная модель?
Для хранения истории следует предусмотреть специальную организацию хранения требований, проектных связей, рабочих продуктов, в первую очередь обеспечивающую:
Когда применяется прием использования метафор?
Метафора Рабочей книги проекта — это …
Что включает в себя часть Концепций развития проекта, которая называется «Специальные принципы и положения»?
Почему стратегии, которые до начала проекта невозможно точно развить до уровня планов и задач, следует рассматривать в предпроектный период?
Когда метод построения WBS сталкивается с непреодолимыми препятствиями?
Разделение принципов в Концепциях развития проекта дает следующие преимущества:
В чем суть плана управления рисками?
Верно ли утверждение, что последовательный проект является более рискованным, чем итеративный?
Управление рисками — это…
Составляющие рисков — это …
Верно ли утверждение, что большая доля новаций в проекте приводит к повышенным рискам?
Верно ли утверждение, что низкая квалификация работников проекта всегда приводит к повышению риска для проекта?
План управления качеством — это:
Из каких предпосылок исходит план последовательно развивающегося проекта?
Внутренняя оценка результатов проектной деятельности характеризуется:
Внешняя оценка результатов проектной деятельности характеризуется:
Первоочередная работа по составлению планов проекта — это …
Допускается ли корректировка планов итеративно развиваемого проекта, когда выясняется, что очередная итерация не укладывается в сроки и ресурсы?
Какие требования предъявляются ко всем программным разработкам?
В чем состоит специфика автоматизации производства программного обеспечения?
Что понимается под результативностью программистской проектной деятельности?
Из каких этапов состоит формирование методов и методик, исходящее из опыта принятия оптимальных решений?
Характеристическое свойство рабочего продукта — это …
Для чего нужно рассматривать группу рабочих продуктов, которые отражают наблюдение за проектом?
Что определяет жизненный цикл в процессе производства программного обеспечения:
Поручения, выполняемые разработчиком проекта, — это:
Преподаватель использует при обучении иллюстрации, схемы. Какими элементами его деятельности они являются?
Отдельная итерация при итеративном наращивании возможностей характеризуется тем, что:
Фактическое начало работ над проектом характеризуется тем, что:
Действительное расщепление линии жизненного цикла — это:
Главные менеджерские обязанности в проекте в контрольной точке
«Спецификации реализуемых сценариев составлены» — это:
Основой спиральной модели Боэма является следующее:
Определение целей, альтернативных вариантов и ограничений — это:
Основой адаптивной разработки по Хайсмиту является:
Какие действия не рассматриваются как этапы обработки требований?
Концепции развития проекта как самостоятельный документ полезны …
Укажите возможные варианты результата анализа требований.
Концептуальная база программного проекта — это…
Реализация как этап в общепринятой модели — это:
Необходимость понятия жизненного цикла разработки
связана с тем, что:
- (Правильный ответ) работы проекта растянуты во времени
- (Правильный ответ) работы проекта взаимозависимы и разнородны
- планируемые результаты выполнения проекта появляются по мере его развития
- (Правильный ответ) существует объективное требование разделения труда разработчиков
Противодействующий лидер — это:
- достаточно авторитетный критик решений менеджера проекта
- противник общепринятых мнений, к которому прислушиваются в коллективе
- (Правильный ответ) лидер коллектива, который фактически препятствует действиям менеджера проекта
- член коллектива, успешно оппонирующий принимаемым решениям
Наличие единственного лидера в группе, на которого может положиться менеджер проекта, это:
- возможность переложить на одного из сотрудников часть менеджерских обязанностей по управлению проектом
- (Правильный ответ) одна из главных предпосылок формирования продуктивно работающего коллектива
- недостаток кадрового обеспечения проекта, поскольку реально требуется несколько ответственных персон
- (Правильный ответ) возможность переложить на одного из сотрудников часть менеджерских обязанностей по руководству коллективом разработчиков
Ресурсы деятельности — это:
- (Правильный ответ) материалы, оборудование, информация и иные объекты, рассматриваемые как элементы деятельности, перерабатываемые в результат
- (Правильный ответ) материалы, оборудование, информация и иные объекты, которые используются субъектом при его активности в качестве исполнителя деятельности
- материалы, оборудование, информация и иные объекты, без которых выполнение деятельности невозможно
Детерминизм, который предписывается для технологичной деятельности, — это:
- деятельность, для выполнения которой не требуется высокая квалификация исполнителей
- (Правильный ответ) возможность полной автоматизации для всех распознаваемых ситуаций
- производственные функции не имеют отношения к системе деятельностей проекта
- (Правильный ответ) связка методов и целей, которой подчинены заданные средства и инструменты
Agile Manifesto — это документ, который фиксирует:
- соглашения между сторонниками стратегии быстрого развития, которым они обязуются следовать при выполнении программных проектов
- (Правильный ответ) положения, характеризующие стратегию быстрого развития проектов в методологиях, принятые ее сторонниками в противовес жестким методологиям
- необходимые и достаточные условия, чтобы методологию можно было считать гибкой
Выберите наиболее точную формулировку конуса операционных маршрутов проектной деятельности:
- наглядное представление траекторий процесса развития проекта, в котором центр конуса соответствует замыслу, а основание — множеству всех вариантов завершения проекта, соответствующих его целям
- (Правильный ответ) наглядное представление траекторий процесса развития проекта, в котором центр конуса соответствует замыслу, основание — множеству всех вариантов завершения проекта, а на основании выделена целевая область с завершениями, соответствующими целям
- множество всех состояний деятельности, связанных друг с другом переходами, которые являются элементами операционных маршрутов
Жизненный цикл программного изделия — это:
- фазы и этапы разработки проекта
- (Правильный ответ) проекция пользовательского понятия «время жизни» на понятие разработчика «технологический цикл» (цикл разработки)
- (Правильный ответ) окончательные и промежуточные цели, фазы и этапы разработки, проекта, а также эксплуатации программного изделия и его ликвидации
- время существования программного изделия от стадии замысла до прекращения эксплуатации
- (Правильный ответ) основа деятельности менеджера программного проекта: окончательные и промежуточные цели проекта, распределение и контроль расходования ресурсов, все остальные аспекты управления развитием проекта
Контрольные точки — это:
- моменты взаимодействия с заказчиком, в которые он принимает результаты проектирования
- этапы жизненного цикла программного изделия
- (Правильный ответ) моменты разработки, когда осуществляется подведение промежуточных итогов, осмысление достигнутого и проверка сделанных ранее предположений
- моменты передачи в эксплуатацию версий и релизов программного изделия
- (Правильный ответ) окончания этапов жизненного цикла программного изделия
Определение требований — это:
- определение того, какие функции нужны пользователю
- (Правильный ответ) описание общего контекста задачи, ожидаемых функций системы и ее ограничений
- действия менеджера проекта, связанные с выяснением того, какая разработка нужна пользователю
- действия заказчика, связанные с выяснением потребности в разработке
- описание ограничений на применимость разрабатываемого приложения
Подтверждение в каскадной модели — это:
- (Правильный ответ) выяснение корректности результатов работы с помощью апелляции к экспертам, внешним по отношению к коллективу разработчиков
- то же, что тестирование
- то же, что аттестация
- то же, что верификация
- подготовка и утверждение заказчиком документа, удостоверяющего корректность результатов этапа
Различия между критерием и ограничением с точки зрения задачи отбора сценариев для реализации состоят в том, что:
- это по сути одно и то же
- (Правильный ответ) критерии служат для упорядочивания сценариев по степени предпочтения для выбора, тогда как ограничения задают условия, нарушение которых запрещает выбор
- критерии фиксируют показатели актуальности, полноты, системной и демонстрационной значимости, а также скорости разработки, тогда как ограничения задают все остальные параметры
- критерии упорядочивают сценарии по степени важности для проекта, а ограничения указывают на изменяемые показатели
Задачи начальной фазы методологии экстремального программирования:
- исследование предметной области, разработка архитектуры и подготовка к первой итерации
- создание условий для выполнения проекта в рамках методологии экстремального программирования
- построение единой концепции проекта
- (Правильный ответ) изучение инструментов, эксперименты для выбора глобальных решений, освоение методик
- (Правильный ответ) построение и внедрение первого релиза программной системы
Говорить об извлечении требований нужно, потому что:
- (Правильный ответ) инициаторы работ говорят не о требованиях к программе, а о проблемах деятельности, которую предполагается автоматизировать
- получая противоречащие предложения, разработчики должны выявлять непротиворечивые требования
- (Правильный ответ) они предъявляются разработчикам для анализа в неформализованном виде
- инициаторы работ совсем не обязательно формулируют требования явно
Трассировка требований — это:
- отслеживание выполнения требований на каждом этапе развития проекта (итерации)
- изучение влияния того или иного требования на реализационные решения на каждом этапе развития проекта (итерации)
- (Правильный ответ) прослеживание прохождения исходного требования через серию трансформаций от одного представления к другому, сопровождающееся соответствующим анализом
Прием «понимание пользовательских потребностей» нужен для:
- определения требований, реализуемых в рамках ближайшей задачи проекта
- определения требований, реализуемых в рамках ближайшей и перспективных задач проекта
- упорядочивания требований по степени актуальности для реализации
- (Правильный ответ) построения системы типов требований для данного проекта
- выяснения средств программной системы, которые необходимы пользователям
Какие варианты работы с требованиями нужно отразить в модели жизненного цикла для учета непрерывности поступления требований в проект?
- (Правильный ответ) требование или группа требований поступают, когда работы итерации начались
- (Правильный ответ) требование или группа требований поступают, когда работы итерации завершились, и релиз системы передан в эксплуатацию
- специально отражать в модели эту ситуацию не нужно
- требование или группа требований обрабатываются до начала работ над проектом
- (Правильный ответ) требование или группа требований обрабатываются до начала работ итерации
Какая задача решается при управлении областью применимости системы?
- ранжирование инициаторов работ с точки зрения предоставления ими требований, наиболее важных для реализации системы
- ранжирование требований к программной системе по степени актуальности для реализации с точки зрения инициаторов работ
- (Правильный ответ) выбрать приоритетное с точки зрения инициаторов работ направление развития проекта в условиях имеющихся на данный момент ресурсов (время, кадры, финансы)
- составление формализованных описаний требований к программной системе, пригодных для передачи разработчикам
Что включает в себя часть Концепций развития проекта, которая называется «Специальные принципы и положения»?
- набор требований к проекту, известных на момент начала его выполнения и принятый для реализации
- соглашения, обусловленные требованиями заказчика, предписывающими то, как должен развиваться проект
- решения, принимаемые в ходе развития проекта, которые непосредственно зависят от предметной области
- (Правильный ответ) соглашения, которые определяются спецификой проектного задания: предметная область разработки, характер использования результатов проектирования и т.п.
- соглашения между заказчиком и разработчиками о том, какие работы должны быть выполнены, чтобы обеспечить автоматизацию пользовательской деятельности
Верно ли утверждение, что последовательный проект является более рискованным, чем итеративный?
- (Правильный ответ) это зависит от другого
- скорее нет, чем да
- да
- скорее да, чем нет
- нет
Составляющие рисков — это …
- причины риска, неопределенные события или обстоятельства, последствия риска и влияние разработчиков на риск
- причины риска, неопределенные события или обстоятельства, последствия риска и влияние разработчиков на причины риска и на его последствия
- первичные риски и риски, возникающие в связи с произошедшими первичными рисками
- рисковые ситуации и влияние разработчиков на них и их последствия
- (Правильный ответ) причины риска, которые вызывают неопределенность, неопределенные события или обстоятельства, которые могут привести к негативному, нейтральному или позитивному воздействию на траекторию проектной деятельности и последствия риска, т.е. незапланированные отклонения траектории выполнения проекта от области допустимости
Внутренняя оценка результатов проектной деятельности характеризуется:
- тем, что она отражает отношение к проектной деятельности потребителей продукции и других инициаторов работ, непосредственно не связанных с производством рабочих продуктов
- тем, что она отражает конкурентоспособность разрабатываемого программного изделия на рынке
- (Правильный ответ) направленностью на улучшение качества процесса производства, роста квалификации сотрудников и других подобных параметров
- направленностью на улучшение качества процессов планирования и контроля развития проектной деятельности
Внешняя оценка результатов проектной деятельности характеризуется:
- тем, что она отражает достоверность прогнозов о качестве снабжения ресурсами и надежности финансирования
- направленностью на улучшение качества субподрядных работ
- (Правильный ответ) тем, что она отражает отношение к проектной деятельности потребителей продукции и других инициаторов работ, непосредственно не связанных с производством рабочих продуктов
- направленностью на улучшение качества процесса производства, роста квалификации исполнителей и других подобных параметров
Допускается ли корректировка планов итеративно развиваемого проекта, когда выясняется, что очередная итерация не укладывается в сроки и ресурсы?
- это невозможно, т.к. при корректном проведении анализа требований для итерации и квалифицированном ее планировании развитие работ итерации является детерминированным
- это возможно только как превентивная мера до начала итерации, что интерпретируется как устранение ошибки плана
- нет, это рассматривается как возникновение риска, для которого должен быть предусмотрен отклик, корректирующий ситуацию в пределах планового задания
- (Правильный ответ) это возможно и используется постоянно как превентивная мера до начала итерации, что интерпретируется как адаптация плана к уточненным условиям
- это нормальное явление, которое интерпретируется как необходимость настройки плана в связи с изменением обстоятельств
Из каких этапов состоит формирование методов и методик, исходящее из опыта принятия оптимальных решений?
- (Правильный ответ) разработка решения в конкретном проекте, анализ и обобщение этого опыта и превращение его в метод, неоднократное применение метода, анализ и обобщение такого применения до уровня методики
- анализ успешного проекта с целью выявления позитивного опыта, распространения его на новые ситуации, представления опыта в виде метода, а совокупности методов — в виде методики
- поиск в реальных проектах похожих решений и оформление полученных результатов в виде не зависящего от проекта метода, соединение непротиворечивых методов в методику
- разработка регламентов и соглашений и формулировка их в виде методики, состоящей из некоторого числа методов, применение методов в реальных проектах, их обобщение и настройка методики на область применения
- поиск хорошо себя зарекомендовавших методик, которые наиболее соответствуют задачам текущего проекта, осмысление опыта их применения, формирование метода, включение его в систему методов новой методики
Преподаватель использует при обучении иллюстрации, схемы. Какими элементами его деятельности они являются?
- ресурсом
- методом
- целью
- результатом
- (Правильный ответ) средством или инструментом
Действительное расщепление линии жизненного цикла — это:
- переход к точке продолжения с запоминанием текущего состояния с целью восстановления его после отработки продолжения для возобновления работ
- (Правильный ответ) такое расщепление, при котором основной процесс развивается в соответствии со своей линией, а переход к точке продолжения рассматривается как организация дополнительного процесса, вкладывающегося в жизненный цикл
- то же, что расщепление линии жизненного цикла с приостановкой основного процесса
Главные менеджерские обязанности в проекте в контрольной точке
«Спецификации реализуемых сценариев составлены» — это:
- распределение работ в коллективе для реализации выбранных сценариев
- распределение финансов с целью выделения их для реализации каждого из выбранных сценариев
- подбор кадров для выполнения реализации выбранных сценариев
- инвентаризация ресурсов и выяснение, хватает ли ресурсов для реализации выбранных сценариев
- (Правильный ответ) оформление подготовленных к реализации сценариев для их утверждения
Основой спиральной модели Боэма является следующее:
- (Правильный ответ) выделение квадрантов плоскости, каждый из которых отвечает за определенный круг проектных работ
- (Правильный ответ) привлечение заказчика к процедуре выбора перспектив развития проекта
- (Правильный ответ) прототипирование как способ решения проблем и выбора вариантов для минимизации рисков
- (Правильный ответ) анализ рисков как способ выявления проблем проекта, требующих решения на основе прототипирования
- распределение ресурсов проекта
Концепции развития проекта как самостоятельный документ полезны …
- для принятия или отклонения требований к проекту со стороны внешних инициаторов работ проекта
- (Правильный ответ) в ходе выполнения проектных работ для того, чтобы избежать недопонимания и бесполезных обсуждений того, как проект должен развиваться
- (Правильный ответ) для целенаправленного изучения требований к программному изделию и приведения проекта и его результатов в соответствие с реальными пользовательскими нуждами
- для распределения проектных работ между исполнителями с учетом их профессиональной ориентации и склонностей
Укажите возможные варианты результата анализа требований.
- (Правильный ответ) требование принимается к реализации на текущей итерации
- (Правильный ответ) требование откладывается до одной из следующих итераций
- (Правильный ответ) требование отклоняется
- требование замораживается до следующего проекта
- требование условно принимается к реализации на текущей итерации
Что включает в себя часть Концепций развития проекта, которая называется «Общие принципы и положения»?
- (Правильный ответ) соглашения, которые зависят от проекта лишь косвенно и определяют возможные для применения стратегии, варианты, а не конкретные решения
- основные требования к разрабатываемой системе, которые ни при каких обстоятельствах нельзя нарушать, т.к. это приведет к невозможности организации разработки системы
- решения, принимаемые для данного проекта, которые не зависят от постановки проектных задач
- основные требования к разрабатываемой системе, которые ни при каких обстоятельствах нельзя нарушать, т.к. это приведет к невозможности поддержки деятельности пользователей разрабатываемой системы
- наиболее широкое представление нужд предметной области, автоматизация которых должна быть обеспечена с помощью разрабатываемой системы
Проектная группа модели Microsoft Solution Framework —это:
- мобильный производственный коллектив, создаваемый для выполнения проекта
- производственный коллектив с установленной иерархией подчинения
- (Правильный ответ) мобильный коллектив с общей ответственностью за выполняемые задания
- производственный коллектив со строгим разделением функций
Функция, выполняемая разработчиком проекта, — это:
- задание, поручаемое для выполнения
- действия, предписанные для выполнения должностной инструкцией разработчика
- любые целенаправленные действия разработчика
- (Правильный ответ) действия, предписанные для выполнения ролью разработчика в проекте
Внешние функции менеджера — это:
- те функции, которые выполняет менеджер вне данного проекта
- взаимодействие менеджера с разработчиками, которое не затрагивает интересы развития проекта
- (Правильный ответ) те функции, которые связаны с взаимодействием менеджера с заказчиком, планировщиком и с другими инициаторами работ
- работа менеджера, которая направлена на руководство коллективом в проекте
Текущее наблюдение за ходом развития проекта — это …
- ежедневный отчет сотрудников о проделанной работе и затраченных ресурсах
- (Правильный ответ) сбор и анализ данных о результатах и ходе проектной деятельности, которые осуществляются постоянно и без отвлечения ресурсов от решения поставленных перед сотрудниками задач
- ежедневный опрос сотрудников о ходе развития проекта
- ежедневное оповещение менеджера о текущих проблемах, возникающих у сотрудников, и подходах к их решению
- ежедневные собрания сотрудников с целью выяснения текущего состояния развития проекта
Менеджмент программных проектов — это:
- отслеживание этапов проекта
- решение задач распределения ресурсов и контроля их расходования
- (Правильный ответ) деятельность, организующая развитие программного проекта во всех его аспектах
- отслеживание жизненного цикла развития проекта
Источники, из которых появляются требования,
регламентирующие и направляющие развитие проекта:
- (Правильный ответ) заказчик и инвестор проекта
- конкуренты
- подрядчики
- (Правильный ответ) будущие пользователи результатов выполнения проекта
- (Правильный ответ) программисты
Расщепление линии жизненного цикла при итеративном наращивании приводит к:
- приостановке выполнения текущей итерации и организации работ над новой итерацией с целью реализации дополнительной функциональности версии системы
- (Правильный ответ) появлению и одновременному существованию двух версий системы: одна из них начинает использоваться, а вторая создается в виде набора требований
- разбиению проектной команды на две части, чтобы выполнять работы, связанные с построенной версией, и работы, обусловленные новой итерацией
- приостановке выполнения текущей итерации и организации работ над новой итерацией с целью исправления обнаруженных ошибок в версии системы
- появлению работоспособной версии системы, функциональные возможности которой наращиваются путем реализации дополнительного набора требований
Предложите, как улучшить StudyLib
(Для жалоб на нарушения авторских прав, используйте
другую форму
)
Ваш е-мэйл
Заполните, если хотите получить ответ
Оцените наш проект
1
2
3
4
5
Лекция
1. Менеджмент в разработке программных
изделий
Вводятся основные понятия проблематики
менеджмента разработки программных
изделий, определяется метод и направление
курса в целом.
Ключевые
слова: разработка
программного обеспечения, менеджмент,
менеджер проекта, служба менеджера,
группа менеджера, делегирование
полномочий, делегирование, абстрактное
действующее лицо проекта, управление
проектом, руководство в проекте, рыночный
программный продукт, заказная разработка,
распространение программного
продукта, переиспользование,
пользовательские требования,
системные требования, участники
разработки проекта, этапы
разработки проекта, функции, выполняемые
разработчиками, роли
разработчиков, ресурсы разработки,
распределение ресурсов, жизненный цикл
программного обеспечения, направления
деятельности
менеджера.
Разработка
программного обеспечения в большинстве
случаев должна
рассматриваться как коллективный труд
специалистов, направленный на
удовлетворение потребности пользователей
в автоматизации их деятельности.
Как и любой другой коллективный труд,
она требует организации,
в частности — управления. Это процесс,
порою длительный, связывающий
производственными и иными отношениями
тех, кого в той или иной
степени можно рассматривать в качестве
производителей программы.
Как и любой труд, тесно связанный с
неоднозначными потребностями
тех, кто будет использовать продукты
труда, необходимым элементом разработки
программ является решение задач изучения
пользователей, с одной стороны, а с
другой — обеспечения обратной связи с
ними, направляющей
производство. Это составляющие, из
которых формируются главные
задачи управления производством
программ. Чаще всего решение
таких задач осуществляется руководителем,
или, как принято говорить,
менеджером проекта.
Понятие
«менеджер проекта» не обязательно
соотносится с конкретной
персоной, отвечающей за управление
производством программной системы
в целом. В небольшом проекте такое
единоначалие чаще всего оправданно:
оно позволяет концентрировать все нити
управления, исключает проблемы
внутреннего для проекта согласования
противоречий,
обеспечивает централизованную
ответственность за проект
перед теми, кто заинтересован в его
выполнении. Однако по мере
перехода к более масштабным проектам
менеджерские обязанности
становится
невозможно концентрировать в одних
руках. Обычно в таких
случаях поступают в соответствии с
одной из двумя схемами организации
производства. Первая схема — это
образование службы
менеджера,
состоящей
из его помощников, которым он может
поручать различные
задания, освобождая себя от рутины
постоянного контроля. Этот
путь, по существу, является лишь
паллиативом. Для еще более сложных
проектов появляется необходимость
следовать второй схеме, т.е.
образовывать группу
менеджеров, ответственных
за разные разграниченные
сферы проекта. В этой схеме централизация
достигается путем
назначения главного менеджера проекта,
который делегирует
полномочия
менеджерам
по направлениям.
Рис.
1.1 иллюстрирует три схемы организации
менеджмента проекта. Здесь
стрелки обозначают связи участников
реализации проекта, обусловленные
их взаимодействием с менеджером, жирность
контура значков отражает
менеджерские обязанности сотрудников.
Как видно из рисунка, в схеме
со службой менеджера помощники по своему
статусу являются обычными
работниками, тогда как при делегировании
полномочий менеджеры
по направлениям получают соответствующие
полномочия в своих
сферах ответственности (обозначены
пунктирными овалами).
Делегирование
можно считать основным инструментом
разделения труда
в проекте (не только в случае менеджмента),
когда есть ответственность
за некоторую функцию (работу и др.), но
для ее выполнения нет собственных
ресурсов, а потому приходится прибегать
к помощи. Собственно
говоря, различие схем работы менеджера
связано с использованием
механизмов поручений или делегирования.
В
коллективах, выполняющих программные
проекты, возможны самые разнообразные
организационные структуры. Так, для
сложных, объемных
по трудозатратам проектов иерархические
цепочки «менеджер — менеджер по
направлению — исполнитель работ»
целесообразно увеличивать,
дифференцируя работы и сферы ответственности
для некоторых менеджеров
по направлению.
Иногда
оправданно делегирование всех менеджерских
обязанностей и
полномочий менеджерам по направлениям.
В результате ответственность
за проект несет не один человек, она
распределяется по менеджерской
группе, т.е. возникает коллективная,
деперсонифицированная
ответственность.
Возможны
схемы, когда вместо менеджеров по
направлениям деперсонифицированная
ответственность назначается группе в
целом, т.е. менеджер
проекта выдает задания, контролирует
их выполнение, осуществляет другие
функции, обращаясь ко всей группе, внутри
которой уже распределяются
обязанности, в том числе и обязанности
менеджера по направлению.
Характерный пример — модель проектной
группы, предлагаемая
в концепции Microsoft
Solution
Framework
(MSF)
[44].
Для
небольших групп возможна следующая
организация работ: обязанности
главного менеджера распределяются по
команде разработчиков, которая
за счет внутренних механизмов решает,
как планировать работы, как
их распределять и контролировать. Это
характерно для так называемого
подхода быстрой
разработки (agile
development)
программных систем,
объединившего в себе несколько методологий
программирования, которые
отказываются от многих принципов
традиционного менеджмента [24]. Наиболее
ярким примером подхода быстрой разработки
является экстремальное программирование
[3]. Ему и другим методам данного
направления мы уделим внимание в
дальнейшем, а пока лишь отметим, что
здесь, как и в других случаях, менеджерские
задачи не исчезают, как могло
бы показаться на первый взгляд. Просто
форма и методы их решения
приобретают другой
характер.
По ряду причин
может оказаться целесообразным сочетание
схем организации менеджмента проекта.
В результате появляются, например,
коллективы, в которых главный менеджер
берет на себя функции менеджера
определенного направления, тем самым
он отвечает и за весь проект в целом, и
за некоторую его часть.
Все
варианты организации менеджмента
перечислить невозможно. Иногда
они возникают стихийно, иногда планируются
под определенную методологию
производства программ. Бывает и так,
что организация менеджмента и
методология выбираются исходя из
исторически сложившейся структуры
коллектива. И ничего предосудительного
в этом нет.
С
точки зрения изучения задач менеджмента
полезно представить их в
функциональном стиле, т.е. абстрагируясь,
когда это возможно, как от масштабов
проектов, так и от организационной
структуры коллектива исполнителей.
Для этого мы связываем такие задачи с
деятельностью абстрактной персоны,
которая в конкретных случаях прибегает
к распределению своих работ по схемам
с поручениями или с делегированием
полномочий.
Конкретизироваться эта персона может
по-разному: как единоличный
начальник, как начальник с менеджерской
группой, как распределенная
между исполнителями роль в проекте и
т.д. Как следствие,
проблема разделения работ оказывается
изолированной, допускающей отдельное
рассмотрение вариантов решения.
Прием
определения абстрактного менеджера
следует считать методическим. В
дальнейшем изложении он называется
определением абстрактного
действующего лица проекта и
применяется к изучению задач, связанных
с выполнением проекта, без привязки их
деятельности к конкретным персоналиям
или групповым ролям.
В
работе менеджера всегда присутствуют
и неразрывно связаны друг с другом два
аспекта: управление
проектом как
деятельность, продвигающая
процесс производства к определенным
целям, и руководство
людь ми, участниками
разработки. Для первого из этих аспектов
можно указать
методические приемы и иногда даже
организационные технологии, обеспечивающие
получение приемлемых результатов в
заданное и вполне
оцениваемое время. Но что касается
руководства людьми, то оно всегда
было и остается в значительной степени
искусством. Тем не менее важно подчеркнуть,
что управление проектом ведется через
персоналии его
участников, через работу с ними и их
взаимодействие между собой, а потому
игнорировать аспект руководства для
любого проекта ни в коем случае нельзя.
Ставя задачу изучения менеджмента,
приходится обсуждать как управление,
так и руководство. Эта двойственность
характерна для
любого менеджмента, но для менеджмента
программных проектов она
играет решающую роль, поскольку данная
отрасль направлена на получение
не материальных, а идеальных «мыслительных»
продуктов, так называемых
артефактов.
С
организационной точки зрения в разработке
программного обеспечения можно
выделить три варианта целей, определяющие
деятельность менеджера. Во-первых,
это производство программ не для
продажи,
напрямую не связанное с получением
дохода. Во-вторых, это производство
рыночного продукта, обеспечивающего
прибыль за счет распространения
(продажи) получаемых результатов.
В-третьих, разработка ведется
под заказ, когда все производство
программы, от стадии замысла до передачи
в эксплуатацию, финансируется внешними
по отношению к разработчикам, но весьма
заинтересованными агентами, обычно
называемыми
заказчиками.
Варианты
существенно различаются и по уровню
ответственности разработки, и по
требованиям к качеству продукции, и по
другим параметрам,
которые необходимо отслеживать. Однако,
если отвлечься от персоналий
и абстрагироваться от различий ресурсов,
необходимых для реализации программ
в каждом из этих случаев, то в менеджменте
производства программ
можно найти много общего, того, что в
любом случае должен или не
должен делать руководитель проекта. По
этой причине полезно считать заказными
любые разработки программ, быть может,
доопределяя «заказчика» как фактический
общий регламент производственного
процесса, выделяя
в руководстве аспекты деятельности,
внешним образом организующие
проект, с одной стороны, а с другой —
направляющие производство в соответствии
с конкретными обстоятельствами развития
проекта.
Главная
и постоянная задача менеджмента
разработки программного
обеспечения — продвижение проекта к
обозначенным в начале его развития
результатам. Если оставить в стороне
приемы и методы, с помощью
которых достигается решение этой задачи,
то она сводится к распределению
и контролю эффективного использования
имеющихся ресурсов проекта: времени,
финансов, технических средств и
производственного потенциала работников.
Множественность критериев, необходимость
согласования интересов участников
проекта и его заказчиков, разнообразие
видов деятельности, составляющих
развитие проекта, — вот
тот организационный и производственный
контекст, который вынужден
учитывать менеджер.
На
фоне получения программного продукта
как результата появляется
ряд дополнительных задач, за решение
которых должен отвечать менеджер
проекта. Здесь уместно отметить два
дополнительных направления
развития.
Характерной
особенностью разработки программного
обеспечения является стремление к
переиспользованию ранее созданных
программных
компонентов. Задачи переиспользования
— это, во-первых, определение
программных продуктов или каких-либо
иных изделий и инструментов,
имеющихся в распоряжении разработчиков,
использование которых
могло бы способствовать прогрессу
развития проекта, а во-вторых, выявление
компонентов данного проекта, которые
было бы полезно задействовать
в других разработках.
Второе
дополнительное направление — это задача
распространения построенного
программного продукта. Если с самого
начала не рассматривать ее и относить
распространение лишь к этапам, следующим
за разработкой, есть опасность сделать
не то, что нужно потребителю продукции,
и выпустить из рук рычаги, с помощью
которых можно влиять на сферу возможного
применения создаваемых программных
продуктов.
Получение
программного продукта как результата
развития проекта
— это процесс, который регламентируется
и направляется пользовательскими
потребностями, возможностями применяемого
оборудования и
другими условиями, как внешними по
отношению к проекту, так и внутренними.
Все эти аспекты принято рассматривать
как требования
к проекту. Изучению
понятия требований и методов работы с
ними в свое время
будет уделено особое внимание, а пока
отметим общепризнанное деление
требований на два класса: пользовательские
и системные требования.
Вот
как эти два класса требований определяет
И. Соммервилл [23]:
-
Пользовательские
требования —
описание на естественном языке
(плюс
поясняющие диаграммы) функций, выполняемых
систе
мой,
и ограничений, накладываемых на нее. -
Системные
требования —
детализированное описание системных
функций
и ограничений, которое иногда называют
функциональ
ной
спецификацией. Оно служит основой для
заключения конт
ракта
между покупателем системы и разработчиками
программно
го
обеспечения.
Ориентируя
свое определение на то, что приходится
различать требования
разных уровней, Соммервилл вводит еще
один класс требований
3.
Проектная
системная спецификация —
обобщенное описание структуры
программной системы, которое будет
основой для более
детализированного проектирования
системы и ее последующей реализации.
Эта спецификация дополняет и детализирует
спецификацию системных требований.
Приведенные
определения дают представление о том,
что понимается под требованиями
разных классов, однако они не выдерживают
критики с точки зрения точности и
применимости к различным ситуациям.
Неправомерно относить проектные
системные спецификации к разряду
требований, поскольку это не внешнее
по отношению к проекту описание, а один
из первых продуктов выполнения проекта;
и то, что такой
продукт нуждается в согласовании, что
он регламентирует разработку,
недостаточно, чтобы считать спецификации
требованиями. Что же касается
требований первых двух классов, то
Соммервилл явно делает акцент лишь на
способе и точности описания программной
системы, оставляя
без внимания необходимое разграничение
между описанием того, что
должна предоставлять пользователю
система — пользовательские
требования
в
нашем понимании, и как она должна работать
— системные
требования.
Разумеется,
в этих определениях нужно говорить и о
функциях,
и об ограничениях, но разделение между
«что» и «как» является действительной
границей между рассматриваемыми
классами. Применительно к менеджменту
это важно, поскольку при организации
процесса производства программного
продукта требования указанных классов
приходится
согласовывать с разными людьми,
заинтересованными в разрабатываемой
системе.
Итак,
с точки зрения целей программный проект
можно рассматривать
как деятельность по реализации системы,
удовлетворяющей вполне определенным
требованиям. Требования не обязательно
формулируются все сразу. Более того,
очень часто они поступают при развитии
проекта и даже уже при использовании
полученной программной системы. И это
характерно
практически для всех программных
разработок. Естественно, деятельность
менеджера должна учитывать, что работа
над проектом ведется в условиях
большой неопределенности относительно
конечного результата.
Перечисленные
аспекты разработки программного
обеспечения определяют
специфику этой деятельности в самых
общих чертах с точки зрения
конкретного ее участника — менеджера
программного проекта. Чтобы разобраться
в том, какие задачи решает менеджер для
организации целенаправленного
эффективного развития проекта, мы
рассмотрим два вопроса:
-
кто участвует в
разработке; -
какие этапы
проходит проект в своем развитии.
Первый
из них поможет выявить функции менеджера
в коллективе разработчиков
и место этих функций среди других
выполняемых при 
развитии
проекта мероприятий. Он имеет два
аспекта, непосредственно связанные
с проведенным выше разграничением между
управлением и руководством.
С
точки зрения управления участники
проекта — это абстрактные действующие
агенты, которые выполняют заданные
функции. Здесь под функцией понимается
некое действие, при выполнении которого
потребляются определенные ресурсы
и производится определенный результат.
Функциональный
взгляд на участников разработки проекта
делает их взаимозаменяемыми,
обезличенными в пределах компетенции,
соответствующей
выполнимости функции. Он приводит к
понятию роли,
назначаемой
работнику для выполнения соответствующих
обязанностей.
Говоря
о руководстве, нужно рассматривать
персоналии, которым назначаются
роли в проекте. Пожалуй, самая главная
задача руководства
— это формирование дееспособного
коллектива, который в состоянии выполнить
данный проект. Понятно, что основным
требованием к коллективу
является его компетентность
и
квалификационная обеспеченность,
необходимые для выполнения проектного
задания. Но глубоко ошибаются
те, кто считает это достаточным. Если
не отработаны способы общения членов
коллектива между собой, с руководством,
с заказчиками, то
никакая компетентность не поможет. В
то же время, как показывает практика,
недостаточная стартовая квалификация
коллектива может успешно
преодолеваться совместным обучением
сотрудников, проводимым
параллельно с основной работой.
Ключевым
качеством коллектива, определяющим его
успешность, является
слаженность.
В
идеальном коллективе все понимают друг
друга с полуслова, есть взаимопонимание
и уважение, не происходят или сведены
к минимуму внутренние конфликты и
противоречия. В реальности менеджеру
редко приходится иметь дело с таким
коллективом, а значит, необходимы меры,
способствующие не только росту
индивидуальной квалификации
работников, но и дееспособности
формируемой команды в
целом. Эти меры следует рассматривать
в качестве задач менеджера как руководителя
коллектива.
Поскольку
развитие проекта — работа, существенно
зависящая от внешних по отношению к
коллективу факторов, определяя место
менеджера
в коллективе разработчиков, полезно
расширить круг участников этого процесса,
включив в него, с одной стороны, заказчиков
программного
продукта, а с другой — руководство
организации {компании, фирмы),
под эгидой которой выполняется проект.
Вопрос
об этапах развития проекта обозначает
задачи менеджера как управляющего
проектом. Он ставится, чтобы раскрыть,
как распределяются
функции менеджера и других исполнителей
во времени. Неоднородность
работ, выполняемых при производстве
программных продуктов, зависимость
этих работ друг от друга, коллективный
характер их выполнения — вот основания
для поэтапной организации развития
проекта с выставлением заданий на этапы
и менеджерским контролем хода работ.
Все
это связывается с понятием жизненного
цикла программного обеспечения.
К
этому нужно добавить, что понятие
жизненного цикла, заимствованное
из традиционных отраслей промышленного
производства, оказалось во многом
(хотя и не во всем!) подобно тому, что
принято считать жизненным
циклом материального продукта.
К
настоящему времени вполне сложилось
представление о том, на какие этапы
разбивается развитие проекта, какие
функции связываются с выполнением
этапов, как должен осуществляться
контроль. Принципы построения
жизненных циклов, которые соответствуют
разным условиям развития
проектов, — предмет специального
изучения, к которому мы очень
скоро вернемся. Здесь же стоит отметить,
что исходя из дидактических
соображений именно жизненный цикл
целесообразно рассматривать
в качестве концептуальной основы
изложения материала по менеджменту
программных проектов. Подобный подход
к изложению применяется
достаточно часто (см., например, [27]).
По
сути, жизненный цикл — это процесс
конструирования программного
обеспечения. Требования к проекту
определяют цели и регламент
данного процесса, а разработчики являются
основной его движущей силой и одним из
главных ресурсов. Другие главные ресурсы
проекта — это
время и финансы, выделяемые для выполнения
проектного задания. Кроме
главных ресурсов проекта, можно говорить
о его производных и вспомогательных
ресурсах. К производным ресурсам
относятся технические средства, а
также программы, используемые в качестве
инструментов,
заготовок и включаемых компонентов, а
к вспомогательным — тепло и
электроэнергия, служебные помещения,
технические и организационные
средства, которые непосредственно с
процессом производства не связаны, но
способствуют его успешному выполнению.
Разделение неглавных
ресурсов на производные и вспомогательные
во многом зависит от специфики выполняемого
проекта. Так, телефон, вообще говоря,
нужно
относить к вспомогательным ресурсам,
но если проект связан, например,
с автоматизацией работы телефонной
станции, то этот ресурс следует
считать производным.
Трудовой
ресурс хорошего проекта является
консервативным, т.е. не очень меняющимся
в ходе выполнения проекта. При плохой
организации Дела
есть риск текучести кадров, которая для
программных проектов отрицательно
сказывается на результатах. Время —
ресурс невосполнимый, а
потому планирование времени является
одной из главных забот менеджера.
Финансы — основной расходуемый ресурс,
который, к сожалению, всегда
ограничен. В частности, они идут не
только на обеспечение заработной
платы работников, но и расходуются на
технические средства и используемые
программы.
В
менеджменте программных проектов
приходится решать задачу составления
и соблюдения оптимального баланса
расходования ресурсов. Эти
задачи характерны для деятельности
менеджера практически любого проекта.
Разумеется, на нее влияют и специфика
проекта, и условия его выполнения.
Как следствие, существует множество
подходов, методов, методик
и даже технологий, поддерживающих
менеджмент. Очень часто они претендуют
на универсальность поддержки. И хотя
подобные претензии — не более чем
реклама, разобраться в том, какова на
самом деле область адекватного
применения предлагаемых инструментов,
без специальной подготовки
довольно трудно. По этой причине мы
пытаемся представить менеджмент
программных проектов в виде, не зависящем
от конкретных методик и технологий,
с тем чтобы любая из них могла быть
соответствующим
образом интерпретирована и читатель
смог осознанно подходить к выбору
рекомендаций и подходов в своей
практической деятельности.
Представленные
выше общие положения, на которых
базируется материал
курса, сегодня практически всегда
берутся за основу изложения в книгах
по программной инженерии (см., например,
[27]). Но следовать им
недостаточно. Требуется общий взгляд
на предмет, который позволит
систематизировать
знания. Выработка такого взгляда у
читателя — одна из основных целей
данного курса.
Таким
образом, при обсуждении задач менеджера
в разработке программных
изделий мы сталкиваемся с тремя
взаимосвязанными направлениями его
деятельности.
-
Первое
направление — это те функции, которые
необходимо выполнять
для успешного развития проекта. Здесь
следует выяснить,
какие
роли сотрудников требуются для данного
проекта. -
Второе
направление — планирование и контроль
хода проекта в
соответствии
с жизненным циклом создаваемого
программного
обеспечения. -
Наконец, третье
направление определяется кругом задач
формирования коллектива и, в частности,
кадровым обеспечением проекта.
Эти
направления подробно рассматриваются
в дальнейших лекциях предлагаемого
курса, рассчитанного на широкий круг
специалистов в области
разработки программного обеспечения.
Вариант
1
1. Менеджмент
программных проектов — это:
-
управление и
руководство в проекте -
отслеживание
жизненного цикла развития проекта -
деятельность,
организующая развитие программного
проекта
во всех его аспектах -
решение
задач распределения ресурсов и контроля
их
расходования -
отслеживание
этапов проекта
2. Служба
менеджера проекта — это:
-
помощники
менеджера, которым он поручает задания
для
освобождения
себя от рутины постоянного контроля -
помощники
менеджера, которым в проекте выделяются
сферы
ответственности
-
организационные
структуры, которые создаются для
помощи
в выполнении задач менеджмента -
помощники
менеджера, которым в той или иной
части
проекта
делегируются полномочия менеджера -
выделенные персоны
из числа разработчиков, которые
помогают
осуществлять менеджмент проекта
3. Источники,
из которых появляются требования,
регламентирующие
и направляющие развитие проекта:
Q
будущие пользователи результатов
выполнения проекта
-
заказчик
и инвестор проекта
О
программисты -
конкуренты
-
подрядчики
Вариант
2
1. Менеджер
программного проекта — это:
-
руководитель
коллектива разработчиков проекта -
административное
лицо, ответственное за отслеживание
жизненного
цикла развития проекта
□ организатор
работ по развитию программного проекта
и
ответственный
за его выполнение
-
тот, кто заказывает
разработку проекта -
сотрудник компании,
распределяющий ресурсы для проекта
2. Делегирование
полномочий — это:
-
распределение
обязанностей между сотрудниками,
участвующими
в реализации проекта -
инструмент
разделения труда, когда для
работника
определяется
ответственность за выполнение
некоторых
функций,
работ и др. -
поручение работнику
выполнение того или иного задания -
назначение
ответственного за определенный этап
выполнения
проекта -
назначение
заместителя на время отсутствия
основного
ответственного
3.
Необходимость понятия жизненного
цикла разработки связана
с тем, что:
-
работы проекта
взаимозависимы и разнородны -
существует
объективное требование разделения
труда
разработчиков -
работы проекта
растянуты во времени -
планируемые
результаты выполнения проекта появляются
по
мере его развития -
есть
аналогии с жизненным циклом из
традиционных
отраслей
промышленного производства
Вариант
3
1. Схемы
организации менеджмента программного
проекта
— это:
-
образование группы
менеджера проекта -
определение
лиц, отслеживающих жизненный цикл
развития
проекта -
единоличное
управление работами по развитию
программного
проекта -
образование службы
менеджера проекта -
распределение
менеджерских обязанностей
между
разработчиками
проекта