Рисунок 2. Общий и проектно определенные процессы и средства их поддержки (среда) в организации
| СТАТЬЯ |
05.11.01
|
Вы хотите обойти конкурентов? Воспользуйтесь Rational Unified Process
Как достичь 3-го уровня CMM
© Леонид Новиков, Interface Ltd.
Характеристики 3-го уровня, "Определенный"
KPA 3-го уровня
3-й уровень и Rational Unified Process
Определение процесса в организации
Программа обучения
Интегральное управление разработкой ПО
Проектирование программного продукта
Межгрупповая координация
Экспертная оценка
Заключение
Мы продолжаем знакомиться с возможностями Rational Unified Process (RUP) , которые могут помочь Вам достичь 2-го и 3-го уровней зрелости CMM.
В предыдущей статье Вам был предложен краткий обзор CMM и описаны возможности RUP, обеспечивающие достижение 2-го уровня CMM. В этой статье говорится о возможности достижения 3-го уровня.
Характеристики 3-го уровня, "Определенный"
На уровне "Определенный" документирован стандартный процесс разработки и сопровождения ПО всей организации, включая и непосредственно разработку ПО, и процессы управления, причем эти процессы интегрированы в согласованное целое. Стандартный процесс CMM обозначается как стандартный процесс разработки программного обеспечения в организации. Процессы, установленные на 3-м уровне, используются (и изменяются), чтобы помочь руководителям проектов и техническому персоналу работать более эффективно. Организация использует эффективные действия разработки программного обеспечения для стандартизации своих процессов. Имеется группа, которая является ответственной за действия процесса разработки в организации. В организации реализована обширная программа обучения, чтобы гарантировать, что коллектив и руководители имеют знания и навыки, необходимые для выполнения назначенных ролей.
Проекты используют стандартный процесс разработки ПО организации для разработки своего собственного процесса, который пригоден для уникальных характеристик проекта.
В CMM этот приспособленный процесс называется проектно определенным процессом разработки ПО.
Хорошо определенный процесс может быть охарактеризован как включающий критерии готовности к старту, исходную информацию, стандарты и процедуры для выполнения работ, механизмы проверки (типа экспертной оценки и тестирования), выходную информацию и критерии завершения. Так как процесс разработки хорошо определен, руководство имеет хорошее понимание технического продвижения всех проектов.
Процесс разработки ПО организации 3-го уровня в итоге должен быть получен как стандартный и непротиворечивый, потому что и непосредственная разработка и управление действиями устойчивы и повторяемы. В пределах установленных производственных линий контролируются затраты, график, функциональные возможности и качество ПО. Эта возможность процесса основана на общем для всей организации понимании действий, ролей и обязанностей в определенном программном процессе.
3-й уровень и Rational Unified Process
Фокусирование организации на процессе
Цель фокусирования организации на процессе состоит в том, чтобы установить в организации ответственность за действия над процессом разработки ПО, которые улучшают потенциальные возможности процесса. Первичный результат действий фокусирования организации на процессе - это набор средств процесса, которые описаны в определении процесса для организации. Эти средства используются программными проектами, как описано в КПА "Интегральное управление разработкой ПО".
Цель 1: Действия разработки и уточнения процесса разработки ПО скоординированы во всей организации.
RUP - это итеративный процесс, который предполагает повторное выполнение "того же самого" определенного процесса в некотором числе итераций. Этот повторяющийся характер введения в действие процесса и оценки состояния и уроков, полученных в каждой стадии и итерации, обеспечивает возможность подстройки процесса для каждой последующей итерации.
Цель 2: Сильные и слабые стороны процесса разработки ПО идентифицированы относительно стандарта процесса.
RUP представляет общий процесс разработки ПО, который может быть приспособлен для эффективного использования на любом данном типе проекта. Указания о том, как приспосабливать RUP даются в Руководящих указаниях по конфигурированию процесса и в Наборе инструментов для развития RUP. Другие технические и управленческие сложности, некоторые из особенностей процесса, которые определяют "форму" используемого в проекте процесса, это:
Цель 3: Развитие процесса уровня организации и действия уточнения запланированы.
Этот цель 3-го уровня полностью зависит от внедряющей организации.
Определение процесса в организации
Цель определения процесса в организации состоит в том, чтобы разработать и поддерживать используемый набор средств процесса разработки программного обеспечения, которые улучшают эффективность процесса в проектах в целом и обеспечивают базу для совокупных, долгосрочных преимуществ организации. Эти средства обеспечивают устойчивую основу, которую можно воплотить через механизмы типа обучения, которое описано в KPA "Программа обучения".
Цель 1: Стандартный процесс разработки ПО в организации разработан и поддерживается.
RUP может обеспечить управляемый старт и служить базовым процессом разработки ПО организации, который может быть развит, приспособлен и поддержан.
Цель 2: Информация, связанная с использованием стандартного процесса проектов разработки ПО в организации собрана, рассмотрена и сделана доступной для всех проектов.
Эта цель должна поддерживаться организацией, которая внедряет RUP.
Рисунок ниже иллюстрирует некоторую рекомендуемую RUP инфраструктуру определения процесса в организации.
Рисунок 2. Общий и проектно определенные процессы и средства
их поддержки (среда) в организации
Цель программы обучения состоит в том, чтобы развить навыки и знания индивидуумов так, чтобы они могли выполнять свои роли эффективно и действенно. Обучение - это ответственность организации, но программные проекты должны идентифицировать необходимые навыки и обеспечивать необходимое обучение, когда потребности проекта уникальны.
Цель 1: Действия обучения запланированы.
Эта цель может быть выполнена организацией, внедряющей RUP. Однако, RUP - это база знаний "лучшего опыта индустрии", предоставляющая рекомендации, концепции и детальные пошаговые описания того, как выполнять различные действия разработки программного обеспечения. Кроме того, RUP - сам по себе хороший источник для изучения материала.
Кроме того, связанные с RUP курсы поддержки включают:
Цель 2: Обучение обеспечивает развитие навыков и знаний, необходимых для выполнения ролей управления и выполнения программного проекта.
Цель 3: Личности в группе разработки программного обеспечения и в связанных с ней группах получают обучение, необходимое для выполнения своей роли.
Эти цели программы обучения должны быть выполнены организацией, которая внедряет RUP. Однако RUP обеспечивает диапазон курсов, перечисленных в предыдущем разделе.
Интегральное управление разработкой ПО
Цель интегрального управления разработкой ПО состоит в том, чтобы интегрировать действия непосредственной разработки и управления в согласованный, определенный процесс, который приспособлен из стандартного процесса разработки ПО организации и связывает средства процесса, которые описаны в KPA "Определение процесса в организации". Это приспосабливание базируется на бизнес среде и технических потребностях проекта, как описано в KPA "Проектирование программного продукта". Интегральное управление разработкой ПО развивается из KPA "Планирование проекта ПО" и KPA "Отслеживание и надзор за программным проектом", определенных на 2-ом уровне.
Цель 1: Проектно определенный процесс разработки ПО - это приспособленная версия стандартного процесса в организации.
В соответствии с "Руководством по конфигурированию процесса", стандартная поставка RUP имеет возможность приспосабливания конфигурации и повторного обзора для использования в проектах различных типов.
Цель 2: Проект запланирован и управляется согласно проектно определенному процессу.
Эта цель должна быть разрешена организацией, которая внедряет RUP.
Проектирование программного продукта
Цель проектирования программного продукта состоит в том, чтобы последовательно выполнить четкий процесс проектирования, который объединяет все действия, чтобы произвести правильные, непротиворечивые программные продукты эффективно и действенно. Проектирование программного продукта описывает технические действия проекта, например, анализ требований, проектирование, кодирование и тестирование.
Цель 1: Задачи проектирования определены, интегрированы и последовательно выполняются для производства ПО.
Действия RUP и определения того, что требуется от каждого работника относительно планируемых артефактов, необходимых для проекта, гарантируют, что задачи будут определены, распределены и выполнены. Итерационный процесс разработки, свойственный RUP, служит для того, чтобы быстро доказать эффективность группы разработки ПО и обеспечивает оценку конечного продукта.
Цель 2: Программные продукты сохраняются совместимыми друг с другом.
Трассируемость между техническими моделями (моделью прецедентов, проектной моделью, исходным кодом и выполнимыми компонентами) поддерживается средой.
Цель межгрупповой координации состоит в том, чтобы установить средства для группы разработки ПО, которые позволяют активно сотрудничать с другими техническими группами, чтобы проект мог наилучшим образом удовлетворить потребности заказчика эффективно и действенно. Межгрупповая координация - это межотраслевой аспект интегрального управления разработкой ПО, который простирается вне разработки программного обеспечения; мало того, что процесс должен быть интегральным, но и взаимодействия группы разработки программного обеспечения с другими группами должны быть скоординированы и управляемы.
Цель 1: Требования заказчика согласованы со всеми взаимодействующими группами.
Одно из преимуществ использования прецедентов как базы для сбора данных и описания требований по сравнению с другими "формальными" методами технического задания состоит в том, что прецеденты легко понимаются участвующими совладельцами. Кроме того, прецедентный метод сбора данных требований в RUP означает, что все совладельцы могут договариваться о том, что должно быть сделано. Это далее проходит через процесс и отражается в моделях и обзорах, которые используются как база для разработки программного обеспечения.
Цель 2: Обязательства между техническими группами согласованы с участвующими группами.
Эта цель должна быть разрешена организацией, которая внедряет RUP. Однако RUP предлагает модели, которые облегчают понимание того, что требуется в каждой стадии развития изделия, от сбора данных требований до развертывания. Управление изменениями и управление конфигурацией RUP гарантируют, что предложения об изменениях будут соответственно оценены и сообщены всем совладельцам.
Технические группы идентифицируют, отслеживают и разрешают межгрупповые проблемы. Итерационный процесс разработки RUP облегчает раннее обнаружение программных проблем из-за постоянной интеграции всего разработанного программного обеспечения. Проблемы интеграции с ПО, которое разработано рядом групп, могу служить "общим пространством" для поднятия и разрешения проблем с перекрестной группой. Эта идея поддерживается процессом обработки дефектов и запросов изменения RUP, который обеспечивает формальный механизм для фиксации, отслеживания и разрешения проблем разработки проекта.
Цель экспертной оценки состоит в том, чтобы удалить дефекты из продуктов работы возможно раньше и эффективнее. Важный эффект заключения экспертной оценки - это лучшее понимание продуктов работы и дефектов, которые могут быть предотвращены. Экспертная оценка программ - важный и эффективный технический метод, который применяется в проектировании программного продукта.
Цель 1: Действия обзора программ запланированы.
Как описано в целях KPA "Обеспечение качества" для 2-го уровня, каждое действие в пределах RUP имеет отдельное действие обзора.
Так как раннее обнаружение проблем снижает общую стоимость, сторонники RUP предлагают выполнять "раннюю и ясную" экспертную оценку всего, и особенно критических артефактов. RUP предлагает перечни контрольных точек, дающих возможность делать обзор в каждой стадии и в пределах каждой модели.
Цель 2: Дефекты в продуктах работы идентифицированы и удалены.
Рецензенты артефактов RUP должны определить, готов ли артефакт к следующей стадии разработки. Если артефакт не будет соответствовать критериям обзора, то в соответствии с программой измерений RUP, должны быть зафиксированы такие подробности, как:
В статье сделана попытка достаточно подробного описания того, какие возможности RUP можно использовать для реализации каждой из целей CMM и, соответственно, достижения 2-го и 3-го уровней зрелости. Я надеюсь, после прочтения у читателя исчезнут любые сомнения в том, что внедрение RUP - это прямой путь увеличения качества разрабатываемого ПО и получения сертификата качества вашего процесса.
За рамками этой статьи осталась проблема внедрения в организации процесса разработки ПО, базирующегося на RUP. Лучшим источником знаний по этой теме является, безусловно, сам Rational Unified Process. Русскоязычным читателям можно порекомендовать уже упоминавшийся цикл статей "Введение в Rational Unified Process" , в частности - выпуск 14 и несколько последующих, которые, я надеюсь, будут закончены и опубликованы на сайте Interface Ltd в ближайшем будущем.
В заключение, еще один совет. Внедрение системы управления качеством в организации на базе RUP - достаточно сложный процесс. Если Вы еще не освоили RUP в полной мере, не стесняйтесь - воспользуйтесь помощью наставников. Вы сэкономите много времени и денег для вашей организации.
Дополнительная информация:
Дополнительную информацию Вы можете получить в компании Interface Ltd.
Обсудить на форуме
Отправить ссылку на страницу по e-mail
|
Interface Ltd. Отправить E-Mail http://www.interface.ru |
|
| Ваши
замечания и предложения отправляйте
автору По техническим вопросам обращайтесь к вебмастеру Документ опубликован: 05.11.01 |