Отчет № алт-1-04 о выполнении научно-исследовательской работы

Вид материала

Содержание

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

Подобный материал:

1 ... 28 29 30 31 32 33 34 35 ... 45

Часть 6. Технические требования к представлению и процедурам публикации материалов, полученных в качестве результатов работ по госконтрактам. Рекомендации

Введение

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

Приведенные ниже рекомендации основаны на практическом опыте использования и экспертизы результатов работ по госконтрактам, в т.ч. выполнявшихся в рамках целевых программ в области информационных технологий (ФЦП «Электронная Россия», ГЦП «Электронная Москва») и призваны служить основой для выработки конкретных требований к исполнителям работ по госконтрактам. В целом документ ориентирован на вновь создаваемые произведения и документы, однако в заключении также кратко рассмотрены вопросы о приведении к единому, удобному для применения виду и ранее полученных результатов работ, в т.ч. отчетной документации по завершенным госконтрактам.

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

Документ условно можно разбить на две основные части:

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

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

более комплексным рассмотрением программ для ЭВМ, как части автоматизированной системы (АС), т.е. «системы, состоящей из персонала и комплекса средств автоматизации его деятельности, реализующей информационную технологию выполнения установленных функций» (здесь и далее термины области АС даны по ГОСТ 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) Предметную часть - собственно набор исходных кодов или дистрибутив программного обеспечения (более подробно о способах представления программ см. п. ).

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