Разработка программы автоматизации регистратуры поликлиники

 

1.5 Тестирование программного продукта

 

Тестирование программного продукта— процесс исследования программного продукта (ПО) с целью получения информации о качестве продукта.

Виды тестирования

Модульное тестирование (юнит-тестирование) — тестируется минимально возможный для тестирования компонент, например, отдельный класс или функция. Часто модульное тестирование осуществляется разработчиками ПО.

Интеграционное тестирование — тестируются интерфейсы между компонентами, подсистемами. При наличии резерва времени на данной стадии тестирование ведётся итерационно, с постепенным подключением последующих подсистем.

Системное тестирование — тестируется интегрированная система на её соответствие требованиям.

Альфа-тестирование — имитация реальной работы с системой штатными разработчиками, либо реальная работа с системой потенциальными пользователями/заказчиком. Чаще всего альфа-тестирование проводится на ранней стадии разработки продукта, но в некоторых случаях может применяться для законченного продукта в качестве внутреннего приёмочного тестирования.

 Иногда альфа-тестирование  выполняется под отладчиком или  с использованием окружения, которое помогает быстро выявлять найденные ошибки. Обнаруженные ошибки могут быть переданы тестерами для дополнительного исследования в окружении, подобном тому, в котором будет использоваться ПО.

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

Часто для свободного/открытого  ПО стадия альфа - тестирования, характеризует функциональное наполнение кода, а бета - тестирования — стадию исправления ошибок. При этом, как правило, на каждом этапе разработки промежуточные результаты работы доступны конечным пользователям.

 

 ГЛАВА II. ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММЫ АВТОМАТИЗАЦИИ РАБОЧЕГО МЕСТА РГИСТРАТУРЫ ПОЛИКЛИНИКИ

 

2.1. Анализ требований заказчика к программе

 

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

В соответствии с техническим заданием были определены основные требования и методы реализации этих требований.

Основные требования к программе:

1. Разработка единого интерфейса работника  регистратуры поликлиники;
2. Заполнение сведений о пациентах, специалистам, их расписании;
3. Возможность записывать пациентов на прием;
4. Возможность фиксировать принятых пациентов;
5. Печать квитанций о каждом приеме и назначиваемых мерах;
6. Печать отчетов по каждому пациенту, специалисту и т.д.

— анализ.

На этапе  анализа были проведены:

• Анализ предметной области, где были выявлены необходимые функции для работы регистратуры поликлиники.
• Анализ аналогов, где были проанализированы достоинства и недостатки продуктов, применяемых в данной предметной области. Примеры интерфейса и определение базовых функций, которые должна выполнять программа.

Так же были выявлены требования к системным  требованиям программы. Данная программа должна быть:

• Совместима с операционными системами Windows XP, Vista,7;
• Использовать не более 512 МБ оперативной памяти, занимать не более 10Мб свободного места на жестком диске, процессор 1,6 Гц;

 

2.2 Описание структуры БД

 

В программе автоматизация  салона регистатуры поликлиники используется база данных созданная в MS Access, состоящая из следующих таблиц:

Пациенты, в таблице хранятся все данные о пациентах, по которым можно его легко идентифицировать. Так же можно определить некоторые особенности этого пациента.

Наименование  атрибута	Тип данных	Назначение
ID	счетчик	Идентификатор пациента
ФИО	текстовый	Фамилия, имя  и отчество пациента
Дата рождения	Дата/время	Дата рождения пациента
Страховой полис	текстовый	Серия и  номер  страхового плиса
Адрес	Текстовый	Адрес пациента
Участок	Числовой	Участок к которому прикреплен пациент

 

Врачи, в данной таблице хранятся данные о врачах необходимые для установления связи с ними.

Наименование  атрибута	Тип данных	Назначение
ID	счетчик	Идентификатор врача
Фамилия	текстовый	Фамилия врача
Имя	текстовый	Имя врача
Отчество	текстовый	Отчество врача
Специальность	Текстовый	Специальность врача
Место работы	Текстовый	Отделение, в  котором работает врач
Кабинет	Числовой	Номер кабинета врача

 

Расписание, таблица, в которой находятся сведения о расписании врачей.

Наименование  атрибута	Тип данных	Назначение
ID	Числовой	Идентификатор врача
День	Текстовый	День недели приема
Начало приема	Время	Начало приема
Конец приема	время	Конец приема

 

Носители, в данной таблице  находятся данные необходимые для  определение стоимость видеопроката.

Наименование  атрибута	Тип данных	Назначение
ID	счетчик	Идентификатор носителя
Название	текстовый	Название носителя
Цена	числовой	Цена за 1 день проката

 

Приемы, таблица для хранения всех сведений о приемах, кто и когда и кем был принят .

Наименование  атрибута	Тип данных	назначение
ID	счетчик	Идентификатор приема
Пациент	текстовый	Пациент, назначенный на прием
Врач	текстовый	Принимающий врач
Дата приема	Дата	Дата, когда приняли пациента
Причина	Текстовый	Причина, по которой  назначен прием
статус	Логический	Принят/не принят

 

Истории, таблица со сведениями о  всех приемах и их результатов

Наименование  атрибута	Тип данных	назначение
ID	счетчик	Идентификатор истории
Пациент	текстовый	Пациент, прошедший  прием
Врач	текстовый	Принимавший врач
Дата приема	Дата	Дата, когда приняли пациента
диагноз	Текстовый	Поставленный  диагноз
примечание	Мемо	Необходимые замечания

 

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

Схему взаимодействия данных можно показать следующей ER-диаграммой:

 

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

Так же показаны отношения  с поставщиками, где сразу фиксируется  какие фильмы поставил поставщик.

 

2.3 Разработка интерфейса программы

 

Пользовательский интерфейс  соответствует стандартному Windows-приложению.

Каждая форма выполняет  определенные функции: заполнение карточек пациентов, врачей, приемов и историй болезни,  печать отчетов.

Главная форма программы выглядит так::

 

 

На этой форме вынесены ссылки на все необходимые для  работы справочники, далее справочники будут показаны более подробно.

Справочник Доктора выглядит следующим образом

При нажатии на кнопки добавляются и удаляются сведения о специалистах клиники. Так же можно добавлять расписания с последующим его распечатыванием.

Одной из самых важных форм является форма фиксирования записи на прием, на этой форме необходимо выбрать пациента и специалиста, к которому вы хотите его записать на прием. Так же существует функция ближайшая дата, которая записывает пациента на самый ближайший день приема

 

.И в завершении форма приема пациентов, на ней показана очередь из еще не принятых пациентов, при нажатии клавиши «Принять», появляется меню в котором необходимо внести данные о приеме.

 

2.4 Разработка программного кода

 

Самыми выдающимися частями  кода можно назвать: просмотр сведении о пациенте, запись на прием и печать отчета

Просмотр сведений

panel2.Visible:=true;

a:='пациент';

b:=adotable1.fieldbyname('Фамилия_Имя_Отчество').AsString;

ADOQuery1.close;

ADOQuery1.SQL.Clear;

ADOQuery1.SQL.text:='Select [Hystory].* from [Hystory] where [Hystory].'+a+'='+#39+b+#39;

ADOQuery1.open;

в данном алгоритме можно  выявить следующие моменты:

Открывается панель на которой  показаны сведения о диагнозах пациентов, на которой происходит выборка из таблицы пациентов

Запись на прием:

dayp:= adotable1.fieldbyname('день').AsString;

myDate :=date+1;

  myDate := IncDay(myDate,-1);

  day := LongDayNames[DayOfWeek(myDate)];

if day=dayp then begin

d:=myDate;

label5.Caption:=datetostr(d);

end

else

for i:= 1 to 7 do

begin

myDate :=myDate+1;

myDate := IncDay(myDate,-1);

  day := LongDayNames[DayOfWeek(myDate)];

   if day=dayp then d:=myDate;

if day=dayp then label5.Caption:=datetostr(mydate);

 myDate :=myDate+1

 

begin

   adotable2.Insert;

   adotable2.FieldByName('врач').AsString:=adotable1.FieldByName('врач').AsString;

   adotable2.FieldByName('пациент').AsString:=form4.ADOTable1.fieldbyname('Фамилия_Имя_Отчество').AsString;

   adotable2.FieldByName('дата').AsDateTime:=strtodate(label5.caption);

   adotable2.FieldByName('принят').AsString:='нет';

   adotable2.FieldByName('причина').AsString:=edit3.text;

   if edit3.Text='' then showmessage('введите причину') else adotable2.Post;

   end;

form5.Close;

end;

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

Алгоритм печати:

  AppProgID:='Word.Application';

ServerIsRunning:= False;

Result:= GetActiveObject(ProgIDToClassID(AppProgID),nil,Unknown);

if (Result=MK_E_UNAVAILABLE) then

App:= CreateOleObject(AppProgID)//создать  сервер

else

begin // с существующей копией  сервера

App:=GetActiveOleObject(AppProgID);

ServerIsRunning:=true;

end;

App.Visible:=True;

name:=adotable1.fieldbyname('Фамилия_Имя_отчество').AsString;

    app.Documents.Add();

  Rng:= App.ActiveDocument.Paragraphs.Item(1).Range;

  sel:=App.Selection;

  sel.font.size:=14;

  sel.font.bold:=true;

  sel.TypeText('Пациент:  '+ name+ ':  история болезни');

  Rng.InsertParagraphAfter;

  Rng:= App.ActiveDocument.Paragraphs.Item(2).Range;

   Rng.InsertParagraphAfter;

  Rng.InsertAfter('врач, дата приема, диагноз, примечания');

  Rng.InsertParagraphAfter;

  sel.font.bold:=false;

  n:=adoquery1.RecordCount;

  adoquery1.First;

  for i:= 1 to n do

  begin

    vr:=adoquery1.fieldbyname('врач').asstring;

    dia:=adoquery1.fieldbyname('диагноз').asstring;;

    data:=adoquery1.fieldbyname('дата  приема').asstring;;

    prim:=adoquery1.fieldbyname('примечания').asstring;;

     Rng.InsertParagraphAfter;

     Rng.InsertAfter(vr+','+data+','+dia+','+prim);

   adoquery1.Next;

  end;

Печать организована посредством связи с MS Word, все данные экспортируются при связи с сервером,  сама печать происходит средствами Word.

 

 

СПИСОК  ЛИТЕРАТУРЫ

 

1. Тельнов Ю.Т Реинжиниринг бизнес процессов / Москва. «Финансы и Статистика» 2004.
2. Калашян А.Н.,Калясов Г.Н Структурное моделирование бизнеса: DFD-технология/ Москва. «Финансы и Статистика» 2001.
3. Фаронов , Delphi 7. Программирование баз данных.
4. Дарахвелидзе П., Марков Е. Программирование в Delphi 7/Санкт-Петербург «БХВ-Петербург 2003;
5. Филонович С.Р., Использование моделей жизненного цикла в организации и диагностике /Москва 2005;
6. Батлер Э.,  Microsoft Office Access 2007: профессиональное программирование / Вильямс 2009;
7. Кириллов В.В., Громов Г.Ю., Введение в реляционные базы данных /Москва BHV 2009;
8. Автоматизированное рабочее место в системе управления предприятием, Сборник научных трудов, СПб, 2002 г;
9. Гофман В., Хомоненко А., Работа с базами данных в Delphi/ Санкт-Петербург «БХВ-Петербург 2003;
10. Коннолли Т., Бегг К., Базы данных. Проектирование, реализация и сопровождение / Москва, Санкт-Петербург, Киев 2003;
11. Кантарь И.Л.. Автоматизированные рабочие места управленческого аппарата, 1990.
12. Рапопорт Э.Я. Структурное моделирование объектов и систем управления. М: финансы и статистика,  2003 г.