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

Подробности

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

Автор: Граделев Елисей Станиславович

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

Аннотация: в квалификационной выпускной работе разрабатывается приложение в среде MS Access для автоматизации деятельности компании по продаже медицинского оборудования. Рассматривается стратегия анализа требований, идентифицируются пользовательские и функциональные требования, а также приводится матрица отслеживания требований. Определяется стратегия проектирования процессов, данных и структур программ, описываются ключевые бизнес-процессы, архитектура данных и пользовательские интерфейсы. Приводятся стратегия реализации приложения, а также копии экранов разработанной программы в MS Access. Формируется стратегия тестирования на основе V-модели, выполняется функциональное, интеграционное и модульное тестирование. Оценивается экономическая целесообразность разработки, а в заключении подводятся итоги работы.
Скачать: PDF, PPT.
Ключевые слова: Microsoft Access, gap анализ на примере предприятия, функциональные требования к программному продукту, ARIS EEPC примеры, общие принципы разработки программных средств, разработка через тестирование, v-model, v модель разработки программного обеспечения, тестирование программного обеспечения пример, функциональное тестирование пример.

Введение

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

• анализ;
• проектирование;
• разработка;
• тестирование.

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

Глава 1. Анализ

1.1. Стратегия анализа требований

Под анализом требований подразумевается процесс сбора информации, требуемой для успешной разработки продукта. В процессе сбора информации можно использовать метод анализа различной документации и спецификаций [6]. Важную роль играет разрешение споров между участниками, вовлеченными в проект. Кроме того, необходимо принимать во внимание мнение всех заинтересованных лиц, будь то разработчики, заказчики или конечные пользователи. Этап анализа деятельности компании является начальным в процессе разработки программы и является самым главным, так как допущенные ошибки в нем могут привести к не желаемому конечному продукту или вообще невозможно будет реализовать программный продукт до конца. Фактически на данной фазе дается ответ на вопрос «Что должна делать программа?» [18]. В рамках данной главы необходимо описать требования к выполняемым функциям компании, а также совокупность условий, в которых будет эксплуатироваться программа. Суть анализа заключается в преобразовании общих, неясных требований к будущей системе в точные определения [7]. Для этого необходимо задать пользовательские и функциональные требования, которые в дальнейшем будут сопоставляться с предполагаемыми компонентами программы. Требования составляются путем обсуждения, опроса и представления конечного результата между пользователем и разработчиком, также в данном процессе может участвовать и сам спонсор проекта.  

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

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

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

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

Функциональные требования – это требования, которые отвечают на вопрос «Что должна делать система?». Они формулируются, исходя из пользовательских требований, и должны описывать, как будет работать сама система: 

• ведение информации о медицинском оборудовании – в эти данные должна входить информация о самом товаре, то есть идентификационный номер оборудования, его технические характеристики, его размеры, его возможности, срок гарантии, а также некоторые преимущества перед другими схожими товарами;
• содержание данных о компании по производству медицинского оборудования – в данном разделе должна содержаться информация, включающая в себя подробные данные о местоположении компании-производителя (его индекс, географическое положение, адрес центрального офиса, склада, завода, данные о директоре компании, а также контактные телефоны, электронная почта, основной сайт в интернете);
• возможность получения информации о наличии товара на складе – в данном разделе должна содержаться информация о количестве товара на складе и его качестве;
• должно приходить уведомление, если товар на складе отсутствует – автоматическая отправка уведомления на почту или в приложение, если товар на складе закончился;
• должны содержаться данные о клиенте-покупателе – ФИО покупателя, дата рождения, его контактные данные, его принадлежность к определенной медицинской организации, должность, краткое описание необходимого продукта;
• данные о поставках – информация о компаниях-партнерах (по доставке), их контактные данные, данные на водителей, которые уже перевозят товар (ФИО, контактная информация), информация о сроках доставки;
• отчет по проданному оборудованию – информация о проданных товарах в одном документе, их идентификационные номера, дата продажи, суммирование за месяц, квартал, год;
• отчет по доставленному оборудованию вовремя клиенту – указание всех доставленных товаров в указанные сроки;
• отчет по отзывам покупателей – суммирование положительных и отрицательных отзывов от покупателей, их краткое содержание, информация о самих покупателях;
• отчет по закупленному оборудованию – все перечисленное оборудование, закупленное у производителя;
• отчет о доставленном оборудовании компании от производителя – должен включать информацию об оборудовании, которое привезли в компанию, так же информацию о качестве этого оборудования, о сроках доставки;
• возможность вносить данные в приложение – организовать возможность для внесения информации о продуктах в приложение;
• возможность сохранения данных – данные/информация, должна храниться в приложении;
• возможность удаления данных – при необходимости пользователю должно быть доступно удаление хранящейся информации из приложения;
• возможность вывода данных – данные при необходимости могут быть изъяты из приложения различным путем (при помощи принтера, съемного носителя и т.д.);
• возможность установки на любой компьютер – приложение должно подходить для любого компьютера;
• информативность – каждое окно приложения должно быть содержательно и интуитивно понятно;
• доступность (легкость восприятия) – пользователю должно быть легко и понятно работать с приложением;
• возможность просмотра и выбора необходимых данных – должна быть реализована возможность в выводе хранимой информации на экран, чтобы пользователь мог с ней ознакомиться. 

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

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

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

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

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

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

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

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

Верхнеуровневое моделирование необходимо для того, чтобы показать основные бизнес-процессы [5]. Для более глубокого анализа и более детальной разработки необходимо использование низкоуровневых методов. В данной работе было решено использовать для верхнеуровневого проектирования нотацию ARIS VACD, а для низкоуровневого – ARIS eEPC. Выбор пал именно на эту пару из-за простоты ARIS VACD и информативности ARIS eEPC. Также основным критерием послужило то, что ARIS eEPC является улучшенной версией аналога UML, но с более логичными и понятными структурой и графическими элементами [20]. Концепция ARIS была предложена и разработана немецким исследователем, профессором Августом Вильгемом Шеером. ARIS представляет собой подход к формализации информации о деятельности организации и представление ее в виде графических моделей, удобных для понимания и анализа. Модели создаваемые по концепции ARIS отражают существующую ситуацию «как есть» и предполагают построение моделей «как должно быть». ARIS VACD – это модель цепочки добавленной стоимости, показывающая из чего и каких последовательных процессов складывается конечная стоимость продукта [3]. Ее основные элементы изображены в таблице 2.

Таблица 2. Основные элементы ARIS VACD

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

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

Таблица 3. Основные элементы ARIS eEPC

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

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

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

Рассмотрим проектирование процесса «Продажи медицинского оборудования» в аннотациях ARIS VACD и eEPC и модели «Как есть» [1]. В данной модели основным фокусом является проектирование текущих процессов компании. Главным аспектом видится вычленение ключевых бизнес-процессов компании и их глубокое рассмотрение при помощи низкоуровневого проектирования ARIS eEPC, описанного ранее. 

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

Основные бизнес процессы компании по продаже медицинского оборудования в аннотации ARIS VACD представлены на рисунке 1. Рисунок содержит процессы закупки, доставки, учета и продажи товаров.

Рис. 1. Основные бизнес процессы компании 

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

Уровень 2 – Продать 

Теперь рассмотрим процесс «Продать» в более детальном виде, применяя низкоуровневую нотацию проектирования ARIS eEPC (рис.2). 

Рис. 2. Второй уровень моделирования 

Уровень 3 – Обсуждение оборудования 

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

Рис. 3. Третий уровень моделирования

Уровень 4 – Предоставление информации об имеющемся оборудовании 

На данном уровне проектирования становится понятным, как происходит процесс предоставления информации об имеющимся оборудовании (рисунок 4). 

Рис. 4. Четвертый уровень моделирования 

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

Далее разрабатывается архитектуры данных проектируемой системы в нотации UML Class Diagram. Диаграмма классов предназначена для представления модели программной системы, то есть графического представления структурных взаимосвязей частей системы, которые не зависят от времени [13]. Вначале необходимо определить ключевые классы данных, которые будут использоваться в программе. Выявленные классы представлены на рисунке 5. 

Рис. 5. Классы данных 

Далее потребуется определить поля данных для каждого из классов проектируемой программы [22]. Одним из важных моментов, является нормализация данных. Существует 6-ть нормальных форм, 5-ть из которых так и называются: первая, вторая, третья, четвертая и пятая нормальная форма. А 6-й является нормальная форма Бойса-Кодда, логически расположенная между 3-й и 4-й формами. Данные считаются нормализованными, если таблицы представлены как минимум в 3-й нормальной форме. Главной целью нормализации является устранение избыточной и дублированной информации. Какими основными требованиями должна удовлетворять каждая из нормальных форм? Первая нормальная форма: 

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

Вторая нормальная форма требует, чтобы неключевые столбцы таблиц зависели от первичного ключа в целом, но не от его части. Причем если таблица находится в 1-й нормальной форме и первичный ключ у нее состоит из одного столбца, то она автоматически находится и во 2-й нормальной форме. Чтобы таблица находилась в третьей нормальной форме, необходимо, чтобы неключевые столбцы в ней не зависели от других неключевых столбцов, а зависели только от первичного ключа. Самая распространенная ситуация в данном контексте – это расчетные столбцы, значения которых можно получить путем каких-либо манипуляций с другими столбцами таблицы. Для приведения таблицы к 3-й нормальной форме такие столбцы необходимо удалить. На рисунке 6 представлены классы, приведенные к 3-й нормальной форме. 

Рис. 6. Классы с полями данных 

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

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

Рис. 7. Блок-схема работы проектируемого приложения 

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

Рис. 8. Экран выбора медицинского оборудования

Рис. 9. Экран отображения выбранного оборудования 

Результаты поиска оборудования отображаются на следующем экране (рисунок 9). Пользователю представляется список оборудования, которое подходит под критерии выборки. Пользователь может выбрать заинтересовавшее его оборудование, затем, нажав на клавишу «Показать информацию», посмотреть подробную информацию о медицинском приборе. После этого можно переходить к завершению оформления покупки оборудования. Рисунок 10 содержит экран детальной информации о выбранном оборудовании. После просмотра пользователь может вернуться в предыдущее окно и выбрать другое оборудование.

Рис. 10. Экран отображения интересующего оборудования 

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

Смоделируем процесс «Продажи медицинского оборудования» в аннотациях ARIS и модели «Как будет», принимая во внимание полученные результаты описания процессов, данных и структуры приложения. В данной модели особое внимание уделяется проектированию бизнес-процессов после внедрения разрабатываемой программы. Главным аспектом модели «Как будет» является выявление отличий процессов на основе применения низкоуровневого проектирования ARIS eEPC. 

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

Основные бизнес-процессы компании по продаже медицинского оборудования в аннотации ARIS VACD представлены на рисунке 11. Рисунок содержит процессы по закупке, доставке, учету и сбыту товаров. Приступим к низкоуровневому моделированию бизнес-процессов с целью выявления роли разрабатываемого приложения. 

Рис. 11. Основные бизнес процессы компании 

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

Уровень 2 – Продать 

Перейдем к рассмотрению процесса «Продать» в более детальном виде, путем его проектирования в нотации ARIS eEPC. Данный бизнес-процесс изображен на рисунке 12. 

Рис. 12. Второй уровень моделирования 

Уровень 3 – Обсуждение оборудования 

От уровня к уровню становится более наглядна роль разрабатываемого приложения в ходе выполнения бизнес-операций. Описание процесса «Обсуждение оборудования» дано на рисунке 13. 

Рис. 13. Третий уровень моделирования 

Уровень 4 – Предоставление информации об имеющемся оборудовании 

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

Рис. 14. Четвертый уровень моделирования

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

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

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

3.1. Стратегия разработки

Разработка программы будет производиться в среде MS Access. Access привлекает простотой освоения и возможностью использования непрофессиональными программистами. Она имеет мощные средства подготовки отчетов из баз данных (БД) различных форматов [14]. Поэтому основное назначение среды – создание отчетов и разработка некоммерческих приложений. В общем случае Access является набором инструментальных средств, предназначенных для создания и эксплуатации информационных систем. К удобным для пользователей и разработчиков средствам Access относятся мастера и конструкторы таблиц, форм, запросов и отчётов. Она позволяет автоматизировать часто выполняемые операции (например, расчёт заработной платы, учёт материальных ценностей и т.п.), разрабатывать удобные формы ввода и просмотра данных, составлять сложные отчёты и др.

Таблица в Access является основным структурным объектом внутреннего строения БД. В неё включают записи определённого вида. Каждая запись таблицы содержит всю необходимую информацию об отдельном объекте [15]. По многим причинам вводить все данные в одну таблицу нерационально, поэтому в Access предусмотрен механизм создания связанных между собой таблиц с различными видами данных. Таблицу Access можно связать с данными, хранящимися на другом компьютере или на сервере. Кроме того, в Access можно использовать таблицу, созданную в другой СУБД. Данные среды MS Access очень просто комбинировать с данными из любой другой программы MS Office [17]. С помощью Access можно выполнять следующие операции: 

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

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

Опишем разработку приложения для оптимизации деятельности компании по продаже медицинского оборудования в среде MS Access. На рисунке 15 изображена структурная схема и связи всех используемых таблиц данных, необходимых для работы приложения. Схема данных строилась путем добавления необходимых таблиц данных, выделением из них ключевых полей, необходимых для создания связей между ними. Все это выполнялось в режиме «конструктора». На рисунке 16 изображен экран «Входной формы». На этом экране пользователь может выбрать интересующую его операцию, чтобы реализовать те или иные функции разрабатываемого приложения. Разработка приложения будет вестись для ключевого процесса поиска оборудования, спроектированного в предыдущей главе. Рисунок 17 содержит экран поиска требуемого медицинского оборудования по конкретным параметрам таблиц данных. После указания селекционных данных, программа выводит на экран таблицу с результатами.

Рис. 15. Экран с отображением схемы данных 

Рис. 16. Экран входной формы

Рис. 17. Экран с поиском информации 

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

Также в приложении была реализована возможность составления отчетов по выполненным продажам. Примеры отчетов даны на рисунках 18-19. Реализация аналитической отчетности является одной из важнейших особенностей программы, что позволяет автоматически рассчитывать объем проданного медицинского оборудования для исключения ручной обработки.

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

Рис. 19. Отчет по доступности оборудования на складе 

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

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

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

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

Существует множество методов и способов проведения испытаний разработанного приложения. Одним из таких способов является тестирование на основе V-модели. Структура модели приведена на рисунке 20. Согласно данной модели каждому этапу проектирования системы соответствует свой уровень тестирования [16]. На рисунке 20 процесс разработки отражен в левой части и имеет последовательность сверху-вниз, а тестирование – в правой. Суть использования данной модели заключается в том, что с каждым уровнем продвижения по «V-траектории» увеличивается количество испытуемых данных. 

Рис. 20. V-модель разработки через тестирование 

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

Функциональное тестирование проводится на основе небольшого количества данных, чтобы посмотреть и проверить работу разработанного приложения в целом. При обнаружении ошибок, необходимо их исправить и повторно провести тестирование. На рисунке 21 показано содержание таблицы данных для оборудования на складе. 

Рис. 21. Экран с имеющимся оборудованием 

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

Рис. 22. Экран с изображением поиска оборудования 

После нажатия «Выполнить», отобразятся результаты поиска (рис.23). Согласно рисункам 21 и 23 из 5-ти наименований оборудования, хранящегося на складе, приложение вывело на экран лишь то, которое было ограничено критериями выборки. Следовательно, программа отработала корректно, никаких ошибок обнаружено не было. 

Рис. 23. Результаты поиск 

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

Интеграционное тестирование проводится только после того, как пройдено функциональное тестирование. Основное отличие интеграционного тестирования от функционального заключается в количестве испытуемых записей и возможных критериев их поиска пользователем. На рисунке 24 изображена база данных уже с 10-ю записями, которые предстоит протестировать. Предположим, в этот раз покупателю интересно оборудования с датой производства позже 2016 года. А также он заинтересован в покупке УЗИ аппаратуры. На рисунке 25 показан экран с указанием критериев выборки необходимого оборудования. 

Рис. 24. Экран с имеющимся оборудованием

Рис. 25. Экран с изображением критерий поиска оборудования 

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

Рис. 26. Результаты поиск 

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

Нагрузочное тестирование проводится только после того, как продукт прошел интеграционное испытание. В данном виде тестирования необходимо провести испытание уже на реальном объеме данных, например, на 50-ти записях. Тестирование проводится по различным критериям поиска оборудования. Использованные в ходе испытаний данные по оборудованию приведены на рисунке 27. 

Рис. 27. Экран с имеющимся оборудованием 

В этот раз покупатель заинтересован в оборудовании с датой производства раньше 20 октября 2016 года. Кроме того, требуется купить МРТ-систему не дешевле десяти миллионов рублей. Критерии поиска оборудования показаны на рисунке 28. На рисунке 29 приведены результаты поиска оборудования согласно введенным критериям поиска. Критических ошибок в ходе нагрузочного тестирования обнаружено не было: программа с поиском справляется без проблем. Именно поэтому сделан вывод о том, что данный вид тестирования успешно пройден, а разработанное приложение готово к использованию и обработке реального объема данных. 

Рис. 28. Критерии поиска

Рис. 29. Результаты поиска 

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

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

Глава 5. Организационно-экономическое обоснование

5.1. Разработка основных разделов бизнес-плана проекта

На разработку отводился 61 рабочий день. Этапы разработки представлены в таблице 4. 

Таблица 4. Этапы разработки 

5.2. Организация и планирование работ

Организация и планирование работ представлены в таблице 5. 

Таблица 5. Организация работ  

5.3. Определение договорной цены

Цена договорная рассчитывается по формуле (1): 

Цена договорная = Себестоимость + Прибыль + НДС. (1) 

Себестоимость формируется из ряда статей: 

• 1 статья «Материалы, покупные изделия и полуфабрикаты» + ТЗР (15%) от ? итого по материалам;
• 3 статья «Основная заработная плата»;
• 4 статья «Дополнительная заработная плата» 20-30% от основной заработной платы;
• 5 статья «Страховые отчисления» – 30% от ФОТ (22% – взносы в Пенсионный фонд, 5,1% – фонд обязательного медицинского страхования, 2,9% – взносы в фонд социального страхования);
• 8 статья «Накладные расходы» – 250% от основной заработной платы.

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

Таблица 6. Основные материалы

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

Дополнительная заработная плата научного и производственного персонала составляет 20% от основной заработной платы (2): 

ДЗП = 27198 * 0.2 = 5440 руб. (2) 

Отчисления на социальные нужды составляют 30% от фонда оплаты труда (3-4), который состоит из основной и дополнительной заработной платы: 

ФОТ = ОЗП + ДЗП = 27198 + 5440 = 32638 руб. (3) 

СН = ФОТ * 30% = 32638 * 0.3 = 9792 руб. (4) 

Накладные расходы (НР) принимаются в размере 250% от суммы основной заработной платы (5): 

НР = ОЗП * 250% = 27198 * 2.5 = 67995 руб. (5) 

При разработке, отладке и тестировании программного продукта использовался один компьютер, за которым было проведено 61 рабочий день по 8 часов. Исходя из расчета оплаты 10 рублей за 1 час машинного времени, сумма составит (6): 

ПР = 1 * 61 * 8 * 10 = 4880 руб. (6) 

Полная стоимость разработки отражена в таблице 8.

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

Норма прибыли составляет 30% от стоимости разработки (7): 

П = 117663 * 30% = 35299 руб. (7) 

Разработка велась не на базе МИРЭА, следовательно, взимается налог на добавленную стоимость (8) в размере 18%: 

НДС = (117663 + 35299) * 18% = 27534 руб. (8) 

Таким образом, формула договорной цены (9) будет представлять собой: 

ДЦ = ОЦ + НДС = 117663 + 35299 + 27534 = 180496 руб. (9) 

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

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

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

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

Выводы

Работа была посвящена разработке приложения для автоматизации деятельности компании по продаже медицинского оборудования. Автоматизация заключалась в сокращении времени работы сотрудников путем компьютеризации ввода, ведения и поиска данных. Для реализации приложения были идентифицированы пользовательские и функциональные требования, которые играют одну из самых важных ролей в цикле разработки. Кроме того, проектировались бизнес-функции и данные разрабатываемой системы. Моделирование велось для ключевых бизнес-процессов компании. Процессы были детально проанализированы и спроектированы в нотациях ARIS VACD и eEPC. Использование нотаций проектирования позволило тщательно рассмотреть процессы организации (как они декомпозируются и выполняются, какие данные содержат и др.). Кроме того, была спроектирована архитектура данных в UML Class Diagram. В результате чего выявлены классы и признаки данных. 

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

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

1. Степанов Д.Ю. Проблемы внедрения корпоративных информационных систем: уровень приложений // Менеджмент сегодня. – 2015. – т.87, №3.
2. Гвоздева Т.В., Баллод Б.А. Проектирование информационных систем. – 2009.
3. Степанов Д.Ю. Анализ, проектирование и разработка корпоративных информационных систем: уровень приложений / МИРЭА. - М., 2017.
4. Исаев Г. Проектирование информационных систем. – 2012.
5. Майоров А., Соловьев И. Проектирование информационных систем. – 2009.
6. Миглинец Ю.А. Анализ требований к автоматизированным информационным системам. – 2008.
7. Степанов Д.Ю. Формирование универсальных требований к пользовательским программам при подготовке спецификации на ABAP-разработку // Актуальные проблемы современной науки. – 2014. – т.78, №4. – c.258-268.
8. ANSI/PMI 99-001-2014. A Guide to the Project Management Body of Knowledge (PMBOK Guide). – Pennsylvan.: Project Management Institute. – 2013.
9. Ковалев С., Ковалев В. Секреты успешных предприятий: бизнес- процессы и организационная структура. – 2012.
10. Войнов И.В., Пудовкина С.Г., Телегин А.И. Моделирование экономических систем и процессов. Опыт построения ARIS-моделей: Монография. – 2002.
11. Калянов Г.Н., Моделирование, анализ, реорганизация и автоматизация бизнес-процессов // Финансы и статистика. – 2006.
12. Кузовкин А.В., Цыганов А.А., Щукин Б.А., Управление данными. Учебник для вузов (высшее профессиональное образование). – 2012.
13. Фаулер М., UML. Основы: Краткое руководство по стандартному языку объективного моделирования: Перевод с английского. – 2006.
14. Епанешников А.М., Епанешников В.А. Практика создания приложений в Access. – 2009.
15. Фуллер Л.У., Кук К., Кауфельд Дж. Microsoft Office Access 2007 для «чайников». – 2007.
16. Скворцов А.В. Автоматизация управления жизненным циклом продукции. – 2013.
17. Гурвиц Г.А., Microsoft Access 2010. Разработка приложений на реальном примере. – 2010.
18. Карл И. Разработка требований к программному обеспечению. – 2004.
19. Фёдоров И.Г., Методика выявления целей, задач и требований бизнес-процесса. – 2014.
20. Козлов А.С., Проектирование и исследование бизнес-процессов. Учебное пособие. – 2017.
21. Буч Г, Рамбо Дж. Введение в UML от создателей языка. – 2015.
22. Степанов Д.Ю. Анализ, проектирование и разработка корпоративных информационных систем: уровень данных / МИРЭА. - М., 2017.
23. Долганова О.И., Виноградова Е.В., Лобанова А.М. Моделирование бизнес-процессов. Учебник и практикум. – 2017.

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

Граделев Е.С. Анализ, проектирование, разработка и тестирование приложения для автоматизации деятельности компании по продаже медицинского оборудования: диплом бакалавра / МИРЭА. - М., 2017. - 54 с. – URL: http://stepanovd.com/training/20-vkr/62-vkrb-2017-2-gradelev.