Главная | Обратная связь | Поможем написать вашу работу!

Продолжительность проекта и наем персонала

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

Взаимосвязь между количеством работающих над проектом сотрудников, общими затратами и длительностью разработки не является прямолинейной. С увеличением количества сотрудников возрастают затраты, в том числе временные, поскольку больше времени будет уходить на общение внутри группы разработчиков. Также больше времени потребуется для определения интерфейсов между частями системы, которые они будут разрабатывать. Увеличивая вдвое количество персонала, нельзя гарантировать, что время разработки сократится также вдвое.

Модель СОСОМО включает формулу для определения календарного времени (TDEV) реализации проекта. Для всех уровней модели СОСОМО существует единая формула расчета времени:

TDEV = 3x(PM)^{(0.33 + 0.2*(}^B^-1.01)),

где РМ – оценка затрат в человеко-месяцах, В – показатель степени, способ определения которого описан ранее (В равен единице для уровня предварительного прототипирования). С помощью этой формулы определяется прогнозируемая длительность проекта.

Однако прогнозируемая длительность проекта и продолжительность графика работ, который определяется планом выполнения проекта, – это не одно и то же. Планируемый график работ может оказаться длиннее или короче прогнозируемой длительности проекта. Разность между этими двумя длительностями учитывается в модели СОСОМО 2:

TDEV = 3 х (РМ)^{(0.33 + 0.2*(В - 1.01))} х %SCED/100,

где % SCED – процент увеличения (или уменьшения) прогнозируемой длительности проекта. Значительные расхождения прогнозируемой длительности с планируемым графиком работ означают неминуемые проблемы в процессе реализации проекта.

Рассмотрим пример вычисления длительности проекта по модели СОСОМО в предположении, что по предварительной оценке затрат для реализации проекта требуется 60 человеко-месяцев (проект с характеристикой В из табл. 23.10.). Примем число 1.17 за значение показателя степени В. Тогда

TDEV = 3(60)^0.36 = 13 месяцев.

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

Интересным в модели СОСОМО может показаться то, что время, требующееся для реализации проекта, – это функция всех затрат по проекту. Причем оно не зависит от количества программистов, работающих над проектом. Это подтверждает идею о том, что не имеет смысла включать большее количество программистов в отстающий от графика проект с тем, чтобы ускорить его завершение. В статье [251] исследован вопрос ускорения реализации проекта и сделан вывод, что в работе неизбежны проблемы, если для разработки ПО не выделяется достаточно времени.

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

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

Наращивание объема работ можно смоделировать с помощью так называемой кривой Рэлея [223]; оценочная модель Путмана (Putnam, [286]) использует модель наращивания персонала, основанную на этих кривых. Модель Путмана учитывает время разработки как ключевой фактор, поскольку с уменьшением времени на разработку экспоненциально увеличиваются затраты на создание системы.

КЛЮЧЕВЫЕ ПОНЯТИЯ

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

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

• Цена программного продукта часто определяется с целью заключения контракта, что приводит к последующей подгонке функциональных возможностей системы для приведения ее в соответствие с этой ценой.

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

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

• Алгоритмические модели определения стоимости используются для управления программными проектами, поскольку они поддерживают количественный анализ параметров. Эти модели позволяют определить вклад каждого отдельного параметра в общую стоимость проекта и провести объективное (хотя и не застрахованное от ошибок) сравнение этих параметров.

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

Упражнения

23.1. Опишите два подхода к определению производительности программиста. Отметьте преимущества и недостатки каждого подхода.

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

23.3. Любой оценке стоимости присущ определенный риск, независимо от метода оценки. Предложите четыре способа снижения возможного риска при оценке стоимости.

23.4. Менеджер проекта создания ПО ответственен за разработку системы управления оборудованием по лучевой терапии для лечения людей с онкологическими заболеваниями. Эта система встроена в аппаратные средства и должна работать на специальном процессоре с ограниченным объемом памяти (8 Мбайт). Машина осуществляет связь с базой данных пациента и по окончании лечения автоматически записывает в нее дозу радиации, которой подвергался пациент, а также другие подробности лечения.

23.5. Для определения затрат, необходимых для разработки данной системы, использована модель СОСОМО. В результате получена оценка объема работ в 26 человеко-месяцев. При оценивании все множители, формирующие стоимость, были приравнены к единице.

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

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

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

23.9. Реализуйте модель СОСОМО с использованием программы электронных таблиц Microsoft Excel. Детальное описание этой модели можно загрузить с Web-узла СОСОМО 2. На Web-странице данной книги я поместил ссылку на этот Web-узел.

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

23.11. Насколько этично назначить компанией-разработчиком относительно низкую цену для контракта, зная, что при столь неопределенных требованиях можно со временем повысить цену за дополнительные изменения в них, которые со временем обязательно будут сделаны заказчиком?

23.12. Следует ли менеджерам применять критерий производительности для определения деловой характеристики специалиста? Какие меры предосторожности необходимы, чтобы этот процесс определения профессиональных возможностей специалиста не влиял на качество его работы?

⇐ Предыдущая 161 162 163 164 165166167 168 169 170 Следующая ⇒