Файл: Стратегия и тактика управления предприятием.pdf

Управление требованиями. Верификация. Валидация.

Управление конфигурацией. Обеспечение качества процессов и продуктов.

Причинно- следственный анализ и решение проблем.

Измерение

Техническое решение.

Интеграция продукта

Верификация продукта

Измерение.

Анализ

Валидация

Рис. 4. Интеграция процессов CMMI в дисциплинах: проектирование систем и проектирование программных средств

Базовые участки процесса «Управление проектом» как следует из рис. 4 включают основные базовые работы: создание и ведение проектного плана, определение и обеспечение обязательств, мониторинг достигнутого прогресса в сравнении с планом, выполнением корректировочных действий, управлением соглашением с поставщиками. Взаимодействие участков процесса «Управление проектом» и с другими категориями участков процессов «Проектирование» и «Поддержка» показано на рис. 5.

Соглашение с поставщиком

Требования по компонентам продуктов; технические проблемы и спорные вопросы; завершенные компоненты продуктов; приемочные проверки и испытания

Состояние, спорные вопросы, результаты проверок прогресса и контрольных точек

Повторное планирование

Что подлежит мониторингу

Корректировоч-ные действия

Потребности измерения

Обязательства

Что делать

Что создавать

Корректировочные действия

Состояние, спорные вопросы, результаты оценок процессов и продуктов, измерения и анализы

Мониторинг и контроль проекта

Планирование проекта

Управление соглашением с поставщиками

Участники процессов “Проектирование” и “Поддержка”

Поставщик

Соглашение с поставщиком

Требования по компонентам продуктов; технические проблемы и спорные вопросы; завершенные компоненты продуктов; приемочные проверки и испытания

Состояние, спорные вопросы, результаты проверок прогресса и контрольных точек

Повторное планирование

Что подлежит мониторингу

Корректировоч-ные действия

Потребности измерения

Обязательства

Что делать

Что создавать

Корректировочные действия

Состояние, спорные вопросы, результаты оценок процессов и продуктов, измерения и анализы

Мониторинг и контроль проекта

Планирование проекта

Управление соглашением с поставщиками

Участники процессов “Проектирование” и “Поддержка”

Поставщик

Рис.5. Взаимодействие процессов

Представленные на рис. 5 базовые участки процесса соответствуют уровню возможностей 1. Для следующих уровней со 2 и выше работы называются «продвинутыми практиками», взаимодействие которых для процесса «Управления проектом» приведены на рис. 6.

Определенный процесс проектирования

Данные об эффективности проекта

Состояние рисков, планы смягчения рисков, корректировочные действия

Интегрированная рабочая среда и практики

Интегрированное управление проектной группой для выполнения процессов проектирования

Координация к сотрудничеству участников проекта

Общее видение и инфраструктура интегрированной и проектной группы для данного проекта

Определенный процесс проекта, координация обязательства, спорные вопросы для решения

Архитектура продукта для структурированных проектных групп

Идентифицированные риски

Задачи, определяемые количественными показателями, подпроцессы, подлежащие статистическому управлению

Извлеченные уроки, данные по планированию и эффективности

Стандартные процессы организации и активы поддержки

Данные статистического управления

Задачи по оценке эффективности процессов, базовые линии, модели

Выявление рисков, обусловленных нестабильными процессами

Управление проектом на основе количеств. показателей

Управление рисками

Участки процесса “Управление процессом”

Интегрирован-ное управление проектом для интегрированной разработки продуктов

Участки процесса “Проектирование” и “Поддержка”

Обеспечение интегрированной проектной группы

Базовые участки процесса “Управление проектом”

рис. 4 и 5 следует - центральным участком как базовых практик, так и всего процесса «Управление проектом» является работа «Планирование». Это же вытекает из тесной взаимосвязи с процессами «Проектирование» и «Поддержка».

Рис.6. Взаимодействие между управляющими и управляемыми участками в процессе «Управления проектом»

По сути, выполнение планирования в рамках процесса «Управления проектом» включает оценку атрибутов рабочих продуктов и задач, определение необходимых ресурсов, идентификацию и анализ связанных с проектом рисков, создание календарных планов и ведение переговоров по обязательствам. Так как при планировании существует необходимость оперировать характеристиками конфигурации рабочих продуктов, то существует тесная взаимосвязь и с участком процесса «Проектирование» - «Разработка требований». План проекта представляет базис для выполнения и контроля работ проекта, направленных на выполнение обязательств заказчика проекта. Как правило, по мере развития проекта и продвижения его по фазам жизненного цикла существует необходимость пересмотра плана проекта, связанная с изменениями в требованиях и обязательствах, неточными оценками, корректировочными действиями и изменениями процессов. На этих участках процесса используются частные работы, определяющие планирование и перепланирование. Таким образом, требования по продукту и компонентам продукта, а также изменение этих требований используются в качестве базиса для планирования и перепланирования. С такой же целью используется взаимосвязь с участком «Управление требованиями» процесса «Проектирование».

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

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

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

- своевременное и твердое принятие решений;

- решение проблем по мере их возникновения;

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

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

Оценки проекта, используемые при планировании, должны включать следующие элементы:

- издержки, связанные с выполнением процессов;

- инфраструктура;

- потребность в ресурсах, включая соответствующее управление и контроль;

- обеспечение качества и контроль;

- управление рисками;

- обеспечение среды программного инжиниринга (SEE);

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

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

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

Рис.7. Измерения характеристики программных средств

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

Базой и организационным механизмом планирования является структура распределения работ (WBS – Work Breakdown Structure). Сама структура распределения работ базируется на архитектуре продукта и обеспечивает схему для организации работ проекта вокруг продуктов, поддержку которых и обеспечивает.

Первоначально для структурирования начальных оценок может быть использована структура работ (WBS) верхнего уровня.

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

- риски и управление ими;

- данные проекта и управление ими;

- ресурсы, их первоначальные оценки, управление и контроль.

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

стоимость и время выполнения. В качестве показателей объема могут быть:

- число функций;

- функциональные точки;

- строки исходного кода;

- число классов и объектов;

- число требований;

- число интерфейсов;

- число страниц;

- число входов и выходов;

- число элементов технического риска;

- объем данных.

Методы определения объема и сложности могут основываться на прошедших валидацию моделях или исторических данных. Достоверность этих оценок основывается на логическом обосновании выбранной модели и характере данных [19].

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

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