"Uten et veikart, kan du være at du kjører i sirkler."
- Bryce's Law
INNLEDNING
Ok, du har kjørt programmet debugger full av gjentagelser og alt stemmer bra. Men for noen ukjent grunn, er hele systemet ubrukelig. Både programvare og data base design ser veldig bra ut, men du kommer sterk-gal prøver å finne problemet. Har du vurdert at det ikke kan være en feil i utformingen av programvare eller data base i det hele tatt? At kanskje problemet ligger i den totale systemarkitektur, eller muligens det bare deg?
I mange tilfeller, diagnostisering et problem er mer smertefullt enn å korrigere det. Mens jeg har gjennomgått grunnleggende prinsipper testing i det siste, se;
Nr. 41 - "Prøving 1, 2, 3 ..." - 12.09.2005
http://www.phmainstreet.com/mba/ss050912.pdf
Her vil jeg diskutere noen tips for å diagnostisere problemer.
Tre tips
En. Gå gjennom systemet og sjekk mann / maskin grensesnitt.
År siden, fikk vi kontrakt av en stor industribedrift lokalisert i nordøst som har problemer med å implementere sin nye butikk-gulv kontrollsystem. Systemet var state-of-the-art når det gjelder programmering og DBMS teknologi. Men de kunne ikke få det til å fungere uansett hva de forsøkte. Frustrert, leide selskapet vi skal se om vi kunne finne problemet. I stedet for å studere kildekoden, som utvikling personalet hadde gjort, begynte vi ved å kartlegge det totale systemarkitektur.
Jeg har beskrevet den "PRIDE" Standard System Struktur Konsept på mer enn én anledning, men i et nøtteskall, kan et system trekkes som en fire-lags hierarki representerer et produkt struktur. Mens et produkt struktur består av fire nivåer representerer produkter, råd, delmontasjer, og drift, "PRIDE" dekomponerer likeså systemet i:
Nivå 1 - SYSTEM
Nivå 2 - SUB-SYSTEM (Business Processes)
LEVEL 3 - PROSEDYRER (Administrative og Computer)
Nivå 4 - OPERATIVE STEG (for saksbehandling) og programmer (for Computer Prosedyrer)
Dette universelt tilnærming for å definere systemet arkitektur gjør et praktisk veikart for fotturer gjennom alle aspekter av systemet og validere sin integritet. Slike hierarkiske diagrammer kan enten produseres fra IRM Repositories eller fra noen enkle grafiske verktøy. I vår rådgivning oppdrag selv, vi bare skisserte den ut med papir og blyant. I utgangspunktet, gikk vi gjennom systemet, samplet arbeid og så for menneske / maskin grensesnitt. Uunngåelig, kom vi på en sub-system der maskinen som vises feil i butikken etasje som krever oppmerksomhet av formannen. Formannen var å ta korrigerende tiltak og svare på datamaskinen. Det var bare ett problem med dette: ingen hadde fortalt formannen om noe av dette. Vi skrev da en enkel saksbehandling for formannen som tok de nødvendige tiltak, og systemet drives korrekt etterpå ("mirakel" som vår klient sa).
Dette bringer opp et viktig punkt: systemene vil feile mer for mangel på administrative prosedyrer enn for godt programmert datamaskin prosedyrer. Selv om produksjon selskapet hadde produsert noen ganske elegant programvare, hadde de helt oversett mannen / maskin-grensesnitt. Igjen, det "PRIDE" Standard System Struktur Konsept hadde gitt de nødvendige
veikartet, men fordi kunden ikke setter pris på behovet for en slik ovenfra og ned blueprinting teknikk, hadde de ingen anelse om hvor alt var.
2. Arbeid bakover.
Når diagnostisering forretningsprosesser, rutiner og programmer, det er en naturlig tilbøyelighet til å gå fra start til slutt i diagnostisering av et problem. Noen ganger kan du finne en hikke ved hjelp av denne tilnærmingen, andre ganger kan du ikke. Prøv heller jobbe bakover fra ende til start, fra utgang til inngang. Igjen, kart design ved hjelp av en flytskjema eller en annen grafisk teknikk. Dersom behandlingen innebærer betydelig beslutninger, trekke en beslutningstre eller bord. Slike grafikk er uvurderlig for validering
design logikk.
Tre. Har en andre øyne se på arbeidet ditt.
Når vi blir besjelet i mekanikken i et design, for ofte den åpenbare blir mindre innlysende for oss. Her kan et nytt sett med øyne lett ser et problem vi har oversett. Dette er spesielt gunstig i butikkene opererer i samsvar med visse standarder design. Enhetlig design praksis gjør
det lettere å oppdage uregelmessigheter enn uten slike standarder.
Hvor den andre personen kommer fra er også viktig. Hvis personen kommer fra arbeidsgruppen, og er kjent med din stil av design, han / hun kan meget vel være i stand til å oppdage et problem. Så igjen, kanskje ikke. Kanskje problemet vil være usynlig for dem også. I dette tilfellet kan det være lurt å konsultere en nøytral
tredje person med et friskt perspektiv på problemet. Dette kan enten være en person fra selskapet eller eventuelt en ekstern konsulent.
KONKLUSJON
Grafisk hjelpemidler, for eksempel flytskjemaer og diagrammer, er nyttig for diagnostisering av et problem, men også huske å utfordre den grafiske. Det er ikke uvanlig at grafikken ikke å matche det som skjer i virkeligheten. En god IRM Repository er også uvurderlig for fyllestgjørende design. Designen er enten behørig registrert
i IRM Repository eller det er ikke. Videre gir et slikt verktøy midlene til å studere forholdet av informasjon ressurser (aka "konsekvensanalyse") som kan avsløre ukjente komponenter som påvirker et design.
Enda viktigere, ideen om å opprettholde et system arkitektur (som gjennomføres av "PRIDE" Standard System Struktur Konsept) gir den nødvendige veikartet for å finne veien gjennom et system uavhengig av sin kompleksitet. Mange programmerere se for eksempel diagrammer som lettsindig først og fremst fordi de er bare opptatt av sine små brikke i puslespillet, og er ubekymret om det totale bildet. Men for de av dere som trenger å se det totale bildet, er systemet arkitektur logiske første skritt for å diagnostisere problemer.
For mer informasjon om "PRIDE" Standard System Struktur konsept, se:
http://www.phmainstreet.com/mba/pride/is.htm