Технологии программирования - Wiegers.Software R. Development Productivity Award Москва 2004 удк 004. 45 В41 Карл Разработка требований к программному с англ. М. дом Русская Редакция , 2004. ил. Isbn 5-7502-0240-2 Эта книга
 Скачать 37.95 Mb.
| Образовательный портал Как узнать результаты егэ Стихи про летний лагерь 3агадки для детей |
Полное содержание архива WinRAR ZIP archive.zip: Глава 7. Как услышать голос клиентастратегии и способы выявления требований (например, сочетание опросов, семинаров, встреч с клиентами, интервью и других прие- мов с возможным использованием различных подходов для разных групп заинтересованных лиц); результаты требований (например, перечень вариантов использования продукта, подробная спецификация требований к программному обеспечению, анализ результатов опроса или цификация атрибутов качества и производительности); график и смету ресурсов (определите, кто из разработчиков и ентов будет участвовать в различных операциях по выявлению тре- бований; примерно оцените усилия и время на выявление требова- риски, связанные с выявлением требований (укажите факторы, ко- торые могут нарушить график работ по выявлению требований, оцените опасность каждого фактора и решите, как смягчить его или управлять им). Выявление требований Возможно, выявление требований — самый трудный, важный, подвер- женный ошибкам и требующий интенсивного общения этап разработ- ки ПО. Как вы уже знаете из главы 2, эта процедура может оказаться успешной только при условии сотрудничества клиентов и ков. Аналитик должен создать атмосферу, благоприятную для тща- тельного исследования обусловленного продукта. Чтобы облегчить общение, используйте лексику предметной области, а не те клиентов компьютерным жаргоном. Не полагайтесь на то, что все участники одинаково понимают важные термины предметной области, - создайте словарь. Однако объясните клиентам, что обсуждение возможной функциональности — это еще не обязательство включить ее в продукт. Этот этап обособлен от анализа приоритетов, осущест- вимости и налагаемых реальностью. Заинтересованным в проекте лицам необходимо расставить приоритеты в списке «голу- бых чтобы проект не стал рыхлым и бесполезным. Мастерство управления дискуссией по выявлению требований при- ходит с опытом, очень помогают в таком деле тренинги, где слушатели учатся брать интервью, общаться в группах, разрешать конфликтные ситуации и т.д. Как аналитику, вам придется «нырнуть» в поток требо- ваний клиента и, «опустившись поглубже», разобраться в его истинных потребностях. Просто задав несколько раз вопрос типа вы Часть II. Разработка требований к ПО сможете перейти от обсуждения уже существующего решения к лению проблемы. Вопросы, допускающие несколько вариантов та, помогут вам разобраться в бизнес-процессах и понять, как система повысит их эффективность. Поинтересуйтесь, какие задачи собираются выполнять пользователи и они будут работать с мой. Вообразите, что вы обучаетесь служебным обязанностям вателя или непосредственно выполняете их под его руководством. кие задачи вам придется решить? Какие вопросы у вас Другой подход — влезть в «шкуру» новичка, которого обучает пользователь. Вы задаете массу вопросов, а он управляет выбирая важную, с его/ее точки зрения, для обсуждения. Попробуйте метод исключений. Что мешает пользователю успешно выполнить задачу? Как система должна реагировать на ошибочные условия? Задавайте вопросы, начинающиеся со слов: «Л что еще могло «Что произойдет, «Вам когда-нибудь «Где вы «Почему вы делаете (или не де- и «А кто-нибудь Задокументируйте каждого требования, чтобы, если потребуется, понять их причину и проследить, на каких же потребностях клиентов основываются те иные направления разработки. Когда вы разрабатываете следующую версию системы, пользователей припомнить три вещи, которые раздражают их больше всего. Этот вопрос поможет вам почему же систему следует менять. При этом также становится ясно, чего же ждут пользо- ватели от новой системы. Как и при любой модификации, неудовле- творение настоящим дает отличную пищу для принятия нового. Попытайтесь вытащить на «свет все предположения клиен- тов и разрешить конфликты. Читайте между строк, чтобы определить те возможности или характеристики, которые клиенты полагают собой разумеющимися и даже не считают нужным обрисовать. Gause и Weinberg (1989) предлагают использовать бесконтекстные вопросы вопросы и вопросы, допускающие разные толкования, чтобы выявить информацию о биз- нес-проблемах и их возможных решениях. Реакция клиентов на вопросы, как «Какой уровень точности необходим в продукте?» или «Почему вы не согласны с ответом иногда более действен- ны, чем вопросы с ответами типа «да/нет» или В процессе сбора информации работающий творчески аналитик не только фиксирует слова клиента, но и подкидывает пользователям но- вые идеи и предлагает альтернативы. Иногда пользователи не пред- ставляют, какие возможности готовы предоставить разработчики; они Глава 7. Как услышать голос клиента 117 страшно обрадуются, если вы предложите функциональность, которая сделает систему особенно удобной. В тех случаях, когда пользователи не способны ясно свои потребности, аналитику стоит пона- блюдать за их работой, чтобы самому разобраться, какие операции следует автоматизировать. Отлично, когда аналитикам удается выйти за рамки, ограничивающие мышление людей слишком тесно связан- ных с конкретной предметной областью. Ищите удобные случаи вторно использовать функциональность, которая уже реализована в другой системе, Интервью с отдельными потенциальными пользователями или с группами — традиционный источник информации при сборе требова- ний, касающихся как коммерческих продуктов, так и информационных систем. [О проведении интервью с пользователями см. Beyer и Holtzb- (1998), Wood и (1995), а также и Harbison Во- влечение пользователей в процесс сбора информации — это способ получить в том числе и финансовую, проекта. Попытайтесь понять, из чего следуют конкретные требования пользователей. По- этапно рассмотрите работу пользователей и постарайтесь понять ее логику. Блок-схемы и деревья решений позволяют отобразить логиче- ские пути принятия решений. Убедитесь, что все понимают, почему система должна выполнять конкретные функции. Иногда предложен- ные требования отражают устаревшие или неэффективные бизнес- процессы, которые не следует встраивать в новую систему, После каждого интервью документируйте элементы, обсуждавшие- ся группой, и попросите интервьюируемых просмотреть список и вне- сти исправления. Просмотр на ранних для успеш- ного сбора поскольку только те люди, которые эти требо- вания могут судить, правильно ли они зафиксированы. В дальнейшем также не отказывайтесь от обсуждений — это позволит разрешить все противоречия и заполнить пробелы. Польза семинаров Аналитики требований часто проводят совместные семинары, упро- щающие сбор информации о требованиях. Это позволяет весьма эф- фективно наладить связи между пользователями и разработчиками и 1995). Основная задача ответственного за мероприятие сотрудника — создать условия для успешного выполнения задачи; именно он планирует семинар, выбирает участников и следит, чтобы обсуждение проводилось продуктивно. Если вы собираетесь приме- Часть II. Разработка требований к ПО нять новые технологии сбора требований, ответственным за первый семинар следует назначить стороннего сотрудника — не из вашей манды. В этом случае аналитик сможет полностью сосредоточиться обсуждении. Пригласите также секретаря, чтобы он фиксировал идеи, возникающие в ходе обсуждения. Согласно одному из какого-либо приятия — искусство управления людьми в ходе этого которое позволяет достичь согласованных решений в сотрудничества, высокопроизводительного труда и сти в результатах своей работы» (Sibbet, 1994). О семинарах, щающих сбор требований, подробно рассказано в труде Ellen ener «Requirements by (Выявление требований помощью сотрудничества). Gottesdiener описывает спектр приемов 1 средств для облегчения семинаров. Вот некоторые из них. Определите основные правила. Участники должны договориться об основных правилах проведения семинаров (Gottesdiener, 2002). На- пример, таких: i своевременно начинать и заканчивать семинар; I не опаздывать после перерывов; не проводить несколько обсуждений одновременно; следить, чтобы каждый принимал участие в работе; комментировать и критиковать решение, а не личность. Придерживайтесь границ проекта. Чтобы удостовериться, что предлагаемые пользовательские требования не выходят за текущие границы проекта, используйте документ об образе и границах Следите, чтоб на каждом семинаре уровень обобщения соответст- вовал выбранным целям. Периодически участники могут углубляться в обсуждения несущественных деталей. На это уходит масса времени, которое на начальном этапе работы следует потратить на пользовательских требований — время деталей наступит позже. Зада- ча организатора — по мере необходимости возвращать участников к теме Ловушка Избегайте преждевременного углубления в детали. Фиксируя мель- чайшие подробности того, что люди уже понимают, вы не снизите риски, остаю- из-за размытости требований, Пользователи легко переходят к обсуждению того, где в отчете или диалоговом окне следует разместить элементы, даже еще до того, как разработчики согласятся с поставленными задачами. Если вы включите Глава 7. Как услышать голос клиента данные детали в требования, то в некоторой степени ограничите про- цесс разработки. К разработке пользовательского интерфейса следует приступать хотя предварительные наброски интерфейса по- лезны на любом этапе при иллюстрации способов ции требований. Проверка осуществимости на ранних стадиях, щая определенной разработки, значительно снижает риски. Фиксируйте темы для дальнейшего обсуждения. На семинаре всплывает масса случайных, но важных сведений: атрибуты качества, бизнес-правила, идеи по разработке пользовательского интерфейса, ограничения и т.п. Запишите их на плакатах простейшим способом, — так вы не потеряете их и продемонстрируете уважение участнику, высказавшему их, Не отвлекайтесь на обсуждение деталей, не относящихся к теме дискуссии, если только они не окажутся важны- ми, например бизнес-правилом, которое ограничивает варианты ис- пользования. Ограничивайте некоторые дискуссии по времени. Организатор семинара имеет право ограничить время обсуждения каждой темы, скажем, первоначально — 30 минут на каждый вариант использова- ния. Возможно, некоторые дискуссии придется завершить позднее, но жесткие временные рамки помогают не тратить времени больше, чем запланировано, на первые обсуждения темы, в результате чего может не хватить времени для обсуждения остальных тем, Не увеличивайте размер команды и тщательно отбирайте участ- ников. Небольшие группы работают намного быстрее. Семинары, чис- ло активных участников которых превышает пять или шесть человек, могут забуксовать, вылиться в отвлеченные разговоры и даже ссоры. Попробуйте одновременного проводить несколько семинаров — это исследовать требования различных классов пользователей, В обсуждении должны участвовать сторонник продукта и другие пред- ставители пользователей, возможно, эксперт в данной предметной об- ласти, аналитик требований и разработчик. Допуском к участию в се- минарах по сбору информации являются знания, опыт и право прини- мать решения. Ловушка Не допускайте в процессе сбора информации обсуждения посторон- них тем, например подробностей дизайна. Вовлекайте в обсуждение каждого. Иногда участники самоустраня- ются от обсуждения, например, расстроившись из-за того, что не представляют себе ценность системы. Возможно, их идеи не воспри- Часть II. Разработка требований к ПО серьезно, поскольку участникам их концепции кажутся неинтересными или группа не хочет отвлекаться от текущей сии. Возможно, аутсайдер не уверен в себе и уступил право голоса бо лее активным сотрудникам или главному аналитику. Организатору необходимо следить за языком телодвижений, чтобы браться в причинах замкнутости того или иного участника, попытаться снова вовлечь его в работу. Ведь интуитивное ние каждого может оказаться очень ценным. У семи нянек... Работа семинаров по сбору информации о требованиях большим количеством уча- стников может продвигаться слишком медленно. Так, моя коллега Дебби, занимав- шаяся организацией где разбирались варианты использования Web-про- дукта, была расстроена именно этим. Двенадцать участников длинно обсуждали детали и не могли договориться. Однако темпы значительно выросли, когда Дебби сократила группу до шести человек, в число которых вошли аналитик, сис- темный архитектор, разработчик и дизайнер. Объем обсуждаемой информации стал но темпы работы более чем компенсировали эту потерю. Участникам семи- нара следует по его окончании обменяться информацией с коллегами, не пригла- шенными на дискуссию, и обсудить высказанные идеи на следующей встрече. Не следует ожидать, что ваши клиенты представят краткий, полный и хорошо орга- низованный список своих потребностей. Аналитикам придется классифицировать мириады бит полученных данных о требованиях, чтобы их удалось задокументиро- вать и использовать соответствующим образом. На рис. 7-1 показано девять таких категорий требований. Некоторая информация не попадает ни в одну из этих категорий, в том не относящиеся к разработке ПО, например необходи- мость обучения пользователей работе с новой системой; I ограничения проекта, например затраты или ограничения, налагае- мые графиком (в отличие от ограничений, касающихся дизайна или реализации); R предположения; 1 требования, касающиеся данных, которые зачастую связаны с оп- ределенной функциональностью системы (вы сохраняете данные на компьютере только для того, чтобы позднее извлечь их); дополнительная информация хронологического или о характера, а также относящаяся к управлению контекстом. Как услышать голос клиента Идеи, Варианты использования касающиеся решений или сценарии Определения Бизнес-правила данных Ограничения Функциональные требования Требования к интерфейсу Атрибуты качества Рис. Классификация требований клиента Далее в этом разделе я привожу некоторые типичные для дискус- сий фразы, по которым вам будет легче выполнить классификацию данных. Вся информация, описывающая финансовые, рыночные или другие отношения коммерческого характера, которые клиенты или разработчики собираются получить от использования продукта, относится к Обращайте внимание в разговоре на такие высказывания о преимуществах, которые покупа- тели или пользователи ПО хотят получить: 1 «Увеличить рыночную долю I «Сэкономить Y$ в год за счет сокращения использования электро- энергии, которая сейчас расходуется неэффективно»; i «Сэкономить Z$ за счет расходов на поддержание ус- таревшей Варианты использования или сценарии. Основные утверждения пользователей о преследуемых ими целях или задачах бизнеса мерческих задачах) называются вариантами использования; единст- венный задокументированный вариант называется сценарием. Рабо- тайте с пользователями, чтобы свести сценарии в более общие вари- анты использования. удается выявить варианты использования, попросив клиентов описать их рабочий процесс. Другой способ — вы- яснить у заказчиков, какие цели они ставят перед собой, усаживаясь 122 Часть II. Разработка требований к ПО за Сотрудник, который скажет: «Мне нужно сделать то-то и то- то», вероятнее всего опишет конкретный вариант использования, пример: «Мне нужно напечатать почтовую этикетку для пакета»; 1 нужно управлять очередью образцов химических отобранных для анализа»; I «Мне необходимо контроллер насоса». Бизнес-правила. Если клиент заявляет, что только классы пользователей могут выполнять определенные действия при определенных он, описывает бизнес-правило. В случае с Chemical Tracking System такое бизнес-правило может чать следующим образом: «Химик может заказать вещество из опасных химикатов уровня 1 только при условии, что в настоящее вре мя действует его допуск на работу с опасными соединениями». Вы жете сформулировать некие функциональные требования к ПО, чтобы определить конкретное правило, например запись в БД о допуске со- трудника должна быть доступной Chemical Tracking System. уже ворилось, бизнес-правила и бизнес-требования — не одно и то же. Вот несколько фраз, по которым вы можете догадаться, что пользова- тель описывает именно бизнес-правила: 1 «Должны совпадать с таким-то постановлением или корпоративной политикой»; I «Должны соответствовать некоему стандарту»; I «Если выполняется такое-то условие, то происходит то-то и то-то»; «Расчеты производятся по следующей формуле». Дополнительная информация Развернутые примеры бизнес-правил в главе 9. Функциональные требования. Функциональные требования вают ожидаемое поведение системы при определенных условиях и действия, которые система позволит выполнять пользователям. циональные требования проистекают из системных требований, зовательских требований, бизнес-правил и других источников, со- ставляющих основу спецификации требований к программному обес- печению. Ниже перечислены примеры функциональных которые вы можете услышать от пользователей: 1 «Если давление превышает 40,0 фунтов на квадратный дюйм, дол- жен загореться предупредительный световой сигнал»; Как услышать голос клиента «У пользователя должна быть возможность сортировать список проекта в прямом и обратном алфавитном порядке»; 1 «Когда кто-либо представляет на рассмотрение новую идею, систе- ма отправляет сообщение по электронной почте Idea Coordinator». Эти высказывания демонстрируют, как пользователи обычно пред- ставляют функциональные требования, однако их нельзя записать не- посредственно в спецификацию требований к программному чению. В первом случае следует заменить «должен загореться» на «за- горится», чтобы стало ясно, что включение предупредительного светового сигнала крайне важно. Второй пример показывает ния пользователя, а не требования к системе. Требование к системе — предоставить пользователю возможности выполнить сортировку. Дополнительная информация Советы тем, кто хочет написать хорошие функциональные требования - в главе 10. Атрибуты Утверждения, насколько хорошо система соот- ветствует определенному режиму работы или позволяет пользовате- лям выполнять конкретные действия, называются атрибутами качест- ва. Обращайте внимание на слова, которыми пользователи описывают желаемые характеристики системы: быстрая, легкая, интуитивно по- нятная, удобная для пользователя, устойчивая к сбоям, надежная и эффективная. Вам придется поработать с чтобы по- нять, что именно они имеют в виду под этими неясными и субъектив- ными терминами, и зафиксировать четкие, поддающиеся проверке ат- рибуты качества, как описано в главе Требования к внешнему интерфейсу. Требования в этом классе описывают связь вашей системы с остальным миром. В специфика- цию требований к программному обеспечению необходимо включить разделы, касающиеся взаимодействия с пользователями, оборудова- нием и другими системами ПО. Вот примеры фраз, указывающих, что клиент описывает внешние требования к интерфейсу: I «Должны распознавать сигналы от определенного устройства»; 1 «Должна отправлять сообщение такой-то системе»; 1 быть в состоянии читать (или записывать) файлы в опре- деленном формате»; такой-то элемент оборудования»; I интерфейс должен соответствовать определен- ному 124 Часть II. Разработка требований к ПО Ограничения. Ограничения, касающиеся дизайна и реализации, циально ограничивают доступные разработчику. Для устройств со встроенным ПО часто необходимо учитывать ограничения, такие, как размер, вес и сквозные соединения в плате, Записывайте разумное обоснование для каждого ограничения, чтобы все участники проекта знали его источник и понимали его обоснован ность. Действительно ли ограничением является требование тить в определенном пространстве? Или это желание, пример, просто получить портативный компьютер с минимальным сом? Введение излишних ограничений препятствует выработке лучшего решения. Из-за ограничений также не всегда удается использовать стандартные компоненты, доступные в продаже. Требование нять определенную технологию также не всегда достижимо — тую технология устарела или недоступна в результате прогресса. нако некоторые ограничения могут оказаться полезными при достиже- нии целей, связанных с атрибутами качества. Например, удается улучшить переносимость ПО путем использования только команд языка программирования и запрета на использование рений, присущих только определенным производителям. Вот какие ог- раничения может выдвинуть клиент: I «Размер файлов, представленных в электронном виде, не должен превышать 10 Мб»; I «В браузере для всех безопасных транзакций следует кодировку»; i «В БД необходимо применять механизм периода выполнения Fra- А это примеры других фраз, указывающих на то, что клиент описы- вает дизайна или реализации: «Должна быть написана на определенном языке вания»; 1 «Не может требовать более такого-то объема памяти»; 1 «Должна функционировать согласованно (или быть совместима) с такой-то системой»; I «Должна использовать определенный элемент управления пользо- вательского интерфейса». Как и в случае с функциональными требованиями, задача аналитика шире, чем просто запись высказываний пользователя в требований к программному ПО. Неудачные слова, такие, как ванно и последовательно, необходимо а в ограничения следует  перейти в каталог файлов | Образовательный портал Как узнать результаты егэ Стихи про летний лагерь 3агадки для детей |
