Приемочные испытания «по понятиям» и «по науке»
Приемка информационной системы, безусловно, апофеоз всего проекта создания информационной системы. Пусть Вас не обманывает цитата в начале статьи, мероприятие это важное и серьезное. Думаю, что это праздник для обеих сторон, но, как известно, чтобы праздник прошел хорошо, к нему надо хорошо подготовиться.
"А мы тут, знаете, всё плюшками балуемся..."
из мультфильма "Карлсон вернулся"
Приемка информационной системы, безусловно, апофеоз всего проекта создания информационной системы. Пусть Вас не обманывает цитата в начале статьи, мероприятие это важное и серьезное. Думаю, что это праздник для обеих сторон, но, как известно, чтобы праздник прошел хорошо, к нему надо хорошо подготовиться.
Начать стоит с формата проведения приемочных испытаний, хотя, скорее всего он уже давно был определен, например, в контракте или техническом задании. Тем не менее, я бы выделил два варианта проведения этого мероприятия и назвал их условно: приемка системы «по понятиям» и приемка системы «по науке». С первым все достаточно понятно, но описать такую процедуру невозможно. Это может быть полная формальность — веселые посиделки с бодрящими напитками или же настоящая вакханалия, где упоминание технического задания является чем-то неприличным и даже оскорбительным. А вот на втором варианте хотелось бы остановиться поподробнее, возможно данная статья приоткроет начинающим специалистам, а боюсь что и некоторым старым воякам, занавесу таинства приемочных испытаний. Постараюсь также дать несколько советов, чтобы испытания прошли более продуктивно.
Немного о стандартах. В далекие времена, будучи студентом, я, как и многие молодые люди своего поколения скептически относился с различным стандартам и руководствам СССР, при этом, даже не вникая в их суть. Но прошло совсем немного времени и здравый смысл взял вверх, не только сам применяю ГОСТы, но и рекомендую их к применению другим. Конечно, в ГОСТах 80-90-хх годах есть явные атавизмы, тем не менее, сравниваю их с уставом вооруженных сил, они что называется «на крови писались» и поверьте, там много здравых мыслей. Специалистов знающих ГОСТы, равно как и документы, оформленные в соответствии с ГОСТ и РД, видно издалека и отличаются они явно в лучшую сторону.
Приемочные испытания проводятся в соответствии с ГОСТ 34.603-92 «Информационная технология. Виды испытаний автоматизированных систем». Данный вид испытаний завершающий после предварительных испытаний и опытной эксплуатации. Цель данных испытаний — проверить соответствие автоматизированной системы требованиям Технического задания и сделать заключение о готовности Системы к вводу в постоянную эксплуатации.
Испытания проводятся по документу Программа и методикой приемочных испытаний (ПМИ). ПМИ разрабатывается с применением РД 50-34.698-90 «Автоматизированные системы. Требования к содержанию документов». Благодаря в первую очередь этому документу приемочные испытания «по понятиям» превращаются в приемочные испытания «по науке». ПМИ описывает все требования (функциональные и нефункциональные) Технического задания и ожидаемые результаты проверки.
Совет №1. ПМИ — это последний шанс для Заказчика повлиять на характеристики принимаемой информационной системы. Особенно если в ходе проекта разрабатывалось Техническое задание, которое в классическом понимании говорит «что делать» (цели и задачи, общие требования, требования к программному, техническому и документационному обеспечению, требования к персоналу и др.) и не разрабатывался Технический проект, который говорит «как делать» (конкретные технические решения по реализации конкретных требований Технического задания). Уделите достаточное время на разработку и согласование Программы и методики приемочных испытаний. Если хотите, это будет ваш устав на приемочных испытаниях.
Заказчику помимо согласования ПМИ не забыть издать приказ о составе приемочной комиссии, и каждого его члена под подпись ознакомить с ПМИ. Кого включать в комиссию — личное дело Заказчика. Рекомендую, чтобы в ней обязательно были:
- Функциональные заказчики
- Представители подразделений — ключевые пользователи Системы
- Представители технических подразделений, которые в дальнейшем будут обслуживать Систему
А также не были (относится к обеим сторонам):
- Слабонервные и неуравновешенные сотрудники
- Сотрудники не умеющие слушать и плохо выражающие свои мысли
- Внештатные сотрудники, представляющие компании конкурентов
Совет №2. Хотите, чтобы на приемочных испытаниях автоматизированной системы все было «по-взрослому»? Помимо проверки функциональных требований выполните:
- Развертывание программного обеспечения Системы «с нуля»
- Проверку заявленных временных показателей полного и частичного восстановления Системы
- Проверку быстродействия Системы путем замера времени выполнения ключевых функций, пусть и в монопольном режиме. Конечно, данные показатели должны быть изначально описаны в Техническом задании, или стороны будут обречены на спор, что есть «комфортное время» выполнения той или иной операции. Мое субъективное мнение уже много лет остается прежним — до 3 сек. на выполнение основных простых операций, далее нужно исходить из конкретной ситуации
- Проверку устойчивости и надежности Системы. Даже такого элементарного теста будет вполне достаточно – открываем интерфейсную форму внесения данных, выдергиваем сетевой шнур или разрываем соединение Wi-Fi, пытаемся сохранить данные, получаем адекватное сообщение, восстанавливаем соединение и повторяем попытку сохранения. Если это веб-приложение рекомендую проверять корректность повторной загрузки страниц, то есть после открытия той или иной формы/страницы, после выполнения команды сохранения данных и т.п., принудительно вызвать команду обновления (в браузерах это обычно клавиша F5)
- Проверку комплектности и качества документации. Лучше эту часть выполнить до начала испытаний, т.к. она требует достаточно много времени. Непосредственно на самих испытаниях озвучить результаты данной проверки
А вообще начните с проверки соответствия общесистемного программного (операционные системы, офисные пакеты, системы управления базами данных и др.) и технического обеспечения Системы (сервера, клиентские станции, каналы связи и др.) заявленным требованиям в Техническом задании. Несоответствия в этих пунктах может стать обоснованной причиной недостижения характеристик Системы заявленным показателям и даже полного невыполнения отдельных функций Системы.
Совет №3. Приемочные испытания проводите на контрольном наборе данных. В Систему должны быть в загружены данные как минимум сопоставимые с плановым объемом данных за первый год работы. Пусть это будет автоматически сгенерированная информация, качество контента тут не на первом месте. Если в процессе опытной эксплуатации необходимый объем данных уже был сформирован — отлично.
Совет №4. Часто в Технических заданиях пишется фраза «Система должна обеспечивать одновременную работу N пользователей». Исполнитель в первую очередь обеспечивает наличие необходимого количества конкурентных лицензий (если такая политика лицензирования предусмотрена). Не стесняйтесь спросить каким образом организационно или технически было обеспечено выполнение данного требования. Если были проведены нагрузочные испытания (в автоматизированном и/или ручном режиме), попросите предоставить протокол и программу проведения. Если данные тесты будут запущены прямо на испытаниях, честь и хвала Исполнителю.
По результатам проведения приемочных испытаний оформляется протокол (отчет) о результатах испытаний, в его составе может быть приложение с описанием выявленных замечаний и сроках их устранения (не забывайте об этом), а также акт технического состояния Системы и готовности ее приемки в промышленную эксплуатацию. Содержание данных документов также описано в РД 50-34.698-90 «Автоматизированные системы. Требования к содержанию документов».
После успешных испытаний по старой русской традиции новорожденную Систему нужно «обмыть», правда этого я так и не нашел ни в одном ГОСТе.
Оригинал статьи опубликован по адресу https://sedcom.ru/topic6.html
Похожие статьи
Комментарии 16
а почему не момент, когда она таки заработает? после приемки еще как минимум должно быть развертывание (пользователей обучить, ПО развернуть, данные загрузить и все такое) и опытно-промышленная эксплуатация. А по-хорошему еще +3 месяца промышленной эксплуатации (если про СЭД речь)...
Виктор, речь про любую АС. Вы путаете предварительные испытания и приемочные. Вот специально в статье написал, чтобы еще раз обозначить все виды испытаний:
Действительно перепутал. Прочитал сейчас оглавление ГОСТа http://www.gosthelp.ru/gost/gost30125.html... 80 видов испытаний имеется, как минимум в этом документе. Ужас.
В итоге относительно чего делать контроль? Современная динамика бизнеса требует быстрого и гибкого управлениям изменениями, а не фиксирования на первоначальной техническом задании.
Если внедряем по Agile, Scrum например применяем, то никакого ТЗ нет в принципе. Product backlog и User Stories - это наше все.
Ну и методики крупных вендоров/интеграторов, подтверждают аргументов. Например, ни в MS Dynamics Sure Step, ни в методиках вендоров СЭД (как минимум две знаю хорошо) такого нет.
Да Вы их не нюхайте, завязывайте с этой гадостью :) Вот Вы когда в процессе тестовой эксплуатации или опытной,что-то меняете вы где-то это фиксируете или все устно? :) А вот после того как реализовываете очередное требование (после зафиксированного ТЗ, или списка требований), каким образом "демонстрируете" его реализацию? А как Заказчик принимает решение о начале промышленной эксплуатации (тут понятно о чем речь, термин каждый свой любит)? Вообщем если ответов нет, то это путь в первый вариант "приемка по понятиям" (устно "по-пацански" договорится, по-быстрому "доточить", в обеденный перерыв "на бегу показать", а потом долго искать инициатора доработки и доказывать "мы ровно так и договаривались делать"), где-то это наверное уместно, но по мне так не пример для подражания и предмет для гордости.
Не вижу ни сложности ни рисков принятые решения запротоколировать, должностным лицам официально "достижения" продемонстрировать под подпись. Назовите эти мероприятия как вам нравится в соответствии с принятой методологией управления проектом, устава проекта, слово ГОСТ вообще не произносите, не пугайте никого :) Вы уже проводите аналогии с протоколированием истории разработки продукта, некой базой знаний и т.п. Итого: тот же смысл, "десиженсы" запротоколировать, "ивенты" провести, только более современными и модными словами, ок :)
...хотя нет, риски есть, при исполнении гос.контрактов и реализации сверх ТЗ могут Заказчика обвинить в "давлении", поэтому он и не любит протоколы связанные с изменением требований, хотя закон и позволяет изменить объем на 10%, правда и стоимость тоже :) Ну и тут можно найти "цивилизованный" выход...
Для водопада. Если в процессе сбора функциональных требований, проектирования, разработки, тестовой или опытной эксплуатации заказчик формулирует требования, которые следует трактовать как изменение "содержания проекта", то оформляется запрос на изменение, разумеется. Если это "рабочий момент", что-то уточнили или переформулировали - то все в протоколы. Дальше все зависит от фазы и управления проектом. Но в целом все единообразно - все вносится в текущие документы (их много, но ключевых у нас несколько - Функциональные требования, Проектные решения, Технический проект, Паспорт системы и т.д.).
Для Scrum. Тут все просто - на спринте никаких изменений.
Для водопада. Главный минус "классического" подхода во внедрении, как известно, сложный переход на шаг назад в этапах проекта. Но всегда есть "запасные пути". На тестовой эксплуатации предусматривается возможность нескольких итераций - на первой итерации проводим функциональное и нагрузочное тестирование. Выявляем ошибки/пожелания - все в журнал. Все поправили - вторая итерация, ровно так же и по той же программе. На опытно-промышленной также есть "запас" на "исправления". Первый месяц (условно) работаем - собираем проблемы/пожелания - все в журнал. Исправляем - и заказчик принимает исправления. Все просто.
А для этого в уставе проекта (иногда и в ТЗ) прописаны условия завершения ОПЭ. Обычно - отсутствие замечаний (в виде акта) и определенные количественные показатели (столько-то договоров прошло согласование и т.д.)
Ну тут да. Но что такое "Приемочные испытания" тогда? Это же не синоним "протоколирования". Если верить указанному ГОСТу - это финальная проверка на соответствие первоначальному ТЗ.
в силу ограниченности последнего (т.е. ТЗ), конечно.
Приемка по ПМИ, а не по ТЗ. А вот что вы отразите в ПМИ - ваше дело, были изменения к ТЗ отразите это и в ПМИ.
Не нравится ПМИ, ну назовите это "контрольный пример для проверки работоспособности АС" (только по ПМИ стороны могли проверить все аспекты Системы, вплоть до квалификации персонала), или назовите модным западным термином.
Думаю проблема в том,что все зацикливаются на том что ГОСТ это нечто старое, совковое. Я же предлагаю посмотреть на это более системно...
Итого, если резюмировать, то при завершении опытно-(промышленной) эксплуатации надо все проверить, что "все хорошо". И делать это осознано по заранее разработанному плану. Окей.
Теперь к плану (ПМИ). Ядро его не есть первоначальное ТЗ, хотя ГОСТ вроде как на это указывает.
А что такое план? "контрольный пример для проверки работоспособности АС"? Так а для чего тогда опытная эксплуатация у нас идет, скажем три месяца? Система уже работает в масштабе предприятия, уже собрали и устранили даже мелкие замечания пользователей. Зачем еще один контрольный пример, когда есть готовая и работающая система, к которой ни у рабочей группы, ни у пользователей нет замечаний?
В итоге ваше предложение не соответствует ни ГОСТу (я кстати ничего против него не имею, хороший артефакт), ну здравому экономическому смыслу. Ибо прогнать еще одно тестирование готовой системы можно, если не встанут два вопроса - зачем и кто за это заплатит...
Подробнее:http://ecm-journal.ru/post/Priemochnye-ispytanija-171po-ponjatijam187-i-171po-nauke187.aspx#comments
Да нет, не так. Просто время другое и работа у нас другая.
Раньше был заказчик в лице государства, был исполнитель (например НИИ какой-то), был бенефициар - завод какой-то. Заказчик конечно хотел, чтобы то что сделал исполнитель соответствовало первоначальным требованиям бенефициара. Иначе коррупция, не целевое расходование средств и все такое.
Вот новая контрактная система, которая идет на смену 94 ФЗ тоже хочет на выходе контролировать итог работ. Там, вероятно, потребуются "приемочные испытания" именно для заказчика. Для того и стандарты обновят со временем (в законодательстве таможенного союза такое уже есть для оборудования и машин). И заплатит за это сам заказчик, т.е. государство.
В теории такие же требования могут выставлять крупный бизнес. У того же Газпрома подобные процедуры описаны как обязательные, если внедрение контролирует "голова".
Так что я не категорически против, я за. Но как вынужденная мера когда без нее никуда.
Да, забыл. Ну и когда это вынужденна мера, то тогда строгое соответствие ГОСТу или другому регламенту, а не вольное "контрольный пример для проверки работоспособности АС", иначе смысл теряется.
Слава, зачем в СЭД эти ПИМИ? Мы же не космические корабли создаем. Тестовая эксплуатация все выявляет, а что не выявили на тестовой будет видно на опытно-промышленной. Ну не случится же катаклизмов из-за возможных ошибок в СЭД.
Ну давайте на пальцах:
1. Предварительные испытания. После них Система передается в опытную эксплуатацию (ОЭ). Проводятся для того чтобы на ОЭ при первом же клике у пользователей все "не рухнуло", или они после 1-2 шагов не обнаружили "тупики" (например отсутствие функции) и как следствие невозможность продолжать испытания. После испытаний - протокол, устранение замечаний и возможно, повторные испытания.
2. Опытная эксплуатация (еще ее называют тестовой), и опытно-промышленная эксплуатация. В любом случае для выявления и дальнейшего устранения замечаний, ошибок и т.п. Замечания, как правило, устраняются без остановки испытаний...
3. Приемочные испытания. После них Система сдается в постоянную эксплуатацию (без всяких приставок "опытно"), для этого нужно основание, протокол устранения замечаний ОЭ (ОПЭ) это конечно хорошо. Но в рамках ОЭ никто не проверяет абсолютно все характеристики Системы, например:
Это делает разработчик, конечно. Вот и получается, что Систему принимают "на веру".
Можно применять любые термины, идти в каком-то другом порядке, но цель то одна - чтобы пользователи "не мучились" с сырым продуктом ни до, ни после официального начала работы в Системе.
Одним словом, я уверяю всю общественность, если завтра вы напишите полную программу и методику приемочных испытаний, сядете с Заказчиком и 2 дня уделите приемке Вашей "уже принятой" Системы - вы нароете очень много интересного. Можно сказать что и проведя испытания еще раз, вы опять что-то нароете? :) Да, но уже в разы меньше! И рано или поздно все это "интересное" всплывет, но к горечи Заказчика уже не в рамках контракта создания Системы (а как уж тут себя Исполнитель поведет зависит только от него) :)
Самое главное, мои статьи во многом Заказчикам, а не Исполнителям. То есть я не "учу жить" никого, но если хоть одна компания обойдет хоть одни "грабли", которые описываются практически в каждом моем посыле - значит пару килобайт места этими статьями я занял не зря :)
Может и случиться, пусть не мировых масштабов, но неприятности для компании могут быть широкого спектра.
А почему вас это задевает?
Во-первых, изменение бизнес-процессов, это норма в современном мире. Они должны меняться.
Во-вторых, заказчик обращается к компании-внедренцу именно потому, что сам не знает, что именно ему нужно! Если бы он это знал, ему не нужна была бы ни коробочная система, ни компания-внедренец. Он вполне мог бы разработать и внедрить все сам. И если компания-внедренец не способна сказать заказчику что же именно ему нужно, то виноват не заказчик, а исполнитель.
Ну вот это как раз не факт. Знать, что надо и уметь реализовать это своими силами - не одно и то же. Заказать разработку может оказаться выгоднее для бизнеса как в конкретной ситуации, так и в долгосрочной перспективе.
Согласен. Но поле возможных решений на порядки шире, т.к. нет необходимости обращаться к поставщику решений для СЭД. Можно обратиться, например, к просто разработчику заказного ПО, коих многократно больше и они, как правило, дешевле.