Принципы работы с требованиями к ПО. Леффингуэлл (2002) (1186169), страница 40
Текст из файла (страница 40)
На семинарах, посвященных вопросам требований, мы всегда спрашиваем: "Какой масштаб в начале проекта ваы обычно задает руководство, заказчики или заинтересованные лгггга?". В ответ только изредка можно услышать "до 100 процентов". Как Глава 19. Проблема масштаба проекта 199 правило, числа в ответах варьируются от 12э до 900 процентов. Среднее значение кало дый раз получается приблизительно одинаковым и составляет около 200 процентов. Этн данные в значительной мере совпадают с результатами исследований группы Стендиша, свидетельствующими. что более половины проектов будут стоить примерно вдвое боль.
ше, чем предполагалось. Теперь мы, возмо|кно, понимаем, почему. Небольшая история о масштабе проекта Однажды одну из наших студенток назначили на новую для нее должность менеджера разработки программного продукта. В прошлом она занималась многими аспектами разработки новых продуктов и маркетинга, но не имела непосредственного опьпа в разработке программного обеспечения. Она выслушала ответы на наш вопрос о мас. штабе с недоверием. Оглядев присутствующих, она сказана: "Неужели вы действительно хотите сказать, что постоянно беретесь сделать вдвое болыпе работы, чем можно успеть эа отведенное время? з Что же зто за профессия? Вы что, сумаспзедшие?". Разра.
ботчнки смущекно посмотрели друг на друга и согласно ответили: "Да". Что происходит, когда проект развивается с изначально заданным масштабом 200 процентов? ° Если функции приложения полностью независимы (что маловероятно), только поло. вина из них будет работать к моменту сдачи. Продукт будет "хромать", обеспечивая только половину предполагаемых возможностей. И зта половина не является целост. ной! Функции не работают совместно, ие производят никакой полезной суммарной ра; боты.
Приложение с решителъно "урезанным" масштабом быстро собирается в единое целое и отправляется. Следствием является серьезное недовольство эаказчинов, чьи ожидания ие оправдались, невыполнение маркетинговых обязательств, некачественные руководства пользователя и рекзамные материалы, которые необходимо срочно переделать. Команда страдает и теряет мотивацию. ° К моменту сдачи каждая функция готова только иа 50 процентов. Поскольку, как правило, существуют взаимозависимости между отдельными частями функции, ничто вообще яе работаеза к окончанию фока Срок сдачи проходит. Все обязательства нарушаются; определяется новый срок сдачи и зачастую начинается новый "марш смерти". В худпзем случае вся команда увольняется после нескольких месяцев работы сверх установленкого срока; объявляется финальная "фаза" первой попытки разработки проекта и назначается новый мекеджер.
Каково качество программного обеспечения в каждом иэ этих случаев? Код, который создавался ближе к концу, плохо сконструирован и содержит дефекты; тестирование сведено к минимуму или вообще не производится; документация и системы подсказок отсутствуют. Заказчикам приходится выполнять как тестирование, так и действия по обеспе. чению качества. В итоге закаэчики реагируют на наши сверхусилия следующим образом: Мы фазу были Разочарованы тем„иасколысо вы опоздали ~или как мало сделали яо фавиекию с нашими оэсиданиями), но ямяфь мы яо.настоящему недовольны, так как обкфуяеияи, что то, чою вы иам я)мдоставизиь — зто ирофоммн ый мусф.
з Многие студенты отметили, что часто руководство полписызает контракт, не спрашивая нх мнения. 196 ь4асть 4. Управление масштабом Трудный вопрос Для того чтобы команда проекта имела хоть какую-то надежду на успех, ей необходимо оценивать масппаб как до начала, так и во время проведения рааработки. Однако в типичном случае задача состоит в сокращении масппаба: Если мм действительно начинаем разработку с 2Юнфоиентнмм масштабам, необходимо соьфатить масштаб проекта, как ми. нимум, в два рава, чтобы иметь шанс на успех. Перед командой встает дилемма: как свкРавшть масштаб и удввлепшс!!эить эакаэчикаУ Это один из самых трудных вопросов. Но еще не все потеряно! Мы рассмотрим способы решения данной проблемы в следующих двух главах.
Глава 20 Задание масштаба проекта Основные положения ° При определении масвггаба проекта первым шагом является задание базо-, вого уровня требований, т.е. упорядоченного списка высокоуровневых: функций, которые будут реализовываться в увазаииой версии продукта. И Второй шаг состоит в приблизительном определении объема трудозатрат,,' необходимого для каждой из перечисленных базовых функций. ° Третьим шагом является оцекка риска для каждой функции или вероятно-, сти того, что ее реализация окажет неблагоприятное воздействие на график и бюджет.
° Используя зти данные, команда задает базовый уровень таким образом, чтобы гарантировать предоставление критически вюкных для успеха про. ' екта функций. Базовый уровень требований Задача управления маспггабом состоит в задании высокоуровневой базы требований дэя данного проекта. Базовый уровень - зто разбитое на злеменнне мнозсество Янниий иеи трейюаний, нонизрьм намечено реал иювать в конкретной версии прил висения. Представленный на рис.
20.1 базовый уровень версии должен быть согласован как с заказчиком, так и с командой разработчиков. Другими словами, базовый уровень должен обладать следующими свойствами. ° Он должен быть, как минимум, "приемлемым" для заказчика. ° Должен иметь разумную вероятность успеха с точки зрения команды разработчиков. Рис. 20Л. Базовый уровень требований Первый втг при задании базового уровня состоит в простом перечислении функций, ко торые были определены для приложения. Очень важно при этом следить за уровнем детали. 198 Часть 4. Управление масштабом эации. В части 8 мы утверждали, что любую новую систему, независимо от того, насколько сложной она явлветсв, можно описать с помощью списка из 2з — 99 фунхций.
Если их будет больше, то описание проекта будет слишком детализировано, что будет помехой при обсуждении его с заказчиками и командой разработчиков. Если же меньше — уровень детализации будет недостаточным для обеспечения удовлетворительного понимания приложения и оценки уровня необходимых для его реализации трудозатрат. Если мы следовали рекомецлуевюл~у для совещюпш по вопросу требований процессу (глава 10) или пришли к аналогичному результату другим путем, в нашем распоряжении будет список из 25-99 функций.
Этот список представляет собой разбитое на пункты высокоуровие. вое описание воэможностей новой или модифицируемой системы. Он является исключи. тельно важным артефактом проекта, который мы будем использовать для оценки масштаба проекта лфед жем, как будут затрачены зца пггельиые средства на уточнение требований, про.
ектирование, разработку программного кода, тестирование и другие действия. В качестве приввера расслютрим некий программный продукт, для которого был составлен список иэ следующих восьми функций. Функция 1. Поддержка внешней реляционной базы данных Функция 2. Многопользовательская безопасность Функция 8, Воэможность клонирования проекта Функция 4. Порт длв новой версии операционной системы 1ОС) Функция 3.
Новый "мастер" проекта Функция б. Импортирование вневших данных по стилям Функция 7. Реализация средств предупреждения Ф)жкция 8. Интеграция с подсистемой управления версиями Установка приоритетов Таблица 20.1. Упорядоченные по приоритетам функции Функция Приоритет Функция 1. Поддержка виеяшсй реляционной базы данных Критический Функция 4. Порт для новой версии ОС Функция б, Импортирование внешних данных ио стилям Критический Критический Как уже отмечалось в части 2, "Понимание потребностей пользователей", задание относительных приоритетов функций набора является составной частью управления маслвтабом, Важно, чтобы заказчики и пользователи, менеджеры нижнего уровня или их представители — не команда разработчиков — определяли приоритеты, находясь в вашем отделе маркетинга.
Первичная расстановка приоритетов должна производиться без заметного влияния со стороны технического сообщества; в противном случае уровень сложности реализации функций будет влиять на приоритеты клиентов, результаты процесса мовуг исказиться и окажется, что приложение не будет удовлетворять реальные потребности клиентов.
Технические люлвенты можно будет учесть на более поздних фазах процесса расстановки приоритетов. Для нашего примера предположим, что лвы провели голосование относительно приоритета каждой функции, используя шкалу "критический- важный-полезный"; результаты этого голосования представлены в табл. 20.1. Глава 20. Задание масштаба проекта 199 Окончание май«20. 1 Приоритет Функция Функция 3. Возможность клонирования проекта Функция 2.
Многопользовательская безопасность Функция 5. Новый "мастер" проекта Функция 7. Реализация средств предупреждения Функция й. Интеграция с подсистемой управления версиями Важный Важный Важный Полезный Полезный Оценка трудозатрат Менеджер продукта: Команда разработчиков: Насколько трудно сделать эту функцию? Мы не знаем. У нас до сих пор еще нет никаких требований или результатов проектирования. Я ато понимаю, но является ли эта функция самой простой, которую вам доводилось когда-либо создавать? Нет. Хорошо, является ли она наиболее сложной функцией в списке? Нет. По шкале "низкая. средняя-высокая" мы присвоим ей Менеджер продукта: Команда разработчиков» Менеджер продукта: Команда разработчиков: Менеджер продукты » Команда может по своему желанию использовать "командо месяцы" нли "командо недели" для оценю» общего вклада функции в проект.
Эта грубая эвристическая оценка служит заменой более детальной оцени», и неизвестно, что лучше, этот метод нлн результат данного диалога. Затем, учить»вэя этн оценки и общее отведенное на проект время, ко«инда может определить, где изначально проводить базовый уровень. Если он проходит нике «рнтическнх функций, все хорошо; если же нет, проект сэнш. ком масштабный и необходимо определять новый (меньший) проеат.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
