Содержание курса
Инфраструктура (ландшафт) для организации проектной деятельности
Выявление функции системы. 2. Моделирование сервисов
Инжиниринг бизнес‑процессов заказчика
Разработка логической структуры данных целевой Информационной системы(ИС)
Моделирование поведения целевой системы. Моделирование процессов управления
Формирование спецификаций требований на создание целевой ИС
Управление изменениями требований и организация эффективного взаимодействия в команде производства ИТ продукта
Организация процессов проектирования в производстве ИТ‑продукта
3. Практическое применение подхода формализации функций системы
Изучение способов выявления и формализации функций системы, особенно актуальны для современных тенденции ИТ‑рынка, связанных с развитием Сервисных моделей и архитектуры микросервисов. Затронем тезисно эти подходы.
Термин | Значение |
Сервисная модель взаимодействия систем | Способ организации взаимодействия между системами или компонентами через предоставление и использование сервисов (услуг). |
В такой модели одна система выступает в роли поставщика услуги (сервиса), а другая — в роли потребителя. Взаимодействие строится на основе определённых протоколов и интерфейсов, что обеспечивает стандартизированную и гибкую передачу данных, при выполнении функций.
Основные элементы сервисной модели:
1) Поставщик услуги (Service Provider) — система, которая реализует сервис и предоставляет интерфейс для доступа к нему.
2) Потребитель услуги (Service Consumer) — система, которая вызывает сервис и использует полученные результаты.
3) Реестр (Service Registry) — место, где хранятся сведения о доступных сервисах и их интерфейсах (например, API Gateway).
4) Контракт (Service Contract) — описание интерфейса сервиса, входных и выходных параметров, возможных ошибок.
Пример организации сервисной модели Информационной системы — «Госуслуги». Она реализована в виде единого государственного портала (https://www.gosuslugi.ru), через который граждане, бизнес и организации получают доступ к государственным и муниципальным услугам в электронном виде. Предполагается, что разработчики каждого сервиса используют свои технологии, методологические подходы и прочие специфические особенности. Но для пользователя это выглядит, как цельная система предоставления множества услуг через «единое окно» доступа.
Такой эффект достигается за счет соблюдения следующих общих принципов сервисной модели:
Разделение ответственности — каждая система выполняет свою узкую задачу через предоставление сервиса.
Независимость сервисов — сервисы могут разрабатываться, обновляться и масштабироваться независимо друг от друга.
Чёткие интерфейсы — сервисы взаимодействуют друг с другом через стандартные интерфейсы (например, REST, SOAP).
Управление состоянием — сервисы могут быть статичными или динамическими (сохранять или не сохранять состояние).
Платформа‑независимость — сервисы могут разрабатываться на разных языках программирования и работать на разных платформах.
На уровне разработки приложений используется схожий подход, при котором программное обеспечение конструируется, как набор независимых сервисов, каждый из которых реализует отдельную бизнес‑функцию и взаимодействует с другими через чётко определённые интерфейсы.
Термин | Значение |
Микросервисная архитектура | это стиль проектирования программного обеспечения, в котором система разбивается на множество независимых сервисов (микросервисов). Каждый микросервис выполняет отдельную задачу и взаимодействует с другими через чётко определённые интерфейсы |
Суть микросервисной архитектуры базируется на схожих правилах:
Система разбивается на множество малых независимых сервисов.
Каждый микросервис выполняет ограниченную функцию (принцип Single Responsibility).
Микросервисы взаимодействуют через сети с использованием стандартных протоколов (HTTP, TCP, WebSocket).
Каждый микросервис может использовать свою базу данных и работать на разных платформах.
Обновление и развертывание микросервисов выполняется независимо друг от друга.
Основные принципы микросервисной архитектуры:
Одиночная ответственность (Single Responsibility). Каждый микросервис отвечает за одну конкретную функцию.
Децентрализация данных (Decentralized Data Management). Каждый микросервис может использовать собственное хранилище данных.
Умные сервисы, простые соединения (Smart Endpoints and Dumb Pipes). Логика реализуется в микросервисах, а связь между ними — упрощённая.
Независимое развёртывание (Independent Deployment). Обновление одного микросервиса не требует остановки всей системы.
Изоляция отказов (Failure Isolation). Сбой одного микросервиса не влияет на работу других.
Многоязычность (Polyglot Programming). Разные микросервисы могут быть написаны на разных языках программирования.
Суть использования подходов сервисной архитектуры — применение эффективного способа конструирования ПО, как набора автономных сервисов, которые вместе образуют гибкую, масштабируемую систему. Это требует сложной инфраструктуры, но даёт высокую управляемость и надёжность.
Для проектирования подобных систем, важно иметь удобный инструмент, позволяющий формализовать требуемую функциональность в виде понятных структурных моделей.
4. Нотации IDEF0 для определения функций системы и границ проекта
Попробуем теперь на практике разобраться, как же можно выявлять функции системы, декомпозировать их, определять стимулирующие воздействия, поступающие на вход одних функции и являющимися продуктом работы других, смежных функций и прочие активности данного этапа.
В итоге, определив функции и потоки данных которыми они обмениваются, мы сможем управлять функциональным составом разрабатываемой нами системой и границами проекта, исходя из наших возможностей и целесообразности. Тему управления границами проекта подробно рассмотрим чуть ниже.
Для того чтобы имитировать работу функции в условиях приближенных к реальным, используется метод функционального моделирования. Это позволяет заранее увидеть возможные проблемы в эксплуатации системы и откорректировать проектное решение. В результате должна возникнуть функциональная структура системы, определяющая то, как каждая функция будут интегрирована в общую структуру системы.
Термин | Значение |
Функциональное моделирование | это метод анализа и описания системы или процесса с помощью набора функций и их взаимосвязей. Оно помогает понять, как именно система работает, какие задачи выполняются и как они взаимодействуют между собой. |
Бессмысленно рассуждать о функциях (свойствах) системы, не определив предварительно среду, в которой эта система будет функционировать, и не обозначив Субъекта, наделяющего систему функциями. Например, предоставление микроскопа, в качестве рабочего инструмента рубщику дров, затея так себе.
Функциональное моделирование применяют для того, чтобы:
Понять структуру функционирования системы — как именно выполняются активности.
Определить последовательность выполнения функций — что происходит сначала, что потом.
Выявить логические связи между функциями — как одна функция зависит от другой.
Оценить производительность системы — найти узкие места и неэффективные процессы.
Оптимизировать процессы — устранить избыточные или дублирующиеся функции.
Наиболее удобной методикой функционального моделирования, в том числе с точки зрения управления границами проекта, на мой взгляд является «старая добрая» методология проектирования SADT, диаграммы IDEF0, использующие иерархическую декомпозицию сверху вниз.
Графическую конструкцию стандарта составляют:
Понятие «Работа» (Activity) для обозначения действия, представленная в виде блока. Принцип «Черного ящика»;
Четыре вида интерфейса: «Вход» (Input), «Выход» (Output), «Управление» (Control) и «Механизм» (Mechanism), представленный в виде дуг.
Понятие «Работа» (Activity) для обозначения действия, представленная в виде блока. Принцип «Черного ящика»;
Четыре вида интерфейса: «Вход» (Input), «Выход» (Output), «Управление» (Control) и «Механизм» (Mechanism), представленный в виде дуг.
Основные элементы нотации:
Функциональный блок (процесс)
· Представляется в виде прямоугольника.
· В блоке указывается название функции (глагол + объект). Функциональный блок выполняет определённое действие.
Входы. Данные или материалы, необходимые для выполнения функции. Указываются слева от блока. Входы поступают в блок и преобразуются в выходы.
Выходы. Результаты выполнения функции. Указываются справа от блока. Выходы могут стать входами для других функций.
Управление. Ограничения или условия, определяющие правила выполнения функции. · Указываются сверху от блока.
Механизмы (ресурсы). Средства, с помощью которых выполняется функция. Указываются снизу от блока.
В ходе моделирования выполняется проведение декомпозиции с использованием техники структурного анализа и проектирования.
На самом верхнем уровне отображается всего один блок — представляющий активность самой системы (A-0).
Далее выполняется детализация с уровня A0 → A1 → A2 и так далее.
Контекстная диаграмма (A-0). Высший уровень модели. Описывает систему в целом — что делает система и как она взаимодействует с внешней средой.
Декомпозиция 1(A-1, А-2,.. А‑n). Детализация функций на 2-м уровне. · Разделение функций системы на подпроцессы. Каждая диаграмма описывает конкретный процесс.
Декомпозиция n(A‑n.1.. А-2.n). Детализация функций на n_ом уровне. Разделение функций на подпроцессы. Каждая диаграмма описывает конкретный процесс.
Так функции системы декомпозируется до уровня, отвечающего потребностям проекта.
Например, рассматривая нашу систему Библиотека, мы определяем, какие входящие, (стимулирующие) сигналы поступают в систему из вне. Отметим такие:
Данные об изданиях;
Данные о читателях;
Данные о сотрудниках библиотеки;
Заявки на выдачу издания;
Методики классификации изданий;
Данные о местах хранения изданий;
Информация, которая покидает систему может быть представлена в виде:
Данных о фонде библиотеки;
Данные о наличии изданий;
Ответы на запросы читателей.
Чаще всего входящими данными воспринимается информация, возникающая вне системы. Аналогично, выходящими данными — информация, предназначенная для внешних систем.
На диаграмме в нотации IDEF0 это выглядит так:
После того, как мы создали диаграмму верхнего уровня, мы можем «провалиться» во внутрь ее и получим новую диаграмму для детализации функций, в которой уже будут отражены все потоки, созданные в вышестоящем уровне смотри Рис.6.6. Теперь мы должны сопоставить эти интерфейсы (потоки данных) с функциями, которые их будут принимать, как стимулы в виде входных параметров или выдавать на выход, результатом своей работы.
Например, данные об издании должны попадать в функцию «Учет изданий», которая преобразует их в данные о библиотечном фонде.
А например, данные о читателях должны попадать в функцию «Учет читателей», которая преобразует их в данные о людях, использующих библиотечный фонд;
Данные о местах хранения должны обрабатываться функцией системы «Управление местами хранения изданий», для получения в системе данных о локации нахождения конкретного экземпляра книги или публикации.
Мы заполняем вакантные (пустые) функциональные блоки названием выявленной функции и соединяем их с потоками данных. На диаграмме это выглядит так, как показано на Рис.6.6
Таким образом мы добавили еще функции:
Учет читателей;
Учет сотрудников;
Обработка заявок читателей
Помимо того, что стрелки с интерфейсами входят в диаграмму «детализации функции» из вне с вышестоящего уровня и выходят из нее наружу, интерфейсы могут соединять функции и на одном уровне диаграммы.
Например, данные об издании, являющиеся результатом функции «Учет изданий», попадают на вход функции «Обработка заявок читателей» и позволяют выполнить работу этой функции по поиску нужного издания по заявке, преобразуя заявку в ссылку на найденное издание. Эту активность мы сможем более детально смоделировать, «провлившись» еще на уровень ниже.
Итак, «занырнув» в блок «Обработка заявок читателей», мы увидим входящие потоки данных и выходящие, а также новые, пока пустые, не соединенные с интерфейсами блоки.
Начнем подбирать функции для входящих данных.
«Издание» и «Заявка на выдачу» необходимы для функции «Поиск издания в фонде», которая будет осуществлять поиск издания в библиотечном фонде по заявке читателя и предоставлять ответ: есть ли издание в фонде и доступен ли его экземпляр для выдачи.
Этот процесс должен «покрывать» Пользовательскую историю US03, записанную нами на этапе сбора потребностей заказчика. Фактически мы производим трассирование функций, формализованных на данном этапе с Потребностями пользователей, выявленных на предыдущем.
Так же наша система должна будет выполнять функцию «Оформление выдачи издания» для фиксации факта выдачи экземпляра издания читателю. И тем самым покрывать Пользовательскую историю US05.
А еще «Бронирование издания для выдачи» функцию для бронирования одного из экземпляров издания для передачи читателю при возврате его в фонд. Этот процесс должен «покрывать» Пользовательскую историю US04.
А также «Оповещение читателя о результатах обработки его заявки» функцию для предоставления читателю информации о результатах обработки его заявки на выдачу издания. Этот процесс должен «покрывать» Пользовательскую историю... А вот для этой функции у нас нет пользовательской истории. Мы ее упустили при сборе начальных требований. Значит мы должны вернуться на шаг назад и добавить в потребности заказчика еще одну Пользовательскую историю.
Теперь определим внутренние интерфейсы, связывающие блоки, детализирующие рассматриваемую нами функцию. У нас получается вот такая диаграмма.
Таким образом слой за слоем, мы детализируем функции нашей системы и устанавливаем интерфейсы между функциями и слоями.
Теперь, когда все функции формализованы и выполнено трассирование с Потребностями пользователей, мы в плотную подошли к теме Границ проекта, затронутую в самом начале раздела.
Термин | Значение |
Управление границами проекта | это процесс обеспечения того, чтобы проект оставался в рамках первоначально определенного объема, предотвращая неконтролируемое расширение задач и функций. |
Эффективное управление границами помогает избежать «расползания» проекта, когда дополнительные требования или изменения приводят к увеличению сроков, бюджета и ресурсов. В рамках управления границам оперируют следующими аспектами:
1) Результаты (deliverables)
Какие конкретные результаты ожидаются от проекта?
В каком виде они должны быть представлены?
Какие параметры качества должны быть соблюдены?
2) Объём работ (Scope)
Что конкретно будет сделано в рамках проекта?
Какие задачи и функции включены в проект?
Какие задачи и функции исключены из проекта?
3) Временные рамки
Когда начинается проект?
Когда заканчивается проект?
Какие этапы включены в график проекта?
4) Ресурсы
Какие ресурсы будут использоваться в проекте?
Какой бюджет выделен?
Какие команды участвуют в проекте?
Таким образом, если мы понимаем, что мы не успеваем в рамках данного проекта реализовать все выявленные функции, мы можем смоделировать исключение одной или нескольких функции из нашей системы.
Например спрогнозируем, что произойдет, если мы попробуем обойтись без возможности «Бронирования издания». У нас провиснет один входящий интерфейс и один исходящий.
Но по большому счету это не сильно повлияет на поведение всей системы и не оставит без важных данных остальные функции. В противном случае, нам бы пришлось искать альтернативы.
Когда стоит исключать функцию из проекта?
Низкая ценность — функция не приносит ожидаемых результатов или выгоды.
Дублирование — функция дублирует уже существующие функции в системе.
Невыполнимость — из‑за технических, организационных или финансовых ограничений функцию невозможно реализовать.
Высокая стоимость — функция требует несоразмерных затрат при низком выходе.
Снижение рисков — функция может привести к нежелательным последствиям или повышению рисков.
Смена целей проекта — при изменении бизнес‑целей или требований.
Устаревание — функция теряет актуальность из‑за изменения внешней среды
Таким образом, ознакомившись с возможностями моделирования функционала системы при помощи диаграмм IDEF0, мы можем констатировать их важные преимущества:
Во‑первых, декомпозиция при анализе автоматизируемых процессов производится сверху вниз, от одного самого высокоуровневого к составляющим его подпроцессам. Последовательное разветвление процессов с уточнением их слой за слоем, позволяет не упустить важные деловые процессы из поля зрения команды, не перегружая внимание слишком большим количеством элементов на одной диаграмме;
Во‑вторых, способ моделирования, при котором за основу берутся входящие потоки данных и управляющие воздействия, позволяет максимально точно и полно выявить вложенные в процесс подпроцессы, которые должны обработать (преобразовать) эти данные. Потоки данных заставляют соединять функций между собой, выявляя недостающие и восполняя схему новыми элементами;
В‑третьих, фиксирование исходящих потоков из процесса и обязательное определение для них — процессов их потребления, позволяет не упустить функции в цепочке обработки и преобразования данных.
5. Итоги этапа формализации функций целевой информационной системы
Формализовать функции системы на ранних стадиях проектирования крайне важно для того, чтобы однозначно зафиксировать решение о том, что система должна делать. Такой подход предоставляет возможность структурировать решение и разбить процесс реализации ИТ‑продукта на этапы производства, разделить на модули, контуры, компоненты и прочие части, которые могут быть реализованы в разных проектах или распределены между командами.
По существу, выявление функций позволяет превратить размытые ожидания в конкретные возможности целевого продукта и помогает избежать ошибок, недопонимания и лишних затрат в дальнейшем.
В результате выполнения работ разработчики, аналитики, тестировщики и заказчики приходят к единому пониманию, что должна делать система. Это снижает вероятность «переделок» из‑за разночтений.
Современные средства проектирования и разработки позволяют использовать шаблоны, генерацию кода, тесты на соответствие функционалу. Каждая функция становится отдельным объектом для проверки.
Для специалистов, управляющих процессом формализованные функции дают основу для оценки трудоёмкости, планирования задач и распределения ресурсов.
Для программистов чёткие функции позволяют легче писать код, проектировать базы данных и интерфейсы.
Выявите функции своей учебной системы. Структурируйте их, определите основные потоки данных. Составьте диаграмму функций в нотации IDEF0.
В следующей части мы рассмотрим, как выявленные сервисы системы можно собрать в цепочки деловых процессов, обеспечивающих работу целевой системой.
