Naša firma je unutrašnju organizaciju rada kao i nastupanje prema klijentima postavila na osnovama Agile principa. Osnovne karakteristike ovakvog organizovanja rada, sa stanovišta klijenata, su:

1. projektni zahtev može biti znatno manje detaljan u odnosu na klasičan pristup.
2. mogućnost korigovanja projektnih zahteva u toku rada na projektu.
3. mogućnost kontrole funkcionalnosti koje se razvijaju kroz aktivno učešće klijenta na njihovom testiranju.
4. kontinuirano testiranje u toku svih faza razvoja, koje finalno testiranje svodi na formalnost.
5. dokumentacija se piše u toku razvoja, tako da u potpunosti odgovara implementiranim funkcionalnostima.
6. manji je pritisak na programere što rezultuje pozitivnijom atmosferom u timu.

Kao svaka preporuka ili standard i Agile je samo mrtvo slovo na papiru ukoliko ne postoje ljudi koji ga na adekvatan način sprovode u praksi. Naše dosadašnje iskustvo u korišćenju Agile principa za klijente znači bezbedan razvoj projekta.

Korisni linkovi: Agile software development, Extreme Programming, Scrum.

Među tehnikama programiranja objektno orijentisani dizajn je verovatno najpopularniji jer predstavlja efikasan način za realizaciju kompleksnih sistema. Karakteriše ga kreiranje malih celina (objekata) koje interno imaju potpuno definisan sistem funkcionisanja, a zatim povezivanje tih malih celina u jedan složen sistem. Definisanje samih objekata je opisivanje, programskim kodom, jednostavnih procedura nad određenim podacima.

Kasnija upotreba ovih objekata u kreiranju složenih interakcija pokazuje da su neke interakcije već viđene u mnogim rešenjima. Kao rezultat tog saznanja kreirani su obrasci ponašanja (pattern). Najpoznatija knjiga koja opisuje ove obrasce je "Design patterns - Elements of Reusable Object-Oriented Software".

U cilju efikasnijeg rada na složenim sistemima, osim korišćenja gotovih obrazaca ponašanja koristimo i narativni opis procedura, UML dijagrame i komentare unutar koda koji se pišu po strogim pravilima. Jednostavno rečeno, to je dokumentacija. Deluje kao nešto što se podrazumeva ali se u praksi prečesto, usled kratkih rokova i drugih problema dešavaju propusti, pa se takve stvari ostavljaju za kraj. Rezultat je da na kraju malo ko zna sve detalje projekta. Mi sa ponosom možemo da kažemo da u svakoj fazi rada na projektu posedujemo napred navedenu dokumentaciju.

Naše aplikacije su sposobne da razmenjuju podatke, kako među sobom, tako i sa drugim aplikacijama, slično učestvovanju u chat-u.

Činjenica da koristimo web service standard za komunikaciju znači da smo otvoreni ka svim platformama i programskim jezicima.

Nedostatak web service-a, u odnosu na neke druge standarde, su prevelike poruke koje se šalju kroz mrežu. Taj nedostatak dolazi do izražaja kod vremenski kritičnih operacija. U tu svrhu smo, kao ekstenziju web service-a, razvili sopstveni sistem kompaktnih poruka koje se brzo kreiraju i prenose do drugih učesnika.

Jedna aplikacija (jedan exe fajl) može da obavlja više poslova odjednom. Te poslove unutar aplikacije obavljaju mali procesi (thread-ovi) koji razmenjuju podatke između sebe i time prave kompleksan sistem. Sistem kao takav može biti trom, sa sporim reagovanjem na spoljnje događaje, ili reagovati u pravom trenutku. Zavisno od potreba, taj zahtev za vremenom reagovanja na spoljnje događaje može biti različit, ali je nešto što se očekuje od sistema.

U svrhu kontrolisanog rada pojedinačnih procesa (thread-ova) unutar jedne aplikacije razvili smo:

1. pouzdan sistem za prenos podataka izmedju thread-ova.
2. sistem thread-ova koji nije opeterećujući za aplikaciju pa svaki thread u pravom trenutku reaguje na događaj za koji je zadužen.

Jednom napisan kod potrebno je testirati. Postoje dve vrste testova. Testovi koje prave programeri i testovi koje izvodi krajnji korisnik. Testovi koje prave programeri (Junit ili xUnit) su prvi testovi koji se primenjuju i veoma su bitni za same programere. Daju im potrebnu dozu poverenja u sam kod koji su napisali. Ti testovi otklanjaju skoro sve nedostatke vezane za propuste u toku kodiranja, kao što su loše implementirane funkcije koje ne rade tačno ono zbog čega su pravljene, pogrešno inicijalizovanje raznih vrednosti, nekontrolisan jednovremen pristup jednom istom podatku od strane više procesa (thread-ova) itd. Testovi koje izvodi krajnji korisnik manje više se bave samo procedurama definisanim projektnim zahtevom.

Ukoliko su navedeni xUnit testovi korektno pisani, uvek smo sigurni da će testiran kod davati rezultat rada kakav je zadat projektom. Bilo kakvo menjanje koda, koje za rezultat ima promenu neke funkcionalnosti, neće ostati nezapaženo jer će xUnit test to prijaviti.

xUnit testove ne treba posmatrati kao konačno rešenje za bagove u aplikacijama. Pisanje testova je vremenski veoma zahtevan posao pa se u praksi, u toku rada na konkretnom projektu, pravi procena do koje mere je napisan kod dovoljno pokriven testovima.

Možemo da kažemo da sav naš kod uvek ima prateće xUnit testove, koji su (takođe) dobro dokumentovani.

Prikupljanje, skladištenje podataka i njihova kasnija analiza je pravi posao za neki od mnogih DB manager-a (PostgreSQL, MySQL, MS SQL Server, Oracle, DB2, ...). Zavisno od količine podataka koje treba obraditi u jedinici vremena bira se i odgovarajući DB manager. Može se praviti i podela na osnovu raspoloživih pratećih alata koji olakšavaju rad sa bazom podataka, pa tako možemo reći da su open source DB manager-i (PostgreSQL, MySQL, ...) zahtevniji za programera od komercijalnih proizvoda (MS SQL Server, Oracle, DB2, ...). Međutim, pošto se na kraju ipak meri učinak rada samog DB manager-a, ostaćemo pri tome da je podelu bolje praviti prema količini podataka koje treba obraditi. Pravo je pitanje koja je to količina podataka koju sistem treba da obradi a koja određuje da li su open source DB manager-i dovoljni ili treba koristiti komercijalne. Pa sve dok možete da se nosite sa problemom pomoću open source DB manager-a koristite njih. Kada rad sa bazom podataka postaje problem za koji nema lakih rešenja, tada pređite na neki komercijalni DB manager.

Naša preporuka za open source DB manager je PostgreSQL. Lak je za instaliranje, održavanje, izuzetno je pouzdan, brz je, radi na svim popularnim operativnim sistemima (Windows, Linux, raznim Unix-ima, Mac OS) i veoma aktivno se razvija kao proizvod.

Što se komercijalnih DB manager-a tiče možda jedinu prednost nad ostalim proizvodima treba dati Oracle-u ili DB2 zbog bolje podrške radu na više servera i manipulisanju sa mnogo konekcija ka bazi (replication i load balancing). Pošto većina firmi nema takve ekstremne zahteve, mi preporučujemo MS SQL Server ili Oracle.

Najrašireniji operativni sistemi danas su MS Windows, Linux i Mac OS (da dodamo i Symbian za mobilne telefone). Teško je reći da svako od nas koristi isključivo jedan operativni sistem. Da, svako ima svog favorita, ali u svakodnevnom životu se srećemo makar sa raznim uređajima za koje ne znamo kakav softver na njima radi. A isti softver može da radi na bilo kom od navedenih popularnih operativnih sistema. I da korisnik ne uočava upotrebnu razliku. Zavisno od softvera moguće je uočiti razliku u izgledu prozora, tastera, tabela... Bitno je da nema upotrebne razlike. Aplikacija koja je pravljena da radi na više operativnih sistema mora da se ponaša isto i da ima isti izgled bilo gde da radi.

Operativni sistemi (skraćeno OS) su kreirani oko nekih pravila. Ta pravila su svuda uglavnom dobro definisana i realizovana. Ali, postoje i neke greške koje proizvođač operativnog sistema ne otklanja ažurno. Aplikacija koja pretenduje da radi na više operativnih sistema mora da zaobilazi te probleme i da ne ugrožava rad drugih aplikacija.

Kao firma posedujemo veliko iskustvo u razvoju aplikacija pod MS Windows i Linux operativnim sistemima. Da bi aplikacije koje pravimo mogle da rade na oba operativna sistema formirali smo razvojno okruženje bazirano na gotovim programskim alatima i našim rešenjima. Pravljenje aplikacija koje stabilno rade pod navedenim operativnim sistemima podrazumeva dobro poznavanje administracije tih OS-ova.

Koja je definicija real-time aplikacije? To je aplikacija čiji je vremenski odziv na bilo koji zahtev od strane korisnika ili neke druge aplikacije takav da se ne ometa proces koji aplikacija obrađuje. Kada jedna aplikacija zatraži podatke od druge aplikacije i očekuje da odgovor stigne za manje od dve sekunde, odgovor mora stići u tom vremenskom periodu. Kada korisnik zatraži podatke od aplikacije klikom na odgovarajući taster i očekuje da će rezultat dobiti za manje od tri sekunde, odgovor mora stići u tom vremenskom periodu. Drugim rečima, odziv ne sme da kasni. Ne postoje fiksna vremena odziva za aplikaciju koja pretenduje da podržava real-time rad, nego su procesi ti koji diktiraju ove veličine. Vremena odziva mogu da se kreću od milisekundi do dana, godina... Očigledno je da se procesi koji zahtevaju brze odzive moraju veoma pažljivo dizajnirati i realizovati u okviru aplikacije da bi se uvek nesmetano odvijali.

U dosadašnjem radu realizovano je praćenje brzih procesa koji su zahtevali vreme odziva od nekoliko milisekundi. Ostvareno vreme odziva između aplikacija, u okviru lokalne računarske mreže srednje veličine je reda veličine sekunde. Pri tome, aplikacije koje učestvuju u toj razmeni podataka mogu biti i samostalne aplikacije koje rade u pozadini bez interakcije sa krajnim korisnikom (sistemski servisi u MS Windows terminologiji, odnosno daemon-i u Unix terminologiji), kao i desktop aplikacije preko kojih krajnji korisnik može da prati procese u realnom vremenu. Možemo da kažemo da umemo da napravimo dobar dizajn koji omogućava brze odzive.