79. Випадки використання

Робота з вимогами. Випадки або варіанти використання (use cases) були запропоновані в кінці 90-х років Айвер Якобсоном, одним з головних авторів мови UML, як діаграмні підхід для витягання і первинної формалізації вимог до систем. Вище вже йшлося про складність з формування єдиної і зв'язковий картини вимог до ПЗ. Необхідно витягти вимоги з усіх можливих джерел, формалізувати в деякому вигляді і обговорити. Цей процес - вилучення, формалізація, обговорення - ітератівен, тобто все робиться не за один присід. Більше того, сам спосіб формалізації повинен бути зручний для обговорення, і в першу чергу, з потенційними користувачами системи, які можуть бути зовсім не компетентні в IT. Їхні коментарі, схвалення та незгоди часто є основою ітеративного вилучення вимог до системи. Крім того, цей спосіб роботи з інформацією повинен вести до створення моделей, зручних у подальшій реалізації системи. Іншими словами, ясно формулювати вихідні завдання для розробки. Тобто спосіб формалізації повинен бути простий, зрозумілий і володіти достатньою строгістю. Цим вимогам задовольняють діаграми випадків використання, що є на сьогоднішній день складовою частиною стандарту UML. Різні користувачі ПЗ, зображувані на діаграмах випадків використання, називаються акторами (actors). Актори можуть позначати:

• типових користувачів ("Менеджер", "Оператор", "Технічна підтримка") - працівників компанії, згрупованих за виконуваним обов'язкам;

• інші системи, які взаємодіють з даної ("Система обробки заявок");

• виділеного користувача ("Петров А.Б.").

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

80. Випадки використання в керуванні розробкою

Отже, вище ми показали, як діаграми випадків використання можуть бути корисні при виявленні первинної формалізації вимог. Але вони можуть виявитися корисними і після того, як це процес завершено. Результуючі діаграми випадків використання можна застосовувати при управлінні розробкою. Менеджер проекту може відслідковувати прогрес проекту по тому, скільки реалізовано функціональності, необхідної користувачеві. Розробники можуть мати діаграми випадків використання десь перед очима, щоб не забувати про основну мету розробки. Ці ж діаграми можуть використовуватися в робочих зустрічах по проекту.

Здавалося б, що може бути простіше - реалізувати набір функцій, необхідних користувачеві. Однак на ділі програмний проект може непомітно втратити цю мету. Замість цього можна, наприклад, дуже довго займатися розробкою складної і багатофункціональною архітектури, після реалізації якої розробники обіцяють, що всі призначені для користувача функції вийдуть майже відразу ж і дуже легко. Однак, як правило, виявляється, що це "відразу ж" було сильним перебільшенням і проект дуже вибивається з розкладу, а багато замовлені користувачем функції в цьому оточенні зробити важко або неможливо. Буває, що надмірна орієнтація на "внутрішнє досконалість" ПО закінчується для проекту або великими неприємностями, або повним крахом. Проте бувають і інші випадки, коли тільки така орієнтація згодом і рятує проект. Останнє трапляється, коли система довго розвивається і супроводжується, або коли вимоги до неї раптово і сильно змінюються, або коли на її основі робляться інші системи. Необхідний баланс між внутрішнім досконалістю програмного забезпечення і функціональністю, потрібної для замовника і доставленої йому в строк. Розробка ПЗ в термінах випадків використання - хороший спосіб контролювати, що процес створення системи рухається в потрібному напрямку.