Процессы жизненного цикла системной инженерии, архитектура: ISO 15288
Все эти новомодные понятия системной инженерии представляют собой явное введение в организационную практику современных парадигм создания рукотворных продуктов и сервисов -- через предписание следовать международным стандартам. Не знали вы, что такое жизненный цикл, так узнаете, когда вам в контракт впишут требование следовать ISO 15288 -- а вписывать в крупных проектах уже начали. Далее несколько вводимых этим стандартом (а также стандартами, на который он ссылается) концептов.
Система -- это набор взаимодействующих частей, у которых есть цель. В системе явно вводится наблюдатель, с точки зрения которого выделяется интересующая-система (system-of-interest) и жесткое определение границ системы. Сервис -- это тоже система (или сервис производится системой). Обеспечивающая (enabling) система -- это система, которая пропихивает system-of-interest по этапам жизненного цикла (производственная система, ремонтная система для систем-продуктов и т.д.). Элементы системы могут быть описаны отдельно как системы, поэтому их можно заказать по контракту.
Все не так просто: этот заход существенно отличается от захода системной инженерии" стандарта ISO 26702, который описывает разработку системы, а не ее жизненный цикл. Впрочем, отличия описаны в самом тексте стандарта ISO 15288 (в приложении F).
Жизненный цикл -- эволюция системы, продукта, сервиса, проекта или другой сущности, порожденной людьми, от концепта до отхода ее от дел (life cycle -- the evolution of a system, product, service, project or other human-made entity from conception through retirement. [ISO/IEC 12207:2007 and ISO/IEC 15288:2007] ).
Модель жизненного цикла -- относящийся к жизненному циклу фреймворк процессов и действий (которые могут быть организованы по стадиям), который также действует как общая рекомендация для общения и понимания. (life cycle model -- a framework of processes and activities (which may be organized into stages) concerned with the life cycle, which also acts as a common reference for communication and understanding. [ISO/IEC 12207:2007 and ISO/IEC 15288:2007] )
"Каждая система, независимо от сорта или размера, следует какой-то модели жизненного цикла от ее начальной концептуализации до конечного отхода от дел. Проход системы в любой последовательности и любым способом через части модели, называется жизненным циклом. Модель жизненного цикла, тем самым, это концептуальное сегментирование определения нужды в системе, ее создания как продукта или сервиса, и ее использования, эволюции и выкидывания. Модель жизненного цикла системы обычно сегментирована на стадии, чтобы помочь планированию, обеспечению, функционированию и поддержке интересующей-системы. Эти сегменты обеспечивают упорядоченное продвижение системы через установленные барьеры принятия решений с целью уменьшить риск и убедиться в достаточности прогресса. Нужда принять решение согласно специфическому критерию перед тем как система сможет перейти на следующую стадию -- это наиболее важный довод для использования модели жизненного цикла" -- из проекта ISO TR 24748. Эти тексты невозможно адекватно перевести на русский язык!
Оттуда же (ISO TR 24748) -- апдейт процессного подхода. Процессы имеют собственника (ответственного за их выполнение), модульны (т.е. каждый процесс посвящен одной и только одной функции, а число интерфейсов между процессами держится минимальным. Функция процесса описывается как его специфическая цель, продукты/outcomes и набор действий). Процесс по ходу жизненного цикла может использовать другой процесс для специализированной функции. Каждый процесс вызывается из организационного фреймворка. Если процесс A вызывается процессом B, и только процессом B, то A принадлежит B. Если функция вызывается более чем одним процессом, то эта функция сама становится процессом. Должно быть возможным верифицировать любую функцию в модели жизненного цикла. Каждый процесс должен иметь внутреннюю структуру, достаточно определенную, чтобы быть выполнимым. Процесс должен быть описан так, чтобы к нему можно было применить стандарт проверки его выполнения ISO 15504.
Процессы жизненного цикла системного инжиниринга делятся на контрактные (распределяющие ответственности между организациями), и три группы, вложенные друг в друга: организационно обеспечивающие проекты, внутри них собственно проектые, а уже внутри них собственно технические (выполняющие работу, а не организовывающие работу). Каждый процесс имеет цели, выходные продукты, ряд предписанных действий, которые состоят в свою очередь из обязательно выполняемых заданий (tasks). Вот эти процессы:
Контрактации:
-- приобретения
-- поставки
Организационные, обеспечивающие проектность:
-- управления моделью жизненного цикла
-- управления инфраструктурой
-- управления портфелем проектов
-- управления человеческими ресурсами
-- управления качеством
Проектные (не-инжиниринговые):
-- Управления проектами
-- Планирования проекта
-- Оценки проекта и контроля
-- Поддержки проектов
-- управления решениями (управленческими!)
-- управления рисками
-- управления конфигурацией
-- управления информацией
-- измерений (ISO 15937)
Технические (собственно работа, а не ее организация):
-- Определения требований заинтересованных лиц
-- Анализа требований
-- Архитектурного проектирования
-- изготовления
-- Интеграции
-- Верификации
-- Перехода
-- Валидации
-- Функционирования
-- Обслуживания
-- устранения
Это не стадии жизненного цикла, это именно процессы. А стадии могут быть любыми, например:
Для системы (ISO 15288):
-- концепт
-- разработка
-- производство
-- эксплуатация
-- поддержка
-- вывод из эксплуатации
Для софта (ISO 12207):
-- концепт
-- разработка
-- сопровождение
-- вывод из эксплуатации
Для хардвера:
-- концепт
-- проектирование
-- изготовление
-- функционирование и обслуживание
-- вывод из эксплуатации
Для людей (ISO 18529):
-- определение скиллов
-- покупка
-- тренинг
-- использование скилов и приобретение опыта
-- увольнение
Для зданий:
-- эскиз
-- проектирование
-- получение разрешения
-- строительство
-- функционирование и обслуживание
-- вывод из эксплуатации
Для процессов:
-- определение продукта (output)
-- рисование прямоугольников и стрелочек (flowcharting)
-- оформление
-- пилотное использование
-- использование и улучшение
-- вывод из эксплуатации
Для естественных сущностей (вода, минералы и т.д.):
-- приобретение
-- разработка
-- эксплуатация
-- вывод из эксплуатации
В качестве упражнения: разберитесь, какими процессами жизненного цикла системного инжиниринга обеспечивается стадия производства.
У стандарта очень и очень жесткие требования. Например, при отказе поставщику в ходе конкурса требуется сообщать причину, по которой поставщик проиграл. Еще более крутое требование -- трассировки проектных решений к пользовательским требованиям. Валидация и верификация должны быть независимыми и относиться к конечному продукту.
Такая жесткая бюрократия наводится на все творчество криэйторов -- которые, конечно, взвывают от этого, но зато построенные ими мосты имеют много меньшую вероятность обвалиться, а весь цикл разработки занимает много меньше времени -- если учесть всю экономию от более простого внесения изменений в проект. Все эти требования стандарта просто отражают современную практику, и вряд ли могут быть реализованы без информационной модели целевой системы (system-of-interest).
В системной инженерии явно вводится архитектура и процесс архитектурного дизайна (синтетический процесс, дополняющий два аналитических -- сбор требований и анализ требований), архитектурный фреймворк и архитектурное описание. Этому, конечно, нужно посвящать отдельный постинг, там замешана дюжина стандартов.
Особое внимание нужно уделить нормативному закреплению в современных стандартах тренда на перетягивание методологий создания софта в методологии создания любых рукотворных продуктов и сервисов. Так, разработанная для софтовых проектов проверка выполнения процессов рутинно рекомендуется для проверки выполнения процессов на любом производстве -- и так далее по всему списку. Конечно, разница пока признается (например, отдельно есть "общий" ISO 15288 и отдельно -- софтовый ISO 12207), но далее действует замечание, что "все сложные системы стремительно становятся с существенной софтовой компонентой" -- и замышлять, проектировать, разрабатывать, эксплуатировать и выкидывать их нужно так же, как софт. "К чему бы ни прикоснулся компьютер, то само становится компьютером".