Почему в процессе разработки возникают риски

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

Ситуация усугубляется тем обстоятельством, что проектирование – никак не точная наука. Возьмём проектирование баз данных, одну из технологий предшествовавших объектно-ориентированному проектированию. Как замечает Хаврискевич: «Хотя всё выглядит просто и ясно, неизбежно примешивается изрядная доля личного представления о важности различных объектов на предприятии. В результате процесс проектирования не воспроизводим: разные проектировщики могут создавать разные модели одного и того же предприятия».

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

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

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

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

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

Прототипная модель делает не существенным тот факт, что начальные требования для программной системы были заданы не точно. Она позволяет оценить реализуемость программной системы или некоторой её части, не доводя процесс разработки до конца, что достигается построением прототипа. Это снижает вероятность риска неправильного понимания разработчиками требований к программному продукту на начальных этапах проектирования. Снижает вероятность того, что придётся «сделать всё заново», что в большинстве случаев невозможно, из-за временных или финансовых ограничений.

Например, для объектно-ориентированной системы главная обязанность менеджера программного продукта, в конечном счёте, – управление как техническим, так и нетехническим риском. Технический риск для объектно-ориентированной системы содержится в решении таких проблем, как выбор структуры наследования классов, обеспечивающий наилучший компромисс между удобством и гибкостью программного продукта. Серьёзное решение приходится также принимать при выборе механизмов упрощения архитектуры и улучшения эффективности. Нетехнический риск содержит в себе такие вопросы, как контроль своевременности поставки программных продуктов от третьих фирм или регулирование отношений заказчика и разработчиков, что необходимо для выяснения реальных требований к системе на стадии анализа.