Пример готовой дипломной работы по предмету: Программирование
Содержание
ВВЕДЕНИЕ
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. Ситуации и безопастность
Заключение
Список использованных источников
Выдержка из текста
Актуальность темы исследования.
Современный бизнес диктует все более и более жесткие требования к качеству создаваемого программного обеспечения (ПО).
Причем слово «качество» понимается как в прямом смысле (надежность, производительность, масштабируемость), так и в смысле продвинутой функциональности, расширяемости (силами пользователя или независимых сервисных фирм).
Создать отвечающий этим требованиям программный продукт на со-временном уровне — непростая задача. Под силу она, пожалуй, только большим корпорациям. Причем речь идет о корпорациях масштаба Microsoft или Oracle. Маленькие же фирмы, коими являются все без исклю-чения фирмы на белорусском рынке, не в состоянии обеспечить инфра-структуру для разработки столь мощного ПО.
Для обеспечения надежности и сокращения сроков разработок можно применять 4GL-языки, CASE и RAD-средства, а также отдельные продукты независимых поставщиков. Но такой подход решает только технические вопросы. Причем, выбирая средства разработки, мы связываем себя с конкретной технологией (например, с файл-серверной или с двухуровневой клиент-сервер).
Такой выбор на долгие годы связывает нас с выбранной когда-то технологией и порой, чтобы перейти на новую технологическую платформу, необходимо полностью переписать продукт. Если даже вы недавно выбрали самую новую технологию (например, многоуровневую технологию клиент-сервер), то можно с уверенностью сказать, что через несколько лет появится новая (лучшая технология) и вам (если, конечно, вы захотите на нее перейти) снова придется переписывать ваш продукт.
Но все эти проблемы меркнут перед тем, что относительно маленькой фирме просто физически не удастся полно и качественно (со всеми нюансами и тонкостями) реализовать все многообразие функций, встречающихся в мире бизнеса. Из-за этого разработчик начинает создавать или универсальную систему, охватывающую всю деятельность предприятия, но делающую это в расчете на «среднее» предприятие, или профессиональную и очень гибкую, но рассчитанную на автоматизацию узкой задачи программу. Похоже, проблемы обоих подходов понятны всем без объяснения.
Если в свое время бухгалтеры и финансисты четко представляли себе, какие задачи им нужно решить с помощью программных средств, то с интегрированными системами ситуация иная. Многие руководители просто не знают, что они хотят улучшить за счет автоматизации. По словам вице-президента компании «АйТи» по исследованиям и разработкам Александра Миронова, наблюдается «неосознанное понимание» потребности в автоматизации управления с «неосознанными» же пока задачами. Так, по данным корпорации «Парус», около половины потенциальных потребителей ПО руководствуется при выборе систем известностью торговой марки и только 16% — технологическими параметрами, то есть качеством системы.
Единственный способ деления рынка интегрированных систем управ-ления предприятием (АСУТП), который прочно закрепился в сознании как потенциальных клиентов, так и разработчиков, — это исторически сложив-шееся деление по месту производства. Все знают, что есть «очень дорогие» западные и более доступные отечественные системы. В результате допуска-ется сразу две ошибки. Во-первых, что касается цен, дешевизна отечествен-ных систем всего лишь миф, который развеивается по мере роста масштабов АСУТП или предприятия-заказчика. Во-вторых, при таком подходе почти невозможно сравнивать реальное качество систем.
Между тем единственное, что различает АСУТП, это именно качество, а оно зависит от двух параметров: задач, которые решает система, и соответствующих этим задачам и заложенных в систему управленческих функций. Белорусские разработчики привыкли козырять тем обстоятельством, что их программные продукты в отличие от западных соответствуют некоему «третьему пути», по которому развивается отечественный менеджмент. Выражается это якобы в меньшей жесткости, большей настраиваемости белорусских АСУТП на индивидуальный стиль конкретного руководителя или компании. И этим, по сути, подменяется идея классификации АСУТП по решаемым ими управленческим задачам.
Очевидно, что стандарт ERP, предусматривающий управление всеми ресурсами предприятия, включая иногда его партнеров и клиентов, с полным набором управленческих воздействий на процесс, применительно к отечественным разработкам вообще пока не обсуждается.
В ответ на упреки многие белорусские разработчики и консультанты утверждают, что к системам типа MRP II и ERP отечественный рынок просто не готов. По словам Александра Карпачева (корпорация «Парус»), «все внедряют финансовые системы и логистику, чтобы эффективно управлять тем, что в дефиците, — деньгами. А производственные мощности и рабочая сила пока не в дефиците, производство недогружено. Нет острой потребности в повышении его эффективности и, следовательно, в автоматизации». Сходную точку зрения высказал и вице-президент группы Aquarius Владимир Дрожжинов: «Программные продукты этого класса (ERP) рассчитаны на определенный уровень насыщения рынка. На Западе компании бьются за доли процентов. А если у нас все и так растет, и станки загружены на 50%, о каких сложных системах можно говорить?».
Белорусским разработчикам ПО разумнее было бы отказаться от конкуренции с мировыми лидерами в создании универсальных продуктов. То есть надо более четко обозначить свой круг интересов — по отраслям и масштабам бизнеса клиента.
Однако сейчас так поступает меньшинство из разработчиков. Скажем, компания «
1 С» заявляет, что работает только с малым бизнесом, а «Парус» — со средним. Что касается отраслевой специализации, то среди клиентов одного и того же производителя ПО можно встретить обычно нефтегазовые, энергетические, строительные, машиностроительные, пищевые, фармацевтические, торговые предприятия, а также государственные и образовательные учреждения. Отсутствие опыта и специалистов-предметников приводит к тому, что создаются некие недифференцированные, максимально обобщенные шаблоны, под которые предлагается «подогнать» реальное производство. Тогда как оно делится на дискретное и непрерывное, единичное, серийное и массовое, а эти типы — на еще более мелкие и т. д. Сузив границы специализации, разработчики могли бы направить освободившиеся ресурсы на достижение необходимого на сегодняшний день качества продукта и сосредоточиться на полноте решаемых системой управленческих задач и интегрированности управленческих функций. В этом случае они могли бы составить конкуренцию зарубежным коллегам из среднего сегмента.
Структура и объем дипломной работы:
Пояснительная записка содержит 62 страницы, включая 8 рисунков, 3 таблицы,
1. литературных источников.
Работа состоит из введения, 5 разделов, заключения.
Во введении отражена актуальность задачи и описаны основные требования к проекту.
В первом разделе проведен обзор средств автоматизации торговли.
Во втором разделе приводится обзор текущего состояния Интернет –торговли и роли в них аукционов.
Третий раздел посвящен описанию процесса проектирования автоматизированной системы.
В четвертом разделе проведен расчет экономической эффективности от внедрения программного продукта .
Пятый раздел посвящен вопросам охраны труда работников, занятых решением задач по составлению программ.
Заключение включает основные выводы по работе.
Список использованной литературы
1. Буч, Г. Язык UML. Руководство пользователя / Дж. Рамбо, А. Джекоб-сон. — М.: ДМК, 2000. — 432с.
2) Информационные технологии в процессе проектирования систем : Мате-риалы научно-методического семинара. — Тюмень: Издательство Тюменского государственного университета, 2002. — 188 с.
3) Чейз, Н. Java 5 на примерах / Н. Чейз.
4) Рассел Джонс, Java
5. полное руководство / А. Рассел Джонс. — М: ВЕК+, 2000. — 704 с.
5) Коналлен, Дж. Разработка Web приложений с использованием UML : Пер. с англ. / Дж. Коналлен. — М.: Издательский дом “Вильямс”, 2001. — 288 с.
6) Браун, М. Spring в подлиннике / М. Браун, Д. Ханикатт. — СПб.: BHV Санкт-Петербург, 1998.
7) Java
2. Руководство разработчика : Пер. с англ. : Уч. пос. — М: Издательский дом “Вильямс”, 2000. — 720с.
8) Сибаров, Ю. Г. Охрана труда в вычислительных центрах / Ю. Г. Сибаров, Н. Н. Сколотнев и др. — М.: Машиностроение, 1990.
9) Гигиенические требования к ВДТ, ЭВМ и организации работы. СанПиН № 9-131 РБ 2000.
10) Общие санитарно-гигиенические требования к воздуху рабочей зоны. ГОСТ 12.1.005-88.
11) Гигиенические требования к микроклимату производственных помещений. СанПиН № 9-80 РБ 98.
12) Отопление, вентиляция и кондиционирование воздуха. СНБ 4.02.01-03.
13) Шум на рабочих местах, в помещениях жилых, общественных зданий и на территории жилой застройки. СанПиН 2.2.4/2.1.8.10-32-2002.
14) Электробезопасность, защитное заземление, зануление. ГОСТ 12.1.030-81.
15) Противопожарные нормы. СанПиН 2.01.02-85.
16) Пожарно-техническая классификация классификация зданий, строи-тельных конструкций и материалов. СНБ 2.02.01-98.
