Анализ и управление рисками проектов в области конвертации баз данных

Ilia A. Semenov

Russia, Saint-Petersburg, INTERNATIONAL UNIVERSITY OF FUNDAMENTAL STUDIES, 2004

 

Введение

 

Организовать — значит сначала оценить возможность, а уже потом ставить задачу.

Неотъемлемым свойством экономического прогресса является использование современных информационных систем. Информационные системы имеют дело с организацией и обработкой больших объемов данных, обеспечивая информационную поддержку принятия решений аналитикам и менеджерам проектов.
Основные задачи, которые ставятся на этапе оценки конвертируемых баз – это определение точных сроков проекта; ошибись здесь, и проект будет неверным долгое время. Сделаем все правильно, и мы – на полпути к решению. Это потенциально одна из наиболее сложных задач в управлении проектами.
Оценка временных затрат процесса переноса баз данных с одной СУБД на другую это открытый вопрос, несмотря на то, что основные этапы этого процесса формализуемы. Специалисты в той или иной области информатики, в области управления СУБД могут осуществлять подобную оценку, но высокоточной ее назвать в большинстве случаев нельзя.
При оценке БД нередко системный аналитик наталкивается на труднопреодолимое препятствие – огромный объем и высокая сложность данных. Сделать такую информацию доступной для анализа – одна из наиболее серьезных задач, стоящих сегодня перед системными аналитиками. Автоматическая идентификация и оценка сложности проектов, качественная и количественная оценка риска, документирование информации о рисках, выявление и решение потенциальных проблем, вот тот неполный список задач, который нужно решать в подобных проектах.
Project manager, системный аналитик должны выработать критерии проекта, которые остаются виртуальными, до тех пор, пока их не выразить словами и планом работ. После этого они становятся целью. Подготовив набор технических требования, спецификаций, определив потенциальные проблемы и сложности, проект становится реальным, а не потенциальным. Жизненно важно придавать проектам максимально возможную определенность. Разработка четкой концептуальной схемы проекта приводит к упрощению понимания сложности проекта до более низких базовых понятий, уровней. Это дает возможность сформулировать цели и проблемы на понятном, для всех участников конверсионной команды, языке. Многие проекты инициируются без должного понимания конвертируемых структур, на решение которых нацелен проект. Мне знакомы некоторые проекты, которые намного превысили первоначальную смету и сроки окончания работ вследствии недостатка понимания членами проектной группы стоящих перед ними целей и неправильного распределения работ внутри команд и неточными оценками временных затрат.
Если в фазе разработки структуры работ что-то пропущено или не доработано, то все недоработки оказываются лишенными необходимого финансирования и места в графике. В результате, осуществление проекта почти наверняка будет происходить с нарушением заданных сроков и превышением сметы расходов, а также с нарушением порядка работ. Этого хаоса в значительной мере можно избежать за счет внедрения специализированных экспертных систем, что позволит исключить вероятность пропуска основных его элементов.
Разработка экспертной системы, основная задача которой – анализ(оценка) всех сущностей баз данных, позволит решить нам ряд проблем, которые были обозначены выше и ставятся на начальном этапе конвертационного жизненного цикла конвертируемых приложений.

Проектные риски

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

  • Сможем ли мы закончить проект вовремя?
  • Не будет ли превышена смета затрат?
  • Возникнут ли такие условия, которые помешают реализации проекта?
  • Будет ли конечный продукт удовлетворять поставленным требованиям?

Управление рисками – это наука и искусство. Оно включает в себя идентификацию и анализ неблагоприятных событий, а также выработку реакции на их наступление. Цель управления рисками – это прогнозирование возможных рисков и поиск путей смягчения последствий их воздействия.
Было бы неправильно говорить, что любой риск имеет неблагоприятный исход. Неопределенность может породить и благоприятные последствия. Неопределенность – это совокупность неизвестных вероятностей исходов событий в будущем, которые могут быть как благоприятными, так и неблагоприятными. Соответственно у нас появляются дополнительные возможности при благоприятном исходе события и риск при негативном стечении обстоятельств. Благоприятная возможность и риск взаимосвязанные понятия, являющиеся следствием друг друга.
По мере реализации проекта и преобразования неопределенностей в реальные факты, вероятность риска и благоприятных возможностей проекта в целом снижается. Однако одна незначительная на первый взгляд неопределенность может повлиять на временные показатели проекта в разы, как в положительную, так и в отрицательную стороны.
Как правило, руководители проектов уделяют высокую степень заинтересованности к рискам. Их интересует потенциальная серьезность убытков, возможность управлять рисками, какие могут быть последствия и способность их оценить. Оптимизм здесь нужно всячески избегать. Полагаться на навыки высоко профессиональной команды правильно, но не в убыток проекту. При анализе рисков мы должны задавать себе следующие вопросы: встречался ли ранее такой риск, существуют ли доказательства отрицательного исхода риска, имеются ли эксперты способные решить данную проблему, есть ли альтернативные решения выхода из ситуации? Опасно, а не редко и неправильно использовать только один наилучший подход к решению проблемы. Фактически до тех пор, пока не будет достигнуто более полное понимание проблемы, представляется вполне вероятным, что реализуемый проект будет служить не той цели, для достижения которой он был предназначен.
Приведу отрицательную сторону неучета рисков проекта. Итоговая прибыль крайне низка и не стоит затраченных усилий. И это в лучшем случае, хуже, если прибыли нет вообще, а есть только убытки. На этапе планирования выгоды определены недостаточно четко и т.д.
Система принципов управления рисками:

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

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

Si – Оценка риска для i-го показателя.
cij –Вектор риска, весовой коэффициент i-го показателя, j-го вида.
eij – Вектор наличия риска, пороговая нелинейная функция.
j = 1..N, N – количество рисков. Каждый показатель состоит из набора возможных рисков.
Анализ рисков позволяет выявить риски присущие конкретному проекту и предусмотреть меры по его снижению.
Изучение риска включает в себя: анализ структур таблиц, для определения неправильной нормализации, анализ некорректных имен сущностей, проверку кода скриптов, для выявления логиго-семантических неточностей, оценку сложности дизайна форм, для выявления дизайнерских трудозатрат и т.д.
Эти особенности баз данных оказывают влияние на формирование системы проектных рисков. Кроме этих рисков специфическими в области информационных технологий являются риски неоткрытия потенциальной проблемы; риск связанный с неточным определением характеристик объектов базы данных, риск связанный с навыками и качествами проектной команды; риск, вызванный вероятностью возникновения форс-мажорных ситуаций.
Все участники проекта заинтересованы в том, чтобы снизить вероятность принятия неточного решения, избежать провала проекта или хотя бы значительных убытков. Для этого участники проекта, эксперты в области баз данных вынуждены учитывать все возможные последствия реализации проекта в динамичном пространстве информационных технологий.
Таким образом, назначение анализа риска заключается в том, чтобы дать потенциальным партнерам необходимую информацию для принятия решений о целесообразности участия в проекте и предусмотреть меры по защите от возможных финансовых потерь.
Анализ риска можно разделить на два этапа: качественный и количественный. Главная задача качественного анализа – определить этапы работ, при выполнении которых возникают риски, выявить потенциальные проблемные области риска. Количественный анализ риска определяет численное количество рисков и риска проекта в целом. Количественный анализ рисков значительно сложнее и базируется на теории вероятностей, математической статистике, теории исследования операций.

Способы снижения проектных рисков

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

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

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

Система поддержки принятия решений в оценке рисков проектов

 

Задача конвертации баз данных с одной системы управления на другую существует давно. Специалисты в этой области уже обладают всеми знаниями о структуре работ и потенциальных рисках, которые могут возникнуть в тот или иной момент. Методы управления известными рисками весьма разнообразны и полностью зависят от экспертов способных их решать. Наличие разных методов диктуется возможностью вырабатывать разные программные решения, суть которых зависит от предпочтений разработчиков программного обеспечения.
На этапе концептуализации проекта системный аналитик вырабатывает схемы работ, анализирует структуру базы, выявляет сложности. Являясь экспертом в области переноса БД аналитик понимает те структуры, где могут возникнуть такие ситуации, для решения которых необходимо прибегнуть к неадекватным методам обработки таких исключений. Однако для их обозначения необходимо их определить. В одних БД могут быть одни риски, в других другие. Вероятность того, что какая-то часть сложных структур порождающих риски будет пропущена зависит от многих показателей. Например, физическая утомляемость, ослабление внимания и ряд других показателей. Человеческий фактор на этапе оценке конвертируемых приложений неприменно себя покажет. Автору известны многие проекты, где сложные ситуации были обнаружены только на этапе реализации проекта переноса, а не на этапе концептуализации.
Необходимость разработки специализированной экспертной системы является острой задачей, в отсутствии которой четкой уверенности в оцененных приложениях не будет никогда.
Автором была разработана ЭС AnalyseEase, предназначенная для анализа сущностей DataEase БД, оценки их сложности и выработки рекомендаций по управлению проектами конвертации. В рамках DataEase БД, AnalyseEase рассматривает перенос последних в разнородные СУБД, такие как MS SQL, Oracle и др.
AnalyseEase имеет собственную базу данных для хранения мета-структур исследуемого приложения – описание таблиц, связей между ними, используемые в них типы полей, программы, процедуры и функции по работе с данными, разнотипные меню управления и т.д. и т.п.
База данных для хранения мета-структур, это хранилище данных являющееся образом DataEase БД, его мета-описание, представляющее все ее сущности в удобном для работы виде, на основе которых строятся процессы анализа данных.
Два основных положения хранилища:

  • информация в хранилище организована вокруг базовых понятий, используемых в системе управления DataEase и в большинстве случаев совпадающая с понятиями других СУБД;
  • “сырые” данные собираются при общении с экспертом и при помощи неинтегрированных приложений. Затем они очищаются от ошибок, агрегируются и представляются в виде, понятном аналитику.

Одной из основных задач ЭС является анализ процедур и функций приложения. ЭС обладает принципами раскопки данных, методами обнаружения знаний в данных, технологиями поиска логических закономерностей.
Нетривиальность разыскиваемых трудностей в процедурах важное положение AnalyseEase. Это означает, что найденные процедуры отражают неочевидные, неожиданные знания, составляющие так называемые скрытые знания. Суть этого поиска во встроенной базе знания (БЗ), которая хранит в себе глубинные знания специалистов. Достоинством БЗ является возможность пополнять свою базу без вмешательства программиста.
Встроенная система объяснения по запросу раскладывает все свои суждения в понятном виде. Система обеспечивает, на основе имеющихся данных в БД, информацией аналитика необходимой для стратегического планирования структуры работ. Позволяет строить отчеты по исключениям, анализу данных и анализу, основанному на системе правил.

Заключение

 

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

Литература

 

  1. Представление знаний в объектно-ориентированной базе. International Conference «Intelligent Systems and Information Technologies in Control». IS&ITC-2000. St.Petersburg/Pskov. SPbSTU Publishers 2000. (Pskov, June 19-23, 2000).
  2. Moving Live DataEase for DOS Applications to DataEase for Windows. Ilia A. Semenov and others. Dialogue — The magazine for DataEase Users. June 2002.
  3. Project Management Handbook. Jeffrey K. Pinto, Editor. 1998 by Jossey-Bass Inc. San Francisco.
  4. Управление проектами. Дж. К. Пинто. СПб.: Питер, 2004.
  5. В. Дюк, А. Самойленко. «DataMining», Санкт-Петербург, «Питер», 2001.
Share and Enjoy:
  • Добавить ВКонтакте заметку об этой странице
  • Мой Мир
  • Facebook
  • Twitter
  • LiveJournal
  • MySpace
  • В закладки Google
  • Google Buzz
  • Яндекс.Закладки
  • LinkedIn
  • Technorati
  • Digg
  • MisterWong.RU
  • Memori.ru
  • Сто закладок

Tags: