Автоматизация деятельности фармацевтических компаний на примере ООО "Шексна-Фарма"

Введение

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

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

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

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

Целью данного проекта является модернизация существующей системы «Склад» на предприятии ООО «Шексна-Фарма».

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

1. Проанализировать особенности существующей системы и обозначить главную проблему ее дальнейшей модернизации.

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

3. Выбрать наиболее выгодный путь решения проблемы.

4. Спроектировать, реализовать и протестировать программный продукт.

5. Оценить результаты внедрения программного продукта на предприятии.

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

Глава 1. Описание существующей системы

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

1.1 Назначение и функции системы

С момента открытия (1990 г.) по настоящее время на предприятии используется разработанная сотрудниками АСУ система складского учета (далее «программа «Склад»). В самом начале своего развития программа «Склад» имела более узкое назначение и, соответственно, функционал, который сводился в основном к автоматизации исключительно бухгалтерского документооборота. В дальнейшем в течение нескольких лет программа «Склад» эволюционировала, что было обусловлено постоянно возникавшими новыми требованиями к функционалу и аналитике программы вследствие растущего интереса к использованию информационных технологий для управления предприятием. В настоящее время функционал программы значительно расширен. Общий размер исходных файлов достигает 3,1 Мб, а общий размер файлов данных составляет около 12 Гб. Среди самых основных задач программы можно выделить следующие:

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

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

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

1.2 Организация базы данных

Выполнение выше обозначенных функций в масштабе бизнес процессов предприятия ООО «Шексна-Фарма» не может обойтись без оперирования большим количеством данных, поэтому на заре эпохи автоматизации работы предприятия был седлан выбор в пользу передового по тем временам программного продукта FoxPro 2.0 for DOS от компании Fox Holdings © 1989-91.

FoxPro 2.0 - это файл-серверная СУРБД со всеми плюсами и минусами файл-серверных систем управления базами данных.

С появлением на рынке FoxPro 2.0, включающего перечисленные ниже ключевые технологии, был совершен переворот в области разработки баз данных на персональных компьютерах:

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

2.В версии 2.0 разработчики Fox включили поддержку SQL.

3.FoxPro 2.0 задействовал принцип WYSIWYG - разработка экранов и отчетов с помощью таких средств, как проектировщики (или мастера) экранов и отчетов (Screen Designer и Report Designer). Мастер экранов генерировал код, позволяя использовать метод разработки GUI в ориентированной на текст среде.

Текущая версия Visual FoxPro основана на COM, и Microsoft утверждает, что .NET-версии продукта не будет. Существует проект Sedna, который должен обеспечить возможность взаимодействия Visual FoxPro с .NET.

В настоящее время последней версией продукта является 9.0. Visual FoxPro 9.0 (VFP9.0) использует одноименный язык программирования FoxPro. Среда разработки версии 7.0 может работать в операционных системах Windows 9x и ядра NT, версии 8.0 и 9.0 - только в Windows XP, 2000, 2003. Среда исполнения (runtime) версий 8.0 и 9.0 работает под любой версией Windows, начиная с 98.

Программа FoxPro 2.0 в свое время стала достижением, удивительные возможности ее (сервис в разработке GUI, SQL и молниеносная быстрота доступа к данным) и сегодня не потеряли своей силы в Visual FoxPro. Все же в настоящий момент файл-серверные СУБД уступают клиент-серверным.

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

Будучи файл-серверной СУБД, FoxPro 2.0 предоставляет разработчику достаточно большой инструментарий, с помощью которого можно создать пользовательский интерфейс (правда, используя только текстовый режим видеоадаптера) и обеспечить доступ к данным. Сами же данные должны находиться в общедоступном месте, т.е. - на файловом сервере, для организации которого в 1990 году для ООО «Шексна-Фарма» была выбрана сетевая операционная система NetWare 4.11 от фирмы Novell.

Следует отметить, что NetWare 4.1 наследует ряд возможностей, ставших стандартом среди сетевых операционных систем фирмы Novell. Эти возможности включают в себя такие свойства, как зеркальное отображение (mirroring) и горячее фиксирование (hotfix), защищающие данные на файловом сервере. Принцип связывания (bindery-based) обеспечивает возможность того, что файловый сервер с NetWare 4.1 «видит» серверы с более старыми версиями NetWare.

Файловый сервер NetWare обладает тремя важными механизмами управления памятью:

- Пулы памяти.

- Постраничная организация.

- Защита памяти.

1.3.1 Пулы памяти

Управление памятью файлового сервера, используемое в NetWare 4.1, намного проще, чем в предыдущих версиях NetWare. Операционная система NetWare 2.x, например, была «связана» ограничениями процессора 80286. Хотя можно запускать NetWare 2.x на 80386 или 80486, но исходный код был разработан для 80286. NetWare 3.x вобрала несколько улучшений в управлении памятью. Характерной особенностью NetWare 3.x является набор пулов памяти. Пулы памяти (memory pools) - это подразделы RAM файлового сервера, которые в различных целях используются модулями NLM. Разработчики NLM должны следовать строгим правилам, указывающим, какая память в какой пул должна возвращаться.

NetWare 4.1 отличается упрощенной схемой управления памятью, содержащей только один пул памяти. Все NLM запрашивают память из пула, а по завершении возвращают ее. Чтобы посмотреть, как используется память, можно воспользоваться MONITOR.NLM, выбирая из трех элементов меню: Resource Utilization (Использование ресурсов), Cache Utilization (Использование кэша) и Memory Utilization (Использование памяти).

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

Отрицательная сторона такого подхода к управлению памятью заключается в том, что после возвращения в главный пул высвобожденная память уже может быть расположена в разных разделах RAM. Эта проблема получила название «фрагментация» (fragmentation).

С точки зрения NetWare, память размещается в кэш-буферах. Каждый кэш-буфер имеет размер 4 Кб. Фрагментация происходит, когда память в несмежных буферах высвобождается несколькими NLM. Непрерывная свободная память - это память, которая доступна для использования и расположена в смежных буферах. Фрагментированная память разбросана по всей карте памяти.

Когда операционная система пытается разместить другой блок памяти, она не знает, какой буфер доступен и где он расположен. NetWare 4.1 использует процесс сборки мусора (garbage collection) для определения объема имеющейся памяти. В результате сборки мусора составляется перечень доступных буферов памяти в форме таблицы. Эта таблица используется NetWare при выделении памяти модулям NLM. Процессом сборки мусора можно управлять с помощью набора команд SET и задавать следующее:

-Периодичность проведения сборки мусора.

-Объем памяти, при превышении которого начинается сборка мусора.

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

1.3.2 Постраничная организация памяти

NetWare 4.1 в своей схеме распределения памяти использует механизм постраничной организации (paging mechanism) компании Intel. Такой механизм встроен в любой процессор типа 80386 и выше, произведенный Intel или по лицензии Intel. Эта схема позволяет NetWare разбивать память на страницы (pages). Каждая страница - это непрерывный блок памяти размером 4 Кб. Информация о распределенных страницах памяти записывается в страничные таблицы. Страничные таблицы (page tables) - это указатели на страницы памяти, которые разбросаны по всей карте оперативной памяти компьютера. Для отслеживания чрезвычайно больших распределений памяти сами страничные таблицы группируются в домены (domains).

Для сетевого администратора такая организация памяти означает, что файловый сервер будет назначать RAM модулям NLM постранично, a NLM воспринимает получаемый блок RAM как непрерывный. В силу своей аппаратной реализации эта функция работает очень быстро.

1.3.3 Кольцевая защита памяти

Ring memory protection. На эту функцию также ссылаются как на уровень привилегий (privilege level). Память в сервере NetWare 4.1 разделена на четыре области или домена. Каждая такая область в спецификации уровня привилегий Intel называется кольцом (ring). Эти четыре кольца пронумерованы от 0 до 3. Ядро операционной системы NetWare 4.1 всегда выполняется в кольце 0. Другие модули NLM по умолчанию также выполняются в кольце 0.

Если модуль NLM назначается кольцу, отличному от кольца 0, то он не может получить доступ к ресурсам внутренних колец без выполнения того, что называется вызовом межкольцевого перехода (inter-ring gate call). Такой процесс защищает программы, выполняющиеся во внутренних кольцах, и для него требуется дополнительное время процессора. Если, например, известно, что NLM может завершаться аварийно, то для его отладки и для защиты других NLM его можно запустить в кольце 3. Когда NLM, выполняющийся не в кольце 0, завершается аварийно, он воздействует только на себя, а также, возможно, делает недоступным свое кольцо. На других кольцах это не сказывается. На рис. 1.1 представлен процесс выполнения NLM в кольце 3. Можно видеть, что в случае аварийного завершения другие NLM не повреждаются.

В настоящее время в NetWare 4.1 определены только кольца 0 и 3. При этом программное обеспечение разрешает переключаться между всеми кольцами (0, 1, 2 и 3). Однако, если вы загружаете NLM в кольцо 1, 2 или 3, фактически он будет загружен в один и тот же домен.

Рисунок 1.1 - Кольцевая защита памяти

Novell ссылается на домен, охватывающий кольцо 0, как на домен OS (сокращение от «operating system»). Домен, связанный с кольцом 3, называется OSP или OS Protected (от «operating system protected»). Функция защиты кольца-домена включается путем добавления команды LOAD DOMAIN.NLM к конфигурационному файлу сервера STARTUP.NCF. Между доменами можно переключаться, используя одну из следующих команд с консоли файлового сервера: DOMAIN OS или DOMAIN OSP.

Используя возможности операционной системой NetWare 4.11 сотрудниками технического центра компании была организована сетевая работа с использованием протоколов семейства IPX/SPX. Общая схема сети представлена на рис. 1.2.

Рабочие станции, на которых установлена СУБД FoxPro 2.0, вместе с файловым сервером образуют сеть посредством коммутатора и витой пары. Общие ресурсы файлового сервера представлены на рабочих станциях как сетевой диск. Количество рабочих станций достигает 100.

Рисунок 1.2 - Схема локальной сети

Данные в виде файлов двухмерных таблиц с расширением DBF размещены в нескольких директориях. Общее количество файлов таблиц, включая файлы индексов, достигает 70000, а сам размер данных - 30 Гб. Сами данные вступают в достаточно сложные отношения друг с другом, но общая идея организации данных может быть представлена на рис. 1.3.

Рисунок 1.3 - Схема существующей базы данных в общем виде

В большинстве операций с данными обязательно участвуют три таблицы: PRIXOD, RASXOD, OSTATOK, остальные таблицы в основном являются справочниками, реализующими связь «один ко многим» или искусственными таблицами, предназначенными для построения отношения «многие ко многим».

PRIXOD - содержит информацию о приходуемом товаре.

OSTATOK - содержит информацию о текущем наличии товаров.

RASXOD - содержит информацию об израсходованном товаре.

ISG - справочник изготовителей.

SKLAD - справочник способов размещения товаров.

TMC - справочник товарно-материальных ценностей.

ORGAN - справочник организаций, выдающих сертификаты на лекарственные средства.

CENNIK - номенклатурный справочник товаров. (исторически сложившееся название).

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

USERS - информация о пользователях программы «Склад».

POKUP - информация о клиентах компании.

1.4 Проблемы существующей системы и пути их решения

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

- Обеспечение удаленного доступа к перечню товаров на складе (остатки).

- Ограничение доступа к иным данным (кроме остатков)

- Обеспечение отправки накладных на удаленный компьютер.

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

-Возможность организации доступа пользователей через сеть Интернет.

-Возможность защиты от несанкционированного доступа.

-Возможности использования протокола TCP/IP.

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

Учитывая все достоинства и недостатки существующей системы, а также новые требования руководства, логично предположить 2 способа решения проблемы:

1.Полностью заменить существующую систему.

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

2. Аналитический обзор

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

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

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

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

- Гибкий интерфейс взаимодействия пользователем.

- Сложность адаптации к бизнес-процессам предприятия.

- Возможность самостоятельной организации данных.

- Полнота функционала.

- Избыточность функционала.

- Доступ ко всей информации в режиме реального времени.

- Клиент-серверная архитектура.

- Затраты на разработку и/или внедрение.

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

1. «Юнико» Оптовый склад. (Автоматизация оптовой торговли ЛС).

НТО Юнико, начиная с мая 1991г., занимается разработкой программного обеспечения для комплексной автоматизации деятельности предприятий малого и среднего бизнеса.

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

Учитывая специфику фармацевтической деятельности, компания Юнико ведет оперативную поддержку таких баз данных, как «Реестр цен» и «База фальсификатов», поддерживает в актуальном режиме модуль «Учет льготных рецептов» системы «Льготное обеспечение», прошедший проверку с 1999 по 2015 годы во всех муниципальных аптеках Московской области.

Основной функционал и аналитика данного ПО:

- Ведение оптового склада и розничных подразделений;

- Гибкий механизм ценообразования в зависимости от вида подразделения (опт или розница), типа операции (приход, внутреннее перемещение), типа и ценовой группы товара, группы покупателей;

- Контроль торговой наценки на превышение предельно допустимой;

- Резервирование товара;

- Выгрузка прайс-листа в Excel;

- Автоматизированный контроль фальсифицированных ЛС и сроков годности;

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

- Автоматическое формирование накладных на внутреннее перемещение, возврат поставщику, списание товара;

- Проведение инвентаризации с применением сканеров штрих-кода, терминалов сбора данных, автоматическое выявление пересортицы, недостачи и излишков товара, инвентаризационная опись и сличительная ведомость по результатам;

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

- Полный комплект первичных и отчетных документов в т.ч. согласно Приказу № 14 МЗ РФ: товарная накладная T-12, счет-фактура, счет, протокол согласования цен, сборочный и упаковочный лист, приложение к накладной, спецификация, журнал оптового отпуска АП-22, журнал регистрации по отпуску товаров АП-90, ведомость №11, журнал 41 счета, завозная книга, книги покупок и продаж, товарные отчеты разных видов;

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

- Наличие 'Генератора отчетов', который позволяет самостоятельно составлять формы отчетов;

- Выгрузка данных по приходным и расходным документам в бухгалтерский комплекс «Юнико» и для «1С бухгалтерии»;

- Контроль расхода квотируемых ЛС;

- Анализ товародвижения: финансово-экономический, в графическом виде, АВС, ХУZ, рейтинговый по товару, поставщику, торговой наценке, прибыли, скорости продаж, сезонности и др.;

- Формирование заказа товара по результатам анализа минимального остатка, интенсивности расхода, времени исполнения заказа, АВС-групп, с учетом уже заказанного, но еще не поступившего или не оприходованного товара;

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

- Система защиты и предупреждений от неправомерных действий пользователей, автоматическое архивирование и хранение копий баз данных;

2. «М-аптека плюс» в конфигурации «Оптовый склад».

«Эскейп» - софтверная компания, основанная в 1992 году. Направление работы - осуществление разработки, внедрения и сопровождения программного обеспечения для автоматизации предприятий.

Компанией «Эскейп» разработан ряд автоматизированных систем управления фармацевтическими предприятиями, таких как: программный комплекс «М-аптека льгота» (1998 г.), автоматизированная система управления аптечными предприятиеми розничной торговли «М-аптека» (1998 г.), автоматизированный программный комплекс «М-аптека плюс» (2001 г.), комплексная система автоматизации управления движением лекарственных средств в регионе, включающая в себя дополнительные модули «М-аптека плюс ЦОД», «М-аптека плюс ДЛО» и «М-аптека плюс ЛПУ» (2007 г.). В настоящий момент программные продукты семейства«М-аптека»в различных версиях и конфигурациях имеют более 4500 инсталляций, охватывая практически все регионы России.

Конфигурация «Оптовый склад» АСУ «М-аптека плюс» разработана для оптовых аптечных складов, а также - для аптечных сетей, имеющих собственные централизованные точки приемки товара и распределения его по подчиненным подразделениям. Система позволяет полностью автоматизировать процесс учета движения товара на складе: приход товара на склад, учет товара по местам хранения и отгрузка товара получателю (для аптечных сетей - передача в точку розничной торговли). Предоставляется возможность включения различных механизмов ценообразования и ведение операций на предприятии любой формы собственности.

Функциональные возможности системы:

- прием товара по заводскому штрих-коду;

- ввод документов вручную или прием электронной накладной от поставщика;

- возможность работы как по заводскому, так и по внутреннему штрих-коду;

ведение контроля качества поступившего товара (проверка серий, сроков годности, сертификатов);

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

- размещение товара по местам хранения;

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

- расценка товара;

- сборка товара для продажи (передачи в розничные подразделения);

- отгрузка товара покупателю;

- ведение учета оплаты за отгруженный товар;

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

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

Данная конфигурация позволяет:

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

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

- получать информацию о количестве операций по исполнителям;

- просматривать историю движения товара по местам хранения;

- просматривать остатки товара по конкретным местам хранения;

- просматривать и распечатывать статус оплаты и историю платежей по всем документам;

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

Работа с поставщиками лекарственных средств:

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

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

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

3. «еФарма 2». (ЗАО «Спарго Технологии»).

Основным видом деятельности компании ЗАО «Спарго Технологии» является оказание информационно-технологических услуг участникам фармрынка, медицинским учреждениям и страховым организациям.

ПО «еФарма 2» разработано на платформе Microsoft.NET Framework 2.0 ориентированной на создание распределенных систем и основанной на инициативе развития защищенных вычислений (Trustworthy Computing Initiative).

«еФарма2 - Центральный офис».

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

Рисунок 2.1 - Система «еФарма»

Возможности «еФарма 2 - Центральный офис»:

- организация единого информационного пространства между всеми точками аптечной сети;

- ведение нескольких складов;

- единое ценообразование для аптечной сети;

- отпуск ЛС населению;

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

- получение статистической отчетности для каждой из аптек;

- обмен данными между подразделениями аптечной сети: складами и аптеками;

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

- подключение дополнительных модулей расширения.

«еФарма2 - Аптека».

Решение для полной автоматизации единичного аптечного учреждения, поддерживающее все основные бизнес-процессы АУ.

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

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

Основные возможности СПО «еФарма 2 - Аптека»:

- приход товара (вручную или загрузкой электронных накладных);

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

- ценообразование в соответствии с местным и региональным законодательством;

- ведение нескольких складов;

- поддержка торгового оборудования;

- отпуск товаров населению;

- составление отчетности и аналитики по накопленной базе данных;

- возможность работы кассы в on/off-line режиме без потери данных.

4. РС-Аптека

Компания Регард Софт поставляет следующие версии программного комплекса РС-аптека: «Аптека 2007», «Аптека 2005», «Аптека 2002» и «Аптека 2000». Компания работает на рынке систем автоматизации аптечных сетей и аптек с 1995 года. На сегодняшний день число инсталляций систем «Аптека» превышает 1000.

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

Офис

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

В системе «Аптека 2007» автоматизация этой функций офиса осуществляется модулями «Служба заказов» и «Электронные накладные».

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

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

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

После приема электронных накладных от поставщиков производится расценка товара (ценообразование) и отправка его по аптекам.

Управление ценами

В системе «Аптека 2007» предусмотрена возможность раздельного ценообразования по группам аптек.

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

При ценообразовании производится контроль предельной наценки для препаратов группы ЖНВЛС согласно ограничениям, установленным в конкретном субъекте РФ.

Документооборот

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

При этом документооборот делится на две составляющие: внутренний документооборот и внешний документооборот.

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

Внешний электронный документооборот, то есть документооборот с поставщиками, обеспечивается модулями «Служба заказов» и «Электронные накладные». Оба модуля поддерживают взаимодействие с более чем с 50-ми системами заказов поставщиков.

Аптеки

Автоматизация процесса розничной торговли в системе «Аптека 2007» осуществляется модулями «Аптечный склад», «Розничная торговля» и «Дисконт».

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

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

Модуль «Розничная торговля» настраивается для работы с различными типами контрольно-кассовых машин и периферийного оборудования.

Модуль «Дисконт» поддерживает неограниченное количество маркетинговых программ:

дисконтные программы с применением дисконтных карт, фиксированные скидки по карте сети, скидки от суммы покупки, скидки на отдельные группы товаров, скидки по накопительным данным, одновременное применение разных скидок (мультидисконт);

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

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

5. 1С-Рарус: Управление аптекой. (На платформе «1С: Предприятие 8»)

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

Основные функциональные возможности программы:

· Учет лекарственных средств

· Учет фармацевтических групп, форм выпуска, ЕГК

· Указание международного непатентованного наименования, дозировки

· Вхождения в обязательный ассортимент, ЖНВЛС

· Учет различных единиц измерения

· Учет сертификатов и сроков годности, фальсификатов

· Возможность вести аналоги (взаимозаменяемость) товаров

Примечание

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

Конфигурация имеет защищенные программные модули, недоступные для изменения пользователем.

Основные отличия функционала «1С-Рарус: Управление аптекой» от «1С-Рарус: Управление аптекой Лайт»:

Посерийный учет лекарственных средств в разрезе партий

Автоматизированный контроль сроков годности и фальсификатов

Фронт кассира

Ценообразование и система штрихового кодирования

Система назначения скидок и наценок

Заказы поставщикам

Оприходование товаров и работа с электронными документами поставщиков

Ячеистые склады

Обмен с «1С: бухгалтерия 8»

Ордерные склады

Внутренние заказы и заказы покупателей

Комплектация и разукомплектация товаров

АРМ; закупка, кладовщик, продавец, коммуникатор

Удаленные кассы, обмен с удаленными кассами

Взаиморасчеты с контрагентами

Для подведения итога, можно представить достоинства и недостатки конкурирующего ПО в виде таблицы (Табл. 2.1):

Таблица 2.1 Сравнительный анализ существующих решений

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

3. Анализ требований к системе

3.1 Требования к функциональности

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

Рисунок 3.1 - Use-case диаграмма

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

1. Максимальная автоматизация всех этапов формирования электронного заказа. Предполагается, что круг пользователей клиентского приложения «Шексна-Фарма» будет весьма обширным и разнообразным (пользователи разного возраста и разного уровня подготовки - от продвинутых до начинающих). В частности, заказчиком были предъявлены следующие требования: возможность установки удаленного подключения без участия пользователя, обязательное получение прайса и других электронных документов и отправка заказа по сети (локальная сеть или интернет).

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

3. Совместимость. Программа должна гарантировано запускаться в операционных системах семейства Windows (XP/7/8.1).

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

5. Безопасность. Обеспечение авторизованного доступа пользователей к системе, через использование логина и пароля.

6. Скорость. Максимальное время отклика системы не более 5 секунд. Возможность быстрой загрузки электронного прайса по каналу через низкоскоростное модемное соединение.

7. Многопользовательский режим. Возможность одновременного подключения нескольких пользователей к системе. Гарантированная стабильность работы при одновременном подключении не более 100 пользователей.

8. Мониторинг. Возможность отслеживать действия пользователей.

9. Интерактивность. Максимальное обеспечение реакцией на любые действия пользователя, информирование пользователя о процессе собственной работы.

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

3.2 Требования к интерфейсу

Интерфейс разрабатываемой программы должен удовлетворять следующим требованиям:

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

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

3. Использование строки состояния для организации обратной связи с пользователем (Вывод сообщений о статусе операции или об ошибках).

4. Наличие главной таблицы наименований для выбора заказываемых позиций. Организация возможности работы с главной таблицей посредством клавиатуры. Разрешение редактировать только столбец с запрашиваемым количеством. Возможность использования различных цветов для маркировки отдельных значимых позиций в главной таблице.

5. Восстановление предыдущих размеров и положения окна при последующих запусках программы.

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

7. Возможность фильтрования позиций по поставщикам, заказанным позициям и др. признакам.

8. Использование подсказки при вводе искомого наименования с целью ускорения поиска.

9. Постоянное отображение итоговой суммы заказа.

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

11. Выход их программы должен происходить стандартным для систем Windows способом: кнопка «закрыть» в правом верхнем углу окна, выбор команды «закрыть» в системном меню, нажатие Alt + F4.

12. кнопка «ОТМЕНА» должна служить отказу операции редактирования и закрытию окна.

13. должен быть выдержан строгий логический порядок обхода полей по клавише Tab или ENTER.

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

15. система должна обеспечивать наглядное представление на экране большого количества информации.

Требования к интерфейсу, предъявленные ООО «Шексна-Фарма, были тщательно проанализированы. В результате этого в редакторе Microsoft Office Visio 2003 был создан схематический внешний вид программы для пользователя. (Рис. 3.2.)

Рисунок 3.2 - Проектирование внешнего вида клиентского приложения

4. Проектная часть разработки

4.1 Выбор архитектуры

Особенностью данного проекта является то, что его результатом станет автоматизация всего лишь небольшой части бизнес-процессов предприятия. Это отдельный программный комплекс, который должен быть интегрирован в уже существующую систему складского учета. Программа «Склад» не строилась по определенному стандарту, а индивидуально «затачивалась» под нужды предприятия в течение долгих лет, расширяя свой функционал и оставаясь неизменно на уровне версии FoxPro 2.0. Подобная стратегия неизбежно приводит к возникновению проблем совместимости старой системы с любым другим новым программным обеспечением. Проблемы совместимости программы «Склад» и узкая специализация программного комплекса автоматизированной системы формирования заказов для сети аптек «Шексна-Фарма» в результате и привели к тому, что на данный момент невозможно подобрать готовое программное обеспечение, имеющееся на рынке прикладного ПО, которое могло бы выполнить функции, отведенные для программы, разрабатываемой в данном проекте.

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

Из рисунка 4.1 видно, что программный комплекс, разрабатываемый в данной работе включает в себя серверное приложение - «сервер заказов» и клиентское приложение.

Основные задачи сервера заказов сводятся к следующему:

1. Принять запрос на подключение от удаленного клиента.

2. Провести аутентификацию пользователя.

3. После успешной аутентификации провести анализ запроса для формирования требуемой информации.

Рисунок 4.1 - Схема доработанной системы

4. Отправка файлов клиенту (операция скачивания прайса) или принятие файлов от клиента (операция отправки заказа).

5. В случае принятия заказов обеспечение присвоения уникального идентификатора каждому заказу в условиях многопользовательского режима.

Основные задачи клиентского приложения сводятся к следующему:

1. Отправить запрос на подключение.

2. После положительного результата аутентификации выполнить загрузку файлов (прайса или накладных) или отправку заказа.

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

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

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

4.2 Организация сетевой работы

Основной задачей при проектировании сетевых приложений является задача выбора способа обмена данными между приложениями. Так как изначально заказчик ставил задачу обеспечения возможности работы через Интернет, нужно подобрать наиболее надежные инструменты. Из наиболее популярных способов следует выделить возможность обмена данными по протоколу FTP, HTTP, по почтовым протоколам POP3 и SMTP. Однако в данном случае возникает необходимость установки и соответственно администрирования дополнительного программного обеспечения. В частности, для поддержки FTP необходимо установить и затем администрировать дополнительный FTP-сервер, что делает проектируемую систему зависимой от другого ПО. Работа по HTTP требует установки WEB-сервера, более того возникает дополнительная задача обеспечения аутентификации многочисленных пользователей. Кроме всего такой WEB-сервер должен иметь возможность выполнять сценарии. Обмен данными по почте также требует установки почтового сервера и ведения электронных почтовых ящиков для всех пользователей. Задача осложняется еще и тем, что заказчик в число требований включил возможность настраивать пользователей из существующей программы «Склад». Для решения этой задачи лучше всего подойдет задействование сокетов.

Сокеты (sockets) представляют собой высокоуровневый унифицированный интерфейс взаимодействия с телекоммуникационными протоколами. В технической литературе встречаются различные переводы этого слова - их называют и гнездами, и соединителями, и патронами, и патрубками, и т. д. По причине отсутствия устоявшегося русскоязычного термина, английское наименование было транслитерировано на русский язык.

Библиотека Winsock поддерживает два вида сокетов - синхронные (блокируемые) и асинхронные (неблокируемые). Синхронные сокеты задерживают управление на время выполнения операции, а асинхронные возвращают его немедленно, продолжая выполнение в фоновом режиме, и, закончив работу, уведомляют об этом вызывающий код. ОС Windows 3.x поддерживает только асинхронные сокеты, поскольку, в среде с корпоративной многозадачностью захват управления одной задачей «подвешивает» все остальные, включая и саму систему. ОС Windows 9xNT поддерживают оба вида сокетов, однако, в силу того, что синхронные сокеты программируются более просто, чем асинхронные, последние не получили большого распространения. В этом проекте синхронные сокеты будут наиболее интересны.

Сокеты позволяют работать со множеством протоколов и являются удобным средством межпроцессорного взаимодействия, но в данном проекте речь будет идти только о сокетах семейства протоколов TCP/IP, использующихся для обмена данными между узлами сети Интернет. Все остальные протоколы, такие как IPX/SPX, NetBIOS по причине низкой популярности рассматриваться не будут.

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

Помимо потоковых и дейтаграммных сокетов существуют, так называемые, сырые (RAW) сокеты. Они предоставляют возможность «ручного» формирования TCP/IP-пакетов, равно как и полного доступа к содержимому заголовков полученных TCP/IP-пакетов, что необходимо многим сетевым сканерам, FireWall-ам, брандмаузерам и, разумеется, атакующим программам, например, устанавливающим в поле «адрес отправителя» адрес самого получателя. Однако в операционных системах семейства Windows поддержка сырых сокетов весьма ограничена.

4.3 Разработка структуры данных во внешней и оперативной памяти

Структура базы данных программы «Склад».

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

Таблица POKUP состоит из большого количества полей, которые содержат информацию о компаниях-клиентах. Все эти данные заполняются менеджерами - основными пользователями программы «Склад». В числе прочих задач руководства была также озвучена задача организации возможность настройки пользователей автоматизированной системы формирования заказов из программы «Склад». Таблица POKUP используется сервером заказов для проведения аутентификации - проверка подлинности пользователей. В схематическое описание структуры таблицы (см. табл. 4.1) будет уместно включить только те поля, которые имеют значение для сервера заказов.

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

Таблица 4.1 Структура таблицы POKUP

Таблица POKUP - единственный файл с расширением `DBF' к которому должен обращаться сервер заказов согласно разрабатываемой архитектуре. Другие таблицы (например, таблица остатков) не должны быть задействованы в работе сервера в целях снижения риска «травматического воздействия» на данные. Таким образом, все данные, которыми обменивается клиент и сервер, передаются в виде файлов. Файлы формируются самой системой «Склад». Например, файл прайса представляет собой текстовые файлы, упакованные в архив, который собственно и передается клиенту.

Серверное приложение может только читать данные из таблицы POKUP. Запрос к этой таблице очень прост: нужно из всех записей выбрать не более одной соответствующей единственному требованию (совпадение логина и пароля). В связи с этим нет необходимости выполнять некий сложный SQL-запрос, а значит и нет необходимости в драйверах на подобие ODBC. Структура и заголовок таблиц DBF достаточно просты и известны. Этой особенностью стоит воспользоваться, так как она дает возможность открыть таблицу DBF как простой файл. Для ускорения работы можно воспользоваться готовым кодом, которым изобилует Интернет. После тщательного изучения ресурсов Интернет можно выделить наиболее удачный компонент - TDBF.

Компонент TDBF Version 1.11 - 14.06.2004. (Copyright 2002-2004 Брусникин И.В.) Компонент предназначен для непосредственного доступа (без использования BDE или ODBC) к файлам формата DBF версий DBase III+, DBase IV, DBase V. Поддерживаемые типы данных: символьный, дата, числа с плавающей точкой, числа с фиксированной точкой, логический. Позволяет выполнять основные операции с DBF-файлами, а также создавать их. Набор доступных методов и свойств компонента максимально приближен к компоненту TTable, но компонент не является потомком TTable и взаимодействовать с визуальными компонентами TDBXXX «не умеет». Работает с Delphi 3.7 под Windows 9X/NT4/2000/XP. Но самое главное его достоинство - это то, что он бесплатный (freeware).

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

Для организации данных на компьютере клиента более всего подходит технология ADO (от англ. ActiveX Data Objects - «объекты данных ActiveX») - интерфейс программирования приложений для доступа к данным, разработанный компанией Microsoft и основанный на технологии компонентов ActiveX. ADO позволяет представлять данные из разнообразных источников (реляционных баз данных, текстовых файлов и т. д.) в объектно-ориентированном виде. Технология ADO позволяет работать с базами данных Access, кроме того, поддержка компонентов ADO включена в Windows 2000/XP по умолчанию. (Что избавляет от установки дополнительного программного обеспечения, на подобие BDE).

Организация локальной базы данных для хранения и обработки информации на машине клиента.

После конвертации текстовых таблиц (файлов с именами вида ANY_NAME.TXT) в формат Access, возникает файл базы данных Access с именем Price.mdb, содержащий таблицы, имена которых совпадают с именами текстовых файлов (если отбросить расширение «.TXT»). Кроме этого, в файл Price.mdb добавляется таблица ORDERS.

Описание таблиц данных.

PRICEI - самая объемная таблица. Содержит информацию о товаре (собственно прайс). На данный момент насчитывает 28601 записей. Их количество склонно к увеличению.

Структура таблицы PRICEI представлена в табл. 4.2.

Таблица 4.2 Структура таблицы PRICEI

ISG - справочник изготовителей (см. табл. 4.3). Содержит только код и наименование изготовителей. На данный момент насчитывает 4374 записей.

Таблица 4.3 Структура таблицы ISG

TMC - справочник групп товарно-материальных ценностей (см. табл. 4.4). На данный момент содержит 23 записи.

Таблица 4.4 Структура таблицы TMC

SKLAD - справочник мест размещения (см. табл. 4.5). На данный момент содержит 21 запись.

Таблица 4.5 Структура таблицы SKLAD

PROVIDERS - справочник поставщиков (см. табл. 4.6). На данный момент содержит 2 записи.

Таблица 4.6 Структура таблицы PROVIDERS

BRAK - Информация о забракованных препаратах (см. табл. 4.7). Количество записей постоянно меняется.

DEFECTUR - Информация о стойкой дефектуре - перечень товаров, отсутствующих на складе и у поставщиков (см. табл. 4.8). Количество записей постоянно меняется.

Таблица 4.7 Структура таблицы BRAK

Таблица 4.8 Структура таблицы DEFECTUR

NEED - Прайс-лист товаров для хозяйственных нужд (табл. 4.9).

Таблица 4.9 Структура таблицы NEED

ORDERS - Таблица заказов (табл. 4.10).

Таблица 4.10 Структура таблицы ORDERS

Схема взаимосвязи таблиц представлена на рис. 4.2.

Рисунок 4.2 Схема локальной базы данных

4.4 Организация многопользовательского режима

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

5. Реализация

Выбирая инструменты для разработки программного обеспечения необходимо учитывать условия, в которых ведется реализация данного проекта, и накопленный опыт сотрудников, участвующих в проекте. Временные и кадровые ограничения требуют того, чтобы выбираемая среда разработки предоставляла широкий перечень программных компонентов и других инструментов, тем самым максимально автоматизируя сам процесс создания программного продукта. Наиболее всего для этого подходит интегрированная среда разработки Borland Delphi 7.0 от компании Borland Software Corporation.

Интегрированная среда разработки (IDE - Integrated Development Environment) Delphi 7 представляет собой многооконную систему. Вид интегрированной среды разработки (пользовательский интерфейс) может различаться в зависимости от настроек. Пользовательский интерфейс среды служит для организации взаимодействия с программистом и включает в себя рад окон, содержащих различные элементы управления. С помощью средств интегрированной среды разработчику удобно проектировать интерфейсную часть приложения, а также писать программный код и связывать его с элементами управления. В интегрированной среде разработки проходят все этапы создания приложения, включая отладку.

Delphi относится к системам визуального программирования, называемым также системами RAD (Rapid Application Development - быстрая разработка приложений). Разработка приложения в Delphi включает два взаимосвязанных этапа:

- создание пользовательского интерфейса приложения;

- определение функциональности приложения.

Пользовательский интерфейс приложения определяет способ взаимодействия пользователя и приложения, т. е. внешний вид формы (форм) при выполнении приложения и то, каким образом пользователь управляет приложением. Интерфейс конструируется путем размещения в форме компонентов, называемых интерфейсными компонентами или элементами управления. Создается пользовательский интерфейс приложения с помощью окна Формы, которое в среде разработки представляет собой модель формы времени выполнения.

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

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

Пользовательский интерфейс приложения составляют компоненты, которые разработчик выбирает в палитре компонентов и размещает в форме, т. е. компоненты являются своего рода строительными блоками. При конструировании интерфейса приложения действует принцип WYSIWYG (What You See Is What You Get - «что видите, то и получаете»), и разработчик при создании приложения видит форму почти такой же, как и при его выполнении.

Компоненты являются структурными единицами и делятся на визуальные (видимые) и невизуальные (системные). При этом понятия «видимый» и «невидимый» относятся только к этапу выполнения, на этапе проектирования видны все компоненты приложения.

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

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

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

- Выполнение до указанной инструкции;

- Пошаговое выполнение приложения;

- Выполнение до точки останова (Break point);

- Включение и выключение точек останова;

- Просмотр значений объектов, например, переменных в окне просмотра;

- Установка значений объектов во время выполнения приложения;

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

Интегрированная среда Delphi 7.0 для работы с сокетами предоставляет удобные инструменты - компоненты Indy (Internet Direct 9.0).

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

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

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

Разработчикам Indy удалось найти решение, устраняющее данную неприятность. В Indy имеется специальный компонент, который решает проблему замораживания пользовательского интерфейса. Название этого компонента говорит само за себя - TIdAntiFreeze, расположен он на вкладке Indy Misc. Этот компонент добавляется в проект в любом месте. TIdAntiFreeze работает по внутреннему таймеру вне стека вызовов и вызывает процедуру Application.ProcessMessages() по окончании таймаута, которая позволяет обработать системные сообщения. Внешние вызовы к Indy продолжают оставаться блокирующими и поэтому работают точно также как и без использования компонента TIdAntiFreeze. Использование TIdAntiFreeze позволяет получить все преимущества блокирующих сокетов без видимых недостатков.

Достоинства блокирующего режима:

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

Типичная сессия в Indy выглядит следующим образом:

with IndyClient do begin

Connect();

try

// Data Transfer

finally

Disconnect();

end;

end;

В то время, как с другими компонентами сессия будет выглядеть примерно так:

procedure TForm1.TestOnClick(Sender: TComponent);

begin

with SocketComponent do begin

Connect();

try

while Connected do begin

if IsError then Abort;

Application.ProcessMessages();

OutData:= 'Data To send';

while length(OutData) > 0 do begin

Application.ProcessMessages();

end;

end;

finally Disconnect();

end;

end;

end;

procedure TForm1.OnConnectError(...);

begin

IsError:= True;

end;

procedure TForm1.OnRead(...);

var

i: Integer;

begin

i:= SocketComponent.Receive(OutData);

OutData:= Copy(OutData, i + 1, MaxInt);

end;

2. Удобство и простота работы с потоками. С блокирующими сокетами почти всегда используются кодовые потоки.

Достоинства потоков:

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

- Инкапсуляция. Каждое соединение может содержать некоторое подобие интерфейса с другим соединением.

- Безопасность. Каждый поток может иметь различные атрибуты безопасности.

- Несколько процессоров. Дает преимущество на системах с несколькими процессорами.

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

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

Стоит упомянуть еще одно достоинство Indy:

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

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

Пул потоков в Indy доступен через компонент TIdThreadMgrPool.

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

5.1 Реализация протокола взаимодействия сервера и клиента

Первый шаг в построении сервера и клиента - это разработка протокола прикладного уровня. Протокол - это набор соглашений, который определяет обмен данных между различными программами. Для стандартных протоколов это определяется соответствующим RFC. В данном проекте требуется разработать протокол, который должен основываться на сервисах протоколов более низкого уровня в модели OSI, а именно протокола TCP стека TCP/IP.

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

После соединения, сервер посылает приветственное сообщение, затем принимает команду. Эта команда может быть любой текстовой строкой, например, “Quit”, которая заставляет сервер разорвать соединение. Сервер может принять несколько команд, прежде чем будет послана команда “Quit”.

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

Таблица 5.1 Протокол взаимодействия клиентского и серверного приложения

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

Рисунок 5.1 - Запрос прайса

Рисунок 5.2 - Отправка заказа

Рисунок 5.3 - Запрос накладных

Рисунок 5.4 - Отправка заявки на накладные

5.2 Сервер заказов

Особенность работы серверных компонентов Indy.

Indy серверные компоненты создают слушающий поток, который изолирован от главного кодового потока программы. Слушающий поток прослушивает входящие запросы от клиентов. Для каждого клиента, которому отвечает, создается новый поток для обслуживания клиента. Соответствующие события затем обслуживаются в контексте данного потока. (Схема представлена на рис. 5.5)

Рисунок 5.5 - Использование потоков в сокетах Indy

Основная задача при программировании сервера заказов сводится к тщательной реализации метода Execute().

5.3 Клиентское приложение (Клиент)

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

Для этого можно воспользоваться Win32 API для создания Мьютекса - именованного объекта ядра Windows.

В самом начале программы происходит создание Мьютекса с определенным именем. Если во второй аргумент функции CreateMutex передать логическое значение True, то функция GetLastError() вернет код ошибки, равный ERROR_ALREADY_EXISTS, если мьютекс с таким именем уже создан кем-то другим (в данном случае другой копией приложения). В этом случае другими функциями Win32 API отыскивается уже существующее окно программы и производится попытка вывести его на передний план на рабочем столе, и после этого выполняется выход из программы.

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

В листинге 5.1 приведен отрывок кода, реализующий запуск одной копии приложения.

Листинг 5.1

var

hMutex: Cardinal;

hApp: HWND;

MutexName: String;

begin

SetLength(MutexName, 256);

GetShortPathName(PAnsiChar(ExtractFilePath(Application.ExeName)), PAnsiChar(MutexName), 256);

SetLength(MutexName, Pos(#0, MutexName) - 1);

MutexName:= StringReplace(MutexName, '', '_', [rfReplaceAll]) + 'EZakaz_One_Copy';

hMutex:= CreateMutex(nil, True, PAnsiChar(MutexName));

if (GetLastError=ERROR_ALREADY_EXISTS) then begin

ReleaseMutex(hMutex);

CloseHandle(hMutex);

hApp:= FindWindow('TApplication', 'Шексна-Фарма (электронный заказ)');

ShowWindow(hApp, SW_RESTORE);

SetForegroundWindow(hApp);

halt;

end;

...

Application.Run;

end.

6. Тестирование

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

Цели тестирования:

- выявить наличие ошибок или убедительно продемонстрировать их отсутствие (что возможно лишь в отдельных тривиальных случаях).;

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

- продемонстрировать реализации требований к характеристикам программы;

- отобразить надежность как индикатор качества программы.

6.1 Методика тестирования

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

Модульное тестирование (unit-testing) (По степени изолированности компонентов). Цель модульного тестирования -- изолировать отдельные части программы и показать, что по отдельности эти части работоспособны.

Тестирование белого ящика (white box) (По знанию системы). При тестировании белого ящика (англ. white-box testing, также говорят -- прозрачного ящика), разработчик теста имеет доступ к исходному коду программ и может писать код, который связан с библиотеками тестируемого ПО. Это типично для юнит-тестирования (англ. unit testing), при котором тестируются только отдельные части системы. Оно обеспечивает то, что компоненты конструкции -- работоспособны и устойчивы, до определённой степени.

Тестирование совместимости (compatibility testing) (По объекту тестирования)

Функциональное тестирование (functional testing) (По объекту тестирования). Проводится в целях проверки реализуемости функциональных требований, то есть способности ПО в определённых условиях решать задачи, нужные пользователям. Функциональные требования определяют, что именно делает ПО, какие задачи оно решает.

На этапе проектирования было проведено модульное тестирование, а на этапе реализации - функциональное тестирование. Модульное тестирование не выявило ошибок, поэтому подробнее остановимся на функциональном тестировании.

Использование средств тестирования:

– встроенный отладчик интегрированной среды разработки Delphi7:

– метод ручного тестирования - пошаговая отладка при обнаружении ошибки;

– метод обратного прослеживания - при выводе неправильного результата строится гипотеза его возникновения, а затем проверяется;

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

– Тщательная проверка руководства.

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

- Процессор Intel Pentium III 600 MHz;

- ОЗУ 256 Mb;

- НЖМД 40 Gb;

- Видеокарта 16Mb.

На рабочих станциях установлена ОС MS Windows XP.

Также было проведено тестирование на совместимость с более ранними и с современными версиями ОС Windows, а именно Windows 98SE и Windows Vista. По результатам тестирования было выявлено, что данный программный продукт совместим и с новой операционной системой, что позволит в дальнейшем перейти на новую платформу без внесения изменений в программный код.

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

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

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

После «отлавливания» и обработки этих ошибок, пользователь будет получать уже следующие сообщения (рис. 6.2, 6.3, 6.4):

Рисунок 6.1 - Окно настроек клиентской программы

Рисунок 6.2 - Сообщение об отсутствии выбранного клиента

Рисунок 6.3 - Подсказка о необходимости указания IP-адреса

Рисунок 6.4 - Подсказка о необходимости указания порта

6.2 Оценка показателей качества по результатам тестирования

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

1. Надежность системы оценивается с помощью следующих критериев:

- Стабильность - атрибут программного обеспечения, относящийся к частоте отказов при ошибках в программном обеспечении. За время тестирования программы отказов и ошибок, вызванных ошибками при разработке системы, обнаружено не было, что позволяет сделать вывод о стабильности работы программного обеспечения. Стабильность - 10 баллов.

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

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

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

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

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

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

3. Эффективность программы оценивается с помощью следующих критериев:

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

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

4. Сопровождаемость программы оценивается с помощью следующих критериев:

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

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

Анализируемость - атрибут ПО, относящийся к усилиям необходимым для диагностики недостатков или случаев отказов, или определения составных частей для модернизации. Благодаря системе Delphi7 программа обладает обработчиком ошибок по умолчанию, что уменьшает трудоемкость диагностики. Анализируемость - 7 баллов.

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

5. Мобильность программы оценивается с помощью следующих критериев:

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

- Простота внедрения - атрибут программного обеспечения, относящийся к усилиям, необходимым для внедрения программного обеспечения в конкретное окружение. Для компьютера необходима операционная система: MS Windows XP/7. Для установки клиентской программы создан инсталляционный пакет. Оценка простоты внедрения - 10 баллов.

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

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

7. Внедрение

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

7.1 Установка программного обеспечения на рабочие места

Разработанная программа изначально была предназначена для установки в аптеки и аптечные пункты торговой сети. Так как не все ошибки могут быть выявлены в процессе тестирования на этапе реализации, целесообразно внедрение начинать постепенно. Поэтому было принято решение вначале испытать программу на одной из аптек - Аптека «Шексна-Фарма», ул. Ильюшина. Эта аптека была выбрана ввиду того, что она располагается ближе всего к офису, что позволяет максимально оперативно решать проблемы, возникающие на этапе внедрения.

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

Текст скрипта приводится в приложении А

При запуске данный скрипт создает файл Setup.exe, который при установке дает возможность пользователю выбрать язык установки (русский или английский), показывает приветственную страницу, требует ознакомиться с лицензией на установку и использование, предлагает выбрать директорию для установки, отображает процесс установки, после установки открывает скопированный файл ReadMe.txt, содержащий инструкции по настройке.

Собственно инсталлятор Setup.exe выполняет следующие действия:

1. Записывает в реестр Windows информацию о директории предыдущей установки (строковый параметр ZakazPath, ключ HKLMSoftwareZakaz)

2. Удаляет в данной директории файл Zakaz.exe и шаблон отчета Order.rav старой версии (если такие есть).

3. Из собственных ресурсов копирует файлы: Zakaz.exe, Unrar.dll, Order.rav, ReaMe,txt. Если инсталлятор не находит файл настроек Sttngs.ini, то он устанавливает также и его с начальными стандартными настройками.

4. Последний этап - создание ярлычка на рабочем столе с именем «Заказ Шексна-Фарма».

7.2 Обучение персонала

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

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

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

7.3 Внесение изменений и дополнений

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

После этого, программа с учетом доработок и пожеланий персонала аптеки «Шексна-Фарма» на ул. Ильюшина была установлена в остальных аптеках и аптечных пунктах торговой сети.

В целом программа выполняет работу в соответствии с требуемыми условиями. С учетом внесенных исправлений по заключению специалистов ООО «Шексна-Фарма» программное обеспечение готово к эксплуатации в производственных условиях и в настоящее время используется в работе аптек и аптечных пунктов.

Основные характеристики клиентской программы приведены в таб. 7.1.

Таблица 7.1 Основные характеристика клиентской программы

8. Технико-экономическое обоснование проекта

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

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

Для расчета показателя экономической эффективности воспользуемся формулой 8.1:

(8.1)

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

8.1 Расчет выгоды в результате внедрения проекта

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

Таким образом, количество человек, которые выполнят работу, эквивалентную работе данного программного продукта, будет рассчитываться по формуле 8.2:

,(8.2)

где N - среднее количество позиций в день;

t_ср. - время в секундах выборки одной позиции;

28800 - количество секунд в 8 часах.

Для вычисления t_ср. были собраны следующие статистические данные:

При выборе позиций вручную в существующей системе фиксировалась дата и время, в результате чего накопилась таблица с данными TIMSET.DBF, которая состоит из 66053 записей. Эта таблица с данными содержит поля с номером накладной (NNAKL), кодом покупателя (NP), кодом пользователя (USERID), датой выбора позиции (DTOTGR), временем выбора позиции (CTIM). С каждой накладной всегда работает только один пользователь, таким образом можно сформировать SQL запрос, который сгруппирует записи и с помощью агрегирующих функций выдаст время занесения первой позиции (MIN(CTIM)), время занесения последней позиции (MAX (CTIM)) и количество позиций (COUNT(*)) для каждой накладной. С помощью вычисляемого поля можно представить продолжительность ручного оформления накладной, которая равняется разнице между временем занесения первой и последней позиции. В связи с этим накладные, состоящие только из одной позиции необходимо отбросить, так как в этом случае разница будет равна 0. Если этого не сделать, то результат подсчета не будет объективным.

Так как Local SQL BDE не поддерживает выполнение запросов вида SELECT … FROM SELECT…, необходимо выполнить 2 запроса с формированием промежуточной таблицы данных.

Первая SQL-инструкция будет выглядеть следующим образом:

SELECT NNAKL, NP, USERID, DTOTGR, MAX(CTIM) AS MAXCTIM, MIN(CTIM) AS MINCTIM, CAST((CAST(MAX(CTIM) AS TIME) - CAST(MIN(CTIM) AS TIME)) / (CAST('00:00:01' AS TIME) - CAST('00:00:00' AS TIME)) AS INTEGER) AS LGTH, COUNT(*) AS CNT FROM TIMSET GROUP BY NNAKL, DTOTGR, USERID, NP HAVING COUNT(*) > 1

Результатом этого запроса будет промежуточная таблица (TIMDATA1), содержащая сгруппированные данные по каждой накладной. Поля таблицы содержат следующую информацию: номер накладной (NNAKL), Код покупателя (NP), код пользователя (USERID), дата выписки накладной (DTOTGR), время занесения последней позиции (MAXCTIM), время занесения первой позиции (MINCTIM), продолжительность ручного оформления накладной в секундах (LGTH), количество позиций в накладной (CNT).

Для проведения такого исследования в среде Delphi 7 было создано приложение, в котором были использованы компоненты для работы с таблицами DBase посредством BDE (Borland Database Engine).

Вид единственного окна приложения представлен на рисунке 8.1.

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

Вторая SQL-инструкция будет выглядеть следующим образом:

SELECT CAST(SUM(LGTH) AS INTEGER) AS TOTAL_LGTH, CAST(SUM(CNT - 1) AS INTEGER) AS TOTAL_POS, SUM(LGTH) / SUM(CNT - 1) AS AVG_TIME FROM TIMDATA1

Рисунок 8.1 - Формирование промежуточной таблицы данных

Результатом второго запроса будет конечная таблица (TIMDATA2), содержащая единственную запись. (Рис. 8.2). Таблица включает в себя три поля: TOTAL_LGTH - показывает общее количество времени в секундах, затраченное на ручную выборку всех анализируемых позиций; TOTAL_POS - количество всех анализируемых позиций; AVG_TIME - среднее время в секундах, которое затрачивается на поиск одной позиции в прайсе (t_ср). Оно получается в результате деления TOTAL_LGTH / TOTAL_POS и составляет 23,836 с.

Для подсчета среднего количества позиций, содержащихся в заказах, поступающих в рабочий день (N), лучше всего брать календарный период, кратный месяцу. В данном проекте представлен отчет за май 2014г. (Этого должно быть достаточно). Заказы представляют собой файлы с расширением DBF, содержащие записи - собственно, выбранные позиции. Если посчитать общее количество всех заказанных позиций (K) и поделить его на количество рабочих дней D (согласно производственному календарю на 2014 в мае 19 рабочих дней, т.е. D = 19), то в результате будет получена требуемая характеристика N.

Рисунок 8.2 - Конечный результат анализа статистических данных

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

По окончании выполнения программы (Рис 8.3), были получены следующие результаты: общее количество анализируемых файлов - 5741; общее количество выбранных позиций (K) - 278528.

- заказанных позиций в рабочий день в среднем.

Таким образом,

человек.

Это означает, что производительность разрабатываемого программного продукта компенсирует труд 12-ти человек с оплатой полной ставки (при сорокачасовой рабочей неделе) вместе с одним человеком, работающим на ј ставки - минимальная возможная нагрузка, предусмотренная на предприятии.

Рисунок 8.3 - Подсчет количества заказанных позиций за один месяц

При минимальном размере ставки, который составляет 16000 рублей в месяц для должности с данной квалификацией, общая экономия средств составит: 16000 · 12,25 = 196000 рублей в месяц.

Соответственно годовая экономия составит 2352000 рублей.

8.2 Расчет затрат на выполнение проекта

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

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

8.2.1 Расчет стоимости материалов и комплектующих

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

Таблица 8.1 Расчет стоимости материалов и комплектующих

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

8.2.2 Определение трудозатрат

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

Таблица 8.2 Перечень этапов и работ по проектированию программного продукта

8.2.3 Организационный план работ

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

^,(8.3)

где n - число этапов;

К_пар - средний коэффициент параллельности выполнения стадии;

t_i - трудоемкость стадии, чел-дн;

ч_i - численность людей, одновременно выполняющих данную стадию (ч_i=2 чел).

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

Расчет цикла разработки приведен в таблице 8.3.

Таблица 8.3 Расчет цикла разработки

Время цикла разработки Т_цик = 147 дней.

8.2.4 Оценка трудоемкости работ

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

Расчет трудоемкости исследования или разработки производится по формуле 8.4:

,(8.4)

где t_i - трудоемкость работ по стадиям (этапам) разработки, чел-дн.;

n - количество работ (стадий, этапов) проектирования.

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

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

, (8.5)

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

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

Оценка трудоемкости работ и этапов представлена в таблице 8.4.

Таблица 8.4 Состав и трудоемкость работ

Фонд времени работы каждого участника определяется путем распределения работ между исполнителями на каждом этапе (см. таблицу 8.5).

Таблица 8.5 Списочный состав и фонды времени исполнителей

Ленточный график работ представлен в приложении Б.

8.2.5 Расчет численности исполнителей работ

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

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

Состав и фонды времени исполнителей указаны в таблице 8.5.

Примерные обязанности и функции исполнителей в проектировании:

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

2. Дипломник: Проектирует, программирует, тестирует все модули. Описывает в документации информацию по ним.

8.2.6 Расчет оплаты труда персонала

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

Среднедневная оплата труда каждого участника рассчитывается по формуле:

,(8.6)

где З_мес - среднемесячная оплата труда, руб;

Ф - среднемесячный плановый фонд времени одного работника, дни.

Расчет оплаты труда приведен в таблице 8.6.

Таблица 8.6 Расчёт оплаты труда

8.2.7 Расчет отчислений на социальные нужды

Отчисления на социальные нужды составляют 26,2% от общего фонда оплаты труда:

З_соц = 0,262 З = 0,262 150900= 39535,8 (руб.)

8.2.8 Расчет амортизационных отчислений на оборудование

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

,(8.5)

где Ц_об - стоимость оборудования (35 тыс. руб. - стоимость компьютера и лазерного принтера);

Н_об - нормы отчислений на амортизацию оборудования (30 % в год);

t_р - время работы оборудования, дней (136 дней, так как работы проводятся на ЭВМ от этапа эскизного проекта до заключительного этапа);

Т_р - число календарных дней в 2008 году (366 дней).

(руб.)

8.2.9 Расчет накладных расходов

Накладные расходы берутся в процентах от оплаты труда (55%):

З_н = 0,55 З = 0,55 150900 = 82995 (руб.)

8.2.10 Расчет затрат на прочие расходы

Расчет затрат на прочие расходы определяется в процентном соотношении от суммы предыдущих статей затрат (2%).

З_проч = 0,02 З_i = 0,02 (З_м + З + З_соц + З_об + З_н)= 0,02 (2419 + 150900 + 39535,8 + 3902 + 82995) = 0,02 279751,8 = 5595,04 (руб.).

8.2.11 Смета затрат

Смета затрат на разработку представлена в таблице 8.7.

Таблица 8.7 Смета затрат на разработку

Исходя из таблицы 8.7 видно, что стоимость разрабатываемого проекта составляет 285346,84 руб.

8.3 Расчет показателя эффективности

Таким образом, согласно формуле (8.1) показатель экономической эффективности составит:

Показатель экономической эффективности =

Показатель экономической эффективности больше 1 в 8 раз, следовательно, разработка не только оправдана, но и экономически выгодна.

Заключение

В процессе дипломного проектирования был проведен анализ существующих решений по автоматизации аптечной деятельности и выбор пути решения поставленной задачи в пользу модернизации существующей на предприятии ООО «Шексна-Фарма» системы складского учета.

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

В результате выполнения данной выпускной квалификационной работы была разработана автоматизированная система формирования заказов для сети аптек «Шексна-Фарма», которая успешно прошла опытную эксплуатацию и теперь используется на предприятии по своему назначению.

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

Внедрение автоматизированной системы формирования заказов на предприятии ООО «Шексна-Фарма», описанной в данном проекте, оказалось весьма эффективным с экономической точки зрения.

автоматизация сервер сетевой клиент

Список использованных источников

1. ГОСТ 19.401-78 ЕСПД. Текст программы. Требования к содержанию и оформлению. - Введ. 01.01.1980.- М.: Изд-во стандартов, 1982. - С.32.

2. ГОСТ 19.701 - 90. ЕСПД. Схемы алгоритмов программ, данных и систем. Условные обозначения и правила выполнения. - Введ. 01.01.1992.- М.: Изд-во стандартов, 1992. - 8 с.

3. ГОСТ Р ИСО/МЭК 9126-93. Оценка программной продукции. Характеристики качества и руководства по их применению. - Введ. с 28.12.93. - М.: Госстандарт России, 1994. - 15 с.

4. Карпова, Т.С. Базы данных: модели, разработка, реализация / Т.С. Карпова. - СПб.: Питер, 2001. - 304 с.: ил.

5. Одинцов, И.О. Профессиональное программирование. Системный подход / И.О. Одинцов. - 2-е изд. перераб. и доп. - СПб.: БХВ-Петербург, 2004. - 624 с.: ил.

6. Фаронов, В.В. Программирование баз данных в Delphi 7. Учебный курс / В.В. Фаронов. - СПб.: Питер, 2005. - 459 с.: ил.

7. Флёнов М.Е. Библия Delphi: «БХВ - Петербург», 865 с