Модели жизненного цикла аппаратно-программного средства (АПС), их достоинства и недостатки

Модели жизненного цикла Наиболее часто говорят о следующих моделях жизненного цикла: Каскадная водопадная или последовательная Итеративная и инкрементальная – эволюционная гибридная смешанная Спиральная spirl или модель Боэма Легко обнаружить что в разное время и в разных источниках приводится разный список моделей и их интерпретация. Например ранее инкрементальная модель понималась как построение системы в виде последовательности сборок релизов определенной в соответствии с заранее подготовленным планом и заданными уже...

2014-06-18

192.04 KB

6 чел.


Поделитесь работой в социальных сетях

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


Модели жизненного цикла аппаратно-программного средства (АПС), их достоинства и недостатки..

Модели жизненного цикла

Наиболее часто говорят о следующих моделях жизненного цикла:

  •  Каскадная (водопадная) или последовательная
  •  Итеративная и инкрементальная – эволюционная (гибридная, смешанная)
  •  Спиральная (spiral) или модель Боэма

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

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

Каскадная (водопадная) модель

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

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

На рисунке изображены типичные фазы каскадной модели жизненного цикла и соответствующие активы проекта, являющиеся для одних фаз выходами, а для других - входами. Марри Кантор [Кантор, 2002, с.145-146] отмечает ряд важных аспектов, характерных для водопадной модели: “Водопадная схема включает несколько важных операций, применимых ко всем проектам:

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

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

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

Фредерик Брукс во втором издании своего классического труда “Мифический человеко-месяц” так описывает главную беду каскадной модели [Брукс, 1995, с.245]:

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

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

Итеративная и инкрементальная модель – эволюционный подход

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

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

Эволюционная модель подразумевает не только сборку работающей (с точки зрения результатов тестирования) версии системы, но и её развертывание в реальных операционных условиях с анализом откликов пользователей для определения содержания и планирования следующей итерации. “Чистая” инкрементальная модель не предполагает развертывания промежуточных сборок (релизов) системы и все итерации проводятся по заранее определенному плану наращивания функциональности, а пользователи (заказчик) получает только результат финальной итерации как полную версию системы. С другой стороны, Скотт Амблер [Ambler, 2004], например, определяет эволюционную модель как сочетание итеративного и инкрементального подходов. В свою очередь, Мартин Фаулер [Фаулер, 2004, с.47] пишет: “Итеративную разработку называют по-разному: инкрементальной, спиральной, эволюционной и постепенной. Разные люди вкладывают в эти термины разный смысл, но эти различия не имеют широкого признания и не так важны, как противостояние итеративного метода и метода водопада.”

Брукс пишет [Брукс, 1995, с.246-247], что, в идеале, поскольку на каждом шаге мы имеем работающую систему:

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

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

Рисунок 3. Снижение неопределенности и инкрементальное расширение функциональности при итеративной организация жизненного цикла.

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

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

Спиральная модель (представлена на рисунке 4) была впервые сформулирована Барри Боэмом (Barry Boehm) в 1988 году [Boehm, 1988]. Отличительной особенностью этой модели является специальное внимание рискам, влияющим на организацию жизненного цикла.

Боэм формулирует “top-10” наиболее распространенных (по приоритетам) рисков (используется с разрешения автора):

  1.  Дефицит специалистов.
  2.  Нереалистичные сроки и бюджет.
  3.  Реализация несоответствующей функциональности.
  4.  Разработка неправильного пользовательского интерфейса.
  5.  “Золотая сервировка”, перфекционизм, ненужная оптимизация и оттачивание деталей.
  6.  Непрекращающийся поток изменений.
  7.  Нехватка информации о внешних компонентах, определяющих окружение системы или вовлеченных в интеграцию.
  8.  Недостатки в работах, выполняемых внешними (по отношению к проекту) ресурсами.
  9.  Недостаточная производительность получаемой системы.
  10.  “Разрыв” в квалификации специалистов разных областей знаний.

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

Рисунок 4. Оригинальная спиральная модель жизненного цикла разработки по Боэму (используется с разрешения автора) [Boehm, 1988]

Сам Барри Боэм так характеризует спиральную модель разработки (используется с разрешения автора):

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

Спиральная модель обладает рядом преимуществ: Модель уделяет специальное внимание раннему анализу возможностей повторного использования. Это обеспечивается, в первую очередь, в процессе идентификации и оценки альтернатив. Модель предполагает возможность эволюции жизненного цикла, развитие и изменение программного продукта. Главные источники изменений заключены в целях, для достижения которых создается продукт. Подход, предусматривающий скрытие информации о деталях на определенном уровне дизайна, позволяет рассматривать различные архитектурные альтернативы так, как если бы мы говорили о единственном проектном решении, что уменьшает риск невозможности согласования функционала продукта и изменяющихся целей (требований). Модель предоставляет механизмы достижения необходимых параметров качества как составную часть процесса разработки программного продукта. Эти механизмы строятся на основе идентификации всех типов целей (требований) и ограничений на всех “циклах” спирали разработки. Например, ограничения по безопасности могут рассматриваться как риски на этапе специфицирования требований. Модель уделяет специальное внимание предотвращению ошибок и отбрасыванию ненужных, необоснованных или неудовлетворительных альтернатив на ранних этапах проекта. Это достигается явно определенными работами по анализу рисков, проверке различных характеристик создаваемого продукта (включая архитектуру, соответствие требованиям и т.п.) и подтверждение возможности двигаться дальше на каждом “цикле” процесса разработки. Модель позволяет контролировать источники проектных работ и соответствующих затрат. По-сути речь идет об ответе на вопрос – как много усилий необходимо затратить на анализ требований, планирование, конфигурационное управление, обеспечение качества, тестирование, формальную верификацию и т.д. Модель, ориентированная на риски, позволяет в контексте конкретного проекта решить задачу приложения адекватного уровня усилий, определяемого уровнем рисков, связанных с недостаточным выполнением тех или иных работ. Модель не проводит различий между разработкой нового продукта и расширением (или сопровождением) существующего. Этот аспект позволяет избежать часто встречающегося отношения к поддержке и сопровождению как ко “второсортной” деятельности. Такой подход предупреждает большого количество проблем, возникающих в результате одинакового уделения внимания как обычному сопровождению, так и критичным вопросам, связанным с расширением функциональности продукта, всегда ассоциированным с повышенными рисками.

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

Описывая созданную спиральную модель, Боэм обращает внимание на то, что обладая явными преимуществами по сравнению с другими взглядами на жизненный цикл, необходимо уточнить, детализировать шаги, т.е. циклы спиральной модели для обеспечения целостного контекста для всех лиц, вовлеченных в проект (Боэм это формулирует так: “Needforfurtherelaborationofspiralmodelsteps. In general, the spiral model process steps need further elaboration to ensure that all software development participants are operating in a consistent context.”). Организация ролей (ответственности членов проектной команды), детализация этапов жизненного цикла и процессов, определение активов (артефактов), значимых на разных этапах проекта, практики анализа и предупреждения рисков – все это вопросы уже конкретного процессного фреймворка или, как принято говорить, методологии разработки.

Действительно, детализация процессов, ролей и активов – вопрос методологии. Однако, рассматривая (спиральная) модель разработки, являясь концептуальным взглядом на создание продукта, требует, как и в любом проекте, определения ключевых контрольных точек проекта - milestones. Это, в большой степени, связано с попыткой ответить на вопрос “где мы?”. Вопрос, особенно актуальный для менеджеров и лидеров проектов, отслеживающих ход их выполнения и планирующих дальнейшие работы.

В 2000 году [Boehm, 2000], представляя анализ использования спиральной модели и, в частности, построенного на его основе подхода MBASE - Model-Based (System) Architecting and Software Engineering (MBASE), Боэм формулирует 6 ключевых характеристик или практик, обеспечивающих успешное применение спиральной модели:

  1.  Параллельное, а не последовательное определение артефактов (активов) проекта
  2.  Согласие в том, что на каждом цикле уделяется внимание::
    •  целям и ограничениям, важным для заказчика
    •  альтернативам организации процесса и технологических решений, закладываемых в продукт
    •  идентификации и разрешению рисков
    •  оценки со стороны заинтересованных лиц (в первую очередь заказчика)
    •  достижению согласия в том, что можно и необходимо двигаться дальше
  3.  Использование соображений, связанных с рисками, для определения уровня усилий, необходимого для каждой работы на всех циклах спирали.
  4.  Использование соображений, связанных с рисками, для определения уровня детализации каждого артефакта, создаваемого на всех циклах спирали.
  5.  Управление жизненным циклом в контексте обязательств всех заинтересованных лиц на основе трех контрольных точек:
    •  Life Cycle Objectives (LCO)
    •  Life Cycle Architecture (LCA)
    •  Initial Operational Capability (IOC)
  6.  Уделение специального внимания проектным работам и артефактам создаваемой системы (включая непосредственно разрабатываемое программное обеспечение, ее окружение, а также эксплуатационные характеристики) и жизненного цикла (разработки и использования).

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

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

  •  Concept of Operations (COO) – концепция <использования> системы;
  •  Life Cycle Objectives (LCO) – цели и содержание жизненного цикла;
  •  Life Cycle Architecture (LCA) – архитектура жизненного цикла; здесь же возможно говорить о готовности концептуальной архитектуры целевой программной системы;
  •  Initial Operational Capability (IOC) – первая версия создаваемого продукта, пригодная для опытной эксплуатации;
  •  FinalOperationalCapability (FOC) – готовый продукт, развернутый (установленный и настроенный) для реальной эксплуатации.

Таким образом, мы приходим к возможному современному взгляду (см., например, представление спиральной модели в [Фатрелл, Шафер и Шафер, 2003, с.159]) на итеративный и инкрементальный – эволюционный жизненный цикл в форме спиральной модели, изображенной на рисунке 5.

Рисунок 5. Обновленная спиральная модель c контрольными точками проекта. (данное представление создано Сергеем Орликом на основе оригинальной модели Боэма и ее модификациях)

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

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

  •  Rational Unified Process (RUP)
  •  Enterprise Unified Process (EUP)
  •  Microsoft Solutions Framework (MSF) в обоих представлениях: MSF for Agile и MSF for CMMI (анонсированная изначально как “MSF Formal”)
  •  Agile-практики (eXtreme Programming (XP), Feature Driven Development (FDD), Dynamic Systems Development Method (DSDM), SCRUM,...).

PAGE  13



 

Другие похожие работы, которые могут вас заинтересовать.
358. Определения аппаратно-программного средства и его жизненного цикла 28.92 KB
  Существует общее соглашение о выделении четырех обобщенных фаз жизненного цикла в скобках приведены используемые в различных источниках альтернативные термины: концепция инициация идентификация отбор определение анализ выполнение практическая реализация или внедрение производство и развертывание проектирование или конструирование сдача в эксплуатацию инсталляция тестирование и т. Модель или парадигма жизненного цикла определяет концептуальный взгляд на организацию жизненного цикла и часто основные фазы жизненного цикла и...
1329. Ломбард: достоинства и недостатки 37.75 KB
  Развитие деятельности ломбардов на различных этапах экономики Первые письменные упоминания греческих и римских летописцев о ломбардах свидетельствуют об их существовании в древнем Китае свыше 3000 лет тому назад. Желание освободиться от гнета ростовщиков бравших огромные проценты за свои услуги вызвало в средние века несколько попыток организовать учреждения имевшие сходные черты с современными ломбардами. Эти учреждения являлись казенными ломбардами...
1344. Страховой рынок и услуги: достоинства и недостатки 29.7 KB
  Цель данного реферата выяснить что такое страховой рынок какие услуги он предоставляет и каковы его достоинства и недостатки. Элементы страхового рынка Страховой рынок представляет собой сложную многофакторную динамическую систему. Страховой рынок представляет диалектическое единство двух систем внутренней системы и внешнего окружения.
5325. Теория лидерских качеств. Достоинства и недостатки 42.36 KB
  Лидер - человек, который создает образ привлекательного будущего и доводит его до сознания своих последователей. Истинные лидеры - это не те, кто занимает высокие посты или имеет власть, а те, кто владеет сердцами и умами людей
19579. Источники маркетинговой информации: внешние, внутренние, достоинства и недостатки 760.57 KB
  Общепризнанно, что одним из ключевых факторов успеха компании на рынке является своевременное получение достоверной и полной информации об изменениях во внешней среде, а также ее эффективный анализ и правильная интерпретация. В течение последних лет из-за высокой скорости изменений в окружающем мире объем информации, требующей сбора и анализа, стремительно увеличивается. Периодические издания, телеканалы, радиостанции, информационные агентства, интернет-ресурсы ежедневно сообщают тысячи самых разнообразных фактов
2189. Понятие жизненного цикла ПО 185.18 KB
  Процессы жизненного цикла ПО по ISO 12207 Основные процессы Поддерживающие процессы Организационные процессы Адаптация Приобретение ПО; Передача ПО в использование; Разработка ПО; Эксплуатация ПО; Поддержка ПО Документирование; Управление конфигурациями; Обеспечение качества; Верификация; Валидация; Совместные экспертизы; Аудит; Разрешение проблем Управление проектом; Управление инфраструктурой; Усовершенствование процессов; Управление персоналом Адаптация описываемых стандартом процессов под нужды конкретного проекта Процессы строятся из...
20177. Анализ жизненного цикла продукции 190.29 KB
  Данная тема является особенно актуальной в современное время, так как жизненный цикл продукции имеет большое значение. Во-первых, он ориентирует руководителей на проведение анализа деятельности предприятия с точки зрения как настоящих, так и будущих позиций. Во-вторых, жизненный цикл товара нацеливает на проведение систематической работы по планированию и разработке новой продукции. В-третьих, данная тема помогает формировать комплекс задач и обосновывать стратегии и мероприятия маркетинга на каждом этапе жизненного цикла
356. Основные процессы жизненного цикла 11.91 KB
  Основные процессы жизненного цикла Приобретение Процесс приобретения как его называют в ГОСТ – “заказа†определяет работы и задачи заказчика приобретающего программное обеспечение или услуги связанные с ПО на основе контрактных отношений. Процесс приобретения состоит из следующих работ названия ГОСТ 12207 даны в скобках если предлагают другой перевод названий работ оригинального стандарта: Initittion – инициирование подготовка Requestforproposl preprtion – подготовка запроса на предложение подготовка заявки на подряд...
16247. Стратегический выбор компании с учетом этапа ее жизненного цикла 26.41 KB
  В условиях рыночной экономики выступая на рынке самостоятельным субъектом хозяйствования компании должны обладать определенной устойчивостью функционирования и развития. Учитывая сложную экономическую ситуацию вызванную мировым финансовым кризисом устойчивость функционирования и развития компании приобретает большое значение. Обладая данной информацией о развитии компании руководитель имеет возможность прогнозировать различные кризисные явления которые...
16487. ИНТЕГРИРОВАННАЯ ЛОГИСТИЧЕСКАЯ ПОДДЕРЖКА ЖИЗНЕННОГО ЦИКЛА НАУКОЕМКОЙ ПРОДУКЦИИ 80.35 KB
  Определение в западной терминологии дефиниции ИЛП связано с существенным изменением требований предъявляемых к надежности сложной техники: для сложной НП нуждающейся в ремонтном обслуживании и имеющей длительный срок использования затраты возникающие на этапе эксплуатации как правило в несколько раз превышают затраты на приобретение изделия. Поэтому создание и внедрение систем ИЛП в первую очередь было связано с поддержкой ЖЦ объектов сложной техники на этапе эксплуатации и их главные задачи заключаются в предотвращении неоправданных...
© "REFLEADER" http://refleader.ru/
Все права на сайт и размещенные работы
защищены законом об авторском праве.