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

ОСНОВНЫЕ ПОНЯТИЯ И ПРОЦЕССЫ УПРАВЛЕНИЯ ПРОЕКТАМИ.

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

Управление проектами – это приложение знаний, опыта, методов и средств для удовлетворения требований, предъявляемых к проекту и ожиданий участников проекта. Чтобы удовлетворить этим требованиям и ожиданиям необходимо найти оптимальное сочетание между целями, сроками, затратами, качеством и другими характеристиками проекта. У проекта обязательно имеется одна или несколько целей. Под целями понимается не только конечный результат проекта, но и выбранные пути достижения этих результатов. Достижение целей проекта может быть реализовано различными способами. Для сравнения этих способов необходимы критерии успешности достижения поставленных целей.

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

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

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

 

Модели жизненного цикла.

Стандарт ISO/IEC 12207 не предлагает конкретную модель ЖЦ и методы разработки ПО (под моделью ЖЦ понимается структура, определяющая последовательность выполнения и взаимосвязи процессов, действий и задач, выполняемых на протяжении ЖЦ. Модель ЖЦ зависит от специфики ИС и специфики условий, в которых последняя создается и функционирует). Его регламенты являются общими для любых моделей ЖЦ, методологий и технологий разработки. Стандарт ISO/IEC 12207 описывает структуру процессов ЖЦ ПО, но не конкретизирует в деталях, как реализовать или выполнить действия и задачи, включенные в эти процессы.

К настоящему времени наибольшее распространение получили следующие две основные модели ЖЦ:

• каскадная модель (70-85 г.г.);
• спиральная модель (86-90 г.г.).

В изначально существовавших однородных ИС каждое приложение представляло собой единое целое. Для разработки такого типа приложений применялся каскадный способ. Его основной характеристикой является разбиение всей разработки на этапы, причем переход с одного этапа на следующий происходит только после того, как будет полностью завершена работа на текущем (рис. 1.1). Каждый этап завершается выпуском полного комплекта документации, достаточной для того, чтобы разработка могла быть продолжена другой командой разработчиков.

Положительные стороны применения каскадного подхода заключаются в следующем [2]:

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

Рис. 1.1. Каскадная схема разработки ПО

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

Рис. 1.2. Реальный процесс разработки ПО по каскадной схеме

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

Для преодоления перечисленных проблем была предложена спиральная модель ЖЦ [10] (рис. 1.3), делающая упор на начальные этапы ЖЦ: анализ и проектирование. На этих этапах реализуемость технических решений проверяется путем создания прототипов. Каждый виток спирали соответствует созданию фрагмента или версии ПО, на нем уточняются цели и характеристики проекта, определяется его качество и планируются работы следующего витка спирали. Таким образом углубляются и последовательно конкретизируются детали проекта и в результате выбирается обоснованный вариант, который доводится до реализации.

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

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

Рис 1.3. Спиральная модель ЖЦ

 

Методология RAD.

Одним из возможных подходов к разработке ПО, в рамках спиральной модели ЖЦ, является метод быстрой разработки приложений RAD (Rapid Application Development).

Под ним, обычно понимается процесс разработки ПО, содержащего 3 элемента:

1. небольшую команду программистов;

2. короткий, тщательно проработанных, производственный график;

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

Команда разработчиков – группа профессионалов, имеющих опыт в анализе, проектировании, генерации кода, тестировании ПО с использованием CASE- средств.

ЖЦ ПО, по методологии RAD, состоит из 4 фаз:

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

Результат фазы: список приоритетов функций будущей ИС. Предварительное функциональное и информационное моделирование ИС.

2. Фаза проектирования. Часть пользователей принимает участие в техническом проектировании системы под руководством специалистов – разработчиков. CASE- средства используются для быстрого получения работающих прототипов приложения. Пользователи, взаимодействуя с ними, уточняют и дополняют требования к системе, которые не были выявлены на предыдущей фазе. Более подробно рассматриваются процессы системы. Анализируется и корректируется функциональная модель. Каждая процедура рассматривается более детально. При необходимости для каждого элемента процедуры создаётся частичный прототип, устраняются неясности или неоднозначности. Определяются требования к разграничению доступа к данным. Определяется набор необходимой документации. Оценка количества функциональных элементов. Принимается решение о разделе ИС на подсистемы, поддающиеся обработки одной команды разработчиков за приемлемое время (60 – 90 дней). С использованием CASE- средств проект распределяется между разработчиками.

Результат фазы:

1. общая информационная модель системы;

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

3. точно определённые, с помощью CASE- средств интерфейсы между подсистемами;

4. построен прототипы экранов, отчётов, диалогов.

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

3. Фаза построения. Быстрая разработка приложения. Разработчики производят интерактивное построение реальной системы на основе полученных в предыдущей фазе моделей, требований не функционального характера. Конечные пользователи на этой фазе оценивают полученные результаты и вносят коррективы, если в процессе разработки система перестаёт удовлетворять определённым требованиям. Тестирование системы осуществляется в процессе разработки. После окончания работ производится интегрирование частей системы с остальными, формирование полного программного кода, тестирование совместной работы данной части приложения с остальными, тестирование системы в целом.

Завершение физического проектирование системы:

1. определяется необходимость распределённых данных;

2. анализ используемых данных;

3. производится физическое проектирование БД;

4. определяются требования к аппаратным ресурсам;

5. определяются способы повышения производительности;

6. завершение разработки документации проекта.

Результат фазы: готовая система, удовлетворяющая всем требованиям.

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

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

Методология RAD применяется для небольших проектов, разрабатываемых для конкретных заказчииков. Она не применима для разработки типовых систем или для построения сложных расчётных программ, разработки ОС и т. д., то есть программ требующих большого объёма уникального кода. Методология так же не подходит для разработки приложений реального времени и приложений от которых зависит безопасность людей. Оценка размера приложения производится на основе функциональных элементов. Она не зависит от языка программирования, на котором ведётся разработка. Размер приложения, который может быть выполнен по методологии RAD для хорошо отлаженной среды разработки ИС, с максимально повторяющимися используемыми программой компонентами, определяется следующим образом:

1. <1000 функциональных элементов – один человек;

2. 1000 – 4000 функциональных элементов – одна команда разработчиков;

3. >4000 функциональных элементов – 4000 функциональных элементов на одну команду разработчиков.

Основные принципы методологии RAD:

1. разработка приложений итерациями;

2. необязательно полное завершение работ на каждом этапе ЖЦ;

3. обязательное вовлечение пользователей в процесс разработки ИС;

4. необходимость применения CASE- средств, обеспечивающих целостность проекта;

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

6. необходимость использования генераторов кода;

7. использование прототипирования, позволяющее полнее выяснить и удовлетворить потребности конечных пользователей;

8. тестирование и развитие проекта, осуществляющее одновременно с разработкой;

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

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

 

 

Типы связей межу функциями.

Одним из важных моментов проектирования ИС с помощью методологии SADT является точная согласованность типов связей между функциями.Различают по крайней мере 7 типов связывания:

“0” – тип случайной связности - наименее желательный. Случайная связь возникает когда конкретня связь между функциями мала или полностью отсутствует. Это относится к ситуации, когда имена данных на SADT – дугах в одной диаграмме имеют малую связь друг с другом. В крайнем варианте связь вообще отсутствует.

“1” – тип логической связности. Логическое связывание происходит тогда, когда данные и функции собираются вместе вследствии того, что они попадают в общий класс или набор элементов, но необходимых функциональных отношений между ними не обнаруживается.

“2” – тип временной связности. Связанные во времени элементы возникают вследствии того, что они представляют функции, связанные во времени, когда данные используются одновременно или функции включаются параллельно, а не последовательно.

“3” – тип процедурной связнности. Процедурно связанные элементы появляются сгруппированными вместе вследствии того, что они выполняются втечение одной и той же части цикла и процесса.

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

выходные данные.

 

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

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

В математических терминах необходимые условия для простейшего типа функциональной свяхности имеет следующий вид: C=g(B) = g(f(A))

 

Значимость	Тип связности	Для функции	Для данных
	Случайная	Случайная	Случайная
	Логическая	Функция одного и того же множества или типа	Данные одного и того же множества или типа
	Временная	Функции одного и того же периода времени(операции инициализации)	Данные используются в каком-либо временном интервале
	Процедурная	Функции, работающие в одной и той же фазе или итерации	Данные, используемые во время одной и той же фазе или итерации
	Коммуникационная	Функция, использующая одни и те же данные	Данные, на которые воздействует однеа и та же деятельность
	Последовтельная	Функции, выполняющие последовательное преобразование одних и тех же данных	Данные, преобразуемые последователдьными функциями
	Функциональная	Функции, объединяемые для выполнения одной функции	Данные, связанные с одной функцией

 

Уровни 4-6 устанавливают типы связногстей, которые разработчики считают важнейшими для получения диаграмм хорошего качества.

 

Диаграммы потоков данных (DFD).

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

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

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

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

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

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

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

Основные понятия электронного документооборота

Документ – это совокупность трех составляющих:

1)Физическая регистрация информации

2) Форма представоения информации

3) Активизация определенной деятельности

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

Документ – это слабоструктурированная совокупность блоков или объектов информации, понятная человеку.

Бюрократическая технология – это технология взаимодействия людей, служб и подразделений внутри и вне организации.

Собственно документооборот может быть двух типов:

1)Универсальный, т. е. Автоматизирующий существующие информационные потоки слабоструктурированной нформации.

2) Операционный, т. е. Ориентированный на работу с документами, содержащими операционную атрибутику, вместе с которой ведется слабоструктурированная информация.

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

К основным преимуществам электронного документооборота можно отнести следующие:

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

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

3) Быстрое сохранение новых документов из уже существующих.

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

5) Сокращение времени поиска нужных документов.

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

Комплексная автоматизация этих функций требует создания единого информационного пространства предприяти, в котором сотрудники и руководство могут осуществлять свою деятельность руководствуясь едиными правилами представления и обработки информации в документном и бездокументном виде. Для этого в рамках предприятия требуется создать единую ИС по управлению информацией или единую систему управления документами, включающую следующие возможности: 1)возможность удаленной работы, когда члены одного коллектива могут работать в разных местах; 2)возможность доступа к информации, когда разхные пользователи должны иметь доступ к одним и тем же данным без потерь в производительности и независимо от своего местоположения в сети; 3)возможности средств коммуникации; 4)возможность сохранения целостности данных в общей БД; 5)возможность полного текстового и реквизитного поиска информации; 6)открытость системы, когда пользовтели должны иметь доступ к привычным средствам создания документов и уже существующим документам, созданным в других системах; 7)защищенность информации; 8)удобство настройки на конкретные задачи пользователей; 9)возможность????????????????? системы для поддержки роста организации и защиты вложенных инвестиций.

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

Ось “F” характеризует уровень организации хранения фактографической информации, которая привязана к специфике конкретного рода деятельности кампании или организации.

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

Ось “D” отражает необходимость организации взаимодействия, т. е. Формирования и передачи товаров, услуг или инормации как внутри организации, так и вне ее.

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

Ось “R” вносит в пространство документооборота реглемент процессов прохождения документов, а именно – описание того, какие процедуры, когда и как должны выполняться.

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

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

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

Эволюция модели.

Модель документооборота имеет три основных фазы своей эволюции.

1)Фактографическая. Начало любой деятельности характеризуется обычным периодом накопления первичной информации, имеющую жесткую структуру и атрибутику. Точка оси “F” – это текущее состояние системы документооборота организации. Движение по этой оси вверх характеризует накопление фактографической информации и начиная с определенного момента можно отметить возникновение понятия операция. На этом этапе начинается процесс возникновения неравенства между ранее равноправными документами. После возникновения привязки к конкретным бизнесс-процессам????????????????? Дальнейшая эволюция документооборота в одномерном пространстве уже невозможна. Необходим переход к новой фазе.

 

 

 

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

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

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

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

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

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

Построение ролевой модели

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

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

 

ОСНОВНЫЕ ПОНЯТИЯ И ПРОЦЕССЫ УПРАВЛЕНИЯ ПРОЕКТАМИ.

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

Управление проектами – это приложение знаний, опыта, методов и средств для удовлетворения требований, предъявляемых к проекту и ожиданий участников проекта. Чтобы удовлетворить этим требованиям и ожиданиям необходимо найти оптимальное сочетание между целями, сроками, затратами, качеством и другими характеристиками проекта. У проекта обязательно имеется одна или несколько целей. Под целями понимается не только конечный результат проекта, но и выбранные пути достижения этих результатов. Достижение целей проекта может быть реализовано различными способами. Для сравнения этих способов необходимы критерии успешности достижения поставленных целей.

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

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

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

 

ПРОЦЕССЫ УПРАВЛЕНИЯ ПРЕКТАМИ.

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

Процессы управления проектами могут быть разбиты на 6 основных групп.

1)Процессы инициации – это принятие решения о начале выполнения проекта.

2) Процессы планирования – это определение целей и успеха проекта и разработка рабочих схем, их достижения.

3) Процессы исполнения – это координация людей и других ресурсов для выполнения плана.

4) Процессы анализа – это определение соответствия плана и исполнение проекта по поставленным целям и критериям успеха, и принятие решений о необходимости применения корректирующих воздействий.

5) Процессы управления – это определение необходимости корректирующих воздействий, их согласование, применение и утверждение.

6) Процессы завершения – это формализация выполнения проекта и подведение его к упорядоченному финалу.

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

 

 

Процессы управления проектами связаны своими результатами. Результат выполнения одного становится исходной информацией для другого. В реальном проекте фазы могут не только предшествовать друг другу, но и накладываться. Повторение инициации на разных фазах проекта помогает контролировать актуальность выполнения проекта.

 

I) Процессы инициации.

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

II) Процессы планирования.

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

1)Планирование качества, т. е. Определение того, какие стандарты качества использовать в проекте и как этих стандартов достичь.