Njohjet dhe kostoja e mos testimit të BI -së tuaj

by Dhjetor 4, 2014Analizat e Cognos, MotioCI, Testimkomentet 0

Përditësuar më Gusht 28, 2019

Testimi është miratuar gjerësisht si pjesë e zhvillimit të softuerit që kur është zhvilluar softueri. Inteligjenca e Biznesit (BI) megjithatë, ka qenë më e ngadaltë për të miratuar testimin si një pjesë e integruar e zhvillimit në softuer BI si IBM Cognos. Le të shqyrtojmë pse BI ka qenë më e ngadaltë për të miratuar praktikat e testimit dhe pasojat e NUK testimi.

Pse organizatat nuk testojnë BI…

  • Kufizimet kohoreMe Projektet BI janë nën presion të vazhdueshëm që të dorëzohen më shpejt. Ajo që disa organizata mund të mos e kuptojnë është se faza më e lehtë për të zvogëluar kohën është testimi.
  • Kufizimet e buxhetitMe Mendimi është se testimi është shumë i shtrenjtë dhe nuk mund t'i kushtohet një ekipi testimi.
  • Më shpejt është më mirëMe Kjo nuk është domosdoshmërisht një qasje "e shkathët" dhe mund t'ju çojë më shpejt në vendin e gabuar.

Fashë-Citim

  • Mendësia "thjesht bëje atë herën e parë"Me Kjo qasje naive këmbëngul se prania e kontrollit të cilësisë duhet të zvogëlojë nevojën për testim.
  • Mungesa e pronësisëMe Kjo është e ngjashme me plumbin e mëparshëm. Mendimi është se "përdoruesit tanë do ta testojnë atë". Kjo qasje mund të çojë në përdorues të pakënaqur dhe shumë bileta mbështetëse.
  • Mungesa e mjeteveMe Koncepti i gabuar se ata nuk kanë teknologjinë e duhur për testim.
  • Mungesa e të kuptuarit të testimitMe Për shembull,
    • Testimi duhet të vlerësojë saktësinë dhe vlefshmërinë e të dhënave, konsistencën e të dhënave, afatin kohor të të dhënave, performancën e shpërndarjes dhe lehtësinë e përdorimit të mekanizmit të shpërndarjes.
    • Testimi gjatë një projekti BI mund të përfshijë testimin e regresionit, testimin e njësisë, testimin e tymit, testimin e integrimit, testimin e pranimit të përdoruesit, testimin ad hoc, testimin e stresit/shkallëzueshmërisë, testimin e performancës së sistemit.

Cilat janë kostot e MOS Testimit të BI?

  • Hartime joefikaseMe Arkitektura e dobët mund të mos zbulohet nëse testimi shpërfillet. Çështjet e projektimit mund të kontribuojnë në përdorshmërinë, performancën, ripërdorimin, si dhe mirëmbajtjen dhe mirëmbajtjen.
  • Çështjet e integritetit të të dhënaveMe Korrupsioni i të dhënave ose sfidat e prejardhjes së të dhënave mund të çojnë në mungesë besimi në numrat.
  • Çështjet e vërtetimit të të dhënaveMe Vendimet e marra për të dhëna të këqija mund të jenë shkatërruese për biznesin. Nuk ka asgjë më të keqe sesa të përpiqesh të menaxhosh me metrikë që bazohen në informacione të pasakta.

Karikaturë Dilbert- të dhënat janë të gabuara

  • Zvogëlimi i adoptimit të përdoruesitMe Nëse numrat nuk janë të duhur, ose nëse aplikacioni nuk është miqësor për përdoruesit, komuniteti juaj i përdoruesve thjesht nuk do të përdorë softuerin tuaj të ri me shkëlqim BI të ndërmarrjes.
  • Rritja e kostove për shkak të mungesës së standardizimit.
  • Rritja e kostove për të riparuar defektet në fazat e mëvonshme të ciklit të jetës së zhvillimit të BIMe Çdo çështje e zbuluar përtej fazës së kërkesave do të kushtojë në mënyrë eksponenciale më shumë sesa nëse zbulohet më herët.

Tani që kemi parashtruar arsyen pse organizatat nuk mund të testojnë dhe kurthet që ndodhin kur ju nuk testoni BI, le të shikojmë disa studime mbi testimin në zhvillimin e softuerit.

Studimet tregojnë se testimi i platformës tuaj BI kursen para!

Një studim i 139 kompanive të Amerikës së Veriut duke filluar nga madhësia nga 250 në 10,000 punonjës, raportuan kosto vjetore të korrigjimit prej 5.2 milion dollarë në 22 milion dollarë. Ky varg i kostos reflekton organizatat që mos kanë testimin e njësive të automatizuara në vend. Më vete, hulumtimet nga IBM dhe Microsoft zbuluan se me testimi i njësisë së automatizuar në vend, numri i defekteve mund të zvogëlohet midis 62% dhe 91%Me Kjo do të thotë që dollarët e shpenzuar për korrigjimin e gabimeve mund të zvogëlohen nga 5 deri në 22 milionë dollarë në intervalin 0.5 milionë dollarë në 8.4 milionë dollarë. Ky është një kursim i madh!

Korrigjimi i kostove pa testim dhe me testim

Shpenzimet për të rregulluar gabimet të përshkallëzohen shpejt.

Një punim mbi taktikat e suksesshme të zhvillimit të softuerit demonstron se shumica e gabimeve bëhen në fillim të ciklit të zhvillimit dhe se sa më gjatë të prisni për të zbuluar dhe korrigjuar, aq më i lartë ju kushton për të rregulluar. Pra, nuk i duhet një shkencëtari të raketave të nxjerrë përfundimin e qartë se sa më shpejt të zbulohen dhe rregullohen gabimet, aq më mirë. Duke folur për shkencën e raketave, ndodh që NASA publikoi një punim pikërisht për këtë - "Shkallëzimi i kostos së gabimit përmes ciklit të jetës së projektit."

Intshtë intuitive që kostot për të rregulluar gabimet të rriten me zhvillimin e ciklit të jetës. Studimi i NASA -s u krye për të përcaktuar se sa shpejt përparon kostoja relative e rregullimit të gabimeve të zbuluara. Ky studim përdori tre qasje për të përcaktuar kostot relative: metodën e kostos nga poshtë-lart, metodën e ndarjes së kostos totale dhe metodën e projektit hipotetik nga lart-poshtë. Qasjet dhe rezultatet e përshkruara në këtë punim supozojnë zhvillimin e një sistemi harduer/softuer që ka karakteristika të projektit të ngjashme me ato të përdorura në zhvillimin e një anije kozmike të madhe, komplekse, një avioni ushtarak ose një sateliti të vogël komunikimi. Rezultatet tregojnë shkallën në të cilën kostot rriten, pasi gabimet zbulohen dhe fiksohen në fazat e mëvonshme dhe të mëvonshme të ciklit të jetës së projektit. Ky studim është përfaqësues i hulumtimeve të tjera të bëra.

SDLC Kostoja për të rregulluar shkallën e gabimeve

Nga grafiku i mësipërm, hulumtimet nga TRW, IBM, GTE, Bell Labs, TDC dhe të tjera tregojnë koston e rregullimit të gabimeve gjatë fazave të ndryshme të zhvillimit:

  • Kostoja e rregullimit të një gabimi të zbuluar gjatë fazës së kërkesave përcaktohet si Njësia 1
  • Kostoja për të rregulluar atë gabim nëse gjendet gjatë fazës së projektimit është dyfishtë Që
  • Në fazën e kodimit dhe debugimit, kostoja për të rregulluar gabimin është njësitë 3
  • Në fazën e testimit të njësisë dhe integrimit, kostoja për të rregulluar gabimin bëhet 5
  • Në fazën e fazës së testimit të sistemeve, kostoja për të rregulluar gabimin hidhet në 20
  • Dhe sapo sistemi të jetë në fazën e funksionimit, kostoja relative për të korrigjuar gabimin është rritur në 98, gati 100 herë më shumë se kostoja e korrigjimit të gabimit nëse gjendet në fazën e kërkesave!

Përfundimi është se është shumë më e kushtueshme për të riparuar defektet nëse ato nuk kapen herët.

Konkluzione

Janë kryer kërkime të rëndësishme të cilat demonstrojnë vlerën e testimit të hershëm dhe të vazhdueshëm në zhvillimin e softuerit. Ne, në komunitetin BI, mund të mësojmë nga miqtë tanë në zhvillimin e softuerit. Edhe pse shumica e kërkimeve zyrtare janë bërë në lidhje me zhvillimin e softuerit, përfundime të ngjashme mund të nxirren në lidhje me zhvillimin e BI. Vlera e testimit është e padiskutueshme, por shumë organizata kanë qenë më të ngadalta për të përfituar nga testimi formal i mjedisit të tyre BI dhe për të integruar testimin në proceset e tyre të zhvillimit të BI. Kostot e nuk testimi është i vërtetë. Rreziqet që lidhen me nuk testimi është i vërtetë.

Dëshironi të shihni disa testime të automatizuara të Cognos në veprim? Shikoni videot në listën tonë të luajtjes nga klikuar këtu!

Analizat e CognosPërmirësimi i Cognos
3 hapa për një përmirësim të suksesshëm të Cognos
Tre hapa për një përmirësim të suksesshëm të IBM Cognos

Tre hapa për një përmirësim të suksesshëm të IBM Cognos

Tre hapa drejt një përmirësimi të suksesshëm të IBM Cognos Këshilla të paçmueshme për ekzekutivin që menaxhon një përmirësim Kohët e fundit, menduam se kuzhina jonë kishte nevojë për përditësim. Fillimisht punësuam një arkitekt për të hartuar planet. Me një plan në dorë, diskutuam specifikat: Cili është qëllimi?...

Lexo më shumë

MotioCI
MotioCI Këshilla dhe truket
MotioCI Këshilla dhe truket

MotioCI Këshilla dhe truket

MotioCI Këshilla dhe truket Tiparet e preferuara të atyre që ju sjellin MotioCI Ne e pyetëm Motiozhvilluesit, inxhinierët e softuerit, specialistët e mbështetjes, ekipi i zbatimit, testuesit e cilësisë së cilësisë, shitjet dhe menaxhmenti cilat janë tiparet e tyre të preferuara të MotioCI janë. Ne i kemi kërkuar që të...

Lexo më shumë