Материал: u_lectures

Основные принципы ISO9000:

Концентрация на потребностях заказчика;

Активная лидирующая роль руководства;

Вовлечение исполнителей в процессы совершенствования;

Реализация процессного подхода;

Системный подход к управлению;

Обеспечение непрерывных улучшений;

Принятие решений на основе фактов;

Взаимовыгодные отношения с поставщиками.

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

SEI-CMM, SEI-CMMI

Стандарт СММ (the Capability Maturity Model) разработан институтом инженерии программного обеспечения (SEI) при университете Карнеги-Меллон.

Назначение стандарта – оценка уровня «зрелости» (maturity levels) организации – разработчика программного обеспечения. Выделяются пять уровней: начальный, повторяемый, определённый, управляемый и оптимизирующий (подробнее см. в [22-8]). Данный стандарт получил широкую известность, значительное количество западных ITкомпаний сертифицировано по CMM.

В2000 г. SEI выпустил CMMI-SE/SW, интегрированную модель совершенствования как ПО, так и возможностей конструирования систем [8].

CMMI-SE/SW имеет две формы. Ступенчатое представление (the staged representation) соответствует структуре SW-CMM с небольшими уточнениями наименований уровней. Пять уровней зрелости содержат 22 области технологических процессов, показанных в таблице 14-1. (CMU/SEI, 2000а). Непрерывное представление (continuous representation), содержит другой взгляд: те же 22 области структурируются по 4 категориям: управление процессами, управление проектами, конструирование и поддержка (CMU/SEI, 2000b).

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

Как и в CMM, в рассматриваемом стандарте на уровне 2 имеется область, именуемая «Управление требованиями», но, в отличие от предыдущего стандарта, на уровне 3 есть и отдельная область «Разработка требований». Размещение этой области на уровне 3 не подразумевает, что требования для проектов организации, не достигших уровня 2, собирать и документировать не нужно. Управление требованиями рассматривается как способ, помогающий создавать более предсказуемые и менее хаотичные проекты, что составляет сущность уровня 2 СММ. Приняв порядок управления изменениями и проверки статуса требований, организация может больше внимания уделять разработке высококачественных требований [8].

Область процессов «Управление требованиями». Ключевые темы включают в себя то, как команда разработчиков должна приобретать понимание требований и разрешать вопросы с клиентами, вовлекать участников проекта в работу с требованиями и управлять изменениями. В отличие от SW-CMM, трассирование (одно из ключевых свойств требований) включено в рассматриваемую область процессов. В стандарте обсуждаются следующие качества трассирования:

обеспечение записи источников низкоуровневых или вторичных требований;

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

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

Область процессов «Разработка требований».

В CMMI-SE/SW описаны три набора приемов разработки требований:

приемы, определяющие полный набор требований клиентов, которые затем используются для разработки требований для продукта (выявить нужды

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

приемы, определяющие полный набор требований для продукта (установить компоненты продукта; разместить требования по компонентам продукта; определить требования к интерфейсу);

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

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

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

CMMI-SE/SW регламентирует взаимосвязи между управлением требованиями, разработкой требований и другими областями процессов (рис. 14-1).

Рис. 14-1

Принципы совершенствования

В [8] сформулированы следующие принципы совершенствования качества программных систем:

поэтапность,

непрерывность,

цикличность,

наличие стимула,

ориентация на цели,

проектный подход.

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

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

Бизнес-процесс улучшения требований характеризуется цикличностью (см. Процесс совершенствования): его основные этапы повторяются на всё более высоком уровне. Циклы оптимизации в софтверных организациях удобно приурочивать к проектам, выполняемых в рабочих группах. Анализ недостатков целесообразно производить тогда, когда они в «оперативной памяти» группы проекта, например – один раз в середине проекта и один – сразу после его окончания. Каждый проект по-своему уникален и несёт в себе потенциал для улучшения процессов.

Основным стимулом к изменениям К.Вигерс считает трудности, с которыми столкнулась команда проекта, например:

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

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

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

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

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

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

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