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

Введение

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

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

Ошибки в публикации сгруппированы по темам:

• Административные;
• Программные;
• Пользовательские.

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

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

Административные

Иногда в 1С появляются ошибки и системные сообщения, которые приводят пользователя в растерянность. Не надо пугаться: любой из них есть логическое объяснение, и подсказки кроются в самих сообщениях.

В данном разделе собрана информация о так называемых «административных» ошибках. Их объединяет, что вызваны они не ошибками программного кода 1С или некорректными действиями пользователей, а административными настройками.

1C Отчетность: не удалось расшифровать файл

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

Читать статью полностью >>

1С удаление: указанная учетная запись уже существует

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

Читать статью полностью >>

Внутренняя ошибка компоненты dbeng8

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

Читать статью полностью >>

Конфигурация узла распределенной ИБ не соответствует ожидаемой

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

Читать статью полностью >>

Компонента 1С: Печать штрихкодов не установлена на данном компьютере

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

Читать статью полностью >>

Конфигурация базы данных не соответствует сохраненной конфигурации 1С

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

В статье описывается, что может быть этому причиной. Главное — не паниковать!

Читать статью полностью >>

Лицензия не обнаружена. Не обнаружен ключ защиты программы

При покупке 1С в комплект поставки включается лицензия на данное программное обеспечение. Лицензия может быть представлена в виде аппаратного ключа — специальной флешки для установки в USB-порт компьютера или программного ключа лицензии — пинкода программной защиты.

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

Читать статью полностью >>

Нарушение прав доступа

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

Читать статью полностью >>

Нарушение целостности системы 1С

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

Читать статью полностью >>

Начало сеанса с информационной базой запрещено

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

Читать статью полностью >>

Недостаточно памяти 1С

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

Читать статью полностью >>

Не найден файл внешней компоненты в 1С 8.3: как исправить

Ошибка Не найден файл внешней компоненты возникает при использовании в 1С дополнительных сервисов, например:

• Сервис Банковских выписок;
• Сервис мониторинга банков;
• Сервис регистрации;
• и т. д.

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

Читать статью полностью >>

Неверный формат хранилища данных 1С 8.3: как исправить

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

Читать статью полностью >>

Не обнаружена установленная версия 1С Предприятия

Ранее ошибка Не обнаружена установленная версия 1С Предприятия могла появиться при смене платформы 1С: Предприятие с 8.2 на 8.3. Кроме того, ошибка может возникнуть вследствие некорректной установки 1С, при переустановке операционной системы и по иным причинам. Во всех этих случаях файл, отвечающий за запуск платформы 1CEStart.cfg, начинает работать некорректно.

Из статьи вы узнаете, что тут можно сделать.

Читать статью полностью >>

Обнаружено неправомерное использование данного программного продукта

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

Читать статью полностью >>

Ошибка 1С: Начало сеанса с информационной базой запрещено

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

Читать статью полностью >>

Ошибка ввода пинкода. Пинкод не укомплектован

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

Читать статью полностью >>

Ошибка при выполнении операции с информационной базой 1С 8.3

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

Читать статью полностью >>

Ошибка формата потока

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

Читать статью полностью >>

Ошибка СУБД: файл базы данных поврежден

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

Читать статью полностью >>

Удаленный узел не прошел проверку в 1С: как исправить

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

Читать статью полностью >>

У пользователя недостаточно прав на исполнение операции

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

Читать статью полностью >>

Установка запрещена на основании системной политики

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

Читать статью полностью >>

Этот хост неизвестен 1С: как исправить

Ошибка Этот хост неизвестен возникает при подключении к серверу 1С и связана с тем, что в процессе запуска базы не удается определить IP-адрес сервера. В статье даются рекомендации по ее исправлению.

Читать статью полностью >>

Программные

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

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

Записи регистра сведений стали неуникальными

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

В статье дается подробная инструкция по поиску и исправлению ошибки.

Читать статью полностью >>

Метод объекта не обнаружен

БухЭксперт8 подготовил в статье 3 примера формирования ошибки Метод объекта не обнаружен. Вы познакомитесь с Синтаксис-помощником 1С, узнаете причины появления ошибки и получите рекомендации для ее исправления с использованием встроенной справки 1С.

Читать статью полностью >>

Неизвестный идентификатор формы

При работе с управляемыми формами 1С можно встретить ошибку Неизвестный идентификатор формы. Чаще всего ее причина — неправильное указание имени формы объекта в программном коде.

Читать статью полностью >>

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

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

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

Читать статью полностью >>

Поле объекта недоступно для записи

Ошибка Поле объекта недоступно для записи появляется при доработках программного кода и обновлениях программы. БухЭксперт8 подготовил внешние обработки, содержащие ошибки и способы их исправления, которые вы можете скачать.

Читать статью полностью >>

Поле объекта не обнаружено

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

Читать статью полностью >>

Переменная не определена

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

Читать статью полностью >>

Печатная форма недоступна 1С 8.3 при вызове внешней печатной формы

При подключении внешних печатных форм в 1С может появиться ошибка Печатная форма недоступна. В статье рассматривается порядок действий по исправлению ошибки.

Читать статью полностью >>

Слишком много фактических параметров

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

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

Читать статью полностью >>

Пользовательские

Большое количество забивается решеткой

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

Читать статью полностью >>

Значение поля номер не уникально

Ошибка Значение поля номер не уникально возникает при создании нового документа или справочника. При записи 1С автоматически присваивает объекту новый номер, но сохранить новые данные не может: где-то в журнале документов уже есть объект с таким же номером.

Причина этой ошибки чаще всего — ручное исправление номеров документов.

Читать статью полностью >>

Конфликт блокировок при выполнении транзакции

При работе в 1С может возникнуть ошибка Конфликт блокировок при выполнении транзакции: превышено максимальное время ожидания предоставления блокировки». В статье рассматривается, как ее исправить.

Читать статью полностью >>

Ошибка совместного доступа к файлу

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

Читать статью полностью >>

Ошибка печати в 1С: как исправить

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

Читать статью полностью >>

Регистрация конфигурации в центре лицензирования не выполнена

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

Читать статью полностью >>

Заключение

ПУТЕВОДИТЕЛЬ по ошибкам и их исправлению в 1С подготовлен командой профессионалов — консультантами и программистами БухЭксперт8. Сохраните эту страничку в социальных сетях или в закладках как шпаргалку. Пользуйтесь ею онлайн всегда, когда это будет необходимо.

Если вам понадобится дополнительная профессиональная помощь
в работе с 1С:Бухгалтерия 3.0
мы будем рады видеть вас на нашем курсе
Бухгалтерский и налоговый учет в 1С:Бухгалтерия 8 ред.3 от А до Я, ОСНО или УСН на ваш выбор

Если Вы еще не подписаны:

Активировать демо-доступ бесплатно →

или

Оформить подписку на Рубрикатор →

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

Подписывайтесь на наши YouTube и Telegram чтобы не пропустить
важные изменения 1С и законодательства

Помогла статья?

Получите еще секретный бонус и полный доступ к справочной системе БухЭксперт8 на 14 дней бесплатно

Мы собрали ответы экспертов 1С на частые вопросы по исправлению ошибок, допущенных в учете и отчетности по НДС, а также в бухгалтерском и налоговом учете для целей налогообложения прибыли. Рассказываем, как исправить ошибки и отразить исправления в «1С:Бухгалтерии 8» ред.3.0.

Как исправить ошибки в номерах, датах и суммах полученных счетов-фактур, зарегистрированных в прошлых налоговых периодах?

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

Об обмене электронными документами из «1С:Бухгалтерии 8» (ред. 3.0), применении УПД и УКД эксперты 1С рассказывали на лекции от 14.12.2017 в 1С:Лектории. 

Допущенные при регистрации счетов-фактур ошибки может обнаружить сам налогоплательщик, а может выявить налоговый орган при проведении камерального контроля (п. 3 ст. 88 НК РФ).

В первом случае налогоплательщику придется представить в налоговый орган уточненную налоговую декларацию с корректными сведениями. Несмотря на то, что обязанность по представлению уточненной декларации возникает только в случае, если допущенные ошибки привели к занижению суммы налога, подлежащей уплате в бюджет (п. 1 ст. 81 НК РФ), исправление сведений, ранее представленных в Разделе 8 декларации по НДС, возможно только путем представления уточненной налоговой декларации.

Во втором случае налогоплательщик получит от налогового органа сообщение с требованием представления пояснений (п. 2.7 Рекомендаций по проведению камеральных налоговых проверок, направленных письмом ФНС России от 16.07.2013 № АС-4-2/12705). В ответ на полученное сообщение налогоплательщик должен направить в налоговый орган пояснение с указанием корректных данных. При этом необходимость в последующем представлении уточненной декларации у налогоплательщика отсутствует, хотя ФНС России рекомендует это сделать (письмо от 06.11.2015 № ЕД-4-15/19395).

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

Ошибки, допущенные в прошлых налоговых периодах, исправляются путем аннулирования ошибочных регистрационных записей и внесения новых регистрационных записей в дополнительном листе книги покупок (п.п. 4, 9 Правил ведения книги покупок, утв. Постановлением Правительства РФ от 26.12.2011 № 1137 (далее — Постановление № 1137), письмо ФНС России от 30.04.2015 № БС-18-6/499@). Данные таких дополнительных листов используются для внесения изменений в налоговую декларацию по НДС (п. 6 Правил заполнения дополнительного листа книги покупок, утв. Постановлением № 1137).

Для исправления технических ошибок, допущенных при регистрации полученного счета-фактуры, в программе «1С:Бухгалтерия 8» редакции 3.0 используется документ Корректировка поступления (раздел Покупки) с видом операции Исправление собственной ошибки.

Документ можно создавать на основании документа Поступление (акт, накладная), в этом случае основные поля на закладке Главное и табличная часть на закладках Товары или Услуги будут заполнены сразу при открытии документа.

Операция Исправление собственной ошибки позволяет исправить ошибочно введенные реквизиты счета-фактуры:

• номер и дату;
• ИНН и КПП контрагента;
• код вида операции;
• суммовые и количественные показатели.

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

В блоке Исправление ошибок в реквизитах счета-фактуры:

• в строке Что исправляем автоматически проставляется гиперссылка на исправляемый документ Счет-фактура полученный;
• для реквизитов: Входящий номер, Дата, ИНН контрагента, КПП контрагента, Код вида операции формируются две колонки с показателями Старое значение и Новое значение, куда изначально автоматически переносятся соответствующие сведения из документа Счет-фактура полученный.

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

Рис. 1. Исправление технической ошибки, допущенной при регистрации полученного счета-фактуры 

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

В этом случае в поле Отражать корректировку следует установить значение Во всех разделах учета, если необходимо одновременно скорректировать данные бухгалтерского и налогового учета по налогу на прибыль и НДС.

Устранение ошибок, затрагивающих количественно-суммовые показатели, выполняется на закладках Товары или Услуги. Табличная часть Товары (Услуги) заполняется автоматически по документу-основанию.

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

В результате проведения документа Корректировка поступления с видом операции Исправление собственной ошибки:

• в строке Счет-фактура внизу документа появляется гиперссылка на новый автоматически созданный документ Счет-фактура полученный, который является, по сути, «техническим дубликатом» ранее введенного ошибочного документа по операции приобретения товаров. Все поля нового документа Счет-фактура полученный будут заполнены автоматически на основании сведений, указанных в документе Кор­ректировка поступления;
• вносятся записи в специальные регистры для целей учета НДС.

В дополнительном листе книги покупок будут отражены две записи:

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

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

В бухгалтерском учете ошибка предшествующего отчетного года, выявленная после утверждения бухгалтерской отчетности за этот год, исправляется в текущем отчетном периоде (п.п. 9, 14 Положения по бухгалтерскому учету «Исправление ошибок в бухгалтерском учете и отчетности» (ПБУ 22/2010), утв. приказом Минфина России от 28.06.2010 № 63н, далее — ПБУ 22/2010).

В налоговом учете, в том числе и для целей налогообложения прибыли, по общему правилу, в соответствии с пунктом 1 статьи 54 НК РФ, ошибки (искажения) исправляются в том периоде, в котором они были совершены. В то же время налогоплательщик вправе провести пересчет налоговой базы и суммы налога в том налоговом (отчетном) периоде, в котором выявлены ошибки (искажения), если:

• невозможно определить период совершения этих ошибок (искажений);
• такие ошибки (искажения) привели к излишней уплате налога.

Очевидно, что завышение суммы прямых расходов не могло привести к излишней уплате налога на прибыль за прошлый год. Налог за прошлый период не был излишне уплачен еще и потому, что у организации в прошлом году образовался убыток, следовательно, такие ошибки учитываются относительно налогового периода, в котором они были совершены (письмо Минфина России от 07.05.2010 № 03-02-07/1-225). Поэтому организация должна выполнить перерасчет налоговой базы и суммы налога за период совершения ошибки, а также представить в налоговый орган уточненную налоговую декларацию за прошлый год (абз. 1 п. 1 ст. 81 НК РФ).

В «1С:Бухгалтерии 8» редакции 3.0 ошибку прошлых лет, связанную с завышением расходов, можно исправить либо документом Корректировка поступления, либо документом Операция.

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

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

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

• в текущем периоде исправить ошибку только в бухгалтерском учете — записями по соответствующим счетам в корреспонденции со счетом 84 «Нераспределенная прибыль (непокрытый убыток)» или со счетом 91 «Прочие доходы и расходы» в зависимости от существенности ошибки (п.п. 9, 14 ПБУ 22/2010);
• для организаций, применяющих Положения по бухгалтерскому учету «Учет расчетов по налогу на прибыль организаций» ПБУ 18/02, утв. приказом Минфина России от 19.11.2002 № 114н (далее — ПБУ 18/02), отразить постоянную разницу (ПР). В данном случае под ПР понимаются доходы, формирующие бухгалтерскую прибыль отчетного периода, но не учитываемые при определении налоговой базы по налогу на прибыль как отчетного, так и последующих отчетных периодов;

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

Организация (на ОСНО, плательщик НДС, положения ПБУ18/02 не применяет) обнаружила ошибки: в прошлых отчетных периодах текущего года не все расходы были отражены в учете. Как и в каком периоде нужно зарегистрировать в программе соответствующие документы?

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

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

Таким образом, указанные расходы автоматически будут учтены при определении налоговой базы (прибыли) текущего отчетного (налогового) периода, которая в соответствии с пунктом 7 статьи 274 НК РФ определяется нарастающим итогом с начала года.

Поскольку в данной ситуации ошибки, допущенные в декларациях по налогу на прибыль за прошлые отчетные периоды текущего года, не привели к занижению суммы налога, подлежащей уплате, то организация не обязана представлять в ИФНС уточненные декларации за эти периоды (абз. 2 п. 1 ст. 81 НК РФ).

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

По мнению Минфина России (письмо от 24.03.2017 № 03-03-06/1/17177), такое неотражение является искажением налоговой базы предыдущего налогового периода, поэтому действовать надо в соответствии с положениями статьи 54 НК РФ. При этом, если в текущем отчетном (налоговом) периоде организация понесла убыток, то в этом периоде перерасчет налоговой базы невозможен, так как налоговая база признается равной нулю.

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

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

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

Что касается налога на добавленную стоимость, то налогоплательщики-покупатели имеют право заявлять налоговый вычет в пределах 3-х лет после принятия на учет приобретенных на территории РФ товаров, работ, услуг, имущественных прав (абз. 1 п. 1.1 ст. 172 НК РФ). Поэтому организация не обязана представлять уточненную декларацию по НДС.

Организация (применяет ОСНО и ПБУ 18/02) ошибочно не отразила в прошлом отчетном периоде текущего года принятие к учету основных средств (ОС) с применением амортизационной премии. Можно ли в программе автоматически исправить эту ошибку в периоде ее обнаружения (предыдущий отчетный период для корректировок закрыт)?

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

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

На закладке Амортизационная премия следует установить флаг Включить амортизационную премию в состав расходов.

При этом, если в действительности ОС было принято к учету в предыдущем отчетном периоде (например, в мае), данный факт хозяйственной жизни необходимо подтвердить первичными документами (приказом руководителя, актом о приеме-передаче объекта ОС, инвентарной карточкой объекта ОС), где зафиксированы соответствующие даты. Амортизация в программе начнет начисляться с августа. В этом же месяце в состав косвенных расходов будут включены расходы на капитальные вложения в размере не более 10 % (не более 30 % — в отношении ОС, относящихся к 3-7 амортизационным группам) первоначальной стоимости ОС (п. 9 ст. 258, п. 3 ст. 272 НК РФ).

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

Рис. 2. Корректировка начисленной амортизации ОС

В данной ситуации можно не уточнять налог на прибыль за полугодие. Но, если в организации зарегистрированы обособленные подразделения (ОП), допущенная во II квартале ошибка могла повлиять на расчет долей прибыли за указанный период. Если указанное ОС является объектом налогообложения налога на имущество организаций, и законодательным органом субъекта РФ установлены отчетные периоды, то организация обязана представить уточненную декларацию по налогу на имущество за полугодие.

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

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

СТОРНО Дебет 08.04.1 Кредит 60.01— на сумму корректировки стоимости ОС;

СТОРНО Дебет 01.01 Кредит 08.04.1— на сумму корректировки стоимости ОС;

СТОРНО Дебет 20.01 (26, 44) Кредит 02.01— на сумму корректировки амортизации за май, июнь, июль текущего года;

Дебет 20.01 (26, 44) Кредит 02.01— на сумму амортизации за август текущего года с учетом скорректированной первоначальной стоимости ОС.

Для целей налогового учета по налогу на прибыль соответствующие суммы фиксируются также в ресурсах Сумма НУ Дт и Сумма НУ Кт. Чтобы в дальнейшем амортизация в бухгалтерском и налоговом учете начислялась с учетом внесенных корректировок, параметры амортизации нужно уточнить с помощью документа Изменение параметров амортизации ОС (раздел ОС и НМА — Параметры амортизации ОС). Документ следует также создать в августе (рис. 3). При вводе документа Изменение параметров амортизации ОС в шапке нужно указать следующие реквизиты:

• наименование события в «жизни» основного средства, которое отражается данным документом;
• установить флаги Отражать в бухгалтерском учете и Отражать в налоговом учете.

Рис. 3. Изменение параметров амортизации ОС

В табличном поле нужно указать:

• основное средство, у которого изменяются параметры начисления амортизации из-за обнаруженной ошибки;
• в поле Срок использ. (БУ) — срок полезного использования основного средства в бухучете в месяцах, первоначально установленный организацией при принятии к учету, например 62 месяца;
•  в поле Срок для аморт. (БУ) — оставшийся срок полезного использования для начисления амортизации в бухгалтерском учете. Данный СПИ рассчитывается как первоначально установленный СПИ за вычетом количества месяцев начисления амортизации за май-август (62 мес. — 4 мес. = 58 мес.);
• в поле Стоимость для вычисления аморт. (БУ) — оставшаяся стоимость ОС для начисления амортизации в бухгалтерском учете. Данная стоимость рассчитывается как скорректированная первоначальная стоимость ОС за вычетом начисленной амортизации за май-август;
• в поле Срок использ. (НУ) — срок полезного использования в месяцах для начисления амортизации в налоговом учете. В указанной ситуации этот срок не меняется.

Начиная с сентября при выполнении регламентной операции Амортизация и износ основных средств прог­рамма будет рассчитывать амортизацию согласно уточненным параметрам.

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

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

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

Сначала разберемся, можно ли признать ошибкой учет ТМЦ по ценам, указанным в первоначальных первичных документах. В соответствии с пунктом 2 ПБУ 22/2010, не являются ошибками неточности или пропуски в отражении фактов хозяйственной деятельности, выявленные в результате получения новой информации, которая не была доступна организации на момент отражения (неотражения) таких фактов. На момент получения ТМЦ и списания их в производство в предыдущих налоговых периодах организация корректно отражала все доходы и расходы. Подписанное с поставщиком соглашение об изменении цены товара является независимым событием, которое не является ошибкой в бухгалтерском учете. Таким образом, при отражении в бухгалтерском учете изменения цены ТМЦ правила ПБУ 22/2010 не применяются.

В бухгалтерском учете прибыль прошлых лет, выявленная в отчетном году, включается в состав прочих доходов (прочих поступлений). Прочие поступления признаются по мере их выявления и подлежат зачислению на счет прибылей и убытков организации (п.п. 7, 11, 16 Положения по бухгалтерскому учету «Доходы организации» ПБУ 9/99, утв. приказом Минфина России от 06.05.1999 № 32н, далее — ПБУ 9/99). А как быть с налогом на прибыль? НК РФ не раскрывает понятия «ошибки (искажения)», поэтому данное понятие следует использовать в том значении, в каком оно используется в законодательстве о бухгалтерском учете (п. 1 ст. 11 НК РФ), и Минфин России с этим соглашается (письмо от 30.01.2012 № 03-03-06/1/40). Несмотря на это, контролирующие органы настаивают на корректировке налоговой базы по налогу на прибыль в прошлых периодах при уменьшении цены на проданный товар:

• при отражении в налоговой базе покупателя скидки, предоставленной ему путем пересмотра цены товара, у данного налогоплательщика налогооблагаемого дохода не возникает (пп. 19.1 п. 1 ст. 265 НК РФ не применяется). Необходимо пересчитать стоимость сырья и материалов в налоговом учете с учетом изменения цены, в том числе путем пересчета средней стоимости соответствующих ТМЦ начиная с периода оприходования до момента списания (письмо Минфина России от 20.03.2012 № 03-03-06/1/137);
• изменения показателей доходов или расходов, возникшие в связи с изменением цены договора, в том числе в связи с предоставлением скидок, учитываются в порядке, предусмотренном статьей 54 НК РФ, т. е. как при обнаружении ошибки (письмо Минфина России от 22.05.2015 № 03-03-06/1/29540).

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

Поскольку в рассматриваемой ситуации корректировка налогового учета затрагивает несколько прошлых налоговых периодов, в программе целесообразно воспользоваться последовательностью действий, описанных ранее: с помощью документа Операция отразить доходы прошлых лет в бухгалтерском учете, в специальных ресурсах для целей налогового учета отразить ПР (если организация применяет положения ПБУ18/02), затем вручную составить регистры налогового учета, куда приложить расчеты корректировок налоговой базы по каждому налоговому периоду.

В отношении НДС — ситуация намного проще. При получении от поставщика корректировочного счета-фактуры на уменьшение стоимости ТМЦ, покупатель должен:

• восстановить часть входного НДС, принятого к вычету при оприходовании ТМЦ. Восстановление НДС нужно выполнить в том налоговом периоде, на который приходится наиболее ранняя из следующих дат: дата получения дополнительного соглашения на уменьшение стоимости ТМЦ либо дата получения корректировочного счета-фактуры (пп. 4 п. 3 ст. 170 НК РФ). В нашей ситуации — это III квартал;
• отразить в книге продаж документ, полученный первым (п. 14 Правил ведения книги продаж, утв. Постановлением № 1137).

Данные операции автоматически выполняются с помощью документа Корректировка поступления с видом операции Корректировка по согласованию сторон.

Чтобы не затрагивать бухгалтерский и налоговый учет, на закладке Главное в поле Отражать корректировку следует установить значение Только в учете НДС.

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

По мнению контролирующих органов, при обнаружении нескольких ошибок (искажений), повлекших как занижение, так и завышение налоговой базы и суммы налога, относящихся к прошлым налоговым (отчетным) периодам, налоговая база и сумма налога уточняются в разрезе каждой обнаруженной ошибки (письмо Минфина России от 15.11.2010 № 03-02-07/1-528).

Перерасчет налоговой базы и суммы налога производится в соответствии с абзацами 2 и 3 пункта 1 статьи 54 НК РФ.

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

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

Изменения в данные налогового учета вносятся:

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

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

Данный документ автоматически исправляет все ошибки прошлых лет в упрощенном порядке, который установлен для несущественных ошибок согласно пунктам 9 и 14 ПБУ 22/2010.

Для исправления НДС необходимо зарегистрировать новый (исправленный) экземпляр счета-фактуры (п. 7 Правил заполнения счетов-фактур, утв. Постановлением № 1137). В дополнительном листе книги продаж автоматически будут отражены две записи (п. 3 Правил заполнения дополнительного листа книги продаж, утв. Постановлением № 1137):

• аннулирование записи по выставленному счету-фактуре, содержащему ошибки;
• регистрационная запись по исправленному счету-фактуре.

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

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

Способы выявления и устранения программных сбоев

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

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

Тем не менее попробовать избавиться от сбоев можно выполнением некоторых действий в такой последовательности.

• Анализ журнала событий. Любые события, несущие важные сведения, в том числе и ошибки программ, фиксируются в специальном системном журнале событий, который пользователь всегда может просмотреть и проанализировать. Чтобы получить к нему доступ, щелкните правой кнопкой мыши на значке Компьютер и в появившемся меню выберите пункт Управление. Далее откроется окно, в левой части которого необходимо раскрыть ветвь дерева Просмотр событий ► Журналы Windows. Все события отсортированы и разделены на пять групп, названия которых говорят сами за себя. Отследив порядок появления интересующего вас сбоя, можно вычислить его причину, а затем воспользоваться соответствующим способом его устранения.
• Исправление системного реестра. Чем сложнее программа, тем больше вероятность, что она активно работает с реестром: сохраняет в нем нужные ей данные, а также использует их для своей инициализации и работы. Поэтому, если какая-то из программ «случайно» произвела некорректные изменения в той части реестра, в которой хранились нужные для первой программы данные, это может стать причиной ее неработоспособности или появления непонятных ошибок. Выход из ситуации — запуск специализированной утилиты, которая устранит все ошибки в реестре.
• Замена драйвера. Немалую часть программных сбоев способны вызвать устаревшие драйверы устройств либо драйверы, которые пытаются расширить стандартную функциональность устройства, например включив возможность разгона видеокарты путем разблокировки механизма управления частотами. Если оборудование довольно новое, «правильный» драйвер всегда можно скачать с веб-сайта производителя этого оборудования.
• Переустановка программы. Вычислив источник появления программного сбоя, то есть программу, которая его инициирует, можно попробовать ее переустановить. Это действие способно дать эффект, особенно если программа долго работала без сбоев и проблемы начались лишь недавно. Если же программа сбоит постоянно, лучше отказаться от ее использования либо найти ее новую версию или альтернативу.
• Апгрейд программы. Программа, написанная для работы в операционной системе Windows ХР или даже Windows 98, изначально не подготовлена к работе в Windows 7/8. Поэтому, даже если запуск программы не был отвергнут системой из-за несовместимости, ее правильное функционирование будет под вопросом. Если причина именно в этом, лучшим решением будет переход на более новую версию программы либо замена ее альтернативным по функцио-нальности приложением.
• Запуск в режиме совместимости. Если вы перешли на операционную систему Windows 7/8, но по какой-то причине не можете купить другую версию программы, которая успешно работала в Windows ХР, а в новой системе отказывается это делать или функционирует со сбоями, можно попробовать запускать ее в специальном режиме. Так, начиная с версии Windows 7, операционная система позволяет запускать программу в режиме совместимости с более ранними операционными системами, вплоть до Windows 95, хотя полной совместимости добиться невозможно. Чтобы выбрать режим совместимости, щелкните правой кнопкой мыши на ярлыке с программой, перейдите на вкладку Совместимость и выберите из списка нужную позицию.
• Изменение прав доступа. Часто программные сбои и разного рода ошибки возникают в процессе работы программ в составе сети с доменом, когда у пользователя имеется самый простой набор прав доступа к ресурсам компьютера и сети. Большая часть программ, особенно непрофессионального уровня, не рассчитаны на подобное стечение обстоятельств и требуют максимального доступа к ресурсам. Выходом из этой ситуации является расширение прав доступа, например перевод пользователя в группу Опытные пользователи. Это может сделать только администратор сети или человек, знающий пароль администратора сети или локального администратора. Иногда Windows преднамеренно блокирует доступ к системному разделу диска, особенно к его корневой структуре. В этом случае в качестве рабочей папки программы можно использовать папку в любом другом, несистемном разделе диска.
• Перезапуск программы. Да, как ни странно, но закрытие программы с последующим ее открытием может устранить возникшую проблему. Например, при просмотре интернет-страниц, особенно активно использующих flash-технологии, браузер Internet Explorer (до 8-й версии программы) может настолько раздуть файл подкачки, что это будет мешать не только его работе, но и функционированию остальных запущенных программ.

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

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

Источник

Учебные материалы.. первая помощь в учебе.

Введение
Данная работа посвящена описанию методов обнаружения и устранения ошибок, позволяющих существенно повысить качество программного обеспечения встраиваемых систем и сэкономить материально-временные ресурсы, затрачиваемые на отладку систем. Рассматриваемые методы без особого труда могут быть использованы при разработке самых разных проектов программного обеспечения встраиваемых систем, причем накопленный опыт полностью сохраняет свою ценность и при реализации других проектов и целевых технологий. Кроме того, они позволяют гарантировать простоту сопровождения, модификации и переноса созданных программ в устройства новых типов. Вкратце, рассматриваемые методы дают возможность не только совершенствовать существующие встроенные приложения и процессы разработки, но и гарантировать, что с распространением новых встраиваемых устройств у вас уже будет накоплен опыт, необходимый для разработки высокоэффективных приложений для этих технологий причем вовремя и в рамках выделенных средств.
Ни для кого не секрет, что отлаживать программы для встраиваемых систем чрезвычайно тяжело. Отладка сама по себе далеко не курорт, а отладка программного обеспечения встраиваемых систем предъявляет к тому же особые требования. Прежде всего, из встроенных систем очень трудно извлекать требуемую информацию. Процесс отладки, как правило, строится на основе выводимой приложением информации и соответствующей обратной связи со стороны программиста, а у программ встроенных систем нет возможности сделать распечатку изображений экрана, которой могут пользоваться разработчики другого типа программного обеспечения.
Из этой неприятной ситуации нужно как-то выходить. Одно из возможных решений подключение специального оборудования к модулю, представляющему собой набор аппаратных средств, для которых и пишется отлаживаемое программное обеспечение. Это специальное оборудование дает разработчику возможность увидеть, что происходит с его программным обеспечением. Например, так называемые мониторы памяти позволяют заносить информацию в отдельные области памяти, считывать в монитор содержимое памяти и использовать содержимое памяти монитора для анализа состояния системы в момент ее краха. Кроме того, встраиваемые системы могут отлаживаться с помощью систем моделирования, представляющих собой программные среды, в которых отлаживаемые программы исполняются так же, как они будут исполняться в целевой системе.
Системы моделирования обладают множеством достоинств. Обычно в их составе имеются отладчики и средства вывода информации на печать, однако системы моделирования это всего лишь имитаторы. Отлаживаемая программа может успешно исполняться в системе моделирования и быть полностью неработоспособной в реальных условиях. Так что системы моделирования это лишь частичное решение. Ошибки программного обеспечения вполне могут пройти мимо системы моделирования и всплыть в реальном оборудовании.
Именно в этом и скрыта главная проблема: как показано на рис. 1, исправление ошибок, которые выявляются не на этапе тестирования, а в процессе использования, обходится значительно дороже. Если ошибка найдена в программе для не-встраиваемых систем, то можно выпустить обновленную версию программы с исправлениями, стоимость таких обновлений, как правило, сравнительно невысокая. Если же ошибка найдена во встроенной системе, то для ее исправления необходим возврат и модификация самих устройств с этой системой. Стоимость такого возврата может достигать астрономических величин, и стать причиной разорения компаний.

Рис. 1. Стоимость устранения ошибок во встраиваемых системах

На мой взгляд, сроки и затраты на выявление и устранение ошибок для встраиваемых систем приблизительно удваиваются (из-за описанных выше трудностей). В свете таких немыслимых затрат любой метод, который изначально будет препятствовать появлению ошибок, имеет неоценимое значение. К счастью для разработчиков встраиваемых систем, для предотвращения ошибок можно использовать некоторые из новых технологий программной разработки. Наиболее рекомендуемые две из них: стандарты программирования и блочное тестирование.
Правда, оба этих метода сегодня не столько применяются, сколько прославляются. Практически каждый разработчик программного обеспечения согласен с их высокой ценностью, но пользуются ими единицы. Подобная непоследовательность объясняется в большинстве случаев двумя причинами. Прежде всего, многие считают следование стандартам программирования и блочное тестирование весьма утомительным делом. Учитывая, сколько времени и сил эти подходы позволяют сэкономить в будущем, разработчикам следовало бы немножко потерпеть и избежать огромных трудозатрат (и возможного отказа от проекта) впоследствии.
Разработчикам систем реального времени еще труднее они в дополнение ко всему должны решать проблемы, связанные с соблюдением различных временных зависимостей. В конце статьи мы рассмотрим трудности, возникающие при отладке систем реального времени, и познакомимся с некоторыми методами отладки, которые рассчитаны на преодоление этих трудностей и которые также могут быть использованы при разработке любого программного обеспечения.
Способы отладки программ
Отладка программ заключается в проверке правильности работы программы и аппаратуры. Программа, не содержащая синтаксических ошибок тем не менее может содержать логические ошибки, не позволяющие программе выполнять заложенные в ней функции. Логические ошибки могут быть связаны с алгоритмом программы или с неправильным пониманием работы аппаратуры, подключённой к портам микроконтроллера.
Встроенный в состав интегрированной среды программирования отладчик позволяет отладить те участки кода программы, которые не зависят от работы аппаратуры, не входящей в состав микросхемы микроконтроллера. Обычно это относится к вычислению математических выражений или преобразованию форматов представления данных.
Для отладки программ обычно применяют три способа: Пошаговая отладка программ с заходом в подпрограммы; Пошаговая отладка программ с выполнением подпрограммы как одного оператора; Выполнение программы до точки останова.
Пошаговая отладка программ заключается в том, что выполняется один оператор программы и, затем контролируются те переменные, на которые должен был воздействовать данный оператор.
Если в программе имеются уже отлаженные подпрограммы, то подпрограмму можно рассматривать, как один оператор программы и воспользоваться вторым способом отладки программ.
Если в программе существует достаточно большой участок программы, уже отлаженный ранее, то его можно выполнить, не контролируя переменные, на которые он воздействует. Использование точек останова позволяет пропускать уже отлаженную часть программы. Точка останова устанавливается в местах, где необходимо проверить содержимое переменных или просто проконтролировать, передаётся ли управление данному оператору.
Практически во всех отладчиках поддерживается это свойство (а также выполнение программы до курсора и выход из подпрограммы). Затем отладка программы продолжается в пошаговом режиме с контролем локальных и глобальных переменных, а также внутренних регистров микроконтроллера и напряжений на выводах этой микросхемы. Следуйте стандартам программирования!

Источник

Устранение программных сбоев

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

Первая помощь при сбоях: способы исправления

1. Вначале следует проанализировать сбои для того, чтобы определить, какие из способов подойдут для решения данной проблемы. Так, например, есть программа-утилита WhatIsHang, благодаря которой можно узнать причину сбоя. Случается, что проблемы возникают из-за некорректного завершения рабочих процессов. Для этого также можно использоваться утилиту AppCrashView, которая просмотрит и проанализирует все отчеты об ошибках, которые выдаются системой.
2. Отключение медленных и нестабильно работающих программ. Случается, что программа просто зависает – это не очень опасно, но если она тянет за собой всю ОС? Как известно, избыточное количество процессов просто тормозят систему, для чего следует применять утилиту Startup Booster. После этого можно удалить некоторые из процессов, которые, например, занимаются чисто обновлением программ. Есть такая программа, как AntiFreeze, которая необходима тогда, когда системный диспетчер задач перестает реагировать на ваши запросы. Правда, она не работает тогда, когда возникает некорректная работа драйверов.
3. Убираем «остатки» драйверов и программ. Многие средства для удаления программ не очищают реестр, а потому эти «остатки» могут значительно тормозить все системы и используемые программы. Между прочим, Windows совершенно не заботит то, что многие применяемые ранее драйверы уже не имеют актуальности, а потому и не чистит их.
4. Многие проблемы возникают из-за того, что установленные антивирусные программы не совместимы с системой. Это также возникает тогда, когда используются компоненты и утилиты от разных фирм, потому старайтесь устанавливать ПО одного производителя.

Самостоятельно решать проблему?

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

Источник

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

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

Виды машинного обучения

Классическое обучение

Принцип постановки данного эксперимента

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

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

Различают два варианта: (1) когда реакция испытываемой системы не изменяет состояние внешней среды, и (2) когда реакция системы изменяет стимулы внешней среды. Эти схемы указывают принципиальное сходство такой системы общего вида с биологической нервной системой.

Типология задач обучения с учителем

Типы входных данных

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

Типы откликов

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

Вырожденные виды систем управления подкреплением («учителей»)

• Система подкрепления с управлением по реакции (R — управляемая система) — характеризуется тем, что информационный канал от внешней среды к системе подкрепления не функционирует. Данная система несмотря на наличие системы управления относится к спонтанному обучению, так как испытуемая система обучается автономно, под действием лишь своих выходных сигналов независимо от их «правильности». При таком методе обучения для управления изменением состояния памяти не требуется никакой внешней информации;
• Система подкрепления с управлением по стимулам (S — управляемая система) — характеризуется тем, что информационный канал от испытываемой системы к системе подкрепления не функционирует. Несмотря на не функционирующий канал от выходов испытываемой системы относится к обучению с учителем, так как в этом случае система подкрепления (учитель) заставляет испытываемую систему вырабатывать реакции согласно определенному правилу, хотя и не принимается во внимание наличие истиных реакций испытываемой системы.

Данное различие позволяет более глубоко взглянуть на различия между различными способами обучения, так как грань между обучением с учителем и обучением без учителя более тонка. Кроме этого, такое различие позволило показать дляискусственных нейронных сетей определенные ограничения для S и R — управляемых систем (см. Теорема сходимости перцептрона).

Обучение с учителем

Обучение с учителем (supervised learning) предполагает наличие полного набора размеченных данных для тренировки модели на всех этапах ее построения.

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

Пример обучения с учителем — классификация (слева), и дальнейшее ее использование для сегментации и распознавания объектов

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

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

А вот задачи регрессии связаны с непрерывными данными. Один из примеров, линейная регрессия, вычисляет ожидаемое значение переменной y, учитывая конкретные значения x.

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

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

Классическое обучение любят делить на две категории — с учителем и без. Часто можно встретить их английские наименования — Supervised и Unsupervised Learning.

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

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

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

4 комментария

Классификация

«Разделяет объекты по заранее известному признаку. Носки по цветам, документы по языкам, музыку по жанрам»

Сегодня используют для:

• Спам-фильтры
• Определение языка
• Поиск похожих документов
• Анализ тональности
• Распознавание рукописных букв и цифр
• Определение подозрительных транзакций

Популярные алгоритмы: Наивный Байес, Деревья Решений, Логистическая Регрессия, K-ближайших соседей, Машины Опорных Векторов

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

6 комментариев

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

Старый доклад Бобука про повышение конверсии лендингов с помощью SVM

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

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

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

Возьмем другой пример полезной классификации. Вот берете вы кредит в банке . Об этом говорит сайт https://intellect.icu . Как банку удостовериться, вернете вы его или нет? Точно никак, но у банка есть тысячи профилей других людей, которые уже брали кредит до вас. Там указан их возраст, образование, должность, уровень зарплаты и главное — кто из них вернул кредит, а с кем возникли проблемы.

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

Для этой задачи придумали Деревья Решений. Машина автоматически разделяет все данные по вопросам, ответы на которые «да» или «нет». Вопросы могут быть не совсем адекватными с точки зрения человека, например «зарплата заемщика больше, чем 25934 рубля?», но машина придумывает их так, чтобы на каждом шаге разбиение было самым точным.

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

Деревья нашли свою нишу в областях с высокой ответственностью: диагностике, медицине, финансах.

Два самых популярных алгоритма построения деревьев — CART и C4.5.

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

Но самым популярным методом классической классификации заслуженно является Метод Опорных Векторов (SVM). Им классифицировали уже все: виды растений, лица на фотографиях, документы по тематикам, даже странных Playboy-моделей. Много лет он был главным ответом на вопрос «какой бы мне взять классификатор».

Идея SVM по своей сути проста — он ищет, как так провести две прямые между категориями, чтобы между ними образовался наибольший зазор. На картинке видно нагляднее:

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

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

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

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

Регрессия

«Нарисуй линию вдоль моих точек. Да, это машинное обучение»

Сегодня используют для:

• Прогноз стоимости ценных бумаг
• Анализ спроса, объема продаж
• Медицинские диагнозы
• Любые зависимости числа от времени

Популярные алгоритмы: Линейная или Полиномиальная Регрессия

Регрессия — та же классификация, только вместо категории мы предсказываем число. Стоимость автомобиля по его пробегу, количество пробок по времени суток, объем спроса на товар от роста компании и.т.д. На регрессию идеально ложатся любые задачи, где есть зависимость от времени.

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

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

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

Для желающих понять это глубже, но тоже простыми словами, рекомендую цикл статей Machine Learning for Humans

метод коррекции ошибки

Эта статья о нейросетях; о коррекции ошибок в информатике см.: обнаружение и исправление ошибок.

Метод коррекции ошибки — метод обучения перцептрона, предложенный Фрэнком Розенблаттом. Представляет собой такой метод обучения, при котором вес связи не изменяется до тех пор, пока текущая реакция перцептрона остается правильной. При появлении неправильной реакции вес изменяется на единицу, а знак (+/-) определяется противоположным от знака ошибки.

Модификации метода

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

Метод коррекции ошибок без квантования

Если реакция на стимул правильная, то никакого подкрепления не вводится, но при появлении ошибок к весу каждого активного А-элемента прибавляется величина , где — число единиц подкрепления, выбирается так, чтобы величина сигнала превышала порог θ, а , при этом — стимул, принадлежащий положительному классу, а — стимул, принадлежащий отрицательному классу.

Метод коррекции ошибок с квантованием

Отличается от метода коррекции ошибок без квантования только тем, что , то есть равно одной единице подкрепления.

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

Метод коррекции ошибок со случайным знаком подкрепления

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

Метод коррекции ошибок со случайными возмущениями

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

метод обратного распространения ошибки .

Метод обратного распространения ошибки (англ. backpropagation)— метод обучения многослойного перцептрона. Впервые метод был описан в 1974 г. А.И. Галушкиным , а также независимо и одновременно Полом Дж. Вербосом . Далее существенно развит в 1986 г. Дэвидом И. Румельхартом, Дж. Е. Хинтоном и Рональдом Дж. Вильямсом и независимо и одновременно С.И. Барцевым и В.А. Охониным (Красноярская группа) .. Это итеративный градиентный алгоритм, который используется с целью минимизации ошибки работы многослойного перцептрона и получения желаемого выхода.

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

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

Сигмоидальные функции активации

Наиболее часто в качестве функций активации используются следующие виды сигмоид:

Функция Ферми (экспоненциальная сигмоида):

Рациональная сигмоида:

Гиперболический тангенс:

,

где s — выход сумматора нейрона, — произвольная константа.

Менее всего, сравнительно с другими сигмоидами, процессорного времени требует расчет рациональной сигмоиды. Для вычисления гиперболического тангенса требуется больше всего тактов работы процессора. Если же сравнивать с пороговыми функциями активации, то сигмоиды рассчитываются очень медленно. Если после суммирования в пороговой функции сразу можно начинать сравнение с определенной величиной (порогом), то в случае сигмоидальной функции активации нужно рассчитать сигмоид (затратить время в лучшем случае на три операции: взятие модуля, сложение и деление), и только потом сравнивать с пороговой величиной (например, нулем). Если считать, что все простейшие операции рассчитываются процессором за примерно одинаковое время, то работа сигмоидальной функции активации после произведенного суммирования (которое займет одинаковое время) будет медленнее пороговой функции активации как 1:4.

Функция оценки работы сети

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

,

где — требуемое значение выходного сигнала.

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

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

Архитектура многослойного перцептрона

Алгоритм обратного распространения ошибки применяется для многослойного перцептрона. У сети есть множество входов , множество выходов Outputs и множество внутренних узлов. Перенумеруем все узлы (включая входы и выходы) числами от 1 до N (сквозная нумерация, вне зависимости от топологии слоев). Обозначим через вес, стоящий на ребре, соединяющем i-й и j-й узлы, а через — выход i-го узла. Если нам известен обучающий пример (правильные ответы сети , ), то функция ошибки, полученная по методу наименьших квадратов, выглядит так:

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

,

где — множитель, задающий скорость «движения».

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

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

где — соответствующая сигмоида, в данном случае — экспоненциальная

Если же j-й узел — не на последнем уровне, то у него есть выходы; обозначим их через Children(j). В этом случае

,

и

.

Ну а — это в точности аналогичная поправка, но вычисленная для узла следующего уровня будем обозначать ее через — от она отличается отсутствием множителя . Поскольку мы научились вычислять поправку для узлов последнего уровня и выражать поправку для узла более низкого уровня через поправки более высокого, можно уже писать алгоритм. Именно из-за этой особенности вычисления поправок алгоритм называется алгоритмом обратного распространения ошибки (backpropagation). Краткое резюме проделанной работы:

• для узла последнего уровня

• для внутреннего узла сети

• для всех узлов

, где это тот же в формуле для

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

Алгоритм

Алгоритм: BackPropagation

1. Инициализировать маленькими случайными значениями,
2. Повторить NUMBER_OF_STEPS раз:

   Для всех d от 1 до m:

   1. Подать на вход сети и подсчитать выходы каждого узла.
   2. Для всех

      .

   3. Для каждого уровня l, начиная с предпоследнего:

      Для каждого узла j уровня l вычислить

      .

   4. Для каждого ребра сети {i, j}

      .

      .

3. Выдать значения .

где — коэффициент инерциальнности для сглаживания резких скачков при перемещении по поверхности целевой функции

Математическая интерпретация обучения нейронной сети

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

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

Недостатки алгоритма

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

Паралич сети

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

Локальные минимумы

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

Размер шага

Внимательный разбор доказательства сходимости показывает, что коррекции весов предполагаются бесконечно малыми. Ясно, что это неосуществимо на практике, так как ведет к бесконечному времени обучения. Размер шага должен браться конечным. Если размер шага фиксирован и очень мал, то сходимость слишком медленная, если же он фиксирован и слишком велик, то может возникнуть паралич или постоянная неустойчивость. Эффективно увеличивать шаг до тех пор, пока не прекратится улучшение оценки в данном направлении антиградиента и уменьшать, если такого улучшения не происходит. П. Д. Вассерман описал адаптивный алгоритм выбора шага, автоматически корректирующий размер шага в процессе обучения. В книге А. Н. Горбаня предложена разветвленная технология оптимизации обучения.

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

См. также

• Обучение без учителя
• Обучение с подкреплением
• Обучение на примерах
• Задачи прогнозирования
• обучение без учителя , алгоритм k-means , обучение с частичным привлечением учителя ,

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

Ответы на вопросы для самопроверки пишите в комментариях, мы проверим, или же задавайте свой вопрос по данной теме.

Автор: Scott Berkun

Перевод: Андрей Олищук

Материал публикуется при согласии редакции электронного журнала для веб разработчиков PHP Inside.

Статья переведена с разрешения ONLamp.com

В работе с ошибками есть одно золотое правило: исправлять ошибки нужно в том порядке, который вероятнее всего приближает к успеху. Звучит банально, не правда ли? Неправда. Могу поспорить, что свыше половины «глючных» и ненадёжных программ, которые вам приходилось использовать, были такими не потому, что разработчикам не хватило времени сделать их лучше. Просто они исправляли не те ошибки. Желание исправить «нужные» ошибки и знание того, каким образом это сделать, — две разные вещи.

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

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

Это эссе, состоящее из двух частей, является своеобразным учебником для использования таких правил и неприкосновенных запасов. Даже больше — я поделюсь с вами идеями, на основании которых вы сможете создавать свои собственные правила. Мои рекомендации состоят из четырех уровней — от отрывочных советов по оказанию «первой помощи» (Уровень 1) до крупномасштабного планирования (Уровень 4). Но перед тем как начать, рассмотрим список неправильных подходов, которых следует избегать при принятии решений о правке ошибок.

Вот десять худших способов принятия решений:

1. Править только те ошибки, которые раздражают вашего директора;
2. Править все ошибки (никогда не успеете);
3. Не править ошибок вовсе (зато успеете сдать систему уже сегодня!);
4. Править только те ошибки, которые раздражают жену/дочь/хомяка вашего босса;
5. Требовать согласования каждого решения самым надоедливым и недалёким человеком в вашей организации (возможно, пересекается с подходом №1);
6. Начать править случайно выбранную ошибку и, остановившись на полпути, перейти к другой. По завершению повторить;
7. Бояться ошибок. Не править их и свалить все на кого-нибудь другого;
8. Расставить ошибки в алфавитном порядке и править их от А до Я, исключая гласные. При соответствующем подходе к именованию ошибок этот подход может превратиться в №3;
9. Создать сложную избирательную систему представителей, выбираемых двумя третями большинства для написания проекта регламента по формированию трёх двусторонних комитетов, наделённых полномочиями по модерированию будущих дисскуссий на тему стратегического управления ошибками;
10. Тратить все имеющееся время на споры о том, похож ли ваш текущий подход на что либо из только что приведённого списка.

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

1. Первая помощь

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

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

Универсальное правило — гораздо проще работать с тремя-четырьмя группами, чем с сотнями или тысячами отдельных вещей.

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

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

Прежде чем вы пропустите эти строки со словами «Я знаю о сортировке, но не делаю её по такой-то и такой-то причине», учтите, что сортировка необходима для оздоровления в процессе оказания первой помощи в любом из смыслов — медицинском или техническом. Нет смысла лепить лейкопластырь на коленку больного, если у него из спины торчит полдюжины отравленных стрел. Без сортировки вы не будете точно знать, на что потратить энергию команды наилучшим образом. В отличие от пациента, исступленными жестами привлекающего ваше внимание к своей спине с незваными стрелами, ваша база кода не скажет, где у нее болит больше всего. Вам нужно определить это самостоятельно. Усилия по сортировке важности ошибок имеют еще и несколько полезных последствий. Разбираясь с ошибками, лидер вынуждает всех улучшать своё видение проекта в целом. Он обнаруживает множество дублирующихся ошибок, уже исправленные ошибки, нехватку данных (которые нужно отправить на уточнение тестерам), ошибки, которыми можно пренебречь, и даже нечто нелепое, вроде жалобы на то, что веб-сайт не предсказывает номера выигрышных лотерейных билетов. Практика показывает, что после первой сортировки количество ошибок обычно уменьшается на 30 процентов, что, конечно же, здорово прибавляет настроения. Однако вам не удастся так легко добиться цели без выполнения всей работы.

Очень простая сортировка

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

Согласно простейшей схеме, все ошибки можно разделить на три группы: «необходимо исправить», «надо бы исправить», «не нужно исправлять». Перебирая ошибки, относите их к одной из этих категорий. При этом чем больше ошибок будет отнесено в «надо бы исправить» и «не нужно исправлять», тем более эффективной будет сортировка, поскольку эти группы представляют собой чёткие решения. Чего вам точно не нужно — так это чтобы 99 процентов ваших ошибок попадало в «необходимо исправить». Такой подход к сортировке называется «трусливым». Если все ошибки нужно исправить, то это равносильно тому, что они равнозначны, но это бессмысленно. Иными словами, вы просто сбежали от решения проблемы. Запомните золотое правило: чтобы добиться успеха, расставьте ошибки в порядке их приоритета.

Если приоритет у всех ошибок один, значит, нет порядка и, следовательно, нет успеха.

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

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

Врачи первой помощи не выбрасывают белый флаг и не просят таймаутов, когда им приходится выбирать, кого из пострадавших спасать в первую очередь. Если они могут делать ТАКОЙ выбор ради человеческих жизней, то уж вы точно справитесь с расстановкой приоритетов для ошибок. Не прячьтесь за невежеством «трусливой сортировки» — будьте тверды, упрямы и ведите свою команду вперед!

Правила очень простой сортировки

Вот основные правила для трех групп ошибок:

1. Если ошибку «должны исправить», то это означает, что она важнее любой ошибки из группы «надо бы исправить» и «не будем править»;
2. Если ошибку «надо бы исправить», значит, она менее важна, чем любая из группы «должны исправить», и более важна, чем из группы «не будем править».
3. Если ошибку «не будем править», значит, она менее важна, чем любая другая ошибка в категории «надо бы исправить».

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

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

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

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

Другими словами — не беспокойся о десерте, если еще не ясно, что будет на обед.

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

Когда сортировать

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

Уровень 2. Более детальная сортировка

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

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

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

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

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

Внимание: качественное описание ошибки (или отсутствие такового) могут быть первым критерием для сортировки ошибок по их важности.

Чтобы улучшить качество информации об ошибке, прежде всего необходимо детализировать группы, на которые эти ошибки делятся. Помимо групп (Должны/Надо бы/Не будем), нужно ввести еще два понятия: «Приоритет» и «Серьезность».

Смысл приоритетов прост: вместо «Должны сделать» назовите это «Приоритет 1», вместо «Надо бы сделать» — «Приоритет 2», и вместо «Не будем делать» — «Приоритет 3». Некоторые команды идут еще дальше и добавляют приоритет 4. Таким образом, Приоритетом 3 становится «вероятно, не будем делать», а Приоритетом 4 — «Не будем делать, пока не остынет преисподняя, потом снова не запылает и опять не остынет». Я не встречал успешных команд, у которых градация приоритетов имела бы более четырех уровней.

Создание 15 различных приоритетов — это совершенно лишняя затея.

«Серьезность» определяет, насколько серьезной будет ошибка для заказчика, если она случится. Отделение серьезности от приоритетности исправления дает лучшее видение ошибки, так как появляется возможность разделить последствия выполнения ошибки от возможности ее появления.

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

Чтобы это заработало, кто-то должен сестьи определить разницу между уровнями серьезности 1, 2 и 3. Хорошо, если при этом будут приводиться примеры реальных ошибок, чтобы люди могли выбрать правильный уровень. После этого, как только будет открываться новая ошибка, степень серьезности будет заполняться надлежащим образом. Кому-то, вероятно, вам, придется добавить степени серьезности и к старым ошибкам.

Вот пример системы определения серьезности. Рекомендую вашей команде собраться вместе и оценить следующее:

• Уровень серьезности 1. Потеря данных. Заказчик теряет данные или серьезно повреждает их. Восстановление данных может быть невозможно или требуется переустановка приложения (или нажатие кнопки «обновить» в браузере»);
• Уровень серьезности 2. Часть функционала не работает или работает с большими проблемами. Большая часть возможностей не работает или работает не так, как ожидалось, поэтому рабочие задачи нельзя решить или приходится искать обходные пути;
• Уровень серьезности 3. Раздражение. Второстепенные функции работают не так, как ожидалось. Обходные пути существуют, но их сложно найти или они раздражают и разочаровывают.

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

Третий важный критерий, который нужно учитывать при работе с ошибками, — это часть проекта, на которую ошибки воздействуют. Чем больше ваша команда, тем важнее учитывать этот критерий. Необходимо понять, какая часть проекта страдает от ошибки: возможность печати или поисковый механизм? Разбейте весь проект на четыре-пять частей и учитывайте их в базе ошибок. Это даст вам новый взгляд на проект — вы сможете определять, какие части проекта наиболее «сырые» или какие части наиболее важны для вас и ваших заказчиков. Если каждый программист отвечает за конкретную часть проекта, то такой подход позволит распределять ошибки для правки.

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

1. Общая методика отладка по: изучение проявления ошибки, локализация ошибки, определение причины ошибки, исправление ошибки, повторное тестирование.

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

2 этап —
локализация ошибки — определение
конкретного фрагмента, при выполнении
которого произошло отклонение от
предполагаемого вычислительного
процесса. Локализация может выполняться:

• путем отсечения
частей программы, причем, если при
отсечении некоторой части программы
ошибка пропадает, то это может означать
как то, что ошибка связана с этой частью,
так и то, что внесенное изменение
изменило проявление ошибки;

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

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

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

4 этап —
исправление ошибки — внесение
соответствующих изменений во все
операторы, совместное выполнение
которых привело к ошибке.

5 этап —
повторное тестирование — повторение
всех тестов с начала, так как при
исправлении обнаруженных ошибок часто
вносят в программу новые.

Следует иметь в
виду, что процесс отладки можно
существенно упростить, если следовать
основным рекомендациям структурного
подхода к программированию:

• программу
наращивать «сверху-вниз», от интерфейса
к обрабатывающим подпрограммам, тестируя
ее по ходу добавления подпрограмм;

• выводить
пользователю вводимые им данные для
контроля и проверять их на допустимость
сразу после ввода;

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

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

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

1. Организация
   испытаний, цель испытаний, предварительные
   и совместные испытания, виды испытаний
   в жизненном цикле ПО: опытного образца,
   рабочей версии, модернизированной
   версии; категории испытаний:
   функциональные, стрессовые, использования
   ресурсов ЭВМ, параллельного решения
   задач.

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

Испытания сложных
КП являются наиболее формализован­ным
и регламентированным видом тестирования.
Для всесторон­ней проверки опытный
образец КП подвергается испытаниями
главного конструктора (предварительные
испытания) и заказчи­ка-пользователя
с участием разработчиков (совместные
испыта­ния).

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

В жизненном цикле
КП можно выделить следующие виды
испытаний

-опытного образца
на полное соответствие требованиям
технического задания,

-рабочей версии
КП, адаптированной к условиям конкретного
применения,

-версии
модернизированного КП при сопровождении.

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

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

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

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

1. Испытания
   программ на надежность: прямые
   экспериментальные методы определения
   показателей надежности программ в
   условиях нормального функционирования,
   форсированные методы испытаний реальных
   систем на надежность.

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

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

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

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

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

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

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

1. Достоверность
   испытаний: методическая и статистическая
   достоверность; документирование
   результатов испытаний: исходных и
   отчетные документы при испытаниях
   программ – техническое задание,
   государственные и отраслевые стандарты,
   программа испытаний, методики испытаний,
   протоколы испытаний, акт испытаний.

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

Методическая
достоверность испытаний КП оп­ределяется
следующими факторами:

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

-достоверностью
и точностью эталонных значений, с
которыми сравниваются результаты
тестирования испытываемой програм­мы
или которые служат опорными при расчете
параметров, зафиксированных в техническом
задании;

-адекватностью и
точностью моделей, используемых для
ими­тации внешней среды и их реакции
на управляющие воздей­ствия;

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

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

Документы:

1. ТЗ

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

1. Государственные
   и отраслевые стандарты

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

-объект испытаний,
его назначение и перечень основных
до­кументов, определивших его
разработку;

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

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

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

Результаты
испытаний фиксируются в протоколах,
которые обычно содержат следующие
разделы:

-назначение
тестирования и раздел требований
технического задания, по которому
проводится испытание;

-указание методик,
в соответствии с которыми проводились
испытания, обработка и оценка результатов;

-условия проведения
тестирования и характеристика исходных
данных;

-обобщенные
результаты испытаний с оценкой их на
соответ­ствие требованиям технического
задания и другим руководящим документам;

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

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

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

1. Виды программной
   документации: проектная и эксплуатационная
   документация. Документирование
   интерактивного ПО. Государственные
   стандарты в области документирования
   ПО. Средства автоматизации документирования.

К программным
относят документы, содержащие сведения,
необходимые для разработки, сопровождения
и эксплуатации программного
обеспечения. Документирование
программного обеспечения осуществляется
в соответствии с Единой системой
программной документации (ГОСТ 19.XXX).
Так ГОСТ 19.101-77 устанавливает виды
программных документов для программного
обеспечения различных типов. Ниже
перечислены основные программные
документы по этому стандарту и указано,
какую информацию они должны содержать.

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

Ведомость
держателей подлинников (код вида
документа — 05) должна содержать список
предприятий, на которых хранятся
подлинники программных документов.
Необходимость этого документа
определяется на этапе разработки и
утверждения технического задания
только для программного обеспечения
со сложной архитектурой.

Текст программы
(код вида документа — 12) должен содержать
текст программы с необходимыми
комментариями. Необходимость этого
документа определяется на этапе
разработки и утверждения технического
задания.

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

Ведомость
эксплуатационных документов
(код вида документа — 20) должна содержать
перечень эксплуатационных документов
на программу, к которым относятся
документы с кодами: 30, 31, 32, 33, 34, 35, 46.
Необходимость этого документа также
определяется на этапе разработки и
утверждения технического задания.

Формуляр
(код вида документа — 30) должен содержать
основные характеристики программного
обеспечения, комплектность и сведения
об эксплуатации программы.

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

Руководство
системного программиста
(код вида документа — 32) должно содержать
сведения для проверки, обеспечения
функционирования и настройки программы
на условия конкретного применения.

Руководство
программиста
(код вида документа — 33) должно содержать
сведения для эксплуатации программного
обеспечения.

Руководство
оператора
(код вида документа — 34) должно содержать
сведения для обеспечения процедуры
общения оператора с вычислительной
системой в процессе выполнения
программного обеспечения.

Описание языка
(код вида документа — 35) должно содержать
описание синтаксиса и семантики языка.

Руководство по
техническому обслуживанию
(код вида документа — 46) должно содержать
сведения для применения тестовых и
диагностических программ при обслуживании
технических средств.

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

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

Прочие документы
(коды вида документа — 90-99) могут
составляться на любых стадиях
разработки, т. е. на стадиях эскизного,
технического и рабочего проектов.
Допускается объединять отдельные
виды эксплуатационных документов,
кроме формуляра и ведомости. Необходимость
объединения указывается в техническом
задании, а имя берут у одного из
объединяемых документов.

1. Планирование
   и организация разработки программных
   систем: принципы планирования разработки,
   принципы организации коллектива
   программистов и распределения работ
   по специалистам; методы бригадной
   организации работ: бригада независимых
   программистов, демократическая бригада,
   бригада главного программиста; права
   и обязанности членов бригад, организация
   их взаимодействия, управление бригадой
   на различных этапах проектирования.

На
этапе планирования разработки ПО
создаются планы и выбираются стандарты,
которые направляют этап разработки и
интегрированный этап. Его

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

1)
определение действий на этапах разработки
и интегрированном этапе, которые будут
посвящены определению системных
требований и уровня ПО;

2)
определение ЖЦ ПО, включая взаимодействие
между этапами, механизм взаимного
влияния этапов, критерии оценки ПО при
переходе от одного этапа к другому;

3)определение
среды ЖЦ, т.е. методы и инструментальные
средства, используемые на каждом этапе;

4)
формирование дополнительных замечаний
к ПО;

5)
рассмотрение стандартов разработки
ПО, соотношение их с системными целями
безопасности, относящиеся к разрабатываемому
ПО;

6)
разработка плана создания ПО;

7)
доработка и проверка плана создания
ПО.

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

-на основе
распределения системного анализа
(алгоритмиза­ции) и разработки программ
по разным коллективам;

-по принципу
выделения коллективов, создающих всю
совокуп­ность программных модулей,
и группы специалистов, объединя­ющих
программы в единый комплекс;

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

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

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

Одним из вариантов
организационной структуры коллектива
при создании крупных КП является
иерархическая структура, базирующаяся
на группах специалистов, каждая из
которых сос­тавляет специализированную,
так называемую «хирургическую бригаду».
Такая бригада решает достаточно
автономную функци­ональную задачу
и должна разработать и отладить группу
взаи­модействующих программ с
достаточно четкой целью функциони­рования.
«Хирургическая бригада» рекомендуется
в составе 7…10 специалистов с различными
задачами и квалификацией. Во главе
бригады стоит «хирург», который
разрабатывает функциональ­ные задачи
программ, составляет алгоритм, пишет
и отлаживает программы, готовит и
проверяет документацию. Он должен
обла­дать значительным системным
опытом, высокой математической и
программистской квалификацией и
талантом разработки и от­ладки сложных
КП. «Второй пилот» является дублером
и может выполнить любую часть работы,
но менее опытен. Он принимает участие
в разработке, обсуждении и оценке
компонент, создаваемых бригадой, в
качестве оппонента или ответчика по
альтернативным решениям, а также несет
ответственность за взаимодей­ствие
с другими бригадами и с разрабатываемыми
ими груп­пами программ.

«Администратор»
позволяет избавить «хирурга» от
множества технических и административных
функций как внутри бригады, так и по
взаимодействию с администрацией всей
организации. При этом «хирургу»
принадлежит определяющее слово по
важ­нейшим вопросам организации и
проведения работ. «Редактор» критикует
документацию, созданную «хирургом»,
дорабатывает ее, снабжает ссылками и
наблюдает за ее публикацией. «Адвокат
языка» обеспечивает «хирурга»
консультациями по применению языка в
трудных или запутанных ситуациях,
способствует полу­чению более
эффективных программ. «Инструментальщик»
— опытный системный программист —
является создателем специа­лизированных
технологических и служебных программ,
каталоги­зированных процедур,
библиотек макрокоманд для расширения
функций технологического обеспечения
по заказу «хирурга». «Наладчик»
разрабатывает системные тесты в
соответствии с назначением и функциями
создаваемой группы программ. Он планирует
последовательность тестирования,
подготавливает имитаторы исходных
данных для комплексной отладки,
регистри­рует процесс проведения
отладки и ее результаты. Кроме того, в
бригаду входят 2…3 технических работника
для выполнения секретарских функций
и различных вспомогательных техни­ческих
работ.

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

Для сложных ПС, в
создании которых участвуют десятки
специалистов, необходимо провести
четкое различие между архи­тектурой
КП и реализацией проекта в целом, а
также его состав­ных частей.
«Системный архитектор» должен
специальными методами обучения
коллектива обеспечивать функциональное,
структурное и технологическое единство
проекта КП. Руководи­тели, ответственные
за функциональные группы программ,
объединяют усилия бригад и обеспечивают
их взаимодействие по функциональному
и информационному сопряжению компонент,
созданных различными бригадами. Таким
образом, иерар­хическая структура
коллектива в верхних ярусах должна
соот­ветствовать иерархической
структуре создаваемого КП, хотя следует
учитывать и обратное влияние структуры
коллектива на структуру КП.

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

1. Внедрение и
   эксплуатация ПО, процесс сопровождения:
   модификация, усовершенствование и
   коррекция ПО; планирование и организация
   сопровождения, методы конфигурационного
   управления; тиражирование и использование
   версий программ, методы сертификации
   ПО.

Во время фазы
эксплуатации и сопровождения начинается
прак­тическое использование
программного изделия.

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

• наличие ошибок
в используемом программном продукте;

• изменение
требований пользователя (расширение
или модифи­кация);

• появление более
совершенных общесистемных программных
средств или технических устройств;

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

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

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

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

Задачи службы
сопровождения программного изделия

В процессе
эксплуатации программного изделия
пользователи взаимодействуют с
организацией (группой), ответственной
за со­провождение. Задачами службы
сопровождения являются:

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

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

3. Модернизация
программного изделия путем расширения
функциональных возможностей или
улучшения эксплуатационных характеристик
программного изделия.

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

5. Контроль
правильности всех корректировок,
вносимых в из­делие, и проверка
качества измененных программ.

6. Доведение до
пользователя информации о внесенных
измене­ниях.

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

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

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

«Не ошибается тот, кто ничего не делает»

Вид урока: комбинированный.

Технология: личностно-ориентированная, игровая.

Цели урока:

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

Тип урока:урок закрепления знанийи , с применением современных компьютерных технологий.

Оборудование:

• персональные компьютеры
• компьютер учителя
• мультимедийный проектор
• интерактивная доска
• карточки самоконтроля
• карточки с клавишами
• программно-методический комплекс «роботландия»:
• часть «знакомство с компьютером»
• программа «правилка»

Ход урока

I.  Мотивация учебной деятельности

Тема нашего урока сегодня: Исправление ошибок в тексте, вставка пропущенных символов.

Существует известная истина: «Не ошибается тот, кто ничего не делает». И мы попробуем на нашем уроке применить сегодня знания двух предметов: русского языка и информатики. Вы знаете, что наш русский язык очень велик и могуч! Как сказал русский писатель А.Куприн: «Русский язык в умелых руках и опытных устах красив, певуч, выразителен, гибок, послушен, ловок и вместителен». В изучении русского языка много интересного. А нам на информатике при работе с текстами и в текстовых редакторах никак не обойтись без знаний нашего родного языка..

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

Задача нашего урока сегодня:

• Научиться применять правило вставки и замены символов;
• Научиться исправлять в предложениях различные ошибки одновременно.

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

Мы окунёмся в мир клавиш, но задания ваши будут ещё и на сообразительность. Сначала у нас разминка!

Главным средством управления персональным компьютером является, всё-таки, не электронная «мышь», а клавиатура. А на ней есть клавиши, без которых просто нельзя обойтись:

• какая из них главная? (ENTER)
• есть клавиши очень похожие друг на друга; чем они похожи и чем отличаются? (SHIFT и CAPS LOCK) – (DELETE и BS)
• что произойдёт, если прижать клавишу, на которой нарисована буква? (Будет печататься только эта буква длительное количество раз.)
• сколько клавиш надо нажать на клавиатуре, чтобы на экране появилось слово Оля? (Четыре.)

Молодцы, ребята, те, кто активно отвечали! Вы уже заработали свои первые оценки (это Ваши «Солнышки»).

А теперь попробуем все получить оценки.

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

ENTER	DELETE	INSERT
BS	ESC	SHIFT

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

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

Обменяйтесь листами, пожалуйста. Я Вам продиктую правильные ответы, а вы в листах своих товарищей ставите + или — если 7 или 6 верных ответов – это «5», 4 и 5 верных ответов «4», а далее уже оценка «3».

II.  Изучение новой темы

Вы знаете, что существует всего 3 типа ошибок:

• неверный символ (замена)
• лишний символ (удаление)
• пропущенный символ (вставка)

Самый сложный вид исправления ошибок — это вставка пропущенных символов.

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

Для выделения места используется клавиша вставки:

— INSERT (вставить)

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

А теперь давайте поиграем:

Четыре ученика выходят к доске с плакатами букв: Ш К Л А

Какое слово хотели показать нам друзья?

(Дети отвечают – ШКОЛА — буква «О» пропущена).

А буква «О» — сидит и ждет, куда бы ей встать.

Моя левая рука будет курсором,  я сейчас поставлю ее на место, где надо поставить пропущенную букву. Кладу руку на букву Л. Правая рука — клавиша вставки. Я нажимаю на нее один раз. Отодвигаю учеников с буквами «Л» и «А» вправо. Вот сюда и встанет буква «О».

Поиграем ещё!

У доски буквы:

Ш К О Н И К

Теперь курсором будет Ирина Крымова.

— Ирина, кому положишь левую руку на плечо? (Буква Н).

— А что делать твоей правой руке? (Которая играет роль клавиши вставки) (два раза нажать клавишу «INSERT«).

Молодец! (получает «Солнышко»).

Давайте выполним небольшую практическую работу.

Каждое из приведённых на экране слов набрано с одной ошибкой:

К какому типу ошибок они относятся?

Запишите правильно эти слова в тетради!

К какому типу относятся ошибки в словах:

ГОСТИННИЦА МАЛЕНКИЙ УЖАСТНО

А теперь, давайте еще раз посмотрим, как это делается на компьютере.

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

На интерактивной доске, в программе «Текстовый редактор» должно быть набрано:

Ш К Л А   Ш К О Н И К — (показать моделирование)

III.  Лабораторная работа
А сейчас мы с вами проведем лабораторную работу. Посмотрите на нашу программу «Правилка». Вот перед нами старуха Шапокляк, которая не любит исправлять ошибки, но мы ей поможем научиться этому нелёгкому делу. Программа «Правилка» вместе с нами, поможет сделать это быстро и качественно.

Успешность выполнения пяти заданий из одной части контролируется присвоением «званий» (они указаны в порядке возрастания):

НЕЗНАЙКА

ТОРОПЫЖКА

СТУДЕНТ

МУДРЫЙ КРОЛИК

ПРОФЕССОР

Если вы выполните пять заданий одной из частей, то программа отобразит в середине экрана окно с приятной надписью: Присваивается звание: «Профессор» рядом с портретом хоть толстенького и не совсем молодого, но вполне симпатичного профессора. Если допустите в одном из заданий ошибку, то получите звание Мудрого Кролика, а не профессора. Ну и постарайтесь уж не быть Торопыжкой и Незнайкой. Я надеюсь на Вас, ребята!

Работа наша будет состоять из трех частей:

1 часть

• неверный символ;
• лишний символ;

(на «3»)

2 часть

• неверный символ;
• пропущенный символ;
• лишний символ;

(на «4»)

3 часть

• В режиме смесь (интересные смешные названия) – заранее невозможно предугадать, к какому типу ошибок будет относиться очередное задание;
• суперсмесь – и того хитрее: в одном задании, то есть, в одном слове или одной фразе, окажутся несколько ошибок различных типов; (задания будут разного типа) – ваши выражения будут содержать одну, а затем несколько ошибок.

(На «5»)

Но прежде чем начинать работать на компьютере, повторите, пожалуйста, правила Техники Безопасности, написанные на доске.

IV. Итог урока

Молодцы, ребята! Я думаю, что вы сами радуетесь своим успехам.

1. Одна оценка будет у Вас за работу с карточками.
2. Вторая оценка за работу на компьютере.
3. Третья оценка у тех, кто отвечал дополнительно.

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

Что такое орфография, думается, объяснять не надо. А что такое какография?

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

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

Ученые давно задумались над вопросом: можно ли ошибку сделать полезной при обучении грамотному письму и если можно, то как этого добиться?

Практика обучения, исследования методистов дают положительный ответ на первую часть вопроса: возможность применения «отрицательного материала» (выражение Л.В. Щербы) и его положительное влияние на становление орфографического навыка сегодня доказаны.

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

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

          Так, в «Справочном пособии» О.В. Узоровой, Е.А. Нефедовой задания типа «исправь ошибки» используются активно. Приведем пример из пособия для 3-го класса:

Па дула зема холодом. Са рвала листя с лисов и дубрав и раз ми-тала их подорогам. Стали Птицы стайками Са бираться. Са брались па кречяли и пали тел и за высокие Горы за синие маря в теплые страны.

Пока воздержимся от комментариев относительно методической грамотности подачи «отрицательного материала», ограничимся констатацией фактов: в данном тексте 33 слова, на которые приходится 27 ошибок, в основном связанных с правописанием безударных гласных, написанием приставок и предлогов, а также употреблением разделительного мягкого знака. И хотя они расположены равномерно (имеются практически в каждом слове), восприятие текста крайне затруднено из-за того, что облик ряда слов изменен до неузнаваемости. Кроме того, в тексте отсутствует часть знаков препинания, что также усложняет задачу пишущего.

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

Чтобы дети могли выявить ошибки, рекомендуется включать слова в такие предложения, где их различные лексические значения проявятся отчетливо: Мать примеряла драчунов. Покупаемую обувь нужно примирять. Дети, спишите в кино. Дети, спешите это предложение и т.п. Если слова каждой пары изъять из контекста, они предстанут перед детьми в «неиспорченном» виде.

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

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

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

1.  Выполнение корректурных упражнений должно явиться составной частью общей системы работы по формированию у младших школьников осознанных орфографических действий. Их место — перед знакомством с правилами письма для мотивации их изучения и преимущественно после прочного усвоения этих правил для обучения самоконтролю.
2.  Корректурные упражнения должны выполняться в системе: а) начинаться с исправления графических ошибок и распространяться на орфографические; б) начинаться с коллективной работы и переноситься на самостоятельную лишь тогда, когда учащиеся усвоят общий способ действия проверки.
3.  Формулировка задания для самостоятельной работы должна направлять правильные действия учеников: указывать последовательность операций и их содержание.
4.  Необходимо обеспечить обязательное исправление всех предъявленных ошибок, причем способом, привлекающим внимание именно к правке (например, мелом или пастой другого цвета).
5.  Должна соблюдаться этапность в предъявлении ошибочного материала: сначала написания, нарушающие одно правило, а потом — несколько; сначала слова, а затем — предложения и тексты.
6.  Предъявляемый материал не должен превышать 8-12 отдельных слов или текст в 25-30 слов, на которые должно приходиться не более 4-6 ошибок, причем их не следует концентрировать в конце текста.

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

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

Чтобы проиллюстрировать соблюдение методической постепенности при использовании «отрицательного материала», покажем одно из собственно корректурных упражнений учебника для 1 — го класса:

Как видим, в этих записях нарушены нормы графики, в частности правила обозначения мягкости согласных. Для исправления предложены отдельные слова, их количество не превышает нормы (8-12 слов). Заметим: задание сформулировано так, что внимание первоклассников сначала фокусируется на правильных написаниях и только потом направляется на поиск ошибок. Кроме того, предусматривается материальная фиксация результатов проверки: над правильно написанными словами ставится +, ошибки же исправляются показанным способом.

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

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

Шаг 1: Занесите ошибку в трекер

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

1. Вы забыли какую-то важную деталь об ошибке, например, в чем она заключалась.
2. Вы могли делегировать ее кому-то более опытному.

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

Вы должны записать в трекер следующую информацию:

1. Что делал пользователь.
2. Что он ожидал увидеть.
3. Что случилось на самом деле.

Это должно подсказать, как воспроизвести ошибку. Если вы не сможете воспроизвести ее в любое время, ваши шансы исправить ошибку стремятся к нулю.

Шаг 2: Поищите сообщение об ошибке в сети

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

Шаг 3: Найдите строку, в которой проявляется ошибка

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

Шаг 4: Найдите точную строку, в которой появилась ошибка

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

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

Шаг 5: Выясните природу ошибки

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

1. Ошибка на единицу
   Вы начали цикл for с единицы вместо нуля или наоборот. Или, например, подумали, что метод .count() или .length() вернул индекс последнего элемента. Проверьте документацию к языку, чтобы убедиться, что нумерация массивов начинается с нуля или с единицы. Эта ошибка иногда проявляется в виде исключения Index out of range.
2. Состояние гонки
   Ваш процесс или поток пытается использовать результат выполнения дочернего до того, как тот завершил свою работу. Ищите использование sleep() в коде. Возможно, на мощной машине дочерний поток выполняется за миллисекунду, а на менее производительной системе происходят задержки. Используйте правильные способы синхронизации многопоточного кода: мьютексы, семафоры, события и т. д.
3. Неправильные настройки или константы
   Проверьте ваши конфигурационные файлы и константы. Я однажды потратил ужасные 16 часов, пытаясь понять, почему корзина на сайте с покупками виснет на стадии отправки заказа. Причина оказалась в неправильном значении в /etc/hosts, которое не позволяло приложению найти ip-адрес почтового сервера, что вызывало бесконечный цикл в попытке отправить счет заказчику.
4. Неожиданный null
   Бьюсь об заклад, вы не раз получали ошибку с неинициализированной переменной. Убедитесь, что вы проверяете ссылки на null, особенно при обращении к свойствам по цепочке. Также проверьте случаи, когда возвращаемое из базы данных значение NULL представлено особым типом.
5. Некорректные входные данные
   Вы проверяете вводимые данные? Вы точно не пытаетесь провести арифметические операции с введенными пользователем строками?
6. Присваивание вместо сравнения
   Убедитесь, что вы не написали = вместо ==, особенно в C-подобных языках.
7. Ошибка округления
   Это случается, когда вы используете целое вместо Decimal, или float для денежных сумм, или слишком короткое целое (например, пытаетесь записать число большее, чем 2147483647, в 32-битное целое). Кроме того, может случиться так, что ошибка округления проявляется не сразу, а накапливается со временем (т. н. Эффект бабочки).
8. Переполнение буфера и выход за пределы массива
   Проблема номер один в компьютерной безопасности. Вы выделяете память меньшего объема, чем записываемые туда данные. Или пытаетесь обратиться к элементу за пределами массива.
9. Программисты не умеют считать
   Вы используете некорректную формулу. Проверьте, что вы не используете целочисленное деление вместо взятия остатка, или знаете, как перевести рациональную дробь в десятичную и т. д.
10. Конкатенация строки и числа
    Вы ожидаете конкатенации двух строк, но одно из значений — число, и компилятор пытается произвести арифметические вычисления. Попробуйте явно приводить каждое значение к строке.
11. 33 символа в varchar(32)
    Проверяйте данные, передаваемые в INSERT, на совпадение типов. Некоторые БД выбрасывают исключения (как и должны делать), некоторые просто обрезают строку (как MySQL). Недавно я столкнулся с такой ошибкой: программист забыл убрать кавычки из строки перед вставкой в базу данных, и длина строки превысила допустимую как раз на два символа. На поиск бага ушло много времени, потому что заметить две маленькие кавычки было сложно.
12. Некорректное состояние
    Вы пытаетесь выполнить запрос при закрытом соединении или пытаетесь вставить запись в таблицу прежде, чем обновили таблицы, от которых она зависит.
13. Особенности вашей системы, которых нет у пользователя
    Например: в тестовой БД между ID заказа и адресом отношение 1:1, и вы программировали, исходя из этого предположения. Но в работе выясняется, что заказы могут отправляться на один и тот же адрес, и, таким образом, у вас отношение 1:многим.

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

Шаг 6: Метод исключения

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

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

Шаг 7: Логгируйте все подряд и анализируйте журнал

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

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

Шаг 8: Исключите влияние железа или платформы

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

Если ваша программа работает по сети, проверьте свитч, замените кабель или запустите программу в другой сети.

Ради интереса, переключите кабель питания в другую розетку или к другому ИБП. Безумно? Почему бы не попробовать?

Если у вас возникает одна и та же ошибка вне зависимости от среды, то она в вашем коде.

Шаг 9: Обратите внимание на совпадения

1. Ошибка появляется всегда в одно и то же время? Проверьте задачи, выполняющиеся по расписанию.
2. Ошибка всегда проявляется вместе с чем-то еще, насколько абсурдной ни была бы эта связь? Обращайте внимание на каждую деталь. На каждую. Например, проявляется ли ошибка, когда включен кондиционер? Возможно, из-за этого падает напряжение в сети, что вызывает странные эффекты в железе.
3. Есть ли что-то общее у пользователей программы, даже не связанное с ПО? Например, географическое положение (так был найден легендарный баг с письмом за 500 миль).
4. Ошибка проявляется, когда другой процесс забирает достаточно большое количество памяти или ресурсов процессора? (Я однажды нашел в этом причину раздражающей проблемы «no trusted connection» с SQL-сервером).

Шаг 10: Обратитесь в техподдержку

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

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

Полезные советы (когда ничего не помогает)

1. Позовите кого-нибудь еще.
   Попросите коллегу поискать ошибку вместе с вами. Возможно, он заметит что-то, что вы упустили. Это можно сделать на любом этапе.
2. Внимательно просмотрите код.
   Я часто нахожу ошибку, просто спокойно просматривая код с начала и прокручивая его в голове.
3. Рассмотрите случаи, когда код работает, и сравните их с неработающими.
   Недавно я обнаружил ошибку, заключавшуюся в том, что когда вводимые данные в XML-формате содержали строку xsi:type='xs:string', все ломалось, но если этой строки не было, все работало корректно. Оказалось, что дополнительный атрибут ломал механизм десериализации.
4. Идите спать.
   Не бойтесь идти домой до того, как исправите ошибку. Ваши способности обратно пропорциональны вашей усталости. Вы просто потратите время и измотаете себя.
5. Сделайте творческий перерыв.
   Творческий перерыв — это когда вы отвлекаетесь от задачи и переключаете внимание на другие вещи. Вы, возможно, замечали, что лучшие идеи приходят в голову в душе или по пути домой. Смена контекста иногда помогает. Сходите пообедать, посмотрите фильм, полистайте интернет или займитесь другой проблемой.
6. Закройте глаза на некоторые симптомы и сообщения и попробуйте сначала.
   Некоторые баги могут влиять друг на друга. Драйвер для dial-up соединения в Windows 95 мог сообщать, что канал занят, при том что вы могли отчетливо слышать звук соединяющегося модема. Если вам приходится держать в голове слишком много симптомов, попробуйте сконцентрироваться только на одном. Исправьте или найдите его причину и переходите к следующему.
7. Поиграйте в доктора Хауса (только без Викодина).
   Соберите всех коллег, ходите по кабинету с тростью, пишите симптомы на доске и бросайте язвительные комментарии. Раз это работает в сериалах, почему бы не попробовать?

Что вам точно не поможет

1. Паника
   Не надо сразу палить из пушки по воробьям. Некоторые менеджеры начинают паниковать и сразу откатываться, перезагружать сервера и т. п. в надежде, что что-нибудь из этого исправит проблему. Это никогда не работает. Кроме того, это создает еще больше хаоса и увеличивает время, необходимое для поиска ошибки. Делайте только один шаг за раз. Изучите результат. Обдумайте его, а затем переходите к следующей гипотезе.
2. «Хелп, плиииз!»
   Когда вы обращаетесь на форум за советом, вы как минимум должны уже выполнить шаг 3. Никто не захочет или не сможет вам помочь, если вы не предоставите подробное описание проблемы, включая информацию об ОС, железе и участок проблемного кода. Создавайте тему только тогда, когда можете все подробно описать, и придумайте информативное название для нее.
3. Переход на личности
   Если вы думаете, что в ошибке виноват кто-то другой, постарайтесь по крайней мере говорить с ним вежливо. Оскорбления, крики и паника не помогут человеку решить проблему. Даже если у вас в команде не в почете демократия, крики и применение грубой силы не заставят исправления магическим образом появиться.

Ошибка, которую я недавно исправил

Это была загадочная проблема с дублирующимися именами генерируемых файлов. Дальнейшая проверка показала, что у файлов различное содержание. Это было странно, поскольку имена файлов включали дату и время создания в формате yyMMddhhmmss. Шаг 9, совпадения: первый файл был создан в полпятого утра, дубликат генерировался в полпятого вечера того же дня. Совпадение? Нет, поскольку hh в строке формата — это 12-часовой формат времени. Вот оно что! Поменял формат на yyMMddHHmmss, и ошибка исчезла.

_{Перевод статьи «How to fix bugs, step by step»}