Внедрение автоматизированной системы торговой деятельности для предприятия ЗАО "Полиграфия и коммуникации"

Пункт меню “Склад” - вызывает диалоговое окно для получения представления склада в разрезе товаров или времени.

UML-диаграмма приложения “Склад” представлена на рисунке 12.

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

Рис.12 UML-диаграмма приложения “Склад”.

Два класса: “Интерфейс” отвечают за пользовательский интерфейс для работы со списком поставок и их содержимым.

2.9 Проектирование приложения “Заказы”

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

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

Выбор счетов для генерации заказов

Получение списка товаров, содержащихся в счетах

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

Формирование плана закупок, то есть разбиение списка товаров по поставщикам.

Редактирование плана закупок, внесение недостающих товаров (с пометкой “Вне счетов”).

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

Внешний вид главной формы приложения показан на рисунке 13.

Основные функции приложения “Заказы”:

Добавить товар - добавление товара в заказ вне поставок. Входные данные: товар(номер). Выходные данные - список товаров для заказа

Удалить товар - удаление товара из списка товаров для заказа. Так как заказ не связан со счетом, то удалить можно и товар, заказываемый по счету. Входные данные: товар(номер). Выходные данные - список товаров для заказа.

Рис.13 Приложение “Заказы” - главная форма.

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

Расчет суммы - расчет суммарной стоимости для плана закупок. Входные данные: план закупок. Выходные данные - стоимость всех товаров плана.

Расчет суммы по заказу - расчет стоимости одного заказа. Входные данные: заказ. Выходные данные - стоимость всех товаров заказа.

Печать - вызывает диалог выбора отчета и его формата для печати. Входные данные: Шаблон для печати, если *.xls-отчет, форма, если *.frf-отчет. Выходные данные - *.xls или *.rtf файл или печатная форма списка поставок.

Фильтр - вызывает диалог для изменения параметров фильтрации списка товаров для заказа. Входные данные: условия фильтрации. Выходные данные - список поставок, входящих в диапазон.

Сохранить план закупок - сохранение отчета по плану закупок в базе данных. Входные данные: отчет. Выходные данные - нет.

UML-диаграмма приложения “Заказы” представлена на рисунке 14

Рис.14 UML-диаграмма приложения “Заказы”.

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

Глава 3. Экспериментальная проверка программного комплекса.

3.1 Исходные данные и постановка задачи для проведения тестирования

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

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

Целью проведения тестирования является проверка функционирования программы в соответствии с требованиями, предъявляемыми к ней.

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

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

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

добавление, изменение, удаление информации;

поиск нужной информации, при определении пользователем параметров поиска;

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

3.2 Тестирование приложений

Тестирование приложения “Прайс”.

Прежде всего, была осуществлена попытка доступа к приложению, пользователем “Serebrinnikov_OA” с ролью “Склад”, которая дает права доступа к приложению “Склад” и, частично, “Заказы”, но не дает права доступа к приложению “Прайс”. Результат - отказ в доступе. После входа в систему под учетной записью администратора, были изменены права доступа для данного пользователя и эта учетная запись получила право на чтение, удаление, добавление товаров в прайс-листе. Добавим группу товаров “Нестандартное оборудование” с родителем “Все товары” в дерево товаров. Добавим в эту группу товар “Часы с флэш-накопителем 64Mb Casio-I32” и товар “ИК-порт ACTiSYS IR”. Добавление, удаление этих товаров из прайса, а также редактирование их свойств проходит нормально. При попытке удаление удаления товара “Монитор Sony Multiscan E100” получаем сообщение: “Товар “Монитор Sony Multiscan E100” не может быть удален, так как он включен в счет, заказ или поставку”. При удалении непустой группы товаров, при наличии в ней хотя бы одного товара, фигурирующего в счетах, заказах или поставках получаем такое же сообщение и все изменения в группе отменяются. Попытка другого пользователя изменить свойства товара, в то время, когда их редактирует пользователь “Serebrennikov_OA” приводит к появлению сообщения: “Редактирование текущей записи невозможно. Запись заблокирована пользователем Serebrinnikov_OA 13:20 19.02.2006”.

Тестирование приложения “Счета”.

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

3.3 Анализ результатов, полученных при тестировании

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

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

Рис. 15 Окно «Добро пожаловать».

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

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

Программный комплекс работает устойчиво, если выполняются перечисленные ниже требования:

Сеть функционирует нормально;

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

Сервер функционирует нормально;

Проверка работы поисков показала, что алгоритмы поисков работают

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

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

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

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

Глава 4. Расчет экономической эффективности проекта

4.1 Анализ рыночных возможностей продукта

На рынке автоматизированных систем для крупных организаций и финансово-промышленных групп на сегодня можно выделить два основных субъекта: это рынок автоматизированных банковских систем (АБС) и рынок корпоративных информационных систем промышленных предприятий. Не смотря на сильную взаимосвязь этих двух рынков систем автоматизации, предлагаемые на них решения, пока еще не достаточно интегрированы между собой, чего следует ожидать в недалеком будущем. Создавая свои отделы и управления автоматизации, предприятия и банки пытались обустроиться своими силами. Однако периодическое "перетряхивание" инструкций, сложности, связанные с разными представлениями пользователей об одних и тех же данных, непрерывная работа программистов по удовлетворению все новых и новых пожеланий отдельных работников и как следствие - недовольство руководителей своими программистами несколько остудило пыл как тех, так и других. Итак, первый подход к решению этой проблемы сводился к проектированию "снизу-вверх". В этом случае, при наличии квалифицированного штата программистов, вполне сносно были автоматизированы отдельные, важные с точки зрения руководства рабочие места. Общая же картина "автоматизированного предприятия" просматривалась недостаточно хорошо, особенно в перспективе. Быстрый рост числа акционерных и частных предприятий и банков позволил некоторым компаниям увидеть здесь будущий рынок и инвестировать средства в создание программного аппарата для этого растущего рынка. Из всего спектра проблем разработчики выделили наиболее заметные: автоматизацию ведения бухгалтерского аналитического учета и технологических процессов (для банков это в основном - расчетно-кассовое обслуживание, для промышленных предприятий - автоматизация процессов проектирования и производства, имеется в виду не конкретных станков и т.п., а информационных потоков). Учитывая тот факт, что ядром АИС безусловно является аппарат, обеспечивающий автоматизированное ведение аналитического учета, большинство фирм начали с детальной проработки данной проблемы. Системы были спроектированы "сверху", т.е. в предположении, что одна программа должна удовлетворять потребности всех пользователей.

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

4.2 Расчет единовременных затрат на разработку ПО

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

Таблица 4.1.

Содержание стадий научно-исследовательской работы (НИР).

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

План-график выполнения приведен на рисунке 16:

Рис 16. План - график разработки и внедрения ПО (диаграмма Ганта).

Итак, общая фактическая трудоемкость разработки ПО составляет:

,

где - общая трудоемкость разработки, дни; Тi - трудоемкость по стадиям, дни; n - количество стадий разработки.

В смету затрат на разработку ПО включаются:

материальные затраты;

основная и дополнительная зарплаты;

отчисления на социальные нужды;

стоимость машинного времени на подготовку и отладку программ;

стоимость инструментальных средств;

накладные расходы.

Материальные затраты.

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

В процессе работы использовались материалы и принадлежности, представленные в таблице 4.2.

Таблица 4.2.

Материалы и принадлежности, использованные в процессе разработки.

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

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

,

где Зср.дн.j - среднедневная зарплата j-го сотрудника, руб./день; Тоб.j - общая трудоемкость проекта j-го сотрудника, дни; n - количество сотрудников, принимающих непосредственное участие в разработке ПО.

Основная зарплата разработчика определена из расчета 7000 руб. в месяц при среднем количестве рабочих дней, равных 20:

.

Заработная плата дипломного руководителя составляет 60 руб./час, причем на консультацию запланировано 23 часа. Следовательно, основная зарплата руководителя дипломного проекта за весь период разработки равна:

.

Заработная плата консультанта по экономической части составляет 50 руб./час, причем на консультацию запланировано 3 часа. Следовательно, основная зарплата консультанта по экономике за весь период разработки равна:

.

В итоге основная заработная плата при выполнении НИР равна:

.

Дополнительная заработная плата равна 10% от основной:

.

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

.

Отчисления на социальные нужды.

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

.

Стоимость машинного времени на подготовку и отладку программ.

Стоимость машинного времени Зомв зависит от себестоимости машино-часа работы ЭВМ СМЧ, а также времени работы на ЭВМ ТЭВМ, и включает амортизацию ЭВМ и оборудования, затраты на электроэнергию, зарплату обслуживающего персонала.

Себестоимость машино-часа ЭВМ и принтера равны соответственно:

,

.

Время работы на ЭВМ и принтере равны соответственно:

.

Затраты на оборудование.

,

где АМ - амортизационные отчисления, руб.; Оф - стоимость ЭВМ и оборудования, руб.; Нам - норма амортизации, %; Тм - время использования оборудования, дни

Затраты на электроэнергию.

,

Затраты на обслуживающий персонал.

Данный вид затрат отсутствует.

Таким образом, стоимость машинного времени на подготовку и отладку программ равно:

Стоимость инструментальных средств.

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

Таблица 4.3. Стоимость СПО.

Затраты на амортизацию инструментальных средств:

руб.

Расчет стоимости машинного времени

;

руб./ч.

Накладные расходы.

Накладные расходы составляют 30% от основной заработной платы разработчиков ПО, а значит:

.

Итак, смета затрат на НИР приведена в таблице 4.4.

Таблица 4.4.

Смета затрат на разработку ПО.

4.3 Единовременные расходы организации заказчика ПО при внедрении автоматизированных рабочих мест (АРМ)

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

программного обеспечения Цпо;

инструментальных средств Цис;

ЭВМ, прочих аппаратных средств и сетевого оборудования Кэвм;

обучение персонала Косв.

Стоимость программного обеспечения.

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

,

где Спо - себестоимость ПО, затраты на разработку по смете из таблицы 5.4; П - прибыль разработчика 20-30% к затратам; НДС - налог на добавленную стоимость 18%.

Итак, стоимость программного обеспечения равна:

Стоимость инструментальных средств.

Стоимость инструментальных средств и годовых сумм амортизации приведены в таблице 4.5.

Таблица 4.5.

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

Стоимость ЭВМ, прочих аппаратных средств и сетевого оборудования.

Стоимость всего необходимого оборудования и годовых сумм амортизации приведены в таблице 4.6.

Таблица 4.6.

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

Затраты на обучение персонала.

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

Косв = Зчас * Чпр* Тосв = 25 * 4 * 40+25*1*48 = 5200.00(руб.),

где Зчас - часовая зарплата программиста (Зчас = 25.00 руб./час);

Чпр - численность персонала на обучение (Чпр = 4 чел.);

Тосв - продолжительность обучения и освоения (Тосв = 40 часов).

Таким образом, на обучение четырех человек необходимо затратить 40 часов. Для руководителя необходим 48-часовой курс обучения.

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

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

Таблица 4.7

График реализации проекта.

Результаты расчетов оформлены в виде инвестиционного плана (таблица 4.8).

Таблица 4.8

Инвестиционный план.

4.4 Источники финансирования проекта

Общие инвестиции проекта составляют 167705 рублей 46 копеек. Источниками финансирования являются собственные средства - 80% (134164 рубля 37 копеек) и кредит коммерческого банка, под 12% годовых - 20% (33541 рубля 00 копеек) на 2 года.

Возврат кредита осуществляется в конце второго года, а со второго месяца выплачиваются проценты (1.5%). Приведем расчеты в таблице 4.9.

Таблица 4.9

Расчеты за кредит.

Сумма всех выплат по истечении срока составит 37565 рублей 92 копейки.

Страницы: 1, 2, 3, 4