ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 24.08.2024
Просмотров: 15
Скачиваний: 0
Тема: «Вступ. Поняття технології програм. Методи програм. Етапи розвитку технології та методів програмування».
План
-
Визначення технології програмування
-
Технології програмування, як технологія розробки надійних програмних засобів
-
Т.П. та інформатизація суспільства.
-
Коротка характеристика розвитку програмування по десятиліттях
-
Загальні принципи розробки програмних засобів
-
Мета модульного програмування
-
Методи розробки структури програми, структурне програмування.
Загальні принципи розробки програмних засобів
-
Специфіка розробки програмних засобів
-
Ж.Ц.П.З.
3) Поняття якості програмного засобу
Кожен ПЗ повинне виконувати задуманими функціями. Якість ПЗ - це сукупність його рис і характеристик, які впливають на його здатність задовольняти задані потреби користувачів
В даний час критеріями якості ПЗ прийнято вважати:
-
функціональність
-
надійність
-
легкість застосування
-
ефективність
-
супровідь
-
мобільність.
4) Забезпечення надійності - основний мотив розробки програмних засобів
Загальні принципи забезпечення надійності ПЗ:
-
попередження помилок;
-
самовиявлення помилок;
-
самовиправлення помилок;
-
забезпечення стійкості до помилок.
Тема: «Методології та технології проектування ІС. Загальні вимоги до методології та технології. Життєвий цикл ІС. Моделі ЖЦ ПЗ.».
План
-
Життєвий цикл ІС.
-
Моделі життєвого циклу ПЗ.
-
Методології і технології проектування ІС.
-
Загальні вимоги до методології і технології
Структура ЖЦ ПЗ базується на трьох групах процесів:
-
основні процеси ЖЦ ПЗ (придбання, постачання, розробка, експлуатація, супровід);
-
допоміжні процеси, що забезпечують виконання основних процесів (документування, управління конфігурацією, забезпечення якості, верифікація, атестація, оцінка, аудит, вирішення проблем);
-
організаційні процеси (управління проектами, створення інфраструктури проекту, визначення, оцінка і поліпшення самого ЖЦ, навчання).
2) Моделі життєвого циклу ПЗ
Найбільшого поширення набули наступні дві основні моделі ЖЦ:
-
каскадна модель (70-85 г.г.);
Мал. 1.Каскадна схема розробки ПЗ
В процесі створення ПЗ постійно виникала потреба в поверненні до попередніх етапів і уточненні або перегляді раніше ухвалених рішень. В результаті реальний процес створення ПЗ приймав наступний вигляд (мал.2):
Мал. 2. Реальний процес розробки ПЗ по каскадній схемі
Позитивні сторони застосування каскадного підходу полягають в наступному:
-
на кожному етапі формується закінчений набір проектної документації, що відповідає критеріям повноти і узгодженості;
-
виконувані в логічній послідовності етапи робіт дозволяють планувати терміни завершення всіх робіт і відповідні витрати.
Основним недоліком каскадного підходу є істотне запізнювання з отриманням результатів. Користувачі можуть внести свої зауваження тільки після того, як робота над системою буде повністю завершена.
-
спіральна модель (86-90 г.г.).
Мал. Спіральна модель ЖЦ
Методології і технології проектування іс. Загальні вимоги до методології і технології
Методології, технології і інструментальні засоби проектування (CASE-средства) складають основу проекту будь-якій ІС. Методологія реалізується через конкретні технології і стандарти, що підтримують їх, методики і інструментальні засоби, які забезпечують виконання процесів ЖЦ.
Технологія проектування визначається як сукупність трьох складових:
-
покрокової процедури, що визначає послідовність технологічних операцій проектування (мал. 4);
-
критеріїв і правил, використовуваних для оцінки результатів виконання технологічних операцій;
-
нотацій (графічних і текстових засобів), використовуваних для опису проектованої системи.
Мал. 4. Представлення технологічної операції проектування
Технологія проектування, розробки і супроводу іс повинна задовольняти наступним загальним требованям:
-
технологія повинна підтримувати повний ЖЦ ПЗ;
-
технологія повинна забезпечувати гарантоване досягнення цілей розробки ІС із заданою якістю і у встановлений час;
-
технологія повинна забезпечувати можливість виконання крупних проектів у вигляді підсистем (тобто можливість декомпозиції проекту на складові частини, що розробляються групами виконавців обмеженої чисельності з подальшою інтеграцією складових частин);
-
технологія повинна забезпечувати можливість ведення робіт по проектуванню окремих підсистем невеликими групами (3-7 чоловік). Це обумовлено принципами керованості колективу і підвищення продуктивності за рахунок мінімізації числа зовнішніх зв'язків;
-
технологія повинна забезпечувати мінімальний час отримання працездатної ІС;
-
технологія повинна передбачати можливість управління конфігурацією проекту, ведення версій проекту і його складових, можливість автоматичного випуску проектної документації і синхронізацію її версій з версіями проекту;
-
технологія повинна забезпечувати незалежність виконуваних проектних рішень від засобів реалізації ІС (систем управління базами даних (СУБД), операційних систем, мов і систем програмування);
-
технологія повинна бути підтримана комплексом узгоджених CASE-засобів, що забезпечують автоматизацію процесів, що виконуються на всіх стадіях ЖЦ.
Реальне застосування будь-якої технології проектування, розробки і супроводу ІС в конкретній організації і конкретному проекті неможливо без вироблення ряду стандартів (правив, угод), які повинні дотримуватися всіма учасниками проекту. До таких стандартів відносяться наступні:
-
стандарт проектування;
-
стандарт оформлення проектної документації;
-
стандарт призначеного для користувача інтерфейсу.
Стандарт проектування повинен встановлювати:
-
набір необхідних моделей (діаграм) на кожній стадії проектування і ступінь їх деталізації;
-
правила фіксації проектних рішень на діаграмах, зокрема: правила іменування об'єктів (включаючи угоди по термінології), набір атрибутів для всіх об'єктів і правила їх заповнення на кожній стадії, правила оформлення діаграм, включаючи вимоги до форми і розмірів об'єктів, і т. д.;
-
вимоги до конфігурації робочих місць розробників, включаючи настройки операційної системи, настройки CASE-засобів, загальні настройки проекту і т. д.;
-
механізм забезпечення спільної роботи над проектом, зокрема: правила інтеграції підсистем проекту, правила підтримки проекту в однаковому для всіх розробників стані (регламент обміну проектною інформацією, механізм фіксації загальних об'єктів і так далі), правила перевірки проектних рішень на несуперечність і так далі
Стандарт оформлення проектної документації повинен встановлювати:
-
комплектність, склад і структуру документації на кожній стадії проектування;
-
вимоги до її оформлення (включаючи вимоги до змісту розділів, підрозділів, пунктів, таблиць і так далі)
-
правила підготовки, розгляду, узгодження і затвердження документації з вказівкою граничних термінів для кожної стадії;
-
вимоги до настройки видавничої системи, використовуваної як вбудований засіб підготовки документації;
-
вимоги до настройки CASE-засобів для забезпечення підготовки документації відповідно до встановлених вимог.
Стандарт інтерфейсу користувача повинен встановлювати:
-
правила оформлення екранів (шрифти і колірна палітра), склад і розташування вікон і елементів управління;
-
правила використання клавіатури і миші;
-
правила оформлення текстів допомоги;
-
перелік стандартних повідомлень;
-
правила обробки реакції користувача.
Тема: «Методологія RAD. ЖЦНЗ за методологією RAD. Основні принципи методології RAD».
План
-
Методологія
-
Етапи ЖЦПЗ за методологією
-
Фаза планування на аналізі (вимоги ПЗ)
-
Фаза проектування
-
Фаза побудови
-
Фаза випровадження
-
Фаза аналізу та планування вимог результати цієї повинна бути:
А) список функцій
Б) періодичність
a) Фаза аналізу планування вимог. Результатом цієї повинна бути проведення:
-
Загально інформаційної моделі
-
Функціональні моделі системи і підсистеми
-
Точно визначена за допомогою case засобів інтерфейси між підсистемами виконуються автономно.
b) Фаза проектування
c) Фаза побудови виконується безпосередньо розробка застосування. На цій фазі виконується і тестування. Завершується фізичне проектування системи наступним:
-
Визначається необхідність розроблення файлів.
-
Проводиться аналіз використання даних.
-
Проводиться фізичне проектування бд.
-
Визначаються вимоги до апаратних ресурсів.
-
Визначаються способи збільшення продуктивності.
-
Завершується розробка документації проекту.
Результатом цієї фази є готова система, що задовольняє усім узгодження вимогам.
d) Фаза впровадження.
Основні принципи методології RAD:
-
Розробка застосувань ітераціями
-
Необов’язковість повного завершення робіт на кожному з етапів ЖЦ
-
Обов’язкове залучення користувачів до процесу розробки ПЗ.
-
Необхідне застосування case засобів, що забезпечують цілісність проекту.
-
Необхідність використовувати генераторів коду.
-
Тестування і розвиток проекту, яке здійснюється одночасно з розробкою
-
Введення розробки нечисленною добре керованою командою розробників (професіоналів).
-
Грамотне керівництво розробкою ПЗ, чітке планування і контроль в виконанні робіт.
Тема: «Структурний підхід ПЗ».
План
-
Суть структурного підходу до проектування ПЗ.
-
Принципи структурного проектування.
-
Структурний підхід ПЗ створюється за допомогою певних моделей. Найбільш поширеними є :
-
DFD (Data Flow Diagrams) – діаграми потоків даних;
-
SADT (Structured Analysis and Design Technique – метод моделі проектування) – моделі і відповідні функціональні діаграми;
-
ERD (Entity-Relationship Diagrams) – діаграми «сутність - зв’язок».
-
Тема: «Методологія функціонального моделювання SADT».
План
-
Методологія SADT
-
Склад функціональної моделі
-
Ієрархія діаграм
-
Типи зв’язків між функціями
Елементи методу ґрунтуються на наступних концепціях:
-
Графічне представлення блокового моделювання. Функція відображається у вигляді блоку, а інтерфейси входу-виходу дугами.
-
Строгість і точність. Обмеження кількості блоків на кожному рівні декомпозиції (правило 3-6 блоків), зв’язність діаграм (номери блоків), унікальність міток, синтаксичні правила для графіки, розділення входів і управлінь.
-
Виділення організації від функції (виключення впливу адміністративної структури організації на функціональну модель).
Методологія SADT відображає функціональну структуру об’єкту, тобто дії і зв’язки між цими діями.
-
Обмеження кількості блоків на кожному рівні декомпозиції (правила 3-6 блоків)
-
Зв’язність діаграм (номерів блоків)
-
Унікальність найменувань блоків
-
Синтаксичні правила для графіків (блоків і дуг)
-
Розділення входів та управлінь (правило визначення ролі даних)
-
Відділення організацій від функцій (тобто виключення впливу структури)