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

АСУ ПУНКТА ТЕХНИЧЕСКОГО ОБСЛУЖИВАНИЯ (АСУ ПТО)

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

Внедрение АРМов ПТО системы АСУ ПТО позволяет решить следующие задачи вагонного депо:

обеспечение технического обслуживания вагонов в соответствии с установленной технологией и нормативно-технической документацией; автоматизацию информационного обслуживания персонала основных подразделений СПТО, участвующих в техническом обслуживании грузовых вагонов; создание условий для повышения оперативности управления организацией обслуживания грузовых вагонов; автоматизацию составления и передачи потребителям отчетных и учетных форм документации; связь информации о техническом состоянии вагонов с информацией о размещении их в поездах и на путях станции, имеющейся в АСУ СПТО и его функциональных аналогах. увязку информации с дополнительно разрабатываемыми комплексами задач (АРМ); автоматическое ведение модели состояния вагонов и их дислокации в местах ремонта вагонов уменьшение операций по корректировке информации о вагонах в модели станции и в ТГНЛ, проводимых операторами СТЦ по прибытию и отправлению поездов; создание информационной основы для полной автоматизации информационных взаимосвязей между всеми подразделениями линейного района. Обмен с другими подсистемами АСУЖТ и АРМами подразделений, ведущими учет вагонов; сокращение времени простоя вагонов на всех участках, где с ним производится работа.

Главным условием установки и запуска АСУ ПТО является функционирующая сортировочная станция, в пределах которой находится Сетевое ПТО, система АСУ ЛР разработки НТЦ «Транссистемотехника».

Подход поезда к станции отражается в АРМе пользователя (оператора ПТО парка прибытия) в следующем виде

Содержится следующая информация:

данные о результатах контроля технического состояния вагонов в прибывающем поезде средствами диагностики; данные о подходе поезда к станции; данные о результатах встречи поезда, которые вводятся оператором ПТО по прибытию после их передачи от осмотрщика-ремонтника вагонов (ОРВ) по встрече; данные о прибытии поезда на станцию, которые вводятся операторами СТЦ по прибытию.

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

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

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

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

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

Когда оператор ПТО по прибытию завершает оформление результатов технического осмотра состава, сведения о выявленных неисправных вагонах передаются в базу данных АСУЛР, на основании чего в натурный лист поезда автоматически вносятся признаки отнесения вагонов к нерабочему парку (особые отметки «9»).

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

Кроме того, по завершению оформления результатов технического осмотра, автоматически формируются уведомления ВУ-23 и сопроводительные листки ВУ-26, а также текстовые сообщения 1353, 1352 для передачи в ДИСПАРК. Документы формы ВУ-23 передаются к распечатке на пункт текущего отцепочного ремонта (МВРП), если неисправный вагон не может следовать далее, и вместе с документами формы ВУ-26 — в СТЦ, если выявленные неисправности вагонов не препятствуют его следованию далее.

При выполнении технического осмотра состава поезда, прибывшего в расформирование, оператор ПТО должным образом помечает вагоны, подлежащие безотцепочному ремонту по наряду либо на специализированных путях ремонта вагонов (МППВ) в сортировочном парке, либо на приёмо-отправочных путях перед отправлением поезда своего формирования со станции.

Отражение сведений о вагонах, требующих безотцепочного ремонта по наряду на МППВ или на путях приёмо-отправочных парков (ПОП) на АРМе оператора ПТО по прибытию

Технология работы на пункте текущего отцепочного ремонта (МВРП) и на специализированных путях ремонта вагонов (МППВ) в сортировочном парке.

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

Пример наряда на выполнение ремонтных работ

Результаты выполнения текущего отцепочного ремонта оформляются на АРМе оператора МВРП.

По данным о выполнении ремонта вагонов на МВРП, рассчитывается уведомление о приёмке вагонов из ремонта формы ВУ-36, которое передаётся на распечатку в СТЦ для внесения изменений в натурный лист поезда (снятие отметок «9» как признаков отнесения вагонов к нерабочему парку), а также формируется текстовое сообщение 1354 для передачи в ДИСПАРК.

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

Технология работы при выполнении технического осмотра и безотцепочного ремонта вагонов на путях приёмо-отправочных парков .

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

Интерфейс оформления технического осмотра состава в приемо-отправочном парке

Оформление устранения неисправности безотцепочного ремонта вагонов на приёмо-отправочных путях.

Учёт расхода материально-технических ресурсов (МТР) при выполнении вагоноремонтных операций.

Задача предусмотрена для учёта расхода запчастей и материалов при техническом обслуживании вагонов на станции и оперативного информирования мастера ВЧД о критическом наличии деталей в парках станции для своевременной выписки наряда на эти материалы и запчасти.

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

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

Наличие запчастей и материалов на стеллажах.

АРМ оператора МППВ

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

Оператор ППВ вводит ограждение состава, бригаду обслуживающую поезд.

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

Все дополнения оператор ППВ вводит в АРМ.

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

После устранения неисправностей данные по ремонту вводятся в АРМ.

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

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

После завершения работ ОРВ по обслуживанию тормозного оборудования вагонов дают готовность оператору. Оператор снимает ограждение и дает заявку на подгонку поездного локомотива.

Вся работа МППВ производится в АРМе АСУ ЛР согласно «Графика зарядки, ремонта вагонов и отправки готового поезда с МППВ станции Входная

Источник

Разработка информационно-справочной системы по учету вагонов на подъездном пути предприятия

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

Рубрика	Программирование, компьютеры и кибернетика
Вид	дипломная работа
Язык	русский
Дата добавления	20.10.2008
Размер файла	1,4 M

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

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

Аннотация

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

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

При проектировании базы данных использовалось CASE-средство как ERwin 4.0. Также использовалась система управления реляционными базами данных Microsoft Access 2003. Среда Delphi 7.0 была выбрана в качестве средства для разработки СУБД

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

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

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

Annotation

This degree work is devoted to a theme «The development of the information system under the account of account materials and conduction statistics of a press». The system will be a real boon to companies that use both own and rented vehicles: it will allow you to automate the vehicles tracking process. The data base is freely distributed. The Case tool Erwin 4.0, Microsoft Access 2003, Delphi 7.0 were used at designing of database. This program has the clear interface adapted for simple and easy process of a press in company.

The following results have been reached during performance of system: the principal model of database, the logic normalized model of database were designed, the physical model of database was constricted, the technical tools were chosen, the basic program modules of system were realized, the ecological and ergonomic requirements were analyzed at designing the interface.

The information system has been developed on the basis of the received materials. This system is directed on automation the vehicles tracking process.

• Аннотация 2
• Annotation 3
• Введение 6
• Постановка задачи 9
• Глава 1. Основы проектирования программных продуктов 12
  • 1.1. Характеристика программных продуктов 12
  • 1.2. Жизненный цикл программного обеспечения (ЖЦ ПО) 15
  • 1.3. Модели жизненного цикла ПО 18
  • 1.4. Структурный подход к проектированию ПП 20
• Глава 2. Основные принципы проектирования базы данных 24
  • 2.1. Понятие базы данных и системы управления базами данных 24
  • 2.2. Основные свойства базы данных 24
  • 2.3. Трехуровневая архитектура базы данных 26
  • 2.4. Жизненный цикл базы данных 28
    • 2.4.1. Планирование разработки базы данных 29
    • 2.4.2. Определение требований к системе 30
    • 2.4.3. Сбор и анализ требований пользователей 30
    • 2.4.4. Проектирование базы данных 30
    • 2.4.5. Разработка приложений 31
    • 2.4.6. Реализация 31
    • 2.4.7. Загрузка данных 32
    • 2.4.8. Тестирование 32
    • 2.4.9. Эксплуатация и сопровождение 33
  • 2.5. Модели представления данных 33
    • 2.5.1. Иерархическая модель данных 34
    • 2.5.2. Сетевая модель данных 34
    • 2.4.3. Реляционная модель данных 34
  • 2.6. Проектирование базы данных 41
    • 2.6.1. Нормализация как особенность проектирования базы данных 41
    • 2.6.2. Концептуальное проектирование базы данных 44
    • 2.6.3. Логическое проектирование базы данных 46
    • 2.6.4. Физическое проектирование базы данных 48
    • 2.6.5. Этапы проектирования базы данных 49
• Глава 3. Проектирование пользовательского интерфейса 51
  • 3.1. Требования к пользовательскому интерфейсу 51
    • 3.1.1. Методы оценки пользовательского интерфейса 53
    • 3.1.2. Цели и критерии оценки пользовательского интерфейса 53
    • 3.1.3. Этапы проектирования интерфейса 55
  • 3.2. Принципы проектирования эргономичного пользовательского интерфейса 56
    • 3.2.1. Размещение информации на экране 57
    • 3.2.2. Непротиворечивость и стандартизация 58
    • 3.2.3. Тексты и диалоги 58
    • 3.2.4. Средства управления графического интерфейса пользователя 59
    • 3.2.5. Меню 59
    • 3.2.6. Формы 60
    • 3.2.7. Организация системы навигации и системы отображения состояний 61
    • 3.2.8. Проектирование сообщений 61
    • 3.2.9. Предотвращение, обнаружение и исправление ошибок 62
• Глава 4. Построение концептуальной модели базы данных 63
  • 4.1. Исследование предметной области применения и выявление требований конечных пользователей и решаемых задач 63
    • 4.1.1. Определение объектов базы данных и связей между объектами 63
    • 4.1.2. Инфологическая модель данных «сущность-связь» 66
  • 4.2. Проектирование логической модели базы данных 68
  • 4.3. Проектирование физической модели базы данных 69
• Глава 5. Реализация проекта 76
  • 5.1. Набор компонентов, используемых для создания приложений 76
  • 5.2. Работа с режимами программыDiplom 77
• Глава 6. Выбор инструментальных средств 102
  • 6.1. Выбор аппаратных средств 102
  • 6.2. ERwin — современное средство проектирования баз данных 102
  • 6.3.MicrosoftAccess2003 105
  • 6.4. Язык SQL как стандартный язык баз данных 108
    • 6.4.1. Функциональные возможности языкаSQL 109
    • 6.4.2. Достоинства SQL 110
  • 6.5. Среда Delphi как средство для разработки СУБД 110
    • 6.5.1. Высокопроизводительный компилятор в машинный код 112
    • 6.5.2. Библиотека визуальных компонент 113
    • 6.5.3. Технологии доступа к данным 114
    • 6.5.4. Элементы управленияWindowsXP 115
    • 6.5.5. Генератор отчетов Rave Reports 5.0 116
• Глава 7. Обоснование реализуемости системы по результатам анализа предельно допустимой длины слова с помощью системыMathCad2001i 117
  • 7.1. Постановка задачи 117
• Глава 8. Расчет затрат на создание программного обеспечения и оценка технико-экономической эффективности разработанного программного обеспечения 122
  • Введение 122
  • 8.1. Расчет затрат на разработку системы учета компьютерного вагонов на подъездном пути на предприятии 122
  • 8.2. Расчет затрат на основную заработную плату разработчикам 123
  • 8.3. Расчет дополнительной заработной платы разработчиков программы 124
  • 8.4. Расчет отчислений на социальное страхование и обеспечение 125
  • 8.5. Расчет затрат на амортизацию ЭВМ, используемых при разработке системы учета компьютерного оборудования на предприятии 126
  • 8.6. Расчет затрат на электроэнергию, используемую ЭВМ в процессе разработки программы 127
  • 8.7. Расчет накладных расходов 128
  • 8.8. Расчет затрат на эксплуатацию системы учета компьютерного оборудования на предприятии 129
  • 8.9. Расчет отпускной цены разрабатываемой системы учета компьютерного оборудования на предприятии 132
  • 8.10. Расчет окупаемости капитальных вложений 132
• Заключение 134
• Глава 9. Экологическая часть 136
  • 9.1. Требования к условиям эксплуатации вычислительной техники (ВТ) 137
    • 9.1.1. Требования к помещениям для эксплуатации ВТ 137
    • 9.1.2. Требования к освещению помещений и рабочих мест пользователей ВТ 138
    • 9.1.3. Требования к шуму и вибрации в помещениях для эксплуатации ВТ 140
    • 9.1.4. Требования к микроклимату, содержанию аэроионов и вредных химических веществ в воздухе помещений эксплуатации ВТ 141
    • 9.1.5. Требования к уровням электромагнитных полей в помещениях для эксплуатации ВТ 143
  • 9.2. Требования к организации и оборудованию рабочих мест пользователей и мест эксплуатации ВТ 144
  • 9.3. Общие рекомендации к организации труда и отдыха при работе с ВТ 147
• Заключение 150
• Список литературы 152
• Приложение 1 154
• Введение
• За последние годы в мире произошли значительные перемены, которые не могли не затронуть области информатики и вычислительной техники. Еще несколько лет назад работа с базами данных и электронными таблицами была уделом профессиональных программистов. Сами системы не были предназначены для широкого пользования. С появлением огромного числа банков, акционерных обществ и частных компаний ситуация резко изменилась.
• В настоящее время обработка и хранение информации не является чисто умозрительной задачей. Потеря информации или ее несвоевременное получение могут обернуться потерей денег. Именно этими обстоятельствами можно объяснить столь бурный рост компьютерной техники и стремительное развитие электронных таблиц и систем управления базами данных (СУБД). Для оперативного, гибкого и эффективного управления предприятиями, фирмами и организациями различных форм собственности широко внедряются системы автоматизированного управления, ядром которых являются базы данных (БД). При большом объеме информации и сложности производимых с ней операций проблема эффективности средств организации хранения, доступа и обработки данных приобретает особое значение.
• Данная дипломная работа посвящена теме «Разработка информационно-справочной системы по учету вагонов на подъездном пути предприятия».
• Система учета подвижного состава предназначена для предприятий, использующих как собственный, так и арендованный подвижной состав, и позволяет автоматизировать процесс его учета. Помимо того, что система существенно облегчает и ускоряет определение местонахождения подвижного состава, она также позволяет анализировать затраты на стоимость его обслуживания.
• База данных, разрабатываемая в данной дипломной работе, является свободно распространяемой, без каких-либо жестких ограничений. Это требование является желательным, поскольку не всегда руководители предприятий готовы пойти на уступки и оплачивать покупку того или иного программного обеспечения.
• Разработанная база данных позволит автоматизировать обработку информации и оперативно реагировать на обстановки, что особенно важно в таком динамичном сегменте рынка как грузоперевозки. Кроме того, она сократит долю ручного труда при ведении учета и позволит автоматизировать процесс составления документов.
• Для удобства учета программу можно разместить на внутреннем сервере компании, что позволит нескольким сотрудникам одновременно вводить информацию в одну БД. Это обеспечит равномерное распределение нагрузки на работников.
• При проектировании базы данных использовалось такое мощное CASE-средство как ERwin 4.0, поскольку от того, насколько хорошо спроектирована база данных, зависит удобство ее дальнейшего использования и администрирования. Также использовалась система управления реляционными базами данных Microsoft Access 2003, которая предоставляет пользователям функциональные возможности, позволяющие осуществлять доступ к важным данным, и производить их глубокий анализ, а также является серьезной средой разработки приложений.
• Среда Delphi 7.0 была выбрана в качестве средства для разработки СУБД, поскольку она отвечает следующим критериям: высокая скорость разработки приложений; возможность быстрого внесения изменений в программу; возможность редактирования и просмотра БД, используя средства разработки.
• Программа обладает интуитивно понятным интерфейсом, полностью адаптированным к простому и необременительному процессу печати в компании.
• Постановка задачи
• Темой дипломной работы является «Разработка информационно-справочной системы по учету вагонов на подъездном пути предприятия» и пользовательского интерфейса к ней. Вопрос автоматизации процесса учета вагонов до сих пор остается открытым и актуальности терять не собирается. Данная информационная система (ИС) позволит специалистам оперативно получать и анализировать данные о наличии, состоянии и точном местонахождении вагонов.
• Информационная система должна представлять собой базу данных, позволяющую вести учет вагонов на подъездном пути предприятия и обеспечивать расчет затрат на обслуживание вагонов и интерфейс к ней.
• ИС должна обеспечивать выполнение всех этих действий, а также должна обладать удобным и простым для восприятия интерфейсом и справочной системой.
• Исходными данными БД являются:
• 1. вагон:

2. операции с вагоном:

цена за единицу измерения

База данных должна отвечать следующим требованиям:

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

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

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

в БД должна быть предусмотрена печать отчетов.

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

Задачи, решаемые с помощью системы:

Загрузка в систему информации о вагонах, обработка информации;

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

Определение текущего местонахождения вагонов;

Ввод, хранение, поиск и вывод информации о вагонах на подъездных путях;

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

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

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

Автоматизированная обработка получаемой информации.

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

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

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

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

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

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

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

Глава 1. Основы проектирования программных продуктов

1.1. Характеристика программных продуктов

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

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

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

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

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

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

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

Основными характеристиками программ являются:

алгоритмическая сложность (логика алгоритмов обработки информации);

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

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

объем файлов программ;

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

объем дисковой памяти;

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

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

наличие вычислительной сети и др.

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

насколько хорошо (просто, надежно, эффективно) можно использовать программный продукт;

насколько легко эксплуатировать программный продукт;

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

Характеристики качества программных продуктов:

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

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

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

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

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

Коммуникативность программных продуктов основана на максимально возможной их интеграции с другими программами, обеспечении обмена данными в общих форматах представления (экспорт/импорт баз данных, внедрение или связывание объектов обработки и др.).[1]

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

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

1.2. Жизненный цикл программного обеспечения (ЖЦ ПО)

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

Основным нормативным документом, регламентирующим ЖЦ ПО, является международный стандарт ISO/IEC 12207 (ISO — International Organization of Standardization — Международная организация по стандартизации, IEC — International Electrotechnical Commission — Международная комиссия по электротехнике). Он определяет структуру ЖЦ, содержащую процессы, действия и задачи, которые должны быть выполнены во время создания ПО.

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

1. формирование требований (анализ)

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

3. реализация (кодирование)

4. тестирование

5. внедрение

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

7. снятие с эксплуатации

Стадия анализа предназначена для изучения требований к создаваемому программному продукту, а именно:

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

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

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

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

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

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

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

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

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

Длительность жизненного цикла для различных программных продуктов неодинакова. Для большинства современных программных продуктов длительность жизненного цикла измеряется в годах (2-3 года). Хотя достаточно часто встречаются на компьютерах и давно снятые с производства программные продукты.

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

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

1.3. Модели жизненного цикла ПО

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

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

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

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

На практике наибольшее распространение получили две основные модели жизненного цикла:

каскадная модель (характерна для периода 1970-1985 гг.);

спиральная модель (характерна для периода после 1986.г.).

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

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

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

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

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

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

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

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

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

1.4 Структурный подход к проектированию ПП

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

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

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

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

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

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

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

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

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

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

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

SADT (Structured Analysis and Design Technique) модели и соответствующие функциональные диаграммы;

DFD (Data Flow Diagrams) диаграммы потоков данных;

ERD (Entity-Relationship Diagrams) диаграммы «сущность-связь».

Наиболее распространенным средством моделирования данных являются диаграммы «сущность-связь» (ERD). Данное средство было использовано в дипломной работе для проектирования специализированной базы данных, на основе которой разрабатывалась система учета подвижного состава на подъездном пути. С помощью ER-диаграмм определяются важные для предметной области объекты (сущности), их свойства (атрибуты) и отношения друг с другом (связи). ERD непосредственно используются для проектирования реляционных баз данных, что соответствует выбранной модели базы данных, проектируемой в данной дипломной работе.[1]

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

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

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

Связь — поименованная ассоциация между двумя сущностями, значимая для рассматриваемой предметной области.[1]

Глава 2. Основные принципы проектирования базы данных

2.1 Понятие базы данных и системы управления базами данных

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

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

2.2 Основные свойства базы данных

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

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

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

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

Эффективность. Свойство эффективности обычно понимается как:

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

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

сочетание этих параметров.

Предельные размеры и эксплуатационные ограничения. Предельные размеры, а также другие ограничения, накладываемые эксплуатацией данной БД, могут существенно повлиять на проектное решение.[3]

2.3. Трехуровневая архитектура базы данных

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

администраторы данных и баз данных;

разработчики баз данных;

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

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

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

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

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

разработчики физической базы данных.

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

разработка концептуальной модели БД;

разработка логической модели БД.

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

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

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

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

Рис.2.1. Уровни моделей данных

Основным назначением трехуровневой архитектуры является обеспечение независимости от данных. Суть этой независимости заключается в том, что изменения на нижних уровнях никак не влияют на верхние уровни.[3]

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

Источник