Анализ и управление риском. Роль рисков при разработке программного обеспечения

Страницы работы

Содержание работы

5. АНАЛИЗ И УПРАВЛЕНИЕ РИСКОМ

5.1 Рисков Программного обеспечения

5.2 Идентификация Риска

5.3 Проектирование Риска

5.4 Уменьшение Риска, Контроль, И Управление

Роль рисков при разработке ПО можно охарактеризовать следующей цитатой:

«В то время как бесполезно устранять риск, сомнительно их минимизировать, просто необходимо, чтобы те риски, которые имеют место были правильными рисками»

5.1 РИСКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

Хотя были значительные дебаты о надлежащем определении для программного риска, есть общее соглашение, что риск всегда включает две характеристики:

·  Неопределенность - риск может или не может случиться; то есть нет 100% вероятных рисков.

·  Потеря - если риск становится действительностью, нежелательные последствия или потери, которые будут иметь место.

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

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

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

Деловые риски угрожают жизнеспособности программного обеспечения быть построенной. Деловые риски часто подвергают опасности проект или программу. Кандидаты на лучшие пять деловых рисков - (1) разработка превосходное программа или система, которую никто действительно не хочет (рыночный риск), (2) разработка программы, которое больше не вписывается в полную деловую стратегию для компании (стратегический риск), (3) разработка программы, которое коммерческая сила не понимает, как продать, (4) потеря поддержка старшего управления из-за изменения{замены} в центре или изменении{замене} в людях (риск управления), и (5) потеря, бюджетная или обязательство персонала (риски бюджета). Чрезвычайно важно обратить внимание, что простая классификация будет не всегда работать. Некоторые риски просто непредсказуемы заранее.

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

5.2 ИДЕНТИФИКАЦИЯ РИСКА

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

Есть два отличных типа рисков для каждой из категорий: родовые риски и определенные изделием{программой} риски. Общие риски - потенциальная угроза каждому программному проекту. Определенные программой риски могут быть идентифицированы только теми с ясным пониманием технологии, людей, и среды, которая является определенной к проекту под рукой. Чтобы идентифицировать определенные изделием{программой} риски, проектный{строительный} план и программное утверждение{заявление} возможностей{контекста} исследованы, и ответ на следующий вопрос развит: "Что специальные характеристики этого изделия{программы} могут угрожать нашему проектному{строительному} плану? "

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

·  Размер изделия{программы} - риски, связанные с полным размером программного обеспечения, которое будет построено или изменен.

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

Похожие материалы

Информация о работе