Ограничение

BR5:

Данные

Набор объектов системы должен содержать хотя бы одну таблицу

Активатор действия

BR6:

Процедуры

Набор объектов системы должен содержать хотя бы одну процедуру

Активатор действия

BR7:

Определение прав

Если права доступа к объекту не определены, то они устанавливаются по умолчанию

Вывод

BR8: Определение ресурсов

При регистрации пользователю выделяется определенный объем памяти

Факт

BR9:

Доступные ресурсы

Объем доступных ресурсов определяется с учетом выделенных ресурсов и ресурсов, затраченных на хранимые объекты

Вычисления

BR10:

Сохранение

При выполнении действий происходит сохранение всех объектов

Факт

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

Рассмотрим модели вариантов использования администратора информационной системы (рисунок 2.1).

Рисунок 2.1. Модель вариантов использования администратора

Администратор информационной системы обеспечивает выполнение функциональных требований к системе:

- регистрирует компанию в системе;

- регистрирует пользователей в системе;

- задает ограничения, права доступа для пользователей;

- организует ведение процедур, триггеров;

- выполняет анализ действий пользователей в системе.

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

Таблица 2.3 - Функциональные требования к системе

Название	Описание	Приоритет
FEAT1: Регистрация компании	Система должна обеспечивать возможность регистрации компании	Высокий
FEAT2: Регистрация пользователя	Система должна обеспечивать возможность регистрации отдельного пользователя в системе	Высокий
FEAT3: Создание объектов	Система должна обеспечивать возможность создания различных объектов: таблиц, процедур, триггеров	Высокий
FEAT4: Выполнение действий	Система должна обеспечивать возможность выполнять различные действия: редактирование, удаление, запуск	Высокий
FEAT5: Задание правил	Система должна обеспечивать возможность задавать права пользователей для доступа к различным объектам	Высокий
FEAT6: Ограничение доступа	Система должна обеспечивать пользователю возможность предоставлять различный доступ другим пользователям к созданным объектам	Средний
FEAT7: Просмотр ресурсов	Система должна обеспечивать возможность просмотра размера предоставляемых ресурсов	Средний
FEAT8: Сохранение объектов	Система должна обеспечивать возможность сохранения созданных объектов	Высокий
FEAT9: Просмотр изменений	Система должна обеспечивать возможность просматривать изменения, примененные к объекту	Высокий
FEAT10: Откат изменений	Система должна обеспечивать возможность отменять изменения, примененные к объекту	Высокий
FEAT11: Анализ действий	Система должна обеспечивать возможность анализа действий пользователя в системе	Высокий
FEAT12: Подготовка отчета	Система должна обеспечивать возможность подготовки отчетов о действиях пользователя в системе	Высокий

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

Таблица 2.4 - Матрица трассировки функциональных требований на бизнес-правила

FEAT1:Регистрация компании

FEAT2:Регистрация пользователя

FEAT3: Создание объектов

FEAT4: Выполнение действий

FEAT5: Задание правил

FEAT6: Ограничение доступа

FEAT7:Просмотр ресурсов

FEAT8:Сохранение объектов

FEAT9: Просмотр изменений

FEAT10: Откат изменений

FEAT11: Анализ действий

FEAT12: Подготовка отчета

BR1:Наличие прав

BR2: Публичность

BR3: Объекты

BR4: Действия

BR5: Данные

BR6: Процедуры

BR7: Определение прав

BR8: Определение ресурсов

BR9: Доступные ресурсы

BR10: Сохранение

Приоритеты функциональных требований представлены в таблице 2.3 в столбце «Приоритет» для каждого требования. Требования, имеющие приоритет «Высокий», должны быть удовлетворены в первую очередь. Определение приоритетов происходило по трехуровневой шкале приоритетов.

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

Рисунок 2.2. Модель вариантов использования менеджера и начальника отдела

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

2.2.3 Анализ нефункциональных требований

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

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

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

Рассмотрим основные группы нефункциональных требований:

1. Требования к архитектуре системы.

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

2. Требования к параметрам оборудования.

- Система должна работать на IBM-совместимых компьютерах.

- Минимальная конфигурация:

- Тип процессора - Pentium 66 и выше

- Объем ОЗУ - 512 Мб.

- Требования к монитору - достаточен монитор SVGA с диагональю 17'.

- Наличие свободного места на жестком диске: не менее 2 Мб для хранения самой программы и место для хранения файла базы данных (количество записей в таблицах базы данных длину записи, где длина одной записи в среднем 1Кб).

- Наличие устройств ввода (клавиатура и мышь)

- Наличие принтера

3. Требования к параметрам системы.

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

- Время отклика системы не должно превышать 1-2 с.

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

4. Требования к программному интерфейсу.

Разрабатываемое программное обеспечение должно удовлетворять следующим эргономическим принципам:

4.1 Минимального рабочего усилия.

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

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

4.4. Минимального объёма оперативной памяти пользователя. От пользователя требуется, чтобы он запоминал минимум информации как текущей, так и общей.

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

Требования, предъявляемые к экранным формам:

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

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

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

5. Требования к структуре системы

- масштабируемость - в будущем может появиться возможность одновременной работы 2 и более дежурных с одной базой данных, а также открытие новой стоянки с общей базой данных

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

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

6. Требования по взаимодействию и интеграции с другими системами.

Должна быть предусмотрена возможность передачи данных в текстовый редактор MS Word и электронные таблицы MS Excel

2.2.4 Анализ проектных ограничений

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

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

1. Уровень квалификации пользователей информационной системы.

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

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

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

2.3 Цели и бизнес-требования проекта, описание критериев успеха проекта

2.3.1 Технико-экономическое обоснование проекта

Стоит отметить, что в среднем выполнение процесса обработки заказов пользователей занимает порядка 192 человеко-часов в месяц. Предположительно трудозатраты по проектному варианту (после внедрения информационной системы) составят 86 человеко-часов в месяц.

Рассчитаем абсолютное снижение трудовых затрат на выполнение задачи:?Т_и=192 - 86 = 106 чел.-часа

4. Коэффициент относительного снижения трудовых затрат составит:

К_и=106 / 192100% = 55 %

5. Индекс снижения трудовых затрат или повышение производительности труда:

Y_и=192 / 86 = 2,23

Определим показатели изменения стоимостных затрат:

1. Определим общие стоимостные затраты работников по базисному варианту:

С0_и= 192 · 200 = 38 400 руб/год

2. Общие стоимостные затраты на выполнение задачи по проектному варианту:

С1_и= 86 · 200 = 17 200 руб/год

3. Рассчитаем абсолютное снижение стоимостных затрат на выполнение задачи:

?С_и= 38 400 - 17 200 = 21 200 руб/год

4. Коэффициент относительного снижения стоимостных затрат составит:

Кс_и= 21 200 / 38 400 100% = 55 %

5. Индекс снижения трудовых затрат или повышение производительности труда:

Yс_и= 38 400 / 17 200 = 2,23

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

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

? приток кадров, заинтересованных в работе с современными средствами труда;

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

2.3.2 Календарно-ресурсное планирование проекта

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

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

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

Рисунок 2.3. Декомпозиция задач проекта

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

Таблица 2.5. Последовательность работ проекта

Код работ	Название	Предшествующая работа	Длительность (дн)
1	Анализ информационной системы компании	-	5
2	Анализ процесса управления доставкой	-	4
3	Постановка задачи автоматизации процесса	1,2	8
4	Анализ существующих систем	3	3
5	Проектирование процесса управления доставкой	2	12
6	Анализ функций выбранного ПС	4,5	8
7	Установка программного средства	6	2
8	Обучение пользователей	7	10
9	Опытная эксплуатация	8	15

Проанализировав проект, составив наименование работ и установив продолжительность каждой работы можно построить линейный график Ганта. График был реализован с помощью программы MS Project 2007. Программа позволяет прописать название задачи, ее длительность, указать название ресурсов, с помощью которых будут реализовываться задачи. Также можно указать затраты на оплату рабочего времени каждого ресурса. В первую очередь осуществляется описание структуры работ проекта.

Стоит отметить, что при задании структуры проекта были выделены этапы, объединяющие несколько задач. На рисунке это строки, выделенные жирным шрифтом со знаком «минус» слева от названия. Имеется возможность сворачивать группы. При этом, рассчитывается общее время выполнения этапа с учетом параллельного выполнения работ.

Кроме того, в таблице введены данные о вехах - задачах, которые имеют длительность 0, т.е. событиях. В нашем проекте обозначены такие события, как начало и завершение проекта. Начало проекта запланировано на 11 января. По результатам расчетов весь проект займет 52 дня, без учета выходных и праздничных дней и закончится 23 марта (рисунок 2.4).



Рисунок 2.4. Структура работ проекта

На основе этой таблиц программа автоматически строит диаграмму Ганта (Рисунок 2.5).

Рисунок 2.5. Диаграмма Ганта

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

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



Рисунок 2.6. Диаграмма Ганта с указанием критических работ

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

Рисунок 2.7. Отдельные этапы выполнения проекта

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

2.3.3 Анализ рисков, определение метрик для мониторинга рисков проекта

В соответствии с определением американского стандарта в области управления проектами PMBOK (2004), риск проекта - это неопределенное событие или условие, которое в случае возникновения имеет позитивное или негативное воздействие, по меньшей мере, на одну из целей проекта, например, сроки, стоимость, содержание или качество. Риск в проекте может иметь не только негативное, но и позитивное влияние, то есть приводить к улучшению качественных и количественных характеристик конечных целей проекта. Проанализируем риски проекта. Риски обусловлены такими факторами, как недостаточное определение всех параметров, обуславливающих выбор новых технологий, случайностью, которую невозможно предусмотреть, неопределенностью интернет - среды, техническими факторами. Анализ рисков проекта проводился на основе экспертной оценки. Эта методика предполагает определение вероятности появления того или иного риска на основе оценок экспертов, которых должно быть не менее трех. В нашем случае в качестве экспертов выступали такие специалисты, как директор компании, начальник отдела и менеджер. Каждый из них давал оценку вероятности появления риска, на основе чего рассчитывалась средняя вероятность. Кроме того, в результате совместного обсуждения была произведена оценка уровня риска. А уже на основе этих двух оценок (вероятности и уровня риска) проводился расчет интегральной оценки риска. Выявленные в результате экспертной оценки риски представлены в таблице 2.6.

Таблица 2.6. Риски проекта

Вид риска	Отрицательное влияние риска
Нежелание пользователей осваивать новые способы работы	Может привести к медленной и неэффективной работе системы
Недостаточная компетентность пользователей	Может привести к невозможности внедрения новой системы
Затягивание сроков проекта внедрения информационной системы управления доставкой корреспонденции	За счет того, что перед вводом сайта компании нужно еще разработать, протестировать и отладить дополнительную программу, сам проект существенно затягивается
Несоответствие функциональных требований, предъявляемых к системе к реальным потребностям организации	Может привести к серьезным сбоям в работе компании
Риск выхода за бюджет проекта	Невозможность доведения проекта до завершающей стадии

Проанализируем вероятность появления риска на основе экспертных оценок (таблица 2.7). В оценке участвовало 3 эксперта.

Таблица 2.7. Вероятности рисков

Вид риска	Вероятность риска по экспертам	Общая оценка
	Эксперт 1	Эксперт 2	Эксперт 3
Нежелание пользователей осваивать новые способы работы	0,25	0,25	0	0,17
Недостаточная компетентность пользователей	0,25	0,5	0,25	0,33
Затягивание сроков проекта внедрения информационной системы управления доставкой корреспонденции	0,5	0,5	0,75	0,58
Несоответствие функциональных требований, предъявляемых к системе к реальным потребностям организации	0,25	0,5	0,25	0,33
Риск выхода за бюджет проекта	0	0	0,25	0,08

Проанализируем уровень риска (оценка потерь от возникновения риска) на основе экспертных оценок (таблица 2.8). В оценке участвовало 3 эксперта.

Таблица 2.8. Уровень рисков

Вид риска	Вероятность риска по экспертам	Общая оценка
	Эксперт 1	Эксперт 2	Эксперт 3
Нежелание пользователей осваивать новые способы работы	0,75	0,75	0,5	0,67
Недостаточная компетентность пользователей	0,25	0	0,25	0,17
Затягивание сроков проекта внедрения информационной системы управления доставкой корреспонденции	1	0,75	1	0,92
Несоответствие функциональных требований, предъявляемых к системе к реальным потребностям организации	0,25	0	0,25	0,17
Риск выхода за бюджет проекта	0,25	0	0	0,08



Рассчитаем интегральную оценку риска всего проекта (таблица 2.8).

Таблица 2.9. Интегральная оценка риска

Вид риска	Уровень риска	Вероятность риска	Приемлемость риска
Нежелание пользователей осваивать новые способы работы	0,67	0,17	0,11
Недостаточная компетентность пользователей	0,17	0,33	0,06
Затягивание сроков проекта внедрения информационной системы управления доставкой корреспонденции	0,92	0,58	0,53
Несоответствие функциональных требований, предъявляемых к системе к реальным потребностям организации	0,17	0,33	0,06
Риск выхода за бюджет проекта	0,08	0,08	0,01
Итого по всем рискам	0,77

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



3. Архитектура проекта и оценка экономической эффективности проекта

3.1 Системная архитектура проекта

3.1.1 Архитектура данных

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

Таблица 3.1 - Взаимодействие с другими подразделениями

№п/п	Подразделение	Получение	Предоставление
1	Экономический отдел	Перечень и характеристика услуг Цены и условия скидок	-
2	Отдел эксплуатации	Отчеты о ходе выполнения работ Документы по выполнению услуг.	Подробные данные о заказе клиента
3	Клиент	Данные клиента Заявка	Договор Отчеты о ходе работ Пакет документов

Для анализа информационных потоков разработаем диаграмму потоков данных. Для построения DFD традиционно используются две различные нотации, соответствующие методам Йордона-ДеМарко и Гейна-Сэрсона. Эти нотации незначительно отличаются друг от друга графическим изображением символов (в работе будет использоваться нотация Гейна-Сэрсона). Контекстная диаграмма модели потоков данных по учету заказов клиентов представлена на рисунке 3.1.

Рисунок 3.1 - Контекстная диаграмма модели потоков данных

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

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

- заявка клиента;

- форма, содержащая данные клиента;

- справка о проведении оплаты;

- отчет о ходе работ;

- отчет о результатах контроля хода выполнения заказа;

В процессе работы информационной системы применяются такие справочники:

- перечень услуг;

- прайс на услуги, условия формирования скидок;

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

- данные клиентов;

- база заказов компании;

- договора;

- счета;

- документы по заказу;

- отчеты по ходу работ;

- документация заказа.

В результате работы системы формируются такие документы:

- договор;

- счета;

- данные по заказу;

- отчеты клиенту о ходе выполнения работ.

Документооборот отдела при решении задачи учета заказов клиентов представлен на диаграмме потоков данных на рисунке 3.2.

Рисунок 3.2 - Диаграмма первого уровня модели потоков данных

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

3.1.2 Архитектура прикладных программ

В компании будет внедрено программное средство автоматизации процесса управления заказами клиентов - MacronERP. Программная архитектура ИС компании после внедрения программного средства представлена схемой на рисунке 3.3.

Рисунок 3.3 - Программная архитектура

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

3.1.3 Технологическая архитектура проекта

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

Рисунок 3.4 - Техническая архитектура

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

3.2 Реализация проектного решения на пилотном участке

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

Рисунок 3.5 - Окно авторизации

При первом запуске программы нужно ввести данные организации, работу которой автоматизирует система (рисунок 3.6).

Рисунок 3.6 -Ввод данных организации

При выборе пункта «Клиенты» отражаются данные обо всех клиентах, с подробными комментариями, информация о заказах, произведенной оплате (рисунок 3.7).

Рисунок 3.7 - Форма «Клиенты»

Данные о курьерах можно просмотреть на форме «Курьеры»

Рисунок 3.8 - Форма «Курьеры»

Окно установки настроек для определенного заказа представлено на рисунке 3.9.



Рисунок 3.9 - Окно установки настроек

При просмотре заказов можно установить фильтр, который обеспечит быстрый отбор нужных заказов (рисунок 3.10).

Рисунок 3.10 - Окно установки фильтра

В программе имеется возможность печати отчетов по выбранным заказам. Для этого нужно задать настройки отчета в окне подготовки отчета (рисунок 3.11).

Рисунок 3.11 - Окно подготовки отчета

Результатом будет визуализированный отчет выполнения заказа



Рисунок 3.12 - Окно отчета

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

3.3 Расчет затрат на реализацию проекта и описание ожидаемого экономического эффекта от использования результатов проекта/автоматизации

3.3.1 Анализ затрат на оплату труда

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

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

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

При расчете стоимости автоматизации необходимо учесть следующие факторы:

- полезный годовой фонд времени;

- годовые эксплуатационные затраты;

- стоимость одного часа машинного времени;

- среднегодовая заработная плата разработчика;

Главным источником роста прибыли и рентабельности является снижение себестоимости. Снижение себестоимости программного продукта можно добиться несколькими путями:

- изменение объема и структуры продукции;

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

- использование ранее написанных модулей.

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

Таблица 3.2 - Этапы реализации проекта

№п/п	Этапы разработки	Время, час.
1	Анализ информационной системы компании	10
2	Анализ процесса управления доставкой	5
3	Постановка задачи автоматизации процесса	15
4	Анализ существующих систем	1
5	Проектирование процесса управления доставкой	10
6	Анализ функций выбранного ПС	20
7	Установка программного средства	20
8	Обучение пользователей	10
9	Опытная эксплуатация	10
	ИТОГО	101
	В том числе машинное время	70

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

С_р= ЗП_р.руч• n₁ + С_м.час • n₂ (3.1)

где: n₁ и n₂ - соответственно количество чел. часов разработки и машинных часов;

n_l = 31 час.;

n₂=70часов.

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

, (3.2)

ФЗП_год= ЗП_ср.год.+ отчисл. (3.3)

Отчисления на социальные нужды составляют 30 % от фонда заработной платы.

ФЗП_год = 300000+ 300000• 0,3 = 390000руб.

Рассчитываем среднечасовую заработную плату по формуле 3.2:

руб.

Вычисляем стоимость разработки программы по формуле 3.1:

С_р = 198,17• 31 + 308,99 • 70 = 27772,57 руб.

3.3.2 Анализ затрат на ресурсное обеспечение

Стоимость одного часа машинного времени вычисляем по формуле:

, (3.4)

где: С_экс - годовые эксплуатационные расходы, руб.;

F_н - эффективный годовой фонд времени, час;

К_исп - коэффициент использования машины и времени разработчика. Коэффициент использования машины принимаем 0,9.

Календарный фонд времени вычисляется по формуле:

F'_n = F_к-F_n



F_K= 365 дней

F_n= 118дней

F'_n= 365 - 118= 247дней

Номинальный годовой фонд времени работы оборудования в часах при работе в одну смену:

(3.5)

= 239 дней, количество полных рабочих дней;

= 8 ч-- продолжительность рабочей смены;

= 8 дней-- количество предпраздничных, сокращенных на один час дней;

= 7 ч -- продолжительность предпраздничной рабочей смены.

Подставив эти данные в формулу (3.5)

ч

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

С_экс = ЗП_ср.год + О_ЗП+ А_год + С_н.р. + С_э,(3.6)

где: ЗП_ср.год - среднегодовая заработная плата разработчика, он же занимается обслуживанием. Работу выполняет инженер-программист с заработной платой в сумме 25000 рублей в месяц;

О_ЗП - отчисления на социальное страхование и обеспечение (30 % от заработной платы), %; А_год - годовые амортизационные отчисления, руб.; С_нр - накладные расходы, руб.; С_э - стоимость потребляемой электроэнергии за год, руб.



руб., (3.7)

где Ч - численность рабочих, 1 человек.

ЗП_ср.год= 25000*1*12 = 300000 руб.

Отчисления на социальное страхование и обеспечение составят:

О_ЗП= 300000 *0,3= 90000 руб.

А_год. = Н_а% • С_комп., (3.8)

где: Н_а - норма амортизации (10%), ускоренная амортизация (20%);

С_комп. - стоимость компьютера (24000 руб.).

руб.

Накладные расходы в условиях предприятия составляют 50% от заработной платы техника-программиста. Сюда включаются затраты на содержание помещения, оборудования, управленческие затраты.

, (3.9)

где П_пр- накладные расходы в условиях предприятия

руб.

Стоимость потребляемой электроэнергии рассчитывается по формуле

С_э = М_п•F_н. • Ц_э • К_исп, (3.10)



где: М_п- сумма потребляемой мощности, составляет 0.4 кВт;

F_н. - годовой фонд рабочего времени, составляет 1968 часов

Ц_э - стоимость 1 кВт, составляет 3,50 руб.;

К_исп- коэффициент использования мощности, принимается 0,9;

С_э= 0,4• 1968 • 3,50• 0,9 =3064,32 руб.

Полученные данные представим в виде таблицы 3.3

Таблица 3.3 - Эксплуатационные расходы

Показатель	Расчетная формула	Значение, руб.	Удельный вес, %
Среднегодовая заработная плата разработчика, руб.		300000	54,82
Отчисления на социальное страхование и обеспечение		90000	16,44
Годовые амортизационные отчисления, руб.	Агод = На% • Скомп	4800	0,88
Накладные расходы, руб.		150000	27,41
Стоимость потребляемой электроэнергии за год, руб.	Сэ = Мп•Fн • Цэ • Кисп	2480	0,45
Итого:	Сэкс = ЗПср.год + ОЗП+ Агод + Сн.р. + Сэ,	547280

Исходя из этих данных получаем:

Сэкс = 240000 + 72000 + 4300 + 112000 + 3064 = 431364 руб.

По полученным значениям рассчитываем стоимость машинного часа, которая рассчитывается по формуле 3.4:

руб.



Рисунок 3.13 - Процентное соотношение эксплуатационных расходов

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

3.3.3 Анализ качественных и количественных факторов воздействия проекта на бизнес-архитектуру организации

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

Расчет экономической эффективности проводится по разности затрат до внедрения (3₁) и после внедрения (3₂), умноженной на объем выполняемых работ (N) за минусом стоимости разработки программы (С_р).

Э = (3₁-3₂)*N-C_p,(3.11)

где: N =247 - количество запусков программы в год;

3₁ = ЗП_р.руч•t_l, (3.12)

где: t_l=3,5 час. - время на выполнение операций в ручном варианте.

3₁ = 198,17•3,5 = 693,60 руб.

3₂ = С_м.ч.• t₂, (3.13)

где: С_мч - стоимость машинного часа;

t₂= 0,5 час. - время на выполнение операций в машинном варианте.

3₂ = 308,99 •0,5 = 154,50 руб.

Годовой экономический эффект составил:

Э = (693,60 - 154,50)• 247 -27772,57 =105385, 13 руб.

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

. (3.14)

года

То есть данная программа окупится через 3,2 месяца. Все полученные данные представлены в таблице 3.3.

Таблица.3.4-Свободные экономические показатели по разработке программы

Показатель	Расчетная формула	Значение
Стоимость одного часа машинного времени, руб.		308,99
Стоимость разработки программы, руб.	Ср= ЗПр.руч• n1 + См.час • n2	27772,57
Цена программного продукта, руб.	Р = Ср + П + НДС,	49157,45
Годовой экономический эффект, руб.	Э = (31-32)*N-Cp,	105385, 13
Срок окупаемости, год.		0,26

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



Заключение

Объектом исследования в выпускной квалификационной работе является компания ООО «Румянцево». Компания предлагает своим клиентам три вида услуг: входящая почта, исходящая почта, экспресс-доставка. Первым этапом выполнения работы был анализ существующей ИТ-архитектуры организации. Уровень зрелости в организации соответствует классу «2 Повторяемый, но интуитивный». Это связано с тем, что в организации нет стандартов управления процессами, не разработана технология. Это касается и управления ИТ-инфраструктурой.

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

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

1. Уровень квалификации пользователей информационной системы.

2. Требования к надежности информационной системы..

3. Время ввода системы в эксплуатацию.

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

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

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

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



Список используемой литературы

1. IT-решения втранспортном бизнесе: итоги конференции // Материалы интернет-страницы: http://rnd.cnews.ru/reviews /index_science.shtml?2007 /09/24/267413

2. Архангельский А.Я. Программирование в Delphi 7. - М.: ООО «Бином-Пресс», 2008, - 1152с.

3. Архипенков С. Лекции по управлению программными проектами [текст] / С. Архипенков. - М.: 2009. - 128 с.

4. Богатин Ю. В. Экономическая оценка качества и эффективности работы предприятия. -- М.: Издательство стандартов, 2009. --216 с.

5. Братищенко В.В. Проектирование информационных систем. [Текст] / Иркутск: БГУЭП, 2008 - 84 стр.

6. Вендров А. М. CASE-технологии: Современные методы и средства проектирования информационных систем. [Текст] / М.: Финансы и статистика, 2009 - 176 стр.

7. Вендров А. М., Практикум по проектированию программного обеспечения экономических информационных систем: Учеб. пособие. - 2-е изд., перераб. и доп. [Текст] / М.: Финансы и статистика, 2009 - 192 стр.

8. Вендров А. М., Проектирование программного обеспечения экономических информационных систем: Учебник. 2-е изд., перераб. и доп. [Текст] / М.: Финансы и статистика, 2009 - 544 стр.

9. Вилков Л.А. Менеджмент процессов [текст] / Л.А. Вилков, Й. Беккер, В. Таратухин, М. Кугелер, М. Роземанн; пер. с нем. - М.: Эксмо, 2007. - 384 с.

10. Гагарина Л.Г. Технология разработки программного обеспечения: учебное пособие [текст] / Л.Г.Гагарина, Е.В. Кокорева, Б.Д. Виснадул. - М.: ИД «ФОРУМ»: ИНФРА-М, 2008. - 400 с.

11. Гвоздева В. А., Лаврентьева И. Ю. Основы построения автоматизированных информационных систем / В. А. Гвоздева, И. Ю. Лаврентьева. - М.: ИД "ФОРУМ", ИНФРА-М, 2010. - 210 с.

12. Годин В. В., Корнев И. К. Информационное обеспечение управленческой деятельности: Учебник. -- М.: Мастерство: Высшая школа, 2008. -213с.

13. Голицина О.Л. Базы данных: Учебное пособие [текст] /О.Л. Голицина, Н.В. Максимов, И.И. Попов. - М.: ФОРУМ: ИНФРА-М, 2009. - 352 с.

14. Головач В. Дизайн пользовательского интерфейса. Искусство мыть слона [текст] / В. Головач. - М.: Dreamstime.com. 2009. - 97 с.

15. ГОСТ 19.105-78. ЕСПД. Общие требования к программным документам. - М.: Закон, 2012. - 35 с.

16. ГОСТ 19.201-78. ЕСПД. Техническое задание. Требования к содержанию и оформлению. - М.: Закон, 2012. - 35 с.

17. ГОСТ Р ИСО/МЭК 12207-99 Информационная технология. Процессы жизненного цикла программных средств [Электронный ресурс]. - Режим доступа: http://www.rfcmd.ru/sphider/docs/InfoSec/GOST_R_ICO-IEC_12207-99.htm

18. Грекул В.И. Проектирование информационных систем: курс лекций: учебное пособие для студентов вузов, обучающихся по специальностям в области информ. технологий [текст] / В.И. Грекул, Г.Н.Денищенко, Н.Л. Коровкина. - М.: Интернет-Ун-т Информ технологий, 2009. - 304 с.

19. Гусятников В. Н., Безруков А. И. Стандартизация и разработка программных систем, учебное пособие [Текст] / М.: ФиС, 2010 - 288 стр.

20. ДейтК.Дж. Введение в системы баз данных, 8-е издание.: Пер. с англ[текст] / К.Дж.Дейт. - М.: Издательскийдом "Вильяме", 2010. -- 1328 с.

21. Диго С.М.Базы данных: проектирование и использование: Учебник [текст] / С.М.Диго. - М.:Финансы и статистика, 2010. - 592 с.

22. Емельянова Н.З. Основы построения автоматизированных информационных систем: Учебное пособие [текст] / Н.З.Емельянова, Т.Л.Партыка, И.И.Попов. - М.: ФОРУМ: ИНФРА-М, 2007. - 416 с.

23. Зыков С. В. Модели жизненного цикла и методологии разработки корпоративных систем [Видеокурс] / Интернет-университет информационных технологий - ИНТУИТ.ру, 2009 - DVD-box: 2 диска.

24. Иванова Г.С. Технология программирования: Учебник для вузов. - 2-е изд., стереотип. - М.: Изд-во МГТУ им. Н.Э. Баумана, 2009. 320 с.: ил.

25. Избачков Ю.С. Информационные системы: Учебник для вузов. 2-е изд[текст] / Ю.С.Избачков, В.Н.Петров. - СПб.: Питер, 2009. - 656 с.

26. Калачанов В.Д., Кобко Л.И. Экономическая эффективность внедрения информационных технологий. Учебное пособие / В.Д. Калачанов, Л.И. Кобко. - М.: МАИ, 2006. - 180 с.

27. КамытбаеваЗ. Backoffice грузоперевозок// Intelligent enterprise. Корпоративные системы. - 20 Февр. 2006г., - №2(135)

28. Кантор М. Управление программными проектами. Практическое руководство по разработке успешного программного обеспечения [Текст] / М.: Вильямс, 2007 - 176 стр.: с ил.

29. Косарев А.И., Пустовая А.И. Тенденции взаимодействия и адаптации предприятий транспорта в информационной экономике.

30. Котляров В.П. Основы тестирования программного обеспечения: Учебное пособие / В.П.Котляров, Т.В. Коликова. - М.: Интернет-Университет Информационных технологий; БИНОМ. Лаборатория знаний, 2009. - 285 с.

31. Крупский А.Ю. Разработка и стандартизация программных средств: Учебное пособие [текст] / А.Ю. Крупский, Л.А.Феоктистова. - М.: Издательско-торговая корпорация «Дашков и Ко», 2009. - 100 с.

32. Левиков Г.А. Управление транспортно-логистическим бизнесом. Учеб.пособие - М.: РосКонсульт, 2010.

33. Лойко В.И. Информационные системы и технологии в экономике: Учебник. - 2-е изд., доп. и перераб[текст] /В.И. Лойко, Т.П. Барановская, М.И. Семенов, А.И. Трубилин. - М.: Финансы и статистика, 2009. - 416 с.

34. Макконел Стив. Профессиональная разработка программного обеспечения [текст] / С. Макконел; пер. с англ. под ред. В.Агаповой. - СПб.: Символ-Плюс, 2011. - 240 с.

35. Маклаков С. В. BPwin и ERwin CASE-средства разработки ИС [Текст] / М.: Диалог-МИФИ, 2009 - 304 стр.

36. Маклаков С. В. Моделирование бизнес-процессов - М., 2009. - 224с.

37. Марков А.С. Базы данных. Введение в теорию и методологию: Учебник [текст] / А.С.Марков, К.Ю.Лисовский. - М.: Финансы и статистика, 2009. - 512 с.

38. Маслов А.В. Проектирование информационных систем в экономике: учебное пособие / А.В. Маслов.- Томск: Изд-во Томского политехнического университета, 2008. - 216 с.

39. Мацяшек Л.А. Анализ требований и проектирование систем.- М.: Наука, 2008- 352 с.

40. Моделирование бизнес-процессов средствами BPwin (часть 1) [Электронный ресурс] - Режим доступа: http://www.intuit.ru/department/se/devis/7/

41. Моделирование бизнес-процессов средствами BPwin (часть 2) [Электронный ресурс] - Режим доступа: http://www.intuit.ru/department/se/devis/8/

42. Моделирование информационного обеспечения средствами ERwin [Электронный ресурс] - Режим доступа: http://www.intuit.ru/department/se/devis/10/

43. Петров В.Н., Избачков Ю.С. Информационные системы: Учебник для вузов. 2-е изд.[Текст] / СПб.: Питер Принт, 2010 - 656 стр.

44. Подолякин О.В. Внедрение информационных систем управления на предприятии / О.В. Подолякин. // Проблемы развития территории. - 2012. - Т. 60. - № 4. - С. 20-28.

45. Принципы и этапы разработки ПО [Электронный ресурс]. - Режим доступа: http://www.tspu.tula.ru/ivt/old_site/umr/trpo/node14.html

46. Проектирование экономических информационных систем: Учебник / Г. Н. Смирнова, А. А. Сорокин, Ю. Ф. Тельнов; Под ред. Ю. Ф. Тельнова. - М.: Финансы и статистика, 2008. - 512с.

47. Рогозов Ю.И. Разработка метода построения информационных функционально-ориентированных моделей предприятия /Изв. ЮФУ. Технические науки[текст] / Ю.И.Рогозов. - 2008. - №7. - С.70-76.

48. Сергеев А. Access2007. Новые возможности [текст] / А.Сергеев. - СПб.: Питер, 2008. - 176 с.

49. Сорокин А.В. Delphi. Разработка баз данных [текст] / А.В.Сорокин. - СПб.: Питер, 2010. - 477 с.

50. Стивенс Род. Программирование баз данных. Изд. 2-е, стереотипное [текст] / Р. Стивенс; пер с англ. под ред. С.М.Молявко. - М.: ООО «Бином-Пресс», 2007. - 384 с.

51. Тельнов Ю.Ф. Реинжиниринг бизнес процессов. М. Финансы и статистика, 2009-319с.

52. Технология освоения и внедрения CASE-средств [Электронный ресурс]. - Режим доступа: http://www.interface.ru/home.asp?artId=22623

53. Титоренко Г.А. Автоматизированные информационные технологии в экономике: Учебник - М.: Компьютер, ЮНИТИ, 2009.-400с.

54. Титоренко Г.А. Информационные системы в экономике:учеб. пособие для вузов- 2-е изд.доп. - М.: «ЮНИТИ-ДАНА», 2008.-463с.

55. Титоренко Г.А. Информационные технологии управления: Учеб. пособие для вузов 2-е изд., доп. - М.: Инфра-М, 2009. - 164 с.

56. Фаронов В.В. Программирование баз данных в Delphi 7. Учебный курс[текст] / В.В.Фаронов. - СПб.: Питер, 2011. - 459 с.

57. Фельдман Я.А. Создаем информационные системы[текст] / Я.А.Фельдман.- М.: СОЛОН-ПРЕСС, 2006. - 120 с.

58. Фленов М.Е. Библия Delphi. - 2-е изд., перераб. и доп[текст]/ М.Е.Фленов. - СПб.: БХВ-Петербург, 2008. - 800 с.

59. Фуфаев Э.В. Базы данных: учеб. пособие для студ. сред. проф. образования - 3-е изд., стер[текст] / Э.В.Фуфаев, Д.Э.Фуфаев. - М.: Издательский центр «Академия», 2007. - 320 с.

60. Хомоненко А. Д., Цыганков В. М., Мальцев М. Г. «Базы данных» Учебник для вузов Изд., Корона-Принт 2008 г - 736с.

61. Якобсон А., Буч Г., Рамбо Дж. Унифицированный процесс разработки программного обеспечения [Текст] / СПб.: Питер, 2009 - 496 стр.: с ил.

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