В. Ляшков, ФОРС
Немного о заказчике
Область применения автоматизированных систем на терминале
Что предшествовало началу разработки
Как проходила разработка
Как проходит внедрение
О применении зарубежных методологий разработки программных
систем в российских условиях
Влияние существующей системы на разработку и внедрение новой
Обеспечение безболезненного перехода со старой системы на новую
Реальный уровень затрат заказчика при разработке большой системы
Предприятие является официальным грузовым агентом IATA, имеет лицензию Общероссийского таможенного перевозчика, является членом Ассоциации Международных автоперевозчиков (АСМАП), декларантом на договорной основе (таможенным брокером).
АО "Шереметьево-Карго" имеет собственную сеть агентств во Франции, Германии, Италии, взаимодействует со многими аналогичными иностранными фирмами. Оно развивает и эксплуатирует крупнейший в России грузовой таможенный терминал с пропускной способностью 550 тысяч тонн груза в год, грузовой автопарк, обеспечивает продажу грузовых авиаперевозок ведущих авиакомпаний мира, организует смешанные перевозки по РФ.
Шереметьево-Карго является крупным предприятием, на котором работает более 1500 человек, обрабатывающих до 3000 накладных и грузов по ним в сутки. Режим работы предприятия - круглосуточный.
В настоящее время АО функционирует в условиях бурного развития транспортного бизнеса, происходящего на фоне изменения законодательства в стране и быстрого развития транспортных технологий. Являясь лидером среди организаций подобного рода, АО непрерывно развивает и совершенствует свои технологии.
ИМПОРТ включает в себя выгрузку груза из самолета, доставку его на склад, раскомплектацию груза , проведение таможенных операций и размещение груза на складе. Далее следует извещение получателя о прибывшем грузе, опять таможенные операции и наконец выдача груза со склада клиенту. Попутно возможно оказание получателю разнообразных услуг, за которые следует выставлять счета и контролировать их оплату.
ЭКСПОРТ начинается с продажи перевозки отправителю груза, бронирования перевозки, выпуска договора перевозки - авианакладной, получения оплаты, приема груза на склад при участии таможни. Далее, за некоторое время до вылета рейса начинается селекция и комплектация груза на рейс, доставку его со склада к борту самолета и его загрузка.
ТРАНЗИТ является совокупностью первых двух процессов, зачастую с добавлением ряда промежуточных операций.
Основные технологические процессы сопровождаются рядом поддерживающих процессов:
Все процессы обработки груза и взаимодействия со всеми заинтересованными сторонами сопровождаются интенсивным потоком документов. Основные взаимодействующие с грузовым терминалом стороны таковы:
Очевидно, что столь многофункциональная деятельность невозможна без применения современных информационных технологий и автоматизированных систем. Применение таких систем позволяет уменьшить сроки и повысить качество обработки грузов. Это достигается благодаря более полному контролю исполнения технологического цикла и уменьшению потерь и нарушений при обработке груза.
Эта система эксплуатируется до последнего времени и обслуживает 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 месяцев - тестирование и внедрение.
Для анализа требований и проектирования в ФОРСе была образована группа под руководством опытного аналитика, ранее работавшего с 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% общего объема данных, вводимых в старую систему.
Указанные выше режимы работы новой системы вводились последовательно для каждого типа рабочих мест, согласно плана-графика развертывания рабочих мест. Первыми вводились рабочие места, обслуживающие процесс ЭКСПОРТ, затем - ИМПОРТ.
На первом этапе опытной эксплуатации рабочие места процесса ЭКСПОРТ подключались к опытному стенду и находились в асинхронном режиме работы.
Через два месяца был установлен промышленный сервер, к нему были подключены уже развернутые рабочие места процесса ЭКСПОРТ и началось развертывание и подключение рабочих мест процесса ИМПОРТ. Для процесса ЭКСПОРТ был введен неполный синхронный режим, а для процесса ИМПОРТ - асинхронный.
В настоящее время, после семи месяцев опытной эксплуатации:
Далее обсуждается ряд вопросов, которые представляют на наш взгляд определенный интерес:
Как известно, классические CASE-методологии разрабатывались с целью уменьшения риска в процессе выполнения проекта. Считалось, что если готовое программное обеспечение не удовлетворяет пользователя, то это результат упущений при постановке задачи. Следствием этого подхода стало увеличение времени, отведенного на стадии анализа и чистого проектирования, а программирование стало считаться чисто техническим этапом работ. На протяжении всего проекта генерируется мощный поток документов о ходе работ, в основном Progress Reports, призванных убедить заказчика, что работы идут нормально. Работы ведутся линейно, итеративность не приветствуется. Пользователь привлекается к работам в основном на этапах анализа и внедрения. Примером реализации такой методологии является ORACLE CASE*METHOD Classic.
Однако жизнь показала, что линейная неитеративная схема с большими сроками постановки задач в некоторых ситуациях неработоспособна. Это следующие ситуации:
Поэтому в последнее время получили распространение методы Rapid Application Development (RAD), предполагающие:
Примером такой идеологии является ORACLE CASE*METHOD Fast Track.
Если рассмотреть требования российских ГОСТов в сравнении с классическим CASE*METHOD, то получится следующее:
| CASE*METHOD | ГОСТ |
|---|---|
| Strategy | Техническое задание |
| Analysis | Технический проект |
| Design | |
| Build | Рабочая документация |
| Transition,Documentation | |
| Production | Ввод в действие |
Как видно, по российским стандартам существенно короче этап анализа требований, а проектирование и кодирование как правило резко не разделяются. Этим российская традиция близка к RAD-методам.
Однако наши ГОСТы также не приветствуют итеративность и к тому же требуют в Техническом проекте описания всех форм и отчетов системы, а также подробного описания алгоритмов, что близко к классическому CASE.
ORACLE Designer/2000 поддерживает как Classic, так и Fast Track, однако при его применении необходимо учитывать следующее:
Реально работающая методология является разумным компромиссом между этими подходами и при использовании Designer/2000 может выглядеть примерно так:
Положительным является то, что у заказчика есть работающий коллектив по поддержке системы, а пользователи обучены воспринимать работу с компьютерным оборудованием как необходимую часть техпроцесса. Немаловажно также, что руководители заказчика представляют себе выгоды, связанные с наличием работающей системы.
Отрицательное влияние старой системы особенно ярко проявляется в следующих моментах (особенно, если система является важной частью технологического процесса):
В связи с этим был разработан документ, регламентирующий вид пользовательского интерфейса для разрабатываемой системы. Согласование данного документа с заказчиком длилось более трех месяцев! В результате разработчикам в ряде случаев пришлось систематически применять нестандартные для SQL*Forms приемы программирования.
Выводы можно сделать такие:
Основные положения:
Такой подход оказывается возможным потому, что среднее время жизни 80% актуальных данных в системе (за исключением справочников) составляет две недели, поэтому время одновременной промышленной работы двух систем сравнительно невелико. Следовательно нет необходимости в автоматизированном обмене данными между системами.
План-график плавного перехода предусматривает сначала переход всего процесса ЭКСПОРТ на новую систему в течение недели.
Процесс ИМПОРТ переводится на новую систему поэтапно, по подразделениям, обслуживающим рейсы на те или иные направления
Нагрузка на руководство и персонал заказчика резко увеличивается с момента подготовки к испытаниям и начинает уменьшаться только после ввода системы в промышленную эксплуатацию, причем этот процесс захватывает большинство персонала. Поэтому, чем длительный процесс внедрения, тем больше скрытых затрат несет заказчик, следовательно необходимо добиваться минимальной длительности этапов опытной эксплуатации и перехода на новую систему. Это известный факт, но его нелишне напомнить.