Технологии программирования - Wiegers.Software R. Development Productivity Award Москва 2004 удк 004. 45 В41 Карл Разработка требований к программному с англ. М. дом Русская Редакция , 2004. ил. Isbn 5-7502-0240-2 Эта книга
 Скачать 37.95 Mb.
| Образовательный портал Как узнать результаты егэ Стихи про летний лагерь 3агадки для детей |
Полное содержание архива WinRAR ZIP archive.zip:  С этим файлом связано 6 файл(ов). Среди них: task2.txt, unit4.png, task1.txt, Mikhneva_Anastasia_1951.pkt, WinRAR_ZIP_archive.zip, Wiegers_Software_Requirements.pdf, Metodicheskie_ukazania_praktika.docx. Показать все связанные файлыГлава Прототипы как средство уменьшения риска 263 Насколько логичной и полной вам кажется навигация? I Не оказалось ли выполнение каких-либо задач слишком сложным? Удостоверьтесь, что пользователи оценивали прототип с соответст- вующих точек зрения. Привлекайте как опытных пользователей, так и новичков. Показывая прототип тем, кто его будет оценивать, подчерк- ните, что в нем воплощена лишь часть нужных функций, остальные бу- дут реализованы в конечной системе. Ловушка Остерегайтесь пользователей, которые вводят реальные данные в оцениваемый прототип, потому что он им кажется реальной системой. Они будут недовольны, если по окончании работы с прототипом введенные ими данные будут потеряны. Вы узнаете больше, наблюдая за работой пользователей с прототи- чем просто опрашивая их. Формальное тестирование легкости и простоты использования эффективно, но простое наблюдение за пользователями в процессе также может многое сказать. Смотрите, к каким клавишам инстинктивно тянутся пальцы пользователя. Отме- чайте места, прототип конфликтует с другими приложениями, ко- торыми часто пользуются клиенты, или где последующие действия пользователя не очевидны. Отмечайте нахмуренные брови, свиде- тельствующие, что пользователь озадачен и не знает, что делать даль- ше, как добраться до нужной точки или открыть другую часть приложе- ния, чтобы просмотреть еще что-нибудь. Просите ваших помощников вслух выражать их мнение во время ра- боты с прототипом, чтобы вы могли понимать ход их мышления и отме- тить требования, которые прототип обрабатывает плохо. Создайте дру- желюбную атмосферу, в которой пользователи будут свободно высказы- вать свои идеи и замечания. Избегайте показывать им «правильный» путь реализации тех или иных функций в прототипе. Записывайте все, что узнаете в процессе оценки прототипа. Гори- зонтальный прототип позволит вам уточнить спецификацию требова- ний к ПО. Если на основе оценки прототипа были приняты какие-либо решения о дизайне интерфейса пользователя или выбраны конкрет- ные методы взаимодействия, запишите эти выводы и то, как вы к ним пришли. Иначе вам придется снова и снова возвращаться к одному и тому же — пустая трата времени. После вертикального прототипиро- вания задокументируйте процесс и результаты оценки, в том числе ре- шения, которые вы приняли об исследованных технических процессах. Ищите любые несоответствия между спецификацией требований к ПО и прототипом. 264 Часть II. Разработка требований к ПО Риски прототипирования Несмотря на то, что прототипирование уменьшает риск неудачи екта по разработке ПО, оно обладает собственными рисками. больший из них заключается в том, что кто-либо из заинтересованных в проекте лиц, увидев действующий прототип, решит, что ный продукт почти готов. да вы, похоже, уже все сделали! — с эн- тузиазмом говорит тот, кого вы попросили оценить глядит отлично. Может, вы быстро доделаете его и отдадите мне?» Если коротко, то: НЕТ! Одноразовый прототип ни в коем случае не предназначен для работы, как бы он ни был похож на готовый продукт Это всего лишь модель, образец, эксперимент. Если нет жестких мерческих обстоятельств, заставляющих немедленно застолбить сто на рынке (в этом случае руководство понимает и принимает ходимость высоких затрат на сопротивляйтесь всем кто настаивает на поставке одноразового прототипа в качестве гото- вого продукта. Такой шаг в действительности лишь отдалит сроки за- вершения продукта, потому что и структура, и код одноразового тотипа намеренно создавались без учета качества или надежности. Ловушка Остерегайтесь тех заинтересованных в проекте лиц, которые что прототип - это просто ранняя версия окончательного продукта. Управление ожиданиями - одна из ключевых составляющих успеха Каждый, кто увидит прототип, должен понимать его назначение и границы применения. Не позволяйте связанным с преждевременным выпуском продукта, отвратить всем, что вы не его как продукт. способов кон- тролировать этот ме прототипы. Ни одному из кто оценивает прототип, и голову не придет, что ухе почти готов. Еще способ — вы- брать инструменты прототипирования, отличающиеся от тех, что меняются для разработки окончательного продукта. Это поможет про- тивостоять тем, кто просит «быстро закончить» и выпустить Оставив внешний вид прототипа неотделанным и незаконченным, вь также уменьшите этот риск. Опасайтесь когда пользователей начинает мучить вопрос как интерфейс пользователя будет выглядеть и действовать. Работая с прототипами, внешне похожими на окончательный пользователи легко забывают, что на стадии уточнения требований Глава 13. Прототипы как средство уменьшения риска 265 должны в основном думать, что же они хотят видеть в системе. Огра- ничьте прототип только теми демонстрациями, функциями и ностями навигации, которые помогут вам устранить сти в требованиях. Третий риск состоит том, что пользователи начнут делать выводы о производительности конечного продукта по производительности тотипа. Вы не будете проводить оценку горизонтального прототипа в рабочей среде продукта. Возможно, для его создания вы использовали менее эффективные средства, например интерпретируемые сцена- а не компилируемый код. В вертикальном прототипе не всегда применяются отлаженные алгоритмы или уровни защиты, что скажется на конечной производительности. Если пользователи увидят, что про- тотип мгновенно реагирует на моделируемый запрос к базе данных, используя жестко закодированные результаты запроса, они могут ждать такой же поразительной производительности от продукта, вклю- чающего огромную распределенную базу данных. Подумайте о реали- зации в прототипе временных задержек, чтобы модель ожидаемого по- ведения окончательного продукта выглядела более реалистичной (а прототип — менее готовым для реализации). Наконец, опасайтесь действий по прототипированию, требующих таких усилий, что команда разработчиков выбьется из графика и будет вынуждена выпустить прототип в качестве готового продукта или торо- пливо и бессистемно доделывать продукт. Относитесь к прототипу, как к эксперименту. Вы проверяете, что требования достаточно определе- ны, и что ключевые аспекты взаимодействия человека и компьютера, а также все архитектурные вопросы так что можно переходить к проектированию и конструированию. Возможностей прототипа долж- но быть ровно сколько, сколько необходимо для проверки гипотез, от- ветов на вопросы и уточнения вашего понимания требований. Факторы успеха прототипирования Прототипирование ПО предлагает мощный набор методов, которые позволят сократить сроки удовлетворить клиентов и соз- дать продукты высокого качества. Чтобы сделать прототипирование эффективной частью процесса составления требований, прислушай- тесь к следующим рекомендациям: I включите задачи прототипирования в план вашего проекта. Со- ставьте график распределения затрат времени и средств на разра- ботку, оценку и модификацию прототипов; 266 Часть II. Разработка требований к ПО сформулируйте цель каждого прототипа до начала его создания; планируйте создание нескольких прототипов. В большинстве случа- ев вам не удастся создать что нужно, с первой попытки чем, собственно, и состоит весь смысл прототипирования!}; одноразовые прототипы создавайте так быстро и дешево, как воз- можно. Вкладывайте минимум усилий в подготовку прототипов, ко- торые помогут отвечать на вопросы или разрешать неясности в тре- бованиях. Не доводите до совершенства одноразовые не встраивайте в одноразовый прототип подробную проверку вход- ных данных, методы безопасного программирования, процедур об- работок ошибок или документации кода; не элементы, которые уже понимаете, кроме случа- ев исследования альтернатив дизайна; используйте правдоподобные данные в экранных формах и сооб- щениях прототипа. Пользователи будут отвлекаться и не воспринять прототип как модель, описывающую внешний вид и по- ведение реальной системы; не ожидайте, что прототип полностью заменит спецификацию тре- бований к ПО. Большая часть скрытой функциональности лишь под- разумевается в прототипе и должна быть задокументировано в спе- цификации требований к ПО, чтобы ее удалось реализовать полно, точно и прозрачно. Видимая часть приложения — это пресловутая вершина айсберга. Изображения экранов не дают деталей ления полей данных, критериев проверки, взаимосвязей между по- лями (таких, как элементы управления пользовательского интер- фейса, появляющихся, только если пользователь совершает опре- деленные действия с другими элементами управления), исключений, бизнес-правил и др. Глава 13. Прототипы как средство уменьшения риска 267 Что теперь? I Выделите часть вашего проекта, например из вариантов использования, отражающий путаницу в требованиях. Набросайте часть возможного интерфейса пользователя, который представляет ваше понимание требований и того, как они должны быть воплощены, - бумажный прототип. Попросите нескольких пользо- вателей выполнить на вашем прототипе сценарий использования. Выявите мес- та, где первоначальные требования были неполными или неверными. Модифи- цируйте соответствующим образом и проведите повторный анализ, чтобы что недостатки устранены. Кратко перескажите содержание этой главы тем, кто будет оценивать ваш прото- тип, чтобы помочь им понять логику и настроиться на реали- стичные ожидания результатов. 268 Часть II. Разработка требований к ПО Назначение приоритетов требований После того как большинство требований к Tracking System было задокументировано, менеджер проекта Дэйв аналитик требований Лори встретились с двумя продуктов. Тим представлял химиков, а Роксана выступала от лица работников склада химикатов. «Как вы знаете, — начал Дэйв, — продуктов нули массу к Chemical Tracking System. К нию, мы не можем включить всю запрашиваемую вами циональность в первый выпуск. Поскольку авторы большинст- ва требований — химики и работники склада, я хотел бы обсудить с вами расстановку приоритетов в требованиях». Тим был озадачен. «Зачем вам назначать приоритеты? требования важны, иначе бы мы не дали их вам». Дэйв объяснил: «Я знаю, что они все важны, но мы не можем реализовать их все и при этом создать высококачественный продукт в заданные сроки. Мы хотим приложить все усилия, чтобы все самые необходимые требования вошли в первый вы - пуск, который должен появиться в конце следующего Мы просим вас помочь нам отделить требования, которые не- обходимо выполнить от тех, которые могут знаю, что отчеты, которые составляет отдел охраны труда техники безопасности, должны быть готовы к концу квартала или у компании будут неприятности, — заметила Роксана. - Мы можем использовать нашу нынешнюю систему учета несколько месяцев, если придется. Но распечатка и сканиро- вание штрих-кодов нужны обязательно, это важнее, чем воз- можность поиска в каталогах поставщиков». 269 Тим запротестовал: «Я обещал химикам функцию поиска по каталогу в качестве примера того, как эта система будет номить им время. Поиск по каталогу необходимо реализовать с самого начала». Лори, аналитик, сказала: "При обсуждении с химиками вари- антов использования мне показалось, что некоторые из них будут применяться очень часто, а другие — лишь время от мени и только одним-двумя людьми. Не могли бы мы взглянуть на ваш полный список вариантов использования и решить, ка- кие из них не нужны вам немедленно? Также, я хотела бы от- срочить реализацию некоторых декоративных функций, ука- занных в приоритетных вариантах использования, если это Тим и Роксана не особо взволновались от того, что придется подождать с реализацией некоторых функций системы. Тем не менее они поняли, что ожидать чудес неразумно. Если продукт не может содержать все требования в версии 1.0, то для всех будет если удастся согласовать первоочередные тре- бования. Для каждого продукта, на разработку которого выделены ограничен- ные ресурсы, необходимо определить относительные приоритеты воз- можностей. Расстановка приоритетов помогает менеджеру проекта разрешать конфликты, планировать выпуски и принимать мые компромиссы. В этой главе рассказано о важности определения приоритетов требований, предлагается простая схема классификации приоритетов и описан процесс точного анализа расстановки приорите- тов, основанный на ценности, затратах и риске, Зачем определять приоритеты требований Когда ожидания клиентов высоки, а сроки поджимают, вам что- бы в продукте были реализованы самые ценные функции как можно раньше. Приоритеты — это способ разрешения борьбы между конку- рирующими требованиями за ограниченные ресурсы. Определение относительного приоритета каждой возможности позволяет вам так планировать разработку, чтобы обеспечивать наибольшую ценность при наименьших затратах. Определение приоритетов наиболее тично для работы в очень строгих временных рамках или при примене - нии инкрементальной модели с жесткими, фиксированными сроками 270 Часть II. Разработка требований к ПО выпуска каждой версии продукта. При экстремальном программиро- вании клиенты выбирают, какие рассказы пользователей (user stories) они желают видеть в каждом двух- или трехнедельном выпуске, а работчики оценивают, сколько из этих рассказов они могут вместить каждый выпуск. Менеджер проекта должен сбалансировать желаемый объем та и ограничения, определяемые сроком, бюджетом, людскими сами и качеством. Один из способов достижения этого — убрать отложить до более поздней версии) требования с низким приорите- том, когда принимаются новые, более важные требования или изменя- ются другие условия проекта. Если клиенты не классифицируют свои требования по важности и срочности, менеджерам проектов прихо- дится делать это своими силами. Неудивительно, что клиентам не гда нравится результат; поэтому они должны указывать, какие требо- вания необходимы с самого начала, а какие могут подождать. Опреде- ляйте приоритеты на ранних стадиях проекта, когда больше шансов успешный результат, и периодически возвращайтесь к ним. Достаточно сложно заставить даже одного клиента решить, какие из его требований приоритетнее. Согласовать мнения нескольких клиен- тов с различными ожиданиями еще труднее. Люди по природе склон- ны отстаивать свои интересы и не жаждут жертвовать собственными нуждами ради чужой выгоды. Тем не менее участие в определении приоритетов требований — одна из обязанностей клиента в отношени- ях «клиент — разработчик», как уже говорилось в главе 2. Обсуждение приоритетов помогает не только определить последовательность реализации требований, но и прояснять ожидания клиентов. И клиенты, и разработчики должны внести вклад в определение приоритетов требований. Клиентам больше всего нужны функции, наиболее ценные для бизнеса или удобства работы. Однако, когда разработчики обрисуют трудоемкость, технический риск или компромиссы, связанные с каждым клиенты могут пере- думать и прийти к выводу, что это требование не так важно, как они считали изначально. Разработчики же иногда решают на ранних стади- ях реализовать некоторые функции с низким приоритетом из-за их влияния на архитектуру системы, в которые люди играют с приоритетами Естественная реакция пользователей на просьбу определить при- оритеты обычно такая: «Мне нужны все эти функции. Уж как-нибудь перейти в каталог файлов | Образовательный портал Как узнать результаты егэ Стихи про летний лагерь 3агадки для детей |
