какие средства определяют требования при разработке внедрении и эксплуатации информационных
Какие средства определяют требования при разработке внедрении и эксплуатации информационных
НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ
РАЗРАБОТКА БЕЗОПАСНОГО ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
Information protection. Secure software development. General requirements
Дата введения 2017-06-01
Предисловие
1 РАЗРАБОТАН Закрытым акционерным обществом «Научно-производственное объединение «Эшелон» (ЗАО «НПО «Эшелон»)
2 ВНЕСЕН Техническим комитетом по стандартизации ТК 362 «Защита информации»
5ПЕРЕИЗДАНИЕ. Октябрь 2018 г.
Введение
Ввиду возрастающей сложности информационных систем актуальными становятся угрозы безопасности информации, связанные с наличием уязвимостей программ (уязвимостей кода), используемых в составе информационных систем. Для защиты от такого рода угроз в настоящее время, как правило, используют комплекс мер, реализуемый в процессах функционирования (эксплуатации) и сопровождения программного обеспечения. В то же время для обеспечения необходимого уровня защиты информации требуется реализация мер, направленных на предотвращение появления и устранение уязвимостей программ в процессах жизненного цикла программного обеспечения, связанных с проектированием, реализацией и тестированием.
Настоящий стандарт направлен на достижение целей, связанных с предотвращением появления и/или устранением уязвимостей программ, и содержит перечень мер, которые рекомендуется реализовать на соответствующих этапах жизненного цикла программного обеспечения.
1 Область применения
Настоящий стандарт устанавливает общие требования к содержанию и порядку выполнения работ, связанных с созданием безопасного (защищенного) программного обеспечения и формированием (поддержанием) среды обеспечения оперативного устранения выявленных пользователями ошибок программного обеспечения и уязвимостей программы.
Настоящий стандарт предназначен для разработчиков и производителей программного обеспечения, а также для организаций, выполняющих оценку соответствия процесса разработки программного обеспечения требованиям настоящего стандарта.
Настоящий стандарт можно применять в качестве источника для формирования мер и средств контроля и управления безопасностью программного обеспечения в соответствии с ГОСТ Р ИСО/МЭК 27034-1. Настоящий стандарт можно использовать для конкретизации или расширения компонентов доверия из ГОСТ Р ИСО/МЭК 15408-3.
2 Нормативные ссылки
В настоящем стандарте использованы нормативные ссылки на следующие стандарты:
ГОСТ 2.001 Единая система конструкторской документации. Общие положения
ГОСТ 19.101 Единая система программной документации. Виды программ и программных документов
ГОСТ 19.201 Единая система программной документации. Техническое задание. Требования к содержанию и оформлению
ГОСТ 19.402 Единая система программной документации. Описание программы
ГОСТ 19.404 Единая система программной документации. Пояснительная записка. Требования к содержанию и оформлению
ГОСТ Р ИСО/МЭК 15408-1- Информационная технология. Методы и средства обеспечения безопасности. Критерии оценки безопасности информационных технологий. Часть 1. Введение и общая модель
ГОСТ Р ИСО/МЭК 15408-2 Информационная технология. Методы и средства обеспечения безопасности. Критерии оценки безопасности информационных технологий. Часть 2. Функциональные компоненты безопасности
ГОСТ Р ИСО/МЭК 15408-3 Информационная технология. Методы и средства обеспечения безопасности. Критерии оценки безопасности информационных технологий. Часть 3. Компоненты доверия к безопасности
ГОСТ Р ИСО 10007 Менеджмент организации. Руководящие указания по управлению конфигурацией
ГОСТ Р ИСО/МЭК 12207 Информационная технология. Системная и программная инженерия. Процессы жизненного цикла программных средств
ГОСТ Р ИСО/МЭК 27001 Информационная технология. Методы и средства обеспечения безопасности. Системы менеджмента информационной безопасности. Требования
ГОСТ Р ИСО/МЭК 27034-1 Информационная технология. Методы и средства обеспечения безопасности. Безопасность приложений. Часть 1. Обзор и общие понятия
3 Термины и определения
В настоящем стандарте применены следующие термины с соответствующими определениями:
безопасность информации: Состояние защищенности информации, при котором обеспечены ее конфиденциальность, доступность и целостность.
3.2 безопасное программное обеспечение: Программное обеспечение, разработанное с использованием совокупности мер, направленных на предотвращение появления и устранение уязвимостей программы.
3.3 динамический анализ кода программы: Вид работ по инструментальному исследованию программы, основанный на анализе кода программы в режиме непосредственного исполнения (функционирования) кода.
3.4 документация разработчика программного обеспечения: Совокупность программных документов, предназначенных для организации работ по созданию программного обеспечения, выполняемых в рамках процессов жизненного цикла программного обеспечения, и/или подтверждения соответствия требованиям настоящего стандарта.
инструментальное средство: Компьютерная программа, используемая как средство разработки, тестирования, анализа, производства или модификации других программ или документов на них.
компьютерная атака: Целенаправленное несанкционированное воздействие на информацию, на ресурс автоматизированной информационной системы или получение несанкционированного доступа к ним с применением программных или программно-аппаратных средств.
3.7 недостаток программы: Любая ошибка, допущенная в ходе проектирования или реализации программы, которая в случае ее неисправления может являться причиной уязвимости программы.
3.8 объект среды разработки программного обеспечения: Аппаратные средства, программы, программно-аппаратные средства и документы, используемые разработчиком для разработки программного обеспечения.
3.9 пользователь (программного обеспечения): Лицо, применяющее программное обеспечение или участвующее в деятельности, прямо или косвенно зависящей от функционирования данного программного обеспечения.
программа: Данные, предназначенные для управления конкретными компонентами системы обработки информации в целях реализации определенного алгоритма.
программное обеспечение: Совокупность программ системы обработки информации и программных документов, необходимых для эксплуатации этих программ.
сетевая атака: Компьютерная атака с использованием протоколов межсетевого взаимодействия.
3.13 система управления конфигурацией программного обеспечения: Совокупность процедур и инструментальных средств (включая их документацию), используемая разработчиком программного обеспечения для разработки и поддержки конфигураций программного обеспечения в течение его жизненного цикла.
среда разработки программного обеспечения: Интегрированная система, включающая в себя аппаратные средства, программное обеспечение, программно-аппаратные средства, процедуры и документы, необходимые для разработки программного обеспечения.
3.15 статический анализ исходного кода программы: Вид работ по инструментальному исследованию программы, основанный на анализе исходного кода программы с использованием специализированных инструментальных средств (статических анализаторов) в режиме, не предусматривающем реального выполнения кода.
3.16 тестирование на проникновение: Вид работ по выявлению (подтверждению) уязвимостей программы, основанный на моделировании (имитации) действий потенциального нарушителя.
угроза (безопасности информации): Совокупность условий и факторов, создающих потенциальную или реально существующую опасность нарушения безопасности информации.
3.18 управление конфигурацией программного обеспечения: Скоординированные действия, направленные на формирование и контроль конфигурации программного обеспечения.
3.19 уязвимость программы: Недостаток программы, который может быть использован для реализации угроз безопасности информации.
3.20 функциональное тестирование программы: Вид работ по исследованию программы, направленный на выявление отличий между ее реально существующими и требуемыми свойствами.
3.21 фаззинг-тестирование программы: Вид работ по исследованию программы, направленный на оценку ее свойств и основанный на передаче программе случайных или специально сформированных входных данных, отличных от данных, предусмотренных алгоритмом работы программы.
3.22 экспертиза исходного кода программы: Вид работ по выявлению недостатков программы (потенциально уязвимых конструкций) в исходном коде программы, основанный на анализе исходного кода программы в режиме, не предусматривающем реального выполнения кода.
3.23 электронный документ: Документ, выполненный программно-техническим средством на электронном носителе.
Какие средства определяют требования при разработке внедрении и эксплуатации информационных
НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ
МЕТОДЫ И СРЕДСТВА ОБЕСПЕЧЕНИЯ БЕЗОПАСНОСТИ
Руководство по разработке профилей защиты и заданий по безопасности
Information technology. Security techniques. Guide for the production of Protection Profiles and Security Targets
Дата введения 2018-01-01
Предисловие
1 РАЗРАБОТАН Обществом с ограниченной ответственностью «Центр безопасности информации» (ООО «ЦБИ»)
2 ВНЕСЕН Техническим комитетом по стандартизации ТК 362 «Защита информации»
5 ВЗАМЕН ГОСТ Р ИСО/МЭК TO 15446-2008
Введение
Профиль защиты содержит взаимосвязанную информацию, имеющую отношение к безопасности ИТ, в том числе:
а) формулировку потребности в безопасности, соответствующую проблеме безопасности и выраженную в терминах, ориентированных на пользователей ИТ;
б) описание проблемы безопасности, уточняющее формулировку потребности в безопасности с учетом порождаемых средой угроз безопасности информации, которым нужно противостоять, политики безопасности организации, которая должна выполняться, и сделанных предположений;
в) цели безопасности ОО, основанные на описании проблемы безопасности и предоставляющие информацию относительно того, как и в какой мере должны быть удовлетворены потребности в безопасности. Предназначение целей безопасности заключается в том, чтобы снизить риск реализации угроз безопасности информации и обеспечить поддержание политики безопасности организации, в интересах которой ведется разработка ПЗ;
г) функциональные требования безопасности и требования доверия к безопасности, которые направлены на решение проблемы безопасности в соответствии с описанием проблемы безопасности и целями безопасности для ОО. Функциональные требования безопасности выражают то, что должно выполняться ОО для удовлетворения целей безопасности. Требования доверия к безопасности определяют степень уверенности в правильности реализации функций безопасности ОО;
д) обоснование, показывающее, что функциональные требования и требования доверия к безопасности являются соответствующими для удовлетворения сформулированной потребности в безопасности. Посредством целей безопасности должно быть показано, что необходимо сделать для решения проблемы безопасности. Функциональные требования безопасности должны удовлетворять целям безопасности.
Задание по безопасности (ЗБ) во многом похоже на ПЗ, но содержит дополнительную информацию, ориентированную на конкретную реализацию продукта ИТ и разъясняющую, каким образом требования ПЗ реализуются в конкретном продукте ИТ. Задание по безопасности содержит следующую дополнительную по отношению к ПЗ информацию:
а) краткую спецификацию ОО, которая представляет функции безопасности и меры доверия к безопасности для конкретного ОО;
б) утверждение о соответствии ЗБ одному или более ПЗ (если применимо);
в) материалы обоснования, устанавливающие, что краткая спецификация ОО обеспечивает удовлетворение требований безопасности, а любые утверждения о соответствии ПЗ действительны.
Профиль защиты может быть использован для определения типового набора требований безопасности, которым должны удовлетворять один или более продуктов ИТ. Профиль защиты может быть применен к определенному виду или типу продуктов (например, операционным системам, системам управления базами данных, межсетевым экранам, средствам антивирусной защиты, средствам контроля съемных машинных носителей информации, системам обнаружения вторжений и т.д.).
Поставщики продукта ИТ в соответствии с потребностями безопасности, сформулированными в ПЗ, могут разработать ЗБ, которое будет демонстрировать то, как их продукт ИТ удовлетворяет потребностям безопасности. Тем не менее соответствие задания по безопасности профилю защиты не всегда является обязательным (если не требуется при сертификации).
1 Область применения
Настоящий стандарт представляет собой руководство по разработке профилей защиты (ПЗ) и заданий по безопасности (ЗБ) в соответствии с комплексом стандартов ГОСТ Р ИСО/МЭК 15408.
Настоящий стандарт не предназначен для использования в качестве вводного материала по оценке безопасности продуктов ИТ в соответствии с ГОСТ Р ИСО/МЭК 15408. Для получения такой информации следует использовать ГОСТ Р ИСО/МЭК 15408-1.
В настоящем стандарте не рассматриваются вопросы, не связанные непосредственно со спецификацией ПЗ и ЗБ, например, такие как регистрация ПЗ и обращение с защищаемой интеллектуальной собственностью.
2 Нормативные ссылки
В настоящем стандарте использованы нормативные ссылки на следующие стандарты:
ГОСТ Р ИСО/МЭК 15408-1-2012 Информационная технология. Методы и средства обеспечения безопасности. Критерии оценки безопасности информационных технологий. Часть 1. Введение и общая модель
ГОСТ Р ИСО/МЭК 15408-2-2013 Информационная технология. Методы и средства обеспечения безопасности. Критерии оценки безопасности информационных технологий. Часть 2. Функциональные компоненты безопасности
ГОСТ Р ИСО/МЭК 15408-3-2013 Информационная технология. Методы и средства обеспечения безопасности. Критерии оценки безопасности информационных технологий. Часть 3. Компоненты доверия к безопасности
ГОСТ Р ИСО/МЭК 18045-2013 Информационная технология. Методы и средства обеспечения безопасности. Методология оценки безопасности информационных технологий
3 Термины и определения
В настоящем стандарте применены термины по ГОСТ Р ИСО/МЭК 15408-1.
4 Сокращения
В настоящем стандарте применены следующие обозначения:
5 Назначение и структура стандарта
Настоящий стандарт предназначен для использования при разработке профилей защиты (ПЗ) или заданий по безопасности (ЗБ), используемых при оценке продуктов ИТ в соответствии с комплексом стандартов ГОСТ Р ИСО/МЭК 15408. Настоящий стандарт представляет собой детальное руководство по разработке различных частей ПЗ или ЗБ и их взаимосвязи.
Настоящий стандарт предназначен в первую очередь для разработчиков ПЗ и ЗБ, а также может представлять интерес для потребителей и пользователей ПЗ и ЗБ, позволяя им понять, чем руководствовались разработчики ПЗ и (или) ЗБ при их разработке, и подтвердить актуальность и точность содержащейся в ПЗ и ЗБ информации. Также настоящий стандарт полезен для оценщиков ПЗ или ЗБ и для ответственных за контроль оценки ПЗ и ЗБ.
Предполагается, что пользователи настоящего стандарта ознакомлены с ГОСТ Р ИСО/МЭК 15408-1, в частности с приложениями А и В, в которых приведены спецификации ЗБ и ПЗ соответственно. Разработчикам ПЗ и ЗБ необходимо также быть ознакомленными и с другими частями ГОСТ Р ИСО/МЭК 15408, включая вводный материал, такой как парадигма функциональных требований безопасности, описанная в ГОСТ Р ИСО/МЭК 15408-2, раздел 5.
Предполагается, что настоящий стандарт полностью соответствует ГОСТ Р ИСО/МЭК 15408, тем не менее в случае любого несоответствия между настоящим стандартом и ГОСТ Р ИСО/МЭК 15408 последнему в качестве нормативного следует отдавать предпочтение.
Разделы 1-4 содержат вводные и ссылочные материалы.
В разделе 5 приведен обзор структуры и назначения настоящего стандарта.
Раздел 6 содержит вводную информацию по ПЗ и ЗБ; в нем дается общее представление о ПЗ и ЗБ и о том, в каких случаях и для чего они могут использоваться. В разделе 6 также рассмотрены взаимосвязь между ПЗ и ЗБ и вопросы, связанные с процессом их разработки.
В разделах 7-13 приведена информация по спецификации обязательных разделов ПЗ или ЗБ согласно структуре ПЗ и ЗБ, установленной в разделах А.2 и В.2 ГОСТ Р ИСО/МЭК 15408-1.
В разделе 14 рассмотрены вопросы разработки ПЗ и ЗБ для составных ОО, то есть ОО, которые состоят из двух или более ОО-компонентов, для каждого из которых имеются собственные ПЗ и (или) ЗБ.
Раздел 15 посвящен некоторым отдельным вопросам, а именно содержанию сокращенных ПЗ и ЗБ для низкого уровня доверия к безопасности, соответствию национальным ограничениям и интерпретациям, а также использованию функциональных пакетов и пакетов доверия к безопасности.
В приложении А приведен пример определения расширенного (по отношению к ГОСТ Р ИСО/МЭК 15408-2) компонента.
В приложении Б приведены примеры угроз, политики безопасности организации, предположений и целей безопасности, а также установлено соответствие между общими функциональными требованиями и соответствующими функциональными компонентами из ГОСТ Р ИСО/МЭК 15408-2.
6 Краткий обзор профилей защиты и заданий по безопасности
В данном разделе приведен краткий обзор роли ПЗ и ЗБ в процессе оценки безопасности продуктов ИТ в соответствии с комплексом стандартов ГОСТ Р ИСО/МЭК 15408.
Государственные информационные системы (ГИСы): практические вопросы защиты информации
Взаимодействие с государством активно переводится в интернет. Это не только упрощает многие процессы, но и накладывает определенную ответственность на пользователей, так как большинство государственных информационных систем обрабатывает персональные данные.
Защита ГИС — не равно защите персональных данных
В РФ существует порядка 100 государственных информационных систем, они подразделяются на федеральные и региональные. Организация, работающая с какой-либо из этих систем, обязана выполнять требования к защите данных, которые в ней обрабатываются. В зависимости от классификации, к разным информационным системам предъявляются разные требования, за несоблюдение которых применяются санкции — от штрафа до более серьезных мер.
Работа всех информационных систем в РФ определяется Федеральным законом от 27.07.2006 № 149-ФЗ (ред. от 21.07.2014) «Об информации, информационных технологиях и о защите информации» (27 июля 2006 г.). В статье 14 этого закона дается подробное описание ГИСов. К операторам государственных ИС, в которых ведется обработка информации ограниченного доступа (не содержащей сведений, составляющих государственную тайну), предъявляются требования, изложенные в Приказе ФСТЭК России от 11 февраля 2013 г. № 17 «Об утверждении требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах».
Напомним, что оператор — гражданин или юридическое лицо, осуществляющие деятельность по эксплуатации информационной системы, в том числе по обработке информации, содержащейся в ее базах данных.
Если организация подключена к государственной информационной системе, то приказ ФСТЭК № 17 обязывает аттестовать систему, а для защиты информации должны применяться только сертифицированные средства защиты информации (имеющие действующие сертификаты ФСТЭК или ФСБ).
Нередки случаи, когда оператор информационной системы ошибочно относит ее к ГИСам, в то время как она таковой не является. В итоге к системе применяются избыточные меры по защите. Например, если по ошибке оператор информационной системы персональных данных классифицировал ее как государственную, ему придется выполнить более жесткие требования к безопасности обрабатываемой информации, чем того требует закон. Тем временем требования к защите информационных систем персональных данных, которые регулирует приказ ФСТЭК № 21, менее жесткие и не обязывают аттестовать систему.
На практике не всегда понятно, является ли система, к которой необходимо подключиться, государственной, и, следовательно, какие меры по построению защиты информации необходимо предпринять. Тем не менее план проверок контролирующих органов растет, планомерно увеличиваются штрафы.
Как отличить ГИС от неГИС
Государственная информационная система создается, когда необходимо обеспечить:
Понять, что информационная система относится к государственной, можно, используя следующий алгоритм:
Если система подразумевает обмен информацией между госорганами, она также с высокой долей вероятности будет государственной (например, система межведомственного электронного документооборота).
Защитить информацию в ГИС и провести аттестацию помогут специалисты
Контур-Безопасность.
Это ГИС. Что делать?
Приказ ФСТЭК 17 предписывает проведение следующих мероприятий по защите информации к операторам ГИС:
Организации, которые подключены к государственным информационным системам, должны выполнить следующие действия:
1. Провести классификацию ИС и определить угрозы безопасности.
Классификация ИС проводится в соответствии с пунктом 14.2 17 приказа ФСТЭК.
Угрозы безопасности информации определяются по результатам
2. Сформировать требования к системе обработки информации.
Требования к системе должны содержать:
3. Разработать систему защиты информации информационной системы.
Для этого необходимо провести:
4. Провести внедрение системы защиты информации информационной системы, а именно:
5. Аттестовать ИСПДн:
Олег Нечеухин, эксперт по защите информационных систем, «Контур-Безопасность»
Не пропустите новые публикации
Подпишитесь на рассылку, и мы поможем вам разобраться в требованиях законодательства, подскажем, что делать в спорных ситуациях, и научим больше зарабатывать.
Какие средства определяют требования при разработке внедрении и эксплуатации информационных
Комплекс стандартов на автоматизированные системы
Information technology. Set of standards for automated systems. Automated systems. Stages of development
МКС 35.080
ОКСТУ 0034
Дата введения 1992-01-01
1. РАЗРАБОТАН И ВНЕСЕН Государственным комитетом СССР по управлению качеством продукции и стандартам
2. УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Постановлением Государственного комитета СССР по управлению качеством продукции и стандартам от 29.12.90 N 3469
4. ССЫЛОЧНЫЕ НОРМАТИВНО-ТЕХНИЧЕСКИЕ ДОКУМЕНТЫ
Обозначение НТД, на который дана ссылка
Номер пункта, приложения
6*. ПЕРЕИЗДАНИЕ. Июль 2009 г.
Стандарт устанавливает стадии и этапы создания АС.
В приложении 1 приведено содержание работ на каждом этапе.
1. ОБЩИЕ ПОЛОЖЕНИЯ
1.1. Процесс создания АС представляет собой совокупность упорядоченных во времени, взаимосвязанных, объединенных в стадии и этапы работ, выполнение которых необходимо и достаточно для создания АС, соответствующей заданным требованиям.
1.2. Стадии и этапы создания АС выделяются как части процесса создания по соображениям рационального планирования и организации работ, заканчивающихся заданным результатом.
1.3. Работы по развитию АС осуществляют по стадиям и этапам, применяемым для создания АС.
1.4. Состав и правила выполнения работ на установленных настоящим стандартом стадиях и этапах определяют в соответствующей документации организаций, участвующих в создании конкретных видов АС.
Перечень организаций, участвующих в работах по созданию АС, приведен в приложении 2.
2. СТАДИИ И ЭТАПЫ СОЗДАНИЯ АС
2.1. Стадии и этапы создания АС в общем случае приведены в таблице.
1. Формирование требований к АС
1.1. Обследование объекта и обоснование необходимости создания АС
1.2. Формирование требований пользователя к АС
1.3. Оформление отчета о выполненной работе и заявки на разработку АС (тактико-технического задания)
2. Разработка концепции АС
2.1. Изучение объекта
2.2. Проведение необходимых научно-исследовательских работ
2.3. Разработка вариантов концепции АС и выбор варианта концепции АС, удовлетворяющего требованиям пользователя
2.4. Оформление отчета о выполненной работе
3. Техническое задание
3.1. Разработка и утверждение технического задания на создание АС
4.1. Разработка предварительных проектных решений по системе и ее частям
4.2. Разработка документации на АС и ее части
5. Технический проект
5.1. Разработка проектных решений по системе и ее частям
5.2. Разработка документации на АС и ее части
5.3. Разработка и оформление документации на поставку изделий для комплектования АС и (или) технических требований (технических заданий) на их разработку
5.4. Разработка заданий на проектирование в смежных частях проекта объекта автоматизации
6. Рабочая документация
6.1. Разработка рабочей документации на систему и ее части
6.2. Разработка или адаптация программ
7.1. Подготовка объекта автоматизации к вводу АС в действие
7.2. Подготовка персонала
7.3. Комплектация АС поставляемая изделиями (программными и техническими средствами, программно-техническими комплексами, информационными изделиями)
7.4. Строительно-монтажные работы
7.5. Пусконаладочные работы
7.6. Проведение предварительных испытаний
7.7. Проведение опытной эксплуатации
7.8. Проведение приемочных испытаний
8. Сопровождение АС
8.1. Выполнение работ в соответствии с гарантийными обязательствами
8.2. Послегарантийное обслуживание
Допускается исключать стадию «Эскизный проект» и отдельные этапы работ на всех стадиях, объединять стадии «Технический проект» и «Рабочая документация» в одну стадию «Технорабочий проект». В зависимости от специфики создаваемых АС и условий их создания допускается выполнять отдельные этапы работ до завершения предшествующих стадий, параллельное во времени выполнение этапов работ, включение новых этапов работ.
ПРИЛОЖЕНИЕ 1
Справочное
1. На этапе 1.1 «Обследование объекта и обоснование необходимости создания АС» в общем случае проводят:
— сбор данных об объекте автоматизации и осуществляемых видах деятельности;
— оценку качества функционирования объекта и осуществляемых видов деятельности, выявление проблем, решение которых возможно средствами автоматизации;
— оценку (технико-экономической, социальной и т.п.) целесообразности создания АС.
2. На этапе 1.2 «Формирование требований пользователя к АС» проводят:
— подготовку исходных данных для формирования требований к АС (характеристика объекта автоматизации, описание требований к системе, ограничения допустимых затрат на разработку, ввод в действие и эксплуатацию, эффект, ожидаемый от системы, условия создания и функционирования системы);
— формулировку и оформление требований пользователя к АС.
3. На этапе 1.3 «Оформление отчета о выполненной работе и заявки на разработку АС (тактико-технического задания)» проводят оформление отчета о выполненных работах на данной стадии и оформление заявки на разработку АС (тактико-технического задания) или другого заменяющего ее документа с аналогичным содержанием.
4. На этапах 2.1 «Изучение объекта» и 2.2 «Проведение необходимых научно-исследовательских работ» организация-разработчик проводит детальное изучение объекта автоматизации и необходимые научно-исследовательские работы (НИР), связанные с поиском путей и оценкой возможности реализации требований пользователя, оформляют и утверждают отчеты о НИР.
5. На этапе 2.3 «Разработка вариантов концепции АС и выбор варианта концепции АС, удовлетворяющего требованиям пользователя» в общем случае проводят разработку альтернативных вариантов концепции создаваемой АС и планов их реализации; оценку необходимых ресурсов на их реализацию и обеспечение функционирования; оценку преимуществ и недостатков каждого варианта; сопоставление требований пользователя и характеристик предлагаемой системы и выбор оптимального варианта; определение порядка оценки качества и условий приемки системы; оценку эффектов, получаемых от системы.
6. На этапе 2.4 «Оформление отчета о выполненной работе» подготавливают и оформляют отчет, содержащий описание выполненных работ на стадии, описание и обоснование предлагаемого варианта концепции системы.
7. На этапе 3.1 «Разработка и утверждение технического задания на создание АС» проводят разработку, оформление, согласование и утверждение технического задания на АС и, при необходимости, технических заданий на части АС.
8. На этапе 4.1 «Разработка предварительных проектных решений по системе и ее частям» определяются: функции АС; функции подсистем, их цели и эффекты; состав комплексов задач и отдельных задач; концепции информационной базы, ее укрупненная структура; функции системы управления базой данных; состав вычислительной системы; функции и параметры основных программных средств.
9. На этапе 5.1 «Разработка проектных решений по системе и ее частям» обеспечивают разработку общих решений по системе и ее частям, функционально-алгоритмической структуре системы, по функциям персонала и организационной структуре, по структуре технических средств, по алгоритмам решений задач и применяемым языкам, по организации и ведению информационной базы, системе классификации и кодирования информации, по программному обеспечению.
11. На этапе 5.3 «Разработка и оформление документации на поставку изделий для комплектования АС и (или) технических требований (технических заданий) на их разработку» проводят: подготовку и оформление документации на поставку изделий для комплектования АС; определение технических требований и составление ТЗ на разработку изделий, не изготавливаемых серийно.
12. На этапе 5.4 «Разработка заданий на проектирование в смежных частях проекта объекта автоматизации» осуществляют разработку, оформление, согласование и утверждение заданий на проектирование в смежных частях проекта объекта автоматизации для проведения строительных, электротехнических, санитарно-технических и других подготовительных работ, связанных с созданием АС.
14. На этапе 6.2 «Разработка или адаптация программ» проводят разработку программ и программных средств системы, выбор, адаптацию и (или) привязку приобретаемых программных средств, разработку программной документации в соответствии с ГОСТ 19.101.
15. На этапе 7.1 «Подготовка объекта автоматизации к вводу АС в действие» проводят работы по организационной подготовке объекта автоматизации к вводу АС в действие, в том числе: реализацию проектных решений по организационной структуре АС; обеспечение подразделений объекта управления инструктивно-методическими материалами; внедрение классификаторов информации.
16. На этапе 7.2 «Подготовка персонала» проводят обучение персонала и проверку его способности обеспечить функционирование АС.
17. На этапе «Комплектация АС поставляемыми изделиями» обеспечивают получение комплектующих изделий серийного и единичного производства, материалов и монтажных изделий. Проводят входной контроль их качества.
18. На этапе 7.4 «Строительно-монтажные работы» проводят: выполнение работ по строительству специализированных зданий (помещений) для размещения технических средств и персонала АС; сооружение кабельных каналов; выполнение работ по монтажу технических средств и линий связи; испытание смонтированных технических средств; сдачу технических средств для проведения пусконаладочных работ.
19. На этапе 7.5 «Пусконаладочные работы» проводят автономную наладку технических и программных средств, загрузку информации в базу данных и проверку системы ее ведения; комплексную наладку всех средств системы.
20. На этапе 7.6 «Проведение предварительных испытаний» осуществляют: