# БИБЛИОТЕКА Курсы Redmine Системная инженерия Стейкхолдеры Управление Критическая цепь Linux Информация Социальные связи Саморазвитие Логика, интеллект Политэкономия Сумма технологии АНАЛИТИКА Ресурсы ПО для аналитики Бизнес-процесс Требования Уровни и типы Источники Нотации Архитектура РАЗРАБОТКА Ресурсы Цикл разработки ПО Continuous Integration OOP - базис Frontend HTTP/REST Apache web-server Регулярные выражения git Javascript Perl Полезности в Windows ТЕСТИРОВАНИЕ Книги и ссылки QA и QC Цикл тестирования 1 Тест-анализ 2 Тест план 3 Тест-дизайн и покрытие Уровни тестирования Виды тестирования Баг-репорт Шаблоны документов XPATH Безопасность Нагрузочное Android Автоматизация Selenium WebDriver Генератор ИНН БАЗЫ ДАННЫХ SQL MongoDB
Эта страница:
- Ссылки и документы - Записки - Основные понятия - Системное видение - Жизненный цикл системы - Практики (processes) - Требования - Спецификация требований - Спецификация требований к ПО - Трассировка
Ещё в этом разделе:
БИБЛИОТЕКА Системная инженерия Стейкхолдеры Управление Критическая цепь Linux Информация Саморазвитие Сознание, интеллект Социальные связи Политэкономия Сумма технологии
Другие разделы:
# АНАЛИТИКА MONGO DB SQL РАЗРАБОТКА БИБЛИОТЕКА ТЕСТИРОВАНИЕ
Системная инженерия
Ссылки и документы
Записки

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

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

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

Функциональные объекты существуют в тот момент, когда какие-то физические объекты играют их роль

За целостность функции отвечает Инженер по требованиям. Инженер по требованиям находит требования.

За целостность конструкции отвечает Архитектор. Архитектор думает как требования удовлетворить. Для этого Архитектор должен досконально знать свою предметную область.

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

Системная инженерия (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. Например, в системе водоснабжения может использоваться одна марка насоса, а может другая.
Это есть дуализм - система представляет из себя пару из Функции и Конструкции.

(скачать схему в XML)
Системное видение

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

(скачать схему в XML)

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

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

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

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

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

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

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

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

----------------->
System / Product
Целевая система / Продукт
Concept
Замысел
Development
Разработка
Production
Производство
Utilization
Функционирование
Support
Обслуживание
Retirement
Списание
Стадия Содержание стадии Примеры рабочих продуктов для бизнес-системы
Замысел Определение потребностей стейкхолдеров
Разработка реалистичной концепции системы. Как правило, включает в себя цели, требования назначения, функции верхнего уровня и концепцию архитектуры системы.
  • Бизнес-модель Остервальдера
  • Стратегическая карта 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). Работает с безличными группами людей.
  • умеет быть инженером - понимать архитектуру, разбираться в инженерных обоснованиях, читать чертежи.
Инженер по требованиям должен знать, откуда какие люди выпрыгнут и за какое место укусят проект.

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

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

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

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

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

TBD

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

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

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

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

TBD

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

Требования к ПО (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) - требуемые характеристики и атрибуты физического воплощения системы и ограничения на её конструкцию, внешний вид, общие свойства, вес, мощность, материал, ограничения на внешние интерфейсы.
  • нефункциональные
    • к производительности
    • к масштабируемости и алгоритмической сложности
    • к потребляемым ресурсам
    • к входным и выходным данным
    • к платформе
    • к взаимодействию с внешним окружением
    • ограничения реализации и к процессу разработки
    • к безопасноти
    • к локализации
    • к надёжности и доступности
    • к развёртванию и обновляемости

TBD

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

TBD

Спецификация требований к ПО

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

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

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

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

TBD

Трассировка

Цель-Требования-Спецификации-Компоненты

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

Тест-кейсы можно увязать к Компонентам ПО, как объектам самого низкого уровня Системы - архитектурного слоя Software. Ниже только физический.