Принципы работы с требованиями к ПО. Леффингуэлл (2002) (1186169), страница 57
Текст из файла (страница 57)
Таким образом, фраза "Мери имела маленького барашка" может иметь любое из слт дующих значений. Глава 26. Неоднозначность и уровень конкретизации 265 "Иметь" еБарашек" Интерпретация Мери — владелец маленькой овечки в возрасте до года либо без постоянных зубов Мери держала в руках (не пускаэа порезвиться) маленького ягненка в возрасте до года либо беэ постоянных зубов Мери обманула маленькую овечку в возрасте до года либо без постоянных зубов Мери родила маленькую антилопу Мери является (или была) матерью некоего маленького, симпатичного существа Мери съела небольшую порцию седла ягненка Мери подкупила мелкого торговца ценными бумагами, кото ый нечист на за 1а 10а 1а 106 1а 12 12 16 2а За 2в Для тех, кто помнит этот стих с детства и сзм читает его на ночь своим детям, все это может казаться совершенно нелепым: "Разве здравомыслящий человек будет интерпре. тнровать такую знакомую фразу столь странными способамиг".
Но это перестанет быль столь уж невероятным. если мы представим, что человек из другой среды, принадлежащий к другой культуре, попытается интерпретировать данную фразу, основываясь ис. ключительно иа словарном определении двух ключевых слов. Раз зто возможно при интерпретации строчки из стиха, это тем более может происходить в сложных программных системах, не имеющих аналогов в прошлом. Как избежать неоднозначности Один нэ способов избежать неоднозначности состоит в том, чтобы вместо естественного языка использовать методы "формальной" спецификации требований, которые приводятся в главе 28.
Пользователи и заинтересованные лица. не входящие в команду разработчиков, предпочитают естественный язык, и даже компьютерщики в повседнев. ном общении отдают ему предпочтение. Но хотя обе группы считают естественный язык удобным, все же их интерпретации и предположения могут существенно отличаться. Может оказаться, что полностью устранить неоднозначность невозможно, но можно предпринять определенные усилия в нескольких направлениях.
Гаус (Санге) и Вайнберг (Ъге(пЬег8) в своей книге (1989) предложили несколько методов. ° Ээ)зксакха запоминания. Необходимо попросить несколько человек, как из группы разработчиков, так и из группы пользователей/заинтересованных лиц, постараться по памяти восстановить исходное требование клиента. Непонятная часть, которую трудно вспомнить, вероятно, является наиболее неоднозначной. Стоит обратить на нее внимание и постараться переопределить ее более понятно, чтобы она поддавалась запоминанию. ° Мплод ключгеых оюз. Как было показано на примере анализа строчки иэ стиха, нужно выявить ключевые слова и выписать их определения, пользуясь авторитетным источником, признанным рюличными участниками проекта. Затем нужно соединить )юэ. личные интерпретации, как это проделывалось с Мери и ее бараюпкоьь В качестве быстрой проверки действенности данного негода, можно отметить, что интерпретация (1а и 1а) "Мери владела маленькой овечкой в возрасте до года либо без постоянных зубов", вероятно, более всего соответствует смыслу сказочной истории.
хбб Часть Б. Уточнение определения системы ° Мемед уопренма. Необходимо прочесть требование, выделяя с помощью питона. ции отдельные слова, пока не будут найдены все возможные интерпретации. Если корректна только одна интерпретация, следует переформулировать требование надлежащим образом; если существует несколько корректных интерпретаций, возможно, необходимо создать соответствующие дополнительные требования.
Мы проиллюстрируем применение этого метода в процессе дальнейшего исследо. ванин примера с Мери и ее барашком. ° Я~>упи милодм. Если нужно, используйте рисунки, графики или формальные мего. ды для выявления неоднозначности и ее устранения. Предположим, что мы увидели фразу "Мери имела маленького барашка" в нашем ыборе требований и пытаемся удостовериться, что мы правильно понялн, что на самом деле имел в виду пользователь. Произнося предложение и выделяя интонацией различные слова, можно выявить следующие варианты. ° МеРи имела маленького барашка; в данном случае пользователь, вероятно, хотел скззать, что зто был барашек Мери, а не Ричарда или кого. нибудь другого. ° Мери имела маленького барашка; возможно, его у нее больше нет.
Возможно, все дело именно во времени данного глагола. ° Мери имела маленького барашка (Магу Ьаб а 11гг!е 1ашЬ); ударение на единствен. ном числе этого барашка, т.е. у Мери он был один, а не целое стадо. ° Мери имела маленмгаго барашка; т.е. это был один нз самых маленьких барашков, каких вам доводилось видеть. ° Мери имела маленького баражкж суть в том, что у Мери был именно барашек, а не свинья, корова или взрослый баран.
Но мы н в этом случае можем ошибаться, д1'- мая, что у нее был детеныш антилопы. Что делать Ни один нз методов не являетса универсальным. Чтобы найти оптимальное сочешнне неоднозначности и конкретизации, ну|кно разработать практические навыки применительно к условиям вашей организации и содержанию конкретного проекта. Уровень конкретизации, который необходимо обеспечить, может даже меняться со временем в зависимости от изменения профессионального уровня участников процесса и их понимания области, в которой вы работаете.
Ниже приводятся наши рекомендации относительно нахождения "золотой середины" для вашего проекта. ° Используйте везде, где это возможно, естественный язык. ° Используйте рисунки и диаграммы, чтобы лучше проиллюстрировать сущность. ° Если сомневаетесь — спрашивайте! Даже если сомнений нет, все равно старайтесь спрашивать. ° В тех случаях, когда неверное понимание недопустимо, дополните ваши спецификации более формальными методами. Учите вал~их людей выявлению проблемы неоднозначности и возможным способам ее решения. Глава 27 Критерии качества требований к программному обеспечению )зЮ!'„сзс)йзыйьзгь) )зср)зтерие)а" ~ачесства является':сам.факт наличия:набора.требо-: ,И ~",цля тоуо эцобгя' удостоэвгерпиться в "качестве требований, модели прецедеи-,' ~ =';:,; 'тов;,, спезйфикасций црецедентов "и авторов, можно.-использовать, кон-,' )'",,' "„трбльиьге~переяни.
° ... ~;. °, Высококачественный пакет.Модегп ЯВ Рас)саке должен иметь хорошее ," ','огла)щеизиле, индекс,',глоссарий, а,также' должен содержать, историю ис'зпшвлений. Качество, как и мастерство в искусстве, трудно измерить. ~"Я узнаю настоящее искусство, когда увижу его.") Тем не менее нам нужно найти способ измерять и повышать качество наших спецификаций. Очевидно, что одной из мер качества является получение в результате завершения проекта хорошего продукта.
Но от такой меры проку немного, так как помимо требований существует много других факторов, влияющих на результат. Мы предлагаем оценивать качество спецификации в целом, рассматривая следующие основные элементы. ° Качество казкдой отдельной спецификации ° Качество применяемых методов (например, качество спецификаций прецеден. тов, акгоров и т.п.) ° Качество пакета, объединяющего все отдельные спецификации Начнем с рассмотрения качества отдельных спецификаций.
Чтобы нечто измерить, естественно, необходимо иметь способ проведения измерений. Девять показателей качества Мы уже обсуждали, что собой представляют "хорошие" требования: они удовлетво. ряют предложенному определению (23) и не содержат описания деталей проектирования и реализации, а также вопросов процесса программирования нли управления проек- 268 Часть 5. Уточнение определения системы том. Но как отличить качественный набор требований от некачественного? Руководству. ясь стандартом 1ЕЕЕ 830, который выделяет восемь "критериев качества" для оценки Ьрл5, мы добавим еще один и объясним, как он поможет нам разработать качественный набор требований. Итак, высококачественный пакет Мое(егп эйли Расйа8е должен быть ° корректным; ° недвусмысленным; ° полным; ° непротиворечивым; ° упорядоченным по важности и сгабильностн; ° поддающимся проверке; ° модифицируемым; ° трассируемым; ° понимаемым. Мы добавили девятый критерий, оолиожпосель понимания.
так как твердо верим, что важнейшим залогом успеха проекта является оби1епиеего участников. Обеспечение качества набора требований второстепенно по сравнению с задачей создания этого набора. Тем не менее, обсудим более подробно каждый из этих девяти эле. ментов, так как они придают дополнительную глубину процессу разработки требований, а также позволяют нам лучше понять природу хороших" требований. Корректные требования Дэвис (1)ао)э, 1993) предложил следуловгую формулировку и ее иллюстрацию (рис. 27.1): "$35 (набор требований к программному обеспечению) является корректным тогда и только тогда, когда каждое требование, сформулированное в нем, представляет нечто, требуемое от создаваемой системы". Рвс.
27.1. Множества потребностей в ялребоеанив Если левый круг (область А) представляет множество потребностей пользователя, а правый (область С) — требования, корректные требования будут находиться в области пересечения кр)тов, области В, Просто записывая некую информацию в документ, нельзя гарантировать, что опа корректна; такую гарантию не сможет обеспечить и применение любого средства автоматизированного проектирования. Если истинное требование пользователя для системы расчета заработной платы состоит в том, чтобы ставка всех служащих была автоматнче- Глава 27. Критерии качества требований к программному обеспечению 269 ски повышена иа 5 процентов, а команда разработчиков по невнимательности создает требование, предусматривающее 10-процентное повышение ставки, это, безусловно, пе.
корректно. Но проверить это можно только с помощью просмотра пользователем. Это явление нельзя назвать новым и неизвестным; с ним команды проектировщиков сталкивались с начала работы над самыми первыми проектами программных систем, равно как и при работе над другими проектами. Но в программных проектах часто встречается ситуация, когда опускается информация из области А и включается нежелательная информация из об.
ласти С. Информация из области С может представлять собой детали проектирования/реализации, о чем мы предупреждали ранее, но это могут быть также требования, кото. рые пользователь никогда не высказывал. Иногда эту информацию включают энтузиасты из числа персонала, занимающегося маркетингом или техническими аспектами, которые думают: "Мы уверены, что пользователь придет в восторг от этой функции, как только увидит ее". (Мы вновь вернемся к теме неправомерных требований в части 6.) Недвусмысленные требования Требование является недвусмысленным яюгда и только тогда, когда гго можмо одно.
гмачко иктгукфвтировать (1ЕЕЕ 830-1993, $ 4.3.2, 1994). Хотя главным свойством любого требования по праву считается корректность, неоднозначность зачастую представляет собой более сложную проблему. Если формулировка требований может по-разному интерпретироваться разработчиками, пользователями и другими участниками проекта, вполне может оказаться, что построенная система будет полностью отличаться от того, что представлял себе пользователь. Эта проблема всегда может возникнуть, если требо. вания пишутся на естественном языке, так как члены органиэации, относящиеся к раз. ным группам, настолько привыкли к своей интерпретации слова или фразы, что им никогда и в голову не придет, что другие могут интерпретировать это слово иначе (эту проблему мы обсуждаяи в главе 26). Полнота набора требований Набор требований является полным оюгда и только эюгда, когда ок окисывагт всг важ мыв требования, икте)ггсуюкгиг яагыоватвгя, в том чисгг требования, стыаммыг с фуккиио мазаными вогможкостями, кроизводиякяьтктяью, офамичгкиями проектирования, аяфибуяюми или вкгигкими имтффгйсаии (1ЕЕЕ 830-1993, б 4.3.3, 1994).
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
