Содержание курса

ВВЕДЕНИЕ
Введение в процесс формирования требований
Инфраструктура (ландшафт) для организации проектной деятельности
Управление целями заинтересованных лиц
Формализация потребностей заказчика
Выявление функции системы и управления границами проекта
Инжиниринг бизнес-процессов заказчика
Разработка логической структуры данных целевой Информационной системы(ИС)
Моделирование поведения целевой системы. Моделирование процессов управления
Формирование спецификаций требований на создание целевой ИС
Управление изменениями требований и организация эффективного взаимодействия в команде производства ИТ продукта
Организация процессов проектирования в производстве ИТ-продукта

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

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

Чаще всего процесс формализации требований к целевой системе включает 3 этапа:

Лингвистическое описание системы. Сбор потребностей заинтересованных лиц;
Анализ и моделирование сложной системы. Формализация Предметной области;
Разработка Требований на реализацию сложной системы. Формирование документа, содержащего структурированное описание характеристик, функции, и ограничений, которые определяют, как должна работать система;

Термин

Значение

Требование на разработку ИС

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

1. Пример формирования требования к несложной системе

Итак, рассмотрим несложную систему “Колесо автомобиля”.

Прежде всего обратимся к накопленным человечеством знаниям и выявим уже известные высокоуровневые требования к нему: «Колесо эта система, которая должна обеспечивать движение, устойчивость и безопасность транспортного средства».

Думаю, большинство из вас видели, как происходит «переобувание» машины в период межсезонья на станции шиномонтажа. Специалист, демонтировав колесо со ступицы декомпозирует его на 2 основных компонента: Диск и Шина. По факту, каждое из выявленных устройств может иметь более сложный состав и структуру, но в данном случае мы должны пренебречь этой сложностью (абстрагироваться).

Таким образом мы установили компонентный состав колеса.

В глоссарии можно зафиксировать:

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

Теперь установим, как используются эти компоненты, для чего они предназначены.

Функциональностью Шины является обеспечение сцепления с дорогой, при этом гарантируя амортизацию, комфорт и безопасность движения обобщающей метасистемы -автомобиля.

Функциональностью Диска является обеспечение взаимодействия Ступицы и Шины. То есть он выступает связующим звеном, передающим крутящий момент от двигателя Шине, через целый ряд преобразующих, трансмиссионных элементов.

Поскольку мы готовимся составлять требования для ИТ-систем давайте представим механизмы взаимодействия в виде интерфейсов сервисов.

С точки зрения взаимодействия, набор интерфейсов Колеса должны обеспечивать следующие возможности:

[Вз.01] Осуществлять сцепление с дорогой;
[Вз.02] Поглощать удары от неровностей дороги;
[Вз.03] Присоединяться к ступице крепежными шпильками;
[Вз.04] Быть наполненным воздухом;
[Вз.05] Обеспечивать герметичность для поддержания давления;
[Вз.06] Обеспечить равномерное распределение массы шины;
[Вз.07] Обеспечивать охлаждение тормозного механизма;

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

Теперь разберем критерии, для интеграционного взаимодействия с внешними подсистемами более крупной метасистемы (автомобиль).

С точи зрения интеграции: Колесо, как компонент, должно реализовывать следующие возможности:

[Ин.01] Быть прикрепленным к ступице и допускать способ отсоединять его при необходимости;
[Ин.02] Быть плотно зафиксированным на ступице. Гарантировать исключение самопроизвольного отсоединения;
[Ин.03] Передавать крутящий момент от ступицы к колесу, без деформации механизма;
[Ин.04] Быть присоединенным к разным “версиям” ступицы. Обеспечить взаимосовмещаемость.
[Ин.05] Быть защищенной от несанкционированного снятия со ступицы (кражи);
[Ин.06] Передавать информацию о снижении давления в шине на приборную панель автомобиля;

Каждому пункту так же присваиваем уникальный идентификатор с соответствующим шифром (Ин. - интеграция).

Теперь перейдем к синтетическому анализу:

Воздействие с внешними системами: как компонент колеса - Шина, критически зависит от трения, а также от ударов. Если колесо неправильно эксплуатировать и (или) хранить, это приведет к деформации шины и, возможно, к аварийной ситуации.

Диск, как компонент колеса, критически зависит от ударов. Если колесо неправильно эксплуатировать, это приведет к деформации диска и, возможно, к аварийной ситуации.

Диск, как компонент колеса, критически зависит от вибрации, а также от ударов. Если колесо не плотно прилегает к ступице, это приведет к несанкционированному отделению колеса от ступицы и, возможно, к аварийной ситуации.

В результате анализа выявленных потребностей можно формализовать следующие требования к колесу автомобиля:

1. [Тр.01] Передача крутящего момента:

1.1. [Тр.01.01] Диск должен передавать крутящий момент от ступицы через соединение со шпильками или болтами к шине. (Реализует потребность: [Ин.03])

1.2. [Тр.01.02] Механизм крепления ступицы и колеса, должен выдерживать высокие нагрузки крутящего момента при высокой скорости (до 200 км/час).

1.3. [Тр.01.03] Шина должна обеспечивать сцепление с дорогой, превращая вращение диска в перемещение автомобиля в пространстве. (Реализует потребность: [Вз.01])

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

2. [Тр.02] Фиксация и центрирование:

2.1. [Тр.02.01] Шина должна устанавливаться на диск, плотно прилегая к его посадочным бортам. (Реализует потребность: [Вз.04])

2.2 [Тр.02.02] При накачивании воздуха давление внутри шины должно прижимать её к диску, обеспечивая герметичность конструкции. (Реализует потребность: [Вз.05])

2.3 [Тр.02.03] Колесо должно легко крепиться к ступице и фиксироваться, препятствуя самопроизвольному отсоединению. (Реализует потребность: [Ин.01], [Ин.02])

2..4 [Тр.02.04] Должна быть обеспечена возможность отсоединять Колесо от ступицы, при соблюдении правил демонтажа; (см. правило демонтажа)

3. [Тр.03] Амортизация и гашение вибраций:

3.1 [Тр.03.01] Шина за счет конструкции должна частично поглощать удары от неровностей дороги, снижая нагрузку на подвеску. (Реализует потребность: [Вз.02])

3.2 [Тр.03.02] Диск должен снижать вибрации за счет своей конструкции. (Реализует потребность: [Вз.02])

4. [Тр.04] Охлаждение тормозной системы:

4.1 [Тр.04.01] Диски должны обеспечивать вентиляцию для улучшения охлаждение тормозных механизмов, предотвращая их перегрев. (Реализует потребность: [Вз.07])

5. [Тр.05] Балансировка и равномерное распределение нагрузки:

5.1 [Тр.05.01] Колесо на высокой скорости (свыше 90 км/час) должно обеспечить равномерное распределение массы, для снижения “биения” колеса. (Реализует потребность: [Вз.06])

5.2 [Тр.05.02] Должна быть возможность установить грузики на диск, для балансировки колеса при вращении.

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

Потребность	Требование	Описание
[Вз.01]	[Тр.01.03]
[Вз.02]	[Тр.03.01]
[Вз.03]	[Тр.01.03]
[Вз.04]	[Тр.02.01]
[Вз.05]	[Тр.02.02]
[Вз.06]	[Тр.05.01]
[Вз.07]	[Тр.04.01]
[Ин.01]	[Тр.02.03]
[Ин.02]	[Тр.02.03]
[Ин.04]	?	Отсутствует требование, реализующее проблему

Проведите свой анализ несложной сущности любой предметной области. Методом реверс-инжиниринга сформируйте требования для реализации описанного домена проблем.

2. Использование приема «Декомпозиция сложных проблем на простые»

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

Нередко мы становимся свидетелями ситуаций, когда разные люди, обсуждая между собой свое отношение к какому-либо явлению, событию или обстоятельствам, дают им диаметрально противоположные оценки. Например, глядя на одну и ту же машину серого цвета (одного из 50 оттенков) одни называют ее светлой, а другие темной. Кто в данном случае, по-вашему, прав?

Если оценивать придирчиво и беспристрастно — никто не прав. Но в современном мире такие оценки, как водится, никого не устраивают, общественность ставит вопрос ребром и хочет разобраться: темная она или светлая.

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

Предположим, для примера, что нам необходимо оценить такое сложное и многогранное явление, как колбаса вареная «Столичная». Хорошая она или плохая?

Как это правильно сделать?

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

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

Но даже такой анализ позволит получить оценку только для человека (или группы лиц) с определенной точкой зрения, формируемой вкусовыми пристрастиями, рекомендациями семейного врача, вероисповеданием, финансовыми возможностями и прочими KPI.

Притом оценки компонентов для разных оценивателей, могут значительно разниться не только между собой, но и в общей оценке композиции в целом. А потому помимо самих оценок каждого ингредиента следует еще учитывать и весомость оценки отдельного компонента в общем ансамбле для разных заинтересованных лиц. Например, для человека с проблемами пищеварения, вес оценки показателя – «острые приправы» может возобладать над всеми остальными.

Мало того, в зависимости от текущих условий потребления: холод, жара, регион приема, интервал последнего принятия пищи и т.п. у одних и тех же оценщиков весомость элемента в оценке композиции опять же может поменяться. Поэтому оценивать необходимо не только само явление/сущность, но условие в которых оно существует/используется.

Решение этой проблемы находит отражение в синтетическом методе познания. Суть его состоит в последовательном выполнении трех операций:

1) выделение большей системы (метасистемы), в которую интересующая нас система входит как часть;

2) рассмотрение состава и структуры метасистемы (ее анализ);

3) объяснение роли, которую играет наша система в метасистеме, через ее связи с другими подсистемами метасистемы.

Эти аспекты следует особо учитывать при формировании требований.

3. Использование приема «Определение точек зрения на проблему»

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

На что необходимо обратить особое внимание. В продолжение разбора примера с оценкой колбасы отмечу, что выясняя пристрастия заказчика для их повсеместного удовлетворения, мы зачастую получаем его оценку о неимоверном пристрастия к определенному сорту деликатеса. И лишь потом, мимоходом, случайно выясняем, что ему его употребление крайне противопоказано и исключено из рациона. Как эти проблемы выявлять на ранних стадиях и нивелировать их последствия, мы подробно разберем с следующих разделах.

Принимая во внимание разные точки зрения при анализе проблем, команда обеспечивает для себя дополнительные преимущества в организации производства:

Расширение перспектив: Разные взгляды помогают увидеть проблему с различных сторон, выявить скрытые аспекты и потенциальные риски.
Избежание предвзятости: Учет мнений различных заинтересованных сторон снижает вероятность одностороннего подхода и ошибок в суждениях.
Улучшение решения: Многообразие точек зрения способствует разработке более сбалансированных и эффективных стратегий решения проблем.
Развитие эмпатии: Понимание позиций других людей укрепляет командную работу и способствует лучшему взаимодействию.

Для более качественного осознания материала, на протяжении всего изложения, мы будем с Вами, рассматривать вполне реальный проект: «Автоматизация Библиотеки».

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

Проектирование Информационных систем. Часть 2. Введение в процесс формирования требований