При выполнении запроса к базе данных, расположенной на файловом сервере, в действительности происходит запрос к локальной копии данных на компьютере пользователя. Поэтому перед выполнением запроса данные в локальной копии обновляются из реальной БД. Данные обновляются в полном объеме. Так, если таблица БД состоит из 1000 записей, а для выполнения запроса (например, выдать сумму премий за октябрь в отделе Y) реально нужно 10 записей, все равно перегоняются все 1000 записей. Таким образом, не нужно иметь слишком много пользователей и запросов от них, чтобы серьезно ''забить" сеть, что, конечно же, не может не сказаться на ее быстродействии.

Обеспечение целостности БД производится из приложений. Это потенциальный источник ошибок, нарушающих физическую и логическую целостность БД, поскольку различные приложения могут производить контроль целостности БД по-разному, взаимоисключающими способами, или не проводить такого контроля вовсе. Намного эффективнее управлять БД из единого места и по единым законам, нежели из разных приложений и по потенциально разным законам (все зависит от того, как написано приложение). Поэтому безопасность при работе в архитектуре "файл-сервер" невысока и всегда присутствует элемент неопределенности. Секретность и конфиденциальность при работе с БД в архитектуре "файл-сервер" обеспечить также тяжело - любой, кто имеет доступ в каталог сетевого сервера, где хранится БД, может изменять таблицы БД любым образом, копировать их, заменять и т.д. [4].

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

Приложение-клиент формирует запрос к серверу, на котором расположена БД, на структурном языке запросов SQL. Удаленный сервер принимает запрос и переадресует его SQL-серверу БД. SQL-сервер - это специальная программа, управляющая удаленной базой данных. SQL-сервер обеспечивает интерпретацию запроса, его выполнение в базе данных, формирование результата выполнения запроса и выдачу его приложению-клиенту. При этом ресурсы клиентского компьютера не участвуют в физическом выполнении запроса; клиентский компьютер лишь отсылает запрос к серверной БД и получает результат, после чего интерпретирует его необходимым образом и представляет пользователю. Так как клиентскому приложению посылается результат выполнения запроса, по сети "путешествуют" только те данные, которые необходимы клиенту. В итоге снижается нагрузка на сеть. Поскольку выполнение запроса происходит там же, где хранятся данные (на сервере), нет необходимости в пересылке больших пакетов данных. Кроме того, SQL-сервер, если это возможно, оптимизирует полученный запрос таким образом, чтобы он был выполнен в минимальное время с наименьшими накладными расходами.

Все это повышает быстродействие системы и снижает время ожидания результата запроса.

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

1. посылка к серверу запросов;

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

3. реализация интерфейса пользователя.

SQL-сервер - это программа, расположенная на компьютере сетевого сервера. SQL-сервер должен быть загружен на момент принятия запроса от клиента. Функциями сервера БД являются:

1. прием запросов от приложений-клиентов, интерпретация запросов, выполнение запросов в БД, отправка результата выполнения запроса приложению-клиенту;

2. управление целостностью БД, обеспечение системы безопасности, блокировка неверных действий приложений-клиентов;

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

4. обеспечение одновременно безопасной и отказоустойчивой многопользовательской работы с одними и теми же данными. В архитектуре "клиент-сервер" используются так называемые "удаленные" (или "промышленные") СУБД. Промышленными они называются из-за того. что именно СУБД этого класса могут обеспечить работу информационных систем масштаба среднего и крупного предприятия, организации, банка. Локальные СУБД предназначены для однопользовательской работы или для обеспечения работы информационных систем, рассчитанных на небольшие группы пользователей.[4, 15, 11].

К разрядку промышленных СУБД принадлежат: Oracle, Gupta, Informix, Sybase, MS SQL Server, DB2, InterBase и ряд других.

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

Кроме этого, существует отдельная категория сотрудников, называемых администраторами баз данных. Как правило, это администраторы сервера, разработчики БД или пользователи, имеющие привилегии на создание, изменение, настройку оптимальных параметров отдельных серверных БД. Администраторы БД также отвечают за предоставление прав на разноуровневый доступ к сопровождаемым ими БД для других пользователей.[4, 15, 11].

Использование архитектуры "клиент-сервер":

1. резко уменьшает сетевой трафик:

2. понижает сложность приложений-клиентов (поскольку тем уже нет необходимости обеспечивать целостность и безопасность БД и следить за параметрами многопользовательской работы с БД);

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

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

2.4 Краткое описание выбранной среды разработки

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

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

В основе такой общепризнанной популярности лежит тот факт, что Delphi, как никакая другая система программирования, удовлетворяет изложенным выше требованиям. Действительно, приложения с помощью Delphi разрабатываются быстро, причем взаимодействие разработчика с интерактивной средой Delphi не вызывает внутреннего отторжения, а наоборот, оставляет ощущение комфорта. Delphi-приложения эффективны, если разработчик соблюдает определенные правила (и часто - если не соблюдает). Эти приложения надежны и при эксплуатации обладают предсказуемым поведением.[4, 22].

Пакет Delphi - продолжение линии компиляторов языка Pascal корпорации Borland. Pascal как язык очень прост, а строгий контроль типов данных способствует раннему обнаружению ошибок и позволяет быстро создавать надежные и эффективные программы. Корпорация Borland постоянно обогащала язык. Когда-то в версию 4.0 были включены средства раздельной трансляции, позже, начиная с версии 5.5, появились объекты, а в состав шестой версии пакета вошла полноценная библиотека классов Turbo Vision, реализующая оконную систему в текстовом режиме работы видеоадаптера. Это был один из первых продуктов, содержавших интегрированную среду разработки программ.

Среда программирования напоминает пакет Visual Basic. В вашем распоряжении несколько отдельных окон: меню и инструментальные панели, Object Inspector (в котором можно видеть свойства объекта и связанные с ним события), окна визуального построителя интерфейсов (Visual User Interface Builder), Object Browser (позволяющее изучать иерархию классов и просматривать списки их полей, методов и свойств), окна управления проектом (Project Manager) и редактор.

Delphi содержит полноценный текстовый редактор типа Brief, назначения клавиш в котором соответствуют принятым в Windows стандартам, а глубина иерархии операций Undo неограниченна. Как это стало уже обязательным, реализовано цветовое выделение различных лексических элементов программы. Процесс построения приложения достаточно прост. Нужно выбрать форму (в понятие формы входят обычные, диалоговые, родительские и дочерние окна MDI), задать ее свойства и включить в нее необходимые компоненты (видимые и, если понадобится, неотображаемые): меню, инструментальные панели, строку состояния и т. п., задать их свойства и далее написать (с помощью редактора исходного кода) обработчики событий. Object Browser Окна типа Object Browser стали неотъемлемой частью систем программирования на объектно-ориентированных языках. Работа с ними становится возможной сразу после того, как вы скомпилировали приложение.

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

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

Visual Component Library (VCL) Богатство палитры объектов для построения пользовательского интерфейса - один из ключевых факторов при выборе инструмента визуального программирования. При этом для пользователя имеет значение как число элементов, включенных непосредственно в среду, так и доступность элементов соответствующего формата на рынке. [4, 22].

2.5 Проектирование структуры базы данных

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

Существует два способа организации информационных массивов:

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

В наше время при создании АСУ требуется качественно новый подход к организации данных. К организации данных в АСУ предъявляют два основных требования:

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

- Максимальная возможная независимость от прикладных программ.

Выполнение этих требований привело к созданию единой (для всех задач системы) базы данных БД. Преимущества БД в АСУ состоят в следующем:

а) Централизованное управление всеми ресурсами, синхронная поддержка данных для всех приложений.

б) Отсутствие проблемы избыточности данных вследствие их интеграции.

в) Однократный ввод и многократное использование данных благодаря устранению дублирования.

г) Унификация средств организации данных и независимость прикладных программ от организации данных. Исходя из приведенных доводов, была выбрана организация базы данных.

2.5.1 Структура БД

При проектировании БД необходимо решить вопрос о наиболее эффективной структуре данных. Основные цели, которые при этом преследуются:

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

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

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

Главная задача данной работы заключается в необходимости автоматизации производственных цехов, а также возможность предоставления оперативной информации по установкам, за определенный период или за конкретные дни для hуководства. Для её решения была разработана АИС, в состав которой входят пока девять таблиц (файлов, имеющих расширение dbf).

Таблица 2.1 - Структура таблицы "Переработка, выработка"(Per_Vur.dbf)

Индекс: P_V.NTX по DTOS (DATA_V) + STR(KOD_USTN, 3)

В данной таблице хранятся данные, переработки и выработки по всем установкам и видам продукции.

Таблица 2.2 - Структура таблицы "Отгрузка, сжег"(Otg_Sjog.dbf)

Индекс: O_S.NTX по DTOS (DATA_V) + STR(KOD_USTN, 3)

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

Таблица 2.3 - Структура таблицы "Расход топлива"(RAS_TOP.dbf)

Индекс: R_T.NTX по DTOS (DATA_V) + STR(KOD_USTN, 3)

Интерес представляют данные о расходе сырья по каждой установке.

Таблица 2.4 - Структура таблицы "Потери при переработке"(Роt_Per.dbf)

Индекс: P_P.NTX по DTOS (DATA_V) + STR(KOD_USTN, 3)

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

Таблица 2.5 - Структура таблицы "Расход реагентов"(RAS_Reag.dbf)

Индекс: R_R.NTX по DTOS (DATA_V) + STR(KOD_USTN, 3)

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

Таблица 2.6 - Структура таблицы "Тип движения"(DV_RAS.dbf)

Индекс: Т_D.NTX по KOD_DV

В данной таблице находятся данные по типу движения на всех установках.

Таблица 2.7 - Структура таблицы "Тип расхода"(Typ_R.dbf)

Индекс: T_R.NTX по KOD_RAS

В этой таблице находятся данные по типу расхода на всех установках.

Таблица 2.8 - Структура таблицы "Справочник установок"(SРR USTN.dbf)

Индексы:

SPR_UST1.NTX по KOD_USTN

SPR_UST2.NTX по STR(KOD_PODR,2,0)+STR(KOD_USTN,3,0)

SPR_UST3.NTX по NAME_USTN

SPR_ UST4.NTX по KOD_ZATR

Данные по установкам находятся в этой таблице.

Таблица 2.9 - Структура таблицы "Справочник марок продукции"(РR M.dbf)

Индексы:

PR_M1 .NTX по KOD_PRОD

PR_M2.NTX по NAME_PROD

PR_ M3.NTX по К_VID+K_SEM+KOD_PROD

• Данные о свойствах и показателей продукта находятся в этой таблице.
• Рисунок 2.3 - Структура взаимосвязи таблиц
• 3 Реализация разработки
• 3.1 Интерфейс программы
• Программа разрабатывалась в среде Borland DELPHI 9.0 компании Inprise Corporation. Выбор данной среды обусловлен следующими причинами:

1. Данная среда является ведущей RAD-системой (средой быстрой разработки приложений) на рынке благодаря следующим особенностям:

1.1. Визуальная среда разработки.

1.2. Полное использование возможностей среды WIN32.

1.3. Гибкость языка Object Pascal.

2. Наибольший опыт разработчика работы именно в этой среде.

3. Пожелание заказчика (в перспективе возможна доработка этого приложения силами других разработчиков).

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

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

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

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

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

Приложение состоит из одной или нескольких форм.

Каждая форма может:

1. Хранить и использовать свои "собственные " не визуальные компоненты;

2. Использовать не визуальные компоненты, хранящиеся в одном или нескольких модулях данных;

3. Использовать не визуальные компоненты, хранящиеся и используемые в других формах.

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

3.2 Экранные формы и модули АИС

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

В данной программе есть несколько экранных форм, список которых с кратким описанием приведен ниже.

* frMainForm - основная форма программы. Содержит основное меню. Вызывает другие окна.

* frAddPerVir - форма ввода параметров по переработке и выработке.

* frAddOtgCjog - форма ввода параметров по отгрузке.

* frAddRasTop- форма ввода параметров по расходу топлива.

* frReport - отчёт по переработке и выработке.

Структура взаимодействия окон приведена на рисунок 3.1.

Рисунок 3.1 - Структура приложения

При запуске программы открывается главная форма рисунок 3.2.

Рисунок 3.2 - Основное окно программы.

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

• * Информация по цехам
• 1. Переработка и выработка по установкам
• 2. Отгрузка, сжег
• 3. Расход энергии
• 4. Потери при переработке
• 5. Расход сырья
• * Информация по ТЭЦ
• 1. Расход топлива на ТЭЦ
• * Сводки и отчёты

1. Деятельность установок

2. Сводка по расходу топлива

3. Отчёт о расходе материалов

4. Справка о выходах н/п

5. Расчёт потерь

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

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

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

Вот пример запроса для отображения данных о переработке и выработке по установкам:

• SELECT Per_vur.DATA_V, Dv_ras.TYPE_DV, Spr_ustn.NCUT_USTN,
• Pr_m.NAME_PROD, Per_vur.KOLVO, Per_vur.KOD_DV,

Per_vur.KOD_USTN, Per_vur.KOD_PROD

FROM "..\word\Per_Vur.DBF" Per_vur

INNER JOIN "..\word\Dv_Ras.DBF" Dv_ras

ON (Per_vur.KOD_DV=Dv_ras.KOD_DV)

INNER JOIN "..\word\Spr_ustn.DBF" Spr_ustn

ON (Per_vur.KOD_USTN = Spr_ustn.KOD_USTN)

INNER JOIN "..\word\Pr_m.DBF" Pr_m

ON (Per_vur.KOD_PROD = Pr_m.KOD_PROD)

где SELECT, FROM, WHERE, INNER JOIN - операторы языка SQL;

Per__Vur.DBF, Dv_Ras.DBF, Spr_ustn.DBF, Pr_m.DBF - название таблиц;

DAТA_V, TYPE_DV, NCUT_USTN - название полей соответствующих таблиц.

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

Предложение FROM, задает имена таблиц к которым делается запрос.

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

Еще на главной форме существуют кнопки управления:

Добавить - Для добавления новой записи в соответствующую таблицу

Удалить - Для удаления выбранной записи из таблицы

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

Выход - Закрытие приложения

При нажатии на кнопку "Добавить" открывается следующая форма рисунок 3.3.

Здесь мы можем установить необходимые нам значения для новой записи. Данные для выпадающих списков формируются из существующих таблиц (справочников). В данном, конкретном случае из таблицы "Установки", "Продукция" и "Тип движения".

Рисунок 3.3. Окно ввода новой записи

Вот фрагмент кода отображающий в выпадающем списке записи справочника "Тип движения":

Table1. Active :=true;

with Table1 do

begin

ComboBox1.Items.Clear;

first;

while not EOF do

begin

СomboBox1.Items.Add(FieldByName('TYPE_DV').AsString);

Next;

end;

first;

ComboBox1.Text:=FieldByName('TYPE_DV').AsString;

end;

При нажатии кнопки "Ввод" в таблице создаётся новая запись. Соответственно "Отмена" - означает не производить изменения в таблице. При нажатии на кнопку "Удалить", из таблицы удаляется соответствующая запись.

Рисунок 3.4 - Фильтр

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

Чтобы устранить эти трудности необходимо нажать на кнопку "Фильтр" рисунок 3.4.

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

Рисунок 3.5 - Работа фильтра

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

Выбрав пункт меню "Сводки и отчёты" мы можем создать отчет по данным соответствующих таблиц.

Отчет создается с помощью элемента QuickReport. Когда приложение запущено и выбран, к примеру, пункт "Отчёт о деятельности предприятия", отчёт будет выглядеть так рисунок 3.6.

Рисунок 3.6 - Отчёт

4 Оценка экономической эффективности проекта

4.1 Стоимость программного продукта

4.1.1 Затраты на создание программного продукта

Стоимость выполнения каждой работы создания ПП определяется как сумма заработной платы работников и накладных (косвенных) расходов по формуле:

Ср = sum ( Зr + Нr ) ,4.1

r - R

где Зr - заработная плата и отчисления на социальное страхование при выполнении r-той работы;

Нr - величина накладных расходов, связанных с выполнением r-той работы;

R - множество выполняемых работ.

Величина заработной платы на выполнение r-той работы равна:

Зr = Зоr + Здr + Зсr , 4.2

Зоr = Тr * Счr * ( 1 + Кпr ) ,4.3

Здr = Кд * Зоr ,4.4

Зсr = Кс * ( Зоr + Здr ) ,4.5

где Зоr - основная заработная плата на выполнение r-той работы;

Тr - трудоемкость работы в нормочасах;

Счr - средняя часовая тарифная ставка выполнения работы;

Кпr - коэффициент премий и доплат;

Здr - дополнительная заработная плата;

Кд - коэффициент дополнительной заработной платы;

Зсr - отчисления на соц. страхование;

Кс - коэффициент отчислений на соц. страхование.

Величина накладных расходов связанных с выполнением r-той работы, определяется по формуле:

Нr = ( Зr*Кнr )/100 ,4.6

где Кнr - процент накладных расходов.

4.1.2 Цена программного продукта

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

Цр = Спп*(1+Кр)*(1+Пт/100)/Рпп ,4.7

где Спп - себестоимость создания программного продукта;

Кр - коэффициент рентабельности разработки;

Кт - процент торговой наценке к оптовой цене;

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

Затраты на создание программного продукта, то есть его себестоимость, составляют 17 643 руб. Коэффициент рентабельности, определяющий прибыль от реализации программного продукта, принятом равным 0,2. Ожидается, что в текущем году будет продано три экземпляра программного продукта с торговой наценкой 70 %.

В этом случае розничная цена программного продукта устанавливается равной:

Цр = 17643*(1+0,2)*(1+70/100)/3 = 11 997 руб.

4.2 Оценка ожидаемого экономического эффекта

4.2.1 Выбор метода расчета

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

Годовой экономический эффект определяется по формуле:

Эг = [( Тб + Ен * Кб ) - ( Тв + Ен * Кв )]*B ,4.8

где Тб,Тв - годовые текущие затраты в базовом и внедряемом вариантах;

Кб,Кв - капитальные вложения в базовом и внедряемом вариантах;

Ен - нормативный коэффициент эффективности капитальных вложений, равный 0.3;

B - число единиц ПП, внедрённого в текущем году.

Срок окупаемости затрат в годах определяется по формуле:

Ток = ( Кв - Кб ) / Эг ,4.9

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

4.2.2 Сведения о базовом и внедряемом вариантах

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

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

4.2.3 Капитальные затраты

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

Капитальные затраты в базовом варианте определяются стоимостью 2-х шкафов, приобретаемых по цене 1200 руб. каждый и 100 папок, предназначенных для хранения документов, стоимостью по 24 руб. каждая. Суммарная их стоимость составляет:

Кб = 1200 * 2 + 24 * 100 = 4800 руб.

Капитальные затраты во внедряемом варианте определяются стоимостью программного продукта, 11 997 руб. и 50% стоимости и установки компьютера, которые приняты равными 9000 руб.

Кв = 11997 + 9000 = 20 997 руб.

4.2.4 Текущие затраты

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

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

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

В базовом варианте занято 2 человека с основной зарплатой в 1000 рублей каждый. Их годовая заработная плата равна:

Зоб = 2 * 1000 * 12 = 24 000 руб.

Зсб = 0.37 * Зоб = 8 880 руб.

Зб = 24000 + 8880 = 32 880 руб.

Накладные расходы приняты равными 70 % заработной платы:

Нб = 32880 * 0.7 = 23 020 руб.

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

Тб = 32880 + 23020 = 55 900 руб.

Во внедряемом варианте занят 1 человек с зарплатой в 1600 руб. выполняет работу с использованием программного продукта за 50 % времени. Его годовая заработная плата за аналогичную работу равна:

Зов = 1 * 1600 * 12 * 0.5 = 9 600 руб.

Звс = 0.37 * 9600 = 3 550 руб.

Зв = 9600 + 3550 = 13 150 руб.

Накладные расходы приняты равными 180 % заработной платы:

Нв = 13150 * 1.8 = 23 670 руб.

Текущие расходы во внедряемом варианте составляют:

Тв = 13150 + 23670 = 36 820 руб.

4.2.5 Расчет экономического эффекта

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

Эг =(55900 + 0.3*4800) - (36820 + 0.3*20997) = 14 220 руб.

Срок окупаемости произведенных затрат равен:

Ток = (20997 - 4800)/14220 = 1.1 года

Выводы

1. Планом создания программного продукта предусмотрено проведение 30 работ, последовательность выполнения которых устанавливается сетевым графиком. Согласно разработанной методике, определена трудоемкость выполнения каждой работы. Общая трудоемкость выполнения проекта составляет 740 нормо-часов. При выбранной структуре сетевого графика расчет и оптимизация на ЭВМ его параметров позволили определить сроки выполнения каждой работы и минимальное потребное количество ее исполнителей. Установлено, что при заданном сроке выполнения всех работ, равном 60 дням, средняя потребность в исполнителях составит 1.54.

2. Затраты на создание программного продукта, то есть его себестоимость, составляет 17 643 руб. Розничная цена программного продукта установлена в 11 997 руб. Ожидается, что в текущем году разработанным программным продуктом воспользуются три потребителя.

3. Уменьшение трудоемкости и числа работников дает возможность получить годовой экономический эффект при использования программного продукта каждым потребителем 14 220 руб. Срок окупаемости дополнительных капитальных затрат потребителя равен 1,1 года.

Заключение

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

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

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

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

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

Разработанная система позволяет:

Производить ввод и редактирование товаров поступающих на склад; показывать товары по категориям;

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

Добавлять и изменять сведения о товарах.

Добавлять и изменять типы товаров

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

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

Печатать сведения о товарах с группировкой по первой букве названия товара.

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

Отображать квартальные обороты заказов каждого товара и полный итог за исследуемый год с условием отбора по клиенту;

Печатать сведения об объемах продаж в убывающем порядке с целью определения наиболее крупных заказов;

Печатать квартальные итоги по сумме продаж в отчете; с возможностью просмотра информации о записи. (предусмотреть форму для запроса периода отчета);

Выводить отчет продаж за исследуемый период по типам. (в подчиненном отчете выводить цифры, а в главном диаграмму);

Предоставить таблицу и график в виде гистограммы о продажах товаров в каждом квартале отчетного года;

автоматизированный учет готовая продукция delphi

Литература

Дж. Тельман, "Основы систем баз данных" [Текст] / Дж. Тельман Москва.:Финансы и статистика, 2003г.-324с.

Дейт К., "Введение в системы баз данных" [Текст] / Дейт К Москва.: Hаука, 2000 г.-225с.

Когловский М.Р., "Технология баз данных на персональных ЭВМ" [Текст] / Когловский М.Р Москва.: 'Финансы и статистика', 2002 г.-324с.

Шумаков П. В., "Delphi 3.0 и создание баз данных" [Текст] / Шумаков П. В Москва 2007г.-506с

Джон Матчо, Дэвид Р.Фолкнер. «Delphi» [Текст] / Джон Матчо -- пер. с англ. -- М.:Бином, 2005г.-461с.

A.M.Епанешников. Епанешников В.А., "Программирование в среде Delphi 2.0" [Текст] / A.M.Епанешников ,М.: Диалог-Мифи, 2007г.-235с.

Дж. Мартин., "Организация баз данных в вычислительных системах" [Текст] / Дж. Мартин ,М: Мир 2008г.-364с.

С.М.Диго, "Проектирование и использования баз данных" [Текст] / С.М.Диго, Москва: Финансы и статистика 2005.-234с.

Горев А.Б, Ахаян Р.С, Макашарипов С.Т, "Эффективная работа с СУБД" [Текст] / Горев А.Б, СПб.:Питер, 2007.-- 704 с.,ил.

Атре Ш., "Структурный подход к организации баз данных" [Текст] / Атре Ш - М.: Финансы и статистика, 2003. - 320 с.

Бойко В.В., Савинков В.М., "Проектирование баз данных и информационных систем" [Текст] / - М.: Финансы и статистика, 2009. - 351 с.

Джексон Г., "Проектирование реляционных баз данных для использования с микроЭВМ" [Текст] /. -М.: Мир, 2001. - 252 с.

Кириллов В.В., "Структурированный язык запросов (SQL)" [Текст] / Кириллов В.В. - СПб.: ИТМО, 2004. - 80 с.

Мейер М., "Теория реляционных баз данных" [Текст] / Мейер М - М.: Мир, 2007. - 608 с.

Тиори Т., Фрай Дж., "Проектирование структур баз данных" [Текст] / Тиори Т., В 2 кн., - М.: Мир, 2005. Кн. 1. - 287 с.: Кн. 2. - 320 с.

Цикритизис Д., Лоховски Ф., "Модели данных" [Текст] / Цикритизис Д., - М.: Финансы и статистика, 2005. - 344 с.

"Paradox for Windows: Практическое руководство". Под редакцией Оспищева Д. А. Издательство АОЗ "Алевар", 2003.

Брябрин В.М., "Программное обеспечение персональных ЭВМ" [Текст] / Брябрин В.М., , Москва, 'Hаука', 2009 г.-349с.

Шафрин Ю.А., "Основы компьютерной технологии" [Текст] / Шафрин Ю.А., М., 2008.-256с.

"Рекоммендации по общепользовательскому интерфейсу", Microsoft, редакция 2005г.

Тейксейра, Стив, Пачеко, Ксавье. Delphi 9. "Руководство разработчика" [Текст] / Тейксейра, .СПб:Издательский дом 'Вильямс' 2009г.-912с.

Ден Оузьер, Стив Гробман, Стив Батсон. DELPHI. "Освой самостоятельно" [Текст] / Ден Оузьер, Перевод с англ.-М.:Восточная Книжная Компания, 2007г.-624с.

Калянов Г.Н., "Консалтинг при автоматизации предприятий": Научно-практическое издание / Калянов Г.Н., . Серия "Информатизация России на пороге 21 века" - М.:СИНТЕГ, 2007г.-316с.

Питер Колетски и др. ORACLE DESIGNER "Настольная книга пользователя" [Текст] / Питер Колетски., Второе издание.Издательство 'Лори' 2009г.

Касьянова Г.Ю., Колесников С.Н., " Управленческий учёт по формуле 'три в одном' [Текст] / Касьянова Г.Ю., " М.:Издательство-консультационная компания 'Статус Кво 09', 2009г.-328с.

Приложение А

СПИСОК СОКРАЩЕНИЙ

АБД - администратор БД;

АИС - автоматизированная информационная система;

АРМ - автоматизированное рабочее место;

АСУ - автоматизированные системы управления;

АСУ П - АСУ предприятия;

АСУ ТП - АСУ технологических процессов;

БД - база данных;

ГОСТ - государственный стандарт;

ПАЗ - противоаварийная защита;

ПТК - программно-технический комплекс;

ПЛК - программно-логический контроллер;

ФЗП - фонд заработной платы;

п/с - подсистема;

п/ф - полуфабрикат;

СтП - стандарт предприятия;

СУБД - система управления базами данных;

ТУ - технические условия;

ТЭП - технико-экономические показатели;

ЯОД - язык описания данных;

Размещено на Allbest.ru