Ресурсы в программных проектах. Управление ресурсами

Ресурс- объект проекта, подлежащий управлению и планированию.

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

Управление сотрудниками заключается в определении ролей (например: заказчик, менеджер, архитектор, руководитель, тестер, разработчик, пользователь и т.д.).

Рабочее время - должно учитываться при формировании команды (нестандартное время работы, выходные, отпуска и т.д.). В общем случае является внешним ограничением при планировании.

Оборудование и машинное время - специализированное оборудование и ПОдля разработки проекта, или для исполнения проекта, или тестирования проекта. В общем случае является внешним ограничением при планировании.

1. В общем случае, понятие «объект проекта, подлежащий управлению и планированию» означает:

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

Роль - конкретное амплуа сотрудника в конкретном проекте в определённом месте. Не все роли могут присутствовать в проекте. При этом возможны варианты:

- 1 сотрудник - 1 роль;

- 1 сотрудник - несколько ролей;

- несколько сотрудников - 1 роль;

- несколько сотрудников - несколько ролей (это общий случай).

Основные роли:

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

- планировщик ресурсов - выдвигает и координирует требования, развивает и направляет план выполнения проекта, обеспечивает финансирование;

- менеджер проекта - внешние функции (взаимодействие с заказчиком и планировщиком), внутренние функции (распределение задач среди команды, организация выполнения проекта);

- архитектор- проектирует архитектуру системы, формирует инфраструктуру разработки;

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

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

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

- разработчик документации- разработка программной и эксплуатационной документации, ведение информационной поддержки процесса разработки;

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

1. За реализацию программных компонентов, автономное тестирование отвечает:

2. Роль заказчика заключается в следующем:

Проектные активности программных проектов

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

Проектная активность - некое действие, выполняемое в ходе проектирования(выполнение задач из ТЗ, реализация изменений, исправление дефектов)

Задача - часть программного проекта. С ней связан некий набор требований. Может реализовываться относительно самостоятельно. Результат её выполнения можно проконтролировать.

Атрибуты задач: планируемое время старта и завершения задачи; список вложенных подзадач; список ресурсов; требующийся для реализации задачи, временные условия старта задачи; временные события, инициирующие завершение задачи.

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

Изменения проекта вызваны одобренными изменениями требований.

Программный дефект -ошибка, обнаруженная в процессе тестирования или наблюдения.

1. Часть программного проекта, с которой связан некий набор требований:

Временные сущности программных проектов

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

Временные сущности: этапы и вехи.

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

Завершение этапа может сопровождаться созданием макета, выпуском версии продукта, реализации компонента продукта, и т.д.. По окончании этапа можно принимать кардинальные решения: продолжение или прекращение проекта, перепланирование, изменение финансирования и т.д..

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

1. Множество задач проекта, подчинённых какой-либо локальной цели:

Визуализация плана. Наблюдение за программным проектом

Существует два основных подхода визуализации плана: диаграмма Ганта, диаграмма PERT.

Наблюдение за проектом ведётся по активности (задачи, дефекты, изменения), ресурсам (сотрудники, время), временным сущностям (этапы, вехи) и срезам.

Срез по задачам -сотрудники, занятые решением задачи, соответствие задач графика, процент завершённости по задачам проекта, общее количество дефектов задачи и т.д..

Срез по сотрудникам- текущие задачи сотрудника, общее количество дефектов, относящихся к сотруднику и т.д..

Срез по дефектам - количество дефектов для данной задачи, количество незакрытых дефектов для каждой задачи, история изменения дефектов, среднее время исправления дефекта, среднее количество дефектов у сотрудников, распределение дефектов по сотрудникам и т.д..

Срез по фиксациям изменений (коммитам) в СКВ - среднее число фиксаций на сотрудника за единицу времени, равномерность фиксаций у сотрудников и т.д..

Срез по критическому пути - сотрудники в критическом пути, задачи в критическом пути, временные запасы в критическом пути.

1. Один из способов визуализации плана:

2. Срез по задачам предполагает отслеживание: