Работая в сфере ИТ, волей-неволей замечаешь огромное количество ошибок в различном программном обеспечении. Будь то ошибки мировых вендоров Microsoft, или же в прикладных бизнес-решениях фирмы 1С, или же в хваленных Apple с детской фатальной ошибкой "1 января 1970". Что уж говорить про небольшие компании с небольшим штатом программистов?

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

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

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

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

Сколько полегло исследователей в попытке пройти сложные маршруты: Г. Седов, Р. Скотт, В. Беринг... О чём это я?

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

Ошибки и Теория конечного автомата

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

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

Представим стандартный граф конечного автомата производственного предприятия с состояниями:

• Расчет
• К производству
• В производстве
• Готово
• Завершён

События конечного автомата:

• a — устанавливается менеджером после подтверждения покупателем;
• b — устанавливается начальником производства, оценив производственные мощности и возможность выполнения;
• c — устанавливается работником склада в момент поступления на склад;
• d — устанавливается менеджером при поступлении денег и передачи груза;
• e — устанавливается менеджером вручную.

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

Это обычная задача, но для проектировщика здесь скрыто много нюансов. Например, произвели продукцию, а часть оказалось браком. Какое состояние должно быть? Учли? Заказчик приехал покупать, но при осмотре решил отказаться от части продукции - завершён или отменён? По ошибке отменили заказ, а надо вернуть в производство.

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


Чем функциональнее ПО, тем больше ошибок. Тестировщик помогает, но не всегда — он не знаком с предметной областью так, как проектировщик.

Я для себя определил, что построение графа статусов на базе теории конечного автомата позволяет объемно взглянуть на решаемую задачу.

Помню, ко мне обратился Финансовый директор с просьбой разработать систему депремирования сотрудников. Учет поручений всех сотрудников вёлся в 1С: Документооборот (ДО), учёт рабочего времени в 1С: Управление производственным предприятием (УПП). Если сотрудник просрочил важную задачу, то его лишали премии на Х%. Для этого сверяем время завершения задачи в ДО, получаем данные сотрудника по табелю за период из УПП и определяем место запятой в «казнить нельзя помиловать».

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



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

Процедура тестирования программного обеспечения давно отлажена и стандартизирована. Но массовые продукты всё равно постоянно выпускают релизы с исправлением ошибок. Примеры:

• WordPress

• 1С: Комплексная автоматизация 2

Можно ли выпустить Функциональное ПО без ошибок? Нет, таких случаев не наблюдалось.

Связь экономики и технических знаний в области ошибок

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



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

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

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

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

Вес ошибок

Вес каждой ошибки разный. В целом, я делю их на 4 вида.

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

Например, я скачал активно продвигаемую программу в Google Play Маркет. Сразу при запуске произошла ошибка.



Важная непреодолимая ошибка

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

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



Важная преодолимая ошибка

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

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



В программе 1С выводилась такая ошибка расчета себестоимости. Пользователь мог (естественно, путём экспериментов) её устранить — перепровести документы. В заявленных возможностях метода РАУЗ это не надо делать, но не на практике.

Замечания

Это всё остальное. Например, приходит мне сообщение от Добродела, а ссылка неработающая. Сразу видно что тестирование не проводилось.



 

Анализ своих ошибок в качестве резюме

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

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