Разновидности процесса разработки

1.4. Разновидности процесса разработки

Разработка программного обеспечения;модели

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

Рис. 1.6. Артефакты и роли

1.4.1. Водопадная модель процесса

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

·  Анализ требований состоит в сборе требований к продукту. Результатом анализа, как правило, является некоторый текст. Эта стадия рассматривается в главах 3 и 4.

·  Проектирование описывает внутреннюю структуру продукта. Обычно такое описание дается в форме диаграмм и текстов. Этот этап рассматривается в главе 5 (архитектура) и в главе 6 (детальное проектирование).

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

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

Рис. 1.7. Водопадная модель процесса разработки

Иногда водопадный процесс расширяют (рис. 1.8) следующими дополнительными фазами.

·  Концептуальный анализ, состоящий в определении общих принципов приложения и выполняемый в самом начале процесса.

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

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

·  Сопровождение программ, состоящее в модификации и внесении исправлений в приложение и осуществляемое в самом конце процесса (глава 10).

Рис. 1.8. Более детализированная модель водопадного процесса

В чистом виде водопадный процесс применяется достаточно редко, разве что в случае небольших проектов или когда команда реализует проект, очень похожий на один из тех, что были осуществлены ею ранее. Основной причиной неприменимости водопадного процесса в чистом виде является сложность большинства приложений. В нашей книге мы используем в качестве примера программного продукта ролевую игру, однако существует столь много различных толкований понятия «ролевая видеоигра» (RPG — Role-Playing Game), что было бы совершенно непрактично попытаться определить все до последнего требования к нашей игре, прежде чем приступать к проектированию и реализации. Тем не менее водопадный процесс является основой для большинства других разновидностей процесса.

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

1.4.2. Спиральная модель процесса

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

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

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

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

Рис. 1.9. Спиральная разработка

И все же для большинства программных проектов преимущества спирального процесса перевешивают его недостатки. Здесь можно сослаться на опыт Министерства обороны США, которое, признав эти преимущества, в 80-х годах отказалось от принятой им ранее установки на использование простой водопадной модели во всех программных проектах.

Сколько же итераций требуется в случае применения спиральной модели? Это зависит от ситуации. Скажем, типичный проект, трудоемкость которого оценивается в три человеко-месяца, а продолжительность — в четыре месяца, вероятнее всего, потребует две-три итерации. Затраты на проведение большего числа шагов могут просто перевесить выгоду от дополнительных итераций. Далее, в разделе 1.4.4, мы покажем, на какие четыре группы разбиваются итерации в USDP.

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

1.4.3. Инкрементальная модель процесса

Иногда представляется возможным понемногу продвигать проект вперед при практически непрерывном процессе. Такая модель разработки программного обеспечения особенно полезна на поздних стадиях проекта, когда продукт находится на сопровождении или когда разрабатываемый продукт очень схож с созданным ранее. Например, Кукумано и Сэлби [21] подготовили доклад по процессу, используемому в некоторых отделениях корпорации Microsoft, где обновления программного кода и документации представляются ежедневно к конкретному времени для интеграции и ночного тестирования. Другие организации используют для этого недельные циклы. Для поддержания соответствующего уровня инкрементальной разработки необходимо иметь четко установленную архитектуру проекта и исключительно синхронизированную систему документации (рис. 1.10). Для организации инкрементальной разработки обычно выбирается характерный временной интервал, например неделя. Затем в течение этого интервала происходит обновление исходного проекта (документации, набора тестов, программного кода и т. д.). Теоретически шаги разработки (increments) могут выполняться и параллельно, но такой процесс очень сложно скоординировать. Инкрементальная разработка проходит лучше всего, если следующая стадия n+1 начинается по возможности после того, как обновление всех модулей на стадии n закончено, и хуже всего, если время, требуемое на обновление модулей, значительно превышает выбранный интервал. Для того чтобы убедиться в этом, представьте, что необходимо изменить модуль 789, который зависит от семи других модулей: 890, 23, 489, 991, 7653, 2134 и 2314. Если изменение занимает девять недель, то модуль 789 должен быть построен исходя из предполагаемого состояния всех семи модулей через девять недель. Эту работу очень трудно скоординировать, так как каждая из семи частей может быть изменена до девяти раз (еженедельно), причем каждое новое изменение может основываться на исследовании эффективности предыдущих изменений.

Рис. 1.10. Инкрементальная разработка

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

1.4.4. Унифицированный процесс разработки программного обеспечения (USDP)

Унифицированный процесс разработки программного обеспечения (Unified Software Developement Process (USDP)USDP (Unified Software Developement Process)Унифицированный процесс разработки ПО (USDP)USDP — Unified Software Development Process)разработка программного обеспечения; модели впервые был предложен в книге Якобсона, Буча и Рамбо [64], изданной в 1999 году. Этот процесс является детищем более ранних методологий, разработанных этими тремя авторами: «Объектная методология» Якобсона, «Методология Буча» [14] и «Техника объектного моделирования» Рамбо [96].

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

·  Начальные итерации начальные итерации USDP;Начало— предварительные (подготовительные) взаимодействия с акционерами:
• основной покупатель;
• пользователи;
• инвесторы;
• другие.

·  Итерации проектирования Проектирование, итерация USDP ; их завершение желательно и просто необходимо; выбор базовой архитектуры.

·  Итерации конструирования. Конструирование: приводят к изначальной оперативной способности.

·  Итерации переход. Переход: выпуск готового продукта.

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

С учетом приведенной выше классификации итераций, USDP может быть представлен матрицей (рис. 1.11 и рис. 1.12). Как и большинство процессов объектно-ориентированного анализа и проектирования, фазы водопадного процесса, представленные Якобсоном, также включают в себя фазу анализа. На рис. 1.11 показано, где эта фаза совпадает с классическими фазами водопадного процесса. Анализ состоит из той части процесса анализа требований, в которой выбираются и соотносятся между собой базовые классы приложения. Кроме того, в USDP отсутствует своя фаза интеграции, обычно представленная в классическом водопадном процессе. Это произошло в связи с убежденностью Буча [15] в том, что объектно-ориентированные приложения могут и должны использовать непрерывную интеграцию. Другими словами, сразу после добавления новых частей исходное приложение интегрируется. Таким образом, отпадает необходимость в специальной фазе интеграции.

Рис. 1.11. Различия между USDP и стандартной терминологией (1)

Рис. 1.12. Различия между USDP и стандартной терминологией (2)

Приблизительный тип и уровень работ для каждого базового рабочего итерационного процесса USDP показан на рис. 1.13. Большинство итераций в разной степени затрагивают практически все фазы водопадного процесса (базовые рабочие процессы). Начальные начальные итерацииитерации;начальныеНачало, итерация USDPитерации USDP;Началоитерации содержат в основном анализ требований, непосредственно анализ, а также могут включать проектирование и реализацию для создания предварительного прототипа, который может быть использован для обсуждения проекта с заинтересованными сторонами. Итерации Проектирование, итерация USDPитерации;проектированияитерации USDP;Проектированиепроектирования затрагивают в основном анализ требований, а также некоторую часть проектирования и реализации. Итерации конструированияКонструирование, итерация USDPитерации;конструированияитерации USDP;Конструирование включают в себя проектирование и реализацию, а итерации Переход, итерация USDPитерации;переходаитерации USDP;Переходперехода — реализацию и тестирование.

Рис. 1.13. Матрица USDP

USDP описывает шесть моделейпроектирование, моделимодели;проектирования (типов рассмотрения свойств приложения) (рис. 1.14). Эти модели будут обсуждаться в дальнейшем, при этом не всегда будет использоваться терминология USDP. Модель вариантов использованиямодель;вариантов использованиявариантов использования, модель описывает случаи, в которых приложение будет использоваться. Аналитическая модельаналитическая модельмодель;аналитическая описывает базовые классы для приложения. Модель проектированиямодель;проектирования описывает связи и отношения между классами и выделенными объектами. Модель развертываниямодель;развертывания описывает распределение программного обеспечения по компьютерам. Модель реализациимодель;реализацииреализация;модель описывает внутреннюю организацию программного кода. Модель тестированиямодель;тестированиятестирование;модель состоит из тестирующих компонентов, тестовых процедур и различных вариантов тестирования.

Рис. 1.14. Шесть моделей приложения в USDP

1.4.5. Сравнение процессов разработки

Характеристики особенностей, данные автором, для чистого водопадного, спирального и инкрементального процессовразработка программного обеспечения;модели;сравнениепроцесс разработки;выборпроцесс разработки;сравнение моделей, приведены в табл. 1.1. Для каждого проекта конкретные факторы могут сильно влиять на представленные здесь оценки. Например, автор оценивает «Сбор метрических данных внутри проекта» как более тяжелый для чистого водопадного процесса, так как метрические данные, собранные о каждой фазе, не могут быть прямо использованы в рамках этого проекта (однако могут быть использованы для будущих проектов). В то же время в спиральном процессе данные, собранные на предыдущих итерациях (например, количество строк кода, введенных за час), могут использоваться на последующих итерациях.

Таблица 1.1. Издержки процессов разработки

Далее следуют пояснения к табл. 1.1.

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

·  Шаги спиральной разработки достаточно немногочисленны, что позволяет проектировать на весьма высоком уровне, но в то же время их достаточно много, чтобы обеспечить проектировщикам растущее понимание проблем проекта. Это преимущество объясняет широкое использование спирального метода.

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