Андон Ф.И., Коваль Г.И., Коротун Т.М., Лаврищева Е.М., Суслов В.Ю. Основы инженерии качества программных систем

Подождите немного. Документ загружается.

542 Глава 11

11.7.4. Другие Agile-методологии: DSDM, ASD, FDD

Помимо подробно рассмотренных методологий XP и SCRUM остановимся

кратко на основных принципах других методологий «ускоренной» разработки,

упомянутых в начале главы.

Динамический метод разработки систем (DSDM, от Dynamic Systems

Development Method) предложен в 1995 году ассоциацией поставщиков и экспертов

в области разработки информационных систем в Великобритании (образовавших-

Консорциум DSDM). Считается первым методом, использующим модель быстрой

разработки RAD (от Rapid Application Development) с прототипированием для дос-

тижения целей построения систем в условиях ограниченных ресурсов проекта.

Основные принципы DSDM соответствуют манифесту Agile-альянса:

• Обязательное активное привлечение пользователя.

• Группа разработки имеет право самостоятельно принимать значимые

для проекта решения.

• Акцент на частом выпуске версий.

• Удовлетворение первоочередных бизнес-требований пользователей.

• Итеративная разработка с приращениями, определяемыми в соответст-

вии с текущими бизнес-требованиями.

• Все изменения, сделанные во время разработки, обратимы.

• Базовые требования к системе утверждаются перед началом проекта.

• Тестирование интегрировано в ЖЦ.

• Обязательное взаимодействие и сотрудничество всех ключевых участни-

ков проекта (включая заказчиков и непосредственных пользователей).

Жизненный цикл разработки систем по методу DSDM включает три после-

довательные фазы – предпроектную, проектную и постпроектную, вторая из кото-

рых разделена на 5 стадий, выполняемых циклически. Краткое схематическое опи-

сание ЖЦ при использовании DSDM представлено в таблице 11.14.

Таблица 11.14. Структура ЖЦ при разработке систем по DSDM

Стадия Описание

Предпроектная

фаза

Идентификация возможных вариантов проектов и их ресурсов.

Проектная фаза

1. Анализ

возможно-

стей

Две последовательные взаимодополняющие стадии.

1. Анализ возможности применения DSDM для определенного типа

проекта системы. Идентификация рисков.

2. Анализ

бизнес-

процессов

2. Определение деловых процессов и групп пользователей. Формиро-

вание списка требований и их приоритезация. Определение общего

плана разработки. Выбор ключевых приемов разработки. Определение

архитектуры системы.

3. Итерация

построения

функцио-

нальной

модели

3.1. Визуальное функциональное моделирование. Определение воз-

можностей функционального прототипа, являющегося результатом

итерации.

3.2. Согласование графика разработки прототипа.

3.3. Разработка функционального прототипа.

3.4. Анализ корректности функционального прототипа (тестирование

и/или анализ документации). Определение перечня функциональных

тестов для системы.

Глава 11 543

Стадия Описание

4. Итерация

проектиро-

вания и

програм-

мирования

4.1. Идентификация прототипа проектных решений. Идентификация

функциональных и технических требований. Определение стратегии

реализации системы.

4.2. Согласование графика реализации требований.

4.3. Создание прототипа системы, который может быть передан потен-

циальному пользователю для апробации и тестирования.

4.4. Анализ корректности прототипа системы (тестирование и верифи-

кация решений).

5. Реализация

5.1. Одобрение и подтверждение правильности протестированных про-

ектных решений пользователем. Подготовка документации пользова-

теля.

5.2. Обучение будущих конечных пользователей системы.

5.3. Развертывание протестированной системы в местах установки.

5.4. Анализ влияния системы на бизнес. Основной вопрос – достигнуты

ли цели, поставленные перед открытием проекта. В зависимости от

результата ответа на этот вопрос – переход на постпроектную фазу или

возврат на одну из предыдущих стадий проектной фазы.

Постпроектная фаза

Поддержание эффективного функционирования системы. Сопровож-

дение и развитие

Основная особенность метода DSDM – разделение разработки на фиксиро-

ванные периоды времени с фиксированным финансовым обеспечением стадий и

установленным целевым уровнем качества системы. Не фиксированным остается

объем функциональных возможностей системы. Известно, что реализация полного

набора требований часто приводит к превышению времени и бюджета проекта. В

DSDM требования, которые должны быть реализованы в определенный период,

выбираются из общего списка и приоритезируются по убыванию их значимости.

Действует правило Парето: 20% требований определяют 80% реальных бизнес-

потребностей. Требования из списка, которые не удалось реализовать в установ-

ленный период за выделенные средства, опускаются.

Вторая важная особенность DSDM – прототипирование системы и тестиро-

вание прототипов пользователями, что позволяет с самых ранних стадий проекта

«подключать» пользователей к созданию системы и своевременно определять в ней

узкие места.

Третья особенность DSDM – акцент на качестве системы. Качество достига-

ется за счет тестирования каждой итерации системы. Однако методы тестирования

не оговариваются, а объем тестирования определяется исходя из жестких ресурсов,

что делает метод DSDM мало пригодным для критических систем, требующих

очень тщательного продолжительного тестирования перед выпуском.

Ввиду итеративной природы DSDM очень важными процессами для обеспе-

чения качества системы являются такие процессы ЖЦ, как Управления требова-

ниями и Управления конфигурацией, выполняемые применительно к каждому

функциональному фрагменту (приращению) системы.

Подробнее о методе DSDM можно узнать из электронной энциклопедии по

адресу http://en.wikipedia.org/wiki/DSDM.

Адаптивная разработка ПО (ASD, от Adaptive Software Development).

Ме-

тодология разработана Джимом Хайсмитом (президентом Information Architects,

544 Глава 11

Inc.) специально для экстремальных проектов и базируется на теории сложных

адаптивных систем [39].

В ASD статический цикл разработки ПС - Планирование–Проектирование–

Программирование - заменяется динамическим циклом Размышление–

Взаимодействие–Обучение (Speculate–Collaborate–Learn).

Этот цикл предполагает непрерывное обучение, связан с постоянными изме-

нениями, повторными оценками, попытками предусмотреть неизвестное будущее

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

группой качества и заказчиками.

Размышление не противопоставляется планированию, а учитывает реально

существующую неопределенность при решении сложных проблем, допускает изна-

чальную ограниченность знаний и возможность ошибок, и предполагает большую

долю исследований и экспериментов, как основу Обучения.

Взаимодействие – заменяет традиционный стиль командного управления при

принятии решений. Современные сложные приложения зачастую не «строятся за-

ново» группой индивидуумов, а постоянно эволюционируют, требуя сбора, анализа

и использования больших объемов накопленной информации, что не под силу оди-

ночкам. Группы проектов должны постоянно взаимодействовать, коллективно по-

вышая свою способность к совместному принятию решений. В условиях быстрых

изменений ситуации в проекте принятие основных решений делегируется непо-

средственно командам проекта. Правильность принятых решений, в свою очередь,

также зависит от Обучения.

Качество Знаний, накопленных в результате применения таких практических

приемов, как ретреспективный обзор проекта, является основным показателем пра-

вильности политики Обучения в организации и залогом ее адаптируемости.

Базовый адаптивный цикл разработки приложений по методологии ASD по-

казан на рисунке 11.6.

Открытие

проекта

Планирование

адаптивного

цикла

Параллельная

компонентная

инженерия

Анализ

качества

Финальная

оценка

качества и

выпуск

Цикл обучения

Размышление Взаимодействие Обучение

Рис. 11.6. Адаптивный цикл разработки

Фаза Размышления (Обдумывания) включает следующие семь шагов:

1. Инициирование и открытие проекта. Включает определение назначения,

целей, ограничений, участников, требований; оценки масштаба, сферы действия и

ключевых рисков.

2. Определение временных рамок проекта с учетом оценок (см. п.1).

3. Определение оптимального числа циклов и продолжительности каждого

из них. Выбор зависит от общей продолжительности проекта и степени неопреде-

ленности в оценке ситуации. Для малых и средних проектов (размер<5000 УЕФ)

цикл составляет 1-4 недели.

Глава 11 545

4. Написание целевых утверждений для каждого цикла. Промежуточные

цели, установленные для каждого цикла, и их контроль по вехам проекта, повыша-

ют прозрачность разработки, способствуют своевременному устранению дефектов

и предупреждению ошибок, и, в целом, накоплению знаний о предметной области

и проекте. Верификация и тестирование – неотъемлемая часть каждого цикла раз-

работки.

5. Выделение основных компонентов и их распределение по циклам. Для ви-

зуализации соотношений «компоненты-циклы» при планировании используется

матрица «компоненты-циклы».

6. Выделение технологических и вспомогательных компонентов и их рас-

пределение по циклам. Критерии распределения таковы: продукты каждого цикла

должны быть полезны пользователю, а наиболее высокие риски - устранены как

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

тами, а ресурсы – распределяться рационально.

7. Разработка списка задач. Задачи определяются путем разбиения каждого

компонента на отдельные части. В список добавляются задачи, не касающиеся

компонентов непосредственно.

Фаза Взаимодействия. Предполагает параллельную разработку работоспо-

собных компонентов. Основная задача менеджеров в этой фазе ASD – организация

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

Фаза Обучения. Предполагает анализ качества в конце каждого цикла разра-

ботки. Цели качества устанавливаются и эволюционируют таким образом, что все-

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

меняемых практических приемов анализа, составляющих основу обучения. Цели

анализа – не столько поиск дефектов, сколько изучение потребительских свойств

будущего продукта (этот анализ выполняют заказчики), функциональных и техни-

ческих характеристик продукта (технические обзоры выполняют разработчики),

эффективности функционирования команд и используемых процессов, состояния

проекта и необходимости перепланирования ресурсов перед началом следующего

цикла. Состояние проекта определяется по состоянию каждого компонента, кото-

рый был запланирован на текущий цикл разработки.

Разработка «от функциональных свойств» или управляемая функцио-

нальностью (FDD, от Feature Driven Development). Это методология разработки

ПС, отталкиваясь от функциональных возможностей, постепенно «разворачивае-

мых» в ходе коротких итеративных циклов с приращениями. Впервые была пред-

ложена Джефом ДеЛуком для крупного банка в Сингапуре в 1997 году как концеп-

туальное объединение многих известных лучших практических приемов разработки

ПС. С 1999 года официально опубликована и поддерживается автором на собствен-

ном сайте - www.nebulon.com.

FDD характеризуется модельно-ориентированным (model-driven) процессом

разработки, включающим 3 последовательные фазы, в ходе которых формируется

общая модель системы, и 2 итеративные фазы, выполняемые применительно к

каждой выделенной функции (свойству) системы. Для контроля продвижения реа-

лизации функций итеративные фазы разделены шестью вехами (по три вехи в каж-

дой итеративной фазе).

Краткое схематическое описание ЖЦ ПС при использовании FDD представ-

лено в таблице 11.15.

546 Глава 11

Таблица 11.15. Структура ЖЦ при разработке систем по FDD

Фаза Описание действий

Разработка

общей

модели

Анализ предметной области (ПрО) и контекста применения разраба-

тываемой системы. Выделение направлений для детального моделиро-

вания.

Разработка моделей по каждому направлению анализа и их объедине-

ние в общую модель системы.

Используемые передовые практические приемы: формирование не-

больших групп аналитиков со стороны пользователей (экспертов) и

разработчиков, объектно-ориентированное моделирование ПрО, сквоз-

ной просмотр ПрО, коллегиальная проверка (анализ) моделей.

Построение

списка

функций

Определение перечня функций, которыми должна обладать система.

Используемый практический прием – функциональная декомпозиция

предметной области на подобласти, связанные с отдельными видами

бизнес-деятельности. Список образуют функции системы, реализующие

отдельные шаги в бизнес-процессе, например, «проверка пароля пользо-

вателя» или «составление регламентного отчета».

Уровень декомпозиции функций таков, что реализация каждой из них

не должна требовать более 2-х недель.

Планирова-

ние

реализации

каждой

функции

Формирование группы планирования, включающей менеджера проек-

та системы и лидеров-программистов.

Выделение классов функций в списке, назначение владельцев классов

(ответственных за проектирование и реализацию классов). Владелец

класса отвечает за эффективность его реализации и концептуальную

целостность.

Формирование команд проектов каждой функции (т.е. укомплектова-

ние «по функциям»).

Проектиро-

вание

каждой

функции

Разработка пакета проектных решений по каждой функции (требова-

ний, альтернатив проекта, объектной модели (включающей классы, ме-

тоды, атрибуты, календарный график)).

Каждый лидер команды программистов выбирает небольшой набор

функций из списка, которые могут быть реализованы за 2 недели.

Далее совместно - лидер команды программистов и владелец соответ-

ствующего класса (кода) – разрабатывают диаграммы последователь-

ности разработки для каждой функции (с указанием дат завершения

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

системы; пишут прологи методов и классов (определяя типы парамет-

ров, возвращаемых значений, исключительные ситуации, сообщения) и,

по завершении, проводят инспекцию проекта.

Программ-

ная реализа-

ция каждой

функции

Разработка программного кода каждой функции владельцами классов.

Автономное тестирование, инспекция кода.

Интеграция функции в общую конструкцию системы (формирование

версии ).

Для удобства контроля продвижения разработки функций системы, с каждой

вехой в итеративных фазах ассоциированы уровни завершенности работы, выра-

женные в процентах:

Глава 11 547

Веха в итерации разработки: Прирост степени готовности:

• Анализ ПрО завершен

+ 1 %

• Проектирование функции завершено

+ 40 %

• Инспекция проекта завершена

+ 3 %

• Кодирование завершено

+ 45 %

• Инспекция кода завершена

+ 10 %

• Функция «добавлена» в систему

+ 1 %

Таким образом, основные отличительные особенности FDD, способствующие

повышению качества создаваемых систем, таковы:

1. Объектно-ориентированное моделирование предметной области. Соот-

ветствие стандартам UML. Удобство модификации (уточнения и развития) моде-

лей.

2. Разработка от функциональных свойств системы (управляемая функцио-

нальностью). Снижение сложности разработки и конструктивной сложности. Про-

зрачность проекта для пользователей. Удобство изучения, сопровождения.

3. Индивидуальное владение кодом. Повышение ответственности за согласо-

ванность реализуемых функций, эффективность и концептуальную целостность

класса.

4. Группы, организованные по функциям (свойствам) системы. Специализа-

ция разработчиков в отдельных областях бизнес-процесса. Динамические команды,

коллективное принятие решений.

5. Инспекции. Применения передовых приемов проверки моделей, проекта,

кода. Своевременное устранение ошибок и уточнение общей модели системы.

6. Регулярные сборки версий. Обеспечение доступности текущего состояния

системы для обзора пользователями. Своевременная обратная связь от пользовате-

лей. Устранение ошибок интеграции на ранних стадиях разработки.

7. Управление конфигурацией. Идентификация исходного кода всех функций,

которые должны быть реализованы в определенный срок. Ведение истории изме-

нений в классах. Улучшение управления разработкой и внесения изменений.

8. Отчетность о состоянии. Повышение прозрачности хода разработки сис-

темы благодаря установленным вехам и количественным показателям готовности.

Дополнительную информацию о методологии FDD можно почерпнуть, на-

пример, из электронной энциклопедии Wikipedia по адресу в Интернет

http://en.wikipedia.org/wiki/Feature_Driven_Development.

11.7.5. Сравнение Agile-методологий

Все Agile-методологии объединяет ряд общих характеристик, а именно:

• Модульность процесса.

• Итеративность с краткими циклами (от 1 до 6 недель), позволяющими

выполнить быструю верификацию и реализацию, а также минимизировать риск.

• Минимизация действий в процессах (отсекаются все избыточные дейст-

вия).

• Динамический жизненный цикл, адаптируемый применительно к возни-

кающим новым рискам.

• Разработка приложений небольшими, но работающими порциями.

• Ориентация на человеческий фактор.

548 Глава 11

• Стиль работы: тесное взаимодействие и сотрудничество.

• Постоянное обучение.

В таблице 11.16 подытожены ключевые аспекты методологий и отмечены их

известные недостатки [40].

Таблица 11.16. Сравнение основных Agile методологий

Методо-

логия

Условия примене-

ния

Ключевые аспекты Известные

недостатки

ХР - небольшие проек-

ты;

- высокая самодис-

циплина

- группы от 3 до 10 чело-

век;

- активное участие заказ-

чика;

- ежедневные сборки

- отсутствие цельного

взгляда на ПС;

- слабое применение

практических приемов

управления

SCRUM nе же, что и в ХР - независимые самоорга-

низованные группы;

- циклы выпуска версий

до 30 дней

не детализированы ин-

теграционные и прие-

мочные тесты для вер-

сий

DSDM - большие проекты;

- деление ПС на не-

зависимые части;

- предпочтение отда-

ется при разработке

ИС

- группы от 2 до 6 чело-

век;

- короткие итерации;

- модель быстрой разра-

ботки (RAD)

метод доступен только

для членов консорциу-

ма DSDM

ASD поддержка распреде-

ленной разработки

- компонентный подход;

- проверки с участием

заказчика.

требует применения

других процессов

FDD - проекты разных

типов и размеров;

- возможно посте-

пенное внедрение

- объектно-ориентиро-

ванная компонентная

разработка;

- итерации: от 2-часов до

2 недель.

- охватывает только

проектирование и реа-

лизацию;

- требует применения

других процессов

11.8. Бездефектная разработка ПС. Подход Cleanroom

С появлением (в конце 90-х годов) и быстрым распространением гибких и

«облегченных» методологий разработки ПС, несколько в тень ушли методологии,

основанные на четко регламентированном, дисциплинированном и документиро-

ванном процессе разработки с разбиением на последовательные стадии и тщатель-

ным контролем состояния проекта. В литературе эти методологии получили обоб-

щенное название «плановые», поскольку разработка и неукоснительное соблюде-

ние документируемых планов и процедур – необходимое условие их применения.

Несмотря на критику в адрес плановых методологий за излишнюю жесткость

и консерватизм, они продолжают широко использоваться в программной инжене-

рии, особенно в проектах создания критических систем в разных отраслях (энерге-

тике, авиации и др.), а также проектах, которые жестко регламентируются ведомст-

венными стандартами и условиями договоров на разработку ПС в критических об-

ластях.

Одна из таких методологий - Cleanroom (от clean room, чистая комната).

Cleanroom – это подход к разработке ПС, основанный на идее предупрежде-

ния ошибок. Его характерные особенности таковы:

Глава 11 549

• процесс разработки с приращениями, стимулирующий непрерывное со-

вершенствование организации;

• технические обзоры, предупреждающие дефекты и существенно сни-

жающие издержки;

• приемы проектирования и кодирования, которые облегчают адаптацию

продукта к изменяющимся требованиям;

• методы тестирования, фокусируемые на измерении качества;

• команды, создаваемые для решения определенной проблемы, что способ-

ствует сотрудничеству и снижению зависимости от «гуру»;

• структурированная документация, отражающая целостную картину раз-

работки и помогающая членам команды осуществлять интеллектуальный контроль

разработки.

Cleanroom может быть частью комплексного подхода к обеспечению качест-

ва в сочетании с ISO-9000 или TQM и применяться на всех уровнях зрелости орга-

низации. Методы Cleanroom совместимы с другими методологиями программной

инженерии, включая объектно-ориентированную и клиент-серверную разработку с

использованием CASE-средств и поддерживаемых ими методологий.

Подход Cleanroom был впервые использован в 80-е годы в IBM примени-

тельно к разработке критических систем диспетчеризации в авиации и обеспечения

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

лась в миллионах долларов и потенциально в человеческих жизнях. Д-р Х. Милс

предложил разработчикам программного обеспечения перенять успешные практи-

ческие приемы высокоточного производства и соединить их с передовой практикой

программной инженерии. Таким образом, в Cleanroom вошел принцип предупреж-

дения дефектов на каждом этапе работы (путем тщательного обзора рабочего про-

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

пользователя компонентов, формализация спецификаций и проекта каждого эле-

мента сборки, согласование с пользователем всех спецификаций, тщательное доку-

ментирование любых изменений, статистический контроль качества и командная

форма работы.

Тестирование в Cleanroom полностью отделено от разработки - не только на

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

нием и оценкой показателей качества (в частности, надежности). Только тестиров-

щики, а не программисты, разрабатывающие код, могут выполнять его на машине.

При проектировании выявляются критические структуры и функции, определяются

профили использования системы и возможные режимы ее отказа, что позволяет

применять дифференцированный подход к распределению ресурсов тестирования и

обеспечению надежности отдельных модулей и компонентов.

Изначально высокая степень безошибочности кода достигается благодаря ин-

ституциализации процедур технических обзоров проекта и инспекции соответствия

кода спецификации. Причем технические обзоры носят конструктивный характер –

их цель не просто обнаружить ошибки, а коллективно убедиться в качестве проек-

та. В отличие от отслеживания источников ошибок, обзоры Cleanroom локальны:

просматривается каждый компонент, содержащий ограниченное количество моду-

лей, и его качество оценивается независимо от остальных компонентов. Однако

каждый обозреватель всегда видит общую архитектуру системы и старается макси-

мально упростить проект. В результате применения такого подхода, разработанные

550 Глава 11

системы получаются компактными и легкими для сопровождения и развития. Кро-

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

тонкости не только «своей» части, но и системы в целом. При коллективном обзоре

снижается влияние возможных ошибок каждого, так как команда «отфильтровыва-

ет» неправильные решения.

Нужно отметить особенности процесса разработки системы. В его основе ле-

жит инкрементный подход, состоящий в послойном наращивании функциональных

возможностей системы и периодической поставке новых компонентов системы

(инкрементов) заказчику.

Размер и содержание каждого инкремента определяются при планировании

инкрементов на основе анализа не только приоритетов реализации функций систе-

мы, а и риска срыва проекта. Так, если требования к интерфейсу пользователя сис-

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

троля этого риска первыми создаются и поставляются пользователям инкременты

системы, содержащие код, который реализует менее сложные функции, но обшир-

ный пользовательский интерфейс. Это дает возможность своевременно провести

согласование требований к интерфейсу и внести необходимые изменения.

В отличие от высокоточного производства, где контроль качества основан на

анализе соответствия спецификациям статистической выборки изделий из партии, в

Cleanroom осуществляется контроль качества на основе статистического тести-

рования (глава 7) и последующего прогнозирования надежности программного

обеспечения по моделям надежности. Статистическое тестирование выполняется в

соответствии с операционным профилем, который отражает частоту выполнения

пользователем различных операционных сценариев работы. Именно операционный

профиль «руководит» выбором тестов, результаты которых образуют статистиче-

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

живаться отказы наиболее часто используемых компонентов системы и устраняться

дефекты в наиболее часто выполняемых фрагментах кода.

Эффективное применение Cleanroom требует опыта. Подход позволяет вне-

дрять отдельные приемы постепенно, не изменяя общей методологии разработки

систем, и рекомендует начать со статистического контроля качества, который под-

держивается тремя приемами - инкрементной разработкой, командной формой ра-

боты и отделением тестирования от кодирования.

Подход Cleanroom естественным образом дополняет методологии совершен-

ствования процессов разработки ПС. Он полностью разделяет принципы TQM и не

противоречит СММ. Как раз СММ можно рассматривать как схему поэтапного

ввода приемов Cleanroom на каждом уровне зрелости.

Одним из основных факторов успеха Cleanroom является специфицирование

каждого отдельного компонента системы и его согласование с пользователями.

Именно такая точка зрения на разработку идеальна для применения объектно-

ориентированного или клиент-серверного подходов, хотя применение других под-

ходов ничем не ограничивается. Даже применение CASE-методологий, «упразд-

няющих» программирование и бумажную технологию документирования, не отме-

няет квалифицированного принятия проектных решений о процессах, данных и их

взаимодействии, и не заменяет коллективного оценивания качества этих решений.

Cleanroom изначально оформился как практический подход к разработке, а

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

Глава 11 551

ний о специальных контролируемых экспериментах по его применению для разных

классов ПС. Однако есть многочисленные опубликованные примеры применения

Cleanroom для широкого спектра отраслей и классов систем (см., например, рабо-

ты [41 - 43], а также по адресу www.cleansoft.com/cleansoft_library.html).

11.9. Сравнение методологий улучшения процесса разработки

11.9.1. Сопоставление методологий разработки

В зависимости от строгости и предсказуемости предписанного процесса

программной инженерии, методологии разработки образуют довольно широкий

непрерывный спектр, на одном конце которого - хаотичный недисциплинирован-

ный процесс, называемый также «ковбойским» или «хакерским» [44, 45], а на

другом – полностью регламентированный плановый процесс.

На рисунке 11.7 методологии упорядочены в спектре от «адаптивных» до

«предсказуемых» процессов [44].

<Хаотичные> <---Agile---> <-------Итеративные-----> <-----Каскадные---->

[------------------------|-------------------------|-----------------------------|-----------]

Адаптивные Предсказуемые

Рис. 11.7. Спектр методологий разработки ПС

Хаотичный процесс разработки характеризуется полным отсутствием или

неупорядоченностью применяемых методов: члены группы делают то, что считают

нужным, не руководствуясь определенными планами.

В Agile-методологиях процесс не хаотичен. Частые пересмотры планов раз-

работки в этих методологиях, акцент на тесном взаимодействии и относительно

небольшой объем документов вовсе не свидетельствуют о хаотичности – процесс

остается дисциплинированным, хотя и не всецело плановым. Agile-методологии

находятся в области адаптивных процессов [44].

Методологии разработки с адаптивными процессами ориентированы на

краткосрочное планирование и быструю перестройку работы в соответствии с

изменяющимися условиями. При их применении возможны проблемы, связанные

с расчетами трудоемкости и стоимости проекта, определением условий договоров

с заказчиком.

Методологии разработки с полностью предсказуемыми процессами (и пре-

имущественно с каскадной моделью ЖЦ), основаны на тщательном долгосрочном

планировании на весь период разработки. При их применении, как правило, воз-

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

ков и состава работ.

Итеративные методологии, в частности, рассмотренные в этой главе RUP и

MSF – представляют собой хорошо сбалансированные методологии, сочетающие

в себе элементы адаптивности и предсказуемости. Длительность итераций может

колебаться от нескольких недель до нескольких месяцев.

По сравнению с итеративными методологиями, в agile-методологиях пред-

полагаются более сжатые сроки итераций и коллективное принятие решений о

дальнейших действиях в проекте.