Планирование проекта

Цель: разрабатывать и поддерживать планы работ по проекту.

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

Основные рабочие продукты: «Меморандум», Черновой вариант проекта, БД метрик, «Пул метрик», «План проекта», «Календарный план», план в MS Project, , БД персонала, «Договор», различные ТИ, «Таблица рисков».

Проблемы: Специфическая цель «Разработка плана проекта».

Практики: «Создание бюджета и календарного плана».

Выявленное несоответствие: Не разработан документ «Бюджет проекта», т. е. бюджет проекта не описывается детально.

Наблюдение и контроль за проектом

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

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

Основные рабочие продукты: «Отчеты об отклонениях», проверка «Календарного плана» в MS Project, таблица закрытия актов, таблица анализа рисков, технологические проверки. Данные постоянно актуализируются.

Проблема: Специфическая цель «Проверка проекта на соответствие плану».

Практики, требуемые в соответствии с требованиями CMMI (далее Практики): «Проверка плановых параметров процесса», «Проверка рисков проекта», «Проверка привлечения заинтересованных лиц».

Выявленное несоответствие: Не осуществляются записи по привлечению заинтересованных лиц.

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

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

За выполнение многих функций в этой ключевой области отвечает SEPG, например:

Ø  документирование, проверка и переработка цели измерений;

Ø  обеспечение обратной связи для уточнения и разъяснения при необходимости информационных нужд и целей;

Ø  расстановка приоритетов, проверка и переработка процедур сбора и хранения данных;

Ø  проверка и переработка содержимого и формата, предложенных анализа и отчетов и т. п.

SEPG – группа специалистов, собирающаяся по необходимости, с целью решения вопросов об улучшение технологии, процессов, процедур и т. д. В DD в неё входят практически все начальники отделов и сотрудники, уже давно работающие в организации и имеющие высокую квалификацию. Группа собирается периодически для обсуждения таких вопросов, как улучшение процесса (например, процесс тестирования), изменение и улучшение процедуры и т. д.

В компании создан «Пул метрик» – очень важный документ, в котором описаны метрики и определены процедуры их сбора. Для всех метрик в таблицах прописаны: определение, хранение, ответственный (в основном технолог), процедура накопления и т. п.

Пример, вычисляемой метрики «Количество ошибок по этапам проекта»:

Основные рабочие продукты: MS Project, отчеты. БД метрик общедоступна, но мало используется.

Проблемы: Специфическая цель «Обеспечение результатов измерений».

Практика: «Сообщение результатов».

Выявленные несоответствия: Не предоставляются результаты измерений и анализа всем заинтересованным лицам. Считаются показатели, но не анализируются причины возникновения проблем: ошибки, спад и т. д. Данные по проектам из MS Project не всегда актуализируются руководителями проектов и отделов, и статистика по проекту не вносится в «План проекта» должным образом. Собирается недостаточное количество метрик для перехода на 4-ый уровень.

Обеспечение качества процессов и продуктов

Цель: предоставить персоналу и руководству объективную информацию о процессах и связанных с ними рабочих продуктах.

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

Основные рабочие продукты: отчет о технологической проверке, отчет о внутренней проверке, акты о несоответствиях, папки СК и «Технологии» в общих папках на файловом сервере, ТИ.

3-й уровень CMMI

Развертывание требований

Цель: разработать и проанализировать требования заказчика и требования к продукту и его компонентам.

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

Основные рабочие продукты: ТЗ, ТИ по тестированию, «Меморандум», «Договор», «Таблица анализа рисков» и т. д.

Разработка технических решений

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

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

Основные рабочие продукты: «Меморандум», «Таблица принятия решений», ТЗ, история решений, техническая и пользовательская документация

Проблемы: Специфическая цель «Выбор решений для компонентов продукта».

Практика: «Подробная разработка альтернативных решений и критериев отбора решений».

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

Фокус на организационном процессе

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

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

Основные рабочие продукты: «Политика компании в области качества», аудиты ДУК, ежегодный анализ документации, работа SEPG, планы по анализу СМК, анализ СМК руководством, технологические проверки, БД метрик, предложения сотрудников и т. д.

Определение организационного процесса

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

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

Основные рабочие продукты: ВИ по обучению персонала, «Положение об управление риском» и т. д. Существует хранилище измерений организации: БД метрик, «Пул метрик». Создана единая организационная библиотека материалов по выполнению процессов: Перечень всех ТИ и процедур, расположенный на сервере компании.

Организационное обучение

Цель: развивать навыки и знания сотрудников, что позволит им осознано и эффективно выполнять свои функции.

Компания заботится о своих сотрудниках, предлагая им различные курсы по обучению. Проводятся опросы и аттестация для выяснения нужд в обучение. Возможность пройти обучение предоставляется в зависимости от возможности сотрудника. Например, в компании проводятся курсы по английскому языку. Предварительно выясняется уровень владения языком сотрудника и соответственно на основании этого предлагается программа обучения: Pre-intermediate, Intermediаte, Upperintermediate и т. д. Занятия проводятся в вечернее время после окончания рабочего дня.

Основные рабочие продукты: заявки, тесты, аттестация, отзывы, курсы, «План по обучению», БД персонала, должностные инструкции и т. п.

Комплексное управление проектом

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

Проекты компании выполняются посредствам использования определенного для проекта процесса, описанного в ТИ и «Технологии». Планирование и управление проектом происходит на основании «Меморандума» и согласованного «Плана проекта».

Основные рабочие продукты: «Меморандум», ТИ, «Классификация проектов», «Технология», «История принятия решений», «План проекта», БД метрик, «Пул метрик», план проекта в MS Project. Загрузка сотрудников отмечается в плане проекта в MS Project.

Проблемы:

Ø  Специфическая цель «Использование конкретизированного процесса проекта».

Практика: «Внесение вклада в организационные материалы по выполнению процесса».

Выявленное несоответствие: Отсутствие базы ПИ-компонент.

Ø  Специфическая цель «Координация и сотрудничество заинтересованных сторон».

Практика: «Управление привлечения заинтересованных лиц».

Выявленное несоответствие: Очень редко разрабатывается план взаимодействия с заказчиком.

Управление рисками

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

В документации компании определены возможные источники возникновения рисков, критерии оценки риска для последующего анализа и уменьшения влияния на проект. Сотрудники компании регулярно отслеживают статус и степень влияния каждого риска, а также вносят соответствующие примечания в план проекта в MS Project.

Основные рабочие продукты: «Таблица анализа рисков», ВИ «Перечень часто встречающихся рисков», «Положение об управление рисками», градация вероятности возникновения риска, план проекта в MS Project. Риски анализируются еженедельно.

Анализ решений и вынесение резолюций

Цель: проанализировать возможные решения, используя формальную оценку процесса, которая рассчитывает обозначенные альтернативы по установленному критерию и вынести соответствующие резолюции.

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

Основные рабочие продукты: ТИ, история принятия решений, «Таблица принятия решения».

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

2-й уровень CMMI

Управление соглашениями с поставщиками

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

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

Основные рабочие продукты: Договор с поставщиками, Меморандум, ТЗ для субподрядчика, План проекта, взаимодействия с ОПР.

Проблемы:

Ø  Специфическая цель «Создание соглашений с поставщиками».

Практика: «Выбор поставщиков».

Выявленные несоответствия: Сотрудниками компании не ведется список кандидатов в поставщики, не документируется анализ достоинств и недостатков кандидатов в поставщики. Не формализованы оценочные критерии при выборе поставщика.

Ø  Специфическая цель «Выполнение соглашений с поставщиками».

Практики: «Приобретение готовых продуктов», «Выполнение соглашения с поставщиком», «Передача продуктов».

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

Управление конфигурацией

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

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

Основные рабочие продукты: ТИ, ТЗ, отчеты по управлению конфигурацией, отчеты о технологических проверках, история версий.

Проблемы:

Ø  Специфическая цель «Создание оценок».

Практика: «Создание системы управления конфигурацией»

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

Ø  Специфическая цель «Отслеживание и контроль изменений».

Практика: «Отслеживание изменений».

Выявленное несоответствие: Нет запросов на изменение.

3-й уровень CMMI

Интеграция продукта

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

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

Основные рабочие продукты: ТИ, Технология, отчеты о тестирование, инструкции по установке

Проблемы: Специфическая цель «Подготовка к интеграции продукта».

Практики: «Разработка стратегии интеграции продукта», «Разработка среды интеграции продукта», «Подробное определение процедур интеграции продукта».

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

Верификация

Цель: удостоверится, что отобранные рабочие продукты отвечают установленным для них требованиям.

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

Основные рабочие продукты: ТИ, отчет о тестирование, Технология

Проблемы: Специфическая цель «Проведение экспертных оценок».

Практика: «Подготовка экспертных оценок».

Выявленное несоответствие: Не составляется календарный план экспертных оценок, контрольная таблица экспертных оценок и т. д.

Валидация

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

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

Основные рабочие продукты: ТИ, отчет о тестирование, демонстрации заказчику.

Проблемы: Специфическая цель «Подготовка к валидации».

Практики: «Определить среду валидации».

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

ВЫВОД

Проведенный мониторинг практик ключевых областей 2 и 3-го уровней CMMI показал, что в компании полностью выполняются лишь практики 13-ти ключевых областей из 18, причем это – 5 ключевых областей 2–го уровня и 8 областей 3-го уровня: Управление требованиями (2), Планирование проекта (2), Наблюдение и контроль за проектом (2), Измерение и анализ (2), Обеспечение качества процессов и продуктов (2), Развертывание требований (3), Разработка технических решений (3), Фокус на организационном процессе (3), Определение организационного процесса (3), Организационное обучение (3), Комплексное управление проектом (3), Управление рисками (3) и Анализ решений и вынесение резолюций (3). Хотя также следует отметить, что и по реализации практик данных областей есть небольшие недоработки, пример:

Практики остальных 5 ключевых областей 2 и 3-го уровня: Управление соглашениями с поставщиками (2), Управление конфигурацией (2), Интеграция продукта (3), Верификация (3), Валидация (3) выполняются частично, т. к. большинство плохо документировано, пример:

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

4.4. Проектная деятельность

Для понимания реальной ситуации в компании недостаточно только рассмотреть её документацию, СМК, проверить соответствие 3-му уровню стандарта CMMI, необходимо проанализировать ее проектную деятельность.

Основной документ компании - «Технология в DD», в котором представлена общая схема процесса для проектов по разработке ПО – маршрутная карта, включающая следующие ключевые этапы:

Ø  подготовка договора;

Ø  проектирование;

Ø  реализация;

Ø  тестирование;

Ø  внедрение и опытная эксплуатация;

Ø  поддержка;

Ø  ролевая модель.

Рис.21. Ролевая проектная модель в компании DD

В ролевой модели для каждой роли определена сфера ответственности, например, интегратор - сборка версий, конфигурационное управление, предварительное тестирование и т. д.

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

Пристальное внимание уделяется удовлетворенности клиента. Ведется специальная БД по удовлетворенности заказчиков DD. Составляются анкеты- опросы клиентов по проектам каждого отдельного департамента, где клиент прописывает на свой взгляд сильные и слабые стороны, оставляет комментарии по конкурентам.

Собирается статистика, в том числе данные по анкетам в разрезе БЕ:

Ø  индекс удовлетворенности;

Ø  количество оцененных проектов;

Ø  полученные/отправленные анкеты и т. д.

Рейтинг возврата анкет за 2007 год составил 73%:

Средние показа%. По сравнению с предыдущими годами наблюдается сохранение рейтинга. В целом CSI компании за 2007 год составил 7,8 баллов из 10.

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

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

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

Начиная с 2002 года, в компании ведутся Checklists проектов по кварталам, где представлены: процессы, их описание с комментариями технолога/руководителя проекта, сроком исправления, и таблица проведения технологических проверок. Осуществляется сбор данных о проектах, реализуемых компаний, из Microsoft Project Professional. В разрабатываемых таблицах фиксируется: название проекта, отдел, год осуществления, трудозатраты, длительность, перерасход, и на основе этого подготавливаются различные графики и составляются соответствующие отчеты с предложениями по улучшению сложившейся ситуации.

В компании мне была поставлена задача, на основании различной документации и MS Project Professional, собрать статистику по проектам компании DD за года и частично за 2002–2005 года, и на основании полученных данных построить графики, наглядно демонстрирующие реальную ситуацию по реализации проектов, используя Statistica 6.0[34] функцию «Histogram: Block Columns» (см. Приложение 2).

Исследование показателей по реализации проектов ДПР за гг.

Для проектов, выполняемых ДПР Digital Design, можно выделить три основные модели проектов. Эти модели определяют порядок взаимодействия ДПР (в роли исполнителя) с заказчиками и посредниками:

Ø  классическая модель разработки/поддержки заказного ПО;

Ø  модель работы с посредником;

Ø  модель разработки внутренних проектов.

На основании перечисленных моделей в компании выделено 4 основных типа проектов:

Ø  проекты по разработке заказного ПО;

Ø  внутренние проекты;

Ø  проекты поддержки;

Ø  проекты по разработке под DocsVision (собственная платформа).

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

Ø  проекты Fixed Price;

Ø  проекты Time and Material.[35]

В рамках исследования проводится анализ изменения результативности[36] планирования сроков и трудозатрат на реализацию проектов Fixed Price в целом ДПР и его отделов, выполняющим наибольшее количество проектов: ОМП и ОПТ (см. Приложение). В ходе исследования проанализированы 130 проектов департамента, из которых:

Всего проанализированы данные по более 200 проектам ДПР (см. Приложение).

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

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

Рис.22. Изменение результативности процессов с увеличением

уровня зрелости компании

Составлено по: международный стандарт CMMI.

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

1)  «Относительный перерасход по длительности» (в %): ;

2)  «Относительный перерасход по трудозатратам» (в %): .

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

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

Статистический анализ проводился с использованием программы Statistica 6.0, Histogram: Block Columns.

Анализ изменения результативности планирования сроков и ресурсов на реализацию проектов ДПР за период гг. (см. Приложение 3)

Рис.23. Относительный перерасход по длительности при реализации проектов

Кривые, соответствующие 2003, 2004, 2005, 2006, 2007 г., характеризуются данными, представленными в таблице ниже.

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

Рис.24. Относительный перерасход по трудозатратам при реализации проектов

Кривые, соответствующие 2003, 2004, 2005, 2006, 2007 г., характеризуются данными, представленными в таблице ниже.

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

Выводы: Значения выбранных показателей не улучшились за 2007г.

Исследование показателя «перерасход по длительности» на каждом этапе реализации проектов ДПР за гг. (см. Приложение 4)

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

Технологические этапы работ по проекту:

Ø  анализ;

Ø  проектирование;

Ø  кодирование;

Ø  дизайн;

Ø  внутреннее тестирование;

Ø  документирование;

Ø  внешнее тестирование;

Ø  внедрение;

Ø  обучение;

Ø  техническая поддержка.

Рис.25. Относительный перерасход по длительности на этапе «Анализ»

Кривые, соответствующие 2004, 2005, 2006, 2007 г., характеризуются данными, представленными в таблице ниже.

Вывод: планирование длительности на реализацию этапа проектов «Анализ» в 2007 улучшилось по сравнению с 2006 годом, однако в целом с 2004 года показатель ухудшился.

Рис.26. Относительный перерасход по длительности на этапе «Внутреннее тестирование»

Кривые, соответствующие 2005, 2006, 2007 г., характеризуются данными, представленными в таблице ниже.

Вывод: планирование длительности на реализацию этапа проектов «Внутреннее тестирование» в 2007 г. существенно улучшилось по сравнению с 2005 годом.

ВЫВОДЫ (см. Приложение 2)

Ø  Планирование сроков и трудозатрат на реализацию проектов в ДПР не улучшилось за 2007 по сравнению с 2006 годом, но улучшилось по сравнению с 2003 г. Относительные значения по срокам и трудозатратам превышают целевое значение (полное соответствие плановых затрат фактическим) и составляет около 26%, что соответствует лишь 3-му уровням CMMI.

Ø  В ОМП планирование сроков и трудозатрат ухудшилось за 2007 год по сравнению с 2006 годом, но улучшилось по сравнению с 2003 годом.

Ø  В ОПТ планирование сроков и трудозатрат ухудшилось за 2006 год по сравнению с 2004 годом, но заметно улучшилось по сравнению с 2003 годом.

Ø  Планирование длительности на реализацию этапа проектов «Анализ» в 2007 г. улучшилось по сравнению с 2006 годом, однако в целом с 2004 показатель ухудшился.

Ø  Планирование длительности на реализацию этапа проектов «Внутреннее тестирование» в 2007 году существенно улучшилось по сравнению с 2005 годом.

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

4.5. Рекомендации по улучшению степени выполнения практик ключевых областей 2 и 3-го уровней CMMI

Компания DD поставила перед собой перспективную цель – сертификацию по стандарту CMMI на 4-ый уровень зрелости. Для осуществления поставленной цели был проведен аудит СМК на соответствие областям усовершенствования 2 и 3-го уровней. В ходе проверки был выявлен ряд недоработок, на основании этого были сформированы рекомендации по реализации оставшихся областей усовершенствования 2 и 3-го уровней.

4.5.1. Общие рекомендации по 2 и 3-му уровням стандарта CMMI

2-ой уровень CMMI

Планирование проекта

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

Рекомендация

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

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

Рекомендация к практике «План Необходимых Знаний и Опыта»

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

Наблюдение и контроль за проектом

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

Рекомендация

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

Управление соглашениями с поставщиками

Не документированы практики связанные с:

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

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

Ø  оценкой готовых коммерческих продуктов.

Рекомендации

Компании DD давно функционирует на рынке и имеет надежных поставщиков, с которыми налажены долгосрочные связи. В процессе работы с поставщиками за годы были наработаны устойчивые отношения и определены все основополагающие моменты в процессе работы друг с другом. В компании ведется спISOк признанных поставщиков, ответственный за него директор ДУК. За оценку поставщиков отвечают директора соответствующих департаментов. Так как компания работает с признанными поставщиками, то все работы осуществляются согласно договору. Однако следует проработать процедуры для работы с потенциальными поставщиками, которые позволят произвести качественный отбор поставщиков на основе выработанных определенных критериев (разработать критерии оценки и т. п.), следить за ходом выполнения договора, и т. д.

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

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

Рекомендации

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

Управление конфигурацией

Не выполняются практики связанные с:

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

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

Рекомендации

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

3-ий уровень CMMI

Разработка технических решений

Не полностью выполняется практика связанная с разработкой альтернативных технических решений и критериев их отбора.

Рекомендация

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

Интеграция продукта

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

Рекомендация

Данные практики в компании выполняются, но они не формализованы и не регламентированы. Необходимо описать их в документе «Технология» и четко следовать установленному порядку.

Верификация

Не выполняется практика связанная с проведением экспертных оценок

Рекомендация

Необходимо разработать процедуру проведения экспертных проверок отобранных рабочих продуктов:

Ø  создать календарный план экспертных оценок;

Ø  контрольная таблица экспертных оценок;

Ø  учебные материалы по экспертным оценкам и т. п.

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

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

Валидация

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

Рекомендация

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

Комплексное управление проектом

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

Рекомендации

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

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

4.5.2. Программный продукт Microsoft Visual Studio Team System 2008[37]

Руководство компании DD заинтересовано в приобретение продукта Microsoft Visual Studio Team System 2008 на уровне ДПР, который занимается разработкой программных решений, и мне было предложено выполнить следующее задание: исследовать функции VSTS 2008 на предмет покрытия ими практик ключевых  областей  CMMI 2 и 3-го уровней.

Руководство и сотрудники департамента заинтересованы в:

Ø  повышении уровня прозрачности процесса разработки ПО;

Ø  вовлечении в процесс коллективной работы всех участников проекта: архитекторов, разработчиков, тестировщиков;

Ø  создании систем хранения требований и управления дефектами;

Ø  совершенствовании технологического процесса разработки;

Ø  создании налаженного механизма сбора и анализа требований и т. п

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

В VSTS предусмотрены две модели процессов разработки ПО:

Ø  Microsoft Solutions Framework (MSF)[38] for CMMI process improvement строго документированный процесс, в котором большое внимание уделено планированию, верификации и аудиту. Модель ориентирована на большие команды и длительные проекты. Ее главное достоинство – высокая управляемость и предсказуемость результата. Кроме того, формальные процессы являются основой для выполнения требований стандарта CMMI 3-го уровня;

Ø  MSF for Agile Software Development слабо формализованная версия MSF, которая предназначена для проектов, опирающихся на высококвалифицированные кадры и разработку с постепенным развитием прототипов будущей системы. Данная модель идеальна в условиях сильной конкуренции и быстрой разработки в изменяющихся условиях, однако результат использования MSF Agile менее предсказуем, чем в случае применения MSF для CMMI Process Improvement.

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

Как продукт, Visual Studio Team System состоит из сервера и набора клиентских приложений.

Сервер Microsoft Visual Studio Team System 2008 Team Foundation Server (TFS)

TFS – это ядро системы, обеспечивающее эффективную совместную работу всех членов группы и высокое качество программного обеспечения.

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

Основные функции:

Ø  управление проектами;

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

Ø  отслеживание рабочих элементов для взаимодействия и управления работой группы;

Ø  создание отчетов и анализ состояния, производительности и показателей качества проект;

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

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

Из за большого объема этот материал размещен на нескольких страницах: 1 2 3 4 5 6