3. Potenciālais ugunsgrēks Neiekļaujas termiņos Kļūdas, kļūdas, kļūdas... Drošības caurumi un veiktspējas problēmas Neērti lietot Dārgi uzturēt un ieviest izmaiņas
4. Kas izraisa? Izstrādes process Caurspīdīgums Slēptas problēmas Kvalitātes mērījumi Nepilnīga dokumentācija Neapzinātas kļūdas Ilgstoša ieviešana Dārga uzturēšana Cilvēkresursu nepietiekamība Kalendārais plāns Nerealizēta funkcionalitāte Komandas sadarbība
5. Kas izraisa? (2) «Slikti definētas prasības» Izpratne Akceptēšana Projekta atcelšana Konfigurācija pārvaldība Kvalitātes regress Meklēšanas laiks Informācijas pazaudēšana
Labdien, mani sauc Rolands Bērziņš, esmu DPA vadošais testēšanas speciālists un es Jums pastāstīšu kā novērst ugunsgrēku.Īsumā ugunsgrēku var raksturot kā situāciju, kad izstrādes procesā atgadās kāda ķibele, kā lūk tas ir noticis šim te cilvēciņam.Uz jautājumiem labprāt atbildēšu prezentācijas beigās.
Vispirms iepazīsimies tuvāk ar potenciālo vai iespējams jau reālo ugunsgrēku.Pēc tam apskatīsim ugunsgrēku rašanās iemeslus, kā arī noskaidrosim kā izvairīties un novērst «Ugunsgrēku» rašanos.Prezentācijas beigās apskatīsim kādus pakalpojums piedāvā DPA, lai novērstu šādas problēmsituācijas.
Uzskaitām problēmsituācijasnav zināms kvalitātes stāvoklis; ir daudz kļūdu2) Iespējams daudziem ļoti pazīstamas situācijas, bet vai esiet padomājuši kā tās rodas?
Šeit es esmu uzskaitījis tipiskākosiemeslus, kuri nereti noved projektu «ugunsgrēka» stadijā, kādu raksturoju iepriekš.Kā pirmo gribu pieminēt necaurredzamu izstrādes procesu, kā rezultātā sistēmas izstrāde norit nekontrolējami un ne pēc labākās prakses. Droši vien vairums būs saskārušies ar dokumentācijas nepilnībām, piemēram, kad sistēma tiek ražota ātrāk kā dokumentācijā ietvertas jaunākās izmaiņas. Laika gaitā tas noved pie arvien smagākām sekām.Nereti notiek arī tā, ka izstrādes komandā fiziski nav resursu, lai veltītu laiku dokumentācijas atjaunošanai. Un ko darīt tad, ja no projekta pazudīs pēdējais programmētājs kopā ar dokumentāciju savā galvā?
Kā nākamo iemeslu gribu minēt situāciju, kad nav konkrēti definētas prasības jeb veicamie uzdevumi.Un Visbeidzot, Tehniskie risinājumi
Pirmie 2 palīdz esošajiem resursiemNākamie 2 veic pakalpojumus
Kā viens no variantiem ir pilnībā nodot sistēmas izstrādi DPA rokās.No DPA iespējams arī pasmelties idejas un ieteikumus, lai uzlabotu esošo izstrādes procesu.Un, protams, DPA veic neatkarīgo testēšanu. Par to turpinājumā.
Vispārīgi kas tad ir neatkarīgā testēšanaKo tajā dara
Kas klientiem ir būtiski saistībā ar DPA piedāvātajiem pakalpojumiem neatkarīgajā testēšanā?JebKo mēs darām un kā mēs to darām.Iepazīsimies kā norit sadarbības ,kā arī uzzināsiet ko no DPA sagaidīt un kāds no tā visa ir ieguvums.
Mūsu klienti iedalās 2 lielās grupās:programmatūras ražošanas uzņēmumos;Un uzņēmumos, kuriem ražo programmatūru.Attiecīgi, neatkarīgajā testēšanā, pirmajiem mēs palīdzam ražot un otrajiem palīdzam pieņemt.Atkarībā no projekta specifikas, tiek noteikts, vai DPA testēšanas speciālisti strādā no klienta lokācijas vai no sava biroja.Šeit gribu uzsvērt, ka komunikācijas veicināšanai, iesaku speciālistus novietot pēc iespējas tuvāk izstrādes grupai.Banku sistēmas risinājumiJa nepieciešams, tad kā minimālo konfigurācijas pārvaldību testēšanas vajadzībām, iespējams ieviest portālu, kurā glabāsies testa plāni, testpiemēri un kļūdu ziņojumi.
ko no neatkarīgās testēšanas veicDPA:Funkcionālo testu veikšanuVeiktspējas un slodzes testu veikšanuTestu automatizācijuKonfigurācijas pārvaldību un laidienu uzstādīšanuAugstas pieejamības testusSistēmas mērogojamības testus
Pirmais būtiskais ieguvums ir tas, ka tiks nodrošināta izstrādes procesa caurredzamība,tādejādi ļaujot noteikt atbilstību kalendārajam plānam un dot vispārīgu priekšstatu par projekta stāvokli.Otrkārt, regulāri tiek nodota informācija par sistēmas kvalitāti.Treškārt, neradīsies problēmas ar sistēmas ieviešanu produkcijas lietošanā.Kā pēdējo un ne mazāk svarīgu ieguvumu jāmin kvalitātes nodrošināšanu, projekta uzturēšanas periodā.