Какими свойствами обладает хорошая программа
Свойства качественного программного обеспечения
Допустим, что кто-то разработал программное обеспечение системы в срок, не превысив при этом предусмотренных затрат. Пусть оно точно и эффективно выполняет все функции, перечисленные в документации. Значит ли это, что оно качественное? По целому ряду характеристик ответ на этот вопрос может быть отрицательным. Например:
– программное обеспечение может оказаться трудным для освоения и модификации, что вызовет дополнительные затраты на его текущее обслуживание, а эти издержки не так уж малы;
– программное обеспечение может оказаться трудным для правильного использования и легким — для неправильного;
– может оказаться, что программное обеспечение в значительной мере привязано к конкретной ЭВМ или плохо стыкуется с ранее разработанными программами.
Существует, однако, целый ряд типичных ситуаций, в которых можно эффективно воздействовать на качество программного обеспечения, и поэтому очень важно знать его основные качественные характеристики.
Управление качеством программного обеспечения – это повышение экономичности его текущего обслуживания. Однако не все качественные показатели программ могут быть выражены непосредственно в терминах затрат, таких, как эксплуатационная надежность, низкий уровень которой приводит к высокой стоимости обслуживания на протяжении всего срока использования программного обеспечения, что связано с частыми корректировками и трудностями приспособления к новым требованиям пользователей.
Еще одна трудность состоит в том, что существующие показатели качества программных средств, как правило, неадекватно отражают те или иные их свойства, определяемые потребностями и предпочтениями будущего пользователя.
В связи с большим разнообразием пользователей невозможно предложить какую-то единую универсальную меру качества программного обеспечения.
Поэтому лучшее, на что может рассчитывать пользователь – это эффективная методика оценки качественных показателей на основе хорошо продуманных детальных вопросников и ранжирования соответствующих характеристик по их важности.
Однако, поскольку метрику программного обеспечения нельзя считать всеобъемлющей, общий результат такой оценки должен рассматриваться скорее как информация к размышлению, чем как окончательные выводы или предписания.
Следовательно, наиболее рациональный способ действий по оценке качества программного обеспечения на сегодня состоит в том, чтобы разработать некоторую систему индикаторов его дефектов и использовать эту систему для определения направлений дальнейшего усовершенствования программных средств, планирования их испытаний, решения вопросов о целесообразности приобретения и организации эксплуатации.
Основную проблему оценки качества программных продуктов представляет тот факт, что многие его частные качественные характеристики противоречивы.
Например:
–
увеличение эффективности нередко становится возможным лишь за счет ухудшения мобильности, точности, понятности и удобства эксплуатации;
–
повышение точности часто отрицательно сказывается на мобильности вследствие зависимости обеих характеристик от длины машинного слова;
–
достижение высокой степени осмысленности может вступать в конфликт с ограничениями на открытость.
Когда возникают подобные конфликтные ситуации, пользователи обычно затрудняются указать, какие же характеристики с их точки зрения являются более существенными.
Повышение жизнеспособности программного обеспечения можно осуществлять следующими четырьмя способами:
–
установлением в явном виде целевых параметров качества и их относительных приоритетов;
–
применением контрольных таблиц и вопросников по анализу качества;
–
введением специальных мер, гарантирующих высокое качество программ;
–
использованием специальных средств и методов повышения качества.
Если пользователь предпочитает эффективности программы ее мобильность и удобство эксплуатации, важно довести это до сведения разработчика, причем, сделать это в такой форме, которая позволяла бы в дальнейшем определить, до какой степени желаемые свойства реализованы в готовой системе программного обеспечения.
Множество характеристик качества программного обеспечения может быть представлено в виде дерева, в котором более элементарные характеристики являются необходимым условием существования более обобщенных (см. схему).
Стрелки в нем указывают логическое отношение следования. Например, если программа удобна в эксплуатации, то она обязательно понятна, она обязательно оказывается структурированной, согласованной и осмысленной, открытой и информативной.
Характеристики, расположенные на нижнем уровне дерева, представляют собой множество элементарных свойств, которые имеют фундаментальные отличия друг от друга и группируются в наборы соответственно условиям, необходимым для существования конкретных характеристик промежуточного уровня.
Для определения качества программного обеспечения необходимо объявить для него целесообразную совокупность характеристик качества по приоритетам, установить для них один или более измеримых показателей. Например, число (процент завершенности, процент ошибок, выявленных при тестировании и т.п.) или качественное суждение, вынесенное человеком в одной из двух форм: в виде численной оценки или в виде решения типа «да — нет».
Качественные характеристики затем используются для вывода некоторой интегральной оценкидостоинства всего программного обеспечения.
При этом должны обнаруживаться также всевозможные аномалии характеристик качества, которые следует классифицировать. Серьезные недостатки должны анализироваться и исправляться либо игнорироваться, если выяснится, что данный критерий неприменим к оцениваемому программному продукту, что бывает довольно часто. Например, низкий уровень понятности, может быть, допустим, в случае высокоэффективной программы, работающей в реальном масштабе времени.
Ниже предлагаются описания всех возможных промежуточных и элементарных свойств качественного программного обеспечения.
Понятность. Программное обеспечение обладает свойством понятностив той степени, в которой оно позволяет оценивающему лицу понять его назначение.
Из этого определения следует, что человек, проводящий оценивание, должен иметь возможность проникнуть в смысл документации и принципов функционирования программного обеспечения, равно как и понять его взаимосвязи с другими программными средствами и подсистемами.
Под этим определением подразумевается, что всякий программный продукт необходимо создавать с учетом нужд конечного пользователя, условий, оговоренных конкретным документом («Соглашением о требованиях», контрактом и т.п.).
Система программного обеспечения понятна лишь в том случае, если она описана ясным и простым языком, свободным от жаргона и неадекватно определенных терминов или символов, и содержит необходимые ссылки на легкодоступные документы, позволяя читателю разобраться в сложных или новых элементах.
В применении к блок-схемам алгоритмов и машинным программам свойство понятности означает четкость и аккуратность рисунков, расшифровку соответствующей символики, согласованное использование символов, адекватные комментарии или описание одинаковых всюду элементов диалога, а также написания в программах одних и тех же символических имен переменных и применение легко различимых имен.
Завершенность. Программный продукт обладает свойством завершенности,если в нем присутствуют все необходимые компоненты, каждый из которых разработан всесторонне.
О документе говорят, что он завершен, если в нем присутствуют все элементы содержания, перечисленные в оглавлении, и это содержание с достаточной полнотой отражает аспекты функционирования систем, соответствующие всем другим характеристикам.
Если база данных содержит архивные данные, то в документацию, кроме структуры базы данных должно быть включено описание всех хранимых сведений. Кроме того, сама база данных не может быть признана завершенной, если она не защищена должным образом от потери информации и не предусматривает наличия необходимого количества резервных копий.
Следовательно, завершенность предполагает замкнутость описания и живучесть программы.
Осмысленность. Программный продукт обладает свойством осмысленности,если его документация не содержит избыточной информации.
Лишние фразы и повторы затемняют основную мысль и не позволяют сосредоточить внимание на важных подробностях. Это относится как к документации, так и к самим программам.
Иногда требования осмысленности могут противоречить друг другу, особенно если читатели не являются специалистами.
Мобильность. Программный продукт обладает свойством мобильности,если он может легко и эффективно использоваться для работы на ЭВМ иного типа, чем, та, для которой он предназначен.
Свойство мобильности равнозначно свойству автономности, определяющему способность программных средств работать «на самообслуживании», без привлечения дополнительных программных ресурсов.
Потребность в обеспечении мобильности зависит от конкретного проекта, и во многих случаях здесь должны сравниваться затраты и получаемый эффект.
Может быть вполне оправданным назначение некоторого произвольно выбранного уровня мобильности, которому должно удовлетворять программное обеспечение, с определенными затратами для перехода к новым условиям функционирования в будущем.
Полезность. Программный продукт обладает свойством полезности, если он удобен для практического применения.
Это свойство имеет две стороны:
1. Программы должны быть написаны так, чтобы была возможность их полного или частичного использования (в случае необходимости) в иных условиях. При этом речь идет не о свойстве мобильности, а об ответе на вопрос: полезна ли функция, выполняемая данным программным продуктом, для других проектов?
Например, если рассматривается информационно-справочная система, важно выяснить, может ли она использоваться не только для тех целей, которые ставились первоначально при ее создании.
2. Необходима надлежащая проработка вопросов обеспечения
взаимодействия человека с машиной: должны быть четко определены входные параметры, форматы ввода данных, которые следует делать либо свободными, либо обеспечивающими определенную гибкость.
Описание выходов программ и базы данных должно быть ясным и легко интерпретируемым, позволяющим гибко определять формат и содержание результирующей информации.
Вопросы человеко-машинных интерфейсов важны даже тогда, когда программный продукт не отличается широтой использования и не обладает общей полезностью. Дело в том, что исходные данные готовятся людьми, результаты тоже должны читаться и интерпретироваться людьми, и люди могут привлекаться к операциям ведения базы данных.
В области сопряжения функций и машины существует широкий набор методов и средств, иногда они встречаются в языках высокого уровня, и большая часть этой работы ложится на разработчиков программного обеспечения.
Особенно благоприятные возможности для решения вопросов человеко-машинных интерфейсов представляют программы, предназначенные для работы с интерактивными терминалами типа графических устройств, проекционных дисплеев, индивидуальных пультов проектировщиков и т.п. Всюду, где такие терминалы существуют, они должны использоваться не только по основному назначению, но и для того, чтобы способствовать процессам подготовки исходных данных представления результатов.
Машинонезависимость. Программный продукт обладает свойством машино-независимости, если входящие в него программы могут выполняться на вычислительной машине иной конфигурации, чем та, для которой они непосредственно предназначены.
Надежность. Программный продукт обладает свойством надежности, если можно ожидать, что он будет удовлетворительно выполнять необходимые функции в течение определенного времени. Обеспечение надежности предполагает получение ответов на следующие две группы вопросов:
1) Способен ли программный продукт удовлетворить выдвинутым требованиям к нему? Если программный продукт — программа, то достигается ли необходимая точность процедур трансляции, загрузки и выполнения?
2) При функционировании в реальных условиях продолжает ли программа работать правильно в случае исходных данных, существенно отличающихся от тестовых? Как много будет выявлено скрытых ошибок после аттестации программы как работоспособной? Какова вероятность того, что результаты будут содержать необнаруженные ошибки?
Структурированность. Программный продукт обладает свойством структурированности,если его взаимосвязанные части организованы в единое целое определенным образом.
Структурированность программы может иметь в своей основе самые различные причины. Например, она может быть разработана в соответствии со специальными стандартами, определенными руководящими принципами и требованиями к интерфейсам, или она может быть написана с использованием языка структурного программирования, или может отражать в своей структуре процесс постепенного эволюционного развития на основе целенаправленных и систематизированных изменений.
Эффективность. Программный продукт обладает свойством эффективности, если он выполняет требуемые функции без лишних затрат ресурсов и времени.
Термин «ресурсы» здесь понимается в широком смысле: эта может быть оперативная память, общее количество выполняемых команд на одну итерацию решаемой задачи или на один прогон, внешняя память, пропускная способность канала и т.п.
Часто эффективностьприобретается ценой ухудшения других характеристик, так как нередко является машинозависимой характеристикой и определяется свойствами конкретного используемого языка программирования.
Необходимость обеспечения эффективности за счет ухудшения других характеристик программного обеспечения должна особо отмечаться в задании на проектирование ПО.
Точность. Программный продукт обладает свойством точности, если выдаваемые им результаты имеют точность, достаточную с точки зрения основного их назначения.
В качестве отрицательного примера можно привести два оператора
SUM: = TIIN/100; SUM: = SUM + TIIN/100;
В результате их действий при некоторых значениях переменных (TIIN = 20 и TIIN = 81) происходит нежелательная потеря целого сума (в результате получается SUM = 0).
Для обеспечения требуемой точности это вычисление можно выполнить оператором
SUM: = (TIIN1+ TIIN2)/100;
Доступность. Программный продукт обладает свойством доступности, если он допускает селективное использование отдельных его компонент.
Отрицательным примером может служить запись
GRVITY: = 1.40764548Е16/ R**2;
Здесь GRVITY – переменная, обозначающая гравитационную постоянную.
Иногда может возникнуть необходимость в использовании иного, не земного значения гравитационной постоянной, например, постоянной характеристикой лунного притяжения.
Для обеспечения широкой доступности программы целесообразна следующая форма выражения:
GRVITY = GCONST/R**2;
где переменной GCONST по умолчанию при запуске программы присваивается значение 1.4076548* 1016, но пользователь может задавать и/или изменить это значение на новое.
Модифицируемость. Программный продукт обладает свойством модифицируемости,если он имеет структуру, позволяющую легко вносить требуемые изменения.
Открытость. Программный продукт обладает свойством открытости, если его функции и назначения соответствующих операторов легко понимаются в результате чтения текста программы.
Коммуникативность. Программный продукт обладает свойством коммуникативности,если он дает возможность легко описывать входные данные и выдает информацию, форма и содержание которой просты для понимания и несут полезные сведения.
Отрицательным примером может служить выдаваемое программой число или набор чисел без комментариев.
Информативность. Программный продукт обладает свойством информативности,если он содержит информацию, необходимую и достаточную для понимания читающим лицом назначения программных средств, принятых допущений, существующих ограничений, исходных данных, результатов, отдельных компонентов и текущего состояния программ при их функционировании.
Расширяемость. Программный продукт обладает свойством расширяемости,если он позволяет увеличивать при необходимости объем памяти для хранения данных или расширять его функции.
Учет человеческого фактора. Программный продукт учитывает человеческий фактор, если он способен выполнять свои функции, не требуя излишних затрат времени со стороны пользователя, неоправданных усилий пользователя по поддержанию процесса функционирования программ и без ущерба для морального состояния пользователя.
Назад
Источник
Ка́чество програ́ммного обеспечения — способность программного продукта при заданных условиях удовлетворять установленным или предполагаемым потребностям (ISO/IEC 25000:2014)[1].
Другие определения из стандартов:
- весь объём признаков и характеристик программ, который относится к их способности удовлетворять установленным или предполагаемым потребностям (ГОСТ Р ИСО/МЭК 9126-93, ISO 8402:94)[2][3];
- степень, в которой система, компонент или процесс удовлетворяют потребностям или ожиданиям заказчика или пользователя (IEEE Std 610.12-1990)[4].
Ранние подходы к определению[править | править код]
Том Демарко в 1999 году предлагал при оценке качества программного обеспечения учитывать, что «качество программного продукта является показателем того, насколько он меняет мир к лучшему»[5].
Джеральд Вайнберг в своей работе 1992 года Quality Software Management: Volume 1, Systems Thinking давал определение качества как «значимого для какого-либо человека»[6][7], подчеркивая тем самым, что понятие качества является по своей природе субъективным — разные люди будут оценивать качество одного и того же программного обеспечения по-разному. Одной из сильных сторон этого определения являются вопросы, на которые должны ответить команды разработчиков программного обеспечения, такие как «Кто те люди, которые будут оценивать наше программное обеспечение?» и «Что будет ценным для них?».
Модели качества[править | править код]
Стандарт ISO/IEC 25010:2011 (ГОСТ Р ИСО/МЭК 25010-2015)[8] определяет модель качества продукта, которая включает восемь характеристик верхнего уровня:
- функциональная пригодность;
- уровень производительности;
- совместимость;
- удобство использования (юзабилити);
- надёжность;
- защищённость;
- сопровождаемость;
- переносимость (мобильность).
В этом стандарте модель качества продукта (англ. software product quality model) рассматривается отдельно от субъективного качества в использовании, которое может сильно отличаться для различных стейкхолдеров[9]. Модель качества в использовании (англ. quality in use model) включает следующие характеристики верхнего уровня[8]:
- результативность;
- производительность;
- удовлетворённость;
- свобода от риска;
- покрытие контекста.
Роберт Гласс в известной книге «Факты и заблуждения профессионального программирования» утверждает, что большинство профессиональных разработчиков согласны с выделением семи показателей качества как основных[10]:
- переносимость;
- надёжность;
- эффективность;
- удобство использования (юзабилити);
- тестируемость[en];
- понятность;
- модифицируемость.
Среди относительно новых моделей качества программного обеспечения можно упомянуть SQUALE и Quamoco[11], которые были применены в промышленных условиях, но пока не получили широкого распространения.
См. также[править | править код]
- Управление качеством
- Тестирование программного обеспечения
- Метрика программного обеспечения
- Технический долг
Примечания[править | править код]
- ↑ Software quality — capability of software product to satisfy stated and implied needs when used under specified conditions: ISO/IEC 25000:2014(en) Systems and software engineering — Systems and software Quality Requirements and Evaluation (SQuaRE) — Guide to SQuaRE
- ↑ ГОСТ Р ИСО/МЭК 9126-93. Оценка программной продукции. Характеристики качества и руководства по их применению
- ↑ ISO 8402:94. Управление качеством и обеспечение качества. Словарь
- ↑ The degree to which a system, component, or process meets customer or user needs or expectations: IEEE Std 610.12-1990. IEEE Standard Glossary of Software Engineering Terminology
- ↑ DeMarco, T., Management Can Make Quality (Im)possible, Cutter IT Summit, Boston, April 1999
- ↑ Weinberg, Gerald M. (1992), Quality Software Management: Volume 1, Systems Thinking, New York, NY: Dorset House Publishing, с. 7
- ↑ Weinberg, Gerald M. (1993), Quality Software Management: Volume 2, First-Order Measurement, New York, NY: Dorset House Publishing, с. 108
- ↑ 1 2 ISO/IEC 25010:2011 Systems and software engineering — Systems and software Quality Requirements and Evaluation (SQuaRE) — System and software quality models
ГОСТ Р ИСО/МЭК 25010-2015 Информационные технологии. Системная и программная инженерия. Требования и оценка качества систем и программного обеспечения (SQuaRE). Модели качества систем и программных продуктов - ↑ Wijnholds, et al, 2016.
- ↑ Роберт Гласс. Факты и заблуждения профессионального программирования. = Facts and Fallacies of Software Engineering. — 2004. — ISBN 5-93286-092-8; 978-5-93286-092-2.
- ↑ Wagner, Stefan; Goeb, Andreas; Heinemann, Lars; Kläs, Michael; Lampasona, Constanza; Lochmann, Klaus; Mayr, Alois; Plösch, Reinhold; Seidl, Andreas. Operationalised product quality models and assessment: The Quamoco approach (англ.) // Information and Software Technology (англ.)русск. : journal. — 2015. — Vol. 62. — P. 101—123. — doi:10.1016/j.infsof.2015.02.009.
Литература[править | править код]
- ГОСТ 28195-89 — Оценка качества программных средств
- Gijs Wijnholds, Zeeger Lubsen, Sylvan Rigal, Joost Visser. Building Software Teams. — O’Reilly Media, Inc., 2016.
Ссылки[править | править код]
- OpenQuality.ru | Качество программного обеспечения
Источник