Анализ подходов к управлению рисками в программных проектах с итеративным жизненным циклом Текст научной статьи по специальности «Экономика и бизнес»

ПРОГРЕСИВНІ ІНФОРМАЦІЙНІ ТЕХНОЛОГІЇ

ПРОГРЕССИВНЫЕ ИНФОРМАЦИОННЫЕ

ТЕХНОЛОГИИ

PROGRESSIV INFORMATICS TECHNOLOGIES

УДК004.052 Брагина Т. И.1, Табунщик Г. В.2

1 Аспирант Запорожского национального технического университета 2Канд. техн. наук, доцент Запорожского национального технического университета

АНАЛИЗ ПОДХОДОВ К УПРАВЛЕНИЮ РИСКАМИ В ПРОГРАММНЫХ __________ПРОЕКТАХ С ИТЕРАТИВНЫМ ЖИЗНЕННЫМ ЦИКЛОМ__________________________________________

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

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

1. ВВЕДЕНИЕ

Разработка информационных систем связана с определенной совокупностью рисков - неопределенных событий или условий, наступление которых отрицательно или положительно сказывается на целях проекта. Каждый проект задумывается и разрабатывается на основании ряда гипотез, сценариев и допущений - факторов, которые для целей планирования считаются верными, реальными или определенными без привлечения доказательств. Неопределенность в рамках программного проекта (1111) следует обязательно рассматривать в качестве потенциального источника возникновения рисков проекта, так как решение проектных задач управления в условиях неопределенности порождает риски выхода из бюджета и расписания, что ставит под угрозу достижимость целей ПП. Следовательно, процессы управления рисками являются наиболее важной компонентой процессов принятия решений и управления проектами.

2. ПОСТАНОВКА ЗАДАЧИ

Процессы управления рисками проекта включают в себя [1]:

- планирование управления рисками;

- идентификацию рисков;

© Брагина Т. И., Табунщик Г В., 2011

- качественный анализ рисков;

- количественный анализ рисков;

- планирование реагирования на риски;

- мониторинг и управление рисками.

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

Исходными данными для выявления рисков является имеющаяся информация как об общих, так и о специфических для данного проекта рисках, связанная с бизнесом, технологиями, организациями и внешними условиями. Основным фактором, влияющим на возможные риски, является принятая в компании модель программного обеспечения (ПО), т. е. структура, определяющая последовательность выполнения и взаимосвязи процессов, действий и задач на протяжении жизненного цикла (ЖЦ). Существуют также дополнительные факторы, которым должно быть уделено внимание: имеющийся у команды опыт, применяемые внутри организации подходы к рискам, выраженные в виде правил и инструк-

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

Для различных моделей ПО можно выделить основные, наиболее часто встречающиеся риски, характерные для каждой из них. Выделим наиболее распространенные модели, ориентированные на итеративный процесс разработки - Rational Unified Process (RUP), Microsoft Solutions Framework (MSF) и Agile (eXtreme Programming, Crystal, Feature Driven Development) [3].

Предвосхищение потенциальных проблем и заблаговременная подготовка четко составленных планов по борьбе с ними сокращает временные затраты в критических ситуациях и ограничивает негативный эффект, создаваемый рисками. Поэтому руководитель проекта, определив модель разработки ПО, которую будет использовать для проекта, должен осознавать сильные и слабые стороны данной модели, а также то, что управление рисками будет зависеть от характерных черт выбранной модели [4, 5].

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

3. ИДЕНТИФИКАЦИЯ РИСКОВ ПРОГРАММНЫХ ПРОЕКТОВ С ИТЕРАТИВНЫМ ЖИЗНЕННЫМ ЦИКЛОМ

Анализ литературы [6-10] позволяет выделить основные риски проектов по разработке ПО:

- внутренние нарушения календарного планирования;

- изменение требований;

- текучесть кадров;

- нарушение спецификаций;

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

- недостаточное внимание к проекту со стороны руководства компании;

- отсутствие мотивации персонала компании.

Нарушения календарного планирования

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

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

дукта, который предстоит создать. В случае, когда календарное планирование строится без учета размера продукта, весьма вероятен перерасход времени на 50-80 %.

Статистика по ГГ-проектам показывает, что многие ком -пании не выполняют предварительной оценки размера проекта, выбирая вместо этого календарное планирование от конца к началу или принимая желаемое за действительное. Те компании, которые прилагают серьезные усилия для определения размера продукта, могут сократить влияние ошибок календарного планирования до 15 %.

Изменение требований

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

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

Текучесть кадров

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

Нарушение спецификаций

Реализация риска нарушение спецификаций чаще всего является фатальной для проекта.

Нарушение спецификаций относится к краху процесса переговоров по установлению требований, которые идут в начале любого проекта. Когда существует глубокий конфликт, не позволяющий прийти к согласию, то часто результат маскируют. В итоге приходится столкнуться с отложенными проблемами, и конфликт разгорается вновь. В худшем случае это происходит на очень поздней стадии проекта, когда истрачены отведенные па проект ресурсы. Проект очень уязвим в этой стадии, и отказ любой из сторон поддерживать его может привести к быстрому прекращению разработки - процентный диапазон прекращения проектов из-за нарушения спецификаций составляет 10-15 % [6].

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

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

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

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

Существует множество причин (сопровождение действующих систем, повышение квалификации, участие в подготовке технико-коммерческих предложений, участие в презентациях, административная работа, отпуска, праздники, больничные), по которым участники проекта не смогут работать по проекту 100 % своего времени. При принятии риска рекомендуется планировать, что разработчики, которые назначены в проект на 100 %, будут реально работать над задачами проекта в среднем от 24 до 32 часов в неделю вместо 40 часов [11].

Недостаточное внимание к проекту со стороны руководства компании

Часть неудач по созданию ПО объясняется фрагментарностью подхода к процессу управления. Например, концентрируя свои усилия на технической стороне реализации, управляющий проектом уделяет недостаточное внимание проблемам управления человеческими ресурсами. Или, наоборот, техническая сторона контролируется не на достаточном уровне либо допускаются несоответствия в графике разработки.

Отсутствие мотивации персонала компании

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

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

4. ПЛАНИРОВАНИЕ РЕАКЦИИ НА РИСК ДЛЯ ПРОЕКТОВ С ИТЕРАЦИОННЫМ ПРОЦЕССОМ РАЗРАБОТКИ

По отношению к выявленным рискам возможны следующие действия [б]:

- ликвидация риска (например, за счет устранения причины);

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

- принятие риска (и выработка плана действия в соответствующих условиях);

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

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

В табл. 1 рассмотрены методы управления рисками для наиболее распространенных моделей ПО с итерационным циклом разработки - RUP, MSF и Agile [4], учитывающие особенности каждого типа проекта.

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

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

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

Таблица 1. Возможная реакция на риск в зависимости от типа программного проекта

' ~^_Тип проекта Тип риска RUP MSF Agile

Нарушения календарного планирования, срыв сроков Перерасчет сроков выполнения этапов работ Планирование временного резерва Выделение сверхурочных трудочасов, повышенное внимание к предварительному планированию

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

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

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

Нарушение спецификаций Политика ликвидации риска - подписание договора между заказчиком и компанией с описанием входных и выходных условий, оценка рисков независимыми экспертами

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

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

Отсутствие мотивации персонала компании Проведение тренингов, корпоративных собраний, внедрение методик team building Премирование персонала в зависимости от успешности выполнения проектов Распространение акций фирмы среди персонала, выделение разработчикам % от прибыли с проекта

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

ВЫВОДЫ

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

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

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

1. Microsoft Solutions Framework. Дисцинлина управления рисками MSF, вер. 1.1: [Электрон. ресурс]. - Режим доступа: http://www.microsoft.com/rus/msf.

2. PMBOK Руководство к Своду знаний по управлению проектами, 3-е изд. / PMBOK, Project Management Institute. - PMI, 2004. - 411 c.

3. Груздо, И. В. Повышение качества программного нроек-та за счет управления рисками / И. В. Груздо // Моделювання в економіці, організація виробництва та управління проектами. - 2009. - 1. - С. 141-14б.

4. ДеМарко, Т. Вальсируя с медведями Управление рисками в проектах по разработке программного обеспечения / Том ДеМарко, Тимоти Листер, p.m. Office, 2005. - 190 с.

5. Брагина, Т. И. Сравнительный анализ итеративных моделей разработки программного обеспечения / Т. И. Брагина, Г. В. Табунщик // Радиоелектроніка, інформатика, управління. - 2010. - № 2. - С. 130-139.

6. Bragina, T. Comparative Analysis of Software Development Models for Electro-technical Systems / T. Bragina, G. Tabunshchik // Proc. of Int. Conf. on Modern Problem of Radio Engineering, Telecommunications and Computer Science TCSET’2010, February 19-23, 2010, Lviv-Slavsko, Ukraine. -P. 347.

7. Брагина, Т. И. Классификация моделей итеративной разработки программного обеспечения / Т. И. Брагина,

Г. В. Табунщик // Системный анализ. Информатика. Ун -равление : материалы Всеукраинской научно-нрактичес-кой конференции, САГУ-2010, Март 04-05, 2010, Запорожье, Украина. - Запорожье : КПУ, 2010. - С. 23-25.

S. Галатенко, В. А. Управление рисками: обзор употребительных подходов / Галатенко В.А. // Информационный бюллетень. - №11(1б2). - 200б. - C. 1-15

9. Липаев, В. В. Анализ и сокращение рисков проектов программных средств / В.В. Линаев // Jet Info. - 2005. - №1. -С. 1-3б.

10. Астахов, А. Как управлять рисками информационной безо-насности? / А. Астахов // CISA. - ноябрь 200б. - С.121 - 124.

11. Петренко, С. Методики и технологии управления информационными рисками / С. Петренко, С. Симонов // IT Manager. - 2003. - №3. - С. 57-б1.

Стаття надійшла до редакції 09.11.2010.

Після доробки 11.03.2011.

Брагіна Т. І., Табунщик Г. В.

АНАЛІЗ ПІДХОДІВ ДО КЕРУВАННЯ РИЗИКАМИ В ПРОГРАМНИХ ПРОЕКТАХ З ІТЕРАЦІЙНИМ ЖИТТЄВИМ ЦИКЛОМ

Виконано огляд головних ризиків програмних проектів з ітераційним життєвим циклом. Запропоновані рекомендації з управління виявленими ризиками в залежності від обраної моделі розробки програмних проектів. Виділено найбільш критичні ризики та проведено їх якісний аналіз.

Ключові слова: керування ризиками, програмні проекти, реакція на ризик.

Bragina T. I., Tabunshchyk G.V.

ANALYSIS RISK MANAGEMENT APPROACHES IN SOFTWARE PROJECTS WITH AN ITERATIVE LIFECYCLE

In the article there is performed a review of the main risks in the software projects with an iterative lifecycle. The authors developed guidelines for the risks identified management, depended on the software development projects model. The most critical risks are identified and the qualitative analysis was made by the authors.

Key words: the risk management, the software projects, reaction on the risk.

УДК 004.75

Дьячук Т. С.

Асистент Запорожского национального технического университета

ОЦЕНКА ХАРАКТЕРИСТИК РАСПРЕДЕЛЕННОЙ СИСТЕМЫ

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

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

ВВЕДЕНИЕ

Оптимизация ресурсов является одной из важных за-

ресурсов: материальные, информационные, финансо-

вые, интеллектуальные, трудовые, энергетические, вре-дач в современном мире. Существует множество видов

^ мени и другие. Эффективное использование ресурсов

© Дьячук Т. С., 2011