Сравнение RUP и других методологий разработки ПО - А сколько формализма нужно?

А сколько формализма нужно?

Долгое время в информационной индустрии бытовало мнение, что чем больше тщательно оформленной документации выпускается в ходе выполнения проекта — тем лучше. Значит, тем тщательнее проработан проект, тем полнее сохраняются и передаются в группу сопровождения знания и проектные решения по проекту и тем проще в дальнейшем сопровождать продукт. Однако оказалось, что это не совсем так. Впрочем, причину проблем сначала, как это нередко бывает, определили не совсем точно. Решили, что вопрос только в объеме документации. Вот, если бы она была компактнее… Почитайте руководства по структурному анализу и проектированию. Сколько там радости по поводу того, что удалось заменить толстые тома компактными диаграммами! И действительно, одна удачная диаграмма может заменить иногда десяток страниц текста. Документация с большим количеством диаграмм стала доступней и компактней. Но и наличие самой лучшей документации не всегда спасает. Разработка идет значительно быстрее, а ошибок совершается значительно меньше, если помимо документации есть человек, который знает, что в ней написано, и может объяснить это всем заинтересованным лицам. Точно так же, как постоянный контакт с заказчиком и возможность быстро получить ответ на любой вопрос ускоряют работу Аналитика, так же возможность обратиться непосредственно к Аналитику и уточнить детали предложенного им решения ускоряет работу Разработчика и далее по цепочке. Кроме того, такие контакты позволяют участникам разработки получить объективную оценку качества предложенных ими решений и накопить весьма полезный профессиональный опыт. И не надо забывать, что разработка и рецензирование документации являются весьма трудоемкими операциями, требующими существенных ресурсов и времени.

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

• Масштаб проекта. Чем больше людей участвует в проекте, тем более формально он, как правило, должен вестись;
• Критичность проекта. Проекты, в которых ошибки могут приводить к тяжелым последствиям вплоть до гибели людей, должны проводиться существенно более формально, чем те проекты, в которых ошибки приводят только к временным неудобствам (как, например, при разработке домашней интернет странички);
• Распределение участников. Чем компактнее расположены участники, чем легче им общаться между собой, тем менее формализованным может быть проект;
• Новизна проекта. Чем более новые для разработчиков технологии вы используете, чем меньше вы знакомы с предметной областью, тем боле тщательно надо прорабатывать проектные решения, и, соответственно, тем более формально это должно происходить. Однако, при наличии компактной высококвалифицированной группы программистов, прорабатывающих такие решения, вы, возможно, предпочтете тщательно оформлять уже отработанные решения перед тем, как приступать к их тиражированию в проекте;
• Требования заказчика. Они существенно различаются в зависимости от отрасли и статуса организации-заказчика. Как правило, эти требования выше для государственных предприятий;
• Ожидаемая долговечность проекта. Если разрабатываемое для конкретного заказчика ПО предполагается через пару лет будет заменено новым, то вряд ли есть смысл тратить много сил на документацию, которая могла бы значительно удешевить более длительный процесс сопровождения ПО. Зато если срок жизни проекта предполагается достаточно длинным — без хорошей документации не обойтись. Автору приходилось иметь дело с системой, созданной более 15 лет тому назад и продолжающей эксплуатироваться. В такой ситуации без качественной документации поддержка системы в работоспособном состоянии была бы просто невозможна.

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

Кроме того, с точки зрения обеспечения требуемого уровня формализации разработки, RUP можно использовать, если от вас требуется соблюдение ГОСТов. Он позволяет без труда обеспечить разработку всех необходимых документов. Также RUP вполне пригоден, если вы хотите выполнить требования второго и третьего уровня CMM или CMMI.