Объектно-ориентированные Case-технологии.требования

Ключевые вопросы программной инженерии
Охватывает 10 областей знаний SWEBOK:
Software requirements – программные требования
Software design – дизайн (архитектура)
Software construction – конструирование программного обеспечения
Software testing – тестирование
Software maintenance – эксплуатация (поддержка) программного обеспечения
Software configuration management – конфигурационное управление
Software engineering management – управление в программной инженерии
Software engineering process – процессы программной инженерии
Software engineering tools and methods – инструменты и методы
Software quality – качество программного обеспечения
3

Ключевые вопросы программной
инженерии
4

Дисциплина Требования
(Software Requirements)
5

Стоимость внесения изменений в разрабатываемое ПО в зависимости от фазы ЖЦ
http://cmcons.com/articles/upravlenie_trebovanijami_instrument_ibm_rational_r/rol_protsessa_upravlenija_trebovanijami_pri_razrabotke_slozhnykh_programmnykh_sistem_praktika_primenenija_metodologii_ibm_rup_i_instrumenta_ibm_rational_requisitepro/
Дисциплина Требования
6

Вспомним определения объекта к которому предъявляются требования:
информационно-вычислительная система (программно-технический комплекс): совокупность данных (баз данных) и программ, функционирующих на вычислительных средствах как единое целое для решения определенных задач [ГОСТ Р 53622-2009].
программный продукт (software product): набор компьютерных программ, процедур и возможно связанной документации и данных. [ИСО/МЭК 90003:2004. Техника программного обеспечения. Рекомендации по применению ИСО 9001:2000 к компьютерному программному обеспечению, стадия пересмотра 90.20]
7
Дисциплина Требования

Дисциплина Требования
8

Откуда берутся ошибки в требованиях:
Требования связаны между собой и с другими артефактами проекта – их нельзя анализировать по одному, а приходится анализировать сразу группу взаимосвязанных требований.
Требования часто относятся к нескольким функциональным областям сразу – их трудно группировать.
Требования разнообразны по значимости (обязательность, риск, важность, стабильность); традиционная группировка по функциям оказывается неоднозначной.
Трудно отслеживать влияние изменившихся требований на другие.
Требования изменяются в процессе жизненного цикла создания ПО.
Снизить трудоемкость процесса и повысить качество управления требованиями позволяют ПП (IBM Rational RequisitePro).
Управление требованиями
9

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

Вспомним, что мы:
разработчик (developer): Организация, которая выполняет разработку задач (в том числе анализ требований, проектирование, приемочные испытания) в процессе жизненного цикла [ГОСТ ISO 9000-2011].
Работаем в рамках:
проект (project): Попытка действий с определенными начальными и конечными сроками, предпринимаемая для создания продукта или услуги в соответствии с заданными ресурсами и требованиями [ГОСТ Р ИСО/МЭК 12207-2010].
проект (project): Уникальный процесс, состоящий из совокупности скоординированных и управляемых видов деятельности с начальной и конечной датами, предпринятый для достижения цели, соответствующей конкретным требованиям, включающий ограничения по срокам, стоимости и ресурсам [ГОСТ ISO 9000-2011].
11

Проект организован согласно ЖЦ:
жизненный цикл (life cycle): Развитие системы, продукта, услуги, проекта или других изготовленных человеком объектов, начиная со стадии разработки концепции и заканчивая прекращением применения [ГОСТ ISO 9000-2011].
модель жизненного цикла (life cycle model): Структура процессов и действий, связанных с жизненным циклом, организуемых в стадии, которые также служат в качестве общей ссылки для установления связей и взаимопонимания сторон [ГОСТ ISO 9000-2011].
12

Виды требований и их определение
(Definition of a Software Requirement)
Стандарт ISO дает наиболее общее и полное определение:
требование: установленная или типично предполагаемая потребность или ожидание [ГОСТ ISO 9000-2011Системы менеджмента качества. Основные положения и словарь].
определенное требование: Установленная потребность или ожидание [ГОСТ ISO 9000-2011].
IEEE Standard Glossary of Software Engineering Terminology (1990) определяет требования как:
1. условия или возможности, необходимые пользователю для решения проблем или достижения целей;
2. условия или возможности, которыми должна обладать система или системные компоненты, чтобы выполнить контракт или удовлетворять стандартам, спецификациям или другим формальным документам
3. документированное представление условий или возможностей для п. 1 и 2
13

требования могут выражаться в форме потребностей, пожеланий, требований, ожиданий и воспринятых ограничений отдельных правообладателей, которые, в свою очередь, выражаются в терминах модели (текстовой или формализованной), ориентированной на цели и поведение системы и описывающей ее в контексте среды и условий функционирования [ГОСТ Р ИСО/МЭК 12207-2010].
проектирование: процесс, который преобразовывает требования в набор характеристик продукта [ГОСТ Р ИСО/МЭК 12207-2010].
14
Виды требований и их определение

15
Виды требований и их определение

16
Виды требований и их определение

Требования к продукту охватывают требования как пользователей (внешнее поведение системы), так и разработчиков (некоторые скрытые параметры). Термин пользователи относится ко всем заинтересованным лицам в создании системы.
Требования к продукту и процессу (Product and Process Requirements) – проводится разграничение соответствующих требований как свойств продукта, который необходимо получить, и процесса, с помощью которого продукт будет создаваться.
Например, ряд требований может быть заложен неявно и программные требования могут порождать требования к процессу, например: выбор платформы J2EE (Java 2 Enterprise Edition) и ее реализации в виде конкретного сервера приложений практически наверняка потребует применения модульного тестирования (Unit testing) как практики процесса разработки и JUnit, как инструмента реализации этой практики.
17
Виды требований и их определение

Чаще всего, для описания комплексных проектов (в части требований) используется три основных документа (спецификации):
определение системы (system definition);
системные требования (system requirements)
программные требования (software requirements).
Системные требования и программные требования (System Requirements and Software Requirements) следует различать, основываясь на определении информационной системы:
18
информационная система – это «комбинация взаимодействующих элементов, созданная для достижения определенных целей; может включать аппаратные средства, программное обеспечение, встроенное ПО, другие средства, людей, информацию, техники (подходы), службы и другие поддерживающие элементы.
Таким образом, подразумевается, что информационная система является более ёмким понятием, чем программное обеспечения и включает окружение, в котором функционирует ПО, как таковое; отсюда, естественным образом, вытекают требования к системе в целом и программному обеспечению (или программной системе), в частности.
Виды требований и их определение

19
1 уровень:
1. Системные требования (System Requirements) – иногда классифицируются как составная часть группы функциональных требований.
Описывают высокоуровневые требования к ПО, содержащему несколько или много взаимосвязанных подсистем и приложений. При этом, система может быть как целиком программной, так и состоять из программной и аппаратной частей.
В общем случае, частью системы может быть так же персонал, выполняющий определенные функции системы
2 уровень:
2. Программные требования (Software Requirements) – это «свойства программного обеспечения, которые должны быть надлежащим образом представлены в нём для решения конкретных практических задач».
Виды требований и их определение

3 уровень:
1. Группа функциональных требований состоит из следующих видов:
потребности (needs) – отражают проблемы бизнеса, персоналии или процесса, которые должны быть соотнесены с использованием или приобретением системы;
бизнес требования (business requirements) – определяют высокоуровневые цели организации или клиента (потребителя) – заказчика разрабатываемой ПС. Бизнес требования формулируют в документе об образе и границах проекта — уставе проекта (project charter), или документом рыночных требований (market requirements document). Определение границ проекта представляет собой первый этап управление общими проблемами расползания границ.
пользовательские требования (user requirements) – описывают цели/задачи пользователей системы, которые должны достигаться/выполняться пользователями при помощи создаваемой ПС. Эти требования часто представляют в виде вариантов использования (Use Cases);
функциональные требования (Functional Requirements) – определяют функциональность (поведение) системы, которая должна быть создана разработчиками для предоставления возможности выполнения пользователями своих обязанностей в рамках бизнес-требований и в контексте пользовательских требований.
20

3 уровень:
2. Группа нефункциональных требований (non-functional requirements) включает в себя:
бизнес-правила (business rules) – включают или связаны с корпоративными регламентами, политиками, стандартами, законодательными актами, внутрикорпоративными инициативами (например, стремление достичь зрелости процессов по CMMI 4-го уровня), учетными практиками, алгоритмами вычислений и т.д. Бизнес правила не являются требованиями к ПО, потому что они находятся снаружи границ любой системы ПО. Иногда бизнес-правила становятся источником атрибутов качества, которые реализуются в функциональности.
Business Rules Group дает понимание бизнес-правила, как «положения, которые определяют или ограничивают некоторые аспекты бизнеса. Они подразумевают организацию структуры бизнеса, контролируют или влияют на поведение бизнеса».
Бизнес правила определяют распределение ответственности в системе, отвечая на вопрос «кто будет осуществлять конкретный вариант, сценарий использования» или диктуют появление некоторых функциональных требований. В контексте дисциплины управления проектами такие правила обладают высокой значимостью и, именно они, часто определяют ограничения проектов, для автоматизации которых создается соответствующая ПС;
21

внешние интерфейсы (external interfaces) – конкретизация аспектов взаимодействия с другими системами, операционной средой (например, запись в журнал событий операционной системы), возможности мониторинга при эксплуатации – все это не столько функциональные требования к которым ошибочно приписывают иногда такие характеристики, сколько вопросы интерфейсов;
атрибуты качества (quality attributes) – описывают дополнительные характеристики продукта в различных «измерениях», важных для пользователей и/или разработчиков. Атрибуты касаются например вопросов портируемости, интероперабельности (прозрачности взаимодействия с другими системами), целостности или устойчивости;
ограничения (constraints) – формулировки условий, модифицирующих требования или наборы требований, сужая выбор возможных решений по их реализации. В частности, к ним могут относиться параметры производительности, влияющие на выбор платформы реализации и/или развертывания (протоколы, серверы приложений, баз данных) которые, в свою очередь, могут относиться, например, к внешним интерфейсам.
22
Виды требований и их определение

Классификация требований (Requirements Classification)
Уровни требований по Вигерсу
23
Виды требований и их определение

Дополнительно требования следует определить как:
квалификационное требование (qualification requirement): Совокупность критериев или условий, которые должны быть удовлетворены для того, чтобы квалифицировать программный продукт как соответствующий спецификациям и готовый для применения в заданном окружении или интеграции с системой, для которой он предназначен [ГОСТ Р ИСО/МЭК 12207-2010];
квалификация (qualification): Процесс демонстрации, определяющий, способен ли какой-либо объект полностью удовлетворять заданным требованиям [ГОСТ Р ИСО/МЭК 12207-2010];
гарантия качества (quality assurance): Все запланированные и систематические действия, выполняемые в рамках системы качества и продемонстрированные надлежащим образом для обеспечения соответствующей уверенности в том, что объект полностью удовлетворяет требованиям к качеству [ГОСТ Р ИСО/МЭК 12207-2010].
24
Виды требований и их определение

Цель процесса определения требований правообладателей состоит в выявлении требований к системе, выполнение которых может обеспечить функциональные возможности, необходимые пользователям системы и иным заинтересованным лицам в заданной эксплуатационной среде [ИСО/МЭК 15288:2007] .
Разработка требований – процесс выявления, формулирования, анализа, документирования и верификации требований, подлежащих выполнению в продукте [ИСО/МЭК 15288:2007].
В ходе разработки требований системный аналитик формирует реестр требований, который ложится в документ или автоматизированную систему управления требованиями.
Процессы работы с требованиями
(Requirements Process)
23

Процессы работы с требованиями
Начальным этапом разработки ПО ИС является технический процесс определения требований правообладателей цель которого состоит в выявлении требований к системе, выполнение которых может обеспечивать предоставление услуг, необходимых пользователям и другим правообладателям в заданной среде применения [ГОСТ Р ИСО/МЭК 12207-2010].
Результаты процесса определения требований правообладателей:
требуемые характеристики и условия использования услуг;
ограничения для системных решений;
возможность прослеживания от требований правообладателей к правообладателям и их потребностям; основа для определения системных требований;
основа для валидации соответствия услуг;
основа для ведения переговоров и заключения соглашений о поставке услуги или продукции [ГОСТ Р ИСО/МЭК 12207-2010].
26

Процессы работы с требованиями
Цель анализа системных требований состоит в преобразовании определенных требований правообладателей в совокупность необходимых системных технических требований, которыми будут руководствоваться в проекте системы [ГОСТ Р ИСО/МЭК 12207-2010].
Результаты процесса анализа системных требований:
устанавливается определенная совокупность системных функциональных и нефункциональных требований, описывающих проблему, подлежащую решению;
выполняются соответствующие технические приемы оптимизации предпочитаемого проектного решения;
системные требования анализируются на корректность и тестируемость;
осмысливается воздействие системных требований на среду применения;
требования расставляются по приоритетам, утверждаются и обновляются;
устанавливается согласованность и прослеживаемость между системными требованиями и базовой линией требований заказчика;
оцениваются изменения базовой линии по стоимости, графикам работ и воздействию технических решений;
системные требования доводятся до сведения всех участвующих сторон и включаются в базовую линию.
27

На начальном этапе можно считать, что:
требование (requirement): потребность или ожидание, которое установлено, обычно предполагается или является обязательным [ГОСТ ISO 9000-2011], а также:
требование (requirement): документально изложенный критерий, который должен быть выполнен, если требуется соответствие документу, и по которому не разрешены отклонения [ГОСТ ISO 9000-2011].
И следует помнить, что:
качество (quality): степень соответствия совокупности присущих характеристик требованиям [ГОСТ ISO 9000-2011].
Процессы работы с требованиями
28

Определимся, что:
заинтересованная сторона (interested party): лицо или группа лиц, заинтересованных в деятельности или успехе организации [ГОСТ ISO 9000-2011].
правообладатель (stakeholder): лицо или организация, имеющие право, долю, требование или интерес в системе или в обладании ее характеристиками, удовлетворяющими ее потребности и ожидания [ГОСТ Р ИСО 12207-2010].
анализ (review): деятельность, предпринимаемая для установления пригодности, адекватности и результативности рассматриваемого объекта для достижения установленных целей [ГОСТ ISO 9000-2011].
проектирование и разработка (design and development): совокупность процессов, переводящих требования в установленные характеристики или спецификации на продукцию, процесс или систему [ГОСТ ISO 9000-2011].
Процессы работы с требованиями
29

Документирование требований (Requirements Elicitation) в соответствии с:
спецификация (specification): документ , устанавливающий требования [ГОСТ ISO 9000-2011].
конструкторский документ: документ, описывающий состав, структуру, алгоритмы обработки данных и методы их реализации, правила функционирования и применения информационно-вычислительной системы и ее составных частей, предназначенный для разработчика на всех стадиях жизненного цикла [ГОСТ Р 53622-2009].
задание на выполнение работы (statement of work): документ, используемый приобретающей стороной как средство для описания и конкретизации задач, которые должны быть выполнены по условиям контракта [ГОСТ 12207-2010].
техническое задание: Организационно-распорядительный документ, содержащий технические требования к информационно-вычислительной системе и порядку ее создания [ГОСТ Р 53622-2009].
Процессы работы с требованиями
30

Документирование требований (Requirements Elicitation) в соответствии со спецификацией требований (Requirements Specification):
Определение системы (System Definition Document)
Спецификация системных требований (System Requirements Specification)
Спецификация программных требований (Software Requirements Specification - SRS)
Процессы работы с требованиями
31

Главная парадигма:
ориентация на потребителя: Организации зависят от своих потребителей, и поэтому должны понимать их текущие и будущие потребности, выполнять их требования и стремиться превзойти их ожидания [ГОСТ ISO 9000-2011 Системы менеджмента качества. Основные положения и словарь].
удовлетворенность потребителей (customer satisfaction): Восприятие потребителями степени выполнения их требований [ГОСТ ISO 9000-2011].
Извлечение требований
(Requirements Elicitation)
32

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

Пирамида Требований
В зависимости от формата, источника и общих характеристик, требования могут быть разделены на различные типы.
Несколько типов требований, наиболее часто использующихся в проектах:
Потребность заинтересованного лица: требование от заинтересованного лица.
Функциональная особенность: предоставляемая системой функциональность, обычно формулируемая бизнес-аналитиком; назначение особенности – удовлетворить потребности заказчика.
Сценарий (использования (Use Case)): описание поведения системы в терминах последовательности действий.
Дополнительное требование: другое требование, обычно нефункциональное, которое не может быть охвачено сценариями использования.
Тестовые сценарии (Test Cases): спецификация тестовых исходных данных, условий выполнения и ожидаемых результатов.
Сценарий (Scenario): особая последовательность действий – алгоритм, «определенный путь» реализации сценария использования.
Адаптация методики IEEE 830-1998
34

Пирамида Требований
35

Потребности заинтересованного лица (Регистратура) – требование от заинтересованного лица:
запись на прием;
обслуживание пациентов в ЛПУ;
ведение нормативно-справочной информации в регистратурах ЛПУ;
планирование работы кабинетов и врачей;
поиск и регистрация пациентов;
закрепление пациента за участком;
подготовка выходных отчетных форм.
Пирамида Требований
Потребности заинтересованного лица (ЛПУ) – требование от заинтересованного лица:
создание, редактирование и прочие виды обработки информации;
регистрацию и ведение учета записи пациентов на прием;
выработку оптимальных технологических маршрутных схем движения документов;
организацию хранения информации;
обмен информацией между подразделениями ЛПУ;
формирование отчетов.
36

Пирамида Требований
Функциональная особенность – предоставляемая системой функциональность (Регистратура):
Для «Ведение нормативно-справочной информации в регистратурах ЛПУ» :
ведение справочника врачей (медицинского персонала ЛПУ);
календарное планирование расписание работы врачей ЛПУ (с возможностью создания резервных зон);
оперативное планирование расписание работы врачей ЛПУ;
кабинеты ЛПУ.
Для «Закрепление пациента за участком»:
Закрепление пациента за участком должно осуществляться в двух режимах:
а) в автоматическом - участок пациента определяется автоматически по адресу проживания;
б) в ручном - регистратор имеет возможность закрепить пациента за любым участком, выбрав его из справочника.
37

Пирамида Требований
38

Сценарий реализации для Предоставления доступа пользователя (пациента) к подсистеме записи на прием к врачу в случае успешной авторизации на web-сайте:
после подтверждения пользователем введенных данных автоматически выполняется запрос в БД ФОМС на проверку полиса ОМС по параметрам «серия, номер, срок действия полиса ОМС + ФИО», ответ на запрос поступает в режиме реального времени;
если проверка полиса ОМС не пройдена, пользователь получает сообщение электронной почты о невозможности записи на прием с указанием причины отказа и предложением посещения регистратуры ЛПУ с документами, удостоверяющими личность пациента.
Дополнительные требования для Регистрации пациентов:
Список льготных категорий формируется в рамках ПК «Льготные рецепты» при загрузке реестра льготников и может отображаться в составе социально-паспортных данных пациента. Должна быть предусмотрена возможность ручного ввода льготной категории.
Пирамида Требований
39

Пирамида Требований
Адаптация методики IEEE 830-1998
40

Пирамида Требований
Примечание: На верхнем уровне располагаются потребности заинтересованного лица.
На последующих уровнях находятся функциональные особенности, сценарии использования и дополнительные требования.
Достаточно часто на разных уровнях этих требований могут быть выяснены детали различного уровня.
Чем ниже уровень, тем более детально описывается требование. Например, потребность может быть следующей: «Данные должны быть неизменными».
Функциональная особенность этого требования будет: «Система должна использовать реляционную базу данных».
На уровне дополнительных требований, требование еще более точное: «Система должна использовать базу данных Oracle».
Чем дальше вниз, тем более детальным становится требование.
Один из лучших способов управления требованиями – обобщать требования, по крайней мере, на двух различных уровнях.
Например, документ Концепция («Vision») содержит высокоуровневые требования (особенности), а низшие уровни пирамиды представляют требования на более детальном уровне.
41

Анализ требований (Requirements Analysis).
Характеристики «хорошего» Требования
Корректность [IEEE 830-1998], правдоподобность (реальность, выполнимость);
Однозначность [IEEE 830-1998], недвусмысленность;
Полнота, завершенность [IEEE 830-1998];
Непротиворечивость [IEEE 830-1998];
Упорядочивание по значимости и/или устойчивости (необходимость и устойчивость) [IEEE 830-1998];
Проверяемость (тестируемость) [IEEE 830-1998];
Модифицируемость [IEEE 830-1998];
Отслеживаемость [IEEE 830-1998];
В дополнение к методике:
Понятность;
Независимость;
Элементарность;
Независимость от реализации (абстрактность).
Адаптация методики IEEE 830-1998
42

Корректность - каждое требование является требованием, которому должно удовлетворять программное обеспечение [IEEE 830-1998].
Если требование содержит факты, эти факты должны быть достоверны.
Треб. для подготовки выходных отчетных форм:
а) амбулаторная карта должна быть в соответствии с установленной учетной формой № 25/у-04;
б) контрольная карта диспансерного больного по диагнозам учета должна быть в соответствии с установленной учетной формой № 30/у -04;
в) талон амбулаторного пациента должен быть в соответствии с установленной учетной формой № 025-12/у.
Характеристики «хорошего» Требования
Адаптация методики IEEE 830-1998
43

Однозначноcть – если и только, если каждое изложенное требование может интерпретироваться только однозначно. Как минимум, для этого требуется, чтобы каждая характеристика конечного продукта была описана с использованием одного уникального термина [IEEE 830-1998].
Недвусмысленность – должен существовать только один путь интерпретации требования.
В тех случаях, когда термин, используемый в специфическом контексте, может иметь множественные значения, этот термин должен быть включен в глоссарий, в котором его значение описывается более конкретно.
Примечание* «Ловушки» естественного языка: Требования часто пишутся на естественном языке. Естественный язык по существу является неоднозначным. Естественный язык SRS должен анализироваться независимой стороной с целью идентификации неоднозначного использование так, чтобы эту неоднозначность можно было скорректировать.
Характеристики «хорошего» Требования
Адаптация методики IEEE 830-1998
44

Характеристики «хорошего» Требования
Адаптация методики IEEE 830-1998
Треб.1: Система не должна принимать пароли более 15-ти символов.
Не совсем ясно, что система должна делать.
Система не должна позволять пользователю вводить более чем 15 символов.
Система должна отсекать введенную строку до 15-ти символов.
Система не должна отображать сообщение об ошибке, если пользователь вводит более чем 15 символов.
Исправленное требование содержит пояснение:
Треб.1: Система не должна принимать пароли более 15-ти символов. Если пользователь вводит более 15-ти символов при выборе пароля, сообщение об ошибке должно информировать пользователя о необходимом исправлении пароля.
45

Характеристики «хорошего» Требования
Адаптация методики IEEE 830-1998
Однозначность: ясность (Краткость, Сжатость, Простота, Точность)
Требования не должны содержать ненужных выражений или информации. Они должны быть изложены кратко и просто:
Треб.1: Иногда пользователь будет вводить Специальность врача которую система будет распознавать.
Это предложение может быть заменено на более простое:
Треб.1: Система должна идентифицировать Специальность врача.
46

47
Завершенность, полнота – если и только, если определены все следующие элементы:
а) Все существенные требования, независимо от того, относятся ли они к функциональным возможностям, рабочим характеристикам, проектным ограничениям, атрибутам или внешним интерфейсам. В частности, должны быть подтверждены и обработаны любые внешние требования, налагаемые спецификацией системы.
б)Определение откликов ПО на все классы входных данных, которые могут быть реализованы, во всех возможных ситуациях. Следует заметить, что важно определить отклики, как на допустимые, так и недопустимые входные значения.
в)Полные обозначения и ссылки на все рисунки, таблицы и схемы в SRS и определение всех терминов и единиц измерения [IEEE 830-1998].
Примечание* Условия TBD – «должно быть определено»:
Требования к характеристикам взаимосвязей со смежными системами:
Треб. Должно обеспечиваться взаимодействие АИС с внешними системами в рамках:
а) получения:
1) данных о полисах ОМС пациентов в БД ФОМС;
2) данных о льготах пациентов в БД Управления социальной защиты.
б) передачи в БД ЛПУ информации о реестре талонов пациентов.
Смежные системы:
а) ФОМС (БД);
б) Управление социальной защиты (БД).
Характеристики «хорошего» Требования
Адаптация методики IEEE 830-1998

Непротиворечивость: внутренняя непротиворечивость и внешняя
Характеристики «хорошего» Требования
Адаптация методики IEEE 830-1998
48
Закрепление пациента за участком должно осуществляться в двух режимах:
а) в автоматическом - участок пациента определяется автоматически по адресу проживания;
б) в ручном - регистратор имеет возможность закрепить пациента за любым участком, выбрав его из справочника.

Упорядочивание по значимости и/или устойчивости
Характеристики «хорошего» Требования
Адаптация методики IEEE 830-1998
Каждое требование в SRS должно быть идентифицировано, чтобы сделать эти различия четкими и явными. Идентификация требований следующим образом помогает:
а) заказчикам более тщательно рассмотреть каждое требование, что часто позволяет разъяснить любые скрытые допущения, которые могут быть заключены в них.
б) разработчикам принять правильные проектные решения и приложить соответствующие усилия к различным составляющим программного изделия.
49

Степень устойчивости
Характеристики «хорошего» Требования
Адаптация методики IEEE 830-1998
Один метод идентификации требований использует величину устойчивости. Устойчивость может быть выражена с точки зрения числа ожидаемых изменений для любого требования, основанных на опыте или знании предстоящих событий, которые влияют на организацию, функции, и пользователей, поддерживаемых системой программного обеспечения.
Степень необходимости
Другой способ упорядочения требований состоит в том, чтобы различать классы требований как необходимые, условные и необязательные.
а) Необходимые. Подразумевают, что программное обеспечение не будет пригодным, если эти требования не будут обеспечены согласованным образом.
б) Условные. Подразумевают, что эти требования расширяют программное изделие, но не сделают его непригодным при их отсутствии.
в) Необязательные. Подразумевают класс функций, которые могут заслуживать или не заслуживать внимания. Это дает поставщику возможность предложить что-либо, что выходит за пределы SRS.
50

Тестируемость (Возможность Проверки)
Тестеры должны иметь возможность проверить, было ли требование реализовано корректно.
Использование некоторых слов может сделать требование невозможным для тестирования:
Некоторые прилагательные: устойчивый, безопасный, точный, эффективный, целесообразный, гибкий, настраиваемый, надежный, дружелюбный, адекватный.
Некоторые наречия и фразы с ними: быстро, безопасно, своевременно.
Неспецифичные слова или акронимы: и т.д., и/или, TBD (to be determined).
Треб.1: Функция поиска должна позволять пользователю искать врача на основе Фамилии, Имени, Специальности, и т.д.
В этом требовании все критерии поиска должны быть детально перечислены. Дизайнер и разработчик не могут догадаться, что пользователь имел в виду под сокращением «и т.д.».
Треб.1: Система должна препятствовать одновременному доступу большого числа пользователей.
Какое количество здесь имеется в виду под «большим числом» - 10, 100 или 1000?
Характеристики «хорошего» Требования
51

Понятность
Требования должны быть грамматически правильные, написаны в соответствующем стиле. Должны быть использованы стандартные соглашения. Слово «должен» должно быть использовано вместо «будет», «обязан» или «может».
Правдоподобность (Реальность, Выполнимость)
Требование должно быть выполнимо в рамках существующих ограничений, таких как время, деньги и доступные ресурсы.
Характеристики «хорошего» Требования
52

Независимость
Чтобы понять требование, не нужно знать какое-либо другое требование.
Треб.1: Список доступных специалистов должен включать номер кабинета, время ФИО.
Треб.2: Он должен быть отсортирован по времени.
Слово «Он» во втором предложении относится к предыдущему требованию. И если порядок требований изменить, это требование будет непонятно.
Характеристики «хорошего» Требования
53
Элементарность
Требование должно содержать отдельный трассируемый элемент для которого возможно отслеживание связи):
Треб.1: Система должна предоставлять возможность выбрать врача по участку, выбрать дату приема, забронировать талон, а также предоставлять информацию об альтернативных специалистах .
Это требование содержит несколько элементарных требований, которые затрудняют трассировку.

Необходимость
В требовании нет необходимости, если: Ни одному заинтересованному лицу требование не нужно. Или Удаление требования не повлияет на систему.
Пример требования, которое не нужно заинтересованному лицу – это требование, которое добавили разработчики или дизайнеры, т.к. полагали, что оно необходимо пользователям или заказчикам. Пример требования, которое может быть удалено, т.к. оно не предоставляет никакой новой информации:
Треб.1: Все требования, указанные в документе Концепции должны быть реализованы и протестированы.
Характеристики «хорошего» Требования
54

Независимость от Реализации (Абстрактность)
Требования не должны содержать ненужной информации о дизайне и реализации системы:
Треб.1: Информация должна храниться в текстовом файле.
Решение того, каким образом информация будет храниться, и затем передаваться пользователю, должно приниматься дизайнерами или архитекторами системы.
Характеристики «хорошего» Требования
55

Постоянство
Не должно существовать конфликтов между требованиями. Конфликты могут быть прямые и косвенные. Прямые конфликты возникают, когда ожидается различное поведение системы в одной и той же ситуации:
Треб.1: Дата должна отображаться в формате дд/мм/гггг.
Иногда возможно разрешить конфликт путем анализа условий, которые явились источником данных требований.
В итоге это приведет к следующему требованию:
Треб.2: Даты должны отображаться в формате, принятом в веб-браузере пользователя.
Характеристики «хорошего» Требования
56

Немногословность
Каждое требование должно быть обозначено только один раз, и не должно перекрываться другим требованием:
Треб.1: Для удобства ввода даты приема в системе должен быть доступен календарь.
Треб.2: Система должна отображать всплывающее окно с календарем при вводе любой даты.
Первое требование (относящееся только к дате приема) является частью второго требования (относящееся к любой дате, вводимой пользователем).
Характеристики «хорошего» Требования
57

Завершенность
Требование должно быть описано для всех возможных условий:
Должно обеспечиваться взаимодействие АИС с внешними системами в рамках:
а) получения:
1) данных о полисах ОМС пациентов в БД ФОМС;
2) данных о льготах пациентов в БД Управления социальной защиты.
б) передачи в БД ЛПУ информации о реестре талонов пациентов.
Однако требования могут быть выражены в виде комбинации критериев:
Изменяемый: Если требование элементарное и немногословное, то оно обычно изменяемое.
Трассируемое: Если оно краткое и имеет уникальный идентификатор (ID), то оно обычно трассируемое (способное к отслеживанию связи).
Характеристики «хорошего» Требования
58

Извлечение требований
Управление требованиями – это интерактивный процесс. На типичной итерации предполагается полное прохождение по пирамиде.
59

60
ПОТРЕБНОСТИ
Определение заинтересованных лиц.
заинтересованная сторона (interested party): лицо или группа лиц, заинтересованных в деятельности или успехе организации [ГОСТ ISO 9000-2011].
заинтересованное лицо (stakeholder): лицо, на которое результат работы системы оказывает непосредственное влияние [Словарь RUP].
правообладатель (stakeholder): лицо или организация, имеющие право, долю, требование или интерес в системе или в обладании ее характеристиками, удовлетворяющими ее потребности и ожидания [ГОСТ Р ИСО 12207-2010].
Две основные группы:
Заказчики, по требованию которых осуществлялась разработка;
Пользователи системы: могут относиться: группа технической поддержки, группа обслуживания системы, расчетная группа, отвечающая за проведение сделок, акционеры компании и некоторые другие.
Разница: пользователи приложения центра обработки вызовов (call-центра), принимающие звонки, могут предпочитать изощренный пользовательский интерфейс, даже если он требует большого времени загрузки. Заказчик (директор call-центра) может запросить простой пользовательский интерфейс, который будет быстро загружаться и позволять 60бслуживать больше звонков в минуту.
Извлечение требований

Например, Заинтересованные лица для разработки АИС для ЛПУ.
Выявленные заинтересованные лица:
Заказчики: руководство ЛПУ; Пользователи: Работник регистратуры 1, Работник регистратуры 2, Пациент, старшей возрастной группы, Пациент средней возрастной группы), представитель ИТ отдела.
Разработчики: директор ИТ компании, бизнес аналитики, системные аналитики, кодировщики, графические дизайнеры, тестеры, менеджеры проектов, менеджеры по внедрению.
Сторонние компании, вовлеченные в процесс: лица, вовлеченные в управление, настройку и сопровождение системы
«Поставщики» стандартов и регламентов.
Извлечение требований
61

Техники извлечения требований
Интервью (индивидуальный диалог).
Анкеты (набор вопросов, отправленный большому количеству заинтересованных лиц).
Семинары (заинтересованные лица собираются на определенный период для интенсивных, насыщенных дискуссий).
Сценарии приложения (использование визуальных/графических инструментов для демонстрирования поведения системы).
Ролевые игры (каждому члену группы назначается определенная роль, обычно роль одного из пользователей).
Сессии с применением метода «мозгового штурма» (Мозговой штурм – групповой метод решения вопросов путем изложения идей в течение непродолжительных, интенсивных сессий).
62

Использование прототипов (разработка прототипов).
Сценарии использования (Use Cases – взаимодействие между пользователем и системой).
Анализ существующих документов (извлечение информации из используемых документов, электронной почты, записей).
Наблюдение и демонстрирование задач (наблюдение за пользователями, выполняющими определенную задачу).
Анализ существующих систем (сбор требований от морально устаревших заменяемых систем или от систем, разработанных в ходе конкуренции).
Техники извлечения требований
63

Техники извлечения требований
64

65
Техники извлечения требований

Техники извлечения требований
66

*Термины «потребности заинтересованного лица» и «запросы заинтересованного лица» - синонимы.
Потребности отражают требования высшего уровня.
Например:
создание, редактирование и прочие виды обработки информации;
регистрацию и ведение учета записи пациентов на прием;
выработку оптимальных технологических маршрутных схем движения документов;
организацию хранения информации;
обмен информацией между подразделениями ЛПУ;
формирование отчетов.
Потребностей такого уровня должно быть не более пяти от одного ЗЛ, и не более пятнадцати согласно проекту.
Техники извлечения требований
67

Разработка Концепции: документ Видение
Извлечение функциональных особенностей системы из потребностей заинтересованного лица.
Концепция должна содержать главную информацию о разрабатываемой системе, как о программном продукте:
Видение (Vision document):
Образ продукта (Product vision)
Границы (проекта) (Project scope)
*Помимо перечисления всех функциональных особенностей, этот документ должен содержать обзор системы, описание пользователей, обзор всех возможностей системы и другую информацию, которая может понадобиться для понимания назначения системы. Он также может содержать список всех потребностей ЗЛ, в случае если они не были зафиксированы в отдельных документах.
ФУНКЦИОНАЛЬНЫЕ ОСОБЕННОСТИ
68
Техники извлечения требований
ПОТРЕБНОСТИ

Образ продукта (Product vision) выстраивает работу всех ЗЛ в одном направлении, содержит концепцию ИС, в процессе изменяется медленно в зависимости от изменения стратегии системы или развития бизнес целей.
Документ О1. Образ продукта (Product vision)
69
Техники извлечения требований
Задачи Заказчика:
Задачи Разработчика – бизнес цели проекта

Образ продукта (Product vision):
потребности (бизнеса) (Needs) – учитывают, прежде всего, интересы Заказчика и определяют цель и подцели проекта (реализация социальных проектов в рамках ПП «Электронная Россия»);
потребности (Needs) включает в себя любые проблемы, возможности и ограничения, которые имеют потенциальную ценность для заинтересованных сторон [BABOK v3].
бизнес требования (Business Requirements) – основаны на выявленных Потребностях (Needs) бизнеса, составляют высший уровень абстракции в цепи требований: определяют образ и границы всего продукта (повысить качество обслуживания пациентов);
бизнес цели проекта – учитывают, прежде всего, интересы Разработчика и заключаются в том, чтобы получить признание в качестве наиболее защищенного продукта на рынке (разработать проект АИС ЛПУ с учетом возможного тиражирования);
70
Техники извлечения требований

Документ О.1 Г1. Границы проекта. Продукт
Документ О.1 Г. 2 Границы проекта. Масштабы и ограничения
71
Техники извлечения требований

1. Introduction
1.1 Business purpose
1.2 Business scope
1.3 Business overview
1.4 Definitions
1.5 Stakeholders
2. References
3.Business management requirements
3.1 Business environment
3.2 Goal and objective
3.3 Business model
3.4 Information environment
4. Business operational requirements
4.1 Business processes
4.2 Business operational policies and rules
4.3 Business operational constraints
4.4 Business operational modes
4.5 Business operational quality
4.6 Business structure
5. User requirements
6. Concept of proposed system
6.1 Operational concept
6.2 Operational scenario
7. Project Constraints
8. Appendix
8.1 Acronyms and abbreviations
Структура документа требований [ISO/IEC/IEEE 29148:2011 Системная и программная инженерия. Процессы жизненного цикла. Разработка требований]
72
Техники извлечения требований
Введение
1.1 Бизнес-цель
1.2 Объем работы
1.3 Обзор бизнеса
1.4 Определения
1.5 Заинтересованные стороны
2. Примечания
3.Бизнес требования
3.1 Бизнес-среда
3.2 Цель и задачи
3.3 Бизнес-модель
3.4 Информационная среда
4. Операционные бизнес требования
4.1 Бизнес-процессы
4.2 Политики и правила бизнес операций
4.3 Эксплуатационные бизнес ограничения
4.4 Режимы работы
4.5 Качество бизнес операций
4.6 Структура бизнеса
5. Требования пользователей
6. Концепция системы
6.1 Требования к системе
6.2 Сценарии использования
7. Ограничения
8. Приложения
8.1 Сокращения и аббревиатура

Сценарии Использования/Варианты использования (Use Cases) – отклик системы на воздействие пользователя.
Соглашению между разработчиками, заказчиками и пользователями что именно система должна делать - «контракт» между разработчиками и заказчиками.
Дополнительная спецификация содержит нефункциональные требования (удобство использования, надежность, производительность, способность к сопровождению).
А также некоторые функциональные требования, распространяющиеся за пределы системы, и вследствие этого, сложные для отображения в сценариях использования. Эти требования называют дополнительными требованиями. Они извлекаются из функциональных особенностей.
73
Техники извлечения требований
ДЛ: Пациент.
ВИ: Выбрать специальность врача.
Отклик: Система предоставляет список «Специальность врачей» в алфавитном порядке.

1.Поток событий для ВИ <имя>.
1.1. Предусловия.
1.2. Главный поток.
1.З. Под-потоки (если применимы).
1.4. Альтернативные потоки.
1.5. Доп. требования
Создание Тестовых Сценариев (Test Cases)
(из Сценариев Использования)
Как только все требования собраны, следует разработать способ проверить, правильно ли они реализованы в конечном продукте.
Тестовые сценарии (test cases) показывают тестерам, какие шаги должны быть сделаны для того, чтобы протестировать все требования.
Тестовые сценарии находятся на низшем уровне пирамиды.
Создание Тестовых Сценариев (Test Cases) (из Дополнительной Спецификации)
74
Техники извлечения требований

Требования являются основой для проектирования системы
75
Техники извлечения требований

Модель бизнес прецедентов
Модель вариантов использования
Модель требований
Техническое задание
SRS
Анализ требований
Тестирование
Определение требований правообладателей
76
АНАЛИЗ и ПРОЕКТИРОВАНИЕ

Техники извлечения требований
Интервью – один из наиболее распространенных методов сбора требований.
Преимущества:
интерактивность, предоставляющая возможность внесения дополнений или доработки вопросов в зависимости от полученных ответов;
хороший способ собрать требования по удобству использования системы, надежности, производительности и удобству сопровождения.
Недостаток:
плохо выявляются нефункциональные требования.
77

78
Рекомендаций для проведения интервью:
Формирование фокус-группы (При выборе ЗЛ для интервью убедитесь, что Вы понимаете, какую именно группу ЗЛ они представляют).
Формирование первоначального списка вопросов.
Проговорите ответы своими словами, чтобы убедиться, что Вы понимаете смысл. Вы не должны предлагать ответ на Ваш вопрос. Например: Какое время реакции системы Вы ожидаете? Три секунды? Не соединяйте несколько вопросов в один. Например: Необходимо ли Вам печатать талон, сохранять на электронной почте или вовсе предпочитаете не иметь «на руках» талон?
На первом этапе, не спрашивайте о деталях реализации.
Не используйте слишком длинные и сложные вопросы.
Не задавайте следующий вопрос, если еще не получен ответ на предыдущий.
Техники извлечения требований

Рекомендаций для проведения интервью:
Если ответ непонятен, задайте дополнительные вопросы, даже если их нет в сценарии интервью.
Когда пользователи отклоняются от темы при ответе на заданный вопрос, не перебивайте их. Позвольте им высказать свои мысли, на какую бы тему они не размышляли. Затем, если Вы не получили ответа на изначальный вопрос, задайте его снова.
Фиксируйте каждое упомянутое пользователем требование, даже если в настоящий момент оно кажется неуместным.
Спросите пользователей о дополнительной информации (экранные формы системы).
При разговоре с заказчиками не говорите о том, будет ли их требование выполнено или нет. Это будет решено позже.
В конце разговора спросите вопрос для получения дополнительной информации, например «Что еще я должен знать?».
Выясните у заинтересованного лица приоритет для каждого требования.
Делайте примечания или используйте записывающее устройство.
69
Техники извлечения требований

Рекомендуемый порядок для интервьюирования:
Официальное Представление.
2. Заполнение Профиля Заинтересованного Лица или Пользователя
Имя: Иванова Галина Петровна
Компания: ЛПУ
Должность: Работник регистратуры
Интервью:
Каковы Ваши основные должностные обязанности?
Какие услуги Вы предоставляете? Для кого?
Каким образом определяется качество Вашей работы?
Какие проблемы препятствуют выполнению работы?
Что сделает Вашу работу легче или сложнее? …….
3. Определение Проблемы
Каие проблемы, по Вашему мнению решит автоматизация большей части работы?
Для каждой проблемы, задайте следующие вопросы:
Почему существует данная проблема?
Как Вы решаете ее сейчас?
Как бы Вы хотели решить ее?
80
Техники извлечения требований:

4. Понимание Среды Пользователя
Кто является пользователем системы?
Какое у них компьютерное образование?
Есть ли у пользователей опыт работы с приложением данного типа?
С какими дополнительными приложениями, которые Вы используете, система может взаимодействовать?
Каковы Ваши ожидания в плане удобства использования АИС?
Какие печатные копии и он-лайн документация Вам необходимы? …
81
Техники извлечения требований
5. Обобщение для Понимания
Вы сказали мне….(перечислите своими словами список проблем, обозначенных заинтересованным лицом). Отражает ли это Ваши текущие проблемы с существующими решениями?
6. Взгляд Аналитика на Проблемы Заинтересованного Лица (утверждение или аннулирование требований)
Какие (если есть) проблемы, связанные с …. (список любых недостатков или дополнительных проблем которые, по Вашему мнению, могут беспокоить ЗЛ или пользователя). Для каждой предложенной проблемы, задайте следующие вопросы: Это реальная проблема? Каковы причины данной проблемы?
Каким образом Вы решаете эту проблему? Как бы Вы хотели решить проблему?
Каким образом Вы бы распределили по приоритету решение данных проблем по сравнению с остальными, Вами обозначенными?

7. Оценка Вашего Решения
Что если бы Вы могли….(суммирование главных возможностей предложенного Вами решения).
Как бы Вы оценили значимость этого?
8. Оценка Возможности.
Кому необходимо данное приложение в Вашей организации?
Насколько много пользователей данного типа будут пользоваться приложением?
Как бы Вы оценили успешное решение?
9. Определение Надежности, Производительности и Требований Сопровождения
Каковы Ваши ожидания в плане надежности?
Каковы Ваши ожидания в плане производительности?
Будете ли Вы сами осуществлять сопровождение продукта или ее будет осуществлять иные лица?
Есть ли у Вас какие-либо специальные требования к сопровождению?
Каковы требования к безопасности?
Каковы требования к установке и конфигурированию системы?
Есть ли специальные требования по лицензиям?
Каким образом будет осуществляться распространение системы?
Каковы требования к маркировке и оформлению пакета требований?
Каковы (если есть) Ваши требования к инструкциям или среде?
Должна ли осуществляться поддержка стандартов?
82
Техники извлечения требований

10. Подведение итогов.
Есть ли какие-либо другие вопросы, которые я должен задать Вам?
Если я должен задать сопутствующие вопросы, я могу звонить Вам?
Хотели бы Вы участвовать в обзоре требований?
11. Резюме Аналитика.
Система должна предоставлять возможность ……
Пользователь должен иметь возможность ……
Система должна следовать инструкциям по разработке установленных …..
Система должна быть доступной … в сутки с уровнем надежности, соответствующим …… приложениям.
Система должна быть разработана в течение …...
Система должна .…...
83
Техники извлечения требований
компромисс (trade-off): действия по принятию решений, в ходе которых производится выбор из различных требований и альтернативных решений на основе конечной выгоды правообладателей [ГОСТ ИСО/МЭК 15288:2007].

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

Техники извлечения требований
Семинары
В процессе семинара по требованиям выбранная фокус группа ЗЛ с проектной командой. Системный аналитик выступает в качестве организатора семинара.
Собираются для интенсивных, насыщенных дискуссий. Семинар по требованиям предоставляет возможность применить другие техники сбора требований: технику «мозгового штурма»; использование сценариев приложения; ролевые игры.
Задачи организатора
1. Перед семинаром:
Пригласите участников.
Распространите план и предварительный материал, чтобы участники могли подготовиться к встрече.
Подготовьте комнату для совещаний и необходимое оборудование (например, проектор).
2. В процессе семинара
Поручите кому-нибудь делать записи.
Ведите дискуссию в соответствии с планом.
Стимулируйте к участию в беседе всех заинтересованных лиц.
Подведите итоги семинара.
3. После семинара
Проанализируйте полученные сведения и документально оформите информацию в презентабельном виде.
Распространите результаты среди участников.
Если необходимо, назначьте дополнительные семинары по результатам.
85
Результаты семинара по требованиям должны быть документально оформлены – запросы Заинтересованных Лиц (Stakeholder Requests).

Инженерия требований.
Управление требованиями
Спецификация требований используется при разработке, тестировании, гарантии качества продукта, управлении проектом и его функциями. В дополнение к функциональным требованиям спецификация содержит нефункциональные требования (защита данных, адаптивность, изменчивость и др.), где описаны цели и атрибуты качества.
Валидация (аттестация) требований - это проверка требований, изложенных в спецификации для того, чтобы убедиться, что они определяют данную систему и отслеживание источников требований.
Заказчик и разработчик ПО проводят экспертизу сформированного варианта требований с тем, чтобы разработчик мог далее проводить разработку ПО.
Одним из методов аттестации является прототипирование, т.е. быстрая отработка отдельных требований на конкретном инструменте и исследование масштабов изменения требований, измерение объема функциональности и стоимости, а также создание моделей оценки зрелости требований.
86

Инженерия требований
Управление требованиями заключается в планировании и контроле выполнения требований и проектных ресурсов в процессе разработки компонентов системы на этапах ЖЦ.
Качество и процесс улучшения требований – это процесс формулировки характеристик и атрибутов качества (надежность, реактивность и др.), которыми должна обладать система и ПО, методы их достижения на этапах ЖЦ и адекватности процессов работы с требованиями.
Верификация требований – это процесс проверки правильности спецификаций требований на их соответствие, непротиворечивость, полноту и выполнимость, а также на соответствие стандартам.
В результате проверки требований делается согласованный выходной документ, устанавливающий полноту и корректность требований к ПО, а также возможность продолжить проектирование ПО.
87

Инженерия требований
Трассирование требований
Трассировку можно описать исходя из следующего:
требования изменяются во время функционирования системы;
возникновение требований и их расположение зависит от деталей практической ситуации и контекста их возникновения (требования можно изменить, изменяя эти детали);
трассировка требований должна поддерживаться и изменятся на протяжении всего ЖЦ программного продукта (т.к. изменяются сами требования, необходимо проводить изменение и промежуточных результатов, полученных при анализе, спецификации, кодировке и т.д.);
для удобства трассировки использовать иерархическую структуру связей между требованиями, основу которой составляет информация об атрибутах требований.
Механизмы трассировки требований:
вместо простых связей вводить более сложные отношения (например, транзитивное отношение для выделения цепочек связей) или вводить специфические отношения;
использовать сложные и гибкие пути трассировки;
поддержать базы данных объектов трассировки и отношений между ними.
88

Лучше один раз увидеть, чем сто раз услышать, тем паче тысячу раз прочитать пересказ.