Принципы работы с требованиями к ПО. Леффингуэлл (2002) (1186169), страница 32
Текст из файла (страница 32)
Мы бы не хотели выступать в роли "пациента" электрохнрургии, "оператора ядерного реактора в ночную смену" или "пилота Боинга 747". В данной ситуации можно применить другие методы, которые позволят кам получить представление об ощущениях пользователя, без потери "крови". Сценарный просмотр Сценарный просмотр — это исполнение роли на бумаге. Прн скеяориом п~юсмож)эе каждый участник следует сценарию, который задает конкретную роль в "пьесе".
Просмотр будет демонстрировать любые неточности в понимании ролей, недостаток информации, доступной актеру нли подсистеме, или недостаток конкретного описания поведения, необходимого актерам для успешного выполнения нх роли. Р- Например, мы однажды создавали сценарный просмотр, который показывал, как студенты и преподаватели будут взаимодействовать с прибором, автоматически оценивающим тесты. Мы использовали прототип прибора и попросили членов команды н представителей закаэчика разыграть роли студентов и преподавателей. Прослютр состоял из множества сцен, таких как "студенты оценивают свои собственные тесты" и "преподаватель оценивает болыной пакет тестов во время занятий". В данной ситуации сценарный просмотр оказался весьма полезным; команда ощутила атмосферу занятий н получила некие новые знания.
Кроме того, это было забавно! Одним из преимуществ сценарного просмотра является то, что сценарий можно лю. днфицировать и проигрывать снова столько раз, сколько необходимо, пока актеры не сочтуг его правильным. Сценарий можно также повторно использовать для обучения новых членов команды. Его можно модифицировать и проигрывать вновь, когда необходимо изменить поведение системы. В определенном смысле данный сценарий становит. ся "живой" раскадровкой для проекта.
СКС-карточки (С1абб-Кевропб1Ь11йу-Со11аЬота11оп, класс-обязанность-взаимодействие) Один из методов обыгрывания ролей часто применяется в объектноориентированном анализе. В данном случае каждому участнику выдается набор индексных карточек, описываю. щнх класс (объект); обязанности (поведение); а также взаимодействия (с какими из моделнр)емых сущностей взаимодействует объект). Этн взаимодействия могут просто представлять сущности проблемной области (такне, как полъэователи, нажатые кнопки, лампы н подъемники) или объекты, существующие в области решения (такне, как подсветка выключателя в холле, окно многодокументного интерфейса или кабина лифта). Когда актер-инициатор инициирует определенное поведение, все участники следуют поведению, заданному на их карточках, Если процесс прерывается из-эа недостатка ин- 158 Часть 8.
Понимание потребностей пользователей формации или если одной сущности необходимо переговорить с другой, а взаимодейсг вне не определено, то карточки людифицируются, и роли разыгрываются снова. Например, в нашем рабочем примере при разработке системы НОЕШЬ команде нужно понять взаимодействия между тремя подсистемами, чтобы определить, как в системе осуществляется кооперация для достижения общей цели и какие производные требования при этом создаются.
Одним из способов сделать это может быть ролевая игра с ис. пользованием СКС-карточек. Некий член команды будет играть роль подсистемы или актора, и команда будет просматривать прецедент или сценарий. Ниже предлагается обра. зец проигрывания одного из возможных прецедентов. Джон ("Управление Мой домовладелец только что нажал кнопку, включением", пульт) управляющую набором ламп.
Он все еще удерживает кнопку в нажатом состоянии. Я послал Бобу сообщение, как только кнопка была нажата, и собираюсь посылать ему сообщения каждую секунду, пока кнопка нажата. Боб ("Центральный блок Когда я получил первое сообщение, то изменил состояние управления") выхода с ямка на ехл.
Когда я получил второе сообщение, стало очевидно, что домовладелец хочет изменить яркость освещения, поэтому при получении каждого сообщения я собираюсь изменять яркость па 10%. Между прочим, Джон, не забывай говорить мне, какая кнопка нажата. Я аппаратно запрограчмирован на изменяемый накал. Я изменяю яркость света при нашем разговоре. Майк (лампа) Замечание. При выявлении потребностей пользователей посредством СКС-карточек основное внимание уделяется внешнему поведению.
Однако данный метод можно также использовать для проектирования объектно. ориентированных систем про. граммного обеспечения. При этом внимание концентрируется на понимании внут. реннего функционирования программного обеспечения, а не па взаимодействии с внешней средой. Но даже в этом случае данный метод часто приводит к обнаружению неправильных или невыявленных требований к системе.
Интересно отметить, что игроки неизбежно обнаруживают узкие места и недостатки в сценарии, и в результате их исправления, как правило, совершенствуется понимание системьь Заключение Обыгрывание ролей является замечательным методом, хотя он используется не очень часто. Почему? Причин много. Во.первых, существует фактор дискомфорта. Не очень приятно портить простой заказ на покупку, когда за вами наблюдает заказчик или клерк, вводящий заказы. Во-вторых, имеется фактор смущения; столкнувшись с необходимостью общаться с реальными людьми вместо клавиатуры, мы оказываемся не в своей тарелке; в конце концов, мы посещали занятия по теории компиляторов, когда нюни ровесники участвовалп в драмкружках! Однако иет сомнений, стоит сделать небольшое усилие, и обыгрывание ролей станет для вас одним из наиболее полезных и недорогих методов, призванных помочь в выявлении требований.
Глава 15 Создание прототипов -'основные положения ' ° ',:.Проттозтпгировэние особенно эффективно ,'~~-":".да, но;;". и,"иеоткрытые руины". для преодоления синдромов,,' ~ФИ Прототип программных требований является частичной.реализацией: ь~~',-'„'.;:программной системы н помогает разработчикам, пользователям и заказ- ', (Й:"',",',чс'ияамлущне понять требования к системе. ~г% Сяездуегсоэдавать прототип "неясных" требований, т.е. тех, которые котя,' (з ~"" М известны,' но плохо определены и малопонятны. Виды прототипов Существует много способов разбиения прототипов па категории, Например, Дэвис (1)ачба, 199э,а) в своей работе вьгделял следующие прототипы: отбрасываемые, эволюционирующие и операционные; вертикальные и горизонтальные: пользовательские интерфейсы и элгор~п мические; и т.д. Каким должен быть прототип в каждом конкретном случае, зависит от того, какую проблему вы пьггаетесь решить путем построения прототипа Например, если риск проекта связан преимущественно с применением технологического подхода — просто это никогда прежде пе делалось таким способом и вы пе уверены, сможет ли применяемая технология обеспечить нужную производительность или пропускную способность — можно создать архитектурный прототип, который главным образом демонстрирует осуществимость используемой технологии.
Архитектурный прототип может быть ожфасмваемым или зэолюякокиРующим. "Отбрасываемый"" означает, что его задача состоит только в определении осуществимости; можно использовать всевозможные сокращения, альтернативные технологии, имитации для ее достижения. По окончании прототип просто отбрасывается, сохраняется только полученное в результате зна- Программные прототипы, как ранние воплощения программной системы, демонстрируют часть функциональных возможностей новой системы.
Принимая во внимание то, что мы уже обсудили, можно предположить, что прототипы л~ожно с успехом приме нять для выявления потребностей пользователей. Пользователи могут трогать, ощущать прототип системы и взаимодействовать с ним, что не может обеспечить пи один другой метод. Прототипирование исключительно эффективно в преодолении как синдрома "да, но..." ("Это не совсем то, что я думал" ), так и синдрома "неоткрытых руин" (" Теперь, п<г сле того как я ее увидел, мне бы хотелось добавить еще одно требование"). 160 Часть 2.
Поннманне потребностей пользователей нне. "Эволюцноннрузощнй" означает, что прототип реализуется в той же архитектуре, которую вы намерены использовать в конечной версии системы, н можно строить рабочую версию системы, развивая данный прототип. Если же основной риск в проекте представляет ннтерфейс пользователя, можно разработать прототип требований с помощью любых технологий, позволяющих создать прототип пользовательского интерфейса как можно быстрее. На рнс. 15.1 представлено дерево решений, которое можно использовать прн выборе вида прототипа, наиболее подходящего для вашего проекта. Гарнаанталььна вр ал ьа Рнс. 15.1.
Дерево рениной для выбора вида ирототинаг веротл веотвь- иратотииы требованийг никспяя — а~хи тентурные нроитотины Прототипы требований Для выявления требований мы сосредоточим наше вннлтапне на видах прототипов, расположенных на верхней ветви данного дерева. Для начала рассмотрим опредсленне. Прототип требований к ирогра.нлтному обетечетгию — зто частичная реализация вислым ы тгуюгра.асиного обестте тсттттш, созданная с целью тымочь разрабоогчикалт, нолыовате иш и клиентам лучам понлть требования к систхеме.
Для выявления требований зачастую можно использовать прототип в виде "отбрасываемого горизонтального интерфейса пользователя". "Горттзонтальный" озна- Глава 15. Создание прототипов 161 чает, что мы будем стараться создать широкий спектр функциональных возможностей системы; в противоположность этому "вертикальный" прототип создает довольно мало требований, но делает это качественно. "Интерфейс пользователя" означает, что мы будем создавать в основном интерфейс системы с ее пользователями, а не заниматься реализацией логики и алгоритмов, лежащих внутри программы, или созданием интерфейсов с другими устройствами или системами.
В качестве средства выявления требований, прототип выполняет свою роль несколькими способами. ° Созданный разработчиком прототип может использоватьсв для пол> ~ения под- тверждения заказчика, что разработчик правильно понимает требования. ° Созданный разработчиком прототип может быть своего рода катализатором, за- ставляющим заказчика подумать о дополнительных требованиях. ° Созданный заказчиком прототип может помочь донести требования до разработ- чика.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
