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

·         Подготовка (сбор требований)

·         Планирование (оценка, расписание)

·         Моделирование (анализ требований, проектирование)

·         Конструирование (кодирование, интеграция, тестирование)

·         Развертывание (поставка, внедрение и сопровождение)

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

Стратегии разработки ПО

Существуют три основные стратегии разработки  ПО

1.       Однократный подход. Данная стратегия предствляет процесс разработки как линейную последовательность этапов жизненного цикла ПО

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

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

Характеристики стратегий разработки ПО в соответствии с требованиями стандартов IEEE/EIA 12207.2-1997 и ГОСТ ИСО/МЭК ТО 15271-2002 приведены в таблице 1.

Стрегия разработки	В начале процесса определены все требования?	Множество циклов разработки?	Промежуточное ПО распростаняется?
Однократный подход	ДА	НЕТ	НЕТ
Инкрементная стратегия	ДА	ДА	Может быть
Эволюционная стратегия	НЕТ	ДА	ДА

 

 

Каскадная модель жизненного цикла

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

Достоинства модели:

·         Простота планирования процесса разработки (составление точного плана работ и временного графика)

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

Недостатки модели:

·         Неудачные решения на одной стадии разработки ставит под угрозу всю разработку

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

·         Результаты проекта доступны заказчику только в конце работы.

 

Инкрементная модель

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

Разработка прототипа (инкремент) в инкрементной модели происходит в рамках этапов каскадной модели «анализ требований - определение спецификаций – проектирование- кодирование - тестирование».

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

 

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

 

Достоинства модели:

·         Простота планирования процесса разработки (составление точного плана работ и временного графика)

·         Получение после каждого инкремента работающего ПО, с которым может ознакомиться заказчик.

Недостатки модели:

·         Заказчик может принять прототип за продукт.

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

·         Разработка основана на точной формулировке требований к ПО.

 

Модель быстрой  разработки приложений (RAD)

Модель быстрой разработки приложений RAD (Rapid Application Development) – второй пример реализации инкрементной стратеги разработки.

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

Для технологии  RAD характерны следующие признаки:

•   использование компонентно-ориентированного принципа разработки

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

•   использование итерационного подхода (что способствует уменьшению времени получения работоспособного прототипа);

•   наличие четко проработанного графика цикла, рассчитанного на  60-90 дней ( что  существенно увеличивает эффективность работы).

При использовании технологии RAD акцент делается на следующих процессах в рамах классического жизненного цикла. 

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

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

Под функциональной точкой в технологии RAD понимают любой из следующих функциональных элементов разрабатываемой системы:

•   входной элемент приложения (входной документ или экранная форма);

•   выходной элемент приложения (отчет, документ или экранная форма);

•   запрос (пара «вопрос/ответ»);

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

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

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

•   менее 1 тыс. функциональных точек - 1 человек;

•   от 1 до 4 тыс. функциональных точек - одна команда разработчиков;

•   более 4 тыс. функциональных точек - одна команда на каждые 4 тыс.точек.

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

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

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

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

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

Однако применение RAD имеет следующие недостатки и ограничения.

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

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

·         Технология не применима в условиях технических рисков, то есть при использовании новой технологии.

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

 

 

Спиральная модель

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

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

 

 

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

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

С каждой итерацией по спирали строятся все более полные версии ПО.

 

Достоинства модели:

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

·         Позволяет явно учитывать риск на каждом витке эволюции разработке

·         Позволяет заинтересовать большое количество пользователей, обеспечивая быстрое продвижение следующих версий продукта на рынке

Недостатки модели:

·         Повышенные требования к заказчику.

·         Трудности контроля и управления временем разработки

·         Трудности определения момента перехода на  следующие стадии (обычно используются оценки экспертов)

 

Компонентно-ориентированная модель

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

Достоинства:

·         уменьшается время разработки (примерно 30%);

·         уменьшается стоимость программной разработки (примерно 70%).

 

XP-процессы

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

Тяжеловесные (heavyweight) – полностью прогнозируемые документированные процессы, при которых порядок спланированных работ не должен меняться

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

Экстремальное программирование (eXtreme Programming, XP) – облегченный (подвижный) процесс, главный автор которого Кент Бек (1999 г.).

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

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

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

Базис ХР образуют перечисленные ниже двенадцать методов.

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

2.          Частая смена версий (Small release) — быстрый запуск в производство простой системы. Новые версии реализуются в очень коротком (двухнедельном) цикле.

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

3.    Метафора (Metaphor) — вся разработка проводится на основе простой, общедоступной истории о том, как работает вся система. «Метафора» обеспечивает глобальное «видение» проекта. Она могла бы рассматриваться как высокоуровневая архитектура, но ХР подчеркивает желательность проектирования при минимизации проектной документации.

4.    Простое проектирование (Simple design) — проектирование выполняется настолько просто, насколько это возможно в данный момент.

5.    Тестирование (Testing) — непрерывное написание тестов для модулей, которые должны выполняться безупречно; заказчики пишут тесты для демонстрации законченности функций. «Тестируй, а затем кодируй» означает, что тестовые варианты разрабатываются параллельно анализу требований. Размышление о тестировании в начале цикла жизни — хорошо известная практика конструирования ПО (правда, редко осуществляемая практически).

6.          Реорганизация (Refactoring) — система реструктурируется, но ее поведение не изменяется; цель — устранить дублирование, улучшить взаимодействие, упростить систему или добавить в нее гибкость. Реорганизация, т.е. непрерывное перепроектирование не требует детализированной проектной документации. Обычно после написания кода проектная документации выбрасывается. Проектная документация сохраняется только в том случае, если заказчик временно не придумывает новые истории (краткие описания того, что должно быть сделано). Тогда систему помещают в «нафталин» и пишут руководство на 5-10 страниц по «нафталиновому» варианту системы. Использование реорганизации приводит к реализации простейшего решения, удовлетворяющего текущую потребность. Изменения в требованиях заставляют отказываться от всех «общих решений».

7.          Парное программирование (Pair programming) — весь код пишется двумя программистами, работающими на одном компьютере. (Это одна из наиболее спорных идей в XP. Может показаться, что парное программирование удваивает ресурсы, но исследования показали, что для согласованной группы затраты увеличиваются на 15%, а время цикла сокращается на 40-50%, причем качество повышается. Для интернет-среды увеличение скорости продаж покрывает повышение затрат).

8.          Непрерывная интеграция (Continuous integration) — система интегрируется и строится много раз в день, по мере завершения каждой задачи. Непрерывное регрессионное тестирование, то есть повторение предыдущих тестов, гарантирует, что изменения требований не приведут к регрессу функциональности.

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

10.          40-часовая неделя (40-hour week) — как правило, работают не более 40 часов в неделю. Нельзя удваивать рабочую неделю за счет сверхурочных работ.

11.          Локальный заказчик (On-site customer) — в группе все время должен находиться представитель заказчика, действительно готовый отвечать на вопросы разработчиков.

12.          Стандарты кодирования (Coding standards) — должны выдерживаться правила, обеспечивающие одинаковое представление программного кода во всех частях программной системы.

 

Контрольные вопросы по теме

1.        Назовите и охарактеризуйте три основные стратегии разработки ПО

2.        Охарактеризуйте каскадную модель жизненного цикла ПО. К какой стратегии относится данная модель?

3.        Перечислите достоинства и недостатки каскадной модели.

4.        Охарактеризуйте инкрементную модель жизненного цикла ПО. К какой стратегии относится данная модель?

5.        Перечислите достоинства и недостатки инкрементной модели.

6.        Охарактеризуйте модель быстрой разработки приложений RAD. К какой стратегии относится данная модель?

7.        Охарактеризуйте спиральную модель жизненного цикла ПО. К какой стратегии относится данная модель?

8.        Перечислите достоинства и недостатки спиральной  модели.

9.        Охарактеризуйте компонентно-ориентированную модель жизненного цикла ПО.

10.     Что такое тяжеловесные и облегченные процессы?

11.     Охарактеризуйте XP-процесс.

12.     Охарактеризуйте двенадцать методов XP-процессов: игра планирования, частая смена версий, метафора, простое проектирование, тестирование, реорганизация, парное программирование, непрерывное интеграция, коллективное владение кодом, 40-часовая рабочая неделя, локальный заказчик, стандарты кодирования.