<!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>Yazılım Geliştirme Hizmetlerinin Satın Alma Yönetiminde COSMIC İşlev Puan Kullanımı</article-title>
      </title-group>
      <contrib-group>
        <contrib contrib-type="author">
          <string-name>Kurtuluş Öztürk</string-name>
          <xref ref-type="aff" rid="aff0">0</xref>
          <xref ref-type="aff" rid="aff2">2</xref>
        </contrib>
        <contrib contrib-type="author">
          <string-name>Selami Bağrıyanık</string-name>
          <xref ref-type="aff" rid="aff0">0</xref>
          <xref ref-type="aff" rid="aff2">2</xref>
        </contrib>
        <contrib contrib-type="author">
          <string-name>Şerife Çağla Özgöç</string-name>
          <xref ref-type="aff" rid="aff0">0</xref>
          <xref ref-type="aff" rid="aff2">2</xref>
        </contrib>
        <contrib contrib-type="author">
          <string-name>Okan Horuz</string-name>
          <xref ref-type="aff" rid="aff0">0</xref>
          <xref ref-type="aff" rid="aff2">2</xref>
        </contrib>
        <contrib contrib-type="author">
          <string-name>Özlem Özenç</string-name>
          <xref ref-type="aff" rid="aff0">0</xref>
          <xref ref-type="aff" rid="aff2">2</xref>
        </contrib>
        <contrib contrib-type="author">
          <string-name>Ersin Ersoy</string-name>
          <xref ref-type="aff" rid="aff0">0</xref>
          <xref ref-type="aff" rid="aff2">2</xref>
        </contrib>
        <contrib contrib-type="author">
          <string-name>Dilek Karahoca</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>Adem Karahoca</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: İşlevsel büyüklük</institution>
          ,
          <addr-line>Yazılım geliştirme hizmet satın alması, COSMIC İşlev Puan, COSMIC Function Point, CFP</addr-line>
        </aff>
        <aff id="aff1">
          <label>1</label>
          <institution>Bahçeşehir Üniversitesi</institution>
          ,
          <addr-line>İstanbul</addr-line>
          ,
          <country country="TR">Türkiye</country>
        </aff>
        <aff id="aff2">
          <label>2</label>
          <institution>Turkcell</institution>
          ,
          <addr-line>İstanbul</addr-line>
          ,
          <country country="TR">Türkiye</country>
        </aff>
      </contrib-group>
      <fpage>2</fpage>
      <lpage>11</lpage>
      <abstract>
        <p>Özet. Bu çalışmada Türkiye'nin en büyük teknoloji ve iletişim hizmetleri sağlayıcı firmalarından birinde gerçekleştirilen yazılım ölçüm dönüşüm programının satın alma hizmetlerindeki etkileri ele alınmıştır. Dönüşüm programının temel adımları, karşılaşılan güçlükler ve faydalar özet olarak açıklanmış, COSMIC İşlev Puan (CFP: COSMIC Function Point) yönteminin satın alma süreçlerine entegrasyonu konusundaki deneyimler ise daha detaylı bir şekilde irdelenmiştir. Söz konusu deneyimler üç temel boyutta ele alınmıştır. Bunlardan birincisi satın alma ekiplerinin sözleşme ve süreçlerinin dönüşümü, ikincisi iş sahibi bilgi teknolojileri ekiplerindeki iş yapış ve hak ediş süreçlerindeki değişimler ve üçüncüsü yazılım geliştirme tedarikçi ekosistemindeki firmaların eğitimleri ve hizmet davranışlarındaki değişimdir. Sonuç olarak dönüşüm programından öncesi ile karşılaştırıldığında oluşan kazanımların bir takım güçlükler yaşansa da toplamda dikkate değer ölçüde olumlu sonuçları olduğu görülmektedir. Bu kazanımların en önemlileri olarak tedarikçilerle işi yaptıran firma arasında gerek teknik gerekse de finansal olarak daha objektif bir mutabakat zemininin oluşması, satın alma ve hak ediş süreçlerinin sadeleşmesi, projelerde yaşanabilecek maliyet öngörü hatalarının azalması ve dolayısıyla iki parti için de risklerin azalması, verimlilik artışı ve maliyetlerin en iyilenmesi, tedarikçi firmanın ürünü sahiplenmesinde ve üretim/kaliteye odaklanmasında artış ve üretilen gereksinim analizi çıktılarında kalite artışı sayılabilir.</p>
      </abstract>
    </article-meta>
  </front>
  <body>
    <sec id="sec-1">
      <title>Use of COSMIC Funtion Point in Procurement of</title>
    </sec>
    <sec id="sec-2">
      <title>Software Development Services</title>
      <sec id="sec-2-1">
        <title>1 Turkcell, İstanbul, Türkiye</title>
        <p>{kurtulus.ozturk, selami.bagriyanik, serife.ozgoc, okan.horuz,
ozlem.yaman@turkcell.com.tr,ersin.ersoy}@turkcell.com.tr
2 Bahçeşehir Üniversitesi, İstanbul, Türkiye
dilek.karahoca@hes.bau.edu.tr, adem.karahoca@eng.bau.edu.tr
Abstract. In this study, the effects of the software measurement transformation
program that was implemented in one of the largest technology and
communications provider in Turkey on procurement services, are discussed. The main steps
of the transformation program are outlined in terms of difficulties and benefits,
and the experience of integrating the COSMIC Function Point (CFP) method into
procurement processes has been explored in more detail. These experiences are
discussed in three main dimensions. The first is the transformation of the
contracts and processes of the procurement teams, the second is the change in the
work processes in the information technology teams, and the third is the change
in the training and service behavior of firms in the software development supplier
ecosystem. As a result, it can be seen that the gains obtained when compared to
the pre-conversion program are considerably positive in total, even though
company had some difficulties in the course of transformation. The most important
of these gains are the formation of a more technical and financially more
objective ground of agreement between the supplier and the contractor, simplification
of the procurement process and the reduction of the costs of forecasting errors in
the projects and thus the risk reduction for both parties, improvement in the focus
of the supplier firm on product ownership and production / quality, and quality
improvement in requirements analysis.</p>
        <sec id="sec-2-1-1">
          <title>Giriş ve İlgili Çalışmalar</title>
          <p>Günümüzde yazılım ürünleri üreten firmaların tüm faaliyetlerini kendi kaynakları ile
gerçekleştirmeleri mümkün değildir. Gerek teknolojinin sürekli gelişmesi ile yeni
alanların ve uzmanlıkların ortaya çıkması, gerek teknolojiye ve dijitalleşmeye olan ihtiyacın
artması ile firmalar yıllar içerisinde dış kaynak ve dış hizmet kullanımına
yönelmişlerdir.</p>
          <p>Turkcell, 1994 yılında kurulduğunda GSM alanında hizmet veren bir mobil şebeke
operatörüyken, zaman içinde; 2G, 3G, 4G ve 4.5G teknolojilerinin ortaya çıkması ile
birlikte ses ve kısa mesaj hizmetlerinin yanında aynı zamanda mobil veri ve sabit
şebeke hizmet sağlayıcısı konumuna gelmiştir. Bu teknoloji ve altyapı gelişimleri ile
birlikte firma; IPTV, eğitim platformu, mesajlaşma uygulaması, müzik arşiv uygulaması
gibi dijital servis ve çözümleri içeren yatırımlara yönelmiştir. Böylece mobil şebeke
operatörü konumundan teknoloji ürünleri üreten ve bunlarla ilgili içerik ve altyapı
hizmetlerini sağlayan konuma gelmiştir. Tüm bu gelişimler yeni uzmanlıklar ve sürekli
artan bir insan kaynağı ihtiyacına yol açmıştır. Böylece firmadaki insan kaynağı
miktarının ve niteliğinin yönetilmesi ihtiyacının yanında, belli alanlarda dışarıdan temin
edilecek dış kaynak, ürün ve hizmetlerin yönetimi de başlı başına bir strateji ve yöntem
gerektirmiştir.</p>
          <p>Proje ve ürün temelli satın alımlar için işgücünü öngörme ve değerleme ihtiyacı
doğmuştur. Bununla birlikte, mevcut ürünler üzerinde yapılan geliştirme ve iyileştirmelerin
satın alımlarında yazılım geliştirme kapsam büyüklüğünü ölçmeye yarayan bir yönteme
ihtiyaç ortaya çıkmıştır. Böylece, yazılım kapsamının ölçümünde firmada CFP yöntemi
kullanılmaya başlanmıştır [1,2]. Daha sonra CFP ölçümünün firmanın gereksinim
modeline uyarlandığı ve otomatik yapılabilir hale getirildiği bir yöntem de tasarlanmıştır
[6].</p>
          <p>Bu bildirinin amacı, yazılım üreten işletmelerde temel bir ihtiyaçlardan biri olan,
yazılım kapsamını ölçmek ve bu ölçüm sonuçlarını kullanarak yapılan ya da yapılacak
olan işi değerlemek veya maliyetini belirlemek için CFP İşlev Puan yönteminin
kullanılmasına dair deneyimin aktarılmasıdır.</p>
          <p>CFP metodu ilk olarak 1979 yılında Albrecht tarafından ortaya atılan ölçüm
yönteminin [3] yıllar içerisinde evrilmesi, farklı varyantlara ayrılması ve gelişimi ile ortaya
çıkmış ve tüm dünyada geçerli hale gelen işlevsel büyüklük ölçümü yöntemlerinden
biri olmuştur [4]. Böylece Common Software Measurement International Consortium
(COSMIC) tarafından tescillenerek bir ISO standardına dönüşmüştür. Genelleştirilmiş
ISO 14143 Yazılım Fonksiyonel Ölçüm Standardizasyonu ile uyumlu ISO/IEC
19761:2003 numaralı kendi standardına sahiptir [5].</p>
          <p>Bir yazılımın fonksiyonel büyüklüğünü ölçebilmek için; yazılımın işlevsel
kullanıcıları ile olan etkileşimindeki veri hareketlerini ve yazılımın veri tabanı katmanı ile
etkileşimindeki veri hareketlerini ölçmek gerekir. İşlevsel kullanıcılar, insan kullanıcılar
olabileceği gibi sensör ve komşu yazılım sistemleri de olabilir. Bu hareketler;
kullanıcılarla veya diğer sistemlerle etkileşim sınırındaki giriş (entry) ve çıkış (exit)
hareketleridir. Aynı şekilde yazılımın veri depolama araçları ile etkileşimindeki hareketler
yazma (write) ve okuma (read)’dır [5]. CFP metodu bu dört temel veri hareketi ile
ölçüm yapar. Belirlenen veri gruplarının sayısı veri hareketlerini ve büyüklüğü artırıcı
etki eder.</p>
          <p>Yöntemin başlıca kullanım alanları olarak şunlar sayılabilir:










</p>
        </sec>
      </sec>
      <sec id="sec-2-2">
        <title>Proje efor/zaman öngörüsü</title>
        <p>Verimlilik ölçümü
İhtiyaç analizi ve kalite ölçüm/iyileştirmesi
Gereksinim değişim oranı
Satın alma yönetimi
Yazılım ürün/proje kapsam fiyat belirleme
Yazılım kalite ölçümü
Teslim hızı
Organizasyon yük dengelemesi
Organizasyon performans ölçümü</p>
        <p>
          Yazılım portföy ölçümü
İşlevsel ölçütlerin yazılım geliştirme satın alma yönetiminde kullanılmasıyla ilgili
daha önce yapılmış çalışmalar mevcuttur. Bu konuda 2004 yılında yapılan bir
çalışmada yazılım satın alma konusunun diğer iş alanlarına göre olgun olmadığının altı
çizilmiş ve işlev puan dahil kontratlarda kullanılabilecek bazı parametreler önerilmiştir
[
          <xref ref-type="bibr" rid="ref6">7</xref>
          ]. Sonraki yıl yapılan bir başka çalışmada mevcut geleneksel satın alma
sözleşmelerinde müşteri ve tedarikçi ilişkiler incelenmiş ve işlev puan bazlı yeni ölçütlerin
kullanımına dair öneriler, deneyimler ve öğrenilen dersler genel olarak paylaşılmıştır [
          <xref ref-type="bibr" rid="ref7">8</xref>
          ].
Daha sonra yapılan bir çalışmada konu ile ilgili literatür verilerek işlevsel büyüklük
ölçütlerinin birer satın alma birimi olarak da kullanılabileceği belirtilmiştir [
          <xref ref-type="bibr" rid="ref8">9</xref>
          ]. Yakın
zamanda IFPUG işlev puan metriği ile ilgili Türkiye’den bir deneyim paylaşılmıştır
[
          <xref ref-type="bibr" rid="ref9">10</xref>
          ]. Bununla birlikte özellikle CFP işlev puan gibi ikinci nesil ölçütler üzerinden satın
alma deneyimine dair deneyim paylaşımları nadirdir. Bu çalışmada, büyük bir tedarikçi
ekosistemine sahip teknoloji firmasındaki geniş çaplı dönüşüm programındaki
deneyimler aktarılacaktır.
2
        </p>
        <sec id="sec-2-2-1">
          <title>Faydalar ve Öğrenilen Dersler</title>
          <p>Yazılım geliştirme faaliyetlerinin kapsamı, bir sistemin uçtan uca geliştirilmesi
olabileceği gibi, var olan bir sistem ya da araç içerisine küçük bir işlev eklemek de olabilir.
İhtiyacın bu denli geniş olması, yapılan işin kapsam belirleme, işgücü ihtiyacı tespiti,
zaman planlaması gibi yönetsel faaliyetlerini de zorlaştırmaktadır. Bu nedenle yazılım
geliştirme firmalarının proje olarak yönettikleri belli başlı büyük işlerinin (dönüşüm,
sistem geliştirme vb.) yanında, ilave özellik ve işlev ekleme, hata çözme, problemleri
giderme gibi çok sayıda küçük işleri de vardır. Tüm bu farklı boyut ve içerikteki işlerin
yönetimi ve ölçümü farklı süreçler gerektirmektedir.
Örneğin uçtan uca bir sistemin geliştirilmesi işini alt yüklenici firmaya ihale etmek,
ana yüklenici ve alt yüklenici firmanın bir araya gelerek, iş kapsam ve tanım
dokümanları (Statement of Work – SOW) üzerinde uzunca bir süre çalışmasını gerektirir. Bu
çalışma sonunda, alt yüklenici firmanın anladığı iş kapsamı üzerinden işgücü tahmini
yapması ve fiyat teklifine dönüştürerek ana yüklenici firmaya iletmesi beklenir. Ancak
kapsamın net olarak anlaşıldığını garanti altına alacak bir ölçüt yoktur. Bunun yanında,
mutabık kalınan iş kapsamının değişen ihtiyaçlar nedeniyle zaman içerisinde ilk
planlanan kapsamdan sapması muhtemeldir. Bu gibi durumları yönetmek için değişiklik
yönetimi koşullarının sözleşme içerisinde net olarak tanımlanması gerekir.</p>
          <p>Benzer şekilde, belirli bir süre zarfında belirli bir sistem ya da benzer sistemler
bütünündeki (domain) küçük ve çok sayıda geliştirme işini alt yüklenici firmaya ihale
etmek için, belirlenecek dönemdeki (aylık, üç aylık, yıllık vb.) iş kapsam büyüklüğünün
ortaya konulması ihtiyacı vardır.</p>
          <p>Yukarıda bahsedilen örneklerle iş yaşamında sıkça karşılaşılmaktadır. Dış kaynak
kullanımı ya da alt yüklenici firma ile çalışmak çoğunlukla belirli bir sözleşme
kapsamında yapılmakta olup, ödemeler için çeşitli yöntemler kullanılmaktadır. Bu amaçla
kullanılan en basit ve bilinen yöntem, dış kaynağın ana yüklenici firma faaliyetlerinde
harcadığı gün sayısı ile kaynağın alt yüklenici firma tarafından belirlenen çalışan-gün
birim fiyatını çarpmak ve toplam ödenecek tutarı tespit etmektir. Ancak bu yöntem,
kaynağın ana yüklenici firma faaliyetlerinde harcadığı yarı zamanlı çalışma günlerini
ve çalışan verimliliği boyutunu göz ardı etmektedir.</p>
          <p>Bu sebeplerle ikinci bir yöntem olarak gerçekte iş üzerinde harcanan zamanın tespit
edilebilmesi için zaman çizelgelerine (timesheet) başvurma gerekliliği doğmuştur.
Ancak zaman çizelgelerinden tespit edilen “iş üzerinde harcanan zaman” esas alınarak
ödeme yapılması, verimlilik boyutunun ödeme ölçütlerine dâhil edilmesini
sağlayamamıştır. Gerçekte ana yüklenici firmaya sağlanan fayda iş için harcanan zaman değil, iş
çıktılarıdır. Bu nedenle, işgücü gibi yazılım geliştirme sürecinin girdileri esas alınarak
ödeme yapılması yerine, üretilen yazılım büyüklüğü ve işlevsellik gibi sürecin çıktıları
üzerinden ödeme yapılması daha anlamlı olacaktır.</p>
          <p>COSMIC İşlev Puan, geliştirilecek yazılımın büyüklüğünü ölçmede kullanılabilecek
bir yöntemdir. Aynı zamanda yazılımın işlevsel kullanıcılarının kullanımına sunulan
fonksiyon sayısını verdiği için, yazılım geliştirme sürecinde üretilen değerin ölçütü
olarak kullanılabilir. Tüm analiz, geliştirme, test ve yönetimsel aktiviteler kullanıcının
işlevsel ihtiyaçlarını karşılamak amacıyla yerine getirilir. Bu bakış açısıyla veri ve/veya
kontrol ağırlıklı yazılımlar için üretilen çıktıyı nicel olarak ifade etmek amacıyla
kullanılabilir.</p>
          <p>Belirli bir dönemde geliştirilecek irili ufaklı tüm işlerin toplamı COSMIC İşlev Puan
olarak tahmin edilip, ihale sürecinde toplam iş kapsamının sayısal ifadesi olarak
kullanılabilir. Böylece ihaleye girecek alt yüklenici adayı firmalar nasıl bir kapsam için teklif
vereceklerini belirli bir hata payıyla da olsa kestirme imkânına sahip olur. Eğer söz
konusu kapsam tek bir proje ise, ortaya çıkacak ürünün geliştirilmesi için kaç COSMIC
İşlev Puanlık (CFP) analiz, geliştirme ve test yapılması gerektiği ortaya konur.
Böylelikle toplam maliyet, diğer bir ifadeyle kontrat değeri belirlenmiş olur.</p>
          <p>Tüm bu ticari süreçleri CFP ile yönetebilmek için öncelikle ilgili iş alanı için iyi bir
talep olgunlaştırma ile projenin planlanması gerekir. Ortaya çıkacak yazılımın
gereksinimleri net olarak belirliyse, CFP ölçümü analiz dokümanları içerisinde net olarak
belirtilir. Eğer gereksinimler belirli değilse tahmini olarak ölçüm ve hesaplama
yapılabilir. Böylece kapsam ana hatlarıyla belirlenmiş olur ve iş tanımı ile birlikte geliştirme ve
test faaliyetleri için hizmet alım ihalesi yapmak için hazırlık evresi tamamlanmış olur.
Hizmet alım ihalesinin amacı birim iş çıktısı için teklif edilen fiyatları değerlendirmek
ve çalışılacak alt yüklenici firmayı belirlemektir. Sürecin sonunda, yazılım geliştirme
içeren bir süreç için CFP başına birim maliyet Şekil 1’deki Adım 1’de gösterildiği
şekilde belirlenmiş olur. Yalnızca kullanıcı ara yüzünü geliştirmek için ihale edilen
modelde ise UIFP (User Interface Function Point) kullanılmaktadır. Ancak bu ölçüt bu
deneyim bildirisinin konusu değildir.</p>
          <p>Ana yüklenici firmanın analiz sürecini kendi kaynakları ile yürüttüğü, geliştirme ve
test süreçlerini ise alt yüklenici firma kaynakları ile yürüttüğü modeli düşünelim.
Analiz ekibi kullanıcı ihtiyaçlarını belirler ve buna uygun bir üst seviye çözüm üzerinde
kullanıcı(ları) ile mutabık kalır. Ardından detay analiz safhasına geçerek belirlediği üst
seviye çözümün kullanım senaryolarını detaylandırmaya başlar. Kullanım senaryoları
doğru kurgulandığında; işlevsel kullanıcılar, sistem/uygulama, veri depolama aygıtları
ve eşlenik diğer sistemler arasındaki veri hareketlerini ve miktarını detaylandırmakta
kullanılabilir. Böylece COSMIC İşlev Puan değerlerini de ölçmeye elverişli bir analiz
ortaya çıkmış olur. Analiz dokümanlarında belirlenen COSMIC İşlev Puan alt yüklenici
firmaya gönderilir ve kapsam üzerinde mutabakat sağlanır. Eğer alt yüklenici firma
ölçülen kapsama itiraz ederse bunu analiz dokümanı üzerinden kolaylıkla iletebilir.
[Şekil 1: Adım 2]</p>
          <p>İlk kez mutabakat sağlandığında işin kapsamı, işgücü, fiyatı belirlenmiş ve alt
yüklenicinin üretim takvimine, ana yüklenici firmanın ise ödeme planına eklenmiş olur.
Kullanıcı kabul testleri tamamlandığında da teslimat yapılmış sayılır ve ilgili kapsam
için ödeme yapılır. [Şekil 1: Adım 3]
Şekil 1 CFP yöntemi ile ihale ve sözleşme yönetimi</p>
          <p>COSMIC İşlev Puanı ile yapılan satın alma uygulamaları, ağırlıklı olarak daha önce
dış kaynak kiralama yöntemiyle yapılan satın alımlar yerine ikame olarak
kullanılmaktadır. CFP, özgeçmişi referans alarak yapılan kaynak kiralama yöntemine olan ihtiyacı
tamamen ortadan kaldırabilecek bir imkân sunmaktadır. Bu sayede özgeçmiş bazlı
kaynak kiralamanın aksine, satın alma için oldukça önemli e–ihale, açık eksiltme ihale
yöntemleri rahatlıkla ve sıklıkla kullanılabilmektedir. Yazılım geliştirme hizmetleri,
farklı yazılım teknolojilerini barındırmaktadır. Bu durumda her bir yazılım teknolojisi,
tüm kategoriler içinde değerlendirilip Tablo 1’de gösterildiği gibi, bir COSMIC İşlev
Puanı için birim fiyat bedelini içeren katalog tablosu hazırlanabilmektedir. Böylece,
CFP katalog tablosu ile hem satın alma kalemleri sadeleşmiş ve yönetimi kolaylaşmış
olur; hem de ciddi bir ortalama fiyat veri havuzu oluşturularak karşılaştırma olanağı
sağlanmış olur.</p>
        </sec>
      </sec>
      <sec id="sec-2-3">
        <title>Tablo 1 Birim CFP Maliyetleri</title>
        <p>Yazılımın iş alanı</p>
      </sec>
      <sec id="sec-2-4">
        <title>Kurumsal İş Çözümleri Kampanya Çözümleri Dijital Eğitim Çözümleri</title>
        <p>Yazılımdaki Teknoloji</p>
        <p>Seti
*a
*b
*c
* Firmaya özel fiyat bilgileri paylaşılmamıştır.</p>
        <p>Birim maliyet
*x TL/CFP
*y TL/CFP
*z TL/CFP</p>
        <p>Yazılım geliştirme hizmetinin bir ölçüt ile ölçülebiliyor olması sayesinde sözleşme
yapısı ve içeriği de CFP’ye uygun bir şekilde revize edilmiştir. CFP bazında yapılan
satın almaların sözleşmelerinde rahatlıkla Hizmet Seviyesi Kontratı (HSK) bazlı
Anahtar Başarı Faktörleri (ABF) tabloları ile satın alınan hizmetin başarısı takip
edilebilmektedir. ABF’lerin takibi sonucunda verdikleri hizmetin içeriğine göre firmalara
belirli aşamalarda ceza kesilebilmektedir. Sözleşmeye eklenen ABF tabloları; üretkenlik,
üretilen iş hacminin kalitesi, teslim sürelerine uyum, şirket içi ve şirket dışında
uyulması gereken diğer regülasyon kuralları gibi ölçütleri içermektedir.</p>
        <p>Yeni sözleşme yapısında ücret maddelerinde de düzenlemeler yapılmıştır. Sözleşme
kapsamında CFP başına alınacak ödeme dışında masraf, ücret, donanım, ekipman gibi
üretilen işin doğrudan çıktıları dışında bir ödeme yapılmaması esasları yer alır. Böylece
tüm giderler iş çıktısına dahil edilecek şekilde bir anlaşma sağlanır. Bu durum alt
yüklenici firmayı HSK’ye konu olan ABF maddelerine uyum sağlamak ve ödeme
alabilmek için ortaya iş çıktısı koymak için motive etmektedir.</p>
        <p>Firmalar ile yapılan iş çıktısı odaklı ve CFP bazlı HSK hizmet sözleşmeleri
sonucunda, hizmet alınan firmanın çalışanlarının hizmet alan firmanın ofisinde bulunma
gerekliliği, toplantı katılımları dışında ortadan kalkmıştır. Alt yüklenici firma
çalışanlarının kendi ofislerinde çalışıp, hizmetin ifası için gerekecek olan iç ve dış eğitimleri ve
kullanacakları demirbaşları kendi öz sermayeleri ile almaları, ana yüklenici firma
tarafında yatırım ve ofis kullanım maliyetleri bakımından verimlilik sağlamaktadır. Aynı
zamanda ARGE merkezine sahip olan alt yüklenici firmalar, çalışanlarının kendi
ofislerinde çalışması sayesinde ARGE teşviklerinden de yararlanabilmektedir.</p>
        <p>Hizmet veren Firma HSK ABF’lerine uyacak ekibi kendisi kurup yönettiği için
ayrıca teknik görüşmelerin önemi artmış olup ihale karar sürecinde iş birimlerinin de ihale
sürecindeki rolü daha disiplinli yürütülmektedir. CFP ile beraber tüm sözleşmelerin
HSK bazlı olması ile değişen iş yasasına uyum da desteklenmiştir.
3</p>
        <sec id="sec-2-4-1">
          <title>Sonuçlar</title>
          <p>CFP bazlı anlaşma modellerinin katkıları farklı noktalarda ölçülebilir. Satın alma
gibi verinin çok değerli olduğu bölümlerde, somut çıktılar oldukça önemlidir. CFP de
veriye dayalı olması ve satın alınan hizmeti sayısallaştırıp ölçülebilir hale getirdiği için
önemli avantajlar sağlamış ve bu nedenle firma içinde değerli bir araç haline gelmiştir.
Sürekli geliştirilebilir yapısı ile gelecek dönemde yazılım dünyasında ve satın alma
alanında yaygınlaşması beklenmektedir.</p>
          <p>Satın alma, bir firmanın parasını harcayan bölüm olarak; yaptığı anlaşmaların
tamamında daha az para ile daha çok fayda sağlamak için tasarruf yapma yönünde çalışır.
Bu tasarrufu her zaman indirimler sağlayarak değil, çoğu zaman model değiştirerek
sağlamaktadır. CFP de bu kapsamda; firmanın doğrudan verimliliğini arttırmakta ve
firmaya doğru yönetim ile mali avantaj sağlamaktadır. Satın alma bölümünün bu bakış
açısına ek olarak iş sahibi de kaliteden ödün vermeden en uygun fiyatlı hizmeti satın
almış olur. Ayrıca tedarikçi de adil ve zarar etmeyeceği kaliteli bir hizmet vermek ister.
CFP modeli bu üç motivasyonun optimizasyonunu kazan-kazan prensibi ile
destekleyen bir perspektif sağlar.</p>
          <p>Bu yapı aynı zamanda, işin mutfağından diye nitelendirilen üçüncü parti firmalara
da ulaşmaya katkı sağlamaktadır. ARGE merkezlerindeki yeni girişimciler, yerel
üretim yapan Kobi’ler, büyük hacme sahip küresel firmalarla birlikte
değerlendirilebilmektedir.</p>
          <p>Olumlu sonuçlara ulaşırken öğrenilen ve geliştirilen birçok yeni süreç
bulunmaktadır. Bunlardan en önemlisi; hak ediş kontrolleri ve uygulamasıdır. CFP’nin sağlıklı bir
şekilde işletilebilmesi için en önemli konulardan biri doğru gereksinim analizi
yapılmasıdır. Bu analizlerin doğru yapılması ile birlikte erken maliyet kestirimlerinin de aynı
şekilde doğru ve net yapılması önemlidir. CFP ile birlikte yapılan anlaşmalarda,
firmalara herhangi bir taahhüt verilmediğinden ve gerçekleşen hak ediş üzerinden ödeme
yapıldığından bahsetmiştik. Bu doğrultuda; yapılan ihalelerde firmalara aktarılan
hacim, firmaların verdiği tekliflere doğrudan etki etmektedir. Bu hacim bilgisi; kurulacak
ekip yetkinliği, büyüklüğü gibi konuları da doğrudan etkilemektedir. Bu kestirimler,
ciddi fark ile gerçekleştiklerinde; Firmalar mali açıdan ciddi sıkıntılar yaşamakta ve
hizmetin sürekliliğinde sorun yaşanabilmektedir.</p>
          <p>Kendine has özellikleri (teknolojiler, iş alanı, üretilmiş bulunan yazılımın kalite
durumu, nasıl bir ekiple üretilmiş olduğu, vb.) bulunan bir geliştirme işi ilk defa dış hizmet
alımı ile yürütülmeye başlanacaksa ihale öncesi, geçmiş verilerden ortalama birim CFP
maliyetlerinin ve beklenen iş hacimlerinin öngörülmesi ve gerçekçi bir öngörü ile
ihaleye hazırlık yapılması hem işi veren hem de hizmeti sağlayan firma açısından hayati
önemdedir. Firma yaptırılacak işi çok iyi ifade etmeli, tedarikçi firmalar da işi tüm
yönleri ile çok iyi anlamalıdır. Böylece aday firmalar, maliyet ve gelir analizlerini daha
sağlıklı yaparak fiyatlama yaptığında, hem rekabetçi hem de gerçekçi bir fiyat
ölçeğinde teklif verebilecektir. Verimlilik hesabını sağlıklı bir şekilde yapamazlarsa ya
standart fiyat bandının üzerinde kalıp pahalı kalacak ya da çok altında kalıp gerçekçi
olmayan bir teklifle gelmiş olacak ve ihaleyi büyük olasılıkla kazanamayacaklardır. Bu
nedenle satın alma birimleri, detaylı bir şartname taslağı ile hareket ederek ihale ve
sözleşme döneminde gri bir alan bırakmadan kazan kazan bir alım süreci için ortamı
kontrol etmelidir.</p>
          <p>CFP yönteminin kullanılması satın alma sözleşmeleri üzerinde bir takım kısıtlar da
oluşturmaktadır. CFP, işlevsel gereksinimlerin ölçümünde kullanılabildiği için proje
kapsamlarındaki gereksinimlerin işlevsel tipte olanlarının hacim olarak baskın olduğu
durumlarda kullanışlıdır. Bu durumda işlevsel olmayan gereksinimler birer maliyet
faktörü olarak düşünülüp ihmal edilebilir. Bu deneyim paylaşımında da bu varsayım
geçerlidir. Bununla birlikte kapsamda daha çok yazılım hatalarının düzeltilmesi, görsel
kullanışlılık düzenlemeleri, güvenlik ihtiyaçları gibi işlevsel olmayan gereksinimler
mevcutsa CFP’nin tek başına kullanımı uygun olmayabilir. Bu durumda işlevsel
olmayan gereksinimlerin ölçümü için destekleyici bir takım ölçütler ile de model
genişletilmelidir. Örneğin görsel düzenlemeler için bir ölçüm metriği üzerinde çalışılmakta ve
gelecekte yayınlanması planlanmaktadır. Yöntemin uygulanması sonucu elde edilen
sayısal verilerin kalite, verimlilik, maliyet öngörüsü ve başka amaçlar için kullanılması
da gelecekte hedeflenen araştırma alanlarından birisidir.</p>
          <p>Kaynaklar
1.</p>
        </sec>
      </sec>
    </sec>
  </body>
  <back>
    <ref-list>
      <ref id="ref1">
        <mixed-citation>
          <string-name>
            <surname>Bağrıyanık</surname>
            ,
            <given-names>S.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Karahoca</surname>
            ,
            <given-names>A.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Ersoy</surname>
            <given-names>E.</given-names>
          </string-name>
          :
          <article-title>Selection of a functional sizing methodology: A telecommunications company case study</article-title>
          .
          <source>Global Journal on Technology</source>
          <volume>7</volume>
          ,
          <fpage>98</fpage>
          -
          <lpage>108</lpage>
          (
          <year>2015</year>
          ).
        </mixed-citation>
      </ref>
      <ref id="ref2">
        <mixed-citation>
          <string-name>
            <surname>Salmanoğlu</surname>
            ,
            <given-names>M.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Öztürk</surname>
            ,
            <given-names>K.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Bagriyanik</surname>
            ,
            <given-names>S.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Ungan</surname>
            ,
            <given-names>E.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Demirörs</surname>
            ,
            <given-names>O.</given-names>
          </string-name>
          :
          <article-title>Benefits and challenges of measuring software size: early results in a large organization</article-title>
          .
          <source>In 25th International Workshop on Software Measurement and 10th International Conference on Software Process and Product Measurement</source>
          , pp.
          <fpage>103</fpage>
          -
          <lpage>114</lpage>
          . IWSM-Mensura,
          <article-title>(</article-title>
          <year>2015</year>
          ).
        </mixed-citation>
      </ref>
      <ref id="ref3">
        <mixed-citation>
          <string-name>
            <surname>Albrecht</surname>
            ,
            <given-names>A.</given-names>
          </string-name>
          ,
          <string-name>
            <given-names>J.</given-names>
            ,
            <surname>Gaffney</surname>
          </string-name>
          ,
          <string-name>
            <surname>J.</surname>
          </string-name>
          ,
          <string-name>
            <given-names>E.: Software</given-names>
            <surname>Function</surname>
          </string-name>
          ,
          <source>Source Lines of Code, and Development Effort Prediction: A Software Science Validation. IEEE Transactions on Software Engineering SE-9</source>
          (
          <issue>6</issue>
          ),
          <fpage>639</fpage>
          -
          <lpage>648</lpage>
          (
          <year>1983</year>
          ).
        </mixed-citation>
      </ref>
      <ref id="ref4">
        <mixed-citation>
          <string-name>
            <surname>Bundschuh</surname>
            ,
            <given-names>M.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Dekkers</surname>
            ,
            <given-names>C.</given-names>
          </string-name>
          : The IT Measurement Compendium. Springer - Verlag, Berlin (
          <year>2008</year>
          )
          <article-title>Common Software Measurement International Consortium</article-title>
          .
          <source>The COSMIC Functional Size Measurement Method Version 4.0</source>
          .1 Measurement Manual, http://cosmic-sizing.org/publications/measurement-manual-401http://cosmic-sizing.org/publications/measurement-manual-
          <volume>401</volume>
          .
        </mixed-citation>
      </ref>
      <ref id="ref5">
        <mixed-citation>
          <string-name>
            <surname>Bagriyanik</surname>
            ,
            <given-names>S.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Karahoca</surname>
            ,
            <given-names>A.</given-names>
          </string-name>
          :
          <string-name>
            <surname>Automated COSMIC Function</surname>
          </string-name>
          <article-title>Point measurement using a requirements engineering ontology</article-title>
          .
          <source>Information &amp; Software Technology</source>
          <volume>72</volume>
          ,
          <fpage>189</fpage>
          -
          <lpage>203</lpage>
          (
          <year>2016</year>
          ).
        </mixed-citation>
      </ref>
      <ref id="ref6">
        <mixed-citation>
          7.
          <string-name>
            <surname>Meli</surname>
            ,
            <given-names>R.</given-names>
          </string-name>
          :
          <article-title>The Software Measurement Role in a Complex Contractual Context</article-title>
          . In SMEF2004, (
          <year>2004</year>
          ).
        </mixed-citation>
      </ref>
      <ref id="ref7">
        <mixed-citation>
          8.
          <string-name>
            <surname>Lelli</surname>
            ,
            <given-names>M.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Meli</surname>
            ,
            <given-names>R.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Moretto</surname>
          </string-name>
          , G.:
          <article-title>Practical approaches for the utilization of Function Points in IT outsourcing contracts</article-title>
          .
          <source>In SMEF</source>
          <year>2005</year>
          , (
          <year>2005</year>
          ).
        </mixed-citation>
      </ref>
      <ref id="ref8">
        <mixed-citation>
          9.
          <string-name>
            <surname>Ozkan</surname>
            ,
            <given-names>B.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Turetken</surname>
            ,
            <given-names>O.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Demirors</surname>
            ,
            <given-names>O.</given-names>
          </string-name>
          :
          <article-title>Software functional size: For cost estimation and more</article-title>
          .
          <source>Software Process Improvement 59-69</source>
          (
          <year>2008</year>
          ).
        </mixed-citation>
      </ref>
      <ref id="ref9">
        <mixed-citation>
          10.
          <string-name>
            <surname>Bağcı</surname>
            ,
            <given-names>V. H.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Çıltık</surname>
            ,
            <given-names>A.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Özçelik</surname>
          </string-name>
          , R.:
          <article-title>IFPUG İşlev Puan Metriği ile Yazılım Üretim Hattı Ölçümü</article-title>
          .
          <source>In UYMS</source>
          <year>2013</year>
          , (
          <year>2013</year>
          ).
        </mixed-citation>
      </ref>
    </ref-list>
  </back>
</article>