Разработка ИС учета охраняемых объектов ЧОП "Рубеж-М"

1.1 Описание предметной области

Компания ЧОП «Рубеж-М». готова предложить:

- Охрана объектов

- Электромонтах ТСО

- Пожарная безопасность

Основные направления деятельности ЧОП «Рубеж-М». текущее и капитальное обслуживание, операции по инженерно-техническому сопровождению сложных работ при капитальном обслуживании, операции РИР.

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

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

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

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

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

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

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

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

Состав нормативной базы системы обслуживание оборудования:

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

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

нормы трудоемкости;

нормы расходов материалов.

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

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

За оборудование своего профиля также отвечают главный энергетик, Служба КИПиА, АСУ ТП.

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

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

Этапы проведения планового обслуживание и обслуживания (рисунки 1.2 и 1.3):

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

остановка оборудования, разборка и уточнение дефектной ведомости;

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

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

Рисунок 1.1 Контекстная диаграмма системы обслуживание и обслуживания

Рисунок 1.2 Диаграмма декомпозиции системы обслуживание и обслуживания

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

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

Деятельность «Подготовка к обслуживанию» (выделена цветом на рисунке 1.3) весьма трудоемка и не автоматизирована в должной мере. На данный момент весь документооборот реализован с помощью средств MS Word и MS Excel. Учет заказов на выполнение работ, перечень запчастей и расходных материалов ведутся в виде таблиц MS Excel, которые при необходимости распечатываются. Дефектные ведомости, заявки на материалы и запчасти и прочее подготавливается и хранится в виде документов MS Word.

1.2 Обоснование необходимости внедрения ИС

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

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

вести учет договоров;

вести учет обслуживаемого оборудования;

вести учет выездов специалистов (выполненных работ);

вести учет движения запасных частей;

вести учет операций с оборудованием;

осуществлять оперативное формирование отчетов;

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

Предприятие-заказчик сам определяет для себя вариант внедрения. Существуют два варианта: комплексное внедрение и внедрение собственными силами.

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

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

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

Информационные системы обычно приобретаются на достаточно долгий срок (среднее время «жизни» ИС - 5-10 лет, но это не предел - во многих компаниях используются системы с гораздо большим «стажем» работы, правда, и обрастающими за это время новыми возможностями). Чтобы система автоматизации приносила ожидаемый эффект, она должна соответствовать данному предприятию - его возможностям, уровню развития и т.д. Стоимость ИС для небольшой фирмы не так уж и мала [2].

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

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

что система автоматизации может делать, или какова ее функциональность;

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

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

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

какова эффективность и возможные сроки окупаемости системы;

уровень и качество сервиса в послепродажный период;

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

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

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

Таким образом, для реализации задачи учета заказов на выполнение работ по хранению и обслуживанию оборудования выбран вариант реализации посредством разработки ИС учета охраняемых объектов, который учитывает специфику процесса обработки информации в ЧОП «Рубеж-М».

1.3 Обзор существующих программных продуктов

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

Компания ITM предлагает предприятиям экономичный путь внедрения информационной системы управления техническим обслуживанием и обслуживанием (ИСУ ТОиР) оборудования (http://www.itm.spb.ru/).

Предложение ITM адресовано целевой группе заказчиков - предприятиям с относительно небольшими обслуживаемыми (сервисными) службами. Этим предприятиям мы предоставляем типовую платформу для организации управления ТОиР - систему TRIM-PMS (TRIM-Planned Maintenance System). Она охватывает всю деятельность персонала, связанного с ТОиР, от регистрации первичных данных до получения и анализа численных значений показателей эффективности системы ТОиР в целом.

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

В состав TRIM-PMS входят:

типовая модель системы ТОиР, предназначенная для целевой группы заказчиков TRIM-PMS;

сетевое программное обеспечение TRIM, реализующее модель системы ТОиР и заранее настроенное под потребности целевой группы заказчиков,

инструкции и руководства по внедрению ИСУ ТОиР на основе программного обеспечения TRIM со стандартными настройками;

типовой регламент использования ИСУ ТОиР, разработанный под указанную выше модель, определяющий роли пользователей и порядок их работы в системе;

набор отчетных форм, получаемых из системы и используемых при организации и проведении ТОиР;

система измеряемых показателей KPI, используемых для оценки и анализа ТОиР и принятия управленческих решений, направленных на улучшения,

руководство по оценке и анализу системы ТОиР по показателям KPI, логически завершающее всю последовательность действий пользователей в системе.

Завершенность концепции TRIM-PMS позволяет заказчикам использовать эту систему как готовую платформу для организации управления ТОиР на своих предприятиях. В этом случае выполнение типового регламента использования TRIM-PMS даст предприятию объективные численные значения тех показателей, которые входят в стандартную поставку системы. Эти показатели характеризуют работоспособность оборудования, эффективность планирования ТОиР и затраты на ТОиР.

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

Заказчик имеет возможность привлечь специалистов ITM к выполнению работ по внедрению ИСУ ТОиР, по доработке платформы, по реализации дополнительных измеримых показателей. Преимущество платформы TRIM-PMS состоит в ее расширяемости, платформа может дорабатываться за счет включения в TRIM-PMS дополнительных функций из базового программного продукта - EAM/MRO-системы TRIM.

Пользователю доступны следующие функции TRIM-PMS:

описание и ведение структуры основных производственных фондов, учет и описание объектов ТОиР;

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

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

планирование периодических работ по техническому обслуживанию и обслуживания;

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

учет остатков складских запасов;

формирование потребности в запасных частях и материалах;

заказ запасных частей для работ;

оформление прихода/расхода товаров;

ведение журнала запланированных и выполненных работ;

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

планирование работ по устранению дефектов;

ввод отчетов о выполнении плановых работ, и работ по устранению дефектов;

списание запасных частей, использованных при выполнении работ;

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

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

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

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

определение и анализ показателей работоспособности оборудования (MTTR, MTBF и т.д.);

определение и анализ показателей эффективности планирования ТОиР;

определение и анализ показателей затрат на ТОиР (план/факт);

анализ отказов, их видов, причин, и последствий и критичности;

ведение технической документации.

Программный продукт «1С:ТОиР Управление обслуживанием и обслуживанием оборудования» от компании «Деснол Софт» (http://remontexpert.ru) предназначен для специалистов по организации обслуживания и обслуживания промышленного оборудования, а так же для всех подразделений, имеющих какое-либо отношение к управлению активами, обслуживанием и обслуживанию: финансы и бухучет, логистика и снабжение, управление кадрами. Система окажет неоценимую помощь руководству, сделав «прозрачной» структуру производственных активов. Для обслуживания служб система является основной поддержкой управления: ведется огромный архив всей нормативной и технической документации, рассчитываются графики ППР, выписываются наряды на работы, ведется учет работ.

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

«1С:ТОиР» относится к классу EAM систем (Enterprise Assets Management) - систем Управления активами (основными фондами): обеспечен учет всех затрат на актив, расчет бюджета, интеграция с кадровой системой, МТО и бухгалтерией.

Затраты на поддержание работоспособности оборудования достаточно велики. «1С:ТОиР» позволяет существенно сократить расходы на техническое обслуживание и обслуживания, снизить продолжительность простоев оборудования, увеличить его загрузку. Такие результаты достигаются за счет следующих факторов:

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

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

оптимизируется процесс МТО на основе точных данных: отказ от «дорогого» в эксплуатации оборудования, снижение складских запасов;

перевод части оборудования на обслуживание по состоянию;

персонификация ответственности, контроль соответствия квалификации персонала;

расчет затрат по нормам, а не «как в прошлом году + инфляция»;

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

сокращение простоев оборудования.

Функции системы:

1) Ведение справочной информации.

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

2) Ведение паспортов оборудования в системе.

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

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

3) Формирование графика обслуживания.

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

4) Ведение нарядов на работы.

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

5) Формирование графика поверок.

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

6) Формирование бюджета.

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

7) Формирование потребности в МТО.

Система сама формирует отчет по потребности в МТО на год, плановый график. А так же на каждый месяц, с возможной корректировкой.

8) Оптимизация затрат на обслуживание.

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

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

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

9) Документы.

Система ведет полный документооборот по обслуживанию, основные документы:

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

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

Дефектная ведомость: при проведении осмотра оборудования выявляются дефекты. Все выявленные дефекты фиксируются документом «Дефектная ведомость». Вся история по выявленным дефектам узлов или агрегатам хранится в системе;

Акты выполненных работ: Все факты завершения обслуживаемых работ оформляются с помощью различных актов. В этих актах отражается время завершения работ, их объем, и стоимость;

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

Наряд-допуск: при проведении обслуживаемых работ в условии повышенной опасности (повышенный риск возникновения пожара или других аварий) система формирует необходимые наряды и допуски на проведение этих работ;

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

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

Таблица 1.1 Сравнение функционала существующих программных продуктов

Рассмотренные системы, а также многие другие, отличаются рядом недостатков:

1) Большинство систем разработано для автоматизации «любой» предметной области в сфере организации и планирования обслуживаниеов, и поэтому они не учитывают все нюансы конкретной задачи;

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

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

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

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

Целью учета охраняемых объектов является постоянная поддержка актуальности информации о заказах на охрану объектов и обслуживание. Информация необходима для планирования работы ЧОП «Рубеж-М»

В рамках данного дипломного проекта подлежат разработке следующие функции ИС учета охраняемых объектов ЧОП «Рубеж-М»:

учет номенклатуры оборудования;

оформление заказа на обслуживание и обслуживание оборудования;

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

формирование выходных документов:

прайс-лист на запчасти и расходные материалы;

договор на обслуживание и обслуживание оборудования;

наряд на выполнение работ;

акт сдачи-приемки работ;

дефектная ведомость;

счет и счет-фактура, выставляемые клиенту;

выполненные работы за период;

формирование статистических диаграмм:

потребность в МТР (материально-технических ресурсах) за период;

статистика расхода МТР за период;

суммы работ за период;

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

2. Рабочий проект

2.1 Функциональное проектирование системы

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

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

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

кто выполняет процедуры бизнес-процесса;

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

какие исходящие документы/информацию генерирует процедура бизнес-процесса;

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

какая документация/условия регламентирует выполнение процедуры;

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

Для построения моделей бизнес-процессов и описания бизнес-процессов используются методологии SADT, семейства IDEF, DFD, UML, ARIS и другие.

Для разработки функциональной модели использовалось CASE-средство Computer Associates BPwin 4.0. BPwin мощный инструмент моделирования, который используется для анализа, документирования и реорганизации сложных бизнес-процессов. Модель, созданная средствами BPwin, позволяет четко документировать различные аспекты деятельности действия, которые необходимо предпринять, способы их осуществления, требующиеся для этого ресурсы и др. Таким образом, формируется целостная картина деятельности предприятия - от моделей организации работы в маленьких отделах до сложных иерархических структур. При разработке или закупке программного обеспечения модели бизнес-процессов служат прекрасным средством документирования потребностей, помогая обеспечить высокую эффективность инвестиций в сферу IT. В руках же системных аналитиков и разработчиков BPwin - еще и мощное средство моделирования процессов при создании корпоративных информационных систем [11].

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

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

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

BPwin поддерживает три методологии: IDEF0, DFD и IDEF3, позволяющие анализировать бизнес с трех ключевых точек зрения [10]:

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

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

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

Контекстная диаграмма и диаграмма декомпозиции системы в нотации IDEF0 представлены на рисунках 1.2 и 1.3.

DFD (Data Flow Diagrams) это диаграммы потоков данных, которые описывают внешние по отношению к системе источники и адресаты данных, логические функции, потоки данных и хранилища данных к которым осуществляется доступ [10]. Как показывает практика, это один из самых простых, доступных и наглядных стандартов для описания бизнес-процессов. Поэтому эта методология была выбрана для моделирования потоков данных ИС учета обслуживаниеных работ нефтяного оборудования.

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

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

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

2.2 Инфологические проектирование системы

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

Наиболее трудоемкими этапами разработки информационных систем являются этапы анализа и проектирования, в процессе которых CASE-средства обеспечивают качество принимаемых технических решений и подготовку проектной документации. При этом большую роль играют методы визуального представления информации. Это предполагает построение структурных или иных диаграмм в реальном масштабе времени, использование многообразной цветовой палитры, сквозную проверку синтаксических правил. Графические средства моделирования предметной области позволяют разработчикам в наглядном виде изучать существующую информационную систему, перестраивать ее в соответствии с поставленными целями и имеющимися ограничениями [15].

Среди таких пакетов - Rational Rose, Together Control Center, BPWin, ERWin, Model Mart, Silverrun Business Process Modeller, Process Analyst.

Для инфологического проектирования базы данных было выбрано CASE_средство Computer Associates ERwin 4.0.

Создание модели данных, как правило, начинается с создания логической модели. После описания логической модели, проектировщик может выбрать необходимую СУБД (систему управления базами данных) и ERwin автоматически создаст соответствующую физическую модель. На основе физической модели ERwin может сгенерировать системный каталог СУБД или соответствующий SQL-скрипт. Этот процесс называется прямым проектированием (Forward Engineering). Тем самым достигается масштабируемость - создав одну логическую модель данных, можно сгенерировать физические модели под любую поддерживаемую ERwin СУБД. С другой стороны, ERwin способен по содержимому системного каталога или SQL-скрипту воссоздать и физическую, и логическую модель данных (Reverse Engineering). На основе полученной логической модели данных можно сгенерировать физическую модель для другой СУБД и затем сгенерировать ее системный каталог [14].

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

2.2.1 Логическое проектирование

В разрабатываемой системе можно выделить следующие сущности: Группы, Реквизиты, Клиенты, МатЦенности, Заказы, МатЦенностиПоЗаказу, Работники, СоставЗаказа, Специализации.

ER-диаграмма системы на логическом уровне представлена на рисунке 2.3.

Рисунок 2.3 ER-диаграмма системы на логическом уровне

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

Выделяют три группы правил целостности [4, 5]:

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

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

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

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

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

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

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

Для приведения сущности к первой НФ следует [12]:

разделить сложные атрибуты на атомарные;

создать новую сущность;

перенести в нее все «повторяющиеся» атрибуты;

выбрать возможный ключ для нового № (или создать новый номер);

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

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

Для приведения сущности ко второй НФ следует [12]:

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

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

установить идентифицирующую связь от прежней сущности к новой.

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

Для приведения сущности к третьей НФ следует [12]:

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

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

установить не идентифицирующую связь от новой сущности к старой.

Разработанная модель находится в 3-й нормальной форме.

2.2.2 Физическое проектирование

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

В качестве СУБД выбрана Microsoft Access.

ER-диаграмма системы на физическом уровне представлена на рисунке 2.4.

Рисунок 2.4 - ER-диаграмма системы на физическом уровне

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

Таблица 2.1 Описание таблиц базы данных

2.3 Используемые классификаторы и системы кодирования

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

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

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

Таблица 2.2 Состав классификаторов

2.4 Разработка интерфейса ИС

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

Взаимодействие с пользователем осуществляется посредством экранных форм. Граф переходов экранных форм (дерево диалога) представлен на рисунке 2.5.

Рисунок 2.5 Граф перехода экранных форм

3. Программа и методика испытаний разработанной системы

3.1 Обоснование выбора СУБД

Первая промышленная версия СУБД dBase dBase II (принадлежащая тогда компании Ashton-Tate, приобретенной позже компанией Borland) появилась в начале 80-х годов. Благодаря простоте в использовании, нетребовательности к ресурсам компьютера и, что не менее важно, грамотной маркетинговой политике компании-производителя этот продукт приобрел немалую популярность [4].

Хранение данных в dBase основано на принципе «одна таблица -- один файл» (эти файлы обычно имеют расширение *.dbf). MEMO-поля и BLOB-поля (доступные в поздних версиях dBase) хранятся в отдельных файлах (обычно с расширением *.dbt). Индексы для таблиц также хранятся в отдельных файлах. При этом в ранних версиях этой СУБД требовалась специальная операция реиндексирования для приведения индексов в соответствие с текущим состоянием таблицы [4].

Формат данных dBase является открытым, что позволило ряду других производителей заимствовать его для создания dBase-подобных СУБД, частично совместимых с dBase по форматам данных. Например, весьма популярная некогда СУБД FoxBase (разработанная Fox Software, Inc. и ныне принадлежащая Microsoft) использовала формат данных dBase для таблиц, однако форматы для хранения MEMO-полей и индексов были своими собственными, несовместимыми с dBase.

После покупки dBase компанией Borland этот продукт, получивший впоследствии название Visual dBase, приобрел набор дополнительных возможностей, характерных для средств разработки этой компании и для имевшейся у нее другой настольной СУБД - Paradox. Среди этих возможностей были специальные типы полей для графических данных, поддерживаемые индексы, хранение правил ссылочной целостности внутри самой базы данных, а также возможность манипулировать данными других форматов, в частности серверных СУБД, за счет использования BDE API и SQL Links [4].

В настоящее время Visual dBase принадлежит компании dBase, Inc. Его последняя версия -- Visual dBase 7.5 имеет следующие возможности:

cредства манипуляции данными dBase и FoxPro всех версий;

ядро доступа к данным Advantage Database Server фирмы Extended Systems и ODBC-драйвер для доступа к данным этой СУБД;

средства визуального построения запросов.

Paradox

В конце 80-х -- начале 90-х годов Paradox, принадлежавший тогда компании Borland International, был весьма популярной СУБД, в том числе и в нашей стране, где он одно время занимал устойчивые позиции на рынке средств разработки настольных приложений с базами данных.

Принцип хранения данных в Paradox сходен с принципами хранения данных в dBase -- каждая таблица хранится в своем файле (расширение *.db), MEMO- и BLOB-поля хранятся в отдельном файле (расширение *.md), как и индексы (расширение *.px).

Однако, в отличие от dBase, формат данных Paradox не является открытым, поэтому для доступа к данным этого формата требуются специальные библиотеки. Например, в приложениях, написанных на C или Pascal, использовалась некогда популярная библиотека Paradox Engine, ставшая основой Borland Database Engine (BDE). Эта библиотека используется ныне в приложениях, созданных с помощью средств разработки Borland (Delphi, C++Builder), в некоторых генераторах отчетов (например, Crystal Reports) и в самом Paradox. Существуют и ODBC-драйверы к базам данных, созданным различными версиями этой СУБД [4].

Microsoft FoxPro и Visual FoxPro

FoxPro ведет свое происхождение от настольной СУБД FoxBase фирмы Fox Software. Разрабатывая FoxBase в конце 80-х годов, эта компания преследовала цель создать СУБД, функционально совместимую с dBase с точки зрения организации файлов и языка программирования, но существенно превышающую ее по производительности. Одним из способов повышения производительности являлась более эффективная организация индексных файлов, нежели в dBase, - по формату индексных файлов эти две СУБД несовместимы между собой [4].