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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Якщо оцінка ЗСТ знаходиться між 1 і 2 - якість артефакту дуже низька. Рекомендується переробити не тільки тестований артефакт, але і батьківський, для того, щоб внести однозначність до представленої там інформації. В цьому випадку може потрібно декілька сесій ЗСТ після доопрацювання артефактів.
• Для артефактів з оцінкою від 2 до 3 потрібне доопрацювання оцінюваного артефакту і рекомендується перегляд батьківського артефакту для того, щоб зрозуміти, що саме привело до втрати інформації. Додаткові ЗСТ-сесії не потрібні.
• Якщо середня оцінка від 3 до 4, потрібне доопрацювання тестованого артефакту, щоб виправити неточності.
• Якщо оцінка більше 4, це означає, що артефакт задовільної якості, доопрацювання не передбачається.

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

Цілком очевидно, що використання зворотного трасування надає двоякий вплив на об'єктно-орієнтовані метрики складності розроблюваного програмного забезпечення:

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

Тим самим повинно відбуватися зниження надійності програмного забезпечення.

• 2. З іншого боку, поліпшується супровід програмного забезпечення, що повинно приводити до поліпшення надійності створюваного ПЗ.

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

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

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

• Whitepaper про зворотне семантичне трасування (eng)

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

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

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