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

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

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

Федеральное агентство связи

Федеральное государственное бюджетное образовательное учреждение

высшего образования «Поволжский государственный университет телекоммуникаций и информатики»

Факультет Информационных систем и технологий

Направление (специальность) Информатика и вычислительная техника

Кафедра Информационных систем и технологий

ВЫПУСКНАЯ КВАЛИФИКАЦИОННАЯ РАБОТА

(БАКАЛАВРСКАЯ РАБОТА)

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

Разработал А.Ю. Ишматов

Самара 2017

Реферат

Название		Разработка информационной системы сервисного
		центра по ремонту электронной техники
Автор		Ишматов Антон Юрьевич
Научный		Тучкова Анна Сергеевна
Руководитель
Ключевые слова		Информационная система, проектирование,
		разработка, внедрение, тестирование
		Программного продукта
Дата публикации		2017
Библиографическое описание		Ишматов А. Ю. Разработка информационной
		системы сервисного центра по ремонту электр.
		техники[Текст]: дипломная работа/А. Ю.
		Ишматов. (ПГУТИ) Факультет информационных
		Систем и технологий. Кафедра ИСТ - Самара.
		2017. 68 с.
Аннотация		Объектом исследования ВКР являются OOO «Сервис», предметом исследования - информационная система центра по ремонту электронной техники. Была разработана и рекомендована ко внедрению ИС, позволяющая оптимизировать бизнес-процессы предприятия.

Введение

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

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

Целью разработки информационной системы «Учет работ по ремонту и обслуживанию компьютерной техники в сервисном центре» является автоматизация учета ремонтных работ и обслуживания компьютерной техники в сервисном центре.

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

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

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

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

В соответствии с поставленной целью необходимо решить следующие задачи:

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

рассмотрение классификации информационных систем;

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

разработка информационной системы сервисного центра;

анализ полученных результатов.

Объектом исследования является ООО «Сервис», основной вид деятельности которого - ремонт электронной техники и оборудования, а также заправки картриджей.

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

Теоретической основой для написания выпускной квалификационной работы составили труды отечественных авторов, таких как: Иванова О. В., Щавелёва Л. В., Горбань А. Н., Боровиков В. П., а также зарубежных авторов: Ф. Уоссерман, Паркер Д. Б., Кэнту М. и другие.

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

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

В первом разделе раскрываются теоретические принципы работы с проектированием ИС.

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

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

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

1. Теоретические основы разработки информационных систем

1.1 Понятие и классификации информационных систем

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

По масштабу (территориальная): одиночные; групповые; корпоративные.

По сфере применения: системы обработки транзакций (оперативная и пакетная обработка транзакций; информационно справочные системы (системы электронных документов, географические информационные системы); офисные ИС (системы автоматизации делопроизводства, управление документооборотом)

По способу организации: на основе архитектуры «файл - сервер»; на основе архитектуры «клиент-сервер»; на основе многоуровневой архитектуры; на основе технологий Интернет - Интранет.

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

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

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

Таблица 1.1

Компоненты информационных систем

Функциональные компоненты	Компоненты системы обработки данных	Организационные компоненты
Функциональные подсистемы	Информационное обеспечение	Новые организационные структуры формы
Функциональные задачи	Техническое обеспечение	Персонал
Модели и алгоритмы	Правовое обеспечение
	Программное обеспечение
	Лингвистическое обеспечение

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

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

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

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

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

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

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

Основным нормативным документом, регламентирующим состав процессов жизненного цикла, является международный стандарт ISO/IEC 12207 (ISO - международная организация по стандартизации; IEC - международная комиссия по эксплуатации).

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

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

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

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

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

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

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

В структурном анализе используются в основном две группы средств, иллюстрирующих функции, выполняемые системой и отношения между данными. Каждой группе средств соответствуют определенные виды моделей (диаграмм), наиболее распространенной является ERD (Entity-Relationship Diagrams) диаграммы "сущность-связь".

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

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

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

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

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

1.2 Понятие системы и конструкции в ИТ

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

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

Множество объектов конечное

Существуют связи между объектами

Из множества и связей может быть синтезирован объект

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

Если для конструкций отношение между объектом и его конструкцией называлось так: «конструкция объекта», то для обозначения отношения между объектом и его системой используется другой термин: «строение объекта». Например, строение человека связывает человека(о) с человеком(с). Кстати, интересно, почему нет термина «система объекта» по аналогии с термином «конструкцией объекта»?

Можно ли назвать системой объект, а не множество объектов? То есть можно ли применить термин система к объекту так же, как термин конструкция применить к объекту? Скорее всего, -- можно. Например, говорят, что система обладает эмерджентностью. Формально этот тезис переводится так: свойства объекта, строение которого представлено в виде исследуемой системы, отличны от свойств элементов этой системы. Поскольку в данном контексте объект назван системой, то объект тоже можно назвать системой.

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

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

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

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

Можно ли распространить на системы тезис о том, что любой объект может иметь разные структуры в зависимости от наблюдателя? Да, можно. Мы прекрасно знакомы с двумя разными парадигмами строения человека, которые порождают разные структуры: внутреннее строение и внешнее строение человека.

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

Кто определяет если ли у множества объектов эмеджентность, или ее нет? Например, пусть есть участки трубопровода. Конструкция из этих участков образует более крупный участок трубопровода. Этот участок обладает новыми свойствами? Если нет, то системная инженерия не сможет назвать конструкцию из участков трубопровода системой. Если же найдется субъект, который скажет, что новые свойства есть, то множество участков превратится в систему. То есть, решение о том, является ли множество объектов конструкцией, или не является, принимает субъект. Кто он? Кстати, аналогичная проблема есть в определении бизнес-процесса в той его части, где процесс, по словам автора определения, должен иметь цель. Получается, что один и тот же процесс в зависимости от того, кто на него смотрит, может быть процессом, а может и не быть.

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

Вернувшись к определению конструкции, можно задать вопрос: должна ли конструкция(о), обладать свойствами эмерджентности? Допустим, что должна. Тогда множество конструкций(к) - это подмножество множества систем(с). Если не должна, то множество конструкций(к) пересекается со множеством систем(с).

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

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

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

Множество может состоять из множеств объектов.

Объекты могут быть любой природы.

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

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

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

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

Однажды мне была поставлена задача смоделировать различные версии конструкции одного объекта. Версии существовали одновременно во времени и моделировали различные версии конструкторских решений. К тому же сами версии менялись во времени, потому что конструкторские решения эволюционировали с течением времени. Без введения понятия конструкция решить такую задачу было можно, но выглядело это очень странно. Похожая задача решалась мной при моделировании планов производства работ, которых одновременно было несколько версий: оптимистичный, пессимистичный и реальный. При этом план производства работ, в свою очередь, был частью другого плана производства работ. И таких этажей было 5. До ввода в модель объектов, моделирующих конструкции, моделирование выглядело так: множество связей «часть-целое», «раскрашенных» в разные цвета. «Красные» связи моделировали одну конструкцию объекта, «зеленые» -- другую. «Цветов» было много и существовала проблема стыковки разных цветов. Фактически, эти «цвета» моделировали различные точки зрения на конструкцию объекта, не называя это явно. То же приходилось делать со свойствами объекта, которому были переданы свойства конструкции: у нас были «красные» значения свойств и «зеленые». Так мы выходили из положения до введения понятия «конструкция».

1.3 Этапы жизненного цикла информационной системы

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

Основным нормативным документом, регламентирующим состав процессов ЖЦ ИС, является международный стандарт ISO/IEC 12207: 1995 «Information Technology - Software Life Cycle Processes» (ISO - International Organization for Standardization - Международная организация по стандартизации, IЕС - International Electrotechnical Commission - Международная комиссия по электротехнике). Структура ЖЦ по стандарту ISO/IEC 12207 базируется на трех группах процессов:

основные процессы ЖЦ ИС (приобретение, поставка, разработка, эксплуатация, сопровождение);

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

организационные процессы (управление проектами, создание инфраструктуры проекта, определение, оценка и улучшение самого ЖЦ, обучение).

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

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

Эти модели можно разделить на 3 основных группы:

Инженерный подход

С учетом специфики задачи

Современные технологии быстрой разработки

Теперь рассмотрим непосредственно существующие модели (подклассы) и оценим их преимущества и недостатки.

Модель кодирования и устранения ошибок

Совершенно простая модель, характерная для студентов ВУЗов. Именно по этой модели большинство студентов разрабатывают, ну скажем лабораторные работы.

Данная модель имеет следующий алгоритм:

Постановка задачи

Выполнение

Проверка результата

При необходимости переход к первому пункту

Модель явно устаревшая. Характерна для 1960-1970 гг., поэтому преимуществ перед следующими моделями в нашем обзоре практически не имеет, а недостатки на лицо. Относится к первой группе моделей.

Каскадная модель жизненного цикла программного обеспечения (водопад)

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

Рис. 1.1 - Каскадная модель жизненного цикла ИС

Преимущества:

Последовательное выполнение этапов проекта в строгом фиксированном порядке

Позволяет оценивать качество продукта на каждом этапе

Недостатки:

Отсутствие обратных связей между этапами

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

Относится к первой группе моделей.

Каскадная модель с промежуточным контролем (водоворот)

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

V модель (разработка через тестирование).

Данная модель имеет более приближенный к современным методам алгоритм, однако все еще имеет ряд недостатков. Является одной из основных практик экстремального программирования, представлена схемой (См. рис. 1.2).

Рис. 1.2 - V-модель жизненного цикла ИС

Модель на основе разработки прототипа

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

Прототипирование используется на ранних стадиях жизненного цикла программного обеспечения:

Прояснить не ясные требования (прототип UI)

Выбрать одно из ряда концептуальных решений (реализация сценариев)

Проанализировать осуществимость проекта

Классификация протопопов:

Горизонтальные и вертикальные

Одноразовые и эволюционные

Бумажные и раскадровки

Модель принадлежит второй группе.

Спиральная модель жизненного цикла программного обеспечения

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

Рис. 1.3 - Спиральная модель

Преимущества:

Быстрое получение результата

Повышение конкурентоспособности

Изменяющиеся требования -- не проблема

Недостатки:

Отсутствие регламентации стадий

Третьей группе принадлежат такие модели как экстремальное программирование (XP), SCRUM, инкрементальная модель (RUP).

2. Разработка задания для создаваемой ИС

2.1 Эффективность внедрения информационных систем

Первая и самая главная причина неэффективного внедрения новой ИС: некорректно поставленная цель для информационной системы.

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

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

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

Даже если предположить, что специалисты-информационщики знают, как следует изменить бизнес-процессы, у них все равно нет нужного административного ресурса, да и ожидаемый результат зависит, в первую очередь, не от программного обеспечения. Здесь явно путается следствие и причина. Допустим, есть предприятие А с информационной системой ABC. Предприятие работает стабильно, нет авралов, неразберихи, заказы выполняются в срок, есть планомерная деятельность отлаженного механизма. Можно сделать вывод, что все хорошо благодаря системе ABC, но это 100% не так. Наличие системы ABC у предприятия A, кончено же, вносит свой вклад в бизнес, но не является ключевым. Если руководство некоего предприятия Б решило внедрить у себя систему ABC в надежде, что после ее внедрения предприятие Б тоже будет работать так же, как A, его ждет сюрприз. Деньги будут потрачены, но ожидаемый эффект не наступит, т.к. методика работы на предприятии Б не изменится.

Эффективные цели.

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

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

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

Техническое задание.

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

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

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

Есть еще один вариант составления ТЗ: в нем декларируется конечная цель заказчика. И тут вы можете сразу заметить противоречия с предыдущем написанным текстом. Это случай составления проекта, в котором информационная система является только частью.

Следующим важным документом для успешного выполнения работ является план-график работ.

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

Запуск системы в работу. Запуску системы предшествует тестирование исполнителем системы на примерах заказчика. После получения положительных результатов начинается работа по реальному внедрению и запуску системы. Если опытная эксплуатация делается только на опытных примерах без участия рядовых исполнителей заказчика, без использования реальных задач, она не достигнет поставленной цели. Целью же является сбор замечаний, которые необходимо устранить для перевода в промышленную эксплуатацию. Данный этап правильнее было бы назвать расширенным тестированием с привлечением исполнителей заказчика. Реальная опытная эксплуатация начинается после внедрения системы при участии, как минимум, 50-70% процентах рабочих мест.

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

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

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

Тестирование с привлечением сотрудников заказчика на реальных примерах;

Опытная эксплуатация с немедленным устраняем возникающих проблем;

Промышленная эксплуатация.

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

2.2 Постановка задания для разрабатываемой ИС

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

Цели разработки информационной системы:

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

Возможность получать отчёты в разрезе тех или иных критериев поиска

Возможность быстрого поиска данных по заданным параметрам

Упрощение процессов работы с информацией

Техническое задание к ИС.

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

В Системе предлагается выделить следующие функциональные подсистемы:

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

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

подсистема формирования и визуализации отчетности, которая предназначена для формирования отчетности.

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

Система должна быть стабильна в работе.

Необходимо установленное антивирусное программное обеспечение.

Персональный компьютер должен иметь бесперебойное питание.

Требования к надежности технических средств и программного обеспечения:

в качестве аппаратных платформ должны использоваться средства с средней надежностью;

применение технических средств, соответствующих классу решаемых задач;

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

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

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

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

План-график работ:

01.03.2017 - согласование технического задания

20.03.2017 - проектирование схемы ИС, разработка даталогической модели данных

15.04.2017 - разработка ИС для сервисного центра

20.04.2017 - тестирование созданной информационной системы

3. Разработка информационной системы

3.1 Инфологическая и датологическая модели базы данных

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

Информационная модель данных предназначена для представления семантики предметной области в терминах субъективных средств описания - сущностей, атрибутов, идентификаторов сущностей, супертипов, подтипов и т.д. Элементы информационной модели данных предметной области являются входными данными для решения задачи проектирования базы данных - создания логической модели данных. (Information Modeling) - одна из методологий семейства IDEF. Применяется для построения информационной модели, которая представляет структуру информации, необходимой для поддержки функций производственной системы или среды. Метод IDEF1, разработанный Т. Рэмей основан на подходе П. Чена. Он позволяет построить модель данных, эквивалентную реляционной модели в третьей нормальной форме. В настоящее время на основе совершенствования методологии IDEF1 создана ее новая версия - методология IDEF1X. IDEF1X разработана с учетом таких требований, как простота изучения и возможность автоматизации. IDEF1X-диаграммы используются рядом распространённых CASE-средств (в частности, ERwin, Design/IDEF).

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

Таблица 3.1

Сущности предметной области

Имя	Определение
Клиент	Организации, оформившие договора на сервисное обслуживание компьютерной техники в компании «Сервис»
Техника	Компьютерная техника, подлежащая сервисному обслуживанию, согласно договору о сервисном обслуживании, либо по заявке клиента на проведение ремонта
Вид	Группы техники, разделенные по функциональным назначениям
Производитель	Официальные марки производителей компьютерной техники
Заказ	Факт выполнения сервисного обслуживания компьютерной техники
Работа	Перечень работ по обслуживанию компьютерной техники, предоставляемых компанией «Компьютерный мир»
Ремонт	Факт включения в заказ на техническое обслуживание компьютерной техники определенного вида работ
Материал	Расходные материалы, используемые для выполнения ремонта и сервисного обслуживания компьютерной техники
Расход	Факт использования, расходных материалов для выполнения ремонта и сервисного обслуживания компьютерной техники
Мастер	Сотрудники компании «Компьютерный мир», выполняющие ремонт и сервисное обслуживание компьютерной техники
Категория	Разновидности расходных материалов

Таким образом, средствами ERwin была спроектирована ER-диаграмма предметной области (См. рис. 3.2), которая отражает выделенные сущности предметной области и связи между ними.

Рис. 3.2 - ER-диаграмма предметной области

После определения атрибутов сущностей, выделения первичных и внешних ключей, и связей между сущностями была составлена IDEF1X-диаграмма КВ-уровня (См. рис. 3.3).

Рис. 3.3 - IDEF1X-диаграмма КВ-уровня

Описание атрибутов сущностей, с указанием владельцев сущностей, можно видеть также на рисунке 3.2.

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

Даталогическая модель создаваемой базы данных

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

информационная система сервисный центр

Рис. 3.4 - Даталогическая модель базы данных

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

3.2 Разработка справочников БД

С помощью ERwin Data Modeler, используя визуальные средства, была описана модель данных предметной области, на основании которой была автоматически сгенерирована схема данных для выбранной реляционной СУБД Access (См. рис. 3.5). Автоматически генерируются также триггеры, обеспечивающие ссылочную целостность БД.

Рис 3.5 - Схема данных Access

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

Для технического описания объектов базы данных представим построенные таблицы Access в форме конструктора (см. пример рис. 3.6, 3.7).

Рис. 3.6 - Таблица Access «Производитель»

Рис. 3.7 - Таблица Access «Клиент»

Дерево функций главного меню разработанной системы представлено схемой (См. рис. 3.8).

Рис. 3.8 - Дерево функций главного меню

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

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

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

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

Рис. 3.9 - Справочник «Клиенты»

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

Рис. 3.10 - Справочник «Сотрудники»

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

Рис. 3.11 - Справочник «Виды техники»

Аналогичным образом представлен справочник «Марки техники» (См. рис. 3.12).

Рис. 3.12 - Справочник «Марки техники»

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