Разработка системы автоматизации процесса учета электронных ключей ООО "Аналитические технологии"

· Наименование клиента.

· Срок действия договора.

· Условия предоставления услуг технической поддержки.

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

Информация о прошивках и проданных или переданных ключах поступает из следующих документов:

· Договор о предоставлении права пользования программным продуктом.

· Партнерский договор.

· Расписка о получении электронного ключа.

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

Характеристика базы данных.

Характеристика инфологической модели БД.

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

Приложение может не входить ни в одну прошивку (например, если оно ещё ни разу не продавалось). Однако одно и тоже приложение может быть в различных прошивках (сущность «приложения прошивки»).

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

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

Счет прихода должен содержать не менее одного электронного ключа (счет с нулевым количеством ключа бессмыслен). Этот факт обуславливает связь «один-ко-многим-или-одному».

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

Пользователем может быть или юридическое, или физическое лицо. Поэтому связи между сущностями «Пользователь» - «Юридическое лицо» - «один-к-одному-или-к-нулю», «Пользователь» - «Физическое лицо» - «один-к-одному-или-к-нулю».

Характеристика даталогической модели БД

На основе ER-модели построим даталогическую модель (таблица 7).

Таблица 7. Даталогическая модель

Сущность	Идентификатор таблицы	Атрибут	Идентификатор поля	Тип поля
Электронный ключ	keys	Идентификатор	key_id	int
		Заводской идентификатор	factory_key_id	nchar(15)
		Идентификатор модели (FK)	key_model_id	smallint
		Запись помечена на удаление	is_deleted	bit
		Запись была обновлена	is_updated	int
Пользователь	users	Идентификатор пользователя	user_id	int
		Идентификатор статуса (FK)	status_id	tinyint
		Является юрид. лицом	is_artificial_person	bit
		FTP-логин	ftp_login	varchar(20)
		FTP-пароль	ftp_password	varchar(10)
		Контактная информация	contact_inf	text
		Запись помечена на удаление	is_deleted	bit
		Запись была обновлена	is_updated	int
Юридическое лицо	artificial_person	Идентификатор пользователя (FK)	user_id	int
		Наименование организации	name	varchar(100)
Физическое лицо	natural_person	Идентификатор пользователя (FK)	user_id	Int
		Фамилия	second_name	varchar(50)
		Имя	first_name	varchar(25)
		Отчество	middle_name	varchar(25)
		Паспортные данные	passport	text
Статус	status	Идентификатор статуса	status_id	Int
		Наименование	status_name	varchar(20)
		Для физических лиц	is_for_natural_person	Bit
		Для юридических лиц	is_for_artificial_person	bit
		Запись помечена на удаление	is_deleted	bit
		Запись была обновлена	is_updated	Int
Стандартный комплект	standard_kit	Идентификатор комплекта	kit_id	smallint
		Наименование	kit_name	varchar(50)
		Запись помечена на удаление	is_deleted	bit
		Запись была обновлена	is_updated	smallint

Для всех сущностей, имеющих составные ключи, в соответствующих таблицах создано поле «Идентификатор», при этом были указаны все возможные альтернативные ключи (AK). Это было сделано с целью минимизации объема базы данных. Первичные ключи таблиц выделены жирным шрифтом. Внешние ключи имеют метку «FK».

Для сущности «Пользователь» атрибут «тип» был заменен на «Является юрид. лицом» логического типа. Если значение равно «истина», то пользователь - юридическое лицо, иначе - физическое лицо. Атрибут логического типа будет занимать гораздо меньше памяти ЭВМ, чем хранение строкового. При этом вероятность появления нового типа пользователя крайне мала.

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

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

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

При редактировании (обновлении) записи старая запись остается при этом в поле «Запись была обновлена» добавляется ссылка на новую запись, которую пользователь ввел при редактировании. Старые, уже обновленные, записи конечному пользователю также не выводятся.

Характеристика результатной информации.

Характеристика таблиц с результатной информацией.

Результирующая информация представляется в справочниках и журналах в виде таблиц. Опишем некоторые табличные представления (таблица 8).

Таблица 8. Соответствие представлений и полей таблиц базы данных

Представление (Справочник или журнал)	Псевдоним поля	Имя поля	Таблица
Юридические лица (справочник «Пользователи»)	ID	user_id	artificial_person
	Наименование	name	artificial_person
	Статус	status_name	status
	Поставщик	is_supplier	artificial_person
	Логин FTP	ftp_login	users
	Пароль FTP	ftp_password	users
	Контактная информация	contact_inf	users
Счета (Журнал)	ID	bill_id	bill
	Номер	bill_number	bill
	Дата	bill_date	bill
	Поставщик	name	artificial_person

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

Характеристика результатных документов.

Информационная система оперативно формирует требующиеся отчеты. Для чего они необходимы?

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

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

· Серийный номер ключа.

· Название организации-владельца ключа.

· Контактная информации организации-владельца ключа (e-mail, телефон, адрес).

· Дата выта выдачи.

· Номер лицензионного договора.

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

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

· Номер ключа.

· Дата прошивки.

· Договор-основание (обычно лицензионный договор).

· Комплектация ключа согласно прошивки.

· Версия аналитической платформы.

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

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

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

· Номер лицензионного ключа.

· Дата обновления версии.

· Версия.

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

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

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

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

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

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

2.2 Программное обеспечение задачи ИС

Общие положения.

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

«Главное меню» предоставляет доступ к семи основным пунктам меню:

• Файл.

• Справочники.

• Документы.

• Журналы.

• Отчеты.

• Сервис.

• Справка.

До входа в информационную систему доступны только пункты главного меню «Файл» и «Справка».

Меню «Файл» раскрывает следующие пункты подменю:

• Настройки подключения.

• Войти/Сменить пользователя.

• Выход.

Пункт «Настройки подключение» вызывает диалоговое окно настройки пути к информационной базе (указание адреса сервера и имени базы данных).

Пункт «Войти» позволяет вызвать диалоговое окно для ввода имени пользователя и пароля учетной записи. Если вход в систему произведен, то данный пункт меняется на «Сменить пользователя». Фактически щелчок пользователя на этом пункте приведет к перезапуску клиентского приложения.

Пункт «Выход» закрывает клиентского приложение.

Меню «Справочники» раскрывает следующие пункты подменю:

• Электронные ключи.

• Модели ключей.

• Приложения.

• Комплекты.

• Пользователи.

• Сборки.

• Статусы.

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

Пункт «Документы» раскрывает следующие пункты подменю:

• Договора ТП.

• Счета.

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

Пункт «Журналы» раскрывает следующие пункты подменю:

• Прошивки.

• Обновления.

• Приход ключей.

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

Пункт «Отчеты» раскрывает следующие пункты подменю:

• Отчет об обновлениях.

• Отчет о наличии ключей.

• Отчет о наличии действующих договоров ТП.

• Отчет о прошивках.

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

Пункт «Сервис» раскрывает следующие пункты подменю:

• Прошить ключ.

• Выполнить сценарий Deductor.

Пункт «Справка» раскрывает следующие пункты подменю:

• Помощь.

• О программе.

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

Структурная схема пакета.

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

1. Модули подключения к базе данных.

2. Модули экранных форм.

3. Модули добавления, редактирования и удаления записей.

4. Модули транзакций.

5. Модули генерации отчетов.

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

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

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

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

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

Рассмотрим общие принципы построения используемых транзакций.

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

Большая часть транзакций реализованная программно. Типичная транзакция редактирования записи состоит из следующих элементов:

1. Считывание записи.

2. Вывод её в специальной экранной форме.

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

4. При отсутствии ошибок фиксация транзакции, иначе откат всех изменений.

DialogResult.OK - событие возникающее, когда пользователь заканчивает работу с диалоговым окном для сохранения внесенных им изменений (например, нажатием на кнопку «OK»).

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

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

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

3. Чтение фантом (phantom reads) или чтение призрачных строк ситуация возникает, когда один пользователь начинает транзакцию, выбирающую данные из некоторой таблицы. В это же время второй пользователь начинает и заканчивает транзакцию, изменяющую набор данных в таблице (например, были удалены или изменены некоторые записи). При этом у первого пользователя остаются «фантомные» строки, которых теперь нет (или которые были изменены).

Описание программных модулей.

Рассмотри блок-схемы основных процедур информационной системы. Рассмотрим блок схему процедуры входа пользователя в информационную систему. Обратим внимание, что рассматриваемая процедура проверят, были ли ранее сохранены логин и пароль. Они записаны в бинарном файле в зашифрованном виде. После расшифровки логин и пароль выводятся на форму (вместо пароля выводятся символы «звёздочка»). Пользователь в этой форме может ввести другие идентификационные данные и по окончанию ввода нажать кнопку «OK» (или клавишу «Enter»). Если пользователь решил сохранить логин и пароль, то они шифруются симметричным алгоритмом Rijndael с 16-байтовым ключом. Для этого используются стандартная библиотека System.Security.Cryptography платформы Framework.Net. Учет пользователей ведется стандартными средствами Microsoft SQL Server 2005.

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

2.3 Технологическое обеспечение ИС

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

Входная информация поступает из следующих документов:

· счет на покупку ключей;

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

· договор технической поддержки;

· расписка о получении ключа;

· партнерский договор.

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

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

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

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

Партнерский договор заключается компаниями-партнерами ООО «Аналитические технологии». В качестве входной информации для ИС используется наименование организации-партнера, перечень передаваемых ключей, список и количество предоставляемых программ.

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

2.3.2 Схема технологического процесса сбора, передачи, обработки и выдачи информации

Схема технологического процесса сбора, передачи, обработки и выдачи информации для наиболее типичных операций выполнена согласно требованиям ГОСТ 19.701-90 [1] приведена в приложении 5.

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

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

3. Обоснование экономической эффективности проекта

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

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

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

1. Получение задания на разработку.

2. Подбор и изучение литературы.

3. Исследование бизнес-процессов и построение моделей “Как есть” и “Как должно быть”.

4. Разработка инфологической модели данных.

5. Разработка таблиц баз данных.

6. Создание диаграммы базы данных.

7. Создание необходимых представлений.

8. Разработка хранимых процедур.

9. Разработка пользовательского интерфейса.

10. Разработка системы авторизации пользователей.

11. Разработка алгоритмов программы.

12. Отладка программы на ЭВМ.

13. Оформление пояснительной записки.

14. Создание презентации.

15. Cоздание демонстрационной версии программы.

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

T1 = 3 чел. · дн.; U1 = 2 чел.

T2 = 3 чел. · дн.; U2 = 1чел.

T3 = 8 чел. · дн.; U3 = 1 чел.

T4 = 1 чел. · дн.; U4 = 1 чел.

T5 = 2 чел. · дн.; U5 = 1 чел.

T6 = 1 чел. · дн.; U6 = 1 чел.

T7 = 3 чел. · дн.; U7 = 1 чел.

T8 = 7 чел. · дн.; U7 = 1 чел.

T9 = 5 чел. · дн.; U8 = 1 чел.

T10 = 1 чел. · дн.; U9 = 1 чел.

T11 = 8 чел. · дн.; U5 = 1 чел.

T12 = 15 чел. · дн.; U6 = 1 чел.

T13 = 21 чел. · дн.; U7 = 1 чел.

T14 = 3 чел. · дн.; U8 = 1 чел.

T15 = 2 чел. · дн.; U9 = 1 чел.

Продолжительность каждой работы ti определяется по формуле:

Тогда общая продолжительность работ T составит:

дня.

Все полученные данные представлены в таблице 9.

Таблица 9. Трудоемкости работ

№ этапа	Вид работ	Длительность, дни	Исполнитель
1	Составление руководителем работы и получение специалистом задания на разработку	1,25	Руководитель проекта, Дипломник
2	Подбор и изучение литературы	3	Дипломник
3	Исследование бизнес-процессов и построение моделей “Как есть” и “Как должно быть”	8	Дипломник
4	Разработка инфологической модели данных	1	Дипломник
5	Разработка таблиц баз данных	2	Дипломник
6	Создание диаграммы базы данных	1	Дипломник
7	Создание необходимых представлений	3	Дипломник
8	Разработка хранимых процедур	7	Дипломник
9	Разработка пользовательского интерфейса	5	Дипломник
10	Разработка системы авторизации пользователей	1	Дипломник
11	Разработка алгоритмов программы	8	Дипломник
12	Отладка программы на ЭВМ	15	Дипломник
13	Оформление пояснительной записки	21	Дипломник
14	Создание презентации	3	Дипломник
15	Создание демонстрационной версии программы	2	Дипломник

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

Материальные затраты. К ним относят:

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

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

Стоимость покупных комплектующих и полуфабрикатов.

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

Стоимость природного сырья.

Стоимость приобретенного со стороны сырья и топлива.

Стоимость покупной энергии всех видов.

Материальные затраты формируются исходя из цен их приобретения.

При разработке данного проекта к этой статье относят материалы, используемые при проектировании. Перечень материалов, цена, стоимость без учета НДС приведены в таблице 10. Общие материальные затраты составят 3 м =683,25 руб.

Таблица 10. Материальные затраты

Наименование материала	Количество, шт.	Цена за единицу руб.	Сумма с НДС, руб.	Цена без НДС, руб.
СD-диск	2	10	20	16,95
Бумага	1	120	130	101,70
Ручка	1	50	50	39
Переплет	2	80	160	135,6
Черный картридж для принтера	1	500	500	390
ИТОГО:				683,25руб.

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

Выплаты стимулирующего характера.

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

Эта статья складывается из затрат на заработную плату исполнителей (руководитель работы и дипломник). Руководитель и дипломник работают по шестидневной рабочей неделе, их оклады составляют: дипломник (стипендия в месяц) - 4600 руб., руководитель работы (рукодство дипломным проектиро-ванием - 10 часов) - 1000 руб. Таким образом, дневная заработная плата дипломника составляет 176,92 руб., руководителя работы - 800,00 руб. Тогда общие затраты на заработную плату составят:

Данные по заработной плате приведены в таблице 11.

Таблица 11. Данные по заработной плате

№ этапа	Наименование этапа	Исполнитель	Дневная ставка, руб.	Количество дней.	Сумма, руб.
1	Составление руководителем и получение дипломником задания на разработку	Руководитель проекта и дипломник	800,00 176,92	1,25 1,75	1000,00 309,61
2	Подбор литературы	Дипломник	176,92	3	530,76
3	Исследование бизнес - процессов и построение моделей “Как есть” и “Как должно быть”	Дипломник	176,92	8	1415,36
4	Разработка инфологической модели данных	Дипломник	176,92	1	176,92
5	Разработка таблиц баз данных	Дипломник	176,92	2	353,84
6	Создание диаграммы базы данных	Дипломник	176,92	1	176,92
7	Создание необходимых представлений	Дипломник	176,92	3	530,76
8	Разработка хранимых процедур	Дипломник	176,92	7	1238,44
9	Разработка интерфейса	Дипломник	176,92	5	884,6

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

Единый социальный налог (ЕСН) составляет 34 % от заработной платы, а именно:

В том числе:

o В пенсионный фонд РФ (26%) = 4020,5 руб.

o В фонд социального страхования РФ (2,9%) = 448,44 руб.

o В фонд обязательного медицинского страхования (5,1%) = 788,64 руб.

Амортизация основных фондов. Сюда входит сумма амортизацион-ных отчислений на полное восстановление основных фондов.

В данном проекте это затраты на амортизацию и эксплуатацию ЭВМ. Они определяются на основе стоимости одного машинного часа и времени эксплуатации ЭВМ, учитывая ее реальную стоимость, стоимость одного машинного часа и стоимость электроэнергии. Стоимость одного машинного часа ЭВМ рассчитывается по формуле:

где СМВ - стоимость машинного времени; КМЧ =12•24•8=2688 - количество машинных часов в году при шестидневной рабочей неделе и восьмичасовом рабочем дне;

ТЭЛ =3,19 руб. за 1 кВт/ч - тариф за электроэнергию;

МПОТ =0,35 кВт - потребляемая ЭВМ мощность.

Стоимость машинного времени СМВ=Ao,

где Ао-амортизационные отчисления. В компании используется линейный способ начисления амортизации. Срок полезного исопльзования ЭВМ - 3 года. Амортизационные отчисления рассчитаем по формуле:

где S - срок полезного использования (лет), СЭВМ - первоначальная стоимость стоимость ЭВМ (21 000 рублей). Тогда:

Затраты на машинное время определяются с учетом машинного часа и общего времени использования ЭВМ:

где NМЧ - количество часов рабочего времени, затраченных на отладку программы. Для данного проекта NМЧ определяется с учетом количества дней отладки программы (42 дня) и количества часов работы ЭВМ в день (6 часов), то есть общее количество времени составило:

Итого суммарная стоимость по статьям 1-4 составила:

Прочие затраты. Сюда входят следующие налоги и сборы:

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

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

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

Затраты на гарантийный ремонт и обслуживание.

Оплата услуг банков, связи, вычислительных центров.

Оплата за аренду объектов основных фондов.

Износ по нематериальным активам.

Другие затраты, входящие в себестоимость, но не вошедшие в предыдущие элементы затрат.

В данном проекте к этой статье относятся накладные расходы. Процент накладных расходов целесообразно принять за 10%.

Таким образом, сметная стоимость СП =36845,54 руб. Полная смета затрат приведена в таблице 12.

Таблица 12. Смета затрат

Наименование статьи	Затраты, руб.
Материальные затраты	683,25
Основная заработная плата	15463,46
Отчисления на социальные нужды	5257,58
Амортизационные отчисления	7000
Накладные расходы	2222.83
ИТОГО:	36845,54

Один час работы одного сотрудника приносит компании доход от 160 до 1000 рублей. В среднем в день поступает от 2 до 3 обращений. На сбор необходимой информации для анализа одного обращения от 20 минут до одного часа. Например, клиент может написать, что при редактировании аналитического сценария появилась некоторая ошибка и указать самую позднюю сборку платформы. Однако перед этим он использовал более раннюю версию, что являлось ключевым момент в появлении ошибки. Так как важная информация не была сообщена вовремя, было затрачено много времени на поиск ошибки там, где её нет. С использование системы можно сократить время сбора общей информации о ключах и организации до 5 минут, что в месяц может принести дополнительных доход от 3 200 до 73 300 рублей, за счет участия сотрудников в освободившееся время в более дорогостоящих проектах.

Отсюда с можно оценить количество максимальное количество месяцев работы системы T, за которое она покроет свою стоимость, как отношение стоимости системы к минимальному месячному доходу от её использования:

Иными словами, при минимальном ожидаемой нагрузке сотрудников службы поддержки и отдела «Маркетинг» система покроет свою стоимость за год. Такой исход можно рассматривать в качестве худшего. Но даже в этом случае очевидна экономическая эффективность внедрения информационной системы.

Заключение

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

Разработанная система позволит значительно повысить эффективность учета электронных ключей в ООО «Аналитические технологии» за счет использования информационных технологий.

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

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

Литература

серверный даталогический информационный

1. ГОСТ 19.701 - 90 (ИСО 5807 - 85) Схемы алгоритмов, программ, данных и систем. - М.: Государственный стандарт союза ССР, 1990. - 22с.

2. Р 50.1.028-2001. Рекомендации по стандартизации. Информационные технологии поддержки жизненного цикла продукции. Методология функционального моделирования. М.: ИПК Изд-во стандартов, 2001. - 50 с.

3. Абдикеев Н.М. Реинжиниринг бизнес-процессов: учебник. - 2-е изд., испр. - М.: Эксмо, 2007. - 592с.

4. Албахари, Дж. С# 3.0 Справочник: Пер. с анг. - 3-е изд. - СПб.: БХВ-Петербург, 2009. - 944с.

5. Михеев Р.Н. MS SQL Server 2005 для администраторов. - СПб.: БХВ-Петербург, 2007. - 544с.

6. Нильсен, Пол. Microsoft SQL Server 2005. Библия пользователя.: Пер. с англ. - М.: ООО «И.Д. Вильямс», 2008 - 1232с.

7. Паклин Н.Б., Орешков В.И. Бизнес-аналитика: от данных к знаниям (+CD): Учеб. Пособие. 2-е изд., перераб. и доп. - СПб.: Питер, 2010. - 704с.

8. Смирнова Г.Н., Сорокин А.А., Тельнов Ю.Ф. Проектирование экономических информационных систем. Учебник М.: «Финансы и статистика», 2003 - 512c.

9. Хомоненко А.Д. Базы данных : учеб. для вузов / А.Д. Хомоненко, В.М. Цыганков, М.Г. Мальцев; ред. А.Д. Хомоненко. - 6-е изд. - СПб. : Корона-Век, 2010. - 736с.

10. An Approach to Security Using Rijndael Algorithm / International Journal of Computer Applications (0975 - 8887) Volume 8 - No.5, - 2010. - p.31-35.

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

...