ТЕМА 1
ДИСЦИПІНИ ПРОГРАМНОЇ ІНЖЕНЕРІЇ І ОБЛАСТІ ЯДРА ЗНАНЬ – SWEBOK

 

У даній темі формально визначено запропоновані дисципліни програмної інженерії. Наведено структуру, зміст та їхнє призначення. Подано дефініцію програмної інженерії у вузькому розумінні, запропонованому у ядрі знань SWEBOK, і широкому – продиктованому прикладними досягненнями щодо сформульованих видів програмного забезпечення, так званих цільових об’єктів (програмних проектів, доменів, сімейств програм і систем). Визначені теоретичні і прикладні ознаки, атрибути і об’єкти програмної інженерії. Наведена класифікація її базових понять і цільових об’єктів, а також методів і засобів їх побудови з використанням сучасної теорії програмування і новітніх інструментальних засобів. Вперше подано зміст і набір головних елементів інженерії програмування, а саме, базового процесу, ядра знань РМВОК, стандартів життєвого циклу та якості програмного продукту і визначено призначення кожного окремого елементу та ядра знань SWEBOK, яке містить у собі 10 областей, що умовно поділені на головні області (вимоги, проектування, конструювання, тестування), та організаційні (керування конфігурацією, проектом, якістю та базовим процесом). Опису цих областей і присвячено другий пункт даної теми.

 

1.1. Загальне визначення дисциплін програмної інженерії

Термін програмна інженерія вперше було використано у 1968 р. З того часу протягом 40 років зміст цього поняття поступово змінювався, що обумовлене постійним розвитком програмування, спочатку як мистецтва одинаків, потім як теоретичної та прикладної науки, і, з часом, як інженерної діяльності.

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

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

Спеціально створений комітет фахівців з інформатики при ACM і IEEE Computer Society сформував базове ядро знань SWEBOK (Software Engineering body of Knowledge – 2001р.), у якому в концентрованому вигляді подав концептуальний зміст десятьох базових областей (knowledge areas) та дефініції програмної інженерії (ПІ), зокрема [1-3]. У ядрі знань SWEBOK наведене таке визначення програмної інженерії (воно відповідає глосарію IEEE):

Визначення 1.1. Інженерія програмного забезпечення (SE) це:

1) застосування систематичного, дисциплінованого та вимірюваного підходу до розробки, експлуатації і супроводження програмного забезпечення (ПЗ) із застосуванням інженерних методів до розробки ПЗ;

2) навчальна дисципліна, що вивчає вказані вище підходи.

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

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

 

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

 

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

– у теорії алгоритмів – нормальні алгоритми, обчислювальні функції, машина Тюрінга, алгоритмічні алгебри, граф-схеми, моделі алгоритмів і програм тощо;

– у математичній логіці – логічні числення і логіко-алгебраїчний апарат специфікації програм;

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

– у теорії доведення – математичне доведення за аксіомами і твердженнями програм, вивід теорем, обґрунтування суперечності й алгоритмічно невирішених проблем, а також теорія верифікації програм, теорія надійності ПЗ;

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

Крім цих засад, система знань програмної інженерії містить у собі [4–9]:

– формальні методи програмування – специфікація програм, їхній доказ, верифікація і тестування, а також математичні моделі надійності, ризику тощо;

– прикладні методи, а саме, прийоми, принципи, правила, окремі дії й цілісні процеси життєвого циклу (ЖЦ) виробництва комп’ютерних систем, які є інструментами колективної розробки, що застосовуються виконавцями великих програмних проектів;

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

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

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

Визначення 1.2. Інженерія програмного забезпечення розділ комп’ютерної науки, який вивчає методи і засоби побудови комп’ютерних програм; відображає закономірності розвитку та узагальнює накопичений досвід програмування; оперує об’єктами (модулями, компонентами, програмними аспектами тощо) та визначає автоматизовані операції щодо їх виробництва; виробляє правила і порядок інженерної діяльності і керування технологічним процесом побудови з простих об’єктів нових, більш складних, об’єктів (програмного забезпечення, програмних систем (ПС), сімейств систем, програмних проектів тощо), а також методи виміру й оцінки готового продукту.

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

Таким чином, програмна інженерія – це наукова і інженерна дисципліни виробництва програмних продуктів (рис. 1.2).

 

Рис.1.2. Наукова і інженерна дисципліни інженерії програмного забезпечення

 

На перетині областей визначення ПІ (овалів на рис. 1.2) – теорія та практика побудови складних програмних об’єктів. Теорія побудови – це теорія їхнього програмування за абстрактними специфікаціями (графовими і структурними схемами, функціями і композиціями, дескрипторами і номінативними даними, сценаріями (use case діаграми), а також формальна перевірка відповідності об’єктів специфікаціям за методами доведення, верифікації, інспекції тощо. Практика побудови – це застосування теоретичних і практичних методів інженерії програмування за допомогою використання засобів перевірки (верифікації, валідації, тестування) специфікацій об’єктів, інструментів їх послідовного трансформування до результуючого коду та інженерія оцінки і сертифікації різних показників якості (надійності, продуктивності, ефективності тощо) виготовленого програмного продукту.

 

1.1.1. Програмна інженерія як наукова дисципліна

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

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

1) основні поняття і об’єкти;

2) теорію програмування і методи керування виготовленням продукту;

3) засоби і інструменти процесів розробки продукту.

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

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

Надамо загальне визначення цільових об’єктів у ПІ.

Визначення 1.3. Програмна (прикладна) система (Application) – комплекс інтегрованих програм і засобів, що реалізують набір взаємопов’язаних функцій деякої предметної області в заданому середовищі. У комплекс можуть входити: прикладні системи (наприклад, програми розрахунку зарплати, обліку матеріалів на складі тощо), загальносистемні програмні засоби (наприклад, транслятор, редактор, СКБД тощо), спеціалізовані програмні засоби для реалізації функцій захисту інженерія ПС (або application engineering), що містить у собі процеси ЖЦ, методи розробки і процедури керування, а також методи і засоби оцінки продуктів і процесів з метою їх удосконалення.

Визначення 1.4. Програмне забезпечення – сукупність програмних засобів, які реалізують функції комп’ютерної системи (або функції технічної апаратно- програмної системи), включаючи загальносистемні засоби (наприклад, ОС, СКБД, вбудовані підсистеми контролю показників технологічних процесів, оброблення сигналів тощо) та прикладні програмні системи. Так, функціями деякої ОС є керування задачами, програмами, даними і т.п. Спосіб виготовлення – інженерія розробки цільових програм для задач з ПЗ.

Визначення 1.5. Сімейство систем (Systems family) сукупність програмних систем із загальним (незмінним для всіх членів сімейства) і керованим (змінним) набором характеристик, що задовольняють визначені потреби прикладної області (домену). Спосіб виготовлення – інженерія домену (Domain Engineering) або конвеєрне виробництво однотипних ПП за єдиною схемою на основі спеціально розроблених базових членів сімейства й інших готових програмних ресурсів (assets) за допомогою базового процесу або автоматизованої лінійки продукту (Product line).

Визначення 1.6. Програмний проект – унікальний і інтегрований комплекс взаємозалежних заходів, орієнтованих на досягнення цілей і задач об’єкта розробки за визначеними вимогами до строків, бюджету та характеристик очікуваних результатів діяльності від нього. Спосіб виготовлення – інженерія процесу розробки і менеджменту проекту.

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

2. Теорія програмування – сукупність методів, мов і засобів опису та проектування цільових об’єктів, а також методів їхнього доведення, верифікації і тестування [6-8]. Разом об’єкти теорії програмування в програмній інженерії використовують формальні методи керування проектом (персоналом, матеріальними та фінансовими ресурсами) і його окремими характеристиками. Відповідно до проведеної нами класифікації методів теорії програмування у програмній інженерії застосовуються такі (рис. 1.3):

 

Рис. 1.3. Сукупність методів програмної інженерії

 

– методи програмування: теоретичні (алгебраїчний, алгоритмічний, експлікативний, алгоритмічний, концепторний, VDM, RAISE тощо) і прикладні (об’єктний, компонентний, аспектний, генерувальний тощо), призначені для проектування різних типів цільових об’єктів;

– методи перевірки правильності за формальними процедурами (твердження, вивід, доказ);

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

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

 

1.1.2. Програмна інженерія як інженерна дисципліна

Програмна інженерія як інженерна дисципліна (або власне інженерія) – це сукупність прийомів виконання діяльності, пов’язаної з виготовленням програмного продукту для різних видів цільових об’єктів із застосуванням методів, засобів і інструментів наукової складової програмної інженерії [8-10]. Основу інженерії становлять наступні базові елементи процесу виготовлення програмного продукту (рис. 1.4):

1) ядро знань SWEBOK, як набір теоретичних концепцій і формальних визначень методів і засобів розробки та керування програмними проектами, які можуть застосовуватися в інженерії програмування;

2) базовий процес ПІ, як стрижень процесної діяльності в організації- розробнику програмного продукту;

3) стандарти, як набір регламентованих правил конструювання проміжних артефактів у процесах ЖЦ;

4) інфраструктура – умови середовища та методичне забезпечення базового процесу ПІ і підтримка дій його виконавців, що займаються виробництвом програмного продукту;

5) менеджмент проекту (РМВОК) – ядро знань з керування промисловими проектами – набір стандартних процесів, а також принципів і методів планування і контролювання роботами у проекті [11];

6) засоби та інструменти розробки програмних продуктів.

 

Рис. 1.4. Базові складові інженерної дисципліни

 

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

Програмну інженерію будемо розглядати з двох точок зору:

– як інженерну діяльність, у якій інженери різних категорій виконують роботи в рамках проекту, використовуючи відповідні теоретичні методи і засоби ПІ, що рекомендовані у ядрі знань SWEBOK, а також стандарти процесів проектування цільових об’єктів за вибраними методами;

– як систему керування проектом, якістю і ризиками з використанням правил і положень стандартів ЖЦ, якості та менеджменту проекту.

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

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

Далі (у пп. 1–5) наведено загальну характеристику базових елементів інженерної дисципліни виготовлення програмного продукту, показаних на рисунку 1.2.

1. Ядро знань SWEBOK – стислий опис концептуальних основ програмної інженерії. Структурно ділиться на 10 розділів (knowledge areas), які умовно можна розкласти за двома категоріями: проектування продукту і інженерна діяльність. Перша категорія – це методи і засоби розробки (формування вимог, проектування, конструювання, тестування, супровід), друга категорія – методи керування проектом, конфігурацією і якістю та базовим процесом організації-розробника (детальніше див. у п. 1.2 конспекту лекцій).

Методи ядра знань програмної інженерії менеджер проекту зіставляє з відповідними стандартними процесами ЖЦ, виконання яких забезпечує послідовна розробка програмного продукту через наповлення базового процесу програмної інженерії методами з ядра знань SWEBOK, а також задачами і діями стандартного ЖЦ, що обумовлює його застосовність до потреб конкретної організації- розробника щодо певної регламентованої послідовності розробки і супроводу програмного продукту. Все це створює технологічний базис інженерії виготовлення конкретного продукту (або низки однотипних продуктів) в організації. На початкових стадіях розробки виконуються процеси визначення вимог до продукту, вироблення проектних рішень і каркасу (абстрактної архітектури) майбутнього продукту. На основі вимог і каркасу розробляються або вибираються готові прості об’єкти для «наповлення» цього каркасу змістом для подальшого його доведення до стану готового продукту.

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

3. Інфраструктура – це набір технічних, технологічних, програмних (методичних) та людських ресурсів організації-розробника, необхідних для виконання підпроцесів базового процесу програмної інженерії, орієнтованого на виконання договору з замовником програмного проекту. До технічних ресурсів належать: комп’ютери, пристрої (принтери, сканери тощо), сервери і т.п., до програмних – загальносистемне ПЗ середовища розробки, напрацювання колективу, оформлені у вигляді компонентів повторного використання, та інформаційне забезпечення. Технологічні та методичні ресурси складають методики, процедури, правила, рекомендації стандартів з процесу і керування персоналом разом з комплектом документів, що встановлює регламент виконання і регулювання процесів ЖЦ, застосовуваних для розв’язання конкретних задач проекту. Людські ресурси – це групи розробників і служб керування проектом, планами, якістю, ризиком, конфігурацією, а також перевірки правильності виконання проекту розробниками [9-11].

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

 

Рис. 1.5. Загальна інфраструктура проекту

 

Після виконання проекту і отримання досвіду побудови конкретного продукту, базовий процес і його окремі елементи, подані на рисунку 1.3, можуть удосконалюватися (доопрацюванням або зміною прийомів, доробкою, змінюванням, додаванням нових засобів) відповідно до вимог стандарту ДСТУ ISO/IEC 15504-7 («Оцінювання процесів ЖЦ ПЗ. Настанови з удосконалення процесу») з метою підвищення рівня можливостей і оцінки потужності процесу.

Готовність всіх видів забезпечення організації-розробника, досконалість виконуваних процесів і якість створеного в ній продукту надають підстави для оцінки зрілості організації або сертифікації процесів виробництва ПЗ. Для оцінювання зрілості може застосовуватися модель зрілості CMM (Capability Maturity Models) [11], запропонована Інститутом програмної інженерії SEI США, або інша модель, наприклад, Bootstrap, Trillium тощо. Модель СММ встановлює рівні зрілості організації щодо створення програмних продуктів. Рівень зрілості визначається наявністю в організації базового процесу усіх необхідних видів ресурсів (у тому числі і фінансових), відповідних стандартів і методик, а також професійних здібностей (зрілості) членів колективу організації, здатних виготовляти програмні продукти в заданий строк і встановленої вартості.

4. Стандарти ПІ встановлюють технологічно відпрацьований набір процесів зі строго визначеним і регламентованим порядком проведення різних видів робіт з програмної інженерії, зв’язаних з розробкою програмного продукту і оцінюванням його якості, ризику тощо. Стандарти у галузі програмної інженерії регламентують різні напрями діяльності щодо проектування програмних продуктів. Вони стандартизують термінологію і поняття, життєвий цикл, якість, вимірювання, оцінювання продуктів і процесів. Найбільш важливими серед них є стандарт ISO/IEC 12207 «Процеси життєвого циклу програмного забезпечення» (та його дещо застарілий вітчизняний еквівалент ДСТУ 3918–99), серія стандартів ДСТУ ISO/IEC 14598 «Оцінювання програмного продукту», стандарт ДСТУ ISO 15939 «Процес вимірювання», серія стандартів ISO/IEC 15504 «Оцінювання процесів ЖЦ ПЗ», базові стандарти з якості – ISO 9001 «Системи керування якістю. Вимоги», ДСТУ 2844–94, ДСТУ 2850–94, що регламентують різні аспекти забезпечення якості ПП. Серед стандартів, що безпосередньо пов’язані з якістю ПЗ, слід також назвати проект нової серії стандартів ISO/IEC TR 9126 «Програмна інженерія. Якість продукту».У цих стандартах узагальнені знання спеціалістів з технології проектування і інженерних методів керування розробкою, починаючи від встановлення вимог і закінчуючи оцінкою якості продукту і можливою його подальшою сертифікацією.

Процеси ЖЦ в стандарті ISO/IEC 12207 подають загальні положення, задачі і регламентовані дії з проектування, а також рекомендації щодо застосування цих процесів для розробки і контролю проміжних результатів. У стандарті містяться також описи організаційних процесів – планування, керування і супроводження. Процес планування призначений для складання планів, графіків робіт з виконання проекту і розподілу робіт між різними категоріями фахівців, а також для контролю планів і виконаних робіт. Процес керування проектом визначає задачі та дії з керування роботами фахівців проекту, які володіють теорією керування, а також відстеження планових строків, що встановлені замовником проекту. Процес супроводження містить у собі дії з виявлення й усунення знайдених недоліків і внесення нових або видалення деяких функцій у продукті.

Ядро знань SWEBOK і стандарти з ЖЦ мають взаємопов’язані складові. Процесам ЖЦ зіставляються необхідні методи ядра і тим самим визначається базовий процес створення проекту, що доповнюється методиками і обмеженнями щодо вироблення продукту. Діючі фундаментальні моделі ЖЦ (каскадна, спіральна тощо), що широко використовуються на практиці, пропонують привнесення в них стилю проектування і реалізації деяких видів продуктів.

5. Менеджмент проекту – це керування виконанням проекту з використанням теорії керування та процесів ядра знань РМВОК (Project Management body of knowledge) [12]. У серії настанов до PMBOK, розроблених американським Інститутом керування проектами (www.pmi.org), подано положення і правила керування часовим виробничим циклом побудови унікального продукту в рамках проекту, спочатку без урахування рівня комп’ютеризації промисловості (1987 р.), а потом і з його врахуванням (2000 р.). Ядро знань PMBOK містить у собі опис лексики, структури процесів і областей знань, відображаючи сучасну практику керування проектами в різних областях промисловості. У ньому визначені процеси ЖЦ проекту і головні області знань, згруповані за задачами: ініціація, планування, використання, моніторинг і керування, завершення. Крім того, область знань «інтеграція» визначає прийняття рішень про використання ресурсів у кожний момент виконання проекту і керування загальними задачами проекту.

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

На теперішній час настанови до PMBOK та SWEBOK введені в статус стандартів, а саме: ISO/IEC TR 19759 («Guide to the Software Engineering Body of Knowledge (SWEBOK)) та IEEE Std.1490 «IEEE Guide adoption of PMI Standard. A Guide to the Project Management Body of Knowledge) та [15].

6. Засоби та інструменти ПІ. Проектування об’єктів виконується за допомогою сучасних візуальних мов, наприклад UML, мов програмування (С++, Java, Object Pasсal тощо) з використанням відповідних інструментальних середовищ, що містять у собі необхідні мовні перетворювачі і інструменти підтримки різних артефактів ПП, що розробляються. Як засоби їх проектування застосовують діаграми використання, потоків даних, класів, поведінки, а також шаблони, каркаси тощо.

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

У середовищі проектування цільових об’єктів застосовуються сучасні технології і відповідні інструментально-технологічні пакети інструментів (наприклад, технології RUP, MSF та інструменти Rational Rose, Microsoft Visual Studio тощо). Вони містять не тільки інструменти проектування різних типів цільових об’єктів проектів, а й засоби і інструменти керування проектом, зокрема персоналом, планами та якістю продуктів.

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

Класифікацію загальних інструментів, рекомендованих для застосування до всіх видів об’єктів у процесах ЖЦ, подано в ядрі знань SWEBOK.

 

1.1.3. Програмна інженерія як виробнича дисципліна

Загальне призначення програмної інженерії – практичне виготовлення комп’ютерних програм, систем і інструментів із застосуванням теоретичних і інженерних методів ПІ.

Головна особливість практики у майбутньому – це використання розроблених готових програм і інформаційних ресурсів Інтернету. Доступ до них може здійснити будь-який користувач і одержувати безкоштовно або на комерційній основі готовий програмний ресурс як сервіс. Він може бути одноразово використаний для розв’язання відповідної задачі, або як окрема програма постійного і багаторазового застосування в деякому домені. Сьогодні сформувалися три інженерні підходи до застосування таких готових ресурсів: reusing engineering, application engineering, domain engineering. Вони використовують як готові ресурси повторно використовувані компоненти, засоби і системи. Застосування готових ресурсів, як багаторазово використаного готового продукту, дає значну економію при виробництві з них нових програмних систем і сімейств систем. Усі види компонентів, а саме, КПВ зберігаються в сховищах проекту – репозитарії [8, 9].

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

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

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

Лінійки продуктів. Технологічні прийоми виробництва програмних продуктів з готових компонентів і програмних систем втілені в так звані лінійки продуктів, що відповідають конвеєрному виробництву програмних продуктів на ринковій основі. Практичні інструменти цього виробництва – SWEBOK, PMBOK і стандарти, а також сучасні інструментально-технологічні системи і середовища з набором необхідних інструментів та засобів.

Автоматизація виробництва ПП. Прикладом такого середовища і реалізації в ній інженерного і виробничого підходів до виготовлення програмних продуктів є система Visual Studio Teams Systems фірми Microsoft. У ній реалізована технологія проектування, кодування, тестування та впровадження програмних проектів. У середовищі системи підтримується технологія підбору, розподілу і виконання робіт різними групами спеціалістів. Вони природно мають різні рівні знань і поділяються на чотири категорії. Кожний спеціаліст отримує роботу відповідно до своїх здібностей, починаючи з підготовчої категорії. Перехід в іншу, вищу, кваліфікаційну категорію залежить від якості виконання попереднього завдання з програмування і отриманого досвіду. Спеціалісти, що входять до четвертої категорії, несуть відповідальність за правильність розробки продукту в цілому в даному середовищі.

Фірма Microsoft впровадила цю систему в ряді університетів України, тому студенти мають змогу брати участь у розробленні пілотних або конкретних проектів і тим самим отримувати практичний досвід застосування базових положень програмної інженерії щодо колективного виготовлення програмних продуктів.

 

1.1.4. Дисципліна керування

Базисом цієї дисципліни є класична теорія керування складними системами, сучасний менеджмент проекту та відповідний стандарт IEEE Std.1490 – настанова до ядра знань PMBOK (Project Management Body of Knowledge). Теорія керування, а саме теорія організаційного керування, розроблена академіком В.М. Глушковим. Вона перевірена практикою побудови технологічних процесів у металургійній, суднобудівельній і хімічній промисловостях, а також знайшла впровадження у масове виробництво (зокрема, в АСУ «Львів»).

Теорія керування складними системами мала розвиток і за кордоном, особливо у теорії планування виробництвом. Так, на фірмі «Dupon» з метою планування й складання планів-графіків великих комплексів робіт для модернізації її заводів було розроблено метод CRM (Critical Path Method), базисом якого є графічне представлення робіт і різних видів операцій із зазначенням часу їхнього виконання. Інший метод мережного планування PERT (Program Evaluation and Review Technique) було випробувано при реалізації проекту розробки ракетної системи «Polaris», що поєднувала близько 3800 підрядників із кількістю операцій понад 60 тис. Застосування цього методу було настільки успішним, що проект було завершено на два роки раніше запланованого терміну. Кожний з цих методів виник у надрах промислового виробництва, адаптований до середовища програмування і став базовим в індустрії програмних продуктів.

Теорія керування і планування відображена в стандарті PMBOK. У ньому визначені процеси ЖЦ проекту і головні області знань, згруповані за задачами: ініціація, планування, використання, моніторинг і керування, завершення. Головна область знань цього ядра – «інтеграція», визначає концепцію керування організаційною діяльністю колективу виконавців проекту, груповану на методах прийняття рішень про ресурси, загальні задачі, служби контролю правильності проекту та вкладання в задану замовником вартість [3, 4, 6].

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

 

1.1.5. Економічна дисципліна

Економіка ПІ є самостійною дисципліною зі своєю теорією і практикою оцінювання вартісних, часових і експертних показників щодо складання контрактів на створення ПП, прийняття проектних рішень, подання вимог, розробка архітектури тощо, визначення ризиків проектування за заданими ресурсами, проведення розрахунків за роботи виконавців та отриману якість ПП. Ця дисципліна є найбільш розвинутою з точки зору методів економічних розрахунків у ПІ, а саме, наявних методологій прогнозування розміру ПП (FРA– Function Points Analyses, Feature Points, Mark-H Function Points, 3D Function Points тощо), оцінювання витрат на розробку ПП за допомогою сімейства моделей COCOMO або інших математичних моделей (Angel, Slim, Seer тощо) [4].

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

Таким чином, наукові, інженерні, виробничі напрями ПІ, дисципліни керування і економіки, а також SWEBOK, СТАНДАРТИ, PMBOK є головними складовими програмної інженерії. Вони зв’язані між собою процесами ЖЦ, методами проектування і керування розробкою програмних проектів. Ключеві моменти з питань вироблення програмних продуктів на процесній і інженерній основі відображено змістовним багатогранником фундаменту ПІ (рис. 1.6).

 

Рис. 1.6. Базові «кити» програмної інженерії

 

Висновки. Проведено системний розгляд програмної інженерії з точки зору науки, інженерії, економіки та керування виробництвом ПП. Надано необхідні аргументи і обґрунтування визначень як цільових об’єктів проектування, так і програмної інженерії. Охарактеризовано основні риси наведених дисциплін ПІ, орієнтованих на індустріальну розробку програмних систем, сімейств систем та доменів (див. детальніше тему 8). До базису програмної інженерії віднесені стандарти ЖЦ, якості програмних продуктів та менеджменту проектів, які висвітлені відповідно у темах 2, 9, 10.

 

1.2. Характеристика областей знань з інженерії програмного забезпечення – SWEBOK

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

Ядро знань SWEBOK – основний науково-технічний документ, що відображає знання та досвід багатьох іноземних і вітчизняних фахівців з програмної інженерії [1–10] і узгоджується з регламентованими процесами ЖЦ стандарту ISO/IEC 12207.

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

Для подання понятійного апарату областей знань SWEBOK проведемо умовне розділення областей на головні (п’ять областей для розробки ПС, рис. 1.7) і допоміжні організаційні області (п’ять областей, що забезпечують інженерію керування розробкою ПС, рис. 1.8).

У кожній області наведені ключові поняття, підходи і методи проектування різних типів ПС. Розподіл областей на основні і допоміжні відповідає структурі розподілу процесів стандарту ISO/IEC 12207 (див. тему 2), виконання яких визначається методами і засобами, запропонованими в ядрі знань SWEBOK.

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

 

Рис.1.7. Головні області знань SWEBOK

 

Рис.1.8. Організаційні області знань SWEBOK

 

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

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

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

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

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

– інженерія вимог (Requirement Engineering);

– виявлення вимог (Requirement Elicitation);

– аналіз вимог (Requirement Analysis);

– специфікація вимог (Requirement Specification);

– валідація вимог (Requirement validation);

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

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

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

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

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

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

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

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

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

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

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

 

1.2.2. Проектування програмного забезпечення

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

Область знань «Проектування ПЗ (Software Design)» складається з таких розділів:

– базові концепції проектування ПЗ (Software Design Basic Concepts);

– ключові питання проектування ПЗ (Key Issue in Software Design);

– структура й архітектура ПЗ (Software Structure and Architecture);

– аналіз і оцінка якості проектування ПЗ (Software Design Quality Analysis and Evaluation);

– нотації проектування ПЗ (Software Design Notations);

– стратегія і методи проектування ПЗ (Software Design Strategies and Methods).

Базова концепція проектування ПЗ – це методологія проектування архітектури за допомогою різних методів (об’єктного, компонентного й ін.), процеси ЖЦ (стандарт ISO/IEC 12207) і техніки – декомпозиція, абстракція, інкапсуляція й ін. На початкових стадіях проектування предметна область декомпозується на окремі об’єкти (при об’єктно-орієнтованому проектуванні) або на компоненти (при компонентному проектуванні). Для подання архітектури програмного забезпечення вибираються відповідні артефакти (нотації, діаграми, блок-схеми і методи).

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

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

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

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

Аналіз і оцінка якості проектування ПЗ – це заходи щодо аналізу сформульованих у вимогах атрибутів якості, функцій, структури ПЗ, з перевірки якості результатів проектування за допомогою метрик (функціональних, структурних і ін.) і методів моделювання і прототипування.

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

Структурні нотації – це структурне, блок-схемне або текстове подання аспектів проектування структури ПЗ з об’єктів, компонентів, їх інтерфейсів і взаємозв’язків. До нотацій відносять формальні мови специфікацій і проектування: ADL (Architecture Description Language), UML (Unified Modeling Language), ERD (Entity–Relation Diagrams), IDL (Interface Description Language) тощо. Нотації містять у собі мовний опис архітектури й інтерфейсу, діаграм класів і об’єктів, діаграм сутність–зв’язок, конфігурації компонентів, схем розгортання, а також структурні діаграми, що задають у наочному вигляді оператори циклу, розгалуження, вибору і послідовності.

Поведінкові нотації відбивають динамічний аспект роботи системи та її компонентів. Ними можуть бути діаграми потоків даних (Data Flow), діяльності (Activity), кооперації (Colloboration), послідовності (Sequence), таблиці прийняття рішень (Decision Tables), передумови і постумови (Pre-Post Conditions), формальні мови специфікації (Z, VDM, RAISE) і проектування.

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

В об’єктно-орієнтованому проектуванні ключову роль відіграє спадкування, поліморфізм й інкапсуляція, а також абстрактні структури даних і відображення об’єктів. Підходи, орієнтовані на структури даних, базуються на методі Джексона і використовуються для подання вхідних і вихідних даних структурними діаграмами. Метод UML призначений для опису сценаріїв роботи проекту у наочному діаграмному вигляді. Компонентне проектування ґрунтується на використанні готових компонентів (reuse) з визначеними інтерфейсами і їх інтеграції в конфігурацію, як основи розгортання компонентної системи для її функціонування в операційному середовищі.

Формальні методи опису програм ґрунтуються на специфікаціях, аксіомах, описах деяких попередніх умов, твердженнях і постумовах, що визначають заключну умову одержання програмою правильного результату. Специфікація функцій і даних, якими ці функції оперують, а також умови і твердження – основа доведення правильності програми.

 

1.2.3. Конструювання програмного забезпечення

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

Область знань «Конструювання ПЗ (Software Construction)» містить у собі такі розділи:

– зниження складності (Reduction in Complexity);

– попередження відхилень від стилю (Anticipation of Diversity);

– структуризація перевірок (Structuring for Validation), – використання стандартів (Use of External Standards).

Зниження складності – це мінімізація, зменшення і локалізація складності конструювання.

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

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

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

Попередження відхилень від стилю. Для розв’язання різних задач конструювання застосовуються різні стилі конструювання (лінгвістичний, формальний, візуальний).

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

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

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

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

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

До таких стандартів відносять: мови програмування (Java, Ада 95, С++ і ін.), інтерфейси мов програмування (МП) і прикладні інтерфейси платформ Windows (COM, DCOM), CORBA і ін. При конструюванні використовують стандарти мов опису даних (XML, SQL і ін.), засобів комунікації (COM, CORBA і ін.), інтерфейсних мов (POSIX, IDL, APL), UML і ін.

Перелічені вище розділи області знань «Конструювання ПЗ» у ядрі знань SWEBOK об’єднуються в групу «Основи конструювання». Крім того, розглядаються групи розділів «Керування конструюванням» та «Практичні міркування». Опишемо першу з них детальніше.

Керування конструюванням – це керування процесом конструювання ПЗ, планування, оцінка виконання плану і розробка заходів щодо внесення змін.

Моделі конструювання містять у собі набір операцій, послідовність дій і результатів. Види моделей визначаються стандартом ЖЦ, методологіями і практиками. Деякі стандарти ЖЦ за своєю природою орієнтовані на конструювання засобами екстремального програмування і раціонального уніфікованого процесу – RUP (Rational Unified Process) [13].

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

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

 

1.2.4. Тестування програмного забезпечення

Тестування ПЗ – це процес перевірки готової програми в статиці (перегляди, інспекції, налагодження вихідного коду) і в динаміці (прогін на наборі тестових даних) з метою перевірки різних шляхів виконання програми і порівняння отриманих результатів із заздалегідь заданими.

Існує дві форми перевірки коду – модульна й інтеграційна. Спочатку використовують стандарти (IEEE 829:1996 і IEEE 1008:1987) з перевірки і тестування модулів. Потім проводиться інтеграційне тестування модулів системи і їх інтерфейсів у динаміці виконання. Під час різних видів перевірок збираються дані про помилки, дефекти, відмови тощо і оформляється відповідна документація (таблиці типів помилок, частоти і часу виявлення відмов і ін.). Зібрані дані використовуються при оцінюванні характеристик якості готового ПЗ, наприклад, надійності.

Область знань «Тестування ПЗ (Software Testing)» містить у собі такі розділи:

– основні концепції і визначення тестування (Testing Basic Concepts and definitions);

– рівні тестування (Test Levels);

– техніки тестування (Test Techniques);

– метрики тестування (Test Related Measures);

– керування процесом тестування (Managing the Test Process).

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

Основна концепція тестування – це базові терміни, ключові проблеми і їхній зв’язок з іншими областями знань. Тестування визначається як процес перевірки правильності програми в динаміці її виконання за тестовими даними. При тестуванні виявляються недоліки: відмови (faults) і дефекти (defects) як причини порушення роботи програми, збої (failures) як небажані ситуації, помилки (errors) як наслідки збоїв і ін. Базове поняття тестування – тест, що виконується в заданих умовах і за наборами даних. Тестування вважається успішним, якщо знайдено дефект або помилка, і вони відразу усуваються. Ступінь тестованості визначається критерієм покриття системи тестами, перевірки всіх можливих шляхів виконання програм і імовірності припущення стосовно того, що може з’явитися збій або помилкова ситуація в системі.

Рівні тестування:

– тестування окремих елементів – це перевірка окремих, ізольованих і незалежних одна від одної частин ПЗ;

– інтеграційне тестування орієнтоване на перевірку зв’язків і взаємодії компонентів (інтерфейсів), що можуть розміщуватися на різних архітектурних платформах розподіленого середовища;

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

На всіх рівнях тестування застосовуються методи:

– функціонального тестування, які забезпечують перевірку реалізації функцій, що визначені у вимогах, а також правильності їх виконання;

– регресійного тестування, що орієнтоване на повторне вибіркове тестування системи або її компонентів після внесення в них змін на тих самих тестах, що і до модифікації;

– тестування ефективності – це перевірка продуктивності, пропускної здатності, максимального обсягу даних і системних обмежень відповідно до вимог;

– стрес-тестування – це перевірка поведінки системи при максимально припустимому навантаженні або в разі його перевищення;

– альфа- і бета-тестування – це тестування системи (альфа) групою тестувальників організації-розробника і тестування системи «зовнішніми» користувачами (бета);

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

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

Техніки тестування базуються на певних теоретичних і практичних положеннях щодо проектування (компонентного, об’єктно-орієнтованого, сервісного і т.п.), а також на таких даних:

– інформація про структуру ПЗ або системи в документації («біла скринька»);

– підбір тестових наборів даних для перевірки правильності роботи компонентів і системи в цілому без знання їх структури («чорна скринька»);

– аналіз граничних значень, таблиць прийняття рішень, потоків даних, статистики відмов і ін.;

– блок-схеми побудови програм і складання наборів тестів для покриття системи цими тестами;

– виявлені і зафіксовані в таблицях системи дефекти, перед- і постумови виконання, структурні характеристики системи (кількість модулів, обсяг даних тощо).

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

Процес тестування документується і, відповідно до стандарту IEEE 829:1995, містить у собі опис тестових документів, їх зв’язку між собою і з задачами тестування. Без документації на процес тестування неможливо провести сертифікацію продукту за моделями зрілості, зокрема, моделлю СММ [11]. Після завершення тестування оцінюється вартість і ризики ПЗ, викликані збоями або недостатньо надійною роботою системи. Вартість тестування – одне з обмежень, на основі якого приймається рішення про його припинення або продовження.

Керування тестуванням:

– планування процесу тестування (складання планів, тестів, наборів даних) і оцінювання показників якості готового продукту;

– проведення тестування компонентів повторного використання і патернів як основних об’єктів складання ПЗ;

– генерація необхідних тестових сценаріїв, що відповідають середовищу виконання ПЗ;

– верифікація правильності реалізації системи і валідація реалізації вимог до ПЗ;

– збирання даних про відмови, помилки і виявлені непередбачені ситуації при виконанні програмного продукту;

– підготовка звітів за результатами тестування й оцінка характеристик системи.

Відповідно до стандарту ISO/IEC 12207 тестування ПЗ розглядається як невід’ємна частина ЖЦ.

 

1.2.5. Супровід програмного забезпечення

Супровід ПЗ – сукупність дій із забезпечення його роботи, внесення змін при виявленні помилок, адаптації ПЗ до нового середовища функціонування, а також підвищення продуктивності або поліпшення деяких характеристик ПЗ. У зв’язку з вирішенням так званої проблеми 2000 року (пов’язаної з кодуванням дат у новому тисячолітті, зокрема, у двохсимвольному форматі) супроводження почав розглядатися, як більш важливий процес, що здійснюють розробники. Після змін система має вирішувати ті самі задачі, а також мати план перенесення інформації в інші БД. Супровід відповідно до стандартів ISO/IEC 12207 і ISO/IEC 14764 проводиться з метою виконання і модифікації програмного продукту в процесі експлуатації за умови збереження його цілісності.

Область знань «Супровід ПЗ (Software Maintenance)» складається з таких розділів:

– основні концепції (Basic Concepts);

– процес супроводження (Process Maintenance);

– ключові питання супроводу ПЗ (key Issue in Software Maintenance);

– техніки супроводу (Techniques for Maintenance).

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

Основні концепції – це базові визначення і термінологія, підходи до еволюції і супроводу ПЗ, до оцінки вартості супроводу тощо. До основних концепцій можна віднести ЖЦ ПЗ (стандарт ISO/IEC 12207) і складання документації. Головне призначення цієї області знань полягає у виконанні готової програмної системи, фіксації помилок, що виникають при виконанні, дослідженні їх причин, аналізі необхідності модифікації системи з метою усунення помилок, оцінці вартості робіт із проведення змін функцій і системи в цілому. Розглядаються проблеми, пов’язані з ускладненістю продукту при великій кількості змін, і методи її подолання.

Процес супроводження містить у собі моделі процесу супроводу і планування діяльності людей, що проводять запуск ПЗ, перевірку правильності його виконання і внесення в нього змін. Цей процес згідно з стандартом ISO/IEC 14764 проводиться шляхом:

– коригування, тобто зміни продукту для усунення виявлених помилок або нереалізованих задач;

– адаптації, тобто настроювання продукту в умовах експлуатації, що змінилися, або в новому середовищі виконання;

– поліпшення, тобто еволюційної зміни продукту для підвищення продуктивності або рівня супроводу;

– перевірки ПЗ, пошуку і виправлення помилок при експлуатації системи.

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

Техніка супроводу (цей розділ називають також еволюцією ПЗ). Відомий фахівець в області ПЗ Дж. Леман (1970 р.) запропонував розглядати супровід як еволюційну розробку програмних систем, оскільки здана в експлуатацію система не завжди цілком завершена, її треба змінювати протягом терміну експлуатації. Внаслідок змін система стає більш складною і погано керованою. У зв’язку з цим виникає проблема зменшення її складності. До технологій еволюції ПЗ відносять реінженерію, реверсну інженерію і рефакторинг.

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

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

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

 

1.2.6. Керування конфігурацією

Керування конфігурацією – це ідентифікація компонентів системи, визначення функціональних, фізичних характеристик системи, апаратного і програмного забезпечення для контролю виконання, внесення змін і трасування конфігурації. Процес керування визначено як один з допоміжних процесів ЖЦ (ISO/IEC 12207), виконуваний технічним і адміністративним менеджментом проекту. При цьому складаються звіти про зміни, внесені у конфігурацію, і ступінь їхньої реалізації, а також проводиться перевірка відповідності внесених змін заданим вимогам.

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

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

Область знань «Керування конфігурацією ПЗ (Software Configuration Management – SCM)» складається з таких розділів:

– керування процесом конфігурації (Management of SMC Process), – ідентифікація конфігурації ПЗ (Software Configuration Identification);

– контроль конфігурації ПЗ (Software Configuration Control);

– облік статусу (поведінка або стани) конфігурації ПЗ (Software Configuration Status Accounting);

– аудит конфігурації ПЗ (Software Configuration Auditing);

– керування версіями ПЗ і доставкою (Software Release Management and Delivery).

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

– систематичне відстеження внесених змін в окремі складові частини конфігурації, виконання аудита змін і автоматизованого контролю за внесенням змін у конфігурацію системи або в ПЗ;

– підтримку цілісності конфігурації, її аудит і забезпечення внесення змін в елементи конфігурації;

– ревізію конфігурації з метою перевірки наявності розроблених програмних або апаратних засобів і узгодження версії конфігурації з заданими вимогами;

– трасування змін у конфігурації на процесах супроводу й експлуатації ПЗ.

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

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

Облік статусу або стану конфігурації ПЗ – комплекс заходів для визначення ступеня зміни конфігурації, а також правильності внесених змін у систему при супроводі. Інформація і кількісні показники накопичуються у відповідній БД і використовуються при складанні звітності, оцінюванні якості і виконанні процесів ЖЦ.

Аудит конфігурації – це діяльність, що виконується для оцінки відповідності продукту і процесів стандартам, інструкціям, планам і процедурам. Аудит визначає ступінь задоволення конфігурації функціональним і фізичним (апаратним) характеристикам системи.

Керування версіями ПЗ – це відстеження наявної версії компонентів конфігурації; складання компонентів; створення нових версій системи на основі існуючих шляхом внесення змін у конфігурацію; узгодження версії продукту з вимогами і проведеними змінами на процесах ЖЦ; забезпечення оперативного доступу до інформації про елементи конфігурації і системи, до яких вони належать. Дане керування містить у собі такі основні поняття.

Базис (baseline) – формально позначений набір елементів ПЗ, зафіксований на процесах ЖЦ.

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

Складання ПЗ – об’єднання коректних елементів і конфігураційних даних у єдину виконувану програму.

 

1.2.7. Керування інженерією програмного забезпечення

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

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

Загальні питання керування проектом містяться в ядрі знань РMBOK [12], а також у стандарті ISO/IEC 12207 – Software life cycle processes, де керування проектом розглядається як організаційний процес ЖЦ.

Область знань «Керування інженерією ПЗ (Software Engineering Management)» складається з таких розділів:

– організаційне керування (Organizational Management);

– керування процесом/проектом (Process/Project Management);

– інженерія вимірювання ПЗ (Software Engineering Measurement).

Організаційне керування – це планування і складання графіка робіт, підбір і керування персоналом, контроль виконання й оцінка вартості робіт згідно з прийнятими стандартами і договорами з замовником. Головним об’єктом організаційного керування проектом є персонал (навчання, мотивація й ін.), комунікації між співробітниками (зустрічі, презентації й ін.), а також попередження й усунення ризику невиконання проекту. Для керування проектом створюється спеціальна структура колективу. Фахівці розподіляються за видами робіт і розв’язують задачі проекту під керуванням менеджера з урахуванням заданої вартості і термінів розробки. Для реалізації задач проекту підбираються необхідні програмні, інструментальні й апаратні засоби.

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

У задачі керування проектом входять також уточнення вимог, перевірка їх відповідності заданим специфікаціям характеристик якості, а також верифікація функцій проекту. Процес керування базується на планових термінах, що відображені мережними діаграмами PERT (Program Evaluation and Review Technique), СРМ (Сrіtісаl Path Method). У них указуються роботи, зв’язки між ними і час виконання.

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

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

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

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

Інженерії вимірювання – удосконалювання процесів керування проектом; оцінювання часових витрат і вартості ПЗ, їх регулювання; визначення категорій ризиків і відстеження чинників для регулярного розрахунку ймовірностей їх виникнення; перевірка заданих у вимогах показників якості окремих продуктів і проекту в цілому [9].

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

 

1.2.8. Базовий процес программної інженерії

Процес інженерії – є метарівнем, що визначає основні поняття, способи реалізації, оцінювання, вимірювання, дії з керування змінами й удосконалення самого процесу. Як уже згадувалася в п. 1.1.2., для оцінювання й удосконалення процесу програмної інженерії застосовується модель зрілості CMM [11], яку розроблено Інститутом програмної інженерії SEI (Software Engineering Institute) США. Ця модель встановлює рівні готовності організації-розробника ПЗ створювати задовільно, середньо, добре і дуже добре програмну продукцію. Поняття рівня готовності визначається наявністю в організації необхідних ресурсів (людських, програмних, технічних і фінансових), стандартів і методик, а також здатністю колективу створювати програмні продукти. Модель СММ має п’ять рівнів. Перший і другий рівні фіксують недостатню готовність виконувати розробку продукту. Третій – п’ятий рівні характеризують певний ступінь готовності, зрілості і здатності фахівців (а, значить, і організації) виготовляти, відповідно, середній, гарний і відмінний продукт. Чим вище рівень зрілості, тим більше вимог ставиться до процесу програмної інженерії, придатного для виконання цілей і задач утворення продукту, що задовольняє користувача.

Існують різновиди цієї моделі: СММ – SW (Software) для оцінки зрілості ПЗ, CMMI (CMM Integrated) – для обліку потреб великих державних структур в ПЗ (США), а також інші моделі, наприклад, Bootstrap – для оцінки зрілості малих і середніх комерційних компаній, стандарт ISO 15504 (Software Process Improvement and Capability) – для удосконалення процесу (наприклад, удосконалювати процес на другому рівні, щоб одержати сертифікат на третій рівень зрілості).

Концепція зрілості процесу програмної інженерії ґрунтується на процесі ПЗ (software process), широті його можливостей (software process capability), результативності (software process performance) і зрілості (software process maturity). Процес ПЗ у моделі СММ – це множина діяльностей (activities), методів (methods), практичних прийомів (practices), що використовують при розробки ПЗ шляхом планування робіт і оцінювання проміжних результатів, які приводять до кінцевого продукту високої якості.

Область знань «Процес програмноїінженерії (Software Engineering Process)» складається з таких розділів:

– концепції процесу інженерії ПЗ (Software Engineering Process Concepts);

– інфраструктура процесу (Process Infrastructure);

– визначення процесу (Process Definition);

– оцінки процесу (Process Assessments);

– якісний аналіз процесу (Qualitative Process Analysis);

– виконання і змінювання процесу (Process Implementation and Change).

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

Інфраструктура процесу містить у собі ресурси (людські, технічні, інформаційні і програмні), стандарти, методики керування якістю, проектом і структуру колективу розробників ПЗ типу: команда, бригада, експериментальна фабрика (Experimental Factory), каркас виробництва на лінії продуктів (Framework for Product Line Practice) і ін. До основних задач інфраструктури належать керування і комунікації в колективі, інженерні методи виробництва програмного продукту й удосконалення процесу з накопиченим досвідом розробки ПЗ.

Визначення процесу ґрунтується на: типах процесів і моделей (каскадна, спіральна, ітераційна й ін.); моделях ЖЦ процесів і засобів, стандартах ЖЦ ПЗ ISO/IEC 12207 і ISO/IEC 15504, IEEE std. 1074 і IEEE std. 1219; методах і нотаціях подання процесів і автоматизованих засобів їх підтримки. Основною метою процесу є підвищення якості одержуваного продукту, поліпшення різних аспектів програмної інженерії, автоматизація і удосконалення процесів.

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

Оцінки стосуються також технічних робіт у сфері програмної інженерії, керування персоналом і якості ПЗ. Для цього проводяться експериментальні дослідження середовища, збирання інформації, моделювання, класифікація отриманих помилок і дефектів, а також статичний аналіз недоліків процесу порівняно з існуючими стандартами (наприклад, ISO/IEC 12207) і потенційних аспектів необхідності вдосконалювати процес.

Якісний аналіз процесу полягає в ідентифікації і пошуку «слабких місць» у процесі створення ПЗ на початку його функціонування і після експлуатації. Розглядається такі техніки аналізу: огляд даних і порівняння процесу з основними положеннями стандарту ISO/IEC 12207, збирання даних про якість процесів; аналіз головних причин відмов у функціонуванні ПЗ, відкіт назад від точки виникнення відхилення до точки правильної роботи системи для з’ясування причин зміни процесу. На якість результатів проекту і процесу впливають застосовувані інструменти і досвід фахівців.

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

 

1.2.9. Методи і інструменти програмної інженерії

Методи забезпечують проектування, реалізацію і виконання ПЗ. Вони накладають деякі обмеження на інженерію ПЗ у зв’язку з особливостями застосування їхніх нотацій і процедур, а також забезпечують оцінку і перевірку процесів і продуктів. Інструменти забезпечують програмну підтримку окремих методів інженерії ПЗ для автоматизованого виконання задач процесів ЖЦ.

Область знань «Методи та інструменти інженерії ПЗ (Software Engineering Tools and Methods)» складається з розділів:

– інструменти інженерії ПЗ (Software Engineering Tools);

– методи інженерії ПЗ (Software Engineering Methods).

Методи інженерії ПЗ – це евристичні методи (heuristic methods), формальні методи (formal methods) і методи прототипування (prototyping methods).

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

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

– мови і нотації специфікації (specification languages and notations), орієнтовані на модель, властивості і поведінку;

– уточнення специфікації (refinement specification) шляхом трансформації в кінцевий результат, близький до кінцевого програмного продукту, що виконується;

– методи верифікації/доведення (verification/proving properties), що використовують твердження (теореми), перед- і постумови, формально описуються і застосовуються для встановлення правильності специфікації програм.

Методи доведення застосовувалися в основному в теоретичних експериментах. Понад 25 років їх застосування було обмежено через трудомісткість і економічну невигідність. У 2005 р. проблема верифікації знову набула актуальності у запропонованому новому міжнародному проекті «Цілісний автоматизований набір інструментів для перевірки коректності ПС» (Т. Хоар, «Открытые системы», 2006, № 6), який поставив наступні перспективні задачі:

– розробка єдиної теорії побудови й аналізу програм;

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

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

Формальні методи верифікації будуть охоплювати всі аспекти створення і перевірки правильності програм. Це приведе до створення потужної верифікованої виробничої основи і сприятиме значному зменшенню помилок у ПЗ (стосовно доведення і верифікації див. тему 6).

Методи прототипування (Prototyping Methods) засновані на використанні прототипу ПЗ для моделювання на ньому завдань нової системи і базуються на:

– стилях прототипування, що уособлюють тривалість використання прототипів, наприклад, стиль створення тимчасово використовуваних прототипів (throw away);

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

– техніках оцінки/дослідження (evaluation) результатів прототипування.

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

Інструменти роботи з вимогами (Software Requirements Tools) – це:

– інструменти розробки (Requirement Development) і керування вимогами (Requirement Management), орієнтовані на аналіз, збирання, специфікування і перевірку вимог;

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

Інструменти проектування (Software Design Tools) – це інструменти для створення ПЗ із застосуванням базових нотацій (структурної SADT/IDEF, моделювання UML і т.п.).

Інструменти конструювання ПЗ (Software Construction Tools) – це інструменти для трансляції і об’єднання програм. До них належать:

– редактори програм (program editors) і програми редагування загального призначення;

– компілятори і генератори коду (compilers and code generators) як самостійні засоби об’єднання програмних компонентів в інтегрованому середовищі для одержання вихідного продукту з використанням препроцесорів, складальників, завантажників і ін.;

– інтерпретатори (interpreters), які забезпечують контрольоване виконання програм за їх описом. Намітилася тенденція злиття інтерпретаторів і компіляторів (наприклад, Java, в.NET);

– відлагоджувачі (debuggers), призначені для перевірки правильності опису вихідних програм і усунення помилок;

– інтегроване середовище розробки (IDE – integrated development environment) та бібліотеки компонентів (libraries components), що є утворюють середовище виконання процесу розробки ПС;

– програмні платформи (Java, J2EE і Microsoft.NET) і платформи для розподілених обчислень (CORBA і WebServices, тощо).

Інструменти тестування (Software Testing Tools) – це:

– генератори тестів (test generators), що допомагають у розробці сценаріїв тестування;

– засоби виконання тестів (test execution frameworks), які забезпечують виконання тестових сценаріїв і відслідковують поведінку об’єктів тестування;

– інструменти оцінки тестів (test evaluation tools), які підтримують оцінювання результатів виконання тестів і ступеня відповідності поведінки тестованого об’єкта очікуваній поведінки;

– засоби керування тестами (test management tools), які забезпечують інженерне керування процесом тестування ПЗ;

– інструменти аналізу продуктивності (performance analysis tools), кількісної її оцінки та оцінки поводження програм у процесі виконання.

Інструменти супроводу (Software Maintenance Tools) містять у собі:

– інструменти полегшення розуміння (comprehension tools) програм, наприклад, різні засоби візуалізації;

– інструменти реінженерії (reengineering tools) підтримують діяльність з перетворення програм і зворотної інженерії (reverse engineering) для відновлення (артефактів, специфікації, архітектури) застарілого ПЗ або генерації нового продукту.

Інструменти конфігураційного керування (Software Configuration Management Tools) – це:

– інструменти відстеження (tracking) дефектів;

– інструменти керування версіями;

– інструменти керування складанням, випуском версії (конфігурації) продукту та його інсталяції.

Інструменти керування інженерною діяльністю (Software Engineering Management Tools) підрозділяються на:

– інструменти планування і відстеження ходу проектів, кількісної оцінки зусиль і вартості робіт у проекті (наприклад, Microsoft Project 2003);

– інструменти керування ризиками, які використовуються для ідентифікації, моніторингу ризиків і оцінки нанесеного ушкодження;

– інструменти кількісної оцінки властивостей ПЗ шляхом вимірювань і розрахунків остаточного значення надійності і якості.

Інструменти підтримки процесів (Software Engineering Process Tools) розділені на:

– інструменти моделювання та опису моделей ПЗ (наприклад, UML і його інструменти);

– інструменти керування програмними проектами (наприклад, Microsoft Project); – інструменти керування конфігурацією для підтримки версій і всіх артефактів проекту.

Інструменти забезпечення якості (Software Quality Tools) діляться на дві категорії:

– інструменти інспектування для підтримки перегляду (review) і аудиту;

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

Додаткові аспекти інструментального забезпечення (Miscellaneous Tool Issues) стосуються:

– техніки інтеграції інструментів (платформ, представлень, процесів, даних) для їх природного сполучення в інтегрованому середовищі;

– метаінструментів для генерації інших інструментів для ПЗ;

– оцінки інструментів при їх еволюції.

 

1.2.10. Якість програмного забезпечення

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

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

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

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

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

Остаточна оцінка якості проводиться відповідно до стандарту ISO/IEC 14598. Якість може підвищуватися за рахунок постійного поліпшення використовуваного продукту виявленням, усуненням дефектів у ПЗ і їх запобіганням.

Область знань «Якість ПЗ (Software Quality)» складається з наступних розділів:

– концепції якості ПЗ (Software Quality Concepts);

– визначення і планування якості (Definition & Planning for Quality);

– техніки й види діяльності, що забезпечують гарантію якості, валідацію і верифікацію (Activities and Techniques for Software Quality Assurance, Validation & Verification –V&V);

– вимірювання при аналізі якості ПЗ (Measurement in Software Quality Analysis).

Концепції якості ПЗ – це зовнішні і внутрішні характеристики якості, їхні метрики, а також моделі якості, визначені на множині цих характеристик, що наведені в стандартах з якості і в [8, 9] – це шість характеристик і кожна з них має кілька атрибутів. До характеристик якості належать:

– функціональність (functionality);

– надійність (realibility);

– зручність застосування (usability);

– ефективність (efficiency);

– супровід (maitainnability);

– переносність (portability).

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

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

Планування якості призначено для підтримки керування процесами досягнення якості продуктів проекту (зокрема проміжних робочих) і ресурсів – програмних, технічних, виконавських і ін. Воно також передбачає керування вимогами до процесів і продуктів і полягає в наступному:

– визначення продукту термінами заданими характеристиками якості;

– планування процесів для гарантії одержання необхідної якості;

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

У стандарті ISO/IEC 12207 визначені спеціальні процеси забезпечення якості – верифікація, валідація (атестація), спільний аналіз і аудит.

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

Інспекція ПЗ – аналіз і перевірка різних видів подання системи і ПЗ (специфікації, архітектурної схеми, діаграм, початкового коду тощо). Виконується на всіх процесах ЖЦ розробки ПЗ.

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

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

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

Вимірювання при аналізі якості ПЗ ґрунтується на метриках продукту і даних, зібраних у процесі створення продукту при заданих ресурсах: оцінок процесів, ПЗ і його моделей, і передбачає документування вимірів. Оцінювання якості продукту полягає у вимірюванні і оцінюванні якісних показників за допомогою даних про різні типи помилок і відмов під час тестування ПЗ і виконання коду на тестових даних. Ці дані аналізуються, перевіряються і використовуються при якісній і кількісній оцінки ПЗ.

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

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

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

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

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

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

Висновки. Запропоновано нове тлумачення програмної інженерії з точки зору науки, інженерії, економіки і керування виробництвом ПП. Наведено дефініцію програмної інженерії як спадкоємиці програмування і комп’ютерної науки, розглянуто її головний аспект – керування роботами і колективом. Обґрунтовано теоретичні і прикладні ознаки та атрибути програмної інженерії і її дисциплін. Визначено їхню структуру, зміст та концепції, а також їхні базові елементи. Встановлено зв’язки основних елементів ПІ через SWEBOK, стандарт ISO/IEC 12207 і PMBOK. Разом вони забезпечують дисципліни вироблення програмних продуктів на процесах розробки, керування і регулювання діяльності розробників програмних продуктів.