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

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

Область процессов

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

CMMI-SE/SW

эта область подобна соответствующей области в

SW-

СММ.

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

должна приобретать понимание требований и разрешать

вопросы

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

управлять изменениями. В отличие от

SW-CMM,

трассирование тре-

бований включено в область процессов «Управление

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

Один из пяти практических приемов, имеющих отношение к управле-

нию

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

таков: «Поддерживайте двустороннее трассирова-

ние требований». Здесь обсуждаются три особенности трассиро-

вания:

1 обеспечение записи источников

низкоуровневых

или вторичных

требований;

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

ям, и его размещение по функциям, объектам, процессам и испол-

нителям;

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

принадле-

жащими к одному типу.

2. Область процессов

«Разработка требований»

CMMI-SE/SW

описаны три набора приемов разработки требований

1 приемы, определяющие полный набор требований клиентов,

кото-

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

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

нужды и ограничения в требования

клиентов);

1 приемы, определяющие полный набор требований для

продукпа

(установить компоненты продукта; разместить требования по

ком-

понентам продукта; определить требования к интерфейсу);

1 приемы получения вторичных требований, понимания требований

их подтверждения

(установить

оперативные концепции и сценарии;

определить требуемую функциональность системы;

проанализиро-

вать вторичные требования; оценить стоимость, сроки и риск соз-

дания продукта;

утвердить

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

Во всех

СММ

формулируются цели, к которым проект или

органи

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

Приложение Б 467

процессов. В них также рекомендуются технические приемы, помо-

гающие достичь этих целей. «Хорошие

приемы»,

описанные в этой ра-

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

низации достигать целей СММ в областях процессов управления тре-

бованиями и разработки требований. Каждая организация должна

выбрать соответствующие приемы и реализовать их в эффективные

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

Цель совершенствования процессов заключается не просто в нако-

плении процессов для

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

рекомендуемой

модели,

такой,

как СММ. Цель — уменьшить стоимость создания и сопровождения ПО

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

практику работающей над проектом команды. Сотрудники должны

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

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

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

нов, обучение и

учет,

чтобы

проверять,

исполняются

ли новые техноло-

гические

процессы,

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

зультаты. Для этого в обе СММ включены приемы, помогающие встро-

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

На рис. Б-1 показаны некоторые взаимосвязи между управлением

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

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

сов в

CMMI-SE/SW.

Эта диаграмма ясно

иллюстрирует,

что требования

существуют не в вакууме, но тесно связаны с другими процессами и

действиями проекта.

Рис.

Б-1.

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

областями процессов

BCMMI-SE/SW

468

Приложение Б

Руководство по поиску

и решению

проблем,

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

Действуя настойчиво, при взаимодействии различных заинтересован-

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

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

Следу-

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

блемы, связанные с требованиями, возникающими в ваших проектах.

После определения наиболее срочных проблем важно выявить основ-

ные причины каждой такой проблемы. Эффективные решения обра-

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

симптомам.

В табл.

В-1,

которая занимает почти все это приложение, перечис-

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

симп-о-

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

столкнуться. Симптомы дополнены описаниями соответствующих

воз-

можных основных причин и предложениями по решению каждой про-

блемы. Конечно, это не единственные

проблемы,

которые могут быть

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

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

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

решать их.

К сожалению, нет гарантии, что предложенные решения излечат

ва-

ши конкретные симптомы, особенно если вызывающие их

проблемы

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

причины лежат вне сферы действия команды разработчиков. И ни од-

но из этих решений не поможет, если вы имеете дело с

неразумными

людьми.

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

вают,

что действия, связанные с требованиями, идут в вашем

проекте

не так хорошо, как хотелось бы. Найдите в колонке «Симптомы»

что-либо,

469

похожее на обнаруженное вами. Затем изучите колонку «Возможные

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

блемы в вашей среде. Далее выберите

приемы

и подходы из колонки

^Возможные

решения»,

которые,

по вашему мнению, эффективно по-

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

и,

если все пойдет хорошо, позволят

решить проблему.

Анализ основных причин

Цель анализа основных причин

(root

case analysis) — определить вы-

зывающие эти симптомы факторы

посредством

трассирования сим-

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

изменить,

чтобы решить проблему. Анализ основных

причин

подразумевает по-

следовательность вопросов «Почему существует наблюдаемая про-

блема?»,

в которой каждый последующий вопрос задается в поисках

причины, стоящей за ответом на предыдущий,

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

симптомы и основные причины

взаимосвязаны,

так что один симптом

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

ных основных причин в области выявления требований, «отсутствуют

необходимые требования», в табл.

В-1

— это «аналитик требований не

задал правильных вопросов». Эта основная причина сама представля-

ет собой один из аспектов процесса выявления симптома «люди, ис-

полняющие роль аналитиков, не знают, как делать это хорошо».

Диаграмма причин и следствий (cause

and

effect diagram) — также

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

Ишикавы

по

имени ее автора, Каору Ишикавы (Kaoru

Ishikawa)

— это эффективный

способ описания результатов анализа основных причин. На рис. В-1

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

рует проблему постоянного нарушения графика командами одной ор-

ганизации. «Кости», отходящие от «позвоночника», показывают на диа-

грамме ответы на вопрос: «Почему команды не заканчивают проекты

вовремя?» Дополнительные «кости» показывают ответы на последую-

щие

«почему?».

В конечном итоге этот анализ раскрывает основные

причины на самых дальних ответвлениях «костей».

Вам не придется возиться с каждой основной причиной, которую вы

найдете с помощью подобного анализа. Принцип Парето (Pareto) фор-

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

«80/20»,

утверждающее, что около 20%

важных основных причин ведут к появлению примерно 80% проблем

(Schulmeyer

McManus,

1996). Даже простой анализ основных про-

470 Приложение В

блем,

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

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

совершен-

ствованию

требований.

Требования пропущены

во время

выявления

Программисты

занятых^,

исправлением

проблем,

вызванных

поздними

изменениями

в требованиях

для

предыдущего проекта

Проекты

Не получены дачные

от отобранных людей

Плохо определен рынок

Изменения в законодательстве

Не отработан

процесс_

контроля

изменений

Рис.

В-1.

Диафамма причин и следствий определяет основные

причины выявленных симптомов

не

заканчиваются

вовремя

Общие симптомы

проблем,

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

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

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

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

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

основные вопросы и оценить их решение. Вот некоторые типичные

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

1 нарушение графика и перерасход бюджета;

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

ет их ожиданиям;

1 продукт требует исправлений и «заплат» сразу после выпуска;

Приложение В

471

I разочарование членов команды, деморализация, утрата мотивации

и текучка кадров;

1 масса переделок;

I дублирование действий;

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

несе;

I потеря доли на рынке или доходов;

i возврат продукта или неприятие продукта рынком;

1 выпуск продукта с уменьшенным набором функций;

ПО, не поддающееся тестированию.

Общие препятствия для реализации решений

Любая попытка изменить способы работы

отдельных

людей или орга-

низаций встречает сопротивление. Определив, как исправить основ-

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

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

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

типичные

препятствия ра-

лизации изменений в требованиях:

1 нехватка времени (все и так слишком заняты); давление рынка, дик-

тующее быстрейший выпуск продукта;

недостаточная заинтересованность руководства в процессе конст-

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

1 общее сопротивление изменениям;

I скептицизм относительно ценности

конструирования

требований;

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

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

политика и устоявшаяся корпоративная культура;

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

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

1 недостаточное число ответственных лиц и плохая отчетность за

действия, связанные с требованиями;

1 недоступность квалифицированных

сторонников

продуктов;

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

кущими приемами работы с требованиями.

Обратите внимание, что эти вопросы

связаны

с людьми или переда-

чей информации, а не технические

препятсл

вия. Большинство препят-

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

шаг — признать их наличие.

472 Приложение В

Таблица

В-1.

Руководство

по поиску и решению проблем, связанных с требованиями

Симптомы

Возможные

основные причины

Возможные решения

Проблемы,

связанные

с процессами

Процессы работы

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

шаблоны докумен-

тов в различных

проектах

несовместимы

между собой.

Используемые

процессы работы с

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

неэффективны.

Отсутствие общего пони-

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

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

Отсутствие у руководства

заинтересованности в на-

личии эффективных про-

цессов работы с требова-

ниями.

Отсутствие механизма

совместного использования

шаблонов и документации

процессов.

Отсутствие хороших при-

меров шаблонов и доку-

ментации требований.

Люди, исполняю-

щие роли анали-

тиков, не знают, как

делать это хорошо.

Недостаток знаний о кон-

струировании требований и

роли аналитика требований,

Руководство считает, что

любой разработчик авто-

матически может стать

хорошим аналитиком.

Документируйте текущий

процесс работы с требова-

ниями и создайте описание-

предложение желаемого

процесса.

Обучите всех членов команды

конструированию требовании,

Примите один или несколькс

стандартных шаблонов

документа образа и границ

пректа,

примеров использо-

вания

и спецификации

требе

ваний к ПО. Обеспечьте

помощь для необходимой

подгонки шаблонов к кон-

кретному проекту.

Соберите и обеспечьте

доступ

к хорошим примерам

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

Используйте метрику исправ

ления дефектов, чтобы помочь

команде понять цену плохих

требований.

Используйте ретроспективу

проектов, чтобы зафикси-

ровать

примеры

текущих

проблем и их последствий.

Обучите будущих аналитиков

как

конструированию

требований, так и соответ-

ствующим особенностям

работы с ПО.

Напишите должностную инс-

трукцию и список необходимых

навыков для аналитиков

требований.

Организуйте

программу обу-

чения новых аналитиков.

Приложение В

473

Таблица

В-1.

Руководство по поиску и решению проблем, связанных с требованиями

(продолжение)

Симптомы

Возможные

основные причины

Возможные решения

Проблемы,

связанные с процессами

Инструментальные

средства управле-

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

используются

недостаточно.

1 Недопонимание

возмож-

ностей

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

средства.

Процессы и культура работы

не изменены для

извлечения

полной выгоды

из

инструментальных средств.

1 Нет ответственных

за внедрение инстру-

ментального средства, !

Отправьте нескольких анали-

тиков на тренинг, органи-

зованный производителем

инструментального средства.

! Определите сторонника

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

для обеспечения его

внедрения

и помощи другим

пользователям.

Выявите и измените особен-

ности процессов и

культуры,

препятствующие

исполь-

зованию инструментального

средства в полной мере.

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

Недовольные

клиенты.

Клиенты отвергают

продукт, как только

увидели его.

Плохой анализ

продукта.

Низкие продажи,

потеря доли рынка.

Недостаточное вовлечение

пользователей в разработку

требований.

Нереалистичные ожидания

клиентов.

Разработчики создавали

продукт на основе своих

догадок о желаниях

клиентов.

Клиент

не знает о возмож-

ностях и ограничениях

разработчиков и технологий.

Несоответствие между

пониманием требований

клиентами и разработ-

чиками.

Недостаточное исследо-

вание рынка.

Соберите

фокус-группы.

Определите классы

пользователей.

Определите сторонников

продукта.

Приведите ожидания клиентов

в соответствие с бизнес-

целями.

Создавайте прототипы и

просите

пользователей

оценивать их.

Используйте совместные

семинары для выявления

требований.

Привлеките представителей

клиентов к участию в экспер-

тизе документации

требований.

474

Приложение В

Таблица

В-1.

Руководство по поиску и решению проблем, связанных с требованиями

(продолжение)

Симптомы Возможные

основные причины

Возможные

решения

Проблемы, связанные с планированием

Требования

неполны,

Требования

недостаточно

детализированы.

Конструирование

следующего выпус-

ка

начинается до то-

го, как требования

для него поняты в

достаточной мере.

Недостаточное вовлечение

пользователей

в разработку

требований.

Разработке требований уде-

ленно недостаточное время,

Установка даты выпуска вер-

сии до определения требо-

ваний, возможно, в связи со

спешкой, вызванной юриди-

ческими причинами или реа-

лиями рынка.

Маркетологи или бизнес-

мены,

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

в продукте, не вовлечены

в процесс работы над

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

Аналитики не

обладают

достаточными навыками

и опытом.

Команда думает, что начать

программировать более

продуктивно, чем понять

требования.

Руководство или клиенты не

понимают необходимости в

требованиях.

У аналитиков и разработ-

чиков нет единого мнения

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

Не принимайте решений

о сроках выпуска до того,

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

ными в достаточной мере.

На ранних стадиях стадиях

проекта привлеките техни-

ческий персонал, чтобы он

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

Тщательн»олределите

образ

и границы продукта.

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

в проекте лицам риски,

связан-

ные с поспешным конструиро-

ванием.

Добивайтесь,

сотрудничества

между

аналитиками,

разработ

чиками

бизнес-партнерами,

чтобы те ставили реалистич-

ные цели.

Усильте полномочия

аналитик,!

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

Используйте метрику исправ-

ления дефектов, чтобы

помоч.

команде понять цену плохих

требований.

Используйте подходы инкре-

ментального моделирования,

чтобы быстро начать

выпускать

продукт, имеющий ценность

для

клиента.

Разработчики должны оце-

нивать качество требований

прежде, чем реализовать их.

Приложение В

475

Таблица

В-1.

Руководство по поиску и решению проблем, связанных с

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

(продолжение)

Симптомы

Возможные

основные причины

Возможные решения

Проблемы,

связанные с планированием

Серьезные изме-

нения

сроках пос-

ле начала проекта,

но без сокращения

масштабов.

Пробелы в работе

над

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

Несколько человек

совершают одни и

те же манипуляции

над требованиями.

Планируется

больше требова-

ний, чем

позволяют

сроки и ресурсы.

Заинтересованные в проекте

лица не понимают влияния

сокращения сроков

на реализацию проекта

в полном объеме.

Нечеткое определение ролей

и обязанностей при кон-

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

Нет ответственного за управ-

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

График устанавливается

до того, как определены

требования.

Плохо определены

масшта-

бы проекта.

Неконтролируемый рост

масштабов проекта.

Не учитывается кривая

обу-

чения при обучении незнако-

мым технологиям или при

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

тальными средствами.

Для участия в проекте

недостаточно персонала.

Требованиям не

назначены

приоритеты.

Факторы риска преврати-

лись в

проблемы.

Обязательства по проекту

приняты до проведения

точной оценки масштабов.

Стройте

взаимоотношения

сотрудничества между ана-

литиками, разработчиками

бизнес-партнерами, чтобы

ставить реалистичные цели.

Договаривайтесь о компро-

миссах при изменении

ограничений проекта,

Определите роли и распреде-

лите обязанности по разработ-

ке требований и управлению

ими в каждом проекте.

Выделите необходимый

персо-

нал для эффективной разра-

ботки и управления требова-

ниями.

Вносите

действия, связанные

с требованиями, в планы и гра-

фики работы по проектам.

Прежде чем принимать обяза-

тельства

по проекту, докумен-

тируйте образ и границы про-

дукта в соответствии с бизнес-

целями.

График разработки составляй-

те на основе требований, воз-

можно,

на стадии первоначаль-

ного исследования требований,

Включите время на подготовку

и кривую обучения в график

работы.

Отделите исследование

технологий и продукта

от разработки продукта.

Определите приоритеты

требований.

Используйте инициативное

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

476

Приложение В