13.5. Супровід програм.

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

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

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

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

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

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

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

Вимоги до інструментальних засобів автоматизації розробки надійних ПС якнайповніше викладені в стандарті ІЕЕЕ 1209-1992. Стандарт містить рекомендації за оцінкою і вибиранням інструментальних засобів, що підтримують процеси життєвого циклу програмних засобів, включаючи процеси управління проектами, процеси розробки і процеси, що йдуть за розробкою, а також інтегральні процеси життєвого циклу ПС. Для оцінки і вибору інструментального середовища і САSЕ -средств стандартом рекомендується испрльзовать приведені нижче набори правил і критеріїв. Групи критеріїв в стандарті виділені і сформовані з урахуванням загальних вимог стандарту IS0 9126:1991 за оцінкою якості програмних продуктів.

Технологічне середовище і САSЕ -средства стандартом рекомендується описувати і вибирати відповідно до показників:

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

• сумісність з іншими інструментальними засобами, включаючи можливість взаємодії і/або прямого обміну даними (наприклад, з системами підготовки текстів і іншими засобами документування, базами даних, репозиторіями і іншими САSЕ -средствами);

• підтримка конкретних методологій, наприклад, объектно-ори- ентированного аналізу, об'єктно-орієнтованого проектування, проектування "згори-вниз";

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

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

• мови специфікацій вимог - можливість САSЕ -средств імпортувати, експортувати або редагувати інформацію вимог, використовуючи формальну мову, контроль несуперечності специфікацій і повноти;

• можливість моделювати аспекти потенційного функціонування системи, що розробляється, на основі вимог і/або проектних даних, наявних у розпорядженні САSЕ -средства, включаючи ефективність системи, інтерфейс оператора, архітектурну продуктивність (час відгуку, завантаження, пропускну спроможність);

• прототипирование - можливість проектування і генерації попередньої версії усієї системи або її частини на основі вимог і/або проектних даних, наявних у розпорядженні САSЕ -средства;

• формування структури звітів, які створюватимуться системою, що розробляється.

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

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

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

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

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

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

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

• здатність САSЕ -средства оцінювати вартість, формувати плани і інші показники проекту за даними, користувачем, що вводиться;

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

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

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

• управління діями з коригування плану проекту, звітів про проблеми і дефекти, що виникли в ході виконання проекту.

Управління конфігурацією версій проекту ПС повинно забезпечувати:

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

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

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

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

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

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

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

• редагування текстів - можливість вводити і редагувати дані в текстовому форматі;

• графічне редагування - введення і редагування даних в графічному форматі;

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

• можливості настільного видавництва для оформлення документації;

• контроль відповідності вихідних результатів CASE -средства стандартам на документацію ПС;

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

Критерії зручності застосування CASE -средства в процесі розробки ПС включають:

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

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

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

• якість документації CASE -средства, включаючи повноту, ясність, читаність, корисність;

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

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

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

• повноту і якість функцій допомоги в режимі "help";

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

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

• легкість інсталяції CASE -средства, як первинною, так і при подальших змінах.

Критерії оцінки ефективності CASE -средства по вимогах стандарту повинні враховувати дані для виконуваних об'єктів і робіт як типового, так і максимального розміру і складності :

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

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

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

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

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

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

Існує безліч визначень якості, в основі поняття якості продукту або послуги лежить ідея про задоволення потреб кінцевого користувача - реального або потенційного споживача. Ось визначення цього поняття відповідно до стандарту ISO 8402:1994.

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

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

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

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

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

Сучасна техніка управління якістю (наприклад, концепція Total Quality Management (TQM)) базується саме на управлінні якістю. На сучасному етапі вже недостатньо мати тільки методи оцінки якості виробленого і використовуваного програмного засобу (вихідний контроль), необхідно мати можливість планувати якість, вимірювати його на усіх етапах життєвого циклу програмного засобу і коригувати процес виробництва програмного забезпечення для поліпшення якості. Міжнародні стандарти серії ISO 9000 регламентують створення системи управління якістю. Проте вони є загальними, лише рекомендаційними. Кожна компанія, що виробляє програмне забезпечення і охоча впровадити у себе дієву систему управління якістю на основі стандартів ISO 9000-ої серії, повинна врахувати специфіку своєї галузі і розробити систему показників якості, яка б відбивала реальний вплив чинників якості на програмний продукт.

Програмне забезпечення як продукт має деякі відмінності від інших промислових продуктів:

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

• великі ресурси витрачаються на стадії планування, реалізації і тестування;

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

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

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

• Усі ці, а також багато інших особливостей має бути враховані в програмі оцінки якості і управління якістю.

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

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

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

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