Настоящий документ содержит технические и организационные рекомендации по способам и средствам представления и публикации произведений и документов, передаваемых по госконтрактам. Основное внимание уделено представлению результатов, полученных при разработке автоматизированных информационных систем и программного обеспечения, однако общие подходы, принятые в документе, могут быть применены и к любым другим нематериальным результатам, представляемым в электронной форме. При этом следует отметить, что нормирование содержательной части таких работ должно являться предметом отдельной разработки с привлечением специалистов соответствующих предметных областей.
Приведенные ниже рекомендации основаны на практическом опыте использования и экспертизы результатов работ по госконтрактам, в т.ч. выполнявшихся в рамках целевых программ в области информационных технологий (ФЦП «Электронная Россия», ГЦП «Электронная Москва») и призваны служить основой для выработки конкретных требований к исполнителям работ по госконтрактам. В целом документ ориентирован на вновь создаваемые произведения и документы, однако в заключении также кратко рассмотрены вопросы о приведении к единому, удобному для применения виду и ранее полученных результатов работ, в т.ч. отчетной документации по завершенным госконтрактам.
В документе не рассматриваются юридические аспекты применимости тех или иных технических условий представления результатов работ по госконтрактам и возможности их раскрытия (широкой публикации).
Документ условно можно разбить на две основные части:
в первой части, включающей разделы Документирование информационных систем и Способы представления, приведены рекомендации по техническим требованиям, которые следует предъявлять к исполнителям работ по госконтрактам в части способов представления результатов.
во второй части, включающей разделы Процедура публикации и Требования к Хранилищу раскрываемых материалов по госконтрактам, рассматриваются непосредственно вопросы технической процедуры раскрытия (публикации) результатов работ.
Раздел требований к содержательной части передаваемых произведений
более комплексным рассмотрением программ для ЭВМ, как части автоматизированной системы (АС), т.е. «системы, состоящей из персонала и комплекса средств автоматизации его деятельности, реализующей информационную технологию выполнения установленных функций» (здесь и далее термины области АС даны по ГОСТ 34.003-90), что не вступает в противоречие с правовой природой передаваемых результатов работ, однако позволяет лучше детализировать технические требования к ним.
наличием достаточно развитой и не полностью устаревшей нормативно-технической базы, позволяющей формулировать требования регламента с опорой на нее и сохранением преемственности.
Раздел требований к форматам представлений (раздел Способы представления) разрабатывался в расчете на его использование в качестве основы для единых стандартов или технических условий на представление результатов работ по госконтрактам. Формулировки раздела без значительных изменений могут использоваться для включения в тексты рабочих программ, заданий на разработку и иных документов, определяющих порядок и форму представления результатов работ. Для упрощения процедуры контрактации нами рекомендуется оформить рекомендации в виде технико-нормативного документа (РД, ОСТ, ведомственной инструкции), ссылку на которую включать в тексты технических заданий.
При выборе форматов в основу требований были положены следующие принципы:
открытость и полнота спецификаций;
доступность программ для создания, просмотра, проверки корректности и обработки материалов, представленных в данном формате.
Раздел требований к Хранилищу (раздел Требования к Хранилищу раскрываемых материалов по госконтрактам) разрабатывался в расчете на его использование в качестве основы для конкурсного задания или рабочей программы по созданию соответствующего информационного сервиса в рамках портала «Электронное правительство» или в виде отдельной АИС.
При формулировании технических заданий, рабочих программ и иной первичной документации к госконтрактам на разработку программ для ЭВМ, даже если в рамках госконтракта не выполняется поставка оборудования (средств вычислительной техники), рекомендуется придерживаться системного подхода, рассматривая любую программу как часть автоматизированной системы, включающей, помимо программного, и другие виды обеспечения. Это позволит более четко документировать условия (среду), в которых будет использоваться разработанная исполнителем по госконтракту программа, в том числе цельно и непротиворечиво определить те компоненты автоматизированной системы, которые должны быть предоставлены госзаказчиком или иным лицом, использующим результаты работ по госконтракту.
В части оформления проектной документации автоматизированных систем на сегодняшний день существует достаточно приемлемая, хотя и нуждающаяся в совершенствовании регламентация, а именно группа ГОСТов, относящихся к 34 серии, в частности:
ГОСТ 34.201-89 Информационная технология. Комплекс стандартов на автоматизированные системы. Виды, комплектность и обозначения документов при создании автоматизированных систем.
ГОСТ 34.601-90 Информационная технология. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Стадии создания.
ГОСТ 34.602-89 Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы
ГОСТ 34.603-92 Информационная технология. Виды испытаний автоматизированных систем
РД 50-34.698-90 Автоматизированные системы. Требования к содержанию документов.
Указанные нормативно-технические документы позволяют достаточно полно и качественно описать разработанную информационную систему и обосновать принятые в ней проектные решения – при условии жесткого соблюдения исполнителем требований состава, назначения и структуры документов. При этом рекомендуется дополнительно ограничивать предусмотренную в ГОСТ возможность исключения и слияния подразделов документации, что часто используется исполнителями для произвольного толкования содержательных требований стандарта.
Аналогичная проблема возникает в связи с тем, что состав документов, предусмотренный ГОСТ 34.201-89, является в значительной степени избыточным, а часть из них либо утратила смысл в силу развития технологий, либо не применима к большинству информационных систем (например, «Схема соединений» для проектов, в рамках которых не производится поставка технических средств, или «Пакеты входных/выходных данных» для систем, реализующих взаимодействие). С другой стороны, документация стадий эскизного и технического проектировании имеет каскадную структуру – большинство документов соответствуют определенным разделам общей пояснительной записке, дополняя или уточняя их.
В результате простую общую ссылку на ГОСТ 34.201-89 в условиях госконтракта следует считать недостаточной. При предоставлении исполнителю права самостоятельно определять состав необходимых проектных и рабочих документов зачастую возникает ситуация либо избыточного документирования (в проект включаются все предусмотренные документы, в т.ч. бессмысленные для данного проекта или дублирующие друг друга), либо недостаточного (все решения по проекту описываются в одной пояснительной записке, что перегружает документ или не позволяет представить всю необходимую информацию). Также на стадии «РД» зачастую опускается документ «Общее описание системы», что не позволяет оценить, как именно были реализованы решения стадий ЭП/ТП.
С учетом рекомендаций, изложенных в разделе Представление программного обеспечения требование об обязательной разработке общего описания следует прямо включать в условия госконтракта (в задание или рабочую программу), а также определять точный состав других документов, подлежащих разработке. Кроме того, рекомендуется более четко выполнять привязку календарных планов госконтрактов к стадийности разработки АС по ГОСТ 34.601. Состав этапов в таблице ниже дан для справки, он может изменяться и дополняться в зависимости от потребностей процесса разработки. Аналогично из проектов могут исключаться отдельные стадии, например, эскизного проектирования. При этом необходимым является соблюдение правильного именования и последовательности стадий, что позволит корректно трактовать положения прочих требований ГОСТ по документированию.
|
Стадии |
Этапы работ |
|
1. Формирование требований к АС |
1.1. Обследование объекта и обоснование необходимости создания АС. 1.2. Формирование требований пользователя к АС. 1.3. Оформление отчёта о выполненной работе и заявки на разработку АС (тактико-технического задания) |
|
2. Разработка концепции АС. |
2.1. Изучение объекта. 2.2. Проведение необходимых научно-исследовательских работ. 2.3. Разработка вариантов концепции АС, удовлетворяющего требованиям пользователя. 2.4. Оформление отчёта о выполненной работе. |
|
3. Техническое задание. |
Разработка и утверждение технического задания на создание АС. |
|
4. Эскизный проект. |
4.1. Разработка предварительных проектных решений по системе и её частям. 4.2. Разработка документации на АС и её части. |
|
5. Технический проект. |
5.1. Разработка проектных решений по системе и её частям. 5.2. Разработка документации на АС и её части. 5.3. Разработка и оформление документации на поставку изделий для комплектования АС и (или) технических требований (технических заданий) на их разработку. 5.4. Разработка заданий на проектирование в смежных частях проекта объекта автоматизации. |
|
6. Рабочая документация. |
6.1. Разработка рабочей документации на систему и её части. 6.2. Разработка или адаптация программ. |
|
7. Ввод в действие. |
7.1. Подготовка объекта автоматизации к вводу АС в действие. 7.2. Подготовка персонала. 7.3. Комплектация АС поставляемыми изделиями (программными и техническими средствами, программно-техническими комплексами, информационными изделиями). 7.4. Строительно-монтажные работы. 7.5. Пусконаладочные работы. 7.6. Проведение предварительных испытаний. 7.7. Проведение опытной эксплуатации. 7.8. Проведение приёмочных испытаний. |
|
8. Сопровождение АС |
8.1. Выполнение работ в соответствии с гарантийными обязательствами. 8.2. Послегарантийное обслуживание. |
В рамках совершенствования системы стандартов на документирование следует разработать дополнительный документ (возможно, в виде внутриведомственной инструкции и т.п.), дающий дополнительные толкования по требуемому содержанию отдельных разделов и пунктов стандартных документов с учетом текущего состояния научно-технического прогресса в области ИТ. Частично (в рамках потребностей публикации результатов работ по госконтрактам, для документа «Общее описание системы») данная задача решается в разделе Представление программного обеспечения настоящих Рекомендаций.
Следует отметить, что текст ГОСТ серии 34 в части требований по оформлению некоторых решений по программному обеспечению АС содержит ссылки на ГОСТ серии 19 – «Единой системе программной документации» (ЕСПД). Эти ГОСТы, разработанные в начале 70-х годов, были ориентированы преимущественно на документирование программ для ЭВМ «единой серии» (ЕС) и к настоящему моменту совершенно устарели. Кроме того, формулировки ГОСТ допускают практически произвольную трактовку, т.е. не решают основной задачи регламентации – обеспечения единого понимания документации всеми участниками работ по госконтракту. На практике следы применения ГОСТ 19 в программной документации по госконтрактам состоят только в наименованиях отдельных документов. В связи с эти настоятельно рекомендуется избегать привязки к ГОСТ 19 серии в требованиях и заданиях госконтрактов, и прямо ограничивать возможность перехода к ним по ссылкам из текстов ГОСТ 34.
К сожалению, рассмотренная в настоящем подразделе система стандартов не покрывает всех потребностей по документированию различных стадий создания ИС. Так, например, в части оформления технико-экономических обоснований создания АС единственным документом уровня ГОСТ остается стандарт предшествующей серии - ГОСТ 24.202-80 «Требования к содержанию документа «Технико-экономическое обоснование», регламентирующий только общую структуру документа, но не его содержательную часть. Недостаточным на практике являются и набор эксплуатационных документов. В связи с этим в разделе Документирование информационных систем нами приведены рекомендации по разработке новых стандартов документирования.
Отдельной задачей в рамках документирования автоматизированных систем является документирование их программного обеспечения (см. ниже) с точки зрения технического и юридического описания программ для ЭВМ, разработка и/или передача прав на которые является непосредственным предметом госконтракта. Для решения этой задачи в настоящем документе в разделе Представление программного обеспечения предложено расширение (детализация) предусмотренного в ГОСТ документа «Общее описание системы».
Здесь и далее в документе под программным обеспечением (ПО) понимается совокупность программ для ЭВМ, предназначенных для отладки, функционирования и проверки работоспособности автоматизированных систем, создание которых осуществляется в рамках госконтрактов, документированные в соответствии с требованиями госконтракта, и представленные на носителях данных. Программное обеспечение системы может включать как программы, разработанные и/или передаваемые по госконтракту, так и иные программы. Допустимость и порядок использования таких компонентов должны быть явным образом определены в первичной документации госконтракта. Перечень и описание входящих в состав программного обеспечения системы, но не передаваемых по госконтракту программ должно быть приведено в описании системы в разделе «сведения, необходимые для обеспечения эксплуатации системы» (см. разд. Описательная часть).
Основными способами представления передаваемых программ являются исходный код и дистрибутив (определения понятий см. п. Предметная часть).
Предпочтительной формой представления является представление программ в исходных кодах, что позволяет анализировать, дорабатывать и повторно использовать разработанные программы и их фрагменты.
Представление программного обеспечения в виде дистрибутива может предусматриваться в следующих случаях:
невозможность раскрытия исходного кода передаваемых программ по юридическим обстоятельствам. В этом случае госзаказчику передается только дистрибутив, являющийся основной формой представления результатов работ;
сложная структура или процедура настройки передаваемых программ, особенности их назначения или эксплуатации (большое количество точек внедрения). В этом случае дистрибутив является дополнительной формой представления результатов работ, не заменяя собой исходного кода. Назначение дистрибутива – упростить процедуру установки и настройки программ, снизить требования к квалификации персонала и вероятность ошибки в результате неправильной сборки.
Необходимость и/или допустимость передачи результатов работ в виде дистрибутива должны быть прямо оговорена в первичной документации госконтракта.
Прочие способы представления программного обеспечения следует рассматривать, как специальные и/или вспомогательные. В их число, в частности, могут входить:
передача ПО в составе функционирующей системы, включающей технические средства (например, компьютер с предустановленной операционной системой).
передача ПО в виде функционирующей инсталляции на технических средствах заказчика или иного оператора системы.
При заключении госконтрактов, условия которых предусматривают подобные условия передачи, рекомендуется производить обязательную техническую и юридическую экспертизу оправданности такой формы представления. В ходе экспертизы следует по возможности определить дополнительный способ представления результатов в виде исходного кода, дистрибутива или резервной копии ПО, обеспечивающий сохранность результатов работ в случае утраты технических средств и прочих обстоятельствах.
При представлении исходных кодов и дистрибутивов программного обеспечения как Госзаказчику, так и Исполнителю (разработчику) следует руководствоваться следующими принципами:
конечной целью работ по госконтрактам, как правило, является не передача заказчику обособленного компонента программного обеспечения, а создание работоспособной автоматизированной системы. Разработчик должен снабдить Госзаказчика информацией обо всех видах обеспечения АС, которым тот должен располагать для запуска системы в эксплуатацию (или иного использования в зависимости от стадии работ, например, для осуществления НИОКР и т.п).
представление исходного кода и дистрибутивов программ, среди прочего, должно служить целям снижения зависимости Госзаказчика от конкретных организаций-разработчиков и их специалистов (носителей знаний). Представленной разработчиком информации должно быть достаточно как минимум для воспроизводства процедур сборки (компиляции и т.п.), настройки и запуска системы (программы) любым специалистом заданной квалификации, при этом от специалиста не должно требоваться никаких интуитивных предположений о настройках, условиях эксплуатации, системных требованиях и т.д.
Для выполнения поставленных задач комплект (пакет) передаваемого программного обеспечения должен включать:
1) Описательную часть. Задачей описательной части является предоставление госзаказчику, а также потенциальному потребителю (компетентному пользователю) публикуемого исходного кода достаточной информации для быстрого первичного анализа его структуры и для сборки функционирующей системы (программного комплекса или компонента). Рекомендации по структуре и оформлению описательной части приведены в разделе Описательная часть.
2) Предметную часть - собственно набор исходных кодов или дистрибутив программного обеспечения (более подробно о способах представления программ см. п. Предметная часть).
В случае если условия госконтракта предусматривают передачу заказчику исходных кодов разработанного программного обеспечения, в программу испытаний при приемке результатов работ следует включать демонстрацию «собираемости» из представленного кода работоспособной системы на основании указаний, приведенных в описательной части. При передаче программ или отдельных компонентов в закрытом виде (исполняемые файлы, объектный код и т.п.) они должны рассматриваться, как дистрибутив. В этом случае программа испытаний должна включать демонстрацию возможности установки и настройки дистрибутива.
Нематериальные результаты работ по госконтрактам должны представляться в электронной форме.
Электронные версии результатов работ передаются госзаказчику по акту на машинных носителях – оптических компакт-дисках (CD-ROM или CD-R, стандарты Philips/Sony –Yellow Book/Orange Book part II, ГОСТ 27667-88, ГОСТ 28376-89). Использование перезаписываемых дисков не допускается. Диск должен иметь файловую систему ISO 9660:1988 (допускается использование расширений Joliet, официальные спецификации файловой системы Joliet могут быть получены у разработчика – компании Microsoft).
После ввода в действие Хранилища (см. раздел Процедура публикации) со средствами, обеспечивающими юридическую значимость совершаемых на нем транзакций, и принятия необходимой нормативной базы, регламентирующей порядок применения ЭЦП и иных средств придания юридической силы действиям, совершаемым в электронной форме, представление результатов работ на компакт-дисках может быть заменено на их загрузку в электронное Хранилище.
Другие формы представления являются дополнительными, дублирующими и определяются госзаказчиком в ТЗ или иных контрактных документах по мере необходимости. В бумажной форме рекомендуется представлять только документы, нуждающиеся в заверении или заполнении сторонами госконтракта. В составе документации на автоматизированные системы к ним, как правило, относятся ТЭО, ТЗ, ЧТЗ, пояснительные записки к эскизному и техническому проектам, программы и методики испытаний, формуляры и паспорта системы, а в отдельных случаях – концепции системы.
Результаты работ по разным госконтрактам должны представляться на разных носителях. В рамках одного госконтракта материалы группируются (путем объединения во иерархические каталоги/директории) в следующем порядке:
Нулевой уровень группировки – по подсистемам, направлениям работ и т.п. если такое деление имеется в условиях госконтракта.
Первый уровень группировки – по этапу контракта/стадии разработки.
Второй уровень группировки – по объему передаваемых прав:
результаты, по которым госзаказчику предоставляется право публикации;
результаты, объем передаваемых прав по которым недостаточен для публикации госзаказчиком (далее условно именуется «группа ограниченных прав»).
Размещая объекты в той или иной группе на данном уровне, исполнитель тем самым декларирует их, как передаваемый на соответствующих условиях, и несет ответственность за последствия этой декларации. Если передаваемые результаты содержат как предназначенные для публикации материалы, так и материалы с ограничениями на их использование, которые не могут быть отделены друг от друга по технологическим причинам, то вся совокупность таких материалов должна размещаться в группе ограниченных прав. Если в условиях госконтракта предусматривается несколько различных видов ограничений прав по тем или иным передаваемым результатам работ, то на том же уровне группировки допускается создавать дополнительные группы ограниченных прав, каждая из которых соответствует отдельной совокупности прав, передаваемых на содержимое группы.
Третий уровень группировки – по виду материалов:
документация;
исходные коды программ;
иные формы представления программ;
прочие материалы (в т.ч. мультимедийные файлы, наборы данных);
вспомогательные материалы, не входящие в состав передаваемых результатов работ, но полезные для их интерпретации (тексты нормативно-технической документации, свободно распространяемые программы для настройки и диагностики системы и т.п.). Данная подгруппа не предназначена для публикации даже при размещении в соответствующей группе второго уровня.
Группировка внутри группы «документация» не производится, группировка в прочих разделах определяется конкретной технической необходимостью (например, в соответствии со структурой каталогов, требующейся для компиляции исходного кода). Поскольку при передаче программного обеспечения наличие его описания является обязательным, при наличии групп «исходные коды программ» или «иные формы представления программ» всегда должна присутствовать группа «документация», содержащая, как минимум, один документ «Общее описание системы» (см. разд. Описательная часть). При передаче только прочих и вспомогательных материалов с ограничением прав по их использованию в группе «документация» должен содержаться справочный документ, описывающий объем передаваемых прав по каждому объекту (файлу, архиву), содержащемуся в той же группе второго уровня.
При большом объеме материалов группы могут разбиваться на несколько физических носителей (дисков), при этом деление должно осуществляться в рамках одного уровня группировки (т.е. допустима размещение на разные носители групп «Документация» и «Исходные коды» или «1 этап» и «2 этап», но недопустимо представление дисков с разбивкой вида «Подсистема А/1 этап», «Подсистема А/2 и 3 этап» и т.п.). Не рекомендуется выполнять разбивку материалов на разные носители ниже второго уровня группировки.
Материалы на компакт-дисках должны представляться только в виде полного комплекта (пакета), состав которого соответствует условиям соответствующего этапа госконтракта. Если в ходе работ возникает необходимость внести изменения в ранее представленный документ, или дополнить переданный пакет новым документом, то все ранее представленные на том же диске материалы представляются на новом диске целиком (включая и не изменявшиеся документы) в качестве очередной версии диска.
На каждом передаваемом носителе должна присутствовать надежная маркировка, включающая: шифр работ (при наличии), краткое наименование исполнителя по госконтракту, краткое наименование госзаказчика, номер и дата госконтракта, номер и дата акта передачи, указание на верхний уровень группировки материалов содержащихся на данном диске (например «4 этап (эскизный проект)/материалы для публикации/документация»), номер версии диска, если данный комплект материалов предоставляется не в первый раз.
После получения машинного носителя госзаказчиком им должна делаться резервная и рабочая копии материалов, а сам диск помещаться в архив. Способ выполнения резервной копии определяется внутренними регламентами госзаказчика. При наличии копии материалов в Хранилище (после его ввода в действие) ведение резервного копирования госзаказчиком не обязательно – в качестве источника рабочей копии используется Хранилище.
Группировка и классификация представляемых материалов в Хранилище должна осуществляться с помощью метаданных каждого информационного объекта (файла).
Примечание: Принципы именования файлов должны быть доопределены после уточнения требований к Хранилищу результатов работ. В качестве предварительной рекомендации предлагается принять одну из двух схем:
Для машинной обработки (для на ввод в действие Хранилища) – использовать буквенно-числовой идентификатор, состоящий из уникального индекса госконтракта, кода типа документа, порядкового номера документа данного типа, номера версии.
Для ручной обработки использовать текстовый идентификатор, включающий краткое наименование исполнителя (основного подрядчика по госконтракту), номер госконтракта, сокращенное обозначение документа (для документации на АС могут использоваться коды по ГОСТ 34.201-89), порядковый номер документа данного типа, номер приложения (если документ является приложением), дату версии.
Под передаваемой документацией здесь и далее подразумеваются текстовые данные (в т.ч. в таблицах), кроме исходных текстов программ, и включенную в них иллюстративную графику (в т.ч. схемы, рисунки. чертежи, диаграммы, графики). Документация может также включать в себя мультимедийные данные, если это определено первичной документацией конкретного проекта.
Ограничения существующего законодательства и принятых в различных ведомствах правил и процедур не позволяют полностью отказаться от представления документов в виде «твердой копии». С учетом этого, а также исходя из потенциальной возможности (раскрытия) публикации результатов работ для всеобщего сведения, каждый передаваемый в рамках госконтракта документ должен быть представлен в электронной версии, т.е. в виде файла как минимум одного из следующих форматов:
Формат для обработки. Обеспечивает возможность как просмотра, так и непосредственной правки, в т.ч. с отслеживанием вносимых изменений. Является обязательным форматом представления документов. При представлении документов в остальных предусмотренных настоящим регламентом форматах, они должны сопровождаться копиями в формате для обработки, соответствующими оригиналу в пределах технических возможностей формата для обработки.
Формат для печати. Предназначен для независящего от используемого оборудования отображения или распечатки документов. Применяется:
Для документов, по юридическим основаниям представляемых также в виде твердой (бумажной) копии, когда юридически значимым является постраничная разбивка текста и расположение на страницах иных содержательных элементов (иллюстраций, колонтитулов и т.п.), которое не может быть обеспечено средствами формата обработки.
Для документов, где значимым является точное взаиморасположение (верстка) содержательных элементов, которое невозможно обеспечить средствами формата для обработки (чертежи и схемы, сложные таблицы, руководства пользователей и учебные материалы, макеты книг и т.п.).
Формат для распространения (гипертекстовый формат). Предназначен для распространения результатов работ в Интернете или по иным сетям, а так же для целей машинной каталогизации, индексирования поисковыми системами, автореферирования и т.п. задач. Содержание документа, представленного в данном формате, должно быть максимально отделено от его представления. Документ может включать внутренние и внешние гиперссылки.
Представление документации в форматах, отличных от вышеперечисленных, в т.ч. в форматах электронных таблиц, презентаций, в виде неформатированных текстовых файлов и т.д. допускается только в качестве дополнения к документу того же содержания в одном из основных форматов.
В каком именно формате должен представляться тот или иной документ, подлежащий сдаче, определяет госзаказчик при составлении технического задания, рабочей программы или иного документа в составе госконтракта, где определяются требования к результатам работ. В том случае, если выдвигается требование о представлении документа одновременно в нескольких форматах, госзаказчик должен определить, какая из версий документа является основной.
Если формат документов не был оговорен при заключении госконтракта, то документы должны быть представлены в формате для обработки, представление их копий в других форматов осуществляется по усмотрению исполнителя.
Каждый представляемый в электронной форме документ должен оформляться в виде отдельного файла. Приложения к документам допускается как включать в состав файла основного документа, так и представлять в виде отдельного файла (при размере приложения, большем, чем ½ от основного документа). Способы представления приложений не должны смешиваться – т.е. при наличии нескольких приложений к документу они должны либо включаться в состав того же файла, что и основной документ, либо каждое из приложений должно оформляться в виде отдельного файла.
В состав каждого передаваемого пакета документов (т.е. если количество одновременно передаваемых документов более одного) должна включаться их опись – ведомость.
Для представления многоязыковых текстовых документов (в т.ч. русскоязычных) должна использоваться двухбайтовая кодировка Unicode (ISO-10646).
OpenOffice.org XML File Format (OASIS OpenOffice XML Format).
Первоначальным разработчиком стандарта является компания Sun Microsystems (http://www.sun.com/software/star/openoffice/index.html). Формат находится в стадии утверждения техническим комитетом OASIS (http://www.oasis-open.org/).
Официальные спецификации формата могут быть получены у технического комитета OASIS (http://www.oasis-open.org/committees/download.php/10765/office-spec-1.0-cd-2.pdf) или у организации-разработчика (http://xml.openoffice.org/xml_specification.pdf).
Спецификации формата распространяются по Public Document License Программы, предназначенные для работы с документами в данном формате, распространяются по лицензиям GNU (General Public License) и Sun Industry Standards Source License. (http://www.openoffice.org/license.html).
Для работы с файлами данного формата может использоваться программный комплекс OpenOffice (http://www.openoffice.org/dev_docs/source/1.1.0/index.html).
В качестве временной меры допускается представление документов по ранее заключенным госконтрактам в виде файлов, подготовленных в программах MS Word версии 7.0 и выше производства компании Microsoft (если иной формат представления документов не определен прямо в первичной документации проекта). При этом рекомендуется представлять документы в формате Rich Text Format (RTF). Учитывая, что формат MS Word является неспецифицированным и проприетарным, полученные в данном формате материалы перед размещением в Хранилище должны преобразовываться к одному из установленных в настоящем документе форматов.
ISO 15930-5:2003 - PDF 1.4 (PDF/X-2)
Первоначальным разработчиком формата является компания Adobe (http://www.adobe.com/).
Официальные спецификации формата могут быть получены у комитета ISO (http://www.iso.org/iso/en/CatalogueDetailPage.CatalogueDetail?CSNUMBER=39939&ICS1=37&ICS2=100&ICS3=99)
Для просмотра документов PDF может использоваться свободно распространяемая программа Adobe Acrobat Reader (http://www.adobe.com/products/acrobat/readermain.html)
Для создания документов в формате PDF может использоваться как коммерческое программное обеспечение компании Adobe (http://www.adobe.com/products/acrobat/main.html), так и инструменты сторонних разработчиков, в т.ч. доступные по свободным лицензиям.
HTML 4.01 Specification (W3C Recommendation 24 December 1999).
Сопровождение стандарта осуществляется организацией World Wide Web Consortium (W3C, www.w3c), редакторы Dave Raggett, Arnaud Le Hors, Ian Jacobs.
Спецификации стандарта могут быть получены у W3C (http://www.w3.org/TR/1999/REC-html401-19991224/). Валидация документов в формате HTML может быть произведена с помощью официального ресурса http://validator.w3.org/. Кроме того, имеется достаточное для задач представления документации по госконтрактам подмножество языка HTML, принятое в качестве международного стандарта ISO/IEC 15445:2000.
Имеется большое количество коммерческих и свободно распространяемых программ для работы с указанным форматом.
При оформлении документов в гипертекстовом формате следует придерживаться следующих правил и ограничений:
документ должен обеспечивать возможность автоматизированного встраивания в произвольные веб-страницы, т.е. не содержать никаких дополнительных элементов внешнего оформления и форматирования (шапок, колонтитулов, меню и т.п.) за исключением основных контейнеров <title>, <body>.
в документе должно использоваться только структурное форматирование с использованием тегов <h*> для заголовков соответствующего уровня, <strong> или <em> для смысловых выделений и т.д.
в документе не допускается явное задание параметров оформления (стилей и т.п.), переопределение стандартных структурных элементов, а также использование других оформительских средств, которые могут привести к конфликту с оформлением других веб-страниц при встраивании в них данного документа (содержимого контейнера body).
табличная разметка (теги <table>, <td>, <tr> и др.) должна использоваться только для оформления таблиц в тексте документа, а не для задания взаимного размещения элементов документа (верстки страниц). Вложение таблиц в таблицы не допускается.
вставка иллюстраций должна осуществляться по инлайновому принципу и допускать свободное автоформатирование текста (т.е. не допускается задание абсолютных параметров расположения). Иллюстрации должны в обязательном порядке снабжаться описанием в поле alt и/или title. Файлы иллюстраций размещаются в том же каталоге, что и файл самого документа, т.е. путь к файлу в параметре src тега <img> должен иметь вид «./» (допускается опускать).
не допускается использование тегов <div>, <span> и т.п. для многослойной верстки (в т.ч. с заданием абсолютных параметров размещения) и замены стандартных элементов структурной разметки.
не допускается использование средств автоматизации документа (сценариев, форм и т.п.)
не допускаются относительные гиперссылки (кроме внутренних якорей документа) и ссылки на ресурсы, не доступные в Интернете по протоколам http (https) или ftp.
По мере развития поддержки данного формата со стороны производителей веб-браузеров рекомендуется произвести миграцию гипертекстовых документов на язык разметки XHTML текущей версии. Поскольку указанные языки разметки являются совместимыми, исполнители работ могут представлять документы на любом из них.
Описательную часть пакета исходных кодов или дистрибутива программы (программного комплекса) рекомендуется оформлять в виде документа «Общее описание системы» (шифр ПД), ГОСТ 34.201-89, РД 50-34.698-90 с учетом нижеприведенных рекомендаций, уточнений и дополнений.
В документ не требуется включать обоснования принятых проектных решений, спецификации стандартных протоколов, доступные из других источников, детальные описания функционирования и т.п. вспомогательные сведения, которые при необходимости могут быть получены из прочей проектной документации. Сведения должны быть представлены в сжатой, конкретной форме, для упрощения восприятия документов рекомендуется использование списков и таблиц. Поясняющие рисунки и схемы следует использовать только в том случае, если представленная с их помощью информация имеет существенное значение для понимания структуры публикуемого кода, и если она не может быть сведена к перечню (простому или иерархическому) или таблице.
В том случае, если разрабатываемая система имеет сложную структуру, требующую подробного описания на стадии РД, в дополнение к основному документу следует разрабатывать отдельное краткое описание, которое и включается в комплект с публикуемыми исходными кодами.
Описательная часть должна относиться только к той системе (части системы), программное обеспечение которой представлено в виде исходного кода в данном пакете. Если система имеет составную структуру (например, включает специальное программное обеспечение, разработанное заказчиком и наложенную покупную подсистему безопасности) – то описывается именно специальное программное обеспечение, сведения о прочих компонентах даются справочно и только в той степени, в которой это необходимо для обеспечения сборки системы из исходного кода. Если система включает два и более независимых компонентов (например, интранет и интернет сервер, выполненные на разных платформах), и код программного обеспечения каждого из них передается в виде отдельного пакета, то на каждый из пакетов представляется собственное описание.
Описание должно включать следующие разделы:
общие сведения о системе
назначение системы;
описание системы;
описание взаимосвязей с другими системами;
описание подсистем (компонентов)
В разделе «Общие сведения о системе» указывают:
1) Полное наименование системы (части системы) в соответствии с техническим заданием на ее разработку или госконтрактом, присвоенные системе шифры и обозначения. Наименования части подсистемы, если описание относится не ко всей системе в целом.
2) Основания для разработки системы (номер госконтракта, ссылки на иные документы, непосредственно относящиеся к проекту). Сведения о госзаказчике.
Сведения об основаниях для публикации кода (например, номер приказа, распоряжения или реквизиты общего нормативного акта) и условия, на которых он распространяется (объем передаваемых прав и т.п.).
4) Сведения о разработчике (разработчиках) системы с указанием контактной информации и, по возможности, конкретного компетентного лица (диспетчера запросов). При участии в разработке нескольких организаций субподрядчики указываются только в том случае, если они отвечали за разработку определенного компонента или модуля и могут предоставить консультационную поддержку по нему.
5) Сведения об эксплуатирующей организации (операторе системы). Организация-оператор системы может отличаться от организации-пользователя. В этом случае указываются только организации, являющиеся центрами компетенции по вопросам эксплуатации системы.
В разделе «Назначение системы» приводят:
1) Вид деятельности, для автоматизации которой предназначена система
Четкое и краткое указание на конкретный рабочий процесс (совокупность процессов), реализуемых в системе, например: «ведение реестра бюджетополучателей», «публикация сведений о конкурсах», «кадровый учет» и т.п.
2) Перечень объектов, на которых используется система.
Сжатый список организаций-пользователей. Если система предназначена для эксплуатации в группе однородных организаций – указывается только их тип (например, «общеобразовательные учреждения»). Если система ориентирована на интернет-пользователей – приводится перечень основных целевых аудиторий.
3) Краткое описание назначения системы в терминах функций и комплексов задач.
Неприемлемый вариант описания:
«Система предназначена для дальнейшего улучшения обслуживания граждан и укрепления трудовой дисциплины»
Приемлемый вариант описания:
Система предназначена для публикации в Интернете исходных кодов программ и программных комплексов, разработанных по госконтрактам МЭРиТ, и реализует следующие функции управления контентом веб-сайта: создание, метаописание, редактирование и публикацию на сайте информационных объектов».
Рекомендуемый размер раздела – не более 1-2 страниц.
В разделе «Описание системы» приводят:
1) структуру системы и назначение ее частей.
Укрупненное описание программного обеспечения системы, необходимое для понимания принципа ее работы и соответствующее ее фактической структуре (т.е., например, если какие-либо подсистемы по ТЗ были реализованы в виде единого программного модуля, то описывается этот модуль, а не виртуальные подсистемы, и наоборот). В описание включаются как передаваемые по госконтракту компоненты, так и предоставляемые заказчиком или третьими сторонами. Для каждого компонента указывается, разработан ли он исполнителем по госконтракту, получен ли у третьей стороны и на каких условиях передается, должен ли быть предоставлен заказчиком и т.д. (перечень передаваемых компонентов рекомендуется оформить в виде таблицы). Структура технического комплекса описывается только в том случае, если она прямо связана со структурой программного обеспечения. Если в составе системы поставляется информационное обеспечение – дополнительно приводится перечень и краткое описание предоставляемых наборов данных.
2) сведения, необходимые для обеспечения эксплуатации системы:
Раздел должен включать:
описание общего (ОС, СУБД и др.) и специального программного обеспечения, компонентов программ (библиотек, SDK), а также необходимых вспомогательных программ для для установки, настройки диагностики и технического обслуживания системы, не входящих в число передаваемых госзаказчику результатов работ. Для всех программ и программных комплексов должны быть указаны:
точные наименования и версии;
поставщик (источник, откуда может быть получена программа);
условия поставки;
все необходимые для работы системы настройки, отличающиеся от предлагаемых «по умолчанию»разработчиком (поставщиком) программ;
все дополнительные компоненты программ (библиотеки, компиляторы и т.п.), не входящие в состав стандартной поставки, предлагаемой разработчиком (с указанием источника, если он отличается от источника получения основной программы). Указывается, используется ли дополнительный компонент на стадии установки (сборки, настройки) данной программы и системы в целом, или необходим в процессе ее использования.
Если система предусматривает возможность использования на различных типах общего программного и технического обеспечения (является кроссплатформенной), то приводятся сведения о степени ее независимости и о конкретных версиях и настройках общего ПО, на которых она тестировалась.
описание комплекса технических средств (КТС). Состав КТС, минимальные и рекомендуемые требования по производительности, если в составе системы передается техническое обеспечение – то указывается, в какой степени система является независимой от них.
описание программного обеспечения и требований к техническим средствам клиентских рабочих мест (для систем типа интернет- и интранет-порталов и т.п. с возможностью подключения сторонних - не входящих в состав персонала - пользователей).
указания по составу и требуемой квалификации обслуживающего персонала..
перечень программных средств (сред разработки), которые должны использоваться для просмотра и редактирования исходных кодов, если формат их представления отличается от формата, пригодного для просмотра и редактирования человеком с помощью произвольного редактора неформатированных (plain text ASCII или Unicode) текстовых файлов.
пояснения по принципам именования объектов и комментирования, принятым при составлении исходного текста программ.
указания по сборке системы из дистрибутива или (или ссылка на соответствующую инструкцию, если она разрабатывалась). Детализация инструкции должна быть достаточной для выполнения сборки/установки без участия разработчика системы и изучения исходного текста, с учетом выдвинутых ранее требований к квалификации персонала.
указания по первичному информационному наполнению системы (загрузке наборов данных и т.п.), если такое обеспечение поставляется в составе системы.
сведения
о необходимых мерах по обеспечению заданной категории защищенности
системы от несанкционированного доступа.
прочие сведения, включая рекомендации по необходимым для поддержания
работы системы инструментальным средствам, диагностическому и т.п.
программному обеспечению с указанием источников их получения
3) описание функционирования системы и ее частей: краткое описание основных рабочих процессов системы и ссылка на документы, детализирующие это описание (при их наличии).
В разделе «Описание взаимосвязей с другими системами» приводят:
1) перечень систем, с которыми связана (или может быть связана) данная АС;
2) описание связей между системами (все используемые каналы связи и протоколы);
3) регламенты связей, в т.ч.: организационные условия взаимодействия, периодичность и состав передаваемой и принимаемой информации, описания процедур взаимодействия. Детальные описания процедур рекомендуется выносить в приложения или приводить точные ссылки на соответствующие проектные и рабочие документы.
В разделе «Описание подсистем» приводят детализацию описания компонентов системы с точки зрения состава представленного исходного кода или состава дистрибутива (развернутого программного комплекса). В общем случае представляет собой перечень файлов с кратким описанием их функционального назначения и пояснениями по принципам их размещения (группировки) в исходном коде, дистрибутиве и развернутом программном комплексе. Для файлов сходного назначения допускается давать одно общее описание, например «драйверы принтеров» или «классы доступа к различным СУБД». Для каждого компонента (файла, группы файлов) должен быть указан объем прав, передаваемых госзаказчику, с особым указанием на допустимость/недопустимость их публикации.
Под исходным кодами понимаются тексты программ, пригодные как для анализа и корректировки человеком, так и для непосредственного преобразования в исполняемый код, интерпретации и т.п. Форматированные распечатки текстов программ (листинги), предназначенные только для чтения и анализа, равно как промежуточные результаты компиляции (байт-код и т.п.), которые не могут быть однозначно преобразованы в человекочитаемый формат, не считаются исходным кодом, а относятся к документации на систему. В общем случае представление листингов программ при наличии их документированного исходного кода не требуется.
Исходные тексты, разработанные и передаваемые исполнителем могут быть представлены в следующем виде:
текстовые неформатированные (plain text) файлы, непосредственно содержащие человекочитаемый исходный код программ;.
специальные форматы, ориентированные на конкретные среды разработки – в тех случаях, когда их применение оправдано и прямо допущено в условиях госконтракта, ТЗ или утвержденной заказчиком проектной документации.
Дополнительно в состав передаваемого исходного кода могут быть включены (при условии явного, с точностью до файлов, указания на это в описательной части) файлы с управляющими последовательностями для сборки программ из исходного кода (make-файлы) конфигурационные файлы, дампы структур БД, сценарии установки и т.п. вспомогательные файлы (в т.ч. разработанные третьими сторонами) – при наличии описания их структуры и формата в рабочей документации, при этом объем передаваемых заказчику прав на эти компоненты не должен быть менее, чем у остального исходного кода;
Представленные материалы должны быть необходимы и достаточны для сборки программы (программного комплекса), удовлетворяющего требованиям ТЗ на разработку и утвержденной проектной документации. Если какие-либо дополнительные компоненты необходимы для сборки программного комплекса, но не поставляются исполнителем, это должно быть оговорено в разделе «Сведения, необходимые для обеспечения эксплуатации системы» описательной части. Квалификация, требуемая для выполнения сборки программы (программного комплекса) из исходного кода не должна превышать базового уровня программиста соответствующей программной платформы.
В общем случае передаваемый исходный код должен обеспечивать возможность его публикации госзаказчиком. В связи с этим из исходного кода должны быть исключены все объекты, не являющиеся результатом работ по госконтракту и содержащие ограничения на право их публикации. Если эти объекты необходимы для сборки/функционирования системы, то они при передаче госзаказчику должны быть размещены в подгруппе «вспомогательные материалы» (см. разд. Способы представления). Если разделение публикуемых и непубликуемых компонентов невозможно или не оправданно по технологическим причинам (в частности, в силу высокой трудоемкости восстановления необходимой для нормальной трансляции совокупности исходных кодов), то такой исходный код рассматривается, как имеющий ограничения в целом.
Под дистрибутивом программного обеспечения системы понимается набор файлов, достаточный для того, чтобы путем выполнения конечного и четко определенного набора операций (инсталляционной процедуры) выполнить установку и запуск всех входящих в состав системы программ (программного комплекса АС), при этом не обязательно включающий пригодный для непосредственного восприятия человеком код программ. В общем случае дистрибутив должен включать программу-инсталлятор или инсталляционный сценарий, упрощающий процесс установки и настройки. Требования к квалификации персонала, выполняющего установку системы из дистрибутива, должны определяться в первичной документации госконтракта.
В тех случаях, когда технические средства, используемые при информационном обмене в рамках процедуры представления и публикации результатов работ, не позволяют сохранить при передаче и хранении требуемую структуру каталогов (директорий), материалы должны передаваться в виде единого файла – образа файловой системы в формате ISO 9660:1988.
Для представления графических материалов (иллюстраций, схем, чертежей), если иное не установлено условиями госконтракта, ТЗ или иной утвержденной документацией, для представления графических материалов (в т.ч. иллюстраций в гипертекстовых документах), должны применяться следующие растровые форматы:
PNG (ISO/IEC 15948:2004)
JPEG (ISO/IEC 10918-1:1994)
Под мультимедиа-материалами понимаются звукозаписи и аудиовизуальные произведения (в т.ч. трехмерные изображения, слайд-шоу и презентации, интерактивные произведения) в статической цифровой форме (мультимедиа-файле). Формат представления таких материалов должен быть установлен в первичной документации проекта (госконтракте, ТЗ, рабочей программе и т.п.). При выборе формата предпочтение должно отдаваться форматам:
с открытыми (официально опубликованными) спецификациями;
широко распространенными (распространенными следует считать форматы, официально поддерживаемые на большинстве стандартизированных программно-аппаратных платформ, причем при определении большинства следует принимать фактическую долю вычислительных систем того или иного типа, используемых в области, где предполагается применение формата);
имеющими больший выбор программных средств для создания, обработки и воспроизведения, в первую очередь – свободно распространяемых и с открытым кодом.
В тексте контракта должно использоваться официальное название формата, рекомендуется снабжать его справочной ссылкой (URL) на официальный источник спецификации. Следует учитывать, что многие употребительные названия мультимедиа-файлов (MPEG, WAV, JPEG, AVI) относятся к совокупности форматов. В документации проекта следует оговаривать конкретную версию (например, указывать тип используемого кодека).
В качестве среды распространения раскрываемых материалов по госконтрактам предполагается использовать возможности Интернета. С технической точки зрения процедура публикации должна включать следующие шаги
1) Размещение поступающих материалов в едином Хранилище раскрываемых результатов работ. Выполняется Оператором Хранилища на основании акта приема-передачи компакт-диска, а по мере реализации соответствующих средств Хранилища - на основании данных ЭЦП исполнителя работ. При размещении производятся следующие действия:
присвоение уникальных идентификаторов и кодов представленным материалам
сверка версий и обновление указателя действующей версии
проверка синтаксической правильности форматов, в которых представлена документация
первоначальная автоматическая индексация, классификация представленных материалов
По мере развития Хранилища на его технические средства также может быть возложен контроль своевременности и полноты представления материалов – путем сопоставления фактически представленных материалов с заранее зарегистрированным техническим заданием и календарным планом.
2) Редакционная обработка. Выполняется Оператором Хранилища с включением в процедуру должностных лиц Исполнителя и Госзаказчика. В ходе обработки производятся следующие действия:
ручная классификация, каталогизация и подробное метаописание поступивших материалов;
сверка с представленными бумажными копиями документов и подтверждение идентичности;
формирование сводных ведомостей результатов работ, контроль за полнотой представленных материалов;
внесение и утверждение технических правок (устранение опечаток, неточностей в наименованиях и т.п.).
3) Отслеживание закрытия работ по контрактам (выполняется Госзаказчиком при техническом содействии Оператора):
размещение в Хранилище необходимых сопроводительных документов, в т.ч. экспертных заключений, замечаний и предложений;
регистрация результатов испытаний информационных систем, информации о вводе в эксплуатацию, применении результатов НИР и НИОКР.
4) Формирование списков на раскрытие размещенных в Хранилище материалов по утвержденному регламенту (выполняется автоматически или Госзаказчиками при техническом содействии Оператора).
5) Утверждение списков раскрываемых материалов и определения режима доступа к ним (выполняется уполномоченными госорганами);
6) Непосредственная публикация для всеобщего или ограниченного доступа, включая размещение анонсов на смежных интернет-ресурсах (автоматически под контролем Оператора).
Для публикации и распространения раскрываемых необходимо создание единого технологического комплекса – Хранилища раскрываемых материалов, представляющего собой специализированную систему управления контентом. Хранилище может быть реализован как функциональная подсистема в рамках уже существующих АИС, например, интернет-портала МЭРиТ, или как самостоятельный информационный ресурс.
В основу работы Хранилища должен быть положено манипулировании информационными объектами – документами, пакетами ПО, другими материалами по госконтрактам, снабженными метаописаниями и классифицированными в системе рубрикаторов Хранилища. Хранилище должен обеспечивать соответствие общим принципам архитектуры электронного государства, в т.ч. наличие средств для:
Нотаризации (наделения правомочностью агентов),
Журналирования (архивирования и неизменяемости),
Транзакционности (обеспечивающих определенность статусов информационных объектов),
Внешнего доступа к внутренним статусам.
Создание Хранилища предлагается осуществлять в два этапа:
на первом этапе необходимо реализовать минимально необходимый набор средств для размещения материалов в Хранилище и обеспечения к ним регламентированного доступа пользователей. Отслеживание материалов, подлежащих раскрытию, при этом возлагается на Оператора и осуществляется оргметодами.
на втором этапе, по мере внедрения средств нотаризации и журналирования, в рамках Хранилища реализуется среда для совместной работы исполнителей по госконтрактам, представление материалов на компакт-дисках заменяется на их прямую загрузку в Хранилище, процедуры представления и раскрытия регламентируются и автоматизируются.
В конечном виде программный комплекс Хранилища должен обеспечивать следующие основные функции:
1) На стадии подготовки материалов к публикации:
авторизованный доступ исполнителей и заказчиков по госконтрактам к единой рабочей среде;
регистрацию проектов и присвоение уникального идентификатора, автоматическую проверку синтаксической правильности и преобразование форматов документации;
регистрацию реестров (перечней) материалов, подлежащих разработке и передаче заказчику в рамках проекта (контракта);
размещение текущих версий документов, пакетов исходных кодов и дистрибутивов программного обеспечения, иных материалов (включая бинарные и мультимедийные файлы), разрабатываемых в рамках госконтрактов;
размещение версий с сохранением предыдущих, фиксацию версии в качестве окончательной;
автоматическое составление реестров (ведомостей) представленных материалов по различным этапам работ;
взаимодействие со смежными системами для организации документооборота в рамках рассмотрения, согласования и утверждения списков на раскрытие;
регистрацию решения о раскрытии всех или части документов по госконтракту и публикации этих материалов;
поддержку функций контроля за полнотой и своевременностью представления и публикации материалов.
В состав средств подготовки к публикации должны быть включены специальные инструменты для размещения в Хранилище материалов госконтрактов, полученных до ввода в действие новых регламентов публикации.
2) На стадии публикации Хранилище должен обеспечивать регламентированный доступ авторизованных и анонимных пользователей к опубликованным материалам госконтрактов. Пользователям Хранилища должны быть доступны различные способы поиска опубликованных материалов:
по совокупности атрибутов метаописаний
по системе тематических и иных рубрикаторов
по контексту документов
Админстративные средства Хранилища должны обеспечивать
ведение реестра пользователей Хранилища (в т.ч. исполнителей и заказчиков работ)
ведение справочников, классификаторов, схем метаописаний информационных объектов
формирование регламента автоматического составления списков на раскрытие материалов
Средства Хранилища, если он реализуется, как независимая система, должны также включать:
инструментарий для мониторинга и диагностики системы
подсистему резервного копирования
подсистему информационной безопасности
При проектировании должны учитываться рекомендации по составу размещаемой информации, форматам и способам ее представления, изложенные выше в настоящем документе.
Помимо функциональных требований при разработке ТЗ (ЧТЗ) на Хранилище должны быть выработаны требования по персоналу, режимам функционирования, средствам восстановления информации после аварий, способам обеспечения информационной безопасности и защиты от несанкционированного доступа, показателям надежности, доступности и быстродействия, а также требования к различным видам обеспечения автоматизированной системы Хранилища – в первую очередь организационному, методическому и информационному.
В настоящее время государственные органы располагают огромным количеством информационных объектов, полученных в рамках госконтрактов, однако они нуждаются в каталогизации, упорядочении, приведению к единому формату представления. Эти работы не могут быть возложены на исполнителей по соответствующим проектам, особенно полностью завершенным. С другой стороны, госзаказчики не располагают необходимыми ресурсами и персоналом для выполнения этой работы.
В связи с этим предлагается в конкурсном порядке определить уполномоченного оператора Хранилища результатов работ, который взял бы на себя организацию и техническое исполнение соответствующих работ. Оператор от имени госзаказчиков должен быть наделен достаточными полномочиями для того, чтобы запрашивать у исполнителей работ дополнительную информацию, необходимую для приведения к единой форме, каталогизации, классификации, метаописания представленных ими материалов.
Работа по публикации накопленных материалов не может быть осуществлена в короткие сроки. В связи с этим возникает задача С этой целью имеющиеся в распоряжении государственных органов материалы предлагается подвергнуть экспресс-экспертизе и разбить на две группы:
содержащие явно востребованную и актуальную информацию, в первую очередь относящуюся к использованию эксплуатируемых госорганами информационных систем, к созданию технических нормативов, стандартизации и регламентации информационного обмена государства и граждан, планированию будущих работ и т.п.
все прочие, в т.ч. относящиеся к предварительным НИОКР по уже реализованным проектам, вышедшим из употребления информационным системам и т.п.
Порядок публикации материалов первой группы должен быть определен на основании более подробной экспертной оценки, исходя из их реальной значимости для государства и общества.
Прочие материалы могут не подвергаться дополнительной трудоемкой экспертизе, а обрабатываться и публиковаться по мере высвобождения ресурсов оператора в порядке, обратном хронологическому – т.е. более поздние (и потенциально более актуальные) результаты работ по госконтрактам обрабатываются и публикуются первыми.
Очевидно, что приведение информационных объектов, вновь создаваемых в рамках работ по госконтрактам, к единому, удобному для восприятия, анализа и использования формату, не должно являться обязанностью госзаказчика. Унификация документации и прочих передаваемых материалов должна осуществляться уже на стадии их разработки, т.е. силами исполнителей. Соответствующие требования должны быть зафиксированы в тексте госконтракта или приложений к нему – рабочих программ, заданий, календарных планов и т.п. Таким образом, первоочередной задачей по совершенствованию процедур представления результатов работ должно стать введение обязательного внутриведомственного нормоконтроля при заключении госконтракта. Его функции – проверка наличия и адекватности требований по документированию, форматам и порядку представления данных.
Однако вырабатывать соответствующие требования для каждого случая отдельно не рентабельно и не всегда возможно. Госзаказчик может просто не располагать специалистами в соответствующей предметной области (почему для выполнения работ и привлекается сторонний исполнитель в рамках госконтракта). Необходимо создание и публикация единого комплекса стандартов, регламентов и иной нормативно-технической документации, для которых существовали бы достаточно простые и четкие правила применения. Тогда госзаказчику будет достаточно просто включить в текст госконтракта ссылки на соответствующие документы и нормативы.
В связи с тем, что принятие новых стандартов на государственном уровне – достаточно сложная и длительная процедура, а техническое регулирование необходимо уже сейчас, на первоначальной стадии соответствующие требования и рекомендации могут вводиться в качестве внутриотраслевых нормативов или ведомственных инструкций – например, на основании приказа по министерству. С юридической точки зрения различия между ГОСТ, ОСТ и внутриведомственными документами не принципиальны – обязанность применения как тех, так и других возникает только вследствие включения такого требования в договор между сторонами.
Тем не менее, статус ГОСТ, несомненно, более весом и универсален. Кроме того, действующие ГОСТы и ОСТы обычно являются предметом изучения при подготовке технических специалистов в профильных ВУЗах и иных учебных заведениях, а практика применения таких нормативно-технических документов значительно шире. Как следствие, исполнители будут иметь лучшее понимание предъявляемых к ним требований и получат больше возможностей для качественного следования требованиям госзаказчика.
Приведенные ниже рекомендации по разработке новых стандартов относятся в основном к области ИТ, однако представляется очевидной необходимость провести аналогичную работу и в других областях, связанных с разработкой нематериальных имущественных объектов, например в рамках НИОКР в сфере гуманитарных наук и т.п.
Одной из важнейших проблем при подготовке договорной, проектной и рабочей документации является отсутствие стандартизированной терминологии по современным технологиям. Действующий ГОСТ 34.003-90 содержит только термины, относящиеся к достаточно узкой области автоматизированных систем, к тому же многие из них громоздки и не соответствуют сложившейся языковой практике. В силу сложившейся практики ИТ-специалисты используют главным образом английские термины, зачастую не имеющие русскоязычных аналогов, неоднозначно транскрибируемые или неудачно ложащиеся на морфологию русского языка. Все это привносит в документацию нежелательный сленговый окрас, затрудняет ее восприятие. Кроме того, толкование многих применяемых терминов неоднозначно и, напротив, одно и то же понятие часто обозначается разными терминами даже в пределах одного документа.
В связи с этим имеется насущная необходимость в разработке ряда глоссариев и словарей, которые, с одной стороны, дали бы адекватные российские синонимы для применяемых в международной практике терминов, с другой стороны, предоставили бы их единое толкование для юридических и технических целей.
Среди необходимых словарей сферы ИТ можно выделить:
терминологию области современных локальных сетей и сетевых архитектур;
терминологию области глобальных сетей, в первую очередь интернета;
терминологию области жизненного цикла программных средств и информационных систем;
терминологию области технологии знаний;
терминологию области управленческих систем и систем поддержки принятия решений;
терминологию графического интерфейса пользователя.
Как отмечалось выше, действующая система стандартов в области ИТ имеет отчетливый уклон в сторону автоматизированных систем, причем главным образом производственного класса (САПР, СУТП и т.п.). Однако интенсивное развитие информационной технологий приводит к проникновению информационно-компьютерных технологий в самые различные области человеческой деятельности, включая быт, досуг, масс-медиа и т.п. непромышленные сферы. Это вынуждает разработчиков и пользователей прибегать к расширительному толкованию понятия «автоматизированные системы», относя его к системам управления производственной и коммерческой деятельности, и к телекоммуникационным и информационно-справочным системам, к интернет-сайтам и порталам и т.д. В то же время принципы функционирования всех не могут быть сведены к простой автоматизации некоторых процессов, более того, многие из перечисленных систем не являются «автоматизирующими» в строгом смысле этого слова.
В связи с этим возникает потребность расширения понятийной сферы системы стандартов информационных технологий. Задача стандартов данной группы – введение четкой классификации и определение минимального набора функциональных задач и показателей назначения различных типов и классов информационных систем, в первую очередь систем обеспечения управленческой деятельности, таких, как ERP, CRM и т.п.
На настоящий момент в России принят стандарт ИСО 12207, регламентирующий жизненный цикл программных продуктов, однако многими специалистами отмечается сложность его применения на практике в силу чрезмерной универсальности. Необходима разработка ряда стандартов или, возможно, руководящих документов, увязанных со стандартом ИСО/МЭК 12207, и регламентирующий процедуры разработки, контроля и документирования для различных типов информационных систем.
В рамках этих стандартов, в частности, имеет смысл регламентировать такие общепринятые, но не находящие отражения в современной системе стандартов процедуры и стадии, как:
анализ информационных систем, построение моделей бизнес-процессов;
разработка пилотных версий и прототипов;
разработка комплексных решений на базе готовых программных продуктов;
адаптация ПО, включая локализацию и интернационализацию;
альфа- и бета-тестирование;
выпуск обновлений, совершенствование версий (апгрейд);
устранение ошибок и сбоев путем выпуска «заплаток» (патчей) и т.п.
В настоящее время ни на уровне официальных стандартов, ни на уровне практического применения в отрасли не существует методик объективной оценки таких важнейших нефункциональных показателей информационных систем, как:
производительность;
быстродействие;
объемы обрабатываемой информации;
надежность;
регламент функционирования;
интенсивность обслуживания;
эргономические показатели и удобство использования
В большинстве случаев при формулировке требований к системам эти параметры либо не регламентируются, либо, что равнозначно, устанавливаются эмпирически, «на уровне стандартных представлений о возможностях систем подобного рода».
Поскольку требования к информационным системам различного назначения могут оказаться весьма различными, предлагается разработать классификатор информационных систем по нефункциональным показателям, сходный, например, с применяемым Гостехкомиссией классификатором степени защиты систем от несанкционированного доступа. Это, в частности, позволит резко сократить затраты на разработку технических заданий и договоров и снизит вероятность двоякого понимания требований к системам у их заказчиков и разработчиков.
Необходимо также предложить унифицированную методологию оценки надежности информационных систем, усовершенствовать, расширить и осовременить существующие стандарты, устанавливающие виды испытаний АС (в частности, ГОСТ 34.603-92).
Заметные сложности для заказчиков и разработчиков информационных систем также порождает слаба регламентация процедур разработки технико-экономических обоснований, в первую очередь при государственной контрактации. На практике в качестве обоснования необходимости внедрения той или иной системы (технологии) приводятся соображения качественного порядка («упорядочение документооборота», «ускорение бизнес-процессов» и т.п.), при этом упускается из виду реальный экономический эффект и его соотношение с затратами на внедрение.
Стандарты, относящиеся к документированию информационных систем, на сегодня наиболее востребованы. Однако изучение практики их применения позволяет придти к неутешительным выводам:
серия стандартов ЕСПД (ГОСТ 19) заметно устарела, и лояльность разработчиков к ней связана исключительно с заложенной в идеологию стандарта свободой его применения. Так, разработчик документации имеет право на свое усмотрение вводить и исключать разделы документации, самостоятельно определять состав необходимых документов. При этом предложенная в стандарте структура и состав документов уже не соответствует реалиям современных программных технологий, будучи рассчитана на пакетные процедуры обработки данных. В результате использование стандартов ЕСПД сводится в основном к оформлению рамок и надписей на титульных листах.
стандарты по документированию серии 34 значительно более информативны, однако избегаются разработчиками в силу отмечавшегося выше перекоса в сторону производственной автоматизации, обилия разделов и документов, связанных с аппаратным обеспечением, и жестко фиксированной процедурой разработки систем, плохо ложащейся на современные технологии интенсивного проектирования.
нормы ИСО 12207 вызывают затруднения в силу их универсализма и размытости, а также сложности толкования.
В связи с этим предлагается подвергнуть кардинальной переработке стандарты серии ЕСПД, привязав их к требованиям ИСО 12207 и снабдив при этом конкретными указаниям по практическому применению (возможно, в форме Руководящего документа, подобного РД 50-34.698-90).
На то время, пока ведется разработка новых нормативно-технических документов, рекомендуется использовать стандарты и РД по документированию из 34 системы ГОСТ, как наиболее современные и, при разумном использовании, достаточно адекватные текущему состоянию информационных технологий. Они же могут послужить хорошей основой для создания нового комплекса стандартов.
Значительной проблемой при публикации исходных кодов является обеспечение их удобочитаемости. В связи с этим предлагается разработать ряд рекомендаций, регламентирующих следующие аспекты создания текстов программ:
использование единых принципов именования программных объектов;
минимальный уровень комментирования текста;
порядок описания программных интерфейсов приложений;
обеспечение автоматического документирования программ.
В качестве первичной основы для разработки таких стандартов могут служить приведенные в настоящем документе рекомендации.