< Попередня  Змiст  Наступна >

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засобу, що використовувався під час розроблення продукту);

 

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

 

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

 

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

 

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

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

 


< Попередня  Змiст  Наступна >
Iншi роздiли:
Тема 2. АВТОМАТИЗОВАНЕ КЕРУВАННЯ ПРОЦЕСАМИ ЖИТТЄВОГО ЦИКЛУ ІНФОРМАЦІЙНИХ СИСТЕМ
2.1. КЕРУВАННЯ ПРОЦЕСАМИ ЯК ОБЄКТ АВТОМАТИЗАЦІЇ
2.2. ЗАСОБИ МОДЕЛЮВАННЯ ПРОЦЕСІВ IBM RATIONAL
2.2.2. IBM Rational Method Composer
2.3. АВТОМАТИЗОВАНА ПІДТРИМКА МЕТОДОЛОГІЇ MICROSOFT SOLUTIONS FRAMEWORK
Дисциплiни

МаркетингАнглійська моваПравоЕтика та естетикаІсторіяБухгалтерський облікЕкономікаІнформатикаМенеджментПолітологіяСтатистикаФінанси

Бібліотека підручників та статтей Posibniki