Этапы разработки ПО при использовании спиральной модели

Этапы разработки	Этапы (подэтапы) жизненного цикла, отдельные работы
Проектирование продукта	Разработка предложений Разработка требований к продукту Заключение контракта Разработка внешней структуры Разработка внутренней структуры Разработка спецификации Моделирование
Реализация базовых функций	Постановка задачи Проектирование Кодирование Тестирование модуля (как «стеклянного ящика»)
Разработка версии «Почти альфа»	Постановка задачи Проектирование Кодирование Исправление ошибок Тестирование модулей
Разработка Альфа - версии	Кодирование Тестирование модулей Доработка проектных документов Исправление ошибок Написание драйверов устройств Начало разработки контрольного примера
Разработка версии «Пре-бета»	Исправление ошибок
Разработка Бета - версии	Завершение реализации функций Исправление ошибок Пересмотр пользовательского интерфейса Написание установочных утилит Работа над драйверами устройств Разработка примеров Подготовка дисков для бета-тестировщиков
Замораживание пользовательского интерфейса	Осуществление изменений, не отражающихся на пользовательском интерфейсе Исправление ошибок Работа над повышением производительности программы Формирование окончательного варианта данных Формирование окончательного варианта программы установки Формирование окончательной конфигурации дисков
Подготовка к финальному тестированию	Исправление ошибок
Последняя проверка целостности	Исправление ошибок Кодирование демонстрационных материалов Архивация исходного кода
Выпуск продукта	Тестирование программного продукта заказчиком Оформление акта приемки-сдачи системы

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

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

Структурная  эволюционная модельбыстрого прототипирования (рис.4) сохраняет некоторые свойства спиральной модели.

 

 

 

 

Рис. 4. Структурная эволюционная модель быстрого прототипирования.

 

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

На рис. 4 в эллипсе выделяются четыре круга.

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

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

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

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

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

Преимущества модели быстрого прототипирования:

– конечный пользователь может сформировать системные требования в процессе разработки;

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

– возможность полноты и системности в формировании требований;

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

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

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

– не все заказчики могут согласиться с применением этой модели, поскольку разрабатываемая система имеет в данном случае репутацию как система «разработанная на скорую руку»;

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

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

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

Область применения:

– требования заранее неизвестны в полном объеме;

– требования непостоянны, существенная вероятность неверно сформулированных требований;

– выполняется новая не имеющая аналогов разработка;

– система имеет повышенную степень сложности.

Название инкрементной модели жизненного цикла ИС происходит от понятия «инкремент» (от англ. – increment) – возрастание, увеличение, прирост.

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

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

На рис. 5 тестирование рассредоточено по нескольким уровням, как это принято в V–образной модели. Вопреки утверждению разработчиков стандартов ISO/IEC 12207: 2008 и ГОСТ Р ИСО/МЭК 12207-2010 можно все же утверждать, что в данном случае инкрементная модель представляет собой сложную разветвленную каскадную модель. При этом инкрементные каскады выполнены по схеме V–образной модели, которая является частным случаем каскадной модели (см. ниже).

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

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

 

 

 

 

Рис. 5. Инкрементная модель (версия 1)

 

 

 

Рис. 6. Инкрементная модель (версия 2)

 

Преимущества инкрементной модели:

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

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

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

– заказчик и пользователь постепенно привыкают к новой технологии управления объектом.

Недостатки:

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

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

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

Область применения. Модель выбирается для проектов, на выполнение которых предусматривается большой период времени. Это достаточно удобно для ИТ-подразделения предприятия, которому поручили системную разработку «своими силами».

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

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

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

Содержание фаз тестирования:

– Модульное тестирование: выполняется проверка каждого закодированного модуля программы на наличие ошибок.

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

– Системное и приемочное тестирования: проверка функционирования программной системы в целом; при этом приемочное тестирование осуществляется в аппаратной и программной среде пользователя.

 

 

Рис. 7. V-образная модель жизненного цикла разработки ИС

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

Существуют много различных технологий тестирования.

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

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

Тестировщик «черного ящика» не изучает исходный код программы – он исследует ее извне, работая с ней, как это будет делать пользователь. И так же, как исследование программы изнутри позволяет выявить проблемы и критические точки, которые невидно извне, так и тестировщик «черного ящика» выявляет ошибки и недостатки, которые программист упускает.

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

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

Преимущества V-образной модели:

– 1) Все преимущества каскадной модели;

– 2) Создание условий для повышения качества ПП за счет повышенного внимания к тестированию, верификации, аудиту.

Недостатки:

– Такие же, как и у каскадной модели.

Область применения: те же области, которые характерны для каскадной модели. V–образная модель выбирается для систем, которые требуют повышенной надежности. Поэтому область ее применения можно дополнить АСУТП – автоматизированными системами управления техническими процессами.

Модель быстрой разработки приложений ( RAD) начала применяться в 80 – х годах прошлого века в компании IBM как альтернатива каскадной модели. По этой причине первоначально она и была разновидностью каскадной модели.

Основные особенности этой модели:

– пользователь задействован на всех фазах жизненного цикла разработки;

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

– разработка должна осуществляться в короткое время (по данным американским источников – за 60 дней, по данным отечественных источников – за 90 дней);

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

Графическое отображение модели RAD представлено на рис. 8. Несмотря на определенную стилизацию изображения достаточно хорошо видно, что это разновидность каскадной модели.

 

 

Рис. 8. Модель быстрой разработки приложений

 

Содержание этапов жизненного цикла рассматриваемой модели:

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

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

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

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

Преимущества модели RAD:

– возможность обеспечения короткого цикла разработки;

– меньшее количество специалистов-разработчиков по 2 причинам: задействование пользователей, использование специалистов, которым знакома предметная область;

– уменьшение затрат на проектирование;

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

Недостатки:

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

– квалификация разработчиков должна быть достаточно высокой в том смысле, что они должны в совершенстве владеть применяемыми CASE–средствами.

Область применения:

– при разработке систем требования, к которым достаточно хорошо известны;

– пользователь готов принимать участие в разработке на постоянной основе;

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

– для разработки системы, которая предназначена для концептуальной проверки, является некритической и имеет небольшой размер;

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

После появления спиральной модели жизненного цикла ИС появилась возможность реализации модели быстрой разработки приложений как разновидности спиральной модели (рис. 9).

 

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

Более подробное описание рассмотренных моделей жизненного цикла см. в работе [14].