1.6.1. Процес оцінювання та вибору CASEсистем

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

Вхідною інформацією для оцінювання є:

— опис потреб користувачів;

— цілі та обмеження проекту;

— дані про доступні CASEзасоби;

— список критеріїв, що використовуються в процесі оцінювання.

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

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

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

Визначення списку критеріїв базується на користувацьких вимогах і містить:

— вибір критеріїв для використання (див. далі);

— визначення додаткових критеріїв;

— визначення області використання кожного критерію (оцінювання, вибір чи обидва процеси);

— визначення однієї або кількох метрик для кожного критерію оцінювання;

— призначення ваги кожному критерію під час вибору.

Критерії формують базис для процесів оцінювання та вибору і можуть набувати таких форм:

— числові міри в широкому діапазоні значень, наприклад обсяг потрібної пам’яті;

— числові міри в обмеженому діапазоні значень, наприклад простота освоєння, виражена у балах від 1 до 5;

— двійкові міри (істина/неправда, так/ні), наприклад здатність генерування документації у форматі Postscript;

— міри, що можуть набувати одне чи більше з кінцевих множин значень, наприклад платформи, для яких реалізовано CASEзасіб.

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

Критерії вибору CASEзасобів можна поділити на кілька груп.

Група 1. Функціональні характеристики

1. Середовище функціонування:

1.1.  проектне середовище:

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

— область застосування — системи оброблення транзакцій, системи реального часу тощо;

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

1.2.  програмне забезпечення та технічні засоби:

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

— технічні засоби, що підтримуються, — елементи обладнання, що можуть використовуватись CASEзасобом, наприклад пристрої введення/виведення;

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

1.3. технологічне середовище:

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

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

— підтримувана методологія — наприклад, структурний або об’єктноорієнтований аналіз і проектування;

— підтримувані мови — мови програмування (Кобол, Ада, С), мови баз даних і мови запитів (DDL, SQL), графічні мови Postscript, HPGL), мови специфікації проектних вимог та інтерфейси операційних систем (мови керування завданнями).

2. Функції, зорієнтовані на фази життєвого циклу:

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

— створення і редагування діаграм різних типів;

— аналіз графічних об’єктів, а також зберігання та подання проектної інформації у графічному вигляді;

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

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

— моделювання даних — можливості введення та редагування інформації щодо елементів даних системи та їх відношень;

— моделювання процесів — можливості введення та редагування інформації щодо процесів системи та їх відношень;

— проектування архітектури ПЗ — проектування логічної структури ПЗ — структури модулів, інтерфейсів тощо;

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

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

— генерування екранних форм на основі специфікацій вимог та/або проектних специфікацій;

— можливість трасування — наскрізного аналізу функціонування системи від специфікації вимог до кінцевих результатів (встановлення і відстежування відповідностей і зв’язків між функціональними та іншими зовнішніми вимогами до ІС, технічними рішеннями і результатами проектування). Пряме трасування (перевірка врахування всіх вимог) і зворотнє (пошук проектних рішень, не пов’язаних із жодними із зовнішніх вимог);

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

— інші види аналізу;

— автоматизоване проектування звітів;

2.2. реалізація — функції, пов’язані зі створенням виконуваних елементів системи (програмних кодів) або модифікацією наявної системи. Багато з критеріїв цієї групи залежать від конкретних мов:

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

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

— компіляція коду;

— конвертування початкового коду з однієї мови в іншу;

— аналіз надійності — можливість кількісно оцінити параметри надійності ПЗ, такі як кількість помилок;

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

— реструктуризація початкового коду — можливість модифікації формату та/або структури наявного початкового коду;

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

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

2.3. тестування:

— опис тестів — генерування тестових даних, алгоритмів тестування, потрібних результатів тощо;

— фіксація дій оператора, їх редагування і повторення у тестових прикладах;

— автоматичний запуск тестових прикладів;

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

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

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

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

— аналіз виняткових ситуацій у процесі тестування;

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

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

3.1. документування:

— редагування текстів і графіків;

— редагування за допомогою форм;

— можливості видавничих систем;

— підтримка функцій і форматів гіпертексту;

— відповідність стандартам документування;

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

3.2. керування конфігурацією:

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

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

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

— керування версіями — введення і контроль даних про версії системи і всіх її компонентів, що колективно використовуються;

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

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

— архівація елементів даних для використання в майбутньому;

3.3.  керування проектом:

— керування роботами і ресурсами — контроль і керування процесом проектування ІС у термінах структури завдань і призначення виконавців, послідовності їх виконання, завершеності окремих етапів проекту і проекту загалом. Можливість підтримки планових даних, фактичних даних та їх аналізу. Типові дані включають графіки (з урахуванням календаря, робочих годин, вихідних тощо), комп’ютерні ресурси, розподіл персоналу, бюджет тощо;

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

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

— керування якістю — введення відповідних даних, їх аналіз і  генерування звітів;

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

Група 2. Надійність:

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

— автоматичне резервування (таке, що визначається постачальником або планується користувачем);

— безпека — захист від несанкціонованого доступу;

— оброблення помилок — виявлення помилок у роботі системи, повідомлення користувача, коректне завершення роботи або збереження стану на момент переривання;

— аналіз відмов у критичних додатках.

Група 3. Простота використання:

— зручність користувацького інтерфейсу;

— локалізація згідно з вимогами країни використання;

— простота освоєння — трудові й часові витрати на освоєння засобів;

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

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

— доступність і якість навчальних матеріалів — комп’ютерні навчальні матеріали, навчальні посібники, курси;

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

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

— уніфікованість користувацького інтерфейсу щодо інших застосовуваних засобів;

— онлайнові підказки (повнота та якість);

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

— припустимий час реакції на дії користувача залежно від середовища;

— простота встановлення та оновлення версій.

Група 4. Ефективність:

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

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

— продуктивність — час, витрачений на виконання конкретних задач (час відгуку на запит, час аналізу 100 000 рядків тощо).

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

Група 5. Супровід:

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

— трасування оновлень (простота освоєння відмінностей нових версій);

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

— супровід кінцевого продукту — простота внесення змін у ПЗ і документацію).

Група 6. Можливість перенесення:

— сумісність із версіями ОС — можливість роботи у середовищі різних версій однієї ОС, простота модифікації CASEзасобу для роботи з новими версіями ОС;

— можливість перенесення даних між різними версіями

CASEзасобу;

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

Група 7. Загальні критерії:

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

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

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

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

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

— експортні обмеження;