- Контакты ООО «Техническая документация»

Заказать услуги ООО «Техническая документация» можно по эл. почте admin @ tdocs . su (без пробелов), по тел. 8-910-468-09-28 или в форме Контакты.

Качество технической документации. Часть II - оценочные элементы надежности

Практические приемы оценки и повышения качества техдокументации по оценочным элементам фактора «надежность» согласно ГОСТ 28195-89. Материал входит в цикл статей «Качество технической документации». Редакция от 18.01.2015.

В первой, вводной части статьи «Качество технической документации. Часть I»:

- Качество технической документации. Часть II

В настоящей и последующих статьях будут освещены практические приемы оценки качества техдокументации (проанализированы критерии оценки), показаны подходы к «автоматическому» повышению качества технической документации, т.е. как разрабатывать документацию таким образом, чтобы качество ее по умолчанию было предопределенным и буквально «зашкаливало» по подходящим оценочным критериям ГОСТ 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,
где D - число экспериментов, в которых искажающие воздействия приводили к отказу,
К - число экспериментов, в которых имитировались искажающие воздействия

Функционирование в заданных режимах

Н0401

Вероятность безотказной работы

То же

P = 1 - Q/N,
где Q - число зарегистрированных отказов,
N - число экспериментов,

Обеспечение обработки заданного объема информации

Н0501

Оценка по среднему времени восстановления

»

где Твдоп - допустимое среднее время восстановления;
Тв - среднее время восстановления, которое определяется по формуле
где N - число восстановлений;
Tвi - время восстановления после i-го отказа

Н0502

Оценка по продолжительности преобразования входного набора данных в выходной

Расчетный

где - допустимое время преобразования i-го входного набора данных;
Тпi - фактическая продолжительность преобразования i-го входного набора данных

Смотрите:

Средства восстановления при ошибках на входе
Средства восстановления при сбоях оборудования
Реализация управления средствами восстановления
Функционирование в заданных режимах
Обеспечение обработки заданного объема информации

Примечание - Здесь и далее требования в оценочных элементах будут применяться все больше к техническому заданию на автоматизированную систему, поскольку:

  • ТЗ на АС наиболее востребованы на текущий момент, да и оценки часто касаются именно требований;
  • на примере ТЗ можно с максимумом наглядности показать способы достижения того самого предопределенного качества документа, о котором упоминалось выше.

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

Средства восстановления при ошибках на входе

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

Наличие требований к программе по устойчивости функционирования при наличии ошибок во входных данных

«Наличие... при наличии...» - Круглые глаза

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

Возможность обработки ошибочных ситуаций

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

Полнота обработки ошибочных ситуаций

Полнота обработки ошибочных ситуаций - в документах должен быть приведен полный перечень ошибочных ситуаций. Если предусмотрена обработка всех ошибочных ситуаций, то полноту обработки можно считать 100-процентной.

Наличие тестов для проверки допустимых значений входных данных

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

Контроль формата ввода данных: программа позволяет пользователю вводить дату только в формате ДД.ММ.ГГГГ, но не в ГГГГ/ММ/ДД и ни в каком ином. Логический контроль: дата окончания школы не может быть введена БОЛЕЕ ранней, нежели чем дата поступления в школу - Подмигиваю (смайл)

О форматно-логическом контроле следует упомянуть где-нибудь в подразделе Требования к лингвистическому обеспечению или создать дополнительный подраздел «Требования к интерфейсу пользователя» в техническом задании.

Наличие системы контроля полноты входных данных

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

- Полнота входных данных

Наличие средств контроля корректности входных данных

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

- Выбор даты из календаря

Наличие средств контроля непротиворечивости входных данных

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

Наличие проверки параметров и адресов по диапазону их значений

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

Наличие обработки граничных результатов

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

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

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

Средства восстановления при сбоях оборудования

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

Наличие требований к программе по восстановлению процесса выполнения в случае сбоя операционной системы, процессора, внешних устройств

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

Наличие требований к программе по восстановлению результатов при отказах процессора, ОС

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

Наличие средств восстановления процесса в случае сбоев оборудования

То же. Только не оборудования, а технических средств.

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

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

Наличие возможности повторного старта с точки останова

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

Сейчас точкой останова можно считать момент времени, когда программа находится в режиме ожидания. К примеру, когда запускается тот же Microsoft Word, он завершает все свои инициализационные процедуры, после чего выходит на точку останова - ждет ввода данных пользователем.

Реализация управления средствами восстановления

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

Наличие централизованного управления процессами, конкурирующими из-за ресурсов

Централизованное управление процессами, конкурирующими из-за ресурсов, встроено во все применяемые ныне операционные системы. Требования к операционным системам, входящим в состав общего программного обеспечения, расписываются в подразделе Требования к программному обеспечению технического задания.

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

См. Наличие требований к программе по устойчивости функционирования при наличии ошибок во входных данных.

Наличие средств, обеспечивающих завершение процесса решения в случае помех

Не совсем ясно, что считать помехами? Если это какие-нибудь электромагнитные помехи или внешние воздействующие факторы по ГОСТ 26883-86, то следует озвучить заданное требование в техническом задании, а в подразделе Требования к защите от влияния внешних воздействий указать предельные их уровни, например «...соответствие нормам индустриальных помех для оборудования класса А согласно ГОСТ Р 51318.22 (СИСПР 22-97)».

Наличие средств, обеспечивающих выполнение программы в сокращенном объеме в случае ошибок или помех

По аналогии с предыдущим пунктом.

Показатель устойчивости к искажающим воздействиям

Не рассматривается, как экспериментальный.

Функционирование в заданных режимах

Вероятность безотказной работы

См. выше.

Обеспечение обработки заданного объема информации

Оценка по среднему времени восстановления

См. выше.

Оценка по продолжительности преобразования входного набора данных в выходной

См. выше.

Выводы по II части статьи

Примечание - Четыре крайних элемента таблицы не учитывались, поскольку речь в них идет об экспериментах, которые проведены быть не могут до испытаний.

Итак, казалось бы, оценочные факторы надежности должны применяться к программному средству, а фактически, причем вполне обоснованно и справедливо, они были применены к техническому заданию, т.е. к документу, и определили его качество. В сумме ТЗ (в части надежности) получило 17 баллов из 23-х возможных, что есть 73,9 %, если подходить формально. Если не учитывать четыре крайних элемента, то процентное соотношение будет составлять 94,4.

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

- Контакты ООО «Техническая документация»

Заказать услуги ООО «Техническая документация» можно по эл. почте admin @ tdocs . su (без пробелов), по тел. 8-910-468-09-28 или в форме Контакты.

Copyright © ООО «Техническая документация» 2016. Заимствуйте наши материалы с блеском!
При цитировании на своих ресурсах наших материалов используйте активные ссылки на них.