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

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

«Меня бесило, что

менеджер,

запросившая

Pharm-Simulatcr,

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

добавил Дэйв. — А

потом

помните

постоянный

поток запросов

на изменения от людей из ее отдела? Не

удивительно,

что про-

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

стоил

он почти в два раза дороже, чем планировалось. Если таксе

произойдет еще

раз,

меня наверно уволят».

У'Рамеша

родилось предложение,

«Можетбыть,

нам

нужно

со-

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

Pharn"-

Simulator,

чтобы попытаться избежать их сейчас. Я читал

ста-

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

ПО,

где

говорилось,

что мы должны выявлять

риск

с самого начала и выяснять, как

предотвратить

причинение им вреда проекту».

«Не уверен, что

стоит,

— возразил Дэйв. — Мы многому

научу-

лись на опыте

Pharm-Simulator,

так что, скорее всего, эти про-

блемы не возникнут снова. Этот проект — не настолько круп-

ный,

чтобы требовалось управлять рисками. Если мы выпишем

все проблемы, возможные при разработке Chemical Tracking

System, это будет выглядеть, как будто я не знаю, как

вести

проект. Я не хочу, чтобы в этом проекте кто-то думал о

плохом.

Мы должны планировать успех!"

Как показывают последние высказывания

Дэйва,

программные инже-

неры — вечные оптимисты. Мы часто ожидаем, что наш

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

прошлых проектах. Реальность такова, что десятки потенциальных

ло-

вушек могут замедлить или пустить под откос проект по

разработка

ПО. Вопреки убеждениям Дэйва, менеджеры проектов по

разработка

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

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

Риск (risk) — это условие, которое может повлечь какие-либо поте-

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

усло-

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

остава-

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

неблагоприятный

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

та или эффективность работы команды. Управление риском — лучшая

практика индустрии ПО (Brown, 1996) — это процесс выявления, оцен-

ки и управления риском до того, как он нанесет ущерб вашему проекту.

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

проблема, а не риск. Решайте текущие проблемы и вопросы, постоян-

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

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

Так как никто не может уверенно

предсказывать

будущее, управле-

ние

риском

— это способ минимизации

в*5роятности

потенциальных

проблем или ущерба от них. Управление риском означает работу над

потенциальной опасностью до того, как она перейдет в кризисную фа-

зу. Это улучшает вероятность успеха проекта и уменьшает финансовые

или другие последствия риска, которого

не

удастся избежать.

Риск,

лежащий вне сферы компетенции

командь*,

следует передать руково-

дству соответствующего уровня.

Поскольку требования так важны в

проектах

по созданию ПО, преду-

смотрительный менеджер уже на ранних

ст

адиях проекта выявит риск,

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

достаточно

агрессивно контроли-

ровать его. Распространенные факторы риска, связанные с требова-

ниями, включают неверное понимание

требований,

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

влечение пользователей, неточности или и

шенения

в масштабах и це-

лях проекта, и постоянно

изменяющиеся

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

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

связанным

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

в сотрудничестве с клиентами или их

представителями.

Совместное

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

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

нерство клиента и разработчика, о котором говорилось в главе 2.

Просто знать о факторах риска

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

чтобы они исчезли, и

поэтому в этой главе рассказано о краткой обучающей программе для

управления риском при создании ПО

(Wit-gers,

1998b). Позже в этой

главе я также перечислю несколько

факторов

риска, которые могут

поднять свои уродливые головы во

время

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

ний. Используйте эту информацию, чтобы

атаковать

риск, связанный с

требованиями, до того, как он нападет на ваш проект.

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

Проекты подстерегает масса рисков, помимо тех. что связаны с грани-

цами проекта и требованиями. Один из них — зависимость от внешних

элементов, таких, как субподрядчик или другой проект, предоставляю-

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

ектом на первое место выходят такие

виды

риска, как неточные

оцен-

ки, неприятие менеджерами точных оценок, недостаточная прозрач-

ность статуса проекта и текучка кадров. Технологический риск

представляет угрозу для очень сложных или использующих передовые

разработки проектов. Недостаток знаний - - тоже очень опасен: испол -

нители не обладают достаточным опытом работы с используемыми

438 Часть

IV.

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

технологиями или

областью

применения приложения. А

постоянно

из-

меняющиеся нормы законодательства могут разрушить и самые луч-

шие планы проектов.

Страшно! Именно поэтому все проекты должны серьезно восприни-

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

значит,

что необходимо исследовать го-

ризонт в поисках

айсбергов,

а не нестись вперед на всех парах, веруя в

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

процессами,

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

екта.

Для

небольших проектов достаточно простого списка

источников

риска, а ключевым элементом успешного крупномасштабного проекта

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

Составляющие управления риском

Управление риском (risk management) — это применение

инструмен-

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

проек-

те приемлемыми рамками. Управление риском предоставляет стан-

дартный подход к

выявлению

и документированию факторов

рискг.,

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

ния (Williams, Walker, и Dorofee,

1997).

Управление риском включает

себя действия, показанные на рис.

23-1.

Рис.

23-1.

Элементы управления риском

Оценка риска (risk assessment) — это процесс исследования проек-

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

выявления

факторов риска, составляя списки факторов риска,

типич-

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

опи-

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

управление

риском

439

санными в разделе «Риск, связанный с

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

этой главы

(Сагг

и др., 1993; McConnell, 1996). При

анализе

риска

вы исследуете потен-

циальные последствия конкретных факторов риска для вашего проек-

та. Определение приоритетов факторов риска поможет вам сконцен-

трироваться на наиболее

опасных,

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

подвер-

женность каждому из них. Подверженность — это функция, включаю-

щая как вероятность потерпеть урон из-за риска, так и масштабы этого

урона.

Предотвращение риска (risk avoidance) — это один из способов ре-

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

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

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

дет особенно трудно воплотить верно. Однако — разработка ПО рис-

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

ность.

Большую часть времени вам придется выполнять контроль риска

(risk

control),

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

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

управления

риском подразуме-

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

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

тельств, ответственных лиц и сроки исполнения. Цель действий по

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

блемой, либо уменьшить его вредное воздействие. Риск не будет кон-

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

разрешение

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

лизацию планов по сдерживанию каждого риска. И, наконец, трасси-

руйте свое продвижение к разрешению каждого риска посредством

мониторинга риска, который должен стать частью вашего

стандартно-

го трассирования статуса проекта. Отслеживайте, насколько хорошо

работают ваши действия по смягчению риска, ищите новые факторы

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

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

риска.

Документирование рисков проекта

Недостаточно просто

знать

риски, угрожающие вашему проекту. Вам

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

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

жении проекта. На рис. 23-2 показан шаблон документирования от-

дельной области риска. Иногда удобно хранить его в электронной таб-

лице, что позволяет легко сортировать список областей риска. Вместо

того чтобы включать его в свой план

управления

проектом или в спе-

440 Часть IV.

Особенности

реализации процесса построения требований

цификацию

требований к ПО, ведите список областей риска в качест-

ве отдельного документа — так его будет легко обновлять на

протяже-

нии проекта.

Используйте формат «причина —

следствие»,

документируя

факто-

ры риска. То есть сначала формулируйте причину риска, вызывающую

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

ре-

зультат—следствие.

Часто люди, говорящие о риске, приводят только

условие («клиенты не придут к единому мнению относительно

требо

ваний к продукту») или только следствие

(«мы

сможем

удовлетворит!,

лишь одного из наших основных

клиентов»).

Одна причина может

по-

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

од>

ному и тому же следствию.

Идентификатор:

<порядковый

номер>

Дата открытия:

<дата,

когда элемент риска был

обнаружен>

Дата

закрытия:

<дага,

когда

элемент

риска был

закрыт>

Описание:

<описание

элемента

риска в форме «причина -

следствие^

Вероятность:

<вероптность

того, что элемент риска станет

проблемой>

Влияние:

<потенциальный

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

элемент

риска станет

проблемой

Подверженность:

<Вероятность,

умноженная на

ущерб>

План смягчения риска:

<один

или несколько методов

управления,

избежания,

уменьшения

последствий

или других

способов

минимизации

риска>

Ответственное

лицо;

человек,

отвечающий

за

разрешение

элемента

риска>

Срок исполнения

<дата,

которой

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

выполнены^-

Рис. 23-2. Шаблон трассирования элемента риска

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

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

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

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

Я оцениваю вероятность по шкале от

0,1

(практически

невозможно}

до

1,0

(обязательно

произойдет},

а ущерб — по относительной шкале от 1

(нет проблем) до

(полный

кошмар).

Еще лучше попытаться оценить

потенциальное влияние в единицах потерянного времени и денег. Ум-

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

го элемента риска.

Не пытайтесь оценить факторы риска слишком точно. Ваша цель —

отделить наиболее угрожающие риски от тех, за которые не нужно хва-

таться немедленно. Проще оценивать и вероятность, и ущерб как вы-

сокий, средний или низкий. Факторы, имеющие как минимум одну

оценку

высокого

уровня, требуют вашего внимания на ранних стадиях.

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

действия,

которые

вы намереваетесь предпринять для контроля риска. Некоторые стра-

тегии смягчения снижают вероятность риска, другие — уменьшают его

влияние. Учитывайте стоимость этих действий при планировании. Не-

разумно тратить $20000 на управление риском, который стоил бы вам

лишь $10000. Вы также можете

составить

планы на непредвиденные

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

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

ект подвергнется воздействию риска. Назначьте для каждого элемен-

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

ределите сроки исполнения действий по смягчению. Долгосрочные

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

гии минимизации риска с массой промежуточных целей.

Рис. 23-3

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

фактор риска, который лидеры проекта

Chemical Tracking System обсуждали в начале этой главы. Команда

оценила вероятность и ущерб на основании своего предыдущего опы-

та.

Но,

не оценив другие факторы риска, она не узнает, насколько серь-

езна подверженность риску с коэффициентом

4,2.

Первые два метода

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

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

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

снижает

вероятность потенциального

ущерба, запрашивая обратную реакцию пользователей по пользова-

тельскому интерфейсу на ранних стадиях проекта.

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

Дата

открытия:

04.03.2003

Дата

закрытия:

(открыт)

Описание:

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

вовлечение

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

составление

требований может взывать необходимость

объемной переработки

пользовательского

интерфейса после бега-тестирования.

Вероятность:

0,6

Влияние:

Подверженность:

4,2

План смягчения риска:

собрать

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

удобству

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

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

провести

встречи

со

сторонниками

продут

для

разработки

требований;

3. разработать одноразовый прототип базовой

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

пользовательского

интерфейса

с участием

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

должны

оценить прототип.

Ответственное

лицо:

Хелен

Срок исполнения

Провести семинар к

16.04.2003.

Рис. 23-3. Пример фактора риска для Chemical Tracking System

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

Список факторов риска — не то же

самое,

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

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

рис

ком в план управления проектом разработки ПО. Для большого

проект;*

необходимо

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

формули

рующии предполагаемые подходы для выявления, оценки,

документи

рования и учета риска. Этот план должен включать распределение

ро-

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

плана

по управлению риском доступен на http://www.processimpact.com/

goodies.shtml.

Для многих проектов назначается менеджер по

управле-

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

одной

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

«Иа-Иа»,

в честь печальногс

персонажа из «Винни-Пуха», который постоянно горевал о

том,

как все

может быть плохо.

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

443

Ловушка Не предполагайте, что фактор риска под

контролем

просто потому, что

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

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

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

управления

риском. Предусмотрите действия для смягчения риска, составление отчетов о стату-

се риска и обновление списка элементов риска в вашем списке задач по проекту.

Установите периодичность мониторинга риска. Не упускайте из ви-

да примерно десять факторов риска с наибольшим коэффициентом и

регулярно оценивайте эффективность методов по смягчению. Когда

действие по минимизации завершено, заново оценивайте вероят-

ность и влияние соответствующего риска, а затем в соответствии с ре-

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

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

что выполнены действия по его минимизации. Вам нужно понять, сни-

зили ли эти методы

подверженность

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

лась ли

вероятность,

что отдельный

элеминт

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

блему.

Не под контролем

Менеджер проекта однажды спросил

меня,

что делать,

если

одни и те же пункты ос-

таются в его еженедельном списке главных пяти факторов риска из недели в неде-

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

либо не исполняются, либо не

эффективны.

Если это так, то подверженность рис-

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

случае более значимыми и требующими вашего внимания становятся элементы

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

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

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

вия по смягчению риска.

Риск,

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

Факторы риска, описанные на предыдущих страницах, группируются по

принадлежности к основным этапам

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

требований: вы-

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

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

444 Часть IV. Особенности реализации процесса

построения

требований

или

влияние риска. Это только начало; составьте свой собственный

список факторов риска и стратегий по смягчению на основе опыта, на-

работанного в каждом проекте. Leishman и Cook (2002) описывают до-

полнительные факторы риска, связанные с требованиями к ПО. Не за-

будьте записывать факторы риска в формате «причина — следствие».

Выявление требований

Образ

и границы проекта. Расползание границ становится более ве-

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

:э

мнения о

том,

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

пред-

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

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

его при выработке решений о принятии или

изменении

требований.

Время, затраченное на

разработку

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

сроки

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

со-

ставлением требований; они считают, что если программисты не

начну

работать над кодом немедленно, то не

закончат

вовремя. Проекты

ши-

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

(на-

пример, информационные системы, системное ПО, коммерческие или

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

10-15%

ресурсов проекта на действия по разработке требований (Rubin

1999)

Записывайте,

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

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

оценить,

достаточно ли этого, и улучшить планирование следующих проектов.

Полнота и корректность спецификации требований. Чтобы требо-

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

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

на пользовательских задачах. Составляйте конкретные сценарии ис-

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

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

прототипы, чтобы требования были

понятны

пользователям и чтобы

получать от них конкретные отзывы. Привлеките представителей кли-

ентов к экспертизе спецификации требований и моделей анализа.

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

оценке реакции ранка

на

продукты, первые в своем роде. Уделите боль-

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

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

обратную реакцию относительно вашего продукта.

Определение нефункциональных требований. Поскольку

основ-

ное внимание, естественно, обращено к функциональности продукта,

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

легко

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

требования.

Запрашивайте клиен-

тов о качественных характеристиках, таки;:, как производительность,

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

целостность

и надежность. Доку-

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

тия как можно точнее в спецификации требований к ПО.

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

Если различные клиенты вашего продукта че

достигли

соглашения от-

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

останется недоволен результатом.

Определите

основных клиентов и

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

ставительства и вовлечения клиентов.

Удостоверьтесь,

что вы пола-

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

для принятия решений.

Не сформулированные требования. У клиентов часто есть скрытые

ожидания, о

которых

они не сообщают, и

поэтому

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

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

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

тов больше делиться своими

мыслями,

пожеланиями, идеями,

инфор-

мацией и сомнениями.

Использование существующего продукта в качестве базовой

версии. Разработка требований считается не важной в проектах сле-

дующего поколения или при переделке предыдущих проектов. Разра-

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

качестве источника требований, со списком изменений и дополнений.

Это вынуждает их собирать требования

чорез

инженерный анализ те-

кущего проекта. Однако это не эффективный и не полный способ вы-

явления требований, поэтому не

удивляйтесь,

если у новой системы

проявятся некоторые недостатки исходной системы. Документируйте

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

рить их, чтобы

убедиться,

что они верны и до сих пор актуальны.

Решения,

предлагаемые

в качестве потребностей. Предлагаемые

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

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

раз-

работчиков принимать плохие

конструкторские

решения. Задача

аналитика

—

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

мым решением,

Анализ требований

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

дое функциональное требование,

функция

или вариант использования

получило приоритет и приписано к

конкретной

версии или итерации

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

требований