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

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

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

Интеграционный слой (интерфейсы)

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

ID Расположение компонента-исполнителя Данные из Данные в Описание Сущность предметной области Транспорт
IR001 CRM CRM ABS Передача информации по Клиенту.
Здесь должен быть кейс из раздела с их перечнем, например "Передача доп. реквизитов для выпуска дебетовой карты".
Клиент ESB

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

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

Предназначение кол-во Характеристики Окружение, ПО
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 т.р.

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

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

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