Принципы работы с требованиями к ПО. Леффингуэлл (2002) (1186169), страница 30
Текст из файла (страница 30)
Автор: Не будьте наивным; это не сработает. Это будет выглядеть глупо и непрофессионально. Член команды: Я понимаю, но какова была эффективность вчераг Автор, будучи человеком воспитанным, не стал произносить первое слово, кото- рое пришло ему в голову. Вторым словом было: "Ладно", На следующий день атмосфера в зале была совершенно иной.
Команда заказчиков опять явилась заранее, но в этот раз опа была менее возбужденной. (Выводы; теперь они знали, что они так же беспомощны, как и мы. Они планировали уничтожить пас, по оказалось, что мы все обречены.) В начале встречи Член команды прикрепил на стену кусок войлока размером 1х2м, вызвав оживление (но ие безучастность) со стороны закаэчика. Глава 12. Раскадровка 147 Член команды поместил болыпне войлочные выключатели н кнопки различных терапевтических режимов на переднюю панель и сказал: "Как будет работать этот ва?эиэнт?". Заказчик посмотрел иа стену и сказал: "А почему бы вам не переместить аварий- ный останов назад?".
Член команды сказал: "Почему бы вам не сделать это," и дал ножницы заказчику. Заказчик взял ножницы, а член команды отошел в дальний конец зала. Заказчик продолжил сеанс интерактивного дизайна с помощью войлока и ножниц. Через час он посмотрел иа стену и сказал: "Достаточно неплохо; пусть будет так". Какова мораль этой истории? Опишем ее с помощью вопроса и ответа. Вопрос: Почему обычный войлок сработал, в то время как профессиональные визуализации — нет? Ответ: Существует две причины.
° Интераативность: что может заказчик сделать с пятью рисунками, в каждом из которых его устраивает только некоторая часть? ° Практичность: совсем несложно раскроить болыпой кусок войлока. Заказчик, эксперт в предметной области, но не обязательно в дизайне, самостоятельно создал приемлемое решение своей проблемы. Мы забрали с собой этот войлок и повесили его иа стену в качестве постоянного напоминания о том, чему мы научились. Этот интерфейс пользователя, хотя, возможно, и не оптимальный, никогда уже болыяе не менялся и оказался вполне приемлемым для тех целей, для которых был предназначен.
Но, увы, данный проект не стал грандиозным успехом его создателей, хотя со временем поступил на рынок и добился признания. Как мы отмечали ранее, рассматриваемая проблема была только одной иэ проблем данного проекта. И Урок 1, Понимание потребностей пользователя — сложная и тонкая проблема. Используйте гибкие и тонкие средства — раскадровки и войлок, если зто нужно, — для ее решения. ш Уроий.
Технология является сложной. Двзжды подумайте. прежде чем приступить к разработке медицинских приборов. Глава 13 Применение прецедентов Основные положения И Прецеденты, как и раскадровки, описывают элементы кшо, шло и как поведения системы. ° Прецеденты описывают юаимодействия между системой и пользователем, уделяя основное внимание тому, что система "делает" для пользовазеля. ° Модель прецедентов описывает функциональное поведение систелпя в целом. В главе 12 описывался процесс создания раскадровок и обсуждалось, как их можно испольэовать, чтобы показать элементы юле, чжон как поведения системы и пользователя. Еще один метод описания поведения состоит в использовании прецедентов.
Данный метод кратко рассматривался в главах 2 и 5, где он применялся при моделировании бизнес-процесса. В данной главе мы продолжим изучение метода прецедентов и опишем, как его можно испольэовать для понимания поведения системы, которую ьзы разрабатываем, в отличие от понимания бизнес-процесса, внутри которого будет оперировать система. Другими словами, мы будем применять прецеденты для выявления требований, чтобы понять, как должно вести себя приложение, которое мы собираемся разработать для решения проблемы пользователей.
Прецеденты настолько важны лля фиксации и спецификации системных требований, что мы продолжим их дальнейшую разработку в части 5, "Уточнение определения систелзы", и части 6, "Построение правильной системы". Метод прецедентов является частью методологии объектно. ориентированного программирования 1ОЬ)есг-Ог)епгеб боймаге Епя)пееппя), как описано в книге ИуесьОпюгзеН зоЯште Еплзгмгппя, А 11зе Сазе 1)поюз А)з)ггоас)з 1Джейкобсон ЦасоЬзоп) и др., 1992).
Это метод анализа и проектирования сложных систем, представляющий собой "основанный на прецедентах" способ описания поведения системы с точки зрения того, как различные пользователи взаимодействуют с ней для достижения своих целей. Такой ориентированный на пользователя подход предоставляет возможность исследовать различные варианты поведения систелзы при раннем привлечении пользователя. Как уже отмечалось ранее, прецеденты служат также 1)МЬ-представлениеьз требований к системе.
Прецеденты можно успешно испольэовать на протяжении всего жизненного цикла программного обеспечения. Помимо фиксации требований к системе, разработанные в процессе выявления требований прецеденты можно применять при анализе и проектировании; они также мозут играть значительную роль в процессе тестирования. В последующих главах метод прецедентов будет рассматриваться более подробно, а в на.
стоящий момент необходимо только понять, как можно испольэовать прецеденты для фиксации исходных требований к системе. 150 Часть 2. Понимание потребностей пользователей Начнем с более формального определения, чем предлагалось ранее. ПРеиа)ект описывает погледовательткть дтстоий, оьтолкломых системой с цепью пРедоспюоить палтпмй Результат конкРетному актоРу. Другими словами, прецеденты описывают взаимодействие между пользователем и сисче. мой, уделяя основное внимание тому, что система "делает" для пользователя.
Кроме того, пт скольку действия описываются последовательно, легко "проследить дейу„„„а стане" и понять, что делает система. В 1)М1. прецедент изображается освежением овальной пиктограммой, содержащей имя данного прецедента. В процессе определения требований прецеденты служат для выявлепйЮдзт ния и фиксации системных требований. Каждый прецедент описывает серию собьпий, в которых некий акгор, скажем "Дженни-Модель", взаимодействует, например, с системой планирования работы с клиентами некоего модельного агентства„чтобы по. лучить нужный ему результат, направление на следующий показ моделей. Построение модели прецедентов Модель пРеиедекпюо системы состоит иэ всех актаров системы и различных прецедентов, посредством которых акторы взаимодействуют с системой, тем самым описывая многообразие ее функционального поведения.
Она также показывает связи между прецедентами, что углубляет наше понимание системы. Первый втг моделирования прецедентов состоит в создании систел~ной диаграммы, описывающей границы системы и определяющей ее акторы. Это позволяет параллельно осуществить этапы 3 и 4 (из описанных в главе 4 пяти этапов анализа проблемы), в которых требуется выявить заинтересованных лиц системы и определить ее границы. Например, для систел~ы управления складом (Джейкобсон ЦасоЬзоп) и др., 1992) граница системы может выглядеть так, как на рис.
13.1. Как видно из рисунка, система используется многими пользователями, каждый из кс» торых взаимодействует с системой для достижения определенной операционной цели, Дальнейший анализ системы показывает, что для поддержки потребностей пользователей необходимы определенные нити системного поведения. Эти нити и есть прецеденты, или специфические последовательности, с помощью которых пользователи взаимодействуют с системой для достижения определенных целей.
Рассмотрим примеры прецедентов данной системы. ° Производимое вручную распределение иэделий иа складе. ° Включение новой единицы хранения. ° Проверка изделий, находящихся на складе. Применение прецедентов к выявлению требований Идею прецедентов можно доходчиво описать будущим пользователям системы. Пре. цеденты пишутся на естественном языке пользователя.
Их легко описывать и докумен- Глава 13. Применение прецедентов 151 тировать. Это обеспечивает простой структурировышый формат для совместной работы команды-разработчика и пользователя пад описанием поведения существующей системы или определением поведения новой системы. Конечно же, каждый пользователь будет обращать внимание на те возможности системы, которые необходимы для выполнения именно его работы. Если поведение полностью исследуется всеми потенциальными пользователями, команде удастся значительно приблизиться к цели полного понимания желаемого поведения системы. После окончания данного процесса останется не так уж много "ксоткрытыкруин" янкциокалькыкеозыожностей. Заведующий ор го ит Рабочий склада Водигвль гвузоаика Ркс.
13Л. Днесрелска складской системы кукованием актеров Кроме того, применяя метод прецедентов для непосредственного исследования интерфейсов пользователя, можно получить ранние отклики иа этот важный и изменчивый аспект системной спецификации и проекта. Однако необходимо помнить, что пользователи системы представляют только один, хотя и важный, класс заинтересованиьгх лиц, и нам могут понадобиться другие методы выявления для получения требований иных участников, таких как заказчики, не являющиеся пользователями, руководители, субподрядчики и т.д.
Кроме того, прецеденты не очень подходят для определения нефункциональных аспектов системных требований, таких как требования практичности, надежности, производительности и т.п. При решении этих задач мы полагаемся на другие методы. После того как выявлены все прецеденты, акторы и объекты системы, следующий шаг состоит в уточнении деталей функционального поведения камского прецедента. Спецификации прецедентов состоят из текстовых и графических описаний каждого прецедента, написанных с позиции пользователя. 152 Часть 2. Понимание потребностей пользователей Спецификацию прецедента можно рассматривать как контейнер, описывающий по.
следовательности связанных событий, которые, в свою очередь, могут подразумевать появление в будущем других требований. Так, спецификация прецедента может содер жать такой пункт "Специалист по обслуживанию вводит свою фамилию (максимум 1б символов), имя и т.д". Поскольку прецеденты описывают взаимодействие пользователь-система, параллельно с их разработкой стоит определить, хотя бы концептуально, экраны, дисплеи и пе.