Принципы работы с требованиями к ПО. Леффингуэлл (2002) (1186169), страница 65
Текст из файла (страница 65)
Последней контрольной точкой является демонстрация работы системы в среде клиента. В процессе разработки существует последняя и очень важная контрольная точка. Нужно продемонстрировать, как продукт работает в среде клиента, и продукт должен понра. виться заказчику настолько, чтобы тот принял его. Суть в том, чтобы по окончании про екта клиент был доволен или, в крайнем случае, не слишком недоволен. Работа по проверке нравилыюсти разработки (ла(Ыал(пя) имеет два важных аспекта: (1) показать, что продукт соответствует предъявляемым к нему требованиям и (2) сосредоточить внимание на приемке клиентом конечного результата.
Хотя теоретически это Глава 29. Как правильно построить "правильную" систему... 399 одно и то же, на практике заключительные приемочные испытания часто демонстрируют, что мы следовали требованиям, но потребности пользователя "сместились" по сравнению с более ранними стадиями проекта. В главе 92 обсуждаются оба аспекта проверки правильности, а также высказываются различные мнения о том, что она подразумевает. Как и при верификации, здесь тоже нужен способ, позволяющий убедиться, что затраты времени и средств на проверку правильности или тестирование являются эффективными. И снова в этом может помочь анализ дивидендов (КО1).
Обработка изменений, возникающих в процессе разработки Наконец, необходимо рассмотреть влияние изменений требований. Приходилось ли эам когда-нибудь работать над системой, в которой требования ни разу не менялись с первого дня? Необходимо строить свои планы с учетом возможности изменений и знать, как этими изменениями управлять. В главе 94 обсуждается возможное разрушительное влияние неконтролируемых изменений и предлагается организованный способ их выявления, оценки воздействия, а также их внесения упорядоченным образом. Далее... Начнем с того, как иа основании требований осуществить проектиро.
ванне и реализацию решения имеющейся проблемы. Этому посвящена следующая глава. Глава 30 От понимания требований к реализации системы Основные положения ° Многие требования достаточно легко отобрасзйть 'в технический проект 'и.,: И Существуют требования, глабо связанные'с'проектированием и'реализацией; форма требования существенно иная; ввзникает, проблема ортого;, ' нальности. ° Смягчить проблему ортогональности.можно посредством применения:. объектно ориентированных методов и прецедентов.: ° Прн проектировании с использованием прецедентов все заинтересовиь',. ные лица получают возможность исследовать предложенную реализацию, системы на соответствие вариантам использования и требованиям.
° Хороший проект системы не обязателъно оптимален в том, что касается возможности видеть, где реализовано каждое конкретное требование. Мы создавали сложные программные системы на протяжении более 40 лет. В истории отрасли были трудности н неудачи, но были и несомненные успехи: интерактивная торговля, обработка текстов, медицинские системы жизнеобеспечения, безопасные внергетические установки и многое другое. Очевидно, что мы должны были как-то научиться переходить из мира требований к проектированию и реализации.
Мы имеем опыт реализации многих сложных систем, со ответствующих предъявляемыгя к иим требованиям. Однако когда дело касается построения сложных систем, требующих высокой степени надежности проекта, это не всегда приятное илн, по крайней мере, строго научное занятие. Причина в том, что не такто просто увидеть проверяемые требования внутри реализации. Доказательство того, что требования осуществляются в программном коде, является нетривиальной задачей. Отображение требований в технический проект и программный код К счастью, для значительного количества требований относительно несложно разработать программу, которая непосредственно преобразует их в технический проект, а за.
302 тйасть 6. Построение правильной системы тем и программный код. Это также означает, что можно протестировать значительную часть кода, используя тесты на соответствие определенного модуля определенному требованию, так как будет обеспечена высокая корреляция между формулировкой требова. ния и реализующим его кодом. Например, достаточно несложно обнаружить и проверить правильность кода, выполняющего требование "Поддерживать входные параметры с плавающей точкой до восьми знаков включительно или "Показывать ход компиляции пользователю" (рис.
30.1). В зависимости от типа создаваемой системы данный подход можно применять для значительной части программного кода, и в этом случае процесс преобразования требований в технический проект и реализацию не столь уж сложен. Рюдгээз! = ~ав Вээй йУМэгбс<>гяМГгМЗс) ТГиа РгсдгвэяйагГ.Мгк = гМГГыбс Рнс..у0.1. ггреебриаоваигге жраяиэивий в ирэекгя и реализацию Проблема ортогональности Но когда дело касается требований вида "Система должна обслуживать до 100 тысяч тор говых операций в час" нли "Система должна разрешать редактирование, основываясь на уровне безопасности, установленном системным администратором", все стано.
антса несколько сложнее. Эти требования сложно связать с проектом системы и '"" ® реалиэационным иодом; они ортогональны или практически ортогонэльны. Не иа существует озответствия один.к.одноиу, которое значительно упрощает реалгг- ээцию и проверку правильности. И тому есть несколько причин. ° Требования говорят об элементах реального мира, таких как двигатели и чеки, в то время как код оперирует стеками, очередями и алгоритмами вычислений.
Это два свверпгенно различных языка. ° Определенные требования, такие как требования произвогпгтельности, ииеют мало общего с логической структурой кода, но тесно связаны со структурой обработки (как взаимодействуют различные части кода, насколько быстро выполняется определенный Глава 30. От понимания требований к реализации системы 303 фрагмент, сколъко прерываний поступает при нахождении в модуле А и т.д.). Когда физически невозможно отобразить требование в логическую структуру, то невозможно и "указать", где в реализации отражено данное требование. ° Для осуществления функций, предусмотренных некоторыми функциональными требованиями, необходимо взаимодействие нескольких элементов системы.
Рассмотреть часть — это ие то же самое, что рассматривать целое; реализация требования оказывается распределенной по нескольким фрагментам кода. ° Возможно, самым важным является то, что при проектировании системы эачас. тую руководствуются не соображениями легкости доказательства того факта, что некое требование удовлетворяется, а другими, гораздо более важными мотивами. Например, стараются оптимизировать дефицитные ресурсы с помощью архитектурных образцов (которые хорошо зарекомендовали себя в других приложениях, но не полностью соответствуют настоящему), посредством повторного использования программного кода, а также применения закупаемых компонентов, которые имеют собственное управление и функциональное поведение и т.д. Те из нас, кто создавал системы высокой надежности и/или должен был по условиям контракта продемонстрировать на бумаге прямую корреляцию между требованиями и программным кодом, конечно, старались сделать это.
Но, надо признаться, такая демонстрация состояла частично из механизмов трассировки реальных (вэзкных и серьезных) требований, а частично — чего-то эфемерного. Объектно-ориентированный подход Проблему ортогопэльности (которая заключается в отсутствии прямой связи между отражающими проблемную область требованиями и реализационным кодом) удалось смягчить благодаря внедрению объектно. ориентированных (ОО) методов.
При использовании ОО-методов создаваемые кодовые сущности теснее связаны с проблемной областью, что, как следствие, повышает степень робастиости. Это происходит не только благодаря объектно. ориентированным принципам абстрактности, сокрытия информации, наследования и т.п., ио и благодаря тому, что сущности реального мира просто изменяются не так часто, как транзакции и данные, которые мы раньше использовали для моделирования нашей системы. Поэтому код также изменяется реже. (Например, люди до сих цор получают расчетные листы, как и 40 лет назад, хотя их форма — электронные вместо бумажных — изменилась коренным образом,) Применяя объектно-ориентированный подход, можно отыскать в программном коде объекты, ответственные за реализацию механизма расчета, и объекты платежных ведомостей, а затем использовать их при верификации требований.
Можно посмотреть на требования для "расчетного листа" и увидеть, поддерживаются лн предполагаемые операции и атрибуты в модели проектирования. Но нужно быль внимательным, так как благое намерение обеспечить взаимно однозначное соответствие между требованиями и кодом может привести к функционально. организованной архитектуре, совершенно не соответствующей объектноориентированному подходу. Согласно основным принципам ОО-методологии, разработ. чик должен описать небольшое число механизмов, выполняющих кэючевые требования системы. В результате получается множество классов, взаимодействие которых приводит 304 Часть 6.
Построение правнльыой системы к более содержательному поведению, чем просто сумма поведений отдельных классов. Это "более содержательное поведение" должно обеспечить более устойчивый и способный к расширению проект, чем могут дать текущие (а в идеале, и будущие) требования в сумме, ыо оно не является взаимно однозначным отображением требований. Таким обра. зом, даже при следовании объектно-ориентированным принципам ортогональность требований все же сохраняется. Прецедент в роли требования Обособленный характер отдельных требований может еще более усложнять проблему ортогоыальности. Каждое требование само по себе может и не представлять серьезной проблемы, но сложно становится рассматривать поведение системы в целом и определять, действительно ли она делает все, что нужно.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
