Swebok: Керівництво до зводу знань з програмної інженерії.

 

З 1993 р. IEEE і ACM координують свої роботи в рамках спеціального спільного комітету -Software Engineering Coordinating Committee (SWECC -http://www.computer.org/tab/swecc).Проект SWEBOK був ініційований цим комітетом у 1998 р. Оцінений можливий обсяг змісту SWEBOK і інші фактори привели до того, що було рекомендовано проводити роботи з реалізації проекту не тільки силами добровольців з рядів експертів індустрії і представників найбільших споживачів і виробників програмного забезпечення, але і на основі принципу “повної зайнятості”. Базовий комплекс робіт, у відповідності зі спеціальним контрактом, був переданий у Software Engineering Management Research Laboratory Університету Квебек у Монреалі (Universite du Quebec a Montreal).

Серед компаній, що підтримали цей унікальний проект були Boeing, MITRE, Raytheon, SAP. У результаті проекту, здійсненого за фінансової підтримки цих і інших компаній і організацій, а також з урахуванням його значимості для індустрії, SWEBOK Advisory Committee (SWAC) прийняв рішення зробити SWEBOK загальнодоступним – http://www.swebok.org/ перспективі, якщо удасться забезпечити відповідний рівень фінансування, SWAC вважає за необхідне закінчену версію SWEBOK 2008 зробити також вільно доступною на Web-сайті проекту. Сьогоднішня “публічність” (загальнодоступність) результатів проекту стала можлива, у першу чергу, саме завдяки підтримці SWEBOK Industrial Advisory Board (IAB) – структури, що поєднує представників компаній, що підтримали проект.

Проект SWEBOK планувався у вигляді трьох фаз: Strawman (“солом'яна людина”), Stoneman (“кам'яна людина”) і Ironman (“залізна людина”). До 2004 р. була випущена версія Посібника зі Зводу Знань 3-їй фази -Ironman, тобто максимально наближена до остаточного варіанту і схвалена IEEE у лютому 2005 р. до публікації в якості Trial-версії. Основна мета поточної “пробної ” версії SWEBOK – поліпшити представлення, цілісність і корисність матеріалу керівництва на основі збору й аналізу відгуків на дану версію для того, щоб випустити фінальну редакцію документа в 2008 р.З ряду обгрунтованих причин, “SWEBOK є досить консервативним” [SWEBOK,2004, с.B-2 ].

Після 6 років безпосередніх робіт над документом, SWEBOK включає “лише” 10 галузей знань (knowledge areas, KA). При цьому, що справедливо і для PMBOK, додавання нових галузей знань у SWEBOK досить прозоре. Усе, що для цього потрібне, зрілість (чи, принаймні, явний і швидкий процес досягнення зрілості) і загальноприйнятності відповідної галузі знань, якщо це не призведе до серйозного
ускладнення SWEBOK (*концепція “загальноприйнятності” - generally accepted – визначена в IEEE Std 1490--1998,Adoption of
PMI Standard — A Guide to the Project Management Body of Knowledge).

Важливо розуміти, що програмна інженерія є дисципліною, що розвивається. Більш того, дана дисципліна не стосується питань конкретизації застосування тих чи інших мов програмування, архітектурних рішень або, тим більше, рекомендацій, що стосуються більш-менш розповсюджених чи тих, що розвиваються, з тим чи іншим ступенем активності/помітності технологій (наприклад, web-служб).

Керівництво до зводу знань, а таким є SWEBOK, включає базове визначення й опис галузей знань (наприклад, конфігураційне управління – configuration management) і, безумовно, є недостатнім для охоплення всіх питань, що відносяться до питань створення програмного забезпечення, але, у той же час потрібним для їхнього розуміння.

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

Структура і зміст SWEBOK.

 

Опис галузей знань у SWEBOK побудовано за ієрархічним принципом, як результат структурної декомпозиції. Така ієрархічна побудова звичайно нараховує два-три рівня деталізації, прийнятих для ідентифікації тих чи інших загальновизнаних аспектів програмної інженерії. При цьому, структура декомпозиції галузей знань деталізована тільки до того рівня, що потрібен для розуміння природи відповідних тем і можливості пошуку джерел компетенції й інших довідкових даних і матеріалів. У принципі, вважається, що як такий “звід знань ” з програмної інженерії представлений не в обговорюваному керівництві (SWEBOK),а в першоджерелах (як зазначених у ньому, так і представлених за його рамками) [SWEBOK,2004, с.1-2 ].

SWEBOK описує 10 галузей знань:

1. Software requirements – програмні вимоги

2. Software design – дизайн (архітектура)

3. Software construction – конструювання програмного забезпечення

4. Software testing - тестування

5. Software maintenance – експлуатація (підтримка)програмного забезпечення

6. Software configuration management – конфігураційне управління

7. Software engineering management – управління в програмній інженерії

8. Software engineering process – процеси програмної інженерії

9. Software engineering tools and methods – інструменти і методи

10. Software quality – якість програмного забезпечення.

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

1. Computer engineering

2. Computer science

3. Management

4. Mathematics

5. Project management

6. Quality management

7. Software ergonimics

8. Systems engineering

Варто відзначити, що прийняті розмежування між галузями знань, їх компонентами (subareas) і іншими елементами досить довільні. При цьому, на відміну від PMBOK, галузі знань SWEBOK не включають “входи ” і “виходи ”. Деякою мірою така декомпозиція пов'язані з тим, що SWEBOK не асоційовано з тією чи іншою моделлю (наприклад, життєвого циклу) чи методом. Хоча на перший погляд перші п'ять галузей знань у SWEBOK представлені в традиційній послідовній (каскадній -waterfall) моделі, це не більш ніж слідування прийнятій послідовності висвітлення відповідних тем. Інші галузі і структура декомпозиції галузей представлені за абеткою.

На рис. 1 представлені перші п'ять галузей знань.

Рис. 1. Перші п'ять галузей знань [SWEBOK,2004,с.1-8, рис.2 ]

 

Інженерія вимог

 

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

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

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

Область знань «Вимоги до ПЗ (Software Requirements))) складається у таких розділів:

- інженерія вимог (Requirement Engineering),

- виявлення вимог (Requirement Elicitation),

- аналіз вимог (Requirement Analysis), специфікація вимог (Requirement Specification).

- валідація вимог (Requirement validation),

- керування вимогами (Requirement Management).

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

Модель процесу визначення вимог - це схема процесів ЖЦ, що виконуються від початку проекту і доти, поки не будуть визначені і погоджені вимоги. Таким процесом може бути маркетинг і перевірка виконання вимог у даному проекті.

Керування вимогами до ПЗ полягає в контролі за виконанням вимог і плану­ванні використання ресурсів (людських, програмних, технічних, часових, вартісних) у процесі розроблення проміжних робочих продуктів на етапах ЖЦ і продукту в цілому.

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

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

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

Специфікація вимог до ПЗ - процес формалізованого опису функціональ­них і не функціональних вимог, вимог до характеристик якості відповідно до стан­дарту якості ISO/IEC 9126, які будуть відпрацьовуватися на етапах ЖЦ ПЗ. У спе­цифікації вимог відбивається структура ПЗ, вимоги до функцій, якості і документа-функцій, якості і документації, а також задається архітектура системи і ПЗ, алгоритми, логіка керування і структура даних. Специфікуються також системні вимоги, не функціональні вимоги і вимоги до взаємодії з іншими компонентами і платформами (БД, СКБД, маршаллінг даних, мережа й ін.).

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

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

Керування вимогами - це керування процесами формування вимог на всіх етапах ЖЦ, а також змінами й атрибутами вимог, проведення моніторингу - відно­влення джерела вимог. Керування змінами виникає після того, ПЗ починає працювати в заданому середовищі і виявляє помилки щодо трактування вимог, невиконання деякої окремої вимоги тощо. Невід'ємною складовою процесу керу­вання є трасування вимог для відстеження правильності встановлення і реалізації вимог до системи і ПЗ на етапах ЖЦ, а також зворотний процес відстеження в отриманому продукті реалізованих вимог. Для уточнення деяких вимог або дода­вання нової вимоги складається план зміни вимог, що погоджується з замовником. Внесені зміни спричиняють і зміни в створеному продукті або в окремих його ком­понентах.