Показаны сообщения с ярлыком use case. Показать все сообщения
Показаны сообщения с ярлыком use case. Показать все сообщения

суббота, 10 сентября 2011 г.

Перемен требуют наши сердца

Если бы Putcha (Venkata) Narasimham, владелец и профессор, знал бы слова популярной песни, гимна 80-х, Виктора Цоя, он тоже назвал свою тему примерно так же. Но он не знает, а потому и назвал тему Time to rename Use Case and Use Case Description? К сожалению не могу расшарить дискуссию в группе. Она доступна только членам USE CASE PROFESSIONALS.

Уважаемого мною Пушту сподвигло на это, то, что название термина "use case" малопонятно начинающим, не несет в себе нужной семантической ясности. Потому пришла пора подумать о замене этого термина более приличествующим случаю. Господин Нарасимхам предлагает заменить термин Use Case на BizGoal и ApGoal (что-то в вольном переводе бизнес-цели и системная цель?), а Use Case Description на GoalDialog или DialogGoal.

В дискуссию вступил John Watson, человек лично знакомый с Ивором Якобсоном. Он подверг критики начинание Пушты, но согласился, что лучше бы термин Use Case остался в своем первоначальном виде Usage Case. Хотя так же он заметил, что важнее не сам термин, как стандартизация определения, что есть этот термин:
While I support a name change from Use Case to Usage Case I think it is very much more important to lobby OMG to provide a standardised definition of what a Usage Case is.
Профессор Нарасимхам, как истинный благородный муж, стоит на своем и призывает придумать более понятный термин. Он аргументирует, защищая позицию не ИТ-специалиста: термин use case понятен айтишнику, потому как он изучал UML, но UML сложен и непонятен простым смертным. В то же время это такой богатый язык и инструмент моделирования, что грех не использовать его в других областях, не только в ИТ. Просто, по мнению Пушты, язык UML и в частности UC и UCD не достаточно стандартизированы. Было бы правильным осуществить и упрощение и стандартизацию UML, приближая ее к таким стандартам как ИСО9000.

Мое мнение я выразил в дискуссии примерно следующим образом: ребята , у нас тоже есть своя заморочка с определением. Правда, нам все равно, будет ли это называться Use Case, или Usage Case, или еще как, все равно наши переводчики его переведут по-своему, а мы, народ привычный, будем смотреть не на термин, а в корень - т.е. каково разъяснение этого термина.

Например BABOK его объясняет так:
An analysis model that describes the tasks that the system will perform for actors and the goals that the system achieves for those actors along the way
На мой взгляд совершенно не понятно о чем идет речь :) А вы как полагает?

суббота, 3 сентября 2011 г.

Советы по наименованию вариантов использования

Оригинал статьи: How to Write Good Use Case Names – 7 Tips

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

Цели именования вариантов использования
При определении имени или названия для варианта использования перед вами стоят следующие цели:

  • Четко указать цель пользователя, представленную вариантом использования
  • Избегать описания аспектов проектирования и реализации
  • Сделать так, чтобы люди захотели читать это вариант использования, а не испытовали страх перед чтением его
  • Предусмотреть возможность изменения варианта использования в новых релизах
  • Определить границы проекта
  • Писать согласовано
Типичные ошибки вариантов использования
Ранее была написана пар статей, в которых нами были определены 10 ошибок вариантов использования. Вот они:
  • Несогласованность
  • Некорректность
  • Неверные приоритеты
  • Намеки реализации
  • Разрыв прослеживаемости
  • Непредвиденные ошибочные условия
  • Пропуск реакции (отклика) системы
  • Неопределенные действующие лица
  • Непрактичные варианты использования
  • Варианты использования за рамками области определения
Правильные имена для вариантов использования помогут избежать ошибок в согласованности, намеков на реализацию, проблем с управлением границ проекта, прослеживаемости. Они также должны способствовать тому, чтобы люди хотели их прочитать. Если название варианта использования будет как заголовок статьи в журнале - вы захотите его прочитать или будете стремиться избежать этого?

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

Советы по написания правильных названия вариантов использования

Вот несколько наилучших рекомендации, собранных по всему Интернету:

  • Правильные названия вариантов использования отражают цель пользователя. Правильное название варианта использования отражает цель пользователя или внешней системы. Название типа "Обработать счета-фактуры" не говорит нам, что нужно сделать - собрать, организовать, произвести аудит или выполнить какие-то другие действия над документами. Более понятным было бы название "Собрать просроченные платежи от клиентов". Целью в данном примере будет сбор платежей от клиентов-должников. Второй вариант названия существенно лучше передает то, что нужно сделать пользователю в ходе выполнения этого варианта использования.
  • Правильные имена вариантов использования должны быть по возможности максимально краткими. Некоторые полагают, что название не должно содержать более 5 слов, а лучше не более двух. Однако существует масса примеров, когда применение ограничение на количество слов в названии непрактично. В предыдущем примере: "Собрать просроченные платежи от клиентов" - какие слова вы бы удалил без потери смысла?
  • Правильные имена вариантов использования используют информативные глаголы. Обычно люди считаю, что мы должны отдавать предпочтение сильным глаголам, а не слабым. Это типичные рекомендации в отношении письма. Однако при написании вариантов использования мы можем быть более конкретными. Бессмысленным будет тот глагол, который указывая на действие, не определяет его достаточно подробно и понятно.  "Обработать заказ" может быть улучшено, используя более информативный глагол. "Проверить заказанные товары" делает понятным, чего пытается достичь пользователь в этом варианте использования.
Приведу перевод следующих двух рекомендаций. Следует заметить, что в реальной практике русского языка эти рекомендации вряд ли применимы.
  • Правильные имена вариантов использования используют действительный залог. Призыв к действию является признаком хорошего письма. Использование активного залога вдохновляет больше, чем действие в страдательном. Сравните: "Рассчитай рентабельность" и "Рентабельность рассчитывается".
  • Правильные имена вариантов использования используют настоящее время. "Создай новую учетную запись" в настоящем времени. "Новая учетная запись была создана" в прошедшем. Настоящее время подразумевает то, что пользователь пытается сделать, а не то, что уже было сделано. 
Вместо них я ввожу другое правило:
  • Правильные имена вариантов использования начинаются с глагола в неопределенной форме или с отглагольного существительного. Сравните: "Записаться на курс" или "Запись на курс". Использование той или иной формы, дело предпочтений. Однако использование неопределенной формы дает большей определенности, чем отглагольное существительное. В моем примере "Запись" можно воспринять как сущность, а не действие. Кроме того "Записаться на курс" легко выводится из такой фразы: "Студент обращается к системе, чтобы записаться на курс" или "Студент желает (хочет) записаться на курс".
  • Правильные имена вариантов использования не содержат действующих лиц. Некоторые люди предпочитают включать имя действующего лица в вариант использования, поскольку это является более конкретным. Однако следует учесть возможность изменения действующего лица для одного и того же варианта использования в разных релизах. Например, "Ранжировать сотрудников по производительности". В первом релизе, эта функциональность определена для супервизиров, которые могут ранжировать своих штатных сотрудников. Во втором релизе, добавлена возможность делать это для менеджеров, которые могут управлять несколькими супервизорами. Предпочтительно иметь две версии одного и того же варианта использования "Ранжировать сотрудников по производительности", чем два варианта использования "Ранжировать прямых/косвенных сотрудников по производительности". 
  • Правильные имена вариантов использования являются согласованными. Следует всегда применять один и тот же набор правил для всех наших названий вариантов использования. Непоследовательное применение правил будет создавать ощущение диссонанса для читателей. Согласованные названия более удобны для читателей, и обеспечивают чувство сплоченности для всего проекта
Другие ссылки:
Правильные названия вариантов использования не будут занимать много усилий, как только  вы приобретете навык писать их в согласованном стиле, следуя предложенным выше рекомендациям. Правильные названия дают ряд преимуществ будущем при просматривании и чтении вариантов использования. Правильные имена - короткие, ясные и стильные. Они побуждают нас прочитать вариант использования, помогают нам понять и помнить какова цель пользователя.

понедельник, 29 августа 2011 г.

Узелок на память 2

Как писать хорошие названия для вариантов использования

Причина появление этого поста описана на форуме: Именование вариантов использования.
Ничего не ново под луной. Где-то в темах форума мы уже обсуждали, что именовать варианты использования нужно с позиции пользователя, а не с позиции функции исполняемой системой.
Тем не менее с удивлением обнаруживаю, что мой коллега профессор Путча (Путша) из Индии настаивает, что именно так и правильно- именовать варианты использования как функция (у него сервис) системы. Подробности читайте в теме  Именование вариантов использования