Распределение ресурсов (Resource Allocation)



С задачами (для которых назначены сроки), должны быть ассоциированы оборудование, средства и, конечно, люди. Это подразумевает распределение (назначение или принятие, в зависимости от стиля и формы управления) обязанностей/ответственности. Для этого может, например, использоваться диаграмма Ганта (Gantt chart). Эта деятельность определяется и ограничивается доступностью ресурсов, их оптимальным использованием в заданном контексте и вопросами, связанными с персоналом (например, продуктивностью конкретных лиц и группы, в целом, организационной и командной структурой, подразумевая специфику коллектива, наравне со штатным расписанием и другие вопросы).

Крайне необходимо выделить как самостоятельную тему данной секции вопросы управления персоналомpeople management, уделив особое внимание аспектам экспертизы (не стоит путать с ролями/обязанностями) и лидерства специалистов в проектной команде. К этой же теме, также стоит отнести вопросы обучения, прохождения тренингов специалистами проектной команды. Наконец, к теме ресурсов имеет непосредственное отношение и определение необходимости и объема привлечения внешних консультантов (не являющихся сотрудниками ни исполнителя, ни заказчика), к сожалению, не упоминаемое здесь в SWEBOK, но крайне важное, по опыту автора, для успешности проекта, обладающего высокой степенью новизны (например, в терминах используемых технологий и, особенно, применения тех или иных архитектурных решений).

Управление рисками (Risk Management)

В части управления рисками должны проводиться:

  • идентификация и анализ рисков - что, когда и почему может быть сделано неверно и к чему это может привести;
  • оценка критических рисков - какие из рисков наиболее значительны (если им не уделять должного внимания) и что необходимо сделать, чтобы их избежать;
  • смягчение рисков (risk mitigation) и планируемость непредвиденных обстоятельств (contingency planning) – формирование стратегии, касающейся рисков и управление профилями рисков.

Для идентификации и оценки рисков необходимо применять соответствующие методы и техники (например, построение дерева решений – decision tree или моделирование процессов – process simulation). Кроме того, со всеми заинтересованными лицами необходимо определить правила и политики прекращения проекта.

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

Управление качеством (Quality Management)

Качество определяется в терминах атрибутов, значимых для данного конкретного проекта и/или ассоциированного с ним продукта. Атрибуты могут выражаться как качественно, так и количественно. Эти характеристики качества определяются в спецификации требований к программному обеспечению (см. область знаний “Требования к программному обеспечению” – Software Requirements).

Отправной точкой для соблюдения качества является набор индикаторов, соответствующих ожиданиям заинтересованных лиц. На этой стадии (как мы помним, речь идет о планировании проекта) также специфицируются процедуры, связанные с проведением SQA-деятельности (деятельности по обеспечению качества – software quality assurance) на протяжении всех процессов жизненного цикла и для проверки и аттестации (V&V – verification and validation) для получаемого продукта и всех активов (артефактов) проекта (см. область знаний “Качество программного обеспечения” – Software Quality).

Управление планом проекта (Plan Management)

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

Выполнение программного проекта. Реализация планов. Управление контрактами с поставщиками. Реализация процесса по ведению измерений. Процесс мониторинга. Процесс контроля. Ведение отчетности.

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

3.1 Реализация планов*(Implementation of Plans)

Проект инициируется и проектные работы выполняются в соответствии с планом. В процессе выполнения используются соответствующие ресурсы (например, усилия персонала, бюджет) и производятся необходимые результаты (deliverables; активы, артефакты проекта – например, архитектурные документы, тестовые сценарии).

* в SWEBOK используется как “план проекта” в единственном числе, так и “планы” – во множественном числе, подразумевающие, судя по контексту, отдельные задачи проекта.


Дата добавления: 2018-05-12; просмотров: 101;