Діаграма сценаріїв використання в процесі розробки ПЗ

Вже кілька років я, як аналітик, досить широко використовую у своїй роботі сценарії використання (СІ) і діаграми СІ для документування вимог. Взагалі, у сценаріїв використання є різні назви. Їх називають use cases, варіанти використання і навіть прецеденти. Пам'ятаю, як в середині 2000-х, на деяких аналітичних ресурсах йшло спекотне обговорення того, як перекласти термін use case на російську мову. Ось тоді це страшне слово «прецедент» і з'явилося, навіть більше того, деякі товариші стверджували, що російська мова збитковий і не дозволяє передати всі тонкощі поняття use case. Але як показав час, поняття сценарій використання (або варіант використання) цілком підходить і досить приємно на слух.

Маючи тільки позитивний досвід роботи з СІ, я був дуже здивований, коли при спілкуванні з колегами з інших компаній дізнався, що вони їх не використовують і, більше того, навіть намагалися переконати мене, що малювання чоловічків, овалів і паличок між ними – це марна трата часу. Тому я і вирішив поділитися своїм досвідом та продемонструвати, як діаграми СІ допомагають мені в роботі.

По-перше, що таке сценарій використання? Сценарій використання – це зв'язний розповідь про поведінку системи, коли вона взаємодіє з кимось (або чимось) із зовнішнього середовища. Хтось або щось може бути користувачем системи, це може бути якась інформаційна система або пристрій. І цей хтось чи щось називається Дійовою особою (ДЛ). А сам сценарій використання являє собою послідовність кроків, які описують дії ДЛ і реакцію системи на них.

Наприклад, сценарій реєстрації на якомусь сайті може виглядати ось так:

  1. Користувач дає команду на реєстрацію.
  2. Сайт відображає форму реєстрації.
  3. Користувач заповнює поля форми і підтверджує реєстрацію.
  4. Сайт підтверджує правильність заповнення форми.
  5. Сайт відправляє на вказаний e-mail лист із запитом для підтвердження реєстрації.
  6. Користувач підтверджує реєстрацію.
  7. Сайт реєструє користувача.
Як можна помітити, дії користувача і системи чергуються між собою, вони ніби грають в м'яч, роблячи паси один одному. Детальніше про СІ можна прочитати тут: ru.wikipedia.org/wiki/Сценарий_использования

Але уїдливий читач може справедливо заперечити, що в розробку такий сценарій віддавати не можна. І він буде правий! Адже ми зараз подивилися на систему з висоти, напевно, 5-поверхового будинку, коли загальна поведінка вже зрозуміло, але детальних вимог ще немає. Тому сценарій використання повинен бути, як мінімум, доповнено альтернативними потоками виконання (те що наведено вище, називається основний потік і описує дії системи, коли все йде як треба). Альтернативні потоки – це потоки, в яких описується реакція системи на помилкові дії користувача або виняткові ситуації, або ж випадки альтернативних дій користувача, якщо він захотів, наприклад, зареєструватися за допомогою облікового запису в соціальній мережі. Також документ зі сценарієм використання можна доповнити деталями інтерфейсу користувача, правил валідації даних, різними бізнес-правилами і повідомленнями про помилки. А ось нефункціональні вимоги зазвичай описуються в окремому документі, так як вони зазвичай застосовуються до всієї системи цілком, а не до конкретних СІ.

Якщо ж піднятися ще вище і подивитися на систему з більшої висоти«, то вона буде виглядати як набір послуг, що надаються системою користувачу (сценарії використання також можна розглядати як високорівневі вимоги до системи). Тут ми приходимо до того, що непогано б було візуалізувати ці вимоги, і для цього відмінно підходить відповідна діаграма UML: діаграма сценаріїв використання. Шматочок діаграми показаний нижче. Вона складається з діючих осіб, сценаріїв використання і різних зв'язків між ними.


Для розробників і тестувальників вона, на перший погляд, несе ще менше користі, ніж самі сценарії використання. Але ж і призначена вона для іншого!

Діаграма СІ малюється зазвичай аналітиком в самому початку проекту для того, щоб широкими мазками охопити весь планований функціонал проекту і погодити його з замовником. І після цього кожен СІ вже деталізується за допомогою кроків і детальних вимог. СІ допомагають дивитися на систему з точки зору надаються системою послуг і не закопуватися зокрема.

Я зазвичай використовую діаграму СІ для вирішення наступних завдань:

  • Оцінка трудомісткості проекту;
  • Планування графіка робіт;
  • Виявлення пропущених вимог;
  • «Зміст» для проектних документів.
Давайте подивимося, як СІ допомагають вирішувати ці завдання.

Оцінка трудомісткості проекту
Як показує досвід і практика, оцінка виходить тим точніше, чим детальніше виділено список майбутніх робіт. Адже дійсно, завдання «написати статтю» оцінити набагато складніше, ніж завдання «знайти 5 картинок для ілюстрацій». Так от, сценарії використання є першою ітерацією розбиття системи на окремі елементи. Більш того, ці елементи мають хорошою в'язкістю (в даному випадку – функціональна) і можуть бути оцінені окремо один від одного. Якщо цього недостатньо, то вже кожен СІ можна декомпозировать на основний/альтернативні потоки або навіть завдання, які необхідно виконати програмісту для реалізації окремого сценарію.

Тут досить часто також проявляється можливість повторного використання раніше створених артефактів. Наприклад, якщо для системи потрібно функціонал реєстрації користувачів, то плюс/мінус він буде працювати однаково в багатьох системах, що при оцінці відразу ж знижує ступінь невизначеності.

Навіть існує спеціальний спосіб оцінки, заснований на СІ – Use Case Points. У цьому випадку виділяються діючі особи і сценарії, у них за певними правилами визначається складність, задаються деякі поправочні коефіцієнти, що враховують професіоналізм команди і складність предметної області, і на виході з'являється готова оцінка. Тобто, до оцінки, в ідеалі, навіть не треба залучати розробників і тестувальників.

Планування графіка робіт
У проектах з фіксованому бюджетом зазвичай явно виділяються послідовні стадії проектування, розробки і тестування (як у водоспадної моделі). Але в реальності тестування вже частково починається навіть до завершення стадії проектування, так як тестувальники підключаться до рев'ю розроблених вимог і починають писати тест-дизайн. І якщо для аналітика і, скажімо, архітектора, скласти графік робіт не становить великої праці, так як активності цих ролей починаються разом зі стартом проекту, визначити, коли й на яку задачу варто підключати тестувальників з розробниками, вже стає складніше. Дійсно, адже вхідними даними для них є підготовлені і погоджені документи з вимогами. І для вирішення цієї проблеми знову добре підходять СІ. Так як кожен сценарій містить у собі завершений опис якогось процесу, то їх простіше погоджувати з замовниками і, відповідно, можна досить точно встановити в план-графіку ключові точки погодження документів вимог. А вже від цих точок планувати роботу решти команди.

Виявлення пропущених вимог
Не дивно, що коли замовник якимось чином озвучує вимоги до майбутньої системи, то він у своєму описі сконцентрований саме на корисному функціоналі і ніяк не згадує, наприклад, функції настройки системи або функції управління обліковими записами користувачів, хоча без них система не буде повноцінно працювати. Дуже часто після отримання таких вимог команда починає виконувати оцінку. У мене на практиці були випадки, коли команда відразу кидалася в бій і оцінювала те, що описав замовник, залишаючи за бортом не озвучені, але, тим не менш, обов'язкові функції системи.

Також буває й інша ситуація, коли в описі системи присутні вимоги про те, що в процесі роботи користувачі повинні створювати якісь сутності. У переважній більшості випадків, до таких сутностей застосовні всі CRUD (Create, Read (або також зустрічається розшифровка Retrieve), Update, Delete) операції, про які теж іноді забувають. У чому ж тут користь моделі СІ? А як раз в графічному поданні вимог. Коли око охоплює всю картинку, то набагато простіше помітити відсутні елементи, ніж коли вимоги сформульовані звичайним текстом.

«Зміст» для проектних документів
Дуже часто замовник просить разом з системою передавати комплект проектної документації. У себе в компанії ми пишемо проектну документацію у вигляді сценаріїв використання. Якщо ж замовник вимагає документи по ГОСТу, то все одно спершу пишуться сценарії, а потім вже на їх основі формуються ГОСТовские документи.

У нас використовується, як мінімум, два підходи до документування: коли кожен СІ описується в окремому документі, і коли в одному документі описуються відразу кілька СІ, відносяться до одній підсистемі. Часто той чи інший підхід визначається, виходячи з прийнятого процесу або звичок замовника.

Вище вже було сказано, що перша версія списку сценаріїв використання вже формується на етапі оцінки і планування графіка робіт. Надалі цей список може доповнюватися та коригуватися, але вже з певним ступенем точності можна домовлятися з замовником про те, які саме документи буде надавати проектна команда.

Висновок
Після цих пояснень, сподіваюся, стала зрозуміла користь, яку дає використання діаграми СІ. Незважаючи на її простоту і навіть надмірність безпосередньо для розробників, вона дає досить хороший імпульс до старту будь-якого проекту. І розглядати її треба перш за все в цьому ключі. Алістер Коберн у своїй книзі «Сучасні методи опису функціональних вимог до систем» теж пише про те, що не бачить сенсу в малюванні паличок і овалів, так як вони не наближають читача до розуміння того, як система повинна працювати. Але і він, як раз, говорить вже про етап детального опрацювання вимог, який слід після визначення набору сценаріїв.
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.