1.2 Методологія jar: сумісна розробка вимог до програмного додатку з використанням швидкого тестування

Існують різні методи, покликані поліпшити обмін інформацією між клієнтом і командою розробників. Один клас методів, які використовуються для вироблення технічних вимог, називаються технологією прискореної розробки специфікації додатків (fast application specification techniques, FAST). Спільна розробка вимог до додатка (Joint Application Requirements, JAR) – це технологія FAST, яка призначена для забезпечення повної інтеграції статичного тестування з процесом вироблення вимог. Інтеграція статичного тестування в процес JAR у вигляді його складової частини досягається за рахунок виконання дій, відомих під назвою досконалої підтримки. Досконала підтримка – це організований спосіб інтерактивного аналізу і перегляду вироблених вимог.

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

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

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

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

• Пам'ятати, що одночасно може висловлюватися тільки одна людина. • Перш ніж пропонувати якусь ідею, подумати про те, яка її цінність і чи надасть вона вплив на кінцевий продукт.

• Ретельно формулювати свої пропозиції і після їх аналізу документувати їх в заключному документі.

• Ставити запитання тільки голові.

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

• Під час засідання комісії JAR не допускати прояви ніяких зовнішніх відволікаючих чинників (повідомлень електронної пошти, викликів по мобільному телефону).

• Бути присутнім на засіданнях, бути уважним, творчим і корисним.

Голова знайомить членів комісії з цілями і обмеженнями проекту з створення програмного забезпечення, а також визначає цілі роботи комісії JAR, в числі яких:

• Збір відомостей про потреби та очікування користувачів, а також визначення показників ефективності.

• Аналіз потреб та очікувань користувачів для вироблення словесного опису функціонування системи та окремих функцій, які повинні виконуватися продуктом.

• Вироблення вимог по поставці та модернізації продуктів, які повинні встановлюватися і модернізуватися на робочих місцях користувачів. • Розробка формулювань всіх розділів вимог, які повинні бути висвітлені в підсумковому документі.

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

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

До складу комісії повинні входити досвідчені експерти по вихідним матеріалами (Source matter expert, SME), що володіють глибокими знаннями в області бізнес-правил, областей застосування і потоків даних, які повинні враховуватися під час розробки нової системи.

Далі приведений приклад засідання комісії JAR з використанням швидкісного тестування.

Представники комісії JAR запасаються щонайменше, кількома сотнями чистих аркушів паперу формату А4, десятком котушок липкої стрічки, кількома десятками різнобарвних кулькових ручок, підставкою для документів, різнокольоровими маркерами, ножицями та клейкою стрічкою. Ці матеріали будуть використовуватися під час підготовки і підтримки настінних плакатів, на яких відображаються вимоги. Розташування плакатів на стінах конференц-залу повинно відповідати структурі документа опису вимог. На великих аркушах можуть бути надруковані назви розділів цього документа. Вони можуть підвішуватися на верхній частині стіни, через рівні проміжки, і повинні розташовуватися за годинниковою стрілкою відповідно зі структурою документа.

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

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

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

• Організація роботи робочої групи управління взаємодією

• Організація роботи робочої групи технічного управління

• Виконання проміжних переглядів програми

• Робота з опитувальними листами, інтерв'ю, експлуатаційними сценаріями, отриманими від кінцевих користувачів (випадки використання на мові UML) • Створення прототипів і моделей

• Спостереження за існуючою системою, середовищами та конфігураціями технологічних процесів

• Прийняття або запозичення рішень та здійснення подальшого вибору • Альфа-тестування • Бета-тестування

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