=Paper=
{{Paper
|id=None
|storemode=property
|title=Projede Bir Müşteri Avukatı: Bağımsız DG Ekibi
|pdfUrl=https://ceur-ws.org/Vol-1072/submission46.pdf
|volume=Vol-1072
|dblpUrl=https://dblp.org/rec/conf/uyms/GurbuzKASS13
}}
==Projede Bir Müşteri Avukatı: Bağımsız DG Ekibi ==
https://ceur-ws.org/Vol-1072/submission46.pdf
Projede Bir Müşteri Avukatı: Bağımsız DG Ekibi
Ayşegül KURT1, Ali GÜRBÜZ2, Merve ASTEKİN1, Mustafa SARI1, Mehmet
ŞAHİNOĞLU1
1
Yazılım Test ve Kalite Değerlendirme Merkezi, TÜBİTAK BİLGEM, Gebze, Kocaeli
1
{aysegul.kurt, merve.astekin, mustafa.sari,
mehmet.sahinoglu}@tubitak.gov.tr
2
Bilişim Teknololojileri Enstitüsü, TÜBİTAK BİLGEM, Gebze, Kocaeli
ali.gurbuz@tubitak.gov.tr
Özet. Yazılım proje yöneticileri hedefledikleri bütçe ve takvim içerisinde hata-
lardan 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 bekle-
nen işlevleri yerine getirdiğinin gösterilmesi doğrulama ve geçerleme faaliyeti-
nin 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 des-
teklenmelidir ki doğrulama ve geçerleme faaliyetleri de tam olarak gerçekleşti-
rilmiş olsun. Yazılım testlerinin iyi anlaşılması, projelerde doğru şekilde uygu-
lanması proje başarılarını ve dolayısı ile, kalitesini arttıracaktır. Yazılım testle-
rinden 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ğru-
lama ve geçerleme ekibine bağlıdır. Bu çalışma kapsamında Bilişim Teknoloji-
leri Enstitüsü ve Yazılım Test ve Kalite Değerlendirme Merkezi olarak projele-
rimizde uyguladığımız “Müşteri Avukatı (User Advocate)” kavramı, çalışma
şekli ve süreci incelenecektir.
Anahtar Kelimeler. Yazılım Doğrulama ve Geçerleme, Müşteri Avukatı, Yazı-
lım Test, Çalışma Modelleri
1 Giriş
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 telefon-
larımızdan bilgisayarlara, vatandaşlık işlemlerinden sağlık sektörüne, üretimden tüke-
time 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 stan-
dartların ve belirlenmiş süreçlerin en iyi şekilde projelerde uygulanması ve daha ön-
ceki projelerde gerçekleştirilen hataların bu projelerde tekrarlanmamasından geçmek-
tedir.
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 ka-
dar 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 koy-
maktadır [1]. 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ık-
tan 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 ra-
kamları 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.
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ğer-
lendirme 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 bul-
gular 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 Projeler Neden Başarısız Olur?
Yazılım dünyasındaki başarısızlıklar uzun yıllardan beri tartışılmaktadır. Başarısızlık-
lar ortaya çıktıkça bu başarısızlıklar üzerinde yapılan çalışmalar artmış ve bu çalışma-
ları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 sonu-
cunda bir yazılım yaşam döngüsü içinde projelerin istenilen maliyet ve takvimde biti-
rilmesinde önemli rol oynayan tahminleme teknikleri geliştirilmiştir.
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 ça-
lışmalar gerçekleştirilmesine rağmen yazılım projelerindeki başarısızlıklar sonlandırı-
lamamıştır.
Proje başarısızlıklarının literatürde [2, 3, 4, 5] genel olarak aşağıdaki maddelerde
toplandığı görülmektedir.
2.1 Zaman-Bütçe Tahmininde Yanılgı
Özellikle kamu tedariğine yönelik yazılım ihalelerinde projelerin tamamlanma sürele-
ri 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 ke-
sin 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ül-
düğü 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 edilme-
diğ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 Müşterinin Anlaşılamaması- İletişim Eksikliği
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 so-
nuçlanır. Oluşan iletişim kazaları da yazılım içerisinde hata olarak ortaya çıkar.
2.3 Değişen Müşteri İstekleri
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 önce-
sinde 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, gereksi-
nimlerin 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 Projede Bir Müşteri/Sponsor Avukatı: Bağımsız DG Ekibi
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 bir-
likte uyguladığımız “Müşteri Avukatı” rolünü Bağımsız bir Doğrulama ve Geçerleme
(DG) ekibine vermekteyiz.
3.1 Yazılım Test ve Kalite Değerlendirme Merkezi (YTKDM)
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 faaliyetle-
rine 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 kap-
samı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.
YTKDM, projelerin görünürlüğünü arttırmak ve yazılım projesi müşterisinin he-
deflediği özellikte ürünlere sahip olmayı sağlamak için test hizmetleri, test süreç da-
nışmanlığı ve yazılım kalite değerlendirme hizmetleri vermektedir.
3.2 Doğrulama ve Geçerleme (DG) Süreci
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 imzalan-
ması 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.
DG süreci, ürün geliştirmedeki hataları erken aşamalarda tespit etmeyi ve geliştiri-
len ü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 geti-
rildiğine dair bir güven oluşturur.
3.3 Bağımsız DG Ekibi Rol ve Sorumluluğu
Yazılım Test ve Kalite Değerlendirme Merkezi tarafından BTE bünyesindeki proje-
lerde 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.
Yazılım ürünleri, yaşam döngüsü boyunca bağımsız bir kuruluş tarafından test edi-
lir, 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.
Bağımsızlık, teknik, yönetimsel ve finansal yönlerden sağlanmaktadır. Yazılım ge-
liş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öneti-
minin 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çesi-
nin kontrolü, yazılımı geliştiren organizasyondan bağımsız bir organizasyon tarafın-
dan yapılarak, “Finansal Bağımsızlık” sağlanmaktadır.
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. Ge-
reksinim 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 sonu-
cunda, 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 Ç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şletil-
mektedir.
─ 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 Çalışma Modellerinin Değerlendirmesi
Çalışma Modeli-1:Sponsor Açısından.
Avantajları. Bu çalışma modelinin avantajları aşağıda maddeler halinde listelenmek-
tedir:
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 uygula-
nan 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çek-
leş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ük-
sek 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 gereksi-
nimlerin 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ı unu-
tulmayarak, oluşabilecek karşıtlıkların önüne geçilebilir.
Çalışma Modeli-2: Müşteri Açısından.
Avantajları. Bu çalışma modelinin avantajları aşağıda maddeler halinde listelenmek-
tedir:
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 gereksi-
nimlerin 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 ne-
den 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 getiril-
diğine dair bir güven ortamı oluşacaktır.
Dezavantajları. Bu çalışma modelinin dezavantajları aşağıda maddeler halinde liste-
lenmektedir:
Bu çalışma modelindeki faaliyetler projeye ek maliyet getirecektir. Fakat, bu ça-
lışma modeli ile projenin ilerleyen aşamalarında bulunacak hatalar, projenin başın-
da 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.
4 Müşteri Avukatı Yaklaşımının Proje Başarısına Etkileri
4.1 Ortak Anlayış
Müşteri Avukatı, proje başlangıcından itibaren sürece dahil olarak tüm aktörler ara-
sı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, gerek-
sinimlerin test edilebilirliğinin de kontrol edilmesi ile, gereksinimlerin net, tam, anla-
şılır ve doğrulanabilir olmasına katkıda bulunur.
4.2 Sorgulama
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 etkileri-
nin düşündürülmesi sağlanmaktadır.
4.3 Müşteriye Güven
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, pro-
jede kendisi adına çıkarlarını koruyan, isteklerini anlayan bir müşteri avukatı bulun-
duğ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 planla-
nan bütçe dahilinde geliştirilmesini sağlayarak müşteri güvenini ve memnuniyetini
arttırmaktadır.
4.4 Risk Yönetimi
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.
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ı edilebilmek-
tedir. 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ülebilmek-
tedir. 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.
5 Müşteri Avukatı Deneyimi
5.1 Sponsor tarafından
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 faali-
yetler, periyodik olarak raporlanarak, talep edilen durumlarda BTE yönetimine iletil-
mektedir. 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.
Ş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ülebil-
mektedir. Sponsor adına teknik izleme ve kontrol faaliyetleri, proje risklerinin bağım-
sı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.
Zaman ve bütçe yönüyle elde edilen nicel kazançlar, proje gizliliği nedeniyle pay-
laşılamamaktadır.
5.2 Müşteri tarafından
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ın-
ması ve bu ölçümlere dayanılarak uzman kişilerce değerlendirme raporu oluşturulma-
sı 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ğerlen-
dirmesi gerçekleştirilir.
Değerlendirme sonucunda kullanılabilirlik açısından iyileştirilmesi gereken nokta-
lar listelenir. Kullanılabilirlik testlerinin yapılamadığı durumlarda ya da kullanılabilir-
lik 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ğer-
lendirme ç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şile-
re, 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 kont-
rol listelerine ve gözden geçirme kurallarına göre gözden geçirilmektedir.
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.
Tüm çalışmaların değerlendirmeleri kullanılarak, genel bir değerlendirme yapıl-
mıştır. Kamu kurumuna bu değerlendirmeler kapsamında neler yapılması ile ilgili
öneriler yapılarak rapor tamamlanmıştır.
Sonuçlar. Bu rapor kapsamında, iş paketlerinin çıktılarında elde edilen sorunlar gös-
termektedir ki, yazılımların yazılım yaşam döngüsü süreçlerinde doğrulama ve geçer-
leme 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.
Elde edilen deneyime göre, kamu kurumlarının yazılım geliştirme projelerinde ge-
liş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 öne-
mi hem kamu kurumu, hem firma, hem de YTKDM olarak bir kez daha açık olarak
fark edilmiştir.
6 Sonuç
TÜBİTAK BİLGEM YTKDM tarafından uygulanmakta olan “Müşteri Avukatı” yak-
laşımı ile, BTE projelerinde geliştirilen yazılım ürünlerinin kalitesi artmıştır. Projeler-
de 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ğlan-
maktadır.
Proje süresince “Müşteri Avukatı” rolünü üstlenen ve proje ekibinden bağımsız şe-
kilde faaliyet gösteren DG ekibi, geliştirilen ürünün doğru ve kaliteli bir şekilde, plan-
lanan 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 kurumla-
rının satın alımlarında da uygulanmış ve başarılı sonuçlar alınmıştır.
Özgün çözümlerin geliştirilmesi, net tanımlanmış gereksinimler ile bu gereksinim-
lerin 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.
Yazılım sektöründe dünya lideri olmamızın en öncelikli şartı küresel gereksinimle-
re cevap verebilen, yenilikçi, güvenilir, standartlara uygun, yeni teknoloji üreten ve
kullanan daha çok yerli yazılım üretmemize bağlıdır.
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şe-
meyen veya üretime geçemeyen pek çok yazılım projesi yer almaktadır.
Yazılım Sanayicileri Derneği (YASAD)’nin kısa ve orta vadede hedeflerinin ara-
sı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 [5]. 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 ekonomi-
sinin 2023 yılına kadar en büyük beş sektörü arasına girmesi için çalışma yer almak-
tadı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 [6].
Ülkemizin Vizyon 2023 için belirlediği hedeflerine ulaşabilmesinde diğer tüm sek-
tö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 kat-
kının etkinliğinin arttırılması, bu çalışma kapsamında bahsedilen “Müşteri Avukatı”
modeli ile doğrudan ilgilidir.
Teşekkür - Yazarlar, bu çalışmanın gerçekleştirilmesi için destek sağlayan
TÜBİTAK BİLGEM Yazılım Test ve Kalite Değerlendirme Merkezi'ne ve TÜBİTAK
BİLGEM Bilişim Teknolojileri Enstitüsü’ne teşekkür eder.
Kaynaklar
1. The Standish Group (2004), Chaos Report, The Standish Group.
2. D.R. Wallace, and R.U. Fujii, “Software Verification and Validation: An Overview”, IEEE
Software, May 1989.
3. http://www.optimum7.com/internet-marketing/programming-2/top-reasons-why-software-
projects-fail-and-how-to-avoid-them.html
4. Lorin J. May, “Major Causes of Software Project Failures”, Crosstalk: The Journal of De-
fense Software Engineering, 1998.
5. Jones, Capers, Patterns of Software Systems Failure and Success, International Thompson
Computer Press, Boston, Mass., 1996.
6. SDE Yazılım Sektörü E-Bülteni: “Yazılımda, Türkiye Neden bir Başarı Hikayesi Olma-
sın?”, Gülara TIRPANÇEKER, 2012.