ݺߣ

ݺߣShare a Scribd company logo

Yazılım projeleri süreç performans ölçümü

•Download as PPTX, PDF•
•
TUBITAK
TUBITAK

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 of 18
Downloaded 36 times
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
İÇ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
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
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
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
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
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
CMMI MODELİ 8
SPICE MODELİ 9
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
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.
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.
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.
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.
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.
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
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
TEŞEKKÜRLER… 18

More Related Content

Yazılım projeleri süreç performans ölçümü

  • 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
  • 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

Editor's Notes

  • #4: 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. Yazılım geliştirme süreçlerinin değerlendirmesi, uluslararası kabul görmüş standartlara göre yapılabilir. CMMI (Capability Maturity Model Integration) ve SPICE (Software Process Improvement and Capability dEtermination) standartları dünya çapında bilinen ve uygulanan standartlardır. Yazılım ürününün hata yoğunluğu ise müşteriye teslim edilen üründeki toplam hata sayısının yazılım ürün büyüklüğüne (toplam satır sayısı) bölünmesi ile elde edilir. 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. Bunun için, yazılım geliştirme süreçlerinin performans ölçümü, darboğazların tespiti ve giderilmesi konusunda kısıtlar teorisinin düşünce süreçlerinin, yani sorun çözme araçlarının kullanımına ilişkin örnek bir uygulama gerçekleştirilmiştir.
  • #6: TOC, Goldratt tarafından 1984’te yayınladığı kitabında tartışıldı ve geliştirildi. TOC ilk zamanlarda; Pazar koşullarını dikkate alarak karı artırmak için üretim planlama ve çizelgeleme için kullanıldı. Daha sonraları pazarlama, satış ve bilgi sistemlerinde de kullanıldı. TOC, devler ve idari hizmetleri gibi kar amacı gütmeyen organizasyonlarda yaygın olarak kullanılmadı Goldratt .
  • #12: : 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. MGA, istenmeyen etkiler ve onların sonuçları arasındaki neden-sonuç ilişkilerini gösteren bir diyagramdır. Amaç, problem yaratan kök nedeni bulmaktır. Öncelikle kök neden bulunur ve ortadan kaldırılır. Böylece istenmeyen etkiler yok olur.
  • #13: Buharlaşan Bulut: İstenmeyen sonucu ortadan kaldırmak için önerilen çözümlerle temel ve ön gereksinimlerin tanımlandığı, çözümler arasındaki çatışmanın ortaya konduğu ve bu çatışmanın yok edilmesi için enjeksiyonun yapıldığı araçtır. 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
  • #14: Gelecek Gerçeklik Ağacı (GGA) : Geleceği hayal ederek canlandırmak ve tahmin etmek için kullanılan bir araçtır. Gelecek gerçeklik ağacı (GGA), mevcut sistemde yapılacak değişiklikler ile meydana gelebilecek sonuçlar arasındaki neden sonuç ilişkisini gösterir. GGA, bir what-if uygulamasıdır. Önerilen değişimin yararlarını, doğuracağı olumsuz etkileri ve bu etkilerin nasıl ortadan kaldırılacağını belirlemeye çalışır.
  • #15: Ön Gereksinim Ağacı: Çözüm fikrinin önündeki tüm engellerin üstesinden gelmek için gerekli olan ikincil çözüm kümelerinin oluşturulması için mantıksal bir yol sunar. Amacı, büyük bir hedefe ulaşmak için ihtiyaç duyulan ara adımların tümünün tanımlanmasına yardımcı olmaktır. Ö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.
  • #16: Geçiş Ağacı (GA): 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.