Принципы работы с требованиями к ПО. Леффингуэлл (2002) (1186169), страница 70
Текст из файла (страница 70)
ваний к продукту и связанным с ними программным требованиям /прецедентам. ° Может оказаться, что связь была случайно пропущена прн задании трассировки. В тз. ком случае простое добавление новой связи и пересчет матрицы трассировки решат проблему. Ов~ибкн такого типа часто встречаются иа ранних стадиях проекта. ° Но может выясниться, что при разработке программных требований просто ие удалось учесть потребности одной из необходимых функций продукта.
В таком случае следует или исправить проект и добавить подходящие требования, отве- 322 Часть 6. Построение правильной системы чающие ланной функции, или поместить пропущенную функцию в категорию "будущих" либо удалить вовсе. В любом случае при верификации важно убедиться, что ни одна связь не пропущена и все элементы более низкого уровня, такис как программные требования/прецеденты, наллежащим образом связаны с более высокоуровневыми требованиями к продукту. "Лишние" отношения Кроме того, верификация может выявить следующее. При проверке свюлбкое матрицы трассировки могут обнаружиться столбцы, не связанные ни с одной строкой.
На рис. 31.8 прецедент 3 (БС3) не связан ни с одной функцией продукта (ГЕА). гас. 31.8. 11рекеденвь длл комарова врояужена атяошеиие Подобные ситуации свидетельствуют, что для созданного прецедента (или требования) не существует связанной с ним функции продукта. Иными словами, по.видимому, требование является лишним. Как и ранее, следует проверить отношения трассировки. ° Может оказаться, что связь пропущена случайно при задании трассировки. В таких случаях нужно просто добавить новую связь, пересчитать матрицу трассировки, и проблема будет решена. ° Но может быть и так, что при задании ф)тшций продукта просто не были учтены по. требности одного из необходимых требований к программному обеспечению.
Такая ситуация люжст возникнуть, если есть опрсделенныс ограничения проектирования, которые необходимы прп реализации, но меняют функции продукта. В таком случае необходимо исправить проект, чтобы учесть осуществимосгь и необходимость гребо. ванпй. Можно удалить соответствующее требование(я) или поместить его в список "б)згущих". С другой стороны, при пересмотре проекта может оказаться, по пропущенную функцию следует помесппь в категорию "будущих" или добавить уже сейчас.
В нашем примере мы в ходе проверки проекта пришли к выводу, что ()С3 является лишней спецификацией, и ее не должно быть в проекте вовсе. Глава 3!. Использование трасснровкн для поддержкн верификации 323 Прн всрнфнкацно пном просмотре такого тяпа ос полное вппмапнс улслястся тому, чтобгл в проект нс закрались бсспрнчнппыс элемсппа. Опыт свпдетслы твуст, что онп значнтслыю увслнчнвшот объем проекта н редко способствуют повьпвспшо качества результата. Размышления о верификации и трассировке Проблемой прп пояске пропущенных/лншннх отношсннй является то, что эта рабо.
та очень механическая. Другнмн словами, возннкаст соблазн сказать: "Мы посмотрслп на все строкн н столбцы, и вес выглядит нормально. ! ак что вернфнкацня закончена. Давайте двнгаться дальше!". Недостатком подобной ар~уьгснтацнн является то, что мы не рассмотрели, шмно я к~ф. гмктнолп отралсены все связи, которые следует (нлн нс следует) уста~овнть.
Мы обнаружнлн, что более гл)бокос изучение исходных трасснровочпых связей всегда приводит к пскнм нх неправлснням. Могут добавлятыя новыс связи, а старые — нзмсняться нлн удаляться. Мы призываем вас рассматривать нсходные связи как некую точку отсчета прн прове. деннн верификации. После задания исходных связей и завсршсння проверки исходных строк/столбцов нужно провести формальные (нлн неформальные) проверки. Только после нроведення по крайней мере одной полномасштабной проверки н внесения измененнй можно считать, что верификация на данной фазе проведена, Связи, как н самн требования, будут эволюционировать со временем. Изменения, конечно же, нензбежны.
Поэтому необходимо трактовать все связн как "живые", подверженные пересмотрам по мере продвижения проекта. Следует проводнть проверки с целью верификации всякий раз, когда становнтся очсвндно, что будузцая, тскугцая нлп прсннлая фаза внесла существснпыс нзмснс~ня в трасснровочпые связи. '1асто нужны ретроспсктнвные пересмотры, котла новос попнманнс проекта прнводцт к пересмотру старых связей и отношсннй. Главным является то, что верификация требует вдумчивого оянюжсиггл н нельзя полагаться на чисто мсханнчсскне действия.
Далее... Вернфнкацня является мон!ным методом, который помогает команде проектировать н рсалнзовать правнльную спстему. К сожалению, до снх пор во мпогнх проектах методы верпфнкацнн недостаточно используются для подтверждсппя того, что проект движется в правнльном направлении. Такие проекты нснзбежно "сбнваются с путя", а члены команды даже пс подозревают об этом. Кс» печно, на каком-то этапе песоотвстствне случайно обнаруживается, по это происходит слншкои поздно н разо'щровапнс пспзбежно.
!!роскты, которые подвергаются частой верификации, гораздо реже преподносят полобпые сюрпризы. Однако ппкакая всрпфнкацня нс может гараптнровать, что конечный результат будет такплп кзк предполагалось. Необходим другой прннцнп, который поможет удостовс. ряться, что создаваемая снстсма является правнльпой. Этот принцип — ггроеерка гфавяльносяш (та1Ыайоп) — обсуждается в следующей главе, Глава 32 Проверка правильности системы , Основные положения,: ':,-,:::..;:,:::;, '...,:: ";, ';, ';,..., - .: ...,,.:-,',:, ц, "( ', ° Проверка йравильйости'(ча1Ыаг(опл) представляет",собой процесслподтвер"'~ ' ждеиия того,''что1 разработанная система'соответствует предьявпяемым к",; ней требованйям.. ,,щ Прйемочное.тестирование проверяет правильность работы системы в ~ среде клиента и в сценариях иснользования. ~ ° Чтобы добиться высокого качества, 'нужно проводить тестирование не,".
только выподнения, но и соответствия требованиям и реальному исполь- ': зованию клиентом. Стандарт 1ЕЕЕ (1994) определяет проверку правильности (лз)Ыаг1оп) следующим обрююм. Процесс оиениванил системы или компонента во время или пв окончании н~юКегса Раэфагютки с Кеглю аглРедгл клал, удавлвэннфяенл ли она указанным яфебованилм (!ЕЕЕ 1012-19Вб, В 2, 1994). Другими словами, проверка правильности призвана подтвердить, что реализованная система соответствует заданным требованиям. Но данное определение недостаточно. Хотя тестирование на соответствие требованиялл является, безусловно, важным шагом, все же существует вероятность, что предоставленная система окажется не такой, как хотел клиент.
Иногда много времени н снл уходит на то, чтобы собрать н понять потребности клиентов, затем следует реализация системы, причем показывается (с помощью тестов по проверке правильности), что она корректно выполняет все собранные требования, после чего конечный продукт доставляется клиенту, а тот упирается и заявляет, что продукт не такой, как он хотел.
Что же не так) Все очень просто. Не удалось превратить туманное "облако" проблемы пользователя в организованную структуру, представленную требованиями. Но это слабое утегаение для команды проекта, затратившей огромные усилия на создание программного продукта. Проводя приелючные тесты на каждой итерации, можно минимизировать этот синдром.
326 Часть 6. Построение правильной системы Проверка правильности Приемо-сдаточные испытания Приемо-сдаточные испытания привлекают заказчика к окончательной проверке системы. Приемо сдаточные испьпзння привлекают заказчика к процессу окончательной проверки правильности системы, чтобы убедиться, что "продукт работает именно так, как нужно клиенту". Для внешних заказчиков приемо.сдаточные испытания могут разрабатываться и выполняться в соответствии с условиями контракта. В среде 1$/П или 13 т' те же задачи, как правило, выполняются клиентом в процессе альфа- или бета-тестирования. Приемо-сдаточные испытания обычно основываются на определенном количестве "сценариев", которые пользователь задает и выполняет в среде использования.
Клиент имеет право конструировать оригинальныс способы проверки системы, чтобы убедиться, что система работает так, как ему необходимо. Если мы все сделали правильно, прис. мо-сдаточные испытания будут основываться на ключевых прецедентах, которые нами уже были определены и реализованы. Но при приемке эти прецеденты будут применяться в различных комбинациях при разных типах загрузки системы и при наличии других факторов среды — параллельная работа с другими приложениями, зависимость от ОС и т.д.
— которые, скорее всего, присутствуют в среде пользователя. В итеративном процессе разработки следует проводить приемочное тестирование при достижении различных важных вех в построении системы, чтобы конечные приемосдаточныс испытания не преподнесли сюрприз команде разработчиков.
В процессе, следующем модели водопада, это нс применяется, и значительные неожиданности являются обычным делом. В любой модели никогда нс поздно обнаружить по крайней мере несколько "неоткрытых руин", которым необходимо >делить внимание. В главе 34 обсуждается, как управлять теми изменениями, которые мо~уг появиться в результате. Тестирование с целью проверки правильности Основной деятельностью при проверке правильности является тестирование. Но как должен выглядеть хороший план тестирования) Один из вариантов предлагается стандартом ! ЕЕЕ 8291983, !ЕЕЕ Ялляая1/т БоЯма ге Тем ВосителГа1юл (1ЕЕЕ, 1994).
Данный стандарт содержит восемь образцов документов, которыми следует руководствоваться прн выборе методологии тестирования, проведении тестов, сообщении о результатах и устранении аномалий. Другие методологии (Кш)опа1, 1999) используют несколько иные подходы, по все онп сходятся в главном. ° Процесс разработи» должен включать в себя гианп)зояаяиг дейсвеия ло ямсипфованию. !В итеративной модели планирование тестов осуществляется преимущест. венно в фазе исследования.) ° 11роцссс разработки должен предусматривать выделение времени и ресурсов для лроект1фованил вмсяиж Полезно иметь общий шаблон, разработанный таким обрззом, чтобы проект каждого отдельного теста больше внимания уделял его индивидуальным особенностям.
Глава 32. Проверка правнльностн системы 327 ° Необходимо предусмотреть выделение времени н ресурсов на выполнение нистов, как па уровне отдельных тестов (прн необходимости), так н па общеснстемном уровне. Тестовые докултепты образуют часть документации реалнзацнн. Дерево документацнн реалнэацнн вместе с документацией тестирования представлено на рнс. $2.1. Потребности пользоаателя 1 Дакументконцепция < < < ЗПЗ.пакет < <л * < < < Прецеденты специ(женин < днамз < требощнйи ° рисков ! Компонв<ты реаваации (функции, реализации прецедантоа, модули, обьелты) тестоа тестов ?т<с. 32.1. Доиулмнеокилреализокии Мы рекомендуем вести журнал, в котором отражается соответствие действий по проверке правнльностн/тестнрованню спецификациям реалнзацнн.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
