Методики диагностики неисправностей.

Пациент перед смертью потел?
Потел?. Это хoрошо !!!.
(из анекдота о врачах)

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

До самого последнего времени мало кто обращал внимание на то обстоятельство, что общение с ЭВМ провадит к изменению самих людей, их поступков, привычек, характеров и даже судеб. На наших глазах рождается новое социальное явление -homo computerus, что в переводе с латинского означает "человек компьютеризированный''. Но идиллия не вечна. Пожар!!! В бухгалтерии "поломалась" база данных. Файловый сервер на другом этаже летит к чертям, документы тамошних пользователей летят туда же. Малозаметная ошибка привела к несовместимости используемого на рабочем месте программного обеспечения. В результате ошибка "вешает" систему, компьютер отдыхает, а пользователи мечутся в панике с криками: "Пусть хоть 100 ошибок лиш бы компьютер работал!!!" (завтра сдавать заказ, в громадной очереди стоят клиенты, не запускается любимая игрушка и т.д.). Сопровождающие программисты весь свой день заняты тушением больших и маленьких возгорания и к концу дня описанные ниже методы врачебной диагностика можно, применять к ним. Если реакция компьютера на действия пользователя оказалась для вас неожиданной - это хороший повод остановиться, подумать, проанализировать действия пользователя, поискать в них то, что привело к странной реакции компьютера. И лучше это делать не в состоянии "горячки", в которую вы впали, а с холодной головой. Не нужно пытаться переупрямить компьютер, молотя беспорядочно по клавишам. Приобретите стойкую уверенность в том, что компьютер правильно реагирует на правильные команды. К сожалению, человеческая психика устроена так, что допустив однажды ошибку, пользователи склонны повторять ее снова и снова (вам, наверное, знакомы так называемые "глазные ошибки", когда неправильное написание слова при чтении постоянно не обнаруживается). В таких ситуациях надо либо на время отвлечься, либо попытаться объяснить и про демонстрировать кому-нибудь вашу проблему. Часто этого бывает достаточно для того, чтобы все понять самому. Большинство причин сбоев оказываются очень простыми, когда, наконец, сумеешь их вычислить. Сбои и зависания обнаружить легко, логические ошибки гораздо сложнее. Очень часто на рабочем месте установлено несколько программных и апаратных средств, и ошибка может крыться в любом из них или вообще где-нибудь на их стыке. Предыдущий сбой "прятал" за собой другую неисправность, более серьезную, которая теперь вылезла на поверхность и грозит нам срывом, технологического процесса. Пользователи отять обнаружили все новые и новые способы свести программу с ума. Во многом это не наука, а искусство. Более чем 10-летний опыт общения с компьютерами побуждает меня поделиться с вами некоторыми соображениями об отношениях между пользователями и компьютерами. Выполнение компьютером достаточно сложных программ способствует возникновению (особенно у новичков) иллюзии разумности его поведения. Со временем, конечно, она исчезает, становится понятно, что компьютер не более сложен, чем вложенные в него программы. Но на первых порах!... Так вот, работая на компьютере, пользователи ни на минуту не должны забывать, что перед ними машина и только машина, что они имеют дело с неодушевленным предметом. "Нет ничего легче" - подумаете вы. Однако мой опыт показывает, что это вовсе не такое простое и совершенно необходимое условие для установления "правильных" отношений пользователя с компьютером. До того, как программа появится на рабочих местах пользователя, она проходит несколько стадий - альфа версию, представляющую собой кое-как работающий скелет программы, и затем бета-версию, которая уже должна делать, все, что от нее требуется. До этапа бета-версии тестированием программы занимается лишь несколько человек, однако, на этапе "бета" к ним подключается еще не мнение дюжины специалистов из отдела контроля качества. Заглянув к ним в любое время суток, в любой день, вы застанете несколько человек за работой. Вы, наверное, думаете, что это не такая уж и, плохая, работа, тем более, что за нее платят деньги. Однако должен вас разочаровать: да, они работают с новыми программами, но и постоянно находят ошибки. В Украине наблюдается несколько иная ситуация. Где-то за десятки, сотни километров находится разработчик или группа разработчиков, на местах применения ПО создаются гуппи из 2-3 программистов которые и выполняют функции бета-тестеров вместе с пользователями. От знаний и умений которых быстро локализировать причину сбоя и зависит работоспособность данного рабочего места или целого технологического процесса. Особенно это характерно для организаций с разветвленной сетью отделений. Две основные задачи стоят перед практикующим программистом - распознать причину неисправности ( поставить диагноз) и минимизировать последствия. Можно выделить три пути, следуя которыми программист может обеспечить высокое качество своей работы:

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

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

В обучении программистов, как вузовском, так и пост дипломном, основное внимание уделяется языкам и методам программирования большая часть времени уходит на накопление и расширение информации. Об методах диагностики ошибок упоминается в скользь. Существующая система подготовки программистов работает с огромным дефицитом методик и знаний поиска неисправностей. Мало времени уделяется обучению методам переработки информации, в частности методам диагностики логических ошибок. Если за диагностикой ошибок при написании программы следит компилятор то считается, что с умением искать логические ошибки вы должны родится иначе не зачем сунутся в программисты. Диагностика ошибок на рабочих местах пользователей находится на уровне медицины средневековья. Тогда врачи уже имели понятие об основных функциях человеческого организма, но все равно причиной всех болезней считалась плохая кровь, которую требовалось выпустить. В отличие от человека основные "узлы" и "software" которого сформировались несколько миллионов лет назад. Рабочее место пользователя отличается огромным разнообразием аппаратных и программных средств и их взаимодействий. Поэтому дать конкретные рекомендации очень и очень сложно. В первую очередь рассчитывайте на свой ум и сообразительность. Поскольку мы не волшебники, а все еще учимся, то речь мы поведем не о потрясающих воображение чудесах, позволяющих создавать безошибочные программные системы, а о небольших, но полезных приемчиках "колдовства", помогающих быстро установить причину ошибки и наметить пути ее устранения. Источником исключительных ситуаций могут быть как ошибки в программе, так и не верные входные данные, задаваемые пользователем, внешняя среда, в которой работает программа. Процесс установления причины неисправности (диагноза) в практике программиста, и в частности выявление логических ошибок непосредственно на рабочих местах пользователей, можно рассматривать как частный случай проблемы принятия решений. В этой связи следует опираться и использовать положения хорошо разработанной в психологии теории принятия решений. Согласно этой теории, диагностирование представляет собой решение задач с риском, т.е. такого класса ситуаций, в которых имеется неопределенность относительно возможного получаемого результата. Человек, решающий такие задачи, в данном случае сопровождающий программист интуитивно использует определенную стратегию правил мышления которая уже сознательно применяется врачами в их работе. Попробуем применить эти методы для обнаружения причин неисправностей на рабочих местах пользователя. Как принимается решение о диагнозе ? Принципы и методы диагностики.

Различают два принципа диагностического мышления - нозологический и синдромный.

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

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

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

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

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

Принцип не навреди .

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

Бытует заблуждение, что есть программы, которые восстанавливают стертые файлы. Не верьте этому! Удачное восстановление возможно только в редких счастливых случаях. Лучше прежде чем что-то уничтожить - подумать, еще раз подумать, чем потом лихорадочно соображать, почему "восстановленная" программа не работает или где отыскать копии стертых данных. К счастью, другие операционные системы уж если что стирают, то насовсем. ОБЩИЕ СПОСОБЫ ОБСЛЕДОВАНИЯ.

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

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

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

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

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

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

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

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

Анамнез

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

Выяснение механизма сбоя и установление места и причин происшествия имеют большое значение. На основании типичного механизма неисправности можно установить у ряда неисправностей безошибочную причину. Вместе с тем знание обстоятельств сбоя может явиться основанием для разработки профилактических мероприятий, направленных на снижение простоев рабочего места. Тяжелая авария может в ближайшие часы привести к полному выходу рабочего места и технологического процесса. Поэтому, расспрашивая пользователя о обстоятельствах, при которых произошел сбой, программист может оказаться важным и единственным источником информации для следственных органов. Расспрос пользователя о начале и первых признаках сбоя, его динамике, предшествующих ремонтах должен проводиться подробно: Есть неисправности и повреждения, при которых один только тщательно собранный анамнез или повреждения позволяет не только заподозрить, но и установить правильную причину. На некоторых рабочих местах с течением времени многие объективные симптомы могут исчезнуть и во время обследования их обнаружить не удается. Примером может служить постановка диагноза повреждения секторов винчестера. Если в анамнезе выявляется классический механизм сбоя с блокировкой работы ПО, характерное течение, а затем периодически повторяющиеся сбои винчестера, то диагноз отказа секторов НDD не вызывает сомнений. Целенаправленным обследованием, рабочего места необходимо лишь исключить или, наоборот, выявить повреждение секторов винчестера. В процессе расспроса пользователя выясняют состояние различных систем: Размер свободного места, быстродействие, работа печатающего устройства, клавиатуры и др. Как и при всех других сбоях, желательно собрать (знать) историю рабочего места. Здесь выявляют: состояние систем при создании. Условия труда и производственные вредности существенно могут повлиять на функции аппаратуры. Всегда необходимо выяснить, какие сбои происходили ранее на этом рабочем месте. Порядок обследования аварийной ситуации на рабочем месте заключается в опросе пользователя и выявлении объективной симптоматики. Опрос должен быть по возможности кратким, целенаправленным и относиться к тем фактам, которые могут непосредственно повлиять на постановку диагноза. Процесс собственно выяснения причин неисправности на рабочем месте пользователя складывается из опроса (жалобы, анамнез неисправности), оценки общего состояния и изучения патологических данных (status localis). В условиях реального времени нередко приходится начинать с изучения объективных данных, чтобы ограничить объем собранной информации только самыми существенными моментами. Осмотр

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

Правильнее было бы сказать, что знакомство программиста с конкретным рабочим местом начинается с осмотра, а не с расспроса. Увидев рабочее место, внимательный программист должен заметить особенности поведения пользователя, внешний вид техники, вынужденную и необычную последовательность действий, нарушение обычного порядка технологического процесса. Осмотр рабочего места позволяет выявить множество достоверных симптомов повреждений и неисправностей аппаратуры и ПО. Проведение осмотра должно осуществляться с соблюдением определенных правил, последовательно и полно. В момент обследования рабочее место должен быть полностью доступно. Персональные компьютеры делают так, чтобы они работали как электрический утюг: включил в сеть и гладь. Но это не значит, что компьютер не требует никакого ухода. Запретите пользователям разводить на столе, где стоит компьютер, свинарник, оранжерею с кактусами. Приучите стирайте пыль и с экрана монитора, и с системного блока и т.п Не тащите на компьютер все подряд! Не делайте из него программную "помойку"!. Речь идет об одном из "рефлексов программиста". Четко определите диапазон компьютерных программ для данного рабочего места. На мировом рынке персональных компьютеров продаются десятки тысяч пакетов программ. Такую прорву даже только просмотреть едва ли возможно, не говоря уже о том, чтобы все попробовать. Вывод такой - нельзя объять необъятное. Кроме того, чем больше программ установлено на рабочем месте пользователя, тем выше вероятность того, что ни в меру любопытный пользователь запустит что-то не положенное о возможности занесения в компьютер вируса или троянской программы, особенно если программы достались вам через вторые, третьи или Бог знает какие руки. Следите за версиями, не держитесь без нужды за старые варианты программ. Чем больше у вас программ, тем труднее поддерживать программное обеспечение в должном порядке. Целесообразно попросить пользователя выполнить постоянные операции. В это время определяют возможные не верные действия пользователя и не верную настройку тумблеров и переключателей, установок в программном обеспечении. Попробуйте самому выполнить действия, которые вызывают проблему в пользователя. В этот момент вы должны преобразится в "профессионального идиота". "Профессиональный идиот" - это не всегда буквальная характеристика. В коллективах, создающих сложные - и не только компьютерные - системы, так называют высококвалифицированных профессионалов, в чьи задачи входит нахождение слабых мест в сдаваемых разработках. Они получают в свое распоряжение систему непосредственно перед или сразу после прохождения ОТК и стараются вывести. ее из строя законными способами. Когда представитель этой профессии возьмется за очередную модель принтера, то он, вероятно, попробует:

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

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

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

1. Жалобы и уточнение их характера. Начало и развитие неисправности (anamnesis morbi) и факторы, непосредственно ему предшествовавшие. Для неотложных состояний - точное указание времени начала сбоя. Проведенные ремонты и их эффективность. Особое внимание следует обратить на саморемонты, их форму и продолжительность. Если техника на рабочем месте ранее проходила технический осмотр третьих фирм, то желательно иметь сведения о полученных результатах и рекомендациях (технические документы, акты). Ориентировочное ознакомление с функциональными особенностями основных систем техники (со слов пользователя ): быстродействие процессора, принтера, сети и т.д. Краткая история рабочего места (anamnesis vitae) с акцентом на возникавшие ранее аварии, могущие оказать существенное влияние на диагнозностирование сбоя. Объективное обследование рабочего места (общее состояние индикаторов, положение тумблеров,скорость обмена информацией с локальными устройствами ). Изучение местных данных (status localis) и выявление симптомов, присущих предполагаемой неисправности. Изучение основных систем и определение изменений, возникших под влиянием местного или общего процесса.
2. Назначение и проведение лабораторных и специальных методов исследования.

В принципе в условиях рабочего места допустимо отступление от приведенной схемы обследования (жалобы, anamnesis morbi, anamnesis vitae, последовательное изучение всех органов и систем, locus morbi и т. д.).

Первоочередное обследование пораженных систем или органов позволяет значительно сократить время, необходимое для установления причины неисправности и оказания рациональной помощи, особенно при локальных неисправностях. Однако при существовании трудностей в правильной интерпретации полученных данных необходимо точно придерживаться приведенной схемы. Методика поиска причины сбоя должна быть строго последовательной, даже в совершенно очевидных для опытного программиста случаях. Следующим положением является переход от менее "трав матичных" способов обследования к более "трав-матичным". Очевидно, наиболее безопасным является осмотр. При осмотре обязательны наличие хорошего освещения и возможность сравнить показания индикаторов и положение переключателей с работающей аналогичной техникой. В процессе осмотра производится изучение активных движений контактов и переключателей соответствующей части устройства вызвавшей подозрения. Помощь программистов на рабочих местах пользователей предусматривает обследование для установления причины сбоя, оценки общего состояния и связанной с ним степени риска полного выхода рабочего места из эксплуатации. Перечень обязательных мероприятий определяется характером неисправности и показанным методом устранения (возможность исправления ситуации на рабочем месте, замена отдельных узлов на резервные силами программистов, направление техники в специализированные ремонтные учереждения ). Полноценное обследование на рабочем месте позволяет значительно сократить сроки устранения ошибки из исходного кода группой занимающихся разработкой ПО. Беседуйте с другими программистами, работающими с аналогичным soft и hard ware! Часто несколько минут такой беседы могут стоить недельных собственных усилий. Внятное изложение своих трудностей другому человеку позволяет иногда по-новому взглянуть на проблему или просто четко сформулировать ее для самого себя. Именно это зачастую оказывается самым сложным. Поговорите с более опытными людьми; а лучше, если они смогут вам что-то показать на практике. В дальнейшем же, если появится какая-то проблема, сначала постарайтесь разобраться в ней с помощью документации сами. Если вы будете постоянно пользоваться услугами друзей, едва ли к вам придет уверенность в собственных силах. Что легко пришло -легко и уйдет. Не следует считать, что консилиум заменит чтение документации. Нужны и самостоятельная работа с документацией, и общение с коллегами. В каждом конкретном случае только ваш опыт может подсказать, как быстрее и проще отыскать ответ. При обследовании сбойной ситуации определяют не только причина вызвавшая сбой и показания к замене техники на резервную. Не менее важна общая оценка неисправности. В неотложных ситуациях, когда сложности сбоя придается меньшее значение, рабочее место автоматически квалифицируется к замене на резервные элементы . Ряд симптомокомплексов (сбой жесткого диска, отсутствие инициализации, не возможность подключения к серверу) сами по себе могут служить показанием к неотложным мероприятиям и исключению рабочего места из технологического процесса . В таких случаях в условиях рабочего места важнее не пытаться точно установить диагноз как причину угрожающего состояния, а оказать необходимую помощь для продолжения нормальной работы на данном рабочем месте. После накопления информации приступим к рассмотру способов установки причины неисправности. Характеристика систем памяти

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

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

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

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

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

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

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

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

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

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

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

Решающее правило - тщательное субъективное и объективное обследование рабочего места. Это важнейший этап диагностики. Неполное или недостаточно детализированное исследование нередко приводят к ошибкам в диагностике.

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

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

Группировка симптомов в синдромы и выделение ведущего синдрома

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

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

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

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

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

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

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

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

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

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

Общие правила выбора методов исследования:

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

Если выполнен решающий метод и поставлен диагноз нозологической формы, то диагностический поиск заканчивается.

Группировка ранее выявленных и вновь обнаруженных симптомов в синдромы и выделение ведущего синдрома

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

Выдвижение ВДГ ( вторичных диагностических гипотез) , их ДД - установление окончательного диагноза НФ ( нозологической формы )

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

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

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

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

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