Page 16 - MAKSİMUM BİZ | SAYI 09 | 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