|
Персональные инструменты |
![]() |
||
|
![]() |
![]() Agile Modeling with Mind Map and UMLМатериал из CustisWikiЭто снимок страницы. Он включает старые, но не удалённые версии шаблонов и изображений. Перевод статьи Agile Modeling with Mind Map and UML. СодержаниеАннотацияСбор требований — или, как говорят в контексте agile-разработки, сбор пользовательских историй (user stories), весьма важный и сложный аспект разработки ПО. Здесь нет никаких стандартных процессов или нотаций, только понимание, что важнейшие факторы эффективности этой фазы — это коммуникация и всевозможные практики уменьшения формализма и облегчения процесса. В этой статье Kenji Hiranabe предлагает использовать майндмапы, чтобы сфокусироваться на этих основных факторах при исследовании пользовательских требований, чтобы затем формализировать полученную модель на UML. Что такое майндмап?Согласно основопологающей книге «The Mind Map Book» от автора методики, Тони Бьюзана (Tony Buzan):
В майндмапах нужно использовать цвета, картинки и схемы, потому что человеческий мозг гораздо лучше приспособлен для распознавания шаблонов и образов, чем чисел и слов. Роджер Сперри (Roger Sperry), нобелевский лауреат в области физиологии, обнаружил, что кора головного мозга подразделяется на два полушария, между которыми ассиметрично распределены функции интеллекта. Его исследования показывают, что правая сторона доминирует в восприятии ритма, цветов и размеров, пространственном ориентировании, целостном восприятии (гештальте), воображении и мечтах; в то время как левая сторона сильна в логике и анализе, операциях над словами, числами и последовательностями/списками. Благодаря использованию обоих (и левого и правого) полушарий, майндмапы реализуют больший потенциал человеческой памяти, чем обычные, линейные записи. Настолько эффективны майндмапы благодаря следующим свойствам:
Чем майндмапы могут быть полезны в разработке ПО?В обзоре Chuck Frey (см. раздел «Рекомендованное чтение») показано, что три основных бизнес-приложения майндмапов это:
Например, использование майндмапов весьма уместно и эффективно в следующих ситуациях или даже фазах разработки ПО:
Майндмапы и пользовательские историиИнтерактивность — это ключевая ценность Agile. Mike Cohn в своей книге «User Story Applied» утверждает, что произошел ключевой сдвиг парадигмы от написания (документации) к общению (обсуждениям). В экстремальном программировании (XP, eXtreme programing) используются специальные карты историй (story cards) для записи результатов переговоров с пользователем. Ограничение на запись информации только на маленькую карту помогает направить обсуждение с заказчиком в конструктивном направлении. Часто даже такие карты пишут сами заказчики (или их представители), после чего их размещают на специальной стене в комнате разработчиков, как краткое резюме и просто напоминание о проведенном обсуждении. Соответственно, если возникает вопрос по пользовательской истории, нужно взять карту со стены, вспомнить, о чем там речь и обсудить ее снова. Исследование пользовательских требований с помощью майндмаповПользовательская история — это по сути фрагмент пользовательского требования. А я предлагаю использовать майндмапы пользовательских требований, чтобы целостно ухватить не только осколки, но и все пользовательские требования целиком. С одной стороны майндмап не хуже в «напоминании», чем карта истории, с другой — он явно более удобен для высокоуровнего обзора всей ситуации. Также майндмап — гибкий контейнер данных, подходящий для конспектирования слабоструктурированных интервью. Т.е. интервьювер может использовать заготовленные шаблоны для начала опроса, но когда беседа пойдет в неожиданном направлении — может легко добавить и новую ветвь, чтобы сконцентрироваться на темах, серьезно заинтересовавших опрашиваемого. Этот рисунок показывает заготовленный шаблон, для фиксации пользовательских требований. Т.е. заранее подгтовлены следующие вопросы:
Ответ на этот вопрос определяет пользователей системы, и потенциальных субъектов в сценариях использования (use case actors).
Это определяет сценарий использования системы (system's story or use case candidates).
А последняя ветвь, «Homework», фиксирует уже не вопрос, а все то, в чем не удалось разобраться в проведенных переговорах. Например, я использовал этот формат для сбора требований по городской библиотечной системе — опрашивая библиотекаря я параллельно записывал такой майндмап. Более того, я присоединил мой ноутбук к дополнительному проектору и оперативно правил этот майндмап одновременно с собеседованием. А элементы в ветке «Homework», по сути, определяют план следующей встречи. Удобство фиксации таких «непредсказуемых» тем и демонстрирует гибкость майндмапов по ведению слабоструктурированных данных. Переход от майндмапов в UMLПосле исследования цельной картины пользовательских требований, можно продолжать двумя способами:
При создании майндмапа пользовательских требований, я добавляю иконки субъектов (actors), сценариев и классов, более того, все эти иконки заранее «заготовлены» в шаблонных ветках майндмап-анкеты.
Использование майндмапов в сочетании с UML означает разделение требований на две модели:
ЗаключениеШаблонные майндмапы представляют прекрасный слабоструктурированный формат для расспросов, включая как структуру обязательных важных вопросов, так и удобство захвата неожиданных тем. Это также помогает исключить ошибки общения и ухватить «мягкую» высокоуровневую структуру пользовательских требований. Также майндмапы помогают вспомнить полный контекст требований на момент их записи. Ну, а после сбора идей на майндмапе, уже можно «сеять» ключевые слова — элементы майндмапа, чтобы «вырастить» соответствующие элементы UML-моделей. Тут уже можно использовать строгий синтаксис UML, чтобы построить семантически богатую модель предметной области и использовать ее для проектирования приложения. В Agile-разработке программного обеспечения считается, что одним из ключевых факторов успеха проекта — это коммуникация между всеми его участниками. Конечно, существует множество способов передачи и обмена информацией, но ни строгие формальные документы, ни обычные устные переговоры не являются адекватным решением. Ничто так не эффективно, как правильный набор лаконичных схем и графов, схватывающих самую суть исследуемой ситуации. И тут майндмапы и UML-диаграммы работают весьма хорошо, но каждый в своей собственной области:
СсылкиОсновы
Исследования и приложения
Репликация: База Знаний «Заказных Информ Систем» → «Agile Modeling with Mind Map and UML» Любые правки этой статьи будут перезаписаны при следующем сеансе репликации. Если у вас есть серьезное замечание по тексту статьи, запишите его в раздел «discussion». |
![]() |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
![]() |
![]() |