Принципы работы с требованиями к ПО. Леффингуэлл (2002) (Принципы работы с требованиями к ПО. Леффингуэлл (2002).djvu), страница 3

Построение правильной системы НО1.!3 2000. Образец тестового примера О1: тест прецедента "Управление освещением" ПО!.!5 2000. Образец тестового примера 02: тест протокола обмена сообщениями Приложение Б. Образец документа-концепции Приложение В. Образец пакета Мол!егп 8К8 Рас!гаке Приложение Г. Принципы управления требованиями в стандартах 3Е1-СММ и 13О 9000 Принципы управления требованиями в стандарте 8Е1-СММ Принципы управления требованиями в стандарте !3О 9000 Приложение Д. Принципы управления требованиями в КаНопа11!п!Глас! Ргосеээ Структура К!.!Р Принципы управления требованиями в КЦ!л Лпэлнз проблемы Понимание потребностей заинтересованных лиц Определение системы Управление масштабом проекта Ут<лчнспнс определения системы Обработка изменений требований Интеграция процессов Сш кок литературы Предметный указатель 377 378 382 382 382 383 388 393 393 400 400 401 403 411 419 419 424 427 428 429 431 432 433 433 430 433 437 439 441 Зова анкер я косоящаю Бояки, моей жеке и яучюему доуеу.

-Дик Яеффиюуоеа Зву ккиеу я яосеящаю моску соавафу, Дину, йаеодаря кооюУому мяа файоюа юфиа смисе. и моей иоки Бадба ~М, Йаеойфя ксенькой моя скилв офеяа смиса. -Док Уайли Предисловие Проблема камня Одна из моих студенток назвала совокупность рассматриваемых в данной книге вопросов проблемой "камня". Она занимается разработкой программного обеспечения в исследовательской лаборатории, и ее заказчики часто предлагают ей задания, которые можно условно представить как "Принесите мне камень". Когда камень доставлен, заказчик некоторое время изучает его и говорит: "Да, ио на самом деле то, что я хотел, — это иейиылой голубой камень".

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

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

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

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

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

Поэта. му, когда заказчик высказывает требования к "каменной системе" нечетко, он делает это, предполагая, что впоследствии сможет их уточнить, изменить и дополнить. Все было бы прекрасно, если бы разработчик и остальные участники процесса создания, тестирования, развертывания и обслуживания данной системы могли осуществлять это с нулевыми затратами времени и денег, но так не получается. К сожалению, часто вообще ничего не получается: более половины разрабатываемых в настоящее время проектов систем программного обеспечения значительно превысили отведенное на них время и бюджет, а выполнение 2з — 33% проектов было прекращено, несмотря на то что уже были истрачены баснословнзве средства. Цель данной книги — зфедотв~атить подобные сбои и гфедлохсиязь узационпльный подход, нозволяюзций создать систему, ховнфую в действительности хочтя видеязь заказчик.

Следовательно, необходимо понимать, что это книга непа програьтшрованию и она ориентире» вана не только на разработчиков программного обеспечения. Это книга об управлении требованиями в сложных программных приложениях. Таким офаюм, данная книга нанисанп дзш всех членов команды рафпботчиков — аналитиков, (заз~~абовтгсхов, пфсонплп, зфово.

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

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

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

Аналогично систему программного обеспечения можно описать с помощью моделей и диаграмм. Чертежи г)""" 1 гк вв дома служат средством общения и переговоров между инженерами и непрофессионалами (юристами, инспекторами и соседями), точно так Ынм же связанные с программной системой технические диаграммы можно создавать так, чтобы "обычные" люди могли их понимать. Для многих чрезвычайно важных требований диаграммы не нужны вовсе. Например, будущий владелец дома может просто написать (например, по английски) требование, которое гласит; "В моем доме должны быть три спальни и достаточно большой гараж для двух машин и шести велосипедов". Как будет показано в этой книге, большинство критически важных требований к программной системе также можно написать с помощью естественного языка.

Многие гфофессиональные пузкеиы, которыми необходимо овладеть для решения данной проблемы, также можно описать посредством практических советов на уровне здравого смысла. Строителю-новичку можно посоветовать: "Не забудьте побеседовать с инспектором по строительству до того, как начнете рыть котлован под фундамент, а не пш сле того, как зальете его раствором и начнете возведение стен". В программном проекте уместен аналогичный совет: "Не забудьте задать правильные вопросы, определить приоритеты требований и не позеаляйже заказчику говорить вам, что все 100% требований критически важны, поскольку вряд ли вы сумеете удовлетворить их все к моменту сдачи". О данной книге В книге Леффингуэлла ((.ей(пкзгеН) и Уидрига (ЪУЫг13) выбран прагматический подход к описанию решения "проблемы камня".

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