Стандарты качества программного обеспечения доклад
Обновлено: 30.06.2024
Часть 1: Модель качества.
Часть 2: Внешние метрики качества.
Часть 3: Внутренние метрики качества.
Часть 4: Метрики качества в использовании.
Часть первая стандарта ISO 9126-1 - (пересмотренная и расширенная редакция ISO 9126:1991), сохранила практически ту же номенклатуру нормативных характеристик качества программных средств. В ней приводится схема взаимосвязи частей стандарта ISO 9126 и частей стандарта ISO 14598, а также область применения, нормативные ссылки, термины и определения. Модель характеристик качества ПС состоит из шести групп базовых показателей, каждая из которых детализирована несколькими нормативными субхарактеристиками:
Функциональная пригодность детализируется:
- пригодностью для применения;
- корректностью (правильностью, точностью);
- способностью к взаимодействию;
Надежность характеризуется:
- уровнем завершенности (отсутствия ошибок);
- устойчивостью к дефектам;
Эффективность рекомендуется отражать:
Применимость (практичность) предлагается описывать:
Сопровождаемость представляется:
- удобством для анализа;
Переносимость (мобильность) предлагается отражать:
- простотой установки - инсталляции;
Дополнительно каждая характеристика сопровождается субхарактеристикой согласованность, которая должна отражать отсутствие противоречий с иными стандартами и нормативными документами, а также с другими показателями в данном стандарте. Характеристики и субхарактеристики в этой части стандарта определены очень кратко (2-3 строки), без комментариев и подробных рекомендаций по их применению к конкретным системам и проектам. Материалы имеют концептуальный характер и не содержат рекомендаций по выбору и упорядочению приоритетов необходимого минимума критериев в зависимости от особенностей объекта среды разработки и применения. Кроме того, отсутствуют методики измерения характеристик и сопоставления с требованиями спецификаций, а также рекомендации, на каких этапах ЖЦ ПС их целесообразно применять.
Описания показателей качества ориентированы на высококвалифицированных системных аналитиков и заказчиков ПС, которым предоставляет возможность выбирать необходимую номенклатуру и способ оценивая характеристик в соответствии с назначением, областью применения и конкретными особенностями создаваемых объектов.
Основные факторы, определяющие качество сложных программных средств
Общее представление о качестве ПС международным стандартом ISO 9126 рекомендуется отражать тремя взаимодействующими и взаимозависимыми метриками характеристик качества, отражающими:
·внутреннее качество, проявляющееся в процессе разработки и других промежуточных этапов жизненного цикла ПС;
·внешнее качество, заданное требованиями заказчика в спецификациях и отражающееся характеристиками конечного продукта;
·качество при использовании в процессе нормальной эксплуатации и результативностью достижения потребностей пользователей с учетом затрат ресурсов.
Эти типы метрик применимы при определении целей проекта и требований к качеству ПС, включая промежуточные компоненты и продукты. Подходящие внутренние атрибуты качества ПС являются предпосылкой достижения в жизненном цикле требуемого внешнего поведения, а приемлемое внешнее поведение - предпосылка достижения качества в использовании.
Внутренние метрики в соответствии со стандартами могут применяться в ходе проектирования и программирования к неисполняемым компонентам ПС таким, как спецификация или исходный программный текст. При разработке ПС промежуточные компоненты следует оценивать с использованием внутренних метрик, которые отражают некоторые функциональные и конструктивные свойства программ. Основная цель применения внутренних метрик – обеспечение требуемого внешнего качества. Рекомендуется использовать внутренние метрики, которые имеют наиболее сильные связи с приоритетными внешними метриками, чтобы они могли помогать при прогнозировании их достижимых значений.
Внутренние метрики дают возможность разработчикам, испытателям и заказчикам, начиная с системного проектирования, прогнозировать качество жизненного цикла программ и заниматься вопросами технологического обеспечения качества до того, как ПС становится готовым к использованию продуктом. Измерения внутренних метрик используют свойства, категории, числа или характеристики элементов из состава ПС, которые, например, имеются в процедурах исходного программного текста, в графе потока управления, в потоке данных и в описаниях изменения состояний памяти. Качество документации также может оцениваться с использованием внутренних метрик.
Внешние метрики используют меры ПС, выведенные из поведения системы, частью которых они являются, путем испытаний, эксплуатации и
наблюдения исполняемых программ или функционирования информационной системы. Перед приобретением или использованием ПС его следует оценить с использованием метрик, основанных на реализации деловых и профессиональных целей, связанных с применением программного продукта в определенной организационной и технической среде. Внешние метрики обеспечивают заказчикам, пользователям и разработчикам возможность прослеживать и анализировать качество ПС в ходе испытаний или опытной эксплуатации. Подходящие внешние метрики специфицируются для получения числовых значений или категорий и свойств внутренних характеристик качества, чтобы их можно было использовать для проверки того, что промежуточные продукты в процессе разработки удовлетворяют внутренним спецификациям качества.
Метрики качества в использовании отражают, в какой степени продукт удовлетворяет потребности конкретных пользователей в достижения заданных целей. Эта метрика не отражена в числе шести базовых характеристик ПС, регламентируемых стандартом ISO 9126-1 вследствие ее общности, однако рекомендуется для интегральной оценки результатов функционирования и применения комплексов программ в стандарте ISO 9126-4. Качество в использовании - это объединенный эффект функциональных и конструктивных характеристик качества ПС для пользователей. Связь качества в использовании с другими характеристиками ПС зависит от задач и функций их потребителей:
· для заказчика требуется полное соответствие характеристик программного продукта условиям контракта, технического задания и спецификаций требований;
· для конечного оперативного пользователя ПС по основному назначению, качество в использовании обусловливают, в основном, характеристики функциональных возможностей, надежности, практичности и эффективности;
· для персонала сопровождения ПС качество в использовании определяется преимущественно сопровождаемостью;
· для персонала, выполняющего перенос ПС на иные платформы, а также инсталляцию и адаптацию к среде применения, качество в использовании определяется, прежде всего, мобильностью.
Практически невозможно измерить все внутренние или внешние субхарактеристики и их атрибуты для всех компонентов крупномасштабных ПС.
Аналогично, обычно не практикуется формализовать требования и оценивать качество в использовании для всех возможных сценариев задач пользователей. Поэтому их необходимо ранжировать и выделять приоритетные процессы и объекты для оценивания характеристик с различной достоверностью.
Для выбора характеристик качества ПС и достоверного сравнения их с требованиями, а также для сопоставления их значений между различными программными продуктами необходимы оценки, измерения и использование определенных мер и шкал. Стандартами рекомендуется, чтобы было предусмотрено измерение каждой характеристики качества ПС (субхарактеристики или ее атрибута) с точностью и определенностью, достаточной для сравнений с требованиями технических заданий и спецификаций, и чтобы измерения были объективны и воспроизводимы. Следует предусматривать нормы допустимых ошибок измерения, вызванных инструментами и/или ошибками человека-эксперта. Чтобы измерения были объективными, должна быть документирована и согласована процедура для присвоения числового значения, свойства или категории каждому атрибуту программного продукта. Процедуры измерений должны давать в результате одинаковые меры с приемлемой устойчивостью, получаемые различными субъектами при выполнении одних и тех же измерений характеристик ПС в различных случаях.
Характеристики, субхарактеристики и атрибуты качества ПС с позиции возможности и точности их измерения можно разделить на три уровня детализации показателей, особенности которых следует уточнять при их выборе:
· категорийные-описательные, отражающие набор свойств и общие характеристики объекта - его функции, категории ответственности, защищенности и важности, которые могут быть представлены номинальной шкалой категорий-свойств;
· количественные, представляемые множеством упорядоченных числовых точек, отражающих непрерывные или дискретные закономерности и описываемые интервальной или относительной шкалой, которые можно объективно измерить и численно сопоставить с требованиями;
· качественные - содержащие несколько упорядоченных или отдельных свойств - категорий, которые характеризуются порядковой или точечной шкалой набора категорий (есть - нет, хорошо - плохо), устанавливаются, выбираются и оцениваются в значительной степени субъективно и экспертно.
К первому уровню относятся показатели качества, которые характеризуются наибольшим разнообразием значений - свойств программ и наборов данных и охватывают весь спектр классов, назначений и функций современных ПС. Эти свойства можно сравнивать только в пределах однотипных ПС и трудно упорядочивать по принципу предпочтительности. Среди стандартизированных показателей качества к этой группе, прежде всего, относится Функциональная пригодность, являющаяся самой важной и доминирующей характеристикой любых ПС. Номенклатура и значения всех остальных показателей качества непосредственно определяются требуемыми функциями программного средства и, в той или иной степени, влияют на выполнение этих функций. Поэтому выбор функциональной пригодности ПС, подробное и корректное описание ее свойств являются основными исходными данными для установления при системном проектировании требуемых значений всех остальных стандартизированных показателей качества.
Ко второму уровню показателей качества относятся достаточно достоверно и объективно измеряемые численные характеристики ПС. Значения этих характеристик обычно в наибольшей степени влияют на функциональную пригодность и метрики в использовании ПС. Поэтому выбор и обоснование их требуемых значений должно проводиться наиболее аккуратно и достоверно уже при проектировании ПС. Их субхарактеристики могут быть описаны упорядоченными шкалами объективно измеряемых значений, требуемые численные величины которых могут быть установлены и выбраны заказчиками или пользователями ПС. Такими характеристиками являются надежность и эффективность комплексов программ. Надежность может отражаться временем наработки на отказ, средним временем восстановления, а также коэффициентом готовности – вероятностью застать ПС в работоспособном состоянии при нормальной эксплуатации. Эти величины могут выбираться и фиксироваться в техническом задании или спецификации требований, и сопровождаться методикой объективных, численных измерений при квалификационных испытаниях для сопоставления с требованиями.
Атрибуты временной эффективности тесно связаны между собой и также значительно влияют на функциональную пригодность ПС. Длительность решения основных задач, пропускная способность по числу их решений за некоторый интервал времени, длительность ожидания результатов (отклика), и некоторые другие характеристики динамики функционирования ПС, могут быть выбраны и установлены количественно в спецификациях требований заказчиком. Эта субхарактеристика не всегда может быть выбрана и достаточно точно зафиксирована в требованиях на начальных этапах разработки, но она может количественно измеряться и последовательно уточняться в жизненном цикле ПС.
Третий уровень стандартизированных показателей качества ПС трудно полностью описать измеряемыми количественными значениями и их некоторые субхарактеристики и атрибуты имеют описательный, качественный вид. В зависимости от функционального назначения ПС по согласованию с заказчиком можно определять экспертно степень необходимости (приоритет) этих свойств и бальные значения уровня реализации их атрибутов в жизненном цикле конкретного ПС. Например, не всегда может требоваться мобильность программ на иные операционные и аппаратные платформы. В других случаях мобильность можно оценивать категориями: отличная, хорошая, удовлетворительная или неудовлетворительная. Такие оценки могут проводиться экспертно на основе анализа возможной трудоемкости и длительности, реализации процессов переноса комплекса программ на новую платформу.
Практичность тесно связана с функциональной пригодностью. Обобщенно этот показатель можно отразить трудоемкостью и длительностью, которые необходимы для изучения и полного освоения функций и технологии применения соответствующего ПС. Каждая из субхарактеристик практичности имеет ряд качественных атрибутов, которые могут выбираться и оцениваться экспертно с учетом функционального назначения ПС, а также надежности и ресурсной эффективности комплекса программ. Некоторые из этих атрибутов можно квалифицировать количественно.
Сопровождаемость может иметь ограниченный характер полной замены программ на вновь разработанные версии и тем самым сливаться с процессами разработки или осуществляться как непрерывная поддержка множества пользователей консультациями, адаптациями и корректировками программ. В зависимости от этого различаются функции и трудоемкость процессов сопровождения, которая может использоваться как обобщенная качественная характеристика при выборе требований к этому показателю качества. Соответственно при проектировании качественно могут быть установлены субхарактеристики сопровождаемости и описаны требуемые их свойства.
При любом виде деятельности людям свойственно непредумышленно ошибаться, результаты чего проявляются в процессе создания или приме-
нения изделий или систем. В общем случае под ошибкой подразумевается дефект, погрешность или неумышленное искажение объекта или процесса. При этом предполагается, что известно его правильное, эталонное состояние, по отношению, к которому может быть определено наличие отклонения - дефекта или ошибки. Для систематической, координированной борьбы с ними необходимы исследования факторов, влияющих на качество ПС со стороны различных, существующих и потенциально возможных дефектов в конкретных программах. Это позволит целенаправленно разрабатывать комплексы методов и средств обеспечения качества сложных ПС различного назначения при реально достижимом снижении уровня дефектов проектирования и разработки.
Различия между ожидаемыми и полученными результатами функционирования программ могут быть следствием ошибок не только в созданных программах и данных, но и системных ошибок в первичных требованиях спецификаций, явившихся исходной базой при создании ПС. Тем самым проявляется объективная реальность, заключающаяся в невозможности абсолютной корректности исходных спецификаций сложных ПС после проектирования. На практике в процессе разработки ПС исходные требования уточняются и детализируются по согласованию между заказчиком и разработчиком. Базой таких уточнений являются неформализованные представления и знания специалистов, а также результаты промежуточных этапов жизненного цикла. Однако установить ошибочность исходных данных и спецификаций еще труднее, чем обнаружить ошибки в созданных программах, так как принципиально отсутствуют формализованные данные, которые можно использовать как эталонные, и их заменяют неформализованные представления заказчиков и разработчиков.
Дефекты функционирования программных средств, не имеющие злоумышленных источников или последствий физических разрушений аппаратных компонентов, проявляются внешне как случайные, имеют разную природу и последствия. В частности, они могут приводить к нарушениям функциональной работоспособности, и к отказам при использовании ПС. В жизненном цикле, на ПС воздействуют различные негативные, дестабилизирующие факторы, которые можно разделить на внутренние, присущие самим объектам уязвимости, и внешние, обусловленные средой, в которой эти объекты функционируют.
Введение строгих количественных метрик в программирование должно было способствовать решению ряда практических задач:
· предсказывать вероятное число ошибок в системе с самого начала проектирования; - на основе анализа фазы проектирования системы предсказывать уровень сложности последующего сопровождения;
· на основе анализа исходного кода программ прогнозировать уровень сложности процессов тестирования и процент остающихся ошибок; - по оценкам сложности фазы проектирования системы определять конечный размер кода;
· определять корреляцию отдельных характеристик программного кода с качеством готовой системы;
· контролировать стадии развития проекта;
· анализировать явные и скрытые дефекты;
· на основе экспериментального сравнения выявлять лучшие методы и технологии.
По мере роста актуальности программных метрик на рынке стали появляться различные "измерительные" программы. Одни из них исследовали характеристики проектов и ПО комплексно, другие ориентировались на вполне конкретные цели: анализ исходного кода, размеров и структуры отдельных модулей.
Вы можете изучить и скачать доклад-презентацию на тему Стандартизация программного обеспечения. Презентация на заданную тему содержит 17 слайдов. Для просмотра воспользуйтесь проигрывателем, если материал оказался полезным для Вас - поделитесь им с друзьями с помощью социальных кнопок и добавьте наш сайт презентаций в закладки!
Стандартизация программных продуктов Сложность, многогранность и универсальность программных продуктов, массовость их применения потребовали стандартизации как самих программ – программных средств(ПС), так и процессов их разработки.
Стандартизация помогает унифицировать и автоматизировать: анализ задачи, разбиение ее на подзадачи; анализ структур данных; выделение модулей; определение интерфейса; вычерчивание блок-схем алгоритмов; непосредственно программирование; отладку и тестирование; анализ качества и количества затраченного труда на разработку программного изделия.
Стандарты имеют большое значение – они обеспечивают возможность разработчикам программного обеспечения использовать данные и программы других разработчиков, осуществлять экспорт/импорт данных. Такие стандарты регламентируют взаимодействие между различными программами. Для этого предназначены стандарты межпрограммного интерфейса, например OLE (Object Linking and Embedding – связывание и встраивание объектов). Без таких стандартов программные продукты были бы “закрытыми” друг для друга Стандарты имеют большое значение – они обеспечивают возможность разработчикам программного обеспечения использовать данные и программы других разработчиков, осуществлять экспорт/импорт данных. Такие стандарты регламентируют взаимодействие между различными программами. Для этого предназначены стандарты межпрограммного интерфейса, например OLE (Object Linking and Embedding – связывание и встраивание объектов). Без таких стандартов программные продукты были бы “закрытыми” друг для друга
5. Стандарты, определяющие термины по программному обеспечению (ГОСТ Р ИСО/МЭК 2382-23-2004, ГОСТ 28806-90, ГОСТ 20886-85, ГОСТ 24402-88, ГОСТ 15971-90, ГОСТ 19781-90). 5. Стандарты, определяющие термины по программному обеспечению (ГОСТ Р ИСО/МЭК 2382-23-2004, ГОСТ 28806-90, ГОСТ 20886-85, ГОСТ 24402-88, ГОСТ 15971-90, ГОСТ 19781-90). 6. Стандарты на процессы жизненного цикла программного обеспечения (ГОСТ Р ИСО/МЭК 12207-99, ГОСТ Р 51904-2002, ГОСТ Р 51189-98, ГОСТ Р ИСО/МЭК 15504-2009, а также отнесем сюда КТ-178В). 7. Обучающие стандарты (ГОСТ Р ИСО/МЭК ТО 12182-2002, ГОСТ Р ИСО/МЭК 15026-2002).
Различают два вида таких стандартов: Различают два вида таких стандартов: стандарты ПС (программного средства), стандарты процесса создания и использования ПС. Стандарты ПС определяют некоторые свойства, которыми должны обладать программы или документы ПС, т.е. определяют в какой-то степени качество ПС. К стандартам ПС относятся, прежде всего, стандарты на языки программирования, на состав документации, на структуру различных документов, на различные форматы и другие. Стандарты процесса создания и использования ПС определяют, как должен проводится этот процесс, т.е. подход к разработке ПС, структуру жизненного цикла ПС и его технологические процессы. Хотя эти стандарты непосредственно не определяют качества ПС, однако считается, что качество ПС существенно зависит от качества процесса его разработки. Эти стандарты проще контролировать, поэтому повсеместно используются для управления качеством ПС
Эффективность Эффективность Эффективность (Efficiency): способность ПО обеспечивать требуемую производительность относительно количества используемых ресурсов в установленных условиях. Временная эффективность (Time behaviour): способность ПО обеспечивать приемлемые времена отклика и обработки, а также пропускную способность при выполнении его функций в установленных условиях. Использование ресурсов (Resource utilization): способность ПО использовать приемлемые ресурсы в течение приемлемого времени при выполнении его функций в установленных условиях. Согласованность (Compliance): способность ПО придерживаться стандартов или соглашений, связанных с эффективностью.
Практичность Практичность Практичность (Usability): способность ПО, обусловливающая легкость его понимания, изучения и использования, а также привлекательность для пользователя при использовании в указанных условиях. Понятность (Understandability): способность ПП, обеспечивающая пользователю понимание, является ли ПО пригодным, и как его можно использовать для конкретных задач и условий использования. Изучаемость (Learnability): способность ПП, обеспечивающая изучение пользователем его применения. Легкость использования (Operability): способность ПП, обеспечивающая пользователю возможность его эксплуатировать и управлять им. Привлекательность (Attractiveness): способность ПП нравиться пользователю. Согласованность (Compliance): способность ПО придерживаться стандартов, соглашений, руководств по стилю или норм, связанных с практичностью.
Надежность Надежность Надежность (Reliability): способность ПО сохранять свой уровень качества функционирования при использовании в указанных условиях. Завершенность (Maturity): способность ПО предотвращать отказ как следствие ошибок в ПО. Устойчивость к ошибке (Fault tolerance): способность ПО поддерживать заданный уровень качества функционирования в случаях ошибок в ПО или нарушения установленного интерфейса. Восстанавливаемость (Recoverability): способность ПО в случае отказа восстанавливать уровень качества функционирования и поврежденные данные. Согласованность (Compliance): способность ПО придерживаться стандартов, соглашений или норм из законов и подобных предписаний, связанных с надежностью.
Функциональные возможности Функциональные возможности Функциональные возможности (Functionality): способность ПО обеспечивать функции, удовлетворяющие установленные и подразумеваемые потребности при использовании ПО в заданных условиях. Пригодность: способность ПО обеспечивать соответствующий набор функций для указанных задач и целей пользователя. Правильность : способность ПО обеспечивать правильные или приемлемые результаты или эффекты. Способность к взаимодействию. : способность ПО взаимодействовать с одной или большим числом указанных систем. Защищенность : способность ПО защищать информацию и данные так, чтобы не уполномоченные субъекты или системы не могли читать или изменять их, а уполномоченные субъекты или системы не получали отказа на доступ к ним. [ISO 12207: 1995] Согласованность : способность ПО придерживаться стандартов, соглашений или норм из законов и подобных предписаний, связанных с областью применения.
Сопровождаемость Сопровождаемость Сопровождаемость (Maintainability): способность ПО к модификации. Изменения могут включать исправления, усовершенствования или адаптацию ПО к изменениям в среде, а также в требованиях и функциональных спецификациях. Анализируемость (Analyzability): способность ПП к диагностике его недостатков или причин отказов в ПО, а также к идентификации его частей для модификации. Изменяемость (Changeability): способность ПП к обеспечению реализации специфицированных изменений. Стабильность (Stability): способность ПО минимизировать непредвиденные эффекты от его изменений. Тестируемость (Testability): способность ПП, обеспечивающая проверку и приемку модифицированного ПО. Согласованность (Compliance): способность ПО придерживаться стандартов или соглашений, связанных с сопровождаемостью.
Мобильность Мобильность Мобильность (Portability): способность ПО к переносу из одной среды в другую. Адаптируемость (Adaptability): способность ПО к модификации для различных указанных сред без применения других действий или средств, чем те, что предназначены для этой цели для рассматриваемого ПО. Легкость установки (Installability): способность ПО к установке в указанной среде. Сосуществование (Co-existence): способность ПО сосуществовать с другим независимым ПО в общей среде, разделяя общие ресурсы. Заменяемость (Replaceability): способность ПО к использованию вместо другого указанного ПО в среде заменяемого ПО. Согласованность (Compliance): способность ПО придерживаться стандартов или соглашений, связанных с мобильностью.
Ответить на вопросы: Ответить на вопросы: Почему считается, что стандарты помогают пользователям, заказчикам и разработчикам? Почему стандарты важны для разработчика сайта?
ГОСТ Р ИСО/МЭК 25051-2017
НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ
Системная и программная инженерия
ТРЕБОВАНИЯ И ОЦЕНКА КАЧЕСТВА СИСТЕМ И ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ (SQuaRE)
Требования к качеству готового к использованию программного продукта (RUSP) и инструкции по тестированию
Information technologies. Systems and software engineering. Systems and software Quality Requirements and Evaluation (SQuaRE). Requirements for quality of Ready to Use Software Product (RUSP) and instructions for testing
Предисловие
1 ПОДГОТОВЛЕН Обществом с ограниченной ответственностью "Информационно-аналитический вычислительный центр" (ООО ИАВЦ) на основе собственного перевода на русский язык англоязычной версии стандарта, указанного в пункте 4
2 ВНЕСЕН Техническим комитетом по стандартизации ТК 22 "Информационные технологии"
4 Настоящий стандарт идентичен международному стандарту ИСО/МЭК 25051:2014* "Системная и программная инженерия. Оценка и требования к качеству программного обеспечения и систем (SQuaRE). Требования к качеству готового к использованию программного продукта (RUSP) и инструкции по тестированию" (ISO/IEC 25051:2014 "Software engineering - Systems and software Quality Requirements and Evaluation (SQuaRE) - Requirements for quality of Ready to Use Software Product (RUSP) and instructions for testing", IDT).
________________
* Доступ к международным и зарубежным документам, упомянутым в тексте, можно получить, обратившись в Службу поддержки пользователей. - Примечание изготовителя базы данных.
ИСО/МЭК 25051 разработан подкомитетом ПК 7 "Системная и программная инженерия" совместного технического комитета СТК 1 "Информационные технологии" Международной организации по стандартизации (ИСО) и Международной электротехнической комиссии (МЭК).
Наименование настоящего стандарта изменено относительно наименования указанного международного стандарта для приведения в соответствие с ГОСТ Р 1.5-2012 (пункт 3.5).
При применении настоящего стандарта рекомендуется использовать вместо ссылочных международных стандартов соответствующие им национальные стандарты, сведения о которых приведены в дополнительном приложении ДА
5 ВВЕДЕН ВПЕРВЫЕ
6 ПЕРЕИЗДАНИЕ. Январь 2019 г.
7 Некоторые положения международного стандарта, указанного в пункте 4, могут являться объектом патентных прав. ИСО и МЭК не несут ответственности за идентификацию подобных патентных прав
Введение
Второе издание ИСО/МЭК 25051 прекращает действие и заменяет первое издание ИСО/МЭК 25051:2006, которое было технически пересмотрено. Это издание также включает в себя Техническую поправку ИСО/МЭК 25051:2006/Кор.1:2007.
Основные изменения заключаются в следующем:
- исправлены заголовки на английском и французском языках;
- внесены изменения в определение готового к использованию программного продукта (RUSP), область его применения и соответствующие примеры;
- достигнута гармонизация с текущей серией стандартов SQuaRE.
ИСО/МЭК 25051 является составной частью серии международных стандартов SQuaRE, которая состоит из следующих разделов:
- Управление качеством (ИСО/МЭК 2500n);
- Модель качества (ИСО/МЭК 2501n);
- Измерение качества ИСО/МЭК 2502n);
- Требования к качеству (ИСО/МЭК 2503n);
- Оценка качества (ИСО/МЭК 2504n);
- Расширения (ИСО/МЭК 25050 - ИСО/МЭК 25099).
Область применения RUSP непрерывно расширяется, и их правильная эксплуатация имеет большое значение для ведения бизнеса, обеспечения безопасности и удовлетворения личных потребностей.
RUSP представляет собой пакеты программного обеспечения, получаемые приобретающей стороной, которая не имеет возможность влиять на их функции и качества. Как правило, программное обеспечение продается в виде пакета либо может быть загружено через интернет вместе с документацией пользователя. RUSP может также считаться программный продукт*, с которым пользователь может работать в любое время посредством облачных вычислений. Информация, указанная на упаковке или представленная на интернет-сайте поставщика, зачастую является единственным инструментом, с помощью которого поставщик или маркетинговая организация может взаимодействовать с приобретателем или пользователем. Поэтому особенно важно предоставлять информацию, дающую возможность приобретающей стороне оценить качественные характеристики готового к использованию программного продукта с учетом их потребностей.
* Текст документа соответствует оригиналу. - Примечание изготовителя базы данных.
Выбор готового к использованию программного продукта высокого качества имеет большое значение, поскольку к RUST может предъявляться требование о возможности его использования в разных средах. Кроме того, может отсутствовать возможность сравнения данного продукта с другими схожими продуктами. Поставщикам необходимо убедиться в возможности использования функций RUSP пользователями. Некоторые поставщики могут предпочесть, чтобы оценка или сертификация таких функций проводилась группой оценки соответствия.
Кроме того, если пользователям необходима уверенность в отношении бизнес-процессов или критически важных рисков безопасности, то они для этой цели могут использовать методы, выбор которых производится уже после покупки. В настоящем стандарте не рассматриваются минимальные требования к безопасности или качеству RUSP, критические для ведения бизнеса, однако даются ссылки на соответствующую информацию (см. приложение А).
ИСО/МЭК 25051:2006 разработан на основе ИСО/МЭК 9126-1:2001 и заменяет ИСО/МЭК 12119:1994. Второе издание ИСО/МЭК 25051 представляет собой версию ИСО/МЭК 25051:2006, пересмотренную с целью соответствия ИСО/МЭК 25010:2011, который заменил модель качества ИСО/МЭК 9126-1:2001.
Указанные выше документы представляют собой основу для второй редакции стандарта, содержащей набор требований к готовому к использованию программному продукту и требования к тестированию RUSP на предмет соответствия.
1 Область применения
Настоящий стандарт применяется к готовому к использованию программному продукту (RUSP). Сокращение "RUSP" в настоящем стандарте используется как определение, означающее "готовый к использованию программный продукт".
1 Ниже приводится неисчерпывающий список примеров RUSP: текстовые процессоры, таблицы, ПО для управления базами данных, графические пакеты, ПО для работы с встроенными техническими, научными или интерактивными функциями, ПО для управления персоналом, продажами, приложения для смартфонов, бесплатное ПО и веб-приложения, такие как программы для создания веб-сайтов и (или) веб-страниц.
2 Программное обеспечение с открытым исходным кодом не относится к RUSP.
Настоящий стандарт устанавливает:
a) требования к RUSP;
b) требования к документации по тестированию RUSP, включая план тестирования, описание тестов и их результатов.
Примечание - Набор документов для тестирования называется документацией по тестированию;
c) инструкции по оценке соответствия RUSP.
В стандарт также входят рекомендации в отношении RUSP, критически важные для безопасности и ведения бизнеса.
Настоящий стандарт предназначен исключительно для того, чтобы обеспечить пользователям уверенность в соответствии предлагаемых свойств RUSP их требованиям. Стандарт не относится к реализации продукции (включая мероприятия по продаже и промежуточные продукты, например спецификации). Система обеспечения качества поставщика не входит в область применения настоящего стандарта.
Целевая аудитория настоящего стандарта включает:
a) поставщиков, которые:
1) определяют требования к RUSP;
2) оценивают собственные программные продукты на предмет соответствия заявленным характеристикам;
3) выпускают декларации соответствия (см. ИСО/МЭК 17050);
4) обращаются за сертификатами или знаками соответствия (см. Руководство 23 ИСО/МЭК);
b) сертифицирующие органы, которые могут устанавливать схемы сертификации (международные, региональные или национальные) (см. Руководство 28 ИСО/МЭК);
c) испытательные лаборатории, которые должны следовать соответствующим инструкциям в ходе тестирований для выдачи сертификата или знака соответствия (см. ИСО/МЭК 17025);
d) организации для аккредитации регистрирующих или сертифицирующих органов и лабораторий тестирования;
e) потенциальных приобретателей, которые могут:
1) сравнивать требования к запланированным рабочим задачам с информацией, содержащейся в описаниях существующих программных продуктов;
2) осуществлять поиск сертифицированного RUSP;
3) проверять соответствие требованиям иными способами;
f) конечных пользователей, которые могут извлекать преимущества из программных продуктов более высокого качества;
1) при создании сред управления и технического оснащения на базе требований к качеству и методов, изложенных в настоящем стандарте;
2) при управлении и совершенствовании собственных процессов по обеспечению качества "и управления персоналом";
h) регулирующие органы, которые могут требовать соблюдения или рекомендовать соблюдение требований настоящего стандарта в отношении RUSP, используемого для критически важных приложений, обеспечивающих безопасность или ведение бизнеса.
2 Соответствие требованиям
RUSP соответствует настоящему стандарту, если:
a) обладает свойствами, приведенными в разделе 5;
b) протестирован в соответствии с документацией по производственному тестированию, которая соответствует требованиям раздела 6;
c) выявленные в ходе тестирования несоответствия документируются и устраняются до момента выпуска продукта. Несоответствия, связанные с заявленными функциями, должны быть либо устранены, либо необходимо прекратить рекламирование таких функций. Известные несоответствия могут быть признаны приемлемыми, если:
1) не нарушают заявленный уровень качества;
2) поставщик должным образом исследовал характер и влияние несоответствия на потенциального приобретателя и признал его незначительным, а также сохранил документацию по выявленным несоответствиям для их устранения в будущем.
Раздел 7 и приложение А носят справочный характер.
Примечание - Чтобы облегчить оценку соответствия, требования настоящего стандарта должны иметь структуру, отвечающую трем условиям (с нумерацией в формате Х.Х.Х.Х). Справочные примечания дополняют эти условия и выступают в качестве инструкций.
3 Нормативные ссылки
Нормативные документы*, полностью или частично упомянутые в настоящем стандарте, обязательны для их применения. Для датированных документов используют только указанные издания. Для недатированных документов используют самые последние издания (с учетом всех изменений).
ISO/IEC 25000 Systems and software engineering - Systems and software Quality Requirements and Evaluation (SQuaRE) - Guide to SQuaRE (Системная и программная инженерия. Требования к качеству систем и программного обеспечения и их оценка (SQuaRE). Руководство по SQuaRE)
ISO/IEC 25010 Systems and software engineering - Systems and software Quality Requirements and Evaluation (SQuaRE) - System and software quality models (Системная и программная инженерия. Требования к качеству систем и программного обеспечения и их оценка (SQuaRE). Модели качества систем и программного обеспечения)
Качество программных продуктов – пожалуй, одна из самых серьезных проблем индустрии программного обеспечения. Оно предполагает набор различных характеристик: надежность, устойчивость ко взлому, способность к адаптации, совместимость, сопровождаемость, переносимость, эффективность и т. п. Поэтому в индустрии ПО существует многообразие стандартов качества.
| Таблица 1. Уровни модели CMM | ||
| № уровня | Название уровня | Ключевые области процесса |
| Начальный | Если организация находится на этом уровне, то ключевых областей процессов для нее не предусмотрено | |
| Повторяющийся | Управление программными конфигурациями. Обеспечение качества программных продуктов. Управление контрактами подрядчиков. Контроль за ходом проектов. Планирование программных проектов.У правление требованиями | |
| Определенный | Экспертные оценки. Координация взаимодействий проектных групп. Инженерия программного продукта. Комплексный менеджмент ПО. Программа обучения персонала. Определение организационного процесса. Область действия организационного процесса | |
| Управляемый | Менеджмент качества ПО. Управление процессом на основе количественных методов | |
| Оптимизируемый | Управление изменением процесса. Управление технологическими изменениями. Предотвращение дефектов |
Стандарт CMM оказался весьма успешным, и впоследствии на его основе была создана целая серия стандартов (табл. 2). Притом он получил новое имя – SW-CMM (Capability Maturity Model for Software), точнее отражающее его положение в достаточно многочисленном семействе стандартов.
| Таблица 2. Развитие стандартов CMM | |
| Название стандарта | Описание |
| System Engineering CMM (SE-CMM) | Ориентирован на вопросы системного инжиниринга – разработку продуктов (анализ требований, проектирование систем продукта и их интеграция) и их производство (планирование производственных линий и функционирование) |
| Trusted CMM (T-CMM) | Предназначен для обслуживания чувствительных и закрытых программных систем, которые требуют гарантии высокого качества ПО |
| System Security Engineering CMM (SSE-CMM) | Сфокусирован на аспектах безопасности программной инженерии, обеспечивает безопасный процесс разработки, в том числе и безопасность членов команды создателей |
| People CMM (P-CMM) | Рассматривает вопросы развития персонала в софтверных организациях |
| Software Acquisition CMM (SA-CMM) | Охватывает вопросы приобретения программных продуктов у внешних организаций |
| Integrated Product Development CMM (IPD-CMM) | Служит средой для интеграции усилий по разработке на всех этапах жизненного цикла и со стороны каждого отдела компании |
Качество программных продуктов – пожалуй, одна из самых серьезных проблем индустрии программного обеспечения. Качество – это гораздо больше, чем просто отсутствие ошибок. Оно предполагает набор различных характеристик: надежность, устойчивость ко взлому, способность к адаптации, совместимость, сопровождаемость, переносимость, эффективность и т. п. Неудивительно, что в индустрии ПО существует такое многообразие стандартов качества.
Качество было легко измерить: или нам платили, или нет.
Дин Леффингуэлл, Дон Уидриг.
Управление программными требованиями
CMM/CMMI
Наверное, самым именитым стандартом качества следует считать Capability Maturity Model (CMM) – модель оценки уровня зрелости процессов разработки вместе с его производными. Он был создан SEI (Software Engineering Institute), который финансируется за счет Министерства обороны США и является структурной единицей Университета Карнеги-Меллона. Первая официальная версия стандарта вышла в 1993 г., хотя работы над ним начались гораздо раньше – основные его положения были опубликованы еще в 1986 г.
Модель CMM (табл. 1) предусматривает пять уровней зрелости, каждому из которых соответствуют определенные ключевые области процессов (Key Process Areas, KPA).
| № уровня | Название уровня | Ключевые области процесса |
| 1 | Начальный | Если организация находится на этом уровне, то ключевых областей процессов для нее не предусмотрено |
| 2 | Повторяющийся | Управление программными конфигурациями.Обеспечение качества программных продуктов.Управление контрактами подрядчиков.Контроль за ходом проектов.Планирование программных проектов.Управление требованиями |
| 3 | Определенный | Экспертные оценки.Координация взаимодействий проектных групп.Инженерия программного продукта.Комплексный менеджмент ПО.Программа обучения персонала.Определение организационного процесса.Область действия организационного процесса |
| 4 | Управляемый | Менеджмент качества ПО.Управление процессом на основе количественных методов |
| 5 | Оптимизируемый | Управление изменением процесса.Управление технологическими изменениями.Предотвращение дефектов |
Деление на уровни и определение KPA для каждого из них позволяет последовательно внедрять CMM, используя стандарт в качестве руководства, которое может обеспечить постоянное совершенствование процесса разработки.
Стандарт CMM оказался весьма успешным, и впоследствии на его основе была создана целая серия стандартов (табл. 2). Притом он получил новое имя – SW-CMM (Capability Maturity Model for Software), точнее отражающее его положение в достаточно многочисленном семействе стандартов.
| Название стандарта | Описание |
| System Engineering CMM (SE-CMM) | Ориентирован на вопросы системного инжиниринга – разработку продуктов (анализ требований, проектирование систем продукта и их интеграция) и их производство (планирование производственных линий и функционирование) |
| Trusted CMM (T-CMM) | Предназначен для обслуживания чувствительных и закрытых программных систем, которые требуют гарантии высокого качества ПО |
| System Security Engineering CMM (SSE-CMM) | Сфокусирован на аспектах безопасности программной инженерии, обеспечивает безопасный процесс разработки, в том числе и безопасность членов команды создателей |
| People CMM (P-CMM) | Рассматривает вопросы развития персонала в софтверных организациях |
| Software Acquisition CMM (SA-CMM) | Охватывает вопросы приобретения программных продуктов у внешних организаций |
| Integrated Product Development CMM (IPD-CMM) | Служит средой для интеграции усилий по разработке на всех этапах жизненного цикла и со стороны каждого отдела компании |
Однако практическое применение стандартов серии CMM показало, что они не обеспечивают безоговорочного успеха в разработке ПО. Эти стандарты не были хорошо согласованы между собой – одновременное внедрение различных модификаций CMM могло оказаться достаточно сложной задачей и приводило в недоумение специалистов организаций, которые с этим сталкивались.
Разрешить большинство проблем CMM призван новый стандарт SEI – Capability Maturity Model Integrated (CMMI) – Интегрированная модель оценки уровня зрелости процессов разработки. Стандарт CMMI изначально создавался таким образом, чтобы объединить существующие варианты CMM и исключить какие-либо противоречия при его практическом применении в различных сферах деятельности высокотехнологичных компаний.
| № уровня | Уровень зрелости CMM | Уровень зрелости многоуровневого представления CMMI | Уровень возможностей непрерывного представления CMMI |
| 0 | – | – | Незавершенный |
| 1 | Начальный | Начальный | Выполнимый |
| 2 | Повторяющийся | Управляемый | Управляемый |
| 3 | Определенный | Определенный | Определенный |
| 4 | Управляемый | Управляемый количественно | Управляемый количественно |
| 5 | Оптимизируемый | Оптимизируемый | Оптимизируемый |
SEI отказывается от CMM и взамен активно продвигает CMMI, обещая ужесточить контроль за процессом сертификации, вводя новые классы, позволяющие сократить затраты на него и сделать его более привлекательным для небольших организаций; обеспечивая совместимость со стандартами ISO. Однако факт остается фактом: в современных условиях наличие сертификата определенного уровня CMM/CMMI не является таким значимым фактором, как несколько лет назад, и принимается без дополнительных вопросов разве что в проектах, выполняемых по государственному заказу.
Стандарты ISO
Стандарты ISO 9000 – обширная и наиболее распространенная во всем мире серия стандартов качества. Они охватывают множество отраслей современной индустрии и периодически обновляются.
Несмотря на то что ISO 9000-3 оперировал терминологией, которая используется при разработке ПО, и рассматривал характерные для программной индустрии вопросы, он являлся не более чем расширенным вариантом ISO 9001:1994, а потому не всегда соответствовал специфике программных проектов.
Сегодня ISO 9000-3 устарел, и ему на смену пришел стандарт ISO/IEC 90003:2004, который, в свою очередь, является проекцией промышленного стандарта ISO 9001:2000 на программную индустрию. По сравнению с предыдущим он гораздо более приспособлен к специфике отрасли, в частности, ссылается на модели жизненного цикла программных систем и детально рассматривает вопросы, характерные для разработки ПО. Однако стандарт ISO 90003:2004 – это стандарт обеспечения качества и не может быть использован для оценки уровня зрелости и предсказания результата программного проекта. В таких случаях прибегают к стандарту ISO/IEC 15504, созданному в рамках совместного проекта международных организаций ISO и IEC под названием SPICE (Software Process Improvement for Capability dEtermination), стартовавшего в 1993 г. Стандарт ISO/IEC 15504 предназначен для оценки процесса разработки информационных систем, в частности, программного обеспечения. Он изначально был спроектирован таким образом, чтобы в значительной степени соответствовать существующим в отрасли стандартам оценки процесса создания ПО. Именно это требование определило схожесть стандарта с основными принципами CMM/CMMI. Его текущая версия, датированная 2004 г., предусматривает шесть уровней возможностей (от нулевого до пятого), которые соответствуют уровням возможностей непрерывного представления стандарта CMMI (табл. 4).
| № уровня | Название уровня возможностей стандарта ISO/IEC 15504 | Название уровня возможностей непрерывного представления CMMI |
| 0 | Незавершенный | Незавершенный |
| 1 | Выполнимый | Выполнимый |
| 2 | Управляемый | Управляемый |
| 3 | Установленный | Определенный |
| 4 | Предсказуемый | Управляемый количественно |
| 5 | Оптимизируемый | Оптимизируемый |
Следует отметить, что в целом стандарты ISO/IEC 15504 и CMMI взаимозаменяемы, в частности, для CMMI предусматривается режим сертификации, в соответствии с которым одновременно проводится и сертификация по ISO/IEC 15504.
Качество программного продукта регламентирует стандарт ISO/IEC 9126, состоящий из отдельных частей, которые выпускаются независимо (на текущий момент их четыре: модель качества, внешние метрики, внутренние метрики и качество при использовании метрик). ISO/IEC 9126 предлагает комплексную иерархическую структуру для описания качественных характеристик ПО. Так, характеристиками качества наиболее высокого уровня являются функциональность, надежность, удобство применения, эффективность, сопровождаемость, переносимость. Каждая из них, в свою очередь, подразделяется на другие, более детальные. На текущий момент ISO/IEC 9126 – пожалуй, самый авторитетный стандарт, определяющий качество программного продукта.
Несмотря на то что ISO позже, чем SEI взялась за разработку стандартов для программной индустрии, она имеет немало шансов завоевать передовую позицию. Стандарты ISO весьма обширны, процедура сертификации хорошо отработана. Отметим, что ISO требует периодической ресертификации, чего SEI не проводила для CMM.
Шесть сигм
Начало методологии шести сигм (Six Sigma) было положено в Motorola в конце 1980-х годов. Столкнувшись с жесткой конкуренцией со стороны японских компаний, Motorola провозгласила курс на повышение качества производимой продукции, одним из направлений которого было снижение количества дефектов до уровня 6σ (где σ – дисперсия) – 3,4 дефекта на миллион возможных (на самом деле 3,4 дефекта на миллион возможных означает не 6, а 4,5 сигмы, однако разработчики методологии добавили полторы сигмы для того, чтобы учесть нестабильность процессов). Подобное значение было избрано не случайно – в результате проведенных в компании исследований было установлено, что именно такой уровень качества обеспечит, кроме явных преимуществ в виде повышения конкурентоспособности продукции, также сокращение издержек за счет уменьшения затрат на доводку некачественных разработок и устранение дефектов.
Реализация шести сигм происходит в виде процесса DMAIC (Define, Measure, Analyze, Improve, Control): определение, измерение, анализ, совершенствование и управление. Этот процесс построен на количественных методах принятия решений. Сильная сторона шести сигм – ориентация на интенсивное применение математического аппарата.
Несмотря на промышленное происхождение методология шесть сигм получила популярность среди разработчиков ПО. Ориентация на количественные методы позволила применять шесть сигм как инструмент для обеспечения постоянного совершенствования процесса. Особенно заметно его преимущество при использовании в организациях, которые достигли высоких уровней зрелости в соответствии с CMM/CMMI и ISO/IEC 15504.
Однако основное преимущество шести сигм одновременно является и основным недостатком методологии: ориентация на количественные методы предусматривает наличие возможностей для их применения. Организация должна приложить определенные усилия для того, чтобы внедрить методы количественной оценки производительности труда, показателей качества и т. д. Количественная оценка в отрасли ПО – весьма сложная задача. Неправильное применение этих методов может стать источником дополнительных проблем, а потому требует большой ответственности.
Кроме того, шесть сигм ориентирована на совершенствование процесса, она не предусматривает изначального повышения показателей его эффективности. Для этих целей необходимы другие подходы.
На практике шесть сигм очень часто успешно применяется совместно с другими стандартами и системами обеспечения качества, позволяя выявить причины проблем и помочь их устранить.
Весьма популярная в Европе методология ITIL (IT Infrastructure Library) ориентирована на обеспечение функционирования IT-инфраструктуры. ITIL разработана при участии правительства Великобритании в конце 80-х – начале 90-х годов XX в. и первоначально получила распространение в правительственных проектах этой страны.
Она стала популярной благодаря учету специфики IT-индустрии. Характерно, что ITIL послужила основой для методологии MOF (Microsoft Operations Framework), созданной Microsoft в целях управления развертыванием и функционированием инфраструктуры, построенной с применением ее собственных решений.
ITIL – это зрелая и обширная методология, охватывающая практически все вопросы, связанные с разворачиванием и использованием информационных систем. В настоящий момент она имеет следующие составляющие, соответствующие ключевым вопросам взаимодействия технологий и бизнеса: служба поддержки, оказание услуг, управление безопасностью, IT-инфраструктурой, цепочками поставок, программными проектами и активами, бизнес-вопросы обеспечения IT-проектов, в том числе и аутсорсинг. ITIL хорошо согласуется со стандартами серии ISO 9000 и может служить основой для проведения по ним последующей сертификации.
Однако данная методология не затрагивает непосредственно процессов разработки ПО, а потому обычно в софтверных компаниях применяется совместно с другими, более ориентированными на специфику ПО стандартами, например CMMI. Особую популярность ITIL получила в таких смежных с разработкой ПО областях, как служба поддержки, внедрение и сопровождение ПО, предоставление услуг по поддержке IT-инфраструктуры.
Заметим, что эта методология допускает достаточно неоднозначную интерпретацию, поэтому ее внедрение должно происходить при участии опытных специалистов во избежание упрощения и неверной трактовки ее положений.
Заключение
Не секрет, что большинство организаций, сертифицированных на самые высокие уровни CMM/CMMI, размещены в Индии. Несмотря на то что последняя – самый значимый игрок на рынке аутсорсинга программных проектов, это совершенно не означает, что индийские компании являются производителями наиболее качественного ПО. Как уже отмечалось, основная цель сертификации для них – получить билет на участие в тендерах по разработке ПО. На практике слепое копирование существующих шаблонов, регламентируемых стандартами качества, не сулит ничего хорошего: применение шаблонных подходов не дает конкурентных преимуществ. Именно поэтому многие компании, являющиеся лидерами рынка программной индустрии, не спешат проходить сертификацию по стандартам качества. Чаще всего они используют несколько стандартов одновременно наряду с собственными разработками, применяя только те их положения, которые действительно обеспечивают конкурентные преимущества. Поэтому ни в коем случае не следует рассматривать внедрение стандартов качества как самоцель. Ни один стандарт не застрахует от создания продукта, не удовлетворяющего потребности заказчика или не соответствующего рыночным ожиданиям.
Читайте также: