Технологии программирования - 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. Показать все связанные файлыГлава Обратная сторона функциональности: атрибуты качества ПО 237 обновление ПО выполнялось на машине, не работающей в данный момент. Это до- рогостоящее решение оказалось дешевле, чем прекращение производства крайне прибыльного товара. Эффективность. Эффективностью называется показатель того, на- сколько эффективно система использует производительность процес- сора, место на диске, память или полосу пропускания соединения (Davis, 1993). Эффективность связана с еще одним классом нефункциональных требований, который обсуждается далее в этой главе. Если система тратит слишком много доступных пользователи заметят снижение производительности — ви- димого показателя неэффективности. Недостаточная производитель- ность раздражает пользователей, которые ожидают вывода на результата запроса к базе данных. Но проблемы кроме того, ставят под удар безопасность, например, при перегрузке системы контроля процессов реального времени. Определите мальную конфигурацию оборудования, при которой удается достичь заданных эффективности, пропускной способности и производитель- ности. Чтобы позволить нижний предел в случае непредвиденных ус- ловий и определить последующий рост, вы можете воспользоваться такой формулировкой: Как минимум 25% пропускной способности процессора и оперативной памяти, доступной приложению, не должно использоваться в услови- ях запланированной пиковой Типичные пользователи не формулируют требования к эффективно- сти в таких технических терминах. Максимум, на они способны, так это упомянуть время отклика или заполнение пространства на диске. Дело аналитика — задать вопросы, которые выявят ожидания вателей о приемлемом снижении производительности, возможных пи- ках нагрузки и ожидаемом росте. Поспешишь — людей насмешишь Одна крупная корпорация разрабатывала сложную графическую модель магазина для их компонентов электронного бизнеса. Покупатель мог посетить электронный магазин на Web-сайте, просмотреть предлагаемые услуги и приобрести различные товары. Графика была великолепной, модель - качественной, но быстродействие оказалось ужасным. Пользовательский интерфейс отлично работал у разработчиков, использовавших высокоскоростное Интернет-соединение с локальными серверами. К сожалению, при стандартных подключениях через модем на скорости 14,4 28,8 кбит/с, которые в то время использовало большинство пользователей, огром- ные файлы изображений загружались невероятно медленно. Все без исключения 238 Часть II. Разработка требований к ПО бета-тестеры теряли интерес к сайту еще до того, как главная страница успевала полностью загрузиться. Увлекшись графической моделью, разработчики не подума- ли об ограничениях операционной среды, эффективности и требованиях к произво- дительности. Пришлось отказаться от этого решения уже после его завершения - дорогостоящий урок, подтвердивший важность обсуждения атрибутов качества ПО в начале проекта. Гибкость. Этот атрибут также называют расширяемостью, мостью, наращиваемостью или Гибкость с какой легкостью в продукт удается добавить новые возможности. - ли ожидается, что при разработке придется вносить множество улуч- шений, стоит выбрать такие решения, которые позволят гибкость ПО. Этот атрибут важен для продуктов, в качестве разработки которых выбрано улучшение и повтор успешных или развитие прототипа. Для проекта, в котором принимал участие, были сформулированы следующие цели, касающиеся реализации гибкости в ПО: Программист по техническому обслуживанию, не менее шести меся- цев работающий с продуктом, должен уметь подключать новое устройство для соз- дания печатных копий, что изменение кода и тестирование, не бо- лее чем за час рабочего времени. Проект нельзя считать неудачным, если программисту требуется минут, чтобы установить новый принтер, следовательно, это ние допускает некоторую степень свободы. Если бы мы не указали это требование, возможно, разработчики выбрали бы такой вариант при котором установка нового устройства в системе заняла слишком много времени. Записывайте требования к качеству в мате, который предусматривает возможность их измерения. Целостность. Целостность — которая включает в себя ность, о чем уже говорилось в главе 10 — связана с блокировкой не- авторизированного доступа к системным функциям, нием потери информации, антивирусной защитой ПО и защитой кон- фиденциальности и безопасности данных, введенных в систему. Целостность очень важна для Интернет-приложений. систем электронной коммерции хотят обезопасить данные своих кредитных карточек. Посетители Web-сайтов не чтобы при- ватная информация о них или список посещаемых ими сайтов ис- пользовались не по а поставщики услуг доступа к Ин- тернету хотят защититься от атак типа «отказ в и прочих атак. В требованиях к целостности нет места ошиб- кам. Используйте следующие точные термины для формулирования Глава Обратная сторона функциональности: атрибуты качества ПО 239 требований к целостности: проверка идентификации уровни привилегий ограничения доступа или опреде- ленные данные, которые должны быть защищены, Вот как можно сформулировать требования к целостности: Только обладающие привилегиями уровня Ауди- тор, должны иметь возможность просматривать транзакции клиентов. Как и многие другие требования к целостности, данное помимо про- чего считается ограничивающим Неплохо бы знать логическое обоснование ваших требований к атрибутам качества и ис- следовать их происхождение, например политику управления. Избе- гайте указывать требования к целостности в виде ограничений дизай- на, как, скажем, требования к паролю для контроля доступа. Реальное требование должно ограничивать доступ к системе неавторизирован- пользователей; пароли — всего лишь один из способов (хотя и са- мый распространенный) выполнения этой задачи, Основанное на вы- бранном подходе к идентификации пользователей, это базовое требо- вание к целостности повлияет на определенные функциональные требования, которые реализуют функции аутентификации в системе. Способность к взаимодействию. Способность к взаимодействию показывает, каким образом система обменивается данными или сер- висами с другими системами. Чтобы оценить способность к действию, вам необходимо какие приложения клиенты будут применять совместно с вашим продуктом и обмен каких данных пред- полагается. Пользователи 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 одно из требований к легкости в эксплуатации сфор- мулировано таким образом: Глава Обратная сторона функциональности: атрибуты качества ПО 243 Легкость в занимающийся обслу- живанием ПО, должен модифицировать существующие отчеты, чтобы их в соответствие с изменениями в федерального правительства в области химии, затратив на разработку не более 20 рабочих часов. При работе над проектом Graphics Engine мы понимали, что нам при- дется часто вносить исправления в ПО, чтобы оно соответствовало по- требностям пользователей. Мы указали примерно такие критерии, что- бы разработчикам удалось создать ПО, более легкое в эксплуатации: Легкость в Вложенность вызываемых функций не должна пре- вышать два Легкость в Для каждого программного модуля непустые коммен- тарии в соотношении к исходному коду должны составлять как минимум 0,5. Ставьте такие задачи разработчикам осторожно, иначе те, лишив- шись самообладания, действовать букву, но не суть задачи. Поработайте с программистами, занимающимися техническим обслуживанием, чтобы понять, какие качества исходного кода облегчат им внесение изменений или исправление недостатков. Для аппаратных устройств со встроенным ПО часто имеются требо- вания к легкости в эксплуатации. Одни из них относятся к выбору ди- зайна ПО, в то время как другие влияют на дизайн оборудования. На- пример последнее можно сформулировать так: Легкость в Дизайн позволяет сертифицированному ремонтнику заменить кабельный шнур печатающей головки не более чем за 10 ми- нут, датчик ленты не более чем за 5 минут и привод ленты не более чем за 5 минут. Легкость перемещения. Мерой ее измерения можно считать усилия, необходимые для перемещения ПО из одной операционной среды в другую. Некоторые практики считают возможность интернационали- зации и локализации продукта высшей степенью его мобильности. Приемы разработки ПО, которые делают легким его перемещение, очень схожи с теми, что применяют, чтобы сделать ПО многократного используемым (Glass, 1992). Обычно мобильность продукта или не имеет никакого или крайне важна для успеха проекта. Важно определить те части продукта, которые необходимо легко перемещать в другие среды, и описать эти целевые среды. Затем разработчики вы- берут способы разработки и которые увеличат мобиль- ность продукта. Например, одни компиляторы определяют размер типа данных inte- ger в 16 бит, а другие — 32 бит. Чтобы выполнить требования к мобиль- ности, программисту надо в символической форме определить тип данных как 16-битное целое без знака и использовать тип 244 Часть II. Разработка требований к ПО WORD вместо целочисленного типа принятого в торе по умолчанию. Таким образом гарантируется, что все ры будут одинаково обращаться к элементам данных типа WORD, что сделает работу системы предсказуемой в различных операционных средах. Возможность повторного использования. Постоянная задача раз- работки ПО — возможность повторного использования — показывает усилия, необходимые для преобразования программных компонентов с целью их дальнейшего применения в других приложениях. Затраты на разработку ПО с возможностью повторного использования тельно выше, чем на создание компонента, который будет работать только в одном приложении. Оно должно быть модульным, хорошо документированным, не зависеть от конкретных приложения и ционной среды, а также обладать некоторыми универсальными можностями. Цели многократного использования сложно количест- венно измерить. Укажите, какие элементы новой системы необходимо спроектировать таким образом, чтобы упростить их повторное нение, или укажите библиотеки компонентов многократного исполь- зования, которые необходимо создать дополнительно к проекту. пример: Возможность повторного Функции ввода химических струк- тур должны быть спроектированы таким образом, чтобы их удавалось повторно пользовать на объектного кода в других приложениях, построенных с международных стандартов для представления химических структур. Тестируемость. Этот атрибут также называют проверяемостью, он показывает легкость, с которой программные компоненты или интег- рированный продукт можно проверить на предмет дефектов. Такой ат- рибут крайне важен для продукта, в котором используются сложные алгоритмы и логика или имеются тонкие функциональные зи. Тестируемость также важна в том случае, если продукт необходимо часто модифицировать, поскольку предполагается подвергать его частому регрессивному тестированию, чтобы выяснить, не ухудшают ли внесенные изменения существующую функциональность, Поскольку я и команда разработчиков твердо знали, что нам при- дется тестировать Graphics Engine много раз в период его ных усовершенствований, мы включили в спецификацию следующую директиву, касающуюся тестируемости ПО: Максимальная сложность модуля не должна превышать 20. Цикломатическая сложность (cyclomatic complexity) — это - во логических ответвлений в модуле исходного кода перейти в каталог файлов | Образовательный портал Как узнать результаты егэ Стихи про летний лагерь 3агадки для детей |
