Определение системы
Определение системы или Описание системы (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 | используется для определения момента вывода из эксплуатации или принятии решения о продлении эксплуатации; демонстрирует отсутствие вредных эффектов (например, загрязнения окружающей среды) при выводе из эксплуатации; используется для планирования и проведения работ по уничтожению и/или переработке воплощения системы. | ❑ Определение системы используется для определения момента вывода из эксплуатации или принятии решения о продлении эксплуатации
❑ Определение системы демонстрирует отсутствие вредных эффектов (например, загрязнения окружающей среды) при выводе системы из эксплуатации ❑ Определение системы используется для планирования и проведения работ по ликвидации и/или переработке воплощения системы |