Page 16 - MAKSİMUM BİZ | BAHAR 2009

Performans ve Operasyonellik "Do¤ru tan›m + do¤ru proje = Baflar›"
Fonksiyonel olmayan gereksinimlerin 2 önemli kategorisi; performans ve operasyonelliktir. Perfor- mans ve operasyonelli¤i istenen seviyede olmayan sis- tem uygulamalar›, nadiren baflar›l› say›labilirler. ‹l- ginçtir ki, birçok bilgi teknolojisi projesinde, fonksiyo- nel olmayan gereksinimler, fonksiyonel olan gereksi- nimlerden daha sonra dikkate al›nmaktad›r.
Fonksiyonel olmayan gereksinimler genellikle sistemin uygunlu¤u ve performans konular›n› dikkate al›r. Fonskiyonel olmayan gereksinimler; esneklik, öl- çeklenebilirlik, uygunluk, sürdürülebilirlik, güvenilir- lik, kullan›labilirlik ve sa¤laml›k gibi alanlar› içerir. Kalite ve maliyet de fonksiyonel olmayan gereksinim- ler aras›nda de¤erlendirilebilir.
Gerçek Dünyadaki Canl› Sistemler
Performans ve operasyonellik genellikle uygu- lama gelifltirme tak›mlar›n›n genifl fonksiyonel gerek- sinimlere odaklanmalar› sebebiyle gölgede kalmakta- d›r. fiu ana kadar canl› sistemlerde karfl›lafl›lan önem- li sorunlar sistemin fonksiyonel olmayan özelliklerin- den kaynaklanmaktad›r.
Vaka-Anlafl›lmas› Güç Düflük Performans Vakas›
fiubeleri ve ofis kullan›c›lar›yla beraber yaklafl›k 5,000 kullan›c›s› bulunan büyük bir banka uygulamas› genifl fonksiyonel bir kapsamla titizlikle canl› kullan›- ma al›nm›flt›r. Uygulama platformu J2EE teknolojisin- den oluflmaktad›r. 2 ayl›k canl› kullan›ma alma safha- s›nda kullan›c›lar aflama aflama ve flube flube, sistem ile ilgili e¤itimleri alm›fllard›r. Canl› kullan›mdan son- raki ilk haftalar uygulaman›n performans› beklenen düzeydedir.
Canl› kullan›ma ald›ktan birkaç hafta sonra kul- lan›c›lar sistemin ara ara kesilmelerinden ve buna ba¤l› performans düflüklü¤ünden flikayet etmeye bafl- larlar. Önceleri 2-5 saniye süren ifl operasyonlar› 20- 30 saniye almaya bafllam›flt›r. Performanstaki bu tu- tars›zl›k teknoloji tak›m›n› belirli fonksiyonlar› ve prob- lemli operasyonlarda kullan›lan veriyi yeniden incele- meye sevk etmifltir. Ancak, teknoloji tak›m› problemi iliflkilendirecek ortak bir sebep bulamam›flt›r.
Uygulama kullan›lmaya devam ettikçe perfor- mans problemi dayan›lmaz hale gelir. Birçok ifl ope- rasyonunun tamamlanmas› sürekli olarak 30 saniye almaktad›r. Sistemin kesik kesik çal›flma s›kl›¤› artm›fl ve çok ciddi bir problem haline gelmifltir. Kullan›c›lar
sistemi kullanmakla ilgili motivasyonlar›n› kaybetme- ye bafllam›fllard›r.
Teknoloji ekibinin üzerinde artan bask›lar sonu- cu, Bilgi Teknolojileri Müdürü, ilgiyi altyap› konular›na çevirmifltir. Bunun bir network ya da sistem kapasitesi konusu oldu¤unu düflünmüfltür. “Uygulamay› ilk çal›fl- t›rd›¤›m›zda performans›n bu kadar iyi olmas›n›n tek mant›kl› sebebi buydu” diyerek problemin do¤rudan uygulama ile ilgili bir konu olmad›¤›na inan›r.
Altyap› ile ilgilenen tak›m, daha sonra uygulama ile iliflkisi ortaya ç›kan teknolojik konularda, yeterli tecrübeye sahiptir. Bunun sonucunda altyap›n›n her biriminin durumunu belirleyen birçok ayr› testler ge- lifltirirler. Altyap› organizasyonu h›zl›ca bu testleri ger- çeklefltirirken yönetime de testlerin sonuçlar› bildirilir. Testlerin sonucunda altyap›n›n bak›fl› aç›s›ndan herfley normal görünmektedir.
Konuya daha fazla ilgi gösterme zaman› gelmifl- ti. Artan s›k›nt›, Bilgi Teknolojileri Müdürünün kendisi- ni rahats›z hissetmesine sebep olmufltu. Ekip sorunu en h›zl› flekilde çözmek için görevlendirilmiflti. Proble- min kritikli¤i yüzünden organizasyonun bütün imkan- lar› uzman ekip için haz›r tutuluyordu.
‹fle dahil olduktan bir süre sonra dan›flmanl›k ekibi flu gözlemleri yapt›:
14