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

Модель обмеженої гарантії на ПО

Компонентна розробка програм (CBSE - component - based software engineering) припускає створення програмних систем з фрагментів. Достоїнства різних стратегій обговорюються багато років, але немає ніяких ознак того, що компонентна розробка ось-ось стане стандартним підходом до створення програмних систем.

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

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

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

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

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

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

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

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

Вимоги до інструментальних засобів автоматизації розробки надійних ПС якнайповніше викладені в стандарті ІЕЕЕ 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 -средство виконує характерні завдання, наприклад час відповіді на запит.

Дата добавления: 2014-01-04