Варианты использования (use cases) в документах ГОСТ 34

Сейчас работаю над проектом разработки информационной системы для крупного госзаказчика. Разумеется, вся документация пишется по ГОСТ 34 и ГОСТ 19, поэтому волею судьбы пришлось вникнуть в содержание и саму суть стандартов. Конечно, очень помогла вводная от Сергея Нужненко.

Что же было интересного обнаружено в ходе разработки документации? А вот что. На стадии технического проекта формируется документ "Описание автоматизируемых функций". В нём есть раздел "3.2 Описание процесса выполнения функций". Как думаете, что могло бы быть помещено в него?

Во многих документах-примерах этот раздел заполняется чем-то, не очень похожим на описание процесса выполнения всех функций. Зачастую содержание раздела следующее: "Описание процесса выполнения функций не приводится", что не есть хорошо. 

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

Если есть другие мысли на эту тему, готов их обсудить.

Перевод статьи "Use Cases and Business Rules: Can They Work Together?"

Над переводом статьи "Use Cases and Business Rules: Can They Work Together?" я трудился еще года два назад, когда готовил материал для аналитического интернет-журнала "Analyze IT". Но четвертому выпуску так и не суждено было выйти, а держать полезный материал у себя в закромах — явно не мой принцип.

Поэтому приглашаю Вас к прочтению статьи "Варианты использования и бизнес-правила: могут ли они работать совместно друг с другом?". Кстати, данный перевод был использован Александром Байкиным в докладе "Бизнес-правила и дополнительные требования в вариантах использования (use cases)" на конференции ReqLabs 2012.

Практика: Разбиение требований в agile-проектах

Очень понравилась статья "Разбиваем требования для успеха Agile проекта", так как с практической точки зрения она является очень ценной. В статье показан поэтапный аналитический процесс выявления качественного требования в виде пользовательской истории.

Сам данной методикой пока не пользовался ни разу, однако, в любом случае, её стоит взять во внимание.

Процесс создания ИТ-аналитиком проектных артефактов

Для себя делаю несколько выводов об общем процессе создания проектных артефактов ИТ-аналитиком.

Итак, процесс ИТ-аналитика по созданию артефактов (по сути, документации и моделей) можно представить в следующем виде:

1. Выявление целей и задач будущей автоматизированной Системы.
2. Описание бизнес-процессов объекта автоматизации в состоянии "как есть" (AS IS) - бизнес варианты использования.
3. Моделирование и описание концепции будущей Системы.
4. Описание системных вариантов использования. По сути, это первоначальные процессы, но в состоянии "как должно быть" (TO BE).
5. Формирование спецификации (SRS), или, другими словами, ТЗ, которое подробно описывает все функции будущей системы.
6. По результатам разработки - создание справочной системы, руководств и инструкций.

Всё наглядно иллюстрирую с помощью VAD-диаграмм (см. рисунок ниже). 

Коллеги, будут какие-либо дополнения/уточнения? Мне важно Ваше мнение.

Итоги конференции "Объектные Системы - 2011"

В текущем году решил принять участие в конференции "Объектные системы". Для этого написал статью под названием "Бесплатные инструменты для IT-аналитика". 29 июня мне на электронный адрес пришло письмо с результатами.

С самой статьёй, которая находится на с. 44-46 сборника, можно ознакомиться по ссылке:

"Объектные системы - 2011: материалы III Международной научно-практической конференции (Ростов-на-Дону, 10-12 мая 2011 г.) / Под общ. ред. П.П. Олейника. - Ростов-на-Дону, 2011. - 160 c."

За участие был получен сертификат.

Таким образом, у меня на одну публикацию стало больше и она имеет вид:

Сафин П.В. Бесплатные инструменты для IT-аналитика // Объектные системы - 2011: материалы III Международной научно-практической конференции (Ростов-на-Дону, 10-12 мая 2011 г.) / Под общ. ред. П.П. Олейника. - Ростов-на-Дону, 2011. - С. 44-46.

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

Не могу не отметить четкий и подробный перевод статьи-инструкции по написанию вариантов использования от Александра Шамрай. В совокупности с книгой Алистера Коберна данная инструкция «расставляет всё на свои места».

Из всей статьи можно выделить перечень важных моментов:

• Сценарии использования – это программные требования, которые определяют функциональность.

• Сценарий использования – это история о том, как бизнес (или система) и пользователи взаимодействуют.

• Сценарии использования – это формальные требования, которые четко определяют результирующее значение.

• Сценарии использования преобразуют выражения «должен» на группы, которые обеспечивают наблюдаемое значение и контекст, организованные с точки зрения пользователя.

• Сценарии использования описывают и функциональность, и результаты.

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

Рекомендации по составлению вариантов использования:

• Распространенной ошибкой является путать требования со спецификациями проектирования.

• Диаграммы обеспечивают визуальный вспомогательный материал для сценария использования.

• Сценарии использования должны иметь один основной поток и несколько альтернативных потоков.

• Альтернативные потоки объясняют отклонение от основного потока.

• Ссылки определяют начало и конец альтернативного потока.

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

• Ссылки указывают на то, что является причиной для начала альтернативного потока и что система делает в ответ.

• Создание стиля для сценария использования позволяет писать и читать их быстрее и проще.

• Удобочитаемость может пострадать, если присутствует оператор «если» в потоке, потому что это обычно означает множественные требования.

• Выбор единственного варианта для субъекта и создание альтернативных потоков для другого варианта может упростить главный поток.

• Плохо написанный сценарий использования имеет слишком много действий создания, чтения, обновления и удаления (СЧОУ), уменьшая ясность. Удаление деятельностей СЧОУ упрощает документ.

• Упорядочивание событий в потоке не всегда необходимо для достижения ясности.

• Соглашение по структуре сценария использования и процессов важно для достижения качества и последовательности.

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

Классификация требований к программному обеспечению и её представление в стандартах и методологиях

Недавно мне случайно попалась на глаза очень полезная презентация от Юрия Булуя на тему "Классификация требований к программному обеспечению и её представление в стандартах и методологиях".

В ней автор провёл отличное сравнение вариантов классификации требований к программному обеспечению в различных стандартах и методологиях, среди которых:

1. SWEBOK;
2. ГОСТ 34;
3. IEEE 830;
4. RUP;
5. Классификация К. Вигерса.

Сама презентация доступна для просмотра тут: http://cee-secr.org/2006/upload/files/63.pdf

Рекомендую для ознакомления!

Где купить «бумажного» Коберна?

Так как электронные варианты книг не очень люблю, потому что не люблю читать с экрана монитора – глаза быстро устают, да и электронной «читалкой» на данный момент ещё не обзавёлся, задался целью купить переведённый оригинал книги Алистера Коберна «Современные методы описания функциональных требований к системам». Что уж тут говорить, а книга действительно нужная для каждого it-аналитика.

Но столкнулся с проблемой – где её купить-то? По советам форумчан с uml2.ru отправил запрос на findbook.ru: книга была в наличии аж в 3-х книжных интернет-магазинах: books.ru, colibri.ru и в Чаконе.

Сперва заказал книгу в самарской Чаконе (дело было в ноябре прошлого года), при этом заполнил специальный бланк заказа, плюс ещё и на интернет-сайте Чаконы оставил заявку на приобретение. Сказали, что в срок от 2 недель до 3 месяцев оповестят меня. До сих пор никакой обратной связи нет…

Затем обнаружил, что на books.ru находится данная книга со статусом «есть в наличии». Обрадовался. Сразу же сделал заказ и оплатил его. Но вдруг, спустя некоторое время узнал, что «товар в настоящий момент снят с продажи и не может быть отправлен». Огорчился. Ладно хоть деньги вернули в полном объёме! Видно, что магазин дорожит своей репутацией и покупателями. Связь держали со мной постоянно, оповещали о состоянии запроса к поставщику. Ну да ладно, не получилось тут, думал, что получится в другом месте.

Третьей попыткой был заказ книги в интернет-магазине colibri.ru. Статус книги был аналогичный – «в наличии». Снова обрадовался. Оплатил заказ и доставку. Обещали после новогодних праздников прислать. Но не тут-то было: спустя несколько недель узнал то же самое – «книги нет в наличии» с соответствующей припиской:

«Такое случается, когда поставщики присылают нам неверные сверки по остаткам на их складе, поэтому на сайте присутствуют отсутствующие на складе товары. Либо пока заказ оформляется, товар уже заканчивается на складе. Мы пытались заказать ее повторно и не раз, но это не приводило к успеху. Приносим свои извинения за доставленные неудобства».

Расстроился. Деньги до сих пор не вернули и на письма отвечают оооочень медленно.

В общем, интернет-магазинами я остался не доволен… А книгу-то хочется приобрести...

Use Case и функция системы - в чём отличия?

Думаю, вопрос в названии статьи мучает большинство начинающих аналитиков, у которых от количества информации после первоначального ознакомления с литературой, прочтения форумов, тематических статей попросту организовывается "каша в голове".

Как же отличить варианты использования (use cases) от функций системы? Как избежать их дублирования?

Ответ на этот вопрос и видение сложившейся ситуации опубликовал в своём блоге Юрий Булуй.

В сообществе UML2 также идёт активное обсуждение данного вопроса: http://www.uml2.ru/forum/index.php?topic=2978.0.

Главное, что я усвоил из вышеуказанного материала:

• Use Case и функция системы - далеко не одно и то же.
• Если я представлю себя пользователем будущей системы, то Use Cases - это описание тех задач/целей, которые я смогу решить с помощью системы.
• Функции системы - это "взгляд" изнутри системы на её окружение. Представляем себя находящимся внутри системы и определяем, что мы сможем сделать для внешнего мира  - пользователей, других систем и т.д.
• Одно из отличий функции от Use Case в том, что функция может быть декомпозирована, Use Case не может быть декомпозирован.

Метод скоростной фиксации сценариев использования

Совсем недавно, при общении с Андреем Бобылёвым, одним из коллег по профессии, вежливо попросил его поделился со мной своим опытом по сбору требований к программному обеспечению, на что Андрей отозвался (за что его огромное спасибо), ответив мне достаточно развёрнуто и по сути.

К слову, в одном из его ответов была предоставлена достаточно интересная ссылка на скоростную методику сбора сценариев использования с помощью ментальных карт (диаграмм связей).

Что же касается самой методики, то, как утверждает автор статьи, Алексей Копылов, она применима в тех случаях, если:

• У проектировщиков нет возможности провести этап исследований с привлечением реальных пользователей;

• Процесс проектирования и разработки является итеративным (например, является вариантом метода разработки Agile);

• Пользовательский интерфейс не слишком сложный;

• Приложение, для которого проектируется пользовательский интерфейс, не слишком критично к ошибкам пользователей.

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

На мой взгляд, такой метод сбора требований должен быть в резерве у каждого бизнес-аналитика.