Перешкоди на шляху виявлення вимог

Синдром «так, але…»

Одна із самих неприємних проблем, з якими зустрічаються розробники, можна назвати синдромом «так, але…». Це перша реакція користувача на кожний розроблений фрагмент програмного забезпечення, яка може бути виражена такими словами:

· «О, це дійсно здорово! Можемо реально використовувати це, добра робота, молодці» і т.д.

· «Так, але як на рахунок?.. А чи можна було б?.. А, що, якщо?..»

Причина синдрому «так, але…» захована в природі проектування програмного забезпечення як інтелектуального неосяжного процесу. Проблема ускладнюється тим, що команда розробників дуже рідко надає будь-що користувачам для обговорення до кінця розробки (створення програмного коду).

Реакція користувачів є наслідком людської природи. Подібну реакцію можна часто спостерігати і у повсякденних обставинах. Користувачі ніколи раніше не бачили нову систему чи щось подібне; вони не розуміють, що програмісти мають на увазі, коли описують її. І ось вона перед ними – вперше за стільки місяців (чи років) очікування вони мають можливість взаємодіяти з системою. І виявляється, що це зовсім не те, чого вони очікували!

Як це не сумно, але потрібно прийняти факт існування синдрому «так, але…» в якості об’єктивної реальності і зробити деякі висновки, які допоможуть членам команди зменшити вплив цього синдрому в майбутніх проектах:

· синдром «так, але…» є наслідком людської природи і невід’ємною частиною розробки будь-якого додатку;

· розробники можуть суттєво зменшити вплив цього синдрому шляхом використання методів, які виявлять ці «але» як можна раніше. Виявивши їх на більш ранніх етапах, можна направити більшу частину зусиль на розробку програм, які вже пройшли тест на «так, але…»

 

Синдром «користувач і розробник»

 

Синдром «користувач і розробник» є наслідком розходження поглядів користувачів і розробників. Користувачі і розробники, як правило, належать до різних світів, розмовляють на різних мовах і мають різний досвід, мотивацію і цілі. Пропонуються рекомендації по полегшенню даної ситуації.

 

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

 

Функції

Використання функцій – зручний спосіб описання можливостей без зайвих подробиць.

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

Рекомендована кількість функцій, яка дає повне представлення про систему, яка розробляється, 25–99, однак бажано, щоб їх число не перевищувало 50.

Після того як всі функції перераховані, можна приступити до прийняття рішення виду «відкласти до наступної версії», «реалізувати негайно», «повністю відкинути» або «дослідити додатково». Цей процес коректування краще проводити на рівні функцій, а не на рівні вимог, інакше можна зав’язнути в деталях.

Щоб краще працювати з цією інформацією, введемо поняття атрибутів функцій – елементів даних, які забезпечують додаткову інформацію про кожну функцію.

Атрибут	Описання/приклади значень функції
Статус	· Припущена · Затверджувана · Включена
Пріоритет/корисність	· Критична · Важлива · Корисна
Трудоємність	· Низький рівень · Середній рівень · Високий рівень
Ризик	Ймовірність того, що функція викличе небажані наслідки, такі як збільшення розходів, відставання від графіка чи навіть закриття проекту. · Високий · Середній · Низький
Стабільність	Ймовірність того, що дана функція буде мінятися чи буде мінятися її розуміння командою · Висока · Середня · Низька
Цільова версія	Вказування версії продукту, в якій вперше з’явиться реалізація даної функції
Призначення	Інформація для розробників
Обґрунтування	Посилання на джерело функції

 

Методи виявлення вимог:

· інтерв’ювання та анкетування;

· наради, присвячені вимогам;

· мозковий штурм та відбір ідей;

· розкадровки;

· прецеденти;

· обігравання ролей;

· створення прототипів.

Інтерв’ювання та анкетування. Інтерв’ю допомагає зрозуміти проблему, не впливаючи на відповіді користувача. Нижче наведені приклади конкретно-вільних запитань:

· чому існує проблема?

· як вона розв’язується в даний момент?

· як замовник хотів би її розв’язувати?

· хто такі користувачі?

· які навики користувачів в комп’ютерній області?

Після цього інтерв’ювер перераховує основні пункти, щоб перевірити, чи все було правильно зрозуміло: «Отже, ви сказали мені …» (перечислюються описані замовником проблеми словами). «Які ще проблеми вам надокучають?»

Правила підготовки інтерв’ю:

1. Всі запитання повинні біти складені наперед.

2. Перед інтерв’ю потрібно познайомитись з інформацією про клієнта.

3. Коротко записуйте відповіді.

Наради. Добре проведена нарада по питанням вимог має багато переваг:

· допомагає створити команду, підпорядковану одній цілі – успіху даного проекту;

· всі зацікавлені особи отримують можливість висказати свою думку, ніхто не залишається в стороні;

· формує згоду між зацікавленими особами і командою розробників по поводу того, що повинен робити додаток;

· може висвітлити і розв’язати політичні питання, які впливають на успіх проекту;

· результат, попереднє визначення системи на рівні функцій, одразу ж стає відомим.

Всі матеріали до наради повинні бути представлені учасникам заздалегідь.

Мозковий штурм. Всі основні учасники збираються в одній кімнаті, їм роздаються матеріали для заміток – не менше 25 листків формату від 7×12 до 12×17.

Правила проведення мозкового штурму:

1. Не допускається критика чи дебати.

2. Дайте свободу фантазії.

3. Генеруйте як більше ідей.

4. Перероблюйте і комбінуйте ідеї.

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

Ідеї обов’язково записують на папір по наступним причинам:

1. Зберігається авторське формулювання.

2. Існує гарантія, що вони не будуть втрачені.

3. Є перспектива розвитку ідеї в подальшому.

4. Забезпечується неперервний творчий процес – не потрібно чекати, поки секретар записує думку учасника.

Розкадровка. Ціль розкадровки у ранньому виявленні реакції типу «так, але…». Існує три типа розкадровок.

1. Пасивні. Користувачу викладають деяку історію з використанням малюнків, схем, картинок з екрана.

2. Активні. Користувачу показують «ще не створений фільм» з використанням анімації чи слайдів.

3. Інтерактивні. Користувач отримує реальний досвід взаємодії з системою (майже так, як і на практиці).

Використання прецедентів. Малюються схеми з факторами; в овалі пишеться вид дії.

Обігравання ролей. Цей спосіб дозволяє розробнику відчути проблеми користувача. Розробник тимчасово стає на місце клієнта, причому можна наперед написати сценарій для програмістів, по якому вони намагаються виконати дії користувачів.

Також дуже ефективним способом є створення сценаріїв на основі CRC-карточок. Карточки описують об’єкт, його поведінку і взаємодію з іншими об’єктами системи. Учасники ділять карточки між собою і використовують їх для ролевої гри, виконуючи дії згідно передписаному. Ефективний спосіб для виявлення проблем проектування системи.

Прототипи вимог. Прототип вимог до ПЗ – це часткова реалізація системи, створена для того, щоб допомогти розробникам, користувачам і клієнтам точніше визначити вимоги до системи. Цей метод також допомагає розв’язати проблему «так, але…».

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