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

Качество — совокупность характеристик объекта, относящихся к его способности удовлетворять установленные и предполагаемые потребности (ISO 9000).

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

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

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

1) Категорийные — описательные, отражающие набор свойств и общие характеристики объекта — его функции, категории ответственности, защищенности и важности, которые могут быть представлены номинальной шкалой категорий свойств.

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

Критерии оценки персонала. По каким критериям оценивать сотрудников?

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

Функциональные критерии отражают основную специфику применения и степень соответствия программ их целевому назначению.

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

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

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

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

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

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

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

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

Критерии качества на ранних стадиях разработки ПО — Мохамад Кассаб

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

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

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

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

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

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

− Структурированность. ПС имеет структуру, позволяющую легко вносить требуемые изменения.

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

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

− Осмысленность. Документация ПС не содержит избыточной информации.

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

− Оцениваемость. Приемлемость ПС для конкретного применения и обеспечивает возможность оценки качества функционирования ПС.

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

− Точность. Выдаваемые ПС результаты имеют точность, достаточную с точки зрения основного их назначения.

− Доступность. ПС допускает селективное использование отдельных его компонент.

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

− Расширяемость. ПС позволяет увеличивать при необходимости объем памяти для хранения данных или расширять вычислительные функции отдельных модулей.

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

− Модифицируемость. ПС имеет структуру, позволяющую легко вносить требуемые изменения.

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

33. Надёжность программных средств и её оценка. Модели надёжности

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

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

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

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

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

Средняя наработка до отказа — математическое ожидание времени работы ПС до очередного отказа.

Среднее время восстановления — математическое ожидание времени отказа.

Коэффициент готовности — вероятность того, что ПС окажется в работоспособном состоянии в произвольный момент времени его использования по назначению.

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

Модели надежности ПС:

1. Аналитические. Дают возможность рассчитать количественные показатели надежности, основываясь на данных о поведении программы в процессе тестирования (измеряющие и оценивающие модели).

1.1. Динамические. Поведение отказов зависит от времени.

1.1.1. Дискретные. Фиксируется число отказов за некоторое время и поведение программы представлено в дискретных точках.

− Модель Шумана

− Модифицированная модель Шумана

− Модель La Padula

− Модель Шика — Волвертона

1.1.2. Непрерывные. Фиксируются интервалы каждого отказа, т.е. получается непрерывная картина появления отказов по времени.

− Модель Джелинского-Моранды

− Модель Мусса

− Модель преходных вероятностей

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

1.2.1. По области ошибок. Учитывается связь количества ошибок и числа тестовых прогонов.

− Модель Миллса. Предполагает необходимость перед началом тестирования искусственно вносить в программу (засорять) некоторое количество известных ошибок. Собирается статистика об ошибках.

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

− Простая интуитивная модель

− Модель Коркорэна

1.2.2. По области данных. Учитывается связь количества ошибок с характеристиками входных данных ПС.

− Модель Нельсона

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

2.1. Модель сложности. Базируется на свойствах внутренней и внешней связанности модулей. Определяет вероятность того, что модуль i будет изменяться, если модуль j изменяется.

2.2. Модель, определяющая время доводки программы. Базируется на свойствах внутренней и внешней связанности модулей. Определяет вероятность того, что модуль i будет изменяться, если модуль j изменяется

Источник: studopedia.su

3. Качество по

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

Характеристиками программ не требующими комментариев являются:

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

• объем дисковой памяти;
• версия операционной системы;
• наличие вычислительной сети и др.

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

3.1 Критерии оценки качества по

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

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

1. длительность проектирования
2. продолжительность эксплуатации очередной версии
3. длительность проведения каждой модификации

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

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

Источник: studfile.net

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

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

В [1] приводится достаточно подробная классификация критериев (факторов) качества программного обеспечения. При этом, анализ различных источников показывает, что данные термины наиболее применимы и поддерживаются большинством.

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

Внешние факторы, которые в том числе описаны в стандарте ИСО 9126:

1. корректность
2. устойчивость
3. расширяемость
4. повторное использование
5. совместимость, эффективность
6. переносимость
7. простота использования
8. функциональность
9. своевременность

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

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

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

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

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

Источник: tstu.ru