Барри, руководитель по тестированию, вел семинар, участники которого проверяли спецификацию требований к ПО на наличие проблем. Во встрече принимали участие представители двух самых крупных классов пользователей, разработчик Джереми и аналитик Триш, которая написала спецификацию требований к ПО. В требовании 83 было указано: "Система обеспечит безопасность рабочих станций, подключенных к DMV, посредством отключения неактивных терминалов по истечении тайм-аута». Джереми представил группе свою интерпретацию этого требования: В требовании 83 говорится о том, что система автоматически отключит пользователя любой рабочей станции, подключенной к системе DMV, если на ней наблюдается бездействие в течение определенного периода времени».
«У кого-нибудь есть вопросы по этому требованию?» - поинтересовался Барри.
Первым высказался Хью-Ли, один из сторонников продукта. «Как система определяет, что терминал не активен? Это как появление заставки на мониторе: если в течение, ну, скажем, пяти минут мышь или клавиатура остаются в покое, то сеанс пользователя закрывается? Это может раздражать, например, когда пользователь просто отвлекся на разговор в течение этих пяти минут».
Триш добавила: «На самом деле в требовании ничего не говорится об отключении пользователя. Я не совсем понимаю, что означает "безопасность... по истечении тайм-аута». Я предположила, что это означает окончание сеанса, но, может, достаточно просто ввести пароль».
Джереми был также озадачен. «В этом требовании речь идет о любой рабочей станции, которая может подключиться к системе DMV или о рабочих станциях, которые активны и подключены к системе DMV в данный момент? О времени ожидания какой длины мы говорим? Возможно, существует некое руководство по безопасности для таких случаев?» Барри убедился, что секретарь точно зафиксировал все точки зрения. «Ну хорошо, похоже, что в требовании 83 есть несколько неясностей и не хватает некоторой информации, в частности, не определено время ожидания. Триш, не могла ли бы ты связаться с координатором отдела безопасности и решить этот вопрос?».
|
|
Большинству разработчиков знакомо чувство расстройства, возникающее, если их просят реализовать слишком неясные или неполные требования. Если они не могут получить необходимую информацию, они вынуждены ориентироваться на собственные предположения, которые не всегда верны. Потребуется много усилий, чтобы исправить ошибки в требованиях, работа над которыми уже завершена. Исследования показали, что в 100 раз дороже исправлять ошибки в требованиях, если на них указывает клиент, чем в процессе разработки этих требований (Boehm, 1981; Grady, 1999). Другие исследования свидетельствуют, что на исправление ошибки, выявленной на стадии работы над требованиями, тратится в среднем 30 минут, тогда как на исправление ошибки, выявленной в ходе тестирования системы, необходимо от 5 до 17 часов (Kelly, Sherif и Hops, 1992). Ясно, что любые усилия, затраченные на выявление ошибок в спецификации к требованиям, сэкономят реальные время и деньги.
Во многих проектах тестирование — одна из последних стадий проекта. Проблемы, связанные с требованиями, могут оставаться в продукте до тех пор, пока они не будут выявлены в ходе долгого тестирования системы или их не обнаружит клиент. Если вы начнете планирование тестирования и разработку вариантов тестирования на ранней стадии проекта, вы сможете обнаружить многие ошибки вскоре после их появления. При этом вы предотвратите дополнительный ущерб, наносимый ими, и снизите затраты на тестирование и обслуживание.
|
|
На рис. 15-1 показана V-образная модель разработки ПО, когда действия, связанные с тестированием и разработкой проекта выполняются параллельно (Davis, 1993). Эта модель указывает, что приемочные испытания основывается на требованиях пользователей, тестирование системы — на функциональных требованиях, а тестирование целостности — на архитектуре.
Рис. 15-1. V-образная модель разработки ПО подразумевает планирование и разработку тестирования на ранней стадии проекта
Планируйте мероприятия по тестированию и начинайте разработку предварительных вариантов тестирования для соответствующего этапа разработки. В процессе разработки требований вы не можете проводить никаких тестов, так как никакого ПО еще нет. Однако концептуальные (то есть, не зависящие от реализации) варианты тестировании, созданные на основе требований, позволят выявить ошибки, неясности и пропуски данных в спецификации требований к ПО и проанализировать модели задолго до того, как разработчики приступят к написанию кода.
Утверждение требований является четвертым этапом — наряду со сбором информации, анализом и созданием спецификации — разработки требований (Abran и Moore, 2001). [6] Утверждение требований позволяет удостовериться в том, что:
|
|
· в спецификации требований к ПО должным образом описаны предполагаемые возможности и характеристики системы, которые удовлетворят потребности различных заинтересованных в проекте лиц;
· требования к ПО точно отражают системные требования, бизнес-правила и др.;
· требования полные и высококачественные;
· все требования согласованы друг с другом;
· требования обеспечивают качественную основу для дизайна и сборки ПО.
Проверка подтверждает, что в документе представлены желаемые характеристики отличных требований (полные, корректные, осуществимые, необходимые, приоритетные, ясные и поддающиеся проверке) и отличных спецификаций к требованиям (полные, согласованные, модифицируемые и поддающиеся отслеживанию). Разумеется, вы можете утвердить только задокументированные требования, а не предполагаемые, которые существуют только в чьем-то воображении.
Утверждение — это не один отдельный этап процесса, выполняемый после сбора и документирования требований. Некоторые проверочные мероприятия, например просмотр все более разрастающейся спецификации требований к ПО, выполняются после каждой процедуры сбора информации, ее анализа и документирования. Другие мероприятия, такие, как официальная проверка спецификации требований к ПО, обеспечивают достижение того уровня качества, которое предшествует финальной версии спецификации. Включите в план проекта этапы утверждения требований в качестве отдельных задач,
Участники проекта иногда с неохотой тратят время на проверку и тестирование спецификации требований к ПО. Интуитивно кажется, что если выделить время на улучшение качества требований, дата выпуска продукта задержится на такой же срок. Однако при таком отношении вы можете смело ожидать нулевых результатов от всех усилий, затраченных на утверждение. В действительности же эти усилия могут сократить график поставки, за счет уменьшения требуемых исправлений и ускорения интеграции и тестирования системы (Blackburn, Scudder и Van Wassenhove, 1996). Capers Jones (1994) отмечает, что каждый доллар, который вы истратили на предотвращение появления дефектов, снизит затраты на исправление на сумму от 3 до 10 долларов. Чем лучше требования, тем выше качество продукта и тем более доволен клиент, что в свою очередь снизит затраты на обслуживание, улучшение и клиентскую поддержку продукта. Инвестируя в качество продукта, вы сохраните больше денег, чем потратили.
Для оценки корректности и качества требований применяйте различные приемы (Wallace и Ippolito, 1997). Один из таких приемов заключается в измерении каждого требования, с тем чтобы вы смогли продумать способ измерения того, насколько хорошо предложенное решение. Suzanne и James Robertson используют термин критерий годности (fit criteria) для подобных приемов (Robertson и Robertson, 1999). В этой главе рассматриваются приемы проверки официальных и неофициальных просмотров требований, разработки вариантов тестирования на основании требований и определения клиентом критериев приемлемости продукта.
Просмотр требований
Всякое исследование продукта ПО на предмет выявления проблем любым другим лицом, кроме его автора, называется экспертной оценкой (peer review). Просмотр задокументированных требований — это эффективный прием выявления неясных или не поддающихся проверке требований, требований, которые были определены недостаточно ясно для разработки, а также других проблем.
Различные типы экспертных оценок называются по-разному (Wiegers, 2002a). Неофициальные просмотры полезны при знакомстве людей с продуктом и сборе отзывов о нем (формирование обратной связи). Однако они несистематические, неполные и несогласованные. Есть несколько видов неофициальных просмотров требований:
· проверка «за столом», когда вы просите одного коллегу исследовать ваш продукт;
· коллективная проверка, когда вы приглашаете несколько коллег для параллельной проверки продукта;
· критический анализ, когда автор описывает создаваемый продукт и просит его прокомментировать.
В отличие от нарочито естественных неформальных просмотров, официальная проверка представляет собой строго регламентированный процесс. По его завершении формируется отчет, в котором указаны материал, рецензенты и мнение команды рецензентов о приемлемости продукта. Главный результат — совокупность всех найденных дефектов и поднятых вопросов. Члены команды, которая выполняет официальный просмотр продукта, делят ответственность за качество проверки, хотя в конце концов за качество продукта отвечают все-таки его создатели (Freedman и Weinberg, 1990).
Наиболее хорошо себя зарекомендовавшая себя форма официальной оценки называется экспертизой (Gilb и Graham, 1993; Radice, 2002). Возможно, инспектирование документации требований — наиболее действенный из доступных приемов проверки качества ПО. Несколько компаний сэкономили ни много ни мало — целых 10 часов труда на каждый час, потраченный на инспектирование документации требований и других готовых к поставке продуктов (Grady и Van Slack, 1994). Инвестиции в проверки вернутся 1000% выгоды, если вы, конечно, не отнесетесь к ним небрежно.
Если вы серьезно решили совершенствовать качество вашего ПО, то ваша команда должна проверить каждый написанный документ, касающийся требований. Детальная проверка объемной документации может быть скучной и долгой. Однако все мои знакомые, кто занимался экспертизой требований, соглашаются, что каждая минута была потрачена не зря. Если у вас не хватает времени на проверку каждой детали, воспользуйтесь рискованными методами анализа: выберите требования, для проверки которых достаточно неофициального просмотра. Начинайте экспертизу спецификации требований к ПО, когда требования разработаны еще примерно на 10%. Выявление значительных дефектов на ранней стадии и систематических проблем в процессе написания требований является отличным способом предотвращения — а не только выявления — ошибок.
| Чем тщательнее присматриваешься, тем больше замечаешь В Chemical Tracking System представители пользователей проводили неофициальный просмотр последней версии спецификации требований после каждого семинара, посвященного сбору информации. Таким образом удавалось выявить множество ошибок. После завершения сбора информации, один аналитик свел всю информацию, полученную от всех классов пользователей в одну спецификацию требований к ПО (50 страниц плюс несколько приложений). Затем два аналитика, один разработчик, три сторонника продукта, менеджер проекта и один тестировщик проверили этот документ за три двухчасовых совещания, проведенных в течение недели. Они обнаружили 233 дополнительные ошибки, в том числе несколько серьезных дефектов. Все проверяющие согласились, что время, потраченное на «прочесывание» спецификации (по одному требованию за раз) сэкономило несчетное количество часов в дальнейшем. |
Проведение экспертизы
Экспертиза была разработана Майклом Фэганом (Michael Fagan) из IIBM в середине 70-х гг. (Fagan, 1976), а другие дополнили и модифицировали его методы (Gilb и Graham, 1993). Экспертиза была признана лучшим приемом в области разработки ПО (Brown, 1996). Этот метод, годится для проверки любого продукта, в том числе документации требований и дизайна, исходного кода, документации тестирования и планов проекта.
Экспертиза — это четко определенный многоэтапный процесс. В нем участвует небольшая команда квалифицированных специалистов, которые тщательно проверяют продукт на наличие дефектов и изучают возможности улучшения. Экспертиза обеспечивает уровень качества продукта, предшествующий окончательному. Иногда возникают дебаты, действительно ли метод Фэгана можно считать лучшей формой проверки (Glass, 1999), однако ни у кого не возникает сомнений, что экспертиза является мощным приемом повышения качества продукта. Множество полезных советов по проведению экспертной оценки и экспертизы опубликовано на https://www.processimpact.com/goodies.shtml, в том числе описание процесса экспертной оценки, контрольные списки дефектов и формы экспертизы.
Участники
Участники инспектирования должны отражать четыре точки зрения на продукт (Wiegers, 2002а).
· Автор продукта и, возможно, коллеги автора. Это может быть аналитик, составивший документацию требований.
· Автор любого предыдущего продукта или спецификации для элемента, который следует проверять. В этой роли может выступить системный инженер или архитектор, который способен подтвердить, что в спецификации требований к ПО система описана достаточно детально. При отсутствии спецификации более высокого уровня в экспертизе должны принять участие представители клиента для того, чтобы подтвердить, что требования в спецификации требований к ПО описаны правильно и полно.
· Люди, которые будут выполнять работу, основанную на проверяемом элементе. Для экспертизы спецификации требований к ПО вы можете привлечь разработчика, тестировщика, менеджера проекта, а также составителя пользовательской документации. Они будут выявлять наличие проблем различных типов. Требование, которое не поддается проверке, скорее всего сможет выявить тестировщик, а разработчик сумеет определить требования, которые технически невыполнимы.
· Люди, отвечающие за работу продуктов, взаимодействующих с проверяемым элементом. Они выявят проблемы с требованиями к внешнему интерфейсу. Они также могут выявить требования, изменение которых в проверяемой спецификации влияет на другие системы (волновой эффект).
· Постарайтесь ограничить команду шестью членами или меньше. Это означает, что некоторые точки зрения не будут представлены при каждой проверке. Большие команды могут легко увязнуть в посторонних дискуссиях, попытках решения проблем и дебатов о том, что считать ошибкой. При этом снижается темп проверки и растет стоимость обнаружения каждого дефекта.
Роли экспертов
Все участники экспертизы, включая автора, ищут недостатки и возможности улучшения. Отдельные участники при этом играют различные роли.
Автор. Автор создает или поддерживает проверяемый продукт. В роли автора спецификации требований к ПО, как правило, выступает аналитик, который осуществлял сбор требований клиента и писал спецификацию. В ходе неофициальных проверок, таких, как критический анализ, именно автор часто возглавляет дискуссию. Однако в экспертизе он принимает более пассивное участие. Он может не брать на себя обязанности других участников — координатора, читателя или секретаря. Поскольку автор не принимает активное участие и, следовательно, оставляет самолюбие за дверью, он имеет возможность выслушать других участников инспектирования, ответить — но не вступать в дебаты — на их вопросы и поразмыслить. Зачастую автору удается обнаружить ошибки, не замеченные другими участниками.
Координатор. Координатор, или руководитель проверки, планирует экспертизу совместно с автором, согласовывает особенности и организует совещания. Координатор распределяет проверяемый материал между участниками за несколько дней до совещания. Он отвечает за своевременное начало совещаний, поощрение вклада каждого участника и управление дискуссией, которая должна быть направлена на выявление дефектов, а не на решение проблем. Кроме того, в его обязанности входит информировать менеджеров или того, кто занимается сбором результатов различных экспертиз, о результатах. Координатор также работает вместе с автором над предложенными изменениями, чтобы все дефекты и проблемы, поднятые в ходе инспектирования, были рассмотрены должным образом.
Читатель. Один из проверяющих выступает в роли читателя. На совещании он перефразирует положения спецификации — по одному требованию за раз. Затем другие участники указывают на потенциальные дефекты и проблемы. Выражая требование своими словами, читатель дает трактовку требования, которая может отличаться от интерпретации других членов команды. Это хороший способ выявления неясностей, возможных недостатков или предположений. При этом важно, чтобы роль читателя выполнял не автор.
Секретарь. Секретарь, или клерк, использует стандартные формы для документирования возникающих вопросов и дефектов, выявленных в ходе совещания. Секретарь должен вслух прочитать свои записи, чтобы убедиться в их точности. Другие участники инспектирования должны помочь ему зафиксировать суть каждой проблемы таким образом, чтобы автор смог четко уяснить природу и местоположение каждой проблемы.
Входные критерии
Вы готовы к экспертизе документа о требованиях в том случае, если он удовлетворяет определенным предварительным условиям. Набор входных критериев (entry criteria) четко обрисовывает авторам то, как следует подготовиться к инспектированию. Они также удерживают команду от траты времени на проблемы, которые следует решать до начала экспертизы. Координатор использует входные критерии в качестве контрольного списка до того, как принять решение о начале инспектирования. Вот несколько входных критериев для составления документации по требованиям:
· документ должен соответствовать шаблону;
· в документе выполнена проверка правописания;
· автор просмотрел документ на наличие ошибок в макете;
· для экспертизы подготовлены все необходимые проверяющим лицам предшествующие документы или документы, на которые имеются ссылки;
· номера строк следует напечатать в документе, чтобы облегчить ссылки на определенные элементы в течении совещания;
· все нерешенные вопросы помечаются значком «TBD» (to be determined — необходимо определить);
· координатор выявляет не более трех существенных дефектов после 10-минутной проверки выбранного фрагмента документа.
Этапы экспертизы
Экспертиза — это многоэтапный процесс, как показано на рис. 15-2. Цель каждого этапа кратко описана далее в этом разделе.
Рис. 15-2. Экспертиза — это многоэтапный процесс. Пунктирные линии указывают на то, что определенные этапы экспертизы могут быть выполнены несколько раз
Планирование. Экспертизу совместно планируют автор и координатор. Они определяют состав участников, материалы, которые проверяющие должны получить до начала первого совещания, и количество совещаний, необходимых для охвата всего материала. Количество обнаруженных дефектов очень зависит от темпов работы (Gilb и Graham, 1993). Как видно на рис. 15-3, чем медленнее изучается спецификация требований к ПО, тем больше дефектов удается выявить (весьма распространено альтернативное толкование этой связки: «Темпы проверки снижаются, если вы обнаруживаете много ошибок»). Поскольку ни одна команда не может тратить бесконечное количество времени на проверку требований, выберите подходящий темп, принимая во внимание риск пропуска важных дефектов. Чаще всего — от двух до четырех страниц в час, хотя оптимальная скорость, при которой достигается максимальный эффект ниже примерно в два раза (Gilb и Graham, 1993). При выборе темпа работы учитывайте следующие факторы:
· дату предыдущей экспертизы;
· объем текста на каждой странице;
· сложность спецификации;
· риск не заметить ошибку;
· насколько критично для успеха проекта проверить весь этот материал;
· квалификацию автора спецификации требований к ПО.
Рис. 15-3. Количество обнаруженных дефектов зависит от темпа инспектирования
Обзорная встреча. Во время обзорной встречи автор описывает исходные данные материала, предназначенного для проверки, предположения, которые он сделал, и его личные цели. Если все проверяющие хорошо знакомы с проверяемым материалом, вы можете пропустить эту стадию.
Подготовка. До совещания каждый из экспертов исследует продукт, чтобы определить возможные дефекты и возникающие вопросы; для этого они используют контрольные списки типичных дефектов (они описаны далее в этой главе) и другие приемы анализа (Wiegers. 2002а). До 75% дефектов, обнаруживаемых при экспертизе, выявляются на этапе подготовки (Humphrey, 1989), поэтому этот этап пропускать нельзя.
| Дополнительная информация Приемы по выявлению недостающих требований, описанные в главе 7, могут оказаться полезными при подготовке к экспертизе. |
| Ловушка Не следует начинать совещание, если участники еще не изучили продукт самостоятельно. Неэффективные совещания могут породить мнение, что экспертиза не что иное, как пустая трата времени. |
Написанные документы требований никогда не смогут заменить дискуссий между участниками проекта, однако серьезные недостатки спецификации необходимо исправить. Возможно, стоит обратиться к разработчикам, проверяющим спецификацию требований к ПО, с просьбой оценить ясность (понятность) требований по 5-балльной шкале (Pfleeger, 2001). Оценка «1» означает, что разработчик не имеет ни малейшего представления о содержании требования, а «5» — что оно абсолютно понятное, полное и недвусмысленное.
Совещание. На совещании читатель знакомит членов команды с каждым требованием спецификации — по одному за раз, перефразируя их своими словами. По мере обсуждения дефектов и других проблем секретарь заносит их в форму, которая для автора требований становится руководством к действию. Цель совещания — выявить в документе как можно больше ошибок. Совещание не должно длиться более двух часов, поскольку работу уставших людей нельзя назвать продуктивной. Если же вам нужно больше времени, следует запланировать еще одно совещание.
В заключение совещания команда принимает решение: следует ли принять документ без изменений, с незначительными поправками или указать на необходимость значительной переработки. Решение «необходимы значительные изменения» свидетельствует о наличии серьезных проблем в процессе разработки требований. Возможно, стоит изучить уже проделанную работу и попытаться найти выход до того, как приступать к следующему этапу работы над спецификацией (Kerth, 2001).
Иногда проверяющие сообщают только о поверхностных и незначительных проблемах. Вдобавок проверяющие легко отвлекаются на дискуссии о том, действительно ли обсуждаемый вопрос является дефектом, на споры о границах проекта и на обсуждение возможных решений проблем. Это все, конечно, полезно, однако эти действия отвлекают проверяющих от непосредственной цели совещания — выявления серьезных дефектов и возможностей улучшения.
Некоторые исследователи придерживаются мнения, что совещания слишком трудоемки (Votta, 1993). Я же считаю, что на них можно выявить те дефекты, которые не удастся обнаружить проверяющим при индивидуальной работе. Как и в том, что касается качества, вам придется принимать рискованные решения о том, сколько усилий вы готовы затратить на улучшение требований перед началом разработки и сборки продукта.
Переработка. Практически на каждом этапе работы, связанным с контролем качеством, выявляются определенные дефекты. После совещания автору следует отвести определенное время на переработку требований. Исправление в будущем дефектов требований обойдется дороже, поэтому именно сейчас следует разрешить неясности, устранить двусмысленности и заложить основу успешного проекта по разработке. Не имеет смысла проводить проверку, если вы не собираетесь исправлять ошибки, которые будут выявлены.
Заключительный этап. На этом заключительном этапе экспертизы координатор или специально назначенный член команды работает с автором, чтобы убедиться, что все поднятые проблемы разрешены и все ошибки исправлены соответствующим образом. Заключительный этап завершает процесс инспектирования, на этом этапе координатор определяет, удовлетворяют ли выходные критерии экспертизы.
Выходные критерии
В ходе экспертизы определяются выходные критерии (exit criteria), которые необходимо одобрить, прежде чем координатор объявит о том, что проверка закончена. Вот перечень стандартных критериев:
· все возникшие вопросы были сняты;
· все изменения, внесенные в документ и соответствующие продукты, были внесены корректно;
· в измененном документе проверено правописание;
· все проблемы, помеченные «TBD», разрешены, при этом фиксировались данные по разрешению каждого, дата и исполнитель;
· документ был сверен с помощью системы управления конфигурацией проекта.