Определение системы

Определение системы или Описание системы (system definition) — информация о воплощении системы.

Перед тем, как сделать любую систему, её нужно определить (define), ибо нельзя сделать то, что “неопределено” (задача “пойди туда, не знаю куда, найди то, не знаю что” — это больше ведь исследовательская задача, а не инженерная. Чтобы воплотить в нашем четырёхмерном пространстве-времени какую-то систему, нужно как минимум иметь представление об этой системе, “определить” её).

Альфой определения системы занимается системный инженер.

Описания системы легко отличить от воплощений системы и документов системы — они не занимают места в физическом мире, у них нет объёма и координат в этом мире, они абстрактны, «идеальны», нематериальны как противоположность материальному/физическому. Системы и системные документы (документы о системах) материальны, они занимают место в физическом мире.

Людей в конечном итоге интересуют воплощения системы, а описания и документация системы их интересуют ровно постольку, поскольку без них воплощение системы трудно сделать, особенно когда речь идёт о системах, создаваемых многими людьми.

Основные подальфы

Определение системы как альфа включает в себя основные подальфы (это только основные подальфы, их может быть много больше):

Требования (определение системы как “чёрного ящика”) - “техническое задание”
Архитектура (важнейшие инженерные решения, определяющие систему как “прозрачный ящик”) - “эскиз”, “проектная документация”
Неархитектурная часть проекта (все инженерные решения, которые будут сочтены не самыми важными) — “рабочая документация”.

Часто выделяют проект/design как совокупность архитектурной и неархитектурных частей (вся архитектура — это design, но не весь design это архитектура). А ещё есть “исполнительная документация” — это описание системы “как построено/изготовлено” (as built) в отличие от “проектной документации” (as designed).

Рабочий продукт

Документация системы

Дисциплины

Инженерия требований,
Проектирование и конструирование (включающие работу с архитектурой системы).

Практики

Практики описания системы — это просто практики записи, они не подразумевают какого-то выдумывания описываемой системы.

Практики описания включают в себя знания по:

языку описания,
используемым нотациям,
описательным идиомам,
редакторам.

Эти практики описания не нужно путать с практиками инженерии (Инженерия требований, Инженерия системной архитектуры, Проверки и приемки):

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

Обобщение ISO 42010 на определение системы

Описания — это рабочие продукты, которые выражают определение системы.

Группа описаний (view) группирует отдельные модели/отдельные описания (model). Так, финансовая группа описаний может группировать баланс и отчёт о прибылях и убытках, архитектурная группа описаний может группировать компонентные, модульные и описания размещения, а также какие-то гибридные описания. Каждая группа описаний имеет свой метод описаний (viewpoint). Тематический метод описания задаёт тематическую группу описаний по определенной тематике.

Любые группы описаний существуют только потому, что есть стейкхолдеры, заинтересованные в системе в той части, которая этими описаниями описываются. Если нет стейкхолдера, которому это описание нужно, то описания просто не должно быть — зачем трудиться для создания того, что не будет никем использовано? Если заинтересованный стейкхолдер есть, но нет нужного ему описания — большая вероятность, что интересы стейкхолдера не будут учтены (помним, что успешной системой называется та, которая удовлетворяет стейкхолдеров.

Воплощение системы удовлетворяет определению системы, а определение системы характеризует (а пока системы нет, то определяет) воплощение системы.

Состояния

OMG Essence определяет следующие состояния для альфы “Определение системы” и контрольные вопросы для проверки каждого состояния:

№	Состояние	State	Описание состояния	Контрольные вопросы
1	Замыслено	Concieved	внешние проектные роли и команда согласны, что система будет сделана; методы описания системы согласованы; способ согласования описаний с внешними проектными ролями согласован; механизмы управления конфигурацией документации согласованы.	❑ Ясно, что будет считаться успехом для новой системы ❑ Методы описания системы согласованы ❑ Способ согласования описаний со стейкхолдерами согласован ❑ Механизмы управления конфигурацией описаний согласованы
2	Непротиворечиво	Coherent	описания системы документированы, и документация доступна команде и стейкхолдерам; происхождение описаний ясно; описания проверяются; противоречивые описания выявлены и ими занимаются; команда понимает описания и соглашается их воплотить; соответствующая описаниям система принимается внешними проектными ролями как заслуживающая воплощения.	❑ Описания документированы и доступны команде и стейкхолдерам ❑ Происхождение описаний ясно ❑ Описания проверяются ❑ Противоречивые описания идентифицированы и ими занимаются ❑ Команда понимает описания и соглашается их воплотить ❑ Система, соответствующая описаниям, принимается стейкхолдерами как заслуживающая воплощения
3	Используется для изготовления	In use for manufacturing	изготавливающая систему часть команды считает, что описаний хватает для начала изготовления; технологии изготовления описаны и документированы; возникающие при изготовлении системы проблемы приводят к доработке и актуализации описаний системы.	❑ Подготовлено достаточное количество описаний системы, чтобы начать изготавливать систему ❑ Технологии изготовления определены ❑ Часть команды, изготавливающая систему, признаёт описания достаточными для изготовления системы ❑ Возникающие при изготовлении проблемы приводят к переработке и актуализации определения системы
4	Используется для проверки и приёмки воплощения	In use for V&V	есть все описания, нужные для проверки и приёмки; испытания, критерии их успешности и способ проведения определены; внешние проектные роли согласны с объёмом испытаний.	❑ Нет частей определения системы, без которых проверки невозможны ❑ Проверки, критерии их успешности и способ их проведения определены ❑ Стейкхолдеры согласны с объемом проверок
5	Используется для эксплуатации	In use for operations	описание системы используется для сбора информации о состоянии эксплуатируемого воплощения системы (цифровой двойник, digital twin); описание системы наряду с информацией цифрового двойника используется для принятия решений о техобслуживании, ремонтах, модернизации.	❑ Определение системы используется для сбора информации о состоянии эксплуатируемого воплощения системы ❑ Определение системы наряду с информацией о состоянии эксплуатируемой системы используется для принятия решений о техобслуживании, ремонтах, модернизации
6	Используется для вывода из эксплуатации	In use for retirement	используется для определения момента вывода из эксплуатации или принятии решения о продлении эксплуатации; демонстрирует отсутствие вредных эффектов (например, загрязнения окружающей среды) при выводе из эксплуатации; используется для планирования и проведения работ по уничтожению и/или переработке воплощения системы.	❑ Определение системы используется для определения момента вывода из эксплуатации или принятии решения о продлении эксплуатации ❑ Определение системы демонстрирует отсутствие вредных эффектов (например, загрязнения окружающей среды) при выводе системы из эксплуатации ❑ Определение системы используется для планирования и проведения работ по ликвидации и/или переработке воплощения системы

См. также

Конфигурация системы