Технологии программирования - 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. Показать все связанные файлыГлава 12. Обратная сторона функциональности: атрибуты качества ПО 245 Чем больше и циклов в модуле, тем тяжелее его тестиро- вать, понимать и поддерживать. Конечно, проект не будет если значение цикломатической сложности одного из модулей достиг- нет 24, однако наша директива указала разработчикам уровень качест- ва, к которому следует стремиться. Если бы ее (она представлена как требование к качеству) не было, не факт, что разработчики при написа- нии своих программ приняли бы во внимание такую характеристику, как цикломатическая сложность. В результате код программы мог ока- заться так запутан, что его тщательное тестирование и дополнение оказалось бы практически невозможным, а отладка вообще стала бы кошмаром. Требования к производительности Требования к производительности определяют, насколько быстро и качественно система должна выполнять определенные функции. Они определяют такие параметры, как скорость (например, время отклика пропускная способность (количество транзакций в секунду), мощность (нагрузка при совместном и распределе- ние по времени (интенсивные запросы реального времени). Жесткие требования к производительности сильно влияют на стратегию разра- ботки ПО и выбор поэтому определите задачи, касаю- щиеся производительности, для соответствующей операционной сре- ды. Все пользователи хотят, чтобы их приложение запускалось момен- тально, но реальные требования к производительности различаются для функции проверки орфографии в программе подготовки текстов и для радиолокационной системы наведения ракеты. Требования к про- изводительности также должны учитывать снижение производитель- при такой перегрузке, как девятый вал звонков в службу спасе- ния Вот несколько простых требований к производительности: Цикл контроля температуры должен быть полностью вы- полнен за 80 Интерпретатор должен проводить в минуту разбор как минимум 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. Обратная сторона функциональности: атрибуты качества ПО 247 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-сайт https://www.gilb.com. Planguage представляет собой мощное средство для точной формулировки атрибутов качества и требований к Указав несколько уровней для ожидаемого ре- зультата, вы получите более широкое представление о требованиях к качеству, чем с помощью простых конструкций, таких, как «черное - белое» и — нет», Компромиссы для атрибутов Для определенных комбинаций атрибутов компромиссы неизбежны. Пользователи и разработчики должны решить, какие атрибуты других и при принятии решений соблюдать эти приоритеты. На 12-1 показаны типичные взаимосвязи атрибутов качества, ленных в табл. однако вам следует знать, что возможны ния 1990; IEEE, 1992; Glass, Знак в ячейке означа- ет, что увеличение величины атрибута в соответствующей строке пози- тивно влияет на атрибут в соответствующем столбце. Например, при повышении легкости перемещения программного компонента повы- шается гибкость ПО, упрощается подключение к компонентам ПО и возможность повторного использования и тестирования. Знак в ячейке означает, что увеличение величины атрибута в этой строке негативно влияет на атрибут в соответствующем столбце. Пустая ячейка означает, что атрибут в этой строке оказывает незначи- тельное влияние на атрибут в столбце. Эффективность оказывает гативное влияние на большинство атрибутов. Если вы напишите ком- пактную и быструю программу, используя хитрости кодирования и тывая некоторые побочные эффекты при выполнении, вероятнее всего эту программу будет сложно поддерживать и исправлять, а также реносить на другие платформы. Аналогично, системы, которые были оптимизированы для удобства использования или спроектированы как гибкие, пригодные для многократного применения и способные взаи- модействовать с другими программными компонентами или компо- нентами оборудования, часто грешат проблемами производительно- сти. При создании чертежей средствами универсального компонента Graphics Engine, о котором говорилось ранее в этой главе, производи- тельность понизилась по сравнению с приложением, где использовался нестандартный код для обработки графики. Вам необходимо найти ба- ланс между возможным ухудшением производительности и ожидаемсй Глава Обратная сторона функциональности: атрибуты качества ПО 249 выгодой от предлагаемого решения, чтобы что компро- на который вы идете, разумен, Матрица на рис. не симметрична, потому что влияние при уве- личении атрибута А на атрибут В не обязательно такое же, как влияние, которое оказывает увеличение атрибута В на атрибут А. Так, из рис. 1 видно, что модификация системы с целью повышения эффективно- сти не оказывает эффекта на целостность. Но повышение целостности вероятнее всего весьма отрицательно отразится на эффективности, поскольку системе придется выполнять множество проверок аутен- тификации пользователей, зашифрованных данных, проверок на нали- чие вирусов и контрольных точек данных. Рис. Позитивные и негативные взаимосвязи некоторых качества Чтобы оптимизировать баланс атрибутов продукта, в процессе сбо- ра информации вам следует определить, задокументировать важней- шие атрибуты качества и расставить для них приоритеты. При опреде- лении атрибутов качества для проекта, используйте рис. для 250 Часть II. Разработка требований к ПО чтобы не поставить перед собой несовместимые цели. Как это, напри- мер, может быть, показано далее. I Не пытайтесь максимизировать удобство и простоту если ПО должно работать на нескольких платформах 1 Нелегко полностью проверить требования к целостности систем с: высоким уровнем безопасности. Для универсальных компонентов многократного использования или тех, что предполагаются для свя зи с другими приложениями, можно в некоторой степени требования безопасности. 1 Крайне надежный код окажется менее эффективным из-за ного выполнения им проверок данных и поиска ошибок. Как правило, слишком ограничивая возможности системы или оп- ределяя конфликтующие требования, вы тем самым усложняете чу разработчикам — им гораздо труднее удовлетворить все требова- ния заказчика. Реализация нефункциональных требований Дизайнеры и программисты должны определить наилучший удовлетворения требования для каждого атрибута качества и произво- дительности. Хотя атрибуты качества относятся к нефункциональным требованиям, они помогают сформулировать функциональные требо- вания, определить направления разработки или техническую инфор- мацию, которая позволяют реализовать продукт желаемого В табл. перечислены некоторые категории технической ции, которые могут быть выведены с помощью атрибутов качества. пример, в медицинское устройство со строгими требованиями к дос- тупности может входить источник резервного питания функциональные требования для визуального или звукового оповеще- когда продукт работает на резервном питании. Это преобразова- ние требований к качеству, имеющих значение для пользователей или для разработчиков, в соответствующую техническую информацию ляется частью процесса разработки требований и дизайна высокого уровня. Глава 12. Обратная сторона функциональности: атрибуты качества ПО 251 Таблица Преобразование требований к качеству в техническую документацию Типы атрибутов качества Категория технической информации Целостность, способность к взаимодействию, Функциональное требование устойчивость к сбоям, легкость и простота исполь- зования, безопасность Доступность, эффективность, гибкость, Архитектура системы надежность Способность к взаимодействию, легкость и про- Ограничения дизайна стота использования Гибкость, легкость в эксплуатации, легкость пере- Руководство по дизайну возможность повторного использования, тестируемость, легкость и про- стота использования Легкость перемещения Ограничение реализации Что теперь? I Определите несколько атрибутов качества для пользователей из табл. кото- рые могут пригодиться для вашего текущего проекта. Сформулируйте несколько вопросов о каждом атрибуте, которые помогут пользователям сформулировать их ожидания. Основываясь на ответах пользователей, письменно сформулируйте од- ну или несколько задач для каждого важного атрибута. i Перепишите несколько примеров атрибутов качества этой главы с помощью при необходимости для наглядности делая некоторые допущения. Удается ли вам выразить эти требования к качеству более точно и недвусмыс- ленно с помощью Planguage? I Напишите одно из ваших собственных требований к атрибуту качества с помо- щью Planguage. Попросите клиента, разработчика и представителя отдела тести- рования оценить, является ли более информативной или нет? Изучите ожидания пользователей, касающиеся качества системы, на предмет возможных противоречий и устраните их. Привилегированные классы пользова- телей должны иметь наибольшее влияние при принятии компромиссов. 1 Отследите, как атрибуты качества влияют на функциональные требования, огра- ничения дизайна и реализации или выбор архитектуры и дизайна Часть II. Разработка требований к ПО Прототипы как средство уменьшения риска сегодня я хотел бы поговорить с вами о требованиях покупателей из Отдела закупок к новой Chemical Tracking System, — начал аналитик требований. — Вы можете рассказать мне, что система должна делать?» «Ничего себе, я даже не как к этому подступиться, — от- ветила Шэрон озадаченно. — Я не знаю, как описать мои по- требности, но узнаю, когда увижу». когда увижу», — фраза, от которой в жилах аналитиков ваний стынет кровь. Сразу в воображении возникает картина: команда разработчиков воплощает свои лучшие идеи в разработке ПО, увидеа которое пользователи говорят: не то, попробуйте еще Дей- ствительно, представить будущую программную систему и ясно изло- жить к ней — нелегкая задача. Многим людям сложно опи- сать свои потребности, не имея перед собой чего-то осязаемого, без образца, да и критиковать гораздо легче, чем создавать. Создание прототипов ПО делает требования более приближает варианты использования к «жизни» и закрывает пробелы з вашем понимании требований. Прототипы предоставляют телям экспериментальную модель или первоначальный срез новой системы, стимулируя их мышление и катализируя обсуждение требо- ваний. Обсуждение прототипов на ранних стадиях процесса разработ- ки помогает заинтересованным в проекте лицам прийти к общему ниманию требований к системе, что уменьшает риск недовольства за- казчиков. Даже при применении методов разработки требований из щих глав отдельные их части могут быть неопределенными или не- ясными как для клиентов, так и для разработчиков, или и тех, и других. 253 Если вы не исправите эти проблемы, разница в ожиданиях между ви- дением продукта и пониманием разработчиков гаран- тирована. Трудно точно представить поведение нового ПО при чтении текстовой документации или изучении аналитических моделей. Поль- зователи более готовы экспериментировать с прототипом (что весе- ло), чем читать спецификацию требований к программному обеспече- нию (что скучно). Услышав от пользователей «узнаю, когда увижу», по- думайте, как вы можете помочь им наглядно представить свои нужды 2000). Однако ни один из участников не представляет се- бе, что же должны создать разработчики, проект обречен. Прототип (prototype) имеет множество поэтому ожидания участников процесса прототипирования могут весьма различаться. Прототип самолета действительно летает — ведь это первый вариант настоящего самолета. Напротив, прототип ПО — это только часть или образец реальной системы — он может в принципе не делать ничего полезного. Прототипы ПО могут быть действующими моделями или статичными образцами; детализированным изображением экрана или его эскизами; наглядной демонстрацией или примерами реальной функциональности; имитацией или подражанием {Constantine и Lock- wood, Stevens и др., В этой главе описаны различные виды прототипов, их использование во время разработки требований к ПО и способы эффективного внедрения макетирования в процесс разра- ботке ПО и Kang, 1992). Что такое прототип и для чего он нужен Прототип ПО — это частичная или возможная реализация предлагаемо- го нового продукта. Прототипы позволяют решать три основные задачи: i прояснение и завершение процесса формулировки требова- ний. Используемый в качестве инструмента формулировки требо- ваний прототип представляет собой предварительную версию час- ти системы, понимание которой вызывает затруднения. Оценка прототипа пользователями указывает на ошибки в формулировке требований, которые можно исправить без больших затрат до соз- дания реального продукта; исследование альтернативных решений. Прототип, как инстру- мент конструирования, позволяет заинтересованным в проекте лицам исследовать различные варианты реализации взаимодейст- вия пользователей, оптимизировать удобство работы и оценить 254 Часть II. Разработка требований к ПО возможные технические приемы. Прототипы позволяют на рабочих образцах насколько осуществимы требования; 1 создание конечного продукта. Используемый в качестве инстру- мента разработки прототип — не что иное, как функциональная реа- лизация первичных элементов системы, которую можно превратить в готовый продукт, осуществляя последовательную цепочку неболь- ших циклов разработки. Основная цель создания прототипа — устранение неясностей на ранних стадиях процесса разработки. Именно исходя из них следует решать, для каких частей системы необходим прототип и что вы надее- тесь выяснить, оценивая его. Прототип полезен для выявления и нения двусмысленных и неполных утверждений в требованиях. Пользо- ватели, менеджеры и другие заинтересованные в проекте лица, не об- ладающие техническими знаниями, считают, что прототип дает им понимание некой пока реальный продукт документируется и разрабатывается. Прототипы, особенно наглядные, легче понять, чем технический жаргон Горизонтальные прототипы Когда люди говорят «прототип они обычно имеют в виду горизон- прототип (horizontal prototype) предполагаемого интерфейса пользователя. Его также именуют поведенческим прототипом (behav- ioral prototype) или моделью. Горизонтальным прототип потому, что в нем не реализуются все слои архитектуры и нюансы сис- темы, но воплощаются некоторые особенности интерфейса теля. Он позволяет пользователям исследовать поведение предпола- гаемой системы в тех или иных ситуациях для уточнения требований, а также выяснить, смогут ли они с помощью системы, основанной на прототипе, выполнять свою работу. Горизонтальный прототип, подобно кинофильму, создает види- мость функциональности, не обеспечивая ее действительного вопло- щения. Он показывает внешний видэкранов пользовательского интер- фейса и позволяет осуществлять частичную навигацию между ними, но не содержит никакой или почти никакой действительной функцио- нальности. Это как типичный вестерн: ковбой входит в салун, а затем выходит из конюшни, он не заказывает выпивку и не видит лошадей, потому что за фасадами декораций ничего нет. Горизонтальные прототипы демонстрируют функциональные воз- можности, которые будут доступны пользователю, внешний вид поль- перейти в каталог файлов | Образовательный портал Как узнать результаты егэ Стихи про летний лагерь 3агадки для детей |
