Процесс быстрой разработки ПО, предложенный в 2001 г. некоммерческой организаций энтузиастов Agile Alliance, является смелым новым подходом к производству ПО. В Manifesto of Agile Alliance дух быстрой разработки представлен четырьмя рекомендациями:

1. Индивидуальные характеристики и взаимодействия процессов и инструментальных средств.

2. Рабочее ПО с полной документацией.

3. Сотрудничество с клиентами после заключения контракта.

4. Определение, что нужно изменить после планирования.

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

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

«Обычный» анализ требований заменен в быстрой разработке историями пользователей, где клиент отмечает особенности, которые, по его мнению, система должна поддерживать. Коллектив разработчиков оценивает, сколько потребуется времени для реализации каждой истории, и сколько реализация каждой истории будет стоить. После этого клиент может выбрать те истории, которые будут реализованы на первой и последующих итерациях. «Обычные» виды проектирования систем и их реализация заменены в быстрой разработке комбинацией приемочных испытаний, рефакторинга и управляемой тестированием разработки. Приемочные испытания – это специальные программы, через которые разрабатываемая прикладная программа должна пройти, чтобы быть принятой клиентами. Этот процесс называется «разработкой, управляемой тестированием» (Test-Driven Development – TDD) или программированием намерений (Intentional Programming – IP) – разработчик программирует свои намерения по приемочным испытаниям до того, как использует их. Этому подходу сопутствует частое использование рефакторинга (refactorings) – усовершенствования в структуре системы без изменения ее поведения.

Быстрая разработка поддерживает и другие концепции типа парного программирования и коллективной собственности. Все программирование выполняется парами программистов — двумя программистами, работающими вместе на одной рабочей станции. Один программист пишет код, а другой наблюдает за процессом и задает вопросы. Роли меняются всякий раз, когда один из программистов хочет «поставить точку с помощью клавиатуры». Пары программистов также меняются местами, по крайней мере, один раз в день. Результатом является коллективная собственность. Никто индивидуально не владеет кодом. Считается, что высокий дух коллективизма и желание выдать продукт перевесят любые требования индивидуальной ответственности.

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

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

Быстрая разработка отличается больше в методах, чем в подходе к итеративной разработке. Ее главный представитель — extreme Programming (ХР). Как и с MDА-подходом, будущее покажет, сможет ли быстрая разработка применяться к большим и сложным системам. Главная опасность, стоящая перед сторонниками быстрого жизненного цикла – риск окончания работы с неудачно созданной и принятой моделью, в которой ПО слеплено без учета заданных требований к проекту.

5.4 Инструментальные средства моделирования систем

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

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

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

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

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

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

Диаграммы и текстовые описания моделей размещаются в хранилище проекта. Хранилище – главный компонент любого инструмента визуального моделирования. Это – БД продуктов проекта. Термин «база данных» (БД) подразумевает сохраняемое и интегрированное размещение данных, допускающее параллельный доступ к ним многих пользователей. Разработка ПО – совместное усилие многих разработчиков, и все они должны иметь параллельный доступ к моделям разработки. Большинство инструментальных средств визуального моделирования использует всю мощь технологии БД или даже применяет коммерческие системы управления БД (СУБД), чтобы реализовать их хранилища. Традиционно средства визуального моделирования называются CASE-инструментами (computer assisted software engineering – автоматизированная программная инженерия).