В проектах по разработке программного обеспечения участвуют множество различных специалистов, у которых разные роли, разные специализации, своя терминология, свой жаргон. И часто в проекте люди не понимают друг друга. Заказчики не понимают, почему те или иные доработки стоят так дорого. Аналитики вынуждены выступать переводчиками между пользователями и разработчиками. А разработчики работают сразу с двумя моделями системы — с моделью представленной аналитиками и моделью реализованной в коде. Это приводит к тому, что основные усилия расходуются не на разработку полезного функционала, а на попытки удержать обе модели в голове и сопоставить их друг с другом.
Методология Domain Driven Design (проектирование на основе предметной области — далее DDD) для решения этой проблемы предлагает в качестве единой опорной точки использовать модель предметной области. Такая модель хорошо понятна заказчикам, служит отличным инструментом для аналитиков. Но важной особенностью такой модели является то, что она может быть напрямую реализована в коде, а значит, пригодна для использования разработчиками.
При принятии решения всегда встают вопросы:
– Что такое Domain Driven Design?
– На каких проектах можно применить DDD? Является ли мой проект таким?
– Какова цена и какие риски?
– Какие типичные ошибки ждут на пути?
Презентация Бибичева Андрея "Аналитик в Agile" с конференции SEF-09 (г. Минск). Видео доступно по ссылке: http://video.yandex.ru/users/stas-fomin/view/33/
А текст статьи - http://www.slideshare.net/biBIGine/agile-2029792
Из данной презентации Вы узнаете:
Кто такой Аналитик?
Чем он занимается?
Что он должен знать и уметь?
Почему требования так важны?
Что Вас ждет дальше?
Презентация предназначена для знакомства с ролью Аналитика (или ИТ специалиста, работающего с требованиями) и презентации полного курса «Разработка и управление требований к ПО".
Запись вебинара: http://vimeo.com/61915197
Кто такой аналитик и чем он занимается в компании и в команде разработки. Юлия Закс из компании сКЮ Контур рассказывает о тонкостях работы аналитиком и о том, как понять, что это твоя профессия.
Аналитики не нужны требования (поставь запятую, где нужно)Alexander Baikin
Я часто слышу: «А зачем нам Аналитики? Хорошие разработчики — вот это сила!» или «Зачем нам требования? Мы и так по Agile шарашим!».
Тогда почему многие жалуются:
«Мы одно и тоже по нескольку раз переделываем!»,
«Заказчик все время орет, что мы делаем не то, что ему нужно!»,
«Мы как будто разговариваем с Заказчиком на разных языках!»,
«Да блин, этот Заказчик сам не знает, что хочет!»,
«У нас постоянно расширяется скоуп проекта!»,
«Мы развиваем большой проект, но уже никто не знает, как он работает! В одном месте правим, в другом ломается!»,
«Но мы же договаривались о другом!!!»
и т. д.
Чтобы решить эти и другие проблемы на проекте как раз нужны Аналитики, которые пишут правильные требования.
Я вас не убедил, что вам нужны правильные Аналитики и хорошие требования?! Тогда послушайте вебинар:
Задача Джоэля Спольски
Зачем нужны аналитики?
Кто такой хороший аналитик?
Как бороться с извечными проблемами?
Как быть с Agile?
Презентация Бибичева Андрея "Аналитик в Agile" с конференции SEF-09 (г. Минск). Видео доступно по ссылке: http://video.yandex.ru/users/stas-fomin/view/33/
А текст статьи - http://www.slideshare.net/biBIGine/agile-2029792
Из данной презентации Вы узнаете:
Кто такой Аналитик?
Чем он занимается?
Что он должен знать и уметь?
Почему требования так важны?
Что Вас ждет дальше?
Презентация предназначена для знакомства с ролью Аналитика (или ИТ специалиста, работающего с требованиями) и презентации полного курса «Разработка и управление требований к ПО".
Запись вебинара: http://vimeo.com/61915197
Кто такой аналитик и чем он занимается в компании и в команде разработки. Юлия Закс из компании сКЮ Контур рассказывает о тонкостях работы аналитиком и о том, как понять, что это твоя профессия.
Аналитики не нужны требования (поставь запятую, где нужно)Alexander Baikin
Я часто слышу: «А зачем нам Аналитики? Хорошие разработчики — вот это сила!» или «Зачем нам требования? Мы и так по Agile шарашим!».
Тогда почему многие жалуются:
«Мы одно и тоже по нескольку раз переделываем!»,
«Заказчик все время орет, что мы делаем не то, что ему нужно!»,
«Мы как будто разговариваем с Заказчиком на разных языках!»,
«Да блин, этот Заказчик сам не знает, что хочет!»,
«У нас постоянно расширяется скоуп проекта!»,
«Мы развиваем большой проект, но уже никто не знает, как он работает! В одном месте правим, в другом ломается!»,
«Но мы же договаривались о другом!!!»
и т. д.
Чтобы решить эти и другие проблемы на проекте как раз нужны Аналитики, которые пишут правильные требования.
Я вас не убедил, что вам нужны правильные Аналитики и хорошие требования?! Тогда послушайте вебинар:
Задача Джоэля Спольски
Зачем нужны аналитики?
Кто такой хороший аналитик?
Как бороться с извечными проблемами?
Как быть с Agile?
Babok v2.0 перевод на русский язык свод знаний по бизнес анализуIvan Shamaev
BABOK версия 2.0 - свод знаний по бизнес-анализу. Перевод на русский язык стандарта BABOK для бизнес-аналитиков, глава введения. Понятия бизнес-анализа, задачи, базовые компетенции.
Глава 9 методы и техники бизнес-анализа (babok 2.0 на русском скачать)Ivan Shamaev
Методики и техники бизнес-анализа для бизнес-аналитиков. Текст взят и переведен на русский язык из BABOK 2.0 (Свод знаний по бизнес-анализу версия 2.0). Скачать в формате pdf BABOK 2.0 на русском языке. Бизнес-анализ. Бизнес-аналитики. Системные аналитики. IIBA. iiba.org, iiba.ru, russia.iiba.org. Руководство по бизнес-анализу. Методы для сбора требований и анализа бизнеса.
Это последняя лекция в серии для очень начинающих аналитиков. Она о высоком: о творчестве, о познании, о сложных задачах, которые тоже являются частью работы аналитика. Об этой стороне редко говорят, считая ее трудно формализуемой, необязательной или считают, что это "не для всех". Но останавливаясь только на обязательных, формальных и рутинных частях работы аналитика, мы сами убиваем любовь к собственной профессии, превращая ее в колесо для белки. Так вот: учитесь видеть в своей профессии творчество!
Управление требованиями. Сбор требований. Характеристики хороших требований. Анализ требований. Управление изменениями требованиями. Курс для бизнес-аналитиков. Основы бизнес-анализа для начинающих
Техносфера Mail.ru Group, МГУ им. М.В. Ломоносова.
Курс "Методы распределенной обработки больших объемов данных в Hadoop"
Видео лекции курса https://www.youtube.com/playlist?list=PLrCZzMib1e9rPxMIgPri9YnOpvyDAL9HD
Поплоухина Елена, Руководитель отдела тестирования в Usetech
https://vk.com/lena_flower
Расскажу об опыте организации процесса внутреннего тестирования проекта со строго формализованным техническим заданием от момента получения технического задания для тестирования требований до момента передачи релиза на приемочное тестирование.
Domain Driven Design - как, почему и зачем?ngrebnev
Одной из самых серьезных проблем в разработке программного обеспечения является борьба со сложностью решаемой задачи. Более того сложность задач решаемых разработчиками с каждым годом стремительно растет. Для решения этой проблемы хорошо себя зарекомендовал на практике набор подходов и методов, объединенных общим названием Domain Driven Design (DDD).
DDD позволяет существенно увеличить скорость разработки, снизить стоимость сопровождения и повысить качестве программного обеспечения. Но, несмотря на это, внедрение DDD на практике сталкивается с множеством трудностей и препятствий, что нередко приводит к полному отказу от применения данного похода в проекте.
Доклад посвящен описанию того как Domain Driven Design может быть использован в вашем проекте, зачем это вам нужно и почему это работает. Будут освещены преимущества и недостатки DDD, трудности с которыми приходится сталкиваться при его использовании и какой результат принесет его применение.
Требования постоянно меняются в ходе разработки
Требования могут противоречить друг другу
Меняются приоритеты разработки
Ограничены ресурсы – нужно уметь расставлять приоритеты
Ограничены сроки – нужно ясно понимать, какой функционал к какой дате будет реализован
Использование Wiki-системы большой командой для управления БА информациейDenis Dniprovskiy
Использование вики-ситемы большой командой для управления БА информацией: от базы знаний до требований и дизайна решения".
В докладке рассмотрю тему, стоит ли использовать вики-систему вместо привычного офисного пакета для управления бизнес-аналитической информацией (включая требования к требованию и дизайн решения).
Что нужно учесть, какие подводные камни могут ожидать, и на что стоит обратить внимание при работе в вики-системе.
Конспект составлен по Е-курс "Использование и управление информационной системы" для подготовки к экзамену по квалификации специалиста информационной технологии
Domain Driven Design в условиях разработки распределенных приложенийngrebnev
Распределенная архитектура приложения сейчас является наиболее актуальным выбором при проектировании корпоративных информационных систем. Такие архитектурные шаблоны как сервисно-ориентированная архитектура (SOA) и трехзвенная архитектура (3-tier architecture) являются de-facto стандартами в разработке корпоративных приложений.
Зачастую, главной проблемой в разработки является борьба со сложностью решаемой задачи, при этом для приложений уровня предприятия сложность с каждым годом стремительно увеличивается. Одним из наиболее эффективных средств борьбы с растущей сложностью является методология проектирования на основе модели предметной области (Domain Driven Design, DDD).
Каждый, кто пытался применить DDD в приложениях, имеющих распределенную архитектуру, будь то сервисы или клиент-сервер, знает с каким количеством трудностей приходится сталкиваться. В докладе будут рассмотрена целесообразность применения DDD в приложениях с сервисно-ориентированной архитектурой и в многозвенных приложениях, будут освещены трудности, возникающие при использовании DDD, и обозначены пути их преодоления. Будут даны ответы на вопросы:
- Стоит ли использовать DDD при разработке распределенных приложений?
- Как использовать DDD при использовании различных архитектурных стилей?
- Какую роль играют библиотеки, инструменты и фреймворки в разработке на основе модели предметной области?
- Какова эффективность использования DDD в agile-процессе разработки распределенных приложений?
Babok v2.0 перевод на русский язык свод знаний по бизнес анализуIvan Shamaev
BABOK версия 2.0 - свод знаний по бизнес-анализу. Перевод на русский язык стандарта BABOK для бизнес-аналитиков, глава введения. Понятия бизнес-анализа, задачи, базовые компетенции.
Глава 9 методы и техники бизнес-анализа (babok 2.0 на русском скачать)Ivan Shamaev
Методики и техники бизнес-анализа для бизнес-аналитиков. Текст взят и переведен на русский язык из BABOK 2.0 (Свод знаний по бизнес-анализу версия 2.0). Скачать в формате pdf BABOK 2.0 на русском языке. Бизнес-анализ. Бизнес-аналитики. Системные аналитики. IIBA. iiba.org, iiba.ru, russia.iiba.org. Руководство по бизнес-анализу. Методы для сбора требований и анализа бизнеса.
Это последняя лекция в серии для очень начинающих аналитиков. Она о высоком: о творчестве, о познании, о сложных задачах, которые тоже являются частью работы аналитика. Об этой стороне редко говорят, считая ее трудно формализуемой, необязательной или считают, что это "не для всех". Но останавливаясь только на обязательных, формальных и рутинных частях работы аналитика, мы сами убиваем любовь к собственной профессии, превращая ее в колесо для белки. Так вот: учитесь видеть в своей профессии творчество!
Управление требованиями. Сбор требований. Характеристики хороших требований. Анализ требований. Управление изменениями требованиями. Курс для бизнес-аналитиков. Основы бизнес-анализа для начинающих
Техносфера Mail.ru Group, МГУ им. М.В. Ломоносова.
Курс "Методы распределенной обработки больших объемов данных в Hadoop"
Видео лекции курса https://www.youtube.com/playlist?list=PLrCZzMib1e9rPxMIgPri9YnOpvyDAL9HD
Поплоухина Елена, Руководитель отдела тестирования в Usetech
https://vk.com/lena_flower
Расскажу об опыте организации процесса внутреннего тестирования проекта со строго формализованным техническим заданием от момента получения технического задания для тестирования требований до момента передачи релиза на приемочное тестирование.
Domain Driven Design - как, почему и зачем?ngrebnev
Одной из самых серьезных проблем в разработке программного обеспечения является борьба со сложностью решаемой задачи. Более того сложность задач решаемых разработчиками с каждым годом стремительно растет. Для решения этой проблемы хорошо себя зарекомендовал на практике набор подходов и методов, объединенных общим названием Domain Driven Design (DDD).
DDD позволяет существенно увеличить скорость разработки, снизить стоимость сопровождения и повысить качестве программного обеспечения. Но, несмотря на это, внедрение DDD на практике сталкивается с множеством трудностей и препятствий, что нередко приводит к полному отказу от применения данного похода в проекте.
Доклад посвящен описанию того как Domain Driven Design может быть использован в вашем проекте, зачем это вам нужно и почему это работает. Будут освещены преимущества и недостатки DDD, трудности с которыми приходится сталкиваться при его использовании и какой результат принесет его применение.
Требования постоянно меняются в ходе разработки
Требования могут противоречить друг другу
Меняются приоритеты разработки
Ограничены ресурсы – нужно уметь расставлять приоритеты
Ограничены сроки – нужно ясно понимать, какой функционал к какой дате будет реализован
Использование Wiki-системы большой командой для управления БА информациейDenis Dniprovskiy
Использование вики-ситемы большой командой для управления БА информацией: от базы знаний до требований и дизайна решения".
В докладке рассмотрю тему, стоит ли использовать вики-систему вместо привычного офисного пакета для управления бизнес-аналитической информацией (включая требования к требованию и дизайн решения).
Что нужно учесть, какие подводные камни могут ожидать, и на что стоит обратить внимание при работе в вики-системе.
Конспект составлен по Е-курс "Использование и управление информационной системы" для подготовки к экзамену по квалификации специалиста информационной технологии
Domain Driven Design в условиях разработки распределенных приложенийngrebnev
Распределенная архитектура приложения сейчас является наиболее актуальным выбором при проектировании корпоративных информационных систем. Такие архитектурные шаблоны как сервисно-ориентированная архитектура (SOA) и трехзвенная архитектура (3-tier architecture) являются de-facto стандартами в разработке корпоративных приложений.
Зачастую, главной проблемой в разработки является борьба со сложностью решаемой задачи, при этом для приложений уровня предприятия сложность с каждым годом стремительно увеличивается. Одним из наиболее эффективных средств борьбы с растущей сложностью является методология проектирования на основе модели предметной области (Domain Driven Design, DDD).
Каждый, кто пытался применить DDD в приложениях, имеющих распределенную архитектуру, будь то сервисы или клиент-сервер, знает с каким количеством трудностей приходится сталкиваться. В докладе будут рассмотрена целесообразность применения DDD в приложениях с сервисно-ориентированной архитектурой и в многозвенных приложениях, будут освещены трудности, возникающие при использовании DDD, и обозначены пути их преодоления. Будут даны ответы на вопросы:
- Стоит ли использовать DDD при разработке распределенных приложений?
- Как использовать DDD при использовании различных архитектурных стилей?
- Какую роль играют библиотеки, инструменты и фреймворки в разработке на основе модели предметной области?
- Какова эффективность использования DDD в agile-процессе разработки распределенных приложений?
Проектирование Программных Систем. Лекция 01Dima Dzuba
Лекция рассказывает о базовых принципах построения программного обеспечения. Проводится сравнение гибких (Agile) и водопадных методологий разработки программного обеспечения.
Формирование и управление командой проекта
• Выбор партнера. Ключевые роли и люди на Проекте;
• Различия в подходах к внедрению систем;
• Мотивация персонала на достижение результата и преодоление сопротивления внутри компании.
Similar to Разработчик, аналитик, заказчик — как найти общий язык? (20)
19. Domain Driven Design
• Единый язык (модель)
• основанный на предметной области
• непосредственно воплощенный в исходном
коде (проектирование по модели, Model
Driven Development)
20. Единый язык
Модель
Переработка Единый
предметной
знаний язык
области
25. Основан на предметной области
• Понятия языка имеют смысл в предметной
области
• В основе модели лежит представление всех
участников проекта о предметной области
30. Воплощен в исходном коде
• Требование:
– Зачислить сотрудника в подразделение
начиная с заданной даты
31. Воплощен в исходном коде
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);
47. Распределение товаров по
магазинам
• Сложная предметная область
• Информационные потоки и бизнес-процесс
определяет заказчик
• Технические сложности преодолимы
49. Система обмена сообщениями с
высокой пропускной способностью
• Простая постановка задачи
• Информационные потоки и бизнес-процесс
(обмен сообщениями) определяет
исполнитель
• Высокая техническая сложность