В данный момент нет необходимости разрабатывать методологию разработки программного обеспечения (ПО) "с нуля". Существует широкий выбор готовых методологий на все случаи жизни. И, хотя, практически каждый достаточно опытный руководитель разработки программного обеспечения со временем находит свои, более удобные для решаемых задач, методы, все же за основу берется одна из стандартных, общепризнанных методологий.
Как же выбрать нужную методологию разработки ПО из такого множества вариантов? По каким параметрам можно оценить различные методологии и оценить их эффективность для решаемых задач? Основными метриками, обычно, называют уровень формализма и модель жизненного цикла проекта.
Различные модели жизненного цикла могут изменяться от итеративной до каскадной разработки и подробно описаны на странице
этапы выполнения работ.
По степени формализма методологии могу отличаться по количеству создаваемых документов, степени их актуальности, аккуратности, полноты заполнения и формальности процедур рецензирования.
Неконтролируемая разработка - имеет 2 основных проявления. Когда правил разработка ПО нет вообще, либо когда они не выполняются. Чаще всего используется новичками в разработке либо коллективами, в которых разработка программ не является профильной деятельностью. Обычно основывается на личном опыте главного разработчика либо руководителя разработки. Степень формализма низкая. Документирование разработки может отсутствовать как класс, либо заканчиваться на комментировании кода и рисовании пары картинок с общей структурой проекта. Модель жизненного цикла может быть любой, либо даже смешением нескольких моделей.
Гибкие методологии (
Agile) - в последние годы получили активное развитие и приобрели большую популярность. Основываются на 12 основных принципах:
1. Главным приоритетом является удовлетворение потребностей заказчика за счет ранней и непрерывной поставки работоспособного программного обеспечения.
2. Приветствуются меняющиеся требования, даже на поздних стадиях разработки. Гибкие процессы используют изменения как средство получить конкурентные преимущества для заказчика.
3. Поставлять работоспособное программное обеспечение часто: от раза в несколько недель, до раза в несколько месяцев, отдавая предпочтение коротким интервалам.
4. Представители заказчика (бизнеса) и разработчики должны работать вместе в течение всего проекта.
5. Проекты строятся вокруг мотивированных личностей. Предоставьте им среду и поддержку, в которой они нуждаются, и доверьте им самим сделать работу.
6. Наиболее эффективный способ передачи информации в команду проекта (а также передавать её внутри команды) - это непосредственное живое общение.
7. Основной мерой прогресса проекта является работоспособное программное обеспечение.
8. Гибкие процессы поощряют разработку с постоянной скоростью. Спонсоры проекта, разработчики и пользователи должны быть способны поддерживать постоянную скорость на неограниченной дистанции.
9. Постоянное внимание техническому совершенству и хорошему дизайну увеличивает степень гибкости.
10. Простота - искусство максимизации работы, которую не надо делать, - является существенным фактором.
11. Наилучшие архитектурные решения, требования и дизайн создаются самоорганизующимися командами.
12. Через регулярные промежутки времени команда должна проводить анализ того, как стать более эффективной и улучшать свой процесс работы.
Таким образом, методология является ориентированной на итеративную разработку и минимальную формализацию процесса.
Число методологий, относящихся к этой группе, велико. Самые известные из них
eXtreme Programming (
XP) -
экстремальное программирование,
Crystal Clear и
Feature Driven Development (
FDD) -
функционально-ориентированная разработка.
Экстремальное программирование - пожалуй, наиболее известная из гибких методологий. Состоит из 12 основных принципов: игра в планирование, переработки кода (refactoring), короткие релизы, метафоры, простой дизайн, разработка «тестами вперед», коллективное владение кодом, парное программирование, 40-часовая рабочая неделя, постоянное присутствие заказчика и стандарты кода. При использовании XP тщательное планирование разработки ПО заменяется на постоянной присутствие заказчика, готового ответить на любые вопросы разработчиков и постоянную переработку (рефакторинг) кода. Низкая формализация разработки обычно не идет дальше хорошего комментирования кода, что позволяет сократить большое количество времени разработки, а следовательно, снизить общую стоимость разработки. При этом существенное внимание уделяется тестированию. Зачастую для каждого модуля системы сначала пишется тест, который продолжает выполняться на протяжении всей разработки после любого изменения кода. Впрочем, не все принципы являются строго обязательными. Например 40-часовая рабочая неделя и парное программирование носят второстепенный характер.
Crystal Clear - методология, позволяющая менять степень формализации процесса разработки в зависимости от критичности задач и количества участников разработки. Основные особенности: итеративная инкрементная разработка, автоматическое регрессионное тестирование, пользователи привлекаются к активному участию в проекте, состав документации определяется участниками проекта, как правило, используются средства контроля версий кода. Ориентирована на поддержание естественных привычек разработчиков. Считается, что если в организации не используется какая-то определенная методология, то достаточно квалифицированный коллектив рано или поздно сам естественным образом придёт к этой
Crystal Clear.
Feature Driven Development (
FDD) - функционально-ориентированная разработка. Разработка состоит из 5 основных этапов: разработка общей модели, составление списка необходимых функций системы, планирование работы над каждой функцией, проектирование функций, конструирование функций. Работа над проектом происходит итеративно, частый выпуск версий, каждая из которых реализует определенный набор функций.
SCRUM - методология, предназначенная для небольших команд (до 10 человек). Весь проект делится на итерации (спринты) продолжительностью 30 дней каждый. Выбирается список функций системы, которые планируется реализовать в течении следующего спринта. Самые важные условия - неизменность выбранных функций во время выполнения одной итерации и строгое соблюдение сроков выпуска очередного релиза, даже если к его выпуску не удастся реализовать весь запланированный функционал. Руководитель разработки проводит ежедневные 20 минутные совещания, которые так и называют - scrum, результатом которых является определение какие функции системы были реализованы за предыдущий день, с какими сложностями столкнулись и что планируется сделать за следующий день. Такие совещания позволяют постоянно отслеживать ход проекта, быстро выявлять возникшие проблемы и оперативно на них реагировать.
Разработка по ГОСТ не является методологией разработки ПО. ГОСТы не описывают сам процесс разработки, а только формулируют предъявляемые к нему требования. В настоящее время используются немного устаревшие, но все еще актуальные ГОСТы 19 и 34 серии, а так же более новый ГОСТ 12207. Следуя ГОСТам разработку следует разделить на несколько строго определенных этапов, по завершении каждого из которых составляется достаточно большая по объему и строго форматизированная документация. Таким образом, разработка программного обеспечения по ГОСТам приводит к каскадному подходу и высокому уровню формализации формализованной разработки. В последнее время такой подход имеет все меньшую популярность и используется в основном для государственных заказчиков.
Rational Unified Process (
RUP) — методология разработки программного обеспечения, созданная компанией Rational Software. В основе методологии лежат 6 основных принципов:
Компонентная архитектура, реализуемая и тестируемая на ранних стадиях проекта.
Работа над проектом в сплочённой команде, ключевая роль в которой принадлежит архитекторам.
Ранняя идентификация и непрерывное устранение возможных рисков.
Концентрация на выполнении требований заказчиков к исполняемой программе.
Ожидание изменений в требованиях, проектных решениях и реализации в процессе разработки.
Постоянное обеспечение качества на всех этапах разработки проекта.
Использование методологии
RUP направлено на итеративную модель разработки. Полных жизненный цикл программы состоит из 4 фаз: