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

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

Тестирование системы. Пользовательские и функциональные тре-

бования представляют собой важнейшие входные данные для тести-

рования системы. Если предполагаемое поведение ПО в различных

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

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

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

Процесс конструирования. Несмотря на то что работающая про-

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

ПО,

требова-

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

ции и связывают воедино различные этапы разработки.

Проверяйте

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

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

проверить, удовлетворяет ли их код спецификациям и соответствую-

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

тировать, какие элементы конструкции и кода ПО были получены на

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

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

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

документацию для сложных программных продуктов. Я спросил

ог.ного

из них, почему они работают так долго. «Мы уже заканчиваем, — отве-

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

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

следний момент». Требования к продукту содержат данные для про-

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

плоко

сформулированные или запаздывающие требования порождают про-

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

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

что

страдальцы в конце цепоч-

ки разработки требований — технические писатели и тестировщики —

часто с энтузиазмом поддерживают улучшенные приемы

конструиро-

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

Требования и различные

заинтересованные в проекте группы

На рис. 22-2 показаны некоторые заинтересованные в проекте лица,

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

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

Объясните

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

ствие,

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

Согласуйте форму и содержание основ взаимодействия между раз-

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

Глава 22. Совершенствование процессов работы с требованиями

4117

с продуктом, — спецификацией требований к ПО или документацией

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

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

того, какая же полная информация необходима читателям этих доку-

ментов.

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

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

Какая информация о технической осуществимости поможет отделу

маркетинга лучше планировать концепции продуктов? Какие отчеты по

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

ние о развитии проекта? Какое

взаимодействие

с отделом разработки

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

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

ми? Активно стремитесь строить взаимоотношения сотрудничества

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

ронами.

Менеджеры по маркетингу

или

менеджеры

продукта

определяет

рыночные

или

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

запрашивав!

изменения

устанавливают

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

распределяет

ресурсы и обязанности

занимается

лицензированием

"и

нструментальных"

средства

комитентов

определяют

бизнес-нужды

нужды

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

производительности;

запрашивают

изменения

по

осуще;:твляет

поддержку

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

передает

информацию

клиентских

сообщения!

об

ошибках

запросах

на модернизацию

описывают

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

требования

Пользователи

атрибуты

качества;

»*^_

^_^-^

прсиеряют

требования

определяют

аппаратный

интерфейс,

ютсн

ому

должно

соответствовать

ПО

распределяет

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

по ПО;

запрашивает

изменения

Группа разработки

оборудования

Рис. 22-2. Связанное с требованиями взаимодействие между разработчиками ПО

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

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

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

418

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

проекте сторонами также изменяется. Люди не любят, когда их

прину-

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

к некоторому сопротивлению вашим начинаниям. Узнайте причины со-

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

Часто оно вызвано страхом перед неизвестным. Чтобы уменьшить

бо-

язнь,

сообщите логическое обоснование совершенствования

техноло-

гических процессов работы с требованиями и намерения своим

колле-

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

от нововведений. Добиваясь сотрудничества, вначале озвучьте свою

точку зрения: «Вот проблемы, которые все мы прочувствовали. Мы

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

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

получить

от вас, и вот как наша общая работа поможет всем

нам».

Вот какое

со-

противление вы можете испытать.

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

ер, воздвигаемый разработчиками, чтобы затруднить изменения. 8

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

ра, а не барьер. Он позволяет хорошо информированным людям

принимать отличные бизнес-решения. Команда разработчиков ПО

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

работал. Если новые процессы не принесут лучших результатов, лю-

ди найдут способы их обойти — и, наверное, это правильно.

I Некоторые разработчики считают документирование и проверку

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

щей» работой — написанием кода. Если вы сможете объяснить, на-

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

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

менедже-

ры будут

больше

ценить необходимость хороших

требований.

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

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

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

качества продукта.

Если одна из целей совершенствования технологических процессов —

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

качеством, менеджер, отвечающий за поддержку продукта, может по-

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

I Занятые клиенты иногда заявляют, что у них нет времени работать

над требованиями. Напомните им о предыдущих проектах, резуль-

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

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

после

выхода продуктов.

Глава 22. Совершенствование процессов работы с требованиями

419

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

акция: «А что мне с этого

будет?»

Однако

такие

изменения не всегда

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

процесс затрагивает. Более важный вопрос, кстати, на который любой,

кто отвечает за совершенствование

процесса,

должен уметь отвечать

убедительно: «Что нам с этого будет?» Любое изменение процессов

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

тающей над проектом, организации-разработчику, компании, клиен-

там или всему миру. Часто убедить людей принять эти изменения мож-

но,

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

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

Основы совершенствования

процессов разработки ПО

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

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

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

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

принципах совершенствования процессов работы над ПО (Wiegers,

1996а).

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

постепенным, непрерывным и цикличным. Не стремитесь улуч-

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

чится исправить все с первой же попытки. Вместо того чтобы ста-

вить целью абсолютное совершенствование, разработайте не-

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

реализацию. Настраивайте свои методы по мере того, как ваша ко-

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

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

выгоде, так что ищите плоды, висящие низко.

2. Люди и организации изменяются только при наличии стимула.

Сильнейший из них — это трудности в работе. Я не имею в виду

ис-

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

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

команду работать

усерднее,

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

испытывали в предыдущих

проектах-

Вот какие проблемы

могу!

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

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

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

требований

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

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

I разработчикам пришлось много работать

сверхурочно,

потому

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

слишком поздно в процессе

разработки;

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

щики не понимали, что продукт должен делать;

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

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

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

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

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

ных

функций,

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

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

организация-разработчик

ПО приобрела плохую репутацию

по-

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

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

ориен-

тированы на цель. Прежде чем улучшать методики,

убедитесь

что знаете, куда идете (Potter и Sakry, 2002). Хотите ли вы умень-

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

про

блем с требованиями? Хотите, чтоб график оказался более

пред

сказуемым? Хотите прекратить пересмотр требований на стадии

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

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

технологических процессов.

Воспринимайте действия по совершенствованию процессов

как мини-проекты. Многие попытки внесения

усовершенствова

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

отсутствие

ожидаемых ресурсов. Учтите ресурсы, необходимые для

совер

шенствования процессов, в общих планах по проекту.

Выполняйте

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

отчетно

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

внимание

малые масштабы проекта по внесению усовершенствований.

Пи-

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

про-

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

которое

участ

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

прове

рить, действительно ли нужно столько усилий и сколько

стон-

работа по совершенствованию.

Глава 22, Совершенствование процессов работы с требованиями 421

Ловушка Наибольшая угроза программе совершенствования процессов работы

над ПО - это недостаточно

серьезное

отношение

руководства

к своим

обязательст-

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

приоритеты программы.

Все члены команды имеют возможность — и обязанность — активно

улучшать свой рабочий процесс. Профессиональным разработчикам

ПО не нужно разрешение менеджеров для совершенствования их ра-

боты и работы их команд. «Народные» программы совершенствования

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

летворенности сотрудников или инициируются харизматическим ли-

дером, могут быть весьма успешными. Тем не менее масштабная ини-

циатива по совершенствованию технологических процессов может

преуспеть, только если руководство готово выделять ресурсы, опре-

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

их вклад в программу по совершенствованию.

Шутливые

советы по совершенствованию

техно

логических процессов

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

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

этой трудной области. Вот некоторые из тех, что я собрал на протяжении ряда лет:

не откусывайте слишком много за раз (если

вы

попробуете

глобально изменить

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

1 бурно радуйтесь малым победам

(больших

побед у вас будет немного);

1 давите мягко, но постоянно (лидеры программ совершенствования технологиче-

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

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

ее);

1 концентрация, концентрация, концентрация (занятая команда разработчиков ПО

может выполнять лишь

три,

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

вершенствованию за раз. Но никогда не беритесь меньше, чем за один

проект);

1 ищите союзников (в каждой команде есть свои

энтузиасты,

которые с готовно-

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

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

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

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

действий;

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

в ожидании лучших результатов, но это -

единственный

полезный результат

процесса совершенствования).

422 Часть

IV.

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

Цикл совершенствования

технологических процессов

На рис. 22-3 изображен цикл совершенствования технологических

процессов, в эффективности которого я убедился. Этот цикл показы-

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

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

по-

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

совершенствования

процессов.

Оцените

текущие приемы

Позволь

технологичес

достичь л

резуль

открытия

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

д<

ве[

новые

не

процессы

олаемых

гатов?

Насколько

был процесс

деист

панирование

1ЙСТВИЙ ПО

СО-

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

план действий

новые

пр<

Создание,

проба

ез

ль

™

план

реализация

следующего цикла

"овых

технологи- |

совершенствований

ческих

процессов

утешным

лакирования

аий?

Наскольк

прошла пробна

и общее вн

гладко

я реализаций

цессы;

пробы;

рения

Оценка

зультатов

Рис. 22-3. Цикл совершенствования технологических процессов при создании ПО

Оцените текущие технологические процессы

Первое, с чего следует начать любое совершенствование, — это

оцен

ка

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

определение их сильных и слабых сторон. Оценка сама по себе не

дае

-г

никаких усовершенствований — но позволяет получить информацию,

Проводя ее, вы строите фундамент для

принятия

верных решений о же

лаемых изменениях. Кроме того, вы делаете видимыми реальные рабо

чие процессы в организации — часто они отличаются от официально

утвержденных или описанных в документации. И вы обнаружите, что

Глава 22. Совершенствование процессов работы с требованиями

42;

члены команды имеют

разные

взгляды на

то,

какие процессы использу-

ются сейчас.

Вы можете оценивать текущие процессы разными способами. Если

вы опробовали какие-либо предложения из разделов «Что теперь?»

предыдущих глав, то уже начали неформально оценивать приемы

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

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

особых затрат выявить важную информацию. Интервью и обсуждения

с членами команды дают более точное и полное понимание,

Вы можете использовать

анкету

приложении

для идентификации

текущих приемов конструирования требований в вашей организации*.

Этот тест помогает понять, какие из ваших процессов работы с требо-

ваниями более всего нуждаются в совершенствовании. Но если вы по-

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

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

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

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

успех ваших будущих проектов.

Более основательный подход

предполагает

приглашение консуль-

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

ПО

Наиболее полные оценки процессов основаны на признанных процес-

сах совершенствования структуры, таких, как Capability Maturity Model

for Software (SW-CMM), разработанный Software Engineering Institute

(Paulkn

др.,

1995).

Приглашенные эксперты обычно

исследуют

множе-

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

связа-

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

спи-

сок обнаруженных сильных и слабых сторон в текущих процессах, а

также, рекомендации к совершенствованию. Выберите метод оценки,

наиболее соответствующий

бизнес-целям,

которые вы желаете

реали-

зовать при совершенствовании технологических процессов, и не

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

vSW-CMM

или любой другой структуры. В приложении Б описано,

кактребованин

соответствуют SW-CMM и более новой модели интеграции

СММ,

на-

зываемой

CMMI-SE/SW.

* Motorola разработала похожую «Модель качества требований к ПО» для оценки процессов

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

{Smith,

1998).

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

Создайте план совершенствования

Если считать действия по совершенствованию процессов

проектами,

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

{Potter

Sakry,

2002). Стратегический план описывает общую программу совершен-

ствования процессов в вашей организации. Тактические планы

дейс^

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

процесс сбора требований или процедуру назначения приоритетов. В

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

совер-

шенствованию, участники и отдельные задачи. Без плана можно

про-

пустить важные задачи. План также дает возможность

отслеживать

выполнение процесса совершенствования, отмечая выполнение

дельных

задач.

На рис. 22-4 показан шаблон плана совершенствования технологи-

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

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

тремя месяцами. Например, я видел план совершенствования

управ-

ления требованиями, включавший в себя следующие задачи:

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

2. проверить и модифицировать процедуру управления изменениями;

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

для проекта А;

4. модифицировать процедуру управления изменениями на

основе

обратной реакции по пробному испытанию;

5. оценить инструментальные средства выявления проблем и вы-

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

ниями;

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

лем и настроить его для поддержки конкретной

процедуры;

7. внедрить новую процедуру управления изменениями и инструмен-

тальное средство в организации.

Поручите каждую задачу конкретному человеку, который будет

отве-

чать за ее выполнение. Не назначайте «всю команду» ответственной

га

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

Если вам нужно выполнить более

задач, в первый цикл включите

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

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

ми. Дорожная карта совершенствования технологических

процессов,

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

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

совершенствования процессов разработки ПО.

Глава 22. Совершенствование процессов работы с требованиями 425

План

совершенствования

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

Проект: Дата:

<наэванне

вашего

проекта>

<дата

написания

планам

Цели:

<Сформулируйте

несколько

целей,

которых

вы желаете достичь в

результате

успешного

выполнения

этого

плана.

(Йэрмулируйте

цели с

точки

зрения бизнеса, а не

изменений

процессах,

Мера успеха:

<0пишите,

как вы будете определять, есть ли желаемые эффекты и проекте в

результате

изменений

процессах.

Масштаб влияния на

организацию:

Опиши темасштаб влияния

изменений

процессах,

описанных вэюм плане. >

Сотрудники и участники:

<0пределите,

кто будет претворять

действие этот

план,

их роли

if,

время,

которое они должны затратить

(в

часах

в неделю либо в

процентах).

Процесс учета и отчетности:

<0пишите,

как будет учитываться

продвижение

выполнении

зада-

этого

плана, и кто будет

получеть

отчеты

по

статусу,

результатам и проблемам, >

Зависимость, риски и ограничения:

«Определите,

какие

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

реализации

этого

плана

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

ей.>

Ожидаемые

сроки

выполнения

всех

задач:

<Когда

вы ожидаете полного выполнения этого

плана?>

Задачи:

Оапишиге

отЗдо

задач

для

каждого

плана

действий.

Номер

задачи

<Номер

по

порядку

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

лицо

<Яеловек,

несущий

ответ-

ственность за

выполнение

Срок

выполнения

<0жеда-

емаядага

выполнения^

Цель Описание

действий

этой

которые

следует

эадачи>

выполнить

для

реализации

конкре:

ной

задачк>

Результаты

<Лроцедуры,

шаблоны или

другие образцы

документов,

ко

горые

будут

созданы

Необходимые

ресурсы

<Любые

необ-

ходимые внеш-

ние ресурсы,

в том числе

материалы,

инс-

трументы,

документы или

люди>

Рис. 22-4. Шаблон плана совершенствования

процессов

разработки ПО

Создайте, опробуйте и реализуйте новые процессы

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

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

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

для самого трудного: реализации плана. Многие программы совер-

шенствования

спотыкаются

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

действиям.

426 Часть IV. Особенности

реализации

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