<!DOCTYPE article PUBLIC "-//NLM//DTD JATS (Z39.96) Journal Archiving and Interchange DTD v1.0 20120330//EN" "JATS-archivearticle1.dtd">
<article xmlns:xlink="http://www.w3.org/1999/xlink">
  <front>
    <journal-meta />
    <article-meta>
      <title-group>
        <article-title>Açık Kaynak Yazılım Seçimi için İki Boyutlu Değerlendirme Metodu</article-title>
      </title-group>
      <contrib-group>
        <contrib contrib-type="author">
          <string-name>Nebi Yılmaz</string-name>
          <xref ref-type="aff" rid="aff0">0</xref>
          <xref ref-type="aff" rid="aff1">1</xref>
        </contrib>
        <contrib contrib-type="author">
          <string-name>Kıvanç Dinçer</string-name>
          <xref ref-type="aff" rid="aff0">0</xref>
          <xref ref-type="aff" rid="aff1">1</xref>
        </contrib>
        <aff id="aff0">
          <label>0</label>
          <institution>Anahtar kelimeler: Açık Kaynak Yazılım, Yazılım Değerlendirme/Seçme</institution>
          ,
          <addr-line>Yazılım Kalite Değerlendirme, ISO 25010 Modeli</addr-line>
          ,
          <country>Yazılım Kalite Modelleri</country>
        </aff>
        <aff id="aff1">
          <label>1</label>
          <institution>Bilgisayar Mühendisliği Bölümü Hacettepe Üniversitesi</institution>
          ,
          <addr-line>Ankara</addr-line>
        </aff>
      </contrib-group>
      <fpage>325</fpage>
      <lpage>336</lpage>
      <abstract>
        <p>Increased popularity of open source software has led to a considerable proliferation of alternative software. However, this being the case, an evident lack of academic studies that would contribute to the evaluation of open source software for organizations has turned the process of selecting the most suitable open source software product that meets the users' quality requirements into an appealing research problem. In this study, a comprehensive method to solve this problem has been obtained from the synthesis of existing studies in the literature with our contribution, which enables product evaluation using both code-based and community-based assessment. In order to perform code-based evaluation, internal attributes of the latest quality model ISO 25010 were used, and the proper metrics were employed in an attempt to measure these attributes. Furthermore, to perform community-based evaluation, metrics obtained from historical data such as e-mailing lists, program reports, frequently asked questions, etc. were utilized.</p>
      </abstract>
      <kwd-group>
        <kwd>Open Source Software</kwd>
        <kwd>Software Evaluation/Selection Methods</kwd>
        <kwd>Software Quality Evaluation</kwd>
        <kwd>ISO 25010 Model</kwd>
        <kwd>Software Quality Models</kwd>
      </kwd-group>
    </article-meta>
  </front>
  <body>
    <sec id="sec-1">
      <title>-</title>
      <p>
        Açık kaynak yazılımlar, kaynak kodları özel bir telif hakkı lisansı (copyright) ile
herkesin incelemesine, kullanımına ve dağıtımına açılan böylece kullanıcıya yazılımı
değiştirme özgürlüğü sunan ve dünyanın her tarafından bilişim uzmanlarınca imece
yöntemi ile endüstri standartlarında geliştirilen yazılımlardır [
        <xref ref-type="bibr" rid="ref1">1</xref>
        ].
      </p>
      <p>Açık kaynak yazılım kullanımı son yıllarda büyük oranda artmıştır. Bu yazılımların
tercih edilmesinin sebebi geçmişten günümüze farklılık göstermektedir. Geçmiş
yıllarda açık kaynak yazılım kullanımının ana sebebi mevcut kod tabanının ihtiyaca göre
değiştirilip tekrar kullanımının kaynak ve zaman tasarrufu sağlaması iken (tekrar
kullanılabilirlik), son yıllarda bu sebeplere ek olarak açık kaynak yazılımların yüksek
kaliteli, güvenli ve güvenilir olarak algılanmaya başlanması da kullanımdaki bu artışı
hızlandırmıştır. Böyle algılanmasındaki temel sebep ise bu yazılımların birçok
geliştiricinin dikkatli incelemesinden geçmiş ve dolayısıyla hatalarından arındırılmış olduğunun
kabul edilmesidir.</p>
      <p>
        Avrupa Birliği, UNESCO, Dünya Bankası gibi kuruluşlar yukarıda zikredilen
gerekçelerle açık kaynak yazılımların kullanımını önermektedirler. Nitekim Almanya,
İspanya, Meksika, Brezilya, Çin, Kore, Hindistan gibi birçok ülke, kamu kurumlarında
açık kaynak kodlu yazılımlarının kullanımını benimsemiş ve bilgi toplumu
stratejilerinin bir parçası yapmışlardır [
        <xref ref-type="bibr" rid="ref2">2</xref>
        ].
      </p>
      <p>
        Şekil 1’de verilen Black Duck Software ve North Bridge Venture
organizasyonlarının raporuna göre, özellikle 2010 yılından sonra açık kaynak yazılımlara ilgi dikkat
çekecek şekilde artmıştır. Geçmiş yıllarda Michael Skok: “Yazılımlar dünyayı ele
geçiriyor (İngilizcesi: Software is eating the world).” demiştir. Fakat günümüzde yine
aynı organizasyonların güncel raporuna göre bu algı değişmiştir ve “Açık kaynak
yazılımlar yazılım dünyasını ele geçiriyor (İngilizcesi: Open source software is eating the
software world)” haline dönüşmüştür [
        <xref ref-type="bibr" rid="ref3">3</xref>
        ].
      </p>
      <p>)2500
inb2000
(
ıs1500
ı
y
sa1000
jeo 500
r
P
0
2006
2008
2010
yıllar
2012
2014
Şekil 1. Açık kaynak yazılımı kullanımının yıllara göre değişimi</p>
      <p>
        Açık kaynak yazılım ürünlerinin popülerliği bu derece artmışken, ticari
yazılımlarda olduğu gibi en büyük problem bu yazılım ürünlerini değerlendirme ve seçme
işlemidir [
        <xref ref-type="bibr" rid="ref4">4</xref>
        ]. Akademik ve endüstri alanında ticari yazılımlar kadar olmasa da, açık
kaynak yazılımların değerlendirilmesi ve seçilmesi için birkaç metot önerilmiş fakat hala
standartlaştırılmış bir metot olmadığı için yapılan çalışmalar eksik ve yetersiz kalmıştır.
Önerilen bazı genel metotlar [
        <xref ref-type="bibr" rid="ref5">5</xref>
        ]’deki gibi açık kaynak yazılımlar için kullanılabilir
olmasına rağmen özellikle bu ihtiyaç için geliştirilmemiştir. Bu eksiklikten dolayı ihtiyaç
sahipleri ihtiyaçlarını karşılayan açık kaynak yazılım ürünlerini subjektif
değerlendirmelerle veya tavsiyeler üzerine seçmektedirler [
        <xref ref-type="bibr" rid="ref6">6</xref>
        ].
      </p>
      <p>Bu çalışmada bu konudaki eksikliği giderebilmek için literatürdeki çalışmalardan bir
sentez yapılarak kendi katkılarımızla beraber bu süreçte kod-tabanlı (code-based) ve
toplum-tabanlı (community-based) olmak üzere iki açıdan değerlendirme imkânı sunan
bir metot geliştirilmesi hedeflenmiştir. Kod–tabanlı değerlendirme yapılırken,
yazılımın kaynak kodları analiz edilerek ISO 25010 kalite modelinde listelenen içsel
öznitelikler arasından ihtiyaç sahibi tarafından önemli görülenler seçilerek uygun metriklerle
ölçülmektedir. Toplum-tabanlı değerlendirme yapılırken ise açık kaynak yazılım
ürünleriyle birlikte sağlanan kaynak kod ve geliştirme süreci hakkındaki tarihsel verilerden
faydalanarak elektronik posta listeleri, problem (hata) raporları ve sıkça sorulan sorular
vb. gibi tarihsel verilerden elde edilen metrikler değerlendirilmektedir.</p>
      <p>Bölüm 2’de konuyla ilgili çalışmalardan bahsedilecek, Bölüm 3’te bu çalışma
kapsamında geliştirilen bu kapsamlı metot tanımlanacak ve ilgili süreç adımları
açıklanacaktır. Bölüm 4’te geliştirdiğimiz metodun iki açık kaynak yazılım ürününe
uygulanmasını içeren doğrulayıcı bir vaka çalışması (case study) takdim edilecek ve elde edilen
bulgular analiz edilecektir. Bölüm 5’de ise sonuçlar ve gelecek çalışmalarla bildiri
sonlandırılacaktır.
2</p>
      <p>
        İlgili Çalışmalar
Literatürde açık kaynak yazılımların kalite özelliklerinin değerlendirilmesine ilişkin az
sayıda çalışma bulunmuş, fakat bu çalışmalarda önerilen metotları derinlemesine
karşılaştıran ve analiz eden bir çalışma bulunmamaktadır. Bu alanda en önemli
çalışmalardan bir tanesini Wheeler yapmıştır [
        <xref ref-type="bibr" rid="ref7">7</xref>
        ]. Çalışmasında açık kaynak yazılımların
değerlendirilme sürecini ticari yazılımların değerlendirilme süreci ile kıyaslamıştır ve
açık kaynak yazılımların değerlendirilmesinde toplum-tabanlı olarak dört aşamadan
oluşan çok genel bir metot geliştirmiştir.
      </p>
      <p>
        Bu alanda çalışma yapanlardan Deprez ve Alexandre [
        <xref ref-type="bibr" rid="ref8">8</xref>
        ] çalışmalarında QSOS [
        <xref ref-type="bibr" rid="ref9">9</xref>
        ]
ve OpenBRR [
        <xref ref-type="bibr" rid="ref10">10</xref>
        ] metotlarını karşılaştırarak analiz etmişlerdir. Bu çalışma, bu
metotların anlaşılmasında yardımcı olmuş ama literatürdeki diğer metotlarla
karşılaştırılmadığı için en uygun metotların bunlardan biri olduğu hakkında ikna edici olmamıştır.
      </p>
      <p>
        Literatürde göze çarpan diğer bir çalışmada ise Sung, Kim ve Rhew [
        <xref ref-type="bibr" rid="ref11">11</xref>
        ] sadece
kodtabanlı değerlendirilmeye yönelik tek yönlü çalışma yapmışlar ve toplum-tabanlı
değerlendirme yapmamışlardır.
      </p>
      <p>Yukarıda verilen çalışmalar incelendikten sonra, bu çalışmada literatürde mevcut
çalışmalardan bir sentez yapılarak kendi katkılarımızla beraber açık kaynak yazılımları
hem kod-tabanlı hem de toplum-tabanlı değerlendiren kapsamlı ve iki boyutlu bir metot
geliştirilmesi hedeflenmiştir. Şekil 2’de ticari yazılımların değerlendirilmesi ile ilgili
alt kısımda literatürdeki değerlendirme metotları özetlenmiş ve açık kaynak
yazılımların değerlendirilmesi ile ilgili üst kısımda ise bu çalışma kapsamında geliştirilen metot
özetlenmiştir.
Şekil. 2. Yazılım (kalite) değerlendirme metotları a) Önerilen metot b) Ticari yazılımlara
yönelik mevcut metotlar</p>
      <p>
        Ticari yazılımlar değerlendirilirken kodun iç yapısı bilinmediğinden dolayı, dış
öznitelikler (external attributes) kullanılır ve literatürde bulunan bazı karar-verme
(decision-making) teknikleriyle aday yazılım ürünlerine skorlar verilip siyah-kutu
değerlendirmesi (black-box evaluation) ile ihtiyaçlarımızı karşılayan en optimum yazılım seçilir
[
        <xref ref-type="bibr" rid="ref5">5</xref>
        ]. Ticari yazılımların aksine açık kaynak yazılım ürünlerinde ürünün koduna
erişebildiğimiz için beyaz-kutu değerlendirmesi (white-box evaluation) yapılabilir ve ürüne ait
içsel öznitelikler kullanılabilir [
        <xref ref-type="bibr" rid="ref12">12</xref>
        ].
3
      </p>
      <p>İki boyutlu değerlendirme metodu
Bu çalışmada Şekil 2’de gösterildiği gibi kod-tabanlı ve toplum-tabanlı olarak iki
boyutlu bir değerlendirme metodu önerilmiştir. Kod-tabanlı değerlendirme yapılırken ISO
25010 modelinden seçilen – kullanıcı tarafından öncelikli görülen - içsel öznitelikler
metriklerle ilişkilendirilmiş ve bu metrikler kullanılarak kodun kalite öznitelikleri
(quality attributes) ölçülerek alternatifler arasından en ideali seçilmeye çalışılmıştır.</p>
      <p>Toplum-tabanlı değerlendirme yapılırken, açık kaynak yazılımlar ile birlikte
sağlanan ve süreç tarihçesini açıklayan veriler ve dokümantasyon kullanılmıştır.</p>
      <p>Geliştirdiğimiz metot aşağıda detaylandırılan dört aşamadan oluşmaktadır.
3.1</p>
    </sec>
    <sec id="sec-2">
      <title>Aday yazılım ürününün belirlenmesi</title>
      <p>Bu aşamada ihtiyaç sahipleri öncelikle hangi çeşit yazılım ürünü için değerlendirme
yapacaklarını belirlemelidirler. Bu doğrultuda piyasada var olan, gereksinimlerini
karşılayacak aday yazılım ürünlerini araştırmalıdırlar.</p>
      <p>İhtiyaç duyulan aday açık kaynak yazılım ürünlerini ararken akla ilk gelen yöntem,
bir internet arama motoru (Google, Yandex, Yahoo, vb.) kullanarak arama yapıp
değerlendirme yapacağımız aday ürünleri belirlemektir. Eğer arama yapacağımız ürün
ismini biliyorsak ona rakip olabilecek isimleri bulmaya yönelik araştırma yapmak ta
uygun olur. Eğer arama yapılacak ürün ismi tam olarak bilinmiyorsa, aday olacak
ürünlerden herhangi birini gözden kaçırmamak için ürün ismi ile ilgili bütün
kombinasyonlar denenmelidir. Örneğin, X formatını Y formatına dönüştüren bir yazılım ürünü için
arama yaptığımızda, X2Y, XtoY gibi çeşitli kombinasyonlar denenmesi lazımdır.</p>
      <p>
        Arama yaparken kullanılabilecek ikinci yöntem ise ürünlerin kodlarını ve
dokümanlarını sağlayan sitelerden (Apache, SourceForge, Debian ve Savannah, vb.) aday açık
kaynak yazılım ürünlerini belirlemektir. Bütün bu araştırmaları yaparken ürünlerin açık
kaynak yazılım lisanslarına (General Public Licence (GPL), Library or Lessor General
Public Licence (LGPL), BDS-style, vb.) sahip olduğuna dikkat etmek lazımdır [
        <xref ref-type="bibr" rid="ref7">7</xref>
        ].
3.2
      </p>
    </sec>
    <sec id="sec-3">
      <title>Kalite özniteliklerinin belirlenmesi</title>
      <p>Bu aşamada, belirlenen açık kaynak yazılım ürün alternatiflerinin hangi kalite
özniteliklerine göre değerlendirileceği ve karşılaştırılacağı belirlenir. Geçmişten günümüze
önerilen kalite modellerinden en bilinirleri McCall (1977), Boehm (1978), FURPS
(1992), Dromey (1995) ve ISO 9126 (2001) modelleridir. Farklı kalite modellerinin
içerdiği öznitelikler (attributes) farklılık göstermektedir. Bazıları önceki modellere
yeni öznitelikler eklerken, bazıları ise öncekileri kendi modellerinden çıkarmıştır.</p>
      <p>
        Biz bu çalışmamızda Tablo 1’de gösterilen ve bütün modellerde önerilen ortak
öznitelikleri ölçmeye çalışacağız. Tabloda da görüldüğü gibi geçmişten günümüze bütün
modellerin önerdiği ortak özniteliklerin verimlilik (efficiency), güvenilirlik
(reliability), fonksiyonellik (functionality), taşınabilirlik (portability), kullanılabilirlik
(usability) ve bakım yapılabilirlik (maintainability) olduğu görülmektedir [
        <xref ref-type="bibr" rid="ref12">12</xref>
        ]. Bu metodun
bu ortak içsel öznitelikleri ölçmek için en güncel kalite modeli olan ISO 25010’un
tanımlarını (Tablo 2) kullanması öngörülmüştür. Kullanıcı bunlardan ihtiyaç
duyduklarını veya önemli gördüklerini seçer.
      </p>
      <p>Tablo 1. Boehm, McCall, FURPS, ISO 9126 ve Dromey'in kalite modelleri (ortak öznitelikler)</p>
      <sec id="sec-3-1">
        <title>Kalite öznitelikleri</title>
        <p>Verimlilik (Efficiency)
Güvenilirlik (Reliability)
Fonksiyonellik (Functionality)
Bakım yapılabilirlik (Maintainability)
Taşınabilirlik (Portability)
Kullanılabilirlik (Usability)</p>
      </sec>
      <sec id="sec-3-2">
        <title>Boehm</title>
        <p>X
X
X
X</p>
      </sec>
      <sec id="sec-3-3">
        <title>McCall</title>
        <p>X
X
X
X
X</p>
      </sec>
      <sec id="sec-3-4">
        <title>FURPS</title>
        <p>X
X
X
X
X
ISO 9126
X
X
X
X
X
X</p>
      </sec>
      <sec id="sec-3-5">
        <title>Dromey</title>
        <p>X
X
X
X
X
X
3.3</p>
      </sec>
    </sec>
    <sec id="sec-4">
      <title>Değerlendirme yapılacak metriklerin belirlenmesi</title>
      <p>İhtiyaçlar doğrultusunda elde edilen açık kaynak yazılım alternatiflerinin nicel olarak
değerlendirilmesi için uygun metriklerle ilişkilendirilmesi lazımdır. Kod-tabanlı
değerlendirme yapmak için belirlenen öznitelikler direk olarak ölçülemeyeceğinden dolayı
uygun metrikler belirlenir.</p>
      <sec id="sec-4-1">
        <title>Kalite öznitelikleri</title>
        <p>Fonksiyonel uygunluk
Güvenilirlik
Performans verimliliği
İşletilebilirlik</p>
        <sec id="sec-4-1-1">
          <title>Güvenlik</title>
        </sec>
        <sec id="sec-4-1-2">
          <title>Uyumluluk Bakım yapılabilirlik</title>
        </sec>
        <sec id="sec-4-1-3">
          <title>Aktarılabilirlik</title>
          <p>Tablo 2. ISO 25010 kalite öznitelikleri</p>
          <p>İçsel öznitelikler
uygunluk, doğruluk, birlikte işlerlik, güvenlik, uyumluluk
olgunluk, hata dayanıklılığı, geri kazanılabilirlik, uyumluluk
zamana göre davranış durumu, kaynak kullanımı, uyumluluk
uygunluk, tanınabilirlik, kullanım kolaylığı, öğrenilebilirlik, çekicilik, teknik
ulaşılabilirlik, uyumluluk
gizlilik, bütünlük, inkar edilememe, hesap verebilirlik, aslına uygunluk,
uyumluluk
değiştirilebilirlik, birlikte varolabilme, birlikte işlerlik, uyumluluk
modülerlik, tekrar kullanılabilirlik, çözümlenebilirlik, değişebilirlik,
değiştirilebilme kararlılığı, sınanabilirlik, uyumluluk
taşınabilirlik, adapte olabilirlik, yüklenebilirlik, uyumluluk</p>
          <p>Toplum-tabanlı değerlendirme yapabilmek için ise ürünün internet sitesinin bize
sağladığı birçok tarihsel arşivlenmiş veriler (elektronik postalar, sıkça sorulan sorular,
problem ve hata raporları, vb.) kullanılır. Bu verileri değerlendirebilmek için analiz
aşamasında kullanılabilecek nitelikte uygun metrikler bulunmaya çalışılır. Daha sonra
ilişkili metrikler yorumlanarak alternatif ürünlerden hangisinin ihtiyaçlarımıza en
uygun olduğu belirlenmeye çalışılır.
3.4</p>
        </sec>
      </sec>
    </sec>
    <sec id="sec-5">
      <title>Analiz etme ve seçme</title>
      <p>
        Bu son aşamada kod-tabanlı değerlendirme yapmak için ihtiyaçlarımıza göre belirlenen
ve nicel değerler elde etmek için metriklerle ilişkilendirilen kalite öznitelikleri analiz
edilir. Metriklerden nicel değerler elde etmek için yazılım ürünün açık kaynak kodu
kod analiz araçları (code analyzer tools) ile ölçülür. Elde edilen bu nicel değerler
sayesinde her bir metrik ile ilişkili kalite öznitelikleri yorumlanır. Eğer belirlenen kalite
öznitelikleri için ölçülen değerler bir kaç aday ürün için birbirine yakın çıkmışsa veya
değerlendirmede kararsız kalınan ürünler arasında derinlemesine analiz yapılmak
isteniyorsa temsili model veriler (representetive dummy data) oluşturularak ölçmek
istenilen özniteliklere uygulanır ve sonuçlar analiz edilir [
        <xref ref-type="bibr" rid="ref7">7</xref>
        ]. Toplum-tabanlı değerlendirme
yapmak için yazılım ürününün internet sitesindeki metriklerle ilişkilendirilen tarihsel
veriler, bu metrik değerleri kullanılarak yorumlanır. Bütün bu değerlendirilmeler
sonucu ihtiyaçlarımızı karşılayan en ideal ürün seçilmeye çalışılır.
      </p>
      <p>Vaka Çalışması</p>
    </sec>
    <sec id="sec-6">
      <title>Aday yazılım ürünlerinin özellikleri</title>
      <p>Bu kısımda vaka çalışması olarak aynı amaca yönelik olan (amaç: kod derleme/build
aracı) ve pratikte benzer popülerliğe sahip iki tane aday açık kaynak yazılım ürünü ele
alınmış ve bu ürünler çalışmamızda önerdiğimiz metot kullanılıp değerlendirilerek
bizim için en ideal olanı seçilmeye çalışılmıştır. Değerlendirme yapılacak ürünlerin
(Apache Ant ve Apache Archiva) detayları Tablo 3’te gösterilmiştir.</p>
      <sec id="sec-6-1">
        <title>Tablo 3. Ürünler hakkında bilgiler</title>
        <p>Ürün özellikleri
İnternet sitesi
Ürün türü
Prog. dili
Ürün statüsü
İncelenen sürüm
Üretim yılı
E. posta arşivi
Hata listeleri</p>
        <sec id="sec-6-1-1">
          <title>Apache Ant</title>
          <p>http://ant.apache.org/
Java tabanlı derleme aracı
JAVA
Aktif
Apache ant 1.9.7 (2016-04-12)
2000
http://ant.apache.org/mail.html
http://issues.apache.org/bugzilla/buglist.cgi?product=Ant</p>
        </sec>
        <sec id="sec-6-1-2">
          <title>Apache Archiva</title>
          <p>http://archiva.apache.org/
Java tabanlı derleme aracı
JAVA
Aktif
Apache archiva 2.2.0 (2015-03-02)
2006
http://archiva.apache.org/mail-lists.html
http://issues.apache.org/jira/browse/MRM
4.2</p>
          <p>
            Özniteliklerin ve metriklerin belirlenmesi
Aday yazılım ürünleri belirlendikten sonra, kod-tabanlı değerlendirme yapmak için
öncelikle ölçülmek istenen öznitelikler belirlenmelidir. Bu vaka çalışmasında Tablo 1’de
gösterilen bütün kalite modelleri tarafından önerilmiş özniteliklerden biri olan bakım
yapılabilirlik (maintainability) seçilmiştir. Bu özniteliği direk olarak ölçemediğimiz
için bu öznitelikle ilişkili Tablo 2’de gösterilen ve ISO 25010’nun tanımları
kullanılmıştır. Daha sonra literatürde kullanılan metrikler araştırılmış ve her bir içsel
özniteliğin nicel olarak ölçülmesi için Tablo 4’te gösterilen uygun metrikler bulunmuştur [
            <xref ref-type="bibr" rid="ref13">13</xref>
            ].
Bu metrikler açık kaynak yazılım ürünlerinin kaynak kodlarının sınıf (class)
seviyesinde Understand Scitool adlı kod analiz aracı [
            <xref ref-type="bibr" rid="ref14">14</xref>
            ] kullanılarak ölçülmüş ve en büyük
(Maks), en küçük (Min), ortalama (Ort) ve standart sapma (SS) değerleri Tablo 5’te
verilmiştir.
          </p>
          <p>Tablo 4. Metriklerin listesi ve kısaltmaları</p>
        </sec>
      </sec>
      <sec id="sec-6-2">
        <title>Siklomatik Karmaşıklık (CC) Kalıtım Ağacının Derinliği (DIT) Alt Sınıf Sayısı (NOC)</title>
      </sec>
      <sec id="sec-6-3">
        <title>Sınıfın Ağırlıklı Metot Sayısı (WMC)</title>
      </sec>
      <sec id="sec-6-4">
        <title>Sınıfın Tetiklediği Metot Sayısı (RFC)</title>
      </sec>
      <sec id="sec-6-5">
        <title>Açıklamaların Sayısı (NOS)</title>
        <p>Nesne Sınıfları Arasındaki Bağımlılık (CBO)</p>
      </sec>
      <sec id="sec-6-6">
        <title>Sınıf Açıklama Sıklığı (CCF) Metotların Uyum Eksikliği (LOC) İç İçe Döngü Sayısı (NNL)</title>
        <p>Tablo 5. Kod-tabanlı değerlendirme sonuçları
4.3</p>
      </sec>
    </sec>
    <sec id="sec-7">
      <title>Bulgular ve Bulguların Tartışılması</title>
      <p>Kod-tabanlı değerlendirmede elde edilen metriklere göre şu sonuçlar elde edilmiştir:</p>
      <p>
        DIT metriği sınıfın kalıtım ağacının köküne uzaklığını ölçer [
        <xref ref-type="bibr" rid="ref15">15</xref>
        ]. Ağaç derinliğinin
fazla olması daha fazla sınıf ve metot içereceği için karmaşıklığı arttırır ve yazılımın
değişebilirliğinin (changeability) ve ürünün kararlılığının (stability) düşük olduğunun
göstergesidir. Bu da istenmeyen bir durum olduğu için Tablo 5’teki sonuçlara göre bu
metrik için içsel özniteliklerden değişebilirlik ve kararlılık bakımından Apache
Archiva’nın daha iyi olduğunu gösterir.
      </p>
      <p>
        WMC metriği bir sınıftaki metotların karmaşıklık derecesi ve sayısıdır [
        <xref ref-type="bibr" rid="ref16">16</xref>
        ].
Metotların sayısı arttıkça kodun çözümlenebilirlik (analyzability) süresi de otomatik olarak
artacaktır. Dolayısıyla Tablo 5’teki sonuçlara göre çüzümlenebilirlik bakımından
Apache Archiva yazılım ürününün daha iyi olduğunu anlaşılır.
      </p>
      <p>
        LOC metriği metotların birbiriyle benzerlik derecesini ölçer [
        <xref ref-type="bibr" rid="ref16">16</xref>
        ]. Bu metriğin
değerinin düşük olması istenir. Dolayısıyla Apache Archiva ürününün metotları diğer
ürüne göre daha uyum içerisinde ve değişebilirliği daha yüksektir (Tablo 5).
      </p>
      <p>
        RFC metriğinin değeri bir sınıftan bir nesnenin metotları çağırılması durumunda, bu
nesnenin tetikleyebileceği tüm metotların sayısıdır. Yani, bir sınıfta yazılan ve çağrılan
toplam metot sayısıdır [
        <xref ref-type="bibr" rid="ref15">15</xref>
        ]. RFC metriğinin değerinin düşük olduğu yazılım ürünleri
daha anlaşılır ve sınanabilirdir. Bu yüzden Tablo 5’te bu metriğin değerlerine göre
Apache Ant ürününün test edilmesi ve hata ayıklaması daha zordur.
      </p>
      <p>
        NOC metriği bir sınıftan türetilmiş alt sınıfların sayısını ölçer. Bu metriğin değerinin
fazla olması yeniden kullanımının yüksek olduğu, daha çok hatanın oluşabileceğini
[
        <xref ref-type="bibr" rid="ref17">17</xref>
        ] ve test yapılırken harcanan çabanın yüksek olduğunu gösterir [
        <xref ref-type="bibr" rid="ref15">15</xref>
        ]. Dolayısıyla
Apache Archiva ürününün sınanabilirliği (testability) daha yüksektir.
      </p>
      <p>
        CBO metriği sınıfın bağlı olduğu sınıf sayısını ölçer. Bu bağımlılık sınıf içerisindeki
bazı özelliklerin veya metotların başka sınıflarda, sınıflar arasında kalıtım olmaksızın
kullanılması durumundaki bağımlılıktır [
        <xref ref-type="bibr" rid="ref17">17</xref>
        ]. Sınıflar arasındaki bağımlılığın fazla
olması modüler tasarıma zarar verir [
        <xref ref-type="bibr" rid="ref15">15</xref>
        ] ve değişebilirliği azaltır. Bu metriğin değeri
bakımından arada fazla fark olmamakla birlikte Apache Ant ürünü değişebilirlik ve
kararlılık bakımından biraz daha üstündür.
      </p>
      <p>CC metriği program kaynak kodunun akışının birbirinden bağımsız yolları takip
etme oranını ölçer ve direk kodun karmaşıklığı ile ilgilidir. Bu metriğin değerinin
büyük olması istenmeyen bir durumdur ve kaynak kodun çözümlenebilirliğine etki eder.
Dolayısıyla çözümlenebilirlik bakımından Apache Archiva ürünü diğer ürüne göre
biraz daha üstündür.</p>
      <p>NNL metriği bir sınıf içerisindeki döngülerin iç içe geçme derinliğini ölçer ve ne
kadar büyük bir değer alırsa kodun sınanabilirliği ve kararlılığı azalır. Dolayısıyla bu
metriğin sonuçlarına göre sınanabilirlik ve kararlılık açısından Apache Archiva ürünü
diğer üründen öndedir.</p>
      <p>NOS ve CCF metrikleri program içerisindeki karmaşıklığı azaltmak adına bize yol
gösterecek yorumların ve açıklamaların sıklığını ölçer. Programın takip edilmesini ve
çözümlenebilmesini kolaylaştırır. Tablo 5’teki sonuçlara baktığımızda NOS metriği
açsından çözümlenebilirlik için Apache Archiva ürünü üstünken, CCF metriği için
Apache Ant ürünü üstündür.</p>
      <p>Sonuçlardan da görüldüğü gibi kod-tabanlı değerlendirme açısından Apache
Archiva Apache Ant yazılım ürününe göre daha üstün özelliklere sahiptir. Tablo 5’te
verilen ISO 25010’nun içsel öznitelikleri (çözümlenebilirlik, değişebilirlik, ...) bakım
yapılabilirliğin ölçülmesini kolaylaştıran alt öznitelikler olduğu düşünüldüğünde, genel
manada Apache Archiva açık kaynak yazılım ürünü ileride değişen ihtiyaç sahibi
isteklerine göre yenilenebilen ve çok daha kolay adapte olabilen bir yapıya sahiptir.</p>
      <p>
        Belirlenen aday yazılım ürünleri arasında toplum-tabanlı değerlendirme
yapılabilmesi için yazılım ürünlerinin internet sitesindeki tarihsel verilere – elektronik posta
arşivi ve problem raporlarına – erişilmiştir. Bu verilerin depolanması için açık kaynak
yazılım ürününün internet sitesinde bulunan Concurrent Version Control (CVS) arşivi
ve Problem Reporting Database (BUGDB) gibi veri tabanları kullanılmaktadır [
        <xref ref-type="bibr" rid="ref18">18</xref>
        ]. Bu
veri tabanlarından elde ettiğimiz ürün ile ilgili tarihsel veriler, ürünün kalite
özniteliklerini ölçmemizi sağlayan toplum-tabanlı değerlendirmelere katkı sağlayarak, ürün
kalitesini ölçmemizde ikincil düzeyde yardımcı olmuştur.
      </p>
      <p>yıllar
Apache ANT</p>
      <p>Apache ARCHIVA
Şekil. 3. Elektronik posta sayılarının yıllara göre değişimi</p>
      <p>Elektronik posta verilerinin Şekil 3’te gösterildiği sonuçları şu şekilde analiz
edilmiştir: Apache Ant yazılım ürünü (2000 yılı) Apache Archiva yazılım ürününe (2006
yılı) göre daha eski bir üründür. Apache Ant ürünü üretildiği ilk yılda üreticiler
arasındaki ürün hakkında teknik tartışmalar ve ürün ile ilgili eksiklikler içeren mesajlaşma
sayısı yıllık 8.000 civarındadır. 2002 yılına gelindiğinde ürün ile ilgili teknik
sıkıntılardan dolayı bu sayı 18.000 civarına çıkmıştır. 2002 yılından sonra bu mesajlaşma trafiği
azalan bir tutum sergilemiş ve 2016 yıllarına geldiğimizde 150 civarına kadar
düşmüştür. Görüldüğü gibi Apache Ant ürününün standart bir ürün haline gelmesi 16 yıllık bir
süreç almıştır. Şu anda bile az da olsa ürünün eksiklikleri ve teknik tartışmalar devam
etmektedir.</p>
      <p>Apache Archiva yazılım ürünü Apache Ant ürününe göre daha yeni bir ürün olmasına
rağmen piyasaya sürüldüğü ilk yılda sayı olarak yıllık 900 civarında mesajlaşma trafiği
ile başlarken bu sayı giderek düzenli olarak azalmış ve 2016 yılına geldiğimizde sayı
olarak yıllık 30 civarına düşmüştür. Apache Ant’a göre daha kısa sürede daha az
mesajlaşma trafiği ile standart bir ürün haline gelmiştir. Bu yüzden iki ürün arasındaki
üreticiler arasındaki mesajlaşma trafiği dikkate alındığında Apache Archiva yazılım
ürünü diğerine göre açık ara üstünlük sağlamıştır.</p>
      <sec id="sec-7-1">
        <title>Tablo 6. Hata (Bug) sayılarının karşılaştırılması</title>
        <sec id="sec-7-1-1">
          <title>Toplam hata sayısı</title>
          <p>Çözülen hata sayısı</p>
        </sec>
        <sec id="sec-7-1-2">
          <title>Başarı oranı</title>
        </sec>
        <sec id="sec-7-1-3">
          <title>Apache Ant</title>
          <p>Apache Archiva
5.962
1.873
5.135
1.654
%86,13
%88,30</p>
          <p>Tablo 6’da gösterilen problem raporlarının sonuçlarına göre Apache Ant yazılım
ürününün toplam hata (bug) sayısının 5.962 olduğu ve bunların 5.135 tanesinin
çözüldüğü görülmektedir. Bu sonuçlara göre bu ürünün hataların bulunup çözümlemesindeki
başarı oranı %86,13 olduğu görülmektedir. Apache Archiva ürününde ise toplamda
1.873 hatanın 1.654 tanesi çözülmüş ve başarı oranı Apache Ant yazılım ürününden
daha yeni bir ürün olmasına rağmen %88,30 çıkmıştır. Bu oran Apache Archiva
ürününün bulunan hataları çözmede daha başarılı olduğunu göstermiştir.</p>
          <p>Tablo 7. Bulunan hataların önem derecelerine göre dağılımları</p>
        </sec>
        <sec id="sec-7-1-4">
          <title>Apache Ant</title>
        </sec>
        <sec id="sec-7-1-5">
          <title>Apache Archiva</title>
        </sec>
        <sec id="sec-7-1-6">
          <title>Engelleyici</title>
          <p>(Blocker)
%13
%1</p>
        </sec>
        <sec id="sec-7-1-7">
          <title>Kritik</title>
          <p>(Critical)
%14
%5</p>
          <p>Büyük
(Major)
%40
%79</p>
          <p>Küçük
(Minor)
%31
%14
Önemsiz
(Trivial)
%2
%1</p>
          <p>Tablo 7’de toplam hata sayılarının önem derecelerine göre dağılımları gösterilmiştir.
Bulunan bu hata çeşitlerinin ürün üzerindeki etkileri farklı olacağından bu hatalara
(Engelleyici=5, Kritik= 4, Büyük= 3, Küçük=2 ve Önemsiz=1) önem sırasına göre ağırlık
verilmiş ve bu hataların ürün üzerindeki etkisi ise şu şekilde hesaplanmıştır:</p>
        </sec>
      </sec>
    </sec>
    <sec id="sec-8">
      <title>Apache Ant</title>
      <p>: (13x5)+(14x4)+(40x3)+(31x2)+(2x1) = 305</p>
    </sec>
    <sec id="sec-9">
      <title>Apache Archiva</title>
      <p>: (1x5)+(5x4)+(79x3)+(14x2)+(1x1) = 291
(1)
(2)</p>
      <p>Denklem 1 ve Denklem 2 incelendiğinde Apache Ant ürünü pazara çıkış süresinden
itibaren karşılaştığı hataların daha ciddi hatalar olduğu anlaşılmaktadır. Bu sonucun ise
ürün seçiminde tercih edilebilirliği negatif yönde etkileyebileceği düşünülmektedir.</p>
      <p>Dolayısıyla hem kod-tabanlı değerlendirme sonuçlarına hem de toplum-tabanlı
değerlendirme sonuçlarına göre iki aday yazılım arasında Apache Archiva ürününün
Apache Ant ürününe göre daha tercih edilebilir ürün olduğu sonucu çıkarılmıştır.
5</p>
      <p>Sonuçlar ve Gelecek Çalışmalar
Bu çalışmada ihtiyaç sahiplerinin alternatif açık kaynak yazılım ürünleri arasından
kendi gereksinimlerine göre değerlendirme ve seçme yaparken takip edecekleri standart
bir yöntem konusunda yeterli akademik çalışma bulunmayışından yola çıkılmıştır. Bu
eksikliği gidermek için literatürdeki yöntemler analiz edilmiş ve kapsamlı bir iki
boyutlu yöntem geliştirilmiştir. Bu yöntemle açık kaynak yazılım ürününün hem
kod-tabanlı hem de toplum-tabanlı değerlendirilmesi yapılmıştır. Bu geliştirilen yöntemi
desteklemek için bir vaka çalışması yapılmış ve aynı maksada yönelik iki alternatif ürün
arasından kalite gereksinimlerini daha iyi karşılayan ürün seçilmeye çalışılmıştır.
Özellikle toplum tabanlı değerlendirmeye yönelik değerlendirmeler henüz başlangıç
seviyesinde olmasına rağmen, tartışmaları tetikleyici ve bundan sonraki çalışmalara yol
gösterici niteliktedir.</p>
      <p>Bu geliştirdiğimiz yöntem gelecekte, kod-tabanlı değerlendirme yapmak için Tablo
1’de görülen kalite modellerinin hepsinin ortak olarak önerdiği tüm öznitelikler için
uygulanmaya çalışılacaktır. Ayrıca toplum-tabanlı değerlendirme yapmak için açık
kaynak yazılım ürünleri internet siteleri derinlemesine analiz edilip değerlendirme
yapmak için yeni tarihsel veriler ve veri analiz yaklaşımları bulunmaya çalışılacaktır.</p>
    </sec>
  </body>
  <back>
    <ref-list>
      <ref id="ref1">
        <mixed-citation>
          1.
          <article-title>Open-source software</article-title>
          . URL https://en.wikipedia.org/wiki/Open-source_software
        </mixed-citation>
      </ref>
      <ref id="ref2">
        <mixed-citation>
          2.
          <string-name>
            <given-names>TR</given-names>
            <surname>Açık Kaynak Kod Platformu</surname>
          </string-name>
          , URL https://acik-kaynak.org.tr
        </mixed-citation>
      </ref>
      <ref id="ref3">
        <mixed-citation>
          3.
          <string-name>
            <surname>Noyes</surname>
          </string-name>
          , K. Senior U.S. Correspondent, PCWorld, Apr
          <volume>17</volume>
          ,
          <year>2013</year>
          , http://www.pcworld.com/article/2035651/open-source
          <article-title>-is-taking-over-the-software-worldsurvey-says</article-title>
          .html
        </mixed-citation>
      </ref>
      <ref id="ref4">
        <mixed-citation>
          4.
          <string-name>
            <surname>Maki-Asiala</surname>
            ,
            <given-names>P.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Matinlassi</surname>
            ,
            <given-names>M.</given-names>
          </string-name>
          :
          <article-title>Quality Assurance of Open Source Components: Integrator Point of View</article-title>
          .
          <source>In: 30th Annual Int. Computer Software and Applications Conference</source>
          (
          <year>2006</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref5">
        <mixed-citation>
          5.
          <string-name>
            <surname>Taytaş</surname>
            ,
            <given-names>E.F.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Gün</surname>
            ,
            <given-names>M.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Dinçer</surname>
            ,
            <given-names>K.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Baştüzel</surname>
            ,
            <given-names>S.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Tekin</surname>
            ,
            <given-names>B.: Kamu</given-names>
          </string-name>
          <string-name>
            <surname>Kurumları Tarafından Yazılım Satın Alma Sürecinde Kullanılacak Etkin Bir Yöntem</surname>
          </string-name>
          <article-title>Geliştirilmesi</article-title>
          .
          <source>In: Proc. of the 9th Turkish National Software Engineering Symposium</source>
          . Izmir,
          <string-name>
            <surname>Turkey</surname>
          </string-name>
          (
          <year>2015</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref6">
        <mixed-citation>
          6.
          <string-name>
            <surname>Hauge</surname>
            ,
            <given-names>O.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Osterlie</surname>
            ,
            <given-names>T.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Sorensen</surname>
            ,
            <given-names>C.F.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Garea</surname>
            ,
            <given-names>M.:</given-names>
          </string-name>
          <article-title>An Empirical Study on Selection of Open Source Software-Preliminary Results</article-title>
          . In: Emerging Trends in Free/Libre/Open Source Software Research and Development. IEEE, (
          <year>2009</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref7">
        <mixed-citation>
          7.
          <string-name>
            <surname>Wheeler</surname>
            ,
            <given-names>D.A.</given-names>
          </string-name>
          :
          <article-title>How to Evaluate Open Source Software/Free Software (OSS/FS) Programs</article-title>
          . URL http://www. dwheeler. com/oss_fs_eval. html, (
          <year>2007</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref8">
        <mixed-citation>
          8.
          <string-name>
            <surname>Deprez</surname>
            ,
            <given-names>J.C.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Alexandre</surname>
            ,
            <given-names>S.</given-names>
          </string-name>
          :
          <article-title>Comparing Assessment Methodologies for Free/Open Source Software: OpenBRR and QSOS</article-title>
          .
          <source>In: Int. Conference on Product Focused Software Process Improvement</source>
          . Springer, (
          <year>2008</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref9">
        <mixed-citation>
          9. QSOS.
          <article-title>Method for Qualification and Selection of Open Source Software (QSOS), version 1.6</article-title>
          . URL http://www.qsos.org.
        </mixed-citation>
      </ref>
      <ref id="ref10">
        <mixed-citation>
          10.
          <string-name>
            <surname>Business</surname>
          </string-name>
          <article-title>Readiness Rating for Open Source</article-title>
          . URL http://www.openbrr.org.
        </mixed-citation>
      </ref>
      <ref id="ref11">
        <mixed-citation>
          11.
          <string-name>
            <surname>Sung</surname>
            ,
            <given-names>W.J.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Kim</surname>
            ,
            <given-names>J.H.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Rhew</surname>
          </string-name>
          , S.Y.:
          <article-title>A Quality Model for Open Source Software Selection</article-title>
          .
          <source>in Advanced Language Processing and Web Information Technology. In: Sixth International Conference on. IEEE</source>
          , (
          <year>2007</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref12">
        <mixed-citation>
          12.
          <string-name>
            <surname>Rawashdeh</surname>
            ,
            <given-names>A.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Matalkah</surname>
            ,
            <given-names>B.</given-names>
          </string-name>
          :
          <article-title>A New Software Quality Model for Evaluating COTS Components</article-title>
          .
          <source>In: Journal of Computer Science</source>
          ,
          <volume>2</volume>
          (
          <issue>4</issue>
          ), p.
          <fpage>373</fpage>
          -
          <lpage>381</lpage>
          (
          <year>2006</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref13">
        <mixed-citation>
          13.
          <string-name>
            <surname>Samoladas</surname>
            ,
            <given-names>I.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Gausios</surname>
            ,
            <given-names>G.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Spinellis</surname>
            ,
            <given-names>D.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Stamelos</surname>
            ,
            <given-names>I.</given-names>
          </string-name>
          :
          <article-title>The SQO-OSS Quality Model: Measurement Based Open Source Software Evaluation</article-title>
          . In: Open Source Development, Communities And Quality. Springer, p.
          <fpage>237</fpage>
          -
          <lpage>248</lpage>
          (
          <year>2008</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref14">
        <mixed-citation>14. Scitools | Build Notes. URL https://scitools.com/build-notes/</mixed-citation>
      </ref>
      <ref id="ref15">
        <mixed-citation>
          15.
          <string-name>
            <surname>Erdemir</surname>
            ,
            <given-names>U.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Tekin</surname>
            ,
            <given-names>U.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Buzluca</surname>
            ,
            <given-names>F.</given-names>
          </string-name>
          :
          <article-title>Nesne Yönetimli Yazılım Metrikleri ve Yazılım Kalitesi. Yazılım Kalitesi ve Yazılım Geliştirme Araçları Sempozyumu</article-title>
          ,
          <string-name>
            <surname>İstanbul</surname>
          </string-name>
          (
          <year>2008</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref16">
        <mixed-citation>
          16.
          <string-name>
            <surname>Calp</surname>
            ,
            <given-names>M.H.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Arıcı</surname>
          </string-name>
          , N.:
          <article-title>Nesne Yönelimli Tasarım Metrikleri ve Kalite Özellikleriyle İlişkisi</article-title>
          .
          <source>Politeknik Dergisi 14.1</source>
          (
          <year>2011</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref17">
        <mixed-citation>
          17.
          <string-name>
            <surname>Chidamber</surname>
            ,
            <given-names>S.R.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Kemerer</surname>
            ,
            <given-names>C.F.</given-names>
          </string-name>
          :
          <article-title>A metrics suite for object oriented design</article-title>
          .
          <source>IEEE Transactions on Software Engineering</source>
          ,
          <volume>20</volume>
          (
          <issue>6</issue>
          ): p.
          <fpage>476</fpage>
          -
          <lpage>493</lpage>
          (
          <year>1994</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref18">
        <mixed-citation>
          18.
          <string-name>
            <surname>Mockus</surname>
            ,
            <given-names>A.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Fielding</surname>
          </string-name>
          , R.T.,
          <string-name>
            <surname>Herbsleb</surname>
            ,
            <given-names>J.D.</given-names>
          </string-name>
          :
          <article-title>Two case studies of open source software development: Apache and Mozilla</article-title>
          .
          <source>ACM Transactions on Software Engineering and Methodology</source>
          .
          <volume>11</volume>
          (
          <issue>3</issue>
          ): p.
          <fpage>309</fpage>
          -
          <lpage>346</lpage>
          (
          <year>2002</year>
          )
        </mixed-citation>
      </ref>
    </ref-list>
  </back>
</article>