8 Орієнтовний перерлік тем до виконання

За допомогою CASE-засоби ВРwin розробити ієрархічні моделі наступних предметних областей:

1) АІС "Бібліотечний каталог";

2) АІС "Відділ кадрів університету";

3) АІС "Студенти університету";

4) АІС деканату факультету;

5) АІС "Розклад занять викладачів кафедри та графік прийняття академзаборгованостей";

6) АІС "Розклад занять студентів університету";

7) АІС "Результати екзаменаційної сесії студентів";

8) АІС "Оплата послуг телефонної мережі";

9) АІС "Гуртожиток;

10) АІС загальноосвітньої школи;

11) АІС "Результати екзаменаційних сесій студента за весь період навчання;

12) АІС профкому організації;

13) АІС обліку матеріальних цінностей (склад);

14) АІС ріелторської компанії;

15) АІС "Магазини міста";

16) АІС "Громадський транспорт міста";

17) АІС "Клінічні лікарні міста";

18) АІС "Підприємства міста";

19) АІС "Довідкова служба аптек";

21) АІС "Довідкова служби поліклініки";

22) АІС "Довідкова служба послуг";

23) АІС "Бронювання квитків на залізничному транспорті";

24) АІС "Будинкоуправління";

25) АІС "Бухгалтерія підприємства".

Додаток 1 - Титульний лист пояснювальної записки

МІНІСТЕРСТВО ОСВІТИ і НАУКИ молоді та спорту УКРАЇНИ

ЧЕРКАСЬКИЙ ДЕРЖАВНИЙ ТЕХНОЛОГІЧНИЙ УНІВЕРСИТЕТ

Факультет інформаційних технологій і систем

Кафедра програмного забезпечення автоматизованих систем

Курсова робота

РОЗРОБКА ІЄРАРХІЧНОЇ ФУНКЦІОНАЛЬНОЇ МОДЕЛІ

"НАВЧАННЯ СТУДЕНТІВ УНІВЕРСИТЕТУ"

ЧДТУ.137170.007 ПЗ

Пояснювальна записка

Виконавець: студент групи ПЗ-904

Михайленко Д. М.

Перевірив: ст. викладач

Плакасова Ж. М.

Дата «___»____________, 201 _ р.

Оцінка «___________________»

Черкаси, 2013

Д одаток 2 - Зразок оформлення змісту (2-й лист у записці)

Зміст

Технічне завдання (стандартний лист с. 2) – ПЕРЕД ЗМІСТОМ

Анотація – перед змістом

Вступ ………..………………………………………………………………….....…………3

1. Формальне визначення моделі в IDEF0.. ……….…………...……..……….5

   1. SADT-моделі………………………………………………………….………...............5

   2. Модель відповідає на питання.………………………………………………..………6

   3. Модель має єдиний суб’єкт……………………………………………….…………..7

   4. У моделі може бути тільки одна точка зору.………………………….…………......7

   5. Моделі як взаємопов’язані набори діаграм...………………………….…………….8

   6. Резюме…………………………………..……………………………….…...................9

2. Правила заповнення поля "КОНТЕКСТ" IDEF0-діаграми…….…..…....12

3. Опис предметної області.………………………………………………...…….13

4. Створення моделі в стандарті IDEF0……………………….….…………....20

Висновки……….………………………………………………………………..….……..23

СПИСОК використаних джерел …….. ...………….…………………...................24

Додаток А Специфікація ………………………………………………………..….……25

Додаток Б РЕЗУЛЬТАТИроботи ……. …………………………………..…………27

Додаток В ЗВІТИ …… ………………………………..…………………………….…..36

Додаток 3 - Зразок оформлення ВСТУПУ

Вступ

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

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

У 80-ті роки розроблено ряд методів структурного проектування програм, спеціально призначених для використання на ранніх етапах процесу розробки складних систем широкого профілю і дозволяють істотно скоротити можливості внесення помилок у систему, що розробляється. Найбільш відомими і широко використовуваними з даних методів є:

• метод структурного аналізу і проектування SADT Роса;

• методи, орієнтовані на потоки даних (методи йоду, Демарк, Гейна, Сарсона);

• методи структурування даних (методи Джексона-Уорнера, Орра, Чена).

Поява нових методів проектування поставило завдання створення програмного забезпечення (ПЗ), що дозволяє автоматизувати їх використання при проектуванні великих систем. До середини 80-х років сформувався ринок програмних засобів, названих CASE-системами.

Спочатку термін CASE трактувався як Computer Aided Software Engineering (комп'ютерна підтримка проектування ПЗ). В даний час даному терміну надається більш широкий зміст і він розшифровується як Computer Aided System Engineering (комп'ютерна підтримка проектування систем), а сучасні CASE-засоби орієнтуються на створення специфікацій, проектування і моделювання складних систем широкого призначення. Найбільш перспективні CASE-продукти базуються на припущенні, що програмна система - це окремий випадок

3