Наличие требований к программе по устойчивости функционирования при наличии ошибок во входных данных
Программа считается правильной, если она не содержит ошибок. Такая программа не дает неверных результатов, т.е. она абсолютно надежна. Этот факт породил ложное представление о том, что число ошибок в программе можно считать наиболее естественной мерой надежности. Было выполнено довольно много работ, в которых предлагались различные методы оценки числа оставшихся в программе ошибок по результатам ее тестирования, в том числе метод "засорения" известными ошибками, однако, как показывают приводимые ниже соображения, количество ошибок в программе не имеет никакого отношения к ее надежности:
1. Число ошибок в программе - величина "ненаблюдаемая", наблюдаются не сами ошибки, а результат их проявления.
2. Неверное срабатывание программы может быть следствием не одной, а сразу нескольких ошибок.
3. Ошибки могут компенсировать друг друга, так что после исправления какой-то одной ошибки программа может начать "работать хуже".
4. Надежность характеризует частоту проявления ошибок, но не их количество; в то же время хорошо известно, что ошибки проявляются с разной частотой: некоторые ошибки остаются невыявленными после многих месяцев и даже лет эксплуатации, но, с другой стороны, нетрудно привести примеры, когда одна единственная ошибка приводит к неверному срабатыванию программы при любых исходных данных, т.е. к нулевой надежности.
Согласно [ГОСТ 9126] качество программного обеспечения это весь объем признаков и характеристик программного обеспечения, который относится к ее способности удовлетворять установленным или предполагаемым потребностям.
Качество программного обеспечения оценивается следующими характеристиками:
Функциональные возможности (Functionality).Набор атрибутов,относящихся к сути набора функций и их конкретным свойствам. Функциями являются те, которые реализуют установленные или предполагаемые потребности.
Надежность (Reliability).Набор атрибутов относящихся к способности программногообеспечения сохранять свой уровень качества функционирования при установленных условиях за установленный период времени.
Практичность (Usability).Набор атрибутов,относящихся к объему работ,требуемых дляиспользования и индивидуальной оценки такого использования определенным и предполагаемым кругом пользователей.
Эффективность (Efficiencies).Набор атрибутов,относящихся к соотношению междууровнем качества функционирования программного обеспечения и объемом используемых ресурсов при установленных условиях.
Сопровождаемость (Maintainability).Набор атрибутов,относящихся к объему работ,требуемых для проведения конкретных изменений (модификаций).
Мобильность (Portability).Набор атрибутов,относящихся к способности программногообеспечения быть перенесенным из одного окружения в другое.
В общем случае под ошибкой подразумевается неправильность, погрешность или неумышленное искажение объекта или процесса, что может быть причиной ущерба – риска при функционировании или применении программы. При этом предполагается, что известно правильное, эталонное состояние объекта или процесса по отношению к которому может быть определено наличие отклонения. Исходным эталоном для любого программного обеспечения являются спецификации требований заказчика или потенциального пользователя, предъявляемых к программам и ожидаемый пользователем или заказчиком эффект от использования программного обеспечения. Важной особенностью при этом является отсутствие полностью определенной программы – эталона, которой должны соответствовать текст и результаты функционирования разрабатываемой программы. Поэтому определить качество программного обеспечения и наличие ошибок в нем путем сравнения разрабатываемой программы с эталонной программой невозможно.
Риски проявляются как негативные последствия проявления ошибок в программном обеспечении в ходе его применения и функционирования, которые могут нанести ущерб системе, в которой применяется это программное обеспечение, внешней среде или пользователям этой системы в результате отклонения характеристик программного обеспечения заданных или ожидаемых пользователем или заказчиком.
Исходя из определения ошибки в программном обеспечении, приведенном выше, можно сделать вывод, что ошибки, проявляющиеся в ходе функционирования программного обеспечения, могут влиять на все показатели качества. В работе рассматриваются ошибки, проявления которых влияют на надежность функционирования программного обеспечения.
По определению, установленному в программу, надежность – свойство объекта выполнять заданные функции, сохраняя во времени значения установленных эксплуатационных показателей в заданных пределах, соответствующим заданным режимам и условиям использования, технического обслуживания, ремонта, хранения и транспортирования.
Рис. 1. Надежность по ГОСТ 27.002 – 89
При этом надежность является комплексным свойством, которое в зависимости от назначения объекта и условий его применения может включать безотказность, долговечность, ремонтопригодность и сохраняемость или определенные сочетания этих свойств (рис. 1). Поскольку программное обеспечение в процессе эксплуатации не изнашивается, его поломка и ремонт в общепринятом смысле не производится, то надежность программного обеспечения имеет смысл характеризовать только с точки зрения безотказности его функционирования и возможности восстановления функционирования после отказов вызванных проявлениями ошибок.
В данном случаи надежность программного обеспечения предлагается характеризовать с помощью следующих характеристик (рис. 2): стабильность, устойчивость и восстанавливаемость.
Рис. 2. Надежность программного обеспечения
В этом случае стабильность и устойчивость характеризуют безотказность программного обеспечения, а восстанавливаемость – возможность восстановления функционирования программного обеспечения после его отказа. Для количественной оценки надежности программного обеспечения необходимо определить показатели надежности для каждого свойства и методику их определения (оценки).
Для оценки стабильности программного обеспечения возможно использование показателей характеризующих безотказность технических устройств(рис. 3).
Рис. 3. Показатели безотказности
В большинстве случаев поток программных ошибок может быть описан негомогенным процессом Пуассона. Это означает, что программные ошибки происходят в статистически независимые моменты времени, наработки
подчиняются экспоненциальному распределению, а интенсивность проявления ошибок изменяется во времени. Обычно используют убывающую интенсивность проявления ошибок. Это означает, что ошибки, как только они выявлены, эффективно устраняются без введения новых ошибок. Главная цель анализа надежности программного обеспечения заключается в том, чтобы определить форму функции интенсивности проявления ошибок и оценить ее параметры по наблюдаемым данным. Как только функция интенсивности проявления ошибок определена, могут быть найдены такие показатели надежности как:
• общее количество ошибок;
• количество остающихся ошибок;
• время до проявления следующей ошибки;
• вероятность безошибочной работы;
• интенсивность проявления ошибок;
• остаточное время испытаний (до принятия решения);
• максимальное количество ошибок (относительно срока службы).
При этом следует различать понятия ошибка и отказ. Применительно к надежности программного обеспечения ошибка это погрешность или искажение кода программы, неумышленно внесенные в нее в процессе разработки, которые в ходе функционирования этой программы могут вызвать отказ или снижение эффективности функционирования. Под отказом в общем случае понимают событие, заключающееся в нарушении работоспособности объекта. Состояние объекта, при котором значения всех параметров характеризующих способность выполнять заданные функции, соответствуют требованиям нормативно – технической и (или) конструкторской (проектной) документации – называется работоспособным. При этом критерии отказов, как признаки или совокупность признаков нарушения работоспособного состояния программного обеспечения, должны определяться исходя из его предназначения в нормативно – технической и (или) конструкторской (проектной) документации.
В общем случае отказ программного обеспечения можно определить как:
прекращение функционирования программы (искажения нормального хода ее выполнения, зацикливание) на время превышающее заданный порог;
прекращение функционирования программы (искажения нормального хода ее выполнения, зацикливание ) на время не превышающее заданный порог, но с потерей всех или части обрабатываемых данных;
прекращение функционирования программы (искажения нормального хода ее выполнения, зацикливание ) потребовавшее перезагрузки ЭВМ, на которой функционирует программное обеспечение.
При этом исходя из всего, все отказы в программном обеспечении следует трактовать как сбои (самоустраняющиеся отказы или однократные отказы, устраняемые незначительным вмешательством оператора), поскольку восстановление работоспособного состояния программного обеспечения может произойти без вмешательства оператора (перезагрузка ЭВМ не требуется), либо при участии оператора или эксплуатирующего персонала (перезагрузка ЭВМ необходима).
Приведенные выше критерии отказов приводят к необходимости анализа временных характеристик функционирования программы и динамических характеристик потребителей данных, полученных в ходе функционирования программного обеспечения. Временная зона перерыва нормальной выдачи информации и потери работоспособности, которую следует рассматривать как зону сбоя (отказа), тем шире, чем более инертный объект находится под воздействием данных, полученным в ходе работы программы. Пороговое время восстановления работоспособного состояния системы, при превышении которого следует фиксировать отказ, близко к периоду решения задач для подготовки информации (данных) соответствующему потребителю (абоненту).
Для любого потребителя данных существует допустимое время отсутствия данных от программы, при котором его характеристики находятся в допустимых пределах . Исходя из этого времени, можно установить границы временной зоны, которая разделяет работоспособное и неработоспособное состояние программного обеспечения и позволяет использовать данные критерии отказов.
Из приведенного выше определения программной ошибки с точки зрения надежности, можно сделать вывод о том , что ошибки, при их проявлении, не всегда вызывают отказ программного обеспечения и каждую ошибку можно характеризовать условной вероятностью возникновения отказа при проявлении этой ошибки. Следует также отметить, что само по себе наличие ошибки в исходном коде не определяет надежность программы до тех пор, пока не произойдет проявления этой ошибки, поэтому пользоваться для оценки надежности программного обеспечения только показателями характеризующие общее количество ошибок в программе, количество оставшихся ошибок и максимального количества ошибок нельзя.
В данном случаи стабильность предлагается оценивать вероятностью безотказной работы, которая оценивается исходя из модели относительной частоты, при этом применение ее ограничено периодом эксплуатации программного обеспечения, что не всегда приемлемо, поскольку надежность объекта, как правило, необходимо оценивать не только в процессе его эксплуатации, но и до начала эксплуатации этого объекта. Ограничение модели относительной частоты вызвано тем, что в этой модели не учитываются процессы тестирования и отладки, а конкретно то, что при возникновении отказа программного обеспечения, ошибка, вызвавшая этот отказ, исправляется.
Наиболее приемлемыми показателями характеризующими стабильность (безотказность) программного обеспечения представляются показатели сходные с показателями безотказности технических систем: вероятность безотказной работы, интенсивность отказов, и среднее время наработки на отказ. Эти показатели взаимосвязаны и, зная один из них, можно определить другие. При определении этих показателей в большинстве случаев можно исходить из модели надежности, предполагающей, что интенсивность проявления ошибок убывает по мере исправления этих ошибок, время между проявлениями ошибок распределено экспоненциально, а интенсивность проявления ошибок постоянна между двумя соседними проявлениями ошибок. Применение такой модели надежности программного обеспечения позволит оценить надежность программного обеспечения во время тестирования и отладки.
Устойчивость, как свойство или совокупность свойств программного обеспечения, характеризующие его возможность поддерживать приемлемый уровень функционирования при проявлениях ошибок в нем , можно оценивать условной вероятностью безотказной работы при проявлении ошибки. Согласно правилу устойчивость оценивается с помощью трех метрик, включающих двадцать оценочных элементов.
Устойчивость программного обеспечения;
Средство восстановления при ошибках на входе;
Наличие требований к программе по устойчивости функционирования при наличии ошибок во входных данных;
1. Возможность обработки ошибочных ситуаций;
2. Полнота обработки ошибочных ситуаций;
3. Наличие тестов для проверки допустимых значений входных данных;
4. Наличие системы контроля полноты входных данных;
5. Наличие средств контроля корректности входных данных;
6. Наличие проверки параметров и адресов по диапазону их знаний;
7. Наличие обработки граничных результатов;
8. Наличие обработки неопределенностей (деление на 0, квадратный корень из отрицательного числа).
Средства восстановления при сбоях в оборудовании;
1. Наличие требований к программе по восстановлению результатов при отказах процессора, операционной системы;
2. Наличие требований к программе по восстановлению процесса выполнения в случае сбоя операционной системы, процессора, внешних устройств;
3. Наличие средств восстановления процесса в случае сбоев оборудования;
4. Наличие возможности разделения по времени выполнения отдельных функций программ;
5. Наличие возможности повторного старта с точки остановки.
Реализация управления средствами восстановления;
1. Наличие централизованного управления процессами, конкурирующими между ресурсами;
2. Наличие возможности автоматически обходить ошибочные ситуации в процессе вычисления;
3. Наличие средств, обеспечения завершения процесса в случае помех;
4. Наличие средств, обеспечивающих выполнение программы в сокращенном объёме в случае ошибок и помех;
5. Показатель устойчивости к искажающим воздействиям.
Метрики и оценочные элементы устойчивости программного обеспечения по ГОСТ 28195 – 89
Результаты оценки каждой метрики определяются результатами оценки определяющих ее оценочных элементов, а результат оценки устойчивости определяются результатами соответствующих ему метрик. Программное обеспечение по каждому из оценочных элементов оценивается группой экспертов – специалистов, компетентных в решении данной задачи, на базе их опыта и интуиции. Для оценочных элементов принимается единая шкала оценки от 0 до 1.
Недостатком такого подхода является одинаковая оценка устойчивости для всех возможных ошибок. Поскольку вероятность возникновения отказа при проявлении разных ошибок может быть разной, возникает необходимость разделения ошибок на несколько категорий. Признаком, по которому в этом случае можно относить ошибки к той или иной категории, можно считать тяжесть ошибки. Под тяжестью ошибки в этом случае следует понимать количественную или качественную оценку вероятного ущерба при проявлении
этой ошибки, а если говорить о надежности, то оценку вероятности возникновения отказа при проявлении ошибки. При этом категорией тяжести последствий ошибки будет являться классификационная группа ошибок по тяжести их последствий, характеризуемая определенным сочетанием качественных и/или количественных учитываемых составляющих ожидаемого (вероятного) отказа или нанесенного отказом ущерба. В качестве показателя степени тяжести ошибки, позволяющего дать количественную оценку тяжести проявления последствий ошибки целесообразно использовать условную вероятность отказа и его возможных последствий при проявлении ошибок разных категорий. Для программного обеспечения, создаваемого для систем управления, потеря работоспособности которых может повлечь за собой катастрофические последствия, возможные категории тяжести ошибок приведены в таблице
Согласно ГОСТ 28195-1989 «Оценка качества программных средств» данный программный продукт следует отнести к подклассу 509 - прочие программные средства. Поэтому, для оценки его качества рассмотрим все номенклатурные показатели представленные в таблице 1 ГОСТ 28195-89.
- 1. Показатели надежности ПС.
- 1.1. Устойчивость функционирования (способность обеспечивать продолжение работы программы после возникновения отклонений, вызванных сбоями технических средств, ошибками во входных данных и ошибками обслуживания).
- 1.2. Работоспособность (способность программы функционировать в заданных режимах и объемах обрабатываемой информации в соответствии с программными документами при отсутствии сбоев технических средств).
- 2. Показатели сопровождения.
- 2.1. Структурность (организация всех взаимосвязанных частей программы в единое целое с использованием логических структур «последовательность», «выбор», «повторение»).
- 2.2. Простота конструкции (построение модульной структуры программы более рациональным с точки зрения восприятия и понимания образом).
- 2.3. Наглядность (наличие и представление в наиболее легко воспринимаемом виде исходных модулей ПС, полное их описание в соответствующих программных документах).
- 2.4. Повторяемость (степень использования типовых проектных решений или компонентов, входящих в ПС).
- 3. Показатели удобства применения.
- 3.1. Легкость освоения (представление программных документов и программы в виде, способствующем пониманию логики функционирования программы в целом и ее частей).
- 3.2. Доступность эксплуатационных программных документов (понятность, наглядность и полнота описания взаимодействия пользователя с программой в эксплуатационных программных документах).
- 3.3. Удобство эксплуатации и обслуживания (соответствие процесса обработки данных и форм представления результатов характеру решаемых задач).
- 4. Показатели эффективности.
- 4.1. Уровень автоматизации (уровень автоматизации функций процесса обработки данных с учетом рациональности функциональной структуры программы с точки зрения взаимодействия с ней пользователя и использования вычислительных ресурсов).
- 4.2. Временная эффективность (способность программы выполнять заданные действия в интервале времени, отвечающем заданным требованиям).
- 4.3. Ресурсоемкость (минимально необходимые вычислительные ресурсы и число обслуживающего персонала для эксплуатации ПС).
- 5. Показатели универсальности.
- 5.1. Гибкость (возможность использования ПС в различных областях применения).
- 5.2. Мобильность (возможность применения ПС без существенных дополнительных трудозатрат на ЭВМ аналогичного класса).
- 5.3. Модифицируемость (обеспечение простоты внесения необходимых изменений и доработок в программу в процессе эксплуатации).
- 6. Показатели корректности.
- 6.1. Полнота реализации (полнота реализации заданных функций ПС и достаточность их описания в программной документации).
- 6.2. Согласованность (однозначное, непротиворечивое описание и использование тождественных объектов, функций, терминов, определений, идентификаторов и т.д. в различных частях программных документов и текста программы).
- 6.3. Логическая корректность (функциональное и программное соответствие процесса обработки данных при выполнении задания общестстемным требованиям).
- 6.4. Проверенность (полнота проверки возможных маршрутов выполнения программы в процессе тестирования).
Эти показатели важны, так как программа должна удовлетворять предъявляемым требованиям по обеспечению необходимой функциональности и корректности работы.
Коды оценочных элементов составлены из 5 символов следующим образом:
- 1-й символ - буква русского алфавита - указывает на принадлежность элементу тому или иному фактору. («Н» -- надежность, «С» -- сопровождаемость, «У» -- удобство применения, «Э» -- эффективность, «Г» -- универсальность, «К» -- корректность);
- 2-й и 3-й символы - номер метрики, которой принадлежит оценочный элемент;
- 4-й и 5-й символы - порядковый номер данного оценочного элемента в метрике.
Расчет значений показателей качества.
1. Итоговая оценка k-й метрики j-го критерия ведется по формуле
где Q - число оценочного элемента (ОЭ) в k-ой метрике.
- 2. Абсолютные показатели критериев i-гo фактора качества определяется по формуле , где n -- число метрик, относящихся к j-му критерию.
- 3. Относительный показатель j-го критерия i-гo фактора качества вычисляется по формуле
4. Фактор качества вычисляется по формуле:
где N -- число критериев качества, относящихся к i-му фактору.
Таблица 8. Пофакторный анализ качества программного продукта.
Наименование оценочного элемента
Показатель устойчивости к искажающим воздействиям
, - число экспериментов, в которых искажающие воздействия приводили к отказу, - число экспериментов, в которых имитировались искажающие воздействия.
Вероятность безотказной работы
Оценка по среднему времени восстановления
, где - допустимое среднее время восстановления,
- среднее время восстановления, определяется по формуле:
, - число восстановлений, - время восстановления после i-го отказа.
TВ=(2+2+3+2+2+3+2+5+4+3+3+3+2+4+4+4+5+2+3+2)/20= 3 с
Q = TВдоп / TВ = 2/3 = 0,667
Оценка по продолжительности преобразования входного набора данных в выходной
- допустимое время преобразования i-го входного набора данных, - фактическая продолжительность преобразования i-го входного набора данных
N=2 (кол-во входных наборов данных).
Оценка простоты программы по числу точек входа и выхода
W=1/(D+1)*(F+1), где D-общее число точек входа в программу, F-общее число точек выхода из программы. D=1, F=1
Оценка простоты программы по числу переходов по условию
U = (1-A/B), где
A - общее число переходов по условию
B - количество исполняемых операторов
U =1-115/503 = 0.771
Отношение числа модулей, отработавших в процессе тестирования и отладки (Qтм) к общему числу модулей(Qом).
Отношение числа логических блоков, отработавших в процессе тестирования и отладки(Qтб), к общему числу логических блоков в программе(Qоб).
1. Фактор надежность (ФН).
Таблица 9. Критерий устойчивость функционирования (УФ).
Наименование оценочного элемента
Наличие требований к программе по устойчивости функционирования при наличии ошибок во входных данных
Возможность обработки ошибочных ситуаций
Полнота обработки ошибочных ситуаций
Наличие тестов для проверки допустимых значений входных данных
Наличие системы контроля полноты входных данных
Наличие средств контроля корректности входных данных
Наличие средств контроля непротиворечивости входных данных
Наличие проверки параметров и адресов по диапазону их значений
Наличие обработки граничных результатов
Наличие обработки неопределенностей
Наличие требований к программе по восстановлению процесса выполнения в случае сбоя операционной системы, процессора, внешних устройств
Наличие требований к программе по восстановлению результатов при отказах процессора, ОС
Наличие средств восстановления процесса в случае сбоев оборудования
Наличие возможности разделения по времени выполнения отдельных функций программы
Наличие возможности повторного старта с точки остановки
Наличие централизованного управления процессами, конкурирующими из-за ресурсов
Наличие возможности автоматически обходить ошибочные ситуации в процессе вычисления
Наличие средств, обеспечивающих завершение процесса решения в случае помех
Наличие средств, обеспечивающих выполнение программы в сокращенном объеме в случае ошибок или помех
Настоящий стандарт устанавливает общие положения по оценке качества программных средств вычислительной техники (далее - ПС), поставляемых через фонды алгоритмов и программ (ФАП), номенклатуру и применяемость показателей качества ПС.
Термины, применяемые в стандарте, и пояснения к ним приведены в приложении 1.
1.1 . Оценка качества осуществляется на всех этапах жизненного цикла ПС при:
- планировании показателей качества ПС;
- контроле качества на отдельных этапах разработки (техническое задание, технический проект, рабочий проект);
- контроле качества в процессе производства ПС;
- проверке эффективности модификации ПС на этапе сопровождения.
1.2 . Оценка качества ПС представляет собой совокупность операций, включающих выбор номенклатуры показателей качества оцениваемого ПС, определение значений этих показателей и сравнение их с базовыми значениями.
1.3 . Оценку качества проводят специалисты организаций:
- разработчика - на этапах разработки ПС;
- фондодержателя - на этапах приемки ПС в фонд;
- испытательных центров и центров сертификации ПС - на этапах испытаний и внедрения;
- изготовителя - на этапах тиражирования ПС;
- пользователя - на этапах внедрения, сопровождения и эксплуатации ПС.
1.4 . Основные задачи, решаемые при оценке качества ПС:
- планирование уровня качества;
- контроль значений показателей качества в процессе разработки и испытаний;
- эксплуатационный контроль заданного уровня качества;
- выбор базовых образцов по подклассам и группам;
- методическое руководство разработкой нормативно-технических документов по оценке качества.
1.5 . Методы определения показателей качества ПС различаются:
- по способам получения информации о ПС - измерительный, регистрационный, органолептический, расчетный;
- по источникам получения информации - традиционный, экспертный, социологический.
1.5.1 . Измерительный метод основан на получении информации о свойствах и характеристиках ПС с использованием инструментальных средств. Например, с использованием этого метода определяется объем ПС - число строк исходного текста программ и число строк - комментариев, число операторов и операндов, число исполненных операторов, число ветвей в программе, число точек входа (выхода), время выполнения ветви программы, время реакции и другие показатели.
1.5.2 . Регистрационный метод основан на получении информации во время испытаний или функционирования ПС, когда регистрируются и подсчитываются определенные события, например, время и число сбоев и отказов, время передачи управления другим модулям, время начала и окончания работы.
1.5.3 . Органолептический метод основан на использовании информации, получаемой в результате анализа восприятия органов чувств (зрения, слуха), и применяется для определения таких показателей как удобство применения, эффективность и т.п.
1.5.4 . Расчетный метод основан на использовании теоретических и эмпирических зависимостей (на ранних этапах разработки), статистических данных, накапливаемых при испытаниях, эксплуатации и сопровождении ПС. При помощи расчетного метода определяются длительность и точность вычислений, время реакции, необходимые ресурсы.
1.5.5 . Определение значений показателей качества ПС экспертным методом осуществляется группой экспертов-специалистов, компетентных в решении данной задачи, на базе их опыта и интуиции.
Экспертный метод применяется в случаях, когда задача не может быть решена никаким другим из существующих способов или другие способы являются значительно более трудоемкими. Экспертный метод рекомендуется применять при определении показателей наглядности, полноты и доступности программной документации, легкости освоения, структурности.
1.5.6 . Социологические методы основаны на обработке специальных анкет-вопросников.
2.1 . Номенклатура показателей качества и характеризуемые ими свойства программных средств приведены в табл. 1 , где представлены 2 уровня иерархической структуры показателей качества ПС:
Наименование групп и комплексных показателей качества
1 . Показатели надежности ПС
Характеризуют способность ПС в конкретных областях применения выполнять заданные функции в соответствии с программными документами в условиях возникновения отклонений в среде функционирования, вызванных сбоями технических средств, ошибками во входных данных, ошибками обслуживания и другими дестабилизирующими воздействиями
1.1 . Устойчивость функционирования
Способность обеспечивать продолжение работы программы после возникновения отклонений, вызванных сбоями технических средств, ошибками во входных данных и ошибками обслуживания
Способность программы функционировать в заданных режимах и объемах обрабатываемой информации в соответствии с программными документами при отсутствии сбоев технических средств
2 . Показатели сопровождения
Характеризуют технологические аспекты, обеспечивающие простоту устранения ошибок в программе и программных документах и поддержания ПС в актуальном состоянии
Организация всех взаимосвязанных частей программы в единое целое с использованием логических структур «последовательность», «выбор», «повторение»
2.2 . Простота конструкции
Построение модульной структуры программы наиболее рациональным с точки зрения восприятия и понимания образом
Наличие и представление в наиболее легко воспринимаемом виде исходных модулей ПС, полное их описание в соответствующих программных документах
Степень использования типовых проектных решений или компонентов, входящих в ПС
3 . Показатели удобства применения
Характеризуют свойства ПС, способствующие быстрому освоению, применению и эксплуатации ПС с минимальными трудозатратами с учетом характера решаемых задач и требований к квалификации обслуживающего персонала
3.1 . Легкость освоения
Представление программных документов и программ в виде, способствующем пониманию логики функционирования программы в целом и ее частей
3.2 . Доступность эксплуатационных программных документов
Понятность, наглядность и полнота описания взаимодействия пользователя с программой в эксплуатационных программных документах
3.3 . Удобство эксплуатации и обслуживания
Соответствие процесса обработки данных и форм представления результатов характеру решаемых задач
4 . Показатели эффективности
Характеризуют степень удовлетворения потребности пользователя в обработке данных с учетом экономических, вычислительных и людских ресурсов
4.1 . Уровень автоматизации
Уровень автоматизации функций процесса обработки данных с учетом рациональности функциональной структуры программы с точки зрения взаимодействия с ней пользователя и использования вычислительных ресурсов
4.2 . Временная эффективность
Способность программы выполнять заданные действия в интервал времени, отвечающий заданным требованиям
Минимально необходимые вычислительные ресурсы и число обслуживающего персонала для эксплуатации ПС
5 . Показатели универсальности
Характеризуют адаптируемость ПС к новым функциональным требованиям, возникающим вследствие изменения области применения или других условий функционирования
Возможность использования ПС в различных областях применения
Возможность применения ПС без существенных дополнительных трудозатрат на ЭВМ аналогичного класса
Обеспечение простоты внесения необходимых изменений и доработок в программу в процессе эксплуатации
6 . Показатели корректности
Характеризуют степень соответствия ПС требованиям, установленным в ТЗ, требованиям к обработке данных и общесистемным требованиям
6.1 . Полнота реализации
Полнота реализации заданных функций ПС и достаточность их описания в программной документации
Однозначное, непротиворечивое описание и использование тождественных объектов, функций, терминов, определений, идентификаторов и т.д. в различных частях программных документов и текста программы
6.3 . Логическая корректность
Функциональное и программное соответствие процесса обработки данных при выполнении задания общесистемным требованиям
Полнота проверки возможных маршрутов выполнения программы в процессе тестирования
- первый уровень определяет группы показателей качества ПС, характеризующие потребительски-ориентированные свойства, которые соответствуют потребностям населения, народного хозяйства и экспорта продукции;
- второй уровень определен комплексными показателями качества ПС, характеризующими программно-ориентированные свойства, которые обеспечивают достижение требуемых потребительски-ориентированных свойств.
2.2 . Выбор номенклатуры показателей качества для конкретного ПС осуществляется с учетом его назначения и требований областей применения. В табл. 2 представлена рекомендуемая применяемость показателей качества в зависимости от принадлежности ПС к тому или иному подклассу (группе) в соответствии с общесоюзным классификатором продукции.
2.3 . Выбранная номенклатура показателей качества фиксируется в ТЗ на разработку ПС.
ГОСУДАРСТВЕННЫЙ СТАНДАРТ СОЮЗА ССР
ОЦЕНКА КАЧЕСТВА ПРОГРАММНЫХ СРЕДСТВ
Quality control of software systems. General principles
Дата введения 1990-07-01
1. РАЗРАБОТАН И ВНЕСЕН Министерством приборостроения, средств автоматизации и систем управления СССР
Ю.П.Галустян, канд. техн. наук; Н.Б.Гуляев, канд. техн. наук; А.П.Дувакин, канд. физ.-мат. наук; А.В.Катков; С.Л.Котов, В.П.Куприянов, канд. эконом. наук; В.П.Морозов, канд. эконом. наук; Е.В.Цальп, канд. техн. наук; Н.Н.Чихалов, канд. техн. наук; В.В.Шураков, д-р эконом. наук.
2. УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ постановлением Государственного комитета СССР по стандартам от 28.07.89 N 2507
3. ВВЕДЕН ВПЕРВЫЕ
4. ССЫЛОЧНЫЕ НОРМАТИВНО-ТЕХНИЧЕСКИЕ ДОКУМЕНТЫ
Обозначение НТД, на который дана ссылка
Настоящий стандарт, устанавливает общие положения по оценке качества программных средств вычислительной техники (далее - ПС), поставляемых через фонды алгоритмов и программ (ФАП), номенклатуру и применяемость показателей качества ПС.
Термины, применяемые в стандарте, и пояснения к ним приведены в приложении 1.
1. ОБЩИЕ ПОЛОЖЕНИЯ
1.1. Оценка качества осуществляется на всех этапах жизненного цикла ПС при:
планировании показателей качества ПС;
контроле качества на отдельных этапах разработки (техническое задание, технический проект, рабочий проект);
контроле качества в процессе производства ПС;
проверке эффективности модификации ПС на этапе сопровождения.
1.2. Оценка качества ПС представляет собой совокупность операций, включающих выбор номенклатуры показателей качества оцениваемого ПС, определение значений этих показателей и сравнение их с базовыми значениями.
1.3. Оценку качества проводят специалисты организаций:
разработчика - на этапах разработки ПС;
фондодержателя - на этапах приемки ПС в фонд;
испытательных центров и центров сертификации ПС - на этапах испытаний и внедрения;
изготовителя - на этапах тиражирования ПС;
пользователя - на этапах внедрения, сопровождения и эксплуатации ПС.
1.4. Основные задачи, решаемые при оценке качества ПС:
планирование уровня качества;
контроль значений показателей качества в процессе разработки и испытаний;
эксплуатационный контроль заданного уровня качества;
выбор базовых образцов по подклассам и группам;
методическое руководство разработкой нормативно-технических документов по оценке качества;
методическое руководство разработкой нормативно-технических документов по оценке качества.
1.5. Методы определения показателей качества ПС различаются:
по способам получения информации о ПС - измерительный, регистрационный, органолептический, расчетный;
по источникам получения информации - традиционный, экспертный, социологический.
1.5.1. Измерительный метод основан на получении информации о свойствах и характеристиках ПС с использованием инструментальных средств. Например, с использованием этого метода определяется объем ПС - число строк исходного текста программ и число строк - комментариев, число операторов и операндов, число исполненных операторов, число ветвей в программе, число точек входа (выхода), время выполнения ветви программы, время реакции и другие показатели.
1.5.2. Регистрационный метод основан на получении информации во время испытаний или функционирования ПС, когда регистрируются и подсчитываются определенные события, например, время и число сбоев и отказов, время передачи управления другим модулям, время начала и окончания работы.
1.5.3. Органолептический метод основан на использовании информации, получаемой в результате анализа восприятия органов чувств (зрения, слуха), и применяется для определения таких показателей, как удобство применения, эффективность и т.п.
1.5.4. Расчетный метод основан на использовании теоретических и эмпирических зависимостей (на ранних этапах разработки), статистических данных, накапливаемых при испытаниях, эксплуатации и сопровождении ПС. При помощи расчетного метода определяются длительность и точность вычислений, время реакции, необходимые ресурсы.
1.5.5. Определение значений показателей качества ПС экспертным методом осуществляется группой экспертов-специалистов, компетентных в решении данной задачи, на базе их опыта и интуиции.
Экспертный метод применяется в случаях, когда задача не может быть решена никаким другим из существующих способов или другие способы являются значительно более трудоемкими. Экспертный метод рекомендуется применять при определении показателей наглядности, полноты и доступности программной документации, легкости освоения, структурности.
1.5.6. Социологические методы основаны на обработке специальных анкет-вопросников.
2. НОМЕНКЛАТУРА ПОКАЗАТЕЛЕЙ КАЧЕСТВА ПРОГРАММНЫХ СРЕДСТВ
2.1. Номенклатура показателей качества и характеризуемые ими свойства программных средств приведены в табл.1, где представлены 2 уровня иерархической структуры показателей качества ПС:
Наименование групп и комплексных показателей качества
1. Показатели надежности ПС
Характеризуют способность ПС в конкретных областях применения выполнять заданные функции в соответствии с программными документами в условиях возникновения отклонений в среде функционирования, вызванных сбоями технических средств, ошибками во входных данных, ошибками обслуживания и другими дестабилизирующими воздействиями
1.1. Устойчивость функционирования
Способность обеспечивать продолжение работы программы после возникновения отклонений, вызванных сбоями технических средств, ошибками во входных данных и ошибками обслуживания
Способность программы функционировать в заданных режимах и объемах обрабатываемой информации в соответствии с программными документами при отсутствии сбоев технических средств
2. Показатели сопровождения
Характеризуют технологические аспекты, обеспечивающие простоту устранения ошибок в программе и программных документах и поддержания ПС в актуальном состоянии
Организация всех взаимосвязанных частей программы в единое целое с использованием логических структур "последовательность", "выбор", "повторение"
2.2. Простота конструкции
Построение модульной структуры программы наиболее рациональным с точки зрения восприятия и понимания образом
Наличие и представление в наиболее легко воспринимаемом виде исходных модулей ПС, полное их описание в соответствующих программных документах
Степень использования типовых проектных решений или компонентов, входящих в ПС
3. Показатели удобства применения
Характеризуют свойства ПС, способствующие быстрому освоению, применению и эксплуатации ПС с минимальными трудозатратами с учетом характера решаемых задач и требований к квалификации обслуживающего персонала
3.1. Легкость освоения
Представление программных документов и программы в виде, способствующем пониманию логики функционирования программы в целом и ее частей
3.2. Доступность эксплуатационных программных документов
Понятность, наглядность и полнота описания взаимодействия пользователя с программой в эксплуатационных программных документах
3.3. Удобство эксплуатации и обслуживания
Соответствие процесса обработки данных и форм представления результатов характеру решаемых задач
4. Показатели эффективности
Характеризуют степень удовлетворения потребности пользователя в обработке данных с учетом экономических, вычислительных и людских ресурсов
4.1. Уровень автоматизации
Уровень автоматизации функций процесса обработки данных с учетом рациональности функциональной структуры программы с точки зрения взаимодействия с ней пользователя и использования вычислительных ресурсов
4.2. Временная эффективность
Способность программы выполнять заданные действия в интервал времени, отвечающий заданным требованиям
Минимально необходимые вычислительные ресурсы и число обслуживающего персонала для эксплуатации ПС
5. Показатели универсальности
Характеризуют адаптируемость ПС к новым функциональным требованиям, возникающим вследствие изменения области применения или других условий функционирования
Возможность использования ПС в различных областях применения
Возможность применения ПС без существенных дополнительных трудозатрат на ЭВМ аналогичного класса
Обеспечение простоты внесения необходимых изменений и доработок в программу в процессе эксплуатации
6. Показатели корректности
Характеризуют степень соответствия ПС требованиям, установленным в ТЗ, требованиям к обработке данных и общесистемным требованиям
6.1. Полнота реализации
Полнота реализации заданных функций ПС и достаточность их описания в программной документации
Однозначное, непротиворечивое описание и использование тождественных объектов, функций, терминов, определений, идентификаторов и т.д. в различных частях программных документов и текста программы
6.3. Логическая корректность
Функциональное и программное соответствие процесса обработки данных при выполнении задания общесистемным требованиям
Полнота проверки возможных маршрутов выполнения программы в процессе тестирования
первый уровень определяет группы показателей качества ПС, характеризующие потребительски-ориентированные свойства, которые соответствуют потребностям населения, народного хозяйства и экспорта продукции;
второй уровень определен комплексными показателями качества ПС, характеризующими программно-ориентированные свойства, которые обеспечивают достижение требуемых потребительски-ориентированных свойств.
2.2. Выбор номенклатуры показателей качества для конкретного ПС осуществляется с учетом его назначения и требований областей применения. В табл.2 представлена рекомендуемая применяемость показателей качества в зависимости от принадлежности ПС к тому или иному подклассу (группе) в соответствии с общесоюзным классификатором продукции.
ГОСТ Р 56939-2016
НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ
РАЗРАБОТКА БЕЗОПАСНОГО ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
Information protection. Secure software development. General requirements
Дата введения 2017-06-01
Предисловие
1 РАЗРАБОТАН Закрытым акционерным обществом "Научно-производственное объединение "Эшелон" (ЗАО "НПО "Эшелон")
2 ВНЕСЕН Техническим комитетом по стандартизации ТК 362 "Защита информации"
4 ВВЕДЕН ВПЕРВЫЕ
5ПЕРЕИЗДАНИЕ. Октябрь 2018 г.
Введение
Ввиду возрастающей сложности информационных систем актуальными становятся угрозы безопасности информации, связанные с наличием уязвимостей программ (уязвимостей кода), используемых в составе информационных систем. Для защиты от такого рода угроз в настоящее время, как правило, используют комплекс мер, реализуемый в процессах функционирования (эксплуатации) и сопровождения программного обеспечения. В то же время для обеспечения необходимого уровня защиты информации требуется реализация мер, направленных на предотвращение появления и устранение уязвимостей программ в процессах жизненного цикла программного обеспечения, связанных с проектированием, реализацией и тестированием.
Настоящий стандарт направлен на достижение целей, связанных с предотвращением появления и/или устранением уязвимостей программ, и содержит перечень мер, которые рекомендуется реализовать на соответствующих этапах жизненного цикла программного обеспечения.
1 Область применения
Настоящий стандарт устанавливает общие требования к содержанию и порядку выполнения работ, связанных с созданием безопасного (защищенного) программного обеспечения и формированием (поддержанием) среды обеспечения оперативного устранения выявленных пользователями ошибок программного обеспечения и уязвимостей программы.
Настоящий стандарт предназначен для разработчиков и производителей программного обеспечения, а также для организаций, выполняющих оценку соответствия процесса разработки программного обеспечения требованиям настоящего стандарта.
2 Нормативные ссылки
В настоящем стандарте использованы нормативные ссылки на следующие стандарты:
ГОСТ 2.001 Единая система конструкторской документации. Общие положения
ГОСТ 19.101 Единая система программной документации. Виды программ и программных документов
ГОСТ 19.201 Единая система программной документации. Техническое задание. Требования к содержанию и оформлению
ГОСТ 19.402 Единая система программной документации. Описание программы
ГОСТ 19.404 Единая система программной документации. Пояснительная записка. Требования к содержанию и оформлению
ГОСТ Р ИСО 10007 Менеджмент организации. Руководящие указания по управлению конфигурацией
ГОСТ Р ИСО/МЭК 12207 Информационная технология. Системная и программная инженерия. Процессы жизненного цикла программных средств
ГОСТ Р ИСО/МЭК 27001 Информационная технология. Методы и средства обеспечения безопасности. Системы менеджмента информационной безопасности. Требования
ГОСТ Р ИСО/МЭК 27034-1 Информационная технология. Методы и средства обеспечения безопасности. Безопасность приложений. Часть 1. Обзор и общие понятия
Примечание - При пользовании настоящим стандартом целесообразно проверить действие ссылочных стандартов в информационной системе общего пользования - на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет или по ежегодному информационному указателю "Национальные стандарты", который опубликован по состоянию на 1 января текущего года, и по выпускам ежемесячного информационного указателя "Национальные стандарты" за текущий год. Если заменен ссылочный стандарт, на который дана недатированная ссылка, то рекомендуется использовать действующую версию этого стандарта с учетом всех внесенных в данную версию изменений. Если заменен ссылочный стандарт, на который дана датированная ссылка, то рекомендуется использовать версию этого стандарта с указанным выше годом утверждения (принятия). Если после утверждения настоящего стандарта в ссылочный стандарт, на который дана датированная ссылка, внесено изменение, затрагивающее положение, на которое дана ссылка, то это положение рекомендуется применять без учета данного изменения. Если ссылочный стандарт отменен без замены, то положение, в котором дана ссылка на него, рекомендуется применять в части, не затрагивающей эту ссылку.
3 Термины и определения
В настоящем стандарте применены следующие термины с соответствующими определениями:
безопасность информации: Состояние защищенности информации, при котором обеспечены ее конфиденциальность, доступность и целостность.
3.2 безопасное программное обеспечение: Программное обеспечение, разработанное с использованием совокупности мер, направленных на предотвращение появления и устранение уязвимостей программы.
3.3 динамический анализ кода программы: Вид работ по инструментальному исследованию программы, основанный на анализе кода программы в режиме непосредственного исполнения (функционирования) кода.
3.4 документация разработчика программного обеспечения: Совокупность программных документов, предназначенных для организации работ по созданию программного обеспечения, выполняемых в рамках процессов жизненного цикла программного обеспечения, и/или подтверждения соответствия требованиям настоящего стандарта.
Примечание - К программным относятся документы, содержащие сведения, необходимые для разработки, изготовления, сопровождения и эксплуатации программ.
инструментальное средство: Компьютерная программа, используемая как средство разработки, тестирования, анализа, производства или модификации других программ или документов на них.
компьютерная атака: Целенаправленное несанкционированное воздействие на информацию, на ресурс автоматизированной информационной системы или получение несанкционированного доступа к ним с применением программных или программно-аппаратных средств.
3.7 недостаток программы: Любая ошибка, допущенная в ходе проектирования или реализации программы, которая в случае ее неисправления может являться причиной уязвимости программы.
3.8 объект среды разработки программного обеспечения: Аппаратные средства, программы, программно-аппаратные средства и документы, используемые разработчиком для разработки программного обеспечения.
3.9 пользователь (программного обеспечения): Лицо, применяющее программное обеспечение или участвующее в деятельности, прямо или косвенно зависящей от функционирования данного программного обеспечения.
программа: Данные, предназначенные для управления конкретными компонентами системы обработки информации в целях реализации определенного алгоритма.
программное обеспечение: Совокупность программ системы обработки информации и программных документов, необходимых для эксплуатации этих программ.
сетевая атака: Компьютерная атака с использованием протоколов межсетевого взаимодействия.
3.13 система управления конфигурацией программного обеспечения: Совокупность процедур и инструментальных средств (включая их документацию), используемая разработчиком программного обеспечения для разработки и поддержки конфигураций программного обеспечения в течение его жизненного цикла.
среда разработки программного обеспечения: Интегрированная система, включающая в себя аппаратные средства, программное обеспечение, программно-аппаратные средства, процедуры и документы, необходимые для разработки программного обеспечения.
3.15 статический анализ исходного кода программы: Вид работ по инструментальному исследованию программы, основанный на анализе исходного кода программы с использованием специализированных инструментальных средств (статических анализаторов) в режиме, не предусматривающем реального выполнения кода.
3.16 тестирование на проникновение: Вид работ по выявлению (подтверждению) уязвимостей программы, основанный на моделировании (имитации) действий потенциального нарушителя.
угроза (безопасности информации): Совокупность условий и факторов, создающих потенциальную или реально существующую опасность нарушения безопасности информации.
3.18 управление конфигурацией программного обеспечения: Скоординированные действия, направленные на формирование и контроль конфигурации программного обеспечения.
Примечание - Управление конфигурацией обычно включает в себя поддержку технической и административной деятельности, связанной с управлением программным обеспечением и требованиями к его конфигурации на всех стадиях жизненного цикла создания программного обеспечения. Адаптировано из ГОСТ Р ИСО 10007.
3.19 уязвимость программы: Недостаток программы, который может быть использован для реализации угроз безопасности информации.
Примечание - Уязвимость программы может быть результатом ее разработки без учета требований по обеспечению безопасности информации или результатом наличия ошибок проектирования или реализации.
3.20 функциональное тестирование программы: Вид работ по исследованию программы, направленный на выявление отличий между ее реально существующими и требуемыми свойствами.
3.21 фаззинг-тестирование программы: Вид работ по исследованию программы, направленный на оценку ее свойств и основанный на передаче программе случайных или специально сформированных входных данных, отличных от данных, предусмотренных алгоритмом работы программы.
3.22 экспертиза исходного кода программы: Вид работ по выявлению недостатков программы (потенциально уязвимых конструкций) в исходном коде программы, основанный на анализе исходного кода программы в режиме, не предусматривающем реального выполнения кода.
3.23 электронный документ: Документ, выполненный программно-техническим средством на электронном носителе.
Читайте также: