ГОСТ 34-й серии для сисадминов, начинающих фрилансеров и всех заинтересованных (часть 3)

Данная статья является третьей частью и продолжает рассмотрение ГОСТов 34й серии (часть 1, часть 2)

Теперь пришло время поговорить о шестой стадии разработки АС, а именно о стадии «Рабочая документация». Что же это за стадия такая? Как я заметил ранее во второй части, эта стадия настолько близка к стадии «Технический проект», что даже ГОСТ 34.601-90 при всей своей строгости допускает объединение этих стадий в одну «Техно-рабочий проект». В чем же между ними разница? Разница достаточно очевидная (как и родство): если на стадии «Технический проект» мы готовили комплект документов именно на проект АС как таковой, то на стадии «Рабочая документация» мы готовим комплект документов необходимых непосредственно для внедрения АС на конкретной площадке.

Что нам по этому поводу говорит ГОСТ? А говорит он нам следующее. В стадии «Рабочий проект» нам предлагают выполнить два этапа

• Разработка рабочей документации на систему и её части.
• Разработка или адаптация программ.

Опять документация на систему и ее части. Мы же делали это на стадии «Технический проект». Зачем нужно такое разделение? Давайте поразмышляем. Например, мы проектируем разворачивание Exchange. Будет ли разница между тем, как развернуть Exchange (в рамках проекта) на физическом сервере или виртуальном? Нет, не будет. А вот подготовка инфраструктуры для внедрения – это как раз то, чем занимается стадия «Рабочий проект». Т.е. по сути, перед нами алгоритм тиражирования. Мы уже имеем спроектированную систему и нам надо спроектировать, как ее поставить.

Если вернуться к моему любимому холодильнику, то на стадии «Технический проект» мы спроектировали холодильник, а на стадии «Рабочий проект» спроектировали куда его будем ставить. Вдруг заказчику надо их два? Например, один на кухне а другой в прихожей. Холодильник то будет один и тот же. А вот установка их будет несколько разная. На кухне мы его взяли и поставили, а в прихожей еще и нишу выдолбили и проводку протащили (не забыли, что в «Техническом проекте» мы спроектировали задачи на эти работы?).
Второй этап «Разработка или адаптация программ» подразумевает тоже самое, что я описал выше, но только для программных продуктов, которые идут в комплекте с разрабатываемой АС. Это может быть как разработка собственных программ, так и адаптация существующих. Например, мы обязаны обеспечить резервное копирование для поддержания уровня эксплуатационных характеристик (отказоустойчивость, живучесть и т.п.). Но на одной площадке мы используем, например, NTBackup, а на другой – HP Data Protection. Вот на этой стадии в этом этапе мы запроектируем эти моменты.

В итоге у нас будет комплект документов, который будет содержать (цитата из ГОСТа) все необходимые и достаточные сведения для обеспечения выполнения работ по вводу АС в действие и её эксплуатации, а также для поддержания уровня эксплуатационных характеристик (качества) системы в соответствии с принятыми проектными решениями, её оформление, согласование и утверждение. Виды документов по ГОСТ 34.201.

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

Завершив стадию «Рабочий проект» мы переходим к седьмой стадии «Ввод в действие». Мой опыт показывает, что в огромном числе проектов начало работы над проектом начинается именно с этой стадии. Чисто технический слад ума и некое противление «бумажной волоките» — вот те основные причины, чтобы сразу ринуться в бой. Надо внедрить Exchange? Давайте купим (скачаем) лицензию, купим сервер и поставим. Знакомо? А потом начинается «а почему тормозит? А почему при миграции простой был двое суток? А почему так быстро место для хранения кончилось? А почему…». А все это потому, что пропустили обоснование и проектирование. А так возник вопрос, достаем комплект документов и смотрим. Вот вы, говорите вы, говорили, что у ваших пользователей под почту уйдет не более 300мб объема. Мы с вами обсудили на этапе проектирования, что система хранения будет создана из расчета 500мб на одного пользователя. Вы с этим согласились, а так же с тем, что раз никто из ваших сотрудников не может назвать конкретную цифру, то мы исходим из предположения. А по факту у вас пользователи используют 2гб под хранение. Так что извините, но это не наш прокол, а ваши недостоверные сведения. Ну или как-то так. Облизываем заказчика по ситуации, само собой. Но факт фиксации момента есть. Уже легче.

Ладно. Двинулись дальше. Итак, стадия семь «Ввод в действие». Что тут замечательного и что нам предлагает выполнить ГОСТ? Смотрим:

• Подготовка объекта автоматизации к вводу АС в действие.
• Подготовка персонала.
• Комплектация АС поставляемыми изделиями (программными и техническими средствами, программно-техническими комплексами, информационными изделиями).
• Строительно-монтажные работы.
• Пусконаладочные работы.
• Проведение предварительных испытаний.
• Проведение опытной эксплуатации.
• Проведение приёмочных испытаний.

Первый этап «Подготовка объекта автоматизации». Наверное, самый мутный этап. Подразумевает, что мы должны подготовить то, что собираемся автоматизировать к вводу в действие автоматизированной системы. Я напишу, как я понимаю этот этап, но если что – меня поправьте. Так вот, я понимаю это так: если мы автоматизируем вид деятельности обмена почтовыми сообщениями, то готовим уже существующую систему к тому, что будет внедрена другая. Например, если мы делаем миграцию с Exchange 5.5 то т.с. «причесываем» его для миграции. Убираем ненужные почтовые ящики, разбираемся с ресурсами и т.д.
Этап второй «Подготовка персонала». Как мы помним, персонал бывает двух видов: эксплуатационный и обслуживающий. На этом этапе проводится необходимое обучение персонала и проверка того, что персонал понимает, с чем ему предстоит работать. Достаточно важный пункт. А то получите «а чего это вы мне тут фигню поставили?». Т.е. персонал должен еще до собственно нажимания кнопок знать что, зачем и почему.

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

Этап четвертый «Строительно-монтажные работы». Вот тут мы крутим серверные шкафы, тянем провода, рубим ниши и сверлим дырки. Набиваем стойки железом и срываем спины, перетаскивая УПС. Или не сами, а привлекаем субподрядчика.

Ниже мы рассмотрим несколько этапов, имеющих отношение к испытаниям. Более подробно мы их рассмотрим в конце статьи при рассмотрении ГОСТа 34.603-92

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

Этап шестой «Проведение предварительных испытаний». Здесь мы проверяем в общих чертах, что наша система функционирует. ГОСТ уточняет, что проведение подобного осуществляется согласно программе и методике испытаний. Теперь понимаете, зачем это надо? Для того, чтобы заказчик не стал юлить, мы с ним обговариваем как будем проводить испытание. Например, если это Exchange, то подключаем тестовый почтовый клиент, отправляем, получаем тестовые сообщения и т.п. Ну, или если вернуться к уже доставшему всех холодильнику, то положили в него пакет мороженого и если через сутки оно не растаяло, то предварительные испытания (а именно такую программу и методику мы согласовали ранее) считаются успешно пройденными. Если же нет, то устраняем обнаруженные недостатки, при необходимости вносим изменения в документацию, если в протоколе испытаний зафиксированы такие моменты. После этого ГОСТ предлагает подписать акт о передачи системы в опытную эксплуатацию. Акт нужен для того, чтобы закрыть этап. Иначе заказчик может начать юлить.

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

Этап восьмой «Проведение приемочных испытаний». Заключительная часть возни с АС. Проводится испытание на соответствие АС составленному ТЗ (на основании проведенных ранее испытаний). Опять же, тут пригождаются составленные ранее и утвержденные методики и программы испытаний. Помните, в первой части я писал о том, что проверка кластера на октазоустойчивость может быть проведена и выдергиванием шнура питания, а может и киданием гранаты в серверную? Поэтому незабываем согласовать методику (методики согласуются на стадиях ТЗ и/или Техпроекта) проведения испытаний. Разница проверок может быть в, например, проверяем кластер, что он вообще переключается при падении ноды, а потом проверяем на сколько это происходит быстро и соответствует ли эта скорость заявленному параметру в ТЗ, когда система в опытной эксплуатации и нагружена. И если все нормально, то АС ТЗ соответствует. После того, как все недостатки устранены и все счастливы, оформляется акт о передаче в постоянную эксплуатацию. Тут исполнитель имеет право наконец расслабиться и откланяться. Более подробно о испытаниях мы, повторюсь, поговорим в этой статье в самом конце при рассмотрении ГОСТа 34.603-92.

И наконец, мы добрались до стадии восьмой «Сопровождение АС». Тут ГОСТ предлагает нам выполнить следующие этапы:

• Выполнение работ в соответствии с гарантийными обязательствами.
• Послегарантийное обслуживание.

Тут все достаточно просто. По гарантии в течении гарантийного срока мы исправляем недостатки, которые будут выявлены за этот период. При необходимости вносим изменения в документацию на АС
Послегарантийное обслуживание, это достаточно интересный этап. Можно сказать, это дальнейший вариант выжать из заказчика еще немного денег. Мы собираем информацию, анализируем работу внедренной системы, ищем проявившиеся отклонения. И хотя ГОСТ предлагает заняться еще и устранением, это не обязательно должно быть бесплатно. Например, у заказчика отказала почтовая система из-за атаки вирусов. А т.к. в ТЗ какой либо защиты от вирусов не предусматривалось (заказчик махнул рукой «а, потом, а то дорого»), то мы предлагаем заказчику развернуть ему антивирусную защиту. А для этого давайте составим ТЗ на новый проект «Антивирусная защита почтовой системы предприятия»…

Так, с ГОСТом 34-601-90 разобрались, я надеюсь. Понятно, почему он основной и все вертится вокруг него? Надеюсь, что да. Теперь давайте, чтобы не плодить еще одну часть, рассмотрим оставшиеся ГОСТы за исключением ГОСТа на техническое задание. Ему я посвящу еще одну статью. Т.к. эти ГОСТы лишь дополняют ГОСТ 34-601-90, то все будет более лаконично.

Давайте рассмотрим следующие ГОСТы

• ГОСТ 34.003-90 Информационная технология. Комплекс стандартов на автоматизированные системы. Термины и определения
• ГОСТ 34.201-89 Информационная технология. Комплекс стандартов на автоматизированные системы. Виды, комплектность и обозначение документов при создании автоматизированных систем
• РД 50-34.698-90 Автоматизированные системы. Требования к содержанию документов.

Для лучшего понимания я приведу еще один рисунок. На нем мы увидим графическое представление вложенности ГОСТов

Вот такая вот получается вложенность. Что же мы тут видим для нас полезное? Ранее мы обсуждали стадии и этапы создания АС. Результатом выполнения стадий были пачки документов. А вот какие именно документы рекомендуется создавать согласно ГОСТ, мы можем почерпнуть из ГОСТа 34.201-89. ГОСТ делает важное уточнение «Состав видов документов, разрабатываемых на стадии «Исследование и обоснование создания АС» определяют в соответствии с разд.3 ГОСТ 24.601, исходя из требуемых результатов выполнения данной стадии». Интересно, но в ГОСТе 34.601-90 (который мы с вами рассматривали) и который пришел на смену ГОСТ 24.601-86 этого пункта почему-то нет. Или у меня не тот скан документа. Так вот, из этого пункта мы узнаем, что «Результатом выполнения стадии «Исследование и обоснование создания АС» является научно-технический отчет, тактико-техническое задание, технико-экономическое обоснование или заявка на создание АС». В общем, нечто, к АС отношение имеющее весьма отдаленное. Это и не мудрено. Т.к. полет мысли и работ в этих стадиях достаточно широк.

Открыв ГОСТ 34.201-89 можно посмотреть, какие документы требует составлять ГОСТ. Вот тут можно, наверное, с чистой совестью сказать спасибо, что требования следовать ГОСТу носят лишь рекомендательный характер. Ибо ГОСТ 34.201-89 разрешает лишь дополнять существующие документы, но никак не уменьшать их количество. В общем, в этом ГОСТе мы увидим возможные варианты документов, которые рекомендуется создавать на стадиях создания АС ГОСТ 34.601-90 (кроме первых двух, но о них я сказал ранее). А так же как необходимо оформлять документы. Можно с удивлением узнать, например, что пачка документов должна был зафиксирована в ведомости этих документов. Хотя, поразмышляв, найдем это весьма логичным. Ну и т.д. И еще раз скажем спасибо (смайлик).

Документов много, они разные с не всегда очевидными названиями. Да и к тому же я неоднократно встречал людей, которые не понимают, чем отличается регламент от инструкции или что-нибудь в том же духе. Чтобы в работе над проектом не возникало разночтений, существует следующий из рассматриваемых ГОСТов – РД 50-34.698-90. Наверное, самый либеральный ГОСТ из рассматриваемых. В общих положениях мы с удовольствием читаем «Допускается включать в документы дополнительные разделы и сведения, объединять и исключать разделы». Как говорится, это просто праздник какой-то. В этом ГОСТе мы можем найти описание тех документов, которые мы ходим создать на определенной стадии и посмотреть что это за документ, какой в нем смысл и как его составлять.

И, чтобы логически завершить тему документов, нам осталось лишь одно: определиться в терминологии. Ведь при написании документов мы используем термины, сокращения и т.п. Чтобы мы в нашей работе с заказчиком имели ввиду одно и тоже, рекомендуется использовать ГОСТ 34.003-90. По нему особо говорить нечего. Можно просто процитировать из общих положений «Настоящий стандарт устанавливает термины и определения основных понятий в области автоматизированных систем (АС) и распространяется на АС, используемые в различных сферах деятельности (управление, исследования, проектирование и т.п., включая их сочетание), содержанием которых является переработка информации. Настоящий стандарт не распространяется на системы, предназначенные для обработки (изготовления, сборки, транспортирования) любых изделий, материалов или энергии. Термины, установленные настоящим стандартом, обязательны для применения во всех видах документации и литературы по автоматизированным системам, входящих в сферу работ по стандартизации и использующих результаты этих работ и рекомендуются для применения в научно-технической, справочной и учебной литературе.»

Ну и, наконец, нам осталось в данной части рассмотреть последний на сегодня ГОСТ: ГОСТ 34.603-92 Информационная технология. Виды испытаний автоматизированных систем.

Зачем нужен этот ГОСТ? В общем положении этого ГОСТа дается очень важное определение «Испытания АС проводят на стадии «Ввода в действие» по ГОСТ 34.601 с целью проверки соответствия создаваемой АС требованиям технического задания (ТЗ)». В нем рассказывается о том, что мы обсуждали чуть ранее в стадиях создания АС. А именно процесс сдачи работы заказчику.

Давайте посмотрим, какие виды испытаний предлагает выполнить нам этот ГОСТ

1. Предварительные
2. Опытная эксплуатация
3. Приемочные

ГОСТ допускает проведение других видов испытаний АС и ее частей. Очень важный момент, указанный в ГОСТе «виды испытаний и статус приемочной комиссии устанавливают в договоре и(или) ТЗ». Что тут важного? Важного тут вот что: во-первых мы фиксируем виды испытаний (проверка кластера выдергиванием вилки из розетки) и приемочную комиссию. Это важно тем, что мы оговариваем, что принимать работу будет определенный круг лиц и заказчик не сможет притащить еще кого-нибудь. Мы имеем полное право отказаться сдавать работу неуполномоченному лицу.

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

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

2. ПРЕДВАРИТЕЛЬНЫЕ ИСПЫТАНИЯ
2.2. Автономные испытания
2.2.1. Автономные испытания АС следует проводить в соответствии с программой и методикой автономных испытаний, разрабатываемых для каждой части АС.
2.2.2. В программе автономных испытаний указывают:
1) перечень функции, подлежащих испытаниям;
2) описание взаимосвязей объекта испытаний с другими частями АС;
3) условия, порядок и методы проведения испытаний и обработки результатов;
4) критерии приемки частей по результатам испытаний.
2.2.3. Подготовленные и согласованные тесты (контрольные примеры) на этапе автономных испытаний должны обеспечить:
1) полную проверку функций и процедур по перечню, согласованному с заказчиком;
2) необходимую точность вычислений, установленную в ТЗ;
3) проверку основных временных характеристик функционирования программных средств (в тех случаях, когда это является существенным);
4) проверку надежности и устойчивости функционирования программных и технических средств.
2.2.4. В качестве исходной информации для теста рекомендуется использовать фрагмент реальной информации организации-заказчика в объеме, достаточном для обеспечения необходимой достоверности испытаний.
2.2.5 Результаты автономных испытаний частей АС следует фиксировать в протоколах испытаний. Протокол должен содержать заключение о возможности (невозможности) допуска части АС к комплексным испытаниям.
2.2.6. В случае, если проведенные автономные испытания будут признаны недостаточными, либо будет выявлено нарушение требований регламентирующих документов по составу или содержанию документации, указанная часть АС может быть возвращена на доработку и назначен новый срок испытаний.

2.3. Комплексные испытания
2.3.1. Комплексные испытания АС проводят путем выполнения комплексных тестов. Результаты испытаний отражают в протоколе. Работу завершают оформлением акта приемки в опытную эксплуатацию.
2.3.2. В программе комплексных испытаний АС или частей АС указывают:
1) перечень объектов испытания;
2) состав предъявляемой документации;
3) описание проверяемых взаимосвязей между объектами испытаний;
4) очередность испытаний частей АС;
5) порядок и методы испытаний, в том числе состав программных средств и оборудования, необходимых для проведения испытаний, включая специальные стенды и полигоны.
2.3.3. Для проведения комплексных испытаний должны быть представлены:
1) программа комплексных испытаний;
2) заключение по автономным испытаниям соответствующих частей АС и устранение ошибок и замечаний, выявленных при автономных испытаниях;
3) комплексные тесты;
4) программные и технические средства и соответствующая им эксплуатационная документация.
2.3.4. При комплексных испытаниях допускается использовать в качестве исходной информацию, полученную на автономных испытаниях частей АС.
2.3.5. Комплексный тест должен:
1) быть логически увязанным;
2) обеспечивать проверку выполнения функций частей АС во всех режимах функционирования, установленных в ТЗ на АС, в том числе всех связей между ними;
3) обеспечивать проверку реакции системы на некорректную информацию и аварийные ситуации.
2.3.6. Протокол комплексных испытаний должен содержать заключение о возможности (невозможности) приемки АС в опытную эксплуатацию, а также перечень необходимых доработок и рекомендуемые сроки их выполнения.
После устранения недостатков проводят повторные комплексные испытания в необходимом объеме.

4. ПРИЕМОЧНЫЕ ИСПЫТАНИЯ
4.1. Приемочные испытания проводят в соответствии с программой, в которой указывают:
1) перечень объектов, выделенных в системе для испытаний и перечень требований, которым должны соответствовать объекты (со ссылкой на пункты ТЗ);
2) критерии приемки системы и ее частей;
3) условия и сроки проведения испытаний;
4) средства для проведения испытаний;
5) фамилии лиц, ответственных за проведение испытаний;
6) методику испытаний и обработки их результатов;
7) перечень оформляемой документации.
4.2. Для проведения приемочных испытаний должна быть предъявлена следующая документация:
1) техническое задание на создание АС;
2) акт приемки в опытную эксплуатацию;
3) рабочие журналы опытной эксплуатации;
4) акт завершения опытной эксплуатации и допуска АС к приемочным испытаниям;
5) программа и методика испытаний. Приемочные испытания следует проводить на функционирующем объекте.
4.3. Приемочные испытания в первую очередь должны включать проверку:
1) полноты и качества реализации функций при штатных, предельных, критических значениях параметров объекта автоматизации и в других условиях функционирования АС, указанных в ТЗ;
4) средств и методов восстановления работоспособности АС после отказов;
5) комплектности и качества эксплуатационной документации.
4.4. Проверку полноты и качества выполнения функций АС рекомендуется проводить в два этапа.
На первом этапе проводят испытания отдельных функций (задач, комплексов задач). При этом проверяют выполнение требований ТЗ к функциям (задачам, комплексам задач). На втором этапе проводят проверку взаимодействия задач в системе и выполнение требований ТЗ к системе в целом.
4.5. По согласованию с заказчиком проверка задач в зависимости от их специфики может проводиться автономно или в составе комплекса. Объединение задач при проверке в комплексах целесообразно проводить с учетом общности используемой информации и внутренних связей.
4.6. Проверку работы персонала в диалоговом режиме проводят с учетом полноты и качества выполнения функций системы в целом.
Проверке подлежит:
1) полнота сообщений, директив, запросов, доступных оператору и их достаточность для эксплуатации системы;
2) сложность процедур диалога, возможность работы персонала без специальной подготовки;
3) реакция системы и ее частей на ошибки оператора, средства сервиса.
4.7. Проверка средств восстановления работоспособности АС после отказов ЭВМ должна включать:
1) проверку наличия в эксплуатационной документации рекомендаций по восстановлению работоспособности и полноту их описания;
2) практическую выполнимость рекомендованных процедур;
3) работоспособность средств автоматического восстановления функций (при их наличии).
4.8. Проверку комплектности и качества эксплуатационной документации следует проводить путем анализа документации на соответствие требованиям нормативно-технических документов и ТЗ.
4.9. Результаты испытаний объектов, предусмотренных программой, фиксируют в протоколах, содержащих следующие разделы:
1) назначение испытаний и номер раздела требований ТЗ на АС, по которому проводят испытание;
2) состав технических и программных средств, используемых при испытаниях;
3) указание методик, в соответствии с которыми проводились испытания, обработка и оценка результатов;
4) условия проведения испытаний и характеристики исходных данных;
5) средства хранения и условия доступа к конечной тестирующей программе;
6) обобщенные результаты испытаний;
7) выводы о результатах испытаний и соответствии созданной системы или ее частей определенному разделу требований ТЗ на АС.
4.10. Протоколы испытаний объектов по всей программе обобщают в едином протоколе, на основании которого делают заключение о соответствии системы требованиям ТЗ на АС и возможности оформления акта приемки АС в постоянную эксплуатацию.
Работу завершают оформлением акта о приемке АС в постоянную эксплуатацию.

На сегодня это все. Нам осталось сделать две вещи: обсудить ГОСТ на создание технического задания и сделать лабораторную работу.

Продолжение следует…

Автор: sudden_buben