- •Курс лекцій
- •Видавничих систем”
- •4.2.4. Критерії оцінки і вибору
- •1. Основи методології проектування видавничих систем
- •1.1. Життєвий цикл видавничих систем.
- •1.2. Моделі життєвого циклу вс
- •1.3. Методології й технології проектування вс
- •1.3.1. Загальні вимоги до методології й технології
- •1.3.2. Методологія rad
- •2. Структурний підхід до проектування іс
- •2.1. Сутність структурного підходу
- •2.2. Методологія функціонального моделювання sadt
- •2.2.1. Склад функціональної моделі
- •2.2.2. Ієрархія діаграм
- •2.2.3. Типи зв'язків між функціями
- •2.3. Моделювання потоків даних (процесів)
- •2.3.1. Зовнішня суть
- •2.3.2. Системи і підсистеми
- •2.3.3. Процеси
- •2.3.4. Накопичувачі даних
- •2.3.5. Потоки даних
- •2.3.6. Побудова ієрархії діаграм потоків даних
- •2.4. Моделювання даних
- •2.4.1. Case-метод Баркера
- •2.4.2. Методологія idef1
- •2.4.2. Критерії оцінки і вибору
- •Синтаксично кероване редагування. Можливість введення і редагування початкових кодів на одному або декількох мовах з одночасним синтаксичним контролем.
- •2.4.3. Підхід, використовуваний в case-засобі Vantage Team Builder
- •2.5. Приклад використання структурного підходу
- •2.5.1. Опис предметної області
- •2.5.2. Організація проекту
- •3. Програмні засоби підтримки життєвого циклу по
- •3.1. Методології проектування по як програмні продукти. Методологія datarun і інструментальний засіб se Companіon
- •3.1.1. Методологія datarun
- •3.1.2. Інструментальний засіб se Companіon
- •3.2. Case-засобу. Загальна характеристика і класифікація
- •4. Технологія впровадження case-засобів
- •4.1. Визначення потреб в case-засобах
- •4.1.1. Аналіз можливостей організації
- •4.1.2. Визначення організаційних потреб
- •4.1.3. Аналіз ринку case-засобів
- •4.1.4. Визначення критеріїв успішного впровадження
- •4.1.5. Розробка стратегії впровадження case-засобів
- •4.2. Оцінка і вибір case-засобів
- •4.2.1. Загальні відомості
- •4.2.2. Процес оцінки
- •4.2.3. Процес вибору
- •4.2.4. Критерії оцінки і вибору
- •4.2.4.2. Простота використання
- •4.2.4.3. Ефективність
- •4.2.4.4. Супроводжуваність
- •4.2.4.5. Переносимість
- •4.2.4.6. Загальні критерії
- •4.2.5. Приклад підходу до визначення критеріїв вибору case-засобів
- •4.3. Виконання пілотного проекту
- •4.4. Перехід до практичного використання case-засобів
- •5. Характеристики case-засобів
- •5.4. Локальные средства (eRwin, bPwin, s-Designor, case.Аналитик)
- •5.5. Об'єктно-орієнтовані case-засоби (Rational Rose)
- •5.6. Допоміжні засоби підтримки життєвого циклу по
- •5.6.1. Засоби конфігураційного управління
- •5.6.2. Засоби документування
- •5.6.3. Засоби тестування
- •5.7. Приклади комплексів case-засобів
1.3. Методології й технології проектування вс
1.3.1. Загальні вимоги до методології й технології
Методології, технології й інструментальні засоби проектування (CASE-засобу) становлять основу проекту будь-якої ВС. Методологія реалізується через конкретні технології й підтримуючі їхні стандарти, методики й інструментальні засоби, які забезпечують виконання процесів ЖЦ.
Технологія проектування визначається як сукупність трьох складових:
покрокової процедури, що визначає послідовність технологічних операцій проектування (мал. 1.4);
критеріїв і правил, які використовуються для оцінки результатів виконання технологічних операцій;
нотацій (графічних і текстових засобів), використовуваних для опису проектованої системи.
Мал. 1.4. Подання технологічної операції проектування
Технологічні інструкції, що становлять основний зміст технології, повинні складатися з опису послідовності технологічних операцій, умов, в залежності від яких виконується та або інша операція, і описів самих операцій.
Технологія проектування, розробки й супроводу ВС повинна задовольняти наступним загальним вимогам:
технологія повинна підтримувати повний ЖЦ ВС;
технологія повинна забезпечувати гарантоване досягнення цілей розробки ВС із заданою якістю й у встановлений час;
технологія повинна забезпечувати можливість виконання великих проектів у вигляді підсистем (тобто можливість декомпозиції проекту на складові частини, що розроблюються групами обмеженої кількості виконавців з наступною інтеграцією складових частин). Досвід розробки великих ВС показує, що для підвищення ефективності робіт необхідно розбити проект на окремі слабо зв'язані за даними й функціям підсистеми. Реалізація підсистем повинна виконуватися окремими групами фахівців. При цьому необхідно забезпечити координацію ведення загального проекту й виключити дублювання результатів робіт кожної проектної групи, що може виникнути при наявності загальних даних і функцій;
технологія повинна забезпечувати можливість ведення робіт по проектуванню окремих підсистем невеликими групами (3-7 чоловік). Це обумовлено принципами керованості колективу й підвищення продуктивності за рахунок мінімізації числа зовнішніх зв'язків;
технологія повинна забезпечувати мінімальний час отримання працездатної ВС. Мова йде не про строки готовності всієї ВС, а про строки реалізації окремих підсистем. Реалізація ВС у цілому в короткий термін може вимагати залучення великої кількості розробників, при цьому ефект може виявитися меншим, ніж при реалізації в більш короткий термін окремих підсистем меншою кількістю розроблювачів. Практика показує, що навіть при наявності повністю завершеного проекту, впровадження йде послідовно по окремих підсистемах;
технологія повинна передбачати можливість керування конфігурацією проекту, версій проекту і його складових, можливість автоматичного випуску проектної документації й синхронізацію її версій з версіями проекту;
технологія повинна забезпечувати незалежність виконуваних проектних рішень від засобів реалізації ВС;
технологія повинна бути підтримана комплексом погоджених CASE-засобів, що забезпечують автоматизацію процесів, що виконуються на всіх стадіях ЖЦ.
Реальне застосування будь-якої технології проектування, розробки й супровід ВС у конкретній організації й конкретному проекті неможливо без вироблення низки стандартів (правил, угод), які повинні дотримуватися всіма учасниками проекту. До таких стандартів відносяться наступні:
стандарт проектування;
стандарт оформлення проектної документації;
стандарт користувацького інтерфейсу.
Стандарт проектування повинен складатися з:
набору необхідних моделей (діаграм) на кожній стадії проектування та ступенів їх деталізації;
правила фіксації проектних рішень на діаграмах, у тому числі: правила іменування об'єктів (включаючи угоди по термінології), набір атрибутів для всіх об'єктів і правила їх заповнення на кожній стадії, правила оформлення діаграм, включаючи вимоги до форми й розмірів об'єктів, і т.д.;
вимоги до конфігурації робочих місць розробників, включаючи налаштування операційної системи, налаштування CASE-засобів, загальні налаштування проекту й т.д.;
механізм забезпечення спільної роботи над проектом, у тому числі: правила інтеграції підсистем проекту, правила підтримки проекту в однаковому для всіх розробників вигляді (регламент обміну проектною інформацією, механізм фіксації загальних об'єктів і т.д.), правила перевірки проектних рішень на конфліктність і т.д.
Стандарт оформлення проектної документації повинен складатися з:
комплектності, складу і структури документації на кожній стадії проектування;
вимог до її оформлення (включаючи вимоги до змісту розділів, підрозділів, пунктів, таблиць і т.д.),
правила підготовки, розгляду, узгодження й затвердження документації із вказівкою крайніх термінів для кожної стадії;
вимоги до налаштування видавничої системи, що використовується як вбудований засіб підготовки документації;
вимоги до настроювання CASE-засобів для забезпечення підготовки документації відповідно до встановлених вимог.
Стандарт інтерфейсу користувача повинен складатися з:
правила оформлення екранів (шрифти й колірна палітра), склад і розташування вікон й елементів керування;
правила використання клавіатури й миші;
правила оформлення текстів допомоги;
перелік стандартних повідомлень;
правила обробки реакції користувача.