Çevik yöntemlerde büyüklük ölçümü: bağımsız ölçümler
mümkün mü?
Tuna Hacaloglu 1,2, Aylin Deveci 3, Selami Bagriyanik 3, Onur Demirors4 1 Atılım Üniversitesi, Ankara, Türkiye
tuna.hacaloglu@atilim.edu.tr
2Orta Doğu Teknik Üniversitesi, Ankara, Türkiye 3Turkcell Teknoloji, İstanbul, Türkiye {aylin.deveci, selami.bagriyanik}@turkcell.com.tr 4 İzmir Yüksek Teknoloji Enstitüsü, İzmir, Türkiye
onurdemirors@iyte.edu.tr
Özet. Çevik yöntemler, günümüz yazılım sektöründe sıklıkla kullanılmaktadır.
Bu yöntemler, sık aralıklarla çalışan ürün ortaya çıkarmayı ve müşteri talep ve değişiklerine olabildiğince uyum göstermeyi hedefler. Bu durumun bir sonucu olarak, Çevik yöntemlerle geliştirilen yazılım projelerinde, gereksinimlerin de-taylı dokümantasyonu ikinci planda kalmış olup; geliştiriciler gereksinimleri daha az detaylı yazma eğilimindedirler. Ancak gereksinimlerin bu şekilde yazıl-ması, işlevsel büyüklük ölçümü, ve büyüklüğe bağlı sistematik efor kestirimi gibi süreçlerin uygulanabilirliğini zorlaştırmaktadır. Bu çalışmada, Scrum pratikleri uygulanarak geliştirilen büyük ölçekli bir teknoloji ve iletişim hizmetleri sağla-yıcısına ait bir yazılım projesinde iki farklı ölçer tarafından yapılan işlevsel bü-yüklük ölçümü deneyimleri aktarılmıştır. Temel olarak, projenin iki ayrı bakış açısından ölçülen işlevsel büyüklük değerlerinin ne kadar değişkenlik gösterdiği ve bu değişikliklerin sebeplerinin irdelenmesi hedeflenmiştir. Projenin fonksiyo-nel gereksinimleri önce bağımsız bir ölçer tarafından COSMIC Fonksiyofonksiyo-nel Bü-yüklük Ölçüm Yöntemi ile ölçülmüştür. Daha sonra, aynı gereksinimler, projenin teknik ürün yöneticisi tarafından aynı yöntem ile ölçülmüştür. Sözü edilen iki ayrı perspektiften ölçümlerin ardından, bu iki farklı ölçüm sonuçları birbiriyle karşılaştırılmış ve ölçüm değerlerinde oluşan sapmaların olası sebepleri araştırıl-mıştır. Bu ölçümler ışığında oluşturulan efor kestirim modelinin başarısının da çalışma kapsamında irdelenmesi hedeflenmiştir.
Anahtar Kelimeler: çevik, agile, SCRUM, işlevsel büyüklük, COSMIC
Size measurement in Agile Methods: are independent
measurements possible?
Tuna Hacaloglu 1,2, Aylin Deveci 3, Selami Bagriyanik 3, Onur Demirors4 1 Atılım Üniversitesi, Ankara, Türkiye
tuna.hacaloglu@atilim.edu.tr
2Orta Doğu Teknik Üniversitesi, Ankara, Türkiye 3Turkcell Teknoloji, İstanbul, Türkiye {aylin.deveci, selami.bagriyanik}@turkcell.com.tr 4 İzmir Yüksek Teknoloji Enstitüsü, İzmir, Türkiye
onurdemirors@iyte.edu.tr
Abstract. Agile methods are being used frequently in today’s software industry.
In these methods, more care is taken to deliver working software products in short time intervals and to adapt to customer change requests as much as possible. As a result of this, detailed documentation of requirements is pushed into the back-ground in agile and developers have tendency of documenting requirements in a less detailed format. However, this issue complicates the applicability of func-tional size measurement and hence size-based effort estimation. In this study, experiences of applying functional size measurement by two measurers on a soft-ware project developed using Scrum practices in a large-scale technology and communications services provider. Basically, it is aimed to examine how the functional size values measured from two different perspectives vary and possi-ble reasons for these changes. First, functional requirements of the project are measured by an independent measurer with COSMIC Functional size measure-ment method. Later, the same requiremeasure-ments set is measured with the same meas-urement method by the technical product manager of the project. Following the aforesaid measurements, the different functional size values are compared and the possible causes for the variations in the measurement values are investigated. In addition, it was aimed to examine the success of effort estimation model cre-ated with software size values measured by COSMIC method.
Keywords: agile, SCRUM, functional size measurement, COSMIC
1
Giriş
Çevik yöntemler geleneksel yazılım geliştirme süreç modellerinin katı yapılarına bir alternatif olarak 2001 yılında bir manifesto [1] olarak ortaya çıkmış olup; özellikle ça-lışan ürünü müşteriye hızlıca sunmayı hedeflemeleri sebebiyle günümüzde sıklıkla ter-cih edilmektedirler. 2015 yılında Garousi, Coskuncay, Betin-Can ve Demirors tarafın-dan yapılmış olan Türkiye’deki Yazılım Mühendisliği Pratikleri araştırmasına katılan 202 yazılım uygulayıcısından edinilen verilere göre Çevik/Yalın yöntemlerin Şelale
Modeli ’nden sonra en çok kullanılan süreç modeli olduğu ortaya çıkmıştır [2]. Çevik Yöntemler, yazılım yaşam döngüsü boyunca bir sonraki sürece ancak bir önceki süreç bütünüyle tamamlandığında geçilebilen, her sürecin kapsamlı dokümantasyonun daya-tıldığı [3] ve değişiklik taleplerinin yönetilememesi gibi Şelale Modeline ait çeşitli so-runları ortadan kaldırmak üzere bir seçenek olarak benimsenmiştir. Çevik yaklaşım-larda bireyler ve onların etkileşimleri, süreçler ve araçyaklaşım-lardan; çalışan yazılım ürünü, kapsamlı dokümantasyondan; müşteri ile işbirliği, sözleşmelerden ve değişikliklere ce-vap verebilmek, bir planı takip ediyor olmaktan daha değerli olarak nitelendirilmiştir [1].
Öte yandan, bir yazılım projesinin başarılı olarak değerlendirilebilmesi için, yazılı-mın müşteri ihtiyaçlarını tam anlamıyla yansıtmasına ek olarak, zamanında ve ön gö-rülen bütçe dâhilinde müşteriye teslim edilmesi de gerekmektedir [4]. Diğer bir deyişle, yazılım proje geliştirme sürecinin nasıl yönetildiği, projenin başarısı açısından büyük önem taşır. Sistematik bir ölçüm sunan COSMIC İşlevsel Büyüklük Ölçümü (İBÖ) gibi yöntemler, tedarikçi ve iş ortakları ile maliyetler konusunda el sıkışmak; daha gözlene-bilir, objektif ve hesap verilebilir olduğu için denetleme ve satın alma süreçleri gibi süreçleri yönetmek açısından faydalı ve gereklidir [5]. Buna ek olarak, proje yönetimi-nin ana kalemlerinden olan efor kestirimi, projeyönetimi-nin geliştirme takvimini belirleme ve de maliyet hesabını doğru yapabilmek için kritiktir. Bu bağlamda, zaman, bütçe ve efor gibi kestirimleri projenin başlangıç evrelerinde gerçekleştirmek için işlevsel büyüklük ölçümünün faydalı bir girdi olduğu bilinen bir gerçektir. Buna rağmen, çevik yazılım geliştiricilerin, genellikle öznel kestirim yöntemlerini daha fazla benimsedikleri ve bunlar arasında en çok öne çıkan kestirim yöntemlerinin hikâye puanı -“story point” (HP) ve kullanım durum puanı -“use case point (KDP) olduğu gözlemlenmiştir [6]. Bu tür öznel yöntemler oldukça kabul görmesine rağmen, çeşitli araştırmacılar tarafından eleştirilmektedirler. Örneğin, Commeyne vd. [7] kestirimlerin öznel olduklarını, dola-yısıyla beceri ve deneyimden bir hayli etkilendiklerini, büyüklük ölçümü olmadıkları için proje üretkenliğini belirleme konusunda eksik kaldıklarını ve projeler arası perfor-mansların karşılaştırılmasına imkân vermediklerini vurgulamıştır.
Buna karşılık, çevik yazılım projelerinde, işlevsel büyüklük ölçümünü uygulamış güncel çalışmalar mevcuttur. Son beş yılda bu konuda yapılan bazı çalışmalara baktı-ğımızda [7,8,9,10] çevik projelerde, COSMIC işlevsel büyüklük ölçümü ile yapılan efor kestirimlerinin başarılı sonuçlar verdiği görülmektedir. Ancak, yine de öznel kes-tirim yöntemlerinin çevik projelerde daha çok tercih edildiği [6] dikkate alındığında işlevsel büyüklük ölçümünün efor ve benzeri kestirimleri yapmak üzere başarısının araştırılması ve yazılım endüstrisinde daha az kullanılmasının sebeplerinin değerlendi-rilmesi önem taşır.
Çevik projelerde işlevsel büyüklük ölçümünün kullanımına bağlı literatürde dile ge-tirilen bir takım güçlükleri 2018 yılında, Hacaloglu ve Demirors bir literatür taraması kapsamında derlemiştir [11]. Buna ek olarak, Hacaloglu ve Demirors, 2019 yılındaki başka bir çalışma kapsamında [12], üç farklı organizasyonun, çevik yöntemler kullanı-larak geliştirilen projelerinde, COSMIC işlevsel büyüklük ölçümü yöntemi ile ölçüm yaparken karşılaşılan zorlukları çoklu vaka çalışması yaparak irdelemişlerdir. Çalışma
sonucunda, literatür bulgularına paralel olarak, COSMIC işlevsel büyüklüğü için ge-rekli olan bazı bileşenlerin ayırt edilmesinde gereksinimlerin yazılış tarzından kaynaklı bazı güçlüklerin olduğu gözlenmiştir [12].
Bu durumun bir sebebi olarak, çevik yöntemleri benimseyen yazılım geliştiricilerin, dokümantasyona daha az; çalışan ürünün hızlı bir biçimde teslimine ise olabildiğince çok önem verme bakış açısında oldukları [3] ve bu kişilerin gereksinimleri daha az de-tay içerecek biçimde yazma eğiliminde olmaları gösterilebilir [13]. Sonuç olarak ge-reksinim tanımlarının formal bir yapıda olmayışı COSMIC gibi işlevsel büyüklük öl-çümü (İBÖ) yöntemlerinin kullanımını zorlaştırdığından [14], işlevsel büyüklüğün ya-zılım proje yönetimine özgü zaman, bütçe, ve efor kestirimi gibi bir takım pratikler için kullanımını da kısıtlamaktadır.
Bu bildiride sunulan çalışmada, Türkiye’de faaliyet gösteren ve gerek çevik yöntem-ler ile yazılım geliştirme konusunda, gerekse COSMIC ile İBÖ ölçümü deneyimi olan büyük ölçekli bir teknoloji ve iletişim hizmetleri sağlayıcısı ait tek bir projeye odakla-narak, projenin işlevsel büyüklüğünün COSMIC ile iki ayrı perspektiften ölçümü he-deflenmiştir.
Söz konusu iki perspektif şu şekildedir:
- Yazılımın büyüklüğünün, COSMIC İBÖ ile bağımsız bir ölçer tarafından ge-reksinimler üzerinden ölçülmesi;
- Yazılımın büyüklüğünün COSMIC İBÖ ile ölçüm deneyimi olan teknik ürün yöneticisi tarafından ölçülmesi.
Çalışma temel olarak, ölçüm sonuçlarını karşılaştırmayı, ölçümler sonucunda oluş-ması muhtemel sapmaları ortaya koymayı ve bu sapmaların sebeplerini irdelemeyi ve çevik proje gereksinim içeriklerinin bu konuya ne kadar etki ettiklerini tartışmayı he-deflemektedir. Ayrıca, bu ölçümler ışığında efor kestirim modeli oluşturularak, COSMIC İBÖ yöntemi ile bulunan yazılım büyüklüğünün efor tahminleme konusun-daki başarısı gözlenecektir.
Bu bildirinin 2. Bölümünde araştırma tasarımı açıklanıp; 3. Bölümünde araştırmanın uygulanması, organizasyon ve ilgili proje kısaca tanıtılarak, 4. Bölümünde araştırma bulguları sunulacaktır. 5. Bölümde ise sonuçlar ve gelecekte hedeflenen çalışmalar ifade edilecektir.
2
Araştırma Tasarımı
Bu çalışmanın üç tane araştırma sorusu vardır:
Soru 1: Çevik yöntemlerle geliştirilen bir projenin farklı perspektiflerden işlevsel büyüklüğü ne kadar değişkenlik gösterir?
Soru 2: Ölçümlerde oluşan sapmaların sebepleri neler olabilir?
Soru 3: Çevik projelerde COSMIC İBÖ ile efor kestirimi ne kadar başarılıdır? Bu sorulara cevap aramak üzere, bu bildiride sunulan çalışma kapsamında altı adım-dan oluşan bir yol haritası izlenmiştir:
1- Çevik yöntemlerle geliştirilen bir projenin edinilmesi,
2- İşlevsel büyüklüğün, bağımsız ölçer tarafından COSMIC İBÖ yöntemi ile ge-reksinimler üzerinden ölçülmesi,
3- İşlevsel büyüklüğün, projede çalışmış ve COSMIC İBÖ yöntemi ile ölçüm de-neyimi olan teknik ürün yöneticisi tarafından ölçülmesi,
4- Sonuçlarının karşılaştırılması ve olası sapmaların irdelenmesi
5- Efor kestirim modelinin oluşturulması ve başarısının değerlendirilmesi
2.1 Ölçüm yöntemi seçimi
Bu çalışmada, projenin büyüklük değerlerini ölçmek üzere COSMIC İşlevsel Büyüklük ölçümü (İBÖ) yöntemi seçilmiştir. COSMIC İBÖ, ikinci nesil bir ölçüm yöntemi olup ISO standardına uyumludur [15]. Yöntemin temeli bir ilgi nesnesine ait veri grubunu hareket ettiren veri hareketlerini saymaya dayanır. Bu veri hareketleri Entry (E), Exit (X), Read (R) ve Write (W) olmak üzere dört farklı tipten oluşur.
Entry yani Girdi işlevsel kullanıcıdan sisteme veri hareketini,
Exit yani Çıktı sistemden işlevsel kullanıcıya doğru bir veri hareketini, Read yani Okuma kalıcı bellekten sisteme olan bir veri hareketini ve Write yani Yazma sistemden kalıcı belleğe olan bir veri hareketini temsil eder [15].
2.2 Proje seçme ölçütleri
Araştırmada kullanılacak projenin seçiminde aşağıda belirtilen ölçütler gözetilmiştir: Öncelikle çevik yöntemlerle yazılım geliştirme deneyimine sahip bir yazılım firmasının bulunması ve bu firmadan çevik yöntemlerden biri ile geliştirilmiş bir projenin temin edilmesi hedeflenmiştir.
2.3 Ölçerlerin seçimi
Projenin daha önce de bahsedildiği gibi öncelikle COSMIC İBÖ deneyimi olan bağım-sız bir ölçer tarafından, daha sonrada projede çalışmış ve COSMIC İBÖ deneyimi olan teknik ürün yöneticisi tarafından ölçülmesi amaçlanmıştır.
2.4 Veri analizi yöntemi
Projenin gereksinimlerinin işlevsel büyüklüğü ile bu gereksinimleri gerçekleştirmeye harcanan eforların arasındaki ilişkiyi değerlendirmek üzere korelasyon analizi ve reg-resyon analizinin kullanılması hedeflenmiştir.
3
Araştırmanın uygulanması
Araştırma için, Bölüm 2.1’de verilen proje seçme ölçütlerini gözeterek elde edilen bir proje önce gereksinimler üzerinden bağımsız ölçücü tarafından COSMIC İBÖ yöntemi ile daha sonra da teknik ürün yöneticisi tarafından aynı yöntemle ölçülmüştür.
Çalış-maya konu olan projenin özellikleri ve ölçüm sürecine dair detaylar Bölüm 3.1’de su-nulmuştur. Bu bölümlerde sözü geçen proje, bu bildiri metni boyunca A projesi olarak adlandırılacaktır.
3.1 A Projesinin tanıtımı
A Projesi, Türkiye’de faaliyet gösteren büyük ölçekli bir teknoloji ve iletişim hizmetleri sağlayıcısına aittir. Firma çevik yazılım geliştirme konusunda deneyimli olup aynı za-manda COSMIC İBÖ yöntemini konusunda da deneyim sahibidir. Bu bildiride irdelen-mek üzere seçilen A projesi çok kullanıcılı bir uygulama yazılımıdır. Fona ihtiyaç du-yan girişimler ile destekçileri birleştiren ve aynı zamanda online alışveriş yapılabilen bir pazar yeri platformudur. Platform genel çerçevede Java ve MySQL teknolojileri ile geliştirilen WEB sitesinden, Mobil RESPONSIVE WEB sitesinden, iOS ve Android gibi mobil uygulamalardan ve diğer yan teknolojilerden oluşmaktadır. Bu bildiride sa-dece WEB versiyonuna ait ölçüm değerleri sunulmuştur.
Platformu geliştiren teknik ekip kadrosu 1 proje yöneticisi, 1 analist, 4 geliştirici, ve 1 testçiden oluşmaktadır. Proje geliştirme takımı, yazılım geliştirme endüstrisinde de sıklıkla tercih edilen bir Çevik yöntem yaklaşımı olan Scrum yöntemi ile çalışmıştır. Scrum yönteminin çapraz-işlevli beklentisi çalışmanın yapıldığı ekipte yetkinliklerin veya uzmanlıkların her alanda eşit dağılmaması nedeniyle esnetilmiştir. Profiller “ge-nelleşen uzman” şeklinde uzmanlaşmaktadır. İlkesel olarak zaman zaman uzmanlıklar arası yardımlaşma ve geçişkenlikler de olacak şekilde esnek bir yapı benimsenmiştir.
Projeler, genellikle üç haftalık sprintler halinde geliştirilmektedir. Proje süreci bir iş, hata ve proje takip sistemi üzerinde oluşturulan Dijital Board üzerinden yürütülmekte-dir. Takım elemanlarının tümü aynı firma çalışanı olmamakla birlikte, iki firma kısmen birlikte, kısmen farklı konumlarda çalışmaktadırlar. Buna rağmen, teknik ürün yöneti-cisi klasik Scrum pratiklerinin, uzaktan da olsa büyük ölçüde uygulandığını belirtmiştir. Örneğin, takım her gün günlük Scrum toplantılarını telefonla yapmalarının yanında, sprint planlama ve retrospektif toplantıları gibi gerekli hallerde bu toplantılar için bir araya gelmektedirler. Buna ek olarak, acil çıkan problemler veya hata düzeltmeleri için yine telefon üzerinden görüşmeler ile toplantıları gerçekleştirmektedir.
Projenin ölçümünün gerçekleştirileceği gereksinim setinde, kullanıcı hikayesi for-matında işlevsel gereksinimler ve onlara karşılık gelen efor değerlerinin bulunmaktadır. Her bir kullanıcı hikâyesi, COSMIC İBÖ yöntemi ile daha önce bahsedilen iki farklı ölçer tarafından ölçülmüştür. COSMIC İBÖ ile iki fazda ölçüm sonucunda edinilen bü-yüklük değerleri Bölüm 4.1’de verilmiştir.
4
Araştırma Bulguları
4.1 A projesinden elde edilen CFP değerlerinin karşılaştırılması
Her iki ölçer tarafından, COSMIC İBÖ yöntemini kullanarak kullanıcı hikayeleri üze-rinden yapılan ölçümün sonuçları (CFP) ve bu kullanıcı hikayelerini gerçekleştirmek üzere harcanmış olan efor değerleri Kişi-Gün olarak Tablo 1’de sunulmuştur. Bu çalış-madaki ölçüm 15 kullanıcı hikâyesi üzerinden gerçekleştirilmiştir. Bu işlemlere toplam
68 gün efor harcanmıştır. Kullanıcı hikayesi başına düşen ortalama efor 4,5 kişi-gündür.
Tablo 1. Ölçüm sonuçları
Kullanıcı
Hikâyesi (Bağımsız ölçer) CFP değeri (Teknik Ürün CFP değeri Yöneticisi) Ölçerler arası fark Efor (Kişi-Gün) 1 3 3 0 1 2 9 3 6 2 3 3 2 1 1 4 3 2 1 1,5 5 9 8 1 4 6 3 2 1 4 7 14 30 16 12 8 15 20 5 26 9 8 10 2 6 10 4 4 0 3,5 11 2 2 0 0,5 12 2 2 0 1 13 6 3 3 3 14 2 1 1 0,5 15 3 1 2 2
Ölçüm sonuçlarına göre Tablo 1’den görülebileceği üzere, 1, 10, 11 ve 12 no.’lu kullanıcı hikâyeler için bağımsız ölçer ile teknik ürün yöneticisi ölçüm sonuçları birbi-rinin aynısıdır. Bu kullanıcı hikâyelebirbi-rinin işlevsel süreçleri irdelendiğinde 1, 11 ve 12 no.’lu hikâyenin “listeleme”, 10. no.lu hikâyenin ise kullanıcıya bir “bilgi gösterimi” olduğu görülmüştür.
Diğer yandan, bu çalışmada bağımsız ölçer ve teknik ürün yöneticisi ölçüm değerleri arasında bir takım farklar gözlenmiştir. Bu farkların aşağıda belirtilen sebeplerden kay-naklandığı düşünülmektedir:
- 2. kullanıcı hikâyesi “bilgi güncelleme” tipinde bir işlevsel süreçtir. Bu kullanıcı hikâyesi için ölçümlerde oluşan fark şu sebepten kaynaklanmaktadır. Bağımsız ölçer, “güncelleme” işlevsel sürecini ölçerken, “güncelleme yapmadan önce lis-tele” gibi bir varsayım yaparak yaklaşırken, teknik ürün yöneticisi listeleme iş-leminin zaten daha önce yapıldığını ve söz konusu kullanıcı hikâyesinin ve ona karşılık gelen eforun sadece güncelleme işlemine ait olduğunu belirtmiştir. Do-layısıyla gereksinimlerde bu detay belirtilmediğinden bu durum için, bağımsız ölçer, güncellemeden önce listeleme gibi daha fazladan varsayım yaparak ölçme eğilimi göstermiştir.
- 3. Kullanıcı hikâyesindeki 1 birimlik farkın sebebi, buradaki fonksiyonel sürece dair bir veri hareketinin daha önceki geliştirme süreçlerinde geliştirilmiş olma-sıdır. Bağımsız ölçer bu hareketi sayarken, teknik ürün yöneticisi saymamıştır.
- 4. Kullanıcı hikâyesindeki 1 birimlik farkın sebebi, bağımsız ölçerin bilgiyi, bil-ginin ilgi nesnesi kullanıcı hikâyesinde açıkça belirtilmediği için veri tabanın-dan okuduğunu varsaymasıdır, fakat teknik ürün yöneticisi bu ilgi nesnesine dair bilginin daha önce okunduğunu belirtmiştir.
- 5. Kullanıcı hikâyesindeki iki ölçer arasındaki 1 birimlik farkın sebebi için ba-ğımsız ölçerin hata/onay mesajını söz konusu sistemin göstereceğini varsayar-ken, teknik ürün yöneticisinin aslında bu mesajın yazılıma entegre başka bir sis-temin görevi olduğunu belirtmesi gösterilebilir. Fakat kullanıcı hikâyesinin bü-yüklüğüne etki eden bu bilgi kullanıcı hikâyesinde ifade edilmemiştir. - 6. Kullanıcı hikâyesindeki yine 1 birimlik farkın sebebi, bağımsız ölçerin
kul-lanıcı hikâyesinde kastedilen süreci farklı anlamasından kaynaklanmaktadır. Asıl ifade edilmek istenen bir fonksiyonel sürecin ön koşulu başka bir fonksi-yonel süreç iken, bağımsız ölçer bu sürecin sıfırdan geliştirileceği şeklinde bir yargıya varmıştır.
- 7, 8 ve 9. Kullanıcı hikâyelerinde, gereksinimler süreç adımlarına dair az detay içerdiği için ve bağımsız ölçerin proje hakkında teknik ürün yöneticisine oranla daha az bilgi sahibi olmasından kaynaklı burada olduğu gibi bazı süreçlerin de-taylarını bilmemesinden ötürü ölçüm yaparken bazı adımları atlama eğiliminde olduğu görülmüştür.
- 14. Kullanıcı hikâyesi bir işlevsel sürece oranla daha alt seviye bilgi içermekte-dir. Bağımsız ölçer, buradaki işlemin ek bir veri hareketini daha içerdiğini dü-şünürken, teknik ürün yöneticisi gerçekte öyle olmadığını ifade etmiştir. Özel-likle geliştirmesi daha önce tamamlanmış kullanıcı hikâyelerinde, hikâyenin ta-mamının yeniden geliştirilmesine ihtiyaç duyulmadan, sadece istenen değişikli-ğin gerçekleştirildiği durumlarda veri hareketi sayısının azaldığı gözlenmekte-dir.
- 15. Kullanıcı hikâyesi için ölçümlerde oluşan farkın sebebi bağımsız ölçerin, gereksinimi tek bir ilgi nesnesi için kayıt oluşturma işlevsel süreci olarak varsa-yarken, teknik ürün yöneticisinin, burada kast edilenin kayıt esnasında veri ta-banına yazma şeklinin değişmesi ile ilgili olduğunu ifade etmesidir.
Genel bir yargı olarak, projede çalışan teknik ürün yöneticisinin, proje ile ilgili bil-gisinin bağımsız ölçerden daha fazla olması ve teknik ürün yöneticisinin ölçtüğü CFP değerlerinin daha doğru olması beklenen bir durumdur. Ancak, çevik süreçlerde gözlemlenen, geliştirme ekibinin gerek toplantılar sırasında gerek geliştirme süreci içinde yaptıkları fikir alışverişlerinin dokümantasyona yansımama ihtimali, bağım-sız ölçerlerin bu konuda güçlükler yaşamalarına yol açmaktadır.
Ölçüm farklarının irdelenmesi sonucunda görülmektedir ki, COSMIC İBÖ ölçümü proje ile ilgili bilgi düzeyleri birbirinden farklı iki ölçer tarafından büyük ölçüde tutarlı sonuçlar vermektedir. İki ölçerin CFP değerleri arasında çok fazla fark bulun-mamaktadır. Ölçüm farklarının en önemli sebebi, gereksinim detaylarının optimal seviyede yazılmamasıdır. Özellikle, bağımsız ölçerin proje hakkında, teknik ürün yöneticisine oranla daha az bilgi sahibi olmasından kaynaklı daha fazla varsayım yaptığı ya da bazı süreçleri atladığı görülmüştür. Burada özellikle kavramlar için aynı terminolojilerin kullanıldığı, birden fazla anlam içermeyen, çelişkili olmayan
ve dolayısıyla herkes tarafından aynı şekilde anlaşılacak biçimde gereksinimler yaz-mak önem taşır [16]. Buna ek olarak, projede bir veri modelinin olmayışı, veri ana-lizine dair herhangi bir bilginin bulunmayışı, projenin bütünsel yapısını, tutulacak verilerin ilgi nesnelerini algılamayı ve dolayısıyla COSMIC ölçümü için gerekli olan veri hareketlerini belirlerken varsayım yapmaya yol açmaktadır. Benzer bir durum [12]’deki çalışmada da gözlenmiştir.
4.2 CFP değerleri ile Efor arasındaki ilişkinin analizi
Bağımsız ölçer ile teknik ürün yöneticisinin ölçümleri sonucunda yapılan görüşmelere göre karar verilen nihai ölçüm değerlerine göre kullanıcı hikayelerinin COSMIC cin-sinden büyüklüğü (CFP) ile efor değerleri arasında bir ilişkinin olup olmadığı incelen-miş ve korelasyon katsayısı 0,79 olarak bulunmuştur. Bu değer güçlü pozitif ilişkiye işaret etmektedir.
Bunun ardından, basit doğrusal regresyon ile projenin işlevsel büyüklüğünün efor tahmin gücü araştırılmıştır. Doğrusal regresyon modeli (1) no.’lu denklemdeki gibi bu-lunmuştur.
6216
,
0
6309
,
0
CFP
Efor
(1)Basit doğrusal regresyon analizi sonucunda bulunan R2 değeri 0,62 efor tahminin CFP ile yapıldığı modelde CFP değerinin efordaki % 62’lik değişimi açıklayabildiğini ifade etmektedir. CFP ile proje büyüklüğü ile efor arasındaki ilişkiyi görsel olarak ifade eden serpme diyagramı Şekil 1’de gösterilmiştir. Şekil 1’de X ekseni kullanıcı hikâye-lerinin CFP cinsinden değerlerini, Y ekseni ise karşılık gelen hikayeleri gerçekleştir-mek üzere harcanan efor değerlerini göstergerçekleştir-mektedir.
Şekil 1. COSMIC İşlevsel Büyüklük ve Efor dağılımı
Bu grafikte regresyon çizgisine diğer değerlere göre uzakta bulunan iki kullanıcı hikâyesi (7. ve 8. Kullanıcı hikâyelerinin) uç değer olup olmadıkları değerlendirilmiştir. 7. hikâyenin çok fazla X (Çıktı) tipinde veri hareketi içerdiği, 8. Hikâyenin ise diğer
y = 0,6309x + 0,6216 R² = 0,6167 0,0 20,0 40,0 60,0 80,0 0 5 10 15 20 25 30 35 H ar can an e fo r
kullanıcı hikâyelerine göre daha fazla süreç içerdiği gözlemlenmiştir. Fakat bu iki kul-lanıcı hikâyesini örneklemden çıkarmak üzere bir gerekçe gözlenmemiştir.
5
Sonuçlar ve Gelecekte Hedeflenen Çalışmalar
Bu bildiride sunulan çalışma kapsamında, çevik yöntemlerle büyük ölçekli bir teknoloji ve iletişim hizmetleri sağlayıcısı bünyesinde geliştirilen bir yazılım projesi iki farklı açıdan ölçülmüştür. Öncelikle, proje bağımsız bir ölçer tarafından gereksinim seti üze-rinden ölçülmüştür. Ardından aynı set, proje ekibinden proje hakkında detaylı bilgi sa-hibi olan bir teknik ürün yöneticisi tarafından ölçülmüştür. Ölçüm sonuçları birbirleri ile kıyaslanmıştır. CFP değerlerinin büyük ölçüde benzeştiği görülmüştür. Buna rağ-men, bazı CFP değerlerinde farklar mevcuttur. Ortaya çıkan bu sapmaların nedenleri araştırılmıştır.
Gereksinimlerin az detay içerecek şekilde yazılmaları, eksik/ yanlış an-lamalara yol açmaktadır, dolayısıyla açık ve tek bir manaya gelecek şekilde yazma yak-laşımının benimsenmesi, gereksinimler ile ilgili detayların olabildiğince dokümantas-yona yansıtılmasının ölçüm tutarlılığı ve doğruluğu açısından kritik olduğu gözlemlen-miştir. COSMIC İBÖ açısından önemli olan veri analizi için eksiklerin bulunması çüm esnasında varsayım yapma durumuna yol açtığı görülmüştür. Daha sonra, bu öl-çümler ile efor kestirim modeli oluşturulmuş ve modelin başarısı değerlendirilmiştir. CFP değerleri ile harcanan efor arasında pozitif ve güçlü bir korelasyon göz çarpmıştır. Kurulan regresyon modelinde CFP’nin eforda %62’lik bir değişimi açıkladığına dair bulgu gözlenmiştir. Bundan sonraki çalışmalarda, projenin mobil versiyonu benzer şe-kilde incelenecektir. Yeni bir boyut olarak bitmiş proje üzerinden ölçüm değerleri, ge-reksinim üzerinden ölçüm değerleri ile arasındaki değişkenlik incelenecektir.
Kaynakça
1. Beck, K., Beedle, M., Van Bennekum, A., Cockburn, A., Cunningham, W., Fowler, M., ... & Kern, J.: Manifesto for agile software development (2001).
2. Garousi, V., Coşkunçay, A., Betin-Can, A., & Demirörs, O.: A survey of software enginee-ring practices in Turkey. Journal of Systems and Software, vol. 108, 148-177. (2015). 3. McCormick, M.: Waterfall vs. Agile methodology. MPCS, N/A. (2012).
4. The Standish Group International, Inc. Standish Grup Chaos Report, (1995). https://www.csus.edu/indiv/r/rengstorffj/obe152-spring02/articles/standishchaos.pdf (Son erişim: 19 Haziran 2019).
5. Deveci, A., Caliskan, S. Bagriyanik, S., Gazdagi, O., Karahoca, A.: Yazılım Geliştirme Hiz-metlerinin Satın Alınması için Bir Maliyet Modeli Önerisi, Ulusal Yazılım Mühendisliğ Sempozyumu (2018).
6. Usman, M., Mendes, E., Weidt, F., & Britto, R.: Effort estimation in agile software deve-lopment: a systematic literature review. In Proceedings of the 10th international conference on predictive models in software Engineering, pp. 82-91, ACM. (2014).
7. Commeyne, C., Abran, A., & Djouab, R.: Effort estimation with story points and cosmic function points-an industry case study. Software Measurement News, vol.21 issue 1, 25-36. (2016).
8. Ungan, E., Çizmeli, N., & Demirörs, O.: Comparison of functional size based estimation and story points, based on effort estimation effectiveness in SCRUM projects. In 2014 40th
EUROMICRO Conference on Software Engineering and Advanced Applications pp. 77-80.
IEEE (2014).
9. Salmanoglu, M., Hacaloglu, T., & Demirors, O.: Effort estimation for agile software deve-lopment: Comparative case studies using COSMIC functional size measurement and story points. In Proceedings of the 27th International Workshop on Software Measurement and
12th International Conference on Software Process and Product Measurement (pp. 41-49).
ACM (2017).
10. Ertaban, C., Gezgin, S., Bağrıyanık, S., Albey, E., & Karahoca, A.: Çevik yöntemlerde cos-mic ı̇şlev puanı ve hikaye puanının birlikte kullanımı. In CEUR Workshop Proceedings. CEUR-WS. (2017).
11. Hacaloğlu, T., & Demirörs, O.: Challenges of using software size in agile software develop-ment: A systematic literature review. IWSM Mensura 2018, CEUR Workshop Proceedings. (2018).
12. Hacaloglu, T. and Demirors, O.: Measureability of functional size in Agile software projects: Multiple case studies with COSMIC FSM, Acccepted in Euromicro SEAA (2019). 13. Firesmith, D.: Specifying Good Requirements, in Journal of Object Technology, vol. 2, no.
4, pp. 77-87. (2003). http://www.jot.fm/issues/issue_2003_07/column7
14. Hussain, I., Kosseim, L., and Ormandjieva, O.: Approximation of COSMIC functional size to support early effort estimation in Agile. Data & Knowledge Engineering, 85, (pp.2-14). (2013).
15. COSMIC, “The COSMIC Functional Size Measurement Method Measurement Manual (The COSMIC Implementation Guide for ISO/IEC 19761: 2017) Version 4.0.2,” Common Software Measurement International Consortium, (2017).
16. Firesmith, D.: Generating Complete, Unambiguous, and Verifiable Requirements from Sto-ries, Scenarios, and Use Cases. Journal of Object Technology, 3(10), 27-40. (2004).
