<\/HEAD>
We zijn er allemaal wel eens geweest. Je maag knort, maar al je mentale energie is gericht op het repareren van de auto voor je die vijftig rijdt op de snelste rijstrook. Wanneer mensen hangry (hongerig\/boos) zijn, kunnen ze prikkelbaar en geagiteerd overkomen, misschien wijzen ze zelfs op elk klein ding dat misgaat, terwijl het probleem zo simpel is als 1k heb honger. Voed me!7. <\/P>
Foutieve diagnoses komen de hele tijd voor en kunnen zich vertalen naar vele andere facetten van het leven, inclusief softwareproblemen, maar zou jij softwareproblemen kunnen diagnosticeren wanneer het lijkt alsof je software hangry is? <\/P>
Het goede nieuws is dat met wat oefening en observatievaardigheden iedereen softwareproblemen als een professional kan categoriseren. Deze blog zal je helpen bij het tegenkomen van softwareproblemen. Het doel is om de vele lagen die problemen kunnen compliceren te doorgronden, zodat je nauwkeurig, maar eenvoudig het probleem kunt aangeven waarbij je hulp nodig hebt.<\/P>
<\/P>
Symptomen van softwareproblemen zijn door de eindgebruiker in veel vormen waarneembaar, zoals een foutmelding, prestatievermindering of een softwarecrash, om er een paar te noemen. Hopelijk zorgen deze onderbrekingen ervoor dat gebruikers contact opnemen met Esri Support en een case aanmaken voor onderzoek. Bij Esri Support hebben onze analisten een specifieke vaardigheidset. Weinigen van ons zijn generalisten, en deze structuur is ontworpen om onze klanten elite technische ondersteuning te bieden020 met andere woorden, we gebruiken geen scripts.<\/P>
Waarom is dit belangrijk? Een van de eerste stappen bij het aanmaken van een case bij Esri Support is het geven van een beschrijving van het probleem, die zal worden gebruikt om een onderwerpregel in de case te vormen. Deze onderwerpregels kunnen worden aangepast naarmate er meer kennis wordt verkregen over het probleem door onderzoek, maar deze initieble onderwerpregel is een grote factor bij het bepalen welke analist de case eerst behandelt. <\/P>
<\/P>
Het bepalen van het algemene symptoom helpt bij het sturen van het triageproces en de levensduur van de case. Laten we deze symptomen in meer detail verkennen.<\/P>
<\/P>
1. Fout: <\/P>
Foutmeldingen zullen ons stoppen in onze sporen. Soms zijn de meldingen erg nuttig en vertellen ze ons precies wat we moeten weten om verder te gaan, soms minder. Wanneer gebruikers fouten tegenkomen vragen we altijd om een screenshot van de fout en de workflow (klikken) die tot de fout leidde. Bijvoorbeeld, 1k krijg de foutmelding: ongeldig cordinaatsysteem-ID7 wanneer ik gegevens toevoeg uit een Oracle enterprise geodatabase in ArcMap.<\/P>
<\/P>
2. Prestatievermindering: <\/P>
Persoonlijk is dit het meest frustrerende probleem om tegen te komen. Er is geen foutmelding; in plaats daarvan is het proces traag en vertelt het draaiende zandlopericoon je niet wanneer je prestaties weer normaal zijn. Wanneer prestatiecases op mijn bureau komen, beoordeel ik eerst de traagheid, omdat traagheid een relatieve term is en iets dat traag is in de ene omgeving optimaal kan zijn in een andere. Het symptoom hier is niet alleen prestatie, maar specifiek prestatievermindering. Met andere woorden, er was een optimalere prestatie die nu verminderd is.<\/P>
Symptomen van trage prestaties kunnen door veel dingen worden veroorzaakt waaronder workflows, overbelaste bronnen en softwarecompatibiliteit om er een paar te noemen. Om met troubleshooten te beginnen is het altijd nuttig om een vergelijkingscase beschikbaar te hebben voor onderzoek. Als je denkt dat je traagheid in software ziet, vraag jezelf dan eerst af dit is traag vergeleken met wat? <\/P>
Bijvoorbeeld, het gebruik van ArcMap 10.1 sp1 om dezelfde workflow op dezelfde gegevens uit te voeren duurt 1 seconde, terwijl gebruik van ArcMap 10.5.1 20 seconden duurt<\/EM>, of Het bekijken van feature class A in ArcCatalog duurt 1 seconde, terwijl bekijken van feature class B 20 seconden duurt. Beide features zijn opgeslagen in dezelfde enterprise geodatabase.<\/EM><\/P>Deze voorbeelden geven ons een snel voorbeeld en een traag voorbeeld die met elkaar vergeleken kunnen worden. Let op dat er in deze voorbeelden slechts n verschil is in de workflows, waardoor we gecontroleerde variabelen hebben en n afhankelijke variabele om te beoordelen020 net als wetenschappers.<\/P><\/P>3. Onverwachte resultaten: <\/P>Dit symptoom zal net als prestatie geen foutmelding geven, maar anders dan prestatie symptomen zullen deze processen wel voltooid worden en lijken succesvol te zijn. Echter wanneer de resultaten geanalyseerd worden zijn ze onjuist of onvolledig. Onverwachte resultaten kunnen ook voorkomen als tools die uitgeschakeld of grijs weergegeven zijn.<\/P>Bijvoorbeeld, Ik open ArcCatalog om Editor Tracking in te schakelen op mijn feature class, maar Enable Editor Tracking is grijs weergegeven<\/EM>, of Ik heb een replica gemaakt van mijn U.S. States feature class, maar slechts 48 staten werden gerepliceerd naar de child geodatabase.<\/EM><\/P>Meestal komen onverwachte resultaten voort uit een workflowprobleem. Een instelling die aan had moeten staan voor deze tool werkte niet of eigenschappen\beperkingen op deze data veroorzaakten onverwachte resultaten. In het eerste voorbeeld hierboven moet de verbinding gemaakt worden als data-eigenaar om Editor Tracking in te schakelen. Elke andere gebruikersverbinding ziet de Editor Tracker optie grijs weergegeven. Het tweede voorbeeld waarbij niet alle data gerepliceerd werd kan komen door filters die geplaatst zijn op de data die gerepliceerd wordt of relatieklassen die database referentiële integriteit afdwingen. <\/P> <\/P>4. Crash:<\/P>Klik klik boem gaat het dynamiet.
Er is geen foutmelding.
Het beste wat je kunt doen is de software opnieuw openen en opnieuw proberen.
Esri beschouwt alle crashes als bugs.
We willen dat onze software je een betekenisvolle foutmelding geeft die je helpt je werk af te ronden.
Crashes gebeuren wanneer de software een argument tegenkomt dat hij niet weet hoe op te lossen.
Meld crashes altijd aan Esri Support zodat wij kunnen zorgen dat onze software weet hoe met deze situaties om te gaan.<\/P> <\/P>Softwareproblemen kunnen complex zijn en meerdere technologieën gebruiken die verschillende niveaus van expertise vereisen over veel verschillende onderwerpen. Deze problemen kunnen benaderbaarder worden door de vraag te beantwoorden: Wat heb ik waargenomen tijdens mijn dagelijkse werk waardoor ik hulp heb gevraagd? Hoewel er altijd uitzonderingen zijn kan ik in 90% van de gevallen beginnen met het beantwoorden van die vraag met n of meer symptomen besproken in deze blog. Ik hoop dat dit helpt om het vermeende duister rond softwareproblemen wat lichter te maken en zoals altijd bel ons gerust als je een van deze problemen tegenkomt of gewoon vragen hebt voor ons. <\/P><\/P>esrisupport<\/P><\/BODY><\/HTML>
