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

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

Версия 21:07, 23 декабря 2016

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

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

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

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

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

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

Рабочий продукт определения системы это описание системы, чаще известный как «проект системы» (design), часто бьётся на множество отдельных документов, баз данных, презентаций, докладных записок, цитируемых стандартов и даже физических макетов.

Дисциплины

Практики

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

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

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

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

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

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

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

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

Тематический метод описания (viewpoint) задаёт тематическую группу описаний (veiw) по определенной тематике.

Каждая группа описаний (view) имеет свой метод описаний (viewpoint).

Группа описаний (view) группирует отдельные модели/отдельные описания (model).

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

Замечания по переводу: очень часто view и viewpoint переводят как “аспект”, но это не совсем верный перевод (тем более, что он не позволяет различить само описание, выполненное для какого-то аспекта — view, и знания о том, как делать такие описания — viewpoint). View — это то, что видишь. Viewpoint — это та точка, из которой видно то, что видишь. Видишь обычно много разного (разных моделей), объединённого тематикой: описания требований, архитектуры, финансовые описания, физические описания, описания безопасности и т.д.

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

См. также