Технологии программирования - Wiegers.Software R. Development Productivity Award Москва 2004 удк 004. 45 В41 Карл Разработка требований к программному с англ. М. дом Русская Редакция , 2004. ил. Isbn 5-7502-0240-2 Эта книга
 Скачать 37.95 Mb.
| Образовательный портал Как узнать результаты егэ Стихи про летний лагерь 3агадки для детей |
Полное содержание архива WinRAR ZIP archive.zip:  С этим файлом связано 6 файл(ов). Среди них: task2.txt, unit4.png, task1.txt, Mikhneva_Anastasia_1951.pkt, WinRAR_ZIP_archive.zip, Wiegers_Software_Requirements.pdf, Metodicheskie_ukazania_praktika.docx. Показать все связанные файлыГлава Любое изображение стоит 1024 слов 227 разместивший заказ на химикат, может запрашивать химикаты, выпол- нять поиск по каталогам продавцов и получать контейнеры с ми. Операции на диаграмме классов весьма приблизительно ствуют процессам, показанным в кружках на диаграммах потоков дан - нижних уровней. umber iner() химиката I chemicalld vendqrName 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 слов 229 одна и та же реакция системы. Если пользователь не авторизован для запроса химикатов, то система не примет запрос, и таким образом ос- тальные условия несущественны прочерками в таблице ре- шений). Таблица показывает, что результат различных логических комбинаций — лишь пять отдельных функциональных требований. Таблица -2. Пример таблицы решений Chemical Tracking System Номер Условие Пользователь авторизован Химикат есть в наличии Химикат считается опасным Сотрудник, разместивший заказ на хими- кат, прошел соответствующую подготовку Действие Принять Отклонить запрос 1 2 3 true 4 true 5 I true true false true x x x x Рис. Пример дерева решений для Chemical Tracking System На рис. показано дерево решений, представляющее ту же ло- гику. Пять прямоугольников обозначают пять возможных результатов принятия или отклонения запроса на химикат. Таблицы решений и ревья это хорошие способы документации требований 230 Часть II. Разработка требований к ПО (или бизнес-правил), позволяющие не пропустить ни одну комбина- цию условий. Даже сложная таблица или дерево решений более про- сты для чтения, чем повторяющиеся требования в текстовом виде. Последнее напоминание У каждого приема моделирования, описанного в этой книге, есть и свои и свои ограничения. Эти приемы позволяют представить одни и те же области, поэтому вам не надо создавать для своего проекта все типы диаграмм. Например, если вы создаете диа- грамму «сущность — связь» и словарь данных, не стоит рисовать диа- грамму классов (или наоборот). Помните, что вы создаете модели ана- лиза для того, чтобы обеспечить более высокий уровень понимания взаимодействия, чем тот, что дает текстовая спецификация ний к ПО или любое другое представление требований. Старайтесь не стать догматиком и не участвовать в религиозных войнах, которые иногда случаются в мире методов и моделей разработки ПО. Вместе этого, используйте все доступные средства для того, чтобы как лучше объяснить требования к вашей системе, Что теперь? I Опробуйте на практике приемы описанные в этой главе, задоку- ментировав разработку существующей системы. нарисуйте карту ди- алогов для банковского автомата или Web-сайта, которые вы используете. 1 Определите часть спецификации требований к ПО, трудную для восприятия, или ту, где обнаружены дефекты. Выберите модель анализа, описанную в этой главе, которая подходит для представления этой части требований. Нарисуйте модель и оцените, помогла бы она решить проблему, создай вы ее раньше, 1 В следующий раз, когда вам понадобится задокументировать определенные тре- бования, выберите прием моделирования, который дополняет текстовое описа- ние. Сделайте набросок модели на бумаге или доске один или два раза, чтобы убедиться, что вы на верном пути, затем воспользуйтесь коммерческими инстру- ментами автоматизированного проектирования ПО, которые поддерживают ус- ловные обозначения модели, которую вы используете. Глава 11. Любое изображение стоит слов 231 Обратная сторона функциональности: качества ПО «Привет, Фил, это снова Мария. У меня вопрос о новой слу- жебной которой вы сейчас занимаетесь. Как вы знаете, эта система работает на нашем мэйнфрейме и каж- дый отдел должен ежемесячно оплачивать используемое дис- ковое пространство и загрузку процессора. Похоже, что в но- вой системе файлы занимают в два раза больше места на диске, чем в старой. Что еще хуже, загрузка процессора за сессию в три раза выше, чем обычно. Вы можете мне, что происходит?" «Конечно, Мария. Вспомните, вы хотели, чтобы в этой системе хранилось больше данных о каждом сотруднике, чем в преды- дущей, поэтому, естественно, база данных стала значительно больше. Следовательно, ваша ежемесячная плата за зование дискового пространства выросла. Кроме того, вы и остальные сторонники продукта просили, чтобы с новой сис- темой было удобнее работать, для чего мы сконструировали этот замечательный графический интерфейс. Однако при этом процессору требуется намного больше компьютерной мощности, чем в предыдущей системе с текстовым режимом отображения. Вот почему так возросла загрузка процессора. Но ведь с новой системой намного удобнее работать, не так ли?» «Так-то оно так, и представить себе не могла, что ее рабо- та будет обходиться так дорого. У меня из-за этого могут быть неприятности. Мой менеджер нервничает. При таких условиях он уже в апреле израсходует годовой выделенный от- делу на компьютерные нужды. Не могли бы вы исправить сис- тему, чтобы снизить стоимость ее работы?» 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 аналитики придумали вспомогательных вопросов для каждого из атрибутов, которые они считали важными. Например, при исследовании целостности они за- интересовались, насколько важно не дать пользователям возмож- ность просматривать заказы, которые были размещены другими поль- или должна ли у каждого пользователя быть возможность поиска по списку химикатов, находящихся на складе. Они представителей пользователей, чтобы оценить каждый атрибут по Глава Обратная сторона функциональности: атрибуты качества ПО 235 шкале от 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 дней в году. Пытаясь добиться указанного уровня доступности, было решено установить две системы, чтобы перейти в каталог файлов | Образовательный портал Как узнать результаты егэ Стихи про летний лагерь 3агадки для детей |
