Практические приемы оценки и повышения качества техдокументации по оценочным элементам фактора «надежность» согласно ГОСТ 28195-89. Материал входит в цикл статей «Качество технической документации». Редакция от 29.04.2021.
Создан 21.12.2011 15:00:44
В первой, вводной части статьи «Качество технической документации. Часть I»:
- рассмотрены общие проблемы качества технической документации;
- определен круг специалистов, заинтересованных в четких и прозрачных инструкциях по оценке качества техдокументации;
- обосновано применение ГОСТ 2.105, ГОСТ 19.106-78, ГОСТ 28195-89 и ГОСТ 8.417-2002 при оценке качества техдокументации.
В настоящей и последующих статьях будут освещены практические приемы оценки качества техдокументации (проанализированы критерии оценки), показаны подходы к «автоматическому» повышению качества технической документации, т.е. как разрабатывать документацию таким образом, чтобы качество ее по умолчанию было предопределенным и буквально «зашкаливало» по подходящим оценочным критериям ГОСТ 28195-89, а также соответствовало требованиям ГОСТ 2.105, ГОСТ 19.106-78 и ГОСТ 8.417-2002.
Оценочные элементы фактора «надежность ПС»
Итак, обратимся к первоисточнику — ГОСТ 28195-89, а именно к таблице 5.
Таблица 5 — Оценочные элементы фактора «надежность ПС» (немного изменена)
|
Код элемента |
Наименование |
Метод оценки |
Оценка |
|
Средства восстановления при ошибках на входе |
|||
|
Н0101 |
Наличие требований к программе по устойчивости функционирования при наличии ошибок во входных данных |
Экспертный |
0-1 |
|
Н0102 |
Возможность обработки ошибочных ситуаций |
То же |
0-1 |
|
Н0103 |
Полнота обработки ошибочных ситуаций |
» |
0-1 |
|
Н0104 |
Наличие тестов для проверки допустимых значений входных данных |
» |
0-1 |
|
Н0105 |
Наличие системы контроля полноты входных данных |
» |
0-1 |
|
Н0106 |
Наличие средств контроля корректности входных данных |
» |
0-1 |
|
Н0107 |
Наличие средств контроля непротиворечивости входных данных |
» |
0-1 |
|
Н0108 |
Наличие проверки параметров и адресов по диапазону их значений |
» |
0-1 |
|
Н0109 |
Наличие обработки граничных результатов |
» |
0-1 |
|
Н0110 |
Наличие обработки неопределенностей (деление на 0, квадратный корень из отрицательного числа и т.д.) |
» |
0-0-11 |
|
Средства восстановления при сбоях оборудования |
|||
|
Н0201 |
Наличие требований к программе по восстановлению процесса выполнения в случае сбоя операционной системы, процессора, внешних устройств |
» |
0-1 |
|
Н0202 |
Наличие требований к программе по восстановлению результатов при отказах процессора, ОС |
» |
0-1 |
|
Н0203 |
Наличие средств восстановления процесса в случае сбоев оборудования |
» |
0-1 |
|
Н0204 |
Наличие возможности разделения по времени выполнения отдельных функций программ |
» |
0-1 |
|
Н0205 |
Наличие возможности повторного старта с точки останова |
» |
|
|
Реализация управления средствами восстановления |
|||
|
Н0301 |
Наличие централизованного управления процессами, конкурирующими из-за ресурсов |
» |
0-1 |
|
Н0302 |
Наличие возможности автоматически обходить ошибочные ситуации в процессе вычисления |
» |
0-1 |
|
Н0303 |
Наличие средств, обеспечивающих завершение процесса решения в случае помех |
» |
0-1 |
|
Н0304 |
Наличие средств, обеспечивающих выполнение программы в сокращенном объеме в случае ошибок или помех |
» |
0-1 |
|
Н0305 |
Показатель устойчивости к искажающим воздействиям |
Расчетный |
P(Y) = 1 -D/K, |
|
Функционирование в заданных режимах |
|||
|
Н0401 |
Вероятность безотказной работы |
То же |
P = 1 — Q/N, |
|
Обеспечение обработки заданного объема информации |
|||
|
Н0501 |
Оценка по среднему времени восстановления |
» |
где Твдоп — допустимое среднее время восстановления; |
|
Н0502 |
Оценка по продолжительности преобразования входного набора данных в выходной |
Расчетный |
где — допустимое время преобразования i-го входного набора данных; |
Примечание — Здесь и далее требования в оценочных элементах будут применяться все больше к техническому заданию на автоматизированную систему, поскольку:
- ТЗ на АС наиболее востребованы на текущий момент, да и оценки часто касаются именно требований;
- на примере ТЗ можно с максимумом наглядности показать способы достижения того самого предопределенного качества документа, о котором упоминалось выше.
Всяческие «фазы» и «этапы» можно смело проигнорировать — в ходе дальнейшего повествования станет понятно, почему именно.
Средства восстановления при ошибках на входе
Наличие требований к программе по устойчивости функционирования при наличии ошибок во входных данных
«Наличие… при наличии…» 😉
Чтобы получить у эксперта заветный кол (единичку), достаточно прописать в подразделе «Требования к надежности программного обеспечения» технического задания что-то такое: «ПО (или программа) должно (должна) обеспечивать устойчивость функционирования при наличии ошибок во входных данных». Как это требование будет реализовано в ходе проектирования — дело стодвадцатьпятое. В данном случае руководствуемся только формальным требованием наличия требования — «…требованием… требования…» 🙄
Возможность обработки ошибочных ситуаций
Единичка зарабатывается способом, аналогичным предыдущему.
Полнота обработки ошибочных ситуаций
Полнота обработки ошибочных ситуаций — в документах должен быть приведен полный перечень ошибочных ситуаций. Если предусмотрена обработка всех ошибочных ситуаций, то полноту обработки можно считать 100-процентной.
Наличие тестов для проверки допустимых значений входных данных
Критерий звучит несколько старообразно. Сейчас, когда практически все программы оснащены графическим интерфейсом пользователя, допустимые значения входных данных, вводимых пользователем в диалоговом или интерактивном режиме, проходят форматно-логический контроль.
Контроль формата ввода данных: программа позволяет пользователю вводить дату только в формате ДД.ММ.ГГГГ, но не в ГГГГ/ММ/ДД и ни в каком ином. Логический контроль: дата окончания школы не может быть введена БОЛЕЕ ранней, нежели чем дата поступления в школу 😎
О форматно-логическом контроле следует упомянуть где-нибудь в подразделе Требования к лингвистическому обеспечению или создать дополнительный подраздел «Требования к интерфейсу пользователя» в техническом задании.
Наличие системы контроля полноты входных данных
Полнота входных данных достигается применением обязательных полей ввода данных в графическом интерфейсе пользователя. Обязательные поля отмечены звездочками, см. рисунок ниже.
Наличие средств контроля корректности входных данных
См. выше. Корректность входных данных, помимо применения форматно-логического контроля, можно обеспечить путем выбора пользователем данных из календарей, выпадающих списков, словарей и т.д., см. рисунок ниже.
Наличие средств контроля непротиворечивости входных данных
Опять-таки форматно-логический контроль, см. Наличие тестов для проверки допустимых значений входных данных. Повторимся: если дату поступления в ВУЗ можно ввести в соответствующее поле более ранней по сравнению с датой поступления в среднюю школу, то налицо логическое противоречие. Потому и необходимы средства контроля непротиворечивости.
Наличие проверки параметров и адресов по диапазону их значений
Требование по проверке параметров можно добавить в техническое задание, проверкой адресов, если речь идет об адресе команды или адресе в пространстве памяти, занимается любая операционная система.
Наличие обработки граничных результатов
Прокомментировать данное требование представляется пока затруднительным.
Наличие обработки неопределенностей (деление на 0, квадратный корень из отрицательного числа и т.д.)
В языках высокого уровня, применяемых повсеместно, присутствует встроенная обработка неопределенностей — поддержка исключительных ситуаций (Exception handling). В техническом задании на АС имеется подраздел Требования к лингвистическому обеспечению, в котором и задаются требования ко всевозможным языкам. В ТЗ на ПО для этого придуман подраздел Требования к информационной и программной совместимости.
Средства восстановления при сбоях оборудования
Наличие требований к программе по восстановлению процесса выполнения в случае сбоя операционной системы, процессора, внешних устройств
Наличие требований к программе по восстановлению процесса выполнения в случае сбоя операционной системы, процессора, внешних периферийных устройств — данные требования следует добавить в п. Перечень аварийных ситуаций, по которым должны быть регламентированы требования к надежности, значения соответствующих показателей технического задания.
Наличие требований к программе по восстановлению результатов при отказах процессора, ОС
По аналогии с предыдущим требованием. При отказах (зависаниях, а не крахах) операционной системы часто применяется интересная штука: на какой-нибудь из портов ПЭВМ или сервера «подвешивается» некое устройство, периодически опрашивающее порт. Если порт в течение некоторого времени не отзывается, устройство просто перезагружает компьютер с восстановлением ранее загруженных и выполнявшихся программ.
Наличие средств восстановления процесса в случае сбоев оборудования
То же. Только не оборудования, а технических средств.
Наличие возможности разделения по времени выполнения отдельных функций программ
Наличие возможности разделения по времени выполнения отдельных функций программ — в техническом задании на автоматизированную систему есть соответствующий подраздел Требования к функциям (задачам), выполняемым системой, в котором имеется соответствующий пункт. В ТЗ на ПО имеется подраздел Требования к функциональным характеристикам, содержащий пункт о характеристиках временных.
Наличие возможности повторного старта с точки останова
Хитрое требование. В стародавние времена применялся принцип мажоритарного резервирования, когда одну и ту же программу выполняли одновременно три микроконтроллера. В силу временных погрешностей (даже при применении одного кварцевого резонатора) каждый из микроконтроллеров выходил в точку останова в разное время (разница была незначительной — какие-нибудь наносекунды — но тем не менее). В момент времени, когда самый медленный контроллер попадал в точку останова, вся компания дружно обменивалась между собой некими данными и, если они были идентичны, выполнялся старт с точки останова. Таким образом обеспечивалась высочайшая надежность, а заодно и синхронизация.
Сейчас точкой останова можно считать момент времени, когда программа находится в режиме ожидания. К примеру, когда запускается тот же Microsoft™ Word, он завершает все свои инициализационные процедуры, после чего выходит на точку останова — ждет ввода данных пользователем.
Реализация управления средствами восстановления
Наличие централизованного управления процессами, конкурирующими из-за ресурсов
Централизованное управление процессами, конкурирующими из-за ресурсов, встроено во все применяемые ныне операционные системы. Требования к операционным системам, входящим в состав общего программного обеспечения, расписываются в подразделе Требования к программному обеспечению технического задания.
Наличие возможности автоматически обходить ошибочные ситуации в процессе вычисления
См. Наличие требований к программе по устойчивости функционирования при наличии ошибок во входных данных.
Наличие средств, обеспечивающих завершение процесса решения в случае помех
Не совсем ясно, что считать помехами? Если это какие-нибудь электромагнитные помехи или внешние воздействующие факторы по ГОСТ 26883-86, то следует озвучить заданное требование в техническом задании, а в подразделе Требования к защите от влияния внешних воздействий указать предельные их уровни, например «…соответствие нормам индустриальных помех для оборудования класса А согласно ГОСТ Р 51318.22 (СИСПР 22-97)».
Наличие средств, обеспечивающих выполнение программы в сокращенном объеме в случае ошибок или помех
По аналогии с предыдущим пунктом.
Показатель устойчивости к искажающим воздействиям
Не рассматривается, как экспериментальный.
Функционирование в заданных режимах
Вероятность безотказной работы
См. выше.
Обеспечение обработки заданного объема информации
Оценка по среднему времени восстановления
См. выше.
Оценка по продолжительности преобразования входного набора данных в выходной
См. выше.
Выводы по II части статьи
Примечание — Четыре крайних элемента таблицы не учитывались, поскольку речь в них идет об экспериментах, которые проведены быть не могут до испытаний.
Итак, казалось бы, оценочные факторы надежности должны применяться к программному средству, а фактически, причем вполне обоснованно и справедливо, они были применены к техническому заданию, т.е. к документу, и определили его качество. В сумме ТЗ (в части надежности) получило 17 баллов из 23-х возможных, что есть 73,9 %, если подходить формально. Если не учитывать четыре крайних элемента, то процентное соотношение будет составлять 94,4.
Мораль: при развернутой формулировке оценочных элементов в виде требований технического задания сам документ «автоматически» получит наивысшую экспертную оценку, что крайне важно при проведении конкурсных разработок.
Определяемый
ГОСТом показатель качествавключает
наряду с факторомнадёжности факторы сопровождаемости,
удобства применения, эффективности,
универсальности (гибкости) и корректности.
Результатом оценки фактора надёжности
является число от нуля до единицы,
близость к единице которого показывает
степень надёжности данного программного
средства. На практике хорошим
считается результат оценки от 0,5 до 0,9,
поскольку 1 – это идеальная надежность
(недостижима), ниже 0,5 –недостаточная.
В соответствии с
[14]
надёжность – способность программных
средств в конкретных областях применения
выполнять заданные функции в соответствии
с программными документами в условиях
возникновения отклонения в среде
функционирования, вызванных сбоями
технических средств, ошибками во входных
данных, ошибками обслуживания и другими
дестабилизирующими воздействиями.
Сам фактор надёжности
включает в себя два критерия:
-
устойчивость
функционирования –
способность
обеспечивать продолжение работы
программы после возникновения отклонений,
вызванных сбоями технических средств,
ошибками во входных данных и ошибками
обслуживания;
-
работоспособность
–
способность
программы функционировать в заданных
режимах и объёмах обрабатываемой
информации в соответствии с программными
документами при отсутствии сбоев
технических средств.
Оценка каждого из
критериев включает в себя оценки так
называемых метрик:
|
для критерияустойчивости |
|
|
для критерия |
В своей оценке
каждая из метрик содержит оценки так
называемых оценочных элементов. Каждый
оценочный элемент обозначается кодом,составленным из 5 символов
(см. рис. 4.2).
|
|
|
Рис.4.2 |
В таблице 4.1 описаны
используемые оценочные
элементы, их значениеи
методы оценки.
|
Таблица |
|||
|
Код |
Наименование |
Метод |
Оценка |
|
H0101 |
Наличие требований |
Экспертный |
0 |
|
H0102 |
Возможность |
« |
0 |
|
H0103 |
Полнота обработки |
« |
0 |
|
H0104 |
Наличие тестов |
« |
0 |
|
H0105 |
Наличие системы |
« |
0 |
|
H0106 |
Наличие средств |
« |
0 |
|
Продолжение |
|||
|
H0107 |
Наличие средств |
Экспертный |
0 |
|
H0108 |
Наличие проверки |
« |
0 |
|
H0109 |
Наличие обработки |
« |
0 |
|
H0110 |
Наличие обработки |
« |
0 |
|
H0201 |
Наличие требований |
« |
0 |
|
H0202 |
Наличие требований |
« |
0 |
|
H0203 |
Наличие средств |
« |
0 |
|
H0204 |
Наличие возможности |
« |
0 |
|
H0205 |
Наличие возможности |
« |
0 |
|
H0301 |
Наличие |
« |
0 |
|
H0302 |
Наличие возможности |
« |
0 |
|
H0303 |
Наличие средств, |
« |
0 |
|
Продолжение |
|||
|
H0304 |
Наличие средств, |
Экспертный |
0 |
|
H0305 |
Показатель |
Расчёт ный |
|
|
где |
D – |
число экспериментов, |
|
|
К – |
число экспериментов, |
||
|
H0401 |
Вероятность |
Расчёт ный |
|
|
где |
Q – |
число |
|
|
N — |
число экспериментов |
||
|
H0501 |
Оценка по среднему |
Расчёт ный |
|
|
|
|||
|
где |
|
допустимое |
|
|
|
среднее время |
||
|
|
|||
|
где |
N |
число восстановлений |
|
|
|
время |
||
|
H0502 |
Оценка по |
Расчёт ный |
|
|
|
|||
|
где |
|
допустимое |
|
|
|
фактическая |
В зависимости от
фазы проектирования фактор надёжности
включает в себя различное количество
показателей. На этапе анализа рассчитывается
только критерий устойчивости
функционирования, включающий в себя
только две метрики: средства восстановления
при ошибках при входе и средства
восстановления при сбоях оборудования.
На этапе проектирования добавляется
ещё метрика реализации управления
средствами восстановления.
На фазах реализации, тестирования,
изготовления, обслуживания(сопровождения)
начинает учитываться критерий
работоспособности и все его метрики.
В соответствие с
приведённым в [14] порядком
расчёта фактора надёжности можно
составить схему технологии оценки
надёжности программного средства(ПС)
(см. рис. 4.3).
-
Рис.
4.3 Порядок расчета надежности .
Оценим
надежность разработанного программного
продукта,выбрав в качестве фазысоздания ПС, на которой
производится расчёт, фазу реализации
и тестирования:
-
Определяются
оценочные элементы используемых метрик
(см. таб. 4.2).Таблица
4.2. Определение оценочных элементов.Код
оценочного элементаВыбранное
значениеОбоснование
H0101
0,1
Ввиду
того, что проект находится на ранней
стадии развития, особых требований
по устойчивости функционирования не
предъявлено. Учитываются лишь самые
общие, отсюда и низкий показатель.H0102
0,8
Возможность
обработки ошибок в разработанной
программе реализована.H0103
0,8
Проверка
на ошибку происходит в каждой точке
обращения к базе данных и другим
компонентам программы, что обеспечивают
высокую полноту.H0104
0,8
Проверку
допустимых значений входных данных
осуществляет сервер базы данных.H0105
0,8
Проверку
допустимых значений и контроль входных
данных осуществляет сервер базы
данных.H0106
0,9
Осуществляется
сервером базы данных.H0107
0,9
Осуществляется
программой и сервером базы данных.H0108
0,6
Частично
реализована в базе данных.H0109
0,5
Не
требуется в силу специфики проекта.H0110
1
Встроена
в стандартные компоненты, обеспечивается
автоматически.H0201
0,1
Оборудование
считается достаточно надёжным, чтоб
не предъявлять такие требования.
Частично обеспечивается операционной
системой.H0202
0,9
Система
является самовосстанавливающейся,
при сбоях оборудования все данные
сохраняются.H0203
0,8
То
же.H0204
0,5
Частично
реализуется сервером базы данных, а
также ОС в силу её многозадачности.H0205
0
Отсутствует.
H0301
0,9
Таких
процессов практически нет, реализуется
операционной системой и достаточностью
ресурсов.H0302
0,6
Частично
реализовано в рамках обработки ошибок.H0303
0,9
Реализована
на уровне стандартных компонент и ОС
при критических ошибках.H0304
0
Отсутствует.
H0305
0,8
Нормальный.
H0401
0,8
Нормальная.
H0501
1
Достаточная.
H0502
1
Достаточная.
-
По полученным
значениям оценочных элементов
рассчитываются задействованные согласно
данной фазе проектирования метрики
(см. таб. 4.3).
Итоговая
оценка k-й
метрики j-го
критерия ведется по формуле:
|
|
(4.1) |
||
|
где |
Q |
число |
|
|
|
оценка |
||
|
Таблица |
|||
|
Метрики |
Оценки |
||
|
1 |
Средства |
0,72 |
|
|
2 |
Средства |
0,46 |
|
|
3 |
Реализация |
0,64 |
|
|
4 |
Функционирование |
0,8 |
|
|
5 |
Обеспечение |
1 |
-
Выбор весового
коэффициента для каждой метрики (см.
таб. 4.4).
Он определяет
значимость этой метрики для дальнейшего
расчёта. Для каждого критерия сумма
весов входящих в него метрик должна
равняться единице.
|
Таблица |
||
|
№ |
Весовой |
Обоснование |
|
1 |
0,5 |
Имеет |
|
2 |
0,3 |
Требуется |
|
3 |
0,2 |
Имеет |
|
4 |
0,6 |
Важности |
|
5 |
0,4 |
Имеет |
-
Нахождение
абсолютных показателей критериев i-го
фактора качества (надёжности) (см.
таб.4.5) ведется по формуле:(4.2)
где
n
—число
метрик, относящихся к j-тому
критерию—
весовые
коэффициенты метрикТаблица
4.5. Абсолютные показатели критериев
надежности.Критерий
Оценка
1
Устойчивость
функционирования0,31784
2
Работоспособность
0,88
-
Расчёт относительных
показателей критериев i-го
фактора качества (см. таб. 4.6) ведется
по формуле:
|
|
(4.3) |
Относительные
показатели критериев определяются
отношением абсолютных показателей
критериев данного образца к абсолютным
показателям критериев базового образца.
Показатели базового образца
выбираются экспертами в соответствии
со значениями показателей, отражающих
современный уровень и прогнозируемый
мировой. Поскольку техническая
информация о характеристиках подобных
программ, которые имеются лишь за
рубежом, отсутствует, базовые показатели
критериеввозьмем равными
единице, то естьидеалу.
-
Выбор весового
коэффициента для каждого критерия
(см.таб. 4.6).
Как и для метрик,
весовой коэффициент определяет значимость
данногокритерия для
дальнейшего расчёта. Сумма весов должна
равняться единице
|
Таблица |
||
|
№ |
Коэффициент |
Обоснование |
|
1 |
0,4 |
В силу достаточной |
|
2 |
0,6 |
-
Оценка фактора
качества надёжность.
Фактор качества
вычисляется по формуле:
|
|
(4.4) |
|
|
где |
N |
число |
|
|
весовые |
Получили
.Как видно, надёжность данной программы
удовлетворяет требованиям.Однакоследует учесть, что в значения
относительныхкритериевпринимались
равнымиабсолютным значениям
(значения базовых критериев
приравнивались к единице, или идеалу,
что на самом деле невозможно, а потому
не совсем корректно).Если
значения базовых критериев отличной
программы оценить равными 0,9, то фактор
надёжности нашей программы повысится
до
.
Соседние файлы в папке DIPLOM4
- #
- #
Подборка по базе: Аналитический отчет_уч_нач_классов.docx, Основы анализа бухгалтерской отчетности.docx, бухгалтерская финансовая отчетность в9.odt, Реферат бух учет и отчетность.docx, Краткий отчет.pdf, рубцов отчет.docx, 28131 Отчет по практике до 13.06 Синергия.docx, Пример отчета (1).docx, ЛР1 Отчёт ЭПУС.docx, Зеленских Шаблон на отчет по преддипломной практике.doc
Министерство науки и высшего образования Российской федерации
Федеральное государственное автономное образовательное учреждение
высшего образования
«ЮЖНЫЙ ФЕДЕРАЛЬНЫЙ УНИВЕРСИТЕТ»
(ФГАОУ ВО «ЮФУ»)
Институт компьютерных технологий и информационной безопасности
Кафедра математического обеспечения и применения ЭВМ
Отчет по лабораторной работе №1
«Оценка качественных показателей программного продукта»
по дисциплине «Качество и тестирование программного обеспечения»
по модулю «Метрология программного обеспечения»
Выполнили:
студенты гр. КТбо2-7
Савосин Д.А.
Костылев А.В.
Проверил:
старший преподаватель кафедры МОП ЭВМ
Проскуряков A.В.
Таганрог 2022
Оглавление
1ЦЕЛЬ РАБОТЫ 3
2ТЕХНИЧЕСКОЕ ЗАДАНИЕ 3
3ВЫПОЛНЕНИЕ РАБОТЫ 4
3.1.1Надежность ПО 5
3.1.2Сопровождаемость 6
3.1.3Корректность 7
3.1.4Универсальность/гибкость. 8
4Вывод 10
5Приложение 11
- ЦЕЛЬ РАБОТЫ
Научиться проводить оценку качества программного средств по различным показателям. В лабораторной работе тестируем и оцениваем качественные показатели ПП.
- ТЕХНИЧЕСКОЕ ЗАДАНИЕ
В лабораторной работе необходимо выполнить следующее:
1. Выбрать показатели качества (не менее 5) и сформулировать их сущность. Каждый показатель должен быть существенным, т. e. Должны быть ясны потенциальные выгоды его использования. Показатели представить в виде таблицы (таблица 1);
| Показатели качества | Сущность показателя | Экспертная оценка (вес) wi | Оценка, установленная экспериментом ri |
2. Установить веса показателей wi (∑wi =1);
3. Для каждого показателя установить конкретную численную оценку ri от 0 до 1, исходя из следующего:
0 – свойство в ПП присутствует, но качество его неприемлемо;
0.5 — 1 – свойство в ПП присутствует и обладает приемлемым качеством;
1 – свойство в ПП присутствует и обладает очень высоким качеством.
Возможно, присвоение промежуточных значений в соответствии с мнением оценивающего лица относительно полезности того или иного свойства ПП.
Результатом выполнения данной работы является отчет об оценке качества ПП, оформленный по требованиям ОС 6.1-97.
-
Задание на лабораторную работу
- Разработать собственный калькулятор;
- Сравнить два программных продукта (ПП): калькулятор фирмы Microsoft и калькулятор, написанный студентами. Сравнение проводить по следующим оценочным элементам: надежность программного средства (ПС), сопровождаемость, корректность, гибкость.
- ВЫПОЛНЕНИЕ РАБОТЫ
Исходный программный продукт, взятый за основу. Калькулятор фирмы Microsoft представлен на рисунке 1:
Рис.1 Калькулятор фирмы Microsoft
Разработанный в процессе выполнения лабораторной работы калькулятор. Данный калькулятор разработан в среде C# представлен на рисунке 2:
Рис.2 Калькулятор на Python
-
Сравнение по оценочным элементам
Сравнение программных продуктов по оценочным элементам:
-
Надежность ПО
Характеризует способность ПО в конкретных областях применения выполнять заданные функции в соответствии с программными документами в условиях возникновения отклонений в среде функционирования, вызванных сбоями технических средств, ошибками во входных данных, ошибками обслуживания и другими дестабилизирующими воздействиями.
Оценочные элементы фактора «Надежность ИС»:
| Код элемента | наименование | Метод оценки | Оценка калькулятора Microsoft | Оценка калькулятора |
| Н0101 | Наличие требований к программе по устойчивости функционирования при наличии ошибок во входных данных | экспертный | 1 | 1 |
| Н0102 | Возможность обработки ошибочных ситуаций | экспертный | 1 | 1 |
| Н0103 | Полнота обработки ошибочных ситуаций | экспертный | 1 | 0 |
| Н0104 | Наличие тестов для проверки допустимых значений входных данных | экспертный | 1 | 0 |
| Н0105 | Наличие системы контроля полноты входных данных | экспертный | 0 | 0,5 |
| Н0106 | Наличие средств контроля корректности входных данных | экспертный | 1 | 0,5 |
| Н0201 | Наличие требований к программе по восстановлению процесса выполнения в случае сбоя операционной системы, процессора внешних устройств | экспертный | 1 | 0 |
| Н0202 | Наличие требований к программе по восстановлению результатов при отказах процессора и операционной системы | экспертный | 1 | 0 |
| Н0203 | Наличие средств восстановления процессора в случае сбоев оборудования | экспертный | 1 | 0 |
| Н0205 | Наличие возможности повторного старта с точки прерывания | экспертный | 0 | 0 |
| Н0110 | Наличие обработки неопределенностей | экспертный | 1 | 0 |
| Н0301 | Наличие централизованного управления процессами, конкурирующими из-за ресурсов | экспертный | 1 | 0 |
| Н0302 | Наличие возможности автоматически обходить ошибочные ситуации в процесса вычисления | экспертный | 0 | 0 |
| всего | 10 | 3 |
-
Сопровождаемость
Характеризует технологические аспекты, обеспечивающие простоту устранения ошибок в ПО и программных документах и поддержания ПО в актуальном состоянии.
Оценочные элементы фактора «сопровождаемость»
| Код элемента | наименование | Метод оценки | Оценка калькулятора Microsoft | Оценка калькулятора |
| С0803 | Наличие комментариев в точках входа и выхода программы | экспертный | 0 | 0 |
| С0303 | Осуществляется ли передача результатов работы модуля через вызывающий его модуль | экспертный | 0 | 0 |
| С0604 | Оценка программы по числу циклов | экспертный | 0 | 0 |
| С1001 | Используется ли язык высокого уровня | экспертный | 1 | 1 |
| С0301 | Наличие проверки корректности передаваемых данных | экспертный | 0 | 0 |
| С0601 | Использование при построении программ метода структурного программирования | экспертный | 1 | 1 |
| С0602 | Соблюдение принципа разработки программы сверху вниз | экспертный | 1 | 0 |
| С0201 | Наличие ограничений на размеры модуля | экспертный | 0 | 0 |
| С0101 | Наличие модульной схемы программы | экспертный | 1 | 0 |
| всего | 4 | 2 |
-
Корректность
Характеризует степень соответствия ПО требованиям, установленным в техническом задании, требованиям к обработке данных и общесистемным требованиям.
Оценочные элементы фактора «корректность»
| Код элемента | наименование | Метод оценки | Оценка калькулятора Microsoft | Оценка калькулятора |
| К0101 | Наличие всех необходимых документов для понимания и использования ПС | экспертный | 1 | 0 |
| К0102 | Наличие описания и схемы иерархии модулей программы | экспертный | 0 | 0 |
| К0103 | Наличие описания основных функций | экспертный | 1 | 1 |
| К0104 | Наличие описания частных функций | экспертный | 1 | 1 |
| К0105 | Наличие описания данных | экспертный | 0 | 0 |
| К0106 | Наличие описания алгоритмов | экспертный | 0 | 0 |
| К0107 | Наличие описания интерфейсов между модулями | экспертный | 0 | 0 |
| К0111 | Наличие описания всех параметров | экспертный | 0 | 0 |
| К0112 | Наличие описания методов настройки системы | экспертный | 0 | 0 |
| К0114 | Наличие описания способов проверки работоспособности программы | экспертный | 0 | 0 |
| К0201 | Реализация всех исходных модулей | экспертный | 1 | 0.5 |
| К0202 | Реализация всех основных функций | экспертный | 1 | 0.5 |
| К0203 | Реализация всех частных алгоритмов | экспертный | 1 | 0.5 |
| К0204 | Реализация всех алгоритмов | экспертный | 1 | 0.5 |
| К0209 | Наличие определения всех данных; переменные, индексы, массивы и пр. | экспертный | 0 | 1 |
| К0210 | Наличие интерфейсов с пользователем | экспертный | 1 | 1 |
| К401 | Отсутствие противоречий в выполнении основных функций | 1 | 1 | |
| К402 | Отсутствие противоречий в выполнении частных функций | экспертный | 1 | 1 |
| К0403 | Отсутствие противоречий в выполнении алгоритмов | экспертный | 1 | 1 |
| К0404 | Правильность взаимосвязей | экспертный | 1 | 1 |
| К0406 | Правильность реализации интерфейса с пользователем | экспертный | 1 | 1 |
| К0407 | Отсутствие противоречий в настройке системы | экспертный | 1 | 1 |
| К0701 | Комплектность документации в соответствии со стандартами | экспертный | 1 | 0 |
| всего | 15 | 12 |
-
Универсальность/гибкость.
Характеризует адаптируемость ПО к новым функциональным требованиям, возникающим вследствие изменения области применения или других условий функционирования;
Оценочные элементы фактора «гибкость»
| Код элемента | наименование | Метод оценки | Оценка калькулятора Microsoft | Оценка калькулятора |
| Г1208 | Наличие общих комментариев к программам | экспертный | 0 | 1 |
| Г1301 | Использование языков высокого уровня | экспертный | 1 | 1 |
| Г1302 | Семантика имен используемых переменных | экспертный | 1 | 1 |
| Г1303 | Использование отступов, сдвигов и пропусков при формировании текста | экспертный | 1 | 1 |
| Г0803 | Зависимость от других программных средств | экспертный | 0 | 0 |
| Г0101 | Оценка числа потенциальных пользователей | экспертный | 1 | 0 |
| Г0201 | Наличие схемы иерархии модулей программы | экспертный | 0 | 0 |
| Г0202 | Оценка независимости модулей | экспертный | 1 | 1 |
| Г0402 | Наличие описания структуры программ | экспертный | 0 | 0 |
| Г0802 | Оценка зависимости программы от программ операционной системы | экспертный | 1 | 1 |
| всего | 6 | 6 |
-
Оценка качества
Проведём расчёт по формуле, которая дана в ТЗ, для оценивания качества каждого оценочного элемента, рассмотренных ранее для калькулятора Microsoft и разработанного нами калькулятора.
Формула:
Оценки качества по следующим оценочным элементам: надежность программного средства (ПС), сопровождаемость, корректность, гибкость:
| Калькулятор Microsoft | Разработанный калькулятор | ||||
| KНM = | 10 | KНР = | 3 | ||
| 13 | 13 | ||||
| KСM = | 4 | KСР = | 2 | ||
| 9 | 9 | ||||
| KКM = | 15 | KКР = | 12 | ||
| 23 | 23 | ||||
| KГM = | 6 | KГР = | 6 | ||
| 10 | 10 | ||||
| KМ= | 33178 | KР= | 21188 | ||
| 13455 | 13455 |
- Вывод
Калькулятор, разработанный в процессе выполнения лабораторной работы, немного уступает калькулятору, разработанному фирмой Microsoft и нуждается в небольшой доработке.
- Приложение
from tkinter import *
from decimal import *
root = Tk()
root.title(‘Calculator’)
buttons = ((‘7’, ‘8’, ‘9’, ‘/’, ‘4’),
(‘4’, ‘5’, ‘6’, ‘*’, ‘4’),
(‘1’, ‘2’, ‘3’, ‘-‘, ‘4’),
(‘0’, ‘.’, ‘=’, ‘+’, ‘4’)
)
activeStr = »
stack = []
# Функция вычисления
def calculate():
global stack
global label
result = 0
operand2 = Decimal(stack.pop())
operation = stack.pop()
operand1 = Decimal(stack.pop())
if operation == ‘+’:
result = operand1 + operand2
if operation == ‘-‘:
result = operand1 — operand2
if operation == ‘/’:
result = operand1 / operand2
if operation == ‘*’:
result = operand1 * operand2
label.configure(text=str(result))
# Функция обработки нажатий
def click(text):
global activeStr
global stack
if text == ‘CE’:
stack.clear()
activeStr = »
label.configure(text=’0′)
elif ‘0’ <= text <= ‘9’:
activeStr += text
label.configure(text=activeStr)
elif text == ‘.’:
if activeStr.find(‘.’) == -1:
activeStr += text
label.configure(text=activeStr)
else:
if len(stack) >= 2:
stack.append(label[‘text’])
calculate()
stack.clear()
stack.append(label[‘text’])
activeStr = »
if text != ‘=’:
stack.append(text)
else:
if text != ‘=’:
stack.append(label[‘text’])
stack.append(text)
activeStr = »
label.configure(text=’0′)
label = Label(root, text=’0′, width=35)
label.grid(row=0, column=0, columnspan=4, sticky=»nsew»)
button = Button(root, text=’CE’, command=lambda text=’CE’: click(text))
button.grid(row=1, column=3, sticky=»nsew»)
for row in range(4):
for col in range(4):
button = Button(root, text=buttons[row][col],
command=lambda row=row, col=col: click(buttons[row][col]))
button.grid(row=row + 2, column=col, sticky=»nsew»)
root.grid_rowconfigure(6, weight=1)
root.grid_columnconfigure(4, weight=1)
root.mainloop()
ОКСТУ 4002
Дата введения 1990-07-01
1. РАЗРАБОТАН И ВНЕСЕН Министерством приборостроения, средств автоматизации и систем управления СССР
ИСПОЛНИТЕЛИ
Ю.П.Галустян, канд. техн. наук; Н.Б.Гуляев, канд. техн. наук; А.П.Дувакин, канд. физ.-мат. наук; А.В.Катков; С.Л.Котов, В.П.Куприянов, канд. эконом. наук; В.П.Морозов, канд. эконом. наук; Е.В.Цальп, канд. техн. наук; Н.Н.Чихалов, канд. техн. наук; В.В.Шураков, д-р эконом. наук.
2. УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ постановлением Государственного комитета СССР по стандартам от 28.07.89 N 2507
3. ВВЕДЕН ВПЕРВЫЕ
4. ССЫЛОЧНЫЕ НОРМАТИВНО-ТЕХНИЧЕСКИЕ ДОКУМЕНТЫ
|
Обозначение НТД, на который дана ссылка |
Номер приложения |
|
ГОСТ 19.004-80 |
Приложение 1 |
|
ГОСТ 15467-79 |
Приложение 1 |
|
ГОСТ 19781-83 |
Приложение 1 |
Настоящий стандарт, устанавливает общие положения по оценке качества программных средств вычислительной техники (далее — ПС), поставляемых через фонды алгоритмов и программ (ФАП), номенклатуру и применяемость показателей качества ПС.
Термины, применяемые в стандарте, и пояснения к ним приведены в приложении 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.1. Устойчивость функционирования |
H1 |
Способность обеспечивать продолжение работы программы после возникновения отклонений, вызванных сбоями технических средств, ошибками во входных данных и ошибками обслуживания |
|
1.2. Работоспособность |
Н2 |
Способность программы функционировать в заданных режимах и объемах обрабатываемой информации в соответствии с программными документами при отсутствии сбоев технических средств |
|
2. Показатели сопровождения |
Характеризуют технологические аспекты, обеспечивающие простоту устранения ошибок в программе и программных документах и поддержания ПС в актуальном состоянии |
|
|
2.1. Структурность |
С1 |
Организация всех взаимосвязанных частей программы в единое целое с использованием логических структур «последовательность», «выбор», «повторение» |
|
2.2. Простота конструкции |
С2 |
Построение модульной структуры программы наиболее рациональным с точки зрения восприятия и понимания образом |
|
2.3. Наглядность |
С3 |
Наличие и представление в наиболее легко воспринимаемом виде исходных модулей ПС, полное их описание в соответствующих программных документах |
|
2.4. Повторяемость |
С4 |
Степень использования типовых проектных решений или компонентов, входящих в ПС |
|
3. Показатели удобства применения |
Характеризуют свойства ПС, способствующие быстрому освоению, применению и эксплуатации ПС с минимальными трудозатратами с учетом характера решаемых задач и требований к квалификации обслуживающего персонала |
|
|
3.1. Легкость освоения |
У1 |
Представление программных документов и программы в виде, способствующем пониманию логики функционирования программы в целом и ее частей |
|
3.2. Доступность эксплуатационных программных документов |
У2 |
Понятность, наглядность и полнота описания взаимодействия пользователя с программой в эксплуатационных программных документах |
|
3.3. Удобство эксплуатации и обслуживания |
УЗ |
Соответствие процесса обработки данных и форм представления результатов характеру решаемых задач |
|
4. Показатели эффективности |
Характеризуют степень удовлетворения потребности пользователя в обработке данных с учетом экономических, вычислительных и людских ресурсов |
|
|
4.1. Уровень автоматизации |
Э1 |
Уровень автоматизации функций процесса обработки данных с учетом рациональности функциональной структуры программы с точки зрения взаимодействия с ней пользователя и использования вычислительных ресурсов |
|
4.2. Временная эффективность |
Э2 |
Способность программы выполнять заданные действия в интервал времени, отвечающий заданным требованиям |
|
4.3. Ресурсоемкость |
Э3 |
Минимально необходимые вычислительные ресурсы и число обслуживающего персонала для эксплуатации ПС |
|
5. Показатели универсальности |
Характеризуют адаптируемость ПС к новым функциональным требованиям, возникающим вследствии изменения области применения или других условий функционирования |
|
|
5.1. Гибкость |
Г1 |
Возможность использования ПС в различных областях применения |
|
5.2. Мобильность |
Г2 |
Возможность применения ПС без существенных дополнительных трудозатрат на ЭВМ аналогичного класса |
|
5.3. Модифицируемость |
Г3 |
Обеспечение простоты внесения необходимых изменений и доработок в программу в процессе эксплуатации |
|
6. Показатели корректности |
Характеризуют степень соответствия ПС требованиям, установленным в ТЗ, требованиям к обработке данных и общесистемным требованиям |
|
|
6.1. Полнота реализации |
К1 |
Полнота реализации заданных функций ПС и достаточность их описания в программной документации |
|
6.2. Согласованность |
К2 |
Однозначное, непротиворечивое описание и использование тождественных объектов, функций, терминов, определений, идентификаторов и т.д. в различных частях программных документов и текста программы |
|
6.3. Логическая корректность |
К3 |
Функциональное и программное соответствие процесса обработки данных при выполнении задания общесистемным требованиям |
|
6.4. Проверенность |
К4 |
Полнота проверки возможных маршрутов выполнения программы в процессе тестирования |
первый уровень определяет группы показателей качества ПС, характеризующие потребительски-ориентированные свойства, которые соответствуют потребностям населения, народного хозяйства и экспорта продукции;
второй уровень определен комплексными показателями качества ПС, характеризующими программно-ориентированные свойства, которые обеспечивают достижение требуемых потребительски-ориентированных свойств.
2.2. Выбор номенклатуры показателей качества для конкретного ПС осуществляется с учетом его назначения и требований областей применения. В табл.2 представлена рекомендуемая применяемость показателей качества в зависимости от принадлежности ПС к тому или иному подклассу (группе) в соответствии с общесоюзным классификатором продукции.
Таблица 2
|
Номер показателя по табл.1 |
Применяемость показателя по подклассам (группам) ПС |
|||||||||||
|
5011 |
5012 |
5013 |
5014 |
5015 |
5016 |
5017 |
503 |
504 |
505 |
506 |
509 |
|
|
1.1 |
+ |
+ |
+ |
+ |
+ |
+ |
+ |
— |
± |
+ |
± |
|
|
1.2 |
+ |
+ |
+ |
+ |
+ |
+ |
+ |
+ |
+ |
+ |
+ |
|
|
2.1 |
± |
± |
± |
± |
± |
± |
± |
± |
± |
± |
± |
|
|
2.2 |
± |
± |
± |
± |
± |
± |
± |
— |
± |
± |
± |
|
|
2.3 |
± |
± |
± |
± |
± |
± |
± |
— |
± |
± |
± |
|
|
2.4 |
± |
± |
± |
± |
± |
± |
± |
± |
± |
± |
± |
|
|
3.1 |
± |
± |
± |
+ |
+ |
+ |
+ |
± |
+ |
± |
± |
|
|
3.2 |
+ |
+ |
+ |
+ |
+ |
+ |
+ |
+ |
+ |
+ |
+ |
|
|
3.3 |
+ |
+ |
± |
+ |
+ |
+ |
+ |
— |
+ |
+ |
± |
|
|
4.1 |
± |
± |
± |
± |
± |
± |
± |
— |
± |
± |
± |
|
|
4.2 |
± |
± |
± |
± |
± |
± |
± |
± |
± |
± |
± |
|
|
4.3 |
+ |
+ |
+ |
± |
± |
+ |
± |
— |
± |
± |
± |
|
|
5.1 |
— |
± |
— |
± |
± |
— |
— |
— |
+ |
± |
± |
|
|
5.2 |
± |
± |
± |
± |
± |
± |
± |
± |
± |
± |
± |
|
|
5.3 |
+ |
+ |
± |
± |
± |
± |
± |
— |
± |
± |
± |
|
|
6.1 |
+ |
+ |
+ |
+ |
+ |
+ |
+ |
+ |
+ |
+ |
+ |
|
|
6.2 |
+ |
+ |
+ |
+ |
+ |
+ |
+ |
+ |
+ |
+ |
+ |
|
|
6.3 |
+ |
+ |
+ |
+ |
+ |
+ |
+ |
+ |
+ |
+ |
+ |
|
|
6.4 |
+ |
+ |
+ |
+ |
+ |
+ |
+ |
+ |
+ |
+ |
+ |
Примечания:
1. Знак «+» означает применяемость, знак «-» — неприменяемость соответствующих показателей качества ПС, знак «±» — ограниченную применяемость.
2. Выбор показателей качества ПС для подкласса 509 (прочие ПС) осуществляется в зависимости от их назначения с учетом требований областей применения.
3. Наименование подклассов (групп) ПС по ОКП:
5011 — операционные системы и средства их расширения;
5012 — программные средства управления базами данных;
5013 — инструментально-технологические средства программирования;
5014 — ПС интерфейса и управления коммуникациями;
5015 — ПС организации вычислительного процесса (планирования, контроля);
5016 — сервисные программы;
5017 — ПС обслуживания вычислительной техники;
503 — прикладные программы для научных исследований;
504 — прикладные программы для проектирования;
505 — прикладные программы для управления техническими устройствами и технологическими процессами;
506 — прикладные программы для решения экономических задач;
2.3. Выбранная номенклатура показателей качества фиксируется в ТЗ на разработку ПС.
ПРИЛОЖЕНИЕ 1 (справочное). ПОЯСНЕНИЕ ТЕРМИНОВ, ПРИМЕНЯЕМЫХ В СТАНДАРТЕ
ПРИЛОЖЕНИЕ 1
Справочное
Таблица 3
|
Термин |
Пояснение |
|
Базовый показатель качества |
Реально достижимая совокупность значений показателей качества ПС для уравнения |
|
Вычислительные ресурсы |
Технические средства ЭВМ, в том числе процессор, объемы оперативной и внешней памяти, время, в течение которого программа занимает эти средства в ходе выполнения |
|
Единичный показатель качества продукции |
По ГОСТ 15467 |
|
Качество продукции |
По ГОСТ 15467 |
|
Комплексный показатель качества продукции |
По ГОСТ 15467 |
|
Логическая структура «выбор» |
Детализация части программы на условный элемент и несколько детальных частей таким образом, что управление передается в зависимости от реализации условного элемента только одной из тех частей, при этом одна из этих частей при необходимости может быть «пустым оператором», т.е. не выполнять никаких действий |
|
Логическая структура «последовательность» |
Детализация части программы на несколько детальных частей таким образом, что передача управления этим частям осуществляется последовательно от предшествующей части к последующей |
|
Логическая структура «повторение» |
Детализация части программы на условный элемент и одну детальную часть таким образом, что управление передается этой части многократно в соответствии с реализацией условного элемента |
|
Маршрут выполнения программы |
Совокупность операторов программы, выполненных во время однократного ее выполнения |
|
Ошибка обслуживания |
Нарушение требуемого порядка взаимодействия с программой со стороны пользователя |
|
Показатель качества продукции |
По ГОСТ 15467 |
|
Программа |
По ГОСТ 19781 |
|
Программное средство вычислительной техники (ПС) |
Программа, предназначенная для многократного применения на различных объектах, разработанная любым способом и снабженная комплектом программных документов |
|
Программный документ |
По ГОСТ 19.004 |
|
Сбой технических средств |
Событие, заключающееся в нарушении исправного состояния технических средств ЭВМ при сохранении ими работоспособного состояния |
|
Среда функционирования |
Совокупность организационных, информационных программных и технических средств ЭВМ при сохранении ими работоспособного состояния |
|
Эксплуатационный программный документ |
По ГОСТ 19.004 |
ПРИЛОЖЕНИЕ 2 (справочное). МЕТОДИКА ОЦЕНКИ КАЧЕСТВА ПС
ПРИЛОЖЕНИЕ 2
Справочное
1. Оценка качеств ПС проводится на фазах жизненного цикла (табл.1) и включает выбор номенклатуры показателей, их оценку и сопоставление значений показателей, полученных в результате сравнения с базовыми значениями.
2. Показатели качества объединены в систему из четырех уровней. Каждый вышестоящий уровень содержит в качестве составляющих показатели нижестоящих уровней. Допускается вводить дополнительные показатели на каждом из уровней.
2.1. Для обеспечения возможности получения интегральной оценки по группам показателей качества используют факторы качества (1-й уровень): надежность ПС, сопровождаемость, удобство применения, эффективность, универсальность (гибкость) и корректность.
2.2. Каждому фактору качества соответствует определенный набор критериев качества (комплексные показатели — 2-й уровень): устойчивость функционирования, работоспособность, структурность, простота конструкции, наглядность, повторяемость, легкость освоения, доступность эксплуатационных программных документов, удобство эксплуатации и обслуживания, уровень автоматизации, временная эффективность, ресурсоемкость, гибкость, мобильность, модифицируемость, полнота реализации, согласованность, логическая корректность, проверенность.
2.3. Критерии качества определяют одной или несколькими метриками (3-й уровень). Если критерий качества определяется одной метрикой, то уровень метрики опускается.
2.4. Метрики составляются из оценочных элементов (единичных показателей — 4-й уровень), определяющих заданное в метрике свойство. Число оценочных элементов, входящих в метрику не ограничено. Взаимосвязь факторов, критериев и метрик с фазами жизненного цикла ПС приведена на черт.1-20.
2.5. Выбор оценочных элементов в метрике зависит от функционального назначения оценочного элемента и определяется с учетом данных, полученных при проведении испытаний различных видов, а также по результатам эксплуатации ПС.
2.6. Для накопления информации об оценочных элементах формируется справочник оценочных элементов (табл.5-10) на основе ранее полученных данных о качестве аналогичных ПС.
3. Оценка качества ПС проводится в определенной последовательности.
3.1. На фазе анализа проводится выбор показателей и их базовых значений.
Таблица 4
Фазы жизненного цикла ПС
|
Процесс |
Фаза |
Подфаза |
Результат |
|
Разработка |
Анализ |
— |
Определение требований. Спецификация требований. Техническое задание |
|
Проектирование |
Логическое проектирование |
Логический проект (функциональный проект). Программно-технический проект: |
|
|
Реализация |
— |
Модули |
|
|
Тестирование |
— |
Тестирование модуля, программы системы, дополняющая документация. |
|
|
Изготовление |
Выпуск |
Программное средство в форме, готовой для поставки. |
|
|
Испытания |
Установленное ПС |
||
|
Применение |
Внедрение |
— |
Подтверждающее стабильной эксплуатации. |
|
Эксплуатация |
— |
Предложения об усовершенствовании. |
|
|
Обслуживание (сопровождение) |
— |
Информация о сопровождении программ. |
3.2. Для показателей качества на всех уровнях (факторы, критерии, метрики, оценочные элементы) принимается единая шкала оценки от 0 до 1.
3.3. Показатели качества на каждом вышестоящем уровне (кроме уровня оценочных элементов) определяются показателями качества нижестоящего уровня, т.е.:
результаты оценки каждого фактора определяются результатами оценки соответствующих ему критериев;
результаты оценки каждого критерия определяются результатами оценки соответствующих ему метрик;
результаты оценки каждой метрики определяются результатами оценки определяющих ее оценочных элементов.
Черт.1. Фаза анализа
Фаза анализа
____________
* Указан номер метрики (критерия).
Черт.1
Черт.2. Фаза проектирования
Фаза проектирования
Черт.2
Черт.3. Фазы реализации, тестирования, изготовления, обслуживания (сопровождения)
Фазы реализации, тестирования, изготовления, обслуживания (сопровождения)
Черт.3
Черт.4. Фаза анализа
Фаза анализа
Черт.4
Черт.5. Фаза проектирования
Фаза проектирования
Черт.5
Черт.6. Фазы реализации, тестирования и изготовления
Фазы реализации, тестирования и изготовления
Черт.6
Черт.7. Фаза обслуживания (сопровождения)
Фаза обслуживания (сопровождения)
Черт.7
Черт.8. Фаза анализа и проектирования
Фаза анализа и проектирования
Черт.8
Черт.9. Фазы реализации и тестирования
Фазы реализации и тестирования
Черт.9
Черт.10. Фазы изготовления, обслуживания (сопровождения)
Фазы изготовления, обслуживания (сопровождения)
Черт.10
Черт.11. Фаза анализа
Фаза анализа
Черт.11
Черт.12. Фаза проектирования
Фаза проектирования
Черт.12
Черт.13. Фаза реализации, тестирования, изготовления, обслуживания (сопровождения)
Фаза реализации, тестирования, изготовления, обслуживания (сопровождения)
Черт.13
Черт.14. Фаза анализа
Фаза анализа
Черт.14
Фаза проектирования
Черт.15. Фаза проектирования
Черт.15
Черт.16. Фазы реализации, тестирования, изготовления, обслуживания (сопровождения)
Фазы реализации, тестирования, изготовления, обслуживания (сопровождения)
Черт.16
Черт.17. Фаза анализа
Фаза анализа
Черт.18. Фаза проектирования
Фаза проектирования
Черт.18
Черт.19. Фазы реализации, тестирования и изготовления
Фазы реализации, тестирования и изготовления
Черт.19
Черт.20. Фазы обслуживания (сопровождения)
Фазы обслуживания
(сопровождения)
Черт.20
Таблица 5
Оценочные элементы фактора «надежность ПС»
|
Код элемента |
Наименование |
Метод оценки |
Оценка |
|
Н0101 |
Наличие требований к программе по устойчивости функционирования при наличии ошибок во входных данных |
Эксперт- |
0-1 |
|
Н0102 |
Возможность обработки ошибочных ситуаций |
То же |
0-1 |
|
Н0103 |
Полнота обработки ошибочных ситуаций |
« |
0-1 |
|
Н0104 |
Наличие тестов для проверки допустимых значений входных данных |
« |
0-1 |
|
Н0105 |
Наличие системы контроля полноты входных данных |
« |
0-1 |
|
Н0106 |
Наличие средств контроля корректности входных данных |
« |
0-1 |
|
Н0107 |
Наличие средств контроля непротиворечивости входных данных |
« |
0-1 |
|
Н0201 |
Наличие требований к программе по восстановлению процесса выполнения в случае сбоя операционной системы, процессора, внешних устройств |
« |
0-1 |
|
H0202 |
Наличие требований к программе по восстановлению результатов при отказах процессора, ОС |
« |
0-1 |
|
Н0203 |
Наличие средств восстановления процесса в случае сбоев оборудования |
« |
0-1 |
|
Н0204 |
Наличие возможности разделения по времени выполнения отдельных функций программ |
« |
0-1 |
|
Н0205 |
Наличие возможности повторного старта с точки останова |
« |
0-1 |
|
Н0108 |
Наличие проверки параметров и адресов по диапазону их значений |
« |
0-1 |
|
Н0109 |
Наличие обработки граничных результатов |
« |
0-1 |
|
Н0110 |
Наличие обработки неопределенностей (деление на 0, квадратный корень из отрицательного числа и т.д.) |
« |
0-1 |
|
H0301 |
Наличие централизованного управления процессами, конкурирующими из-за ресурсов |
« |
0-1 |
|
H0302 |
Наличие возможности автоматически обходить ошибочные ситуации в процессе вычисления |
« |
0-1 |
|
Н0303 |
Наличие средств, обеспечивающих завершение процесса решения в случае помех |
« |
0-1 |
|
H0304 |
Наличие средств, обеспечивающих выполнение программы в сокращенном объеме в случае ошибок или помех |
« |
0-1 |
|
Н0305 |
Показатель устойчивости к искажающим воздействиям |
Расчет- |
|
|
Н0401 |
Вероятность безотказной работы |
То же |
|
|
Н0501 |
Оценка по среднему времени восстановления |
« |
где
где |
|
Н0502 |
Оценка по продолжительности преобразования входного набора данных в выходной |
« |
где |
Таблица 6
Оценочные элементы фактора «сопровождаемость»
|
Код элемента |
Наименование |
Метод оценки |
Оценка |
|
C0803 |
Наличие комментариев в точках входа и выхода программы |
Эксперт- |
0-1 |
|
С0302 |
Оценка простоты программы по числу точек входа и выхода |
Расчет- |
где
|
|
С1002 |
Оценка простоты программы по числу переходов по условию |
То же |
|
|
С0303 |
Осуществляется ли передача результатов работы модуля через вызывающий его модуль |
Эксперт- |
0-1 |
|
С0304 |
Осуществляется ли контроль за правильностью данных, поступающих в вызывающий модуль от вызываемого |
« |
0-1 |
|
С0604 |
Оценка программы по числу циклов |
« |
0-1 |
|
С0801 |
Наличие комментариев ко всем машинозависимым частям программы |
« |
0-1 |
|
С0802 |
Наличие комментариев к машинозависимым операторам программы |
« |
0-1 |
|
С0901 |
Соответствие комментариев принятым соглашениям |
« |
0-1 |
|
С1001 |
Используется ли язык высокого уровня |
« |
0-1 |
|
С0301 |
Наличие проверки корректности передаваемых данных |
« |
0-1 |
|
C0902 |
Наличие комментариев-заголовков программы с указанием ее структурных и функциональных характеристик |
« |
0-1 |
|
C0601 |
Использование при построении программ метода структурного программирования |
« |
0-1 |
|
C0602 |
Соблюдение принципа разработки программы сверху вниз |
« |
0-1 |
|
C0201 |
Наличие ограничений на размеры модуля |
« |
0-1 |
|
C0101 |
Наличие модульной схемы программы |
« |
0-1 |
|
C030 |
Наличие требований к независимости модулей программы от типов и форматов выходных данных |
« |
0-1 |
|
C0102 |
Оценка программы по числу уникальных модулей |
« |
0-1 |
|
C0903 |
Оценка ясности и точности описания последовательности функционирования всех элементов программы |
« |
0-1 |
|
C0603 |
Оценка программы по числу циклов с одним входом и одним выходом |
« |
0-1 |
Таблица 7
Оценочные элементы фактора «удобство применения»
|
Код элемента |
Наименование |
Метод оценки |
Оценка |
|
У0101 |
Возможность освоения программных средств по документации |
Экспертный |
0-1 |
|
У0102 |
Возможность освоения ПС на контрольном примере при помощи ЭВМ |
То же |
0-1 |
|
У0103 |
Возможность поэтапного освоения ПС |
« |
0-1 |
|
У0201 |
Полнота и понятность документации для освоения |
« |
0-1 |
|
У0202 |
Точность документации для освоения |
« |
0-1 |
|
У0203 |
Техническое исполнение документации |
« |
0-1 |
|
У0301 |
Наличие краткой аннотации |
« |
0-1 |
|
У0302 |
Наличие описания решаемых задач |
« |
0-1 |
|
У0303 |
Наличие описания структуры функций ПС |
« |
0-1 |
|
У0304 |
Наличие описания основных функций ПС |
« |
0-1 |
|
У0306 |
Наличие описания частных функций |
« |
0-1 |
|
У0307 |
Наличие описания алгоритмов |
« |
0-1 |
|
У0308 |
Наличие описания межмодульных интерфейсов |
« |
0-1 |
|
У0309 |
Наличие описания пользовательских интерфейсов |
« |
0-1 |
|
У0310 |
Наличие описания входных и выходных данных |
« |
0-1 |
|
У0311 |
Наличие описания диагностических сообщений |
« |
0-1 |
|
У0312 |
Наличие описания основных характеристик ПС |
« |
0-1 |
|
У0314 |
Наличие описания программной среды функционирования ПС |
« |
0-1 |
|
У0315 |
Достаточность документации ввода ПС в эксплуатацию |
« |
0-1 |
|
У0316 |
Наличие информации технологии переноса для мобильных программ |
« |
0-1 |
|
У0401 |
Соответствие оглавления содержанию документации |
« |
0-1 |
|
У0402 |
Оценка оформления документации |
« |
0-1 |
|
У0403 |
Грамматическая правильность изложения документации |
« |
0-1 |
|
У0404 |
Отсутствие противоречий |
« |
0-1 |
|
У0405 |
Отсутствие неправильных ссылок |
« |
0-1 |
|
У0406 |
Ясность формулировок и описаний |
« |
0-1 |
|
У0407 |
Отсутствие неоднозначных формулировок и описаний |
« |
0-1 |
|
У0408 |
Правильность использования терминов |
« |
0-1 |
|
У0409 |
Краткость, отсутствие лишней детализации |
« |
0-1 |
|
У0410 |
Единство формулировок |
« |
0-1 |
|
У0411 |
Единство обозначений |
« |
0-1 |
|
У0412 |
Отсутствие ненужных повторений |
« |
0-1 |
|
У0413 |
Наличие нужных объяснений |
« |
0-1 |
|
У0501 |
Оценка стиля изложения |
« |
0-1 |
|
У0502 |
Дидактическая разделенность |
« |
0-1 |
|
У0503 |
Формальная разделенность |
« |
0-1 |
|
У0504 |
Ясность логической структуры |
« |
0-1 |
|
У0505 |
Соблюдение стандартов и правил изложения в документации |
« |
0-1 |
|
У0506 |
Оценка по числу ссылок вперед в тексте документов |
« |
0-1 |
|
У0601 |
Наличие оглавления |
« |
0-1 |
|
У0602 |
Наличие предметного указателя |
« |
0-1 |
|
У0603 |
Наличие перекрестных ссылок |
« |
0-1 |
|
У0604 |
Наличие всех требуемых разделов |
« |
0-1 |
|
У0605 |
Соблюдение непрерывности нумерации страниц документов |
« |
0-1 |
|
У0606 |
Отсутствие незаконченных разделов абзацев, предложений |
« |
0-1 |
|
У0607 |
Наличие всех рисунков, чертежей, формул, таблиц |
« |
0-1 |
|
У0608 |
Наличие всех строк и примечаний |
« |
0-1 |
|
У0609 |
Логический порядок частей внутри главы |
« |
0-1 |
|
У0701 |
Наличие полного перечня документации |
« |
0-1 |
|
У0801 |
Уровень языка общения пользователя с программой |
« |
0-1 |
|
У0802 |
Легкость и быстрота загрузки и запуска программы |
« |
0-1 |
|
У0803 |
Легкость и быстрота завершения работы программы |
« |
0-1 |
|
У0804 |
Возможность распечатки содержимого программы |
« |
0-1 |
|
У0805 |
Возможность приостанова и повторного запуска работы без потерь информации |
« |
0-1 |
|
У0901 |
Соответствие меню требованиям пользователя |
« |
0-1 |
|
У0902 |
Возможность прямого перехода вверх и вниз по многоуровнему меню (пропуск уровней) |
« |
0-1 |
|
У1001 |
Возможность управления подробностью получаемых выходных данных |
« |
0-1 |
|
У1002 |
Достаточность полученной информации для продолжения работы |
« |
0-1 |
|
У1101 |
Обеспечение удобства ввода данных |
« |
0-1 |
|
У1102 |
Легкость восприятия |
« |
0-1 |
|
У1201 |
Обеспечение программой выполнения предусмотренных рабочих процедур |
« |
0-1 |
|
У1202 |
Достаточность информации, выдаваемой программой для составления дополнительных процедур |
« |
0-1 |
Таблица 8
Оценочные элементы фактора «эффективность»
|
Код элемента |
Наименование |
Метод оценки |
Оценка |
|
Э0101 |
Проблемно-ориентированные функции |
Экспертный или расчетный |
0-1 |
|
Э0102 |
Машинно-ориентированные функции |
То же |
0-1 |
|
Э0103 |
Функции ведения и управления |
« |
0-1 |
|
Э0104 |
Функции ввода/вывода |
« |
0-1 |
|
Э0105 |
Функции защиты и проверки данных |
« |
0-1 |
|
Э0106 |
Функции защиты от несанкционированного доступа |
« |
0-1 |
|
Э0107 |
Функции контроля доступа |
« |
0-1 |
|
Э0108 |
Функции защиты от внесения изменений |
« |
0-1 |
|
Э0109 |
Наличие соответствующих границ функциональных областей |
« |
0-1 |
|
Э0110 |
Число знаков после запятой в результатах вычислений |
« |
0-1 |
|
Э0201 |
Время выполнения программ |
« |
0-1 |
|
Э0202 |
Время реакции и ответов |
« |
0-1 |
|
Э0203 |
Время подготовки |
« |
0-1 |
|
Э0205 |
Затраты времени на защиту данных |
« |
0-1 |
|
Э0206 |
Время компиляции |
« |
0-1 |
|
Э0301 |
Требуемый объем внутренней памяти |
« |
0-1 |
|
Э0302 |
Требуемый объем внешней памяти |
« |
0-1 |
|
Э0303 |
Требуемые периферийные устройства |
« |
0-1 |
|
Э0304 |
Требуемое базовое программное обеспечение |
« |
0-1 |
Таблица 9
Оценочные элементы фактора «универсальность»
|
Код элемента |
Наименование |
Метод оценки |
Оценка |
|
Г0101 |
Оценка числа потенциальных пользователей |
Экспертный |
0-1 |
|
Г0102 |
Оценка числа функций ПС |
То же |
0-1 |
|
Г0103 |
Насколько набор функций удовлетворяет требованиям пользователя |
« |
0-1 |
|
Г0104 |
Насколько возможности программ охватывают область решаемых пользователем задач |
« |
0-1 |
|
Г0105 |
Возможность настройки формата выходных данных для конкретных пользователей |
« |
0-1 |
|
Г0201 |
Наличие схемы иерархии модулей программы |
« |
0-1 |
|
Г0202 |
Оценка независимости модулей |
« |
0-1 |
|
Г0203 |
Оценка числа уникальных элементов/реквизитов |
« |
0-1 |
|
Г0204 |
Используется ли в текущем вызове модуля информация, полученная в предыдущем вызове |
« |
0-1 |
|
Г0205 |
Оценка организации точек входа и выхода модуля |
« |
0-1 |
|
Г0206 |
Наличие описания атрибутов модуля |
« |
0-1 |
|
Г0301 |
Оценка программ по числу переходов и точек ветвления |
« |
0-1 |
|
Г0401 |
Использование метода пошагового уточнения |
« |
0-1 |
|
Г0402 |
Наличие описания структуры программ |
« |
0-1 |
|
Г0403 |
Наличие описания связей между элементами структуры программы |
« |
0-1 |
|
Г0404 |
Наличие в программе повторного выполнения функций (подпрограмм) |
« |
0-1 |
|
Г0501 |
Использование стандартных протоколов связи |
« |
0-1 |
|
Г0601 |
Использование стандартных интерфейсных программ |
« |
0-1 |
|
Г0701 |
Оценка зависимости пограмм от емкости оперативной памяти ЭВМ |
« |
0-1 |
|
Г0702 |
Оценка зависимости временных характеристик программы от скорости вычислений ЭВМ |
« |
0-1 |
|
Г0703 |
Оценка зависимости функционирования программы от числа внешних запоминающих устройств и их общей емкости |
« |
0-1 |
|
Г0704 |
Оценка зависимости функционирования программы от специальных устройств ввода-вывода |
« |
0-1 |
|
Г0801 |
Применение специальных языков программирования |
« |
0-1 |
|
Г0802 |
Оценка зависимости программы от программ операционной системы |
« |
0-1 |
|
Г0803 |
Зависимость от других программных средств |
« |
0-1 |
|
Г0901 |
Оценка локализации непереносимой части программы |
« |
0-1 |
|
Г1001 |
Оценка использования отрицательных или булевых выражений |
« |
0-1 |
|
Г1002 |
Оценка программы по использованию условных переходов |
« |
0-1 |
|
Г1003 |
Оценка программы по использованию безусловных переходов |
« |
0-1 |
|
Г1004 |
Оформление процедур входа выхода из циклов |
« |
0-1 |
|
Г1005 |
Ограничения на модификацию переменной индексации в цикле |
« |
0-1 |
|
Г1007 |
Оценка программы по использованию локальных переменных |
« |
0-1 |
|
Г1006 |
Оценка модулей по направлению потока управления |
« |
0-1 |
|
Г1101 |
Оценка программы по числу комментариев |
« |
0-1 |
|
Г1201 |
Наличие заголовка в программе |
« |
0-1 |
|
Г1202 |
Комментарии к точкам ветвлений |
« |
0-1 |
|
Г1203 |
Комментарии к машинозависимым частям программы |
« |
0-1 |
|
Г1204 |
Комментарии к машинозависимым операторам программы |
« |
0-1 |
|
Г1205 |
Комментарии к операторам объявления переменных |
« |
0-1 |
|
Г1206 |
Оценка семантики операторов |
« |
0-1 |
|
Г1207 |
Наличие соглашений по форме представлений комментариев |
« |
0-1 |
|
Г1208 |
Наличие общих комментариев к программам |
« |
0-1 |
|
Г1301 |
Использование языков высокого уровня |
« |
0-1 |
|
Г1302 |
Семантика имен используемых переменных |
« |
0-1 |
|
Г1303 |
Использование отступов, сдвигов и пропусков при формировании текста |
« |
0-1 |
|
Г1304 |
Размещение операторов по строкам |
« |
0-1 |
|
Г1401 |
Передача информации для управления по параметрам |
« |
0-1 |
|
Г1402 |
Параметрическая передача входных данных |
« |
0-1 |
|
Г1403 |
Наличие передачи результатов работы между модулями |
« |
0-1 |
|
Г1404 |
Наличие проверки правильности данных, получаемых модулями от вызываемого модуля |
« |
0-1 |
|
Г1405 |
Использование общих областей памяти |
« |
0-1 |
Таблица 10
Оценочные элементы фактора «корректность»
|
Код элемента |
Наименование |
Метод оценки |
Оценка |
|
К0101 |
Наличие всех необходимых документов для понимания и использования ПС |
Экспертный |
0-1 |
|
К0102 |
Наличие описания и схемы иерархии модулей программы |
То же |
0-1 |
|
К0103 |
Наличие описания основных функций |
« |
0-1 |
|
К0104 |
Наличие описания частных функций |
« |
0-1 |
|
К0105 |
Наличие описания данных |
« |
0-1 |
|
К0106 |
Наличие описания алгоритмов |
« |
0-1 |
|
К0107 |
Наличие описания интерфейсов между модулями |
« |
0-1 |
|
К0108 |
Наличие описания интерфейсов с пользователями |
« |
0-1 |
|
К0109 |
Наличие описания используемых числовых методов |
« |
0-1 |
|
К0110 |
Указаны ли все численные методы |
« |
0-1 |
|
К0111 |
Наличие описания всех параметров |
« |
0-1 |
|
К0112 |
Наличие описания методов настройки системы |
« |
0-1 |
|
К0113 |
Наличие описания всех диагностических сообщений |
« |
0-1 |
|
К0114 |
Наличие описания способов проверки работоспособности программы |
« |
0-1 |
|
К0201 |
Реализация всех исходных модулей |
« |
0-1 |
|
К0202 |
Реализация всех основных функций |
« |
0-1 |
|
К0203 |
Реализация всех частных функций |
« |
0-1 |
|
К0204 |
Реализация всех алгоритмов |
« |
0-1 |
|
К0205 |
Реализация всех взаимосвязей в системе |
« |
0-1 |
|
К0206 |
Реализация всех интерфейсов между модулями |
« |
0-1 |
|
К0207 |
Реализация возможности настройки системы |
« |
0-1 |
|
К0208 |
Реалчзация диагностики всех граничных и аварийных ситуаций |
« |
0-1 |
|
К0209 |
Наличие определения всех данных (переменные, индексы, массивы и проч.) |
« |
0-1 |
|
К0210 |
Наличие интерфейсов с пользователем |
« |
0-1 |
|
К0301 |
Отсутствие противоречий в описании частных функций |
« |
0-1 |
|
К0302 |
Отсутствие противоречий в описании основных функций в разных документах |
« |
0-1 |
|
К0303 |
Отсутствие противоречий в описании алгоритмов |
« |
0-1 |
|
К0304 |
Отсутствие противоречий в описании взаимосвязей в системе |
« |
0-1 |
|
К0305 |
Отсутствие противоречий в описании интерфейсов между модулями |
« |
0-1 |
|
К0306 |
Отсутствие противоречий в описании интерфейсов с пользователем |
« |
0-1 |
|
К0307 |
Отсутствие противоречий в описании настройки системы |
« |
0-1 |
|
К0309 |
Отсутствие противоречий в описании иерархической структуры сообщений |
« |
0-1 |
|
К0310 |
Отсутствие противоречий в описании диагностических сообщений |
« |
0-1 |
|
К0311 |
Отсутствие противоречий в описании данных |
« |
0-1 |
|
К0401 |
Отсутствие противоречий в выполнении основных функций |
« |
0-1 |
|
К0402 |
Отсутствие противоречий в выполнении частных функций |
« |
0-1 |
|
К0403 |
Отсутствие противоречий в выполнении алгоритмов |
« |
0-1 |
|
К0404 |
Правильность взаимосвязей |
« |
0-1 |
|
К0405 |
Правильность реализации интерфейса между модулями |
« |
0-1 |
|
К0406 |
Правильность реализации интерфейса с пользователем |
« |
0-1 |
|
К0407 |
Отсутствие противоречий в настройке системы |
« |
0-1 |
|
К0408 |
Отсутствие противоречий в диагностике системы |
« |
0-1 |
|
К0409 |
Отсутствие противоречий в общих переменных |
« |
0-1 |
|
К0501 |
Единообразие способов вызова модулей |
« |
0-1 |
|
К0502 |
Единообразие процедур возврата управления из модулей |
« |
0-1 |
|
К0503 |
Единообразие способов сохранения информации для возврата |
« |
0-1 |
|
К0504 |
Единообразие способов восстановления информации для возврата |
« |
0-1 |
|
К0505 |
Единообразие организации списков передаваемых параметров |
« |
0-1 |
|
К0601 |
Единообразие наименования каждой переменной и константы |
« |
0-1 |
|
К0602 |
Все ли одинаковые константы встречаются во всех программах по одинаковыми именами |
« |
0-1 |
|
К0603 |
Единообразие определения внешних данных во всех программах |
« |
0-1 |
|
К0604 |
Используются ли разные идентификаторы для разных переменных |
« |
0-1 |
|
К0605 |
Все ли общие переменные объявлены как общие переменные |
« |
0-1 |
|
К0606 |
Наличие определений одинаковых атрибутов |
« |
0-1 |
|
К0701 |
Комплектность документации в соответствии со стандартами |
« |
0-1 |
|
К0702 |
Правильное оформление частей документов |
« |
0-1 |
|
К0703 |
Правильное оформление титульных и заглавных листов документов |
« |
0-1 |
|
К0704 |
Наличие в документах всех разделов соответствии со стандартами |
« |
0-1 |
|
К0705 |
Полнота содержания разделов в соответствии со стандартами |
« |
0-1 |
|
К0706 |
Деление документов на структурные элементы: разделы, подразделы, пункты, подпункты |
« |
0-1 |
|
К0801 |
Соответствии организации и вычислительного процесса эксплуатационной документации |
« |
0-1 |
|
К0802 |
Правильность заданий на выполнение программы, правильность написания управляющие и операторов (отсутствие ошибок) |
« |
0-1 |
|
К0803 |
Отсутствие ошибок в описании действий пользователя |
« |
0-1 |
|
К0804 |
Отсутствие ошибок в описании запуска |
« |
0-1 |
|
К0805 |
Отсутствие ошибок в описании генерации |
« |
0-1 |
|
К0806 |
Отсутствие ошибок в описании настройки |
« |
0-1 |
|
К1001 |
Наличие требований к тестированию программ |
« |
0-1 |
|
К1002 |
Достаточность требований к тестированию программ |
« |
0-1 |
|
К1003 |
Отношение числа модулей, отработавших в процессе тестирования и отладки ( |
Расчетный |
|
|
К1004 |
Отношение числа логических блоков, отработавших в процессе тестирования и отладки ( |
То же |
|
Примечание — Коды оценочных элементов составлены из 5 символов следующим образом:
1-й символ — буква русского алфавита указывает на принадлежность элемента тому или иному фактору. («Н» — надежности, «С» — сопровождаемости, «У» — удобству применения, «Э» — эффективности, «Г» — универсальности, «К» — корректности);
2-й и 3-й символы — номер метрики, которой принадлежит оценочный элемент;
4-й и 5-й символы — порядковый номер данного оценочного элемента в метрике.
Например, «К1004» означает, что это 4-й оценочный элемент из 10-й метрики фактора «корректность».
3.4. В процессе оценки качества ПС на каждом уровне (кроме уровня оценочных элементов) проводятся вычисления показателей качества ПС, т.е. определение количественных значений абсолютных показателей (, где
— порядковый номер показателя данного уровня для
-го показателя вышестоящего уровня) и относительных показателей (
), являющихся функцией показателя
, и базового значения
.
3.5. Каждый показатель качества 2-го и 3-го уровней (критерий и метрика) характеризуется двумя числовыми параметрами — количественным значением и весовыми коэффициентами ().
3.6. Сумма весовых коэффициентов показателей уровня () относящихся к
-му показателю вышестоящего уровня (
), есть величина постоянная. Сумма весовых коэффициентов (
) принимается равной 1.
,
3.7. Общая оценка качества ПС в целом формируется экспертами по набору полученных значений оценок факторов качества.
3.8. Для оценки качества ПС различного назначения методом экспертного опроса составляется таблица значений базовых показателей качества ПС.
3.9. Определение усредненной оценки () оценочного элемента по нескольким его значениям (
) проводится по формуле

где — число значений ОЭ (оценочного элемента);
— порядковый номер метрики;
— порядковый номер ОЭ.
3.10. Итоговая оценка -й метрики
-го критерия ведется по формуле

где — число ОЭ в
-й метрике.
3.11. Абсолютные показатели критериев -го фактора качества определяются по формуле
, (4)
где — число метрик, относящихся к
-му критерию.
3.12. Относительный показатель -го критерия
-го фактора качества вычисляется по формуле

3.13. Фактор качества (*) вычисляется по формуле
*, (6)
где — число критериев качества, относящихся к
-му фактору.
_______________
* Соответствует оригиналу. — Примечание.
4. Качество ПС определяется путем сравнения полученных расчетных значений показателей с соответствующими базовыми значениями показателей существующего аналога или расчетного ПС, принимаемого за эталонный образец
4.1. Значения базовых показателей ПС должны соответствовать значениям показателей, отражающих современный уровень качества и прогнозируемый мировой уровень.
4.2. В качестве аналогов выбираются реально существующие ПС того же функционального назначения, что и сравниваемое, с такими же основными параметрами, подобной структуры и применяемые в условиях эксплуатации.

Решение
Сообщение от krazyd
Расскажите ваше мнение на тему обработки ошибок, как лучше реализовать?
1) Обрабатывать все возможные ошибки. Все. Повторю еще раз — все. Да, все.
Многие почему-то этого не делают. Если некая функция может вернуть false, вы
обязаны проверить это. Если в программе вызывается три сотни разных функций,
каждая из которых может завершиться ошибкой, вы обязаны написать код проверки
возвращаемого значения к каждой из них. Если метод некоего класса может выбрасывать
исключение, вы не должны помещать код его вызова в try/catch с пустым блоком catch —
это худшее, что можно придумать. Если некая операция или последовательность операций
завершается неудачей, то самое плохое, что можно в этом случае сделать — тихо
замолчать факт ошибки или, что еще хуже, попытаться выполнить ту же операцию, но
каким-то другим способом.
Не следование этому простому, на первый взгляд, принципу, влечет за собой то, что
лично я называю «пробрасывание ошибки» или «распостранение ошибки». Вместо того, чтобы
быть пойманной и четко классифицированной сразу по месту возникновения, вместе с
кодами исключения, стек-трейсом и другой полезной информацией, ошибка маскируется и
плавает в программе где-то на дне еще некоторое время, после чего все равно всплывает,
но уже совершенно в другом месте и с гораздо более невнятными симптомами, когда
возможности для ее диагностики уже нет. Искать такие ошибки, как правило, уже бесполезно.
Суть качественной обработки ошибок — максимально резкая реакция на их возникновение,
вместе со сбором максимально полной информации о контексте. Разумеется, есть ошибки
логические, которые являются ожидаемыми, например, невозможность сохранить данные в файл
из-за отсутствия прав на запись. В этом случае, очевидно, следует показать пользователю
какое-то осмысленное, «человеческое» сообщение и продолжить работу адекватным и наиболее
ожидаемым для него способом. Все остальное, что попадает в класс «unexpected», «overflow»,
«no memory», деление на ноль и т.п., должно обрабатываться соответствующим образом.
2) Принцип в пункте 1 распостраняется на ключевые аспекты архитектуры приложения.
Если есть некий API, он должен быть спроектирован так, чтобы его можно было использовать
лишь одним, и никаким другим способом. И при попытке хоть что-то сделать не так должна
возвращаться ошибка. Если некий клиентский код, работая с нашим протоколом обмена данными,
посылает их не в том порядке, не с теми заголовками, с неверной длиной и т.п., то ни в
коем случае не следует пытаться «угадать» намерения клиента. Снова лучшая стратегия здесь —
сразу прервать обработку и вернуть соответствующий код ошибки. Как привередливая и
чрезмерно внимательная к деталям тетка. Вообще, чем уже «коридор» выполнения кода, тем
меньше возможностей где-то накосячить и сойти пути, который был намечен разработчиком.
Это один из ключевых принципов.
3) Не следует пытаться «восстановиться» после какой-то критической ошибки. Самое лучшее и
простое — дать программе просто упасть, сообщив пользователю о том, что произошло, ну возможно
еще снять крэш-дамп и создать логи. Не следует применять здесь какие-то «умные» стратегии,
они все равно будут нелепы.
4) Слой обработки ошибок должен быть четко отделен от слоя бизнес-логики приложения.
Иначе вы рискуете получить спагетти-код, нашпигованный if-ами через каждые три строчки.
Такой код очень трудно понимать, т.к. «лес» не видно за «деревьями». Исключения обычно
помогают достичь этой цели, к тому же их, в отличие от true/false и кодов возврата,
нельзя проигнорировать. То есть, где-то на низком уровне мы пишем реализацию, со всеми
свойственными ей заморочками, детализацией, проверкой ошибок и т.п., а сверху должен
быть простой, очевидный, компактный и самодокументированный код, чтобы одного взгляда
на который для любого смертного, даже не знакомого с программированием, хватило бы
для понимания того, что этот код делает.
5) «Исключения vs коды возврата» — руководствуемся соображениями пункта 4 (исключения
позволяют этого достигнуть), а также тем, что в объект исключения можно запихнуть любое
количество полезной информации. Но при этом учитываем перфоманс (коды быстрее) и вопросы
переносимости (выброс исключения даже за пределы модуля уже может привести к проблемам, а
из-за отсутствия ABI они не совместимы между компиляторами и, иногда, между разными
версиями одного и того же компилятора).
6) Ассерты, проверки инвариантов и тому подобное, должны быть расставлены на каждом шагу.
Это помогает отслеживать возникновение ошибок при внесении изменений в код, что очень важно.
Хороший ассерт, который вдруг выстрелил, сразу дает понять, что именно произошло и почему.
12




Средства
Функционирование



























