Борьба со сложностью в мышлении

 

Edsger Dijkstra в 1974 году ввёл[133] понятие разделения интересов (separation of concerns) как способ упорядочивания человеческих мыслей о каком-то предмете. Этот принцип гласит, что нужно обсуждать сложные ситуации по одному интересу за раз, удерживая внимание на каком-то одном аспекте, одной ипостаси этой ситуации. Это не значит, что игнорируются все остальные. Просто это удерживание во внимании одного аспекта проблемы и одновременно всей проблемы. По словам Edsger Dijkstra про такое мышление, «It is being one – and multiple-track minded simultaneously».

И это разделение мышления по интересам проводится на каждом уровне системной холархии, поскольку ввиду эмерджентности на каждом уровне система начинает проявлять какие-то новые свойства.

Сложность обсуждения системы тем самым падает по двум направлениям:

• деление полного обсуждения всей системы на обсуждение её отдельных частей по уровням холархии. Каждая часть холона проще, чем холон в целом, поэтому обсуждение проходит более-менее единообразно на каждом уровне, каждая часть холона определяется его требованиями (requirements). В требованиях игнорируется внутренняя структура холона и его частей – это определение системы как «чёрного ящика».

• деление полного обсуждения каждого холона на обсуждение отдельных ипостасей этого холона как прозрачного ящика: принципов организации взаимодействия и структуры частей холона. Важнейшие из этих определений – это архитектура  (architecture), а все остальные определения с точностью, достаточной для изготовления – это неархитектурная часть проекта (non-architectural part of design).

Тем самым детальное и в подробностях обсуждение огромных сложных систем принципиально (в силу самой сути системного подхода) может быть разбито на достаточно маленькие части, и ни одна часть этого обсуждения не будет забыта, ни одно описание не будет пропущено. Как съесть слона? По кусочку за раз!

 

 

Системное мышление по своей природе коллективно, оно позволяет разделить умственный (по проектированию) и физический (по изготовлению и эксплуатации) труд системы, задействовать множество разных исполнителей стейкхолдерских ролей – и при этом обеспечивается детальное продумывание всех частей системы (холархия!) со всех сторон (множественность частных описаний!).

Но как договориться о том, как склеивать все эти самые разные частные описания самых разных частей системы в одно целое? Как договориться всем этим людям? Это можно сделать на основании 4D экстенсионализма. Все эти описания можно совместить, если понимать, что они описывают одно и то же место в пространстве-времени, относятся к одному и тому же воплощению системы. Без системного подхода сложные проекты с задействованием большого количества разных специалистов выполнить в срок и вовремя невозможно.

 

Требования как часть определения системы

 

Требования являются частью определения системы, и они в силу этого всегда есть: о них не принято говорить, что их разрабатывают (их не придумывают!), их обычно выявляют (discover) в разговорах с различными стейкхолдерами, а также в экспериментах. О требованиях хорошо думать примерно так же, как о цвете системы (который тоже может входить в требования, так что это не самый плохой пример).

Цвет – это не сама система, и это не часть описания системы (описанием для цвета был бы фрагмент текста с номером цвета из каталога цветов, или длиной волны для этого цвета, или названием цвета, или пятно краски нужного цвета, или значения интенсивностей красного-зелёного-голубого в составе цвета, и т.п.). Мы можем обсуждать цвет системы, можем выявлять пожелания к цвету у разных стейкхолдеров, а затем описывать выявленный цвет после выбора адекватного метода описания. Вот и самые разные требования как часть определения системы мы можем обсуждать, выявлять, а затем описывать после выбора метода описания.

Приключения требований на этом не заканчиваются: требования анализируют, затем их наборы делают непротиворечивыми, после чего обеспечивают к ним доступ самых разных стейкхолдеров (это обеспечение доступа и называется управление требованиями /requirements management). Всё вместе называют инженерия требований (requirements engineering). Обратите внимание, что как выявление требований входит в инженерию требований, так и управление требованиями. Управлять нельзя тем, чего ещё нет, а выявленные требования это только сырьё для дальнейшей работы.

В описаниях требования выражаются как спецификации требований, части технических заданий (технические задания обычно – это «задания на работы», требования в них маленькая часть), протоколы технических совещаний и т. п. Требования декомпозируемы: любое требование может быть разбито на множество более мелких, часто говорят о наборах требований.

 

Два понимания требований

 

Есть два понимания требований, которые нужно различать по контексту их употребления (помним, что люди вполне могут разбираться в высказываниях типа «косил косой с косой косой косой на косе» и понимают при этом, что у каждого слова может быть много значений):

1. Требования (requirements) – это часть определения системы, определяющая систему как «чёрный ящик», т.е. что делает система по отношению к её системному окружению, без описания внутренней структуры системы, происходящих внутри системы взаимодействий частей системы. Прежде всего тут важно поведение системы, выполнение ей своего назначения, функции в использующей системе. Поэтому основные требования называют функциональными требованиями. Нефункциональных требований не бывает, хотя в литературе этот термин регулярно встречается, но он считается некорректным: все требования описывают какое-то поведение системы, ожидания этого поведения. Но речь не всегда идёт о поведении в использующей системе. Требования качества в отличие от функциональных, относятся прежде всего к поведению в обеспечивающих системах, в том числе обслуживающих уже готовую систему: по-английски их иногда называют – ilities (reliab ility, accessab ility и т.п.), а по-русски – ости  (надёжн ость, доступн ость, и т.п.).

Требования отличают от потребностей (stakeholder needs, stakeholder requirments) как требований внешних стейкхолдеров к использующей системе. Если мы выходим за пределы инженерии, то у требований могут быть другие имена. Например, для организаций речь может идти о стратегии – но суть тут будет та же самая: описание того, что хотелось бы получить от организации. Требования, взятые вместе со временем их выполнения, называют контрольными точками  (milestone). Если требование – это «помидор красный», то «помидор красный, 10 мартобря 2019 года» будет контрольной точкой. Очень часто на контроле стоят не сами требования, а контрольные точки: «дорога ложка к обеду».

2. Альтернативное понимание требования уже не имеет отношения к системному подходу, не связано с границами системы. Это просто любое утверждение, данное в деонтической модальности. Любое высказывание из описания системы (например, «X=10») невозможно как-то понять по отношению к деятельности без указания на модальность (modality)[134]: то, как нужно понимать значения высказывания. Скажем, «в системе [существует] X=10» это алетическая (aletic) модальность, модальность существования. «Я верю, что в системе X=10» – это модальность доксическая (doxastic), веры. Деонтическая (deontic) модальность говорит о долженствовании, разрешении, рекомендации[135]: «Я требую, чтобы X=10». В этом втором понимании требований можно потребовать что угодно – и оно станет требованием, даже если речь идёт не о чёрном ящике. Например, «в автомобиле должен быть корпус из углепластика», «в смартфоне должны быть использованы отечественные микропроцессоры» относятся к «прозрачному ящику», но слова «должен» и «должны» указывают на деонтическую модальность.

Ограничения (constraints) свободы принятия решений по поводу «прозрачного ящика» связаны именно с таким пониманием: ограничения как высказывания в деонтической модальности по поводу устройства «прозрачного ящика» поступают вместе с функциональными требованиями и требованиями качества, но их часто тоже называют требованиями не по их системному пониманию, а по альтернативному, деонтическому. Поэтому «в автомобиле должен быть корпус из углепластика» является не требованием, а ограничением с точки зрения системного подхода, но «по бытовому» это тоже требование.

 

Требования и холархия

 

Стандарт описания требований ISO/IEC 29148:2011 подчёркивает то, что требования есть у каждого холона в холархии. Вот пример из этого стандарта:

 

 

Чтобы лучше понять этот пример, нужно «перевести с айтишного» слово business.

Стандарт ISO/IEC 29148:2011 даёт чёткое указание, что слово бизнес (business) тут просто условный термин, обозначающий просто организацию (organization): «The term business is used even though it could apply to not-for-profit organizations such as in the public sector. Users of this standard may replace each occurrence of the term business with the term organization or organizational depending on the users’ environment».

Это относится не только к требованиям, но и ко многому другому. Так бизнес-процесс лучше называть организационным процессом.

Картинка очень неподробно и схематично показывает холархию какой-то организации, в которой внутри организационного окружения (organization environment) находится вся работающая организация (business operation), в которой содержится какая-то часть организации, работающая с системой (system operation), в которой есть система (system), в которой есть элемент системы (system element), в котором есть программное обеспечение (software). Каждый из указанных холонов в холархии имеет какие-то описания «чёрного ящика», называемые требованиями – и на картинке некоторые из них показаны зелёными стрелками, указывающими на границы соответствующих вложенных друг в друга систем-холонов.

Целевой системой тут является «система» (system), требования к ней так и называются: системные требования (system requirements).

Требования к использующей системе будут называться требования стейкхолдеров (stakeholder requirements) или потребности/нужды стейкхолдеров (stakeholder needs). Их не перепутать: они описывают разные системы на их границах (как «чёрный ящик», без подробностей про внутреннее устройство каждой из систем), на картинке это чётко видно.

Мы привели эту картинку для того, чтобы показать присутствие в проекте множества самых разных требований.

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

 

Целеориентированная инженерия требований

 

Идея о том, что требования не «объективны», а их субъективно задают стейкхолдеры для того, чтобы достичь каких-то целей, не так уж стара.

В 1986 году Ивар Якобсон предложил технику выявления требований, при которой рассматриваются варианты использования (use cases)[136].

Вариант использования определяет взаимодействие между пытающимися достичь своих целей внешними актёрами (actors) и целевой системой.

Актёры в вариантах использования (в других практиках термин актёр/актор/actor может означать совсем друге) это функциональные объекты, которые необязательно люди: они могут быть людьми, компанией или просто предпринятием, компьютерной программой, или даже компьютером.

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

Вот типичная диаграмма вариантов использования[137]:

 

 

В 1995 году появился подход к моделированию требований, называемый i*[138], и он продолжил идею взаимодействия актёров и системы для достижения своих целей. Упор был сделан не только на варианты использования системы актёрами, но и на описания взаимодействий самих актёров, а весь подход получил название целеориентированной инженерии требований (goal-oriented requirements engineering). В философии тех, кто может иметь свои цели, принято называть агентами (agents) – независимо от живой или неживой (например, системы искусственного интеллекта) природы этих агентов.

В i* приняли, что требования отражают цели, убеждения, возможности и договорённости агентов, окончательно признав социальную природу требований, их «необъективность»: «Agents attribute intentional properties (such as goals, beliefs, abilities, commitments) to each other and reason about strategic relationships. Dependencies between agents give rise to opportunities as well as vulnerabilities. Networks of dependencies are analyzed using a qualitative reasoning approach. Agents consider alternative configurations of dependencies to assess their strategic positioning in a social context».

Был предложен язык для записи взаимодействий актёров, преследующих свои цели:

 

 

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

В 2008 году международный союз телекоммуникаций принял стандарт ITU-T Z.151[139], в котором для моделирования требований предлагался целеориентированный язык требований подхода i* (Goal-oriented Requirements Language) и карты вариантов использования (Use Case Maps). В простейшем случае вариант целеориентированной системной инженерии предполагает написание коротких пользовательских историй (user story), в которых актёр сведён до обычной стейкхолдерской роли. Пример формата таких историй[140]: «Я как _стейкхолдер_ хочу, чтобы _ целевая-система_ _формулировка требования _, для того чтобы _потребности-для-использующей-системы_».

 

Проверка и приёмка

 

Проверка и приёмка (verification and validation, V&V, верификация и валидация) служат для того, чтобы убедиться в работоспособности системы. По сути, это просто тщательное тестирование системы, проведение испытаний, обоснование успешности системы. Успешность – это соответствие ожиданиям стейкхолдеров. Стейкхолдеров же у нас два набора:

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

• и внутренние, которых волнует работоспособность целевой системы – работает ли целевая система как задумано, удовлетворяет ли системным требованиям?

Почему же используется два слова? Потому что по факту проверяется работоспособность двух систем, проводятся два набора испытаний: проверочные (целевой системы, соответствие её требованиям) и приёмочные (использующей системы, соответствие её потребностям).

 

 

Почему это так важно различать? Потому что не факт, что команда инженеров правильно сформулировала требования. Вполне возможно, что при попадании целевой системы в её системное окружение появится взаимодействие между элементами системы, которое не было учтено в требованиях – и требования будут удовлетворены, а потребности – нет. Инженеры будут считать, что они выполнили требования, и требовать оплаты за работу. А стейкхолдеры будут считать, что денег за работу давать не нужно, ибо для них система оказывается бесполезна. И стейкхолдеры всегда найдут способ доказать, что они правы. Поэтому целевая система не только проверяется, но и использующая валидируется.

Испытания/тестирование разного сорта могут составлять до 85% от общей стоимости проекта. Именно потому, что недостаточно проверки/верификации, но ещё нужна и валидация, в испытаниях требуется участие не только целевой системы, но и значительной части её системного окружения. Поскольку системное окружение может быть недоступно, или очень дорого, то это требует часто создания испытательных стендов, более дорогих, чем сама целевая система. В результате какая-нибудь задвижка для атомной станции оказывается полностью идентичной задвижке для городского водопровода, но будет стоить впятеро дороже: потому что её много тщательней испытывали.

 

Понятие архитектуры

 

Архитектура, как и любое другое определение системы, всегда есть – начиная с того момента, когда вы выделили систему из окружающего мира. Не всегда есть архитектурное описание. Архитектура дана нам в виде архитектурных описаний, и поэтому в речи и текстах часто путаются понятия «архитектуры» и «архитектурного описания». Обычно понятно из контекста, о чём идёт речь.

Так, «цвет» шкафа тоже есть, но есть и описание цвета – слово «чёрный», код цвета по одной из цветовых моделей[141] или даже попытка воспроизвести этот цвет ■ (на каком-то носителе, вот прямо как тут). Но если есть шкаф, то и цвет у него есть. И архитектура у шкафа есть. Но может не быть описание цвета (нигде не будет написано, какой у шкафа цвет), как может не быть описания архитектуры.

Об описании цвета или архитектуры мы говорим, или о самом цвете или архитектуре – это понимаем из контекста, или проговариваем явно. Если мы говорим «цвет нужно сделать почернее», то это про цвет, а если «цвет в кодировке RGB», то про описание цвета. С архитектурой всё то же самое.

ISO 42010 даёт следующее определение архитектуры: «Архитектура (системы) – основные понятия или свойства системы в её среде, заключающиеся в её элементах, их отношениях и принципах её проектирования и развития»[142]. Обратите внимание, что в этом определении нет никакого упоминания структуры системы. Ибо для такой системы как интернет нельзя указать на структуру системы: в интернете никто не знает, что входит в структуру интернета в каждый конкретный момент, какие есть связи между элементами этой системы, непрерывно появляются и исчезают новые узлы интернета и между ними непрерывно появляются и исчезают новые каналы связи. Но определение от этого не стало понятней.

Вот другое определение архитектуры, от части авторов того же ISO 42010, но данное ими в книге про документирование системных архитектур[143]: «Архитектура системы это набор структур, необходимых для рассуждений о системе, каковые структуры состоят из элементов, отношений и свойств этих элементов и отношений»[144]. Там наоборот, дан акцент на структуры.

Но самых разных определений много больше, и в интернете есть место, где собрано более 150 таких определений[145]. Самые разные стейкхолдеры определяют архитектуру по-разному, с акцентом на те или иные её свойства, те или иные классы целевых систем.

Мы будем придерживаться неформального простого и понятного определения архитектуры, которое дал Ralf Johnson: «Архитектура – это обо всём важном. Что бы это ни было.»[146].

Эти слова обычно указывают на важные решения, которые могут быть для «железных» систем инженерные, для предприятия организационные, менеджерские или предпринимательские, в случае танцев – постановочные решения, и т. д. Важные решения определяются как такие, в случае принятия альтернативных решений по ним придётся перепринять большинство других решений, то есть перепроектировать и затем переделать всю систему. Так, если при проектировании самолёта принято решение сделать его с реактивным двигателем, а не обычным поршневым, то это означает переделку практически всей конструкции: от устройства топливной системы до формы крыльев и фюзеляжа. Если в здании принято решение печатать его на бетонном 3D-принтере, а не выкладывать его из бетонных блоков или даже из кирпича, то смело можно переделывать всю проектную документацию – или переделывать весь дом, если он уже построен.

Если принято решение сделать какой-то винтик не с левой резьбой, а с правой, то вряд ли это приведёт к переделке всего изделия. Будет переделан лишь этот винтик и резьба в связанной с ним гайке. Такое решение не архитектурное. Весь проект/design тем самым делится на две части: архитектура и неархитектурная часть проекта  (non-architectural part of design).

Архитектурное описание в простейшем виде представляет собой список принятых важных инженерных решений. При этом то, что одному архитектору кажется важным, другому архитектору может казаться неважным – это не «объективный» список, он существенно зависит от опыта и знаний того, кто этот список составляет. Важно при этом, что такой список находится не в голове архитектора, а выписывается отдельно, документируется. Неважно, будет ли это документирование в форме электронного текста или таблицы, или в виде бумажного документа, или просто в виде записей фломастером на флип-чарте – подойдёт любая форма, в которой эти важные решения перечислены, и их можно обсудить с командой проекта и внешними экспертами.

Более сложные формы архитектурных описаний включают в себя компонентные, модульные диаграммы, трассировку компонент и их функций к модулям, размещения и компоновки. То есть архитектурное описание это совсем необязательно список принятых решений: решения могут быть документированы и в других формах. Главное, чтобы они не оказались устными. Интересно, что в советской устной архитектурной традиции, когда архитектурных описаний практически не было, всё важное обозначалось словами «заделы», «опыт», «наработки». Архитектуры были, но их нельзя было предъявить, обсудить, передать, развить иным способом, кроме как задействовав ту команду, которая имела тот самый «опыт» и «заделы» в голове.

Обычно важнейшими архитектурными решениями оказываются решения модульного синтеза: какие модули выбираются для выполнения каких потребных функций. Тем самым в архитектуру попадают решения по верхнеуровневому разбиению на функции, и верхнеуровневому разбиению на модули – в их взаимосвязи. Иногда функциональные описания называют логической архитектурой, а модульные описания и описания компоновки – физической архитектурой. Есть и возражение к такой терминологии: архитектура это про всё важное, а если выбирать только логические и только физические части важного, то это только части архитектуры, а не отдельные архитектуры. Тем не менее, термины эти можно встретить довольно часто, равно как часто можно встретить и другой нерекомендованный термин «нефункциональные требования».

Все эти решения оказываются не только субъективными в части отнесения к архитектурным (и поэтому нельзя провести чёткую границу между «важным» и «неважным»), но относительными в части принятия их разными стейкхолдерами: что архитектурное для одного, неархитектурное для другого. Если один конструктор делает самолёт (целевая система), а другой делает к нему двигатель (подсистема), то для первого выбор типа топливного насоса – неархитектурное решение, а для второго – важное архитектурное решение.

 

 

На рисунке субъективность отнесения к архитектурным решениям показана насыщенностью цвета, при этом стрелки примерно соответствуют небольшому числу взаимосвязанных решений, определяющих все остальные решения. Стейкхолдеров-архитекторов показано два: один занимается архитектурой всей системы, другой архитектурой подсистемы. Где остановиться в принятии архитектурных решений? Спускаясь по отношениям часть-целое в холархии нужно остановиться там, где стейкхолдер-архитектор считает, что там уже нет его важных решений, то есть работа уже поделена между разработчиками модулей и дальше будут их важные решения.

Требования, которые однозначно ведут к архитектурным решениям часто называют архитектурными требованиями. Например, для самолёта скорость является архитектурным требованием. Если самолёт должен обеспечивать скорость 0км/час, то его архитектура должна быть архитектурой вертикального взлёта и посадки. Если скорость должна быть 2000км/час, то это может быть обеспечено только для реактивного самолёта.

Итак, архитектура это (с точностью до разницы между определением и описанием – самой архитектурой и выражающими её рабочими продуктами):

• самые важные части функционального и конструктивного определений системы в их взаимосвязи, или оно же как

• компоненты + модули + размещения (только важные, верхнеуровневые), или оно же как

• принципиальная схема + заказная спецификация + компоновка (только важные, верхнеуровневые), или оно же как

• логическая архитектура + физическая архитектура (при учёте возражения о недопустимости «частных архитектур»), или оно же как

• список важнейших принятых конструкторских/проектных/постановочных решений

 

Понятие конфигурации

 

Конфигурация (configuration) – это текущее актуальное состояние холархии системы и её описаний. Обычно в ходе разных проектов порождается множество самых разных вариантов частей воплощения системы, множество самых разных описаний системы, относящихся к разным моментам времени, разработанных самыми разными людьми, и нужно понимать – какие изо всех этих частей системы входят в холархию, и какие описания являются для них актуальными.

В ходе разработки инженерной системы обычно рассматривают самые разные варианты требований, архитектуры, неархитектурной части проекта/design. И эти описания ещё и изменяются каждое по нескольку раз. Как определить, какие из этих описаний должны быть использованы изготовителями системы? А если часть изготовителей изменили систему так, что она уже не соответствует этим описаниям, а часть изготовителей работает «как договаривались» – можно ли быть уверенным, что из изготовленных частей можно будет собрать работающую систему? Конечно, нет. Ошибки, связанные с тем, что некоторые части системы и их описания не известны, или даже известны, но не соответствуют друг другу, весьма распространены.

Конфигурация системы – это сами части системы и их описания. Сама конфигурация может быть определена (defined) и, соответственно, описана (described). Описание конфигурации (configuration description, иногда говорят и «конфигурационное описание») в речи часто сокращают до просто «конфигурация» – и разницу между конфигурацией (составом самой системы) и описанием конфигурации нужно определять из контекста так же, как разницу между архитектурой и архитектурным описанием, когда для обоих используют слово «архитектура».

Управление конфигурацией (configuration management) – отслеживание, что конфигурация воплощения системы и описания системы известны и соответствуют друг другу. Это дисциплина лежит посредине между менеджерскими и инженерными дисциплинами. Конфигурация составляется из конфигурационных единиц (configuration item) – самых мелких частей, на которые делится система в части её логистики. Речь идёт о единицах передачи частей системы и описаний этих частей от одного исполнителя работ к другому, от одной обработки к другой.

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

Чтобы не потерять эти конфигурационные единицы при учёте, иметь возможность на них сослаться в разговоре и различных описаниях системы, им даются индивидуальные обозначения (designations). Стандарт IEC 81346[147] представляет собой стандарт, в котором предлагается типовой способ такого описания, учитывающий системный подход – наличие нескольких альтернативных структур системы (компонентной/функциональной, модульной/продуктной, размещений, и т.д.).

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

Версия (version) системы – это её конфигурация по состоянию на какой-то момент времени. Отслеживание смены версий в результате изменений (changes) нужно для того, чтобы точно указывать, какая из многочисленных возникающих и исчезающих по ходу проекта конфигураций системы имеется ввиду.

Базис (baseline, конфигурационный базис) – это проверенная на целостность и утверждённая административно версия.

Управление изменениями (change management) часто включают в состав управления конфигурацией (так и пишут: «управление конфигурацией и изменениями», но обычно это отдельная дисциплина. Её не нужно путать с управлением организационными изменениями – как нужно менять организацию, чтобы это не вызывало сопротивления людей и вело к положительным результатам. Инженерное управление изменениями – это про то, как принимать решения по изменению конфигурации, чтобы минимизировать конфигурационные ошибки. Для этого в конфигурации различают обычные рабочие версии с более простыми внесениями изменений и базисы, внесение изменений в которые связано с дополнительными инженерными и административными проверками на целостность конфигурации.

 

Инженерия предприятия

 

Обеспечивающая система – тоже система, только нужно не забывать, что всё её существование связано с целевой системой и поэтому не нужно говорить, что она сама целевая. Если вы поставляете какой-нибудь продукт для использования в составе какого-то предприятия или предпринятия (или его части, если речь не идёт обо всём предприятии или предпринятии в целом), то оно будет использующей системой для вашего продукта. Часы, которые вы поставили автомобильному заводу, могут быть использованы заводчанами (а не «пользователями часов») либо в выпускаемом заводом автомобиле (и заводчане тогда не «пользователи часов!»), либо в заводском цеху (и тогда заводчане сначала выступают как разработчики цеха как использующей системы для часов, а потом и как пользователи для часов).

В случае инженерии предприятия все системные рассмотрения остаются, только может меняться терминология. Так, потребности и требования могут называться стратегией, модулями предприятия называются подразделения (более общий термин – организационное звено, ведь в предприятии могут быть и «правления» и «советы», которые не являются подразделениями в обычном смысле слова, но явно включены в организацию), компонентами предприятия являются его практики, а управление конфигурацией предприятия называется учётом.

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

 

 

Понятие жизненного цикла