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

Вид материала

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

Содержание Технические требования к аппаратно-программному комплексу системы 5 3.Общая постановки задачи, формулировка цели и задач 11 Общие сведения Наименование работы Основание для выполнения работы Назначение и цели создания системы Назначение системы. Цель выполнения работы Характеристика объекта автоматизации Краткие сведения об объекте автоматизации Требования к системе в целом Структура системы Требования к составу и квалификации персонала системы Требования к квалификации персонала, контролю знаний и навыков Технические требования к аппаратно-программному комплексу системы Требования к приспособляемости Требования к надежности Требования по эргономике и технической эстетике Требования к функциям, выполняемым системой Требования к документации Порядок приемки Особые условия Приложение 1 Постановка задачи планирования сменно-суточной работы подвижного состава по перевозки железобетонных изделий на стр Общие принципы проектирования ... Полное содержание

Подобный материал:

• Задание на курсовую работу., 709.15kb.
• Техническое задание на выполнение технологических работ по разработке и внедрению автоматизированной, 896.43kb.
• Комплекс стандартов на автоматизированные системы. Техническое задание на создание, 223.53kb.
• Техническое задание на выполнение работ по созданию продукции производственно-технического, 155.05kb.
• Техническое задание на выполнение консалтинговых работ (pr-услуг) по проекту «Стоматологическая, 30.03kb.
• А. Д. Голиков "06" декабря 2007 г. Техническое задание, 94.61kb.
• «Разработка автоматизированной централизованной информационно-аналитической системы, 193.86kb.
• Техническое задание на выполнение работ по созданию сайта листов, 1081.26kb.
• Концепция планирования перевозок грузов на транспорте в системе маркетинга Прогнозирование, 15.53kb.
• Техническое задание на выполнение работы «Создание информационной системы автоматизации, 387.86kb.

ТЕХНИЧЕСКОЕ ЗАДАНИЕ

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

(ПРОТОТИП)


Общие положения


Москва 2006

Содержание

Общие сведения

Наименование работы

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

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

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

Назначение и цели создания системы

Назначение системы.

На практике задача планирования работы ПС относится к числу частично структурированных в аспекте формирования сменно-суточного плана перевозок. В этом случае

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

Предоставление пользователю сформированного сменно-суточного плана – в данном случае строго структурированная задача, когда выполняется

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

Центр диспетчерского управления автоперевозками железобетонных изделий (ЖБИ) на строящиеся объекты (корпуса) с заводов- изготовителей – домостроительных комбинатов (ДСК) ИОУ занимается планированием сменно-суточных планов доставки ЖБИ в соответствии с запланированными часовыми графиками отгрузки ЖБИ с заводов ДСК (монтажными графиками). Отдельная задача – коррекция сменно-суточного плана доставки ЖБИ в режиме реального времени и координация работы диспетчеров колонн автокомбината.

К числу задач, подлежащих автоматизации в перспективе, можно отнести:

• сбор, обобщение, анализ данных о выполнении работы подвижного состава (ПС) на маршрутах на базе мониторинга в реальном масштабе времени или, как вариант, в режиме постфактум с подготовкой ежедневного отчета руководству для обеспечения возможности более оперативно предпринимать выбор альтернативного управляющего воздействия на организацию системы доставки ЖБИ;
  
• подготовка информационных материалов по экстраординарным ситуациям в процессе доставки с целью принятия руководством решений по проведению предупредительных мероприятий, нейтрализации и ликвидации последствий таких ситуаций;
  
• более оперативное осуществление общего контроля и руководства работой диспетчеров филиалов с доведением принятых решений до подчиненных структур;
  
• обеспечение регистрации и архивации данных с размещением «очищенной» информации в хранилищах данных (ХД) и автоматизации поддержки выполнения запросов в процессе ретроспективных аналитических исследований;
  
• оперативное представление данных о состоянии автомобильных дорог и искусственных сооружений на маршрутах доставки ЖБИ.
  

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

Цель выполнения работы

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

Стратегическая цель – повышение эффективности оперативного управления доставкой ЖБИ автотранспортом с отслеживанием режимов работы ПС и выдачей рекомендаций по целенаправленным аргументированным воздействиям на выполнение операций по всей транспортной цепочке.

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

Краткие сведения об объекте автоматизации

Центр диспетчерского управления (ЦДУ) перевозками ЖБИ является структурным подразделением двухуровневой территориально-распределенной системы оперативного управления процессом доставки. Обеспечивает руководство центрами управления нижних уровней – диспетчерских подразделений (например, колонн ОАО «Первый автокомбинат»), а также взаимодействие с диспетчерскими службами заводов ЖБИ.

Реализованная в настоящее время автоматизированная система планирования перевозок требует замены. Необходимо выполнить работы по модернизации и развитию аппаратно-программного комплекса ЦДУ с учетом требований по комплексному развитию диспетчеризации перевозок строительных грузов (см. Приложение 1).

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

Структура системы

Система должна включать следующие функциональные составляющие:

• модернизированный аппаратный комплекс ЦДУ;
  
• системное программное обеспечение;
  
• прикладное программное обеспечение;
  
• система голосовой (телефонной) связи;
  
• система электронной почты;
  
• информационное и организационное обеспечение.
  

В перспективе:

• локальная вычислительная сеть (ЛВС) с выходом в Интернет (канал передачи данных уточняется);
  
• мобильные аппаратно-программные комплексы;
  
• системы беспроводной передачи данных.
  

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

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

• прикладных баз данных и программных комплексов;
  
• информационно-аналитической системы;
  
• геоинформационной системы (ГИС).
  

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

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

Требования к составу персонала (пользователей) системы

Состав персонала (в расширенном варианте) должен включать:

• Администратора системы,
  
• Пользователей системы.
  

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

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

Требования к квалификации персонала, контролю знаний и навыков

Квалификационные требования к персоналу (пользователям) автоматизированной системы ЦДУ, кроме познаний в предметной области, включают оценку:

Администратор системы	Базовых знаний по администрированию сетевых операционных систем, систем управления базами данных; базовых знаний пользователя электронной почты
Пользователь системы	Базовой подготовке пользователя Windows и программ офисной автоматизации Word, Excel; базовых знаний пользователя электронной почты

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

Система должна представлять собой программу для Microsoft Win (XP, 2000) или более поздней версии с графическим пользовательским интерфейсом.

СУБД SQL Server 2003. Общие сведения о языке:

«Стандарты языка реляционных баз данных SQL: краткий обзор»

u/download/www.eManual.ru_540.php

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

IBM PC (не ниже Pentium-3)

оперативная память 128 Мб

разрешение экрана - 800х600, True Color (24 разряда)

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

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

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

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

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

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

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

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

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

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

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

Требования по эргономике и технической эстетике

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

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

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

Требования к функциям, выполняемым системой

Должны быть реализованы следующие функции:

• автоматизированный и ручной ввод данных монтажных графиков в согласованных форматах и протоколах;
  
• выполнение операций по планированию сменно-суточного плана работы ПС с учетом заданных временных и других ограничений на базе экспертно-аналитических расчетов и предоставлению диспетчеру ЦДУ альтернатив для выбора варианта задания для каждой единицы ПС;
  
• анализ полученных данных и формирование отчетов в соответствии с утвержденными формами;
  
• агрегацию и накопление информации в архивной базе данных – хранилище данных (ХД, DW);
  
• навигацию и просмотр архивных данных, накапливаемых системой.
  

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

В состав поставляемой документации входят:

• Руководство пользователя.
  
• Краткие методические материалы по применению системы.
  

Документация предоставляется в печатном виде (1 экземпляр) и на носителе (компакт-диск).

Порядок приемки

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

Особые условия

При изменении или дополнении настоящего технического задания должно быть оформлено отдельное соглашение (дополнение к ТЗ).

Авторское право – сохраняется за разработчиками.

Приложение 1

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

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

Используя традиционные подходы к построению систем обработки данных применительно к данному проекту, возникает потребность отметить определенные сложности:

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

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

Естественный вывод – предложение о проектировании системы обработки данных и знаний (СОЗД) или автоматизированной экспертной системы поддержки принятия решений (АЭ СППР).

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

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

ЕСЛИ < условие > ТО < действие >

ИНАЧЕ < действие >.

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

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

2. Основные задачи по этапам проектирования.

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

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

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

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

Определяются следующие особенности:

1. Типы доступных данных.

2. Выводимые данные (данные, получаемые на основе исходных данных).

3. Подзадачи общей задачи (внутренняя иерархия).

4. Используемые стратегии и алгоритмы.

5. Виды и типы взаимосвязей между объектами ПрО.

6. Типы ограничений, накладываемых на процесс решения.

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

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

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

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

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

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

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

2. Имеется много похожих правил на множество частных случаев, а в ПрО существуют понятия, явно не указанные экспертом. Задача инженера по знаниям - объединить несколько правил в одно (метаправило).

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

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

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

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

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

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

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

Основными видами модификации систем подобного типа являются:

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

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

На практике задача планирования работы ПС относится к числу частично структурированных в аспекте формирования сменно-суточного плана перевозок. В этом случае

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

Предоставление пользователю сформированного сменно-суточного плана – в данном случае строго структурированная задача, когда выполняется

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

4. Вербальное описание решаемой проблемы

Начать с описания предметной области (в плане последовательности работы диспетчера по планированию работы ПС).

5. Даталогическая модель

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

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




Рисунок 1. Схема данных.