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

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

Создан 14.02.2012 14:56:30

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

Гибкость:

Возможность использования программного средства в различных областях применения [из 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 — Оценочные элементы фактора «универсальность», скорректированная (добавлены метрики)

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

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

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

• пользователей программных средств;
• пользователей систем обработки информации;
• пользователей автоматизированных систем.

Теперь о числе потенциальных пользователей. Их число может быть оценено с точностью до ± 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, а представить в табличном виде, навскидку так:

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

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