Принципы работы с требованиями к ПО. Леффингуэлл (2002) (1186169), страница 29
Текст из файла (страница 29)
В программировании раскадровки чаще всего используются при работе с деталями человеко. машинного интерфейса, где каждый пользователь может иметь свое мнение о том, как должен работать интерфейс. Раскадровки для ориентированных на пользователя систем описывают три основных элемента любой деятельности. 1. Кто такие игроки? 2. Что с ними происходит? 3. Как это происходит? Элемент «шэ определяет игроков или пользователей системы. В системах программного обеспечения, обсуждавшихся ранее, "кто" — это такие игроки, как пользователи, другие системы или приборы, т.е. акторы, которые взаимодействуют с создаваемой системой-решением. Для пользователей взаимодействие, как правило, описывается с помощью специально организованного экранного ввода или форм ввода данных, выходной информации в виде данных или отчетов, а также устройств ввода и вывода других типов, тааих как кнопки, переключатели, дисплеи и мониторы.
Для приборов и систем взаимодействие будет осуществлятъся посредством программных или аппаратных интерфейсов, таких кзк коммуникационный протокол илн сигнал привода контроллера мотора. Элемент чяю представляет поведение пользователей при взаимодействии с системой нли, наоборот, поведение системы при взаимодействии с пользователем. Элемент «а« описывает состояния, в которых пребывает игрок или система при взаимодействии.
Например, в свое время мы создали раскадровку для автоматически управляемых развлекательных атчракционов в парке. ° Элемент «шо представляет посетителей аттракциона. ° гйяо представляет поведение аттракциона, предлагавшего посетителям различные события. ° Ка«демонстрирует более подробное описание того, как это взаимодействие происходит- события, переход из одного состояния в другое, — и описывает как состояния посетителей (удивление, испуг), так и состояния аттракциона (ускорение, торможение, разгрузка). 144 т1асть 2.
Понимание потребностей пользователей Средства и методы раскадровки Раскадровки могут быть настолько разнообразны, насколько позволяет воображение членов команды. Средства н методы раскадровки мокнут быть настолько разннообразны, насколько позволяет воображение членов команды и пользователей системы. Самые простые пассивные раскадровки можно создавать с помощью бумаги и карандаша или заметок на самоклеющихся листочках. Для построения более сложных пассивных раскадровок можно использовать администраторы представлений, такие как Роиегропн или Нытзгб Впйпем СгарЫсз. Интеракплвные раскадровки пассивного и активного типа создаются с помощью НурегСагд, Япре~СаЫ и раз. личных пакетов, которые позволяют быстро разрабатывать пользователыкие экраны и выходные отчеты.
Интераатнвные раскадровки можно создавать с помощью разнообразных специальных пакетов программного обеспечения для интерактивного прототипирования, таких как 11ап Впс1цп'з 1>это 1ь Для создания более сложных анимаций и имитаций можно испольэоватьтакие средства, как Масгошегйаз1лгессог и Сьпетацоп компанииЪЪЫпз. Так, например, в компании йЕ1.А один из членов команды умел неплохо делать зарисовки. На концептуальной стадии разработки проекта он просто набрасывал полдюжины (или около того) простых схематических картинок, демонстрирующих варианты типичного использования продукта или различные аспекты его интерфейса.
Это был быстрый и недорогой способ получить реакцию потенциальных пользователей. Кроме того, как мы увидим позднее, то, что раскадровка при этом напоминала комикс, позволяло избежать некоторых проблем, которые могут возникать при создании раскздровок. К сожалению, после того кзк этот человек оставил компанию, нам пришлось искать другие методы раскадровки. Теперь, когда мы в основном занимаемся 1УБ-приложениями, для решения наших за. дач оказалось возможным ограничиться Роиегрони или другими обычными настольнымн администраторами представлений, используемыми совместно с образцами экранных копий, созданных с помощью тех же средств, которые применяются при построении графических интерфейсов пользователя в приложении.
Следует заметить, что простое добавление анимационных возможностей к РожегРо1пг стало, пожалуй, самым грандиозным прорывом в технике раскадровки. С их появлением в программе способность выражать динамику и иптерактивность возросла на порядок. Советы по раскадровке Раскадровка является мощным методом быстрого получения обратной реакции поль. зователя с помощью недорогих средств. Поэтому раскадровки особенно эффективны в преодолении синдрома "да, но...". Они также помогают в разрешении синдрома "ненайденных руин" путем обеспечения быстрой реакции пользователя на то, что система, по-видимому, "не должна делать".
Но, как и для любого другого метода, возможны определенные сложности. Ниже приводятся некоторые рекомендации, о которых необходимо помнить при использовании на практике метода раскадровки. ° Не яхладывабям много средсжв в росхадраеху. Если она будет выглядеть как реальный рабочий продукт, клиенты будут опасаться вносить в нее изменения. Поэтому хо- Глава 12.
Раскадровка 145 рошо, если удается сделать раскадровку схематичной, даже грубой. (См. историю о раскадровке в конце данной главы.) ° Если эм ничего яе меклеэм, вм ничему яе научились Делай ге раскадровку такой, чтобы ее было легко изменять. Следует иметь возможность модифицировать раскадровку за считанные часы. ° Не дяшйгле Ряскафоеку ошигком хэроаий.
Если вы сделаете это, клиенты захотят "получить ее" (т.е. испольэовать как некий готовый продукт). (В одном проекте нам пришлось много лет поддерживать Ехе!/7В-продукт, который изначалыю бьи не бо. лее чем раскадровкой.) Делайте раскадровку схематичной; используйте средства и методы, которые не позволят превратить ее в реально используемый продукт. Это ос<т бенно важно для раскадровок, выполненных в форме кода. (Сеееэс Если приложение должно быть реализовано на языке ) ага, швпите раскадровку на ЪЪпа) Ваис.) ° Если возможно, делабэм Расхафюеку инте)лзнтпивной. Если клиент получит опыт использования продукта, это вызовет больше реакций и приведет к выявлению большего числа новых требований, чем может дать пассивная раскадровка.
Заключение В данной главе мы рассматривали простой и недорогой метод выявления требований. Раскадровка предназначена для быстрого выявления реакций пользователя типа "да, но..." с помощью недорогих средств. Мы можем с уверенностью сказать, что раскадровки очень полезны и всегда вносят нечто новое в понимание системы.
Поэтому мы советуем команде разработчиков следую~нее. ° Создавать раскадровку как можно раньше. ° Делать раскадровки чаще. ° Применять раскадровки во всех проектах, имеющих новое или новаторское содержание. При этом удастся на ранних агапах получить реакцию "да, по...", что, в свою очередь, поможет создать системы, которые лучше справляются со своей з.щачей по удовлетворению реальных потребностей пользователей, и сделать это быстрее и экономнее! История о раскадровке (Чтобы никого не обидеть, мы изменили некоторые факты о проекте в этой достаточно правдивой истории.) Эта история произошла во время разработки сложного электромеханического прибора для больничной аптеки.
Заказчиком был производитель Роггппе 1.000; наша компания занималась разработкой этой новой слоясной электро. механической оптической инфузионной системы. Проект зашел в тупик Однажды главкому руководителю проекта (будем называть его "автором") позвс» нил один из руководителей заказчика (Старший 7Р, "М-р Биг"), влиятельный человек, с которым мы никогда прежде пе имели удовольствия встречаться. М-р Биг: Автор, как продвигается наш любимый проект) Автор: Не очень хорошо. М-РБиг: Так я н зная.
Послушайте, не бывает нерешаемых проблем. Приезжайте со всей вашей командой на встречу. Как насчет средыу 146 Часть 2. Понимание потребностей пользователей Автор: (поспел~но отменяя все указания для членов команды на среду) Среда подходит. М-рБиш Отлично.
Приезжайте. Не беспокойтесь о расходах на поездку. Мы их возместим. Только покупайте билеты в один конец. Автор: (сдержанно) Благодарю. Увидимся в среду. В указанный день мы вошли в большой конференц-зал, где в дальнем конце уже сидели все представители команды заказчика. Видно было, что они находязся здесь уже некоторое время. (Возник вопрос: Почему команда почувствовала необ. ходимость собраться до начала встречи?) Автор, который не в первый раэ сталкивался с подобной ситуацией, прошел а другой конец комнаты и сел рядом с м-ром Битом (рассуждая, что и-ру Биту будет сложнее кричать на него, если он будет сидеть рядом', если же тот побьет Автора, то будет возможность выиграть судебный процесс и возместить потерянную прибыль от проекта!). После короткой дискуссии Автор заметил, что среди многих значительных проблем, с которыми столкнулся проект, проблема "недостатка единства в требованиях" вызывает задержку проекта и превышение расходов.
М-р Биг сказал: "Приведите мне пример". Автор привел отличный пример. Члены команды заказчика немедленно начали спорить между собой, деьюнстрируя, что это действительно являлось проблемой. Субподрядчик вздохнул с некоторым облегчением. М- р Биг с минуту посмотрел на команду и сказал: "Очень смешно. Приведите мне другой пример." Команда автора предъявила пять цветных изображений предла.
гаемой передней панели, каждое иэ которых было достаточно профессионально сделано, и заявила: "Мы представили все эти вариантзя дизайна несколько недель назад и до сих пор ие можем получить единого мнения относительно дизайна, мы уже пришли к выводу о необходимости взимания платы за простой". М-р Биг заявил: "Этого не может быть. Команда, выберите какой-нибудь вариант." Члены команды заказчика снова вступили в перепалку друг с другом. Весь день прошел подобным образом.
Согласия не было. Надежды практически не осталось. Утром на следующий день Автора попросил о встрече некий член команды проекта (" Член команды"). Член команды. который, помимо всего прочего, умел шить, достал кусок войлока, ножницы, цветные маркеры и сказал: "Я хочу использовать эти средства, чтобы помочь в органиэации той части встречи, которая касается интерфейса пользователя".
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
