Эволюция процессов разработки программного обеспечения

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

Классической считается каскадная модель разработки или модель водопада [14], схема которой представлена на рис. 9.

Следуя каскадной модели, разработчик переходит от одной стадии к другой строго последовательно. На этапе анализа формируется список требований к программному продукту. Далее на этапе проектирования создаются документы, подробно описывающие способ и план реализации указанных требований. Разработанная проектная документация используется при реализации программного кода. Полученные модули продукта тестируются автономно (т.н. Unit-тестирование). Потом производится их интеграция: предварительно проверенные компоненты объединяются во все более сложные комбинации (тестирование сопряжений), которые тестируются до тех пор, пока не будет собрана вся система и не произведена ее комплексная проверка. Затем происходит сдача продукта заказчику, его внедрение и поддержка – мелкие доработки и устранение ошибок в процессе эксплуатации.

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

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

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

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

Прототипы могут использоваться только для проверки тех или иных свойств разрабатываемой системы, тогда они называются вре́менными. Другие прототипы могут лечь в основу будущей системы или ее отдельных компонент и при постепенном наращивании функциональности превратятся в окончательный продукт. Такие прототипы называют эволюционирующими, а соответствующий процесс разработки – инкрементным. На практике рассмотренные подходы могут комбинироваться, например, как показано на рис. 10.

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

Существует множество вариаций процесса разработки программ. Наверное, у каждой фирмы он свой и, кроме того, изменяется от проекта к проекту. Это не снижает значимости унифицированных формализованных процессов разработки. Такие процессы разрабатывались и продолжают разрабатываться. Примерами могут быть: унифицированный процесс разработки программного обеспечения USDP (The Unified Software Development Process) [13], методология разработки программного обеспечения RUP (Rational Unified Process), созданная компанией Rational Software и др. Процесс проектирования формализуется не только для программного обеспечения, но и для других видов продуктов. Пример – свод знаний по управлению проектами PMBoK (Project Management Body of Knowledge) Института управления проектами PMI (Project Management Institute).

Громоздкие формализованные процессы проектирования обладают преимуществом в крупномасштабных проектах, где необходимо налаживать совместную работу множества организаций. Однако было замечено, что в проектах среднего и малого масштабов систематически более стабильные результаты проектирования демонстрировали небольшие группы разработчиков, использующих гибкие облегченные методики. Таких методик множество: т. н. экстремальное программирование, DSDM (Dynamic Systems Development Method), Scrum и др. Представители перечисленных направлений в 2001 году выпустили «Манифест гибкой методологии разработки программного обеспечения» (более кратко – Agile), в котором сформулировали следующие ключевые идеи:

- личности и их взаимодействия важнее, чем процессы и инструменты;

- работающее программное обеспечение важнее, чем полная документация;

- сотрудничество с заказчиком важнее, чем контрактные обязательства;

- реакция на изменения важнее, чем следование плану.

Манифест Agile выдвигает также 12 принципов разработки:

- удовлетворение клиента за счёт ранней и бесперебойной поставки ценного программного обеспечения;

- приветствие изменений требований даже в конце разработки (это может повысить конкурентоспособность полученного продукта);

- частая поставка рабочего программного обеспечения (каждый месяц или неделю или ещё чаще);

- тесное, ежедневное общение заказчика с разработчиками на протяжении всего проекта;

- проектом занимаются мотивированные личности, которые обеспечены нужными условиями работы, поддержкой и доверием;

- рекомендуемый метод передачи информации – личный разговор (лицом к лицу);

- работающее программное обеспечение – лучший измеритель прогресса;

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

- постоянное внимание улучшению технического мастерства и удобному дизайну;

- простота – искусство не делать лишней работы;

- лучшие технические требования, дизайн и архитектура получаются у самоорганизованной команды;

- постоянная адаптация к изменяющимся обстоятельствам.

Можно заметить, что принципы гибкой разработки Agile находятся в определенном противопоставлении формализованным моделям типа водопада. Упор делается на личностные качества и заинтересованность разработчиков, их непосредственное взаимодействие, не обремененное формальностями и лишней документацией. Как правило, разработчики (оптимально около 10 человек) находятся в одном офисе, где также располагается и заказчик. Гибкие процессы разработки очень эффективны в ситуациях, когда крайне ограничены сроки и ресурсы (отсюда термин – экстремальное программирование).

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

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

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