RUP и другие методологии разработки ПО
Часть 3. Как выбирать методологию?
В первой части статьи мы определили ключевые показатели, по которым имеет смысл сравнивать методологии, во второй — проанализировали некоторое количество методологий. Теперь пора решить, какая же методология лучше.
Если вернуться к аналогии с выбором цифровой фотокамеры, то можно сказать, что мы уже разобрались, по каким принципиальным параметрам камеры отличаются друг от друга, прочитали обзор, в котором для каждой камеры указаны размер изображения в мегапикселах, характеристики объектива и количество программ съемки. Теперь мы хотим найти ответ на самый главный вопрос: что же все-таки выбрать?
В случае и с камерой, и с методологией ответ будет одинаков: не следует гнаться за экстремальными характеристиками, нужно выбрать то, что отвечает вашим задачам. Для этого при выборе методологии надо решить, какую степень формализма вы хотите обеспечить и насколько итерационным должен быть проект.
Сколько формализма нужно?
Польза документации
В информационной индустрии долгое время считалось, что чем больше тщательно оформленной документации выпускается в ходе выполнения проекта, тем лучше — значит, тем тщательнее проработан проект, тем полнее сохраняются и передаются в группу сопровождения знания и проектные решения по проекту и тем проще в дальнейшем сопровождать продукт.
Однако, как оказалось, это не совсем так. Впрочем, причину, по которой возникали проблемы, сначала определили, как это нередко бывает, неправильно. Решили, что вопрос только в объеме документации — вот если бы она была компактнее… Почитайте старые (да, десятилетние для информационных технологий — это даже очень старые) руководства по структурному анализу и проектированию — сколько там радости по поводу того, что удалось заменить толстые тома компактными диаграммами! Действительно, одна удачная диаграмма может заменить иногда десяток страниц текста. Документация с большим количеством диаграмм стала более доступной и компактной.
Общение вместо документации
Однако наличие самой лучшей документации спасает не всегда. Разработка идет значительно быстрее, а ошибок совершается гораздо меньше, если есть не только документация, но и человек, который знает, что в ней написано, и может объяснить это всем заинтересованным лицам. Как постоянный контакт с заказчиком, позволяющий быстро получить ответ на любой вопрос, ускоряет работу аналитика, точно так же возможность обратиться непосредственно к аналитику и уточнить детали предложенного им решения ускоряет работу разработчика и так далее по цепочке. Кроме того, подобные контакты дают участникам разработки возможность получить объективную оценку качества предложенных ими решений и накопить весьма полезный профессиональный опыт. Не следует также забывать, что разработка и рецензирование документации являются весьма трудоемкими операциями, требующими существенных ресурсов и времени.
Таким образом, формальная документация проекта не является единственным и, более того, самым быстрым каналом передачи информации между участниками разработки. Использование других возможностей, прежде всего непосредственного контакта, позволяет существенно ускорить обмен информацией, уменьшить затраты на разработку документации и сократить сроки разработки. Однако увлечение личным общением и пренебрежение формальным документированием и другими формализованными процедурами ведет к потере управляемости проектом. Превышение некоторого объема сведений, который участники разработки должны помнить, или удлинение периода, в течение которого их нужно помнить, приводит к росту количества ошибок и соответственно затрат на их исправление.
Как выбирать?
К сожалению, не существует единого оптимального уровня формализации процесса. Он должен определяться для каждого конкретного проекта и может меняться в очень широком диапазоне. Из основных факторов, влияющих на оптимальный уровень формализации процесса, можно назвать:
- масштаб проекта — чем больше людей участвует в проекте, тем более формально он должен вестись;
- критичность проекта — проекты, в которых ошибки могут приводить к тяжелым последствиям, вплоть до гибели людей, должны проводиться гораздо более формально, чем те проекты, в которых ошибки приводят только к временным неудобствам (как, например, при разработке домашней интернет-странички);
- распределение участников — чем компактнее расположены участники, чем легче им общаться между собой, тем менее формализованным может быть проект;
- новизна проекта — если разработчики используют новые технологии и мало знакомы с предметной областью, то следует более тщательно прорабатывать проектные решения — соответственно это должно происходить более формально. Однако если над проектом работает небольшая группа высококвалифицированных программистов, возможно, более предпочтительным будет тщательное оформление уже отработанных решений перед их тиражированием;
- требования заказчика — существенно различаются в зависимости от отрасли и статуса организации-заказчика. Как правило, эти требования выше для государственных предприятий;
- ожидаемая долговечность проекта — если разрабатываемое для конкретного заказчика ПО планируется через пару лет заменить новым, то вряд ли имеет смысл тратить много сил на документацию, которая могла бы значительно удешевить длительный процесс сопровождения ПО. Если же срок жизни проекта предполагается достаточно длинным, то без хорошей документации не обойтись. Автору приходилось иметь дело с системой, созданной более 15 лет тому назад и продолжающей эксплуатироваться, — в такой ситуации поддержка системы в работоспособном состоянии без качественной документации была бы просто невозможна.
Таким образом, если ваша организация достаточно велика (больше десятка разработчиков) и если вы выполняете проекты для различных отраслей или для систем разного уровня критичности — желательно выбирать для каждого проекта свой оптимальный уровень формализации.
Сколько итераций потребуется?
Еще раз об итерациях
Сколько или, точнее, какой длительности итерации лучше использовать? Вопреки первому предположению, более показательным параметром, чем количество итераций, в данном случае является именно длительность итерации.
Итерация — это не просто календарный срок, это определенный этап выполнения проекта:
- на который составляется детальный план;
- который завершается выпуском итогового релиза (в ходе итерации сборка программы может проводиться еженедельно или даже ежедневно, но итоговый релиз выпускается единожды в конце итерации);
- по завершении которого могут меняться приоритеты дальнейшей разработки;
- по окончании которого производится оценка используемого процесса и, при необходимости, вносятся соответствующие изменения.
Польза и вред итераций
Итерации в процессе разработки позволяют:
- контролировать и корректировать выполнение проекта (необходимость продемонстрировать работающий релиз в конце итерации не позволяет программисту ограничиться типичным ответом о 90%-ной готовности класса или метода);
- более эффективно работать с изменяющимися требованиями (например, осуществляя анализ изменившихся требований и решая, что будет переработано в продукте в ходе подготовки к очередной итерации);
- более эффективно оперировать рисками, корректируя планы очередной итерации в соответствии с текущим состоянием списка наиболее приоритетных рисков;
- на ранних этапах оценивать потенциальные характеристики системы (поскольку наличие работоспособного релиза позволяет начать тестирование системы с самых первых итераций);
- не тратить время на разработку бесполезных детальных планов на далекую перспективу (если требования к проекту могут существенно меняться раз в месяц, а принципиальная архитектура еще не выбрана, стоит ли детально планировать работы на следующий квартал?).
Однако проведение итерации — это определенные дополнительные расходы на подведение итогов и (пере)планирование, размер которых зависит от числа и распределения участников проекта. Для группы из пяти человек, работающих в одной комнате, подведение итогов итерации может занять час, а для группы из сотни разработчиков, работающих в разных городах, на сбор и подведение итогов может уйти пара недель, и еще почти столько же уйдет на доведение до их сведения новых планов и организацию работы по ним.
Как выбирать?
Таким образом, при выборе количества и длительности итераций, как и при выборе степени формализма, нужно искать оптимальное решение. Продолжительность итерации должна быть тем больше, чем больше команда и чем шире география ее членов, и тем меньше, чем выше неопределенность проекта, например используется новая технология или нестабильны требования к проекту.
Еще одним фактором, влияющим на выбор длительности итерации, является применение инструментальных средств. Так, средства управления изменениями и конфигурациями и средства автоматизации тестирования позволяют уменьшить не только трудоемкость процесса разработки, но и накладные расходы на подведение итогов итерации.
На основании опыта собственных разработок, а также собранной статистики IBM Rational рекомендует выбирать продолжительность итерации в диапазоне от одной до восьми недель. Итерации длительностью восемь недель, как правило, хватает даже для команд численностью порядка ста человек.
Подведем итоги
Итак, мы рассмотрели показатели, характеризующие различные методологии разработки ПО, провели сравнение ряда известных методологий разработки и требований ГОСТов по этим показателям и разобрались, как оценить, какие значения показателей нужны для того или иного проекта.
Заодно мы выяснили, что RUP является одной из наиболее универсальных методологий. Она позволяет в очень широких пределах менять как степень формализма разработки, так и его итеративность.
Хорошо освоенная RUP позволяет разработать универсальный процесс, который можно успешно использовать в различных проектах. Для этого достаточно освоить RUP и способы ее настройки, чтобы иметь в запасе несколько вариантов процесса разработки для разных типов проектов.
RUP также позволяет легко удовлетворять требования ГОСТов и обеспечивает сертификацию организации на весьма высокий уровень модели CMM.
 |
|
