Лекція на тему Програмна інженерiя, НУДПСУ

Програмна iнженерiя - система методiв та засобiв розробки, експлуатацiї та супроводження програмного забезпечення, придатна до масового вiдтворення.

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

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

БАЗОВ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шень у програмну систему, що реал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чно до 82 млрд долар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йк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) відновити попередній стан системи, внести необхідні коректи­ви і повторити виконання послуги із старою стратегією;

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

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

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

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

• додаткові перевірки коректності даних, які передають зовнішні системи або окремі компоненти однієї системи.

Усі зазначені вище дії втілюються в додаткових компонентах проекту і призводять до додаткових витрат на певні надмірні пере­стороги, які є ціною за надійність функціонування системи. Доцільність таких витрат визначається виключно специфікою сис­тем. Якщо наслідки помилок незворотні, наприклад, як у систем підвищеного ризику (космічні та ядерні системи, моніторинг хворих, керування реальними об*єктами), доводиться йти на дублювання процесів і додаткові перевірки. Іноді навіть використовують пара­лельну роботу кількох команд або взаємну перевірку комп'ютерів, що працюють паралельно, коли один з них здійснює моніторинг іншого. Так, кажуть, що для керування системою ШАТЛ сім комп*ютерів дублюють один одного.

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

Трансформація проекту в програму

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

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

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

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

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

Тестування охоплює такі основні види робіт:

- розробку програмного продукту на етапах життєвого циклу та верифікацію результатів на кожному етапі;

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

- керування виконанням тестів та аналіз результатів тестування;

- повторне тестування.

Тестування становить від 30 % до 50 % трудомісткості робіт зі створення коду. Історично першим різновидом тестування було налагодження – перевірка програмного об'єкта на наявність у ньому помилок і усунення їх.

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

Класифікація відмов та помилок робиться за міжнародним стандартом АМ5І/ІЕЕЕ-729-83.

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

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

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

Відмова може бути наслідком таких причин:

- помилкова специфікація або пропущена вимога, тобто специ­фікація точно не відображає припущення користувача;

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

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

- проект програми може мати помилки (наприклад, опис компо­ненти містить алгоритм контролю несанкціонованого доступу, що не управляється коректно);

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

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

Помилки та причини появи їх на етапах ЖЦ

Є підходи до класифікації помилок у програмному забезпеченні відповідно до їхнього розподілу за етапами життєвого циклу і до джерел Їхнього виникнення:

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

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

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

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

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

Характерними помилками цього етапу є:

- неадекватність опису специфікаціями вимог кінцевих корис­тувачів;

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

- невідповідність вимог замовника до окремих і загальних вла­стивостей програмного забезпечення;

- некоректність опису функціональних характеристик;

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

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

- визначення інтерфейсу користувача із середовищем;

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

- визначення процесу опрацювання інформації або зв'язків між процесами (наслідок некоректного визначення взаємозв'язків компо­нентів та процесів);

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

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

- визначення умов виникнення можливих помилок у програмі;

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

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

- безконтрольність допустимості значень вхідних та вихідних параметрів, індексів масивів, циклів, ділення на О та ін.;

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

- порушення стандартів кодування (погані коментарі, нераціо­нальне виділення модулів і компонентів тощо);

- використання одного імені для позначення кількох об'єктів або кількох імен на позначення одного об'єкта;

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

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

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

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

Тести програм і систем

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

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

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

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

 Команда тестувачів

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

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

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

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

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

 СУПРОВОДЖЕННЯ ПРОГРАМНИХ СИСТЕМ. Супроводження – будь-які роботи з внесення змін до системи після того, як її було передано користува­чеві для експлуатації. На відміну від обладнання, яке з часом потре­бує ремонту, програм­не забезпечення не "зношується", тому процес супроводження націлений на підтримку передусім еволюціонування системи, тобто на зміну її функцій та властивостей. Серед причин, котрі можуть зумовити потребу змін, можна назвати типові, а саме:

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

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

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

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

Серед видів діяльності із здійснення супроводження прийнято розрізняти такі:

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

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

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

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

АНАЛІЗ І ДОСЯГНЕННЯ ЯКОСТІ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ. Якість програмного забезпечення –  сукупність властивостей, що визначають спроможність забезпечення задоволь­нити запити замовника, які він висловив як вимоги до розробки.

Аналіз якості у програмний інженерії орієнтований на:

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

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

• забезпечення надійності як основної характеристики гарантії якості програмного забезпечення .

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

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

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

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

Виконання перелічених процесів включають такі дії:

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

- ревізія керування, розробки і забезпечення гарантії якості про­грамного забезпечення, а також всієї проектної документації (звіти, графіки розробки, повідомлення);

- контроль проведення формальних інспекцій та оглядів;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

До підхарактеристик зручності застосування програмного забез' печення належать:

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

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

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

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

Ефективність забезпечується множиною атрибутів, які показу­ють взаємозв'язок між рівнем виконання програмного забезпечення і кількістю використовуваних ресурсів у початкових умовах. До ре­сурсів належать засоби, апаратура, інші використовувані продукти, матеріали (наприклад, папір для друкувального пристрою), послуги штатного обслуговуючого персоналу тощо. До підхарактеристик ефективності програмного забезпечення на­лежать:

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

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

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

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

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

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

- стабільність: атрибути, які вказують на ризик модифікації;

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

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

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

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

- настроюваність (простота інсталяції): показники необхідних зусиль для запуску або інсталяції даного програмного забезпечення в певному середовищі;

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

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

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

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

• ухвалення рішення про ступінь відповідності досягнутого рівня якості розробленого ПЗ заданому рівню;

• опис ознак та властивостей, реалізованих у ПЗ;

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

МЕНЕДЖМЕНТ ІНЖЕНЕРІЇ ПРОГРАМНИХ СИСТЕМ. Дослідження проблем планування й керування проектом пока­зали, що в 1998 р. закічилися невдало 26 % з усіх програмних проектів (порівняно з 40 % у 1997 р.), а 40 % значно перевищили кошторис або не функціонують (33 % в 1997 р.). Крім того, як відзначається, число невдалих проектів зменшилося в компаніях, котрі працюють над невеликими за об'ємом, а тому більш легкими для керування проектами.

Аналіз проектів, що зазнали краху, дозволив виділити 10 причин провалів: 1) керівники проектів не розуміють вимог замовника; 2) масштаби проекту визначено неправильно; 3) зміни проекту провадяться з великими труднощами; 4) змінам піддають обрану технологію проектування; 5) замовник змінює вимоги; 6) взятий термін виконання проекту нереальний; 7) користувач не ухвалює деяких рішень; 8) інвестиції втрачено; 9) для реалізації проекту не вистачає виконавців; 10) менеджери проекту не застосовують прогресивних методів керівництва.

Чинники успішного створення якіс­ного проекту: а) проект починати з правильного кроку; б) підтримувати темпи роботи; в) забезпечити прогрес і правильні рішення; г) провести постаналіз (так званий "посмертний аналіз") завер­шених проектів.

ПОВТОРНЕ ВИКОРИСТАННЯ В ПРОГРАМНІЙ ІНЖЕНЕРІ. ЇОднією з характерних рис інженерної діяльності є використання готових рішень або деталей. Однак усі, хто працює над створенням реальних систем, знають, що промислове використання готових рішень у програмній інженерії ще не стало повсякденною практикою. Якщо у світі працюють майже 8 млн програмістів, то приблизно 80 % з них працюють над створенням програм обліку й організаційного управління на кількох рівнях: окремого підрозділу фірми, окремого аспекту діяльності фірми, фірми в цілому, корпорації, галузі і, нарешті, держави. Це, переважно, задачі розрахунків, статистики, допомоги в прийнятті рішень при управлінні різноманітними ресурсами - кад­ровими, фінансовими тощо.

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

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

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

Накопичений досвід розробки систем програмного забезпечення може бути зафіксовано в різноманітних формах, починаючи від кон­кретних параметризованих програмних модулів і кінчаючи програм­ними архітектурами та середовищами. Далі будемо називати повторно використовуваними компонентами (ПВК} елементи знань про минулий досвід розробки систем програмування, якщо:

1) їх можуть використовувати не лише їхні розробники;

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

З повагою ІЦ "KURSOVIKS"!