Технологии программирования - Wiegers.Software R. Development Productivity Award Москва 2004 удк 004. 45 В41 Карл Разработка требований к программному с англ. М. дом Русская Редакция , 2004. ил. Isbn 5-7502-0240-2 Эта книга
 Скачать 37.95 Mb.
| Образовательный портал Как узнать результаты егэ Стихи про летний лагерь 3агадки для детей |
Полное содержание архива WinRAR ZIP archive.zip:  С этим файлом связано 40454 файл(ов). Среди них: Kopytin_A_I_Diagnostika_v_art-terapii_Metod_Mandala.pdf, Бютнер Жить с агрессивными детьми.doc, Теремкова Н.Э. - Логопедические домашние задания для детей 5-7 л, что такое ЦИПР.docx, Kopytin_A_I_Art-terapia_-_novye_gorizonty.pdf, Сетка песочного листа.docx, АУТИЗМ ПРЕЗЕНТАЦИЯ Краснова (1).ppt.ppt, Professia_tyutor_Informatsionno-metodicheskiy_byulleten.pdf, Semago_M_M_Rabochaya_kniga_psikhologo_-_mediko_pedagogicheskogo_ и ещё 40444 файл(а). Показать все связанные файлыГлава 13. Прототипы как средство риска интерфейса планировку, графику, элементы управления) и структуру доступа к информации (структуру навигации). Перемещение между интерфейса возможно, но вместо не- которых элементов пользователь увидит лишь краткое сообщение о том, что будет здесь находиться. появляющаяся в ответ на запрос к базе данных, может быть случайной или а со- держание отчетов — жестко Старайтесь использо- вать реальные данные в образцах отчетов, диаграмм и это увеличит достоверность прототипа как модели реальной системы. Горизонтальный прототип не выполняет полезной работы, хотя ино- гда и кажется, что должен. Зачастую имитации вполне что- бы пользователи могли решить, нет ли каких-либо упущений, невер- ных или ненужных функций. Некоторые прототипы выражают концеп- цию реализации конкретных вариантов использования, как ее видят разработчики. Оценивая пользователи могут указать на аль- тернативные возможности их реализации, пропущенные шаги взаимо- действия или дополнительные условия исключений. Работая с горизонтальным прототипом, пользователь должен кон- центрироваться на общих требованиях и последовательности выпол- няемых действий, не отвлекаясь на особенности внешнего вида эле- ментов экрана (Constantine, На этой стадии не беспокойтесь о точном расположении элементов экрана, шрифтах, цветах, рисунках и элементах управления. Время детализации интерфейса пользователя наступит после того, как прояснятся требования к системе и будет оп- ределена общая структура интерфейса. Вертикальные прототипы Вертикальный прототип (vertical prototype), также называемый структур- ным (structural prototype) или проверкой вопло- щает срез функциональности приложения от интерфейса пользователя до сервисных функций. Вертикальный прототип действует как настоящая система, поскольку затрагивает все уровни ее реализации. Разрабаты- вайте вертикальный прототип всякий раз, когда сомневаетесь в осущест- вимости и стабильности предполагаемого подхода к архитектуре системы или когда хотите оптимизировать алгоритмы, оценить предлагаемую схему базы данных или проверить критически важные временные требо- вания. Чтобы получить значимые результаты, вертикальные прототипы создают, используя средства разработки вереде, аналогичной среде разработки. Вертикальные прототипы используются для исследования 256 Часть II. Разработка требований к ПО критически важных требований к интерфейсу и времени исполнения, а также для сокращения рисков на стадии проектирования системы. Однажды я работал с командой, которая занималась реализацией необычной клиент-серверной архитектуры для стратегии перехода от мэйнфрейм-системы к программной среде, основанной на серверах и рабочих станциях, работающих под UNIX и объединенных в сеть (Thompson и Wiegers, 1995). Вертикальный прототип, реализовавший небольшую часть клиента пользовательского интерфейса (на мэйн- фрейме) и соответствующую часть функциональности сервера (на ра- бочей станции под UNIX), позволил нам оценить коммуникационные компоненты, производительность и надежность предлагаемой ар>и- Эксперимент прошел успешно, как и построение решения на основе этой архитектуры. Одноразовые прототипы Прежде чем создавать прототип, примите четкое и ясное решение, прекратите ли вы работать с ним после оценки или сделаете его частью выпускаемого продукта. Создайте одноразовый прототип prototype), или исследовательский прототип (exploratory чтобы ответить на вопросы, разрешить неясности и улучшить к ПО (Davis, 1993). Если вы решили, что после выполнения прекратите работу с стройте его как можно более быстро и дешево. Чем больше усилий вы вложите в прототип, тем труднее бу- дет участникам проекта отказаться от него, Создавая одноразовый прототип, разработчики пренебрегают шинством известных им методов конструирования качественного ПО. В одноразовом прототипе предпочтение отдается быстроте реализации и модификации, а не устойчивости, надежности, производительности и долговременному удобству сопровождения. Поэтому внимательно сле- дите, чтобы низкокачественный код одноразового прототипа не попал в окончательный продукт. В противном случае пользователи и персонал технического обслуживания будут страдать от последствий этого в те- чение всего срока эксплуатации продукта. * Не стоит уничтожать прототип, если возможно его повторное применение в будущем. Тем не менее он не должен стать частью окончательного продукта. Поэтому назовите его нереализуемый прототип. Глава 13. Прототипы как средство риска Одноразовый прототип наиболее уместен, когда команда разработ- чиков сталкивается с неизвестностью, неполно- той или неопределенностью в требованиях к ПО. Разрешение этих вопросов уменьшает риск продолжения разработки. Прототип, помо- гающий пользователям и разработчикам визуально представить реа- лизацию требований, позволяет выявить пробелы в документации, а также решить, годятся ли требования для создания продукта, поддер- живающего необходимые бизнес-процессы. Ловушка Не делайте прототип более сложным, чем это необходимо для целей его создания. Не поддавайтесь искушению - или давлению - доба- вить в прототип больше функций. На рис. 13-1 показана последовательность шагов разработки от ва- риантов использования до детализированного проекта интерфейса пользователя через построение одноразового прототипа. Каждое опи- сание варианта использования включает последовательность дейст- вий субъекта и реакцию системы, которые вы можете смоделировать посредством схемы диалогов, чтобы отразить особенности архитек- туры интерфейса пользователя. Одноразовый прототип представляет элементы диалога в виде экранов, меню и диалоговых окон. Когда его оценивают пользователи, возможны изменения в описании вариантов использования (если, например, обнаруживается альтернативный путь) или изменения в карте диалогов. Каждый раз, когда требования уточняются и создаются наброски экранов, элементы интерфейса пользователя оптимизируется для удобства и простоты использова- ния. Такой метод постепенного уточнения обходится дешевле, чем ес- ли вы скакнете прямо от описаний вариантов использования к закон- ченному интерфейсу пользователя, а потом обнаружите серьезные проблемы в требованиях, исправление которых потребует глобальной переделки продукта. Описание использования Карта диалогов связь прототип обратная связь дизайн пользовательского Рис. Последовательность действий от вариантов использования к дизайну интерфейса пользователя через одноразовый прототип 258 Часть II. Разработка требований к ПО Эволюционные прототипы В отличие от одноразового прототипа, эволюционный прототип (evolu- tionary prototype) представляет собой прочный архитектурный «фунда- для постепенного создания окончательного продукта — по прояснения требований. Эволюционное — один компонентов модели спирального цикла разработки ПО 1988) и некоторых процессов разработки объектно-ориентированного ПО 1996). В отличие от одноразовых прототипов, «быстро и начерно», для построения эволюционного прототипа необ- ходимо с самого начала использовать отличный и качественный код. Поэтому на конструирование эволюционного прототипа больше времени, чем на одноразовый прототип, моделирующий те же свойства системы. Эволюционный прототип следует создавать в рас- чете на легкий рост и частое расширение, поэтому должны уделять большое внимание архитектуре и принципам проек- тирования. При создании такого прототипа ни в коем случае не стоит экономить на качестве. Считайте первый цикл в создании эволюционного прототипа проб- ным выпуском, реализующим хорошо понятную и неизменную часть требований. Уроки, извлеченные из реакции пользователей на рование и первоначальное использование продукта, учитываются при модификации в следующем цикле. Окончательный продукт — это куль- минация серии эволюционных прототипов. Такие прототипы позволя- ют пользователям быстро получить действующие образцы. Эволю- ционные прототипы хорошо подходят для приложений, которые, как вы знаете, со временем будут расширяться; к ним относятся, напри- мер, проекты постепенной интеграции различных информационных систем. Эволюционное прототипирование годится и для проектов разра- ботки Интернет-приложений. В одном из таких проектов, которым я руководил, моя команда создала серию из четырех прототипов на ос- нове требований, полученных в результате анализа вариантов исполь- зования. Каждый прототип оценивали несколько пользователей, и мы вносили изменения на основе их ответов на наши вопросы. Исправле- ния, которые мы внесли после оценки четвертого прототипа, стали окончательным вариантом нашего Интернет-сайта. На рис. 13-2 показано несколько способов комбинирования раз- личных видов прототипирования. Например, информацию, получен- ную в результате выполнения серии одноразовых прототипов, вы мо- жете использовать для уточнения требований, которые затем шаг за Глава 13. Прототипы как средство уменьшения риска 259 шагом реализовать через последовательность эволюционных типов. Другой способ, показанный на рис. 13-2, — применение гори- зонтального одноразового прототипа для прояснения требований пе- ред разработкой окончательной версии дизайна пользовательского интерфейса, в то время как одновременно с помощью вертикального прототипирования проверяется архитектура системы, компоненты приложения и алгоритмы ядра. Что вам совершенно точно не удастся так это превратить намеренно низкокачественный одноразовый прото- тип в удобный для сопровождения выверенный код, необходимый для построения окончательной системы. Кроме того, рабочие прототипы, которые демонстрируют возможности продукта нескольким телям, привлекаемым к разработке скорее всего нельзя мас- штабировать для тысяч пользователей без серьезных архитектурных изменений. Втабл. 13-1 суммированы некоторые стандартные вариан- ты применения одноразовых, эволюционных, горизонтальных и верти- кальных прототипов. одноразового горизонтального Рис. Несколько возможных способов использования прототипов а процессе разработки ПО 260 Часть II. Разработка требований к ПО Таблица Стандартные способы применения прототипов ПО Одноразовые Эволюционные Вертикальные Прояснение и уточнение примеров использования и функциональных ний Выявление пропущенных функций Исследование возможных вариантов интерфейса пользователя Демонстрация технической осуществимости Реализация базовых вариантов использования Реализация дополнительных вариантов использования по приоритетам Реализация и доработка Web-сайтов Адаптация системы к быстро ме- няющимся требованиям бизнеса Реализация и наращивание ключе- вой клиент-серверной функцио- нальности и уровней Реализация и оптимизация основ- ных алгоритмов Тестирование и настройка дительности Бумажные и электронные прототипы Не всегда для разрешения неопределенностей в требованиях нужен прототип в виде исполняемого кода. Бумажный прототип proto- иногда его называют низкокачественным прототипом, — это де- шевый, быстрый и низкотехнологичный способ выяснить, как может некий фрагмент системы Hohmann, 1997). Бу- мажные прототипы помогают установить, действительно ли пользова- тели и разработчики одинаково понимают требования. Они вам попробовать, практически не рискуя, сделать шаг при кода продукта. Похожий метод, называемый методом и Widrig, 2000), показывает предлагаемый ин- терфейс пользователя, без привлечения пользователей к работе с ним. Для создания бумажных прототипов требуются инструменты не слож- нее, чем бумага, учетные карточки, наклейки и чистые пластиковые зрачки. Проектировщик делает наброски экранов, как он их представля- ет, не заботясь о где точно будут элементы управле- ния и как они будут выглядеть. Пользователи с готовностью делятся своим мнением, в результате чего возможны глубокие на листе бумаги. В некоторых случаях, однако, они не склонны критико- вать полюбившийся им компьютерный прототип, в который разработчик, Глава 13. Прототипы как средство уменьшения риска 261 по всей видимости, вложил много труда. Разработчики также иногда противятся внесению существенных изменений в тщательно выполнен- ный электронный прототип. При применении низкокачественного прототипа человек играет роль компьютера, пока длится оценочный сценарий. Он инициирует действия, произнося вслух, что он собирается сделать в конкретном экране: «Я хочу выбрать команду Предварительный просмотр из меню Файл». При этом пользователь показывает страницу или учетную кар- точку, представляющую экран, который должен появиться после вы- полнения действия. Это позволяет оценить, соответствует ли ответ ожидаемому и содержит ли экран необходимые элементы. Если нет, вы просто берете чистый лист бумаги или карточку и рисуете все заново. Ищем волшебника Команда разработчиков, копировальные устройства, однажды пожало- валась мне, что у их последнего устройства обнаружились проблемы с удобством Самая обычная задача по копированию выполнялась в пять отдель- ных действий, что пользователям казалось ужасно неудобным. «Надо было нам сде- лать прототип этой задачи чем создавать продукт», - тоскливо сказал один разработчиков. Но как же прототип ровать такой сложный как копировальный аппарат? Во- купите большой телевизор. Во-вторых, напишите на коробке от него «КОПИРОВАЛЬНЫЙ АППАРАТ». Потом посадите кого-нибудь внутрь коробки и попросите пользователя подойти снаружи и изображать различные операции с ап- паратом. Человек внутри коробки будет отвечать так, как, по его мнению, реагиро- вало бы устройство, а представитель пользователей должен отмечать, та ли это ре- акция, которую он себе представляет. С помощью простого, веселого прототипа, подобного этому, - иногда его называют «прототипом волшебника из страны Оз» - зачастую удается на ранних стадиях разработки получить реакцию пользователей, руководствуясь которой разработчики и строят решения. Плюс вы получаете боль- шой телевизор. Какими бы совершенными ни были ваши инструменты рования, наброски экранов на бумаге делать все равно быстрее. Бумажное прототипирование ускоряет каждый цикл, а это — ключевой фактор успеха при разработке требований. Это отличный метод уточ- нения требований для проектирования детализированных интерфей- сов пользователей, создания эволюционных прототипов или традици- онного проектирования и конструирования. Он также помогает коман- де лучше управлять ожиданиями клиентов. 262 Часть II. Разработка требований к ПО Если вы решите создать электронный одноразовый прототип, вос- пользуйтесь соответствующими инструментами Неко- торые из них перечислены здесь: I языки программирования, как Microsoft Visual Basic, IBM и Inprise Delphi; языки подготовки сценариев, такие, как Python и Rexx; I коммерческие наборы инструментальных средств ния, средства раскраски изображений на экране и компоновщики графического интерфейса пользователя; средства рисования, такие, как Microsoft Visio и Microsoft Powe - Point. Средства для Web, использующие легко модифицируемые страни- цы HTML (Hypertext Markup Language), годятся для создания прото- типов, которые предназначены для прояснения требований. они не позволяют быстро исследовать детализированный дизайн ин- терфейсов. Соответствующие инструменты позволят вам с легкостью реализовать и обновлять компоненты интерфейса пользователя, вне зависимости от неэффективности его кода. Конечно же, если вы даете эволюционный прототип, то должны использовать высококаче- ственные средства разработки с самого начала. Оценка прототипа Для улучшения оценки горизонтальных прототипов создавайте сцена- рии, проводящие пользователей через последовательность и задавайте конкретные вопросы, чтобы выявить требуемую информа- цию. Этот метод — дополнение к общему приглашению: что вы думаете об этом прототипе». Сценарии оценки составляйте на основании вариантов использования или функций, которые должен представлять прототип. Сценарий попросит пользователей определенные задачи и проведет их через наиболее неясные области прототипа. В конце выполнения каждой задачи и, возможно, в пунктах, сценарий задает связанные с задачами вопросы. Ну и, конечно же, вы вправе задать вопросы сами. 1 Реализует ли прототип все необходимые функции так, как вы этого ожидали? 1 Не упущены ли какие-либо необходимые функции? 1 Заметили ли вы какие-либо условия ошибки, не учтенные в про- тотипе? I Нет ли в прототипе каких-либо ненужных функций? перейти в каталог файлов | Образовательный портал Как узнать результаты егэ Стихи про летний лагерь 3агадки для детей |
