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

В результате успешной реализации процесса управления качеством:

a) в рамках организации создается система качества, которая обеспечивает достижение требуемых проектных уровней качества;

b) предоставляется информация о состоянии качества каждого проекта;

c) организацией (подразделениями) для каждого проекта планируются и выполняются деятельности по управлению системой качества согласно международным стандартам ISO серии 9000.

4.9. Процессы проекта

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

Процессами проекта являются:

 

• процесс планирования проекта;
• процесс оценки проекта;
• процесс контроля проекта;
• процесс принятия решений;
• процесс управления рисками;
• процесс управления конфигурацией;
• процесс управления информацией.

 

ПРИМЕЧАНИЕ. Планирование, оценка и контроль являются ключевыми процессами любой практической деятельности по управлению проектом. Они предусматриваются в управлении любым предприятием, начиная от организации в целом и заканчивая отдельным процессом жизненного цикла программной системы и его деятельностями.

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

4.9.1.1. Цель процесса планирования проекта

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

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

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

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

4.9.1.2. Результаты процесса планирования проекта

В результате успешной реализации процесса планирования проекта:

a) определяются роли, ответственность и полномочия сторон;

b) разрабатывается и утверждается план руководством проекта;

c) разрабатываются и утверждаются календарный план реализации проекта и другие необходимые проектные планы;

d) формально запрашиваются ресурсы и услуги, необходимые для выполнения проекта;

e) определяются критерии для показателей реализации проекта;

f) кадры проекта проходят обучение (инструктаж) в соответствии с планом проекта.

4.9.2. Процесс оценки проекта

4.9.2.1. Цель процесса оценки проекта

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

4.9.2.2. Результаты процесса оценки проекта

В результате успешной реализации процесса оценки проекта:

a) предоставляются данные об исполнении проекта или результаты его оценки;

b) оценивается адекватность ролей, прав и обязанностей участников проекта;

c) оценивается адекватность ресурсов и услуг, необходимых для выполнения проекта;

d) анализируются отклонения в показателях исполнения проекта;

e) вовлеченные стороны информируются о состоянии проекта.

4.9.3. Процесс контроля проекта

4.9.3.1. Цель процесса контроля проекта

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

4.9.3.2. Результаты процесса контроля проекта

В результате успешной реализации процесса контроля проекта:

a) определяется и направляется корректирующее действие, если достижения проекта не удовлетворяют запланированным целям;

b) инициируется повторное планирование проекта, если изменились цели и ограничения проекта или плановые предположения оказались недействительными;

c) санкционируется (или нет) действие по переходу проекта с одного запланированного этапа на другой;

d) достигаются цели проекта.

4.9.4. Процесс принятия решений

4.9.4.1. Цель процесса принятия решений

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

4.9.4.2. Результаты процесса принятия решений

В результате успешной реализации процесса принятия решений:

a) определяются обстоятельства и потребность в решении;

b) определяются альтернативные пути осуществления действий;

c) выбирается предпочтительный ход действий;

d) накапливаются и отражаются в отчетах решения, их обоснования и предпосылки.

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

4.9.5.1. Цель процесса управления рисками

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

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

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

Риски, воздействующие на проект, делятся на четыре категории:

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

b) технологические риски - связанные с работоспособностью элементов системы, архитектурным решением и сборкой разнородных компонентов в единую систему;

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

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

4.9.5.2. Результаты процесса управления рисками

В результате успешной реализации процесса управления рисками:

a) оценка рисков осуществляется в течение всего жизненного цикла программной системы;

b) определяются и классифицируются риски;

c) количественно определяется неблагоприятное воздействие рисков;

d) определяются меры по предотвращению рисков;

e) определяется стратегия управления каждым выявленным риском;

f) предпринимаются меры в отношении рисков, составляющих проблему;

g) ведется отчетность о рисках и их состоянии.

4.9.6. Процесс управления конфигурацией

4.9.6.1. Цель процесса управления конфигурацией

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

4.9.6.2. Результаты процесса управления конфигурацией

В результате успешной реализации процесса управления конфигурацией:

a) определяется стратегия управления конфигурацией;

b) определяются элементы, требующие управления конфигурацией;

c) устанавливаются основы конфигурации;

d) отслеживаются изменения в элементах конфигурации;

e) контролируется выпуск элементов конфигурации;

f) информация о статусе управляемых элементов конфигурации обеспечивается в течение жизненного цикла программной системы.

4.9.7. Процесс управления информацией

4.9.7.1. Цель процесса управления информацией

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

4.9.7.2. Результаты процесса управления информацией

В результате успешной реализации процесса управления информацией:

a) определяется вся подлежащая управлению информация;

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

c) определяются формы представления информации;

d) регистрируется статус информации;

e) поддерживаются актуальность, полнота и действительность информации;

f) информация предоставляется вовлеченным сторонам.

4.10. Технические процессы

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

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

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

 

 

Рисунок 5. Технические процессы жизненного цикла программной системы

 

4.10.1. Процесс концептуального моделирования

4.10.1.1. Цель процесса концептуального моделирования

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

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

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

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

Оформление, согласование и утверждение концепции осуществляются в соответствии с:

a) законом Республики Молдова о нормативных актах Правительства и других органов центрального и местного публичного управления № 317-XV от 18.07.2003 г. („Monitorul Oficial al Republicii Moldova” № 208-210/783 от 03.10.2003 г.);

b) Постановлением Правительства о порядке проведения юридической экспертизы и государственной регистрации ведомственных нормативных актов №1104 от 28.11.1997 г. („Monitorul Oficial al Republicii Moldova” № 6-7/10 от 21.01.1998 г.).

4.10.1.2. Результаты процесса концептуального моделирования

В результате успешной реализации процесса концептуального моделирования:

a) определены цель и назначение моделируемой АИС;

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

c) определены функциональность, информационные объекты и потоки, пути интеграции с другими системами;

d) концепция оформлена, согласована и утверждена заказчиком.

4.10.1.3. Деятельности процесса концептуального моделирования

Деятельности данного процесса показаны на рисунке 6.

 

 

Рисунок 6. Деятельности процесса концептуального моделирования

 

4.10.2. Процесс прикладного моделирования

4.10.2.1. Цель процесса прикладного моделирования

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

Описанный вариант программного продукта поставщик предлагает заказчику в виде бизнес-предложения, краткое содержание которого определено в приложении 1.

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

4.10.2.2. Результаты процесса прикладного моделирования

В результате успешной реализации процесса прикладного моделирования:

a) изучена предметная область;

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

c) разработан единый словарь терминов;

d) определены заинтересованные стороны, а также взаимодействующие организации и сторонние АИС;

e) определены бизнес-процессы и бизнес-роли программной системы;

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

g) утверждены артефакты и передаются для дальнейшей работы.

4.10.2.3. Деятельности процесса прикладного моделирования