Тема: «Вступ. Поняття технології програм. Методи програм. Етапи розвитку технології та методів програмування».

План

1. Визначення технології програмування

2. Технології програмування, як технологія розробки надійних програмних засобів

3. Т.П. та інформатизація суспільства.

4. Коротка характеристика розвитку програмування по десятиліттях

5. Загальні принципи розробки програмних засобів

6. Мета модульного програмування

7. Методи розробки структури програми, структурне програмування.

Загальні принципи розробки програмних засобів

1. Специфіка розробки програмних засобів

2. Ж.Ц.П.З.

3) Поняття якості програмного засобу

Кожен ПЗ повинне виконувати задуманими функціями. Якість ПЗ - це сукупність його рис і характеристик, які впливають на його здатність задовольняти задані потреби користувачів

В даний час критеріями якості ПЗ прийнято вважати:

• функціональність

• надійність

• легкість застосування

• ефективність

• супровідь

• мобільність.

4) Забезпечення надійності - основний мотив розробки програмних засобів

Загальні принципи забезпечення надійності ПЗ:

• попередження помилок;

• самовиявлення помилок;

• самовиправлення помилок;

• забезпечення стійкості до помилок.

Тема: «Методології та технології проектування ІС. Загальні вимоги до методології та технології. Життєвий цикл ІС. Моделі ЖЦ ПЗ.».

План

1. Життєвий цикл ІС.

2. Моделі життєвого циклу ПЗ.

3. Методології і технології проектування ІС.

4. Загальні вимоги до методології і технології

Структура ЖЦ ПЗ базується на трьох групах процесів:

• основні процеси ЖЦ ПЗ (придбання, постачання, розробка, експлуатація, супровід);

• допоміжні процеси, що забезпечують виконання основних процесів (документування, управління конфігурацією, забезпечення якості, верифікація, атестація, оцінка, аудит, вирішення проблем);

• організаційні процеси (управління проектами, створення інфраструктури проекту, визначення, оцінка і поліпшення самого ЖЦ, навчання).

2) Моделі життєвого циклу ПЗ

Найбільшого поширення набули наступні дві основні моделі ЖЦ:

• каскадна модель (70-85 г.г.);

Мал. 1.Каскадна схема розробки ПЗ

В процесі створення ПЗ постійно виникала потреба в поверненні до попередніх етапів і уточненні або перегляді раніше ухвалених рішень. В результаті реальний процес створення ПЗ приймав наступний вигляд (мал.2):

Мал. 2. Реальний процес розробки ПЗ по каскадній схемі

Позитивні сторони застосування каскадного підходу полягають в наступному:

• на кожному етапі формується закінчений набір проектної документації, що відповідає критеріям повноти і узгодженості;

• виконувані в логічній послідовності етапи робіт дозволяють планувати терміни завершення всіх робіт і відповідні витрати.

Основним недоліком каскадного підходу є істотне запізнювання з отриманням результатів. Користувачі можуть внести свої зауваження тільки після того, як робота над системою буде повністю завершена.

• спіральна модель (86-90 г.г.).

Мал. Спіральна модель ЖЦ

Методології і технології проектування іс. Загальні вимоги до методології і технології

Методології, технології і інструментальні засоби проектування (CASE-средства) складають основу проекту будь-якій ІС. Методологія реалізується через конкретні технології і стандарти, що підтримують їх, методики і інструментальні засоби, які забезпечують виконання процесів ЖЦ.

Технологія проектування визначається як сукупність трьох складових:

• покрокової процедури, що визначає послідовність технологічних операцій проектування (мал. 4);

• критеріїв і правил, використовуваних для оцінки результатів виконання технологічних операцій;

• нотацій (графічних і текстових засобів), використовуваних для опису проектованої системи.

Мал. 4. Представлення технологічної операції проектування

Технологія проектування, розробки і супроводу іс повинна задовольняти наступним загальним требованям:

• технологія повинна підтримувати повний ЖЦ ПЗ;

• технологія повинна забезпечувати гарантоване досягнення цілей розробки ІС із заданою якістю і у встановлений час;

• технологія повинна забезпечувати можливість виконання крупних проектів у вигляді підсистем (тобто можливість декомпозиції проекту на складові частини, що розробляються групами виконавців обмеженої чисельності з подальшою інтеграцією складових частин);

• технологія повинна забезпечувати можливість ведення робіт по проектуванню окремих підсистем невеликими групами (3-7 чоловік). Це обумовлено принципами керованості колективу і підвищення продуктивності за рахунок мінімізації числа зовнішніх зв'язків;

• технологія повинна забезпечувати мінімальний час отримання працездатної ІС;

• технологія повинна передбачати можливість управління конфігурацією проекту, ведення версій проекту і його складових, можливість автоматичного випуску проектної документації і синхронізацію її версій з версіями проекту;

• технологія повинна забезпечувати незалежність виконуваних проектних рішень від засобів реалізації ІС (систем управління базами даних (СУБД), операційних систем, мов і систем програмування);

• технологія повинна бути підтримана комплексом узгоджених CASE-засобів, що забезпечують автоматизацію процесів, що виконуються на всіх стадіях ЖЦ.

Реальне застосування будь-якої технології проектування, розробки і супроводу ІС в конкретній організації і конкретному проекті неможливо без вироблення ряду стандартів (правив, угод), які повинні дотримуватися всіма учасниками проекту. До таких стандартів відносяться наступні:

• стандарт проектування;

• стандарт оформлення проектної документації;

• стандарт призначеного для користувача інтерфейсу.

Стандарт проектування повинен встановлювати:

• набір необхідних моделей (діаграм) на кожній стадії проектування і ступінь їх деталізації;

• правила фіксації проектних рішень на діаграмах, зокрема: правила іменування об'єктів (включаючи угоди по термінології), набір атрибутів для всіх об'єктів і правила їх заповнення на кожній стадії, правила оформлення діаграм, включаючи вимоги до форми і розмірів об'єктів, і т. д.;

• вимоги до конфігурації робочих місць розробників, включаючи настройки операційної системи, настройки CASE-засобів, загальні настройки проекту і т. д.;

• механізм забезпечення спільної роботи над проектом, зокрема: правила інтеграції підсистем проекту, правила підтримки проекту в однаковому для всіх розробників стані (регламент обміну проектною інформацією, механізм фіксації загальних об'єктів і так далі), правила перевірки проектних рішень на несуперечність і так далі

Стандарт оформлення проектної документації повинен встановлювати:

• комплектність, склад і структуру документації на кожній стадії проектування;

• вимоги до її оформлення (включаючи вимоги до змісту розділів, підрозділів, пунктів, таблиць і так далі)

• правила підготовки, розгляду, узгодження і затвердження документації з вказівкою граничних термінів для кожної стадії;

• вимоги до настройки видавничої системи, використовуваної як вбудований засіб підготовки документації;

• вимоги до настройки CASE-засобів для забезпечення підготовки документації відповідно до встановлених вимог.

Стандарт інтерфейсу користувача повинен встановлювати:

• правила оформлення екранів (шрифти і колірна палітра), склад і розташування вікон і елементів управління;

• правила використання клавіатури і миші;

• правила оформлення текстів допомоги;

• перелік стандартних повідомлень;

• правила обробки реакції користувача.

Тема: «Методологія RAD. ЖЦНЗ за методологією RAD. Основні принципи методології RAD».

План

8. Методологія

9. Етапи ЖЦПЗ за методологією

   1. Фаза планування на аналізі (вимоги ПЗ)

   2. Фаза проектування

   3. Фаза побудови

   4. Фаза випровадження

Фаза аналізу та планування вимог результати цієї повинна бути:

А) список функцій

Б) періодичність

a) Фаза аналізу планування вимог. Результатом цієї повинна бути проведення:

1. Загально інформаційної моделі

2. Функціональні моделі системи і підсистеми

3. Точно визначена за допомогою case засобів інтерфейси між підсистемами виконуються автономно.

b) Фаза проектування

c) Фаза побудови виконується безпосередньо розробка застосування. На цій фазі виконується і тестування. Завершується фізичне проектування системи наступним:

1. Визначається необхідність розроблення файлів.

2. Проводиться аналіз використання даних.

3. Проводиться фізичне проектування бд.

4. Визначаються вимоги до апаратних ресурсів.

5. Визначаються способи збільшення продуктивності.

6. Завершується розробка документації проекту.

Результатом цієї фази є готова система, що задовольняє усім узгодження вимогам.

d) Фаза впровадження.

Основні принципи методології RAD:

1. Розробка застосувань ітераціями

2. Необов’язковість повного завершення робіт на кожному з етапів ЖЦ

3. Обов’язкове залучення користувачів до процесу розробки ПЗ.

4. Необхідне застосування case засобів, що забезпечують цілісність проекту.

5. Необхідність використовувати генераторів коду.

6. Тестування і розвиток проекту, яке здійснюється одночасно з розробкою

7. Введення розробки нечисленною добре керованою командою розробників (професіоналів).

8. Грамотне керівництво розробкою ПЗ, чітке планування і контроль в виконанні робіт.

Тема: «Структурний підхід ПЗ».

План

1. Суть структурного підходу до проектування ПЗ.

2. Принципи структурного проектування.

1. Структурний підхід ПЗ створюється за допомогою певних моделей. Найбільш поширеними є :

   1. DFD (Data Flow Diagrams) – діаграми потоків даних;

   2. SADT (Structured Analysis and Design Technique – метод моделі проектування) – моделі і відповідні функціональні діаграми;

   3. ERD (Entity-Relationship Diagrams) – діаграми «сутність - зв’язок».

Тема: «Методологія функціонального моделювання SADT».

План

1. Методологія SADT

2. Склад функціональної моделі

3. Ієрархія діаграм

4. Типи зв’язків між функціями

Елементи методу ґрунтуються на наступних концепціях:

• Графічне представлення блокового моделювання. Функція відображається у вигляді блоку, а інтерфейси входу-виходу дугами.

• Строгість і точність. Обмеження кількості блоків на кожному рівні декомпозиції (правило 3-6 блоків), зв’язність діаграм (номери блоків), унікальність міток, синтаксичні правила для графіки, розділення входів і управлінь.

• Виділення організації від функції (виключення впливу адміністративної структури організації на функціональну модель).

Методологія SADT відображає функціональну структуру об’єкту, тобто дії і зв’язки між цими діями.

1. Обмеження кількості блоків на кожному рівні декомпозиції (правила 3-6 блоків)

2. Зв’язність діаграм (номерів блоків)

3. Унікальність найменувань блоків

4. Синтаксичні правила для графіків (блоків і дуг)

5. Розділення входів та управлінь (правило визначення ролі даних)

6. Відділення організацій від функцій (тобто виключення впливу структури)

На Садт діаграмах не вказані явно ні послідовність процесу ні час його виконання. Зворотні зв’язки ітерації зображуються за допомогою дуг. Зворотні зв’язки можуть пояснюватися коментарями, зауваженнями та виправленнями.