УДК 004.4

МЕТОДЫ МИНИМИЗАЦИИ РЕСУРСНЫХ РИСКОВ В ПРОЕКТАХ РАЗРАБОТКИ ПРОГРАММНЫХ ПРОДУКТОВ

Ошурков Вячеслав Александрович1, Макашова Вера Николаевна1
1Магнитогорский государственный технический университет

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

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


METHODS OF MINIMIZATION OF RESOURCE RISKS IN PROJECTS OF SOFTWARE DEVELOPMENT

Oshurkov Vyacheslav Aleksandrovich1, Makashova Vera Nikolayevna1
1Magnitogorsk State Technical University

Abstract
This article is dedicated resource risks in projects of software development. The analysis we have identified specific for this project resource risks highlighted standards and methods of minimization of resource risks, and develop a response plan resource risks in projects of software development.

Рубрика: 05.00.00 ТЕХНИЧЕСКИЕ НАУКИ

Библиографическая ссылка на статью:
Ошурков В.А., Макашова В.Н. Методы минимизации ресурсных рисков в проектах разработки программных продуктов // Современные научные исследования и инновации. 2014. № 10. Ч. 1 [Электронный ресурс]. URL: http://web.snauka.ru/issues/2014/10/37111 (дата обращения: 29.09.2017).

Более  85% опрашиваемых российских организаций, занимающиеся разработкой программных продуктов, учитывают ресурсные риски при разработке проекта [4]. Несмотря на это, больше половины проектов по разработке программного продукта завершаются провалом. Связанно это с отсутствием опыта управления ресурсными рисками. Ниже приведены цифры, свидетельствующие об актуальности проблемы: [7]:

-       компании, у которых высокая зрелость, завершают 73% проектов в срок и 69% проектов в рамках запланированного бюджета, и лишь 10% закрываются до завершения;

-       компании, у которых средняя зрелость, завершают уже 56% проектов в срок и 58% в рамках бюджета, а 11% проектов закрывается до завершения;

-       компании, зрелость которых определена как низкая, завершают уже менее половины проектов в срок – 42%, 44% в рамках бюджета, и 13% заканчиваются до запланированного ранее завершения.

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

Ресурсные риски – это риск, обусловленный недостатками в организации работы [9]. Такие риски связаны с командой разработчиков программного продукта:

  1. Аналитики.
  2. Программисты.
  3. Верстальщики.
  4. Тестировщики.

Основными причинами ресурсных рисков в проектах по разработке программного продукта являются [9]:

-                недостатки координации работ и слабое регулирование основных ресурсов в проекте;

-                ошибки в назначении ресурсов проекта на задачи;

-                низкая продуктивность ресурсов;

-                ошибки, присущие расписанию при планировании проекта;

-                качество ресурсов.

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

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

Таблица 1 – Иерархическая структура проекта

№ п/п

                          Задача

Подзадача

1

Постановка задачи

Предпроектное обследование
Подготовка документации (определение требований)
Согласование документации

2

Разработка программного продукта

Проектирование программного продукта
Интеграция продукта

3

Тестирование программного продукта

Тестирование
Исправление ошибок

4

Внедрение программного продукта

Установка программного продукта
Обучение персонала

5

Информационная поддержка

Доработка продукта по результатам эксплуатации

Таблица 2 – Ресурсный план проекта

№ п/п

Ресурс

Процент загрузки

1

Аналитик 1

100%

2

Аналитик 2

100%

3

Аналитик 3

100%

4

Аналитик 4

100%

5

Программист 1

100%

6

Программист 2

100%

7

Верстальщик 1

100%

8

Тестировщик 1

100%

9

Тестировщик 2

100%

10

Менеджер проекта

100%

11

Куратор проекта

100%

Для выявления ресурсных рисков в проекте принято использовать следующие стандарты:

  1. PMBOK.
  2. FERMA.
  3. PRINCE2.
  4. Microsoft Solutions Framework (MSF).
  5. Oracle Application Implementation Method (AIM).

В результате анализа стандартов, нами был взят за основу стандарт «PMBOK», т.к. он стандарт, во-первых, унифицированный для всех стран, во-вторых, отображает специфику проекта, в-третьих, ориентирован на процесс и определяет для него все ресурсы, инструменты и результаты.

1 этап. Идентификация рисков

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

Таблица 3 – Реестр ресурсных рисков проекта

№ п/п

Ресурсный риск

Описание

1

Декомпозиция спецификации

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

2

Низкая продуктивность

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

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

3

Уровень сотрудничества

Низкая продуктивность является следствием низкого уровня сотрудничества. Из этого вытекают следующие проблемы:

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

- ресурс не реализует уникальные навыки.

4

Ошибки, присущие расписанию

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

5

Координация работы

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

6

Качество ресурсов

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

2 этап. Качественный анализ рисков

Расставим приоритеты (вероятность наступления) рисков по 5-бальной шкале (см. табл. 4), в соответствии со спецификой проекта.

3 этап. Количественный анализ рисков

Определим влияние рисков по 5-бальной шкале (см. табл. 4). На основании вероятности наступления и влиянии риска определим уровень риска. Для определения показателей ресурсных рисков нами был рассчитан коэффициент ранговой корреляции Кенделла, где X – вероятность наступления ресурсного риска, Y – влияние ресурсного риска.

Результаты расчета:

-                коэффициент корреляции Кенделла τ = 0,2;

-                критическая точка Tkp = 0,8.

τ < Tkp – нулевая гипотеза; ранговая корреляционная связь между признаками ресурсных рисков незначимая. Можно сделать следующие выводы:

  1. Объект Y не зависит от объекта X. Рост вероятности наступления ресурсного риска никак не отразится на его влиянии (последствие проявления).
  2. Объект X не зависит от объекта Y. Рост увеличения влияния (последствие проявления) ресурсного риска никак не отразится на его вероятности наступления.

Таблица 4 – Результаты качественного и количественного анализа рисков

Ресурсный риск

Вероятность наступления (1-5) (X)

Влияние риска (1-5) (Y)

Уровень риска

1

Декомпозиция спецификации

3

5

высокий

2

Низкая продуктивность

5

3

средний

3

Уровень сотрудничества

1

5

средний

4

Ошибки, присущие расписанию

3

5

средний

5

Координация работы

2

5

высокий

6

Качество ресурсов

1

4

высокий

4 этап. Планирование реагирования на риски

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

  1. Модель «SW-CMM».
  2. Рациональный унифицированный процесс разработки программного продукта (RUP).
  3. Гибкая методология разработки программных продуктов «Agile».
  4. Доска задач «SCRUM».
  5. Опросные листы.

Для минимизации ресурсных рисков по проекту разработки программного продукта мы предлагаем использовать следующую комбинацию методов и технологий:

  1. Гибкая технология разработки программных продуктов «Agile».
  2. Доска задач SCRUM.

Суть «Agile» состоит в получении оперативной обратной связи и как следствие — быстрой реакции на изменения в проекте (приоритетах, списке работ, в новых идеях заказчика).

«SCRUM» позволяет выявить текущую занятость ресурсов в проектах.

Минимизация ресурсных рисков по проекту разработке программного продукта

Во-первых, расставим приоритеты между задачами на этапе планирования проекта (см. табл. 5). Результат приоритезации – фокусирование на самых важных задачах проекта. Стоит отметить, что приоретизация задач будет меняться в результате начала проекта и работы с заказчиком.

Таблица 5 – Приоритеты задач проекта в соответствии с «Agile»

№ п/п

Задача

Приоритет

1 Постановка задачи

1

1.1 Предпроектное обследование

1.1

1.2 Подготовка документации (определение требований)
1.3 Согласование документации

1.2

2 Разработка программного продукта

2

2.1 Проектирование программного продукта

2.1

2.2 Интеграция продукта

2.1

3 Тестирование программного продукта

3

4.1 Тестирование

3.2

4.2 Исправление ошибок

3.1

4 Внедрение программного продукта

4

3.1 Установка программного продукта

4.2

3.2 Обучение персонала

4.1

5 Информационная поддержка

5

5.1 Доработка продукта по результатам эксплуатации

5.1

Во-вторых, избавимся от многозадачности ресурсов. Для выявления текущей загрузки ресурсов предлагаем использовать доску задач «SCRUM». На доске ресурс проекта должен ежедневно отмечать следующую информацию:

  1. Информация по текущей задаче (в работе): название задачи, время решения текущей задачи.
  2. Общее количество текущих задач (в работе).
  3. В каких задачах ресурс заинтересован.
  4. Выполненные задачи.
  5. Задачи, которые необходимо сделать.
  6. Предложения по решению текущих задач.

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

В-третьих, обновим план проекта (см. табл. 6) в соответствии с основной концепцией «Agile». Основная концепция «Agile» предполагает промежуточные итерации. Под итерациями, в контексте разработки ПО, понимается:

  1. Совещания с рабочей группой (рабочая группа по «Agile» выделяется на один проект и не претерпевает изменений в составе до окончания проекта).
  2. Совещания с заказчиком.
  3. Обсуждение открытых вопросов по проекту.
  4. Демонстрация функционала.

Таблица 6 – Перечень задач в соответствии с «Agile»

№ п/п

Задача

1 Постановка задачи
1.1 Предпроектное обследование
1.2 Подготовка документации (определение требований)
1.3 Совещание: 2 раза/день
1.4 Согласование документации
2 Разработка программного продукта
2.1 Проектирование программного продукта
2.2 Циклическая задача: совещания, обсуждение открытых вопросов, общение с заказчиком, демонстрация функционала
2.3 Внесение изменений по результатам общения с заказчиком
2.4 Координация работ
2.5 Интеграция продукта
3 Тестирование программного продукта
3.1 Тестирование
3.2 Совещание: 2 раза/день
3.3 Исправление ошибок
4 Внедрение программного продукта
4.1 Установка программного продукта
4.2 Совещание: 2 раза/день
4.3 Обучение персонала
5 Информационная поддержка
5.1 Доработка продукта по результатам эксплуатации
5.2 Циклическая задача: совещания, обсуждение открытых вопросов, общение с заказчиком, демонстрация функционала

В результате применения «Agile» и «SCRUM» можно минимизировать ресурсные риски. В таблице 7 представлены основные воздействия на ресурсные риски.

Таблица 7 – Минимизация ресурсных рисков

Ресурсный риск

Минимизация ресурсного риска

1

Декомпозиция спецификации

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

2

Уровень сотрудничества

Проведение итераций:

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

- встречи с заказчиком и уточнение вопросов по ходу реализации ПО;

- документирование хода работы и ее результатов;

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

3

Низкая продуктивность

Доска задач SCRUM обеспечит менеджеру проекта прозрачность ресурсов:

- Информация по текущей задаче (в работе): временные рамки решения текущей задачи.

- Общее количество текущих задач (в работе).

- В каких задачах ресурс заинтересован.

- Выполненные задачи.

- Задачи, которые необходимо сделать.

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

4

Ошибки, присущие расписанию

Периодические совещания и определение на соответствие срокам.

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

5

Координация работы

В отличие от альтернативной методологии разработки — «Каскадная модель», когда заказчик получает через заранее определенный срок, к примеру, через год строго то, что изначально запланировали в проекте, в Аgile изменения можно вносить по мере необходимости в процессе разработки. Это облегчит весь процесс разработки и сдачи программного продукта

6

Качество ресурсов

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

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

Для идентификации ресурсных рисков нами был использован стандарт управления проектами PMBOK:

  1. На первом этапе мы идентифицировали ресурсные риски и занесли их в реестр.
  2. На втором этапе мы произвели качественный анализ рисков, по результатам которого проставили каждому риску вероятность наступления по 5-больной шкале.
  3. На третьем этапе мы произвели количественный анализ рисков, по результатам которого проставили каждому риску величину влияния по 5-больной шкале и уровень. Взяв за основу признаки ресурсных рисков: вероятность наступления ресурсного риска и влияние ресурсного риска, мы выявили зависимость между этими признаками, рассчитав коэффициент ранговой корреляции Кенделла. Зависимости не обнаружилось.
  4. На заключительном этапе нами был составлен план реагирования на риски. В качестве механизмов минимизации ресурсных рисков нами были взяты:

4.1.          Гибка технология разработки программных продуктов Agile.

4.2.          Доска задач SCRUM.

В результате мы привели проект в соответствие с механизмами минимизации ресурсных рисков:

-                расставили приоритеты между задачами;

-                избавились от многозадачности;

-                обновили план проекта, добавив итерации.

Применение выбранных механизмов помогут во время отреагировать на ресурсные риски и максимально эффективно реализовать проект в поставленные сроки.


Библиографический список
  1. Agile – гибкое управление проектами [Электронный ресурс]. – 2014. – Режим доступа: http://wunderkraut.ru/agile-gibkoe-upravlenie-proektami
  2. FERMA. Стандарт управления рисками.
  3. ГОСТ Р 54869—2011 «Проектный менеджмент. Требования к управлению проектом».
  4. Практика управления финансовыми рисками в компаниях нефинансового сектора: Результаты исследования Декабрь 2008 Бейкер Тилли Русаудит // Официальный сайт компании Бейкер Тилли Русаудит. 2012. – 15 с.
  5. Ресурсные риски [Электронный ресурс]. – 2013. – Режим доступа: http://www.taurion.ru/project/15/4
  6. Руководство к Своду знаний по управлению проектами Четвертое издание (Руководство PMBOK) Американский национальный стандарт ANSI/PMI 99-001-2004.
  7. Семинар Московского отделения PMI риски [Электронный ресурс]. – 2011. – Режим доступа: http://www.pmi.org
  8. Технология разработки программного обеспечения [Электронный ресурс]. – 2013. – Режим доступа: http://tehprog.ru/index.php_page=lecture12.html
  9. Характеристика рисков в различных сферах предпринимательской деятельности [Электронный ресурс]. – 2013. – Режим доступа: http://bussinesrisk.ru/lektsii-po-upravleniyu-riskom-na-predpriyatii/70-xarakteristika-riskov-v-razlichnyx-sferax.html
  10. Якобсон А., Буч Г., Рамбо Дж. Унифицированный процесс разработки программного обеспечения – Спб.: Питер, 2002. – 496 с.: ил.
  11. Рогов М.А. Риск – менеджмент. М., 2011. С. 15.


Все статьи автора «Вячеслав Ошурков»


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

Связь с автором (комментарии/рецензии к статье)

Оставить комментарий

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

Если Вы еще не зарегистрированы на сайте, то Вам необходимо зарегистрироваться: