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

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.

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

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

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ı

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 bulutBu 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 tasarlanmış bir sebep-sonuç zinciridir.

8

CMMI MODELİ

9

SPICE MODELİ

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.

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

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

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

Ü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

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

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, bileşen testi vb.) çözümü konusunda bir yol göstereceği düşünülmektedir.

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/

18

TEŞEKKÜRLER…