Вигерс Карл. Разработка требований к программному обеспечению

Подождите немного. Документ загружается.

системы. Оцените приоритет каждого нового

требования

по отноше-

нию к объему оставшейся работы, чтобы иметь возможность прини-

мать разумные решения о компромиссах.

Технически сложные функции. Оцените осуществимость каждого тре-

бования, чтобы определить те из них, реализация которых может

занять

больше времени, чем ожидается. Нам всегда кажется, что успех —

ря-

дом,

за углом, поэтому трассируйте статус проекта, чтобы следить

за

требованиями, реализация которых отстает от графика. Старайтесь

исправлять ситуацию как можно раньше.

Незнакомые технологии, методы, языки, инструменты или аппа-

ратное обеспечение. Не нужно недооценивать кривую обучения ра-

боте с новыми методами, необходимыми для удовлетворения некото-

рых требований. Выявляйте эти рискованные требования в начале

проекта и выделяйте достаточное время на фальстарты, обучениЕ!',

эксперименты и прототипирование.

Спецификация требований

Понимание требований. Различия в интерпретации требований

раз-

работчиками и клиентами ведут к расхождениям в ожиданиях, когда

произведенный продукт не способен удовлетворить нужды

клиентоЕк

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

тестировщиками и клиентами уменьшают этот риск.

Подготовленные,

опытные

аналитики требований могут задать клиентам верные

вопро-

сы и составить высококачественные спецификации. Модели и

прото-

типы, представляющие требования с разных точек зрения, также по-

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

Спешка, заставляющая пропускать пометки

«TBD».

Полезно выде-

лять области спецификации требований, которые требуют

доработк-1

специальными пометками, например

«TBD»,

но рискованно

начинать

конструирование, пока они не сняты. Записывайте имя человека, отве-

чающего за разрешение каждой неясности и планируемые сроки

раз-

решения.

Неоднозначная терминология. Создайте словарь для

определение

бизнес- или технических терминов, которые могут быть истолкованы

разными читателями по-разному. В частности, определите любые

термины, имеющие как общее, так и техническое или узкоспециальное

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

структуры данных. Экспертиза спецификации требований поможет уча-

стникам выработать общее понимание ключевых терминов и концепций.

Глава 23. Требования к

ПО

и управление риском 447

Включение дизайна в требования. Описание дизайна в специфика-

ции требований налагает ненужные ограничения на возможности, дос-

тупные разработчикам. А те сдерживают создание оптимальных конст-

рукций. Удостоверьтесь, что требования

описывают,

что необходимо

сделать для решения бизнес-проблемы, а не то, как это должно быть

сделано.

Утверждение требований

Неутвержденные требования.

Перспектива

утверждения длинной

спецификации требований пугает, как и мысль о написании вариантов

тестирования в самом начале процесса разработки. Тем не менее,

если вы подтвердите корректность и качество требований до начала

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

ределки на более поздних стадиях проекта. Выделите время и ресур-

сы на эти действия в план проекта. Обяжите представителей клиентов

участвовать в проверке требований, потому что только они могут су-

дить, удовлетворят ли сформулированные требования их нужды. Также

проводите пошаговые, неформальные экспертизы, чтобы выявлять

проблемы как можно раньше и дешевле.

Качество проверки. Если

проверяющие

не знают, как проводить экс-

пертизу документации требований и какие действия эффективны при

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

нов команды, которые будут участвовать в экспертизе. Пригласите че-

ловека с опытом проверки из вашей или сторонней организации для

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

тренировать участников.

Управление требованиями

Изменение требований. Вы можете уменьшить расползание границ

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

трольных точек для утверждения изменений.

Объединение

выявления

требований с существенным участием пользователей может сокра-

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

(Jones

1996а).

Ме-

тоды контроля качества, определяющие ошибки в требованиях на ран-

них стадиях, сокращают количество последующих модификаций. Что-

бы уменьшить влияние изменения требований, отложите реализацию

тех из них, которые, скорее всего,

изменятся,

пока они не будут опре-

делены, а также проектируйте систему, закладывая возможность лег-

кой модернизации.

Процесс изменения требований. Риск, связанный с тем, как проис-

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

448 Часть IV. Особенности реализации процесса построения требований

процесса изменений, использования неэффективных механизмов из-

менений и внесения коррективов без учета этого процесса. Развитие

культуры и дисциплины управления изменениями требует времени.

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

воздействия предлагаемых изменений, решения принимал совет по

управлению изменениями и

использовалось

инструментальное сред-

ство для поддержки определенной процедуры.

Нереализованные требования. Матрица трассируемое™ требова-

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

проектирования,конструирования

или тестирования.

Увеличение объема проекта. Если требования изначально плохо оп-

ределены, дальнейшее их выявление может увеличить объем проект

э.

Реализация нечетко определенных областей продукта

потребует

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

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

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

пользова-

теля.

Для смягчения этого риска планируйте жизненный

цикл,

состоя-

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

моделирования версий. Реализуйте базовую

функциональность

в пер-

вом выпуске и наращивайте способности системы далее,

Управление риском - ваш друг

Менеджер проекта может использовать управление риском, чтобы вы-

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

для проекта. Представьте себе менеджера нового проекта, озабочен-

ного привлечением нужных пользователей в выявление требований.

Если он умен, то сообразит, что это условие представляет собой

эле:-

мент риска, и внесет его в список, оценив его вероятность и

влияние,

основываясь на предыдущем

опыте.

Если по прошествии некоторого

времени пользователи все еще не вовлечены в работу над проектом,

риск возрастет и, может быть, даже уже угрожает успеху проекта. Мне

удавалось убеждать менеджеров отложить проект, когда не удавалось

привлечь достаточно представителей пользователей, приводя такой

аргумент; мы не должны впустую тратить деньги компании на заранее

обреченный проект.

Периодическое трассирование рисков позволяет менеджеру проек-

та знать масштабы угрозы от выявленных областей риска. Сообщайте

о недостаточно контролируемом риске вышестоящему руководству,

которое может принять решение исправить его либо продолжать рабо-

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

Глава 23. Требования к ПО и управление риском 449

открытыми и принимать обоснованные решения, даже если вам не

удается контролировать каждую неприятность, с которой может столк-

нуться ваш проект.

Что дальше?

Определите несколько угрожающих вашему

текущему

проекту рисков, связанных

с требованиями. Не обозначайте текущие проблемы как факторы риска, отме-

чайте только то, что еще не случилось. Документируйте риски,

используя

шаблон

на рис. 23-2. Предложите по крайней мере один возможный метод

смягчения

для каждого риска.

1 Проведите «мозговой штурм» риска с ключевыми

лицами,

заинтересованными в

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

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

нию и перемножьте эти величины для вычисления подверженности этому риску.

Отсортируйте список по уменьшению подверженности, чтобы определить пять

самых серьезных факторов риска, связанных с требованиями. Назначьте для ка-

ждого из них ответственного за исполнение

действий

по смягчению.

450 Часть IV. Особенности реализации процесса построения требований

Эпилог

Нет ничего более важного для успеха проекта по разработке ПО, чем

понимание того, что проблемы необходимо решать. Требования

со-

ставляют фундамент успеха. Если команде разработчиков и клиентам

не удастся достичь соглашения по поводу возможностей и характери-

стик продукта, то вероятнее всего вы получите такой результат, кото-

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

приемы разработки требований не так эффективны, как вам бы хоте-

лось, избирательно и вдумчиво воспользуйтесь теми методами, пред-

ставленными в этой книге, которые, как вы считаете, помогут вам.

Дчя

успешной разработки требований необходимо:

I вовлекать представителей клиентов как можно раньше и шире;

1 разрабатывать требования итеративно и

поступательно;

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

риться, что все понимают их;

9 убедиться, что все группы заинтересованных лиц считают требова-

ния полными и корректными;

9 контролировать внесение изменений в требования.

Изменять способы организации

разработки

требований трудно.

Также трудно признать, что применяемые сегодня методы не работают

так

хорошо, как хотелось

бы,

и просчитать, что следует изменить.

как

сложно выкроить время, чтобы обучиться новым технологиям, разра-

ботать процесс улучшения, опробовать и

настроить

его, а потом еще и

внедрить его на фирме. И какие аргументы вам придется искать, чтобы

убедить всех заинтересованных лиц в необходимости этих изменений.

Однако, если вы не измените способы работы, нечего надеяться, что

текущий проект окажется лучше предыдущего.

451

Успех процесса улучшения разработки ПО зависит от многих причин:

1 выявите болевые точки в организации;

1 сфокусируйте ваше

внимание

на нескольких проблемах за раз;

установите ясные цели и разработайте план действий для улучше-

ния процесса;

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

которые будут затронуты

изменениями;

1 убедите топ-менеджера, что процесс улучшений следует рассмат-

ривать как стратегические инвестиции в успешный бизнес.

Держите в памяти все эти принципы, и когда будете строить дорож-

ную карту реорганизации процесса разработки требований, и когда

начнете ваше путешествие. Выбирайте такие приемы, которые подхо-

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

вы активно применяете хорошие приемы и полагаетесь на здравый

смысл, вам удастся значительно улучшить процесс обработки требо-

ваний и получить все преимущества и выгоды, которые за этим следу-

ют. И запомните, что без прекрасных требований разрабатываемый

продукт выглядит, как коробка с шоколадом: вы не знаете, что обнару-

жите, открыв ее.

452 Эпилог

Приложение А

Самостоятельная оценка

применяемых вами приемов

работы с требованиями

Это приложение содержит двадцать вопросов, которые вы можете

ис-

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

и определения областей, которые стоит усилить. Копия этого теста

электронная таблица для анализа результатов доступны на

http://

www.processimpact.com/goodies.shtml. Выберите из четырех

воэмож

ных

вариантов ответа на каждый вопрос

тот,

который наиболее близко

описывает то, как вы в настоящее время решаете конкретную

проб

лему, связанную с требованиями. Если вы хотите оценить результаты

количественно, присваивайте 0 баллов за каждый ответ «а», 1 балл

за

каждый ответ «б», 3 балла за каждый ответ «в» и 5 баллов за каждый

от

вет

«г». Максимально возможное количество баллов — 100. В каждом

вопросе указана ссылка на

главу,

где

объясняется

тема вопроса.

Не стремитесь получить как можно больше баллов, этот тест позво-

лит вам определить новые приемы, полезные вашей организации. Не

все вопросы подходят к типу разрабатываемого вами ПО. Кроме

того

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

лезные подходы. Например, новейшие продукты, не имеющие анало-

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

требованиями,

со временем

меняющиеся вместе с концепцией продукта. Однако учитывайте, что

неформальные подходы к работе с требованиями увеличивают веро-

ятность значительных переделок. Большинство организаций получит

выгоду от применения методов, представленных ответами «в» и «г».

На результаты может повлиять ваш выбор людей, выполняющих

тест. Избегайте респондентов, которые вместо того, чтобы описать ре-

альную ситуацию в организации, учитывают корпоративную политику

или стараются дать те ответы, которые им кажутся «правильными»,

453

Как определяются, сообщаются и используются границы проекта?

[Глава 5]

а)

Человек,

задумавший продукт, общается с группой разработчи-

ков телепатически или вербально.

б) Где-то здесь у нас есть положение об образе проекта.

в) Мы составляем положение об образе и границах, устав проекта

или подобный документ на основе стандартного

шаблона.

Все

заинтересованные в проекте лица имеют доступ к этому доку-

менту.

г) Мы оцениваем все предлагаемые функции продукта и измене-

ния в требованиях, проверяя, попадают ли они в границы про-

екта, указанные в соответствующих документах.

2. Как выявляются и характеризуются группы клиентов продукта?

[Глава 6]

а) Разработчики догадываются, кто станет клиентами.

б) Отдел маркетинга думает, что знает кто станет клиентами.

в) Целевые группы клиентов и сегменты рынка определяют

ме-

неджеры на основе исследования рынка и нашей

существую-

щей базы пользователей.

г) Заинтересованные в проекте лица определяют четкие классы

пользователей, характеристики

которых

кратко записаны в до-

кументации требований к ПО,

3. Как вы получаете информацию от пользователей для требований?

[Глава

а) Разработчики уже знают, что создавать.

Маркетологи, менеджеры по продукту или менеджеры пользо-

вателей уверены, что способны выразить точку зрения пользо-

вателей.

в) Проводится анкетирование или опрос фокус-групп пользова-

телей.

г) В проекте участвуют конкретные представители различных

классов пользователей, наделенные конкретной ответственно-

стью обязанностями и полномочиями.

4. Насколько хорошо обучены и насколько опытны ваши аналитики

требований? [Глава 4]

а) Они — разработчики или бывшие пользователи, имеющие мало

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

требований к ПО.

454 . Приложение А

б) Разработчики, опытные пользователи или менеджеры проек-

тов, имеющие некоторый опыт конструирования

требований,

исполняют роль аналитиков.

в) Аналитики прошли обучение в течение нескольких дней и имеют

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

г)

У нас есть профессиональные бизнес-аналитики или конструк-

торы требований, имеющие подготовку и опыт в области прие-

мов проведения собеседования, ведения собраний групп и на-

писания технических текстов.

5. Как системные требования размещаются по программным частям

продукта? [Глава 17]

а) Предполагается, что ПО будет работать, несмотря на любые

недостатки оборудования.

б) Конструкторы ПО и оборудования обсуждают, какие подсисте-

мы должны выполнять конкретные функции.

в) Конструктор или архитектор системы анализирует системные

требования и решает, какие из них будут реализованы в каждой

подсистеме.

г}

Части системных требований размещаются по программным

подсистемам и трассируются до отдельных программных тре-

бований. Интерфейсы подсистем подробно определяются и

документируются,

6. Какие методы используются для понимания проблем клиента?

[Глава

а) Наши разработчики очень умные; они и так понимают все

про-

блемы.

б) Мы спрашиваем пользователей, что они хотят, а потом это

соз-

даем.

в) Мы обсуждаем с пользователями их бизнес-нужды и

системы,

с которыми они работают в настоящее время, а затем состав-

ляем спецификацию требований.

г) Мы наблюдаем за тем, как пользователи выполняют свои зада-

чи, моделируем их текущие рабочие процессы и узнаем,

чти

они собираются делать при помощи новой системы. В резуль-

тате становится ясно, как можно автоматизировать части их

бизнес-процессов и какие программные функции окажутся

наиболее ценными.

7. Какие приемы используются для выявления всех отдельных требо

ваний к ПО? [Главы 7 и 8]

Приложение А 455

а) Мы начинаем с общего

понимания,

пишем

код,

а потом моди-

фицируем его, пока все не получится.

б) Руководство или отдел маркетинга задает концепцию продук-

та, а разработчики пишут требования. Маркетологи говорят

разработчикам, не упустили ли те чего-либо. Если направление

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

этом разработчикам.

в) Представители отдела маркетинга или клиентов говорят разра-

ботчикам, какие функции и возможности должен содержать

продукт.

г) Мы проводим организованные собеседования или семинары

по выявлению требований с участием представителей

различ-

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

использования, чтобы понять цели пользователей, и выявляем

функциональные требования на основе вариантов использова-

ния.

8. Как документируются требования к ПО? [Главы 10 и

11]

а)

Наши требования к ПО складываются из воспоминаний очевид-

цев, электронных и голосовых сообщений и заметок, сделан-

ных во время собеседований и собраний.

б) Мы составляем описания в произвольной текстовой форме или

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

в) Мы записываем требования на структурированном естествен-

ном языке с последовательным уровнем детализации, в соот-

ветствии со стандартным шаблоном спецификации требований

к ПО. Иногда мы дополняем эти требования графическими мо-

делями анализа с применением стандартных пояснений.

г) Мы храним свои требования в базе данных или коммерческом

инструментальном средстве управления требованиями, а мо-

дели анализа — в коммерческом инструментальном средстве,

Вместе с каждым требованием хранятся несколько его атрибу-

тов.

Как выявляются и документируются такие нефункциональные тре-

бования, как атрибуты качества ПО? [Глава 12]

а)

что такое «Атрибуты качества

ПО»''

б) Мы проводим бета-тестирование, чтобы получить ответ поль-

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

в) Мы документируем некоторые атрибуты,

такие,

как

производи-

тельность, простота использования и требования к

защищен-

ности.

456 Приложение А