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