Методології, технології й інструментальні засоби проектування ( CASE-Засобу) становлять основу проекту будь-якого програмного продукту. Методологія реалізується через конкретні технології й підтримуючі їхні стандарти, методики й інструментальні засоби, які забезпечують виконання процесів ЖЦ.
Технологія проектування визначається як сукупність трьох складових:
покрокової процедури, що визначає послідовність технологічних операцій проектування;
критеріїв і правил, використовуваних для оцінки результатів виконання технологічних операцій;
нотацій (графічних і текстових засобів), використовуваних для опису проектованої системи.
Рис. Подання технологічної операції проектування
Технологічні інструкції, що становлять основний зміст технології, повинні складатися з опису послідовності технологічних операцій, умов, залежно від яких виконується та або інша операція, і описів самих операцій.
Технологія проектування, розробки й супроводження програм повинна задовольняти наступним загальним вимогам:
технологія повинна підтримувати повний ЖЦ ПЗ;
технологія повинна забезпечувати гарантоване досягнення цілей розробки програмного забезпечення із заданою якістю й у встановлений час;
технологія повинна забезпечувати можливість виконання великих проектів у вигляді підсистем (тобто можливість декомпозиції проекту на складові частини, розроблювальні групами виконавців обмеженої чисельності з наступною інтеграцією складових частин). Досвід розробки великих програмних продуктів показує, що для підвищення ефективності робіт необхідно розбити проект на окремі слабко зв'язані за даними й функціям підсистеми. Реалізація підсистем повинна виконуватися окремими групами фахівців. При цьому необхідно забезпечити координацію ведення загального проекту й виключити дублювання результатів робіт кожної проектної групи, що може виникнути в силу наявності загальних даних і функцій;
технологія повинна забезпечувати можливість ведення робіт із проектування окремих підсистем невеликими групами ( 3-7 чоловік). Це обумовлено принципами керованості колективу й підвищення продуктивності за рахунок мінімізації числа зовнішніх зв'язків;
технологія повинна забезпечувати мінімальний час одержання працездатної ИС. Мова йде не про строки готовності всієї програми, а про строки реалізації окремих підсистем. Реалізація програмного продукту в цілому в короткий термін може зажадати залучення великої кількості розроблювачів, при цьому ефект може виявитися нижче, ніж при реалізації в більше короткий термін окремих підсистем меншим числом розроблювачів. Практика показує, що навіть при наявності повністю завершеного проекту, впровадження йде послідовно по окремих підсистемах;
технологія повинна передбачати можливість керування конфігурацією проекту, ведення версій проекту і його складових, можливість автоматичного випуску проектної документації й синхронізацію її версій з версіями проекту;
технологія повинна забезпечувати незалежність виконуваних проектних рішень від засобів реалізації (систем керування базами даних (СУБД), операційних систем, мов і систем програмування);
технологія повинна бути підтримана комплексом погоджених CASE-Засобів, що забезпечують автоматизацію процесів, виконуваних на всіх стадіях ЖЦ. Загальний підхід до оцінки й вибору CASE-Засобів описаний у розділі 4, приклади комплексів CASE-Засобів.
Реальне застосування будь-якої технології проектування, розробки й супроводи в конкретній організації й конкретному проекті неможливо без виробітку ряду стандартів (правил, угод), які повинні дотримуватися всіма учасниками проекту. До таких стандартів ставляться наступні:
стандарт проектування;
стандарт оформлення проектної документації;
стандарт користувальницького інтерфейсу.
Стандарт проектування повинен установлювати:
набір необхідних моделей (діаграм) на кожній стадії проектування й ступінь їхньої деталізації;
правила фіксації проектних рішень на діаграмах, у тому числі: правила іменування об'єктів (включаючи угоди по термінології), набір атрибутів для всіх об'єктів і правила їхнього заповнення на кожній стадії, правила оформлення діаграм, включаючи вимоги до форми й розмірів об'єктів, і т.д.;
вимоги до конфігурації робочих місць розроблювачів, включаючи настроювання операційної системи, настроювання CASE-Засобів, загальні настроювання проекту й т.д.;
механізм забезпечення спільної роботи над проектом, у тому числі: правила інтеграції підсистем проекту, правила підтримки проекту в однаковому для всіх розроблювачів стані (регламент обміну проектною інформацією, механізм фіксації загальних об'єктів і т.д.), правила перевірки проектних рішень на несуперечність і т.д.
Стандарт оформлення проектної документації повинен установлювати:
комплектність, состав і структуру документації на кожній стадії проектування;
вимоги до її оформлення (включаючи вимоги до змісту розділів, підрозділів, пунктів, таблиць і т.д.),
правила підготовки, розгляду, узгодження й твердження документації із вказівкою граничних строків для кожної стадії;
вимоги до настроювання видавничої системи, використовуваної як убудований засіб підготовки документації;
вимоги до настроювання CASE-Засобів для забезпечення підготовки документації відповідно до встановлених вимог.
Стандарт інтерфейсу користувача повинен установлювати:
правила оформлення екранів (шрифти й колірна палітра), состав і розташування вікон і елементів керування;
правила використання клавіатури й миші;
правила оформлення текстів допомоги;
перелік стандартних повідомлень;
правила обробки реакції користувача.
Лекція №3, 4
Тема: Моделі розробки програмного забезпечення. Базові процеси, переваги та недоліки. Каскадна, V – модель, модель прототипування програмного продукту. Інкриментна модель, ХР – модель, спіральна модель.
Мета: Ознайомлення з моделями розробки програмного забезпечення. Визначення переваг та недоліків.
