Sb97307

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

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

АИС «Курсы повышения квалификации». Необходимо автоматизи-

ровать деятельность по организации курсов повышения квалификации в учебном заведении. Имеются сведения о сформированных группах студентов. Группы формируются в зависимости от специальности и отделения. Проведение занятий обеспечивает штат преподавателей. Для каждого из них в базе данных хранятся стандартные анкетные данные. В результате распределения нагрузки определяется, сколько часов занятий проводит каждый преподаватель с группами. Также хранятся данные о предмете и оплате за 1 час.

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

АИС «Туристическая компания». Необходимо автоматизировать финансовую сторону деятельности туристической компании, продающей путев-

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

На очередной демонстрации выясняется, что туристические путевки могут иметь разную длительность: 7, 12 и 14 ночей. Стоимость путевки зависит от длительности тура.

АИС «Аренда автомобилей». Необходимо автоматизировать работу компании по аренде автомобилей. В автопарке компании есть несколько автомобилей различных марок, стоимостей и типов. Каждый автомобиль имеет определенную стоимость проката. При совершении сделки с клиентами фиксируются анкетные данные клиентов, дата выдачи и ожидаемая дата возврата автомобиля.

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

21

ТЕСТ ДЛЯ САМОКОНТРОЛЯ

1.Для чего служит устав проекта?

1) Для формальной авторизации проекта и документирования началь-

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

выполняться, контролироваться и закрываться;

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

4)для описания процессов выполнения работ по достижению целей

проекта.

2.Концепция _______ означает, что изменение одного из ограничений – содержания, сроков или стоимости – влияет на остальные ограничения.

1)Оценки по трем точкам;

2)Тройственного ограничения;

3)трех мудрецов;

4)теории трех потребностей.

3.Какие из следующих документов НЕ используются как входы для процесса подтверждения содержания?

1)Базовый план по содержанию, включающий в себя описание содержания проекта, ИСР и словарь ИСР;

2)проверенные, т. е. законченные результаты, и проверенные на корректность в процессе выполнения контроля качества;

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

4)матрица, описывающая ответственность исполнителей в случае провала проекта.

4.Что НЕ является основанием для предприятия накапливать базу зна-

ний «lessons learned»?

1) База знаний о проектах «lessons learned» – важный компонент ин-

формационных ресурсов предприятия;

2)база знаний о проектах «lessons learned» должна использоваться для выявления ответственных за ошибки в проектах и дальнейшего их наказания;

3)база знаний о проектах «lessons learned» используется для выработ-

ки решений по улучшению результатов в будущих проектах;

22

4) ретроспектива – совещание по формированию базы знаний о проек-

тах «lessons learned» при завершении очередной фазы проекта, является инструментом сплочения команды проекта.

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

1)Перечень срабатывания рисков;

2)перечень выявленных рисков;

3)передача риска;

4)дерево решений.

6.Проект по разработке программного обеспечения находится в самом начале, необходимо оценить высокоуровневые риски. Что нужно делать?

1)Разрабатывать устав проекта;

2)идентифицировать и качественно и количественно анализировать

риски;

3)разрабатывать резервные планы для непредвиденных ситуаций;

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

выми заинтересованными сторонами проекта.

7. Какое утверждение лучше всего описывает процесс определения до-

пущений на этапе инициации проекта?

1) Выявить все риски, связанные с проектом – обязанность лица, от-

ветственного за продажи;

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

проекта;

3)все виды допущений должны быть зафиксированы в уставе проекта;

4)риски являются следствием неопределенности. Устранение всех неопределенностей означает, что проект будет полностью лишен рисков.

8.Словарь ИСР – это документ, который…

1)…описывает термины области знаний управления содержанием

проекта;

2)…описывает каждый пакет работ в ИСР;

3)…в случае международных проектов дает перевод терминов ИСР на английский язык;

4)…помогает сопоставлять функциональные требования с техниче-

скими.

23

9. Вы недавно вошли в команду проекта. Устав проекта уже разработан.

Что нужно делать дальше?

1)Разрабатывать перечень рисков;

2)разрабатывать расписание контрольных точек проекта;

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

4)утверждать план управления проектом.

10.Во время совещания возникла дискуссия – сколько и каких докумен-

тов, описанных в PMBoK, должно формироваться в проекте? Как правильно ответить на этот вопрос?

1)Команда может вообще не руководствоваться принципами, изложенными в PMBoK, они не влияют на результат;

2)чем больше документов будет разработано, тем лучше будет ре-

зультат;

3)нужно следовать всем процессам и составлять все документы, описанные в PMBoK;

4)проектная команда должна выбрать процессы и документы в соответствии с требованиями текущего проекта.

11.В каком документе описываются критерии приемки продукта?

1)Описание содержания проекта;

2)иерархическая структура работ;

3)документ о назначении ресурсов;

4)план управления содержанием проекта.

12.Во время проверки кода в крупном программном проекте команда обнаружила много критических ошибок. Эти ошибки хаотично разбросаны по всему коду. Какой инструмент, скорее всего, может помочь команде опре-

делить области концентрации ошибок в целях выработки приоритетов стратегии реагирования?

1)Контрольный список (checklist);

2)диаграмма влияния;

3)дерево решений;

4)технологическая схема.

13.Базовые планы по содержанию включают в себя:

1)все планы по управлению проектом;

2)базовые планы по расписанию и стоимости;

3)идентификатор конфигурации продукта и техническое задание;

4)словарь ИСР, ИСР, определение содержания проекта.

24

14.Что неправильно по отношению к запросам на изменение?

1)Запросы на изменение должны быть рассмотрены и одобрены либо отвергнуты перед их выполнением;

2)запросы на изменение могут привести к изменению содержания;

3)при профессиональном управлении запросы на изменение помога-

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

рования и их нужно избегать любым путем.

15.Сжатие – это техника ускорения проекта с помощью…

1)…перераспределения существующих ресурсов или назначения дополнительных ресурсов на проект;

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

3)…сокращения количества функций программного продукта для уменьшения количества операций;

4)…сокращения времени на выполнение операций с помощью административных мер воздействия на команду проекта.

16.Во время совещания по идентификации рисков ваша команда определила более 150 рисков. Вы беспокоитесь, что количественная оценка каж-

дого из этих рисков займет больше времени, чем запланировано, причем некоторыми рисками можно пренебречь. Что будете делать?

1)Идентифицируете риски, вероятность срабатывания которых наиболее велика. Оцените количественно только те риски, которые не войдут в этот список;

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

тетов при проведении количественного анализа; 3) оцените качественно вероятность каждого риска и затем проанали-

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

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

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

рая операция имеет следующие характеристики: ранний старт ES = 3, поздний старт LS = 13, ранний финиш EF = 9, поздний финиш LF = 19. Это зна-

чит, что…

1)Операция на критическом пути;

2)операция имеет задержку по времени;

25

3)операция выполняется в срок;

4)операция не на критическом пути.

18.Руководство организации требует представить отчет о текущем ста-

тусе выполнения проекта. Вы воспользуетесь ….

1)Детализированными оценками стоимости;

2)планами управления проектом;

3)гистограммами;

4)отчетом о прохождении вех в расписании проекта.

ГЛОССАРИЙ

Базовый план (Baseline) – утвержденный для проекта план с возможным включением одобренных изменений. Сравнивается с фактическим выполне-

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

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

Выравнивание ресурсов (Resource Leveling) – любая форма анализа сети,

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

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

Диаграмма Ганта (Gantt Chart) – графическое представление информа-

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

вязанных к датам.

26

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

Заинтересованная сторона (Stakeholder) – лицо или организация, на чьи интересы могут позитивно или негативно повлиять исполнение или заверше-

ние проекта. Заинтересованная сторона также может оказывать влияние на проект и его результаты.

Запрос на изменение (Change Request) – запросы на увеличение или уменьшение содержания проекта, изменение стратегий, процессов, планов или процедур, изменение цен или бюджетов или пересмотр расписаний.

Идентификация рисков (Identify Risks) – процесс определения рисков,

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

Иерархическая структура работ (Work Breakdown Structure) – ориенти-

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

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

Инспекция (Inspection) – обследование и изучение с целью проверить, соответствует ли операция, элемент, продукт, результат или услуга указан-

ным требованиям.

Качественный анализ рисков (Perform Qualitative Risk Analysis) – про-

цесс расстановки приоритетов в отношении рисков для их дальнейшего анализа или действий путем оценки и сопоставления их воздействия и вероятно-

стей возникновения.

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

ления проектами.

Количественный анализ рисков (Perform Quantitative Risk Analysis) –

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

Контроль качества (Perform Quality Control) – процесс мониторинга и документирования результатов действий, направленных на обеспечение ка-

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

Контрольное событие (Milestone) – важный момент или событие проекта.

27

Критерии приемки (Acceptance Criteria) – критерии, в том числе требо-

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

Критическая операция (Critical Activity) – любая запланированная операция на критическом пути в расписании проекта. Чаще всего определяется методом критического пути.

Критический путь (Critical Path) – обычно, но не всегда, последователь-

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

Матрица вероятности и воздействия (Probability and Impact Matrix) –

общепринятый подход, заключающийся в отнесении риска к высоким, сред-

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

Матрица отслеживания требований (Requirements Traceability Matrix) –

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

Менеджер проекта (Project Manager) – лицо, назначенное исполняющей организацией для достижения целей проекта.

Накопленные знания (Lessons Learned) – знания, полученные в ходе ис-

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

обходимо включать в базу накопленных знаний.

Обеспечение качества (Perform Quality Assurance) – процесс проверки соблюдения требований качества и результатов измерений в процессе контроля качества для обеспечения использования соответствующих стандартов качества и операционных определений.

Ограничение (Constraint) – состояние, качество или понимание сдержи-

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

нения проекта или процесса.

Отношение предшествования (Precedence Relationship) – термин, ис-

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

Операция (Activity) – элемент работ проекта.

Остаточный риск (Residual Risk) – риск, оставшийся после реагирова-

ния на риски.

28

Оценка длительности операций (Estimate Activity Durations) – процесс приблизительного определения количества рабочих периодов, требуемых для завершения отдельных операций при предполагаемых ресурсах.

Оценка ресурсов операций (Estimate Activity Resources) – процесс оценки типов и количества материалов, человеческих ресурсов, оборудования или запасов, требуемых для выполнения каждой операции.

Пакет работ (Work Package) – результат или элемент работ проекта,

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

Передача риска (Risk Transference) – метод планирования реагирования на риски, который перекладывает последствия наступления угрозы вместе с ответственностью за реагирование на третью сторону.

Подтверждение содержания (Verify Scope) – процесс формализованной приемки достигнутых результатов проекта.

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

Принятие риска (Risk Acceptance) – метод планирования реагирования на риски, свидетельствующий о том, что команда проекта приняла решение не изменять план управления проектом в связи с риском или не нашла другой подходящей стратегии реагирования.

Реестр рисков (Risk Register) – документ, содержащий результаты качественного анализа рисков, количественного анализа рисков и планирования реагирования на риски.

Сетевая диаграмма проекта (Project Schedule Network Diagram) – любое схематическое отображение логических связей между запланированными операциями проекта. Всегда строится слева направо для отображения хроно-

логии работ проекта.

Сжатие (Crashing) – особый тип метода сжатия расписания проекта,

при котором общая длительность проекта уменьшается после проведения анализа серии альтернатив для достижения максимального сжатия длитель-

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

29

Снижение рисков (Risk Mitigation) – метод реагирования на риски, кото-

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

Содержание (Scope) – совокупность продуктов, услуг и результатов, являющихся предметом проекта

Совместное расположение (Co-location) – способ размещения, при ко-

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

Уклонение от риска (Risk Avoidance) – метод планирования реагирова-

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

Ответы на вопросы теста: 1 – 1; 2 – 2; 3 – 4; 4 – 2; 5 – 2; 6 – 1; 7 – 3; 8 – 2;

9 – 3; 10 – 4; 11 – 1; 12 – 1; 13 – 4; 14 – 4; 15 – 1; 16 – 2;17 – 4; 18 – 4.

СПИСОК ЛИТЕРАТУРЫ

1. Руководство к своду знаний по управлению проектами (Руководство

PMBOK) / пер. с англ. М.: Олимп-Бизнес, 2014.

2. Архипенков С. Лекции по управлению программными проектами //

Сергей Архипенков: сайт. Москва, 2009. URL: http://www.arkhipenkov.ru/resources/sw_project_management.pdf (дата обраще-

ния 31.10.2016).

3.Демарко Т., Листер Т. Вальсируя с Медведями. Управление рисками в проектах по разработке программного обеспечения / пер. с англ. М.: Компа-

ния p.m.Office, 2005.

4.Пайлон Д., Майлз Р. Управление разработкой ПО. СПб.: Питер, 2014.

464 с.

30