Системна інженерія програмного забезпечення: введення

1. Системи і системна інженерія
2. Що таке системна інженерія ПО?
3. SwSE і програмна інженерія
4. SwSE і управління проектом
5. функції SwSE
6. аналіз вимог
7. Дизайн програмного забезпечення
8. планування процесів
9. контроль процесів
10. Верифікація, підтвердження і тестування

23.05.2002г.

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

Програмні системи стають все більше і складніше. Класичний приклад - Microsoft Word, який 20 років тому вміщувався на дискеті на 360 Кбайт, а тепер для нього необхідний компакт-диск ємністю 600 Мбайт.

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

Реалізація переважної більшості великих програмних систем не вкладається в заплановані терміни, виходить за рамки кошторису, і при цьому не цілком виправдовує очікування замовника. Цей феномен добре відомий як «криза програмного забезпечення» [ 1 ]. Щоб вирішити цю кризу, розробники програмного забезпечення використовують при створенні продуктів різні інженерні методики.

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

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

У цій статті визначення і процеси зі стандартів IEEE на програмну інженерію [ 2 ] Інтегруються в процес SwSE. Більш докладний виклад цього матеріалу, включаючи детальний покроковий опис розгортання SwSE, міститься в [3].

Системи і системна інженерія

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

Стандарт IEEE Std. 1220-1998 описує процес системної інженерії та її застосування на протязі всього циклу життя виробу [4]. Системна інженерія породжує документи, а не обладнання. Документи пов'язують процеси розробки з циклом життя проекту. Вони визначають передбачувані оточення процесів, інтерфейси та інструменти управління ризиками в рамках всього проекту.

Системна інженерія включає в себе п'ять функцій.

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

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

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

Що таке системна інженерія ПО?

Термін «системна інженерія програмного забезпечення» з'явився на початку 80-х років, і його приписують Вінстону Ройс [ 5 ]. SwSE відповідає за загальне технічне управління системою і підтвердження коректності остаточних системних продуктів. Як і системна інженерія, SwSE породжує документи, а не компоненти. У цьому вона відрізняється від програмної інженерії (software engineering - SwE), породжує комп'ютерні програми та посібники користувача.

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

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

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

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

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

SwSE і програмна інженерія

І SwSE, і SwE - це технічні і управлінські процеси, однак SwE породжує програмні компоненти та описує їх документацію. Більш строго, програмна інженерія включає в себе наступне.

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

Мал. 1 ілюструє зв'язки між системної інженерією, SwSE і SwE. Традиційна системна інженерія виконує початковий аналіз та проектування, а також інтеграцію і тестування остаточної системи.

Мал. 1. Інженерні зв'язку між системної інженерією, системної інженерією програмного забезпечення (SwSE) і програмної інженерії

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

SwSE і управління проектом

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

Мал. 2 ілюструє управлінські зв'язки між проектним менеджментом, SwSE і SwE. Керівництво проектом включає в себе загальне управління розподілом робіт в проекті і повноваження надання ресурсів. SwSE визначає технічний підхід, приймає технічні рішення, взаємодіє з технічними представниками замовника, а також схвалює і приймає кінцевий програмний продукт. SwE відповідає за розробку програмного дизайну, кодування і розробку програмних компонентів.

функції SwSE

У таблиці 1 перераховані п'ять основних функцій системної інженерії, корелюють з SwSE; розміщено короткий опис функцій SwSE.

Таблиця 1. Функції системної інженерії, що корелюють з системної інженерією ПЗ

аналіз вимог

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

Програмні вимоги можна класифікувати наступним чином [ 8 ].

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

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

Дизайн програмного забезпечення

Дизайн програмного забезпечення - це процес вибору і документування найбільш ефективних елементів, які в сукупності будуть реалізувати вимоги до програмної системи [9]. Дизайн визначає специфічний, логічний підхід до задоволення програмних вимог.

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

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

Запропонована в статті методологія архітектурний дизайн відносить до SwSE, а детальний дизайн - до SwE.

планування процесів

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

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

У таблиці 2 показаний приклад поділу функцій планування для проекту програмної системи.

Таблиця 2. Планування процесів і планування проекту

контроль процесів

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

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

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

Таблиця 3. Контроль процесів і контроль проекту

Верифікація, підтвердження і тестування

Процес верифікації, підтвердження і тестування (verification, validation and testing - VV & T) визначає, чи коректний процес інженерії, і чи відповідають продукти пропонованим вимогам [10].

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

VV & T - це безперервний процес моніторингу операцій системної інженерії, SwSE, SwE і проектного менеджменту з метою переконатися, що вони слідують технічним і управлінським планам, специфікаціям, стандартам і процедурам. Крім того, VV & T оцінює проміжні і остаточні продукти проекту SwE. Проміжні продукти включають в себе специфікації вимог, опис архітектури, плани тестування і оцінку результатів. До остаточних продуктів відносяться програмне забезпечення, посібники, навчальні матеріали тощо

SwSE використовує методи та інструментарій VV & T для оцінки вимог специфікацій, опису архітектури і інших проміжних продуктів. Тестування виконується для того, щоб визначити, чи відповідає остаточний продукт специфікаціям вимог даного проекту.

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

Системна інженерія і SwSE - дисципліни, які використовуються в першу чергу для технічного планування «на вході» життєвого циклу системи і для перевірки того, що наприкінці проекту всі плани були виконані. На жаль, в реальних проектах ці дисципліни часто ігноруються.

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

література

1. WW Gibbs, «Software's Chronic Crisis», Scientific Am., 1994, Sept.

2. IEEE, Software Engineering Standards Collection, vols. 1-4, IEEE Press, Piscataway, NJ, 1999.

3. RH Thayer, «Software System Engineering: A Tutorial», Software Engineering Volume 1: The Development Process, 2nd ed., RH Thayer and M. Dorfman, eds., IEEE CS Press, Los Alamitos, Calif., 2002

4. IEEE Std. 1220-1998, Standard for Application and Management of the System Engineering Process, IEEE Press, Piscataway, NJ, 1998.

5. WW Royce, «Software Systems Engineering», seminar presented as part of the course titled Management of Software Acquisition, Defense Systems Management College, Fort Belvoir, Va., 1981-1988

6. IEEE Std. 1058-1998, Standard for Software Project Management Plans, IEEE Press, Piscataway, NJ, 1998.

7. IEEE Std. 610.12-1990, Standard Glossary of Software Engineering Terminology, IEEE Press, Piscataway, NJ, 1990.

8. IEEE Std. 830-1998, Recommended Practice for Software Requirements Specifications, IEEE Press, Piscataway, NJ, 1998.

9. IEEE Std. 1016-1998, Recommended Practice for Software Design Descriptions, IEEE Press, Piscataway, NJ, 1998.

10. IEEE Std. 1012-1998, Standard for Software Verification and Validation, IEEE Press, Piscataway, NJ, 1998.

Річард Тейер ( [email protected] ) - почесний професор програмної інженерії Каліфорнійського університету в Сакраменто, консультує з програмної інженерії та управління проектами, веде дослідження і читає лекції в Університеті Стречклайда (Глазго, Шотландія).

Richard H. Thayer. Software System Engineering: A Tutorial. IEEE Computer, April 2002. Copyright 2002 IEEE Computer Society. Translated and reprinted with permission.