Обеспечение качества проекта на этапе проектирования

СОДЕРЖАНИЕ

Обеспечение качества проекта на этапе проектирования. Обеспечение целостности элементов конфигурации……………………………………2

Обновление реестра рисков на фазе проектирования. Набор команды проекта. Описание процесса……………………………………………….6

Планирование инфраструктуры для команды проекта…………………..13

Разработать расписание проекта ИС «Расписание» методом критического пути…………………………………………………………………………..14

Используемая литература………………………………………………...24

1. ОБЕСПЕЧЕНИЕ КАЧЕСТВА ПРОЕКТА НА ЭТАПЕ ПРОКТИРОВАНИЯ

Работы по обеспечению качества проекта на фазе проектирования направлены на решение следующих задач.

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

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

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

На этапе планирования фазы проектирования ЖЦ ИТ руководитель проекта совместно с менеджером по качеству выполняет корректировку программы обеспечения качества проекта.

Для этого предварительно менеджером по качеству осуществляются:

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

настройка рабочей среды;

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

настройка инфраструктуры, тестирование системы;

выполнение системного и пользовательского теста;

установка рабочей среды;

выполнение теста на запуск;

подготовка и проведение обучения для конечных пользователей;

корректировка графика выполнения, списка ответственных за обеспечение качества;

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

создание спецификаций на проектирование;

создание технических спецификаций;

определение методов интеграции и модификаций;

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

определение дополнительных требований к обучению;

настройка конфигурации;

установка среды разработки;

установка среды тестирования;

разработка функциональных характеристик;

тестирование параметров/функций;

тестирование процессов;

общее тестирование;

создание технической и пользовательской документации;

проверка наличия необходимых процедур;

доработка процедур обеспечения и контроля качества на этапе производства (настройки и внедрения).

Обеспечение целостности элементов конфигурации

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

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

Реализуемое на данной стадии сопровождение и контроль документов, как и прежде, предусматривает сохранение и ведение документации по проекту. Цель подпроцесса - гарантировать:

доступ к документам для ознакомления;

защиту документов от несанкционированного доступа;

контроль за ведением документов;

осведомленность получателя о статусе документа;

обеспечение процедуры обзора и утверждения документа.

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

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

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

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

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

описание элементов;

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

момент времени, в который были зафиксированы базовые наборы;

версия и изменения для каждого базового набора;

состояние элемента;

причина изменения конфигурации.

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

2. ОБНОВЛЕНИЕ РЕЕСТРА РИСКОВ НА ФАЗЕ ПРОЕКТИРОВАНИЯ

Для фазы проектирования ЖЦ ИС наиболее типичны следующие источники рисков :

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

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

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

оценка рисков проекта не корректируется;

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

Наиболее распространенными действиями, направленными на смягчение вышеперечисленных рисков, являются действия, направленные на то, чтобы:

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

на предыдущем этапе устанавливать состав критичного для данного этапа персонала;

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

заранее планировать и своевременно проводить тестирование нового ПО;

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

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

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

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

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

Набор команды проекта

Основными задачами управления персоналом на стадии проектирования ЖЦ являются:

внесение корректировок в план управления персоналом с учетом согласованных изменений предыдущей стадии;

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

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

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

развитие команды проекта.

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

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

Описание процесса

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

Согласно PMBOK  набор команды проекта - это процесс привлечения человеческих ресурсов, необходимых для выполнения проекта.

При наборе членов команды проекта необходимо учитывать следующее:

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

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

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

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

стоимость - величина оплаты труда потенциального члена команды.

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

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

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

Рис. 10.7. Шаблон организационной диаграммы

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

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

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

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

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

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

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

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

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

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

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

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

4. Разработка расписания проекта  методом критического пути

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

Создать перечень операций, которые должны быть включены в расписание.

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

Определить длительность каждой операции.

Длительность каждой операции определялась в рамках процессов оценки трудоемкости и определения длительности операций (см. соответствующие разделы издания).

Определить предшествующую операцию для каждой операции.

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

Рассчитать с помощью прямого прохода (forward pass) раннее расписание (early schedule): ранний старт (ES) и ранний финиш (EF) для каждой операции.

При расчете раннего расписания для операций требуется придерживаться нескольких правил составления расписаний (scheduling conventions). Данные правила приняты сообществом по составлению расписаний (scheduling community). В расписании старт первой операции всегда назначается на дату старта проекта. Эта дата является входом плана проекта. Первая дата старта является стартом проекта. Дата раннего финиша - это дата раннего старта плюс длительность операции. При этом применяется следующее правило. Считается, что каждая операция начинается в момент начала того периода, в который она стартует, и оканчивается в момент завершения периода, в который она завершается. Это означает, что еслидлительность операции составляет один день и если она начинается первого января, то заканчивается данная операция также первого января. В соответствии с данным правилом ранний финиш любой операции равен раннему старту плюс длительность минус один. Таким образом, операция 1 начинается в день 1 и заканчивается в день 15 (см. табл. 3.3). Следующая операция должна начаться в следующий доступный временной период: поскольку операция 1 заканчивается в день 15, операция 2 должна начаться в день 16, а закончиться в день 20. Операции 3 и 4 представляют следующую проблему. Эти операции зависят от операции 2, т. е. операция 2 должна окончиться перед их стартом. Очевидно, что датой раннего старта обеих операций будет день 21.

Формула 1. Расчет раннего финиша

EF=ES + Длительность - 1

Рассчитать с помощью обратного прохода (backward pass) позднее расписание (late schedule) для каждой операции.

Для выполнения обратного прохода необходимо начинать с последней операции, которая была выполнена в раннем расписании. Логическим обоснованием этого является следующее: если раннее расписание определяет самую раннюю дату завершения проекта, то в обратном проходе мы ищем для всех операций самые поздние даты их выполнения, при которых проект мог бы быть полностью выполнен. Мы начинаем с наиболее поздней из дат раннего финиша, соответствующей завершению последней операции. Это время позднего финиша (LF). Для получения времени позднего старта (LS) из времени позднего финиша вычитается длительность. Даты позднего расписания (поздний старт и поздний финиш) для операции 11 будут соответственно днями 90 и 94. Поскольку дата позднего старта операции 11 - день 90, операции 10 и 3 должны быть окончены не позднее дня 89. Это будет датой позднего финиша для обеих операций. Таков самый поздний срок завершения данных операций для того, чтобы обеспечить завершение проекта в день 94 и дату позднего старта операции 11. Для получения дат позднего старта для каждой операции вычитаются их длительность. При рассмотрении операции 2 надо быть очень внимательными в выборе даты позднего финиша, которая также согласуется с датами позднего старта операций 3, 4 и 6. Поскольку датами позднего старта операций 3, 4 и 6 являются дни 86, 53 и 21, соответственно, датой позднего финиша операции 2 является день 20.

Формула 2. Расчет позднего финиша

LS=LF - Длительность + 1

Вычислить временной резерв ( float ) для каждой операции.

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

Формула 3. Расчет временного резерва

float = LS - ES = LF - ES

Определить критический путь (critical path).

Критический путь (critical path) - это последовательность операций, имеющих нулевой временной резерв (zero float). Операции с нулевым временным резервом - это операции, задержка которых обязательно влечет за собой задержку окончания всего проекта. Операции такого типа необходимо жестко контролировать, чтобы обеспечить завершение работы над проектом в установленное время. И наоборот, операции, которые не лежат на критическом пути и имеют ненулевой временной резерв, необязательно контролировать так жестко. К тому же, важно знать, выполнение каких операций проекта может быть задержано без изменения даты завершения проекта. Ресурсы операций, имеющих резерв времени, при необходимости могут быть использованы для выполнения обхода (workaround).

Определить, не состоится ли предполагаемое завершение проекта раньше даты обязательства (promise date).

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

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