Принципы работы с требованиями к ПО. Леффингуэлл (2002) (1186169), страница 50
Текст из файла (страница 50)
шается не работать после сбояу МТТК может иметь несколько значений; напри. мер, пользователь может указать, что 90% всех системных сбоев должны ликвнднроваться за 5 минут, а 99.9% — в течение часа. Вновь важна точность: требования должны четко )называть, означает ли восстановление, что все пользователи снова будут иметь возможность получать доступ ко всем услугам, или допускается частичное восстановление.
° Точность (ассипзсу). Какая точность требуется системам с числовым выводому На. пример, должны ли результаты в финансовых системах быть с точностью до пенни плн доллара) ° Максимальный коэффициент оннсбок. Как правило, выражается как число ошибок, приходящееся па тысячу строк кода (Ьпбз/К1.ОБ) или на одну функцию. Глава кэ. Требования к программному обеспечению кэу ° Каличесямо рязличнмл ошибок. Обычно ошибки делятся на незначительные, серьезные и критические. Здесь также важны четкие определения: требования должны опреде. лять, что понимается под "критической" ошибкой — полная потеря данных или невоз.
можносп испольэовать определенную часть функциональных возможностей системы. В некоторых случаях требования могут указывать некоторые "ориентировочные" метрики надежности. Типичным примером этого является использование некой "метрики сложности" для оценки сложности и, тем самым, потенциальной "ошибочности" программы. Производительность К требованиям производительности обычно относится следующее. ° Время ответа для транзакции: среднее, максимальное ° Пропускная способность: число транзакций в секунду ° Емкость: сколько пользователей илн транзакций может обслужить система ° Режимы снижения производительности; допустимые режимы работы при ухудшении параметров системы Если новая система должна совместно с другими системами или приложениями использовать аппаратные ресурсы (ЦП, память, каналы, дисковую память, сетевой диапа. зоп частот), может также потребоваться указать, насколько "цивилизованно" опа себя при этом ведет.
Возможность обслуживания Возлюжиость обслуживания заключается в способности легко модифицировать про. граммное обеспечение с целью внесения изл~енеиий и исправлений. В некоторых предметных областях можно заранее предвидеть вероятную природу будущих изменений, и требования могут содержать указание "времени ответа" группы поддержки для простых, средних и сложных изменений. Предположим, мы создаем новую систему расчета заработной платы.
Одно иэ многих требований к такой системе состоит в том, что опа должна вычислять удерживаемые правительственные налоги для каждого работника. Пользователь, конечно, знает, что правительство каждый год меняет алгоритм вычисления налогов. Это изменение затрагивает две величины: вместо удержания Х процентов от общей заработной платы работника, по пе более 5Р, новый закон требует удержания У процентов, но ие более бф Таким образом, требование можно сформулировать так: "Модификации системы с целью задания новых коэффициентов налогообложения должны осуществляться командой в течение одного дня после получения уведомления от официальных властей".
Но предположим, что налоговая инспекция периодически вносит в данный алгоритм поправки, аналогичные следующей: "Для левшей с голубыми глазами ставка налогооблсг жсиия должна составлять Х процентов, ио не более 3К". Подобные модификации сложнее предусмотреть в программе; хотя можно попытаться сделать ее максимально гибкой. Команда, вероятно, согласится, что данная модификация попадает в категорию изменений "среднего уровня" сложности, для которых требование люжет задавать время реагирования — одна неделя.
Представим себе, что перед началом проекта менеджер отдела заработной платы сказал; "Возможно, мы будем расширять сферу пашей деятельности. В этом случае нужно 238 Часть 5. Уточнение определения системы иметь возможность сделать так, чтобы алгоритм вычисления удерживаемого налога ог ражак действующее законодательство Франции, Германии или Гонконга". Если предположить, что такое "требование" вообще имеет смысл, его можно сформулировать только в виде намерений и целей; и будет сложно измерить и проверить его выполнение.
Чтобы действительно повысить вероятность возможности обслуживания системы в данной ситуации, нужно потребовать использования определенных языков программирования, систем управления базами данных (СУБД), программных средств, стандартных процедур поддержки, стилей и стандартов программирования и т,д.
(В этом случае, как мы увидим далее, требования, в действительности, становятся ограничениями проектирования.) Нельзя утверждать, что в результате система станет легко обслуживаемой, но, по крайней мере, мь> можем приблизиться к цели. ОГраничения проектирования Ог(>аиичепия и)>оекпп>1>овапия, как правило, касаются вариантов проектирования системы или процессов, используемых при се построении.
Ниже кратко описаны различные формы ограничений проектирования. ° Покое требование, которое допускает несколько вариантов проектирования; проект является осознанным выбором среди этих вариантов. Если это возможно, хотелось бы пе указывать конкретный вариант в требованиях, а оставить выбор за разработчиками, так как они смогут лучше оценить технические и экономические характеристики каждого варианта. Если мы не оставляем возможности выоора (" Использовать СУБД Огас!с"), возможности проектирования сужаются, утрачивается гибкость и свобода разработки. ° Требование, налагаемое па процесс создания программы (" Программировать па Ъ'В" или "Использовать ХУЕ-библиотеку классов").
1<ак было показано в примере с Уйпа1 Ва>!с, источники и причины таких ограничений мо>ут быть различны, н разработчики иногда вынуждены принимать их, независимо от того, нравятся опи им или нет. Но важно отделять их от обычных требований, так как подобные ограничения могут быть достаточно произвольными, они могут оыть обуслов. лены политическил>и соображениями, а также могут подвергаться изменениял> по мере развития технологий. рассмотрим определение. Ог)>аиичевия п|>оекп>и)>алания полагаются па п|>оекп> системы или пуюкессь>, с помои>ью ко>по)>ых система создается. Они пе влияюл> па впеи>пее поведение сиспммы, по д>викин выпсмпяп>ьсл для удовлеоюорепия технических, деловых или копи>Раки>пых обязательспы. Можно указать следующие источники ограничений проектирования.
° Операциопные среды> |>1>огу>аммы пии>утсл иа 1миа! Вапс. ° Совместимость с существующимн системами: Л)>илолсение долзсно выпапшться как па >совой, так и ка премией па>аей»лат9>о)уме. ° Прикладные стандарты: Использовать библиотеку классов из |>еие|оу>гт'з | йга>у 99-724 па ко(>по|к>п>иенам се)>ве(~е!Т. Глава 23. Требования к программному обеспечению 239 ° Корпоративные практические наработки и стандарты; Доллсна обесиечиоатьсл со. вместимость с су»бествующей базой данных Иснаеыовать оландоРты иу»оерамми)зова.
нил Сл+. Еще одним важным источником ограничений проектирования являются разнообразные инструкции и стандарты, которым подчиняет. ся разработка проекта. Например, разработка л»едицинских продуктов 3 в США регулируется миожествол» инструкций и стандартов Р)УА (Управление по санитарному надзору эа продуктами и медикаментами), которые касаются ие только продукта, но и процесса его разработки и документирования.
Среди организаций, инструкциям и стандартам которых должно отвечать проектирование, люжио указать следующие. ° Управление по санитарному надзору за продуктами и медикаментами (Р1)А) ° Федеральная правительственная комиссия США по средствам связи (РСС) ° Министерство обороны ()УО1>) ° Международная организация по стандартизации (15О) ° Лаборатории по технике безопасности ( С1 ) Как правило, сформулированные в виде разнообразных инструкций проектные ограничения этого типа слишком длинные, чтобы их можно было непосредственно включить а требования. В большинстве случаев достаточно внести их в список ограничений проектирования в форме ссылок. Таким образом, требование может иметь вид: Програмна будет»милостью соответствовать сн»инда»эн»у Тй)гбо»»э»осе 5»алба»а, 1»издали 3.1-3.4.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
