WWW.DISSERS.RU

БЕСПЛАТНАЯ ЭЛЕКТРОННАЯ БИБЛИОТЕКА

   Добро пожаловать!

Pages:     | 1 |   ...   | 4 | 5 || 7 | 8 |   ...   | 9 |

«Разработка требований к программному обеспечению Практические приемы сбора требований и управления ими при разработке программного продукта Карл И. Вигерс Дважды ...»

-- [ Страница 6 ] --

Сотрудник, размещающий заказ на химикат, указывает в запросе желаемый хими кат, вводя его название или номер идентификатора химиката или импортируя его структуру из инструмента для рисования. Система удовлетворяет запрос, предлагая новый или бывший в употреблении контейнер с химикатом со склада химикатов ли бо позволяя создать запрос для заказа химиката у стороннего продавца.

Дополнительная информация Этот вариант использования продукта показан на рис. 8-6, Функциональное требование. Здесь показана некоторая функцио нальность, связанная с этим случаем использования продукта.

1. Если на складе есть контейнеры с химикатами, на которые поступил запрос, система отобразит список доступных контейнеров, 2. Пользователь либо выберет один из перечисленных контейнерОЕ или попросит разместить запрос на заказ нового контейнера у про давца.

Карта диалогов. На рис. 15-7 показана часть карты диалогов для ва рианта использования «Запрос химиката», которые имеют отношение к этой функции. Прямоугольники на этой карте диалогов представляют изображения пользовательского интерфейса, а стрелки показывают возможные пути перехода от одного изображения к другому.

Подробнее о картах диалогов рассказано Дополнительная информация в главе 11.

Глава 15. Утверждение требований ! 1- А» чГ DB отмена— — f Выберите химикат для запроса введите идентификатор введите идентификатор химиката;

химиката нет химиката;

химикат на складе есть на складе DB DB50 заказать новый контейнер Список поставщиков Список контейнеров химикатов на складе химикатоа продавец контейнер выбран выбран Рис. 15-7. Фрагмент карты диалогов для варианта использования «Запрос химиката» Контрольный пример. Поскольку для этого варианта использования существует несколько возможных путей выполнения, вы можете при думать несколько вариантов тестирования для обработки нормально го направления, альтернативных направлений и исключений. Ниже по казан вариант тестирования, когда пользователю отображаются кон тейнеры, доступные на складе. Этот вариант тестирования разработан на основе описания варианта использования этой задачи пользовате ля и карты диалогов с рис. 15-7.

В диалоговом окне DB40 введите действительный идентификатор химиката;

на складе имеются два контейнера с этим химикатом. Откроется диалоговое окно DB50, в котором показаны эти два контейнера. Выберите второй контейнер. DB закроется, и контейнер 2 будет добавлен в конец списка текущих запросов на хими каты в диалоговом окне DB70.

Рамеш, руководитель тестирования Chemical Tracking System, напи сал несколько вариантов тестирования, похожих на этот, исходя из своего понимания того, как пользователь может взаимодействовать с системой для запроса химиката. Такие абстрактные варианты тестиро вания не зависят от деталей реализации. В них не разъясняется ввод данных в поля, щелчки кнопок или другие особые детали взаимодейст Часть II. Разработка требований к ПО вия. По мере разработки пользовательского интерфейса Рамеш воз вращался к этим абстрактным вариантам тестирования, создавая бо лее точные процедуры тестирования.

А теперь самое интересное — тестирование требований с помощью вариантов тестирования. Сначала Рамеш соединил на карте каждый вариант тестирования с функциональными требованиями. Он прове рил и убедился, что вариант тестирования может быть выполнен при существующем наборе требований. Он также убедился, что по крайней мере один вариант тестирования связан с каждым функциональным требованием. Затем Рамеш проследил путь исполнения каждого вари анта тестирования по карте диалога с помощью маркера. Толстая ли ния на рис. 15-8 показывает, путь предыдущего варианта тестирования на карте диалогов.

отмена DB Выберите химикат для запроса введите идентификатор введите идентификатор химиката;

химиката нет химиката;

химикат есть на складе на складе DB50 заказать новый контейнер Список контейнеров на складе химикатов контейнер продавец выбран выбран DB Текущий список J4 запросов химикатов Рис. 15-8. Отслеживание варианта тестирования на карте диалогов для варианта использования «Запрос химиката» Отслеживая путь исполнения для каждого варианта тестирования, вы можете найти некорректные или пропущенные требования, испра вить ошибки на карте диалогов и отшлифовать варианты тестирова ния. Предположим, что после «исполнения» всех вариантов тестирова ния в этом случае линия на карте диалогов, помеченная как «заказать 30!:

Глава 15. Утверждение требований новый контейнер» от DB50 к DB60 на рис. 15-7 не была выделена. Воз можны два объяснения этому:

I перемещение от DB50 к DB60 не допускается поведением системы.

Аналитик должен убрать эту линию с карты диалогов. Если в специ фикации есть требование, в котором указан этот переход, то это требование также необходимо удалить;

I перемещение допустимо поведением системы, но вариант тести рования, который демонстрирует это поведение, отсутствует.

Точно так же, предположим, что вариант тестирования, доступный пользователю, позволяет перейти непосредственно от диалогового окна DB40 к DB70. Однако в диалоговом окне на рис. 15-7 такой линии нет, и поэтому вариант тестирования не может быть выполнен с суще ствующими требованиями. И опять же возможны две интерпретации, и вам необходимо определить, какая из них верна:

I перемещение от DB40 к DB70 не допускается поведением системы, следовательно, вариант тестирования неправильный;

I перемещение от DB40 к DB70 допускается поведением системы, но на карте диалогов и, возможно, в спецификации требований к ПО отсутствует требование, позволяющее выполнить вариант тестиро вания.

В этих примерах аналитик и тестировщик объединили требования, модели анализа и варианты тестирования для выявления пропущен ных, ошибочных или ненужных требований задолго до того, как разра ботчики приступили к написанию кода. Концептуальное тестирование требований к ПО — мощный прием управления затратами и графиком проекта, так как он позволяет выявлять неясности и ошибки в требова ниях в начале игры. Каждый раз, когда я использую этот прием, я нахо жу ошибки во всех элементах, которые сравниваю друг с другом. Как сказал RossCollard (1999):

Варианты использования продукта и варианты тестирования отлично взаимодейст вуют в двух случаях: если варианты использования написаны полно, аккуратно и яс но, то процесс составления вариантов тестирования становится крайне простым;

а если варианты использования не в лучшей форме, то попытка составления вариан тов тестирования поможет вам отладить вариант использования продукта.

Определение критерия приемлемости Разработчики ПО могут быть уверены, что они создают идеальный продукт, однако последнее слово за клиентом. Клиенты тестируют продукт, чтобы определить, удовлетворяет ли система критерию при Часть II. Разработка требований к ПО емлемости (acceptance criteria) (IEEE, 1990). Если да, то клиент платит за продукт, разработанный согласно контракту. Критерий приемлемо сти — и, следовательно, проверка приемлемости — является показа телем, удовлетворяет ли продукт задокументированным требованиям и годится ли он для использования в предполагаемой операционной среде (Hsia, Kung и Sell, 1997). Делегирование разработки тестов на приемлемость пользователям — эффективная стратегия разработки требований. Чем раньше в процессе разработки пользователи проду мают тесты на проверку приемлемости, тем скорее удастся отловит^ дефекты в требованиях и разрабатываемом ПО.

Проверку приемлемости следует сосредоточить на предполагае мых сценариях использования (Steven, 2002;

Jeffries, Anderson и Hen drickson, 2001). Ключевым пользователям при принятии решения о способе оценки приемлемости системы стоит принять во внимание наиболее общие и важные варианты использования, когда они реша ют, каким образом оценивать приемлемость ПО. Тесты приемлемости фокусируются на нормальной линии поведения вариантов использо вания продукта, а не на более редких альтернативных направления'< или на том, обрабатывает ли система исключения соответствующим образом. При малейшей возможности старайтесь автоматизировать тестирование приемлемости. Это упростит вам жизнь, когда их при дется проводить после внесения изменений и добавления дополни тельной функциональности в следующих версиях продукта. Тестиро вание приемлемости также должны затрагивать нефункциональные требования. Они должны подтверждать, что цели, связанные с произ водительностью, достигаются на всех платформах, система соответ ствует стандартам легкости и простоты использования и все соответ ствующие пользовательские требования были реализованы.

Пользовательское тестирование приемлемости не заменит полного Ловушка тестирования системы на основании требований, при котором тестируются все нор мальные пути и пути исключений, а также большое количество комбинаций данных.

Если критерий приемлемости разрабатывается клиентами, то появ ляется еще одна возможность утвердить наиболее важные требова ния. На этапе сбора информации это изменение формулировки вопро са с «Что вам нужно делать с помощью системы?» к «Как вы делаете вывод о том, что система удовлетворяет вашим потребностям?». Если клиент не может описать, как он оценит, что конкретное требование удовлетворено системой, значит, требование сформулировано недос таточно ясно, Глава 15. Утверждение требований Недостаточно просто написать требования. Вы должны убедиться, что именно эти требования и нужны и что они достаточно хороши, что бы стать основой для дизайна, сборки, тестирования и управления проектом. Планирование тестов приемлемости, неофициальных про смотров требований, экспертизы спецификации требований к ПО и приемов тестирования требований поможет вам собрать продукт вы сокого качества быстрее и дешевле, чем когда бы то ни было.

Что теперь?

1 Выберите наугад страницу в спецификации требований к ПО вашего проекта, Попросите представителей различных групп заинтересованных в проекте лиц тщательно проверить ее с помощью контрольного списка дефектов на рис. 15- на предмет выявления проблем.

I Если в ходе этой пробной проверки обнаружено столько ошибок, что рецензенты забеспокоились о качестве продукта, убедите представителей пользователей и разработчиков проверить всю спецификацию требований к ПО. Чтобы эта про верка была максимально результативна, обучите команду.

Щ Определите концептуальные варианты тестирования для варианта использова ния продукта или для той части спецификации требований к ПО, которая еще не реализована в виде кода. Спросите у представителей пользователей, отражено ли, по их мнению, в вариантах тестирования предполагаемое поведение систе мы. Убедитесь, что вы определили все функциональные требования, которые бу дут разрешены конкретным вариантом тестирования, и что в спецификации нет лишних требований.

1 Совместно со сторонниками продукта определите критерии, которые они и их коллеги будут использовать для оценки приемлемости системы, Часть (\. Разработка требований к ПО Проблемы при разработке специальных требований В этой книге описана разработка требований для только создаваемо го, нового ПО или системы, т.е. речь идет о проекте с чистого листа (green-field project). Однако многие организации тратят массу сил на обслуживание существующих систем или построение следующих вер сий уже установленного коммерческого продукта. Другие компании создают новые системы с нуля, вместо того чтобы заняться интегра цией, настройкой и расширением готовых коммерческих продуктов (commercial off-the-shelf, COTS) для удовлетворения своих потребно стей. Есть еще и такие, что разработку ПО доверяют сторонним орг а низациям. В этой главе описываются различные приемы работы над требованиями для таких типов проектов, а также для неожиданно воз никающих проектов с непостоянными и неопределенными бизнес-по требностями.

Требования к проектам по обслуживанию Обслуживание (maintenance) означает изменения, вносимые в экс плуатируемое в настоящее время ПО. Иногда на обслуживание, кото рое часто называют продолжающейся разработкой (continuing engi neering или ongoing development), тратится большая часть ресурсов организации, специализирующейся на разработке ПО. Программи сты, занимающиеся поддержкой, обычно исправляют ошибки, добав ляют новые функции или сообщения к существующим системам, а так же приводят функциональность в соответствие с изменившимися бизнес-правилами. Немногие действующие системы имеют адекват ную документацию. Тех разработчиков, которые стояли у истоков ci/c темы и держали всю информацию в головах, давно уже нет. Приемы, описанные в этой главе, помогут вам разбираться с требованиями для обслуживания и поддержки действующих проектов, чтобы сделать продукт более качественным и лучше выполнять дальнейшее обслужи вание (Wiegers, 2001).

Пропавшая спецификация В спецификации требований для следующей версии сформировавшейся системы часто пишут так: «Новая система должна делать то же, что и старая, кроме того, что будут добавлены новые функции и исправлены ошибки». Как-то аналитик получила именно такую спецификацию для пятой версии важного продукта. Чтобы точно вы яснить, что же текущая версия делает, она заглянула в спецификацию требований к четвертой версии этого ПО. К сожалению, по существу там было сказано вот что:

«Версия 4 должна делать то же, что и версия 3, кроме того, что будут добавлены но вые функции и исправлены ошибки». Она подняла все предыдущие документы, но так и не смогла найти настоящую спецификацию к требованиям. В каждой специфи кации пречислялись отличия новой версии от предыдущей, однако нигде не было описания первоначальной системы. Как следствие, у каждого сложилось свое пони мание возможностей текущей системы. Если вы оказались в такой ситуации, задоку ментируйте требования для следующей версии более подробно, чтобы все заинте ресованные лица смогли разобраться в том, что же все-таки система делает.

Начните сбор информации При отсутствии точной документации к требованиям, специалисты по обслуживанию должны заняться обратной инженерией, т.е. разобрать ся в функциях системы исходя из ее кода. Я называю эту работу «ар хеологией программного обеспечения». Чтобы она оказалась макси мально выгодной, «археологи» должны документировать результаты своих изысканий в форме описания требований или дизайна. Аккурат но фиксируя информацию об определенных частях текущей системы, команда облегчит себе работу по дальнейшему улучшению системы.

Возможно, ваша текущая система представляет собой бесформен ный сгусток истории и загадок, как на рис. 16-1. Представьте, что вас попросили реализовать некую новую функциональность в области А на этом рисунке. Начните с документирования новых требований в струк турированной, пусть и неполной, спецификации требований к ПО или воспользуйтесь утилитой для управления требованиями. Когда вы до бавите новую функциональность, вам придется сообразить, как новые экраны и функции будут взаимодействовать с существующей систе мой. Эти взаимодействия показаны на рис. 16-1 в виде мостов между областью А и текущей системой. Анализируя ситуацию, вы получите 310 Часть II. Разработка требований к ПО представление о белой области текущей системы — области В. Так вы выявите новую информацию, которую необходимо зафиксировать.

Один из полезных приемов — нарисовать карту диалогов для новых экранов, которые вы собираетесь добавить, показав перемещения от существующих элементов экрана и к ним. Вы также можете воспользо ваться и другими приемами моделирования: диаграммами классов и взаимодействия, диаграммами потоков данных и диаграммами «сущ ность — связь». Контекстная диаграмма или диаграмма варианта ис пользования продукта отображает внешние объекты или лица, взаи модействующие с системой. Еще один способ получения недостаю щий информации — добавлять в словарь данных новые понятия и изменять существующие определения при добавлении новых элемен тов к системе.

Рис. 16-1. Добавляя ясный и понятный фрагмент А к аморфной документации уже работающей системы, вы проясняете данные в области В документации При построении представления требований, в которое включены фрагменты текущей системы, решаются три задачи:

I останавливается непроизводительное растрачивание данных, по этому специалисты по обслуживанию лучше разбираются в измене ниях, внесенных только что;

I собирается информация о текущей системе, которая ранее не быпа задокументирована. При обслуживании системы команда сможет расширять эти раздробленные представления данных, таким обра зом, непрестанно улучшая документацию к системе. Растущая сто имость документирования этой вновь найденной информацией не велика по сравнению с ценой, которую кому-то придется заплатить в будущем, чтоб «раскопать» ее заново;

t обеспечивается проверка полноты функциональности системы по средством набора действующих тестов. (С другой стороны набор Глава 16. Проблемы при разработке специальных требований тестов пригодится в качестве первоначального источника информа ции при восстановлении требований к ПО.) Если вам нужно оказать хирургическое вмешательство в ПО в связи с вводом новых, пересмотром старых правительственных постановле ний или изменением политики компании, составьте список бизнес правил, влияющих на систему. Если вы не сделаете этого, вся важная информация останется только в головах членов команды. Поскольку люди по-разному интерпретируют важность влияния бизнеса на ваш проект, раздробленную информацию можно считать жалким вкладом в общее дело.

Множество проблем выявляется на стадии работы над взаимодей ствующими элементами, включая особенности взаимодействия раз личных ПО, ПО и оборудование, ПО и людей. При реализации измене ний выделите время на документирование обнаруженной информации о текущих внешних пользователях, ПО, оборудовании и коммуникаци онных интерфейсах. Структурные данные о совместной работе компо нентов системы помогут вам в будущем добавлять расширения более безопасно и эффективно. Однажды подрядчику потребовалось внести существенное улучшение в систему управления роботом, над созда нием которой работала моя команда. Наши модели дизайна помогли ему, и он смог эффективно совместить новые функции с архитектурой существующей системы. Если бы мы не предоставили эту информа цию, подрядчику пришлось заниматься обратной инженерией кода, чтобы разобраться в архитектуре и дизайне.

Разработка полной спецификации требований к ПО для всей произ водственной системы не всегда целесообразна. Между двумя крайно стями — работой безо всякой документацией и воссозданием идеаль ной спецификации — существует множество промежуточных стадий.

Если вы знаете, зачем вам нужны задокументированные требования, то сможете решить, будут ли оправданы затраты на воссоздание всей спецификации или ее части. Чем на более ранней стадии цикла разра ботки ПО вы находитесь, тем боле ценно наличие задокументирован ных требований.

Как-то я работал с командой, которая только что начала заниматься требованиями для второй версии крупного продукта со встроенным ПО. Требования для версии 1, которая в тот момент реализовывалась, были проработаны не очень хорошо. Ведущий аналитик требований желал знать, стоит ли возвращаться и исправлять требования для вер сии. Руководство же компании полагало, что эта производственная линия будет основных источником дохода в течение по крайней мере 10 лет, а также планировало повторно воспользоваться некоторыми ос Часть II. Разработка требований к ПО новными требованиями в нескольких побочных продуктах. В этом слу чае стоило улучшить документацию требований для версии 1, посколь ку она лежала в основе всей последующей работы над продуктами это го семейства. Если бы команда в тот момент работала над версией 5. предыдущей системы, которую планировалось изъять из производства в течение года, тогда не стоило бы воссоздавать спецификацию требо ваний к ПО.

От кода через требования к тестированию Компания A. Datum Corporation нуждалась в полном наборе вариантов тестирования для основного продукта, сложного и крайне важного бухгалтерского приложения, разработанного несколько лет назад. Специалисты компании решили воссоздать ва рианты использования на основе существующего кода, а затем, описаясь на них, разработать варианты тестирования.

Сначала аналитик воссоздал диаграммы класса производства ПО с помощью средств, способных создавать модели из исходного кода. Затем он составил описа ния вариантов использования для типичных пользовательских задач, причем некото рые были весьма сложными. Эти варианты использования затрагивали все возмож ные пользовательские сценарии, а также множество условий исключений. Аналитики нарисовали диаграммы последовательностей UML (Unified Modeling Language - уни фицированный язык моделирования) для того, чтобы связать варианты использова ния и классы систем (Armour и Miller, 2001). И последнее: они вручную собрали большой набор вариантов тестирования, чтобы обработать все нормальные и ис ключительные случаи вариантов использования. Создавая требования и тестируя функциональность посредством обратной инженерии, вы можете быть уверены, что они отражают реальную систему и ее известные модели использования.

Применяйте новые приемы работы с требованиями В основе всей разработки ПО лежат требования, которые могут быть сформулированы в форме простого запроса на изменение. Проекты по обслуживанию предоставляют возможность испробовать новые методы разработки требований безопасно и в малом масштабе. За манчиво утверждение, что небольшое улучшение не означает необхо димости написания требований. Давление, которое оказывается при выпуске следующей версии, может заставить вас решить, что у вас нет времени на требования. Но улучшение проектов позволит вам посте пенно обучаться. Таким образом, к следующему крупному проекту вы будете чувствовать себя опытным и уверенным, применяя эффектив ные приемы при разработке требований.

Глава 16. Проблемы при разработке специальных требований Предположим, отдел маркетинга или клиент требуют добавления к уже сформированному продукту новой функции. Изучите эту функцию с точки зрения вариантов использования, обсудив с инициатором за проса задачи, которые клиенты будут выполнять с ее помощью. Если до этого вы не имели дела с вариантами использования, попробуйте задокументировать их с помощью стандартного шаблона, как показа но на рис. 8-6. Если вы опробуете приемы работы с вариантами ис пользования, то снизите первоначальный риск их применения в проек те, разрабатываемом с нуля, поскольку именно от вашей квалифика ции может зависеть успех или неудача. Вы можете опробовать в малом масштабе и другие приемы при обслуживании продукта, например:

9 создание словаря данных (глава 10);

i рисование моделей анализа (глава 11);

I определение атрибутов качества и целей производительности (глава 12);

1 построение пользовательского интерфейса и технических прототи пов (глава 13);

1 проверку спецификации к требованиям (глава 15);

I написание вариантов тестирования на основе требований (глава 15);

I определение критерия приемлемости для пользователей (глава 15) Перемещайтесь по цепочке трассируемости Требования трассируемости данных помогут программисту по обслу живанию определить, какие компоненты следует модифицировать по сле изменения определенного требования. Однако в плохо задоку ментированной действующей системе информации о трассируемости нет. Когда кому-то из вашей команды доведется модифицировать су ществующую систему, он должен позаботиться о создании частичной матрицы трассируемости требований для того, чтобы связать новые или измененные требования с соответствующими элементами дизай на, кодом и вариантами тестирования. Собирать связи трассируемо сти по мере разработки не сложно, тогда как воссоздать их в завер шенной системе — практически нереально.

Глава 20 посвящена трассируемости требований.

Дополнительная информация Из-за возникновения «кругов на воде» при многих модификациях вам необходимо убедиться, что каждое изменение требования кор ректно сказывается на продуктах, связанных с разрабатываемым. От личный способ проверить согласованность изменений — экспертиза.

Часть II. Разработка требований к ПО Ниже перечислены четыре точки зрения (им посвящена Глава 15), ко торые должны представлять эксперты;

это касается и тех, кто занима ется обслуживанием:

I автора требований — при модификациях или улучшениях;

1 клиента, инициирующего запрос, или представителя отдела марке тинга, которые могут подтвердить, что в новых требованиях точно описаны необходимые изменения;

1 разработчиков, тестировщиков или других сотрудников, которые будут работать, руководствуясь новыми требованиями;

1 людей, на чью работу могут повлиять вносимые изменения.

Обновляйте документацию Все существующие представления требований следует обновлять по мере обслуживания, чтобы они адекватно отражали возможности мо дифицируемой системы. Если обновление обременительно, то им часто будут пренебрегать, поскольку занятые люди стараются сразу перейти к следующему запросу на обновление. А устаревшая доку ментация по требованиям и дизайну вряд ли окажется полезной при дальнейшем обслуживании. В индустрии ПО бытует страх того, что Hia написание документации всегда уходит слишком много времени, по этому вырабатывается условный рефлекс — пренебрегать всяким об новлением документации к требованиям. Однако какова цена того, что вы не обновляете требования и специалисту по обслуживанию (а, мо жет, им станете вы сами!) придется воссоздавать информацию? Отве тив на этот вопрос, вы сможете принять толковое решение о том, сле дует ли исправлять документацию требований при изменении ПО.

Требования для пакетных решений Даже при покупке готового пакета в качестве части или всего решения для нового проекта вам понадобятся требования. Готовые продукть, как правило, нужно конфигурировать, настраивать, интегрировать и расширять для работы в предполагаемой среде. Для выполнения всех этих действий необходимы требования, которые, кроме того, позво лит вам правильно выбрать наиболее подходящий пакет. Один из спо собов такой оценки предлагает следующее (Lawlisn др., 2001):

в оценить ваши требования по шкале от 1 до 10, чтобы определить важность каждого ;

Глава 16. Проблемы при разработке специальных требований определить, насколько каждый пакет отвечает вашим потребно стям. Используйте оценку 1 для обозначения полного удовлетворе ния, 0,5 — для частичного удовлетворения и 0 — если вас все не устраивает. Вы можете найти информацию, чтобы выполнить оцен ку, в литературе о продукте, в ответе поставщика на запрос на пред ложение (приглашение принять участие в торгах по проекту) или с помощью прямой проверки продукта;

оцените каждый пакет для нефункциональных требований, важных для ваших пользователей — производительность, легкость и про стоту применения, а также другие атрибуты качества, перечислен ные в главе 12;

оцените стоимость продукта, надежность поставщика, поддержку продукта, осуществляемую поставщиком, внешние интерфейсы, которые позволят вам осуществлять расширение и интеграцию продукта, а также совместимость с технологическими требования ми или ограничениями для вашей среды.

Готовый пакет Рис. 16-2. Готовые пакеты настраиваются и интегрируются в существующую среду приложений, и расширяются с помощью дополнительных элементов.

В этом разделе описывается несколько способов определения тре бований при планировании приобретения коммерческого продукта, отвечающего вашим потребностям (рис. 16-2), Разработка вариантов использования Не имеет смысла разрабатывать подробные функциональные требо вания или пользовательский интерфейс, если вы планируете приобре 316 Часть II. Разработка требований к ПО сти готовый продукт. В этом случае стоит обратить особое внимание на уровень требований пользователей. И здесь вам помогут варианты использования продукта. Любой выбранный вами пакет должен обес печивать выполнение клиентских задач, хотя каждый пакет делает это своим способом. Варианты использования позволят вам обнаружить пробелы и выявить те фрагменты, где необходима настройка или рас ширение, чтобы пакет полностью удовлетворял вашим потребностям.

Многие пакеты предоставляют готовые решения для удовлетворения нужд, связанных с обработкой информации. Следовательно, вы долж ны указать отчеты, которые должен генерировать готовый продукт, и определить, до какой степени продукт позволит вам настраивать его стандартные отчеты. Вряд л и вы найдете готовые решения для каждо го варианта использования, поэтому расставьте их и сообщения по приоритетам. Определите, какие функции должны быть доступны EI первый день, какие могут подождать до дальнейших расширений ибес) каких пользователи не смогут работать.

Для того чтобы определить, позволит ли пакет пользователям вы полнять их задачи, и если да, то насколько хорошо, на основе вариан тов использования с высоким приоритетом разработайте варианть тестирования. Включите в них варианты использования, в которых рас сматривается, как система обрабатывает возможные важные условия исключений. Схожий прием — запустить готовый продукт для наборе сценариев, представляющего ожидаемые модели использования — и> еще называют оперативным профилем (Musa, 1996).

Работа с бизнес-правилами Изучая требования, необходимо определить бизнес-правила, кото рым готовый продукт должен соответствовать. Сможете ли вы сконфи гурировать продукт в соответствии с корпоративной политикой, про мышленными стандартами или правительственными постановления ми? Насколько легко вносить коррективы при изменении этих правил и положений? Создаются ли отчеты в корректном формате? Вы также можете определить структуры данных, необходимые для удовлетворе ния вариантов использования и бизнес-правил. Попробуйте отыскать несогласованности между вашими структурами данных и набором мо делей данных поставщика.

Некоторые пакеты учитывают глобальные бизнес-правила, напри мер расчет подоходного налога с дохода или печать деклараций о до ходах, Уверены ли вы, что они реализованы корректно? Обеспечит ли sac поставщик новой версией пакета в случае изменения этих правил и расчетов? Если да, то как быстро? Предоставит ли поставщик список Глава 16. Проблемы при разработке специальных требований бизнес-правил, реализованных в пакете Если продукт поддерживает какие-либо бизнес-правила, которые для вас неприемлемы, можете ли вы отключить или изменить их?

Определение требований к качеству Атрибуты качества и задачи, связанные с производительностью, о ко торых рассказывалось в главе 12, — еще один аспект требований пользователей, который имеет большое значение при выборе пакет ного решения. Следует рассмотреть, по крайней мере, следующие ат рибуты.

I Производительность. Каково максимальное время отклика, при емлемое для определенных операций? Может ли пакет обработать ожидаемую загрузку одновременно подключенных пользователей и пропускную способность транзакций?

1 Легкость и простота использования. Соответствует ли пакет всем принятым стандартам пользовательского интерфейса? Похож ли интерфейс на интерфейсы других приложений, с которыми зна комы пользователи? Насколько легко ваши клиенты смогут обучить работать с пакетом?

1 Гибкость. Насколько легко разработчики смогут изменить или рас ширить пакет, чтобы удовлетворить ваши потребности? Входят ли в пакет соответствующие «ловушки» (точки подключения и расшире ния) и прикладные программные интерфейсы, чтобы добавлять расширения?

8 Способность к взаимодействию. Насколько легко вы сможете интегрировать пакет с другими приложениями, используемыми в компании? Используются ли стандартные форматы для обмена данными?

П Целостность. Допускает ли пакет контроль допуска пользователей к системе или применение специальных функций? Предохраняет ли он данные от потери, повреждения или неавторизованного досту па? Можете ли вы определять различные уровни привилегий поль зователей?

При приобретении готовых пакетов организация получает меньшую гибкость при работе с требованиями, чем при разработке продукта «под заказ». Вам необходимо выяснить, какие из запрошенных воз можностей не могут быть предметом переговоров, а какие вы может изменять в рамках ограничений, налагаемых пакетом. Единственная возможность выбрать правильный пакет решений — понять задачи пользователей и коммерческие задачи, для решения которых вы при обретаете пакет.

318 Часть II. Разработка требований к ПО Требования к проектам, выполняемым сторонними организациями Для того чтобы поручить разработку продукта другой компании, необ ходимо иметь требования высокого качества, поскольку, вероятнее всего, прямые контакты с командой разработчиков будут минималь ными. Вы отправите поставщику запрос на предложение, специфика цию требований и определенные критерии приемлемости продукта, а они вернут завершенный продукт и сопутствующую документацию, как показано на рис. 16-3.

Запрос на предложение.

требования, критерий приемлемое!!' \ Продуй, документадин Рис. 16-3. Требования - краеугольный камень проекта, выполняемого сторонними организациями У вас не будет возможности для ежедневных уточнений, принятия решений и изменений, которые вы практикуете, когда разработчики и заказчики работают в непосредственной близости друг от друга. Пло хо определенные и плохо организованные требования зачастую стано вятся причиной неудачи проекта, выполняемого сторонними органи зациями (Wiegers, 2003). При подготовке требований для удаленной разработки вам надо иметь в виду некоторые особенности, которые описаны далее.

Детализируйте запрос. Если вы распространяете запрос на предло жение, поставщикам необходимо точно знать, что именно вы хотите, чтобы сообщить вам достоверную информацию и оценку (Porter-Ro1h, 2002).

Избегайте неясностей. Остерегайтесь неясных терминов (табл. 10-1), они становятся причиной полной неразберихи. Как-то раз я читал спе цификацию требований к ПО, предназначенную для сторонней организа ции-разработчика, в которой много раз повторялось слово подцерж*а.

Глава 16. Проблемы при разработке специальных требований Однако специалисты этой организации не знали, как значение этого слова интерпретировать в каждом случае. Ответственность за ясное выражение требований заказчика лежит на создателе требований.

Определите точки взаимодействия с поставщиком. Если с разра ботчиками нельзя организовать встречи «лицом к лицу, в режиме ре ального времени», придумайте другие механизмы, которые позволят вам быть в курсе дел по вашему проекту. Экспертные оценки и прото типы позволяют понять, как поставщик интерпретирует требования.

Поэтапная разработка, при которой поставщик периодически постав ляет небольшие части продукта, считается одним из способов, обес печивающих управление рисками. Он позволяет быстро корректиро вать курс, когда разработчики поставщика из-за непонимания выбира ют неверное направление.

Ловушка Не следует предполагать, что поставщики будут интерпретировать не ясные и неполные требования точно так же, как вы. Некоторые поставщики понимают требования буквально и создают точно то, что вы запросите. Бремя передачи всей необходимой информации поставщику лежит на заказчике;

не отказывайтесь почаще беседовать с поставщиком, чтобы снять все вопросы, касающиеся требований.

Определите взаимно приемлемый процесс управления измене ниями. В ходе разработки примерно 45% проектов, выполняемых сто ронними организациями, пользовательские требования неумолимо разрастаются (Jones, 1994}. У изменений всегда есть цена, поэтому управление изменениями, позволяющее контролировать границы проекта, жизненно важно при работе по контракту. В контракте необ ходимо указать, кто платит за различные виды изменений, например за только что запрошенную функциональность или коррективы, вноси мые в первоначальные требования.

Выделите время для нескольких циклов и проверки требований.

В график одного неудавшегося проекта, разрабатываемого сторонней организацией, был включен этап длиной в одну неделю под названием «Проведение семинаров по требованиям», следующим был указан этап реализации нескольких подсистем. Поставщик забыл о важнейших промежуточных стадиях — проверке и корректировке спецификации требований. Поскольку процесс разработки требований является ите рационным и зависит от эффективного взаимодействия, необходимо предусмотреть время на эти циклы проверок. В том проекте заказчика и разработчика разделял континент. При этом обмен информации при миллиардах вопросов, возникающих при работе над спецификацией Часть II. Разработка требований к ПО требований к ПО, был медленным. Неспособность своевременно ре шать вопросы, связанные с требованиями, нарушает график проекта, и со временем приведет обе стороны в зал суда.

Определите критерий приемлемости. В соответствии с рекомен дацией Stephen Covey «начинайте, думая об окончании» (Covey, 1989i, определите, как вы будете оценивать приемлемость разрабатываема го по контракту продукта для вас и ваших клиентов. Как вы будете ре шать, пора ли делать финальный платеж?

Дополнительная информация В главе 15 предлагается несколько приемов для определения критерия приемлемости.

Требования для принципиально новых проектов Когда я слышу выражение «собрать требования», мне представляется поиск требований, лежащих вокруг офиса, как сбор цветов, которые мы можем сорвать и положить в корзину. Если бы это было так просто!

В некоторых проектах, где, как правило, проблемы хорошо обоснова ны, и в самом деле можно указать большую часть предполагаемой функциональности на ранней стадии. Для них имеет смысл заранее разработать согласованные требования.

Однако в более неопределенных проектах предполагаемые воз можности системы проясняются только со временем. Для таких новых проектов характерны неясные требования и частые изменения. Поэто му необходимо и требования, и ПО разрабатывать поэтапно и посте пенно (Highsmith, 2000). При быстрой разработке проектов, для кото рых учитываются растущие требования рынка, часто отходят от обще принятых приемов создания требований. Вместо этого за основу берут неясные, высокоуровневые положения о бизнес-целях. Однаж ды президент компании, занимающейся разработкой ПО для Интерне та, сообщил мне в разговоре, что у них часто возникают проблемы, связанные с требованиями. Одна из причин крылась в том, что прямо после подписания контракта с клиентом исполнители организовывали семинар, посвященный визуальному дизайну. Они не удел ял и времен и на выяснение того, как пользователи смогут получать данные с Web сайта, что приводило к значительным переделкам.

Глава 16. Проблемы при разработке специальных требований Преобладание новых и стремительно развивающихся проектов при вело к созданию различных методик быстрой разработки. Их цель — быстро передать полезную функциональность в руки пользователям (Gilb, 1988;

Beck, 2000;

Cockburn, 2002). В них применяется упрощен ный подход к разработке требований и неформальный подход к управ лению требованиями. Требования описываются в терминах характери стик продукта или в форме историй пользователей, похожими на обычные варианты использования, описанные в главе 8. Вместо под робной документации к требованиям предпочтение отдается постоян ному взаимодействию с представителем клиента, который, находясь рядом, имеет возможность разъяснять детали и отвечать на вопросы.

В философии быстрой разработки изменения ПО рассматриваются как нечто неизбежное и желательное. Система корректируется под воздействием обратной связи с клиентом и при изменении бизнес нужд, Чтобы справиться с этими изменениям, системы строятся с не большим приращением, причем подразумевается, что следующая разработанная часть повлияет на уже созданную часть системы, улуч шит первоначальные функции и добавит новые. Этот способ хорошо работает при высокой степени неясности в требованиях для информа ционных систем и Интернет-проектов. Однако он меньше подходит для работы с приложениями, требования к которым ясны, и для разра ботки встроенных систем, Совершенно очевидно, что процесс разработки должен быть осно ван на ясном понимании того, что пользователи хотят делать с помо щью системы. Требования к быстро меняющимся проектам слишком нестабильны, чтобы оправдать массу усилий, затраченную на предва рительную разработку требований. Однако по мнению Jeff Gainer (1999): «Трудность для разработчиков ПО заключается в том, при по вторяющихся циклах разработки появляется искушение изменить тре бования и расширить объем работ». Если этими циклами управлять должным образом, то они помогут вам сделать ПО, соответствующее текущим бизнес-нуждам, хотя и ценой переработки заблаговременнс завершенного дизайна, кода и тестов.

Иногда лица, заинтересованные в проекте, утверждают, что роль требований неизвестна и непостижима, тогда как они просто горят от нетерпения побыстрее заняться написанием кода, при этом они не учитывают возможность всеобъемлющего перекодирования. Не под давайтесь искушению использовать «время Интернета» как оправ дание экономии на разработке требований. Если вы и в самом деле работаете над совершенно новым проектом, вам, возможно, следует Часть II. Разработка требований к ПО воспользоваться приемами работы с требованиями, описанными в следующих разделах.

Бессистемная спецификация пользовательских требований Неформально задокументированные требования годятся для систем, создаваемых небольшими, географически не разделенными команда ми. Методика быстрой разработки, именуемая экстремальным про граммированием (Extreme Programming), рекомендует документиро вать требования в форме простых рассказов для пользователей, напи санных на учетных карточках (Beck, 2000;

Jeffries, Anderson и Hendrickson, 2001). Обратите внимание, что даже при этом подходе необходимо, чтобы клиенты представляли себе требования достаточ но ясно, чтобы описать поведение системы в форме рассказов.

Ловушка Не следует ожидать, что для успеха проекта хватит и телепатической передачи ненаписанных требований. Требования для каждого проекта должны быть представлены в формах, которые позволят ознакомить с ними всех заинтересован ных лиц, обновлять их и управлять ими на протяжении разработки проекта. Кроме того, необходимо, чтобы кто-то отвечал за такое документирование и обновление.

Присутствие клиента Частые беседы участников проекта и клиентов считаются наиболее эффективным способом разрешения многих проблем, связанных с требованиями. Написанная документация, несмотря на детализацию, не полностью заменяет это постоянное общение. Основу экстремаль ного программирования составляет постоянное и непосредственное присутствие клиента на этих обсуждениях. Однако, как говорилось в главе 6, большинство проектов предназначено для нескольких классов пользователей, а также для других заинтересованных лиц.

Клиент в поле зрения Однажды я писал программу для ученого-исследователя, рабочее место которого бы ло расположено примерно в 10 футах от моего стола. Джон мог моментально отве чать на мои вопросы, высказывать свое мнение по поводу экранов интерфейса и по яснять неформально изложенные требования. Однажды Джон перебрался в новый офис, расположенный на том же этаже того же здания. Я заметил, что моя произво дительность моментально упала из-за задержки при получении ответной информа ции от Джона. Я стал тратить больше времени на устранение проблем, поскольку Глава 16. Проблемы при разработке специальных требований иногда двигался в неправильном направлении, так как вовремя не получал корректи рующих указаний. При раработке ничто не заменит тесное взаимодействие с работающим за соседним столом клиентом. Однако будьте осторожны - при слиш ком частых прерываниях людям трудно опять сосредоточиться на работе, Может по требоваться 15 минут на повторное погружение в крайне эффективное, сосредото ченное состояние, которое называется потоком (DeMarco и Lister, 1999).

Сам по себе находящийся рядом клиент не гарантирует желаемого результата. Мой коллега Крис, налаживая работу команды разработ чиков, привлек двух сторонников продукта. Выводы его оказались та кими: «В то время как близость оказала благотворное воздействие на команду разработчиков, результаты работы со сторонниками продукта были смешанными. Один из них был в центре всего, и все же умудрял ся избегать нас. Человек, выполняющий обязанности сторонника про дукта в данный момент, прекрасно общается с разработчиками и дей ствительно убыстряет разработку ПО».

Не следует ожидать, что одному человеку удастся разрешить все воз Ловушка никающие проблемы, связанные с требованиями. Когда роль сторонника продукта выполняют несколько представителей пользователей, это более эффективно.

Периодическая расстановка приоритетов на ранних стадиях Поэтапная разработка успешна, если клиенты и разработчики сотруд ничают при выборе порядка реализации функций. Задача команды раз работчиков — регулярно передавать полезную функциональность и ка чественные улучшения в руки пользователей, поэтому им необходимо знать, над какими возможностями они будут работать на каждом этапе.

Простое управление изменениями Процессы разработки ПО должны быть настолько просты, насколько возможно для того, чтобы работа была сделана отлично, но не проще.

Пассивный контроль не годится для новых проектов, которые требуют частых изменений. Сделайте процесс внесения изменений «обтекае мым», чтобы минимальное количество людей максимально быстро принимали решения об изменении требований. Это не означает, что каждый разработчик должен просто вносить любые изменения, кото рые нравятся ему или клиентам: это приведет к хаосу, а не убыстрит разработку.

Часть II. Разработка требований к ПО Что теперь?

i Если вы обслуживаете продукт, применяете готовые решения, обращаетесь к сторонним разработчикам или создаете проект «с нуля», изучите приемы форму лирования требований, описанные в главе 3, чтобы выбрать из них тот, который сделает ваш проект ценным и успешным.

I Если у вас возникали связанные с требованиями проблемы, когда вы прежде за нимались разработкой проектов таких типов, как те, что описаны в этой главе, проанализируйте их - это поможет диагностировать проблемы и определить ос новные причины. Если вы воспользуетесь приемами из главы 3 или способами, описанными здесь, то удастся ли вам предотвратить возникновение проблем в следующем проекте подобного типа?

Глава 16. Проблемы при разработке специальных требований От разработки требований к следующим этапам Работа над Chemical Tracking System продвигалась просто за мечательно. Но спонсор проекта Жерар и сторонник продукта от персонала, работающего на складе, Роксана, сомневались, стоит ли тратить много времени на определение требований, Тем не менее они присоединились к разработчикам и другим сторонникам продукта, которые проводили однодневный тре нинг, посвященный работе над требованиями к ПО. На этом тренинге подчеркивалась важность достижения общего пони мания всеми заинтересованными в проекте лицами бизнес целей и нужд пользователей. Кроме того, всех участников оз накомили с терминологией, касающейся требований, концеп циями и приемами, которые будут использоваться в работе. А также призвали применять лучшие приемы для работы с тре бованиями на практике, По мере развития проекта Жерар получил отличные отзывы от представителей пользователей о том, насколько хорошо прошла разработка требований. Он даже организовал ланч для аналитиков и апологетов продукта, чтобы отпраздновать создание основной версии требований для первого выпуска системы. На ланче Жерар поблагодарил тех, кто занимался сбором информации для создания требований, за их вклад и коллективную работу. А затем сказал: « Теперь, когда с требо ваниями все в порядке, я с нетерпением ожидаю скорого появ ления готового кода».

«Мы еще не готовы писать код продукта, — ответил менеджео проекта, —Мы планируем выпускать систему поэтапно, поэто му ее необходимо разрабатывать, сообразуясь с будущими дополнениями. С помощью прототипов мы получили четкое 326 Часть II. Разработка требований к ПО представление о технической стороне и смогли понять харак теристики интерфейса, который предпочитают пользователи, Если на этой стадии мы потратим еще немного времени на ди зайн, то сможем избежать проблем в течение следующих не скольких месяцев, когда придет время добавлять функцио нальность к системе».

Жерар расстроился. Все выглядело так, как будто разработчи ки сознательно медлили, вместо того чтобы прямо приступить к работе. Однако не делал ли он преждевременных выводов?

Опытные менеджеры проекта и разработчики понимают ценность пре образования требований к ПО в надежный дизайн и рациональные планы. Они необходимы в тех случаях, когда следующая версия пред ставляет 1 или 100% всего конечного продукта. В этой главе мы рас смотрим, как преодолеть пропасть, которая отделяет разработку тре бований от успешного выпуска продукта: несколько вариантов влия ния требований на планы проекта, дизайн, код и тестирование, как показано на рис. 17-1.

^^„„^^ • Используйте требования для оценки масштаба проекта """"""Ч " ^Р11 Р304613* основывайтесь на размере продукта s'*' Q Планы проекта j • Обновляйте планы при изменении требований Учитывайте приоритеты требований при выполнении итерации Попросите разработчиков просмотреть требования Учитывайте атрибуты качества при дизайне архитектуры Распределяйте требования по компонентам Отследите требования до дизайна и кода Начинайте разработку тестирования на ранних стадиях Используйте требования при тестировании системы Попросите пользователей разработать проверочные тесты Отследите требования до тестов Рис. 17-1. Влияние требований на планирование проекта, дизайн, написание кода и тестирование От требований -- к планам проекта Поскольку именно требования определяют предполагаемый исход (результат) проекта, планы, сметы и графики следует разрабатывать на основе требований. Однако необходимо помнить, что наиболее важный результат проекта — это та система, которая соответствует бизнес-целям, а не обязательно та, в которой реализованы все пер воначально требования согласно первоначальному плану проекта.

Глава 17, От разработки требований - к следующим этапам В требованиях и планах указана первоначальная оценка затрат на про ект, определенная членами команды. Однако границы проекты могут выйти за первоначальные рамки, дай планы могут оказаться невыпол нимыми. Кроме того, бизнес-потребности, бизнес-правила и ограни чения проекта могут измениться. Успех проекта сомнителен, если вы не будете обновлять ваши планы в соответствии с изменяющимися целями и обстоятельствами.

Менеджеров проекта часто интересует, сколько времени и усилий понадобится для разработки требований. Для небольших проектов, которыми обычно занималась наша команда, этот этап обычно стоил от 12 до 15% всех затрат (Wiegers, 19Э6а), однако показатель зависит от объема и сложности проекта. Несмотря на опасения, что работа над требованиями замедлит создание продукта, доказано, что понятные требования ускоряют процесс разработки, что и показывают следую щие примеры:

1 изучение 15 проектов в сфере телекоммуникаций и банковской сферы показало, что в наиболее успешных проектах примерно 28% ресурсов тратилось на разработку требований (Hofmann и Lehner, 2001): 11%— на сбор информации по требованиям, 10% — на мо делирование, а 7% на проверку и утверждение. На разработку тре бований для среднего проекта необходимой,7% всех ресурсов и 38,6% времени;

I в проектах NASA, в которых затрачивалось более 10% всех ресурсов на разработку требований, затраты и отклонения от графика оказа лись существенно ниже, чем в проектах, где на требования затрачи валось меньше ресурсов (Hooks иРаггу, 2001);

I исследования, проведенные в Европе, показали, что команды, раз рабатывающие продукты более быстро, посвятили больше времени и усилий требованиям, чем более медленные команды (табл. 17-1) (Blackburn, Scudder и Van Wassenhove, 1996).

Не все ресурсы на разработку требований должны расходоваться в начале проекта, как в модели «водопада» или последовательной моде ли жизненного цикла. В итеративных моделях определенное время на требования будет тратиться в каждом повторном цикле разработки.

Цель таких проектов — реализовывать функциональность каждые не сколько недель, поэтому требованиями придется заниматься часто, но мало. На рис. 17-2 показано, как в разных моделях жизненного цикла в период разработки продукта распределяются усилия на требования.

Часть II. Разработка требований к ПО Таблица 17-1. Затраты на требования ускоряют разработку Усилия, затраченные Время, затраченное на требования на требования Более быстрые проекты 14% 17% Более медленные проекты 7% Модель «водопада» & Итеративная модель Последовательная модель Время Рис. 17-2. Распределение затрат на требования по времени различается для проектов, разрабатываемых на основе различных моделей жизненного цикла Старайтесь избегать паралича аналитического процесса. Если в са Ловушка мом начале проекта масса усилий тратится на разработку совершенных и полных требований - «раз и навсегда», то зачастую мало полезной функциональности уда ется реализовать в срок. С другой стороны, не следует избегать разработки требо ваний вообще только из-за боязни паралича аналитического процесса.

Требования и расчеты Первый шаг при оценке проекта — прикинуть объем продукта ПО. Эт;

з делают исходя из текстовых требований, моделей анализа, прототипов или элементов пользовательского интерфейса. Хотя не существует идеального мерила размера ПО, чаще всего используются следующие:

I количество отдельно тестируемых требований (Wilson, 1995);

Глава 17. От разработки требований - к следующим этапам I функциональные точки и характерные точки (Jones, 1996b) или трех мерные функциональные точки, включающие в себя данные, функ ции и элементы управления (Whitmire, 1995);

I количество, тип и сложность элементов графического пользова тельского интерфейса {graphical user interface, GUI);

1 оценка строк кода, необходимого для реализации специальныхтре бований;

1 количество классов объектов или других объектно-ориентирован ных метрик {Whitmire, 1997).

Все эти методы годятся для расчета размера. Выбирайте любой, учитывая собственный опыт и природу разрабатываемого ПО. Пони мание того, что команда добилась успеха при разработке схожих про ектов, используя аналогичные технологии, поможет вам оценить ре зультативность работы команды. Как только вы получите данные о раз мере, вы сможете воспользоваться коммерческим инструментом для расчета, который предлагает допустимые комбинации затрат на раз работку и сроков. Эти средства позволят вам привести в порядок рас четы, выполненные на основе таких факторов, как квалификация раз работчиков, сложность проекта, а также опыт команды в данной пред метной области. Информация о некоторых доступных средствах оценки ПО опубликована на http:// www.laatuk. com/tools/effon_estima tionjools.html.

Если вы не сравните ваши расчеты с действительными результата ми проекта и не улучшите методы расчета, то ваша оценка вечно будет оставаться всего лишь предположением. Чтобы собрать достаточна данных для корреляции размера ПО с усилиями на его разработку, по требуется время. Ваша цель —вывести уравнения, которое позволит с уверенностью оценить размер завершенного ПО на основании требо ваний к нему.

Однако даже самые лучшие методики не сработают, если клиенты, менеджеры или юристы будут часто менять требования. Если измене ния настолько велики, что аналитик и разработчики не успевают их учитывать, команда может впасть в ступор, не имея возможности про должать проект, В этом случае, возможно, стоит приостановить рабо ту, пока потребности клиентов не прояснятся.

Определенные крайние сроки поставки — головная боль для менед жеров большинства проектов. Каждый раз, когда заданные сроки и тщательно просчитанный график не совпадают, необходимы перего воры. Менеджер проекта, который может аргументировать расчеты, тщательно выполненные и основанные на фактах, выглядит при пе реговорах гораздо лучше, чем оперирующий предположениями. Если Часть II. Разработка требований к ПО лица, заинтересованные в проекте, не могут разрешить конфликт, раз горевшийся вокруг графика, стоит обратить внимание на бизнес-цели проекта: они будут определять, стоит ли уменьшить объем, добавить ресурсы или согласиться на некоторое снижение качества. Такие ре шения принимать нелегко, однако это единственный способ макси мально повысить ценность подлежащего сдаче продукта.

Есть час?

Как-то клиент попросил наших разработчиков адаптировать небольшую программу, которую он написал для себя, к нашей общей компьютерной сети, чтобы и его кол леги могли ее использовать. «Есть час?» - спросил меня наш менеджер, передавая мне поверхностную оценку размера проекта. Когда я порасспросил клиента и его коллег, чтобы понять, что же им требуется, оказалось, что проблем несколько боль ше. Я потратил 100 часов только на написание программы, которая им была нужна, без наведения лоска. Тот факт, я потратил в 100 раз больше времени, чем рассчи тывал менеджер, говорит о том, что его расчеты были несколько поспешными и ос новывались на неполной информации. Аналитик должен изучить требования, оце нить масштаб и составить представление о размере до того, как кто-нибудь присту пит к расчетам или возьмет на себя определенные обязательства.

Неясно сформулированные требования неизбежно приводят к не точным расчетам размера, затрат и графика. Поскольку определен ные неясности в требованиях на ранних стадиях проекта неизбежнь, заложите в график и бюджет резерв для непредвиденных обстоя тельств, чтобы учесть некоторое разрастание требований (Wiegers, 2002d). Оно происходит из-за изменения ситуации в бизнесе, смеще ния приоритетов пользователей и рынка, а также того, что со време нем заинтересованные в проекте лица лучше начинают понимать, что же продукт может и должен делать. Однако значительное увеличение требований, как правило, указывает на то, что масса положений была упущена в ходе сбора информации.

Отведите время на выбор соответствующих измерений для тех ти пов проектов, над которыми работает ваша команда. Между размером продукта, затратами, сроком разработки, производительностью и вре менем становления команды существуют сложные нелинейные взаи моотношения (Putnam и Myers, 1997). Если вы разберетесь в них, вы сможете избежать «области невозможного», то есть такой комбинации факторов, зависящих от размера продукта, графика и сотрудников при которой еще не один продукт не был успешно разработан.

Глава 17. От разработки требований - к следующим этапам Ловушка Не позволяйте, чтобы на ваши расчеты влияли желания других. Ваши прогнозы не должны меняться только потому, что кому-то они не нравятся. Слиш ком большое несоответствие в прогнозах указывает на необходимость переговоров.

Требования и график В некоторых проектах применяется график «справа— налево»: снача ла устанавливают дату поставки продукта, а затем определяют требо вания. В таком случае разработчики зачастую часто не успевают за кончить работу в указанные сроки, включив в ПО всю необходимую функциональность соответствующего уровня. Более реалистично оп ределить требования к ПО до составления подробных планов и приня тия определенных обязательств. Тем не менее стратегия «дизайн по расписанию» может сработать, если менеджеру проекта удастся дого вориться с заказчиком, какая часть желаемой функциональности удов летворит его в указанные сроки. Как и всегда, расстановка приорите тов требований — ключевой фактор для успеха проекта.

Для сложных систем, в которых ПО является лишь частью конечного продукта, детальные графики, как правило, составляются после раз работки требований на уровне продукта (системы) и предварительно го определения архитектуры. На этом этапе ключевые даты поставки могут быть определены и согласованы на основе информации из таких источников, как отдел маркетинга, отдел продаж, отдел по работе с клиентами и разработчики.

Рассмотрите возможность поэтапного планирования и финансиро вания проекта. На стадии первоначального изучения требований вы получите достаточно информации, чтобы составить реалистичные планы и расчеты для одного или более этапов сборки. Проекты, требо вания к которым сформулированы нечетко, выиграют в случае поэтап ного цикла разработки. Эта модель позволит разработчикам присту пить к созданию качественного ПО задолго до полного выяснения тре бований. Расставив приоритеты требований, вы сможете определить очередность включения функциональности на каждом этапе.

Часто причина неудачи проекта по разработке ПО кроется в том, что разработчики и другие участники проекта плохо составляют планы, а не в том, что они плохие специалисты. К главным ошибкам планирова ния относятся пропуск стандартных задач, недооценка затрат или сро ков, а также проектных рисков, необоснованный оптимизм. Кроме то го, не забудьте учесть возможные переделки. Эффективное планиро вание проекта предполагает наличие следующих элементов:

Часть II. Разработка требований к ПО оценку размера продукта;

информацию о производительности специалистов, основанную на прошлом опыте;

список задач, которые необходимы для полной реализации или проверки функции или варианта использования;

требования с приемлемым уровнем стабильности;

опыт, который позволит менеджеру проекта учесть нематериальные факторы и индивидуальные особенности каждого проекта.

Не поддавайтесь давлению и не принимайте на себя невыполнимых Ловушка обязательств. Это верный путь к неудаче.

От требований - к дизайну и коду Граница между требованиями и дизайном не четкая, однако постарай тесь не делать в ваших спецификациях упор на реализацию, кроме тех случаев, когда имеется веская причина для намеренного ограничения дизайна. В идеале на описание предполагаемых функций системы не должно влиять представление о дизайне (Jackson, 1995). Надо при знать, что во многих проектах учитываются ограничения дизайна, на лагаемые разработанными ранее продуктами, а совместимость с пре дыдущими продуктами — самое стандартное требование. Именно по этому в спецификации к требованиям практически всегда содержится некоторая информация о дизайне. Однако в спецификации не должны содержаться случайные элементы дизайна —то есть ненужные или не запланированные ограничения конечного дизайна. Подключите дизай неров или разработчиков к экспертизе требований, чтобы удостове риться, что требования могут служить надежной основой для дизайна, Требования к продукту, атрибуты качества и характеристики пользо вателей влияют на архитектуру продукта (Bass, Clements и Kazman, 1998). Изучая предлагаемую архитектуру, вы рассмотрите разные точ ки зрения, что поможет вам проверить требования и отшлифовать их точность, как и при использовании прототипов. Оба метода базируют ся на следующем посыле: «Если я правильно понимаю требования, то способ, который я сейчас проверяю, позволит удовлетворить их. Те перь же, когда у меня в руках предварительная архитектура (или про тотип), поможет ли это мне лучше разобраться в требованиях?» Глава 17. От разработки требований - к следующим этапам Архитектура особенно важна для систем, в которые входят компо ненты ПО и оборудования, а также для сложных систем, состоящих ис ключительно из ПО. Важный этап анализа требований — распределе ние высокоуровневых требований к системе по различным подсисте мам и компонентам. Системный инженер, аналитик или архитектор классифицирует требования к системе по их принадлежность к функ циональным и требованиям к оборудованию (Lettingwell и Widrig, 2000).

Трассируемая информация позволяет разработчикам отследить, в ка ких элементах дизайна будет отражено каждое требование.

В результате неверного распределения решений может статься, что ПО, определенное как функциональное, следовало бы назначить ком понентам оборудования (или наоборот);

кроме того, в таком случае возможна низкая производительность или трудности при замене не коего компонента для улучшения версии. При разработке одного про екта инженер по оборудованию сообщил моей группе, что в нашем ПО должны быть преодолены все ограничения, налагаемые его дизайном оборудования! Хотя ПО само по себе более гибко, чем оборудование, инженерам не следует использовать это качество, чтобы сэкономить на дизайне оборудования. Воспользуйтесь приемом проектирования и создания программ, чтобы выработать оптимальные решения того, ка кие возможности каждый системный компонент будет удовлетворять в рамках заданных ограничений.

Распределение системных функций по подсистемам и компонентам надо выполнять «сверху вниз» (Hooks и Farry, 2001). Представьте DVD проигрыватель, в который входит мотор, открывающий и закрываю щий лоток дисковода и вращающий диск, оптическая подсистема для считывания данных с диска, ПО для формирования изображений, мно гофункциональный пульт дистанционного управления и многое дру гое, как показано на рис. 17-3. Подсистемы взаимодействуют для управления поведением в таких случаях, когда, скажем, пользователь нажимает кнопку на пульте дистанционного управления, чтобы от крыть лоток дисковода во время проигрывания диска. В таких сложных продуктах требования к системе влияют на дизайн архитектуры, а ар хитектура в свою очередь влияет на распределение требований.

При разработке некоторых проектов дизайн ПО немного изменяется, тем не менее на дизайн время никогда не бывает потрачено зря. Разно образные разработки ПО удовлетворяют большинству требований к продукту. Они различаются по производительности, эффективности и устойчивости к сбоям, а также по использованным техническим мето дам. Если вы перескакиваете от требований к коду, это означает, что вы по существу разрабатываете ПО «на лету». Вы разрабатываете какой-то Часть II. Разработка требований к ПО дизайн, но обязательно идеальный, вероятный результат в этом случае — плохо структурированное ПО. Переделывая код, вы, конечно же, улучшите дизайн (Fowler, 1999), однако унция заранее разработан ного дизайна стоит фунта переделок уже выпущенного продукта. Про думав альтернативы дизайна, вы будете уверены, что разработчики бу дут принимать во внимание любые указанные ограничения дизайна.

Рис. 17-3. Такие сложные продукты, как DVD-проигрыватели, содержат множество подсистем ПО и оборудования Невероятно уменьшившийся проект Как-то я занимался проектом, имитирующем поведение фотографической системы с помощью восьми вычислительных процессов. После скурпулезного анализа тре бований команде не терпелось приступить к написанию кода. Но вместо этого нам пришлось создавать модель - в тот момент мы больше думали о создании реше ния, а не пытались разобраться в проблеме. Мы быстро поняли, что в трех этапах моделирования использовались идентичные вычислительные алгоритмы, в трех других применялся еще один набор алгоритмов, а в остальных двух - третий набор.

Взгляд с позиций дизайна позволил упростить проблему и уменьшить число слож ных вычислений с восьми до трех. Начни мы кодировать сразу же после анализа требований, в какой-то момент мы бы без сомнения обнаружили повторение кода, но мы сэкономили массу времени, выявив их гораздо раньше. Изменение моделей дизайна намного более эффективно, чем переделка кода!

Как и в случае с требованиями, отличный дизайн — это результат итераций. Многократно прорабатывайте дизайн для уточнения перво начальной концепции по мере получения информации и появления до полнительных идей. При недостатках в дизайне появляются продукты, которые трудно обслуживать и расширять, которые не удовлетворяют пожеланиям клиентов в отношении производительности, легкости и простоты использования и надежности. Время, затраченное на преоб разование требований в дизайн, — это отличная инвестиция в созда ние высококачественных и надежных продуктов.

Глава 17. От разработки требований - к следующим этапам Вам не нужно разрабатывать полный подробный дизайн всего про дукта до начала реализации, однако следует выполнить дизайн каждо го компонента до того, как вы приступите к его реализации. Планиро вание дизайна наиболее полезно для особенно трудных проектов, где разрабатываются системы со множеством внутренних граничащих и взаимодействующих друг с другом компонентов, а также тех, которы ми занимаются неопытные разработчики (McConnell, 1998). Однако проекты любого типа выиграют, если вы:

I разработаете надежную архитектуру подсистем и компонентов, ко торая выдержит будущие изменения;

1 определите ключевые классы объектов или функциональные моду ли, которые необходимо создать, определив их интерфейсы, функ ции и взаимодействия с другими элементами;

I разберетесь, как выполняются планируемые потоки или где разме щается функциональность в параллельных процессах для парал лельно работающих систем;

I определите предполагаемую функциональность каждой единицы кода, которая следует основному принципу дизайна: сильная свя занность, слабая связь и сокрытие информации {McConnell, 1993);

S убедитесь, что в дизайн включены все функциональные требования и что он не содержит ненужной функциональности;

1 удостоверитесь, что дизайн учитывает все условия исключения, ко торые могут возникнуть;

1 убедитесь, что дизайн будет отвечать заданным критериям произ водительности, устойчивости к сбоям, надежности и др.

По мере преобразования требований в дизайн и код разработчики сталкиваются с определенными неясными и запутанными местами. В идеале они могут обратиться к клиентам или аналитиками за разъяс нениями. Если же проблему нельзя решить немедленно, любые пред положения, догадки или интерпретации разработчики должны задоку ментировать и отправить на просмотр представителям клиента. Если таких проблем много, значит, требования сформулированы недоста точно ясно и детально до того, как аналитик передал их разработчи кам. Просмотрите остальные требования вместе с одним или несколь кими разработчиками и уточните их, прежде чем продолжите сборку продукта. Также пересмотрите процессы утверждения требований, чтобы выяснить, как получилось так, что требования низкого качества попали к разработчикам.

Часть II. Разработка требований к ПО От требований ~ к тестированию Тестирование и разработка требований связаны синергетически. Со гласно мнению консультанта Dorothy Graham: «Чем лучше требовании, тем качественнее тесты;

чем качественнее анализ тестирования, тем лучше требования» (Graham, 2002). Требования обеспечивают основу для тестирования системы. Продукт следует тестировать на соответ ствие тому, что он, как записано в требованиях, должен делать, а не на предмет дизайна или кода. Тестирование системы, выполненное на основе кода, может стать накликанной бедой. Продукт может с вести себя именно так, как описано в вариантах тестировании, созданных н;

а основе кода, но это не означает, что он соответствующим образом реализует пользовательские или функциональные требования. Под ключите тестеров к экспертизе требований, чтобы убедиться, что тре бования поддаются проверке и могут служить основой для тестирова ния системы.

Что тестировать?

Участник семинара как-то заметил: «Я работаю в группе тестирования. У нас нет на писанных требований, поэтому мы должны протестировать систему на предмет то го, что она с нашей точки зрения должна делать. Иногда мы ошибаемся, тогда мы узнаем у разработчиков, каковы функции системы, и тестируем ее снова». Тестиро вание того, что разработчики создали, - не то же самое, что тестирование того, что они должны были создать. Требования - это конечный документ для системных и пользовательских проверочных испытаний. Если требования к системе сформулиро ваны плохо, то тестеры обнаружат множество предположений, реализованных раз работчиками. Некоторые из них отражают соответствующие решения разработчи ков, другие же отшлифованы или неверно истолкованы. Аналитик должен включить предположения и их источники в спецификацию требований к ПО, чтобы провести будущее повторное тестирование более эффективно, Тестеры проекты должны определить, как они будут проверять каж дое требование. Возможных методов несколько:

1 тестирование (выполнение ПО с целью поиска дефектов);

1 экспертиза (проверка кода на предмет его соответствия требованиям);

i демонстрация (демонстрация того, что продукт работает, как ожи далось);

I анализ (обоснование того, как система должна работать при опре деленных условиях).

Глава 17. От разработки требований - к следующим этапам Само по себе обдумывание того, как проверить каждое требование, является ценным приемом работы над качеством. Используйте такие приемы анализа, как графики типа «причина— результат», чтобы со ставить варианты тестирования на основе логики, описанной в требо вании (Myers, 1979). При этом обнаруживаются неясности, пропуски или предположения и другие проблемы. Необходимо, чтобы каждое функциональное требование можно было проследить по крайней мере до одного варианта тестирования в системном тестовом наборе, для того чтобы ни одна ожидаемая реакция системы не осталась непрове ренной. Вы можете измерить прогресс тестирования по частям, высчи тывая процент требований, которые прошли проверку. Опытные тесте ры могут обогатить тестирование, основанное на требованиях, допол нительными тестами, основанными на истории продукта, предполага емых сценариях использования, общих характеристиках качества и слу чайностях.

В тестировании на основе требований применяются различные стратегии тестирования: зависящие от выполняемых действий, отдан ных (включая анализ значений границ и разбиения на эквивалентные классы), от логики, от событий и от состояния (Poston, 1996). Можно ге нерировать варианты тестирования автоматически, используя офици альную спецификацию, однако если вы будете использовать более рас пространенные спецификации к требованиям, составленные на есте ственном языке, вам придется разрабатывать варианты тестирования вручную.

По мере продвижения разработки команда будет конкретизировать требования от высоких уровней абстракции, как, например, в вариан тах использования, через детализированные функциональные требо вания к ПО к спецификациям для отдельных модулей кода. Авторитет ный специалист в области тестирования Boris Beizer (1999) подчерки вает, что тестирование на основе требований должно выполняться на каждом уровне конструирования ПО, а не только на конечном пользо вательском уровне. Масса кода в приложении не доступно пользовате лям напрямую, однако он необходим для внутренних взаимодействий.

Каждый модуль должен удовлетворять собственной спецификации, даже если функция этого модуля невидима для пользователя. Как следствие, тестирование системы на основе пользовательских требо ваний — необходимая, но не достаточная стратегия тестирования сис темы.

Часть II. Разработка требований к ПО От требований - к успеху Недавно я наблюдал такую ситуацию: разработчики-контрактники при соединились к проекту для реализации приложения, требования для которого писала друга команда. Новички только взглянули на дюжину трехдюймовых переплетов документации по требованиям, вздрогнули от ужаса и начали программировать. В ходе сборки они не обращались к спецификации. Вместо этого они построили то, что, по их мнению, задумывалось, основываясь на неполном и неточном понимании буду щей системы. Неудивительно, что возникло множество проблем. Пер спектива разбираться в массе даже самых совершенных требований без сомнения приводит в уныние, но игнорирование требований — это верный путь к провалу проекта. Гораздо быстрее прочитать требова ния, какими бы объемными они не были, до реализации, чем создавать ненужную систему, а затем переделывать ее. Еще лучше собрать раз работчиков в начале проекта, чтобы они смогли поучаствовать в рабо те над требованиями и уже тогда создать прототипы.

Практика более успешного проекта такова: составлялся список все< требований, которые были включены в определенную версию. Группа контроля качества проекта (quality assurance, QA) оценивала каждую версию, тестируя все требования. То из них, которое не удовлетворяло критериям тестирования, считалось ошибочным. Группа контроля ка чества откладывала выпуск версии, если не было удовлетворено коли чество требований, превышающее заранее оговоренное, или крайне важные требования. В основе успеха проекта лежало использование:

документированных требований для принятия решения о готовности версии к выпуску, Конечным, подлежащим сдаче продуктом считается система ПО;

отвечающая потребностям и ожиданиям клиента. Требования являют ся важным этапом на пути от бизнес-потребностей до удовлетворен ных клиентов. Если в основе ваших планов проекта, дизайна ПО и сие темного тестирования не лежат высококачественные требования, ве роятнее всего вам придется затратить много усилий на создание качественного продукта. Однако не становитесь и рабом требований, Не имеет смысла тратить массу времени на создание ненужной доку ментации и проведение ритуальных встреч, если при этом не создает ся ПО и проект закрывается. Попытайтесь достичь разумного баланса между доскональной спецификацией и кодированием «из головы» — это снизит до приемлемого уровня риск создания ненадлежащего продукта.

Глава 17. От разработки требований - к следующим этапам 33S Что теперь?

1 Попробуйте отследить все требования в реализованной части спецификации требований к ПО до отдельных элементов дизайна. Это можно отразить в моде лях потока данных, таблице в диаграмме «сущность - связь», объектных классах или методах или других элементах дизайна. Недостающие элементы дизайна могут указывать на то, что разработчики выполнили всю свою работу в уме, пе рейдя сразу от требований к коду. Если разработчики нерегулярно занимаются дизайном, прежде чем приступить к написанию кода, возможно, их следует обу чить дизайну ПО.

I Запишите количество строк кода, функциональных точек, классов объектов или элементов пользовательского интерфейса, которые необходимы для реализации каждой функции продукта или варианта использования, Укажите вашу оценку за трат, необходимых для полной реализации и проверки каждой функции или ва рианта использования, а также реальные затраты. Выявите взаимосвязи размера продукта и затраченных усилий - это поможет вам выполнить более точные рас четы для будущих спецификаций к требованиям.

I Рассчитайте средний процент незапланированного роста проекта для нескольких пхледних проектов. Можете ли вы включить резерв для непредвиденных обстоя тельств в график проекта для учета такого увеличения объема в будущих проекта?

Используйте данные об увеличении объема из предыдущих проектов для объяс нения этого резерва, чтобы он не выглядел как произвольное решение для ме неджеров, клиентов и других заинтересованных лиц.

340 Часть II. Разработка требований к ПО Ill Принципы и приемы управления требованиями к ПО В главе 1 говорилось, что разработку технических условий можно раз делить на разработку требований и управление требованиями. Стадия разработки подразумевает сбор информации, анализ, уточнение и ут верждение требований. Как правило, она заканчивается созданием па кета документов;

документа об образе и границах продукта, докумен тации к вариантам использования, спецификации требований к ПО, словаря данных и соответствующих моделей анализа. После проверки и одобрения этот пакет определяет базовую версию требований, со глашение между разработчиками и клиентами. Вероятно, входе разра ботки заключаются и дополнительные соглашения, касающиеся гото вого продукта, ограничений, графиков, бюджета или контрактных обя зательств;

но эти темы выходят за рамки данной книги.

Соглашение по требованиям является связующим звеном между раз работкой и управлением требованиями. У членов команды должен быть доступ к текущим требованиям на протяжении всего проекта, возможно, через Web-решения посредством инструментов управления требования ми. Под управлением требованиями подразумевают все действия, под держивающие целостность, точность и своевременность обновления со глашения о требованиях в ходе проекта. Как показано на рис. 18-1, это:

I управление изменениями базовой версии требований;

1 поддержание планов проекта актуальными в соответствии с меняю щимися требованиями;

I управление версиями отдельных требований и документации тре бований;

I контроль состояния требований в базовой версии;

i управление логическими связями между отдельными требования ми и другими материалами для работы с проектом.

Часть III. Управление требованиями к ПО предложение определение схемы эпределение определение связей изменений идентификации версии возможных состояний анализ влияния определение версий требований требованиями изменений спецификации фиксирование эпределение связей принятий решений состояния с другими 1ЭНИЙ обновление 31 ре деление версий каждого треба аания элементами системы документации этдельных требований отчет о распреде требований лении статуса всех обновление планов требований измерение изменчивости требований Рис. 18-1. Основные составляющие управления требованиями Разработчики, принимающие предлагаемые изменения требова ний, не всегда способны соблюдать текущий график и выполнять обя зательства, касающиеся качества. Менеджер проекта должен обгово рить изменения этих обязательств с другими менеджерами, работаю щими над проектом, клиентами и всеми заинтересованными в проекте лицами. Введение новых или изменение существующих требований влияет на проект следующим образом:

1 откладывается реализация требований низших уровней;

1 приглашаются новые специалисты;

I на короткий период времени вводится режим сверхурочной работа, по возможности оплачиваемой;

I в соответствии с новой функциональностью изменяется график;

1 страдает качество, так как необходимо уложиться в график (слии ком часто это реакция по умолчанию).

Ни один из этих способов нельзя назвать идеальным для всех случа ев, поскольку гибкость проектов зависит от функций, опыта специали стов, бюджета, графика и качества (Wiegers, 1996a). При принятии ре шений полагайтесь на приоритеты, установленные при планировании проекта ключевыми фигурами из тех, кто заинтересован в проекте. Не зависимо от того, какова будет ваша реакция на корректировку требо ваний, при необходимости примите как данность изменения ожиданий и обязательств. Это гораздо лучше, чем надеяться, что каким-то об разом к принятой в начале проекта дате выпуска все новые функции Глава 18. Принципы и приемы управления требованиями к ПО появятся в продукте, причем без таких последствий, как перерасход бюджета или переутомление команды.

В этой главе рассматриваются основные принципы управления тре бованиями. В других главах части III некоторые приемы управления требованиями описываются более подробно, в том числе изменение управлением (глава 19), анализ влияния изменений (также глава 19) и контроль за требованиями (глава 20). Завершается часть III обсужде нием коммерческих средств, с помощью которых команда управляет требованиями (глава 21).

Базовая версия требований Базовая версия (baseline) — это набор функциональных и нефункцио нальных требований, которые разработчики обязались реализовать в определенной (выбранной) версии. Определение базовой версии по зволяет заинтересованным в проекте лицам выработать общее пони мание возможностей и свойств, которые они хотят видеть в данной версии. Принятая базовая версия требований — как правило, версия становится базовой после официальных экспертизы и утверждения — предается для управления конфигурацией. Последующие изменения разрешается вносить в нее только через определенный в проекте про цесс управления изменениями. До принятия базовой версии требова ния все еще изменяются, поэтому не имеет смысла ограничивать мо дификацию какими-то процедурами. Однако начинайте контролиро вать версии, уникальным образом идентифицируя разные версии каждого документа требований, сразу после того, как сделаете пред варительный набросок этого документа, С практической точки зрения, положения в базовой версии должны отличаться от предложенных, но не принятых требований, Необходи мо, чтобы основная версия спецификации требований к ПО содержала только те требования, которые запланированы для конкретного выпус ка. Этот документ должен быть ясно определен как базовый, чтобы от личать его от серии выполненных ранее набросков версий, которые еще не утверждены. Сохранение требования в средстве управления требованиями облегчает идентификацию требований, принадлежа щих определенной базовой версии, и управление изменениями в ней.

В этой главе описываются некоторые способы управления требова ниями в базовой версии.

Часть III. Управление требованиями к ПО Процедуры управления требованиями Необходимо определить действия, которые, как ожидается, проектная команда будет выполнять для управления требованиями. Задокумен тируйте эти действия и организуйте тренинг для специалистов, чтобы сотрудники организации могли выполнять их последовательно и эф фективно. Обратите внимание на следующее:

1 на инструменты, приемы и соглашения для управления версиями различных документов требований и отдельных требований;

I на то, как составляется базовая версия требований;

I на статус требований, которые будут использоваться, и лица, котс рые имеют право изменять их;

I на процедуры контроля за статусом требования;

1 на способы, с помощью которых новые требования и изменения су ществующих требований предлагаются, обрабатываются, обсужда ются и передаются всем заинтересованным лицам;

I на методы анализа влияния предложенного изменения;

I на то, как на планах и обязательствах проекта отразятся изменения требований.

Вы можете включить всю эту информацию в одно описание процес са управления требованиями. Или же разработать отдельные процеду ры для контроля за изменениями, анализа влияния и контроля за со стоянием. Эти процедуры следует довести до сведения каждого со трудника организации, поскольку они представляют общие функции, которые должны выполняться каждым проектной командой.

Дополнительная информация В главе 22 описано несколько полезных образ цов документов для управления требованиями.

Кто-то должен выполнять действия при управлении требованиями, поэтому в описаниях процесса также следует определить роли участ ников, ответственных за выполнение каждой задачи. Проектный анали тик требований, как правило, несет основную ответственность за управление требованиями. Он выбирает механизм сохранения требо ваний (например, средство управления требованиями}, определяет ат рибуты требований, скоординирует обновление данных о состоянии и трассируем ости требований и сгенерирует отчеты об изменении дей ствий.

Глава 18. Принципы и приемы управления требованиями к ПО Ловушка Если никто из участников проекта не несет ответственности за выпол нение этапов управления требованиями, не следует ожидать их выполнения.

Контроль версий «Я наконец доделала функцию запроса по каталогу различных поставщиков, — сообщила Шери на еженедельной встрече, посвященной состоянию проекта Chemical Tracking System. Вот это была работа!» «О, клиент отказался от этой функции две недели назад, — по дал реплику менеджер проекта Дейв. — Ты разве не получила новую версию спецификации?» Шери была озадачена. "Как это понимать, отказался? Эти тре бования черным по белому напечатаны вверху страницы 6 са мой последней версии моей спецификации».

«Мм, их нет в моей копии. У меня версия 7.5 спецификации. А у тебя?» «У меня тоже 1.5, —с отвращением сказала Шери. — Эти доку менты должны быть идентичны, но очевидно, это не так. И что, эта функция все еще включена в базовую версию или я потра тила впустую 40 часов моей жизни?» Если вы когда-либо слышали подобный разговор, вы знаете, как рас страиваются люди, когда тратят впустую время, работая над устаревши ми или непоследовательными требованиями. Контроль версий— это важный аспект управления спецификациями требований и другими про ектными документами. Каждой версии следует присвоить уникальный идентификатор. У каждого члена команды должен быть доступ к текущей версии требований, а изменения необходимо ясно документировать и передавать всем заинтересованным сторонам. Чтобы минимизировать путаницу, конфликты и непонимание, назначьте право обновления тре бований строго определенным лицам и убедитесь, что идентификатор версии изменяется при каждом изменении требования.

Часть III. Управление требованиями к ПО Это не ошибка, а функция!

Разработчики-контрактники как-то получили массу отчетов об ошибках от людей, тестировавших последнюю версию систему, которую они только что поставили кли енту. Разработчики были в недоумении - система успешно прошла все их собствен ные проверки. После обстоятельного изучения проблемы, выяснилось, что клиенты тестировали новое ПО, сверяясь с устаревшей спецификацией требований. То, что тестеры в отчетах называли ошибками, на самом деле оказалось функциями. (В обычной ситуации это просто шутка, из тех, что любят программисты.} Масса уси лий была потрачена впустую, поскольку тестеры неправильно представляли себе по ведение системы. Им понадобилось много времени, чтобы переписать тесты в соот ветствии с последней версией спецификации и повторно протестировать продукт, а все из-за контроля версий.

Каждая версия документа требований должна содержать историю переработки, где указываются внесенные изменения, дата каждого из них, лицо, внесшее изменение, а также причина. Возможно, следует добавлять номер версии к названию каждого отдельного требования, который можно последовательно увеличивать при модификации тре бований, например Print.ConfirmCopies-1, Простейший механизм управления версиями — именовать вручную каждую версию спецификации требований к ПО согласно соглашению.

Попытка различать версии документов по дате изменения или дате пе чати часто приводит к ошибкам и неразберихе;

я не рекомендую их ис пользование. Несколько команд, в которых я работал, успешно приме няли такое соглашение: первая версия любого нового документа назы вается «Версия 1.0, набросок 1». Следующий черновик называется «Версия 1.0, набросок 2». Автор последовательно увеличивает номер наброска при каждом изменении и так до тех пор, пока документ не бу дет утверждена базовая версия документа. Тогда название меняется на «Версия 1.0, утвержденная». Следующие версии называются «Вер сия 1.1, набросок 1» при небольшом изменении или «Версия 2.0, на бросок 1» при значительном изменении. (Разумеется, термины «не большой» и «значительный» субъективны или, по крайней мере, зави сят от контекста.) При применении этой схемы ясно различаются наброски и версии базового документа, однако необходимо соблю дать строгий порядок в ведении документации.

Если вы сохраняете требования в текстовом редакторе, вы можете отследить коррективы с помощью режима изменений текста. Эта функция выделяет внесенную правку, зачеркивая удаленные фрагмен ты, подчеркивая добавленные и помечая вертикальными линиями на Глава 18. Принципы и приемы управления требованиями к ПО полях положение каждого изменения. Так как откорректированный до кумент трудно читать, в текстовом редакторе предусмотрена возмож ность просмотреть и распечатать документ с пометками или его окон чательную версию с принятой правкой. После того как вы составите базовую версию документа с такими пометками, сначала создайте ар хив версии с пометками, затем примите все коррективы, а затем со храните очищенную версию как новую базовую версию для следующе го раунда изменений.

Более сложный метод предполагает сохранение спецификации тре бований в таком средстве контроля версий, как тот, что применяется для контроля исходного кода с помощью системы контроля версий (check-in и check-out}. Для этой цели разработана масса коммерче ских средств управления конфигурацией. Я знаю об одном проекте, когда несколько сотен написанных в Microsoft Word вариантов исполь зования продукта сохраняется в таком средстве контроля версий. Чле ны команды имеют доступ ко всем предыдущим версиям каждого ва рианта использования, для которых фиксируется история изменений.

Аналитику требований этого проекта и его заместителю, отвечающему за архивирование, предоставлен доступ на чтение и запись;

осталь ным членам команды — доступ только на чтение.

Наиболее надежный метод контроля версий заключается в хране нии требований в базе данных коммерческого средства управления требованиями, как описано в главе 21. Эти средства отслеживают пол ную историю изменений требований, что особенно важно, если нужно вернуться к более ранней версии требования. Такое средство позво ляет вносить комментарии, где можно разумно обосновать решение о добавлении, изменении или удалении требования;

эти комментарии могут оказаться полезными при необходимости обсуждения требова ния в будущем.

Атрибуты требований Представьте себе каждое требование в виде объекта, который облада ет свойствами, отличающими его от других требований. В дополнение к тестовому описанию, каждое функциональное требование должно иметь несколько поддерживающих его фрагментов информации, или атрибутов (attributes), связанных с ним, Эти атрибуты представляют содержимое и поднаготную каждого требования, они располагаются за описанием предполагаемой функциональности. Вы можете сохра нить атрибуты в таблице, базе данных или, что наиболее эффективно, Часть III. Управление требованиями к ПО в средстве управления требованиями. Последние предоставляют не сколько сгенерированных системой атрибутов, а также предоставляют возможность определить другие атрибуты. Эти средства позволяют фильтровать, сортировать выбранные подмножества требований на основании значений их атрибутов и запрашивать базу данных для и:< просмотра. Например, вы можете вызвать список всех высокоприори тетных требований, которые Шери должна реализовать в версии 2.3 и которые имеют статус Approved (Одобрено).

Большой набор атрибутов особенно важен для громадных и слож ных проектов. Возможно, вам следует указать для каждого требования такие атрибуты, как:

I дата создания требования;

I номер его текущей версии;

i автор требования;

1 лицо, ответственное за удовлетворение требования;

I ответственный за требование или список заинтересованных лиц (чтобы принимать решения о предложенных изменениях);

I состояние требования;

I происхождение или источник требования;

I логическое обоснование требования;

I подсистема (или подсистемы), для которых предназначено требо вание;

i номер версии продукта, для которого предназначено требование;

1 используемый метод проверки или критерий тестирования прием лемости;

i приоритет реализации;

1 стабильность (показатель того, какова вероятность изменения тре бования в будущем;

нестабильность требований может показывать плохо определенные или изменчивые бизнес-процессы или биз нес-правила).

Для чего же нужно это требование?

Менеджер продукта в компании, выпускающей электронные измерительные прибо ры, хотел просто записать включенные требования, потому что продукт конкурентов обладал теми же функциями. Такие функции хорошо отмечать с помощью атрибута Rationale (Логическое обоснование), позволяющего указать, почему конкретное тре бование включено в продукт.

Глава 18. Принципы и приемы управления требованиями к ПО Выберите наименьший набор атрибутов, с помощью которого вам удастся эффективно управлять проектом, Например, вряд ли вам одновременно потребуются и имя того, кто отвечает за требование, и название подсистемы, в которой расположено требование. Если ка кая-либо информация об атрибуте хранится в другом месте, например в общей системе контроля разработки, не следует копировать его в базе данных требований.

Ловушка Множество атрибутов требований могут настолько озадачить разработ чиков, что они просто не смогут предоставить все значения для всех атрибутов и эффективно использовать информацию об атрибутах. Начните с трех или четырех ключевых атрибутов. Добавьте другие атрибуты, когда вы будете знать, каким обра зом они улучшат ваш проект.

Основные версии требований динамичны. Набор требований, за планированный для определенной версии, будет изменяться по мере добавления новых положений и удаления или отсрочки до более позд них версий существующих требований. Разработчики могут ^жонгли ровать» отдельными документами требованиями для текущего проек та и будущих версий. Управление этими изменяющимися базовыми версиями и спецификацией требований на их основе— нудное дело.

Если отложенные требований или те, от которых вы решили отказать ся, остаются в спецификации требований, читатели спецификации мо гут запутаться в том, какие требования включены в конкретную базо вую версию. Однако вам вряд ли захочется тратить много времени впустую, перетаскивая требования из одной спецификации требова ний в другую. Один из способов решения этой проблемы — сохранить требования в средстве управления требованиями и определить атри бут Release Number (Номер версии). Отсрочка требования означает изменение его запланированного выпуска, поэтому просто обновив номер версии, вы передвинете требование в другую базовую версию.

Теми требованиями, от которых вы решили отказаться, лучше всего управлять с помощью атрибута статуса, как описано в следующем раз деле.

На определение и обновление этих атрибутов требуется часть за трат, отведенных на управление требованиями, однако эти инвестиции в значительной степени окупаемы. В одной компании периодически генерировался отчет о требованиях, в котором показывалось, какое из 750 требований в трех связанных спецификациях назначено каждому дизайнеру. Один из дизайнеров обнаружил несколько требований, ко торые он не считал своими. Он рассчитал, что сэкономил от одного до Часть III. Управление требованиями к ПО двух месяцев, отведенных на переделку дизайна, которые бы понадо бились, если бы он выяснил ситуацию с этими требованиями позднее.

Контроль статуса требований "Как движется работа над той подсистемой, Джеки», — спро сил Дейв.

"Довольно хорошо, Дейв. Готово около 90%».

Дейв был озадачен: "А разве пару недель назад ты не сделала примерно 90%?» Джеки ответила: «Я думала, что да, но теперь эти 90% дейст вительно готовы».

Иногда разработчики ПО слишком оптимистичны, когда сообщают об окончании задачи. Часто они выдают сами себе кредит, считая выпол ненными те задачи, к которым они приступили, но еще не закончили.

Они могут сделать первоначально определенную работу на 90%, а за тем столкнуться с непредвиденными трудностями. Тенденция пере оценивать выполнение работе приводит к ситуации, типичной для всех проектов по разработке ПО или крупных задач, когда в течение долгого времени сообщается, что выполнено 90% объемов. Контроль статуса каждого функционального требования на протяжении всей разработки позволяет более точно оценивать готовность проекта. Ожидание же «выполнения задач» означает только повторы. Например, вы плани руете реализовать в следующей версии только часть варианта исполь зования, оставив полную реализацию до будущих версий. В этом слу чае вы будете отлеживать состояние тех функциональных требований, которые запланированы для ближайшей версии, поскольку этот набор требований должен быть выполнен на 100% до выпуска продукта.

Ловушка Существует старая шутка, что на первую половину проекта по разра ботке тратится 90% ресурсов, а на остальную половину - оставшиеся 90% ресур сов. Чересчур оптимистичная оценка и попустительское отношение к контролю статуса - верный путь к перерасходам в проекте.

В таблице 18-1 перечислено несколько возможных состояний тре бований. (Альтернативная схема показана в Caputo, 1998.) Некоторые специалисты добавляют состояние Designed (Разработано) (если эле менты дизайна, в которых отражены функциональные требования, Глава 18. Принципы и приемы управления требованиями к ПО созданы и проверены) и Delivered (Выпущено) (ПО отдано в руки поль зователей, как для бета-тестирования). Полезно отслеживать требо вания, от которых вы отказались, и причины этого, потому что отверг нутые требования имеют обыкновение «всплывать» в ходе разработки.

Статус Rejected (Отклонено) позволяет оставить предложенное требо вание доступным для будущего использования, не создавая беспоряд ка в наборе утвержденных требований для определенного выпуска.

Распределение требований по нескольким категориям состояния имеет больший смысл, чем попытка контролировать процент заверше ния каждого требования или всей базовой версии. Определите, кто может изменить состояние требования, и обновляйте статус, только когда удовлетворены определенные условия перехода. Изменение со стояния также ведет к обновлению данных о трассируемости требова ний, когда указывается, в каких элементах дизайна, кода и тестирова ния отражено требование (табл. 18-1).

Таблица 18-1. Рекомендуемые состояния требования Определение Состояние Требование запрошено авторизированным источником Proposed (Предложено) Approved (Одобрено) Требование проанализировано, его влияние на проект про считано, и оно было размещено в базовой версии опреде ленной версии. Ключевые заинтересованные в проекте лица согласились с этим требованием, а разработчики ПО обязались реализовать его Implemented (Реализовано) Код, реализующий требование, разработан, написан и про тестирован. Требование отслежено до соответствующих элементов дизайна и кода Verified (Проверено) Корректное функционирование реализованного требования подтверждено в соответствующем продукте.Требование отслежено до соответствующих вариантов тестирования.

Теперь требование считается завершенным Deleted (Удалено) Утвержденное требование удалено из базовой версии.

Опишите причины удаления и назовите того, кто принял это решение Rejected (Отклонено] Требование предложено, но не запланировано для реализа ции ни в одной будущих версий. Опишите причины отклоне ния требования и назовите того, кто принял это решение 352 Часть III. Управление требованиями к ПО На рис. 18-2 показано, как контролировать состояние требования в гипотетическом 10-месячном проекте: на графике показано, сколько процентов требований к системе в каждом состоянии имеется в кон не каждого месяца. Обратите внимание, что при этом не устанавливав" ся, изменяется ли со временем количество требований в базовой вер сии. Кривые иллюстрируют, как достигается такая цель проекта, как полная проверка всех утвержденных требований. Основная часть ра боты считается выполненной, когда всем требованиям назначено со стояние Verified (Проверено) (реализуется, как запланировано) или Deleted (Удаленщ) (удалено из базовой версии).

— Proposed (Предложено) - - Approved (Одобрено) —— Implemented (Реализовано) - - Verified (Проверено) -- Deleted (Удалено) 1 2 3 4 5 6 Месяц Рис. 18-2. Контроль состояния требований для цикла разработки проекта Измерение усилий, необходимых для управления требованиями Как и при разработке требований, в ваш план проекта должны быть включены задачи и ресурсы для выполнения задач по управлению тре бованиями, описанные в этой главе. Если вы выясните, сколько усилий тратится на управление требованиями, вы сможете оценить — мало их, как надо или слишком много — и изменить рабочие процессы и бу дущие планы соответствующим образом.

35:;

Глава 18. Принципы и приемы управления требованиями к ПО В организации, где никогда не измерялась ни одна из сторон рабо ты, как правило, трудно контролировать, как члены команды тратят их рабочее время. Для измерения непосредственных усилий на разра ботку и управление проектом необходимо заняться корпоративной культурой и дисциплиной сотрудников — только так удастся фиксиро вать ежедневную работу. На это уходит не так много времени, как мно гие боятся, Команда сможет получить ценные идеи, поняв, как на са мом деле тратятся усилия на различные задачи проекта (Wiegers, 1996а). Обратите внимание, что рабочие усилия — это не то же самое, что прошедшее календарное время. Выполнение задач может преры ваться или возникает необходимость переговорить с другими людьми, что ведет к задержкам. Прилагаемые усилия, необходимые для выпол нения задачи и измеряемые в человеко-часах, не обязательно изме нятся из-за этих факторов, однако продолжительность выполнения за дачи увеличится.

Контроль усилий также позволяет выяснить, выполняют ли разра ботчики предполагаемые задачи для управления требованиями. Не удача в управлении требований увеличивает риск появления неуправ ляемых изменений и требований, по неосторожности пропущенных к ходе реализации. Считайте усилия для выполнения следующих дейст вий усилиями для управления требованиями:

I предложение изменения требований и новых требований;

1 оценка предложенных изменений, включая оценку влияния измене ния;

1 изменение работы совета по управлению;

В обновление документации требований или базы данных;

I сообщение об изменениях требований заинтересованным группам и отдельным лицам;

I контроль и отчет о состоян ии требования;

1 сбор информации о трассируемости требований.

Управление требованиями помогает убедиться, что усилия, затра ченные на сбор, анализ и документацию требований не потрачены впустую. Например, если вы не сможете своевременно обновлять на бор требований в соответствии с вносимыми изменениями, то заинте ресованным в проекте лицам будет трудно представить функциональ ность в каждой версии. Эффективное управление требованиями может уменьшить неверные ожидания: заинтересованные лица будут проин формированы о текущем состоянии требований в ходе процесса раз работки.

Часть III. Управление требованиями к ПО Что теперь?

I Определите схему контроля версий для определения документации требований.

Задокументируйте схему как часть процесса управления требованиями.

I Выберите состояния, которые вы хотите использовать для описания жизненного цикла функциональных требований. Нарисуйте диаграмму перехода состояний, чтобы показать условия, вызывающие изменения одного состояния на другое.

1 Определите текущее состояние для каждого функционального требований в базовой версии. Обновляйте состояние по мере разработки.

1 Опишите процессы, которым будет следовать ваша организация для управления требованиями а каждом проекте. Попросите нескольких аналитиков нарисовать, просмотреть, попробовать выполнить и одобрить действия и результаты. Этапы процесса, которые вы определите, должны быть практичными и выполнимыми, и они должны добавлять определенную ценность проекту.

Глава 18. Принципы и приемы управления требованиями к ПО Изменения случаются '•Как продвигается разработка, Гленн?» — спросил Дейв, ме неджер проекта Chemical Tracking System на совещании, по священному состоянию проекта.

"Я не так далеко продвинулся, как рассчитывал, — признался Гленн. — Сейчас я добавляю новую функцию запроса в катало ге для Шэрон, и это требует намного больше времени, чем я предполагал».

Дейв был озадачен. «Я не помню, чтобы мы обсуждали новую функцию запроса каталога на недавней встрече совета по управлению изменениями. Шэрон подала этот запрос через процесс контроля изменений?» «Нет, она обратилась ко мне напрямую с этим предложением, — сказал Гленн. — Мне следовало попросить ее оформить его, как официальный запрос на изменение, но все выглядело на столько просто, что я сказал ей, что поработаю над этим. Вы яснилось, что не все так просто. Каждый раз, когда мне кажет ся, что закончил, я понимаю, что я пропустил изменение, кото рое должно быть в другом файле, поэтому мне приходится исправлять это, собирать компонент и заново тестировать его.

Я думал, мне хватит шести часов, однако я уже потратил на это четыре дня. Вот почему я не закончил другие, запланирован ные, задачи. Знаю, что задерживаю следующую сборку. Мне закончить с этой функцией или заняться тем, над чем я рабо тал раньше?» Большинство разработчиков сталкивались с простыми на первый взгляд изменениями, которые оказывались более сложными, чем они ожидали. Разработчики иногда не выполняют — или не могут выпол Часть III. Управление требованиями к ПО нить — реалистичные расчеты затрат и других последствий предло женного изменения ПО. И когда разработчик, который хочет быть любезным, соглашается добавить улучшение, запрашиваемое пользо вателем, требования изменяются через «заднюю дверь», а не утверж даются заинтересованными лицами, которые имеют на это право. Tsi кие неконтролируемые изменения — повсеместный источник хаоса в проекте, нарушения графика и проблем с качеством, особенно если работа ведется на нескольких участках или проект выполняет сторон няя организация. Организация, серьезно относящаяся к управлению своими проектами по разработке ПО, должна убедиться, что:

i предложенные изменения требований тщательно оценены до их в вода в дело;

I соответствующие лица принимают бизнес-решения, будучи хорошо информированными о запрошенных изменениях;

I одобренные изменения доведены до сведения всех участников проекта;

i изменения требований, внесенные в проект, согласованы друг о другом.

Изменение ПО само по себе неплохое дело. Виртуально определить все требования к продукту практически невозможно, а по мере про гресса изменяются и сопутствующие обстоятельства. Эффективная команда разработчиков ПО быстро отреагирует на необходимые ИЗ' менения, чтобы продукт, который они создают, был своевременно по ставлен клиентам.

Однако у изменений всегда есть цена. Простая Web-страница кор ректируется быстро и легко;

новшества же в дизайне интегрированной микросхемы могут обойтись в десятки тысяч долларов. Даже на откло нение запроса на изменение тратятся ресурсы, необходимые для по дачи, оценки и принятия решения. Если заинтересованные в проекте лица не управляют изменениями в ходе разработки, им вряд ли из вестно, что именно будет получено в результате, а это неизбежно ве дет к расхождениям в ожиданиях. Чем ближе выпуск версии, тем боль ше вам следует противиться желанию внести изменения в эту версию, поскольку последствия изменений становятся все более серьезными.

Обязанность аналитика требований — включить утвержденные из менения в проектную документацию требований, Принцип все тот же:

документация требований должна точно описывать поставляемый продукт. Если вы не будете обновлять спецификацию требований по мере разработки продукта, его ценность будет снижаться, и команде придется работать таким образом, как будто бы у нее вообще нет ника кой спецификации.

Глава 19. Изменения случаются Если вам нужно внести изменение, начните с наивысшего уровня абстракции, затрагиваемого этим изменением, и далее влияйте на ос тальные компоненты системы через связанные с ним системные ком поненты. Например, предложенное изменение может повлиять на ва риант использования и его функциональные требования, однако никак не затронет ни одно бизнес-требование. Изменение требования к сис теме высокого уровня может воздействовать на множество требова ний к ПО. Некоторые изменения касаются только внутренних компо нентов системы, так, например, реализуется уровень взаимодействия.

Они невидимы для пользователя и скорее относятся к изменениям ди зайна или кода.

Если разработчик реализует изменение требования напрямую в ко де, не пропуская его через описание требований и дизайна, возможны проблемы. Описание функций продукта, как оно приведено в специ фикации требований, становится менее точным, поскольку код— это конечная реальность ПО. Код может стать неустойчивым и хрупким, если изменения вносятся без соотношения с архитектурой и структу рой дизайна. В одном проекте разработчики ввели новую и изменили существующую функциональность, о чем остальные члены команды не знали до тестирования системы. При этом понадобилась незаплани рованная переработка процедур тестирования и пользовательской до кументации. Последовательные приемы контроля изменений помога ют предотвратить такие проблемы, а также связанные с этим рас стройства, переделки и трату времени на тестирование.

Управление незапланированным ростом объема Capers Jones (1994) сообщает, что незапланированный рост объема ставит под удар:

I 80% проектов по разработке систем управления информацией;

1 70% проектов по разработке военных систем ПО;

9. 45% проектов по созданию ПО, выполняемых по контракту.

Незапланированным изменением требований считается предложе ние новой функциональности и существенной модификации после ут верждения базовой версии требований к проекту. Чем дольше продол жается работа над проектами, тем больше их объем. Требования к сис теме управления информацией, как правило, увеличиваются на 1% в месяц (Jones, 1996b). Темп прироста может составлять до 3,5% в ме Часть III. Управление требованиями к ПО сяцдля коммерческого ПО, при этом темпы роста других типов проек тов входят в этот показатель. Проблема заключается не в изменении требований, а в том, что запоздалые изменения значительно влияют на уже выполненную работу. Если каждое предложенное изменение одобряется, то тем, кто финансирует проект, его участникам и клиен там может казаться, что проект никогда не будет завершен — и дейст вительно, такая возможность существует, Определенные изменения требований абсолютно приемлемы, не избежны и даже благоприятны. Бизнес-процессы, рыночные возмож ности, конкурирующие продукты, и технологии — все они могут ме няться в ходе разработки продукта, и менеджеры могут определить, как в ответ на эти изменения необходимо откорректировать направле ние работы. Неуправляемый рост объема, при котором в проект посте янно включается новая функциональность без учета ресурсов, графика или целей качества, гораздо коварнее. Небольшая модификация здесь, неожидаемое улучшение там, и скоро нет никакой надежды раз работать продукт соответствующего качества, который клиенты ожи дают к определенному сроку.

Первый шаг при управлении незапланированным ростом объема — документирование образа, границ и ограничений новой системы, ка< части бизнес-требований (см. главу 5). Оценивайте каждое предло женное требование или функцию, соотносясь с бизнес-целями, обра зом продукта и границами проекта. Если задействовать клиентов к сборе информации, то снижается количество требований, упущенных из внимания, которые приходится добавлять к задачам команды поели того, как обязательства приняты, а ресурсы распределены (Jones, 1996а). Составление прототипов — это еще один эффективный прием управления незапланированным ростом объема (Jones, 1994). Прото тип позволяет предварительно реализовать продукт, что помогает раз работчикам и пользователям прийти к общему пониманию нужд поль зователей и необходимых решений. Короткие циклы разработки при инкрементальной разработке системы позволяют вносить изменение часто, это особенно полезно, когда требования неясные или быстро изменяются (Beck, 2000).

Наиболее эффективный прием для управления незапланированным ростом объема— это умение сказать: «Нет» (Weinberg, 1995). Люди в принципе не любят отказывать, а разработчиков могут прессинговать по поводу каждого предложенного требования. Такие принципы, как "Клиент всегда прав» и «Мы сделаем все, чтобы клиент остался дово лен», звучат прекрасно в теории, однако за их выполнение нужно пла тить. Игнорируя это, вы никак не измените тот факт, что коррективы Глава 19. Изменения случаются не могут произойти просто так. Президент одной компании, специали зирующейся на поставке программного обеспечения, привык слышать от менеджера по разработке в ответ на предложение новой функции:

«Не сейчас». «Не сейчас»,— звучит более привлекательно, чем про стой отказ. В этом слышится обещание включить функцию в следую щие версии. Включение каждой функции, запрашиваемой клиентами, специалистами отдела маркетинга, менеджерами продукта и разра ботчиками, приводит к размыванию обязательств, снижению качества, истощению разработчиков и созданию ПО с избыточной функциональ ностью. Клиенты не всегда правы, но в их высказываниях всегда есть смысл, поэтому фиксируйте их идеи — возможно, их стоит включить в последующие версии.

В идеальном мире вам удастся собрать все требования к новой сис теме до начала сборки, и они останутся стабильными в течение всей разработки. Это основа последовательной или водопадной модели разработки ПО, но на практике так не бывает. На определенном этапе вам необходимо «заморозить» требования до определенной версии или вам никогда не удастся получить результат. Однако, если вы при остановите работу над требованиями слишком рано, то вы проигнори руете то обстоятельство, что клиенты не всегда уверены в том, что именно им нужно;

клиентам понадобились изменения, и разработчи кам необходимо отреагировать на это. Для каждого проекта следует предусмотреть включение определенных изменений в проект, но кон тролируемым способом.

Ловушка «Заморозить» требования для новой системы после выполнения пер воначального сбора информации - не умно и не практично. Лучше опредепите ба зовую версию, когда решите, что требования достаточно хорошо определены, что бы начать дизайн и сборку, а затем управляйте неизбежными изменениями, чтобы минимизировать их негативное влияние на проект.

Процесс контроля изменений Как-то, оценивая процесс разработки ПО, я спросил специалистов, ра ботающих над проектом, как они включают изменения в требования к продукту. После неловкой паузы, один из них сказал: «Каждый раз, ко гда специалист отдела маркетинга хочет внести изменение, он обра щается к Брюсу или Сэнди, потому что они всегда соглашаются, а мы нет». Эта процедура внесения изменений не показалось мне хорошей.

Часть III. Управление требованиями к ПО Процесс контроля изменений позволяет руководителю проекта принимать информированное бизнес-решение, которое удовлетворя ет клиента и имеет коммерческую ценность, при этом контролируются затраты на жизненный цикл продукта. Вы можете отслеживать статус всех предложенных изменений и убедиться, что предложенные требо вания не были потеряны или упущены. После утверждения базовой версии набора требований придерживайтесь этого порядка для внесе ния всех предлагаемых изменений в нее.

Клиенты и другие заинтересованные лица часто уклоняются от но вого процесса, однако процесс контроля изменений — не препятствие для модификации. Это механизм суммирования и фильтрации, даю щий уверенность, что в проект включены наиболее ценные изменение.

Если предложенное изменение не настолько важно, чтобы заинтере сованное в проекте лицо потратило пару минут на передачу его через стандартные, простые каналы, то стоит задуматься о его ценности во обще. Процесс управления должен быть тщательно задокументиро ван, максимально прост и, что важнее всего, эффективен.

Ловушка Если вы предложите заинтересованным лицам новый процесс контро ля изменений - неэффективный, громоздкий или слишком сложный, они постара ются найти способ избежать этого - и, возможно, будут правы.

Контроль изменений требований схоже с процессом сбора и приня тия решений по отчетам об ошибках. Эти же средства могут поддержи вать обе задачи. Однако следует помнить: инструмент не заменяет процесс. Использование коммерческого средства отслеживания про блем для управления предложенными изменениями требований не за менит описание процесса, где объясняются содержимое и обработка запроса на изменение.

Политика контроля изменений Руководство должно ясно довести до сведения сотрудников политику, в которой описываются ожидания того, как участники проекта должны обрабатывать предложенные изменения требований. Политики имеют смысл, только если они реалистичны, добавляют ценность и проводят ся в жизнь. Я обнаружил, что могут быть полезными следующие поло жения политики контроля изменений:

В все изменения требований должны вноситься в соответствии с про цессом. Если запрос на изменение подается каким-то иным спосо бом, он не рассматривается;

Глава 19. Изменения случаются i нельзя заниматься дизайном или реализовать неутвержденные из менения, кроме проверки их осуществимости;

I сам по себе запрос на изменение не гарантирует выполнение этого изменения. Совет по управлению изменениями проекта (change control board, CCB) решает, какие изменения следует реализовать.

(Мы поговорим о совете по управлению изменениями проекта да лее в этой главе.);

i содержимое базы данных изменений должно быть видимым для всех заинтересованных в проекте лиц;

1 первоначальный текст запроса на изменение не должен изменяться или удаляться;

i анализ влияния изменения необходимо выполнять для каждого из менения;

i каждое включенное изменение требования должно отслеживаться вплоть до утверждения запроса на это изменение;

1 обоснование каждого утверждения или отклонения запроса на из менение необходимо документировать.

Разумеется, мелкие изменения вряд ли повлияют на проект, а суще ственные воздействуют довольно сильно. В принципе, любые из них следует обрабатывать с помощью процесса контроля изменений. На практике вы можете делегировать принятие определенных детальных решений, касающихся требований, разработчикам, однако ни одно ре шение, влияющее на работу более чем одного человека, не должно ид ти в обход процесса контроля изменений. Однако процесс должен предлагать «быстрый путь», чтобы ускорить не рискованные и деше вые изменения в сжатом цикле принятия решений.

Ловушка Разработчики не должны использовать процесс контроля изменений как барьер для задержки выполнения каких-либо изменений. Если изменение неизбежно - работайте над ним.

Описание процесса контроля изменений На рис. 19-1 показан шаблон описания процесса контроля изменений для обработки модификаций требований и других изменений проекта.

Вы можете загрузить его образец с http://www.processimpact.com/goo dies.shtml. Далее речь пойдет в основном о том, как процесс будет об рабатывать изменения требований. Я считаю полезным включить сле дующие четыре компонента во все процедуры и описания процесса:

362 Часть III. Управление требованиями к ПО входной критерий — условия, которые должны быть удовлетворены до выполнения процесса или процедуры;

различные задачи, задействованные е процессе или процедуре, участник проекта, отвечающий за выполнение каждой задачи, и другие лица, принимающие участие в выполнении задачи;

последовательные действия для подтверждения того, что задачи были выполнены правильно;

выходной критерий — условия, указывающие, когда процесс или процедура считаются успешно завершенными.

1. Введение 1.1. Назначение 1.2. Границы 1.3. Определения 2. Роли и ответственности 3. Состояние запроса на изменение 4. Входной критерий 5. Задачи 5.1. Оценка запроса 5.2. Принятие решения 5.3. Внесение изменения 5.4. Уведомление всех задействованных лиц 6. Проверка 6.1. Проверка изменения 6.2, Установка продукта 7. Выходной критерий 8. Отчет о состоянии контроля изменений Приложение. Элементы данных, сохраненные для каждого запроса Рис. 19-1, Пример шаблона описания процесса контроля изменений 1. Введение Во введении описывается назначение процесса и определяются орга низационные границы, в которых он применяется. Если этот процесс затрагивает только изменения в определенных продуктах, их следует определить здесь. Также укажите, существуют ли какие-то специаль ные виды изменений, которые не подлежат контролю, например изме нения в промежуточных или служебных продуктах, созданных в ходе проекта. В разделе 1.3 определите все термины, необходимые для по нимания остальной информации, Глава 19. Изменения случаются 2. Роли и ответственности Перечислите членов команды — по ролям, не по именам, которые уча ствуют в процессе контроля изменений, и опишите их обязанности. В табл. 19-1 приведены некоторые типичные роли;

адаптируйте их в со ответствии с конкретной ситуацией. Каждый человек может выполнять несколько ролей. Например, председатель совета по управлению из менениями также может получать подаваемые запросы на изменения.

В небольших проектах несколько, а возможно, и все роли выполняют ся одним человеком.

Таблица 19-1. Возможные роли участников проекта при управлении изменениями Описание и ответственность Роль Председатель совета Возглавляет совет по управлению изменениями;

как правило, обладает правом принятия окончательного решения, если совет по управлению измене не приходит к согласию;

выбирает тех, кто оценивает и вносит ниями изменения для каждого запроса на изменение Группа, принимающее решение утвердить или отклонить каждое Совет по управлению изменениями предложенное изменение для определенного прооекта Тот, кто оценивает Человек, которого председатель совета просит проанализи изменение ровать влияние предложенного изменения;

это может быть сотрудник технического отдела, клиент, маркетолог или сотруд ник, занимающийся всем этим понемногу Отвечает за внесение изменений в продукт, когда запрос Тот, кто вносит изменение на изменение утвержден Тот, кто инициирует запрос Некто, подающий новый запрос на изменение Получатель зал роса Лицо, которому передаются новые запросы на изменение Тот, кто проверяет изменение Человек, определяющий, корректно ли выполнено изменение 3. Состояние запроса на изменение Запрос на изменение проходит через определенные стадии на протя жении жизненного цикла, причем на каждой стадии он имеет различ ные статусы. Вы можете представить эти изменения состояния, ис пользуя диаграмму перехода состояний, как показано на рис. 19-2.

Обновляйте состояние запроса, только когда удовлетворяются опре деленные критерии.

364 Часть III. Управление требованиями к ПО Инициатор подает запрос на изменение Отравлен Тог, кто оценивает изменение, анализирует влияние изменения выполнена i решает не вносить Совет по управлению изменениями решает внести изменение, определяет версию и назначает ответственного за внесение изменения Изменение было отменено;

отменить внесение изменения Назначенный сотрудник Проверка выполнил изменение прошла неудачно и запросил проверку Изменение было отменено;

отменить внесение изменения Тот, кто проверяет изменение, подтвердил его I Проверка не понадобилась;

ответственный за внесение Поовевено _ Изменение было отменено;

изменения установил "~ отменить внесение изменения модифицированный продукт !

Ответственный за внесение изменения установил модифицированные продукты Ы Завершено Рис. 19-2. Диаграмма перехода состояний для запроса на изменение 4. Входной критерий Основным входным критерием для процесса контроля изменений яв ляется действительный запрос на изменение, полученный по утвер жденным каналам.

Глава 19. Изменения случаются Все потенциальные инициаторы запросов должны знать, как пода вать запросы на изменение, независимо от того, отправляют они его, заполняя бумажную форму или Web-форму, отправляя сообщение по электронной почте или используя средство контроля изменений. На значьте каждому запросу на изменение уникальный идентификатор и направьте их всех к единой точке контакта — получателю запроса.

5. Задачи Следующий шаг — это оценка запроса на предмет технической выпол нимости, затрат и соответствия бизнес-требованиям проекта и огра ничениям ресурсов. Председатель совета по управлению изменения ми может назначить сотрудника для оценки влияния изменения, ана лиза риска, анализа опасности и др. Анализ позволяет убедиться, что вероятные последствия изменения ясны. Тот, кому поручена оценка, и члены совета по управлению изменениями должны также рассмотреть коммерческие и технические последствия отклонения изменения.

Затем уполномоченные члены совета по управлению изменениями решают, утвердить или отклонить запрошенное изменение. Совет по управлению изменениями присваивает каждому одобренному изме нению уровень приоритета, или назначает дату реализации, или на значает это изменение определенной сборке или номеру версии. Да лее совет по управлению изменениями оповещает о решении, обнов ляя состояние запроса или уведомляя всех членов команды, которые занимаются модификацией. После этого необходимо обновить: доку ментацию требований, описание дизайна и моделей, компоненты пользовательского интерфейса, код, документацию тестирования, эк раны справки и руководства для пользователей. Тот, кто вносит изме нения, делает это установленным путем.

6. Проверка Изменения требования, как правило, проверяют с помощью эксперт ной оценки, чтобы убедиться, что измененные требования, варианты использования и модели соответствующим образом отражают все ас пекты изменения. Информация о трассируемости поможет вам найти все части системы, которые это изменение затрагивает и которые, как следствие, необходимо проверить. Поручите нескольким членам ко манды проверить изменения с помощью тестирования или эксперти зы. После этих процедур тот, кто занимается проверкой, устанавлива ет обновленные продукты, сделав их доступными остальным членам команды, и переопределяет базовую версию, в которой учтены изме нения.

Pages:     | 1 |   ...   | 4 | 5 || 7 | 8 |   ...   | 9 |



© 2011 www.dissers.ru - «Бесплатная электронная библиотека»

Материалы этого сайта размещены для ознакомления, все права принадлежат их авторам.
Если Вы не согласны с тем, что Ваш материал размещён на этом сайте, пожалуйста, напишите нам, мы в течении 1-2 рабочих дней удалим его.