Разработка информационной системы "Автомастерская"

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

Министерство науки и высшего образования Российской Федерации

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

высшего образования

«Северо-Восточный федеральный университет имени М.К. Аммосова»

Институт математики и информатики

Кафедра математической экономики и прикладной информатики

КУРСОВАЯ работа

по дисциплине “Проектный практикум”

на тему:

Разработка информационной системы “Автомастерская”

Направление подготовки: 09.09.03 Прикладная информатика

Профиль: Прикладная информатика в экономике

Выполнил(а): студент(ка) 4 курса группы ПИЭ-20 ИМИ СВФУ

И.И. Иванов

Якутск 2023



СОДЕРЖАНИЕ

Введение

1. ТЕОРЕТИЧЕСКИЕ ОСНОВЫ РАЗРАБОТКИ ИНФОРМАЦИОННЫХ СИСТЕМ

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

1.2 Требования к ИС

1.3 Методы разработки информационных систем

2. ПОСТАНОВКА ЗАДАЧИ И МОДЕЛЬ ИС

2.1 Требования к разработке ИС

2.2 Описание жизненного цикла ИС

2.3 Управление проектом

2.4 Проектирование системы и процессов на языке UML

3. ОПИСАНИЕ РАЗРАБОТАННОЙ ИНФОРМАЦИОННОЙ СИСТЕМЫ

3.1 Аттестация требований и тестирование

3.2 Руководство пользователя

ЗАКЛЮЧЕНИЕ

СПИСОК ИСПОЛЬЗОВАННОЙ ЛИТЕРАТУРЫ



ВВЕДЕНИЕ

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

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

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



1.ТЕОРЕТИЧЕСКИЕ ОСНОВЫ РАЗРАБОТКИ ИНФОРМАЦИОННЫХ СИСТЕМ

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

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

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

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

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

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

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

Информационная система определяется следующими свойствами:

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

информационная система является динамичной и развивающейся;

при построении информационной системы необходимо использовать системный подход;

выходной продукцией информационной системы является информация, на основе которой принимаются решения;

информационную систему следует воспринимать как человекокомпьютерную систему обработки информации.

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

ввод информации из внешних или внутренних источников;

обработка входной информации и представление ее в удобном виде;

вывод информации для представления потребителям или передачи в другую систему;

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

Рисунок 1- Процессы в информационной системе

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

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

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

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

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

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

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

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

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

1.2 Требования к ИС

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

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

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

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

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

1) анализ технической осуществимости создания системы;

2) формирование и анализ требований;

3) специфицирование требований и создание соответствующей документации;

4) аттестация этих требований.

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

Рисунок 2 - Процесс разработки требований

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

Следующим этапом процесса разработки требований является формирование (определение) и анализ требований.

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

Рисунок 3 - Процесс формирования и анализа требований

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

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

2. Сбор требований. Это процесс взаимодействия с лицами, формирующими требования. Во время этого процесса продолжается анализ предметной области.

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

4. Разрешение противоречий. Без сомнения, требования многочисленных лиц, занятых в процессе формирования требований, будут противоречивыми. На этом этапе определяются и разрешаются противоречия различного рода.

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

6. Проверка требований. На этом этапе определяется их полнота, последовательность и непротиворечивость.

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

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

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

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

Наиболее эффективным подходом к анализу таких систем является использование внешних опорных точек зрения. На основе этого подхода разработан метод VORD (Viewpoint-Oriented Requirements Definition -- определение требований на основе точек зрения) для формирования и анализа требований.

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

1.3 Методы разработки информационных систем

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

ERP (Enterprise Resource Planning) - система планирования (управления) ресурсами предприятия.

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

ECM (Enterprise Content Management) - это стратегическая инфраструктура и техническая архитектура для поддержки единого жизненного цикла неструктурированной информации (контента) различных типов и форматов.

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

HRM (Human Resource Management) - область знаний и практической деятельности, направленная на своевременное обеспечение организации персоналом и оптимальное его использование.

EAM (Enterprise Asset Management) - это информационная система, предназначенная в основном для автоматизации процессов, связанных с техническим обслуживанием оборудования, его ремонтом, а также послепродажным обслуживанием этого оборудования.

EDMS (Electronic Document Management) - система управления документами предприятия.

Workflow (Business Process Management (BPM)) - система, отвечающая за документооборот предприятия в комплексе, начиная от простого поручения до конечных маршрутов и версий используемых документов.

Collaboration - система, отвечающая за электронное взаимодействие людей, но не формализованное, как workflow, и не просто «архив», как EDMS.

ERP-система может быть использована в нескольких направлениях:

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

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

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

Продажи:

управление контактами;

работа с клиентами;

ввод заказов покупателей;

создание коммерческих предложений;

Управление продажами:

анализ «трубы продаж» («воронки продаж»);

анализ цикла продаж;

региональный анализ;

отчетность по продажам (запланированная и произвольная);

Регистрация продаж по телефону (работа с покупателем по телефону и во время личного общения):

создание и распределение списка покупателей;

автоматический набор номера покупателя;

регистрация звонков (в автоматическом режиме, при наличии регистратора звонков);

регистрация заказов покупателей;

Органайзер:

календарь и планирование (как для группы, так и для каждого отдельного пользователя);

e-mail;

Поддержка и обслуживание покупателей (пользователей, клиентов):

регистрация обращений покупателей;

переадресация обращений;

движение заявок (заказов) покупателя внутри компании;

отчетность по заказам покупателя (клиента);

информация по запросам (заказам, покупкам) клиента;

управление гарантийным/постгарантийным и коммерческим сервисным обслуживанием;

Маркетинг:

маркетинговые кампании;

управление возможными заказами;

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

Отчеты:

для руководящего состава;

для среднего звена;

для всех остальных;

Интеграция с ERP:

получение/отправка данных через Интернет;

с внешними базами данных (БД);

сделки через Интернет;

Синхронизация данных:

с мобильными пользователями и портативными устройствами;

синхронизация с другими БД (внутри компании) и серверами приложений.

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

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

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

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

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

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

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

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



2.ПОСТАНОВКА ЗАДАЧИ И МОДЕЛЬ ИС

2.1 Требования к разработке ИС

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

Опорные точки зрения:

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

Клиент	Администратор	Консультант
Запись предыдущих посещений автосервиса	Доступ к базе данных	Доступ к каталогу услуг
Просмотр каталога	Переопределение цен	Оформление заказа клиенту
Выбор услуги	Печать чека	Печать чека
Бронирование даты		Занесение клиента в базу данных
		Заполнение истории посещений клиента

Информационная модель системы:

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

Рисунок 4 - Иерархия точек зрения

Аттестация требований.

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

Аттестация требований:

1) Просмотр каталога

Два раза щелкнуть на вкладку «Каталог».

2) Переопределение цен

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

3) Занесение клиента в базу данных

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

4) Заполение истории поещений клиента

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

Проверка на непротиворечивость прошла успешно.

Проверка на выполнимость прошла успешно.

Проверка на полноту прошла успешно.

Рисунок 5 - Информационная модель

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

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

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

Техническое задание к программе ИС "Автомастерская"

Содержание

1. Введение информационный данные автомастерская

1.1. Наименование программы

1.2. Назначение и область применения

2. Требования к программе

2.1. Требования к функциональным характеристикам

2.2. Требования к надежности

2.2.1. Требования к обеспечению надежного функционирования программы

2.2.2. Время восстановления после отказа

2.2.3. Отказы из-за некорректных действий оператора

3. Условия эксплуатации

3.1. Климатические условия эксплуатации

3.2. Требования к квалификации и численности персонала

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

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

3.4.1. Требования к информационным структурам и методам решения

3.4.2. Требования к исходным кодам и языкам программирования

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

3.4.4. Требования к защите информации и программ

3.5. Специальные требования

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

4.1. Предварительный состав программной документации

5. Технико-экономические показатели

5.1. Экономические преимущества разработки

6. Стадии и этапы разработки

6.1. Стадии разработки

6.2. Этапы разработки

6.3. Содержание работ по этапам

7. Порядок контроля и приемки

7.1. Виды испытаний

7.2. Общие требования к приемке работы

Введение

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

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

1.1. Наименование программы

Наименование программы: ИС "Автомастерская"

1.2. Назначение и область применения

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

2. Требования к программе

2.1. Требования к функциональным характеристикам

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

Регистрация заказа:

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

Учет компетенций сотрудников:

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

Формирование счетов:

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

Учет компетенций сотрудников:

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

2.2. Требования к надежности

2.2.1 Требования к обеспечению надежного функционирования программы

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

а) организацией бесперебойного питания технических средств;

б) использованием лицензионного программного обеспечения;

в) регулярным выполнением рекомендаций Министерства труда и социального развития РФ, изложенных в Постановлении от 23 июля 1998 г. об утверждении межотраслевых типовых норм времени на работы по сервисному обслуживанию ПЭВМ и оргтехники и сопровождению программных средств»;

г) регулярным выполнением требований ГОСТ 51188-98. Защита информации. Испытания программных средств на наличие компьютерных вирусов

2.2.2. Время восстановления после отказа

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

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

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

2.2.3. Отказы из-за некоректных действий оператора

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

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

3. Условия эксплуатации

3.1. Климатические условия эксплуатации

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

3.2. Требования к квалификации и численности персонала

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

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

а) задача поддержания работоспособности технических средств;

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

в) задача установки (инсталляции) программы.

г) задача создания резервных копий базы данных.

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

3.3.1. В состав технических средств должен входить IВМ-совместимый персональный компьютер (ПЭВМ), выполняющий роль сервера, включающий в себя:

3.3.1.1. процессор Pentium-2.0Hz, не менее;

3.3.1.2. оперативную память объемом, 256 Мбайт, не менее;

3.3.1.3. свободного пространства на жестком диске, 1 Гигабайт, не менее;

3.3.1.4. операционную систему Windows 2000 Server или Windows 2003;

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

3.4.1. Требования к информационным структурам и методам решения

База данных работает под управлением Microsoft SQL Server. Используется много поточный доступ к базе данных. Необходимо обеспечить одновременную работу с программой с той же базой, данной модулей экспорта внешних данных.

3.4.2. Требования к исходным кодам и языкам программирования

Дополнительные требования не предъявляются.

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

Системные программные средства, используемые программой, должны быть представлены лицензионной локализованной версией операционной системы Windows 2000 Server или Windows 2003 и Microsoft SQL Server 2000.

3.4.4. Требования к защите информации и программ

Требования к защите информации и программ не предъявляются.

3.5. Специальные требования

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

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

4.1. Предварительный состав программной документации

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

4.1.1. техническое задание;

4.1.2. программу и методики испытаний;

4.1.3. руководство оператора.

5. Технико-экономические показатели

5.1. Экономические преимущества разработки

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

6. Стадии и этапы разработки

6.1. Стадии разработки

Разработка должна быть проведена в три стадии:

1. разработка технического задания;

2. рабочее проектирование;

3. внедрение.

6.2. Этапы разработки

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

На стадии рабочего проектирования должны быть выполнены перечисленные ниже этапы работ:

1. разработка программы;

2. разработка программной документации;

3. испытания программы.

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

6.3. Содержание работ по этапам

На этапе разработки технического задания должны быть выполнены перечисленные ниже работы:

1. постановка задачи;

2. определение и уточнение требований к техническим средствам;

3. определение требований к программе;

4. определение стадий, этапов и сроков разработки программы и документации на неё;

5. согласование и утверждение технического задания.

На этапе разработки программы должна быть выполнена работа по программированию (кодированию) и отладке программы.

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

На этапе испытаний программы должны быть выполнены перечисленные ниже виды работ:

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

2. проведение приемо-сдаточных испытаний;

3. корректировка программы и программной документации по результатам испытаний.

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

7. Порядок контроля и приемки

7.1. Виды испытаний

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

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

Ход проведения приемо-сдаточных испытаний Заказчик и Исполнитель документируют в Протоколе проведения испытаний

7.2. Общие требования к приемке работы

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

Описание жизненного цикла ИС

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

Структура:

Анализ требований

Стадия проектирования

Кодирование

Тестирование и откладка

Эксплуатация и сопровождение

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

Классификация:

Процессы планирования

Процессы разработки

Процессы тестирования

Процессы внедрения

Процессы сопровождения

Процессы управления

Область применения

1.1. Назначение

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

1.2. Область распространения

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

1.3. Адаптация настоящего стандарта

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

1.4. Соответствие

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

1.5. Ограничения

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

Управление проектом

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

Анализ требований (1.09.2023 - 14.09.2023)

- формирование инициативного предложения по проекту

- разработка бизнес-плана, ТЭО, концепции проекта

Стадия проектирования (14.09.2023 - 14.10.2023)

- планирование целей и границ проекта

- определение последовательности работ

- проектирование интерфейса

Кодирование (14.10.2023 - 1.12.2023)

- написание кода

Тестирование и откладка (1.12.2023 - 20.12.2023)

- поиск ошибок в программном коде

- исправление ошибок

Введение в эксплуатацию (20.12.2023 - 31.12.2023)

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

- постепенное накопление информации

Сопровождение (31.12.2023 - …)

- последующая техническая поддержка

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

Руководитель проекта	Иванов Иван Иванович
Проектировщик	Алексеев Алексей Алексеевич Соболев Иван Олегович
Разработчик	Ядреев Артем Семенович Иванов Алексей Иванович
Тестировщик	Алексеев Иван Алексеевич
Техническая поддержка	Сидоров Олег Иванович

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

Рисунок 6 - Диаграмма распределения работников и работ по этапам

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

Для конкретизации задач были определены следующие этапы:

Анализ требований -14 дней

Стадия проектирования

- планирование целей и границ проекта -15дней

- проектирование интерфейса - 15 дней

Кодирование - 45 дней

Тестирование и откладка

- поиск ошибок в программном коде - 14 дней

- исправление ошибок - 20 дней

Введение в эксплуатацию - 11 дней

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



Операция	A	B	C	D	E	F	G	Всего
Продолжительность	14	15	15	45	14	20	11	134

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

		Наиболее ранний возможный срок	Наиболее поздний допустимый срок
Работа i	Продолжительность di	Начала, ESi	Окончания, EFi	Начала, LSi	Окончания, LFi
Начало	0	0	0	0	0
A	14	0	14	0	14
B	15	14	29	14	29
C	15	14	29	14	29
D	45	29	74	29	74
E	14	74	88	74	88
F	20	74	94	74	94
G	11	94	105	94	105
Окончание	0	105	105	105	105



LF(G) = 95 LS(L) = 95-11 = 84

LF(F) = 84 LS(F) = 84-20 = 64

LF(E) = 78 LS(E) = 78-14 = 64

LF(D) = 64 LS(D) = 64-45 = 29

LF(C) = 29 LS(C) = 29-15 = 14

LF(B) = 29 LS(B) = 29-15 = 14

LF(A) = 14 LS(A) = 14-14 = 0

LF (начала) = LS (начала)

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

Рисунок 7 - План работ для выбранного сетевого графика

ПРОЕКТИРОВАНИЕ СИСТЕМЫ И ПРОЦЕССОВ НА ЯЗЫКЕ UML

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

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

Рисунок 8 - Диаграмма прецедентов

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

Рисунок 9 - Диаграмма деятельности

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

Рисунок 10 - Диаграмма последовательности

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

Рисунок 11 - Диаграмма классов

3. ОПИСАНИЕ РАЗРАБОТАННОЙ ИНФОРМАЦИОННОЙ СИСТЕМЫ

3.1 Аттестация требований и тестирование

На первом этапе решается вопрос о выборе некоторого подмножества множества

тестов, которое сможет найти наибольшее количество ошибок за наименьший

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

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

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

Чаще всего совокупность тщательно составленных функциональных тестов покрывает множество структурных тестов.

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

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

При функциональном тестировании выявляются следующие категории ошибок:

некорректность или отсутствие функций;

ошибки интерфейса;

ошибки в структурах данных;

ошибки машинных характеристик (нехватка памяти и др.);

ошибки инициализации и завершения. Техника тестирования ориентирована:

на сокращение необходимого количества тестовых вариантов;

на выявление классов ошибок, а не отдельных ошибок.

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

3.2 Руководство пользователя

Перед работой пользователя с ИС рекомендуется внимательно ознакомиться с настоящим руководством.

Документ подготовлен в соответствии с РД 50-34.698-90 - в части структуры и содержания документов, и в соответствии с ГОСТ 34.201-89 - в части наименования и обозначения документов.

1. Введение

1.1. Область применения

Требования настоящего документа применяются при:

предварительных комплексных испытаниях;

опытной эксплуатации;

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

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

1.2. Краткое описание возможностей

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

1.3. Уровень подготовки пользователя

Для эксплуатации ИС определены следующие роли:

Пользователь;

Консультант;

Администратор.

Пользователь ИС Автомастерская должен иметь опыт работы с ОС MS Windows (8/10/11), навык работы с Mozilla FireFox, Google Chrome, Safari для iOS, Microsoft Edge, Яндекс.Браузер с использованием настроек браузера по умолчанию (javascript, cookies и т.д. включено), а также обладать навыками работы с аналитическими приложениями.

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

1. Инструкция по установке ИС;

2. Руководство администратора ИC;

3. Руководство по техническому обслуживанию ИС;

4. Руководство пользователя ИС УНП.

2. Назначение и условия применения Автомастерская

Информационная система «Автомастерская» предоставляется для обеспечения эффективной работы одноименной компании. Основные функции ИС:

Графическое отображение статистики;

Организация данных о выполненных работах, истории обращений;

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

Управление доступом сотрудников и администрирование учётных записей.

3. Подготовка к работе

Для работы с ИАС КХД необходимо следующее программное обеспечение:

1. Компьютерное оборудование;

2. Браузер.

3.2. Порядок загрузки данных и программ

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

1. Необходимо зайти на сайт ИС Автомастерская;

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

3.3. Порядок проверки работоспособности

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

1. Необходимо зайти на сайт ИС Автомастерская;

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

4. Описание операций

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

Пользователь (User)

- Просмотр истории выполненных работ;

- Просмотр визуализации статистики.

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

Интерфейс выглядит так:

Рисунок 12 - Раздел «Главная»

Рисунок 13 - Раздел "Каталог"



ЗАКЛЮЧЕНИЕ

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

В процессе разработки были успешно применены принципы объектно-ориентированного проектирования, что обеспечило модульность и гибкость системы. Кроме того, создание комплекта UML-диаграмм и проведение тестирования позволили детально проработать структуру программы, выявить и устранить выявленные ошибки.

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

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

...