Технологии разработки программных систем

- Если необходимо, строятся дополнительные диаграммы:

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

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

- Завершается построение статической модели добавлением информации о детальном дизайне (например, области видимости значений и паттерны).

- Командой осуществляется проверка дизайна на соответствие все предъявляемым к системе требованиям. Это действие свидетельствует о завершении стадии проектирования для проекта.

Веха 3 позволяет установить, что:

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

- детальный дизайн обладает достаточной глубиной (т.е. достаточно подробен), чтобы облегчить относительно небольшой и плавный переход к коду;

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

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

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

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

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

На этапе 4 выполняются следующие действия:

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

- Пишется или генерируется программный код.

- Осуществляется модульное и интеграционное тестирование.

- Совершается системное тестирование и тестирование приемлемости для пользователей. Это действие свидетельствует о завершении стадий реализации и тестирования для проекта.

Веха 4 позволяет установить, что:

- модульные тесты соответствуют описанию прецедентов и диаграммам последовательности;

- созданный программный код соответствует диаграммам классов и последовательности, рассматриваемых как руководство к написанию кода.

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

Одним из преимуществ Процесса ICONIX является то, что для каждого этапа указано 10 наиболее распространённых ошибок разработки и их разбор.

4.3 Эволюционные технологические подходы

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

Особенностями эволюционных подходов являются: 1. Использование прототипирования и 2. Тесное взаимодействие с заказчиком.

Выделяют эволюционные подходы следующих двух видов:

1. Подходы прототипирования: Эволюционная доставка, Итеративная доставка, Постадийная доставка.

2. Подходы быстрой разработки: Итеративная инкрементная разработка (IID), Быстрая разработка приложений (RAD), Эволюционная быстрая разработка (ERD), Метод разработки динамичных систем (DSDM).

Подходы прототипирования являются вариациями Итеративной инкрементной разработки, на котором основываются и другие подходы быстрой разработки.

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

Подходы прототипирования

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

Выделяют следующие основные подходы прототипирования: 1. Эволюционная доставка; 2. Итеративная доставка; 3. Постадийная доставка.

Модели ЖЦ для прототипируемых подходов являются вариантами прототипируемой модели с учётом каскадной и других моделей.

Эволюционная доставка - эволюционный подход, ориентированный в первую очередь на создание пользовательского интерфейса.



Рис.4.11. Модель ЖЦ для подхода Эволюционная доставка

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

Подход применяется в проектах с ярко выраженным преобладанием разработки пользовательского интерфейса. Существенным недостатком подхода является невозможность определить стоимость и продолжительность проекта.



Рис.4.12. Модель ЖЦ для подхода Итеративная доставка

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

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

Подход применяется в проектах с ярко выраженным преобладанием разработки функциональности. Существенным недостатком подхода также является невозможность определить стоимость и продолжительность проекта.

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

Рис.4.13. Модель ЖЦ для подхода Постадийная доставка

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

Итеративная инкрементная разработка (IID)

Итеративная инкрементная разработка (ИИР, IID - Iterative and Incremental Development) - подход разработки, являющийся альтернативой (классическому) каскадному подходу и использующий прототипы.

Идея повышения качества путём организации производства в виде коротких циклов «Планирование - Выполнение - Проверка - Действие» была предложена в 1939 г. в работе У. Шуарта, эксперта по качеству Bell Labs. Эта идея получила развитие в области разработки ПО и привела к созданию в середине 1950_х гг. подхода ИИР. ИИР использовался в ряде исследовательских проектов, выполненных подразделением FSD (Отделение федеральных систем) фирмы IBM по заказу Министерства обороны США.

ИИР стал одним из основных компонентов ряда современных строгих и гибких подходов, в том числе RAD, DSDM, RUP и многих живых подходов.

Подход основан на одноимённой модели, приведённой в §3.3.

Быстрая разработка приложений (RAD)

Быстрая разработка приложений (БРП, RAD - Rapid Application Development) - эволюционный подход, сформулированный Дж. Мартином в 1991 г.

В 1980_х гг. Дж. Мартин, сотрудник фирмы IBM, разработал подход БРП. В 1991 г. он опубликовал книгу под названием «Быстрая разработка приложений», в которой он сформулировал основные положения. В дальнейшем подход БРП стал пониматься более широко и включил в себя другие методики, нацеленные на ускорение разработки приложений.

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

БРП обладает следующими особенностями:

1. Команда разработчиков. Малочисленная проектная команда (от 2 до 10 человек) из опытных, разносторонне подготовленных специалистов, способных заменять друг друга.

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

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

На основе БРП созданы и другие подходы: Адаптивная разработка ПО (ASD), Метод разработки динамичных систем (DSDM) и т.д.

Основы подхода

К основным принципам БРП следует отнести следующие:

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

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

3. Обязательное вовлечение пользователей в процесс разработки системы.

4. Ведение разработки немногочисленной хорошо управляемой командой профессионалов.

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

6. Необязательность полного завершения работ на каждой из фаз ЖЦ.

7. Необходимое применение CASE-средств, обеспечивающих целостность проекта на всём протяжении ЖЦ.

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

9. Непременное использование генераторов кода.

10. Тестирование и развитие проекта одновременно с разработкой.

Для выполнения разработки согласно перечисленным принципам используется метрика - оценка размера приложения. Эта метрика вычисляется на основе так называемых функциональных элементов, к которым относят следующие элементы приложения: входной элемент (документ, экранная форма), выходной элемент (отчёт, документ, экранная форма), запрос (пара «вопрос - ответ», сообщение), файл приложения (совокупность записей данных, используемых внутри приложения), интерфейс приложения (совокупность записей данных, передаваемых другому приложению или получаемых от него).

Подобная метрика не зависит от используемого языка программирования. Размер приложения, которое может быть выполнено с помощью БРП, для хорошо отлаженной среды разработки с максимальным повторным использованием программных компонентов определяется следующим образом:

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

- одна команда при числе функциональных элементов 1000 - 4000,

- 4000 функциональных элементов на одну команду разработчиков при числе функциональных элементов более 4000.

Жизненный цикл проекта

Основой модели ЖЦ для подхода служит итеративная инкрементная модель, ориентированная на разработку работающих прототипов (рис.4.14).

В БРП выделены следующие 4 фазы: 1. Планирование и Анализ требований; 2. Проектирование; 3. Построение; 4. Внедрение.

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



Рис.4.14. Схема модели ЖЦ для подхода RAD

На фазе 2 часть пользователей принимает участие в логическом проектировании системы под руководством разработчиков. Для быстрого получения работающих прототипов приложений используется CASE-средство. Пользователи, непосредственно взаимодействуя с ними, уточняют и дополняют требования к системе, которые не были выявлены на предыдущей фазе. Более подробно рассматриваются процессы системы. Анализируется и корректируется функциональная модель. Каждый процесс рассматривается детально. При необходимости для каждого элементарного процесса создаётся частичный прототип (экран, диалог, отчёт), устраняющий неясности или неоднозначности. Определяются требования разграничения доступа к данным. На этой же фазе происходит определение набора необходимой документации. После детального определения состава процессов оценивается количество функциональных элементов разрабатываемой системы и принимается решение о разделении её на подсистемы, поддающиеся реализации одной командой разработчиков за приемлемое для RAD-проектов время - порядка 60 - 90 дней. С использованием CASE-средства проект распределяется между различными командами (делится функциональная модель). Результатами фазы должны быть: общая информационная модель системы, функциональные модели системы в целом и подсистем, точно определённые с помощью CASE-средства интерфейсы между автономно разрабатываемыми подсистемами, построенные прототипы экранов, отчётов, диалогов. Все модели и прототипы должны быть получены с применением того CASE-средства, которое будут использоваться в дальнейшем при построении системы. Применение единой среды хранения информации о проекте позволяет избежать опасности искажения данных.

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

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

Приведённая схема разработки не является абсолютной. Возможны различные её варианты в зависимости от целей проекта.

4.4 Адаптивные технологические подходы

Адаптивные подходы являются гибкими подходами, получившими также название живых подходов. Они имеют много общего с эволюционными подходами, особенно с подходом RAD.

Особенностями адаптивных подходов являются: Открытое взаимодействие, Разработка короткими итерациями, Адаптируемость процесса разработки.

Выделяют адаптивные подходы следующих видов:

1. Игровые адаптивные подходы: Адаптивная разработка ПО (ASD), Экстремальное программирование (XP), Скрам (Scrum).

2. Управляемые адаптивные подходы: Управляемая тестами разработка (TDD), Управляемая возможностями разработка (FDD), Управляемая поведением разработка (BDD), Управляемая дизайном разработка (D3).

3. Унифицированные адаптивные подходы: Гибкие варианты UP.

4. Облегчённые адаптивные подходы: Облегчённая разработка ПО (LSD).

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

Особенности живых подходов

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

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

В феврале 2001 г. 17 известных сторонников гибких подходов встретились в местечке Сноубёрд (штат Юта, США), для обсуждения вопросов создания ПО более лёгким, быстрым и «человеко-центрированным» способом. Кроме того они предложили общее название для подходов с указанными выше способами разработки: Живая разработка ПО.

Результатом этого обсуждения стал «Манифест Живой разработки ПО», известный под сокращённым названием «Живой манифест».

Живой манифест включает в себя уведомление с основными положениями и сам документ с принципами живой разработки ПО.

Основные положения при разработке ПО связаны с правильной оценкой:

1. Люди и их взаимодействие важнее процессов и средств.

2. Работающее ПО важнее исчерпывающей документации.

3. Сотрудничество с заказчиком важнее обсуждения контракта.

4. Реагирование на изменения важнее следования плану.

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

Адаптивная разработка ПО (ASD)

Адаптивная разработка ПО (АРП, ASD - Adaptive Software Development) - живой подход, предложенный Дж. Хайсмитом.

Идея представления процесса разработки как адаптивной системы была высказана Э.А. Эдмондсом в его статье ещё в 1974 г. Работа со строгими подходами разработки привела Хайсмита к выводу об ошибочности их применения в условиях постоянно меняющегося окружения и созданию своего подхода.

Изложение этого подхода приведено в его книге «Адаптивная разработка ПО: Подход сотрудничества при управлении сложными системами», изданной в 2000 г. В этой книге нет подробного описания практик, но она закладывает теоретическую основу адаптивных разработок. Это позволяет использовать АРП совместно с другими гибкими подходами (Crystal, FDD, XP). В настоящее время подходы АРП и Crystal Family объединены их авторами в единый подход.

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

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

Хайсмит рассматривает процесс разработки как сложную адаптивную систему: организация-разработчик - это среда, участники проекта - агенты, а продукт - проявляемый результат сотрудничества участников. Такое рассмотрение приводит к иному пониманию разработки и формированию нового подхода.

Основы подхода

Вместо статического ЖЦ «Планирование - Проектирование - Построение» в АРП предлагается динамический ЖЦ «Обдумывание - Сотрудничество - Обучение». Этот цикл ставит своей целью непрерывное обучение (рис.4.15).

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

Рис.4.15. Схема модели ЖЦ для подхода ASD

Цикл обладает следующими свойствами: 1. Целенаправленность; 2. Компонентный подход; 3. Итеративность; 4. Ограниченность по времени; 5. Управляемость рисками; 6. Допущение изменений.

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

Компонентный подход определяет построение ЖЦ исходя не из самих задач, а из результатов - компонентов системы. Здесь под компонентом понимается некоторый набор возможностей программы (или некоторых элементов, входящих в поставку системы), который должен быть разработан в течение итерации. Документация по отношению к возможности считается второстепенной, так как только работающий код позволяет заказчику ощутить реальные результаты работы.

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

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

Управляемость рисками позволяет осознать и проанализировать риски.

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

Жизненный цикл проекта

Модель ЖЦ для АРП (рис.4.16) основана на приведённой выше схеме цикла.

В модели эта схема конкретизируется в виде трёх фаз: 1. Обдумывание; 2. Сотрудничество; 3. Обучение.

На фазе 1 выполняются два процесса.

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

1. Определение цели и задач проекта.

2. Выявление и краткое описание ограничений и требований к системе.

3. Изучение расстановки сил в проекте (организация проекта и команды).

4. Первоначальная оценка размера и масштабности проекта.

5. Определение ключевых рисков.

6. Установление временных рамок для всего проекта.

Рис.4.16. Модель ЖЦ для подхода ASD

Все расчёты являются предварительными и в дальнейшем могут измениться.

Адаптивное планирование циклов состоит из следующих действий:

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

2. Определение цели и задач для каждого цикла разработки.

3. Соотнесение компонентов системы с циклами разработки.

4. Планирование циклов с учётом разрабатываемых компонентов.

Распределение компонентов по циклам - непростая задача. Главным критерием здесь является поставка заказчику в конце каждого цикла некоторой видимой, осязаемой, работающей части системы. К другим критериям относят следующие:

1. Первоочередная разработка компонентов с высокой степенью риска.

2. Учёт естественных зависимостей между компонентами.

3. Балансирование расходов различных используемых ресурсов.

На фазе 2 «Сотрудничество» выполняется один процесс. Параллельная разработка компонентов включает отдельные параллельно реализуемые действия по разработке каждого запланированного на текущий цикл компонента.

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

На фазе 3 «Обучение» выполняются два процесса.

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

В конце каждого цикла разработки нужно знать:

1. Качество продукта с точки зрения заказчика.

2. Качество продукта с технической точки зрения.

3. Работоспособность команды и используемость практик.

4. Текущее положение дел в проекте (статус проекта).

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

Экстремальное программирование (XP)

Экстремальное программирование (ЭП, XP - eXtreme Programming) - живой подход, предложенный К. Беком.

Возникновение ЭП тесно связано с выполнением проекта C3 (букв. Всеобъемлющее компенсирование для Chrysler) - разработка системы учёта выплат работникам фирмы Daimler Chrysler. Суть проекта заключалась в разработке единой системы вместо множества разрозненных приложений. Именно на этом проекте К. Беком отрабатывались практики, лёгшие в основу подхода. В создании ЭП и работе над проектом приняли также участие У. Каннингем и Р. Джефрис. В 1996 г. Бек стал руководить проектом, но в 2000 г. фирма прервала проект. Полученная к этому моменту система использовалась только для 10 тысяч человек из 87 тысяч работников. Поэтому успешный на словах проект на самом деле оказался провальным. Главной причиной этого является не сам подход, а его применение к неподходящему проекту. Для реализации проекта C3 (разработки формализуемой системы) необходимо было использовать один из строгих подходов. В 1999 г. вышло первое издание К. Бека «Экстремальное программирование в объяснении: Избирание изменения», а в 2004 г. - второе издание этой книги в соавторстве с Ц. Андрес, переработанное с учётом опыта применения ЭП.

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

При этом практики ЭП оказываются слишком тесно взаимосвязанными, что приводит к излишней жёсткости подхода. Практики считаются фиксированной частью, в то время как ЖЦ системы - адаптивной частью ЭП, что противоречит логике разработки и приводит к проблемам в проектах, использующих этот подход.

Основы подхода

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

Жизненный цикл проекта

В ЭП рассматривается модель ЖЦ идеального проекта для ЭП (рис.4.17).

Согласно этой модели выделено 5 фаз ЖЦ: 1. Исследование; 2. Планирование; 3. Реализация / Итерации; 4. Продуцирование / Обслуживание; 5. Смерть.



Рис.4.17. Схема модели ЖЦ для подхода XP

На фазе 1 выполняется предварительная подготовка к работе, в рамках которой можно выделить следующие операции:

1. Команда выбирает инструменты, осваивает необходимые знания и навыки, анализирует варианты архитектур системы, оценивает будущие задачи.

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

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

Планирование работы и выпуска основано на наблюдении за четырьмя ограничениями, названными в ЭП переменными: стоимость, время, качество и содержание. Заказчиком должно фиксироваться не более трёх переменных, а команда выбирает результирующие значения остальных переменных.

На фазе 3 выполняются итерации разработки и функциональное (приёмочное) тестирование системы. Итерации разработки предназначены для реализации историй в рамках плана выпуска и формирования функциональных тестов. В ходе первой итерации формируется общий дизайн, для которого отбираются подходящие истории, для остальных итерации отбор историй выполняется заказчиком. Функциональное тестирование позволяет получить одобренный заказчиком выпуск, включающий истории с учётом плана выпуска.

На фазе 4 выполняются развёртывание системы в реальной среде эксплуатации и её обслуживание. Во время развёртывания и обслуживания системы заказчик может сформировать новый набор историй для их включения в следующий выпуск продукта.

На фазе 5 завершается эксплуатация системы. Это может произойти по двум причинам: 1. У заказчика нет историй для новых выпусков продукта; 2. Система находиться в плохом состоянии из-за большого числа дефектов.

На протяжении этих фаз ЖЦ выполняются 4 деятельности, связанные с программированием: 1. Кодирование; 2. Тестирование; 3. Слушание; 4. Проектирование. Основой для всех деятельностей является программный код системы.

4.5 Генетические технологические подходы

Генетические подходы являются строгими подходами. Они основаны на аналогии разработки ПО и различных (в частности, биологических) процессов происхождения.

Выделяют генетические подходы следующих трёх видов:

1. Синтезирующее программирование.

2. Конкретизирующее программирование.

3. Сборочное программирование.

Перечисленные виды подходов оказываются тесно связанными с методологиями разработки ПО. Подход 1 ориентирован на методологии императивного (в том числе структурного и параллельного) программирования и ООП. Подходы 2 и 3 ориентированы на специальные методологии, которые рассмотрены при описании указанных видов генетических подходов. Методологии логического и функционального программирования могут лежать в основе подходов 1 и 2. Методология сентенциального программирования лежит в основе подхода 2. Методологии ограничительного, событийного и автоматного программирования могут лежать в основе подходов любых видов.

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

Синтезирующее программирование

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

Для получения программы необходимо решить следующие основные задачи:

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

2. Выбрать алгоритмический язык реализации, а также программно-аппаратную платформу для реализации.

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

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

5. Протестировать полученный код программы.

Существует ряд подходов различного уровня применения в процессах ЖЦ, которые относятся к синтезирующему программированию и связаны с соответствующим языком спецификации. К таким языкам спецификации относятся следующие: UML - язык спецификации для объектно-ориентированной разработки ПО; SDL - язык для однозначного специфицирования и описания поведения реактивных и распределённых систем; ASN.1 - стандартный гибкий язык описания структур данных для представления, кодирования, передачи и декодирования данных. Автоматическая генерация программ возможна для многих языков спецификаций, в частности для перечисленных выше языков.

Конкретизирующее программирование

Конкретизирующее программирование - вид подходов, предполагающих извлечение программы из существующей универсальной программы путём конкретизации общих элементов. Существует много подходов различного уровня применения в процессах ЖЦ, относящихся к конкретизирующему программированию.

Среди них следует отметить следующие подходы:

1. Обобщённое программирование.

2. Подход на основе паттернов и анти-паттернов.

3. Подход на основе архитектурных стилей.

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

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

Подход на основе архитектурных стилей ориентирован на первоначальное определение архитектуры разрабатываемой системы. Архитектурный стиль - это набор архитектурных структур, ориентированный на разработку системы для конкретной ПрО. М. Шоу и Д. Гарлан предложили использовать каталог таких стилей для их идентификации и документирования, а также облегчения использования в дальнейшем на практике. Каждый архитектурный стиль обычно имеет определённое концептуальное представление - архитектурный паттерн, и связанное с некоторой методологией разработки реализационное представление - архитектурный каркас.

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

Сборочное программирование

Сборочное программирование - вид подходов, предполагающих сборку программы из уже разработанных фрагментов. Сборка может осуществляться вручную, указываться на языке сборки или извлечена полуавтоматическим образом из спецификации. Фрагментами кода обычно выступают программные модули или иные части программы, представляемые в виде модулей определённого вида.

Выделяют следующие основные способы поддержки этого подхода:

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

2. Повышение эффективности межмодульных интерфейсов. Обеспечение поддержки модульности на уровне программно-аппаратной платформы.

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

Сборочное программирование тесно связано с методом повторного использования кода, причём как исходного, так и бинарного. Выделяют несколько разновидностей технологических подходов сборочного программирования, которые в значительной степени определяются базисной методологией: 1. Модульное сборочное; 2. Объектное сборочное; 3. Компонентное сборочное и 4. Аспектное сборочное программирование.

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

Модульное сборочное программирование - исторически первый подход сборочного программирования, базирующийся на процедурах и функциях методологии структурного императивного программирования, точнее их объединении - программных модулях. В разных языках программные модули называются по-разному: модуль (module в Modula_2, unit в Pascal), пакет (package в Ada) или просто отдельный файл (в C/C++ и т.п.).

Некоторые рассматривают указанную методологию, дополненную концепцией модуля, как полноправную, самостоятельную, используя для неё название модульно-ориентированное программирование, подчёркивая этим выделение модульности как отдельной специфики, а не части топологической специфики.

Развитием этого подхода является расширяемое программирование - модульно-основанное программирование, при котором добавление новых модулей возможно без каких-либо изменений в существующих модулях. Данный подход предложен Н. Виртом и впервые реализован при проектировании Oberon System. Фактически это компонентно-основанное программирование без ООП, так как модуль в Oberon является полноценным компонентом (т.е. выполняет соответствующие ему функции). Развитием Oberon стал Component Pascal, в своём названии отразивший своё происхождение от языка Pascal и свою нацеленность на компонентное программирование.

Объектное сборочное программирование - подход сборочного программирования, базирующийся на библиотеках классов ООП, поставляемых в виде исходного (VCL в Delphi) или бинарного кода (DLL в C/C++ для MS Windows).

Как следует из названия, подход соответствует методологии ООП.

Компонентное сборочное программирование - развитие предыдущего подхода, базирующееся на библиотеках компонентов. Данный подход связан с такими понятиями, как компонент и интерфейс.

Компонент - класс, доступ к которому обеспечивается через строго определённые интерфейсы. Под интерфейсом понимается набор средств и правил для обеспечения единообразного взаимодействия. Использование интерфейсов компонентов вместо непосредственного доступа к объектам позволяет снять проблему несовместимости компиляторов и обеспечивает смену версий компонентов без перекомпиляции основанного на них ПО. Наиболее известными примерами реализации этого подхода являются COM (DCOM, COM+), CORBA, .NET.

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

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

Аспект - модуль, который содержит реализацию определённой значимости. Значимость (букв. участие, отношение) - эксплуатационная часть системы, несущая определённую характеристику (в отличие от основной части, ориентированной на ПрО). Значимость связана с определёнными эксплуатационными требованиями, предъявляемыми к системе (надёжность, контролируемость, безопасность). Примерами значимостей являются обработка контекстно-зависимых ошибок и исключений, ведение журналов работы с системой, выполнение контрольных проверок параметров, подтверждение подлинности.

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

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



4.6 Формальные технологические подходы

Формальные подходы основаны на применении математических принципов к разработке ПО. Выделяют формальные подходы следующих трёх видов:

1. Формальные генетические подходы.

2. Подходы формальной разработки.

3. Смешанные формальные подходы: Инженерия стерильного цеха (CrSE).

Подходы формальной разработки фактически являются комбинацией и/или развитием идей и принципов формальных генетических подходов. Смешанные формальные подходы используют ряд принципов формальной разработки в рамках часто используемых моделей ЖЦ.

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

Эти виды подходов предназначены для обеспечения разработки путём применения математического формализма в спецификациях и процессах ЖЦ.

Формальные генетические подходы

Формальные генетические подходы основаны на аналогии разработки ПО и вывода математических утверждений.

Проблемами доказательств (правильности) программ занимались многие отечественные и зарубежные исследователи. Под правильностью ПО здесь понимается отсутствие в нём любых дефектов. В 1975 г. Э.В. Дейкстра в работе «Охраняемые команды, недетерминированность и формальное порождение программ» высказал идею и сформулировал свои положения по доказательству программ. Эти положения послужили основой его известной книги «Дисциплина программирования», изданной в 1976 г. В 1981 г. Дэвид Грис опубликовал адаптацию этой книги к учебному процессу под названием «Наука программирования». В 1984 г. А.П. Ершов в своём докладе (Труды Академии наук СССР) предложил термин «доказательное программирование». Доказательное программирование - разработка ПО, обладающая свойством доказательности правильности создаваемого продукта. Кроме того, А.П. Ершов указал 3 вида доказательного программирования, которые тесно связаны с видами генетических подходов. Поэтому эти виды получили в дальнейшем название формальных генетических подходов.

Выделяют следующие формальные генетические подходы:

1. Формальное синтезирующее программирование.

2. Формальное конкретизирующее программирование.

3. Формальное сборочное программирование.

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

Приведём краткий обзор формальных генетических подходов.

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

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

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

В настоящее время формальное синтезирующее программирование является редко используемым подходом доказательного программирования.

Формальное конкретизирующее программирование основывается на применении универсальных программ - программ, реализующих некоторый обобщённый метод, пригодный для решения любых проблем некоторого класса из соответствующей ПрО.

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

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

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

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

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

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

- при частичном задании исходных данных редуцирует (упрощает) программу к так называемой остаточной программе, являющейся требуемой специализированной программой.

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

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

Здесь используется более конкретное понимание этого понятия. Модуль обладает определённой структурной и функциональной целостностью и специально приспособлен для организации чётко определяемого и контролируемого информационно-логического взаимодействия с другими модулями. Указанное взаимодействие означает обмен информацией или соподчинённость выполнения.

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

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

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

Подходы формальной разработки

Подходы формальной разработки основаны на применении формальных методов на некотором интервале или на всём протяжении ЖЦ.

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

Модели ЖЦ для подходов формальной разработки являются модификацией и/или конкретизацией описанной ниже модели трансформации.