Comments 13
В свое время (давнее) Writing effective use cases, которое читал в свободно выложенной допечатной версии просто перевернуло мои представления о правильном проектировании программ.
После прочтения этой книги я тоже взглянул по другому на постановку требований, но мой опыт написания и чтения сценариев по описанному принципу, очень затруднителен и не удобен. Гораздо удобнее использовать таблицу.
Для себя я вывел таблицу из трех столбцов: в первый столбец я записываю "Действие" (обычно это основное действующее лицо), во второй "Ответная реакция" (обычно это система), в последний столбец записываю "Пояснения": ссылки на нормативные документы или другие ограничения, (например по размеру передаваемых данных или времени на выдачу результата) и обязательно перечисляю возможные исключения.
Таким образом я всегда понимаю «у кого мяч» (как выразился бы Коберн), и могу понять, с какими проблемами можно столкнуться при реализации шага.
Для себя я вывел таблицу из трех столбцов: в первый столбец я записываю "Действие" (обычно это основное действующее лицо), во второй "Ответная реакция" (обычно это система), в последний столбец записываю "Пояснения": ссылки на нормативные документы или другие ограничения, (например по размеру передаваемых данных или времени на выдачу результата) и обязательно перечисляю возможные исключения.
Таким образом я всегда понимаю «у кого мяч» (как выразился бы Коберн), и могу понять, с какими проблемами можно столкнуться при реализации шага.
Спасибо. Указанный вами способ более нагляднее, но не создается фокуса на валидации — места возникновения исключений + сценариев их обработки или недопущения. В этом смысле он менее полный.
Немного не понял, на счет того, что нет фокуса места возникновения исключений. По мне так как раз у Коберна не понятно какие могут возникнуть проблемы при выполнении шага.
Так как читая основной сценарий не возникает вопроса, а что может пойти не так и только после того как читаешь полотнище дальше понимаешь, что все не так радужно как кажется на первый взгляд.
В своей форме я постарался сделать этот момент более наглядным.
Так как читая основной сценарий не возникает вопроса, а что может пойти не так и только после того как читаешь полотнище дальше понимаешь, что все не так радужно как кажется на первый взгляд.
В своей форме я постарался сделать этот момент более наглядным.
Пример моей формы записи сценария
О — проверки вписываются, так что фокус есть. В исходном тексте в Ответной реакции это не было ясно. Кстати, в указанном примере, неплохо было бы добавить правило проверки дублей, название — не очень удобный логический идентификатор + неясно является ли проверка обязательной, допускается ли наличие двух документов или нет. Это warning или error. Если error, то что идет дальше? Прерывание сценария = потеря клиентского ввода = потеря в терминах lean. По идее нужно предложить открыть старый документ, чтобы убедится что это дубль перед возможным прерыванием, только наталкивает на это мысль недопущения потери, о чем указано в в статье.
То же самое — не описано, что происходит в пункте 2b. Прерывание сценария = потеря клиентского ввода = потеря. Как недопустить ее? По идее нужно позволять сохранять документ с незаполненными обязательными полями (кстати, есть старая книга Купера Психбольница для пациентов — в ней разобран этот случай) + сделать статус Черновик (вот в хабре к примеру это не сделано — что так же ухудшает юзабилити). Собственно поэтому эта форма менее полная.
Так же поскольку целевое действие публикация на сайте, то возможны исключения — во введенных данных есть ошибки, не видные в редакторе, но влияющие на отображение на сайте. В этих случаях стоит делать предпросмотр перед публикацией.
Но за формат представления спасибо.
То же самое — не описано, что происходит в пункте 2b. Прерывание сценария = потеря клиентского ввода = потеря. Как недопустить ее? По идее нужно позволять сохранять документ с незаполненными обязательными полями (кстати, есть старая книга Купера Психбольница для пациентов — в ней разобран этот случай) + сделать статус Черновик (вот в хабре к примеру это не сделано — что так же ухудшает юзабилити). Собственно поэтому эта форма менее полная.
Так же поскольку целевое действие публикация на сайте, то возможны исключения — во введенных данных есть ошибки, не видные в редакторе, но влияющие на отображение на сайте. В этих случаях стоит делать предпросмотр перед публикацией.
Но за формат представления спасибо.
За ссылку спасибо
Ну ждем ещё обзор на Вигерса. Потом на babok. Посты же надо высасывать из пальца
Тогда уж лучше работу Ивора Якобсона, USE CASE 2.0 EBOOK
Он как никак автор метода :)
Он как никак автор метода :)
Мне такая книга сильно понравилась Use Case Modeling. Хотя, конечно, их много и других.
Спасибо. Есть ли там усиления метода, описанного в книге Коберна? или, возможно, более полно описано место use case в аналитическом процессе?
Мне кажется, там простым (на английском, что редкость) языком и очень лаконично, но емко разобраны как вообще разрабатывать use case. Конечно, книга издана давно. Предисловие написано Иваром Якобсоном. В аннотации можно найти следующее.
In Use Case Modeling, experienced use case practitioners Kurt Bittner and Ian Spence share their tips and tricks for applying use cases in various environments. They delve into all aspects of use case modeling and management, demonstrating how development teams can capitalize on the approach's simplicity when modeling complex systems.
In this ready reference, readers will discover how to:
Introduce a development team to use cases and implement a use case approach
Identify the key elements of a use case model, including actors; and the components of a use case, including basic flow, preconditions, post-conditions, sub-flows, and alternate flows
Master the objectives and challenges of creating detailed descriptions of use cases
Improve their descriptions' readability and consistency
Prevent and remedy common problems arising from the misuse of include, extend, and generalization use case relationships.
Organize and conduct a review of a use case model to realize the best possible approach
Книгу могу дать, хотя Вы ее легко найдете в открытом доступе.
In Use Case Modeling, experienced use case practitioners Kurt Bittner and Ian Spence share their tips and tricks for applying use cases in various environments. They delve into all aspects of use case modeling and management, demonstrating how development teams can capitalize on the approach's simplicity when modeling complex systems.
In this ready reference, readers will discover how to:
Introduce a development team to use cases and implement a use case approach
Identify the key elements of a use case model, including actors; and the components of a use case, including basic flow, preconditions, post-conditions, sub-flows, and alternate flows
Master the objectives and challenges of creating detailed descriptions of use cases
Improve their descriptions' readability and consistency
Prevent and remedy common problems arising from the misuse of include, extend, and generalization use case relationships.
Organize and conduct a review of a use case model to realize the best possible approach
Книгу могу дать, хотя Вы ее легко найдете в открытом доступе.
Sign up to leave a comment.
Усиление методики UseCase данное в книге Алистера Кобёрна