Воройский Ф.С. Основы проектирования автоматизированных библиотечно-информационных систем

Подождите немного. Документ загружается.

141

ское обеспечение) и выходные формы документов, необходимые конкретной библио-

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

дач;

2. Каковы потенциальные возможности данного программного обеспечения по наращи-

ванию или изменению исходного состава решаемых задач, необходимых для их вы-

полнения операций и данных (в том числе видов обрабатываемых документов, соста-

ва и структуры полей их описания, словарей, выходных форм и т.п.) и чем обеспечи-

вается реализация этих возможностей.

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

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

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

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

лагаемым нам программным обеспечением. Если в процессе знакомства с программой-

претенденткой мы замечаем это несоответствие (при поверхностном ознакомлении с «объек-

том» этот изъян может обнаружиться слишком поздно!), мы вправе предложить разработчику

доработать или настроить ПО на наши условия.

Не исключено, что вас начнут убеждать в отсутствии необходимости такой доработки (на-

пример, по включению форматов новых видов обрабатываемых документов, изменению

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

и т.п.). Состав аргументов может быть очень широким и содержать как вполне объективные

доводы, так и откровенно неаргументированные, например: «Не видим в этом необходимо-

сти».

Если ваши обоснованные предложения будут легко приняты, быстро и недорого

реализованы, считайте, что по первому пункту программы данного раздела претен-

дентка прошла экзамен успешно.

И все-таки… вы создаете систему не на один год. И как бы детально вы ни проанализиро-

вали и ни спрогнозировали её развитие, жизнь всегда внесет свои коррективы. Нужно быть

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

ния могут быть как достаточно серьёзными (например, связанными с решением принципиаль-

но новых для вашей организации задач, изменением организационной структуры системы,

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

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

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

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

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

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

- 14.2.6. Более мелкие, но требующие оперативного выполнения изменения, в зависимости от

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

привлечение к доработке его разработчиков, других программистов (разной степени квалифи-

кации) или могут быть выполнены опытными пользователями — сотрудниками вашей органи-

зации, составляющими персонал системы. Очевидно, что предпочтение при прочих равных

условиях вы отдадите ПО, соответствующему последнему условию!

14.2.4. Эксплуатационные характеристики и стоимость

Эксплуатационные характеристики в первую очередь включают в себя надежность, быст-

родействие и стоимость эксплуатации.

Надежность ПО мы связываем с двумя основными качествами: устойчивостью его работы

и реализованными в нём средствами защиты самой программы и накопленных данных от раз-

рушения и несанкционированного доступа.

Устойчивость работы программных средств определяется количеством и характером сбо-

ев (в том числе «зависаний» и ошибок) системы в процессе работы. Причины этого явления

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

технике принято называть «поправкой на дурака». В данном понимании в качестве «дураков»

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

работе с системой. Характер сбоев определяет глубину их последствий: только относительно

небольшая потеря времени на выполнение последней операции или существенно значитель-

ные затраты времени, связанные с необходимостью перезагрузить систему, выполнить опе-

рации ее настройки (перенастройки), потерей части обработанных данных и т.п.

142

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

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

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

Защита программной среды и информации от разрушения и несанкционированного дос-

тупа осуществляется на программном уровне системой паролей, вводимых для персонала и

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

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

лизуется она не одинаково. Это означает, что при анализе каждого конкретного программного

продукта необходимо определить его соответствие по указанному признаку задачам созда-

ваемой вами системы и условиям ее эксплуатации.

В части «деловых качеств» ПО отдельно остановимся на его быстродействии. Это качест-

во проявляется при выполнении одних и тех же действий (операций) на одинаковых по вели-

чине массивах данных и при использовании однотипных технических средств. Сказанное ка-

сается операций сортировки, построения словарей системы, поиска данных, выполнения рас-

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

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

может колебаться от долей до единиц и даже десятков секунд. И если для редко выполняе-

мых операций медлительность работы ПО несущественна, то для операций, часто повторяю-

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

быстродействие ПО не сложно на реальных и желательно достаточно больших массивах дан-

ных (не менее 100 тыс. записей) в организации, в которой оно используется.

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

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

средств и соответственно — дополнительных затрат на их приобретение.

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

• приобретение собственно прикладной программы АБИС;

• обучение персонала;

• обновление (в случае модернизации) и/или замену прикладной программы (в случае

ее утраты, порчи и т.п.);

• приобретение необходимых для обеспечения работы системы других программных, а

также технических средств;

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

Касаясь первых трех показателей заметим, что разные собственники (разработчики) про-

граммного продукта устанавливают далеко неодинаковые условия его продажи, восстановле-

ния и обновления, а также начального обучения персонала организации-покупателя и автор-

ского сопровождения работы своего детища. Поскольку этот вопрос пересекается с после-

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

речисленных условий в последующем предохранит вас от многих разочарований!

Существующие версии программ АБИС также требуют и различных средств обеспечения,

имеющих весьма не равноценную стоимость. К примеру, стоимость программной среды

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

вышать стоимость приобретаемого вами программного продукта. Это же может относиться к

СУБД, на основе которой создан данный программный продукт. В части основных аппаратных

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

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

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

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

ных органах (особенно в малых и даже — средних), к сожалению, стало весьма распростра-

ненным. Даже оставляя моральную сторону данного явления, напомним, что «скупой платит

дважды». В частности, санкции за нарушение законов Российской Федерации «Об авторском

праве и смежных правах», «О правовой охране программ для электронных вычислительных

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

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

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

Во-первых

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

разными средствами и на разных носителях так называемыми пиратскими фирмами, лишает

143

их пользователей прав на обращение к фирме-разработчику за помощью при возможных про-

блемах с эксплуатацией соответствующего ПП, а также на приобретение по льготной стоимо-

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

удачно написанных программ.

Во-вторых,

приобретение даже лицензированных, но распространяемых бесплатно или по

сниженной стоимости версий ПП также лишает вас ряда преимуществ (не самая новая версия

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

права на льготное приобретение новых версий и т.п.).

Далеко небезразлично также, насколько экономна претендентка при использовании

внешней дисковой памяти. При этом справедливо рассматривать два аспекта: объем диско-

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

личества данных (скажем — книжных формуляров электронного каталога). Последствия оши-

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

на основные, но вспомогательные технические средства, которые служат для поддержки ар-

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

Ограничившись приведенными аргументами и отнюдь не претендуя на их полноту, отме-

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

приобретении ПО системы, которое ведет к материальным затратам, не связанным с необхо-

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

отсутствием более эффективных проектных и технических решений.

Итак, рекомендуем: приобретая ПО АБИС необходимо оценить целесообразность и

возможность конкретных (прямых и связанных с ними) затрат и их альтернативных ва-

риантов!

14.2.5. “Доброжелательность и привлекательность”

«Доброжелательность и привлекательность» ПО системы реализуется комплексом

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

• оказание помощи в технической реализации диалога на всех или большинстве чело-

веко-машинных операций (во всяком случае — наиболее трудоемких);

• обеспечение сокращения числа и объёма рутинных операций;

• комфортную и эстетичную форму воспроизведения данных на экране;

• эмоциональное воздействие на пользователей и персонал системы;

• документальную поддержку работы с ПО.

Основными средствами оказания помощи пользователям АБИС являются развитая сис-

тема «меню», а также текстовых и графических инструкций выполнения различных операций.

Последние могут совмещаться с «меню» в виде набора вариантов альтернативных команд,

составлять часть оформления экрана или вызываться при необходимости командой «Help»

(помощь) непосредственно в процессе выполнения тех или иных операций. Инструкции долж-

ны быть исчерпывающими, максимально понятными, но краткими.

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

цию персонала и пользователей и ускоряющими внедрение АС, являются встроенные обу-

чающие (в том числе демонстрационные) программные модули.

Сокращение числа и объёма выполняемых пользователями и специалистами системы ру-

тинных и даже требующих определенных интеллектуальных затрат промежуточных операций

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

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

ПО специальных программных модулей, ориентированных на решение наиболее важных или

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

Комфортные условия работы оператора обеспечиваются средствами реализации тре-

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

• удобное для восприятия расположение текстов, графических изображений и полей на

экране;

• использование шрифтов и цвета для выделения основных и вспомогательных элемен-

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

цветовой маркировки и размещения на экране функционально однородных элементов

формата);

144

• исключение как резких, так и малых контрастов (яркостных и цветовых) текстового и

графического материала с фоном.

Средствами эмоционального воздействия на пользователей и персонал системы яв-

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

дружеского человеческого общения, заставок изображений и т.п.

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

с системой, входящие в комплект документации, прилагаемой к ПО, поскольку с их изучения и

начинается взаимодействие персонала и пользователей с программно-техническими средст-

вами системы. Кроме того, к инструкциям приходится обращаться при изменении состава вы-

полняемых работ и операций, а также после длительных перерывов работы с системой. Ис-

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

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

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

тального обеспечения работы операторов АС, не имеющих развитой системы программного

обеспечения помощи.

С сожалением следует отметить, что большинство разработчиков АБИС пренебрегают

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

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

персонал и пользователи АБИС — вправе предъявлять соответствующие требования, по-

скольку значительную часть рабочего времени (следовательно — и жизни!) проводим или бу-

дем проводить в непосредственном общении с их творениями. И от того, насколько доброже-

лательна к нам и привлекательна выбираемая система, зависит, что она принесет: “смех, сле-

зы или любовь?”.

14.2.6. Оценка организации — поставщика ПО АБИС

Поставщиком ПО АБИС, как правило, является организация, которая его разработала.

Строго говоря, косвенно с «личностью разработчиков» мы в той или иной мере ознакомились,

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

необходимости оценивать их персоналии в роли «очень близких родственников» на достаточ-

но длительную перспективу. Теперь же вполне уместно хотя бы спросить: «Не оставят ли они

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

развитие системы?».

Следует сразу оговориться, что мы далеки от желания бросить тень недоверия на авто-

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

при внедрении системы в вашей организации, при появлении сбоев в работе программных

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

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

Отсутствие или недостаточность ресурсов у разработчиков ПП для реальной и система-

тической поддержки внедрения, эксплуатации и развития (тем более по индивидуальным тре-

бованиям заказчика!) своих разработок может создать достаточно серьезные проблемы для

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

обеспечения!

Последнее означает, что, выбирая ПО АБИС и заключая договор на ее внедрение

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

соглашения):

• условия внедрения системы (включая загрузку, настройку, обучение персонала и со-

провождение начального этапа эксплуатации программных средств);

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

и нарушениях целостности программной среды;

• планы и направления дальнейшего развития разработок системы;

• условия получения или приобретения последующих версий программного продукта, а

также связанных с ним или его работой услуг, документов или данных;

• наличие в вашем городе (регионе) библиотек или служб, являющихся владельцами

данного программного продукта, имеющих опыт его эксплуатации и могущих оказать

вам помощь.

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

будет. Тем не менее, мы уверены, что только осознанный выбор ПО АБИС, сделанный с уче-

145

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

просчетов и их последствий. Если же вы решили положиться на случай, может быть вам и

повезет. Искренне будем рады этому! Однако предварительно задумайтесь над вопросом,

заданным писателем П. Вацлавеком: “Как стать несчастным без посторонней помощи?” (см.

также [2]).

14.3. РАЗРАБОТКА ТЕХНИЧЕСКИХ ЗАДАНИЙ НА СОЗДАНИЕ ПРОГРАММНЫХ СРЕДСТВ

ОТСУТСТ-

ВУЮЩИХ В ТИПОВОМ КОМПЛЕКСЕ ПО АБИС

14.3.1. Общие рекомендации

Как уже отмечалось ранее, в связи с определёнными условиями как в процессе выбора

версии программного обеспечения АБИС, так и в дальнейшем (в процессе его эксплуатации)

может возникнуть необходимость в дополнении этого комплекса новыми программными мо-

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

Круг возможных ситуаций, требующих такой доработки основных средств ПО может быть

достаточно обширным и связанным как с основными или функциональными задачами систе-

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

Основным документом, содержащим сведения, необходимые для разработки дополни-

тельных средств ПО, является техническое задание. ТЗ разрабатывается постановщиком за-

дач. Обычно эту функцию берут на себя работники библиотек и информационных служб, ко-

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

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

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

содержания и степень детализации описания ТЗ.

В этих условиях разработчику часто приходится идти на «хитрости» (можно считать их од-

ним из элементов методики разработки средств ПО новых задач АБИС), заключающиеся в

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

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

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

от дорогостоящего программирования задачи в условиях возможного недопонимания со сто-

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

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

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

этом случае исходный вариант ТЗ будет разработан с учетом требований, предъявляемых к

системе и структуре данных всеми задачами.

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

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

новых задач. Это в свою очередь позволит комплексно подойти к проектированию всех новых

задач и создать единую базу данных для всего банка этих задач.

Оценку целесообразности реализации задач, технологичности их реализации желательно

осуществлять путем совместного рассмотрения этих задач пользователями, посредниками

(разработчиками библиотечных и информационных систем), программистами и непосредст-

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

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

ментными (т. е. решаемые систематически со строго установленной периодичностью и в соот-

ветствии с системной документацией).

14.3.2. Варианты формализованного представления ТЗ на разработку

средств ПО отдельных задач АБИС

Существуют разные подходы к составлению ТЗ на разработку средств ПО отдельных за-

дач или их групп в АБИС. Каждый из этих подходов обладает определёнными достоинствами

и недостатками. Выбор того или иного варианта структуры и содержания ТЗ определяется

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

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

водим некоторые возможные варианты составления ТЗ, на основании которых можно выбрать

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

задания.

1. В соответствии с одним из подходов, описанных в работе [11], рекомендуетcя

включать в структуру исходных требований на задачу следующие разделы:

146

• «Анкета задачи»;

• «Выходные документы»;

• «Альбом входных данных»;

• «Перечень входных документов - источников информации»;

• «Правила преобразования входных данных в выходные».

Раздел «Анкета задачи

» должен содержать общие сведения об описываемой задаче, а

именно:

• наименование задачи;

• назначение задачи;

• основание для автоматизации;

• взаимосвязь с другими задачами и т.д.

В раздел «Выходные документы

» должны быть включены макеты и порядок использова-

ния выходных форм.

В разделе «Альбом входных данных

» могут быть указаны объекты и исходные данные,

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

сивам).

Раздел «Перечень входных документов— источников информации

» должен содержать

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

Раздел «Правила преобразования входных данных в выходные

» должен содержать опи-

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

исходных данных.

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

щим пользователем, согласовано с подразделением автоматизации и утверждено руководи-

телем библиотеки или информационной службы.

2. Другой вариант ТЗ на разработку ПО, предназначенного для автоматизации от-

дельных задач, включает в себя разделы:

• «Введение»;

• «Общие сведения»;

• «Алгоритм решения»;

• «Сведения для системного программиста».

В разделе «Введение»

указываются сведения о том, что содержит, устанавливает или

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

данные о решаемых задачах общего характера.

В разделе «Общие сведения

» приводится краткое описание технических средств, инфор-

мационной базы, уточняются периодичность решения задачи и вид режима работы (напри-

мер, диалоговый или пакетный и т.п.).

В разделе «Алгоритм решения

» приводят блок-схему алгоритма решения задачи, правила

его построения, определяют правила перехода с одного блока на другой; приводят сведения о

входных и выходных данных.

В разделе «Сведения системному программисту»

должны быть приведены инструкции по

настройке программы, указаны структура программы, а также необходимые данные, позво-

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

ППП АБИС или на вычислительном центре организации, в которую входит библиотека или

информационная служба.

3. Вариант ТЗ, который можно считать упрощенным в том плане, что он не содержит

разработки алгоритма решения задачи и рекомендаций системному программисту по структу-

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

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

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

ствующих программных модулей. Конкретный пример ТЗ такого вида приведен ниже. Опреде-

лённую помощь в разработке ТЗ на ПО АБИС могут оказать также материалы, приведенные в

работах [12-14].

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

телем организации. Пример разработки ТЗ на АРМ «Комплектование» приведен в Приложе-

147

нии 5.

СПИСОК ЛИТЕРАТУРЫ

1. Громов Г.Р. Национальные информационные ресурсы: проблемы промышленной экс-

плуатации. М.: Наука, 1985. 235 с.

2. Воройский Ф.С. АБИС:проблемы выбора и внедрения // Библиотека. 1993. N 8. С. 61-65;

N 9. С. 30-33; 1994. N 2. С. 29-33; N3. С. 33-38.

3. Шрайберг Я.Л., Воройский Ф.С. Автоматизированные библиотечно-информационные

системы России: состояние, выбор, внедрение, развитие. М.: Liberея, ГПНТБ России,

1996. 273 с.

4. Шрайберг Я.Л., Воройский Ф.С. Новые модификации известных отечественных автома-

тизированных библиотечно-информационных систем (Разработки ГПНТБ России, БЕН

РАН, ГИВЦ МК РФ, ДИТ, НПО “Информ-система” // С компьютером на «Ты». М.: Liberея.

1998. Вып. 1. С. 36-49.

5. Воройский Ф.С., Грибов В.Т., Каленов Н.Е. Рынок программного обеспечения для авто-

матизированных библиотечно-информационных систем // Информационные ресурсы Рос-

сии, 1998. № 5. С. 18-22.

6. Воройский Ф.С., Грибов В.Т., Каленов Н.Е. Запад нам поможет? // Библиотека, 1998. №

5. С. 47-50.

7. Калёнов Н.Е. Проблемы автоматизации библиотечной технологии // НТИ, сер.1. 1995. N

9. С. 9-12.

8. Воройский Ф.С. Автоматизация в Москве // Библиотека. 1994. N10. С. 46-49.

9. Создание Корпоративной сети публичных библиотек Москвы: эскизный проект (с элемен-

тами технического проектирования) / Научн. рук. доктор техн. наук Я.Л. Шрайберг, отв.

исполн. канд. техн. наук, проф. Ф.С. Воройский. М.: ГПНТБ России, 1999. 84с.

(http://corporate.gpntb.ru/eskiz.php

10. Создание Корпоративной сети публичных библиотек Москвы: технический проект / Научн.

рук. доктор техн. наук Я.Л.Шрайберг, отв. исполн. канд. техн. наук, проф. Ф.С. Ворой-

ский.-М.: ГПНТБ России, 2000. 85с. (http://www.gpntb.ru/win/

korppro/2/ index.html).

11. Моздор С.В. Проектирование и внедрение локальных автоматизированнных информа-

ционных систем: Нормат. и метод. материалы. Сер. Орг. информ. деятельности.-М.: ВИ-

МИ, 1989. Вып. 1 (20). 75 с.

12. Воройский Ф.С., Моздор С.В. Проектирование информационной технологии и авто-

матизированных рабочих мест в составе служб предприятий: Нормат. и метод. материа-

лы. Сер. Орг. информ. деятельности. М.: ВИМИ, 1992. 75 с.

13. Воройский Ф.С., Кузнецов М.В., Моздор С.В., Хомутов А.В. Формирование и эксплуа-

тация интегрированных баз данных информационных систем. Сер. Информатика и ин-

форм. технология. М.: ВИМИ, 1987. Вып.7. 28 с.

14. Кузнецов М.В., Моздор С.В., Полтев А.А., Хомутов А.В. Проектирование программно-

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

Сер. Организация информационной деятельности. М.: ВИМИ, 1987. Вып. 4 (23). 77 с.

148

ЛАВА

XV. К

ВОПРОСУ О ПРОЕКТИРОВАНИИ КОММУНИКАЦИОННОГО ОБОРУДОВАНИЯ

АБИС

15.1. ОБЩАЯ ПОСТАНОВКА ПРОБЛЕМЫ

Библиотеки и информационные службы России, уверенно ступившие на путь внедрения

современных информационных технологий, всё в большей степени начинают осознавать про-

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

правном состоянии многочисленное и разнородное кабельное и другое оборудование. Не

приспособленные к сложившимся новым условиям и требованиям здания сегодня «обвеши-

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

коробками, розетками, «украшаются» просверленными отверстиями в стенах и перегородках,

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

устройств. Однако нарушением эстетики внутренних помещений дело не ограничивается. При

выходе из строя какой-либо линии связи, например локальной вычислительной сети (ЛВС),

найти место повреждения становится весьма сложной задачей. Трудности со временем уве-

личиваются, поскольку происходит постоянное наращивание количества терминалов (рабочих

станций, других видов периферийных устройств, телефонных аппаратов, телевизоров, уст-

ройств охранной сигнализации и т.д.) и/или изменение мест их расположения. Не способст-

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

ты, проводимые в здании.

Описанная ситуация не только достаточно известна — она может быть даже принята как

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

вые здания библиотек вводятся в строй или производится капитальный ремонт старых зда-

ний. Тем не менее в дальнейшем всё остаётся по-прежнему, поскольку сметы и технические

задания на строительство или ремонт зданий не предусматривают реализацию в них совре-

менной инфраструктуры кабельных и других соединительных систем и средств. Причиной ска-

занного чаще всего является тот факт, что заказчики проектов АБИС в лице директоров биб-

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

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

накомление заинтересованных руководителей организаций и работников финансирующих

органов с накопленным в данной области опытом.

Помимо некоторых вариантов (например, использование для создания ЛВС в здании ли-

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

отличающихся подхода к созданию современных коммуникационных средств ЛВС, которые

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

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

15.2. СТРУКТУРИРОВАННЫЕ КАБЕЛЬНЫЕ СИСТЕМЫ

Структурированная кабельная система (СКС ) [structured cabling system - SCS] пред-

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

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

смонтированная в соответствии с международными и национальными стандартами. Одно-

временно под СКС понимается формализованная открытая архитектура построения кабельно-

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

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

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

Основными структурными элементами («подсистемами») СКС являются:

• распределительный пункт здания - специальное помещение, в котором размещается

оборудование для соединения внутренних и внешних кабелей, обеспечивающих выход

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

ду;

• телекоммуникационная комната – в развитых корпоративных сетях служит для раз-

мещения сетевого оборудования;

• распределительный пункт этажа – отдельные помещения или специально спроекти-

рованные телекоммуникационные шкафы, объединяющие горизонтальные кабельные

разводки с вертикальной магистралью;

• вертикальная проводка – включает кабельные каналы, трубы, желоба, кабельные

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

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

149

этажей и телекоммуникационных шкафах;

• горизонтальная проводка – кабели, которые расходятся из телекоммуникационных

шкафов каждого этажа, а также служат для соединения портов сетевого оборудования

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

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

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

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

проводке.

Со структурированными кабельными системами связаны также следующие поня-

тия и термины [1, 11]:

• Cable - «кабель» - один электрический провод или оптическое волокно или несколько

таких проводов или волокон (кабельных элементов), покрытых изолирующей (защит-

ной) оболочкой;

• Cable element – «кабельный элемент» - любая конструктивная часть кабеля (провод,

витая пара, 4-парная сборка, оптоволокно и т. п.), возможно с индивидуальной изоля-

цией;

• Cabling system – «кабельная система» - совокупность

изических каналов для пере-

дачи электрических и/или оптических сигналов, включающая линейные и магистраль-

ные кабели и соединительные элементы;

• Cabling system certification – «сертификация СКС» - процедуры контроля качества

проектирования, оформления технической документация монтажа структурированных

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

нальным стандартам и предоставления на этой основе долгосрочных гарантий;

• Campus - «комплекс зданий» - совокупность нескольких зданий одной организации

на ограниченной территории;

• Campus backbone – «магистраль комплекса зданий» - физический канал

(кана-

лы) между распределительными пунктами зданий;

• Campus distributor – «распределительный пункт комплекса зданий» - место, где

сходятся магистральные каналы локальной сети;

• Collapsed backbone - «свернутая магистраль» - организация локальной сети, при ко-

торой кабельная система обеспечивает подключение терминального оборудования к

центральному сетевому устройству (коммутатору, концентратору) без промежуточных

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

ми;

• Comms (communication) room – «телекоммуникационная комната» - помещение,

где размещаются телекоммуникационное оборудование, кроссирующие, соединитель-

ные и распределительные панели. Как правило кондиционируется и защищается от

доступа посторонних;

• MAC – Moves, Adds and Changes – «перемещения, добавления и изменения» – со-

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

рующих СКС.

• Интеллектуальное здание, ИЗ [Intelligent building] – концепция «разумного построе-

ния» интегрируемых видов сервиса современных зданий различного назначения, обес-

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

вать на изменения среды, происходящих в зданиях процессов или требований обита-

телей и владельцев зданий. Физической основой ИЗ стали структурированные ка-

бельные системы, объединяющие многообразные и многочисленные исполнительные

устройства (например, пожаротушения, освещения, кондиционирования, охранной сиг-

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

ляющим программно-аппаратным комплексом здания. «Разумное построение» здания

предполагает, что все виды сервиса могут интегрироваться друг с другом с минималь-

ными затратами (финансовыми, временными и трудовыми), а их обслуживание органи-

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

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

высокой степенью защиты от ошибок обслуживающего персонала. Подробнее см. [9].

Здесь и далее технические термины см. в работе [11].

150

В развитых западных странах СКС и их элементная база стандартизированы и устанавли-

ваются (монтируются) или выпускаются многими фирмами.

Основные международные стандарты по кабельным системам:

• ISO/IEC Generic Cabling Standard 11801 - редакция 15.07.1995 (основной между-

народный стандарт),

• CENELEC Generic Cabling Standard EN 50173 (основной европейский стандарт),

• CENELEC EN 50167 for horizontal cables (европейский стандарт по горизонтальным эк-

ранированным кабелям),

• CENELEC EN 50168 for patch cables (европейский стандарт по соединительным экрани-

рованным кабелям),

• CENELEC EN 50169 for bacbone cables (европейский стандарт по магистральным экра-

нированным кабелям),

• ANSI/TIA/EIA Generic Cabling Standard 568-A (основной стандарт США).

Стандарт на телекоммуникационную систему офисных зданий ANSI/TIA/EIA 568A опреде-

ляет в деталях ее структуру, TIA/EIA 569 (Commercial Building Telecommunications Standart)

дополняет этот стандарт рекомендациями относительно прокладки кабельных трасс, стандарт

TIA/EIA 607 (Commercial Building Grounding and Bounding) определяет подсистему заземления,

TIA/EIA 606 – является стандартом на документацию и администрирование. СКС ведущих тор-

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

15, 16 и 20 лет (гарантируемый стандартами срок – 10 лет).

Производством компонентов систем СКС, удовлетворяющих требованиям международ-

ных стандартов, занимается ряд фирм. Наиболее известные из них: AMP, BICCbrandRex, ITT-

Cannon, Lucent Technologies, MOD-TAP, Siemon.

В России проектированием, сертификацией и монтажём «под ключ» занимается фирма

Prime Vision Electrbc – PVE (системный партнёр компании ITT-Cannon, тел./факс в Москве 361-

9560, E-mail: info@pve.ru

, Internet: /www.pve.ru );

Поставкой широкой номенклатуры оборудования и комплектующих для СКС занимается

фирма АйТи-СКС (в Москве тел.974-7979, факс-9747990, E-mail: info@it.ru

, Internet: www.it.ru).

Подробнее см. [1-11].

15.3. БЕСПРОВОДНЫЕ ЛОКАЛЬНЫЕ ВЫЧИСЛИТЕЛЬНЫЕ СЕТИ

Беспроводные ЛВС [Wireless LAN] используют в качестве среды передачи данных элек-

тромагнитное излучение радиочастотного (как правило - СВЧ) или оптического (инфракрасно-

го - ИК) диапазонов. Основу беспроводных ЛВС составляет WLL (Wireless Local Loop) –

«Беспроводная локальная линия». Последняя представляет собой технологию и/или сис-

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

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

(ТфОП).

Типовая архитектура WLL (см. рис. 15.1.) включает следующие основные компонен-

ты:

• контроллеры базовых станций – устройства, предназначеные для концентрации и

коммутации трафика WLL, обработки вызовов и обеспечения связи с коммутатором

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

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

• базовые станции – приемопередающие радиостанции, осуществляющие связь со ста-

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

вания;

• абонентские терминалы – портативные беспроводные телефонные трубки, специ-

альные настольные телефонные аппараты с трансивером (см.[11]) и антенной, а также

стационарные блоки на одну или несколько телефонных линий, к которым подключают

обычные телефоны, факсы или модемы (в широкополосных системах, предоставляю-

щих доступ к сетям ISDN, используются терминальные адаптеры ISDN);

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

осуществляющий мониторинг ее компонентов, контроль абонентских терминалов, а

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