"Utan en plan, kanske du kör i cirklar."
- Bryce's lag
INLEDNING
Okej, du kör programmet felsökare upprepade gånger och kontrollerar allting bra. Men av någon okänd anledning är hela systemet obrukbart. Både mjukvara och databasdesign ser fin ut, men ni kommer skarp-Raving galna att försöka lokalisera problemet. Har ni övervägt att det kanske inte är en brist i utformningen av programvara eller data base alls? Det kanske problemet ligger i det övergripande systemet arkitektur, eller möjligen det bara du?
I många fall diagnosticera ett problem är mer smärtsamt än att rätta till det. Medan jag har gått igenom grundläggande tester principer i det förflutna, se;
Nr 41 - "Test 1, 2, 3 ..." - 12 September 2005
http://www.phmainstreet.com/mba/ss050912.pdf
Här vill jag diskutera några tips för att diagnostisera problem.
Tre tips
1. Gå igenom systemet och kontrollera människa / maskin-gränssnitt.
År sedan var vi på uppdrag av ett stort industriföretag i nordost som har problem med att genomföra sin nya verkstadsgolvet styrsystem. Systemet var state-of-the-art i fråga om programutbud och DBMS tekniken. Men de kunde helt enkelt inte få det att fungera oavsett vad de försökte. Frustrerad anlitade företaget för oss att se om vi kunde hitta problemet. Istället för att studera källkod, i utvecklingen personalen hade gjort, började vi med att kartlägga det övergripande systemarkitektur.
Jag har beskrivit den "Pride" standardsystem Struktur Concept på mer än ett tillfälle, men i ett nötskal, kan ett system tas ut som en fyra nivåer hierarki som representerar en produkt struktur. En produkt struktur består av fyra nivåer som representerar produkter, utrustningar, komponenter och operationer, "Pride" på samma sätt sönderdelas systemet i:
Nivå 1 - SYSTEM
Nivå 2 - delsystem (affärsprocesser)
NIVÅ 3 - Förfaranden (administrativ och dator)
NIVÅ 4 - operativa åtgärder (för administrativa förfaranden) och program (Computer förfaranden)
Denna allmängiltiga synsätt för att definiera systemarkitekturen gör en bekväm färdplan för promenader genom alla aspekter av systemet och godkänna sin integritet. Sådan hierarki diagram kan antingen produceras från IRM förråd eller några enkla grafiska verktyg. I våra konsultuppdrag dock skissade vi helt enkelt ut med hjälp av papper och penna. I grund och botten gick vi genom systemet, urvalet arbete och såg till människa / maskin-gränssnitt. Oundvikligen kom vi på en sub-system där datorn visas fel i verkstadsgolvet som kräver uppmärksamhet av förman. Förmannen var att vidta de korrigerande åtgärder och svara på datorn. Det fanns bara ett problem med detta: ingen hade sagt till förman om något av detta. Vi sedan skrev ett enkelt administrativt förfarande för förmannen som vidtog de nödvändiga åtgärderna och systemet skulle fungera korrekt därefter ("mirakulöst" som kund sa).
Detta visar en viktig punkt: system kommer att misslyckas mer för bristfälliga administrativa förfaranden än väl programmerad dator förfaranden. Även om det tillverkande företaget hade producerat några ganska elegant programvara, de hade förbisett helt mellan människa och maskin. Återigen, "Pride" Standardsystem Struktur Concept hade lämnat de nödvändiga
färdplan, men eftersom kunden inte uppskatta behovet av en sådan top-down BluePrinting teknik, hade de ingen aning om vart allt var.
2. Arbeta bakåt.
När diagnostisera affärsprocesser, rutiner och program, det finns en naturlig benägenhet att gå från början till slut att ställa diagnos ett problem. Ibland kan du hitta en hicka som använder denna metod, andra gånger kan du inte. Försök istället att arbeta baklänges från slutet till början, från produktion till ingången. Återigen, karta mönstret med ett flödesschema eller någon annan grafisk teknik. Om behandlingen innefattar betydande beslut, utarbeta ett beslut träd eller bord. Sådana bilder är ovärderliga för validering
design logik.
3. Har ett extra par ögon ser över ditt arbete.
När vi blir präglas i mekaniken i en konstruktion, alltför ofta det självklara inte lika uppenbar för oss. Här kan en annan uppsättning ögon ser lätt ett problem som vi har förbisett. Detta är särskilt användbart i affärer i enlighet med vissa normer för utformning. Enhetlig design metoder gör
det lättare att upptäcka avvikelser än utan sådana standarder.
Om den andra personen kommer från är också viktigt. Om personen kommer från ditt arbete grupp och är bekant med din stil design, kan han / hon mycket väl kunna upptäcka ett problem. Då igen, kanske inte. Kanske problemet kommer att vara osynliga för dem. I så fall kanske du vill rådfråga en neutral
tredje person med ett nytt perspektiv på problemet. Detta kan antingen vara en person inifrån företaget eller eventuellt en extern konsult.
SLUTSATS
Grafiska hjälpmedel som flödesscheman och diagram är användbara för diagnostik ett problem, utan även komma ihåg att utmana bilden. Det är inte ovanligt att grafik inte matcha vad som händer faktiskt. En bra IRM Arkivet är också ett ovärderligt för styrkande design. Designen är antingen registreras på vederbörligt sätt
i IRM arkivet eller inte. Dessutom ger ett sådant verktyg medel för att studera sambandet av informationskällor (aka "konsekvensanalys") som kan avslöja okända komponenter som påverkar en design.
Ännu viktigare är tanken att behålla ett system arkitektur (som genomförts av "Pride" Standard System Struktur Concept) ger den nödvändiga vägen kartan för att hitta din väg genom ett system oberoende av dess komplexitet. Många programmerare visa sådana sjökort som oseriöst främst eftersom de bara bryr sig om sina små pusselbit och är likgiltiga för den totala bilden. Men för dig som behöver se den totala bilden, systemarkitekturen det logiska första steget för att diagnostisera problem.
För mer information om "Pride" standardsystem Struktur Concept, se:
http://www.phmainstreet.com/mba/pride/is.htm