Разработчик, аналитик, заказчик — как найти общий...
53
Разработчик, аналитик, заказчик — как найти общий язык? Николай Гребнев CUSTIS
-
Upload
ngrebnev -
Category
Technology
-
view
426 -
download
1
description
В проектах по разработке программного обеспечения участвуют множество различных специалистов, у которых разные роли, разные специализации, своя терминология, свой жаргон. И часто в проекте люди не понимают друг друга. Заказчики не понимают, почему те или иные доработки стоят так дорого. Аналитики вынуждены выступать переводчиками между пользователями и разработчиками. А разработчики работают сразу с двумя моделями системы — с моделью представленной аналитиками и моделью реализованной в коде. Это приводит к тому, что основные усилия расходуются не на разработку полезного функционала, а на попытки удержать обе модели в голове и сопоставить их друг с другом. Методология Domain Driven Design (проектирование на основе предметной области — далее DDD) для решения этой проблемы предлагает в качестве единой опорной точки использовать модель предметной области. Такая модель хорошо понятна заказчикам, служит отличным инструментом для аналитиков. Но важной особенностью такой модели является то, что она может быть напрямую реализована в коде, а значит, пригодна для использования разработчиками. При принятии решения всегда встают вопросы: – Что такое Domain Driven Design? – На каких проектах можно применить DDD? Является ли мой проект таким? – Какова цена и какие риски? – Какие типичные ошибки ждут на пути?
Transcript of Разработчик, аналитик, заказчик — как найти общий...
Разработчик, аналитик, заказчик — как найти общий язык?
Николай Гребнев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?
Основная сложность задачи заключена в предметной области
Очень широкая граница, о которой необходимо договариваться с заказчиком
ПРИМЕР
Распределение товаров по магазинам
• Сложная предметная область• Информационные потоки и бизнес-процесс
определяет заказчик• Технические сложности преодолимы
АНТИПРИМЕР
Система обмена сообщениями с высокой пропускной способностью
• Простая постановка задачи• Информационные потоки и бизнес-процесс
(обмен сообщениями) определяет исполнитель
• Высокая техническая сложность
ТИПИЧНАЯ ОШИБКА
Модель предметной
областиКод
Переработка знаний
Модель предметной
области
Модель приложения
