June 8th, 2009

2021 год

Метод поэтапного выделения ресурсов (ICM)

Метод поэтапного выделения ресурсов (ICM, Incremental Commitment Model, http://csse.usc.edu/csse/TECHRPTS/2009/usc-csse-2009-500/usc-csse-2009-500.pdf) является методом управления жизненным циклом ("software and systems process", аналогично RUP, OpenUP, DSDM, spiral model, V-model и т.д.). Вот его основные особенности:

1. Принципы:
№1. Выделение достаточного ресурса системных инженеров, разработчиков и менеджеров, обеспечение их подотчетности через достаточно короткие этапы разработки (development increment) -- ибо слишком легко переобещать и смыться (overpomise and depart).

№2. Удовлетворение заинтересованных сторон: переговоры по взаимно удовлетворяющему набору системных требований, решений и планов, а затем управление предлагаемыми изменениями, чтобы сохранить взаимно удовлетворяющий результат.

№3. Поэтапное и эволюционное наращивание (growth) описания системы (system definition) и выделения ресурсов заинтересованных сторон (stakeholder commitment). Требования и ресурсы для сложной системы не могут быть монолитными или полностью предварительно специфицированными, они появляются постепенно по мере проведения экспериментов, прототипирования, использования ранних образцов. Доверие заинтересованных сторон, описание системы и выделение ресурсов происходят через эволюционный процесс.

№4. Повторяющаяся (iterative) разработка и описание системы: повторяющиеся этапы (итерации) приводят к постепенному улучшению требований, решений и планов разработки.

№5. Одновременное описание системы и ее разработка. Вначале это сводится к одновременному формулированию требований и решений, а также интегрированному описанию продукта и процесса. Дальше происходит сочетание стабилизированной разработки текущего этапа с одновременной связанной с изменениями переработкой (rebaselining) требований, решений и планов базиса следующего этапа. Это позволяет не ждать каждый раз, когда будут окончательно сформулированы будущие требования.

№6. Основанные на доказательстве, ведомые рисками (evidence-based, risk-driven) контрольные точки (milestones) для принятия решений о выделении ресурсов. В этих контрольных точках происходит оценка доказательства достижимости требований независимыми экспертами, после чего принимаются решения об изменении требований, выделении ресурсов, доработках или наоборот, пропусках стадий и т.д.
2. Ресурсы на разработку выделяются (commit) не однократно "одной суммой", а поэтапно (incremental) -- метафорой тут является не игра в рулетку, при которой на кон ставится вся сумма, а игра в покер, в которой ставка распределяется на много партий.

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

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

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

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

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

Рекомендуется создание assurance case вести непрерывно с самого начала проекта (постоянная верификация и валидация, continuous verification and validation).

6. Обоснование реализуемости валидизируется независимыми экспертами. Валидизация -- не случайное слово. Речь идет не просто о верификации соответствия требованиям, но и репрезентативность выбранных для обоснования сценариев, полноты тестирования и т.д.. Это важно, ибо 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
-- и так далее

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

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

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

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

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

12. Разработка метода поэтапного выделения ресурсов финансировалась DoD, поэтому все тексты существенно ссылаются на требования положений документа DoDI 5000.02 к методам управления жизненным циклом. Отсюда в тексте регулярно путаются терминология самого ICM и терминология ВПК США типа "milestone A". Но это неважно, сам ICM независим от требований DoD и может быть использован в любых проектах.
2021 год

О процессах, практиках, процедурах и формах жизненного цикла

Русское "проект" мы переводим на английский то как project, то как design с полным пониманием, что project и design сами по себе как-то связаны, но эта связь не повод их путать. Такую же логику -- перевод разными словами -- нужно использовать, переводя слово process.

В стандарте описания методов управления жизненным циклом SPEM 2.0 (называемом Software and System Process Engineering Metamodel) предложено жестко различать ContentMethod и Process для указания на метод и указания развертки по времени любых видов (логической или стадийной).

Метод (а точнее, его маленький кусочек -- практика) никак не связан с процедурой, в нем не дается последовательность действий (о чем соответствующие стандарты обычно явно предупреждают -- например, это оговаривается в ISO 24774). Скажем, практика пассировки овощей рассказывает, что овощи нужно жарить в масле, чтобы они были вкуснее при варке (правда, в малороссии пассировку считают методом ухудшения вкуса первых блюд, который придумали дикие в пищевом отношении северные народы. В Москве ведь не едят, а питаются). Для описания практик используется формализм process ISO 24774 или MethodContent SPEM 2. Практики затем используются в процедурах (и поэтому их в SPEM 2 даже обозначают в процедурах не значком "практика", а специальным значком "использование практики").
После этого "использования" (use в SPEM 2) появляется процедура: рецепт приготовления борща, в котором используется уже известная и общая для всех рецептов практика пассировки. Для описания последовательности использования дел в процедурах используется формализм BPMN 2.0 (включающий оркестровку-BPMN 1.1, ежели борщ готовит семья, а также хореографию-DEMO, ежели речь идет о распределении работ между несколькими сервисами (сервис -- это агент, исполняющий DEMO-трансакцию)).

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

Конечно, в англоязычных текстах можно встретить игру слов, в которой (часто -- намеренно, из-за невозможности и нежелания различить методический и временнОй аспекты проговариваемых разных уровней описания жизненного цикла, как на детальном уровне описания конкретного ЖЦ, так и в варианте типового описания -- метода управления жизненным циклом), его целиком называют process, чаще всего в традиции словоупотребления software process. Так, в текстах по ICM они самоназывают ICM, а также RUP, DSDM и т.д. как process).

Ситуация осложняется, ибо в разных подходах (frameworks) принято по-разному соотносить понятия для разных явлений (occurrence), обозначаемых словами process, activity, task, work. Где-то process состоит из ряда логически (результирующий артефакт одной является входным артефактом другой) связанных друг с другом экземпляров activities, а где-то activity представляет собой класс для всех process. Во всех этих случаях нужно передавать process и activity разными словами.

Дополнительное осложнение происходит от выбранного в ISO 15288 способа рассказа о целевой системе (system-of-interest) и ее жизненном цикле (включающем процессы изменений под воздействием обеспечивающей системы) как центральном объекте. На самом деле разговор по факту идет все времи про практики и процедуры обеспечивающей системы (enabling system), выполнение которых неформально называют управлением жизненным циклом. Словосочетание life cycle management поэтому в сам стандарт ISO 15288 не попало, зато попало в названия различных стандартов ISO (например, ISO TR 24748 -- Gide for life cycle management, в котором как раз поясняется терминология, связанная с описанием жизненного цикла). В кругу самих стандартописателей говорят же просто о практиках жизненного цикла (а не практиках управления жизненным циклом), не смущаясь тем, что практики эти относятся не к целевым системам, а к обеспечивающим системам -- в силу взаимно однозначного соответствия между делателем и делаемым.

Для всего обсуждаемого (process, iteration, activity, task) SPEM 2 использует класс Work Definition = определение работы, который сам является стереотипом для метаклассов Action и Classifier), и это Work Definition можно укладывать как в процедуры, так и в практики. Мудро, по-русски "описание работы" тоже означает все, что угодно -- и процедурный, и методический аспект.
Но это не отменяет задачи перевода самих process, iteration, activity, task и даже step. Особенно, ежели activity является подклассом не только Work Definition, но и Work Breakdown Element (а там уже и до упоминания milestone недалеко -- Because Milestone is commonly used to refer to both the event itself and the point in time at which the event is scheduled to happen, it is modeled as a Work Breakdown Element (i.e., it appears as part of a breakdown structure and can have predecessors)).

Итого, предложение по русскоязычной гармонизации понятий, связанных с process (для основных стандартов организационного моделирования):

1. ISO 15288 и 24774
-- process=практика, activity=мероприятие, task=дела
-- process reference model = типовой набор практик
-- life cycle form = форма жизненного цикла (последовательность стадий), порождается (не указано в ISO 15288!) методом управления жизненым циклом (типа ICM, RUP, DSDM, OpenUP и т.д.).
-- life cycle model = описание жизненного цикла

2. SPEM 2
-- method content = практика
-- process = форма жизненного цикла
-- method framework = метод управления жизненным циклом
-- process, delivery process, development process, software process, software and system process = описание жизненного цикла
-- workflow = процедура
-- activity = <деятельность> (чтобы не закрывать возможность характеризовать как практику, так и процедуру)

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