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

ГЛАВА 4. Програмна інженерія як сукупність технологій розробки інформаційних систем

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

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

Базовi поняття програмної інженерії

Термін “програмна інженерія” (Software Engineering) вперше вжито в 1968 р., коли створення програмного забезпечення досягло такого ступеня розвитку, що можна застосовувати інженерні технології. Зараз розроблення програмного забезпечення стало справді масовим явищем.

Методи ПІ - це способи розроблення ПЗ, що містять рекомендації щодо послідовності обробки інформації, нотації, правила опису ІС тощо.

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

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

Основні роздiли програмної інженерії:

• аналiз вимог до ІС, яку треба створити;

• детальний проект ІС;

• кодування;

• тестування системи;

• процес супроводження програмного продукту;

• керування конфiгурацiєю;

• забезпечення якостi розроблення;

• забезпечення вiдповiдностi розроблення вимогам її замовникiв та забезпечення вiдповiдностi кодiв проекту;

• процес удосконалення отриманого програмного продукту.

Життєвий цикл ПЗ

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

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

Головні ресурси програмної iнженерiї, що визначають ефективнiсть розроблень, - це час та вартiсть.

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

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

Характерні роботи процесу розроблення:

• Визначення вимог. Збiр та аналiз вимог замовника виконавцем та подання їх у нотацiї, яка є зрозумiлою як замовнику, так i виконавцю.

• Проектування. Перетворення вимог до розроблення у послiдовнiсть проектних рiшень щодо способiв реалiзацiї вимог: формування загальної архiтектури програмної системи та принципiв її прив'язки до конкретного середовища функцiонування; визначення детального складу модулiв кожної з архiтектурних компонент.

• Реалiзацiя. Перетворення проектних рiшень у програмну систему, що реалiзує означенi рiшення.

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

• Експлуатацiя та супроводження готової системи.

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

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

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

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

• побудову моделей діяльності організації, що передбачає обробку матеріалів обстеження;

• побудову двох видів моделей:

• моделі "як є", що відображає існуючий на момент обстеження стан справ та дозволяє зрозуміти, як саме функціонує дане підприємство, а також виявити вузькі місця і сформулювати пропозиції щодо поліпшення ситуації;

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

Перехід від моделі "як є" до моделі "як має бути" можна виконувати двома способами:

1) удосконалюванням існуючих технологій на основі оцінки їхньої ефективності;

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

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

Є кiлька класiв нефункцiональних вимог, суттєвих для бiльшостi ІС, якi виражають обмеження, актуальнi для багатьох проблемних галузей:

• вимоги конфiденцiйностi;

• вiдмовостiйкiсть;

• кiлькiсть клiєнтiв, що одночасно мають доступ до системи;

• вимоги безпеки;

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

• виконавськi якостi системи (обмеження щодо ресурсiв пам'ятi, швидкiсть реакцiї на звернення до системи тощо).

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

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

Тестування програм та систем

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

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

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

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

Верифікація - перевірка відповідності реалізації системи специфікаціям результатів проектування й опису компоненти.

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

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

Усі помилки, що виникають у програмах, прийнято підрозділяти на кілька класів:

• логічні і функціональні помилки;

• помилки обчислень і часу виконання;

• помилки введення-виведення і маніпулювання даними;

• помилки інтерфейсів;

• помилки обсягу та інші.

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

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

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

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

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

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

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

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

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

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

Види супроводження:

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

• адаптивне - адаптація продукту до змінених обставин використання після передачі системи в експлуатацію

• попереджувальне - діяльність із забезпечення адаптивного супроводження на старті розроблень.

Аналіз якості програмного забезпечення

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

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

Атрибути функціональності ПЗ:

• функціональна повнота - атрибут, який показує ступінь достатності основних функцій для вирішення спеціальних завдань відповідно до призначення ПЗ;

• правильність - атрибут, який показує, як забезпечується досягнення правильних та погоджених результатів;

• інтероперабельність - атрибути, які вказують на спроможність ПЗ взаємодіяти з іншими системами і середовищами;

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

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

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

Атрибути надійності ПЗ:

• безвідмовність - атрибути, які визначають частоту відмов через наявність помилок у ПЗ;

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

• відновлюваність - атрибути, які вказують на спроможність програми до перезапуску для повторного виконання й відновлення даних після відмов;

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

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

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

Атрибути зручності застосування ПЗ:

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

• легкість навчання визначається зусиллями на вивчення умов використання;

• оперативність характеризується швидкістю реакції системи на дії користувача;

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

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

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

Атрибути супроводжуваності ПЗ:

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

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

• стабільність - атрибут, що характеризує імовірність модифікації;

• тестованість - атрибут, що характеризує зусилля щодо проведення валидації та верифікації.

Переносність - це здатність ПЗ пристосовуватися до роботи при зміні середовища виконання.

Атрибути переносності ПЗ:

• адаптивність;

• настроюваність;

• сумісність;

• узгодженість;

• інтероперабельність.

Оцінювання якості ПЗ - це дії, які мають визначити, якою мірою ПЗ відповідає своєму призначенню.

Висновки

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

• традицiйнi гiлки iнженерiї мають високий ступiнь спецiалiзацiї, а в програмній інженерії спецiалiзацiя помiтна тiльки у досить вузьких застосуваннях (приміром, операцiйнi системи);

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

• окремi проблеми традицiйної iнженерiї та вiдповiднi їм готовi рiшення добре класифiкованi та каталогiзованi, а у програмній інженерії кожна нова розробка - це нова проблема, у якiй досить важко розглядiти аналогiї з системами, що були побудованi ранiше.

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

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

Список літератури

1. Андон Ф.И., Лаврищева Е.М. Методы инженерии распределенных компьютерных приложений. – К.: Наукова думка, 1997.

2. Бабенко М.П., Лаврищева Е.М. Основи програмної інженерії. Навчальний посібник. – К.: Знання, 2001.

3. Леффингуэлл Д., Уидриг Д. Принципы работы с требованиями к программному обеспечению. Унифицированный подход.-Издательский дом ”Вильямс”,  2001.

4. Соммервилл И. Инженерия программного обеспечения.-Издательский дом ”Вильямс”, 2002 г.

Контрольні питання:

1. У чому суть інженерної і наукової діяльності?

2. У чому специфіка програмної інженерії як інженерної діяльності?

3. Який вигляд мають продукти програмної інженерії?

4. Що таке життєвий цикл розробки програмного забезпечення?

5. Які бувають етапи процесу розробки програмного забезпечення?

6. Що таке верифікація інформаційного продукту?

7. Що таке валидація інформаційного продукту?

8. У чому полягає супроводження інформаційних продуктів?

9. Що таке помилка в інформаційному продукті?

10. Хто входить до команди тестувачів?

11. За якими параметрами оцінюють якість ІС?

З повагою ІЦ “KURSOVIKS”!