Форум Сообщества Аналитиков
Дисциплины => Системный Анализ и Требования => Варианты Использования (Use Case) => Тема начата: bas от 08 Февраля 2008, 21:40:59
-
1. Столкнулся с такой ситуацией, что трудно\не_нужно применение ВИ для описания Пользовательских Требований (ПТ). А ситуация такая, что Система не будет иметь четко разделенных ролей. Т.е. будет один пользователь и у него будут набираться права из ф-ций Системы. Т.е. классическая ERP\CRM система без четко разделенных ролей. Т.е. даже если разделить все на ВИ, то получится бред с точки зрения Д, т.к. будет один пользователь и куча ВИ к нему.
2. Пришли к такому мнению, что Описывать ВИ не надо, а описать ПТ в виде иерархии и разбития по модулям. Шаблон для описания ПТ был выбран - шаблон для ВИ.
3. Как мне кажется не совсем плохой подход. Хочется даже сказать, чтобы многие новички использовали такую технику, т.к. многие не могут использовать правильно ВИ и ДВИ.
Что скажите?
-
Саша, немного сумбурно и не понятно.
Хотя в целом вопрос ясен. Итак, ты полагешь или констатируешь, что
1. есть некое не пустое множество функций в системе
2. есть некое непустое множество пользователей такой системе без четко выраженной роли
3. роль пользователя представляет собой абстракцию, определяемую текущим набором прав.
4. классификация ролей возможна, но не имеет смысла. Т.е. действительно некая группа пользователей может иметь одинаковый набор функций, но эта группа случайна и никак не определяет специфику роли
5. Одно из главных различий между вариантом использования и алгоритмом (функцией) заключается в том, что алгоритм (функция), который может содержать некоторую последовательность шагов, не будет (не должен) отображать диалог между пользователем и системой. Т.е. если функция системы (ERP-CRM) не отражает диалог пользователя с системой, то очевидно использовать ВИ не следует, в противном случае нужно писать вариант использования.
6. Поскольку функций в системе может быть много, они так или иначе могут быть классифицированы по типу и следовательно распределены по пакетам, так что большое количество ВИ на одной диаграмме не такая уж проблема. С другой стороны совершенно необязательно строить такую диаграмму, если она не целесообразна
7. ВИ не единственный инструмент описания требований пользователя. Для этого можно испрользовать пользовательские истории.
8. Для более детального анализа сказанного Сашей, хотелось бы увидеть все-таки некоторые примеры, поскольку пункт 3 неясен и не новичку (какую технику? почему автор полагает что такая техника возможна, как понять не ошибается ли автор в своих суждениях по данной теме?)
-
Эд,
Все верно. Это что-то среднее между Пользовательской Историей (ПИ) и ВИ. Как я представляю ПИ все-таки не структурируются, не живут долго и пишутся без особого шаблона и взаимосвязей. Мы же предполагаем опираться на эти ПТ как на одни из основных требований на данный момент и в будущем, и если же надо будет их детализировать, то будет это делать с помощью функц. треб. (ФТ).
Пример, ну самый простой - Справочники:
* Редактировать справочник
Сценарии:
- Просмотреть
- Добавить
- Удалить
- Редактировать
- Копировать
** Редактировать Категорию товара
** Редактировать свойства Товара
** ....
* - означает корневое ПТ
** - означает детализацию ПТ (в частности тут наследие используется)
-
Саша, я думаю ты находишься под впечатлением RUP или другой методологии. Вариант использования - это и есть пользовательская история. Разница лишь в акцентах.
ВИ допускает любую форму описания и неформальную и формальную - способ записи зависит от процесса или стратегии разработки.
Однако спорить не буду.
Перечисленные тобой функции - совершенно не ВИ, а лишь части ВИ. Например ВИ : Управления справочниками - типичный CRUD ВИ и ничего более. Есть даже целый проработанный шаблон где указывается пользователь и два ВИ: CRUD и X information
-
Пользовательские требования рассматривают систему с перспективы самого пользователя и тех бенефитов\целей которые он имеет по отношению к системе. Если возможных вариантов использования очень много и нельзя выделить конкретный ВИ, думаю имеет смысл сосредоточится на функциональных требованиях.
-
Перечисленные тобой функции - совершенно не ВИ, а лишь части ВИ. Например ВИ : Управления справочниками - типичный CRUD ВИ и ничего более. Есть даже целый проработанный шаблон где указывается пользователь и два ВИ: CRUD и X information
Эдуард, а как же описывать такой вариант использования?
Например, есть вариант использование "Управление справочниками", который, по вашему, включает в себя функции (шаги) создание, удаление, редактирование справочника. Это очень громоздкий ВИ с кучей альтернативных потоков. Имхо, каждая операция CRUD - это отдельные ВИ, потому, что она содержит в себе различные действия, вызываются различные формы пользовательского интерфейса.
Может я и не прав, но в проекте, в котором я участвую, ситуация аналогична той, что у Александра.
Система (аналог ECM) не имеет как такового пользователя (отдельного актора), а имеются лишь наборы прав (роли), которые позволяют пользователю использовать различные услуги системы.
Получается, что основные варианты использования такой системы это управление каталогами, управление таксономией, управление контентом, управление правами пользователя и др. Мы же сделала описанное выше пакетами ВИ, каждый из которых состоит из ВИ создать, удалить, отредактировать и т.д. Получается такой подход не правильный?
-
Виталий,
Это будет уже не ВИ, ВИ - это в первую очередь цель пользователя, ну какая цель в удалении Справочника, если его даже еще нет?
В том то и дело, что это уже не ВИ, это больше ПИ, но описанные в виде шаблона ВИ, что мне показалось очень удобно.
Юра,
А чем тебе не нравится подход, кот. я предложил?
-
Эдуард, а как же описывать такой вариант использования?
Получается, что основные варианты использования такой системы это управление каталогами, управление таксономией, управление контентом, управление правами пользователя и др. Мы же сделала описанное выше пакетами ВИ, каждый из которых состоит из ВИ создать, удалить, отредактировать и т.д. Получается такой подход не правильный?
Виталий, во-первых, ВИ - это некое удобное средство, возникшее в результате практики. Это не математическая концепция или физический закон. Потому, естественно, Вы используете это так, кк считаете нужным. Но следует прислушаться к мнению специалистов, которые пришли к такому решению
Вот описание CRUD Ви из книги Gunnar Övergaard, Karin Palmkvist. Use Cases Patterns and Blueprints
Intent
Merge short, simple use casessuch as Creating, Reading, Updating, and Deleting pieces of information into a single use case forming a conceptual unit.
Keywords: Create data, delete data, information handling, merge use cases, read data, short flow, short use case, simple operation, update data.
Patterns
CRUD: Complete (см. ris1)
Description
The CRUD: Complete pattern consists of one use case, called CRUD Information (or Manage Information), modeling all the different operations that can be performed on a piece of information of a certain kind, such as creating, reading, updating, and deleting it.
Applicability
This pattern should be used when all flows contribute to the same business value and are all short and simple.
Type
Structure pattern.
CRUD: Partial
Model (см. ris2)
Description
An alternative pattern models one of the alternatives of the use case as a separate use case.
Applicability
This pattern is preferable when one of the alternatives of the use case is more significant, longer, or much more complex than the other alternatives.
Type
Structure pattern.
Discussion
Quite often systems handle information that, from the system's viewpoint, is very easily created in the system. After a simple syntax or type check, and perhaps some trivial calculation or business-rule check (see Chapter 16, "Business Rules"), the information is simply stored in the system. No advanced calculations, verifications, or information retrieval will have to be performed. The description of the flow is only a few sentences long, and there are probably not more than one or two minor alternative paths in the flow. Reading, updating, or deleting the information are equally simple operations. Each of them can be described in a few sentences.
Should such operations be modeled as use cases and, if so, must they be included in the use-case model? The answer to both questions is yes. They are indeed use cases because something is to be performed in the system; someone is to use the system to create (read, delete, update) some piece of information in the system. Moreover, they must be included in the use-case model, or the model will not be complete. If these use cases are not included in the model, some stakeholder will probably miss them; otherwise, the functionality should not have been included in the system in the first place.
Luckily, this does not necessarily mean that this kind of functionality should be expressed as separate use cases. Instead, according to the CRUD: Complete pattern, we group them together in so-called CRUD use cases, including all four types of operations on some kind of informationcreation, reading, updating, and deletion of any such information.
This procedure has a few obvious advantages. First, the size of the model will be reduced, which will make it easier to grasp because the number of use cases will be reduced. Second, nobody will be interested in a system containing only a subset of these use cases (for example, read and delete, but not create and update). Grouping these flows together in a single use case called something like CRUD X ensures that all four are included in the model, and makes it clear to every reader of the model that this is the use case where all this functionality is captured. Third, the value of each of the separate use cases is very small (if any) for the stakeholders; it is the whole collection of them that gives a value to the stakeholders. Together these use cases form one conceptual unit (see Figure 20.1).
Note that if only some of the four operations are simple while others are complex, you can group the simple operations into one use case and let the other ones be modeled as separate use cases, according to the CRUD: Partial pattern.
Note also that this is a typical situation where a use case does not have only one basic flow. None of them can be said to be more "basic," or "normal," than the others. Therefore, a CRUD use case will typically have four basic flows, and possibly a few alternative flows, as is shown in the following example.
An instance of a CRUD use case will perform either a creation, a reading, an updating, or a deletion, and after that it will cease to exist. This instance will not continue to live and wait for the next operation to be performed. That operation will be performed by another instance of the same use case.
A so-called CRUD use case may of course include other (basic) flows than the four common ones, such as searching for an item, or performing some simple calculation based on an item.
It is important not to merge advanced or complex operations into one use case. They should remain separate use cases instead, because they will probably be developed, reviewed, designed, and implemented separately.
As a general rule, when not sure whether to merge the different usages into one use case or to keep them as separate use cases, they should no doubt be kept apart. This decision will not affect the functionality of the system, only the model structure and hence its maintenance.
Example
This section provides an example of the CRUD: Complete pattern. It models the registration of a new task to be performed sometime in the future, the modification of a registered but not performed task, the cancellation of such a task, and the presentation of tasks that either failed during their execution or have not yet been performed (see Figure 20.2). As you can see, the four different alternatives are quite simple and short, and they are expressed as four basic flows, because none of them can be said to be superior to the others. Therefore, this is an application of the CRUD: Complete pattern even if some of the four basic flows in this case are different from the standard ones.
см ri3. The CRUD Task use case models the creation, modification, presentation, and cancellation of a task.
Error handling and exceptional flows are expressed as alternative flows of the use case.
The Item Look-Up and the Future Task blueprints are also useful in this example.
Use Case: CRUD Task
Brief Description
The use case registers, modifies, or cancels the information about a task to be performed as stated in information received from the Task Definer.
Basic Flow
The use case has four different basic flows:
Register Task
Modify Existing Task
Cancel Task
View Tasks That Failed
REGISTER TASK
The use case starts when the Task Definer chooses to register a new task. The use case presents a list of possible kinds of tasks to the Task Definer, and asks what kind of task is to be registered, what name it is to be assigned, and when it is to be performed.
The Task Definer enters the required information. The use case checks whether the specified time is in the future and whether the name of the task is unique.
The use case registers a new task in the system and marks the task as enabled.
The use case ends.
MODIFY EXISTING TASK
The use case starts when the Task Definer chooses to modify an already registered task. The use case retrieves the names of all the tasks not marked as active and presents them to the Task Definer.
The Task Definer selects one of the tasks. The use case retrieves the information about the task and presents it to the Task Definer.
The Task Definer modifies any of the presented information except the name of the task.
The Task Definer accepts the information. The use case checks whether the specified time is in the future and, if so, stores the modified information.
The use case ends.
CANCEL TASK
The use case starts when the Task Definer chooses to cancel a task. The use case retrieves all the tasks not marked as active.
The Task Definer selects one of the tasks. The use case retrieves the information about the task and presents it to the Task Definer.
If the Task Definer confirms the cancellation, the use case removes the task; otherwise, no modifications are made.
The use case ends.
VIEW TASKS THAT FAILED
The use case starts when the Task Definer chooses to view a list of all the tasks that have failed. The use case collects all the tasks with the status failed and presents their names to the Task Definer.
The use case ends.
Alternative Flows
CANCEL OPERATION
The Task Definer may choose to cancel the operation at any time during the use case, in which case any gathered information is discarded, and the use case ends.
INCORRECT NAME OR TIME
If the name of the task is performed not unique or the time is not in the future, the Task Definer is notified that the information is incorrect and is requested to re-enter the incorrect information.
The Task Definer re-enters the information. The flow resumes where the check of the information is performed.
Analysis Model
The analysis model of a CRUD use case is based on all the flows of the use case. It must include the realization of all the basic flows as well as the realization of the alternative flows.
However, because the flows are quite simple in this case, the model usually contains one boundary class for presentation and modification of the information, one control class to handle any checks, and one entity class (or perhaps a few) to store the information (see Figure 20.3). The flow starts in the System Form when the Information User requests to create, read, update, or delete the information. An instance of the Information Handler is created, which opens an instance of the Information Form to the Information User.
см. ris4. An analysis model of a CRUD use case.
Depending on the chosen operation, the actor enters information about a new piece of information, or the Information Handler retrieves existing information and asks the Information User via the Information Form to select one item. The Information Form sends the new information or the identity of the selected item, respectively, to the Information Handler which performs the chosen operation. Finally, the Information Form and the Information Handler are removed and the use case ends.
-
Мы же предполагаем опираться на эти ПТ как на одни из основных требований на данный момент и в будущем, и если же надо будет их детализировать, то будет это делать с помощью функц. треб. (ФТ).
Виталий,
Это будет уже не ВИ, ВИ - это в первую очередь цель пользователя, ну какая цель в удалении Справочника, если его даже еще нет?
В том то и дело, что это уже не ВИ, это больше ПИ, но описанные в виде шаблона ВИ, что мне показалось очень удобно.
Александр, действительно хорошая идея.
Проводя аналогию с тем, что делаю в своем проекте, прихожу к выводу, что мы с Вами столкнулись с одной и той же проблемой. А именно, как описывать пользовательские требования для "инфраструктурных" систем, т.е. систем которые не несут как таковую бизнес-логику для пользователя, а предоставляют некоторый функционал, который пользователь будет использовать для построения необходимой для него логики.
Например, из различных функций (создать каталог, добавить файл, послать сообщение) будет выстраиваться некий процесс, который уже имеет смысл для пользователя, т.е. ЦЕЛЬ.
Тогда получается, что в данном случае от варианта использования остается лишь каркас, для удобного описания и представления этих так называемых ПТ?
У нас следующий подход:
1. Мы описываем функционал (можно наверное назвать его ПТ) используя ДВИ (см. файл)
2. Далее каждую функцию описываем в виде сценария и/или диаграммы деятельности (ДД)
3. Анализируя, получаем классы анализа
4. Действия из ДД дробятся на более детальные функции системы (мы называем их системными функциями)
5. Создаем диаграммы последовательности используя полученные системные функции
6. Распределяем системные функции по компонентам системной архитектуры (трехслойная по Фаулеру). Многие системные функции как у нас получилось используются в нескольких ПТ.
Если я правильно понял, Александр, Вы предлагаете именно такой подход, только называя это другими именами.
Мы тоже называем их не ВИ, а функциональными узлами (operational nodes), т.к. используем MODAF.
Эдуард, спасибо за подсказку. Теперь понимаю свою ошибку. :)
-
Виталий и Саша, а чем Вас не устраивает обычная техника описания функциональных требований, например, которая приведена у Вигерса?
Кстати, у Ливенгуэлла приведены достаточно понятные аргументы когда имеет смысл, а когда нет использовать варианты использования.
Хотя, мне кажется, неважно что и как Вы используете, главное, если внутри команды есть понимание, то значит все окей.
-
Виталий,
Мы предполагаем использовать примерно такой подход как Вы описываете. Только не надо их называть ВИ и делать ДВИ, в последней ИМХО нет смысла, да и не правильно это. Возможно надо посмотреть SysML, мне кажется там можно делать Д из требований.
Эд,
Ну то, что мы описываем, есть именно ПТ, не ф-ые. Т.е. это некий сценарий между Пользователем и Системой, это не только то что делает Система.
Вообще у меня есть идея как-то оформить этот подход и назвать это как - Пользовательский Сценарий.
Мне хотелось проверить, что я не изобретаю велосипед ...
-
Наткнулся в интернете на книжку по управлению требованиями
(http://www.ibmpressbooks.com/bookstore/product.asp?isbn=0321383001).
Так как книга новая, я не смог ее найти в электронном виде (может плохо искал :)).
Дак вот, автор предлагает добавить в пирамиде иерархии требований, ниже ВИ, еще и сценарии. Это конечно, обычный РУПовский подход, но мне показалось, что можно прикрутить его к текущей ситуации, т.е. под вариантом использования понимать, например, управление справочником, а под сценариями - создание, удаление, копирование и др.
Вобщем почитайте, если интересно (см. аттач)
-
Виталий, на мой взгляд в книге нет ничего принципиально нового.
Что такое ВИ. Это некоторая спецификация целевого использования пользователем системы. Т.е. ВИ определяет цель использования системы. Реализация такого использования в рамках одной цели может приводить по сути к разным результатм: успешное достижение цели или неуспешное, либо частичное.
ВИ описывает некоторое множество возможных сценариев, путей протекания ВИ. ВИ как минимум состоит из основного потока(сценария) и альтернативных потоков(сценариев). Метафора штанов у Коберна.
Каждый сценарий (будучи реализованный) естественно требует тестирования его реализации
-
Предлагаю продолжить дискуссию, п.ч. о чем я говорю, многим кажется спорным.
Прикладываю свой доклад на РИТ для этого.
-
Предлагаю продолжить дискуссию, п.ч. о чем я говорю, многим кажется спорным.
Прикладываю свой доклад на РИТ для этого.
Александр, если можно опишите кратко по пунктам основные отличия ПС от ВИ, а то я немного запутался 8)
Если различие только в том, что для описания ПС мы не используем диаграммы, то это еще не говорит о том, что это не ВИ
Вигерс, кстати называет ВИ - именно пользовательскими требованиями, мне кажется что ВИ - это нечто среднее между пользовательскими требованиями и функц. требованиями, так как из них прослеживаются как те, так и другие.
Посмотрев сценарий описанного вами ПС, не увидел разницы с ВИ -> действие пользователя - ответ системы, как реакция на действие пользователя.
Единственное отличие в том, что в альтернативные сценарии представляют собой отдельный функционал, который является неким расширением основного функционала и под одним ПС собраны все функции, оперирующие конкретным объектом управления, например справочником
-
Прочитал доклад Александра. Соглашусь с Виталием. По-моему чистое нарушение принципа Оккама: не создавай сущностей сверх меры.
Представленные для обсуждения пользовательские сценарии по существу варианты использования в стиле Дуга Розенберга, о которых мы уже начали дискутировать в теме Розенберг против Коберна (http://www.uml2.ru/forum/index.php?topic=673.msg7711#msg7711). Замечу, что Розенберг указывает на то, что:
1. каждый шаг ВИ должен содержать объекты модели предметной области и названия форм, как вы полагаете их использовать
2. описание должно быть не более 8 шагов
3. такой стиль помогает лучше понять задачу программисту и лучше написать user guide.
Как мне кажется пользовательские сценарии в интерпретации Саши - и есть сосбтвенно user guide в действии
Понятие сценарий часто определяется как экземпляр варианта использования
Единственное отличие в том, что в альтернативные сценарии представляют собой отдельный функционал, который является неким расширением основного функционала и под одним ПС собраны все функции, оперирующие конкретным объектом управления, например справочником
Ну собственно тут говорится об описании CRUD ВИ
-
В общем ты написал кучу всего, что использовалось в моем подходе, я обобщил все это и предложил метод описания ПТ.
И еще принципиальное отличие ПС от ВИ, то что когда мы оперируем ПС, то вообще забываем о ВИ и выстраиваем иерархию ПТ с нужной глубиной как вам кажется правильно.
-
Внимательно посмотрел презентацию еще раз. Все-таки чего-то не догоняю. Может имеет смысл описать это в виде статьи на основе некоторого примера, и чтобы все преимущества проявились в этом примере?
-
Естественно, исходя из презентации наверное все не ясно, многое хотел сказать словами.
Наверное ты прав, надо написать статью.
-
Александр, описанный Вами сценарий, мне напомнил crud ВИ, приведенный Коберном в своей всем известной книге 8).
Посмотрите ВИ32 в книге коберна, помоему вы написали нечто похожее.
-
Еще раз говорю, что мы когда декомпозируем ПТ вообще НЕ ДУМАЕМ КАТЕГОРИЕЙ ВИ, т.е. целями Пользователей, а декомпозируем по ф-ти, по блокам, как-то еще ...
-
Саша, тогда не понятно зачем открывать велосипед, если он 100 лет открыт.
Иерархия требований существует давно. Стиль их описаний вполне конкретен. Используете ли вы сценарный тип ВИ или список - сути дела не меняет. На лицо функциональная декомпозиция.
Если принятый подход понятен команде и эффективен - это хорошо, но в чем приницпиальная разница, я не улавливаю
-
Принципиальная разница между чем и чем?? Приведи аналог описания ИМЕННО ПТ, похожий на мой.
-
Дык я не могу привести пример, поскольку не понимаю, что тут другого.
По моему типичные круд ВИ. От них принципиальная разница.
Ну вот пример пользовательских требований (и не только)
1. Книжный магазин должен быть реализован на базе web-технологий, но решение должно иметь достаточно гибкую архитектуру для обеспечения возможности разработки альтернативных внешних интерфейсов (Swing/апплеты, web-сервисы, и т.д.).
2. Книжный магазин должен быть способен продавать книги посредством заказов, принятых через Интернет.
3. Пользователь должен иметь возможность добавить книги в online торговую корзину, до контроля.
a. Точно так же пользователь должен иметь возможность удалить выбранные книги из корзины.
4. Пользователь должен иметь возможность управлять списками предпочтений книг, которые он или она хочет купить позже.
5. Пользователь должен иметь возможность отменить заказы прежде, чем они будут отправлены.
6. Пользователь должен иметь возможность совершить оплату кредитной картой или платежным поручением (банковским переводом).
7. Пользователь должен иметь возможность возвратить книги.
8. Книжный магазин должен быть встраемым в вебсайты партнеров, используя миникаталоги, которые получают из полного главного каталога, хранимого в центральной базе данных.
a. Миникаталоги должны быть определены в XML-формате, поскольку они будут переданы между этим и (позже, чтобы быть определенными) внешние системы.
b. Система выполнения доставки должна быть выполнена через Веб-службы Амазонки.
9. Пользователь должен иметь возможность создать учетную запись клиента, так, чтобы система запоминала детали пользователя (название, адрес, детали кредитной карты) при его входе в систему.
a. Система должна поддержать список учетных записей в своей центральной базе данных.
b. Когда пользователь вошел, его пароль должен всегда соответствовать паролю в сводном списке учетных записей.
10. Пользователь должен иметь возможность поиска книги в соответствии с различным методами поиска: по заголовку, по автором, по ключевому слову, или категории - и затем изучить детали книги.
11. Пользователь должен иметь возможность отправить отзыв на понравившиеся книги; комментарии
должны появляться на экране деталей книги. Обзор должен включать оценку клиента (1-5), которая обычно отображается рядом с заголовком книги в списке книг.
a. Рецензии на новую книгу должны модерироваться то есть быть проверенными и одобренными представителем персонала прежде, чем они будут опубликованы на вебсайте.
b. Более длинные отзывы должны быть урезаны при отображении на экране деталей книги; клиент может
изучить полную версию отзыва на отдельной странице.
12. Должна существовать возможность для персонала публиковать рецензии редактора книг. Они должны также
отображаться на экране деталей книги.
13. Книжный магазин должен позволить сторонним продавцам (например, книжные магазины second-hand) добавлять их собственные индивидуальные книжные каталоги. Они добавляются в сводный каталог книг так, чтобы книги этих продавцов включались в результаты поиска.
14. Книжный магазин должен быть масштабируемым, со следующими определенными требованиями:
a. Книжный магазин должен быть способным к поддержанию учетных записей пользователя вплоть до 100 000 клиенты за его первые шесть месяцев, и затем дальнейшие 1 000 000 после этого.
b. Книжный магазин должен быть способным к обслуживанию до 1 000 пользователей одновременно (10 000 после шести месяцев).
c. Книжный магазин должен иметь возможность выполнять до 100 запросов поиска в минуту (1,000/минута после шести месяцев).
d. Книжный магазин должен иметь возможность выполнять до 100 покупок в час (1,000/час после шести месяцев).
-
аааааааааааааааааа, буду бить :)
Ну не ВИ это, там просто пример в презентации не совсем верный
-
аааааааааааааааааа, буду бить :)
Ну не ВИ это, там просто пример в прицентации не совсем верный
будешь бить или будут бить?
чего там в прицентации не совсем верное?
Саша - ты вроде аналитик - выражай мысль однозначно, а то не поймешь тебя приходится догадываться :)
-
Что такое ВИ? ВИ - это в первую очередь цель пользователя по отношению к системе. Т.е. чтобы правильно выявить ВИ нам нужно правильно сформулировать цели, которые далее станут ВИ.
Для начинающего аналитика правильно выявить цели и следовательно обозначить правильно ВИ трудно и требует значительных навыков и тренировки. Вот что получается когда человек пытается выявить ВИ: http://www.uml2.ru/forum/index.php?topic=286.0
Т.е. начинающие аналитики могут хорошо декомпозировать функционально, но не могут декомпозировать цели. С другой стороны подход описания ПТ в виде сценария (т.е. сам шаблон ВИ) очень удобен и понятен с одной стороны разработчику и аналитику, а с другой стороны заказчику.
Вот как раз мой подход скрещивает две вещи - функциональную декомпозицию ПТ и шаблон описания ПТ в виде облегченного шаблона сценария ВИ. Тем самым получим новый (модифицированный) подход в описании ПТ
Фуф, вроде все. Если и так не понятно, то я тогда не заню как объяснить ....
-
Окей, Саня, (блин хорошее у тебя имя - столько в нём разнообразия)
Мысль твоя понятна, понята и принята.
Правда не вижу нового на самом деле - типичное использование функционального подхода. Я подобное объясняю при преподавании DFD и IDEF0.
Т.е. имеем иерархию функции или процессов. Ну аналог твоей иерархии ПТ по сути. Декомпозиция упирается в миниспецификацию, которая может описываться с использованием:
1. описаний на естественном структурированном языке
2. с помощью языков программирования
3. с помощью визуальных блок-схем
4. с помощью таблиц и деревьев решений
правило такое - описание не должно превышать 20-30 строк (и то много), должно быть простым - т.е. следование ветвление цикл
С другой стороны ПТ- разве не задача пользовтеля и его цель от использования системы.
Насколько можно судить - Коберн как раз указывает на естественность определения цели и описание ее достижения в виде сценария. Пример Наташи не показательный: она нуждалась в сдачи курсовой, а не приобретение навыков, хотя к ее чести надо сказать, что работала она очень настойчиво и скурпулезно.
Так или иначе твой подход имеет место быть и безусловно нуждается в описании, примерах и пропаганде :)
-
Интересная ситуация. Я подумал, что если передо мной поставить задачу описать пользовательские требования для текстового процессора типа word, я знаю как это сделать используя подход Александра или используя форму ФТ и совершенно теряюсь как это сделать с помощью ВИ (CRUD ВИ).
Эд, не могли бы вы в качестве примера написать текст ВИ для текстового редактора типа word. (буквально 10 строчек, так чтобы было понятно, как они в принципе будут выглядеть)
-
Интересная ситуация. Я подумал, что если передо мной поставить задачу описать пользовательские требования для текстового процессора типа word, я знаю как это сделать используя подход Александра или используя форму ФТ и совершенно теряюсь как это сделать с помощью ВИ (CRUD ВИ).
Эд, не могли бы вы в качестве примера написать текст ВИ для текстового редактора типа word. (буквально 10 строчек, так чтобы было понятно, как они в принципе будут выглядеть)
Думаю, что для ПО типа word требования имеет смысл описывать в формате иерархического списка. А ВИ могут быть использованы для описания специфических задач пользователей. Скажем так, можно сделать ВИ типа "Создать документ" и вариантивность спрятать в слотах типа "Вариации технологий и данных", "Дополнительные требования" и т.п. ... но зачем прилагать такие усилия? Только для демонстрации того, что ВИ можно использовать и в этих целях?
-
Способы применения и роли вполне можно применить для MS Word, чтобы иметь верхнеуровневый контекст, организованный по целям пользователям. Вообще работа от целей, как вы понимаете, здорово помогает строить развитие продукта эффективно.
Я бы вообще начал с бизнес-процесса, затем задействовал способы применения, а потом перешёл на уровень простых атомарных ФТ и слотов вариаций способа применения.
-
Кроме того, способ применения — это единица планирования в итерационной разработке, тебе ли этого не знать, Юра. Поэтому и организация требований по способам применения — это не блажь, а способ разрезать функциональность на такие куски, чтобы каждый из них давал пользователю некоторый полезный для него результат, что важно для итерационной разработки.
-
По поводу нужности UC.
IMHO UC - это не просто артефакт, а способ мышления и работы. Они заставляют продумать и зафиксировать, что нужно actor'у, и как он будет это делать с помощью системы, а потом поделиться этим пониманием, и, как уже сказал Денис, строить и учитывать работу по UC. Это способ связать ответы на вопросы "зачем", "что" и "как". Вне зависимости от кол-ва actor'ов.
Наверное, если взаимодействие с пользователем - очень простое, а разработчики уже многократно делали подобные вещи "в лучшем виде" (и их, разработчиков, немного), то детально фиксировать взаимодействие с пользователем не обязательно, но вот цель этого взаимодействия - всё равно нужно. Тем более, что сложность взаимодействия с пользователем имеет свойство увеличиваться в следующих версиях. Пример - утилиты командной строки в unix/linux.
Про UC для MS Word: IMHO это ничего себе задача. Тех же actor'ов там много. Только из первичных - навскидку, оператор, VBA-программист, OLE. И целая серия вторичных, от clipart на узле MS до получателя электронной почты mail merge. И каждый раздел стандартного ribbon'а - это минимум один низкоуровневый UC, типа "настроить шрифт текста" или "CRUD таблицу".
-
Я задавал вопрос потому, что так и не понял убедил ли Эдуард в итоге Александра, что "Пользовательские Сценарии" являются избыточным понятем. В качестве примера я предлагал рассмотреть Word, для того, чтобы самому сделать вывод, нужны ли мне "Пользовательские Сценарии"
Юрий, спасибо за предложенный вариант со слотами ВИ, к сожалению я сейчас ничего не могу сказать по этому поводу, мне нужно разобраться что такое "Слоты ВИ". Если это помимо всего прочего, возможность создавать иерархию сценариев в рамках одного ВИ, то, похоже, действительно, без "Пользовательский Сценариев" вполне можно обойтись.
По поводу того, зачем пытаться искусственно натягивать требования на форму ВИ - тут я согласен с упоминавшимся мнением, что ВИ - это еще и способ мышления. Собственно, ВИ предрасполагает все время отталкиваться от целей пользователя, что позволяет избегать некоторых проблем, например, YAGNI ("Не факт, что это вам понадобится").
Насчет Word, да, пожалуй, я переборщил. Для того, чтобы понять чем можно заменить "Пользовательские Сценарии" достаточно было бы WordPad.
В итоге, являются ли слоты ВИ средством, заменяющим "Пользовательские Сценарии"?