Система — различия между версиями
Admin (обсуждение | вклад) (→Системы с участием людей) |
Admin (обсуждение | вклад) м (→Состояния) |
||
| Строка 71: | Строка 71: | ||
❑ Система может быть опробована и её ключевые характеристики могут быть измерены. | ❑ Система может быть опробована и её ключевые характеристики могут быть измерены. | ||
| − | ❑ Критические [[Конфигурация|конфигурации]] оборудования были продемонстрированы. | + | ❑ Критические [[Конфигурация системы|конфигурации]] оборудования были продемонстрированы. |
❑ Критические [[Интерфейс|интерфейсы]] были продемонстрированы. | ❑ Критические [[Интерфейс|интерфейсы]] были продемонстрированы. | ||
Версия 16:12, 18 ноября 2016
Термин (слово) “система” используется минимально в трёх различных смыслах, которые следует различать:
- “Система” из системного подхода. Система определяется как иерархия холонов — холархия. Холон — это что-то, что является одновременно целым для своих частей и само является частью для какого-то объемлющего целого. Система — это холон, у которого есть появляющиеся (emergent) свойства, получающиеся от взаимодействия его частей. “Эмерджентность” — это главное свойство системы: “целое больше, чем сумма его частей”. В системной инженерии холоны представляют собой индивиды, имеющие пространственно-временную протяжённость.
- “Система” из систематики — различные классификационные (таксономические) “системы”. Это тоже иерархии, но элементами в них являются классы (множества), отсюда и название — классификаторы. Конечно, в системном подходе системы часто классифицируются по самым разным признакам, но нужно помнить, что “система классификации” — это не система из системного подхода, там нет эмерджентности, нет отношений часть-целое и холонов. Классификаторы и таксономии — это предмет систематики, а не системного подхода. Системы из инженерного системного подхода классифицируются “системами” из систематики.
- “Система” как указание на какой-то набор правил, процедур, обычаев, имеющий какую-то (совсем необязательно иерархическую) структуру. Тут слово “система” указывает на какую-то упорядоченность, неслучайность, продуманность. Это не имеет отношения к системному подходу, не подразумевает специально устроенного мышления, похожего для всех этих разных систем. Хотя и тут опытный глаз сможет уловить какие-то “части-правила” и эмерджентность “целой системы”, демонстрирующей в целом наборе правил что-то большее, чего нет в каждом отдельном правиле.
Системные инженеры никогда не начинают рассматривать систему как состоящую из каких-то частей. Системные инженеры понимают, что любая система это холон (целое, состоящее из частей-подсистем, и само являющееся частью целого-надсистемы) — и начинают рассмотрение с того, что “холон это часть другого холона”, а не “холон состоит из частей-холонов”. Это позволяет системному инженеру хорошо ориентироваться в сложном мире: ни на секунду он не теряет контекста, оставаясь способным обсуждать как самый маленький винтик в самом маленьком приборе, так и совсем огромные системы планетарного масштаба. От этих “скачков масштаба” он не сходит с ума, для него это самая обычная процедура: поменять целевую систему в ходе обсуждения на надсистему или подсистему — главное, чтобы он это делал осознанно. Системный подход даёт нам операторы “select” (выбора объекта для действия) и "zoom" (как в фотоаппаратах, можно выбрать подходящий масштаб разбирательства с ситуацией).
В холархии каждая система сначала характеризуется своей основной функцией в качестве части надсистемы (т.е. в каком операционном окружении будет находиться их целевая система, зачем она нужна надсистеме, какая функция целевой системе в её операционном окружении), а уж только затем —из каких она состоит частей, какая у неё конструкция, как она устроена.
“Система — в глазах смотрящего”, нет никакого “объективного” способа определить систему без упоминания стейкхолдеров. Система определяется (Определение системы — ещё одна альфа из схемы инженерного проекта) так, чтобы это определение было удобно для деятельности стейкхолдера. Какого? В разных случаях разного: поэтому определение системы может существенно отличаться от стейкхолдера к стейхолдеру, речь может идти об абсолютно разных системах и может потребоваться огромная работа по согласованию этих определений. Стейкхолдеры — это люди/организации которые в принципе будут действовать, если им эта система нужна или наоборот, мешает.
Содержание
[убрать]Границы системы
Любая система имеет свою “границу” — так говорят о том, что какие-то объекты мира включаются как части в состав “целого” системы, а какие-то объекты не включаются. “Система” — это такой способ указать на специальным образом выделенный кусок мира в его противопоставлению тому миру, который остался за границей системы.
Граница системы определяется субъективно как удобная для целей деятельности стейкхолдеров, деятельностно-субъективно, а не личностно-субъективно. Объективация же границы проходит как согласование определения системы между различными стейкхолдерами: стейкхолдеры подстраивают свои деятельности так, чтобы в них появлялась система в одинаковых для всех границах. Как правило, все стейкхолдеры в момент начала проекта представляют систему по-разному, и по-разному проводят границу между системой и её средой (системами в операционном окружении).
Имеется несколько критериев, помогающих определить, должен ли некоторый объект определяться как часть системы:
- Контроль со стороны разработчика - контролирует ли разработчик системы разработку данного объекта? Может ли разработчик повлиять на требования к объекту или эти требования определяются независимо от желания разработчика? Средства выделяются из бюджета разработчика или финансирование осуществляет другая организация?
- Контроль эксплуатации - будет ли эксплуатация данного объекта после внедрения системы находиться под контролем организации, эксплуатирующей ее? Будет ли владелец системы определять цели и задачи, стоящие перед этим объектом? Будет ли эксплуатационный контроль время от времени переходить к другой организации?
- Привязка функций - при функциональном описании системы может ли системный инженер привязывать функции к определенным объектам?
- Единство цели - необходим ли данный объект для успешной работы системы? Можно ли после внедрения системы удалить его без ущерба для других объектов?
Классификация систем по ISO 15288
- Целевая система (system-of-interest) — та, которая подлежит созданию (или модернизации) командой инженеров и рассматривается на всём протяжении жизненного цикла. Например, насос.
- Система в эксплуатационной среде/операционном окружении (system in operational environment) — одна из систем, которые окружают целевую систему в момент её эксплуатации. Например, трубопроводная система, к которой подключён насос во время эксплуатации.
- Обеспечивающая система (enabling systems) — система, которая создаёт и поддерживает систему в ходе её ЖЦ. Например, цех, который производит насос.
Любую систему можно классифицировать либо как целевую, либо как обеспечивающую, либо как систему в операционном окружении. Вот диаграмма, показывающая, что существует множество обеспечивающих систем, которые на стадии своей эксплуатации выполняют работы по обеспечению (enabling) той или иной стадии ЖЦ целевой системы. Сама же целевая система на стадии своей эксплуатации работает в составе систем своего операционного окружения, выполняя свою функцию:
Успешность системы
Системы систем
см. Система систем
Системы с участием людей
Если ISO 15288 говорил, что “в состав системы люди могут как входить, так могут и не входить”, то на сегодняшний день очевидно, что какие-то более-менее сложные системы без людей рассматривать нельзя. А поскольку каждый человек владеет как минимум сам собой как подсистемой, то рассмотрение “системы систем” вместо “просто системы” возникает сегодня много чаще. Системы сегодня рассматривают не столько уже как киберфизические, но как социотехнические или кибер-физико-человеческие (cyberphysic-human). Одной из поддисциплин системной инженерии также является организационная инженерия.
Состояния
OMG Essence определяет следующие состояния для альфы "Программная система" и контрольные вопросы для проверки каждого состояния:
| № | Состояние | State | Описание состояния | Контрольные вопросы |
|---|---|---|---|---|
| 1 | Архитектура выбрана | Architecture Selected | Архитектура, которая адресует ключевые технические риски и любые применимые организационные ограничения, выбрана. | ❑ Критерии, которые должны быть использованы при выборе архитектуры, согласованы.
❑ Аппаратная платформа определена. ❑ Языки программирования и используемые технологии выбраны. ❑ Границы системы известны. ❑ Значимые решения об организации системы приняты. ❑ Решения о том, что покупать, что создавать, а что переиспользовать, приняты. |
| 2 | Демонстрируемая | Demonstrable | Исполняемая версия системы, которая демонстрирует, что архитектура пригодна для использования, доступна и поддерживает тестирование. | ❑ Ключевые архитектурные характеристики были продемонстрированы.
❑ Система может быть опробована и её ключевые характеристики могут быть измерены. ❑ Критические конфигурации оборудования были продемонстрированы. ❑ Критические интерфейсы были продемонстрированы. ❑ Интеграция с другими существующими системами была продемонстрирована. ❑ Необходимые стейкхолдеры согласны, что демонстрируемая архитектура подходит. |
| 3 | Подходит для использования | Usable | Система подходит для использования и демонстрирует все качественные характеристики эксплуатируемой системы. | ❑ Система может эксплуатироваться использующими её стейкхолдерами.
❑ Функциональность, обеспечиваемая системой, протестирована. ❑ Результат работы системы приемлемдля стейкхолдеров. ❑ Уровни дефектов приемлемы для стейкхолдеров. ❑ Система полностью документирована. ❑ Содержание релиза известно. ❑ Добавляемая польза, обеспечиваемая системой, ясна. |
| 4 | Готова | Ready | Система (как целое) была принята для разворачивания в её эксплуатационном окружении. | ❑ Установочная и другая пользовательская документация доступна.
❑ Представители стейкхолдеров принимают систему как удовлетворяющую своему назначению. ❑ Представители стейкхолдеров хотят принять систему в эксплуатацию. ❑ Эксплуатационная поддержка наличествует. |
| 5 | Эксплуатируется | Operational | Система используется в её эксплуатационном окружении. | ❑ Система сделана доступной стейкхолдерам, которые намерены её использовать.
❑ Есть как минимум один пример полностью работающей системы. ❑ Система полностью поддерживается на согласованном уровне сервиса. |
| 6 | Выведена из эксплуатации | Retired | Система больше не поддерживается. | ❑ Система была заменена или прекращена в использовании.
❑ Система больше не поддерживается. ❑ Нет «официальных» стейкхолдеров, которые до сих пор используют систему. ❑ Апдейты к системе больше не будут производиться. |