Технологии программирования - Wiegers.Software R. Development Productivity Award Москва 2004 удк 004. 45 В41 Карл Разработка требований к программному с англ. М. дом Русская Редакция, 2004. ил. Isbn 5750202402 Эта книга
 Скачать 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. Показать все связанные файлыГлава 8. Как понять требования пользователей 143 Участники семинара, посвященного Chemical Tracking System, начи- нали каждое обсуждение с определения действующего лица, которое получит преимущество варианта использования, и краткого описания этого варианта. Затем они указывали предварительные ус- ловия и выходные условия, ограничивающие вариант использования, а также все этапы внутри этих границ. Выяснив частоту вы на ранних стадиях получите представление о необходимости и важ- ности Далее аналитики спрашивали как те се- бе представляют взаимодействие с системой для выполнения Установленная последовательность действий лиц и реакции системы как нормальное направление. Нумерация этапов по- следовательности окончательно проясняла ситуацию. Хотя у каждого участника было свое представление об интерфейсе и специальных ме- ханизмах взаимодействия, группа смогла выработать общее понима- ние важнейших этапов диалога системы и пользователя, Придерживаясь границ вариант использования из восьми этапов, я понял, что выходные удовлетворены уже после пятого этапа. Следовательно, этапы 6, 7 и 8 были излиш- ними, так как выходили за границы варианта использования. Точно так же предвари- тельные условия варианта использования должны удовлетворены до начала этапа. Изучая описание варианта использования, убедитесь, что предвари- тельные и выходные условия ограничивают его соответствующим образом. Аналитик фиксировал действия отдельного лица и реакцию систе- мы на отдельных клейких листочках, которые затем прикреплял на схе- му. Возможен и другой способ проведения — в ходе дения спроецировать с помощью компьютера шаблон варианта ис- пользования на большой экран и отредактировать его, хотя иногда это замедляет обсуждение. Команда, занимающаяся сбором информации, разработала гичные диалоги для определения альтернативных направлений и ис- ключений. Если пользователь говорит: «По умолчание это должно значит, он описывает нормальное направление развития ва- рианта использования. Такая фраза, как: «Необходимо, чтобы пользо- ватель также предполагает обсуждение альтернативное на- правление. Многие условия исключений удавалось выяснились, когда аналитик задавал примерно такие вопросы: «Что должно произойти, если в текущий момент БД отключена?» или «Что, если этого химиката нет в На семинаре также удобно обсудить ожидания поль- зователей, касающиеся качества продукта, например времени реак- Часть II. Разработка требований к ПО доступности и надежности системы, ограничений дизайна интерфейса и требований по безопасности. После того как участники семинара описали каждый вариант ис- пользования, и никто не предлагал уже никаких дополнительных исключений или специальных требований, приступали к дующему варианту использования. Участники не пытались рассмот- реть все варианты использования за одно марафонское обсуждение или точно определить все детали каждого варианта Они запланировали изучение вариантов использования по щей и их последующее многократное рассмотрение и уточнение, На рис. 8-5 показана последовательность этапов разработки антов использования. После семинара аналитик детально фиксирова каждый вариант использования, как на рис. 8-6, Существует два спо- соба представить этапы взаимодействия пользователя и системы, торые и составляют основу варианта использования. На рис. 8-6 диа- лог представлен в виде пронумерованного списка этапов с указанием того, какой элемент (система или определенное действующее лицо) выполняет каждый шаг. Так же описываются и альтернативные направ- ления и исключения, для которых показан этап нормального направле- ния развития, на котором появляется ответвление, или этап, где можно исключение. Существует еще один прием — описать процесс средствами таблицы из двух столбцов, как показано на рис. 8-7 Brock, Действия лица показаны в левом столбце, а реакция темы — в правом. Цифры указывают на последовательность этапов диалога. Эта схема отлично работает, когда с системой взаимодейст- вует только один пользователь. Чтобы сделать эту таблицу более по- нятной, вы можете записать каждое действие или реакцию системы в отдельной строке, чтобы альтернативная последовательность очевидной, как показано на рис, 8-8. Часто варианты использования содержат дополнительную или требования, которые не годятся ни для одного из разделов шаблона. Для таких данных предусмотрен раздел «Специальные тре- бования»: сюда записывают атрибуты качества, тре- бования к производительности и др. Также зафиксируйте любую ин- формацию, которая может пользователям, например необходимое для завершения варианта использования неявное модействие одной системы с другой. Глава 8. Как понять требования пользователей Рис. 8-5. Сбор информации для варианта использования Идентификатор вари- Вариант ис- Название варианта использования Дата ИИ 04.12.02 Автор последнего обновления Дата обновления Запросить 27.12.02 Действующее Сотрудник, разместивший заказ на химикат Сотрудник, разместивший заказ на химикат, в необходимый химикат, вводя его название или номер химиката или импорти- руя его структуру из соответствующего графического средства. Система выполня- ет запрос, предлагая новый или контейнер с химикатом со скла- да или позволяя создать запрос на заказ у стороннего Предварительные условия Выходные Личность пользователя 2. Пользователь имеет право запрашивать 3. База данных запасам химикатов в данный момент подключена. Запрос сохраняется в Chemical Tracking System. 2. Запрос был отправлен по электронной почте на химикатов или поставщику, Рис. 8-6. Фрагмент описание варианта использования 146 Часть II. Разработка требований к ПО Нормальное ление вари- анта 1.0 химикат со склада указывает требуемый химикат. 2. Система что такой доступен, 3. Система перечисляет контейнеры с необходимым химикатом, имеющиеся на складе. 4. Сотрудник может просмотреть историю любого контейнера. 5. Сотрудник выбирает определенный контейнер или просит отправить запрос поставщику (альтернативное направление Б. Сотрудник вводит остальную информацию, чтобы завершить запрос. 7. Система сохраняет запрос и отправляет его по электронной почте на склад химикатов. на- правление варианта использо- вания Включение химикат у поставщика (ответвление после этапа 5) Сотрудник ищет химикат по каталогам поставщика. 2. Система отображает список поставщиков, где также указаны размеры, класс и цена контейнеров. 3. Сотрудник выбирает поставщика, размер, класс и количество контейнеров. 4. Сотрудник вводит остальную информацию, чтобы запрос. 5. Система сохраняет запрос и его по электронной почте поставщику, Химикат доступен (на этапе 2). Система отображает сообщение «Химикат не существует". 2. Система спрашивает сотрудника, хочет ли он запросить другой химикат или выйти из программы. За. Сотрудник просит запросить другой химикат. 4а. Система начинает нормальное направление развития варианта Сотрудник решает выйти из системы. Система завершает вариант использования. Химиката нет в продаже (на этапе 5). Система отображает сообщение поставщика этого химиката». 2. Система спрашивает сотрудника, хочет ли он запросить другой химикат или выйти из программы. За. Сотрудник запрашивает другой химикат. 4а. Система заново начинает нормальное направление развития варианта ис- пользования, Сотрудник решает выйти из системы. завершает использования. Вариант Просмотреть хронологию контейнера Приоритет Частота Используется примерно пять раз в неделю каждым химиком, раз в неделю ка- ния работником склада. Бизнес-правила Только сотрудник, получивший разрешение заведующе- го лаборатории, может химикаты. Рис. 8-6. Фрагмент описание варианта использования «Запросить химикат» Глава 8. Как понять требования пользователей 147 Специальные Система должна химические структуры форме из любых средств, рисование химических Импортированные химические структуры должны достоверными, и вопросы Тим выяснит, нужно ли руководства для запроса относя- к уровню 1 списка опасных Дата выполнения: 04.01.03. Рис. 8-6. Фрагмент описание варианта использования «Запросить химикат» (продолжение) Укажите 4. запросите 5. Выберите отправить заказ направление 2. Убедится, что химикат существует. 3- Отобразит список с в на складе. Рис. 8-7. Описание этапов варианта использования в двухстолбцовом формате Действия лица Укажите химикат. 4. нужно, 5. Выберите контейнер или попросите заказ поставщику 1. что такой химикат существует, с необходимым химикатом, в данный момент на складе. Рис. Альтернативный макет для описания этапов варианта в двухстолбцовом формате Вам не необходимо полное описание варианта использова- ния. Alistair Cockburn описывает и (fully шаблоны вариантов использования (последний показан на рис. 8-6). Рабочий вариант использования — это просто текстовое из- ложение целей пользователя и взаимодействий с системой; что-то вроде раздела «Описание» на рис. 8-6. Рассказы кото- рые рассматриваются как требования в экстремальном программиро- вании, представляют собой, по существу, рабочие версии варианта ис- пользования, как правило, написанные на учетных карточках (Jeffries, Anderson и Hendrickson, Полные описания вариантов использо- вания необходимы, если: Часть II. Разработка требований к ПО I в работе над проектом представители пользователей действуют не в тесной связи с I приложение сложное, и высок риск сбоев системы; описания вариантов использования — это самый низкий уровень детализации предназначенный для разработчиков; i вы планируете разработать подробные варианты тестирования на основании пользовательских требований; I для совместной работы территориально удаленных друг от друга команд необходимо детальные общие данные. Ловушка Не пытайтесь догматически определять количество деталей, которые необходимо включить в вариант помните, что ваша задача - доста- хорошо разобраться, для чего система нужна пользователям, чтобы разра- ботчики могли заняться приложением, не опасаясь необходимости будущих пере- делок. На рис. 8-5 показано, что после каждого семинара аналитики Chem- ical Tracking System выявляли функциональные требования к ПО на нове описаний вариантов использования об этих темах — в следующем разделе главы). Они также создали модели анализа некоторых сложных вариантов использования, например диаграмму перехода состояний, показывающую все возможные состояния запро- са химиката и все допустимые изменения состояний. Спустя день или два после семинара аналитик раздал описания ва- риантов использования и функциональных требования участникам, чтобы те просмотрели их до начала следующего семинара. Эти просмотры выявили множество ошибок: ранее не ные альтернативные направления, новые исключения, некорректные функциональные требования и пропущенные этапы диалога. между семинарами хотя бы один день. Умственное расслабление, торое наступает, когда минует день или два после мозгового штурма, позволяет людям взглянуть на проделанную работу с новой точки зре- ния. Один аналитик, проводивший семинары каждый день, заметил, что участникам стало трудно находить ошибки в просматриваемых до- кументах, потому что информация была еще свежа в Они прокручивали в уме дискуссии, которые только что и не замечали ошибок, Глава 8. Как понять пользователей 149 информация В главе описано несколько анали- за для Chemical Tracking Ловушка Не ждите окончания сбора информации по чтобы про- сить пользователей заняться просмотром собранного материала. На ранних стадиях разработки Chemical Tracking System руководи- тель тестирования создал концептуальные варианты тестирования, не зависящие от специфики реализации, на основе вариантов использо- вания (Collard, Эти варианты тестирования помогли прийти ко- манде к общему четкому пониманию как система должна функ- ционировать при реализации определенных сценариев использова- ния. Эти варианты тестирования позволили аналитикам проверить, действительно ли выявлены все функциональные требования, необхо- димые для выполнения пользователями каждого варианта использо- вания. На заключительном семинаре, участники вместе провели кри- тический анализ вариантов тестирования, чтобы убедиться, что одина- ково понимают, как должны работать варианты использования. Как и при любом контроле качества, они нашли ошибки и в требованиях, и в вариантах тестирования. информация В главе детально обсуждается, как соста- вить варианты тестирования на основании требований. Варианты использования продукта и функциональные требования Разработчики ПО не реализуют бизнес-требования или варианты ис- пользования. Они реализуют функциональные требования, опреде- ленные фрагменты поведения системы, позволяющие клиентам вы- полнять варианты использования и выполнять свои задачи. Варианты использования описывают поведение системы с точки зрения дейст- вующего лица, при этом упускается множество деталей. Чтобы разра- ботать и реализовать систему должным образом разработчику необ- ходимо ознакомиться с множеством точек зрения. Некоторые практики считают, что варианты использования это и есть функциональные требования. Однако мне случалось видеть, как возникали проблемы из-за того, что варианты использования просто Часть II. требований к ПО передавались разработчикам для реализации. Варианты использова- ния описывают точку зрения пользователя, его взгляд на внешнее, видимое поведение системы. В них не содержится всей которая необходима для написания ПО, Так, использующему банковский не важно, какие действия этот автомат должен выполнить, например взаимодейство- вать с компьютером банка. Эти детали невидимы для пользователя, однако разработчик должен о них знать. Естественно, в описания использования могут такие детали подобных неоче- видных однако, как в ходе дискуссий с телями такие вопросы не поднимаются. Даже у разработчиков, кото- рым передали полные варианты использования, часто возникает много вопросов. Чтобы уменьшить эту неопределенность, я рекомен- дую аналитикам требований ясно расписывать детали функциональ- ных требований, необходимых для реализации каждого варианта ис- пользования 1998). Многие функциональные требования не записаны в последователь- ности диалогов действующего лица и системы. Некоторые из них оче- видны, например: «Система назначит уникальный порядковый номер каждому запросу» Нет смысла повторять эти детали в спецификации требований к если они совершенно ясно указаны в варианте пользования. Другие функциональные требования не входят в ние варианта использования. Их выявляет аналитик на основании представления о варианте использования и операционной среды системы. Преобразование требований, как их видит пользователь, в форму, полезную — задача аналитика, один из многих способов, позволяющих ему обогатить проект. В Chemical Tracking System варианты использования в применялись в качестве механизма для определения необходимых функциональных требований. Аналитики составляли только рабочие описания наименее сложных вариантов использования. Затем они вы- являли все функциональные требования, которые после реализации позволяли выполнять все варианты использования, в том числе тернативные направления и обработчики исключений. И далее доку- ментировали эти функциональные требования в спецификации требо- ваний к ПО, сформированной с учетом особенностей продукта. Задокументировать функциональные требования, связанные с риантом использованием, можно несколькими способами. Выбор способа зависит от того, как ваша команда будет выполнять дизайн, сборку и тестирование — на основе документации о вариантах исполь- зования, спецификации требований к ПО или применяя оба этих 8. Как требования пользователей мента. Ни один этих методов нельзя назвать идеальным, поэтому выберите тот, что лучше позволит вам документировать и управлять требования к ПО вашего проекта. Только варианты использования Вы можете включить функциональные требования непосредственно в описание каждого варианта использования. Независимо от этого вам понадобится отдельная дополнительная спецификация для фиксиро- вания нефункциональных и всех функциональных требований, кото- рые не связаны с конкретными вариантами использования. Несколько использования могут нуждаться в одном и том же функцио- нальном требовании, Если для пяти вариантов использования потре- буется аутентификация пользователя, вам вряд ли захочется писать пять разных блоков кода. Вместо их повторения, установите перекре- стные ссылки на функциональные требования, присутствующие в не- скольких вариантах использования. Иногда вариант использования включает о которых говорилось ранее в этой главе и ко- торые являются решением проблемы. Варианты использования и спецификация требований к ПО Другая возможность — в довольно простой форме описать использования и задокументировать функциональные вы- явленные из каждого варианта использования в спецификации требо- ваний к ПО. В этом случае вам придется установить трассируемость между вариантами использования и связанными с ними функциональ- ными требованиями. Лучше всего управлять трассируемостью, если вы сохраните все варианты использования и функциональные требо- вания в средстве управления требованиями. информация Подробнее о средствах управления требова- ниями - в главе Только спецификация требований к ПО Третий способ — упорядочить спецификацию требований к ПО по ва- риантам использования или функциям и включить последние в специ- фикацию. Именно его и применяли специалисты, работавшие над Chemical Tracking System. В этой схеме нет отдельных документов для вариантов использования. Вы определяете повторяющиеся функцио- нальные требования или указываете каждое функциональное требова- Часть II. Разработка требований к ПО только один раз и ссылаетесь на него при каждом появлении его в другом варианте использования. Преимущества способа с применением вариантов использования Преимущества применения вариантов использования в том, что каждый вариант на поставленной задаче и ле. Пользователи будут более четко представлять, что же им даст вая система, если вы выберете способ, который на функциях системы. При разработке нескольких представители клиентов что варианты использования им более четко представить, какие возможности должны чить посетители их Web-сайтов. А аналитики и разработчики смогли разобраться и в пользователей, и в предметной области. Тщательное изучение этапов взаимодействия лица и мы помогает еще на ранних стадиях разработки выявить неясности и а также позволяет составить варианты тестирования на основе вариантов использования. Очень расточительно и болезненно для разработчиков писать код, которым никогда не удастся воспользоваться. Если вы будете временно определять требования и включать в них все мыслимые функции, то рискуете создать избыточные требования. Способ с при- менением вариантов использования позволяет выявить функциональ- ные требования, с помощью которых пользователи будут конкретные задачи. Так вы предотвратите появление «функций-си- рот», тех, что в ходе сбора информации казались весьма полезными, однако которыми никто че будет пользоваться из-за того, что они не связаны напрямую с решением рабочих задач, Способ с применением вариантов использования облегчает расста- новку приоритетов требований. Высшим приоритетом обладают те функциональные требования, которые созданы на основе вариантов использования с высшим приоритетом. Высший приоритет ся по следующим причинам: § варианты импользования описывают один из основных бизнес-про- цессов, активизируемых системой; многие пользователи часто обращаются к ним; £ их запросил привилегированный класс пользователей; i они предоставляют необходимые для соответствия требованиям; $ функции других систем зависят от их наличия. | Образовательный портал Как узнать результаты егэ Стихи про летний лагерь 3агадки для детей |
