ГОСТ Р МЭК 60880—2010
Окончание таблицы В. 1Ь
ПунктРекомендацияПозволяет избсжать/позволяет добиться
В.1Ы Следует определить последствия, оказываемые от
дельными решениями на другие части системы
Дублирования работ / тщательного про
ектирования
B.1bg Разрыв между уровнями проектирования ПО должен
быть таким, чтобы те. кто проводит анализ, могли
понять каждый уровень проектирования в его взаи
мосвязи с предыдущим уровнем
Проектов, трудных для понимания / яс
ности проекта ПО и согласованности
проекта, подлежащего верификации
B.1bhСледует проводить проектирование и разработку ПО.
гические схемы, другие графические средства или
проблемно-ориентированные языки
Неправильной интерпретации или не
используя одно или несколько формализованных точности /
описаний высокого уровня (там. где это целесооб
разно и эффективно), подобно тому, как это делает ся
в математической логике, теории множеств, а так же
использовать псевдокод, таблицы решений, ло
В.1biСледует использовать автоматические средства раз
работки
/ сокращения области ошибок человека
B.1bj Документацию следует составлять так. чтобы автор
спецификации был в состоянии понять и проверить
реализацию функций в проекте
/ модификаций и соответствия специ
фикациям
Т а б л и ц а
В. 1с — Верификация промежуточных результатов проекта
П у н кт
Р еком ендацияП озволяет избеж ать,’позволяет добиться
В.1с
Промежуточные результаты проекта должны вери
фицироваться
/ наиболее быстрого обнаружения оши
бок. полноты проекта
В.1са
Следует показать полноту и самосогласованность
каждого уровня проекта
Необходимости последующих измене
ний/
В.1сЬ
Следует показать, что каждый уровень проекта
согласуется с предыдущим уровнем и со специфика
цией требований к ПО. существенных для данного
уровня
Пропущенныхаспектов /отсутствия про
пущенных требований
В.1СС
Проверки согласованности следует проводить пер
соналу. не вовлеченному в процесс разработки
—
B.1cd
Этому персоналу следует только отмечать недостат
ки. но не давать никаких рекомендаций
Привязки конкретных лиц к программе
/ сохранения критического отношения
В.1се
Где необходимо, им следует давать четкие поясне
ния. чтобы помочь разработчикам правильно понять
обнаруженные недочеты
/ повысить интерес к деятельности по
верификации и общую эффективность
работы группы
Т а б л и ц а
B.1d — Управление модификаций в процессе разработки
П у н кт
Р еком ендация
П озволяет избеж ать.’позволяет добиться
B.1d
Внесение необходимых изменений в процессе раз
работки программы должно начинаться на самом
раннем этапе проектирования, на котором еще мож
но вносить изменения
Внесения новых дефектов в результа
те изменений/отсутствия скрытых, име
ющих отдаленные последствия дефек
тов
B.1db
Если какой-либо модуль изменяется, тодля него сле
дует провести повторное тестирование всоответствии
с описанными ранее принципами (см. 11.2) до его
повторной интеграции в системе
Скрытых дефектов в модуле, вызван
ных изменением/
49