Форум Сообщества Аналитиков
Дисциплины => Системный Анализ и Требования => Варианты Использования (Use Case) => Тема начата: Denis Beskov от 01 Марта 2009, 13:19:44
-
Проектировщик интерфейсов, который работал там, утверждает (http://friendfeed.com/e/ca2d60cc-2922-40cd-a611-4c8c41d398a2/use-cases-UI-Modeling-Company/), что их аналитики создают описания use case вот в таком виде (http://www.uimodeling.ru/process/documents/use-cases.html).
Что вы об этом думаете?
-
Полностью согласен с Your Dah.
То что предложено не является use case в его изначальном понимании. Правда авторы и название извратили и семантику. Сценарий как мы понимаем экземпляр Use case, а не наоборот.
-
Все зависит от поставленного в Большой компании процесса. Может им так удобнее, может они сначала создают графическое изображение странички, а потом уже задумываются о логике работы...Например, сначала прорабатывается юзабилити, а предметка воруется с другого сайта...
То что их нельзя называть use case, я согласен - суть они переврали, с другой стороны, если такой подход помогает им разрабатывать качественные и классные продукты, то почему бы и нет. В конце концов - методологии и технологии - это лишь инструмент достижения целей...
-
Это, похоже, первый блин. Это примерно как первый опыт применения ООП программистом, всю жизнь просидевшим на ассемблере.
Мне ещё понравилось Описание целевой аудитории (http://www.uimodeling.ru/process/documents/personas.html). Кто-то, похоже, прочитал "Психбольницу в руках пациентов" и так же "творчески" применил подход, описанный Аланом Купером.
А ещё есть диаграммы взаимодействия (http://www.uimodeling.ru/process/documents/use-case-diagrams.html). Но аналитикам со слабым здоровьем я туда ходить не советую, а особенно не советую смотреть на URL этой страницы.
ИМХО, весь этот "контент" используется только пиара ради, а не работы для. Сайт должен создать у клиента видимость "солидности" - очень распространённое в рунете явление в последнее время.
-
Я такой подход описал в своей презентации - Пользовательские Сценарии как лучший способ описания Пользовательских Требований (http://www.uml2.ru/forum/index.php?topic=628.msg7650#msg7650)
-
Как "Сценарии взаимодействия" это вполне может себе жить. Но не как Use Cases. Я всегда говорил, что если желаешь делать ТАК КАК ТЕБЕ ХОЧЕТСЯ/удобно/понятно ... то называй это "сценарием", если обзываешь нечто use case, будь добр придерживаться их сути.
-
А ещё есть диаграммы взаимодействия (http://www.uimodeling.ru/process/documents/use-case-diagrams.html). Но аналитикам со слабым здоровьем я туда ходить не советую, а особенно не советую смотреть на URL этой страницы.
Взять банан, подписать Это перец - поди потом докажи, что это вовсе не перец.
То что изображено называтся примерно так - диаграмма последовательности экранных форм. Крэг Ларман, в частности, приветствовал использования диаграмм состояний для отображения логики переходов по web-страницам.
Что они и сделали, почему-то назвав диаграммами взаимодействия. Вопрос кто с кем взаимодействует?
-
Так это дизайнерский юзкейс?...
На юзкейс обычный не тянет - там же дизайн описан.
Состав полей — это дизайн? Впервые слышу.
-
Все выделять не стала.
Если это не детали дизайна, то я не знаю, что это такое. Назовите это деталями реализации, если вам не нравится слово "дизайн". :)
Но в том, что это не требования, я могу поклясться даже под градом тухлых помидоров, уж простите.
ida, это элементы проектирования, а не дизайна. Ты же пишешь выше «дизайнерские use case'ы?».
А мы таковых не знаем :) Есть business use case, use case и use case realisation. Похоже на последнее. (Если бы не прочие НО).
-
Отличный антипаттерн. Нужно будет сохранить и в тренинг вставить.
-
:)
Коллеги из минской локации...
У нас в компании все зависит от проекта. Поэтому, слава богу не все так пишут UC в EPAM :)
-
Я однажды читал UC, которые присылали аналитики из Штатов ... "я плакалъ". Так что дело не в локации и компании, а в конкретных людях.