Введення
- Мета статті
- Суть проблеми
- Всі можливості ПЗ
- Вимоги Замовника 1
- Всі можливості ПЗ
- Вимоги Замовника 2
- Всі можливості ПЗ
- Вимоги Замовника 3
- Axiom
- Перше знайомство з Axiom
- Створення шаблонів артефактів
- Створення артефакту
- Взаємозв'язки між артефактами
- Інтеграція з MS Word
- Таблиця артефактів
- Крім того
- Разом
- Плюси
- Мінуси
- P.S.
При роботі з вимогами можливе застосування різних методів їх організації: від методу повного хаосу, до інтеграції вимог з програмним кодом (стаття П'ять рівнів зрілості вимог). Поступово покращуючи роботу з вимогами, зазвичай, у процес починають впроваджувати різні нові методології та інструменти. Одним з класів інструментів, покликаних спростити роботу з вимогами, є спеціально навчені «звірки»: Системи Управління Вимогами (СУТ). Основними можливостями таких систем є:
- Створення простішого, ніж цілий документ, одиниці керування проектом (вимога). Прочитати і підтвердити одну вимогу набагато простіше, ніж погоджувати ціле Технічне завдання.
- Вказує зв'язки між вимогами. Така можливість дозволяє відстежувати зміни в пов'язаних вимогах. Тобто. якщо щось змінилося, то далі система може виділяти всі елементи, пов'язані зі зміненим, як підозрювані на зміну.
- Вибір представлення набору взаємопов'язаних вимог. При великій кількості вимог іноді необхідно представити всю картину їх взаємозв'язку. Комусь зручніше переглянути цю інформацію у вигляді таблиці (матриці трасування), комусь у вигляді ієрархічного дерева, комусь у вигляді мережевих графіків (стаття Системи управління вимогами: що і навіщо?).
Серед даних програм є відомі «Монстро-звірі», такі як: IBM Rational DOORS, Borland Caliber, Polarion Requirements та ін. З великою кількістю функціональних можливостей. Такі системи, як правило, є добре зарекомендували себе, але дорогими. Однак серед цього переліку є маленькі, безкоштовні, маловідомі, але дуже корисні «звірки» типу Axiom.
Мета статті
Як правило, коли приймається рішення про впровадження нового інструменту, мається на увазі, що у членів команди є перелік вимог до нового ПЗ, що склався з тих проблем, з якими вони зіткнулися. Особисто мені, коли я була в подібній ситуації, дуже не вистачало оглядових статей, в яких описувалися функціональні можливості інструментів і конкретні ситуації їх застосування. Тому метою цієї статті є опис основних функціональних можливостей системи управління вимогами Axiom.
Суть проблеми
Я зіткнулася з проблемою управління вимогами, коли збирала потреби до готового програмного забезпечення, яке може налаштовуватися під потреби клієнтів. Функціональні можливості цієї програми визначають набір вимог до неї. Поясню на абстрактному прикладі. Припустимо є готова програма, в якій користувач може:
- Ввести текст у текстове поле;
- Зберегти введений текст у форматах doc, xml і pdf;
- Надрукувати введений текст.
Перший Замовник, купуючи дане ПЗ, заявив, що йому потрібні всі перераховані функції, але формати xml і pdf він не знає, платити за цю можливість він не хоче, тому зберігати введений текст він буде тільки у форматі doc. Виходячи з цього отримуємо наступний набір вимог для цього Замовника:
Другий замовник сказав, що йому взагалі не потрібна функція друку тексту. У нього є своє ПЗ, яке відмінно роздруковує документи у форматах doc, xml і pdf. Для даного Замовника перелік вимог до ПЗ містить:
А третій Замовник купив ПЗ з повним набором функціональних можливостей.
Це означає, що кількість вимог до купованого продукту, який налаштовується під конкретного Замовника, менше або дорівнює кількості функціональних можливостей програми.
У процесі вдосконалення якості програми в рази збільшилася кількість функціональних можливостей. Як наслідок зросла і кількість вимог. Документи технічного завдання (ТЗ) стали дуже громіздкими. Вникати в них як технічним фахівцям, так і клієнтам, стало набагато важче. Плюс до всього стало важче тримати таку велику кількість можливостей в голові. Збільшилася ймовірність упустити будь-яку реалізовану функцію.
Через ситуацію, що склалася, я вирішила спробувати інструмент, в якому було б можливо описати всі вимоги до ПЗ. З повного переліку всіх можливих вимог, для конкретного проекту повинні вибиратися ті вимоги, які відповідають потребам Замовника. На основі цього набору інструмент також повинен автоматично створювати документи формату doc, щоб спрощувати завдання формування Технічного завдання. Крім того, необхідно, щоб у ньому можна було визначити взаємозв'язки між вимогою і тими діями, які потрібно зробити для включення або виключення саме цієї вимоги до ПЗ.
Спробувавши різні СУТ (вибиралися в основному безкоштовні інструменти зі статті List of Requirements Management Tools), я зупинилася на інструменті Axiom компанії iConcur.
Axiom
Axiom - це безкоштовний крос-платформенний клієнт-серверний додаток управління вимогами.
Необхідно також зазначити, що у розробника є і платна версія продукту, з додатковими можливостями, але все ж Axiom позиціонується як безкоштовний продукт, оскільки функціональних можливостей безкоштовної версії цілком достатньо для спрощення роботи з вимогами.
Отже, чому саме Axiom? Я вибрала цей інструмент, з наступних причин:
- Безкоштовне ПЗ;
- Гнучкість інструменту (можливість налаштувати роботу з інструментом залежно від особливостей конкретної компанії або проекту);
- Простота інструмента;
- Можливість створення документів на основі даних, що зберігаються в інструменті.
Але зупинимося детальніше на основних функціональних можливостях даного продукту.
Перше знайомство з Axiom
Після авторизації користувача відкривається головне вікно інструмента.
Його можна розділити на такі логічні частини:
- Панель інструментів і меню (вгорі);
- Дерево артефактів (у лівій частині вікна; що таке артефакт буде описано трохи нижче);
- Вікно редагування інформації про артефакті (посередині);
- Допоміжні розділи (view), розташовані праворуч і внизу.
Отже, що таке артефакт? Артефакт - це продукт проекту, породжуваний і/або використовуваний в ньому при роботі над програмним забезпеченням, наприклад, вимога, тест кейс тощо. У Axiom даний термін застосовується дуже активно.
Всі об'єкти, створені користувачем, є артефактами, і всі вони будуть відображатися в дереві артефактів.
Перелік створюваних артефактів та відомостей, які за ними збиратимуться, визначається самими користувачами інструмента за допомогою шаблонів артефактів.
Створення шаблонів артефактів
Саме завдяки даній функції інструмент є дуже гнучким і його можна налаштувати під різні потреби членів команди.
Що таке шаблон? Шаблон - це набір атрибутів, за яким здійснюється опис артефакту. Наприклад, для роботи нам потрібен артефакт Функціональна вимога. Функціонально вимога повинна містити такі відомості:
- Назва («Збереження документа», «Додавання кнопки до інтерфейсу», «Передача даних»);
- Опис (наприклад: Система повинна зберігати документ при натисканні кнопки «OK»);
- Джерело вимоги, тобто людина, яка його озвучила;
- Питання, що виникають під час обговорення цієї вимоги;
- Статус вимоги, наприклад, «Затверджено», «Погоджено», «Переглянуто», «Відхилено» тощо.
- Пріоритет, тобто наскільки важливо реалізувати цю вимогу.
- Інформація про те, чи буде ця вимога реалізована в першій версії продукту.
Перелічений вище список - це набір даних (атрибутів), за яким буде виконуватися опис всіх функціональних вимог продукту.
Атрибути Axiom можуть бути різноманітними типами: це і текстові поля, і випадаючі списки, з встановленими користувачем переліком значень, і атрибути-прапорці, за допомогою яких можна відзначити чи володіє артефакт певною властивістю чи ні.
З описаних вище атрибутів Функціональної вимоги логічно припустити, що атрибути «Джерело» і «Питання» повинні бути текстовими полями, «Статус» і «Пріоритет» - випадаючими списками, а інформацію про входження вимоги в першу версію продукту можна реалізувати прапором. На зображенні нижче представлено приклад з реалізованим шаблоном Функціональних вимог, який названо «Вимоги».
На основі створеного шаблону можна буде сформувати необмежену кількість артефактів.
Створення артефакту
Створення самого артефакту відбувається наступним чином:
- У дереві артефактів, ви вибираєте той вузол (групу артефактів), до якого належить цей артефакт;
- Потім необхідно вибрати шаблон, на підставі якого буде створено артефакт;
- Встановити назву артефакту (Name);
- І відредагувати його атрибути та опис.
На малюнку нижче представлений результат створення артефакту функціональної вимоги «Введення тексту» на основі шаблону «Вимоги».
Подібно можна створювати артефакти на основі інших шаблонів. На малюнку нижче створено артефакт налаштування програми, що містить опис дій, які необхідно виконати для того, щоб певна функціональна можливість була включена в ПЗ. Цей артефакт створений на основі іншого шаблону і має інший набір атрибутів.
Взаємозв'язки між артефактами
Для визначення зв'язків між артефактами в Axiom є спеціальний розділ «Linking Surface». У Axiom реалізовано стандартний шаблон взаємозв'язків, на основі якого можна створювати різні типи зв'язків, наприклад, «Пов'язаний з», «Неможливо реалізувати без», «Батьківський елемент для» тощо. Взаємозв'язки встановлюються користувачем вручну в розділі «Linking Surface», шляхом з'єднанням артефактів обраним типом зв'язку. На малюнку нижче представлено створений взаємозв'язок функціональних вимог і налаштувань за допомогою нового типу зв'язку «Необхідно виконати».
Дані зв'язку показують які параметри необхідно виконати, щоб працювала та чи інша функціональна можливість.
Крім того, в якості взаємозв'язків можуть виступати гіперпосилання на інші артефакти, які можна додавати в опис до артефакту для додаткового пояснення.
Інтеграція з MS Word
В Axiom реалізована інтеграція з MS Word, що дозволяє формувати документи, що містять інформацію щодо створених артефактів. Ця функціональна можливість призначена для спрощення формування таких документів, як Технічне завдання (Software Requirements Specification), Видіння (Vision) та інших проектних документів. Необхідна інформація по артефактах вже зберігається в Axiom, і користувачеві не потрібно повторно вводити ці відомості вручну.
Після встановлення Axiom на комп'ютер в MS Word з'являється спеціальна вкладка «Axiom», за допомогою якої користувач може сформувати шаблон документа. Для цього користувачеві необхідно розставити в потрібних місцях документа посилання на атрибути вибраних артефактів. На зображенні нижче створюється шаблон документа, що містить такі відомості щодо артефактів:
- Назва (Name);
- Ідентифікаційний номер (ID);
- Опис нефункціональної вимоги (Content).
Після цього користувач може сформувати готовий документ, що містить всі необхідні дані.
Необхідно відзначити, що мною була перевірена інтеграції Axiom тільки з MS Word версії 2007, 2010. 2013 версія також перевірялася, але з нею інтеграція не працює.
Таблиця артефактів
Таблиця артефактів (Artifact Table) - це спеціальний розділ Axiom для представлення набору артефактів у зручному табличному вигляді.
Однією зі зручних функціональних можливостей даного розділу, я вважаю зміну атрибуту відразу декількох артефактів. Наприклад, потрібно змінити статус відразу у декількох вимог на «Complete».
На мій погляд, ця можливість значно прискорює редагування артефактів.
Крім того
Вище були перераховані ті основні функціональні можливості Axiom, які я використовувала і знайшла дуже зручними на поточному етапі впровадження інструменту в процес роботи. Але крім того, в безкоштовній версії Axiom реалізовані такі зручні функції:
- Обговорення. Користувачі можуть обговорити артефакти і отримати зворотний зв'язок за допомогою спеціального розділу Обговорення (Discussion);
- Адміністрування користувачів. Ця можливість дозволяє створювати нового користувача і визначати його логін і пароль. На жаль, у поточній версії продукту реалізовано всього 2 ролі користувачів: адміністратор, який може все, і простий «смертний» користувач, якому доступний лише перегляд артефактів.
- Перегляд історії версій артефактів та атрибутів різних версій за допомогою розділу Історія (History).
- Експорт сформованих даних у формат xml, xls.
Для платної версії також доступні:
- Axiom Rules Language. Функціональна можливість, яку особисто мені було б цікаво спробувати. У чому полягає її суть? Компанія iConcur створила свою мову опису вимог для виключення неоднозначності їх розуміння. Крім того, був створений редактор, який перевіряє коректність написаної вимоги. На малюнку нижче представлено наочний приклад вимоги, написаної на цій мові.
- Створення прототипів інтерфейсу. У платній версії Axiom є вбудований редактор прототипів. Створені інтерфейси так само вважаються артефактами і можуть бути пов'язані з іншими артефактами.
- Перегляд матриці трасування вимог за допомогою спеціального розділу Матриця Взаємозв'язок (Linking Matrix). Цей розділ дозволяє переглядати взаємозв'язки між артефактами в табличному вигляді, як показано на малюнку нижче.
- Перегляд ієрархічного дерева зв'язків артефактів (Linking Tree).
Примітка: функціональні можливості платної версії інструмента описані на підставі Керівництва користувача Axiom і не були мною випробувані.
Разом
Підбиваючи підсумки, хотілося б перерахувати виявлені гідності і недоліки даного продукту.
Плюси
БЕЗКОШТОВНИЙ. З випробуваних мною безкоштовних інструментів дана система найбільш «пристойна». Приємний сайт компанії розробника, проста установка, зручний інтерфейс користувача. Плюс до всього для безкоштовного інструменту у програми реалізовано достатню кількість функціональних можливостей, принаймні, для того, щоб вирішити мою задачу.
Гнучкість інструмента. Завдяки можливості створення самими користувачами шаблонів артефактів, які використовуються ними при роботі, цей інструмент може бути застосований в різних проектах.
Простота роботи. По-перше, це інтуїтивно зрозумілий інтерфейс. По-друге, у інструменту немає мудрих налаштувань роботи і якихось додаткових параметрів, як, наприклад, у MS Word розділ меню «Параметри», що визначає важливі, але іноді неочевидні аспекти роботи з ПЗ. Додатково, Axiom володіє набором безкоштовних відео-туторіалів, які доступним чином навчають (саме навчають, а не пояснюють) користувача основним можливостям інструменту і додатковими «фічам», які можуть значно спростити роботу з інструментом.
Кроссплатформенність. Версія 4.0 була доступна для встановлення тільки для Windows OS і Linux. У новій версії 4.1 стала доступна установка продукту на Mac OS.
Мінуси
Дивна компанія. Вперше я зустріла згадку про цю програму на Stack Overflow, де «CEO of iConcur Software» Брент Вілсон рекламував даний продукт. Коментарі до відповіді Брента, особливо ось цей: «I tried this product recently and couldn't even log in as the admin. I tried calling, emailing, and opening a support ticket but no response after a week. Is iConcur still alive? "мене здивували. Ну і плюс до всього технічна підтримка працює дійсно дивно: іноді відповідає в той же день, іноді тижнями не відповідає, а буває, що і зовсім мовчить. На виправдання компанії можу зауважити, що нещодавно вийшла нова версія ПЗ, так що «пацієнт швидше живий, ніж мертвий».
Помилки ПО. Таких помилок, які робили б неможливим роботу з продуктом або, наприклад, видаляли результати годинної роботи, я не виявила. Були баги пов'язані з установкою ПЗ, запуском клієнтської частини (перед цим потрібно перезапустити сервер) або не відображалися піктограми в інтерфейсі... Але все ж це не дуже приємно. З іншого боку, багато хто з нас працює з MS Word...
Відсутність інтеграції з MS Word 2013. Це дійсно прикро. Тому що цю функціональну можливість я знаходжу дуже зручною, але вона обмежує мене у виборі версії іншого ПЗ. Але можливо все виправиться в наступних версіях.
P.S.
Особисто мені даний інструмент дійсно подобається. На жаль, я не можу описати підсумкові результати його впровадження, так як це, з різних причин, процес нешвидкий. У будь-якому випадку, я вважаю, що Axiom може бути корисний навіть для простого ознайомлення з такими «звірками» як системи управління вимогами.
