Модели жизненного цикла программного обеспечения

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

Модели жизненного цикла программного обеспечения

Одним из базовых понятий методологии проектирования автоматизированных систем управления является понятие жизненного цикла программного обеспечения. Жизненный цикл (ЖЦ) программного обеспечения (ПО) – это непрерывный процесс, который начинается с момента принятия решения о необходимости создания ПО и заканчивается в момент его полного изъятия из эксплуатации. Основным нормативным документом, регламентирующим ЖЦ ПО, является международный стандарт ISO/IEC 12207 (ISO – International Organization of Standardization – Международная орга­низация по стандартизации, IEC – International Electromechanical Commission – Международная комиссия по электротехнике). Он определяет структуру жизненного цикла, содержащую процессы, действия и задачи, которые должны быть выполнены во время создания и эксплуатации ПО.

Структура жизненного цикла программного обеспечения по стандарту ISO/IEC 12207 базируется на трех группах процессов [42, 43, 82, 118]:

· основные процессы ЖЦ ПО (приобретение, поставка, разработка, эксплуатация, сопровождение);

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

· организационные процессы ЖЦ ПО (управление проектами, создание инфраструктуры проекта, определение, оценка и улучшение самого ЖЦ, обучение).

Каждый процесс характеризуется определенными задачами и методами их решения, исходными данными, полученными на предыдущем этапе, и результатами. ЖЦ ПО носит итерационный характер: результаты очередного этапа часто вызывают изменения в проектных решениях, выработанных на более ранних этапах. Стандарт ISO/IЕС 12207 не предлагает конкретную модель ЖЦ и методы разработки ПО. Его регламенты являются общими для любых моделей ЖЦ, методологий и технологий разработки. Стандарт ISO/IEC 12207 описывает структуру процессов ЖЦ ПО, но не конкретизирует в деталях, как реализовать или выполнить действия и задачи, включенные в эти процессы.

Модель жизненного цикла программного обеспечения – это схематическое изображение последовательности выполнения процессов и отдельных видов работ ЖЦ ПО. Модель ЖЦ ПО зависит от специфики ПО, условий его создания и эксплуатации. Классификация моделей ЖЦ ПО дана по работе [151].

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

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

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

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

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

· модель весьма доступна для понимания, ее стадии хорошо определены;

· проста и удобна в применении, так как процесс разработки выполняется поэтапно;

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

· отличается стабильностью требований;

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

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

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

· дефекты можно обнаружить на более ранних этапах, когда их устранение еще не требует относительно больших затрат;

· облегчает работу менеджеру проекта по составлению плана и комплектации команды разработчиков;

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

· определяет процедуры по контролю за качеством, любые полученные данные по проекту подвергаются контролю;

· ход выполнения проекта легко проследить.

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

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

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

· не отображает основное свойство разработки ПО, направленное на разрешение возникающих проблем;

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

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

· у пользователей нет возможности ознакомиться с системой заранее, это происходит лишь в самом конце жизненного цикла;

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

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

· проект можно выполнить в полном соответствии с требованиями пользователей, но это не гарантирует его запуска в эксплуатацию;

· каждая фаза является предпосылкой для выполнения следующей, что делает эту модель рискованной для систем, не имеющих аналогов;

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

· все требования должны быть известны в начале ЖЦ, но пользователи редко могут сформулировать все требования на начальном этапе разработки;

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

· модель основана на документации, и ее объем может быть избыточным;

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

· отсутствует возможность учесть итерации в рамках проекта.

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

V-образная модель ЖЦ ПО была создана с целью помочь работающей над проектом команде в планировании с обеспечением дальнейшей возможности тестирования системы. В этой модели особое значение придается действиям, направленным на верификацию и аттестацию продукта. Она демонстрирует, что тестирование продукта обсуждается, проектируется и планируется на ранних этапах ЖЦ. План приемки заказчиком разрабатывается на этапе планирования, а компоновочного испытания системы — на фазах анализа, разработки проекта и т.д. Этот процесс разработки планов испытания обозначен пунктирной линией между прямоугольниками V-образной модели. V-образная модель (рис. 2.2) была разработана как разновидность каскадной модели и унаследовала от нее последовательную структуру. Каждая последующая фаза начинается после получения результатов предыдущей фазы. Модель демонстрирует комплексный подход к определению фаз процесса разработки ПО. В ней подчеркнуты взаимосвязи, существующие между аналитическими фазами и фазами проектирования, которые предшествуют кодированию, после которого следуют фазы тестирования. Пунктирные линии означают, что эти фазы необходимо рассматривать параллельно.

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

· в модели особое значение придается планированию, направленному на верификацию и аттестацию продукта на ранних стадиях его разработки;

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

· определение требований выполняется перед разработкой проекта системы, а проектирование ПО — перед разработкой компонентов;

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

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

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

Недостатки V-образной модели:

· с ее помощью непросто справиться с параллельными событиями;

· в ней не учтены итерации между фазами;

· не предусмотрено внесение динамических изменений на этапах ЖЦ;

· тестирование требований происходит слишком поздно, вследствие чего невозможно внести изменения, не повлияв при этом на график проекта;

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

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

Структурная эволюционная модель быстрого прототипирования ЖЦ ПО представлена на рис. 2.3. Прототипирование — это процесс построения рабочей модели системы. Начало ЖЦ разработки помещено в центре эллипса. Пользователь и программист разрабатывают предварительный план проекта, руководствуясь предварительными требованиями. Используя методы ускоренного анализа, пользователь и программист совместно работают над определением требований и спецификаций для важнейших частей системы. Планирование проекта — это первое действие на этапе быстрого анализа, с помощью которого получают документ, описывающий в общих чертах примерные графики и получаемые данные. Таким образом, создается план проекта, а затем выполняется быстрый анализ, после чего проектируется база данных, пользовательский интерфейс и разработка функций. Второе действие — это быстрый анализ, на протяжении которого предварительные опросы пользователей используются для разработки умышленно неполной высокоуровневой модели системы на уровне документации. В результате получают частичную спецификацию требований, которые используется для построения исходного прототипа, создаваемого на последующих трех этапах. Дизайнер конструирует модель (с использованием инструментальных средства), то есть частичное представление системы, которое включает в себя только те базовые свойства, которые необходимы для удовлетворения требований заказчика. Затем начинается итерационный цикл быстрого прототипирования. Разработчик демонстрирует прототип, а пользователь оценивает его функционирование. После этого определяются проблемы, над устранением которых совместно работают пользователь и дизайнер. Этот процесс продолжается до тех пор, пока пользователь не будет удовлетворен тем, как система выполняет предъявленные к ней требования. Получив одобрение пользователя, быстрый прототип преобразуют в детальный проект, и систему настраивают на производственное использование. Именно на этом этапе настройки ускоренный прототип становится полностью действующей системой, которая заменяет собой частичную систему, полученную в итерационном цикле прототипирования. Заключительная фаза представляет собой функционирование и сопровождение, которые отображают действия, направленные на перемещение системы в стадию производственного процесса.

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

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

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

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

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

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

· модель позволяет выполнять гибкое проектирование и разработку, включая несколько итераций на всех фазах ЖЦ;

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

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

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

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

· уменьшение объема доработок снижает затраты на разработку;

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

· обеспечивается управление рисками;

· документация сконцентрирована на продукте, а не на его разработке;

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

Недостатки структурной модели быстрого прототипирования:

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

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

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

· в результате использования модели можно получить систему с плохими характеристиками, особенно если пропускается этап подгонки;

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

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

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

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

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

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

· прототипирование вызывает зависимость и может продолжаться слишком долго, разработчики могут попасть в цикл «кодирование — устранение ошибок», что приводит к незапланированным итерациям;

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

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

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

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

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

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

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

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

Модель быстрой разработки приложений ЖЦ ПО появилась в 1980-х годах XX века. В ответ на ограничения каскадной модели компания IBM начала использовать метод быстрой разработки приложений (Rapid Application Development, RAD). Благодаря методу RAD пользователь задействован на всехфазах ЖЦ проекта — не только при определении требований, но и при проектировании, разработке, тестировании, а также конечной поставке программного продукта. Характерной чертой RAD является короткое время перехода от определения требований до создания полной системы. Метод основывается на последовательности итераций эволюционной системы или прототипов, критический анализ которых обсуждается с пользователями. В процессе такого анализа формируются требования к продукту. Разработка каждого интегрированного продукта ограничивается четко определенным периодом времени 60 - 90 дней и называется временным блоком. Факторы, позволяющие создать систему за 60 дней, включают в себя использование мощных инструментальных средств разработки, высокий уровень повторного использования ПО, а также четкое планирование и выделенные ресурсы. Решающее участие конечного пользователя заключается в перемещении процессов ЖЦ от программирования и тестирования к планированию и проектированию. Модель быстрой разработки приложений, представленная на рис. 2.4., демонстрирует этапы процесса разработки ЖЦ ПО и отображает участие пользователя на всех этапах (пунктирная линия).

Преимущества модели быстрой разработки приложений (RAD):

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

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

· можно провести быстрый начальный просмотр продукта;

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

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

· обеспечивается эффективное использование средств и структур;

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

· в состав каждого временного блока входит анализ, проектирование и внедрение (фазы отделены от действий);

· основное внимание переносится с документации на код, причем при этом работает принцип «получаете то, что видите»;

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

· в модели повторно используются существующие компоненты ПО.

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

· если пользователи не могут участвовать в процессе разработки на протяжении всего ЖЦ, это может негативно сказаться на продукте;

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

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

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

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

· при использовании модели «вслепую» на затраты и дату завершения работы над проектом ограничения не накладываются;

· команды, разрабатывающие коммерческие проекты с помощью модели RAD, могут «затянуть» разработку ПО до такой степени, что его поставка конечному пользователю будет под большим вопросом;

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

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

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

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

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

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

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

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

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

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

· пользователи могут высказаться по поводу каждой версии системы;

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

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

· график распределения рабочей силы может выравниваться посредством распределения по времени объема работы над проектом;

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

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

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

· снижаются затраты на первоначальную поставку ПО;

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

· снижается риски неудачи и изменения требований;

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

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

· пользователи могут увидеть самые важные и полезные функциональные возможности продукта на более ранних этапах разработки;

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

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

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

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

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

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

· в модели не предусмотрены итерации в рамках каждого инкремента;

· определение полной функциональной системы должно осуществляться в начале ЖЦ, чтобы обеспечить определение инкрементов;

· поскольку создание некоторых модулей будет завершено значительно раньше других, возникает необходимость в четко определенных интерфейсах;

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

· может возникнуть тенденция к переносу решения трудных проблем на будущее с целью продемонстрировать успех на ранних этапах разработки;

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

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

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

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

Спиральная модель ЖЦ ПО была впервые представлена доктором Боэмом Б. и опубликованав 1988 году, в ней учтены недостатки каскадной модели перечисленные выше. Спиральная модель воплощает в себе преимущества каскадной модели. При этом в нее также включены анализ рисков, управление ими, а также процессы поддержки и менеджмента. Здесь также предусмотрена разработка программного продукта при использовании метода прототипирования или быстрой разработки приложений. Модель отображает базовую концепцию, которая заключается в том, что каждый цикл представляет собой набор операций, которому соответствует такое же количество стадий, как и в модели каскадного процесса. Причем принимается во внимание каждая составляющая часть продукта, и каждый уровень сложности, начиная с общей формулировки потребностей и заканчивая кодированием каждой отдельной программы. Как показано на рис. 2.6, в каждый квадрант модели входят целевые и вспомогательные действия. Проектирование начинается с центра в квадранте 1 (определение целей, альтернативных вариантов и ограничений), затем исследуются риски, составляется план их разрешения, подготавливается переход к следующей итерации. Для каждой итерации следует определить цели, альтернативные варианты и ограничения; установить и разрешить риски; дать оценку альтернативным вариантам; разработать результативные данные для этой итерации и подтвердить их правильность; спланировать следующую итерацию. Затем следует выбрать метод осуществления следующей итерации в случае, если требуется ее выполнять. В квадрантах отсутствует заданное количество циклов. Их количество нужно выбирать по необходимости, а итерации можно адаптировать под определенный проект. Следует отметить тот факт, что кодирование выполняется значительно позже, чем в других моделях. Смысл заключается в том, чтобы минимизировать риск посредством последовательных уточнений требований, выдвигаемых пользователем.

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

· спиральная модель разрешает пользователям «увидеть» систему на ранних этапах;

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

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

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

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

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

· здесь не ставится цель выполнить невозможное — сразу довести систему до совершенства;

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

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

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

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

· при использовании спиральной модели не нужно распределять заранее все необходимые для выполнения проекта финансовые ресурсы;

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

Недостатки спиральной модели:

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

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

· необходимы высокопрофессиональные знания для оценки рисков;

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

· большое количество промежуточных стадий приводит к созданию и обработке дополнительной внутренней и внешней документации;

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

· при выполнении действий на этапе вне процесса разработки возникает необходимость в переквалификации или смене разработчиков;

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

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

Расценивая первоначальную спиральную модель как сложную, некоторые пользователи разработали ее упрощенную версию (рис. 2.7). На рис. 2.8 представлена модифицированная версия этой модели, созданная Консорциумом по вопросам разработки ПО (Software Productivity Consortium, SPC).

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

На основании анализа различных моделей жизненного цикла ПО, их достоинств, недостатков и областей применения можно сделать вывод о целесообразности проектирования автоматизированной системы управления для зерноперерабатывающих предприятий по спиральной модели жизненного цикла. Для обоснования сделанного вывода воспользуемся методом, предложенным в работе [151]. В таблице 2.1 сформулированы вопросы, характеризующие системные требования, коллектив разработчиков, пользователей и параметры проекта, и ответы на эти вопросы, обосновывающие возможность использования различных моделей ЖЦ ПО. Жирным шрифтом выделены ответы, характеризующие проектируемую автоматизированную систему управления для зерноперерабатывающих предприятий. В последней строке таблицы приведено количество ответов для проектируемой системы управления, удовлетворяющих области применения соответствующей модели ЖЦ ПО. Полученные результаты показывают, что характеристики проектируемой системы управления больше всего соответствуют области применения спиральной модели ЖЦ ПО (30 ответов из 32 возможных, ближайший конкурент – модель прототипирования с результатом 21), и однозначно обосновывают правильность сделанного выбора в пользу спиральной модели жизненного цикла ПО.

Таблица 2.1.

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