har du hørt den om det forsvinnende lageret? En dag forsvant den-ikke fra fysisk syn—men fra de vaktsomme øynene til en velkjent forhandlers automatiserte distribusjonssystem. En programvarefeil hadde på en eller annen måte slettet lagerets eksistens, slik at varer bestemt for lageret ble omdirigert andre steder, mens varer på lageret sløvet. Fordi selskapet var i økonomiske problemer og hadde vært forskaling andre varehus for å spare penger, de ansatte på «manglende» lageret holdt stille. I tre år har ingenting kommet eller forlatt. Ansatte fikk fortsatt lønnsslippene sine, fordi et annet datasystem håndterte lønnslisten. Når programvarefeil endelig kom frem i lyset, varene i lageret ble solgt, og øverste ledelse fortalte ansatte å si noe om episoden.
denne historien har vært flytende rundt it-bransjen i 20-noen år. Det er sannsynligvis apokryft, men for de av oss i bransjen er det helt plausibelt. Hvorfor? Fordi episoder som dette skjer hele tiden. I oktober i fjor måtte den gigantiske Britiske matforhandleren J Sainsbury PLC avskrive SIN INVESTERING PÅ 526 millioner dollar i et automatisert forsyningskjedestyringssystem. Det ser ut til at varer ble sittende fast i selskapets depoter og varehus og ikke kom gjennom til mange av sine butikker. Sainsbury ble tvunget til å ansette ca 3000 ekstra funksjonærer for å lagre hyllene manuelt .
Dette er bare en av de siste I en lang, dyster historie AV IT-prosjekter gått galt . DE FLESTE IT-eksperter er enige om at slike feil oppstår langt oftere enn de burde. Dessuten er feilene universelt fordomsfrie: de skjer i alle land; til store selskaper og små; i kommersielle, ideelle og statlige organisasjoner; og uten hensyn til status eller omdømme. Forretnings-og samfunnskostnader av disse feilene – i form av bortkastede skattebetalere og aksjonær dollar samt investeringer som ikke kan gjøres-er nå godt inn i milliarder av dollar i året.
problemet blir bare verre da det vokser allestedsnærværende. I år vil organisasjoner og myndigheter bruke anslagsvis $ 1 trillion på it-maskinvare, programvare og tjenester over hele verden. AV IT-prosjektene som er igangsatt, vil fra 5 til 15 prosent bli forlatt før eller kort tid etter levering som håpløst utilstrekkelig. Mange andre kommer sent og over budsjett eller krever massiv omarbeiding. Få IT-prosjekter, med andre ord, virkelig lykkes.
den største tragedien er at programvarefeil for det meste er forutsigbart og unødvendig. Dessverre ser de fleste organisasjoner ikke å forhindre feil som en presserende sak, selv om det ser risiko for å skade organisasjonen og kanskje til og med ødelegge den. Å forstå hvorfor denne holdningen vedvarer, er ikke bare en akademisk øvelse; det har enorme implikasjoner for næringsliv og samfunn.
PROGRAMVARE ER OVERALT. Det er det som lar oss få penger fra EN MINIBANK, ringe og kjøre bilene våre. En vanlig mobiltelefon inneholder nå 2 millioner linjer med programvarekode; innen 2010 vil det trolig ha 10 ganger så mange. General Motors Corp. da vil bilene ha 100 millioner kodelinjer hver.
det gjennomsnittlige selskapet bruker omtrent 4 til 5 prosent av inntektene på informasjonsteknologi, med de som er svært IT—avhengige—som finans-og teleselskaper-bruker mer enn 10 prosent på det. Med andre ord, er det nå en av de største bedriftens utgifter utenfor ansattes kostnader. Mye av pengene går til maskinvare-og programvareoppgraderinger, programvarelisensavgifter og så videre, men en stor del er for nye programvareprosjekter som er ment å skape en bedre fremtid for organisasjonen og dens kunder.
Regjeringer er også store forbrukere av programvare. I 2003 hadde Storbritannia mer enn 100 store STATLIGE IT-prosjekter på gang som utgjorde 20,3 milliarder dollar. I 2004 katalogiserte den AMERIKANSKE regjeringen 1200 sivile IT-prosjekter som kostet mer enn 60 milliarder dollar, pluss ytterligere 16 milliarder dollar for militær programvare.
noen av disse prosjektene kan koste over $1 milliard. For å ta to nåværende eksempler, forventes datamaskinmoderniseringsarbeidet ved Us Department Of Veterans Affairs å løpe $ 3.5 milliarder, mens automatisering av helsepostene til STORBRITANNIAS Nasjonale Helsetjeneste sannsynligvis vil koste mer enn $ 14.3 milliarder for utvikling og en annen $50.8 milliarder for distribusjon.
slike megasoftware prosjekter, en gang sjeldne, er nå mye mer vanlig, som mindre IT-operasjoner er koblet inn i «systemer av systemer.»Flytrafikkontroll er et godt eksempel, fordi det er avhengig av forbindelser mellom dusinvis av nettverk som gir kommunikasjon, vær, navigasjon og andre data. Men integrasjonens knep har stymied mange EN IT-utvikler, til det punktet hvor akademiske forskere i økende grad tror at datavitenskap selv må bli omtalt i lys av disse massivt komplekse systemene.
når et prosjekt mislykkes , truer det en organisasjons prospekter. Hvis feilen er stor nok, kan den stjele selskapets hele fremtid. I en fantastisk meltdown ledet Et dårlig implementert ressursplanleggingssystem FoxMeyer Drug Co. en $ 5 milliarder engros narkotika distribusjon selskap I Carrollton, Texas, å stuper inn konkurs i 1996.
det svikt i regjeringen kan sette nasjonal sikkerhet, SOM FBIS Virtuelle Sak fil fiaskoen har vist. VCF-systemet på 170 millioner DOLLAR, en søkbar database som var ment å tillate agenter å «koble prikkene» og følge opp ulike intelligensstykker, endte i stedet for fem måneder siden uten at noe system ble distribuert .
IT-feil kan også stunt økonomisk vekst og livskvalitet. Tilbake i 1981 begynte Us Federal Aviation Administration å se på å oppgradere sitt antikke flytrafikkstyringssystem, men innsatsen for å bygge en erstatning ble snart riddled med problemer . I 1994, da byrået endelig ga opp prosjektet, hadde den forventede kostnaden tredoblet seg, mer enn 2,6 milliarder dollar hadde blitt brukt, og forventet leveringsdato hadde gått ned med flere år. Hver flypassasjer som er forsinket på grunn av gridlocked skyways føler fortsatt denne avbestillingen; den kumulative økonomiske effekten av alle disse forsinkelsene på BARE DE AMERIKANSKE flyselskapene (ikke tankene passasjerene) nærmer seg $ 50 milliarder.
På Verdensbasis er det vanskelig å si hvor mange programvareprosjekter som feiler eller hvor mye penger som blir kastet bort som et resultat. Hvis du definerer feil som total oppgivelse av et prosjekt før eller kort tid etter at det er levert, og hvis du godtar en konservativ feilfrekvens på 5 prosent, blir milliarder dollar bortkastet hvert år på dårlig programvare.
FOR eksempel, I 2004, USA regjeringen brukte 60 milliarder dollar på programvare (ikke medregnet den innebygde programvaren i våpensystemer); en feilfrekvens på 5 prosent betyr at 3 milliarder dollar sannsynligvis var bortkastet. Men etter flere tiår SOM IT-konsulent er jeg overbevist om at feilfrekvensen er 15 til 20 prosent for prosjekter som har budsjetter på $10 millioner eller mer. Når jeg ser på den totale investeringen i nye programvareprosjekter – både myndigheter og bedrifter-de siste fem årene, anslår jeg at prosjektfeil sannsynligvis har kostet DEN AMERIKANSKE økonomien minst 25 milliarder dollar og kanskje så mye som 75 milliarder dollar.
selvfølgelig reflekterer ikke 75 milliarder dollar prosjekter som overstiger budsjettene deres-som de fleste prosjekter gjør. Det gjenspeiler heller ikke prosjekter levert sent—som flertallet er. Det unnlater også å ta hensyn til mulighetskostnadene ved å måtte starte på nytt når et prosjekt er forlatt eller kostnadene ved bug-ridd systemer som må gjentatte ganger omarbeides.
da er det også kostnaden for rettssaker fra rasende kunder som saksøker leverandører for dårlig implementerte systemer. Når du legger opp alle disse ekstra kostnadene, går den årlige fanen for mislykket og urolig programvare konservativt et sted fra $ 60 milliarder til $ 70 milliarder i Usa alene. For de pengene kan du starte romfergen 100 ganger, bygge og distribuere hele 24-satellitt Global Positioning System, og utvikle Boeing 777 fra bunnen av-og fortsatt ha noen milliarder igjen.
hvorfor mislykkes prosjekter så ofte?
Blant de vanligste faktorene:
- Urealistiske eller uartikulerte prosjektmål
- Unøyaktige estimater av nødvendige ressurser
- Dårlig definerte systemkrav
- Dårlig rapportering av prosjektets status
- Ustyrte risikoer
- Dårlig kommunikasjon mellom kunder, utviklere og brukere
- bruk av umoden teknologi
- manglende evne til å håndtere prosjektets kompleksitet
- slurvete Utviklingspraksis
- dårlig prosjektledelse
- interessentpolitikk
- kommersielt press
selvfølgelig prosjekterer It Sjelden mislykkes for bare en eller to grunner. FBIS VCF-prosjekt led av mange av problemene nevnt ovenfor. De fleste feil kan faktisk spores til en kombinasjon av tekniske, prosjektledelse og forretningsbeslutninger. Hver dimensjon samhandler med de andre på kompliserte måter som forverrer prosjektrisiko og problemer og øker sannsynligheten for feil.
Vurdere en enkel programvare ork: et innkjøpssystem som automatiserer bestilling, fakturering og frakt av deler, slik at en selger kan legge inn en kundes bestilling, få den automatisk kontrollert mot priser og kontraktskrav, og sørge for at delene og fakturaen sendes til kunden fra lageret.
kravene til systemet angir fire grunnleggende trinn. Først er det salgsprosessen, som skaper en regning for salg. Denne regningen sendes deretter gjennom en juridisk prosess, som gjennomgår kontraktsbetingelsene for det potensielle salget og godkjenner dem. Tredje på linje er avsetningsprosessen, som sender ut delene som er kontrahert for, etterfulgt av finansprosessen, som sender ut en faktura.
La oss si at som den første prosessen, for salg, blir skrevet, behandler programmererne hver ordre som om den ble plassert i selskapets hovedsted, selv om selskapet har grener i flere stater og land. Den feilen påvirker i sin tur hvordan skatt beregnes, hva slags kontrakt utstedes, og så videre.
jo før utelatelsen oppdages og korrigeres, jo bedre. Det er som å strikke en genser. Hvis du ser en savnet maske rett etter at du har gjort det, kan du bare unravel litt garn og gå videre. Men hvis du ikke fanger feilen til slutten, må du kanskje unravel hele genseren bare for å gjenta den ene sømmen.
hvis programvarekoderne ikke fanger deres utelatelse før endelig systemtesting—eller verre, før etter at systemet har blitt rullet ut—vil kostnadene for å rette feilen trolig være mange ganger større enn om de hadde fanget feilen mens de fortsatt jobbet med den første salgsprosessen.
og i motsetning til en savnet søm i en genser, er dette problemet mye vanskeligere å finne ut; programmererne vil bare se at feil vises, og disse kan ha flere årsaker. Selv etter at den opprinnelige feilen er korrigert, må de endre andre beregninger og dokumentasjon og deretter teste hvert trinn på nytt.
faktisk har studier vist at programvarespesialister bruker omtrent 40 til 50 prosent av tiden sin på unødvendig omarbeid i stedet for på det de kaller verdiøkende arbeid, som i utgangspunktet er arbeid som er gjort riktig første gang. Når et stykke programvare gjør det i feltet, kan kostnaden for å fikse en feil være 100 ganger så høy som det ville ha vært i utviklingsstadiet.
hvis feil florerer, så omarbeiding kan begynne å sump et prosjekt, som en jolle i en storm. Hva er verre, forsøk på å fikse en feil ofte introdusere nye. Det er som om du øser ut den jollen, men du lager også lekkasjer. Hvis for mange feil blir produsert, blir kostnaden og tiden som trengs for å fullføre systemet så stor at det ikke er fornuftig å fortsette.
i de enkleste vilkårene mislykkes ET IT-prosjekt vanligvis når omarbeidet overstiger det verdiskapende arbeidet som er budsjettert for. Dette er hva som skjedde Med Sydney Water Corp., Den største vannleverandøren I Australia, da Den forsøkte å introdusere et automatisert kundeinformasjon og faktureringssystem i 2002 . Ifølge En undersøkelse Fra Den Australske Riksrevisjonen var blant faktorene som dømte prosjektet utilstrekkelig planlegging og spesifikasjoner, noe som igjen førte til mange endringsforespørsler og betydelige tilleggskostnader og forsinkelser. Sydney Water avbrutt prosjektet midway, etter å ha brukt AU $ 61 millioner (US $33.2 millioner).
som alle fører oss til det åpenbare spørsmålet: hvorfor oppstår så mange feil?
programvareprosjektfeil har mye til felles med flyulykker. Akkurat som piloter aldri har tenkt å krasje, har programvareutviklere ikke som mål å mislykkes. Når et kommersielt fly krasjer, ser etterforskerne på mange faktorer, for eksempel været, vedlikeholdsposter, pilotens disposisjon og opplæring og kulturelle faktorer i flyselskapet. På samme måte må vi se på forretningsmiljø, teknisk ledelse, prosjektledelse og organisasjonskultur for å komme til røttene av programvarefeil.
Hoved blant forretningsfaktorene er konkurranse og behovet for å kutte kostnader. I økende grad forventer toppledere AT IT-avdelinger skal gjøre mer med mindre og gjøre det raskere enn før; de ser programvareprosjekter ikke som investeringer, men som rene kostnader som må kontrolleres.
Politiske krav kan også skape kaos på ET IT-prosjekts tidsplan, kostnad og kvalitet. Da Denver International Airport forsøkte å rulle ut sitt automatiserte bagasjehåndteringssystem, holdt statlige og lokale politiske ledere prosjektet til en urealistisk tidsplan etter hverandre. Mangelen på å levere systemet i tide forsinket åpningen av flyplassen i 1995 (da den største I Usa), noe som forsterket den økonomiske effekten mange ganger.
Selv etter at systemet var fullført, fungerte det aldri pålitelig: det tygget opp bagasjen, og vognene pleide å transportere bagasjen rundt ofte sporet. Til slutt saksøkte United Airlines, flyplassens hovedleier, systementreprenøren, og episoden ble et testament til farene ved politisk hensiktsmessighet.
mangel på støtte fra øverste ledelse kan også fordømme ET IT-foretak. Dette går spekteret fra å ikke tildele nok penger og arbeidskraft til ikke klart å etablere IT-prosjektets forhold til organisasjonens virksomhet. I 2000, forhandler Kmart Corp, I Troy, Mich., lansert en $1.4 milliarder IT-moderniseringsinnsats rettet mot å knytte sine salgs -, markedsførings -, forsynings-og logistikksystemer, for bedre å konkurrere med rival Wal-Mart Corp., I Bentonville, Ark. Wal-Mart viste seg å være for formidabel, og 18 måneder senere kuttet kmart med kontanter På modernisering, og avskrev $130 millioner den allerede hadde investert i den. Fire måneder senere, det erklært konkurs; selskapet fortsetter å slite i dag.
OFTE, IT-prosjektledere ivrige etter å få finansiert ty til en form for liar ‘ s poker, overpromising hva deres prosjekt vil gjøre, hvor mye det vil koste, og når det vil bli fullført. Mange, om ikke de fleste, programvareprosjekter starter med budsjetter som er for små. Når det skjer, må utviklerne gjøre opp for mangelen på en eller annen måte, vanligvis ved å prøve å øke produktiviteten, redusere omfanget av innsatsen, eller ta risikable snarveier i gjennomgangs-og testfasene. Disse øker alle sannsynligheten for feil og til slutt feil.
et toppmoderne reisebestillingssystem ledet av Et konsortium Av Budget Rent-A-Car, Hilton Hotels, Marriott og Amr, morselskapet Til American Airlines, er et tilfelle. I 1992, tre og et halvt år og $165 millioner i prosjektet, forlot gruppen det, og citerte to hovedårsaker: en altfor optimistisk utviklingsplan og en undervurdering av de tekniske vanskelighetene som er involvert. Dette var den samme gruppen som tidligere hadde bygget det svært vellykkede Sabre reservasjonssystem, beviser at tidligere resultater er ingen garanti for fremtidige resultater.
etter krasj etterforskere vurdere været som en faktor i en flyulykke, de ser på selve flyet. Var det noe i flyets design som forårsaket ulykken? Bærer den for mye vekt?
i IT-prosjektfeil kommer lignende spørsmål alltid opp om prosjektets tekniske komponenter: maskinvaren og programvaren som brukes til å utvikle systemet og utviklingspraksis selv. Organisasjoner blir ofte forført av sirenens sang av det teknologiske imperativet – den ukontrollable trangen til å bruke den nyeste teknologien i håp om å få et konkurransefortrinn. Med teknologi som endrer seg raskt og lovende fantastiske nye evner, er det lett å bukke under. Men bruk av umoden eller uprøvd teknologi er en sikker rute til feil.
i 1997, etter å ha brukt 40 millioner dollar, stengte Staten Washington NED ET IT-prosjekt som ville ha behandlet førerkort og kjøretøyregistreringer. Motorkjøretøy tjenestemenn innrømmet at de ble fanget opp i jage teknologi i stedet for å konsentrere seg om å implementere et system som møtte deres krav. IT-fiaskoen som brakte Ned FoxMeyer-Stoffet et år tidligere, stammer også fra å vedta et toppmoderne ressursplanleggingssystem og deretter skyve det utover hva det kunne gjøre.
et prosjekts rene størrelse er et fountainhead av feil. Studier indikerer at store prosjekter mislykkes tre til fem ganger oftere enn små. Jo større prosjektet er, jo mer kompleksitet er det i både dets statiske elementer (de diskrete delene av programvare, maskinvare og så videre) og dets dynamiske elementer (koblingene og samspillet mellom maskinvare, programvare og brukere; tilkoblinger til andre systemer; og så videre). Større kompleksitet øker muligheten for feil, fordi ingen virkelig forstår alle de samvirkende delene av hele eller har evnen til å teste dem.
Tankevekkende men sant: det er umulig å grundig teste ET IT-system av noen reell størrelse. Roger S. Pressman påpekte I sin bok Software Engineering, en av de klassiske tekstene i feltet, at » uttømmende testing presenterer visse logistiske problemer….Selv et lite 100-linjers program med noen nestede baner og en enkelt sløyfe som utfører mindre enn tjue ganger, kan kreve 10 til kraften til 14 mulige baner som skal utføres.»For å teste alle de 100 billioner banene, bemerket han, forutsatt at hver kunne evalueres på et millisekund, ville det ta 3170 år.
ALLE IT-systemer er iboende skjøre. I en stor murbygning må du fjerne hundrevis av strategisk plasserte murstein for å få en vegg til å kollapse. Men i et 100 000-linjers program tar det bare en eller to dårlige linjer for å produsere store problemer. I 1991 gikk en del av atandamp;Ts telefonnettverk ut, og etterlot 12 millioner abonnenter uten tjeneste, alt på grunn av en enkelt feilskrevet karakter i en linje med kode.
Slurvete utviklingspraksis er en rik kilde til feil, og de kan forårsake feil på ethvert STADIUM AV ET IT-prosjekt. For å hjelpe organisasjoner med å vurdere deres programvareutviklingspraksis, HAR USA Software Engineering Institute, I Pittsburgh, opprettet Capability Maturity Model, ELLER CMM. Det priser et selskaps praksis mot fem nivåer av økende modenhet. Nivå 1 betyr at organisasjonen bruker ad hoc og muligens kaotisk utviklingspraksis. Nivå 3 betyr at selskapet har preget sin praksis og nå forstår dem. Nivå 5 betyr at organisasjonen kvantitativt forstår variasjonene i prosessene og praksisene den gjelder.
per januar hadde nesten 2000 offentlige og kommersielle organisasjoner frivillig rapportert CMM nivåer. Over halvparten erkjente å være på enten nivå 1 eller 2, 30 prosent var på nivå 3, og bare 17 prosent hadde nådd nivå 4 eller 5. Prosentene er enda mer dystre når du innser at dette er en selvvalgt gruppe; åpenbart vil selskaper med de verste IT-praksisene ikke underkaste seg EN CMM-evaluering. (CMM blir erstattet AV CMM-Integrasjon, som tar sikte på en bredere vurdering av en organisasjons evne til å lage programvareintensive systemer.)
Umoden IT-praksis dømt USA Internal Revenue Service er $ 4 milliarder modernisering innsats i 1997, og de har fortsatt å plage IRS nåværende $ 8 milliarder modernisering. Det kan bare være egentlig umulig å oversette skattekoden til programvarekode—skattelovgivningen er kompleks og basert på ofte vag lovgivning, og den endres hele tiden. FRA EN it-utviklerens synspunkt er det et krav mareritt. MEN IRS har ikke blitt hjulpet av åpen fiendtlighet mellom interne og eksterne programmerere, en latterlig undervurdering av arbeidet som er involvert, og mange andre dårlige praksiser.
PILOTENS HANDLINGER LIKE FØR et fly krasjer er alltid av stor interesse for etterforskerne. Det er fordi piloten er den ultimate beslutningstakeren, ansvarlig for sikker drift av båten. På samme måte spiller prosjektledere en avgjørende rolle i programvareprosjekter og kan være en viktig kilde til feil som fører til feil.
Tilbake i 1986 besluttet London Stock Exchange å automatisere sitt system for oppgjør av aksjetransaksjoner. Syv år senere, etter å ha brukt $600 millioner, slettet Det Taurus-systemets utvikling, ikke bare fordi designet var for komplisert og tungvint, men også fordi ledelsen av prosjektet var, for å bruke ordet til en av sine egne toppledere, «delusional.»Som undersøkelser viste, syntes ingen å ønske å vite prosjektets sanne status, selv om flere og flere problemer dukket opp, tidsfrister ble savnet, og kostnadene økte .
IT-prosjektlederens viktigste funksjon er å tildele ressurser til ulike aktiviteter. Utover det er prosjektlederen ansvarlig for prosjektplanlegging og estimering, kontroll, organisering, kontraktstyring, kvalitetsstyring, risikostyring, kommunikasjon og human resource management.
Dårlige beslutninger av prosjektledere er trolig den største årsaken til programvarefeil i dag. Dårlig teknisk ledelse kan derimot føre til tekniske feil, men de kan generelt isoleres og løses. En dårlig prosjektledelsesbeslutning—for eksempel å ansette for få programmerere eller velge feil type kontrakt—kan imidlertid forårsake ødeleggelse. For eksempel hevder utviklerne av det dømte reisebestillingssystemet at de ble hobbled delvis ved bruk av en fastpriskontrakt. En slik kontrakt forutsetter at arbeidet vil være rutine; reservasjonssystemet viste seg å være alt annet enn.
Prosjektledelsesbeslutninger er ofte vanskelige nettopp fordi De involverer avveininger basert på uklar eller ufullstendig kunnskap. Estimere hvor mye ET IT-prosjekt vil koste og hvor lang tid det vil ta er så mye kunst som vitenskap. Jo større eller flere nye prosjektet, jo mindre nøyaktige estimatene. Det er en løpende vits i bransjen AT IT-prosjektestimater i beste fall er innen 25 prosent av sin sanne verdi 75 prosent av tiden.
det finnes andre måter som dårlig prosjektledelse kan fremskynde et programvareprosjekts død. En studie av Project Management Institute, I Newton Square, Pa., viste at risikostyring er minst praktisert av alle prosjektledelsesdisipliner på tvers av alle industrisektorer, og ingen steder er det sjeldnere brukt enn I IT-bransjen. Uten effektiv risikostyring har programvareutviklere lite innsikt i hva som kan gå galt, hvorfor det kan gå galt, og hva som kan gjøres for å eliminere eller redusere risikoen. Det er heller ingen måte å avgjøre hvilke risikoer som er akseptable, noe som igjen gjør prosjektbeslutninger om avvik nesten umulige.
Dårlig prosjektledelse tar mange andre former, inkludert dårlig kommunikasjon, noe som skaper en ugjestmild atmosfære som øker omsetningen; ikke investere i personalopplæring; og ikke gjennomgå prosjektets fremgang med jevne mellomrom. Noen av disse kan bidra til å spore et programvareprosjekt.
det siste området som etterforskere ser på etter en flyulykke er organisasjonsmiljøet. Har flyselskapet en sterk sikkerhetskultur, eller legger det vekt på å møte flyplanen fremfor alt? I IT-prosjekter er en organisasjon som verdsetter åpenhet, ærlighet, kommunikasjon og samarbeid mer tilbøyelig til å finne og løse feil tidlig nok til at omarbeiding ikke blir overveldende.
hvis det er et tema som går gjennom den torturerte historien om dårlig programvare, er det en feil å konfrontere virkeligheten. Ved flere anledninger fortalte det amerikanske Justisdepartementets generalinspektør, et eksternt panel av eksperter og andre til fbis leder at VCF-systemet var umulig som definert, og likevel fortsatte prosjektet uansett. De samme holdningene eksisterte blant de som var ansvarlige for reisebestillingssystemet, London-Børsens Taurus-system og FAAS flytrafikkkontrollprosjekt-alt tyder på organisasjonskulturer drevet av frykt og arroganse.
En fersk rapport fra National Audit Office I STORBRITANNIA fant mange tilfeller av regjeringen IT-prosjekter ‘ blir anbefalt å ikke gå fremover, men fortsetter likevel. STORBRITANNIA har til og med en regjeringsavdeling som er ansvarlig for å forhindre IT-feil, men som rapporten bemerket, ignorerer mer enn halvparten av byråene avdelingen overvåker rutinemessig sitt råd. Jeg kaller denne typen atferd irrasjonell prosjekteskalering-manglende evne til å stoppe et prosjekt selv etter at det er åpenbart at sannsynligheten for suksess raskt nærmer seg null. Dessverre er slik oppførsel på ingen måte unik.
i den endelige analysen har store programvarefeil en tendens til å ligne den verste tenkelige flyulykken , hvor piloten var uerfaren, men overmåte utslett, fløy inn i en isstorm i et uprøvd fly, og jobbet for et flyselskap som ga leppe service til sikkerhet mens de kuttet ned på trening og vedlikehold. Hvis du leser etterforskerens rapport etterpå, vil du riste på hodet og spørre: «Var ikke et slikt krasj uunngåelig?»
så også årsakene til at programvareprosjekter mislykkes er velkjente og har blitt rikelig dokumentert i utallige artikler, rapporter og bøker . Og likevel fortsetter feil, nesten feil og vanlig gammel dårlig programvare å plage oss, mens praksis som er kjent for å avverge feil, blir skjult. Det ser ut til at å få kvalitetsprogramvare i tide og innenfor budsjett ikke er en presserende prioritet hos de fleste organisasjoner.
Det syntes ikke å være På Oxford Health Plans Inc., I Trumbull, Conn., i 1997. Selskapets automatiserte faktureringssystem var avgjørende for bunnlinjen, og likevel var toppledere mer interessert i å utvide Oxfords virksomhet enn å sikre at faktureringssystemet kunne møte dagens behov . Selv da problemer oppstod, som fakturaer ble sendt ut måneder sent, betalte ledere liten oppmerksomhet. Da faktureringssystemet effektivt kollapset, mistet selskapet titalls millioner dollar, og aksjen falt fra $ 68 til $26 per aksje på en dag, og slettet ut $ 3.4 milliarder i bedriftsverdi. Aksjonærer brakte søksmål, og flere myndigheter undersøkte selskapet, som til slutt ble bøtelagt $ 3 millioner for regulatoriske brudd.
selv organisasjoner som blir brent av dårlige programvareopplevelser virker ute av stand til eller uvillige til å lære av sine feil. I en rapport fra 2000 bemerket US Defense Science Board, et rådgivende organ Til Forsvarsdepartementet, at ulike studier bestilt av DOD hadde gjort 134 anbefalinger for å forbedre programvareutviklingen, men bare 21 av disse anbefalingene hadde blitt handlet på. De andre 113 var fortsatt gyldige, bemerket styret, men ble ignorert, selv om DOD klaget over den dårlige forsvarsprogramvareutviklingen!
noen organisasjoner bryr seg om programvarekvalitet, som erfaringen fra programvareutviklingsfirmaet Praxis High Integrity Systems, I Bath, England, viser. Praxis krever at kundene forplikter seg til prosjektet, ikke bare økonomisk, men som aktive deltakere i it-systemets opprettelse. Selskapet bruker også en enorm mengde tid på å forstå og definere kundens krav, og det utfordrer kundene til å forklare hva de vil og hvorfor. Før en enkelt linje med kode er skrevet, er både kunden og Praksis enige om hva som er ønsket, hva som er mulig, og hvilke risikoer som er involvert, gitt de tilgjengelige ressursene.
Deretter bruker Praxis en streng utviklingstilnærming som begrenser antall feil. En av de store fordelene med denne modellen er at den filtrerer ut de mange potensielle kundene som ikke er villige til å akseptere ansvaret for å artikulere SINE IT-krav og bruke tid og penger til å implementere dem riktig.
Noe nivå av programvarefeil vil alltid være med oss. Faktisk trenger vi sanne feil-i motsetning til unødvendige blunders – for å fortsette å gjøre tekniske og økonomiske fremskritt. Men for mange av feilene som oppstår i dag, kan unngås. Og ettersom vårt samfunn kommer til å stole PÅ IT-systemer som er stadig større, mer integrerte og dyrere, kan kostnadene ved feil bli katastrofalt høye.
selv nå er det mulig å ta spill på hvor neste store programvarefeil vil oppstå. EN av mine ledende kandidater er IT-systemene SOM kommer fra DEN AMERIKANSKE Regjeringens American Health Information Community, et offentlig-privat samarbeid som søker å definere datastandarder for elektroniske medisinske journaler. Tanken er at når standarder er definert, VIL IT-systemer bli bygget for å la medisinske fagfolk over hele landet legge inn pasientjournaler digitalt, noe som gir leger, sykehus, forsikringsselskaper og andre helsepersonell umiddelbar tilgang til pasientens komplette medisinske historie. Helseeksperter mener at et slikt system av systemer vil forbedre pasientomsorgen, kutte kostnadene med anslagsvis 78 milliarder dollar per år, og redusere medisinske feil, og spare titusenvis av liv.
men denne tilnærmingen er bare en rørdrøm hvis programvarepraksis og feilfrekvenser forblir som de er i dag. Selv etter de mest optimistiske estimatene, for å skape et elektronisk journalsystem vil det kreve 10 års innsats, 320 milliarder dollar i utviklingskostnader og 20 milliarder dollar per år i driftskostnader-forutsatt at det ikke er feil—overskridelser, tidsplan slips, sikkerhetsproblemer eller skummel programvare. Dette er neppe et realistisk scenario, særlig fordi DE FLESTE IT-eksperter anser det medisinske samfunnet å være den minst datakyndige av alle profesjonelle bedrifter.
Pasienter og skattebetalere vil til slutt betale prisen for utviklingen, eller feilen, av boondoggles som dette. Gitt DAGENS IT-praksis, er feil en tydelig mulighet, og det ville være et tap av enestående størrelse. Men så vurderer land over hele verden eller allerede på jobb med mange tiltak av tilsvarende størrelse og innvirkning—blant annet innen luftfart, nasjonal sikkerhet og militæret.
som elektrisitet, vann, transport og andre kritiske deler av vår infrastruktur, blir det raskt iboende for vår daglige eksistens. OM noen tiår vil en STOR IT-feil bli mer enn bare en dyr uleilighet: det vil sette vår livsstil i fare. I mangel av den typen industrielle endringer som vil redusere programvarefeil, hvor mye av vår fremtid er vi villige til å gamble på disse enormt kostbare og komplekse systemene?
vi vet allerede hvordan du gjør programvare godt. Det kan endelig være på tide å handle på det vi vet.