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

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

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

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

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

Требования к техническому обеспечению

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

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

• совместимость и возможность изменения конфигурации технических средств;

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

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

2.3 Разработка системной архитектуры

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

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

• прикладной архитектуры,

• архитектуры данных,

• технической архитектуры.

Прикладная архитектура включает в себя:

• прикладные системы (приложения), обеспечивающие исполнение бизнес-функций и бизнес-процессов;

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

• средства и методы разработки и сопровождения приложений.

Архитектура данных включает в себя:

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

• применяемые для этого системы управления базами данных или хранилищами данных;

• правила и средства санкционирования доступа к данным.

Техническая архитектура состоит из:

• сетевой архитектуры

• архитектуры платформ.

Сетевая архитектура включает в себя:

• локальные вычислительные сети, включая физические собственные и арендованные каналы связи и каналообразующую аппаратуру;

• используемые в сетях коммуникационные протоколы, сервисы и системы адресации;

• аварийные планы по обеспечению бесперебойной работы сетей в условиях чрезвычайных обстоятельств.

Архитектура платформ включает в себя:

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

• операционные и управляющие системы, утилиты и офисные программные системы;

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

Разрабатываемый модуль «Техническое обслуживание и ремонт» ИУС SIKE. Autopark является структурным элементом информационной системы управления автопарком предприятия. Модуль будет взаимодействовать с основной информационно-управляющей системой предприятия и прочими системами ведущими учет отдельных активов предприятия (финансовый учет, учет материалов на складе и пр.).

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

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

В данной главе были разработаны проектные решения на разработку модуля «Техническое обслуживание и ремонт» ИУС SIKE. Autopark.

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

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



3. Реализация проектных решений по разработке модуля «техническое обслуживание и ремонт» ИУС SIKE.Autopark

3.1 Информационное обеспечение модуля «Техническое обслуживание и ремонт» ИУС SIKE. Autopark

Информационная модель данных является визуальным представлением структур данных и бизнес-правил для СУБД. В рамках данной дипломной работы была разработана модель данных, позволяющая наглядно отобразить процесс ТО и ремонта автотранспортных средств через разрабатываемый модуль «ТОиР» информационно-управляющей системы SIKE. Autopark.

В качестве информационной модели разрабатываемого модуля была выбрана модель «сущность-связь», представленная в нотации IDEF1X. Такая диаграмма излишне не детализирована, в неё включаются основные сущности и связи между ними, которые удовлетворяют основным требованиям, предъявляемым к информационной системе. Информационная модель в логическом и физическом представлении отображена ниже (см. рисунки 3.1-3.2).

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



Рисунок 3.1. Логическая модель информационной модели данных (основной набор сущностей модуля)



Рисунок 3.2. Физическая модель информационной модели данных

Также, представленные в модели типы данных отличаются от используемых при разработке модуля «ТОиР», так как используемое для построения модели программное средство (AllFusion Erwin Data Modeler) позволяет выбрать типы данных лишь из имеющегося списка, а при разработке данного модуля используются типы данных, созданные непосредственно в компании SIKE. Ниже приведена таблица соответствия используемых в SIKE и указанных на инфологической модели типов данных.

Таблица 3.1. Соответствие типов данных компании SIKE указанным в модели типам данных

В SIKE	В модели	Значение
type_id_inc	int	Идентификатор (ID) с автоинкрементом
type_id	int	Идентификатор (ID) без автоинкремента (для внешних ключей)
type_str	varchar ()	Символьный тип данных
type_bool	bit	Логический тип данных
type_date	datetime	Дата и время

Сводные данные по информационной модели представлены в таблице 3.2.

Таблица 3.2. Сводная таблица информационной модели

Сущность	Атрибут	Значение	Тип данных
1. Справочник структурных подразделений (spStruct)	StructID	идентификатор структурного подразделения	Уникальный идентификатор
	Struct	наименование структурного подразделения	Символьный(100)
	Code	внутренний код подразделения	Символьный(10)
	Gr	признак группы	Логический
	Is_hide	признак удаленной записи	Логический
	User_modif	информация об изменении записи	Символьный(50)
2. Справочник автоколонн (spAutokolonna)	AutokolonnaID	идентификатор автоколонны	Уникальный идентификатор
	StructID	идентификатор структурного подразделения, к которому относится автоколонна (вн. ключ)	Уникальный идентификатор
	Autokolonna	наименование автоколонны	Символьный(100)
	Is_hide	признак удаленной записи	Логический
	User_modif	информация об изменении записи	Символьный(50)
3. Справочник автомобилей (spAutomob)	AutomobID	идентификатор автомобиля	Уникальный идентификатор
	AutokolonnaID	идентификатор автоколонны, к которой относится автомобиль (вн. ключ)	Уникальный идентификатор
	StructID	идентификатор структурного подразделения, к которому относится автоколонна (вн. ключ)	Уникальный идентификатор
	MarkaID	идентификатор марки автомобиля (вн. ключ)	Уникальный идентификатор
	FirmID	идентификатор контрагента (вн. ключ)	Уникальный идентификатор
	GosNomer	государственный номер автомобиля	Символьный(10)
	dSpisan	дата списания автомобиля	Дата / Время
	dProdan	дата продажи автомобиля	Дата / Время
	is_Spisan	признак списания автомобиля	Логический
	is_Prodan	признак продажи автомобиля	Логический
	SposobProved	способ проведения ТО	Символьный(20)
	Is_hide	признак удаленной записи	Логический
	User_modif	информация об изменении записи	Символьный(50)
4. Справочник марок автомобилей (spMarka)	MarkaID	идентификатор марки	Уникальный идентификатор
	Marka	наименование марки	Символьный(100)
	Is_hide	признак удаленной записи	Логический
	User_modif	информация об изменении записи	Символьный(50)
5. Справочник контрагентов (spFirm)	FirmID	идентификатор контрагента	Уникальный идентификатор
	Firm	наименование контрагента	Символьный(100)
	Address	адрес контрагента	Символьный(100)
	INN	ИНН контрагента	Символьный(15)
	Firm_kr	краткое наименование контрагента	Символьный(20)
	Is_hide	признак удаленной записи	Логический
	User_modif	информация об изменении записи	Символьный(50)
6. Справочник подрядных организаций, проводящих ТО (spTOPodryad)	TOPodryadID	идентификатор подрядной организации	Уникальный идентификатор
	StructID	идентификатор структурного подразделения, с которым работает подрядная организация (вн. ключ)	Уникальный идентификатор
	FirmID	идентификатор контрагента (внешний ключ)	Уникальный идентификатор
	MarkaID	идентификатор марки автомобиля (вн. ключ)	Уникальный идентификатор
	Is_default	признак, указывающий, что данная организация используется по умолчанию при проведении ТО	Логический
	Is_hide	признак удаленной записи	Логический
	User_modif	информация об изменении записи	Символьный(50)
7. Справочник цен подрядных организаций (spTOPodryadCe	TOPodryadCenaI D	идентификатор стоимости работы подрядной организации	Уникальный идентификатор
	TOPodryadID	идентификатор подрядной	Уникальный
na)		организации (вн. ключ)	идентификатор
	Bdate	дата начала действия цены	Дата / Время
	Cena	цена за час работы	Символьный(20)
	User_modif	информация об изменении записи	Символьный(50)
8. Справочник типов ТО (spTipTO)	TipTOID	идентификатор типа ТО	Уникальный идентификатор
	TipTO	наименование типа ТО	Символьный(20)
	NormProbeg	норма пробега до ТО	Символьный(20)
	NormChasov	норма наработки моточасов до ТО	Символьный(20)
	Is_hide	признак удаленной записи	Логический
	User_modif	информация об изменении записи	Символьный(50)
9. Периодичность и нормы проведения ТО (spAutomobGrT O)	AutomobGrTOID	идентификатор	Уникальный идентификатор
	AutomobID	идентификатор автомобиля (вн. ключ)	Уникальный идентификатор
	TipTOID	идентификатор типа ТО (вн. ключ)	Уникальный идентификатор
	NormProbeg	норма пробега до ТО	Символьный(20)
	NormChasov	норма наработки моточасов до ТО	Символьный(20)
	Is_ProbegTO	признак, указывающий, что пробег или наработка считаются от последнего проведенного ТО	Логический
	Is_hide	признак удаленной записи	Логический
	User_modif	информация об изменении записи	Символьный(50)
10. Графики ТО (spAutoRemontO perGTO)	AutoRemontOper GTOID	идентификатор строки графика ТО	Уникальный идентификатор
	AutomobID	идентификатор автомобиля (вн. ключ)	Уникальный идентификатор
	TipGrTO	тип графика ТО	Символьный(20)
	StatGrTO	статус графика ТО	Символьный(20)
	KvMes	квартал / месяц графика ТО	Символьный(20)
	God	год графика ТО	Символьный(4)
	Is_TOGBO	признак проведения ТО для газобаллонного оборудования	Логический
11. Графики проведения ТО. Даты проведения ТО (spAutoRemontO perGTODat)	AutoRemontOper GTODatID	идентификатор даты проведения ТО	Уникальный идентификатор
	AutoRemontOper GTOID	идентификатор строки графика ТО (вн. ключ)	Уникальный идентификатор
	TipTOID	идентификатор проводимого типа ТО (вн. ключ)	Уникальный идентификатор
	Dat	дата проведения ТО	Дата / Время
	SposobProved	способ проведения ТО	Символьный(20)
	Summa	сумма стоимости материалов	Символьный(20)
		ТО
	SummaR	сумма стоимости работ ТО	Символьный(20)
	Norma	сумма количества нормированного времени на выполнение работ ТО	Символьный(20)
12. Шаблоны ТО (spMarkaShablon GTO)	MarkaShablonGT OID	идентификатор шаблона ТО	Уникальный идентификатор
	TipTOID	идентификатор проводимого типа ТО (вн. ключ)	Уникальный идентификатор
	MarkaID	идентификатор марки автомобиля (вн. ключ)	Уникальный идентификатор
	NormProbeg	норма пробега до ТО	Символьный(20)
	NornChasov	норма наработки моточасов до ТО	Символьный(20)
	Is_hide	признак удаленной записи	Логический
	User_modif	информация об изменении записи	Символьный(50)
13. Ремонтный лист (spAutoRemontR emList)	AutoRemontRem ListID	идентификатор ремонтного листа	Уникальный идентификатор
	AutomobID	идентификатор автомобиля (вн. ключ)	Уникальный идентификатор
	MarkaID	идентификатор марки автомобиля (вн. ключ)	Уникальный идентификатор
	FirmID	идентификатор контрагента (вн. ключ)	Уникальный идентификатор
	TipTOID	идентификатор проводимого типа ТО (вн. ключ)	Уникальный идентификатор
	AutokolonnaID	идентификатор автоколонны, к которой относится автомобиль (вн. ключ)	Уникальный идентификатор
	Bdat	дата начала проведения ремонта	Дата / Время
	Edat	дата окончания проведения ремонта	Дата / Время
	Nomer	номер ремонтного листа	Символьный(20)
	User_modif	информация об изменении записи	Символьный(50)
14. Работы ремонтного листа (spAutoRemontR emListRab)	AutoRemontRem ListRabID	идентификатор работы ремонтного листа	Уникальный идентификатор
	AutoRemontRem ListID	идентификатор ремонтного листа (вн. ключ)	Уникальный идентификатор
	VidRemRabID	идентификатор вида ремонтной работы (вн. ключ)	Уникальный идентификатор
	VremyaVipoln	время выполнения работы	Символьный(20)
	User_modif	информация об изменении записи	Символьный(50)
15. Материалы ремонтного листа (spAutoRemontR	AutoRemontRem ListDetalID	идентификатор материала ремонтного листа	Уникальный идентификатор
	AutoRemontRem ListRabID	идентификатор работы ремонтного листа (вн. ключ)	Уникальный идентификатор
emListDetal)	AutoRemontRem ListID	идентификатор ремонтного листа (вн. ключ)	Уникальный идентификатор
	TmID	идентификатор используемого материала (вн. ключ)	Уникальный идентификатор
	Kolust	количество используемого материала	Символьный(20)
	User_modif	информация об изменении записи	Символьный(50)
16. Справочник технологически х карт (spTechCard)	TechCardID	идентификатор технологической карты	Уникальный идентификатор
	TipTOID	идентификатор проводимого типа ТО (вн. ключ)	Уникальный идентификатор
	MarkaID	идентификатор марки автомобиля (вн. ключ)	Уникальный идентификатор
	Name	наименование технологической карты	Символьный(100)
	Bdate	дата начала действия технологической карты	Дата / Время
	SposobProved	способ проведения ТО	Символьный(20)
	Is_hide	признак удаленной записи	Логический
	User_modif	информация об изменении записи	Символьный(50)
17. Справочник видов ремонтных работ (spVidRemRab)	VidRemRabID	идентификатор вида ремонтной работы	Уникальный идентификатор
	VidRemRabPID	идентификатор родительской сущности (вн. ключ)	Уникальный идентификатор
	VidRemRab	наименование вида ремонтной работы	Символьный(20)
	Gr	признак группы	Логический
	NormaTrud	норма времени на выполнение работы	Символьный(20)
	Is_hide	признак удаленной записи	Логический
	User_modif	информация об изменении записи	Символьный(50)
18. Работы технологически х карт (spTechCardVid RemRab)	TechCardVidRem RabID	идентификатор работы технологической карты	Уникальный идентификатор
	TechCardID	идентификатор технологической карты (вн. ключ)	Уникальный идентификатор
	VidRemRabID	идентификатор вида ремонтной работы (вн. ключ)	Уникальный идентификатор
	Norma	норма времени на выполнение работы	Символьный(20)
	User_modif	информация об изменении записи	Символьный(50)
19. Справочник материалов (spTm)	TmID	идентификатор материала	Уникальный идентификатор
	TmPID	идентификатор родительской сущности (вн. ключ)	Уникальный идентификатор
	Tm	наименование материала	Символьный(20)
	Edizm	единица измерения	Символьный(20)
	Gr	признак группы	Логический
	Fullname	полное наименование материала	Символьный(100)
	Fullkod	полный код материала	Символьный(20)
	Tm_kr	краткое наименование материала	Символьный(10)
	Nnom	номенклатурный номер	Символьный(20)
	Nkat	номер по каталогу	Символьный(20)
	Is_hide	признак удаленной записи	Логический
	User_modif	информация об изменении записи	Символьный(50)
20. Материалы технологически х карт (spTechCardTm)	TechCardTmID	идентификатор материала технологической карты	Уникальный идентификатор
	TechCardID	идентификатор технологической карты (вн. ключ)	Уникальный идентификатор
	TmID	идентификатор материала (вн. ключ)	Уникальный идентификатор
	Kol	количество материала	Символьный(20)
	User_modif	информация об изменении записи	Символьный(50)
21. Справочник цен материалов (spTmCena)	TmCenaID	идентификатор цены материала	Уникальный идентификатор
	TmID	идентификатор материала (вн. ключ)	Уникальный идентификатор
	Cena	цена за единицу материала	Символьный(20)
	Dat	дата начала действия цены	Дата / Время
	Is_hide	признак удаленной записи	Логический
	User_modif	информация об изменении записи	Символьный(50)

Построенная физическая модель хранения данных учитывает реализацию с помощью СУБД Microsoft SQL Server 2012.



3.2 Программное обеспечение модуля «Техническое обслуживание и ремонт» ИУС SIKE. Autopark

модуль информационный архитектура программный

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

• подсистема хранения данных;

• подсистема формирования отчетности;

• подсистема, производящая необходимые расчеты и вычисления.

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

• справочной и нормативной информации, используемой в процессе работы;

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

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

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

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

В процессе проектирования данной АИС - модуля «ТОиР» - использовались различные CASE-средства. MSVisio - при построении функциональной модели в нотации eEPC, а также в процесее построении диаграммы причинно-следственных связей (диаграммы Исикавы). Allfusion Process Modeler - при построении функциональной модели в нотациях IDEF0 и DFD. При построении вариантов использования модуля использовалось такое программное средство как Rational Rose - диаграмма прецедентов (UseCase).

При разработке модели данных (логической и физической информационной модели) использовалось CASE-средство Allfusion Erwin Data Modeler (IDEF1X).

Сам модуль «Техническое обслуживание и ремонт» реализован с помощью СУБД - Microsoft SQL Server 2012, пакета программ OpenOffice, операционной среды - Windows 7, а также интегрированной среды разработки ПО - Borland Delphi.

Данные получаемые в ходе работы с модулем, хранятся и обрабатываются при помощи Microsoft SQL Server 2012. В данной СУБД в качестве основного языка запросов используется Transact-SQL.

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

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

3.3 Технологическое обеспечение модуля «Техническое обслуживание и ремонт» ИУС SIKE. Autopark

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

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

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

• выбор критериев и типа отчётности;

• просмотр, редактирование, сохранение, удаление, печать отчётности;

• просмотр справочной информации;

• поиск необходимой информации по запросам;

• рассылка результатов отчетности получателям (вышестоящим руководителям).

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

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

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

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

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

3.4 Проведение мероприятий по сопровождению модуля «Техническое обслуживание и ремонт» ИУС SIKE. Autopark

В соответствии с ГОСТ 34-601.90. «ИТ. Комплекс стандартов на АС. АС. Стадии создания» Сопровождение автоматизированной информационной системы является последней стадией создания АС.

Согласно ГОСТу процесс сопровождения делится на два этапа: ? выполнение работ в соответствии с гарантийными обязательствами; ? послегарантийное обслуживание.

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

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

Таким образом, основной целью сопровождения АИС является корректировка системы и повышение эффективности ее работы.

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

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

1. Консультации по вопросам работы с модулем «Техническое обслуживание и ремонт» ИУС SIKE. Autopark.

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

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

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

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

Компания SIKE обязуется в течение 72 часов с момента поступления заявки от Заказчика дистанционно восстановить работоспособность используемого программного средства. При необходимости на объекте Заказчика.

3. Осуществление дополнительных услуг:

• установка новых версий Программных компонентов (ПК) силами Исполнителя на объекте Заказчика или дистанционно;

• оптимизация функциональных возможностей программных

компонентов по требованиям Заказчика;

• восстановление потерянной информации в необходимом объеме, в случаях невозможности восстановления силами сотрудников Заказчика;

• консультации пользователей ПК по ликвидации последствий некорректных или ошибочных действий пользователей;

• восстановление ПК, разрушенных в результате технических сбоев и некорректных действий пользователей;

• восстановление работоспособности ПК, прерванной в результате некорректных действий пользователей;

• выявление и удовлетворение эргономических пожеланий

пользователей;

• восстановление работоспособности ПК, прерванной в результате сбоев в работе оборудования.

4. Выезды к Заказчику консультантов Исполнителя.

Выезд для решения срочных проблем, возникших при эксплуатации программного средства при невозможности их дистанционного решения, осуществляется в экстренном режиме (первым поездом). Перечень Услуг, оказываемых Исполнителем Заказчику на выезде, указан в п. 3.

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

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

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

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

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



4. Оценка экономической эффективности разработки и реализации модуля «техническое обслуживание и ремонт» ИУС SIKE. Autopark

4.1 Расчет экономических инвестиций в модуль «Техническое обслуживание и ремонт» ИУС SIKE. Autopark

Для начала определим ресурсы, участвовавшие в проекте разработки модуля «ТОиР».

В процессе разработки модуля приняли участие 9 специалистов. Также для разработки было приобретено программное обеспечение фирмы Autosoft («Автокаталог» и «Нормы времени»). На рисунке 4.1 представлены данные об использованных ресурсах и затратах на их использование.

Рисунок 4.1 Ресурсы проекта разработки модуля «ТОиР».

Для расчета продолжительности и стоимости разработки модуля на основе стандарта ГОСТ 34.601-90 «Информационная технология. Комплекс стандартов на автоматизированные системы. Автоматизированные системы.

Стадии создания» был разработан план-график (Рисунок 4.2):



Рисунок 4.2. План-график проекта разработки модуля «ТОиР»

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

Таблица 4.1. Затраты по статьям

Статья затрат	Затраты
Формирование требований к модулю	14 000 руб.
Разработка концепции модуля	30 800 руб.
Техническое задание на модуль	28 000 руб.
Технический проект	25 200 руб.
Рабочий проект	224 050 руб.
Ввод в действие	148 750 руб.

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



Рисунок 4.3. Диаграмма распределения затрат на разработку

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

Ниже представлен график использования ресурсов (Рисунок 4.4), на котором изображены трудозатраты каждого члена рабочей группы проекта на выполнение отведенных ему задач. Также на графике изображен и объем денежных затрат на каждого конкретного сотрудника в зависимости от его загруженности во время проекта.



Размещено на http://www.allbest.ru/

2

Размещено на http://www.allbest.ru/

Рисунок 4.4. Использование ресурсов в процессе разработки модуля «ТОиР»

Таким образом, согласно представленному план-графику, разработка модуля «Техническое обслуживание и ремонт» обошлась компании SIKE в 470 800 руб. и продолжалась на протяжении 111 рабочих дней.

4.2 Экономический эффект от реализации модуля «Техническое обслуживание и ремонт» ИУС SIKE. Autopark

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

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

• Конкурентоспособность реализуемого продукта.

• Использование ресурсов (важно, предотвратить возможный дефицит ресурсов, задействованных в изготовлении других программных продуктов).

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

1. Совокупный объем инвестиционных затрат на разработку.

2. Потери от снятия с производства других программных продуктов.

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

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

Рассмотрим данные показатели применительно к разработке компанией SIKE модуля «Техническое обслуживание и ремонт».

Исходя из представленного в параграфе 4.1 план-графика разработки, совокупный объем инвестиционных затрат на разработку модуля составляет - 470 800 рублей.

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

Использование ресурсов - оптимизировано. Все работы по разработке модуля «ТОиР» проводились согласно план-графику. Каждый член команды проекта занимался отведенной ему задачей в рамках выделенного времени. Все работы по другим проектам, в которых участвовали члены команды, производились во время, отведенное соответствующими план-графиками, не противореча выполнению данного план-графика (см. рисунок 4.2).

Окупаемость программного продукта - в течение года после выпуска модуля. Компания SIKE имеет предварительные договоренности с 10 предприятиями о покупке ими системы SIKE. Autopark после включения в ее состав нового модуля «ТОиР». С учетом стоимости системы на данный момент времени и при выполнении указанных договоренностей, компания SIKE возвратит около 90% от общей суммы затрат на разработку модуля (420 000 рублей). Оставшиеся 10% будут оплачены за счет резервных фондов компании SIKE, а также прибыли от реализации других программных продуктов. Окупаемость этих средств будет обеспечена реализацией системы SIKE. Autopark двум предприятиям в течение года после выпуска обновленной конфигурации системы.

Конкурентоспособность продукта

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

Программное решение компании SIKE - модуль «Техническое обслуживание и ремонт» в составе ИУС SIKE. Autopark воплощает в себе лучшие качества подобных систем. Модуль включает максимально необходимую функциональность в области автоматизации ТО и ремонта автотранспорта, сопоставимую лишь с крупными ERP-системами.

Стоимость решения ИУС SIKE. Autopark до включения в его конфигурацию модуля «Техническое обслуживание и ремонт» составляла 42 000 рублей. При этом стоимость системы не зависела от количества рабочих мест пользователей системы и являлась единовременной (отсутствует ежегодная оплата лицензии на пользование системой). После включения в типовую конфигурацию системы модуля «ТОиР», цена системы осталась неизменной, что позволяет системе SIKE. Autopark удерживать равновесие на рынке, оставаясь приблизительно в одной ценовой категории с наиболее дешевыми решениями, но при этом предлагая большие функциональные возможности (см. рисунок 4.5).

Рисунок 4.5. Сравнение цен программных продуктов автоматизации автопарка (ТО и ремонта)

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

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

В рамках данной главы было проведено технико-экономическое обоснование разработки модуля «Техническое обслуживание и ремонт» ИУС.SIKE. Autopark.

Для выполнения этой задачи был произведен расчет инвестиций вложенных в разработку модуля «ТОиР». Расчет производился на основании план-графика работ, входящих в проект по разработке модуля, и распределения ресурсов по видам работ (расчет трудозатрат ресурсов). Стоимость разработки модуля «Техническое обслуживание и ремонт», проходившей с 2 сентября 2013 года по 1 февраля 2014 года (111 рабочих дней), составила 470 800 рублей.

На основании произведенного расчета была проведена оценка экономической эффективности реализации модуля. Подробно рассмотрены все факторы, оказавшие влияние на решение компании разрабатывать модуль «ТОиР». Приведены экономические показатели целесообразности разработки и реализации данного модуля в составе типового решения ИУС SIKE. Autopark. Доказана конкурентоспособность системы на российском рынке программного обеспечения.



Заключение<...