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

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

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

Что есть в ГОСТ по части сопровождения и сопровождаемости автоматизированных систем и программ?

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

Процесс модификации существующей программы вычислительной машины, обусловленный необходимостью устранения выявленных в ней ошибок и (или) изменения ее функциональных возможностей [из п. 12 ГОСТ 19.004-80]

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

Все прозрачно. Теперь о показателях сопровождения. Структурность:

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

Простота конструкции:

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

Наглядность:

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

Повторяемость:

Степень использования типовых проектных решений или компонентов, входящих в программное средство [из п. 2.4 Таблицы 1 п. 2.1 ГОСТ 28195-89]

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

Таблица 6 из ГОСТ 28195-89 Оценочные элементы фактора «сопровождаемость», добавлены метрики качества.

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

Оценка программы по числу уникальных модулей

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

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

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

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

Наличие ограничений на размеры модуля

При нынешних гигантских объемах оперативной памяти данный фактор можно проигнорировать. Но все равно остается непонятным: наличие ограничений - это 0 или 1?

Межмодульные связи

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

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

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

Не совсем понятно, куда и что передается... Порой создается впечатление, что к разработке ГОСТ 28195-89 приложили руку не только высококвалифицированные специалисты, но и кухаркины дети.

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

Не совсем понятный критерий: сколько точек входа (выхода) необходимо, чтобы считать программу простой?

Осуществляется ли передача результатов работы модуля через вызывающий его модуль

В любом программном модуле всегда предусмотрена функция возврата чего-либо. Кому нужен модуль, который в результате своего выполнения ничего не возвращает? Оценочный элемент представляется довольно мутным.

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

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

Экспертиза принятой системы идентификации

Хочется добавить - классификации и кодирования согласно ПР 50.1.019-2000...

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

Основных логических структур всего три:

1. Логическая структура «последовательность»;
2. Логическая структура «выбор»;
3. Логическая структура «повторение».

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

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

И без повторений - многократных повторных вызовов чего-либо в программе тоже не обойтись.

Соблюдение принципа нисходящего программирования

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

А как программировать иначе, как не структурно?

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

Почти то же, что и выше... Дедуктивный метод, однако.

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

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

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

Оценка программы по числу циклов - см. рисунок (ниже).

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

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

Комментарии обоснования декомпозиции программ при кодировании

Комментарии обоснования декомпозиции программ при кодировании: что бы это значило?

Комментарии логики программ проекта

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

Сейчас, наверное, машиннозависимых программ-то и не найти. Разве что BIOS'ы, стартовые абсолютные программы и загрузочные модули типа grub какие-нибудь остались...

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

См. выше.

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

Наличие комментариев в точках входа и выхода программы - см. рисунок (ниже).

Точкой входа в программный модуль Drupal является с 94-я строка в его исходном тексте. Комментарии приведены в строках с 90-й по 93-ю.

Оформление текста программ

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

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

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

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

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

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

С точностью более-менее понятно, поскольку ее можно оценить простой сверкой работы программы с описанием применения. А что понимать под ясностью? Ясность формулировок и описаний?

В обоих случаях экспертный метод оценки применим мало.

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

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

Чтобы не повторяться, внедряем в этот пункт сведения из второй части статьи:

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

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

Вот они, пресловутые условные переходы - см. рисунок (ниже).

Стоит отвлечься от темы, чтобы еще раз поругать конструкции типа if...else. Код программы, построенный с применением указанной конструкции (особенно с многократным ее вложением), становится совершенно нечитаемым, поэтому ни о какой простоте программы и речи быть не может. Возникают проблемы с наглядностью и легкостью усвоения... Другое дело ветвления - те же условные переходы, но с применением оператора case, см. рисунок (ниже). Тут-то код совершенно прозрачен и прекрасно читается! К сожалению, оператор case работает далеко не со всеми типами переменных...

Итак:

• в техническом задании следует прописать требования по минимизации числа переходов по условию с применением конструкции if...else;
• в тексте программы все будет видно и так, поэтому общую оценку подсчитать будет очень легко.

Использование типовых компонентов ПС

Использование типовых компонентов ПС - это что-то вроде применения типовых проектных решений.

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

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

Метрики 11 и 12 отсутствуют. Метрика 4 на черт. 5 называется экспертиза принятой системы идентификации, на черт. 6 - принятая система идентификации. Множество метрик не имеет оценочных элементов.

Продолжение последовало.

Заказать услуги, установить контакты со специалистами компании можно по электронной почте admin собака tdocs точка su, по ICQ UIN 481-726-610 или с помощью формы «Контакты». Вопросы некоммерческого характера могут быть заданы в Форуме проектировщиков и разработчиков технической документации.