Технологии программирования - 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. Показать все связанные файлыГлава 16. Проблемы при разработке специальных требований 321 Преобладание новых и стремительно развивающихся проектов при- вело к созданию различных методик быстрой разработки. Их цель — быстро передать полезную функциональность в руки пользователям 1988; Beck, 2000; Cockburn, 2002). В них применяется упрощен- ный подход к разработке требований и неформальный подход к управ- лению требованиями. Требования описываются в терминах характери- стик продукта или в форме историй похожими на обычные варианты использования, описанные главе 8. Вместо под- робной документации к требованиям предпочтение отдается постоян- ному взаимодействию с представителем клиента, который, находясь рядом, имеет возможность разъяснять детали и отвечать на вопросы. В философии быстрой разработки изменения ПО рассматриваются как нечто неизбежное и желательное. Система корректируется под воздействием обратной связи с клиентом и при изменении бизнес- нужд, Чтобы справиться с этими изменениям, системы строятся с не- большим приращением, причем подразумевается, что следующая разработанная часть повлияет на уже созданную часть системы, улуч- шит первоначальные функции и добавит новые. Этот способ хорошо работает при высокой степени неясности в требованиях для информа- ционных систем и Интернет-проектов. Однако он меньше подходит для работы с приложениями, требования к которым ясны, и для разра- ботки встроенных систем, Совершенно что процесс разработки должен быть осно- ван на ясном понимании что пользователи хотят делать с помо- щью системы. Требования к быстро меняющимся проектам слишком нестабильны, чтобы оправдать массу усилий, затраченную на предва- рительную разработку требований. Однако по мнению Jeff «Трудность для разработчиков ПО заключается в при по- вторяющихся циклах разработки появляется искушение изменить тре- бования и расширить объем работ». Если этими циклами управлять должным образом, то они помогут вам сделать ПО, соответствующее текущим бизнес-нуждам, хотя и ценой переработки заблаговременнс завершенного дизайна, кода и тестов. Иногда лица, заинтересованные в проекте, утверждают, что роль требований неизвестна и непостижима, тогда как они просто горят от побыстрее заняться написанием кода, при этом они не учитывают возможность всеобъемлющего перекодирования. Не под- давайтесь искушению использовать Интернета» как оправ- дание экономии на разработке требований. Если вы и в самом деле работаете над совершенно новым проектом, вам, возможно, следует 322 Часть II. Разработка требований к ПО воспользоваться приемами работы с требованиями, описанными в следующих разделах. Бессистемная спецификация пользовательских требований Неформально задокументированные требования годятся для создаваемых небольшими, географически не разделенными ми. Методика быстрой разработки, именуемая экстремальным про- граммированием (Extreme Programming), рекомендует документиро- вать требования в форме простых рассказов для пользователей, напи- санных на учетных карточках (Beck, 2000; Jeffries, Anderson и Обратите внимание, что даже при этом подходе необходимо, чтобы клиенты представляли себе требования достаточ- но чтобы описать поведение системы в форме рассказов. Ловушка Не следует ожидать, что для успеха проекта хватит и телепатической передачи ненаписанных требований. Требования для каждого проекта должны быть представлены в формах, которые позволят ознакомить с ними всех заинтересован- ных лиц, обновлять их и управлять ими на протяжении разработки проекта. Кроме того, необходимо, чтобы кто-то отвечал за такое документирование и обновление. Присутствие клиента Частые беседы участников проекта и клиентов считаются наиболее эффективным способом разрешения многих проблем, связанных с требованиями. Написанная документация, несмотря на детализацию, не полностью заменяет это постоянное общение. Основу экстремаль- ного программирования составляет постоянное и непосредственное присутствие клиента на этих обсуждениях. Однако, как говорилось в главе 6, большинство проектов предназначено для нескольких классов пользователей, а также для других заинтересованных лиц. Клиент в поле зрения Однажды я писал программу ученого-исследователя, рабочее место которого бы- ло расположено примерно в 10 футах от моего стола. Джон мог моментально отве- чать на мои вопросы, высказывать свое мнение по поводу экранов интерфейса и по- яснять неформально изложенные требования. Однажды Джон перебрался в новый офис, расположенный на том же этаже того же здания. Я что моя произво- дительность моментально упала из-за задержки при получении ответной информа- ции от Джона. Я стал тратить больше времени на устранение проблем, поскольку Глава 16. Проблемы при разработке специальных требований 323 иногда двигался в неправильном направлении, так как не получал корректи- рующих указаний. При ничто не заменит тесное взаимодействие с работающим за соседним столом клиентом. Однако будьте осторожны - при слиш- ком частых прерываниях людям трудно опять сосредоточиться на работе, Может по- требоваться 15 минут на повторное погружение в крайне сосредото- ченное состояние, которое называется потоком и Lister, Сам по себе находящийся рядом клиент не гарантирует желаемого результата. Мой коллега Крис, налаживая работу команды разработ- чиков, привлек двух сторонников продукта. Выводы его оказались та- кими: «В то время как близость оказала благотворное воздействие на команду разработчиков, результаты работы со сторонниками продукта были смешанными. Один из них был в центре и все же умудрял- ся избегать нас. Человек, выполняющий обязанности сторонника про- дукта в данный момент, прекрасно общается с разработчиками и дей- ствительно убыстряет разработку ПО». Ловушка Не следует ожидать, что одному человеку удастся разрешить все воз- никающие проблемы, связанные с требованиями. Когда роль сторонника продукта выполняют несколько представителей пользователей, это более Периодическая расстановка приоритетов на ранних стадиях Поэтапная разработка успешна, если клиенты и разработчики сотруд- ничают при выборе порядка реализации функций. Задача команды раз- работчиков — регулярно передавать полезную функциональность и ка- чественные улучшения в руки пользователей, поэтому им необходимо знать, над какими возможностями они будут работать на каждом этапе. Простое управление изменениями Процессы разработки ПО должны быть настолько насколько возможно для того, чтобы работа была сделана отлично, но не проще. Пассивный контроль не годится для новых проектов, которые требуют частых изменений. Сделайте процесс внесения изменений «обтекае- мым», чтобы минимальное количество людей максимально быстро принимали решения об изменении требований. Это не означает, что каждый разработчик должен просто вносить любые изменения, кото- рые нравятся ему или клиентам: это приведет к хаосу, а не убыстрит разработку. 324 Часть II. Разработка требований к ПО теперь? i Если вы обслуживаете продукт, применяете готовые обращаетесь к сторонним разработчикам или проект «с изучите приемы форму- лирования требований, описанные в главе 3, чтобы выбрать них тот, который сделает ваш проект ценным и успешным. Если у вас возникали связанные с требованиями проблемы, когда вы прежде за- нимались разработкой проектов таких типов, как те, что описаны в этой главе, проанализируйте их - это поможет диагностировать проблемы и определить ос- новные причины. Если вы воспользуетесь приемами из главы 3 или способами, описанными здесь, то удастся ли вам предотвратить проблем в следующем проекте подобного типа? Глава 16. Проблемы при разработке специальных требований 325 От разработки требований - к следующим этапам Работа над Chemical Tracking System продвигалась просто за- мечательно. Но спонсор проекта и сторонник продукта от персонала, работающего на складе, Роксана, сомневались, стоит ли тратить много времени на определение требований, Тем не менее они присоединились к разработчикам и другим сторонникам продукта, которые проводили однодневный тре- нинг, посвященный работе над требованиями к ПО. На этом тренинге подчеркивалась важность достижения общего пони- мания всеми заинтересованными в проекте лицами бизнес- целей и нужд пользователей. Кроме всех участников оз- накомили с терминологией, касающейся требований, концеп- циями и приемами, которые будут использоваться в работе. А также призвали применять лучшие приемы для работы с тре- бованиями на практике, По мере развития проекта Жерар получил отличные отзывы от представителей пользователей о том, насколько хорошо прошла разработка требований. Он даже организовал ланч для аналитиков и апологетов продукта, чтобы отпраздновать создание основной версии требований для первого выпуска системы. На ланче Жерар поблагодарил тех, кто занимался сбором информации для создания требований, за их вклад и коллективную работу. А затем сказал: Теперь, когда с ваниями все в порядке, я с нетерпением ожидаю скорого ления готового кода». еще не готовы писать код продукта, — ответил менеджео проекта, планируем выпускать систему поэтапно, поэто- му ее необходимо разрабатывать, сообразуясь с будущими дополнениями. С помощью прототипов мы получили четкое 326 Часть II. требований к ПО представление о технической стороне и смогли понять теристики интерфейса, который предпочитают пользователи, Если на этой стадии мы потратим еще немного времени на ди зайн, то сможем избежать проблем в течение следующих скольких месяцев, когда придет время добавлять функцио нальность к системе». расстроился. Все выглядело так, как будто разработчи- ки сознательно медлили, вместо того чтобы прямо приступить к работе. Однако не делал ли он преждевременных выводов? Опытные менеджеры проекта и разработчики понимают ценность пре- образования требований к ПО в надежный дизайн и рациональные планы. Они необходимы в тех случаях, когда следующая версия ставляет 1 или 100% всего конечного продукта. В этой главе мы рас- смотрим, как преодолеть которая отделяет разработку тре- бований от успешного выпуска продукта: несколько вариантов влия- ния требований на планы проекта, дизайн, код и тестирование, как показано на рис. • требования для оценки масштаба проекта " основывайтесь на размере Планы проекта • Обновляйте планы при требований Учитывайте приоритеты требований при выполнении Попросите просмотреть требования Учитывайте атрибуты качества при дизайне архитектуры Распределяйте требования по компонентам Отследите требования до дизайна и кода Начинайте разработку тестирования на ранних стадиях Используйте требования тестировании системы Попросите пользователей разработать проверочные тесты Отследите требования до тестов Рис. 17-1. Влияние требований на планирование проекта, дизайн, написание кода и тестирование От требований -- к планам проекта Поскольку именно требования определяют предполагаемый исход (результат) проекта, планы, сметы и графики следует разрабатывать на основе требований. Однако необходимо помнить, что наиболее важный результат проекта — это та система, которая соответствует а не обязательно та, в которой реализованы все пер- воначально требования согласно первоначальному плану проекта. Глава От разработки требований - к следующим этапам 327 В требованиях и планах указана первоначальная оценка затрат на про- определенная членами команды. Однако границы проекты могут выйти за первоначальные рамки, планы оказаться невыпол- нимыми. Кроме бизнес-потребности, бизнес-правила и ограни- чения проекта могут Успех проекта если вы не будете обновлять ваши планы в соответствии с изменяющимися целями и обстоятельствами. Менеджеров проекта часто интересует, сколько времени и усилий понадобится для разработки требований. Для небольших проектов, которыми обычно занималась наша команда, этот этап обычно стоил от до всех затрат (Wiegers, однако показатель зависит от объема и сложности проекта. Несмотря на опасения, что работа над требованиями замедлит создание продукта, доказано, что понятные требования ускоряют процесс разработки, что и показывают следую- щие примеры: изучение 15 проектов в сфере телекоммуникаций и банковской сферы показало, что в наиболее успешных проектах примерно 28% ресурсов тратилось на разработку требований и на сбор информации по требованиям, 10% — на мо- делирование, а 7% на проверку и утверждение. На разработку тре- бований для среднего проекта всех ресурсов и 38,6% времени; в проектах NASA, в которых затрачивалось более всех ресурсов на разработку требований, затраты и отклонения от графика оказа- лись существенно ниже, чем в проектах, где на требования затрачи- валось меньше ресурсов (Hooks 2001); исследования, проведенные в Европе, показали, что команды, раз- рабатывающие продукты более быстро, посвятили больше времени и усилий требованиям, чем более медленные команды (табл. 17-1) (Blackburn, Wassenhove, 1996). Не все ресурсы на разработку требований должны расходоваться в начале проекта, как в модели «водопада» или последовательной моде- ли жизненного цикла. В итеративных моделях определенное время на требования будет тратиться в каждом повторном цикле разработки. Цель таких проектов — реализовывать функциональность каждые не- сколько недель, поэтому требованиями придется заниматься часто, но мало. На рис. показано, как в разных моделях жизненного цикла в период разработки продукта усилия на требования. 328 Часть II. Разработка требований к ПО Таблица Затраты на требования ускоряют разработку Усилия, затраченные на требования затраченное на требования Более быстрые проекты 14% Более медленные проекты 7% & 1 Модель Последовательная модель Рис. Распределение затрат на требования по времени различается для проектов, разрабатываемых на основе различных моделей жизненного цикла Ловушка Старайтесь избегать паралича аналитического процесса. Если в са- начале проекта масса усилий тратится на разработку совершенных и полных требований - и то зачастую мало полезной функциональности уда- ется реализовать в срок. С другой стороны, не следует избегать разработки требо- ваний вообще только из-за боязни паралича аналитического процесса. Требования и расчеты Первый шаг при оценке проекта — объем продукта ПО. делают исходя из текстовых требований, моделей анализа, или элементов интерфейса. Хотя не существует идеального мерила размера ПО, чаще всего используются I количество отдельно тестируемых требований (Wilson, перейти в каталог файлов | Образовательный портал Как узнать результаты егэ Стихи про летний лагерь 3агадки для детей |
