Глава 17 От разработки требований — к следующим этапам




 

Работа над Chemical Tracking System продвигалась просто замечательно. Но спонсор проекта Жерар и сторонник продукта от персонала, работающего на складе, Роксана, сомневались, стоит ли тратить много времени на определение требований, Тем не менее они присоединились к разработчикам и другим сторонникам продукта, которые проводили однодневный тренинг, посвященный работе над требованиями к ПО. На этом тренинге подчеркивалась важность достижения общего понимания всеми заинтересованными в проекте лицами бизнес-целей и нужд пользователей. Кроме того, всех участников ознакомили с терминологией, касающейся требований, концепциями и приемами, которые будут использоваться в работе. А также призвали применять лучшие приемы для работы с требованиями на практике.

По мере развития проекта Жерар получил отличные отзывы от представителей пользователей о том, насколько хорошо прошла разработка требований. Он даже организовал ланч для аналитиков и апологетов продукта, чтобы отпраздновать создание основной версии требований для первого выпуска системы. На ланче Жерар поблагодарил тех, кто занимался сбором информации для создания требований, за их вклад и коллективную работу. А затем сказал: «Теперь, когда с требованиями все в порядке, я с нетерпением ожидаю скорого появления готового кода».

«Мы еще не готовы писать код продукта, — ответил менеджер проекта, — Мы планируем выпускать систему поэтапно, поэтому ее необходимо разрабатывать, сообразуясь с будущими дополнениями. С помощью прототипов мы получили четкое представление о технической стороне и смогли понять характеристики интерфейса, который предпочитают пользователи. Если на этой стадии мы потратим еще немного времени на проектирование, то сможем избежать проблем в течение следующих нескольких месяцев, когда придет время добавлять функциональность к системе».

Жерар расстроился. Все выглядело так, как будто разработчики сознательно медлили, вместо того чтобы прямо приступить к работе. Однако не делал ли он преждевременных выводов?

 

Опытные менеджеры проекта и разработчики понимают ценность преобразования требований к ПО в надежный дизайн и рациональные планы. Они необходимы в тех случаях, когда следующая версия представляет 1 или 100% всего конечного продукта. В этой главе мы рассмотрим, как преодолеть пропасть, которая отделяет разработку требований от успешного выпуска продукта: несколько вариантов влияния требований на планы проекта, проектирование, написание кода и тестирование, как показано на рис. 17-1.

 

 

Рис. 17-1. Влияние требований на планирование проекта, дизайн, написание кода и тестирование

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

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

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

· Менеджеров проекта часто интересует, сколько времени и усилий понадобится для разработки требований. Для небольших проектов, которыми обычно занималась наша команда, этот этап обычно стоил от 12 до 15% всех затрат (Wiegers, 1996а), однако показатель зависит от объема и сложности проекта. Несмотря на опасения, что работа над требованиями замедлит создание продукта, доказано, что понятные требования ускоряют процесс разработки, что и показывают следующие примеры;

· изучение 15 проектов в сфере телекоммуникаций и банковской сферы показало, что в наиболее успешных проектах примерно 28% ресурсов тратилось на разработку требований (Hofmann и Lehner 2001): 11% — на сбор информации по требованиям, 10% — на моделирование, а 7% — на проверку и утверждение. На разработку требований для среднего проекта необходимо 15,7% всех ресурсов и 38,6% времени;

· в проектах NASA, в которых затрачивалось более 10% всех ресурсов на разработку требований, затраты и отклонения от графика оказались существенно ниже, чем в проектах, где на требования затрачивалось меньше ресурсов (Hooks и Farry, 2001);

· исследования, проведенные в Европе, показали, что команды, разрабатывающие продукты более быстро, посвятили больше времени и усилий требованиям, чем более медленные команды (табл. 17-1) (Blackburn, ScuddernVanWassenhove, 1996).

Не все ресурсы на разработку требований должны расходоваться в начале проекта, как в модели «водопада» или последовательной модели жизненного цикла. В итеративных моделях определенное время на требования будет тратиться в каждом повторном цикле разработки. Цель таких проектов — реализовывать функциональность каждые несколько недель, поэтому требованиями придется заниматься часто, но мало. На рис. 17-2показано, как в разных моделях жизненного цикла в период разработки продукта распределяются усилия на требования.

 

Таблица 17-1. Затраты на требования ускоряют разработку

  Усилия, затраченные на требования Время, затраченное на требования
Более быстрые проекты 14% 17%
Более медленные проекты 7% 9%

 

 

 

Рис. 17-2. Распределение затрат на требования по времени различается для проектов, разрабатываемых на основе различных моделей жизненного цикла

 

Ловушка Старайтесь избегать паралича аналитического процесса. Если в самом начале проекта масса усилий тратится на разработку совершенных и полных; требований — «раз и навсегда», то зачастую мало полезной функциональности удается реализовать в срок. С другой стороны, не следует избегать разработки требований вообще только из-за боязни паралича аналитического процесса.

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

Первый шаг при оценке проекта — прикинуть объем продукта ПО. Это делают исходя из текстовых требований, моделей анализа, прототипов или элементов пользовательского интерфейса. Хотя не существует идеального мерила размера ПО, чаще всего используются следующие:

· количество отдельно тестируемых требований (Wilson, 1995);

· функциональные точки и характерные точки (Jones, 1996b) или трехмерные функциональные точки, включающие в себя данные, функции и элементы управления (Whitmire, 1995);

· количество, тип и сложность элементов графического пользовательского интерфейса (graphical user interface, GUI);

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

· количество классов объектов или других объектно-ориентированных метрик (Whitmire, 1997).

Все эти методы годятся для расчета размера. Выбирайте любой, учитывая собственный опыт и природу разрабатываемого ПО. Понимание того, что команда добилась успеха при разработке схожих проектов, используя аналогичные технологии, поможет вам оценить результативность работы команды. Как только вы получите данные о размере, вы сможете воспользоваться коммерческим инструментом для расчета, который предлагает допустимые комбинации затрат на разработку и сроков. Эти средства позволят вам привести в порядок расчеты, выполненные на основе таких факторов, как квалификация разработчиков, сложность проекта, а также опыт команды в данной предметной области. Информация о некоторых доступных средствах оценки ПО опубликована на https://www.laatuk.com/tools/effort_estimation_tools.html. (Сайт закрыт прим. Редактора)

Если вы не сравните ваши расчеты с действительными результатами проекта и не улучшите методы расчета, то ваша оценка вечно будет оставаться всего лишь предположением. Чтобы собрать достаточно данных для корреляции размера ПО с усилиями на его разработку, потребуется время. Ваша цель — вывести уравнения, которое позволит с уверенностью оценить размер завершенного ПО на основании требований к нему.

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

Определенные крайние сроки поставки — головная боль для менеджеров большинства проектов. Каждый раз, когда заданные сроки и тщательно просчитанный график не совпадают, необходимы переговоры. Менеджер проекта, который может аргументировать расчеты, тщательно выполненные и основанные на фактах, выглядит при переговорах гораздо лучше, чем оперирующий предположениями. Если лица, заинтересованные в проекте, не могут разрешить конфликт, разгоревшийся вокруг графика, стоит обратить внимание на бизнес-цели проекта: они будут определять, стоит ли уменьшить объем, добавить ресурсы или согласиться на некоторое снижение качества. Такие решения принимать нелегко, однако это единственный способ максимально повысить ценность подлежащего сдаче продукта.

 

Есть час? Как-то клиент попросил наших разработчиков адаптировать небольшую программу, которую он написал для себя, к нашей общей компьютерной сети, чтобы и его коллеги могли ее использовать. «Есть час?» - спросил меня наш менеджер, передавая мне поверхностную оценку размера проекта. Когда я порасспросил клиента и его коллег, чтобы понять, что же им требуется, оказалось, что проблем несколько больше. Я потратил 100 часов только на написание программы, которая им была нужна, без наведения лоска. Тот факт, я потратил в 100 раз больше времени, чем рассчитывал менеджер, говорит о том, что его расчеты были несколько поспешными и основывались на неполной информации. Аналитик должен изучить требования, оценить масштаб и составить представление о размере до того, как кто-нибудь приступит к расчетам или возьмет на себя определенные обязательства.

 

Неясно сформулированные требования неизбежно приводят к неточным расчетам размера, затрат и графика. Поскольку определенные неясности в требованиях на ранних стадиях проекта неизбежны, заложите в график и бюджет резерв для непредвиденных обстоятельств, чтобы учесть некоторое разрастание требований (Wiegers, 2002d). Оно происходит из-за изменения ситуации в бизнесе, смещения приоритетов пользователей и рынка, а также того, что со временем заинтересованные в проекте лица лучше начинают понимать, что же продукт может и должен делать. Однако значительное увеличение требований, как правило, указывает на то, что масса положений была упущена в ходе сбора информации.

Отведите время на выбор соответствующих измерений для тех типов проектов, над которыми работает ваша команда. Между размером продукта, затратами, сроком разработки, производительностью и временем становления команды существуют сложные нелинейные взаимоотношения (Putnam и Myers, 1997). Если вы разберетесь в них, вы сможете избежать «области невозможного», то есть такой комбинации факторов, зависящих от размера продукта, графика и сотрудников, при которой еще не один продукт не был успешно разработан.

 

Ловушка Не позволяйте, чтобы на ваши расчеты влияли желания других. Ваши прогнозы не должны меняться только потому, что кому-то они не нравятся. Слишком большое несоответствие в прогнозах указывает на необходимость переговоров.

Требования и график

В некоторых проектах применяется график «справа - налево»: сначала устанавливают дату поставки продукта, а затем определяют требования. В таком случае разработчики зачастую часто не успевают закончить работу в указанные сроки, включив в ПО всю необходимую функциональность соответствующего уровня. Более реалистично определить требования к ПО до составления подробных планов и принятия определенных обязательств. Тем не менее стратегия «проектирования по расписанию» может сработать, если менеджеру проекта удастся договориться с заказчиком, какая часть желаемой функциональности удовлетворит его в указанные сроки. Как и всегда, расстановка приоритетов требований — ключевой фактор для успеха проекта.

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

Рассмотрите возможность поэтапного планирования и финансирования проекта. На стадии первоначального изучения требований вы получите достаточно информации, чтобы составить реалистичные планы и расчеты для одного или более этапов сборки. Проекты, требования к которым сформулированы нечетко, выиграют в случае поэтапного цикла разработки. Эта модель позволит разработчикам приступить к созданию качественного ПО задолго до полного выяснения требований. Расставив приоритеты требований, вы сможете определить очередность включения функциональности на каждом этапе.

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

· оценку размера продукта;

· информацию о производительности специалистов, основанную на прошлом опыте;

· список задач, которые необходимы для полной реализации или проверки функции или варианта использования;

· требования с приемлемым уровнем стабильности;

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

 

Ловушка Не поддавайтесь давлению и не принимайте на себя невыполнимых обязательств. Это верный путь к неудаче.

 



Поделиться:




Поиск по сайту

©2015-2024 poisk-ru.ru
Все права принадлежать их авторам. Данный сайт не претендует на авторства, а предоставляет бесплатное использование.
Дата создания страницы: 2016-02-12 Нарушение авторских прав и Нарушение персональных данных


Поиск по сайту: