Учебное пособие санктПетербург 2015
 Скачать 3.34 Mb.
|
|
Уровень 5 – Победитель конкурса на получение Европейской премии по качеству (Winner European Quality Award). Высшему уровню соответствуют организации, ставшие победителями в своих категориях. В Европе видных ученых в области управления качеством не было. Значительно позже к 80 – годам прошлого столетия европейское сообщество стало пе- ренимать опыт американских и японских инженеров и ученых, а потом внедрять его у себя на предприятиях. 3.4 Российский опыт управления качеством Движение за улучшение качества продукции в Рос- сии существовало с периода проведения индустриализа- ции. С течением времени становилось ясно, что устойчи- вого совершенствования качества продукции нельзя до- 73 Модели управления качеством программного обеспечения биться путем проведения отдельных и даже крупных, но разрозненных мероприятий. Только путем системного и комплексного, взаимосвязанного осуществления техни- ческих, организационных, экономических и социальных мероприятий на научной основе можно быстро и устой- чиво совершенствовать качество продукции. Российский опыт основывался на инициативах отдельных предприятий сокращать количество брака и по возможности улучшать качество и зачастую сво- дился к сложному выбору - что делать с уже произве- денным браком. Понятия «управление качеством» даже не было в лексиконе наших промышленных предпри- ятий до середины 90-х годов ХХ века. И только с посте- пенной интеграцией России в мировое экономическое пространство, появлением международных стандартов ИСО передовые предприятия стали серьезно занимать- ся менеджментом качества. Ставить вопрос перед собой и персоналом, что делать, чтобы брака не было вообще и качество продукции не зависело от бригады, смены, начальника цеха, наладчика и было постоянным. Российские модели управления качеством на- чали развиваться в 60-е годы двадцатого века на про- мышленных предприятиях страны: • Саратовская область – концепция бездефектной работы БИП; • Горьковский авиационный завод – система КА- НАРСПИ (Качество, Надёжность, Ресурс С Первых Изделий); • Ярославский моторный завод «Автодизель» – система НОРМ; • предприятия Львовской области во взаимодейс- твии с ВНИИ стандартизации Госстандарта СССР и науч- но-производственным объединением «Система» – КСУКП (комплексная система управления качеством продукции). 74 Методы оценки и измерения характеристик информационных систем Важным критерием, характеризующим качест- во труда и определяющим размер материального по- ощрения, являлся коэффициент качества труда, кото- рый вычислялся для каждого работника предприятия, каждого коллектива за установленный промежуток времени (неделя, месяц, квартал) путем учета коли- чества и значимости допущенных производственных нарушений. В системе устанавливался классификатор основных видов производственных нарушений: каж- дому дефекту соответствует определенный коэффици- ент снижения. Максимальная оценка качества труда и максимальный размер премии устанавливаются тем работникам и коллективам, которые за отчетный пери- од не имели ни одного нарушения. Основными недостатками этих систем следует счи- тать отсутствие единого государственного подхода, ори- ентации на потребителя и спонтанность развития. Для освоения прогрессивного мирового опыта по управлению качеством необходимо реализовать комплекс обеспечи- вающих мероприятий, включающий разработку и реали- зацию системы мер и преимуществ, стимулирующих ра- боту. На это должна быть нацелена создаваемая в стране организационная структура, проводящая оценку и призна- ние систем качества, а также обучение специалистов, спо- собных выполнять все виды работ в области постоянного обеспечения, контроля и улучшения качества. 3.5 Модель CMM История «Модели Совершенствования Воз- можностей» (Capability Maturity Model, CMM) на- чалась в 1991 году в американском институте сис- темного программирования (Software Engineering Institute, SEI) при университете Карнеги-Меллона с выходом первой версии этого стандарта. Более рас- 75 Модели управления качеством программного обеспечения пространённым переводом этого стандарта является «модель зрелости процесса разработки программно- го обеспечения». Первоначальным предназначением стандарта CMM являлась разработка методики выбора наилучших поставщиков программного обеспечения для крупных правительственных организаций США. Для этого пла- нировалось сформулировать достаточное описание спо- собов оценки процессов разработки, а также методику их дальнейшего совершенствования. Результат оказался настолько подробным, что CMM стало возможным при- менять в рамках компаний-разработчиков, желающих усовершенствовать существующие процессы. Основным понятием стандарта CMM являет- ся зрелость организации. Организация считается незрелой, если процесс разработки программного обеспечения в ней зависит только от конкретных исполнителей, а решения принимаются спонтанно. В связи с этим велика вероятность дополнительных бюджетных издержек и срывов сроков проекта. В зрелой же организации существуют формализован- ные процедуры для создания и управления проекта- ми, которые по мере необходимости уточняются и совершенствуются. Более того, в подобных компа- ниях существуют стандарты на процессы разработ- ки, тестирования, внедрения, правила оформления конечного программного кода, компонентов, интер- фейсов и т.д. Всё перечисленное составляет инфра- структуру и корпоративную культуру, поддержива- ющую процесс разработки программного обеспе- чения. В целом, стандарт CMM содержит критерии оценки зрелости организации и методы совершенс- твования имеющихся процессов, что принципиально отличает его от ISO 9001, в котором лишь указаны 76 Методы оценки и измерения характеристик информационных систем необходимые условия для достижения минимально- го уровня организации процессов и нет никаких ре- комендаций по их дальнейшему улучшению. Модель CMM состоит из пяти уровней зре- лости (рисунок 30). Каждый последующий уровень подразумевает соответствие всем характеристикам предыдущего [45]. Начальный уровень (initial level) является осно- вой для сравнения со следующими уровнями. В орга- низации этого уровня не существует стабильных усло- вий для создания качественного программного обес- печения, а результат любого проекта целиком зависит от конкретных исполнителей. Стрессовые ситуации превращают процесс разработки в написание кода и его минимальное тестирование. Следующим уровнем является повторяемый (repeatable level). Для того чтобы организация соответс- твовала данному уровню в ней должен быть внедрён процесс управления проектами, основанный на накоп- ленном опыте, а также стандарты на разрабатываемое программное обеспечение. Критические ситуации мо- гут понизить уровень процессов до начального. Определённый уровень (Defined level) является третьим в иерархии модели CMM и характеризуется до- кументированным стандартным процессом разработки и сопровождения программного обеспечения. В процессе стандартизации происходит переход на самые эффек- тивные технологии и методики. Обязательным условием достижения данного уровня является наличие в органи- зации постоянно действующей программ по повышению квалификации и обучению сотрудников. Находясь на данном уровне, организация перестаёт зависеть от кон- кретных исполнителей и не имеет тенденции опускаться на уровень ниже в стрессовых ситуациях. 77 Модели управления качеством программного обеспечения Управляемый уровень (managed level) определя- ется введением количественных показателей качества на программные продукты и на процессы в целом, за счёт чего достигается более совершенное управление проектами. Последним уровнем модели CMM является оп- тимизированный (optimizing level). Он характеризует- ся применением мероприятий по улучшению не только к существующим процессам, но и к оценке ввода но- вых технологий. Главной задачей организации на этом уровне является постоянное улучшение существую- Рисунок 30 – Уровни зрелости организации в модели CMM 78 Методы оценки и измерения характеристик информационных систем щих процессов, при этом должны предусматривать- ся возможные ошибки и дефекты. Также необходимо предпринимать действия по уменьшению стоимости разработки программного обеспечения, например, че- рез формирование базы знаний с удачными решения- ми для их повторного использования. Сертификация организаций на соответствие мо- дели CMM производится по всем ключевым областям. Оценка осуществляется исходя из десяти бальной шка- лы. Для успешной сертификации конкретной области необходимо набрать шесть баллов. Ключевая область оценивается по следующим показателям: • заинтересованность руководства в данной об- ласти (планируется ли внедрение данной области, су- ществует ли в ней необходимость); • насколько широко данная область применяется в компании; • успешность использования данной области на практике. Необходимо заметить, что в мире существует очень мало компаний, в которых есть сертификация пятого уровня хотя бы одной области деятельности (около 50). По некоторым оценкам, более 70% ком- паний-разработчиков соответствуют первому уровню зрелости. Применение модели CMM затрудняется из-за следующих проблем: • стандарт CMM не является общедоступным; • стандарт ориентирован на применение в круп- ных компаниях; • оценка качества процессов в компании может проводиться только специалистами, аккредитованны- ми институтом SEI. 79 Модели управления качеством программного обеспечения 3.6 Модель SPICE Разработка стандарта SPICE (Software Process Improvement and Capability dEtermination – определе- ние возможностей и улучшение процесса создания про- граммного обеспечения) началась в 1991 году по иници- ативе Международной организации по стандартизации (ISO). Согласно реестру ISO/IEC, стандарт SPICE имеет номер 15504 и имеет название «Information Technology – Software Process Assessment». Определяющее место в стандарте занимает базовая модель, включающая пять категорий, состоящих из 35 процессов и 201 вида де- ятельности. Опыт и идеи многих стандартов были ис- пользованы для разработки SPICE (рисунок 31). [45] В связи с большим количеством рассмотренных стандартов и основательным подходом с повышенным уровнем детализации, документация SPICE содержит около 500 страниц. SPICE также как и CMM использует многоуров- невую модель, а также ставит основную задачу посто- янно совершенствовать процесс разработки програм- много обеспечения. В SPICE определены шесть уров- ней, описание которых приведено в таблице 3. Рисунок 31 – Предшественники стандарта SPICE 80 Методы оценки и измерения характеристик информационных систем Таблица 3 – Уровни модели SPICE Уровни Наименование Характеристика 0 Первоначаль- ный Процесс не определён или не производит ожидаемого выход- ного продукта. 1 Реализованный • процесс достигает своих це- лей; • измерения производитель- ности. 2 Управляемый • выходной продукт процесса соответствует требованиям; • управление производитель- ностью; • управление созданием про- дуктов. 3 Учреждённый (установлен- ный) • управляемый процесс реа- лизуется в соответствии с его определением и при удовлетво- рительном уровне затрат; • документирование процесса; • отслеживание ресурсов. 4 Предсказуемый • эффективность учрежденного процесса находится в опре- делённых пределах, установ- ленных в соответствии с целями организации; • измерение процесса; • управление процессом. 5 Оптимизируе- мый • предсказуемый процесс оп- тимизируется для достижения целей организации; • измерение процесса; • постоянное совершенствование. 81 Модели управления качеством программного обеспечения Модель SPICE подразумевает возможность со- вершенствования уровней отдельных процессов, а не всей организации в целом. Таким образом, в организа- ции могут существовать процессы, соответствующие различным уровням модели. Не существует офици- ального перевода стандарта, поэтому использованные термины официально не зарегистрированы. Основные элементы стандарта показаны на рисунке 32. Определение состояния процесса включает вы- полнение следующих этапов: 1. Оценка процесса. Осуществляется посредс- твом сравнения имеющегося процесса разработки программного обеспечения с изложенным в стандар- те. Результаты позволяют определить его сильные и слабые стороны. 2. Определение возможностей процесса. Предо- ставляет возможность оценить возможности по улуч- шению рассматриваемого процесса. Часто производит- ся компанией-поставщиком, чтобы доказать заказчикам способность достижения заданного уровня показателей. Рисунок 32 – Элементы стандарта SPICE [45] 82 Методы оценки и измерения характеристик информационных систем 3. Улучшение процесса. В случае возникновения необходимости в улучшении процесса производится техническая реализация поставленных задач, в соот- ветствии с чётко сформулированными целями. После этого весь цикл начинается заново. Стандарт SPICE является открытым и достаточ- но популярным. Для более подробного определения особеннос- тей SPICE в таблице 4 приведены сравнительные ха- рактеристики с ISO 9001. Таблица 4 – Сравнение SPICE и ISO 900 [45] ISO/IEC 15504 SPICE ISO 9001 Подробная модель Абстрактная модель Разработан для области про- граммного обеспечения Разработан для обобщен- ного производства, пре- имущественно серийного Определение способности и улучшения процессов Только сертификация Шесть уровней для оценки про- цессов Оценка по принципу «со- ответствие – несоответс- твие» Требования для аттестации, ру- ководство по применению Только модель Дополняет ISO 9000 Дополняется ISO 15504 SPICE Двумерная структура Последовательная одно- мерная Предполагает свободу при вы- боре стратегии улучшений Последовательность ша- гов включена в стандарт Уровни для каждого процесса Единый уровень зрелости для всей организации Результаты требуют обработки и упрощения Результаты просты для понимания Результаты очень подробны Чрезмерно упрощённые результаты 83 Модели управления качеством программного обеспечения 3.7 Модель МакКола Предложенная МакКолом в 1977 году модель качества программного обеспечения является первой в своей области и предназначена для оценки качества программного продукта с помощью его характеристик. Модель МакКола (рисунок 18) состоит из трёх основ- ных направлений определения качества программного обеспечения [49]: • использование (корректность, надежность, эф- фективность, целостность, практичность); • модификация (тестируемость, гибкость, сопро- вождаемость); • переносимость (мобильность, возможность многократного использования, функциональная сов- местимость). Объективно оценить или измерить факторы ка- чества довольно трудно, поэтому МакКол ввел мет- рики качества, которые с его точки зрения легче из- мерять и оценивать. Оценки в его шкале принимают значения от 0 до 10. Каждая метрика влияет на оценку нескольких факторов качества. Числовое выражение фактора представляет собой линейную комбинацию значений влияющих на него метрик. Коэффициенты этого выра- жения определяются по-разному для разных организа- ций, команд разработки, видов программного обеспе- чения, используемых процессов и т.п. 3.8 Модель Боэма Модель Боэма была представлена в 1978 году и схожа с моделью МакКола в связи с похожей иерар- хической моделью, состоящей из высокоуровневых, промежуточных и примитивных характеристик, каж- дая из которых вносит свой вклад в уровень качества 84 Методы оценки и измерения характеристик информационных систем программного обеспечения. Модель Боэма определяет качество программного обеспечения при помощи на- бора показателей и метрик. Основным отличием моде- ли Боэма можно считать представление характеристик программного обеспечения в более крупном масшта- бе, чем в модели МакКола (рисунок 33) [49]. Рисунок 33 – Модель качества МакКола 85 Модели управления качеством программного обеспечения Практичность в данной модели описывает, на- сколько легко, надежно и эффективно программный продукт может быть использован, сопровождаемость характеризует насколько легко можно изменить и повторно протестировать программный продукт, и мобильность описывает, как программный продукт может использоваться, даже при изменении програм- мных и аппаратных средств. 3.9 Модель FURPS/FURPS+ Акроним FURPS, используемый в обозначении модели, обозначает следующие категории требований к качеству ПО [49]: • Functionality (Функциональность) /особеннос- ти, возможности, безопасность/; • Usability (Практичность) /человеческий фактор, эргономичность, пользовательская документация/; • Reliability (Надежность) /частота отказов, вос- становление информации, прогнозируемость/; • Performance (Производительность) /время от- клика, пропускная способность, точность, доступ- ность, использование ресурсов/; • Supportability (Эксплуатационная пригодность) /тестируемость, расширяемость, адаптируемость, сопро- вождаемость, совместимость, конфигурируемость, обслу- живаемость, требования к установке, локализуемость/. • Символ «+» дополняет FURPS следующими ат- рибутами: ограничения проекта (ограничения по ресур- сам, требования к языкам и средствам разработки, тре- бования к аппаратному обеспечению); интерфейс (ограничения, накладываемые на взаимодействие с внешними системами); требования к выполнению; • • • 86 Методы оценки и измерения характеристик информационных систем физические требования; требования к лицензированию. Модель качества FURPS, предложенная Р. Грей- ди и Hewlett Packard, построена схожим образом с моделями МакКола и Боэма (Рис. 34), но в отличие от них состоит из двух слоев: первый определяет харак- теристики, а второй связанные с ними атрибуты. [49] Основной концепцией, лежащей в основе FURPS, яв- ляется декомпозиция характеристик программного обеспечения на две категории требований, а именно, функциональные (F) и нефункциональные (URPS) требования. Эти выделенные категории могут быть использованы как в качестве требований к програм- мному продукту, так и в оценке его качества. • • Рисунок 34 – Модель качества Боэма |