yazılım geliştirme süreçlerinin performans ölçümünde karşılaşılan engellerin kısıtlar teorisi düşünme süreci ile çözümlenmesi.

1. Yazılım Proje Geliştirme Süreçlerinin
Performansının Ölçümünde Kısıtlar Teorisi
Düşünme Süreçlerinin Kullanımı
Özgür GÜN, Y.Müh.
KOCAELİ ÜNİVERSİTESİ
FEN BİLİMLERİ ENSTİTÜSÜ
ENDÜSTRİ MÜHENDİSLİĞİ DOKTORA PROGRAMI

2. İÇERİK
 GİRİŞ
 KISITLAR TEORİSİ
 DÜŞÜNME SÜRECİ
 CMMI MODELİ
 SPICE MODELİ
 YAZILIM GELİŞTİRME SÜREÇ MODELLERİ
 YAZILIM PROJE GELİŞTİRME SÜREÇLERİNİN PERFORMANSININ ÖLÇÜMÜNDE
KISITLAR TEORİSİ DÜŞÜNME SÜREÇLERİNİN KULLANIMI
 SONUÇ
 KAYNAKLAR
2

3. GİRİŞ
 Yazılım projelerinin başarısında projede işletilen süreçlerin
performansı önemli rol oynamaktadır. Yazılım süreçlerinin
performansı, süreçlerin uluslararası standartlara uygunluğu
denetimi yapılarak ve yazılım ürünlerindeki hata yoğunluğu
hesaplanarak ölçülebilir. Bu çalışmada kısıtlar teorisi
yöntemlerinin yazılım projelerinde işletilen süreçlerinin
performansının ölçülmesinde nasıl kullanılabileceğinin
gösterilmesi amaçlanmaktadır.
 Bu çalışmada, Araştırma ve Geliştirme faaliyetlerinde bulunan,
askeri ve sivil projelerde yer alan bir kamu kuruluşunda
gerçekleştirilen projelerin süreç performanslarının ölçümünde
karşılaşılan sorunlar hakkında bilgi toplanmaya çalışılmıştır.
3

4. YAZILIM GELİŞTİRME SÜREÇLERİ
 Yazılım Geliştirme Süreçleri: Bir yazılım projesinin
başlangıcından müşteriye teslimine kadar proje
ekibinin yaptığı faaliyetler.
 Gereksinim analizi
 Gereksinimlerdeki değişkenlik oranı, takvim ve işgücü uyumu
 Tasarım
 Takvim ve işgücü uyumu, tasarıma gelen değişiklik istekleri
 Gerçekleme
 Birim test kapsama oranı, birim test hata oranı, takvim ve işgücü uyumu
 Tümleştirme
 Takvim ve işgücü uyumu, sistem tümleştirmedeki hata oranı
 Test
 Takvim ve işgücü uyumu, hata yoğunluğu
4

5. KISITLAR TEORİSİ
 Goldratt’ın Amaç kitabında kısıtları analiz etmek ve
yönetmek için beş adımlı bir model tanımlanmıştır.
Bu model kısıtlar teorisinin en önemli parçalarından
biridir.
 Kısıtları belirle
 Kısıtlardan mümkün olan en büyük faydayı elde et
 Kısıtın özelliklerine göre diğer aktiviteleri/süreçleri
tasarla
 Performansı iyileştirmek için kaynak ekle
 Birinci adıma geri dön ve yeni kısıt aramaya başla
5

6. DÜŞÜNME SÜRECİ 1/2
 Bir diğer teknik ise Düşünme Sürecidir (Thinking
Process). Goldratt (1990a)’a göre kısıt yönetimi ile
uğraşan yöneticileri üç tane karar vermesi gerekir.
 Sistemde ne değişecek,
 Neye dönüşecek,
 Değişim nasıl gerçekleşecek?
 Bu soruları adreslemek için düşünme süreci aşağıdaki
beş aracı sunmuştur.
 Mevcut gerçeklik ağacı (neden-sonuç)
 Buharlaşan bulut
 Gelecek gerçeklik ağacı
 Ön gereksinim ağacı
 Geçiş ağacı
6

7. DÜŞÜNME SÜRECİ 2/2
 Mevcut gerçeklik ağacı
Düşünce süreçlerinin uygulanmasındaki ilk adım istenmeyen etkilerin listelenmesi ve bunlara göre mevcut
gerçeklik ağacının oluşturulmasıdır. MGA bir sistemin mevcut durumunu analiz etmek ve problemleri daha
iyi anlamak için oluşturulur ve sistemin performansını azaltan istenmeyen etkilere sahip temel problemleri
tanımlar.
 Buharlaşan bulut
Bu araç, tek bir problemin ayrı olarak ele alınmasını, karşılaşılan çatışmaların ve varsayımların
belirlenmesini ve çözüm amacıyla incelenmesini içerir. Buharlaşan bulut yöntemi problemin yaşandığı
mevcut durumdan arzulanan gelecek duruma geçişte, problemlerin ortadan kaldırılmasına katkıda
bulunarak etkili bir köprü görevi görmektedir.
 Gelecek gerçeklik ağacı
Geleceği hayal ederek canlandırmak ve tahmin etmek için kullanılan bir araçtır. Önerilen
değişimin yararlarını, doğuracağı olumsuz etkileri ve bu etkilerin nasıl ortadan
kaldırılacağını belirlemeye çalışır.
 Ön gereksinim ağacı
Ön gereksinim ağacının geliştirilmesi arzulanan sonuçlara ulaşmayı engelleyen yerel
engelleri, durumları ve ihmalleri tanımlar ve bu engelleri ve değişime direncin üstesinden
gelmeyi sağlayacak yeni hedefleri ve amaçları belirler.
 Geçiş ağacı
Geçiş ağacı (GA), amaca ulaşmak için gerekli faaliyetlerin tanımlanmasında kullanılır. Arzu edilmeyen
sonucun tanımlanmasından, değişimin tamamlanmasına kadar adım adım süreçleri ortaya koymak için
7

8. CMMI MODELİ
8

9. SPICE MODELİ
9

10. YAZILIM GELİŞTİRME SÜREÇ MODELLERİ
Her süreç modeli, yazılım geliştirmede başarılı olmak için bu yaşam döngüsünü (SDLC-
software development life cycle) izler. Yazılım süreç modelleri ürünlerin kalitesine
olumlu etkisinin yanı sıra, projelerin karmaşıklığını azaltıp karışıklıkları önler. Projenin
hedeflerine ulaşabilmesi için geliştirilmiş süreç modellerinin isimleri
 Waterfall (Şelale) Model,
 V Model,
 Incremental (Artırımlı) Model,
 RAD (Rapid Application Development) model,
 Agile Model,
 Iterative (Yinelemeli) Model
 Spiral Model vb.
Bu çalışmada “V Model” incelenmiştir.
10

11. Yazılım Proje Geliştirme Süreçlerinin Performansının Ölçümünde
Kısıtlar Teorisi Düşünce Süreçlerinin Kullanımı 1/5
11
Projede kullanılan
geliştirme araçları
için araç destek
ekibi olmaması
Ölçme ve
değerlendirme
için yeterli sayıda
personel
atanmaması
Proje geliştirme
süreçleri için
destek
araçlarının
kullanılmaması*
Proje
çalışanlarının
süreçleri
uygulamamaları
*
Yönetim
desteğinin
olmaması
Süreç performans
sonuçlarına göre
süreç
iyileştirmelerinin
yapılmaması
Projede kullanılan
araçlarla ilgili
problemlerin
çözümü için yerel
destek alınmaması
Projede kullanılan
araçların yıllık
bakımlarının
yapılmaması
Süreç performans
ölçümünün
yapılamaması
Süreç performans
göstergelerinin
tanımlı olmaması
Performans
ölçüm ve
değerlendirme
sürecinin tanımlı
olmaması*
Yazılım
geliştirme
süreçlerinin
tanımlanmaması
Yazılım geliştirme
süreç iş akışlarının
destek araçlarında
tanımlanmaması
Mevcut Gerçeklik Ağacı
MGA, istenmeyen etkiler ve
onların sonuçları arasındaki
neden-sonuç ilişkisini gösteren
bir diyagramdır. Amaç, kök
nedeni bulmaktır. Bu neden
bulunup ortadan kaldırıldığında
istenmeyen etkiler yok olur.
Yazılım projesi süreçlerinin
performans ölçümünde
karşılaşılan ana kısıtlar; proje
geliştirme faaliyetlerinde destek
araçlarının kullanılmaması,
proje çalışanlarının süreçleri
uygulamamaları, performans
ölçüm ve değerlendirme
sürecinin tanımlı olmaması
olarak sıralanabilir.

12. Yazılım Proje Geliştirme Süreçlerinin Performansının Ölçümünde
Kısıtlar Teorisi Düşünce Süreçlerinin Kullanımı 2/5
12
Proje destek araçlarının
kullanılması
Proje destek araçlarının
kullanılmaması
Destek araçlarının
projelerde etkin
kullanılması ve
verimin artması
Destek araçlarının
projelerde
uygulanması
Süreç performans
ölçümü için altyapının
hazır hale gelmesi
Çalışanlara araç
kullanıcı
eğitimlerinin
verilmesi
Araçlar için bütçe ve
insan kaynağı ayrılması
Buharlaşan Bulut
Buharlaşan bulut tekniği mevcut
kök nedeni ortaya çıkaran
problemlerin çözümlerinin ortaya
konulmasında kullanılır.
Şekildeki buharlaşan bulut,
yazılım projeleri geliştirme
süreçlerinin performans
ölçümlerinde karşılaşılabilecek
çatışmalardan bir tanesini ve
çözüm için olası enjeksiyonları
göstermektedir. Burada yaşanan
çatışma proje geliştirme
aşamasında normalde
kullanılması gereken destek
araçlarının kullanılması ya da
kullanılmamasıdır.

13. Yazılım Proje Geliştirme Süreçlerinin Performansının Ölçümünde
Kısıtlar Teorisi Düşünce Süreçlerinin Kullanımı 3/5
13
Üretkenliğin
artması
Kişiye bağımlılığın
kalkması,
kurumsallaşma
Daha fazla proje
kazanımı
Müşteri
memnuniyeti
Maliyetlerin
düşmesi
İstatistiksel süreç
kontrolü
Kapasite ve kar
artışı
Süreç performans
denetimleri ve
değerlendirmesi
Hata yoğunluğu az
ürünler
Performansı düşük
süreçlerde iyileştirme
yapılması
Gelecek Gerçeklik Ağacı
Bu aşamanın amacı,
gerçekleştirilmek istenen bir
durumun beklenen en iyi
sonuçlara (İstenen Etki -
Desirable Effect - DE)
ulaştıracağının doğrulanmasıdır.
GGA’nda, önceki şekildeki
buharlaşan bulutta bahsedilen
proje destek araçlarının
projelerde uygulamaya alınması
ile üretkenlik (kod,
dokümantasyon geliştirme süresi
vb.) artar. Projede üretilen
bilgilerin kişiye bağımlılığı ortadan
kalkar. Performansı düşük olan
süreç/alt süreçlerde iyileştirmeler
yapılarak darboğazlar aşılır.

14. Yazılım Proje Geliştirme Süreçlerinin Performansının Ölçümünde
Kısıtlar Teorisi Düşünce Süreçlerinin Kullanımı 4/5
14
Destek araçlarımı
alımı için bütçe
ayrılması ve
personel atanması
Proje geliştirme
faaliyetlerinin
araçlarda
gerçekleştirilme oranı
Zayıf proje
performans izleme
faaliyetleri
Destek araçlarının
projede
kullanılmaması
Proje çalışanlarının eğitilmesi,
yönetim tarafından çalışanların
araçları kullanarak proje
geliştirmesinin özendirilmesi,
araçlardan sorgular yardımı ile
süreç performanslarının
ölçülmesi
Yönetim desteği ve
çalışanları
özendirmesi
Ön Gereksinim Ağacı
Ön gereksinim ağacıyla, çözüme
ulaşmamızı engelleyen durum
tanımlanır. Bu çalışmada çözüme
ulaşmamızı engelleyen durum,
şekildeki ön gereksinim ağacında
görüldüğü gibi proje destek
araçlarının projelerde
uygulamaya alınmaması ve
kullanılmamasıdır. Bu engeli
ortadan kaldırmak için proje
destek araçlarının satın alınması
için bütçe ayrılır, bu araçların
kurulumu, yapılandırması,
idamesi ve çalışanlara eğitim
verilmesi için personel ataması
yapılır.

15. Yazılım Proje Geliştirme Süreçlerinin Performansının Ölçümünde
Kısıtlar Teorisi Düşünce Süreçlerinin Kullanımı 5/5
15
Yönetimin
özendirmesi ve
proje
çalışanlarının
destek araçlarını
kullanması
Yazılım destek
araçlarının yıllık
bakımlarının
yapılması ve yerel
destek anlaşması
yapılması
Yazılım destek
araçları için
kaynak ayrılması
Yazılım
geliştirme
süreçleri iş
akışlarının destek
araçlarında
tanımlanması
Performans ölçüm
ve değerlendirme
sürecinin
tanımlanması ve
uygulanması
Süreç performansı
uygulanması için
Yönetim
Politikasının
oluşturulması
Darboğaz
oluşturan
süreçlerin tespiti
ve iyileştirilmesi
Proje süreç
denetlemelerinde
süreç performans
ölçümlerinin
dikkate alınması
Süreç
performanslarının
ölçülmesi ve
değerlendirilmesi
Hata yoğunluğu
düşük ürün
gerçekleştirme
Geçiş Ağacı
Geçiş ağacı ise, detaylı bir şekilde
planlanan ana amaçlara ulaşmak ve
bunları uygulamaya geçirmek için
gerekli faaliyetlerin tanımlanmasında
kullanılır.
proje süreç performanslarının etkin bir
şekilde ölçülmesi ve süreçlerin
iyileştirilmesi ve darboğazların
giderilmesi için yönetim tarafından bir
politika belirlenmeli, bu politika gereği
performans ölçme ve değerlendirme
süreçleri tanımlanmalı, ihtiyaç duyulan
araçlar satın alınmalı, bu araçları
yönetecek ve eğitim verecek personel
görevlendirilmeli, proje çalışanları
özendirilerek proje faaliyetlerinin
araçlar kullanılarak yapılması
sağlanmalı ve böylece kurumsal
hafızanın oluşması sağlanarak kişiye
bağımlılığın ortadan kaldırılarak
standart iş yapma tarzı kuruma
yerleşmelidir.

16. SONUÇ
 Yazılım ürün kalitesi, sadece bitmiş ürünün test edilmesi ve hataların giderilmesi ile
sağlanmaya çalışılırsa bu hem çok maliyetli olacaktır hem de projenin gecikmesine
neden olacaktır. Önerilen çözüm, projenin erken aşamalarından itibaren süreç
performanslarının sürekli izlenmesi ve sapmalar durumunda düzeltici faaliyetlerin
başlatılmasıdır.
 Projelerin kazanılmasından ve başlamasından itibaren proje sözleşmesine uygun
proje yaşam döngüsü modeli seçilmelidir. Yazılım organizasyonu, yazılım geliştirme
faaliyetleri için IEEE 12207 ve CMMI gibi standart ve modellerdeki süreçleri kendi
kurumunun özelliklerini ve iş yapış tarzını dikkate alarak özelleştirmeli ve projelerde
uygulanmasını sağlamalıdır.
 Gereksinim yönetim aracı, konfigürasyon ve değişiklik yönetim aracı, iş yönetim
aracı, test yönetim araçları, risk yönetim araçları bir yazılım geliştirme
organizasyonunun kullanacağı tipik araçlardır.
 Bu araçların organizasyonda kullanımı güçlü bir yönetim politikasına, bu politikanın
gereği olarak süreçlerin tanımlanması, destek araçları için kaynakların ayrılmasına
bağlıdır.
 Bu çalışmanın, yazılım sektöründe faaliyet gösteren firmaların yazılım geliştirme
süreçlerinde karşılaştıkları diğer zorlukların (yazılım birim test, kod gözden geçirme,
16

17. KAYNAKLAR
1 Goldratt, E.M. (1990a)What is this thing called theory of constraints
and how should it be implemented? Massachusetts:North River Press
[2] Goldratt, E.M. (1990b). The haystack syndrome: Sifting information
out of the data ocean. New York: North River Press
[3] Goldratt, E.M. (1990c). What is this thing called the theory of
constraints? New York: North River Press
[4] Klein, D., & DeBruine, M. (1995). A thinking process for establishing
management policies. Review of Business, 16(3), 31–37.
[5] Dettmer, H.W. (1997). Goldratt’s theory of constraints: A systems
approach to continuous improvement. Milwaukee: ASQC Quality Press
[6] Ring, P.S., & Perry, J.L. (1985). Strategic management in public and
private organizations: Implications of distinctive contexts and
constraints. The Academy of Management Review, 10(2), 276–286.
[7] CMMI-DEV v1.3, www.cmmiinstitute.com
[8] ISO/IEC 15504, www.iso.org
[9] V Model, http://www.waterfall-model.com/v-model-waterfall-model/
17

18. TEŞEKKÜRLER…
18