Форум Сообщества Аналитиков
Дисциплины => Системный Анализ и Требования => Варианты Использования (Use Case) => Тема начата: ilita от 04 Октября 2010, 15:41:55
-
В поисках мудрости, связанной с вариантами использования, на просторах интернета наткнулась на вот такой вопрос (из списка для собеседования на должность аналитика):
Как долго может длиться экземпляр варианта использования до достижения своей цели? В оригинале - "How long (time/calendar) may an instantiated use case run before it could complete its goal?"
Первое, что пришло в голову - "столько, сколько нужно", но хорошего аргументированного ответа я придумать не смогла. Как бы Вы ответили на этот вопрос?
-
Смотри книгу Коберна "Современные методы описания функциональных требований". Там все написано.
Если коротко, то для юзкейса уровня целей пользователя - до 10 минут.
-
А я вот не согласна с Коберном (если он такое утверждает). Не могу придумать конкретного примера, но внутреннее ощущение, что более длительные варианты использования имеют право на существование присутствует.
Внутренний конфликт даже заставил бросить все и полезть в эту книжку, но пока там ничего подобного не нашла... SALar, можете уточнить, куда смотреть?
-
Я думаю тут следует понять на каком уровне смотреть. Но в любом слкучае Salar прав. Если почитать того же Крэга Лармана, то он говорит:
что ВИ следует выделять
- это элементарный бизнес-процесс (или задача)
- это то, что одобрит руководство
- это нечто достаточно компактное по времени
Наверное, точных границ нет, но это скорее всего минуты или несколько десятков минут максимум
-
Добрый день.
В поисках мудрости ...
можно было бы и весь тест приложить.
Ну да ладно держите - вот он - во вложении :).
Наверно имелось ввиду следующее:
См. раздел 5.5 (книги), rдe вопрос обсуждается подробно.
- Удостоверьтесь, что для варианта использования указан правильный уровень
цели: обобщенный, пользователя или подфункции.
- Периодически проверяйте, знаете ли вы, где "уровень моря" для ваших целей и
насколько ниже (или выше) уровня моря находятся... Напомним тесты... :
Цели добивается одно лицо в одном месте в одно время
(2 - 20 мин).
- Действующее лицо может уйти удовлетворенным, как только цель
будет достигнута.
- Добившись многих целей, действующее лицо (если работает по
найму) может попросить повышения.
-
Спасибо за ответы :)
Посмотрела Корбена, к вопросу действительно лучше подходить учитывая уровни. В глоссарии есть практически готовый вариант ответа (термин "уровень"):
Вариант использования обобщенного уровня требует для выполнения несколько сеансов уровня цели пользователя, возможно, недели, месяцы или годы.
…
Вариант использования уровня цели пользователя описывает достижение основным действующим лицом определенной и непосредственной цели. Он обычно выполняется одним основным действующим лицом за один сеанс продолжительностью от 2 до 20 мин (или меньше, если основным действующим лицом является компьютер). Далее основное действующее лицо может продолжить работу с друrими целями.
-
Отмечу слово "обычно" в приведенной цитате. Это - важно. Потому что ВИ уровня пользователя - это сеанс работы пользователя с системой для достижения некоторой цели. И я встречал кейсы, когда такая работа длиться дольше, до нескольких часов, за которые пользователь реально достигает одну цель (и так каждый день). Обычно это происходит по побочным веткам процесса и связано с некоторым перебором вариантов "вручную". Если интересно, могу написать подробнее.
-
maksiq, да, интересно. Напишите подробней, пожалуйста!
-
Первый пример - автоматизация склада, формирование сменного задания складу, выполняется ежедневно с жесткими временными рамками (начинают в 16, надо успеть до 19). Основная ветка - тупая, система выбирает все заказы (назовем это так) с завтрашней датой отгрузки, контролирует, что для всех регулярных адресатов заказы уже созданы, проверяет ограничения и формирует это самое задание по некоторому алгоритму. Человек практически жмет большую кнопку, смотрит интегральные результаты и все, процесс на несколько минут. По этому сценарию идут 2/3 дней. А остальные - по побочным ветвям: если каких-то заказов нет, то репер - формировать из того что есть, или ждать. Если ограничения (их много, они разные) не удовлетворяются, то дальше начинается работа оператора, он смотрит на задание под разными разрезами и уменьшает его, или может принять решение о формировании с превышением (склад может поднатужится и сделать на 30% больше, но не ежедневно, а вот в машину лишний объем - не влезет, но можно поменять). А если почему-то отгрузка на день оказалась маленькой, он смотрит заказы на послезавтра и может запустить их. В общем-то, описание этого в виде ВИ - относительно муторное, потому что очень много ветвлений, но надо же на что-то опираться при проектировании интерфейса. Поэтому несколько кейсов мы прописали, как частых, так и экзотических. При этом, хотя человек в этом процессе взаимодействует не только с системой, но и с телефоном, это непрерывный кусок работы, на выходе которого должен быть вполне осязаемый результат. Это - один кейс.
Другой кейс. Девочки сидят на загрузке Каталогов от поставщиков. Квант работы - загрузка Каталога на следующий сезон от одного поставщика. Это Excel/Word файл условно структурированного формата, часто на несколько тысяч артикулов. "Условно" означает, что жесткой структуры нет. Конечная цель - товары и модели с необходимой атрибутикой должны появиться в Каталоге и правильно лечь по веткам, создав, где надо новые, а также - заполнив вспомогательные справочники (по необходимости). В зависимости от числа товаров, качества исходного материала и объема новых дополнительных справочников, задача занимает от некоторого количества минут на универсальной форме загрузки, до нескольких часов с последовательным преобразованием информации. Основное для нас было продумать удобную навигацию по интерфейсам и полуавтоматические кейсы заполнения справочников. А для этого - понять ход работы на типичных ветках.
Третий кейс. Бухгалтера, выверка отчетности. Тоже мутная задача. Смотришь, как он это делает в существующей системе, описываешь нитки ВИ (а то забудешь), потом - проектируешь новый интерфейс (или доработки), спрямляя проблемные места. Опять-таки, у него квант работы - отчет (или некоторая часть), выверяемая за "разумное" время - типа, полдня.
Как-то так.
-
Вопрос такой - реально ли такой большой ВИ описать с помощью user story? Или это просто нецелесообразно и нечетабельно?
-
Нечитабельно*
-
... Поэтому несколько кейсов мы прописали, как частых, так и экзотических. При этом, хотя человек в этом процессе взаимодействует не только с системой, но и с телефоном, это непрерывный кусок работы, на выходе которого должен быть вполне осязаемый результат. Это - один кейс.
Это один сценарий уровня уровня воздушного змея. И это несколько сценариев уровня моря.
Другой кейс. Девочки сидят на загрузке Каталогов от поставщиков. Квант работы - загрузка Каталога на следующий сезон от одного поставщика. Это Excel/Word файл условно структурированного формата, часто на несколько тысяч артикулов. "Условно" означает, что жесткой структуры нет. Конечная цель - товары и модели с необходимой атрибутикой должны появиться в Каталоге и правильно лечь по веткам, создав, где надо новые, а также - заполнив вспомогательные справочники (по необходимости). В зависимости от числа товаров, качества исходного материала и объема новых дополнительных справочников, задача занимает от некоторого количества минут на универсальной форме загрузки, до нескольких часов с последовательным преобразованием информации. Основное для нас было продумать удобную навигацию по интерфейсам и полуавтоматические кейсы заполнения справочников. А для этого - понять ход работы на типичных ветках.
Квант работы - это загрузка одной записи от одного поставщика. Это уровень пользователя (моря). 0.1 - 10 минут.
Загрузка каталога от поставщика - это обобщенный сценарий (уровня змея). Он действительно несколько дольше.
Третий кейс. Бухгалтера, выверка отчетности. Тоже мутная задача. Смотришь, как он это делает в существующей системе, описываешь нитки ВИ (а то забудешь), потом - проектируешь новый интерфейс (или доработки), спрямляя проблемные места. Опять-таки, у него квант работы - отчет (или некоторая часть), выверяемая за "разумное" время - типа, полдня.
Квант работы - это выверка одной записи. Это уровень пользователя (моря). 0.1 - 10 минут.
Проверка всего отчета - это обобщенный сценарий (уровня змея). Он действительно несколько дольше.
Таким образом во всех трех случаях вы рассмотрели обобщенные сценарии. И показали, что во всех трех случаях ВИ уровня пользователя длится менее 10 минут.
Что и требовалось показать.
-
Один из источников предлагал критерий WAVE для определения ВИ
What
Actor
Value
Entire
Вот в Entire и скрыта продолжительность. Еще одна метафора на тему длительности и целостности ВИ - "сделав это, я могу выпить чашечку кофе".
-
В поисках мудрости, связанной с вариантами использования, на просторах интернета наткнулась на вот такой вопрос (из списка для собеседования на должность аналитика):
Как долго может длиться экземпляр варианта использования до достижения своей цели? В оригинале - "How long (time/calendar) may an instantiated use case run before it could complete its goal?"
Отвечу так, как отвечают аналитики: в зависимости от того, как мы собираемся это применять.
-
SALar Вы неверно представляете кванты работы во всех трех сценариях. Потому что это компьютер при примитивном программировании крутит цикл по записям. Человек работает со всем заданием/каталогом/отчетом целиком. Потому что там взаимозависимые вещи и интегральные ограничения (в первом случае), а во втором и в третьем - идет настройка некоторых описателей или выбор класса строк, убеждаются что с ними хорошо, отбрасывают, разбираются с оставшимися. Да и компьютер при программировании в терминах коллекций, а не циклов - работает так же, по классам ситуаций. Естественно, в посте я писал по диагонали, без подробностей и шагов - которые интересны только в контексте конкретного бизнес-процесса. Но кванты работы с точки зрения человека и бизнес-области - именно такие, как я написал. Конечно, формлаьно можно придумать за человека жесткий алгоритм, по которому он якобы работает, но реально он работает не так, а параллельно и сложно. Тут, кстати, полная аналогия с процессом проектирования: есть умозрительная методика последовательных шагов и есть реальная жизнь со свободными переключениями. ПО должно поддерживать реальную жизнь.