Жизненный цикл

Версия от 00:38, 19 июля 2016; Admin (обсуждение | вклад) (Стадии жизненного цикла)

Жизненный цикл системы (system life cycle) — это деятельность всех обеспечивающих систем, ведущих целевую систему от её замысла до вывода из эксплуатации, обычно эта деятельность разбита на стадии, которые вполне могут быть не только последовательными, но и перекрываться во времени друг с другом. Когда говорят “управление жизненным циклом” как раз говорят об управлении деятельностью (управлении обеспечивающей системой), обеспечивающей переход от одной стадии жизненного цикла к другой.

Жизненный цикл проекта (project life cycle) — это часть жизненного цикла системы, которая укладывается в рамки проекта. Иногда жизненный цикл проекта совпадает во времени с какой-то стадией жизненного цикла, иногда не совпадает. Более того, совершенно необязательно, что в рамки жизненного цикла проекта (деятельности проекта) попадает вся деятельность какой-то стадии жизненного цикла системы. Проект обычно бьётся на этапы (чтобы хоть как-то отделять этапы проекта от стадий жизненного цикла).

Рабочие продукты

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

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

Стадии жизненного цикла выделяют по изменению в ходе жизненного цикла преимущественного образа мышления (в ISO 24744 — change of mental framework). Это не слишком формальное определение, но оно как минимум не предлагает сосредотачиваться на “состоянии целевой системы”, а даётся именно в терминах обеспечивающих систем. На разных стадиях жизненного цикла системы люди думают про разное: на стадии проектирования люди думают о проектировании, на стадии строительства о стройке, на стадии эксплуатации — об эксплуатации.

В системной инженерии выделяют следующие стадии ЖЦ (стадии разбиваются на этапы):

  1. Разработка концепции (Copcept Development)
    Concept-dev.png
    1. Анализ потребностей - выявляется потребность в новой системе (действительно ли она нужна, существует ли практический способ удовлетворить потребность).
      Инструменты и методики на этом этапе относятся к двум областям математики: анализ операций и исследование операций. Помимо математического изучения проблемы производится также анализ технологий (см. Управление технологиями) и ставятся эксперименты.
    2. Исследование концепции - разрабатывается начальный набор требований, исследуются возможные варианты концепции (удовлетворяющие нужды, с приемлимыми затратами).
      Инструменты и методики относятся к процессному подходу (например, анализ требований), математические методы (например, поддержки принятия решений) и экспертных оценок (например, мозговой штурм).
    3. Определение концепции - определяется предпачтительная концепция (достигается благоприятный баланс между функциональными возможностями, сроком службы и стоимостью). Сравнивают характеристики, практическую полезность, риски разработки и стоимость альтернативных концепций.
      Инструменты и методики можно разбить на две категории: анализ альтернатив (частная разновидность исследования операций) и построение архитектуры системы.
  2. Разработка инженерно-технического решения (Engineering Development)
    Engineering-dev.png
    1. Эскизное проектирование - минимизируется число невыявленных концепцией проблем. Задачи: 1) идентификация и снижение рисков разработки; 2) разработка проектной документации на систему и модель (макет, образец), прошедшая валидацию.
      На этой стадии применяются экспериментальные модели и имитационное моделирование, цель которых - снизить затраты на валидацию концепций, рекомендованных в качестве основы при проектировании компонентов и подсистем.
    2. Техническое проектирование - возможность заказчику и пользователю системы ознакомиться с проектом на ранних этапах, проконтролировать выполнение бюджета и графика, высказать разработчику полезные критические замечания. Системный инженер отвечает за совместимость отдельных компонентов (соответствие требованиям к функциональности и совместимости), а также за то, чтобы при изменениях не нарушались интерфейсы и конфигурация (управление изменениями). На этом этапе уточняется программы испытаний и аттестации, а также создается прототип (виртуальный, физический или гибридный).
      Инструменты: САПР. Модели системы и имитационные модели должны соответствовать текущему состоянию проекта и результатам испытаний.
    3. Комплексирование и аттестация - проверяется согласованность интерфейсов компонентов, их взаимодействие в соответствии с функциональными требованиями. Часто требуется разработка и конструирование вспомогательных комплексов, делающих возможными имитацию эксплуатационных воздействий и ограничений. Результатами являются: 1) спецификации на изготовление системы (технические условия на производство системы) и 2) готовая система (все необходимое для производства и сборки и, возможно, прототип).
      Могут помочь методики комплексирования, инструменты, методы, средства и принципы испытаний и аттестации.
  3. Постразработческая стадия (Postdevelopment)
    1. Производство - на этом этапе возможны неожиданные проблемы (ошибки в программах, сбои в ходе заводских испытаний). Системный инженер должен диагностировать источник проблемы и найти эффективное решение.
    2. Эксплуатация и сопровождение - планирование этого этапа подразумевает подготовку логистической системы и программ обучения операторов и ремонтного персонала. На протяжение срока эксплуатации возможно обновление системы, обусловленное эволюцией ее целей и задач, а также техническим прогрессом.

Управление жизненным циклом

см. Управление жизненным циклом

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

См. также обзор: http://mydotnetcoolfaqs.blogspot.ru/2011/04/

Водопадная (каскадная)

Модель, в которой жизненный цикл выглядит как поток, последовательно проходящий фазы анализа требований, проектирования, реализации, тестирования, интеграции и поддержки.

Отдельные практики выполняются последовательно, как вода проходит каскад. Все рабочие продукты стадий проходят hand over (передачу) на следующую стадию, и дальше не меняются, а используются для получения продуктов этой стадии. Ключевая предпосылка “водопада” — это то, что практики совпадают со стадиями жизненного цикла. То есть “проектирование” — это и практика, и стадия жизненного цикла. “Тестирование” — это и практика, и название жизненного цикла. В реальной жизни выполнение работ каждой практики-стадии вызывает необходимость обращения к уже прошедшим практикам (но их стадии-то прошли, и ресурсов на них уже нет, и рабочие продукты уже считаются сданными!). Ужас в том, что возвращаться назад приходится часто не на одну стадию-практику-ступеньку, а сразу на несколько, в том числе бывает, что и с последней на первую!

Спиральная

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

Придумана Barry Boehm. Разработка происходит “по спирали”, в которой одновременно выполняется цикл из нескольких практик, поэтому практики и стадии жизненного цикла оказались разъединены. Проблема остается: практики последовательно выполняются на каждом витке спирали, т.е. сохраняется “микроводопад”.

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

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

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

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

  • оценка и разрешение рисков,
  • определение целей,
  • разработка и тестирование,
  • планирование.

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

V-диаграмма

Используется чаще всего, чтобы пояснять самые общие черты системноинженерного процесса/метода/жизненного цикла:

  • Фундаментальную разницу между практиками определения системы (работы с информацией), реализации системы (работы с веществами и полями), а также использованием системы. В том числе на V-диаграмме показывается основная идея системной инженерии “восемь раз отмерь, один раз отрежь”: рекомендуется максимизировать трату ресурсов на более ранних стадиях, чтобы потом экономить трату много больших ресурсов на более поздних стадиях.
  • Соответствие определений и воплощений системы, поддерживаемое через проверки (верификация) и приёмки (валидация).
  • Ведущие практики жизненного цикла (дисциплины-рабочие продукты- инструменты).
  • Разницу между системноинженерными практиками (выше пунктирной линии), имеющими дело с системой в целом и “обычными” инженерными практиками, имеющие дело с частями системы.
  • Взаимодействие между практиками: работа идёт отнюдь не по той практике-стадии, которой соответствует точка времени на диаграмме! Нет, одновременно задействована вся “вертикаль” практик — архитектор общается и с инженерами по требованиям, и с занимающимися рабочим проектированием, а инженер-интегратор общается и с эксплуатационщиками, и с производителями оборудования.

Эта простейшая диаграмма имеет огромное число вариаций и модификаций (например Dual V-model).

Горбатая диаграмма

На этой диаграмме phases (фазы) это стадии жизненного цикла, которые в свою очередь разбиты на итерации. Практики названы “дисциплинами”. Чётко видно, что работы по требованиям продолжаются вплоть до стадии передачи в эксплуатацию (transition), а тестирование начинается на начальных стадиях, а не только при подготовке к передаче в эксплуатацию.

Agile

см. Agile

Практики (processes) жизненного цикла в версии ISO 15288

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

Для некрупных проектов этот стандарт избыточен.

Паттерны жизненного цикла

Паттерны жизненного цикла выделяют в зависимости от распределения различных рисков по стадиям жизненного цикла (см.):

  • Купи готовое (Use Single NDI),
  • Гибкий (Agile),
  • Гибкий с архитектурой (Architected Agile),
  • Формальные методы (Formal Methods),
  • Оборудование с программными компонентами (Hardware with embedded Software component),
  • Неделимость для начала эксплуатации (Indivisible Initial Operational Capability),
  • Много закупок (NDI-intensive) — проектирование (в отличие от конструирования),
  • Гибрид гибкости и плана (Hybrid agile/plan-driven system),
  • Много собственников в системе систем (Multi-owner system of systems),
  • Семейство систем (Family of systems),
  • Brownfield (модернизация),
  • Акцент на сервисах (Services-Intensive).