МИНИСТЕРСТВО ОБРАЗОВАНИЯ РЕСПУБЛИКИ БЕЛАРУСЬ
Учреждение образования «БЕЛОРУССКИЙ ГОСУДАРСТВЕННЫЙ ТЕХНОЛОГИЧЕСКИЙ УНИВЕРСИТЕТ»
Факультет Издательского дела и полиграфии
Кафедра Информационные системы и технологии
Специальность Информационные системы и технологии (издательско-полиграфический комплекс)
ПОЯСНИТЕЛЬНАЯ ЗАПИСКА
к дипломному проекту на тему:
«Разработка автоматизированной системы управления торговым предприятием»
Дипломник ______________________________________.
Руководитель проекта ____________________________.
Заведующий кафедрой ____________________________.
Консультанты ___________________________________.
___________________________________
Нормоконтролеры: _______________________________.
Дипломный проект защищен с оценкой _________________________
Председатель ГЭК _______________________________
МИНСК 2008
ВВЕДЕНИЕ
1. Автоматизированные системы управления предприятием
1.1. Компьютерные системы управления предприятием
1.2. Три уровня эффектов от ИТ-проектов
1.3. Принципы классификации систем управления
1.4. Стоимость проекта АСУТП
1.5. Внедрение системы автоматизации, основные проблемы и задачи
2. Торговое предприятие во всемирной компьютерной сети
2.1. Электронная коммерция
2.2. Интернет-аукционы
3. Проектирование и реализация АСУТП
3.1. Язык программирование Java
3.2. Концепция Business Engine
3.3. Общее представление АСУТП
3.4. Основные технические решения.
3.5. Структура системы
3.6. Взаимосвязь со смежными системами.
3.7. Подсистемы
3.8. Проектирование. Построение диаграмм39
4. Экономический раздел
4.1. Описание задачи
4.2. Расчет времени на создание программного продукта
4.3. Расчет заработной платы исполнителя работ
4.4. Расчет начислений на заработную плату
4.5. Расчет себестоимости 1-го машино-часа работы ПЭВМ
4.6. Расчет расходов на содержание и эксплуатацию ПЭВМ
4.7. Расчет себестоимости программного продукта
4.8. Расчет цены программного продукта
5. Охрана труда
5.1. Мероприятия по охране труда
5.2. Производственная санитария
5.3. Мероприятия и факторы
5.4. Ситуации и безопастность
Заключение
Список использованных источников
Пояснительная записка содержит 62 страницы, включая 8 рисунков, 3 таблицы, 16 литературных источников.
АВТОМАТИЗИРОВАННАЯ СИСТЕМА УПРАВЛЕНИЯ ТОРГОВЫМ ПРЕДПРИЯТИЕМ, КОНТРАГЕНТ, АУКЦИОН, ПЛАТЕЖНАЯ СИСТЕМА
Работа состоит из введения, 5 разделов, заключения.
Во введении отражена актуальность задачи и описаны основные требования к проекту.
В первом разделе проведен обзор средств автоматизации торговли.
Во втором разделе приводится обзор текущего состояния Интернет –торговли и роли в них аукционов.
Третий раздел посвящен описанию процесса проектирования автоматизированной системы.
В четвертом разделе проведен расчет экономической эффективности от внедрения программного продукта .
Пятый раздел посвящен вопросам охраны труда работников, занятых решением задач по составлению программ.
Заключение включает основные выводы по работе.
Введение
Современный бизнес диктует все более и более жесткие требования к качеству создаваемого программного обеспечения (ПО). Причем слово «качество» понимается как в прямом смысле (надежность, производительность, масштабируемость), так и в смысле продвинутой функциональности, расширяемости (силами пользователя или независимых сервисных фирм).
Создать отвечающий этим требованиям программный продукт на современном уровне — непростая задача. Под силу она, пожалуй, только большим корпорациям. Причем речь идет о корпорациях масштаба Microsoft или Oracle. Маленькие же фирмы, коими являются все без исключения фирмы на белорусском рынке, не в состоянии обеспечить инфраструктуру для разработки столь мощного ПО.
Для обеспечения надежности и сокращения сроков разработок можно применять 4GL-языки, CASE и RAD-средства, а также отдельные продукты независимых поставщиков. Но такой подход решает только технические вопросы. Причем, выбирая средства разработки, мы связываем себя с конкретной технологией (например, с файл-серверной или с двухуровневой клиент-сервер). Такой выбор на долгие годы связывает нас с выбранной когда-то технологией и порой, чтобы перейти на новую технологическую платформу, необходимо полностью переписать продукт. Если даже вы недавно выбрали самую новую технологию (например, многоуровневую технологию клиент-сервер), то можно с уверенностью сказать, что через несколько лет появится новая (лучшая технология) и вам (если, конечно, вы захотите на нее перейти) снова придется переписывать ваш продукт.
Но все эти проблемы меркнут перед тем, что относительно маленькой фирме просто физически не удастся полно и качественно (со всеми нюансами и тонкостями) реализовать все многообразие функций, встречающихся в мире бизнеса. Из-за этого разработчик начинает создавать или универсальную систему, охватывающую всю деятельность предприятия, но делающую это в расчете на «среднее» предприятие, или профессиональную и очень гибкую, но рассчитанную на автоматизацию узкой задачи программу. Похоже, проблемы обоих подходов понятны всем без объяснения.
Если в свое время бухгалтеры и финансисты четко представляли себе, какие задачи им нужно решить с помощью программных средств, то с интегрированными системами ситуация иная. Многие руководители просто не знают, что они хотят улучшить за счет автоматизации. По словам вице-президента компании «АйТи» по исследованиям и разработкам Александра Миронова, наблюдается «неосознанное понимание» потребности в автоматизации управления с «неосознанными» же пока задачами. Так, по данным корпорации «Парус», около половины потенциальных потребителей ПО руководствуется при выборе систем известностью торговой марки и только 16% — технологическими параметрами, то есть качеством системы.
Единственный способ деления рынка интегрированных систем управления предприятием (АСУТП), который прочно закрепился в сознании как потенциальных клиентов, так и разработчиков, — это исторически сложившееся деление по месту производства. Все знают, что есть «очень дорогие» западные и более доступные отечественные системы. В результате допускается сразу две ошибки. Во-первых, что касается цен, дешевизна отечественных систем всего лишь миф, который развеивается по мере роста масштабов АСУТП или предприятия-заказчика. Во-вторых, при таком подходе почти невозможно сравнивать реальное качество систем.
Между тем единственное, что различает АСУТП, это именно качество, а оно зависит от двух параметров: задач, которые решает система, и соответствующих этим задачам и заложенных в систему управленческих функций. Белорусские разработчики привыкли козырять тем обстоятельством, что их программные продукты в отличие от западных соответствуют некоему «третьему пути», по которому развивается отечественный менеджмент. Выражается это якобы в меньшей жесткости, большей настраиваемости белорусских АСУТП на индивидуальный стиль конкретного руководителя или компании. И этим, по сути, подменяется идея классификации АСУТП по решаемым ими управленческим задачам.
Очевидно, что стандарт ERP, предусматривающий управление всеми ресурсами предприятия, включая иногда его партнеров и клиентов, с полным набором управленческих воздействий на процесс, применительно к отечественным разработкам вообще пока не обсуждается.
В ответ на упреки многие белорусские разработчики и консультанты утверждают, что к системам типа MRP II и ERP отечественный рынок просто не готов. По словам Александра Карпачева (корпорация «Парус»), «все внедряют финансовые системы и логистику, чтобы эффективно управлять тем, что в дефиците, — деньгами. А производственные мощности и рабочая сила пока не в дефиците, производство недогружено. Нет острой потребности в повышении его эффективности и, следовательно, в автоматизации». Сходную точку зрения высказал и вице-президент группы Aquarius Владимир Дрожжинов: «Программные продукты этого класса (ERP) рассчитаны на определенный уровень насыщения рынка. На Западе компании бьются за доли процентов. А если у нас все и так растет, и станки загружены на 50%, о каких сложных системах можно говорить?».
Белорусским разработчикам ПО разумнее было бы отказаться от конкуренции с мировыми лидерами в создании универсальных продуктов. То есть надо более четко обозначить свой круг интересов — по отраслям и масштабам бизнеса клиента.
Однако сейчас так поступает меньшинство из разработчиков. Скажем, компания «1С» заявляет, что работает только с малым бизнесом, а «Парус» — со средним. Что касается отраслевой специализации, то среди клиентов одного и того же производителя ПО можно встретить обычно нефтегазовые, энергетические, строительные, машиностроительные, пищевые, фармацевтические, торговые предприятия, а также государственные и образовательные учреждения. Отсутствие опыта и специалистов-предметников приводит к тому, что создаются некие недифференцированные, максимально обобщенные шаблоны, под которые предлагается «подогнать» реальное производство. Тогда как оно делится на дискретное и непрерывное, единичное, серийное и массовое, а эти типы — на еще более мелкие и т. д. Сузив границы специализации, разработчики могли бы направить освободившиеся ресурсы на достижение необходимого на сегодняшний день качества продукта и сосредоточиться на полноте решаемых системой управленческих задач и интегрированности управленческих функций. В этом случае они могли бы составить конкуренцию зарубежным коллегам из среднего сегмента.