Upravljanje životom aplikacije

imageOd definiranja zahtjeva pa do isporuke, dugi je put razvoja softvera, a na kraju tog puta najčešće smo opet na novom početku. Nakon isporuke slijede novi zahtjevi te opet putujemo kroz iste stadije planiranja, implementacije i testiranja da bi došli do nove isporuke. I onda opet ispočetka. To su ciklusi života jedne aplikacije, jednog softverskog uratka. Kako aplikacija ne bi živjela bez kontrole, potrebno je njome upravljati. To cjeloživotno upravljanje razvojem aplikacija naziva se ALM (Application Lifecycle Management).

Cjeloživotno upravljanje aplikacijom (ALM) obuhvaća aktivnosti i alate koji pokrivaju cjelokupni životni tijek razvoja softvera od prvih ideja do završne isporuke, pa i dalje kroz faze održavanja sve do odlaska softvera u zasluženu mirovinu. ALM objedinjuje sve stadije života aplikacije te prožima sve discipline prisutne u softverskom razvoju, od upravljanja zahtjevima (requirements management), preko arhitekture, implementacije, testiranja do projektog menadžmenta te upravljanja verzijama i međuverzijama (release i build management). Ciljevi ALM-a su: kroz sve faze razvoja povećati produktivnost i istovremeno unaprijediti transparentnost i kvalitetan uvid u stanje razvojnog procesa. Vizija ALM-a je brak između biznisa i razvojnih timova. U organizacijama koje primjenjuju ALM, biznis i razvoj čvrsto su povezani, razvojni timovi nisu izolirani otoci svojih organizacija. Biznis zna i vrednuje što ljudi u razvoju rade, a razvojni timovi svjesni su svoje uloge u poslovanju tvrtke. Situacija u većini tvrtki vrlo je rijetko takva. Na žalost, vrlo često, upravo suprotna. Biznis ne doživljava razvojni tim. Nema uvid u stanje razvojnih projekata. Zapravo, nema uopće mogućnosti saznati osnovne informacije o projektu, dobiti odgovor na najjednostavnija pitanja. Kakvo je stanje projekta? Kada će softver biti spreman za isporuku? Kakva je kvaliteta aplikacije koja se razvija? Kada bi takva pitanja postavili članovima razvojnog tima, oni ne bi znali odgovor, ili bi pak svaki odgovor bio drugačiji. Ako nemamo sustav koji će nam omogućiti transparentnost u razvojnom procesu, sustav koji će sam davati odgovore na ovakva pitanja, vjerojatno nikada nećemo ni znati u kakvom je stanju naš projekt, ili ćemo odgovore dobiti tek kada za to bude prekasno. Statistika govori da većina razvojnih projekata propada i nikada se ne dovrši do kraja, a oni koji dođu do svog cilja, često probiju ALM graf1zacrtane budžete i planirano vrijeme. Morali to biti tako? Postoje i svijetli primjeri u razvoju softvera, postoje projekti koji su vrijedni divljenja, ali oni nisu slučajno postali takvi. Davno je prošlo vrijeme kada je za razvoj uspješnog softvera bila dovoljna jedna garaža i par entuzijasta. Zahtjevi na softver današnjice kao i zakoni tržišta iziskuju drugačiji pristup. Želimo li kvalitetan softver, ALM nije jedna od mogućnosti, ALM je nužan i to ALM u svim fazama razvojnog procesa. Na tržištu se nalazi puno alata koji pokrivaju neke faze razvoja, ali samo ih je nekoliko za koje možemo reći da su ALM sustav, sustav koji objedinjuje alate za sve faze razvojnog procesa. Među najpoznatije i najviše zastupljene na tržištu spadaju sustavi velikih IT divova kao što su: Microsoft Visual Studio ALM, IBM Rational Team Concert te skup HP ALM alata.

U početku bijaše kôd…

Verzioniranje razvojnog kôda odnosno upotreba nekog od sustava za upravljanje i spremanje izvornog koda (version control system) jedna je od najčešće korištenih disciplina ALM-a. Taj segment ALM-a opće je prihvaćen i većina razvojnih timova koristi neki od alata za verzioniranje. Iako se alati međusobno razlikuju, principi rada su im prilično slični. Kompletan razvojni kod sprema se u središnju bazu podataka i svaki korisnik, odnosno programer, prije nego mijenja bilo koju datoteku, preuzima je iz baze (check-out), radi na njoj te je po završetku posla vraća u bazu (check-in, commit). Svaka promjena se bilježi u povijest promjena i ostaje zauvijek zabilježena. Uz to, većina alata nudi i razne druge opcije za dodatno naprednije upravljanje kodom. Do pojave naprednijih ALM alata, za potrebu verzioniranja najčešće su se koristili jednostavni alati kao što je sada već zastarjeli Microsoft SourceSafe, Java bazirani SubVersion ili CVS. Nedostatak tih alata je što nisu integrirani u cjelokupni ALM sustav, negoALM stupanj organizacije su izolirani alati koji služe isključivo verzioniranju koda. ALM sustavi nove generacije verzioniranje povezuju i sa sustavom za upravljanje radnim stavkama, testiranjem, automatizacijom buildova i svim drugim podsustavima ALM-a. Izvorni kod osnova je svakog softverskog projekta i nužna je njegova veza sa cjelokupnim razvojnim procesom. Tako se stvara kolaboracija između programera i ostatka tima. Programer i dalje programira i govori jezikom koji samo računalo razumije, a testeri, dizajneri, voditelji timova znaju točno što on radi jer svaka njegova promjena u kodu vezana je uz točno definiranu radnu stavku (work item) i ništa ne smije biti dodano u kod, a da nije rezultat neke definirane radne stavke, na primjer zadatka ili opisa buga.

Sve se piše, sve se pamti

 

Jedna od glavnih ideja ALM-a je transparentnost. Sve što se radi na projektu treba imati svoj trag. Svako rješenje je rezultat definiranog zadatka, a svaki zadatak proizašao je iz dokumentiranog zahtjeva. Također, svaka greška otkrivena u testiranju mora biti zabilježena, a kada se riješi, rješenje se mora povezati sa definicijom buga. Idealno i svaki bug otkriven je tijekom izvršavanja točno unaprijed definiranih testnih slučajeva. Svaki testni slučaj testira točno određeni scenarij koji je opet rezultat nekog od početnih zahtjeva. Zahtjevi, zadaci, bugovi, testni slučajevi, sve su to vrste radnih stavki (work items). Ovisno o metodologiji rada koju koristimo, radnih stavki može biti više ili manje. ALM alati moraju omogućiti prilagodbu definicija radnih stavki metodologiji i procesu koji se koristi na projektu.

work_item_workflowUz upravljanje zahtjevima i upravljanje radnim stavkama, usko je vezano i upravljanje promjenama (Change Request Management). Ovisno o stupnju formalnosti naše organizacije, upravljanje promjenama bit će jednostavniji ili složeniji postupak. Što je organizacija veća i sustav koji se mijenja „bitniji“, to je proces upravljana promjenama složeniji. Zamislite postupak promjene softverskog koda ili ispravljanje greške u sustavu za upravljanje vojnim satelitom ili možda bliži nam primjer: promjena u softverskom sustavu bankarskog poslovanja. Svaka promjena u takvom sustavu strogo je definirani proces. Da bi linija koda ušla u takav softver, nije dovoljno da postoji jedan zahtjev, radna stavka koja ga opisuje, već takav zahtjev mora proći kroz strogo definirani tijek događaja (workflow). Od početne definicije pa da verifikacije zahtjeva, od raznih nivoa unutar firme pa do faze implementacije, te testiranja na raznim sustavima i podsustavima. ALM alati, kroz upravljanje radnim stavkama, moraju omogućiti takav razvojni proces.

Graditeljstvo softvera

branching_vizualizacija Release i build managament, u slobodnom prijevodu upravljanje verzijama i međuverzijama, neizostavni su dijelovi ALM-a. Prije pojave ALM sustava, postojali su alati namijenjeni bilo jednoj, bilo drugoj disciplini. Međutim njihovim povezivanjem, ALM sustavi dali su tim disciplinama dodatnu vrijednost. Svaka izdana verzija softvera, bilo da je riječ o verziji za tržište ili samo jednog korisnika, bilo da je izdani service pack ili mala zakrpa, mora biti posebno označena i spremljena na dohvatljivo mjesto. Izvorni kod takve verzije mora biti lako dohvatljiv iz sustava za upravljanje kodom. Radni kod i kod izdanih verzija mora se moći odvojiti. To odvajanje verzija nazivamo grananje (branching). Grananjem se dobiva mogućnost istovremenog rada na promjenama izdane verzije i radne verzije aplikacije.

Daily Build ili dnevna izgradnja međuverzija odavno je poznata praksa. I prije postojanja modernih ALM sustava, postojali su razni alati za upravljanje buildovima. Dnevni build zapravo bi bolje bilo zvati noćni build jer se najčešće izvršava u gluho doba noći. U vrijeme kad su uredi prazni i kad razvojni tim ne radi na projektu, razvojni proces i dalje je aktivan. Noć je idealno vrijeme u kojem naši serveri mogu obavljati razne zahtjevne poslove i tako koristiti vrijeme mira i tišine na razvojnim radnim stanicama. Preporuka ALM-a je da se svaku noć izvrši build u kojem će seBuild_steps integrirati sve promjene prethodnog dana, te će se nakon toga nova međuverzija pripremiti kao setup i/ili automatski isporučiti u sustav za testiranje. Izvršit će se sve automatske analize i testovi nad aplikacijom, a ujutro razvojni tim u svom mailboxu dobit će izvještaj o rezultatima builda. ALM omogućuje upravo to, pa i više od toga. Dobra je praksa da se buildovi izvršavaju i češće od jednom dnevno. Stoga nam većina alata omogućuje definiranje builda koji se pokreće svakim checkinom. Time se uspostavlja continuous integration, kontinuirana integracija koda u build proces. Svakom promjenom izvršava se build i nakon par minuta ili na većim projektima možda malo dulje vrijeme, dobivamo izvještaj o tome kako je prošao build.

Aplikacija u laboratoriju

Rijetki su timovi koji u svojim redovima imaju testere, osobe zadužene isključivo za testiranje. S druge strane programeri ne vole testirati. Ili su preuvjereni u kvalitetu svog uratka pa im je testiranje „ispod časti“ ili su pak prezagušeni poslom pa za taj „nebitni“ dio nemaju vremena. Tko onda testira softver? Korisnik? Da, to je nažalost česti odgovor. Pronalazi li korisnik bugove? Ovo je retoričko pitanje, svi smo mi korisnici pa jako dobro znamo kakav je softver koji koristimo, bilo privatno, bilo poslovno. Koliko košta ispravak otkrivene greške? Statistika kaže da je ispravak greške kod korisnika i do nekoliko puta skuplje od ispravka greške koju smo otkrili na samom početku razvoja. Kako uočiti propuste u implementaciji na vrijeme? Prvi korak je da se promijeni ALM_dashboardraspoloženje prema testiranju. No, kada odlučimo početi testirati, pitanje je što testirati? Ako bi nakon svake promjene uvijek iznova testirati cijelu aplikaciju, brzo bi odustali od toga. Potrebna nam je naravno pomoć alata za automatsko testiranje. Potreban nam je alat uz čiju pomoć možemo definirati testove, izvršiti testove, prikupiti rezultate testova te ih pratiti i analizirati kroz vrijeme. Alati koji dolaze sa modernim ALM sustavima nude upravo to. Po mnogim svojstvima najkvalitetniji među njima su HP Quality Center iz HP sustva za ALM, Microsoft Test Manager integriran sa Team Foundation Serverom te IBM Rational Quality Manager iz IBM porodice ALM alata.

Svi za jednog, ALM za sve

Alati za upravljanje zahtjevima, zadacima, verzijama, alati za testiranje, alati za izvršavanje buildova, sve to u raznim fazama pomaže razvojnom timu. No kada se povežu ti alati u jedan cjeloviti sustav onda je njihova vrijednost veća nego zbroj vrijednosti svakog pojedinačno. Kvaliteta svakog pojedinačnog alata je bitna, ali ne i presudna. Današnji vrhunski alati za razvoj sami po sebi nisu dovoljni da bi razvojni projekti bili uspješni. ALM rješenja podrazumijevaju alate koji razmjenjuju podatke, implementiraju workflowekoji prelaze granice pojedinih rola i na taj način uspostavljaju komunikaciju među njima. Kvalitetna integracija alata katkada igra veću ulogu od njihovih osobina i specifičnosti. Tek kroz integraciju alati omogućavaju koordinaciju svih ALM aktivnosti i time osiguravaju da rezultat našeg projekta rješava poslovni problem zbog kojeg je projekt i započet.

Ako alati nisu međusobno povezani i ne brinu se za razmjenu informacija, ljudi su prisiljeni kontinuirano manualno sinkronizirati tj. kopirati podatke iz jedne aplikacije u drugu, npr. prijave grešaka iz aplikacije za podršku korisnicima se moraju kopirati u aplikaciju ili dokument za evidenciju bugova koju koristi razvojni tim. Ako se informacija o statusu pojedinih zadataka ne distribuira automatski, projektni menadžer mora sazivati sastanke ili tražiti izvještaje od članova tima. Sva ta eksplicitna komunikacija zahtjeva vrijeme i trud i tako smanjuje produktivnost. Integriranim ALM sustavima i njihovom pravilnom primjenom svi podaci o projektu prikupljaju se sami i daju transparentnu sliku stanja projekta, a razvojni tim ne opterećuju još jednih administrativnim poslom, već naprotiv olakšava im poslovnu svakodnevicu i povećava njihovu produktivnost.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>