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

Столбцы таблицы:

1 Подготовка и определение области управления

2 Планирование

3 Выполнение и контроль

4 Проверка и оценка

5 Завершение

Таблица 10

X- Объективное отображение

О- Субъективное отображение

Таблица 11

Столбцы таблицы:

1 Подготовка и определение области управления

2 Планирование

3 Выполнение и контроль

4 Проверка и оценка

5 Завершение

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

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

Достигнутый прогресс определяется по всем составляющим процесса управления проектом [24]:

1. Прогресс в сравнении с календарным планом:

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

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

2. Мониторинг затрат и затраченного труда при выполнении проекта:

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

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

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

3. Мониторинг атрибутов рабочих продуктов и задач:

- периодическое измерение фактических атрибутов рабочих продуктов и задач, таких как объем или сложность;

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

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

4. Мониторинг обеспечиваемых и используемых ресурсов. Для проектирования программных средств, например использующиеся ресурсы:

- хост - компьютеры и периферийное оборудование;

- сети;

- компьютеры и периферийное оборудование для тестирования программных средств;

- программные средства для целевой компьютерной среды;

- среда проектирования программных средств (инструментальные программные средства).

5. Мониторинг знаний и квалификаций персонала проекта:

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

- идентификация значительных отклонений от расчетов в плане проекта.

6. Мониторинг связанных с проектом рисков:

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

- передача информации по состоянию рисков прямым участникам;

- состояние рисков:

• изменения вероятности реализации риска;
• изменение приоритета риска.

7. Мониторинг управления данными:

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

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

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

8. Мониторинг привлечения участников:

- периодическая проверка состояния привлечения участников;

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

Кроме основного процесса «Разработка» в проект могут быть включены вспомогательные процессы (управление конфигурацией, управление документированием, обеспечение и управление качеством). В общем случае, модели жизненного цикла программных средств, процессы, работы и задачи могут выполняться одновременно, могут быть взаимозависимы; или должны координироваться в режиме итераций на протяжении жизненного цикла программного проекта (рис. 8). Идентифицированные процессы могут иметь итеративную «жизнь» и выполняться с любой частотой повторения и в любом порядке, необходимом для выполнения требований или для достижений целей проекта [22]:

Для последующей формализации процесса «Управление проектом» выбираем модуль эволюционной разработки (табл.7) по следующим причинам:

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

Рис.8. Распределение трудоемкости по фазам жизненного цикла

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

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

3. Эволюционная модель допускает неполное понимание требований в начале проекта и последующую конфигурацию их в версиях.

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

3.4. Системная формализация

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

, где ,

до определения М. Месаровича: или , где X – множество входных результатов (объектов), а Y-множество выходных. Трансформация последнего определения касалась введения цели системы Z, наблюдения N и выбранного метода моделирования G.

Хотя и очевидно, что общие системы чрезвычайно разнообразны, это разнообразие может быть представлено конечным числом типов общих систем, каждая из которых характеризуется определенным эпистемологическим уровнем с соответствующим набором методологических отличий. Так как общие системы образуют пространство, то на нем можно определить типы системных задач и назвать его пространством задач. Любой тип задач определяется в терминах упорядоченных связей между двумя типами систем – начальным и конечным, а также набором типов требований, совместимых с типами этих задач. Для конкретных задач это могут быть цели или ограничения. Задача станет конкретной, если задать конкретные требования и в зависимости от типов требований задать тем самым конкретную исходную систему. Решение системной задачи сводится к решению задач, состояние которых представлены общими системами хорошо определенного типа, т.е. допускается, что из конкретной задачи будет выделен свободно интерпретируемые и конкретно зависимые задачи. Для подобного рода задач созданы достаточно тонкие методы решения в терминах общих систем, не связанных интерпретацией или контекстом [19].