В каком формате должен быть представлен базовый координационный файл
Формат размещения информации на сайте образовательной организации обозначен в Требованиях к структуре официального сайта <1> (далее - Требования). Эти Требования начали действовать с сентября 2014 г.
<1> Утверждены Приказом Рособрнадзора от 29.05.2014 N 785.
Требования разработаны Рособрнадзором в соответствии с п. 8 Правил размещения информации на сайте образовательной организации <2>. Требования также определяют структуру официального сайта образовательной организации <3>.
<2> Правила размещения на официальном сайте образовательной организации в информационно-телекоммуникационной сети Интернет и обновления информации об образовательной организации, утв. Постановлением Правительства РФ от 10.07.2013 N 582.
<3> О структуре такого сайта см. статью С.П. Фролова "Требования к сайту образовательной организации", N 10, 2014.
Обязательная информация может размещаться на официальном сайте в текстовой и (или) табличной формах, в форме копий документов.
Форматы документов
В Требованиях перечислены форматы файлов документов, которые должны быть представлены на сайте: Portable Document Files (расширение файла .pdf), Microsoft Word/Excel (.doc, .docx, .xls, .xlsx), Open Document Files (.odt, .ods) (п. 4).
Portable Document Files (Portable Document Format File) - это формат для электронных документов. С помощью PDF-файлов обычно распространяются инструкции, бланки заявлений, документация, чертежи. В формате PDF удобно создавать анкеты или опросники. Документ PDF может включать в себя текст, изображения, формы, мультимедиа-вставки и другую информацию. Одно из преимуществ использования формата - возможность защиты файла. Можно, например, разрешить просмотр документа определенной категории пользователей, но запретить его редактирование, копирование или распечатку.
Для создания и редактирования файлов PDF, как правило, используют программу Adobe Acrobat. Существует много бесплатных программ, позволяющих открывать PDF-документ на компьютерах с операционными системами Windows, MacOS, Linux, на мобильных платформах.
Формат DOCX - это формат электронного документа Microsoft Word 2007 и выше (2010 и 2011). В более ранних версиях MS Word данный формат не поддерживается. По сути, DOCX - это более совершенная версия старого доброго "дока" (расширение .doc). Преимущество нового формата в том, что он весит меньше, чем DOC, с ним современные приложения работают быстрее.
Файл с расширением .docx открывается программами Microsoft Office 2007 и выше (2010 и 2011) (пакет MS Office), Open Office org3 и выше. Более ранними версиями программы он не распознается. Формат включает в себя сжатие типа ZIP, за счет которого можно существенно уменьшить размер файлов. Формат создавался как замена формату документов XLS), который раньше использовали приложения Microsoft Office.
Файл с расширением .xlsx - удобен для вычислений, составления отчетов и других бухгалтерских или статистических операций (для вычислений используются формулы в особом виде). Данные хранятся в виде таблиц. Также в XLSX-файл могут быть включены диаграммы, графики, изображения, возможна группировка и сортировка данных.
Open Document Files (Open Document Format) - это открытый формат файлов для хранения и обмена редактируемыми офисными документами. Open Document Format считается альтернативой частным закрытым форматам (включая Word (.doc), Excel (.xls)), а также формату Microsoft Office Open XML. Документы Open Document Format могут включать в себя различные объекты: текст и его форматирование (расширение .odt), диаграммы, рисунки, электронные таблицы (.ods).
Обратите внимание, что форматы, указанные контролирующим органом, касаются только обязательных документов. Это не означает запрет на использование других форматов файлов - для размещения необязательной информации могут быть использованы видео-, аудиоматериалы, презентации и т.д.
Требования к файлам
Пункт 5 Требований содержит обязательные условия насчет файлов, размещаемых на сайте:
- максимальный размер файла не должен превышать 15 Мб (файлы большего веса трудно загружаются). Если размер файла превышает максимальное значение, то он должен быть разделен на несколько частей (файлов), размер которых соответствует данному Требованию;
- сканирование документа должно быть выполнено с разрешением не менее 75 dpi;
- отсканированный текст в электронной копии документа должен быть читаемым (то есть размер документа должен позволять прочитать информацию, которую он содержит. Для этого можно использовать функцию увеличения).
Информация, обязательная для размещения, должна быть представлена в текстовом и (или) табличном формате. Такой формат должен обеспечивать автоматическую обработку данной информации (машиночитаемый формат) в целях повторного использования без предварительного изменения человеком (п. 6).
Согласно п. 7 Требований все страницы сайта, содержащие сведения, обязательные к размещению, должны иметь специальную html-разметку, позволяющую однозначно идентифицировать информацию. Данные, размеченные указанным образом, должны быть доступны для просмотра посетителями сайта. То есть заказчик должен проконтролировать полноту отображения обязательной информации и правильность ее размещения: соблюдаются ли абзацы, выделены ли заголовки, насколько удобочитаем текст и т.д.
Заключение
Технологические и программные средства, которые используются для функционирования официальных сайтов, должны обеспечивать:
а) доступ пользователей для ознакомления с информацией на основе свободного общедоступного программного обеспечения;
б) защиту информации от уничтожения, модификации и блокирования доступа к ней, а также от иных неправомерных действий;
в) возможность копирования информации на резервный носитель, обеспечивающий ее восстановление.
МИНИСТЕРСТВО СТРОИТЕЛЬСТВА И ЖИЛИЩНО-КОММУНАЛЬНОГО ХОЗЯЙСТВА РОССИЙСКОЙ ФЕДЕРАЦИИ
от "___" _____________ 2014 года N ____
Приложение к приказу
Минстроя России
от "___" ___________ 2014 года N ____
Требования к формату документов, предоставляемых в электронной форме для получения государственной услуги по государственной экспертизе проектной документации, результатов инженерных изысканий
1. Требования к формату документов, предоставляемых в электронной форме для проверки достоверности определения сметной стоимости объектов капитального строительства, строительство которых финансируется с привлечением средств федерального бюджета, утвержденном постановлением Правительства Российской Федерации от 18 мая 2009 года N 427 "О порядке проведения проверки достоверности определения сметной стоимости объектов капитального строительства, строительство которых финансируется с привлечением средств федерального бюджета"
Принятые сокращения и термины
1. Форматы документов.
1.1. Сводный сметный расчет:
- Рекомендуемый формат документов: *.xlsx.
- Допустимые форматы документов: *.pdf (с обязательной возможностью копирования текста), *.xml (ПК "ГРАНД-Смета").
- Материал должен быть продублирован с подписями и печатями в формате *.pdf.
1.2. Сметные расчеты:
- Рекомендуемый формат документов: *.xlsx.
- Допустимые форматы документов: *.pdf (с обязательной возможностью копирования текста), *.xml (ПК "ГРАНД-Смета").
1.3. Ведомости объемов работ:
- Рекомендуемый формат документов: *.pdf с подписями поставщиков и заказчика.
- Допустимые форматы документов: *.docx (с дублированием в *.pdf с подписями разработчиков и заказчика).
1.4. Документы, обосновывающие цену материалов, отсутствующих в ценниках базового периода (прайс-листы):
- Рекомендуемый формат документов: *.pdf с подписями разработчиков и заказчика.
1.5. Содержание документов:
- Одна книга документации - один документ, не допускается формирование документации по принципу "одна страница - один документ".
- Текстовые фрагменты должны включаться в документ как текст с возможностью копирования.
- Графические изображения должны соответствовать оригиналу, как по масштабу, так и по цветовому отображению.
- Графические документы должны быть оптимизированы для просмотра.
- Документ должен иметь содержание, поиск.
- В документах *.pdf рекомендуется создавать закладки по оглавлению и по полному перечню таблиц и рисунков.
- Каждый документ документации в электронном виде должен быть заверен ЭП уполномоченного лица.
2. Требования к параметрам сканирования:
2.1. Сканирование должно осуществляться непосредственно с оригинала документа в масштабе 1:1 (не допускается сканирование с ксерокопий).
2.2. При отсутствии в документе каких-либо графических изображений сканирование рекомендуется осуществлять в черно-белом режиме при условии, что текст в документе черного цвета.
2.3. При наличии в документе цветных графических изображений либо цветного текста необходимо сканировать документ в режиме полной цветопередачи.
2.4. При наличии в документе изображений, отличных от цветного, сканирование рекомендуется осуществлять в режиме "Оттенки серого" при условии, что текст в документе черного цвета.
2.5. Документы текстовой части ПСД рекомендуется сканировать с разрешением 300 dpi.
2.6. Документы графической части ПСД должны быть отсканированы с разрешением 300 dpi для форматов А4, А3, А2 (включая кратные форматы) и 300 dpi для форматов А1 (включая кратные форматы) и А0.
2.7. Состав, содержание и форма сформированных электронных комплектов ПСД должны быть такими, чтобы при их распечатке обеспечивалось полное соответствие бумажной копии документа ее оригиналу (в том числе по масштабу и цветовому решению), без каких-либо дополнительных действий со стороны пользователя.
3. Аутентичные электронные документы.
3.1. Комплект аутентичных ЭД - это комплект ПСД подготовленный на основе компьютерного оригинала (без воспроизведения на бумажном носителе) в графических и текстовых редакторах.
3.2. Заверение ПСД в режиме аутентичного документа (без воспроизведения на бумажном носителе) может осуществляться одним из двух способов, перечисленных ниже:
- каждое лицо, участвующее в разработке, осуществляющее нормоконтроль и согласование ПСД заверяет ЭД своей ЭП. Порядок заверения определяется внутренними регламентами организации-заявителя. Полностью подготовленный ЭД подписывается ЭП уполномоченного лица организации заявителя, после чего может быть передан для прохождения экспертизы;
- при невозможности обеспечить всех ответственных лиц ЭП на отдельные документы, книги, разделы (тома) проекта оформляется информационно-удостоверяющий лист (УЛ). В УЛ указывают обозначения ЭД, к которым он выпущен, фамилии и подлинные подписи лиц, разработавших, проверивших, согласовавших и утвердивших соответствующий ЭД. Подписи лиц, разработавших ЭД и УЛ, и нормоконтролера являются обязательными. В соответствующей графе "Дата" УЛ указывается дата и время последнего изменения утверждаемого документа. Рекомендации по оформлению УЛ содержатся в ГОСТ 2.051-2006 Электронные документы.
3.3. Полностью оформленный на бумажном носителе УЛ сканируется с сохранением в форматах *.pdf, подписывается ЭП уполномоченного лица организации-заявителя, после чего собирается в одну книгу (документ) и может быть передан для прохождения экспертизы.
4. Общие рекомендации по способам формирования ЭД.
Заверенные копии бумажных подлинников ПСД (комплект ПСД на электронной бумаге )
Заверение ЭП уполномоченного лица
Заверенные копии оригиналов, выпущенных в специализированных программных средствах (комплект аутентичных ЭД).
1.Заверение с ЭП всех участников разработки ПСД
2.Заверение с УЛ и ЭП уполномоченного лица
5. Общие правила именования документов электронных документов.
- Наименование документа должно быть понятным, соответствовать наименованию на титульном листе и составу проекта.
6. Структура каталога переданной документации.
Папка-каталог с названием:
- Общий перечень предоставляемой на экспертизу документации.
- Результаты инженерных изысканий *
* (в случае проведения экспертизы проверки достоверности сметной стоимости объектов, финансируемых без привлечения средств федерального бюджета, предоставляются вместе с положительным заключением государственной экспертизы по технической части)
- Пояснительная записка к сметной документации.
- Сводный сметный расчет.
- Объектные сметные расчеты.
- Локальные сметные расчеты.
- Ведомости объемов работ и спецификации.
- ИРД (исходно-разрешительная документация).
- Иная документация (по необходимости).
7. Состав и содержание папок.
7.2. Состав и содержание папки-каталога "Ведомости объемов работ и спецификации":
- Ведомости объемов строительных и монтажных работ, спецификации на оборудование и мебель должны быть представлены по каждому разделу проектной документации и видам инженерных изысканий отдельно.
- Ведомости объемов строительных и монтажных работ, спецификации на оборудование и мебель должны быть продублированы в виде отсканированных образов документов с подписями разработчиков и ГИПа, представлены в формате *.pdf.
- Все позиции в ведомостях объемов работ должны содержать ссылки на чертежи и формулы подсчета объемов работ.
7.3. Состав и содержание папки-каталога "Прайс-листы":
- Прайс-листы должны быть подобраны на основе конъюнктурного анализа наиболее экономичного решения (в соответствии с МДС 81-35.2004), с представлением сравнительной таблицы стоимостных показателей, подтверждены Заказчиком и представлены в формате *.pdf.
- Стоимость в прайс-листах должна быть с расшифровкой включенных в стоимость затрат (НДС, тара, транспортные расходы, комплектация и т.д.) в рублевом исчислении.
7.4. Состав и содержание папки-каталога "ИРД"
Отдельно в папках с соответствующим названием располагаются иные материалы, необходимые для проведения государственной экспертизы:
- заключение государственной экспертизы;
- задание на проектирование;
- задание на выполнение инженерных изысканий;
- Решение о подготовке и реализации бюджетных инвестиций в объект капитального строительства;
В далеком 2001 году, консорциум W3C выработал рекомендации языка определения схем XML (XSD), объединив наиболее популярные языки описания схем в один стандарт. Основная цель, которая при этом преследовалась – получение платформо-независимого стандарта, который могут использовать все участники информационного обмена. Обуздав хаос, XML стал самым привлекательным форматом информационного обмена. В наши дни XML формат в информационных технологиях используется очень широко, выйдя далеко за рамки простого обмена данных.
2. Проблематика
Если же Вы связаны с разработкой приложений со слабосвязанными или распределенными компонентами в сервис-ориентированной архитектуре, Вам знакомы понятия SOA (service-oriented architecture) и SOAP (Simple Object Access Protocol), то очень скоро наступит момент, когда Вы сами будете нуждаться в актуальной документации больше, чем Ваш заказчик.
Поэтому вопрос «Нужна ли документация?» имеет однозначный ответ «Да», рано или поздно с этим столкнется каждый, кто связан с разработкой ПО, использующего XML.
Следующий очевидный вопрос – каким должен быть результат документирования форматов? Ответить на этот вопрос довольно сложно, ведь у разных потребителей результата (архитекторов, разработчиков, аналитиков, технических писателей, администраторов, представителей Заказчика и всех остальных) стоят совершенно разные задачи.
Решают эту задачу по-разному. Кто-то (например, разработчики oXygen) пошел по пути полного описания XSD схемы. В результате чего описание становится еще более сложным для понимания, чем сама схема. Другие стоят на том, что все должны уметь читать XSD схемы и никакой документации не нужно – иногда только потому, что понимают, что они не в состоянии поддерживать актуальность этой документации. Как всегда, истина лежит где-то посередине…
3. Суть проблемы
И вот тут у него возникает дилема: внести только те изменения, о которых сообщил ему архитектор или крыжить все схемы, у которых изменился размер файла. Любой, даже самый добросовестный работник выберет первый вариант – и будет неправ. Этот вариант не работает! – в схемах очень часто присутствуют незаявленные изменения, о которых архитектор или разработчик забывает сообщить и при таком подходе описание форматов неизбежно разойдется со схемами. Чем это грозит? – когда начнется разработка, расхождение обнаружится, что внесет толику хаоса и в разной степени усложнит разработку всем командам, участвующим в интеграции.
Каково же решение? Увы – остается единственный вариант – крыжить каждый раз, все изменившиеся схемы. Это принять очень непросто. Документ с альбомом форматов может занимать не одну сотню листов и прокрыжить его, это очень тяжелый и кропотливый труд. Очень часто, на того, кто разрабатывает этот документ оказывает сильное давление срочность выполнения. Не все понимают, почему изменить описание нескольких элементов в нескольких схемах может «стоить» целый рабочий день или еще больше.
Самый очевидный вариант документирования форматов – ручками. Открываете схему и описываете ее элемент за элементом, что занимает очень много рабочего времени. Если схема большая или их много, то уже через несколько дней Вы приобретете специфический красный оттенок глаз профессионального программиста и стойкое отвращение к этой работе. Следом придет понимание того, что не может быть, чтобы подобную работу давно не автоматизировали и последующий упорный поиск готового инструмента.
Прежде чем искать инструмент для автоматизации, неплохо было бы понять, как его хотелось бы использовать и каким должен быть результат его работы?
- Документирование структуры элементов одной или нескольких XSD схем с заполненным «documentation» – это самый простой вариант, когда мы формируем документ из одного источника информации (XSD схемы). Обычно это схемы, которые разработаны внутри команды в рамках текущей работы. Идеально, если разработка ведется с учетом соглашения о разработке схем, в котором указано, не только то, что элементы схемы должны документироваться, но и каким именно содержанием и формулировками.
- Документирование структуры элементов одной или нескольких XSD схем с незаполненным «documentation», либо заполненным частично – этот вариант посложнее. Это схемы, которые разработаны другими командами. Часто такие схемы регулярно приходят со стороны «As is» и мы не можем предъявлять к ним какие-либо требования. В этом случае из самой схемы может быть взята только структура, а описание элементов нужно добавлять ручками.
- Сравнение структуры элементов XSD схем разных версий – у нас есть схемы и их описание, и вот схемы поменялись и нужно актуализировать описание либо получить информацию об изменениях. Схемы могут меняться как значимо, когда добавляются или удаляются элементы, так и чисто косметически, когда в каком-то комментарии убрали лишний пробел и изменилась контрольная сумма файла. Отдельно нужно отметить случай, когда схема переписывается с использованием другого шаблона – в этом случае с точки зрения данных ничего не меняется, но узнать в новой схеме старую можно только потратив на это много времени или используя специальное ПО. С учетом того, что схемы могут приходить пачками из сотен штук, становится понятно, что сравнивать схемы глазками очень сложная и ресурсоемкая работа.
- "№ п/п" — здесь показано позиционирование элемента на схеме в виде многоуровневого списка.
- «Наименование элемента и его тип» — здесь показаны данные, идентифицирующие элемент – наименование элемента и его тип.
- «Описание элемента» — здесь показаны бизнес данные по элементу – его описание с точки зрения бизнеса.
- «Правила заполнения» — здесь показаны технические данные: правила заполнения элемента, формат данных, примеры значений и т.д.
- «Мн.» — здесь показана мощность элемента – обязательность, множественность и возможность выбора элемента.
5. Поиск решения
Исходя из сценариев использования и требуемого результата сформировались основные требования к функциям инструмента, который должен автоматизировать эту активность:
- Генерация описания форматов элементов для выбранной XSD схемы.
- Генерация описания форматов элементов для всех XSD схем в выбранной папке и ее дочерних папках.
- Сравнение описания форматов элементов для выбранной схемы (либо схем в папках) и ее предыдущей версии.
- Обогащение описания форматов элементов в выходном документе с использованием описаний элементов, заданных в отдельном файле.
- Приведение описания форматов элементов к единому виду в структуре шаблона «Матрешка», независимо от использованного шаблона при проектировании XSD схем.
Однако, проблема была как никогда актуальна и такой инструмент был создан…
6. Решение
6.1. Пример обработки документированной схемы
Здесь показан результат описания форматов элементов, полученного из XSD схемы с заполненным «documentation».
6.1.1. Исходная схема
6.1.2. Полученный результат
6.2. Пример использования внешнего описания
Здесь показан результат описания форматов элементов, полученного из XSD схемы с незаполненным «documentation».
6.2.1. Исходная схема
6.2.2. Данные файла внешнего описания
6.2.3. Полученный результат
Обратите внимание, что полученный результат полностью идентичен результату обработки документированной схемы!
6.3. Пример сравнения двух схем
Здесь показано описание форматов элементов, полученного при сравнении разных версий XSD схемы.
6.3.1. Исходная схема
6.3.2. Предыдущая версия схемы
6.3.3. Полученный результат
У новых элементов «FirstName», «LastName» и «Zip» выделены жирным шрифтом все колонки. У элемента «Address» изменилась позиция – жирным шрифтом выделена только первая колонка. Удаленные элементы «FullName» и «Country» выделены серым шрифтом. Также «читать» изменения помогает фон строк.
Данное представление делает отличия легко читаемыми как на экране, так и в печатном виде.
Читайте также: