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

 

Зміст

Вступ

. Аналіз предметної області

.1 Постановка задачі

. Проект програмного забезпечення

.1 Ескізний проект

.1.1 Контекстна діаграма

.1.2 Розробка інформаційної моделі програмного забезпечення (ER-діаграма)

.1.3 Діаграма станів и опис

.1.4 Розробка інтерфейсу

.2 Технічний проект

.2.1 Діаграма та специфікація класів

.3 Робочий проект

.3.1 Вибір мови програмування

.3.2 Побудова фізичної моделі даних

. Результати розробки

Висновки

Список використаної літератури

Додатки

Вступ

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

1. Аналіз предметної області

На сьогоднішній день на станції немає єдиної, взаємозалежної і повноцінно функціонуючої автоматизованої інформаційної системи розробки звітної документації. Всі розробки виконуються диспетчерами власноруч, використовуючи власний досвід, окрім запису телефонної розмови на компютер. Ми бачимо, що ШМД (швидка медична допомога) виступає по відношенню до установ і організацій, що входять в об'єднання як вищестоящий орган, оскільки першою отримує інформацію про потребу в наданні екстреної медичної допомоги населенню і відрізняється від інших видів медичної допомоги тим, що істотне місце в ній займає до госпітальний етап. Понад 70% всіх хворих, що потребують швидкої медичної допомоги, починають отримувати її на до госпітальному етапі, який цілком залежить від роботи диспетчерів.

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

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

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

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

Слід зазначити, що в даній роботі було припущено, що певна машина ШМД направляється одним диспетчером. Уся ж поточна інформація нотується тим самим диспетчером до журналу реєстрації.

.1 Постановка задачі

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

скоротити час на етапі реєстрації виклику;

підвищити якість інформації, яка використовується в процесі оперативного управління;

підвищити ефективність роботи диспетчерів оперативних служб;

забезпечити рівномірне навантаження на співробітників в процесі обслуговування викликів;

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

скоротити час підготовки оперативної та звітно-статистичної інформації;

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

Отримання дзвінків від населення здійснюється централізовано за єдиним телефоном «03», цілодобово. Всі телефонні переговори, утворені на кожному робочому місці оперативного відділу, постійно записуються. КАСУ дозволяє провести первинне медичне сортування на етапі прийняття виклику, завдяки застосуванню алгоритму прийому виклику. Крім того, алгоритм прийняття виклику дозволяє пов'язати привід звернення і дані про стан хворого з відповідним типом необхідної бригади. З моменту впровадження КАСУ алгоритми прийому виклику зазнають зміни в бік мінімізації кількості запитань та конкретизації їх. Також автоматизована підсистема дає можливість постійного моніторингу «стану» кожної бригади, що дозволяє раціонально використовувати їх.

2. Проект програмного забезпечення

.1 Ескізний проект

.1.1 Контекстна діаграма

На основі технічного завдання побудуємо початкову контекстну діаграму з потоками даних. З опису технічного завдання маємо наступні зовнішні обєкти для програми: Диспетчер, Головний лікар, Бригади 03.

Рисунок 2.1 - Контекстна діаграма 0 рівня

Таблиця 2.1 відповідність потоків даних на різних рівнях.

1Інформація для диспетчера містить такі документи як: · Звіт бригади; · Звіт від головного лікаря;2Диспетчер має змогу переглянути необхідно інформацію яку бригади або головний лікар передають до БД. Диспетчер має змогу занести дані про бригади до БД.3Звіт для головного лікаря повинен містити інформацію про хворого який було створено бригадою.4Звіт від головного лікаря повинен містити діагноз який було виявлено у ході обстеження хворого.5Інформація від бригади (звіт) повинна включати в себе такі поля як: № Звіту Дата (обстеження) ПІБ(хворого)6Інформація для бригади повинна містити наступні поля: 1) № Звіту 2) Дата 3) Адреса

2.1.2 Розробка інформаційної моделі програмного забезпечення (ER-діаграма)

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

Рисунок 2.2 - Інформаційна модель програмного забезпечення

Побудована ER-діаграма містить. 6 сутностей - «Виїзд на завдання» яке в свою чергу поділяється на наступні «Диспетчер», «Пацієнт», «Головний лікар», «Відділ диспетчеризації СШМД».

2.1.3 Діаграма станів и опис

Отримана діаграма станів системи зображена на рисунку 2.3.

Рисунок 2.3 - Діаграма станів

Стани системи описані в таблиці 2.2

Таблиця 2.2 - Опис станів системи

Номер/Назва початкового стануНомер стрілки переходу станівНомер/Назва кінцевого стануОписання стану (Доступні функції)Значення переходуС0/Главное меню1С1/Занесення данихУ цьому стані доступні переходи до: · Дані про хворих · Дані про бригадуУ цьому переході маємо можливість перейти до іншого стану за допомогою кнопки «Занесення даних»С0/Головне меню2С2/ЗвітиУ цьому стані маємо змогу перейти до наступних станів: · Звіт від головного лікаря · Звіт бригадиУ цьому переході маємо можливість перейти до іншого стану за допомогою кнопки «Звіти»C1/Занесення даних3С3/Дані про хворихУ цьому стані відбувається занесення інформації, а саме: · Дата · ПІБ · Діагноз · У цьому переході маємо можливість перейти до іншого стану за допомогою кнопки «Дані про хворих»C1/Занесення даних4С4/Дані про бригадуУ цьому стані відбувається занесення інформації, а саме : · № Виклику · Дата · АдресаУ цьому переході маємо можливість перейти до іншого стану за допомогою кнопки «Дані про бригаду»C2/ Звіти5С5/Звіт від головного лікаряУ цьому стані ми маємо можливість переглянути звіт від головного лікаря.У цьому переході маємо можливість перейти до іншого стану за допомогою кнопки «Звіт від головного лікаря»C2/ Звіти6С6/Звіт бригадиУ цьому стані ми маємо можливість переглянути звіт бригади.У цьому переході маємо можливість перейти до іншого стану за допомогою кнопки «Звіт бригади»

.1.4 Розробка інтерфейсу

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

Серед основних платформ, які б ми могли використати, можна виділити такі, як Paradox, FoxPro та Microsoft Office Access. Самою доступною та самою розповсюдженою з них є остання. Тому для виконання даної роботи ми будемо використовувати СУБД Access 2007.

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

Таблиця 2.3 - Кнопки форми «Меню»

Назва кнопкиРеакція на натиснення Занесення данихВідкривається форма «Занесення даних»ЗвітиВідкривається форма «Звіти»ВихідВихід з бази даних

В формі «Занесення даних» знаходяться 2 кнопки : «Дані про хворих» та «Дані про бригаду». При натисненні кнопки «Звіти» повинні відкритись форми «Звіт від головного лікаря» та «Звіт бригади».

Якщо натиснути кнопку «Занесення даних» маємо змогу переглянути форми «Дані про хворих» та «Дані про бригаду».

Якщо натиснути кнопку «Дані про хворих» то повинна відкритись форма у якій користувач матиме змогу занести дані про дату, ПІБ та діагноз.

Якщо натиснути кнопку «Дані про бригаду» ми матимемо змогу занести дані про бригаду за критеріями : № виклику, дата, адреса.

Якщо натиснути кнопку «Звіт від головного лікаря » у цьому стані ми матимемо можливість переглянути інформацію від головного лікаря по таким критеріям як ПІБ (хворого), дата, діагноз.

Якщо натиснути кнопку «Звіт бригади» при натисненні на цю кнопку ми матимемо можливість переглянути звіт о роботі яка було виконана бригадою.

. Інтерфейс стану 0

. Інтерфейс стану 1

. Інтерфейс стану 2

4. Інтерфейс стану 3

.2 Технічний проект

.2.1 Діаграма та специфікація класів

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

Рисунок 2.4 - Декомпозиція діаграми потоків даних 1-го рівня.

Таблиця 2.4 - Словник потоків даних декомпозиції діаграми 1-го

Імя потокуСтруктура потокуДані для диспетчераФІО хворого, дата, діагноз.Команди диспетчераДо команд диспетчера належать документи від бригади.Інформація від бригадиІнформація(звіт) від бригади приймається за такими критеріями як: · № Звіту · Дата · Адреса · ДіагнозДані для адміністратораІнформація яка була занесена до БД.Звіт для головного лікаряЛікар отримує звіти які містять у собі такі поля як : · Звіт від бригади · Дата · Діагноз Звіт від головного лікаряГоловний лікар створює звіт за такими критеріями як: Дата ПІБ Діагноз (який було поставлено) Лікування

Отримана діаграма потоків даних 1-го рівня належить ще більшої деталізації.

Результат декомпозиції модуля «Обслуговування диспетчера»

Рисунок 2.5 - Декомпозиція діаграми потоків даних 1-го рівня.

Таблиця 2.5 - Словник потоків даних декомпозиції діаграми 1-го

Імя потокуСтруктура потокуДані адміністратораІнформація яка заповнюється при регістрації користувача у БД.Команди адміністратораЗворотна інформація від БД.Дані для адміністратораІнформація яку було занесено до БД.Дані диспетчераФІО хворого, дата, діагноз.Команди диспетчераДо команд диспетчера належать документи від бригади.

.3 Робочий проект

.3.1 Вибір мови програмування

Доцільним і зручним виявилось створити базу даних у СУБД Microsoft Access 2003, яка пропонує вбудований інструментарій для інтеграції БД з оболонкою програмного забезпечення на мові Visual Basic.

.3.2 Побудова фізичної моделі даних

Дані, по яким необхідно представити фізичну модель даних в СУБД MS Access 2003 на підставі раніше розробленої логічної моделі даних БД «СШМД», представлені в нижче приведених таблицях 2.6 - 2.11.

Таблиця 2.6 - Структура таблиці «Diagnoz» (Діагнози)

Найменування поляЛогічне імяТип данихключKodКод діагнозуintegerPKNameНазва діагнозуVarchar(30)

Таблиця 2.7 - Структура таблиці «Dispetcherska» (Відділ)

Найменування поляЛогічне імяТип данихключKodКод відділуintegerPKNameНазва відділуVarchar(30)КоdКод диспетчераintegerТаблиця 2.8 - Структура таблиці «Dispetcher» (Диспетчер)

Найменування поляЛогічне імяТип данихключKodКод диспетчераintegerPKNameПрізвище диспетчера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Код бригадиintegerPKNameНазва бригадиVarchar(30)

Таблиця 2.10 - Структура таблиці «Viizd» (Виїзд на завдання)

Найменування поляЛогічне імяТип данихключKodКод документуintegerPKNameНазва документуVarchar(30)NomerНомер документуVarchar(30)DataDocДата заповненняDateKod_PersonaКод пацієнтаintegerFKKod_MedocurКод медустановиintegerFKKod_DiagnozКод діагнозуintegerFK

Таблиця 2.11 - Структура таблиці «Patient»(Пацієнти)

Найменування поляЛогічне імяТип данихключKodКод пацієнтаintegerPKNameПрізвище пацієнтаVarchar(30)FirstNameІм'я пацієнтаVarchar(20)SecNameПо-батькові пацієнтаVarchar(20)DataPrivДата народження пацієнтаDateKod_StreetКод вулиціintegerFKDomНомер дому пацієнтаVarchar(10)ApartmentНомер квартири пацієнтаVarchar(10)PolСтать пацієнтаChar(1)U4astokДільниця, де проживає пацієнтsmallintN_PasportНомер паспорта пацієнтаVarchar(10)N_KartaНомер медкартки пацієнтаVarchar(10)N_TelefonНомер телефону пацієнтаVarchar(20)DateViizdДата виїзду на викликdateDateZapovnennaДата заповнення dateMoreInformДодаткова інформаціяVarchar(20)

Фізична модель даних представлена на рисунку 2.6.

Рисунок 2.6 - Фізична модель бази даних

3. Результати розробки

У даній роботі було розроблено програмне забезпечення «ЦШМД» для станцій швидкої медичної допомоги.

Воно виконує наступні функції:

·Ведення інформації про хворих;

·Ведення інформації про бригади;

·Ведення інформації від головного лікаря;

·Пошук хворих;

·Формування звітів від бригад;

Усі заплановані функції було реалізовано.

При реалізації було створено файл БД у СУБД Access з назвою ЦШМД розміром 16 Mb, який містить код на мові програмування Visual Basic та запити на мові SQL загальною кількістю 171 строки.

Вихідні коди програми наведено у додатках Д та Є. Програму та методику випробовувань наведено у додатку Е.

Висновки

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

В результаті проектування програмного забезпечення автор розробив БД з автоматизованою обробкою потоків даних та процесів в ній за допомогою програмних модулів, які вирішують наступні проблеми:

·Зручне занесення інформації про хворих у базу;

·Зручне занесення інформації про бригаду у базу;

·Зручне збереження інформації у цифровому вигляді на ЕОМ;

·Створення зручної форми занесення даних;

·Пошук інформації про хворих;

·Пошук інформацію про виїзд бригад;

·Формування звітів;

·Швидкий доступ до даних;

·Видача необхідної інформації за запитом;

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

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

Список використаної літератури

1.Методичні вказівки до виконання курсового проекту з дисципліни «Технологія розробки і САПР програмного забезпечення».

.ГОСТ 19.102-77. Единая система программной документации. Стадии разработки.

.Конноли Т. Бегг К. Базы данных. Проектирование, реализация и сопровождение. Теория и практика, 3-е издание.

.Грубер М. Введение в SQL.

.Джоуне, Эйри, Свивене,Райан,Кригель,Алекс. Функции SQL.

Додаток А

Технічний проект

. Підстава для розробки.

Умовне позначення програмного виробу:«ЦШМД»

Документ: Завдання на лабораторну роботу

Затвердила: Тудоран В.А

Дата затвердження: 20.09.12.

. Призначення розробки.

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

.1 Функціональне призначення.

Головним призначення даної системи є регулювання відношень диспетчерів з бригадам.

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

.2 Експлуатаційне призначення.

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

. Вимоги до програми чи програмному виробу.

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

.1.1 Вимоги до складу виконуваних функцій.

Система повинна містити модуль по роботі диспетчера.

Модуль по роботі диспетчера, бригади та головного лікаря.

В модулі де буде працювати диспетчер повинно бути реалізовано:

) Створює звіт стосовно виклику

·ПІБ клієнта

·Час прийому виклику

·Адреса

) Передає виклик до бригади

·Час передачі виклику

·Фрагмент карти з адресою виклику (координати)

) Бригада передає звіт після виклику

А)

·Час отримання виклику

·Час прибуття на місце виклику

·Час закінчення роботи на місці

·Пробіг машини за виклик

Б)

·Симптоми які було виявлено у ході обстеження

·Діагноз

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

) Авторизація для персоналу

·П.І.Б.

·Пароль

) Розробка спеціалізованої документації

До розробки документації входять:

·Дата створення документу

·П.І.Б.

·Симптоми при першому огляді

·Діагноз який було поставлено на основі симптомів

·Курс лікування

) Розробка звіту по виклику

·Час та дата отримання виклику

·Час який було затрачено на клієнта

Також додатково у ході розробки системи будуть автоматизовані наступні функції:

·автоматизація роботи в певному регламенті за попередньо відпрацьованими матрицями (таблицями);

·автоматизація роботи на основі алгоритмiзацiї лiкувально-дiагностичного процесу;

·автоматизація компютерної обробки даних та занесення їх до вiдповiдних форм документів.

.2 Вимоги до організації вхідних даних.

Вхідними даними є назва файлу, яку користувач обирає для звіту. Це дані, що вводяться з клавіатури у текстовій формі, та за правилами назва файлу не повинна містити символи: /\ : * ? <>. Вхідні дані повинні бути представлені у виді звітів спеціальної форми.

.3 Вимоги до організації вихідних даних.

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

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

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

Необхідний рівень підготовки користувача: базові навики користування компютером та програмою Microsoft Office Access.

.5 Вимоги до складу та параметрів технічних засобів.

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

Операційна система:Windows XP

Процесор: Pentium

Пам'ять: 512Мб.

Дисковий простір: 20 Гб.

.6 Вимоги до інформаційної та програмної сумісності

.6.1 Вимоги для вихідного коду та язикам програмування

Вихідний код програми повинен бути представлені у вигляді скриптів на мові VBA або SQL запитів.

.6.2 Вимоги до програмного продукту, які використовуються програмою

Єдиним системним програмним засобом, що буде використовувати програма, є операційна система.

Операційна система: Windows XP або вище Microsoft Office Access

.6.3 Вимоги до захисту інформації та програм

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

Всі працівники установи, що є користувачами, взаємодіють з системою на рівні визначених прав доступу. Права доступу визначаються посадовими обов'язками співробітника і задаються системним адміністратором.

Захист підсистеми від несанкціонованого доступу реалізується на двох рівнях - системному рівні і рівні додатка. Системний рівень передбачає можливість входу користувача в підсистему і запуску програм. З достатнім ступенем надійності такий захист реалізований на сервері системи, заснованому на ОС Windows XP. Під час запуску програм відбувається повторна авторизація диспетчера-користувача, причому його ім'я може не збігатися з ім'ям в операційній системі.

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

.7 Вимоги до маркування та пакування

Програма повинна розповсюджуватись на оптичних СD-дисках.

.8 Вимоги до транспортування та зберігання.

Умови експлуатації повинні відповідати Наказу Міністерства труда і соціальної політики України (Комітет з надзору та охороною праці України) від 10.02.1999 №21 «Про затвердження правил охорони праці при експлуатації електронно-обчислювальних машин».

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

Програма має збігатися і транспортуватися як все CD-диски згідно ГОСТ. Не допускати подряпин на боці, з якого буде зчитуватися інформація.

Дана програма встановлюється на жорсткий диск. Для коректної роботи температура в приміщенні повинна бути в межі від +15 до +35 °C, відносна вологість не більше 70%.

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

Повний пакет документів повинен включати:

ØОпис програми;

ØТекст програми;

ØПрограма і методика випробувань;

ØПосібник користувача;

.10 Техніко-економічні показники

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

4. Стадії і етапи розробки

Таблиця 1 Стадії та етапи розробки.

СтадіяЕтапСтрокиЕскізний проектПрийняття принципових рішень по структурі програмного продукту, усім видам забезпечення, попередній розрахунок економічної ефективності та технічних показників продукту:Початок: Завершення:Технічний проектВибір інструменту мови кодування. Формування програмного продукту в цілому. Розробка документації.Початок: Завершення:Робочий проектВиготовлення та налагодження компонентів програмного продукту. Заплановані строки початку та завершення. Початок: Завершення:Введення в лініюДослідне функціонування програмного продукту з метою перевірки працездатності, визначення дійсних техніко-економічних показників, корегування документації.Початок: Завершення:

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

Додаток Б

програма швидкий допомога автоматизація

Опис програмного забезпечення

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

Розроблена автоматизована система призначена для центрів швидкої медичної допомоги.

Вона націлена на:

·Уникнення неефективного витрачення робочого часу працівників в звязку з виконанням рутинних операцій по пошуку

·Редагуванню інформації кожного обєкту у базі

·Ризику втрати цінної інформації

. Функціональне призначення

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

3. Опис логічної структури

За логічною структурою програма може бути поділена на такі модулі:

·Ведення інформації про хворих

·Ведення інформації про бригади

. Використані технічні засоби

При розробці даної системи були використані наступні технічні засоби:

·Процесор Intel Pentium 4 2.53 GHz;

·Графічний адаптер NVIDIA GeForce 5700 Ultra;

·ОЗП: 2 Гб;

·50 мб дискового простору

·Маніпулятор миша та клавіатура

. Запуск

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

Щоб відкрити програму, треба натиснути 2 рази на ліву кнопку миші на файлі CFMR.mdb.

. Вхідні дані

Вхідними даними є дані про хворих (ПІБ, Дата народження, адреса, номер телефону,діагноз), дані про бригаду (Адреса, дата, час, № бригади), що вводить користувач.

. Вихідні дані

Вихідними даними є дані про хворих (ПІБ, Дата народження, адреса, номер телефону,діагноз), дані про бригаду (Адреса, дата, час, № бригади), що виводяться з БД на екран.

Додаток В

Опис застосування

. Призначення програми

Розроблена автоматизована система призначена для центрів швидкої медичної допомоги.

Вона націлена на:

·Уникнення неефективного витрачення робочого часу працівників в звязку з виконанням рутинних операцій по пошуку

·Редагуванню інформації кожного обєкту у базі

·Ризику втрати цінної інформації

. Умови використання

Для коректної роботи програми необхідний персональний компютер, що відповідає наступним апаратним вимогам:

·Процесор: Pentium III 800Hz

·Пам'ять 256 Mb

·Дисковий простір: 20 Mb + необхідний простір для зберігання файлу БД.

·Операційна система:Windows 98/XP/Vista/7

. Опис задачі

Дана програма призначена для введення центром швидкої медичної допомоги звітів бригад та картки хворих.

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

·Ведення інформації про хворих(здійснення зміни або занесення до БД інформацію про хворих).

·Ведення інформації про бригади (здійснення зміни або занесення до БД інформації про бригади).

·Пошук інформацію про хворих (здійснення вводу інформації, за якою відбуватиметься пошук БД)

. Вхідні та вихідні дані

Вхідними даними є дані про хворих (ПІБ, Дата народження, адреса, номер телефону,діагноз), дані про бригаду (Адреса, дата, час, № бригади), що вводить користувач.

Вихідні дані

Вихідними даними є дані про хворих (ПІБ, Дата народження, адреса, номер телефону,діагноз), дані про бригаду (Адреса, дата, час, № бригади), що виводяться з БД на екран.

Додаток Г

Інструкція користувача

Програмне забезпечення «ЦШМД» використовується для ведення центром швидкої медичної допомоги карток клієнтів, звітів від бригад.

Кінцевим користувачем програми може бути будь-яка людина, що володіє базовими знаннями ПК: знає основи Windows XP, вміє встановлювати та запускати програми на компютер.

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

. Загальні відомості про програму.

Назва програми: програмне забезпечення «ЦШМД»

Функціональне призначення: ведення центром швидкої допомоги обліку карток хворих та звітів від бригад.

Програмне забезпечення, необхідне для функціонування програми: ОС Windows, Access 2003 або вище.

. Вхідні дані

Вхідними даними є дані про хворих (ПІБ, Дата народження, адреса, номер телефону,діагноз), дані про бригаду (Адреса, дата, час, № бригади), що вводить користувач.

Вихідні дані

. Вихідними даними

Вихідними даними є дані про хворих (ПІБ, Дата народження, адреса, номер телефону,діагноз), дані про бригаду (Адреса, дата, час, № бригади), що виводяться з БД на екран.

4. Робота з програмою

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

Щоб її відкрити, треба натиснути 2 рази ліву кнопку на миші на файлі «ReportsInfo.mdb» у результаті відкриється вікно з головною формою.

Додаток Д - Текст програми

Для того щоб виконати перевірку чи є заповнення деякого рядку можна скористатися цим кодом:

(me.Поле_Имя.Value = "")"Сначала введите имя".Undo

абоSub MyName_Change()(Len(Me.MyName.Text) > 0) Then.MyNameSecond.Locked = False.MyNameSecond.Locked = True.MyNameSecond.Text = ""IfSub

Форма:Compare Database

Private Sub Êíîïêà6_Click()Error GoTo Err_Êíîïêà6_Click.GoToRecord,, acNewRec

Exit_Êíîïêà6_Click:Sub

Err_Êíîïêà6_Click:Err.Description

Resume Exit_Êíîïêà6_Click Sub

Форма 1:Compare Database

Private Sub Êíîïêà6_Click()Error GoTo Err_Êíîïêà6_Click.Close

Exit_Êíîïêà6_Click:Sub

Err_Êíîïêà6_Click:Err.Description

Resume Exit_Êíîïêà6_Click

End Sub

справочник:Compare DatabaseSub Form_Load()Sub

Private Sub Êíîïêà5_Click()Error GoTo Err_Êíîïêà5_Click.GoToRecord,, acNewRec

Exit_Êíîïêà5_Click:Sub

Err_Êíîïêà5_Click:Err.Description

Resume Exit_Êíîïêà5_Click SubCompare Database

Private Sub Êíîïêà3_Click()Error GoTo Err_Êíîïêà3_Click.Close

Exit_Êíîïêà3_Click:Sub

Err_Êíîïêà3_Click:Err.Description

Resume Exit_Êíîïêà3_Click

End Sub

Справочник:Compare DatabaseSub Form_Load()Sub

Private Sub Êíîïêà9_Click()Error GoTo Err_Êíîïêà9_Click.GoToRecord,, acNewRec

Exit_Êíîïêà9_Click:Sub

Err_Êíîïêà9_Click:Err.Description

Resume Exit_Êíîïêà9_Click SubCompare Database

Private Sub Êíîïêà13_Click()Error GoTo Err_Êíîïêà13_Click.GoToRecord,, acNewRec

Exit_Êíîïêà13_Click:Sub

Err_Êíîïêà13_Click:Err.Description

Resume Exit_Êíîïêà13_Click Sub

Кнопка6:

Private Sub Êíîïêà6_Click()

On Error GoTo Err_Êíîïêà6_Click.GoToRecord,, acNewRec

Exit_Êíîïêà6_Click:Sub

Err_Êíîïêà6_Click:Err.Description

Resume Exit_Êíîïêà6_Click

Кнопка 7:

Private Sub Êíîïêà7_Click()Error GoTo Err_Êíîïêà7_Click.DoMenuItem acFormBar, acEditMenu, 8,, acMenuVer70.DoMenuItem acFormBar, acEditMenu, 6,, acMenuVer70

Exit_Êíîïêà7_Click:Sub

Err_Êíîïêà7_Click:Err.Description

Resume Exit_Êíîïêà7_Click

End Sub

Кнопка 8:Sub Êíîïêà8_Click()Error GoTo Err_Êíîïêà8_Click.Close

Exit_Êíîïêà8_Click:Sub

Err_Êíîïêà8_Click:Err.Description

Resume Exit_Êíîïêà8_Click

End Sub

Додаток Є

Програма і методика випробувань

При проведенні випробувань функціональні характеристики програми підлягають перевірці на відповідність вимогам, перерахованим у пункті 3.1 «Вимоги до функціональних характеристик» технічного завдання.

. Обєктом випробування

Обєктом випробування є програмне забезпечення для центрів медичної допомоги.

. Мета випробувань

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

. Вимоги до програми

Вимоги до програми наведені у технічному завданні (Додаток 1)

. Засоби та порядок випробувань

.1 Технічні засоби

·Процесор Intel Pentium 4 2.53 GHz;

·Графічний адаптер NVIDIA GeForce 5700 Ultra;

·ОЗП: 2 Гб;

·Монітор 19 WXGA;

·50 мб дискового простору;

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

.2 Програмні засоби

·Операційна система: Windows XP

·Microsoft Access 2003

.3 Порядок випробовувань

Запустити виконавчий файл програми «CFMR.mdb». Випробування відбуваються з чітким дотриманням інструкції користувача, викладеної у додатку Г.

Методи випробувань

При занесенні інформації до групи товарів, користувач буде повинен заповнити наступні поля після чого інформація буду занесена до БД. (Рисунок 1)

Рисунок 1 - Занесення інформації про хворих

При занесенні інформації до групи товарів, користувач буде повинен заповнити наступні поля після чого інформація буду занесена до БД. (Рисунок 2)

Рисунок 2 - Занесення інформації від головного лікаря

Для виконання пошуку по БД користувач матиме змогу скористуватися формами для пошуку по № виклику або адресою. (Рисунок 3)

Рисунок 3 - Занесення інформації про бригаду

При занесенні інформації від бригади, користувач повинен буде заповнити наступні поля після чого інформація буду занесена до БД. (Рисунок 4)

Рисунок 4 - Занесення інформації від бригади

Зміст Вступ . Аналіз предметної області .1 Постановка задачі . Проект програмного забезпечення .1 Ескізний проект .1.1 Контекстна діаграма

Больше работ по теме: