Разное

• Курс лекций о введении в системную инженерию (Левенчук Анатолий Игоревич, 2012). Первые две лекции "весьма вводные" — при просмотре их можно смело перематывать. Самое интересное начинается примерно с середины третьей.

Книги

• litres.ru — купить печатную/электронную книгу "Системное мышление. Учебник" Анатолия Левенчука (2022)
• ridero.ru — купить печатную/электронную книгу "Системное мышление. Учебник" Анатолия Левенчука (2022). Я покупал бумажный вариант ещё первого издания и в цифровом виде. Рекомендую, соотношение польза/цена крайне высокое.
• (DOC) Подход системной инженерии к управлению ЖЦ. Понятийный минимум (2008)

Стандарты

• (PDF) ISO 15288-2015 Systems and software engineering — Systems life cycle processes.
• (PDF) ГОСТ Р 57193-2016 Системная и программная инженерия. Процессы жизненного цикла систем.
• (PDF) ISO 29148-2018. Systems and software engineering — Life cycle processes — Requirements engineering

Контринстинктивность/контринтуитивность в мышлении.

Люди обычно проникают вглубь вещей, обычно на один шаг, один уровень.
Системный инженер проникает внаружу вещей, смотрит вверх, вовне.

Функция как поведение объекта для какого-то назначения.

Формы обратной связи

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

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

• система (system) — совокупность (комбинация) взаимодействующих элементов, организованных для достижения одной или нескольких поставленных целей.
  • Целевая система (system of interest)
  • Обеспечивающая система (enabling system). Это та система, которая берёт Целевую систему за шкирку и тащит её по жизненному циклу (lifecycle).
  • Система в операционном (эксплуатационном) окружении (system in operational environment) — системы, которые непосредственно связаны с целевой системой, с выполнением ею своей функции
• интерес (concern) в значении "забота"
• стейкхолдер (stakeholder)

Система определяется как иерархия холонов — холархия. Холон — это что-то, что является одновременно целым для своих частей и само является частью для какого-то объемлющего целого. Система — это холон, у которого есть появляющиеся (emergent) свойства, получающиеся от взаимодействия его частей. Эмерджентность — это главное свойство системы: "целое больше, чем сумма его частей" (синергия).

О системе говорят в терминах функции. Систему задаёт функция, а не конструкция. В функции главное — назначение.

Один и тот же объект может выполнять разные функции, принадлежать разным системам. Один и тот же человек в одной системе — преподаватель, а в другой системе — муж жены.
Одна и та же конструкция может выполнять разные функции Ф1..Фn. Например, один и тот же камень может быть якорем, а может быть подпоркой.
Одна и та же функция может поддерживаться различными вариантами конструкций, К1..Кn. Например, в системе водоснабжения может использоваться одна марка насоса, а может другая.
Это есть дуализм — система представляет из себя пару из Функции и Конструкции.

Воображение системного инженера одновременно зажигает три экрана: надсистемы (группа деревьев), системы (дерево), подсистемы (лист дерева).
Иногда включаются и другие экраны: наднадсистема (лес) и подподсистема (клетка листа).
А главное — всё это видно в развитии, потому что работают боковые экраны, показывающие прошлое и будущее на каждом уровне.

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

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

На практике чаще всего встречаются следующие системно-инженерные роли:

• системный инженер — отвечает за весь жизненный цикл системы;
• системный аналитик — отвечает за требования к системе, за целостность Функции.
• системный архитектор — отвечает за системную архитектуру, за целостность Конструкции. Архитектор думает как требования удовлетворить. Для этого Архитектор должен досконально знать свою предметную область.
• системный тестировщик — отвечает за тестирование системы;
• системный администратор — отвечает за обслуживание системы

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

V-диаграмма как принципиальная схема ЖЦ

V-диаграмма с добавлением подальф определения и воплощения системы:

Виды жизненных циклов

Водопад:

Спираль:

Спираль — с методом гибкой (agile) работы, SCRUM, использующийся в разработке ПО

Фазы жизненного цикла системы в разрезе деятельностей

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

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

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

Для реализации практики, организация должна иметь:

• оргспособность (enablers) = структурная способность организации к выполнению работ.
• оргвозможность (capability) = функциональная способность к выполнению работ в организации. "Поставленная практика", загруженные уже в головы стейкхолдеров-исполнителей знания по дисциплине и развёрнутый и опробованный инструментарий

25 обязательных практик (processes) ISO 15288

Технические практики проектирования

Требование (requirement) = утверждение (statement), которое переводит или выражает нужды (needs) и связанные с ними обстоятельства (conditions) и ограничения (constraints).

Инженер по требованиям:

• находит требования
• отвечает за целостность функции
• умеет быть лидером (leadership) — упаковывать живых тушек с личными интересами в культурно-обусловленные позиции. Работает с людьми
• умеет быть социотехником — найти и извлечь все требования из человека в позиции . Работает с диаграммами целеполагания (early requirements engineering). Работает с безличными группами людей.
• умеет быть инженером — понимать архитектуру, разбираться в инженерных обоснованиях, читать чертежи.

1. Сначала выявляются цели создания Системы (бизнес-требования). Может сложиться впечатление, что фиксация данных требований не является обязательной для разработки. Но в этом случае у Исполнителя не будет возможности контролировать соответствие разработанной Системы тем целям, для которых она создавалась, а так же – возможности устанавливать семантические зависимости между целями разработки системы и сценариями её использования;
2. Далее определяются роли пользователей Системы (как людей, так и других программных систем, см. стейкхолдеры). После этого выявляются и описываются сценарии использования Системы каждой из данных ролей. Так формируются Требования пользователей.
3. Далее разрабатывается полный набор требований к функционалу Системы таким образом, чтобы данная функциональность позволяла выполнить все сценарии, описанные в Требованиях пользователей. Так же фиксируются ограничения для Системы и параметры среды её функционирования.

Бизнес-требования

Бизнес-требования (Business Requirements, BR) или Стейкхолдерские требования (Stakeholder Requirements, StR) или Пользовательские требования (User Requirements) — обычно описывают проблемную область, определяют контекст, в котором система будет функционировать, — но не то что именно она делает, а её роль, которую она играет в глобальном окружении.
Формулируются рынком, внешними регуляторами, Заказчиком, Пользователями. Требования от разных стейкхолдеров могут быть противоречивы, разрознены и неполны.

Кому эти требования необходимы:

• Заказчикам ПО
• лицу, заключающему контракт на разработку ПО
• Тестировщикам для валидации

Системные требования

Системные требования (System Requirements) — Требования, которые достаточны для разработки/доработки Системы.
Системные/подсистемные требования определяют то, что система должна иметь возможность делать. Они берут свое начало на высоком системном уровне, затем анализируются и декомпозируются, чтобы образовать требования для подсистем уровнем ниже. Они могут выражаться в простых формах ("система должна..."), либо изображаться в виде моделей и диаграмм.

Кому эти требования необходимы:

• Заказчикам ПО
• руководству компании-Разработчика
• Разработчикам
• Тестировщикам для верификации
• Администраторам системы (тем, кто будет заниматься её поддержкой)

Требования к ПО

Требование к ПО (Software Requirements) = описание того, какие функции и с соблюдением каких условий должно выполнять приложение в процессе решения полезной для пользователя задачи.
Спецификации этих требований (Software Requirements Specification, SRS) детализируют требования к ПО до уровня, достаточного для разработки ПО для удовлетворения этих требований.

Синтаксис требования (Requirement Syntax)

[Обстоятельство] [Субъект] [Действие] [Объект] [Ограничение]
Например:

ИЛИ [Обстоятельство] [Действие или Ограничение] [Значение]
Например:

ИЛИ [Субъект] [Действие] [Значение]
Например:

Виды требований

• требования назначения (Operational Requirements) — относятся к назначению и целям создания системы. Совокупность этих требований должна описывать конечное состояние мира после того, как система будет развернута и начнет использоваться. Иногда их называют "требования к возможностям системы", "необходимые возможности".
  Требования, выведенные из потребностей стейкхолдеров после анализа потребностей.
• функциональные требования (Functional Requirements) — требования к системе или её элементам, определяющие их задачи или функции, которые должны выполняться.
  Требования, выведенные из сценариев использования, сценариев взаимодействия — user stories, use cases.
• к показателям функционирования (Performance Requirements) — описывают насколько хорошо система должна выполнять предъявленные к ней требования (минимальные числовые пороговые значения).
• к реализации (Design Constraints) — требуемые характеристики и атрибуты физического воплощения системы и ограничения на её конструкцию, внешний вид, общие свойства, вес, мощность, материал, ограничения на внешние интерфейсы.
• нефункциональные
  • к производительности
  • к масштабируемости и алгоритмической сложности
  • к потребляемым ресурсам
  • к входным и выходным данным
  • к платформе
  • к взаимодействию с внешним окружением
  • ограничения реализации и к процессу разработки
  • к безопасноти
  • к локализации
  • к надёжности и доступности
  • к развёртванию и обновляемости

• Спецификация бизнес-требований (Business Requirements Specification, BRS)
• Спецификация стейкхолдерских требований (Stakeholder Requirements Specification, StRS)
• Спецификация системных требований (System Requirements Specification, SyRS)
• Спецификация требований к ПО (Software Requirements Specification, SRS)

Спецификация требований к ПО (software requirements specification, SRS) = структурированный набор требований (функции, производительность, ограничения разработки, атрибуты) ПО и его интерфейсов (связей с внешними системами). Необходимы:

• Разработчикам
• Тестировщикам для верификации
• Администраторам Системы (тем, кто будет заниматься её поддержкой)

Спецификация требований к ПО обычно содержит:

• требования к внешним интерфейсам (external interfaces).
  Определяют все входы и выходы из программного обеспечения
• требования к функциям продукта (functions).
  Определяют все фундаментальные действия, имеющие место быть в программном продукте в приёме и обработке входящих потоков, в обработке и генерировании исходящих.
• требования к дизайну/юзабилити (usability).
  Определяют требования к юзабилити (качество в использовании) и целям программного системы, включая измеряемую эффективность и критерии удовлетворения контекстов использования.
• требования к производительности (performance).
  Определяют как статические, так и динамические числовые требования, предъявляемые к программному обеспечению или к взаимодействию человека с программным обеспечением в целом.
• требования к логической структуре БД (logical database).
  Задают логические требования для любой информации, которая должна быть помещена в базу данных.
• Ограничения проектирования/разработки (design constraints).
  Указывают ограничения на проектирование системы, налагаемые внешними стандартами, нормативными требованиями или ограничениями проекта.
• Соответствие стандартам (standard compilance).
  Указывают требования, вытекающие из существующих стандартов или правил.
• Атрибуты программного продукта, как то:
  • Надёжность
  • Доступность
  • Безопасность
  • Ремонтопригодность
  • Переносимость (кроссплатформенность)

Requirements traceability = трассируемость требований = прослеживаемость требований = отслеживаемость связей требований.

Например, установление сквозной связи Потребности клиента — Требования — Основные элементы Системы

набросок UML-диаграммы

скачать схему в формате diagrams.net (бывший draw.io)