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

/ АНАЛИЗ АРХИТЕКТУРА: - АРХИТЕКТУРА - Solution Design | Что нужно для составления SD | Шаблон проектного решения - DDD - Микросервисы и service mesh - ESB - HTTP/REST - RPC ДАННЫЕ DevOps БИБЛИОТЕКА ПРОЦЕССЫ ТЕСТИРОВАНИЕ
Solution Design (Проектное решение)
last update: 04-06-2021, 17:42 UTC
Что нужно для составления SD
Потребность в данном документе возникает, когда доработке подвергается сразу несколько систем.
Проектное решение (Solution Design) составляется на основе: Бизнес- и Пользовательских требований или Vision.

Цепочка аналитических артефактов и место Проектного решения в ней:

Памятка:

Шаблон проектного решения

Суть решения

Приводится краткое описание сути решения, позволяющее определить, как изменится ИТ-ландшафт в результате внедрения проектного решения, какую проблему это решит и какие цели будут достигнуты.

Сценарии использования решения

Содержание раздела должно отвечать на вопросы:

  • какие функциональные возможности реализует проектное решение?
  • кто и как будет их использовать после внедрения?
Описывается:
  • какие пользователи (Роли) будут работать с новым/измененным решением;
  • сценарии использования (Use cases) решения (основной и важные альтернативные). Use cases разрабатываются на основе Бизнес-требований и модели "ToBe" Бизнес-процессов, приведенных в концепции;
  • основные пользовательские и системные функции решения.
Например:
# Acteur
(Действующее лицо)
Verbe
(Шаг, действие)
Objet
(Объект воздействия)
Objectif
(Целевой объект)
1 Клиент подаёт заявку на Продукт/Услугу эксперту в офисе
2 Эксперт регистрирует заявку Карточка Клиента в Системе
3 Система присваивает номер заявки Карточка Клиента в Системе
N ... ... ... ...

Архитектура проектного решения

Приводится логическое, физическое представление (при необходимости) и интеграционный слой проектного решения.

Могут быть приведены несколько вариантов проектного решения. В этом случае должны быть описаны достоинства и недостатки каждого варианта.

  • Модель + Описание (если требуется). Описание может включать в себя:
    • cсылки на архитектурное описание существующих компонентов (н-р, "для реализации этого кейса мы используем существующий компонент Системы1")
    • ссылки на раздел с описанием интеграционного слоя (н-р, если у нас новый интерфейс, либо старый изменился)
    • перечень необходимого оборудования
  • Достоинства/Недостатки

Логическое представление

Для описания логической модели проектного решения может быть использован язык моделирования Archimate. Модель должна демонстрировать:

  • все перечисленные use cases;
  • какими компонентами слоя приложений будут реализованы use cases;
  • возможные изменения в инфраструктуре.
Например: (скачать модель в .archimate)

Физическое представление

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

Интеграционные потоки

Приводится перечень предполагаемых интерфейсов интеграции информационных систем и сервисов.
Например:

Бизнес-логика Инициатор.ИС Данные из Микросервис Инициатор.Тип взаимодействия микросервиса с транспортом Транспорт Тип взаимодействия с конечной ИС Конечная ИС
из в
Запрос в систему2 для чего-нибудь Система1 Система1 Система2 Какой-то там Асинхронный Request-Response, MQ шина.адаптер1 --> шина.адаптер2 Асинхронный Request-Response, MQ Система2

Потребность в оборудовании и его лицензировании

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

Предназначение кол-во Характеристики Окружение, ПО
Web сервер 2 CPU: 16vCPU;
RAM: 32Gb
SSD: 100Gb
Windows Server 2012 R2

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

Оценка решения

Оценка приводится для каждого варианта решения. В оценке должно быть указание на то, в каких ИС потребуются доработки.
Например:

Функциональность (use case) Система1 Система2 Система3
Печать заявки + (30 т.р.)
Фотографирование Клиента + (35 т.р.)
Отправка запроса в ПФР + (25 т.р.)
Выпуск дебетовой карты + (90 т.р.)
ИТОГО: 65 т.р. 25 т.р. 90 т.р.

ИЛИ

Состав работ Трудоёмкость, ч/дн Стоимость, руб. без НДС
1 Аналитика 220 0,000,000.00
2 Разработка 340 0,000,000.00
3 Тестирование 260 0,000,000.00
4 DevOps 60 0,000,000.00
5 Проектное управление 120 0,000,000.00
6 Риски (10%) - 0,000,000.00
7 Командировочные расходы - 0,000,000.00
ИТОГО: 1000 0,000,000.00

И/ИЛИ

Трудозатраты по Системе1 XXX
Трудозатраты по Системе2 XXX
Трудозатраты по Системе3 XXX
Трудозатраты по Системе4 XXX
Асинхронные развязки при обработке команд +
Маршрутизация, брокер очередей +
Гарантированная доставка информации по процессам в конечную систему +
Главный плюс решения: что-то там
Минусы решения
  1. Добавляется ещё одна ИС (набор микросервисов), которую надо дорабатывать, тестировать и обслуживать.
  2. Потребуется закупать мощности для развёртывания и включения в текущие промышленные и тестовые контуры.
  3. ...
Эту таблицу можно использовать для демонстрации Заказчику сравнения вариантов решения для дальнейшего выбора.

Декомпозиция работ

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

ИС # задачи в СУЗ Сервис / Бизнес-функция
(берётся из Archimate-модели решения)
Функциональность
(берётся из разработанных use cases)
Учётная система XXXX веб-сервис проверки наличия у Клиента ИНН
  • отправка запроса к веб-сервису ПФР
  • обработка данных ответа
Учётная система YYYY выпуск дебетовой карты и заполнение справочников ...