Наверх

Приемочные испытания «по понятиям» и «по науке»

Время чтения: 6 минут
16
Приемочные испытания «по понятиям» и «по науке»

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

"А мы тут, знаете, всё плюшками балуемся..."
из мультфильма "Карлсон вернулся"

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

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

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

Приемочные испытания проводятся в соответствии с ГОСТ 34.603-92 «Информационная технология. Виды испытаний автоматизированных систем». Данный вид испытаний завершающий после предварительных испытаний и опытной эксплуатации. Цель данных испытаний — проверить соответствие автоматизированной системы требованиям Технического задания и сделать заключение о готовности Системы к вводу в постоянную эксплуатации.

Испытания проводятся по документу Программа и методикой приемочных испытаний (ПМИ). ПМИ разрабатывается с применением РД 50-34.698-90 «Автоматизированные системы. Требования к содержанию документов». Благодаря в первую очередь этому документу приемочные испытания «по понятиям» превращаются в приемочные испытания «по науке». ПМИ описывает все требования (функциональные и нефункциональные) Технического задания и ожидаемые результаты проверки.

Совет №1. ПМИ — это последний шанс для Заказчика повлиять на характеристики принимаемой информационной системы. Особенно если в ходе проекта разрабатывалось Техническое задание, которое в классическом понимании говорит «что делать» (цели и задачи, общие требования, требования к программному, техническому  и документационному обеспечению, требования к персоналу и др.) и не разрабатывался Технический проект, который говорит «как делать» (конкретные технические решения по реализации конкретных требований Технического задания). Уделите достаточное время на разработку и согласование Программы и методики приемочных испытаний. Если хотите, это будет ваш устав на приемочных испытаниях.

Заказчику помимо согласования ПМИ не забыть издать приказ о составе приемочной комиссии, и каждого его члена под подпись ознакомить с ПМИ. Кого включать в комиссию — личное дело Заказчика. Рекомендую, чтобы в ней обязательно были:

  • Функциональные заказчики
  • Представители подразделений — ключевые пользователи Системы
  • Представители технических подразделений, которые в дальнейшем будут обслуживать Систему

А также не были (относится к обеим сторонам):

  • Слабонервные и неуравновешенные сотрудники
  • Сотрудники не умеющие слушать и плохо выражающие свои мысли
  • Внештатные сотрудники, представляющие компании конкурентов

Совет №2. Хотите, чтобы на приемочных испытаниях автоматизированной системы все было «по-взрослому»? Помимо проверки функциональных требований выполните:

  • Развертывание программного обеспечения Системы «с нуля»
  • Проверку заявленных временных показателей полного и частичного восстановления Системы
  • Проверку быстродействия Системы путем замера времени выполнения ключевых функций, пусть и в монопольном режиме. Конечно, данные показатели должны быть изначально описаны в Техническом задании, или стороны будут обречены на спор, что есть «комфортное время» выполнения той или иной операции. Мое субъективное мнение уже много лет остается прежним — до 3 сек. на выполнение основных простых операций, далее нужно исходить из конкретной ситуации
  • Проверку устойчивости и надежности Системы. Даже такого элементарного теста будет вполне достаточно – открываем интерфейсную форму внесения данных, выдергиваем сетевой шнур или разрываем соединение Wi-Fi, пытаемся сохранить данные, получаем адекватное сообщение, восстанавливаем соединение и повторяем попытку сохранения. Если это веб-приложение рекомендую проверять корректность повторной загрузки страниц, то есть после открытия той или иной формы/страницы, после выполнения команды сохранения данных и т.п., принудительно вызвать команду обновления (в браузерах это обычно клавиша F5)
  • Проверку комплектности и качества документации. Лучше эту часть выполнить до начала испытаний, т.к. она требует достаточно много времени. Непосредственно на самих испытаниях озвучить результаты данной проверки

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

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

Совет №4. Часто в Технических заданиях пишется фраза «Система должна обеспечивать одновременную работу N пользователей». Исполнитель в первую очередь обеспечивает наличие необходимого количества конкурентных лицензий (если такая политика лицензирования предусмотрена). Не стесняйтесь спросить каким образом организационно или технически было обеспечено выполнение данного требования. Если были проведены нагрузочные испытания (в автоматизированном и/или ручном режиме), попросите предоставить протокол и программу проведения. Если данные тесты будут запущены прямо на испытаниях, честь и хвала Исполнителю.

По результатам проведения приемочных испытаний оформляется протокол (отчет) о результатах испытаний, в его составе может быть приложение с описанием выявленных замечаний и сроках их устранения (не забывайте об этом), а также акт технического состояния Системы и готовности ее приемки в промышленную эксплуатацию. Содержание данных документов также описано в РД 50-34.698-90 «Автоматизированные системы. Требования к содержанию документов».

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

Оригинал статьи опубликован по адресу http://sedcom.ru/topic6.html

Чтобы прочитать эту статью до конца,
или зарегистрируйтесь

Комментарии 16

Виктор Золотов 27 января 2014
Приемка информационной системы, безусловно, апофеоз всего проекта создания информационной системы

а почему не момент, когда она таки заработает? после приемки еще как минимум должно быть развертывание (пользователей обучить, ПО развернуть, данные загрузить и все такое) и опытно-промышленная эксплуатация. А по-хорошему еще +3 месяца промышленной эксплуатации (если про СЭД речь)...

Виктор, речь про любую АС. Вы путаете предварительные испытания и приемочные. Вот специально в статье написал, чтобы еще раз обозначить все виды испытаний:

Данный вид испытаний завершающий после предварительных испытаний и опытной эксплуатации.
Виктор Золотов 27 января 2014
Вы путаете предварительные испытания и приемочные

Действительно перепутал. Прочитал сейчас оглавление ГОСТа http://www.gosthelp.ru/gost/gost30125.html... 80 видов испытаний имеется, как минимум в этом документе. Ужас.

И в принципе в приемочных испытаниях есть смыл... Если мы за время опытной эксплуатации так все изменили (причем вместе с заказчиком), что итоговая система перестала удовлетворять требованиям (того же заказчика). 
Но реального применения при внедрении СЭД/ECM не вижу. Если только мы не перенесемся как раз в 80-е.
Аргументы (если внедряем водопадом):
  1. При формулировании ТЗ (до старта проекта) почти всегда нет даже адекватных функциональных требований бизнеса.
  2. Далее собираем ФТ. Меняется очень многое.
  3. Далее делаем проектные решения (не важно как называется - главное описываем как реализуем ФТ в конкретной ИС). Тоже что-то меняется относительно ФТ, ибо жизнь и разработчики вносят свои коррективы.
  4. Далее идем на тестовую и опытную эксплуатации. Бизнес вносит правки. На выходе снова что-то относительно новое.

В итоге относительно чего делать контроль? Современная динамика бизнеса требует быстрого и гибкого управлениям изменениями, а не фиксирования на первоначальной техническом задании.

Если внедряем по Agile, Scrum например применяем, то никакого ТЗ нет в принципе. Product backlog и User Stories - это наше все.

Ну и методики крупных вендоров/интеграторов, подтверждают аргументов. Например, ни в MS Dynamics Sure Step, ни в методиках вендоров СЭД (как минимум две знаю хорошо) такого нет.

P.S. ГОСТы СССР занятное чтение, реально создают атмосферу "тех лет", чувствуется прямо запах и гулкие шаги какого-нибудь коридора в НИИ метрологии и стандартизации...

Да Вы их не нюхайте, завязывайте с этой гадостью :) Вот Вы когда в процессе тестовой эксплуатации или опытной,что-то меняете вы где-то это фиксируете или все устно? :) А вот после того как реализовываете очередное требование (после зафиксированного ТЗ, или списка требований), каким образом "демонстрируете" его реализацию? А как Заказчик принимает решение о начале промышленной эксплуатации (тут понятно о чем речь, термин каждый свой любит)? Вообщем если ответов нет, то это путь в первый вариант "приемка по понятиям" (устно "по-пацански" договорится, по-быстрому "доточить",  в обеденный перерыв "на бегу показать", а потом долго искать инициатора доработки и доказывать "мы ровно так и договаривались делать"), где-то это наверное уместно, но по мне так не пример для подражания и предмет для гордости.

Не вижу ни сложности ни рисков принятые решения запротоколировать, должностным лицам официально "достижения" продемонстрировать под подпись. Назовите эти мероприятия как вам нравится в соответствии с принятой методологией управления проектом, устава проекта, слово ГОСТ вообще не произносите, не пугайте никого :) Вы уже проводите аналогии с протоколированием истории разработки продукта, некой базой знаний и т.п. Итого: тот же смысл, "десиженсы" запротоколировать, "ивенты" провести, только более современными и модными словами, ок :)

...хотя нет, риски есть, при исполнении гос.контрактов и реализации сверх ТЗ могут Заказчика обвинить в "давлении", поэтому он и не любит протоколы связанные с изменением требований, хотя закон и позволяет изменить объем на 10%, правда и стоимость тоже :) Ну и тут можно найти "цивилизованный" выход...

Виктор Золотов 27 января 2014
Вот Вы когда в процессе тестовой эксплуатации или опытной,что-то меняете вы где-то это фиксируете

Для водопада. Если в процессе сбора функциональных требований, проектирования, разработки, тестовой или опытной эксплуатации заказчик формулирует требования, которые следует трактовать как изменение "содержания проекта", то оформляется запрос на изменение, разумеется. Если это "рабочий момент", что-то уточнили или переформулировали - то все в протоколы. Дальше все зависит от фазы и управления проектом. Но в целом все единообразно - все вносится в текущие документы (их много, но ключевых у нас несколько - Функциональные требования, Проектные решения, Технический проект, Паспорт системы и т.д.).

Для Scrum. Тут все просто - на спринте никаких изменений.

каким образом "демонстрируете" его реализацию?

Для водопада. Главный минус "классического" подхода во внедрении, как известно, сложный переход на шаг назад в этапах проекта. Но всегда есть "запасные пути". На тестовой эксплуатации предусматривается возможность нескольких итераций - на первой итерации проводим функциональное и нагрузочное тестирование. Выявляем ошибки/пожелания - все в журнал. Все поправили - вторая итерация, ровно так же и по той же программе. На опытно-промышленной также есть "запас" на "исправления". Первый месяц (условно) работаем - собираем проблемы/пожелания - все в журнал. Исправляем - и заказчик принимает исправления. Все просто.

Для Scrum. В нем все четко прописано - каждый спринт заканчиваем демонстрацией работы user story.
А как Заказчик принимает решение о начале промышленной эксплуатации?

А для этого в уставе проекта (иногда и в ТЗ) прописаны условия завершения ОПЭ. Обычно - отсутствие замечаний (в виде акта) и определенные количественные показатели (столько-то договоров прошло согласование и т.д.)

Не вижу ни сложности ни рисков принятые решения запротоколировать

Ну тут да. Но что такое "Приемочные испытания" тогда? Это же не синоним "протоколирования". Если верить указанному ГОСТу - это финальная проверка на соответствие первоначальному ТЗ.

"полноты и качества реализации функций при штатных, предельных, критических значениях параметров объекта автоматизации и в других условиях функционирования АС, указанных в ТЗ;"
А пафос моего сомнения в том, что к завершению ОПЭ, ИС сравнивать с ТЗ бессмысленно, а силу ограниченности первого.
Виктор Золотов 27 января 2014
а силу ограниченности первого.

в силу ограниченности последнего (т.е. ТЗ), конечно.

А пафос моего сомнения в том, что к завершению ОПЭ, ИС сравнивать с ТЗ бессмысленно, а силу ограниченности первого.

Приемка по ПМИ, а не по ТЗ. А вот что вы отразите в ПМИ - ваше дело, были изменения к ТЗ отразите это и в ПМИ.

Итого: тот же смысл, "десиженсы" запротоколировать, "ивенты" провести, только более современными и модными словами, ок :)

Не нравится ПМИ, ну назовите это "контрольный пример для проверки работоспособности АС" (только по ПМИ стороны могли проверить все аспекты Системы, вплоть до квалификации персонала), или назовите модным западным термином.

Думаю проблема в том,что все зацикливаются на том что ГОСТ это нечто старое, совковое. Я же предлагаю посмотреть на это более системно...

Виктор Золотов 28 января 2014
были изменения к ТЗ отразите это и в ПМИ

Итого, если резюмировать, то при завершении опытно-(промышленной) эксплуатации надо все проверить, что "все хорошо". И делать это осознано по заранее разработанному плану. Окей.

Теперь к плану (ПМИ). Ядро его не есть первоначальное ТЗ, хотя ГОСТ вроде как на это указывает. 

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

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

Подробнее:http://ecm-journal.ru/post/Priemochnye-ispytanija-171po-ponjatijam187-i-171po-nauke187.aspx#comments 

Виктор Золотов 28 января 2014
на том что ГОСТ это нечто старое, совковое.

Да нет, не так. Просто время другое и работа у нас другая.

Раньше был заказчик в лице государства, был исполнитель (например НИИ какой-то), был бенефициар - завод какой-то. Заказчик конечно хотел, чтобы то что сделал исполнитель соответствовало первоначальным требованиям бенефициара. Иначе коррупция, не целевое расходование средств и все такое.

Вот новая контрактная система, которая идет на смену 94 ФЗ тоже хочет на выходе контролировать итог работ. Там, вероятно, потребуются "приемочные испытания" именно для заказчика. Для того и стандарты обновят со временем (в законодательстве таможенного союза такое уже есть для оборудования и машин). И заплатит за это сам заказчик, т.е. государство. 

В теории такие же требования могут выставлять крупный бизнес. У того же Газпрома подобные процедуры описаны как обязательные, если внедрение контролирует "голова".

Так что я не категорически против, я за. Но как вынужденная мера когда без нее никуда.

Виктор Золотов 28 января 2014
Так что я не категорически против, я за. Но как вынужденная мера когда без нее никуда.

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

Слава, зачем в СЭД эти ПИМИ? Мы же не космические корабли создаем. Тестовая эксплуатация все выявляет, а что не выявили на тестовой будет видно на опытно-промышленной. Ну не случится же катаклизмов из-за возможных ошибок в СЭД.

Ну давайте на пальцах:

1. Предварительные испытания. После них Система передается в опытную эксплуатацию (ОЭ). Проводятся для того чтобы на ОЭ при первом же клике у пользователей все "не рухнуло", или они после 1-2 шагов не обнаружили "тупики" (например отсутствие функции) и как следствие невозможность продолжать испытания. После испытаний - протокол, устранение замечаний и возможно, повторные испытания.

2. Опытная эксплуатация (еще ее называют тестовой), и опытно-промышленная эксплуатация. В любом случае для выявления и дальнейшего устранения замечаний, ошибок и т.п. Замечания, как правило, устраняются без остановки испытаний...

3. Приемочные испытания. После них Система сдается в постоянную эксплуатацию (без всяких приставок "опытно"), для этого нужно основание, протокол устранения замечаний ОЭ (ОПЭ) это конечно хорошо. Но в рамках ОЭ никто не проверяет абсолютно все характеристики Системы, например:

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

Это делает разработчик, конечно. Вот и получается, что Систему принимают "на веру".

Можно применять любые термины, идти в каком-то другом порядке, но цель то одна - чтобы пользователи "не мучились" с сырым продуктом ни до, ни после официального начала работы в Системе.

Одним словом, я уверяю всю общественность, если завтра вы напишите полную программу и методику приемочных испытаний, сядете с Заказчиком и 2 дня уделите приемке Вашей "уже принятой" Системы - вы нароете очень много интересного. Можно сказать что и проведя испытания еще раз, вы опять что-то нароете? :) Да, но уже в разы меньше! И рано или поздно все это "интересное" всплывет, но к горечи Заказчика уже не в рамках контракта создания Системы (а как уж тут себя Исполнитель поведет зависит только от него) :)

Самое главное, мои статьи во многом Заказчикам, а не Исполнителям. То есть я не "учу жить" никого, но если хоть одна компания обойдет хоть одни "грабли", которые описываются практически в каждом моем посыле  - значит пару килобайт места этими статьями я занял не зря :)

Anna Dolganova 25 августа 2014
Ну не случится же катаклизмов из-за возможных ошибок в СЭД.

Может и случиться, пусть не мировых масштабов, но неприятности для компании могут быть широкого спектра. 

Тестовая и ОЭ может не выявить узких мест в разработке. Как говорится, если дефект не найден - это не значит, что дефектов нет. По результатам такого тестирования будут отшлифованы основные сценарии использования - и этого вроде как достаточно. 
ИМХО все "подводные камни" знает в большинстве случаев только сам разработчик и рецензент, по коду гораздо проще отследить где могут возникнуть проблемы.
Меня лично больше задевает появление/изменение требований после окончания разработки - заказчик зачастую не понимает, что именно хочет. Известно, пользователь не знает, чего он хочет, пока не увидит то, что он получил. Но это уже больше касается технологии управления требованиями. А в рамках текущего контекста - первоначальные требования и все последующие изменения оных обязательно надо вести, с составлением сопутствующих сценариев использования. И приемочное проводить по этим требованиям, остальные пожелалки оценивать отдельно как по адекватности, так и по трудозатратам.
Михаил Романов 25 августа 2014
Меня лично больше задевает появление/изменение требований после окончания разработки - заказчик зачастую не понимает, что именно хочет.

А почему вас это задевает?

Во-первых, изменение бизнес-процессов, это норма в современном мире. Они должны меняться.

Во-вторых, заказчик обращается к компании-внедренцу именно потому, что сам не знает, что именно ему нужно! Если бы он это знал, ему не нужна была бы ни коробочная система, ни компания-внедренец. Он вполне мог бы разработать и внедрить все сам. И если компания-внедренец не способна сказать заказчику что же именно ему нужно, то виноват не заказчик, а исполнитель.

Андрей Подкин 25 августа 2014
Если бы он это знал, ему не нужна была бы ни коробочная система, ни компания-внедренец.

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

Михаил Романов 26 августа 2014
Знать, что надо и уметь реализовать это своими силами - не одно и то же.

Согласен. Но поле возможных решений на порядки шире, т.к. нет необходимости обращаться к поставщику решений для СЭД. Можно обратиться, например, к просто разработчику заказного ПО, коих многократно больше и они, как правило, дешевле.

Чтобы прокомментировать, или зарегистрируйтесь