Когда программные проблемы, о которых сообщают, не являются действительно программными проблемами
Извинения, если это было уже покрыто или Вы думаете, что это действительно принадлежит на Wiki.
Я - разработчик программного обеспечения в компании, которая производит машины печати микромассива для промышленности биологических наук. Я, прежде всего, вовлечен во взаимодействие через интерфейс с различными битами аппаратных средств (пневматика, гидравлика, шаговые двигатели, датчики и т.д.) через разработку GUI в C++, чтобы произнести с придыханием и распечатать образцы на слайды микромассива.
При присоединении к компании я заметил, что каждый раз, когда была связанная с аппаратными средствами проблема, это заставит целую установку замораживаться, при этом никто будет любой более мудрое относительно того, чем определенная проблема была - аппаратные средства / программное обеспечение / неправильное употребление и т.д. С тех пор, я улучшил вещи несколько путем представления тайм-аутов программного обеспечения и обработки исключений, чтобы лучше определить и иметь дело с любыми связанными с аппаратными средствами проблемами, которые возникают, например, команды PLC не успешно завершенные, несоответствующие команды ответа FPGA и различные другие условия типа мертвой блокировки и т.д. Кроме того, программное обеспечение теперь зарегистрирует сводку определенной проблемы, сообщить пользователю и выйти из потока корректно. Это программное обеспечение не встраивается, просто взаимодействуя через интерфейс использующий последовательные порты.
Несмотря на то, что было достигнуто, парни непрограммного обеспечения все еще не осознают это в этих случаях, проблемой 'программного обеспечения', о которой они сообщают мне, не является действительно программная проблема, скорее программное обеспечение сообщает о проблеме, но не вызывает ее. Не понимайте меня превратно, нет ничего, что я наслаждаюсь больше, чем снизиться на программных ошибках как тонна кирпичей и рассмотрении способов улучшить устойчивость всегда. Я знаю систему достаточно хорошо теперь, когда у меня почти есть шестое чувство для этих вещей.
Неважно, сколько раз я пытаюсь объяснить это, ничто действительно не проникает. Они все еще сообщают, что является чрезвычайно аппаратными проблемами (который в конечном счете фиксируется) как программного обеспечения.
Я хотел бы получить известие от любых других, которые вынесли подобные события взаимных упреков и какие методы они раньше имели дело с ними.
ОБНОВИТЕ Некоторые большие ответы здесь, которые в значительной степени говорят одно и то же: будьте более описательными. Я предполагаю идентификацию команды и разбомбить чисто, когда аппаратные средства перестали работать, был первая стадия, но все еще не была достаточно. Следующий этап будет состоять в том, чтобы отобразить то, что является неспециалисту довольно бессмысленными командами PLC к чему-то более наводящему на размышления. "Тайм-аут Команды M71 PLC" становится "Отказом инициализировать систему шприца. Проверьте соответствующий вакуум, достигнутый" и так далее...
8 ответов
Возможно, сообщая о проблеме либо в виде сообщения пользователю, либо в виде записи в файле журнала, вам нужно четко дать понять, что виновато именно оборудование:
«Шаговый двигатель не отвечает».
К сожалению, поскольку это программное обеспечение, которое люди видят и с которым взаимодействуют, они предполагают, что программное обеспечение — это все, что есть.
Вы можете попробовать пометить сообщения об ошибках как «АППАРАТНАЯ ПРОБЛЕМА». Могу донести вашу точку зрения.
В системе не существует такой вещи, как непрограммная проблема. Программное обеспечение - это босс, и босс не может винить инструменты в неудаче.
Если базовое оборудование неисправно, оно должно сообщить пользователю, что именно пошло не так с каким компонентом. Если этого не произошло, это проблема программного обеспечения.
Например, отключение TCP означает необходимость повторного подключения. Если это ответ ПЛИС, он должен точно сказать, какие были входы и выходы пользователю , и кто виноват. В противном случае это проблема программного обеспечения.
Кто сообщает о проблемах?
Если это конечные пользователи, я думаю, это не проблема. Они просто знают, что то, что они пытаются сделать, не работает. Пользователь не несет ответственности за диагностику проблемы. Все, что они знают, это: «Я пытался сделать X, Y должно было случиться, но вместо этого произошло Z». Все остальное - ваша проблема.
Если специалисты по аппаратному обеспечению настаивают на том, что проблема в программном обеспечении, а специалисты по программному обеспечению настаивают на том, что проблема в аппаратном обеспечении, то вам необходимо усовершенствовать программное обеспечение для более точной диагностики ошибок, как отметили ChrisF и другие.
Если начальство обвиняет группу программного обеспечения в проблемах, за которые отвечает группа оборудования, и вам надоело брать на себя вину за ошибки других людей, хорошо, я понимаю это. Опять же, как программист, вы можете создавать более точные сообщения об ошибках. Если вы можете прямо сказать: «Шаговый двигатель не отвечает» или что-то еще, то у вас есть «моральный авторитет», чтобы настоять на том, чтобы кто-то провел диагностику шагового двигателя. Просто сказать: «Я почти уверен, что это проблема с оборудованием» не выиграет спор.
Тесто-ориентированная разработка (не обязательно означает "управляемая тестами") - это то, на что вы должны выделять ресурсы.
По сути, каждая подсистема должна иметь достаточно тщательный набор модульных тестов для выявления проблем до интеграции. Каждый раз, когда возникает проблема, тестируйте аппаратное обеспечение, чтобы вы могли точно (или почти точно) знать, что это проблема аппаратного обеспечения. Это означает, что аппаратное обеспечение должно быть спроектировано таким образом, чтобы его можно было тщательно протестировать.
Я был руководителем интеграции в команде роботов моего колледжа, и эта тактика очень помогает.
Надеюсь, это поможет.
"Если то, что вы делаете, не работает, прекратите это делать и попробуйте что-то другое"
Как отмечалось в других комментариях, это проблема коммуникации и, в меньшей степени, восприятия. Люди будут обвинять в том, чего они не понимают НАМНОГО легче, чтобы почувствовать себя жертвой. Двигатель может искрить, загораться и взрываться от того, что кто-то сильно перегрузил питающее устройство (с КАЖДЫМ предупреждением не делать этого) - но если программное обеспечение перестает отвечать, угадайте, что вызвало проблему?
Поскольку обучение каждого из ваших пользователей в классе EE и CS или 10 классах совершенно не обсуждается, вернитесь к старой доброй коммуникации. Основой которого являются 4 вещи (в основном мое мнение) без особого порядка - Что вы наблюдаете, что вы чувствуете, что вы думаете и что нужно сделать. Итак, с этой идеей я буду реализовывать на практике, давая такой ответ.
Похоже, что ваши пользователи любят обвинять программное обеспечение, в то время как ключевой проблемой (наблюдайте) является какое-то базовое аппаратное обеспечение. Пытаться объяснить это пользователям - непрактично и пустая трата времени, это не их работа, и большинству из них будет все равно (чувствую). Что вы можете попробовать, так это поговорить с командой инженеров о деталях, которые они используют, и поискать вещи, которые лучше работают с программным обеспечением в целом. Может быть, есть какие-то ограничения на входы, которые никогда не учитывались? (подумайте) Замена оборудования или просто лучшее его понимание может быть реальным ответом, а также более целенаправленные ошибки и обратная связь с пользователями (сделано).
Во-первых, убедитесь, что ваши пользователи с большей вероятностью прочитают и поймут ваши сообщения об ошибках. Отображение "команда FPGA GS_WIDGIT_FROB возвращает недопустимый ответ 0xFF45001C. Завершение работы контроллера с кодом 576D. (Ошибка 1Xf)" может быть по-раздобен для вас. Но пользователь, скорее всего, нажмет «Ок», не прочитав его. Даже если они читают его, это не говорит им никакой полезной информации. В любом случае, вы получаете телефонный звонок. Отображение «Widgit Frobber требует обслуживания», но все равно зарегистрируйте все тяжелые детали где-нибудь, и вы, вероятно, получите меньше звонков.
Во-вторых, вы знаете, что это аппаратная проблема, поэтому сделайте что-нибудь с этим! Получите поддержку аппаратного обеспечения электронной почты или что-то еще, что нужно, чтобы решить проблему. Если пользователь вынужден решить, какие действия предпринять, чтобы исправить это, вы можете поспорить, что он ошибется, по крайней мере, некоторое время. Если пользователь видит "Widgit Frobber требует обслуживания. Уведомление о поддержке оборудования (тикет No234)Они знают, что им не нужно ничего делать.
Я согласен с другими постерами, но я хотел добавить другую точку зрения: Все могло быть и хуже. Они могут пытаться решить аппаратные проблемы в течение нескольких дней или недель, а затем выяснить позже, когда все будут под прицелом и будут сходить с ума от того, что это не будет исправлено, что они решали не ту проблему, и на самом деле это была проблема программного обеспечения. Так что считайте, что вам повезло. Если они всегда классифицируют это как проблему с программным обеспечением, по крайней мере, вы об этом знаете. Только тогда вы сможете устранить неполадки, возможно, ввести дополнительный код для решения проблем или выявления проблем и сделать систему хоть немного лучше".
Кроме того, это практически то же самое, с чем когда-либо сталкивался каждый разработчик программного обеспечения. За исключением того, что обычно это программное обеспечение против пользователя, а не программное обеспечение против оборудования. И в этом случае, похоже, не существует известного решения. Есть много способов решить проблему, но нет способа ее устранить. Поэтому постоянно растет список аббревиатур, описывающих, как обвинить пользователя без грубости: ID-ten-T error, PICNIC, PEBKAC и т.д.