Модели качества программного обеспечения и методы его оценивания Содержание
 Скачать 2.43 Mb.
|
|
Доктор технических наук, профессор Соколов Б.В. Модели качества программного обеспечения и методы его оценивания СодержаниеОсновные понятия и определения. Модели качества программного обеспечения Программный код и его метрики Методы оценивания качества программного обеспечения Основные понятия и определения Основные понятия и определения Качество – совокупность характеристик объекта, определяющих его способности удовлетворять установленным или предполагаемым потребностям (Международный стандарт ISO-8402). Качествоведение – отрасль знаний, в которой изучаются закономерности получения и обработки информации о качестве объекта на всех этапах его жизненного цикла. Квалиметрия – раздел качествоведения, в котором разрабатываются методологические и методические основы количественного оценивания качества продукции, средства обеспечения единства форм оценивания указанного качества и достижение требуемой точности Основные понятия и определения Выбор ( построение) математической модели Разработка вычислительного алгоритма Построение машинной модели (программирование) Анализ результатов Проведение вычислений на ЭВМ Качество модели – совокупность свойств модели, обуславливающих ее пригодность для использования по назначению. Возможные предназначения модели – имитация функционирования объекта-оригинала в целях более глубокого познания его свойств, оптимизации его характеристик, прогнозирования его поведения, принятие управленческих решений Основные понятия и определения Прямые задачи – анализ качества продукции Обратные задачи – синтез продукции с заданными (требуемыми) свойствами, управление качеством продукции с целью придания ей необходимых свойств. В квалиметрии моделей главную роль играют обратные задачи, т.к. модели являются основным предметом разработки. Основные понятия и определения.Качество системы определяемая степенью удовлетворения системой заявленных и подразумеваемых потребностей различных заинтересованных сторон, которая позволяет, таким образом, оценить достоинства. Эти заявленные и подразумеваемые потребности представлены в международных стандартах серии SQuaRE (Требования и оценка качества систем и программного обеспечения) посредством моделей качества, которые представляют качество продукта в виде разбивки на классы характеристик, которые в отдельных случаях далее разделяются на подхарактеристики. (Некоторые подхарактеристики разделяются далее на под-подхарактеристики.) Подобная иерархическая декомпозиция обеспечивает удобную разбивку качества продукта на классы. Однако множество подхарактеристик, связанных с характеристикой, избранной для представления типичных проблем, необязательно будет исчерпывающим. Измеримые, связанные с качеством свойства системы называют свойствами качества, связанными с соответствующими показателями качества. Чтобы прийти к показателям характеристики или подхарактеристики качества в случаях, когда характеристика или подхарактеристика не может быть непосредственно измерена, необходимо идентифицировать подмножество свойств, которое в совокупности покрывает характеристику или подхарактеристику, получить показатели качества для каждого свойства и, объединив их в вычислительном отношении, достигнуть полученного показателя качества, соответствующего характеристике или подхарактеристике качества. Модель качества продуктаМодель качества при использованииЦели моделей качестваЦелью модели качества продукта является компьютерная система, в которую входит целевой программный продукт, а цель модели качества при использовании - это совокупная человеко-машинная система, которая включает в себя и целевую компьютерную систему, и целевой программный продукт. В целевую компьютерную систему входят также компьютерное оборудование, нецелевые программные продукты, нецелевые данные и целевые данные, которые, в свою очередь, являются объектом анализа модели качества данных. Целевая компьютерная система является частью информационной системы, в состав которой могут быть также включены одна или более компьютерных систем и системы связи, такие как локальная сеть и Интернет. В состав информационной системы в более крупной человеко-машинной системе (такой как корпоративная система, встроенная система или крупномасштабная система управления) могут входить пользователи, техническая и физическая среда использования. Рамки целевой системы определяются исходя из области применения требований или оценки и из того, кто рассматривается в качестве пользователей. Пример - Если в качестве пользователей самолета с компьютерной системой управления полетом рассматривать пассажиров, то система, от которой они зависят, включает летный экипаж, сам самолет, аппаратное и программное обеспечение системы управления полетом. В случае, если в качестве пользователей рассматривать летный экипаж, то система, от которой они зависят, состоит только из самого самолета и системы управления полетом. Цели моделей качестваМодели качества программного обеспечения Руководящие документыГОСТ Р ИСО/МЭК 25010-2015 Информационные технологии (ИТ). Системная и программная инженерия. Требования и оценка качества систем и программного обеспечения (SQuaRE). Модели качества систем и программных продуктов ГОСТ Р ИСО/МЭК 25010-2015 НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ Информационные технологии СИСТЕМНАЯ И ПРОГРАММНАЯ ИНЖЕНЕРИЯ Требования и оценка качества систем и программного обеспечения (SQuaRE). Модели качества систем и программных продуктов Information technology. Systems and software engineering. Systems and software Quality Requirements and Evaluation (SQuaRE). System and software quality models Свойства качества - это неотъемлемые свойства программного обеспечения, которые обеспечивают качество. Свойства качества могут быть разделены на одну или несколько подхарактеристик. Измеряются свойства качества посредством метода измерения. Метод измерения представляет собой логическую последовательность операций, используемых для количественного определения свойств относительно конкретной шкалы. Результат применения метода измерения называют элементом показателя качества (ЭПК). Характеристики и подхарактеристики качества могут быть количественно определены с помощью функции измерения. Функция измерения - это алгоритм, используемый для объединения элементов показателя качества. Результат применения функции измерения называют показателем качества программного обеспечения. Таким образом показатели качества программного обеспечения становятся количественными показателями характеристик и подхарактеристик качества. Для измерения характеристики или подхарактеристики качества могут быть использованы несколько показателей качества программного обеспечения. Эталонная модель измерения качества программного продуктаКачество в жизненном циклеЦелевые объекты модели качества и их взаимосвязьМодель жизненного цикла качества системы/программного обеспеченияМодель качества программного обеспечения МакКолаМодель качества программного продукта БоэмаМодель качества программного обеспечения FURPS/FURPS+Модель FURPS предложена Грейди и Hewlett Packard. Акроним FURPS, используемый в обозначении модели, обозначает следующие категории требований к качеству ПО: Functionality (Функциональность) /особенности, возможности, безопасность/; Usability (Практичность) /человеческий фактор, эргономичность, пользовательская документация/; Reliability (Надежность) /частота отказов, восстановление информации, прогнозируемость/; Performance (Производительность) /время отклика, пропускная способность, точность, доступность, использование ресурсов/; Supportability (Эксплуатационная пригодность) /тестируемость, расширяемость, адаптируемость, сопровождаемость, совместимость, конфигурируемость, обслуживаемость, требования к установке, локализуемость/. Символ «+» расширяет FURPS модель, добавляя к ней:
интерфейс (ограничения накладываемые на взаимодействие с внешними системами); требования к выполнению, физические требования, требования к лицензированию. Модель качества программного обеспечения ГецциКарло Гецци и соавторы различают качество продукта и процесса. Характеристики ПО Гецци: целостность, надежность и устойчивость, производительность, практичность, верифицируемость, сопровождаемость, возможность многократного использования, мобильность, понятность, возможность взаимодействия, эффективность, своевременность реагирования, видимость процесса разработки Некоторые другие модели качества программного обеспеченияМодель качества Дроми Модель качества SATC Модель качества ISO 9126 Модель качества QMOOD Модель качества Хосрави Модель качества Шармоа Основные аспекты качества программного обеспеченияСравнительный анализ моделей качества программного обеспеченияПрограммный код и его метрики Одной из тем в программировании, к которым интерес периодически то появляется, то пропадает, является вопрос метрик кода программного обеспечения. В крупных программных средах время от времени появляются механизмы подсчета различных метрик. Волнообразный интерес к теме так выглядит потому, что до сих пор в метриках не придумано главного — что с ними делать. То есть даже если какой-то инструмент позволяет хорошо подсчитать некоторые метрики, то что с этим делать дальше зачастую непонятно. Конечно, метрики — это и контроль качества кода (не пишем большие и сложные функции), и «производительность» (в кавычках) программистов, и скорость развития проекта. Количественные метрики Прежде всего, следует рассмотреть количественные характеристики исходного кода программ (в виду их простоты). Самой элементарной метрикой является количество строк кода (SLOC). Данная метрика была изначально разработана для оценки трудозатрат по проекту. Однако из-за того, что одна и та же функциональность может быть разбита на несколько строк или записана в одну строку, метрика стала практически неприменимой с появлением языков, в которых в одну строку может быть записано больше одной команды. Поэтому различают логические и физические строки кода. Логические строки кода — это количество команд программы. Данный вариант описания так же имеет свои недостатки, так как сильно зависит от используемого языка программирования и стиля программирования. Кроме SLOC к количественным характеристикам относят также: количество пустых строк, количество комментариев, процент комментариев (отношение числа строк, содержащих комментарии к общему количеству строк, выраженное в процентах), среднее число строк для функций (классов, файлов), среднее число строк, содержащих исходный код для функций (классов, файлов), среднее число строк для модулей. Метрики Холстеда. Данные метрики основаны на следующих показателях: n1 — число уникальных операторов программы, включая символы- разделители, имена процедур и знаки операций (словарь операторов), n2 — число уникальных операндов программы (словарь операндов), N1 — общее число операторов в программе, N2 — общее число операндов в программе, n1' — теоретическое число уникальных операторов, n2' — теоретическое число уникальных операндов. Учитывая введенные обозначения, можно определить: n=n1+n2 — словарь программы, N=N1+N2 — длина программы, n'=n1'+n2' — теоретический словарь программы, N'= n1*log2(n1) + n2*log2(n2) — теоретическая длина программы (для стилистически корректных программ отклонение N от N' не превышает 10%) V=N*log2n — объем программы, V'=N'*log2n' — теоретический объем программы, где n* — теоретический словарь программы. L=V'/V — уровень качества программирования, для идеальной программы L=1 L'= (2 n2)/ (n1*N2) — уровень качества программирования, основанный лишь на параметрах реальной программы без учета теоретических параметров, EC=V/(L')2 — сложность понимания программы, D=1/ L' — трудоемкость кодирования программы, y' = V/ D2 — уровень языка выражения I=V/D — информационное содержание программы, данная характеристика позволяет определить умственные затраты на создание программы E=N' * log2(n/L) — оценка необходимых интеллектуальных усилий при разработке программы, характеризующая число требуемых элементарных решений при написании программы При применении метрик Холстеда частично компенсируются недостатки, связанные с возможностью записи одной и той же функциональности разным количеством строк и операторов. Еще одним типом метрик ПО, относящихся к количественным, являются метрики Джилба. Они показывают сложность программного обеспечения на основе насыщенности программы условными операторами или операторами цикла. Данная метрика, не смотря на свою простоту, довольно хорошо отражает сложность написания и понимания программы, а при добавлении такого показателя, как максимальный уровень вложенности условных и циклических операторов, эффективность данной метрики значительно возрастает. Метрики сложности потока управления программы Метрики сложности потока управления данными Метрики сложности потока управления и данных программы Объектно-ориентированные метрики Гибридные метрики Вывод: в настоящее время ни одной универсальной метрики не существует. Любые контролируемые метрические характеристики программы должны контролироваться либо в зависимости друг от друга, либо в зависимости от конкретной задачи, кроме того, можно применять гибридные меры, однако они так же зависят от более простых метрик и также не могут быть универсальными. Строго говоря, любая метрика — это лишь показатель, который сильно зависит от языка и стиля программирования, поэтому ни одну меру нельзя возводить в абсолют и принимать какие-либо решения, основываясь только на ней. Общие показатели качества программных средств
Частные показатели качества программных средств
Частные показатели качества программных средств
Продолжение Методы оценивания качества программного обеспечения Реальные задачи выбора, возникающие на практике, чрезвычайно разнообразны, но всех их объединяет общая схема поиска решения, суть которой состоит в формировании совокупности операций (процедур), проводимых на множестве допустимых альтернатив, в результате чего выделяется множество наилучших (оптимальных) альтернатив. Для поиска указанных альтернатив в задачах выбора необходимо задать соответствующие критерии (греч. Kriterion ‑ мерило для оценки), под которыми в дальнейшем понимаются и правила (признаки), позволяющие сопоставлять и сравнивать допустимые альтернативы друг с другом для выбора наилучшей из них. При этом оценивание альтернатив в сложных инженерно-технических задачах, как правило, осуществляется с использованием нескольких критериальных функций. Данные функции в научно-технической литературе часто называют еще целевыми функциями, показателями качества, показателями эффективности. Можно указать на 4 основных вида задач выбора, при решении которых необходимо использовать многокритериальный подход. Перечислим указанные виды задач многокритериального выбора: Характерные особенности задач многокритериального выбора 1-й вид задач, в которых окончательное решение, определяет порядок совместных действий нескольких объектов, эффективность функционирования каждого из которых оценивается отдельными критериальными функциями (например, совместная деятельность СТС при выполнении общей задачи); 2-й вид задач, в которых качество принимаемого решения необходимо оценивать для нескольких вариантов условий воздействия среды на СТС и для каждого варианта вводится отдельная оценка; 3-й вид задач, в которых принятие решения осуществляется поэтапно с использованием на каждом этапе своих критериальных функций (например, оценка эффективности жизненного цикла СТС); 4-й вид задач, в которых качество решения необходимо оценивать с нескольких точек зрения ‑ по отдельным компонентам качества. Например, оценка качества выполнения плана работы системы обслуживания активных подвижных объектов (АПО) может характеризоваться временем окончания всех операций взаимодействия на интервале планирования, количеством израсходованных ресурсов системы обслуживания (СО), объемом выполненных операций. Анализ показывает, что большинство задач выбора, возникающих на практике, принадлежит к одному из перечисленных выше видов задач или является их комбинацией. Таким образом, при создании, исследовании, применении и развитии сложных технических, экономических, организационных, военно-технических систем оценивание качества соответствующих процессов становится возможным только при использовании нескольких показателей (нескольких целевых, критериальных функций). Это приводит, в свою очередь, к появлению в задачах выбора критериальной неопределенности. Рассмотрим пример, иллюстрирующий причины появления указанной критериальной неопределенности при решении задач выбора на практике. Следует подчеркнуть, что подобного рода примеров можно привести очень много (далее в данной и последующих главах будут приводиться еще ряд примеров постановки задач многокритериального выбора). Даже в обыденной жизни каждый человек при определении места работы или отпуска испытывает затруднения, связанные с наличием нескольких противоречивых критериев, на основании которых нужно принять окончательное решение. Одна из главных особенностей задач многокритериального выбора состоит в том, что данные задачи не являются корректными в рамках аксиоматики, принятой в классической теории оптимизации и принятия решения. В самом деле, если взять условия примера 4.1, то формальная постановка задачи многокритериального выбора сводится к следующему. Пусть вектор характеризует основные параметры проектируемого самолета, возможные значения которых задаются множеством допустимых альтернатив . Качество проектирования самолета оценивается m-скалярными критериальными функциями , содержательная интерпретация которых приводилась выше (см. условия примера 4.1). Образуем из данных функций вектор . 4.1.1. Характерные особенности задач многокритериального выбораВ указанных условиях задача многокритериального выбора сводится к поиску такого вектора , при котором (4.1) или по-другому (4.2) Условие существования решения (4.1) или (4.2) может быть записано как условие совпадения решения m-частных задач поиска экстремума по каждому j-му показателю качества на множестве S: (4.3) где Выполнение условия (4.3) возможно лишь в случае непротиворечивости частных показателей качества проектирования самолета. Однако, как показывает содержательный анализ примера 4.1, указанные показатели являются сугубо противоречивыми и оптимизация параметров проектирования самолета по каждому из них приводит к альтернативным (несовпадающим) решениям. Таким образом, постановка задачи (4.1) является не корректной в рамках аксиоматики классической теории экстремальных задач. Некорректность задач многокритериального выбора обуславливает необходимость использования для ее решения соответствующих этапу классу задач методов. Известно, что основу таких методов составляет регуляризация-доопределение (уточнение) задачи путем привлечения дополнительной качественной и количественной информации о свойствах критериальных функций, об альтернативах, о принципах оптимальности и т.п. В рассматриваемом примере на основе дополнительной информации должен быть доопределен принцип оптимальности и методы его реализующие таким образом, чтобы в регуляризованной задаче выполнялись все условия корректности. Вторая особенность задач многокритериального выбора состоит в том, что основным источником дополнительной информации при поиске наилучших альтернатив являются эксперты (Э), хорошо знающие заданную предметную область, и лицо, принимающее решение, преследующее определенную цель (цели), в интересах достижения которой и решается рассматриваемая задача. ЛПР, как и эксперты, должно быть компетентным специалистом в соответствующей предметной области, обладать опытом деятельности в ней, а также должно быть наделено необходимыми полномочиями. Следует отметить, что в ряде случаев дополнительная информация в задачах многокритериального выбора может быть получена и от других источников (например, на основе анализа результатов системного моделирования). Третья особенность задач многокритериального выбора заключается в том, что в данных задачах множество допустимых альтернатив и множество частных отношений предпочтений может задаваться как непосредственно, так и с использованием соответствующих функций, функционалов, операторов и т.п. Возможен комбинированный (смешанный) вариант задания множества допустимых альтернатив и отношений предпочтения. Отметим, что очень часто критериальные функции имеют различные масштабы измерения и их сравнение становится трудным, а в ряде ситуаций даже невозможным. Поэтому данные критериальные функции необходимо приводить к единому масштабу измерения или, другими словами, нормализовать их. Таким образом, основные особенности и соответствующие проблемы, связанные с решением задач многокритериальной оптимизации, имеют скорее не вычислительный, а концептуальный характер, т.к. невозможно строго математически доказать, что выбранная в конкретных условиях ЛПР альтернатива из числа недоминируемых (неулучшаемых одновременно по всем показателям) является наилучшей. В другой ситуации ЛПР может выбрать другую недоминируемую альтернативу. Указанное положение можно считать основной аксиомой в задачах принятия многокритериальных решений. Для корректного решения на практике перечисленных выше проблем необходимо уметь строить математические модели многокритериальной оптимизации и обоснованно применять для поиска «наилучших» альтернатив соответствующие методы и алгоритмы оптимального выбора. Первым шагом в процессе построения указанных математических моделей является их обобщенное теоретико-множественное описание. Обобщенная структура выбора с мультипредпочтением, описывающая задачи векторной оптимизации, имеет следующий вид: где s — множество допустимых альтернатив; — множество исходных отношений предпочтения; — множество правил согласований отношений предпочтения. В задачах векторной оптимизации исходные (входные) отношения предпочтения задаются посредством функций (функционалов) , отображающих Hi множество альтернатив на подмножество действительной оси и дающих каждой альтернативе кардинальную (количественную) оценку. Подмножество Hi(iГ) называется шкалой оценок по критериальной функции fi. В дальнейшем в данной главе ограничения общности будем предполагать, что каждую критериальную функцию fi необходимо максимизировать (т.е. большие значения критериальных функций предпочтительнее меньших), а предпочтения ЛПР не меняются скачком. Кроме того, для удобства в дальнейшем вектор будем обозначать просто символом x. Если множество Г состоит из «m»‑элементов (Г={1,2,…,m}), то функции образуют «m»‑мерный вектор , сопоставляющий, каждой «точке» принадлежащей пространству (области) допустимых альтернатив xs соответствующую «точку» в m‑мерном пространстве целевых (критериальных) функций . Уточненное описание структуры выбора с многими отношениями предпочтения. Общая постановка задач векторной оптимизацииНа рис.4.1 для случая m=n=2 приведена используемая обычно для пояснения сущности проблем многокритериального выбора геометрическая интерпретация пространства допустимых альтернатив s и пространства целевых (критериальных) функции . Конечной целью исследования задач векторной оптимизации обычно является отыскание некоторой наилучшей (оптимальной, эффективной) альтернативы, принадлежащей множеству допустимых альтернатив s. При этом в настоящее время известно большое разнообразие вариантов задания множества s, каждый из которых соответствует конкретной модели, относящейся, например, к классу математических, логико-лингвистических либо логико-алгебраических моделей. Рис. 4.1. Частные показатели качества программных средств Липаев В.В. Надежность программных средств. М.:Синтег, 1998. Липаев В.В. Оценка качества программных изделий. М.:Эрис, 2001. Липаев В.В. Обеспечение качества программных средств. Методы и стандарты. М.:Синтег, 2001. Липаев В.В. Качество программных средств. М.:Янус, 2002. Международный стандарт ISO 9126:1991 «Информационная технология. Оценка программного продукта. Характеристики качества и руководство по их применению». Пальчун Б.П., Юсупов Р.М. Оценка надежности программного обеспечения. СПб.:Наука, 1991. Баранов С.Н., Домарацкий А.Н., Ласточкин Н.К., Морозов В.П. Процесс разработки программных изделий. М.:Наука, 2000. Список основной рекомендуемой литературы
Список дополнительной рекомендуемой литературы
Список дополнительной рекомендуемой литературы
Acknowledgement The research described in this paper is partially supported by International project ERASMUS +, Capacity building in higher education, № 73751-EPP-1-2016-1-DE-EPPKA2-CBHE-JP, Innovative teaching and learning strategies in open modelling and simulation environment for student-centered engineering education. Контактная информация18. Conclusion Соколов Борис Владимирович: Phone: +7 812 328-23-76; Fax: +7 812 328-44-50; E-mail: sokol@iias.spb.su; Web: http://www.spiiras-grom.ru СПАСИБО ЗА ВНИМАНИЕ |