Содержание
Введение
Глава I. Постановка задачи и описание предметной области
1.1 Постановка задачи
1.2 Описание предметной области (бизнес-процессы)
1.3 Обоснование для разработки нового ПО
1.4 Техническое задание
Глава II. Разработка ПО и построение БД
2.1. Функциональные требования к системе
2.2. Схема работы склада предприятия
2.3. Выбор и обоснование технологии проектирования и инструментальных средств разработки
2.4. Постановка задач по подсистемам
2.5. Обоснование выбора СУБД Access для разработки БД
2.6. Разработка структуры базы данных и отношений атрибутов
2.6.1. Нормализация базы данных
2.6.2. База данных автоматизированной системы управления складом
Глава III. Система АРМ «Логистика»
Глава IV. Расчет экономической эффективности
4.1 Анализ рыночных возможностей продукта
4.2 Расчет единовременных затрат на разработку ПО
4.3 Единовременные расходы организации заказчика ПО при внедрении автоматизированных рабочих мест (АРМ)
4.5 Текущие расходы пользователя ПО при эксплуатации АРМ
4.6 Экономия текущих затрат пользователя ПО
4.7 Финансовый план проекта
4.8 Показатели экономической эффективности проекта
Глава V. Обоснование выбора Delphi
Введение
В данной дипломной работе планируется рассмотреть раздел логистики складирования, как один из наиболее важных и значимых в деятельности предприятия – производителя.
Логистика – наука о планировании, организации, управлении, контроле и регулировании движения материальных и информационных потоков в пространстве и во времени от их первичного источника до конечного потребителя.
Логистика подразделяется на несколько основных направлений:
- информационная логистика;
- закупочная логистика;
- логистика производственных процессов;
- сбытовая логистика;
- логистика запасов;
- логистика складирования;
- транспортная логистика;
- организация логистического управления.
Перемещение материальных потоков в логистической цепи невозможно без концентрации в определенных местах необходимых запасов, для хранения которых предназначены соответствующие склады. Движение через склад связано с затратами живого и овеществленного труда, что увеличивает стоимость товара. В связи с этим проблемы, связанные с функционированием складов, оказывают значительное влияние на рационализацию движения материальных потоков в логистической цепи, использование транспортных средств и издержек обращения.
Современный крупный склад — это сложное техническое сооружение, которое состоит из многочисленных взаимосвязанных элементов, имеет определенную структуру и выполняет ряд функций по преобразованию материальных потоков, а также накапливанию, переработке и распределению товаров между потребителями. При этом возможное многообразие параметров, технологических и объемно-планировочных решений, конструкций оборудования и характеристик разнообразной номенклатуры товаров, перерабатываемых на складах, относит склады к сложным системам. В то же время склад сам является всего лишь элементом системы более высокого уровня — логистической цепи, которая и формирует основные и технические требования к складской системе, устанавливает цели и критерии ее оптимального функционирования, диктует условия переработки товара.
Поэтому склад должен рассматриваться не изолированно, а как интегрированная составная часть логистической цепи. Только такой подход позволит обеспечить успешное выполнение основных функций склада и достижение высокого уровня рентабельности.
При этом необходимо иметь в виду, что в каждом отдельно взятом случае, для конкретного склада, параметры складской системы значительно отличаются друг от друга, так же как ее элементы и сама структура, основанная на взаимосвязи этих элементов. При создании складской системы всегда нужно руководствоваться следующим основным принципом: лишь индивидуальное решение с учетом всех влияющих факторов может сделать ее рентабельной. Предпосылкой этого является четкое определение функциональных задач и основательный анализ переработки груза как внутри, так и вне склада. Разброс гибких возможностей необходимо ограничить благоразумными практически выгодными показателями. Это означает, что любые затраты должны быть экономически оправданными, т. е. внедрение любого технологического и технического решения, связанное с капиталовложениями, должно исходить из рациональной целесообразности, а не из модных тенденций и предлагаемых технических возможностей на рынке.
Основное назначение склада — концентрация запасов, их хранение и обеспечение бесперебойного и ритмичного снабжения заказов потребителей.
Глава
I
. Постановка задачи и описание предметной области
1.1 Постановка задачи
Всем известно, что для того, чтобы система управления складом предприятия работала и выполняла все предназначенные ей функции, необходима какая-либо информационная поддержка, которая исключила бы все возможные ошибки и неточности.
Для этого необходимо создание автоматизированного рабочего места управления складом, которая помогла бы предприятию и его работникам вести точный учет всех операций и располагать необходимой информацией - то есть вести собственную базу данных (БД). Именно такая система смогла бы сэкономить время, деньги и обеспечить правильность ведения всех проводимых на складе операций и управлять ими.
Система предназначена для хранения и обработки данных о имеющихся на складе товаров, об услугах, которые также предоставляются потребителям. Обработанные данные могут использоваться сотрудниками, оформляющими заказы, клиентами (о наличии услуг) и другими сотрудниками предприятия для принятия решений о предоставлении и реализации новых услуг.
Общая концепция решения складской системы должна быть экономичной. Экономический успех обеспечивается в случае, если планирование и реализация складской системы рассматриваются с точки зрения интересов всего предприятия, являясь лишь частью общей концепции склада. А рентабельность склада и будет, в конечном счете, основным критерием выбранной общей концепции.
Система складирования предполагает оптимальное размещение товара на складе и рациональное управление им. При разработке системы складирования необходимо учитывать все взаимосвязи и взаимозависимости между внешними (входящими на склад и исходящими из него) и внутренними (складскими) потоками объекта и связанные с ними факторы (параметры склада, технические средства, особенности груза и т.д.). Разработка системы складирования основывается на выборе рациональной системы из всех технически возможных систем для решения поставленной задачи методом количественной и качественной оценки. Этот процесс выбора и оптимизации предполагает выявление связанных между собой факторов, систематизированных в несколько основных подсистем.
Каждая подсистема в себя целый ряд возможных элементов. При этом число элементов, составляющих основные подсистемы, может быть достаточно значительным, а сочетание их в различные комбинации еще более увеличивает многовариантность системы. Это означает, что альтернативный выбор всех конкурентных вариантов должен осуществляться в определенной последовательности с учетом технико-экономической оценки каждого из них.
Выбор рациональной системы складирования должен осуществляться в следующем порядке:
определяются место склада в логистической цепи и его функции;
устанавливается общая направленность технической оснащенности складской системы (механизированная, автоматизированная, автоматическая);
определяется задача, которой подчинена разработка системы складирования;
выбираются элементы каждой складской подсистемы;
создаются комбинации выбранных элементов всех подсистем;
осуществляется предварительный выбор конкурентных вариантов из всех технически возможных;
проводится технико-экономическая оценка каждого конкурентного варианта;
осуществляется альтернативный выбор рационального варианта.
Выбор элементов складских подсистем ведется с помощью схем и диаграмм или разработанных программ на ЭВМ. Это обеспечивает методический подход с учетом всех возможных вариантов.
Логистический процесс на складе весьма сложен, поскольку требует полной согласованности функций снабжения запасами, переработки груза и физического распределения заказов. Практически логистика на складе охватывает все основные функциональные области, рассматриваемые на микроуровне. Поэтому логистический процесс на складе гораздо шире технологического процесса и включает (рисунок 1):
Функционирование всех составляющих логистического процесса должно рассматриваться во взаимосвязи и взаимозависимости. Такой подход позволяет не только четко координировать деятельность служб склада, он является основой планирования и контроля за продвижением груза на складе с минимальными затратами. Условно весь процесс можно разделить на три части:
1) операции, направленные на координацию службы закупки;
2) операции, непосредственно связанные с переработкой груза и его документацией;
3) операции, направленные на координацию службы продаж.
Снабжение запасами.
Основная задача снабжения запасами состоит в обеспечении склада товаром (или материалом) в соответствии с возможностями его переработки на данный период при полном удовлетворении заказов потребителей. Поэтому определение потребности в закупке запасов должно согласовываться со службой продаж и имеющейся мощностью склада.
Контроль за поставками.
Учет и контроль за поступлением запасов и отправкой заказов позволяет обеспечить ритмичность переработки грузопотоков, максимальное использование имеющегося объема склада и необходимые условия хранения, сократить сроки хранения, сократить сроки хранения запасов и тем самым увеличить оборот склада.
Разгрузка и приемка грузов.
При осуществлении этих операций необходимо ориентироваться на условия поставки заключенного договора.
Проводимые на данном этапе операции включают:
разгрузку транспортных средств;
контроль документального и физического соответствия заказов поставки;
документальное оформление прибывшего груза через информационную систему;
формирование складской грузовой единицы.
Внутрискладская транспортировка.
Внутрискладская транспортировка предполагает перемещение груза между различными зонами склада. Транспортировка грузов внутри склада должна осуществляться при минимальной протяженности во времени и пространстве по сквозным «прямоточным» маршрутам.
Складирование и хранение.
Процесс складирования заключается в размещении и укладке груза на хранение. Основной принцип рационального складирования – эффективное использование объема зоны хранения.
Процесс складирования и хранения включает:
закладку груза на хранение;
хранение груза и обеспечение соответствующих для этого условий;
контроль за наличностью запасов на складе, осуществляемый через информационную систему.
Комплектация (комиссионирование) заказов и отгрузка.
Процесс комплектации сводится к подготовке товара в соответствии с заказами потребителей. Комиссионирование заказов клиентов проводится в зоне комплектации. Подготовка и оформление документации осуществляется через информационную систему. При этом выбирается оптимальный маршрут доставки заказов.
Транспортировка и экспедиция заказов
могут осуществляться как складом, так и самим заказчиком. Наиболее распространена и экономически оправдана централизованная доставка заказов складом.
Сбор и доставка порожних товароносителей
играют существенную роль в статье расходов. Эффективный обмен товароносителей возможен лишь в тех случаях, когда достоверно определено их оптимальное количество и четко выполняется график их обмена с потребителями.
Информационное обслуживание склада
предполагает управление информационными потоками и является связующим стержнем функционирования всех служб склада.
Информационное обслуживание охватывает:
обработку входящей документации;
предложения по заказам поставщиков;
оформление заказов поставщиков;
управление приемом и отправкой;
контроль наличия товаров на складе;
прием заказов потребителей;
оформление документации отправки;
диспетчерскую помощь, включая оптимальный выбор партий отгрузки и маршруты доставки;
обработку счетов клиентов;
обмен информацией с оперативным персоналом и верхним иерархическим уровнем организации;
различную статистическую информацию.
Контроль за выполнением заказов и обеспечение обслуживания клиентов.
На обеспечение координации деятельности службы продаж в первую очередь направлены операции контроля за выполнением заказов и оказание услуг клиентам, от выполнения которых зависит уровень обслуживания. Выделяют три основные категории элементов обслуживания: допродажное, во время продажи и послепродажное.
1.2 Описание предметной области (бизнес-процессы)
Вся ответственность в управлении предприятием лежит на Генеральном директоре. Основной целью деятельности при управлении является максимизация прибыли и минимизация рисков. Именно эти задачи являются основными при работе в этой сфере деятельности. Цели деятельности можно охарактеризовать таким образом:
- обеспечить создание соответствующей организационной структуры продаж;
- обеспечить эффективное управление персоналом;
- планировать размещение и ассортимент товаров;
- сегментировать рынок по покупателям.
Основными задачами являются:
повышение оперативности и достоверности информации о состоянии предприятия;
повышение контроля выполнения управленческих решений и планов;
снижение риска злоупотреблений со стороны персонала;
оптимизация использования финансовых, трудовых и материальных ресурсов;
разработка и внедрение новых информационных технологий, PR-акции, реклама;
планирование и проведение специальных мероприятий;
продвижение товара;
ценообразование;
оценка эффективности управления.
Основные функции:
- непосредственное участие в разработке и управлении продажами;
- ведение БД клиентов и товаров;
- составление и оформление заказов клиентов;
составление и оформление заявок поставщикам;
- предоставление необходимой информации клиентам;
- предоставлении необходимой информации поставщикам;
- осуществление мероприятий по разработке стратегии продаж;
- мотивация сотрудников;
- предложение новых товаров;
- эффективность управления.
Вся вышеуказанная информация характеризует систему управления складской логистикой. Сотрудниками данного отдела являются:
Генеральный директор;
Работники отдела сбыта, главная функция которых состоит в работе и связи с клиентами;
Работники склада: их главная задача – обеспечение и контролирование товаров.
Разработка данного автоматизированного рабочего места предназначена для закрытого акционерного общества (ЗАО) «Приосколье», которое на данный момент времени занимает большую нишу на Российском рынке производственных товаров. «Приосколье» - это крупный птицеводческий комплекс, который начал свою деятельность в 2004 году, а уже в 2005 году предприятие вышло на производственную мощность. На данный момент объем выпускаемого мяса птицы доведено до 50 тысяч тонн в год. На данный момент в производственной работе занято около двух тысяч человек.
Задачи, которые ставит перед собой ЗАО «Приосколье» следующие:
создание вертикально-интегрированного птицеводческого комплекса с замкнутым циклом по производству мяса бройлеров путем увеличения существующих производственных мощностей;
занятие прочной позиции отечественного товаропроизводителя куриного мяса высокого качества в существующей сегодня нише продовольственных товаров, используя:
знание и опыт ведущих зарубежных компаний для организации и технологического ведения проекта первые 2-3 года;
поддержку птицеводства России Правительством;
возможность получения субсидий из федерального и областного бюджета для компенсации процентной ставки по кредиту;
разрешение правительством РФ беспошлинного ввоза в Россию соевого шрота, важнейшего компонента корма птицы, производимого в России в недостаточном количестве;
наличие зарубежных поставщиков современного оборудования и технологий, обязующихся сопровождать строительство, запуск. Выход на проектную мощность всех структурных звеньев комплекса, участвовать в оптимизации технологических процессов.
1.3 Обоснование для разработки нового программного обеспечения
При выборе способов собственной автоматизации у каждой компании существуют следующие альтернативы:
Приобрести готовое решение.
В данной ситуации организация покупает настроенную модель ведения бизнеса. Плюсами такого решения можно считать: низкую стоимость системы, универсальный набор связанных бизнес процессов, высокую надежность. В качестве минусов следует отметить: необходимость перестройки собственной деятельности под приобретенную модель, отсутствие специфичной управленческой отчетности.
Приобрести адаптируемое решение и услуги по настройке.
При таком подходе организация получит универсальное программное обеспечение, адаптированное под его специфику. Качество адаптации очень сильно зависит от стоимости дополнительной настройки. Такое решение будет учитывать специфику данной организации, как в плане процессов, так и отчетности. Надежность данного решения будет меньше, так как в ходе настройки неизбежно будет внесено какое-то количество ошибок. Стоимость владения будет существенно выше, чем в первом случае.
Нанять собственных специалистов, которые создадут решение.
Данный подход должен иметь право на жизнь только в случае совершенной уникальности стоящих задач. Аргументами за использование такого подхода может служить только полное соответствие решения поставленным задачам.
Сравнительная характеристика существующих
программных продуктов.
На данный момент на российском рынке существует очень много разнообразного ПО для автоматизации складской логистики. Некоторые из них представлены в таблице 1, где описываются основные их характеристики:
Таблица 1
Количество транзакций в час |
Количество пользователей | Поддержка | Внедрение в эксплуатацию, в мес. | Количество радиотерминалов | Стоимость, тыс. дол. |
|
| “ФОЛИО ЛогистикСклад” 8.1 | менее 200 |
не более 10 |
- поддержка бумажной технологии или ограниченного круга терминалов сбора данных; - предоставление стандартных отчетов; - автономный режим работы или простейший интерфейс обмена данными с головной системой |
3-6 | не более 10 |
менее 15 |
| advantics фирмы PSI Logistics | свыше 1000 | свыше 40 | - наличие наряду со стандартными и настраиваемыми отчетами генератора отчетов; - потребность в мощных вычислительных платформах; - предоставление интерфейсов к системе корпоративного управления и к устройствам складской механизации |
15-30 | свыше 20 | от 50 |
| Radio Beacon WMS Expert фирмы Radio Beacon | от 200 до 1000 | от 10 до 40 |
- наличие наряду со стандартными отчетами генератора отчетов; - способность работать на компьютерных платформах среднего уровня или на рабочих станциях в режиме тонкого клиента; - наличие интерфейсов к системе корпоративного управления и к устройствам механизации складских операций |
12 | 10-20 | 15-50 |
| Logistics Vision Suite от Mantis | около 800 | свыше 35 | - наличие наряду со стандартными отчетами генератора отчетов; - потребность в мощных вычислительных платформах; - автономный режим работы или простейший интерфейс обмена данными с головной системой |
17-25 | около 20 | свыше 30 |
| CoreWMS от “Аргус Софт” | от 500 до 800 | 25-40 | - поддержка бумажной технологии или ограниченного круга терминалов сбора данных; - способность работать на компьютерных платформах среднего уровня или на рабочих станциях в режиме тонкого клиента; - предоставление интерфейсов к системе корпоративного управления и к устройствам складской механизации |
10 | 10-15 | 15-30 |
Для автоматизации складом ЗАО «Приосколье» мною был выбран третий подход. Такое решение было принято по следующим причинам:
1) высокая стоимость тех программ, которые уже существуют на рынке. Я считаю, что не каждое предприятие может позволить себе программное обеспечение стоимостью от 15 до 50 тысяч долларов;
2) мала вероятность того, что купленное программное обеспечение будет полностью удовлетворять требованиям конкретного предприятия. Возможно, придется «дописывать» некоторые модули программы.
То есть автоматизированная система управления складом будет создана именно для этого предприятия и будет уникальным в своем роде. Даня программа будет выполнять такие операции как:
1. Адресный учет товарно-материальных ценностей на складе.
2. Разбиение сложных складских процедур на простейшие технологические операции.
3. Управление действиями сотрудников на складе.
4. Оптимизацию передвижения по складу при сборе заказов.
5. Получение информации об исполнителе каждой технологической операции.
Основными преимуществами предлагаемого нами решения являются:
1. Простота во внедрении и использовании.
2. Уникальность и полное соответствие всем требования предприятия.
3. Невысокая стоимость.
1.4 Техническое задание
Прежде чем приступать к разработке автоматизированной системы необходимо определить основные критерии, по которым будет разработана система и выявить основные требования. Для этого необходимо составить техническое задание, на основании которого будет разработана конкретная автоматизированная система для предприятия.
1. Основание для разработки.
Настоящее техническое задание распространяется на разработку автоматизированной системы управления складом предприятия, предназначенной для предоставления наиболее полной информации об услугах и работе ЗАО «Приосколье». Предполагается, что использовать данную систему будут сотрудники склада.
Основными задачами данной автоматизированной системы является получение наиболее точной информации о товаре на складе, о поставщиках, о покупателях и сделках с ними.
Эта система обеспечит оперативный доступ к необходимой информации.
2. Назначение.
Она предназначена для хранения и обработки данных о товаре на складе, об услугах, которые также предоставляются данным предприятием. Обработанные данные могут использоваться сотрудниками, оформляющими заказы, клиентами (о наличии услуг) и другими сотрудниками предприятия для принятия решений о заказах новых услуг поставщикам.
3. Требования к программе или программному изделию.
Требования к функциональным характеристикам.
Система должна обеспечивать возможность выполнения следующих функций:
Регистрация в системе;
Аутентификация;
Отображение, ввод и коррекцию информации о товарах, имеющихся на складе;
Отображение, ввод и коррекцию информации о клиентах;
Ввод и коррекцию информации о заказах, предоставление клиенту его экземпляра договора, вывод на печать экземпляра договора предприятия;
Обработка заказов и ведение финансового журнала выполнения заказов;
Предоставление статистики по бухгалтерскому учету для клиента;
Исходные данные:
Список товаров;
Цены на товары;
Информация о клиенте (ФИО, адрес, номер и серия паспорта);
Информация о заказе (код интересующего договора, дата и срок выполнения заказа).
Результаты:
Список договоров;
Финансовый отчёт руководителю (прибыль и убытки за определённый промежуток времени);
Электронные и напечатанные экземпляры договоров.
Требования к надёжности.
Предусмотреть контроль вводимой информации.
Предусмотреть блокировку некорректных действий пользователя при работе с системой.
Обеспечить целостность хранимой информации.
Обеспечить защиту от несанкционированного доступа к информации.
Требования к составу и параметрам технических средств
Система должна работать на IBM совместимых компьютерах.
Минимальная конфигурация:
Тип процессора……...PentiumII или Athlonи выше;
Частота процессора …………………..333Mhz и выше;
Объём оперативного запоминающего устройств…64 Мб и более;
Объем свободного пространства на жестком диске……5 Mб и выше.
Требования к информационной и программной совместимости.
Система должна работать под управлением семейства операционных систем Win 32 (Windows 95, Windows 98, WindowsMe, Windows 2000, WindowsNT, WindowsXP).
Требования к программной документации.
Разрабатываемые программные модули должны быть самодокументированны, т.е. тексты программ должны содержать все необходимые комментарии.
Программная система должна включать справочную систему о работе и подсказки пользователю.
В состав сопровождающей документации должны входить:
Пояснительная записка, содержащая описание разработки.
4.3.2 Руководство системного программиста.
4.3.3 Руководство пользователя.
4.3.4.1. Схема структурная программной системы.
4.4.3.2. Формы интерфейса пользователя.
Из всего вышесказанного можно сделать вывод, что для работы любого предприятия необходима какая-либо информационная поддержка, которая могла бы упростить работу всех сотрудников предприятия. Для этого и было автоматизировано рабочее место, которое предназначено для хранения и обработки данных об имеющихся на складе товаров, об услугах, которые также предоставляются потребителям. Именно такая система смогла бы сэкономить время, деньги и обеспечить правильность ведения всех проводимых на складе операций и управлять ими.
Глава
II
. Разработка ПО и построение БД
2.1 Функциональные требования к системе
Информационная система, построенная на основе данных принципов, должна, с одной стороны, служить источником информации для сопровождения этапов продажи и инструментом для работы с поступающей и аккумулируемой информацией, с другой стороны, позволять контролировать состояние в любой момент времени по выделенным параметрам.
Для работы в соответствии с данными принципами база должна обеспечивать следующую функциональность:
А. Информационные.
Работа с информацией о товаре на складе.
Работа с адресной информацией о клиенте.
Работа с рыночной информацией.
Информационная поддержка продаж.
Б. Функции поддержки при работе с клиентом.
Текущая ситуация при работе с клиентом.
Потребности клиента в товарах предприятия.
Работа по этапам сделки.
Обеспечение функций по продажам при работе с клиентами.
В. Функции поддержки при управлении отделом.
Планирование работы отдела.
Постановка задач перед работниками отдела.
Контроль выполнения задач работниками отдела.
Контроль текущих показателей работы отдела.
Получение фактических показателей по итогам периода.
Г. Функции анализа и прогнозирования.
Анализ продаж.
Прогнозирование динамики продаж.
Анализ результатов работы сотрудников.
Анализ рыночной ситуации.
Д. Функции обработки имеющейся информации.
Оперативная обработка имеющегося массива информации при изменении отдельных атрибутов (например, при изменении территориального распределения компаний).
Оперативное создание групп клиентов для работы по специальным программам.
Другие групповые действия над записями.
Перечисленные функции являются основными, для обеспечения которых и создается база. Разумеется, в зависимости от уровня реализации, перечень функций может меняться - скажем, в простейшем случае БД может обеспечивать только информационные функции, а другие только частично.
2.2 Схема работы склада предприятия
Для проектирования автоматизированного рабочего места «Логистика» используется программа BPwin 4.0, которая является мощным инструментом для создания моделей, позволяющих анализировать, документировать и планировать изменения сложных бизнес-процессов. BPwin предлагает средство для сбора всей необходимой информации о работе предприятия и графического изображения этой информации в виде целостной и непротиворечивой модели.
BPwin поддерживает три методологии: IDEF0, DFD и IDEF3, позволяющие анализировать бизнес с трех ключевых точек зрения:
С точки зрения функциональности системы. В рамках методологии IDEF0 (Integration Definition for Function Modeling) бизнес-процесс представляется в виде набора элементов-работ, которые взаимодействуют между собой, а также показывается информационные, людские и производственные ресурсы, потребляемые каждой работой.
С точки зрения потоков информации (документооборота) в системе. Диаграммы DFD (Data Flow Diagramming) могут дополнить то, что уже отражено в модели IDEF3, поскольку они описывают потоки данных, позволяя проследить, каким образом происходит обмен информацией между бизнес-функциями внутри системы. В тоже время диаграммы DFD оставляют без внимания взаимодействие между бизнес-функциями.
С точки зрения последовательности выполняемых работ. И еще более точную картину можно получить, дополнив модель диаграммами IDEF3. Этот метод привлекает внимание к очередности выполнения событий. В IDEF3 включены элементы логики, что позволяет моделировать и анализировать альтернативные сценарии развития бизнес-процесса.
BPwin умеет проверять создаваемые модели с точки зрения синтаксиса выбранной методологии, проверяет ссылочную целостность между диаграммами, а также выполняет ряд других проверок, чтобы помочь создать правильную модель, а не просто рисунок. При этом сохраняются главные преимущества рисунка – простота создания и наглядность.
Как видно из контекстной диаграммы (рисунок 2), управляющая информация входит в блок сверху (Лицензия на занятие торговлей), в то время как входная информация (Бланк заявки поставщику, Бланк заказа клиента, Список о количестве запасов на складе), которая подвергается обработке, показана с левой стороны блока, а результаты (выход) показаны с правой стороны блока (Заполненный и заверенный бланк заявки, Договора, контрольные документы). Механизм (Работники отдела склада, Работники отдела продаж), который осуществляет операцию, предоставляется дугой, входящий в блок снизу.
Рисунок 2. Контекстная диаграмма.
Далее блок «Автоматизированная система управления складом» разбивается на три процесса, которые представлены на диаграмме декомпозиции процесса (рисунок 3):
Оформление заявки на поставку товара;
Формирование заказа клиента;
Оформление договора на продажу.
Рисунок 3. Диаграмма декомпозиции процесса.
На основании вышеприведенных диаграмм определяются основные задачи и функции разрабатываемой автоматизированной системы управления складом предприятия.
Основными задачами системы являются:
повышение оперативности и достоверности информации о состоянии предприятия;
повышение контроля выполнения управленческих решений и планов;
снижение риска злоупотреблений со стороны персонала;
оптимизация использования финансовых, трудовых и материальных ресурсов;
разработка и внедрение новых информационных технологий, PR-акции, реклама;
планирование и проведение специальных мероприятий;
продвижение товара;
ценообразование;
оценка эффективности управления.
Основные функции системы:
- непосредственное участие в разработке и управлении продажами;
- ведение БД клиентов и товаров;
- составление и оформление заказов клиентов;
составление и оформление заявок поставщикам;
- предоставление необходимой информации клиентам;
- предоставлении необходимой информации поставщикам;
- осуществление мероприятий по разработке стратегии продаж;
- мотивация сотрудников;
- предложение новых товаров;
- эффективность управления.
Вся вышеуказанная информация характеризует систему управления складской логистикой. Сотрудниками данного отдела являются:
Генеральный директор;
Работники отдела сбыта, главная функция которых состоит в работе и связи с клиентами;
Работники склада: их главная задача – обеспечение и контролирование товаров.
2.3 Выбор и обоснование технологии проектирования и инструментальных средств разработки
Любой проект разработки программного обеспечения в своем развитии проходит определенный жизненный цикл – последовательность этапов и совокупность действий, в результате которых создается первая версия продукта. Реалистичная модель жизненного цикла упрощает выполнение проекта и гарантирует, что в проекте с каждым следующим этапом реализуется все больше запланированных задач. Прежде чем приступить к разработке системы необходимо иметь четкое описание методологии разработки, адаптированной к конкретному проекту. На основе выбранной методологии производится выбор конкретных проектных инструментов и программных средств (таблица 2):
Таблица 2
| Средства | Rational Rose Enterprise Edition | BPWin 4.0 | EasyCase 3.1 | Вес критерия |
| Критерии | ||||
| цена/доступность | 10 | 10 | 9 | 5 |
| объектный подход | 10 | 0 | 0 | 5 |
| Функциональный подход | 0 | 10 | 7 | 5 |
| требования к ресурсам | 7 | 8 | 10 | 3 |
| Техническая поддержка | 10 | 10 | 1 | 4 |
| Совместимость с установленным ПО | 10 | 10 | 2 | 4 |
| Итого | 201 | 204 | 122 |
Основываясь на всем вышеуказанном, было принято решение использовать в качестве инструментального средства разработки проекта RationalRoseEnterpriseEdition, который полностью поддерживает объектно-ориентированный подход.
Rational Rose - CASE-средство фирмы Rational Software Corporation (США) - предназначено для автоматизации этапов анализа и проектирования ПО, а также для генерации кодов на различных языках и выпуска проектной документации.
Структура и функции
В основе работы Rational Rose лежит построение различного рода диаграмм и спецификаций, определяющих логическую и физическую структуры модели, ее статические и динамические аспекты. В их число входят диаграммы классов, состояний, сценариев, модулей, процессов.
Средства автоматической генерации кодов программ на языке С++, используя информацию, содержащуюся в логической и физической моделях проекта, формируют файлы заголовков и файлы описаний классов и объектов. Создаваемый таким образом скелет программы может быть уточнен путем прямого программирования на языке С++. Анализатор кодов С++ реализован в виде отдельного программного модуля. Его назначение состоит в том, чтобы создавать модули проектов в форме Rational Rose на основе информации, содержащейся в определяемых пользователем исходных текстах на С++. В процессе работы анализатор осуществляет контроль правильности исходных текстов и диагностику ошибок. Модель, полученная в результате его работы, может целиком или фрагментарно использоваться в различных проектах. Анализатор обладает широкими возможностями настройки по входу и выходу. Например, можно определить типы исходных файлов, базовый компилятор, задать, какая информация должна быть включена в формируемую модель и какие элементы выходной модели следует выводить на экран. Таким образом, Rational Rose/С++ обеспечивает возможность повторного использования программных компонент.
В результате разработки проекта с помощью CASE-средства Rational Rose формируются следующие документы:
диаграммы классов;
диаграммы состояний;
диаграммы сценариев;
диаграммы модулей;
диаграммы процессов;
спецификации классов, объектов, атрибутов и операций
заготовки текстов программ;
модель разрабатываемой программной системы.
Последний из перечисленных документов является текстовым файлом, содержащим всю необходимую информацию о проекте (в том числе необходимую для получения всех диаграмм и спецификаций).
Тексты программ являются заготовками для последующей работы программистов. Они формируются в рабочем каталоге в виде файлов типов .h (заголовки, содержащие описания классов) и .cpp (заготовки программ для методов). Система включает в программные файлы собственные комментарии, которые начинаются с последовательности символов //##. Состав информации, включаемой в программные файлы, определяется либо по умолчанию, либо по усмотрению пользователя. В дальнейшем эти исходные тексты развиваются программистами в полноценные программы.
Взаимодействие с другими средствами и организация групповой работы
Rational Rose интегрируется со средством PVCS для организации групповой работы и управления проектом и со средством SoDA - для документирования проектов. Интеграция Rational Rose и SoDA обеспечивается средствами SoDA.
Для организации групповой работы в Rational Rose возможно разбиение модели на управляемые подмодели. Каждая из них независимо сохраняется на диске или загружается в модель. В качестве подмодели может выступать категория классов или подсистема.
Для управляемой подмодели предусмотрены операции:
загрузка подмодели в память;
выгрузка подмодели из памяти;
сохранение подмодели на диске в виде отдельного файла;
установка защиты от модификации;
замена подмодели в памяти на новую.
Наиболее эффективно групповая работа организуется при интеграции Rational Rose со специальными средствами управления конфигурацией и контроля версий (PVCS). В этом случае защита от модификации устанавливается на все управляемые подмодели, кроме тех, которые выделены конкретному разработчику. В этом случае признак защиты от записи устанавливается для файлов, которые содержат подмодели, поэтому при считывании "чужих" подмоделей защита их от модификации сохраняется и случайные воздействия окажутся невозможными.
2.4 Постановка задач по подсистемам
Выше были определены функциональные требования к системе. Все эти функции включают в себя реализацию конкретных задач.
Использование диаграммы UseCase (рисунок 4)– это возможность увидеть систему с ее функциями и подфункциям с точки зрения пользователя.
«Генеральный директор»
ввиду постоянных внешних и внутренних изменений корректирует бизнес-план. В ходе написания этих корректировок следует дать достоверную оценку макроэкономической ситуации и текущего состояния рынка в целом, а также положения на нем отрасли, динамики ее развития и имеющихся у нее перспектив, при условии неизменности подходов. Кроме того, оценивается внутренняя ситуация отрасли и обозначаются назревшие проблемы
Рисунок 4. Диаграмма
Use
Case
.
Рассмотрим каждую функцию:
Проведение ценовой политики – оптимальная ценовая политика требует определенной информационной поддержки. Эта функция является основной, потому что именно с помощью нее можно значительно поднять уровень продаж, снижая цены. С помощью нее мы учитываем все факторы и принимаем решения.
Сравнение имеющихся ресурсов – с помощью этой функции сравниваем и анализируем уже имеющиеся ресурсы. С помощью них можно охарактеризовать эффективность управления продажами.
Снижение издержек и рисков – с помощью снижения издержек можно повысить спрос и наоборот. От этой функции зависит многое, так как риск является скрытым препятствием и может понизить уровень продаж.
Использование финансовых и материальных ресурсов – необходимо увязать имеющиеся у нас ресурсы с необходимыми требованиями рынка.
«Склад»
От того, насколько правильно и точно будет выполняться и строиться работа склада предприятия зависит очень многое. Это основывается на том, что основной и главной функцией склада является контролирование и пополнение уже имеющихся товаров, а также закупка новых. Наряду с этим рассматриваются следующие функции:
Формирование заявки (формирование заказов поставщикам) – необходимо оформить заказ на основе планов закупок. При этом производится анализ уже имеющихся товаров. Также производится точный анализ рынка предлагаемой продукции. Необходимо выбрать тех поставщиков, которые бы отвечали нашим требованиям и запросам (например, выбираем приемлемые цены и хорошее качество вместо дешевого товара, но зато низких цен.)
Входной информацией является:
ID поставщика;
Наименование товара;
Количество единиц;
Дата и время доставки;
Остаток товара на складе.
Выходной информацией является оформление заявки.
Имеющиеся товары на складе – необходимо предоставить максимально точную информацию о всех товарах. На основании этого создается и формируется заявка, в которой нужно указать точное количество единиц товара, который нам необходим.
Исполнение обязательств по договорам – здесь работник Склада оговаривает точные сроки поставки и отгрузки товара. Выписывает необходимые для этого документы.
Контроль взаиморасчетов с поставщиками – необходимо своевременно рассчитываться с поставщиками. В противном случае предприятие не застраховано от того, что поставщик не подведет и вовремя осуществит выполнение нашей заявки. Это немаловажная функция, потому что иметь одних и тех же поставщиков в течении длительного времени, с которыми отлажена работа гораздо удобнее, нежели постоянно от заявки к заявке налаживать контакты с новыми.
«Отдел продаж»
Какой бы выгодный товар не получил Склад, как бы хорошо не распланировало весь процесс Генеральный директор в конечном итоге все упирается в Отдел продаж и его работников. От того, насколько хорошо они знают и умеют выполнять свою работу, зависит, как будет продаваться товар, и, как следствие, благополучие управления продажами. В разрабатываемой системе считается, что работник Отдела продаж сам заполняет форму заказа. Форма заполняется каждый раз, когда приходит новый клиент.
Формирование заказа – заказ формируется основываясь на БД имеющихся в наличии товаров.
Входной информацией является:
№ заказа;
ID клиента;
Наименование товара;
Количество единиц товара;
Стоимость товара;
Дата заказа.
Выходной информацией является оформленный заказ.
Учет и контроль за исполнением заказов клиентов.
Ведение договоров с покупателями – оговариваются условия доставки товара, а также условия расчета.
Анализ продаж – на основании анализа продаж производится изучение потребительского спроса.
«Бухгалтерия»
Главной задачей является автоматизация складского учета, анализ состояния складов, контроль движения товарно-материальных ценностей; бухгалтерский и налоговый учет в полном соответствии с национальным законодательством; формирование налоговой, бухгалтерской и другой регламентированной отчетности в различные органы; бухгалтерский учет и контроль смет расходов бюджетных организаций в полном соответствии с законодательством и ведомственными инструкциями; сбор сводной отчетности бюджетных организаций
«Клиенты»
(потребители) – предприятием изучается потребительский спрос на производимый вид товара, разрабатывается гибкая система цен.
«Поставщики»
- юридическое или физическое лицо, обеспечивающее какими-либо товарами другое лицо на определенных условиях. Поставщиком может быть изготовитель и посредник.
Важно снизить стоимость материальных ресурсов для увеличения прибыли (при неизменных накладных расходах).
Выбор и определение поставщика (определить критерии оценки поставщика, затем осуществить его поиск). Поставщик может предложить себя сам, можно найти в справочниках, на ярмарках, выставках.
Критерии оценки поставщика:
- приемлемая цена;
- качество поставляемой продукции;
- качество обслуживания потребителей;
- гибкость поставок;
- ограничение размера заказа;
- дороги;
-удаленность поставщика от потребителя;
- психологический климат в коллективе;
- кредитоспособность и финансовое положение.
Критерии выбора поставщика:
- определение количества возможных поставщиков (определение всех возможных поставщиков, включая и тех, чьими услугами наша компания ранее не пользовалась);
- определение позиции поставщиков на рынке;
- определение профессионализма и надежности поставщиков;
- предварительная оценка всех возможных поставщиков (сравнение показателей сервиса и качества, предлагаемых поставщиками расходных материалов с показателями, требуемыми внутрипроизводственными потребителями);
- проведение переговоров с поставщиками;
- оценка уровня цены;
- надежность поставок.
Диаграмма классов (class diagram) (рисунок 5) служит для представления статической структуры модели системы в терминологии классов объектно-ориентированного программирования. Диаграмма классов может отражать, в частности, различные взаимосвязи между отдельными сущностями предметной области, такими как объекты и подсистемы, а также описывает их внутреннюю структуру и типы отношений.
Данная диаграмма классов позволяет увидеть взаимоотношения между объектами системы, связи и зависимости.
Рисунок 5. Диаграмма классов.
Диаграмма UseCase и диаграмма классов являются основанием для построения структуры БД.
2.5 Обоснование выбора СУБД
Access
для разработки БД
Приложение MicrosoftAccess является мощной и высокопроизводительной 32-разрядной системой управления реляционной базой данных (далее СУБД).
База данных
– это совокупность структурированных и взаимосвязанных данных и методов, обеспечивающих добавление выборку и отображение данных.
Реляционная база данных. Практически все СУБД позволяют добавлять новые данные в таблицы. С этой точки зрения СУБД не отличаются от программ электронных таблиц (MicrosoftExcel), которые могут эмулировать некоторые функции баз данных. Существует три принципиальных отличия между СУБД и программами электронных таблиц:
СУБД разрабатываются с целью обеспечения эффективной обработки больших объёмов информации, намного больших, чем те, с которыми справляются электронные таблицы.
СУБД может легко связывать две таблицы так, что для пользователя они будут представляться одной таблицей. Реализовать такую возможность в электронных таблицах практически невозможно.
СУБД минимизируют общий объём базы данных. Для этого таблицы, содержащие повторяющиеся данные, разбиваются на несколько связанных таблиц.
Access – мощное приложение Windows. При этом производительность СУБД органично сочетаются со всеми удобствами и преимуществами Windows.
Как реляционная СУБД Access обеспечивает доступ ко всем типам данных и позволяет одновременно использовать несколько таблиц базы данных. Можно использовать таблицы, созданные в среде Paradox или dBase. Работая в среде MicrosoftOffice, пользователь получает в своё распоряжение полностью совместимые с Accessтекстовые документы(Word), электронные таблицы(Excel), презентации(PowerPoint).С помощью новых расширений для Internet можно напрямую взаимодействовать с данными из WorldWideWeb и транслировать представление данных на языке HTML, обеспечивая работу с такими приложениями как InternetExplorer и NetscapeNavigator.
Access специально спроектирован для создания многопользовательских приложений, где файлы базы данных являются разделяемыми ресурсами в сети. В Access реализована надёжная система защиты от несанкционированного доступа к файлам.
Несмотря на то, что Access является мощной и сложной системой, его использование не сложно для непрофессиональных пользователей.
Элементы базы данных.
Таблицы.
В базе данных информация хранится в виде двумерных таблиц. Можно так же импортировать и связывать таблицы из других СУБД или систем управления электронными таблицами. Одновременно могут быть открыты 1024 таблицы.
Запросы.
При помощи запросов можно произвести выборку данных по какому-нибудь критерию из разных таблиц. В запрос можно включать до 255 полей.
Формы.
Формы позволяют отображать данные из таблиц и запросов в более удобном для восприятия виде. С помощью форм можно добавлять и изменять данные, содержащиеся в таблицах. В формы позволяют включать модули.
Отчёты.
Отчёты предназначены для печати данных, содержащихся в таблицах и запросах, в красиво оформленном виде. Отчёты так же позволяют включать модули.
Макросы
Модули.
Модули содержат VBA-код, используемый для написания процедур обработки событий, таких как например нажатия кнопки в форме или отчёте, для создания функций настройки, для автоматического выполнения операций над объектами базы данных и программного управления операциями, т.е. добавление VBA-кода позволяет создать полную базу данных с настраиваемыми меню, панелями инструментов и другими возможностями. Модули снимают с пользователя приложения необходимость помнить последовательность выбора объектов базы данных для выполнения того или иного действия и повышают эффективность работы.
База данных может содержать до 32768 объектов.
В состав Accessвходит множество мастеров, построителей и надстроек, которые позволяют упростить процесс создания объектов базы данных.
2.6 Разработка структуры базы данных и отношений атрибутов
Осуществляется детализация хранилищ данных, а также документально обосновываются сущности системы и способы их взаимодействия, включая идентификацию объектов предметной области (сущностей), свойств этих объектов (атрибутов) и их связей (отношений).
Сущность представляет собой множество экземпляров реальных или абстрактных объектов, обладающих общими атрибутами или характеристиками. Любой объект системы может быть представлен только одной сущностью, которая должна быть уникально идентифицирована. Отношение в самом общем виде представляет собой связь между двумя и более сущностями. Отношение должно быть однозначно поименовано.
Для идентификации требований, в соответствии с которыми сущности вовлекаются в отношения, используются связи. Каждая связь соединяет сущность и отношение и может быть направлена только от отношения к сущности. Значение связи характеризует её тип и выбирается из множества: "0 или 1", "0 или более", "1", "1 или более", "диапазон p:q". Пара значений связей, принадлежащая одному и тому же отношению, определит тип этого отношения.
Для большинства приложений достаточно использовать следующие типы отношений:
один к одному (используется на верхних уровнях иерархии модели данных, на нижних встречается редко);
один ко многим (отношения такого типа являются наиболее часто используемыми);
многие ко многим (используется на ранних этапах проектирования с целью прояснения ситуации).
В дальнейшем каждое из отношений типа "многие ко многим" должно быть преобразовано в комбинацию типов отношений "один к одному" или "один ко многим" (возможно с введением вспомогательных ассоциативных сущностей и с введением новых отношений).
Каждая сущность обладает одним или несколькими атрибутами, которые однозначно идентифицируют каждый экземпляр сущности. При этом любой атрибут может быть определен как ключевой.
Все связи являются бинарными и представляют собой линии с двумя концами, соединяющими сущности, для которых должно быть определено имя, степень множественности и степень обязательности. Степень множественности определяет, один или много объектов участвуют в связи. Степень обязательности определяет, обязательна ли или не обязательна данная связь между сущностями.
Разработка структуры базы данных включает такие основные этапы, как:
идентификация сущностей, их атрибутов, а также первичных и альтернативных ключей;
идентификация отношений между сущностями и указание типов отношений;
разрешение неспецифических видов отношений (многие к многим).
Этап 1
является определяющим при построении модели. Исходной информацией для этого этапа служит содержание хранилищ данных, определяемое входящими и выходящими из него потоками. Первоначально осуществляется анализ хранилища, включающий сравнение содержимого входных и выходных потоков и создания на основе этого сравнения варианта схемы хранилища. На следующем шаге осуществляется упрощение схемы путем устранения избыточности. Следующий шаг – упрощение схемы при помощи нормализации (удаление повторяющихся групп). Единственным способом нормализации является расщепление данной схемы на две более простые. Далее производится определение ключевых атрибутов для идентификации сущности.
Для шага нормализации существуют концепции и методы, разработанные Коддом (Codd). Он установил три типа нормализованных схем, называемых первой, второй и третьей нормальной формой.
Согласно Кодду любая нормализованная схема (схема без повторяющихся групп) автоматически находится в первой нормальной форме (1НФ), независимо от того, насколько сложен ее ключ и какая взаимосвязь может существовать между ее элементами. По определению схема находится во второй нормальной форме (2НФ), если все её ключевые атрибуты полностью зависят от ключа. Схема находится в третьей нормальной форме (3НФ), если она находится во 2НФ, и ни какой неключевой атрибут не зависит от другого неключевого атрибута.
Этап 2
служит для выявления и определения отношений между сущностями, а также для идентификации типов отношений. На этом этапе допускаются неспецифические отношения "многие ко многим".
Определение отношений включает выявление связей, для этого отношение должно быть проверено в обоих направлениях следующим образом: выбирается экземпляр одной из сущностей и определяется, сколько различных экземпляров второй сущности может быть с ним связано.
Этап 3
предназначен для разрешения отношений "многие ко многим". Для этого каждое такое неспецифическое отношение преобразуется в два специфических с введением новых.
2.6.1 Нормализация базы данных
Нормализация таблиц базы данных - первый шаг на пути проектирования структуры реляционной базы данных. Строго говоря, конечно, не самый первый - сначала надо решить, что же мы вообще будем хранить в базе, то есть определиться со структурой полей, их типами и размерностью, смыслом хранимой в них информации.
Теория нормализации реляционных баз данных была разработана в конце 70-х годов 20 века. Согласно ей, выделяются шесть нормальных форм, пять из которых так и называются: первая, вторая, третья, четвертая, пятая нормальная форма, а также нормальная форма Бойса-Кодда, лежащая между третьей и четвертой.
База данных считается нормализованной, если ее таблицы (по крайней мере, большинство таблиц) представлены как минимум в третьей нормальной форме. Часто многие таблицы нормализуются до четвертой нормальной формы, иногда, наоборот, производится денормализация.
Главная цель нормализации базы данных - устранение избыточности и дублирования информации. В идеале при нормализации надо добиться, чтобы любое значение хран
Первая нормальная форма
Первая нормальная форма:
запрещает повторяющиеся столбцы (содержащие одинаковую по смыслу информацию)
запрещает множественные столбцы (содержащие значения типа списка и т.п.)
требует определить первичный ключ для таблицы, то есть тот столбец или комбинацию столбцов, которые однозначно определяют каждую строку
Вторая нормальная форма
Вторая нормальная форма требует, чтобы неключевые столбцы таблиц зависели от первичного ключа в целом, но не от его части: если таблица находится в первой нормальной форме и первичный ключ у нее состоит из одного столбца, то она автоматически находится и во второй нормальной форме.
Третья нормальная форма
Чтобы таблица находилась в третьей нормальной форме, необходимо, чтобы неключевые столбцы в ней не зависели от других неключевых столбцов, а зависели только от первичного ключа. Самая распространенная ситуация в данном контексте - это расчетные столбцы, значения которых можно получить путем каких-либо манипуляций с другими столбцами таблицы. Для приведения таблицы в третью нормальную форму такие столбцы из таблиц надо удалить.
Нормальная форма Бойса-Кодда
Нормальная форма Бойса-Кодда требует, чтобы в таблице был только один потенциальный первичный ключ. Чаще всего у таблиц, находящихся в третьей нормальной форме, так и бывает, но не всегда. Если обнаружился второй столбец (комбинация столбцов), позволяющий однозначно идентифицировать строку, то для приведения к нормальной форме Бойса-Кодда такие данные надо вынести в отдельную таблицу.
Четвертая нормальная форма
Для приведения таблицы, находящейся в нормальной форме Бойса-Кодда, к четвертой нормальной форме необходимо устранить имеющиеся в ней многозначные зависимости. То есть обеспечить, чтобы вставка / удаление любой строки таблицы не требовала бы вставки / удаления / модификации других строк этой же таблицы.
Пятая нормальная форма
Таблицу, находящуюся в четвертой нормальной форме и, казалось бы, уже нормализованную до предела, в некоторых случаях еще можно бывает разбить на три или более таблиц, соединив которые, мы получим исходную таблицу. Получившиеся в результате такой, как правило, весьма искусственной, декомпозиции таблицы и называют находящимися в пятой нормальная форме. Формальное определение пятой нормальной формы таково: это форма, в которой устранены зависимости соединения. В большинстве случаев практической пользы от нормализации таблиц до пятой нормальной формы не наблюдается.
Разработаны специальные формальные математические методы нормализации таблиц реляционных баз данных. На практике проектировщик баз данных, детально познакомившись с предметной областью, как правило, достаточно быстро создаст структуру, в которой большинство таблиц находятся в четвертой нормальной форме:.
Главное, чего мы добьемся, проведя нормализацию базы данных - это устранение (или, по крайней мере, серьезное сокращение) избыточности, дублирования данных. Как следствие, значительно сокращается вероятность появления противоречивых данных, облегчается администрирование базы и обновление информации в ней, сокращается объем дискового пространства.
2.6.2 База данных автоматизированной системы управления складом
После того как все таблицы системы отвечают принципам нормализации БД, следует определить наборы связей между таблицами для функциональной взаимосвязанной работы базы данных в системе (рисунок 6):
Рисунок 6. Схема данных.
Для этих целей система в общем виде условно разделяется на три составляющие:
Клиенты и оформление их заказов;
Поставщики, оформление заявок;
БД товаров.
В раздел «Клиенты и оформление их заказов» включены 2 таблицы:
«Клиенты»;
«ОформлениеЗаказа».
Связываются таблица «Клиенты» с таблицей «ОформлениеЗаказа» по ключевому полю «IDклиента», используя отношение типа «один ко многим». Схема связей показана на рисунке 7:
Рисунок 7. Схема связи «Клиенты и оформление их заказов».
В раздел «Поставщики, оформление заявок» включены следующие таблицы:
«Поставщики»;
«ОформлениеЗаявки».
Связываем эти таблицы используя тип отношения «один к одному», по ключевому полю «IDпоставщика». Схема данных связей показана на рисунке 8:
Рисунок 8. Схема «Поставщики, оформление заявок».
В разделе «БД товаров» используются уже вышеупомянутые таблицы:
«ОформлениеЗаказа»;
«ОформлениеЗаявки».
Эти таблицы связываются между собой с помощью с помощью третьей таблицы «БД товаров» типом отношения «один ко многим». Это видно из рисунка 9:
Рисунок 9. Схема «БД товаров».
Данные полей указанных таблиц формируются из полей идентификаторов клиентов, а также выбранных клиентом в процессе работы с системой.
Для условий требований Третьей нормальной формы в таблицах предусмотрен составной ключ, включающий в себя два поля {номер заказа и идентификатор клиента}, уникальный, достаточный и неизбыточный, однозначно определяющий каждую запись в таблицах.
Одному заказанному товару соответствует один номер заказа, но если клиент в процессе работы с системой заказывает ещё один товар, то на каждую запись по этому клиенту присваивается один номер заказа.
Если заказ оформлен, то есть, принят на выполнение в работу, а клиент желает заказать дополнительный товар, тогда оформляется новый заказ, используя те же идентификаторы клиента.
Основой для разработки базы данных служат таблицы, в которых содержится необходимая информация.
В данной БД используются следующие таблицы:
1. «Клиенты» (таблица 3):
IDКлиента: идентификатор клиента. Является ключевым полем данной таблицы. По нему выполняется поиск конкретного клиента;
ФИО клиента: вводятся фамилия, имя, отчество нового клиента;
Город: предприятию необходимо знать тот город, в котором проживает клиент;
Адрес: адрес клиента;
Телефон: телефон клиента;
e-mail: необходим для того, чтобы предприятие в любой момент могло вязаться с клиентом и уточнить его заказ;
Паспортные данные: необходимы для предприятия, потому что именно паспорт является главным удостоверяющим личность клиента документом.
Все вышеперечисленные поля крайне необходимы для того, чтобы внести в БД наиболее точную и достоверную информацию о клиенте.
Таблица 3.
«Клиенты»
| Название поля | Тип данных | Размер поля |
| IDКлиента | Счетчик, ключевое поле | Длинное целое |
| ФИО клиента | Текстовый | 50 |
| Город | Текстовый | 50 |
| Адрес | Текстовый | 50 |
| Телефон | Числовой | Длинное целое |
| Текстовый | 50 | |
| Паспортные данные | Числовой | Длинное целое |
«ОформлениеЗаказа» (таблица 4):
№заказа: является ключевым полем данной таблицы. По номеру заказа можно отследить и идентифицировать клиента;
IDКлиента: идентификатор клиента;
НаименованиеТовара: дается перечень товаров;
КоличествоЕдиницТовара: выбирается количество товара;
СтоимостьТовара: цена за единицу товара;
ДатаЗаказа: число оформления заказа;
БДТоваров: обращение к БД товаров.
Все эти поля служат для того, чтобы заказ был оформлен в индивидуальном порядке для каждого клиента.
Таблица 4.
«Оформление заказа»
| Название поля | Тип данных | Размер поля |
| №Заказа | Счетчик, ключевое поле | Длинное целое |
| IDКлиента | Числовой | Длинное целое |
| НаименованиеТовара | Текстовый | 50 |
| КоличествоЕдиницТовара | Числовой | Длинное целое |
| СтоимостьТовара | Денежный | |
| ДатаЗаказа | Дата/время | |
| БДТоваров | Мастер подстановок | Вводится из таблицы «БДТоваров» |
«Продажа» (таблица 5):
№заказа: является ключевым полем данной таблицы. По номеру заказа можно отследить и идентифицировать клиента;
ФИОКлиента: вводятся фамилия, имя и отчество клиента;
НаименованиеТовара: выбирается из списка всех товаров;
СтоимостьТовара: цена за единицу товара;
КоличествоЕдиницТовара: количество покупаемого товара;
ДатаЗаказа: число оформления продажи.
Для того, чтобы продать товар необходимо знать то что мы продаем и в каком количестве. Это наиболее подробно представлено в таблице «Продажа» данной БД.
Таблица 5.
«Продажа»
| Название поля | Тип данных | Размер поля |
| №Заказа | Счетчик, ключевое поле | Длинное целое |
| ФИО клиента | Текстовый | 50 |
| НаименованиеТовара | Текстовый | 50 |
| СтоимостьТовара | Денежный | |
| КоличествоЕдиницТовара | Числовой | Длинное целое |
| ДатаЗаказа | Дата/время |
«БДТоваров» (таблица 6):
НаименованиеТовара: предлается весь перечень имеющихся товаров;
КоличествоТовараНаСкладе: количество всех товаров, которые имеются на складе;
ЦенаЗаЕдиницуТовара: цена за единицу выбранного товара;
ОстатокТовараНаСкладе: остаток определенного товара на складе.
Продавая товар или приобретая товар через поставщиков нам необходимо руководствоваться какими-то данными. Эти данные мы получаем из таблицы «БДТоваров».
Таблица 6.
«БДТоваров»
| Название поля | Тип данных | Размер поля |
| НаименованиеТовара | Текстовый, ключевое поле | 50 |
| КоличествоТовараНаСкладе | Числовой | Длинной целое |
| ЦенаЗаЕдиницуТовара | Денежный | |
| ОстатокТовараНаСкладе | Числовой | Длинное целое |
«ОформлениеЗаявки» (таблица 7):
IDПоставщика: идентификатор поставщика, в данной таблице является ключевым полем;
НаименованиеТовара: тот товара, который необходимо включить в список заявки;
КоличествоЕдиниц: количесво заказываемого товара;
ДатаВремяДоставки: оговариваются дата и время когда товар будет доставлен.
Все эти поля служат для того, чтобы заявка была оформлена в индивидуальном порядке, где будут указаны конкретны товары в конкретном количестве.
Таблица 7.
«ОформлениеЗаявки»
| Название поля | Тип данных | Размер поля |
| IDПоставщика | Счетчик, ключевое поле | Длинное целое |
| НаименованиеТовара | Текстовый | 50 |
| КоличествоЕдиниц | Числовой | Длинной целое |
| ДатаВремяДоставки | Дата/время |
«Поставщики» (таблица 8):
IDПставщика: идентификатор поставщика, в данной таблице является ключевым полем;
ЮридическийАдрес: адрес, по которому можно связаться с поставщиком;
ФИО: фамилия, имя, отчество поставщика;
№РасчетногоСчета: один из важных атрибутов, необходим для того, чтобы предприятие могло переводить средства на счет поставщика.
В этой таблице представлены все данные, которые необходимы для работы с поставщиками.
Таблица 8.
«Поставщики»
| Название поля | Тип данных | Размер поля |
| IDПоставщика | Счетчик, ключевое поле | Длинное целое |
| ЮридическийАдрес | Текстовый | 50 |
| ФИО | Текстовый | 50 |
| №РасчетногоСчета | Числовой | Длинное целое |
Глава
III
. Система АРМ «Логистика»
Система АРМ «Логистика» предназначена для автоматизации работы с клиентами, поставщиками, а также для получения достоверной информации о всех товарах склада, об операциях, производимых на складе.
Для входа в систему АРМ «Логистика» Вам необходимо выполнить следующие указания:
Включить компьютер;
в меню «Пуск» выбрать необходимую программу и запустить ее;
запустить файл приложения «ProjectLogistika»;
После чего появится форма «Безопасный вход», на которой служащий предприятия (Работник Отдела Продаж, Работник Склада, Бухгалтер, либо Генеральный Директор) – пользователь системы АРМ «Логистика» - должны будут ввести индивидуальный пароль: Пользователь и Пароль;
Это необходимо для того, чтобы защитить систему от несанкционированного доступа посторонних лиц. В данной программе пароль не может содержать менее 6 и более 20 символов (буквы, цифры, либо буквы+цифры), не должен содержать пробелов. В коде программы прописан так называемый «счетчик», который блокирует программу после 5 неправильных вводов пароля.
После этого на экране пользователя появится главная форма программы «Главная форма», на которой пользователь может выполнить такие операции как: возможность зарегистрировать клиента и работать с базой данных товаров, а также перейти на форму ведения бухгалтерского учета и оформления заказов и заявок. Для всех работников предприятия определена и ограничена область пользования данной программой. Только Генеральный директор и Бухгалтерия имеют доступ к «Клиентам», «Поставщикам», «БД товаров», «Бухгалтерии». Остальные же работники могут работать только с конкретными, относящимися к их непосредственной сфере работы приложениями. Например, работники Склада могут работать с приложениями «БД товаров» и «Поставщиками», а работники Отдела Продаж с приложениями «БД товаров» и «Клиенты».
Предполагается, что кнопка «Клиенты» предназначена для работников Отдела продаж, в обязанности которых входит следующее:
зарегистрировать нового клиента и ввести о нем всю необходимую информацию;
выполнить новые операции для уже существующих клиентов (оформить заказ клиента);
продать товар.
Прежде чем начать работу с клиентом необходимо определить статус конкретного клиента: Новый клиент или Существующий клиент.
Также есть возможность с этого окна перейти к приложениям «Поставщики» и «Бухгалтерия», но это может сделать лишь начальник Отдела Продаж, у которого имеется доступ.
Здесь же на закладке «Товары» любой работник Отдела Продаж может получить достоверную информацию о всех имеющихся в наличии товаров. Для этого необходимо зайти на закладку «БД товаров». Также есть возможность узнать в каком количестве (остаток) конкретный товар имеется на складе. Это можно увидеть на вкладке «Товары» - «Остаток на складе».
Также здесь автоматизировано число регистрации клиента. Работник Отдела Продаж просто выбирает число и система автоматически сохраняет его для дальнейшей работы.
После того, как будут заполнены все поля, такие как: Статус клиента, Дата регистрации, Информация о клиенте работник Отдела Продаж «Создает» клиента. Также имеется возможность редактировать уже существующие записи, а также удалять их.
После того, как клиент зарегистрирован при нажатии на кнопку «Создать» появляется окно «Оформление заказа».
Здесь автоматически проставляется № заказа и из предыдущей таблицы переносится ID клиента. Работник Отдела продаж должен пометить все товары, которые хочет приобрести клиент. При выборе товара цена конкретного товара определяется автоматически, количество же товара прописывается вручную работником Отдела Продаж.
Дата заказа определяется автоматически на день оформления заказа.
После заполнения полей «№ заказа», «ID клиента», «Наименование товара», «Количество единиц товара», «Стоимость товара» работник Отдела продаж должен «Выполнить поиск по БД товаров…» и убедится в том, что товар действительно имеется в наличии и в достаточном количестве для осуществления конкретной продажи. При нажатии на кнопку «Выполнить поиск по БД товаров…» появится следующее окно:
Для того чтобы получить информацию о конкретном товаре необходимо не вкладке «Наименование товара» выбрать интересующий товар. Количество товара указывается определенным числом и вводится вручную. На вкладке «Цена за единицу товара» появится цена в рублях, в зависимости от того какой товар выбран цена появляется автоматически. Также здесь можно посмотреть, сколько товара осталось на складе и хватит ли его для того, чтобы оформить заказ.
После выполнения всех необходимых операций появляется окно:
Заказ считается оформленным.
Возвращаясь к нашей главной форме можно начать работу с поставщиками. Предполагается, что кнопка «Поставщики» предназначена для работников Склада, в обязанности которых входит следующее:
зарегистрировать нового поставщика и ввести о нем всю необходимую информацию;
выполнить новые операции для уже существующих поставщиков (оформить заявку для клиента);
Прежде чем начать работу с клиентом необходимо определить статус конкретного клиента: Новый клиент или Существующий клиент.
Также с этого окна можно перейти к приложениям «Клиенты», «Бухгалтерия», но такую возможность имеет лишь начальник Склада.
На вкладке «Товары» можно обратится к БД товаров, а также получить информацию о любом товаре (остаток), который имеется на складе.
На вкладке «Документы» из перечня мы выбирает конкретный документ: Заявка, Поступление ТМЦ (купля-продажа), Поступление ТМЦ (комиссия), Поступление ТМЦ (импорт).
Далее заполняются все поля, благодаря которым мы получаем наиболее достоверную информацию о поставщике. Создаем нового поставщика или редактируем уже существующего. После заполнения всех полей появляется окно:
В «Наименование товара» галочкой помечаем те товары, которые хотим включить в заявку, а в «Количество единиц товара» вручную цифрами прописываем то количество товара, которое нам необходимо. После этого согласовываем дату и время доставки товара и заполняем все оставшиеся поля. Заполнив все поля нажимает кнопку «Оформить заявку» и завершаем работу с поставщиками.
Также на главной форме имеется кнопка «БД товаров». Зайдя на нее можно получить полные сведения о все товарах. Которые имеются в наличии. По нажатию на эту кнопку появляется окно:
Здесь мы можем произвести отбор товара по тому признаку, который нас интересует. Это облегчает работу при поиске нужного товара. Мы можем отобрать товар по номенклатуре, по складам, по поставщикам, по дате поступления. Такой способ отбора позволяет сузить поиск и получить наиболее достоверную информацию за меньшее количество времени.
Глава
IV
. Расчет экономической эффективности
4.1 Анализ рыночных возможностей продукта
На рынке автоматизированных систем для крупных организаций и финансово-промышленных групп на сегодня можно выделить два основных субъекта: это рынок автоматизированных банковских систем (АБС) и рынок корпоративных информационных систем промышленных предприятий. Несмотря на сильную взаимосвязь этих двух рынков систем автоматизации, предлагаемые на них решения, пока еще не достаточно интегрированы между собой, чего следует ожидать в недалеком будущем. Создавая свои отделы и управления автоматизации, предприятия и банки пытались обустроиться своими силами. Однако периодическое "перетряхивание" инструкций, сложности, связанные с разными представлениями пользователей об одних и тех же данных, непрерывная работа программистов по удовлетворению все новых и новых пожеланий отдельных работников и как следствие - недовольство руководителей своими программистами несколько остудило пыл как тех, так и других. Итак, первый подход к решению этой проблемы сводился к проектированию "снизу-вверх". В этом случае, при наличии квалифицированного штата программистов, вполне сносно были автоматизированы отдельные, важные с точки зрения руководства рабочие места. Общая же картина "автоматизированного предприятия" просматривалась недостаточно хорошо, особенно в перспективе.
Быстрый рост числа акционерных и частных предприятий и банков позволил некоторым компаниям увидеть здесь будущий рынок и инвестировать средства в создание программного аппарата для этого растущего рынка. Из всего спектра проблем разработчики выделили наиболее заметные: автоматизацию ведения бухгалтерского аналитического учета и технологических процессов (для банков это в основном - расчетно-кассовое обслуживание, для промышленных предприятий - автоматизация процессов проектирования и производства, имеется в виду не конкретных станков и т.п., а информационных потоков). Учитывая тот факт, что ядром АИС безусловно является аппарат, обеспечивающий автоматизированное ведение аналитического учета, большинство фирм начали с детальной проработки данной проблемы. Системы были спроектированы "сверху", т.е. в предположении, что одна программа должна удовлетворять потребности всех пользователей.
Рассматриваемый в данной работе программный продукт позиционируется как средство, способное устранить недостатки каждого из двух вышеперечисленных подходов и решить задачу управления складом ЗАО “Приосколье”.
4.2 Расчет единовременных затрат на разработку ПО
К единовременным затратам разработчика относятся затраты на теоретические исследования, постановку задачи, проектирование, разработку алгоритмов и программ, отладку, опытную эксплуатацию, оформление документов.
Фактическая трудоемкость по стадиям проектирования представлена в виде таблицы (табл.4.1).
Таблица 4.1.
Содержание стадий научно-исследовательской работы (НИР).
| Стадии НИП | Содержание работ | Трудоемкость | |
| дни | % | ||
| Техническое задание | Изучение и анализ предметной области, изучение и анализ области внедрения, работа с консультантами, постановка задачи, составление и согласование технического задания с руководителем. | 22 | 12,6 |
| Эскизный проект | Построение концептуальной модели системы, описание входных и выходных данных, способов их преобразования. Разработка структур данных. | 33 | 21,6 |
| Технический проект | Разработка технического проекта. Построение структуры классов и определение способов их взаимодействия. | 31 | 19,2 |
| Рабочий проект | Написание программ, утилит и дополнительных модулей информационной системы, отладка программного обеспечения, тестирование. | 52 | 31,4 |
| Внедрение | Разработка справочной и технической документации, подготовка и защита отчета. Регистрация. | 24 | 15,2 |
| Итого: | 162 | 100 | |
Итак, общая фактическая трудоемкость разработки ПО составляет:
,
где – общая трудоемкость разработки, дни; Т
i
– трудоемкость по стадиям, дни; n
– количество стадий разработки.
В смету затрат на разработку ПО включаются:
материальные затраты;
основная и дополнительная зарплаты;
отчисления на социальные нужды;
стоимость машинного времени на подготовку и отладку программ;
стоимость инструментальных средств;
накладные расходы.
Материальные затраты.
Под материальными затратами понимают стоимость всех материалов, использующихся в процессе разработки и внедрения ПО (в том числе стоимость бумаги, дискет, картриджа или красящей ленты и прочих материалов) в действующих ценах.
В процессе работы использовались материалы и принадлежности, представленные в таблице 4.2.
Таблица 4.2.
Материалы и принадлежности, использованные в процессе разработки.
| Наименование | Количество, шт. | Цена, руб. | Стоимость, руб. |
| Дискеты | 7 | 15 | 105 |
| Бумага | 400 | 0,5 | 200 |
| Ватман | 6 | 10 | 60 |
| Ручка | 5 | 10 | 50 |
| CD-RW диск | 3 | 32 | 96 |
| Дипломная папка | 2 | 15 | 30 |
| Картридж | 1 | 200 | 200 |
| Итого: | 761 | ||
Основная и дополнительная заработные платы.
Основная заработная плата при выполнении НИР включает зарплату всех сотрудников, принимающих непосредственное участие в разработке ПО. В данном случае необходимо учитывать основные зарплаты разработчика (студента), руководителя дипломного проекта, консультанта по экономической части.
Таким образом, основная заработная плата Зосн
при выполнении НИР рассчитывается по формуле:
,
где Зср.дн.
j
– среднедневная зарплата j
-го сотрудника, руб./день; Тоб.
j
– общая трудоемкость проектаj
-го сотрудника, дни; n
– количество сотрудников, принимающих непосредственное участие в разработке ПО.
Основная зарплата разработчика определена из расчета 8000 руб. в месяц при среднем количестве рабочих дней, равных 24:
.
Заработная плата дипломного руководителя составляет 60 руб./час, причем на консультацию запланировано 23 часа. Следовательно, основная зарплата руководителя дипломного проекта за весь период разработки равна:
.
Заработная плата консультанта по экономической части составляет 50 руб./час, причем на консультацию запланировано 3 часа. Следовательно, основная зарплата консультанта по экономике за весь период разработки равна:
.
В итоге основная заработная плата при выполнении НИР равна:
.
Дополнительная заработная плата равна 10% от основной:
.
Итого основная и дополнительная заработная плата составляют:
.
Отчисления на социальные нужды.
Отчисления на социальные нужды составляют на сегодняшний день 26% от общего фонда заработной платы, следовательно:
.
Стоимость машинного времени на подготовку и отладку программ.
Стоимость машинного времени Зомв
зависит от себестоимости машино-часа работы ЭВМ СМЧ
, а также времени работы на ЭВМ ТЭВМ
, и включает амортизацию ЭВМ и оборудования, затраты на электроэнергию, зарплату обслуживающего персонала.
Себестоимость машино-часа ЭВМ и принтера равны соответственно:
,
.
Время работы на ЭВМ и принтере равны соответственно:
.
Затраты на оборудование.
,
где АМ
– амортизационные отчисления, руб.; Оф
– стоимость ЭВМ и оборудования, руб.; Нам
– норма амортизации, %; Тм
– время использования оборудования, дни
Затраты на электроэнергию.
,
Затраты на обслуживающий персонал.
Данный вид затрат отсутствует. Таким образом, стоимость машинного времени на подготовку и отладку программ равно:
Стоимость инструментальных средств.
Стоимость инструментальных средств включает стоимость системного программного обеспечения, использованного при разработке проекта в размере износа за этот период. Расчет производить аналогично расчету амортизационных отчислений оборудования, представим его в таблице 4.3.
Таблица
4
.3.
Стоимость СПО.
| Программное обеспечение | Стоимость, руб. |
| MS WINDOWS 2000 Prof | 6000 |
| Delphi 7 | 8100 |
| Microsoft Office XP Professional | 4500 |
| Итого: | 18600 |
Затраты на амортизацию инструментальных средств:
руб.
Расчет стоимости машинного времени
;
руб./ч.
Накладные расходы.
Накладные расходы составляют 30% от основной заработной платы разработчиков ПО, а значит:
.
Итак, смета затрат на НИР приведена в таблице 4.4.
Таблица 4.4.
Смета затрат на разработку ПО.
| Элемент затрат | Стоимость, руб. |
| Материальные затраты | 761 |
| Основная и дополнительная зарплата | 61248 |
| Отчисления на социальные нужды | 15924,48 |
| Оплата машинного времени | 2407,58 |
| Стоимость инструментальных средств | 1317,03 |
| Накладные расходы | 16780 |
| Итого: | 98438,09 |
4.3 Единовременные расходы организации заказчика ПО при внедрении
автоматизированных рабочих мест (АРМ)
К единовременным затратам пользователя программного обеспечения Kобщ
относятся затраты на оплату:
программного обеспечения Цпо
;
инструментальных средств Цис
;
ЭВМ, прочих аппаратных средств и сетевого оборудования Кэвм
;
обучение персонала Косв
.
Стоимость программного обеспечения.
Стоимость программного обеспечения, специально разработанного для заказчика, рассчитывается по формуле:
,
где Спо
– себестоимость ПО, затраты на разработку по смете из таблицы 4.4; П
– прибыль разработчика 20–30% к затратам; НДС
– налог на добавленную стоимость 18%.
Итак, стоимость программного обеспечения равна:
Стоимость инструментальных средств.
Стоимость инструментальных средств и годовых сумм амортизации приведены в таблице 4.5.
Таблица 4.5.
Расчет стоимости и амортизационных отчислений инструментальных средств.
| Виды ПО | Стоимость, руб. | Норма амортизации, % | Амортизационные отчисления, руб. |
| MS WINDOWS Millenium | 2500 | 30 | 750 |
Стоимость ЭВМ, прочих аппаратных средств и сетевого оборудования.
Стоимость всего необходимого оборудования и годовых сумм амортизации приведены в таблице 4.6.
Таблица 4.6.
Расчет стоимости и амортизационных отчислений оборудования.
| Наименование оборудования | Количество | Цена, руб. | Стоимость, руб. | Норма амортизации, % | Амортизационные отчисления, руб. |
| ПК
|
1 шт. | 30000,00 | 30000.00 | 30 | 9000,00 |
| Сетевая розетка | 1 шт. | 8,00 | 8,00 | 30 | 2,40 |
| Кабель UTP5 | 6 м | 4,00 | 24,00 | 30 | 7,20 |
| Хозяйственный инвентарь (мебель) | 1 шт. | 7500,00 | 7500,00 | 10 | 750,00 |
| Итого: | 37532,00 | 9759,6 | |||
Затраты на обучение персонала.
Затраты организации на освоение ПО и обучение персонала работе с программой и ЭВМ производятся по формуле:
Косв
= Зчас
* Чпр
* Тосв
= 23.8 * 5 * 42+23.8*1*50 = 6188,00(руб.
),
где Зчас
– часовая зарплата программиста (Зчас
= 23,8 руб./час);
Чпр
- численность персонала на обучение (Чпр
= 5 чел.);
Тосв
– продолжительность обучения и освоения (Тосв
= 42 часов).
Таким образом, на обучение четырех человек необходимо затратить 42часов. Для руководителя необходим 50-часовой курс обучения.
Итак, общая сумма единовременных капитальных вложений рассчитывается по формуле:
Распределение инвестиций по времени реализации проекта осуществляется на основе предварительных расчётов времени необходимого для разработки ПО по отдельным стадиям проектирования (таблица 4.7), затрат на разработку и общей суммы единовременных капитальных вложений.
Таблица
4
.7
График реализации проекта.
| Этапы реализации | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 |
| Техническое задание | 22 | |||||||
| Эскизный проект | 30 | 3 | ||||||
| Технический проект | 20 | 11 | ||||||
| Рабочий проект | 10 | 15 | 18 | 9 | ||||
| Внедрение | 12 | 12 | ||||||
| Покупка оборудования | 4 | |||||||
| Обучение персонала | 10 |
Результаты расчетов оформлены в виде инвестиционного плана (таблица 4.8).
Таблица
4
.8
Инвестиционный план.
| Этапы реализации | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 |
| Техническое задание | 17445,62 | |||||||
| Эскизный проект | 17445,62 | 8722,81 | ||||||
| Технический проект | 8722,81 | 8722,81 | ||||||
| Рабочий проект | 8722,81 | 17445,62 | 17445,62 | 8722,81 | ||||
| Внедрение | 8722,81 | 17445,62 | ||||||
| Покупка оборудования | 37532 | |||||||
| Обучение персонала | 6188 | |||||||
| Итого: | 17445,62 | 17445,62 | 17445,62 | 17445,62 | 54977,62 | 17445,62 | 17445,62 | 23633,62 |
Источники финансирования проекта
Общие инвестиции проекта составляют 183285 рублей 19 копеек. Источниками финансирования являются собственные средства – 80% (146628 рубля 19 копеек) и кредит коммерческого банка, под 12% годовых – 20% (36657 рубля 00 копеек) на 2 года.
Возврат кредита осуществляется в конце второго года, а со второго месяца выплачиваются проценты (12%). Приведем расчеты в таблице 4.9.
Таблица
4
.9
Расчеты за кредит.
| Показатель | Годы | |
| 1 | 2 | |
| Возврат кредита, руб. | - | 36657,00 |
| Сумма непогашенного долга, руб. | 36657,00 | 36657,00 |
| Проценты за кредит, руб. | 4398,84 | 4398,84 |
| Итого к оплате, руб. | 4398,84 | 41055,84 |
Сумма всех выплат по истечении срока составит 41055 рублей 84 копейки.
4.5 Текущие расходы пользователя ПО при эксплуатации АРМ
Текущие расходы пользователя при внедрении АРМ учитывают затраты в год на:
амортизацию оборудования, ПО и инструментальных средств;
материалы (картриджи и бумага);
электроэнергию;
обтирочные и смазочные материалы;
ремонт оборудования.
Амортизацию оборудования, ПО и инструментальных средств.
Данные по амортизации оборудования и ПО расположены в таблицах 4.5, 4.6.
Материалы.
При эксплуатации будут использоваться материалы, представленные в таблице 4.10.
Таблица 5.10
Материалы, использующиеся в процессе эксплуатации.
| Наименование | Количество, шт. |
Цена, руб. |
Стоимость, руб. |
| Бумага | 4000 | 0,4 | 1600 |
| Картридж | 1 | 200 | 200 |
| Итого: | 1800 | ||
Электроэнергия.
Затраты на электроэнергию посчитаем по формуле:
где СЭВМ
, Спринт.
– стоимость машино-часа ЭВМ и принтера соответственно;
Тсут.ЭВМ
, Тсут.принт.
– суточное время работы ЭВМ и принтера соответственно;
Тгод
– время рабочих дней в году.
Обтирочные и смазочные материалы.
Стоимость обтирочных материалов равна 50 рублей 00 копеек.
Ремонт оборудования.
Ремонт оборудования составляет 5% от стоимости. Значит:
К5%
= КЭВМ
* 0.05 = 37532 * 0.05 = 1876,6 (рублей
).
На основе произведенных расчетов составим смету текущих расходов за год (таблица 4.11).
Таблица 5.11
Смета текущих расходов.
| Затраты на: | Расходы, руб. |
| амортизацию оборудования, ПО и инструментальных средств | 10509,6 |
| материалы | 1800,00 |
| электроэнергию | 965,00 |
| обтирочные и смазочные материалы | 50,00 |
| ремонт оборудования | 1876,6 |
| Итого: | 15201,2 |
4.6 Экономия текущих затрат пользователя ПО
Основными источниками экономии организации при создании АРМ специалистов являются:
экономия затрат за счет ускорения документооборота;
экономия за счет быстрой реакции на изменение предпочтений покупателей
экономия затрат на заработную плату;
экономия материальных ресурсов за счет сокращения количества расходных материалов
а также обеспечивается экономия за счет:
Экономия затрат за счет ускорения документооборота.
В результате внедрения АРМ происходит ускорение документооборота, что является “узким” местом любой торговой организации, а значит и увеличение клиентской базы и объемов продаж. Это действительно серьезная проблема, особенно в свете постепенного выхода компании на рынок розничных продаж. По оценкам специалистов экономия составит не менее 19000 рублей в месяц или не менее 228000 в год. Более оперативная работа с поставщиками позволит снизить процент выплат по товарному кредиту и снизить вероятность штрафных платежей за несвоевременную поставку – при самом неблагоприятном стечении обстоятельств порядка 27000 рублей в месяц. Значит, экономия будет составлять минимум 300000 рублей в год.
Экономия за счет быстрой реакции на изменение предпочтений покупателей
Внедрение автоматизированной системы позволит сократить издержки, связанные с вынужденным снижением цены на товар в результате падения спроса на него, т.е. позволит избежать покупок и хранения невостребованной техники. По самым пессимистичным оценкам это позволит сэкономить от 7000 рублей ежемесячно, т.е. не менее 84000 в год.
Экономия затрат на заработную плату за счет сокращения численности персонала.
Оценить прямой эффект от внедрения АРМ с этой позиции очень просто, так как в данном конкретном случае оно приведет к освобождению одного рабочего места. Это связано с тем, что функции нового АРМа позволяют выполнять большее число операций с меньшей трудоемкостью. Рассчитаем экономию по заработной плате по формуле:
,
где D
Ч
– сокращение численности;
Змес
– оплата труда в месяц, (4000 руб.);
Тэф
– эффективный фонд рабочего времени в год, (12 месяцев);
Х
- размер доплат, премий,(100%);
Y
– отчисления на социальные нужды, (26%).
С учетом освобождения компьютерной техники и хозяйственного инвентаря экономия составит Э=120960+38532=159253 руб.
Экономия материальных ресурсов за счет сокращения количества и унификации отчетных форм.
В результате внедрения АРМ появится возможность экономии материальных затрат за счет сокращения количества расходных материалов в размере 4700 рублей.
Таким образом, общая экономия после внедрения АРМ составит:
Эобщ.
= 552000+84000 + 120960 + 4700 = 761660 (рублей
).
4.7 Финансовый план проекта
Инвестиционный проект с финансовой точки зрения объединяет два противоположных процесса - создание производственного объекта и получение дохода. Поэтому для оперативного управления финансами необходимо составить таблицу денежных потоков в соответствии с графиком реализации проекта.
Таблица денежных потоков наличности содержит сводные данные об объемах продаж, увеличении доходов, инвестициях, производственных и финансовых издержках по каждому периоду осуществления проекта. Вначале необходимо оценить ликвидность проекта - способность проекта отвечать по имеющимся финансовым обязательствам.
Оценка ликвидности проекта основывается на планировании движения денежных средств по каждому периоду. Для чего отдельно рассматриваются доходы и расходы объекта и разность между ними в денежном выражении.
С позиции бюджетного подхода под ликвидностью, понимают положительную разницу (сальдо) поступлений и платежей в течение всего срока жизни проекта. Отрицательное значение сальдо поступлений и платежей говорит о дефиците денежных средств
Для оценки финансовой состоятельности проекта представим исходные и расчетные данные в таблице 5.12.
Так как сальдо денежной наличности нарастающим итогом является по всем периодам положительной величиной, перейдем к определению чистой текущей стоимости проекта, характеризующей эффективность проекта.
Таблица 5.12
Оценка финансовой состоятельности проекта.
| 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 1 год | 2 год |
| 17445,62 | |||||||||||||
| 17445,62 | 8722,81 | ||||||||||||
| 8722,81 | 8722,81 | ||||||||||||
| 24722,81 | 1445,62 | 17445,62 | 8722,81 | ||||||||||
| 8722,81 | 17445,62 | ||||||||||||
| 37532 | |||||||||||||
| 6188 | |||||||||||||
| -17445,62 | -17445,62 | -17445,62 | -33445,62 | -38977,62 | -17445,62 | -17445,62 | -23633,62 | ||||||
| 63471,67 | 63471,67 | 63471,67 | 63471,67 | 761660,00 | 761660,00 | ||||||||
| 1266,77 | 1266,77 | 1266,77 | 1266,77 | 15201,20 | 15201,20 | ||||||||
| 410,56 | 410,56 | 410,56 | 410,56 | 410,56 | 410,56 | 410,56 | 410,56 | 410,56 | 410,56 | 410,56 | 4926,70 | 0,00 | |
| -410,56 | -410,56 | -410,56 | -410,56 | -410,56 | -410,56 | -410,56 | 61794,34 | 61794,34 | 61794,34 | 61794,34 | 741532,10 | 746458,80 | |
| 14830,64 | 14830,64 | 14830,64 | 14830,64 | 177967,70 | 179150,11 | ||||||||
| -410,56 | -410,56 | -410,56 | -410,56 | -410,56 | -410,56 | -410,56 | 46963,70 | 46963,70 | 46963,70 | 46963,70 | 563564,40 | 567308,69 | |
| -410,56 | -410,56 | -410,56 | -410,56 | -410,56 | -410,56 | -410,56 | 48230,47 | 48230,47 | 48230,47 | 48230,47 | 578765,60 | 582509,89 | |
| 28445,87 | |||||||||||||
| 8211,17 | |||||||||||||
| 8211,17 | |||||||||||||
| 76657,04 | 0,00 | 0,00 | 0,00 | 0,00 | 0,00 | 0,00 | 0,00 | 0,00 | 0,00 | 0,00 | 0,00 | 8211,17 | 0,00 |
| 99211,42 | 22143,82 | 22143,82 | 6143,82 | 611,82 | 22143,82 | 22143,82 | 15955,82 | 88230,47 | 88230,47 | 88230,47 | 88230,47 | 626976,76 | 622509,89 |
| 99211,42 | 121355,24 | 143499,06 | 149642,88 | 150254,70 | 172398,53 | 194542,35 | 210498,17 | 298728,64 | 386959,10 | 475189,57 | 563420,03 | 1190396,80 | 1812906,69 |
Таблица 5.13
Денежные потоки.
| Показатели | Месяцы | Годы | ||||||||||||
| 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 1 год | 2 год | |
| Инвестиционная деятельность | -17445,62 | -17445,62 | -17445,62 | -17445,62 | -54977,62 | -17445,62 | -17445,62 | -23633,62 | 0,00 | 0,00 | 0,00 | 0,00 | 0,00 | 0,00 |
| Операционная деятельность | 0,00 | -410,56 | -410,56 | -410,56 | -410,56 | -410,56 | -410,56 | -410,56 | 48230,47 | 48230,47 | 48230,47 | 48230,47 | 578709,60 | 582509,89 |
| Чистый денежный поток | -17445,62 | -17035,06 | -17035,06 | -17035,06 | -54567,06 | -17035,06 | -17035,06 | -23223,06 | 48230,47 | 48230,47 | 48230,47 | 48230,47 | 578709,60 | 582509,89 |
| Коэффициент дисконтинирования | 0,992 | 0,984 | 0,976 | 0,969 | 0,961 | 0,953 | 0,946 | 0,938 | 0,931 | 0,923 | 0,916 | 0,909 | 0,926 | 0,857 |
| Дисконтинированный денежный поток | -17306,06 | -16762,50 | -16632,67 | -16500,67 | -52435,80 | -16239,79 | -16110,91 | -21788,89 | 44892,80 | 44536,51 | 44183,04 | 43832,39 | 535885,09 | 499210,98 |
| NPV | -17306,06 | -34068,55 | -50701,23 | -67201,90 | -119637,70 | -135877,49 | -151988,39 | -173777,29 | -128884,49 | -84347,98 | -40164,93 | 3667,45 | 539552,54 | 1038763,52 |
| Дисконтированный доход | 0,00 | -403,99 | -400,86 | -397,68 | -394,52 | -391,39 | -388,29 | -385,21 | 44892,80 | 44536,51 | 44183,04 | 43832,39 | 535885,1 | 499210,98 |
| Капитальные вложения | -17306,06 | -17166,49 | -17033,54 | -16898,35 | -52830,32 | -16631,19 | -16499,19 | -22174,10 | 0,00 | 0,00 | 0,00 | 0 | 0 | 0 |
| SRR | -6,85 |
4.8 Показатели экономической эффективности проекта
Международная практика в процессе оценки проектов использует несколько обобщающих показателей. К таким показателям относятся:
интегральный экономический эффект;
индекс доходности;
внутренний коэффициент эффективности;
период возврата капитальных вложений и срок окупаемости.
Интегральныйэкономическийэффект (NPV – Net Present Value of Discounted Cash Flow).
NPV представляет собой чистую текущую стоимость проекта. Она определяется путем вычисления разности совокупного дохода за весь период функционирования проекта и всех видов расходов, суммированных за тот же период с учетом дисконтирования.
Результаты расчета NPV представлены в виде таблицы 5.13.
Годовую ставку дисконтирования возьмем равной:
.
Коэффициент дисконтирования за год равен:
.
В месяц коэффициент дисконтирования равен:
.
Итоговое значение NPV равно 1033239 рублей 63 копейки.
Индекс доходности.
Определяется как отношение суммарного дисконтированного дохода к суммарным дисконтированным капитальным вложениям:
.
Внутренний коэффициент эффективности.
Определяется как пороговое значение рентабельности, при котором NPV равно нулю
где r
1
– исходная ставка дисконтирования; r
2
– ставка дисконтирования, при которой NPV < 0; r
пор
– внутренний коэффициент эффективности проекта; NPVr
1
, NPVr
2
– NPV соответственно при r
1
и r
2
.
Подберем ставку дисконтирования, при которой NPV < 0: r
2
= 91,6%, NPVr
2
= -40164,93.
Тогда:
, значит проект считается эффективным.
Срок окупаемости и срок возврата вложений.
Определим срок окупаемости и срок возврата вложений сначала аналитическим способом:
,
где tx
– количество периодов, при которых NPV < 0; NPVt
– последнее отрицательное значение NPV; ДДП
t
+1
– величина ДДП в “t
+1
”-м периоде.
Графический способ. Финансовый профиль проекта представляет собой график изображения величины кумулятивной чистой текущей стоимости во времени.
На рисунке 1 представлен финансовый профиль данного проекта.
Рис 1 Финансовый профиль.
Выводы по главе
Проанализировав рассчитанные показатели эффективности проекта, можно сказать, что внедрение данного проекта является экономически эффективным. Об этом говорит:
срок окупаемости проекта – 1,8 года;
положительное сальдо реальных накопленных денег;
пороговое значение рентабельности больше ставки дисконтирования (0,84>0,08).
положительность интегрального экономического эффекта (NPV=1033239,63 руб >0);
индекс доходности больше 1 (SRR = 6,85 >1);
В результате применение данной разработки позволит компенсировать затраты на разработку и эксплуатацию, получить экономический эффект от использования данного комплекса.
В ходе вычислений были получены следующие результаты:
Была рассчитана смета затрат на разработку программного продукта, итоговая сумма которой равняется: 98438,09 руб.
Был рассчитан экономический эффект от внедрения программного продукта, который составил: 578765,60 рублей в год.
Глава
V
. Обоснование выбора
Delphi
Delphi - язык и среда программирования, относящаяся к классу RAD- (Rapid Application Development «Средство быстрой разработки приложений») средств CASE - технологии. Delphi обладает широким набором возможностей, начиная от проектировщика форм и кончая поддержкой всех форматов популярных баз данных.
Сравнение Delphi с другими подобными инструментами:
назначение и возможности Delphi (создаваемые ею программы могут работать не только под управлением Windows, а сама она относится к классу инструментальных средств ускоренной разработки программ (RapidApplicationDevelopment));
Инструмент ускоренной разработки программ (это ускорение достигается за счет двух характерных свойств: визуального конструирования форм и широкого использования библиотеки визуальных компонентов (VisualComponentLibrary));
Визуальное конструирование избавляет программиста от многих аспектов разработки интерфейса программы, так как Delphi автоматически готовит необходимые программные заготовки и соответствующий файл ресурсов;
Библиотека визуальных компонентов предоставляет программисту огромное разнообразие созданных разработчиками Delphi программных заготовок, которые готовы к работе в рамках вашей программы. Компоненты включают в себя программный код и все необходимые для его работы данные. Что избавляет программиста от рутинной работы. Использование компонентов не только во много раз уменьшает сроки разработки программ. Но и существенно снижает вероятность случайных программных ошибок;
Прогон и отладка программ (в любой момент вы можете узнать текущее значение переменной и при необходимости изменить его без перекомпиляции программы);
Мощность и гибкость языка программирования ObjectPaskal – безусловное достоинство Delphi, выгодно отличающее эту среду от других инструментов RAD. ObjectPaskal имеет самый быстрый среди продуктов подобного рода оптимизирующий компилятор, позволяющий создавать быстрые и относительно компактные программы;
Инструмент создания приложений баз данных. Delphi- самое эффективное средство разработки приложений баз данных. Это определяется тремя обстоятельствами: высокопроизводительной машиной доступа к данным разного формата, наличием многочисленных компонентов, ориентированных на эту сферу применения, и поставкой вместе с Delphi компактного, мощного и простого в администрировании сервера баз данных InterBase. Многочисленные компоненты, поддерживающие разработку приложений баз данных, обеспечивают обслуживание самых различных задач: выборку и сортировку данных. Их наглядное представление, изменение и публикацию данных в виде отчетов.
Выгоды от проектирования АРМ в среде Windows с помощью Delphi:
· Устраняется необходимость в повторном вводе данных;
· Обеспечивается согласованность проекта и его реализации;
· Увеличивается производительность разработки и переносимость программ.