exam09 3
Реферат к лекции 9 Модели качества программных средств и программного обеспечения
Выполнил: Светличный Егор, группа ИДБ-18-06
Capability Maturity Model — модель зрелости возможностей (модель полноты потенциала) создания ПО: эволюционная модель развития способности компании разрабатывать программное обеспечение. В ноябре 1986 года американский институт Software Engineering Institute (SEI) совместно с Mitre Corporation начали разработку обзора зрелости процессов разработки программного обеспечения, который был предназначен для помощи в улучшении их внутренних процессов.
- Начальный. Самый примитивный статус организации. Организация способна разрабатывать ПО. Организация не имеет явно осознанного процесса, и качество продукта целиком определяется индивидуальными способностями разработчиков. Один проявляет инициативу, и команда следует его указаниям. Успех одного проекта не гарантирует успех другого. При завершении проекта не фиксируются данные о трудозатратах, расписании и качестве.
- Повторяемый. В некоторой степени отслеживается процесс. Делаются записи о трудозатратах и планах. Функциональность каждого проекта описана в письменной форме. В середине 1999 года лишь 20 % организаций имели 2-й уровень или выше.
- Установленный. Имеют определённый, документированный и установленный процесс работы, не зависящий от отдельных личностей. Вводятся согласованные профессиональные стандарты, а разработчики их выполняют. Такие организации в состоянии достаточно надёжно предсказывать затраты на проекты, аналогичные выполненным ранее.
- Управляемый. Могут точно предсказать сроки и стоимость работ. Есть база данных накопленных измерений, но нет изменений при появлении новых технологий и парадигм.
- Оптимизированный. Есть постоянно действующая процедура поиска и освоения новых и улучшенных методов и инструментов.
Использование модели на практике выявило неоднозначность в подходах к достижению более высоких уровней организации процессов разработки ПО. Поэтому к 2002 году разрабатываются рекомендации по улучшению процесса разработки, которые получают название CMMI (Capability Maturity Model Integration). На текущий момент последняя версия CMMi — 1.3 (опубликована в ноябре 2010).
В 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, используемый в обозначении модели, обозначает следующие категории требований к качеству ПО:
- Functionality (Функциональность) /особенности, возможности, безопасность/;
- Usability (Практичность) /человеческий фактор, эргономичность, пользовательская документация/;
- Reliability (Надежность) /частота отказов, восстановление информации, прогнозируемость/;
- Performance (Производительность) /время отклика, пропускная способность, точность, доступность, использование ресурсов/;
- Supportability (Эксплуатационная пригодность)/тестируемость, расширяемость, адаптируемость, сопровождаемость, совместимость, конфигурируемость, обслуживаемость, требования к установке, локализуемость/.
- Символ «+» дополняет FURPS следующими атрибутами: ограничения проекта (ограничения по ресурсам, требования к языкам и средствам разработки, требования к аппаратному обеспечению); интерфейс (ограничения, накладываемые на взаимодействие с внешними системами); требования к выполнению;физические требования; требования к лицензированию.
Модель качества FURPS, предложенная Р. Грейди и Hewlett Packard, построена схожим образом с моделями МакКола и Боэма, но в отличие от них состоит из двух слоев: первый определяет характеристики, а второй связанные с ними атрибуты. Основной концепцией, лежащей в основе FURPS, является декомпозиция характеристик программного обеспечения на две категории требований, а именно, функциональные (F) и нефункциональные (URPS) требования. Эти выделенные категории могут быть использованы как в качестве требований к программному продукту, так и в оценке его качества.
Карло Гецци и его соавторы различают качество продукта и процесса. Согласно модели Гецци, к качеству программного обеспечения относят следующие характеристики программного обеспечения: целостность; надежность и устойчивость; производительность; практичность; верифицируемость; сопровождаемость; возможность многократного использования; мобильность; понятность; возможность взаимодействия; эффективность; своевременность реагирования; видимость процесса разработки.
В Центре обеспечения качества программного обеспечения NASA (Software Assurance Technology Center, SATC) была разработана программа метрик, обеспечивающая оценку рисков проекта, качества продукции и эффективности процессов. Программа SATC рекомендует отдельно отслеживать качество требований, качество программного обеспечения и других продуктов (документации), качество тестирования и качество выполнения процессов. Модель качества SATC определяет набор целей, связанных с программным продуктом и атрибуты процессов в соответствии со структурой модели качества программного обеспечения ISO 9126-1.
Качество программного обеспечения определяется в стандарте ISO 9126-1 как всякая совокупность его характеристик, относящихся к возможности удовлетворять высказанные или подразумеваемые потребности всех заинтересованных лиц. Модель качества ISO 9126-1 различает понятия внутреннего качества, связанного с характеристиками ПО самого по себе, без учета его поведения; внешнего качества, характеризующего ПО с точки зрения его поведения; и качества ПО при использовании в различных контекстах – того качества, которое ощущается пользователями при конкретных сценариях работы ПО. Для всех этих аспектов качества введены метрики, позволяющие оценить их. Кроме того, для создания надежного ПО существенно качество технологических процессов его разработки. Взаимоотношения между этими аспектами качества по схеме, принятой ISO/IEC 9126 показано на рисунке 3. На рисунке 4 представлены факторы и атрибуты внешнего и внутреннего качества программного обеспечения в соответствии с ISO/IEC 9126. На рисунке 37 приведена модель оценивания согласно ISO/IEC 9126.