<!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>Projede Bir Müşteri Avukatı: Bağımsız DG Ekibi</article-title>
      </title-group>
      <contrib-group>
        <contrib contrib-type="author">
          <string-name>Ayşegül KURT</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>Ali GÜRBÜZ</string-name>
          <email>ali.gurbuz@tubitak.gov.tr</email>
          <xref ref-type="aff" rid="aff0">0</xref>
          <xref ref-type="aff" rid="aff1">1</xref>
        </contrib>
        <contrib contrib-type="author">
          <string-name>Merve ASTEKİN</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>Mustafa SARI</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>Mehmet ŞAHİNOĞLU</string-name>
          <xref ref-type="aff" rid="aff0">0</xref>
          <xref ref-type="aff" rid="aff2">2</xref>
        </contrib>
        <aff id="aff0">
          <label>0</label>
          <institution>Anahtar Kelimeler. Yazılım Doğrulama ve Geçerleme</institution>
          ,
          <addr-line>Müşteri Avukatı, Yazı- lım Test, Çalışma Modelleri</addr-line>
        </aff>
        <aff id="aff1">
          <label>1</label>
          <institution>Bilişim Teknololojileri Enstitüsü, TÜBİTAK BİLGEM</institution>
          ,
          <addr-line>Gebze, Kocaeli</addr-line>
        </aff>
        <aff id="aff2">
          <label>2</label>
          <institution>Yazılım Test ve Kalite Değerlendirme Merkezi, TÜBİTAK BİLGEM</institution>
          ,
          <addr-line>Gebze, Kocaeli</addr-line>
        </aff>
      </contrib-group>
      <abstract>
        <p>Özet. Yazılım proje yöneticileri hedefledikleri bütçe ve takvim içerisinde hatalardan arındırılmış ve kendisinden beklenen işlevleri yerine getiren yazılımlar geliştirmek isterler. Bir yazılımın hatalardan arındırılmış olduğunun ve beklenen işlevleri yerine getirdiğinin gösterilmesi doğrulama ve geçerleme faaliyetinin bir parçası olan yazılım testlerinin temel amacıdır. Ancak yazılım testleri projelere beklenen bütçe ve zaman içerisinde kalması yönünde pozitif yönde katkı sağlamasına rağmen bunu başarmak için yeterli değildir. Bunun yanında yazılım test faaliyetleri, gözden geçirmeler ve statik analizler ile mutlaka desteklenmelidir ki doğrulama ve geçerleme faaliyetleri de tam olarak gerçekleştirilmiş olsun. Yazılım testlerinin iyi anlaşılması, projelerde doğru şekilde uygulanması proje başarılarını ve dolayısı ile, kalitesini arttıracaktır. Yazılım testlerinden en üst seviyede fayda sağlanması, proje içerisinde iyi tanımlanmış ve doğru uygulanan bir yazılım test stratejisine ve daha da önemlisi iyi bir doğrulama ve geçerleme ekibine bağlıdır. Bu çalışma kapsamında Bilişim Teknolojileri Enstitüsü ve Yazılım Test ve Kalite Değerlendirme Merkezi olarak projelerimizde uyguladığımız “Müşteri Avukatı (User Advocate)” kavramı, çalışma şekli ve süreci incelenecektir.</p>
      </abstract>
    </article-meta>
  </front>
  <body>
    <sec id="sec-1">
      <title>Giriş</title>
      <p>Yazılım endüstrisi dünyanın en büyük endüstrilerin biridir. Bu alanda geliştirilen
ürünlerin büyüklüğü ve insan hayatının her alanınında yer alması, bu endüstrinin
önemini daha da arttırmaktadır. Bu endüstri içerisinde üretilen yazılımlar cep
telefonlarımızdan bilgisayarlara, vatandaşlık işlemlerinden sağlık sektörüne, üretimden
tüketime her alanda karşımıza çıkmaktadır. Bu kapsamda aklımıza gelen her alanla ilgili
ihtiyaçların karşılanması için yazılımlar geliştirilmiş, geliştirilmeye devam edilmekte
ve yeni ihtiyaçların karşılanması için de projeler açılmaktadır. Bu alandaki projelerin
başarıyla sonuçlandırılmasının, projelerde üretilen ürünlerin hatalardan arındırılmış
bir şekilde hedeflenen işlevleri tam yerine getirmesinin temel yolu, bu konudaki
standartların ve belirlenmiş süreçlerin en iyi şekilde projelerde uygulanması ve daha
önceki projelerde gerçekleştirilen hataların bu projelerde tekrarlanmamasından
geçmektedir.</p>
      <p>
        Yazılım dünyasının gelişimine bakıldığında, yıllar geçtikçe geliştirilen yazılımların
büyüklüğünün ve karmaşıklığının arttığı görülmektedir. Bu büyüme ve karmaşıklık,
doğası gereği bazı problemleri beraberinde getirmiştir. Aslında yazılım dünyasında
ortaya çıkan problemler, ilk yazılımların geliştirilmesiyle başlamıştır. Bunun başlıca
sebeplerinden biri o günlerde yeni gelişmekte olan yazılım dünyasının elinde daha
önceki projelerden elde edilen tecrübe ve öğrenilen derslerden oluşturulan yeteri
kadar iyi pratiklerinin (best practices) olmayışı ve yazılım geliştirmeyi mühendislik
disiplinleri açısından ele almayışlarıdır. Bu konuda 2004 yılında The Standish Group
tarafından yayınlanan The Chaos Report adlı araştırma ilginç sonuçlar ortaya
koymaktadır [
        <xref ref-type="bibr" rid="ref1">1</xref>
        ]. ABD’de farklı sektörlere farklı ölçeklerde yazılım geliştiren firmaların
gerçekleştirdikleri 30,000 yazılım projesi incelenerek 2004 yılı rakamlarına göre
oluşturulan bu raporda, yazılım projelerinin sadece %34′ünün başarılı, %15′inin
başladıktan sonra iptal edildiği; %51′inin ise tartışmalı, yani zamanında bitirilememiş veya
gereksinimleri karşılamamış şekilde bitirilen projeler olduğu görülmektedir. Bu
rakamları farklı bir şekilde ifade edecek olursak, yazılım sektöründe yapılan gemilerin
%15′inin daha suya indirilmeden battığı sonucuna ulaşılır. Ayrıca rapora göre,
yazılım hataları ABD ekonomisine yılda 60 milyar $’a mal oluyor. Bu rakam yazılımda
kalite problemlerinin ne kadar önemli bir kayba neden olduğunun açık ve çarpıcı bir
göstergesidir.
      </p>
      <p>Bu çalışma içerisinde Bilişim Teknolojileri Enstitüsü olarak gerçekleştirdiğimiz
projelerdeki hata oranının azaltılması, proje başarısının arttırılması, müşterinin ve
kullanıcının istediği ürünlere tam ulaşılabilmesi için Yazılım Test ve Kalite
Değerlendirme Merkezi ile birlikte uyguladığımız “Müşteri Avukatı” rolünü anlatacağız.
Çalışmanın ilk bölümünde, genel olarak projelerin neden başarısız olduğuna dair
bulgular paylaşılacaktır. Sonraki bölümde, başarısızlığın nedenlerini ortadan kaldıran
Müşteri Avukatı rolü açıklanacaktır. Bir sonraki bölümde, Müşteri Avukatı
yaklaşımının proje başarısına etkilerinin incelenmesinin ardından, Müşteri Avukatı rolü ile
gerçekleştirilen projelerde edilinilen deneyimler üzerinde durulacaktır. Son bölümde
ise genel bir değerlendirme ile çalışma sonlandırılacaktır.
2</p>
    </sec>
    <sec id="sec-2">
      <title>Projeler Neden Başarısız Olur?</title>
      <p>Yazılım dünyasındaki başarısızlıklar uzun yıllardan beri tartışılmaktadır.
Başarısızlıklar ortaya çıktıkça bu başarısızlıklar üzerinde yapılan çalışmalar artmış ve bu
çalışmaların sonucunda iyi tanımlanmış ve gelişmeye açık disiplinli bir yazılım geliştirme
yaklaşımının geliştirilmesini sağlamıştır. Başarısızlıkların incelenmesi amacıyla
yapılan çalışmada öncelikle, geliştirilen fakat başarısız olan projelerden kayıtlar tutulmaya
ve başarısızlık noktaları ile nedenleri tespit edilmeye çalışıldı. Bunun yanında
başarıya ulaşmış olan projelerde incelenerek en iyi pratiklere ulaşıldı. Tüm bunların
sonucunda bir yazılım yaşam döngüsü içinde projelerin istenilen maliyet ve takvimde
bitirilmesinde önemli rol oynayan tahminleme teknikleri geliştirilmiştir.</p>
      <p>Günümüze gelindiğinde elimizde on binlerce projeden elde edilen sayısız en iyi
pratikler, iyi tanımlanmış yazılım projeleri yaşam döngüsü ve bu döngü içerisinde
gerçekleştirilecek olan eylemler netleşmiş olarak bulunmaktadır. Ancak tüm bu
çalışmalar gerçekleştirilmesine rağmen yazılım projelerindeki başarısızlıklar
sonlandırılamamıştır.</p>
      <p>
        Proje başarısızlıklarının literatürde [
        <xref ref-type="bibr" rid="ref2 ref3 ref4 ref5">2, 3, 4, 5</xref>
        ] genel olarak aşağıdaki maddelerde
toplandığı görülmektedir.
2.1
      </p>
      <p>Zaman-Bütçe Tahmininde Yanılgı
Özellikle kamu tedariğine yönelik yazılım ihalelerinde projelerin tamamlanma
süreleri genellikle tartışmaya açık olmaksızın müşteri tarafından projelerin başlamasından
önce belirlenir. İlgili yazılım ihalesine çözüm sunacak olan şirketler de çözümlerini
bu varsayım kısıtına yönelik olarak sunarlar. İhalenin alımı ve işin başlaması ile
kesin olan o tarihten önce işin tamamlanmasına yönelik hızlı bir saldırı ile analiz ve
kodlama işlemleri başlar. Ancak işin kalitesi bu aşamada her zaman olduğu gibi ihmal
edilir. Öncelikli olarak hatalı da olsa çalışan bir kodu ortaya çıkarmak hedeflenir. Bu
şekilde geliştirilen yazılımlar her zaman içerisinde hata barındırmaya açıktır.
Görüldüğü gibi, işin içerisinde bir ihale ve en düşük fiyatla bu işin alımı varsa, bu durum
projenin başarısı üzerinde ciddi anlamda risk oluşturmaktadır. Sonuçta; kamunun
tedarik edeceği yazılımların, ihtiyacı tam olarak yansıtmaması, yeterince test
edilmediği için hatalar içermesi, müşteri profili gözetilmediği için kullanılabilirliğinin düşük
olması ve bu yazılımların çöpe atılması söz konusu olmaktadır.
2.2</p>
      <sec id="sec-2-1">
        <title>Müşterinin Anlaşılamaması- İletişim Eksikliği</title>
        <p>Yazılım projelerinin başarısı için müşteri, kullanıcı ve geliştirme ekibi arasındaki
iletişim çok önemlidir. Ortak bir proje dilinin kullanımı, tarafsız bir gözle müşteri
gereksinimlerine ve kullanıcı senaryolarına bakış gereklidir. Geliştirme ekibi böyle
bir iletişimi kursa dahi zaman baskısından dolayı detaya inemez ve bir an önce bir
ürün geliştirmeyi hedefler. Bu şekildeki stresli ortam, daima iletişim kazalarıyla
sonuçlanır. Oluşan iletişim kazaları da yazılım içerisinde hata olarak ortaya çıkar.
2.3</p>
      </sec>
      <sec id="sec-2-2">
        <title>Değişen Müşteri İstekleri</title>
        <p>Teknik anlamda isteklerini tam olarak ifade edemeyen müşteriler ile gereksinimlerin
belirlenmesi safhası, proje başarısında oldukça önemlidir. Geliştirme dönemi
öncesinde tamamlanmaya çalışılan gereksinim belirleme süreci, kritik önem taşımaktadır.
Proje ekibi ile müşteri arasındaki iletişimsizlik ya da fikir değiştiren müşteri,
gereksinimlerin tekrar analiz edilmesine ve tekrar geliştirme döngüsüne girmesine neden
olarak, planlanan zaman ve bütçenin ötesine geçilmesine neden olabilmektedir. Bu
nedenle, gereksinimlerin tanım ve kapsamının netliği ile sabitliği proje başarısını
kritik derecede etkilemektedir.
3</p>
      </sec>
    </sec>
    <sec id="sec-3">
      <title>Projede Bir Müşteri/Sponsor Avukatı: Bağımsız DG Ekibi</title>
      <p>Bilişim Teknolojileri Enstitüsü olarak gerçekleştirdiğimiz projelerdeki hata oranının
azaltılması, proje başarısının arttırılması, müşterinin ve kullanıcının istediği ürünlere
tam olarak ulaşılabilmesi için Yazılım Test ve Kalite Değerlendirme Merkezi ile
birlikte uyguladığımız “Müşteri Avukatı” rolünü Bağımsız bir Doğrulama ve Geçerleme
(DG) ekibine vermekteyiz.
3.1</p>
      <sec id="sec-3-1">
        <title>Yazılım Test ve Kalite Değerlendirme Merkezi (YTKDM)</title>
        <p>Yazılım Test ve Kalite Değerlendirme Merkezi (YTKDM), Devlet Planlama Teşkilatı
(DPT) desteği ile 2010 yılı Şubat ayında TÜBİTAK BİLGEM bünyesinde
faaliyetlerine başlayan bir merkezdir. Yazılım sektörüne hizmet vererek yazılım projelerinin
başarısını arttırmak, yazılımların rekabet gücünü arttırmak için kalite metrikleri
kapsamında değerlendirmeler yaparak belgelendirmek, geliştirilen yazılımları objektif ve
bağımsız şekilde test ederek değerlendirmek amaçları ile kurulmuştur.</p>
        <p>YTKDM, projelerin görünürlüğünü arttırmak ve yazılım projesi müşterisinin
hedeflediği özellikte ürünlere sahip olmayı sağlamak için test hizmetleri, test süreç
danışmanlığı ve yazılım kalite değerlendirme hizmetleri vermektedir.
3.2</p>
      </sec>
      <sec id="sec-3-2">
        <title>Doğrulama ve Geçerleme (DG) Süreci</title>
        <p>Doğrulama ve Geçerleme, yazılım sürecinin her aşamasındaki çıktılarının istenen
özelliklere uygunluğunun kontrolüdür. DG faaliyetleri, proje sözleşmesinin
imzalanması ile başlayan ve projenin resmi olarak sonlandırılmasına kadar olan proje yaşam
döngüsündeki tüm gözden geçirmeleri ve test faaliyetlerini içerir.</p>
        <p>DG süreci, ürün geliştirmedeki hataları erken aşamalarda tespit etmeyi ve
geliştirilen üründeki hata yoğunluğunu azaltmayı hedeflemektedir. Erken safhalarda tespit
edilen hatalar ile, düzeltici faaliyetlerin daha az emek ve daha az maliyet ile daha az
sürede gerçekleştirilmesi sağlanır. Proje başlangıcı itibariyle işletilmeye başlanan
süreç, geliştirilen üründe amaçlanan müşteri gereksinimlerinin yerine tam olarak
getirildiğine dair bir güven oluşturur.
3.3</p>
      </sec>
      <sec id="sec-3-3">
        <title>Bağımsız DG Ekibi Rol ve Sorumluluğu</title>
        <p>Yazılım Test ve Kalite Değerlendirme Merkezi tarafından BTE bünyesindeki
projelerde görevlendirilen DG ekibi, projelerin henüz teklif aşamasında kurulmaktadır.
Kurulan DG ekibi, proje sözleşmesinin imzalanmasıyla birlikte müşteri kurum ile
iletişime geçerek, proje süresince gerçekleştirecekleri faaliyetler ve sorumlulukları ile
ilgili bilgi vermektedir.</p>
        <p>Yazılım ürünleri, yaşam döngüsü boyunca bağımsız bir kuruluş tarafından test
edilir, testleri değerlendirir, test sonuçları belgelendirilir ve tüm safhalardaki gözden
geçirmeleri gerçekleştirilir. Bağımsız olarak gerçekleştirilen bu faaliyetler, objektif
değerlendirmeyi sağlarken, yanlılığı ortadan kaldırmaktadır.</p>
        <p>Bağımsızlık, teknik, yönetimsel ve finansal yönlerden sağlanmaktadır. Yazılım
geliştirici ekipten ayrı olarak yer alan DG ekibi, proje ekibinden farklı bir bakış açısı
getirerek, geliştiriciler tarafından görülemeyen hataların bağımsız bir ekip tarafından
görülmesini sağlar; “Teknik Bağımsızlık” ilkesi ile hareket eder. DG süreci
yönetiminin takvim ve insan kaynağı yönleriyle, proje yönetiminden ayrı bir organizasyon
tarafından yürütülmesi ile “Yönetimsel Bağımsızlık” sağlar. DG Faaliyetleri
bütçesinin kontrolü, yazılımı geliştiren organizasyondan bağımsız bir organizasyon
tarafından yapılarak, “Finansal Bağımsızlık” sağlanmaktadır.</p>
        <p>Teknik, yönetimsel ve finansal yönlerden proje ekibinden bağımsız olan DG ekibi,
proje sözleşmesinin imzalanması aşamasından itibaren faaliyete başlamaktadır.
Gereksinim aşamasında gözden geçirme faaliyetlerinde aktif olarak yer alır. Kullanıcının
tam olarak istediğini zamanında ve planlanan bütçe dahilinde geliştirerek müşteri
memnuniyetini arttırma yönüyle, DG ekibi tarafından bu aşamada gerçekleştirilen
gözden geçirmeler büyük önem taşır. Projenin ilerleyen aşamalarında, ortaya çıkan
değişiklik isteklerini aktif bir şekilde takip ederek, proje güncel durumu hakkında,
bağımsız bir göz ile objektif değerlendirme yapabilmektedir. Değerlendirmeler
sonucunda, gerektiğinde projeye risk bildiriminde bulunup, risk analizlerinin yapılmasını
tetikler. Projenin tüm safhalarında bağımsız olarak gerçekleştirilen gözden geçirmeler
ile sağlanan izleme ve kontrol; müşteri, sponsor ve proje arasındaki iletişime ışık
tutmaktadır. DG ekibi, riskli gördüğü durumları sponsor kuruma/kişiye aktararak,
proje gidişatının üst seviyede izlenmesini sağlar.
3.4</p>
        <p>Çalışma Modelleri
Çalışma Modeli-1: Sponsor Açısından. Bu çalışma modelinde yazılımın üretimine
sponsor olan kurum adına projede görev alınır. Sponsor, yazılım geliştirme projesi
için kaynakları sağlayan/serbest bırakan, onaydan sorumlu kurum ya da yöneticiyi,
Yüklenici ise bu yazılımı geliştiren firmayı belirtmektedir. Çalışma modelinde
aşağıdaki faaliyetler gerçekleştirilmektedir.
─ Projelere, teklif hazırlama aşamasında dahil olunmakta ve “test kaynakları” proje
yönetimi ile birlikte YTKDM tarafından planlanmaktadır.
─ Projelerdeki Doğrulama ve Geçerleme süreci YTKDM personeli tarafından
işletilmektedir.
─ Test planlarının hazırlanması,
─ Gözden geçirmelerin gerçekleştirilmesinin sağlanması ve gözden geçirmelere aktif
katılım,
─ Test durumlarının ve test senaryolarının hazırlanması,
─ Hata yönetim sisteminin kurulması,
─ Proje ekibi ile birlikte test ortamının kurulması,
─ Testlerin gerçekleştirilmesi, hataların tespiti ve bildirimi,
─ Test sonuçların raporlanması,
─ Projelerde gerektiğinde test otomasyonu ile ilgili çalışmalar yapılmaktadır.
Çalışma Modeli-2: Müşteri Açısından. Bu çalışma modelinde yazılımı kullanacak
kurum adına projede görev alınır. Bu çalışma modelinde Müşteri, yazılım ihtiyacı
olan kurumu, Yüklenici ise bu yazılımı geliştiren firmayı belirtmektedir. Çalışma
modelinde aşağıdaki faaliyetler gerçekleştirilmektedir.
 Teknik Şartname hazırlık sürecinde bu çalışma modeline uygun gerekli maddelerin
şartnameye eklenmesi ve teknik şartnamenin son halinin gözden geçirilmesi,
 Proje Başlangıcında Yazılım Test, Kalite ve Yazılım Geliştirme Süreçleri ile ilgili
danışmanlık verilmesi,
 Yüklenici tarafından hazırlanan;
─ Test Planlarının,
─ Gereksinimlerinin,
─ Test Senaryolarının,
─ Test Raporlarının,
─ Test Ortamının gözden geçirilmesi,
 Proje ile ilgili Dönemsel Değerlendirme Raporlarının Müşteri’ye sunulması,
 Belirlenen test faaliyetlerini izleme ve kontrol etme,
 Kabul testlerine eşlik etme,
 Proje Kapanış Raporunun Müşteri’ye sunulması çalışmaları gerçekleştirilmektedir.
3.5</p>
        <p>Çalışma Modellerinin Değerlendirmesi
Çalışma Modeli-1:Sponsor Açısından.</p>
        <p>Avantajları. Bu çalışma modelinin avantajları aşağıda maddeler halinde
listelenmektedir:
 Yüklenicinin yapacağı düzeltici ve iyileştirici faaliyetlerin uygulatılması sponsor
adına müşteri avukatı kurum tasarrufunda olacaktır.
 Projelerin ilerleme süreçlerine dair izleme ve kontrol faaliyetleri, sponsor adına
etkin ve doğru şekilde yapılacaktır.
 Yüklenicilerdeki yazılım geliştirme yaşam döngüsü ile aktif ve bağımsız
uygulanan doğrulama ve geçerleme süreci farkındalığı artacaktır.
 Yetkin personel ile doğrulama ve geçerleme sürecinin kalitesinin artmasına katkı
sağlanacaktır.
 Proje başlangıcı itibariyle işletilmeye başlanan süreçte tespit edilen hatalar ile,
düzeltici faaliyetlerin daha az emek ve daha az maliyet ile daha az sürede
gerçekleştirilmesi sağlanacaktır.
 Proje başından itibaren yürütülen test ve hata ayıklama döngüsü ile, proje kabul
testlerinin daha az hata ile, daha az efor harcayarak, proje süresince kazanılan
yüksek müşteri güveni altında daha kısa sürede tamamlanması sağlanacaktır.
 Performans, güvenilirlik, güvenlik, kullanılabilirlik gibi işlevsel olmayan
gereksinimlerin de olmasını sağlanacak ve testlerin gerçekleştirilmesi denetlecektir.
 Proje bütçesine ek maliyet getiren bu yaklaşım, projenin ileri aşamalarında daha
büyük maliyetlere neden olabilecek hataların erken aşamalarda bulunmasını
sağlaması yönüyle bir kayıp değil; proje başarısı açısından bir avantajdır.
Dezavantajları. Bu çalışma modelinin dezavantajları aşağıda listelenmektedir:
 Proje ekibinin, tüm safhalarda yakından izlendiği bu çalışma modelinde, DG ekibi
ile proje ekibi arasındaki psikolojik faktörler önem kazanmaktadır. Her iki aktörün
de, müşteriyi memnun edecek daha kaliteli yazılım ürünleri için çalıştıkları
unutulmayarak, oluşabilecek karşıtlıkların önüne geçilebilir.
Çalışma Modeli-2: Müşteri Açısından.</p>
        <p>Avantajları. Bu çalışma modelinin avantajları aşağıda maddeler halinde
listelenmektedir:
 Yüklenicinin yapacağı düzeltici ve iyileştirici faaliyetlerin uygulatılması müşteri
adına müşteri avukatı kurum tasarrufunda olacaktır.
 Projelerin izlenmesi ve kontrolü daha etkin yapılacaktır.
 Yüklenicilerdeki doğrulama ve geçerleme süreci (SDLC) farkındalığı artacaktır.
 Yetkin personel ile doğrulama ve geçerleme sürecinin kalitesinin artmasına katkı
sağlanacaktır.
 Performans, güvenilirlik, güvenlik, kullanılabilirlik gibi işlevsel olmayan
gereksinimlerin de olması ve bu gereksinimlerin testlerinin yapılması sağlanacaktır.
 Bu çalışma modeli, proje bütçesine ek maliyet getirmektedir. Fakat bu maliyet,
bağımsız test yaklaşımı ve projenin ileri aşamalarında daha büyük maliyetlere
neden olabilecek hataların erken aşamalarda bulunmasını sağlayarak, proje başarısı
açısından bir avantaja dönüşmektedir.
 Proje başlangıcı itibariyle işletilmeye başlanan izleme ve kontrol faaliyetleri ile,
geliştirilen üründe amaçlanan müşteri gereksinimlerinin yerine tam olarak
getirildiğine dair bir güven ortamı oluşacaktır.</p>
        <p>Dezavantajları. Bu çalışma modelinin dezavantajları aşağıda maddeler halinde
listelenmektedir:
 Bu çalışma modelindeki faaliyetler projeye ek maliyet getirecektir. Fakat, bu
çalışma modeli ile projenin ilerleyen aşamalarında bulunacak hatalar, projenin
başında bulunabilmektedir. Bu hataların erken aşamada bulunması proje açısından ciddi
maliyet düşürücü bir etkisi bulunmaktadır.
 Yüklenici bu çalışma modelinde bulunan hata ve görüşleri uygulamakta isteksiz
olabilmektedir. Bu da Yüklenici açısından bir uyum sorunu oluşturabilmektedir.</p>
      </sec>
      <sec id="sec-3-4">
        <title>Ortak Anlayış</title>
      </sec>
    </sec>
    <sec id="sec-4">
      <title>Müşteri Avukatı Yaklaşımının Proje Başarısına Etkileri</title>
      <p>Müşteri Avukatı, proje başlangıcından itibaren sürece dahil olarak tüm aktörler
arasında ortak bir anlayış kazandırılmasını sağlar. Müşteri ile proje arasında bir nevi
mütercim tercüman davranışıyla, tüm paydaşların ortak anlayışta buluşmasını sağlar.
Müşteri ile projenin ortak dilini oluşturdukları gereksinim belirleme sürecinde,
gereksinimlerin test edilebilirliğinin de kontrol edilmesi ile, gereksinimlerin net, tam,
anlaşılır ve doğrulanabilir olmasına katkıda bulunur.
4.2</p>
      <sec id="sec-4-1">
        <title>Sorgulama</title>
        <p>Müşteri Avukatı, projenin her aşamasında aktif rol aldığı gözden geçirmeler ve takip
ettiği değişiklik isteklerine getirdiği değerlendirmeler ile, her aktörün isteğinin önce
kendisi tarafından sorgulanmasını, sonra da tüm ekip tarafından sorgulanmasını
sağlıyor. Gerçekleştirilecek/Gerçekleştirilen aktivitelerin, oluşan risklerin projeye
etkilerinin düşündürülmesi sağlanmaktadır.
4.3</p>
      </sec>
      <sec id="sec-4-2">
        <title>Müşteriye Güven</title>
        <p>Bağımsız DG ekibi tarafından müşteri adına gerçekleştirilen tüm izleme ve kontrol
işlerinin yakından takibi ile, müşteri güveni kazanılmaktadır. Müşteri tarafında,
projede kendisi adına çıkarlarını koruyan, isteklerini anlayan bir müşteri avukatı
bulunduğuna dair güven hissi hakimdir. Gereksinim aşamasında kullanıcının tam olarak
istediğini ortaya çıkarmaya çalışan bağımsız ekip, bu isteklerin zamanında ve
planlanan bütçe dahilinde geliştirilmesini sağlayarak müşteri güvenini ve memnuniyetini
arttırmaktadır.
4.4</p>
      </sec>
      <sec id="sec-4-3">
        <title>Risk Yönetimi</title>
        <p>Müşteri Avukatı ile her aşaması sorgulanan projelerde, sorgulanan noktaların proje
üzerinde oluşturduğu riskler de bu bağımsız ekip tarafından değerlendirilmektedir.
Projeden bağımsız, müşteri gözüyle risk yönetimi ele alınmaktadır.</p>
        <p>Proje yönetimince, yalnızca bütçe, personel, zaman üzerine hesaplanan risklerin
dışında, yazılım test ve kalite yönleriyle de riskler mevcuttur. Yüksek kod karmaşıklık
değerleri, yazılım bileşenleri arasındaki yüksek bağımlılık, derin kalıtım ağaçları gibi
yazılım kalite metrik değerlerinin işaret ettiği riskler, projelerde göz ardı
edilebilmektedir. Bağımsız DG ekiplerince gerçekleştirilen statik kod analizlerinde alarm verdiği
görülen yazılım kalite metrikleri detaylı analiz edilerek bu tür riskler
öngörülebilmektedir. Bu risklerin erken safhalarda çözümlenmesi, yineleme testleri için harcanan
zaman ve maliyeti azaltmaktadır. Müşteri Avukatı, projeyi yazılım kalite riskleri
yönüyle de değerlendirmektedir.</p>
      </sec>
    </sec>
    <sec id="sec-5">
      <title>Müşteri Avukatı Deneyimi</title>
      <sec id="sec-5-1">
        <title>Sponsor tarafından</title>
        <p>Proje Tanıtımı. Proje, BTE tarafından bir proje ekibine geliştirilmesi görevi verilen
yazılım ürünün doğrulama ve geçerleme faaliyetlerini içermektedir. Sözleşmenin
imzalanması ile başlayan proje yaşam döngüsü süreci boyunca gerçekleştirilen
faaliyetler, periyodik olarak raporlanarak, talep edilen durumlarda BTE yönetimine
iletilmektedir. Proje sözleşmesinin imzalanmasıyla başlayan ve projenin kapatılmasına
kadar olan proje yaşam döngüsündeki tüm gözden geçirmeleri ve test faaliyetlerini
içeren sürecin, TÜBİTAK BİLGEM BTE sürecindeki yeri Şekil-1’de görülebilir.</p>
        <p>Şekil 1. BTE Süreç Haritası
Bu proje kapsamında aşağıdaki faaliyetler gerçekleştirilmiştir:
 Test planlarının hazırlanması
 Tüm Yazılım Geliştirme Süreçlerine ait Yönetimsel ve Teknik Gözden Geçirmeler
ile Dokümantasyon Gözden Geçirmeleri
 Test durumlarının ve test senaryolarının hazırlanması
 Proje ekibi ile birlikte test ortamının kurulması
 Gerekli ve uygun şartlarda test otomasyonu
 Testlerin gerçekleştirilmesi ve sonuçların raporlanması
 Statik kod analizlerinin periyodik olarak gerçekleştirilmesi
Sonuçlar. BTE projelerinde, sürece projenin en başından bağımsız doğrulama ve
geçerleme ekipleri ile katılmak DG faaliyetlerinin başarı olasılıklarını arttırmaktadır.
Erken safhada tespit edilen riskler ve hatalar, düşük maliyet ile kısa sürede
çözülebilmektedir. Sponsor adına teknik izleme ve kontrol faaliyetleri, proje risklerinin
bağımsız olarak değerlendirilmesini sağlamaktadır. Projenin yazılım geliştirme sürecine
başladığı ilk andan itibaren periyodik olarak gerçekleştirilen statik kod analizleri ile,
yazılım ilk satırlarından başlayarak kontrollü olarak denetlenebilmektedir. Bu sayede,
gerekli görülen durumlarda başlatılan kod yeniden düzenlemeleri, daha düşük maliyet
ve kısa zaman planında gerçekleştirilebilmektedir.</p>
        <p>Zaman ve bütçe yönüyle elde edilen nicel kazançlar, proje gizliliği nedeniyle
paylaşılamamaktadır.
5.2</p>
      </sec>
      <sec id="sec-5-2">
        <title>Müşteri tarafından</title>
        <p>Proje Tanıtımı. Proje, bir kamu kurumunun ürün halindeki yazılımlarının analiz ve
değerlendirilmesini içeren bir danışmanlık projesidir. Proje sonunda kuruma bir rapor
iletilerek bu yazılımlar ile ilgili detaylı analiz ve değerlendirmeler yapılmıştır. Bu
proje kapsamında aşağıdaki iş paketleri gerçekleştirilmiştir:
 Keşifsel Testler
Bu iş paketinde, yetkin kişiler tarafından kişilerin tecrübelerine dayalı olarak, hata
oluşma olasılığı yüksek görülen alanlara yoğun test faaliyetleri uygulanır.
 Statik Kod Analizleri
Kaynak kod üzerinde çeşitli yazılım kalite ölçüm araçları kullanılarak, ölçümler
alınması ve bu ölçümlere dayanılarak uzman kişilerce değerlendirme raporu
oluşturulması adımları gerçekleştirilir. Başlıca iyileştirilmesi gereken kod bölümleri listelenerek,
yazılımın alarm veren bölgeleri ortaya çıkarılır.
 Kullanılabilirlik değerlendirmesi
Bir uygulama ya da web sitesinin oluşturulan kontrol listesine dayanılarak
değerlendirmesi gerçekleştirilir.</p>
        <p>Değerlendirme sonucunda kullanılabilirlik açısından iyileştirilmesi gereken
noktalar listelenir. Kullanılabilirlik testlerinin yapılamadığı durumlarda ya da
kullanılabilirlik testleri öncesinde kullanılan pratik bir yöntemdir.
 Yazılım Bakım Yapılabilirlik Çalışmaları
Bakım yapılabilirlik metriklerinin ölçüldüğü ve değerlendirildiği yazılım kalite
değerlendirme çalışmasıdır.
 Kod ve Dokümantasyon Gözden Geçirmeleri
Bir iş ürününün proje çalışanlarına, yöneticilere, kullanıcılara veya diğer ilgili
kişilere, yorum yapmaları veya onaylamaları için sunulması süreci veya bu amaçla yapılan
değerlendirme işlemini kapsar. Kodlar kodlama standartlarına, dokümanlar ise
kontrol listelerine ve gözden geçirme kurallarına göre gözden geçirilmektedir.</p>
        <p>Yapılan her bir çalışma kullanılacak yöntemin açıklaması, çalışma sonunda elde
edilen sonuçlar ve bu sonuçların değerlendirmesinin yapıldığı bölümlerden oluşan bir
formatta hazırlanmıştır.</p>
        <p>Tüm çalışmaların değerlendirmeleri kullanılarak, genel bir değerlendirme
yapılmıştır. Kamu kurumuna bu değerlendirmeler kapsamında neler yapılması ile ilgili
öneriler yapılarak rapor tamamlanmıştır.</p>
        <p>Sonuçlar. Bu rapor kapsamında, iş paketlerinin çıktılarında elde edilen sorunlar
göstermektedir ki, yazılımların yazılım yaşam döngüsü süreçlerinde doğrulama ve
geçerleme süreç faaliyetlerine uyulmadan geliştirildiği ve bunun sonucunda da bakım
yapılabilirliği düşük, yazılım kalite metriklerine göre kötü, test faaliyetleri sonucunda
kritik işlevsel hatalar içeren, birçok dokümantasyon eksikliği olduğu fark edilmiştir.</p>
        <p>Elde edilen deneyime göre, kamu kurumlarının yazılım geliştirme projelerinde
geliştirilen yazılımların teknik şartname ve uyması gereken standartlara uygunluğunun
belirli periyotlarla denetimi projenin başarısı ve müşteri memnuniyeti açısından
önemi hem kamu kurumu, hem firma, hem de YTKDM olarak bir kez daha açık olarak
fark edilmiştir.
6</p>
      </sec>
    </sec>
    <sec id="sec-6">
      <title>Sonuç</title>
      <p>TÜBİTAK BİLGEM YTKDM tarafından uygulanmakta olan “Müşteri Avukatı”
yaklaşımı ile, BTE projelerinde geliştirilen yazılım ürünlerinin kalitesi artmıştır.
Projelerde gerçekleştirilen gözden geçirmeler ile bağımsız bir şekilde etkin yönetilen riskler,
projelerin başarı ile sonuçlanması olasılığını artırmıştır. Müşteri adına gerçekleştirilen
bu detaylı izleme ve kontrol faaliyetleri ile müşteri memnuniyeti üst düzeyde
sağlanmaktadır.</p>
      <p>Proje süresince “Müşteri Avukatı” rolünü üstlenen ve proje ekibinden bağımsız
şekilde faaliyet gösteren DG ekibi, geliştirilen ürünün doğru ve kaliteli bir şekilde,
planlanan zaman ve maliyet çerçevesinde müşteriye sunulmasını sağlayarak, müşteri
memnuniyetini garantilemektedir. YTKDM tarafından BTE projelerinde uygulanan
bu model, Kamu kurumlarından gelen talepler doğrultusunda, değişik Kamu
kurumlarının satın alımlarında da uygulanmış ve başarılı sonuçlar alınmıştır.</p>
      <p>Özgün çözümlerin geliştirilmesi, net tanımlanmış gereksinimler ile bu
gereksinimlerin karşılandığı başarılı projelere bağlıdır. Bu çalışma kapsamında anlatılan yöntem
başarılı yazılım projelerinin geliştirilmesi için kullanılması gereken bir yapıdır.</p>
      <p>Yazılım sektöründe dünya lideri olmamızın en öncelikli şartı küresel
gereksinimlere cevap verebilen, yenilikçi, güvenilir, standartlara uygun, yeni teknoloji üreten ve
kullanan daha çok yerli yazılım üretmemize bağlıdır.</p>
      <p>2016 yılında, küresel yazılım ve hizmet sektörünün 2011’den itibaren % 37,9’lük
bir artış ile 3.422,8 milyar dolarlık pazar değerine sahip olacağı öngörülmektedir.
2011-2016 döneminde, sektörün yıllık bileşik büyüme oranı % 6,6 olarak tahmin
edilmektedir. Türkiye’de Ar-Ge faaliyeti tamamlandıktan sonra satılamayan,
gelişemeyen veya üretime geçemeyen pek çok yazılım projesi yer almaktadır.</p>
      <p>
        Yazılım Sanayicileri Derneği (YASAD)’nin kısa ve orta vadede hedeflerinin
arasında, Türkiye’nin hemen bütün yazılım ihtiyaçlarının yerli ürünlerden sağlanması,
kurumsallaşma, kalite ve rekabetçiliği iyileştirme çalışmaları ve 2015 yılına kadar bir
milyar dolar yazılım ve hizmet ihracat hacmine ulaşılması yer almaktadır [
        <xref ref-type="bibr" rid="ref5">5</xref>
        ]. Daha
uzun vadede kurulu, üye firmaların küresel hale gelmesi, başka küresel firmalarla
işbirlikleri ve sinerjiler geliştirilmesi ve yazılımın ihracat açısından Türkiye
ekonomisinin 2023 yılına kadar en büyük beş sektörü arasına girmesi için çalışma yer
almaktadır. SDE Elektronik Bülten III- 2023 Yazılım Hedeflerine göre, yazılım ve hizmet
ihracat bedelinin 2023 yılında 10 Milyar Dolar olması öngörülmektedir [
        <xref ref-type="bibr" rid="ref6">6</xref>
        ].
      </p>
      <p>Ülkemizin Vizyon 2023 için belirlediği hedeflerine ulaşabilmesinde diğer tüm
sektörlerin yazılıma ihtiyaç duyduğu düşünülürse yazılım sektörü önemli bir noktada
durmaktadır. Yazılım sektörünün gerek özel sektör için, gerekse de kamu için
sunacağı çözümler ve geliştireceği başarılı projeler, küresel kalkınmamıza açık bir katkı
sağlayacaktır. Bu kapsamda, başarısız proje sayısının düşürülmesi, yazılım
sektörünün Türkiye’nin önemli bir ihracat kalemi haline gelebilmesi için devlet destekleri ve
Ar-Ge önceliklerinin yanında, projeler kapsamında Müşteri Avukatı rolünü üstlenecek
danışmanlık desteği almalarının da teşvik edilmesi büyük önem taşımaktadır. Bu
katkının etkinliğinin arttırılması, bu çalışma kapsamında bahsedilen “Müşteri Avukatı”
modeli ile doğrudan ilgilidir.</p>
    </sec>
    <sec id="sec-7">
      <title>Kaynaklar</title>
    </sec>
  </body>
  <back>
    <ref-list>
      <ref id="ref1">
        <mixed-citation>
          1. The Standish Group (
          <year>2004</year>
          ),
          <source>Chaos Report</source>
          , The Standish Group.
        </mixed-citation>
      </ref>
      <ref id="ref2">
        <mixed-citation>
          2.
          <string-name>
            <given-names>D.R.</given-names>
            <surname>Wallace</surname>
          </string-name>
          , and R.U. Fujii, “
          <article-title>Software Verification and Validation: An Overview”</article-title>
          , IEEE Software, May
          <year>1989</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref3">
        <mixed-citation>
          3. http://www.optimum7.
          <article-title>com/internet-marketing/programming-2/top-reasons-why-softwareprojects-fail-and-how-to-avoid-them</article-title>
          .html
        </mixed-citation>
      </ref>
      <ref id="ref4">
        <mixed-citation>
          4.
          <string-name>
            <surname>Lorin</surname>
            <given-names>J</given-names>
          </string-name>
          . May, “Major Causes of Software Project Failures”,
          <source>Crosstalk: The Journal of Defense Software Engineering</source>
          ,
          <year>1998</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref5">
        <mixed-citation>
          5.
          <string-name>
            <surname>Jones</surname>
          </string-name>
          , Capers,
          <source>Patterns of Software Systems Failure and Success</source>
          , International Thompson Computer Press, Boston, Mass.,
          <year>1996</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref6">
        <mixed-citation>
          6.
          <string-name>
            <given-names>SDE</given-names>
            <surname>Yazılım Sektörü E-Bülteni</surname>
          </string-name>
          <string-name>
            <given-names>:</given-names>
            “Yazılımda, Türkiye Neden bir Başarı Hikayesi Olmasın?”,
            <surname>Gülara</surname>
          </string-name>
          <string-name>
            <surname>TIRPANÇEKER</surname>
          </string-name>
          ,
          <year>2012</year>
          .
        </mixed-citation>
      </ref>
    </ref-list>
  </back>
</article>