Определение системы — различия между версиями

(→‎См. также)
 
(не показано 9 промежуточных версий этого же участника)
Строка 1: Строка 1:
−
'''Определение системы'''. Перед тем, как сделать любую систему, её нужно определить (define), ибо нельзя сделать то, что “неопределено” (задача “пойди туда, не знаю куда, найди то, не знаю что” — это больше ведь исследовательская задача, а не инженерная. Чтобы воплотить в нашем четырёхмерном пространстве-времени какую-то систему, нужно как минимум иметь представление об этой системе, “определить” её).  
+
'''Определение системы''' или '''Описание системы''' (system definition) — информация о [[Воплощение системы|воплощении системы]].
  
 +
Перед тем, как сделать любую систему, её нужно определить (define), ибо нельзя сделать то, что “неопределено” (задача “пойди туда, не знаю куда, найди то, не знаю что” — это больше ведь исследовательская задача, а не инженерная. Чтобы воплотить в нашем четырёхмерном пространстве-времени какую-то систему, нужно как минимум иметь представление об этой системе, “определить” её).
  
 
Альфой определения системы занимается системный инженер.
 
Альфой определения системы занимается системный инженер.
  
 +
Описания системы легко отличить от [[Воплощение системы|воплощений системы]] и [[Документация системы|документов системы]] — '''они не занимают места в физическом мире''', у них нет объёма и координат в этом мире, они абстрактны, «идеальны», нематериальны как противоположность материальному/физическому. Системы и системные документы (документы о системах) материальны, они занимают место в физическом мире.
 +
 +
Людей в конечном итоге интересуют воплощения системы, а описания и документация системы их интересуют ровно постольку, поскольку без них воплощение системы трудно сделать, особенно когда речь идёт о системах, создаваемых многими людьми.
  
 
== Основные подальфы ==
 
== Основные подальфы ==
 
Определение системы как альфа включает в себя основные подальфы (это только основные подальфы, их может быть много больше):
 
Определение системы как альфа включает в себя основные подальфы (это только основные подальфы, их может быть много больше):
−
* [[Требования]] (определение системы как “чёрного ящика”) - "техническое задание"
+
* [[Требования]] (определение системы как “чёрного ящика”) - "[[техническое задание]]"
−
* [[Архитектура]] (важнейшие инженерные решения, определяющие систему как “прозрачный ящик”) - "эскиз", "проектная документация"
+
* [[Архитектура]] (важнейшие инженерные решения, определяющие систему как “прозрачный ящик”) - "эскиз", "[[Проектная документация|проектная документация]]"
−
* [[Неархитектурная часть проекта]] (все инженерные решения, которые будут сочтены не самыми важными) — “рабочая документация”.
+
* [[Неархитектурная часть проекта]] (все инженерные решения, которые будут сочтены не самыми важными) — “[[рабочая документация|рабочая документация]]”.
−
 
+
−
Часто выделяют проект/design как совокупность архитектурной и неархитектурных частей (вся архитектура — это design, но не весь design это архитектура). А ещё есть “исполнительная документация” — это описание системы “как построено/изготовлено” ('''as built''') в отличие от “проектной документации” ('''as designed''').
+
  
 +
Часто выделяют проект/design как совокупность архитектурной и неархитектурных частей (вся архитектура — это design, но не весь design это архитектура). А ещё есть “исполнительная документация” — это описание системы “как построено/изготовлено” ('''as built''') в отличие от “[[Проектная документация|проектной документации]]” ('''as designed''').
  
 
== Рабочий продукт ==
 
== Рабочий продукт ==
−
 
+
[[Документация системы]]
−
Рабочий продукт определения системы это описание системы, чаще известный как '''«проект системы» (design)''', часто бьётся на множество отдельных документов, баз данных, презентаций, докладных записок, цитируемых стандартов и даже физических макетов.
+
−
 
+
  
 
== Дисциплины ==
 
== Дисциплины ==
 
* [[Инженерия требований]],
 
* [[Инженерия требований]],
−
* Проектирование и конструирование (включающие работу с архитектурой системы).
+
* [[Проектирование]] и [[конструирование]] (включающие работу с архитектурой системы).
−
 
+
  
 
== Практики ==
 
== Практики ==
Строка 36: Строка 36:
 
* '''Практики инженерии''' учат тому, как придумать соответствующие определения системы (альфы).
 
* '''Практики инженерии''' учат тому, как придумать соответствующие определения системы (альфы).
 
* '''Практики описания''' — как создать рабочие продукты, документирующие принятые при определении системы инженерные решения. Писарь, пишущий под чужую диктовку знакомыми ему иероглифами — это не инженер. Это писец. Инженер — это тот, кто придумывает инженерные решения, которые потом (обычно сам!) записывает иероглифами соответствующих нотаций, плюс потом инженер ещё и воплощает придуманное.
 
* '''Практики описания''' — как создать рабочие продукты, документирующие принятые при определении системы инженерные решения. Писарь, пишущий под чужую диктовку знакомыми ему иероглифами — это не инженер. Это писец. Инженер — это тот, кто придумывает инженерные решения, которые потом (обычно сам!) записывает иероглифами соответствующих нотаций, плюс потом инженер ещё и воплощает придуманное.
−
 
  
 
== Обобщение ISO 42010 на определение системы ==
 
== Обобщение ISO 42010 на определение системы ==
−
 
 
'''Описания''' — это [[Рабочий продукт|рабочие продукты]], которые выражают определение системы.
 
'''Описания''' — это [[Рабочий продукт|рабочие продукты]], которые выражают определение системы.
 +
 +
[[Метод описания|Группа описаний]] (view) группирует отдельные [[Модель|модели]]/отдельные описания (model). Так, финансовая группа описаний может группировать баланс и отчёт о прибылях и убытках, архитектурная группа описаний может группировать компонентные, модульные и описания размещения, а также какие-то гибридные описания. Каждая группа описаний имеет свой [[Метод описания|метод описаний]] (viewpoint). Тематический метод описания задаёт тематическую группу описаний по определенной тематике.
 +
 +
Любые группы описаний существуют только потому, что есть [[Стейкхолдер|стейкхолдеры]], заинтересованные в системе в той части, которая этими описаниями описываются. Если нет стейкхолдера, которому это описание нужно, то описания просто не должно быть — зачем трудиться для создания того, что не будет никем использовано? Если заинтересованный стейкхолдер есть, но нет нужного ему описания — большая вероятность, что интересы стейкхолдера не будут учтены (помним, что успешной системой называется та, которая удовлетворяет стейкхолдеров.
  
 
[[Воплощение системы]] удовлетворяет определению системы, а определение системы характеризует (а пока системы нет, то определяет) воплощение системы.
 
[[Воплощение системы]] удовлетворяет определению системы, а определение системы характеризует (а пока системы нет, то определяет) воплощение системы.
  
−
[[Метод описания|Тематический метод описания]] (viewpoint) задаёт тематическую группу описаний (veiw) по определенной тематике.
+
== Состояния ==
 +
[[OMG Essence]] определяет следующие состояния для альфы "Определение системы" и [[Практика контрольных вопросов|контрольные вопросы]] для проверки каждого состояния:
  
−
Каждая группа описаний (view) имеет свой метод описаний (viewpoint).
+
{| 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
 +
|  внешние проектные роли и команда согласны, что система будет сделана; методы описания системы согласованы; способ согласования описаний с внешними проектными ролями согласован; механизмы управления конфигурацией документации согласованы.
 +
| ❑ Ясно, что будет считаться успехом для новой системы
  
−
Группа описаний (view) группирует отдельные [[Модель|модели]]/отдельные описания (model).
+
❑ Методы описания системы согласованы
  
−
Так, финансовая группа описаний может группировать баланс и отчёт о прибылях и убытках, архитектурная группа описаний может группировать компонентные, модульные и описания размещения, а также какие-то гибридные описания.
+
❑ Способ согласования описаний со стейкхолдерами согласован
  
−
''Замечания по переводу:'' очень часто view и viewpoint переводят как “аспект”, но это не совсем верный перевод (тем более, что он не позволяет различить само описание, выполненное для какого-то аспекта — view, и знания о том, как делать такие описания — viewpoint). View — это то, что видишь. Viewpoint — это та точка, из которой видно то, что видишь. Видишь обычно много разного (разных моделей), объединённого тематикой: описания требований, архитектуры, финансовые описания, физические описания, описания безопасности и т.д.
+
❑ Механизмы управления конфигурацией описаний согласованы
 +
|-
 +
| 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
 +
| используется для определения момента вывода из эксплуатации или принятии решения о продлении эксплуатации; демонстрирует отсутствие вредных эффектов (например, загрязнения окружающей среды) при выводе из эксплуатации; используется для планирования и проведения работ по уничтожению и/или переработке воплощения системы.
 +
| ❑ Определение системы используется для определения момента вывода из эксплуатации или принятии решения о продлении эксплуатации
 +
 +
❑ Определение системы демонстрирует отсутствие вредных эффектов (например, загрязнения окружающей среды) при выводе системы из эксплуатации
 +
 +
❑ Определение системы используется для планирования и проведения работ по ликвидации и/или переработке воплощения системы
 +
|}
  
 
== См. также ==
 
== См. также ==
 
* [[Конфигурация системы]]
 
* [[Конфигурация системы]]
  
−
 
−
 
 
[[Категория: Концепции]]
 
[[Категория: Концепции]]
 +
[[Категория: Альфы]]

Текущая версия на 12:55, 8 апреля 2024

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

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

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

См. также

Источник — «http://sewiki.ru/index.php?title=Определение_системы&oldid=4748»