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

Технология Х-протокола -- одна из самых простых и открытых. Она изначально разработана для использования в сетях. Все необходимое для создания ПО доступно в Интернете бесплатно. Задача построения систем сводится к написанию программ на С++, связанных с СУБД вызовами соответствующих API-функций SQL-серверов.

Экономия вычислительных ресурсов позволяет обслуживать большое количество клиентов. Существует огромное число написанных приложений в данной технологии. Серверы X-Window имеются для DOS, MS Windows, MacOS, что позволяет легко обращаться к графическим программам с этих платформ.



Таблица 8.1

Построение аппаратного и компьютерного обеспечения

Отечественный подход	Опыт зарубежных стран
Аппаратное Маломощный сервер Дорогое сетевое оборудование Дорогие рабочие станции (ПК) Программное На сервере: Microsoft Windows NT или Nowell NetWare На рабочих станциях: Microsoft Windows 95, 98 Программы выполняются на рабочих станциях, данные хранятся на сервере. В лучшем случае используется технология клиент-сервер Программы приобретаются в готовом виде, модернизируются с трудом	обеспечение Мощный центральный сервер Недорогое сетевое оборудование Недорогие терминалы обеспечение На сервере: Unix или Microsoft Windows NT Terminal Server На терминалах: ПО для показа информации с сервера (штатное) Создаются программы, хранимые (как и данные) на сервере Программы, написанные на заказ, легко модернизируются

Компания Microsoft предлагает копроративным клиентам недорогие решения. Огромное количество существующего ПО для DOS, Windows 3.1, Windows 95, Windows 2000 и NT продолжает работать на этой платформе. К сожалению, для каждого клиента создается свое виртуальное адресное пространство, с загрузкой в память всех необходимых для данной программы библиотек. При запуске большого количества приложений клиентами значительное количество загружаемого программного кода нерационально расходует ресурсы системы. Сама компания Microsoft рекомендует на каждые 15 клиентов использовать 128 Мбит оперативной памяти и один процессор.

Повсеместное распространение Интернета не могло не повлиять на развитие программной индустрии. Поэтому разработчики СУБД создают соответствующие интерфейсы. Oracle, InterBase Software, Informix и многие другие фирмы создают свои версии. Однако существуют и универсальные инструменты, специально предназначенные для удобства разработчиков, позволяющие абстрагироваться как от типа сервера, так и от платформы работы, будь то Unix, Windows или MacOS. Для создания небольших программ достаточно стандартного HTML, а для больших задач на клиентской части подходит Javan Javascript.В этой связке удачно реализуется тройственная технология: на центральном компьютере устанавливается SQL-сервер для хранения информации, на нем же устанавливается HTTP-сервер со страницами, содержащими обращения к CGI-скриптам центрального приложения (или содержащими инструкции на выполнение SQL-запросов в самих страницах), и запускается центральное приложение. Все эти задачи могут выполняться на разных компьютерах, объединенных в высокоскоростную сеть. Клиентским частям системы остается только запуск броузера и интерфейс.

Производители графических терминалов теперь поставляют свои изделия, совместимые со всеми перечисленными выше технологиями. Использование имеющегося парка компьютеров также возможно, так как производители первых двух технологий сами создают решения для разных платформ (Х-серверы и Remote Desktop Client есть для Unix, Windows и MacOS), третья же технология -- по определению многоплатформенная.

В настоящее время все более популярной становится операционная система Linux. Эта бесплатная Unix-подобная операционная система обладает всеми достоинствами современной высокопроизводительной ОС. Linux используют более 10 миллионов пользователей во всем мире. Она обладает рядом важных достоинств.

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

* Цена. Система распространяется практически бесплатно -- по цене носителя на CD-ROM или из Интернета. Большинство приложений для Linux также распространяются бесплатно: С++, Perl, Apache, Interbase, Oracle, Informix, Sybase, Ingres, DB2 и т.д.

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

* Надежная поддержка. Малейшие ошибки устраняются мгновенно, лучше и быстрее, чем в коммерческих ОС.

* Распространенность. Linux используется во всем мире. Для Linux написано огромное количество утилит и программ.

* Масштабируемость. Если вам не хватает мощности, можно ставить много процессоров, переходить на другие платформы, создавать вычислительные кластеры. Linux работает на Intel, Alpha, PowerPC и других 16-, 32- и 64-разрядных и многопроцессорных системах.

Почему ИС часто терпят неудачу, если требуется проинтегрировать хотя бы небольшую часть из этих объектов в рамках единой АСУП? Традиционные системы были разработаны так, чтобы сохранить только табличный текст и числовые данные, т. е. были способны управлять только малой частью общей информации компании. Хорошо справляясь со своей работой по ведению электронного учета и составления счетов, такие информационные системы не могут эффективно сохранять и обрабатывать другие типы данных, как видео- и аудиообразы, пространственные данные или web-страницы. Очевидно, что основным элементом информационной системы предприятия, который отвечает за эти функции, является БД.

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

Компьютерные технологии вышли на новый виток развития, когда отчетливо просматривается стремление перенести в виртуальный мир объекты мира реального с минимальными потерями. Объектная СУБД -- именно то средство, которое обеспечивает запись объектов в БД в том виде, который соответствует их реальной конфигурации. «What You have coded is what You put in database* -- «Все, что вы запрограммировали, вы помещаете в базу данных» -- вот девиз такой СУБД.

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

Примером функциональных возможностей современной ИПС, представленной на российском рынке, является ODB-Text -- приложение, созданное на базе объектной СУБД ODB-Jupiter и представляющее собой средство коллективной обработки документов и ведения корпоративного архива. ODB-Text позволяет:

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

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

* просматривать документы архива с помощью стандартного Интернет-браузера;

* обеспечивать связь с другими БД.

Для решения задач первого уровня автоматизации наиболее важно наличие узкоспециальных знаний о конкретике работы предприятия. В решении этого круга задач безусловный приоритет на стороне местных служб АСУ. Однако для корректного выполнения автоматизации «сверху» в большей степени ощущается потребность в системных знаниях. И вот здесь уже становится необходимым своего рода внешнее соуправление глобальными процессами автоматизации.

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

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

8.2 БАЗИСНЫЙ НАБОР ХАРАКТЕРИСТИК ДЛЯ ВЫБОРА АСУ

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

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

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

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

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

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

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

ЖЦ, так и постоянно возникающими отличиями действительно реализуемых ЖЦ от идеальных представлений.

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

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

Основные принципы и методы создания профилей стандартов установлены в стандартах серии ГОСТ Р ИСО/МЭК ТО 10000, определяющих основы и таксономию международных функциональных стандартов информационной технологии.

Процессы ЖЦ АС выделены по принципу ответственности субъекта (заказчика, поставщика, разработчика и т.д.), реализующего конкретный процесс. В свою очередь, каждый из процессов состоит из ряда работ и решаемых при выполнении соответствующей работы задач. С точки зрения соподчиненное™ и важности данных процессов они разбиты на три группы: основные, вспомогательные и организационные.

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

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

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

2. Процессы свободно соединены между собой. Количество интерфейсов между процессами сведено к минимуму.

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

* процесс должен быть своего рода модулем ЖЦ, т. е. каждый процесс выполняет только собственную функцию в ЖЦ, а интерфейсы между двумя любыми процессами минимальны;

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

* если процесс А вызван процессом В и только процессом В, тогда А принадлежит к В;

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

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

5. Каждый процесс должен иметь внутреннюю структуру, соответствующую его задачам.

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

Ответственность является особенностью структуры ЖЦ применительно к условиям проекта, в который может быть вовлечено множество субъектов.

8.3 ВЫБОР НЕОБХОДИМОГО ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

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

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

Многообразие моделей ЖЦ покажем кратким представлением трех самых известных, фундаментальных типов моделей ЖЦ: каскадной, инкрементной и эволюционной.

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

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

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

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

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

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

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

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

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

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

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

Применительно к ПС построение профилей стандартов активно применяется в международной и национальной стандартизации. В России впервые основы построения и использования профилей стандартов ЖЦ ПС заложены в базовом стандарте ГОСТ Р ИСО/МЭК 12207. Данный документ введен в действие с 1 июля 2000 г., тесно взаимоувязан с рядом стандартов, принятых ранее, и с некоторыми стандартами, разрабатываемыми в данное время на основе прямого применения стандартов ИСО.

Актуальность стандарта ГОСТ Р ИСО/МЭК 12207 для современных условий настолько высока, что принятие в ISO его исходного, международного варианта вскоре вызвало самую положительную оценку российских экспертов и ряд рекомендаций по его использованию в реальных условиях. Была высказана идея использования стандарта ИСО/МЭК 12207 на ЖЦ ПС в качестве системообразующего для создания моделей ЖЦ на системы в целом, тем более когда разработчик сталкивается с наличием различных типов нормативных документов, которые необходимо или полезно использовать для организации ЖЦ ПС.

Соответствие проекта стандарту ГОСТ Р ИСО/МЭК 12207 определяется как реализация в рамках конкретного проекта такой модели ЖЦ ПС, которая построена на основе выбора из данного стандарта соответствующих процессов, работ и задач. Выполнение процесса или работы считается завершенным, если решены все требуемые в них задачи в соответствии с предварительно установленными в договорной документации проекта (договоре или контракте) критериями и требованиями.

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

Основные процессы ЖЦ реализуются ответственным субъектом, вовлеченным в ЖЦ ПС. Ответственным субъектом является одно из юридических лиц (или подразделений, или должностных физических лиц), которые реализуют соответствующий процесс. Ответственными субъектами являются заказчик, поставщик, разработчик, эксплуатационный (оператор) и сопровождающий персонал. Основные процессы определяют следующее:

* процесс заказа -- работы заказчика (субъекта, приобретающего систему, ПС или получающего программную услугу);

* процесс поставки -- работы поставщика (субъекта, поставляющего систему, ПС или программную услугу заказчику);

* процесс разработки -- работы разработчика (субъекта, проектирующего и разрабатывающего ПС);

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

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

* вспомогательные процессы являются составной частью других процессов, обеспечивающей успешную реализацию и качество выполнения проекта. Конкретный вспомогательный процесс при необходимости инициируется и используется другим процессом. Вспомогательные процессы определяют следующее: процесс документирования -- работы по описанию информации, выдаваемой в конкретном процессе ЖЦ;

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

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

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

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

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

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

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

* организационные процессы ЖЦ -- применяются каким-либо субъектом для создания и реализации основной структуры модели ЖЦ ПС, охватывающей взаимосвязанные процессы и соответствующий персонал, а также для постоянного совершенствования данной структуры и входящих в нее процессов. Организационные процессы, как правило, являются типовыми независимо от области выполнения конкретных проектов и договоров. Организационные процессы определяют следующее:

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

процесс создания инфраструктуры -- основные работы по созданию базовой структуры какого-либо процесса ЖЦ;

процесс усовершенствования -- основные работы, выполняемые субъектом при создании, оценке, контроле и усовершенствовании выбранных процессов ЖЦ;

процесс обучения -- работы по соответствующему обучению персонала.

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

Для приобретения ПП крупных производителей ПО, таких как корпорация Microsoft, следует обращаться к ее партнерам, через которых она действует во всем мире. Каждый пользователь ПП должен иметь лицензию на него. Лицензия должна быть закуплена для каждого компьютера, на котором установлен или используется загружаемый через сеть ПП. Договор между пользователем и производителем не подписывается: считается, что покупатель принимает условия лицензионного соглашения, если он вскрывает дистрибутив-упаковку с дискетами или компакт-диском. Это так называемая оберточная лицензия, предусмотренная законом «О правовой охране программ для ЭВМ и баз данных» от 23 сентября 1992 г.

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

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

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

Часто хорошие новинки появляются у малоизвестных компаний, но через некоторое время лидеры обязательно применяют эти новинки в своих продуктах, так что ставка на лидера и в этих случаях оказывается правильной, поскольку небольшой инкубационный период позволяет определить качество и перспективность нового решения. Примером может служить новая технология IPswitching, которую компания Ipsilon применила для ускоренной передачи IP-пакетов через магистрали ATM. Через полгода компания Cisco разработала аналогичную технологию Tagswitching, внеся в исходную идею некоторые усовершенствования. Единственным недостатком ставки на лидеров является более высокая стоимость их продуктов по сравнению с компаниями второго эшелона.

8.4 ЭТАПЫ ВВОДА В ЭКСПЛУАТАЦИЮ АСУ

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

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

Общеотраслевыми руководящими методическими материалами по созданию АСУП (утверждены постановлением Государственного комитета Совета Министров СССР по науке и технике № 335 от 18 июля 1977 г.) установлены следующие стадии создания АСУП.

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

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

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

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

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

На основании ТЭО составляется техническое задание (ТЗ) на разработку АСУП. Если система разрабатывается очередями, ТЗ составляется и утверждается на нее в целом с выделением ее первой очереди. Допускается составление и утверждение ТЗ на первую очередь с указанием основных характеристик системы в целом.

ТЗ является результатом более детального изучения существующей системы управления предприятием и завершает предпроек-тную стадию создания АСУП. В этой работе принимает участие старший состав коллектива разработчиков, который впоследствии будет вести работы по созданию АСУП.

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

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

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

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

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

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

Организация разработки АСУП состоит в установлении взаимоотношений и создании условий работы всех разработчиков системы.

Накопленный к настоящему времени опыт создания АСУП позволяет сформулировать следующие основные задачи по разработке АСУП:

* формализация и стандартизация работ;

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

* тесное сотрудничество разработчиков с сотрудниками организации-заказчика на всех этапах разработки.

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

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

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

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

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

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

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

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

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

ГЛАВА 9. ПЕРСПЕКТИВЫ РАЗВИТИЯ АСУ НА АВТОМОБИЛЬНОМ ТРАНСПОРТЕ

9.1 КОНКУРЕНТНАЯ БОРЬБА НА РЫНКЕ ИНФОРМАЦИОННЫХ ТЕХНОЛОГИЙ

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

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

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

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

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

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

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

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

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

* направление основной деятельности;

* первоначальная структура продуктовых потоков;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ниже приведены общие рекомендации по внедрению ИС в организации (на предприятии).

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

2. Способствуйте тому, чтобы персонал ИС почувствовал себя причастным к общему делу фирмы.

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

3. Вносите ясность в функции специалистов ИС и пользователей.

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

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