Vložki se samo povečujejo, da bi že prvič dobili pravo kakovost. Kakovost s spletnimi storitvami in SOA lahko izboljša ali uniči zmogljivost in zanesljivost sestavnih storitev, lahko celo obarva dojemanje IT na splošno.
Preberite prepis podcasta.
Nedavno programsko opremo Borland izdal svojo pobudo za upravljanje kakovosti življenjskega cikla (LQM)., ki izvaja zagotavljanje kakovosti v celotnem procesu oblikovanja aplikacij, s posebnim poudarkom na fazi zahtev.
Seveda pri kakovosti ne gre le za kodo, temveč za kakovost postopka, metodologije in pravilne opredelitve. Gre tudi za ljudi.
Zato smo Borlandov pristop h kakovosti prenesli na teren, da bi preizkusili razmišljanje v prometni trgovini za razvoj aplikacij. V tem sponzoriranem B2B informacijskem podcastu poslušajte Chrisa Meystrika, podpredsednika programskega inženiringa pri Nakit Televizija v Knoxvillu, Tenn., opisuje svoje hitro razvijajoče se okolje in kaj išče pri orodjih, testiranju in upravljanju življenjskega cikla aplikacije.
Oglejte si odlomke iz razprave:
... Naredili smo prehod na zelo agilen, ponavljajoč se razvojni proces, kjer mora biti kakovost del. Na samem začetku tega procesa, od zahtev celo pred odkritjem, imamo QA inženirji in menedžerji za zagotavljanje kakovosti, vključeni v projekt, da bi razumeli, kakšni so vplivi bo. S tem lahko podjetje že na samem začetku začnemo razmišljati o kakovosti, z našim izdelkom menedžerji in vodje projektov, ki dobijo pogled iz ptičje perspektive na to, kaj bi lahko bil načrt projekta v resničnem življenju izgleda kot. Od tam naprej je naš QA močno vpleten v agilni proces, vse do konca, merjenja kakovosti izdelka. Tako mora biti.
Potrebujemo, da nam prodajalci dobavijo izdelke, ki so odprti, izdelke, ki bodo med seboj komunicirali v vsaki fazi življenjskega cikla razvoja našega izdelka. Imamo inženirje za zahteve, produktne vodje in vodje projektov – tako v začetnih fazah projekt skupaj s projektno listino -- poskus dodelitve sredstev in nato postavljanje začetnih zahtev skupaj.
Ko inženirji to končno dobijo, se ne ukvarjajo z istim naborom orodij. Svet inženirja zahtev je svet dokumentacije in sledljivosti ter zmožnosti zagotoviti, da je vsaka zahteva, ki jo napišejo, nedvoumna in da jo je mogoče ob koncu dneva preveriti. To je na začetku njihova naloga.
Ko se to potisne v inženiring, uporabljajo svoj sistem za upravljanje izvorne kode (SCM) in njihove sisteme za sledenje napakam in težavam ter uporabljajo svoje IDE. Ne potrebujemo jih, da pridemo v druge orodja. Vsa ta orodja morajo soobstajati v enem ogrodju ALM, ki vsem tem orodjem omogoča komunikacijo.
Tako na primer v Eclipsu, ki je tukaj zelo, zelo priljubljen, dobite bežen vpogled v te zahteve izgledajo naravnost do namizja inženirjev, ne da bi morali odpreti kakšno drugo orodje, kar poznamo še nihče počne. Brez tega imate vstopno oviro, ki se ji preprosto želite izogniti. Komunikacije so težje.
Ko gre za sledljivost, želite sledljivost vse do ravni izvorne kode, od teh zahtev do Subversion, ki je orodje, ki ga uporabljamo. Vse do ustvarjanja testnih načrtov iz zahtev naši inženirji za zagotavljanje kakovosti ne uporabljajo orodja za zahteve; uporabljajo avtomatizirana orodja za regresijsko testiranje in avtomatizirana orodja za testiranje delovanja. Želijo napisati svoje testne načrte in imeti dvosmerni vnos v orodja za zahteve in iz njih, da lahko ohranijo svojo sledljivost. Torej mora biti povsod komunikacijsko in odprto.
Vložki se samo povečujejo, da bi že prvič dobili pravo kakovost. Kakovost s spletnimi storitvami in SOA lahko izboljša ali uniči zmogljivost in zanesljivost sestavnih storitev, lahko celo obarva dojemanje IT na splošno. Zato se mora kakovost zgoditi že od samega začetka, ne kot dejavnost v pozni fazi, da ne bi arhitekti in poslovni analitiki ugotavljajo, da storitvam ni mogoče zaupati enako kot monolitnim aplikacije.
Za več, poslušaj na 29 minutni podcast, oz preberi celoten zapis. Sponzor: Borland Software.