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

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

Итак, показатели универсальности программного средства:

Гибкость:

Возможность использования программного средства в различных областях применения [из 5.1 табл. 1 п. 2.1 ГОСТ 28195-89]

Мобильность:

Возможность применения программного средства без существенных дополнительных трудозатрат на ЭВМ аналогичного класса [из 5.2 табл. 1 п. 2.1 ГОСТ 28195-89]

или

Совокупность свойств программного средства, характеризующая приспособленность для переноса из одной среды функционирования в другие [из 18 разд. 2 ГОСТ 28806-90]

Модифицируемость:

Обеспечение простоты внесения необходимых изменений и доработок в программу в процессе эксплуатации [из 5.3 табл. 1 п. 2.1 ГОСТ 28195-89]

или

Совокупность свойств программного средства, характеризующая усилия, необходимые для внесения в него изменений, связанных с устранением дефектов или приведением в соответствие с изменившейся средой функционирования [из 5.2 прил. 2 ГОСТ 28806-90]

Оценочные элементы фактора «универсальность»

Таблица 9 ГОСТ 28195-89 - Оценочные элементы фактора «универсальность», скорректированная (добавлены метрики)

Код элемента

Наименование

Метод оценки

Оценка

Широта охвата функций

Г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

Смотрите:
Широта охвата функций
Простота архитектуры проекта
Сложность архитектуры проекта
Сложность структуры кода программ
Применение стандартных протоколов связи
Применение стандартных интерфейсных программ
Зависимость от используемого комплекса технических средств
Зависимость от базового программного обеспечения
Изоляция немобильности
Простота кодирования
Число комментариев
Качество комментариев
Использование описательных средств языка
Независимость модулей
Выводы по VI части

Широта охвата функций

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

Оценка числа потенциальных пользователей

Поскольку задача-минимум цикла статей О качестве... - охват программных документов, документов на СОИ и документации на автоматизированные системы, то под потенциальными пользователями следует понимать:

Теперь о числе потенциальных пользователей. Их число может быть оценено с точностью до ± 0,01 (или с более высокой точностью) при условии, что разработка ведется в интересах конкретного потребителя (или «чисто конкретного», выражаясь языком «просвещенной интеллигенции»). На естественном языке это означает, что пользователями программного средства или АС будет заранее известное количество персонала заказчика.

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

Оценка числа функций ПС

Оценка числа функций ПС - что это:

  1. Число функций в перечне функциональных возможностей программы;
  2. Число функциональных объектов программы;
  3. Число процедур-функций?

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

Итак, в ГОСТ 28195-89 в который уже раз обнаружена формулировка, допускающая множественное (неоднозначное) толкование, что, собственно, запрещено самим ГОСТ 28195-89, см. согласованность программного средства 😉 Также нарушены:

Насколько набор функций удовлетворяет требованиям пользователя

Это не deja vu... Кто ж его, бедолагу, спросит? См. Соответствие меню требованиям пользователя.

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

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

Социологические методы основаны на обработке специальных анкет-вопросников [из 1.5.6 ГОСТ 28195-89]

Возможность настройки формата выходных данных для конкретных пользователей

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

  1. Одному - в doc, другому - в pdf;
  2. Одному - более полную, другому - менее полную.

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

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

Простота архитектуры проекта

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

Наличие схемы иерархии модулей программы

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

Оценка независимости модулей

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

Оценка числа уникальных элементов/реквизитов

Оценка числа уникальных элементов/реквизитов: снова приходится гадать, о чем речь. Быть может, о том, что не должно быть двух или более модулей (или более мелких элементов структуры) с одним и тем же или частично одним и тем же функционалом? Тогда это что-то похожее на унифицированную процедуру.

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

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

Оценка организации точек входа и выхода модуля

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

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

Наличие описания атрибутов модуля: что есть атрибуты модуля? Для документов, включая электронные, имеются сервисные, справочные, предопределенные атрибуты, а что для модулей?

Сложность архитектуры проекта

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

Оценка программ по числу переходов и точек ветвления - в переводе с языка ГОСТ 28195-89 на русский это означает применение в программах определенного числа:

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

Фокус, подобный работе оператора goto, активно применялся в диссертациях: халтурщик-соискатель давал ссылку на что-то «см. здесь», оттуда - «см. там», а оттуда еще «см. еще где-то тут». И так - многократно. Только очень дотошный руководитель или оппонент решался пролистать весь бумажный документ и убедиться, что ссылка ведет в никуда 😀

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

Сложность структуры кода программ

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

Использование метода пошагового уточнения

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

Наличие описания структуры программ

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

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

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

Наличие в программе повторного выполнения функций (подпрограмм)

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

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

Использование стандартных протоколов связи

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

Применение стандартных интерфейсных программ

Использование стандартных интерфейсных подпрограмм

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

Зависимость от используемого комплекса технических средств

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

Оценка зависимости программ от емкости оперативной памяти ЭВМ

Оценка зависимости программ от емкости оперативной памяти ЭВМ: к объему оперативной памяти предъявляются требования в техническом задании, см. Требования к составу и параметрам технических средств. Таким образом, дело не в зависимости, а наличии требования (обязательного или альтернативного) в соотвествующем разделе ТЗ Требования к составу и параметрам технических средств. Оценочный элемент дублируется, см. Требуемый объем внутренней памяти.

Оценка зависимости временных характеристик программы от скорости вычислений ЭВМ

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

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

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

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

Оценка зависимости функционирования программы от специальных устройств ввода-вывода: все определяется техническим заданием. А устройств таких довольно много, перечисляем:

  1. Устройство автоматического ввода графической информации по ГОСТ 25868-91;
  2. Устройство ввода альтернативы (Choice device) по ГОСТ 27459-87;
  3. Устройство ввода изолированной речи по ГОСТ 25868-91;
  4. Устройство ввода печатного текста по ГОСТ 25868-91;
  5. Устройство ввода позиций (Locator) по ГОСТ 27459-87;
  6. Устройство ввода последовательности позиций (Stroke device) по ГОСТ 27459-87;
  7. Устройство ввода речи по ГОСТ 25868-91;
  8. Устройство ввода рукописного текста по ГОСТ 25868-91;
  9. Устройство ввода штриховых кодов по ГОСТ 25868-91;
  10. Устройство ввода-вывода аналоговых сигналов по ГОСТ 25868-91;
  11. Алфавитно-цифровая клавиатура ввода данных по ГОСТ 25868-91;
  12. Клавиатура ввода данных по ГОСТ 25868-91;
  13. Функциональная клавиатура ввода данных по ГОСТ 25868-91;
  14. Ввод-вывод данных с перфолент и перфокарт - это совсем уже из истории техники.

Зависимость от базового программного обеспечения

Смотрите:
Применение специальных языков программирования
Оценка зависимости программы от программ операционной системы
Зависимость от других программных средств

Применение специальных языков программирования

Применение специальных языков программирования: почему не применять их в спецпроектах? Или не применять объектно-ориентированные языки?

Оценка зависимости программы от программ операционной системы

Оценка зависимости программы от программ операционной системы: см. Требуемое базовое программное обеспечение.

Зависимость от других программных средств

См. выше.

Изоляция немобильности

Оценка локализации непереносимой части программы

Оценка локализации непереносимой части программы: см. Наличие информации технологии переноса для мобильных программ.

Простота кодирования

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

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

Оценка использования отрицательных или булевых выражений: интересно, как оценить? А ведь так удобно...

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

На этом портале страницы с терминологией, документами и процессами разработки и документирования по ГОСТам открываются без правых и левых боковых блоков. Сделано с помощью php-кода.

Оценка программы по использованию условных переходов

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

Оценка программы по использованию безусловных переходов

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

Оформление процедур входа и выхода из циклов

Оформление процедур входа и выхода из циклов: см. Наличие комментариев в точках входа и выхода программы.

Ограничения на модификацию переменной индексации в цикле

Ограничения на модификацию переменной индексации в цикле: неужели в прежние времена были в моде бесконечные циклы?

Оценка программы по использованию локальных переменных

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

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

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

Число комментариев

Оценка программы по числу комментариев

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

Качество комментариев

Смотрите:
Наличие заголовка в программе
Комментарии к точкам ветвлений
Комментарии к машинозависимым частям программы
Комментарии к машинозависимым операторам программы
Комментарии к операторам объявления переменных
Оценка семантики операторов
Наличие соглашений по форме представления комментариев
Наличие общих комментариев к программам

Наличие заголовка в программе

См. Наличие комментариев-заголовков программы с указанием ее структурных и функциональных характеристик.

Комментарии к точкам ветвлений

Крайне необходимы, иначе за логическими структурами «выбор» не уследить.

Комментарии к машинозависимым частям программы

См. Наличие комментариев ко всем машинозависимым частям программы.

Комментарии к машинозависимым операторам программы

См. Наличие комментариев к машинозависимым операторам программы.

Комментарии к операторам объявления переменных

Комментарии к операторам объявления переменных: ужасно, когда переменная, константа, массив и т.д. объявлены, но не откомментированы. В тексте программы разобраться невозможно.

Оценка семантики операторов

Оценка семантики операторов: это, наверное, что-то вроде формальной верификации.

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

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

Наличие общих комментариев к программам

Наличие общих комментариев к программам: обязательно!

Использование описательных средств языка

Смотрите:
Использование языков высокого уровня
Семантика имен используемых переменных
Использование отступов, сдвигов и пропусков при формировании текста
Размещение операторов по строкам

Использование языков высокого уровня

См. Используется ли язык высокого уровня.

Семантика имен используемых переменных

См. Оценка семантики операторов.

Использование отступов, сдвигов и пропусков при формировании текста

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

Размещение операторов по строкам

Размещение операторов по (отдельным) строкам: тоже обязательно. Текст программы удлиняется, но остается читаемым.

Независимость модулей

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

Передача информации для управления по параметрам

Передача информации для управления по параметрам: вероятно, имеется в виду передача информации с применением фактических и формальных параметров.

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

См. выше.

Наличие передачи результатов работы между модулями

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

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

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

Использование общих областей памяти

Использование общих областей памяти: см. Наличие централизованного управления процессами, конкурирующими из-за ресурсов.

Выводы по VI части

Выводы по VI части следующие:

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

Дублирование оценочных элементов прослеживается по ссылкам на предыдущие статьи цикла. В том, что оценочные элементы могут иметь место в различных показателях, страшного ничего нет, но названия их могли бы быть согласованы, чего в ГОСТ 28195-89 сделано не было. Возможности множественного толкования также встречаются сплошь и рядом.

Иерархию (перечисление 3) возможно было организовать без черт. 1 - 20, а представить в табличном виде, навскидку так:

Показатель

«Фаза»

Критерий

Метрика

Код элемента

Наименование

Метод оценки

Оценка

Все выглядело бы значительно прозрачнее.

Статьи цикла будут «гармонизированы» в части оценочных факторов.