# Процессы Ресурсы Цикл разработки ПО Waterfall RUP Agile Kanban Управление Архитектура Ресурсы ПО для Архитектора Кто архитекторы? Архитектурные слои язык Archimate GAP-анализ SOA Типы интеграции Vision (Концепция) Проектное решение ESB Микросервисы и service mesh HTTP/REST RPC DDD Анализ Ресурсы ПО для Аналитика Кто аналитики? Бизнес-процесс Требования Уровни и типы Источники Стейкхолдеры Нотации Сервисы DevOps CI/CD/CDP VM и Docker Контракты API Оценка задачи git Frontend Apache Регулярка Linux Тестирование Ресурсы QA и QC Цикл тестирования Уровни тестирования Виды тестирования Баг-репорт Тестирование требований Тест-анализ и тест дизайн Интеграционное, API, E2E Тест план Метрики качества Автотесты Selenium XPATH Нагрузочное Данные Ресурсы MDM Big data Об информации SQL intro MongoDB intro Библиотека Системная инженерия Станислав Лем Экстраполяция в будущее Политэкономия Сознание, интеллект

/ АНАЛИЗ АРХИТЕКТУРА ДАННЫЕ DevOps Gaming Библиотека: + Библиотека - Системная инженерия | Ссылки и документы | Заметки с лекций | Основные понятия | Системное видение | Системно-инженерные роли | Жизненный цикл системы | Практики (processes) | Требования | Спецификация требований | Спецификация требований к ПО | Трассировка + Сознание, разум + Политэкономия + Станислав Лем + Экстраполяция + Диаграммы + Арт ПРОЦЕССЫ ТЕСТИРОВАНИЕ
Системная инженерия
latest update of the page: 03-02-2024, 19:07 UTC
Все балаганы с картинками и фасилитаторами заканчиваются в тот момент, когда насладившийся картинками и фасилитированным общением начальник уходит, и оставшимся инженерам надо, наконец, заняться настоящим мышлением, то есть выдать на-гора реально сложный работающий продукт.
Красивый и захватывающий процесс легко подменяет результат.
Конечно, инженеры, которых учили думать, работают не так, как об этом рассказывают опирающиеся на картинки люди из движения design-thinking.
© Анатолий Левенчук.
Ссылки и документы

Разное

Книги

Стандарты

  • (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
За ISO пришлось раскошелиться. Разрабатывать и затем продавать мировые стандарты это высший пилотаж цинизма. Мы, человеки, так долго будем идти к колонизации дальнего космоса...
Заметки с лекций

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

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

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

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

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

Основные понятия

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

Основные понятия:
  • система (system) — совокупность (комбинация) взаимодействующих элементов, организованных для достижения одной или нескольких поставленных целей.
    • Целевая система (system of interest)
    • Обеспечивающая система (enabling system). Это та система, которая берёт Целевую систему за шкирку и тащит её по жизненному циклу (lifecycle).
    • Система в операционном (эксплуатационном) окружении (system in operational environment) — системы, которые непосредственно связаны с целевой системой, с выполнением ею своей функции
  • интерес (concern) в значении "забота"
  • стейкхолдер (stakeholder)
соответствуют основным понятиям, введённым международным стандартом процессов жизненного цикла ISO/IEC 15288:2008 Systems and software engineering — System life cycle processes. источник изображения — книга Анатолия Левенчука "Системное мышление".

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

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

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

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

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

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

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

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

Первая группа законов развития технических системстатика — относится к критериям жизнеспособности новых технических систем.
Необходимыми условиями принципиальной жизнеспособности технической (как и биологической!) системы являются:

  1. наличие и хотя бы минимальная работоспособность её основных частей;
  2. сквозной проход энергии через систему к её рабочему органу;
  3. согласование собственных частот колебаний (или периодичности действия) всех частей системы.

Вторая группа законов развития технических системкинематика характеризует направление развития независимо от конкретных технических и физических механизмов этого развития.
Все технические системы развиваются:

  1. в направлении увеличения степени идеальности;
  2. в направлении увеличения степени динамичности;
  3. неравномерно — через возникновение и преодоление технических противоречий, причем чем сложнее система, тем неравномернее и противоречивее развитие её частей;
  4. до определенного предела, за которым система включается в надсистему в качестве одной из её частей; при этом развитие на уровне системы резко замедляется или совсем прекращается, заменяясь развитием на уровне надсистемы.

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

Системно-инженерные роли

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

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

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

Жизненный цикл системы

Стадия Содержание стадии Примеры рабочих продуктов для бизнес-системы
Замысел Определение потребностей стейкхолдеров
Разработка реалистичной концепции системы.
Как правило, включает в себя цели, требования назначения, функции верхнего уровня и концепцию архитектуры системы.
  • Бизнес-модель Остервальдера
  • Стратегическая карта BSC
  • Функции верхнего уровня в формате IDEF0
Разработка Разработка детального проекта системы
  • Модель функции IDEF0
  • Модель процессов (CFFC, BPMN, EPC)
  • Модель организационной структуры
  • Требования к персоналу
  • Модели оборудования и IT-систем
Производство Изготовление или приобретение компонентов системы, сборка их в единую систему
  • Помещение
  • Нанятый персонал
  • Оборудование
  • IT-системы
Функционирование Работа системы в соответствии со своим предназначением
Обслуживание Временный вывод из эксплуатации системы или её части, замена компонентов или профилактическое обслуживание, ввод в эксплуатацию
  • Заменённый сотрудник
  • Заменённый сервер
Списание Вывод из эксплуатации, разборка, уничтожение или повторное использование компонентов
  • Уволенный персонал
  • Проданные или переданные на хранение активы

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

источник изображения — книга Анатолия Левенчука "Системное мышление".

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

источник изображения — книга Анатолия Левенчука "Системное мышление".

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

Водопад:

Спираль:

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

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

Так называемая "горбатая диаграмма" (hump diagram):
Практики (processes)

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

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

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

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

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

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

Предприятия
(enterprise processes)
Проекта
(project enabling processes)
Технические
(techincal processes)
Контрактации (соглашения):
  1. закупки
  2. поставки
  1. управление моделью жизненного цикла
    (life cycle model management)
  2. управление инфраструктурой предприятия
    (infrastructure management)
  3. управление портфелем проектов / программой
    (project portfolio management)
  4. управление ресурсами (персоналом)
    (human resource management)
  5. управление качеством
    (quality management)
    Управление проектами:
  1. планирование проекта
    (project planning)
  2. оценки и контроля проекта
    (project assessment and control)

  3. Поддержка проектов:
  4. управление принятием решений
    (decision management)
  5. управление рисками
    (risk management)
  6. управление конфигурацией
    (configuration management)
  7. управление информацией
    (information management)
  8. измерение
    (measurement)
  1. определение требований
    (stakeholder requirements definition)
  2. анализ требований
    (requirements analysis)
  3. проектирование архитектуры
    (architectural design)
  4. реализация (изготовление) элементов
    (implementation, production)
  5. комплексирование (сборка)
    (integration)
  6. проверка функциональности
    (functional verification)
  7. передача в эксплуатацию
    (transition)
  8. приёмка требований
    (requirements validation)
  9. функционирование / эксплуатация
    (operation)
  10. обслуживание
    (maintenance)
  11. изъятие и списание / вывод из эксплуатации
    (disposal)
== Обеспечивают ==>

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

Требования
Ресурсы:

Требование (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)

В ISO 29148 предлагается следующий:

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

Когда сигнал X получен [Обстоятельство], система [Субъект] должна установить [Действие] разряд сигнала [Объект] в течение 2-х секунд [Ограничение].

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

В состоянии 1 [Обстоятельство] радарная система должна обнаруживать цели в радиусе [Действие или Ограничение] 100 километров [Значение].

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

Учетная система [Субъект] должна отображать неоплаченные счета [Действие] в порядке возрастания [Значение] в котором счета должны быть оплачены.

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

  • требования назначения (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 = трассируемость требований = прослеживаемость требований = отслеживаемость связей требований.

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

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

определяет, основание для -->
Цель, нужда, интерес Требования
и их Спецификации
Спецификация требований к ПО (SRS) Компоненты ПО
  • увеличение дохода:
    • привлечение новых Клиентов
    • сокращение потерь потенциальных Клиентов
    • увеличение количества Продуктов/Услуг
    • улучшение качества Продуктов/Услуг
    • ...
  • сокращение издержек:
    • оптимизация бизнес-процессов по продаже Продуктов
    • оптимизация бизнес-процессов предоставления Услуг
    • ...
  • ...
  • Бизнес-требования (BR)
    и Спецификация (BRS)
  • Стейкхолдерские требования (StR)
    и Спецификация (StRS)
  • Пользовательские требования (UR)
  • Системные требования (SR)
    и Спецификация (SyRS)
  • Ограничения (Constraints)
    • интерфейсы связанных систем
    • законы
    • доступный бюджет, сроки
    • используемая технологическая платформа
    • возможности пользователя/оператора
    • ...
  • ...
  • интерфейсы
  • функции
  • дизайн/юзабилити
  • производительность
  • логическая структура БД
  • соответствие стандартам
  • надёжность
  • доступность
  • безопасность
  • ремонтопригодность
  • кроссплатформенность
  • Ограничения проектирования/разработки:
    • интерфейсы связанных систем
    • используемая программная платформа, фреймворк, ЯП
  • Данные (сущности), хранящиеся в:
    • БД
    • файлах
    • оперативной памяти
  • Формы GUI
    • веб-страницы
    • окна desktop-приложения
    • ...
  • Событийные процедуры для форм GUI
  • Вспомогательные
    • триггеры
    • постобработки
    • хранимые процедуры
    • workflow-компоненты
    • ...
  • Интерфейсы
    • веб-сервисы
    • ...
  • Периодические задания
    • JOBы в БД
      • SSIS-пакет
      • вызовы пакетов в ORACLE
      • ...
    • *nix — crontable
    • Windows — планировщик заданий
    • ...
  • отчёты
  • подсистема управления правами