Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 2)

У підрозділі «Опис логічної структури» наводиться алгоритм розв'язання задачі, реалізований програмами комплексу; опис методів, що використовуються; структура програмного комплексу в цілому та характеристика кожної програми, яка входить до нього.

У підрозділі «Технічні засоби, що використовувалися» визначається мінімальна конфігурація комплексу технічних засобів, в разі необхідності —потрібні додаткові пристрої, технічні характеристики принтера; вказуються можливі конфігурації технічних засобів, які потрібні для роботи програмного комплексу в різних умовах застосування.

У підрозділі «Виклик та завантаження» визначається спосіб звертання до комплексу (у середовищі СКБД або на рівні операційної системи за допомогою файла настроювання). У разі необхідності описуються файли настроювання, створені для забезпечення функціонування комплексу (наприклад, файли типу «mem» чи «bat»);

вказуються рекомендації щодо відображення у файлі настроювання СКБД (файл config.fx), розміщення командних файлів комплексу та таблиць баз даних у відповідних директоріях системи для прискорення пошуку під час роботи комплексу. У разі необхідності описуються дії щодо настроювання програмного комплексу за умови конкретного застосування (настроювання на можливі конфігурації технічних засобів, генерація робочого варіанта комплексу і зв'язки з вибірковим виконанням окремих функцій чи їх сукупності).

Допускається наведення відомостей про використання оперативної пам'яті та обсягів завантажувальних модулів у кілобайтах.

У підрозділі «Вхідні та вихідні дані» опис виконується по кожній таблиці бази даних із вказівкою змісту відомостей, які в ній зберігаються, джерела її формування (первинний документ, програма, де вона утворюється), призначення, наявність індексного файла з уточненням ключів упорядкування, у разі необхідності — спосіб кодування окремих реквізитів з наведенням системи кодування по тексту або у додатках. Якщо для роботи комплексу треба виконати попередню автономну підготовку вхідних даних (наприклад, створення довідників), то її необхідно описати.

Допускається посилання на опис формату даних у додатку проекту. Під час опису вихідних документів зазначаються: термін видання та користувач інформації; дії, пов'язані з перевіркою правильності одержаних результатів. Зразки документів належить наводити у додатку проект).

У підрозділі «Призначення програми» наводиться стислий опис призначення програмного комплексу та функцій, які він виконує; опис основних характеристик і особливостей комплексу (режим і час роботи, потрібний обсяг пам'яті); обмеження на галузь застосування.

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

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

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

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

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

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

Допускається посилання на зразки форм вхідної та вихідної інформації у додатку проекту. В додаток документа рекомендується включати образи екранів, послідовно сформованих під час роботи з комплексом.

Підрозділ «Опис задачі» містить стислий опис економічної суті задачі та опис реалізованого математичного апарату.

У підрозділі «Вхідні та вихідні дані» опис виконується по кожній таблиці бази даних з вказівкою змісту відомостей, які в ній зберігаються, джерела її формування (первинний документ та програма, де вона утворюється), призначення, наявності індексного файла з уточненням ключів упорядкування, а в разі необхідності — способу кодування окремих реквізитів. Якщо для роботи комплексу має бути виконана попередня автономна підготовка вхідних даних (наприклад, створення довідників), то її необхідно описати.

Допускається посилання на опис формату даних у додатку проекту..

Під час опису вихідних документів вказуються: термін подання та користувач інформації, дії щодо перевірки правильності одержаних результатів. Зразки документів слід наводити у додатку проекту.

Обов'язковим є подання структури та змісту таблиць бази даних, що використовуються в процесі експлуатації комплексу;

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

6. Вказівки щодо оформлення та захисту курсового проекту

Курсовий проект оформляється кожним студентом у вигляді окремого звіту.

Оформлення текстової частини курсового проекту та додатків до нього має відповідати таким вимогам:

1. Текстова частина курсового проекту розташовується на одній сторінці чистого аркуша формату А4 (210*297).Текст на аркуші розміщується таким чином: ліворуч — поле для підшивки не менш як 30 мм, праворуч — 10 мм, знизу — 25 мм та зверху — по 20 мм. У разі необхідності (подання схем великого обсягу) можна використовувати вкладки формату A3 (297*420), якщо скласти їх до формату А4.

2. Титульний аркуш проекту (див. додаток А) повинен бути підписаний студентом та керівником курсового проекту.

3. Кожен документ проекту повинен мати окремий титульний аркуш.

4. Нумерація сторінок у курсовому проекті повинна починатися з другої сторінки і закінчуватися додатками. Номер сторінки ставиться у верхньому правому куті. Нумерація — наскрізна (титульні аркуші документів рахуються, але не нумеруються).

5. Зміст проекту розміщується після титульного аркуша проекту на окремій сторінці із заголовком «Зміст». У зміст включають документи, розділи, їх найменування та номери сторінок, з яких вони починаються. Найменування документів і розділів курсового проекту повинно відповідати змісту тексту. При наявності у проекті додатків у змісті для кожного з них наводиться номер, назва та номер сторінки, з якого він починається.

6. Графічна частина виконується на аркушах ватману або слайдах. В графічну частину рекомендується включити інформаційну модель, схему зовнішніх функцій та структурну модель програмного комплексу.

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

1. Демонстрація експлуатаційних можливостей програмного комплексу (виконується розробником у присутності членів комісії). Виявлені недоліки фіксуються у протоколі.

2. Доповідь з основних положень курсового проекту (10—15 хвилин). У доповіді повинно бути визначено: об'єкт розробки, галузь застосування програмного комплексу; обґрунтовано прийняті проектні рішення та проаналізовано одержані результати; зроблено пояснення щодо усунення дефектів, знайдених на всіх стадіях проектування.

Під час підготовки відповідей на запитання, поставлені членами комісії, студенту дозволяється користуватися тезами доповіді, графічним та ілюстративним матеріалом, текстовою частиною проекту.

3. Оцінка якості оформлення курсового проекту членами комісії.

4. Аналіз курсового проектування та винесення рішення про оцінку проекту проводиться на закритому засіданні комісії. Основні критерії оцінки проекту такі:

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

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

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

• своєчасність виконання графіка робіт при проектуванні та поданні курсового проекту.

7. Приклад курсової роботи. Розробка системи обробки інформації в податковій сфері

Діаграми потоків даних (DFD) є основним засобом моделювання функціональних вимог до проектованої системи. З їх допомогою ці вимоги представляються у вигляді ієрархії функціональних компонентів (процесів), зв'язаних потоками даних. Головна мета такого уявлення - продемонструвати, як кожний процес перетворить свої вхідні дані у вихідні, а також виявити відносини між цими процесами.

Для побудови DFD традиційно використовуються дві різні нотації, відповідні методам Йордану і Гейна -Сэрсона. Ці нотації трохи відрізняються один від одного графічним зображенням символів. Відповідно до даних методів модель системи визначається як ієрархія діаграм потоків даних, що описують асинхронний процес перетворення інформації від її введення в систему до видачі користувачу. Діаграми верхніх рівнів ієрархії (контекстні діаграми) визначають основні процеси або підсистеми із зовнішніми входами і виходами. Вони деталізують за допомогою діаграм нижнього рівня. Така декомпозиція продовжується, створюючи багаторівневу ієрархію діаграм, до тих пір, поки не буде досягнутий рівень декомпозиції, на якому процеси стають елементарними і деталізувати їх далі неможливо.

Основними компонентами діаграм потоків даних є:

• зовнішні єства; системи і підсистеми; процеси; накопичувачі даних;

• потоки даних.

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

Першим кроком при побудові ієрархії DFD є побудова контекстних діаграм. Звичайно при проектуванні щодо простих систем будується єдина контекстна діаграма із зіркоподібною топологією, в центрі якій знаходиться так званий головний процес, сполучений з приймачами і джерелами інформації, за допомогою яких з системою взаємодіють користувачі і інші зовнішні системи. Перед побудовою контекстної DFD необхідно проаналізувати зовнішні події (зовнішні єства), що роблять вплив на функціонування системи. Кількість потоків на контекстній діаграмі повинна бути по можливості невеликою, оскільки кожний з них може бути надалі розбитий на декілька потоків, на наступних рівнях діаграми.

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

Для складних систем будується ієрархія контекстних діаграм. При цьому контекстна діаграма верхнього рівня містить не єдиний (головний) процес, а набір підсистем, сполучених потоками даних. Контекстні діаграми наступного рівня деталізують контекст і структуру підсистем.

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

• наявність у процесу щодо невеликої кількості вхідних і вихідних потоків даних (2-3 потоки);

• можливості опису перетворення даних процесом у вигляді послідовного алгоритму;

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

• можливості опису логіки процесу за допомогою специфікації невеликого

• об'єму (не більше 20 - 30 рядків).

• Специфікації повинні задовольняти наступним вимогам:

• для кожного процесу нижнього рівня повинна існувати одна тільки одна специфікація;

• специфікація повинна визначати спосіб перетворення вхідних потоків у вихідні;

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

• специфікація повинна прагнути обмеження надмірності;

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

Фактично специфікації є описами алгоритмів задач, виконуваних процесами. Специфікації містять номер або ім'я процесу, списки вхідних і вихідних даних і тіло (опис) процесу, що є специфікацією алгоритму або операції, що трансформує вхідні потоки даних у вихідні. Відома велика кількість різноманітних методів, що дозволяють описати тіло процесу. Відповідні цим методам мови можуть варіюватися від структурованої природної мови або псевдокоду до візуальних мов проектування.

Характеристики

Список файлов книги