Opgedateer Augustus 28, 2019
Sedert sagteware ontwikkel is, is toetsing wyd aanvaar as deel van sagteware -ontwikkeling. Business Intelligence (BI) was egter stadiger om toetse aan te neem as 'n geïntegreerde deel van die ontwikkeling in BI -sagteware soos IBM Cognos. Kom ons ondersoek waarom BI stadiger was om toetspraktyke aan te neem en die gevolge daarvan NIE toets.
Waarom organisasies nie BI toets nie ...
- Tydsbeperkings. BI -projekte is onder konstante druk om vinniger afgelewer te word. Sommige organisasies besef miskien nie dat toetsing die maklikste fase is om tyd te verminder nie.
- Begrotingsbeperkings. Die gedagte is dat toetsing te duur is en nie 'n toetsspan kan toewy nie.
- Vinniger is beter. Dit is nie noodwendig 'n 'rats' benadering nie en kan u slegs vinniger op die verkeerde plek bring.
- Die "doen dit net die eerste keer reg" mentaliteit. Hierdie naïewe benadering dring daarop aan dat die teenwoordigheid van kwaliteitskontrole die behoefte aan toetsing moet verminder.
- Gebrek aan eienaarskap. Dit is soortgelyk aan die vorige koeël. Die gedagte is dat 'ons gebruikers dit sal toets'. Hierdie benadering kan lei tot ongelukkige gebruikers en baie ondersteuningskaartjies.
- Gebrek aan gereedskap. Die wanopvatting dat hulle nie die regte tegnologie het om te toets nie.
- Gebrek aan begrip vir toetsing. Byvoorbeeld,
- Die toetsing moet die akkuraatheid en geldigheid van data, die konsekwentheid van die data, die tydigheid van die data, die prestasie van die aflewering en die gemak van gebruik van die afleweringsmeganisme evalueer.
- Toets tydens 'n BI -projek kan regressietoetsing, eenheidstoetsing, rooktoetsing, integrasietoetsing, toetsing van gebruikersaanvaarding, ad hoc -toetsing, stres-/skaalbaarheidstoetsing, toetsing van stelselprestasie insluit.
Wat is die koste om NIE BI te toets nie?
- Ondoeltreffende ontwerpe. Swak argitektuur word moontlik nie ontdek as toetsing geïgnoreer word nie. Ontwerpkwessies kan bydra tot bruikbaarheid, prestasie, hergebruik, sowel as onderhoud en onderhoud.
- Data integriteit kwessies. Datakorrupsie of uitdagings met data -afkoms kan lei tot 'n gebrek aan vertroue in die getalle.
- Data validering kwessies. Besluite wat oor slegte data geneem word, kan die onderneming vernietigend wees. Daar is niks erger as om te probeer bestuur deur statistieke wat op verkeerde inligting gebaseer is nie.
- Verminderde gebruikersaanneming. As die getalle nie korrek is nie, of as die toepassing nie gebruikersvriendelik is nie, gebruik u gebruikersgemeenskap net nie u blink nuwe onderneming-BI-sagteware nie.
- Verhoogde koste as gevolg van gebrek aan standaardisering.
- Verhoogde koste om defekte te herstel in latere stadiums van die lewensiklus van die BI -ontwikkeling. Enige probleme wat buite die vereistesfase ontdek word, kos eksponensieel meer as vroeër ontdek.
Noudat ons uiteengesit het waarom organisasies moontlik nie toets nie en die slaggate wat voorkom as u nie BI toets nie, kyk ons na 'n paar studies oor toetsing in sagteware -ontwikkeling.
Studies toon dat die toets van u BI -platform geld bespaar!
Een studie van 139 Noord -Amerikaanse maatskappye van 250 tot 10,000 5.2 werknemers, het jaarlikse ontfoutingskoste van $ 22 miljoen tot $ XNUMX miljoen gerapporteer. Hierdie koste reeks weerspieël organisasies wat nie outomatiese eenheidstoetsing in werking stel. Afsonderlik het navorsing deur IBM en Microsoft dit bevind met outomatiese eenheidstoetsing, kan die aantal gebreke met tussen 62% en 91% verminder word. Dit beteken dat dollars wat aan ontfouting bestee word, kan verminder word van die $ 5M - $ 22M -reeks tot die $ 0.5M tot $ 8.4M -reeks. Dit is 'n groot besparing!
Koste om foute vinnig op te los, eskaleer.
'N Referaat oor suksesvolle sagteware -ontwikkelingstaktieke toon aan dat die meeste foute vroeg in die ontwikkelingsiklus gemaak word en dat hoe langer u wag om op te spoor en reg te stel, hoe hoër kos dit u om dit reg te stel. Dit verg dus nie 'n vuurpylwetenskaplike om die duidelike gevolgtrekking te maak dat hoe gouer foute ontdek en opgelos word nie, hoe beter. As ons van vuurpylwetenskap praat, gebeur dit net so dat NASA 'n artikel oor dit gepubliseer het - "Foutkoste -styging deur die lewensiklus van die projek."
Dit is intuïtief dat die koste om foute reg te stel toeneem namate die lewensiklus van die ontwikkeling vorder. Die NASA -studie is uitgevoer om vas te stel hoe vinnig die relatiewe koste van die herstel van foute vorder. Hierdie studie het drie benaderings gebruik om die relatiewe koste te bepaal: die bottom-up-kostemetode, die totale koste-uiteensettingsmetode en die top-down-hipotetiese projekmetode. Die benaderings en resultate wat in hierdie artikel beskryf word, veronderstel die ontwikkeling van 'n hardeware-/sagteware -stelsel met projekteienskappe soortgelyk aan dié wat gebruik word vir die ontwikkeling van 'n groot, komplekse ruimtetuig, 'n militêre vliegtuig of 'n klein kommunikasiesatelliet. Die resultate toon in watter mate die koste styg, aangesien foute in latere en later fases in die lewensiklus van die projek opgespoor en opgelos word. Hierdie studie is verteenwoordigend van ander navorsing wat gedoen is.
Uit die grafiek hierbo toon navorsing van TRW, IBM, GTE, Bell Labs, TDC en ander die koste om foute reg te stel tydens die verskillende ontwikkelingsfases:
- Die koste om 'n fout op te los wat tydens die vereiste fase ontdek is, word gedefinieer as 1 eenheid
- Die koste om die fout reg te stel as dit tydens die ontwerpfase gevind word, is verdubbel Wat
- In die kode- en ontfoutingsfase is die koste om die fout reg te stel 3 eenhede
- By die eenheidstoets en die integreerfase word die koste om die fout reg te stel 5
- By die stelseltoetsfase, die koste om die fout reg te stel, styg tot 20
- En sodra die stelsel in die operasionele fase is, die relatiewe koste om die fout reg te stel, het gestyg tot 98, byna 100 keer die koste om die fout reg te stel indien dit in die vereiste fase gevind word!
Die uiteinde is dat dit baie duurder is om defekte te herstel as dit nie vroeg opgevang word nie.
Gevolgtrekkings
Daar is aansienlike navorsing gedoen wat die waarde van vroeë en deurlopende toetsing in sagteware -ontwikkeling toon. Ons, in die BI -gemeenskap, kan leer van ons vriende in sagteware -ontwikkeling. Alhoewel die meeste formele navorsing oor sagteware -ontwikkeling gedoen is, kan soortgelyke gevolgtrekkings gemaak word oor BI -ontwikkeling. Die waarde van toetsing is onbetwisbaar, maar baie organisasies was traag om voordeel te trek uit formele toetsing van hul BI -omgewing en toetsing in hul BI -ontwikkelingsprosesse te integreer. Die koste van nie toets is werklik. Die risiko's verbonde aan nie toets is werklik.
Wil u 'n paar outomatiese Cognos -toetse in aksie sien? Kyk na die video's op ons snitlys deur hier te klik!
