Çevik bir Hikâye: Celal Bayar Üniversitesi Öğrenci Kayıtlanma Modülü Bu Dönem Neden Çökmedi?

Transkript

1 inet-tr 14 - XIX. Türkiye'de İnternet Konferansı Bildirileri Çevik bir Hikâye: Celal Bayar Üniversitesi Öğrenci Kayıtlanma Modülü Bu Dönem Neden Çökmedi? Onur Leblebici, Deniz Kılınç, Ceyhun Araz, Cihan Demirel, Bora Gürsel, Seda Görmez Celal Bayar Üniversitesi, Bilgisayar Araştırma ve Uygulama Merkezi, Manisa onur.leblebici@cbu.edu.tr, deniz.kilinc@cbu.edu.tr, ceyhun.araz@cbu.edu.tr, cihan.demirel@cbu.edu.tr, bora.gursel@cbu.edu.tr, seda.gormez@cbu.edu.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, 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 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 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]. 85 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

2 Çevik bir Hikâye: Celal Bayar Üniversitesi Öğrenci Kayıtlanma Modülü Bu Dönem Neden Çökmedi? Onur Leblebici, Deniz Kılınç, Ceyhun Araz, Cihan Demirel, Bora Gürsel, Seda Görmez 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 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. 86 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 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 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 Güz kayıtlanma döneminde bu yeni kayıtlanma sistemi hayata geçirilmiş ve 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

3 geri dönüşler dikkate alındığında üniversitelerin 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üreci 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 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. 87 inet-tr 14 - XIX. Türkiye'de İnternet Konferansı Bildirileri Ş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

4 Çevik bir Hikâye: Celal Bayar Üniversitesi Öğrenci Kayıtlanma Modülü Bu Dönem Neden Çökmedi? Onur Leblebici, Deniz Kılınç, Ceyhun Araz, Cihan Demirel, Bora Gürsel, Seda Görmez 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 Ortamı: Sadece yazılım geliştirmenin yapıldığı ve yazılım uzmanlarının kendi temel testlerini yaptıkları ortamdır. (2) Test Ortamı: 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 Ortamı: Ü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. 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: 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 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ığı-

5 inet-tr 14 - XIX. Türkiye'de İnternet Konferansı Bildirileri 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. Şekil 3. Kod haritası Toplam 210 tane kullanım senaryosu (usecase) çı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 Ö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. 89 Şekil 4. Örnek Kayıt Ekranı Üniversite sistemindeki kullanıcı sayısı (Öğrenciler, Akademisyenler, Öğrenci İşleri İdari

6 Çevik bir Hikâye: Celal Bayar Üniversitesi Öğrenci Kayıtlanma Modülü Bu Dönem Neden Çökmedi? Onur Leblebici, Deniz Kılınç, Ceyhun Araz, Cihan Demirel, Bora Gürsel, Seda Görmez Personel) 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 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 ilk 30 dakikada gözlemlenen metrikler aşağıdaki gibidir: 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, 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 lerce kullanıcıyı kaldırabilecek kaliteli yazılım ürünü geliştirmelerinin hayal olmadığı ortadadır. Toplam öğrenci sisteme girmiştir. Toplam 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. 90 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, BIL- GEM. [2] Celal Bayar Üniversitesi tanıtımı, Erişim tarihi: 01/09/2014 [3] Yükseköğretim Kurulu (YÖK) tanıtımı, Erişim tarihi: 03/09/2014 [4] Agile Türkiye, 2013 Software Production Report. (2013)

7 inet-tr 14 - XIX. Türkiye'de İnternet Konferansı Bildirileri [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 (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 (2008) [9] ISTQB test prensipleri, testing-principles-by-istqb, Erişim tarihi: [10] Celal Bayar Üniversite ÖnLisans ve Lisans Eğitim ve Öğretim Yönetmeliği, lisans_egitim_ve_ogretim_yonetmeligi_yeni. php, Erişim tarihi: [11] CSS3 teknolojisi ile ilgili genel tanıtım, Erişim tarihi: [8] Microsoft Team Foundation Server, en.wikipedia.org/wiki/team_foundatio n_server, Erişim tarihi: