Çevik bir Hikâye: Celal Bayar Üniversitesi Öğrenci Kayıtlanma Modülü Bu Dönem Neden Çökmedi?
Onur LEBLEBİCİ, Deniz KILINÇ, Ceyhun ARAZ, Cihan DEMİREL, Bora GÜRSEL, Seda GÖRMEZ
Celal Bayar Üniversitesi, Bilgisayar Araştırma ve Uygulama Merkezi, Manisa onu
r . l e b l e b i c i @ c b u . e d u . tr , d e n i z . k i l i n c @ c b u . e d u . t r , ceyhu n . a r az @ c b u . e d u . t r , ci h a n . d e m ir e l @ c b u . e d u . t r , bo
r a . g u r s e l @ c b u . e d u . tr , s eda . g o r m e z @ c b u . e d u . tr
Özet: Yazılım teknolojilerinin hızla ilerlediği bu dönemde üniversitelerde kullanılan yazılım otomasyon sistemlerinin geride kalması önemli bir problemdir. Bu duruma ilave olarak;
üniversitelerin Bilgisayar Bilimleri, Bilgisayar Mühendisliği, Yazılım Mühendisliği ve Bilgisayar Programcılığı gibi bölümleriyle sektör için uzman personel yetiştirdiğini düşünürsek, olay farklı bir boyut almakta ve maalesef “Terzi kendi söküğünü dikemiyor”
sonucu ortaya çıkmaktadır. Tecrübe aktarımı niteliğindeki bu bildiride, CBÜ BAUM tarafından geliştirilen Yeni Kayıtlanma Modülünün geliştirme süreçleri ve detayları hakkında bilgilendirme yapılmıştır. Deneysel sonuçlarda da görüldüğü üzere hayata geçirilen bu modül, 33.000 kullanıcının üzerinde yoğun bir kullanıma rağmen, yüksek sistem performansı ve sıfır hata sayısı ile ciddi bir başarı elde etmiştir. Hem yazılım performans metrikleri hem de öğrencilerden gelen olumlu geri dönüşler dikkate alındığında üniversitelerin 100.000’lerce kullanıcıyı kaldırabilecek kaliteli yazılım ürünü geliştirmelerinin hayal olmadığı ortadadır.
Anahtar Sözcükler: Üniversite Yazılım Otomasyonları, Çevik Yazılım Geliştirme, SCRUM
Abstract: Despite the rapid evolution of software technologies, software automation systems in universities, could not keep up with. In addition to this situation, the fact that the universities are responsible to educate professional engineers in Computer Science, Computer Engineering, Software Engineering and Computer Programming reminds us the idiom “the shoemaker's son always goes barefoot”. In this paper, a newly developed Student Registration Module and its development process details are provided. The paper is in the form of experience sharing and the development is done by CBÜ BAUM. As seen in the experimental results, despite intensive usage over 33,000 users, system has zero defects and reached high overall system performance. As a result, implemented module is an admirable success.
Finally, it is obvious that development of a high quality software, supporting 100.000 users is not a fantasy.
1. Giriş
Son yıllarda yazılım teknolojileri hızlı bir gelişim sürecine girerek, küçük, orta ve büyük ölçekli yazılım geliştirme firmaları ve açık kaynak kod toplulukları tarafından farklı alanlarda kullanılabilen yazılımlar üretilmeye başlanmıştır[1].
Teknoloji bu hızla ilerlerken üniversitelerde kullanılan yazılım otomasyon sistemlerinin
buna ne kadar ayak uydurabildiği önemli bir tartışma konusudur. Bir de üniversitelerin Bilgisayar Bilimleri, Bilgisayar Mühendisliği, Yazılım Mühendisliği ve Bilgisayar Programcılığı gibi bölümleriyle bu sektör için uzman personel yetiştirdiğini düşünürsek, olay farklı bir boyut almakta ve maalesef
“Terzi kendi söküğünü dikemiyor” sonucu ortaya çıkmaktadır.
Bir üniversite yazılım otomasyon sistemi temelde 3 kullanıcı grubuna hizmet
vermektedir: (1) Öğrenciler, (2) Akademik Personel, (3) İdari Personel. Bu kullanıcı grupları farklı alt kullanıcı gruplarına ayırılabilmektedir.
Bir üniversitenin yazılım otomasyon sistemi aslında kurumsal bir yazılım ürününden farksız olup, değişik derinlikte alt yazılım ürünlerini ve modüllerini içerebilmektedir.
Örneğin: Öğrenci Otomasyonu, Personel Otomasyonu, Elektronik Belge Yönetim Sistemi, Akademik Performans Yönetimi bu alt ürünlerden bazılarıdır.
Türkiye’deki üniversitelerde kullanılan yazılım otomasyonlarında herhangi bir standart bulunmamaktadır ve bu durumu normal karşılamak gerekir. Çünkü üniversiteler Yükseköğretim Kuruluna[3]
(YÖK) bağlı olsalar da kendi içlerinde özerk birer kurumdurlar. Her üniversitenin kendine süreçlerini tanımladığı çeşitli yönetmelikleri bulunmaktadır (Örnek için bakınız [10]). Bu yönetmelikler de bir yazılım ürününün veya modülünün işleyişini ve fonksiyonlarını oluşturmaktadır.
Üniversite yazılım otomasyonlarında standartlaşması en zor olan ürünlerden birisi de Öğrenci Otomasyonudur. Yüksek seviyede dikey derinliğe sahip olan bu otomasyonun üniversiteden üniversiteye değişen onlarca farklı süreci ve uygulaması bulunmaktadır.
Öğrenci otomasyonlarındaki Kayıtlanma Modülü de tüm üniversite yazılım otomasyonundaki en zor modüllerden birisidir. Özellikle kökleşmiş, lisans ve lisansüstü bölümlere sahip ve 10.000’lerce öğrencisi olan üniversitelerde 100’lerce farklı öğrenci kayıtlanma senaryosu bulunmaktadır.
Kayıtlanma modülündeki diğer zorluk da öğrencilerin istediği dersi, dersin kontenjanı dolmadan seçmek istemesidir. Öğrencileri bu noktada “Başlatılmayı beklenen bir yarışmanın yarışmacılarına” benzetebiliriz.
Yarışmanın başlatılması yani kayıtlanma sistemin açılması ile birlikte öğrencilerin tek hedefleri “bir an önce istedikleri dersi seçmek ve kayıtlanmayı tamamlamaktır”.
Tam da bu noktada üniversite kayıtlanma modülü yoğun bir stres testinden geçmektedir.
Binlerce öğrenci interaktif bir web uygulamasından sisteme girmekte ve kayıt olmaya çalışmaktadır. Böyle bir sistemin çalışması için çeşitli yazılım kalite metriklerinden söz edilebilir ancak buradaki en önemli konu sistemin performansını bütünüyle ele almaktır: (a)Yazılım mimarisi ve kalitesi, (b) Sunucu konfigürasyonu ve mimarisi, (c) Ağ mimarisi.
Eğer yazılım sistem performansı bütünüyle ele alınmaz ve sistem bu kullanıcı sayısını kaldıramazsa, o an interaktif olan binlerce öğrenci sistemle ilgili olumsuz düşünceye kapılmakta ve bunu çevreleri ile paylaşmaktadırlar.
1992 yılında kurulan Celal Bayar Üniversitesi [2] (CBÜ) 2014 yılında Bilgisayar Araştırma ve Uygulama Merkezini (BAUM), üniversite yazılım geliştirme ve test süreçlerini yönetmesi ve gerçekleştirmesi için yeniden yapılandırmıştır.
Celal Bayar Üniversitesi 2013-2014 Bahar kayıtlanma döneminde, kayıtlanma sisteminin
öğrencilere açıldığı ilk 30 dakika sonrasında servis veremez hale gelmiştir. Bu kötü tecrübe sonrasında CBÜ BAUM ekibi Kayıtlanma Sistemini yeniden yazma kararı almıştır. Çevik bir yazılım geliştirme yöntemi olan Scrum kullanılarak 4 kişiden oluşan (Yazılım Mimarı, Yazılım Görsel Arayüz Uzmanı, Yazılım Veritabanı Uzmanı, Yazılım Test Uzmanı) bir Kayıtlanma Ekibi oluşturulmuş ve sistem en baştan analiz edilerek yeniden geliştirilmiştir.
2014-2015 Güz kayıtlanma döneminde bu yeni kayıtlanma sistemi hayata geçirilmiş ve
33.000 kullanıcının üzerinde yoğun bir kullanıma rağmen, yüksek sistem performansı ile ciddi bir başarı elde edilmiştir. Hem yazılım performans metrikleri hem de öğrencilerden gelen olumlu geri dönüşler dikkate alındığında üniversitelerin 100.000’lerce kullanıcıyı kaldırabilecek kaliteli yazılım ürünü geliştirmelerinin hayal olmadığı net bir başarı hikayesi ile ortaya konulmuştur.
Tecrübe aktarımı niteliğindeki bu bildiride, CBÜ BAUM tarafından geliştirilen Yeni Kayıtlanma Modülünün geliştirme süreçleri ve detayları hakkında bilgilendirme yapılmıştır.
Bildirinin 2. bölümünde CBÜ BAUM ekibinin yapılanması ve yazılım geliştirme süreci ile ilgili bilgilendirme yapılmıştır. 3.
bölümde kayıtlanma sisteminin yeniden geliştirilmesi ile ilgili süreçler, teknik detaylar ve dikkat edilen yazılım geliştirme metrikleri üzerinde durulmuştur. 4. bölümde yeni kayıtlanma sisteminin hayata geçirilmesi ve sonuçları üzerinde durulmuş ve bu sistemin diğer üniversitelerde uygulanabilirliği tartışılmıştır.
2. BAUM Ekibi, Yazılım Geliştirme ve Test
Sürec i
CBÜ BAUM ekibi, üniversite yazılım otomasyonlarının yönetilmesi, geliştirilmesi
ve test edilmesi amacıyla 2014 yılında yeniden yapılandırılmıştır. Toplam 11
personel ve 1 müdürden oluşan ekibin tek odağı yazılım ve testtir. Çevik yazılım geliştirme yöntemlerinden olan SCRUM pratikleri BAUM’un yazılım geliştirme süreç temelini oluşturmaktadır.
SCRUM, hem ülkemizde hem dünyada yaygın olarak kullanılan çevik yöntemlerden biridir. 2013 yılında Agile Türkiye tarafından gerçekleştirilen Yazılım Üretkenlik Raporu sonuçlarına[4] göre de Türkiye’deki projelerin % 64’ünde çevik yöntemler uygulanmaktadır. SCRUM gibi çevik yöntemlerin üretkenliği [5], yazılım kalitesini [6] ve ekip üyeleri arasındaki iletişimi arttırdığı [7] bilinmektedir.
SCRUM temelde, yinelemeli bir yaşam döngüsü tanımlamakta ve büyük iş kalemlerinin, küçük ve yönetilebilir işlere bölünmesi ve önceliklendirilmesi ile ilgili yöntemleri içermektedir.
Şekil 1. SCRUM Süreci
BAUM’da genelde 2-3 haftalık sprintler oluşturulur. Arka planda sürekli güncel tutulan bir backlog bulunmaktadır. Zaman zaman birimlerden gelen ve o dönemde öncelikli olmayan iş maddeleri veya yazılım ekibi tarafından öngörülen sistem iyileştirmeleri bu backloga girilir.
Her sprinti tek sprint takımı gerçekleştirir.
Sprint planlama genelde 1-2 gün zaman alan bir süreçtir. Sprint planında hangi iş maddelerinin olacağına ürün yöneticisi ve müşteri temsilcisi karar verir. Müşteri temsilcisi genelde üniversite idare biriminde çalışan bir personel (Örn: Öğrenci İşleri, Personel Şube müdürleri) veya Rektör Danışmanıdır. Sprint planlaması yapılırken yazılım uzmanlarına istediği işi seçme hakkı verilir.
BAUM’da Scrum Master rolünü Yazılım Mimarı gerçekleştirir. Scrum Master, ekibin lideridir ve sprintin başarılı bir şekilde tamamlanması için elinden geleni yapar.
Ekibin dış etkenlerden en az şekilde etkileneceği bir çalışma ortamı sağlar. Günlük sprint toplantılarını yönetir.
Yazılım kaynak kod kontrol yönetim aracı ve SCRUM sürecindeki planların yönetimi ve gerçekleştirilmesi amacıyla Microsoft TFS (Team Foundation Server) ürünü [8]
kullanılmaktadır. Yazılım ve test aşamalarında çalışan tüm BAUM personelinin TFS sisteminde bir kullanıcı grubu ve hesabı bulunmaktadır.
SCRUM Backlog, TFS sistemi üzerinde tutulur ve tüm sprint planları yine TFS sistemi üzerinde gerçekleştirilir. Plandaki her iş maddesi için bir kullanıcı hikayesi oluşturulur ve daha sonra her hikaye alt görevler ile detaylandırılır. Yazılım uzmanlarına bu görevler delege edilir. Yazılım uzmanları geliştirdikleri bir isteğin veya çözdükleri bir
hatanın ilk testlerini yaptıktan sonra işi bütünüyle test etmesi ve kapatması için TFS üzerinden ilgili test uzmanına delege ederler.
BAUM yazılım geliştirme sürecinde 3 farklı dağıtım ve uygulama ortam bulunmaktadır:
(1
) Dev Orta m ı: Sadece yazılım geliştirmenin yapıldığı ve yazılım uzmanlarının kendi temel testlerini yaptıkları ortamdır.
(2
) Test Orta m ı: Yapılan sprint geliştirmeleri test uzmanları tarafından ilk olarak test ortamında test edilir. Test ortamının gerçek ortama çok yakın olması gerektiği için test veritabanı ve sistemi düzenli olarak canlı ortamdan kopyalanır.
(3
) Prod Orta m ı: Üniversite yazılım otomasyonunun çalıştığı canlı ortamdır.
Sprintlerdeki işler tamamlandıkça, sprint sonlarında bu ortam güncellenir. Acil hata çözümlerinde sprintin sonu beklenmeden, güncelleme önce test ortamında yapılır, testler sonucunda hatanın çözüldüğü gözlemlenirse, canlı ortam güncellenir.
2.1. BAUM Test Süreci
BAUM test sürecinin tamamı yine TFS sistemi üzerinden yürütülür. Sprintteki iş maddelerinin kullanıcı hikayelerine karşılık gelen yeni test senaryoları oluşturulur.
BAUM test ekibi ISTQB tarafından belirlenen 7 test prensibini [9] duvarına asar ve benimser.
Prensip 1: Testler hataların varlığını gösterir.
Yazılım testleri hataların var olduğunu gösterir fakat hiç bir hata kalmayacağını garanti etmez.
Prensip 2: Yazılım ürünün komple test edilmesi mümkün değildir.
Prensip 3: Erken test (Early testing). Yazılım geliştirme süreci ne olursa olsun, test aktivitesine mümkün olan en erken zamanda başlanmalıdır.
Prensip 4: Hataların kümelenmesi (Defect clustering). Hatalar, yazılımın belirli bölümlerinde kümelenebilir.
Prensip 5: DNT paradoksu (Pesticide paradox). Tekrarlayan aynı tipteki test aktiviteleri, yazılımda benzer hataların bulunmasına neden olurlar. Dolayısıyla, test koşulları sürekli yenilenmeli ve revize edilmelidir. Amacımız bataklıkta sivrisinek avlamak değil, bataklığı kurutmak olmalıdır.
Prensip 6: Testler içerik ve durum bağımlıdır. Yazılımın modül içeriğine veya kullanım durumlarına bakılarak farklı tipte veya derinlikte test aktiviteleri uygulanabilir.
Prensip 7: Hatalar %100 giderilemez. Test aktiviteleri esnasında hataların bulunması, yazılımın hatalardan %100 arındırıldığı veya son kullanıcının ihtiyaçlarının %100 kapsandığı anlamına gelmez.
BAUM test uzmanı kendisine delege edilen bir istekle ilgili temelde 4 test yapar:
1. Duman Testi: Genel anlamda ürünün ilk çalıştırılmasında duman çıkıp çıkmama testi olarak görülür. Bir bileşenin veya sistemin ana görevinin en can alıcı veya kritik
fonksiyonlarının çalıştığını görmek için detaydan uzak planlanmış tüm test koşullarının kapsandığı test biçimidir.
2. Fonksiyon Testi: Kodların minimum veri ile beklenen fonksiyonları ve işlevi yerine getirdiğinden emin olunması için yapılan test biçimidir. Genelde Kullanıcı Hikayeleri ve Test Senaryoları baz alınarak yapılırlar.
3. Ekran Standartları Testi: Yazılım ürünün belirlenen ekran standartlarına uyup uymadığının kontrol edildiği test biçimidir.
4. Kullanılabilirlik Testi: Gerçek hayat kullanım koşulları altında bir yazılımın kolay anlatılabilir, öğrenilebilir, kolay kullanılabilir ve kullanıcıya cazip gelme standartlarını içeren test türüdür.
Bu testlere ek olarak sprint tamamlandıktan sonra beklenmeyen etkilerin tespiti ve ölçümlenmesi için Test Uzmanı tarafından Basit Regresyon Testi yapılır. Ürünle ilgili önemli ve etkilenebilecek kısımlar baştan test edilirler.
3. Öğrenci Kayıtlanma Modülü Yeniden
Yazılma Süreci
Öğrenci Kayıtlanma Modülünün yazılım geliştirme ve test süreci 3'er haftalık toplam 4 sprintte tamamlanmıştır. Nesneye dayalı modelleme yaklaşımı ile Öğrenci Kayıtlanma Süreci yeniden modellenmiştir. Modelleme sürecinde UML durum senaryoları ve sınıf diyagramları oluşturulmuştur.
Özellikle doğrulama (validation) ve kayıtlanma kuralları için esnek bir katman tasarlanmıştır. Bunun sebebi CBÜ Kayıtlanma Yönetmeliğinde ileride olabilecek değişikliklerin yazılım bakım maliyetinin minimum düzeyde tutulmak istenmesidir.
Örneğin: Öğrencinin Alması Gereken, Alabileceği ve/veya Seçebileceği derslerde standart bir kural değişikliği olursa, değişiklik maliyetinin test süreci dahil 1 saati geçmemesi hedeflenmiştir.
Şekil 3. Kod haritası
Toplam 210 tane kullanım senaryosu (use- case) çıkartılmıştır. Her senaryo üzerinden Scrum ekibi ve öğrenci işleri ekibi birlikte geçmiş ve senaryolar doğrulanmıştır. Bu kullanım senaryoları, daha sonra test senaryolarına dönüştürülmüştür.
Öğrenci kayıtlanma ekranları kullanıcı deneyim kriterleri göz önünde bulundurularak yeniden tasarlanmıştır. Ekranların tasarımında basitliğe ve kullanım kolaylığına dikkat edilmiştir. Ekranlarda etkin görselliği yakalamak için ağırlıklı olarak CSS3[11]
teknolojisi kullanılmıştır.
Şekil 2. UML sınıf diyagramından bir bölüm
Şekil 4. Örnek Kayıt Ekranı
Üniversite sistemindeki kullanıcı sayısı (Öğrenciler, Akademisyenler, Öğrenci İşleri İdari Personel) 45.000’in üzerinde olduğu ve kayıtlanma modülü, ekranlar dahil baştan geliştirildiği için kayıtlanma modülü eğitim videoları BAUM test departmanı tarafından oluşturulmuş ve ilgili web ekranlarına kısa yolları yerleştirilmiştir. Eğitim videolarının toplam izleyici sayısı yaklaşık 13.000’dir.
Yazılım geliştirme sürecinde sürekli dikkat edilen bazı önemli noktalar ve yapılan genel performans iyileştirmeleri aşağıdaki gibi özetlenebilir:
Web sayfalarının ebatları minimum seviyede tutulmuştur.
Sunuculara giden toplam istek (request)
sayısı olabildiğince azaltılmıştır.
Yük optimizasyonu için harici CDN'ler kullanılmıştır.
Java script dosyaları minify edilmiştir.
Java script dosyaları, CSS dosyaları, resim dosyaları gibi statik içeriğe sahip dosyalar cachlenmiştir.
4. Deneysel Sonuçlar
Kayıtlanma modülü 15 Eylül 2014 saat 10:00’da devreye alındıktan sonra i lk 3 0 d a k i k a d a gözlemlenen metrikler aşağıdaki gibidir:
Toplam 33.274 öğrenci sisteme girmiştir.
Toplam 272.387 ders seçilmiştir.
Ortalama sistem cevap verme süresi (Average Response Time) 0,8 sndir.
Ortalama web sunucu yoğunluğu (CPU)
%10 dur.
Ortalama servis sunucu yoğunluğu (CPU) %12 dir.
Ortalama veritabanı sunucu yoğunluğu (CPU) %8 dir.
Sistemi devreye alınmadan önce modülün kodlama ve test sürecinde yaklaşık 40 hata tespit edilmiş ve çözülmüştür. Sistem devreye alındıktan sonraki 2 hafta kullanım sürecinde yazılım modülü ile ilgili hiç hata çıkmamış olup sadece 1 tane geliştirme yapılmıştır.
5. Tartışma ve Öneriler
Teknolojinin hızla ilerlediği bu dönemde üniversitelerde kullanılan yazılım otomasyon sistemlerinin bu duruma ayak uyduramaması önemli bir problemdir. Bu duruma ilave olarak; üniversitelerin Bilgisayar Bilimleri, Bilgisayar Mühendisliği, Yazılım Mühendisliği ve Bilgisayar Programcılığı gibi bölümleriyle bu sektör için uzman personel yetiştirdiğini düşünürsek, olay farklı bir boyut almakta ve maalesef “Terzi kendi söküğünü dikemiyor” sonucu ortaya çıkmaktadır.
Tecrübe aktarımı niteliğindeki bu bildiride, CBÜ BAUM tarafından geliştirilen Yeni Kayıtlanma Modülünün geliştirme süreçleri ve detayları hakkında bilgilendirme yapılmıştır.
Deneysel sonuçlarda da görüldüğü üzere hayata geçirilen bu modül, 33.000 kullanıcının üzerinde yoğun bir kullanıma rağmen, yüksek sistem performansı ve sıfır hata sayısı ile ciddi bir başarı elde etmiştir.
Hem yazılım performans metrikleri hem de öğrencilerden gelen olumlu geri dönüşler dikkate alındığında üniversitelerin 100.000’lerce kullanıcıyı kaldırabilecek kaliteli yazılım ürünü geliştirmelerinin hayal olmadığı ortadadır.
Kaynaklar
[1] Nermin SÖKMEN, Türkiye’de Yazılım Üreticilerinin Yetkinlik Düzeyi, Firmaların ve
Sektörün Gelişimi cilt 1, TUBITAK, BILGEM.
[2] Celal Bayar Üniversitesi tanıtımı, h tt p :/ / ww w .c b u .e d u .t r , E rişim tarihi:
01/09/2014
[3] Yükseköğretim Kurulu (YÖK) tanıtımı, h tt p :/ / ww w . y o k . g o v .t r , E rişim tarihi:
03/09/2014
[4] Agile Türkiye, 2013 Software Production Report. h tt p :/ / ww w . a g ile t u r k e y . or g / ( 2013) [5] Sutherland, J., Jakobsen, C.R., Johnson, K.: Scrum and CMMI Level 5: The Magic Potion for Code Warriors. In: Proceedings of the 41st Annual Hawaii International Conference on System Sciences (2008) [6] Livermore, J. A.: Factors that impact implementing an agile software development methodology. In: SoutheastCon Proceedings, IEEE, pp. 82- 86 (2007)
[7] Pikkarainen, M., Haikara, J., Salo, O., Abrahamsson, P., Still, J.: The impact of agile practices on communication in software development. Empirical Software Engineerging, 13 (3), pp. 303-337. (2008) [8] Microsoft Team Foundation Server, h tt p :// e n . w i k i p e d ia .or g / w i k i / T e a m _ F ou n d atio n _ Se r v e r , E rişim tarihi: 01.10.2014
[9] ISTQB test prensipleri, h tt p :/ / s o f t w a re - tes
t i ng . p l/ e n / b asi c s - o f - s o f t w a r e - tes t i n g / s e v e n - tes
t i n g - pr i n ci p l e s - b y - i s t q b , E rişim tarihi:
02.10.2014
[10] Celal Bayar Üniversite ÖnLisans ve Lisans Eğitim ve Öğretim Yönetmeliği, h tt p :/ / ww w . b a y a r .e d u .tr/ o g r e n ci/ o n li s a ns _ v e_
li
s a n s _ e g i ti m _ v e _o g r et i m _ y o n e t m el i g i _ y e n i.
p h p , E rişim tarihi: 05.10.2014
[11] CSS3 teknolojisi ile ilgili genel tanıtım, h tt p :/ / ww w . w 3 s c h oo l s .c o m /c s s /cs s 3_ i n tr o .asp , Erişim tarihi: 02.10.2014
