КРИТЕРИИ КАЧЕСТВА ПРОГРАММ (Основные эксплуатационные требования к программным продуктам)

Радости и печали профессии.

А стоит ли вообще заниматься программированием?

 

 

Программистский фольклор

 

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

Хороший программист пишет хорошие программы, эффективные программы, хорошо оформленные программы.

Хороший программист умеет общаться с пользователями его программ.

Хороший программист умеет работать с другими людьми.

Хороший программист моется хотя бы раз в неделю.

Хороший программист приходит на работу вовремя.

Хороший программист никогда не приходит на работу не вовремя.

Хороший программист не доставляет хлопот.

Хороший программист умеет работать в напряженной обстановке.

Хороший программист любит классическую музыку.

 

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

Она работает.

Она работает согласно спецификации.

Она гибкая.

Она сделана в срок.

В ней нет ошибок.

Ошибки, которые неизбежны, быстро могут быть выявлены и локализованы.

Она хорошо оформлена.

Она решает задачи быстро.

Она имеет дружественный интерфейс.

Очень важное правило: "Программы пишутся для людей, а не для ЭВМ".

 

Математика делает то, что можно, так, как нужно, тогда как информатика делает то, что нужно, так, как можно.

 

 

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

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

Качество программного продукта характеризуется набором свойств, определяющих, насколько продукт "хорош" с точки зрения заинтересованных сторон, таких как:

-заказчик продукта;

-спонсор;

-конечный пользователь;

-разработчики и тестировщики продукта;

-инженеры поддержки;

-сотрудники отделов маркетинга, обучения и продаж.

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

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

Разработка программного обеспечения - это, прежде всего, нахождение способов получения качественного программного продукта.

Критерии качества программных средств устанавливаются государственными стандартами, в частности, ГОСТ 28195-89 и ГОСТ Р ИСО/МЭК 9126-93

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

1. Функциональные возможности, пригодность и правильность ПО

Характеризуется :

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

б) правильностью и соответствием результатов или эффектов.

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

1) решает несколько другую задачу;

2) решает только часть поставленной задачи;

3) работает не во всех случаях, предусмотренных техническим

заданием.

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

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

д) полнотой проверенности возможных маршрутов выполнения программы в процессе тестирования. (пояснить)

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

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

Неконструктивность понятия правильной программы.

Таким образом, можно считать, что продуктом технологии программирования является ПС, содержащее программы, выполняющие требуемые функции. Здесь под «программой» часто понимают правильную программу, т.е. программу, не содержащую ошибок. Однако, понятие ошибки в программе трактуется в среде программистов неоднозначно. Согласно Майерсу будем считать, что в программе имеется ошибка, если она не выполняет того, что ожидается от нее пользователю на основании документации по применению этой программы. Следовательно, понятие ошибки в программе является существенно не формальным. В ПС программы и документация взаимно увязаны, образуют некоторую целостность. Поэтому правильнее говорить об ошибке не в программе, а в ПС в целом: будем считать, что в ПС имеется ошибка (software error), если оно не выполняет того, что разумно ожидать от него пользователю. В частности, разновидностью ошибки в ПС является несогласованность между программами ПС и документацией по их применению. В работе [1.3] выделяется в отдельное понятие частный случай ошибки в ПС, когда программа не соответствует своей функциональной спецификации (описанию, разрабатываемому на этапе, предшествующему непосредственному программированию). Такая ошибка в указанной работе называется дефектом программы. Однако выделение такой разновидности ошибки в отдельное понятие вряд ли оправданно, так как причиной ошибки может оказаться сама функциональная спецификация, а не программа.

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

2. Надежность.

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

(график динамики частоты отказов L с течением времени T)

Источниками помех(ошибок) могут быть все участники вычислительного процесса: технические средства, программные средства и люди. Техничекие средства подвержены сбоям, например, из-за резких скачков напряжения питания. ПО может содержать ошибки. А люди могут ошибаться при ивводе исходных данных.

Характеризуется:

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

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

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

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

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

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

3. Эффективность (компактность) т.е оптимальное использование ресурсов ЭВМ.

Характеризуется:

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

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

в) ресурсоемкостью, т.е. минимально необходимыми вычислительными ресурсами (требуемая память ОЗУ и внешней памяти, время выполнения), числом обслуживающего персонала и число обслуживаемых внешних устройств).

 

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

Характеризуется:

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

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

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

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

Все это способствует быстрому освоению ПО профессиональными программистами.

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

Характеризуется:

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

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

в) доступностью эксплуатационных программных документов т.е. понятностью, наглядностью и полнотой описания взаимодействия пользователя с программой в эксплуатационных программных документах. (В «Абонент » это Помощь(Руководство пользователя), Руководство системного администратора).

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

Характеризуется:

а) мобильностью(совместимостью) т.е. набором атрибутов, относящихся к способности ПО быть перенесенным из одного окружения (организационного, программного или аппаратного) в другое (например, способность работы ПО на различных технических средствах или возможность достаточно простого переноса на другие технические средства);

б) гибкостью (изменяемость) т.е. возможностью использования программы в различных областях применения.

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

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

 

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

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

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

Верификация и валидация (см. http://www.intuit.ru/department/se/verify/1/4.html)

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

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

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

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

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

Различие между верификацией и валидацией проиллюстрировано на рисунке 1.

Рисунок 1 - Соотношение верификации и валидации

Приведенные определения получены некоторым расширением определений из стандарта IEEE 1012 на процессы верификации и валидации [2]. В стандартном словаре терминов программной инженерии IEEE 610.12 1990 года [3] определение верификации по смыслу примерно то же, а определение валидации несколько другое - там говорится, что валидация должна проверять соответствие полученного в результате разработки ПО исходным требованиям к нему. В этом случае валидация являлась бы частным случаем верификации, что нигде в литературе по программной инженерии не отмечается, поэтому, а также потому, что оно поправлено в IEEE 1012 2004 года, это определение следует считать неточным. Частое использование фразы B. Boehm'а [4]:

Верификация отвечает на вопрос "Делаем ли мы продукт правильно?", а валидация- на вопрос "Делаем ли мы правильный продукт?"

также добавляет путаницы, поскольку афористичность этого высказывания, к сожалению, сочетается с двусмысленностью. Однако многочисленные труды его автора позволяют считать, что он подразумевал под верификацией и валидацией примерно те же понятия, которые определены выше. Указанные разночтения можно проследить и в содержании стандартов программной инженерии. Так, стандарт ISO 12207 [5] считает тестирование разновидностью валидации, но не верификации, что, по-видимому, является следствием использования неточного определения из стандартного словаря [3].

Чтобы было проще понять, сразу приведу пример типичной верификации: тестирование программы или проведение испытания оборудования. Имея определенные требования на руках, мы проводим испытание продукта и фиксируем, соблюдены ли требования. Результат верификации — это ответ на вопрос «Соответствует ли продукт требованиям?».

Но далеко не всегда продукт, соответствующий установленным требованиям, можно применять в конкретной ситуации. Например, лекарство прошло все положенные испытания и поступило в продажу. Значит ли это что оно может быть применено каким-то конкретным больным? Нет, т. к. каждый пациент имеет свои особенности и конкретно для этого лекарство может быть губительным, т.е. кто–то (врач) должен подтвердить: да, этому больному можно принимать это лекарство. То есть врач должен выполнить валидацию: придать законную силу конкретному применению.

Или еще пример. Предприятие выпускает трубы, предназначенные для закладки в землю, в соответствии с некоторыми ТУ (Техническими условиями). Продукция этим ТУ соответствует, но поступил заказ, предполагающий укладку труб по дну моря. Могут ли трубы, соответствующие имеющимся ТУ, быть применены в данном случае? Именно валидация и дает ответ на этот вопрос.

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

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

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