14. Верификация и валидация – цели и задачи. V – модель как основа организации процесса верификации.

На каждом этапе разработки система подвергается тестиро­ванию. В этом разделе рассматриваются предпосылки и методы проведения тестирования. Следует учесть, что недостаточно пол­но протестированная система с большой долей вероятности бу­дет плохо функционировать, поэтому тестированию систем во всех компаниях, разрабатывающих АСОИУ, уделяется особое внимание. Тестирование и оценка работоспособности системы, которые обеспечивают подтверждение ее соответствия требова­ниям на функциональные и эксплуатационные свойства, а также соответствия требованиям к интерфейсу, называется валидацией системы. Одной из составляющих частей тестирования сис­темы является ее верификация на всех этапах разработки. Ве­рификация — это процесс определения соответствия системы на каждом этапе разработки требованиям, устанавливаемым на предыдущих этапах. Верификация, которая затрагивает вопросы соответствия функциональных требований системы выполняет­ся после формулирования функциональных требований к систе­ме и перед началом следующего этапа. После завершения этапа проектирования и перед переходом к следующему этапу выполняется верификация, целью которой является проверка соответствия разработанного программного обеспечения системы спецификациям качества функционирова­ния и функциональным требованиям к системе. После завершения этапа программирования и перед пере­ходом к следующему этапу выполняется верификация, целью которой является проверка степени проработанности создавае­мого программного обеспечения системы и соответствия спе­цификации качества функционирования системы, составленной на этапе проектирования. Таким образом, каждая фаза разработки системы должна завершаться процедурой верификации. На этапе проектирования, как и на этапе планирования, программного кода еще нет, поэтому и здесь тестируются толь­ко идеи. Однако на этом этапе идеи лучше формализованы и 139описаны намного подробнее, чем в первоначальных планах. Анализируя проектные документы, специалисты должны соста­вить четкое представление о работе будущей системы. Специалисты по тестированию могут и не участвовать в ра­боте группы аналитиков, однако для планирования системы бу­дущих тестов такое участие может быть необходимо. На сове­щаниях группы аналитиков специалистам по тестированию лучше всего быть пассивными участниками и высказываться только в случае необходимости. Одной из самых важных пред­посылок успешного тестирования является правильная поста­новка задачи. На этапе проектирования в центре внимания аналитиков должны быть следующие вопросы: • действительно ли проект хорош? Необходимо проана­лизировать возможность создания эффективного, компактного, хорошо тестируемого и легкого в сопровождении и модерниза­ции продукта; • соответствует ли проект требованиям? Проект дол­жен быть формализованным выражением требований, представ­ленных в документации этапа планирования; • полон ли проект? Следует выявить наличие в проекте описаний всех взаимосвязей между модулями и данными, усло­вий передачи данных между модулями и условий работы каждо­го модуля и их реализации; • достаточно ли он реалистичен? Необходимо рассмот­реть степень удовлетворенности имеющихся системных ресур­сов (как аппаратных, так и программных) потребностям проек­та, возможность достаточно быстрой работы программного про­дукта, а также быстрого извлечения информации из баз данных и ее обработки, выяснить, насколько удачно выбраны инстру­ментальные средства разработчиков; • хорошо ли описана в проекте подсистема обработки ошибок? Одной из ошибок разработчиков при нисходящем про­ектировании является желание оставить вопросы обработки ошибок, как самые незначительные, на завершающую стадию разработки системы. Однако о подобных элементах часто вообще забывают или же из-за нехватки времени они проектируются на­спех, поверхностно и в результате плохо. Все возможные условия возникновения ошибок должны быть самым тщательным образом продуманы и описаны в проекте. Важно правильно определить уровень, йа котором обрабатывается каждая из ошибок, чтобы ее возникновение в одном модуле не вело к ошибкам в других. В ходе тестирования на этапе проектирования могут быть проведены следующие совещания: • совещания аналитиков. Обычно целью совещаний, про­водимых при анализе проектных документов, является не реше­ние проблем, а прежде всего их выявление. В таком совещании должна участвовать небольшая группа сотрудников — около семи человек. В эту группу не должны входить авторы проекта. Аналитики заранее читают документы и на совещании крити­куют их и задают друг другу вопросы. Во многих компаниях информационная система вообще не считается завершенной, пока на нее не будет составлена фор­мальная рецензия (разумеется, одобрительная). Таким образом, проект перерабатывается и снова анализируется до тех пор, пока он не будет одобрен группой аналитиков. Совещания этой груп­пы могут быть трех типов: обзорные, инспекционные и рецензионные; - обзорное совещание, на котором проектировщики де­монстрируют модель программы. Шаг за шагом они показыва­ют, что делает программа с тестовыми данными, предложенны­ми аналитиками. Такая демонстрация позволяет увидеть, как взаимодействуют между собой различные части системы, и вы­явить ее недостатки (неудобные режимы, избыточность функ­ций или пропущенные детали); - инспекционное совещание, на котором специалисты под­робно анализируют каждый элемент проекта или его отдельный аспект (обработку ошибок, соответствие ранее выработанным стандартам, эффективность реализации конкретной функции и т.д.); - рецензионное совещание. К этому совещанию аналити­ки готовят список возникших у них вопросов. Они делятся своими соображениями и выделяют элементы проекта, которые показались им неточными или сомнительными. Цель этого совещания — сформировать список всех выявленных проблем и убедиться, что каждую из них проектировщики правильно поняли. Решение выявленных проблем в задачи совещания не входит. Идеальное рецензионное совещание должно направляться опытным в этом деле специалистом и обязательно документи­роваться. Такой специалист-организатор находит подходящее помещение, ведет совещание, останавливает оппонентов, когда они прерывают друг друга или отклоняются от темы, и готовит итоговый отчет. Он следит за тем, чтобы от обсуждения про­блем аналитики не переходили к обсуждению способов их ре­шения. Это будет сделано позднее меньшей группой специали­стов и вне рецензионного совещания. Специальный персонал записывает все важные замечания и с помощью проекторов или другой аналогичной техники выво­дит их на большой экран, где они видны каждому участнику со­вещания. Любой, кому покажется, что записывающий упустил нечто важное, может попросить отобразить эту информацию. Обязательно должно фиксироваться каждое достигнутое согла­шение. Записаны должны быть и все вопросы, которые остались открытыми до следующего совещания. Такая техника проведе­ния совещаний способствует их продуктивности, особенно ко­гда мнения аналитиков очень сильно расходятся. Некоторые группы тестирования специально обучают свой персонал ведению и протоколированию таких совещаний. Каче­ственное ведение протокола, способность выявить и зафиксиро­вать основные стороны дискуссии является важным фактором, влияющим на дальнейшее обсуждение выявленных проблем.

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