Форум Сообщества Аналитиков

×


Просмотр сообщений

В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.


Сообщения - Сергей Евтухович

Страницы: « 1 2 3 4 5 6 7 8 9 »
16
А в реализации я посмотрел, так там совершенно разные маршруты, контроллеры и вьюхи.
Если реализация отличается, но соответствующие требования пересекаются, я бы выделил общую часть двух юзкейсов во включаемый третий. Хотя, с другой стороны, если в новой реализации планируется преднамеренно оставить две разные реализации, то лучше оставить два разных юзкейса.

17
Сергей, добрый день. Нет, не рассматривал. Но чуточку подумав, решил, что тут не прокатит
Эдуард, не могли бы пояснить почему вы считаете что не прокатит?

18
Добрый день, друзья!

Возникла задача документирования существующей системы. Решил начать с выявления реализованных use cases и столкнулся с некоторым моментом, который замечал и раньше, но не уделял этому должного внимания, чтобы разобраться.

Итак, в чем же проблема.
Пользователь веб- или мобильного приложения может разместить заявку на выполнение определенной услуги. При этом заявка попадает в список не распределенных заявок и ожидает своей очереди.

Однако заявку можно оставить, и придя в офис лично или позвонив по телефону. В этом случае оформляет заявку оператор. Если заявку оформляет оператор, то заявка уже попадает в список заявок этого оператора. При оформлении заявки в таком случае существует возможность указывать больше деталей и особенностей этой заявки, чем у заявки, которую размещает обычный пользователь.

В целом жизненные циклы заявки созданных разными способами одинаковы, за исключением начального состояния и одного правила перехода.

Так заявка, созданная оператором, всегда остается закрепленной за этим оператором, но может перейти в состояние Просрочена, если с момента ее создания в течение определенного времени по ней не было никаких работ.

А заявка, созданная обычным пользователем, после того как оператор ее взял на себя, может перейти в исходное "не распределенное" состояние, если с момента ее взятия в течение определенного времени по ней не было никаких работ.

Следует ли рассматривать эти два сценария как разные, хотя и похожие (во много пересекающиеся) ВИ, или же стоит рассмотреть как одни ВИ, в котором есть некий основной сценарий и альтернативы?
Эдуард, добрый день!

А вы не рассматривали вариант двух разных юзкейсов с включением общего поведения (include) в третий юзкейс?

19
Наткнулся на описание ЮМЛ от МС:
https://msdn.microsoft.com/ru-ru/library/dd409376.aspx

Кто какие ошибки найдет?

На затравку: мне очень не понравилась вот эта схема:


Что это за ЗЛ - Ресторан? Как Клиент заказывает еду без него?

1. Описываются несколько типов диаграмм и предлагается начать разработку с любой, хотя надо идти от общего к частному. Т.е. будет странным от sequence перейти к use case диаграмме.
2. С одной стороны говорится о том что требования описывают внешнее поведение, видимое через UI и API, с другой стороны, к примеру, sequence диаграмма описывается как часть требований, но говорится про взаимодействие с частями системы.
3. Непонятный UC "Доставить еду" на второй диаграмме. Вынесен за границу некой подсистемы, но вместе с тем приведён на той же диаграмме и непонятно к чему он относится. Такое ощущение,  что это неудачно названный бизнес-UC.

Дальше читать не стал. Много букв:) А пример с эктором ресторан конечно не очень удачный. Хотя такой Эктор может существовать если, к примеру, в ресторане работает одно лицо, которое выполняет все роли.


20
Разработчики игры должны следовать руководствам по разработке игр от держателя платформы. Но самостоятельно на низком уровне думать о зарядке/разрядке аккумулятора они не должны.

Т.е. то что я хочу сказать - разработчики должны следовать советам из руководства о том, как сохранить заряд батареи. Если эти рекомендации не нарушались, то, следовательно, игра была написана правильно.

Может оказаться что советы в руководстве не помогают достичь цели, т.е. максимально снизить потребление энергии. В таком случае часть пользователей откажется от игры и доход от продажи уменьшится. Помимо следования руководству хорошо бы ещё убедиться что советы достаточно полезны.

21
Ден, у тебя есть методика по ситуационному анализу. Пусть в кратком варианте? Этот вопросе не в рамках обсуждаемой темы, но интересно.

Прикольно. Я не писал это сообщение. Либо пора попить что-нибудь от склероза:)

22
Вы сначала потренируйтесь в ситуационном анализе, установите факты, выявите проблемы, определите цепочку последствий, причины.

Затем сформулируйте цели, критерии успеха.

Ден, у тебя есть методика по ситуационному анализу. Пусть в кратком варианте? Этот вопросе не в рамках обсуждаемой темы, но интересно.
Мне, тоже было бы интересно узнать.

23
можно показать, где это я утверждаю?
Я говорил про формулировку фич, которые объединяют в себе несколько вариантов использования. Вы сказали что занимаетесь этим после перехода к анализу ВИ, то есть, когда ВИ уже сформулированы. ВИ уже есть, а фичи ещё не сформулированы. Кто кого неправильно понял?
Этот момент мы рассматриваем когда переходим к анализу вариантов использования. Но в данной задаче это не имеет большого значения. Эта работа выполняется в другом курсе.

24
Потребность проистекает из проблемы. Избыточная трудоемкость - это проблема, некоторый недостаток, то что хочется поменять. Не не может формулироваться как потребность в избыточной трудоемкости, но как потребность в ее устранении. Такая связь может объяснить почему возникла такая потребность.
Problem Statement Насколько я знаю это проблема с точки зрения бизнеса, а "Избыточная трудоёмкость" - с точки зрения конкретного человека. Это может быть его личное мнение, что трудоёмкость слишком велика, но владелец бизнеса может считать что это не проблема, а норма: "Во всех библиотеках так работают, а ей видите ли трудно". Поэтому я бы сказал скорее всего что это Need, а не Problem statement.

Если считать потребность, то такая формулировка мне нравится. Но тут нужно помнить - краткое именование потребности и ее расширенное описание.
Например "быстро узнать о наличии книги"?
Примерно так.

Не очень Вас понимаю, можете дать более развернутое разъяснение.
Как можно назвать фичи, если у вас есть только 2 UC: "Просмотреть список книг" и "Зарегистрировать читателя"? Можно назвать аналогично UC, если вообще есть смысл в использовании фич в такой системе. В таком случае студенты скорее всего не поймут зачем вообще нужны фичи.

Этот момент мы рассматриваем когда переходим к анализу вариантов использования. Но в данной задаче это не имеет большого значения. Эта работа выполняется в другом курсе.
Обычно сначала формулируются фичи, а уже потом по каждой фиче выделяются UC. Вы же утверждаете, что у вас наоборот. Странно.

Ждём следующей серии версии от авторов работы :)

25
Вполне возможно, но в данном случае мы опускаемся чуть ниже к этим самым неграм. Соглашусь, что трудоемкость - как краткая формулировка мало понятна. Избыточная трудоемкость - лучше?
Если вы опускаетесь ближе к "неграм", то тогда это уже не Problem Statement, а Stakeholder Need. В таком случае лучше придерживаться устоявшейся терминологии и назвать эти сущности потребностями (Need). "Избыточная трудоёмкость..." более интересно звучит, но если это всё-таки потребность, то я сформулировал бы примерно так: "Снизить время, необходимое на регистрацию читателя до 5 минут".

Полностью согласен. Хотя необходимость повторной регистрации в каждом филиале - явная проблема :). Какие бы Вы формулировки предложили?
Напомню пример создавался автором, что называется с колес.
Если я правильно понял из описания, то:
"Информация о наличии" -> "Необходимо иметь возможность в течение 30 секунд получать информацию о точном местонахождении невыданного экземпляра книги."

В данном случае, поскольку в рамка учебного курса невозможно смоделировать реальные запросы ЗЛ и взаимодействия с ними, то упрощается до формулировки предполагаемых потребностей, устраняющих проблему (concern - озабоченность) ЗЛ
Почему невозможно смоделировать запросы ЗЛ? У вас же есть описание задачи? Это уже запрос ЗЛ. Если разделить его на 2 документа, можно оформить их как протокол совещания, e-mail и т.п.
В предлагаемом Вами варианте предлагаю придерживаться терминологии из стандартов/методологий. Если это не запросы ЗЛ, то не надо использовать такой термин. Иначе можно запутаться.

Я согласен, что свойства к качеству должны быть заявлены, но где функциональные свойства?
"Развлечения и работа" - это функциональность.

Естественно, если Вы запишите "ввод, изменение, удаление данных о.." разве это не будет функциональной возможностью, функцией, свойством будущей системы?
Если вариантов использования мало, то можно назвать фичи аналогично вариантам использования, но тогда исчезает образовательная ценность такого упражнения. Студентам я бы показал как разделять функционал на высокоуровневые возможности. К примеру для нескольких ВИ, таких как CRUDLS, можно сформулировать фичу как "Управление такими-то сущностями". Тогда хотя бы будет понятно, что отношение фич к ВИ это не 1-к-1, а 1-ко-многим.

Тут я следую рекомендациям моего эксперта. Это не сами прецеденты, это требования типа прецеденты, которые впоследствии будет развернуты в полноценные сценарии и диаграммы активности типа черный ящик.
Зачем тогда называть вариантами использования то, что не является ими?:) Сами себя запутываете.

Системный требования я оставил для полноты. Давайте, пока оставим их в данном случае вне поля нашего рассмотрения. Хорошо?
ОК.

26
Эд, а зачем так сразу переходить к трассировке проблем на возможности?

Вы сначала потренируйтесь в ситуационном анализе, установите факты, выявите проблемы, определите цепочку последствий, причины.

Затем сформулируйте цели, критерии успеха.

Потом уже можно переходить к выдвижению возможностей и трассировке.
Согласен с Денисом. Так было бы гораздо интереснее. Но если сузить задачу, то...

Сергей, пока студенты собираются с мыслями, попробуем обсудить формулировки:
проблем (issue) - потребностей (need) - возможноcтей (feature)

Во вложении выгрузка из модели, если у вас есть ЕА, я предоставлю и сам проект.
Проект касается некой сети библиотек. Поскольку это образец, то он не полон и в нем к сожалению вполне возможны логические ошибки.

Попробуем разобрать какие? Не все, а на примере какой-то определенной части?
Давайте попробуем. Начнём в проблем:
1. Трудоемкость регистрации читателя
2. Повторная регистрация
3. Трудоемкость поиска изданий
4. Информация о наличии
5. Трудоемкость заказывания
6. Трудоемкость комплектования заказа

Есть несколько замечаний:
1. Основное: обычно под проблемами понимаются проблемы бизнеса в целом, а не конкретных заинтересованных лиц. "Трудоёмкость регистрации читателя"? Разве владельцу бизнеса должны быть интересны проблемы "негров"? Сотрудникам трудно регистрировать читателей? Да наплевать, если это не приводит к потере прибыли или снижению других важных показателей бизнеса. Надо задать вопрос что плохого в трудоёмкости регистрации читателей? Возможно клиенты уходят к конкурентам? Или из "министерства" грозятся уволить директора за плохие показатели? И как это отражается на достижении целей бизнеса, к чему приводит?
2. "Повторная регистрация", "Информация о наличии"... Это вообще непонятно что. Можно ли себе представить, что существует проблема "Информация о наличии"? Надо переформулировать.

Запросы заинтересованных лиц:
Обычно под этим понимаются самые первые необработанные источники:
1. Электронные письма (дословно).
2. Документы с "требованиями", как это понимает заказчик. Обычно "неструктурированный поток мыслей".
3. Протоколы совещаний.

Возможности:
В документе они больше похожи на варианты использования. Для того чтобы правильно настроиться на правильную формулировку возможностей (Features) я обычно вспоминаю маркетологов МВидео, Эльдорадо, Техносила. Они очень хорошо формулируют на уличных билбордах фичи различной электроники. Что-то типа:
1. Быстрая подготовка к работе.
2. Удобство использования.
3. Высокая производительность.
4. Развлечения и работа.

Системные требования:
Насколько я понимаю предполагается представление требований в виде вариантов использования. Есть следующие замечания:
1. Основная часть ВИ - сценарии основного и альтернативных потоков. В документе я не увидел пошаговых сценариев с описанием команд экторов и ответов системы.
2. "Проверка дублирования" и прочие подобные - это не варианты использования. Правильная формулировка предусматривает получение эктором некоторого сервиса от системы.


27
Эдуард, не за что:) Мне самому интересно чем всё это закончится. Если есть такая возможность, прошу выкладывать новые версии:)

28
Начнём с определений:
1. "Stakeholder need - The business or operational problem (opportunity) that must be fulfilled to justify purchase or use of the system." То есть это формулировка некоторой проблемы (потребности), с которой сталкивается кто-то из заинтересованных лиц в ходе своей работы и которую он хотел бы решить (или улучшить что-то в своей деятельности, воспользоваться некоторой возможностью).
2. "Feature - an externally observable service provided by the system that directly fulfills a stakeholder need." Некий сервис системы, который может полностью или частично решить проблему заинтересованного лица и обладает собственной значимостью для ЗЛ с точки зрения бизнеса.

Need (по вертикали):
"Автоматический расчёт зарплаты" - это не бизнес-проблема, а очевидно сервис, предоставляемый системой (Feature). Теперь надо задать вопрос... Какую бизнес-потребность конкретного ЗЛ решает этот сервис? Может быть этот сервис и не нужен совсем? Формулировка Need для главного бухгалтера, которому не нравится что зарплата рассчитывается слишком долго, может выглядеть примерно так: "Снижение времени расчёта зарплаты в 2 раза". У бухгалтера, который непосредственно вручную считает зарплату, формулировка может звучать немного по другому: "Избавление от обязанности по расчёту зарплаты".

Feature (по горизонтали):
"Администрирование данных о служащих" - это не Feature, поскольку не обладает собственной значимостью и не может удовлетворить подразумевающиеся бизнес потребности (Need). А вот в качестве Use Case как раз подойдёт. Трассировка может быть как раз на Feature "Автоматический расчёт зарплаты". То есть пока не заведёшь данные о служащих, не сможешь автоматически рассчитать зарплату.

29
Эдуард, добрый день!

Пока скажу об основной ошибке, которую я вижу в матрице. Need по смыслу больше похожи на Feature. А большинство Feature это скорее Use Case.

30
Цели не могут выполняться. Выполняться могут функции. Для начала определите цели создания системы. Чем наличие системы лучше её отсутствия. Потом уже определите функции, т.е. как система поможет конкретным экторам работать на достижение целей создания системы.

Страницы: « 1 2 3 4 5 6 7 8 9 »