Özet Yazılım evrimi alanında, açık kaynak yazılım geliştirmeden daha zengin veri içeren endüstriyel yazılımlar üzerinde daha fazla ampirik araştırma yapılmasına ihtiyaç vardır. Bu çalışmada, Yazılım Depoları Madenciliği (YDM) teknikleri kullanılarak endüstriyel bir yazılımın evrimi analiz edilmiştir. Veri kaynağı olarak kaynak kod depoları, hata depoları ve iletişim arşivlerini kullanmaya odaklanan mevcut çalışmaların aksine, bu araştırma Kurumsal Kaynak Planlama, Konfigürasyon Yönetimi Veritabanı ve İnsan Kaynakları (İK) sistemlerini kullanır. Bu sistemler, yazılımcı deneyimi, yazılım bakımı için harcanan süre, efor tipi gibi veriler içerir. Bu verileri bu çalışma kapsamında incelenen yazılımın kaynak kod deposundan alınan ve her bir değişikliğin detaylarını içeren verilerle birleştirdik. Daha sonra bu birleştirilen veriler üzerinde kontrol grafikleri, Spearman korelasyon ve ANOVA testleri gibi çeşitli istatistiksel analizler uyguladık. Çalışmamızın sonuçları, incelenen yazılımın bakım/evrim fazında yazılımcı deneyimi ve fazla mesainin verimlilik üzerinde etkileri olduğunu gösterdi. Buna karşın kaynak kodun karmaşıklığı ve bağımlılığı (coupling) üzerinde herhangi bir önemli (significant) etkisi gözlenmedi. Ayrıca, süreç ve ürün metrikleri arasında yapılan korelasyon analizi bazı önemli yazılım eğilimlerini ortaya çıkardı.
odaklanmıştır [
Bu çalışmada, endüstriyel bir yazılım üzerinde ampirik bir araştırma gerçekleştirildi. Bakım fazındaki bir finansal yazılım bileşeninin son 2 yıllık verileri analiz edildi. Yazılımın nasıl evrildiği konusunda detaylı ve doğru bilgi edinebilmek için YDM teknikleri kullanıldı. Bu çalışma kapsamında kullanılan yazılım depoları şunlardır: Konfigürasyon Yönetimi Veritabanı (KYVT), Kurumsal Kaynak Planlaması (KKP), İnsan Kaynakları (İK) sistemi ve kaynak kod deposudur. Bu yaklaşım, ana veri kaynağı olarak daha önce sözü edilen yazılım depolarını kullanmaya odaklanmış mevcut YDM araştırmalarından farklıdır.
YDM teknikleri ile farklı yazılım depolarından toplanan verileri birleştirerek, çalışmamızda şu sorulara cevap vermeye çalışacağız: S1 Yazılım evriminde hangi ürün ve süreç metrikleri arasında korelasyon vardır? S2 Yazılımın bakımını yapan yazılımcıların deneyiminin verimlilik üzerinde etkisi var mıdır? S3 Fazla mesainin verimlilik üzerinde etkisi var mıdır? S4 Yazılımın bakımını yapan yazılımcıların deneyiminin kaynak kod karmaşıklığı ve bağımlılığı (coupling) üzerinde etkisi var mıdır? S5 Fazla mesainin kaynak kod karmaşıklığı ve bağımlılığı (coupling) üzerinde etkisi var mıdır? Çalışmamızın sonuçları, incelenen yazılımın bakım/evrimi fazında yazılımcı deneyimi ve fazla mesainin verimlilik üzerinde etkileri olduğunu gösterdi. Buna karşın kaynak kodun karmaşıklığı ve bağımlılığı üzerinde herhangi bir önemli (significant) etkisi gözlenmedi. Ayrıca, süreç ve ürün metrikleri arasındaki korelasyon analizi sonucunda, raporlanan hata sayıları ve hata düzeltme, destek faaliyetleri için harcanan efor için artış eğilimi saptandı. Sonuçlar, aynı zamanda kaynak kodun bazı parçalarının yeniden düzenlenmesi (refactoring) ihtiyacını ortaya çıkarmıştır. 2
İlgili Çalışmalar
Manny Lehman’ın araştırmaları ve ortaya koyduğu sekiz yasa yazılım evrimi
araştırmalarının temelini oluşturmaktadır. Lehman’ın ampirik çalışmaları
yazılım değişikliklerine ve yazılım evriminin doğasına odaklanmıştır. Yazılım sistem
evrimini analiz etmek için oluşturulan yaklaşımlar kullanılan veri ve veri
kaynaklarına göre değişiklik gösterirler [
Literatürde endüstriyel yazılımlar üzerinde yapılmış çeşitli vaka incelemeleri
de vardır. Gall [
Literatürde KYVT [
Çalışmamızda, versiyon geçmişi, hata/istek raporları, yazılımcı efor ve
deneyim verileri sırasıyla kaynak kod deposu, VYVT, KKP ve İK veri kaynakları
kullanılarak elde edilmiştir. Çalışmamızda, yazılım evrimi konusunda
tanımlanan iki açık noktaya [
Endüstriyel yazılımlar hakkında daha fazla deneysel araştırma ihtiyacı, ve Daha çeşitli yazılım depolarından veri kulanımı ve entegrasyonu Çalışmamızda geliştirilen adaptörler, SPSS betikleri (scripts) ve Yazılım Evrimi Kontrol Aracı (YEKA) prototipi sayesinde yapılan analizler tek bir kereye mahsus olmamakta ve sürekliliği sağlanmaktadır. Analiz için sürdürülebilir bir çözüm sağlaması çalışmamızın diğer bir katkısıdır. 3 3.1
Şekil 1 yaklaşımımızın özetini sunar. Farklı veri kaynaklarından veri
toplayabilmek için dört adaptör geliştirdik: KYVT adaptörü, KKP adaptörü, İK adaptörü
ve CA SCM adaptörü. Adaptörler basit bir arayüze sahiptir ve verilen tarih
aralığına göre veri kaynağını sorgular. CA SCM adaptörü belirtilen tarih aralığında
yapılan kaynak kod değişiklikleri ve kaynak kodun kendisini alabilmek için CA
SCM SDK (Yazılım Geliştirme Kiti) kullanır. KYVT, İK ve KKP adaptörleri
Java veri erişim teknolojisi olan JDBC (Java Database Connectivity) [
VAD dosyaları veri işleme ve ölçüm için Yazılım Evrimi Kontrol Aracına
(YEKA) girdi olarak verilir. YEKA üç modülden oluşmaktadır: VAD Modülü,
Metrik Modülü ve PMD [
Şekil 1: İzlenen Yaklaşım
aracıdır. PMD ile analiz için kaynak kodun derlenmesine gerek olmadığından
çok esnek ve verimli bir çözüm sağlar. Metrik Modülünün bir diğer önemli rolü
ise farklı veri kaynaklarından toplanan ilişkili verilerin eşleştirilmesidir.
Örneğin, KKP sisteminden alınan bir efor kaydı ile kaynak kod deposundan alınan
bir ya da birkaç kaynak kod değişikliği birbiriyle ilişkilendirilmelidir. Bu eşleşme
Metrik Modülü tarafından gerçekleştirilir. Çalışmamızda istatistiksel analizler
için SPSS Statistics [
Bu çalışmada kullanılan metrikler üç kategoriye ayrıldı: ürün, süreç ve kaynak metrikleri. Aşağıdaki bölümlerde, ilk olarak taban metrikler daha sonra da bu taban metrikler kullanılarak oluşturulan türetilmiş (derived) metrikler anlatılmaktadır. Ürün Metrikleri Kaynak kod evrimini izlemek amacıyla, literatürde nesne yönelimli programlama için tanımlanmış aşağıdaki metrikler taban metrik olarak kullanılmıştır:
Boyut ölçümü ve elde edilen metriklerin normalizasyonu için NCSS metriği kullanılmıştır. Ayrıca kontrol grafikleri üzerinde yazılım evrim verisindeki kontrol-dışı noktaların tespiti için NCSS kullanılmıştır. Diğer metrikler korelasyon analizi sonuçlarına göre seçilmiştir. Metot seviyesinde hesaplanabilen bir metrik olan CC metriğini sınıf seviyesinde kullanmak için, bir sınıfın tüm metotları için ayrı ayrı ölçülen CC değerlerinin ortalaması alınmıştır.
Sınıf seviyesindeki metrikler ile korelasyonlarını kontrol etmek için, iki metot seviyesi metriği de çalışmaya dahil edilmiştir: CCMetotMax ve NCSSMetotMax. Bu iki metrik ile sınıfların boyut ve karmaşıklık açısından en büyük metotlarının evrim eğilimlerini tespit etmeyi hedefledik:
Sadece değişikliklerin etkilerini ölçmek amacıyla, tüm kaynak kod metrikleri için (Delta) metrikleri tanımlanmış ve analizler bu delta değerleri üzerinde gerçekleştirilmiştir.
Bu yaklaşımımızı şu şekilde formüle ettik. wi yazılımın bakım fazındaki i nolu haftayı temsil eder, ti i nolu haftanın başlangıç tarihini gösterir, cij i nolu haftada değiştirilen j nolu Java sınıfını gösterir, m wi haftasında değiştirilen tüm sınıfların sayısını temsil eder. CC(ti; cij ), cij sınıfının ti tarihindeki karmaşıklığını göstermektedir. Bu tanımlara dayanarak, belirli bir hafta wi ve o hafta içerisinde değiştirilen sınıfların listesi 0’dan m’e kadar kullanılarak o hafta için Delta CC metriği şu şekilde hesaplanır:
CC(wi) = m X(CC(ti; cij ) j=0
CC(ti 1; cij ))
Benzer şekilde, diğer metrikler için Delta tanımları yapılır.
Süreç Metrikleri Kaynak kod metriklerine ek olarak, yazılım bakım/evrim süreçleri için de metrikler tanımlanmıştır:
NoF ve NOER ölçümleri KYVT’den elde edilmiştir. Efor metrikleri (CorrEf ve EnhcEf) KKP sisteminden elde edilir. Efor metrikleri için iki kategori tanımlamıştır: Fazla mesai ve normal mesai. Fazla mesai, günlük 8 saati geçen çalışmaları ve hafta sonu çalışmalarını kapsamaktadır. Verimlilik ölçümü için eforlar toplanırken, en az bir fazla mesai girişi içeren efor toplamlarını fazla mesai olarak sınıflandırıldık. Bunun dışındaki efor toplamları normal olarak sınıflandırıldı. Bu veriler, 3 ve 5 nolu araştırma sorularını cevaplandırmak için kullanıldı.
Ürün ve süreç taban metriklerini kullanarak, araştırma sorularını yanıtlamak için aşağıdaki türetilmiş metrikler tanımlanmıştır:
Verimlilik ölçümü için üç temel husus ele alınmıştır: kaynak kod ölçümleri ile efor ölçümlerinin eşleştirilmesi, verimlilik hesaplamasına dahil edilecek efor kategorileri, verimlilik ölçümünün yapılacağı periyot (haftalık, günlük, vb.). Değişiklik tarihi (hafta numarası), yazılımcı ve proje bilgilerini kullanarak girilen efor ile kaynak kod deposuna aktarılan (check-in) değişiklikleri eşleştirdik. Verimlilik hesaplamasına dahil edilecek efor kategorisi olarak kodlama seçildi. Testler ve yönetim için harcanan efor verimlilik hesaplamasında kullanılmadı. Verimlilik ölçümünün hafta bazında yapılmasına karar verdik, böylece kaynak kodun eforun harcandığı gün kaynak kod deposuna aktarılmadığı durumların büyük ölçüde üstesinden geldik.
Türetilmiş metriklerin hesaplanması için aşağıdaki denklemler kullanılmıştır: BirimCCArtisi(wi) =
CC(wi)
N CSS(wi) BirimCBOArtisi(wi) =
CBO(wi)
N CSS(wi) V erimlilik(wi) =
N CSS(wi)
EnhcEf (wi)
Yazılımcı deneyiminin ve fazla mesainin türetilmiş metrikler üzerindeki etkisini bulmak için, yazılımcı ve fazla mesai özelliklerine göre gruplandırılma yapılmıştır. Bu ölçümler, 2., 3., 4. ve 5. araştırma sorularını cevaplandırmak için kullanılmıştır.
Kaynak Metrikleri Yazılımcı deneyimi için aşağıdaki metrik tanımlanmıştır:
Bu metrik için yapılan ölçümler İK sisteminden elde edilmiş, 2. ve 4. araştırma sorularını cevaplamak için kullanılmıştır.
Daha önce yapılan çalışmalara dayanarak yazılımcı deneyimi için üç kategori
tanımladık [
Sıfır Hipotezleri 2 ile 5 arasındaki soruları yanıtlamak için sırasıyla aşağıdaki sıfır hipotezleri tanımlanmıştır: – Hipotez 1: Yazılımcı deneyiminin verimlilik üzerinde etkisi yoktur. (H1) – Hipotez 2: Fazla mesainin verimlilik üzerinde etkisi yoktur. (H2) – Hipotez 3: Yazılımcı deneyiminin kaynak kod karmaşıklığı ve bağımlılığı (coupling) üzerinde etkisi yoktur. (H3) – Hipotez 4: Fazla mesai kaynak kod karmaşıklığı ve bağımlılığı (coupling) üzerinde etkisi yoktur. (H4)
Sıfır hipotezleri ANOVA testleri kullanılarak sınanmıştır. 4 4.1
Kaynak kod depoları, kaynak kodu ve kaynak koda yapılan değişiklikleri
saklamak ve yönetmek için kullanılır. Değişikliklerin tarihçesi, değişikliği yapan
yazılımcı, değişiklik tarihi, oluşan versiyonlar ve hatta ilgili ister veya proje
görevinin bilgisi kaynak kod depolarından elde edilebilir. Kaynak kod depolarındaki
bu zengin veri, YDM araştırmalarının temelini oluşturmaktadır. Bu çalışmada,
kaynak kod deposu yönetmek için kullanılan araç, Computer Associates (CA)
şirketinin bir ürünü olan CA Software Change Manager (CA SCM) [
Birçok şirket bilgi sistemlerinin tüm bileşenleri ile ilgili bilgileri Konfigürasyon
Yönetimi Veritabanında (KYVT) depolar. KYVT terimi, BT hizmet yönetimi
için en iyi uygulamaları (best practice) tanımlayan Bilgi Teknolojisi Altyapı
Kütüphanesinden (Information Technology Infrastructure Library, ITIL)
kaynaklanıyor olsa da, benzer sistemler neredeyse tüm BT departmanları tarafından
kullanılmaktadır. KYVT şu verileri içerir [
Kurumsal Kaynak Planlama (KKP) sistemleri finans/muhasebe, üretim, satış, servis ve müşteri ilişkileri yönetimini kapsayan, kurumların iç ve dış yönetim entegrasyonunu sağlayan bütünleşik yönetim sistemleridir. Çalışmamızda, yazılımcı efor verisi KKP sisteminden elde edilmiştir. Çalışmada kullanılan KKP sistemi kurum içi geliştirilmiş bir sistemdir.
İnsan Kaynakları (İK) sistemleri veya İnsan Kaynakları Yönetim Sistemleri (İKYS), çalışan bilgilerinin bir araya toplanması ve birleştirilmesi için özel olarak tasarlanmış sistemleri ifade eder. İK sistemleri bordro yönetiminden performans değerlendirmeye kadar birçok işlevi sağlayabilir. Çalışmamızda yazılımcıların deneyim bilgileri her çalışan hakkında en doğru verileri içeren İK sisteminden elde edilmiştir. İK sistemi de kurum içi geliştirilmiş bir sistemdir. 4.2
Çalışma kapsamında, kaynak kod verileri CA SCM versiyon kontrol sisteminden, hata/geliştirme verileri KYVT’dan, yazılımcı efor verileri KKP sisteminden ve yazılımcı deneyimi İK sisteminden toplanmıştır.
Kaynak kod verileri için, öncelikle kaynak kod deposunda belirtilen dönemde oluşturulan tüm versiyonlar adaptörler aracılığıyla çekildi. Daha sonra çekilen her sürüm üzerinde YEKA ile statik kod analizi yapıldı. PMD tarafından metot ve sınıf seviyesindeki metrikler hesaplandı. Kod metrikleri yanında, ilgili versiyonu oluşturan yazılımcı, oluşturma tarihi ve ilgili hata/istek/proje numarası da kaynak kod deposundan sağlandı.
KYVT üzerinde her yazılım ürünü ayrı bir yapılandırma öğesi (YÖ) (configuration item) olarak tanımlanır ve her değişiklik kaydedilip ilgili YÖ ile ilişkilendirilir. Çalışmamızda belirlenen süre içinde yazılım ürünü ile ilgili tüm değişiklikler (hata düzeltme veya geliştirme) adaptörler aracılığıyla toplandı. İncelenen KYVT üzerinde değişiklik için üç farklı tip tanımlanmıştır: Hata, İstek, Proje. Bu nedenle hata düzeltme ve geliştirme kolayca ayırt edilebildi.
İncelenen KKP sistemine her yazılımcı sorun, istek ya da proje için her gün harcanan eforu saat olarak girer. İzin verilen minimum değer 0.5 saattir. Örneğin bir problem çözme 0.5 saatten daha az sürerse, 0.5’e yuvarlanır. Bu çalışma kapsamında tek bir giriş için azami efor değeri 10 saat olarak gözlendi. Girilen her efor değeri kullanıcı tarafından sağlanan hata, istek ya da bir proje görev numarası (id) ile ilişkilendirilir. Böylece efor verisi her yazılımcı ve her gün için hata/geliştirme taskı seviyesinde toplanabilmiştir. Her efor girişi için aynı zamanda fazla mesai olup olmadığı belirtilmiştir. Detay seviyesi yüksek efor verileri sayesinde çalışmamızda detaylı analiz ve inceleme yapabildik.
Yazılımcı deneyimi verileri İK sisteminden çalışma kapsamında geliştirilen adaptörler aracılığıyla elde edildi. Yazılımcı deneyimi, çalışanın çalışmış ve çalışıyor olduğu şirket veya kurumlardaki iş deneyimleri toplanarak yıl olarak hesaplanır. Çalışma kapsamında kaynak kod deposu analizinde tespit edilen her yazılımcı için deneyim verisi İK sisteminden temin edildi. 4.3
Süreç sapmalarını tespit etmek ve kontrol-dışı noktalardan gelen verileri
ayıklamak için kontrol grafikleri kullandık. Kontrol grafikleri istatistiksel süreç kontrol
(İSK) araçlarından biridir [
Metrikler arasındaki korelasyonun tespiti için, Spearman korelasyon analizi
kullandık. Çalışma kapsamında bulunan korelasyon değerleri daha önceki
araştırmalardan da yararlanarak şu şekilde değerlendirildi [
Yazılımcı deneyimi ve mesai tipinin (fazla mesai/normal) etkisini ölçmek için, varyans analizi (ANOVA) uygulanmıştır (alfa düzeyi 0.05). ANOVA deneysel araştırmalarda grupların ölçülen özellik bakımından birbirinden istatistiksel olarak farklı olup olmadığını kontrol etmek için yaygın olarak kullanılır. Ancak, ANOVA hangi grupların özellikle hangilerinden farklı olduğu bilgisini sağlamaz. Bu amaçla çalışmamızda Tukey HSD ve Games-Howell testlerini post-hoc testler olarak kullandık.
ANOVA analizinde grupların eşit varyanslara sahip olduğu varsayılır. Çalışmamızda bu varsayımı kontrol etmek için Levene testi kullanılmıştır. Bu varsayımın karşılanmadığı durumlarda, çalışmamızda Welch ve Brown-Forsythe testleri kullanılmıştır. Ayrıca bu gibi durumlarda post-hoc test olarak Tukey HSD yerine eşit olmayan varyanslar için tasarlanmış Games-Howell testi kullanılmıştır.
Bu çalışma kapsamında yapılan istatistiksel analizler için SPSS [
Örnek Olay İncelemesi Bu çalışmada analizi yapılan finansal yazılım bileşeninin 2 yıla yayılan bakım/evrim verileri incelenmiştir. İlgili bileşenin yazılım geliştirmesi 10 ayda tamamlanmış ve bu süre sonunda ilk sürümü kullanıma alınmıştır. Sunulan çalışma bu noktadan sonra başlayan bakım/evrim fazının ilk 2 yılını kapsar. Yazılım bileşeni Java ile geliştirilmiş ve 6 yazılımcı bakımında görev almıştır.
Şekil 2: Kontrol Grafiği - Kod Büyüklüğü Değişiminin Evrimi 5.1
İlk olarak yazılımın kaynak kod büyüklüğünün değişimi kontrol edildi. Amacımız sadece ilgili değişikliklerin analiz için kullanılmasını sağlamaktı. Kaynak kod deposundan ölçümlenen değişikliklerin kod büyüklüğü (Delta-NCSS) için kontrol grafiği çizdik (Şekil 2).
Çizilen kontrol grafiğinde 36. haftanın NCSS değerinin ÜKS (Üst Kontrol Sınırı) üzerinde olduğunu gördük. Bu nedenle bu nokta kontrol-dışı nokta olarak değerlendirildi. 36. haftada kaynak kod deposuna aktarılan dosyalar detaylıca incelendiğinde, şirketteki başka bir bileşenin kaynak kodunun uygulamanın kaynak kod deposuna kopyalanmış olduğu tespit edildi. Böylece aynı şirketteki projeler arasında kaynak kod tekrarını (duplication) ortaya çıkarmış olduk. Ilgili kaynak kod çalışılan yazılımın bakım projeleri kapsamında geliştirilmediğinden ilgili metrik veri noktasının analizden çıkarılmasına karar verildi.
Kontrol-dışı veri noktası çıkarıldıktan sonra, kontrol grafiği yeniden çizildi (Şekil 3). Bu sefer, hesaplanan yeni kontrol limitlerine göre 95. hafta kontroldışı nokta olarak tespit edildi. Detaylı incelemede, yeni oluşturulan bir Java sınıfının projenin varolan bir Java sınıfından kopyalandığı ortaya çıktı. Bu durum efor ve kaynak kod metrikleri arasındaki ilişkiyi analiz ederken hataya neden olabileceğinden, ilgili Java sınıfı analizden çıkarıldı.
Tablo 1: Spearman Korelasyon Analizi Sonuçları
HaftaNo CorrEf CorrEf =.492**
p=.000
Bu kontrol-dışı nokta da çıkardıktan sonra çizilen kontrol grafiğinde (Şekil 4) tüm değerler kontrol limitleri arasında görülmüştür. Bu çalışmada sunulan diğer analizler bu iki kontrol-dışı noktanın kaldırılması sonucu oluşan kaynak kod ölçümlerini kulllanmışlardır. 5.2
Korelasyon Analizi Sonuçları 1 numaralı araştırma sorusunu yanıtlamak için bu çalışmada dikkate alınan metrikler arasında yapılan Spearman korelasyon analizinin sonuçları Tablo 1’de gösterilmiştir. CC, NCSS, NOA, NOO, ve CBO gibi tüm kaynak kod metrikleri ile geliştirme istekleri için harcanan efor (EnhcEf) arasında orta düzeyde korelasyon gözlemlenmiştir. Öte yandan hata düzeltme eforu (CorrEf) ve delta kaynak kod metrikleri arasında herhangi bir korelasyon tespit edilmemiştir. Bu gözlemler, kaynak kod üzerindeki değişikliklerin esas olarak geliştirme istekleri (enhancements) kapsamında yapıldığını göstermektedir.
Hafta numarası ve hata düzeltme eforu (CorrEf) arasında tespit edilen ortaderece korelasyon ilginç bir gözlem olarak değerlendirilebilir. Hafta numarası ve
Tablo 2: ANOVA Sonuçları - Yazılımcı Deneyimi Verimlilik BirimCCArtışı BirimCBOArtışı Tablo 3: Verimlilik - Yazılımcı Deneyimi için Games-Howell Sonuçları
Deneyimsiz Orta-Deneyimli
Deneyimsiz Orta-Deneyimli .967
Deneyimli .002* .002* hata sayısı (NoF) arasında da orta-derece korelasyon tespit edildi. Bu hata düzeltme ve destek faaliyetleri için harcanan haftalık efor ve tespit edilen haftalık hata sayıları için artan bir eğilim ortaya koymaktadır. Ayrıca, ilginç olmamakla beraber hata düzeltme eforu (CorrEf) ile hata sayısı (NoF) arasında yüksek korelasyon tespit edilmesi analizi yapılan verilerin doğrulamasına katkı sağlamaktadır.
CC - CCMetotMax ve NCSS - NCSSMetotMax metrikleri arasında
oldukça yüksek korelasyon (sırasıyla p değerleri: 0,873 ve 0,928) gözlemlendi. Bu
projedeki sınıfların büyüklüğünün, özellikle sınıfın en büyük boyutlu metodunun
boyutunu artırarak arttığını ortaya koymaktadır. Bu ilgili sınıfların metotlarının
yeniden düzenlenmesi (refactoring) için bir ihtiyaç olarak yorumlanabilir.
Fowler’ın önerdiği yeniden düzenleme (refactoring) tekniklerinin [
üzerinde etkisi var mıdır? 1 numaralı Hipotezin ANOVA testinin sonuçları Tablo 2’de sunulmaktadır. Levene testi grup varyanslarının eşit olmadığını gösterir (p = 0.004 < 0.05). Bu nedenle Welch ve Brown-Forsythe testlerinde (tabloda sırasıyla * ve ** ile işaretlenmiş) elde edilen sonuçlar kontrol edilir. Her iki test de yazılımcı deneyiminin verimlilik üzerinde önemli (significant) etkisi (p değerleri 0.003 ve 0.0) olduğunu göstermektedir. Bu nedenle, ilgili sıfır hipotezi H1 reddedilir. Tablo 3’de gruplar arasındaki farkların ayrıntılarını gösteren (önemli değerler * ile işaretlenmiştir) Games-Howell testinin sonuçları verilmiştir. Testlere göre, deneyimli yazılımcıların verimlilik değerleri deneyim
Tablo 4: Mesai Tipi için ANOVA Sonuçları Verimlilik BirimCCArtışı BirimCBOArtışı siz ve orta-deneyimli yazılımcılarınkinden önemli derecede (significant) farklıdır. Ancak, deneyimsiz ve orta-deneyimli yazılımcıların verimlilik değerleri arasında önemli bir fark tespit edilmemiştir. Bu, verilen görevlerin zorluk seviyesi, teknoloji ve uygulama deneyimi gibi farklı nedenlere bağlanabilir. Farklı faktörlerin verimlilik üzerindeki etkisi gelecekteki çalışmalarımızda ayrıca incelenecektir.
potez için ANOVA testi sonuçları Tablo 4’de sunulmuştur. Levene testi (p =
0.003 < 0.05) grup varyanslarının eşit olmadığını gösterir. Bu nedenle Welch ve
Brown-Forsythe testlerinde elde edilen sonuçlar kontrol edilir (sırasıyla * ve **
ile işaretlenmiş). Her iki test de fazla mesainin verimlilik üzerinde önemli bir
etkisi (p = 0.040 < 0.05) olduğunu göstermektedir. Bu nedenle ilgili hipotez H2
reddedildi. Genel kanının aksine, analiz sonuçları fazla mesai grubu için
verimliliğin diğer gruba göre daha yüksek olduğunu ortaya koymuştur. Bu durum için
bir açıklama; yazılımcıların fazla mesai sırasında normaleden daha az kesintiye
(interrupt) uğraması olabilir. Yazılımcılarla yaptığımız görüşmelerde normal
çalışma saatleri içinde gün boyunca genellikle e-posta, gelen telefon çağrıları ve
diğer acil istekler ile geliştirme işlerinin kesintiye uğradığını dile getirdiler. Bazı
çalışmalar [
Bu sonucu yorumlarken, fazla mesai eforunun genel efora oranı da (bu uygulama için %10) dikkate alınmalıdır (Şekil 5). Daha yüksek fazla mesai oranlarına sahip uygulamların sonuçları ile karşılaştırmak ilginç olacaktır. Sonuçlar üzerinde etkisi olabilecek bir diğer parametre de fazla mesai ücreti olabilir. Analiz yapılan şirkette yazılımcılara fazla mesai ücreti ödeniyordu. Fazla mesai ödenen yazılımcıların ödenmeyenlere göre daha motive çalışmaları beklenir. Bu konuyu da gelecekteki çalışmalarımızda araştırmayı planlıyoruz.
S4: Yazılımın bakımını yapan yazılımcıların deneyiminin kaynak kod karmaşıklığı ve bağımlılığı (coupling) üzerinde etkisi var mıdır? Tablo 2 Hipotez 3 için ANOVA sonuçlarını göstermektedir. Sonuçlar farklı yazılımcı deneyimi grupları arasında BirimCCArtışı ve BirimCBOArtışı metrikleri için Şekil 5: Mesai Tipi Pareto Diyagramı önemli (significant) bir fark göstermemektedir (p değerleri .745 ve .093). Bu durumda, sıfır hipotezi H3 reddedilemez.
üzerinde etkisi var mıdır? Tablo 4 Hipotez 4 için ANOVA sonuçlarını göstermektedir. Sonuçlar fazla mesai ve normal mesai arasında BirimCCArtışı ve BirimCBOArtışı metrikleri için önemli (significant) bir fark göstermemektedir (p değerleri sırasıyla .262 ve .807). Bu nedenle, sıfır hipotezi H4 reddedilemez. 6
Bu makalede, bir finansal yazılım bileşeninin evrimi için örnek olay incelemesi sunuldu. Çalışmada YDM teknikleri kullanılmıştır. Kaynak kod deposu, VYVT, KKP ve İK sistemleri veri kaynakları olarak kullanılarak versiyon geçmişi, hata raporları/geliştirme istekleri, yazılımcı deneyimi, efor ve mesai tipi verileri analiz edilmiştir. Bu yaklaşım, temel veri kaynağı olarak kaynak kod, hata depoları ve iletişim arşivlerine odaklanmış YDM kullanan mevcut yazılım evrimi araştırmalarından farklıdır. Bu çalışmada, çeşitli yazılım depolarından elde edilen veriler birleştirilip üzerinde kontrol grafikleri, Spearman korelasyon ve ANOVA testleri gibi istatistiksel analizler uygulanmıştır. Bu analizler sonucunda, süreç ve ürün metrikleri arasındaki ilişkiler, korelasyonlar, süreçteki sapmalar ve eğilimler gibi yazılım evrimi için değerli bilgiler ve içgörüler elde edilmiştir.
Çalışmamızda, projedeki sınıfların büyüklüğünün, özellikle sınıfın en büyük boyutlu metodunun boyutunun arttırılarak arttığı ortaya çıkmıştır. Bu ilgili sınıfların metotlarının yeniden düzenlenmesi (refactoring) için bir ihtiyaç olarak yorumlanmıştır. Ayrıca, aynı şirkette faklı projeler arasında kaynak kod tekrarı (duplication) yapıldığı ortaya çıktı. Çalışmamızın sonuçları, incelenen yazılımın bakım/evrimi fazında yazılımcı deneyimi ve fazla mesainin verimlilik üzerinde etkileri olduğunu gösterdi. Buna karşın kaynak kodun karmaşıklığı ve bağımlılığı üzerinde herhangi bir önemli (significant) etkisi gözlenmedi. Ayrıca, süreç ve ürün metrikleri arasındaki korelasyon analizi sonucunda, raporlanan hata sayıları ve hata düzeltme, destek faaliyetleri için harcanan efor için artış eğilimi saptandı.
Gelecek çalışmalarımız için, atanan görevlerin zorluk seviyesi, ilgili teknoloji ya da uygulamadaki deneyim gibi verimlilik üzerinde etkisi olabilecek farklı faktörleri incelemeyi planlıyoruz. Ayrıca, Git, Mercurial, Subversion gibi diğer kaynak depoları için adaptörler geliştirmeyi ve YEKA geliştirmesini tamamlamayı planlamaktayız.