Просмотр сообщений
В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.
Вы сначала потренируйтесь в ситуационном анализе, установите факты, выявите проблемы, определите цепочку последствий, причины.Ден, у тебя есть методика по ситуационному анализу. Пусть в кратком варианте? Этот вопросе не в рамках обсуждаемой темы, но интересно.
Затем сформулируйте цели, критерии успеха.
Обычно сначала формулируются фичи, а уже потом по каждой фиче выделяются UC. Вы же утверждаете, что у вас наоборот. Странно.
Если вы опускаетесь ближе к "неграм", то тогда это уже не Problem Statement, а Stakeholder Need. В таком случае лучше придерживаться устоявшейся терминологии и назвать эти сущности потребностями (Need). "Избыточная трудоёмкость..." более интересно звучит, но если это всё-таки потребность, то я сформулировал бы примерно так: "Снизить время, необходимое на регистрацию читателя до 5 минут".Потребность проистекает из проблемы. Избыточная трудоемкость - это проблема, некоторый недостаток, то что хочется поменять. Не не может формулироваться как потребность в избыточной трудоемкости, но как потребность в ее устранении. Такая связь может объяснить почему возникла такая потребность.
Если я правильно понял из описания, то:Если считать потребность, то такая формулировка мне нравится. Но тут нужно помнить - краткое именование потребности и ее расширенное описание.
"Информация о наличии" -> "Необходимо иметь возможность в течение 30 секунд получать информацию о точном местонахождении невыданного экземпляра книги."
Почему невозможно смоделировать запросы ЗЛ? У вас же есть описание задачи? Это уже запрос ЗЛ. Если разделить его на 2 документа, можно оформить их как протокол совещания, e-mail и т.п.Это требует времени, у меня его нет. Исходные описания задачи далеки от предлагаемого Вами
В предлагаемом Вами варианте предлагаю придерживаться терминологии из стандартов/методологий. Если это не запросы ЗЛ, то не надо использовать такой термин. Иначе можно запутаться.Мы этим и не пользуемся. Это пример консультанта-эксперта.
Если вариантов использования мало, то можно назвать фичи аналогично вариантам использования, но тогда исчезает образовательная ценность такого упражнения.
Студентам я бы показал как разделять функционал на высокоуровневые возможности.Именно это я и пытаюсь дать используя концепцию feature
К примеру для нескольких ВИ, таких как CRUDLS, можно сформулировать фичу как "Управление такими-то сущностями". Тогда хотя бы будет понятно, что отношение фич к ВИ это не 1-к-1, а 1-ко-многим.Этот момент мы рассматриваем когда переходим к анализу вариантов использования. Но в данной задаче это не имеет большого значения. Эта работа выполняется в другом курсе.
Зачем тогда называть вариантами использования то, что не является ими?У меня двоякое представление об этом, я с вами и согласен и нет. Это предложение эксперта, я в процессе его осмысления
ОК.
Согласен с Денисом. Так было бы гораздо интереснее. Но если сузить задачу, то...Это Ваше право
Но я не готов обсуждать это в данном случае, так как цели задачи иные.Давайте попробуем. Начнём в проблем:Вполне возможно, но в данном случае мы опускаемся чуть ниже к этим самым неграм. Соглашусь, что трудоемкость - как краткая формулировка мало понятна. Избыточная трудоемкость - лучше?
Есть несколько замечаний:
1. Основное: обычно под проблемами понимаются проблемы бизнеса в целом, а не конкретных заинтересованных лиц. "Трудоёмкость регистрации читателя"? Разве владельцу бизнеса должны быть интересны проблемы "негров"? Сотрудникам трудно регистрировать читателей? Да наплевать, если это не приводит к потере прибыли или снижению других важных показателей бизнеса. Надо задать вопрос что плохого в трудоёмкости регистрации читателей? Возможно клиенты уходят к конкурентам? Или из "министерства" грозятся уволить директора за плохие показатели? И как это отражается на достижении целей бизнеса, к чему приводит?
2. "Повторная регистрация", "Информация о наличии"... Это вообще непонятно что. Можно ли себе представить, что существует проблема "Информация о наличии"? Надо переформулировать.Полностью согласен. Хотя необходимость повторной регистрации в каждом филиале - явная проблема
. Какие бы Вы формулировки предложили?Запросы заинтересованных лиц:В данном случае, поскольку в рамка учебного курса невозможно смоделировать реальные запросы ЗЛ и взаимодействия с ними, то упрощается до формулировки предполагаемых потребностей, устраняющих проблему (concern - озабоченность) ЗЛ
Обычно под этим понимаются самые первые необработанные источники:
1. Электронные письма (дословно).
2. Документы с "требованиями", как это понимает заказчик. Обычно "неструктурированный поток мыслей".
3. Протоколы совещаний.
В документе они больше похожи на варианты использования. Для того чтобы правильно настроиться на правильную формулировку возможностей (Features) я обычно вспоминаю маркетологов МВидео, Эльдорадо, Техносила. Они очень хорошо формулируют на уличных билбордах фичи различной электроники. Что-то типа:Я согласен, что свойства к качеству должны быть заявлены, но где функциональные свойства? Естественно, если Вы запишите "ввод, изменение, удаление данных о.." разве это не будет функциональной возможностью, функцией, свойством будущей системы?
1. Быстрая подготовка к работе.
2. Удобство использования.
3. Высокая производительность.
4. Развлечения и работа.
Системные требования:Тут я следую рекомендациям моего эксперта. Это не сами прецеденты, это требования типа прецеденты, которые впоследствии будет развернуты в полноценные сценарии и диаграммы активности типа черный ящик.
Насколько я понимаю предполагается представление требований в виде вариантов использования. Есть следующие замечания:
1. Основная часть ВИ - сценарии основного и альтернативных потоков. В документе я не увидел пошаговых сценариев с описанием команд экторов и ответов системы.
2. "Проверка дублирования" и прочие подобные - это не варианты использования. Правильная формулировка предусматривает получение эктором некоторого сервиса от системы.
Чем "ведение БД о служащих" отличается от "Администрирования данных о служащих"? И что это за потребность такая - ведение БД?Ничем, это скажем так ошибка, неопытность.
Эд, а зачем так сразу переходить к трассировке проблем на возможности?Да вроде не очень спешим. Сначала заинтересованные лица, определения их возможных проблем, построение матрицы, изучение ее на полноту и непротиворечивость, избыточность и косячность.
Тема непростая, не надо так спешить и комкать, системный метод же не просто так придуман.
Эдуард, не за что:) Мне самому интересно чем всё это закончится. Если есть такая возможность, прошу выкладывать новые версии:)Я вообще-то надеялся, что студенты включаться в дискуссию.
Пока скажу об основной ошибке, которую я вижу в матрице. Need по смыслу больше похожи на Feature. А большинство Feature это скорее Use Case.
Вроде бы, восстановил. Если обнаружите отсутствие приложенных файлов или аватаров - дайте знать, пожалуйста.Спасибо
Не могу понять. В постах ссылок на картинки почему-то нет.Видимо нарушились ссылки на вложения. Смотреть в админку/ форум/ вложения и аватары /
Ага, спасибо, про постоянные ссылки я забыл. Исправил.А вот в чем собака порылась, а я не сразу и нашел. Надо тег {smfdisput} вытирать
А что не отображается в FAQ? Он сейчас, конечно, выглядит не так, как положено выглядеть FAQ, но все статьи туда перенесены:
http://www.uml2.ru/category/faq/
