# БИБЛИОТЕКА Курсы Системная инженерия Сознание, интеллект Политэкономия Сумма технологии Экстраполяция в будущее ПРОЦЕССЫ Ресурсы Цикл разработки ПО Waterfall RUP Agile Kanban Управление Теория ограничений АНАЛИЗ Ресурсы ПО для Аналитика Кто аналитики? Бизнес-процесс Требования Уровни и типы Источники Стейкхолдеры Нотации АРХИТЕКТУРА Ресурсы ПО для Архитектора Кто архитекторы? Архитектурные слои язык Archimate GAP-анализ SOA Микросервисы ESB Solution Design DDD РАЗРАБОТКА Ресурсы Continuous Integration git Frontend HTTP/REST Apache Регулярка JS Perl Linux ТЕСТИРОВАНИЕ Ресурсы QA и QC Цикл тестирования 1 Тест-анализ 2 Тест план 3 Тест-дизайн и покрытие Уровни тестирования Виды тестирования Баг-репорт Шаблоны XPATH Безопасность Нагрузочное Android Автоматизация Selenium Генератор ИНН ДАННЫЕ Об информации SQL MongoDB
Эта страница:
Шаблон проектного решения (SDD)
Ещё в этом разделе:
АРХИТЕКТУРА Solution Design Document DDD
Другие разделы:
# АНАЛИТИКА АРХИТЕКТУРА ДАННЫЕ РАЗРАБОТКА БИБЛИОТЕКА ПРОЦЕССЫ ТЕСТИРОВАНИЕ
Solution Design Document
Составляется на основе: Бизнес- и Пользовательских требований или Концепции/Vision.
Шаблон проектного решения (SDD)

Суть решения

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

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

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

  • какие функциональные возможности реализует проектное решение?
  • кто и как будет их использовать после внедрения?
Описывается:
  • какие пользователи (Роли) будут работать с новым/измененным решением;
  • сценарии использования (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 сервер CRM 2 CPU: 16vCPU;
RAM: 64Gb
SSD: 146Gb
Windows Server 2012 R2 CRM 2019

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

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

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

Функционал (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)
CRM XXXX веб-сервис проверки наличия у Клиента ИНН
  • отправка запроса к веб-сервису ПФР
  • обработка данных ответа
Учётная система YYYY выпуск дебетовой карты и заполнение справочников ...