Место верификации среди процессов разработки программного обеспечения

1.5. Ролевой состав коллектива разработчиков, взаимодействие между ролями в различных технологических процессах

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

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

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

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

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

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

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

Специалист по контролю качества. Эта роль принадлежит члену проектной группы, который осуществляет взаимодействие с разработчиком, менеджером программы и специалистами по безопасности и сертификации с целью отслеживания целостной картины качества продукта, его соответствия стандартам и спецификациям, предусмотренным проектной документацией. Следует различать специалиста по тестированию и специалиста по контролю качества. Последний не является членом технического персонала проекта, ответственным за детали и технику работы. Контроль качества подразумевает в первую очередь контроль самих процессов разработки и проверку их соответствия определенным в стандартах качества критериям.

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

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

Специалист по безопасности. Данный специалист ответственен за весь спектр вопросов безопасности создаваемого продукта. Его работа начинается с участия в написании требований к продукту и заканчивается финальной стадией сертификации продукта.

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

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

1.6. Задачи и цели процесса верификации

Сначала рассмотрим цели верификации. Основная цель процесса - доказательство того, что результат разработки соответствует предъявленным к нему требованиям. Обычно процесс верификации проводится сверху вниз, начиная от общих требований, заданных в техническом задании и/или спецификации на всю информационную систему, и заканчивая детальными требованиями к программным модулям и их взаимодействию. В состав задач процесса входит последовательная проверка того, что в программной системе:

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

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

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

На выбор эффективных методов верификации и последовательность их применения в наибольшей степени влияют основные характеристики тестируемых объектов:

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

Определим некоторые понятия и определения, связанные с процессом тестирования как составной части верификации. Майерс дает следующие определения основных терминов [2].

Тестирование - процесс выполнения программы с целью обнаружения ошибки.

Тестовые данные - входы, которые используются для проверки системы.

Тестовая ситуация (test case) - входы для проверки системы и предполагаемые выходы в зависимости от входов, если система работает в соответствии со спецификацией требований.

Хорошая тестовая ситуация - та ситуация, которая обладает большой вероятностью обнаружения пока еще необнаруженной ошибки.

Удачный тест - тест, который обнаруживает пока еще необнаруженную ошибку.

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

Отказ - непредсказуемое поведение системы, приводящее к неожидаемому результату, которое могло быть вызвано дефектами, содержащимся в ней.

Таким образом, в процессе тестирования программного обеспечения, как правило, проверяют следующее:

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

1.7. Тестирование, верификация и валидация - различия в понятиях

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

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

Рис. 1.7. Тестирование, верификация и валидация

Верификация программного обеспечения - более общее понятие, чем тестирование. Целью верификации является достижение гарантии того, что верифицируемый объект (требования или программный код) соответствует требованиям, реализован без непредусмотренных функций и удовлетворяет проектным спецификациям и стандартам. Процесс верификации включает в себя инспекции, тестирование кода, анализ результатов тестирования, формирование и анализ отчетов о проблемах. Таким образом, принято считать, что процесс тестирования является составной частью процесса верификации, такое же допущение сделано и в данном учебном курсе.

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

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