
- •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
1.3. Методології й технології проектування вс
1.3.1. Загальні вимоги до методології й технології
Методології, технології й інструментальні засоби проектування (CASE-засобу) становлять основу проекту будь-якої ВС. Методологія реалізується через конкретні технології й підтримуючі їхні стандарти, методики й інструментальні засоби, які забезпечують виконання процесів ЖЦ.
Технологія проектування визначається як сукупність трьох складових:
покрокової процедури, що визначає послідовність технологічних операцій проектування (мал. 1.4);
критеріїв і правил, які використовуються для оцінки результатів виконання технологічних операцій;
нотацій (графічних і текстових засобів), використовуваних для опису проектованої системи.
Мал. 1.4. Подання технологічної операції проектування
Технологічні інструкції, що становлять основний зміст технології, повинні складатися з опису послідовності технологічних операцій, умов, в залежності від яких виконується та або інша операція, і описів самих операцій.
Технологія проектування, розробки й супроводу ВС повинна задовольняти наступним загальним вимогам:
технологія повинна підтримувати повний ЖЦ ВС;
технологія повинна забезпечувати гарантоване досягнення цілей розробки ВС із заданою якістю й у встановлений час;
технологія повинна забезпечувати можливість виконання великих проектів у вигляді підсистем (тобто можливість декомпозиції проекту на складові частини, що розроблюються групами обмеженої кількості виконавців з наступною інтеграцією складових частин). Досвід розробки великих ВС показує, що для підвищення ефективності робіт необхідно розбити проект на окремі слабо зв'язані за даними й функціям підсистеми. Реалізація підсистем повинна виконуватися окремими групами фахівців. При цьому необхідно забезпечити координацію ведення загального проекту й виключити дублювання результатів робіт кожної проектної групи, що може виникнути при наявності загальних даних і функцій;
технологія повинна забезпечувати можливість ведення робіт по проектуванню окремих підсистем невеликими групами (3-7 чоловік). Це обумовлено принципами керованості колективу й підвищення продуктивності за рахунок мінімізації числа зовнішніх зв'язків;
технологія повинна забезпечувати мінімальний час отримання працездатної ВС. Мова йде не про строки готовності всієї ВС, а про строки реалізації окремих підсистем. Реалізація ВС у цілому в короткий термін може вимагати залучення великої кількості розробників, при цьому ефект може виявитися меншим, ніж при реалізації в більш короткий термін окремих підсистем меншою кількістю розроблювачів. Практика показує, що навіть при наявності повністю завершеного проекту, впровадження йде послідовно по окремих підсистемах;
технологія повинна передбачати можливість керування конфігурацією проекту, версій проекту і його складових, можливість автоматичного випуску проектної документації й синхронізацію її версій з версіями проекту;
технологія повинна забезпечувати незалежність виконуваних проектних рішень від засобів реалізації ВС;
технологія повинна бути підтримана комплексом погоджених CASE-засобів, що забезпечують автоматизацію процесів, що виконуються на всіх стадіях ЖЦ.
Реальне застосування будь-якої технології проектування, розробки й супровід ВС у конкретній організації й конкретному проекті неможливо без вироблення низки стандартів (правил, угод), які повинні дотримуватися всіма учасниками проекту. До таких стандартів відносяться наступні:
стандарт проектування;
стандарт оформлення проектної документації;
стандарт користувацького інтерфейсу.
Стандарт проектування повинен складатися з:
набору необхідних моделей (діаграм) на кожній стадії проектування та ступенів їх деталізації;
правила фіксації проектних рішень на діаграмах, у тому числі: правила іменування об'єктів (включаючи угоди по термінології), набір атрибутів для всіх об'єктів і правила їх заповнення на кожній стадії, правила оформлення діаграм, включаючи вимоги до форми й розмірів об'єктів, і т.д.;
вимоги до конфігурації робочих місць розробників, включаючи налаштування операційної системи, налаштування CASE-засобів, загальні налаштування проекту й т.д.;
механізм забезпечення спільної роботи над проектом, у тому числі: правила інтеграції підсистем проекту, правила підтримки проекту в однаковому для всіх розробників вигляді (регламент обміну проектною інформацією, механізм фіксації загальних об'єктів і т.д.), правила перевірки проектних рішень на конфліктність і т.д.
Стандарт оформлення проектної документації повинен складатися з:
комплектності, складу і структури документації на кожній стадії проектування;
вимог до її оформлення (включаючи вимоги до змісту розділів, підрозділів, пунктів, таблиць і т.д.),
правила підготовки, розгляду, узгодження й затвердження документації із вказівкою крайніх термінів для кожної стадії;
вимоги до налаштування видавничої системи, що використовується як вбудований засіб підготовки документації;
вимоги до настроювання CASE-засобів для забезпечення підготовки документації відповідно до встановлених вимог.
Стандарт інтерфейсу користувача повинен складатися з:
правила оформлення екранів (шрифти й колірна палітра), склад і розташування вікон й елементів керування;
правила використання клавіатури й миші;
правила оформлення текстів допомоги;
перелік стандартних повідомлень;
правила обробки реакції користувача.