Разработчик, аналитик, заказчик — как найти общий...

Разработчик, аналитик, заказчик — как найти общий язык?

Николай ГребневCUSTIS

СитуацияОрганизация

Процесс(ы)

ИС

Процесс разработки информационной системы

Участники• Заказчик:– Методологи– Пользователи– Руководство

• Исполнитель:– Аналитики– Разработчики– Тестировщики– Руководители

У каждого участника свое представление о ИС

Каждый говорит на своем языке

Заказчик• SDH• Оптическая секция• Сетевой элемент• СПК (сеть пакетной коммутации)• Тракт• …

Аналитик• Документ• Справочник• Состояние• …

Разработчик• Класс• Метод• Синглтон• SOLID• Датасет• Биндинг• …

Руководитель• Сроки• Бюджет• …

Проблемы• Непонятно, что делать• Сделали не то• Не можем обосновать стоимость работ

Непонятно, что делать

Сделали не то

Стоимость работ

Кто виноват?

Что делать?

Domain Driven Design (DDD)

Domain Driven Design• Единый язык (модель)• основанный на предметной области• непосредственно воплощенный в исходном

коде (проектирование по модели, Model Driven Development)

Единый язык

Переработка знаний

Модель предметной

областиЕдиный

язык

Переработка знаний– поиск системы абстрактных понятий, учитывающей все необходимые подробности

Все участники проекта используют единый язык

Все требования формулируются в терминах модели предметной области

Единый язык основан на предметной области

Основан на предметной области• Понятия языка имеют смысл в предметной

области• В основе модели лежит представление всех

участников проекта о предметной области

Основан на предметной области, а не на особенностях используемых технологий

Основан на предметной области

Кадровое делопроизводство

Датасет с таблицей сотрудников

Команда на обновление

Соединение с БД

Основан на предметной области

Личное дело сотрудника

Табель УРВ

Сотрудник

Кадровое делопроизводство

Единый язык непосредственно воплощен в исходном коде

Воплощен в исходном коде• Требование:– Зачислить сотрудника в подразделение

начиная с заданной даты

Воплощен в исходном кодеDepartmentHistoryRepository.Remove( from dh in DepartmentHistoryRepository where dh.EmployeeId = employee.Id && dh.DateStart >= date select dh);

var dhe = from dh in DepartmentHistoryRepository where dh.EmployeeId = employee.Id && dh.DateStart <= date && dh.DateEnd >= date select dh;dhe.DateEnd = date.AddDay(-1)

DepartmentHistoryRepository.CreateNew( employee, date);

Воплощен в исходном коде

подразделение.Зачислить( сотрудник, дата);

ЧТО МЫ ПОЛУЧАЕМ?

Domain Driven Design• Средство для формулировки требований и

общения• Адекватное отражение сложности системы• Обоснованную стоимость работ

Обоснованная стоимость работ

Большая сложность изменений

Масштабные изменения моделиВведение новых понятий

Высокая стоимость

СКОЛЬКО ЭТО СТОИТ?

Из чего складывается стоимость?

Много общения и согласованийПлотная работа с заказчикомВысокая прозрачность системыМеньше гибкости на стороне исполнителя

Разработчики должны участвовать в построении модели предметной областиОбщение с заказчикомКомпетенции аналитика у разработчика

Ограничения накладываемые инструментамиНе все, что можно придумать, можно реализовать.

Риск неправильно спроектировать модель предметной области

А НУЖНО ЛИ ЭТО?

На каких проектах применять DDD?

Основная сложность задачи заключена в предметной области

Очень широкая граница, о которой необходимо договариваться с заказчиком

ПРИМЕР

Распределение товаров по магазинам

• Сложная предметная область• Информационные потоки и бизнес-процесс

определяет заказчик• Технические сложности преодолимы

АНТИПРИМЕР

Система обмена сообщениями с высокой пропускной способностью

• Простая постановка задачи• Информационные потоки и бизнес-процесс

(обмен сообщениями) определяет исполнитель

• Высокая техническая сложность

ТИПИЧНАЯ ОШИБКА

Модель предметной

областиКод

Переработка знаний

Модель предметной

области

Модель приложения

СПАСИБО

Докладчик: Николай Гребневe-mail: ngrebnev@gmail.comslideshare.net: ngrebnev