Технологии программирования - Wiegers.Software R. Development Productivity Award Москва 2004 удк 004. 45 В41 Карл Разработка требований к программному с англ. М. дом Русская Редакция , 2004. ил. Isbn 5-7502-0240-2 Эта книга
 Скачать 37.95 Mb.
| Образовательный портал Как узнать результаты егэ Стихи про летний лагерь 3агадки для детей |
Полное содержание архива WinRAR ZIP archive.zip: Глава Особенности разработкик ПО где описана среда разработки, ограничения бюджета, руководство пользователя или требования для выпуска продукта и продвижения его в поддерживаемую среду. Все это относится к требованиям к екту, но не к поэтому они не будут рассмотрены в этой книге Разработка и управление требованиями Путаница, которая возникает, как только речь заходит о затрагивает даже то, что именно называть этим словом. Некоторые авторы называют целую область разработкой технических условий (requirements и Kotonya, 1998); другие упот- ребляют термин управление требованиями (requirements manage- ment) {Leffingwell и 2000). Я считаю полезным разделить об- ласть разработки технических условий на разработку требований quirements development) — подробнее об этом в части II этой книги — и управление требованиями (requirements management) — см. часть III как показано на рис. 1 -2. Область разработки технических условий Извлечение Анализ Документирование Проверка Рис. Компоненты области разработки технических условий Разработка требований Далее мы можем подразделить этот этап на извлечение (elicitation), анализ (analysis), и утверждение (val- idation) и Moore, 2001). В эти входят все включающие сбор, оценку и документирование требований для ПО или продуктов, в том числе: I идентификация классов пользователей для данного продукта; выяснение потребностей тех, кто представляет каждый класс поль- I. Требования к продукту: что, почему и кто 1 определение задач и целей а также которыми эти задачи связаны; I информации, полученной от пользователей, чтобы отделить задачи от функциональных и требований, бизнес - правил, предполагаемых решений и поступающих извне данных; распределение высокоуровневых требований по компонентам определенным в системной архитектуре; I установление относительной важности атрибутов качества; установление приоритетов реализации; I документирование собранной информации и построение моделей; 1 просмотр спецификации требований, который позволяет удостове- риться в том, что запросы пользователей всеми понимаются одина - и устранение возникших проблем до передачи документа Постепенность процесса — ключ к успеху разработки требований. Планируйте цикличность исследования требований, высокоуровневые требования и уточняйте их корректность у телей. Выполнение этих задач требует времени и может однако это важный аспект работы с неясно определенным новым ПО. Управление требованиями Этот этап определяется как «выработка и поддержание согласия с заказчиками по поводу требований к ПО» и др., 1995). Это соглашение воплощается в спецификации (в письменной форме) и моделях. Одобрение пользователей — только половина дела. Разработчики также должны принять - ванные требования и высказаться за создание этого продукта. К - виям по управлению требованиями относятся: определение основной версии требований (моментальный срез требований для конкретной версии продукта); I просмотр предлагаемых изменений требований и оценка сти воздействия каждого изменения до его принятия; I включение одобренных изменений требований в проект ленным способом; согласование плана проекта с требованиями; обсуждение новых обязательств, основанных на оцененном нии изменения требований; 1 отслеживание отдельных требований до их дизайна, исходного ко- да и вариантов тестирования; Глава Особенности разработки требований к ПО I отслеживание статуса требований и действий по изменению на протяжении всего проекта. На рис. 1 -3 показан другой способ разделения областей разработки требований и управления ими. В этой книге описано несколько дюжин специальных приемов для выполнения извлечения требований, их анализа, документации, проверки и управления, Сотрудники отдела | менеджеры Разработка требований требованиями Сотрудники отдела маркетинга, менеджеры Анализ, докумен- обсуждение версия ная версия Окружающая среда проекта Рис. 1 -3. Разделение областей разработки требований и управления ими Каждый проект имеет требования Frederick Brooks выразительно определил критическую роль требова- ний при разработке ПО в эссе (1987) «No Silver Bullet: Essence and Accidents of Software Строжайшее и единственное правило построения систем ПО - решить точно, что же строить. другая часть концептуальной работы не является такой трудной, как выяснение деталей технических требований, в том числе и взаимодействие с людьми, с механизмами и с иными системами ПО. Никакая часть работы так не портит результат, если она выполнена плохо. Ошибки никакого другого этапа ра- боты не исправляются так трудно. Часть I, Требования к продукту: что, почему и кто Каждое приложение или содержащая ПО система имеет телей, которые полагаются на нее, как на средство улучшения их жиз ни. Время, которое тратится на выяснение потребностей представляет собой высокоэффективную инвестицию в успех проекта. Если разработчики не записывают требования, с которыми заказчики уже согласились, как могут они удовлетворить этих заказчи ков? Даже требования к ПО, не предназначенного для использования, следует хорошо понять. Например, библиотеки ПО компоненты и инструменты, созданные для внутреннего разработчиками. Зачастую невозможно полностью определить требования до варительного В этом случае действуйте итеративно постепенно: разрабатывайте одну порцию требований за тельно дождитесь ответной реакции заказчика, прежде чем к следующему циклу. У вас не будет оправдания, если вы начнете пи- сать код до того, как просмотрите требования перед следующим гом. Итерации при кодировании стоят гораздо дороже, чем при ботке Люди иногда впустую тратят время, отведенное на написание тре- бований, но этот этап не самый сложный. Самое трудное — эти требования. Первоначально написание требований - собой процесс выяснения, разработки и расшифровки данных. понимание требований к продукту дает вам уверенность, что ваша манда работает теми проблемами, над которыми нужно, и приду- мает лучшее их решение. Требования позволят вам расставить при- оритеты в работе и оценить ресурсы, которые понадобятся. Не что собой представляют требования, вы не сможете определить мо- мент окончания проекта, установить, достигнуты ли цели, или выбрать компромиссное решение, когда придется сужать границы проекта. Никаких предположений в требованиях Я недавно имел дело с группой разработчиков, которая применяла доморощенные инструменты разработки ПО, в том числе и редактор исходного кода. К ни один из них не записал, что инструмент должен позволять пользователям печа- тать код, хотя пользователи без сомнения предполагали, что это будет именно так. Разработчикам приходилось вручную переписывать исходник, чтоб просмотреть код. Если вы не записываете даже подразумеваемые и предполагаемые не удивляйтесь, если продукт не будет ожиданиям пользователей. Перио- дически спрашивайте: «Что мы чтобы постараться извлечь на по- верхность эти спрятанные мысли. Если вы заметите какое-то предположение при Глава Особенности разработки требований к ПО 2-2437 обсуждении требований, запишите его и подтвердите его точность. Если вы зани- заменой системы, просмотрите системные характеристики, чтобы выяс- нить, действительно ли они необходимы при замещении, а не выносите поспешного решения - да нет. Когда плохие требования появляются у хороших людей ошибо к S 8 8 § _ гаш Разработка ' Работа с Рис. 1 -4. Относительная стоимость исправления ошибок в требованиях в зависимости от того, когда они обнаружены Основное следствие проблем с требованиями — переделка того, как вы думаете, уже готово. На это расходуется от 30 до 50% общего бюджета и Papaccio, а ошибки в требовани- ях стоят от 70 до 85% стоимости переделки 1997). Как по- казано на рис. гораздо дороже исправить дефекты, которые най- дены позднее в проекте, чем сразу после создания (Grady, 1999). Сле- довательно, предотвращение ошибок в требованиях и обнаружение их на ранних стадиях сильно уменьшает объем переделки. Вообразите, насколько изменится ваша жизнь, если вы сократите этот объем напо- ловину! Вы сможете построить ПО быстрее или сконструировать боль- ший и лучший продукт за о же время и даже иногда будете приходить домой. Часть I. Требования к продукту: что, почему и кто Дефекты в требованиях представляют собой угрозу успеху где успех означает выпуск продукта, который удовлетворяет ям пользователей в качестве и функциональности при соблюдении бюджета и графика проекта. В главе 23 рассказано, как управлять та- кими рисками, чтобы предотвратить крушение проекта. Некоторые общих рисков описаны далее в этой главе. Недостаточное вовлечение пользователей Заказчики зачастую не почему так важно тщательно брать требования и обеспечить их качество. Разработчики не всегда придают значение вовлечению пользователей в процесс, из-за того что среди них больше фанатов написания кода, а не любителей зиться с клиентами или же потому что они считают, что все уже знают потребностях пользователей. В любом случае трудно добраться людей, которые непосредственно будут иметь дело с продуктом, выразители мнения пользователей не всегда понимают, что тем нужно в реальности. Недостаточное вовлечение пользователей ведет к ошибок в требованиях на поздних стадиях проекта, а к задержке завершения проекта. Нет альтернативы разработчиков реальными пользователями на тяжении всего проекта главу 6). «Разрастание» требований пользователей Так как требования тщательно прорабатываются и их объем со нем увеличивается, проект часто выходит за установленные рамки как по срокам, так и по бюджету. принятые планы не все- гда основаны на реалистичном понимании размера и сложности тре- бований, ограничение же на модификацию только усиливает пробле- мы. Эти проблемы частично кроются в частых запросах пользователей на изменения, а в том, какими способами отвечают на них. Чтобы управлять границами требований, для начала уточните биз- нес-цели проекта, основы его образа, рамки, ограничения, успеха и ожидаемую пользу. Оцените, как предполагаемые характери- стики или изменения требований отразятся на связанной с ними структуре. Эффективный процесс модификации заставляет нее работать аналитиков, которые помогут всем заинтересованным лицам принять обдуманные бизнес-решения относительно того, изменения следует принять, и увязать их стоимость со временем, ре - сурсами или возможными компромиссами. Изменения зачастую тически важны для успеха, однако они всегда имеют цену. Особенности разработки требований к ПО По мере того как продукт модифицируется в процессе разработки, его архитектура может медленно разрушаться. «Заплатки» кода трудняют понимание и поддержку продукта. Добавление кода может стать причиной нарушения твердых и взаимосвязанных принципов зайна и разрыва связей 1993). Чтобы минимизировать возможность потери качества продукта в результате проблем такого рода, вначале как возможные изменения отразятся на архитектуре и дизайне, а уж затем реализуйте их непосредственно в коде. Двусмысленность требований Двусмысленность — страшилка любой спецификации требований (Lawrence 1996). Один из ее пользователь имеет воз- можность интерпретировать одно и то же положение по-разному. Другой — что у нескольких читателей требований возникает разное представление о продукте. В главе 10 указано множество слов и фраз, которые порождают двусмысленность, возлагая ответственность ин- терпретации на пользователя. Кроме того, двусмысленность зачастую проистекает из неточности и плохой детализации требований, в ре- зультате чего разработчикам приходится заполнять возникающие пробелы собственными силами. Двусмысленность ведет и к формированию различных ожиданий у заинтересованных лиц. Впоследствии некоторые из них «Что же это получилось?» Разработчики же впустую тратят время, за- нимаясь не теми проблемами. А тестеры готовятся к проверке не тех особенностей поведения системы. Один из способов обнаружить двусмысленности — пригласить раз- личных представителей пользователей для официальной экспертизы требований. (Подробнее об этом рассказано в главе 15.) Пусть они документ и выскажут свои замечания. Если они интерпре- тируют требования различными способами, но это имеет смысл для каждого из них, то неясность не проявится сейчас, а гораздо позже, когда исправлять ее будет весьма дорого. Другой способ вскрыть двусмысленность — написать вариант тестирования для требования и построить прототип. и Weinberg и другие «Золочение» продукта Под «золочением» понимают такие ситуации, когда разработчики до- бавляют функции, которых нет в спецификации, но им кажется, что это понравится пользователям. Зачастую же клиентам не нужны такие из- Часть I. Требования к продукту: что, почему и кто возможности, получается, что время, отведенное на реали- зацию тратится впустую. Прежде чем просто вставлять новые разработчики и аналитики должны представить свои творческие на суд заказчиков. Задача команды — четко соблюдать спецификации, а не действовать за спиной клиентов без одобрения. Пользователи иногда требуют функции или элементы которые выглядят отлично, но не представляют особой ценности продукта. Все, вы захотите добавить, стоит времени и поэто- му постарайтесь осознать ценность своевременного выпуска продук- та. Чтобы уменьшить «золочение», отслеживайте каждый бит функцио- нальности до его первоисточника, чтобы четко понимать, именно он включен в продукт. Применение вариантов использования для извлечения требований поможет сосредоточиться на выборе те>: элементов, которые помогут пользователям выполнять их Минимальная спецификация Иногда сотрудников отдела маркетинга или менеджеров искушение создать урезанный вариант спецификации, как, например набросок концепций продукта на салфетке. Они ожидают, что ботчики «нарастят мясо» на основе этих набросков, пока проект разви вается. Это годится для тесно сплоченной команды, которая ется небольшой системой, или когда выполняется или когда требования действительно гибкие 1996), Хотя в большинстве случаев это все-таки раздражает (которые могут действовать при некорректных предположениях и с инструкциями) и дезориентирует клиентов (которые получат тот продукт, который они воображали). Пропуск классов пользователей Большинство продуктов предназначены для нескольких групп пользо- вателей, которые могут применять различные наборы функций с ной частотой и имеют опыт работы с ПО самого широкого Если вы не определили важные классы пользователей для вашего дукта заранее, некоторые потребности клиентов не будут После идентификации всех классов удостоверьтесь, что каждый из них имеет голос главу 6). Глава Особенности разработки требований к ПО 1 !3 Небрежное планирование «Я кое-что придумал для нового продукта. Когда вы сможете это сде- лать?» Не отвечайте на подобный вопрос, пока больше не узнаете о проблеме. Неопределенные, недетализированные требования порож- дают слишком оптимистические оценки: они «выходят боком», когда возникает перерасход. Неподготовленная оценка звучит как обяза- тельство для слушателя. При плохо просчитанной смете проект боль- ше всего страдает из-за затрат на частые изменения требований, про- пущенных требований, недостаточного взаимодействия с пользова- телями, недетализированной спецификации требований и плохого анализа (Davis, 1995). Когда вы высказываете оценку, то указывайте либо качественные показатели (лучший вариант, наиболее худший вариант), либо количественные, но с учетом вашего мнения («Я на 90% уверен, что мы сделаем это за три Выгоды от высококачественного процесса разработки требований Те организации, которые применяют высококачественные процессы разработки требований получают массу преимуществ. Одно из них — уменьшение объема переделок в течение последней стадии разработ- ки и на протяжении всего длительного периода обслуживания та. Эффективность качественных требований не очевидна, и многие люди ошибочно считают, что время, которое тратится на обсуждение требований, просто отсрочивает выпуск продукта. При завершении проекта становится особо ясной ценность приемов повышения каче- ства на ранних стадиях (Wiegers, В удачных процессах создания требований к совместной работе над проектом привлекалось множество заинтересованных лиц, причем на протяжении всего проекта. Сбор требований позволяет команде раз- работчиков лучше понять пользователей или реалии что крити- чески важно для любого проекта. Гораздо дешевле понять все особен- ности до построения ПО, чем после передачи его в руки пользователей. Привлечение пользователей к созданию требований порождает восхищение продуктом и верность клиентов. Делая упор на задачи пользователей, а не на внешне привлекательные функции, команда из- бежит необходимости переписывать код, который даже не понадобит- ся. Вовлечение клиентов в процесс снижает вероятность появления ложных ожиданий, возникающих из-за различия того, в чем пользова- 20 Часть I. Требования к продукту: что, почему и кто тели нуждаются, и того, что разработчики выпускают. Подумайте о том, как со временем получать отзывы заказчиков. Причем лучше раньше, позже; может быть, в этом вам помогут прототипы, которые - лируют активность пользователей в этом вопросе. Для разработки тре - бований необходимо время, его все-таки нужно для правления массы проблем в бета-версии или после выпуска. Кроме того, есть и дополнительные выгоды. Ясное разделение бований на те, что относятся к ПО, оборудованию или подсистемам, взаимодействующим с людьми, позволяет применять системный ход к разработке продукта. Эффективные процессы контроля за нениями минимизируют неблагоприятные последствия от изменения требований. составленные документы облегчают тес - тирование продукта, что в свою очередь повышает шансы создать вь - продукт, который удовлетворит всех пользователей Никто не станет обещать конкретный возврат инвестиций в процесс улучшения требований. Вы можете мысленно проанализировать, что вы от этого получите. Сначала прикиньте общую сумму вложений. Она складывается из стоимости оценки применяемых сейчас приемов, работки новых процедур и документирования шаблонов, тренинга манды, покупки книг и инструментов и, возможно, привлечения сультантов со стороны. Наибольшая инвестиция — это время, которое ваша команда тратит на сбор, документирование, просмотр и - ние требованиями. Но теперь подумайте о возможных выгодах, ми вы будете наслаждаться, и о том, сколько времени и денег они сэкономят. Невозможно количественно оценить все преимущества, нако они реальны: меньше дефектов в требованиях; 1 меньше переделок; меньше ненужных функций; I ниже стоимость модификации; быстрее разработка; I меньше разобщенности; меньше расползания границ; i меньше беспорядка в проекте; 1 точнее оценки тестирования; 1 выше удовлетворение заказчиков и разработчиков.  перейти в каталог файлов | Образовательный портал Как узнать результаты егэ Стихи про летний лагерь 3агадки для детей |
