Что такое первичные ошибки в программе

С этим файлом связано 1 файл(ов). Среди них: Rekun.docx.
Показать все связанные файлы

Подборка по базе: Тема 3. Преступность и ее основные характеристики.Файл.pdf, Библиотековедение. Основные виды деятельности в библиотечном дел, Локализация поражений мозга и основные принципы локализации высш, Радиационные аварии виды, причины, основные опасные факторы и ис, Реферат Основные акушерско 2022.doc, Нефтяные битумы. Основные показатели качества нефтяных битумов.d, Расположите основные этапы мировоззрения в порядке их становлени, Структура социокультурного пространства ночного города и ее осно, Анализ учебников с 1 по 4 класс по русскому языку и основные пон, Приорнтетные цели и основные механизмы воздействия органов госуд

1. CALS-технологии

CALS-технологии это непрерывная информационная поддержка поставок и жизненного цикла изделий, или ИПИ (информационная поддержка процессов жизненного цикла изделий) — информационные технологии, используемые в управлении процессами жизненного цикла изделия или системы, в основном для сложных (высокотехнологичных и наукоёмких) образцов продукции машиностроения и иных объектов техники.

В общем виде CALS-технологии — это процесс создания единого информационного пространства в отдельно взятой системе обеспечения жизненного цикла продукции. С развитием производственных систем возникла необходимость разработки механизмов и процедур оперативного обмена данными между различными субъектами производственных отношений на разных этапах использования изделий.

Первоначально данная концепция была реализована в вооруженных силах США для снижения объемов бумажного документооборота, повышения оперативности обратной связи между заказчиками и поставщиками вооружений и амуниции, повышении управляемости системы и снижении общих затрат на информационную область. Сама аббревиатура CALS обозначала «компьютерную поддержку поставок».

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

Основные принципы CALS-технологий базируются на контроле и организации этапов существования продукции. К ним относят:

• Обеспечение системного управления (использование специальных информационных пространств);
• Минимизацию затрат на всех стадиях;
• Использование стандартных механизмов описания управляемых объектов (интеграция информационных потоков);
• Дифференциацию программных элементов на основе использования общих стандартов (данных и интерфейсов доступа) и применение платформ на коммерческой основе;
• Представление информации на безбумажной основе с приоритетом использования электронной подписи;
• Сопутствующий инжиниринг все процессов;
• Непрерывное корректирование и усовершенствование с целью создания оптимальной модели управления.

Создание информационной плоскости предполагает решение задачи на двух уровнях:

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

К преимуществам интегрированной среды можно отнести:

• Защиту данных во времени (обеспечение целостности);
• Обеспечение доступа к информации всех участников проекта, независимо от их положения в пространстве;
• Минимизацию потерь данных;
• Гибкость реагирования системы на внесенные коррективы (изменения доступны практически мгновенно в рамках всей системы);
• Повышение пропускной способности обработки данных;
• Широкие возможности разнообразных платформ проектирования и поддержки.

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

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

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

Примерами CALS-технологий являются цифровые методы проектирования производств, поддерживающие контроль жизненного цикла продукции (Product LifecycleManagement) — так называемые PLM-системы. К ним относят следующие классы систем:

• CAD – (Computer Aided Design) – решение задач проектирования изделий и элементов; моделирование объектов на плоскости (2D-модель) и в пространстве (3D-модель); средства получения чертежей; архивы данных по элементам конструкций и создание шаблонов документов.
• CAE – (Computer Aided Engineering) – исследование свойств объектов (при изготовлении и эксплуатации); создание проверочных систем анализа объекта по разработанной модели; оптимизация параметров объекта по заданным условиям и ограничениям.
• CAM — (Computer Aided Manufacturing) – программирование контроллеров станков с ЧПУ; исследование вариантов траектории инструмента по алгоритмам обрабатываемой поверхности; анализ геометрических конфликтов; подгонка к оборудованию.
• PDM — (Product Data Management) — хранение данных и контроль документации; создание архива образцов; обеспечение доступа к информации и ее защита.

CALS-технологии — это прежде всего методика информационной поддержки бизнес процессов, которая нашла свое применение в различных сферах производственной деятельности. Эффективность ее распространения и использования базируется на системной разработке соответствующей информационной среды. Для реализации данной цели необходимым условием является использование специальных композиционных подходов по формированию новых систем поддержки. Примером подобной компании на рынке России является НИЦ CALS-технологий «Прикладная логистика». Основные задачи компании лежат в плоскости прогрессивных платформ и нормативов их использования. Основными направлениями деятельности есть: осуществление оперативного наблюдения различных проектных данных и минимизация потерь продукции. НИЦ CALS-технологий — разработчик нескольких известных авторских платформ. Сделаем их краткий обзор.

Еще одной важной функцией вычислительных методов является управление различными ресурсами и потоками предприятия в реальном времени — материально-техническими, финансовыми, процессами складирования, персоналом, планированием и сбытом продукции. Системы, реализующие выполнение перечисленных задач относятся к ERP-системам (Enterprise Resource Planning − управление ресурсами предприятия).

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

К типовым функциям данного класса программных продуктов относят:

• Создание и контроль различных спецификаций (позволяют определить конечное изделие, учесть все необходимые ресурсы для производства);
• Управление сбытом продукции (прогноз реализации изделия на основе планов продаж);
• Анализ потребности в материалах (определение размера партий и сроков поставок, конкретных групп сырья и комплектующих);
• Организацию закупочной деятельности (формирование договоров о поставках, оптимизация складской деятельности предприятия);
• Планирование загрузки производственных мощностей (на уровне как всего предприятия, так и отдельных цехов или рабочих мест);
• Контроль финансовых ресурсов (учет и аудит финансов).

CALS-технологии в России используются на многих отечественных предприятиях, как гражданского, так и военного сектора. Электронная документация используется для многих изделий. К примеру, в авиации для самолетов, вертолетов, авиационных двигателей и комплектующих. Помимо этого, ведутся разработки систем навигации, телефонной и радио связи, управления. Применяются при проектировании и разработке автотракторной техники. Элементы системы используются на Воронежском механическом заводе, в государственной корпорации «Росатом», НПП «Аэросила», ОАО «Российские железные дороги» и др. Как видим, примеры CALS-технологии достаточно разнообразны.

2 Первичные ошибки, вторичные ошибки и их проявления

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

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

Распределение выявленных ошибок

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

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

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

Убывание ошибок в программном обеспечении и интенсивность их обнаружения не беспредельно. После отладки в течение некоторого времени интенсивность обнаружения ошибок при самом активном тестировании снижается настолько, что разработчики попадают в зону нечувствительности к программным ошибкам и отказам. При такой интенсивности отказов программ трудно прогнозировать затраты времени, необходимые для обнаружения очередной ошибки. Создается представление о полном отсутствии ошибок в программе, о невозможности и бесцельности их поиска. Поэтому усилия на отладку сокращаются, и интенсивность обнаружения ошибок еще больше снижается. Этой предельно низкой интенсивности обнаружения отказов соответствует наработка на обнаруженную ошибку, при которой прекращается улучшение характеристик программного обеспечения на этапах его отладки и испытаний у заказчика.

Ошибку можно отнести к одному из ниже перечисленных классов:

• системные ошибки;
• ошибки в выборе алгоритма;
• алгоритмические ошибки;
• технологические ошибки;
• программные ошибки.

Системные ошибки в большом (сложном) программном обеспечении определяются, прежде всего неполной информацией о реальных процессах, происходящих в источниках и потребителях информации.

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

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

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

При автономной и в начале комплексной отладки ПО доля найденных системных ошибок в нем невелика (примерно 10%), но она существенно возрастает (до 35—40%) на завершающих этапах комплексной отладки. В процессе эксплуатации преобладающими являются системные ошибки (примерно 80% всех ошибок). Следует отметить также большое количество команд и групп программ, которые корректируются при исправлении каждой системной ошибки.

Ошибки в выборе алгоритма. В настоящее время накоплен значительный фонд алгоритмов для решения типовых задач.

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

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

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

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

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

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

Технологические ошибки — это ошибки документации и фиксирования программ в памяти ЭВМ. Они составляют 5—10 % от общего числа ошибок, обнаруживаемых при отладке. Большинство технологических ошибок выявляются автоматически формализованными методами (например, транслятором).

Программные ошибки. Языки программирования — это искусственные языки, созданные человеком для описания алго­ритмов. Все предложения таких языков строятся по строгим синтаксическим правилам, обеспечивающим однозначное их понимание, что позволяет поручать расшифровку алгоритма ЭВМ, построенного по правилам семантики.

10.1. Общие
особенности дефектов, ошибок и рисков
в сложных программных средствах

10.2. Причины
и свойства дефектов, ошибок и модификаций
в сложных программных средствах

10.3. Риски
в жизненном цикле сложных программных
средств

10.4. Риски
при формировании требований к
характеристикам сложных программных
средств

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

К
понятию
«риски» относятся
негативные события и их величины,
отражающие потери, убытки или ущерб от
процессов или продуктов, вызванные
дефектами при
проектировании требований, недостатками
обоснования проектов ПС, а также при
последующих этапах разработки, реализации
и всего жизненного цикла комплексов
программ. В ЖЦ ПС не всегда
удается достигнуть требуемого
положительного эффекта и может проявляться
некоторый ущерб — риск в создаваемых
проектах, программных
продуктах и их характеристиках. Риски
проявляются, как негатив-ные
последствия дефектов функционирования
и применения ПС, которые
способны нанести ущерб системе, внешней
среде или пользователю в результате
отклонения характеристик объектов или
процессов от заданных требованиями
заказчика, согласованными с разработчиками.

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

Характеристики
дефектов и рисков непосредственно
связаны с достигаемой
корректностью, безопасностью и надежностью
функционирования
программ и помогают:

• оценивать
  реальное состояние проекта и планировать
  необходимую трудоемкость и длительность
  для его положительного завершения;

• выбирать
  методы и средства автоматизации
  тестирования и отладки программ,
  адекватные текущему состоянию разработки
  и сопровождения
  ПС, наиболее эффективные для устранения
  определенных видов дефектов и рисков;

• рассчитывать
  необходимую эффективность контрмер и
  дополнительных
  средств оперативной защиты от
  потенциальных дефектов и невыявленных
  ошибок;

— оценивать
требующиеся ресурсы ЭВМ по расширению
памяти и производительности, с учетом
затрат на реализацию контрмер при
модификации и устранении ошибок и
рисков.

Понятие
ошибки в программе —
в
общем случае под ошибкой подразумевается
неправильность,
погрешность или неумышленное искажение
объекта или процесса, что может быть
причиной
ущерба —риска
при
функционировании
и применении программы. При этом
предполагается, что
известно
правильное, эталонное состояние объекта
или процесса, по
отношению к которому может быть определено
наличие отклонения — ошибки
или дефекта. Исходным эталоном для
любого ПС являются спецификация
требований заказчика или потенциального
пользователя, предъявляемых
к программам. Подобные документы
устанавливают состав, содержание
и значения результатов, которые должен
получать пользователь при
определенных условиях и исходных данных.
Любое отклонение результатов
функционирования программы от
предъявляемых к ней требований и
сформированных по ним эталонов-тестов,
следует квалифицировать как ошибку
—
дефект
в программе,
наносящий
некоторый ущерб. Различия между ожидаемыми
и полученными результатами функционирования
программ могут быть следствием ошибок
не только в созданных программах, но и
ошибок в первичных требованиях
спецификаций, явившихся
базой при создании эталонов-тестов. Тем
самым проявляется объективная
реальность, заключающаяся в невозможности
абсолютной корректности и полноты
исходных спецификаций и эталонов для
сложных проектов
ПС.

На
практике в процессе ЖЦ ПС исходные
требования поэтапно уточняются,
модифицируются, расширяются и
детализируются по согласованию
между заказчиком и разработчиком. Базой
таких уточнений являются неформализованные
представления и знания специалистов-заказчиков
и
разработчиков, а также результаты
промежуточных этапов проектирования.
Однако установить некорректность таких
эталонов еще труднее, чем обнаружить
дефекты в сопровождаемых программах,
так как принципиально отсутствуют
формализованные данные, которые можно
использовать как исходные. В процессе
декомпозиции и верификации исходной
спецификации
требований на ПС возможно появление
ошибок в спецификациях
на группы программ и на отдельные модули.
Это способствует расширению спектра
возможных дефектов и вызывает необходимость
со-

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

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

С этим файлом связано 1 файл(ов). Среди них: Rekun.docx.
Показать все связанные файлы

Подборка по базе: Тема 3. Преступность и ее основные характеристики.Файл.pdf, Библиотековедение. Основные виды деятельности в библиотечном дел, Локализация поражений мозга и основные принципы локализации высш, Радиационные аварии виды, причины, основные опасные факторы и ис, Реферат Основные акушерско 2022.doc, Нефтяные битумы. Основные показатели качества нефтяных битумов.d, Расположите основные этапы мировоззрения в порядке их становлени, Структура социокультурного пространства ночного города и ее осно, Анализ учебников с 1 по 4 класс по русскому языку и основные пон, Приорнтетные цели и основные механизмы воздействия органов госуд

1. CALS-технологии

CALS-технологии это непрерывная информационная поддержка поставок и жизненного цикла изделий, или ИПИ (информационная поддержка процессов жизненного цикла изделий) — информационные технологии, используемые в управлении процессами жизненного цикла изделия или системы, в основном для сложных (высокотехнологичных и наукоёмких) образцов продукции машиностроения и иных объектов техники.

В общем виде CALS-технологии — это процесс создания единого информационного пространства в отдельно взятой системе обеспечения жизненного цикла продукции. С развитием производственных систем возникла необходимость разработки механизмов и процедур оперативного обмена данными между различными субъектами производственных отношений на разных этапах использования изделий.

Первоначально данная концепция была реализована в вооруженных силах США для снижения объемов бумажного документооборота, повышения оперативности обратной связи между заказчиками и поставщиками вооружений и амуниции, повышении управляемости системы и снижении общих затрат на информационную область. Сама аббревиатура CALS обозначала «компьютерную поддержку поставок».

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

Основные принципы CALS-технологий базируются на контроле и организации этапов существования продукции. К ним относят:

• Обеспечение системного управления (использование специальных информационных пространств);
• Минимизацию затрат на всех стадиях;
• Использование стандартных механизмов описания управляемых объектов (интеграция информационных потоков);
• Дифференциацию программных элементов на основе использования общих стандартов (данных и интерфейсов доступа) и применение платформ на коммерческой основе;
• Представление информации на безбумажной основе с приоритетом использования электронной подписи;
• Сопутствующий инжиниринг все процессов;
• Непрерывное корректирование и усовершенствование с целью создания оптимальной модели управления.

Создание информационной плоскости предполагает решение задачи на двух уровнях:

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

К преимуществам интегрированной среды можно отнести:

• Защиту данных во времени (обеспечение целостности);
• Обеспечение доступа к информации всех участников проекта, независимо от их положения в пространстве;
• Минимизацию потерь данных;
• Гибкость реагирования системы на внесенные коррективы (изменения доступны практически мгновенно в рамках всей системы);
• Повышение пропускной способности обработки данных;
• Широкие возможности разнообразных платформ проектирования и поддержки.

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

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

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

Примерами CALS-технологий являются цифровые методы проектирования производств, поддерживающие контроль жизненного цикла продукции (Product LifecycleManagement) — так называемые PLM-системы. К ним относят следующие классы систем:

• CAD – (Computer Aided Design) – решение задач проектирования изделий и элементов; моделирование объектов на плоскости (2D-модель) и в пространстве (3D-модель); средства получения чертежей; архивы данных по элементам конструкций и создание шаблонов документов.
• CAE – (Computer Aided Engineering) – исследование свойств объектов (при изготовлении и эксплуатации); создание проверочных систем анализа объекта по разработанной модели; оптимизация параметров объекта по заданным условиям и ограничениям.
• CAM — (Computer Aided Manufacturing) – программирование контроллеров станков с ЧПУ; исследование вариантов траектории инструмента по алгоритмам обрабатываемой поверхности; анализ геометрических конфликтов; подгонка к оборудованию.
• PDM — (Product Data Management) — хранение данных и контроль документации; создание архива образцов; обеспечение доступа к информации и ее защита.

CALS-технологии — это прежде всего методика информационной поддержки бизнес процессов, которая нашла свое применение в различных сферах производственной деятельности. Эффективность ее распространения и использования базируется на системной разработке соответствующей информационной среды. Для реализации данной цели необходимым условием является использование специальных композиционных подходов по формированию новых систем поддержки. Примером подобной компании на рынке России является НИЦ CALS-технологий «Прикладная логистика». Основные задачи компании лежат в плоскости прогрессивных платформ и нормативов их использования. Основными направлениями деятельности есть: осуществление оперативного наблюдения различных проектных данных и минимизация потерь продукции. НИЦ CALS-технологий — разработчик нескольких известных авторских платформ. Сделаем их краткий обзор.

Еще одной важной функцией вычислительных методов является управление различными ресурсами и потоками предприятия в реальном времени — материально-техническими, финансовыми, процессами складирования, персоналом, планированием и сбытом продукции. Системы, реализующие выполнение перечисленных задач относятся к ERP-системам (Enterprise Resource Planning − управление ресурсами предприятия).

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

К типовым функциям данного класса программных продуктов относят:

• Создание и контроль различных спецификаций (позволяют определить конечное изделие, учесть все необходимые ресурсы для производства);
• Управление сбытом продукции (прогноз реализации изделия на основе планов продаж);
• Анализ потребности в материалах (определение размера партий и сроков поставок, конкретных групп сырья и комплектующих);
• Организацию закупочной деятельности (формирование договоров о поставках, оптимизация складской деятельности предприятия);
• Планирование загрузки производственных мощностей (на уровне как всего предприятия, так и отдельных цехов или рабочих мест);
• Контроль финансовых ресурсов (учет и аудит финансов).

CALS-технологии в России используются на многих отечественных предприятиях, как гражданского, так и военного сектора. Электронная документация используется для многих изделий. К примеру, в авиации для самолетов, вертолетов, авиационных двигателей и комплектующих. Помимо этого, ведутся разработки систем навигации, телефонной и радио связи, управления. Применяются при проектировании и разработке автотракторной техники. Элементы системы используются на Воронежском механическом заводе, в государственной корпорации «Росатом», НПП «Аэросила», ОАО «Российские железные дороги» и др. Как видим, примеры CALS-технологии достаточно разнообразны.

2 Первичные ошибки, вторичные ошибки и их проявления

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

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

Распределение выявленных ошибок

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

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

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

Убывание ошибок в программном обеспечении и интенсивность их обнаружения не беспредельно. После отладки в течение некоторого времени интенсивность обнаружения ошибок при самом активном тестировании снижается настолько, что разработчики попадают в зону нечувствительности к программным ошибкам и отказам. При такой интенсивности отказов программ трудно прогнозировать затраты времени, необходимые для обнаружения очередной ошибки. Создается представление о полном отсутствии ошибок в программе, о невозможности и бесцельности их поиска. Поэтому усилия на отладку сокращаются, и интенсивность обнаружения ошибок еще больше снижается. Этой предельно низкой интенсивности обнаружения отказов соответствует наработка на обнаруженную ошибку, при которой прекращается улучшение характеристик программного обеспечения на этапах его отладки и испытаний у заказчика.

Ошибку можно отнести к одному из ниже перечисленных классов:

• системные ошибки;
• ошибки в выборе алгоритма;
• алгоритмические ошибки;
• технологические ошибки;
• программные ошибки.

Системные ошибки в большом (сложном) программном обеспечении определяются, прежде всего неполной информацией о реальных процессах, происходящих в источниках и потребителях информации.

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

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

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

При автономной и в начале комплексной отладки ПО доля найденных системных ошибок в нем невелика (примерно 10%), но она существенно возрастает (до 35—40%) на завершающих этапах комплексной отладки. В процессе эксплуатации преобладающими являются системные ошибки (примерно 80% всех ошибок). Следует отметить также большое количество команд и групп программ, которые корректируются при исправлении каждой системной ошибки.

Ошибки в выборе алгоритма. В настоящее время накоплен значительный фонд алгоритмов для решения типовых задач.

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

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

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

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

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

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

Технологические ошибки — это ошибки документации и фиксирования программ в памяти ЭВМ. Они составляют 5—10 % от общего числа ошибок, обнаруживаемых при отладке. Большинство технологических ошибок выявляются автоматически формализованными методами (например, транслятором).

Программные ошибки. Языки программирования — это искусственные языки, созданные человеком для описания алго­ритмов. Все предложения таких языков строятся по строгим синтаксическим правилам, обеспечивающим однозначное их понимание, что позволяет поручать расшифровку алгоритма ЭВМ, построенного по правилам семантики.

10.1. Общие
особенности дефектов, ошибок и рисков
в сложных программных средствах

10.2. Причины
и свойства дефектов, ошибок и модификаций
в сложных программных средствах

10.3. Риски
в жизненном цикле сложных программных
средств

10.4. Риски
при формировании требований к
характеристикам сложных программных
средств

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

К
понятию
«риски» относятся
негативные события и их величины,
отражающие потери, убытки или ущерб от
процессов или продуктов, вызванные
дефектами при
проектировании требований, недостатками
обоснования проектов ПС, а также при
последующих этапах разработки, реализации
и всего жизненного цикла комплексов
программ. В ЖЦ ПС не всегда
удается достигнуть требуемого
положительного эффекта и может проявляться
некоторый ущерб — риск в создаваемых
проектах, программных
продуктах и их характеристиках. Риски
проявляются, как негатив-ные
последствия дефектов функционирования
и применения ПС, которые
способны нанести ущерб системе, внешней
среде или пользователю в результате
отклонения характеристик объектов или
процессов от заданных требованиями
заказчика, согласованными с разработчиками.

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

Характеристики
дефектов и рисков непосредственно
связаны с достигаемой
корректностью, безопасностью и надежностью
функционирования
программ и помогают:

• оценивать
  реальное состояние проекта и планировать
  необходимую трудоемкость и длительность
  для его положительного завершения;

• выбирать
  методы и средства автоматизации
  тестирования и отладки программ,
  адекватные текущему состоянию разработки
  и сопровождения
  ПС, наиболее эффективные для устранения
  определенных видов дефектов и рисков;

• рассчитывать
  необходимую эффективность контрмер и
  дополнительных
  средств оперативной защиты от
  потенциальных дефектов и невыявленных
  ошибок;

— оценивать
требующиеся ресурсы ЭВМ по расширению
памяти и производительности, с учетом
затрат на реализацию контрмер при
модификации и устранении ошибок и
рисков.

Понятие
ошибки в программе —
в
общем случае под ошибкой подразумевается
неправильность,
погрешность или неумышленное искажение
объекта или процесса, что может быть
причиной
ущерба —риска
при
функционировании
и применении программы. При этом
предполагается, что
известно
правильное, эталонное состояние объекта
или процесса, по
отношению к которому может быть определено
наличие отклонения — ошибки
или дефекта. Исходным эталоном для
любого ПС являются спецификация
требований заказчика или потенциального
пользователя, предъявляемых
к программам. Подобные документы
устанавливают состав, содержание
и значения результатов, которые должен
получать пользователь при
определенных условиях и исходных данных.
Любое отклонение результатов
функционирования программы от
предъявляемых к ней требований и
сформированных по ним эталонов-тестов,
следует квалифицировать как ошибку
—
дефект
в программе,
наносящий
некоторый ущерб. Различия между ожидаемыми
и полученными результатами функционирования
программ могут быть следствием ошибок
не только в созданных программах, но и
ошибок в первичных требованиях
спецификаций, явившихся
базой при создании эталонов-тестов. Тем
самым проявляется объективная
реальность, заключающаяся в невозможности
абсолютной корректности и полноты
исходных спецификаций и эталонов для
сложных проектов
ПС.

На
практике в процессе ЖЦ ПС исходные
требования поэтапно уточняются,
модифицируются, расширяются и
детализируются по согласованию
между заказчиком и разработчиком. Базой
таких уточнений являются неформализованные
представления и знания специалистов-заказчиков
и
разработчиков, а также результаты
промежуточных этапов проектирования.
Однако установить некорректность таких
эталонов еще труднее, чем обнаружить
дефекты в сопровождаемых программах,
так как принципиально отсутствуют
формализованные данные, которые можно
использовать как исходные. В процессе
декомпозиции и верификации исходной
спецификации
требований на ПС возможно появление
ошибок в спецификациях
на группы программ и на отдельные модули.
Это способствует расширению спектра
возможных дефектов и вызывает необходимость
со-

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

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

Потери
эффективности и риски программ за счет
неполной корректности в первом приближении
можно считать прямо пропорциональными
(с
коэффициентом) вторичным ошибкам в
выходных результатах. Типичным является
случай, когда одинаковые по величине и
виду вторичные ошибки
в различных результирующих данных
существенно различаются по своему
воздействию на общую эффективность и
риски применения комплекса программ.
Это влияние вторичных ошибок, в лучшем
случае, можно
оценить методами экспертного анализа
при условии предварительной, четкой
классификации видов возможных первичных
ошибок в программах
и выходных величин. Таким образом, оценка
последствий, отражающихся
на вторичных ошибках и функционировании
программ, может, в
принципе,
производиться по
значениям ущерба —
риска
вследствие неустраненных их причин —
первичных
ошибок в программе. Вторичные
ошибки являются определяющими для
эффективности функционирования
программ, однако не каждая первичная
ошибка вносит заметный вклад в выходные
результаты. Вследствие этого ряд
первичных ошибок может
оставаться необнаруженным и, по существу,
не влияет на функциональные
характеристики ПС.

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

При
системном анализе модификаций
интенсивность обнаружения ошибок
относительно невелика, и ее трудно
выделить из процесса проектирования
ПС. Интенсивность проявления и обнаружения
вторичных ошибок
наиболее велика на этапе активного
тестирования и автономной отладки
программных компонентов. Затем она
снижается приблизительно экспоненциально.
Различия интенсивностей устранения
первичных ошибок, на основе их вторичных
проявлений, и
внесения первичных ошибок

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

Небольшими
ошибками называют
такие, на которые средний пользователь
не обратит внимания при применении ПС
вследствие отсутствия их проявления
и последствия которых обычно так и не
обнаруживаются. Небольшие ошибки могут
включать орфографические ошибки на
экране, пропущенные разделы в справочнике
и другие мелкие проблемы. Такие ошибки
никогда не помешают выпуску и применению
версии системы и программного
продукта. По десятибалльной шкале рисков
небольшие ошибки находятся в пределах
от 1 до 3-го приоритета (см. ниже).

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

Критические
ошибки останавливают
выпуск версии программного продукта.
Это могут быть ошибки
с высоким влиянием, которые
вызывают сбой
в системе или потерю данных, отражаются
на надежности и безопасности
применения ПС, с которыми никогда не
передается комплекс программ
пользователю. По десятибалльной шкале
— от 8 до 10-го приоритета.

Совокупность
ошибок, дефектов и последствий модификаций
проектов
крупномасштабных комплексов программ
можно упорядочить и условно представить
в виде перевернутой пирамиды в зависимости
от потенциальной
опасности и возможной величины
корректировок их последствий — рис.
10.2. В верхней части перечня расположены
модификации, дефекты
и ошибки, последствия которых обычно
требуют наибольших затрат
ресурсов для реализации изменений, и
они постепенно сокращаются
при снижении по перечню. Такое представление
величины типов корректировок программ
и данных полезно использовать как
ориентир для
учета
необходимых ресурсов при разработке и
сопровождении ПС, однако оно может
содержать значительные отклонения при
упорядочении статистических данных
реальных проектов. Каждому типу
корректировок соответствует
более или менее определенная категория
специалистов, являющихся источником
изменений данного типа (таблица 10.1).
Такую корреляцию
целесообразно рассматривать и учитывать
как общую качественную тенденцию
при анализе и поиске их причин.

Таблица
10.1

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]

• #
• #
• #
• #
• #
• #
• #
• #
• #
• #
• #

2.2. Первичное выявление ошибок

В течение многих лет большинство программистов убеждено в том, что программы пишутся исключительно для выполнения их на машине и не предназначены для чтения человеком, а единственным способом тестирования программы является ее исполнение на ЭВМ. Это мнение стало изменяться в начале 70-х годов в значительной степени благодаря книге Вейнберга «Психология программирования для ЭВМ» [9]. Вейнберг показал, что программы должны быть удобочитаемыми и что их просмотр должен быть эффективным процессом обнаружения ошибок.

По этой причине, прежде чем перейти к обсуждению традиционных методов тестирования, основанных на применении ЭВМ, рассмотрим процесс тестирования без применения ЭВМ («ручное тестирование»), являющийся по сути первичным обнаружением ошибок. Эксперименты показали, что методы ручного тестирования достаточно эффективны с точки зрения нахождения ошибок, так что один или несколько из них должны использоваться в каждом программном проекте. Описанные здесь методы предназначены для периода разработки, когда программа закодирована, но тестирование на ЭВМ еще не началось. Аналогичные методы могут быть получены и применены на более ранних этапах процесса создания программ (т. е. в конце каждого этапа проектирования). Некоторые из таких методов приводятся в работах [10] и [11].

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

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

2.3. Инспекции и сквозные просмотры

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

Инспекции и сквозные просмотры включают в себя чтение или визуальную проверку программы группой лиц. Эти методы развиты из идей Вейнберга [9]. Оба метода предполагают некоторую подготовительную работу. Завершающим этапом является «обмен мнениями» – собрание, проводимое участниками проверки. Цель такого собрания – нахождение ошибок, но не их устранение (т. е. тестирование, а не отладка).

Инспекции и сквозные просмотры широко практикуются в настоящее время, но причины их успеха до сих пор еще недостаточно выяснены. Заметим, что данный процесс выполняется группой лиц (оптимально три-четыре человека), лишь один из которых является автором программы. Следовательно, программа, по существу, тестируется не автором, а другими людьми, которые руководствуются изложенными ранее принципами (в разделе 1), обычно не эффективными при тестировании собственной программы. Фактически «инспекция» и «сквозной просмотр» – просто новые названия старого метода «проверки за столом» (состоящего в том, что программист просматривает свою программу перед ее тестированием), однако они гораздо более эффективны опять-таки по той же причине: в процессе участвует не только автор программы, но и другие лица. Результатом использования этих методов является, обычно, точное определение природы ошибок. Кроме того, с помощью данных методов обнаруживают группы ошибок, что позволяет в дальнейшем корректировать сразу несколько ошибок. С другой стороны, при тестировании на ЭВМ обычно выявляют только симптомы ошибок (например, программа не закончилась или напечатала бессмысленный результат), а сами они определяются поодиночке.

Ранее, более двух десятков лет, проводились широкие эксперименты по применению этих методов, которые показали, что с их помощью для типичных программ можно находить от 30 до 70 % ошибок логического проектирования и кодирования. (Однако эти методы не эффективны при определении ошибок проектирования «высокого уровня», например, сделанных в процессе анализа требований.) Так, было экспериментально установлено, что при проведении инспекций и сквозных просмотров определяются в среднем 38 % общего числа ошибок в учебных программах [12]. При использовании инспекций исходного текста в фирме IBM эффективность обнаружения ошибок составляла 80 % [13] (в данном случае имеется в виду не 80 % общего числа ошибок, поскольку, как отмечалось ранее, общее число ошибок в программе никогда не известно, а 80 % всех ошибок, найденных к моменту окончания процесса тестирования).

Конечно, можно критиковать эту статистику в предположении, что ручные методы тестирования позволяют находить только «легкие» ошибки (те, которые можно просто найти при тестировании на ЭВМ), а трудные, незаметные или необычные ошибки можно обнаружить только при тестировании на машине. Однако проведенное исследование показало, что подобная критика является необоснованной [14]. Кроме того, можно было бы утверждать, что ручное тестирование «морально устарело», но если обратить внимание на список типовых ошибок, то они до сих пор остались прежними и увеличит ли скорость тестирования ЭВМ не всегда очевидно. Но то, что эти методы стали совсем непопулярными – это факт. Бесспорно, что каждый метод хорош для своих типов ошибок и сочетание методов ручного тестирования и тестирования с применением ЭВМ для конкретной команды разработчиков представляется наиболее эффективным подходом; эффективность обнаружения ошибок уменьшится, если тот или иной из этих подходов не будет использован.

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

2.3.1. Инспекции исходного текста

Инспекции исходного текста представляют собой набор процедур и приемов обнаружения ошибок при изучении (чтении) текста группой специалистов [Fagan M. E. Design and Code Inspections to Reduce Errors in Program Development. – IBM Systems J., 1976, 15(3), p. 182–211.5]. При рассмотрении инспекций исходного текста внимание будет сосредоточено в основном на методах, процедурах, формах выполнения и т. д.

Инспектирующая группа включает обычно четыре человека, один из которых выполняет функции председателя. Председатель должен быть компетентным программистом, но не автором программы; он не должен быть знаком с ее деталями. В обязанности председателя входят подготовка материалов для заседаний инспектирующей группы и составление графика их проведения, ведение заседаний, регистрация всех найденных ошибок и принятие мер по их последующему исправлению. Председателя можно сравнить с инженером отдела технического контроля. Членами группы являются автор программы, проектировщик (если он не программист) и специалист по тестированию.

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

1. Программиста просят рассказать о логике работы программы. Во время беседы возникают вопросы, преследующие цель обнаружения ошибки. Практика показала, что даже только чтение своей программы слушателям представляется эффективным методом обнаружения ошибок и многие ошибки находит сам программист, а не другие члены группы. Этот феномен известен давно и часто его применяют для решения проблем. Когда решение неочевидно, то объяснение проблемы другому человеку заставляет разработчика «разложить все по полочкам» и решение «само приходит» к разработчику.
2. Программа анализируется по списку вопросов для выявления исторически сложившихся общих ошибок программирования.

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

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

В большинстве примеров описания процесса инспектирования утверждается, что во время инспекционного заседания ошибки не должны корректироваться. Однако существует и другая точка зрения [16]: «Вместо того, чтобы сначала сосредоточиться на основных проблемах проектирования, необходимо решить второстепенные вопросы. Два или три человека, включая разработчика программы, должны внести очевидные исправления в проект с тем, чтобы впоследствии решить главные задачи. Однако обсуждение второстепенных вопросов сконцентрирует внимание группы на частной области проектирования. Во время обсуждения наилучшего способа внесения изменений в проект кто-либо из членов группы может заметить еще одну проблему. Теперь группе придется рассматривать две проблемы по отношению к одним и тем же аспектам проектирования, объяснения будут полными и быстрыми. В течение нескольких минут целая область проекта может быть полностью исследована и любые проблемы станут очевидными… Как упоминалось выше, многие важные проблемы, возникавшие во время обзоров блок-схем, были решены в результате многократных безуспешных попыток решить вопросы, которые на первый взгляд казались тривиальными».

Время и место проведения инспекции должны быть спланированы так, чтобы избежать любых прерываний инспекционного заседания. Его оптимальная продолжительность, по-видимому, лежит в пределах от 90 до 120 мин. Так как это заседание является экспериментом, требующим умственного напряжения, увеличение его продолжительности ведет к снижению продуктивности. Большинство инспекций происходит при скорости, равной приблизительно 150 строк в час. При этом подразумевается, что большие программы должны рассматриваться за несколько инспекций, каждая из которых может быть связана с одним или несколькими модулями или подпрограммами.

Для того чтобы инспекция была эффективной, должны быть установлены соответствующие отношения. Если программист воспринимает инспекцию как акт, направленный лично против него, и, следовательно, занимает оборонительную позицию, процесс инспектирования не будет эффективным. Программист должен подходить к нему с менее эгоистических позиций [9]; он должен рассматривать инспекцию в позитивном и конструктивном свете: объективно инспекция является процессом нахождения ошибок в программе и таким образом улучшает качество его работы. По этой причине, как правило, рекомендуется результаты инспекции считать конфиденциальными материалами, доступными только участникам заседания. В частности, использование результатов инспекции руководством может нанести ущерб целям этого процесса.

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

2.3.2. Сквозные просмотры

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

Подобно инспекции, сквозной просмотр проводится как непрерывное заседание, продолжающееся один или два часа. Группа по выполнению сквозного просмотра состоит из 3–5 человек. В нее входят председатель, функции которого подобны функциям председателя в группе инспектирования, секретарь, который записывает все найденные ошибки, и специалист по тестированию. Мнения о том, кто должен быть четвертым и пятым членами группы, расходятся. Конечно, одним из них должен быть программист. Относительно пятого участника имеются следующие предположения: 1) высококвалифицированный программист; 2) эксперт по языку программирования; 3) начинающий (на точку зрения которого не влияет предыдущий опыт); 4) человек, который будет, в конечном счете, эксплуатировать программу; 5) участник какого-нибудь другого проекта; 6) кто-либо из той же группы программистов, что и автор программы.

Начальная процедура при сквозном просмотре такая же, как и при инспекции: участникам заранее, за несколько дней до заседания, раздаются материалы, позволяющие им ознакомиться с программой. Однако эта процедура отличается от процедуры инспекционного заседания. Вместо того, чтобы просто читать текст программы или использовать список ошибок, участники заседания «выполняют роль вычислительной машины». Лицо, назначенное тестирующим, предлагает собравшимся небольшое число написанных на бумаге тестов, представляющих собой наборы входных данных (и ожидаемых выходных данных) для программы или модуля. Во время заседания каждый тест мысленно выполняется. Это означает, что тестовые данные подвергаются обработке в соответствии с логикой программы. Состояние программы (т. е. значения переменных) отслеживается на бумаге или доске.

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

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

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

2.3.3. Проверка за столом

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

Большей частью проверка за столом является относительно непродуктивной. Это объясняется прежде всего тем, что такая проверка представляет собой полностью неупорядоченный процесс. Вторая, более важная причина заключается в том, что проверка за столом противопоставляется одному из принципов тестирования [Error: Reference source not found], согласно которому программист обычно неэффективно тестирует собственные программы. Следовательно, проверка за столом наилучшим образом может быть выполнена человеком, не являющимся автором программы (например, два программиста могут обмениваться программами вместо того, чтобы проверять за столом свои собственные программы), но даже в этом случае такая проверка менее эффективна, чем сквозные просмотры или инспекции. Данная причина является главной для образования группы при сквозных просмотрах или инспекциях исходного текста. Заседание группы благоприятствует созданию атмосферы здоровой конкуренции: участники хотят показать себя с лучшей стороны при нахождении ошибок. При проверке за столом этот, безусловно, ценный эффект отсутствует. Короче говоря, проверка за столом, конечно, полезна, но она гораздо менее эффективна, чем инспекция исходного текста или сквозной просмотр.

Поделитесь с Вашими друзьями: