Просмотр сообщений
1
Варианты Использования (Use Case) / Use cases и модификация стандартных модулей
« : 08 Апреля 2010, 13:39:37 »
Решил попробовать с помощью use cases описать требования к сайту, создаваемому на платформе CMS Drupal. Drupal - это типичный фрисофт модульной конструкции. То есть есть компактное ядро, к которому друпалеры разрабатывают модули для реализации конкретного функционала и выкладывают в общий доступ. Постепенно в сообществе накапливаются сотни модулей на все случаи жизни. Несколько десятков из этих модулей настолько популярны, что их функционал и поведение известны всем разработчикам, и они являются de facto стандартными.
Естейственно, при разработке хотя бы чуть-чуть специфического сайта возникает необходимость кастомизации (модификации поведения) некоторых модулей. Технически это не вызывает никаких проблем, т.к. все модули в комментированных исходниках, надо просто переписать соответствующие места в шаблонах PHP или переопределить функции javaScript.
На начальном этапе все выглядело неплохо: я написал пользовательские истории (пользовательские use cases), они на ура были согласованы с заказчиком; специалист по Друпалу подобрал состав модулей, наиболее близко обеспечивающих нужное поведение.
Далее возникло следующее противоречие.
С одной стороны, детальное описание юз кейзов, реализуемых системой, достаточно бессмысленно. Все равно 95% поведения системы определено стандартными модулями, и совершенно нецелесообразно как что-то в этом поведении менять, так и документировать его. Документировать стандартное поведение представляется нецелесообразным, т.к. эта документация не нужна ни разработчикам (уже все разработано), ни тестировщикам (уже протестировано), ни пользователям (они считают стандартное поведение само самим разумеющимся). НО! Надо описать, в чем должны состоять ОТЛИЧИЯ требуемого поведения ОТ СТАНДАРТНОГО. То есть напрашивается некая диаграмм вариантов использования с зависимостями не типа <<include>>, а что то вроде <<replace>>.
То есть описание может выглядеть как-то так: "При просмотре новостей пользователь работает с сайтом в соответствии со стандартным сценарием просмотра новостей с использованием модуля view, за исключеним того, что в главном потоке ВМЕСТО стандартной последовательности действий системы при щелчке по заголовку новости в списке новостей делается то-то и то-то...
С другой стороны, стандартное поведение модулей Drupal все же не так известно людям, как стандартное поведение компонентов UI Windows. И если я с чистой совестью могу при описании Windows-приложения сослаться на то, что поведение компонентов должно соответствовать UX Interactions Guidelines, то при ссылке на стандартное поведение модулей Drupal я рискую получить полное непонимание некоторых читателей документации (уже получаю).
С третьей стороны, сами друпальщики считают все эти юз кейзы вообще бредом, который к веб-сайтостроению неприменим, т.к. пользователь в силу специфики веба может в любой момент оказаться на любой странице сайта. А где какие ссылки проставить, пусть думают специалисты по юзабилити.
Нет ли у кого опыта применения use cases в такой ситуации?
Может быть лучше и не пытаться их здесь использовать?
Естейственно, при разработке хотя бы чуть-чуть специфического сайта возникает необходимость кастомизации (модификации поведения) некоторых модулей. Технически это не вызывает никаких проблем, т.к. все модули в комментированных исходниках, надо просто переписать соответствующие места в шаблонах PHP или переопределить функции javaScript.
На начальном этапе все выглядело неплохо: я написал пользовательские истории (пользовательские use cases), они на ура были согласованы с заказчиком; специалист по Друпалу подобрал состав модулей, наиболее близко обеспечивающих нужное поведение.
Далее возникло следующее противоречие.
С одной стороны, детальное описание юз кейзов, реализуемых системой, достаточно бессмысленно. Все равно 95% поведения системы определено стандартными модулями, и совершенно нецелесообразно как что-то в этом поведении менять, так и документировать его. Документировать стандартное поведение представляется нецелесообразным, т.к. эта документация не нужна ни разработчикам (уже все разработано), ни тестировщикам (уже протестировано), ни пользователям (они считают стандартное поведение само самим разумеющимся). НО! Надо описать, в чем должны состоять ОТЛИЧИЯ требуемого поведения ОТ СТАНДАРТНОГО. То есть напрашивается некая диаграмм вариантов использования с зависимостями не типа <<include>>, а что то вроде <<replace>>.
То есть описание может выглядеть как-то так: "При просмотре новостей пользователь работает с сайтом в соответствии со стандартным сценарием просмотра новостей с использованием модуля view, за исключеним того, что в главном потоке ВМЕСТО стандартной последовательности действий системы при щелчке по заголовку новости в списке новостей делается то-то и то-то...
С другой стороны, стандартное поведение модулей Drupal все же не так известно людям, как стандартное поведение компонентов UI Windows. И если я с чистой совестью могу при описании Windows-приложения сослаться на то, что поведение компонентов должно соответствовать UX Interactions Guidelines, то при ссылке на стандартное поведение модулей Drupal я рискую получить полное непонимание некоторых читателей документации (уже получаю).
С третьей стороны, сами друпальщики считают все эти юз кейзы вообще бредом, который к веб-сайтостроению неприменим, т.к. пользователь в силу специфики веба может в любой момент оказаться на любой странице сайта. А где какие ссылки проставить, пусть думают специалисты по юзабилити.
Нет ли у кого опыта применения use cases в такой ситуации?
Может быть лучше и не пытаться их здесь использовать?