Качество программного обеспечения (ПО) определяется на основе изучения внешних и внутренних особенностей продукта. Внешнее качество определяется по тому, как оно работает в режиме реального времени, насколько продуктивно для пользователей. Вторая особенность фокусируется на внутренних аспектах, которые зависят от качества написанного кода. Пользователь больше сосредотачивается на том, как ПО работает на внешнем уровне, качество которого может поддерживаться только в том случае, если специалист написал хороший программный код.

Качество программного обеспечения

В настоящее время существует два важных подхода, которые используются для определения качества ПО:

1. Управление дефектами.
2. Атрибут качества.

Все, что не соответствует требованию клиента, попадает в разряд дефектов. Команда разработчиков, которая не в состоянии полностью понять требования клиента, будет допускать ошибки проектирования.

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

Качество программного обеспечения значительно улучшилось за последние два десятилетия. Одна из причин этого заключается в том, что компании используют новые технологии, такие как объектно-ориентированную разработку и инструменты CASE. Кроме того, можно наблюдать растущую важность внедрения методов управления на производстве.

Управление качеством ПО делится на три основных направления:

1. Гарантия. Разработка основ организационных мероприятий и стандартов качества программного обеспечения..
2. Планирование. Выбор соответствующих стандартов и адаптация под конкретный программный проект.
3. Контроль. Определение процессов, которые гарантируют, что разработка ПО соответствует стандартам качества.

Политика организации SQA

Политика организации в отношении качества программного обеспечения должна выполнять следующие требования:

• Соответствие целям и задачам организации.
• Приверженность общим концепциям обеспечения качества.
• Приверженность стандартам качества, принятым организацией.
• Обязательства выделять адекватные ресурсы.
• Стремление к постоянному улучшению качества и производительности организации.

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

• Ответственность за подготовку годовой программы мероприятий и бюджета SQA.
• Организация разработки планов развития системы SQA.
• Общий контроль за выполнением ежегодной программы регулярных мероприятий и запланированных проектов развития.
• Определение соответствия программы мероприятий характеристикам и объему услуг субподрядчика и закупок ПО, запланированных на будущий год.
• Презентация и пропаганда вопросов SQA для исполнительного руководства.
• Изучение предложений, подготовленных отделом SQA для ежегодной программы мероприятий, проверка потенциала предложения для достижения целей.

Концепции высокого уровня

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

Например, при оценке синтаксического анализатора XML можно использовать набор тестов на соответствие XML W3C. Он включает в себя тесты, разработанные для удовлетворения всех направлений контроля, а также рекомендации W3C Extensible Markup Language (XML) с особым акцентом на требованиях к обработке ошибок в правильности или достоверности документов XML. Таким образом процент пройденных тестовых случаев используется, как метрика для оценки следующих характеристик рассматриваемого XML-анализатора:

• Перспектива пользователя.
• Функциональность.
• Надежность и отказоустойчивость.

С точки зрения пользователя есть несколько важных характеристик, отвечающих на следующие вопросы:

• Кто предоставляет полный спектр необходимых функций по назначению?
• Надежно ли работает ПО для получения необходимых результатов при правильном использовании?
• Функционирует ли программа безопасно и надежно в случае неправильного ввода?
• Легко ли использовать программный продукт?
• ПО функционирует быстро или кажется излишне медленным?
• Хорошо ли сочетается программа с другим продуктом, который использует пользователь?

Считая, что вопросы качества пользователю важны, ИТ-группа, отвечающая за развертывание и обслуживание ПО, может столкнуться с другими проблемами:

1. Защита от вредоносных атак.
2. Качество использования вычислительных ресурсов.

Некачественными ресурсами считаются те, которые требует больше памяти и вычислительной мощности, чем необходимо.

ИСО обеспечивает эту модель двумя новыми категориями высшего уровня, связанными с технологическим обеспечением качества программного обеспечения.

Требования ISO 9126 к продукту

ISO 9126 является международным стандартом для оценки ПО. Он разделен на четыре части, в которых рассматриваются следующие темы:

• Внешние показатели.
• Внутренние показатели.
• Модель качества.
• Показатели качества программного обеспечения.

Первая часть ISO 9126 является расширением предыдущего стандарта, выполненного McCall (1977), Boehm (1978) и FURPS в определении набора характеристик качества.

• Функциональность.
• Надежность.
• Юзабилити.
• Ремонтопригодность.
• Портативность.

Функциональность продукта

Функциональность является основной целью любого продукта или услуги. Чем больше возможностей использования товара, тем сложнее становится определить его функциональность. Для ПО может быть указан список того, что для него доступно.

Некоторые перечисленные характеристики ПО (например, удобство) присутствуют только в определенной степени, то есть не просто «включен» или «отключен». Многие люди путают общую функциональность процесса и программного продукта. Часто это связано с тем, что диаграммы потоков данных (DFD) и другие инструменты моделирования могут отражать функциональность процесса, как набор преобразованных данных в data out.

ISO 9126-1 и другие модели качества не помогают измерить общие затраты или выгоды процесса, а исследуют только программный компонент. Взаимосвязь между функциональными возможностями ПО в рамках общего бизнес-процесса выходит за рамки ISO 9126.

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

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

Способность учиться использовать систему (обучаемость) является одной из основных характеристик юзабилити.

КПД связан с системными ресурсами, применяемыми при предоставлении необходимой функциональности. Объем дискового пространства, память и сеть являются хорошими показателями КПД. Как и в случае ряда других критериев, существуют совпадения между ними. Например, удобство использования системы влияет на ее производительность.

Способность идентифицировать и исправить ошибку в программном компоненте - это то, к чему относится характеристика ремонтопригодности. На ее показатели влияет читаемость или сложность кода, а также модульность. Это то, что помогает идентифицировать причину неисправности, чтобы затем устранить ее.

Характеристики ремонтопригодности:

• Анализируемость - выявляет основную причину отказа.
• Изменчивость - определяет усилия, которые прилагаются к модификации кода для устранения ошибки.
• Стабильность - демонстрирует, насколько стабильна система в работе, когда в нее вносятся изменения.
• Тестируемость - определяет, сколько усилий идет на тестирование системы.
• Переносимость - способность системы адаптироваться к изменениям в ее среде.
• Адаптируемость - насколько легко система адаптируется к изменениям, внесенным в спецификации.
• Скорость установки - насколько легко система может быть установлена.
• Возможность замены - насколько легко можно заменить компонент системы.
• Стоимость качества ПО. Она очень важна. Когда разработчик решит провести тестирование для своего продукта, он на самом деле собирается потратить время, деньги и усилия на ее проверку.
• Пригодность - определяет, соответствуют ли функции ПО требованиям.
• Точность - устанавливает правильность реализации функций.
• Функциональная совместимость - взаимодействуя с другими компонентами системы.
• Соответствие ПО необходимым законам и рекомендациям.
• Обеспечение качества и безопасности программного обеспечения и обработки транзакций, связанных с данными.
• Надежность - способность ПО работать в определенных условиях в течение обозначенного периода времени.
• Зрелость - частота сбоев ПО.
• Восстанавливаемость - представление о способности системы вернуться к полноценной работе после сбоя.

Портативность относится к тому, насколько хорошо ПО может адаптироваться к изменениям в его среде или с его требованиями. Объектно-ориентированные методы проектирования и реализации могут способствовать тому, насколько эти характеристики качества программного обеспечения присутствует в данной системе.

Стоимость процессов анализа

Стоимость качества рассчитывается путем анализа затрат на соответствие и несоответствие. Цена первого показателя связана с:

1. Расходами на профилактику. Это сумма, потраченная на обеспечение правильного соблюдения всех методов. Она включает в себя обучение командам, проверки кода и любые другие действия, связанные с QA.
2. Затратами на оценку. Это сумма денег, потраченная на планирование всех тестовых заданий, а затем на их выполнение, например, на разработку тестовых примеров.
3. Расходы на несоответствие. Это затраты, которые возникают из-за внутренних и внешних сбоев.

Внутренние сбои - это расходы, которые появляются, когда тестовые примеры выполняются впервые на внутреннем уровне, при этом некоторые из них терпят неудачу. Расходы возникают, когда программист должен исправить все дефекты, выявленные в его фрагменте во время модульного или компонентного тестирования.

Внешние сбои - это расходы, которые возникают, когда дефект устанавливается заказчиком, а не тестером. Эти расходы намного больше, чем те, которые появляются на внутреннем уровне. Особенно это актуально, если усиливается программный сбой.

Дисциплинированный анализ процесса

Это процессорная оценка программного продукта. Она включает в себя выявление и характеристику текущей практики, определение сильных и слабых сторон, а также способность контролировать или избегать существенные причины плохого качества товара. Аудит программ может быть трех типов:

1. Самооценка. Проводится внутри собственного персонала организации.
2. Оценка сторонней организации.
3. Оценка третьей стороной.

Аудит процесса ПО выполняется в открытой общей среде с целью улучшения его показателей и с использованием программ обеспечения качества программного обеспечения. Результаты такого аудита являются конфиденциальными для организации.

Что касается сбора данных, то используются четыре метода:

1. Стандартный перечень вопросов зрелости.
2. Индивидуальные и групповые интервью.
3. Обзоры документов.

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

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

функциональность,

надёжность,

лёгкость применения,

эффективность,

сопровождаемость,

мобильность.

Функциональность - это способность ПС выполнять набор функций, удовлетворяющих заданным или подразумеваемым потребностям пользователей. Набор указанных функций определяется во внешнем описании ПС.

Надежность подробно обсуждалась в первой лекции.

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

Эффективность - это отношение уровня услуг, предоставляемых ПС пользователю при заданных условиях, к объему используемых ресурсов.

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

Мобильность - это способность ПС быть перенесенным из одной среды (окружения) в другую, в частности, с одной ЭВМ на другую.

Функциональность и надёжность являются обязательными критериями качества ПС, причём обеспечение надёжности будет красной нитью проходить по всем этапам и процессам разработки ПС. Остальные критерии используются в зависимости от потребностей пользователей в соответствии с требованиями к ПС - их обеспечение будет обсуждаться в подходящих разделах курса.

2. Обеспечение надёжности - основной мотив разработки программных средств

Рассмотрим теперь общие принципы обеспечения надёжности ПС, что, как мы уже подчёркивали, является основным мотивом разработки ПС, задающим специфическую окраску всем технологическим процессам разработки ПС. В технике известны четыре подхода обеспечению надёжности :

предупреждение ошибок;

самообнаружение ошибок;

самоисправление ошибок;

обеспечение устойчивости к ошибкам.

Целью подхода предупреждения ошибок - не допустить ошибок в готовых продуктах, в нашем случае - в ПС. Проведенное рассмотрение природы ошибок при разработке ПС позволяет для достижения этой цели сконцентрировать внимание на следующих вопросах:

борьбе со сложностью;

обеспечении точности перевода;

преодоления барьера между пользователем и разработчиком;

обеспечения контроля принимаемых решений.

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

Остальные три подхода связаны с организацией самих продуктов технологии, в нашем случае - программ. Они учитывают возможность ошибки в программах. Самообнаружение ошибки в программе означает, что программа содержит средства обнаружения отказа в процессе ее выполнения. Самоисправление ошибки в программе означает не только обнаружение отказа в процессе ее выполнения, но и исправление последствий этого отказа, для чего в программе должны иметься соответствующие средства. Обеспечение устойчивости программы к ошибкам означает, что в программе содержатся средства, позволяющие локализовать область влияния отказа программы, либо уменьшить его неприятные последствия, а иногда предотвратить катастрофические последствия отказа. Однако, эти подходы используются весьма редко (может быть, относительно чаще используется обеспечение устойчивости к ошибкам). Связано это, во-первых, с тем, что многие простые методы, используемые в технике в рамках этих подходов, неприменимы в программировании, например, дублирование отдельных блоков и устройств (выполнение двух копий одной и той же программы всегда будет приводить к одинаковому эффекту - правильному или неправильному). А, во-вторых, добавление в программу дополнительных средств приводит к её усложнению (иногда - значительному), что в какой-то мере мешает методам предупреждения ошибок.

Основной проблемой в управлении качеством является тот факт, что определение качества слишком неясное и неоднозначное. Это вызвано тем, что обычно термин качество понимается неправильно. Такая путаница может объясняться несколькими причинами...

Попробуем ответить на вопросы:

• Популярный взгляд на качество
• Выводы

Что такое качество программного обеспечения?

В нашем первом выпуске мы попытаемся дать определение терминами качество и качество программного обеспечения.

Основной проблемой в управлении качеством является тот факт, что определение качества слишком неясное и неоднозначное. Это вызвано тем, что обычно термин качество понимается неправильно. Такая путаница может объясняться несколькими причинами.

Первая , качество это не отдельно взятая идея или понятие, скорее многомерная и разноплановая концепция.

Вторая , для любого понятия и определения существует несколько уровней абстракции, например, когда люди говорят о качестве, одна часть понимает под этим слишком широкий и размытый смысл, в то время как другая может ссылаться на конкретное определение и значение.

Третья , термин качество является неотъемлемой частью нашего повседневного общения, однако общепринятое и профессиональное использование может быть весьма сильно отличаться.

Популярный взгляд на качество

Общепринятое мнение о качестве таково, что это нечто нематериальное и "неосязаемое" - о нем могут вестись споры и дискуссии, его можно критиковать и восхвалять, но взвесить и измерить качество невозможно. Такие выражения как «хорошее качество» и «плохое качество» служат наглядным примером, как люди говорят о чем-нибудь неопределенном для них, то, что они не могут четко характеризовать и определить. Такое мнение отражает тот факт, что люди воспринимают и интерпретируют качество по-разному. Подразумевается, что качество не может быть контролируемым и управляемым, и тем более оно не может быть количественно измеримым. Такой взгляд ярко контрастирует с профессиональным подходом к управлению качеством - качество это четко определенная величина, которую можно измерить и проконтролировать, она поддается управлению и улучшению.

Другое популярное мнение, что качество неразрывно связанно с роскошью, первым сортом и тонким вкусом. Дорогой, досконально продуманный и более технически сложный продукт рассматривается как гарантия высочайшего качества, нежели более дешевые аналоги. Следуя такой логике Кадиллак - это качественная машина, а Шевроле нет, невзирая на надежность и количество поломок; или же HI-FI система это качественная система, а обыкновенное радио - нет. Согласно такому подходу, качество ограниченно определенным классом дорогостоящих продуктов с замысловатой функциональностью и классовым продуктам. Проще говоря, едва ли недорогой продукт будет классифицирован как качественный продукт.

Профессиональный подход к качеству

К сожалению, такое неопределенное и расплывчатое представление не может быть использовано для улучшения процессов разработки программного обеспечения. Следовательно, необходимо дать четкое и удобное для работы определение. В 1979 году Crosby определил качество как «соответствие требованиям» ("conformance to requirements"), а Juran и Gryna в 1970 определили качество как «пригодность к использованию» ("fitness for use"). Эти два определения тесно связанны и прекрасно согласуются, как мы увидим позже.

«Соответствие требованиям» предполагает, что требования должны быть настолько четко определены, что они не могут быть поняты и интерпретированы некорректно. Позже, на этапе разработки, производятся регулярные измерения разработанного продукта, для определения соответствия требованиям. Любые несоответствия должны рассматриваются как дефекты – отсутствие качества. Например, спецификация на определенную модель радиостанции может требовать возможности принимать определенную частоту радиоволн на расстоянии более чем 30 километров от источника вещания. В случае, если радиостанция неспособна выполнить данное требование, она не удовлетворяет требования к качеству и должна быть признана негодной и некачественной. Исходя из тех же принципов, если Кадиллак соответствует всем требованиям к машинам Кадиллак, значит это качественная машина. Если Шевроле соответствует всем требованиям к машинам Шевроле, следовательно, это тоже качественная машина. Эти две машины могут быть совершенно разными по стилю, скорости и экономичности, но если обе измерять по стандартным для них наборам, тогда они обе будут являться качественными машинами.

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

Эти два определения качества («соответствие требованиям» и «пригодность к использованию») по существу одинаковы. Разница в том, что вариант «пригодность к использованию» указывает на важную роль требований и ожиданий заказчика. Роль заказчика, связанная с качеством, никогда не может быть переоценена. С точки зрения заказчика, качество продукта, который он приобрел, состоит из множества различных факторов, таких как: цена, производительность, надежность и т.д.

Только ваш заказчик может рассказать вам о качестве, потому что это единственное что он действительно покупает. Заказчик не покупает продукт. Он покупает ваши гарантии того, что все его ожидания к продукту будут реализованы.

Guaspari ”I Know It When I See It”

Выводы

Давайте еще раз попытаемся дать определение качеству с точки зрения заказчика или пользователя продукта.

Качество - это пригодность к использованию. Делает ли данный продукт то, в чем я нуждаюсь, облегчает ли он мою работу, могу ли я его использовать так, как мне удобно.

А теперь посмотрим на точку зрения разработчика.

Качество - это соответствие специфицированным и собранным требованиям делает ли данный продукт все то, что указано в требованиях.

Проблема в том, что специфицированные и собранные требования это обычно лишь часть всех реальных требований и ожиданий заказчика. Где же правильное определение качества?

Качество это соответствие реальным требованиям, явным и неявным. Очень часто неявные требования настолько очевидны для заказчика или пользователя, что он даже не предполагает, что они неизвестны разработчикам. Для примера вернемся к нашим автомобилям - заказчик может детально описать требования к дизайну, параметрам двигателя, оформлению салона, цвету кузова, но нигде не указать, что шины должны быть круглыми, а лобовое стекло - прозрачным.

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

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

Современные модели качества программного обеспечения

Введение

программный качество цикл

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

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

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

Чтобы убедиться в справедливости этих утверждений, сравним два подхода к определению успешности проекта:

Приведенное определение успешности программного проекта несколько отличается от определения успешности проекта вообще, так как является более прагматичным. Оно сосредоточено на руководстве организацией, нацеленной на достижение успешного конечного результата, который в определении выражен словами «отвечающей требованиям потребителя». Тот факт, что конечный программный продукт не обладает всеми изначально запланированными возможностями, не имеет особого значения, если это удовлетворяет руководство компании, отделы маркетинга и продаж, а главное - пользователей.

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

В состав участников любого программного проекта помимо разработчиков программного обеспечения входят три основные категории. Это покупатели, пользователи и инвесторы. Каждая из этих сторон преследует свои интересы. При этом каждое физическое лицо или организация может входить как в одну, так и в несколько категорий (например, пользователь может быть покупателем, а покупатель - инвестором), а сам проект может подразумевать разработку одного из видов ПО Классификация с точки зрения участников проекта:

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

· производственного ПО, т.е. больших систем, которые разработаны для приобретения компаниями и организациями без каких-либо модификаций (например, САПР или издательские системы). Обычно покупателем является организация, занимающаяся информационными технологиями, а компания-разработчик является инвестором.

· заказного ПО - систем, разработанных в соответствии с определенным контрактом. В роли заказчика могут выступать правительственные организации или крупные компании. В зависимости от конкретного заказа роль инвестора может играть как компания - разработчик, так и компания - заказчик, либо обе эти стороны.

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

· встроенного ПО. Покупателями такого программного обеспечения чаще всего являются производители потребительских товаров, игрушек и пр., желающие внедрить данную программу в свою продукцию. Покупатели данной продукции одновременно являются и ее пользователями.

В настоящее время существует несколько схем взаимодействия между заказчиком и разработчиком ПО:

«Свой» заказчик

Ситуация, при которой команда разработчиков в течение длительного времени обслуживает единственного заказчика. Как правило, подобный вариант характеризуется отлаженными отношениями между заказчиком и разработчиками. Зачастую, такие команды располагаются на территории заказчика. Основные характеристики этого типа проекта:

· доступность заказчика в любое время;

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

· достаточно гибкие требования к качеству программного обеспечения;

· постоянное сопровождение своих продуктов, их доработка и совершенствование;

· устойчивые финансовые взаимоотношения между заказчиком и разработчиками;

· долгосрочные планы по сотрудничеству.

Продукт под заказ

Ситуация, при которой команда разработчиков находит стороннего заказчика и договаривается с ним о разработке программного продукта, призванного решить те или иные проблемы заказчика. Основные характеристики такого типа проекта:

· доступность заказчика можно охарактеризовать как «периодическую»;

· представление о нуждах и потребностях заказчика формируется на базе произведенного обследования;

· заранее оговариваются требования к программному обеспечению, согласно которым производится приемка готового продукта;

· финансовые отношения оформляются в виде разового контракта;

· планы по дальнейшему сотрудничеству в значительной мере зависят от качества и устойчивости продукта, который разработчик поставил заказчику.

Тиражируемый продукт

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

· конкретного заказчика, формирующего требования к продукту, не существует;

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

· качество программного обеспечения контролируется только внутренним отделом качества + обратная связь с пользователями. Широко используется бета-тестирование;

· разработчик в течение заранее оговоренного периода времени поддерживает поставленный продукт;

· финансовые отношения существуют в виде фиксированной цены на продукт;

· планы по развитию продукта формируются на основе анализа рынка.

Аутсорсинг

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

· разработчик не контактирует с конечным потребителем своей продукции. Вся информация получается в виде технического задания от крупной компании-подрядчика;

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

· подрядчик предоставляет свои требования к процессу производства ПО и его качеству;

· поддержку продукта, как правило, осуществляет подрядчик;

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

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

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

1. Стандарты качества программного обеспечения

В настоящее время существует несколько определений качества, которые в целом совместимы друг с другом. Приведем наиболее распространенные:

Определение ISO: Качество - это полнота свойств и характеристик продукта, процесса или услуги, которые обеспечивают способность удовлетворять заявленным или подразумеваемым потребностям.

Определение IEEE: Качество программного обеспечения - это степень, в которой оно обладает требуемой комбинацией свойств.

Основным стандартом качества в области инженерии программного обеспечения в настоящее время является стандарт ISO/IEC 9126:1-4:2002 (ГОСТ Р ИСО/МЭК 9126-93). В дополнение к нему выпущен набор стандартов ISO/IEC 14598, регламентирующий способы оценки характеристик качества. В совокупности они образуют модель качества, известную под названием SQuaRE (Software Quality Requirements and Evaluation).

В соответствии со стандартом ISO 9126 общее представление о качестве программного средства (ПС) рекомендуется описывать тремя взаимодействующими и взаимозависимыми метриками характеристик качества, отражающими:

· внешнее качество, заданное требованиями заказчика в спецификациях и отражающееся в характеристиках конечного продукта;

· внутреннее качество, проявляющееся в процессе разработки и других промежуточных этапах жизненного цикла ПС;

· качество при использовании в процессе нормальной эксплуатации и результативность достижения потребностей пользователей с учетом затрат ресурсов.

Внешние и внутренние характеристики качества касаются свойств самой программной системы и отражают взгляд заказчика и разработчика на нее. Однако конечный пользователь ждет достижения максимального совокупного эффекта от применения ПС - повышения продуктивности работы и общей удовлетворенности программным продуктом. Такой взгляд на качество программной системы обозначается термином «качество при использовании» или «эксплуатационное качество» программного средства.

Атрибуты программной системы, характеризующие ее качество, измеряются с использованием метрик качества. Метрика - это комбинация конкретного метода измерения (способа получения значений), атрибута сущности и шкалы измерения (средства, используемого для структурирования получаемых значений). Метрика определяет меру атрибута - переменную, которой присваивается значение в результате измерения (см. рисунок 3.1).

Определение требований к качеству, обычно начинается с перечисления внешних характеристик качества, отражающих требования к функционирующему программному продукту. Далее, для того чтобы количественно определить критерии качества, по которым будет осуществляться проверка и подтверждение соответствия программной системы предъявляемым к ней требованиям, специфицируются подходящие внешние измеримые свойства (внешние атрибуты) ПС и связанные с ними метрики, представляющие собой модели оценивания атрибутов, а также приемлемые диапазоны изменения значений (мер) соответствующих атрибутов (см. рис.3.1).

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

Рис. 3.1. Система измерения качества

После определения требований к внешним метрикам специфицируются внутренние характеристики качества и внутренние атрибуты ПС. Они используются для планирования достижения требуемых внешних характеристик качества конечного программного продукта и их встраивания в промежуточные (рабочие) продукты ПС в ходе разработки. Далее определяются внутренние метрики качества. Понятия внутренних характеристик качества, атрибутов и метрик связывается с не работающими на компьютере рабочими продуктами ПС (документами, текстами кода, тестами и др.), получаемыми на стадиях разработки, предшествующих тестированию (определение требований, проектирование, кодирование).

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

Метрики качества в использовании отражают, в какой степени продукт удовлетворяет потребностям конкретных пользователей в достижении заданных целей. Эти метрики не отражены в числе шести базовых характеристик, регламентируемых стандартом ISO 9126-1 вследствие их общности, однако рекомендуются для интегральной оценки результатов функционирования и применения комплексов программ в стандарте ISO 9126-4.

Общий подход к моделированию качества программного обеспечения заключается в том, чтобы сначала идентифицировать небольшой набор атрибутов (характеристик) качества самого высокого уровня абстракции и затем в направлении «сверху вниз» разбить эти атрибуты на наборы подчиненных атрибутов. Стандарт ISO/IEC 9126 является типичным примером такого подхода. Для оценки качества программного средства используется шесть групп базовых показателей, каждая из которых детализирована несколькими нормативными субхарактеристиками. Характеристики и субхарактеристики в стандарте определены кратко, без комментариев и подробных рекомендаций по их применению к конкретным системам и проектам. Изложение имеет концептуальный характер и не содержит рекомендаций по выбору и упорядочению приоритетов, а также необходимого минимума критериев в зависимости от особенностей объекта, среды разработки, сопровождения и применения. Первая часть стандарта -- ISO 9126-1 -- распределяет атрибуты качества программных средств по шести характеристикам, используемым в остальных частях стандарта. Исходя из принципиальных возможностей их измерения, все характеристики могут быть объединены в три группы, к которым применимы разные категории метрик Стандартами рекомендуется, чтобы было предусмотрено измерение каждой характеристики качества ПС (субхарактеристики или ее атрибута) с точностью и определенностью, достаточной для сравнений с требованиями технических заданий и спецификаций, и чтобы измерения были объективны и воспроизводимы. :

· категорийные, или описательные (номинальные) метрики используются для оценки функциональных возможностей программных средств;

· количественные метрики применимы для измерения надежности и эффективности сложных комплексов программ;

· качественные метрики в наибольшей степени соответствуют практичности, сопровождаемости и мобильности программных средств.

Вторая и третья части стандарта -- ISO 9126-2 и ISO 9126-3 -- посвящены формализации соответственно внешних и внутренних метрик характеристик качества сложных программных средств. Все таблицы содержат унифицированную рубрикацию, где отражены имя и назначение метрики; метод ее применения; способ измерения, тип шкалы метрики; тип измеряемой величины; исходные данные для измерения и сравнения; а также этапы жизненного цикла программного средства (по ISO 12207), к которым применима метрика. Четвертая часть стандарта -- ISO 9126-4 -- предназначена для покупателей, поставщиков, разработчиков, службы сопровождения ПО, пользователей и менеджеров качества. В ней обосновываются и комментируются выделенные показатели сферы использования программных средств и группы выбранных метрик для пользователей. Характеристики, используемые для оценки качества программного обеспечения, и уточняющие их субхарактеристики сведены в таблицу 3.1.

Табл. 3.1. Характеристики качества программного обеспечения

Функциональные возможности (Functionality) Данный набор атрибутов качества характеризует то, что программное обеспечение делает для удовлетворения потребностей пользователя, тогда как другие наборы, главным образом, характеризуют, когда и как это выполняется.	Способность программного обеспечения реализовать установленные или предполагаемые потребности пользователей
Пригодность для применения по назначению (Suitability)	Наличие и соответствие набора функций конкретным задачам
Правильность/корректность реализации требований (Accuracy) Например, необходимая степень точности вычисленных значений.	Способность программного обеспечения обеспечивать правильность (или соответствие) результатов
Способность к взаимодействию с компонентами и средой (Interoperability) Способность к взаимодействию используется вместо совместимости для того, чтобы избежать возможной путаницы с взаимозаменяемостью.	Способность ПО взаимодействовать с конкретными системами
Согласованность (Compliance)	Способность программного обеспечения придерживаться соответствующих стандартов или соглашений, или подробных рекомендаций
Защищенность/безопасность функционирования (Security)	Способность ПО предотвращать несанкционированный доступ (случайный или преднамеренный) к программам и данным
Надежность (Reliability) Износа или старения программного обеспечения не происходит. Ограничения надежности проявляются из-за ошибок возникающих на этапе определения требований, проектирования и реализации. Отказы из-за этих ошибок зависят от способа использования программного обеспечения и ранее выбранных версий программ.	Способность программного обеспечения сохранять свой уровень качества функционирования при установленных условиях за установленный период времени
Стабильность/уровень завершенности (Maturity)	Характеризуется частотой отказов, вызванных наличием ошибок в программном обеспечении
Устойчивость к ошибке (Fault tolerance)	Способность программного обеспечения поддерживать определенный уровень качества функционирования в случаях программных ошибок или нарушения определенного интерфейса
Восстанавливаемость после проявления дефектов (Recoverability) Восстанавливаемость характеризуется двумя аспектами: легкостью устранения дефектов разработки (ремонтопригодность) и легкостью технического обслуживания программного продукта в условиях его эксплуатации (поддерживаемость). Понятие дефект можно определить как некоторый аспект системы, препятствующий выполнению поставленных перед ней задач. Дефекты могут быть вызваны ошибками, допущенными при разработке, либо возникнуть из-за недопонимания требований, предъявляемых к системе. Система считается восстанавливаемой, если устранение системных дефектов является экономически эффективным . Восстанавливаемость можно обеспечить при наличии следующих двух условий: источники дефектов легко устранить, устранение одного дефекта не порождает другого. Обычно ПО является восстанавливаемым, если при проектировании системы было четко указано какие функции должна выполнять каждая из частей программы. Одним из признаков некачественной программы является уязвимость программного кода: каждый раз при устранении дефекта возникают проблемы в других частях программы.	Способность программного обеспечения восстанавливать уровень качества функционирования и данные, непосредственно поврежденные в случае отказа. Характеризуется необходимыми для этого затратами усилий и времени
Практичность (Usability) Круг пользователей может включать операторов, конечных пользователей и косвенных пользователей, на которых влияет данное программное обеспечение или которые зависят от его использования. Практичность должна рассматриваться во всем разнообразии условий эксплуатации пользователем, которые могут влиять на программное обеспечение, включая подготовку к использованию и оценку результатов.	Характеризуется объемом работ, требуемых для использования программного обеспечения определенным или предполагаемым кругом пользователей
Понятность функций и документации (Understandability)	Характеризует усилия пользователя по пониманию общей логической концепции ПО и его применимости
Изучаемость процессов функционирования и применения (Learnability)	Характеризует усилия пользователя по обучению применению программного обеспечения (например, оперативному управлению, вводу, выводу)
Простота использования (Operability)	Характеризует усилия пользователя по эксплуатации и оперативному управлению ПО
Эффективность (Efficiences) Ресурсы могут включать другие программные продукты, технические средства, расходные материалы (например, бумагу для печати, гибкие диски) и услуги эксплуатирующего, сопровождающего или обслуживающего персонала.	Определяется соотношением между уровнем качества функционирования программного обеспечения и объемом используемых ресурсов при установленных условиях
Временная эффективность реализации комплекса программ (Time behavior)	Характеризуется временем отклика и скоростью выполнения функций
Используемость вычислительных ресурсов (Resource behavior)	Характеризуется объемом используемых ресурсов и продолжительностью использования ПО при выполнении функции
Сопровождаемость (Maintainability) Изменение может включать исправления, усовершенствование или адаптацию программного обеспечения к изменениям в окружающей обстановке, требованиях и условиях функционирования.	Характеризует объем работ, требуемых для проведения конкретных изменений (модификаций)
Анализируемость (Analysability)	Характеризует усилия, необходимые для диагностики недостатков или случаев отказов или определения составных частей для модернизации
Изменяемость компонентов и комплекса программ (Changeability)	Характеризует усилия, необходимые для модификации, устранения отказа или для изменения условий эксплуатации
Устойчивость (Stability)	Характеризует риск от непредвиденных эффектов модификации
Тестируемость изменений при сопровождении (Testability)	Характеризует усилия, необходимые для проверки модифицированного программного обеспечения
Мобильность (Portability) Окружающая обстановка может включать организационное, техническое или программное окружение.	Способность программного обеспечения быть перенесенным из одного окружения в другое
Адаптируемость к изменениям среды (Adaptability)	Характеризует удобство адаптации ПО к различным конкретным условиям эксплуатации, без применения других действий или способов, кроме тех, что предназначены для этого в рассматриваемом программном обеспечении
Простота установки/внедрения/инсталляции после переноса (Installability)	Характеризует усилия, необходимые для внедрения программного обеспечения в конкретное окружение
Соответствие (Confortncnce)	Способность программного обеспечения подчиняться стандартам или соглашениям, относящимся к мобильности
Взаимозаменяемость компонентов при корректировке комплекса программ (Replaceability) Взаимозаменяемость с конкретным программным средством не предполагает, что данное средство заменимо рассматриваемым программным средством. Взаимозаменяемость может включать атрибуты простоты внедрения и адаптируемости.	Характеризует простоту и трудоемкость применения данного ПО вместо другого конкретного программного средства в среде этого средства

2. Управление качеством ПО на стадиях жизненного цикла

Для того чтобы должным образом управлять качеством на каждой стадии жизненного цикла программного средства, необходимо рассматривать разнообразные аспекты качества и учитывать изменение представлений о качестве в ходе процесса разработки. Стандарт ISO/IEC 9126 предлагает варьировать взгляды на качество продукта по стадиям ЖЦ следующим образом:

· целевое качество - необходимое и достаточное качество, которое отражает реальные потребности пользователя. Поскольку потребности, заявленные заказчиком, не всегда отражают реальные нужды пользователей относительно качества программного продукта, и эти нужды могут изменяться после того, как были зафиксированы в документации проекта, целевое качество рассматривается разработчиками как концептуальная сущность, которая не может быть полностью определена в начале проекта и должна восприниматься как ориентир. Требования к целевому качеству должны по возможности включаться в спецификацию требований к качеству ПС и оцениваться путем измерения эксплуатационного качества по завершении разработки программного продукта.

· затребованное (установленное) качество продукта - это тот уровень значений характеристик внешнего качества, который фактически заявлен в спецификации требований к качеству и должен использоваться как цель для его проверки. Требования ко всем или некоторым характеристикам качества указываются в спецификации требований к ПС. Наряду с оптимальными значениями характеристик должны также указываться минимальные значения, что поможет заказчикам и разработчикам избежать ненужного превышения стоимости и сроков разработки.

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

· оцененное (или прогнозируемое) качество продукта - качество, которое оценивается или предсказывается как качество конечного программного продукта на каждой стадии разработки на основании характеристик качества программного проекта.

· качество поставляемого продукта - это качество готового к поставке продукта, как правило, протестированного в моделируемой среде на моделируемых данных.

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

Кроме того, необходимо учитывать, что каждая из характеристик качества имеет тот или иной вес (значимость) в определенной прикладной сфере и для соответствующего сообщества пользователей, отражая их точку зрения на качество.

Представления о качестве программного обеспечения различных участников программного проекта

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

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

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

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

Второй важной проблемой является разработка удобного и профессионального пользовательского интерфейса. Приступая к проектированию интерфейса следует помнить, что возможностей программы, которые не нашли отражения в ее интерфейсе просто не существует! Ничто так не раздражает пользователя как непонятный интерфейс. Не важно, каким образом обеспечивается функциональность системы - все это бесполезно, если пользователь не имеет к ней доступа Вспомните интерфейс MS DOS или раннего MS Project. . Система с хорошим пользовательским интерфейсом всегда ведет себя именно так, как ожидает пользователь.

При создании ПО коллектив разработчиков должен сделать некоторые предположения не только о функциональности, но и об условиях эксплуатации программы (например, сколько пользователей могут одновременно просматривать web - страницу, каково максимальное количество записей в базе данных или минимальное время отклика системы на выполнение определенных задач и т.п.). Иногда эти условия бывают явными, иногда - скрытыми. Поэтому для пользователя очень важен такой атрибут качества как надежность. Надежный (отказоустойчивый) продукт создан таким образом, что работает даже при условиях, выходящих за пределы предположений, принятых при его разработке.

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

Еще одним фактором, доказывающим надежность программного обеспечения, является работоспособность - процентное соотношение времени, в течение которого программное обеспечение доступно пользователям.

Для того чтобы система была работоспособной она должна иметь большое значение времени наработки на отказ. Достижение высоких показателей работоспособности требует длительного тестирования и значительных ресурсов, поэтому задача руководителя проекта - найти компромиссное решение между стоимостью разработки ПО, сроками поставки системы и показателями ее работоспособности.

Таблица 3.2: Время простоя ПО при различных значениях показателя работоспособности

Работоспособность

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

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

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

Ну и, конечно же, покупателя волнует стоимость ПО. В стоимость входит не только стоимость покупки программного продукта. Сюда может входить ежегодная лицензионная плата, стоимость установки, настройки и внутренней поддержки, стоимость дополнений и обновлений, стоимость дополнительного аппаратного обеспечения, необходимого для работы программы. Для многих (особенно плохо разработанных) систем стоимость владения может существенно превышать первоначальную стоимость покупки.

Инвесторы - это физические лица или организации, оплачивающие разработку. Инвестор ожидает, что его вложения принесут доход. Этот доход может быть получен непосредственно от продажи программного продукта или заключаться в повышении эффективности работы организации, для которой этот продукт предназначался. Если уделяется большое внимание качеству ПО, инвестор обычно оплачивает и эксплуатационную стоимость, включающую расходы на персонал, который оказывает техническую поддержку по телефону и выезжает на места, собирает отчеты о проблемах, возникающих при использовании программы, ищет и устраняет дефекты, создает и поставляет дополнения и обновления к программам. Для заказных программ и программ, предназначенных для длительного использования, эксплуатационная стоимость чаще всего превышает стоимость разработки. Из этого следует, что более важно создание продукта с ограниченной эксплуатационной стоимостью, чем с низкой стоимостью разработки. Одним из основных факторов, влияющих на эксплуатационную стоимость ПО, является его надежность, другим - сопровождаемость и стоимость выявления и устранения дефектов в программном коде и других неисправностей на местах.

Инвесторы программных проектов обычно надеются, что новая разработка станет основой поддержания конкурентоспособности на рынке. В последние годы при разработке ПО (особенно заказного) учитывается возможность повторного использования созданного программного кода для снижения себестоимости следующей версии системы. Кроме того, разработка программного продукта обычно приводит к появлению некоторой интеллектуальной собственности, которую также можно продать.

Итак, инвесторов, в основном, интересуют три аспекта:

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

· эксплуатационная стоимость, которая увеличивает расходы, что может привести к снижению прибыли.

· стоимость интеллектуальной собственности.

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

Атрибут качества	Пользователь	Покупатель	Инвестор
Функциональность
Надежность
Практичность
Эффективность
Сопровождаемость
Мобильность

Разработчик - это физическое лицо или организация, непосредственно создающие программное обеспечение. Так как разработчики отвечают за то, что созданный программный продукт действительно удовлетворяет заданным требованиям, они заинтересованы в качестве промежуточных артефактов не меньше, чем и в качестве конечного продукта. Причем, при оценке результатов каждой промежуточной фазы цикла разработки, разработчики должны использовать различные метрики для одних и тех же характеристик качества. Так, например, пользователь понимает эффективность в терминах времени реакции, тогда как разработчик использует в проектной спецификации термины длины маршрута и времени ожидания и доступа. В то же время разработчики и заказчики и/или пользователи должны использовать одни и те же характеристики качества при приемке конечного продукта.

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

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

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

Руководителя программного проекта должно интересовать, какова будет стоимость разработки качественного ПО, и может ли компания позволить себе такие расходы. Какой уровень качества будет «по карману» для той или иной разработки?

Чтобы ответить на этот вопрос, прежде всего необходимо определить, какие из атрибутов качества приоритетны для каждой из сторон, заинтересованных в данной разработке, и найти компромиссное решение. Надо иметь в виду, что недостаточное качество приведет не просто к увеличению затрат (например на эксплуатационное и гарантийное обслуживание), но прежде всего к потере рынка, поэтому увеличение затрат на проектно-конструкторские и научно-исследовательские работы даже до 50% в целях достижения необходимого качества будет более чем оправдано в коммерческом смысле. Наиболее распространенным заблуждением является предположение, что качественное ПО - это то, которое полностью удовлетворяет требованиям и не имеет дефектов. В целом невозможно найти последний дефект и выпустить бездефектную программу. Для достижения этой цели потребуется такое тестирование, которое не может позволить себе ни одна организация. Кроме того, тестирование как средство достижения качества обладает ограниченными возможностями. В литературе приводятся примеры, когда в системах с особыми требованиями к безопасности после интенсивного тестирования и тысяч часов использования были обнаружены остаточные ошибки. И хотя обнаружение и устранение дефектов является важной задачей, программные средства часто бывают непригодными из-за дефектов разработки. Программа может работать так, как планировали программисты, она может пройти все тесты, но быть непригодной из-за того, что разработчики не понимали, что нужно пользователям. Чтобы принять решение о том, достаточно ли хорошим является разработанное ПО, надо сравнить стоимость непоставки программного продукта с эксплуатационной стоимостью в случае его поставки.

3. Современные модели качества программного обеспечения

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

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

За исключением очень простых проектов, различные компоненты ПС обычно имеют совершенно разные требования к характеристикам качества. Например, компоненты, обеспечивающие интерфейс с пользователем, характеризуются высокими требованиями к удобству использования, а базы данных - повышенными требованиями к целостности. Концептуальное разделение единого программного продукта на компоненты, характеризующиеся однотипными требованиями к качеству, помогает снизить конфликты между различными требованиями.

В пределах одной организации процессы разработки могут иметь различное наполнение и варьироваться в зависимости от применяемых в проектах методологий и интегрированных инструментов. Эти различия ограничивают возможность использования одного и того же множества метрик по различным проектам. Например, не имеет смысла сравнивать число строк кода, разработанного с применением структурных методов, с числом строк, разработанных объектно-ориентированным методом.

Если организация - разработчик специализируется на выпуске однотипных программных продуктов, в ней постепенно складываются определенные подходы к обучению сотрудников, стратегии проектирования и программирования, приемы сбора и регистрации всевозможных данных, методологии выполнения измерений и т.д. Это дает возможность использовать собственный опыт разработки программных систем со схожими характеристиками, накапливать полезную историческую информацию по проектам, относящуюся к качеству. Как следствие таким организациям удается более точно строить модель качества, выбирать подходящие метрики, устанавливать количественные меры для всех характеристик качества и прогнозировать их достижение уже на ранних стадиях разработки.

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

Существуют десятки различных подходов к обеспечению качества ПО, и у каждого из них есть как свои преимущества, так и недостатки. Одной из первых моделей качества стал стандарт ISO серии 9000, первая версия которого была выпущена в 1987 году. С тех пор сертификаты ISO серии 9000 сохраняют неизменную популярность и признаются во всем мире.

Однако время не стоит на месте, и методики, положенные в основу стандарта ISO 9001, постепенно устаревают. Наиболее существенными его недостатками считаются:

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

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

· отсутствие в стандарте механизмов, способствующих улучшению существующих процессов.

Перечисленные проблемы заставили профессиональное сообщество программистов разрабатывать более совершенные решения в области обеспечения качества, что привело к созданию в начале 90-х годов целого ряда новых стандартов и методологий. Примерами наиболее удачных и содержательных стандартов могут служить Capability Maturity Model (CMM) и ISO/IEC 15504 (SPICE).

Capability Maturity Model

Официальная история CMM Capability Maturity Model обычно переводят как «модель зрелости процесса разработки ПО», хотя более верным по смыслу был бы перевод «модель совершенствования возможностей». начинается в 1991 году, когда американский институт программной инженерии SEI, существующий при университете Карнеги-Меллон, опубликовал первую версию этого стандарта.

Изначальной целью разработки стандарта было создание методики, позволяющей крупным правительственным организациям США выбирать наилучших поставщиков ПО. Для этого предполагалось создать исчерпывающее описание способов оценки процессов разработки ПО и методики их дальнейшего усовершенствования. В результате, авторам удалось добиться такой степени подробности и детализации, что стандарт оказался пригодным и для обычных компаний-разработчиков, желающих улучшить существующие процессы.

Базовым понятием модели СММ считается зрелость компании-разработчика. Незрелой считается организация, в которой процесс разработки программного обеспечения зависит только от конкретных исполнителей и менеджеров, и решения зачастую просто импровизируются «на ходу». Как следствие, здесь высока вероятность превышения бюджета или срыва сроков окончания проекта.

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

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

В модели CMM определено пять уровней зрелости организаций. В результате аттестации компании присваивается определенный уровень, который в дальнейшем может повышаться или (теоретически) понижаться. На рисунке 3.2 перечислены некоторые технологии, внедрение которых необходимо для достижения различных уровней зрелости организации. Отметим, что каждый следующий уровень включает в себя все ключевые характеристики предыдущих.

Рис. 3.2. Пять уровней зрелости в модели CMM.

Начальный уровень (initial level) описан в стандарте в качестве основы для сравнения со следующими уровнями. Если компания-разработчик находится на начальном уровне организации, в ней фактически не существует стабильных условий для создания качественного программного обеспечения. Результат любого проекта целиком и полностью зависит от личных качеств менеджера и опыта программистов, причем успех в одном проекте может быть повторен только в случае назначения тех же менеджеров и программистов на следующий проект. Более того, если такие менеджеры или программисты уходят из компании, то с их уходом резко падает качество производимых программных продуктов. В стрессовых ситуациях процесс разработки сводится к написанию кода и его минимальному тестированию.

Для достижения повторяемого уровня (repeatable level) на предприятии должны быть внедрены технологии управления проектами. При этом планирование и управление проектами основывается на накопленном опыте, существуют стандарты на разрабатываемое программное обеспечение (причем обеспечивается следование этим стандартам!) и существует специальная группа обеспечения качества. Применяемые средства планирования и управления дают возможность повторения ранее достигнутых успехов. В случае необходимости организация может взаимодействовать с субподрядчиками. Однако в критических условиях процесс имеет тенденцию скатываться на начальный уровень.

Далее следует определенный уровень (defined level), который характеризуется тем, что стандартный процесс создания и сопровождения программного обеспечения задокументирован (включая и разработку ПО, и управление проектами). Подразумевается, что в процессе стандартизации происходит переход на наиболее эффективные практики и технологии. Для создания и поддержания подобного стандарта в организации должна быть создана специальная группа. Наконец, обязательным условием для достижения данного уровня является наличие на предприятии программы постоянного повышения квалификации и обучения сотрудников. Начиная с этого уровня, организация перестает зависеть от личностных и профессиональных качеств конкретных разработчиков, и не имеет тенденции скатываться на уровень ниже в стрессовых ситуациях.

На управляемом уровне (managed level) в организации устанавливаются количественные показатели качества - как на программные продукты, так и на процесс в целом. Это обеспечивает более точное планирование проекта и контроль качества его результатов. Основное отличие от предыдущего уровня состоит в более объективной, количественной оценке продукта и процесса. Таким образом, более совершенное управление проектами достигается за счет уменьшения отклонений различных показателей проекта. При этом осмысленные вариации в производительности процесса можно отличить от случайных вариаций (шума), особенно в хорошо освоенных областях.

Наконец, оптимизирующий уровень (optimizing level) характеризуется тем, что мероприятия по улучшению применяются не только к существующим процессам, но и для оценки эффективности ввода новых технологий. Основной задачей всей организации на этом уровне является постоянное улучшение существующих процессов. При этом улучшение процессов в идеале должно помогать предупреждать возможные ошибки или дефекты. Кроме того, должны вестись работы по уменьшению стоимости разработки программного обеспечения, например, с помощью создания и повторного использования компонентов.

Каждый уровень СММ характеризуется областью ключевых процессов (ОКП), причем считается, что каждый последующий уровень включает в себя все характеристики предыдущих уровней. Иначе говоря, для 3-го уровня зрелости рассматриваются ОКП 3-го уровня, ОКП 2-го уровня и ОКП 1-го уровня. Область ключевых процессов образуют процессы, которые при совместном выполнении приводят к достижению определенного набора целей. Если все цели ОКП достигнуты, компании присваивается сертификат данного уровня зрелости. Если хотя бы одна цель не достигнута, то компания не может соответствовать данному уровню СММ.

При сертификации проводится оценка соответствия всех ключевых областей по 10-балльной шкале. Для успешной квалификации данной ключевой области необходимо набрать не менее 6 баллов. Оценка ключевой области производится по следующим показателям:

...

Подобные документы

Схемы взаимодействия между заказчиком и разработчиком программного обеспечения. Качество программного обеспечения и определение основных критериев его оценка на современном этапе, особенности управления на стадиях жизненного цикла, анализ достаточности.

презентация , добавлен 14.08.2013


Реализация задачи использования методики SDLC (управление жизненным циклом разработки программного обеспечения) при внедрении реальной системы информационных технологий. Описание проекта внедрения системы автоматической регистрации участников выставок.

реферат , добавлен 10.09.2010


Понятие программного обеспечения, вопросы его разработки и использования. Общая характеристика системного программного обеспечения и работа операционной системы. Специфика процесса управления разработкой программного обеспечения и его особенности.

курсовая работа , добавлен 23.08.2011


Основные процессы разработки, приобретения и внедрения сложных систем. Семейство стандартов ISO 9000. Зрелые и незрелые организации-разработчики программного обеспечения. Основные направления формирования метрик для оценки компьютерных программ.

дипломная работа , добавлен 27.11.2012


Современные инструменты разработки программного обеспечения для СУТП. Универсальные языки программирования и сравнение их со SCADA-системами. Разработка программного обеспечения с использованием многоканальных измерительных преобразователей Ш9327.

дипломная работа , добавлен 13.07.2011


Этапы разработки технического задания. Спецификация программного обеспечения при структурном подходе. Дерево диаграмм, базовые понятия сетевой модели данных. Разработка пользовательского интерфейса. Разработка сценария диалога на основе экранных форм.

курсовая работа , добавлен 24.06.2012


Цели и задачи программной инженерии. Понятие программного обеспечения. Шесть принципов эффективного использования программного обеспечения. Виды программного обеспечения: общесистемное, сетевое и прикладное. Принципы построения программного обеспечения.

курсовая работа , добавлен 29.06.2010


Базовые основы разработки программного обеспечения: его классический жизненный цикл, макетирование, стратегии конструирования, модели качества процессов разработки. Применение параллельных алгоритмов и CASE-системы, критерии оценки их эффективности.

курсовая работа , добавлен 07.04.2015


Изучение основных видов угроз программного обеспечения. Выявление наиболее эффективных средств и методов защиты программного обеспечения. Анализ их достоинств и недостатков. Описания особенностей лицензирования и патентования программного обеспечения.

курсовая работа , добавлен 29.05.2013


Общий календарный план выполнения этапов проекта программного обеспечения. Последовательность разработки согласно классической каскадной модели. Изображение хода работ по спиральной модели согласно Боему. Технические требования на продукт, WBS-структура.

Основным стандартом качества в области инженерии программного обеспечения в настоящее время является стандарт ISO/IEK 9126. Он определяет номенклатуру, атрибуты и метрики требований качества программного обеспечения. Относительно недавно этот стандарт стал одним из определяющих факторов при моделировании качества программного обеспечения и остается им до сих пор.

В дополнение к нему выпущен набор стандартов ISO/IEK 14598, регламентирующий способы оценки этих характеристик. В совокупности они образуют модель качества, известную под названием SQuaRE.

Общий подход заключается в том, чтобы сначала идентифицировать небольшой набор атрибутов качества самого высокого уровня абстракции и затем в направлении «сверху вниз» разбить эти атрибуты на наборы подчиненных атрибутов. Стандарт ISO/IEK 9126 является типичным примером такого подхода.

В рамках модели SQuaRE выделяются следующие 6 основных характеристик качества:

1. Функциональность (точность, согласованность, интероперабельность, безопасность, пригодность). Функциональные требования традиционно составляют основной предмет спецификации, моделирования, реализации и аттестации программного обеспечения. Они формулируются в виде утверждений в императивной модальности, описывающих поведение системы. Использование формальных методов позволяет довести уровень отклонения фактического поведения системы от требуемого практически до нуля. Это достигается путём выражения функциональных требований в виде предложений подходящих формальных исчислений, так что верификация сводится к строгому доказательству.

2. Надёжность (устойчивость, завершенность, восстанавливаемость). Показатели надёжности характеризуют поведение системы при выходе за пределы штатных значений параметров функционирования по причине сбоя в окружении либо в самой системе. При оценке атрибутов надёжности применяются методы теории вероятностей и математической статистики. Требования к надёжности особенно важны при разработке критических систем обеспечения безопасности жизнедеятельности. Хотя использование формальных методов способствует снижению количества внутренних ошибок (т.е. росту завершенности системы), обеспечение надёжности в целом требует специальных подходов, учитывающих специфику различных типов систем.

3. Удобство (эффективность освоения, эргономичность, понимаемость). Соответствие системы требованиям к удобству чрезвычайно трудно поддается оценке. Предлагаемые подходы включают замеры расхода нормативных единиц труда(нормо-часов), затрачиваемого пользователями на овладение системой, а также проведение и анализ экспертных оценок, в том числе с применением методов нечеткой логики(fuzzy logic). В контексте использования формальных методов наилучшим решением представляется изначальная ориентация на формализмы, способные максимально точно отразить структуру исходной предметной области. Например, при создании вычислительных систем критерием адекватности формализма с точки зрения будущего пользователя является поддержка абстрактного математического языка, не зависящего от концептуальных ограничений, накладываемых компьютерными технологиями.

4. Эффективность (по ресурсам и по времени). Атрибуты эффективности традиционно относятся к числу важнейших количественных показателей качества программных систем. Их значения подлежат фиксации в эксплуатационной документации программным и аппаратным изделием. Имеется высокоразвитый инструментарий для измерения этих значений. Разработаны также методики, позволяющие прогнозировать интегральные значения показателей эффективностей системы исходя из значений этих показателей для компонентов самой системы и её окружения. Выбору формальных методов обеспечения эффективности следует уделять особое внимание. При этом, следует иметь ввиду, что, хотя имеется тесная взаимосвязь между производительностью и ресурсоёмкостью, подходы к обеспечению каждого из этих требований в общем случае имеют различную природу.

5. Сопровождаемость (простота анализа, изменяемость, стабильность). Требования сопровождаемости направлены в первую очередь на минимизацию усилий по сопровождению и модернизации системы, затрачиваемых эксплуатационным персоналом. Для их оценки используется различные методики прогнозирования затрат на выполнение типовых процедур сопровождения. Интегральная стоимость сопровождения долгоживущих систем может существенно превышать стоимость их разработки. Сопровождение существенно упрощается в случае, когда разработка велась с использованием формальных методов, поскольку имеется в определённом смысле, исчерпывающий комплект технологической документации и проверочных тестов.

6. Переносимость (адаптируемость, согласованность со стандартами и правилами, гибкость инсталляции, заменяемость). Переносимость систем характеризует степень свободы при выборе компонентов системного окружения, необходимых для её функционирования. Оценка переносимости затрудняется принципиальной незавершённостью, динамичностью списка возможных вариантов окружения, обусловлены быстрым прогрессом в сфере IT. Системы, разрабатываемые с использованием формальных методов, как правило, отличаются высоким уровнем переносимости. В частности, если такая система не поддерживает некоторую целевую технологическую платформу, создание «клона» реализация её абстрактной модели с использованием целевых средств программирования требует существенно меньших затрат, чем замена самой системы либо платформы.

Модель качества, создаваемая в рамках данного стандарта, определяется общими характеристиками продукта. Характеристики же, в свою очередь, могут быть уточнены, другими словами, иерархично разбиты на подхарактеристики качества. Так, например, характеристика сопровождаемости может быть представлена такими подхарактеристиками как простота анализа, изменяемость, стабильность, проверяемость.

И, наконец, нижний уровень иерархии представляют непосредственно атрибуты программного обеспечения, поддающиеся точному описанию и измерению. Требования качества в свою очередь могут быть представлены как ограничения на модель качества. Оценка качества продукта в таком случае происходит по следующей схеме. Вначале оцениваются атрибуты программного изделия. Для этого выбирается метрика и градуируется шкала оценки в зависимости от возможных степеней соответствия атрибута накладываемыми ограничениями. Для каждой отдельной оценки атрибута градация обычно выбирается заново и зависит от требований качества, накладываемых на него. Набор «измеренных» атрибутов представляют собой критерии для оценки подхарактеристики и характеристик, и как результат качества продукта.

Билет 26 27

Ка́чество програ́ммного обеспечения - характеристика программного обеспечения (ПО) как степени его соответствия требованиям. При этом требования могут трактоваться довольно широко, что порождает целый ряд независимых определений понятия. Чаще всего используется определение ISO 9001, согласно которому качество есть «степень соответствия присущих характеристик требованиям».

Качество исходного кода

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

Читаемость кода

Лёгкость поддержки, тестирования, отладки, исправления ошибок, изменения и портируемости

Низкая сложность кода

Низкое использование ресурсов: памяти и процессорного времени

Корректная обработка исключительных ситуаций

Малое число предупреждений при компиляции и линковке

Методы улучшения качества кода: рефакторинг.

Факторы качества

Фактор качества ПО - это нефункциональное требование к программе, которое обычно не описывается в договоре с заказчиком, но, тем не менее, является желательным требованием, повышающим качество программы.

Некоторые из факторов качества:

понятность

Назначение ПО должно быть понятным, из самой программы и документации.

Все необходимые части программы должны быть представлены и полностью реализованы.

краткость

Отсутствие лишней, дублирующейся информации. Повторяющиеся части кода должны быть преобразованы в вызов общей процедуры. То же касается и документации.

портируемость

Лёгкость в адаптации программы к другому окружению: другой архитектуре, платформе, операционной системе или её версии.

согласованность

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

сопровождаемость

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

тестируемость

Позволяет ли программа выполнить проверку приёмочных характеристик, поддерживается ли возможность измерения производительности.

удобство использования

Простота и удобство использования программы. Это требование относится прежде всего к интерфейсу пользователя.

надёжность

отсутствие отказов и сбоев в работе программ, а также простота исправления дефектов и ошибок:

структурированность

эффективность

Насколько рационально программа относится к ресурсам (память, процессор) при выполнении своих задач.

Безопасность

ISO 9126 (ГОСТ Р ИСО / МЭК 9126-93) - «Информационная технология. Оценка программного продукта. Характеристики качества и руководство по их применению». ISO 9126 это международный стандарт, определяющий оценочные характеристики качества программного обеспечения (далее ПО). Российский аналог стандарта ГОСТ 28195. Стандарт разделяется на 4 части, описывающие следующие вопросы: модель качества; внешние метрики качества; внутренние метрики качества; метрики качества в использовании

Модель качества, установленная в первой части стандарта ISO 9126-1, классифицирует качество ПО в 6-ти структурных наборах характеристик, которые в свою очередь детализированы под-характеристиками(субхарактеристиками), такими как:

Функциональность - Набор атрибутов характеризующий, соответствие функциональных возможностей ПО набору требуемой пользователем функциональности. Детализируется следующими подхарактеристиками (субхарактеристиками):

Пригодностью для применения

Корректностью (правильностью, точностью)

Способностью к взаимодействию (в частности сетевому)

Защищенностью

Надёжность - Набор атрибутов, относящихся к способности ПО сохранять свой уровень качества функционирования в установленных условиях за определенный период времени. Детализируется следующими подхарактеристиками (субхарактеристиками):

Уровнем завершенности (отсутствия ошибок)

Устойчивостью к дефектам

Восстанавливаемостью

Доступностью

Готовностью

Практичность (применимость) - Набор атрибутов, относящихся к объему работ, требуемых для исполнения и индивидуальной оценки такого исполнения определенным или предполагаемым кругом пользователей. Детализируется следующими подхарактеристиками (субхарактеристиками):

Понятностью

Простотой использования

Изучаемостью

Привлекательностью

Эффективность - Набор атрибутов, относящихся к соотношению между уровнем качества функционирования ПО и объемом используемых ресурсов при установленных условиях. Детализируется следующими подхарактеристиками (субхарактеристиками):

Временной эффективностью

Используемостью ресурсов

Сопровождаемость - Набор атрибутов, относящихся к объему работ, требуемых для проведения конкретных изменений (модификаций). Детализируется следующими подхарактеристиками (субхарактеристиками):

Удобством для анализа;

Изменяемостью

Стабильностью

Тестируемостью

Мобильность - Набор атрибутов, относящихся к способности ПО быть перенесенным из одного окружения в другое. Детализируется следующими под характеристиками (субхарактеристиками):

Адаптируемостью

Простотой установки (инсталляции)

Сосуществованием (соответствием)

Замещаемостью

Подхарактеристика Соответствие не приведена в вышеописанном списке, но она принадлежит всем характеристикам. Эта характеристика должна отражать отсутствие противоречий с иными стандартами или характеристиками. Например соответствие надежности и практичности.

Каждая качественная подхарактеристика (субхарактеристика) (например адаптируемость) в дальнейшем разделяется на атрибуты. Атрибут - это сущность, которая может быть проверена или измерена в программном продукте. Атрибуты не определены в стандарте из-за их разнообразия в различных программных продуктах.

В стандарте выделена модель характеристик качества в использовании. Основными характеристиками качества программных средств (далее ПС) в использовании рекомендуются:

Системная эффективность - "Применения программного продукта по назначению"

Продуктивность - "Производительность при решении основных задач ПС, достигаемая при реально ограниченных ресурсах в конкретной внешней среде применения"

Безопасность - "Надежность функционирования комплекса программ и возможный риск от его применения для людей, бизнеса и внешней среды"

Удовлетворение требований и затрат пользователей в соответствии с целями применения ПС

Вторая и третья части стандарта ISO 9126-2,3 посвящены формализации соответственно внешних и внутренних метрик характеристик качества сложных ПС. В ней изложены содержание и общие рекомендации по использованию соответствующих метрик и взаимосвязей между типами метрик.

Четвертая часть стандарта ISO 9126-4 предназначена для покупателей, поставщиков, разработчиков, сопровождающих, пользователей и менеджеров качества ПС. В ней повторена концепция трех типов метрик, а также аннотированы рекомендуемые виды измерений характеристик ПС.