Определение системы - История изменений

Admin: /* См. также */

2024-04-08T09:55:53Z

‎См. также

Admin в 21:23, 30 июня 2022

2022-06-30T21:23:39Z

Admin: /* Рабочий продукт */

2022-06-30T21:22:58Z

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

Admin в 21:22, 30 июня 2022

2022-06-30T21:22:29Z

Admin: /* Основные подальфы */

2019-09-06T22:08:09Z

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

Admin в 10:35, 28 декабря 2016

2016-12-28T10:35:05Z

Admin: /* Основные подальфы */

2016-12-23T18:07:36Z

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

Admin в 10:21, 14 ноября 2016

2016-11-14T10:21:33Z

Admin: /* Дисциплины */

2016-11-02T11:23:17Z

‎Дисциплины

Admin в 21:24, 1 августа 2016

2016-08-01T21:24:00Z

← Предыдущая		Версия 09:55, 8 апреля 2024
Строка 45:		Строка 45:

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

	== См. также ==		== См. также ==

← Предыдущая		Версия 21:23, 30 июня 2022
Строка 1:		Строка 1:
−	'''Определение системы''' или '''Описание системы'''(system definition) — информация о [[Воплощение системы\|воплощении системы]].	+	'''Определение системы''' или '''Описание системы''' (system definition) — информация о [[Воплощение системы\|воплощении системы]].

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

@@ Строка 18: / Строка 18: @@
 == Рабочий продукт ==
-Рабочий продукт определения системы это описание системы, чаще известный как '''«проект системы» (design)''', часто бьётся на множество отдельных документов, баз данных, презентаций, докладных записок, цитируемых стандартов и даже физических макетов.
+[[Документация системы]]
 == Дисциплины ==

@@ Строка 1: / Строка 1: @@
-'''Определение системы'''. Перед тем, как сделать любую систему, её нужно определить (define), ибо нельзя сделать то, что “неопределено” (задача “пойди туда, не знаю куда, найди то, не знаю что” — это больше ведь исследовательская задача, а не инженерная. Чтобы воплотить в нашем четырёхмерном пространстве-времени какую-то систему, нужно как минимум иметь представление об этой системе, “определить” её).
+'''Определение системы''' или '''Описание системы'''(system definition) — информация о [[Воплощение системы|воплощении системы]].
 Альфой определения системы занимается системный инженер.
 == Основные подальфы ==

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

@@ Строка 34: / Строка 34: @@
 '''Описания''' — это [[Рабочий продукт|рабочие продукты]], которые выражают определение системы.
-[[Воплощение системы]] удовлетворяет определению системы, а определение системы характеризует (а пока системы нет, то определяет) воплощение системы.
+[[Метод описания|Группа описаний]] (view) группирует отдельные [[Модель|модели]]/отдельные описания (model). Так, финансовая группа описаний может группировать баланс и отчёт о прибылях и убытках, архитектурная группа описаний может группировать компонентные, модульные и описания размещения, а также какие-то гибридные описания. Каждая группа описаний имеет свой [[Метод описания|метод описаний]] (viewpoint). Тематический метод описания задаёт тематическую группу описаний по определенной тематике.
-[[Метод описания|Тематический метод описания]] (viewpoint) задаёт тематическую группу описаний (veiw) по определенной тематике.
+Любые группы описаний существуют только потому, что есть [[Стейкхолдер|стейкхолдеры]], заинтересованные в системе в той части, которая этими описаниями описываются. Если нет стейкхолдера, которому это описание нужно, то описания просто не должно быть — зачем трудиться для создания того, что не будет никем использовано? Если заинтересованный стейкхолдер есть, но нет нужного ему описания — большая вероятность, что интересы стейкхолдера не будут учтены (помним, что успешной системой называется та, которая удовлетворяет стейкхолдеров.
-Каждая группа описаний (view) имеет свой метод описаний (viewpoint).
+[[Воплощение системы]] удовлетворяет определению системы, а определение системы характеризует (а пока системы нет, то определяет) воплощение системы.
-−
-Группа описаний (view) группирует отдельные [[Модель|модели]]/отдельные описания (model).
-−
-Так, финансовая группа описаний может группировать баланс и отчёт о прибылях и убытках, архитектурная группа описаний может группировать компонентные, модульные и описания размещения, а также какие-то гибридные описания.
-−
-''Замечания по переводу:'' очень часто view и viewpoint переводят как “аспект”, но это не совсем верный перевод (тем более, что он не позволяет различить само описание, выполненное для какого-то аспекта — view, и знания о том, как делать такие описания — viewpoint). View — это то, что видишь. Viewpoint — это та точка, из которой видно то, что видишь. Видишь обычно много разного (разных моделей), объединённого тематикой: описания требований, архитектуры, финансовые описания, физические описания, описания безопасности и т.д.
-−
-Любые группы описаний существуют только потому, что есть [[Стейкхолдер|стейкхолдеры]], заинтересованные в системе в той части, которая этими описаниями описываются. Если нет стейкхолдера, которому это описание нужно, то описания просто не должно быть — зачем трудиться для создания того, что не будет никем использовано? Если заинтересованный стейкхолдер есть, но нет нужного ему описания — большая вероятность, что интересы стейкхолдера не будут учтены (помним, что успешной системой называется та, которая удовлетворяет стейкхолдеров.
 == См. также ==

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

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