Разработка, внедрение и адаптация программного обеспечения отраслевой направленности Часть 2. Разработка, внедрение и адаптация программного обеспечения отрас. Тема введение в обеспечение качества программных средств
 Скачать 418.37 Kb.
|
14.5. Элементы профиля процессаТермин "профиль" стал широко использоваться в программной инженерии с появлением концепции открытых систем и в связи с необходимостью определения стандартов мобильности программ и данных (например, OSE, Open system environment profile ). Этот термин использовал также Дж.Д. Муса в концепции инженерии надежности применительно к описанию альтернативных вариантов процесса применения программных средств (functional profile, operational profile). В.В. Липаев определяет профиль как "совокупность нескольких (или подмножество одного) базовых стандартов и/или других нормативных документов с четко определенными и гармонизированными подмножествами обязательных и факультативных возможностей, предназначенную для реализации заданной функции или группы функций. Функциональная характеристика (заданный набор функций, в частности, система качества) объекта стандартизации является исходной для формирования и применения профиля этого объекта или процесса. В профиле выделяются и устанавливаются допустимые факультативные возможности и значения параметров каждого стандарта и/или нормативного документа, входящего в профиль, выбранные из альтернативных вариантов. На базе одной и той же совокупности стандартов могут формироваться и утверждаться различные профили для разных проектов программны и сфер применения". В.В. Липаев выделяет две категории профилей в жизненном цикле программных средств - профили, регламентирующие архитектуру и структуру программных средств и их компонентов - функций, интерфейсов, протоколов взаимодействия, форматов данных и др. и профили, регламентирующие процессы жизненного цикла. Применительно к процессам обеспечения качества программных средств предлагается конкретизировать понятие профилей второй категории - профилей процессов. Любой процесс жизненного цикла можно обобщенно рассматривать как агрегацию составляющих его элементов - действий, объектов, субъектов и ограничений, а под профилем процесса понимать совокупности стандартов, базовых требований, практических приемов и процедур, учетно-отчетных форм и др. для отдельных элементов в агрегации. Схематически профиль любого процесса жизненного цикла программного средства представлен на рисунке 13.4. Рис. 13.4. Элементы профиля процесса жизненного цикла программного средства Требования к профессиональной зрелости исполнителей процесса характеризуют необходимый уровень компетентности специалистов, участвующих в его выполнении. Стандарты рабочих продуктов процесса определяют требования к структуре и содержанию входных и выходных документов процесса, которые обычно представляют собой набор форм, разработанных и утвержденных для применения при выполнении процесса. Метрики процесса включают множество методов и шкал для измерения стоимости, трудоемкости и продолжительности процесса, а также размера и сложности объектов деятельности процесса. Профиль стандартов процесса составляют международные и другие стандарты, касающиеся планов процесса, а также методов и средств выполнения как процесса в целом, так и отдельных действий в процессе. Если к разрабатываемого программного средства предъявляются повышенные требования относительно безопасности функционирования , защиты информации , целостности системы (как, например, в критических системах управления ядерными реакторами) - это может накладывать отпечаток на спектр используемых методов, ресурсов и стандартов при выполнении процессов. Такого рода ограничения обычно регулируются ведомственными стандартами (или стандартами предприятия), сужающими поле деятельности общепринятых стандартов. Методы и средства выполнения процесса включают методическую и инструментально-технологическую поддержку выполнения процесса. Для процессов контроля качества этот элемент профиля включает методы проведения обзоров, инспекций, сквозного просмотра, сбора и обработки данных и др., а также набор стандартных инструментов статистического контроля процессов (гистограмм, диаграмм и др.), применяемых группой качества. Далее перечисленные элементы профиля процесса контроля качества рассматриваются подробнее. 14.6. Требования к подготовке компетентных специалистов В модели процессов жизненный цикл программных средств существует специальный организационный процесс "управление трудовыми ресурсами (кадрами)" , цель которого состоит в подборе (подготовке) компетентных специалистов для выполнения работ по проектам программных средств. Компетентность специалистов образуется сочетанием знаний, мастерства (умения) и личных качеств (способствующих эффективному выполнению процессов), а они, в свою очередь, достигаются с помощью образования, специальной подготовки и личного опыта, которые должны подтверждаться перед назначением специалиста на ту или иную роль в области качества (рисунок 13.5). Рис. 13.5. Составляющие компетентности для выполнения процесса Совершенствование любого процесса жизненного цикла программного средства основано, прежде всего, на улучшении работы каждого специалиста, исполняющего определенную роль в процессе. В 1995 году У.С. Хамфри (SEI) предложил концепцию "персонального (личного) процесса участника разработки программного обеспечения" (PSP, "Personal Software Process"). PSP - это схема и совокупность методов индивидуальной профессиональной деятельности исполнителей процессов ЖЦ, основанной на принципах планирования, учета, самоконтроля и личной ответственности за качество принимаемых решений и выполняемых действий. В основе PSP лежат принципы У.Е. Деминга и Дж.М. Джурана PSP помогает формулировать измеримые цели собственного процесса, фиксировать потраченное время, анализировать допускаемые и устраняемые ошибки, контролировать объем выполненной работы и повышать производительность труда. По словам У. Хамфри “рекомендуемая цель процесса состоит в создании бездефектных продуктов в рамках графика и запланированных затрат”. Повышение качества разрабатываемого продукта достигается по трем ключевым аспектам: трассируя все допущенные дефекты, исполнитель определяет причины собственных ошибок и старается работать внимательнее; анализируя данные о дефектах, исполнитель начинает осознавать стоимость их устранения и необходимость определения наиболее эффективных способов обнаружения и локализации дефектов; исполнитель использует эффективные практические приемы PSP для предупреждения появления ошибок в дальнейшем. Процесс PSP определяется на семи уровнях. Каждый уровень процесса надстраивается над предыдущими, основываясь на приобретенных исполнителями навыках и накопленных исторических данных. На каждом уровне (начиная с PSP 0) добавляются новые элементы процесса и усложняются приемы работы: PSP 0. Исполнители используют привычные для них приемы работы и изучают основы PSP. Охватываемый материал - приемы учета времени разработки и регистрации каждого дефекта. Данные измерений используются для анализа процесса и планирования, а также в качестве эталонов при оценивании улучшений процесса; PSP 0.1. На этом уровне применения процесса добавляются приемы измерения объема работы (размера продукта) и формирования предложений по усовершенствованию процесса. Используется форма для регистрации обнаруженных проблем и предложений по их решению, которая помогает не упустить множество мелких деталей; PSP1. Исполнители знакомятся с методом PROBE (PROxy Based Estimating, оценивание по объектам-представителям). Это специально разработанный для PSP метод, основанный на применении регрессионного анализа для оценки размера продукта по историческим данным и определения точности оценки; PSP 1.1. На этом уровне применения PSP добавляются приемы оценивания ресурсов и построения графика (расписания) работы, а также отслеживания затрат труда и сроков завершения каждой задачи. Это позволяет соотносить важность задач с трудоемкостью их решения и переупорядочивать задачи. PSP 2. На этом уровне вводятся приемы обзора проекта и кода, а также оценивания качества. По данным о ранее допущенных дефектах разрабатываются персональные опросные листы (вопросники) для обзора проекта и кода. PSP 3. На этом уровне процесса исполнители осваивают приемы верифи¬кации проекта и методы адаптации PSP к условиям реальной среды разработки крупных проектов программных средств. На каждом уровне PSP используется множество однотипных журналов, форм, описаний (скриптов) и стандартов. Описания определяют шаги процесса на каждом уровне, журналы и формы предоставляют шаблоны для учета и хранения данных, а стандарты обеспечивают нормативную поддержку работы исполнителей. Для успешного применения PSP нужна специальная подготовка (обычно 120-150 часов интенсивной практической работы) и желательно последующее закрепление навыков в определенной производственной среде, что предотвратит "скатывание" к работе "по старинке". Чтобы помочь каждому исполнителю, коллективу исполнителей (команде) и менеджерам проектов успешно применять методы PSP, У. Хамфри в 1996 году предложил концепцию "коллективного процесса разработки ПО" (TSP, Team Software Process) . Во время 4-дневного периода настройки все члены команды определяют стратегию работы по проекту на ближайшие 3-4 месяца, выстраивают процесс и составляют коллективный и индивидуальные планы работ, которыми руководствуются в следующем цикле разработки. Форма работы команды в период настройки - совещания (9 совещаний за 4 дня), которые готовятся командиром и проводятся по определенной схеме (рисунок 13.8). Рис. 13.8. Схема процесса настройки На заключительном этапе настройки команда анализирует результаты этого процесса и готовит предложения по его улучшению. Соблюдение намеченного плана поддерживается и контролируется. Практика применения процессов PSP и TSP в зарубежных фирмах-разработчиках программных средств (в частности, Advanced Information Services, Boeing, Motorola Inc. и др.) свидетельствует о существенном повышении компетентности специалистов, производительности их труда, эффективности процессов жизненного цикла, применяемых в проектах разработки программных средств, и качества конечных программных продуктов. Обобщив передовой опыт в области организационного строительства, управления трудовыми ресурсами и знаниями, в 90-е годы SEI предложил также модель People CMM (People Capability Maturity Model, модель зрелости процесса управления кадрами) . Модель People CMM помогает организациям оценить зрелость кадровой политики, создать программу непрерывного совершенствования процесса подготовки и управления кадрами, а также повышения корпоративной культуры. Модель описывает 5 уровней зрелости (стадий эволюции), на каждом из которых институциализируются практические приемы, открывающие новые возможности по организации труда коллектива. В состав модели входят следующие пять уровней: Инициация процесса - включает все подготовительные этапы Управление - включает тренировку и обучение персонала Определение целей - включает исследование и планирование Прогнозирование - включает определение возможных вариантов развития событий Оптимизация - включает методы оптимизации и правильно организации процесса Структура People CMM представлена в форме матрицы , элементы которой - ключевые направления деятельности по управлению трудовыми ресурсами - взаимосвязаны и отнесены к четырем аспектам управления: развитие индивидуальных способностей; формирование рабочих групп и корпоративной культуры; стимулирование и управление производительностью; управление кадрами. Рис. 13.9 Взаимосвязь ключевых направлений процесса в People CMM В основе модели лежит парадигма о зрелости компании, которая определяет ее общий уровень. Чем выше уровень зрелости организации, тем больше возможностей для привлечения, удерживания, профессионального роста и эффективного использования специалистов. Наряду с моделью SW-CMM, People CMM широко применяется в зарубежных фирмах. В Северной Америке, Европе и Австралии эту модель используют Lockheed Martin, Boeing, BAE Systems, Ericsson, IBM Global Services, Novo Nordisk IT A/S (NNIT), Citibank, U.S. Army, Advanced Information Services Inc. (AIS) и др. Более 40% организаций, достигших 4 и 5 уровня зрелости по модели СММ, используют People CMM для дальнейшего совершенствования процессов разработки программных продуктов. По результатам применения People CMM в Индии в 2001 году модель названа "оружием борьбы с утечкой мозгов". |