Назад в раздел Разработка и внедрение системы автоматизации большого авиагрузового терминалаВ. Ляшков, ФОРС
Немного о заказчике AО "Шереметьево-Карго" - одно из крупнейших авиатранспортных предприятий в Российской Федерации, предоставляющее услуги по организации перевозки, обработке и экспедированию грузов по транспортным маршрутам России и за ее пределами. Предприятие является официальным грузовым агентом IATA, имеет лицензию Общероссийского таможенного перевозчика, является членом Ассоциации Международных автоперевозчиков (АСМАП), декларантом на договорной основе (таможенным брокером). АО "Шереметьево-Карго" имеет собственную сеть агентств во Франции, Германии, Италии, взаимодействует со многими аналогичными иностранными фирмами. Оно развивает и эксплуатирует крупнейший в России грузовой таможенный терминал с пропускной способностью 550 тысяч тонн груза в год, грузовой автопарк, обеспечивает продажу грузовых авиаперевозок ведущих авиакомпаний мира, организует смешанные перевозки по РФ. Шереметьево-Карго является крупным предприятием, на котором работает более 1500 человек, обрабатывающих до 3000 накладных и грузов по ним в сутки. Режим работы предприятия - круглосуточный. В настоящее время АО функционирует в условиях бурного развития транспортного бизнеса, происходящего на фоне изменения законодательства в стране и быстрого развития транспортных технологий. Являясь лидером среди организаций подобного рода, АО непрерывно развивает и совершенствует свои технологии. Область применения автоматизированных систем на терминале Первоочередной задачей системы автоматизации терминала является обслуживание основного технологического цикла обработки грузов. Цикл состоит из следующих технологических процессов: ИМПОРТ, ЭКСПОРТ и ТРАНЗИТ. ИМПОРТ включает в себя выгрузку груза из самолета, доставку его на склад, раскомплектацию груза , проведение таможенных операций и размещение груза на складе. Далее следует извещение получателя о прибывшем грузе, опять таможенные операции и наконец выдача груза со склада клиенту. Попутно возможно оказание получателю разнообразных услуг, за которые следует выставлять счета и контролировать их оплату. ЭКСПОРТ начинается с продажи перевозки отправителю груза, бронирования перевозки, выпуска договора перевозки - авианакладной, получения оплаты, приема груза на склад при участии таможни. Далее, за некоторое время до вылета рейса начинается селекция и комплектация груза на рейс, доставку его со склада к борту самолета и его загрузка. ТРАНЗИТ является совокупностью первых двух процессов, зачастую с добавлением ряда промежуточных операций. Основные технологические процессы сопровождаются рядом поддерживающих процессов: Ведением расписания и отслеживанием графика выполнения техпроцессов; Отслеживанием состояния и подготовкой авиационной тары; Оказанием разнообразных услуг клиентам, начислением оплаты и отслеживанием платежей; Поддержкой функционирования разветвленного складского хозяйства (это называется модным термином складская логистика); Выяснением неисправностей при перевозках, в том числе розыск груза и идентификация груза без маркировки. Все процессы обработки груза и взаимодействия со всеми заинтересованными сторонами сопровождаются интенсивным потоком документов. Основные взаимодействующие с грузовым терминалом стороны таковы: Отправители и получатели груза; Авиакомпании - перевозчики; Таможня. Очевидно, что столь многофункциональная деятельность невозможна без применения современных информационных технологий и автоматизированных систем. Применение таких систем позволяет уменьшить сроки и повысить качество обработки грузов. Это достигается благодаря более полному контролю исполнения технологического цикла и уменьшению потерь и нарушений при обработке груза. Что предшествовало началу разработки Опыт применения информационных систем в Шереметьево-Карго довольно давний. С 1985 г в АО работает информационная система SIGMA, французского производства на ЭВМ MITRA с сетевой СУБД типа CODASYL и программным обеспечением, написанным на COBOL. Эта система эксплуатируется до последнего времени и обслуживает 100 одновременных on-line пользователей, 20 типов рабочих мест. С 1985 года прошло уже более 10 лет и к настоящему моменту система SIGMA по ряду параметров перестала удовлетворять АО. Во-первых, такое оборудование, как и запасные части для него уже давно не выпускают, что приводит к регулярным сбоям и аварийным остановам системы, приносящим большие убытки. Во-вторых, программное обеспечение не удовлетворяет требованиям по сохранению данных в результате сбоев оборудования, и кроме того обладает рядом ограничений на объемы используемых данных. В-третьих, развитие транспортных технологий потребовало расширения функциональности программного обеспечения, а используемая технология не позволяет гибко и быстро модифицировать устаревшие программные единицы или добавлять новые. В-четвертых, система SIGMA морально устарела. Было принято решение о необходимости перехода на новую систему. В процессе анализа ситуации варианты закупки зарубежной системы или разработки собственными силами были отвергнуты как нереальные, и был сделан вывод о необходимости разработки новой системы силами российских разработчиков. Основные требования к процессу разработки новой информационной системы и ее свойствам формулировались следующим образом: Для построения информационно-функциональной модели предприятия обязательно использовать CASE-инструментарий. Эту модель предполагалось использовать далее при реорганизации предприятия и разработке требований к другим информационным системам, а также использовать ее для поддержки жизненного цикла и дальнейшего развития разрабатываемой системы. Применять CASE-методологию при разработке системы на всех этапах. Использовать мощную современную СУБД, обеспечивающую управление большими объемами данных и современный уровень защиты данных от сбоев. В связи с тем, что предполагаемый срок жизни системы составляет 10-15 лет, применяемое системное программное обеспечение должно иметь высокий уровень мобильности и масштабируемости и быть от лидирующего поставщика. Число одновременно работающих пользователей в системе - 150. В начале 1994 года АО "Шереметьево-Карго" провело тендер, который совместно выиграли фирмы Интегпрог и ФОРС. Предполагалось, что вопросами поставки аппаратных средств и системной интеграцией занимается Интегпрог, а программное обеспечение разрабатывает ФОРС. В качестве аппаратного решения был предложен сервер AViiON фирмы Data General с архитектурой SMP и операционной системой DG-UX. Сетевая среда - Ethernet. Основными оконечными устройствами пользователя являются символьные терминалы, подключенные к терминальным серверам. В качестве СУБД предложен ORACLE7, как полностью отвечавший требованиям заказчика. Средством проектирования избран Oracle CASE 5.0 в силу его высокой интегрированности со средствами разработки, поддержкой многопользовательской работы и всего цикла разработки системы. Основными средствами разработки были предложены SQL*Forms 3.0 и SQL*Menu 5.0, хорошо зарекомендовавшие себя при работе в символьном режиме. Длительность проекта по разработке прикладного программного обеспечения была установлена в 22 месяца, из которых 6 месяцев выделялось на анализ требований и проектирование, следующие 10 месяцев - генерацию и кодирование, и еще 6 месяцев - тестирование и внедрение. Работы начались и проводились в полном соответствии с идеологией CASE*METHOD. Для анализа требований и проектирования в ФОРСе была образована группа под руководством опытного аналитика, ранее работавшего с Oracle CASE. После завершения анализа, на этапе проектирования, планировалось передать дела группе разработчиков. Заказчиком, АО "Шереметьево-Карго" и системным интегратором были организованы группы по надзору за исполнением проекта. Большим плюсом было то, что заказчик располагает как квалифицированными бизнес-аналитиками, хорошо представляющими себе используемые технологии обработки грузов, так и опытными компьютерными специалистами, обслуживающими старую систему SIGMA. Анализ требований проводился в тесном сотрудничестве с бизнес-аналитиками и системными программистами заказчика. Были сданы и подписаны результаты стадий стратегии и анализа. Началась стадия проектирования, которая неожиданно затянулась, поскольку результаты работ не утверждались заказчиком. Нормальные рабочие отношения между сотрудничавшими ранее группами заказчика и исполнителя стали напряженными. Отставание работ от плана становилось значительным, уже должен был давно начаться этап программирования. В это время, на десятом месяце проекта, как и планировалось, к работам по данному проекту была подключена наша группа разработчиков. Ситуация требовала быстрого анализа и принятия решений по поводу дальнейшей разработки, так как конечные сроки завершения проекта не могли быть изменены. Изучение ситуации показало, что обследование и анализ предметной области были проведены с достаточной полнотой, собрано и структурировано много материала. В репозитарии Oracle CASE существовала достаточно подробная ER-модель, пригодная для разработки базы данных. Имелось пригодное для кодирования описание автоматизируемых функций, которое однако содержалось в файлах MS Word! При этом между группами исполнителя и заказчика существовали расхождения по числу и объему функций, подлежащих автоматизации. Представители заказчика выражали тревогу по поводу отсутствия работающих программ. Часть проблем возникла из-за отличия западной и российской культур разработки информационных систем. Развивавшаяся десятки лет советская школа разработки информационных систем выработала отличные от западной подходы, терминологию, этапность, документацию. Это все регламентируется государственными стандартами. В CASE*Method названия этапов и их продолжительность, а также состав работ не совпадают с требованиями российских стандартов По российским стандартам существенно короче этап анализа требований, а проектирование и кодирование как правило резко не разделяются. Естественно, не получив после этапов Strategy и Analysis ни одного знакомого документа, заказчики заволновались. К тому же CASE 5.0 не был русифицирован. Можно представить себе состояние руководителя, ожидающего получить проектные документы, а ему в третий раз приносят документ, относящийся к анализу требований, имеющий непонятное название и на 90% содержащий английский текст! Вот откуда и появились описания функций в MS Word... Соответственно, информационная модель оказалась отрезанной от описания функций и ни о какой генерации системы речи идти не могло. Другая часть проблем возникла из-за нечетко очерченных в начале анализа требований границ системы. Одной из главных причин этого являлось отсутствие одинаково трактуемого всеми документа, фиксирующего эти границы. Остальные проблемы возникли из-за совмещения должностей начальника проекта и главного аналитика в группе исполнителя. Такое совмещение в данном проекте не позволило уделять достаточно времени контактам с руководством заказчика и разъяснению применяемых подхода и методов. Положение следовало исправлять. В приступившей к работе группе разработки руководитель сосредоточился на доработке бизнес-модели, подготовке документов, общении с заказчиками и оперативном управлении. Был также назначен главный программист, ответственный за групповую разработку базы данных и приложений. В то же время началась активная работа в области обучения заказчика технологиям Oracle, которая продолжается по сей день. Поскольку огромное количество подготовленного материала не воспринималось заказчиком как нечто документальное, то сразу началась подготовка Технического Задания - привычного заказчику документа, фиксирующего границы системы. Одновременно началась разработка базы данных на основе существующей информационной модели. В этой связи был осуществлен переход на Designer 2000, обладающий мощными возможностями моделирования данных. Такой переход полностью себя оправдал. Богатая функциональность Data Diagrammer'а и поддержка групповой работы позволили быстро получить приемлемую схему базы данных, а его хорошие презентационные возможности - успешно представить ее заказчику. По прошествии четырех недель было подписано Техническое Задание и заказчик был ознакомлен со схемой базы данных. Напряжение заметно спало, стало налаживаться конструктивное сотрудничество. Следующим шагом было начато программирование по уже имеющимся согласованным спецификациям. Для этого была применена технология вертикального слоения программного продукта, которая подразумевает выделение и реализацию некоторого ядра - набора программных компонент, обеспечивающих всю необходимую обработку входных данных, но не всех, а некоторой выделенной их части. Далее по известной технологии вносятся рассредоточенные изменения в реализованные программные компоненты, добавляющие новый вертикальный слой. Это позволяет расширить набор входных данных. И так далее. По имеющимся спецификациям было выделено ядро системы, реализующее идеальный технологический цикл авиационного грузового комплекса. В ядре были выделены непересекающиеся технологии на соответствующих наборах данных. Был составлен план-график внесения дополнений в программное обеспечение. Для этого была пересмотрена этапность работ с сохранением срока окончания проекта. Одновременно началась подготовка Технического Проекта, составной частью которого должна была стать функциональная модель, разработанная средствами Designer 2000. Улучшенные презентационные возможности и поддержка русского языка позволили успешно сотрудничать в создании функциональной модели предприятия. Принятые решения привели к желаемым результатам. Программное ядро системы было досрочно установлено у заказчика и позволило начать комплексные испытания по всему технологическому циклу на ограниченных наборах входных данных, хотя объем закодированных функций составлял не более 35-40% от конечного. Официальные комплексные испытания ядра программного обеспечения были проведены через шесть месяцев после подписания Технического задания. После этого последние сомнения у заказчика отпали. Официальные комплексные испытания всего программного обеспечения начались еще через два месяца и проходили в три этапа в течение трех месяцев. Испытания проводились на опытном стенде заказчика силами специально подготовленных пользователей. Испытания были закончены в тот срок, который намечался для завершения проекта. Предстояла опытная эксплуатация. На этом этапе предстояло решить ряд достаточно сложных задач: Установить промышленный сервер и сконфигурировать его; Развернуть сеть рабочих мест по всему предприятию; Провести полное обучение и аттестацию всех пользователей системы; Наладить функционирование новой системы в режиме параллельной работы со старой; Провести приемку программного обеспечения, исходных текстов и документации. Для этого были разработаны два документа под названием "Программа опытной эксплуатации" и "Концепция плавного перехода", определяющие этапы развертывания новой системы и постепенного перехода со старой системы на новую. Программой опытной эксплуатации предусматривались три последовательных режима работы относительно старой системы: Асинхронный режим, когда работа по конкретным документам в новой системе происходила независимо от старой системы; Синхронный режим с неполными данными, когда данные вводятся в старую и новую систему одновременно, но в новую систему вводятся не все данные по документу; Полный синхронный режим с параллельным вводом данных. Обмен данных между системами не предусматривался. Предполагалось, что при синхронных режимах объем данных, вводимых параллельно в обе системы составит 10-15% общего объема данных, вводимых в старую систему. Указанные выше режимы работы новой системы вводились последовательно для каждого типа рабочих мест, согласно плана-графика развертывания рабочих мест. Первыми вводились рабочие места, обслуживающие процесс ЭКСПОРТ, затем - ИМПОРТ. На первом этапе опытной эксплуатации рабочие места процесса ЭКСПОРТ подключались к опытному стенду и находились в асинхронном режиме работы. Через два месяца был установлен промышленный сервер, к нему были подключены уже развернутые рабочие места процесса ЭКСПОРТ и началось развертывание и подключение рабочих мест процесса ИМПОРТ. Для процесса ЭКСПОРТ был введен неполный синхронный режим, а для процесса ИМПОРТ - асинхронный. В настоящее время, после семи месяцев опытной эксплуатации: Установлены и подключены к промышленному серверу все рабочие места системы; Рабочие места процесса ЭКСПОРТ функционируют в полном синхронном режиме, причем объем вводимых в новую систему данных составляет 50% всех данных по процессу ЭКСПОРТ; Рабочие места процесса ИМПОРТ находятся в неполном синхронном режиме и функционируют с запланированной нагрузкой; Идет аттестация пользователей системы; Идет приемка программного обеспечения и документации системы. Далее обсуждается ряд вопросов, которые представляют на наш взгляд определенный интерес: Применение зарубежных методологий разработки в российских условиях; Влияние существующей автоматизированной системы на процесс разработки и внедрения; Обеспечение безболезненного перехода со старой системы на новую; Реальный уровень затрат заказчика при разработке большой системы. О применении зарубежных методологий разработки программных систем в российских условиях В данном разделе мы ограничимся обсуждением методологии CASE*METHOD (Classic и Fast Track) и инструментария Designer/2000. Как известно, классические CASE-методологии разрабатывались с целью уменьшения риска в процессе выполнения проекта. Считалось, что если готовое программное обеспечение не удовлетворяет пользователя, то это результат упущений при постановке задачи. Следствием этого подхода стало увеличение времени, отведенного на стадии анализа и чистого проектирования, а программирование стало считаться чисто техническим этапом работ. На протяжении всего проекта генерируется мощный поток документов о ходе работ, в основном Progress Reports, призванных убедить заказчика, что работы идут нормально. Работы ведутся линейно, итеративность не приветствуется. Пользователь привлекается к работам в основном на этапах анализа и внедрения. Примером реализации такой методологии является ORACLE CASE*METHOD Classic. Однако жизнь показала, что линейная неитеративная схема с большими сроками постановки задач в некоторых ситуациях неработоспособна. Это следующие ситуации: За время выполнения проекта изменяются требования заказчика к функционированию системы; Невозможно получить постановку задачи от пользователя, предварительно не показав ему, как программа может работать; Заказчик не может понять, почему столько времени и денег уходит на написание бумаг, которые не приносят ему непосредственной пользы (чисто русская ситуация). Поэтому в последнее время получили распространение методы Rapid Application Development (RAD), предполагающие: Относительное уменьшение времени на чистую (бумажную) постановку; Принципиальное допущение итеративности разработки, с коррекцией требований; Непосредственное интенсивное взаимодействие разработчиков с пользователями на протяжении всего проекта; Жесткое соблюдение временных рамок работ при регулярно проводимой приоритезации требований, позволяющей добавлять более приоритетные новые требования в обмен на менее приоритетные старые. Примером такой идеологии является ORACLE CASE*METHOD Fast Track. Если рассмотреть требования российских ГОСТов в сравнении с классическим CASE*METHOD, то получится следующее:
Как видно, по российским стандартам существенно короче этап анализа требований, а проектирование и кодирование как правило резко не разделяются. Этим российская традиция близка к RAD-методам. Однако наши ГОСТы также не приветствуют итеративность и к тому же требуют в Техническом проекте описания всех форм и отчетов системы, а также подробного описания алгоритмов, что близко к классическому CASE. ORACLE Designer/2000 поддерживает как Classic, так и Fast Track, однако при его применении необходимо учитывать следующее: Генерируемая с его помощью документация как правило не русифицирована; Состав и структура этой документации крайне непривычны русскому заказчику, в частности, не содержат пространных описаний; Генерация исполняемых модулей до сих пор является в основном декларируемой возможностью и по большей части бесполезна, а это значит, что диаграммеры верхнего уровня пригодны только для задач презентации результатов, но никак не для построения программной системы; Средства разработки серверной части полностью поддерживают групповую работу и полезны на любом уровне общности. Реально работающая методология является разумным компромиссом между этими подходами и при использовании Designer/2000 может выглядеть примерно так: На этапе постановки задачи составляются "Описание технологического процесса", снабженное всеми видами диаграмм от Designer/2000 (используются диаграммеры верхнего уровня) и Техническое задание, задающее, в том числе, границы системы. Эта работа выполняется аналитиками. В ней обязательно участвует главный программист проекта. Далее идет этап интерактивной разработки, выполняемой программистами-разработчиками. На этом этапе происходит уточнение требований и, при необходимости, их изменение. Работа ведется в непосредственном контакте с пользователями. На этом этапе используются диаграммеры нижнего уровня Designer/2000 и выбранные средства разработки. Технический проект не разрабатывается, однако принципиальные вопросы регулируются отдельными документами (например требования к интерфейсу пользователя, взаимодействие с внешними системами и т.д.). Этот этап заканчивается испытаниями системы и подготовленной к испытаниям предварительной документацией. Далее идет этап опытной эксплуатации, на котором также готовится эксплуатационная документация и описание системы. Крайне желательно суметь разделить систему на части, запускаемые в опытную эксплуатацию в разное время, поскольку работающая часть системы весьма стимулирует активность и решимость заказчика, направленные на введение в действие всей системы. Если не удается выделить сравнительно независимые части системы, то следует воспользоваться методом вертикального слоения, выделив некоторое ядро. Влияние существующей системы на разработку и внедрение новой Это влияние имеет как положительные, так и отрицательные стороны. Положительным является то, что у заказчика есть работающий коллектив по поддержке системы, а пользователи обучены воспринимать работу с компьютерным оборудованием как необходимую часть техпроцесса. Немаловажно также, что руководители заказчика представляют себе выгоды, связанные с наличием работающей системы. Отрицательное влияние старой системы особенно ярко проявляется в следующих моментах (особенно, если система является важной частью технологического процесса): При определении границ системы заказчик будет настаивать на том, чтобы новая система как минимум исполняла ВСЕ функции старой, даже если в новой системе нет в них необходимости; Пользователи, привыкшие к старому (даже неудобному) интерфейсу, воспримут новый интерфейс, как правило, в штыки. Например, в начале автономного тестирования модулей ядра обнаружилось сильное неприятие пользователями интерфейса, обеспечиваемого SQL*Forms 3.0. Тому виной были большое количество используемых функциональных клавиш, сложность навигации по экрану и некоторые другие особенности. В связи с этим был разработан документ, регламентирующий вид пользовательского интерфейса для разрабатываемой системы. Согласование данного документа с заказчиком длилось более трех месяцев! В результате разработчикам в ряде случаев пришлось систематически применять нестандартные для SQL*Forms приемы программирования. Выводы можно сделать такие: Еще на этапе разработки Технического задания, до его подписания, необходимо тщательно изучить старую систему на предмет ее функциональности и интерфейса; В это же время необходимо начать разъяснительную работу среди руководителей и обучение персонала новым технологиям. Упущенное здесь время все равно потом добавится (причем в гораздо большем количестве) к общей длительности проекта. При составлении Технического задания необходимо представить сравнение функций старой и разрабатываемой систем, с тем, чтобы не возвращаться к этому позже (скажем, на этапе приемки). Обеспечение безболезненного перехода со старой системы на новую В данном разделе представлены основные положения документа под названием "Концепция плавного перехода", регулирующего вопросы безболезненного перехода со старой системы на новую. Данный документ является совместным трудом заказчика и обоих разработчиков системы. Он разрабатывался и согласовывался в течение шести месяцев.
Основные положения:
Процесс замены оборудования должен быть разнесен по времени с переходом на новую прикладную информационную систему;
Переход на новую систему должен быть поэтапным и однонаправленным, возврат к старой системе недопустим;
Автоматизированного обмена данными между системами не предусматривается;
В целях минимизации риска и уменьшения накладных организационных расходов необходимо обеспечить: Такой подход оказывается возможным потому, что среднее время жизни 80% актуальных данных в системе (за исключением справочников) составляет две недели, поэтому время одновременной промышленной работы двух систем сравнительно невелико. Следовательно нет необходимости в автоматизированном обмене данными между системами. План-график плавного перехода предусматривает сначала переход всего процесса ЭКСПОРТ на новую систему в течение недели. Процесс ИМПОРТ переводится на новую систему поэтапно, по подразделениям, обслуживающим рейсы на те или иные направления Реальный уровень затрат заказчика при разработке большой системы
Общеизвестно, что затраты заказчика при разработке большой автоматизированной системы не ограничиваются оплатой работы исполнителя. Ниже приведен список работ, проводимых руководством и специалистами заказчика:
Постановка задачи, выяснение, реинжиниринг и согласование технологии;
Нагрузка на руководство и персонал заказчика резко увеличивается с момента подготовки к испытаниям и начинает уменьшаться только после ввода системы в промышленную эксплуатацию, причем этот процесс захватывает большинство персонала. Поэтому, чем длительный процесс внедрения, тем больше скрытых затрат несет заказчик, следовательно необходимо добиваться минимальной длительности этапов опытной эксплуатации и перехода на новую систему. Это известный факт, но его нелишне напомнить. | |||||||||||||||||
| ||
|