Известно, что один и тот же алгоритм может быть реализован на ЭВМ различными способами, т.е. может быть составлено несколько различных программ, решающих одну и ту же задачу.
Таким образом, нужно иметь некоторые критерии оценки программы, с помощью которых можно судить насколько одна программа лучше другой. Анализ и оценка программы носят преимущественно качественный характер.
1. Программа работает и решает поставленную задачу. Понятно, что эта характеристика программы является самой важной.
В связи с этим каждая программа должна быть устроена так, чтобы можно было проверить правильность полученных результатов. Такая проверка проводится в процессе отладки программы, на определенных наборах входных данных, для которых заранее известен ответ. Но отладка может доказать лишь наличие ошибок в программе, но не может доказать правильности программы для всех возможных вычислений, реализуемых с ее помощью. В связи с этим необходима разработка методов аналитической верификации программы.
Качество и его критерии
Для аналитического доказательства правильности программы требуется, чтобы программа легко анализировалась. Это означает, что программа должна быть устроена так, чтобы можно было понять, каким образом с ее помощью получается данный ответ.
2. Минимальное время, затрачиваемое на тестирование и отладку программы. Тестирование и отладка программы – необходимый этап в процессе решения задачи на ЭВМ. Он занимает от трети до половины всего времени разработки программы, поэтому очень важно уменьшить время, затрачиваемое на тестирование и отладку.
Тестирование и отладка программы облегчается, если программа просто анализируется и снабжена необходимыми комментариями, облегчающими ее понимание. Хорошие комментарии могут ускорить процесс отладки.
Понимание и отладка программы облегчается, если она имеет простую и ясную структуру, в частности, если ограничено использование операторов передачи управления (GOTO). Перегруженность программы этими операторами приводит к хаотической структуре и затрудняет отладку.
Еще один важный принцип – использование мнемонических обозначений для переменных. Языки программирования представляют здесь вполне достаточные возможности. Для лучшего понимания программы необходимо использовать мнемонику, отражающую физический (математический, экономический и т.д.) смысл переменной (например, SPEED — скорость).
3. Уменьшение затрат на сопровождение. Разработанная и отлаженная программа предназначена для многократного использования, и ее эксплуатацией, как правило, занимаются не разработчики, а другие программисты, входящие в так называемую группу сопровождения.
Программистам, сопровождающим программу, часто приходится продолжать отладку программы и производить ее модернизацию, в связи с изменением технического задания, введением новых средств программного обеспечения или выявлением новых ошибок и недоработок в программе.
Для уменьшения затрат на сопровождение необходимо, чтобы каждый разработчик учитывал сложность сопровождения. Следует разрабатывать, отлаживать и оформлять программу с учетом того, что ее будут использовать и сопровождать другие программисты.
4. Гибкость программы. Разработанная программа обычно находится в эксплуатации длительное время. За это время могут измениться требования к решаемой задаче, техническое задание, требования к программе. Появляется необходимость внести определенные изменения в программу, что в некоторых случаях бывает трудно сделать, т.к. разработчиком не предусмотрена такая возможность. «Хорошая» программа должна допускать модификацию.
5. Уменьшение затрат на разработку. Программирование является коллективным трудом. Состав группы программистов, работающих над решением данной задачи, может по каким-либо причинам измениться. Поэтому проектирование и разработка программы должны вестись таким образом, чтобы было возможно при необходимости передать ее завершение другому программисту. Несоблюдение этого требования часто приводит к срыву сроков сдачи программ в эксплуатацию.
6. Простота и эффективность. Программа должна быть просто организована. Это может проявляться и в структуре программы, и в использовании простых и наиболее естественных средств языка программирования, и в предпочтении простых структур данных и т.п.
Эффективность программы считается одной из главных ее характеристик. Поэтому часто в ущерб другим качествам программы разработчики прибегают к сложным ухищрениям, чтобы уменьшить объем используемой памяти или сократить время выполнения программы. Во многих случаях затрачиваемые на это усилия не оправдывают себя. Разумный подход к повышению эффективности программы состоит в том, чтобы выявить наиболее «узкие» места и постараться их улучшить.
Раздел №18 (2 часа)
• Общее представление о базах данных
• Основные понятия систем управления базами данных
• Уровни представления данных
• Основные модели данных
• Реляционные базы данных
Источник: cyberpedia.su
Критерии качества программы
Качество программного обеспечения — характеристика программного обеспечения (ПО) как степени его соответствия требованиям. При этом требования могут трактоваться довольно широко, что порождает целый ряд независимых определений понятия. Чаще всего используется определение ISO 9001, согласно которому качество есть «степень соответствия присущих характеристик требованиям».
Качество исходного кода
Качество кода может определяться различными критериями. Некоторые из них имеют значение только с точки зрения человека. Например, то, как отформатирован текст программы, совершенно не важно для компьютера, но может иметь серьёзное значение для последующего сопровождения. Многие из имеющихся стандартов оформления кода, определяющих специфичные для используемого языка соглашения и задающие ряд правил, улучшающих читаемость кода, имеют своей целью облегчить будущее сопровождение ПО, включающее отладку и обновление. Существуют и другие критерии, определяющие, «хорошо» ли написан код, например, такие, как структурированность — степень логического разбиения кода на ряд управляемых блоков.
- Читаемость кода
- Лёгкость поддержки, тестирования, отладки, исправления ошибок, изменения и портируемости
- Низкая сложность кода
- Низкое использование ресурсов: памяти и процессорного времени
- Корректная обработка исключительных ситуаций
- Малое число предупреждений при компиляции и линковке
Методы улучшения качества кода: рефакторинг.
Факторы качества
Фактор качества ПО — это нефункциональное требование к программе, которое обычно не описывается в договоре с заказчиком, но, тем не менее, является желательным требованием, повышающим качество программы.
Некоторые из факторов качества:
понятность
Назначение ПО должно быть понятным, из самой программы и документации.
полнота
Все необходимые части программы должны быть представлены и полностью реализованы.
краткость
Отсутствие лишней, дублирующейся информации. Повторяющиеся части кода должны быть преобразованы в вызов общей процедуры. То же касается и документации.
портируемость
Лёгкость в адаптации программы к другому окружению: другой архитектуре, платформе, операционной системе или её версии.
согласованность
По всей программе и в документации должны использоваться одни и те же соглашения, форматы и обозначения.
сопровождаемость
Насколько сложно изменить программу для удовлетворения новых требований. Это требование также указывает, что программа должна быть хорошо документирована, не слишком запутана, и иметь резерв роста по использованию ресурсов (память, процессор).
тестируемость
Позволяет ли программа выполнить проверку приёмочных характеристик, поддерживается ли возможность измерения производительности.
удобство использования
Простота и удобство использования программы. Это требование относится прежде всего к интерфейсу пользователя.
надёжность
отсутствие отказов и сбоев в работе программ, а также простота исправления дефектов и ошибок:
структурированность
эффективность
Насколько рационально программа относится к ресурсам (память, процессор) при выполнении своих задач.
безопасность
С точки зрения пользователя
Помимо технического взгляда на качество ПО, существует и оценка качества с позиции пользователя. Для этого аспекта качества иногда используют термин «юзабилити». Довольно сложно получить оценку юзабилити для заданного программного продукта. Наиболее важные из вопросов, влияющий на оценку:
- Является ли пользовательский интерфейс интуитивно понятным?
- Насколько просто выполнять простые, частые операции?
- Насколько легко выполняются сложные операции?
- Выдаёт ли программа понятные сообщения об ошибках?
- Всегда ли программа ведёт себя так как ожидается?
- Имеется ли документация и насколько она полна?
- Является ли интерфейс пользователя само-описательным/само-документирующим?
- Всегда ли задержки с ответом программы являются приемлемыми?
Источник: cyberfac.ru
Показатели и критерии качества программ
Должна ли программа быть хорошей? Вопрос может показаться банальным. Однако очень важно его задать, поскольку любое усилие по улучшению методов программирования должно быть основано на осознании того, что программу можно обсуждать, критиковать, улучшать и сравнивать с другими программами, что она может быть хорошей или плохой и что важно сделать ее “хорошей” относительно некоторых критериев.
Важность установления критериев качества программ и проверки этих критериев подтверждается практическим опытом и обилием сообщений в средствах массовой информации о тех или иных происшествиях, связанных с неправильным выполнением ЭВМ возложенных на нее задач. Ниже приводятся примеры различных типов ошибок, которые могут возникать при эксплуатации программ.
Качество программ — это определенная совокупность свойств программного продукта, обеспечивающих решение возложенных на него задач в заданной среде функционирования и с допустимым множеством исходных данных.
Показателями качества являются надежность (безошибочность, включая и экстремальные, нестандартные условия выполнения), модифицируемость (легкость доработки и разбиения на модули), мобильность (настройка на новые условия, перенос на другую ЭВМ с минимальными затратами), дружественность интерфейса между ЭВМ и пользователем, занимаемый объем памяти, качество документации, подробность документирования самой программы.
Надежность программы является наиболее важным критерием качества программы в целом.
Модифицируемость программы — функциональное разбиение программы на автономные модули (модульное программирование), возможность доработки (изменения) содержания модулей.
Переносимость — легкость адаптации к изменению среды, т.е. компонентов программирования, возможность переноса программы из одной операционной системы в другую.
Занимаемая память — объем ОЗУ (кбайт, Мбайт) и объем ВЗУ, необходимых для функционирования программы.
Надежность программы определяется надежностью ее составляющих:
— алгоритмическая (вычислительная) надежность:
— надежность программного обеспечения;
Рассмотрим кратко отдельные составляющие надежности программ.
Алгоритмическая (вычислительная) надежность — способность программы выполнять свои функции при изменении условий функционирования.
Информационная надежность предусматривает:
— способность алгоритма или программы правильно выполнять свои функции при различных ошибках в исходных данных;
— способность информационной системы обеспечивать целостность хранящихся в ней данных;
— способность алгоритма и программы нормально функционировать в случае неправильных действий пользователя при вводе информации.
Надежность программного обеспечения — это характеристика способности программного обеспечения выполнять возложенные на него функции при поступлении требований на их выполнение, показатель качества, характеризующий свойства программного изделия выдавать одни и те же результаты при различных условиях функционирования.
При рассмотрении вопроса надежности программ следует учитывать тот факт, что надежность и правильность программ — не одно и то же. Правильность программы — это отсутствие в программе, разработанной по заданному алгоритму, программных ошибок. Надежность программы — более широкое понятие.
Надежность — это способность программ давать разумные результаты при всех возможных данных и действиях, в частности, в аномальных условиях. Если в программу вводят необычные данные, они должны быть выявлены и отброшены. Должны выявляться ошибки программы, ошибки данных, к которым следует добавить проблему предельных случаев и возможные ошибки аппаратуры.
Рассмотрение всех составляющих качества программ является очень сложной и объемной задачей. Поэтому мы ограничимся только теми показателями качества программ, которые зависят от разработчика (программиста).
Приведем примеры различных типов ошибок, встречающихся в программах.
Тип 1. Ошибки, допущенные при разработке и не обнаруженные при проверке (тестировании).
Неудача при запуске первого американского спутника к Венере произошла, вероятнее всего, из-за ошибки в программе — вместо требуемой в операторе цикла (Фортран) запятой программист поставил точку. Вот как был записан этот оператор:
На самом же деле он должен был выглядеть следующим образом:
Значительное количество программных ошибок в новой операционной системе WINDOWS-95 снижает ее надежность, поэтому корпоративные пользователи не спешат с ее внедрением. В начальный период каждый месяц эксплуатации WINDOWS-95 выявлял новые ошибки.
Тип 2. Ошибки, возникающие при вводе в компьютер неверных данных. В 70-х годах произошел глобальный сбой энергосистемы, снабжающей электроэнергией северо-восточную часть США, из-за неправильной установки начальных условий в компьютер управления.
Тип 3. Компьютерные вирусы, “вмешивающиеся” в работу компьютера и выполняемую им программу.
В начале 1989 г. вирусом, написанным американским студентом Моррисом, были заражены и выведены из строя тысячи компьютеров, в том числе принадлежащих министерству обороны США.
Тип 4. Выход из строя компонентов компьютера и обслуживающих его систем.
В процессе эксплуатации компьютера возможно физическое повреждение накопителя на жестком магнитном диске, выход из строя блока питания, отключение электроэнергии, колебания напряжения в электрической сети и др. Результатом такого рода неисправностей может быть полная потеря информации, хранящейся на жестком магнитном диске, частичная или полная потеря информации в файлах баз данных, нарушение работы систем, управляемых компьютером, и многое другое.
Тип 5. Выход из строя или сбои в работе внешних устройств (измерительных приборов, датчиков и других устройств), обеспечивающих компьютер входной информацией.
В июле 1985 года произошло преждевременное отключение компьютером одного из основах двигателей американского космического корабля “Челленджер”, которое едва не закончилось катастрофой. Если бы бортовая ЭВМ была запрограммирована на данную неисправность, то критической ситуации могло не произойти.
Тип 6. “Злая воля” человека, носителем которой чаще всего выступает либо программист, либо оператор. Программист, создавая программный комплекс, может сознательно внести в него ошибку. Следующим вариантом проявления “злой воли” программиста является включение в программу “логической бомбы”, срабатывающей, например, после определенного числа запусков программы, при определенных значениях входных данных и др. Оператор, обслуживающий компьютер, может сознательно ввести в него неверные данные.
Программист, работающий в вычислительном центре Волжского автозавода, сознательно внес в программу “логическую бомбу”. После конфликта с администрацией завода, отказавшейся повысить ему заработную плату, программист привел эту “логическую бомбу” в действие. Главный конвейер остановился, завод понес значительный материальный ущерб.
Другим проявлением “злой воли” человека является внешнее вмешательство в компьютеры, использующие сетевые технологии. Злоумышленник, взламывая систему защиты, либо нарушает корректную работу компьютера (сбои в работе, искажения и уничтожение хранимой в компьютере информации и др.), либо похищает конфиденциальную информацию, либо похищает деньги со счетов банка.
Программист, работающий в одном из американских банков, ввел в программу обработки счетов свою “добавку”, которая позволила зачислять на его личный счет остаток, получающийся от округления каждого расчета до цента. При громадном объеме банковских операций годовой “доход” программиста составил десятки тысяч долларов.
Приведенный список примеров может быть многократно дополнен. Но даже эти иллюстрации ошибок программного обеспечения и их последствий позволяют сделать обоснованный вывод о важности работ по повышению качества программ и разработки критериев оценки этого качества.
Статьи к прочтению:
- Показатели оценивания компетенций на этапах их формирования
- Показатели оценки результатов учебной деятельности
Простые показатели качества модели регрессии (R2, критерии Акаике и Шварца)
Похожие статьи:
- Номинации программы, критерии и сроки отбора ПОЛОЖЕНИЕ О проведении регионального этапа всероссийской программы «Арт-Профи Форум» на 2016-2017 годы Общие положения 1.1. Положение о региональном…
- Формы, свойства, показатели качества информации Основные понятия и методы теории информации и кодирования Формы, свойства, показатели качества информации Информатика – наука, изучающая способы…
Источник: csaa.ru