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

Реферат к лекции 9. Роль и обязанности архитектора программных средств.

Выполнил: Светличный Егор, группа ИДБ-18-06

Проверил: Косилов Глеб, группа ИДБ-18-06

Модель CMM

Capability Maturity Model — модель зрелости возможностей (модель полноты потенциала) создания ПО: эволюционная модель развития способности компании разрабатывать программное обеспечение.

❌ Лишняя модель относительно вопроса.

В ноябре 1986 года американский институт Software Engineering Institute (SEI) совместно с Mitre Corporation начали разработку обзора зрелости процессов разработки программного обеспечения, который был предназначен для помощи в улучшении их внутренних процессов.

Уровни:

• Начальный. Самый примитивный статус организации. Организация способна разрабатывать ПО. Организация не имеет явно осознанного процесса, и качество продукта целиком определяется индивидуальными способностями разработчиков. Один проявляет инициативу, и команда следует его указаниям. Успех одного проекта не гарантирует успех другого. При завершении проекта не фиксируются данные о трудозатратах, расписании и качестве.
• Повторяемый. В некоторой степени отслеживается процесс. Делаются записи о трудозатратах и планах. Функциональность каждого проекта описана в письменной форме. В середине 1999 года лишь 20 % организаций имели 2-й уровень или выше.
• Установленный. Имеют определённый, документированный и установленный процесс работы, не зависящий от отдельных личностей. Вводятся согласованные профессиональные стандарты, а разработчики их выполняют. Такие организации в состоянии достаточно надёжно предсказывать затраты на проекты, аналогичные выполненным ранее.
• Управляемый. Могут точно предсказать сроки и стоимость работ. Есть база данных накопленных измерений, но нет изменений при появлении новых технологий и парадигм.
• Оптимизированный. Есть постоянно действующая процедура поиска и освоения новых и улучшенных методов и инструментов.

Использование модели на практике выявило неоднозначность в подходах к достижению более высоких уровней организации процессов разработки ПО. Поэтому к 2002 году разрабатываются рекомендации по улучшению процесса разработки, которые получают название CMMI (Capability Maturity Model Integration). На текущий момент последняя версия CMMi — 1.3 (опубликована в ноябре 2010).

Модель SPICE

В 1991 году Международная организация по стандартизации инициировала работу по созданию единого стандарта оценки программных процессов SPICE (Software Process Improvement and Capability dEtermination, определение возможностей и улучшение процесса создания программного обеспечения).

❌ Аналогично, это модель не из темы вопроса

Официально стандарт называется "ISO/IEC 15504: Information Technology - Software Process Assessment" Задачей SPICE является создание международного стандарта, в котором был бы учтен весь накопленный опыт в области разработки ПО. Так же, как и в CMM, основной задачей организации является постоянное улучшение процесса разработки ПО. В SPICE используется схема с различными уровнями возможностей (в SPICE определено 6 различных уровней), но эти уровни применяются не только к организации в целом, но и к отдельно взятым процессам.

Уровни:

• Процесс не выполняется
• Выполняемый процесс (Измерение производительности процесса)
• Управляемый процесс (Управление производительностью, Управление созданием продуктов)
• Установленный процесс (Документирование процесса, Отслеживание ресурсов процесса)
• Предсказуемый процесс (Измерение процесса, Управление процессом)
• Оптимизирующий процесс (Изменение процесса, Постоянное совершенствование)

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

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

Модель МакКола

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

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

Рис. 1. Модель качества программного обеспечения МакКола.

Модель Боэма

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

Рис. 2. Модель качества программного обеспечения Боэма.

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

Модель FURPS/FURPS+

Акроним FURPS, используемый в обозначении модели, обозначает следующие категории требований к качеству ПО:

• Functionality (Функциональность) /особенности, возможности, безопасность/;
• Usability (Практичность) /человеческий фактор, эргономичность, пользовательская документация/;
• Reliability (Надежность) /частота отказов, восстановление информации, прогнозируемость/;
• Performance (Производительность) /время отклика, пропускная способность, точность, доступность, использование ресурсов/;
• Supportability (Эксплуатационная пригодность)/тестируемость, расширяемость, адаптируемость, сопровождаемость, совместимость, конфигурируемость, обслуживаемость, требования к установке, локализуемость/.
• Символ «+» дополняет FURPS следующими атрибутами: ограничения проекта (ограничения по ресурсам, требования к языкам и средствам разработки, требования к аппаратному обеспечению); интерфейс (ограничения, накладываемые на взаимодействие с внешними системами); требования к выполнению;физические требования; требования к лицензированию.

Модель качества FURPS, предложенная Р. Грейди и Hewlett Packard, построена схожим образом с моделями МакКола и Боэма, но в отличие от них состоит из двух слоев: первый определяет характеристики, а второй связанные с ними атрибуты. Основной концепцией, лежащей в основе FURPS, является декомпозиция характеристик программного обеспечения на две категории требований, а именно, функциональные (F) и нефункциональные (URPS) требования. Эти выделенные категории могут быть использованы как в качестве требований к программному продукту, так и в оценке его качества.

Модель Гецци

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

Модель SATC

В Центре обеспечения качества программного обеспечения NASA (Software Assurance Technology Center, SATC) была разработана программа метрик, обеспечивающая оценку рисков проекта, качества продукции и эффективности процессов. Программа SATC рекомендует отдельно отслеживать качество требований, качество программного обеспечения и других продуктов (документации), качество тестирования и качество выполнения процессов. Модель качества SATC определяет набор целей, связанных с программным продуктом и атрибуты процессов в соответствии со структурой модели качества программного обеспечения ISO 9126-1.

Модель ISO 9126

Качество программного обеспечения определяется в стандарте ISO 9126-1 как всякая совокупность его характеристик, относящихся к возможности удовлетворять высказанные или подразумеваемые потребности всех заинтересованных лиц. Модель качества ISO 9126-1 различает понятия внутреннего качества, связанного с характеристиками ПО самого по себе, без учета его поведения; внешнего качества, характеризующего ПО с точки зрения его поведения; и качества ПО при использовании в различных контекстах – того качества, которое ощущается пользователями при конкретных сценариях работы ПО. Для всех этих аспектов качества введены метрики, позволяющие оценить их. Кроме того, для создания надежного ПО существенно качество технологических процессов его разработки. Взаимоотношения между этими аспектами качества по схеме, принятой ISO/IEC 9126 показано на рисунке 3.

Рис. 3. Взаимоотношения аспектов качества

На рисунке 4 представлены факторы и атрибуты внешнего и внутреннего качества программного обеспечения в соответствии с ISO/IEC 9126.

Рис. 4. Факторы и атрибуты качества

На рисунке 5 приведена модель оценивания согласно ISO/IEC 9126.

Рис. 5. Модель оценивания качества

Модель Дроми

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

Модель QMOOD

Джагдиш Банзия и Карл Дэвис предложили иерархическую модель качества для объектно-ориентированного проектирования (QMOOD), которая расширяет методологию модели качества Дроми и включает в себя четыре уровня:

1. Определение показателей качества проекта: набор атрибутов качества проекта, которые используются в QMOOD для описания характеристик объектно-ориентированных систем включат: функциональность, эффективность, понятность, расширяемость, возможность многократного использования и гибкость.
2. Определение объектно-ориентированных свойств проекта: свойства проекта могут быть определены в процессе исследования внутренней и внешней структуры, функциональности компонент проекта, атрибутов, методов и классов. Структурным и объектно-ориентированным множеством свойств проекта, которые используются в QMOOD, являются: размер проекта, иерархическая структура, инкапсуляция, связанность, состав проекта, наследование, полиморфизм, обмен информацией, сложность.
3. Определение объектно-ориентированных метрик проекта: различные объектно-ориентированные метрики проекта.
4. Определение объектно-ориентированных свойств проекта: Компоненты проекта были определены для определения архитектуры объектно-ориентированного проекта. Эта модель определяет парадигму, а также вводит ряд новых объектно-ориентированных метрик.

Модель SQuaRЕ

В дополнение к ISO 9126 выпущен набор стандартов ISO/IEC 14598, регламентирующий способы оценки этих характеристик. В совокупности они образуют модель качества, известную под названием SQuaRE (Software Quality Requirements and Evaluation).

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

1. Функциональность (точность, согласованность, интероперабельность, безопасность, пригодность). Функциональные требования традиционно составляют основной предмет спецификации, моделирования, реализации и аттестации программного обеспечения. Они формулируются в виде утверждений в императивной модальности, описывающих поведение системы. Использование формальных методов позволяет довести уровень отклонения фактического поведения системы от требуемого практически до нуля.
2. Надежность (устойчивость, завершенность, восстанавливаемость). Показатели надежности характеризуют поведение системы при выходе за пределы штатных значений параметров функционирования по причине сбоя в окружении либо в самой системе. При оценке атрибутов надежности применяются методы теории вероятностей и математической статистики. Требования к надежности особенно важны при разработке критических систем обеспечения безопасности жизнедеятельности (dependable systems). Хотя использование формальных методов способствует снижению количества внутренних ошибок (т.е. росту завершенности системы), обеспечение надежности в целом требует специальных подходов, учитывающих специфику различных типов систем.
3. Удобство (эффективность освоения, эргономичность, понимаемость). Соответствие системы требованиям к удобству чрезвычайно трудно поддается оценке. Предлагаемые подходы включают замеры расхода нормативных единиц труда (нормо-часов), затрачиваемого пользователями на овладение системой, а также проведение и анализ экспертных оценок, в том числе с применением методов нечеткой логики (fuzzy logic). В контексте использования формальных методов наилучшим решением представляется изначальная ориентация на формализмы, способные максимально точно отразить структуру исходной предметной области.
4. Эффективность (по ресурсам и по времени). Атрибуты эффективности традиционно относятся к числу важнейших количественных показателей качества программных систем. Их значения подлежат фиксации в эксплуатационной документации к программным и аппаратным изделиям. Имеется высокоразвитый инструментарий для измерения этих значений. Разработаны также методики, позволяющие прогнозировать интегральные значения показателей эффективности системы исходя из значений этих показателей для компонентов самой системы и ее окружения. Выбору формальных методов обеспечения эффективности следует уделять особое внимание. При этом следует иметь в виду, что, хотя имеется тесная взаимосвязь между производительностью и ресурсоемкостью, подходы к обеспечению каждого из этих требований в общем случае имеют различную природу.
5. Сопровождаемость (простота анализа, изменяемость, стабильность, проверяемость). Требования к сопровождаемости направлены в первую очередь на минимизацию усилий по сопровождению и модернизации системы, затрачиваемых эксплуатационным персоналом. Для их оценки используются различные методики прогнозирования затрат на выполнение типовых процедур сопровождения. Интегральная стоимость сопровождения долгоживущих систем может существенно превышать стоимость их разработки.
6. Переносимость (адаптируемость, согласованность со стандартами и правилами, гибкость инсталляции, заменяемость). Переносимость системы характеризует степень свободы в выборе компонентов системного окружения, необходимых для ее функционирования. Оценка переносимости затрудняется принципиальной незавершенностью, динамичностью списка возможных вариантов окружения, обусловленной быстрым прогрессом в сфере информационных технологий. Системы, разрабатываемые с использованием формальных методов, как правило, отличаются высоким уровнем переносимости.

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

❌ Вот и нужно было модели оценки процессов привести в реферате про зрелось процессов, а не здесь.

Ссылки

• Современные модели качества программного обеспечения
• Capability Maturity Model
• Методы оценки и измерения характеристик информационных систем
• Cравнение моделей качества программного обеспечения