Servis Tabanlı Kurumsal Yazılım Gelitirilmesinde XP Kullanımı ve Eletirisi Ensar GÜL 1, Ünal YILDIRIM 2 1 Avrupa Yazılım, Tübitak Mam Tekseb A Blok No: 201 Gebze, Kocaeli 1 eposta: ensar.gul@avrupayazilim.com Özet Bu bildiride, yazılım gelitirmede kullanılan Uç Programlama Extreme Programming (XP) yaklaımının servis tabanlı kurumsal yazılımlarının gelitirilmesinde kullanılmasının dourduu pratik sonuçlar anlatılmı ve XP ye eletirel bir bakı açısı getirilmitir. Abstract In this paper the practical results of applying Extreme Programming(XP) in the development of an enterprise application using service oriented architecture are presented and XP methodology has been criticized. 1. Giri Uç Programlama Extreme Programming (XP), kaliteli bir yazılımı, mümkün olan en kısa sürede gerçekletirmeyi hedefleyen, bir dizi, deer, kural ve uygulamadan oluan bir yazılım gelitirme yöntemidir. XP, yazılım projelerinde riskleri azaltan, projenin ortamdaki deiimlere en iyi ekilde uyum salamasına izin veren ve sistem yaam döngüsü kapsamında verimlilii ön planda tutan çevik bir yöntem olarak kabul edilmektedir[1]. XP hakkında ayrıntılı bilgi için [2,3,4,5,6] kaynaklarına bakılabilir. Fakat uygulamada XP nin bu iddialarının her zaman ve ortamda gerçeklemedii gözlenmitir. Bu bildiride geni ölçekli bir kurumsal yazılımın gelitirilmesinde uygulanan XP yaklaımından kazanılan deneyimler anlatılacaktır. Bildirinin ikinci bölümünde XP`nin kullanıldıı yazılım hakkında bilgi verilmi, üçüncü bölümde bu yöntemin servis tabanlı kurumsal yazılım gelitirilmesinde uygulanması ve karılaılan güçlükler anlatılmı, dördüncü bölümde ise sonuçlar tartıılmıtır. 2. Tedarikçi Yönetim Sistemi (TYS ) Proje Kapsamı Yazılımın gelitirildii kurum, üretime yönelik hammadde ve yarı mamul alımları ile satı destek (promosyon) malzemelerinin yurt içi alımlarını Satın Alma Koordinatörlüü ve bu koordinatörlüe balı 18 Satın Alma Müdürlüü ile gerçekletirmektedir.
Satın Alma Müdürlükleri stok takibi, talepleri izleme, sipari açma gibi operasyonel ilemlerini gerçekletirmek için AS-400 sistemini kullanmaktadırlar. Satın almanın yanı sıra malzeme yönetimi, kalite kontrol, üretim planlaması, satı ve muhasebe gibi temel iletme ihtiyaçlarını karılamaya yönelik olarak gelitirilen AS-400 Sistemleri her irkette birbirinden baımsız olarak çalımaktadır. TYS öncelikle tedarikçi ve malzeme fiyatı onaylama süreçlerini elektronik ortama taımayı ve böylece bu süreçleri kayıt altına alıp, daha verimli izlenebilir bir hale getirmeyi hedeflemektedir. kinci olarak TYS intranet aracılıı ile tüm irketlerin ortak olarak kullanacaı ve katkıda bulunacaı bir bilgi tabanı olarak karar alma sürecinde Satın Alma Müdürlüklerine destek niteliindedir. TYS malzeme ihtiyaçlarını belirleme, talep yaratma, sipari açma ve malzeme kabul etme gibi operasyonel ihtiyaçlara bu versiyonda cevap vermemektedir. Sistemin kapsamı, tedarikçi ve fiyat onaylama süreçleri çevresinde satın alma karar destek ortamına gerekli bilgi daarcıını oluturmak ve bunun tüm grup irketleri arasında paylaılmasını salamaktır. Bu amaçla sistemin u fonksiyonları gerçekletirilmitir: a. Genel Kullanıcı lemleri b. Tedarikçi Bilgileri Gir/Güncelle c. Tedarikçi Onayla d. Malzeme Bilgileri Gir/Güncelle e. Malzeme ve Fiyat Belirle f. Satın Almayı Onayla g. Sistemi Yönet h. Rapor Çek Tedarikçi likileri Yönetim Sistemi ile; satın alma sürecinde farklı birimlerden/irketlerden toplanan bilgilerin paylaıma açılması, onay süreçlerinin elektronik olarak kayıt/gözlem altına alınması ve bu yolla satın alma kararlarının verilme sürecinde önemli bir verimlilik ve kontrol artıı salanması hedeflenmektedir. 2.1. Proje Teknik Yapısı Ürün bir Java uygulaması olarak, J2EE teknolojileri kullanılarak, çok-katmanlı (multi-tier) mimari yaklaım ile tasarlanmıtır. Platform baımsızlık (Unix, Windows, Linux), veritabanı baımsızlık (Oracle, DB2, mysql, postgresql, DB2400, Sybase, vb.) ve uygulama sunucusu baımsızlık ürünün ana özellikleri olarak planlanmıtır. Uygulamanın genel katmanları ekil 1'de görülmektedir. Uygulama web, mobil telefon ve masa üstü kullanıcılarını destekleyecek ekilde tasarlanmı ancak u ana kadar sadece web arayüzü gerçekletirilmitir. TYS sistem mimarisi, MVC (Model View Controller) modeline uygun bir ekilde, modüler yapıya sahip olacak ekilde ve esnek bir veri modeli üzerine kurulmutur. Kullanıcı ön yüzü deiik ara birimlerden olabilecei gibi, ilk tasarım web uygulaması olarak yapılmıtır. Sunucu kısmında i mantıı modüler bir yapıya bölünmü, dıarıdan ve içerden çarılabilecek servisler üzerine kurulmutur. Kalıcı Nesneler (Persistent Object) tabakasında `hibernate`[7] kullanılarak JDBC API
karmaası uygulamadan soyutlanmı; veri modeli, kavramsal ve fiziksel olmak üzere iki seviyede normalize bir ekilde tasarlanmıtır. Kullanıcı ara yüzü alt yapısı olarak JSF[8] kullanılmıtır. Uygulamanın alt yapısında Spring[9] yapısından faydalanılarak, singleton sınıflar uygulama balangıcında oluturularak tek bir yerden yönetimi salanmıtır. Uygulamanın çoklu dili desteklemesi amacıyla özellikler (properties) dosyaları kullanılmıtır. Uygulamadaki veri tabanı ilemlerin bütünlüü için bir ilem yöneticisi (Transaction Manager) ve servislere eriim için servis yöneticisi kullanılmıtır. Uygulamada kullanıcıya hata mesajlarının gösterilmesinde çoklu dil desteklenmi ve hata mesajları sınıflandırılmıtır. Genel amaçlı kullanılacak sınıflar ve arayüzler common, share ve util gibi paketlere ayrılmıtır. Bütün uygulamada gelitirme, test ve üretim aamasındaki log mesajlarının ayrılması için log4j kullanılmıtır. Gelitirilen yazılım yaklaık 180K satırdan olumaktadır. Mobil Swing Java Web Start Web stemci Güvenlik Tabakası(Security Layer) Web Servisleri JSP/JSF/Struts Servis Katmanı (Service Layer) Veri Modeli Katmanı (Data Model Layer) Nesne Veritabanı likilendirme Katmanı (Object Relational Mapping Layer) Hibernate Toplink JDO Dier Veritabanı Oracle DB2 AS400 Dier ekil 1. Yazılım Mimari Katmanları
3. XP Uygulaması ve Karılaılan Zorluklar Yazılım gelitirme sürecince sürümler iki hafta olarak planlandı. Proje ekibinde 14 kii görev aldı. Bu kiiler 7 çift olarak programlama yaptılar. 5. sürümün sonunda yazılım bitirilmesi hedeflenmiti. Bazı eksiklere ramen bu sürenin sonunda çalıan bir yazılım üretildi. Aaıda XP prensiplerinin uygulması konusunda karılaılan zorluklar ve bu balamda XP ye getirdiimiz eletiriler sıralanmıtır. Planlama ve küçük sürümler XP çerçevesinde ilk sürümlerde çalıır bir programın iskeletinin çıkarılması kolay deildir. Özellikle karmaık sistemlerde sistemin tümününe hakim olunması, i parçalarının tanımlanması, bunların gerçekletirilmesi XP nin iddia etti gibi kolay olmamaktadadır. Gelitirdiimiz uygulamada veri eriim katmanı, servis katmanı, GUI`de kullanılan teknolojiler balı baına uzmanlık gerektiren, örenilmesi zaman alan teknolojilerdir. Bunların hepsinin yazılımcılar tarafından iyi derecede örenilmesi ve verimli bir ekilde kod üretilmesi zaman kaybına yol açmaktadır. ler yapıldıkça sürekli yeni iler ortaya çıkmaktadır. Bu da proje ile ilgili salıklı bir tahmin yapılmasını zorlatırmaktadır. lk bata yaklaık 300 adet i birimi (task) planlanmı iken yazılım süreci boyunca bu i birimi sayısı artarak yaklaık 700 adet olmutur. Ayrıca buna ek olarak yaklaık 600 adet deiiklik ya da hata eklenmitir. Eli Programlama ( Pair Programming ) Yazılım sırasında balangıçta % 80 oranında eli programlama (pair programming) kullanılmı, sona doru rotasyonun getirdii uygulama zorlukları nedeni ile bu oran % 20 ye kadar dümütür. Eli programlamada karılaılan zorluklar: Sürekli e deiimi nedeni ile yazılım güçlükleri ortaya çıkmıtır. Kiilerin yaptıkları iler yarım kalmıtır. Yarım kalan ileri eler arasında paylatırmak sorun olmutur. Yazılımcıların çalıma alanlarının belli olmayıı herhangi bir alanda uzmanlamayı engellemitir. (Bu durum sık sık e deitirilmesinden kaynaklanmıtır). Bir iin iki kiiye aynı anda verilmesi, kiilerde sorumluluk duygusu olumamasına neden olmaktadır. Bir iten iki kiinin sorumlu olması, kiilerin i hakkında karar verme ve uygulamaya geçme hakkını kendilerinde görememesine neden olmaktadır. yapıldıktan sonra hangi ii kimin yaptıının tam olarak belli olmayıı hataların sorumlusunun tam olarak anlaılamamasına neden olmaktadır. Sonradan hangi ii kimin yaptıının tam olarak bilinmemesi baarı deerlendirilmesi konusunda salıklı ve somut veri bulunmamasına neden olmaktadır.
lerin deiik parçalarının deiik eler tarafından yapılması, iler arasında kopuklua neden olmaktadır. lerin deiik kiiler tarafından yapılması ve bir iin iki kiiye paylatırılması ilerin hızlı ve verimli yapılması ile çelimektedir. 3.1. Ortak Kod Sahiplii Yazılım büyük ölçekli olduu için bir sürüm boyunca ilerin tanımlanması hayli zor olmutur. Özellikle kısa süreli iler bulmak ve tanımlamak kolay olmamaktadır. Bazı i parçaları sürüm süresi boyunca devam etti. Bu süre sonunda eer verilen i eksik kaldıysa, bundan sonraki sürümde farklı bir çift programcıya verildi. Yeni ii alan programcılar yazılan kısımları örenmek ve bunun üzerine kod yazabilmekte zorlandılar. Ortak kod sahiplii yazılımcıların çıkan sorunları ve eksikleri sahiplenmemesine yol açmaktadır. 3.2. Ayaküstü toplantılar Bu toplantılar çok faydalı olmaktadır. Bu toplantılarda alınan, yazılımda uygulanacak yöntemlere ilikin önemli teknik kararlar, yazılı hale getirilerek yayımlanmalıdır. Aksi halde bu yöntemlerin uygulanmasında zorluklar ortaya çıkmaktadır. 3.3. Birim Testler (Unit Testing ) Gelitirilen yazılıma her yazılımcı müdahale edebilmektedir. Bir çift yazılımcının yaptıı hatanın bütün sistemi etkilememesi ve sistem entegrasyonun bozulmaması içim birim testler yapılmalıdır. Veri tabanı içeren sistemlerde yazılım veri tabanını deitirdii için, birim testlerinin yazılması zor olmutur.veri tabanı baımsız olan modüller için birim testler yazılmı olup, bunun için junit kullanılmıtır. 3.4. Yeniden Yapılandırma (Refactoring ) XP, yazılım mimarisinin önceden belirlenmedii, sürekli yapılan yeniden yapılandırmalarla nihai mimarinin ve yazılım yapısının ortaya çıkmasını hedefliyor. Biz bu konuda üst seviye bir mimari tasarımın olmasının daha faydalı olduunu düünüyoruz. Bu yaklaımımızla belirsizliklerin biraz daha azaltılmasını hedefledik. Hemen kodlamaya balamak ve korkmadan yazılan bölümleri çöpe atmak pratikte söylenildii kadar kolay olmamaktadır. Yazılım ortaya çıkmaya balayınca çeitli nedenler, örnein bazı modüllerin yava çalıması, yeniden yapılandırılacak kısımları belirlemektedir. Bu kısımlar tamamen atılarak veya yeniden yazılarak müterinin istedii ürün ortaya çıkmaktadır. Yeniden yapılandırma sırasında, sürümün tamamen bitirilmesi ya da sürüm tam olarak bitmiyor ise bile dondurularak genel bir yeniden yapılandırma için zaman ayrılmalıdır. Sürüm sonunda yazılımın tam olarak dondurulamadıı durumlarda sorun yaanmıtır.
3.5. Müteri ile birlikte çalıma XP bir müteri temsilcisinin sürekli programcılarla birlikte çalımasını öngörüyor. Bu erken geri besleme açısından çok faydalıdır. Hatta analiz aamasında sadece analizcilerin degil bütün programcıların bir ölçüde analiz çalımalarına katılması ve iin bütününü görmesi program gelitirirken ilerini kolaylatıracaktır. 4. Sonuçlar Gelitirdimiz yazılımda sürüm (iteration) süresi 2 hafta olarak planlanmıtı. Her sürüm sonunda olgunlamı ilerin ortaya çıkması için bu sürenin yeterli olmadıı gözlendi. Proje boyunca gerekirse sürüm süresi deitirilmeli, fakat önceden belirlenmi en fazla süreyi, örnein 3 haftayı, amamalıdır. Veri tabanı üzerinde birim testlerin zorluu nedeni ile bu testlerin verimli kullanılması mümkün olmamaktadır. Yazılımcıların çalıma alanlarının sürekli deimesi, nedeni ile herhangi bir alanda uzmanlamayı engellemektedir. XP de rotasyon yapılması yazılımı güçletirmektedir. Eli programla, herhangi iki kiiden birisinin ayrılması durumunda, bilgi birikiminin korunmasını yeterince salamaktadır. Fakat rotasyon yapılmasının i gücü kaybına neden olacaı göz önüne alınmalıdır. Mutlaka e deiimi yapılacak ise bu küçük gruplar içinde olmalıdır. Proje süresince bir iin sorumlusu mümkün olduu kadar sabit kalmalıdır. Eer iin sorumlusu sık sık deiir ise, i ile ilgili yapılmayan bölümün sorumluluunu alamamaktadır. XP ile projenin ne kadar süreceini tahmin etmek zordur. Bu, metodolojinin kendisinden kaynaklanmakadır. Sürekli yeniden yapılandırma ile sonuca varılmaya çalıılmakdadır. Yapılan yeniden yapılandırmanın, projeye nasıl etki edecegi ve projenin ne kadar sürecei tahmin edilememektedir. Karmaık sistemleri iyi tanımlı alt bölümlere ayırarak XP nin uygulanması faydalı olabilir. Sistemin tümüne birden XP uygulanması beklenen faydaları salamamıtır. Dier yazılım metodolojileri gibi XP de her kapıyı açan bir anahtar deildir. Kullanılmadan önce getirecei olumlu ve olumsuz sonuçlar düünülmeli, gerekirse projeye has yeni bir metodoloji kullanılmalıdır.
5. Kaynakça 1. Telekomünikasyon Yazılımlarının Gelitirilmesinde XP Yaklaımı, Taylan ekerci, Aziz Can Yücetürk, Ensar Gül, UYMS 2003, zmir. 2. Beck, K., Extreme Programming Explained: Embrace Change, Addison Wesley, 2000, ISBN: 0201616416. 3. Jeffries, R., Anderson, A., Hendrickson, C., Extreme Programming Installed, Addison Wesley, 2001, ISBN: 0201708426. 4. http://www.xprogramming.com/ 5. Exreme Programming FAQ, http://www.jera.com/techinfo/xpfaq.htm 6. The new Methodology, Martin Fowler, http://www.martinfowler.com/articles/newmethodology.html 7. www.hibernate.org 8. Java Server Faces, http://java.sun.com/j2ee/javaserverfaces/reference/api/index.html 9. www.springframework.org