Створення програмного продукту

Міністерство освіти і науки України Кіровоградський кооперативний коледж економіки і права імені М. П. Сая Циклова комісія комп’ютерних технологій Практичні роботи Тема: «Створення програмного продукту»

Керівник: к.т.н.

С.В. Сорокун Виконавець:

студент гр. РПЗ-46

Фіофілатов Євген Кіровоград, 2013р.

Тема. Аналіз проблеми Мета: сформувати навики роботи з реальним замовником програмних систем, навчитися ідентифікувати зацікавлених осіб та проводити інтерв'ю з ними, навчитися розробляти анкети для опиту зацікавлених осіб, навчатися виконувати аналіз предметної області для розробки програмного забезпечення.

Анкета для опиту зацікавлених осіб

Перелік питань для інтерв'ю

1) Які вимоги до бази даних повинні бути в наявності?

— Надійність;

— змістове наповнення;

— реляційна модель;

— швидкий пошук;

— сортування даних.

2) Які програмні вимоги повинні бути до бази даних?

База даних повинна працювати під управлінням сімейства операційних систем Windows. Повинен бути встановлений Microsoft Office Access починаючи з версії 2003 і закінчуючи 2013 (pro).

3) Які можуть бути не бажані ситуації?

Програмний засіб не буде функціонувати (або буде функціонувати некоректно) в наступних випадках:

* Якщо відключений комп’ютер.

* Відсутній компакт-диск (не буде можливості встановити базу даних).

* Якщо пошкоджений носій (диск).

4) у чому полягає специфікація якості?

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

* Завершеність — база даних містить всю необхідну інформацію для роботи.

надійність:

* Завершеність — база даних містить всю необхідну інформацію для роботи оператора ЕОМ.

5) додатки згідно вимог?

* Діаграма прецедентів

* Діаграма класів Тема заняття. Постановка задачі

Мета: провести аналіз з отриманого матеріалу в практичній роботі № 1, сформувати проблеми, її актуальність та потреби зацікавлених осіб. Сформувати постановку задачі для розробки програмного забезпечення.

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

Інтерв'ю з представником компанії

Постановка завдання

1.1 Підстави для проведення розробки: завдання викладача, від 18.11.2013р.

1.2 Найменування та умовне позначення розробки: «БД Облік порушень ПДР». Microsoft Access 2003

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

Програмний продукт вимагає наступні технічні конфігурації ПК:

Типи підтримуваних операційних систем:

* Всі сімейства Windows,

* Процесор тактовою частотою: 1,6 ГГц

* Обсяг оперативної пам’яті: 128 Mb

* Місце на жорсткому диску об'ємом: 512 Mb.

* Також необхідна наявність таких пристроїв:

монітор, системний блок, миша, клавіатура.

Програмна документація поставляється в друкованому вигляді.

* Технічне завдання

* Функціональна специфікація

* Специфікація якості

* Дослідницький розділ

* Технологічний розділ

* Розділ випробування програмного продукту

* Економічний розділ Згідно вимог замовника:

Вимоги до функціональних характеристик:

Склад виконуваних функцій:

* Запуск бази

* Для кожного порушення фіксується і зберігається дата, час

* Для кожного порушення фіксується і зберігається вид порушення

* Для кожного порушення фіксується і зберігається розмір штрафу

* При оплаті всіх штрафів машина видаляється з бази

* Закриття бази Організація вхідних даних Організація вихідних даних База даних повинна працювати під управлінням сімейства операційних систем Windows,. Повинен бути встановлений Microsoft Office Access 2003 або більш новішої версії.

Тема заняття. Технічне завдання: загальні відомості

Мета: сформувати навички розробки та оформлення технічного завдання на розробку автоматизованих систем відповідно до ДСТУ 34.602−89 на стадії - загальні відомості.

Завдання: розробити розділ технічного завдання: загальні відомості.

Календарний план роботи

Найменування системи.

Повне найменування системи — «БД Облік порушень ПДР» .

Відомості про замовника та виконавця Замовник системи — Віктор Федорович Янікевич Виконавець — Фіофілатов Євген Підстави для виконання робіт, терміни і фінансування.

Розробка ведеться на підставі договору № 1 від 18.11.2013, заключного між Компанією «Регігони» і Фіофілатовим Євгеном.

Система повинна бути розроблена протягом 3 робочих тижнів і здана в експлуатацію до 09.12.2013.

Роботи зі створення системи фінансуються компанією.

Порядок контролю Види випробувань: проект має бути зданий керівнику проекту до 09.12.2013р. Замовник перевіряє якість виконання проекту протягом 5 днів. Розробник зобов’язується усунути всі помилки протягом трьох днів.

Загальні вимоги до прийому роботи Після усунення зауважень розробник захищає проект і здає в експлуатацію не пізніше 13.12.2013

Інформаційні об'єкти Таблиці: База даних «Облік порушень ПДР» складається з 3 таблиць: «Власник», «Автомобіль», «Порушення», які містять текстову інформацію; 2 запити: «Запит на видалення», «Запит боржникі»; 1 звіту «власник «.

Визначення функцій програмного продукту База даних «Облік порушень ПДР» призначена для введення, зберігання інформації; збору і фіксації видів порушень, розмір штрафів і виведення їх на друк або екран комп’ютера.

Тема заняття. Технічне завдання: призначення мети та створення (розвитку) системи Мета: сформувати навички розробки та оформлення технічного завдання на розробку автоматизованих систем відповідно до ДСТУ 34.602−89 на стадії - призначення мети та створення (розвитку) системи.

Завдання: розробити розділ технічного завдання: призначення мети та створення (розробка) системи.

Мета створення системи Метою роботи є створення бази даних «Облік порушень ПДР» зі зручним для користувача інтерфейсом.

Для досягнення мети були поставлені завдання:

* Вивчити літературу по заданій темі

* Оформити технічне завдання

* Обґрунтувати вибір середовища проектування

* Розробити структуру бази даних

* Описати архітектуру бази даних

* Виконати тестування і налагодження

* Розробити документації для користувача

* Виконати розрахунок економічних показників Призначення системи

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

надійності:

* Автономність — база даних буде функціонувати тільки за наявності MS Access ;

* Точність — у базі даних точно виконуються всі звіти і запити ;

* Стійкість — при введенні неправильних вхідних даних база даних буде коректно функціонувати, виводячи повідомлення про невірно введених даних;

* Захищеність — можливо випадково або навмисно видалити інформацію з бази даних.

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

* Інформативність — інформація в базі даних міститься в повній мірі ;

* Комунікабельність — інформація легко сприймається ;

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

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

* Ресурсо-спроможна — необхідно 256 МБ оперативної пам’яті для хорошої і швидкої роботи бази даних.

* модифікуватися — можна змінити вміст таблиць, звітів і запитів ;

* вивчаєма — легко досліджуваний програмний скрипт.

Завдання, які вирішуються системою бази даних

* запуск бази;

* для кожного запиту фіксується і зберігається дата, час;

* для кожного запиту фіксується і зберігається вид порушення;

* для кожного запиту фіксується і зберігається розмір штрафу;

* при оплаті всіх штрафів машина видаляється з бази;

* закриття бази шляхом запитів.

Тема заняття. Технічне завдання: характеристика об'єкта автоматизації

Мета: сформувати навички розробки та оформлення технічного завдання на розробку автоматизованих систем відповідно до ДСТУ 34.602−89 на стадії - характеристика об'єкта автоматизації.

Завдання: розробити розділ технічного завдання: характеристика об'єкта автоматизації, визначити виконавців та замовників, їх взаємодію, умови роботи.

Організація і планування науково-дослідної та інноваційної діяльності

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

Бази даних створюються спеціально для зберігання, обробки, проведення розрахунків, сортування, вибірки та подання будь-яких масивів даних за будь-якими критеріями.

Облік і звітність з науково-дослідних робіт Опис зовнішнього інформаційного середовища

* Канали введення: CD-ROM, т.я. база даних «Облік порушень ПДР» знаходиться на магнітному носії інформації;.

* Канали виведення: монітор та принтер.

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

* прайс-листи;

* інформація про клієнтів / замовників;

* каталог товарів / послуг;

* звіти персоналу;

* рух товарів;

* статистична і будь-яка інша інформація, що виходить за рамки двох рядків.

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

Іншим серйозним обмеженням реляційних систем є їх відносно слабкі можливості по частині подання семантики програми. Найбільше, що забезпечують реляційні СУБД, — це можливість формулювання та підтримки обмежень цілісності даних. Після проектування реляційної бази даних багато знань проектувальника залишаються зафіксованими в кращому випадку на папері через відсутність в системі відповідних виразних засобів.

Усвідомлюючи ці обмеження і недоліки реляційних систем, дослідники в області баз даних виконують численні проекти, засновані на ідеях, що виходять за межі реляційної моделі даних. По всій видимості, яка-небудь з цих робіт стане основою систем баз даних майбутнього. Слід зауважити, що тематика сучасних досліджень, що відносяться до баз даних, виключно широка. Отже зробимо висновок з вище сказаного і зупинимося на реляційній «Базі Даних» котру ми і будемо розробляти на протязі відведеного періоду часу.

Тема заняття. Технічне завдання: вимоги до системи Мета: сформувати навички розробки та оформлення технічного завдання на розробку автоматизованих систем відповідно до ДСТУ 34.602−89 на стадії - вимоги до системи.

Завдання: розробити розділ технічного завдання: вимоги до системи, відповідно до ДСТУ 34.602−89.

Вимоги до експлуатації

Кліматичні умови експлуатації:

— в холодну пору року в приміщенні повинна бути 21−25 С, а в теплу23−25 С. Вологість повітря від 40% до 60%.

— вимоги до видів обслуговування: адміністратор бази даних

— вимоги до кваліфікації користувача: оператор ЕОМ.

Технічні параметри Програмний продукт вимагає наступної технічної конфігурації ПК.

Типи підтримуваних операційних систем:

* Всі сімейства Windows,

* Процесор частотою: 1,6 ГГц

* Обсяг оперативної пам’яті: 256 Mb

* Місце на жорсткому диску об'ємом: 512 Mb.

Програмні вимоги База даних повинна працювати під управлінням сімейства операційних систем Windows,. Повинен бути встановлений Microsoft Office Access 2003.

Вимоги до програмної документації

Програмна документація поставляється в друкованому вигляді.

* Технічне завдання

* Функціональна специфікація

* Специфікація якості

* Дослідницький розділ

* Технологічний розділ

* Розділ випробування програмного продукту

* Економічний розділ Техніко-економічні показники Дана база даних дозволяє скоротити час на пошук потрібної інформації, ведення обліку та звітності.

Технічні характеристики персонального комп’ютера на якому ведеться розробка «Бази Даних»:

* сімейство Windows vista (home premium)

* Процесор: AMD FX-4100 3.6GHz/8MB/2000MHz (FD4100WMGUSBX) sAM3

* Обсяг оперативної пам’яті: 8096 Mb ddr3

* Відеокарта GeForce Gt 9800 (512 mb)

Тема заняття. Технічне завдання: склад та зміст створення (розвитку) системи Мета: сформувати навички розробки та оформлення технічного завдання на розробку автоматизованих систем відповідно до ДСТУ 34.602−89 на стадії - склад та зміст створення (розвитку) системи.

Завдання: розробити розділ технічного завдання: склад та зміст створення (розвитку) системи, відповідно до ДСТУ 34.602−89.

Завдання, які вирішуються системою «Баз Даних»

База даних дозволяє:

— Використання збережених процедур;

— редагування існуючих даних;

— вибірка даних;

— формувати звіти на підставі вже існуючих;

Призначення системи Бази даних використовувалися в обчислювальній техніці з незапам’ятних часів. У перших комп’ютерах використовувалися два види зовнішніх пристроїв — магнітні стрічки і магнітні барабани. Ємність магнітних стрічок була достатньо велика. Пристрої для читання-запису магнітних стрічок забезпечували послідовний доступ до даних. Для читання інформації, яка знаходилася в середині або наприкінці магнітної стрічки, необхідно було спочатку прочитати всю попередню ділянку. Наслідком цього була надзвичайно низька продуктивність операцій введення-виведення даних в зовнішню пам’ять. Магнітні барабани давали можливість довільного доступу, але мали обмежений об'єм інформації. Зрозуміло, говорити про якусь систему управління даними у зовнішній пам’яті, в той момент не доводилося. Кожна прикладна програма, якою потрібно було зберігати дані в зовнішній пам’яті, сама визначала розташування кожного блоку на магнітній стрічці. Прикладна програма також брала на себе функції інформаційного обміну між оперативною пам’яттю і пристроями зовнішньої пам’яті за допомогою програмно-апаратних засобів низького рівня. Такий режим роботи не дозволяє або дуже утрудняє підтримку на одному носії декількох архівів довго зберігається. Крім того, кожній прикладній програмі доводилося вирішувати проблеми іменування частин даних і структуризації в зовнішній пам’яті. Історія БД фактично почалася з появою магнітних дисків. Такі пристрої зовнішньої пам’яті володіли істотно більшою ємністю, ніж магнітна стрічка і барабани, а також забезпечували у багато разів більшу швидкість доступу в режимі довільної вибірки. На відміну від сучасних систем управління, які можуть застосовуватися для самих різних баз даних, переважна більшість раніше розроблених СУБД були тісно пов’язані з користувацькою базою для того, щоб збільшити швидкість роботи, хоч і на шкоду гнучкості. Спочатку СУБД застосовувалися тільки у великих організаціях з потужною апаратною підтримкою, необхідної для роботи з великими обсягами даних. Сучасні автори часто вживають терміни «банк даних» і «база даних» як синоніми, проте в загальногалузевих керівних матеріалах щодо створення банків даних Державного комітету з науки і техніки (ДКНТ), виданих у 1982 р., ці поняття розрізняються.Банк даних (БнД) — це система спеціальним чином організованих даних — баз даних, програмних, технічних, мовних, організаційно — методичних засобів, призначених для забезпечення централізованого накопичення та колективного багатоцільового використання даних. База даних (БД) — іменована сукупність даних, що відображає стан об'єктів та їх відносин у розглянутій предметній області.

Тема заняття. Технічне завдання: порядок контролю та прийняття системи Мета: сформувати навички розробки та оформлення технічного завдання на розробку програмного продукту відповідно до ДСТУ 34.602−89 на стадії - порядок контролю та прийняття системи.

З допомогою Access я можу контролювати майже всі дії «Бази Даних» при цьому використовуючи:

Можливості DDE і OLE. За допомогою DDE (Dynamic Data Exchange — динамічний обмін даними) і OLE (Object Linking and Embedding — зв’язування і впровадження об'єктів) у форми і звіти Access можна додавати нові об'єкти. Такими об'єктами можуть бути звук, малюнки, діаграми і навіть відеокліпи. Можна впроваджувати об'єкти OLE (наприклад, растрові зображення) або документи текстових процесорів (Word або WordPerfect) або встановлювати зв’язки з електронними таблицями Excel. Пов’язуючи ці об'єкти зі своєю базою даних, я зможу створювати динамічні форми і звіти, а також використовувати одну й ту ж інформацію в різних додатках Windows. У Access повною мірою реалізовано управління реляційними базами даних. Система підтримує первинні та зовнішні ключі і забезпечує цілісність даних на рівні ядра (що запобігає несумісній операції оновлення або видалення даних). Крім того, таблиці в Access забезпечені засобами перевірки допустимості даних, що запобігають некоректний введення незалежно від того, як він здійснюється, а кожне поле таблиці має свій формат і стандартні описи, що істотно полегшує введення даних. Access підтримує всі необхідні типи полів, у тому числі текстовий, числовий, лічильник, грошовий, дата / час, MEMO, логічний, гіперпосилання і поля об'єктів OLE. Якщо в процесі спеціальної обробки в полях не виявляється ніяких значень, система забезпечує повну підтримку порожніх значень. Реляційна обробка даних в Access за рахунок гнучкої архітектури системи здатна задовольнити будь-які потреби. При цьому Access може використовуватися як автономна СУБД в режимі файл-сервера або клієнтського компонента таких продуктів, какSQL Server. Крім того. Access підтримує протокол ODBC (Open Database Connectivity), що дозволяє підключатися до баз даних безлічі різних форматів, таких як SQL Server, Oracle, Sybase і навіть DB / 2 для великих ЕОМ фірми IBM.

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

Імпортування, експортування і зв’язування зовнішніх файлів. Access дозволяє імпортувати та експортувати файли багатьох відомих форматів, включаючи dBASE, FoxPro, Excel, SQL Server, Oracle, Btrieve, багато текстові формати ASCII (у тому числі з фіксованою довжиною рядка або заданим обмежувачем), а також дані у форматі HTML. У результаті імпортування створюється таблиця Access; в результаті експортування табліциAccess створюється файл у заданому форматі.

Зв’язування (раніше йменувалося приєднанням) означає, що можна використовувати зовнішні дані без створення таблиць Access. Можна встановлювати подібний зв’язок з даними dBASE, FoxPro, Excel, ASCII і SQL. Дуже потужна можливість — зв’язування таблиць Access з їхніми зовнішніми таблицями з наступним спільним використанням; це відноситься до таблиць Access, dBASE, FoxPro і SQL Server.

Форми і звіти. Вікна конструкторів форм і звітів мають однаковий інтерфейс і надають користувачеві багато можливостей. Форма або звіт конструюється за принципом WYSIWYG (What You See Is What You Get — що бачиш, те й отримаєш). Додаючи черговий елемент управління, я зможу побачити, як при цьому змінюється створювана форма.

Дайте відповіді на питання:

1. Основні етапи розвитку технології розробки.

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

Другий етап (70−80-і роки XX ст.) характерний розробленням програмних продуктів відповідно до концепцій MRP і MRP II:

MRP (Material Requirements Planning) — планування потреби в матеріалах.

MRPII (Manufactory Resource Planning) — планування ресурсів підприємства.

2. Вказівки послідовності виконання технологічних операцій.

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

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

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

комплектувальна карта — це технологічний документ, що містить дані про деталі, складальні одиниці та матеріали, що входять до комплекту виробу.

3. Структурний підхід до програмування.

Базовими принципами структурного підходу є:

принцип «поділяй і пануй» ;

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

Основними з цих принципів є:

абстрагування — виділення суттєвих аспектів системи;

несуперечності - обґрунтованість і погодженість елементів системи;

структурування даних — дані мають бути структуро-вані й ієрархічно організовані.

4. Об'єктний підхід до програмування.

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

Тема заняття. Стадія «Ескізний проект»

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

Розробка документу за стандартом «ЄСКД»

1) Технічні характеристики (показники якості)

Програмний продукт вимагає наступної технічної конфігурації ПК. Типи підтримуваних операційних систем:

* Всі сімейства Windows

* Процесор частотою: 1.6 Ghz

* Обсяг оперативної пам’яті: 256 Mb

* Місце на жорсткому диску об'ємом: 512 Mb.

* Також необхідна наявність таких пристроїв:монітор, системний блок, миша.

2) Спеціальні вимоги Для забезпечення надійності необхідно встановити захист від зміни даних в базі і її технічних елементів.

3) Макет створення ключового поля в Microsoft Access 2003

4) Технічні вимоги до виробу і матеріалів База даних поставляється на CD — диску. Його треба берегти від впливу магнітних полів, прямих сонячних променів, попадання вологи і від фізичних ушкоджень Тема заняття. Стадія «Технічний проект»

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

Завдання: розробити технічний проект програмного продукту, що вами розробляється Документ на виріб (ЄСКД) за технічним проектом Створення архітектури бази даних

* Архітектура програмного засобу є шаруватої, так як :

* Для роботи бази даних необхідно додаток MS Access (міститься в пакеті прикладних програм MS Office). Для програми MS Access необхідна операційна система Windows 95 і старше;

* На кожному шарі нічого невідомо про властивості наступних шарів ;

* Кожен шар може взаємодіяти з безпосередньо попереднім шаром тільки через певний інтерфейс;

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

Рисунок. Схема архітектури програмного засобу

* Архітектура бази даних є комплекс автономно-виконуваних програм.

Технологія створення Бази даних «Облік порушень ПДР»

* База даних створена в середовищі Microsoft Access 2003;

* Запустити Microsoft Office Access 2003, команда: Пуск / Microsoft Office Access 2003, покажу на прикладі рисунку:

Рис. 10.2. Запуск Microsoft Office Access 2003

Створення таблиць

* Створити таблицю «Власник» в режимі конструктор, для цього потрібно відкрити подвійним клацанням миші пункт «Створення таблиць в режимі конструктора» (див. рис. 10.3);

Рис. 10.3. Створення таблиць в режимі конструктора

Дайте відповідь на питання:

1. Еволюція моделей життєвого циклу програмного забезпечення.

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

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

Тема заняття. Розробка структурної схеми програмного продукту Мета: навчитися будувати структурну схему програмного забезпечення.

Завдання: побудувати структурну схему розробляємого вами програмного продукту.

Тема заняття. Розробка функціональної схеми програмного продукту Мета: навчитися будувати функціональну схему програмного забезпечення.

Завдання: побудувати структурну схему розробляємого Вами програмого продукту.

Дайте відповіді на питання:

1. Системи менеджменту якості.

В умовах ринкової економіки успішна діяльність будь-якої компанії можлива лише в тому випадку, коли вироблені нею продукція/послуги:

· відповідають чітко визначеним потребам, середовищу застосування і призначення;

· мають необхідні споживчі властивості;

· відповідають діючим (прийнятим, погодженим) нормативним документам;

· відповідають чинному законодавству та іншим вимогам суспільства;

· пропонуються покупцеві за конкурентноспроможними цінами;

· обумовлюють одержання прибутку.

2.Основні положення та словник.

ISO 9000 описує основні положення систем управління якістю та визначає термінологію стосовно систем управління якістю.

ISO 9001 установлює вимоги до системи управління якістю для випадків, коли організація має продемонструвати свою спроможність поставляти продукцію, що відповідає вимогам замовників і застосовних регламентів, а також прагне підвищувати задоволеність замовників.

ISO 9004 подає настанови щодо результативності та ефективності системи управління якістю. Призначеність цього стандарту — поліпшувати показники діяльності організації, а також задоволеність замовників та інших зацікавлених сторін.

3. Інформаційна технологія.

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

4. Процеси життєвого циклу програмних середовищ

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

Спіральна модель — Розробка ітераціями відображає об'єктивно існуючий спіральний цикл створення системи. Неповне завершення робіт на кожному етапі дозволяє переходити на наступний етап, не чекаючи повного завершення роботи на поточному. При ітеративному способі розробки відсутню роботу можна буде виконати на наступній ітерації. Головне ж завдання — що найшвидше показати користувачам системи працездатний продукт, тим самим активізуючи процес уточнення і доповнення вимог.

Тема заняття. Розробка блок-схеми підпрограм програмного продукту Мета: навчитися будувати алгоритми до розробляємих підпрограм програмного продукту.

Завдання: розробити блок-схему алгоритму підпрограм програмного продукту.

Рис. 13.1. Блок-схема підпрограми «Облік порушень»

Тема заняття. Розробка блок-схеми програмного продукту Мета: навчитися будувати блок-схему реалізації програмного продукту, що розробляється.

Завдання: розробити блок-схему алгоритму підпрограм програмного продукту.

Рис. 14.1. Блок-схема «Облік порушень»

Тема заняття. Розробка інтерфейсу програмного продукту Мета: навчитися розробляти інтерфейс програмного продукту Завдання: розробити інтерфейс програмного продукту.

Таблиця 15.1. Опис вихідних даних

* Додаємо таблицю «Порушення» і натискаємо «Додати»

Рис. 15.2. Додавання таблиці порушення

· Створюємо запит на видалення Рис. 15.3. Створення запиту на видалення

* Додаємо поле «Оплата» і умова відбору «оплачено»

Рис. 15.4. додавання поля «ОПЛАТА», і умову вибірки «ОПЛАЧЕНО»

· Зберігаємо «Запит на видалення»

Рис. 15.5. збереження запиту

* Створюємо запит «Не сплачені» в режимі конструктора (див. рис.9)

* Додаємо поля: Прізвище, Ім'я, По батькові з таблиці «Власник», Номер автомобіля, Марка з таблиці «Автомобіль», Дата порушення, Розмір штрафу, Сплатити до, Оплата з таблиці «Порушення» і зберігаємо запит.

Рис. 15.6. створення запиту на вибірку Тема заняття. Розробка підпрограм програмного продукту Мета: навчитися будувати підпрограми програмного продукту, що розробляється Завдання: розробити підпрограми програмного продукту.

Створюємо форми:

* Створюємо форму «Власник «в режимі майстра форм;

* вибрати поля для форми «Власник «;

* вибираємо вид представлення даних і натискаємо «Далі «;

* вибираємо зовнішній вигляд підпорядкованої форми і натискаємо «Далі «;

* вибираємо стиль форми і натискаємо «Далі «;

* задаємо ім'я форми «Власник «і натискаємо «Готово «;

Створюємо макроси:

* Створюємо макрос «Запит на видалення «в режимі конструктора;

* створюємо макрос «Запит не оплачені «в режимі конструктора;

* створюємо макрос «Звіт власник» в режимі конструктора;

* створюємо макрос «Форма власник» в режимі конструктора;

* створюємо головну кнопкову форму, виконуємо наступні команди Сервіс / Службові програми / Диспетчер кнопкових форм;

* створюємо кнопкову форму і натискаємо «Так» ;

* створюємо сторінки кнопкової форми;

* відкриваємо кнопкову форму, задати елементи даної кнопкової форми;

* відкриваємо і задаємо елементи кнопкової форми «робота з формою» ;

* задати автоматичний запуск кнопкової форми, виконати команду сервіс / параметри запуску;

* відкрити головну кнопкову форму в режимі конструктора і виконати форматування і додай малюнок;

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

Завдання: виконати функціональне тестування підпрограм програмного продукту

Таблиця 18.1 «Власник»

Рис. 18.2. Створення полів і типів даних Таблиця 18.3. «Автомобіль»

Рис. 18.4. Створення полів і типів даних Таблиця 18.5. «Порушення»

Рис. 18.6. Створення полів і типів даних Тема заняття. Відлагодження підпрограм програмного продукту Мета: навчитися виконувати відлагодження підпрограм програмного продукту.

Завдання: виконати відлагодження підпрограм програмного продукту Створення звітів

* Створити звіт «Звіт Власник» за допомогою майстра, для цього потрібно відкрити подвійним клацанням миші пункт «Створення звіту за допомогою майстра»

Рис. 19.1. Створення звіту з допомогою майстра У вікні створення звітів вибрати Запит: «Не сплачені»

Рис. 19.2. створення звіту власник

* Додати рівні групування, потім натиснути кнопку Далі

Тема заняття. Симбіоз підпрограм в блок — програмний продукт Мета: навчитися виконувати симбіоз (злиття, об'єднання) підпрограм програмного продукту в єдиний програмний блок.

Завдання: виконати симбіоз розроблених підпрограм в програмний проект.

Створивши і об'єднавши відношення виконаємо симбіоз: створимо зв’язки між відношеннями, виділимо власника і об'єднаємо в таблиці котрі будуть залежати один від одної

Тема заняття. Тестування програмного продукту Мета: навчитися виконувати тестування програмного продукту.

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

* Відкрити базу даних «Облік порушень ПДР «.

* Переконатися в наявності Головною кнопкової форми, картинки на формі.

* Переконатися в наявності і правильність роботи кнопок переходу на об'єкти в головній кнопкової формі :

Робота з формами ;

Робота з запитами ;

Робота з звітами ;

Вийти з бази даних;

Перехід на головну кнопкову форму.

* Перевірити вірність роботи макросів, які відкривають Форми.

* Перевірити вірність роботи макросів, які відкривають Запити.

* Перевірити вірність роботи макросів, які відкривають Звіти.

* Переконатися в наявності підлеглою і правильності роботи форми «Власник «.

* Переконатися в наявності і перевірити, як формуються запити:

Запит, на видалення ;

Запит, на вибірку не оплачених власників.

* Переконатися в наявності і перевірити, як формуються звіти :

Звіт на підставі запиту про вибір всіх не оплачених власників ;

* Переконатися в наявності таблиці «Власник «і відповідно типів даних із завданням:

Код Власника — текстовий ;

Прізвище — текстовий ;

Ім'я — текстовий ;

По батькові - текстовий ;

Номер Паспорти — числовий ;

Номер посвідчення — числовий ;

Рік народження — Дата / Час.

* Переконатися в наявності таблиці «Автомобіль» та відповідно типів даних із завданням:

Код Автомобіля — текстовий ;

Код власника — текстовий ;

Код Порушення — текстовий ;

Номер автомобіля — текстовий ;

Марка — текстовий.

* Переконатися в наявності таблиці «Порушення «і відповідно типів даних із завданням:

Код Порушення — текстовий ;

Дата порушення — дата / час ;

Час порушення — текстовий ;

Вид порушення — текстовий ;

Розмір штрафу — грошовий ;

Сплатити до — дата / час ;

Оплата — текстовий.

Перевірити схему даних

Таблиця 21.1. Текстові дані таблиці «Власник» .

§ Таблиця «Авто»

Таблиця 21.2. Текстові дані таблиці «Автомобіль» .

Таблиця 21.3. Текстові дані таблиці «Порушення» .

Тема заняття. Відлагодження програмного продукту Мета: навчитися виконувати відлагодження програмного продукту.

Завдання: виконати відлагодження програмного продукту довільним методом.

* При відкритті бази даних, з’являється інформаційне повідомлення програмний тестування база автоматизація Рис. 22.1. інформаційне повідомлення про відкриття бази даних «Облік порушень ПДР»

* Головна кнопкова форма і картинка у формі є в наявності.

* Кнопки переходу :

" Робота з формою «є в наявності і працює коректно ;

" Робота із запитами «є в наявності, працює у відповідності з завданням ;

" Робота із звітами «є в наявності, працює коректно ;

" Вийти з бази даних" є в наявності, працює коректно ;

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

* Макроси, що відкривають форми працюють коректно.

* Макроси, що відкривають запити працюють коректно.

* Макроси, що відкривають звіти працюють коректно.

* Підпорядкована форма «Автомобіль» є в наявності, працює коректно.

* Форма «Власник» є в наявності, працює коректно.

* Запити :

Запит, на видалення оплачених власників є в наявності, формується відповідно до завдання ;

Запит, про вибір всіх не оплачених власників є в наявності, формується коректно.

* Звіти :

Звіт на підставі запиту про вибір всіх не оплачених власників, є в наявності, формується коректно ;

* Таблиця «Власник «є в наявності :

Відповідає типу даних Код Власника текстовий ;

Відповідає типу даних Прізвище текстовий ;

Відповідає типу даних Ім'я текстовий ;

Відповідає типу даних батькові текстовий ;

Відповідає типу даних Номер Паспорти числовий ;

Відповідає типу даних Номер посвідчення числовий ;

Відповідає типу даних Рік народження дата / час.

* Таблиця «Автомобіль» є в наявності :

Відповідає типу даних Код Автомобіля текстовий ;

Відповідає типу даних Код власника текстовий ;

Відповідає типу даних Код порушення текстовий ;

Відповідає типу даних Номер автомобіля текстовий ;

Відповідає типу даних Марка текстовий ;

* Таблиця «Порушення «є в наявності :

Відповідає типу даних Код Порушення текстовий ;

Відповідає типу даних Дата порушення дата / час ;

Відповідає типу даних Час порушення текстовий ;

Відповідає типу даних Вид порушення текстовий ;

Відповідає типу даних Розмір штрафу грошовий ;

Відповідає типу даних Сплатити до дата / час ;

Відповідає типу даних Оплата текстовий.

* Схема даних працює коректно.

* Дані :

У таблиці «Власник «дані введені коректно ;

У таблиці «Автомобіль» дані введені коректно ;

У таблиці «Порушення «дані введені не коректно.

* База даних «Облік порушень ПДР «закрилася.

Дайте відповіді на питання:

1. Введення в системний аналіз Системний аналіз виник в епоху розробки комп’ютерної техніки. Успіх його застосування при вирішенні складних завдань багато в чому визначається сучасними можливостями інформаційних технологій. М.М. Моісеєв призводить, за його висловом, досить вузьке визначення системного аналізу: «Системний аналіз — це сукупність методів, заснованих на використанні ЕОМ і орієнтованих на дослідження складних систем — технічних, економічних, екологічних і т.д. Результатом системних досліджень є, як правило, вибір цілком певної альтернативи плану розвитку регіону, параметрів конструкції і т.п. Тому витоки системного аналізу, його методичні концепції лежать в тих дисциплінах, які займаються проблемами прийняття рішень: теорії операцій і загальної теорії управління «.

2. Система переривань Розглядаються основні питання, пов’язані з організацією роботи ЕОМ при обробці переривань, а також особливості системи переривань в персональній ЕОМ.

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

Міністерство освіти і науки України Кіровоградський кооперативний коледж економіки і права імені М. П. Сая Циклова комісія комп’ютерних технологій Тема заняття. Розробка документу «Паспорт системи»

Мета: визначити основні складові документу «Паспорт системи».

Завдання: розробити паспорт програмного продукту.

Документ «Паспорт програмного продукту»

Загальні відомості

Кліматичні умови експлуатації:

— в холодну пору року в приміщенні повинна бути 21−25 С, а в теплу 23−25 С. Вологість повітря від 40% до 60%.

— вимоги до видів обслуговування: адміністратор бази даних

— вимоги до кваліфікації користувача: оператор ЕОМ.

Найменування програмного продукту, її позначення, присвоєне розробником База даних «Облік порушень ПДР»

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

Найменування організації - розробника

«FialkaSoftware»

Склад функцій, реалізованих в програмному продукті

База даних «Облік порушень ПДР» призначена для введення, зберігання інформації; збору і фіксації видів порушень, розмір штрафів і виведення їх на друк або екран комп’ютера.

Опис принципу функціонування

* Запуск бази

* Для кожного порушення фіксується і зберігається дата, час

* Для кожного порушення фіксується і зберігається вид порушення

* Для кожного порушення фіксується і зберігається розмір штрафу

* При оплаті всіх штрафів машина видаляється з бази

* Закриття бази Організація вхідних даних Організація вихідних даних База даних повинна працювати під управлінням сімейства операційних систем Windows,. Повинен бути встановлений Microsoft Office Access 2003 або більш новішої версії.

Загальний регламент та режими функціонування;

База даних повинна працювати під управлінням сімейства операційних систем Windows,. Повинен бути встановлений Microsoft Office Access 2003 або більш новішої версії.

Відомості про сумісність з іншими системами ;

Програмний продукт вимагає наступні технічні конфігурації ПК:

Типи підтримуваних операційних систем:

* Всі сімейства Windows,

* Процесор тактовою частотою: 1,6 ГГц

* Обсяг оперативної пам’яті: 128 Mb

* Місце на жорсткому диску об'ємом: 512 Mb.

* Також необхідна наявність таких пристроїв:

монітор, системний блок, миша, клавіатура.

Дайте відповіді на питання:

1. Введення в системний аналіз Системний аналіз виник в епоху розробки комп’ютерної техніки. Успіх його застосування при вирішенні складних завдань багато в чому визначається сучасними можливостями інформаційних технологій. М.М. Моісеєв призводить, за його висловом, досить вузьке визначення системного аналізу: «Системний аналіз — це сукупність методів, заснованих на використанні ЕОМ і орієнтованих на дослідження складних систем — технічних, економічних, екологічних і т.д. Результатом системних досліджень є, як правило, вибір цілком певної альтернативи плану розвитку регіону, параметрів конструкції і т.п. Тому витоки системного аналізу, його методичні концепції лежать в тих дисциплінах, які займаються проблемами прийняття рішень: теорії операцій і загальної теорії управління «.

Тема заняття. Розробка документу «Загальний опис системи»

Мета: визначити основні складові документу «Загальний опис системи».

Завдання: розробити загальний опис програмного продукту.

Документ на «Загальний Опис Системи»

Призначення програмного продукту База даних «Облік порушень ПДР» призначена для введення, зберігання інформації; збору і фіксації видів порушень, розмір штрафів і виведення їх на друк або екран комп’ютера.

Вид діяльності

Бази даних використовувалися в обчислювальній техніці з незапам’ятних часів. У перших комп’ютерах використовувалися два види зовнішніх пристроїв — магнітні стрічки і магнітні барабани. Ємність магнітних стрічок була достатньо велика. Пристрої для читання-запису магнітних стрічок забезпечували послідовний доступ до даних. Для читання інформації, яка знаходилася в середині або наприкінці магнітної стрічки, необхідно було спочатку прочитати всю попередню ділянку. Наслідком цього була надзвичайно низька продуктивність операцій введення-виведення даних в зовнішню пам’ять. Магнітні барабани давали можливість довільного доступу, але мали обмежений об'єм інформації. Зрозуміло, говорити про якусь систему управління даними у зовнішній пам’яті, в той момент не доводилося.

Опис програмного продукту

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

надійності:

* Автономність — база даних буде функціонувати тільки за наявності MS Access ;

* Точність — у базі даних точно виконуються всі звіти і запити ;