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

Подробности

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

Автор: Долгова Дарья Владимировна

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

Аннотация: дипломная работа посвящена реализации приложения в среде MS Access для автоматизации работы врача-ортопеда одной из столичных клиник. Приводится концепция анализа требований к разрабатываемой программе, определяются пользовательские и функциональные требования, составляющие матрицу отслеживания требований. Дается концепция проектирования процессов, данных и структур программ на основе ARIS VACD, ARIS eEPC, UML Class Diagram и трехуровневой структуре описания программ. Приводятся результаты моделирования ключевых бизнес-процессов, архитектуры баз данных и пользовательских программ. Доказывается целесообразность реализации программ в среде MS Access. Проводятся функциональное, интеграционное и нагрузочное испытания на основе V-модели разработки через тестирование.
Скачать: PDF, PPT.
Ключевые слова: программа по ортопедии, ортопедические стельки, ортопедический салон, ортопедия диагнозы, пример базы данных Access, функциональные требования, Сomputer Aided Software Engineering, Architecture of Integrated Information Systems, диаграмма классов uml пример, Unified Modeling Language, нормализация БД пример, 1 НФ, 2 НФ, 3 НФ, нормализация таблиц баз данных, трехуровневая структура описания программ, первая нормальная форма, вторая нормальная форма, третья нормальная форма, CASE средства примеры.

Введение

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

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

1.1. Концепция анализа

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

• интервьюирование представляет собой опрос заинтересованных лиц с целью выявления ожиданий от конечного продукта. Такой метод используется, когда основным объемом знаний обладает ограниченный круг людей или при невозможности собрать основных пользователей в одном месте;
• анкетирование заключается в составлении списка вопросов для выявления требований, предъявляемых к конечному продукту;
• метод мозгового штурма состоит в непрерывном обсуждении требований и записи всего, что прозвучало для последующей обработки. Он удобен тем, что могут рассматриваться нестандартные требования;
• сценарии и ролевые игры позволяют моделировать сценарии работы программного обеспечения. Благодаря этому методу пользователь и исполнитель лучше понимают, как будет работать система, что от нее требуется;
• создание прототипов подразумевает создание «макета» программ для представления его пользователю с возможностью дальнейшего изменения. Прототипы не являются рабочей версией программы, так как не учитывают всех функций и возможностей, которые требуются для корректной работы приложения [2].

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

1.2. Идентификация пользовательских требований

Пользовательские требования определяют задачи, которые должна разрешать программная разработка. Данные требования могут быть описаны в виде утверждений, способов взаимодействия и методов реализаций [2]. После проведения процедуры анализа были выявлены следующие пользовательские требования: 

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

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

База данных (БД) должна хранить информацию по клиентам, основным товарам, сопутствующим товарам, диагнозам, симптомам, рекомендациям по лечению, рекомендациям по уходу за основными товарами. Программа должна позволять составлять отчеты по необходимым признакам за определённый промежуток времени: количество принятых клиентов, количество проданных основных товаров, количество проданных сопутствующих товаров, итоговая сумма продаж, самый популярный товар. Выбор диагноза будет представлять собой процесс селекции всех возможных диагнозов и его хранение в карточке клиента. Cписок обслуженных клиентов за определенный промежуток времени должен содержать следующую информацию: дата, ФИО, номер телефона, предыдущая покупка, диагноз. Кроме того, должна быть предусмотрена возможность внесения новой информации в систему, такой как: карточки клиента, поставка сопутствующих товаров, новый товар и прочее. Подбор сопутствующих товаров будет осуществляться в зависимости от требуемых. Проверка наличия товаров необходима для отображения количества оставшегося товара на складе. Возможность вывода данных необходима для переноса информации на другие устройства или в сторонние программы. Требуется реализация функции удаления или архивирования неактуальной информации из баз данных. Кроме того, должно быть предусмотрено изменение неверно введенных данных. Простота и легкость интерфейса подразумевает приведение интерфейса и функций программного обеспечения к наиболее доступному и легкому виду. 

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

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

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

1.5. Результаты и их обсуждение

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

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

2.1. Концепция проектирования

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

IDEF0 (Integrated Definition 0) 

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

IDEF3 (Integrated Definition 3) 

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

DFD (Data Flow Diagrams) 

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

ARIS (Architecture of Integrated Information Systems) 

В настоящее время наблюдается тенденция интеграции разнообразных методов проектирования, заключающаяся в создании интегрированных средств моделирования. Одним из таких средств является программный продукт, разработанный германской фирмой IDS Scheer и носящий название ARIS [18]. ARIS поддерживает четыре типа моделей (и множество видов моделей в каждом типе), отражающих различные аспекты исследуемой системы: 

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

Для построения перечисленных типов моделей используются как собственные методы моделирования ARIS, так и сторонние методы и языки моделирования, в частности, UML. Основная нотация – ARIS eEPC (extended Event driven Process Chain), расширенная модель цепочки процессов, управляемых событиями. Данная нотация является расширением нотации IDEF0. Бизнес-процесс в нотации eEPC представляет собой поток последовательно выполняемых работ (процедур, функций), расположенных в порядке их выполнения. Реальная длительность выполнения процедур в eEPC визуально не отражается. Для получения информации о длительности процессов необходимо использовать другие инструменты описания, например, MS Project [18]. 

Нотация «Диаграммы цепочки добавленной стоимости» VACD является прототипом классического DFD-стандарта и используется для описания бизнес-процессов верхнего уровня. Дополнительным отличием данной и других процессных моделей является то, что информационные и материальные потоки на схеме VACD изображаются не стрелками, а объектами. При этом для каждого типа потока используется свой объект. В ARIS VACD в отличие от классического подхода также используются логические связи между работами, которые позволяют отобразить последовательность выполнения работ. В качестве одного из вариантов логической последовательности может выступать временная последовательность выполнения работ, что характерно для классического подхода WFD [19]. Модели в ARIS представляют собой диаграммы, элементами которых являются разнообразные объекты – функции, события, структурные подразделения, документы и др. Между объектами могут быть установлены связи определённых видов (выполняет, принимает решение, должен быть проинформирован о результатах и т.д.). Каждому объекту соответствует определенный набор атрибутов, которые позволяют ввести дополнительную информацию [5]. 

Проанализировав концепции моделирования бизнес-процессов, был сделан выбор в пользу ARIS eEPC и ARIS VACD. С помощью нотации ARIS VACD описываются верхнеуровневые процессы (1-2 уровни), а при помощи ARIS eEPC – низкоуровневые (3-8 уровни). В таблицах 1-2 приведены графические элементы указанных нотаций.

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

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

Верхнеуровневого моделирования недостаточно, чтобы расписать все возможные процессы и функции компании, для этого используется методология ARIS eEPC. Модель eEPC применяется для подробного описания бизнес-логики процесса с использованием четырех групп элементов: функциональные, логические, организационные элементы и данные [2]. При использовании всех групп элементов и достаточно углубленном описании процессов, получается всесторонняя бизнес-модель, показывающая основные действия, выполняемые конкретными людьми. Элементы ARIS eEPC даны в таблице 3.

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

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

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

В этом пункте рассматривается проектирование процесса работы врача-ортопеда в аннотациях ARIS VACD и eEPC модели «AS-IS», которая подразумевает под собой проектирование процессов в настоящий момент времени.  

1 уровень – Основные бизнес-процессы 

На первом уровне описываются основные бизнес-процессы врача-ортопеда коммерческой организации (рис.1). 

Рис. 1. 1-й уровень модели «Как есть» (основные процессы) 

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

2 уровень – Прием пациента 

На втором уровне рассматривается процесс приема пациента более подробно, чем на первом уровне. Декомпозиция процесса «Прием пациента» изображена на рисунке 2.  

Рис. 2. 2-й уровень модели «Как есть» (прием пациента) 

Уровень 3 – Создание карточки пациента 

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

Рис. 3. 3-й уровень модели «Как есть» (создание карточки пациента) 

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

Архитектура данных – это статическое и динамическое описание информационных систем, содержащих в себе некоторое количество отделов или подразделов организации. Классический структурный подход к созданию ИС предполагает последовательную реализацию этапов анализа, проектирования, создания модулей, объединения модулей в единую систему, тестирования и внедрения. Применение CASE-технологий и CASE-средств позволяет в несколько раз сократить время разработки ИС и значительно снизить вероятность появления ошибок за счет автоматизации начальных этапов разработки (как следствие – более качественное планирование и проектирование) и автоматической генерации структуры БД и кода клиентского приложения. UML (Unified Modeling Language) – унифицированный язык моделирования. UML представляет собой набор соглашений, которые предназначены для облегчения процесса моделирования и обмена информацией в проектной группе. Наличие стандартизированной нотации позволяет сократить время на усвоение информации, упрощает общение и взаимодействие, облегчает документирование. UML представляет собой графическую нотацию, предназначенную для моделирования и описания всех процессов, протекающих в ходе разработки. Основу UML представляют диаграммы, которые различаются по типам и предназначены для моделирования различных аспектов работы. 

Результаты моделирования могут быть сведены в таблицу, но использовать ее нельзя до тех пор, пока не будет проведена нормализация данных для исключения повтора и копирования информации (рисунок 4). Нормальной таблицей считается та, которая приведена как минимум к третьей нормальной форме. Отношение называется приведенным к первой нормальной форме, если все его атрибуты простые. Отношение находится во второй нормальной форме, если оно находится в первой нормальной форме и значения в каждом неключевом атрибуте однозначно определяются значением первичного ключа. Отношение находится в третьей нормальной форме, если оно находится во второй нормальной форме и все неключевые атрибуты не зависят друг от друга [15]. 

Рис. 4. Таблица данных, приведенная к 3-й нормальной форме 

2.4. Трехуровневая структура описания программ

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

Рис. 5. Интерфейс «Главная страница» 

На рисунке 6 подробно изображено содержание карточки пациента: идентификационный номер пациента, ФИО, дата рождения, дата приема, телефонный номер и адрес. Экран также будет содержать кнопку занесения информации в базу данных. Рисунок 7 содержит экран постановки диагноза пациенту, который будет содержать в себе поля идентификационного номера пациента и список диагнозов. 

Рис. 6. Интерфейс «Карточка пациента» 

Рис. 7. Интерфейс «Диагноз» 

Интерфейс добавления нового товара на склад, который будет содержать идентификационный номер товара, его название и цену, приведен на рисунке 8. Рис.9 демонстрирует экран продажи товара пациенту с полями ввода идентификационного номера продажи, идентификационного номера товара, количества и даты продажи. 

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

Рис. 9. Интерфейс «Продажа» 

2.5. Ключевые бизнес-процессы в модели «Как будет»

После рассмотрения структуры интерфейсов необходимо спроектировать процессы врача-ортопеда в нотациях ARIS VACD и eEPC, но в модели «TO-BE», так как уже ясна степень использования программных разработок в ходе реализации бизнес-операций. На рисунке 1 изображены основные бизнес-процессы врача-ортопеда в нотации VACD, процессы схожи для обоих моделей «AS-IS» и «TO-BE». На рисунке 10 показан процесс «Приема пациента» на 2-м уровне описания, в то время как 11-й рисунок демонстрирует модель операции «Создание карточки пациента» для 3-го уровня моделирования. Оба рисунка иллюстрируют бизнес-процессы в модели «Как будет». 

Рис. 10. 2-й уровень модели «Как будет» (прием пациента) 

Рис. 11. 3-й уровень модели «Как будет» (создание карточки пациента) 

2.6. Результаты и их обсуждение

В данной главе была описана такая неотъемлемая часть разработки приложений как проектирование. Сначала определялась стратегия моделирования. После тщательного анализа были выбраны нотации ARIS VACD для верхнеуровнего моделирования и ARIS eEPC для низкоуровнего проектирования бизнес-процессов. Используя выбранные нотации моделирования, были спроектированы основные бизнес-процессы организации в моделях «Как есть» и «Как будет». Кроме того, разработана архитектура данных на основе методологии UML Class Diagram и спроектирована структура пользовательских интерфейсов для разрабатываемого приложения. 

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

3.1. Концепция разработки

Среда Microsoft Access обладает всеми чертами классической системы управления базами данных (СУБД). Access это не только мощная, гибкая и простая в использовании СУБД, но и система для разработки приложений баз данных. К числу наиболее используемых компонентов Access относятся средства разработки объектов и мастера, которые можно использовать для создания таблиц, запросов, различных типов форм и отчетов. В MS Access включены помощники, помогающие производить анализ структуры данных, импортировать электронные таблицы и текстовые данные, повышать быстродействие программ, создавать и настраивать одно из более чем двадцати типов приложений. Чтобы полностью автоматизировать работу приложения, можно использовать макросы для связывания данных с формами и отчетами. Большинство приложений можно создать, не написав ни единой строки программного кода. Однако при необходимости построения действительно сложного приложения можно использовать язык программирования Visual Basic [11, 12]. Для проектирования базы данных необходимо располагать описанием выбранной предметной области, которое должно охватывать реальные объекты и процессы, определять все необходимые источники информации для обеспечения предполагаемых запросов пользователя и решаемых в приложении задач. Следует заметить, что чаще всего базы данных создаются средствами СУБД в области организационно-экономического управления. 

3.2. Программы для реализации бизнес-процессов

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

Рис. 12. Входная форма 

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

Рис. 13. Новый клиент 

Экран оприходования товара на склад (рисунок 14) содержит автоматически генерируемый индивидуальный код товара, название товара, цену, количества и кнопку перехода на экран указания взаимосвязи диагноза и товара. На рисунке 15 изображен экран доступного количества товара на складе, который содержит в себе выпадающий список со всеми товарами и их кодами, названия и цены товара, количество на складе и количество проданного товара. 

Рис. 14. Добавление товара на склад 

Рис. 15. Количество товара на складе 

Рисунок 16 содержит экран диагнозов клиента со следующими полями: список кодов клиентов и диагнозов, дата приема. Так же на экране присутствует кнопка перехода на экран поиска товара по диагнозу. Экран продажи товара (рисунок 17) включает автоматически генерируемый код продажи, выпадающий список кодов клиентов, дату продажи, кнопки для перехода на главный экран и экран подбора товара.

Рис. 16. Диагнозы клиентов 

Рис. 17. Новая продажа 

3.3. Аналитическая отчетность

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

Рис. 18. Отчет по продажам 

Рис. 19. Всплывающее окно даты 

Рис. 20. Отчет по клиентам 

3.4. Результаты и их обсуждения

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

Глава 4. Тестирование

4.1. Стратегия тестирования

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

Рис. 21. V-образная модель 

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

Функциональное тестирование проверяет корректность работы заданных функций и подсистем каждой разработанной программы. Функциональные требования служат источником тестовых сценариев, для которых задаются приоритеты по шкале MuSCoW (Must, Should, Could, Would). Это позволяет не пропустить тестирование наиболее важные бизнес-функций компании. Рассмотрим тестирование процесса заполнения карточки нового клиента. На рисунке 22 изображен экран ведения карточки пациента. После заполнения данных необходимо нажать кнопку «Указать диагноз». Нажатие кнопки отобразит экран выбора диагноза пациента (рис. 23). Далее с помощью кнопки «Поиск товара по диагнозу» осуществляется соответствующий поиск продукции. 

Рис. 22. Новый клиент 

Рис. 23. Диагноз клиента 

Рисунок 24 содержит всплывающее окно, запрашивающее подтверждение указанного диагноза. Выполнив подтверждение, программа отображает следующий экран (рисунок 25), где выводится таблица с товарами, найденными для введенного ранее диагноза. 

Рис. 24. Окно запроса диагноза 

Рис. 25. Поиск товара по диагнозу  

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

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

Рис. 26. Запрос даты приема 

Рис. 27. Отчет по клиентам 

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

Нагрузочное тестирование необходимо для того, чтобы проверить, как программное обеспечение справляется с большим потоком входной информации. На рисунках 28-29 изображены результаты выборки данных для клиентов и складских запасов. Проектируемое приложение успешно справилось с обработкой большого объема данных, кроме того в ходе испытаний критических дефектов выявлено не было. 

Рис. 28. Таблица клиентов 

Рис. 29. Таблица склада 

4.5. Оценка экономической целесообразности

Экономическая целесообразность разработки автоматизированной информационной системы для компании «Доброта.ру» заключается в следующем: 

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

4.6. Результаты и их обсуждение

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

Выводы

Целью данной работы являлось создание автоматизированного рабочего места врача-ортопеда в коммерческой компании по продаже товаров медицинской направленности. Необходимо было оптимизировать рабочий процесс с целью экономии времени сотрудника и средств компании. Первым пунктом реализации приложения являлась идентификация способов анализа требований. После чего было проведено непосредственное выявление пользовательских и функциональных требований и создание матрицы отслеживания требований для контроля создания приложения. Этот этап разработки является наиболее важным, так как именно от требований проектируется приложение. После того, как этап анализа требований был реализован, необходимо было перейти к этапу проектирования приложения. Он включал в себя концепцию проектирования, в которой были выбраны нотации проектирования процессов и данных, такие как ARIS VACD и eEPC и UML Class Diagram; построение ключевых процессов в модели «Как есть» и «Как будет»; формирование архитектуры данных разрабатываемой системы, а также построение трехуровневой структуры программ. На данном этапе были тщательно рассмотрены ключевые бизнес-процессы, которые необходимо было автоматизировать. А создание пользовательских интерфейсов помогло еще лучше представить, какой программа будет после завершения. 

Далее велась непосредственная разработка программы для рабочего места врача-ортопеда. Этот этап необходимо было начать с выбора платформы, на которой создавалось бы приложение. После тщательного анализа была выбрана среда Microsoft Access, так как она является простой и понятной в обращении; имеет возможность внесение данных из программы Microsoft Excel, в которой ранее велась часть баз данных; является полностью совместимой с системой Windows и обладает огромными возможностями по импорту и экспорту данных. Эти преимущества позволят с легкостью перейти на новое программное обеспечение, не затрачивая времени на перенос информации из «старых» баз данных. На этом же этапе было разработано приложение, основными функциями которой являются создание карточки пациента, учет товара, продажа товара, подбор товара в зависимости от диагноза и составление отчетов по обслуженным клиентам и проданному товару. Не менее важно было провести тестирование созданного приложения, для этого была разработана концепция тестирования, которая включала в себя функциональные, интеграционные и нагрузочное тестирование. В ходе испытаний были выявлены несущественные недоработки, которые позже были устранены. 

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

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

1. Балдин К.В., Уткин В.Б. Информационные системы в экономике. – М.: Дашков и Ко, 2008. – 218 с.
2. Химонин Ю. И. Сбор и анализ требований к программному продукту (Версия 1.03), 2009.
3. Душин В.К. Теоретические основы информационных процессов и систем: Учебник. – М.: Дашков и Ко, 2009. – 504 с.
4. Вигерс К.И., Битти Дж. Разработка требований к программному обеспечению. – СПб.: БХВ-Петербург, 2016.
5. Степанов Д.Ю. Анализ, проектирование и разработка корпоративных информационных систем: уровень приложений / МИРЭА. - М., 2017.
6. Коберн А. Современные методы описания функциональных требований к системам / Коберн А. – М.: Лори, 2017.
7. Жихарев А.П. Автоматизированные информационные системы и ресурсы. – М.: Юнити-Дана, 2009. – 256 с.
8. Исаев Г.В. Проектирование информационных систем. Учебное пособие. – М.: Омега-Л, 2013. – 464 с.
9. Агальцов В.П. Локальные базы данных. – М.: НВП ИНЭК, 2009. – 52 с.
10. Гурвиц Г. Microsoft Access 2010. Разработка приложений на реальном примере. – СПб: БХВ-Петербург, 2010. – 497 с.
11. Одиночкина С. Разработка баз данных в Microsoft Access 2010. – СПб: НИУ ИТМО, 2012. – 83 с.
12. Сеннов А.С. Access 2010. Учебный курс – СПб.: Питер, 2010. – 288 с.
13. Медицинская информатика / Королюк И.П. – Самара: Офорт, 2012. – 244 с.
14. Медицинская информатика: учебник для студентов учреждений высшего профессионального образования / Кобринский Б.А., Зарубина Т.В. – М.: Академия, 2012. – 192 с.
15. Фаулер М., Скотт К. UML. Основы. – М.: Символ-Плюс, 2002. – 192 с.
16. Блинов И.Н., Романчик В.С. Java. Методы программирования / Блинов И.Н. – М.: Четыре четверти, 2003.
17. Рамбо Дж., Блаха М. UML 2.0. Объектно-ориентированное моделирование и разработка / Рамбо Дж. – М.: Питер, 2007.
18. Шеер А.В. ARIS – моделирование бизнес-процессов. – М.: Вильямс, 2009. – 224 с.
19. Ротер М., Шук Дж. Учитесь видеть бизнес-процессы. Построение карт потоков создания ценности / Ротер М. – М.: Альпина Паблишер, 2017. – 144 с.
20. Кавалерский Г.М., Гаркав А.В. Травматология и ортопедия. Учебник/ Кавалерский Г.М. – М.: Academia, 2013. – 640 с.
21. Грязнухин Э., Шапиро К., Корнилов Н. и др. Травматология и ортопедия. Учебник / Грязнухин Э. – М.: изд. ГЭОТАР-Медиа, 2016. – 600 с.
22. Котельников Г., Миронов С. Травматология. Национальное руководство. Краткое издание / Котельников Г. – М.: ГЭОТАР-Медиа, 2016. – 530 с. 

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

Долгова Д.В. Анализ, проектирование, разработка и тестирование приложения для автоматизации работы врача-ортопеда / МИРЭА. - М., 2017. - 55 с. – URL: http://stepanovd.com/training/20-vkr/61-vkrb-2017-3-dolgova.