Метод поэтапного выделения ресурсов (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 и может быть использован в любых проектах.
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 и может быть использован в любых проектах.