Смекни!
smekni.com

Методические указания по выполнению дипломных работ (стр. 12 из 25)

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

Процессы анализа можно также разделить на основные и вспомогательные процессы.

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

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

─ анализ стоимости - определение соответствия фактической и прогнозной стоимости операций и фаз проекта (директивных);

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

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

Вспомогательные процессы анализа связаны с анализом факторов, влияющих на цели и критерии успеха проекта. Эти процессы включают:

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

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

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

2.2.5. Процессы оперативного управления.

Управление исполнением проекта - это определение и применение необходимых управляющих воздействий с целью успешной реализации проекта.

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

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

─ найти оптимальные корректирующие воздействия;

─ скорректировать план оставшихся работ;

─ согласовать намеченные изменения со всеми участниками проекта.

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

К основным процессам оперативного управления относятся:

─ общее управление изменениями - определение, согласование, утверждение и принятие решений к исполнению корректирующих воздействий и координация изменений по всему проекту;

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

─ управление целями - корректировка целей проекта по результатам процессов анализа;

─ управление качеством - разработка мероприятий по устранению причин неудовлетворительного исполнения.

Среди вспомогательных процессов управления выделяют:

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

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

2.2.6. Процессы завершения.

Проект завершается следующими процессами:

─ закрытием контрактов - завершением и закрытием контрактов, включая разрешение всех возникших споров;

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

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

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

3. Обоснование выбора методологии моделирования бизнес – процессов.

3.1. Проблемная область и требования к ее модели.

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

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

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

К моделям проблемных областей предъявляются следующие требования:

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

─ понятность для заказчиков и разработчиков на основе применения графических средств отображения модели;

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

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

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

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

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

─ время выполнения процессов;

─ стоимостные затраты;

─ надежность процессов;

─ косвенные показатели эффективности, такие как объемы производства, производительность труда, оборачиваемость капитала, рентабельность т.д.

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

Набор средств моделирования проблемной области в настоящее время поддерживается с помощью CASE (Computer Aided Software Engineering) – средств или средств моделирования компонентных технологий.

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

3.2. Матрица согласованных моделей в архитектурах.

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

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