Обновлено: 14.01.2025

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

Все эти стандарты появились в конце 80-х - начале 90-х годов (год выпуска обозначен числом после дефиса), заменив или дополнив более ранние стандарты 19-й и 24-й серий.

Чтобы понять и оценить логику, содержащуюся в семействе ГОСТ 34, проанализируем содержание составляющих его стандартов более подробно. Ориентированные на ИТ-специалистов ГОСТ 34.320-96 "Концепции и терминология для концептуальной схемы и информационной базы", ГОСТ 34.321-96. "Эталонная модель управления данными", ГОСТ 34.10 -01 "Криптографическая защита информации . Процессы формирования и проверки электронной цифровой подписи" и ГОСТ 34.11-94 "Криптографическая защита информации . Функция хэширования" я рассматривать не буду, поскольку они рассчитаны не на управленцев, а на технических специалистов. Для нас интерес представляют следующие стандарты:

ГОСТ 34.003-90, помимо того что содержит многочисленные ошибки, полностью устарел и потерял актуальность, поэтому о нем я говорить не буду. Таким образом, далее рассматривается четыре последних документа.

Стандарт ГОСТ 34.201-89

Серьезно устаревший, но отчасти пригодный для использования стандарт (ГОСТ 34, 1989а). Устанавливает соответствие документов стадиям создания АС 1 АС - автоматизированная система, т. е. информационная система, разрабатываемая или внедряемая на конкретном предприятии. , описанным в ГОСТ 24.601 (впоследствии заменен на ГОСТ 34.601). По составу документов и стадиям проекта можно проследить происхождение стандарта из практики строительства. Очевидно, проектная природа строительства и деятельности по созданию информационной системы навела авторов стандарта на мысль распространить основные формы организации строительных проектов на проекты создания информационных систем. Отчасти это оказалось удобно - такие документы, упомянутые в стандарте, как " Техническое задание ", " Эскизный проект ", " Технический проект ", " Инструкция " (пользователя), " Программа и методика испытаний" прочно вошли в практику создания систем. С другой стороны, "Ведомость машинных носителей информации", "Каталог базы данных " или "Ведомость держателей подлинников" вряд ли сейчас имеют смысл. Стандарт включает также элементы практики делопроизводства в виде правил кодирования документов.

Короче говоря, при "творческом" подходе он может еще послужить, особенно в тех организациях, где проектная деятельность регулируется аналогичными проектно-ориентированными стандартами, а состав проектных документов близок к тому, что предлагает ГОСТ 34.201-89.

Стандарт ГОСТ 34.601-90

Один из наиболее применяемых до сих пор стандартов (ГОСТ 34, 1990), определяющий стадии и этапы создания автоматизированной системы. Приведенная ниже таблица является центральной в стандарте.

Практически все перечисленные стадии и этапы до сих пор встречаются в практике создания информационных систем предприятий и организаций. Конечно, можно критиковать стандарт за негибкость в части последовательности и названий стадий и этапов, но факт остается фактом - он продемонстрировал исключительную живучесть, и понять, в чем причина этого, гораздо важнее, чем заниматься критикой разработки почти 20-летней давности. Мне кажется, что стандарт демонстрирует точное соответствие своим целям. Во-первых, он не требует знаний в области ИТ и, следовательно, понятен обычным управленцам. Во-вторых, он компактен и прост по структуре, что позволяет человеку, не знакомому с ним, быстро войти в курс дела. В-третьих, он самодостаточен - практически никаких ссылок на смежные документы в нем нет (за исключением ГОСТ 34.201). И наконец, он практичен - сразу понятно, как его применять и как контролировать его применение.

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

Стандарт ГОСТ 34.602-89

Требование "подготовить Техническое задание в соответствии с ГОСТ 34.602-89", знакомо, наверное, каждому, кто хоть однажды участвовал в заказной разработке ИС или ее приемке, да и вообще всем, кто так или иначе связан с информационными системами. Некоторые разработчики до сих пор считают хорошим тоном помнить наизусть состав Технического задания (ТЗ) в соответствии с ГОСТ 34.602-89 (ГОСТ 34, 1989б).

1. Общие сведения.
2. Назначение и цели создания (развития) системы.
3. Характеристика объектов автоматизации.
4. Требования к системе.
5. Состав и содержание работ по созданию системы.
6. Порядок контроля и приемки системы.
7. Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие.
8. Требования к документированию.
9. Источники разработки.

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

"2.6.2. В подразделе "Требования к функциям (задачам)", выполняемым системой, приводят:

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

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

Приведенный отрывок демонстрирует иерархичность стандарта: система состоит из подсистем, комплексов задач, отдельных задач, функций. Чем точнее и подробнее сформулированы требования, тем более предсказуемым будет результат. Специально формулируются требования к функциям взаимодействия подсистем (сейчас мы бы сказали "к методам интеграции"), функции привязываются к плану-графику реализации системы (который тем самым также становится иерархическим). Специально упомянуты требования к качеству. Форма представления выходной информации , т.е. совокупность отчетов, также заслужила отдельного упоминания. Одним словом, представленный отрывок показывает, что разработка Технического задания в соответствии с ГОСТ 34.602-89 - непростая и очень трудоемкая работа, накладывающая серьезные обязательства не только на разработчика, но и на заказчика системы. Потенциал стандарта чрезвычайно велик, и неудивительно, что популярность его остается неизменно высокой на протяжении стольких лет.

С течением времени стали видны и оборотные стороны стандарта:

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

Стоит подчеркнуть, что, как и ГОСТ 34.601-90, ГОСТ 34.602-89 не требует специальной подготовки в области информационных технологий, поэтому контролировать соответствие ему Технического задания может обычный управленец, в задачу которого входит, например, взаимодействие с субподрядчиками. Это упрощает внедрение и практическое применение стандарта.

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

Открытые стандарты и открытые форматы электронных документов

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

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

Критерии открытости стандарта

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

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

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

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

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

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

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

ISO/IEC 26300:2006 Information technology – Open Document Format for Office Applications. ИСО/МЭК 26300:2006 (ODF ISO/IES 26300:2006). Информационные технологии – формат Open Document для офисных приложений (Open Document) 1.0. Официальный перевод.

ISO/IEC DIS 29500:2008 Information technology – Office Open XML file formats.

Открытый формат – это формат электронного документа, позволяющий переносить (обмениваться) этот документ с одной программной платформы на другую без искажения его формы, структуры, содержания и работы с ним далее.

Первый описывает открытый формат Open Document Format (ODF) – сокращенное от OASIS Open Document Format for Office Application – для офисных приложений. Международный стандарт представления электронных документов ISO/IEC 26300:2006, полностью соответствующий всем критериям открытости, в 2007 г. был принят и как стандарт ANSI.

Второй Office Open XML (Open XML) – серия форматов файлов для хранения электронных документов пакетов офисных приложений – в частности, Microsoft Office. Международный стандарт ISO/EIC DIS 29500 принят в 2008 г.
Оба формата представляют собой zip-архив , содержащий текст в виде XML, графику и другие данные .
Чтобы стандарт представлял реальную ценность, он должен быть принят и внедрен. Это означает, что производители программного и аппаратного обеспечения будут использовать стандарт в процессе разработки своих продуктов. Организации конечных потребителей тоже играют определенную роль в принятии стандарта. Проще говоря, при постановке технических заданий и требований к разрабатываемой продукции, организация должна учитывать существующие стандарты и стремиться им соответствовать.

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

«Группы, разрабатывающие стандарты Open Document Format и Office Open XML, должны работать вместе, параллельно развивая обе спецификации. Сторонники обоих форматов добьются большего успеха, если будут вместе развивать свои спецификации» .

Microsoft финансирует свободный проект плагина для Microsoft Office ODF Converter для пакетного преобразования документов . Кроме того, расширения, обеспечивающие совместимость с ODF, будут выпущены и для некоторых более ранних версий офисного пакета Microsoft . Недавно Microsoft выступила в поддержку конкурирующего формата ODF, проголосовав за его включение в список американских национальных стандартов. В перспективе в данный список будет включен и OPEN XML .

В мае 2008 г. корпорация Microsoft опубликовала пресс-релиз о поддержке новых форматов в Microsoft Office 2007 Service Pack 2 (выход этого пакета обновлений ожидается в первой половине 2009 г.) . В Office 2007 SP2 появится поддержка: PDF, PDF/A, XPS (формата электронных документов Microsoft XPS, конкурирующего с PDF) и ODF (причем не просто появится поддержка, а еще и будет возможность назначить ODF форматом по умолчанию) . Microsoft поддерживает создание дополнений к программам для MS Office, чтобы позволить использовать ODF. В частности, Microsoft создал транслятор Open XML – проект «моста» между Open XML и ODF .
При сопоставлении форматов ODF и Open XML полезно обратить внимание на тенденции использования обоих форматов независимыми разработчиками программного обеспечения. При проведении сравнительного анализа выявлено, что качественно принципиальных различий между этими двумя форматами нет . Есть различия, имеющие технический характер. Очевиден процесс сближения этих стандартов и форматов, диктуемый пользователями (рынком). Подтверждением тому является внесение изменений Microsoft в Open XML и разработка консорциумом W3C нового открытого стандарта Compound Document Format (CDF). Он имеет более высокие шансы на успех в качестве универсального формата по сравнению с ODF. Одной из отличительных особенностей CDF является совместимость с унаследованными форматами Microsoft, в том числе и с форматом Open XML. Кроме того, CDF ориентирован на интеграцию настольных компьютеров, серверов и портативных устройств, переносимость данных с одной платформы на другую и независимость от решений конкретных поставщиков.

Теперь оба формата стандартизированы на международном уровне, и для них откроются двери в государственные учреждения многих стран мира, которым разрешается использование только признанных ISO форматов документооборота. А пользователи разных платформ и взглядов, как и ранее, будут иметь неотъемлемое право выбирать, какое ПО устанавливать на свои компьютеры: запатентованное или с открытым кодом .

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

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

В этой связи, сторонние наблюдатели высказывают надежду, что теперь так называемая «война форматов» потеряла актуальность, что можно только приветствовать, и очевидная тенденция сближения и взаимопроникновения этих форматов тому подтверждение.
«Открытые форматы являются хорошим инструментом для решения следующих задач:
– обеспечение взаимодействия информационных систем;
– коллективная работа над проектами документов;
– представление законченного документа в другие государственные органы, физическим и юридическим лицам;
– прием электронных документов государ­ственными органами от физических и юридических лиц;
– долговременное хранение электронных документов.
ODF и Open XML будут использоваться достаточно широко. Их придется поддерживать всем серьезным производителям ПО, ведь открытые форматы рассматриваются как важная компонента программ электронного правительства» .
Именно это обстоятельство и привлекает внимание правительства РФ (равно как и других стран) к открытым форматам и объясняет их стремление внедрить ПО с открытым исходным кодом в государственные органы власти и управления.

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

Депутаты Национальной ассамблеи Франции требуют принятия закона, который обязует правительственные ведомства использовать ODF при создании и распространении документов, и рекомендуют странам Европы, которые имеют партнерские отношения с Францией, применять данный формат при обмене документами на европейском уровне .
«Открытый формат ODF стал государственным стандартом электронных документов в ЮАР. Отныне он будет использоваться для всех коммуникаций правительственного уровня. ODF избран в качестве типового формата офисной документации в минимальных стандартах совместимости информационных систем в правительстве» .

Так же формат ODF утвержден в качестве национального стандарта организацией по стандартизации Хорватии (Hrvatski zavod za norme, HZN). Организация по стандартизации Южно-Африканской Республики (South African Bureau of Standards, SABS) утвердила открытый формат ODF в качестве национального стандарта, а еще ранее формат ODF был утвержден в качестве стандарта правительственной связи. В 2009 году стандарт должен стать основным форматом для внутреннего документооборота в правительственных учреждениях ЮАР. Утверждение открытого формата ODF в качестве национального стандарта расширяет возможности его внедрения в коммерческом и государственном секторах стран и не носит обязательный характер» .

Следуя примеру властей штата Массачусетс (США), принявших открытый формат документов ODF в качестве стандарта для собственного документооборота , и властей штатов Техас и Миннесота, рассматривающих аналогичный законопроект, власти штата Калифорния также приступили к обсуждению возможности замены проприетарных форматов документов на свободные. При этом подразумевается, что закон будет иметь не рекомендательный, а обязательный характер, в связи с чем, закрытые форматы будут запрещены. Однако сенаторы штата Массачусетс проголосовали за использование одновременно двух форматов документов – и ODF, и Open XML. Изначально законопроект подразумевал только один вариант – открытый международный стандарт ODF, но в последний момент сенаторы решили, что без программной продукции Microsoft не обойтись, поэтому и добавили в финальный документ еще один формат .

На тот факт, что представителей американского правительства интересуют оба открытых формата, указывает проведение в американском городе Портленд, штат Орегон, традиционной ежегодной конференции Government Open Source Conference (GOSCON) , в рамках которой также обсуждается положение дел с продвижением форматов документов ODF и Open XML .

В качестве участников дискуссии выступают представители таких компаний и организаций, как Microsoft, Sun, IBM и OpenDocument Foundation . Основной причиной повышенного интереса представителей правительства к проблемам открытых стандартов стал результат голосования в Международном комитете по стандартизации (ISO) по вопросу выдвижения формата Open XML в качестве еще одного международного стандарта форматов документов. Чиновники проявляют озабоченность неопределенностью ситуации. «По традиции конференция GOSCON является местом, где представители властей и бизнесмены получают точные рекомендации по дальнейшему развитию отрасли и возвращаются домой уже с готовыми решениями, поэтому многие участники конференции надеются, что разработчики обоих форматов документов смогут прийти к определенному согласию в вопросах, касающихся международных стандартов. Проблемам взаимодействия форматов была посвящена отдельная секция конференции-Open Standards and Interoperability”, в рамках которой обсуждались такие вопросы, как использование единых стандартов документов, их пригодность к работе в различных программах и возможность долговременного хранения важных данных с сохранением возможности их обработки в будущем. Опыт последних лет показывает, что частая смена закрытых форматов документов приводит к невозможности получения доступа к важным данным, поэтому особое значение должно уделяться открытым форматам, гарантирующим способность в будущем без лишних проблем обрабатывать данные, сохраняемые в цифровом виде долгие годы» .

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

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

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

Более подробно перечисленные форматы рассмотрены во 2 главе данной работы.

Сайер П. Мир лучше войны [Электронный ресурс] //

Novell, Inc. – американская ИТ-корпорация, специализирующаяся на сетевых сервисах, управлении сетями и Linux.

Сравнение ODF/Open XML конвертеров [Электронный ресурс] /

Шурупов Д. Sun выпустит транслятор ODF для Microsoft Office [Электронный ресурс]

Парамонов В. В Office 2007 будет поддержка OpenDocument [Электронный ресурс]

Парамонов В. Microsoft выступила в поддержку формата ODF [Электронный ресурс]

Форматы Open XML и ODF: сравнительный анализ [Электронный ресурс]

Александрович Г.Я. Стандартизация офисных электронных документов. История вопроса [Электронный ресурс]

Спецификация Microsoft Open XML не прошла утверждения в ИСО [Электронный ресурс]

Ларин М.В. Электронные документы в управлении: науч.-метод. пособие. М.: ВНИИДАД, 2008. С. 138.

Формат ODF утвержден в качестве национального стандарта Хорватии, Бразилии и ЮАР [Электронный ресурс] //

Парамонов В. Формат OpenDocument стал международным стандартом [Электронный ресурс] //

Группа Open Document Foundation, создана в 2002 г. с целью продвижения универсального, открытого файлового формата документов Open Document Format (ODF).

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

Существует тьма статей на тему «как писать документацию», но если вы решили взяться за неё в первый раз, то в новой для вас области не сразу понятно, дело ли пишет автор, или отсебятину выдумывает.

Для того чтобы сформировать своё мнение без перелопачивания статей, можно пойти двумя путями: довериться некому авторитету или посмотреть в стандарты – уж там-то с наибольшей вероятностью проблему обдумали со всех сторон.

Кто-то может сказать «а-а, стандарты! они ещё более адово скучные, чем сама документация!». Ну, не будем врать, есть немного :) Но если у вас документ в электронном формате – найти необходимое не составляет труда. И кроме того, ну надо же размочить раздел стандарты уже, а то висит пустой, даже обидно.

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

ГОСТ 34.602-89 «Техническое задание на создание автоматизированной системы» — стандарт на ТЗ. Спасибо Jazzist.

Буржуйские.

Не было предела моему возмущению, когда я узнала, что международные стандарты не бесплатные. Это как правила дорожного движения сделать платными. Но в принципе, может и резонно: организации-то не государственные. Хотят – могут и деньги брать за свою работу. К счастью, многие стандарты можно скачать по-привычному, по-пиратски.

IEEE Std 1063-2001 «IEEE Standard for Software User Documentation» — в документе обозначены требования к структуре, содержимому и формату инструкций пользователя.
Официальная страница.

IEEE Std 1016-1998 «IEEE Recommended Practice for Software Design Descriptions» — рекомендации к документам, описывающим архитектуру программного обеспечения, то бишь к техническому описанию.
Официальная страница.
Особливо понравилась табличка-экстракт основного содержания документа (здесь вольный перевод):

Тип обзора	Содержание	Атрибуты	Примеры представления
Декомпозиция	Разбиение системы на структурные составляющие	Определение, тип, назначение, функции, зависимые сущности	Иерархическая диаграмма декомпозиции, словесное описание.
Описание зависимостей	Описание связей между сущностями и системными ресурсами.	Определение, тип, назначение, зависимости, ресурсы.	Структурные схемы, диаграммы потоков данных, схемы транзакций.
Описание интерфейса	Список всего, что может потребоваться знать проектировщику, программисту или тестеру для того чтобы использовать структурные составляющие системы.	Определение, функции, интерфейсы.	Файлы интерфейса, таблицы параметров.
Описание деталей	Описание внутреннего устройства частей сущности.	Определение, обработка данных, данные.	Блок-схемы, N-S диаграммы, PDL

ISO/IEC FDIS 18019:2004 «Guidelines for the design and preparation of user documentation for application software» — рекомендации по созданию документации пользователя. Так сказать, советы «хозяйке на заметку». Довольно приятное руководство с большим количеством примеров (имхо, больше подходит для чтения до или в самом начале создания документации, так как подходит к процессу основательно, от самого планирования). Также в приложениях есть чеклисты «что не забыть сделать в процессе разработки документации» и «что должно быть в документе»
Официальная страница.

ISO/IEC 26514:2008 «Requirements for designers and developers of user documentation» — довольно свежий и, судя по содержанию, полезный документ. Но, как раз, видимо, ввиду его свежести, этот стандарт нигде не найти бесплатно. По крайней мере, мне этого сделать не удалось.
Официальная страница.

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

Уточнения, дополнения и полезные ссылки приветствуются)

UPD: очень познавательный комментарий, спасибо lkochetova

UPD1: совесть меня таки замучила, и в статье больше не будет висеть прямых ссылок на скачивание стандартов, не распространяемых свободно. Если они вам понадобятся — нагуглить не составит труда.

UPD2: также смотрите статью Документирование по ГОСТ 34* — это просто с подробным разбором отечественных стандартов на проектную документацию.

@turbojedi Клаву хардварную была попытка сделать?

@001iz @Graveraider Всегда был вопрос а как у Evil персонажей могут быть романтики. Там скорее как в KoToR прогибание под свою сторону силы.

@Graveraider @001iz Q: Есть ли в игре романы? A: Да. Вы можете завести роман с 4 компаньонами, 2 из которых бисексуальны.

@001iz Заметки натуралиста, наплыв народу в комиксшопы вот произошел, после теории большого взрыва, где ненавязчиво подавалась идея что у задрота есть деньги, главное втереться к нему в доверие) Но только с хардкором тяжело.

Советуем посмотреть также Сайт Некроманта

Метки

Материалы распространяются на условиях лицензии GNU FDL

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

Ещё в детстве мне попалась детская книга по САПР и я понял что придя в университет не буду сидеть за кульманом…. ладно отвлекся

Figure 2: На случай если вы не вдохновились первой картинкой

Table of Contents

Зачем это нужно

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

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

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

<sarcasm>С одной стороны все просто давайте все себе поставят MS Office, Solidworks, Maya, AutoCAD и.т.д. и проблем в мире не будет. Но в силу природы людей, а также монополизма и тендеров мы пока не переходим.</sarcasm>

Figure 3: Наличие нейтрального хорошо описанного стандарта упрощает жизнь многих участников. Т.к. количество конвертеров сокращается в разы.

STEP — (англ. STandard for Exchange of Product model data — стандарт обмена данными модели изделия) — совокупность стандартов ISO 10303 используемая в для передачи данных об изделиях между различными приложениями не только САПР.

Вдвойне важно это для мира open source вы помните что позволили сделать хорошо описанные стандарты в области Интернет, а также работы Unix систем. А если возвращаться к примерам из настоящего то это стандартизация open document format , которая вынудила Microsoft вводить свой хоть и кривой но уже открытый формат Office Open XML

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

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

Отмечу что соблюдение стандартов важно для самого предприятия, если ввод стандарта помогает. Понятно что никто не требует Вас передавать данные внутри предприятия в STEP формате(STEP частичное переведен на русский).

Также отмечу КРУПНЫМИ буквами что в создание стандарта участвуют представители отрасли, а не непонятные чиновники из министерства… которые как обычно ничего не знают ни в чем не разбираются и лепят очередной закон. Так составляются стандарты там и там им стараются следовать, а не насаждают с упорством сверху.

История

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

Если собираетесь лезть в дебри 2 вот целый сайт Бауманского РК6,а там множество книг Норенкова. Забавно в студенческие годы я ещё на первом курсе купил все его книги по САПР, и не мог в них продвинуться, там вместо картинок и экшена про буквенные стандарты и настройку сети на предприятии говорилось. Ну вот спустя годы в быстром темпе перечитывал, так что перечитывайте непонятные моменты.

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

Прикладные протоколы AP- Специфические для отдельной предметной области модели данных, т.е. там на языке Express описаны модели данных в области например автомобильной промышленности AP214 или электронной AP210.

Есть ещё общие ресурсы, но о них позже.

Развитие линии стандартов STEP находит выражение в разработке новых стандартов Parts Library (ISO 13584), Parametrics (ISO 14959), Mandate (ISO 15531).

Разница подходов CALS и PLM

Изучение шло тяжело пока я на форуме электронных САПР не нашел замечательную монографию Шильникова П.С. 4 . Можете сразу её и начинать читать.

Прояснилась и разница в англоязычном PLM и CALS.

К интеграции данных существуют два подхода – CALS и PLM. Данные понятия часто путают, некоторые авторы даже наивно полагают, что это – одно и то же. В действительности же, несмотря на некоторое сходство,CALS и PLM – это два противоположных подхода к достижению одной цели.

Цель эта состоит в полном объединении всех задач, решаемых с помощью компьютера, на всех этапах Жизненного Цикла Изделия: маркетинг, подготовка производства (проектирование, конструкторская и технологическая подготовка производства), материально-техническое снабжение, производство, контроль, упаковка и хранение, распределение, эксплуатация и утилизация (см. стандарты серии ISO 9000).

Подход PLM, суть которого ясна из приведенного рисунка, состоит в том, чтобы обеспечить решение всех задач с помощью набора взаимоувязанных программных продуктов одного крупного разработчика программного обеспечения… И из этого же видна и основная возникающая при этом проблема. Проблема заключается в том, что пользователь привязывается к программным продуктам одного разработчика. Подход CALS, наоборот, состоит в том, чтобы освободить пользователя от зависимости от одного разработчика. Основа подхода – это SDE, или Единое Информационное Пространство, построенное на применении Международных стандартов представления данных. Основной стандарт – это ISO 10303 STEP (STandard for Exchange of Product model data – Стандарт обмена данными модели изделия). Статус Международного стандарта обеспечивает два очень важных свойства STEP – стабильность примерно в пять лет, и новые версии не изменяют и не отменяют, а дополняют старые) и общедоступность (необходимые для практической работы материалы по стандарту или находятся в свободном доступе в Интернете или могут быть куплены за несколько сотен долларов в официальных органах стандартизации, например, ВНИИКИ).

Денотант, треугольник Фреге и ограничения текстового STEP файла

Итак вот тут и лежит пропасть которая отделяет подход openPLM от того что уже было придумано. Нам необходимо описать наш объект.

Снова надергаем цитат из 4 .

Моделируемый объект – это то, что моделируется или описывается т.е. денотат (D).

Figure 4: Треугольник Фреге

Объединив три рассмотренных элемента (концепт, знак и денотат), получаем «Концепцию смысла» Готлоба Фреге.

И тут следует сделать замечание что STEP фай это знак, модели используемые в нем и описанные в прикладном стандарте на языке EXPRESS это концепт.

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

Прикладные протоколы

Некоторые из них:

В настоящее время наиболее широко используемыми Прикладными протоколами являются AP203 (Конструкция с управляемой конфигурацией) и AP214 (Ядро данных для автомобильной промышленности).

Протокол AP214 предоставляет достаточно широкие возможности по передаче рабочего проекта изделия, однако в CAD-системах коммерчески доступные препроцессоры и постпроцессоры STEP поддерживают только то подмножество AP214, которое совпадает с AP203.

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

Эти протоколы вы в основном и встречаете в сети когда конвертируете в вашем САПР. Как минимум в 203 описана передача твердых тел.

Протокол для систем CAE (АСНИ) «Анализ и конструкция композитных и металлических конструкций» АР209. Прочностные расчеты по МКЭ и композитные материалы – это предметная область, охватываемая Протоколом AP209.

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

• Разводка платы и конструкторское оформление,
• Модули,
• Блоки печатного монтажа (PWAs),
• Платы печатного монтажа (PWBs).

Фирмой STEP Tools, Inc. (США) ведутся работы по разработке протокола STEP NC (AP238), позволяющего представлять данные для оборудования с ЧПУ, в первую очередь – для обработки резанием, но в перспективе планируется расширение этих подходов и на другие виды технологических процессов. Цель внедрения AP238 – добиться независимости от постпроцессоров ЧПУ, обеспечить долгосрочное хранение данных для оборудования с ЧПУ и повысить надежность и гибкость данных

А как же полная модель объекта?

А как же передача полной информации об объекте? Снова приведем цитаты.

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

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

Такая же ситуация с программным хранением данных описанных EXPRESS

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

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

По степени обобщенности информационные ресурсы STEP делятся на несколько групп – интегрированные информационные ресурсы (самые обобщенные и встречающиеся практически во всех предметных областях – тома 40й серии), информационные ресурсы предметной области (тома 100й серии), прикладные интерпретированные конструкции, ориентированные на решение отдельных задач (тома 500 й серии) и прикладные модули (тома 1000 й серии). Рассмотрим некоторые из томов ISO 10303 STEP,содержащих интегрированные информационные ресурсы

Итого: Стандарты прикладных протоколов разрабатываются так чтобы пересекающиеся с другими областями элементы множества, были реализованы одинаково. Также создано описание неких общих базовых понятий, вроде ISO 10303-41 где содержатся сущности, необходимые для задания общего определения изделия.

Не все Прикладные протоколы были изначально модульными, но они к этому идут о чем можно узнать в этой презентации PDES.inc 5

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

Т.е. у нас есть яблоко-васи.stp это всего лишь частный экземпляр информационной модели Яблоко, которая описана на языке EXPRESS. Если мы напишем что то что будет понимать EXPRESS и хранить экземпляры данных в памяти компьютера то мы получим SDAI

Думаю что интерфейсу на питоне надо будет придумать другое название нежели PySDAI(stepcode есть наметки реализации)

MIM появился позже аж в 10303-1001 6 это набор сущностей который позволяет подцепится к объекту объектам и показать их представление. Т.е. у нас есть AP210 сточки зрения стандарта электронная схема это набор нод, с именами, которые соединены между собой. И формат не предусматривает привычный человеку чертеж схемотехники, да не один.

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

Осталось понять чем и как переносятся функциональные-spice модели, но это уже описано здесь 8

Parts Library (P-LIB)

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

Отдельно добавлю цитату отсюда 9

Parts Library (P-LIB) содержат обзор и основные принципы представления данных о стандартных компонентах промышленных изделий. В этих стандартах представлены в виде библиотек данные о семействах таких типовых широко используемых компонентов изделий, как болты, подшипники, электронные компоненты и т.п., с целью использования этих данных в системах автоматизированного проектирования. В P-LIB содержатся также правила использования, интерфейса и модификации библиотечных описаний. Цель стандарта — обеспечить инвариантный для приложений механизм оперирования частями библиотеки. Благодаря ISO 13584 различные прикладные САПР могут разделять данные из обобщенных баз, беспрепятственно обмениваться данными о типовых компонентах.

Стандарты P-LIB состоят из нескольких частей.

• 1 обзор и основные положения серии стандартов.
• 10-19 отведены для частей, содержащих концептуальные положения.
• 20-29 выделены для описания логических ресурсов. Здесь разработаны части: 20 — общие ресурсы; 24 — логическая модель поставляемой библиотеки (Logical model of supplier library); 26 — определение поставщиков (Supplier Identification).
• 30-39 используются для описания ресурсов внедрения. Здесь разработана часть 31 — интерфейс геометрического программирования (Geometric Programming Interface).

Видимо часть из этих стандартов применяется где-то у нас так как есть перевод ISO 13584-35:2010 10

Мы нашли панацею?

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

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

Выводы, наши цели и планы.

Из этого следует, что подход openPLM был плох тем что он от частных примеров шел к общим схемам которые уже существуют, и настоящие opensource PLM будет работать с EXPRESS моделями используя SDAI, а уж на чем будет реализован графический или веб-интерфейс, дело 10-е.

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

Общие требования к текстовым документам ГОСТ 2.105-95 и ГОСТ Р 2.105-2019 — это свод правил, призванный стандартизировать форму заполнения конструкторской документации. Они содержат нормы, которым должны подчиняться структура и состав текстов в сфере строительства, приборостроения и машиностроения.

Общие моменты

С 1 июля 2020 года вступит в силу приказ Федерального агентства по техническому регулированию и метрологии от 29.04.2019 № 175-ст, которым предусмотрено два нововведения:

• ГОСТ 2.105-95 утрачивает силу в качестве национального стандарта, но сохраняет действие в качестве межгосударственного;
• ГОСТ Р 2.105-2019 признают национальным.

Дополнительно в этой сфере приняты:

На практике при выполнении работы применяются те стандарты, которые выставляет заказчик, поскольку требования ЕСКД (единых систем конструкторской документации) и в целом ГОСТы в РФ считаются добровольными. Если документация оформляется для российского рынка, используйте правила оформления из национального свода. Если вы готовите бумаги для партнеров из ЕАЭС, стоит продолжать работу по ГОСТ 2.105-95. В ситуациях, когда документами пользуются компании и из России, и из других стран, укажите наименование стандарта, который использован при их подготовке.

Способы оформления

Разрешается заполнять документацию:

• машинописным способом в соответствии с ГОСТ 13.1.002-2003. Межгосударственный стандарт. Репрография. Микрография. Документы для микрофильмирования. Общие требования и нормы (введен в действие Постановлением Госстандарта России от 26.02.2004 № 63-ст);
• рукописным методом, используя положения ГОСТ 2.304-81. Межгосударственный стандарт. Единая система конструкторской документации. Шрифты чертежные (утв. Постановлением Госстандарта СССР от 28.03.1981 № 1562);
• применяя ЭВМ, согласно ГОСТ 2.004-88. Межгосударственный стандарт. Единая система конструкторской документации. Общие требования к выполнению конструкторских и технологических документов на печатающих и графических устройствах вывода ЭВМ (утв. Постановлением Госстандарта СССР от 28.11.1988 № 3843);
• на электронных носителях информации.

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

Техническое оформление: общие требования

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

Межгосударственный стандарт ГОСТ 2.105-95

Национальный стандарт ГОСТ Р 2.105-2019

Высота символов — не менее 2,5 мм

· шрифт Times New Roman или Arial размером 14 для основного текста и размером 12 для приложений, примечаний, сносок и примеров;

· допускается использование шрифта размером 13 и 11 для основного текста и размером 12 и 10 для приложений, примечаний, сносок и примеров соответственно.

Расстояние между боковыми линиями формы и текстом должно составлять минимум 3 мм

Абзац начинается с красной строки, минимальный отступ — 15 — 17 мм

Абзацы начинается с отступа, равного 12,5 — 17 мм

От нижней и верхней границ следует отступать не менее 10 мм

Интервал между строками — не менее 8 мм

· текст оформляют с использованием полуторного межстрочного интервала;

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

· расстояние между заголовком и текстом при выполнении документа машинописным способом равно 3, 4 интервалам, при выполнении рукописным способом — 15 мм;

· расстояние между заголовками раздела и подраздела — 2 интервала, при выполнении рукописным способом — 8 мм.

· расстояние между заголовком и текстом, между заголовками раздела и подраздела — не менее 4 высот шрифта, которым набран основной текст. Расстояние между строками заголовков подразделов и пунктов принимают таким же, как в тексте;

· при выполнении машинописным способом интервал равен 3 или 4 интервалам, при выполнении рукописным способом — не менее 15 мм.

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

Относительно копий в ГОСТ 2.105-95 заявлено, что их (здесь и далее приведены выдержки из текста):

выполняют одним из следующих способов:

• типографским — в соответствии с требованиями, предъявляемыми к изданиям, изготовляемым типографским способом;
• ксерокопированием — рекомендуется размножать способом двустороннего копирования;
• светокопированием;
• микрофильмированием;
• на электронных носителях данных.

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

• сканированием исходного бумажного документа;
• конвертированием или трансформированием ТДЭ из одного формата в другой или из одной схемы данных в другую;
• цифровым копированием.

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

• частей с присвоенным наименованием и обозначением. За исключением первой, каждой из них присваивается порядковый номер;
• книг, у которых тоже есть номера и наименования;
• разделов. Обязательно проставляется номер каждого, отделенный точкой от основного названия. Точка в конце названия не используется, перенос слов не допускается. Начало каждого раздела оформляется на новом листе;
• подразделов. Первая цифра обозначает принадлежность к конкретному разделу, вторая — порядковый номер конкретного подраздела.

Что касается нумерации, ЕСКД при оформлении документов позволяет сделать ее как сквозной, так и отдельной для каждого раздела.

Чего делать нельзя

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

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

Помимо этого, требования ЕСКД 2020 года запрещают:

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

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

Читайте также:

  
• Мегалюкс средство для очистки оргтехники и офисной мебели антистатическое
  
• Архитектура каких компьютеров основана на идеях параллелизма и конвейеризации вычислений
  
• Offline member raid как вернуть в онлайн
  
• Wolfenstein the new order не меняется разрешение экрана
  
• Где сделать компьютерную томографию в минске