Просмотр исходного текста страницы Определение системы

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

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

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

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

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

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

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

== Рабочий продукт ==
[[Документация системы]]

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

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

Практики описания включают в себя знания по:
* языку описания,
* используемым нотациям,
* описательным идиомам,
* редакторам.

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

== Обобщение ISO 42010 на определение системы ==
'''Описания''' — это [[Рабочий продукт|рабочие продукты]], которые выражают определение системы.

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

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

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

== Состояния ==
[[OMG Essence]] определяет следующие состояния для альфы "Определение системы" и [[Практика контрольных вопросов|контрольные вопросы]] для проверки каждого состояния:

{| class="wikitable" style="font-size: 9pt;"
! style="text-align: center; font-weight: bold; width:4%" | №
! style="text-align: center; font-weight: bold; width:10%" | Состояние
! style="text-align: center; font-weight: bold; width:10%" | State
! style="text-align: center; font-weight: bold; width:16%" | Описание состояния
! style="text-align: center; font-weight: bold; width:60%" | Контрольные вопросы
|-
| 1
| style="font-weight: bold;" | Замыслено
| Concieved
|  внешние проектные роли и команда согласны, что система будет сделана; методы описания системы согласованы; способ согласования описаний с внешними проектными ролями согласован; механизмы управления конфигурацией документации согласованы.
| ❑ Ясно, что будет считаться успехом для новой системы

❑ Методы описания системы согласованы

❑ Способ согласования описаний со стейкхолдерами согласован

❑ Механизмы управления конфигурацией описаний согласованы
|-
| 2
| style="font-weight: bold;" | Непротиворечиво
| Coherent
| описания системы документированы, и документация доступна команде и стейкхолдерам; происхождение описаний ясно; описания проверяются; противоречивые описания выявлены и ими занимаются; команда понимает описания и соглашается их воплотить; соответствующая описаниям система принимается внешними проектными ролями как заслуживающая воплощения.
| ❑ Описания документированы и доступны команде и стейкхолдерам

❑ Происхождение описаний ясно

❑ Описания проверяются

❑ Противоречивые описания идентифицированы и ими занимаются

❑ Команда понимает описания и соглашается их воплотить

❑ Система, соответствующая описаниям, принимается стейкхолдерами как заслуживающая воплощения
|-
| 3
| style="font-weight: bold;" | Используется для изготовления
| In use for manufacturing
|  изготавливающая систему часть команды считает, что описаний хватает для начала изготовления; технологии изготовления описаны и документированы; возникающие при изготовлении системы проблемы приводят к доработке и актуализации описаний системы.
| ❑ Подготовлено достаточное количество описаний системы, чтобы начать изготавливать систему

❑ Технологии изготовления определены

❑ Часть команды, изготавливающая систему, признаёт описания достаточными для изготовления системы

❑ Возникающие при изготовлении проблемы приводят к переработке и актуализации определения системы
|-
| 4
| style="font-weight: bold;" | Используется для проверки и приёмки воплощения 
| In use for V&V
| есть все описания, нужные для проверки и приёмки; испытания, критерии их успешности и способ проведения определены; внешние проектные роли согласны с объёмом испытаний.
| ❑ Нет частей определения системы, без которых проверки невозможны

❑ Проверки, критерии их успешности и способ их проведения определены

❑ Стейкхолдеры согласны с объемом проверок
|-
| 5
| style="font-weight: bold;" | Используется для эксплуатации
| In use for operations
| описание системы используется для сбора информации о состоянии эксплуатируемого воплощения системы (цифровой двойник, digital twin); описание системы наряду с информацией цифрового двойника используется для принятия решений о техобслуживании, ремонтах, модернизации.
| ❑ Определение системы используется для сбора информации о состоянии эксплуатируемого воплощения системы

❑ Определение системы наряду с информацией о состоянии эксплуатируемой системы используется для принятия решений о техобслуживании, ремонтах, модернизации
|-
| 6
| style="font-weight: bold;" | Используется для вывода из эксплуатации
| In use for retirement
| используется для определения момента вывода из эксплуатации или принятии решения о продлении эксплуатации; демонстрирует отсутствие вредных эффектов (например, загрязнения окружающей среды) при выводе из эксплуатации; используется для планирования и проведения работ по уничтожению и/или переработке воплощения системы.
| ❑ Определение системы используется для определения момента вывода из эксплуатации или принятии решения о продлении эксплуатации

❑ Определение системы демонстрирует отсутствие вредных эффектов (например, загрязнения окружающей среды) при выводе системы из эксплуатации

❑ Определение системы используется для планирования и проведения работ по ликвидации и/или переработке воплощения системы
|}

== См. также ==
* [[Конфигурация системы]]

[[Категория: Концепции]]
[[Категория: Альфы]]