Версия 0.3 презентация

объект "жизненный цикл"

Версия 0.3

инженеров (системный, специальный, эксплуатант, оператор), разные объекты их интересов (внешняя среда, предприятие, проект, целевая система). Управленцы и инженеры имеют разные работы, требующие разных описаний и координации между ними.
Жизненный цикл – особый объект, который используется для координации работ управленцев и инженеров. Использование ЖЦ для этих целей явно зафиксировано и разъяснено в ISO15288 и сопутствующих руководствах.
ISO 15288 не указывает, как избежать ошибок управления жизненных циклов и как получать экземпляры жизненного цикла. Для создания экземпляра жизненного цикла для конкретного проекта требуется метод управления жизненным циклом, определяющий способ координации работ управленцев и инженеров.
Наиболее продвинутым вариантом метода управления жизненным циклом является ICM: он генерирует конкретное описание жизненного цикла в зависимости от профиля рисков конкретного проекта.
Для координации работ управленцев и инженеров через жизненный цикл требуются специальные артефакты: описание жизненного цикла, требования, «оценочное дело».

или сторона называется по выполняемой ею практике; например, если она исполняет практику поставки, она называется поставщиком.

Основные роли по группам практик
[регулятор]
Заказчик
Орг.менеджер
Проектный менеджер
Инженер

Целевые объекты по группам практик:
[Внешняя среда]
Внешняя организация
Организация
Проект
Целевая система

ISO TR 27748-1)

CEO (орг.управление и мультипроектное управление)
функционального линейного менеджера и проектного менеджера
менеджера проекта и системного инженера (например, нынешний ГИП)

Мультипроектность организации (ISO15288 этот аспект игронирует)
Регулятор как управленец

от замысла до исчезновения системы
Жизненный цикл – это проводимые с целевой системой от замысла до исчезновения практики и мероприятия
Рабочая группа INCOSE по жизненному циклу сейчас заново ищет определения, учитывая необычные целевые системы: практики, технологии, регулирование и т.д.)
Синонимы для части, связанной с разработкой: Software process, Delivery process, System process («процесс» указывает на развертку во времени) и даже project (не в значении «организация).
ISO 15288:2008 – «В настоящем Стандарте в качестве контекста для описания практик, связанных с планированием, исполнением, оценкой и контролем, выбран проект» [а не «процесс», как в менеджменте качества и ERP].
В ISO 15288 слово process не несет смысла развертки во времени, а означает указание на содержание проводимых работ. Поэтому переводится как «практика».
В ISO 15288 жизненный цикл выходит за пределы разработки, и поэтому несводим к проекту.

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

view и management view

[менеджерская]

выделения ресурсов.
Типы менеджерских решений. Их основания («доказательства приемлемости рисков»).
Форма жизненного цикла
последовательная,
инкрементальная,
эволюционная.

Инженерная

[Форма] разработки: восходящая, нисходящая, изнутри-наружу
итеративность
Технические пересмотры
Функциональный и физический аудиты
базисы
V-модель

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



Пересмотр выделения ресурсов = decision gate
Пересмотры выделения ресурсов требуют специальных артефактов: 1. описание жизненного цикла (моменты пересмотра), 2. требований к результатам следующей стадии, и 3. «оценочного дела» (доказательства приемлемости рисков перехода к следующей стадии)

целиком на уровне промежуточных уровней описания. При выполнении практики Интеграция (изготовление, сборка, наладка) получают много сюрпризов по нестыковкам, объем переделок становится огромным -- время и бюджет увеличиваются в разы.
проект планируют так, чтобы у исполнителей не было запасов времени между работами (приоритет загрузки ресурсов). Это имеет сразу два негативных последствия: случайные отклонения в отдельных работах невозможно скомпенсировать (все задержки будут просуммированы, и на это время задержится весь проект), также невозможно будет правильно спланировать промежуточный межстадийный пересмотр выделения ресурсов -- решение о выделении ресурсов можно будет принимать только по небольшим работам, но не по всему проекту в целом. То есть пересмотреть проект при таком подходе будет невозможно: пока пересматриваешь один ручеек этой речки, другие ручейки уже убежали.
"недопересмотры" и "псевдопересмотры" -- когда решение по выделению ресурсов по факту не может быть принято, но любое частное решение по какой-нибудь гаечке оформляется как полноценный пересмотр всего проекта. В тот момент, когда проект заходит в тупик, уже нет способов планово организовать принятие полноценного корректирующего решения по всем работам проекта -- только "авральные" внесистемные, внепроцедурные, внерегламентные.
слишком мало стадий в высокорисковых больших проектах: например, пересмотр выделения ресурсов случается в самом начале проекта, а затем только при передаче в эксплуатацию (через 5-10 лет после принятия решения о старте проекта -- проект ведь может быть очень большой!), затем сразу в момент вывода из эксплуатации (через десятки лет). Нельзя удивляться, что весь проект проходит в непрерывных авральных совещаниях по переделкам на всех стадиях, но эти совещания мало меняют ход проекта: принятие решений по отдельной параллельной струйке в речке ведущихся работ мало влияет на течение других струй. А интегрирующую задвижку на всю речку ведущихся работ просто не предусмотрели, поэтому о речке в целом мало кто думает (знаменитое "к пуговицам претезний нет?") -- отсюда и огромное число переделок в таких недосинхронизированных, недопересмотренных проектах.
при пересмотре выделения ресурсов не меняют требования, хотя и корректируют выделяемые ресурсы. Требования тоже нужно менять, утверждая под свежевыделенные ресурсы новые требования. Для этого, конечно, доработка требований должна входить в работы предыдущей стадии.

ISO 15288 не дает практик того, как этих ошибок избежать.
Этот список можно продолжать и продолжать, но все эти ошибки подробно разбираются в рамках конкретных методов управления жизненным циклом (ICM, RUP, DSDM, OpenUP, spiral model и т.д.). Правда, в каждом методе обсуждается только класс "любимых" для этого метода ошибок, и игнорируются другие.

3.2.1). Это только про функции и версии системы, но не про формы разработки (сверху-вниз, снизу-вверх, изнутри-наружу).
Форма жизненного цикла и формы разработки существенно связаны, хотя относятся к разным группам описаний (менеджерской и инженерной) и должны быть скоординированы.
Общая дискуссия: «водопад» против «гибкости» (ноты против джаза).
Существует множество методов управления ЖЦ, порождающих различные формы ЖЦ в их связи с формами разработки:
Rational Unified Process (RUP),
OpenUP,
Dynamic Systems Development Method (DSDM),
eXtreme programming
…
ISO 15288 никак не проясняет предпочтений к форме ЖЦ, форме разработки или методу управления ЖЦ, но указывает на необходимость иметь описание ЖЦ.
Для описания ЖЦ нужно мыслительно породить его экземпляр. Нельзя избежать выбора метода управления ЖЦ.
Наш выбор – метод постадийного выделения ресурсов (ICM)

множества предыдущих поколений разных методов УЖЦ (главным образом – используемых министерством обороны США, т.е. крайне разнообразных).
Разработка метода поэтапного выделения ресурсов финансировалась DoD, поэтому все тексты существенно ссылаются на требования положений документа DoDI 5000.02 к методам управления жизненным циклом. Отсюда в текстах ICM регулярно путаются «отрасленезависимая» терминология самого ICM и терминология ВПК США типа "milestone A". Но это неважно, сам ICM независим от требований DoD и может быть использован в любых проектах.
Автор – Barry Boehm (он же автор «спиральной модели», первым указавший на необходимость итераций практик в рамках разработки).
«Генератор» разных форм ЖЦ – в зависимости от паттерна рисков проекта
Дает ответы на вопросы об ошибках координации работ менеджеров и инженеров (дополняет ISO 15288)

Требует трех особых артефактов для обеспечения коммуникации менеджеров и инженеров:
Описания жизненного цикла
Требований
«оценочного дела» (assurance case)
Описывает использование этих артефактов

по форме жизненного цикла, стадиям, контрольным точкам, выполняемым работам и т.д.
Описание жизненного цикла может существовать в форме (компьютерной) модели [не путать «модель/вид жизненного цикла» как «типовая форма и метод разработки» и «описание/модель жизненного цикла» как формат представления]
Компьютерное моделирование жизненного цикла:
Стандарт OMG SPEM 2 обмена моделями ЖЦ между различными программными средствами
Существуют разнообразные программные средства моделирования ЖЦ (например, свободный софт EPF Composer)
Модель ЖЦ может быть отображена людям как «вебсайт» с описанием стадий ЖЦ, контрольных точек и пересмотров выделения ресурсов, необходимых артефактов, выполняющих различные практики ролей и т.д.

софту

Cреда
Рыночные тренды
Законы и подзаконные акты
Юридические обязательства
Социальная ответственность
Технологическая база
Трудовые ресурсы
Конкурирующие продукты
Стандарты и спецификации
Общественная культура

Рис. из ISO 29148 «Инженерия требований»

Есть требования к требованиям (отдельным требованиям, группам требований) – ISO 29148 «инженерия требований»
Требования непрерывно актуализируются, они не «застывают»

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

дело»

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

Пересмотр выделения ресурсов:
«доработать на предыдущей стадии»
«идти на следующую стадию»
«закрыть проект»

Доказательство приемлемости рисков достижения требований
независимыми экспертами

t

Конец проекта

инженеров, разработчиков и менеджеров, обеспечение их подотчетности через достаточно короткие этапы разработки (development increment) -- ибо слишком легко переобещать и смыться (overpomise and depart).
№2. Удовлетворение заинтересованных сторон: переговоры по взаимно удовлетворяющему набору системных требований, решений и планов, а затем управление предлагаемыми изменениями, чтобы сохранить взаимно удовлетворяющий результат.
№3. Поэтапное и эволюционное наращивание (growth) описания системы (system definition) и выделения ресурсов заинтересованных сторон (stakeholder commitment). Требования и ресурсы для сложной системы не могут быть монолитными или полностью предварительно специфицированными, они появляются постепенно по мере проведения экспериментов, прототипирования, использования ранних образцов. Доверие заинтересованных сторон, описание системы и выделение ресурсов происходят через эволюционный процесс.
№4. Повторяющаяся (iterative) разработка и описание системы: повторяющиеся этапы (итерации) приводят к постепенному улучшению требований, решений и планов разработки.
№5. Одновременное описание системы и ее разработка. Вначале это сводится к одновременному формулированию требований и решений, а также интегрированному описанию продукта и процесса. Дальше происходит сочетание стабилизированной разработки текущего этапа с одновременной связанной с изменениями переработкой (rebaselining) требований, решений и планов базиса следующего этапа. Это позволяет не ждать каждый раз, когда будут окончательно сформулированы будущие требования.
№6. Основанные на доказательстве, ведомые рисками (evidence-based, risk-driven) контрольные точки (milestones) для принятия решений о выделении ресурсов. В этих контрольных точках происходит оценка доказательства достижимости требований независимыми экспертами, после чего принимаются решения об изменении требований, выделении ресурсов, доработках или наоборот, пропусках стадий и т.д. Ресурсы на разработку выделяются (commit) не однократно "одной суммой", а поэтапно (incremental) -- метафорой тут является не игра в рулетку, при которой на кон ставится вся сумма, а игра в покер, в которой ставка распределяется на много партий.

проектах имеют особенность быть несинхронизированными как по времени, так и по своим результатам, из-за чего происходят многочисленные переделки в момент обнаружения нестыковок.
Для предотвращения нестыковок по времени объявляются специального типа контрольные точки (milestones): точки привязки (anchor points). Отдельные работы ведутся по принципу "по времени" (timeboxing -- столько времени, сколько отведено). Иногда говорят про "график как независимая переменная", а управление происходит через постоянное изменение базиса требований (rebaselining) в меньшую или большую сторону в зависимости от запаса времени и бюджета.
Для предотвращения нестыковок по результатам в обязательные результаты стадии добавляется документ Обоснование реализуемости (Feasibility Evidence Description). Этот документ готовится не просто к заданному времени, независимо от состояния работ, а по итогам готовности результатов стадии -- он целостно оценивает результаты стадии на момент ее завершения.

3. Содержание Обоснования реализуемости, обеспечиваемого разработчиками в качестве одного из основных результатов стадии и валидизируемого независимыми экспертами свидетельствует о том, что если система будет построена по предлагаемым описаниям (архитектуре, чертежам и т.д.), то она будет:
удовлетворять требованиям: возможностей (capability), интерфейсов, уровня обслуживания, развития (evolution)
поддерживать Концепцию эксплуатации (operational concept, набор сценариев использования)
уложится в бюджет и в сроки, обозначенные в планах ее создания,
породит ожидаемый возврат на инвестиции,
породит удовлетворительные результаты для всех критических для успеха системы заинтересованных сторон,
избежит всех больших рисков, адресуя недостатки в доказательствах как риски и закрывая эти недостатки планами управления рисками,
послужит основанием выделения заинтересованными сторонами ресурсов для продолжению работ.

просто трассировкой требований к решениям и слайдами в PowerPoint в момент "сдачи результатов работ". Обоснование реализуемости входит в число основных результатов стадии, на его подготовку и оценку независимыми экспертами выделяется достаточно времени и финансирования. Обоснование реализуемости должно включать в себя доказательство совместимости и целостности параллельно разработанных элементов, т.е. нельзя обойтись доказательством реализуемости отдельных элементов. Обоснование реализуемости может включать:
результаты прототипирования (сетей, роботов, пользовательских интерфейсов, взаимодействия с покупными товарами),
замеры: производительности, масштабируемости, точности
эксперименты: производительности, взаимодействия, безопасности
модели: стоимости, графика работ, производительности, надежности, "развилок" (tradeoffs)
имитационные модели: масштабируемости, производительности, надежности
ранние рабочие версии: инфраструктуры, интеграции данных с уменьшением их объема (data fusion), совместимости с предыдущими версиями (legacy compatibility)
ссылки на прошлый опыт
комбинации всего перечисленного
[все это очень похоже на assurance case в версии ISO 15026]

5. Неадекватное обоснование чаще всего включает следующие выражения:
наши инженеры чудовищно креативны. Они найдут для этого решение.
вы имеем три алгоритма, которые удовлетворяют техническим условиям на типовых маломасштабных примерах. Как минимум один из них можно масштабировать и обработать нетиповые ситуации.
мы все построим и затем наладим, чтобы удовлетворить техническим условиям
поставщик готового оборудования заверил нас, что обеспечит сертифицированную по условиям безопасности версию к тому моменту, когда нам нужно будет сдавать работу мы уже демонстрировали решения для каждой подсистемы разным заказчикам. Нам потребуется просто интегрировать все вместе.
При получении таких заявлений необходимо проводить прототипирование решений и специальные оценки рисков.
Рекомендуется создание assurance case вести непрерывно с самого начала проекта (постоянная верификация и валидация, continuous verification and validation).

Валидизация -- не случайное слово. Речь идет не просто о верификации соответствия требованиям, но и репрезентативность выбранных для обоснования сценариев, полноты тестирования и т.д.. Это важно, ибо 20% "неучтенных" сценариев обычно дают 80% трудоемкости переделок.

7. Точки привязки имеют специальное содержание: на них в результате рассмотрения Обоснований реализуемости происходит пересмотр выделения ресурсов (commitment review) заинтересованными сторонами -- поэтому точки привязки часто так и называют: "Пересмотр выделения ресурсов". Каждый пересмотр выделения ресурсов сопровождается принятием следующих решений: -- переход к новой стадии (с утверждением новых требований и нового финансирования) -- доработки в рамках предыдущей стадии -- прекращение всего проекта -- пропуск следующей стадии ввиду незначительных рисков

8. Жизненный цикл в Методе поэтапного выделения ресурсов разделен на два периода: Период I поэтапное (incremental) описание системы с тремя пересмотрами выделениями ресурсов:
исследования / нужды и возможности, готовность заинтересованных лиц
оценивание (valuation) / объем работы, бизнес-кейсы, высокоуровневая архитектура, форма жизненного цикла
основание / детальные показатели, требования, архитектура, планы, выбранные партнеры-аутсорсеры
Период II поэтапные (incremental) разработка и эксплуатация системы -- повторяющиеся (iteration) стадии с регулярно повторяющимися пересмотрами:
стадия-(increment)-1 (параллельно): разработка-1 + основания-2 / в разработке-1 использование результатов основания-1 вплоть до валидации и верификации, в основах-2 пересмотр базиса для разработки-2 (в конце стадии две процедуры пересмотра выделения ресурсов: для разработки-1 и основание-1)
стадия-2 (параллельно): эксплуатация-1 + разработка-2 + основание-3
и так далее
Для каждой стадии жизненного цикла метод поэтапного выделения ресурсов имеет рекомендации по составу практик и рабочих продуктов, которые еще не зафиксированы в письменном виде (на данный момент в отчетах зафиксированы лишь заголовки требуемых разделов документации метода).

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

10. Три основные практики (activities) метода поэтапного выделения ресурсов:
параллельное ведомое рисками и возможностями наращивание понимания и описания системы
оценка обоснованности реализуемости для продолжения
пересмотр заинтересованными лицами и выделение ими ресурсов

11. Метод поэтапного выделения ресурсов может быть использован как конструктор, из которого в зависимости от того, какой профиль риска у проекта выбираются детальки-практики для использования во всевозможных других методах управления жизненным циклом. По факту, любые формы жизненного цикла (последовательности стадий) можно рассматривать как частные случаи метода поэтапного выделения ресурсов (ICM) и выбирать их по потребности, добавляя к ним требуемые ICM точки привязки с пересмотром выделения ресурсов и подготовкой к этим пересмотрам обоснований реализуемости. ICM дает некоторые типовые профили рисков и таблицу с указанием на различные методы управления жизненным циклом, а также ключевые к ним доработки -- методы "Купи готовое" (Use NDI), Agile, Architectered Agile, Formal Methods и т.д.