Проектирование и разработка информационной системы сервисного центра по ремонту автомобилей. Часть 2

1  2  3

---

2.2 Разработка модели базы данных

 

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

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

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

Процесс создания инфологической модели включает в себя следующие этапы [14, 15]:

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

Логическим уровнем представления модели считается теоретический взгляд на данные, на нем данные представлены точно так же, как и в реальности. Логическую модель данных принято считать универсальной, и никак не связанной с определенной реализацией СУБД. Физическая модель данных, наоборот, находится в зависимости от определенной СУБД, фактически считаясь отображением системного каталога. В физической модели имеется информация обо всех объектах БД (базы данных). Так как не существует стандартов на объекты БД (к примеру, отсутствует стандарт на типы данных), физическая модель находится в зависимости от определенной реализации СУБД. Таким образом, одной и той же логической модели могут отвечать ряд различных физических моделей. Если в логической модели не имеет значения, каким именно типом данных располагает атрибут, то в физической модели считается важным описание всей информации об определенных физических объектах [15].

Инновационные объектно-ориентированные CASE-средства предоставляют возможность эффективного решения задач проектирования приложений. Среди подобных пакетов – Rational Rose, Together Control Center, BPWin, ERWin, Model Mart, Silverrun Business Process Modeller, Process Analyst.

Для инфологического проектирования БД избрано CASE‑средство Computer Associates ERwin.

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

Следовательно, в модели приведены сущности и реквизиты, показанные в приложении 1. Характеристика каждой таблицы и описание ее полей представлено в приложении 2.

 

2.3 Разработка структуры вычислительно-локальной сети

 

На рисунке 2.3 показана структурная схема технической архитектуры анализируемого предприятия [12].

Как рабочие станции применяются модель OLDI Office 110 с такой конфигурацией:

• процессор Intel® Celeron 430 (Conroe-L, 3.60 ГГц, FSB800MHz, 1024Kb L2,Socket 775);
• жёсткий диск 500Gb (SATA III);
• оперативная память DDR III 2Гб;
• сетевая карта 2×10/100/1000 Мбит/с;
• видеокарта интегрирована в чипсет iG31;
• звуковая карта 8-канальная;
• размеры 520 мм х 210 мм х 340 мм.

Рис. 2.2 Схема базы данных

Из всех серверов на предприятии применяются только сервер базы данных и файл–сервер. Как аппаратная основа серверов применяется Office Server TX 3000R15, имеющий такие технические характеристики:

• процессор Intel® Core™5 750 (Lynnfield, 3.32ГГц, 16Мб, LGA1156);
• чипсет Intel 3420;
• жёсткий диск 2000Gb (SATA III, 14400rpm, 64Mb);
• оперативная память DDR3 8192 Mb (pc-22120) 2666MHz;
• оптические накопители DVD±RW;
• видеокарта XGI® Z9s (64MB DDR2);
• сетевая карта 6х10/100/1000 Мбит/с;
• тип корпуса Full Tower.

Рис. 2.3 Схема технической архитектуры предприятия

Пользовательские сегменты и сервера посредством маршрутизатора 3Com13701-ME объединяются в сеть. Внутри сегментов пользователей как коммутаторы применяются 3COM Gigabit Switch 8 3CGSU08. Эти типы коммутаторов снабжены программными брандмауэрами. [53]

Телефонная сеть построена с применением АТС Panasonic KX-TEM824.

Как оконечные устройства применяются офисные телефоны Panasonic KX-T7710.

Как среда передачи данных применяется кабель витая пара 5 категории (100BASE-ТX) со скоростью передачи до 100 мбит/сек.

Каждая из рабочих станций комплектуется МФУ Xerox Phaser 3100MFP/Х.

На рисунке 2.4 показана наглядно программная архитектура ИС.

Все ПК снабжены стандартным пакетом ПО:

• ОС Windows 7 Pro х64;
• Браузер Mozilla Firefox;
• Пакет MS Office 2007;
• Avira AntiVir Premium Security Suite;
• Adobe Acrobat 9.0 Professional.

Рис. 2.4 Программная архитектура предприятия

Принимая во внимание специфику деятельности отделов, ПК предприятия обеспечиваются дополнительными программными обеспечениями (персональными пакетами ПО для отделов):

• Отдел IT: Radmin Viewer 3, Remote Administrator v2.2, Total Commander;
• Бухгалтерия: 1С Бухгалтерия: Версия 8.

 

3. Управление ресурсами и рисками проекта

3.1 Диаграмма Ганта проекта

 

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

Деятельность разработчика условно разделена на 4 роли: Главный разработчик, Разработчик БД, Разработчик интерфейса, Тестировщик. Лист задач представлен на Рисунке 3.1.

Рис.3.1 Лист задач

На основе данного листа задач построим диаграмму Гантта. Изображение диаграммы – Рисунок 3.2.

Рис. 3.2 Диаграмма Гантта

 

3.2 Риск-менеджмент

 

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

— стандарт не должен содержать жёстких нормативных критериев;

— при использовании стандарта не должно быть излишней бюрократической нагрузки;

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

— стандарт должен быть актуален и соответствовать современным требованиям к ИС.

Жизненный цикл проекта регламентируют ГОСТы серии 34. Но в настоящее время отдельные положения данных ГОСТов очень сильно устарели, к тому же, некоторые этапы из жизненного цикла регламентированы не в полной мере.

Другим стандартом считается международный стандарт ISO/IEC 12207:1995 «Information Technology — Software Life Cycle Processes». Данный стандарт больше подходит для описания жизненного цикла проекта, представленного в предоставленной работе, так как он ориентирован прежде всего на разработку ИС в рамках предприятия и даёт общие рекомендации для любого жизненного цикла, в тоже время позволяя определить его структуру и сформулировать процессы, действия и задачи в рамках каждого этапа.

Для предоставленного проекта выделены следующие стадии жизненного цикла:

— анализ;

— проектирование;

— внедрение;

— сопровождение.

Первая стадия «Анализ». Эта стадия начинается с подэтапа «Определение запросов к будущему сайту». Первой задачей является «Анализ бизнес-процессов предприятия «КАК ЕСТЬ»». Данную задачу выполняет менеджер отдела продаж, назначенный генеральным директором в качестве ответственного лица и IT специалист. В процессе выполнения задачи формирует структурно — функциональную диаграмму бизнес-процессов предприятия «КАК ЕСТЬ» в нотации IDEF0. По результатам выполненного анализа выбирается совокупность задач автоматизации. Данная задача выполняется IT специалистом. Завершающая задача подэтапа состоит в «Определении свойств сайта, которые необходимы для решения задачи». Задача решается менеджером отдела продаж и IT специалистом.

Следующим подэтапом в стадии «Анализ» считается определение функций будущего сайта и подбор стратегии автоматизации. В подэтапе участвуют менеджер отдела продаж, IT специалист.

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

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

— аргументация проектных решений по ПО;

— аргументация проектных решений по техническому обеспечению;

— аргументация проектных решений по ИО.

Целью данных задач является формирование необходимые требования к вышеперечисленным видам обеспечения ИС предприятия. Участником данного подэтапа является IT специалист.

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

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

— оценить риски проекта;

— разработать информационную модель будущей ИС;

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

— охарактеризовать входные и выходные данные, а также алгоритмы их расчёта;

— перечислить необходимое программное и техническое обеспечение для функционирования ИС;

—  охарактеризовать дерево функций, сценарии диалога, структуру базы данных проектируемой ИС;

— разработать пользовательские интерфейсы;

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

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

— установка локального сервера Apache;

— создание всех модулей ИС согласно ТЗ;

— разработка интерфейса на основе созданных модулей.

Все работы выполняет IT специалист предприятия. Конечным результатом данной стадии является готовая ИС.

Главной целью стадии Внедрения является размещение тестирование ИС. Ключевые стратегии введения системы представлены ниже.

Стратегия “Параллельное применение”. Параллельное применение — синхронно выполняются новая и старая технология решения задачи, итоги их подлежат сравнению. Ежели полученные результаты согласуются довольно-таки продолжительное время, то выполняется переход на новую технологию.

Достоинства системы:

— наименьший риск ошибок в виде новых технологий;

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

Недостатки системы:

— удвоение загрузки персонала;

— требуется удвоенные мощности серверов;

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

Стратегия “Скачок”. Скачок — старая технология действует до конкретного момента, потом осуществляется введение новой технологии, а после ее введения реализуется исключительно новая технология

Достоинства стратегии:

— минимальная продолжительность переходного периода;

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

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

Недостатки системы:

— большие риски несоответствия характеристик ИС требованиям компании;

— высокие запросы к действиям по планировании перехода на новую технологию;

Стратегия “Пилотный проект”. Данная стратегия – это стратегия скачка, применяемая к ограниченному количеству процессов, областью внедрения, как правило, является небольшой участок компании.

Достоинства системы:

— малый риск выбора неправильного решения, которое не приведёт к долгому простою всей компании;

— наличие возможности изменять планируемую технологию в ходе внедрения ИС на участке;

— отсутствуют двойные затраты на внедрение технологии.

Недостатки системы:

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

— необходимо одновременно управлять новой и старой ИС.

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

Достоинства системы:

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

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

Недостатки системы:

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

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

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

Во время этапа внедрения IT сотрудником предприятия производится:

— установка всех необходимых программных средств на сервер предприятия;

— проведение тестирования;

— устранение ошибок, выявленных в процессе тестирования.

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

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

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

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

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

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

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

Риски на подэтапе «Определение требований к ИС». Главная угроза на этом подэтапе заключается в недостаточном определении свойств ИС, которые необходимы для разрешения задачи и в неправильном выборе задач проектирования (недостаточный или чрезмерно большой объем задач автоматизации). На стадии эксплуатации это может привести к дополнительной доработке ИС, что влечёт за собой финансовый риск. Риск можно предотвратить применением инновационных case-средств в процессе моделирования бизнес-процессов. В случае появления подобного риска выполняется дополнительное моделирование с применением инновационных case-средств.

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

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

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

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

На подэтапе «Создание ПО» основная угроза состоит в неправильной разработке программы. Данный риск можно устранить применением для программирования языка 4-го поколения CLARION, который при программировании показывает неправильности различных компонентов создаваемого программного средства. Следует учесть, что тестирование программных модулей будет выполняться на стадии введения.

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

 

3.3 Характеристика объекта автоматизации

 

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

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

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

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

При приемке оборудования в ремонт наладчик осуществляет следующие действия:

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

Существующая схема организации учета ремонтов приводится на рисунке 3.4. На рисунке 3.5 приведена декомпозиция данного процесса.

Рис. 3.4 Существующая схема организации учета ремонтов

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

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

Рис. 3.6 Декомпозиция процесса учета заявки

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

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

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

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

Целями решения комплекса задач по автоматизации работы наладчика являются:

1. повышение качества ремонта за счет более оперативного реагирования на возникающие нужды;
2. уменьшение временных затрат
3. повышение качества работы с заказчиками

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

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

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

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

Задачи разработки системы:

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

Объектом автоматизации считается рабочее место наладчика.

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

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

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

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

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

Схема информационных потоков в методологии DFD в рамках работы отдела заказов и взаимодействующих с ним подразделений представлена на рисунках 3.7 и 3.8 [9].

К участникам бизнес-процесса относятся: клиенты; поставщики; менеджеры отдела; бухгалтерия; отдел материально-технического снабжения (МТС); работники.

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

Таблица 3.1

Информационные связи компонентов системы

 

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

Рис. 3.8 Диаграмма потоков данных на уровне подсистем

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

— определение, является ли клиент постоянным заказчиком компании (постоянные заказчики получают скидки);

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

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

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

— сдача заказа, оформление менеджером приемо-сдаточного акта, счета и счета-фактуры.

 

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

 

Наименование системы

Информационная система учета данных по обслуживанию и ремонту оборудования и авто в отделе обслуживания и ремонта оборудования сервисного центра (сокращенно – ИС УДОиРО).

Основание для разработки

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

Цель разработки

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

Требования к системе в целом

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

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

1. наладчик;
2. администратор системы, осуществляющий ее настройку.

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

Показатели назначения

• Максимальное время выполнения функций по вводу в систему справочных данных и данных для документов не должно превышать пяти минут для одной операции;
• Редактирование данных справочников и форм документов не должно превышать пяти минут для одного документа;
• Функция вывода данных (формирования отчетов) не должна превышать пяти минут для одного отчета.

Требования по безопасности

Для обеспечения безопасности при использовании ИС УДОиРО пользователям требуется соблюдать Инструкцию по технике безопасности при работе с компьютерами. Комплекс технических средств, необходимый для нормального функционирования системы, должен отвечать требованиям СанПиН 2.2.2/2.4.1640-11 «Гигиенические требования к персональным электронно-вычислительным машинам и организации работы», утв. Главным государственным санитарным врачом РФ 12 сентября 2011 г.

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

Для обеспечения ИС УДОиРО от несанкционированного доступа необходимо предусмотреть авторизацию пользователя при входе в систему.

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

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

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

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

Требования по сохранности информации при авария

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

Требования по стандартизации и унификации

При создании системы необходимо использовать среду разработки Delphi RAD Studio и СУБД Mysql.

Экранные формы системы должны быть разработаны в соответствии с требованиями к интерфейсу программных средств ГОСТ Р ИСО 14915-1-2010 «Эргономика мультимедийных пользовательских интерфейсов».

Общая оценка программного продукта должна быть проведена в соответствии с ГОСТ 28195-89 «Оценка качества программных средств». В том числе программный продукт должен быть оценен по следующим критериям:

• Надежность;
• Сопровождаемость;
• Удобство применения;
• Эффективность;
• Универсальность;
• Корректность.

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

Структура и основные функции системы

ИС УДОиРО должно состоять из следующих модулей:

1. Модуль «Справочники».
2. Модуль «Склад».
3. Модуль «Ремонты».
4. Модуль «Отчеты».

Каждый модуль АРМ должен выполнять соответствующие функции.

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

Модуль «Справочники»:

• Добавление, редактирование и удаление данных в справочнике «Сотрудники»;
• Добавление, редактирование и удаление данных в справочнике «Марки и модели»;
• Добавление, редактирование и удаление данных в справочнике «Запчасти»;
• Добавление, редактирование и удаление данных в справочнике «Оборудование».

Модуль «Склад»:

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

Модуль «Ремонты»:

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

Модуль «Отчеты»:

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

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

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

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

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

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

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

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

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

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

Для работы с системой компьютер конечного пользователя должен быть оснащен ОС Microsoft Windows не ниже седьмой версии.

При создании системы необходимо использовать среду разработки Delphi RAD Studio и СУБД Mysql.

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

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

• процессор не ниже Intel Core i3 не ниже 3.30 GHz. Рекомендуется использовать многопроцессорные сервера;
• оперативная память не менее 4096 Мбайт (рекомендуется 8128 Мбайт и выше). Компьютер конечного пользователя должен удовлетворять следующим техническим требованиям:
• Intel Celeron Dual-Core, 2000Mhz, 1024 Мб RAM, 160 Гб HDD, VGA видеоадаптер, монитор LCD, клавиатура, мышь.

Для обеспечения сетевой работы АРМ НТО компьютеры возможных пользователей системы должны быть объединены в ЛВС. В качестве сетевого интерфейса необходимо применить сетевой протокол TCP/IP с пропускной способностью 10/100 Мбит/с.

Программный продукт должен позволять одновременное использование не более чем 10 пользователями одновременно, по количеству АРМ.

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

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

В том числе должны быть разработаны:

• Руководство администратора;
• Руководство наладчика.

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

 

3.5 Работы по созданию системы

 

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

Таблица 3.2

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

 

3.6 Порядок контроля и приема системы

 

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

 

3.7 Cостав и содержание работ по подготовке объекта автоматизации к вводу в эксплуатацию

 

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

1. Разработка технического задания.
2. Проектирование ИС.
3. Внедрение.

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

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

• разработка программы;
• разработка программной документации;
• тестирование программы.

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

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

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

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

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

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

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

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

 

3.8 Требования к документации

 

Данный проект должен содержать разделы:

1. Техническое задание;
2. Аналитическая часть;
3. Проектная часть;
4. Экспериментальная часть;
5. Акт сдачи приемки системы.

 

3.9 Источники разработки

 

Разработка ведется на основании:

• задание на разработку;
• техническое задание;
• календарный план-график выполнения этапов работы (см. п. 5 данного технического задания).
• ГОСТ 34.601-90. Информационная технология. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Стадии создания. (Взамен ГОСТ 24.601-86, ГОСТ 24.602-86);
• ГОСТ 34.602-89. Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы (Взамен ГОСТ 24.201-85);
• ГОСТ 34.603-92. Информационная технология. Виды испытаний автоматизированных систем (Взамен ГОСТ 24.104-85 в части разд.3.);
• РД 50-34.698-90. Автоматизированные системы. Требования к содержанию документов. (Взамен ГОСТ 24.104-85 в части разд. 3.);
• ГОСТ 34.201-89. Информационная технология. Комплекс стандартов на автоматизированные системы. Виды, комплектность и обозначения документов при создании автоматизированных систем (Взамен ГОСТ 24.101-80, ГОСТ 24.102-80).

---

1  2  3