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

Содержание:

Введение

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

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

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

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

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

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

Для более усовершенствования предлагается добавить модуль сетевого доступа к работе с данными. Это позволит облегчить нагрузку на рабочий персонал и решить проблему с многопользовательским доступом.

В данной курсовой работе будет рассматриваться объект - ООО "АПТЕКА-РИЭЛТИ".

Предмет исследования - процессы учета продаж лекарств и автоматизированные технологии их реализации.

Цель курсового проекта – автоматизировать учет лекарственных препаратов в аптеке. Для данной цели будет использоваться система «1С: Предприятие 8.2».

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

описание и моделирование предметной области модуля, обзор и анализ существующих аналогов;

- разработка спецификации требований к модулю;

- математическая постановка задачи;

- проектирование базы данных;

- разработка архитектуры программной системы.

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

1. Технико-экономическая характеристика предметной области и предприятия

1.1. Характеристика предприятия и его деятельности

Основным видом экономической деятельности ООО "АПТЕКА-РИЭЛТИ"

является "торговля розничная лекарственными средствами в специализированных магазинах (аптеках)". Также ООО "АПТЕКА-РИЭЛТИ" работает еще по направлениям:

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

1.2 Организационная структура управления предприятием

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

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

Организационная структура предприятия показана на рис. 1.

Рисунок 1 – Организационная структура предприятия

Обязанности рабочего персонала.

1. Генеральный директор.

- Осуществляет руководство деятельностью фармацевтической организации.

- Участвует в решении вопросов совершенствования деятельности организации;

- Обеспечивает выполнение обязательств по трудовому договору;

- Организует работу по повышению квалификации работников;

- Следит за выполнением работниками своих должностных обязанностей.

2. Главный бухгалтер (менеджер).

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

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

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

3. Отдел кадров.

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

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

4. Старший провизор

- Ведет отчетную деятельность выполнения работы провизоров;

- Осуществляет продажу лекарственных препаратов;

- Следит за наличием лекарственных препаратов на витринах;

- Консультирует покупателей, помогает с выбором нужного лекарства.

5. Провизор

- Осуществляет продажу лекарственных препаратов;

- Следит за наличием лекарственных препаратов на витринах;

- Консультирует покупателей, помогает с выбором нужного лекарства.

6. Заведующий складом

- Принимает участие в разгрузочно-погрузочных работах;

- Ведет инвентаризационную ведомость оборудования в аптеке и на складе;

- Ведет отчетную деятельность выполнения работы работников склада;

- Следит за состоянием оборудования, техники, средств пожаротушения, при необходимости проводит ремонт оборудования.

7. Работники склада.

- Принимает участие в разгрузочно-погрузочных работах;

- Следит за состоянием оборудования, техники, средств пожаротушения, при необходимости проводит ремонт оборудования.

Выбор комплекса задач автоматизации и характеристика существующих бизнес-процессов.

Объектом проектирования является модуль учета продаж лекарств ООО "АПТЕКА-РИЭЛТИ". В аптечном деле существует немало специфических бизнес-процессов, требующих нестандартного подхода и других (чем в обычной торговли) алгоритмов решения.

В процессе деятельности аптеки выполняются три основных бизнес-процесса:

закупка фармацевтических товаров;

хранение фармацевтических товаров;

продажа фармацевтических товаров.

Бизнес-процесс "Закупка фармацевтических товаров" реализуется на основе договорных отношений с поставщиками.

Бизнес-процесс "Хранение фармацевтических товаров" - хранение фармацевтических товаров в материальной комнате и торговом зале.

Бизнес-процесс "Продажа фармацевтических товаров" включает:

поиск товара в каталоге и определения его местонахождения;

сканирования штрих-кода упаковки фармацевтического препарата

сканирования дисконтной карты покупателя для установления скидки на товар;

ввод данных по оплате купленного товара;

формирования кассового отчета за рабочую смену;

учет продаж фармацевтических товаров за период.

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

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

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

наличие функции учета продаж товаров по льготным и бесплатным рецептам;

контроль за обязательным ассортиментом;

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

взаимодействие автоматизированной системы управления аптекой с внешними справочными системами;

работа с банковскими картами;

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

Контекстная диаграмма IDEF0 и диаграммы декомпозиции показаны на рисунках 2-7

Рисунок 2 Контекстная диаграмма IDEF0 «Учет лекарств в ООО "АПТЕКА-РИЭЛТИ"»

Рисунок 3 Нулевой уровень декомпозиции контекстной диаграммы IDEF0 «Учет лекарств в ООО "АПТЕКА-РИЭЛТИ"»

Рисунок 4 Диаграмма декомпозиции «Закупка фармацевтических товаров»

Рисунок 5 Диаграмма декомпозиции «Хранение фармацевтических товаров»

Рисунок 6 Диаграмма декомпозиции «Продажа фармацевтических товаров»

Рисунок 7 Модель диаграммы

2. Информационное обеспечение задачи

2.1 Информационная модель и её описание

Рисунок 8 Информационная модель

Область 1 показывает вход в ИС и авторизацию пользователей (сотрудников аптеки). Форма «Авторизация» предполагает введение логина и пароля для входа в систему.

Область 2 отображает основные рабочие функции ИС. На ней видно, что список всех имеющихся лекарств можно посмотреть в «Спр. Справочнике лекарств». Форма «Оплаты» предполагает оплату выбранных лекарств, а форма «Составление отчета» нужна для отчетности перед директором аптеки.

Область 3 показывает, что получается на выходе системы. Для клиентов печатается чек, в котором указан список купленных лекарств, их количество, цена и предоставленная скидка (если такая имеется). Для директора выходит отчет о проданном товаре, остатке товара на складе, отчет доходах и расходах.

При оформлении расхода материалов на производственные цели применяют следующие документы: лимитно-заборные карты и требования. Основными реквизитами этих документов является наименование и количество отпущенных складом материалов.

2.2 Используемые классификаторы и системы кодирования

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

2.3 Характеристика нормативно-справочной, входной и оперативной информации

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

Таблица 1

Спецификация функциональных требований

Идентификатор требования	Название требования (варианта использования)	Атрибуты требований
		Приоритет	Трудность	Контакт
1	2	3	4	5
FR-UC-01	Авторизация	Обязательное	Средняя	Директор, старший провизор, провизор
FR-UC-02	Добавить данные в базу данных фармацевтических товаров	Обязательное	Средняя	Директор, старший провизор
FR-UC-03	Редактирование данных в базе данных фармацевтических товаров	Рекомендуемое	Средняя	Директор, старший провизор
FR-UC-04	Удаление данных из базы данных фармацевтических товаров	Обязательное	Средняя	Директор, старший провизор
FR-UC-05	Продажа товара	Обязательное	Средняя	Старший провизор, Провизор
FR-UC-06	Формирование отчета розничной торговли	Обязательное	Средняя	Главный бухгалтер
FR-UC-07	Формирование кассового отчета	Обязательное	Средняя	Старший провизор, провизор
FR-UC-08	Формирование отчета по продажам	Обязательное	Средняя	Главный бухгалтер

Спецификация нефункциональных требований показана в табл. 2

Таблица 2

Спецификация нефункциональных требований

Идентификатор требования	Название требования	атрибуты требований
		Приоритет	Трудность	Контакт
1	2	3	4	5
1. Применимость
ZA-01	Соответствие стандартам интерфейса пользователя	Рекомендуемое	Низкая	Программа
2. Надежность
NA-01	100% доступность	Рекомендуемое	Высокая		Программа
3. Рабочие характеристики
RC-01	Быстродействие для транзакций в среднем 5 секунд	Рекомендуемое	Средняя	Программа
RC-02	Время запуска системы - не более 5 сек.	Рекомендуемое	Низкая	Программа
RC-03	Время на обработку запроса на поиск данных в БД - не более 2 сек.	Рекомендуемое	Средняя	Программа
4. Эксплуатационная пригодность
EP-01	Наличие программного продукта «1С: Предприятие 8.2»	Обязательное	Средняя	Программа
5. Атрибуты качества
QA-01	Небольшое количество сбоев в работе системы (не более 1 - 2 за рабочий день)	Рекомендуемое	Средняя	Программа

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

Разработка программы для учета фармацевтических товаров на предприятии будет осуществляться на основе платформы «1С: Предприятие».

2.4 Характеристика результатной информации

Документы, которые используются в системе приведены в табл. 3

Таблица 3

Информационный список документов

Код документа	Название	Входящий / Исходящий	Функция
DC-01	Чеки	входной	Ввод данных о расходах
DC-02	Кассовый отчет	выходной	Ввод данных о расходах
DC-03	Отчет по розничным продажам	выходной	Просмотр данных о продажах за период
DC-03	Отчет по прибыли	выходной	Просмотр данных о доходах

3. Программное обеспечение задачи

3.1 Общие положения (дерево функций и сценарий диалога)

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

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

Рисунок 8 Дерево функций ИС

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

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

• сбор данных;
• обработка данных;
• генерация данных;
• хранение данных;
• передача данных.

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

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

Технологический процесс выдачи результатной информации происходит в двух направлениях:

• вывод результатной информации на печать,
• вывод результатной информации на экран.

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

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

3.2 Характеристика базы данных

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

Рисунок 9 ER модель информационной системы.

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

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

Физическая модель определяет размещение данных во внешней памяти. Она еще называется внутренней моделью системы и форма ее представления зависит от выбранной СУБД. Если выбрана такая СУБД, которая поддерживает реляционную модель данных, то надо таблицы вместе с атрибутами и связи между таблицами перенести в среду СУБД с учетом требований к соответствующим объектам БД. Так, идентификаторы (имена) таблиц и полей должны удовлетворять требованиям СУБД, типы данных, размеры полей, ограничения также должны быть приведены в соответствие с принятыми в данной СУБД.

Таблица 4

Описание структуры записей таблицы «Справочник лекарств»

Наименование поля	Идентификатор поля	Тип поля	Длина поля	Прочее
Код справочника	Kod_sprav	число	5	ключевое поле
Наименование лекарства	Name_lecarstvo	строка	20
Упаковка	Kod_pack	строка	20
Срок годности	Srok_god	число	10
Количество	Kod_Kol	число	10
Цена	Kod_price	число	10
Рецепт	Name_recipe	строка	30

Таблица 5

Описание структуры записей таблицы «Главная форма»

Наименование поля	Идентификатор поля	Тип поля	Длина поля	Прочее
Код главной формы	Kod_glav_form	число	15	ключевое поле
Справочник лекарств	Name_spr	строка	20
Отчет	Kod_otchet	строка	25
Склад	Kod_sclad	число	5
Оплата	Kod_Oplata	число	10

Таблица 6

Описание структуры записей таблицы «Склад»

Наименование поля	Идентификатор поля	Тип поля	Длина поля	Прочее
Код склада	Kod_sclad	число	5	ключевое поле
Название лекарства	Name_lec	строка	20
Количество	Kod_kol	число	10
Рецепт	Name_recipe	число	30

Таблица 7

Описание структуры записей таблицы «Форма оплаты»

Наименование поля	Идентификатор поля	Тип поля	Длина поля	Прочее
Код формы оплаты	Kod_price_form	строка	30	ключевое поле
Наименование лекарства	Name_lecarstvo	строка	20
Цена	Kod_price	число	10
Скидка	Kod_discount	число	10
Количество	Kod_Kol	число	10
Чек	Kod_check	строка	10

Таблица 8

Описания структуры записей таблицы «Чек»

Наименование поля	Идентификатор поля	Тип поля	Длина поля	Прочее
Код чека	Kod_check	число	10	ключевое поле
Название лекарства	Name_lec	строка	20
Количество	Kod_kol	число	10
Цена	Kod_price	число	10

Таблица 9

Описания структуры записей таблицы «Отчет»

Наименование поля	Идентификатор поля	Тип поля	Длина поля	Прочее
Код отчета	Kod_otchet	строка	25	ключевое поле
Название лекарств	Name_lec	строка	20
Остаток лекарств	Kod_ost_lec	число	10
Доходы	Kod_income	число	25
Расходы	Kod_costs	число	25

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

3.3 Структурная схема пакета (дерево вызова программных модулей)

Схема работы приложения представлена на рис. 9

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

Рисунок 10 Блок схема работы главного модуля приложения

3.4 Описание программных модулей

В ходе разработки программного модуля были созданы следующие экранные формы и входящие документы, которые приведены на рис. 11 - 18

Рисунок 11 Окно выбора логина и ввода пароля

Рисунок 12 Окно добавления фармацевтических товаров

Рисунок 13 Окно удаления фармацевтических товаров

Рисунок 14 Окно редактирования фармацевтических товаров

Рисунок 15 Окно продажи фармацевтических товаров

Рисунок 16 Кассовый отчет

Рисунок 17 Отчет по розничным продажам

Рисунок 18 Отчет по прибыли

4. Контрольный пример реализации и его описание

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

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

Для того, чтобы удостовериться в том, что программное приложение удовлетворяет требованиям, указанным в спецификации требований модуля «Учет лекарств в аптеке» необходимо протестировать следующие требования (табл. 5-7): авторизация; добавления данных о фармацевтическом товаре; формирование отчетов.

Тестовый пример №1.

Задача: проверка авторизации. Тест-требования, проверяются:

1. Предпосылки для теста: система должна проверить логин и пароль.
2. Критерий прохождения теста: все реальные значения совпадают с ожидаемыми.

Таблица 10

Тест-кейс «Авторизация»

№	Шаг сценария	Ожидаемый результат	Полученный результат	Отметка о прохождении шага сценария (Да / Нет)
11	Открытие программы	Появляется форма для выбора логина и ввода пароля	Появляется форма для выбора логина и ввода пароля	Да
22	Ввести верный логин и пароль	Вход в программу	Вход в программу	Да
33	Ввести неверный логин и пароль.	Должна появиться ошибка: «Ошибка введения логина или пароля»	Ошибка	Да

Отметка о прохождении теста: пройден.

Тестовый пример 2.

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

Таблица 11

Тест-кейс «Номенклатура»

№	Шаг сценария	Ожидаемый результат	Полученный результат	Отметка о прохождении шага сценария (Да / Нет)
11	Выбор из главного меню «Справочник - Номенклатура»	Появляется форма где нужно ввести данные	Форма для ввода названия товара появилась	Да
22	Ввести информацию о товаре	Товар должен отразиться в структуре	Товар появился в структуре	Да
33	Нажать дважды на товар	Должно появиться окно редактирования	Появилось окно редактирования	Да

Отметка о прохождении теста: пройден.

Тестовый пример 3.

Назначение: проверка того, что пользователь может сформировать отчеты. Тест-требования, проверяются: 2 раза. Предпосылки для теста: система должна позволять формировать отчеты. Критерий прохождения теста: все реальные значения совпадают с ожидаемыми.

Таблица 12

Тест-кейс «Формирование отчетов»

№	Шаг сценария	Ожидаемый результат	Полученный результат	Отметка о прохождении шага сценария (Да / Нет)
11	Выбор из главного меню «Отчет» и выбрать нужный.	Появляется форма формирования отчетов.	Форма для формирования отчетов появилась.	Да
22	Ввести период.	Период должен отразиться.	Период появлялся	Да
33	Нажать кнопку «Сформировать»	Должен сформироваться отчет.	Отчет сформирован	Да

Отметка о прохождении теста: пройден.

Заключение

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

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

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

Разработана программа удовлетворяет всем требованиям, разработанным на этапе постановки задачи.

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

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

Список использованной литературы

1. Астапчук, В.А.  Корпоративные информационные системы: требования при проектировании: учебное пособие для вузов / В.А. Астапчук, П. В. Терещенко. - 2-е изд., испр. и доп. - М.: Издательство Юрайт, 2018. - 110 с.
2. Гвоздева Т.В., Баллод Б.А. Проектирование информационных систем. – Ростов-на-Дону: Феникс, 2010. – 512 с.
3. Гордеев, С. И. Организация баз данных в 2 ч. Часть 1: учебник для вузов / С.И. Гордеев, В. Н. Волошина. - 2-е изд., испр. и доп. - М.: Издательство Юрайт, 2018. - 311 с.
4. Григорьев, М.В. Проектирование информационных систем: учебное пособие для вузов / М.В. Григорьев, И.И. Григорьева. - М.: Издательство Юрайт, 2017. - 318 с.
5. Долганова, О.И. Моделирование бизнес-процессов: учебник и практикум для академического бакалавриата / О.И. Долганова, Е. В. Виноградова, А.М. Лобанова; под ред. О. И. Долгановой. - М.: Издательство Юрайт, 2018.- 289 с.
6. Каменнова, М.С. Моделирование бизнес-процессов. В 2 ч. Часть 1: учебник и практикум для бакалавриата и магистратуры / М. С. Каменнова, В. В. Крохин, И. В. Машков. - М. : Издательство Юрайт, 2018. - 282 с.
7. Кожевникова, Г. П. Информационные системы и технологии в маркетинге: учебное пособие для академического бакалавриата / Г.П. Кожевникова, Б. Е. Одинцов. - М.: Издательство Юрайт, 2018. - 444 с.
8. Куприянов, Ю. В. Модели и методы диагностики состояния бизнес-систем: учебное пособие для вузов / Ю. В. Куприянов, Е. А. Кутлунин. - 2-е изд., испр. и доп. - М.: Издательство Юрайт, 2018. - 128 с.
9. Мезенцев К.Н. Автоматизированные информационные системы. – М.: Академия, 2012. – 174 с.
10. Моделирование систем и процессов: учебник для академического бакалавриата / В. Н. Волкова [и др.] ; под ред. В. Н. Волковой, В. Н. Козлова. - М.: Издательство Юрайт, 2018. - 450 с.
11. Пирогов В.Ю. Информационные системы и базы данных. Организация и проектирование. – СПб.: БХВ-Петербург, 2011. – 528 с.
12. Проектирование информационных систем. Учебное пособие для студентов / Сост. А. В. Бычков Кубан. гос. технол. ун-т. Каф. ВТ и АСУ. - Краснодар: Изд-во ГОУВПО «КубГТУ» , 2010. - 82 с.
13. Советов Б.Я., Цехановский В.В. Информационные технологии. – М.: Юрайт, 2012. – 272 с.