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

Содержание

Решение задач на ЭВМ включает в себя следующие основные этапы, часть из которых осуществляется без участия ЭВМ.

Постановка задачи:

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

Анализ и исследование задачи, модели:

анализ существующих аналогов;
анализ технических и программных средств;
разработка математической модели;
разработка структур данных.

Разработка алгоритма:

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

Программирование:

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

Тестирование и отладка:

Критерии качества релиза

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

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

«белого» или «прозрачного ящика» (тестирование маршрутов);
«черного ящика»

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

Анализ результатов решения задачи и уточнение в случае необходимости математической модели с повторным выполнением этапов 2-5.

Сопровождение программы:

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

Критерии качества программы

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

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

Критериями качества ПП являются:

Функциональность
Соответствие назначению
Точность
Способность взаимодействовать со средой
Соответствие нормам
Безопасность (защита от взлома данных и других преступных посягательств)
Надежность
Зрелость («обкатанность»)
Отказоустойчивость
Способность восстанавливаться после сбоев
Пригодность к использованию
Понимаемость
Изучаемость
Удобство и простота в работе
Эффективность
Быстродействие и время отклика
Потребление ресурсов
Сопровождаемость
Анализируемость (диагностика причин ошибок и сопоставление с исходным кодом)
Пригодность к изменениям
Стабильность
Тестируемость
Переносимость
Адаптируемость
Легкость инсталляции
Мобильность
Соответствие нормам по переносимости и инсталляции
Заменяемость (способность заменить аналоги?)

Функциональность – это способность ПП выполнять набор функций, определенных его внешними спецификациями.

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

Диалоговые программы

Основным методом общения пользователя с современными программами является диалог.

Имеются два вида программ: не диалоговые программы (выполняются без дополнительного обращения к пользователю) и диалоговые (интерактивные).

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

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

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

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

С точки зрения программного обеспечения в состав интерфейса пользователь-компьютер входят два компонента:

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

Жизненный цикл программы

Жизненный цикл и этапы разработки программного обеспечения.

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

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

Постановка задачи

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

Анализ требований и определение спецификаций

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

1. Критерии качества программного средства. Определение качества ПО в стандарте ISO 9126. Многоуровневая модель качества ПО. Оце

Критерии качества программного средства. Определение качества ПО в стандарте ISO 9126. Многоуровневая модель качества ПО. Оценочные характеристики качества программного продукта

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

Основными критериями качества ПО (criteria of software quality) являются:

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

Оценочные характеристики качества:

Оценочные характеристики качества предположительно из раздела «оценки , метрики и меры» этой лекции

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

Размерно-ориентированные метрики

Размерно-ориентированные метрики Основаны на LOC-оценках, т.е. на количестве строк в текстах программ ( ). К числу размерно-ориентированных метрик относятся:

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

Метрики производительности и качества

Метрики производительности и качества рассчитываются в виде следующих отношений:

Производительность = [число строк кода(LOC)] /[Затраты]

где затраты измеряются в человеко-месяцах (работа одного человека в течении месяца)
Качество =

Качество = [число ошибок] / [число строк кода(LOC)]

Метрики стоимости и документированности

Удельная Стоимость = [Стоимость в тыс. рублей] / [число строк кода(LOC)] _________ Документированность = [число страниц документации] / [число строк кода(LOC)]

Достоинства и недостатки Размерно-ориентированные метрик

Достоинства:

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

Недостатки:

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

Функционально-ориентированные метрики (FP-оценки)

Исходят не из размера программного продукта, а из его функциональности.
Оценивают:

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

Вместо количества строк в текстах используется количество функциональных указателей (Function Points)
следующая формула взята из слайдов лекций=

FP=UI*(0.65+0.01*E[F(i)])

UI — оценка сложности пользовательского интерфейса,
F(i) («эф итое») – коэффициенты регулировки сложности, основанные на эмпирической оценке ряда системных параметров и принимающие целые значения в диапазоне от 0 до 5.
E[F(i) — сумма всех коэффициентов по i параметру.

FP-оценки
К числу параметров, учитываемых коэффициентами регулирования сложности относятся:

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

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

метода функциональных указателей ((Function Points) – коммерческие информационные системы

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

Функционально-ориентированные метрики

Функционально-ориентированные метрики аналогичны соответствующим размерно-ориентированным метрикам с точностью до замены =

параметра длины на количество функциональных указателей
или указатель свойств в зависимости от выбранного метода FP-оценки

Достоинства и недостатки Функционально-ориентированных метрик

Достоинства:

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

Недостатки:

используют не прямые, а косвенные измерения
основаны на субъективных оценках

Key Words for FKN + antitotal forum (CS VSU):

программирование
ошибки
неофициальный форум фкн
фкн
вгу воронеж
фкн + вгу + antitoal

Источник: fkn.ktu10.com

Критерии качества на ранней стадии развития ПО

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

Написать нам

Над материалом работали

Мохамад Кассаб

PhD in Computer Science, доцент университета Пенстэйт в Пенсильвании, доцент Университета Иннополис

127 публикаций
Партнёр проекта

Университет Иннополис