Какими свойствами обладает хорошая программа

Свойства качественного программного обеспечения

Допустим, что кто-то разработал программное обеспечение системы в срок, не превысив при этом предусмотренных затрат. Пусть оно точно и эффективно выполняет все функции, пере­численные в документации. Значит ли это, что оно качественное? По целому ряду характеристик ответ на этот вопрос может быть отрицательным. Например:

– программное обеспечение может оказаться трудным для освоения и модификации, что вызовет дополнительные затраты на его текущее обслуживание, а эти издержки не так уж малы;

– программное обеспечение может оказаться трудным для правильного использования и легким — для неправильного;

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

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

Управление качеством программного обеспечения – это повышение экономичности его текущего обслуживания. Однако не все качественные показатели программ могут быть выражены непосредственно в терминах затрат, таких, как эксплуатационная надежность, низкий уровень которой приводит к высокой стои­мости обслуживания на протяжении всего срока использования программного обеспечения, что связано с частыми коррек­тировками и трудностями приспособления к новым требованиям пользователей.

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

В связи с большим разнообразием пользователей невозможно предложить какую-то единую универсальную меру качества программного обеспечения.

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

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

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

Основную проблему оценки качества программных продуктов  пред­став­ляет тот факт, что многие его частные качественные характеристики противоречивы.

Например:

–  

увеличение эффективности нередко становится возмож­ным лишь за счет ухудшения мобильности, точности, понятности и удобства эксплуатации;

–  

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

–  

достижение высокой степени осмысленности может всту­пать в конфликт с ограничениями на открытость.

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

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

–  

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

–  

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

–  

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

–  

использованием специальных средств и методов повы­шения  качества.

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

Множество характеристик качества программного обеспе­чения может быть представлено в виде дерева, в котором более элементарные характеристики являются необходимым условием существования более обобщенных (см. схему).

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

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

Для определения качества программного обеспечения необ­ходимо объявить для него целесообразную совокупность харак­теристик качества по приоритетам, установить для них один или более измеримых показателей. Например, число (процент завершенности, процент ошибок, выявленных при тестировании и т.п.) или качественное суждение, вынесенное человеком в одной из двух форм: в виде численной оценки или в виде решения типа «да — нет».

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

Читайте также:  Какие свойства воды есть в твердом состоянии

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

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

Понятность. Программное обеспечение обладает свойством понятностив той степени, в которой оно позволяет оцени­вающему лицу понять его назначение.

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

Под этим определением подразумевается, что всякий прог­раммный продукт необходимо создавать с учетом нужд конечного пользователя, условий, оговоренных конкретным документом («Соглашением о требованиях», контрактом и т.п.).

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

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

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

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

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

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

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

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

Иногда требования осмысленности могут противоречить друг другу, особенно если читатели не являются специалистами.

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

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

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

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

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

Это свойство имеет две  стороны:

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], которые были применены в промышленных условиях, но пока не получили широкого распространения.

См. также[править | править код]

  • Управление качеством
  • Тестирование программного обеспечения
  • Метрика программного обеспечения
  • Технический долг

Примечания[править | править код]

  1. 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
  2. ↑ ГОСТ Р ИСО/МЭК 9126-93. Оценка программной продукции. Характеристики качества и руководства по их применению
  3. ↑ ISO 8402:94. Управление качеством и обеспечение качества. Словарь
  4. 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
  5. ↑ DeMarco, T., Management Can Make Quality (Im)possible, Cutter IT Summit, Boston, April 1999
  6. ↑ Weinberg, Gerald M. (1992), Quality Software Management: Volume 1, Systems Thinking, New York, NY: Dorset House Publishing, с. 7
  7. ↑ Weinberg, Gerald M. (1993), Quality Software Management: Volume 2, First-Order Measurement, New York, NY: Dorset House Publishing, с. 108
  8. 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). Модели качества систем и программных продуктов
  9. ↑ Wijnholds, et al, 2016.
  10. Роберт Гласс. Факты и заблуждения профессионального программирования. = Facts and Fallacies of Software Engineering. — 2004. — ISBN 5-93286-092-8; 978-5-93286-092-2.
  11. 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 | Качество программного обеспечения

Источник