Проект програмного забезпечення управління діяльністю станції швидкої допомоги
Вступ В даній роботі описується автоматизація роботи диспетчера швидкої допомоги. У цілях забезпечення контролю, обігу документів та створення карток (хворих) при занесенні інформації стосовно бригад швидкої допомоги. Відповідно у процесі роботи проводиться дослідження предметної галузі (автоматизація роботи використовується на станціях медичної допомоги), аналіз існуючих потоків даних, створення… Читати ще >
Проект програмного забезпечення управління діяльністю станції швидкої допомоги (реферат, курсова, диплом, контрольна)
Зміст Вступ
1. Аналіз предметної області
1.1 Постановка задачі
2. Проект програмного забезпечення
2.1 Ескізний проект
2.1.1 Контекстна діаграма
2.1.2 Розробка інформаційної моделі програмного забезпечення (ER-діаграма)
2.1.3 Діаграма станів и опис
2.1.4 Розробка інтерфейсу
2.2 Технічний проект
2.2.1 Діаграма та специфікація класів
2.3 Робочий проект
2.3.1 Вибір мови програмування
2.3.2 Побудова фізичної моделі даних
3. Результати розробки Висновки Список використаної літератури Додатки
Вступ В даній роботі описується автоматизація роботи диспетчера швидкої допомоги. У цілях забезпечення контролю, обігу документів та створення карток (хворих) при занесенні інформації стосовно бригад швидкої допомоги. Відповідно у процесі роботи проводиться дослідження предметної галузі (автоматизація роботи використовується на станціях медичної допомоги), аналіз існуючих потоків даних, створення проектної документації та безпосередня розробка бази даних для станцій швидкої допомоги, яка буде використовуватись у медичній галузі для ведення звітної документації.
1. Аналіз предметної області
На сьогоднішній день на станції немає єдиної, взаємозалежної і повноцінно функціонуючої автоматизованої інформаційної системи розробки звітної документації. Всі розробки виконуються диспетчерами власноруч, використовуючи власний досвід, окрім запису телефонної розмови на комп’ютер. Ми бачимо, що ШМД (швидка медична допомога) виступає по відношенню до установ і організацій, що входять в об'єднання як вищестоящий орган, оскільки першою отримує інформацію про потребу в наданні екстреної медичної допомоги населенню і відрізняється від інших видів медичної допомоги тим, що істотне місце в ній займає до госпітальний етап. Понад 70% всіх хворих, що потребують швидкої медичної допомоги, починають отримувати її на до госпітальному етапі, який цілком залежить від роботи диспетчерів.
Диспетчирування швидкої медичної допомоги ми розглядаємо, як важливий етап, від якості надання допомоги на якому нерідко залежать подальший благополучний результат розвитку захворювання і попередження подальших важких ускладнень. У зв’язку з цим генеральною метою вважаємо вдосконалення організації диспетчерської служби, оскільки швидке і грамотне рішення диспетчера сприяє зростанню оперативності, профільності у напрямі бригад і, отже, госпіталізації тяжкохворих і тих, що постраждали, в спеціалізовані відділення і центри в ранні строки, зниження летальності на до госпітальному етапі та на стаціонарі.
Одне з найважчих завдань в роботі диспетчерів оперативного відділу — це направлення бригад на виклик, що поступив. Низький рівень роботи бригад пояснюється у ряді випадків неможливістю визначення по телефону передбачуваного діагнозу і стану хворого.
Привід для виклику часто не дає достатніх орієнтирів для напряму бригади швидкої допомоги і може не відповідати вигляду і стану тяжкості захворювання або травми. Залежно від компетентності диспетчерів оперативного відділу ШМД визначатиметься профільність виїздів бригад. Проте диспетчери не завжди ухвалюють належне рішення про напрям бригад на виклик за профілем, що обумовлене відсутністю контролю за роботою диспетчерів з боку завідувача станції ШМД, розробленої підсистеми навчання диспетчерів. У цих умовах диспетчер виходить з рішення лише однозначного завдання: щонайшвидше направити будь-яку бригаду на виклик.
При цьому спеціалізована бригада часто не отримує профільного напряму, а в той же час лінійна бригада прямує на виклик, який повинен бути відданий спеціалізованій бригаді.
Слід зазначити, що в даній роботі було припущено, що певна машина ШМД направляється одним диспетчером. Уся ж поточна інформація нотується тим самим диспетчером до журналу реєстрації.
1.1 Постановка задачі
Для оптимізації процесу управління діяльністю станції, в тому числі для вирішення оперативних завдань необхідно впровадити комплексну автоматизовану систему управління діяльністю станції (КАСУ) шляхом розробки і впровадження у її діяльність сучасних інформаційних технологій, що дозволяють:
* скоротити час на етапі реєстрації виклику;
* підвищити якість інформації, яка використовується в процесі оперативного управління;
* підвищити ефективність роботи диспетчерів оперативних служб;
* забезпечити рівномірне навантаження на співробітників в процесі обслуговування викликів;
* звільнити співробітників оперативних служб від трудомістких ручних робіт по прийому, передачі та контролю виконання викликів;
* скоротити час підготовки оперативної та звітно-статистичної інформації;
* підвищити оперативність та якість довідкової інформації населенню, що представляється медичним закладам, оперативних служб міста.
Отримання дзвінків від населення здійснюється централізовано за єдиним телефоном «03», цілодобово. Всі телефонні переговори, утворені на кожному робочому місці оперативного відділу, постійно записуються. КАСУ дозволяє провести первинне медичне сортування на етапі прийняття виклику, завдяки застосуванню алгоритму прийому виклику. Крім того, алгоритм прийняття виклику дозволяє пов’язати привід звернення і дані про стан хворого з відповідним типом необхідної бригади. З моменту впровадження КАСУ алгоритми прийому виклику зазнають зміни в бік мінімізації кількості запитань та конкретизації їх. Також автоматизована підсистема дає можливість постійного моніторингу «стану» кожної бригади, що дозволяє раціонально використовувати їх.
2. Проект програмного забезпечення
2.1 Ескізний проект
2.1.1 Контекстна діаграма На основі технічного завдання побудуємо початкову контекстну діаграму з потоками даних. З опису технічного завдання маємо наступні зовнішні об'єкти для програми: Диспетчер, Головний лікар, Бригади 03.
Рисунок 2.1 — Контекстна діаграма 0 рівня Таблиця 2.1 відповідність потоків даних на різних рівнях.
Інформація для диспетчера містить такі документи як: · Звіт бригади; · Звіт від головного лікаря; | ||
Диспетчер має змогу переглянути необхідно інформацію яку бригади або головний лікар передають до БД. Диспетчер має змогу занести дані про бригади до БД. | ||
Звіт для головного лікаря повинен містити інформацію про хворого який було створено бригадою. | ||
Звіт від головного лікаря повинен містити діагноз який було виявлено у ході обстеження хворого. | ||
Інформація від бригади (звіт) повинна включати в себе такі поля як: № Звіту Дата (обстеження) ПІБ (хворого) | ||
Інформація для бригади повинна містити наступні поля: 1) № Звіту 2) Дата 3) Адреса | ||
2.1.2 Розробка інформаційної моделі програмного забезпечення (ER-діаграма)
Виходячи з наведеної функціональної моделі бази розробляємого програмного забезпечення, зробимо інформаційну модель.
Рисунок 2.2 — Інформаційна модель програмного забезпечення
Побудована ER-діаграма містить. 6 сутностей — «Виїзд на завдання» яке в свою чергу поділяється на наступні «Диспетчер», «Пацієнт», «Головний лікар», «Відділ диспетчеризації СШМД».
2.1.3 Діаграма станів и опис
Отримана діаграма станів системи зображена на рисунку 2.3.
Рисунок 2.3 — Діаграма станів
Стани системи описані в таблиці 2.2
Таблиця 2.2 — Опис станів системи
Номер/Назва початкового стану | Номер стрілки переходу станів | Номер/Назва кінцевого стану | Описання стану (Доступні функції) | Значення переходу | |
С0/Главное меню | С1/Занесення даних | У цьому стані доступні переходи до: · Дані про хворих · Дані про бригаду | У цьому переході маємо можливість перейти до іншого стану за допомогою кнопки «Занесення даних» | ||
С0/Головне меню | С2/Звіти | У цьому стані маємо змогу перейти до наступних станів: · Звіт від головного лікаря · Звіт бригади | У цьому переході маємо можливість перейти до іншого стану за допомогою кнопки «Звіти» | ||
C1/Занесення даних | С3/Дані про хворих | У цьому стані відбувається занесення інформації, а саме: · Дата · ПІБ · Діагноз · | У цьому переході маємо можливість перейти до іншого стану за допомогою кнопки «Дані про хворих» | ||
C1/Занесення даних | С4/Дані про бригаду | У цьому стані відбувається занесення інформації, а саме : · № Виклику · Дата · Адреса | У цьому переході маємо можливість перейти до іншого стану за допомогою кнопки «Дані про бригаду» | ||
C2/ Звіти | С5/Звіт від головного лікаря | У цьому стані ми маємо можливість переглянути звіт від головного лікаря. | У цьому переході маємо можливість перейти до іншого стану за допомогою кнопки «Звіт від головного лікаря» | ||
C2/ Звіти | С6/Звіт бригади | У цьому стані ми маємо можливість переглянути звіт бригади. | У цьому переході маємо можливість перейти до іншого стану за допомогою кнопки «Звіт бригади» | ||
2.1.4 Розробка інтерфейсу
Інтерфейс має дуже велике значення для системи тестування. Він повинен бути простим та водночас зручним для користувача, щоб будь яка людина, яка має базові навички роботи з комп’ютером, могла без жодних перешкод працювати з системою. Дана система буде мати графічний інтерфейс.
Серед основних платформ, які б ми могли використати, можна виділити такі, як Paradox, FoxPro та Microsoft Office Access. Самою доступною та самою розповсюдженою з них є остання. Тому для виконання даної роботи ми будемо використовувати СУБД Access 2007.
Форма «Меню» представлятиме собою кнопочку форму, яка складається з набору кнопок, що забезпечують доступ до інших форм та функцій програми. В таблиці 2.3 перелічені всі кнопки форми «Меню»
Таблиця 2.3 — Кнопки форми «Меню»
Назва кнопки | Реакція на натиснення | |
Занесення даних | Відкривається форма «Занесення даних» | |
Звіти | Відкривається форма «Звіти» | |
Вихід | Вихід з бази даних | |
В формі «Занесення даних» знаходяться 2 кнопки: «Дані про хворих» та «Дані про бригаду». При натисненні кнопки «Звіти» повинні відкритись форми «Звіт від головного лікаря» та «Звіт бригади».
Якщо натиснути кнопку «Занесення даних» маємо змогу переглянути форми «Дані про хворих» та «Дані про бригаду».
Якщо натиснути кнопку «Дані про хворих» то повинна відкритись форма у якій користувач матиме змогу занести дані про дату, ПІБ та діагноз.
Якщо натиснути кнопку «Дані про бригаду» ми матимемо змогу занести дані про бригаду за критеріями: № виклику, дата, адреса.
Якщо натиснути кнопку «Звіт від головного лікаря «у цьому стані ми матимемо можливість переглянути інформацію від головного лікаря по таким критеріям як ПІБ (хворого), дата, діагноз.
Якщо натиснути кнопку «Звіт бригади» при натисненні на цю кнопку ми матимемо можливість переглянути звіт о роботі яка було виконана бригадою.
1. Інтерфейс стану 0
2. Інтерфейс стану 1
3. Інтерфейс стану 2
4. Інтерфейс стану 3
2.2 Технічний проект
2.2.1 Діаграма та специфікація класів Отриманні у ескізному проекті діаграми потоків даних мають дуже загальне значення, тому необхідно провести декомпозиції деяких їх елементів. Результат декомпозиції (1 рівень) представлений на рисунку 2.4.
Рисунок 2.4 — Декомпозиція діаграми потоків даних 1-го рівня.
Таблиця 2.4 — Словник потоків даних декомпозиції діаграми 1-го
Ім'я потоку | Структура потоку | |
Дані для диспетчера | ФІО хворого, дата, діагноз. | |
Команди диспетчера | До команд диспетчера належать документи від бригади. | |
Інформація від бригади | Інформація (звіт) від бригади приймається за такими критеріями як: · № Звіту · Дата · Адреса · Діагноз | |
Дані для адміністратора | Інформація яка була занесена до БД. | |
Звіт для головного лікаря | Лікар отримує звіти які містять у собі такі поля як : · Звіт від бригади · Дата · Діагноз | |
Звіт від головного лікаря | Головний лікар створює звіт за такими критеріями як: Дата ПІБ Діагноз (який було поставлено) Лікування | |
Отримана діаграма потоків даних 1-го рівня належить ще більшої деталізації.
Результат декомпозиції модуля «Обслуговування диспетчера»
Рисунок 2.5 — Декомпозиція діаграми потоків даних 1-го рівня.
Таблиця 2.5 — Словник потоків даних декомпозиції діаграми 1-го
Ім'я потоку | Структура потоку | |
Дані адміністратора | Інформація яка заповнюється при регістрації користувача у БД. | |
Команди адміністратора | Зворотна інформація від БД. | |
Дані для адміністратора | Інформація яку було занесено до БД. | |
Дані диспетчера | ФІО хворого, дата, діагноз. | |
Команди диспетчера | До команд диспетчера належать документи від бригади. | |
2.3 Робочий проект
2.3.1 Вибір мови програмування
Доцільним і зручним виявилось створити базу даних у СУБД Microsoft Access 2003, яка пропонує вбудований інструментарій для інтеграції БД з оболонкою програмного забезпечення на мові Visual Basic.
2.3.2 Побудова фізичної моделі даних Дані, по яким необхідно представити фізичну модель даних в СУБД MS Access 2003 на підставі раніше розробленої логічної моделі даних БД «СШМД», представлені в нижче приведених таблицях 2.6 — 2.11.
Таблиця 2.6 — Структура таблиці «Diagnoz» (Діагнози)
Найменування поля | Логічне ім'я | Тип даних | ключ | |
Kod | Код діагнозу | integer | PK | |
Name | Назва діагнозу | Varchar (30) | ||
Таблиця 2.7 — Структура таблиці «Dispetcherska» (Відділ)
Найменування поля | Логічне ім'я | Тип даних | ключ | |
Kod | Код відділу | integer | PK | |
Name | Назва відділу | Varchar (30) | ||
Коd | Код диспетчера | integer | ||
Таблиця 2.8 — Структура таблиці «Dispetcher» (Диспетчер)
Найменування поля | Логічне ім'я | Тип даних | ключ | |
Kod | Код диспетчера | integer | PK | |
Name | Прізвище диспетчера | Varchar (30) | ||
FirstName | Ім'я диспетчера | Varchar (20) | ||
SecName | По-батькові диспетчера | Varchar (20) | ||
N shift | Номер зміни диспетчера | Varchar (20) | ||
N TrudKn | Номер трудової книжки диспетчера | Varchar (20) | ||
N IdKod | Номер ідентифікаційного коду диспетчера | Varchar (20) | ||
N_Pasport | Номер паспорта пацієнта | Varchar (10) | ||
MoreInform | Додаткова інформація | Varchar (20) | MoreInform | |
Таблиця 2.9 — Структура таблиці «ViizdnaBrigada» (Виїздна бригада)
Найменування поля | Логічне ім'я | Тип даних | ключ | |
Kod | Код бригади | integer | PK | |
Name | Назва бригади | Varchar (30) | ||
Таблиця 2.10 — Структура таблиці «Viizd» (Виїзд на завдання)
Найменування поля | Логічне ім'я | Тип даних | ключ | |
Kod | Код документу | integer | PK | |
Name | Назва документу | Varchar (30) | ||
Nomer | Номер документу | Varchar (30) | ||
DataDoc | Дата заповнення | Date | ||
Kod_Persona | Код пацієнта | integer | FK | |
Kod_Medocur | Код медустанови | integer | FK | |
Kod_Diagnoz | Код діагнозу | integer | FK | |
Таблиця 2.11 — Структура таблиці «Patient"(Пацієнти)
Найменування поля | Логічне ім'я | Тип даних | ключ | |
Kod | Код пацієнта | integer | PK | |
Name | Прізвище пацієнта | Varchar (30) | ||
FirstName | Ім'я пацієнта | Varchar (20) | ||
SecName | По-батькові пацієнта | Varchar (20) | ||
DataPriv | Дата народження пацієнта | Date | ||
Kod_Street | Код вулиці | integer | FK | |
Dom | Номер дому пацієнта | Varchar (10) | ||
Apartment | Номер квартири пацієнта | Varchar (10) | ||
Pol | Стать пацієнта | Char (1) | ||
U4astok | Дільниця, де проживає пацієнт | smallint | ||
N_Pasport | Номер паспорта пацієнта | Varchar (10) | ||
N_Karta | Номер медкартки пацієнта | Varchar (10) | ||
N_Telefon | Номер телефону пацієнта | Varchar (20) | ||
DateViizd | Дата виїзду на виклик | date | ||
DateZapovnenna | Дата заповнення | date | ||
MoreInform | Додаткова інформація | Varchar (20) | ||
Фізична модель даних представлена на рисунку 2.6.
Рисунок 2.6 — Фізична модель бази даних
3. Результати розробки У даній роботі було розроблено програмне забезпечення «ЦШМД» для станцій швидкої медичної допомоги.
Воно виконує наступні функції:
· Ведення інформації про хворих;
· Ведення інформації про бригади;
· Ведення інформації від головного лікаря;
· Пошук хворих;
· Формування звітів від бригад;
Усі заплановані функції було реалізовано.
При реалізації було створено файл БД у СУБД Access з назвою «ЦШМД» розміром 16 Mb, який містить код на мові програмування Visual Basic та запити на мові SQL загальною кількістю 171 строки.
Вихідні коди програми наведено у додатках Д та Є. Програму та методику випробовувань наведено у додатку Е.
Висновки Після визначення проблематики та існуючих проблем, після встановлення засобів їх вирішення та досягнення основної мети, було розроблено проект програмного забезпечення для швидкої обробки усіх потоків інформації центру швидкої медичної допомоги.
В результаті проектування програмного забезпечення автор розробив БД з автоматизованою обробкою потоків даних та процесів в ній за допомогою програмних модулів, які вирішують наступні проблеми:
· Зручне занесення інформації про хворих у базу;
· Зручне занесення інформації про бригаду у базу;
· Зручне збереження інформації у цифровому вигляді на ЕОМ;
· Створення зручної форми занесення даних;
· Пошук інформації про хворих;
· Пошук інформацію про виїзд бригад;
· Формування звітів;
· Швидкий доступ до даних;
· Видача необхідної інформації за запитом;
Було зроблено аналіз предметної області для цього програмного забезпечення. Наводяться контекстна діаграма, інформаційна модель, діаграма станів, діаграма потоків даних, специфікація модулів. Було розроблено зручний інтерфейс для користувача. Доступною мовою описано процес та методологію створення програми, наведено документацію.
Також наведено результати тестування програми, успішні результати яких свідчать про те, що програма готова до введення в дію. Усі заплановані функції програми було реалізовано.
Список використаної літератури
1. Методичні вказівки до виконання курсового проекту з дисципліни «Технологія розробки і САПР програмного забезпечення».
2. ГОСТ 19.102−77. Единая система программной документации. Стадии разработки.
3. Конноли Т. Бегг К. Базы данных. Проектирование, реализация и сопровождение. Теория и практика, 3-е издание.
4. Грубер М.
Введение
в SQL.
5. Джоуне, Эйри, Свивене, Райан, Кригель, Алекс. Функции SQL.
Додаток, А Технічний проект
1. Підстава для розробки.
Умовне позначення програмного виробу:"ЦШМД"
Документ: Завдання на лабораторну роботу
Затвердила: Тудоран В. А Дата затвердження: 20.09.12.
2. Призначення розробки.
Головною метою даної курсової роботи є створення програмного забезпечення, ведення автоматизації роботи і направлення бригад на виклик, що поступив як найшвидше. Створене програмне забезпечення націлено на уникнення неефективного витрачення робочого часу працівників в зв’язку з виконанням направлення бригад за профілем, та подальшим занесенням інформації у базу для швидкого пошуку з можливістю редагування. Дана автоматизована система забезпечує цілісність інформації та мінімізує ризик втрати цінної інформації.
2.1 Функціональне призначення.
Головним призначення даної системи є регулювання відношень диспетчерів з бригадам.
Розглянемо відношення диспетчерів з бригадами без втручання автоматизованої системи. Якщо ШМД приймає виклик то після цього диспетчер повинен знайти бригаду за профілем. З’ясувати чи знаходиться дана бригада у розташуванні ШМД, та чи є можливість посилання її за даною адресою на даний момент часу. Потім занотувати даний виїзд бригади у журналі реєстрації.
2.2 Експлуатаційне призначення.
Розроблена програма може успішно використовуватися у ШМД, головним диспетчерами.
3. Вимоги до програми чи програмному виробу.
3.1 Вимоги до функціональних характеристик.
3.1.1 Вимоги до складу виконуваних функцій.
Система повинна містити модуль по роботі диспетчера.
Модуль по роботі диспетчера, бригади та головного лікаря.
В модулі де буде працювати диспетчер повинно бути реалізовано:
1) Створює звіт стосовно виклику
· ПІБ клієнта
· Час прийому виклику
· Адреса
2) Передає виклик до бригади
· Час передачі виклику
· Фрагмент карти з адресою виклику (координати)
3) Бригада передає звіт після виклику А)
· Час отримання виклику
· Час прибуття на місце виклику
· Час закінчення роботи на місці
· Пробіг машини за виклик Б)
· Симптоми які було виявлено у ході обстеження
· Діагноз Програма повинна забезпечувати виконання наступних функцій:
1) Авторизація для персоналу
· П.І.Б.
· Пароль
2) Розробка спеціалізованої документації
До розробки документації входять:
· Дата створення документу
· П.І.Б.
· Симптоми при першому огляді
· Діагноз який було поставлено на основі симптомів
· Курс лікування
2) Розробка звіту по виклику
· Час та дата отримання виклику
· Час який було затрачено на клієнта
Також додатково у ході розробки системи будуть автоматизовані наступні функції:
· автоматизація роботи в певному регламенті за попередньо відпрацьованими матрицями (таблицями);
· автоматизація роботи на основі алгоритмiзацiї лiкувально-дiагностичного процесу;
· автоматизація комп’ютерної обробки даних та занесення їх до вiдповiдних форм документів.
3.2 Вимоги до організації вхідних даних.
Вхідними даними є назва файлу, яку користувач обирає для звіту. Це дані, що вводяться з клавіатури у текстовій формі, та за правилами назва файлу не повинна містити символи: /: *? «<>. Вхідні дані повинні бути представлені у виді звітів спеціальної форми.
3.3 Вимоги до організації вихідних даних.
Вихідними даними є усі вищезгадані типи звітів у текстовій формі, що виводяться за бажанням користувача. Звіти зберігаються у файл який має формат «.txt». Також в дану систему впроваджено можливість занесення інформації до спеціальної таблиці даних
Повинна зберігати усі отримані звіти, та зберігати їх до текстового файлу або зберігатися на окремому пристрої.
3.4 Вимоги до експлуатації
Необхідний рівень підготовки користувача: базові навики користування комп’ютером та програмою Microsoft Office Access.
3.5 Вимоги до складу та параметрів технічних засобів.
Даний програмний продукт потребує від комп’ютеру, на якому буде встановлений, наступних характеристик, які треба розглядати як мінімальні:
Операційна система: Windows XP
Процесор: Pentium
Пам’ять: 512Мб.
Дисковий простір: 20 Гб.
3.6 Вимоги до інформаційної та програмної сумісності
3.6.1 Вимоги для вихідного коду та язикам програмування Вихідний код програми повинен бути представлені у вигляді скриптів на мові VBA або SQL запитів.
3.6.2 Вимоги до програмного продукту, які використовуються програмою
Єдиним системним програмним засобом, що буде використовувати програма, є операційна система.
Операційна система: Windows XP або вище Microsoft Office Access
3.6.3 Вимоги до захисту інформації та програм Програма буде використовуватися на станції швидкої допомоги, а лікарська етика вимагає забезпечення конфіденційності інформації.
Всі працівники установи, що є користувачами, взаємодіють з системою на рівні визначених прав доступу. Права доступу визначаються посадовими обов’язками співробітника і задаються системним адміністратором.
Захист підсистеми від несанкціонованого доступу реалізується на двох рівнях — системному рівні і рівні додатка. Системний рівень передбачає можливість входу користувача в підсистему і запуску програм. З достатнім ступенем надійності такий захист реалізований на сервері системи, заснованому на ОС Windows XP. Під час запуску програм відбувається повторна авторизація диспетчера-користувача, причому його ім'я може не збігатися з ім'ям в операційній системі.
Доступ до даних і функцій дозволяється тільки при правильному введенні користувальницького імені і пароля. При будь-яких змінах даних по протоколі зроблених змін можна визначити ким і коли вони були зроблені.
3.7 Вимоги до маркування та пакування Програма повинна розповсюджуватись на оптичних СD-дисках.
3.8 Вимоги до транспортування та зберігання.
Умови експлуатації повинні відповідати Наказу Міністерства труда і соціальної політики України (Комітет з надзору та охороною праці України) від 10.02.1999 № 21 «Про затвердження правил охорони праці при експлуатації електронно-обчислювальних машин».
Розробник програми повинен брати участь в супроводженні і подальшому розвитку даної програми.
Програма має збігатися і транспортуватися як все CD-диски згідно ГОСТ. Не допускати подряпин на боці, з якого буде зчитуватися інформація.
Дана програма встановлюється на жорсткий диск. Для коректної роботи температура в приміщенні повинна бути в межі від +15 до +35 °C, відносна вологість не більше 70%.
3.9 Вимоги до програмної документації
Повний пакет документів повинен включати:
Ш Опис програми;
Ш Текст програми;
Ш Програма і методика випробувань;
Ш Посібник користувача;
3.10 Техніко-економічні показники З впровадженим програмного забезпечення станція швидкої допомоги отримає можливість економити витрати на бензин та соляру (в залежності від типу двигуна машини) за рахунок того, що на виклик висилається та бригада, яка знаходиться найближче.
4. Стадії і етапи розробки
Таблиця 1 Стадії та етапи розробки.
Стадія | Етап | Строки | |
Ескізний проект | Прийняття принципових рішень по структурі програмного продукту, усім видам забезпечення, попередній розрахунок економічної ефективності та технічних показників продукту: | Початок: Завершення: | |
Технічний проект | Вибір інструменту мови кодування. Формування програмного продукту в цілому. Розробка документації. | Початок: Завершення: | |
Робочий проект | Виготовлення та налагодження компонентів програмного продукту. Заплановані строки початку та завершення. | Початок: Завершення: | |
Введення в лінію | Дослідне функціонування програмного продукту з метою перевірки працездатності, визначення дійсних техніко-економічних показників, корегування документації. | Початок: Завершення: | |
Продукт вважається завершеним якщо виконує всі функції технічного завдання.
Додаток Б
програма швидкий допомога автоматизація
Опис програмного забезпечення
1. Загальні відомості
Розроблена автоматизована система призначена для центрів швидкої медичної допомоги.
Вона націлена на:
· Уникнення неефективного витрачення робочого часу працівників в зв’язку з виконанням рутинних операцій по пошуку
· Редагуванню інформації кожного об'єкту у базі
· Ризику втрати цінної інформації
2. Функціональне призначення
Дана автоматизована система призначена для ведення центром швидкої медичної допомоги обліку карток хворих, контролю бригад та виконувати інформаційний обмін між диспетчером головним лікарем та бригадами.
3. Опис логічної структури За логічною структурою програма може бути поділена на такі модулі:
· Ведення інформації про хворих
· Ведення інформації про бригади
4. Використані технічні засоби При розробці даної системи були використані наступні технічні засоби:
· Процесор Intel Pentium 4 2.53 GHz;
· Графічний адаптер NVIDIA GeForce 5700 Ultra;
· ОЗП: 2 Гб;
· 50 мб дискового простору
· Маніпулятор миша та клавіатура
5. Запуск Для того, щоб можна було користуватись базою даних, треба її встановити. Для цього потрібно скопіювати розроблену систему на свій комп’ютер.
Щоб відкрити програму, треба натиснути 2 рази на ліву кнопку миші на файлі «CFMR.mdb».
6. Вхідні дані
Вхідними даними є дані про хворих (ПІБ, Дата народження, адреса, номер телефону, діагноз), дані про бригаду (Адреса, дата, час, № бригади), що вводить користувач.
7. Вихідні дані
Вихідними даними є дані про хворих (ПІБ, Дата народження, адреса, номер телефону, діагноз), дані про бригаду (Адреса, дата, час, № бригади), що виводяться з БД на екран.
Додаток В Опис застосування
1. Призначення програми Розроблена автоматизована система призначена для центрів швидкої медичної допомоги.
Вона націлена на:
· Уникнення неефективного витрачення робочого часу працівників в зв’язку з виконанням рутинних операцій по пошуку
· Редагуванню інформації кожного об'єкту у базі
· Ризику втрати цінної інформації
2. Умови використання Для коректної роботи програми необхідний персональний комп’ютер, що відповідає наступним апаратним вимогам:
· Процесор: Pentium III 800Hz
· Пам’ять 256 Mb
· Дисковий простір: 20 Mb + необхідний простір для зберігання файлу БД.
· Операційна система: Windows 98/XP/Vista/7
3. Опис задачі
Дана програма призначена для введення центром швидкої медичної допомоги звітів бригад та картки хворих.
Для вирішення задачі були створені наступні модулі:
· Ведення інформації про хворих (здійснення зміни або занесення до БД інформацію про хворих).
· Ведення інформації про бригади (здійснення зміни або занесення до БД інформації про бригади).
· Пошук інформацію про хворих (здійснення вводу інформації, за якою відбуватиметься пошук БД)
4. Вхідні та вихідні дані
Вхідними даними є дані про хворих (ПІБ, Дата народження, адреса, номер телефону, діагноз), дані про бригаду (Адреса, дата, час, № бригади), що вводить користувач.
Вихідні дані
Вихідними даними є дані про хворих (ПІБ, Дата народження, адреса, номер телефону, діагноз), дані про бригаду (Адреса, дата, час, № бригади), що виводяться з БД на екран.
Додаток Г
Інструкція користувача Програмне забезпечення «ЦШМД» використовується для ведення центром швидкої медичної допомоги карток клієнтів, звітів від бригад.
Кінцевим користувачем програми може бути будь-яка людина, що володіє базовими знаннями ПК: знає основи Windows XP, вміє встановлювати та запускати програми на комп’ютер.
Для роботи з цим програмним забезпеченням, користувачу потрібно ознайомитися з наведеною нижче інструкцією.
1. Загальні відомості про програму.
Назва програми: програмне забезпечення «ЦШМД»
Функціональне призначення: ведення центром швидкої допомоги обліку карток хворих та звітів від бригад.
Програмне забезпечення, необхідне для функціонування програми: ОС Windows, Access 2003 або вище.
2. Вхідні дані
Вхідними даними є дані про хворих (ПІБ, Дата народження, адреса, номер телефону, діагноз), дані про бригаду (Адреса, дата, час, № бригади), що вводить користувач.
Вихідні дані
3. Вихідними даними Вихідними даними є дані про хворих (ПІБ, Дата народження, адреса, номер телефону, діагноз), дані про бригаду (Адреса, дата, час, № бригади), що виводяться з БД на екран.
4. Робота з програмою Для того, щоб можна було користуватись програмою, треба її встановити. Для цього скопіюємо її на комп’ютер. Після запуску програми користувач повинен чітко дотримуватися інструкцій.
Щоб її відкрити, треба натиснути 2 рази ліву кнопку на миші на файлі «ReportsInfo.mdb» у результаті відкриється вікно з головною формою.
Додаток Д — Текст програми Для того щоб виконати перевірку чи є заповнення деякого рядку можна скористатися цим кодом:
If (me.Поле_Имя.Value = «»)
MsgBox «Сначала введите имя»
Application.Undo
EndIf
або
Private Sub MyName_Change ()
If (Len (Me.MyName.Text) > 0) Then
Me.MyNameSecond.Locked = False
Else
Me.MyNameSecond.Locked = True
Me.MyNameSecond.Text = «»
End If
End Sub
Форма:
Option Compare Database
Private Sub Кнопка6_Click ()
On Error GoTo Err_Кнопка6_Click
DoCmd.GoToRecord, acNewRec
Exit_Кнопка6_Click:
Exit Sub
Err_Кнопка6_Click:
MsgBox Err. Description
Resume Exit_Кнопка6_Click
End Sub
Форма 1:
Option Compare Database
Private Sub Кнопка6_Click ()
On Error GoTo Err_Кнопка6_Click
DoCmd.Close
Exit_Кнопка6_Click:
Exit Sub
Err_Кнопка6_Click:
MsgBox Err. Description
Resume Exit_Кнопка6_Click
End Sub
справочник:
Option Compare Database
Private Sub Form_Load ()
End Sub
Private Sub Кнопка5_Click ()
On Error GoTo Err_Кнопка5_Click
DoCmd.GoToRecord, acNewRec
Exit_Кнопка5_Click:
Exit Sub
Err_Кнопка5_Click:
MsgBox Err. Description
Resume Exit_Кнопка5_Click
End Sub
Option Compare Database
Private Sub Кнопка3_Click ()
On Error GoTo Err_Кнопка3_Click
DoCmd.Close
Exit_Кнопка3_Click:
Exit Sub
Err_Кнопка3_Click:
MsgBox Err. Description
Resume Exit_Кнопка3_Click
End Sub
Справочник:
Option Compare Database
Private Sub Form_Load ()
End Sub
Private Sub Кнопка9_Click ()
On Error GoTo Err_Кнопка9_Click
DoCmd.GoToRecord, acNewRec
Exit_Кнопка9_Click:
Exit Sub
Err_Кнопка9_Click:
MsgBox Err. Description
Resume Exit_Кнопка9_Click
End Sub
Option Compare Database
Private Sub Кнопка13_Click ()
On Error GoTo Err_Кнопка13_Click
DoCmd.GoToRecord, acNewRec
Exit_Кнопка13_Click:
Exit Sub
Err_Кнопка13_Click:
MsgBox Err. Description
Resume Exit_Кнопка13_Click
End Sub
Кнопка6:
Private Sub Кнопка6_Click ()
On Error GoTo Err_Кнопка6_Click
DoCmd.GoToRecord, acNewRec
Exit_Кнопка6_Click:
Exit Sub
Err_Кнопка6_Click:
MsgBox Err. Description
Resume Exit_Кнопка6_Click
Кнопка 7:
Private Sub Кнопка7_Click ()
On Error GoTo Err_Кнопка7_Click
DoCmd.DoMenuItem acFormBar, acEditMenu, 8, acMenuVer70
DoCmd.DoMenuItem acFormBar, acEditMenu, 6, acMenuVer70
Exit_Кнопка7_Click:
Exit Sub
Err_Кнопка7_Click:
MsgBox Err. Description
Resume Exit_Кнопка7_Click
End Sub
Кнопка 8:
Private Sub Кнопка8_Click ()
On Error GoTo Err_Кнопка8_Click
DoCmd.Close
Exit_Кнопка8_Click:
Exit Sub
Err_Кнопка8_Click:
MsgBox Err. Description
Resume Exit_Кнопка8_Click
End Sub
Додаток Є
Програма і методика випробувань При проведенні випробувань функціональні характеристики програми підлягають перевірці на відповідність вимогам, перерахованим у пункті 3.1 «Вимоги до функціональних характеристик» технічного завдання.
1. Об'єктом випробування
Об'єктом випробування є програмне забезпечення для центрів медичної допомоги.
2. Мета випробувань Мета випробувань — перевірка працездатності програми, її відповідність до технічного завдання, одержання навиків роботи з нею.
3. Вимоги до програми Вимоги до програми наведені у технічному завданні (Додаток 1)
4. Засоби та порядок випробувань
4.1 Технічні засоби
· Процесор Intel Pentium 4 2.53 GHz;
· Графічний адаптер NVIDIA GeForce 5700 Ultra;
· ОЗП: 2 Гб;
· Монітор 19″ WXGA;
· 50 мб дискового простору;
· Маніпулятор миша та клавіатура;
4.2 Програмні засоби
· Операційна система: Windows XP
· Microsoft Access 2003
4.3 Порядок випробовувань
Запустити виконавчий файл програми «CFMR.mdb». Випробування відбуваються з чітким дотриманням інструкції користувача, викладеної у додатку Г.
5 Методи випробувань При занесенні інформації до групи товарів, користувач буде повинен заповнити наступні поля після чого інформація буду занесена до БД. (Рисунок 1)
Рисунок 1 — Занесення інформації про хворих При занесенні інформації до групи товарів, користувач буде повинен заповнити наступні поля після чого інформація буду занесена до БД. (Рисунок 2)
Рисунок 2 — Занесення інформації від головного лікаря
Для виконання пошуку по БД користувач матиме змогу скористуватися формами для пошуку по № виклику або адресою. (Рисунок 3)
Рисунок 3 — Занесення інформації про бригаду При занесенні інформації від бригади, користувач повинен буде заповнити наступні поля після чого інформація буду занесена до БД. (Рисунок 4)
Рисунок 4 — Занесення інформації від бригади