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

Подробности

Опубликовано: 10.07.2018 11:29

Автор: Орешкина Анна Михайловна

Просмотров: 11411

Аннотация: в работе реализуется приложение в среде MS Access для автоматизации работы городской больницы. Описываются возможные способы сбора требований, анализируются пользовательские требования, на основе которых составляются функциональные требования и матрица отслеживания. Приводится обоснование выбранных способов проектирования, описываются ключевые бизнес-процессы, строится архитектура данных разрабатываемой программы и пользовательские интерфейсы. Рассматриваются методы разработки, а также копии экранов разработанной программы с указанием порядка обработки данных для ключевых бизнес-процессов. Дается описание трёх видов тестирования для проверки работоспособности программ, а также экономическая целесообразность. В заключении подводятся итоги проделанной работы.
Скачать: PDF, PPT.
Ключевые слова: автоматизация торговой деятельности, автоматизация бизнес процессов дипломная, автоматизация предприятия пример, CASE средства проектирования информационных систем, ARIS методология, uml class diagram, декомпозиция бизнес-процессов пример, этапы тестирования, нефункциональное тестирование, стрессовое тестирование программного обеспечения.

Аннотация

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

В главе «Проектирование приложения» приводится обоснование выбранных способов проектирования, описываются ключевые бизнес-процессы, строится архитектура данных разрабатываемой программы и пользовательские интерфейсы. В главе «Разработка программы» описываются методы разработки, а также приводятся копии экранов разработанной программы с указанием порядка обработки данных для ключевых бизнес-процессов. В главе «Тестирование разработанного приложения» приводится описание трёх видов тестирования для проверки работоспособности программы, а также экономическая целесообразность работы. В «Заключении» подводятся итоги работы, а в «Списке литературы» – список использованных печатных источников и интернет ресурсов. 

Введение

В последнее время всё больше и больше медицинских учреждений подвергаются объединению. Реформы здравоохранения нацелены на централизацию медучреждений и создание единых крупных административно-экономических механизмов управления. В связи с этим, администрация тех больниц и клиник, к которым присоединяют другие лечебные заведения, сталкивается с серьёзной проблемой: объединение данных и создание общей базы пациентов. Данная проблема осложняется тем, что подавляющее большинство учреждений в качестве базы данных использует либо свои собственные программы, либо таблицы MS Excel. Несомненно, для маленьких и отдалённых больниц подобное ведение дел может быть вполне приемлемым. Но для крупных центров – категорически нет. Это обусловлено следующими факторами: 

• затруднённый поиск информации о пациенте;
• невозможность вывода на экран информации только по 1 искомому пациенту (обилие прочих данных повышает вероятность ошибиться, особенно во время экстренных ситуаций);
• высокая вероятность ошибиться и занести данные по одному пациенту в графу к другому.

Для создания приложения по автоматизации работы более крупных медицинских учреждений целесообразным будет использование системы управления базами данных (СУБД), например, Microsoft (MS) Access. Преимущества данной системы заключаются в следующем: 

• простота освоения и возможность использования непрофессиональным программистом (в большинстве случаев базу данных заполняет медицинский персонал);
• возможность работы как на автономном компьютере, так и в локальной сети;
• работа под управлением операционной системы (ОС) Microsoft Windows, которая установлена во всех медучреждениях;
• возможен импорт файлов из MS Excel.

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

• проанализированы требования, предъявляемые к приложению;
• спроектирована структура программного приложения;
• разработана программа в среде MS Access;
• тестирование разработанного приложения. 

Глава 1. Анализ требований

Анализ требований – это важнейшая часть процесса разработки программного обеспечения (ПО), которая задаёт вектор всей остальной работе. Она включает в себя следующие подпроцессы: 

• сбор требований к разрабатываемому ПО;
• систематизацию выявленных требований;
• поиск взаимосвязей и их рационализация;
• документирование полученной информации.

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

• документируемость (в письменном и/или электронном виде);
• выполнимость;
• тестируемость;
• достаточный (для текущего проекта) уровень детализации.

Анализ требований – это достаточно длительный и трудоёмкий процесс, который состоит из трёх основных этапов: 

• сбор информации:
• общение с заказчиком и конечным пользователем;
• изучение предметной области;
• анализ собранной информации:
• систематизация информации;
• поиск противоречий и неточностей;
• в случае наличия данных проблем, их решение;
• поиск взаимосвязей;
• документирование информации (описание, сценарии, спецификация процессов и т.д.).

Основная задача анализа требований – это получение списка не дублируемых требований к разрабатываемому ПО [1]. Корректная группировка требований позволит определить минимальное и достаточное количество необходимых функций, которые в свою очередь смогут удовлетворить максимально большое количество целей. Таким образом, грамотный подход к этой задаче поможет обозначить чёткие рамки проекта, что сэкономит бюджет и облегчит процесс разработки ПО.  

1.1. Способы анализа требований

Во время подготовки данной работы для наиболее полного сбора и анализа всех возможных требований следовало воспользоваться пятью способами, описанными далее. Опрос – это один из самых часто используемых методов получения информации. Суть данного метода заключается в том, что респонденту (опрашиваемому) задают заранее подготовленные вопросы, ответы на которые позволяют исследователю получить необходимые данные [2]. Опросы бывают следующих видов: 

• анкетирование;
• метод лестницы;
• свободный;
• устный;
• письменный;
• стандартизированный.

Также опросы можно разделить по способу взаимодействия исследователя с респондентом: 

• личный (прямой контакт);
• дистанционный (опрос по телефону, по сети Интернет и т.д.).

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

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

Понятие «документооборот» определяется как «движение документов в организации с момента их создания или получения до завершения исполнения или отправки» [3]. Понятие «электронный документооборот» определяется как «документооборот с использованием автоматизированной информационной системы (системы электронного документооборота)». Следовательно, анализ электронного и/или обычного документооборота поможет узнать степень загруженности как отдельных сотрудников, так и организационно-методического отдела в целом, а также наметить основные направления рационализации документооборота, что, несомненно, окажется полезным при разработке нового ПО. Управленческую документацию принято подразделять на три основных блока, которые указаны на рисунке 1.1. Основные цели создания управленческой документации: 

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

Рис. 1.1. Структура управленческой документации

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

Разработчик ПО во время анализа требований, разумеется, может опираться также и на свой собственный опыт, полученный во время работы. Вероятно, некоторые требования не будут названы ни заказчиком, ни конечным пользователем, но всё равно должны быть учтены при создании новой программы. Также при возникновении спорных ситуаций между заказчиком и пользователем решить их разработчик сможет, опираясь только на собственный опыт. В доступе к управленческой документации было отказано. Следовательно, и анализ документооборота был невозможен. Также было запрещено наблюдение за выполнением операций. Данные запреты обусловлены пунктом 1 статьи 13 главы 2 Федерального закона РФ [4]. В связи с этим остаются доступными только два способа анализа требований к разрабатываемому ПО: проведение опроса, использование знаний. 

1.2. Пользовательские требования

Пользовательские требования – это требования, описывающие задачи, которые должны выполняться пользователями при помощи разрабатываемого ПО. При проведении свободного, устного, личного опроса были зафиксированы следующие требования: 

• база данных (БД) должна хранить данные:
• о пациенте (ФИО, дата рождения, возраст, пол, вес, контрольная группа);
• об анамнезе пациента (сопутствующие заболевания сердечно-сосудистой системы (ССС), сопутствующие заболевания дыхательной системы (дых.), прочие сопутствующие заболевания, номер класса по шкале American Association of Anaesthetists (шкала ASA применяется для оценки степени операционно-анестезиологического риска, оценивающая физическое состояние пациента);
• об операции (поставленный диагноз, по которому проводилась операция, дата проведения операции, длительность операции, длительность анестезии, ФИО хирурга, проводившего операцию);
• о контроле состояния пациента во время операции (систолическое (сист.) артериальное давление, диастолическое (диаст.) артериальное давление, среднее (средн.) артериальное давление, частота сердечных сокращений (ЧСС), степень насыщения крови кислородом (SpO2), номер контроля (за операцию их в среднем проводится три: в начале (до вмешательства), в середине (в процессе инвазивного вмешательства) и в конце);
• о реабилитации пациента после операции (время пробуждения (после общего наркоза), время экстубации (извлечение интубационной трубки после наркоза, при восстановлении самостоятельного адекватного дыхания больного), время ориентации (приход пациента в сознание), время перевода в палату (перевод из реанимации в обычную палату);
• вывод данных на экран для ознакомления:
• полный анамнез зарегистрированного пациента;
• полная информация о зарегистрированном пациенте;
• выборочная информация о зарегистрированном пациенте:
  • ФИО – дата рождения;
  • ФИО – сопутствующие заболевания;
  • ФИО – дата операции;
  • ФИО – состояние во время операции;
• список ФИО пациентов по:
  • году рождения;
  • сопутствующему(им) заболеванию(ям) ССС;
  • сопутствующему(им) заболеванию(ям) дых.;
  • прочим сопутствующему(им) заболеванию(ям);
  • ФИО хирурга;
  • дате операции (по конкретному дню);
  • дате операции (по конкретному месяцу);
  • длительности операции;
• список с полной информацией о пациентах из выбранной контрольной группы.

Также необходимо включить следующие три требования: 

• возможность вносить данные:
  • регистрация нового пациента;
  • изменение и/или добавление данных об уже зарегистрированном пациенте;
• возможность удалять данные:
  • выборочно удалять ошибочно введённые или неактуальные данные об уже зарегистрированном пациенте;
  • полностью удалять данные о пациенте;
• возможность работы с приложением на любом компьютере медицинского учреждения;
• обеспечение лёгкости работы с приложением для всего медицинского персонала учреждения;
• возможность вывода информации на бумажный носитель;
• хранение информации.

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

1.3. Функциональные требования

Функциональные требования – это требования, объясняющие, что должно быть в разрабатываемом ПО, а также какие действия должны выполняться системой. Значит, пользовательские требования будут иметь следующий вид: 

• БД должна содержать таблицы:
  • «Пациент», куда входит информация о ФИО больного, его дате рождения, возрасте, поле, весе и контрольной группе;
  • «Анамнез», куда входит информация о наличии или отсутствии сопутствующих заболеваний ССС, дых. и проч., а также значение класса по шкале ASA;
  • «Операция», куда входит информация о поставленном диагнозе, дате проведения операции, длительности операции и анестезии, а также ФИО хирурга;
  • «Контроль», куда входит информация о артериальном давлении (сист., диаст. и средн.), ЧСС, SpO2 и номер контроля;
  • «Реабилитация», куда входит информация о времени пробуждения, экстубации, ориентации и перевода в палату;
• вывод на экран данных:
  • ФИО из таблицы «Пациент» и все данные из таблицы «Анамнез»;
  • всех заполненных ранее полей из таблиц «Пациент», «Анамнез», «Операция», «Контроль» и «Реабилитация»;
  • поля «Фамилия», «Имя», «Отчество», «Дата рождения» из таблицы «Пациент»;
  • таблицы «Пациент» (поля «Фамилия», «Имя», «Отчество») и «Анамнез» (поля «Сопутствующие заболевания (ССС)», «Сопутствующие заболевания (дых.)», «Сопутствующие заболевания (проч.)»);
  • таблицы «Пациент» (поля «Фамилия», «Имя», «Отчество») и «Операция» (поле «Дата операции»);
  • таблицы «Пациент» (поля «Фамилия», «Имя», «Отчество») и все данные таблицы «Контроль»;
  • список с полями «Фамилия», «Имя», «Отчество» из таблицы «Пациент» с одинаковым значением года рождения в поле «Дата рождения»;
  • список с полями «Фамилия», «Имя», «Отчество» из таблицы «Пациент» с одинаковым значением в поле «Сопутствующие заболевания (ССС)» из таблицы «Анамнез»;
  • список с полями «Фамилия», «Имя», «Отчество» из таблицы «Пациент» с одинаковым значением в поле «Сопутствующие заболевания (дых.)» из таблицы «Анамнез»;
  • список с полями «Фамилия», «Имя», «Отчество» из таблицы «Пациент» с одинаковым значением в поле «Сопутствующие заболевания (проч.)» из таблицы «Анамнез»;
  • список с полями «Фамилия», «Имя», «Отчество» из таблицы «Пациент» с одинаковым значением в поле «ФИО хирурга» из таблицы «Операция»;
  • список с полями «Фамилия», «Имя», «Отчество» из таблицы «Пациент» с одинаковым значением дня в поле «Дата операции» из таблицы «Операция»;
  • список с полями «Фамилия», «Имя», «Отчество» из таблицы «Пациент» с одинаковым значением месяца в поле «Дата операции» из таблицы «Операция»;
  • список с полями «Фамилия», «Имя», «Отчество» из таблицы «Пациент» с одинаковым значением в поле «Длительность операции» из таблицы «Операция;
  • все имеющиеся данные тех зарегистрированных пациентов, у которых стоит выбранное одинаковое значение в поле «Контрольная группа» из таблицы «Пациент»;
• на экран выводится окно с анкетой пациента, в которой можно ввести данные о новом пациенте или отредактировать данные о зарегистрированном ранее больном;
• есть возможность удалить частично или полностью данные о зарегистрированном пациенте;
• программа должна корректно работать на всех компьютерах медучреждения;
• программа должна быть интуитивно понятна всему медперсоналу;
• любая хранящаяся в приложении информация должна иметь возможность вывода при помощи принтера;
• данные хранятся непосредственно в создаваемом приложении. 

1.4. Матрица отслеживания требований

Матрица отслеживания требований — это таблица, которая связывает требования к разрабатываемому продукту. Иными словами, в ней сопоставляются требования пользовательские и функциональные, а также описывается программный компонент будущей системы, которым будет покрываться каждое из требований. Составление и применение данной матрицы облегчает отслеживание требований на протяжении всего жизненного цикла проекта, что помогает удостовериться в том, что одобренные требования выполнены в конце проекта. Матрица отслеживания требований разрабатываемого приложения для автоматизации городской больницы представлена в таблице 1.1.

Таблица 1.1. Матрица отслеживания требований 

Глава 2. Проектирование приложения

Проектирование – это процесс, в результате которого составляются описания нового или модернизируемого технического объекта, необходимые и достаточные для создания объекта в заданных условиях. Проектирование СУБД – это определение архитектуры, а также компонентов, интерфейсов и других характеристик системы или её части. Основные задачи данного процесса: 

• обеспечение хранения в СУБД всей необходимой информации;
• обеспечение возможности получения данных по всем заявленным заказчиком и/или пользователем запросам;
• сокращение избыточности и дублирования данных (нормализация);
• обеспечение целостности базы данных.

Этап проектирования – это условно выделенная часть процесса проектирования, которая сводится к выполнению одной или нескольких процедур. Процедуры объединяются или же разбиваются в зависимости от того, к какому иерархическому уровню и/или аспекту описания относятся получаемые при их выполнении проектные решения. Проектирование СУБД принято разделять на три этапа: 

• концептуальное проектирование, данный этап заключается в построении семантической модели предметной области. Она имеет самый высокий уровень абстракции;
• логическое проектирование, второй этап включает в себя создание схемы на основе конкретной модели данных. Для реляционной модели данных логическая модель – это набор схем отношений с указанием первичных ключей, а также «связей» между отношениями, представляющих собой внешние ключи;
• физическое проектирование, на последнем этапе создаётся схема для конкретной СУБД (MS Access в данном случае). Специфика выбранной СУБД может включать в себя, например, ограничения на именование объектов или на поддерживаемые типы данных. Также данный подэтап включает в себя выбор решений касательно физической среды хранения данных (например, разделение по файлам и устройствам), создание индексов и прочее. 

2.1. Способы проектирования

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

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

Также важно отметить, что модели бизнес-процессов – это не промежуточный результат, который используется для написания каких-либо рекомендаций и заключений. Это самостоятельный имеющий важное практическое значение результат. Модель должна показывать наглядные ответы на следующие вопросы: 

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

Одной из методологий бизнес-моделирования, получившей широкое распространение в РФ, является методология Architecture of Integrated Information Systems (ARIS) [5], которая была разработана профессором компании IDS Scheer AG (Германия) Августом-Вильгельмом Шеером, а на данный момент принадлежит компании Software AG. Данная нотация имеет ряд преимуществ, которые делают выбор именно данного способа проектирования целесообразным: 

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

Существует несколько нотаций проектирования, которые подходят для разных уровней описания. Нотация ARIS Value Added Chain Diagram (ARIS VACD) используется для верхнеуровневого (1 уровень) описания. На этих уровнях описываются ключевые процессы, выполняемые в организации. ARIS VACD подходит для изучения организации в целом. Несмотря на то, что для выявления возможных проблем этой нотации может быть недостаточно, она помогает определить те процессы, которые и нуждаются в изменениях и доработке. Элементы, используемые в данной нотации, приведены в таблице 2.1.

Таблица 2.1. Графические элементы ARIS VACD 

Наименование	Графическое изображение
Процесс
Входящий/исходящий объект
Ответственный

Нотация ARIS extended Event Driven Process Chain (ARIS eEPC) подходит для более низкоуровневого (2-8 уровень) описания процессов. По сути это расширенная версия нотации ARIS VACD, которая позволяет более детально изучить протекающие в организации процессы. Как правило, именно на данном этапе проектирования становятся очевидны проблемы, мешающие развитию организации. Элементы, используемые в данной нотации, приведены в таблице 2.2. 

Таблица 2.2. Графические элементы ARIS eEPC 

Описание	Графический элемент
Инициирующий/последующий процесс
Инициирующее/последующее событие
Процесс
Ответственный
Прикладная система
Входящий/исходящий документ
Разветвитель/соединитель «И»
Разветвитель/соединитель «ИЛИ»
Разветвитель/соединитель исключающий «ИЛИ»

Для проектирования структуры приложения используется диаграмма классов, демонстрирующая классы системы, их атрибуты, методы и взаимосвязи между ними. На диаграмме классы представлены в рамках, содержащих следующие компоненты: имя класса, поля (атрибуты) класса. 

2.2. Ключевые бизнес-процессы в моделях «AS-IS» и «TO-BE»

Если рассматривать первый уровень описания процессов (рисунок 2.1) в больнице, то ключевых процессов будет 3-и: поступление пациента в больницу (по направлению из поликлиники или через бригаду скорой медицинской помощи), непосредственно лечение пациента, а также выписка после завершения лечения. При поступлении пациента в регистратуре и лечащим врачом принимаются общие данные о поступившем больном, его анамнез и диагноз (в случае поступления по направлению из поликлиники). Далее пациент поступает на лечение, в процессе которого собираются данные об операции и реабилитации, после чего его выписывают из больницы. Все собранные данные заносятся в медкарту больного, а также в таблицу MS Excel для более быстрого поиска при создании отчётов.

Рис. 2.1. Первый уровень описания процессов 

Далее необходимо перейти ко второму уровню описания каждого из процессов. В качестве наиболее показательного примера будет достаточно рассмотреть второй уровень описания процесса «Лечение пациента» последовательно в начале в модели «AS-IS», а затем в модели «TO-BE». Данный процесс был выбран, поскольку именно на этом этапе идёт самое активное взаимодействие с данными о пациенте. Процесс «Лечение пациента» состоит из пяти основных процессов: обследование для уточнения диагноза, подготовка пациента к операции и её проведение, перевод в реанимацию, перевод в палату. Во время первых четырёх процессов доктор постоянно обращается к общим данным о пациенте, его анамнезу, а также информации о диагнозе. Во время перевода в палату лечащий врач обращается только к данным о процессе реабилитации пациента. Графические представления второго уровня процесса «Лечение пациента» в моделях «AS-IS» и «TO-BE» представлены на рисунках 2.2 и 2.3 соответственно. 

Рис. 2.2. Процесс «Лечение пациента» в модели «AS-IS» 

Рис. 2.3. Процесс «Лечение пациента» в модели «TO-BE» 

Как видно из сравнения двух моделей, разрабатываемое приложение действительно упрощает работу медицинского персонала. Сейчас необходимые данные приходится искать в медицинской карте пациента или в таблице MS Excel и распечатывать. Поскольку карты хранятся в регистратуре, а таблицы – на компьютере у некоторых докторов, общий доступ в любой момент к необходимой информации отсутствует. А в любом медицинском учреждении не редки ситуации, когда счёт идёт даже не на минуты, а на секунды – именно поэтому необходимо обеспечить всеобщий доступ в любой момент ко всей необходимой информации.  

2.3. Архитектура данных разрабатываемой системы

На основе порядка использования данных, приведённого выше, всю информацию можно разбить на классы, приведённые в таблице 2.3. 

Таблица 2.3. Классы данных  

Далее необходимо провести процедуру нормализации данных [6]. Стандартно все данные приводят к третьей нормальной форме (НФ), так как нормализации такого уровня бывает достаточно. Согласно 1-й НФ, в одном поле таблицы должен храниться только один атрибут. Таким образом в классе «Пациент» данные «ФИО» необходимо разбить на три отдельные строки: «Фамилия», «Имя», «Отчество». В классе «Операция» данные «ФИО хирурга» необходимо вынести в отдельный класс. Согласно 2-й НФ, должны соблюдаться условия 1-й НФ и каждый не ключевой атрибут должен зависеть от ключа. Следовательно, в классы «Пациент», «Анамнез» и «Операция» добавляется графа «Код пациента», а в таблицы «Операция», «Контроль» и «Реабилитация» – «Кодоперации». Также из класса «Пациент» убирается графа «Возраст», потому как она зависит от графы «Дата рождения», что противоречит условию 2-й НФ.

Рис. 2.4. Архитектура данных разрабатываемого приложения

Согласно 3-й НФ должны соблюдаться условия 2-й НФ и все не ключевые поля, содержимое которых может относиться к нескольким записям таблицы, должно выноситься в отдельные таблицы. Таким образом, после разделения всех данных на классы и проведения процедуры нормализации, получается архитектура разрабатываемого приложения, приведённая на рисунке 2.4.

2.4. Описание разрабатываемого приложения

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

Рис. 2.5. Первый интерфейс 

Допустим, пользователь решил занести данные о новом пациенте. В таком случае, ему откроется следующее диалоговое окно (рисунок 2.6), в котором он выбирает «Пациент». Далее на экране появляется интерфейс «Пациент» (рисунок 2.7). Данные, внесённые в графы, заполняют соответствующие строки таблицы «Пациент». Таким же образом заполняются прочие данные.

Рис. 2.6. Интерфейс «Добавить анкету»

Рис. 2.7. Интерфейс «Новый пациент» 

Если пользователю необходимо редактировать данные, то он точно так же выбирает конкретный блок, который необходимо изменить. Интерфейсы для редакции информации выглядят точно так же, как и соответствующие интерфейсы внесения данных. В том случае, если пользователю необходимо вывести на экран определённую информацию или составить отчёт, нажать на кнопку «Отчёт» и выбрать форму отчётов (рисунок 2.8). Если пользователю необходимо составить отчёт, шаблон которого не предусмотрен программой, то необходимо выбрать «Собственный отчёт». После этой процедуры он сможет в окне «Поиск» отобразить требуемые таблицы и данные в них.

Рис. 2.8. Интерфейс «Отчёты» 

Глава 3. Разработка программ 

3.1. Методы разработки

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

3.2. Реализация процесса регистрации нового пациента

Когда пациент только поступил в больницу, необходимо внести его данные в общую базу. Для этого пользователь выбирает последовательно «Добавить анкету», «Пациент» и открывает окно «Новый пациент», приведённое на рисунке 3.1. Далее заполняет соответствующие графы информацией о больном, полученной в результате опроса. 

Рис. 3.1. Внесение первичных данных о пациенте 

После этого доктор приступает к сбору анамнеза. Полученные либо при опросе, либо из медицинской книги данные пользователь вносит в форму «Анамнез» (рисунок 3.2). 

Рис. 3.2. Внесение данных об анамнезе пациента  

3.3. Реализация процесса полного анамнеза пациентов

Когда врачу необходимо изучить данные анамнеза пациента, нужно выбрать последовательно «Отчёты» и «Отчёт анамнез» (рисунок 3.3). 

Рис. 3.3. Интерфейс «Отчёты»

После этого пользователю будет предложено ввести код пациента, чьи данные необходимо получить. Далее пользователь увидит на экране полный анамнез зарегистрированного пациента, как на рисунке 3.4. 

Рис. 3.4. Анамнез пациента 

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

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

Рис. 3.5. Поиск по выбранному параметру 

Далее пользователь увидит таблицу (рисунок 3.6), которая будет содержать только запрашиваемые данные. 

Рис. 3.6. Таблица с выбранными данными 

Глава 4. Тестирование разработанного приложения

4.1. Методы тестирования

V-Model – модель проектирования, которая призвана сделать более простой разработку системы. Структура данного метода представлена на рисунке 4.1. V-образная модель часто применяется при разработке систем, которым особенно важно бесперебойное функционирование. Например, прикладные программы в медицинских учреждениях для наблюдения за состоянием пациентов. Особенностью данной модели можно назвать то, что она направлена на тщательную проверку и тестирование продукта, находящегося уже на первоначальных стадиях проектирования. Стадия тестирования проводится одновременно с соответствующей стадией разработки. Для проверки работоспособности разработанного ПО достаточно провести 3-и вида тестирования: функциональное, интеграционное и нагрузочное. 

Рис. 4.1. Структура V-модели 

4.2. Функциональное тестирование

Функциональное тестирование – это тестирование ПО в целях проверки реализуемости функциональных требований. То есть на данном этапе проверяется, способен ли разработанный продукт ПО в определённых условиях решать задачи нужные пользователям. Для этого необходимо сверить соответствие функциональных требований из главы 1 с имеющимися программными компонентами разработанной программы. Данные тестирования занесены в таблицу 4.1. Таким образом, можно сказать, что функциональные требования были реализованы и функциональное тестирование прошло успешно. 

Таблица 4.1. Функциональное тестирование программы  

Функциональное требование	Программный компонент	Графическое представление
Ведение таблицы данных «Пациент», содержащей информацию о пациенте, полученную путём опроса или из медкарты	Программа по вводу данных пациента
Ведение таблицы данных «Анамнез», содержащей информацию о сопутствующих заболеваниях, полученную путём опроса или из медкарты	Программа по вводу данных о анамнезе пациента
Ведение таблицы данных «Операция», содержащей информацию о поставленном диагнозе и проведённой операции	Программа по вводу данных об операции
Ведение таблицы данных «Контроль», содержащей информацию о состоянии пациента, полученную путём снятия показаний с приборов	Программа по вводу данных о контроле состояния пациента
Ведение таблицы данных «Реабилитация», содержащей информацию о скорости восстановления пациента после проведённой операции	Программа по вводу данных о реабилитации пациента
Таблица с соответствующими имеющимися данными	Программа по выводу на экран запрашиваемых данных
Возможность ввода информации	Средство для внесения информации	-
Возможность удаления данных	Средство для удаления информации	-
Корректная работа на всех персональных компьютерах медучреждения	Разрабатываемое ПО	-
Доступность всем работникам учреждения	Разрабатываемое ПО	-
Возможность вывода данных	Средство для вывода информации
Возможность хранения данных	Разрабатываемое ПО

 4.3. Интеграционное тестирование

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

Рис. 4.2. Таблица с запрошенными данными  

4.4. Нагрузочное тестирование

Нагрузочное тестирование – это способ тестирования работоспособности, сбор показателей и определение производительности и времени отклика программно-технической системы или устройства в ответ на внешний запрос. Для тестирования было выбрано следующее количество записей: 1, 30 и 50 (примерное количество пациентов за 2 недели), 100 (примерное количество пациентов за месяц). Данные по нагрузочному тестированию приведены в таблице 4.2. На основе полученных результатов можно сказать, что нагрузочное тестирование прошло успешно. 

Таблица 4.2. Результаты нагрузочного тестирования

4.5. Экономическая целесообразность

На разработку отводится 60 рабочих дней. Этапы разработки, сроки выполнения, а также организация работ представлена в таблице 4.3. 

Таблица 4.3. Этапы, сроки и организация работ 

Статья «Материалы, покупные изделия и полуфабрикаты» включает в себя (кроме стоимости приобретаемых материалов и изделий) транспортно-заготовительные расходы, которые составляют около 15% стоимости затрат по статье. Дополнительно включаются затраты на оформление комплекта документов. Расчёт затрат по первой статье приведён в таблице 4.4. 

Таблица 4.4. Расчёт затрат по статье «Материалы, покупные изделия, полуфабрикаты»  

Расчёт по статье «Основная заработная плата» приведён в таблице 4.5. Оплата за день рассчитана делением месячного оклада на 22 дня.

Таблица 4.5. Расчёт основной заработной платы 

Расход по статье «Дополнительная заработная плата» (ДЗП) составляет 25% от суммы основной заработной платы (ОЗП) и рассчитывается по формуле (4.1). 

ДЗП = ОЗП * 0.25. (4.1) 

Дополнительная заработная плата научного и производственного персонала составляет по проекту 7 794 руб. Расход по статье «Страховые отчисления» (СО) составляет 30% от фонда оплаты труда (ФОТ), который состоит из основной и дополнительной заработной платы, и рассчитывается по формуле (4.2). 

СО = (ОЗП + ДЗП) * 0.3. (4.2) 

Таким образом, страховые отчисления по текущему проекту составляют 11 691 руб. Статья «Накладные расходы» (НР) составляет 250% от суммы ОЗП научного и производственного персонала и рассчитываются по формуле (4.3). 

НР = ОЗП * 0.25. (4.3) 

Накладные расходы текущего проекта составляют 77 940 руб. При разработке, отладке и тестировании программного продукта использовался один компьютер, за которым было проведено 60 рабочих дней по 8 часов. Исходя из расчета оплаты 10 рублей за 1 час машинного времени, сумма составит 4 800 руб. Полная себестоимость (ПС) проекта приведена в таблице 4.6. 

Таблица 4.6. Полная себестоимость проекта 

Норма прибыли (НП) рассчитывается по формуле (4.4). 

НП = ПС * 0.3. (4.4) 

Таким образом, норма прибыли по текущему проекту составляет 41 726 руб. НДС рассчитывается по формуле (4.5). 

НДС = (ПС + НП)* 0.18. (4.5) 

НДС текущего проекта составляет 32 546 руб. Договорная цена будет рассчитываться по формуле (4.6). 

ДЦ = ПС + НДС. (4.6) 

Договорная цена текущего проекта составляет 171 632 руб., что позволяет утверждать об экономической целесообразности разработки. 

Заключение

В процессе работы были собраны и проанализированы пользовательские требования. На их основе были составлены функциональные требования, которым должно удовлетворять разрабатываемое приложение. Также была составлена матрица отслеживания требований, которая помогала в процессе проектирования и разработки отслеживать соответствие программных компонентов ожиданиям конечных пользователей. На этапе проектирования благодаря описанию некоторых бизнес-процессов в моделях «AS-IS» и «TO-BE» в очередной раз подтвердилась необходимость создания приложения, а также удалось составить наиболее удобную для конечного пользователя структуру разрабатываемого ПО. 

Далее на основе всех собранных данных была разработана программа в среде MS Access. После разработки было проведено тестирование приложения на предмет соответствия всем требованиям, качества работы всех элементов и скорости выполнения некоторых задач. Также была доказана экономическая целесообразность работы. Таким образом, можно сказать, что поставленная цель работы была достигнута, а задачи – выполнены. В процессе подготовки пояснительной записки для повышения наглядности было составлено 10 таблиц, приведено 17 рисунков (моделей, проектов программы и пользовательских интерфейсов, снимков с экрана), а также использовано 6 расчётных формул для экономического раздела.

Список литературы

1. Химонин Ю. Сбор и анализ требований к программному продукту. Версия 1.03 – 2009 – 51 с.
2. Никандров В.В. Экспериментальная психология. Учебное пособие. – СПб.: «Речь» – 2003. – 480 с.
3. ГОСТ Р 7.0.8-2013. Национальный стандарт Российской Федерации. Система стандартов по информации, библиотечному и издательскому делу. Делопроизводство и архивное дело. Термины и определения" (утв. Приказом Росстандарта от 17.10.2013 N 1185-ст).
4. Федеральный закон «Об основах охраны здоровья граждан Российской Федерации» (принят Государственной Думой 01.10.2011, одобрен Советом Федераций 09.10.2011).
5. Шеер А.В. ARIS - моделирование бизнес-процессов / пер. с англ. и ред. Рыбянец А.А. – 3-е изд. – М.: Вильямс – 2009. – 223 с.
6. Дейт К.Дж. Введение в системы баз данных / пер. с англ. и ред. Птицына К.А. – 8-е изд. – М.: Вильямс – 2016. – 1327 с.
7. Компьютерная справочная правовая система «Консультант Плюс» http://www.consultant.ru.
8. Карчевский Е.М., Филиппов И.Е., Филиппова И.А. Access 2010 в примерах. Учебное пособие – К.: Казанский университет – 2012. – 140 с.
9. Фуллер Л.У., Кук К., Кауфельд Д. Microsoft Office Access 2007 для “чайников” / пер. с англ. и ред. Сысонюк А.Г. – М.: Вильямс – 2007. – 384 с.
10. Одиночкина С.В. Разработка баз данных в Microsoft Access 2010 – СПб.: НИУ ИТМО – 2012. – 83 с.
11. Бекаревич Ю.Б., Пушкина Н.В. Самоучитель Microsoft Access 2013 – СПб.: БХВ-Петербург – 2014. – 464 с.
12. Официальный сайт Российской Государственной Библиотеки http://www.rsl.ru
13. INTERNATIONAL STANDARD ISO/IEC/IEEE 24765. Systems and software engineering — Vocabulary – 2010. – 410 с.  

Выходные данные

Орешкина А.М. Анализ, проектирование, разработка и тестирование приложения для автоматизации городской больницы: диплом бакалавра / МИРЭА. - М., 2017. - 49 с. – URL: http://stepanovd.com/training/20-vkr/65-vkrb-2017-1-oreshkina.