Знание различных способов, как можно подать сигнал бедствия sos, может в дальнейшем спасти вашу жизнь. Или чью-то ещё, если вы сами умеете принимать и понимать значение таких сигналов.
Впервые сигнал SOS был использован 1 апреля 1905 года в Германии, и первоначально был просто общепринятым сигналом тревоги в рамках азбуки Морзе. Эта была последовательность из трёх точек, трёх тире и ещё трёх точек. Его используют по всему миру до сих пор, и многие тысячи людей обязаны ему своим спасением.
Так звучит сигнал SOS.
/wp-content/uploads/2019/08/Morse-Code-SOS-Sound-Effect.mp4
Для справки:
Ошибочно считается, что сигнал SOS — это аббревиатура, которая расшифровывается как «Save Our Souls» (или «Save Our Spirits», в переводе «спасите наши души»), «Save Our Ship», «Save Or Sink» (спасите, или утонем). Есть даже русскоязычное «Спасите От Смерти».
На самом же деле эти варианты появились много позже того момента, когда этот сигнал бедствия начал использоваться в международной практике. SOS был выбран из нескольких буквенно-числовых последовательностей как наиболее простая и узнаваемая. В азбуке Морзе сигнал SOS — отдельный символ, который обозначается с чертой поверх букв: SOS.
Далее мы приведём 10 способов, как можно сообщить потенциальным спасателям, что вы в беде и нуждаетесь в помощи.
1. Сигнал SOS с помощью зеркала
Вы можете передавать сигнал бедствия с помощью зеркала или любого другого материала, способного отражать солнечные лучи. Если светить в направлении самолёта, корабля или любого другого спасательного транспортного средства, то это поможет быстрее вас обнаружить. Комбинация из трёх коротких вспышек, трёх длинных и ещё трёх коротких даст спасателям знать, что у вас проблемы.
В далёком 1980 году некто Джоел Слайтер, хирург 48 лет, отправился в двухнедельный сплав по речке Колорадо, что в Аризоне. И всё было хорошо до тех пор, пока случайная волна не выбросила его из лодки. В придачу, верёвка захлестнула ногу Джоела, так что его ещё и хорошенько протащило по камням. Но его 24-летний сын успел прийти на помощь и вовремя перерезать злополучную верёвку. Так что американец отделался раздробленным коленом, сломанным тазом и переломом бедра со смещением. Выжил, но продолжать сплав уже точно не мог. К счастью, у ещё одного человека из лодки оказалось под рукой сигнальное зеркальце. А неподалёку как раз пролетал самолёт. 35 тысяч футов (10,5 километров) высоты не помешали пилоту разглядеть сигнал и вызвать спасательный вертолёт на помощь. Примерно так звучит типичная история человека, которого спас сигнал SOS, посланный с помощью сигнального зеркальца.
2. Сигнал SOS с помощью свистка
Интернациональный звуковой код для спасательных свистков ещё проще. Чтобы передать просьбу о помощи, нужно трижды коротко подуть в свисток. Ответные два свиста означают «Двигайтесь сюда», а ответный один свист – «Где вы?». Либо же один свист выступает в качестве проверки, если свистящему показалось, что он слышит какой-то звуковой код.
3. Сигнал бедствия с помощью костров
Ночью сигнал SOS особенно удобно подавать с помощью костров. Три костра, расположенные равносторонним треугольником со стороной примерно в 100 футов (30,5) метров – международный сигнал бедствия.
В дневное время тот же самый сигнал можно подавать с помощью дыма. Для этого стоит добавить в уже разгоревшийся костёр немного зеленых листьев и веток, чтобы дым стал гуще. Кроме того, стоит выбирать максимально высоко расположенное место для таких костров. И хотя ветра будут сносить дым в сторону, его всё равно можно будет проследить до источника.
4. Сигнал бедствия с помощью камней и песка
С помощью подобных материалов можно делать надписи. Только для этого лучше использовать достаточно большие камни. Либо же можно прорывать в песке небольшие траншеи, глубиной в 10 сантиметров, а шириной – 5 см, с помощью которых тоже можно оставлять надписи. С мокрым песком, впрочем, работать ещё проще. Так что после дождя или сильного прилива наступает самое время для размещения сигнала SOS. Также можно использовать тот же принцип, что и с кострами – три большие кучки камней или песка по углам равностороннего треугольника.
5. Сигнал SOS c помощью фонарика или мобильного телефона
Тут тот же самый принцип, что и с сигнальным зеркальцем. Только ещё и в ночное время можно использовать. Три короткие вспышки, три длинные и снова три короткие. Фонарик на мобильном телефоне тоже справится с этой задачей.
![10 способов подать сигнал бедствия SOS - Last Day Club 2]()
6. Сигнал бедствия с помощью факела
Если ни фонарика, ни телефона с собой нет, всегда можно сделать факел. Но лучше дождаться ночи. При этом стоит найти что-то, чем можно прикрывать огонь, а потом – дождаться пролетающих или проплывающих спасателей, чтобы передать уже знакомый вам аварийный сигнал SOS.
7. Сигнал бедствия с помощью красного и синего цвета
Красные и синие огни обычно означают, что кто-то попал в беду и нуждается в помощи. Такие сигналы используют, например, полиция и пожарные, чтобы предупреждать о своём появлении. Вы их тоже можете использовать, только несколько иным образом. Например, сделав флаг из красной и синей материи, а затем – начать размахивать им с какой-нибудь высокой точки или даже дерева.
8. Сигнал бедствия с помощью своего тела
Если в распоряжении вообще никаких инструментов нет, то можно использовать для подачи сигнала SOS и собственное тело. Вполне достаточно просто равномерно размахивать руками вверх и вниз. Нужно только убедиться, что вы находитесь на открытом пространстве.
Если вы знаете код Морзе, то можете использовать для передачи сигналов моргание. К такому способу нередко прибегали американские солдаты во Вьетнаме, чтобы предупреждать своих коллег о засадах.
9. Сигнал бедствия с помощью оранжевого дыма
Это довольно распространённый способ дать знать, что что-то не так с кораблями. Там всегда есть запасы специального горючего, которое даёт оранжевый дым в процессе сгорания. Такой дым прекрасно заметен даже с далёкого расстояния. Впрочем, такую же сигнальную дымовуху с оранжевым дымом можно и самостоятельно собрать. Главное – выяснить, какие вещества даёт оранжевый дым при поджигании.
10. Сигнал SOS c помощью стука
Если вы каким-то образом окажетесь в изолированном замкнутом пространстве, то вы сможете дать о себе знать с помощью стука по азбуке Морзе. Передать сигнал SOS в такой ситуации – не особо сложно. К такому методe часто прибегают шахтёры, попавшие в завал, жертвы похищения или люди, оказавшиеся в плену.
SOS — радиосигнал о помощи, терпящих бедствие на море. Состоит из сочетания трех точек, трёх тире и ещё трех точек азбуки Морзе. Мнение, будто SOS — английского словосочетания «Save Our Souls» («Спасите наши души») или «Save Our Ship» («Спасите наш корабль») — красивая легенда.
На самом деле расшифровки нет, просто соединение точек, тире, точек — наиболее простая и отчетливая комбинация.
Единый сигнал бедствия SOS был принят морским сообществом 3 октября 1906 года в Берлине на международной радиотелеграфной конференции. Дискуссия по этому вопросу была долгой и сложной.
До того каждая фирма, выпускающая радиооборудование, требовала от моряков использовать собственный, ею разработанный, сигнал. Например, американцы предлагали сигнал NG, компания «Маркони Уайрлесс телеграф», представлявшая интересы Великобритании, имела сигнал CQ, означающий «приходите быстро, опасность», немецкий концерн «Сляби-Арко» — сигнал SOE.
В первом и втором случае, однако, имелся существенный недостаток — сложность передачи, в немецком варианте на конце звучала лишь одна точка, что при слабой слышимости и радиопомехах могло привести к непониманию. SOS был выбран именно из-за его простоты. Утверждают, что конференция прислушалась к мнению физиков, музыкантов и психологов, выступавших на ней консультантами.
Впервые сигнал SOS прозвучал в эфире в том же, 1906 году с парохода «Ирбис», 10 июня 1909 года SOS отправил в эфир капитан пассажирского корабля «Кунард», терпящего бедствие у Азорских. «Кунард» был спасен.
Три минуты молчания
В 1927 году в Вашингтоне международная радиотелеграфная конференция установила единую международную частоту для передачи сигналов бедствия на море — 500 кгц, и запретила использование её для иных трансляций.
С момента ввода в действие сигнала SOS сорок восемь раз в сутки, то есть каждый час с 15-й по 18-ю минуту и с 45-й по 48-ю в радиоэфире наступали три минуты молчания. В это время радисты всех стран вслушивались в эфир, не раздастся ли от кого-нибудь призыв о помощи.
Так продолжалось до 1 февраля 1999 года, когда мир перешел на новую сигнальную систему, позволяющую осуществлять связь в автоматическом режиме, с применением буквопечатающих устройств и факсимильных аппаратов.
«Три минуты молчания»
Прекрасный роман Георгия Владимова. Был написан в 1969 году, тогда же опубликован в журнале «Новый мир», отдельным изданием с купюрами вышел в 1976 году и больше не издавался, так как вскоре Владимов оказался в числе
Считается, что известный позывной SOS, означающий, что корабль терпит бедствие, является аббревиатурой английской фразы Save Our Souls
, то есть Спасите наши души. На самом деле это не что иное, как миф. На самом деле сигнал SOS (если по азбуке Морзе, то это три точки — три тире — три точки) вообще не является аббревиатурой какой-то фразы.
Расшифровка SOS как Save Our Souls
является самой распространенной, но, тем не менее, не единственной.
Иногда данный сигнал считают аббревиатурой фраз Save Our Ship
(то есть спасите наш корабль), или Swim Or Sink
(то есть плыть или тонуть), или даже Stop Other Signals
(на мой взгляд, самая экстравагантная расшифровка: прекратите другие сигналы). Однако ничего подобного SOS, тем не менее, не означает.
Если мы вспомним азбуку Морзе, то SOS — это ни что иное, как сочетание трех точек (S), трех тире (O) и опять трех точек (S).
Это говорит о том, что данный сигнал, как и многие другие, появился еще в эпоху связи через беспроволочный телеграф — ведь именно тогда и началось использование морзянки.
Тот, кто знаком с этой системой коммуникаций, сразу скажет, что подобное сочетание можно набрать очень быстро. Возможно, именно поэтому слово SOS так полюбилось корабельным радистам.
Впрочем, сигналом бедствия это сочетание букв стало далеко не сразу. Вообще, первый такой сигнал появился в 1903 году.
Тогда, на Берлинской международной конференции радиотелеграфистов было подписано соглашение о том, что станции беспроводного телеграфа, если это возможно, должны давать приоритет сигналам о помощи, получаемым от кораблей в море.
И в качестве такового было предложено сочетание CQD — тире, точка, тире, точка, два тире, точка, два тире, две точки.
Следует заметить, что такое сочетание появилось неслучайно — оно представляло собой комбинацию сигнала общего вызова всех телеграфных станций CQ, к которому присоединили букву D, ибо с нее начинается английское слово danger
(то есть опасность).
В данном случае смысл сигнала был таким: Всем телеграфным станциям сообщаю об опасности. Однако, как это несложно заметить, быстро набрать такой сигнал весьма затруднительно даже для опытного радиста. Тем более, если он находится на судне, терпящим бедствие.
Кстати, международным сигналом CQD так и не стал — его применяли лишь суда, использующие радиоаппараты фирмы Marconi Co.
То есть корабли, оборудованные другими аппаратами, этот сигнал не транслировали. И, соответственно, не понимали, что он значит. Да и далеко не каждая береговая станция могла правильно его идентифицировать.
В итоге вопросы выработки международного сигнала бедствия стали предметом дискуссий на второй Международной радиотелеграфной конференции в Берлине в 1906 году. В ее работе приняли участие представители 29-ти стран, в том числе Англии, Германии, России, США, Франции и Японии. Сначала представители фирмы Marconi Co.
настаивали на утверждении в качестве такового уже используемого ими CQD, но делегаты из США резко возразили против этого — по их данным, такой сигнал часто путали с с общим вызовом CQ.
К тому же выяснилось, что эти оба сигнала применялись и береговыми телеграфистами при авариях и несчастных случаях на железных дорогах, что вносило еще большую неразбериху.
После делегаты из Германии предложили сочетание сигнал SOE (три точки, три тире, точка), однако и он многим не понравился — возникли опасения, что буква Е в конце может затеряться и не быть идентифицированной при дальнем приеме или перегруженном эфире. Отвергли также и предложение англичан сделать сигналом бедствие сочетание NC, означающее во флажковой международной сигнализации Терплю бедствие, нужна немедленная помощь
— его было бы сложно быстро набрать.
В итоге немецкие телеграфисты решили заменить в сочетании SOE одну букву. Так и родился знаменитый сигнал SOS, который понравился всем, поскольку данное сочетание было просто набрать, да и к тому же оно ясно идентифицировалось и при самой максимальной загрузке эфира. В результате этот сигнал был принят в качестве позывного судна, терпящего бедствие, что произошло 3 ноября 1906 года.
Есть слова, которые пришли из другого языка, да так и остались. Их немало, и постепенно они становятся архаизмами, сменяясь другими словами с тем же значением.
Но есть одно слово, которое стало международным. Его понимают все, кто связан с морем. Это сигнал SOS. Расшифровка переводится по-разному, но на русском языке самым распространенным стало «спасите наши души».
Роль изобретения радио в спасении людей
Как передать сигнал о помощи кораблю? Раньше это можно было сделать с помощью пушечных выстрелов, перевернутого государственного флага и спущенных парусов.
Согласитесь, в открытом море все это будет бесполезным, если поблизости не пройдет еще один корабль. Но с открытием радио наступает другой отсчет времени. Отныне стало возможным передавать информацию на гораздо большие расстояния, чем раньше.
Сначала не существовало никаких интернациональных кодов, предписывающих срочно идти на помощь находящемуся в беде судну.
Сигналы передавали по радио в кодификации Морзе, с помощью коротких и длинных сигналов. Первым принял подобный аларм ледокол «Ермак».
Расположенная в Финляндии радиостанция передала в эфир приказ о немедленном спасении пятидесяти рыбаков. Оторвалась льдина, и их уносило от берега.
Это случилось 6 февраля 1900 года. Первая спасательная операция завершилась успешно, всех рыбаков ледокол принял на борт. Сегодня используют гораздо более технологичные средства связи, но до сих пор морские суда оснащаются радиопередатчиками.
Сигналы, предшествовавшие SOS
Этот случай послужил причиной принятия единой системы передачи сигналов бедствия. Было решено использовать азбуку Морзе, но установить единый международный код.
Спустя три года после спасения людей у берегов Финляндии для этого стали использовать код CQ (первые буквы словосочетания come quick, что переводится как «приходите быстро»). В следующем году компания Маркони, выпускавшая радиопередатчики, предлагает добавить к коду букву D (по первой букве слова danger, что означает «опасность»).
Немецкий Telefunken, конкурент итальянцев, вводит свою комбинацию букв — SOE («Спасите наше судно»). Америка ввела свой код — NC (need salvation), то есть «нуждаюсь в спасении».
Каждый радиотелеграф передавал «свой» сигнал. Он мог быть понят только на таком же оборудовании. Это привело к тому, что лайнер «Фатерланд» отказался сообщить важные сведения американскому кораблю «Лебанон», спешившему на поиски судна. Это произошло по причине запрета на переговоры с теми, у кого нет оборудования Маркони.
Немного истории
В 1906 году, после нескольких обсуждений, посвященных этому вопросу, телеграфисты мира принимают сигнал SOS, заменив код SOE. Это случилось 6 октября в Берлине.
Чтобы было понятно, что это именно международный код, было решено принять еще один символ в азбуке Морзе. Он состоит из трех тире, заключенных с обеих сторон тремя точками. Перерывов нет — SOS.
Расшифровки слова как такового уже не существовало, поскольку эти буквы уже ничего не значили. Да и в разных языках были разные транскрипции. Краткость, узнаваемость, удобство отличия от обрывков речи — это послужило основанием для принятия сигнала SOS.
Однако из-за противоречивых инструкций от производителей радиоаппаратуры этот код был введен повсеместно только с 1908 года. И даже после этого все еще случались накладки. Например, гибнущий «Титаник» передавал CQD из-за того, что на нем был аппарат Маркони.
Первые сигналы
До 1912 года было несколько использований нового сигнала, но помощь приходила вовремя и надобность в единой сигнальной системе еще не была очевидна.
После трагедии Титаника это стало необходимым. Как и было предписано, после катастрофы с айсбергом радист направил сигнал CQD, позже — на свой риск — SOS. Но парадокс в том, что корабли поблизости приняли это за шалости пассажиров.
После гибели полутора тысяч человек этот сигнал больше не игнорировали.
SOS на английском
Хотя официальной расшифровки и нет, поскольку это не слова, сокращенные по первым буквам, все же в народе прижились некоторые варианты:
- Save Our Souls — фраза, сразу же придуманная моряками, стала и самой известной. Она означает «спасите наши души». Эти романтичные слова послужили источником вдохновения авторам стихов и песен. Во многом благодаря им так широко известен этот морской код.Вместо «души» часто используют слово «корабль» — Save Our Ship.Swim Or Sink — вопль о помощи, переводится как «плыть или тонуть».Stop Other Signals (немного странная на первый взгляд расшифровка SOS: «прекратите другие сигналы»). В такое время иные сигналы и правда неуместны.СОС («спасите от смерти») — логичная расшифровка на русском языке.
Все эти варианты образованы уже после выбора международного кода Морзе. Письменно он выглядит как три латинские буквы с чертой над ними.
Заповедная частота
Вместе с установленным сигналом выделяется и специальная частота его передачи. Пятнадцатую и сорок пятую минуту каждого часа выделяют для прослушивания эфира. Это время называют радиомолчанием. Прерываются все сообщения для того, чтобы услышать зов о помощи.
В 1927 году устанавливают запрет на ведение передач на частоте 500 кГц. Кроме сигнала SOS, частоту используют для других сообщений, угрожающих безопасности (мины, обмеление фарватера и т. п.).
Азбука Морзе — это код, с помощью которого обмениваются сообщениями корабли или самолёты. Изобрёл его Сэмюэл Морзе. Самым известным кодом в системе является «SOS», состоящий из трёх точек, трёх тире и ещё трёх точек.
Сэмюэл Морзе
Это универсальный сигнал бедствия, и использовался он на море настолько часто, что люди искренне считали, что это акроним — сокращение от фраз, например, «спасите наш корабль» (англ. save our ship) или «спасите наши души» (англ. save our souls). На деле всё немного иначе: «SOS» ни на чём не основан и не имеет вообще никакого смысла.
Сигналом бедствия «SOS» стал благодаря своей простоте — запомнить его удивительно легко. Кстати, это не первый код, который люди используют для этих же целей.
Сначала использовался сигнал «CQD» — в 1904-м году Гульельмо Маркони ввёл этот сигнал на основании фразы «come quick danger» (англ. «приходите скорее, опасность»).
В 1908-м году на смену «CQD» пришёл «SOS», но ему потребовались годы, чтобы стать общепринятым.
10 попыток объяснить существование жизни без дарвиновской Теории эволюции
После кругосветного путешествия Чарльз Дарвин окончательно уверовал в то, что в природе преобладает система, которую он назвал «естественный отбор», и которая, в свою очередь, вызывает процесс эволюции.
Проще говоря, организмы, которые живут достаточно долго для того, чтобы воспроизвести потомство, передают ему свою генетическую память. Если же организм по тем или иным причинам погиб, не оставив потомства, его характеристики не появятся в генофонде.
Со временем наращивание характеристик может привести к возникновению совершенно новых… Читать далее…
Непривлекательный Тутанхамон
Когда британский археолог Говард Картер в 1922-м году обнаружил гробницу фараона Тутанхамона, она рассказал о замечательных вещах, которые ему довелось увидеть.
После этого мальчик-фараон, с его золотой пещерой, позолоченной маской и безвременной кончиной, захватил воображение всего мира.
Сейчас, на канале ВВС, в документальном фильме «Тутанхамон: неприкрытая правда», учёные приоткрыли завесу тайны, окружающей жизнь фараона и его смерть. По мнению учёных, за каноничной маской фараона с очень заострёнными чертами, скрывалось вполне… Читать далее…
10 животных, чьи достижения намного превосходят ваши собственные
Одна из причин, по которой мы любим животных, заключается в том, что мы считаем их глупее себя, и нас греет это чувство превосходства.
Ну да, мы, возможно, провели последние несколько часов за просмотром «Покемонов» по кабельному каналу, но это всё равно более продуктивное занятие по сравнению с собакой, которая в течение четырёх часов пыталась укусить собственное отражение в зеркале.
Однако есть животные, которые отказались играть по этим правилам и добились того, о чём нам можно только мечтать, например…… Читать далее…
История сигнала SOS
«Мэй-Дэ»
За многие годы появилось великое множество сигналов, обозначавших только одно — кто-то терпит бедствие. Это и выстрелы из пушки, раздававшиеся через короткие промежутки времени, и определенная комбинация парусов, и оранжевый дым или красные ракеты.
Иногда о беде сигнализировали специальные флаги, которые видно за 4-5 миль. Просьба о помощи по Международному своду сигналов обозначается двумя флагами, поднятыми одновременно: клетчатым сине-белым и полосатым сине-бело-красным.
С появлением радиотелефонной связи родились аварийные позывные: «Мэй-Дэ». Иногда такой сигнал называют «Майский день», но это неверно. На самом деле, в переводе с французского он означает «помоги мне». В любом случае достаточно передать его на любой частоте — и все поймут, что вы попали в беду.
На сегодняшний день существует около 2000 способов, с помощью которых судно может известить спасателей о приключившейся беде. Ну и конечно в их число входит самый известный в мире призыв о помощи — сигнал SOS, родившийся на свет после изобретения азбуки Морзе.
В 1835 году, задолго до появления радио, американский художник Самюэль Финли Бриз Морзе создал простую, но эффективную систему связи — азбуку Морзе. Первоначально она состояла из трех символов: точка, короткое тире и длинное тире. Но в 1851 году все коды были переведены на два знака: точка и тире.
1865 года азбука Морзе стала широко использоваться во флоте. Вначале сообщения передавались флажками и фонарями. С изобретением радио точки и тире зазвучали в эфире, но какой-то единой, общемировой системы аварийных сигналов не существовало. Каждая фирма, выпускающая радиостанции, разрабатывала свой код связи для экстренных случаев.
Так например руководство Международной акционерной компании «Маркони», имевшей в те годы монополию на оборудование радиотелеграфными станциями морских судов Англии и Италии, постановило, что все суда, оснащенные радиостанциями «Маркони», должны пользоваться для передачи сообщений о бедствии сигналом CQD — первыми буквами в английских словах «приходите быстро, опасность». При этом руководители компании запрещали держать связь с судами, оборудованными радиостанциями других фирм, а так же пользоваться их кодами. Подобная практика рано или поздно привела бы к катастрофе.
Симметричный сигнал SOS
Представитель германской фирмы «Сляби-Арко» предложил сигнал SOE, используемый в позывных судов, оборудованных радиостанциями своей фирмы.
Однако при обсуждении был отмечен существенный недостаток этого сигнала: так как буква Е передается по азбуке Морзе одной точкой, то при слабом приеме и в условиях помех сигнал может быть искажен и не понят. И тогда поступило предложение заменить букву Е на букву S.
Получился симметричный сигнал SOS, который и был утвержден 3 октября 1906 года как единый международный сигнал бедствия.
Существовало множество «расшифровок» этого сигнала: «спасите наши души», «спасите наш корабль» или даже «остановите другие сигналы». В русском варианте бытовало такое толкование: СОС — «спасите от смерти». На самом деле эти три буквы никакой расшифровки не имеют. Просто три точки, три тире, три точки — наиболее быстрая и легко запоминающаяся комбинация сигналов азбуки Морзе.
Одновременно с введением единого сигнала бедствия, на море появилось еще одно правило: 48 раз в сутки, 2 раза каждый час (с 15-й по 18-ю минуту и с 45-й по 48-ю) наступало радиомолчание. В это время обрывались на полуслове любые сообщения, и радисты всего мира внимательно слушали эфир — не нуждается ли кто в помощи.
Впервые сигнал SOS прозвучал в 1906 году с борта парохода «Ирбис». Но буквально через несколько минут моряки поняли, что могут спастись своими силами и прекратили подачу сигнала.
В 1909 году возле Азорских островов потерпел крушение пассажирский лайнер «Кунард». На этот раз помощь была необходима, капитан воспользовался вновь принятым сигналом бедствия и получил подмогу.
Ну и наконец 1912 год — трагедия «Титаника». 15 апреля в 0 часов 15 минут Филлипс, первый радист суперлайнера, послал в эфир радиосигнал, сообщающий о катастрофе — CQD.
Несмотря на подписание берлинской конвенции, связисты британских судов еще несколько лет по привычке продолжали применять коды Маркони. Однако к двум часам ночи с «Титаника» шли уже все общепринятые сообщения о бедствии, включая SOS.
В 2 часа 17 минут радист британского судна «Вирджиния» услышал призыв о помощи, но сигналы гибнущего лайнера были настолько слабыми, что он их просто не понял.
Сигналы-призраки
«Титаник» ушел на дно Атлантики, но гибель его обросла мистическими исторями, которые всплывают и поныне. Так например 15 апреля 1972 года офицер-радист американского авианосца «Теодор Рузвельт» некто Ллойд Детмер принял сигнал SOS. На запрос о координатах и названии терпящего бедствие судна неизвестный радист сообщил, что ведет передачу с …тонущего Титаника.
Офицер немного растерялся, но сразу же сообщил в береговую охрану о полученном сигнале. С берега раздраженно ответили, что никто кроме «Теодора Рузвельта» никаких сигналов SOS не получал и язвительно посоветовали офицеру умерить свое воображение, либо обратиться к врачу. Ллойд был полностью уверен в своем психическом здоровье и потребовал расследования.
Изучение архивов, последовавшее в процессе дознания, выявило интересные факты. Оказывается подобные сигналы якобы с тонущего «Титаника» береговая охрана США принимала в 1924-ом, 1930-ом, 1936-ом и 1942-ом годах.
Полученные сообщения были абсолютно идентичны и приходили ночью 15 апреля, как раз в то время, когда суперлайнер шел на дно. Но ни в одном из случаев не удалось запеленговать источник сигнала. История на этом не заканчивается.
15 апреля 1996 года канадское судно «Квебек» вновь зафиксировало призывы о помощи, исходящие с затонувшего десятки лет назад океанского суперлайнера…
Подобные случаи не обошли и наших моряков. Так с 28 октября 2001 года из Охотского моря начали непрерывно поступать сигналы SOS.
Их приняли десятки судов, но первыми сигнал зафиксировали японцы и тут же проинформировали российскую пограничную службу. Тотчас же в район бедствия вышло из Владивостока спасательное судно «Ирбис».
Моряки тщательно обыскали акваторию, но ничего подозрительного не обнаружили, а сигналы тем временем продолжали поступать.
Дальнейшие исследования показали, что сигналы идут из точки, находящейся в 70 километрах от нефтедобывающей платформы «Моликпак», установленной на сахалинском шельфе, а источник сигнала скорее всего находится на дне — на глубине примерно 20 метров.
Однако поиски ни к чему не привели, а местные рыбаки сообщили спасателям, что год назад в Охотском море наблюдалось точно такое же явление.
Расследование этого загадочного события не дало никаких результатов, а 8 ноября сигналы внезапно прекратились…
С 1 февраля 1999 года азбука Морзе практически не используется в переговорах морских судов. На смену точкам и тире, пришла спутниковая система ГМССБ (Глобальная Морская Система Связи при Бедствии), которая немедленно определяет местоположение вызывающего судна с точностью до 200 метров и обеспечивает связь с другими кораблями.
Все суда водоизмещением свыше 300 тонн, а также пассажирские лайнеры и нефтяные платформы постепенно оснащаются этой системой. Теперь сигналы бедствия будут посылаться на спутник, и через него поступать в координационные центры в Германии, Англии, Австралии и Калифорнии. А сигнал SOS скоро окончательно станет достоянием прошлого.
Как расшифровывается SOS?
Наверняка каждому известна аббревиатура SOS. Этот сигнал бедствия используется в радиотелеграфной связи на международном уровне. «Спасите наши души» – распространенная расшифровка данного сигнала, однако так ли это?
История возникновения и расшифровка
До ХХ века на судах использовался CQD – код бедствия того времени. И лишь в 1906 в радиотелеграфной связи был предложен международный сигнал SOS. В Берлине 7 февраля этого года подписали особую статью.
В соответствии с ней суда, которые терпят крушение, должны использовать радиотелеграф для подачи сигнала «…—…». При этом, сигнал должен повторяться через короткие промежутки.
Азбука Морзе, русский и английский алфавит
До момента появления привычного сигнала почти в каждой стране были свои знаки оповещения. А до того, как было изобретено радио, моряки применяли аудиосигналы или же визуально привлекали внимание – использовали колокола, флаги, сигнальные огни и прочее. Затем производители радиостанций стали предлагать и использовать свои собственные сочетания кодов бедствия: SOE, CQD, NC.
На Международной радиотелеграфной конференции, проходящей в 1906 году в Германии, были собраны представители 29-ти стран. Они отдали голоса за сигнал бедствия SOS. Почему же нельзя было дальше использовать сигнал CQD?
Все просто – SOS короче и проще для слухового восприятия. Тем более, его нельзя было спутать с сигналом CQ, который имел самое разное предназначение (к примеру, приглашение к проведению сеанса связи).
Интересный факт: сигнал SOS просуществовал почти столетие и только в 1999 Международная морская организация заменила его на GMDSS, что является автоматической системой оповещения.
Вопреки распространенному мнению, SOS не расшифровывается, как «Спасите Наш Корабль» или «Спасите Наши Души». Сочетание букв – случайное, и выбрано оно для того, чтобы легко распознавать сигнал на слух. Также оно быстро запоминается.
Первые случаи использования SOS
Многие считают, что самый первый случай использования сигнала бедствия SOS – это «Титаник». На самом деле, это неправда и данный случай является приблизительно восьмым.
Интересно: Почему нельзя дарить часы? Причины, предрассудки и фото
Также есть и другое утверждение – сигнал SOS дал пароход «Славония», который потерпел крушение в 1909 неподалеку от Азорских островов. Однако к тому времени еще использовался код CQD.
Наиболее вероятное первое применение SOS случилось в том же 1909, когда 11 августа пароход «Арапаоэ» сбился с курса. Судно потеряло ход и начало дрейфовать в направлении Джексонвилла. Сигнал своевременно приняли и корабль спасли.
Интересный факт
Почему SOS?
Эту букву выбрали потому, что с неё начинается английское слово «danger» (опасность). К сочетанию CQD моряки быстро подобрали фразу «Come Quick, Danger». Но так как этот сигнал использовался только на судах, оборудованных радиоаппаратами «Marconi Co.», его нельзя было назвать единым международным сигналом бедствия.
Почему говорят мэй дэй?
«May day» Фраза представляет собой приблизительную английскую транскрипцию французского m’aidez — сокращённый вариант фразы venez m’aider («придите мне на помощь», «помогите мне»). … Mayday был придуман в 1923 году Фредериком Стэнли Мокфордом, старшим радистом аэропорта Кройдон в Лондоне.
Кто придумал сигнал SOS?
У SOS нет какого-то конкретного автора. Он был утвержден в ходе коллективного обсуждения 3 октября 1906 года на Второй международной радиотелеграфной конференции в Берлине. Делегаты 29 стран собрались с целью введения единого для всех стран сигнала бедствия.
Как звучит сигнал сос на азбуке Морзе?
Три точки, три тире, три точки (…—…), которые передаются без пауз между буквами. Именно так звучит сигнал SOS.
Как подать сигнал SOS?
Сигнал бедствия с помощью костров
Ночью сигнал SOS особенно удобно подавать с помощью костров. Три костра, расположенные равносторонним треугольником со стороной примерно в 100 футов (30,5) метров – международный сигнал бедствия. В дневное время тот же самый сигнал можно подавать с помощью дыма.
Сколько человек живет в Германии?
Когда May Day?
В первый понедельник мая англичане отмечают Майский праздник (May Day). Этот праздник традиционно сопровождается уличными шествиями и народными гуляньями. Музыканты, жонглеры на ходулях, менестрели и харчевни создают здесь подлинную атмосферу средневекового карнавала.
Как расшифровывается аббревиатура сос?
Мнемоническая конструкция SOS оказалась наиболее стойкой, как и некоторые сопутствующие ей словосочетания, такие как Save Our Souls (в перевод с англ. — «Спасите наши души»). У русских моряков для толкования сигнала использовался мнемоник «Спасите От Смерти».
Как подается сигнал сос с помощью фонарика?
Общепринятый и международный знак можно подать при помощи фонаря, мобильного телефона, доступного осветительного прибора. Основное действие — повторение сигнала 3 коротких, 3 длинных, 3 коротких, пауза, повтор. Источник света нужно прикрывать рукой, с разными временными промежутками.
Что такое с о с?
СОС — система обработки сообщений; СОС — система ограничительных сигналов; СОС — собственные оборотные средства; СОС — список отозванных сертификатов.
Почему Титаник подает сигнал сос?
С «Титаником» и сигналом SOS связана еще одна мистическая история. 15 апреля 1972 года американский линкор «Теодор Рузвельт» принял сигнал SOS с затонувшего 60 лет назад корабля. Радист, разумеется, удивился и запросил берег. Ответ был спокойным и странным: на сигнал SOS не реагировать, следовать прежним курсом.
Кто придумал азбуку Морза?
Азбука Морзе/Изобретатели
Какой код у цифры 5 в азбуке Морзе?
Напевы азбуки Морзе
Международный символ
| 5 | • • • • • |
| 6 | – • • • • |
| 7 | – – • • • |
| 8 | – – – • • |
Код Морзе
Как подать сигнал сос с телефона?
Вызов служб экстренной помощи
Нажмите и удерживайте боковую кнопку и одну из кнопок регулировки громкости до тех пор, пока не появится ползунок «Экстренный вызов — SOS». Перетащите ползунок «Экстренный вызов — SOS», чтобы вызвать службы экстренной помощи.
Какой самый опасный район в Москве?
Что означают три точки в азбуке Морзе?
СОС — международный сигнал бедствия в радиотелеграфной связи. Сигнал передается без каких-либо межбуквенных интервалов и представляет собой последовательность «три точки— три тире— три точки». Принято считать, что SOS является аббревиатурой от фразы Save our souls рус. Спасите наши души или Save our ship рус.
Когда придумали азбуку Морзе?
Азбука Морзе/Изобретатели
Как на самом деле расшифровывается SOS
Нам, обыкновенным жителям, приходилось сталкиваться с этим запоминающимся знаком разве что в фильмах и мультфильмах. Особенно часто этот символ использовали в случаях, когда герой оказывался на необитаемом острове и таким образом пытался подать знак бедствия.
Да, это сочетание букв действительно является сигналом о том, что кто-то попал в беду, причем применяется он повсеместно еще с начала прошлого века.
Однако, вопреки распространенному мнению, это никакая не аббревиатура, и значение у этого знака немного отличается от того, что показывают в кино.
Сигнал о проблеме
Многие убеждены, что SOS является аббревиатурой выражения Save Our Souls, что переводится с английского как «спасите наши души». Довольно драматичная идея, однако ложная, так как эти символы просто сами по себе являются знаком, в который не стремились добавлять расшифровку.
Международный сигнал бедствия стараются подавать любыми способами
Несмотря на частоту в использовании подобных знаков как раз в виде аббревиатур, данная комбинация букв представляет собой последовательность кода Морзе. Данная идея была официально представлена властями Германии еще в 1905 году. Этот код был добавлен в существующий тогда свод правил радиосвязи для того, чтобы каким-либо образом выделять оповещение о бедствии из потока сообщений.
Так, изначально этот знак стали использовать на кораблях, которые только начинали выходить в международные воды. Если на борту случалась критическая ситуация, то быстро связаться с другими судами можно было лишь посредством азбуки Морзе. Так, работникам кораблей необходим был какой-то особый сигнал, который отличался бы от всех остальных и сразу давал понять о бедственном положении.
Так выглядит сигнал на азбуке Морзе
Универсальный знак
До того как этот знак стал международным символом, разные государства использовали разные коды. Так, британские суда пользовались комбинацией CQD, где первые две буквы обозначали вызов абсолютно всех станций, а последняя обозначала опасность, что на английском пишется как danger. Правда, этот сигнал так и не прижился, ведь довольно часто его путали с обычным общим вызовом.
Сигнал отличается своей однозначностью
Однако SOS, представленный немецким правительством, вскоре стал международным обозначением, так как отличался своей универсальностью.
Мало того, что он не образовывал собой какого-либо известного слова и не нес в себе двузначности, так он еще и оказался узнаваем благодаря симметричному изображению.
Он не только одинаковым образом читается как в слева направо, так и в обратную сторону, но еще и четко читается даже в перевернутом виде. Так, независимо от того, с какой стороны будет идти подмога, они смогут понять, что за символ изображен.
Также предлагаем почитать о сигнале, который используют пилоты в случае экстренной ситуации.
А вы когда-либо пользовались этим сигналом?
Кто придумал сигнал SOS?
И, как ни странно, известный многим по экшен-фильмам сигнал бедствия SOS оказался не единственным и даже не первым вариантом. Почему закрепился именно он – читайте в колонке нашего обозревателя Николая Гринько. Изобретателями радио считаются не меньше десятка человек.
Как расшифровывается аббревиатура сос?
Мнемоническая конструкция SOS оказалась наиболее стойкой, как и некоторые сопутствующие ей словосочетания, такие как Save Our Souls (в перевод с англ. — «Спасите наши души»). У русских моряков для толкования сигнала использовался мнемоник «Спасите От Смерти».
Как звучит сигнал сос на азбуке Морзе?
Три точки, три тире, три точки (…—…), которые передаются без пауз между буквами. Именно так звучит сигнал SOS. Данная английская аббревиатура обозначает фразу Save Our Souls/Ship и переводится как «спасите наши души/корабль».
Как подается сигнал сос с помощью фонарика?
Общепринятый и международный знак можно подать при помощи фонаря, мобильного телефона, доступного осветительного прибора. Основное действие — повторение сигнала 3 коротких, 3 длинных, 3 коротких, пауза, повтор. Источник света нужно прикрывать рукой, с разными временными промежутками.
Как подать сигнал SOS?
Сигнал бедствия с помощью костров
Почему не состоялись бои Хабиба и Фергюсона?
Ночью сигнал SOS особенно удобно подавать с помощью костров. Три костра, расположенные равносторонним треугольником со стороной примерно в 100 футов (30,5) метров – международный сигнал бедствия. В дневное время тот же самый сигнал можно подавать с помощью дыма.
Почему Титаник подает сигнал сос?
С «Титаником» и сигналом SOS связана еще одна мистическая история. 15 апреля 1972 года американский линкор «Теодор Рузвельт» принял сигнал SOS с затонувшего 60 лет назад корабля. Радист, разумеется, удивился и запросил берег. Ответ был спокойным и странным: на сигнал SOS не реагировать, следовать прежним курсом.
Что такое с о с?
СОС — система обработки сообщений; СОС — система ограничительных сигналов; СОС — собственные оборотные средства; СОС — список отозванных сертификатов.
Кто придумал азбуку Морза?
Азбука Морзе/Изобретатели
Какой код у цифры 5 в азбуке Морзе?
Таблица кодов азбуки Морзе
Цифра
| 5 | • • • • • |
| 6 | – • • • • |
| 7 | – – • • • |
| 8 | – – – • • |
Код
Как расшифровывается азбука Морзе?
Азбука Морзе — код Морзе, «Морзянка» — способ кодирования букв алфавита, цифр, знаков препинания и других символов при помощи длинных и коротких сигналов, так называемых «тире» и «точек» (а также пауз, разделяющих буквы). … символ «точка» в русском варианте: · · · · · · , а в латинском: · – · – · –
Как выкладывать знаки о помощи?
Важно правильно их расположить: сигнал должен быть виден и с земли, и с воздуха. Символы не должны быть меньше 300 см в ширину и 1000 см в длину. Пробельное пространство между знаками — не менее 300 см. Символы выкладывают любыми подручными предметами, которые хорошо видно на земле.
Сколько лет Варнаве из Камеди вумен?
Как показать сос?
Три коротких световых сигнала, три длинных и снова три коротких.
Как подать сигнал о помощи?
Чтобы подать сигнал бедствия, пользуйтесь следующими звуковыми и световыми способами:
- Красная ракета
- Звуковой сигнал — три точки, три тире, три точки. Повторять с интервалами в одну минуту.
- Световой сигнал — как и звуковой (три короткие вспышки, три длинные, три короткие). повторять с интервалом в одну минуту.
Как подать сигнал сос с телефона?
Вызов служб экстренной помощи
Нажмите и удерживайте боковую кнопку и одну из кнопок регулировки громкости до тех пор, пока не появится ползунок «Экстренный вызов — SOS». Перетащите ползунок «Экстренный вызов — SOS», чтобы вызвать службы экстренной помощи.
Что означают три точки в азбуке Морзе?
СОС — международный сигнал бедствия в радиотелеграфной связи. Сигнал передается без каких-либо межбуквенных интервалов и представляет собой последовательность «три точки— три тире— три точки». Принято считать, что SOS является аббревиатурой от фразы Save our souls рус. Спасите наши души или Save our ship рус.
Когда придумали азбуку Морзе?
Азбука Морзе/Изобретатели
Р 50.1.041-2002
РЕКОМЕНДАЦИИ
ПО СТАНДАРТИЗАЦИИ
Информационные
технологии
РУКОВОДСТВО ПО ПРОЕКТИРОВАНИЮ
ПРОФИЛЕЙ СРЕДЫ ОТКРЫТОЙ
СИСТЕМЫ (СОС)
ОРГАНИЗАЦИИ-ПОЛЬЗОВАТЕЛЯ
ГОССТАНДАРТ
РОССИИ
Москва
Предисловие
1 РАЗРАБОТАНЫ Институтом радиотехники и электроники
Российской Академии Наук (ИРЭ РАН), Московским государственным институтом
радиотехники, электроники и автоматики (Технический университет) и
Всероссийским научно-исследовательским институтом стандартизации (ВНИИстандарт)
Госстандарта России
ВНЕСЕНЫ Техническим комитетом по
стандартизации ТК 22 «Информационные технологии»
2 ПРИНЯТЫ И ВВЕДЕНЫ В ДЕЙСТВИЕ Постановлением
Госстандарта России от 14 ноября 2002 г. № 415-ст
3 ВВЕДЕНЫ ВПЕРВЫЕ
СОДЕРЖАНИЕ
1 Область применения. 3
2 Нормативные
ссылки. 3
3 Определения,
сокращения и обозначения. 3
3.1 Определения. 3
3.2 Сокращения. 7
3.3 Обозначения. 9
4 Общие положения. 10
4.1 Среда открытых
систем (СОС) 10
4.2 Профиль среды
открытых систем.. 10
4.3 Метод,
основанный на понятии жизненного цикла. 14
4.4 Повторное
использование профиля. 15
4.5 Использование
метода построения профилей СОС.. 15
4.6 Преимущества
от использования профилей СОС.. 15
5 Профиль СОС в
организации-пользователе. 16
5.1 Эталонная
модель СОС POSIX.. 16
5.2 Типы профилей. 17
5.3 Профили СОС
организации-пользователя. 18
6 Процесс
разработки профиля СОС организации-пользователя. 23
6.1 Общие
положения. 23
6.2 Модель
процесса создания профиля СОС организации-пользователя. 24
6.3 Определение
области действия профиля (этап определения области применения) 25
6.4 Анализ
требований к документу «Структура требований пользователя». 25
6.5 Определение
служб ИТ (этап логического проектирования) 29
6.6 Определение
стандартов, технических профилей и внутренних технологий (этап физического
проектирования) 35
6.7 Выбор
продуктов (этап эксплуатационного проектирования) 36
7 Рекомендуемая
структура профиля СОС организации-пользователя. 37
7.1 Рекомендуемая
структура. 37
8 Вопросы,
связанные с профилем СОС организации-пользователя. 38
8.1 Аттестационное
тестирование. 38
8.2 Вопросы
реализации. 39
8.3 Планирование
внедрения. 39
8.4 Использование
общедоступных технических требований. 40
9 Преимущества
профилей СОС организации-пользователя. 40
Приложение А. Библиография. 41
Введение
Современная информационная инфраструктура, включающая
информационные, вычислительные и телекоммуникационные ресурсы, представляет
собой гетерогенную программно-аппаратную среду, использующую компьютеры
различных классов и производителей. При этом возникает проблема совместимости в
этой среде, т. е. реализация трех основных качеств, включая: обеспечение
переносимости приложений между различными платформами, взаимодействия систем и
их масштабируемости. Среда, обладающая сочетанием этих трех качеств, называется
средой открытой системы (СОС).
Открытость среды достигается использованием
согласованного набора стандартов (профиля) на все программно-аппаратные
компоненты. Обеспечение открытости — достаточно сложная научно-методическая
задача с учетом того, что число стандартов в области информационных технологий
достаточно велико, и количество этих стандартов постоянно возрастает в
результате появления новых технологий.
Одной из важнейших задач в решении проблемы
обеспечения открытости информационных систем является создание методики
построения профилей как неотъемлемой части информационной инфраструктуры любого
уровня.
Настоящие рекомендации по стандартизации разработаны с
учетом требований стандарта IEEE Std 1003.23-98 «Стандарт института инженеров по
электротехнике и электронике. Руководство по проектированию профилей среды
открытой системы организации-пользователя» [1] и предназначены оказывать
содействие пользователям, проектировщикам, заказчикам и специалистам по
применению и эксплуатации сложных информационных систем при создании профилей
СОС организации-пользователя, которые устанавливают требования организаций к
обработке информации и телекоммуникациям. В зависимости от целого ряда
факторов, включая функции, процессы и задачи, выполняемые организацией, может
быть принят различный подход к проектированию профилей СОС. Настоящие
рекомендации не содержат всех необходимых сведений для создания профиля СОС,
они устанавливают методологию выбора стандартов и процедуры проектирования
профилей СОС организации-пользователя и при практическом применении должны быть
дополнены другими технологиями, имеющими отношение к созданию профилей СОС с
учетом специфики конкретной организации.
Р 50.1.041-2002
РЕКОМЕНДАЦИИ
ПО СТАНДАРТИЗАЦИИ
Информационные технологии
РУКОВОДСТВО ПО ПРОЕКТИРОВАНИЮ ПРОФИЛЕЙ СРЕДЫ
ОТКРЫТОЙ СИСТЕМЫ (СОС) ОРГАНИЗАЦИИ-ПОЛЬЗОВАТЕЛЯ
Information technologies.
Guide for developing the User Organization Open System Environment (OSE)
profiles
Дата введения 2004-01-01
1 Область применения
Настоящие рекомендации предназначены для описания
процесса проектирования профилей среды открытых систем (СОС)
организации-пользователя (профилей СОС). Настоящие рекомендации содержит
описание основных принципов оформления требований пользователя и сведения об
информационных технологиях (ИТ) и службах (услугах), которые могут обеспечить
выполнение требований пользователей, а также информацию о порядке выбора
стандартов, спецификаций и рекомендаций, которые должны обеспечивать поддержку
ИТ и их служб. В настоящих рекомендациях также рассматривается необходимость
подготовки плана формирования больших систем, включая описание таких
мероприятий, как, например, аттестационное тестирование, сопровождающих
применение профилей.
Процесс проектирования профиля СОС, применимый при
реализации любого подхода к процедуре проектирования, в том числе основанного
на применении лицензионных (запатентованных) продуктов и решений, описан в
разделе 5.
Настоящие рекомендации содержат сведения о переходе от
физического (основанного на стандартах) уровня проектирования к
эксплуатационному уровню (основанному на продуктах, имеющихся на рынке), но не
содержат требований по выбору конкретных продуктов и решений.
Настоящие рекомендации могут применяться
пользователями с учетом принятой в конкретной организации политики основной
(деловой) и технической (технологической) деятельности.
В настоящих рекомендациях установлен ряд требований и
запросов пользователя, подлежащих учету при разработке профилей СОС, за
исключением положений о результатах практического применения профиля СОС.
Настоящие рекомендации не устанавливают обязательные
требования, которым должны соответствовать разработанные профили СОС.
В настоящих рекомендациях не определен обязательный
порядок использования какого-либо конкретного профиля, архитектуры или способа
их применения.
Настоящие рекомендации не являются руководством по
проведению аттестационного тестирования профилей СОС и не устанавливают методы
тестирования профилей СОС организации-пользователя.
2 Нормативные ссылки
В настоящих рекомендациях использованы ссылки на
следующие стандарты:
ИСО/МЭК МФС 11183-1-92*) Информационная
технология. Международные функциональные стандарты AOMln управления ВОС. Управление коммуникациями. Часть 1.
Спецификация элемента услуги управления связью, протоколов уровней
представления и сеанса, используемых элементами услуги удаленного доступа и
управления связью
ИСО/МЭК 14252-95*) Информационная
технология. Руководство по среде открытых систем для POSIX
*) Оригинал — во ВНИИКИ Госстандарта
России.
3 Определения, сокращения и обозначения
3.1 Определения
В настоящих рекомендациях использованы следующие
термины с соответствующими определениями:
3.1.1 аккредитованная организация — разработчик
стандартов (accredited standards development organization): Организация, признанная в качестве
организации — разработчика стандартов международным органом по стандартизации
(например ИСО, МЭК или МСЭ-Т) или одним из полномочных членов этих организаций
(например национальным органом по стандартизации, таким как Госстандарт
России).
3.1.2 профиль прикладной среды (application environment profile): Комбинация многих стандартов, а также стандартных
профилей, которая определяет различные типы функциональных возможностей,
необходимых для конкретной среды.
3.1.3 прикладная платформа (application platform): Набор ресурсов, включая технические и программные
средства, обеспечивающий услуги для работы прикладного программного средства.
Прикладная платформа предоставляет услуги на своих
интерфейсах, обеспечивая максимально возможную «прозрачность» конкретных
характеристик платформы для прикладного программного средства.
3.1.4 прикладное программное средство (application software): Программное средство, предназначенное для
приложения и состоящее из программ, данных и документации.
3.1.5 прикладной программный интерфейс (ППИ) (application program interface (API)): Интерфейс между прикладным программным средством и
прикладной платформой, через который обеспечивается доступ ко всем необходимым
службам (услугам).
3.1.6 базовый стандарт (base standard): Принятый
международный стандарт, технический отчет, рекомендация МСЭ-Т или национальный
стандарт.
3.1.7 направления деятельности (НД) (домен) (business area (BA) (domain)): Логическое
выделение из всей деятельности предприятия сходных направлений, например
финансовой деятельности, деятельности по продажам и маркетингу.
3.1.8 целевая функция (business function): Набор
процессов, обеспечивающих достижение конкретной цели деятельности.
3.1.9 требование к бизнес-системе (ТБС) (business system requirement (BSR)): Устанавливаемое предприятием требование к системе,
то есть набор процессов, процедур и документации, обеспеченный соответствующей
технологией, регламентирующее коэффициент критичности успеха (ККУ) или ключевой
показатель эффективности (КПЭ) при достижении цели или вида деятельности
предприятия.
3.1.10 интерфейс коммуникационной службы
(ИКУ) (communications services interface (CSI)): Граница, через которую обеспечивается доступ к
службам при взаимодействии между внутренними объектами прикладного программного
средства и внешними объектами прикладной платформы.
3.1.11 профиль компонента (component profile): Профиль,
образуемый путем формального определения подмножества единственного стандарта.
3.1.12 коэффициент критичности успеха
(ККУ) (critical success factor (CSF)): Мера эффективности деловой системы, которая в
совокупности с другими ККУ образует КПЭ.
3.1.13 фактический стандарт (de facto standard): Стандарт, разработанный неофициально, когда один
или несколько субъектов создают продукцию или технологию, которые имеют спрос и
копируются, становясь так широко используемыми, что отклонение от их исходных
образцов вызывает проблемы с совместимостью или ограничивает
конкурентоспособность.
3.1.14 создаваемый стандарт (emerging standard): Технические
требования (спецификация), представленные на рассмотрение аккредитованной
организацией, разрабатывающей стандарты, но еще не прошедшие процесс принятия
компетентным органом.
3.1.15 внешняя среда (external environment): Набор
объектов, внешних по отношению к прикладной платформе, с которой обеспечивают
взаимодействие различные службы организации.
К внешним объектам относятся персонал, сменные
носители, не установленные в платформе, линии связи и другие платформы.
3.1.16 интерфейс с внешней средой (ИВС) (external environment interface (EEI)): Интерфейс
между прикладной платформой и внешней средой, обеспечивающий необходимые
службы. ИВС предназначен прежде всего для обеспечения функциональной
совместимости систем и приложений. Основными службами, предоставляемыми через
ИВС, являются:
— интерфейс
человек-компьютер (ИЧК);
— информация;
—
коммуникации.
3.1.17 функциональное качество (ФК) (functional quality (FQ)): Мера уровня
службы (услуги) и эффективности (производительности), предполагаемая при
обеспечении выполнения ТБС с помощью предложенного технологического решения.
Данные ФК допускается использовать в качестве критериев оценки эффективности и
для аттестационного тестирования, а также для выбора стандартов при реализации
проекта на физическом уровне и изделий при переводе проекта на физическом
уровне в реализуемое (эксплуатационное) решение.
3.1.18 технические средства (hardware): Физическое оборудование, используемое при обработке
данных, в противоположность программам, процедурам, правилам и соответствующей
документации.
3.1.19 гармонизация (harmonization): Процесс, обеспечивающий исключение
дублирования и непротиворечивость стандартов (включая профили).
3.1.20 интерфейс человек-компьютер (ИЧК)
(human/computer interface (HCI)): Граница, через которую реализуется физическое
взаимодействие человека с прикладной платформой.
3.1.21 служба информационных систем (ИС)
(information systems (IS) service): Высокоуровневое описание служб, применяемых для
реализации ТБС. Службы ИС дают перекрестные ссылки на ТБС, которые они
обеспечивают, службы ИТ, которые их обеспечивают, и технологические компоненты,
вмещающие данные службы.
3.1.22 службы информационной технологии
(ИТ) (information technology (IT) service): Самый
неделимый уровень технологии. Группа служб ИТ взаимодействует для обеспечения
служб ИС, поддерживающих ТБС. Службы ИТ описываются в терминах протоколов, ППИ
и компонентов служб.
3.1.23 модель служб информационной
технологии (ИТ) (information technology (IT) service model): Текстовое и графическое представление служб ИТ,
определяющее все низкоуровневые компоненты и интерфейсы служб.
3.1.24 информационный (informative): По ИСО/МЭК 14252.
3.1.25 интерфейс (interface): Общая граница между двумя функциональными
объектами, требования к которой определяются стандартом.
Стандарт на интерфейс определяет службы в терминах
функциональных характеристик и поведения, наблюдаемого на интерфейсе. Стандарт
на интерфейс является договором, документально определяющим взаимные
обязательства между пользователем и поставщиком служб, а также гарантирует
стабильную документально оформленную четкость выполнения конкретного
обязательства.
3.1.26 функциональная совместимость (interoperability): Способность двух или более систем
обмениваться информацией и использовать эту информацию.
3.1.27 ключевой показатель эффективности
(КПЭ) (key performance indicator (KPI)): Показатель
эффективности конкретной бизнес-системы, выраженный в терминах целей и задач
предприятия.
3.1.28 местный(е) (locale(s)): Определение
среды пользователя в зависимости от языка и культурных обычаев.
3.1.29 нормативный (normative): Обязательный набор инструкций или ссылок.
3.1.30 открытые технические требования
(спецификации) (open specifications): Технические требования
(спецификации), утверждаемые организацией, использующей процесс открытого
публичного согласования для внедрения новых технологий и требований
пользователя.
3.1.31 открытая система (open system): Система,
реализующая достаточно открытые спецификации или стандарты для интерфейсов,
служб и форматов, облегчающая прикладному программному средству:
— перенос его
с минимальными изменениями в широком диапазоне систем, использующих продукты
разных производителей (поставщиков);
—
взаимодействие с другими приложениями, расположенными на локальных или
удаленных системах;
—
взаимодействие с людьми в стиле, облегчающем переносимость пользователя.
3.1.32 среда открытой системы (СОС) (open system environment (OSE)): Исчерпывающий набор интерфейсов, служб и форматов
совместно с пользовательскими аспектами, необходимый для обеспечения
функциональной совместимости или переносимости приложений, данных или персонала
в соответствии со стандартами и профилями ИТ.
3.1.33 профиль среды открытой системы (СОС)
(open system environment (OSE) profile): Выбранный набор
стандартов и их вариантов (опций), определяющий поведение интерфейсов для
конкретного класса или области приложений в терминах функциональных вызовов,
протоколов, форматов данных и т.д.
3.1.34 предложенное решение (point solution): Предложенная
архитектура систем, достаточно конкретизированная для определения возможности
удовлетворения требований и стоимости их реализации.
3.1.35 переносимость (прикладного
программного средства) (portability (application software)): Степень легкости, с которой прикладные программные
средства и данные могут быть перенесены с одной прикладной платформы на другую.
3.1.36 базовый стандарт POSIX: Интерфейс операционных систем, обеспечивающий
переносимость прикладных программ. Семейство стандартов, определяющее
стандартный интерфейс приложения с операционной системой вместе со средой,
обеспечивающей переносимость приложения в исходных кодах.
3.1.37 функциональный стандарт POSIX (POSIX ФС) (standardized profile (POSIX SP)): Функциональный стандарт, специфицирующий
применение определенных базовых стандартов POSIX для обеспечения класса приложений и полностью
соответствующий эталонной модели, определенной в ИСО/МЭК 14252.
3.1.38 профиль (profile): Набор из одного или нескольких базовых стандартов с
указанием, при необходимости, выбранных классов, подмножеств, опций базовых
стандартов, необходимых для выполнения конкретной функции. См. также профиль
прикладной среды (3.1.2), функциональный стандарт POSIX (3.1.37) и профиль СОС
системы организации-пользователя (3.1.53).
3.1.39 протокол (protocol): Набор семантических и синтаксических правил,
определяющий поведение взаимодействующих объектов.
3.1.40 общедоступные технические
требования (спецификации) (ОТТ) (publicly available specifications (PAS)). Спецификации, являющиеся доступными без каких-либо
ограничений и не требующие сублицензирования дополнительного разрешения для
применения и распространения (продажи) конкретной реализации.
3.1.41 эталонная модель (reference model):
Структурированный комплект взаимосвязанных представлений об объекте (например
информационной системе), охватывающий данный объект в целом, упрощающий
разбиение связей по тематике, который может быть представлен посредством
обычного описания.
3.1.42 путеводитель (road map): Общая схема
процесса.
3.1.43 масштабируемость (scalability): Способность обеспечивать
функциональные возможности вверх и вниз по упорядоченному ряду прикладных
платформ, отличающихся по быстродействию и ресурсам.
3.1.44 служба (услуга) (service): Отдельная часть функциональной возможности объекта,
которая предоставляется объектом на одной стороне интерфейса объекту на другой
стороне интерфейса.
3.1.45 соединители (sockets): Интерфейс транспортного протокола.
3.1.46 программное средство (software): Программы, процедуры, правила и любая
соответствующая им документация, имеющие отношение к эксплуатации системы
обработки информации.
3.1.47 технические требования
(спецификация) (specification): Документ,
устанавливающий законченным, точным, поддающимся проверке способом требования к
системе или компоненту системы, их проект, поведение или характеристики.
3.1.48 стандарт (standard): По ИСО/МЭК 14252.
3.1.49 функциональный стандарт (standardized profile): Прошедший процедуру голосования, официальный,
гармонизированный документ, определяющий профиль.
3.1.50 технология (technology): Научные знания, используемые для
достижения практической цели.
3.1.51 модель технологического
компонента (technology component model): Выбранные
службы ИТ, необходимые для реализации одной или нескольких служб ИС,
обеспечивающих реализацию ТБС.
3.1.52 пользователь (user): Источник деловых инициатив, которым должен
соответствовать профиль СОС организации-пользователя и реализацию которых этот
профиль должен обеспечивать. В настоящих рекомендациях понятия пользователь и
организация-пользователь взаимозаменяемы.
3.1.53 профиль СОС
организации-пользователя (user organization OSE profile): Профиль,
документально оформленный в терминах стандартов открытой системы (3.1.31), функциональных
стандартов POSIX (3.1.37), функциональных
стандартов (3.1.49) и (или) промежуточных технологий или изделий,
которые необходимы в качестве основы инфраструктуры при принятии решений по
удовлетворению деловых потребностей предприятия.
3.2 Сокращения
В настоящих рекомендациях использованы следующие
сокращения:
АВПР (САМ) — автоматизированное производство (Computer-Aided
Manufacture);
АПР (CAD) —
автоматизированное проектирование (Computer-Aided Design);
АПС (МТА) — агент передачи сообщения (Message Transfer Agent);
АСКИ (ASCII) —
американский стандартный код для информационного обмена (American Standard Code for Information Interchange);
БД (DB) — база
данных (Database);
БДН (MAU) — блок
доступа к носителю (Media Access Unit);
БУИ (MIB) — база управленческой информации (Management
Information Base);
BOC (OSI) — взаимосвязь открытых систем (Open System Interconnection);
ВТК (VTC) — видео-телеконференция (Video Teleconferencing);
ГВС (WAN) — глобальная вычислительная сеть (Wide Area
Network);
ГИП (GUI) —
графический интерфейс пользователя (Graphical User Interface);
ЦУБД (RDA) — доступ к
удаленной базе данных (Remote
Database Access);
ЕВРО (ECU) —
европейская денежная единица (European
Currency Unit);
ECOC (EWOS) —
европейский семинар по открытым системам (European Workshop on Open Systems);
ЗHK (RFC) — запросы на комментарий (Request For Comments);
ИВС (EEI) — интерфейс
с внешней средой (External Environment Interface);
ИГУ (GDI) — интерфейс
графического устройства (Graphics
Device Interface);
ИКУ (CSI) — интерфейс коммуникационных услуг (Communications
Services Interface);
ИП (UI) — интерфейс
пользователя (User Interface);
ИС (IS) —
информационные системы (Information Systems);
ИСГО (IGES) — исходная
спецификация графического обмена (Initial Graphics
Exchange Specification);
ИТ (IT) —
информационная технология (Information Technology);
ИЧК (HCI) — интерфейс
человек-компьютер (Human/Computer Interface);
ККУ (CSF) —
коэффициент критичности успеха (Critical
Success Factor);
ОАПЗО (КОРБА)*) (CORBA) — общая архитектура посредника запросов к объектам (Common Object Request Broker Architecture);
КПЭ (KPI) — ключевой
показатель эффективности (Key Performance Indicator);
ЛВС (LAN) — локальная
вычислительная сеть (Local
Area Network);
MKKTT (CCITT) — Международный
консультативный комитет по телефонии и телеграфии, см. МСЭ-Т (Consultative
Committee on International Telephony and Telegraphy);
ММГ (CGM) — метафайл машинной графики (Computer Graphics
Metafile);
MPA (ADM) — метод разработки архитектуры (Architecture Development Method);
МСЭ-Т (ITU-T) — Международный союз электросвязи — бюро телекоммуникационных стандартов (International
Telecommunication Union Telecommunication Standards Bureau);
МФС (ISP) — международный функциональный стандарт (International
Standardized Profile);
НД (BA) — направления
деятельности (Business Area);
ОГИ (CGI) — общий
графический интерфейс (Common
Graphical Interface);
ОПС (CAE) — общая прикладная среда (Common
Application Environment);
OPЗMC (DISC) — общепринятые решения заказчиков на основе международных стандартов (Delivering
International Solutions to Customers through International Standards);
ОС (OS) —
операционная система (Operating System);
OTT (PAS) —
общедоступные технические требования (Publicly Available Specifications);
ОУ (CM) — общее
управление (Common Management);
ОУБД (ODBC) — открытое
управление базами данных (Open Database Connectivity);
ПДЗД (LAPD) — протокол
доступа к звену данных (Link Access Protocol D);
ПДС (PPP) — протокол
двухточечного соединения (Point-to-Point
Protocol);
ПДУФ (FTAM) — передача, доступ и управление файлом (File Transfer, Access and Management);
ПП (АР) — прикладная платформа (Application
Platform);
ППИ (API) — прикладной программный интерфейс (Application
Program Interface);
ППС (АЕР) — профиль прикладной среды (Application Environment Profile);
ППУС (SNMP) — простой
протокол управления сетью (Simple Network Management Protocol);
ППФ (FTP) — протокол передачи файла (File Transfer
Protocol);
ППЭП (SMTP) — простой протокол электронной почты (Simple Message Transfer Protocol);
ПС (PS) — прикладная
служба (печати) (Print Service);
РАП (ATM) — режим
асинхронной передачи (Asynchronous Transfer Mode);
РВС (MAN) —
региональная вычислительная сеть (Metropolitan Area Network);
РВСР (DCE) —
распределенная вычислительная среда (Distributed Computing Environment);
РГУО (OMG) — рабочая
группа по управлению объектами (Object
Management Group);
РОТ (DTP) — распределенная обработка транзакций (Distributed
Transaction Processing);
PC (WS) — рабочая
станция (Workstation);
СИ (NI) — сетевой
интерфейс (Network Interface);
СОС (OSE) — среда
открытой системы (Open System Environment);
ССФ (NFS) — система
сетевых файлов (Network File System);
СТК1 (JTC1) —
Совместный технический комитет 1 ИСО/МЭК (Joint Technical Committee 1);
СТП (FUR) — структура
требований пользователя (Framework for User Requirements);
СУБД (DBMS) — система
управления базой данных (Database
Management System);
CУOOBD (OODBMS) — система
управления объектно-ориентированной базой данных (Object Oriented Database Management System);
СУРБД (RDBMS) — система
управления реляционной базой данных (Relational Database
Management System);
ТБ (UUT) —
тестируемый блок (модуль) (Unit Under Test);
ТБС (BSR) —
требование к бизнес-системе (Business
System Requirement);
ТСОП (PSTN) —
телефонная сеть общего пользования (Public Switched Telephone Network);
УВП (RPC) — удаленный
вызов процедуры (Remote Procedure Call);
УДС (MAC) —
управление доступом к среде (Media
Access Control);
УЛЗ (LLC) —
управление логическим звеном (Logical
Link Control);
ФК (FQ) —
функциональное качество (Functional Quality);
ФОС (OSF) — фонд
открытого программного обеспечения (Open Software Foundation);
ФС (SP) —
функциональный стандарт (Standardized Profile);
ЦСИС (ISDN) — цифровая
сеть с интеграцией служб (Integrated Services Digital Network);
ЭГ-СОС (EG-OSE) — экспертная группа по среде открытых систем (Expert Group — Open System Environment);
ЭОДФУКТ (ЭДИФАКТ*)) (EDIFACT) — электронный обмен данными для финансов,
управления, коммерции и торговли (Electronic Data Interchange for Finance, Administration, Commerce
and Trade);
ЭОД (EDI) — электронный обмен данными (Electronic Data
Interchange);
ЯГС (GKS) — ядро графической системы (Graphics Kernel
System).
*) Общепринятые, установившиеся в
практике сокращения.
3.3 Обозначения
В настоящих рекомендациях использованы следующие
обозначения:
BSD — программные средства, распространяемые лабораторией
Беркли (Berkley Software Distribution);
BSI — Британский институт стандартов (British Standards Institute);
CAN — сеть с абонентским доступом для комплекса зданий (Campus Area Network);
C-ISAM — интерфейс
языка Си для механизма доступа к индексно-последовательному файлу (The С Language Interface to Index Sequential file Access Mechanism);
e-mail — электронная почта (electronic mail);
FIPS — федеральный стандарт по обработке информации (США), Federal
Information Processing Standard);
FTR — федеральные рекомендации по телекоммуникациям (США) (Federal Telecommunications Recommendation);
IAB — Совет по деятельности в Интернете (Internet Activities Board);
IDEF — интегрированное описание и функциональное
моделирование (Integrated Definition and Functional Modeling);
IETF — рабочая группа по технологиям в Интернете (Internet Engineering Task Force);
I/F — интерфейс (Interface);
JFIF — формат файла обмена JPEG (JPEG File Interchange Format);
JPEG — объединенная экспертная группа по фотографии (Joint Photographic Experts
Group);
MIDI — цифровой интерфейс музыкальных инструментов (Musical Instrument Digital Interfase);
PASC — комитет IEEE по стандартам переносимости приложений (Portable Applications Standards Committee of
the IEEE Computer Society);
PHIGS — интерактивные иерархические графические системы для программиста (Programmers
Hierarchical Interactive Graphics Systems);
POSC — корпорация открытого программного обеспечения для
нефтяной промышленности (Petrotechnical Open Software Corporation);
POSIX — интерфейс операционных систем для вычислительных
сред, обеспечивающий переносимость приложений (Portable Operating Systems
Interface for Computer Environments);
SGML — стандартный обобщенный язык описания документов (Standard Generalized Markup
Language);
SQL — язык структурированных запросов (Structured Query Language);
TCP — протокол управления передачей данных (Transmission Control Protocol);
UDP — протокол дейтаграмм пользователя (User Datagram Protocol);
Win32 — набор руководств фирмы Microsoft по интерфейсам и ППИ системы Windows (The set of Windows
interface guidelines and APIs as published by Microsoft);
XA — описание интерфейса СУРБД по каналу передачи данных (X/Open DTP RDBMS
interfase definition);
XLIB — системная библиотека X Window (X Window System Library);
ХМ — описание интерфейса X/Open по каналу передачи данных (X/Open DTP Application interfase definition);
XPG — документ стандартов X/Open (X/Open Portability Guide);
XSI — системный интерфейс X/Open (X/Open System Interface);
XTI — транспортный интерфейс X/Open (X/Open Transport Interface);
2D — двумерный (Two Dimensions);
3D — трехмерный
(Three Dimensions).
*)
Общепринятые, установившиеся в практике сокращения.
4 Общие положения
4.1 Среда открытых систем (СОС)
СОС описывает функциональные особенности
информационных систем (ИС), необходимые для обеспечения переносимости и
функциональной совместимости приложений в гетерогенных (разнородных) сетях,
объединяющих аппаратные и программные платформы различных типов.
4.2 Профиль среды открытых систем
Профиль СОС представляет собой специально подобранный
набор базовых стандартов и устанавливаемых в них вариантов требований (опций),
которыми для конкретного класса или области приложений определяют на языке
функциональных требований, протоколов, интерфейсов, форматов данных и т.д.
функционирование приложений при их взаимодействии между собой.
Профили СОС описывают совокупность спецификаций,
формально представляющих потребности организации (или ее части) в
информационных технологиях. Профили СОС могут быть использованы для решения
любой из следующих проблем или их комбинаций:
—
инвентаризации принятых подходов к решению задач информатизации и выбора ИТ;
— помощи при
решении вопросов выбора новых продуктов ИТ и их приобретения;
— управления
процессом информатизации организации в целом.
Профиль СОС позволяет установить соответствие между
требованиями пользователя (решаемой проблемой), информационными службами и ИТ,
которые эти требования поддерживают, а также стандартами и спецификациями,
которым они соответствуют. Настоящие рекомендации содержат положения по выбору
конкретных требований пользователя и уточнению соответствия выбранных
стандартов этим требованиям. При наличии ряда альтернативных нормативных
документов профиль СОС может быть использован для выбора наиболее оптимального
нормативного документа, отвечающего задачам пользователя.
В случае, если ни один из известных нормативных
документов не может удовлетворить требованиям пользователя, профиль СОС
позволяет выявить «пробелы» в наличии нормативных документов, определяющих
требования пользователя. Профили СОС могут также содержать большое число
положений и требований, характеризующих подход конкретной организации к решению
таких вопросов информатизации, как например:
— существующие
и потенциальные требования («КАК ЕСТЬ» и «КАК ДОЛЖНО БЫТЬ»), установленные
профилем СОС, в том числе к стратегии деловой (основной) деятельности,
способам практической реализации (функциональной архитектуры) стратегии деловой
деятельности, стратегии информатизации, стратегии управления предприятием;
конечному пользователю;
— стандарты,
потенциально удовлетворяющие этим требованиям, включая действующие стандарты;
разрабатываемые стандарты (проекты), стандарты «де-факто» и общепринятые
спецификации;
— системы,
удовлетворяющие требованиям профиля СОС;
— планы учета
(переноса) требований пользователя и необходимых ему услуг;
— стратегии
перехода от одних информационных технологий к другим.
С учетом того, что потребности и стратегия организации
могут меняться, профиль СОС также может меняться и развиваться.
Примечание
— В ряде случаев организации относят к категории профилей документы, не
отвечающие назначению и правилам построения профилей. Например, часто профилями
СОС называют следующие документы:
— спецификации на закупку оборудования;
— планы стратегий развития;
— рекомендуемую последовательность действий;
— архитектуры технических средств.
4.2.1 Подход POSDC к понятию СОС
Подход POSDC к понятию
СОС основывается на выделении в составе информационной системы составных частей
или структурных элементов, каждый из которых объединяет в своем составе
совокупность объектов, близких по физической природе или родственных по какому-либо
признаку, называемую средой. Подход POSIX
основан на возможности отделения среды прикладной платформы (application platform entity) от среды
прикладных программных средств (application software entity) и внешней среды (external environment)
так, как показано на рисунке 1.
Рисунок
1 — Эталонная модель СОС (OSE)
Такое отделение упрощается, если указать все
интерфейсы между средами, включая поддерживаемые ими службы и форматы данных.
Для создания среды открытых систем необходимо в первую очередь обеспечить
стандартизацию «прикладного программного интерфейса» (ППИ — API) и «интерфейса внешней среды» (ИВС — EEI), а также служб и форматов данных. Система становится
«открытой» вследствие использования стандартов, разработанных для «открытого»
процесса.
Информационная система отвечает требованиям
«открытости» в зависимости от следующих аспектов (характеристик) ее реализации:
— система, на
которую не оформлены права собственности (незапатентованная система). Именно
такие системы, как правило, имеют в виду, когда утверждают, что «X является открытой системой», где в качестве X могут фигурировать такие системы, средства и
компоненты как Ada, POSIX, ANSI С, X Windows и
т.д. В этом случае X, теоретически являясь системой,
на которую не распространяются права собственности, может и не быть (официально
или неофициально) стандартизированной. При этом фактически необходима ее
независимая стандартизация без влияния со стороны поставщика (ов);
—
функционально совместимая система. Открытая (в этом случае) система легко
перенастраивается для работы и (или) взаимодействия с другими системами
(закрытая система не дает или даже запрещает такую возможность);
— расширяемая
(наращиваемая) система. Открытая (в этом случае) система может быть легко
расширена для обеспечения дополнительных функциональных возможностей, не
предусмотренных разработчиком системы, причем это расширение может быть
выполнено без помощи разработчика (закрытая система не может расширяться
пользователем или поставщиком без существенных затрат и (или) ограничения ее
функциональных возможностей).
На рисунке 1 показаны интерфейсы и большая
часть служб, входящих в эталонную модель среды открытых систем, в соответствии
с подходом POSIX. Эта модель является
достаточно гибкой для того, чтобы поддерживать различные виды архитектур, в том
числе часто используемую на практике архитектуру «клиент-сервер», которая может
быть реализована дублированием модели и соединением двух моделей посредством
внешнего связного интерфейса. Этот подход, предусматривающий добавление
распределенных служб (услуг) к списку основных служб модели, использован в
настоящих рекомендациях для представления моделей служб информационных
технологий.
Каждая из основных служб может
быть, в свою очередь, представлена в виде композиции более простых служб
информационных технологий (список служб информационных технологий приведен в
разделе 6), которые определяются базовыми стандартами. В ряде
случаев базовый стандарт имеет дополнения (варианты, опции)
без достаточной проработки порядка его применения. При этом должны быть выбраны
варианты (опции), отвечающие требованиям пользователя. В случае, если два
поставщика гарантируют соответствие поставляемых ими продуктов одному и тому же
базовому стандарту, достоверность обеспечения функциональной совместимости
данных продуктов должна быть подтверждена выбором одних и тех же вариантов
(опций) базового стандарта и соглашением о порядке его применения, что должно
быть учтено в процессе проектирования профилей СОС. Для обеспечения выбора
подходящих вариантов (опций) и соглашений о порядке применения базового
стандарта следует использовать прототип (макет) физической модели среды. Вопросы
тестирования на соответствие и функциональную совместимость профиля рассмотрены
в разделе 8.
При построении профиля СОС должны быть определены
используемые форматы данных и соответствующие им стандарты. Выбор и реализация
определений элементов данных, словарей данных, процесса деловой (основной)
деятельности и диаграмм связи между средами (объектами) модели гарантируют
переносимость самого профиля СОС наряду с переносимостью и функциональной
совместимостью данных, приложений и служб информационных технологий.
4.2.2 Процесс проектирования профиля СОС
организации-пользователя
Процесс проектирования профиля СОС, определенный
настоящими рекомендациями (более детально рассмотрен в разделе 5),
состоит из следующих этапов:
— этап 1 —
определение области применения профиля (т.е. установление направления
деятельности организации в целом или ее частей, для которых предназначен
профиль, например управление финансами);
— этап 2 —
выявление функциональных требований, предъявляемых пользователем (т.е. целевых
функций, присущих каждому из направлений деятельности, например обслуживание
клиентов);
— этап 3 —
определение ТБС (BSR) и ФК (FQ) (например своевременная еженедельная выплата
заработной платы);
— этап 4 —
определение требований к информационным службам (например к управлению базами
данных и обработке транзакций);
— этап 5 —
выявление информационных технологий, удовлетворяющих требованиям к конкретным
информационным службам (этот этап часто называют стадией логического
проектирования);
— этап 6 —
построение физической модели и выбор базовых стандартов (этот этап часто
называют конечным этапом проектирования);
— этап 7 —
анализ физической модели с целью убедиться в выполнении требований ТБС (BSR) и ФК (FQ);
— этап 8 —
окончательная доработка (настройка) физической модели;
— этап 9 —
окончательный выбор базовых стандартов, их вариантов (опций) и других
продуктов, в частности программного обеспечения (этот этап часто называют
эксплуатационным проектом);
— этап 10 —
определение стоимости жизненного цикла предложенного проектного решения;
— этап 11 —
реализация прототипа физической модели в соответствии с принятым решением.
При проектировании профиля СОС в ряде случаев можно
ограничиться уровнем построения физической модели и выбора базовых стандартов
на этапе 6. Использование моделирования элементарных процессов на ранних этапах
проектирования также помогает при реализации завершающих этапов (см. этапы 7 —
10 проектирования).
Если физический проект оказывается слишком
дорогостоящим для организации, возможен пересмотр ТБС (BSR). Например, при выплате заработной платы организация
может изменить технологию платежей (используя электронные платежные документы
взамен бумажных или проводя выплаты каждые две недели, а не еженедельно). Такое
разделение основного процесса на элементарные процессы (sub-process) часто
используют для усовершенствования процесса деловой (основной) деятельности
организации. Процедура усовершенствования процесса деловой деятельности
организации может быть определена как процесс перехода от состояния «КАК ЕСТЬ»
к состоянию «КАК ДОЛЖНО БЫТЬ». Процедуры усовершенствования процесса деловой
деятельности организации допускается использовать на начальном этапе выявления
требований (этап 2). Профиль СОС формируют на основе композиции результатов,
полученных на этапах 8 и 9. В профиле СОС рекомендуется отразить результаты,
полученные на этапах 1 — 5. Примерная структура профиля СОС приведена в разделе
7.
4.3 Метод, основанный на понятии
жизненного цикла
В настоящих рекомендациях профиль СОС рассматривается с
точки зрения его жизненного цикла. Жизненный цикл профиля СОС состоит из
следующих этапов (фаз): определения требований (requirement definition),
проектирования (design), практической реализации (implementation) и сопровождения (maintenance). На рисунке 2 показана
взаимосвязь между стратегией деловой (основной) деятельности организации (в
разрезе «сверху вниз» и «снизу вверх») и требованиями к функциональным
возможностям системы и проектированию профиля СОС, учитывающим участие
пользователей и специалистов по информационным технологиям.
Рисунок
2 — Взаимосвязь между стратегией
деловой (основной) деятельности организации и требованиями к функциональным
возможностям системы и проектированию профиля СОС
4.3.1 Этап определения требований
На этапе определения требований описывают
функциональные и технические требования, устанавливаемые в профиле СОС.
Результаты, полученные на этом этапе, могут вызвать изменения в технологии
проектирования профиля СОС, а также в корпоративной или деловой стратегии
организации. Эти требования формируются:
—
пользователями информационных служб;
— на основе
бизнес-планов организации;
— исходя из
текущей и перспективной стратегии организации по применению информационных
технологий;
— на основе
опыта эксплуатации систем, уже существующих в конкретной организации.
4.3.2 Этап проектирования
На этом этапе выполняется окончательное
проектирование. Результатом окончательного проектирования применительно к
профилю СОС является определение стандартов и выбор интерфейсов,
удовлетворяющих требованиям, предъявляемым к системе в целом. После того как
несколько вариантов проекта подвергнуты оценке с точки зрения стоимости
жизненного цикла или имеющихся рисков, может потребоваться корректировка
некоторых требований или проектных решений.
4.3.3 Этап практической реализации
После того как на этапе проектирования определен
основной вариант профиля СОС, проводится его более тщательная проектная
проработка [включая порядок применения вариантов (опций)]. Полученный в
результате проработки профиль СОС является основой для составления закупочной
спецификации. После получения системных программных и аппаратных средств от
поставщика их проверяют на соответствие функциональным и эксплуатационным
требованиям. Если полученные средства или платформы уже прошли у поставщика
аттестационное тестирование, процедура тестирования у потребителя может быть
сокращена при условии обеспечения совместимости этих средств со средствами в
организации пользователя. Более подробно вопросы тестирования рассмотрены в
разделе 8.1.
4.3.4 Этап сопровождения
На этапе сопровождения профиль СОС продолжает
выполнять полезную функцию в качестве инструмента для управления конфигурацией
системы. На этапе сопровождения профиль СОС превращается из документа, на
основании которого проводились закупки, в документ, определяющий стратегию
информатизации в целом и позволяющий установить план текущих и долгосрочных
мероприятий по развитию информационной инфраструктуры организации и внедрению в
ней новых информационных технологий.
4.4 Повторное использование профиля
Профили предназначены для многократного применения и
постоянной актуализации для более эффективной работы по внедрению и закупке
новых средств информационных технологий как для пользователей, так и для
разработчиков и производителей этих средств.
Практика использования профилей СОС для многих
организаций предусматривает распространение документации на профиль СОС среди
ряда организаций для выработки единого подхода к решению задач информатизации.
4.5 Использование метода построения
профилей СОС
В основу проектирования профилей СОС в настоящих
рекомендациях положен метод, основанный на использовании требований,
обусловленных стратегией деловой (основной) деятельности, принятой в конкретной
организации. Однако такой метод должен использоваться с учетом специфики конкретной
организации и перспектив ее развития по решению задач информатизации.
4.6 Преимущества от использования
профилей СОС
Использование профилей СОС дает следующие
преимущества:
—
независимость от поставщика;
— возможность
поддержки любого технологического образца;
— обеспечение
взаимосвязи между деловой (основной) деятельностью конкретной организации и
применяемыми информационными технологиями;
— обеспечение
интеграции и функциональной совместимости;
— обеспечение
реализации структуры инвестиций, дающей максимальную отдачу от вложений в
информационные технологии;
— обеспечение
наглядной и полной информации о результатах деятельности конкретной
организации.
5 Профиль СОС в организации-пользователе
5.1 Эталонная модель СОС POSIX
Эталонная модель СОС POSDC (ИСО/МЭК 14252) разработана для обеспечения
переносимости приложений между платформами разных производителей. Переносимость
приложений расширяет конкурентоспособность применяемых приложений и платформ и
обеспечивает автоматическую модернизацию при их изменениях.
Эталонная модель СОС POSDC устанавливает три объекта [прикладные программные
средства (application software), прикладную платформу (application platform)
и внешнюю среду (external environment)] и два интерфейса между ними, обозначаемых как ППИ (API) и ИВС (EEI).
Эталонная модель СОС POSDC (рисунок 3) предусматривает наличие
следующих служб, обеспечивающих взаимосвязь прикладных программных средств с
прикладной платформой:
— системные
службы, обеспечивающие услуги операционных систем и языков;
—
коммуникационные службы, обеспечивающие возможности совместной работы между
системами;
—
информационные службы, обеспечивающие переносимость данных на запоминающие
устройства;
— службы
интерфейса человек-компьютер [ИЧК (HCI)],
обеспечивающие переносимость персонала.
Для обеспечения этих служб используют технические
требования (спецификации), определенные стандартами и другими нормативными
документами.
Рисунок 3 — Эталонная модель СОС POSIX
5.2 Типы профилей
Взаимосвязь между стандартами и различными типами
профилей показана на рисунке 4.
Рисунок
4 — Взаимосвязь между стандартами и
различными тихими профилей
В различных областях деятельности и организациях
имеются готовые к применению профили. Наиболее широко известны профили,
используемые для описания коммуникационных служб, применяемых для обеспечения
взаимосвязи открытых систем (ВОС).
Профиль, проектируемый на основе единственного
стандарта, включает подмножество конкретных значений вариантов требований
(опций) и параметров, установленных в данном стандарте. Данный тип профиля
определяется как «профиль компонента» и используется поставщиком в качестве
основы для описания конкретной реализации.
Профиль прикладной среды (ППС) может включать
комбинацию множества стандартов и «профилей компонентов», определяющую разные
типы функциональных возможностей, необходимых для конкретной среды.
Функциональный стандарт (стандартизованный профиль) POSIX является набором из одного или нескольких базовых
стандартов POSIX для описания конкретной
функциональной возможности.
Международный функциональный стандарт (МФС) является
международно признанным документом, описывающим один или несколько профилей.
Пример — ИСО/МЭК МФС 11183-1.
Организации пользователей могут разрабатывать профили
СОС для описания технологии, необходимой для обеспечения своей деятельности.
Профиль СОС организации-пользователя должен включать:
— область
применения и назначение потребностей или требований пользователя;
— ссылки на
один или несколько базовых стандартов или других профилей;
— конкретные
формулировки условий использования вариантов из базовых стандартов;
— решения по
«пробелам» в областях действия стандартов или конфликтам между стандартами;
— требования
соответствия профилю.
Профиль СОС должен быть полным, согласованным и
однозначно понимаемым.
Профили СОС направлены на обеспечение использования
пользователями и производителями широко известных стандартов СОС для
определения поставляемых систем и услуг или описания конкретного требования к
продукции.
5.3 Профили СОС организации-пользователя
Профили СОС организации-пользователя могут иметь более
широкую область применения, чем технические профили, описанные в 5.2.
Профили СОС организации-пользователя могут применяться для описания
компьютерных или коммуникационных технологий, обеспечивающих деятельность:
— предприятия
в целом (например нефтехимического комбината);
— области
деловой деятельности (ОДД) организации (например технического отдела
нефтехимической компании);
— конкретных
технических требований к деловой системе (ТДС) (например автоматизацию
учреждения).
Настоящий раздел содержит уточненное описание профилей
СОС организации-пользователя. Руководство по разработке профиля СОС
организации-пользователя приведено в разделе 6.
Профили СОС организации-пользователя, независимо от
области их применения, определяют требования пользователя, информационные
службы (услуги), а также конкретные стандарты и профили, обеспечивающие эти
службы. При отсутствии действующих стандартов для информационной службы
необходимо определить «пробелы» в технологии, реализующей эту службу. При
закупке готовой продукции или разработке новой продукции, требования к которой
не определены стандартами и профилями, для заполнения таких «пробелов» могут
быть использованы другие нормативные документы или требования, применяемые в
конкретной организации. Заполнение «пробелов» зависит от специфики организации
и определяется финансовыми, временными и функциональными ограничениями ее
деятельности.
Профили СОС организации-пользователя используются в
зависимости от декомпозиции технологической структуры на составляющие
компоненты (рисунок 5).
Рисунок
5 — Декомпозиция технологической
структуры на составляющие компоненты
На высшем уровне профиль СОС организации-пользователя
описывает технологическую структуру, необходимую для обеспечения деловых
потребностей организации. Технологическая структура предусматривает
декомпозицию структуры организации по областям направлений ее деятельности
(НД).
На рисунке 6 приведен пример
технологической структуры организации-пользователя, определяющей три области
(домена) направлений ее деятельности (в структуре нефтехимической компании).
На следующем уровне профиль СОС
организации-пользователя может быть уточнен для компонентов каждой
вычислительной среды (НД или домена), предназначенной для конкретного
компонента. Языком, используемым на этом уровне профиля, является язык служб
ИТ, необходимый для обеспечения требований к бизнес-системам (ТБС) организации.
Рисунок
6 — Пример технологической структуры
организации-пользователя
На рисунке 7 приведен пример технической
вычислительной среды с технологическими компонентами, необходимыми для
обеспечения служб ИТ, определяющими требования к бизнес-системе (ТБС) для
конкретной вычислительной среды (например для области технической деятельности
нефтехимической компании).
Рисунок
7 — Пример технической вычислительной
среды
На следующем уровне каждый технологический компонент в
профиле СОС организации-пользователя должен быть описан набором служб ИТ,
необходимых для поддержки конкретного компонента. На рисунке 8
приведен пример модели (шаблона) технологического компонента, содержащей
основные службы ИТ.
Рисунок
8 — Пример модели (шаблона)
технологического компонента
Конкретные технологические
компоненты в каждой вычислительной среде содержат только подмножество служб ИТ,
необходимых для удовлетворения требований к бизнес-системам (ТБС) организации.
Конкретные технологические компоненты могут быть представлены в моделях
(шаблонах) технологических компонентов, которые описывают только необходимые
службы ИТ. На рисунке 9 приведен пример модели (шаблона)
технологического компонента «Общая рабочая станция».
Рисунок 9 — Пример модели (шаблона) технологического
компонента «Общая рабочая станция»
Область применения профиля СОС
организации-пользователя описывается рядом моделей технологических компонентов.
На низшем уровне каждая служба ИТ может быть описана в
виде модели общей (абстрактной) службы ИТ и модели используемой (организационно
зависимой) службы ИТ.
Для моделей служб ИТ используют те же схематические
обозначения, что и для эталонной модели СОС (рисунок 3), в которой эти службы
определяют интерфейсы ППИ и ИВС. На рисунке 10 показана модель общей службы
ИТ (службы отображения).
Рисунок
10 — Пример модели общей службы ИТ
(службы отображения)
На рисунке 11 приведен пример модели
используемой службы ИТ для службы отображения в СОС. Интерфейсы, установленные
в модели общей службы ИТ, определяются стандартами или техническими профилями.
Рисунок 11 — Пример модели используемой службы ИТ (служба
отображения в СОС)
6 Процесс разработки профиля СОС
организации-пользователя
6.1 Общие положения
Проектирование информационных систем на основе
внедрения технологии открытых систем позволяет обеспечить взаимодействие
(интероперабельность) систем и переносимость (мобильность) прикладных
программных средств между системами. Применение технологии открытых систем в
качестве основы для реализации целей деятельности организации обеспечивает
независимость от поставщика, гибкость в использовании средств телекоммуникаций,
технических и программных средств, уменьшает время переобучения персонала.
Процесс разработки профилей СОС, представленный в
настоящих рекомендациях, основан на методике выделения и определения
эксплуатационных потребностей и требований организации-пользователя и
разработке на их основе профилей СОС организации-пользователя, направленных на
обеспечение независимости от поставщиков технических и программных средств при
проектировании информационных систем.
Настоящая методика позволяет осуществить на основе
профиля СОС увязку требований к деловой деятельности организации с техническими
решениями организации-пользователя при проведении работ по информатизации.
Требования к профилю, выраженные в требованиях к ТБС и требованиях к службам
информационной системы (ИС), необходимых для их поддержки, разрабатывают
«сверху вниз» (от общих положений и требований к частным). Выделение служб ИТ,
необходимых для обеспечения служб ИС, выраженных в требованиях стандартов и в требованиях
к продуктам (изделиям), разрабатывают итеративным способом «снизу вверх» (от
частных положений и требований к общим).
6.2 Модель процесса создания профиля СОС
организации-пользователя
Общая модель разработки профиля СОС
организации-пользователя (рисунок 12) является расширением этапов (фаз)
установления требований и проектирования профиля в соответствии с взаимосвязью
между стратегией деловой (основной) деятельности организации и требованиями к
функциональным возможностям системы и проектированию профиля СОС (рисунок 2).
Рисунок
12 — Общая модель разработки профиля
СОС организации-пользователя
Краткое описание этапов разработки профилей СОС в 6.2.1 —
6.2.5.
Подробное описание в 6.3 — 6.7.
6.2.1 Область действия
На этом этапе разработки профиля СОС
организации-пользователя определяют область его применения, то есть направления
деловой деятельности, на которые ориентирован конкретный профиль.
6.2.2 Анализ требований
Этап анализа требований к профилю СОС организации-пользователя
состоит в определении эффективного набора ТБС, их функциональных качеств (ФК),
а также декомпозиции набора ТБС на службы ИС. Выходным документом этого этапа
разработки профиля СОС является матрица перекрестных ссылок между ТБС и
службами ИС.
6.2.3 Логический проект
На этапе логического проекта определяют службы ИТ,
необходимые для поддержки ИС. В результате выполнения этого этапа разработки
профиля СОС определяют: технологическую структуру, вычислительную среду, модели
технологических компонентов, а также общие модели служб ИТ вместе со службой
ИТ/ИС и матрицами перекрестных ссылок между моделями служб ИТ и
технологическими компонентами.
6.2.4 Физический проект
На этапе физического проекта определяют совокупность
связей общих моделей служб ИТ и технологических компонентов со стандартами.
Должны быть также определены варианты требований (опции) базовых стандартов для
обеспечения взаимодействия общих моделей служб ИТ и технологических компонентов
со стандартами, а ФК используют для принятия решений о применимости стандартов.
При этом необходимо определить поддерживаемые профилем СОС характеристики,
учитывающие специфику организации, включая работу в многоязычных и
мультикультурных средах.
В результате выполнения этапа физического
проектирования определяют: полностью описанные модели службы ИТ, модели
технологических компонентов и структуру (перечень) стандартов СОС для
организации-пользователя.
6.2.5 Эксплуатационный проект
Этап эксплуатационного проектирования состоит в
применении ФК и требований к физическим моделям и выбору конкретных технических
и программных средств. В результате выполнения этого этапа разработки профиля
СОС определяют каталог технических и программных средств СОС для
организации-пользователя.
Эксплуатационный проект сопровождают планом внедрения
и тестирования. В соответствии с настоящими рекомендациями создание профиля СОС
организации-пользователя завершается на этапе физического проектирования.
6.3 Определение области действия профиля
(этап определения области применения)
Эффективность разработки и реализации профиля СОС
организации-пользователя зависит от области действия (применения)
разрабатываемого профиля. Например, профиль СОС организации-пользователя может
охватывать отрасль в целом, отдельную организацию или ее подразделение.
Разработка и внедрение профиля СОС организации-пользователя с разветвленной
структурой обеспечивает совершенствование связей между различными
подразделениями организации, гарантирует взаимодействие информационных систем
этих подразделений, а также переносимость прикладных программных средств между
платформами разных поставщиков.
На этапе определения области применения выявляют:
— направления
деятельности (например отраслей, ведомств), подлежащие учету в профиле;
— срок
реализации профиля, то есть срок окончания создания профиля;
— деловые и
технические стратегии, положения и ограничения;
— лучшие
деловые показатели деятельности конкретной организации;
— потенциал
коллектива, разрабатывающего конкретный профиль, а также его возможности и
знания при экспертизе деловой деятельности организации.
6.4 Анализ требований к документу
«Структура требований пользователя»
Этап анализа требований к документу СТП должен
гарантировать направление ресурсов организации на решение проблем
взаимодействия и переносимости (мобильности) прикладных программных средств,
связанных с ключевыми целями организации. Руководители высшего уровня должны
описать эти цели способом, который может быть легко понят руководителями
среднего звена, снабженцами, инженерами и техническими исполнителями,
отвечающими за реализацию технических решений.
СТП рекомендует определение представительного набора
ТБС, определенного посредством процесса декомпозиции служб организации. СТП
предусматривает применение метода разработки архитектуры (МРА) [2]. В
настоящих рекомендациях приведено описание метода МРА для разработки профилей
СОС организации-пользователя, а также другие применяемые методы. Целевое
назначение методов разработки архитектуры определяют в три этапа:
1 — установление направлений деятельности (НД);
2 — установление требований к бизнес-системе (ТБС);
3 — выделение служб ИС.
6.4.1 Выделение направлений деятельности (НД)
В зависимости от специфики конкретной организации НД
могут быть отнесены к различным проблемно-ориентированным направлениям
деятельности (деловые, эксплуатационные, военные или образовательные
направления). Для каждого конкретного НД указывают ключевые показатели
эффективности (КПЭ) управления конкретной организацией. НД определяют как
области различных деловых функций, перекрывающих ведомственные и географические
границы в пределах конкретной организации.
На рисунке 13 приведен пример выделения
различных направлений деятельности.
Рисунок
13 — Пример выделения различных
направлений деятельности
Конечный профиль СОС организации-пользователя должен
отвечать реальным деловым потребностям организации: организационная структура
или географическое положение конкретной организации не должны влиять на профиль
СОС организации-пользователя.
6.4.2 Установление требований к бизнес-системе (ТБС)
Следующей стадией анализа требований является
установление ТБС для каждого НД. В зависимости от специфики организации ТБС
могут рассматриваться в зависимости от требований в различных
проблемно-ориентированных направлениях деятельности (деловые, эксплуатационные,
военные или образовательные).
ТБС определяют из множества деловых потребностей,
требующих технологической поддержки для обеспечения соответствующего КПЭ или
попадания в первый десяток коэффициента критичности успеха в КПЭ предприятия.
Подготовка предполагаемого профиля СОС организации-пользователя должна включать
исчерпывающе полный набор ТБС для каждого НД и предполагаемое развитие профиля
во времени. ТБС определяют, как правило, для перспективных (в настоящее время
не реализуемых) требований.
По важности на первое место ставят ТБС подразделений,
собирающих информацию для организации, т.е. подразделения ИТ, выполняющих,
например, функции планирования, служб управления и т.д.
На рисунке 14 приведен пример выделения
(декомпозиции) технических направлений деятельности в требования к
бизнес-системе.
Рисунок
14 — Пример выделения (декомпозиции)
технических направлений деятельности в требования к бизнес-системе
ТБС для области действия профиля должны быть
установлены и документально оформлены, исходя из требований их деловых целей и
ФК с учетом состава пользователей и качества требуемых служб. Пример каталога
ТБС приведен в таблице 1, пример матрицы ТБС/ФК — в таблице 2.
Таблица 1 — Пример каталога ТБС
|
Направление деятельности (НД) |
Краткое содержание |
|
|
1 |
Административные |
|
|
1.1 |
Финансовые |
Продажи, |
|
1.2 |
Операции |
Управление |
|
1.3 |
Кадровые |
Проект |
|
2 |
Технические |
|
|
2.1 |
Контроль |
Хранилища |
|
2.2 |
Моделирование |
Объемное |
|
2.3 |
Планирование |
Результат |
|
3 |
Эксплуатационные |
|
|
3.1 |
Интерфейс |
Управляющий |
Таблица 2 — Пример матрицы ТБС/ФК
|
ФК |
Требования к бизнес-системе по направлениям |
||||||
|
Финансовые операции |
Управление проектом |
Кадровые вопросы |
Контроль качества |
Моделирование |
Планирование и составление графиков |
Интерфейс к операциям автоматизированного |
|
|
Число |
100 |
50 |
50 |
50 |
150 |
50 |
100 |
|
Число |
50 |
25 |
25 |
25 |
70 |
10 |
50 |
|
Требования |
1 |
50 |
1 |
10 |
100 |
1 |
350 |
|
Число |
1 |
1 |
5 |
5 |
1 |
1 |
1 |
|
Наличие |
12 ∙ 5 |
12 ∙ 5 |
12 ∙ 5 |
12 ∙ 5 |
12 ∙ 5 |
12 ∙ 5 |
24 ∙ 7 |
Требования к ТБС по
направлениям деятельности в зависимости от функционального качества (ФК)
необходимо увязать с помощью процесса выделения (декомпозиции) со службами ИС,
службами ИТ, технологическими компонентами и стандартами, образующими профиль
СОС организации-пользователя.
Конкретная организация должна официально согласовать
ТБС и определить приоритетные направления деятельности со своими партнерами.
Приоритетные направления деятельности и ТБС должны определять общие требования,
которым должен удовлетворять профиль СОС.
ТБС описывают на деловом языке конкретной организации,
тем самым обеспечивая взаимную увязку деловых потребностей организации с
принимаемыми техническими решениями.
6.4.3 Установление требований к службам ИС
На этом этапе разработки профиля СОС
организации-пользователя осуществляют выделение (декомпозицию) каждого ТБС на
службы ИС, необходимые для поддержки ТБС.
Служба ИС определяет конкретную услугу обработки
информации, необходимую для поддержки ТБС. Например, ТБС для управления
промышленным производством требует обеспечения службами ИС обработки в реальном
времени, управления базой данных, обработки документов и изображений,
накопления и восстановления данных и т.д.
Функциональные качества, связанные с каждым
требованием ТБС, требуют реализации службами ИС, обеспечивающими ТБС.
На рисунке 15
показана взаимосвязь между ТБС и службами ИС.
Рисунок
15 —
Взаимосвязь между ТБС и службами ИС и ТБС
Для определения взаимосвязи между требованиями к
бизнес-системе и службами ИС используют матрицу. Пример матрицы перекрестных
ссылок ТБС/службы ИС приведен в таблице 3.
Таблица 3 — Пример матрицы перекрестных ссылок ТБС/службы ИС
|
Служба |
Требования к бизнес-системе (ТБС) |
||||||
|
Финансовые операции |
Управление проектом |
Кадровые вопросы |
Контроль качества |
Моделирование |
Планирование и составление графиков |
Интерфейс к операциям автоматизированного |
|
|
Система |
Да |
Да |
Да |
Да |
Да |
Да |
|
|
СУБД |
Да |
Да |
Да |
Да |
Да |
Да |
Да |
|
Система |
Да |
Да |
Да |
Да |
Да |
||
|
Обработка |
Да |
Да |
Да |
Да |
Да |
Да |
Да |
|
АПР/АВПР |
Да |
Да |
|||||
|
Обработка |
Да |
Да |
Да |
||||
|
Статистический |
Да |
||||||
|
Обработка |
Да |
Да |
Да |
Да |
|||
|
Публикации |
Да |
Да |
|||||
|
Электронная |
Да |
Да |
|||||
|
Обработка |
Да |
||||||
|
Компьютерная |
Да |
Да |
|||||
|
Видеоконференция |
Да |
Да |
Да |
Да |
|||
|
Управление |
Да |
Согласованные ТБС,
спроецированные на обеспечивающие их службы ИС, составляют основу перечня
(спецификации) требований к профилю СОС организации-пользователя. Они также
служат источником информации для разработки схем технологической структуры и
вычислительной среды, показанных на рисунках 6 и 7.
Подобные перекрестные ссылки также являются первым
этапом отражения деловых требований в технологических (методических) решениях.
6.5 Определение служб ИТ (этап
логического проектирования)
На этом этапе создания профиля СОС выделяют (определяют)
службы ИТ, необходимые для представления служб ИС, которые в свою очередь
необходимы для обеспечения деловой деятельности организации.
Служба ИТ представляет отдельную (специфическую)
область технологии, реализуемую конкретной службой.
Многоуровневые отношения между службами ИС и ИТ
показаны на рисунке 16.
Рисунок 16 — Многоуровневые отношения между службами ИС и ИТ
Рисунок
17 — Выделение (декомпозиция) групп
службы ИТ
Эталонная модель СОС POSIX (см. рисунок 3)
определяет четыре главные группы служб (услуг) СОС:
1) службу интерфейса человек-компьютер;
2) системную службу;
3) информационную службу;
4) коммуникационную службу.
Такое определение главных групп служб (услуг) СОС
имеет высокий уровень обобщения и для обеспечения реализации требует
преобразования этих групп в конкретных моделях в группы среднего и (или)
низкого уровня.
Способ детализации, применяемый в настоящих
рекомендациях, предусматривающий три уровня выделения (декомпозиции), показан
на рисунке 17.
Группировки модели СОС содержат службы, определенные в
эталонной модели СОС POSIX.
Группировки профиля СОС организации-пользователя использованы в методе
разработки архитектуры (МРА) [2]. Службы ИТ являются самым низким уровнем
выделения (декомпозиции) и представляют собой службы, определяемые стандартами
и реализуемые в виде продуктов (изделий). Такое выделение (декомпозиция)
облегчает построение моделей технологических компонентов, представленных на
рисунках 8
и 9.
В таблице 4 представлен пример матрицы перекрестных связей служб
ИС и ИТ. В таблице 5 представлен пример матрицы перекрестных связей
технологических компонентов и служб ИТ.
Примеры групп служб ИТ профиля СОС организации-пользователя и охватываемых
ими отдельных служб ИТ приведен в таблице 6.
Таблица 6 — Примеры групп служб ИТ
профиля СОС организации-пользователя и охватываемых ими отдельных служб ИТ
|
Группа |
Группы служб ИТ профиля СОС |
Служба ИТ |
|
Службы интерфейса человек-компьютер |
Представление |
Символьное (строка команд) |
|
Графический |
||
|
Двумерная |
||
|
Трехмерная |
||
|
Видео |
||
|
Аудио |
||
|
Ввод |
Символьный |
|
|
Чертежный |
||
|
Штрих-код |
||
|
Смарт-карта |
||
|
Видео |
||
|
Аудио |
||
|
Системные |
Обработка |
Многозадачная |
|
Многопроцессорная |
||
|
В |
||
|
Суперкомпьютерная |
||
|
Локальные |
Электронная |
|
|
Распечатка |
||
|
Использование |
||
|
Системное |
||
|
Информационные |
Обмен |
Запись |
|
Текст |
||
|
Изображение |
||
|
Черчение |
||
|
Видео |
||
|
Аудио |
||
|
Управление |
СУБД |
|
|
Объектная |
||
|
Плоский |
||
|
Обработка |
||
|
Коммуникационные |
Распределенные |
Передача |
|
Электронная |
||
|
Электронный |
||
|
Доступ |
||
|
Вызов |
||
|
Управление |
||
|
Управление |
||
|
Сетевое |
||
|
Авторизация |
||
|
Аутентификация |
||
|
Аудит |
||
|
Взаимосвязь |
ЛВС |
|
|
Магистральная |
||
|
РВС |
||
|
Телефонная |
||
|
ГВС |
Таблица 6
приведена в качестве примера и не исчерпывает перечень служб ИТ. При
определении служб ИТ для конкретного профиля СОС организации-пользователя
некоторые из приведенных в таблице 6 служб ИТ могут не использоваться.
Пользователь может в случае необходимости дополнить данный список другими
службами ИТ.
После определения необходимых служб ИТ создают общие
модели конкретных служб ИТ как показано на рисунке 10.
6.6 Определение стандартов, технических
профилей и внутренних технологий (этап физического проектирования)
На этапе физического проектирования осуществляют
наполнение общих моделей служб ИТ. Это наполнение требует принятия технических
решений и выбора стандартов, удовлетворяющих целям взаимодействия и
переносимости, а также собственных решений, применяемых в переходный период до
определения финансового обеспечения и принятия недостающих стандартов.
Для выявления действующих и планируемых к разработке
стандартов и профилей может быть использован ИСО/МЭК 14252, а также другие
информационные источники.
Целый ряд организаций, например таких как POSC, разработали документы, в которых определены
стандарты и профили, применяемые для удовлетворения их требований.
Выбор (декомпозиция) ТБС в службы ИТ позволяет
сократить число стандартов, которые необходимо использовать при разработке
профиля СОС организации-пользователя.
В модели (шаблоны) общих моделей служб ИТ должны быть внесены
конкретные интерфейсы, службы платформы и службы взаимосвязи. В ряде случаев
стандарт или спецификация могут отсутствовать. В зависимости от наличия времени
на разработку профиля допускаются следующие варианты решения:
— поиск
промышленного, частного или разрабатываемого стандарта, удовлетворяющего
потребностям организации-пользователя;
— поиск
изделия (реализации, имеющейся в продаже), удовлетворяющего требованиям к
службе ИТ;
— принятие
решения, устраняющего отсутствие утвержденного стандарта или спецификации;
— отсрочка
реализации до появления требуемого для разработки профиля СОС стандарта.
Выбор варианта решения зависит от подхода к деловой
деятельности в конкретной организации.
Выбор конкретных стандартов для наполнения логических
моделей служб ИТ зависит от:
—
взаимодействия с ранее выбранными стандартами;
— наличия
продуктов (изделий) в продаже;
— степени
соответствия показателям назначения (ФК) (выделенным из ТБС).
Процесс наполнения логических моделей служб ИТ
является итерационным.
Если профиль СОС организации-пользователя охватывает
широкую область, он может быть пригоден для наполнения логических моделей
различными взаимосвязанными принятыми и разрабатываемыми стандартами (с
указанием ближайших, средних и отдаленных сроков принятия разрабатываемых
стандартов). Указание сроков принятия разрабатываемых стандартов облегчит
планирование внедрения профиля СОС.
Процесс создания профиля СОС считают завершенным, если
наполнены модели служб ИТ, как показано на рисунке 11, и созданы матрицы
перекрестных связей, как показано в таблицах 4 и 5. Модели технологических
компонентов, полностью определенные в требованиях наполняющих их служб ИТ, и их
показатели назначения (ФК) допускается использовать в качестве закупочных
спецификаций. Наполненные модели служб ИТ могут быть использованы для
разработки и реализации технических заданий, а также в качестве руководства для
аттестационного тестирования.
6.7 Выбор продуктов (этап
эксплуатационного проектирования)
На этапе эксплуатационного проектирования для того,
чтобы физический проект соответствовал требованиям исполнения, процесс
разработки профиля СОС должен быть дополнен этапом, обеспечивающим применение
профиля СОС для закупки соответствующих продуктов. В этом случае технические
решения для каждой конкретной организации будут уникальны и могут изменяться во
времени.
В ряде случаев продукты, определенные стандартами,
недоступны или не полностью отвечают требованиям совместимости с ранее
выбранными изделиями. В этом случае полученный профиль СОС и требования
совместимости следует откорректировать на следующей итерации.
Физический проект (6.6) должен быть реализован в
требованиях конкретных стандартов, наполненных моделей служб ИТ и
технологических компонентов, требующих реализации. Важно, чтобы именно эти
модели были полностью наполнены до перехода к практическому применению профиля
СОС.
Выбор продуктов и их интеграция
усложняются, если на одной платформе должно функционировать множество
приложений. В этом случае выбор ППИ и операционной системы имеет решающее
значение. Дополнительная информация — в разделе 8.
Пример выбора продукции (изделий) приведен на рисунке 18.
Необходимыми исходными данными являются:
— справочный
каталог продукции — источник информации по существующей и разрабатываемой
продукции и стратегиям ее разработки;
— стратегия ИТ
организации, разрабатывающей стандарты на изделия конкретной организации и
определяющей требования по их сопровождению и эксплуатации другими
организациями;
— физическая
модель профиля СОС организации-пользователя;
— ФК для ТБС —
требования к рабочим характеристикам ТБС, использованные для фрагментации
профиля, в терминах производительности, числа одновременно работающих
пользователей, времени отклика, объемов баз данных, работоспособности, защиты
информации и т.д.
Рисунок
18 — Пример выбора продукции
(изделий)
Для реализации одного и того же физического
технологического компонента могут быть выбраны разные продукты (изделия) в зависимости
от ФК служб ИС, которые технологический компонент будет обеспечивать в
различных областях, удовлетворяя различным ТБС.
В результате обработки (нормализации) исходных данных
создают каталог продукции и поставщиков для конкретной организации. Данный
каталог продукции и поставщиков должен служить справочным перечнем при заказах.
В целом процесс создания профиля СОС
организации-пользователя направлен от установления требований к деловой
деятельности к технологическим решениям в соответствии с требованиями к
внедряемым (реализуемым) продуктам (изделиям) и позволяет:
— снижать
стоимость и сроки процесса заказа;
—
устанавливать долгосрочные отношения с продавцами;
—
стимулировать разработку продуктов (изделий);
— служить
основой для будущих разработок и стимулировать развитие системы, гарантирующей
максимальное взаимодействие.
7 Рекомендуемая структура профиля СОС
организации-пользователя
7.1 Рекомендуемая структура
Настоящий пункт должен содержать описание: концепции
профиля СОС; процесса разработки, внедрения и сопровождения этих профилей, а
также в нем рассмотрены вопросы, связанные с профилями СОС
организации-пользователя и возможными путями разработки профиля СОС, что должно
упростить способ общения для организаций-пользователей и позволить максимально
использовать повторно общие элементы, обеспечивая в то же время защиту
коммерческой и государственной тайны.
Рекомендуемая структура профиля СОС
организации-пользователя:
1 Назначение данного профиля СОС
организации-пользователя.
2 Специфика предприятия.
3 Детализированный профиль СОС
организации-пользователя:
а) область применения профиля;
б) анализ требований;
в) логический проект;
г) физический проект.
4 Заключение и выводы.
7.1.1 Назначение конкретного профиля
СОС организации-пользователя
Настоящий подпункт должен содержать описание общих
деловых и технологических предпосылок для создания профиля СОС
организации-пользователя и формулировку существующих и перспективных проблем,
решению которых должен способствовать профиль.
7.1.2 Специфика предприятия в профиле СОС
организации-пользователя
Настоящий подпункт должен содержать краткое описание
существующей и перспективной деловой и эксплуатационной среды, на которую
должен быть ориентирован профиль.
7.1.3 Детализированный профиль СОС организации-пользователя
Настоящий подпункт должен содержать необходимые
уточнения профиля СОС организации-пользователя и процессы его разработки в
соответствии с рекомендациями, приведенными в разделах 5 и 6.
7.1.3.1 Область применения профиля
Деловая область применения профиля СОС
организации-пользователя может быть кратко описана при помощи диаграмм Венна,
общих блок-схем, нотации IDEF или любой другой
формы наглядного представления.
7.1.3.2 Анализ требований
Настоящий подпункт должен документально представлять в
наиболее наглядной форме направления деятельности (НД), выделяемые в следующие
области применения профиля:
— принятого и
утвержденного каталога ТБС-документов, включая ФК для каждого ТБС;
— выбранных
служб ИС, документально оформленных в виде каталога служб ИС;
— матрицы
перекрестных связей (ссылок) ТБС/службы ИС.
7.1.3.3 Логический проект
Настоящий подпункт должен документировать логический
проект профиля СОС организации-пользователя с учетом:
— выбранных
служб ИТ;
— матрицы
перекрестных связей служб ИС и ИТ;
— логических
моделей технологических компонентов;
— логических
моделей служб ИТ;
— компьютерной
среды для каждой из областей деловой деятельности;
—
технологической структуры — общей диаграммы области применения в пределах
развертываемых технологических компонентов;
— любых
матриц, связывающих службы ИС/ИТ и технологические компоненты.
7.1.3.4 Физический проект
Настоящий подпункт должен документировать наполнение
компонентов логического проекта в терминах профилей, общих технических
требований (ОТТ) и базовых стандартов, а также идентифицировать «пробелы», то
есть позиции, в которых отсутствуют существующие и разрабатываемые стандарты.
Когда в профиле СОС организации-пользователя могут быть использованы два или
более подходящих стандартов, выбор стандарта должен зависеть от его
реализуемости в конкретном продукте, соответствия ФК и совместимости с другими
стандартами, входящими в профиль. В результате должен быть получен документ —
структура стандартов для описания наполненных логических моделей служб ИТ и
технологических компонентов.
8 Вопросы, связанные с профилем СОС
организации-пользователя
8.1 Аттестационное тестирование
Профиль в целом объектом тестирования не является,
однако тестированию подлежат отдельные входящие в него компоненты. Подлежат
тестированию конечные цели функционирования профиля. Отдельные компоненты
профиля подлежат тестированию на соответствие необходимым стандартам и
требованиям, определяющим ФК.
При тестировании соответствия конкретной реализации
требованиям профиля СОС организации-пользователя применяют системный подход,
включающий:
— тестирование
конкретных заявок о соответствии базовым стандартам СОС или спецификациям
(некоторые или все заявки могли быть проверены в ранее проведенных испытаниях);
— тестирование
комплекса заявок о соответствии технической реализации базовым стандартам СОС
или спецификациям. В этом случае могут потребоваться для многих взаимодействий
контрольные примеры (включая сосуществование, распределение ресурсов и
совмещение событий), что может привести к невыполнимому объему необходимых
тестов.
Тестирование на соответствие технической реализации
требованиям базовых стандартов СОС не гарантирует возможностей взаимодействия
всех компонентов и средств информационных систем. В процессе тестирования
определяется соответствие технической реализации набору тестовых утверждений,
содержащихся в базовом стандарте СОС. Один из способов определения соответствия
может заключаться в разработке эталонной реализации конкретного стандарта или
стандартизованного профиля, как показано на рисунке 19.
Рисунок
19 — Определение соответствия технической
реализации на основе эталонной реализации стандарта
Объект тестирования (тестируемый блок — ТБ) проходит
испытания с использованием сценариев тестирования. Поведение ТБ отслеживают и
сравнивают с ожидаемым результатом эталонной реализации. Преимущество
настоящего способа состоит в том, что при этом могут быть испытаны изделия
разных поставщиков. Если эталонную реализацию разработать невозможно,
допускается использовать другие методы аттестационного тестирования, такие как
тестирование элемента программного средства, квалификационное тестирование
программного средства и совместное тестирование технических и программных
средств.
8.2 Вопросы реализации
После разработки профиля СОС организации-пользователя
необходимо документировать соглашения по реализации, связанные с каждым
стандартом и (или) спецификацией, входящими в профиль СОС.
В качестве примера может быть приведен язык SQL, применение которого предусматривает наличие
аттестационных тестов четырех уровней в зависимости от набора используемых вызовов.
При использовании различных СУРБД не обязательно, чтобы все они поддерживали
тот же набор вызовов. Следует отметить, что большинство продуктов содержит
специфические характеристики и расширения, выходящие за пределы базового уровня
соответствия стандартам. Следует избегать использования таких специфических
характеристик и расширений, если необходимо обеспечить взаимодействие
компонентов и средств информационных систем. Если нельзя избежать применения
специфических характеристик, их использование документируют в каждом конкретном
приложении. Кроме того пользователи должны учитывать демаскирование («masking-off»)
нестандартных кодов, что позволяет локализовать нестандартные функции
использованием интерфейса.
8.3 Планирование внедрения
После того как организация-пользователь разработала
профиль СОС, важно составить план по его внедрению. Руководителям высшего
уровня следует установить приоритеты при реализации отдельных частей профиля.
Если исполнители будут ориентированы на внедрение профиля СОС организации-пользователя
без выделения приоритетов и точных сроков внедрения различных частей профиля,
маловероятно, что требования переносимости и взаимодействия, которые должны
реализоваться в приоритетном порядке, будут внедрены.
Внедрение профиля в соответствии с целями
организации-пользователя упростится, если в профиле будут четко документированы
ключевые цели обеспечения взаимодействия. План внедрения может содержаться в
приложении к профилю СОС организации-пользователя или в отдельном документе.
План внедрения профиля должен быть действующим документом и постоянно
актуализироваться по мере изменения целей управления в организации.
8.4 Использование общедоступных
технических требований
Общедоступные технические требования (ОТТ)
представляют собой спецификации (например промышленные профили, стандарты
«де-факто») и могут быть использованы при разработке профилей СОС. Примерами
таких ОТТ могут служить ЗНК или стандарты, разработанные в IETF СТК 1 различает два способа включения ОТТ в
международные стандартизованные профили. Первый способ состоит в использовании
прямых ссылок на ОТТ, второй — в принятии стандарта, разработанного на основе
ОТТ.
9 Преимущества профилей СОС
организации-пользователя
Преимущества от внедрения профилей СОС
организации-пользователя заключаются в том, что они позволяют решить следующие
основные проблемы:
— внедрение
открытых систем, обеспечивающее взаимную увязку требований пользователей,
выраженных на их языке, и технических решений, отвечающих требованиям
пользователя;
— внедрение
технологии открытых систем, позволяющей развивать требования производственной
деятельности, организовывать обеспечение их реализации, то есть обеспечивать
соответствие технологий заданным производственным требованиям.
Организация-пользователь определяет свои потребности в
требованиях к производственной деятельности, в то время как поставщики
технологических решений описывают эти решения в требованиях, определяющих их
техническую реализацию. И поставщики, и организации-пользователи затрачивают
значительные ресурсы для соотнесения требований производственной деятельности и
технологических решений, в особенности, когда задачи производственной
деятельности требуют поставок технологических решений из различных источников
(и, следовательно, интегрированных решений) для обеспечения интегрированного
производственного (делового) процесса.
Обобщения схема разработки профиля СОС
организации-пользователя приведена на рисунке 20.
Преимущества от внедрения профилей СОС организации-пользователя
обеспечивают:
— лучшее
взаимопонимание: образуется прямая связь между требованиями к деловой
деятельности (ТБС) и техническим решением (наполненными моделью служб ИТ и
технологических компонентов). Управляющий персонал и специалисты в области
информационных технологий подходят однозначно к описанию одних и тех же
требований к деловой деятельности, применяя профиль СОС, разработанный методом
«сверху вниз», исходя из требований основной деятельности;
— облегчение
комплектования: профили СОС организации-пользователя облегчают пользователям
задачу формулирования технических требований, понятных их потенциальным
поставщикам. Тем самым сокращается время процесса взаимной увязки технических
требований и решений и снижается общая стоимость работ;
— облегчение
общего процесса интеграции: поскольку профили СОС организации-пользователя
разрабатывают методом «сверху вниз», исходя из требований основной
деятельности, возникает единое интегрированное решение технической
функциональной совместимости и производственных процессов как естественное
следствие полного наполнения моделей служб ИТ и технологических компонентов
перед переходом к следующему этапу;
Рисунок
20 — Обобщенная схема разработки
профиля СОС организации-пользователя
— уровень
служб, согласованный с задачами основной деятельности: при наличии профилей СОС
организации-пользователя технологические компоненты специфицируют не только в
требованиях поддержки производственной деятельности, но и в требованиях,
определяющих технологии, обеспечивающие эту производственную деятельность.
Таким образом, соответствие техническим требованиям и тестирование
производственных характеристик могут быть установлены до начала комплектования;
— защиту
инвестиций: наполнение профиля СОС организации-пользователя стандартами и
техническими профилями обеспечивает требования по переносимости и
масштабируемости информационных систем;
— обратную связь с процессом разработки
стандартов: идентифицируя на ранней стадии отсутствующие стандарты и профили, пользователи,
разработчики стандартов и поставщики ИТ получают механизм для наиболее
экономичного подхода к исследованию и разработке новых стандартов и профилей,
ускоряющего процесс маркетинга;
— обратную
связь с процессом разработки продукции: разрабатывая профиль методом «сверху
вниз», исходя из производственных требований, пользователи могут оказывать
влияние на разработку поставщиками новых продуктов ИТ, непосредственно
отслеживать требования пользователей.
ПРИЛОЖЕНИЕ А
(справочное)
Библиография
[1] IEEE Std 1003.23-98 Стандарт
института инженеров по электротехнике и электронике. Руководство по
проектированию профилей среды открытой системы организации-пользователя
[2] CAP Gemini Sogeti, Architecture Development Method, April 7, 1995
Ключевые слова: обработка данных, обмен информацией, взаимосвязь
сетей, взаимосвязь открытых систем, профили ВОС, организация-пользователь,
требования
Видели этот мем, где игрушечный осьминог с надписью «2022» весело «душит» серого котика, а тот с вежливым видом и ужасом в глазах спрашивает: «Извините, какое у нас стоп-слово?»
Смешно только в первую секунду, а потом многие из нас вспоминают то липкое чувство, когда тебе нужно срочно остановить то, что происходит с тобой (или вокруг, или с твоими близкими), а никакого стоп-слова тут не предусмотрено. Это жуткое ощущение, что ты полностью потерял контроль и тебе явно не нравится то, куда тебя несут обстоятельства.
Так вот! Чтобы прямо здесь и сейчас не лишиться рассудка, нужно вернуть себе эту почву под ногами. Нужно вспомнить, что в море всего того, что мы изменить не можем, есть кое-что, что нам подвластно – всегда. Даже если денег нет, даже если гречки в доме осталось всего на полтора месяца, а дальше непонятно как жить.
Что остается в нашей власти, даже когда нас душит этот чертов плюшевый осьминог?
Поза. Звучит смешно, но до тех пор, пока мы не прикованы к постели наручниками или параличом, мы вправе поменять свое положение в пространстве. Сесть удобнее, вдруг встать и пройтись, вытянуть руки, согнуть ноги, лечь на пол – все это простые действия с поистине магическим эффектом. Вы напоминаете своему телу, что вы еще здесь, и пока только вы решаете, как двигаться.
Правила. Попробуйте осознанно похулиганить: взять и нарушить какое-нибудь правило. Вдруг позвольте себе десерт в середине рабочего дня. Выпейте свой кофе не за столом, а сидя на диване. Во время обеденного перерыва на работе сходите прогуляться без всякого повода. Разрешите детям один раз не ложиться спать в одиннадцать, а вместо этого заварите чай и устройте картежный вечер. Купите в магазине не гречку (или не только гречку), но и кусочек хорошего сыра.
Внешность. Моя прабабушка Ольга Михайловна дожила почти до ста лет. Много лет подряд она перед сном накручивала себе букли, а утром снимала их и любовалась на себя, кудрявую, в зеркало. Это был незыблемый ритуал – неважно, что у нас на завтрак, что происходит в мире, какая погода за окном – но ее кудряшки были в ее власти. Она дарила себе отражение в зеркале, которое ее радовало. Мы тоже так можем: главное – найти то главное в себе, что приносит максимум удовольствия.
Игра. В детстве мы проживали все, что для нас ново, сложно или страшно, в игре. Разыгрывали сцены с машинками и куклами, спасались от потопа на утлой лодке из диванных подушек, загадывали: если сейчас выиграю в домино, значит, завтра меня на математике не спросят… Если в реальности тяжело, верните себе игру. Представьте себя героем фильма или книги, назовите ежедневные дела миссиями, приклеивайте себе звездочки на футболку за каждое маленькое дело, которое выполняете. Любая геймификация, приносящая положительные эмоции, вам поможет.
Передвижения. Истинная тюрьма у нас внутри: снаружи не так много заборов и преград, зато есть много дорог, и все они куда-то ведут. Найдите полтора часа времени, выходите из дома и направляйтесь туда, куда хочется. Просто в соседний район, к вашей старой школе, туда, где вам обычно хорошо и приятно. Эти места в шаговой доступности – тоже ваш ресурс, которым вы можете управлять. Просто прийти и быть здесь.
Тема для размышлений. Сложно не думать о страшном. Даже самые невинные вещи напоминают о том, что сейчас болит и притягивает внимание. И все равно, мы в силах впустить в свой повседневный контекст совершенно отвлеченные темы: дизайн одежды во времена Бонапарта, история создания шоколада, нюансы приготовления ферментированного кофе или влияние определенных запахов на гормональный фон – найдите пару минут в день, чтобы подумать о любой невинной ерунде, которая вас забавляет и радует. Вы вправе не только страдать и волноваться, но и испытывать интерес к чему угодно.
Сегодня модные гаджеты не только подчёркивают стиль их владельцев, но и делают жизнь людей безопаснее.
С помощью мобильных устройств можно вызвать спасательные службы в любую точку страны и сообщить им о месте нахождения пострадавшего.
Всё это возможно благодаря кнопке SOS, которая всё чаще появляется в новых гаджетах.
Эта новинка предназначена для того, чтобы владелец гаджета мог просто и оперативно подать сигнал тревоги в любой экстремальной ситуации, когда ему или другому человеку требуется помощь.
Сегодня такую кнопку можно увидеть во многих мобильных устройствах: телефонах, GPS-трекерах, браслетах, часах и кулонах, которые мы всегда носим с собой.
При этом они выглядят современно и модно. Перед обзором данных устройств давайте же разберёмся с принципом работы кнопки SOS.
Благодаря кнопке SOS абоненту даже не потребуется дозваниваться по номеру «112» и объяснять оператору причину вызова. Это может спасти человеку жизнь, когда у него нет связи или он физически не может дозвониться по необходимому номеру.
В экстренной ситуации, используя gps трекер с кнопкой SOS, достаточно нажать на тревожную кнопку и удерживать её несколько секунд, после чего сигнал сразу же поступит диспетчеру экстренной службы и нескольким родственникам и близким, чьи контакты были внесены в гаджет.
Вместе с сигналом тревоги на телефонные номера, забитые в память трекера, с помощью спутниковых сигналов передаются координаты, где находится пострадавший. Это способствует оперативному реагированию служб и оказанию своевременной помощи.
По такому же принципу работают мобильные телефоны, часы, браслеты и кулоны, оборудованные кнопкой SOS.
В некоторых гаджетах при нажатии тревожной кнопки включается громкая сирена. Это позволяет привлечь внимание людей, которые могут находиться рядом и оказать первую медицинскую помощь до прибытия спасательных служб.
Обзор гаджетов с кнопкой COC
В магазинах представлено изобилие различных устройств, оборудованных тревожной кнопкой, рассмотрим наиболее оптимальные варианты:
- Мобильный телефон с кнопкой COC Just 5
Пользуется огромной популярностью у людей пожилого возраста с плохим зрением. Благодаря своей прочности и простоте подходит также детям или любителями экстремальных видов спорта. Телефон оборудован большими кнопками и дисплеем с крупным шрифтом. Совместим со слуховыми аппаратами и работает с СИМ-картами всех операторов GSM.
На тыльной стороне телефона находится оранжевая кнопка SOS для отправки сигнала в экстренную службу и по нескольким заданным пользователем номерам в случае экстренной ситуации.
Ещё при нажатии кнопки включается громкая сирена, привлекающая внимание находящихся рядом людей.
Кнопка работает даже тогда, когда телефон отключён, хотя здесь установлена батарея-долгожитель мощностью 1000 мАч.
- Стильные детские часы с кнопкой SOS K911
Устройство представляет собой мобильный телефон в виде детских часов. Если ребёнку грозит опасность, то при нажатии кнопки SOS в течение нескольких секунд он может связаться с родителями или круглосуточным диспетчерским центром, который окажет неотложную помощь.
Благодаря встроенному GPS-модулю родители могут отслеживать местоположение ребёнка в онлайн-режиме и получать уведомления при прибытии в указанное место, отклонении с маршрута или снятии часов с руки.
Наличие микрофона позволяет слушать всё происходящее возле ребёнка. Батареи хватает на неделю работы в режиме трекера и на 6 часов беспрерывного разговора.
- Браслет Астра-Р РПД
Это радиопередающее устройство в виде стильного браслета. Кнопка SOS позволит лицам, попавшим в чрезвычайное происшествие, и людям с ограниченными возможностями общения и передвижения быстро отправить экстренное сообщение.
При включении кнопки тревожный сигнал передаётся на модуль GSM сигнализации, посредством которой по мобильной связи идёт оповещение экстренной службы и родственников.
Чтобы предотвратить ложное срабатывание, на протяжении 5 минут можно отключить оповещение.
- GPS-кулон T-01
Универсальный гаджет, предназначенный для вызова экстренной помощи и отслеживания местоположения его владельца при помощи геолокации. Оборудован датчиком падения, который при первых признаках падения автоматически передаёт тревожный сигнал на указанные в гаджете номера. В рабочем режиме способен работать без подзарядки около 5 дней.
Такие технологические новинки, как кнопка SOS позволяют людям использовать гаджеты не только для того, чтобы делать фотографии для социальных сетей или соревноваться с друзьями, чьё устройство более стильное, дорогое, мощное и новое.
Сегодня благодаря гаджетам мы можем спасти свою или чужую жизнь в опасной ситуации, когда судьба человека может решиться в считанные секунды.