Категории
Самые читаемые
onlinekniga.com » Компьютеры и Интернет » Программирование » Модель зрелости процессов разработки программного обеспечения - Марк Паулк

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

Читать онлайн Модель зрелости процессов разработки программного обеспечения - Марк Паулк

Шрифт:

-
+

Интервал:

-
+

Закладка:

Сделать
1 ... 19 20 21 22 23 24 25 26 27 ... 44
Перейти на страницу:

Операция 9 Отслеживание технических операций по проекту разработки, при необходимости — применение корректирующих действий.

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

2. Содержимое успешных сборок продукта сравнивается с планом разработки ПО.

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

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

Практики, связанные с выявлением рисков, содержатся в описании Операции № 13 группы ключевых процессов «Планирование проекта».

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

2. Менеджер проекта регулярно проверяет области с высокой степенью риска.

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

Практики, связанные с документированием данных по проекту, содержатся в описании Операции № 15 группы ключевых процессов «Планирование проекта».

1. Записи включают в себя оценочные данные и дополнительные сведения, необходимые для воспроизведения оценочных расчетов и проверки их обоснованности.

2. Данные по изменениям в плане проекта разработки должны быть управляемыми и контролируемыми.

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

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

В этих проверках принимают участие:

1. Линейные менеджеры и подчиненные им ведущие специалисты.

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

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

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

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

В этих практиках термином «конечные пользователи» называются конечные пользователи, определенные заказчиком, либо их представители.

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

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

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

6. В ходе проверок изучаются риски проекта разработки.

7. В случае необходимости, по результатам проверок уточняется план разработки ПО.

Измерения и анализ

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

Примеры измерений: определение объема трудозатрат и других ресурсов, вложенных в выполнение работ по отслеживанию хода проекта и контролю над ним; определение статуса изменений плана разработки

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

Проверка внедрения

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

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

1. Проверка технических, финансовых, кадровых аспектов и выполнения графика.

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

3. Изучение рисков проекта разработки.

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

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

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

1. В проверках принимают участие представители задействованных групп.

2. Технические, финансовые, кадровые аспекты и показатели календарного графика сравниваются с планом разработки ПО.

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

4. Обсуждение зависимостей между группами.

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

6. Изучение рисков проекта разработки.

7. Поручение и проверка задач, а также отслеживание их выполнения.

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

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

См. группу ключевых процессов «Обеспечение качества ПО».

Минимальное содержание проверок и/или аудитов:

1. Мероприятия по пересмотру и изменению обязательств.

2. Мероприятия по изменению плана разработки ПО.

3. Содержание измененного плана разработки ПО.

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

5. Мероприятия по проведению плановых технических и административных проверок.

8.4. Управление производственным субподрядом

Группа ключевых процессов для уровня 2: повторяемый уровень.

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

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

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

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

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

Цели

Цель 1 Выбор генеральным подрядчиком квалифицированных субподрядчиков.

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

1 ... 19 20 21 22 23 24 25 26 27 ... 44
Перейти на страницу:
На этой странице вы можете бесплатно читать книгу Модель зрелости процессов разработки программного обеспечения - Марк Паулк.
Комментарии