Модель процесу оцінки та вибору [17], що розглядається нижче (малюнок 4.2), описує найбільш загальну ситуацію оцінки та вибору, а також показує залежність між ними. Як можна бачити, оцінка та вибір можуть виконуватися незалежно один від одного або разом, кожен з цих процесів вимагає застосування певних критеріїв.
Процес оцінки та вибору може переслідувати декілька цілей, включаючи одну або більше з таких:
оцінка декількох CASE-засобів і вибір одного або більше з них; оцінка одного або більше CASE-засобів і збереження результатів для подальшого використання; вибір одного або більше CASE-засобів з використанням результатів попередніх оцінок.Рис. 4.2. Модель процесу оцінки і вибору
Як видно з малюнка, вхідною інформацією для процесу оцінки є:
визначення користувальницьких потреб; цілі й обмеження проекту; дані про доступні CASE-засобах; список критеріїв, які використовуються в процесі оцінки.Результати оцінки можуть включати результати попередніх оцінок. При цьому не слід забувати, що набір критеріїв, що використовувалися при попередній оцінці, повинен бути сумісним з поточним набором. Конкретний варіант реалізації процесу (оцінка і вибір, оцінка для майбутнього вибору або вибір, заснований на попередніх оцінках) визначається перерахованими вище цілями.
Елементи процесу включають:
мети, припущення та обмеження, які можуть уточнюватися під час процесу; потреби користувачів, що відображають кількісні та якісні вимоги користувачів до CASE-засобів; критерії, що визначають набір параметрів, відповідно до яких проводиться оцінка і прийняття рішення про вибір; формалізовані результати оцінок одного або більше коштів; рекомендований рішення (зазвичай або рішення про вибір, або подальша оцінка).Процес оцінки та / або вибору може бути початий тільки тоді, коли особа, група або організація повністю визначила для себе конкретні потреби і формалізувала їх у вигляді кількісних та якісних вимог у заданій предметній області. Термін "призначені для користувача вимоги" Угоді означає саме такі формалізовані вимоги.
Користувач повинен визначити конкретний порядок дій і прийняття рішень з будь-якими необхідними итерациями. Наприклад, процес може бути представлений у вигляді дерева рішень з його послідовним обходом і вибором підмножин кандидатів для більш детальної оцінки. Опис послідовності дій має визначати потік даних між ними.
Визначення переліку критеріїв засноване на користувацьких вимогах і включає:
вибір критеріїв для використання з наведеного далі переліку; визначення додаткових критеріїв; визначення області використання кожного критерію (оцінка, вибір або обидва процеси); визначення однієї або більше метрик для кожного критерію оцінки; призначення ваги кожному критерію при виборі. Процес оцінкиМетою процесу оцінки є визначення функціональності і якості CASE-засобів для подальшого вибору. Оцінка виконується у відповідності з конкретними критеріями, її результати включають як об'єктивні, так і суб'єктивні дані по кожному засобу.
Процес оцінки включає наступні дії:
формулювання задачі оцінки, включаючи інформацію про мету і масштабах оцінки; визначення критеріїв оцінки, що випливає з визначення завдання; визначення засобів-кандидатів шляхом перегляду списку кандидатів і аналізу інформації про конкретні засоби; оцінка засобів-кандидатів в контексті обраних критеріїв. Необхідні для цього дані можуть бути отримані шляхом аналізу самих засобів та їх документації, опитування користувачів, роботи з демо-версіями, виконання тестових прикладів, експериментального застосування засобів і аналізу результатів попередніх оцінок, підготовка звіту за результатами оцінки.Одним з найважливіших критеріїв у процесі оцінки може бути потенційна можливість інтеграції кожного із засобів-кандидатів з іншими засобами, вже знаходяться в експлуатації або запланованими до використання в даній організації.
Масштаб оцінки повинен встановлювати необхідний рівень деталізації, необхідні ресурси і ступінь придатності її результатів. Наприклад, оцінка повинна виконуватися для набору з одного або більш конкретних CASE-засобів; CASE-засобів, що підтримують один або більше конкретних процесів створення і супроводу ПЗ або CASE-засобів, що підтримують один або більше проектів або типів проектів.
Список CASE-засобів - можливих кандидатів формується з різних джерел: оглядів ринку ПЗ, інформації постачальників, оглядів CASE-засобів і інших подібних публікацій.
Наступним кроком є отримання інформації про CASE-засобах або отримання їх самих або і те, й інше. Ця інформація може складатися з оцінок незалежних експертів, повідомлень і звітів постачальників CASE-засобів, результатів демонстрації можливостей CASE-засобів з боку постачальників та інформації, отриманої безпосередньо від реальних користувачів. Самі CASE-засоби можуть бути отримані шляхом придбання, у вигляді оціночної копії або іншими способами.
Оцінка та накопичення відповідних даних може виконуватися такими способами:
аналіз CASE-засобів і документації постачальника; опитування реальних користувачів; аналіз результатів проектів, які використовували дані CASE-засоби; перегляд демонстрацій і опитування демонстраторів; виконання тестових прикладів; застосування CASE-засобів у пілотних проектах; аналіз будь-яких доступних результатів попередніх оцінок.Існують як об'єктивні, так і суб'єктивні критерії. Результати оцінки відповідно до конкретних критерієм можуть бути двійковими, перебувати в деякому числовому діапазоні, бути просто числове значення або мати будь-яку іншу форму.
Для об'єктивних критеріїв оцінка повинна виконуватися шляхом відтворюваної процедури, щоб будь-який інший фахівець, що виконує оцінку, міг отримати такі ж результати. Якщо використовуються тестові приклади, їх набір повинен бути заздалегідь визначений, уніфікований і задокументований.
За суб'єктивними критеріями CASE-засіб має оцінюватися групою фахівців, що використовують одні й ті самі критерії. Необхідний рівень досвіду фахівців або груп повинен бути заздалегідь визначений.
Результати оцінки повинні бути стандартним чином задокументовані (для полегшення подальшого використання) і, при необхідності, затверджені.
Звіт за результатами оцінки повинен містити наступну інформацію:
введення. Загальний огляд процесу та перелік основних результатів; передумови. Мета оцінки і бажані результати, період часу, протягом якого виконувалася оцінка, визначення ролей та відповідного досвіду фахівців, що виконували оцінку; підхід до оцінки. Опис загального підходу, включаючи отримані CASE-засоби, інформацію, визначальну контекст і масштаб оцінки, а також будь-які припущення та обмеження; інформація про CASE-засобах. Вона повинна включати наступне: 1) найменування CASE-засоби, 2) версію CASE-засоби; 3) дані про постачальника, включаючи контактну адресу і телефон; 4) конфігурацію технічних засобів; 5) вартісні дані; 6) опис CASE-засоби, що включає підтримувані даним засобом процеси створення і супроводу ПЗ, програмне середовище CASE-засоби (зокрема, підтримувані мови програмування, операційні системи, сумісність з базами даних), функції CASE-засоби, вхідні / вихідні дані і область застосування; етапи оцінки. Конкретні дії, що їх у процесі оцінки, повинні бути описані зі ступенем деталізації, необхідної як для розуміння масштабу і глибини оцінки, так і для її повторення при необхідності; конкретні результати. Результати оцінки повинні бути представлені в термінах критеріїв оцінки. У тих випадках, коли звіт охоплює цілий ряд CASE-засобів або результати даної оцінки будуть зіставлятися з аналогічними результатами інших оцінок, необхідно звернути особливу увагу на формат представлення результатів, сприяє такого порівняння. Суб'єктивні результати повинні бути відокремлені від об'єктивних і має супроводжуватися необхідними поясненнями; факти та висновки; додатки. Формулювання задачі оцінки і уточнений список критеріїв. Процес виборуПроцеси оцінки та вибору тісно взаємозалежні один з одним. За результатами оцінки цілі вибору і / або критерії вибору та їх ваги можуть зажадати модифікації. У таких випадках може знадобитися повторна оцінка. Коли аналізуються остаточні результати оцінки і до них застосовуються критерії вибору, може бути рекомендовано придбання CASE-засоби або набору CASE-засобів. Альтернативою може бути відсутність адекватних CASE-засобів, в цьому випадку рекомендується розробити нове CASE-засіб, модифіковані існуюче або відмовитися від впровадження.
Процес вибору тісно взаємопов'язаний з процесом оцінки і включає наступні дії:
формулювання завдань вибору, включаючи цілі, припущення та обмеження; виконання всіх необхідних дій по вибору, включаючи визначення і ранжування критеріїв, визначення засобів-кандидатів, збір необхідних даних та застосування ранжируваних критеріїв до результатів оцінки для визначення коштів з найкращими показниками. Для багатьох користувачів важливим критерієм вибору є інтегрованість CASE-засоби з існуючим середовищем; виконання необхідної кількості ітерацій з тим, щоб вибрати (або відкинути) кошти, які мають схожі показники; підготовка звіту за результатами вибору.У процесі вибору можливе одержання двох результатів:
рекомендацій щодо вибору конкретного CASE-засоби; запиту на отримання додаткової інформації до процесу оцінки.Масштаб вибору повинен встановлювати необхідний рівень деталізації, необхідні ресурси, графік і очікувані результати. Існує ряд параметрів, які можуть бути використані для визначення масштабу, включаючи:
використання попереднього відбору (наприклад, відбір тільки засобів, що працюють на конкретній платформі); використання раніше отриманих результатів оцінки, результатів оцінки із зовнішніх джерел або комбінації того й іншого;У тому випадку, якщо попередні оцінки виконувалися з використанням різних наборів критеріїв або виконувалися з використанням конкретних критеріїв, але різними способами, результати оцінок повинні бути представлені в узгодженій формі. Після завершення даного кроку оцінка кожного CASE-засобу повинна бути представлена в рамках єдиного набору критеріїв і повинна бути безпосередньо порівнянна з іншими оцінками.
Алгоритми, які зазвичай використовуються для вибору, можуть бути засновані на масштабі або ранзі. Алгоритми, засновані на масштабі, обчислюють єдине значення для кожного CASE-засоби шляхом множення ваги кожного критерію на його значення (з урахуванням масштабу) і складання всіх творів. CASE-засіб з найвищим результатом отримує перший ранг. Алгоритми, засновані на ранзі, використовують ранжування CASE-засобів - кандидатів за окремими критеріями або групами критеріїв у відповідності зі значеннями критеріїв у заданому масштабі. Потім, аналогічно попередньому, ранги зводяться разом і обчислюються загальні значення рангів.
При аналізі результатів вибору передбачається, що процес вибору завершений, CASE-засіб вибрано і рекомендовано до використання. Тим не менш, може знадобитися більш точний аналіз для визначення ступеня залежності значень ключових критеріїв від відмінностей у значеннях характеристик CASE-засобів - кандидатів. Такий аналіз дозволить визначити, наскільки результат ранжирування CASE-засобів залежить від оптимальності вибору вагових коефіцієнтів критеріїв. Він також може використовуватися для визначення суттєвих відмінностей між CASE-засобами з дуже близькими значеннями критеріїв або рангами.
Якщо жодне з CASE-засобів не задовольняє мінімальним критеріям, вибір (можливо, разом з оцінкою) може бути повторений для інших CASE-засобів - кандидатів.
Якщо відмінності між самими кращими кандидатами несуттєві, додаткова інформація може бути отримана шляхом повторного вибору (можливо, разом з оцінкою) з використанням додаткових або інших критеріїв.
Рекомендації по вибору повинні бути суворо обгрунтовані. У разі відсутності адекватних CASE-засобів, як було зазначено вище, рекомендується розробити нове CASE-засіб, модифіковані існуюче або відмовитися від впровадження.
Критерії оцінки та виборуКритерії формують базис для процесів оцінки та вибору і можуть приймати різні форми, включаючи:
числові заходи в широкому діапазоні значень, наприклад, обсяг необхідної пам'яті; числові заходи в обмеженому діапазоні значень, наприклад, простота освоєння, виражена в балах від 1 до 5; виконавчі заходи (істина / неправда, так / ні), наприклад, здатність генерації документації у форматі Postscript; заходи, які можуть приймати одне або більше з кінцевих множин значень, наприклад, платформи, для яких підтримується CASE-засіб.Типовий процес оцінки та / або вибору може використовувати набір критеріїв різних типів.
Структура набору критеріїв наведена на малюнку 4.3. Кожен критерій має бути вибраний і адаптований експертом з урахуванням особливостей конкретного процесу. У більшості випадків тільки деякі з безлічі описаних нижче критеріїв виявляються прийнятними для використання, при цьому також додаються додаткові критерії. Вибір та уточнення набору використовуваних критеріїв є критичним кроком у процесі оцінки і / або вибору.
Функціональні характеристики
Критерії першого класу призначені для визначення функціональних характеристик CASE-засоби. Вони в свою чергу поділяються на ряд груп та підгруп.
Середовище функціонування: Проектна середовище: підтримка процесів життєвого циклу. Визначає набір процесів ЖЦ, які підтримує CASE-засіб. Прикладами таких процесів є аналіз вимог, проектування, реалізація, тестування і оцінка, супровід, забезпечення якості, управління конфігурацією і управління проектом, причому вони залежать від прийнятої користувачем моделі ЖЦ. область застосування. Прикладами є системи обробки транзакцій, системи реального часу, інформаційні системи і т.д. розмір підтримуються. Визначає обмеження на такі величини, як кількість рядків коду, рівнів вкладеності, розмір бази даних, кількість елементів даних, кількість об'єктів конфігураційного управління. ПЗ / технічні засоби: необхідні технічні засоби. Обладнання, необхідне для функціонування CASE-засоби, включаючи тип процесора, об'єм оперативної і дискової пам'яті. підтримувані технічні засоби. Елементи обладнання, які можуть використовуватися CASE-засобом, наприклад, пристрої введення / виводу. потрібного ПЗ. ПЗ, необхідне для функціонування CASE-засоби, включаючи операційні системи та графічні оболонки. підтримуване ПЗ. Програмні продукти, які можуть використовуватися CASE-засобом.Рис. 4.3. Структура набору критеріїв
Технологічне середовище: відповідність стандартам технологічного середовища. Такі стандарти стосуються мови, бази даних, сховища, комунікацій, графічного інтерфейсу користувача, документації, розробки, управління конфігурацією, безпеки, стандартів обміну інформацією та інтеграції за даними, з управління та за призначеною для користувача інтерфейсу. сумісність з іншими засобами. Здатність до взаємодії з іншими засобами, включаючи безпосередній обмін даними (прикладами таких засобів є текстові процесори, бази даних та інші CASE-засоби). Можливість перетворення сховища або його частини в стандартний формат для обробки іншими засобами. підтримувана методологія. Набір методів і методик, підтримуваних CASE-засобом. Прикладами є структурний або об'єктно-орієнтований аналіз та проектування. підтримувані мови. Всі мови, використовувані CASE-засобом. Прикладами таких мов є мови програмування (Кобол, Ада, С), мови баз даних і мови запитів (DDL, SQL), графічні мови (Postscript, HPGL), мови специфікації проектних вимог і інтерфейси операційних систем (мови управління завданнями). Функції, орієнтовані на фази життєвого циклу: Моделювання:Дані критерії визначають здатність виконання функцій, необхідних для специфікації вимог до ПЗ та перетворення їх у проект: побудова діаграм. Можливість створення і редагування діаграм різних типів, що представляють інтерес для користувача. Найбільш поширені типи діаграм описані в розділі 2. графічний аналіз. Можливість аналізу графічних об'єктів, а також зберігання і подання проектної інформації в графічному поданні. У більшості випадків графічні аналізатори інтегровані із засобами побудови діаграм. введення і редагування специфікацій вимог і проектних специфікацій. До специфікаціям такого роду відносяться опису функцій, даних, інтерфейсів, структури, якості, продуктивності, технічних засобів, середовища, витрат і графіків. мова специфікації вимог і проектних специфікацій. Можливість імпорту, експорту і редагування специфікацій з використанням формальної мови. моделювання даних. Можливість введення і редагування інформації, яка описує елементи даних системи і їх відносини. моделювання процесів. Можливість введення і редагування інформації, яка описує процеси системи і їх відносини. проектування архітектури ПЗ. Проектування логічної структури ПЗ - структури модулів, інтерфейсів і ін імітаційне моделювання. Можливість динамічного моделювання різних аспектів функціонування системи на основі специфікацій вимог і / або проектних специфікацій, включаючи зовнішній інтерфейс і продуктивність (наприклад, час відгуку, коефіцієнт використання ресурсів і пропускну здатність). Прототипування. Можливість проектування і генерації попереднього варіанту всієї системи або її окремих компонент на основі специфікацій вимог і / або проектних специфікацій. Прототипування в основному стосується зовнішнього користувальницького інтерфейсу і здійснюється за безпосередньої участі користувачів. генерація екранних форм. Можливість генерації екранних форм на основі специфікацій вимог і / або проектних специфікацій. можливість трасування. Можливість наскрізного аналізу функціонування системи від специфікації вимог до кінцевих результатів (встановлення та відстеження відповідностей та зв'язків між функціональними та іншими зовнішніми вимогами до ІС, технічними рішеннями і результатами проектування). Пряма трасування (перевірка обліку всіх вимог) і зворотна трасування (пошук проектних рішень, не пов'язаних ні з якими зовнішніми вимогами). синтаксичний та семантичний контроль проектних специфікацій. Контроль синтаксису діаграм і типів їх елементів, контроль декомпозиції функцій, перевірка специфікацій на повноту і несуперечність. інші види аналізу. Конкретні додаткові види аналізу можуть включати алгоритми, потоки даних, нормалізацію даних, використання даних, призначений для користувача інтерфейс. автоматизоване проектування звітів. Реалізація:
Реалізація зачіпає функції, пов'язані зі створенням виконуваних елементів системи (програмних кодів) або модифікацією існуючої системи. Багато хто з перерахованих нижче критеріїв залежать від конкретних мов і включають наступні: синтаксично кероване редагування. Можливість введення і редагування вихідних кодів на одному або декількох мовах з одночасним синтаксичним контролем. генерація коду. Можливість генерації кодів на одному або декількох мовах на основі проектних специфікацій. Типи генерованого коду можуть включати звичайний програмний код, схему бази даних, запити, екрани / меню. компіляція коду. конвертація вихідного коду. Можливість перетворення коду з однієї мови в інший. аналіз надійності. Можливість кількісно оцінювати параметри надійності ПЗ, такі, як кількість помилок та ін реверсний інжиніринг. Можливість аналізу існуючих вихідних кодів і формування на їх основі проектних специфікацій. реструктуризація вихідного коду. Можливість модифікації формату та / або структури існуючого вихідного коду. аналіз вихідного коду. Прикладами такого аналізу можуть бути визначення розміру коду, обчислення показників складності, генерація перехресних посилань і перевірка на відповідність стандартам. налагодження. Типові функції налагодження - трасування програм, виділення вузьких місць і найбільш часто використовуваних фрагментів коду і т.д. Тестування:
Критерії тестування включають наступні: опис тестів. Типові можливості включають генерацію тестових даних, алгоритмів тестування, необхідних результатів і т.д. фіксація і повторення дій оператора. Можливість фіксувати дані, що вводяться оператором за допомогою клавіатури, миші і т.д., редагувати їх і відтворювати в тестових прикладах. автоматичний запуск тестових прикладів. регресійне тестування. Можливість повторення та модифікації раніше виконаних тестів для виявлення розбіжностей у системі та / або середовищі. автоматизований аналіз результатів тестування. Типові можливості включають порівняння очікуваних і реальних результатів, порівняння файлів, статистичний аналіз результатів та ін аналіз тестового покриття. Оснащеність засобами контролю вихідного коду та аналіз тестового покриття. Перевіряються, зокрема, звернення до операторів, процедур і змінним. аналіз продуктивності. Можливість аналізу продуктивності програм. Аналізовані параметри продуктивності можуть включати використання центрального процесора, пам'яті, звернення до певних елементів даних і / або сегментів коду, тимчасові характеристики і т.д. аналіз виняткових ситуацій у процесі тестування. динамічне моделювання середовища. Зокрема, можливість автоматично генерувати модельований вхідні дані системи. Загальні функції:
Наведені нижче критерії визначають функції CASE-засобів, що охоплюють всю сукупність фаз ЖЦ. Підтримка всіх цих функцій здійснюється за допомогою сховища. Документування: редагування текстів і графіки. Можливість вводити і редагувати дані в текстовому і графічному форматі. редагування за допомогою форм. Можливість підтримувати форми, визначені користувачами, вводити і редагувати дані у відповідності з формами. можливості видавничих систем. підтримка функцій і форматів гіпертексту. відповідність стандартам документування. автоматичне вилучення даних з сховища та генерація документації по специфікаціям користувача. Управління конфігурацією: контроль доступу і змін. Можливість контролю доступу на фізичному рівні до елементів даних і контролю змін. Контроль доступу включає можливості визначення прав доступу до компонентів, а також вилучення елементів даних для модифікації, блокування доступу до них на час модифікації і приміщення назад в репозиторій. відстеження модифікацій. Фіксація і ведення журналу всіх модифікацій, внесених в систему в процесі розробки або супроводу. управління версіями. Ведення та контроль даних про версіях системи і всіх її колективно використовуваних компонентах. облік стану об'єктів конфігураційного управління. Можливість отримання звітів про всіх послідовних версіях, вмісті та стан різних об'єктів конфігураційного управління. генерація версій і модифікацій. Підтримка користувальницького опису послідовності дій, необхідних для формування версій і модифікацій, і автоматичне виконання цих дій. архівування. Можливість автоматичного архівування елементів даних для подальшого використання. Управління проектом: керування роботами і ресурсами. Контроль і керування процесом проектування ІС в термінах структури завдань і призначення виконавців, послідовності їх виконання, завершеності окремих етапів проекту і проекту в цілому. Можливість підтримки планових даних, фактичних даних та їх аналізу. Типові дані включають графіки (з урахуванням календаря, робочих годин, вихідних і ін), комп'ютерні ресурси, розподіл персоналу, бюджету та інших оцінка. Можливість оцінювати витрати, графік та інші проектні параметри, що вводяться користувачами. управління процедурою тестування. Підтримка управління процедурами і програмою тестування, наприклад, керування розкладом планованих процедур, фіксація і запис результатів тестування, генерація звітів і т.д. управління якістю. Введення відповідних даних, їх аналіз та генерація звітів. коригувальні дії. Підтримка управління коригуючими діями, включаючи обробку повідомлень про проблемні ситуації. Надійність адміністрування сховища. Контроль та забезпечення цілісності проектних даних. автоматичне резервування (обумовлений постачальником або плановане користувачем). безпеку. Захист від несанкціонованого доступу. обробка помилок. Виявлення помилок в роботі системи, повідомлення користувача, коректне завершення роботи або збереження стану до моменту переривання. аналіз відмов у критичних додатках. 4.2.4.2. Простота використання зручність для користувача інтерфейсу. Зручність розташування та подання часто використовуваних елементів екрану, способів введення даних і ін локалізація (відповідно до вимог цієї країни). простота освоєння. Трудові і часові витрати на освоєння коштів. адаптованість до конкретних потреб користувача. Адаптованість до різних алфавітів, режимам текстового та графічного представлення (зліва-направо, зверху-вниз), різних форматів дати, способам введення / виводу (екранним формам і форматам), змін у методології (змін графічних нотацій, правил, властивостей і складу зумовлених об'єктів ) та ін якість документації (повнота, зрозумілість, легкість для читання, корисність та ін.) доступність і якість навчальних матеріалів. Вони можуть включати комп'ютерні навчальні матеріали, навчальні посібники, курси. вимоги до рівня знань. Кваліфікація і досвід, необхідні для ефективного використання CASE-засобів. простота роботи з CASE-засобом (як для початківців, так і для досвідчених користувачів). уніфікованість користувальницького інтерфейсу (по відношенню до інших засобів, що використовується в даній організації). онлайнові підказки (повнота і якість). якість діагностики (зрозумілість і корисність діагностичних повідомлень для користувача). допустимий час реакції на дії користувача (залежно від середовища). простота встановлення та оновлення версій. 4.2.4.3. Ефективність вимоги до технічних засобів. Вимоги до оптимального розміру зовнішньої і оперативної пам'яті, типу і продуктивності процесора, що забезпечує прийнятний рівень продуктивності. ефективність робочого навантаження. Ефективність виконання CASE-засобом своїх функцій залежно від інтенсивності роботи користувача (наприклад, кількість натискань клавіш або кнопки миші, необхідну для виконання певних функцій). продуктивність. Час, що витрачається CASE-засобом для виконання конкретних завдань (наприклад, час відповіді на запит, час аналізу 100000 рядків коду). У деяких випадках дані оцінки продуктивності можна отримати з зовнішніх джерел. 4.2.4.4. Сопровождаемость рівень підтримки з боку постачальника (швидкість вирішення проблем, постачання нових версій, забезпечення додаткових можливостей). трасуванню оновлень (простота освоєння відмінностей нових версій від існуючих). сумісність оновлень (сумісність нових версій з існуючими, включаючи, наприклад, сумісність з вхідним чи вихідним даними). сопровождаемость кінцевого продукту (простота внесення змін в ПЗ і документацію). 4.2.4.5. Переносимість сумісність з версіями ОС (можливість роботи в середовищі різних версій однієї і тієї ж ОС, простота модифікації CASE-засоби для роботи з новими версіями ОС). переносимість даних між різними версіями CASE-засоби. відповідність стандартам переносимості. Такі стандарти включають документацію, комунікації і призначений для користувача інтерфейс, віконний інтерфейс, мови програмування, мови запитів і ін 4.2.4.6. Загальні критерії
Наведені нижче критерії є загальними за своєю природою і не належать до сукупності показників якості, наведеної у стандарті ISO / IEC 9126: 1991.
витрати на CASE-засіб. Включають вартість придбання, встановлення, початкового супроводу і навчання. Слід враховувати ціну для всіх необхідних конфігурацій (включаючи єдину копію, кілька копій, локальну ліцензію, ліцензію для підприємства, мережеву ліцензію). оцінний ефект від впровадження CASE-засоби (рівень продуктивності, якості і т.д.). Така оцінка може зажадати економічного аналізу. профіль дистриб'ютора. Загальні показники можливостей дистриб'ютора. Профіль дистриб'ютора може включати величину його організації, стаж в бізнесі, фінансове становище, список будь-яких додаткових продуктів, ділові зв'язки (зокрема, з іншими дистриб'юторами даного засобу), планована стратегія розвитку. сертифікація постачальника. Сертифікати, отримані від спеціалізованих організацій у галузі створення ПЗ (наприклад, SEI та ISO), які засвідчують, що кваліфікація постачальника в галузі створення і супроводу ПЗ задовольняє деяким мінімально необхідним або цілком певним вимогам. Сертифікація може бути неформальною, наприклад, на основі аналізу якості роботи постачальника. ліцензійна політика. Доступні можливості ліцензування, право копіювання (носіїв і документації), будь-які обмеження та / або штрафні санкції за вторинне використання (мається на увазі продаж користувачем CASE-засоби продуктів, до складу яких входять деякі компоненти CASE-засоби, що використовувалися при розробці продуктів). експортні обмеження. профіль продукту. Загальна інформація про продукт, включаючи термін його існування, кількість проданих копій, наявність, розмір і рівень діяльності користувацької групи, система звітів про проблеми, програма розвитку продукту, сукупність застосувань, наявність помилок і ін підтримка постачальника. Доступність, реактивність і якість послуг, що надаються постачальником для користувачів CASE-засобів. Такі послуги можуть включати телефонну "гарячу лінію", місцеву технічну підтримку, підтримку в самій організації. доступність і якість навчання. Навчання може проводитися на території постачальника, користувача або де-небудь в іншому місці. адаптація, необхідна для впровадження CASE-засобів в організації користувача. Прикладом може бути визначення способу використання централізованого CASE-засоби з єдиною, загальною БД в розподіленому середовищі. Виконання пілотного проектуПеред повномасштабним впровадженням обраного CASE-засоби в організації виконується пілотний проект, метою якого є експериментальна перевірка правильності рішень, прийнятих на попередніх етапах, і підготовка до впровадження.
Пілотний проект являє собою початкове реальне використання CASE-засоби в призначеній для цього середовищі і зазвичай має на увазі більш широкий масштаб використання CASE-засоби по відношенню до того, який був досягнутий під час оцінки. Пілотний проект повинен мати багато з характеристик реальних проектів, для яких призначений даний засіб. Він переслідує такі цілі:
підтвердити достовірність результатів оцінки та вибору; визначити, чи дійсно CASE-засіб годиться для використання в даній організації, і якщо так, то визначити найбільш підходящу область його застосування; зібрати інформацію, необхідну для розробки плану практичного впровадження; придбати власний досвід використання CASE-засоби .Пілотний проект дозволяє отримати важливу інформацію, необхідну для оцінки якості функціонування CASE-засобу та його підтримки з боку постачальника після того, як засіб встановлено.
Важливою функцією пілотного проекту є прийняття рішення щодо придбання чи відмови від використання CASE-засоби. Провал пілотного проекту дозволяє уникнути більш значних і дорогих невдач надалі, оскільки пілотний проект зазвичай пов'язаний з придбанням відносно невеликої кількості ліцензій та навчанням вузького кола фахівців.
Первісне використання нової CASE-технології в пілотному проекті має ретельно плануватися і контролюватися. Пілотний проект включає наступні кроки (малюнок 4.4).
Визначення характеристик пілотного проекту
Пілотний проект повинен мати наступні характеристики:
Область застосування. Щоб полегшити остаточне визначення області застосування CASE-засоби, предметна область пілотного проекту повинна бути типовою для звичайної діяльності організації. Пілотний проект має допомогти визначити будь-яку додаткову технологію, навчання або підтримку, які необхідні для переходу від пілотного проекту до широкомасштабного використання кошти. У рамках цих обмежень пілотний проект повинен мати невеликий, але значущий розмір. Масштабованість. Результати, отримані в пілотному проекті, повинні показати масштабованість кошти. Мета - отримати чітке уявлення про масштаби проектів, для яких даний засіб можна застосувати.Рис. 4.4. Кроки пілотного проекту
Показність. Пілотний проект не повинен бути незвичайним або унікальним для організації. CASE-засіб повинен використовуватися для вирішення задач, які відносяться до предметної області, добре розуміється всією організацією. Критичність. Пілотний проект повинен мати істотну значущість, щоб опинитися в центрі уваги, але не повинен бути критичним для успішної діяльності організації в цілому. Необхідно усвідомлювати, що початкове впровадження нової технології має на увазі певний ризик. При виборі пілотного проекту доводиться вирішувати наступну дилему: успіх незначного проекту може залишитися непоміченим, з іншого боку, провал значущого проекту може викликати надмірну критику. Авторитетність. Група фахівців, що беруть участь в проекті, повинна володіти високим авторитетом, при цьому результати проекту будуть серйозно сприйняті іншими співробітниками організації. Характеристики проектної групи. Проектна група повинна мати готовністю до нововведень, технічної зрілістю і прийнятним рівнем досвіду і знань в даній технології та предметної області. З іншого боку, група повинна відображати в мініатюрі характеристики всієї організації в цілому.У більшості випадків існує баланс між бажанням реалізувати ідеальний пілотний проект і реальними обмеженнями організації. Організація повинна вибрати пілотний проект таким чином, щоб, по-перше, спосіб використання CASE-засоби в ньому збігався з подальшими планами, і, по-друге, перераховані вище характеристики були збалансовані з реальними умовами організації.
Крім того, організація повинна враховувати тривалість пілотного проекту (і в цілому процесу впровадження). Занадто тривалий проект пов'язаний з ризиком втрати інтересу до нього з боку керівництва.
Планування пілотного проекту
Планування пілотного проекту повинне по можливості вписуватися в звичайний процес планування проектів в організації. План повинен містити наступну інформацію:
цілі, завдання і критерії оцінки; персонал; процедури і угоди; навчання; графік і ресурси.Цілі, завдання та критерії оцінки
Очікувані результати пілотного проекту повинні бути чітко визначені. Ступінь відповідності з цими результатами представляє собою основу для наступної оцінки проекту. Для визначення цілей, завдань і критеріїв оцінки необхідно виконати наступні дії:
описати проект в термінах очікуваних результатів (тобто кінцевого продукту). Інформація повинна включати форму подання та зміст результатів. Мають бути чітко визначені договірні вимоги та відповідні стандарти. визначити загальні цілі проекту. Прикладом цілі може бути визначення ступеня поліпшення якості проектної документації в результаті застосування CASE-засобів. визначити конкретні завдання, що реалізують поставлені цілі. Кожній мети можна поставити у відповідність одну або кілька конкретних завдань з кількісно оцінюваними результатами. Прикладом такого завдання може бути порівняльний аналіз якості документації, отриманої за допомогою CASE-засоби і без нього. Документація може включати специфікацію вимог до ПЗ, високорівневі і детальні проектні специфікації. визначити критерії оцінки результатів. Щоб визначити ступінь успіху пілотного проекту, необхідно використовувати набір критеріїв, заснованих на згаданих вище завданнях. Прикладом критерію може бути ступінь несуперечності проектної документації та контрольованості виконання вимог до ПЗ. Значення критеріїв повинні порівнюватися з базовими значеннями, отриманими до виконання пілотного проекту.Персонал
Фахівці, вибрані для участі в пілотному проекті, повинні мати відповідний авторитет і вплив і бути прихильниками нової технології. Група повинна включати як технічних фахівців, так і менеджерів, зацікавлених у новій технології і розбираються в її використанні. Група повинна володіти високими здібностями до комунікації, знанням особливостей організаційних процесів і процедур, а також предметної області. Група не має, тим не менше, складатиметься повністю з фахівців вищої ланки, вона повинна представляти середній рівень організації.
Багато CASE-засоби забезпечують можливості, пов'язані з генерацією проектної документації та конфігураційним управлінням. Фахівці, пов'язані з цими та іншими суміжними аспектами розробки і супроводу ПЗ, також повинні бути включені до складу групи.
Після завершення пілотного проекту група повинна бути відкрита для обміну інформацією з іншими фахівцями організації щодо можливостей нового засобу і досвіду, отриманого при його використанні. Може виявитися бажаним розосередити членів проектної групи по всій організації з метою розповсюдження їх досвіду і знань.
Процедури і угоди
Необхідно чітко визначити процедури і угоди, що регулюють використання CASE-засобів в пілотному проекті. Це завдання швидше за все може виявитися більш довгою та складною, ніж очікується, при цьому може виявитися необхідним залучення сторонніх експертів. Прикладами процедур і угод, які можуть вплинути на успіх пілотного проекту, є методологія, технічні угоди (зокрема, з найменувань та структурі каталогів, стандарти проектування та програмування - див. підрозділ 1.3) та організаційні угоди (зокрема, облік використання ресурсів, авторизація , контроль змін, процедури експертизи та підготовки звітів, стандарти перевірки якості).
У пілотному проекті по можливості повинні використовуватися прийняті в організації процедури і угоди. З іншого боку, протягом пілотного проекту процедури і угоди мають тенденцію до розвитку і вдосконалення у міру накопичення досвіду застосування засобу. Існуючі процедури і угоди можуть виявитися неефективними або надто обмежують. При цьому ті зміни, які пропонується в них вносити, повинні документуватися.
Навчання
Повинні бути визначені види і обсяг навчання, необхідного для виконання пілотного проекту. При плануванні навчання потрібно мати на увазі три види потреб: технічні, управлінські та мотиваційні. Ресурси, необхідні для навчання (навчальні аудиторії та обладнання, викладачі та навчальні матеріали), повинні відповідати плану пілотного проекту.
Графік навчання повинен визначати як фахівців, які підлягають навчанню, так і види навчання, яке вони повинні пройти. Навчання, яке проводиться в період виконання проекту, має починатися як можна швидше після початку проекту. Навчання засобів, процесів чи методів, які не будуть використовуватися протягом кількох місяців після початку проекту, має плануватися на той час, коли в них виникне реальна потреба.
Постачальники CASE-засобів зазвичай пропонують навчання використанню поставляються ними коштів. Крім цього, для деяких засобів може бути необхідно навчання методології. Деякі види навчання повинні виконуватися власними силами. Такі види навчання включають використання CASE-засоби в контексті процесів, що відбуваються в організації, а також в сукупності з іншими засобами в даному середовищі. Частина плану пілотного проекту, пов'язана з навчанням, повинна використовуватися в якості входу для плану практичного впровадження.
При виборі необхідного навчання повинні прийматися до уваги наступні фактори:
кваліфікація викладачів; відповідність навчання характеристикам конкретних груп фахівців (на-приклад, оглядові курси для менеджерів, докладні курси для розробників); можливість проведення курсів безпосередньо на робочих місцях; можливість проведення розширених курсів; можливість підготовки власних викладачів.
Графік і ресурси
Повинен бути розроблений графік, що включає ресурси та терміни (етапи) проведення робіт. Ресурси включають персонал, технічні засоби, програмне забезпечення та фінансування. Дані про персонал можуть визначати конкретних фахівців або вимоги до кваліфікації, необхідної для успішного виконання пілотного проекту. Фінансування має визначатися окремо по кожному виду робіт: придбання CASE-засобів, установка, навчання, окремі етапи проектування.
Виконання пілотного проекту
Пілотний проект повинен виконуватися згідно з планом. Організаційна діяльність, пов'язана з виконанням пілотного проекту та підготовкою звітів, повинна виконуватися в установленому порядку. Пілотна природа проекту вимагає спеціальної уваги до питань придбання, підтримки, експертизи та оновлення версій. Ці питання розглядаються нижче.
Придбання, установка і інтеграція
Після того, як CASE-засіб вибрано, воно повинно бути придбано, інтегровано в проектну середовище і налаштований у відповідності з вимогами пілотного проекту. Межі цієї діяльності залежать від тих дій, які мали місце в процесі оцінки і вибору, а також від ступеня модифікації кошти, необхідної для його використання в проекті.
Процес придбання може включати підготовку контракту, переговори, ліцензування та іншу діяльність, яка виходить за рамки даних рекомендацій. Ця діяльність вимагає витрат часу та людських ресурсів, які повинні бути враховані при плануванні. План повинен передбачати можливість відмови від обраного засобу на даному етапі через договірних розбіжностей.
Після того, як процес придбання завершено, засіб повинен бути встановлено відтестованими і прийнято в експлуатацію. Тестування дозволяє переконатися, що поставлений продукт відповідає вимогам контракту, володіє необхідною повнотою та коректністю. Етап приймання може бути передбачений контрактом, його реальний термін може відрізнятися від того, який був передбачений спочатку в плані пілотного проекту. Особливу увагу необхідно приділити дотриманню всіх вимог постачальника до параметрів середовища функціонування CASE-засоби.
Після завершення приймання може знадобитися налаштування та інтеграція. Налаштування може включати модифікацію інтерфейсів, пов'язану з вимогами фахівців проектної групи, а також встановленням прав доступу і привілеїв. Налаштування повинна залишатися в рамках тих можливостей, які надає сам засіб. Не слід займатися модифікацією готових продуктів на рівні вихідних кодів.
Якщо новий засіб має використовуватися в сукупності з деякими іншими засобами, необхідно визначити взаємодію засобів та потрібну інтеграцію. Для інтеграції нових засобів з існуючими може знадобитися побудова спеціальних оболонок. Складна інтеграція може зажадати залучення сторонніх експертів.
Підтримка
Доступна підтримка повинна включати (за згодою) "гарячу лінію" постачальника і підтримку місцевого постачальника, підтримку в самій організації, контакти з досвідченими користувачами в інших організаціях та участь у роботі груп користувачів.
Внутрішня підтримка повинна здійснюватися фахівцями, знайомими з установкою засобів і роботою з ними. Існує кілька можливих варіантів отримання такої підтримки (наприклад, від фахівця даної організації, що має досвід попередньої роботи із засобом; учасників процесу оцінки та вибору або досвідченого консультанта). Такий тип підтримки повинен спеціальним чином плануватися і адмініструватися. Особлива увага повинна бути приділена засобам, які працюють у мережах або володіють репозиторіями, що підтримують багатокористувацьку роботу.
Періодичні експертизи
Звичайні процедури експертизи проектів, що існують в організації, повинні виконуватися і для пілотного проекту, при цьому особлива увага повинна приділятися саме пілотним аспектам проекту. Крім цього, результати експертиз повинні служити мірою успішного використання CASE-засобів.
Оновлення версій
Користувачі CASE-засоби можуть очікувати періодичного оновлення версій з боку постачальника протягом виконання пілотного проекту. При цьому необхідно ретельне ставлення до інтеграції цих версій. Слід заздалегідь оцінити вплив цих оновлень на хід проекту. Нові версії можуть як забезпечити нові можливості, так і породити нові проблеми. Наприклад, нова версія може зажадати видозміненого або додаткового навчання, а також може справити негативний вплив на вже виконану до цього моменту роботу.
Оцінка пілотного проекту
Після завершення пілотного проекту його результати необхідно оцінити і зіставити їх з початковими потребами організації, критеріями успішного впровадження CASE-засобів, базовими метриками і критеріями успіху пілотного проекту. Така оцінка повинна встановити можливі проблеми і найважливіші характеристики пілотного проекту, які можуть вплинути на придатність CASE-засоби для організації. Вона повинна також вказати проекти або структурні підрозділи всередині організації, для яких даний засіб є підходящим. Крім цього, оцінка може дати інформацію щодо вдосконалення процесу впровадження в подальшому.
У процесі оцінки пілотного проекту організація повинна визначити свою позицію по наступних трьох питань:
Чи доцільно впроваджувати CASE-засіб? Які конкретні особливості пілотного проекту призвели до його успіху (або невдачі)? Які проекти або підрозділи в організації могли б отримати вигоду від використання коштів?Прийняття рішення про доцільність впровадження CASE-засобів
На даному етапі процесу впровадження організація повинна зробити суттєві інвестиції в CASE-засоби. Якщо кошти задовольнили або навіть перевищили очікування організації, то рішення про впровадження може бути прийнято достатньо просто і швидко.
З іншого боку, може виявитися, що в рамках пілотного проекту кошти не виправдали тих очікувань, які на них покладалися, або ж у пілотному проекті вони використовувалися задовільно, проте досвід показав, що подальші вкладення в засоби не гарантують успіху.
Можливі чотири категорії результатів і відповідних дій:
Пілотний проект зазнав невдачі, і його аналіз показав неадекватність очікувань організації. У цьому випадку організація може переглянути результати проекту в контексті більш реалістичних очікувань. Пілотний проект зазнав невдачі, і його аналіз показав, що обрані засоби не задовольняють потреби організації. У цьому випадку організація може ухвалити рішення не впроваджувати дані кошти, однак при цьому також переглянути свої потреби і підхід до оцінки і вибору CASE-засобів. Пілотний проект зазнав невдачі, і його аналіз показав наявність таких проблем, як невдалий вибір пілотного проекту, неадекватне навчання і нестача ресурсів. У цьому випадку може виявитися досить складно прийняти рішення про те, чи слід знову виконати пілотний проект, продовжити роботу по впровадженню або відмовитися від CASE-засобів. Однак, незалежно від прийнятого рішення, процес впровадження потребує перегляду і підвищеної уваги. Пілотний проект завершився успішно, і визнано за доцільне впроваджувати CASE-засобу в деяких підрозділах або, можливо, у всій організації в цілому. У цьому випадку наступним кроком є визначення найбільш підходящого масштабу впровадження.У ряді випадків аналіз пілотного проекту може показати, що причиною невдачі з'явився більш ніж один фактор. Подальші спроби впровадження CASE-технології повинні чітко виявити всі причини невдачі. В екстремальних випадках ретельний аналіз може показати, що в даний момент організація просто не готова до успішного впровадження складних CASE-засобів. У такій ситуації організація може спробувати вирішити свої проблеми іншими засобами.
Особливості пілотного проекту
Дуже важливо провести аналіз пілотного проекту з тим, щоб визначити його елементи, які є критичними для успіху, і визначити ступінь відображення цими елементами діяльності організації в цілому. Наприклад, якщо в пілотному проекті беруть участь найкращі програмісти організації, він може закінчитися успішно навіть всупереч використання CASE-засобів, а не завдяки їм. З іншого боку, CASE-засоби можуть бути застосовані для розробки додатку, для якого вони явно не підходять за своїми характеристиками. Тим не менш, таке використання могло б вказати на область найбільш раціонального застосування засобів в даній організації.
Найважливіші характеристики пілотного проекту, не є представницькими для організації в цілому, можуть включати наступні:
Процеси в пілотному проекті в чому-небудь відрізняються від процесів у всій організації. Кваліфікація групи пілотного проекту не відображає кваліфікацію інших фахівців організації. Ресурси, виділені на виконання проекту, відрізняються від тих, які виділяються для звичайних проектів. Предметна область або масштаб проекту не відповідають іншим проектам.Вигода від використання CASE-засобів
Пілотний проект слід порівняти з діяльністю організації в цілому з тим, щоб визначити найбільш істотна подібність і відмінність. Наприклад, якщо найбільш зацікавлені й кваліфіковані учасники проекту зіткнулися з серйозними труднощами в освоєнні коштів, то менш зацікавленим і кваліфікованим програмістам з інших підрозділів потрібно істотно більше навчання.
Пілотний проект може також показати, що кошти доцільно використовувати для деяких класів проектів і недоцільно для інших. Наприклад, засіб формальної верифікації може підходити для життєво важливих додатків і не підходити для менш критичних додатків.
Перед розробкою плану переходу організація повинна оцінити очікуваний ефект для різних підрозділів або класів проектів. При цьому слід враховувати, що деякі підрозділи можуть не володіти необхідною кваліфікацією або ресурсами для використання CASE-засобів.
Прийняття рішення про впровадження
Можливим рішенням має бути одне з наступних:
Впровадити засіб. У цьому випадку рекомендований масштаб впровадження повинен бути визначений в термінах структурних підрозділів та предметної області. Виконати додатковий пілотний проект. Такий варіант має розглядатися тільки в тому випадку, якщо залишилися конкретні невирішені питання щодо впровадження CASE-засоби в організації. Новий пілотний проект повинен бути таким, щоб відповісти на ці питання. Відмовитися від засобу. У цьому разі причини відмови від конкретного засобу повинні бути визначені в термінах потреб організації чи критеріїв, які залишилися незадоволеними. Перед тим, як продовжити діяльність по впровадженню CASE-засобів, потреби організації повинні бути переглянуті на предмет своєї обгрунтованості. Відмовитися від використання CASE-засобів взагалі. Пілотний проект може показати, що організація або не готова до впровадження CASE-засобів, або автоматизація даного аспекту процесу створення і супроводу ПЗ не дає ніякого ефекту для організації. У цьому разі причини відмови від CASE-засобів повинні бути також визначені в термінах потреб організації чи критеріїв, які залишилися незадоволеними. При цьому необхідно розуміти відмінність цього варіанту від попереднього, пов'язаного з вадами конкретного засобу.Результатом даного етапу є документ, в якому обговорюються результати пілотного проекту і деталізуються рішення щодо впровадження.
Перехід до практичного використання CASE-засобівПроцес переходу до практичного використання CASE-засобів починається з розробки та подальшої реалізації плану переходу. Цей план може відображати поетапний підхід до переходу, починаючи з ретельно обраного пілотного проекту до проектів з істотно збільшеним різноманітністю характеристик.
Розробка плану переходу
План переходу повинен включати наступне:
Інформацію щодо цілей, критеріїв оцінки, графіка і можливих ризиків, пов'язаних з реалізацією плану. Інформацію щодо придбання, встановлення та налаштування CASE-засобів. Інформацію щодо інтеграції кожного засобу з існуючими засобами, включаючи як інтеграцію CASE-засобів один з одним, так і їх інтеграцію в процеси розробки та експлуатації ПЗ, що існують в організації. Очікувані потреби в навчанні і ресурси, що використовуються протягом і після завершення процесу переходу. Визначення стандартних процедур використання коштів.Цілі, критерії оцінки, графік і ризики, пов'язані з планом переходу
Дана інформація повинна включати наступне:
Типи проектів, в яких в кінцевому рахунку буде використовуватися засіб. Графік переходу до практичного використання кошти в окремих проектах, який включає необхідну підготовку до його широкого використання. Графік впровадження кошти в термінах кількості користувачів, включаючи необхідне навчання. Можливі ризики і непередбачені обставини. Джерела існуючих (базових) даних і метрики для оцінки змін, викликаних використанням коштів.На додаток до сказаного, слід приділити особливу увагу питанням контролю змін. Ролі вищого керівництва, суб'єктів та об'єктів змін повинні бути уточнені в порівнянні з пілотним проектом, оскільки технологія підлягає широкому розповсюдженню в організації.
Мається на увазі, що план переходу успішно виконаний, коли не потрібно більше спеціального планування підтримки використання коштів. У цей момент використання коштів узгоджується з тим, що від нього очікувалося, і план роботи з ним включається в загальний план поточної підтримки ПЗ, що існує в організації.
Придбання, установка і настройка засобів
Придбання, встановлення та налаштування, виконані в рамках пілотного проекту, можуть знадобитися в більш широкому масштабі. При цьому необхідна наступна інформація:
Сукупність програмних компонент, документації і навчання, які необхідно купувати для кожної окремої платформи. Механізм отримання нових версій. Налаштування кошти, необхідна для виконання існуючих в організації процедур і угод. Особа або підрозділ, відповідальний за установку, інтеграцію, настройку та експлуатацію кошти. План конвертації даних і зняття старих засобів з експлуатації.Завдання придбання, встановлення та налаштування повинні бути як можна швидше передані з групи пілотного проекту в існуючу службу системної підтримки ПЗ організації.
Інтеграція кошти з існуючими засобами і процесами
Інтеграція нового засобу з існуючими засобами і процесами є важливим кроком у повномасштабному впровадженні кошти. У більшості випадків така інтеграція в процесі пілотного проектування не здійснюється, проте накопичується в цьому процесі інформація може допомогти в розробці планів інтеграції. Для планування інтеграції необхідна наступна інформація:
Найменування і версії існуючих засобів, з якими має інтегруватися новий засіб. Описи даних, які повинні спільно використовуватися новим і існуючими засобами, а також попередня інформація про джерела цих даних. Описи інших взаємозв'язків між новим і існуючими засобами (таких, як зв'язку з передачі управління і порядку використання), а також попередня інформація про механізми підтримки цих взаємозв'язків. Оцінки витрат, термінів і ризиків, пов'язаних з інтеграцією (і, можливо, переходом від існуючих засобів і даних). Визначення способу впровадження даного засобу в діяльність з удосконалення існуючих процесів. Очікувані зміни в існуючих процесах і продуктах, які є наслідком використання нового засобу і оцінювані, по можливості, кількісно.Ризик, пов'язаний з інтеграцією нового засобу з існуючими засобами і процесами, знижується, якщо потреби в інтеграції враховуються в процесі оцінки та вибору засобу.
Навчання та ресурси, що використовуються протягом і після завершення процесу переходу
Дана інформація повинна включати наступне:
Персонал (включаючи користувачів, адміністраторів та інтеграторів), що потребує в навчанні використанню кошти. Вид навчання, необхідного для кожної категорії користувачів і обслуговуючого персоналу, з урахуванням особливої важливості навчання спільного використання різних засобів, а також методів і процесів, пов'язаних з даними засобами. Вид навчання, необхідного для різних фахівців (наприклад, для групи тестування і незалежної служби сертифікації). Частота навчання. Види і доступність підтримки.Визначення стандартів і процедур використання коштів
План переходу повинен визначати такі стандарти і процедури використання коштів:
Інструкції по моделюванню та проектуванню. Угоди з присвоєння імен. Процедури контролю якості та процесів приймання, включаючи розклад експертиз і використовувані методології. Процедури резервного копіювання, захисту майстер-копій і конфігурації бази даних. Процедури інтеграції з існуючими засобами і базами даних. Процедури спільного використання даних і контролю цілісності БД. Стандарти та процедури забезпечення таємності. Стандарти документування.Стандарти використання CASE-засобів, вироблені під час пілотного проекту, повинні використовуватися в якості відправної точки для розробки більш повного набору стандартів використання коштів в даній організації (див. підрозділ 1.3). При цьому має враховуватися досвід учасників пілотного проекту.
Реалізація плану переходу
Реалізація плану переходу вимагає постійного моніторингу використання CASE-засобів, забезпечення поточної підтримки, супроводу та безпека коштів у міру необхідності.
Періодичні експертизи
Досягнуті результати повинні періодично піддаватися експертизі відповідно до графіка, план переходу повинен коригуватися при необхідності. Постійна увага повинна приділятися ступеня задоволення потреб організації і критеріїв успішного впровадження CASE-засобів.
Періодичні експертизи повинні продовжуватися і після завершення процесу впровадження. Такі експертизи можуть аналізувати метрики та іншу інформацію, що отримується в процесі роботи з CASE-засобами, щоб визначати, наскільки добре вони продовжують виконувати необхідні функції. Такі експертизи можуть також вказати на необхідність додаткової модифікації процесів.
Поточна підтримка
Поточна підтримка необхідна для наступного:
Відповідей на питання, пов'язані з використанням коштів. Передачі інформації про досягнуті успіхи та отриманих уроків іншим фахівцям організації. Модифікації та вдосконалення стандартів, угод та процедур, пов'язаних з використанням коштів. Інтеграції нових засобів з існуючими та супроводження інтегрованих засобів у міру появи нових версій. Допомоги новим співробітникам в освоєнні коштів і пов'язаних з ними процедур. Планування і контролю оновлення версій. Планування впровадження нових можливостей засобів в організаційні процеси.Дії, що виконуються в процесі переходу
Для підтримки процесу переходу до практичного використання коштів бажано виконання наступних дій:
Підтримка поточного навчання. Потреба в навчанні може виникати періодично внаслідок появи нових версій коштів або залучення до проекту нових співробітників. Підтримка рольових функцій, пов'язаних з процесом впровадження. Оскільки впровадження CASE-засобів призводить до змін у культурі організації, необхідно в процесі впровадження виділити ряд ключових ролей (такі, як керівництво вищого рівня, проектна група і цільові групи). Методики управління оновленням версій. Ці методики можуть бути пов'язані з оновленням версій, процедурами установки, процедурами контролю якості для оцінки нових версій, процедурами оновлення бази даних, конфігурацією версій і середовищем підтримки (інші кошти, операційна система і т.д.). Вільний доступ до інформації. Повинні бути визначені механізми, що забезпечують вільний доступ до інформації про досвід впровадження і витягнутих з цього уроках, зокрема дошки оголошень, інформаційні бюлетені, призначені для користувача групи, семінари та публікації. Налагодження тісної робочого взаємодії з постачальником. Така взаємодія дозволяє організації бути в курсі планів постачальника і забезпечувати оперативне задоволення своїх вимог.Для успішного впровадження CASE-засобів в організації істотно важливою є послідовність в їх застосуванні. Оскільки більшість систем розробляються колективно, необхідно визначити характер майбутнього використання коштів як окремими розробниками, так і групами. Використання стандартних процедур дозволить забезпечити плавний перехід між окремими стадіями ЖЦ ПЗ.
Як правило, всі розуміють, що навчання є центральним ланкою, що забезпечують нормальне використання CASE-засобів в організації. Тим не менш, досить поширена помилка полягає в тому, що виробляється початкове навчання для групи непідготовлених користувачів, а потім все обмежується мінімальним поточним навчанням. Учасники пілотного проекту, що отримали початкове навчання, можуть бути високо кваліфікованими ентузіастами нової технології, які прагнуть використовувати її будь-що-будь. З іншого боку, для розробників, які будуть брати участь у проекті в подальшому, може знадобитися більш інтенсивне і глибоке навчання, а також постійна підтримка у використанні засоби.
На додаток до цього слід зазначити, що кожна категорія персоналу (наприклад, адміністратори коштів, служба підтримки робочих місць, інтегратори засобів, служба супроводу і розробники додатків) потребує різному навчанні.
Навчання не повинно замикатися тільки на користувачах CASE-засобів, навчатися повинні також ті співробітники організації, на діяльність яких так чи інакше впливає використання CASE-засобів.
У процесі подальшого використання коштів в організації навчання має стати частиною процесу орієнтації при наймі нових співробітників і залучення співробітників до проектів, в яких використовуються CASE-засоби. Навчання повинно стати невід'ємною складовою частиною нормативних матеріалів, що стосуються діяльності організації, які пропонуються новим співробітникам.
Одна загальна помилка, яка робиться в процесі переходу, полягає в недооцінці ресурсів, необхідних для підтримки постійного використання складних CASE-засобів. Зростання необхідних ресурсів викликається трьома причинами:
Складністю коштів, Частотою появи нових версій, Взаємодією між засобами і зовнішнім середовищем.Складність коштів призводить до зростання потреб у ретельному і продуманому навчанні. Крім того, багато CASE-засоби можуть використовуватися тільки кваліфікованими фахівцями, які вміють супроводжувати проектні бази даних і оперативно реагувати на виникаючі проблеми. Висока частота оновлення версій засобів може призвести до виникнення нетривіальних проблем, які найчастіше не беруться до уваги. Такі оновлення зазвичай згубно позначаються на жорстких плани та графіки роботи. Взаємодія між засобами і зовнішньої по відношенню до них середовищем також може іноді породжувати деякі проблеми. Мається на увазі той факт, що хоча багато засобів досягли рівня мінімальної несумісності даних між окремими версіями, проблеми забезпечення сумісності з іншими елементами зовнішнього середовища залишаються в силі.
Оцінка результатів переходу
Програма постійної оцінки якості та продуктивності ПЗ має важливе значення для наступного:
Визначення ступеня вдосконалення процесів, випередження можливих стратегічних прорахунків, Своєчасного відмови від використання застарілої технології.Щоб визначити, наскільки ефективно нове CASE-засіб підвищує продуктивність і / або якість, організація повинна спиратися на деякі базові дані. На жаль, лише деякі організації в даний час накопичують дані для реалізації програми поточної кількісної оцінки та удосконалення процесів. Для доказу ефективності CASE-засобів і їх можливостей поліпшувати продуктивність необхідні такі базові метричні дані, як:
Використане час, Час, виділений персонально для конкретних фахівців, Розмір, складність і якість ПЗ, Зручність супроводу.Метрична оцінка повинна починатися з реальної оцінки поточного стану середовища ще до початку впровадження CASE-засобів і підтримувати процедури постійного накопичення даних.
Період часу, протягом якого виконується кількісна оцінка впливу, що чиниться впровадженням CASE-засобів, є дуже значущою величиною з точки зору визначення ступеня успішності переходу. Деякі організації, успішно впровадили в кінцевому рахунку CASE-засоби, зіткнулися з короткочасними негативними ефектами на початку процесу. Інші, успішно почавши, недооцінили довготривалі витрати на супровід і навчання. Внаслідок цього, найбільш прийнятний часовий інтервал для оцінки ступеня успішності впровадження повинен бути достатньо великим, щоб подолати будь-які негативні ефекти на початковому етапі, а також змоделювати майбутні довготривалі витрати. З іншого боку, даний інтервал повинен відповідати цілям організації і очікуваним результатам.
У кінцевому рахунку, досвід, отриманий при впровадженні CASE-засобів, може частково змінити цілі організації і очікування, що покладаються на CASE-засоби. Наприклад, організація може зробити висновок, що кошти доцільно використовувати для більшого чи меншого кола користувачів і процесів у циклі створення і супроводу ПЗ. Такі зміни в очікуваннях часто можуть дати позитивні результати, але можуть також призвести до внесення відповідних коректив у визначення ступеня успішного впровадження CASE-засобів в даній організації.
Результатом даного етапу є впровадження CASE-засобів в повсякденну практику організації, при цьому більше не вимагається якого-небудь спеціального планування. Крім того, підтримка CASE-засобів включається до плану поточної підтримки ПЗ в даній організації.
Література Вендров А.М. Один з підходів до вибору засобів проектування баз даних і додатків. "СУБД", 1995, № 3. Зіндер Є.З. Бізнес-реінжиніринг і технології системного проектування. Навчальний посібник. М., Центр Інформаційних Технологій, 1996 Калянов Г.М. CASE. Структурний системний аналіз (автоматизація та застосування). М., "Лорі", 1996. Марка Д.А., МакГоуен К. Методологія структурного аналізу і проектування. М., "Метатехнология", 1993. Міжнародні стандарти, що підтримують життєвий цикл програмних засобів. М., МП "Економіка", 1996 Створення інформаційної системи підприємства. "Computer Direct", 1996, N2 Шлеер С., Меллор С. Об'єктно-орієнтований аналіз: моделювання світу в станах. Київ, "Діалектика", 1993. Barker R. CASE * Method. Entity-Relationship Modelling. Copyright Oracle Corporation UK Limited, Addison-Wesley Publishing Co., 1990. Barker R. CASE * Method. Function and Process Modelling. Copyright Oracle Corporation UK Limited, Addison-Wesley Publishing Co., 1990. Boehm BW A Spiral Model of Software Development and Enhancement. ACM SIGSOFT Software Engineering Notes, Aug. 1986 Chris Gane, Trish Sarson. Structured System Analysis. Prentice-Hall, 1979. Edward Yourdon. Modern Structured Analysis. Prentice-Hall, 1989. Tom DeMarco. Structured Analysis and System Specification. Yourdon Press, New York, 1978. Westmount I-CASE User Manual. Westmount Technology BV, Netherlands, 1994. Uniface V6.1 Designers 'Guide. Uniface BV, Netherlands, 1994. IEEE Std 1348-1995. IEEE Recommended Practice for the Adoption of CASE Tools. IEEE Std 1209-1992. IEEE Recommended Practice for the Evaluation and Selection of CASE Tools. PVCS Version Manager. User's Guide. PVCS Tracker. User's Guide. QA Partner. User's Guide. Новоженов Ю.В. Об'єктно-орієнтовані технології розробки складних програмних систем. М., 1996. Панащук С.А. Розробка інформаційних систем з використанням CASE-системи Silverrun. "СУБД", 1995, № 3. Горчинська О.Ю. Designer/2000 - нове покоління CASE-продуктів фірми ORACLE. "СУБД", 1995, № 3. Горін С.В., Тандоев А.Ю. Застосування CASE-засоби Erwin 2.0 для інформаційного моделювання в системах обробки даних. "СУБД", 1995, № 3. Горін С.В., Тандоев А.Ю. CASE-засіб S-Designor 4.2 для розробки структури бази даних. "СУБД", 1996, № 1. DATARUN Concepts. Computer Systems Advisers Research Ltd., 1994. SE Companion Installation and Administration Manual. SECA Inc., 1995. Петров Ю.К. JAM - інструментальний засіб розробки додатків в інформаційних системах архітектури "клієнт / сервер", побудованих на базі РСУБД. "СУБД", 1995, № 3.