WWW.DISSERS.RU

БЕСПЛАТНАЯ ЭЛЕКТРОННАЯ БИБЛИОТЕКА

   Добро пожаловать!

Pages:     | 1 |   ...   | 2 | 3 || 5 | 6 |   ...   | 9 |

«Разработка требований к программному обеспечению Практические приемы сбора требований и ими при разработке программного продукта Карл И. Вигерс Дважды лауреат Software Development Productivity Award ...»

-- [ Страница 4 ] --

Приложение Б. Модели анализа В этом необязательном разделе описывается, а точнее напоминается о таких моделях анализа, как диаграммы потока данных, диаграммы классов, диаграммы перехода состояния и диаграммы связь» (см. главу Приложение В. Список вопросов Это динамический список еще не разрешенных проблем, связанных с требованиями. Это могут быть элементы, помеченные (to be determined — необходимо определить), отложенные решения, необхо димая информация, неразрешенные конфликты и т.п. Все это не обя зательно включать в спецификацию требований к ПО, но в некоторых организациях принято прилагать список к спецификации требо ваний к ПО. Постарайтесь как можно быстрее разрешить эти пробле мы, чтобы они не стали препятствием к своевременному созданию ос нов спецификации требований к ПО высокого качества.

Принципы создания требований Не существует выверенного способа написания идеальных а лучший учитель — это опыт, который нарабатывается со нем. Безупречную документацию по требованиям отличает техниче ский стиль изложения и пользовательская терминология, а не компью терный сленг. (1999) предлагает множество рекомендаций и примеров на эту тему. Вот некоторые из них:

Глава 10. Документирование требований используйте полные с правильной грамматикой, пра вописанием и пунктуацией. Предложения и абзацы должны быть краткими и ясными;

используйте действительный залог «Система сделает то-то», а не «Произойдет последовательно используйте термины и именно так, как они опре делены в словаре. Остерегайтесь синонимов и слов, близких по значению. Не следует в спецификации требований к ПО пытаться разнообразить лексику, чтобы заинтересовать читателя;

нечеткие требования верхнего уровня следует детализировать та ким образом, чтоб они стали абсолютно ясны;

требования следует излагать последовательно, например «Сис тема будет» или «Пользователь будет», затем — активный а после — наблюдаемый результат. Укажите инициирующие усло вия или действия, вследствие которых система ведет себя опре деленным образом. Например, «Если запрошенный химикат най ден на складе химикатов, система отобразит список всех храни мых на складе контейнеров с указанным химикатом». Вы можете использовать «должно» как синоним «будет», однако следует из бегать «следовало бы», «можно было бы» и аналогичных слов, из которых не ясно, необходимо ли действие;

при указании требования в форме «Пользователь будет...» иденти фицируйте определенного исполнителя (например, «Покупатель применяйте списки, рисунки, графики и таблицы, чтобы предста вить информацию визуально. Читателей утомляет большой объем сплошного текста;

подчеркните наиболее значимые фрагменты информации. Здесь годятся: графики, последовательности, в которых первый элемент подчеркивается, повторы, пустое пространство и визуальный кон траст, например затенения (Kovitz, 1999);

требования, изложенные неясным языком, не поддаются проверке, поэтому избегайте двусмысленных и субъективных терминов, В табл. 10-1 перечислены некоторые из а также приводятся ре комендации, как исправить такие неясности, Ловушка Оценка качества требований зависит от того, кто их оценивает. Анали тик может верить, что создал абсолютно ясный, безо неясностей и проблем. Однако если у читателей возникли вопросы, значит, требуется доработка.

194 Часть II. требований к ПО Таблица Неоднозначные термины, которых следует избегать в спецификаций к требованиям Неоднозначные термины Способы их улучшения адекватный Определите, что понимается под и как система это может оценить Практически выполнимо Не заставляйте разработчиков определять, что под этим пони мается. Прставьте пометку «TBD» и определите дату, к которой эту проблему следует разрешить По меньшей Укажите минимальное и максимальное как минимум, не более чем, допустимые не должно превышать Между Определите, указаны ли конечные точки Зависит от Определите природу зависимости. Обеспечивает ли другая система ввод данных в вашу систему, надо ли установить дру гое ПО до запуска вашей системы и зависит ли ваша система от другой при выполнении определенных расчетов или служб?

Эффективный Определите, насколько эффективно система ресурсы, насколько быстро она выполняет определенные операции и насколько она проста в обращении Быстрый, моментальный Укажите минимальную приемлимую скорость, при система выполняет определенное действие Гибкий Опишите способы изменения системы в ответ на изменения условий или бизнес-потребностей Улучшенный, лучший, более Определите количественно, насколько лучше или быстрее быстрый, превосходный стали показатели в определенной функциональной области включает в себя, Список элементов должен включать все возможности.

но не огранечен этим;

и т.д.;

В противном случае его нельзя использовать при разработке и т.п.;

такой как или Укажите минимальное и максимальное допустимые значения руйте, оптимизируйте определенного параметра в Также опишите поведение системы при нештатных или неиде варианте условиях Глава 10. Документирование требований Таблица 10-1. Неоднозначные термины, которых следует избегать в спецификаций к требованиям Неоднозначные термины их улучшения Укажите, делает выбор: системы, пользователь или разра Необязательно ботчик Разумный, при необходи- Объясните, как это выполнить мости, при условиях Устойчивый к сбоям Определите, как система должны обрабатывать исключения и реагировать на работы Цельный, прозрачный, Выразите ожидания пользователя, применяя характеристики элегантный продукта, которые можено наблюдать Несколько Укажите сколько или задайте минимальную и максимальную границы диапазона Не следует Старайтесь формулировать требования в позитивной описывая, что именно система будет делать Реальный Поясните этот термин Достаточный Укажите, какая степень чего-либо свидетельствует достаточности Поддерживает, позволяет Дайте точное определение, какие действия система будет выполнять, поддерживая конкретную возможность Дружественный, простой, Опишите системные характеристики, которые будут отвечать легкий потребностям пользователей и его ожиданиям, касающимся легкости и простоты применения продукта Составляйте требования настолько подробно, чтобы при удовлетво рении требования задача клиента была бы выполнена, однако избегай те ненужных ограничений разработки. Требования должны быть сфор мулированы достаточно подробно, чтобы риск непонимания был мини мальным, для этого необходимо учесть знания и опыт разработчиков.

Если разработчики предлагают несколько способов удовлетворения требования и все они приемлемы, значит, особенности продукта и де тализация изложения выбраны верно, Точно сформулированные требо вания повышают вероятность того, что ожидания клиентов будут реали менее строгие формулировки дают разработчикам больше 196 II. Разработка требований к ПО свободы для интерпретаций. Если разработчику по составленной цификации не удается абсолютно ясно представляет себе ожидания клиентов, следует включить дополнительную информацию, чтобы зить риск последующих исправлений.

Создатели документации зачастую тратят массу чтоб «пой мать» нужный уровень детализации. Попробуйте отдельно описать требования, которые можно протестировать. Если вам удастся приду мать несколько вариантов тестирования, значит, необходимый уро вень достигнут. Если ваши тесты многочисленны и разно образны, несколько требований соединены вместе;

их сле дует разделить на более простые. Тестируемые требования предложены в качестве атрибута размера ПО (Wilson, При написании требований соблюдайте уровень детализации. Мне приходилось видеть в одной и той же спецификации положения, кото рые значительно варьировались в их границах. Например, ция клавишей будет интерпретироваться как Сохранить файл» и «Комбинация клавишей будет интерпретироваться как файла» считались отдельными требованиями, а «Продукт будет реаги ровать на команды редактирования, введенные голосом» описывалось как целая подсистема (или даже а не одно требование.

Избегайте длинных повествовательных абзацев, которые несколько требований. Наличие в требовании таких слов, как «или» и «также», предполагает, что несколько требований могли объединены. Это не означает, не можете использовать союз ••>, но если вы делаете это, проверяйте, соединяет ли он две части одного требования или два отдельных требования. Никогда не «и/или» в требованиях;

это оставляет читателю свободу маневра. Та кие выражения, как «пока не» и «кроме» также указывают на наличие нескольких требований: «Кредитная карточка покупателя будет счи таться действительной для платежей до тех пор, пока не истечет ее срок действия». Разделите это положение на два — для двух когда срок действия кредитной карты истек и когда она действительна, Избегайте излишних положений о требованиях. Повторяя требова ний в нескольких местах спецификации требований к ПО, вы те чтение документа, но затрудняете его поддержку. Одинаковые бования придется изменять одновременно, в противном случае воз никнет несогласованность. Перекрестные ссылки на связанные между собой элементы в спецификации помогут вам синхронизировать по следние при внесении изменений. Сохраняя отдельные требования в средстве управления требованиями или в базе данных только один Глава 10. Документирование требований раз, вы решите проблему избыточности и упростите повторное пользование общих нескольких проектов.

Попытайтесь найти наиболее эффективный метод представления каждого требования. Как-то я проверял спецификацию требований к ПО, в которой содержался набор предлагаемый в качест ве образца: «Текстовый редактор сможет проанализировать докумен ты следующего определяющих постановления следующей Предлагалось три возможных значения и четыре возможных значения для двенадцати схожих требований. Однако из этих двенадцати одного не хватало, а одно повторялось. Найти ошибку можно было одним единственным образом — составить таблицу всех возможных вариантов и проверить их. Ошибку удалось бы предотвратить, если требования в специфика ции были составлены по образу и подобию табл. Требования бо лее высокого уровня могут звучать так: Текстовый редактор сможет провести анализ документов нескольких форматов, опреде ляющих постановления на уровнях юрисдикции, как показано в табл, Если у какой-либо комбинации нет соответствующего функцио нального укажите в ячейке таблицы Н/П применимо).

Таблица 10-2. Образец табличного формата номеров в качестве образца Уровень юрисдикции Теговый Формат ASCII формат Федеральный ТРИ 3. [на уровне штата] Территориальный (местный) Международный Примеры требований: до и после В главе 1 перечислено несколько характеристик качественно сформу лированных требований: полные, выполнимые, необхо димые, имеющие приоритет, точно выраженные и поддающиеся про верке. Поскольку наличие требований, не отвечающих этим характе ристикам, приводит к напрасно затраченным усилиям и последующим переделкам, старайтесь разрешить проблемы на ран Часть II. Разработка требований к ПО них стадиях работы. Далее я покажу несколько далеких от ства требований, взятых из реальных проектов. Исследуйте каждое них, используя перечисленные ранее характеристики качества, и по пытайтесь определить проблему. Для начала, например, поддаются ли они проверке. Если вам не удастся составить бы точно сказать, были ли требования реализованы соответствующим возможно, они неясно сформулированы или не хватает обходимой информации.

Я высказал свои соображения о проблемах для каждого и предложил несколько путей их решения. Дополнительные еще их однако на определенном этапе вы должны к непосредственному написанию ПО. Больше примеров по нию неудачных требований изложено Hooks и (2001), (2002), а также Alexander и Stevens (2002).

Ловушка Старайтесь избегать паралича аналитического процесса. Нельзя тра тить слишком много времени на попытки сделать требования идеальными. Ваша цель - написать требования, которые хороши достаточно, чтобы разработчики мог ли приступить к продукта при приемлемом уровне риска.

Пример 1. «Диспетчер фоновых задач обеспечивает сообщение о со стоянии через регулярные интервалы, не менее 60 се Что понимается под сообщениями о состоянии? При каких условиях и как именно они поставляются пользователю? Какдолго они остаются после их отображения? Продолжительность временного интервала не сформулирована точно, а слово только вносит дополнительную неясность. Один из способов оценить требование — проверить, устраивают ли пользователя нелепые, но имеющие на существование интерпретации этого требования. Если нет, то над требованием необходимо еще поработать. В этом примере интервал должен равняться по крайней мере 60 секундам;

таким образом, если сообщение будет появляться раз в год, это нормально? А если жуток не должен превышать 60 секунд, то будет ли интервал, одну миллисекунду, слишком коротким? Эти утрированнье интерпретации не выходят за рамки первоначального совершенно очевидно, что пользователь хотел совершенно Из-за этих причин требование нельзя проверить, Глава 10. Документирование требований А вот возможные способы исправления недостатков этого требова ния, которыми вы можете воспользоваться после того, как получите дополнительную информацию от клиента, Диспетчер фоновых задач отобразит сообщения о состоянии в назначенной области пользовательского интерфейса.

1.1 Сообщения будут обновляться каждые 60 секунд плюс/минус 10 секунд после фоновой задачи.

1.2 Сообщения должны оставаться видимыми постоянно.

1.3 Если взаимодействие с фоновой задачей возможно, то ДФЗ отобразит процент выполнения фоновой задачи.

1.4 По завершению фоновой задачи ДФЗ отобразит сообщение «Выполнено».

1.5 Если выполнение фоновой задачи остановлено, ДФЗ зит соответствующее сообщение.

Я разделили это требование на нескольких дочерних, потому что для каждого понадобится отдельный тестирования, кроме го, так каждое проще отслеживать. Если несколько требований динено в один абзац, то при сборке или тестировании существует опасность пропуска одного из них. В измененном требовании не зан способ отображения сообщения о состоянии. Это проблема зайна;

если вы сейчас определите ее здесь, то разработчики воспри мут ее как ограничение, а это может их расстроить. Кроме того, в случае вряд ли можно рассчитывать на оптимальный продукт.

Пример 2. должен моментально переключаться между режимами отображения к сокрытия непечатаемых символов».

Компьютеры не могут сделать что-либо поэтому это требование невыполнимо. Кроме того, это требование неполное, по скольку в нем не указана условие переключения. Выполняет ли это из менение при определенных условиях само ПО или это происходит по инициативе пользователя? Какая часть документа изменяется: выде ленный фрагмент текста, весь документ, текущая страница или что-то еще? Какие именно непечатаемые символы: скрытый текст, управляю щие символы, тэги разметки или что-то еще? До тех пор пока на вопросы не будут получены требование будет невозможно проверить. Вот как это требование можно улучшить:

«Пользователь сможет переключать отображение и сокрытие всех тэгов в редактируемом документе с помощью активации механизма определенного триг гера. Отображение должно в течение секунды или менее».

Вот теперь стало ясно, что непечатаемые символы — это тэги раз метки Мы знаем, что пользователь инициирует изменение изо 200 Часть II. Разработка требований к ПО но требование не ограничивает разработку определением точного механизма. Мы также добавили требование производительно сти, которое определяет, как быстро отображение должно изменяться.

«Моментально» означает «моментально для зрения человека», что вполне достижимо на достаточно быстром компьютере.

Пример 3. выведет отчет об ошибках в разметке, помощью которого даже пользователи, мало знакомые с языком смогут быстро устранить ошибки».

Многозначное слово «быстро» относится к действию, выполняемо му человеком, а не анализатором. Из-за этого недостаточного объяс нения сообщение об ошибке определено не полностью, кроме того, мы не знаем, когда создается этот отчет. Как проверить это требова ние? Найдите какого-нибудь новичка в XML и посмотрите, сможет ли он быстро исправить ошибки с помощью этого отчета?

Это требование содержит важное понятие определенного класса пользователей — в данном случае это пользователи, мало знакомые с XML, которым нужна помощь ПО для нахождения синтаксических оши бок Аналитик должен найти подходящего представителя этого класса пользователей, чтобы выяснить, какую информацию следует поместить в отчет об ошибке анализатора разметки. Попробуем вме сто этого другой способ.

После того, как XML Parser полностью файл, он генерирует отчет об ошибках, в котором указан номер строки и текст любых XML-ошибок, обнару женных в анализируемом файле, а также описание каждой найденной ошибки.

2. Если никаких ошибок в разметке не было найдено, отчет не генерируется.

Теперь мы знаем, когда создается отчет об ошибках и что в нем со держится, однако то, как отчет будет выглядеть, мы оставили на рение дизайнера. Мы также сформулировали условие исключения, торое первоначальное не если ошибки he найдено, генерировать отчет не надо.

Пример 4, «Если возможно, счетов следовало бы по списку корпоративных счетов».

Что означает «если возможно»? Технически осуществимо? Или ко гда доступен основной список счетов во время запуска? Если вы не уверены, можно ли реализовать функцию, сделайте пометку чтобы указать, что эта проблема еще не решена. После проверки одно из двух будет ликвидировано — либо пометка либо требование.

В требовании не что произойдет, если проверка пройдет ус пешно или окончится неудачей. Избегайте неточных слов вроде «сле довало бы». Некоторые авторы требований пытаются выразить тонкие Глава 10. Документирование требований различия, используя «следовало и «возможно», чтобы подчеркнуть значимость. Я предпочитаю использовать «будет» или «должен» как ясное указание на цель требования и приоритеты. Вот как выглядит исправленный вариант требования.

«В момент ввода номера счета система проверит его по основному корпоративному списку счетов. Если номер счета в списке не найден, система отобразит сообщение об ошибке и не примет заказ».

Связанное требование будет относиться к условию исключения: ос новной список счетов не доступен во время проверки достоверности.

Пример 5. «В редакторе не будет функций поиска и замены, резуль таты которых могут быть катастрофичными».

Понятие «катастрофичные результаты» можно интерпретировать по-разному. Непреднамеренное глобальное изменение может обер нуться катастрофой, если пользователь не обнаружит ошибку или не может ее исправить. Будьте благоразумны при составлении обратных требований, описывающих, что система не будет делать. Основная за бота в этом защита содержимого файла от непреднаме ренных повреждений или потерь. Возможно, настоящие требования выглядят так.

1. Редактор будет подтверждения от пользователя, где тот должен подтвердить глобальные изменения текста, удаления и вставки, которые могут привести к потере данных.

2. В приложении будет реализована многоуровневая функция отмены, ограничен ная только системными ресурсами, которые доступны приложению.

Пример 6. «Испытательный прибор позволит пользователю легко подключить дополнительные компоненты, в том числе импульсный ге нератор, вольтметр, измеритель емкости и нестандартные Это требования к продукту, содержащему встроенное ПО, которое используется для тестирования различных типов измерительных при боров. Слово «легко» подразумевает требование легкости и простоты использования, но он не измеряемо и не поддается проверке. «В том числе» не дает ясности, полный ли это список внешних устройств, ко торые должны быть подключены к испытательному устройству, или су ществует еще множество других приборов, о которых мы не знаем. Вот какие альтернативные требования содержат хорошо обдуманные ог раничения дизайна.

Испытательное устройство содержит USB-порт, чтобы пользователь смог под ключить любое измерительный прибор, у которого есть 202 Часть II. Разработка требований к ПО 2. будет установлен на передней панели чтобы позволить квали фицированному оператору подключить измерительный прибор за секунд или менее.

Словарь данных Давным-давно я вел проект, в котором три программиста иногда не брежно использовали различные имена, длину переменных и рий достоверности для одного и того же элемента. Результат очеви ден: путаница с определением, повреждение данных и го ловная боль при обслуживании. Мы пострадали из-за отсутствия словаря данных (data dictionary) — общего хранилища, где значение, тип данных, длину, формат, необходимая точности л допустимые диапазоны значений или список значений всех элементов данных и атрибутов, используемых в приложении.

Информация в словаре данных связывает различные представления требований. Проблема целостности становится меньше, если все работчики будут придерживаться определений из словаря данных.

ните собирать определения данных еще в процессе выявления ваний. Словарь данных дополнит словарь где приведены оп ределения отдельных терминов. Вы можете объединить эти документы, хотя лично я предпочитаю хранить их отдельно. Словарем данных мож но управлять, как приложением к спецификации требований к ПО или как отдельным документом или файлом.

По сравнению с определениями данных, размещенными в различ ных местах функциональных требований, отдельный словарь облегчает поиск необходимой информации, а также помогает избе жать ненужных повторов и несогласованности. В некоторые ские средства анализа и дизайна входит компонент словаря данных.

Если вы устанавливаете словарь данных вручную, подумайте о приме нении гиперссылок. Щелкнув элемент данных, который представляет собой часть определения структуры данных, вы перейдете к нию этого элемента данных;

таким образом, перемещаться по иерар хическому дереву определений легко и просто.

Элементы в словаре данных представлены с помощью простой но тации Robertson и Robertson, 1994).

элемент расположен слева от знака равенства, а само определение справа. Так определяются простейшие элементы данных, ние нескольких элементов данных в структуры, необязательные менты итерация (повтор) элемента данных и список значений Глава Документирование требований элемента данных. Следующие примеры взяты из проекта Chemical Tracking System (ну откуда же Простейшие элементы данных. Простейшим элементом данных на зывается тот, дальнейшее упрощение которого невозможно или нужно. Его определение содержит тип простейших данных, размер, диапазон допустимых значений и другие подобные атрибуты. Про стейшие данные определяются с помощью комментария, т.е. текста.

ограниченного звездочками:

Request ID = * сгенерированный системой, последовательный состоящий из целого числа, начинающийся с образом идентифици рующий каждый запрос * Структура. Структура данных или записей содержит несколько эле ментов данных. Если элемент в структуре данных является необяза тельным, поставьте его в скобки:

Запрошенный химиката + Количество контейнеров + Класс +0бъем + Единицы объема + (Поставщик) Эта структура определяет всю информацию, связанную с запросом определенного химиката. Поставщик (vendor) является необязатель ным элементом, поскольку сотруднику, разместившему запрос, может быть кто именно поставил химикат. Каждый элемент дан ных в структуре должен быть определен в словаре данных. Структуры могут содержать другие структуры.

Повтор. Если в структуре данных содержится несколько экземпляров элемента данных, заключите этот элемент в фигурные скобки. Пока жите допустимое количество возможных повторов в формате перед открывающей скобкой:

Запроса + Дата запроса + Номер счета Этот пример показывает, что запрос химиката должен содержать по крайней мере один, но не более химикатов. К каждому запросу до бавлены атрибуты идентификатора, дата, когда запрос был создан, и номер счета для оплаты.

Выбор. Элемент данных, который может принять ограниченное число отдельных значений, называется перечисляемым простейшим. Пока 204 Часть II. Разработка требований к ПО жите возможные значения в списке внутри квадратных скобок, где элементы списка разделены вертикальными разделителями:

Единицы количества = | «килограммы» | «миллиграммы» | * текстовая строка, состоящая из 9 символов, указывающая единицы, связанные с количеством запрошенного химиката * Эта запись указывает на то, что существует только четыре допусти мых значения для текстовой строки Единицы Коммента рий, ограниченный звездочками, — это текстовое определение эле мента данных.

Время, потраченное на создание словаря данных, будет более чем компенсировано временем, которые вы сэкономите, избежав ошибок, возможных, если участники проекта по-разному понимают ключевые данные. Если вы регулярно обновляете словарь данных, он останется ценным средством и при обслуживании и при разработке схожих систем, Что теперь?

I Проверьте страницу функциональных требований в спецификации требований к ПО вашего проекта и убедитесь, что каждое положение демонстрирует характе ристики отличных требований. Перепишите все требования, которые не отвеча ют этому уровню.

Если в вашей организации еще нет стандартного шаблона спецификации требо ваний к ПО, соберите небольшую рабочую группу для его обсуждения. Начните с шаблона на рис. 10-1 и измените его так, чтоб он наилучшим образом соответ ствовал потребностям ваших проектов и продуктов. Выработайте стандарт име нования отдельных требований.

Пригласите от трех до шести лиц, заинтересованных в проекте, для проверки спецификации требований к ПО для вашего проекта Убедитесь, что каждое требование отвечает соответствующим характеристикам, о которых говорилось в главе Проверьте спецификацию на наличие конфликтов между различными требованиями в спецификации, недостающих требований и недос тающих разделов. Убедитесь, что обнаруженные недостатки, исправлены в спе цификации требований к ПО и в любых предыдущих продуктах, созданных на ос нове этих требований.

Возьмите комплексный объект данных из одного из ваших приложений и опре делите его с помощью образца словаря данных, представленного в этой главе.

Глава 10. Документирование требований Любое изображение стоит слов работающие над проектом Chemical Tracking System, выполняли первую проверку спецификации требова ний к ПО. В ней участвовали (менеджер проекта), Лори требований), Элен (ведущий разработчик), (руководитель тестирования), Тим (сторонник продукта от хи миков) и Роксана (апологет продукта от специалистов, тающих на складе химикатов). Тим начал со слов: "Я прочитал всю спецификацию требований. Большинство требований мне показались нормальными, но некоторые дались с трудом.

Я не уверен, что мы определили все этапы для процесса за проса было трудно продумать все варианты тестирования для того, чтобы раскрыть все возможные изменения статуса запро са, — добавил Рамеш. — Я обнаружил, что множество требова ний, касающихся статуса, разбросаны по всей спе цификации, но не могу твердо сказать, пропущены ли какие-то из них. Мне показалось, что пара требований конфликтует», Роксана обнаружила похожую проблему. сбило с столку описание того, как непосредственно выполнять запрос химика та, — сказала она. — Отдельные функциональные требования имели смысл, но мне трудно представить всю последователь ность действий при После того как остальные участники поделились своими опа сениями, Лори подвела итоги: с помощью специфи нам не удастся узнать о системе все, что необходимо. Я несколько картинок, чтобы нам было легче предста вить требования и понять, не прояснит ли это проблемные об ласти. Спасибо за то, что высказали ваше мнение".

206 Часть II. Разработка требований к ПО Согласно авторитетному мнению специалиста в области требований Alan Davis, никакое представление требований в одном виде не дает их полной картины (Davis, Необходима комбинация текстовых и визуальных способов представления требований, чтобы полная картина создаваемой системы. К таким способам относятся списки и таблицы, графические модели анализа, прототипы тельского интерфейса, варианты тестирования, деревья решений и таблицы решений. В идеале различные представления требований должны создавать разные специалисты. Аналитик может функциональные требования и нарисовать отдельные модели, дизай нер пользовательского интерфейса — создать прототип, а руководи тель тестирования — написать варианты тестирования. Сравнение представлений, созданных различными специалистами в ходе разно образных исследований, помогает выявить несоответствия, сти, допущения и упущения, которые трудно обнаружить, когда вания представлены в одном формате.

Определенные типы информации с помощью диаграмм удается связать гораздо эффективнее, чем с помощью текста. Изображения помогают преодолеть языковые барьеры и терминологические разно гласия между членами команды. Аналитику придется ос тальным заинтересованным лицам назначение используемых моделей и применяемые условные обозначения. В этой главе рассказывается о нескольких приемах моделирования требований с иллюстрациями и ссылками на другие источники, где можно получить более подробную информацию.

Моделирование требований Когда много лет назад я начал рисовать модели анализа, я надеялся найти единственный прием, позволяющий собирать всю в одно целостное отображение требований к системе. Со временем я понял, что подобной всеобъемлющей диаграммы не существует. Пер воначальной целью структурированных систем анализа была замена классической функциональной спецификации графическими диаграммами и системами обозначений, более формальными, текстовые комментарии (DeMarco, Однако опыт показал, что модели анализа должны дополнять — а не заменять — спецификации требований на естественном языке (Davis, К моделям визуального представления относятся диаграммы пото ков (data flow diagrams, DFD), диаграммы "сущность — связь» Глава Любое изображение стоит 1024 слов (entity-relationship diagrams, ERD), диаграммы перехода состояний (state-transition diagrams, STD), называемые также диаграммами со стояний, карты диалогов (dialog maps), диаграммы вариантов исполь зования которых рассказывалось в главе диаграммы классов и диаграммы (о них также рассказывалось в главе 8).

Системы обозначений, представленные здесь, обеспечивают стандартный для всей индустрии язык, которые участники проекта. Конечно, вы можете специально разработать чтобы возможности устного и письменного общения в рам ках проекта, однако не факт, что пользователи интерпретируют их оди наково. В то же время нельзя не признать ценность нестандартных приемов моделирования. Одна команда применяла средство для со ставления графика моделирования временных требований для встро енного ПО, причем за единицу измерения были приняты миллисекун ды, а не дни или недели.

Эти модели годятся разработки и изучения требований, а также для построения ПО. Будете ли вы использовать их для анализа или для дизайна, зависит от временных рамок и целей моделирования. При менение этих диаграмм для анализа требований позволит вам смоде лировать предметную область или создать концептуальные представ ления новой системы. Они отображают логические аспекты компонен тов данных предметной области, транзакции и преобразования, объекты реального мира и изменения состояния системы. Вы можете создавать модели на основании текстовых требований, чтобы отобра зить их с различных точек зрения, или вывести детализированные функциональные требования из моделей высокого уровня, созданных на основе предоставленной пользователями информации. В процессе разработки модели демонстрируют, как вы намерены реализовать систему: ту базу данных, которую вы планируете создать, классы объ ектов, которые вы будете иллюстрировать примерами, и модули кода, которые вы собираетесь разрабатывать.

Ловушка Не следует полагать, что разработчики смогут просто преобразовать модели анализа в код, не разобрав подробно процесс. Поскольку в обоих ти пах диаграмм используются одни и те же системы обозначений, ясно назовите каж дый из них моделью анализа (концепция) или моделью дизайна (то, что плани руете создать).

208 Часть II. Разработка требований к ПО Приемы моделирования анализа, описанные в этой главе, под держиваются различными коммерческими инструментами автомати зированного проектирования ПО (computer-aided software engineering, CASE). Использование этих инструментов обеспечивает некоторое преимущество перед обычными средствами рисования.

они легко позволяют улучшить качество диаграмм при повторных прс смотрах требований. Вам не удастся создать отличную модель с пер вого раза, поэтому итерацию можно назвать ключом к успеху при мо делировании систем (Wiegers, 1996a). Кроме того, инструменты матизированного проектирования ПО «знают» правила для метода моделирования, который они поддерживают. Они способны определить синтаксические ошибки и несоответствия, которые спе циалистам, проверяющим не всегда удается Эти инструменты связывают различные диаграммы друг с другом и с их общими определениями данных в словаре данных, а также позволя ют поддерживать модели в согласованном состоянии и в соответствии с функциональным требованиям в спецификации требований к ПО.

Редкий случай, когда команде необходимо создать полный набор моделей для всей системы. При моделировании сосредоточь тесь на наиболее сложных и опасных участках а также на где наиболее вероятны неясности и неопределенности. Элементы системы, от которых зависит ее безопасность и защита, а также менты, влияющие на выполнение критически важных задач, можно смело назвать кандидатами на моделирование, так как последствие дефектов в них окажутся особенно тяжелыми.

От желания клиента к модели анализа Тщательно слушая, как клиенты представляют свои требования, ана литик может выделить ключевые слова, которые преобразуются в оп ределенные элементы модели. В табл. перечислены возможное отображение значимых существительных и глаголов, употребляемых пользователями, в компонентах модели, о которых рассказано далее в этой главе. По мере того как вы будете записывать пожелания вателей в виде требований и моделей, вам придется связать каждый компонент модели с определенным пользовательским требованием Глава Любое изображение стоит 1024 слов Таблица Привязка пожеланий клиента к анализа Тип слова Примеры Компоненты модели анализа Оконечные объекты или хранили Существительные Люди, организации, системы ща данных (диаграммы потоков ПО, элементы данных данных) или существующие Действующие лица (диаграммы вариантов Объекты или их атрибуты (диаграммы «сущность Классы или их атрибуты [диаграммы классов) Глаголы задачи, которые Процессы (диаграммы потоков данных) пользователь может выпол или события, которые использования (диаграм мы вариантов использования) могут Взаимосвязи (диаграммы «сущность - связь») Преобразования (диаграммы перехода состояний) Процессы (диаграммы процессов) В этой книге я использовал в качестве учебного примера Chemical Tracking System. В следующем абзаце для этой системы описаны по требности который представил сторонник продукта от класса Химики. Значимые существительные выделены полужирным начертанием, а глаголы или отглагольные существительные — курси отыщите эти ключевые слова в моделях анализа, показанных да лее в этой главе. На схемах некоторых моделей с целью иллюстрации показана информация, выходящая за рамки содержания следующего абзаца, тогда как на других моделях отображена только часть инфор мации, представленной здесь:

или из работающих на складе химикатов может разместить запрос на один или несколько химикатов. Запрос может быть выполнен или доставки контейнера с который числится инвентарной описи товаров на складе химика тов, или посредством заказа на химикат у постороннего поставщика. Сотрудник, размещающий запрос, при подготовке за проса должен иметь возможность искать в режиме реального времени нужный химикат в каталогах поставщиков. Системе необходимо состояние каждого запроса с момента его подготовки и до момента его выполнения или отмены. Ей также необходимо отслежи 210 Часть II. Разработка требований к ПО вать историю каждого контейнера с химикатом с момента его получе ния компанией до его полного расходования или Диаграмма потока данных Диаграмма потока данных (data flow diagram, DFD) — основной румент структурного анализа 1979;

Robertson и Robertson, Она позволяет трансформационные процессы сис (хранение) данных или материалов, которыми система управляет, и потоки данных или материалов между процесса ми, хранилищами и внешним миром. При моделировании данных для системного анализа используется прием при котором сложные проблемы раскладываются на состав ляющие, размещаемые по нарастающей по уровням Этот метод отлично подходит для систем обработки транзакций и дру гих приложений с большим набором функций. Посредством добавле ния элементов управления потоком диаграмму потока данных удалось применить для моделирования работающих в режиме реаль ного времени (Hatley, Hruschka и Pirbhai, 2000).

Диаграмма потока данных позволяет представить этапы бизнес процесса или операции предложенной системы ПО. Я часто пользо вался этим средством, опрашивая клиентов — я набрасывал на доске диаграмму, пока длилось обсуждение бизнес-операций. Диаграммы потока данных могут представлять системы на самых разных уровнях абстракции: диаграммы высокого уровня предоставляют целостный, панорамный вид данных и выполняемых компонентов в многоэтапном процессе, дополняющем точное, детальное представление, мое в спецификации требований. Диаграмма потока данных рирует то, как совмещаются функциональные требования в специфи кации, чтобы пользователь смог выполнять определенные задачи, на пример запрос химиката.

Ловушка Не обольщайтесь, что клиентам заранее известно, как читать модели анализа, однако не думайте, что они не смогут разобраться в них. Объясните цели и условные обозначения для каждой модели сторонникам продукта и попросите и> просмотреть диаграммы.

Контекстная диаграмма на рис. 5-3 — это наивысший уровень абст ракции диаграммы потока данных. Контекстная диаграмма пред ставляет всю систему как единый процесс, изображенный в виде Глава Любое изображение стоит слов (пузырька). На ней также показаны оконечные объекты (terminators), или внешние объекты, подсоединенные к системе и данным или мате риальным потокам системами и оконечными объектами. Потоки на контекстной диаграмме часто представляют сложные структуры данных, определенные в словаре данных.

Вы можете конкретизировать контекстную диаграмму до уровня О, выделив важнейшие процессы системы. На рис. показан уровень О диаграммы потока данных для Chemical Tracking System (несколько упрощенный). процесс Chemical Tracking System, обозначае мый на контекстной диаграмме одним кружком, был разделен на семь основных процессов Как и на контекстной диаграмме, око нечные объекты показаны прямоугольниками. Все потоки данных присутствовавшие на контекстной диаграмме, отражены на уровне 0 диаграммы потока данных. Кроме того, парами параллельных линий здесь обозначены хранилища данных, которые относятся ко внутренней части системы и, следовательно, не показаны на контекст ной диаграмме. Стрелка от кружка к хранилищу, указывает, что данные были помещены в хранилище, стрелка, выходящий из хранилища, обо значает операцию считывания, а двунаправленная стрелка между хра нилищем и кружком — операцию обновления.

Каждый процесс, изображенный в виде отдельного кружка на уровне О диаграммы, можно расписать более подробно с помощью отдельной диаграммы, изобразив на ней всю функциональность этого процесса.

Аналитик продолжает последовательные уточнения до тех пор, пока диаграммы нижних уровней не будут содержать только простейшие операции, которые можно ясно представить в виде комментариев, псевдокода, графика или диаграммы процесса. Функциональные тре бования в спецификации требований к ПО точно определят, что проис ходит в ходе каждого простейшего процесса. Диаграммы потока дан ных каждого уровня должны быть сбалансированы и согласованы с рас положенным выше уровнем так, чтобы вся входящие и исходящие потоки на дочерней диаграмме соответствовали аналогичным на роди тельской диаграмме. Сложные потоки данных в диаграммах высоких уровней могут быть разделены на составные элементы, как определе но в словаре данных, на диаграммах потока данных нижних уровней, На первый взгляд схема на рис, выглядит сложной. Однако ес ли вы изучите ближайшее окружение любого процесса, то увидите элементы данных, которые он принимает и отдает, а также их исходные точки и точки назначения. Чтобы увидеть, как именно в процессе ис пользуются элементы данных, вам понадобится либо нарисовать бо 212 Часть II. Разработка требований к ПО лее подробную дочернюю диаграмму потока данных или сослаться на функциональные требования для этой части системы.

а по нерсхи на складе из Катало запрос персонала данные Рб обучении персо работе с на ными запрос о на склад с а складе по отслеживанию на складе на складе по со стоянию сов на на состояние запрос отчет заказа химиката об у поставщика у химиката Рис. Уровень 0 диаграммы потока данных для Chemical Tracking System Ниже приведены некоторые правила для рисования диаграмм пото ка данных. Не все придерживаются одних и тех же правил (например, некоторые аналитики показывают оконечные объекты только на текстных однако я считаю их полезными. Использование Глава Любое изображение стоит 1024 слов моделей для улучшения взаимодействия участников проекта важнее догматического соблюдения этих правил.

I размещайте хранилища данных только на уровне 0 и более низких уровнях диаграммы потока данных, а не на контекстной диаграмме;

1 процессы взаимодействуют через хранилища данных, а не посред ством прямых потоков от одного процесса к другому. Точно так же данные не могут передаваться напрямую из одного хранилища в другое, они должны пройти через процесс (кружок);

S не пытайтесь вообразить последовательность этапов процесса с помощью диаграммы потока данных;

называйте каждый процесс как короткое действие: глагол + объект (например, создать инвентарный отчет). Используйте названия, по нятные клиентам и употребляемые в деловой или предметной об ласти;

i присваивайте процессам уникальные номера согласно иерархии. На уровне 0 диаграммы, пронумеруйте каждый используя це лые числа. Если вы создадите дочернюю диаграмму потока данных для процесса пронумеруйте процессы на ней и 1 не показывайте на одной диаграмме более 8-10 в про тивном случае ее будет трудно изменять и понимать. Если у вас больше десяти процессов, создайте еще один уровень абст ракции, сгруппировав связанные процессы в процесс более высоко го уровня;

I кружки с только входящими или только исходящими потоками вы зывают подозрение. Корректный процесс, изображаемый кружком на диаграмме потока данных, как правило, отличает наличие и вхо дящих, и исходящих потоков.

Когда представители клиентов просматривают диаграмму потока данных, они должны убедиться, что на ней отображены все известные процессы и что у них нет отсутствующих или ненужных входящих или исходящих потоков. При изучении диаграммы потока данных часто вы являются не распознанные ранее классы пользователей, бизнес-про цессы и соединения с другими системами.

Диаграмма «сущность - связь» Точно так же, как диаграмма потока данных иллюстрирует процессы, происходящие в системе, модель данных отображает взаимоотноше ния данных. Широко такая модель данных, диаграм ма — связь» (entity-relationship ERD) 214 Часть II, Разработка требований к ПО 1996). Если диаграмма «сущность — представляет логические группы информации предметной и их взаимосвязи, вы ис пользуете диаграмму — в качестве инструмента лиза Анализ диаграммы "сущность — связь» понять и связать компоненты данных компании или системы, не под разумевая, что в продукт будет обязательно включена база данных. И наоборот, когда вы создаете эту диаграмму в ходе разработки мы, вы определяете логическую или физическую структуру базы дан ных системы.

Объектами называются физические элементы (включая людей) или агрегация элементов данных, важных для бизнеса, которого выполняете, или для системы, которую вы создать и Robertson, 1994). Объекты называются посредст вом существительных в единственном числе, они показаны в угольниках на диаграмме «сущность — связь». На Рис. показана часть диаграммы — связь» для Chemical Tracking System с использованием одной из нескольких применяемых для диаграмм кого типа систем обозначений. Обратите что объекты За прос химиката, Каталог поставщика и Товары на складе химикатов на диаграмме потока данных на рис. 11- ных. Другие объекты представляют действующие лица, взаимодейст вующие с системой (Сотрудник, разместивший заказ на химикат), фи зические элементы, частью деловых операций (Контей нер с химикатом), и блоки данных, которые не показаны на О диаграммы потока но показаны на ее более низком (История контейнера, Химикат), Каждый объект несколькими атрибутами;

у отдельных экземпляров объекта будут различные значения атрибутов. Например, в атрибуты каждого химиката включены уникальный химический тификатор, строгое название химиката и графическое его химической структуры. В словаре данных приводятся детальные определения этих атрибутов — это гарантирует, что объекты на грамме "Сущность — связь» и соответствующие им хранилища данных на диаграмме потока данных определены идентично.

Ромбы на диаграмме «сущность — обозначают шения (relationships), показывающие логические и числовую связь пар объектов. Названия взаимоотношениям даются в соответствии с при родой соединений. Например, взаимоотношения между элементами «Сотрудник, разместивший заказ на химикат», и «Запросом определяются как размещение. Вы можете прочитать это взаимоотно шения как «Сотрудник размещает Запрос на химикат» или как Глава 11. Любое изображение стоит 1024 слов на химикат размещен Сотрудником». Согласно некоторым правилам, фигуру в форме ромба следует назвать «размещен что имеет смысл, только если читать диаграмму слева направо. Когда вы покаже те клиентам диаграмму «сущность — связь», попросите их проверить, все ли взаимоотношения показаны корректно и соответствующим об разом. Также попросите их определите все возможные взаимоотно шения с объектами, которые не показаны на модели.

ший на Рис. -2. Часть диаграммы «сущность - связь» для Chemical Tracking System элементов (cardinality) каждого взаимоотношения, или его множественность, показаны цифрой или буквой на прямых, соеди няющих объекты и взаимоотношения. Для диаграмм «сущность связь" используются различные правила для обозначения количества элементов;

условные обозначения на рис. используются наиболее часто. Поскольку каждый Сотрудник, заказ на химикат, может разместить несколько запросов, то между элементами «Сотруд ник, разместивший заказ на химикат», и «Запрос химиката» существует связь «один ко многим». Количество элементов показано цифрой 1 на линии, соединяющей элемент «Сотрудник, разместивший заказ на хи микат», и взаимоотношение «размещение», и буквой (много) на ли Часть II. Разработка требований к ПО нии, соединяющей элемент «Запрос химиката» и взаимоотношение Ниже перечислены другие возможные I один к одному контейнер с химикатом отслеживается в од ной Истории контейнера);

I многие ко многим (в каждом каталоге поставщика содержится мно жество Химикатов, а некоторые Химикаты встречаются в несколь ких Каталогах Если вам известно более точное количество элементов, чем просто много, вы можете указать вместо общего конкретное число или диа пазон.

проблем, а не ПО Как-то я в качестве представителя специалистов по ИТ работал в команде, которая занималась модернизацией бизнес-процессов. Наша задача заключалась в снижении в 10 раз времени, необходимого для того, чтобы новый химикат оказывался доступ ным для использования в продукте. В команду были включены представители сле дующих подразделений задействованных в коммерциализации химиката:

химиков-синтетиков, которые создали новое вещество;

химиков-технологов, разрабатывающих процесс промышленного производства вещества;

I химиков-аналитиков, разрабатывающих методы проверки чистоты вещества;

I патентных поверенных, которые занимаются патентной защитой изобретения;

1 специалистов отдела охраны труда и здоровья, получающих разрешение прави тельства на использование химиката в потребительских товарах.

После того как мы новый который по нашему мнению должен был необыкновенно ускорить коммерческое применение химиката, я опросил чле нов команды, ответственных за каждый этап процесса. Я задал каждому два вопро са: информация вам нужна для выполнения этого этапа?» и «Какую информа цию, которая появится в результате выполнения этого этапа, следует Собрав и сравнив ответы, я выявил те этапы, информацию для которых не постав лял никто, а также этапы, выходная информация не была нужна никому. Мы разрешили эти проблемы, Затем я диаграмму потока данных, чтобы проиллюстрировать новый цесс коммерциализации химиката и диаграмму «сущность - связь» для вания взаимоотношений данных. Все наши элементы данных были определены словаре. Такие модели анализа будут полезны в качестве инструментов ствия, которые помогут членам команды выработать общее понимание нового Кроме модели собой прекрасную точку отсчета для раз работки требований для приложений и определения их границ.

Глава Любое изображение стоит слов Диаграмма перехода состояний Для любых систем ПО необходимо учитывать комбинацию функцио нального поведения, особенности управления данными и изменения состояния. Состояний, в которых в каждый момент времени могут на ходиться системы реального времени и приложения, управляющие немного. Изменение состояния происходит, только когда удовлетворяются четко определенные критерии, такие, как получение определенного сигнала на входе при определенных условиях. Приме ром может служить перекресток магистрали с установленными датчи ками движения, защищенной полосой поворота, а также разметкой и сигналами для пешеходного перехода. Многие информационные сис темы имеют бизнес-обьектами на покупку, счета-фак туры, товарно-материальные ценности и т.п., для жизненных циклов которых возможно несколько различных состояний. Элементы систе мы, для которых возможен набор состояний и их изменение, называ ются механизмами с конечным числом состояний (finite-state machi nes) (Booch, Jacobson, 1999).

При описании сложного механизма с конечным числом состояний на естественном языке высока вероятность упустить из внимания раз решенное изменение состояния или появления запрещенного изме нения. В зависимости от структуры спецификации требований к ПО, требования, относящиеся к поведению состояния механизма, могут быть в ней разобщены. В этом случае весьма трудно понять поведение системы.

Диаграмма перехода состояний diagram) позволяет получить точное, полное и ясное представление о механизме с конеч ным числом состояний. Связанный с этой моделью прием ма состояния — включен в обладающий в некотором смысле более бо гатым набором условных обозначений унифицированный язык моде лирования (Unified Modeling Language, который моделирует состояния объекта в течение его жизненного цикла (Booch, Jacobson, 1999). Диаграмма перехода состояний содержит три типа элементов:

1 возможные состояния системы — показаны в виде прямоугольников;

разрешенные состояния, или транзакции (transitions), — показаны в виде стрелок, соединяющих пары прямоугольников;

1 события или условия, вызывающие каждую транзакцию, — показа ны в виде текстовых пояснений для каждой стрелки перехода. Текст может пояснять и событие, и соответствующую реакцию системы, 218 Часть II. Разработка требований к ПО На рис. показана часть диаграммы перехода состояний для до машней системы безопасности. В диаграмме перехода состояний для системы реального времени предусмотрено особое состояние, но называемое Ожидание (эквивалентно состоянию Отключено на сунке), в которое система возвращается, когда она не процессами. В отличие от этого, диаграмма перехода состояний для объекта, имеющего определенный жизненный цикл, например Запрос химиката, имеет одно или более конечных состояний, которые ют финальные значения состояния объекта.

изменение параметров войти в автомати- выйти ческий датчики отключены, установить режим отсутствия хозяев в доме хозяев в течение 30 секунд ввести правильный код обнаружено введен неправильный код правильный код не введен в течение 30 секунд в полицию дым, Обнаружен дым, звонок в службу в противопожарную Рис. -3. Часть диаграммы перехода состояний для домашней системы безопасности На диаграмме перехода состояний не показаны детали выполняемых системой, а только возможные изменения состояний, возникающие в результате этих процессов. Диаграмма перехода со стояний помогает разработчику понять предполагаемое поведение системы. Это хороший метод проверки того, все ли необходимые состояния и переходы состояний корректно и полно описаны в функ циональных требованиях. могут вывести варианты тес тирования на основании диаграммы перехода состояний, в которую Глава Любое изображение стоит слов включены все допустимые пути переходов. Клиентам, как правило, хватает незначительных пояснений, касающихся принятой системы обозначений, — что означают прямоугольники и стрелки, — чтобы прочитать диаграмму перехода состояний.

Вспомните из главы 8, что основная функция Chemical Tracking System — позволить действующим лицам, которые названы «Сотруд ники, разместившие заказ на химикат», разместить запрос химиката, который может быть выполнен либо складскими работниками (если химикат есть на либо сторонним поставщиком (для этого ему надо отправить запрос). Каждый запрос проходит через несколько со стояний с момента его создания до момента либо его выполнения, ли бо отмены (два конечных состояния). Таким образом, мы можем батывать жизненный цикл запроса химиката как механизм с конечным числом состояний и моделировать его так, как показано на рис. -4.

Эта диаграмма перехода состояний показывает, что отдельный за прос может находиться в одном из следующих семи состояний:

I В подготовке. Сотрудник создает новый запрос, инициировав эту функцию из другой части системы;

1 Отложен. Сотрудник сохраняет часть запроса для выполнения в будущем, не передавая его в систему и не отменяя операцию за проса;

1 Принят. Пользователь отправляет законченный запрос и система принимает его к исполнению;

Размещен. Запрос должен быть удовлетворен сторонним постав щиком, покупатель размещает заказ у продавца;

1 Выполнен. Запрос удовлетворен: контейнер с химикатом постав лен либо со склада химикатов, либо от поставщика;

1 Заказ ожидает У продавца не оказалось химиката в наличии, и он уведомил покупателя, что заказ отложен для будущей поставки;

Отменен. Сотрудник отменил принятый системой заказ до того, как тот был выполнен, или покупатель отменил заказ у продавца, до того как тот был выполнен или пока он был отложен.

Когда представители пользователей Chemical Tracking System про смотрели диаграмму перехода состояний для запроса химиката, они определили, что одно состояние не нужно, другое важное состояние отсутствует, и указали два неправильных перехода. При изучении со ответствующих функциональных требований эти ошибки никто из них не заметил. В этом и заключается важность представления информа ции о требованиях на нескольких уровнях абстракции. Зачастую про 220 Часть II. Разработка требований к ПО легче обнаружить, если идти назад от наиболее детализирован ного уровня и рассматривать большую картину, которую обеспечивают модели анализа. Однако диаграмма перехода состояний не дает уро вень деталей, достаточный разработчику для создания ПО.

тельно, в спецификацию требований к ПО для Tracking Sys tem были включены функциональные требования, связанные с боткой запроса химиката и возможными изменениями его состояния, I t пользователь создает новый новый сохраняет незаконченный запрос пользователь вызывает незаконченный запрос система принимает запрос сотрудник, заказ запрос на складе на химикат, отменяет запрос покупатель размещает у химикат покупатель отменяет от поставщика заказ у поставщик помешает заказ на в невыполненные Рис. -4. Диаграмма перехода состояний для запроса химиката a Chemical Tracking System Глава Любое изображение стоит слов Карта диалогов Пользовательский интерфейс также можно рассматривать как меха низм с конечным числом состояний. Только один элемент диалога (та кой, как меню, рабочая область, диалоговое окно, командная строка или дисплей сенсорного доступен в определенный момент времени для ввода информации пользователем. Пользователь может перейти к другим определенным элементам диалога, с действием, которые он в активной области ввода. Количе ство возможных путей навигации в сложном графическом интерфейсе велико, однако оно конечно и, как правило, все возможности извест ны. Следовательно, множество пользовательских интерфейсов можно моделировать, применяя одну из форм диаграммы перехода состоя ния, которая называется карта диалогов (dialog (Wasserman, Wiegers, 1996a). и описывают похо жий прием — карту перемещений (navigation map), которую отличает более богатый набор условных обозначений для представления раз личных типов элементов взаимодействия и контекстных переходов.

Карта диалогов представляет дизайн пользовательского интерфей са на высоком уровне абстракции. На ней показаны элементы диалога в системе и навигация между ними, но не показан подробный вид эк рана. Карта диалогов позволяет рассмотреть возможные пользовательского интерфейса с учетом вашего понимания требова ний. Пользователям и разработчикам стоит изучить карту диалогов, чтобы выработать общее представление того, как пользователь может взаимодействовать с системой для выполнения задачи. Карты диало гов также полезны при моделировании визуальной архитектуры Web сайта. Ссылки для перемещений, которые вы включаете Web-сайт, на картах диалогов изображаются в виде переходов. Карты диалогов свя заны с архивными системными документами, в которые также включе но краткое описание назначения каждого экрана и Widrig, 2000).

Карты диалогов отражают сущность взаимодействий системы пользователя и основные моменты решения задачи, без тормозящих работу команды деталей макета экрана. С помощью такой карты поль зователи могут отследить отсутствующие, неправильные или ненуж ные переходы и, следовательно, отсутствующие, неправильные или ненужные требования. Абстрактная концептуальная карта диалогов, разработанная в ходе анализа требований, становится руководством для подробной разработки пользовательского интерфейса.

222 Часть II. Разработка требований к ПО как и обычные диаграммы перехода состояния, карта диало гов показывает каждый элемент диалога как состояние ник) и каждую допустимую возможность перемещения как переход (стрелка). Условие, инициирующее перемещение по пользовательско му интерфейсу, показано в виде текстового ярлыка на стрелке перехо да. Существует несколько типов инициализирующих условий:

действие пользователя, например нажатие функциональной ши или щелчок гиперссылки или кнопки диалогового окна;

1 значение данных, такое, как недостоверная информация, в резуль тате чего появляется сообщение об ошибке;

I системное условие, например отсутствие бумаги в принтере;

некоторые комбинации вышеперечисленных, например ввод ра элемента меню и нажатие клавиши Enter, Карты диалогов слегка напоминают диаграммы потоков, но у них другое назначение. Диаграммы потока ясно показывают этапы цесса и точки принятия решений, но не пользовательский В отличие от них, на карте диалогов не отображается процесс, выпол няющийся по линиям перехода, которые соединяют один элемент лога с другим. Выполнение решения (обычно это выбор скрыто за экранами, которые показаны на карте диалогов в виде пря моугольников, а условия, в результате которых отображается тот или другой экран, описаны над стрелками переходов. Вы можете карту диалогов как противоположность — или дополнение — диаграм мы потока.

Чтобы упростить карту диалогов, пропустите глобальные функции, такие, как нажатие клавиши F1 для вызова справки для каждого диало гового элемента. В разделе спецификации требований к ПО, посвя щенному пользовательскому интерфейсу, должно быть указано, что эта функциональность будет доступна, но демонстрация множества экранов справки на карте диалогов вносит в модель беспорядок при незначительных преимуществах. Точно так же при моделировании Web-сайта не нужно включать стандартные для каждой страницы ки перемещения. Вы также можете опустить транзакции, реализую щие последовательность перемещений по Web-странице которые запускаются кнопкой Back Web-браузера.

Карта диалогов — это прекрасный способ представить взаимодей ствия действующего лица и системы, описываемые вариантом ис пользования. Карта диалогов позволяет отобразить направления в виде ответвлений от нормального Я обна ружил, что наброски фрагментов карты диалогов на доске оказались особенно полезны на семинарах по сбору информации, Глава Любое изображение стоит 1024 слов вариантов когда участники изучали последователь ность действий пользователя и реакций системы при выполнении за дачи.

В главе 8 описан вариант использования Chemical Tracking System под названием «Запрос химиката». Нормальное направление развития этого использования подразумевает запрос контейнера с хи микатом со склада. Альтернативное направление — запрос химиката у поставщика. Пользователь, размещающий запрос, хотел бы иметь воз можность просматривать историю доступных контейнеров с этим хи микатом, прежде чем выбрать один из них. На рис. -5 показана карта диалогов для этого несколько сложного варианта использования, На первый взгляд эта диаграмма может показаться довольно запу танной, но в ней довольно легко разобраться, если попробовать за один раз отследить один прямоугольник и одну линию. Пользователь инициирует этот вариант использования, размещая заказ химиката из меню Tracking System. В карте это действие пользо вателя, обозначенное стрелкой в верхней левой части карты, направ ленной к прямоугольнику с названием «Список текущих запросов».

Этот прямоугольник представляет основное рабочее пространство для такого варианта использования, те, список химикатов в текущем за просе пользователя. Стрелки, исходящие из этого прямоугольника на карте диалогов показывают все возможные перемещения — следо вательно, функциональность — доступные пользователю:

1 отменить весь запрос;

I передать к исполнению запрос, если в нем содержится хотя бы один химикат;

I добавить новый химикат к запросу;

I удалить химикат из списка.

В последней операции, удалении химиката, не участвует какой-либо еще элемент диалога, при этом просто обновляется список текущих запросов после как пользователь вносит По мере перемещения по этой карте диалогов вы увидите элемен ты, отражающие остальные элементы варианта использования «За прос химиката»:

I один для химиката у поставщика;

другой путь для выполнения запроса через склад химикатов;

еще один возможный путь — просмотр истории контейнера, храня щегося на складе химикатов;

I отображение сообщения об ошибке для обработки ввода непра вильного ID химиката или других возможных ошибочных условий.

224 Часть II. Разработка требований к ПО т OK;

выход из функции запрос Т запросить отменить весь запрос отправить запрос для больше у удалить химикат отменить брать поставщика из списка нового химиката и к списку запросить добавление другой химикат нового химиката запросить неправильное у поставщика Отобразить химиката j Cm сообщение i ко можно j У [ 1 у химикат.

запросить другой химикат запросить химикат запросить на е д химикат у поставщика выбрать контейнер • добавить к списку Список историю возврат контейнера Рис. -5. Карта диалогов для варианта использования «Запрос химиката» в системе Chemical Tracking System Глава Любое изображение стоит слов Некоторые переходы на карте диалогов позволяют пользователю откатить операцию. Пользователей раздражает, если они уже переду мали, а им все-таки приходится завершать задачу. Карты диалогов по зволяют облегчить и упростить работу, предлагая функции отката и от мены в стратегических точках.

Пользователь, изучающий карту диалогов, может обнаружить не достающее требование. Например, осторожный пользователь может захотеть подтвердить операцию, которая отменяет весь запрос, чтобы избежать непроизвольной потери данных. Дешевле добавить такую функцию на этапе анализа, чем встраивать ее в уже законченный про дукт, Поскольку карта диалогов представляет концептуальные элемен ты, участвующие во взаимодействии пользователя и системы, не пы тайтесь зафиксировать все детали пользовательского интерфейса на этапе работы над требованиями. Лучшее применение этих моделей — помочь всем, кто заинтересован в проекте, выработать общее понима ние предполагаемой функциональности системы.

Диаграмма классов Объектно-ориентированная разработка ПО вытеснила структурный анализ и разработку, породив анализ и разработку. Как правило, в предметной или рабочей области объекты (objects) соотносятся с объектами реального мира. Они представляют отдельные экземпляры, выведенные из родового шаблона, который называется класс (class). В описания классов входят атрибуты (дан и которые можно выполнять с этими атрибутами.

грамма классов (class diagram) — это графический способ отобразить классы, идентифицированные в ходе объектно-ориентированного анализа, и взаимоотношений между ними.

Для продуктов, разработанных с помощью объектно-ориентирован ных методов, не требуются уникальные приемы разработки требова ний. Дело том, что требования отражают то, что пользователям необ ходимо сделать с помощью системы, и особенности предполагаемой функциональности, а не то, как она будет создана. Пользователям не придется вникать в объекты и классы. Однако если вы собираетесь разрабатывать систему с помощью объектно-ориентированных прие мов, то анализ требований стоит начать с определения классов доме нов, их атрибутов и поведения. Это упростит переход от анализа к ди зайну, так как дизайнер сопоставляет объекты предметной области с 226 Часть II. Разработка к ПО системными объектами и детализирует атрибуты и операции класса.

Стандартным языком объектно-ориентированного моделирования является унифицированный язык моделирования (Unified Language, Rumbaugh и Jacobson, 1999). На уровне ракции, который годится для анализа требований, вы можете зовать систему обозначений в диаграмме классов, как показано на рис. для вы правильно Chemical System. Дизайнер переработает эти концептуальные диаграммы сов, не зависящие от особенностей реализации, в более диаграммы классов для объектно-ориентированного дизайна и зации. Взаимодействия классов и сообщения, которыми они демонстрируют диаграммы последовательностей и диаграм мы сотрудничества, подробно о которых рассказано в Booch, Rum baugh;

Jacobson и Lauesen (2002).

На рис. 4 класса — каждый в большом прямоугольни ке: Сотрудник, разместивший заказ на химикат, Каталог Запрос химиката и Элемент строки запроса. Вы видите, что информа ция на этой диаграмме классов и данные на другой анализа, из тех, что показаны в этой главе, похожи — везде дается одна и та же проблема). Сотрудник, разместивший заказ на хи микат, показан на диаграмме «сущность — связь» на рис. где он представляет действующее лицо — член класса пользователей Хими ки или Сотрудники склада химикатов. На диаграмме а рис. также что оба эти класса могут размещать запросы химикатов. Кстати, не путайте класс пользователей и класс невзирая на схожесть названий, они не связаны собой.

Атрибуты (attributes), связанные с классом Сотрудник, разместив ший заказ на химикат, показаны в средней части прямоугольника, кото рый обозначает их класс: имя, Номер_отдела и Но мер_офиса (правило применения заглавных букв довольно странено в диаграммах). Это свойства или элементы связанные с каждым — членом класса Сотрудник, разместив ший заказ на химикат. Похожие атрибуты могут содержаться в опреде лении хранилищ на диаграмме потоков данных или в данных.

Операции (operations) — это службы, которые объект каждого клас са может выполнять. Операции показаны в нижней части поля класс как правило, за ними стоят пустые скобки. На диаграмме представляющей дизайн, эти операции соответствуют функциям методам а аргумент функции часто заключен в скобки. В дели анализа класса просто должно быть показано, что Сотрудник, Глава Любое изображение стоит 1024 слов разместивший заказ на химикат, может запрашивать химикаты, выпол нять поиск по каталогам продавцов и получать контейнеры с ми. Операции на диаграмме классов весьма приблизительно ствуют процессам, показанным в кружках на диаграммах потоков дан нижних уровней.

umber iner() химиката chemicalld vendqrName I quantity add() Рис. -6. Диаграмма классов для части Chemical System соединяющие прямоугольники классов на рис. -6, симво лизируют связи между классами. Цифры на них указывают на множе ственность связи, точно так же, как линии на диаграммах «сущность — — на множественность взаимоотношений между объектами. На рис. знак звездочки обозначает связь «один ко многим» между классами Сотрудник, разместивший заказ на химикат, и Запрос хими ката: один сотрудник может разместить множество запросов, но каж дый принадлежит только одному сотруднику.

228 Часть II. Разработка требований к ПО Таблицы решений и деревья решений Часто система ПО управляется сложной логикой, учитывающей раз личные комбинации условий, результатом которых является ное поведение системы. Например, если водитель нажимает ускорения на системе круиз-контроля и автомобиль в ный момент то система увеличит скорость автомобиля, противном случае команда игнорируется. Для спецификации ний к ПО необходимы функциональные требования, в которых будет описано, что должна делать система при всех комбинациях условий Однако условие легко пропустить, в результате чего пропускается и требование. Эти пробелы трудно заметить, просматривая текстовые спецификации вручную.

Таблицы решений и деревья это два альтернативных приема для представления того, что система должна делать, когда в игру вступают сложные логика и решения (Davis, В таблице шений (decision table) перечислены различные значения для всех фак торов, влияющих на поведение и приведены ожидаемые действия системы в ответ на каждую комбинацию факторов. Факторы могут быть показаны либо как утверждения с различными условиями true и false, либо как вопросы с возможными ответами «да» или «нет» Естественно, вы также можете использовать таблицы решений с торами, которые имеют более двух возможных значений.

Ловушка Не нужно создавать и таблицу решений, и дерево решений, чтобы по казать один и тот же фрагмент информации;

вполне достаточно одного из них.

В табл. показана таблица решений с управляющей принятием или отклонением запроса нового химиката Chemical ing System. На решение влияет четыре фактора:

авторизирован ли пользователь, создающий запрос;

1 имеется ли химикат в наличии на складе или у поставщика;

I включен ли химикат в список опасных химикатов, для работы с необходима специальная подготовка;

1 есть ли у создающего запрос, соответствующая готовка для работы с этим типом опасного вещества.

Каждый из этих четырех факторов имеет два возможных условия, true или false. В принципе это увеличивает на или 16 различные ком бинации true/false для вероятных отдельных функциональных ваний. Однако на практике результатом многих комбинаций является Глаеа Любое изображение стоит 1024 слов одна и та же реакция системы. Если пользователь не авторизован для запроса химикатов, то система не примет запрос, и таким образом ос тальные условия несущественны прочерками в таблице ре шений). Таблица показывает, что результат различных логических комбинаций — лишь пять отдельных функциональных требований.

Таблица -2. Пример таблицы решений Chemical Tracking System Номер Условие 1 2 3 4 Пользователь авторизован true true I Химикат есть в наличии Химикат считается опасным true true Сотрудник, разместивший заказ на хими кат, прошел соответствующую подготовку false true Действие Принять x x Отклонить запрос x x Рис. Пример дерева решений для Chemical Tracking System На рис. показано дерево решений, представляющее ту же ло гику. Пять прямоугольников обозначают пять возможных результатов принятия или отклонения запроса на химикат. Таблицы решений и ревья это хорошие способы документации требований Часть II. Разработка требований к ПО (или бизнес-правил), позволяющие не пропустить ни одну комбина цию условий. Даже сложная таблица или дерево решений более про сты для чтения, чем повторяющиеся требования в текстовом виде.

Последнее напоминание У каждого приема моделирования, описанного в этой книге, есть и свои и свои ограничения. Эти приемы позволяют представить одни и те же области, поэтому вам не надо создавать для своего проекта все типы диаграмм. Например, если вы создаете диа грамму «сущность — связь» и словарь данных, не стоит рисовать диа грамму классов (или наоборот). Помните, что вы создаете модели ана лиза для того, чтобы обеспечить более высокий уровень понимания взаимодействия, чем тот, что дает текстовая спецификация ний к ПО или любое другое представление требований. Старайтесь не стать догматиком и не участвовать в религиозных войнах, которые иногда случаются в мире методов и моделей разработки ПО. Вместе этого, используйте все доступные средства для того, чтобы как лучше объяснить требования к вашей системе, Что теперь?

I Опробуйте на практике приемы описанные в этой главе, задоку ментировав разработку существующей системы. нарисуйте карту ди алогов для банковского автомата или Web-сайта, которые вы используете.

1 Определите часть спецификации требований к ПО, трудную для восприятия, или ту, где обнаружены дефекты. Выберите модель анализа, описанную в этой главе, которая подходит для представления этой части требований. Нарисуйте модель и оцените, помогла бы она решить проблему, создай вы ее раньше, 1 В следующий раз, когда вам понадобится задокументировать определенные тре бования, выберите прием моделирования, который дополняет текстовое описа ние. Сделайте набросок модели на бумаге или доске один или два раза, чтобы убедиться, что вы на верном пути, затем воспользуйтесь коммерческими инстру ментами автоматизированного проектирования ПО, которые поддерживают ус ловные обозначения модели, которую вы используете.

Глава 11. Любое изображение стоит слов Обратная сторона функциональности:

качества ПО «Привет, Фил, это снова Мария. У меня вопрос о новой слу жебной которой вы сейчас занимаетесь. Как вы знаете, эта система работает на нашем мэйнфрейме и каж дый отдел должен ежемесячно оплачивать используемое дис ковое пространство и загрузку процессора. Похоже, что в но вой системе файлы занимают в два раза больше места на диске, чем в старой. Что еще хуже, загрузка процессора за сессию в три раза выше, чем обычно. Вы можете мне, что происходит?" «Конечно, Мария. Вспомните, вы хотели, чтобы в этой системе хранилось больше данных о каждом сотруднике, чем в преды дущей, поэтому, естественно, база данных стала значительно больше. Следовательно, ваша ежемесячная плата за зование дискового пространства выросла. Кроме того, вы и остальные сторонники продукта просили, чтобы с новой сис темой было удобнее работать, для чего мы сконструировали этот замечательный графический интерфейс. Однако при этом процессору требуется намного больше компьютерной мощности, чем в предыдущей системе с текстовым режимом отображения. Вот почему так возросла загрузка процессора.

Но ведь с новой системой намного удобнее работать, не так ли?» «Так-то оно так, и представить себе не могла, что ее рабо та будет обходиться так дорого. У меня из-за этого могут быть неприятности. Мой менеджер нервничает. При таких условиях он уже в апреле израсходует годовой выделенный от делу на компьютерные нужды. Не могли бы вы исправить сис тему, чтобы снизить стоимость ее работы?» 232 Часть II. Разработка требований к ПО Фил расстроился. «Ничего исправлять не нужно. Новая ма учета сотрудников — это именно то, что вы заказывали. Я предполагал, вы отдаете себе отчет том, что если вы больше данных или больше работаете на компьютере, то ваши затраты вырастут. Возможно, нам следовало обсудить это раньше, поскольку сейчас уже практически ничего не удастся сделать. Мне очень жаль».

Естественно, что пользователей, как правило, интересуют нальные, или требования — то есть возможности, пре ПО, однако для успеха ПО недостаточно правильно лизовать соответствующую функциональность. Кроме того, телей волнует, насколько хорошо новая система будет работать. К характеристикам, описывающим это свойство системы, легкость быстрота запуска, количество сбоев и ботка неожиданных ситуаций. В целом они называются атрибутами чества ПО или факторами качества и считаются частью (или неповеденческих) требований к системе.

Довольно трудно дать определение атрибутам качества, часто именно они отличают продукт, которые просто работает так, как ожидалось, от продукта, который вызывает у клиентов восхищение.

мнению Роберта Шаррета Charette, 1990), «В реальных мах успех или неудачу проекта часто определяют именно нальные требования, а не функциональные». В отличном ПО выдержан оптимальный баланс конкурирующих характеристик качества. Если в ходе сбора информации о требованиях вы досконально не ожидания клиента, относящиеся к качеству, то вам крупно повезет, ли продукт их удовлетворит. Но, как правило, более частый исход — разочарованные пользователи и расстроенные разработчики.

С технической точки зрения атрибуты качества влияют на касающиеся архитектуры и дизайна;

примером может жить распределение системных функций по различным компьютерам для достижения связанных с производительностью или целост ностью. Гораздо труднее и дороже перестраивать систему, чем нировать необходимые параметры с самого начала.

Клиенты, как правило, высказывают свои ожидания о качестве про дукта неявно, однако все же в ходе сбора информации удается нить основное. Хитрость заключается в том, чтобы уловить, что же сто ит за их рассуждениями о том, что система должна быть простой в ращении, быстрой, надежной или устойчивой к сбоям. Качество, во всех его проявлениях, должно быть определено и клиентами, и теми, Глава 12. Обратная сторона функциональности: атрибуты качества ПО кто создает, тестирует и поддерживает ПО. Вопросы, с помощью кото рых выясняются невысказанные ожидания клиентов, позволяют уста новить и качество продукта, и критерии дизайна, что поможет разра ботчикам создать отличный продукт.

Атрибуты качества К атрибутам качества можно отнести несколько дюжин характеристик продукта хотя для большинства проектов хватило бы всего нескольких. Если разработчикам известно, какие характеристи ки наиболее важны для успеха проекта, они могут выбрать соответст вующие приемы, работая над архитектурой, дизайном и программным наполнением ПО, которые позволят достичь определенного качества (Glass, DeGrace и Для классификации атрибутов ка чества применяются различные схемы Brown и Lipow, 1976;

Cavano и 1978;

IEEE 1992;

DeGrace и Stahi, 1993). Один из спо собов классификации основан на разделении характеристик, которые проявляются в период выполнения, и тех, что не проявляются Clements и Kazman, Согласно другому способу разделяются очевидные характеристики, главным образом важные для пользовате лей, от скрытых качеств, которые имеют значение службы техниче ской поддержки. Последние косвенно влияют на мнение клиента, так как упрощают возможные изменения его корректировку, проверку и переход на другие платформы.

В табл. 12-1 перечислено несколько атрибутов качества обеих кате горий, которые необходимо принимать во внимание в любом проекте.

Некоторые много значат для встроенных систем (эффективность и на дежность), тогда как другие особенно важны для Интернет-приложе ний и приложений для мэйнфреймов (доступность, целостность и лег кость в эксплуатации) или для настольных систем (способность к взаи модействию и удобство и простота использования). Для встроенных систем часто учитывают и другие важные атрибуты качества, напри мер безопасность (о которой рассказывалось в главе 10), легкость и простота установки и обслуживания. Для Интернет-приложений также важен еще один атрибут — масштабируемость.

В идеальном мире каждая система имела бы максимально возмож ные значения всех этих атрибутов. Она была бы постоянно доступна и интуитивно понятна, не испытывала бы никаких сбоев, моментально предоставляла бы результаты, естественно, всегда корректные. По скольку все перечисленное — советую вам выяснить с помо 234 Часть II. Разработка требований к ПО табл. какие атрибуты наиболее важны для успеха вашего проекта. Затем разделите их на те, что важны пользователям, и что важны разработчикам, чтобы дизайнеры смогли принять решения.

Таблица Атрибуты качества ПО Важны преимущественно Важны преимущественно для пользователей для разработчиков Доступность Легкость в эксплуатации Эффективность Легкость Возможность повторного Целостность Тестируемость Способность к взаимодействию Устойчивость к сбоям Удобство и простота использования Для различных элементов ПО необходимы различные сочетания ат рибутов качества. Для одних крайне важна эффективность, а для дру гих -- практичность. Выделите параметры качества, относящиеся продукту в и те, что важны только для определенных тов, классов пользователей или вариантов использования.

тируйте ваши глобальные пожелания, касающиеся качества продукта, в разделе 4.5 шаблона спецификации о требованиях к ПО, приведен ного в главе 10, и ассоциируйте с отдельными возможностями, риантами использования или функциональными требованиями.

Определение качества Большинство пользователей не знают ответов на такие вопросы, как ваши требования к возможности взаимодействия?» или «На сколько надежным должно быть программное При ра боте над Chemical Tracking System аналитики придумали вспомогательных вопросов для каждого из атрибутов, которые они считали важными. Например, при исследовании целостности они за интересовались, насколько важно не дать пользователям возмож ность просматривать заказы, которые были размещены другими поль или должна ли у каждого пользователя быть возможность поиска по списку химикатов, находящихся на складе. Они представителей пользователей, чтобы оценить каждый атрибут по Глава Обратная сторона функциональности: атрибуты качества ПО шкале от 1 (не имеет никакого значения) до 5 (крайне важно). Ответы помогли аналитикам выделить наиболее важные атрибуты. Иногда у различных классов пользователей оказывались собственные предпоч тения, тогда при разрешении любых конфликтов преимущество отда валось привилегированному классу.

Затем аналитики поработали с пользователями, чтобы выработать определенные, измеряемые и поддающиеся проверке требования к каждому атрибуту (Robertson и Robertson, 1997). Если атрибуты каче ства нельзя проверить, то не удастся установить, достигнуты ли они.

Следует указывать масштаб или единицы измерения для каждого ат рибута и поставленной задачи, а также их минимальные и ные значения. Система обозначений Planguage, которая описывается далее в этой главе, поможет вам в этом. Если вы не знаете, ка изме рить все важные атрибуты качества, по крайней мере определите их приоритеты и предпочтения клиентов. Стандарт IEEE для Software Quality Metrics предоставляет прием для определения требований к качеству ПО в контексте общей системы измерения каче ства (IEEE, 1992).

Ловушка При рассмотрении качества не пренебрегайте мнением всех заинтересованных сторон, в том числе программистов по техническому обслу живанию.

Возможно, стоит спросить пользователей, они представляют се бе неприемлемые производительность, удобство и простоту исполь зования, целостность и надежность. Это позволит определить свойст ва системы, которые противоречат ожиданиям пользователей о каче стве, например возможность удаления файлов пользователями (Voas, 1999). Определяя неприемлемые характери стики — своего рода обратные требования — попробуйте разработать чтобы реализовать эти характеристики системы на практике.

Если это вам не удастся, вероятно, вы достигли своих целей в шении атрибутов. Такой способ особо важен для приложений, безо пасность которых критически важна: негативные изменения их надеж ности или производительности аукнутся тяжелыми последствиями.

В заключительной части этого раздела кратко описан каждый атри бут качества табл. 12-1 и приводятся некоторые примеры атрибутов (немного из различных проектов. (2002) предлагает множество отличных примеров требований, относящихся к качеству.

236 Часть II. Разработка требований к ПО Атрибуты, важные для пользователей Пользователи совершенно справедливо считают весьма важными рибуты качества, описанные в этом разделе.

Доступность. Под доступностью понимается запланированное доступности в течение которого система действительно дос для использования и полностью работоспособна. Формально доступность равна среднему времени до сбоя (mean time to TF) системы, деленному на сумму среднего времени до сбоя и даемого времени до восстановления системы после сбоя. На достуг также влияют периоды планового технического обслуживания.

Некоторые авторы рассматривают доступность как совокупность на дежности, легкости в эксплуатации и целостности Отдельные задачи более других зависят от времени, и ли будут страшно разочарованы (и даже если система не окажется доступной в нужный момент. Узнайте у клиентов, какой цент времени доступности им действительно необходим и есть ли пе риоды времени, когда доступность настоятельно необходима для биз неса или выполнения задач, связанных с безопасностью. Для Web сайтов и глобальных приложений, с которыми работают по всему миру, требования по доступности еще более сложны и важны.

Одно из требований к доступности можно сформулировать так:

Система должна быть доступна как минимум на 99,5% по рабочим дням, с 6:00 до полуночи по местному времени и доступна как минимум на 99,95% по рабочим дням, с до по местному времени.

Как и другие приведенные здесь примеры, это требование несколь ко упрощено. Оно не определяет уровень производительности во мя доступности. Считается ли система доступной, если в режиме с плохими характеристиками в ней может работать только один ватель сети? Записывайте требования к качеству, чтобы их можно бь ло измерить и добиться четкого соглашения между аналитиком ваний, командой разработчиков и клиентами.

Цена качества Не указывайте для таких атрибутов качества, как надежность или доступность, поскольку такие результаты недостижимы, а стремление достичь их до рого. Одна компания указала в требованиях к системе по обслуживанию цеха равную 24 часа в день, 365 дней в году. Пытаясь добиться указанного уровня доступности, было решено установить две системы, чтобы Глава Обратная сторона функциональности: атрибуты качества ПО обновление ПО выполнялось на машине, не работающей в данный момент. Это до рогостоящее решение оказалось дешевле, чем прекращение производства крайне прибыльного товара.

Эффективность. Эффективностью называется показатель того, на сколько эффективно система использует производительность процес сора, место на диске, память или полосу пропускания соединения (Davis, 1993). Эффективность связана с еще одним классом нефункциональных требований, который обсуждается далее в этой главе. Если система тратит слишком много доступных пользователи заметят снижение производительности — ви димого показателя неэффективности. Недостаточная производитель ность раздражает пользователей, которые ожидают вывода на результата запроса к базе данных. Но проблемы кроме того, ставят под удар безопасность, например, при перегрузке системы контроля процессов реального времени. Определите мальную конфигурацию оборудования, при которой удается достичь заданных эффективности, пропускной способности и производитель ности. Чтобы позволить нижний предел в случае непредвиденных ус ловий и определить последующий рост, вы можете воспользоваться такой формулировкой:

Как минимум 25% пропускной способности процессора и оперативной памяти, доступной приложению, не должно использоваться в услови ях запланированной пиковой Типичные пользователи не формулируют требования к эффективно сти в таких технических терминах. Максимум, на они способны, так это упомянуть время отклика или заполнение пространства на диске.

Дело аналитика — задать вопросы, которые выявят ожидания вателей о приемлемом снижении производительности, возможных пи ках нагрузки и ожидаемом росте.

Поспешишь — людей насмешишь Одна крупная корпорация разрабатывала сложную графическую модель магазина для их компонентов электронного бизнеса. Покупатель мог посетить электронный магазин на Web-сайте, просмотреть предлагаемые услуги и приобрести различные товары. Графика была великолепной, модель - качественной, но быстродействие оказалось ужасным. Пользовательский интерфейс отлично работал у разработчиков, использовавших высокоскоростное Интернет-соединение с локальными серверами.

К сожалению, при стандартных подключениях через модем на скорости 14, 28,8 кбит/с, которые в то время использовало большинство пользователей, огром ные файлы изображений загружались невероятно медленно. Все без исключения 238 Часть II. Разработка требований к ПО бета-тестеры теряли интерес к сайту еще до того, как главная страница успевала полностью загрузиться. Увлекшись графической моделью, разработчики не подума ли об ограничениях операционной среды, эффективности и требованиях к произво дительности. Пришлось отказаться от этого решения уже после его завершения дорогостоящий урок, подтвердивший важность обсуждения атрибутов качества ПО в начале проекта.

Гибкость. Этот атрибут также называют расширяемостью, мостью, наращиваемостью или Гибкость с какой легкостью в продукт удается добавить новые возможности. ли ожидается, что при разработке придется вносить множество улуч шений, стоит выбрать такие решения, которые позволят гибкость ПО. Этот атрибут важен для продуктов, в качестве разработки которых выбрано улучшение и повтор успешных или развитие прототипа. Для проекта, в котором принимал участие, были сформулированы следующие цели, касающиеся реализации гибкости в ПО:

Программист по техническому обслуживанию, не менее шести меся цев работающий с продуктом, должен уметь подключать новое устройство для соз дания печатных копий, что изменение кода и тестирование, не бо лее чем за час рабочего времени.

Проект нельзя считать неудачным, если программисту требуется минут, чтобы установить новый принтер, следовательно, это ние допускает некоторую степень свободы. Если бы мы не указали это требование, возможно, разработчики выбрали бы такой вариант при котором установка нового устройства в системе заняла слишком много времени. Записывайте требования к качеству в мате, который предусматривает возможность их измерения.

Целостность. Целостность — которая включает в себя ность, о чем уже говорилось в главе 10 — связана с блокировкой не авторизированного доступа к системным функциям, нием потери информации, антивирусной защитой ПО и защитой кон фиденциальности и безопасности данных, введенных в систему.

Целостность очень важна для Интернет-приложений.

систем электронной коммерции хотят обезопасить данные своих кредитных карточек. Посетители Web-сайтов не чтобы при ватная информация о них или список посещаемых ими сайтов ис пользовались не по а поставщики услуг доступа к Ин тернету хотят защититься от атак типа «отказ в и прочих атак. В требованиях к целостности нет места ошиб кам. Используйте следующие точные термины для формулирования Глава Обратная сторона функциональности: атрибуты качества ПО требований к целостности: проверка идентификации уровни привилегий ограничения доступа или опреде ленные данные, которые должны быть защищены, Вот как можно сформулировать требования к целостности:

Только обладающие привилегиями уровня Ауди тор, должны иметь возможность просматривать транзакции клиентов.

Как и многие другие требования к целостности, данное помимо про чего считается ограничивающим Неплохо бы знать логическое обоснование ваших требований к атрибутам качества и ис следовать их происхождение, например политику управления. Избе гайте указывать требования к целостности в виде ограничений дизай на, как, скажем, требования к паролю для контроля доступа. Реальное требование должно ограничивать доступ к системе неавторизирован пользователей;

пароли — всего лишь один из способов (хотя и са мый распространенный) выполнения этой задачи, Основанное на вы бранном подходе к идентификации пользователей, это базовое требо вание к целостности повлияет на определенные функциональные требования, которые реализуют функции аутентификации в системе.

Способность к взаимодействию. Способность к взаимодействию показывает, каким образом система обменивается данными или сер висами с другими системами. Чтобы оценить способность к действию, вам необходимо какие приложения клиенты будут применять совместно с вашим продуктом и обмен каких данных пред полагается. Пользователи Chemical Tracking System привыкли рисо вать химические структуры, с помощью нескольких коммерческих ин струментов, поэтому они выдвинули следующее требование к способ ности взаимодействия:

Способность к Chemical Tracking System должна иметь воз можность импортировать любые допустимые химические структуры из пакетов (версии 2.3 или более ранней) и (версии 5 или более ран ней).

Вы также могли бы указать данное требование как требование к внешнему интерфейсу и определить стандартные форматы файлов, которые способна импортировать Chemical Tracking System. В качест ве альтернативы можно определить несколько функциональных требо ваний, относящихся к операции импорта. Однако иногда, рассматри вая систему с точки зрения атрибутов качества, вы что не которые определенные требования не заданы. Клиенты не указали данную потребность при обсуждении внешнего интерфейса или функ циональности системы. Как только аналитик задал вопрос о других системах, с которыми придется взаимодействовать Chemical Tracking 240 Часть II. Разработка требований к ПО System, сторонник продукта немедленно упомянул два пакета для ри сования химических структур.

Надежность. Надежностью называется вероятность работы ПО без сбоев в течение определенного периода времени lannino и 1987). Иногда одной из характеристик надежности считают устойчивость к сбоям. Для измерения надежности ПО используют та кие показатели, как процент успешно завершенных операций и сред ний период времени работы системы до сбоя. Определите количест венные требования к надежности, основываясь на том, серьезными окажутся последствия сбоя и оправдана ли цена повыше ния надежности. Системы, для которых требуется высокая надеж ность, следует проектировать с высокой степенью возможности тес тирования, чтобы облегчить выявление недостатков, отрицательно влияющих на надежность.

Однажды моя команда разрабатывала ПО для управления лабора торным оборудованием, предназначенным для опытов с редкими до рогостоящими химикатами, длящихся целый день.

требовался программный компонент, который обеспечил бы надеж ность проведения экспериментов. Другие системные функции, такие как периодическая запись в журнал данных о температуре, были столь важными. Требования к надежности для данной системы звуча ли так:

Не более пяти из тысячи начатых экспериментов могут быть поте ряны из-за сбоев ПО.

Устойчивость к сбоям. Однажды клиент компании, разрабатываю щей устройства для измерений, пожелал, чтобы их следующий дукт «был, как танк». Сотрудникам компании так понравилось сравне ние, что они ввели в обиход новый, слегка ироничный атрибут — «как танк». Его стали применять, когда речь шла об устойчивости к сбоям, которую еще иногда называют отказоустойчивостью (fault toler ance). Под устойчивостью ксбоям понимают уровень, до тема продолжает корректно выполнять свои функции, несмотря на верный ввод данных, недостатки подключенных программных нентов или компонентов оборудования или неожиданные условия работы. к сбоям ПО легко восстанавливается после личных проблем и «не замечает» ошибок пользователей. Выясняя тре бования к устойчивости работы ПО, спросите пользователей, ошибочные ситуации возможны при работе с системой и как система должна на них реагировать. Вот один из примеров требования к устой чивости Глава Обратная сторона функциональности: атрибуты качества ПО Устойчивость к Если при работе с произошел сбой и поль зователь не успел сохранить файл, то редактор должен восстановить все измене ния, внесенные раньше, чем за минуту до сбоя, при следующем запуске программы данным пользователем.

Несколько лет назад я занимался разработкой программного ком понента многократного использования Graphics Engine, который пре образовывал файлы с графическими схемами и выводил изображение на назначенное устройство вывода 1996b). Несколько прило жений, которым было необходимо создавать графики, обращались к Graphics Engine. Поскольку разработчики не могли контролировать, ка кие именно данные приложения передают в Graphics Engine, важным атрибутом качества была названа устойчивость к сбоям системы. Одно из наших требований звучало так:

Устойчивость к Для всех параметров, описывающих графики, должны быть указаны значения по умолчанию, которые ядро Graphics Engine будет исполь зовать в случае, если данные входного параметра указаны неверно или отсутствуют.

Выполнение этого требования позволит избежать сбоя программы, если, например, приложение запрашивает цвет, который плоттеру не удается воспроизвести. Graphics Engine использует значение по умолчанию — черный цвет — и продолжит работу. Тем не менее это можно рассматривать как сбой поскольку конечный пользователь не получил желаемый цвет. Однако такой подход снизил серьезность последствий сбоя — вместо краха программы получен неправильный цвет, что является примером отказоустойчивости.

Удобство и простота использования. Также называется использования и инженерной психологией. Этот атрибут связан с мас сой факторов, которые составляют основу того, что пользователи то описывают как дружелюбие к пользователю. Но в лексиконе тиков и разработчиков нет термина ПО», они говорят о ПО, которое спроектировано для эффективного и необременитель ного использования. В последнее время вышло несколько книг, посвя щенных разработке удобных в использовании программных систем, например Constantine и и Nielsen (2000). Удобство и простота использования измеряется требуемыми для под готовки ввода данных, эксплуатации и вывода конечной информации.

Аналитики требований для Chemical Tracking System задавали пред ставителям пользователей такие вопросы, как «Насколько важна вас возможность быстрого запроса химикатов?» и «Сколько времени вы готовы отвести на Все это — несложные исход ные точки для определения многих характеристик, которые могут 242 Часть II. Разработка требований к ПО лать ПО удобным в работе. При обсуждении этого атрибута удается явить поддающиеся измерению, например:

Удобство и простота Пользователь, прошедший соответст вующую должен иметь возможность выбрать требуемый химикат из ка талога поставщика в среднем за четыре и максимум за шесть минут, Узнайте, должна ли система соответствовать стандартам или соглашениям, касающимся пользовательского фейса, и должен ли последний быть совместим с другими часто ис пользуемыми системами. Вы можете сформулировать такое ние следующим образом:

Удобство и простота Всем меню должны быстрые клавиши, нажимаемые одновременно с Ctrl. Командам ме ню, которые также присутствуют в меню File пакета Microsoft Word XP, должны соот ветствовать те же быстрые клавиши, что и в Word.

Кроме того, удобство и простота использования определяется и тем, насколько легко новые или непостоянные пользователи научатся рабо тать с продуктом. Простота обучения также поддается исчислению и из мерению:

Удобство и простота использования-3. Химик, который прежде никогда не ис пользовал Chemical Tracking System, не более чем 30 минут разобраться, правильно запросить химикат.

важные для разработчиков В этом разделе описываются атрибуты качества, которые в первую очередь важны для разработчиков ПО и специалистов по техническо му обслуживанию.

Легкость в Этот атрибут показывает, насколько удоб но исправлять ошибки или модифицировать ПО. Легкость в ции зависит от того, насколько просто разобраться в работе ПО, изме нять его и тестировать, и тесно связано с гибкостью и тестируемо стью. Этот показатель крайне важен для которые подвергаются частым изменениям, и тех, что создаются быстро возможно, с экономией на Легкость в эксплуатации измеря ют, используя такие термины, как среднее время, требуемое для раз решения проблемы, и процент корректных исправлений. Для Chemical Tracking System одно из требований к легкости в эксплуатации сфор мулировано таким образом:

Глава Обратная сторона функциональности: атрибуты качества ПО Легкость в занимающийся обслу живанием ПО, должен модифицировать существующие отчеты, чтобы их в соответствие с изменениями в федерального правительства в области химии, затратив на разработку не более 20 рабочих часов.

При работе над проектом Graphics Engine мы понимали, что нам при дется часто вносить исправления в ПО, чтобы оно соответствовало по требностям пользователей. Мы указали примерно такие критерии, что бы разработчикам удалось создать ПО, более легкое в эксплуатации:

Легкость в Вложенность вызываемых функций не должна пре вышать два Легкость в Для каждого программного модуля непустые коммен тарии в соотношении к исходному коду должны составлять как минимум 0,5.

Ставьте такие задачи разработчикам осторожно, иначе те, лишив шись самообладания, действовать букву, но не суть задачи. Поработайте с программистами, занимающимися техническим обслуживанием, чтобы понять, какие качества исходного кода облегчат им внесение изменений или исправление недостатков.

Для аппаратных устройств со встроенным ПО часто имеются требо вания к легкости в эксплуатации. Одни из них относятся к выбору ди зайна ПО, в то время как другие влияют на дизайн оборудования. На пример последнее можно сформулировать так:

Легкость в Дизайн позволяет сертифицированному ремонтнику заменить кабельный шнур печатающей головки не более чем за 10 ми нут, датчик ленты не более чем за 5 минут и привод ленты не более чем за 5 минут.

Легкость перемещения. Мерой ее измерения можно считать усилия, необходимые для перемещения ПО из одной операционной среды в другую. Некоторые практики считают возможность интернационали зации и локализации продукта высшей степенью его мобильности.

Приемы разработки ПО, которые делают легким его перемещение, очень схожи с теми, что применяют, чтобы сделать ПО многократного используемым (Glass, 1992). Обычно мобильность продукта или не имеет никакого или крайне важна для успеха проекта. Важно определить те части продукта, которые необходимо легко перемещать в другие среды, и описать эти целевые среды. Затем разработчики вы берут способы разработки и которые увеличат мобиль ность продукта.

Например, одни компиляторы определяют размер типа данных inte ger в 16 бит, а другие — 32 бит. Чтобы выполнить требования к мобиль ности, программисту надо в символической форме определить тип данных как 16-битное целое без знака и использовать тип 244 Часть II. Разработка требований к ПО WORD вместо целочисленного типа принятого в торе по умолчанию. Таким образом гарантируется, что все ры будут одинаково обращаться к элементам данных типа WORD, что сделает работу системы предсказуемой в различных операционных средах.

Возможность повторного использования. Постоянная задача раз работки ПО — возможность повторного использования — показывает усилия, необходимые для преобразования программных компонентов с целью их дальнейшего применения в других приложениях. Затраты на разработку ПО с возможностью повторного использования тельно выше, чем на создание компонента, который будет работать только в одном приложении. Оно должно быть модульным, хорошо документированным, не зависеть от конкретных приложения и ционной среды, а также обладать некоторыми универсальными можностями. Цели многократного использования сложно количест венно измерить. Укажите, какие элементы новой системы необходимо спроектировать таким образом, чтобы упростить их повторное нение, или укажите библиотеки компонентов многократного исполь зования, которые необходимо создать дополнительно к проекту.

пример:

Возможность повторного Функции ввода химических струк тур должны быть спроектированы таким образом, чтобы их удавалось повторно пользовать на объектного кода в других приложениях, построенных с международных стандартов для представления химических структур.

Тестируемость. Этот атрибут также называют проверяемостью, он показывает легкость, с которой программные компоненты или интег рированный продукт можно проверить на предмет дефектов. Такой ат рибут крайне важен для продукта, в котором используются сложные алгоритмы и логика или имеются тонкие функциональные зи. Тестируемость также важна в том случае, если продукт необходимо часто модифицировать, поскольку предполагается подвергать его частому регрессивному тестированию, чтобы выяснить, не ухудшают ли внесенные изменения существующую функциональность, Поскольку я и команда разработчиков твердо знали, что нам при дется тестировать Graphics Engine много раз в период его ных усовершенствований, мы включили в спецификацию следующую директиву, касающуюся тестируемости ПО:

Максимальная сложность модуля не должна превышать 20.

Цикломатическая сложность (cyclomatic complexity) — это во логических ответвлений в модуле исходного кода Глава 12. Обратная сторона функциональности: атрибуты качества ПО Чем больше и циклов в модуле, тем тяжелее его тестиро вать, понимать и поддерживать. Конечно, проект не будет если значение цикломатической сложности одного из модулей достиг нет 24, однако наша директива указала разработчикам уровень качест ва, к которому следует стремиться. Если бы ее (она представлена как требование к качеству) не было, не факт, что разработчики при написа нии своих программ приняли бы во внимание такую характеристику, как цикломатическая сложность. В результате код программы мог ока заться так запутан, что его тщательное тестирование и дополнение оказалось бы практически невозможным, а отладка вообще стала бы кошмаром.

Требования к производительности Требования к производительности определяют, насколько быстро и качественно система должна выполнять определенные функции. Они определяют такие параметры, как скорость (например, время отклика пропускная способность (количество транзакций в секунду), мощность (нагрузка при совместном и распределе ние по времени (интенсивные запросы реального времени). Жесткие требования к производительности сильно влияют на стратегию разра ботки ПО и выбор поэтому определите задачи, касаю щиеся производительности, для соответствующей операционной сре ды. Все пользователи хотят, чтобы их приложение запускалось момен тально, но реальные требования к производительности различаются для функции проверки орфографии в программе подготовки текстов и для радиолокационной системы наведения ракеты. Требования к про изводительности также должны учитывать снижение производитель при такой перегрузке, как девятый вал звонков в службу спасе ния Вот несколько простых требований к производительности:

Цикл контроля температуры должен быть полностью вы полнен за Интерпретатор должен проводить в минуту разбор как минимум 5000 операторов, не содержащих ошибок.

Web-страница должна загружаться не более чем за секунд при модемном соединении со скоростью 50 кбит/с.

Авторизация запроса на получение денег из банкомата не должна длиться более секунд.

246 Часть II. Разработка требований к ПО Ловушка Не забудьте обдумать, как вы будете оценивать продукт на соответст вие атрибутам качества. Непроверяемые требования к качеству ничем не лучше не проверяемых функциональных требований.

Определение нефункциональных требований с помощью языка Planguage Некоторые из атрибутов качества, перечисленных в этой главе, ются неполными или неспециализированными — очень трудно зить их одной-двумя короткими фразами. Вам не удастся оценить, вечает ли продукт неточно сформулированным требованиям к ву или нет. Кроме того, упрощенные задачи, связанные с качеством производительностью, могут оказаться невыполнимыми. Максималь ное время отклика, равное двум секундам для запроса к БД, замеча тельно работает при несложном поиске в локальной БД, но абсолютно невыполнимо при соединении шести связанных таблиц, размещеннь х на серверах, которые расположены в разных местах.

Для решения проблемы неявных и неполных нефункциональных требований консультант Tom (1988;

разработал язык планирования с большим набором ключевых слов, который по зволяет точно устанавливать атрибуты качества и друге задачи та (Simmons, Далее показано, как выразить требование к произ водительности с помощью всего лишь нескольких из множества клю чевых слов Planguage. Этот пример является версией требований на языке Planguage к производительности из главы 10: «95% запросов БД каталога должны быть выполнены в течение 3 секунд на однопользова тельском компьютере Intel Pentium ГГц под управлением Windows XP, когда доступны как минимум 60% системных ресурсов».

TAG. Производительность. Время отклика на запрос.

Быстрый отклик на запросы БД на пользовательской плат форме.

SCALE. Время (в секундах) между нажатием клавиши Enter и щелчком отправки запроса и началом отображения результатов METER. Тестирование с использованием секундомера, выполненное на 250 тестовых запросах, представляющих определенный онный профиль использования.

Глава 12. Обратная сторона функциональности: атрибуты качества ПО MUST. He более секунд на 98% запросов <— Специалист выездной службы поддержки.

PLAN. He более 3 секунд для запросов категории 8 секунд для всех запросов, WISH. He более двух секунд для всех запросов, Основная пользовательская платформа DEFINED. Процессор Intel Pentium 4 1,1 ГГц, оперативная память 128 Мб, под управлением ОС Microsoft Windows с установленным пакетом версии 3.3, однопользовательский компьютер, свободно как минимум 60% сис темных ресурсов, другие приложения не выполняются, В каждом требовании присутствует уникальный или метка.

Цель (ambition) устанавливает цель или задачу для системы, которая порождает данное требование. Масштаб (scale) определяет единицы измерения, а счетчик (meter) описывает точно, как выполнить измере ния. Все заинтересованные стороны должны одинаково хорошо пони мать, каким образом измеряется производительность.

пользователь проще воспринимает систему измерений, которая осно вана на времени от нажатия клавиши Enter до вывода всех запроса, чем до начала отображения как указано в при мере, Разработчик может заявить, что требование удовлетворено, а пользователь будет утверждать обратное. Точно выраженные требова ния к качеству и системе измерений помогут предотвратить такого ро да недоразумения.

Вы можете указать несколько желаемых количественных которые необходимо измерять. Критерий must (обязательство) опре деляет наименьший достижимый уровень. Требование не удовлетво рено до тех пор, пока не будут удовлетворены все условия must, таким образом, это условие должно быть обосновано в бизнес-терминах.

Можно указать требование must другим способом. Для этого нужно определить условие fait (еще одно ключевое слов языка Planguage), например: «Более 10 секунд ожидания для более 2% всех запросов». Величина plan (план) указывает номинальное я wish (пожелание) представляет собой идеальный результат. Кроме то го, покажите источник требуемой производительности, например, упомянутое выше условие must (обязательство) указал специалист вы ездной службы поддержки. Для облегчения чтения любые специализи рованные термины, используемые в операторах языке Planguage, за даны defined (определяемые).

Planguage определяет множество дополнительных ключевых слов, с помощью которых удается добиться более гибкой и точной 248 Часть II. Разработка требований к ПО кации требований. Так как язык Planguage, его словарь и синтаксис еще рекомендую обратиться за свежей информацией на Web-сайт http://www.gilb.com. Planguage представляет собой мощное средство для точной формулировки атрибутов качества и требований к Указав несколько уровней для ожидаемого ре зультата, вы получите более широкое представление о требованиях к качеству, чем с помощью простых конструкций, таких, как «черное белое» и — нет», Компромиссы для атрибутов Для определенных комбинаций атрибутов компромиссы неизбежны.

Пользователи и разработчики должны решить, какие атрибуты других и при принятии решений соблюдать эти приоритеты. На 12-1 показаны типичные взаимосвязи атрибутов качества, ленных в табл. однако вам следует знать, что возможны ния 1990;

IEEE, 1992;

Glass, Знак в ячейке означа ет, что увеличение величины атрибута в соответствующей строке пози тивно влияет на атрибут в соответствующем столбце. Например, при повышении легкости перемещения программного компонента повы шается гибкость ПО, упрощается подключение к компонентам ПО и возможность повторного использования и тестирования.

Знак в ячейке означает, что увеличение величины атрибута в этой строке негативно влияет на атрибут в соответствующем столбце.

Пустая ячейка означает, что атрибут в этой строке оказывает незначи тельное влияние на атрибут в столбце. Эффективность оказывает гативное влияние на большинство атрибутов. Если вы напишите ком пактную и быструю программу, используя хитрости кодирования и тывая некоторые побочные эффекты при выполнении, вероятнее всего эту программу будет сложно поддерживать и исправлять, а также реносить на другие платформы. Аналогично, системы, которые были оптимизированы для удобства использования или спроектированы как гибкие, пригодные для многократного применения и способные взаи модействовать с другими программными компонентами или компо нентами оборудования, часто грешат проблемами производительно сти. При создании чертежей средствами универсального компонента Graphics Engine, о котором говорилось ранее в этой главе, производи тельность понизилась по сравнению с приложением, где использовался нестандартный код для обработки графики. Вам необходимо найти ба ланс между возможным ухудшением производительности и ожидаемсй Глава Обратная сторона функциональности: атрибуты качества ПО выгодой от предлагаемого решения, чтобы что компро на который вы идете, разумен, Матрица на рис. не симметрична, потому что влияние при уве личении атрибута А на атрибут В не обязательно такое же, как влияние, которое оказывает увеличение атрибута В на атрибут А. Так, из рис.

1 видно, что модификация системы с целью повышения эффективно сти не оказывает эффекта на целостность. Но повышение целостности вероятнее всего весьма отрицательно отразится на эффективности, поскольку системе придется выполнять множество проверок аутен тификации пользователей, зашифрованных данных, проверок на нали чие вирусов и контрольных точек данных.

Рис. Позитивные и негативные взаимосвязи некоторых качества Чтобы оптимизировать баланс атрибутов продукта, в процессе сбо ра информации вам следует определить, задокументировать важней шие атрибуты качества и расставить для них приоритеты. При опреде лении атрибутов качества для проекта, используйте рис. для Часть II. Разработка требований к ПО чтобы не поставить перед собой несовместимые цели. Как это, напри мер, может быть, показано далее.

I Не пытайтесь максимизировать удобство и простоту если ПО должно работать на нескольких платформах 1 Нелегко полностью проверить требования к целостности систем с:

высоким уровнем безопасности. Для универсальных компонентов многократного использования или тех, что предполагаются для свя зи с другими приложениями, можно в некоторой степени требования безопасности.

1 Крайне надежный код окажется менее эффективным из-за ного выполнения им проверок данных и поиска ошибок.

Как правило, слишком ограничивая возможности системы или оп ределяя конфликтующие требования, вы тем самым усложняете чу разработчикам — им гораздо труднее удовлетворить все требова ния заказчика.

Реализация нефункциональных требований Дизайнеры и программисты должны определить наилучший удовлетворения требования для каждого атрибута качества и произво дительности. Хотя атрибуты качества относятся к нефункциональным требованиям, они помогают сформулировать функциональные требо вания, определить направления разработки или техническую инфор мацию, которая позволяют реализовать продукт желаемого В табл. перечислены некоторые категории технической ции, которые могут быть выведены с помощью атрибутов качества.

пример, в медицинское устройство со строгими требованиями к дос тупности может входить источник резервного питания функциональные требования для визуального или звукового оповеще когда продукт работает на резервном питании. Это преобразова ние требований к качеству, имеющих значение для пользователей или для разработчиков, в соответствующую техническую информацию ляется частью процесса разработки требований и дизайна высокого уровня.

Глава 12. Обратная сторона функциональности: атрибуты качества ПО Таблица Преобразование требований к качеству в техническую документацию Типы атрибутов качества Категория технической информации Целостность, способность к взаимодействию, Функциональное требование устойчивость к сбоям, легкость и простота исполь зования, безопасность Доступность, эффективность, гибкость, Архитектура системы надежность Способность к взаимодействию, легкость и про- Ограничения дизайна стота использования Гибкость, легкость в эксплуатации, легкость пере- Руководство по дизайну возможность повторного использования, тестируемость, легкость и про стота использования Легкость перемещения Ограничение реализации Что теперь?

I Определите несколько атрибутов качества для пользователей из табл. кото рые могут пригодиться для вашего текущего проекта. Сформулируйте несколько вопросов о каждом атрибуте, которые помогут пользователям сформулировать их ожидания. Основываясь на ответах пользователей, письменно сформулируйте од ну или несколько задач для каждого важного атрибута.

i Перепишите несколько примеров атрибутов качества этой главы с помощью при необходимости для наглядности делая некоторые допущения.

Удается ли вам выразить эти требования к качеству более точно и недвусмыс ленно с помощью Planguage?

I Напишите одно из ваших собственных требований к атрибуту качества с помо щью Planguage. Попросите клиента, разработчика и представителя отдела тести рования оценить, является ли более информативной или нет?

Изучите ожидания пользователей, касающиеся качества системы, на предмет возможных противоречий и устраните их. Привилегированные классы пользова телей должны иметь наибольшее влияние при принятии компромиссов.

1 Отследите, как атрибуты качества влияют на функциональные требования, огра ничения дизайна и реализации или выбор архитектуры и дизайна Часть II. Разработка требований к ПО Прототипы как средство уменьшения риска сегодня я хотел бы поговорить с вами о требованиях покупателей из Отдела закупок к новой Chemical Tracking System, — начал аналитик требований. — Вы можете рассказать мне, что система должна делать?» «Ничего себе, я даже не как к этому подступиться, — от ветила Шэрон озадаченно. — Я не знаю, как описать мои по требности, но узнаю, когда увижу».

когда увижу», — фраза, от которой в жилах аналитиков ваний стынет кровь. Сразу в воображении возникает картина: команда разработчиков воплощает свои лучшие идеи в разработке ПО, увидеа которое пользователи говорят: не то, попробуйте еще Дей ствительно, представить будущую программную систему и ясно изло жить к ней — нелегкая задача. Многим людям сложно опи сать свои потребности, не имея перед собой чего-то осязаемого, без образца, да и критиковать гораздо легче, чем создавать.

Создание прототипов ПО делает требования более приближает варианты использования к «жизни» и закрывает пробелы з вашем понимании требований. Прототипы предоставляют телям экспериментальную модель или первоначальный срез новой системы, стимулируя их мышление и катализируя обсуждение требо ваний. Обсуждение прототипов на ранних стадиях процесса разработ ки помогает заинтересованным в проекте лицам прийти к общему ниманию требований к системе, что уменьшает риск недовольства за казчиков.

Даже при применении методов разработки требований из щих глав отдельные их части могут быть неопределенными или не ясными как для клиентов, так и для разработчиков, или и тех, и других.

Если вы не исправите эти проблемы, разница в ожиданиях между ви дением продукта и пониманием разработчиков гаран тирована. Трудно точно представить поведение нового ПО при чтении текстовой документации или изучении аналитических моделей. Поль зователи более готовы экспериментировать с прототипом (что весе ло), чем читать спецификацию требований к программному обеспече нию (что скучно). Услышав от пользователей «узнаю, когда увижу», по думайте, как вы можете помочь им наглядно представить свои нужды 2000). Однако ни один из участников не представляет се бе, что же должны создать разработчики, проект обречен.

Прототип (prototype) имеет множество поэтому ожидания участников процесса прототипирования могут весьма различаться.

Прототип самолета действительно летает — ведь это первый вариант настоящего самолета. Напротив, прототип ПО — это только часть или образец реальной системы — он может в принципе не делать ничего полезного. Прототипы ПО могут быть действующими моделями или статичными образцами;

детализированным изображением экрана или его эскизами;

наглядной демонстрацией или примерами реальной функциональности;

имитацией или подражанием {Constantine и Lock wood, Stevens и др., В этой главе описаны различные виды прототипов, их использование во время разработки требований к ПО и способы эффективного внедрения макетирования в процесс разра ботке ПО и Kang, 1992).

Что такое прототип и для чего он нужен Прототип ПО — это частичная или возможная реализация предлагаемо го нового продукта. Прототипы позволяют решать три основные задачи:

i прояснение и завершение процесса формулировки требова ний. Используемый в качестве инструмента формулировки требо ваний прототип представляет собой предварительную версию час ти системы, понимание которой вызывает затруднения. Оценка прототипа пользователями указывает на ошибки в формулировке требований, которые можно исправить без больших затрат до соз дания реального продукта;

исследование альтернативных решений. Прототип, как инстру мент конструирования, позволяет заинтересованным в проекте лицам исследовать различные варианты реализации взаимодейст вия пользователей, оптимизировать удобство работы и оценить 254 Часть II. Разработка требований к ПО возможные технические приемы. Прототипы позволяют на рабочих образцах насколько осуществимы требования;

1 создание конечного продукта. Используемый в качестве инстру мента разработки прототип — не что иное, как функциональная реа лизация первичных элементов системы, которую можно превратить в готовый продукт, осуществляя последовательную цепочку неболь ших циклов разработки.

Основная цель создания прототипа — устранение неясностей на ранних стадиях процесса разработки. Именно исходя из них следует решать, для каких частей системы необходим прототип и что вы надее тесь выяснить, оценивая его. Прототип полезен для выявления и нения двусмысленных и неполных утверждений в требованиях. Пользо ватели, менеджеры и другие заинтересованные в проекте лица, не об ладающие техническими знаниями, считают, что прототип дает им понимание некой пока реальный продукт документируется и разрабатывается. Прототипы, особенно наглядные, легче понять, чем технический жаргон Горизонтальные прототипы Когда люди говорят «прототип они обычно имеют в виду горизон прототип (horizontal prototype) предполагаемого интерфейса пользователя. Его также именуют поведенческим прототипом (behav ioral prototype) или моделью. Горизонтальным прототип потому, что в нем не реализуются все слои архитектуры и нюансы сис темы, но воплощаются некоторые особенности интерфейса теля. Он позволяет пользователям исследовать поведение предпола гаемой системы в тех или иных ситуациях для уточнения требований, а также выяснить, смогут ли они с помощью системы, основанной на прототипе, выполнять свою работу.

Горизонтальный прототип, подобно кинофильму, создает види мость функциональности, не обеспечивая ее действительного вопло щения. Он показывает внешний видэкранов пользовательского интер фейса и позволяет осуществлять частичную навигацию между ними, но не содержит никакой или почти никакой действительной функцио нальности. Это как типичный вестерн: ковбой входит в салун, а затем выходит из конюшни, он не заказывает выпивку и не видит лошадей, потому что за фасадами декораций ничего нет.

Горизонтальные прототипы демонстрируют функциональные воз можности, которые будут доступны пользователю, внешний вид поль Глава 13. Прототипы как средство риска интерфейса планировку, графику, элементы управления) и структуру доступа к информации (структуру навигации).

Перемещение между интерфейса возможно, но вместо не которых элементов пользователь увидит лишь краткое сообщение о том, что будет здесь находиться. появляющаяся в ответ на запрос к базе данных, может быть случайной или а со держание отчетов — жестко Старайтесь использо вать реальные данные в образцах отчетов, диаграмм и это увеличит достоверность прототипа как модели реальной системы.

Горизонтальный прототип не выполняет полезной работы, хотя ино гда и кажется, что должен. Зачастую имитации вполне что бы пользователи могли решить, нет ли каких-либо упущений, невер ных или ненужных функций. Некоторые прототипы выражают концеп цию реализации конкретных вариантов использования, как ее видят разработчики. Оценивая пользователи могут указать на аль тернативные возможности их реализации, пропущенные шаги взаимо действия или дополнительные условия исключений.

Работая с горизонтальным прототипом, пользователь должен кон центрироваться на общих требованиях и последовательности выпол няемых действий, не отвлекаясь на особенности внешнего вида эле ментов экрана (Constantine, На этой стадии не беспокойтесь о точном расположении элементов экрана, шрифтах, цветах, рисунках и элементах управления. Время детализации интерфейса пользователя наступит после того, как прояснятся требования к системе и будет оп ределена общая структура интерфейса.

Вертикальные прототипы Вертикальный прототип (vertical prototype), также называемый структур ным (structural prototype) или проверкой вопло щает срез функциональности приложения от интерфейса пользователя до сервисных функций. Вертикальный прототип действует как настоящая система, поскольку затрагивает все уровни ее реализации. Разрабаты вайте вертикальный прототип всякий раз, когда сомневаетесь в осущест вимости и стабильности предполагаемого подхода к архитектуре системы или когда хотите оптимизировать алгоритмы, оценить предлагаемую схему базы данных или проверить критически важные временные требо вания. Чтобы получить значимые результаты, вертикальные прототипы создают, используя средства разработки вереде, аналогичной среде разработки. Вертикальные прототипы используются для исследования 256 Часть II. Разработка требований к ПО критически важных требований к интерфейсу и времени исполнения, а также для сокращения рисков на стадии проектирования системы.

Однажды я работал с командой, которая занималась реализацией необычной клиент-серверной архитектуры для стратегии перехода от мэйнфрейм-системы к программной среде, основанной на серверах и рабочих станциях, работающих под UNIX и объединенных в сеть (Thompson и Wiegers, 1995). Вертикальный прототип, реализовавший небольшую часть клиента пользовательского интерфейса (на мэйн фрейме) и соответствующую часть функциональности сервера (на ра бочей станции под UNIX), позволил нам оценить коммуникационные компоненты, производительность и надежность предлагаемой ар>и Эксперимент прошел успешно, как и построение решения на основе этой архитектуры.

Pages:     | 1 |   ...   | 2 | 3 || 5 | 6 |   ...   | 9 |



© 2011 www.dissers.ru - «Бесплатная электронная библиотека»

Материалы этого сайта размещены для ознакомления, все права принадлежат их авторам.
Если Вы не согласны с тем, что Ваш материал размещён на этом сайте, пожалуйста, напишите нам, мы в течении 1-2 рабочих дней удалим его.