ЖУРНАЛ «СТА» №1/2007

П ОДСЧЁТ ЭКОНОМИЧЕСКОЙ ЭФ - ФЕКТИВНОСТИ Использовать схему «создание, тес- тирование, обнаружение, отладка» в условиях, когда задачам недостаёт про- цессорных ресурсов, – это очень доро- го. Часто недостаток системных ресур- сов — это следствие сбойного, необъ- яснимого поведения системы, а не серьёзных поломок. В результате дос- таточно трудно собрать адекватную ин- формацию о возникших проблемах. Обычно поиск такого рода неисправ- ностей требует как наличия детальных знаний об устройстве системы, так и большого объёма кропотливой рабо- ты — в итоге требуется целая команда специалистов, чтобы обнаружить про- блему и найти пути её решения. Про- цесс включает в себя следующие дейст- вия. 1. Тестер создаёт отчет о проблеме, описывающий неожиданное поведе- ние системы при тестировании. Так как проблему сложно воспроизвести, тестер не может собрать достаточную информацию, способную облегчить решение проблемы. 2. Разработчик производит серию тес- товых запусков, пытаясь воспроизве- сти описанную проблему. Как прави- ло, разработчик обнаруживает, что дело не в конкретном процессе, а в некотором другом, который полно- стью загружает процессор, лишая та- ким образом все другие процессы процессорного времени обработки. 3. На этом этапе границы поиска реше- ния проблемы расширяются, в про- цесс вовлекается больше специали- стов. Решение может состоять в на- стройке приоритетов потока или в изменении поведения процесса. 4. Каждый привлеченный к процессу разработчик выполняет необходи- мые изменения и тестирует свою часть проекта, затем интегрирует из- менения в систему. 5. Тестер выполняет повторное тести- рование и закрывает отчёт об ошибке при условии, что в ходе этих меро- приятий не было выявлено дополни- тельных проблем или ошибок. Исходя из описанного алгоритма поиска неисправностей, составляем таблицу затрат на отладку одной про- блемы (табл. 1). Из этого примера видно, как недоста- ток процессорного времени проекта об- работки может увеличить затраты на разработку и задержать сдачу проекта; в нашем случае это дветри календарные недели. И это при том, что в нашем примере рассматривается система толь- ко с четырьмя потоками, в то время как многие промышленные системы содер- жат сотни и даже тысячи потоков, для каждого из которых существует сотня способов занять всё процессорное вре- мя. Так как стадия интеграции системы занимает больше всего времени при разработке проекта, оптимизация этой стадии приводит к сокращению издер- жек производства и тем самым способ- ствует более быстрому выходу конечно- го продукта на рынок. М ИНИМУМ УСИЛИЙ С ростом сложности и объёма про- граммного кода вероятность появления проблем нехватки процессорного вре- мени и других дефектов в конечном продукте возрастает. Стоимость устра- нения таких неполадок, после того как система была собрана, возрастает мно- гократно, не говоря уже об ударе по ре- путации разработчика и других финан- совых издержках, с этим связанных. Фирмыпоставщики и разработчики, которые создают программные продук- ты для систем промышленной автома- тизации, должны использовать любые возможности и методы, находящиеся в их распоряжении, чтобы обеспечить корректность отладки и полноценное тестирование своих программ. Более сложная задача, однако, найти и воплотить технологии разработки, ко- торые минимизируют усилия разработ- чиков и используемые компьютерные ресурсы. При условии правильного при- менения технология адаптивного рас- пределения процессорного времени яв- ляется таким решением. Более того, она 74 СТА 1/2007 П Р О Г РАММНО Е ОБ Е С П Е Ч Е НИ Е / СИС Т ЕМЫ Р Е АЛ Ь НО ГО В Р ЕМЕ НИ www.cta.ru Рис. 4. Распределение процессорных ресурсов при использовании технологии адаптивной декомпозиции Таблица 1 Затраты времени на решение проблемы Задача Необходимое время 1. Проверка и создание отчёта о проблеме (1 человек тестирует и создает отчёт) 1 день 2. Первоначальный этап выявления неисправности (1 человек отвечает за устранение проблемы) 2 дня 3. Совместное выявление неисправности (3 человека принимают участие) 3 дня 4. Совместное решение проблемы (3 человека принимают участие, каждый тратит 3 рабочих дня) 9 дней 5. Перепроверка (1 человек заново тестирует систему) 1 день Всего трудозатрат 16 дней