Технологии программирования - Wiegers.Software R. Development Productivity Award Москва 2004 удк 004. 45 В41 Карл Разработка требований к программному с англ. М. дом Русская Редакция , 2004. ил. Isbn 5-7502-0240-2 Эта книга
 Скачать 37.95 Mb.
| Образовательный портал Как узнать результаты егэ Стихи про летний лагерь 3агадки для детей |
Полное содержание архива WinRAR ZIP archive.zip:  С этим файлом связано 6 файл(ов). Среди них: task2.txt, unit4.png, task1.txt, Mikhneva_Anastasia_1951.pkt, WinRAR_ZIP_archive.zip, Wiegers_Software_Requirements.pdf, Metodicheskie_ukazania_praktika.docx. Показать все связанные файлыГлава 14. Назначение приоритетов требований 279 при равенстве остальных факторов — должны иметь наивысший приоритет. А можно еще на кулачках Одна которая ввела у себя процедуру определения осно- ванную на таблице, показанной в этой главе, обнаружила, что это помогло команде, работающей над проектом, выйти из тупика. Несколько заинтересованных в проекте лиц придерживались различных мнений о том, какие функции наиболее важны проекта, и команда оказалась в безвыходном положении. Анализ с помощью цы сделал оценку приоритетов более объективной и менее эмоционально накален- позволив команде к некоторым удовлетворительным заключениям и двигаться дальше. Консультант Johanna Rothman писала: предлагала эту электронную табли- цу своим клиентам в качестве инструмента для принятия решений. Хотя те, кто про- бовал ей не разу не заполнили ее до конца, они обнаружили, что дис- которая начиналась при ее чрезвычайно полезна для опре- деления относительных приоритетов различных требований». Таким образом, используйте концепцию выгоды, урона, стоимости и риска для направления дискус- сий о приоритетах. Это более ценно, чем формально выполнить полную проработку анализа электронной таблицы и затем полагаться исключительно на вычисленную последовательность приоритетов. Точность этого метода ограничена возможностью команды оцени- вать выгоду, урон, стоимость и риск для каждого элемента. Поэтому используйте подсчитанную последовательность приоритетов только как ориентир. Представители клиентов и разработчиков должны про- верить итоговую таблицу, чтобы прийти к соглашению о рейтингах и результирующей последовательности приоритетов. Настройте эту мо- дель под себя, используя набор готовых требований из какого-нибудь предыдущего проекта. Измените значения веса так, чтобы подсчитан- ная последовательность приоритетов хорошо сочеталась с вашей того, насколько в действительности важны тре- бования в вашем калибровочном наборе. Это даст вам некоторую уве- ренность в использовании данной таблицы в качестве модели для рас- становки приоритетов в ваших проектах. 280 Часть It. Разработка требований к ПО Ловушка Не придавайте слишком большого значения малым отличиям в под- считанных значениях приоритетов. Данный метод не претенду- ет на математическую точность. Ищите группы требований с похожими значениями приоритетов. Заинтересованные в проекте лица часто по-разному оценивают важность того или иного требования и потенциальный уровень от отсутствия. Один из вариантов таблицы приоритетов учитывает вход- ные данные от нескольких классов пользователей или других ресованных в проекте лиц. На странице Multiple (Множе- ство пользователей) загружаемой электронной таблицы скопируйте колонки Relative Benefit (Относительная выгода) и Relative Penalty (От- носительный урон) для каждого заинтересованного в проекте лица, участвующего в анализе. Затем назначьте вес для каждого участника, больший вес отдавая привилегированным классам пользователей, а не группам, имеющим меньшее влияние на принятие решений, касаю- щихся проекта. В таблице будет учтен вес каждого участника при под- счете общего значения ценности. Эта модель также поможет вам принимать решения о при оценке предлагаемых изменений в требованиях. Учитывайте, как их приоритеты соответствуют приоритетам требований в принятой зовой версии, чтобы выбирать наилучшую последовательность зации. Старайтесь, чтобы ваш процесс определения приоритетов был на- сколько возможно простым, но не проще этого. Стремитесь превра- тить обсуждение требований из политической баталии форум, где за- интересованные в проекте лица смогут давать честные оценки. даст вам лучшую возможность создавать продукты, обладающие мак- симальной бизнес-ценностью. Глава 14. Назначение приоритетов требований 281 Что дальше? 1 Примените модель определения приоритетов, описанную в этой главе, к 10-15 функциям или вариантам использования из недавнего проекта. Насколько хоро- шо подсчитанные этим способом приоритеты совпадают с теми, которые вы оп- ределили каким-либо другим методом? Насколько хорошо они соответствуют вашим ощущениям правильной расстановки приоритетов? 1 Если обнаружилась диспропорция между приоритетами, предсказанными моде- лью, и которые кажутся вам правильными, проанализируйте, какая часть модели не дает ожидаемых результатов. Попытайтесь разные зна- чения веса для выгоды, урона, стоимости и риска. Изменяйте модель до тех пор, пока она не даст соответствующие Настроив и изменив модель расстановки приоритетов, примените ее к новому проекту. Включите подсчитанные приоритеты в процесс принятия решений. По- смотрите, дает ли это результаты, которые заинтересованным в проекте лицам ка- жутся более удовлетворительными, чем те, что получались при прежнем подходе. 282 Часть II. Разработка требований к ПО Утверждение требований Барри, руководитель по вел участни- ки которого проверяли спецификацию требований к ПО на на- личие проблем. Во встрече принимали участие представители самых крупных классов пользователей, разработчик реми и аналитик Гриш, которая написала спецификацию тре- бований к ПО. В требовании 83 было указано: "Система обес- печит безопасность рабочих станций, подключенных к посредством отключения неактивных терминалов по нии тайм-аута». Джереми представил группе свою интерпре- тацию этого требования: требовании 83 говорится о том, что система автоматически отключит пользователя любой бочей станции, подключенной к системе если на ней на- блюдается бездействие в течение определенного периода времени». кого-нибудь есть вопросы по этому требованию?» — поин- тересовался Барри. Первым высказался один из сторонников «Как система определяет, что терминал не активен? Это появление заставки на мониторе: если в течение, ну, пяти минут мышь или клавиатура остаются в покое, то пользователя закрывается? Это может раздражать, когда пользователь просто отвлекся на разговор в течение этих пяти минут». добавила: «На самом деле в требовании ничего не гово- рится об отключении пользователя. Я не совсем понимаю, что означает "безопасность... по истечении Я предпо- ложила, что это означает окончание сеанса, но, может, точно просто ввести пароль», 283 Джереми был также озадачен. «В этом требовании речь идет о любой рабочей станции, которая может подключиться к систе- ме о рабочих станциях, которые активны и ны к системе в данный момент? О времени ожидания ка- кой длины мы говорим? Возможно, существует некое руково- дство по безопасности для таких случаев?» Барри убедился, что секретарь точно зафиксировал все точки зрения. «Ну похоже, что в требовании 83 есть не- сколько неясностей и не хватает некоторой информации, в ча- стности, не определено время ожидания. Гриш, не могла ли бы ты связаться с координатором отдела безопасности и шить этот Большинству разработчиков знакомо чувство расстройства, возни- кающее, если их просят реализовать слишком неясные или неполные требования. Если они не могут получить необходимую информацию, они вынуждены ориентироваться на собственные предположения, ко- торые не всегда верны. Потребуется много усилий, чтобы исправить ошибки в требованиях, работа над которыми уже завершена. Исследо- вания показали, что в раз дороже исправлять ошибки в требовани- ях, если на них указывает клиент, чем в процессе разработки этих тре- бований 1981; Grady, 1999). Другие исследования свидетель- ствуют, что на исправление ошибки, выявленной на стадии работы над требованиями, тратится в среднем 30 минут, тогда как на исправление ошибки, выявленной в ходе тестирования системы, необходимо от 5 до часов и Hops, 1992). Ясно, что любые усилия, затра- ченные на выявление ошибок в спецификации к требованиям, сэконо- мят реальные время и деньги. Во многих проектах тестирование — одна из последних стадий про- екта. Проблемы, связанные с требованиями, могут оставаться в про- дукте до тех пор, пока они не будут выявлены в ходе долгого тестиро- вания системы или их не обнаружит клиент. Если вы начнете вание тестирования и разработку вариантов тестирования на ранней стадии проекта, вы сможете обнаружить многие ошибки вскоре после их появления. При этом вы предотвратите дополнительный ущерб, на- носимый ими, и снизите затраты на тестирование и обслуживание. На рис. 15-1 показана V-образная модель разработки ПО, когда действия, связанные с тестированием и разработкой проекта выпол- няются параллельно 1993). Эта модель что приемоч- ные испытания основывается на требованиях тестиро- 284 Часть II. Разработка требований к ПО системы — на функциональных требованиях, а тестирование це- лостности — на архитектуре системы. Пользовательские требования; приемочных тестирования системы планирование •• • Проверка проверки целостности целостности Дизайн; планирование Тестирование тестирования элементов кода Рис. V-образная модель разработки ПО подразумевает планирование и разработку на ранней стадии проекта Планируйте мероприятия по тестированию и начинайте предварительных вариантов тестирования для соответствующего эта- па разработки. В процессе разработки требований вы не можете водить никаких тестов, так как никакого ПО еще нет. Однако концепту- альные (то есть, не зависящие от реализации) варианты тестировании, созданные на основе требований, позволят выявить ошибки, сти и пропуски данных в спецификации требований к ПО и проанали- зировать модели задолго до того, как разработчики приступят к напи- санию кода. Утверждение требований является четвертым этапом — наряду со сбором анализом и созданием спецификации — разра- ботки требований Moore, Утверждение зволяет удостовериться в том, что: Для описания этого этапа некоторые авторы используют термин и 1997). При проверке определяется, соответствует ли результат разработки на данном пе требованиям к нему (делается ли все правильно). При действи- тельно ли продукт отвечает потребностям клиента ли все в нужном В этой книге я использую терминологию «Software Engineering Body и Moore, и называю четвертую составляющую разработки требования утверждением. Глава Утверждение требований 285 1 в спецификации требований к ПО должным образом описаны пред- полагаемые возможности и характеристики системы, которые удов- летворят потребности различных заинтересованных в проекте лиц; I требования к ПО точно отражают системные требования, бизнес- правила и др.; требования полные и высококачественные; i все требования согласованы друг с другом; 1 требования обеспечивают качественную основу для дизайна и сборки ПО. Проверка подтверждает, что в документе представлены желаемые характеристики отличных требований корректные, осущест- вимые, необходимые, приоритетные, ясные и поддающиеся проверке) и отличных спецификаций к требованиям (полные, согласованные, мо- дифицируемые и поддающиеся отслеживанию). Разумеется, вы може- те утвердить только задокументированные требования, а не предпола- гаемые, которые существуют только в чьем-то воображении. это не один отдельный этап процесса, выполняе- мый после сбора и документирования требований. Некоторые прове- рочные мероприятия, например просмотр все более разрастающейся спецификации требований к ПО, выполняются после каждой процеду- ры сбора информации, ее анализа и документирования. Другие меро- приятия, такие, как официальная проверка спецификации требований к ПО, обеспечивают достижение того уровня качества, которое пред- шествует финальной версии спецификации. Включите в план проекта этапы утверждения требований в качестве отдельных задач, Участники проекта иногда с неохотой тратят время на проверку и тестирование спецификации требований к ПО. Интуитивно кажется, что если выделить время на улучшение качества требований, дата вы- пуска продукта задержится на такой же срок. Однако при таком отно- шении вы можете смело ожидать нулевых результатов от всех затраченных на утверждение. В действительности же эти усилия могут сократить график поставки, за счет уменьшения требуемых исправле- ний и ускорения интеграции и тестирования системы (Blackburn, Scud- и 1996). Capers Jones (1994) отмечает, что каждый который вы истратили на предотвращение появления дефек- тов, снизит затраты на исправление на сумму от 3 до долларов. Чем лучше требования, тем выше качество продукта и тем более доволен клиент, что в свою очередь снизит затраты на обслуживание, улучше- ние и клиентскую поддержку продукта. Инвестируя в качество продук- та, вы сохраните больше денег, чем потратили. 286 Часть II. Разработка требований к ПО Для оценки корректности и качества требований применяйте раз- личные приемы (Wallace и Один из таких приемов заклю- чается в измерении каждого требования, с тем чтобы вы смогли проду- мать способ измерения того, насколько хорошо предложенное реше- ние. Suzanne и James Robertson используют термин годности (fit criteria) подобных приемов (Robertson и Robertson, 1999). этой главе рассматриваются приемы проверки официальных и неофици- альных просмотров требований, разработки вариантов тестирования на основании требований и определения клиентом критериев прием- лемости продукта. Просмотр требований Всякое исследование продукта ПО на предмет выявления проблем любым другим лицом, кроме его автора, называется экспертной оцен- кой (peer review). Просмотр задокументированных требований — это эффективный прием выявления неясных или не поддающихся провер- ке требований, требований, которые были определены недостаточно ясно для разработки, а также других проблем. Различные типы экспертных оценок называются по-разному (Wieg- ers, 2002a). Неофициальные просмотры полезны при знакомстве лю- дей с продуктом и сборе отзывов о нем (формирование обратной свя- зи). Однако они несистематические, неполные и несогласованные. Есть несколько видов неофициальных просмотров требований: 1 проверка «за когда вы просите одного коллегу исследо- вать ваш продукт; проверка, когда вы приглашаете несколько коллег параллельной проверки продукта; i критический анализ, когда автор описывает продукт и просит его прокомментировать. В отличие от нарочито естественных неформальных просмотров, официальная проверка представляет собой строго ный процесс. По его завершении формируется отчет, в котором указа- ны материал, рецензенты и мнение команды рецензентов о приемле- мости продукта. Главный результат— совокупность всех найденных дефектов и поднятых вопросов. Члены команды, которая выполняет официальный просмотр продукта, делят ответственность за качество проверки, хотя в конце концов за качество продукта отвечают все-таки его создатели 1990). перейти в каталог файлов | Образовательный портал Как узнать результаты егэ Стихи про летний лагерь 3агадки для детей |
