Зворотне семантичне трасування

Зворотне семантичне трасування (ОСТ)- метод контролю якості, який дозволяє виявляти помилки, витік або спотворення інформації при створенні проектних артефактів: документації, коду і т. д. Метод найбільш цінний на ранніх стадіях розробки програмного забезпечення, при створення вимог та архітектури майбутньої системи за відсутності виконуваного коду для тестування. ОСТ є частиною P-Modeling Framework.

Зміст

[ред.] Вступ

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

Найчастіше зворотне семантичне трасування застосовується для:

Перевірки UML моделей;
Перевірки змін у вимогах;
Перевірка виправлень помилок у коді;
Швидкій адаптації нової людини в команді (новому члену команди дають завдання провести сесію ОСТ — він знайомиться з програмою, документацією,набагато швидше, тому що йому необхідно не просто прочитати матеріал, але і проаналізувати його).

[ред.] Ролі

Основними дійовими особами в процесі зворотного семантичного трасування є:

[ред.] Процес

[ред.] Визначити всі артефакти проекту та їх взаємозв'язки

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

У загальному випадку, кількість ОСТ сесій визначається важливістю артефактів для проекту та рівнем контролю якості для цього артефакту (тестування, верифікація, рецензії тощо)

Кількість ОСТ сесій визначається на етапі планування проекту.

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

[ред.] Розставити пріоритети для артефактів

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

Дуже висока(1): якість артефакту дуже важлива для загальної якості продукту та впливає на успіх проекту загалом. Приклади таких артефактів: специфікація вимог, архітектура системи, виправлення критичних помилок у системі, ризики дуже ймовірно.
Висока (2): Артефакт має вплив на якість фінального продукту. Наприклад: тест кейси, вимоги до інтерфейсу та юзабіліті, дефекти з високим пріоритетом, ризики з високою ймовірністю.
Середня (3): артефакт має середній чи опосередкований вплив на якість кінцевого продукту. Наприклад: план проекту, дефекти із середнім пріоритетом.
Низька(4): артефакт має незначний вплив на якість програмного продукту, що розробляється. Наприклад: завдання програмістів, косметичні дефекти, ризики з низькою ймовірністю.

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

Низький(1): Не передбачено тестування чи перевірки (рецензії), непорозуміння та втрати інформації дуже ймовірні, над артефактом працює розподілена команда, існує мовний бар'єр тощо.
Середній(2): Рецензію не передбачено, над артефактом працює нерозподілена команда.
Достатній(3): Передбачено рецензування чи парне програмування, над артефактом працює нерозподілена команда.
Відмінний(4): Для артефакту передбачено парне програмування,верифікація та/або тестування, автоматичне або юніт тестування. Існують інструменти для створення або тестування артефактів.

[ред.] Визначити, хто проводитиме ОСТ

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

[ред.] Провести ОСТ

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

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

Після цього реверс-інженери беруть артефакт і відновлюють вихідний текст. ОСТ сесія сама по собі займає близько години (для 1 сторінки тексту, приблизно 750 слів)

[ред.] Оцінити якість артефактів

Щоб завершити сесію ОСТ, необхідно порівняти вихідний і відновлений текст і оцінити якість артефактів. Рішення про переробку, доопрацювання та виправлення артефактів робиться на підставі цієї оцінки.

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

Критерії оцінки та шкала:

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

Кожен експерт дає оцінку, потім обчислюється середня оцінка (середнє арифметичне). Залежно від цієї оцінки, проджект менеджер приймає рішення про виправлення артефактів, переробку їх або доопрацювання.

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

Для артефактів з оцінкою від 2 до 3 потрібно доопрацювання артефакту, що оцінюється, і рекомендується рев'ю батьківського артефакту для того, щоб зрозуміти, що призвело до втрати інформації. Додаткові ОСТ сесії не потрібні.

Якщо середня оцінка від 3 до 4, потрібно доопрацювання артефакту, що тестується, щоб виправити неточності.

Якщо оцінкабільше 4, це передбачає що артефакт хорошої якості, доопрацювання не передбачається.

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