Transkript

1 ANKARA ÜNİVERSİTESİ FEN BİLİMLERİ ENSTİTÜSÜ YÜKSEK LİSANS TEZİ SAVUNMA SİSTEMLERİNDE YAZILIM PROJE YÖNETİMİ Gülbahar GÜMRÜKÇÜ ELEKTRONİK MÜHENDİSLİĞİ ANABİLİM DALI ANKARA 2010 Her hakkı saklıdır

2 ÖZET Yüksek Lisans Tezi SAVUNMA SİSTEMLERİNDE YAZILIM PROJE YÖNETİMİ Gülbahar GÜMRÜKÇÜ Ankara Üniversitesi Fen Bilimleri Enstitüsü Elektronik Mühendisliği Anabilim Dalı Danışman: Yrd.Doç.Dr.Murat Hüsnü SAZLI Günümüzde teknolojinin hızlı gelişiminin etkisi ile yazılım yoğunluklu sistemlerin kullanımı gerek günlük hayatımızda gerekse savunma sanayisinde her geçen gün artmaktadır. Bu sistemlerin en önemli kısmını her alanda hizmet sağlamak üzere geliştirilen yazılımlar oluşturmaktadır. Etkin olarak kullandığımız bu yazılımların üretimi diğer sistemlerden farklı özelliklere sahiptir. Bundan dolayı, yazılım sektöründe ürün odaklı kalite yönetiminden çok süreç odaklı kalite yönetimi önem kazanmıştır. Dünyada süreç odaklı yazılım geliştirme aşamalarına ışık tutan yöntemlerin kullanımı ile elde edilen olumlu sonuçlar yazılım kalite standartlarının önemini arttırmıştır. Artık firmaların uluslararası yazılım projeleri ihalelerine girebilmeleri için belirli bir seviyede yazılım kalite standardı belgesine sahip olması şartı aranmaktadır. Bu aşamada ISO/IEC 12207(Software life cycle process), CMM (Capability Maturity Model), CMMI (Integrated Capability Maturity Model), ISO-2000 ve AQAP-160 modelleri karşımıza çıkmaktadır. Bu belgeleri almak sadece uluslararası kabul için değil aynı zamanda şirketlerin verimliliğinin arttırılması, müşteri memnuniyeti ve projelerin başarı ile sonuçlanması açısından önem taşımaktadır. Bu tez çalışmasında ilk olarak bu modeller ve modellerin tedarik süreçleri hakkında bilgi verildikten sonra modellerin karşılaştırması yapılmıştır. Türkiye nin jeopolitik konumu itibarı ile Türk Silahlı Kuvvetleri (TSK) caydırıcılığını sürdürebilmek için yazılım yoğunluklu yüksek teknolojili sistemler tedarik etmektedir. Bu sistemlerin özellikle Türk Savunma Sanayisi tarafından milli olarak geliştirilmesi hayati önem arz ettiğinden, yazılım firmalarının olgunluk seviyelerinin belirli bir seviyede olması ve projelerdeki başarı oranlarını arttırabilmeleri için bu seviyelerini arttırıcı girişimlerde bulunmaları gerekmektedir. Tez kapsamında, bu firmaların kullandıkları modeller hakkında bilgi verildikten sonra yazılım sistemlerinin; planlanan süre, ayrılan kaynak ve istenen verimde sağlanabilmesi için tedarik makamı ve yüklenicinin aynı dili konuşmasının önemine değinilmiştir. TSK de Hv.K.K.lığı nın tedarik süreçleri, 2007 öncesi ve sonrasında uygulanan yöntemler çerçevesinde ele alındıktan sonra mevcut süreç CMM ile karşılaştırılarak gerçekçi tedarik süreci iyileştirme önerileri verilmiştir. Mayıs 2010, 105 sayfa Anahtar Kelimeler: Yazılım Süreç Modelleri, Olgunluk Düzeyleri, Yetenek Seviyeleri, CMM, CMMI. i

3 ABSTRACT Master Thesis SOFTWARE PROJECT MANAGEMENT AT DEFENSE SYSTEMS Gülbahar GÜMRÜKÇÜ Ankara University Graduate School of Natural and Applied Sciences Department of Electronic Engineering Supervisor: Asst.Prof.Murat Hüsnü SAZLI Nowadays, with the effect of rapid technological developments, the use of the intensive software systems is increasing both in our daily life and at the defense industry day by day. The most important component of these systems is the software developed in order to provide service in every field. Production of this software that we use effectively has got different characteristics from the other systems. For this reason, process oriented quality management has become more important than product oriented quality management at the software sector. The positive outcomes achieved by using the methodologies which shed light on the stages of process oriented software development have fostered the importance of software quality standards all over the world. From now on, in order to bid for the tenders of international software projects, the firms are required to have the certificate of software quality standard at a specific level. In this stage, obtaining the models ISO/IEC 12207(Software life cycle process), CMM (Capability Maturity Model), CMMI (Integrated Capability Maturity Model), AQAP-160, ISO-2000 are of great significance not only to receive international approval, but also to increase the productivity of the companies, customer satisfaction and conclude the projects successfully. In this study of thesis, first of all information about these models and the processes of supplying the models will be given, and then the models are compared. In consideration of Turkey s geopolitical location, in order to be able to maintain its deterrence, Turkish Armed Forces supplies software intensive and high technology systems. Since developing these systems nationally especially by Turkish Defense Industry, has gained vital importance, in order for the maturity levels of the software firms at Turkish Defense Industry to be at a certain level, and for them to be able to increase their rate of accomplishment in the projects, they should attempt to increase these levels. After acquainting about these firms point of views on the topic of amendment of software process and assessment and their targets, in order to be able to obtain the software intensive systems within the intended period, according to the allotted source and at the expected productivity, the importance for the procurement authority and the contractor to speak the same language is underlined in this thesis. In this context, after Turkish Air Force s Supply Processes are evaluated within the framework of methods used before and after the year 2007, present process is compared with SA-CMM and realistic supply process enhancement suggestions are provided. May 2010, 105 pages Key Words: Models of Software Process, Levels of Maturity, Levels of Capacity, CMM, CMMI. ii

4 TEŞEKKÜR Tez çalışmamdaki yardımları için danışman hocam Sayın Yrd.Doç.Dr.Murat Hüsnü SAZLI ya (Ankara Üniversitesi Elektronik Mühendisliği Anabilim Dalı), Bu konuda sahip olduğu bilgi ve tecrübeleri ile bana yardımcı olmak için değerli zamanını ayırdığı ve pozitif bakış açısıyla hayatta her zaman bir çözüm yolu bulabileceğimi görmemi sağladığı için Sayın Prof.Dr.Semih BİLGEN e (Orta Doğu Teknik Üniversitesi Elektrik Elektronik Mühendisliği Bölümü), Yüksek Lisans eğitimime başlamam ve bitirmem konusunda desteğini eksik etmeyen amirlerime ve arkadaşlarıma, Sevgilerini ve güvenlerini her zaman yanımda hissettiğim ailemin benim için yaptıkları tüm fedakârlıklar için en derin duygularımla teşekkür ederim. Gülbahar GÜMRÜKÇÜ Ankara, Mayıs 2010 iii

5 İÇİNDEKİLER ÖZET...i ABSTRACT...ii TEŞEKKÜR...iii KISALTMALAR DİZİNİ...vi ŞEKİLLER DİZİNİ...,vii ÇİZELGELER DİZİNİ... viii 1. GİRİŞ YAZILIM SÜREÇ YÖNETİMİ Tanımlar Yazılım projelerinin yaşam çevrimi faaliyetleri Yazılım sistemlerinin proje yönetim süreci Yazılım geliştirme süreç modelleri Şelale (Waterfall) modeli Prototip model Spiral model Askeri Yazılım Sistemlerinin Geliştirme Süreci Yazılım Proje Yönetiminde Geliştirilen Kalite Standartları ve Olgunluk Modelleri Yazılım süreç olgunluğuna göre organizasyonların yapısı Yazılım yetenek olgunluk modeli (Capability Maturity Model-CMM) CMM ın gelişimi CMM in yapısı CMM in avantajları CMM in değerlendirme yöntemi CMM Tedarik Süreci (Software Acquisition Capability Maturity Model SA-CMM) Tekrarlanabilir düzey (CMM Seviye-2) Tanımlı düzey (CMM Seviye-3) CMMI ( Capability Maturity Model Integrated-Tümleşik Yetenek Olgunluk Modeli) iv

6 CMMI in gelişimi CMMI in yapısı CMMI in gösterim biçimleri Genel Amaçlar CMMI ın avantajları CMMI in değerlendirme yöntemi CMMI tedarik süreci CMMI-ACQ 2. Olgunluk Seviyesi Süreç Alanları CMMI-ACQ 3. Olgunluk Seviyesi Süreç Alanları ISO 9000 Kalite Yönetim Sistemi ve Kalite Güvence Standartları AQAP-160 (Allied Quality Assurance Publications- Müttefik Kalite Güvence Yayınları) Modellerin karşılaştırılması TÜRKİYE DE YAZILIM SÜREÇ MODELLERİNİN KULLANIMI Giriş Türk Silahlı Kuvvetleri nin (TSK) Tedarik Süreci MEVCUT TEDARİK SÜRECİNİN SA CMM SEVİYE-2 YE GÖRE ANALİZİ SONUÇ VE ÖNERİLER.91 KAYNAKLAR...95 EK 1 Mevcut Tedarik Sürecinin SA CMM Seviye-2 ye Göre Analizi...99 ÖZGEÇMİŞ v

7 KISALTMALAR DİZİNİ AQAP Allied Quality Assurance Process (Müttefik Kalite Güvence Süreci) ANSI Amerikan Ulusal Standartlar Enstitüsü ASA Anahtar Süreç Alanı BT Bilişim Teknolojileri CMM Capability Maturity Model (Yetenek Olgunluk Modeli) CMMI Integrated Capability Maturity Model (Tümleşik Yetenek Olgunluk Modeli) DOD-STD US Department Of Defense Standart EIA Electronic Industries Association (Elektronik Endüstrileri Birliği) GA Genel Amaç Hv.K.K.lığı Hava Kuvvetleri Komutanlığı HİP Harekat İhtiyaç Planı IEEE Institute of Electrical and Electronics Engineers ISO International Organization for Standardization(Uluslararası Standart Teşkilatı) IEC International Electrotechnical Commission (Uluslararası Elektronik Komisyonu) IPPD Integrated Process and Product Development Integrated İSM İhtiyaç Sahibi Makam MSB Milli Savunma Bakanlığı NDIA National Defense Industrial Association (Ulusal Savunma Endüstriyel Birliği) OYTEP On Yıllık Tedarik Planı ÖYE Ön Yapılabilirlik Etüdü P-CMM People CMM PPBS Planlama, Programlama ve Bütçeleme Sistemi PPBUS Planlama, Programlama, Bütçeleme ve Uygulama Sistemi PTD Proje Tanımlama Dokümanı SA-CMM Software Acquisition Capability Maturity Model (Yazılım Tedarik Yetenek Olgunluk Modeli) SDİL Sözleşme Doküman İsterleri Listesi SHP Stratejik Hedef Planı SE System Engineering (Sistem Mühendisliği) SEI Software Engineering Institue (Yazılım Mühendisliği Endüstirisi) SSM Savunma Sanayii Müsteşarlığı SW Software Enginnering (Yazılım Mühendisliği) TBP Teknik Bilgi Paketi TSK Türk Silahlı Kuvvetleri TÇD Teklife Çağrı Dosyası YAYEDEM Yazılım Yetenek Değerlendirme Modeli YE Yapılabilirlik Etüdü vi

8 ŞEKİLLER DİZİNİ Şekil 1.1 Karmaşıklık derecelerine göre yazılımlar...2 Şekil 1.2 Yazılım proje yönetim alanında geliştirilen kalite standartları ve olgunluk modelleri...5 Şekil 2.1 Bir projenin başlangıcından bitişine kadar yazılım çevirim etkinlikleri...10 Şekil 2.2 Yazılım geliştirme şelale (Waterfall)modeli...14 Şekil 2.3 Yazılım geliştirme prototip model...15 Şekil 2.4 Yazılım geliştirme spiral model...16 Şekil 2.5 Yazılım yaşam-döngüsü standardının tarihçesi...17 Şekil 2.6 IEEE/EIA Yazılım yaşam çevrimi süreçleri...18 Şekil 2.7 CMM Yazılım süreç olgunluk seviyeleri...26 Şekil 2.8 Yetenek olgunluk modeli yapısı...27 Şekil 2.9 SA-CMM ve SW-CMM ilişkisi...32 Şekil 2.10 CMMI Modelinin tarihsel gelişimi...49 Şekil 2.11 CMMI ın yapısı...52 Şekil 3.1 Tedarik makamı/yüklenici olgunluk seviyelerinin birbirine etkisi...78 Şekil 3.2 Ömür devri proje yönetim aşamaları...79 vii

9 ÇİZELGELER DİZİNİ Çizelge 1.1 Yazılım projeleriyle ilgili birkaç araştırmanın sonuçları...3 Çizelge 2.1 Tedarik edilecek yazılım sisteminin başlangıç aşamasında yazılım süreçleri..12 Çizelge 2.2 Tedarik edilecek yazılım sisteminin geliştirme aşamasında yazılım süreçleri.13 Çizelge 2.3 Tedarik edilecek yazılım sisteminin teslim ve bakım aşamasında yazılım süreçleri...13 Çizelge 2.4 IEEE Std.1062 modeli tedarik ömür devri...22 Çizelge 2.5 Olgun ve olgun olmayan organizasyonların özellikleri...24 Çizelge 2.6 CMM seviyeleri ve anahtar süreç alanları...28 Çizelge 2.7 SA-CMM nin düzeyleri ve anahtar süreç alanları...32 Çizelge 2.8 SW- CMM ve CMMI in Seviye 2 ve Seviye-3 için örnek eşleşmesi...50 Çizelge 2.9 CMMI Basamaklı modelinin olgunluk seviyeleri ve süreç alanları...53 Çizelge 2.10 CMMI sürekli model süreç yetenek düzeyleri ve tanımları...55 Çizelge 2.11 CMMI süreç alanlarının sınıflandırılması...56 Çizelge 2.12 İlk üç genel amacın genel uygulamaları...57 Çizelge 2.13 Kategoriler bazında zaman boyunca performans ilerlemesi.58 Çizelge 2.14 CMMI değerlendirmesi için gerekli süre ve kaynaklar...58 Çizelge 3.1 Türkiye de yazılım sektöründe hizmet veren bazı kuruluşların yazılım ile ilgili sertifikaları...77 Çizelge 3.2 TSK nin 2007 öncesindeki tedarik sürecinde yaşanan sıkıntılar...80 Çizelge 3.3 Tedarik modelleri...83 Çizelge 3.4 Mevcut süreç ile 2007 yılı öncesi tedarik sürecinde yaşanan sıkıntılara getirilen çözümler...84 viii

10 1. GİRİŞ Dünyada teknolojinin hızla gelişmesi ile birlikte yazılım yoğunluklu sistemlerin kullanım alanlarının artması, bu sistemleri günlük hayatımızın ve savunma sanayinin vazgeçilmez bir öğesi haline getirmiştir. Yazılım sistemlerinin etkinliğinin artması, bu sistemlerden daha yüksek beklentilerin ve hedeflerin oluşmasına neden olmuştur. Bugün yüksek teknolojik ürünlerde yazılımın sağladığı katkının her geçen gün nasıl arttığının en güzel örneğini havacılık ve uzay teknolojisinde görmek mümkündür lı yıllarda kullanılan F4 uçaklarına yazılımla kazandırılan işlevsellik %8, 1982 de F16 uçaklarına yazılımla kazandırılan işlevsellik %45 dolaylarında iken 2000 li yıllarda F22 uçaklarına yazılımla kazandırılan işlevsellik %80 e ulaşmıştır. (The Standish Group Reports 1999). Yazılım ağırlıklı sistemler, farklı mühendislik (Elektronik, Makine, Endüstri vb) alanlarına getirdikleri çözümler sayesinde önemli bir yere sahiptir. Bu sistemler üzerinde yazılımın fonksiyonelliğinin her geçen gün artması ve yaşanan tecrübeler; kurumsal ölçekte bilişim altyapılarının kullanımı, organizasyonel ve işlevsel altyapı doğru kurulmadıkça elektronik sistemlerden yeterli düzeyde yararlanılamayacağını göstermiştir. Yazılım ürünlerinin kullanımı ve geliştirilmesinde kurumsal olgunluğun önemiyle ilgili çalışma sonuçlarına, Uluslararası Elektrik Elektronik Mühendisliği Enstitüsü (IEEE) tarafından yayımlanan çeşitli kaynaklardan ulaşılabilmektedir. Ör. Bkz. (Bellini ve Storto 2006), (Bollinger ve McGowan 2009), (Galin ve Avrahami 2006). Yazılım geliştirilmesi aşamasında yürütülen faaliyetler; diğer mühendislik alanlarından farklı özelliklere sahiptir. Yazılımın kendi doğasında yer alan en önemli özellik, süreç yönetimi temeline dayanması ve ürün kalitesinin onu üreten sürecin kalitesi tarafından belirlenmesidir. Yazılım tabanlı sistemlerin gelişmesi, tedarik edilecek ürüne yönelik talepleri de artırmaktadır. Örneğin bir sistemin tedarik edilebilmesi için o günün şartlarına göre 1

11 hazırlanan en ideal şartname bile tedarik için geçen sürede, yeni ihtiyaçların oluşumu ile yetersiz kalabilmektedir. Oluşan yeni isteklerin sisteme kazandırılması için yürütülen modernizasyon çalışmaları ise sistem yazılımlarının büyüklüğünü ve karmaşıklığını arttırmaktadır. Günümüzde kullanılan yazılım sistemlerinin karmaşıklık dereceleri teknik ve yönetsel olarak gruplandırıldığında, hangi alanda ne kadar karmaşıklık derecesi ile karşılaşılabileceği şekil 1.1'de görülebilmektedir. Teknik Karmaşıklık (yüksek) - Gömülü, gerçek zamanlı - Dağıtık, hataya dayanıklı - Özel geliştirme, yüksek başarım Derleyiciler Savunma Sistemleri Silah Kontrol Yönetsel Karmaşıklık (düşük) - Küçük Ölçekli - Resmi olmayan - Tek paydaş - Küçük ürünler Kontrol Sistemleri Üretim Sistemleri Gömülü Otomatik Sistemler Geliştirme Araçları Küçük Ölçekli Bilimsel Benzetimler Bilgi Sistemleri Uygulamaları Dağıtık İşleme Bilgi Sistemleri Uygulamalari Grafik Kullanici Arayuzu Kontrol Sistemleri Enerji Üretim Büyük Ölçekli Benzetimler Bilgi Sistemleri Uygulamaları Girişim Çözümleri Hava Trafik Kontrol Sistemleri Büyük Güvenlik Sistemleri Savunma Sistemleri Askeri Bilgi Sistemleri Devlet Yönetsel Sistemleri Kişi Bilgi Sistemleri Yönetsel Karmaşıklık (yüksek) - Büyük Ölçekli - Sözleşmeye Dayalı - Çok sayida Paydaşlı - Projeler İş Dünyası Yazılımları Calışma Tabloları Atölye Otomasyonu Teknik Karmaşıklık (düşük) - Genelde modern dil kullanımı - Bileşen tabanlı - Uygulamaların tekrar gelişmesi - Etkileşimli başarım Şekil 1.1 Karmaşıklık derecelerine göre yazılımlar (Sarıdoğan 2004) Yazılımın diğer alanlardan farklı özelliklere sahip olmasının yanısıra her geçen gün daha büyük ve karmaşık sistemlerin parçası olması, bu sistemlerin planlanan zaman, verim ve maliyette gerçekleştirilmesinde sorunlar yaşanmasına sebep olabilmektedir. Dünyada yazılım sektöründe hizmet veren bazı kuruluşlarının bu konuda yaptığı inceleme sonuçları çizelge 1.1 de verilmiştir. 2

12 Çizelge 1.1 Yazılım projeleriyle ilgili birkaç araştırmanın sonuçları (Aykol 2005) a. Gartner Institute Bilişim Teknoloji (BT) sektörü araştırması - BT projelerinin %74 ü başarısız ya da maliyet/zaman hedeflerini aşıyor. - BT projelerinin %51 i bütçesini %200 oranında aşıyor ve hedeflenen özelliklerin %75 ini karşılayabiliyor. b. Standish Group (Chaos in the new Millenium 2000) - Yazılım projelerinin başarıya ulaşma oranı %28 dir. - Diğerleri %23 başarısız ya da %49 zorlanmış projelerdir. c. Gartner Group (Technowledge SM 99 Presentation) - BT projelerinin %70 i beklenen faydayı sağlamıyor. ç. Gartner Institute 2001 BT sektörü araştırması - Amerika da her yıl başarısız BT projeleri için 75 milyar dolar harcanıyor. Yazılım projelerinde yaşanan başarısızlıkların yüksek mali kayıplara neden olmasının yanısıra insan hayatını etkileyecek durumların ortaya çıkması, başta ABD olmak üzere birçok ülkeyi bu başarısızlıkların temel sebeplerini araştırtmaya yöneltmiştir. Yazılım projelerinde yaşanan bu sıkıntılar üzerinde yapılan incelemeler, sorunun teknik problemlerden değil yönetimden kaynaklandığını ortaya çıkarmıştır. Bu konuda daha önce çeşitli araştırmacılar tarafından yazılım yoğunluklu sistem geliştirme projelerinin başarı/başarısızlık unsurlarının belirlenmesi amacıyla yapılan çalışmalar incelenerek, en önemli faktörlerin belirlenebilmesi ve aralarındaki ilişkilerin önem derecelerine göre bir model çerçevesinde sistematik olarak ortaya konulabilmesi için Türk Savunma Sanayinde yazılım yoğunluklu sistemlerin tedarik edilmesinde, geliştirilmesinde ve kullanılmasında görev alan proje yöneticisi ve çalışanları ile yapılan inceleme sonucunda; söz konusu projelerin daha başarılı ve etkin bir yöntemle gerçekleştirilip, zamanında istenilen amaçlara ulaşılmasında en önemli unsurun iyi bir proje yöneticisinin projedeki varlığı olduğu ortaya çıkmıştır (Gürkan 2007). Yazılım sistemlerinde diğer mühendislik dalları gibi ürün odaklı kalite yaklaşımından daha çok ürünün ortaya çıkarılmasını sağlayan süreç odaklı yaklaşımın hâkim olduğu belirlenmiştir. Dünyada yazılım sistemlerinin geliştirilebilmesi için çeşitli yazılım süreç 3

13 yöntemleri (Şelale (Waterfall), Prototip ve Spiral Model) kullanılmaktadır. Yazılım geliştiren firmaların, zaman içinde oluşan farklı ihtiyaçları karşılamak ve sorunları çözebilmek için süreç yönetiminde metodoloji kullanılması yaklaşımını geliştirmeleri kalite standartlarının önemini arttırmıştır. Bu kapsamda, yazılım proje yönetiminde geliştirilen standartlar şekil 1.2 de görülmektedir. Her model bir sonraki modelin veya standardın gelişimine katkı sağlamıştır. Bunların arasında özellikle uluslararası alanda yaygın kullanılanlar: ISO/IEC (Software Life Cycle Process-Yazılım Yaşam Döngüsü Süreçleri) Standardı, yazılım süreçlerinin değerlendirilmesi ve iyileştirilmesi konularında geliştirilen CMM (Capability Maturity Model-Yetenek Olgunluk Modeli), CMMI (Capability Maturity Model Integrated-Tümleşik Yetenek Olgunluk Modeli), ISO 9001 ve AQAP-160 dır. Yazılım süreç modelleri; yazılım geliştirmenin mühendislik süreçlerine (gereksinim analizi, tasarım, kod ve test) ve mühendisliğin nasıl uygulanacağına odaklanmaktadır. Yazılım proje yönetiminde geliştirilen standartlar ve olgunluk modelleri ise mühendislik faaliyetlerinin daha başarılı ve etkili yapılmasını sağlamak için proje yönetim ve destek süreçlerine odaklanmaktadır. Bu nedenle yazılım olgunluk modelleri ve yazılım geliştirme süreç modelleri yazılım endüstrisinde çoğu zaman müşterek olarak kullanılmaktadır (Sen ve Zheng 2007). Örneğin Bollinger ve McGowan (1991) kuruluşların yazılım yeteneklerinin değerlendirilmesinin zorluğuna ve önemine değindikleri çalışmalarını, 2009 yılında (Bollinger ve McGowan 2009) gözden geçirirken...şu sırada gerçekten önemli yazılım sistemleri için gerekli ama yeterli olmayan kısıtlar için en geçerli yanıtımız CMMI dır. ifadesini kullanmışlardır. Günümüzde artan rekabet koşullarında yazılım firmalarının maliyet, süre ve verimlilik bakımından planlarına uyan, faydalı ve güvenilebilir yazılımları geliştirme ihtiyacı, kurumların uygun süreç modellerini kullanmalarını gerektirmiştir. Bu organizasyonlar hazır bir süreci benimseyebildikleri gibi, mevcut süreçlerin yetersizliklerini araştırıp gidererek kendi kurumsal yapılarına uygun olarak oluşturdukları süreci uygulayarak da başarılı sonuçlara ulaşabilmektedirler. 4

14 PSP People CMM SA-CMM SW-CMM ISO NATO AQAP 160 DOD- STD MIL-STD-498 DOD-STD -2167A FAA- ICMM CMMI* NATO AQAP 150 ISO SE-CMM TickIT SSE- CMM Q9000 ISO 9000 SERIES ISO 15288* IEEE Şekil 1.2 Yazılım proje yönetim alanında geliştirilen kalite standartları ve olgunluk modelleri (Ferguson ve Sheard 1998, Tuluk 2005) Yazılım projelerinin geliştirmesinde yazılım süreç yöntemleri ile birlikte yazılım kalite standartlarının kullanımı projelerin başarı ile tamamlanmasında olumlu katkı sağlamıştır. Türkiye deki yazılım firmalarının ve özellikle Savunma Sanayinde yazılım yoğunluklu ürün geliştiren firmaların; bu gelişimleri takip ederek, kendi kurumsal yapılarına ve oluşturacakları ürüne bağlı olarak uygun bir modeli benimseyip kullanmaları, hem başarı oranlarının yükselmesini hem de uluslarası rekabet ortamında daha güçlü olmalarını sağlamaktadır. Yazılım projeleri için geliştirilen kalite standartları ve olgunluk modellerinin, yüklenici ve tedarik makamı tarafından benimsenerek kullanılması durumunda istenen başarıya ulaşma olasılığı artmaktadır. Yüklenici kurum olarak Türk Savunma Sanayinde yazılım üreten firmaların en büyük müşterisi Türk Silahlı Kuvvetleri (TSK) dir. TSK de yazılım yoğunluklu sistemlerin tedariği; Planlama Programlama Bütçe Sistemi (PPBS) faaliyetleri sonucunda ihtiyaçların projelendirilmesi ile belirlenen tedarik makamı ve modeline göre gerçekleştirilmektedir. Bu faaliyetler 2007 yılında güncelenerek yürürlüğe giren MY Planlama Programlama Bütçeleme Sistemi (PPBS) yönergesine göre yürütülmektedir. 5

15 Dünyadaki diğer büyük ülkelerin silahlı kuvvetleri de farklı PPBS ve proje yönetim planlarını uygulamalarının yanısıra, yazılım projelerinde süreç bazlı kalite standartlarının kullanılması istenmekte ve özellikle ABD bu alanda yürütülen çalışmaları teşvik etmektedir. TSK nin mevcut tedarik sürecinin de bu uluslararası standartlardan faydalanarak geliştirilmesinin yazılım projelerinin başarısına olumlu katkı sağlayacağı değerlendirilmektedir. Ayrıca TSK her alanda ulaşmayı hedeflediği yüksek olgunluk seviyesini, özellikle milli ve kritik sistemlerin geliştirilmesinde bir ön koşul olarak ortaya koyarak, Türk Savunma Sanayi firmalarının olgunluk seviyesini arttırmalarını, dolayısıyla daha başarılı ve kaliteli iş yapmalarını teşvik etmiş olacaktır. Bu tez çalışmasında sırası ile; Bir yazılım sisteminin geliştirilebilmesi için gerekli yaşam çevrimi faaliyetleri ve izlenecek yazılım proje yönetim faaliyetleri gözden geçirildikten sonra, yazılım sistemlerini geliştirmek için kullanılan yazılım süreç yöntemleri (Şelale (Waterfall), Prototip ve Spiral Model) kısaca incelenip, süreç odaklı yaklaşım sonucunda oluşan olgunluk seviyesi modelleri ele alınacaktır. -Yazılım mühendisliği ve yazılımda kalite anlayışının sonucu olarak, yazılım proje yönetiminde geliştirilen olgunluk modelleri ve kalite standartları (CMM, CMMI, AQAP 160, ISO 9001) incelendikten sonra bu modellerin tedarik süreçlerinde kullanımı karşılaştırmalı olarak tartışılacaktır. - Özellikle Türk Savunma Sanayii ndeki yazılım firmalarının söz konusu uluslararası standartları kullanım durumu araştırılacaktır. Ayrıca daha önce yayımlanmış tez çalışmalarında verilen bilgiler ile firma/kurum ve kuruluşlarla paylaşılan bilgiler çerçevesinde, TSK nin 2007 öncesi ve sonrasında uygulanan tedarik süreci incelenecektir. Bu kapsamda, mevcut tedarik sürecinin yayımlanmasından kısa bir süre önce sonuçlanan bir doktora çalışmasında önerilen tedarik modelinin (Gürkan 2007) sağlayacağı faydaların, mevcut tedarik sürecinde karşılanma durumu değerlendirilecektir. Bunun ardından, mevcut tedarik sürecinin günümüzün teknolojisi 6

16 ve gereksinimleri ile uyumunun sağlanabilmesi için Yazılım Alımı Yetenek Olgunluk Modeli (SA CMM) ölçütlerinden yararlanılarak gerçekçi tedarik süreci iyileştirme önerileri ortaya konulmaya çalışılacaktır. Bu önerilerin kurumsal kültür, yasal mevzuat ve uygulama yöntemleri bakımından gerçekçi nitelik taşıması ve dolayısıyla uygulanabilir olmaları bu çalışmanın her aşamasında gözetilen bir kısıt olmuştur. 7

17 2. YAZILIM SÜREÇ YÖNETİMİ 2.1 Tanımlar Bu bölümde, tez kapsamında sıkça kullanılacak terimlerin tanımları sunulmuştur. Yazılım: Değişik ve çeşitli görevler yapma amaçlı tasarlanmış elektronik araçların birbirleriyle haberleşebilmesini ve uyumunu sağlayarak, görevlerini ya da kullanılabilirliklerini geliştirmeye yarayan makine komutlarıdır.(htp://tr.wikipedia.org, 2009) Süreç: Belirli bir girdiyi, müşterileri için belirli bir dizi faydalı çıktıya dönüştüren; tanımlanabilen, sınırları konulabilen, tekrarlanabilen, ölçülebilen, mutlaka bir sorumlusu olan, fonksiyonlar arası ve birbirine bağlı değer yaratan faaliyetler dizinidir. (Standartlar Belgelendirme Ltd. Şti.Etkin Süreç Yönetimi ve ISO 9001: ) Yazılım Süreci (Software Process): Yazılımın ve yazılıma bütünleşik diğer ürünlerin (örnek olarak; proje planları, tasarım dokümanları, kod, test durumları, kullanıcı kılavuzları) geliştirilmesi ve bakımı için kullanılan aktivitelerin, metotların, uygulamaların ve dönüşümlerin oluşturduğu bütündür. ( Carnegie Mellon Üniversitesi - Software Engineering Institue (SEI): Amerikan Savunma Bakanlığı nın (Department of Defense-DOD) yazılım sistemlerini öngörülebilen takvim, maliyet ve performanslar dahilinde tedarik etmesini sağlamak, yazılım mühendisliği uygulamalarının geliştirilmesi ve yazılım sistemlerinin kalitesini arttırmak amacı ABD de 1984 yılında kurulmuş ve fonları federal hükümet tarafından sağlanan bir araştırma-geliştirme merkezidir. SEI nin görevi, yazılıma bağımlı sistemlerin kalitesini arttırmak için yazılım mühendisliği uygulamalarını geliştirmek üzere liderlik etmektir (Tatlı 2007). 8

18 2.2 Yazılım Projelerinin Yaşam Çevrimi Faaliyetleri Teknolojinin hızla gelişmesi ile birlikte yazılım ağırlıklı elektronik sistemlerin savunma alanında kullanımı her geçen gün artmaktadır. Yazılım projelerinin geliştirilmesinde zaman içinde yaşanan tecrübelerden faydalanılarak, tedarik edilecek yazılım sistemlerinin tedarikçinin istediği ihtiyaçları, fonksiyonelliği, güvenilirliği ve verimliliği sağlayabilmesi için belirli standartlar, yöntemler ve araçlar geliştirilmiştir. Donanım ve yazılımdan oluşan savunma sistemlerinin, planlama, sistem çözümlemesi, tasarım, gerçekleştirim ve test aşamalarından oluşan bir proje yaşam çevrimi yöntemi kullanılarak gerçekleştirilmesi projelerin başarısında önemlidir. Bu aşamaların uygulanışı kurumun yapısı, projenin büyüklüğü ve sistem amaçlarına göre farklı olabilmektedir. En son ve en yaygın yazılım geliştirme standardı olan IEEE/EIA ye göre bir projenin başlangıcından bitişine kadar basit yazılım çevrim etkinlikleri şekil 2.1 de belirtildiği üzere Edinme Süreci, Sağlama Süreci, Geliştirme Süreci, İşletme Süreci ve Bakım Sürecinden oluşmaktadır. Edinme Sürecinin ilk aşaması; kullanıcının ihtiyacını karşılayacak sistemin geliştirilebilmesi için kullanıcı isterlerinin (gereksinimlerinin) belirlenmesi ve bu isterleri sağlayacak sistemin tanımlanmasından oluşmaktadır. Projelerin belirli bir zaman ve maliyet ile gerçekleştirilmesi istenmektedir. Bu amaçla sistemin genel isterleri belirlendikten sonra sistemin projelendirilmesinden önce, mevcut teknolojik olanaklar ile bunların sağlanmasının mümkün olup olmadığının belirlenebilmesi için yapılabililik araştırması gerekmektedir. Gerçekleştirilmek istenen sistemin yapılabilirlik araştırmasında; maliyet, teknik ve yasal açıdan yapılabilirliğin değerlendirilmesi, alternatif çözümlerin incelenmesi, risklerin belirlenmesi ve benzer diğer projelerin başarılarına göre maliyet öngörüsü ile geliştirme sürecinin ana çizgilerinin oluşturulması hedeflenmektedir. Tanımlanan sistemin kullanıcı ortamı sistem çözümlemesi(analizi) yöntemi ile modellenmektedir. Çözümleme aşaması 9

19 sonunda ortaya çıkan fonksiyon ve gereksinimlerin yazılım, donanım ve kullanıcı tarafından sağlanacakların belirlenmesi ile sistemin genel mimari yapısı, donanım türü ve miktarı, kullanım yöntemi, kullanıcı arayüzü ve personel ihtiyaçları ortaya konulmaktadır. EDİNME SÜRECİ SAĞLAMA SÜRECİ GELİŞTİRME SÜRECİ İŞLETME SÜRECİ BAKIM SÜRECİ BAŞLANGIÇ Sistem kavramsal tanımı, temel sistem gereksinimlerinin belirlenmesi Teklif İsteği Teklif Değerlendirilmesi İsterlerin Çözümlemesi Yazılımın Çözümlenmesi, Tasarımı, Gerçekleştirilmesi, Testi İyileştirici ve düzeltici bakım Sözleşme Hazırlanması Görüşmeler ve Sözleşme İmzalanması Donanım ve yazılım öğelerinin tümleştirilmesi Sistemin işletilmesi Sistemin kullanımının sona ermesi İş Tanımı Sistem testi ve teslim BİTİŞ Şekil 2.1 Bir projenin başlangıcından bitişine kadar yazılım çevrim etkinlikleri (Sarıdoğan 2004) Yapılabilirlik araştırması sonucunda elde edilen verilere göre edinme sürecindeki teklif isteği dokümanı hazırlanmaktadır. Daha sonra bu gereksinimleri karşılayabilecek firmanın (yüklenicinin) seçilebilmesi için teklif isteği dokümanı firmalara gönderilmekte, ardından gelen tekliflerin, bu dokümanda belirtilen gereksinimleri karşılama durumlarına göre değerlendirilmeleri sonucunda seçilen firma ile imzalanacak sözleşme hazırlanmaktadır. Tedarik Sürecinde, yüklenicilerin teklif isteği dokümanına verdiği cevaplar değerlendirildikten sonra seçilen firma ile sözleşme imzalanmak üzere görüşmeler icra 10

20 edilmektedir. İmzalanan sözleşme gereği projenin gerçekleştirilmesinde izlencek yolu belirten İş Tanımı Dokümanı hazırlanmaktadır. Genel sistem gereksinimlerinin hangi yazılım ve donanım ile sağlanabileceği belirlendikten sonra kurumun yapısına, projenin büyüklüğüne ve sistem amaçlarına göre seçilen yazılım geliştirme yöntemi ile sistem gerçekleştirilmektedir. Geliştirilen veya hazır alınan her bir yazılım ve donanım öğesi kendi içinde test edildikten sonra diğer öğelerle bir araya getirilerek sistem tümleştirilir. Tümleştirme tamamlandıktan sonra sistemin bir bütün olarak kullanılacağı ortamda çeşitli test ve denemeler ile doğrulaması yapılarak müşteri kabul testleri gerçekleştirilmektedir. Geliştirilen sisteme yönelik eğitimler (kullanıcı eğitimi ve donanım/yazılım bakım eğitimi) verildikten sonra ilk kullanım esnasında ortaya çıkan sorunların garanti süresi içerisinde giderilmesinin ardından sistem kullanıcı tarafından teslim alınmış olur. Sistem envanterde kaldığı sürece ihtiyaç duyulan genel kontrol, iyileştirme ve düzeltici faaliyetler bakım aşamasında yapılmaktadır. 2.3 Yazılım sistemlerinin proje yönetim süreci Kullanıcı ihtiyaçlarını sağlayacak sistemin tanımlanmasından, bakım aşamasına kadar projelerin başarı ile tamamlanabilmesi için projeler belirli yöntemler kullanılarak gerçekleştirilmektedir. Proje yönetimi ile projenin organizasyon yapısı kurulup, yetki ve sorumluklar belirlenip, gerçekleştirilecek işin proje yönetim planı hazırlanıp, geliştirme süresince proje devamlı olarak kontrol edilerek, gerekli düzeltmeler ve iyileştirmeler yapılmaktadır. Proje yönetim süreci, sistem geliştirebilmek için gerekli mühendislik faaliyetlerini içeren idari ve teknik planlara göre gerçekleştirilmektedir. Tedarik edilecek bir yazılım sisteminin standart bir yazılım geliştirme sürecinde bulunan evreler, kritik aşama noktaları ve her aşama sonunda üretilecek belgeler; Başlangıç, Geliştirme ve Teslim ve Bakım olarak gruplandırılarak çizelge de sıra ile verilmiştir (Sarıdoğan 2004). 11

21 Çizelge 2.1 Tedarik edilecek yazılım sisteminin başlangıç aşamasında yazılım süreçleri (Saridoğan 2004) Aşama Noktası Temel Evre Süreç Araştırma Belge Araştırma Yapılabilirlik Araştırması Yapılabilirlik Raporu veya İnceleme Etüdü Projelendirme (Müşteri veya Tanımlama Projelendirme İşletim Kavramı Tanımlaması Proje Tanımlama Belgesi geliştirici tarafından ) Edinme Süreci Teknik Şartname veya Proje Beratı Görevlendirme İş Tanımı veya Proje Beratı Planlama Planlama ve Proje Planlaması Proje Yönetim Planı Hazırlık Kalite Güvence Planı Sistem Mühendisliği Yönetim Planı Konfigürasyon Yönetim Planı Risk Yönetim Planı Sistem Test Planı (Doğrulama Planı, Onaylama Planı) Yazılım Geliştirme Standartları Tanımı Yazılım Geliştirme Planı (Geliştirme Süreci Planı) Bakım Süreci Planı İşletim Süreci Planı Yazılım Test Planı Yazılım ve Donanım Yazılım Kurulum Planı Geliştirme Ortamının Yazılım Aktarım Planı Kurulması Donanım Geliştirme Planı Personel Görevlendirme Görevlendirme Planlaması Proje Takvimi Eğitim Planlaması Kurumsal Eğitim Planı 12

22 Çizelge 2.2 Tedarik edilecek yazılım sisteminin geliştirme aşamasında yazılım süreçleri (Sarıdoğan 2004) Aşama Noktası Fonksiyonel Sabitleme Ürün Sabitleme Temel Evre Süreç Araştırma Belge Sistem Çözümlemesi Yazılım Gerçekleştirimi Sistem İsterleri Çözümlemesi Sistem Tasarımı Sistem Yazılım İsterleri Çözümlemesi Sistem Yazılım Tasarımı Her Öğe İçin Yazılım İsterleri Çözümlemesi Her Öğe İçin Yazılım Tasarımı Her Öğe İçin Yazılım Gerçekleştirimi ve Birim Testi Her Öğe İçin Birim Tümleştirme ve Test Sistem-Alt sistem Tanımlaması Ara yüz İsterleri Tanımlaması Alt sistem Teknik Anlaşmaları Sistem-Alt Sistem Tasarım Tanımlaması Sistem Mimari ve İster Atama Tanımı Ara yüz Tasarım Tanımlaması Sistem Yazılım İsterleri Tanımlaması Sistem Yazılım Tasarımı Tanımlaması Veri Tabanı Tasarım Tanımlaması Yazılım İsterleri Tanımlaması Ara yüz isterleri Tanımlaması Yazılım Tasarım Tanımlaması Ara yüz Tasarım Tanımlaması Kaynak Kod Yazılım Geliştirme Dosyaları Yazılım Test Tanımlaması Öğe Yeterlilik Testi Yazılım Test Tanımlaması Test Sonuç Raporu Test Tümleştirme ve Test Sistem Tümleştirme Testi Tanımlaması Kabul Testi Tanımlaması Çalışma Testi Sistem Yeterlilik Testi Yerinde Kabul Testleri Tanımlaması Kabul Testi Raporu Çizelge 2.3 Tedarik edilecek yazılım sisteminin teslim ve bakım aşamasında yazılım süreçleri (Sarıdoğan 2004) Aşama Noktası Kullanım Temel Evre Süreç Araştırma Belge Kullanıcıya Teslim Yazılım Kullanıma Hazırlama Yazılımı Aktarmaya Hazırlanma (gerektiğinde) Bakım Bakım Yazılım Bakımı Yazılım Ürün Tanımlaması Yazılım Sürüm Tanımlaması Kullanıcı Kılavuzları Yazılım Kurulum Kılavuzu Yazılım Ürün Tanımlaması Yazılım Sürüm Tanımlaması Bilgisayar Programlama Kılavuzu Kaynak Kod Yazılım Geliştirme dosyaları Yazılım Sorun Raporu Sorun Giderme Raporu Değişiklik Önerisi (Değişiklik İsteği ve Düzeltme İsteği) 13

23 2.4 Yazılım Geliştirme Süreç Modelleri Yazılım süreç modelleri, yazılım sisteminin geliştirilebilmesi için oluşturulmuş faaliyetlerini içermektedir. Bu alt bölümde, bu süreç modellerinin başlıcaları olan Şelale (Waterfall) Modeli, Prototip Model ve Spiral Modeli gözden geçirilecektir. Yazılım projesinin içeriğine, kurumun yapısına ve geçmişte yaşanan deneyimlere göre bu modellerden uygun olanı kullanılabilmektedir Şelale (Waterfall) Modeli Yazılım proje yönetimi alanında temel oluşturan ve doğrusal olarak yazılım gelişimi sağlayan Şelale (Waterfall) Modelinin akış diyagramı şekil 2.2 de verilmiştir. İhtiyaçların Belirlenmesi Sistem Tasarımı Gerçekleştirme (Kodlama) Entegrasyon ve Sistem Testi Ürün İşletme-Bakım Onarım Müşteri Şekil 2.2 Yazılım geliştirme şelale (Waterfall)modeli (Kalıpsız 2006) Özellikle gereksinimlerin proje süresi içinde değişmeyeceği bilindiğinde, bunların perojenin ilk aşamasında iyi tanımlanabildiği ve tedarik makamının sürekli destek sağlayamayacağı (yurtdışı) projeler için uygun bir yöntemdir. Şelale (Waterfall) Modeli en eski ve en yaygın kullanılan yazılım geliştirme yöntemi olmasına rağmen, aşağıda belirtilen dezavantajlarından dolayı son zamanlarda birçok büyük projede uygun bulunmamaktadır. Belirlenen ihtiyaçlar geliştirme sürecinde değişebildiği için projelerin çevrim tekrarı olmadan ardışık sıra izlemesi çok ender rastlanan bir durumdur. Bu da projelerin planlanan bütçe ve zamanda teslim edilmesini olumsuz olarak etkiler. 14

24 Kullanıcının tüm gereksinimlerinin ilk aşamada doğru tanımlanması her zaman mümkün olmayabilir. Kullanıcı, ürünü ortaya çıktıktan sonra görebilmekte ve ürünün oluşması uzun zaman aldığında kullanıcının ihtiyaçları değişebilmektedir. Bu durum, kullanıcının geliştirme sürecine katılması ve gelişen ihtiyaçların ürüne yansıtılması ile önlenebilmektedir. Bu da şelale sürecinin tanımına uymamaktadır Prototip Model Kullanıcı gereksinimlerinin ayrıntılı ve kesin olarak tanımlanamadığı ve/veya geliştiricinin de ortaya konan ihtiyaçların karşılanmasında kullanılacak yazılım ve donanımın yeterli olduğuna emin olamadığı, belirsizlik durumlarında akış diyagramı şekil 2.3 de verilen prototip yazılım geliştirme yöntemi kullanılabilir. İhtiyaç duyulan sistemin nasıl olacağı hakkında kullanıcıya fikir verilebilmesi için bir ön modeli yapılır, daha sonra bu modeldeki eksiklikler belirlenerek süreç içinde giderilmeye çalışılır. Müşteri İsteklerin Belirlenmesi (Analiz) Sistem Tasarımı Gerçekleştirme (Kodlama) Entegrasyon ve Sistem Testi Ürün İşletme-Bakım Onarım Prototip Şekil 2.3 Yazılım geliştirme prototip model (Kalıpsız 2006) Prototip yönteminde sistem gereksinimlerini kullanıcı ve geliştirici birlikte tanımlayarak, detaylı çalışılması gerekecek alanlar belirlenir, sonra sistem tasarımı yapılarak temel işlevleri belirlendikten sonra ilk örneğin (prototip) buna göre geliştirilmesi sağlanır. Geliştirilen prototip kullanıcı tarafından denenir ve oluşan istekler değerlendirildikten sonra protipe yansıtılır. Kullanım alanlarına göre geliştirilen 15

25 prototip uygun görülüp sistem haline getirilebileceği gibi istekleri karşılamadığı düşünülerek tamamen iptal edilip, yeni bir prototip geliştirildikten sonra sistemin yapılmasına karar verilebilmektedir Spiral Model Üst model olarak ifade edilen spiral model şekil 2.4 de görüldüğü gibi genel olarak art arda tekrarlanan planlama, risk çözümlemesi, mühendislik ve değerlendirme aşamalarından oluşur. Planlama aşamasında, belirlenen amaçlara göre alternatifler ve kısıtlamalar değerlendirilmektedir. Risk Çözümlemesi aşamasında, tanımlanan riskler için çözüm yöntemleri araştırılmaktadır. Mühendislik aşamasında ürün geliştirilmektedir. Değerlendirme aşamasında, geliştirilen ürün kullanıcı ile birlikte incelenmektedir. Planlama Risk Çözümleme Değerlendirme Mühendislik Şekil 5.4. Yazılım Geliştirme Spiral Model Şekil 2.4 Yazılım geliştirme spiral model (Kalıpsız 2006) İlk aşamada tanımlanan isterlere göre proje planlaması yapılır. İkinci aşamada, tanımlanan bu isterlere göre bir risk çözümlemesi yapılır. Üçüncü aşamada, prototip yöntemi (veya modelleme yöntemi) kullanılarak risk çözümlemesi sonucunda ortaya çıkan isterlerin tanımlanmasındaki belirsizlikler giderilir. Dördüncü aşamada; ortaya 16

26 çıkan ilk ürün kullanıcı tarafından incelendikten sonra önerilerde bulunur. Bu şekilde tanımlanan ilk döngü bir sonraki döngü için bir girdi oluşturur. Her aşamada müşteri ve geliştirici önemli ara ürünleri birlikte belirleyip, riskleri anlayarak önlemler almaktadır. 2.5 Askeri Yazılım Sistemlerinin Geliştirme Süreci Ülkeler daha üstün özelliklerde silah ve savunma sistemine sahip olabilmek için savunma alanında büyük yatırımlar yapmakta ve Araştırma Geliştirme (ARGE) çalışmalarına önem vermektedir. Askeri sistemlerin kendine has özelliklerinin (güvenilirlik, gerçek zamanlı çalışma, etkinlik, birlikte çalışabilirlik, uzun süre kullanılması, savaş/barış şartlarında kullanılması vb.) sağlanabilmesi için gerçekleştirilecek faaliyetlerin askeri standartlara göre yapılması gerekmektedir. Askeri sistemler için geliştirilen yazılımların diğer sistemlere göre farklı niteliklere sahip olması askeri yazılım projelerinin de diğer yazılım geliştirme projelerine göre daha dikkatli bir süreç altında yürütülmesini gerektirmektedir. İlk defa Amerikan Savunma Bakanlığı (Department of Defense-DOD) bünyesindeki kuruluşlar tarafından oluşturulan Amerikan Askeri Standartlarının tarihsel bir süreç içinde gelişimi ve IEEE/EIA standardının bu tarihçe içindeki yeri şekil 2.5 de görülmektedir. Askeri yazılım geliştiren yükleniciler için bu standartların uygulanması zorunlu hale getirilmiştir. DOD-STD-2167A Defense System Software Development 29 Şubat Aralık A ISO/IEC Software Life CycleProcesses 1 Ağustos 1995 ISO A MIL-STD-498 Software Development and Documentation Standards DOD-STD-7935A 5 Aralık Mayıs 1998 DOD Automated Information Systems (AIS) Documentation Standards Ekim Aralık J-STD Software Life Cycle Processes, Software Development 30 Eylül 1995-Deneme IEEE/EIA IEEE/EIA IEEE/EIA Software Life Cycle Processes 31 Mart 1998 Şekil 2.5 Yazılım yaşam döngüsü standardının tarihçesi (Sarıdoğan 2004) 17

27 En son geliştirilen ve yaygın olarak kullanılan IEEE/EIA 12207, yazılım geliştirme sürecindeki kullanıcı, tedarikçi, geliştirici, yüklenici, alt yüklenici ve teslimattan sonraki destek vb. ile bunlar arasındaki bağlantıların tanımlandığı sistem mühendisliği ilkesine dayanmaktadır. Bu standart herhangi bir yazılım yaşam çevrim modeli (şelale, spiral, prototipleme vb.) ile birlikte kullanılabilmektedir. IEEE/EIA standardı ile tanımlanan yazılım yaşam çevrimi, yazılıma ihtiyaç duyulmasından yazılımın kullanımdan kalkıncaya kadarki faaliyetleri tanımlayan 5 temel süreç, 9 destek süreci ve 4 organizasyonel süreçten oluşmaktadır. Şekil 2.6 da içeriği gösterilen bu süreçlerin özellikleri aşağıda açıklanmıştır. Yaşam Çevrimi Temel Süreçler Edinme Sağlama Geliştirme İşletme Bakım Destekleyici Süreçler Belgelendirme Düzen Yönetimi Kalite Güvence Doğrulama Gerçekleştirme Birleşik Gözden Geçirme Denetim Problem Çözme Organizasyonel Süreçler Yönetim Altyapı İyileşme Eğitim Şekil 2.6 IEEE/EIA Yazılım yaşam çevrimi süreçleri (Sarıdoğan 2004) Temel Süreçler: Yaşam çevriminin esas sağlayıcılarıdır. IEEE/EIA standardı bir yazılım projesinin başlangıcından bitişine kadar yaşam döngüsü boyunca icra edilecek; yazılım edinme, sağlama, geliştirme, işletme ve bakım süreci faaliyetlerini tanımlamaktadır. -Edinme (acquisition) Süreci: Sözleşme kapsamında yazılım sistemini geliştirecek yüklenicinin ve kullanıcının (müşterinin) görevlerinin tanımlandığı aşamadır. Teklife çağrı dosyasının hazırlanması, sözleşme hazırlanması, sözleşme sonrası satıcının izlenmesi ve ürünün kabulü ile sözleşmenin tamamlanmasını kapsayan ana faaliyetlerden oluşmaktadır. 18

28 -Sağlama (supply) Süreci: Yazılım sistemini sağlayan kurumun (yüklenici) sorumluluğundaki, teklife yanıt hazırlanması, sözleşme, planlama, yürütme ve denetim, gözden geçirme ve değerlendirme, teslim ve tamamlama faaliyetlerini içermektedir. -Geliştirme (development) Süreci: Sistem istekleri çözümlemesi, sistem tasarımı, yazılım istekleri çözümlemesi, yazılım mimari tasarımı, yazılım ayrıntılı tasarımı, yazılım kodlama ve test, yazılım tümleştirme, yazılım geçerlilik testi, sistem tümleştirme, sistem geçerlilik testi, yazılım yükleme ve yazılım kabul desteği yerine getirilmektedir. -İşletme (operation) Süreci: Yazılımın işletilmesini sağlayacak kullanıcı faaliyetlerinden oluşmaktadır. -Bakım (maintenance) Süreci: Kullanıcı gereksinimlerini karşılayabilmesi için yazılımın güncelleştirilmesi, arızalarının giderilmesi, gözden geçirilmesi, taşınması, kabulü ve kullanımdan kaldırılması faaliyetlerini kapsamaktadır. Destekleyici Süreçler: Projenin başarılı olması ve kalitesinin arttırılması için yazılım yaşam döngüsü boyunca diğer süreçlere destek sağlayan faaliyeler yerine getirilmektedir. -Belgelendirme (documentation) Süreci: Yazılım yaşam döngüsü süresince üretilen bilginin kayıt edildiği aşamadır. Yazılım kullanıcılarının gereksinim duyduğu belgelerin planlanmasını, tasarlanmasını, geliştirilmesini, dağıtımını ve bakımını sağlayan etkinliklerden oluşmaktadır. -Konfigürasyon Yönetimi (configuration management) Süreci: Bir sistemin tanımlanan yazılım bileşenlerindeki değişikliklerin ve sürümlerinin kontrol edilip, kaydedilerek raporlandığı faaliyeleri içermektedir. 19

29 -Kalite Güvence (quality assurance) Süreci: Yazılımın planlamalara ve sözleşme isterlerine uygunluğunun güvence altına alınmasını sağlayacak faaliyetlerden oluşmaktadır. -Doğrulama (verification) Süreci: Sistem isteklerinin doğruluğunun ve tam olarak karşılandığının belirlenebilmesi amacıyla gerçekleştirilecek faaliyetlerden oluşmaktadır. -Onaylama (validation) Süreci: Geliştirilmiş yazılımın son halinin belirlenmiş kullanım amacına uygunluğunun değerlendirildiği faaliyetleri içermektedir. Projenin içeriğine göre onaylama ölçüsü ve kapsamı farklı yapılmaktadır. -Birleşik Gözden Geçirme (joint review) Süreci: Bir yaşam çevrimi sürecinde, teknik gözden geçirmeler ile ürünlerin durumu değerlendirilmekte, proje yönetim gözden geçirmeleri ile durumun planlara ve takvime göre uygunluğu incelenmektedir. -Denetim (audit) Süreci: Yüklenicinin ürünü isteklere ve planlamalara uygun olarak geliştirdiğinin değerlendirilmesi için alıcının gerçekleştireceği faaliyetlerden oluşmaktadır. -Problem Çözme (problem resolution) Süreçleri: Karşılaşılan problemlerin çözülmesi ve bu çözümlerin izlenmesini sağlayacak bir süreçten oluşmaktadır. Organizasyonel Süreçler: Bir kurum içinde yaşam çevriminin gerçekleştirilmesini, kontrol edilmesini ve iyileştirilmesini sağlamak üzere 4 adet örgütsel süreç tanımlamaktadır. -Yönetim (management) Süreci: Yönetim isterlerinin belirlenmesi, planlamayı, yürütmeyi, denetimi, gözden geçirmeyi, değerlendirme ve kapanışı kapsamaktadır. 20

30 Temel süreçdeki benzer faaliyetlerden hedef ve yöntemlerdeki ayrıntılar açısından farklılıklar vardır. -Altyapı (infrastructure) Süreci: Altyapı kapsamında gerekenlerin tanımlanması, planlanıp belgelendirilerek, uygun zamanda kurulması ve sürecin isterlerine göre devam ettirilebilmesi için gerekli faaliyetlerden oluşmaktadır. -İyileştirme (improvment) Süreci: Bir örgütün yaşam çevrimi sürecini değerlendirmek, ölçmek, denetlemek ve iyileştirmek için gereken faaliyetlerden oluşmaktadır. Kurumsal düzeyde yürütülen bu etkinlikler, önceki projelerden elde edinilen deneyimlerle birlikte süreç iyileştirmede kullanılarak, kurumsal fayda sağlamakla birlikte mevcut ve planlanacak projelerde gelişen yazılım teknolojilerinden daha fazla yararlanılmasını sağlayacaktır. -Eğitim (training) Süreci: Yönetim ve teknik aşamalarda tanımlanmış personel yetiştirmek için eğitim gereksinimlerinin belirlenmesi, planlanması, verilmesi ve kayıt edilmesi faaliyetlerinden oluşmaktadır. ISO/IEC de dikkat edilmesi gereken en önemli husus; yaşam döngüsü süreçleri tanımlanırken süreçlerin yeteneğini değerlendirmeyi sağlayan bir model ile birlikte kullanılması gerekmektedir. Yazılım süreç iyileştirme için bir organizasyonda temel olarak bulunması gereken süreçleri tanımlayan IEEE/EIA ye ek olarak yazılım sistemlerinin tedarik edilmesinde yardımcı olarak kullanılabilecek standartlar IEEE 982.1, IEEE 1062 ve IEEE 1228 dır. Bunlardan IEEE 1062 nin kapsamı çizelge 2.4 de verilmiştir. Bu model, tedarik makamı ile üretici firma (yüklenici) arasında bütünlüğü sağlayarak, tedarik planlaması sırasında kaliteyi öne çıkarıp, üretici firmanın değerlendirilmesi için yol gösterici 5 ana aşama ve 9 alt süreçten oluşmaktadır. 21

31 Çizelge 2.4 IEEE 1062 modeli tedarik ömür devri. 1. Planlama 2. Sözleşme 1.Organizasyon Stratejisinin Planlaması 2.Organizasyonda İcra Edilecek Süreçlerin Uygulaması 3.Yazılım İhtiyaçlarının Belirlenmesi 4.Muhtemel Üretici Firmaların Belirlenmesi 5.Sözleşme Gereksinimlerinin Hazırlanması 6.Tekliflerin Değerlendirilmesi ve Üretici Firmanın Seçimi 3.Ürünün Uygulaması 7.Üretici Firma Performansının Kontrolü 4. Ürün Kabulü 8.Yazılımın Kabulü 5. İdame 9.Yazılımın Kullanılması 1.1.Planlama sürecinin başlatılması 1.2.Organizasyon stratejisinin belirlenmesi 1.3.Genel uygulama yöntemlerinin oluşturulması 2.1.Yazılım tedarik sürecinin oluşturulması 2.2.Sözleşme uygulama yöntemlerinin belirlenmesi 2.3.Diğer organizasyonlardan gerekli hizmetlerin sağlanması 2.4.Yazılım tedarik sürecinin başarısı için sorumluluk makamının belirlenesi 2.5.Sürecin amaca göre düzenlenmesi 3.1.Tedarik edilecek yazılımın tanımlanması 3.2.Teklif değerlendirme standardının belirlenmesi 3.3.Tedarik makamı ve üretici firma sorumluluklarının belirlenmesi 3.4.Yazılım ve hizmetlerin değerlendirilmesi, kabulü için planların oluşturulması 3.5.Olasılık planlarının geliştirilmesi 4.1.Mevcut yazılım ürünleri ile ilgili bilgilerin toplanması 4.2.Gösteri esnasında yazılımın değerlendirilmesi 4.3.Üretici firmanın yazılımını kullanan müşterilerin araştırılması 4.4.Önceki sözleşmelere ait performans bilgilerinin gözden geçirilmesi 4.5.Üretici firma tekliflerinin araştırılması 5.1.İşin kalitesinin belirlenmesi 5.2.Ödemenin nasıl yapılacağının belirlenmesi 5.3.Başarısızlık durumunda yapılacakların belirlenmesi 5.4.Sözleşme şartlarının hazırlanması 5.5.Sözleşme şartlarının adli yönden gözden geçirilmesi 6.1.Tekliflerin değerlendirilmesi 6.2.Tesislerin yerinde görülmesi 6.3.Kalifiye bir üretici firmanın seçilmesi 6.4.Sözleşmenin görüşülmesi 7.2.Sözleşmenin icrasının kontrolü 7.3.Üretici firmanın çalışmalarının takibi 8.1.Yazılımın test ve değerlendirmesi 8.2.Test esnasında kontrolün sürdürülmesi 8.3.Kabul sürecinin oluşturulması 9.1.Sözleşmedeki uygulamaların değerlendirilmesi 9.2.Kullanıcı memnuniyetinin değerlendirilmesi 9.3.Üretici firma performansının değerlendirilmesi 22

32 2.6 Yazılım Proje Yönetiminde Geliştirilen Kalite Standartları ve Olgunluk Modelleri Yazılım süreç olgunluğuna göre organizasyonların yapısı Yazılımın verimliliği ve kalitesini arttırmak için yürütülen çalışmalarda, yazılım sistemlerinde yaşanan sıkıntıların büyük ölçüde yazılım süreçlerinin yönetimindeki eksikliklerden kaynaklandığını ortaya çıkmıştır. Günümüzde yazılım organizasyonları yazılım projelerinde başarılı olabilmek için kurumsal yapılarına, politikalarına ve gelecekteki hedeflerine uygun olan yazılım proje yönetimi kalite standartlarını benimseyerek uygulamaktadırlar. Yazılım sürecinin amacı; belirlenen bir standarda göre faaliyetlerin yürütülmesi ve değişkenliğin azaltılmasıyla sağlanacak kurumsal iyileşme ile olgunluk seviyesini arttırmaktır. Paulk ve arkadaşları (1995) tarafından yayımlanan olgun ve olgun olmayan organizasyonların karşılaştırması çizelge 2.5 de verilmiştir. Disiplinli ve olgun yazılım süreçlerine geçilebilmesi için yazılım süreç olgunluk çerçevesinin oluşturulması gerekmektedir. Yazılım süreç olgunluk çerçevesi, yazılım süreci, yazılım süreç yeteneği, yazılım süreç performansı ve yazılım süreç olgunluğu kavramlarının bütünleşmesinden meydana gelmektedir (Paulk 1995, Tatlı 2007). Süreç yeteneği: Sürecin izlenerek, süreç çıktılarına ilişkin değer aralıklarının tahmin edilebilmesidir. Süreç performansı: Gerçekleşen sonuçları ifade etmektedir. Süreç olgunluğu: Sürecin yönetiminin, ölçümünün, kontrolünün ve tanımlanmasının yeterliliği değerlendirilmektedir. Süreç yeteneği ve süreç performansının geliştirilmesi, süreç olgunluğunun artmasını sağlayacaktır. Yazılım organizasyonlarının süreç olgunluğunun artması, yürütülecek faaliyetleri kişilerden bağımsız hale getirerek kurumsallaşmayı sağlayacaktır. 23

33 Çizelge 2.5 Olgun ve olgun olmayan organizasyonların özellikleri (Paulk 1995, Tatlı 2007) Süreç Tanımları Süreç Yönetim Ortamı Proje Hedefleri ve Süreç Takibi Maliyet/Temin/ Performans Kurumsallaşma Olgun Olmayan Organizasyonlar Çoğu zaman tanımlanmamış ve tanımlanmışlar ise düzgün uygulanmıyor. Doğaçlama Kriz Çözümü Takip için objektif temeller belirlenmiş değil. Diğer proje hedeflerine ulaşmak üzere kaliteden ödün veriliyor. Gerçekçi olmayan hedeflerden oluşmaktadır. Genellikle tahminlerden sapma olur. Süreç yönetimini destekleyen altyapı yoktur. Disipline süreçlerin faydasına inanılmamaktadır. Olgun Organizasyonlar Tanımlanmış, güncelleniyor ve gelişim planı bir şekilde uygulamaya konuluyor. Planlanmış faaliyetlere dayalıdır. Risk Yönetimi Takip için objektif temeller oluşturulmuş. Kalite, maliyet, temin hedefleri ve süreç sorunları sürekli izleniyor. Geçmiş tecrübelere dayalı gerçekçi hedeflerden oluşmaktadır. Genellikle beklenen sonuçlara ulaşılmaktadır. Süreçleri desteklemek için uygun alt yapı kuruludur. Disipline süreçleri destekleyen bir kurum kültürü oluşmuştur. Yazılım olgunluk modelleri, yazılımın üretimi ve işletme-idamesi için izlenecek süreçlerin kontrolünde ve iyileştirilmesi gereken süreçlerin belirlenmesinde kullanılarak organizasyonların olgunluk seviyelerini arttırmalarını sağlamaktadır. Bu bölümde sıra ile yazılım süreç modellerinin geliştirilmesinde yaygın olarak kullanılan Yazılım Yetenek Olgunluk Modeli (Capability Maturity Model-CMM), Tümleşik Yetenek Olgunluk Modeli (Capability Maturity Model Integrated-CMMI) ve bu modellerin tedarik sürecinde uygulanmaları konuları gözden geçirilecektir. 24

34 2.6.2 Yazılım yetenek olgunluk modeli (Capability Maturity Model-CMM) CMM ın gelişimi 1980 lerde Amerikan Savunma Bakanlığı nın (Department of Defense, DoD) yazılım projelerinde yaşanan sıkıntılara çözüm bulması için Carnegie Mellon Üniversitesi nden yardım istemesi üzerine, üniversitede kurulan Software Engineering Institute-SEI tarafından geliştirilen Yetenek Olgunluk Modeli (Capability Maturity Model-CMM), yazılım üreten kurumların süreçlerini iyileştirmelerine, yazılım tedariği yapan kurumların ise yüklenici firmaların seçiminde ve kalite düzeylerinin belirlenmesinde kullanılmaktadır. CMM in ana düşüncesi süreçler iyileştikçe, bu süreçler izlenerek üretilen ürünün kalitesinin artacağıdır. CMM, bir kurumun başlangıç seviyesinden iyileşen seviyeye geçilebilmesi için gerçekleştirilmesi gereken süreç iyileştirme faaliyetlerini kapsamaktadır(aydoğdu 2004) yılında SEI, üretici organizasyonların yazılım süreçlerinin olgunluklarını artırmak üzere bir olgunluk çerçevesi geliştirmeye başlamış ve Yazılım Süreçleri Olgunluk Çerçevesi 1987 yılında yayımlanmıştır. Yazılım Süreçleri Olgunluk Çerçevesi, 1991 yılında Yazılım için Yetenek Olgunluk Modeli, (Capability Maturity Model for Software) CMM sürüm 1.0 olarak geliştirilmiştir. Ayrıca SEI tarafından çeşitli CMM ler geliştirilmiştir (Tatlı 2007). Bu modeller; Software Capability Maturity Model-SW CMM (Yazılım Yetenek Olgunluk Modeli) Systems Engineering Capability Maturity Model-SE CMM (Sistem Mühendisliği Yetenek Olgunluk Modeli) Integrated Product Development Capability Maturity Model- IPD CMM (Entegre Ürün Geliştirme Yetenek Olgunluk Modeli) People Capability Maturity Model- P CMM (İnsan-Yetenek Olgunluk Modeli) Software Acquisition Capability Maturity Model- SA CMM (Yazılım Tedariki Yetenek Olgunluk Modeli ) 25

35 CMM in yapısı Yazılım geliştiren firmaların yaşadıkları deneyimlerden oluşturulan CMM, süreç iyileştirme için beş olgunluk seviyeli bir gelişim yöntemi sunmaktadır. 1 nci olgunluk düzeyi başlangıç, 5 nci olgunluk düzeyi ise en ileri duruma karşılık gelmektedir. Süreçler süreç verilerini esas alarak sürekli iyileştirilir Seviye 5 İyileşen Sürekli iyileştirme Süreç kontrolü Süreçler ölçümler esas alınarak anlaşılır Süreçler belgelendirilir ve tutarlı olarak uygulanır Geçmiş başarılar benzer kişiler ile tekrarlanır Tanımlı süreçler yok, araçlar entegre değil Seviye 2 Tekrarlanabilir Seviye 1 Başlangıç Seviye 4 Yönetilen Seviye 3 Tanımlı Proje yönetimi Tutarsız yönetim Kapasite yönetimi Süreç yönetimi Tanımlı süreçlerin getirdiği yeteneklerin kullanılması Süreç tanımı (kurumsal yaygınlaştırma) Temel yönetim kontrolü (proje/departman esaslı) Şekil 2.7 CMM yazılım süreç olgunluk seviyeleri (Demirörs 2007) CMM in olgunluk seviyelerinin birbirini tamamlayarak ve yukarı doğru ilerlediği şekil 2.7 den görülmektedir. Yani bir önceki basamakta yürütülen faaliyetlerin başarılı gerçekleştirilmeleri koşuluyla üst basamaktaki faaliyetler yerine getirilebilmektedir. Bir olgunluk seviyesinde yer alan anahtar süreç alanı, bir alttaki anahtar süreç alanının genişletilmiş ve yeni faaliyetler ilave edilmiş hali olabilmektedir. Şekil 2.8 de verilen CMM yapısında; Süreç yeteneğini tanımlayan Olgunluk Seviyeleri, Hedefleri belirleyen Anahtar Süreç Alanları, Gerçekleştirim ve kurumsallaşma için gerekli özelliklerden oluşan Ortak Özellikler, Temel etkinliklerden oluşan Anahtar Uygulamalar bulunmaktadır. 26

36 Olgunluk Seviyeleri Süreç Yeteneği GÖSTERİR İÇERİR Anahtar Süreç Alanları Hedefler ULAŞTIRIR Ortak Özellikler ORGANİZE Uygulamalar GÖSTERİR Alt Yapı veya Faaliyetler BELİRTİR Anahtar Uygulamalar Şekil 2.8 Yetenek olgunluk modeli yapısı (Tatlı 2007) Belirli bir olgunluk seviyesindeki kurumun sahip olması gereken temel yetenekler, kurumda anahtar süreç alanı olarak ifade edilen uygulamaların yerleşmesi ile sağlanmaktadır.olgunluk seviyelerine göre sağlanması gereken anahtar süreç alanları çizelge 2.6 da özetlenmiştir. 27

37 Çizelge 2.6 CMM seviyeleri ve anahtar süreç alanları (Sarıdoğan 2004) Düzeyler Anahtar Süreç Alanları Düzey Özellikleri (5)Eniyilenen (Optimizing) (4)Nicel Olarak Yönetilen (Quantitatively Managed) (3)Tanımlı (Defined) (2) Yönetilen (Managed) (1) Başlangıç (İnitial) Süreç Değişimi Yönetimi Teknoloji Değişimi Yönetimi Hata Önleme Yazılım Nitelik Yönetimi Nitelik Süreç Yönetimi Kurum Süreç Tanımı Kurum Süreç Odaklanması Gruplararası Eşgüdüm Yazılım Ürün Mühendisliği Tümleşik Yazılım Yönetimi Gözden Geçirme ve Değerlendirme Eğitim Programı İsterler Yönetimi Yazılım Proje Planlaması Yazılım Proje İzlemesi Yazılım Kalite Güvencesi Yazılım Konfigürasyon Yönetimi Alt yüklenici Yönetimi Kurumsallaşma gerçekleşmiştir. Kurum süreç iyileştirmeyi sürekli bir hedef haline getirmiştir. Süreç iyileştirme için özkaynaklar ayrılmaktadır. Geri beslemelerin sistematik bir şekilde değerlendirilmesine başlanmıştır. Tanımlı süreçler ölçülmekte ve başarım göstergeleri değerlendirilmektedir. Niceliksel veri toplulukları tanımlanmış, süreç ve ürün ölçütleri toplanmış, süreç iyileştirme çalışmasına geçilmiş ve. başarımı kestirmek mümkündür. Firma kültürü yazılı hale gelmiştir. Bir kurum kendine ait süreçlerle tanımlanır. Resmi yöntemler vardır ve tanımlanmış süreçler bütün projelerde izlenmektedir. Yazılı olmayan ve kısmen tutarlı süreçler vardır. Kalite Güvencesi ve Konfigürasyon Denetim Yöntemleri oturmuştur. Organizasyon aynı tipteki projeleri başarılı olarak tekrar edebildiği için bu düzeye tekrarlanabilirlik düzeyide denir. Buna karşın resmi süreç modeli eksiktir. Projenin başarısı yöneticilerin bireysel özendirme çalışmalarının sonucudur. Başarı sadece bireylere bağlıdır. Proje denetimi için resmi yöntemler bulunsa da bunların düzenli olarak kullanılmasını sağlayacak kurumsal bir yapı mevcut değildir. Organizasyon başarılı bir yazılım geliştirebilir, ancak yazılım öznitelikleri ve yazılım süreci kestirilemez.. Hehangi bir kriz anında işi bırakmak olasıdır. 28

38 CMM yapısına göre her bir olgunluk seviyesi birkaç anahtar sürece ayrılmıştır. Her anahtar süreç ortak özellik olarak adlandırılan beş bölümden oluşmaktadır. Ortak Özellikler anahtar uygulamaları belirtir ve bu uygulamalar anahtar süreçlerin hedeflerine ulaşmalarını sağlamaktadır. - Anahtar süreç alanında yer alan Ortak Özellikler : Başarım Kararlılığı (Taahhütler): Amaçlara ulaşılması için gerekli kurumsal alt yapılardan; kurumun yazılı bir politikasının olmasını, süreçlerini oluşturulup devam ettirilmesi için yapılması gerekenleri ve yönetimin bu politikaya bağlılığını içermektedir. Beceri (Yetenekler): Amaçlara ulaşılması için gerekli kurumsal alt yapılardan, yazılım süreç bileşenlerinin uygulanması için gerekli eğitim, insan ve kaynak alt yapısını içermektedir. Etkinlikler (Faaliyetler): Amaçlara ulaşılması için planlar, prosedürler, işin yapılışı, izlenmesi, sorumlulukların tanımlanması ve düzeltici faaliyetleri içermektedir. Ölçümler(Ölçüm-analiz): Gerçekleştirilen faaliyetlerin verimliliğini tespit edebilmek için gerekli ölçümlerin belirlenmesi, süreçlerin ölçülmesi ve sonuçların analiz edilmesini içermektedir. Doğrulamalar: Üst yönetim ve proje yöneticileri tarafından yapılan denetim ve gözden geçirmeler ile faaliyetlerin süreçte belirtildiği şekilde yapıldığı teyit edilmektedir. - Ortak Özelliklerin Anahtar Uygulamaları: CMM in toplam 18 Anahtar Süreç Alanı için 150 Anahtar Uygulaması mevcuttur. Kurumun seviyesi belirlenirken Anahtar Uygulama larda %80 üstü geçer, altı kalır şekilinde değerlendirilmektedir (Yücalar 2006). 29

39 CMM in avantajları CMM in yazılım geliştirme konusunda sağladığı faydaların yanısıra son zamanlarda büyük bütçeli ve yüksek katma değerli yazılım ihalelerinde CMM bir ön koşul olarak aranmaya başlanmıştır. Bu durum özellikle savunma sanayi alanında hizmet veren firmaların büyük askeri projelere ve devlet ihalelerine girebilmek için CMM Seviye-3 e ulaşmayı hedeflemesine sebep olmuştur. CMM in süreç iyileştirme sağladığı birkaç ülkedeki organizasyonun 400 den fazla projesinin sonuçlarının raporlandığı 19 çalışma Galin ve Avrahami tarafından (2006) seçilerek incelendiğinde; CMM in aşağıda belirtilen 7 (yedi) ortak yazılım geliştirme metriğinin performansını sürekli iyileştirdiği belirlenmiştir: -Hata yoğunluğu, -Yazılım geliştirme verimliliği, -Tekrarlanan iş oranı, -Tipik bir yazılım projesinin tamamlanmaması için zaman dönemi, -Takvim uygunluğu, -Hata belirleme etkinliği, -Yatırımın geri dönüşü, Söz konusu metriklerin ve CMM seviyelerinin ilerleyişine göre performans iyileştirmesi değerlendirildiğinde CMM programlarına yapılan yatırımın, yazılım geliştirme ve sürdürülmesinde iyileştirme sağladığı ortaya çıkmıştır (Galin ve Avrahami 2006). Çokuluslu bir İtalyan yazılım firmasının Ocak 1997 den Mayıs 2001 e kadar süreç iyileştirme çalışmaları kapsamında, CMM Seviye-1 den Seviye-3 e geçişteki niceliksel ve niteliksel veriler kullanılarak CMM in organizasyonel öğrenmeye etkisi araştırıldığında; - CMM Seviye-1 den CMM Seviye-2 ye geçişte 20 anahtar süreç alanınındaki hedefi sağlayan firmanın proje seviyesinde öğrenmenin organizasyonel seviyede 30

40 öğrenmeye oranı 20/4 iken; - CMM Seviye-2 den CMM Seviye-3 e geçişte 17 anahtar süreç alanınındaki hedefi sağlayan firmanın proje seviyesinde öğrenmenin organizasyonel seviyede öğrenmeye oranı 10/11 olduğu belirlenmiştir. Bu verilerden CMM Seviye-2 den CMM Seviye-3 e geçen bir firmanın organizasyonel öğrenmeye odaklandığı ve CMM in bir yazılım organizasyonu içindeki bilgi yönetimi ve öğrenmeyi etkili bir şekilde desteklediği görülmüştür. Bir organizasyonun CMM seviyesinin arttırması, projelerin tahmin edilebilirliğinin artmasını, risklerin azaltılarak iyi bir şekilde yönetilebilmesini ve organizasyonel öğrenmenin artmasını sağlayacaktır (Bellini ve Storto 2006) CMM in değerlendirme yöntemi Kurumlar, Carnegie Mellon Üniversitesi Yazılım Mühendisliği Enstitüsü (SEI) nin belirlediği denetçiler tarafından verilen CMM sertifikasına ön ve ara denetim olmak üzere iki aşamalı denetimden geçtikten sonra sahip olabilmektedir. Bu amaçla organizasyonlar ilk aşamada gerekli koşulları öğrenmekte daha sonra denetçiler denetime gelmeden önce gönderdikleri soru listesine verdikleri cevaplara göre olgunluk seviyesinin gerekli şartlarını sağladığı denetçi tarafından tespit edildiğinde Olgunluk Seviye Belgesi kuruma verilmekte ve belirli zamanlarda ara denetimler yapılmaktadır. CMM Seviye 1 den Seviye 2 ye ulaşmak ortalama olarak 24 ay, Seviye2 den Seviye 3 e 22 ay, Seviye 3 ten Seviye 4 e 32 ay ve Seviye 4 ten Seviye 5 e ulaşmak ise 16 ay sürmektedir. CMM değerlendirmesinin belirli dönemlerde tekrarlanması gerektiğinden, 2. veya 3. düzeyde olan bir kuruma her yıl içsel, iki yılda birde dışsal resmi denetim uygulanmaktadır (Yücalar 2006). 31

41 Yazılım tedarik süreci ve CMM (Software Acquisition Capability Maturity Model SA CMM) SEI tarafından sistem ve özellikle yazılım sistemlerinin tedarikindeki yönetim sorunlarına çözüm sağlamak için SA-CMM modeli geliştirilmiştir. Şekil 2.9 da gösterildiği gibi yazılımı geliştiren üretici firmanın tedarik sürecindeki faaliyetlerini SW-CMM, tedarik makamının bu süreçteki faaliyetlerini ise SA-CMM tanımlamaktadır. Tedarik Eden İhtiyaçlar Sonuçlar Üretici Firma SA-CMM SW-CMM Şekil 2.9 SA-CMM ve SW-CMM ilişkisi (Katar 2006) 5 ana aşamadan oluşan SA-CMM nin düzeylere göre sağlaması gereken Anahtar Süreç Alanları çizelge 2.7 de verilmiştir. Çizelge 2.7 SA-CMM nin düzeyleri ve anahtar süreç alanları (Bilgen 2005) Düzey Bakış Açısı Anahtar Süreç Alanı 5 Eniyileme Sürekli süreç iyileştirme -Satın alma yenilik yönetimi -Sürekli süreç iyileştirme 4 Niceliksel Niceliksel yönetim -Niceliksel satın alma yönetimi -Niceliksel süreç yönetimi 3 Tanımlı Standart süreçler -Eğitim programı -Satın alma risk yönetimi -Sözleşme başarım yönetimi -Proje başarım yönetimi -Kullanıcı isterleri -Süreç tanımı ve bakımı 2 Tekrarlanabilir Temel proje yönetimi -Destek dönemine geçiş -Değerlendirme -Sözleşme izleme -Proje yönetimi -İsterler geliştirme ve yönetimi -Teklif isteme -Yazılım satın alma planlama 1 Başlangıç Kişisel beceri, şans, kahramanlık 32

42 Yazılım sistemi geliştirmek için seçilecek firmanın, beklentileri karşılayacağına emin olabilmek için en az 2 nci olgunluk düzeyinde olması gerekmektedir. Bu amaçla bu tez kapsamında SA-CMM nin Seviye-2 için TSK bünyesinde gerçekleştirilmesi gereken anahtar süreç alanı faaliyetleri incelendikten sonra ulaşılması arzu edilen Seviye-3 için gerekli anahtar süreç alanı faaliyetlerine değinilecektir Tekrarlanabilir düzey (CMM Seviye-2) Temel proje yönetim faaliyetlerini gerçekleştirebilmek için gereken 7 anahtar süreç alanı ve bu anahtar süreç alanlarının ortak özelliklerinin anahtar uygulamaları aşağıda verilmiştir. 1.Tedarik Planlaması Hedefler: H1:Tedarik planlarının hazırlanması ve tedarik süreci boyunca güncel tutulması, H2:Tedarik planlamasının projenin ve ürünün tüm yaşam çevrimi boyunca geçerli olması, Başarım Kararlılığı: BK1:Tedarik planlaması için yazılı politikanın varlığı, BK2:Tedarik planlaması sorumlularının belirlenmiş olması, Beceri: B1:Tedarik planlaması ekibinin varlığı, B2:Tedarik planlaması için gerekli kaynağın ayrılmış olması, B3:Tedarik yönetimi konusunda tecrübeli personelin sağlanmış olması, Etkinlikler: E1:Yazılım tedarik planlamasından sorumlu personel sistem satın alma planlama faaliyetlerine de katılması, E2:Yazılım ve sistem tedarik planlamasının bağlantılı olarak gerçekleştirilmesi, E3: Projenin tedarik stratejisi geliştirilmesi ve belgelenmesi, E4: Tedarik planlama sürecinin tüm öğelerinin göz önüne alması (ör. Risk 33

43 belirleme ve izleme, proje yönetimi, teklif alımı, büyüklük kestirimleri, isterler, sözleşme yönetimi, değerlendirme, bakım ve destek, vb.) E5:Tedarik planı belgelenerek, proje süresince güncel tutulması, E6:Tedarik planında ürünün yaşam çevrimi desteğinin göz önüne alınması, E7:Ürünün yaşam çevrimi boyunca maliyet kestirimlerinin hazırlanması ve bağımsız kişilerce gözden geçirilmesi, Ölçümler: Ö1:Ölçümler yapılırak TP faaliyetlerinin ve sonucunda ortaya çıkan ürünün durumunun belirlenmesi için kullanılır. Doğrulama: D1:TP faaliyetleri tedarik kurumu üst yönetimi tarafından periyodik olarak gözden geçirilir. D2:TP faaliyetleri proje yöneticisi tarafından periyodik ve olay bazlı olarak gözden geçirilir. 2.Teklif İsteme (İhale Hazırlığı ve Sonuçlandırma) Hedefler: H1:Sözleşme gereklerini ve değerlendirme kriterlerini içeren bir ihale paketinin hazırlanması, H2:Tekliflerin hem teknik hem de idari yönden sözleşme gereklerini yerine getirebilme durumuna göre değerlendirilmesi, H3:Sözleşme gereklerini yerine getirebilecek olan yüklenicinin seçilmesi, Başarım Kararlılığı: BK1:Teklif isteme politikasının yazılı biçimde bulunması, BK2:Teklif isteme sorumlusunun belirlenmiş olması, BK3:Proje ekibinin sözleşme yönetimi deneyimine sahip kişileri de içermesi, Beceri: B1:Teklif alma işini yürüten bir grubun varlığı, B2:Gerekli kaynağın sağlanmış olması, 34

44 B3:Teklif alma sorumlularının deneyimli ya da gerekli eğitimleri almış olması, B4:Teklif alma sorumlularının, bu sürecin hedef ve yöntemlerine ilişkin olarak yönlendirilmiş olmaları, Etkinlikler: E1:Faaliyetlerin dokümante edilmiş plan ve yöntemlere göre yürütülmesi, E2:Teknik-idari, ürün ve teklif değerlendirme isterlerine ihale paketinde ve sözleşmede yer verilmesi, E3: Ürüne ilişkin maliyet ve takvim kestirimlerinin hazırlanması, E4: Maliyet ve takvim kestirimlerinin bağımsız kişilerce gözden geçirilmesi, E5: Tekliflerin yazılı planlar uyarınca değerlendirilmesi, E6: İhaleyi kazanacak teklif sahibinin teklif değerlendirmesi doğrultusunda belirlenmesi, E7:Proje ekibince sözleşme imzası öncesinde, yüklenici ile kullanıcı arasında sözleşme gereklerinin karşılıklı olarak doğru anlaşılmasının sağlanması, Ölçümler: Ö1:Ölçümler İhale hazırlığı ve sonuçlandırma faaliyetlerinin ve ürününün durumunun belirlenmesi için kullanılır. Doğrulama: D1:Üst yönetim periyodik gözden geçirmeleri, D2:Proje yöneticisi periyodik ve olay bazlı olarak gözden geçirmeleri. 3.Gereksinimler (İsterler) Geliştirme ve Yönetimi Hedefler: H1:Sözleşme isterlerinin geliştirilmesi, yönetimi ve güncel tutulması, H2:Kullanıcılar ve diğer ilgililerin proje süresince isterler konusunda girdi sağayabilmesi, H3:Sözleşme isterlerinin izlenebilir ve doğrulanabilir olması, H4:Sözleşme isterlerine ilişkin ana çizgilerin, teklif isteme paketinin dağıtılmasından önce tamamlanmış olması, 35

45 Başarım Kararlılığı: BK1: Sözleşme isterlerinin saptanmasına ve yönetimine yönelik yazılı bir politikanın varlığı, BK2: İsterler geliştirme ve yönetimi sorumlularının belirlenmiş olması, Beceri: B1:Sorumlu ekibin varlığı, B2:Yeterli kaynağın tahsis edilmiş olması, B3:Sorumlu kişilerin yeterince deneyimli olması ya da gerekli eğitimleri almış olması, Etkinlikler: E1:Faaliyetlerin dokümante edilmiş isterlerin gelişimi ve yönetimi plan ve prosedürlerine göre yürütülmesi, E2:Proje ekibinin sözleşme isterlerini geliştirmesi, bunlara ilişkin başlangıç noktalarının belirlemesi, isterleri güncel tutması ve teklif isteme paketinin dağıtılması öncesinden başlayarak değişimi denetim altında bulundurması, E3:Sözleşme isterlerinde değişikliklerin tedarik edilecek ürüne etkilerine göre incelenmesi, E4: Tüm değişikliklere, performansa, mimariye, desteklenebilirliğe, sistem kaynaklarından faydalanmaya, değerlendirme gereklerine ve maliyet etkilerine göre bir değer verilmesi, E5:Sözleşme isterleriyle sunulan ürünler arasındaki uyumluluğun proje süresince denetlenmesi, E6:Sözleşme isterlerinin geliştirme ve güncel tutulmalarında tüm ilgililerin katkıda bulunmaları, Ölçümler: Ö1:Ölçümler Gereksinimlerin Gelişimi ve Yönetimi faaliyetleri ürününün durumunun belirlenmesi için kullanılır. Doğrulama: D1:Üst yönetim periyodik gözden geçirmeleri, D2:Proje yöneticisinin periyodik ve olay bazlı olarak gözden geçirmeleri. 36

46 4.Proje Yönetimi Hedefler: H1: Proje yönetimi etkinliklerinin planlı, örgütlü, denetimli ve açık biçimde gerçekleştirilmesi, H2: Projenin performansının, maliyetinin ve takviminin tedarik süresince düzenli olarak izlenmesi, hedeflerle karşılaştırılması ve kontrolün sağlanması, H3: Tedarik süresince oluşan sorunların yönetilmesi ve denetlenmesi, Başarım Kararlılığı: BK1: Projenin gerçekleştirilmesine ilişkin yazılı bir politikanın varlığı, BK2: Proje yönetimi sorumluluğunun tanımlanmış olması, Beceri: B1: Tedarik yönetimi ekibinin varlığı, B2: Tedarik projesi süresince gerekli kaynağın sağlanmış olması, B3: Proje ekibinin yeterli birikime sahip ya da eğitim almış olması, Etkinlikler: E1: Proje ekibinin dokümante edilmiş proje yönetimi planı ve yöntemine göre çalışması, E2: Proje fonksiyonlarına ilişkin roller, yetki ve sorumlulukların belgeli, güncel ve ilgililerin bilgisine açık tutulması, E3:Yükümlülüklerin ve bunlardaki değişikliklerin ilgililere bildirilmesi, E4: Maliyet, takvim, kaynaklar ve teknik yönlere ilişkin risklerin izlenmesi, E5: Proje konularının, parasal kaynakların ve harcamaların planlarla karşılaştırılması ve bunlara ilişkin gerekli işlemlerin gerçekleştirilmesi, E6: Satın alma sürecinde saptanan sorunların kaydedilmesi, izlenmesi ve çözümüne yönelik önlemlerin gerçekleştirilmesi, E7: Proje süresince planların güncel tutulması, Ölçümler: Ö1: Ölçümler Proje Yönetim faaliyetlerinin ve ürününün durumunun belirlenmesi için kullanılır. 37

47 Doğrulama: D1: Üst yönetim periyodik gözden geçirmeleri, D2: Proje yöneticisi periyodik ve olay bazlı olarak gözden geçirmeleri. 5. Sözleşme İzleme ve Yönlendirme Hedefler: H1: Proje ekibinin yüklenicinin yürüttüğü faaliyetleri sözleşme isterlerine uygun olarak yerine getirdiğine ve yönettiğine dair yeterli bir denetime sahip olması, H2:Proje ekibiyle yüklenici arasında sürekli iletişim kurulması ve yükümlülüklerin karşılıklı olarak kabul edilerek yerine getirilmesi, H3: Sözleşme süresince sözleşmedeki tüm değişikliklerin yönetilmesi, Başarım Kararlılığı: BK1: Kurumun bu konuya ilişkin yazılı bir politikaya sahip olması, BK2: Bu alandaki sorumluluğun belirlenmiş olması, BK3: Proje ekibinin sözleşme yönetiminde deneyim sahibi kişileri içermesi, Beceri: B1: Sorumlu ekibin gerekli deneyime sahip, gerekli eğitimi alan kişileri içeren biçimde kurulmuş ve yeterli kaynaklarla donatılmış olması, Etkinlikler: E1: Faaliyetlerin belgelenmiş sözleşme izleme ve yönetimi planları kapsamında yürütülmesi, E2: Proje ekibi sözleşmenin izlenmesi ve yüklenici faaliyetlerini değerlendirirken gerekli gördüğü yüklenici planlarını belirli zamanlarda incelemesi, E3: Proje ekibinin düzenli gözden geçirmeler yapması ve bunları yüklenici ile paylaşması, E4: Yüklenicinin gerçekleşen bütçe ve takviminin planlananlarla karşılaştırılarak uyumsuzlukların tespit edilmesi, E5:Yüklenicinin ürüne ilişkin teknik etkinliklerinin izlenmesi, planlarla karşılaştırılması ve uyumsuzlukların tespit edilmesi, E6: Yüklenicinin ürüne ilişkin ömür boyu destek mekanizmasının kurulmasını sağlamak üzere yazılım mühendislik çerçevesinin gözden geçirilmesi, izlenmesi 38

48 ve sorunların saptanması, E7: Sözleşme izleme ve yönetimi sırasında belirlenen tüm sorunların proje ekibinin ya da yüklenicinin yönetim sistemine kaydedilerek çözüm sağlanana kadar izlenmesi, Ölçümler: Ö1: Ölçümler sözleşme izleme faaliyetlerinin ve ürününün durumunun belirlenmesi için kullanılır. Doğrulama: D1: Üst yönetimin periyodik gözden geçirmeleri, D2: Proje yöneticisi periyodik ve olay bazlı olarak gözden geçirmeleri. 6. Değerlendirme Hedefler: H1: Değerlendirme isterlerinin, sözleşme isterleriyle birlikte geliştirilmesi ve tedarik süresince güncel tutulması, H2: Değerlendirmelerin tedarik süresince planlı biçimde gerçekleştirilmesi, H3: Değerlendirmelerin ürün kabülünü sağlayacak şekilde, nesnel bir temel oluşturması, Başarım Kararlılığı: BK1: Tedarik süresince değerlendirmelerin yönetimi konusunda yazılı bir politikanın varlığı, BK2: Sorumlulukların belirlenmiş olması, Beceri: B1: Birikim sahibi ve eğitimli kişilerden oluşan bir değerlendirme ekibinin kurulmuş ve yeterli kaynaklarla donatılmış olması, Etkinlikler: E1: Etkinliklerin yazılı plan ve yöntemler uyarınca yapılması, E2: Sözleşme isterleri ile birlikte proje değerlendirme isterlerinin hazırlanması, E3: Değerlendirme etkinliklerinin elden geldiğince, yüklenicinin değerlendirme çalışmalarını yinelemekten kaçınıp onlardan da yararlanacak biçimde planlanması, E4: Değerlendirmelerin gelişen ürünler üzerinde planlı bir şekilde yapılması, 39

49 E5: Değerlendirme sonuçlarının kabul kararlarını desteklemek üzere analiz edilmesi ve sözleşme isterleriyle karşılaştırılması, Ölçümler: Ö1: Ölçümler değerlendirme faaliyetlerinin ve ürününün durumunun belirlenmesi için kullanılması, Doğrulama: D1: Üst yönetim periyodik gözden geçirmeleri, D2: Proje yöneticisi periyodik ve olay bazlı olarak gözden geçirmeleri. 7. Destek Dönemine Geçiş Hedefler: H1: Proje ekibinin, destek örgütünün destek sorumluluğunu üstlendiği zaman yeterli hizmet sağlayabilmesi için gerekli önlemleri alması, H2: Destek sorumluluğunun, yükleniciden destek örgütüne geçişi sırasında herhangi bir aksaklığın yaşanmaması, H3: Geçiş süresince ürünlerin konfigürasyon yönetiminin devam ettirilmesi, Başarım Kararlılığı: BK1: Destek dönemine geçişe ilişkin yazılı politikanın varlığı, BK2: Destek dönemine geçiş planlamasına destek ekibinin katılımı için gerekli tedbirlerin sağlanması, BK3: Destek dönemine geçiş sorumluluğunun belirlenmiş olması, Beceri: B1: Deneyimli ve eğitimli kişilerden oluşan, yeterli kaynaklarla donatılmış sorumlu bir ekibin varlığı, B2: Ürünlere bakım ve destek sağlayacak örgütün proje planlamasının erken aşamalarında belirlenmiş olması ve yaşam çevrimine ilişkin desteklenebilirlik konularının proje isterleri arasında yer alması, B3: Destek örgütünün, geçiş öncesinde, bütün ürünlere ilişkin destek için gerekli envantere (ör.belgeler, destek yazılımı, konfigürasyon yönetim sistemleri) sahip olması, B4: Destek dönemine geçişle ilgili tüm kuruluşların bu dönemin gereklerine 40

50 ilişkin bilgilendirilmesi, Etkinlikler: E1: Tüm faaliyetlerin dokümante edilmiş Desteğe Geçiş plan ve prosedürleri kapsamında yapılması, E2: Ürün sorumluluklarının ancak destek organizasyonunun bakım ve desteği gereğince yapabileceği görüldükten sonra devredilmesi, E3: Proje ekibinin, geçiş dönemi süresince destek hizmetlerini aksamadan yürütülmesini sağlaması, E4: Proje ekibinin, geçiş süresince ürünlere ilişkin konfigürasyon yönetiminin yürütülmesini denetlemesi, Ölçümler: Ö1: Ölçümler Desteğe Geçiş faaliyetlerinin ve ürününün durumunun belirlenmesi için kullanılır. Doğrulama: D1: Üst yönetim periyodik gözden geçirmeleri, D2: Proje yöneticisi periyodik ve olay bazlı olarak gözden geçirmeleri Tanımlı düzey (CMM Seviye-3) Tanımlı (standart) seviyenin sağlanabilmesi için gerçekleştirilmesi gereken 6 anahtar süreç alanı ve bu anahtar süreç alanlarının ortak özelliklerinin anahtar uygulamaları aşağıda verilmiştir. 1. Süreç Tanımlama ve İdame Hedefler: H1: Kurumun standart tedarik sürecinin tanımlanması, yönetimi ve denetimi, H2: Süreç tanımlama ve güncelleme etkinliklerinin kurum içinde koordine edilmesi, H3: Standart tedarik sürecinin projelerde uygulanmasıyla ilgili bilgilerin toplanması, analiz edilmiş ve erişilebilir olması, 41

51 Başarım Kararlılığı: BK1: Süreç tanımlama ve güncelleme için yazılı politikanın varlığı, BK2: Kurumun bu konuda destek vermesi, BK3: Sorumluluğun belirlenmiş olması, Beceri: B1: Tecrübeli ve eğitim sahibi kişilerden oluşan, yeterli kaynaklarla donatılmış bir ekibin olması, Etkinlikler: E1: Etkinliklerin yazılı süreç tanımlama ve güncelleme planları uyarınca yapılması, E2: Tedarik kurumunun standart tedarik sürecinin; (a) Kendi tanımlama ve güncelleme planları uyarınca tanımlanması ve güncellenmesi, (b) Düzenli olarak gözden geçirilip belirlenen sorunlara ilişkin çözümlerin bulunması, E3: Satın alma süreci tanımlama ve güncellenmesinin kurum içinde koordineli ve belgelenerek yapılması, E4: Kurumun standart tedarik sürecinin projelerde uygulanma ilke ve ölçütlerinin geliştirilmesi, güncellenmesi ve proje ekiplerinin konuya ilişkin bilgilendirilmeleri, Ölçümler: Ö1: Ölçümler yapılırak TP faaliyetlerinin ve sonucunda ortaya çıkan ürünün durumunun belirlenmesi için kullanılır. Doğrulama: D1: TP faaliyetleri tedarik kurumu üst yönetimi tarafından periyodik olarak gözden geçirilir. D2: TP faaliyetleri proje yöneticisi tarafından periyodik ve olay bazlı olarak gözden geçirilir. 42

52 2. Kullanıcı İsterleri Hedefler: H1: Son kullanıcı isterlerinin belirlenmesi, belgelenmesi ve onaylanması işlerinin son kullanıcıların kendileri tarafından yapılması, H2: Son kullanıcı isterlerinin satınalma isterleri arasında yer alması, H3:Son kullanıcı isterlerindeki değişikliklerin uygun biçimde gereğinin yapılması, Başarım Kararlılığı: BK1:Tedarik kurumunun kullanıcı isterleri etkinliklerini gerçekleştirmek için yazılı politikasının olması, BK2:Kullanıcı isterlerinin tespit edilmesi ve belgelenmesi sorumluluğunun belirlenmiş olması, Beceri: B1:Tecrübeli ve eğitimli kişilerden oluşan, gerekli kaynaklarla donatılmış bir ekibin olması, Etkinlikler: E1:Proje ekibinin kullanıcı isterlerine ilişkin faaliyetlerini yazılı kullanıcı isterleri planına göre gerçekleştirmesi, E2:Son kullanıcıların isterlerinin ve değerlendirme ölçütlerinin tespit edilmesi, E3:Son kullanıcı isterlerinin çözümlenmesi ve sonuçların dokümante edilmesi, E4:Satın alma isterlerinin son kullanıcı isterleriyle uyumlu olduğunun son kullanıcılarca onaylanması, E5:Son kullanıcı isterlerinin projenin tedarik isterleri geliştirme ve güncelleme çalışmalarına girdi oluşturması, E6:Son kullanıcıların, isterlerinin durumu konusunda düzenli olarak bilgilendirilmesi, Ölçümler: Ö1:Ölçümler ihale hazırlığı ve sonuçlandırma faaliyetleri ve ürününün durumunun belirlenmesi için kullanılır. Doğrulama: D1:Üst yönetim periyodik gözden geçirmeleri 43

53 D2:Proje yöneticisi periyodik ve olay bazlı olarak gözden geçirmeleri. 3.Proje Performans Yönetimi Hedefler: H1:Projenin, tedarik kurumunun standart tedarik sürecinden uyarlanmış tanımlı bir tedarik sürecince yönetilmesi, H2:Proje ekibinin satınalma hedeflerine ulaşması, Başarım Kararlılığı: BK1:Projenin tedarik etkinliklerinin planlanması ve yönetimi için yazılı politikanın olması, Beceri: B1:Tedarik projesi etkinliklerini yürütmekten sorumlu kişilerin tecrübeli ve eğitimli olmaları, Etkinlikler: E1:Tedarik kurumunun standart süreçlerinin, tanımlı uyarlama ilkeleri doğrultusunda uyarlanarak projenin tanımlı satınalma sürecinin geliştirilmesi ve belgelenmesi (Süreç Tanımlama ve Güncelleme ASA sıyla ortak) E2:Tedarik kurumunun standart tedarik süreci uyarınca proje yönetimi planının geliştirilmesi ve güncellenmesi (Planlama, Proje Yönetimi ve Sözleşme İzleme ASA ile ortak) E3:Proje ekibinin satınalma yönetimi etkinliklerinin projenin tanımlı tedarik sürecine ve proje yönetim planına uygun olarak gerçekleştirilmesi, E4:Bir önceki etkinlikte değinilen sürecin geçerli proje hedefleri doğrultusunda gözden geçirilmesi, E5:Proje ekibinin, etkinliklerini, projeyi destekleyen diğer birimler ve etkinliklerle eşgüdümlü olarak yürütmesi, E6:Tedarik kurumunun tedarik süreciyle ilgili birikiminden proje planlama, büyüklük kestirimi ve yönetimi etkinliklerinde yararlanılması,(proje Tanımlama ve Yönetimi ASA ile ortak) E7:Tedarik kurumu ile ilgili gruplar arasındaki kritik bağımlılıkların belirlenmesi, üzerinde görüşmeler yapılması ve yönetilmesi, 44

54 E8:Proje ekibince, son kullanıcıların bugünkü ve gelecekteki isterlerinin karşılanmasını sağlamak üzere düzenli gözden geçirmeler yapılması, E9:Proje ekibinin başarımını saptamak üzere ölçümlerin yapılması ve eğilimlerin çözümlenmesi (ör. Harcanan iş gücü, plan değişikliklerinin sıklığı, isterler değişiklikleri, sözleşme değişiklikleri gibi) Proje ekibince risklerin ve giderilme etkinliklerinin belirlenmesi (Yazılım Satınalma Planlama, Sözleşme Başarım Yönetimi ve Satınalma Risk Yönetimi ASA larıyla ortak) E10:Proje ekibinin tedarik sürecine ilişkin birikimi, elde ettiği sonuçlar ve çıkardığı derslerin belirlenmesi, belgelenmesi ve satınalma örgütünün süreç envanterine eklenmesi, Ölçümler: Ö1:Ölçümler Gereksinimlerin Gelişimi ve Yönetimi faaliyetlerinin ve ürününün durumunun belirlenmesi için kullanılır. Doğrulama: D1:Üst yönetim periyodik gözden geçirmeleri, D2:Proje yöneticisi periyodik ve olay bazlı olarak gözden geçirmeleri. 4. Sözleşme Performans Yönetimi Hedefler: H1:Sözleşme süresince yüklenicinin süreç, başarım ve ürün niteliğinin risklerinin mümkün olduğunca erken belirlenmesi ve giderilmesi amacıyla denetlenmesi, H2:Son kullanıcılar, proje ekibi ve yüklenici arasında işbirliğine dayalı üretken bir ortamın oluşturulması, Başarım Kararlılığı: BK1:Sözleşme başarım yönetimi etkinlikleri için yazılı politikanın varlığı, Beceri: B1:Sözleşme başarım yönetimini gerçekleştiren kişilerin yeterli deneyim, eğitim ve kaynağa sahip olmaları, Etkinlikler: E1: Sözleşme başarım yönetimi planlarının yazılı olarak hazırlanması ve kullanılması, 45

55 E2:Yüklenicinin (Satıcı ekibin) mühendislik süreçlerinin ve çıktılarının düzenli olarak incelenerek eğilimlerin çözümlenmesi, E3:Satıcı ekibin başarım değerlendirmesinde bu çözümlemelerden yararlanılması, E4:Satıcının süreç ve ürünlerinin iyice anlaşılmasına dayalı olarak satınalma sürecinde değişikliklerin önerilebilmesi, E5:Son kullanıcıların, işletim isterlerinin karşılanma düzeyini saptamak üzere, gelişen ürünlerin değerlendirmesine düzenli olarak katılması, E6:Son kullanıcılar, proje ekibi ve satıcı ekibi arasında işbirliğine dayalı üretken bir ortamın oluşturulması, Ölçümler: Ö1:Ölçümler Proje Yönetim faaliyetlerinin ve ürününün durumunun belirlenmesi için kullanılır. Doğrulama: D1:Üst yönetim periyodik gözden geçirmeleri, D2:Proje yöneticisi periyodik ve olay bazlı olarak gözden geçirmeleri. 5. Tedarik Risk Yönetimi Hedefler: H1:Risk belirleme ve giderme çalışmalarına proje çapında katılımın özendirilmesi, H2:Proje ekibinin tanımlı satınalma sürecinin tüm proje işlevleri için risk saptama, çözümleme ve giderme olanağı sağlaması, H3:Proje gözden geçirmelerinin saptanmış risklere ilişkin durumu da içermesi, Başarım Kararlılığı: BK1:Satın alma risk yönetimi için yazılı politikanın varlığı, BK2:Sorumluluğun belirlenmiş olması, Beceri: B1:Deneyimli ve eğitimli kişilerden oluşan bir ekibin yeterli kaynaklarla donatılmış olması, 46

56 Etkinlikler: E1:Etkinliklerin tedarik (satın alma)planıyla bütünleştirilmesi, E2:Projenin tanımlı satınalma süreciyle uyumlu olarak Satınalma Risk Yönetimi Planı nın geliştirilmesi (Süreç Tanımlama ve Güncelleştirme ASA ile birlikte), E3:Proje ekibinin yazılı planlara göre çalışması, E4:Risk saptama ve gidermede geniş katılımın özendirilmesi, E5:Risk yönetiminin teklif isteme, kullanıcı isterleri, proje başarım yönetimi ve sözleşme başarım yönetimi süreçleriyle bütünleşik olarak yürütülmesi (ilgili ASA larla birlikte), E6:Satın alma risklerinin çözümlenmesi, izlenmesi ve çözülene ya da giderilene kadar denetim altında tutulması, E7:Proje gözden geçirmelerinde belirlenen risklerin durumunun da göz önüne alınması, Ölçümler: Ö1:Ölçümler Sözleşme İzleme faaliyetlerinin ve ürününün durumunun belirlenmesi için kullanılır. Doğrulama: D1:Üst yönetimin periyodik gözden geçirmeleri, D2:Proje yöneticisi periyodik ve olay bazlı olarak gözden geçirmeleri. 6. Eğitim Programı Yönetimi Hedefler: H1:Projelerin satın alma hedeflerine ulaşmaları için gereken eğitimin belirlenmesi ve sağlanması, H2:Eğitim programının tedarik kurumunun standart tedarik süreci konusunu içeren eğitim gereksinimlerini karşılaması, Başarım Kararlılığı: BK1:Yazılı bir politikanın varlığı, BK2:Sorumlulukların belirlenmiş olması, 47

57 Beceri: B1:Eğitimli, birikim sahibi kişilerden oluşan ve yeterli kaynakla donatılmış bir ekibin varlığı, Etkinlikler: E1:Satınalma örgütünün eğitim isterlerini destekleyecek eğitim programının planlanması, geliştirilmesi, gerçekleştirilmesi ve güncel tutulması, E2:Her satın alma projesinin kendi eğitim gereklerini, hem satınalma süreciyle hem de alınan hizmet ve ürünlerle ilgili ( kullanıcı eğitimi ) olarak belirlemesi ve eğitim programı süreçlerine uygun bir eğitim planı hazırlaması, E3:Eğitim programı uyarınca satınalma eğitiminin verilmesi, E4:Belirlenen satın alma görevlerini yerine getirmeleri için gereken eğitime ya da birikime sahip kişilerin eğitim programını atlamaları için tanımlı ve uygulanan bir sürecin bulunması, E5:Eğitim kayıtlarının tutulması, E6:Eğitim programının niteliğini denetlemek için gerekli ölçümlerin yapılması, Ölçümler: Ö1:Ölçümler değerlendirme faaliyetlerinin ve ürününün durumunun belirlenmesi için kullanılması, Doğrulama: D1:Üst yönetim periyodik gözden geçirmeleri, D2:Proje yöneticisi periyodik ve olay bazlı olarak gözden geçirmeleri. 48

58 2.6.3 CMMI ( Capability Maturity Model Integrated-Tümleşik Yetenek Olgunluk Modeli) CMMI in gelişimi ABD Savunma Bakanlığı yazılım geliştirme yeteneğinin değerlendirme Toplam kalite yönetimi yaklaşımı çalışmaları (Crosby Maturity Grid) Yazılım sektörünün deneyimleri CMM V1.0 Software Engineering Institute (SEI) CMM V1.1 SW-CMM SE-CMM 1991 den başlayarak farklı alanlarda geliştirilen CMM modellerinin bir kurumda birlikte kullanılmasının kullanıcıları karmaşıklığa sürüklediği, yüksek maliyetlere, tutarsızlıklara ve iletişim sıkıntılarına yol açtığı tespit edilmiştir. Bu sorunları çözebilmek için 1997 yılında DoD un desteği ile SEI tarafından başlatılan CMM Tümleştirme projesi çalışmaları kapsamında, Yazılım Yetenek Olgunluk Modeli (SW- CMM), Sistem Mühendisliği Yetenek Olgunluk Modeli (SE-CMM), Tümleşik Ürün ve Süreç Geliştirme Yetenek Olgunluk Modeli (IPPD-CMM) birleştirilip, organizasyon genelinde süreçlerin olgunlaştırılması için tek bir gelişim çatısı altında kullanılabilecek CMMI geliştirilmiştir. CMMI in tarihsel gelişimi şekil 2.10 da özetlenmiştir. IPPD- CMM Uygulama deneyimleri Standartlardaki gelişmeler 2000 CMMI V Software Acqusioin CMMI V CMMI V CMMI for Development V CMMI for Acqusioin V1.2 Şekil 2.10 CMMI modelinin tarihsel gelişimi CMM e göre süreç iyileştirme çalışması başlatan bir organizasyon hedeflerine ulaşana kadar aynı CMM modelini uyguladıktan sonra, ulaşmak istediği CMMI olgunluk/yeterlilik seviyesini inceleyerek, kendi amaçlarına uygun olarak eksikliklerini belirleyip, yerine getirmesi gerekmektedir. Eğer bir şirket CMM Seviye 2 ya da daha 49

59 yüksek bir olgunluk düzeyinde ise kendi süreçleri ile CMMI Seviye 2 den itibaren süreçler arasında çizelge 2.8 de verildiği gibi bir eşleştirme (mapping) yapılarak aradaki farkların giderilmesi uygun olmaktadır.( ) Çizelge 2.8 SW- CMM ve CMMI in Seviye 2 ve Seviye-3 için örnek eşleşmesi SW-CMM Seviye 2 (Version 1.1) Anahtar Süreç Alanları CMMI Seviye 2 (Version 1.1) Süreç Alanları SW Gereksinmlerin Yönetimi Gereksinmlerin Yönetimi SW Proje Planlama Proje Planlama SW Proje İzleme ve Gözden Geçirme Proje İzleme ve Takip SW Subcontract Management Tedarikçi Sözleşme Yönetimi -- Ölçme ve Çözüleme SW Kalite Güvence Süreç ve Ürün Kalite Güvence SW KonfigürasyonYönetimi KonfigürasyonYönetimi SW-CMM Seviye 3 (Version 1.1) Anahtar Süreç Alanları CMMI Seviye 3 (Version 1.1) Süreç Alanları -- Gereksinim Geliştirme SW Ürün Mühendisliği Teknik Çözüm Ürün Bütünleştirme Eş incelemeler Doğrulama Geçerlilik Kurumsal Süreç Odaklanması Kurumsal Süreç Odaklanması Kurumsal Süreç Tanımlanması Kurumsal Süreç Tanımlanması Eğitim Programı Kurumsal Eğitim Bütünleşik SW Yönetimi Bütünleşik Proje Yönetimi Risk Yönetimi Grup içinde (Paydaşlar arasında) Koordinasyon Bütünleşik Eğitim Karar Çözümleme ve Çözüm Üretme CMMI modeli; yazılım sistemleri tedarik eden kurumların yüklenici olarak seçecekleri firmaların yeterliliğine karar verirken ve organizasyonların durumlarının üst makam tarafından değerlendirilmesi için kullanılmaktadır. Bir organizasyonun süreçlerinde nelerin olması gerektiğini denetleyen CMMI modeli belirlenen eksikliklerin nasıl giderileceğini kuruma bırakmaktadır. İlk olarak 2001 yılında yayımlanan CMMI modelinin 2006 yılında son sürümü CMMI v1.2 yayımlanmıştır. CMMI v1.3 ün 2010 Kasım ayında yayımlanması beklenmektedir tarihli CMMI v1.2 sonrasında bu kapsamda CMMI-DEV, CMMI-SVC ve CMMI-ACQ üç yeni olgunluk çerçevesi geliştirilmiştir: (Kalaycı 2007) 50

60 CMMI-DEV: Bir projenin sonunda yeni bir ürün ya da hizmet geliştiren kurumlar tarafından kullanılabilir. CMMI-SVC: Geliştirilmesi tamamlanarak kullanıcıya teslim edilmiş bir ürün yada hizmetin işletme, bakım ve idamesi ile ilgili faaliyetlerin yürütülmesinde kullanılabilir. CMMI-ACQ: Tedarik yapan kurumların tedarik süreçlerinin olgunluğunun ölçülmesi ve iyileştirilmesini sağlamak için kullanılabilir CMMI in yapısı CMMI nın yapısı şekil 2.11 de görülmektedir. CMMI modelinin temelini süreç alanları oluşturur. CMMI süreç alanlarının tanımları, aşağıdaki bileşenleri kapsar: Süreç alanı adı Amaç Tanıtıcı notlar İlişkili süreç alanları Özel hedefler Özel pratikler Tipik iş ürünleri Alt pratikler Genel hedefler Genel pratikler Genel pratik detaylar 51

61 Süreç Alanı Amaç Durumu Tanıtım Notları İlgili Süreç Alanları Özel Amaçlar Özel Amaçlar Özel Uygulamalar Genel Uygulamalar İş Ürünleri Alt Uygulamalar Alt Uygulamalar Genel Uygulama Olgunlaşmaları Gerekli Bileşen Beklenen Bileşen Bilgilendirici Bileşen Şekil 2.11 CMMI ın yapısı (Yücalar 2006) CMMI in süreç alanı bileşenleri; Gerekli Bileşen, Beklenen Bileşen ve Açıklamalar (Bilgilendirici Bileşen) olmak üzere üç temel bileşenden oluşmaktadır. - Gerekli Bileşenler (GB): Organizasyonun süreç geliştirme için kesinlikle karşılaması gereken genel ve özel amaçlardan oluşmaktadır. CMMI denetimlerinde organizasyon veya sürecin özel ve genel amaçları yerine getirmesine göre kurumun olgunluk seviyesi veya sürecin yetkinlik seviyesine karar verilmektedir. Gerekli bileşenler kurumlar tarafından farklı yorumlanmaksızın, CMMI modelinde belirtildiği şekilde sağlanması gerekmektedir. - Beklenen Bileşenler (BB): Organizasyonun gerekli bileşenlere ulaşabilmesi için değerlendiriciler ve iyileştiricilerin rehber olarak kullandığı, yapılması gerekenleri belirten genel ve özel uygulamalardan oluşmaktadır. - Açıklamalar (A): Organizasyonların gerekli ve beklenen bileşenleri anlamasına yardımcı olmak için kullanılmaktadır. 52

62 CMMI in gösterim biçimleri CMMI gösterimi için sürekli ve basamaklı olarak iki seçenek önerilmiştir. Sürekli CMMI gösterimi bir kurumun her bir süreç alanında süreç iyileştirmede gösterdiği başarı için uygulanan yetenek düzeylerini tanımlarken, basamaklı CMMI gösterimi ise kurumun tamamının olgunluk seviyesi için uygulanır. Her olgunluk seviyesi için tanımlanmış süreç alanları vardır. Basamaklı model Çizelge 2.9 da görüleceği üzere beş olgunluk seviyesi ve bu olgunluk seviyelerine ulaşılabilmesi için sağlanması gereken süreç alanlarından oluşmaktadır. Çizelge 2.9 CMMI Basamaklı modelinin olgunluk seviyeleri ve süreç alanları Olgunluk Seviyesi 1. Olgunluk Seviyesi Başlangıç 2. Olgunluk Seviyesi-Yönetilen 3. Olgunluk Seviyesi-Tanımlı 4. Olgunluk Seviyesi-Sayılarla Yönetilen 5. Olgunluk Seviyesi-Sürekli İyileşen İlgili Süreç Alanları Bütün şirketler en az 1. olgunluk seviyesindedir. Gereksinim Yönetimi Proje Planlama Proje İzleme ve Kontrol Yüklenici Sözleşme Yönetimi Konfigürasyon Yönetimi Ölçme ve Çözümleme Süreç ve Ürün Kalite Güvencesi Gereksinim Geliştirme Teknik Çözüm Ürün Bütünleştirme Doğrulama Geçerlilik Kurumsal Süreç Odaklaması Kurumsal Süreç Tanımlama Kurumsal Eğitim Bütünleşik Proje Yönetimi Risk Yönetimi Karar Çözümleme ve Çözüm Üretme Kurumsal Süreç Başarımı Sayısal Proje Yönetimi Kurumsal Yenilikçilik ve Yaygınlaştırma Sebep Çözümlemesi ve Çözüm Üretme 53

63 Organizasyonların olgunluk seviyelerine göre belirtilen süreç alanları ile ilgili genel ve özel hedeflerin yerine getirilmesi ile kurumsal olarak o olgunluk seviyesine ulaşılmaktadır. Bütün kurumlar var oluşları ile en azından birinci olgunluk seviyesine karşılık gelmekte ve her zaman bir üst seviyeye ulaşmayı hedeflemektedirler. 1. Olgunluk Seviyesi nin (Başlangıç) Özellikleri: Kurumda kanıtlanmış süreçler olmadığından faaliyetler kişilere göre farklı şekilde yapılmakta, ürünler belirlenen süre ve bütçe ile tamamlanamamaktadır. Sıkıntılı dönemlerde süreçler atlanabildiğinden, başarılı sonuçlara ulaşılması çoğunlukla kurumdaki kişilere bağlıdır. 2. Olgunluk Seviyesi nin (Yönetilen) Özellikleri: Organizasyonların süreçleri planlanmış, uygulanmış, ölçülmüş ve denetim altına alınmıştır. Bu seviyedeki süreç alanlarında birinci ve ikinci genel amaçlar sağlanmaktadır. Organizasyonlar projeleri belirledikleri bütçe ve zamanda tamamlamaktadır. Değişik süreç uygulamaları teşvik edilerek, organizasyon için en uygun süreçler belirlenmeye çalışılmaktadır. Kurumsal politikalar doğrultusunda kurum öncelikleri oluşturulmaktadır. Yönetimin ve sorumlu kişilerin katılımı ile belirli dönemlerde ve önemli aşamalarda projeler gözden geçirilmektedir. Sıkıntılı zamanlarda süreçten vazgeçmek yerine, daha iyi olacağı değerlendirilen süreç belirlenerek uygulanmaya çalışılmaktadır. 3. Olgunluk Seviyesi nin (Tanımlı) Özellikleri: 2. ve 3. olgunluk seviyesine ait bütün süreç alanları birinci, ikinci ve üçüncü genel amaçları sağlamaktadır. Organizasyon genel olarak ortak iş tanımları kullanmaktadır. Organizasyonun standart süreçlerinden projeye göre düzenlenerek oluşturulan tanımlı süreçler kullanılmakta ve süreçler amaç, girdiler, çıktılar, doğrulama noktaları, ölçümler vb. ayrıntılı olarak ifade edilmektedir. Projeler benzer şekilde gerçekleştirildiğinden, edinilen tecrübelerden gelecek projelerde faydalanılarak maliyet ve süre kestirimleri daha uygun yapılmaktadır. 4. Olgunluk Seviyesi nin (Sayılarla Yönetilen) Özellikleri: 2., 3. ve 4. olgunluk seviyesine ait tüm süreç alanları ilk üç genel amacın gereklerini yerine getirmektedir. Organizasyon aynı işleri uzun zamandan beri aynı yöntemle yaptığından, iş yapılışları ölçülerek karşılaştırılmaktadır. Aynı iş için aynı sonuca ulaşılması hedeflenmekte ve projeler sayısal olarak yönetebilmektedir. Böylece maliyet ve süre tahminlerinin yanı sıra proje başarıları da yüksek doğrulukta sağlanmaktadır. 5. Olgunluk Seviyesi (Sürekli İyileşen) Özellikleri: 2., 3., 4. ve 5. olgunluk seviyesine ait bütün süreç alanları ilk üç genel amacın gereklerini sağlamaktadır. Aynı işin daha iyi 54

64 sonuçla nasıl elde edilebileceği hedeflenmektedir. Bu kapsamda sayısal verilerden yararlanarak kuruma en faydalı olacak süreç iyileştirme alanları belirlenmeye çalışılmaktadır. Süreç iyileştirmede yenilikçiliğe önem verilen kurumsal yapı sayesinde ürünler; düşük maliyetle, yüksek hatasızlık oranı ve daha kısa sürede yapılabilmektedir. Sürekli model Kurumlar süreç iyileştirmek için süreç alanları içinden istedikleri süreç alanını sürekli gösterim biçimi ile modelleyebilmektedir. Organizasyonlar süreç yeteneği yaklaşımı sayesinde öncelikleri ve hedeflerine göre en zayıf süreç alanlarını iyileştirebilmektedir. Bir süreç alanının alabileceği en düşük yetkinlik seviyesi 0 (sıfır) olup, bu o süreç alanının olmadığı veya uygulanmadığını göstermektedir. Belirtilen genel amaçları sağlamasına göre verilen yetkinlik seviyesinin 0 dan 5 e numaralanan (6 adet) süreç yetenek düzeyleri ve tanımları çizelge 2.10 da verilmiştir. Çizelge 2.10 CMMI sürekli model süreç yetenek düzeyleri ve tanımları Düzey Düzey Adı Düzey Tanımı 0 Eksik (Incomplete) Süreç yok veya öngörülen genel hedefleri kapsamaz. 1 Yapılan (Performed) 2 Yönetilen (Managed) 3 Tanımlı (Defined) 4 Nicel olarak yönetilen (Quantitatively Managed) 5 Eniyilenen (Optimizing) Süreç, öngörülen temel uygulamaları büyük oranda sağlamaktadır. Üretim için ihtiyaç duyulan faaliyetler yerine getirilerek ve desteklenmektedir. Süreç, temel uygulamaların performansını ve ilgili iş ürünlerini düzenli bir şekilde yönetmeyi başarıyor. Süreci destekleyen alt yapı mevcuttur. Süreç, standart bir süreç tanımına ve uygun kaynakların atanması ile yürütülmektedir. Ürünlerin, ölçümlerin ve organizasyon süreç varlıklarının iyileştirilmesi desteklenmektedir. Süreç, sayısal olarak ölçülen verilere gore kontrol edilmektedir. Kalite ve süreç performansı istatistiksel açıdan anlaşılarak, süreç yaşam döngüsünde kullanılmaktadır. Sürecin değişme yöntemi tanımlanarak, sürekli olarak iyileştiriliyor. Sürekli gösterim biçiminde süreç alanları; süreç yönetimi, proje yönetimi, mühendislik ve destek olmak üzere çizelge 2.11 de gösterilen dört sınıfta gruplandırılır. Bu sınıflar CMMI süreç alanları arasındaki bağlantıların analizi ile kurumların süreç iyileştirme faaliyetlerinin daha iyi önceliklendirilerek planlanmasını sağlamaktadır. 55

65 Çizelge 2.11 CMMI süreç alanlarının sınıflandırılması Sınıf Süreç Yönetimi Proje Yönetimi Mühendislik Destek Süreç Alanı Olgunluk Seviyesi Kurumsal Süreç Odaklaması 3 Kurumsal Süreç Tanımı 3 Kurumsal Eğitim 3 Kurumsal Süreç Başarımı 4 Kurumsal Yenilikçilik ve Yaygınlaştırma 5 Proje Planlama 2 Proje İzleme ve Kontrol 2 Yüklenici Sözleşme Yönetimi 2 Bütünleşik Proje Yönetimi 3 Risk Yönetimi 3 Sayısal Proje Yönetimi 4 Gereksinim Yönetimi 2 Gereksinim Geliştirme 3 Teknik Çözüm 3 Ürün Bütünleştirme 3 Doğrulama 3 Geçerlilik 3 Konfigürasyon Yönetimi 2 Süreç ve Ürün Kalite Güvencesi 2 Ölçme ve Çözümleme 2 Karar Çözümleme ve Çözüm Üretme 3 Sebep Çözümlemesi ve Çözüm Üretme Genel amaçlar Bir sürecin kurumsallaşma seviyesini belirlemek için aşağıda belirtilen beş genel amaç kullanılmaktadır. Genel Amaç 1 (Uygulanan Kurumsallaşma) Genel Amaç 2 (Yönetilen Kurumsallaşma) Genel Amaç 3 (Tanımlı süreç) Genel Amaç 4 (Sayılarla yönetilen süreç) Genel Amaç 5 (Sürekli iyileştirilen süreç) Her genel amaç bir kurumsallık seviyesine karşılık gelmektedir. Çizelge 2.12 de ilk üç genel amacın genel uygulamaları verilmiştir. 56

66 Çizelge 2.12 İlk üç genel amacın genel uygulamaları (Kalaycı 2007) 1.Belirli iş ürünlerini girdi alan ve belirli iş ürünlerini çıktı olarak üreten bir süreç ile süreç alanının Özel Amaçlarına ulaşmayı destekle ve mümkün kıl. 1.1.Süreç alanının amaçlarına uygun olarak, gerekli iş ürünleri ve hizmetler üretmek için, sürecin özel uygulamalarını yerine getiriyor musunuz? 2. Süreci yönetilen bir süreç olarak kurumsallaştır 2.1.Sürecin planlanması ve yürütülmesi için kurumsal bir politika oluşturulmuş ve güncel tutuluyor mu? 2.2.Süreci hayata geçirmek için plan oluşturulmuş ve güncel tutuluyor mu? 2.3.Süreç ile ilgili iş ürünlerini geliştirmek, hizmetleri sunmak ve süreci hayata geçirmek için yeterli kaynak sağlanmış mı? 2.4.Süreci hayata geçirmek, sürecin iş ürünlerini geliştirmek ve hizmetleri sunmak için yetki ve sorumluluklar atanmış mı? 2.5.Süreci destekleyecek ya da hayata geçirecek kişilere ihtiyaç duydukları eğitimler zamanında verilmiş mi? 2.6.Sürecin seçilen iş ürünleri uygun seviyede denetim altında tutuluyor mu? 2.7.Sürecin ilgili paydaşları plana uygun olarak belirleniyor ve katılımları sağlanıyor mu? 2.8.Sürecin uygulanmasını plana göre izle ve denetle, gerekirse düzeltici çalışmalar hayata geçiriliyor mu? 2.9.Süreç, süreç tanımlarına, standartlara ve yordamlara göre tarafsız olarak değerlendiriliyor ve uygunsuzlukları belirleniyor mu? 2.10.Sürecin sonuçları, durumu ve çalışmaları üst düzey yönetim ile birlikte gözden geçiriliyor ve sorunlara çözüm üretiliyor mu? 3. Süreci tanımlı süreç olarak kurumsallaştır 3.1.Süreç uygulaması için tanımlı süreç oluşturulmuş ve güncel tutuluyor mu? 3.2.Kurumun standart süreçleri ve süreç varlıkları üzerinde iyileştirmeler yapmak ve gelecekteki kullanımlarını desteklemek için, süreç planlanırken ve uygulanırken oluşturulan iş ürünleri, ölçümler, ölçüm sonuçları ve iyileştirme önerileri toplanıyor mu? CMMI ın avantajları CMMI diğer süreç iyileştirme yöntemlerine göre ürün yaşam döngüsüne ilişkin daha detaylı bilgi sağladığından, yüksek olgunluk seviyesine sahip kurumlar ihtiyaçlarını daha iyi tanımlamaktadır. CMMI ile yazlım ve sistem mühendisliği entegre edilerek ürün mühendisliğine dönüştürülmüştür (Yücalar 2006). 57

67 Dünya çapında, değişik alanlarda faaliyet gösteren irili ufaklı organizasyonel birimler içeren 35 büyük organizasyon üzerinde yapılan araştırmaların sonuçlarına göre düzenlenen çizelge 2.13 de zamana göre kategoriler bazında performansa ait ortalama ilerleme görülebilmektedir (TBD/Kamu-BIB/2008-ÇG1). Çizelge 2.13 Kategoriler bazında zaman boyunca performans ilerlemesi Performans Kategorisi Ortalama İlerleme Maliyet 34 % Takvimlendirme 50 % Üretkenlik 61 % Kalite 48 % Müşteri Memnuniyeti 14 % Yatırım Getirisi 4.0 : CMMI in değerlendirme yöntemi CMMI denetimi; SCAMPI A, SCAMPI B ve SCAMPI C olmak üzere üç çeşit Süreç İyileştirme için Standart CMMI Değerlendirme Yöntemi (SCAMPI-Standart CMMI Appriasal Method for Process Improvement) kullanılarak yapılmaktadır. A ve B sınıfı denetimler gerçek projeler tarafından üretilmiş gerçek belgeler üzerinden yapılır. Ön koşul olmamak ile birlikte A öncesi genellikle en az bir B sınıfı denetim yapılır. Böylece B sınıfı denetim ile asıl denetime hazır olduğunu gören kurumlar, A sınıfı denetim yaptırarak resmi belgelerini almaktadırlar. C sınıfı denetimler; kağıt üzerindeki süreç tanımlarından, hatta süreç tanımları dahi olmadan yapılması planlanan iyileştirme planları üzerinden yapılabilmektedir. CMMI değerlendirmesinde denetlenecek kurum ve denetleyecek kurum/kişi için gerekli ve yeterli koşullar çizelge 2.14 de özetlenmiştir. Çizelge 2.14 CMMI değerlendirmesi için gerekli süre ve kaynaklar (Yücalar 2006) Dentlenecek Kurum için Parasal Kaynak : min 35K USD + Süre: 10 gün Kurum içi ekip:5-9 kişi (x 1500 Euro Introduction eğitimi ve 3 günlük SCAMPI eğitimi) Denetleyecek kurum/kişi için Kurum:Lisanslı Transition Partner olmak, Kişi: Lead Appraiser sertifikası almak, Parasal Kaynak: <65K USD Süre:3 yıl (2 kez SCAMPI değerlendirmesine katılması) Gerekli asgari deneyim: 10 yıl Sertifika için:sei ye başvuru ve yetkilendirme 58

68 CMMI tedarik süreci SEI (CMU/SEI-2004-TR-001) CMMI tedarik süreci diğer süreçler ile kıyaslandığında aşağıda farklar ortaya çıkmaktadır: SA-CMM den daha bütünleşik bir yöntemdir. Satın almanın yalnızca alıcının değil satıcının da süreçleriyle ilgili olduğu gerçeğine dayanmaktadır. Özellikle kamu kuruluşlarında satın alma ve sonrasındaki destek konusunda gereken yol gösterme hizmetini sağlamayı hedeflemektedir. Bütünleşik ürün ve süreç geliştirme ilkelerini içermektedir. Satın alma süreçlerinin olgunluğunun ölçülmesi ve iyileştirilmesini amaçlayan tedarik için CMMI modeli (CMMI-ACQ,V1.2) Kasım 2007 tarihinde yayımlanarak yürürlüğe girmiştir. Bu tez çalışması kapsamında incelenen TSK için kabul edilecek en düşük düzey CMMI Seviye 2 ve ulaşılması hedeflenen CMMI Seviye 3 olduğu için CMMI-ACQ nin 2. ve 3. olgunluk Seviyeleri ve bu seviyeleri sağlayacak süreç alanları için Gerekli Bileşenler (GB) ve Beklenen Bileşenlerin (BB) içeriği aşağıda ayrıntılı olarak incelenecektir CMMI-ACQ 2. Olgunluk seviyesi süreç alanları Yönetilen olgunluk seviyesi için gerçekleştirilmesi gereken 9 süreç alanı ve bu süreç alanlarının sağlanması için tanımlanmış gerekli ve beklenen bileşenler aşağıda verilmiştir. 1. Gereksinimlerin Yönetimi (Requirement Management-REQM) Gereksinim yönetiminin amacı: Projenin ürünleri ve ürün bileşenlerinin gereksinimlerinin yönetilmesi, Bu gereksinimler ile proje planları ve iş ürünleri arasındaki tutarsızlıkların tespit edilmesidir. 59

69 BB.1.1 Gereksinimlerin Anlaşılması: Gereksinim sağlayıcılar ile gereksinimlerin anlamı üzerinde ortak bir anlayışın geliştirilmesi, BB.1.2 Gereksinimler için taahhütlerin alınması: Projeye katılanlarından gereksinimler için taahhütlerin alınması, BB.1.3 Gereksinim değişikliklerinin yönetilmesi: Proje boyunca gelişen gereksinimiler için değişikliklerin yönetilmesi, BB.1.4 Gereksinimlerin izlenebilirliğinin iki yönlü sürdürülebilmesi: Gereksinimler ile iş ürünleri arasında iki yönlü izlenebilirliğin sağlanabilmesi, BB.1.5 Gereksinimler ve proje planları arasındaki tutarsızlıkların tespit edilmesi: Proje planları, iş ürünleri ve gereksinimler arasındaki tutarsızlıkların tespit edilmesi. 2. Proje Planlama: Proje Planlamanın Amacı: Proje faaliyetlerinin tanımlandığı planların oluşturulması ve güncel tutulması, GB 2.1 Kestirimlerin Yerleştirilmesi: Proje planlama parametreleri için kestirimlerin oluşturulması ve güncel tutulması. BB Tedarik stratejisinin oluşturulması ve güncel tutulması, BB Projenin kapsamının tahmin edilebilmesi için en üst seviyede İş Döküm Yapısının (İDY) oluşturulması, BB İş ürünleri ve görev özelliklerinin tahmin edilmesinin (kestirimler) oluşturulması ve güncel tutulması, BB Proje planlama için temel olacak, projenin yaşam döngüsü aşamalarının tanımlanması, BB İş ürünler ve görev öznitelikleri için emek ve maliyet kestirimlerinin oluşturulması, GB 2.2 Bir Proje Planının Geliştirilmesi: Proje yönetim çalışmalarına temel oluşturmak üzere proje planı oluşturulması ve güncel tutulması. BB Proje bütçesinin ve zaman planının(takvimin) oluşturulması ve güncel tutulması, BB Proje risklerinin belirlenmesi ve çözümlenmesi (analiz edilmesi), 60

70 BB Proje verilerini yönetmek için veri yönetim planı yapılması, BB Projenin icra edilebilmesi için gerekli kaynakların planlanması, BB Projenin icra edilebilmesi için gerekli olan bilgi ve becerinin planlanması, BB İlgili paydaşların katılımının sağlanmasının planlanması, BB İşletim ve desteğe geçiş için planlamanın yapılması, BB Tüm proje planının oluşturulması ve güncel tutulması, GB 2.3 Proje planı için taahhütlerin oluşturulması ve güncel tutulması. BB Proje taahhütlerinin anlaşılabilmesi için projeyi etkileyen tüm proje planlarının gözden geçirilmesi, BB Tahmin edilen (kestirilen) ve mevcut kaynakların bağdaştırılabilmesi için proje planının düzenlenmesi, BB Plan gerçekleştirilmesinden ve desteklenmesinden sorumlu ilgililerden taahhütlerin alınması. 3. Proje İzleme ve Kontrol: Proje İzleme ve Kontrolünün Amacı: Proje gelişiminin anlaşılmasını sağlamak ve böylece projenin başarımı planlardan önemli ölçüde sapıyorsa uygun düzeltici faaliyetleri gerçekleştirmektir. GB 3.1 Projenin gerçekleşen başarım ve ilerlemelerin proje planına göre izlenmesi BB Projenin planlama parametrelerinin gerçekleşen değerlerinin proje planına göre izlenmesi, BB Taahhütlerin, proje planında tanımlanmış taahhütlere göre izlenmesi, BB Risklerin, proje planında belirlenmiş risklere göre izlenmesi, BB Veri yönetiminin, proje planına göre izlenmesi, BB İlgililerin (Paydaşların) katılımının, proje planına göre izlenmesi, BB Projenin gidişatının, başarımının ve sorunlarının düzenli olarak gözden geçirilmesinin sağlanması, BB Projenin belirlenmiş kilometre taşlarında, gerçekleşen proje başarım ve sonuçlarının gözden geçirilmesi, BB İşletme ve desteğe geçişin izlenmesi, 61

71 GB 3.2 Projenin başarımı yada sonuçları planlanmadan önemli ölçüde saptığında sorun giderecek çalışmaların yönetilmesi BB Sorunların belirlenmesi, çözümlenmesi ve sorun giderici çalışmaların tespit edilmesi, BB Belirlenen sorunları çözmek için uygun faaliyetlerin gerçekleştirilmesi, BB Sorun giderici çalışmaların kapanıncaya kadar yönetilmesi. 4. Sözleşme Yönetimi: Sözleşme Yönetiminin Amacı: Tedarikçilerden satın alınan ürünlerin satın alma sürecini yönetmektir. GB 4.1 Tedarik sözleşmesi şartlarının hem tedarikçi hem de yüklenici tarafından yerine getirilmesi. BB Tedarik sözleşmesinde belirlenmiş tedarik türüne göre faaliyetlerin gerçekleştirilmesi, BB Tedarik süreçlerinin seçilmesi, izlenmesi ve analiz edilmesi, BB Satın alınacak ürünleri kabul etmeden önce, tedarikçi sözleşmesi şartlarının yerine getirildiğinden emin olunması, BB Yüklenicinin sunduğu faturaların yönetilmesi. 5. Ölçme ve Analiz: Ölçme ve Analizin amacı: Yönetim bilgi ihtiyaçlarını desteklemek için bir ölçme yeteneğini geliştirilmek ve sürdürülmesini sağlanmaktır. GB 5.1 Ölçüm hedefleri ve faaliyetlerinin, tanımlanmış bilgi ihtiyaçları ve hedeflerine göre sıralanması, BB Tanımlanmış bilgi ihtiyaçları ve hedeflerinden türetilmiş ölçüm hedeflerinin oluşturulması ve sürdürülmesi, BB Ölçüm hedeflerini karşılamak için kullanılacak ölçümlerin belirlenmesi, BB Ölçme verilerinin nasıl sağlanacağını ve saklanacağının belirlenmesi, 62

72 BB Ölçüm verilerinin nasıl çözümleneceğini ve iletileceğinin belirlenmesi, GB 5.2 Tanımlanmış bilgi ihtiyaçları ve hedeflerini karşılayan ölçme sonuçlarının sağlanması, BB Belirlenmiş ölçüm verilerinin elde edilmesi, BB Ölçüm verilerinin çözümlenmesi ve yorumlanması, BB Ölçüm verilerinin, ölçüm tanımlarının ve analiz sonuçlarının saklanması ve yönetilmesi, BB Ölçme ve analiz çalışması sonuçlarının bütün ilgililere duyurulması. 6. Süreç ve Ürün Kalite Güvencesi: Süreç ve Ürün Kalite Güvencesi nin Amacı: Yönetime ile çalışanlara süreçler ve iş ürünleri ile ilgili objektif bakış açısını sağlamaktır. GB 6.1 İş ürünü ve sürecin tarafsız değerlendirilmesi: Uygulanan süreçlerin ve bunlarla alakalı iş ürünü ve hizmetlerin, ilgili süreç tanımlarına, standartlara ve prosedürlerine uyumunun tarafsız olarak değerlendirilmesi, BB Uygulanan süreçler arasından seçilenlerin, ilgili süreç tanımlarına, standartlara ve prosedürlerine uyumunun tarafsız olarak değerlendirilmesi, BB İş ürünleri ve hizmetler arasından seçilenlerin süreç tanımlarına, standartlara ve prosedürlerine uyumunun tarafsız olarak değerlendirilmesi, GB 6.2 Uyumsuzluk sorunlarını tarafsız olarak izlenmesi, duyurulması ve çözüldüğünde emin olunması. BB6.2.1 Kalite sorunlarının ilgililere duyurulması, sorunların yönetim ve çalışanlar ile birlikte çözüldüğünden emin olunması, BB6.2.2 Kalite güvence faaliyetlerine ilişkin kayıtların oluşturulması ve güncel tutulması. 7. Konfigürasyon Yönetimi: Konfigürasyon Yönetimi nin Amacı: İş ürünlerinin bütünlüğünü oluşturmak ve sürdürebilmek için konfigürasyon kimlik belirlemesi, konfigürasyon kontrolü, 63

73 konfigürasyon durum muhasebesi ve konfigürasyon denetimlerinin yapılmasıdır. GB 7.1 Tanımlanmış iş ürünleri için dayanakların oluşturulması. BB Konfigürasyon yönetimi altına alınacak; konfigürasyon öğeleri, bileşenleri ve ilgili iş ürünlerinin belirlenmesi, BB İş ürünleri denetimi için konfigürasyon yönetimi ve değişiklik yönetimi sisteminin oluşturulması ve güncellenmesi, BB İç kullanım ve müşteriye teslimat amacıyla dayanakların oluşturulması veya yayımlanması, GB 7.2 Konfigürasyon yönetimi altındaki iş ürünleri üzerinde yapılan değişikliklerin izlenmesi ve kontrol edilmesi. BB Konfigürasyon öğeleri için yapılan değişiklik isteklerinin izlenmesi, BB Konfigürasyon öğeleri üzerinde yapılan değişikliklerin kontrol edilmesi, GB 7.3 Dayanakların bütünlüğünün oluşturulması ve güncel tutulması BB Konfigürasyon öğelerini tanımlayan kayıtların oluşturulması ve güncel tutulması, BB Konfigürasyon dayanaklarının bütünlüğünü korunması için konfigürasyon denetimlerinin yapılması. 8. Tedarik Gereksinimlerinin Geliştirilmesi: Tedarik Gereksinimleri Geliştirilmesinin Amacı: Müşteri ve sözleşmeye ait gereksinimlerin oluşturulması ve çözümlenmesidir. GB 8.1 Müşteri gereksinimlerinin geliştirilmesi: İlgililerin ihtiyaçlarını, beklentilerini, kısıtlarını, ara yüzlerinin toplanması ve müşteri gereksinimlerine dönüştürülmesi, BB Ürün yaşam döngüsünün bütün aşamaları için ilgililerin ihtiyaçlarını, beklentilerini, kısıtlarını ve ara yüzlerinin sağlanması, BB İlgililerin ihtiyaçlarını, beklentilerini, kısıtlarını ve ara yüzlerini önceliklendirilmiş müşteri gereksinimlerine dönüştürülmesi, 64

74 GB 8.2 Sözleşme gereksinimleri içinde müşteri gereksinimlerini özümseyerek ve ayrıntılı bir şekilde inceleyerek geliştirilmesi, BB Müşteri gereksinimlerine dayanan sözleşme gereksinimlerinin oluşturulması ve güncel tutulması, BB Tedarikçiye teslim edilmesi için sözleşmesel gereksinimlerin tahsis edilmesi, GB 8.3 Gereksinimlerin çözümlenmesi ve geçerli kılınması BB Uygulama kavramları ve ilgili senaryoların oluşturulması ve güncel tutulması, BB Gereksinimlerin zorunlu ve yeterli olduğunu temin etmek için analiz edilmesi, BB İlgililerin ihtiyaçları ile kısıtları arasında dengeyi sağlamak için gereksinimlerin analiz edilmesi, BB Ürünün, kullanıcının ortamında istendiği gibi çalışacağından emin olunması için gereksinimlerin geçerliliğinin yapılması. 9. Teklif İsteme ve Tedarik Sözleşmesinin Geliştirilmesi: Teklif İsteme ve Tedarik Sözleşmesinin Geliştirilmesinin Amacı: Teklif isteme paketinin hazırlanması, ürün veya hizmeti teslim edecek yüklenicinin seçimi ve tedarik sözleşmesinin oluşturulması ve güncel tutulması. GB 9.1 Teklif İsteme ve tedarik sözleşmesinin geliştirilmesi için hazırlık yapılması. BB Potansiyel supplier (yüklenici) tanımlanması, BB Teklif değerlendirme kriterleri ve gereksinimlerini içeren teklif isteme paketinin oluşturulması ve güncel tutulması, BB Kullanılabilir bir ürünün tedarik edilebilmesinde gerçekçi ve makul bir yaklaşımın sağlanabilmesi için Teklif İsteme Paketinin ilgililer (paydaşlar) ile gözden geçirilmesi, BB Teklif İsteme Paketinin Dağıtılması ve Güncel tutulması: Potansiyel yüklenicinin cevaplaması için teklif istem paketinin dağıtılması ve teklif isteme süresince güncel tutulması, 65

75 GB 9.2 Resmi bir değerlendirme formu kullanılarak yüklenici seçilir. BB Yazılı teklif değerlendirme kriterlerine göre teklif edilen çözümlerin değerlendirilmesi, BB Tedarik sözleşmesini tamamlayabilmek için kullanılacak müzakere planlarının oluşturulması ve güncel tutulması, BB Belirlenmiş kriterler ve gereksinimlerin sağlanmasına yönelik kabiliyetlerinin değerlendirilmesine dayanılarak yüklenicinin seçilmesi, GB 9.3 Tedarik Sözleşmesinin oluşturulması ve güncel tutulması, BB Tedarik gereksinimleri ve yüklenicinin teklif edilen yaklaşımlarına dayanarak son kullanıcı ve seçilen yüklenici arasında karşılıklı anlaşmanın oluşması ve sürdürülmesi, BB Tedarik sözleşmesinin oluşturulması ve sürdürülmesi CMMI-ACQ 3. Olgunluk seviyesi süreç alanları Yönetilen olgunluk seviyesi için gerçekleştirilmesi gereken 9 süreç alanı ve bu süreç alanlarının sağlanması için tanımlanmış gerekli ve beklenen bileşenler aşağıda verilmiştir. 1. Tedarik Teknik Yönetimi: Tedarik Teknik Yönetiminin Amacı: Yüklenicinin teknik çözümlerini değerlendirmek ve çözüm için seçilen arayüzlerin yönetmektir. GB 1.1 Yüklenici çözümlerinin sözleşme gereksinimleirni karşıliyorsa onaylanmasının değerlendirilmesi BB Yüklenicinin teknik çözümlerinin seçilmesi için analiz edilmesi ve analiz yöntemlerinin kullanılması, BB Seçilen yüklenici teknik çözümlerinin analiz edilmesi, BB Sözleşmede tanımlandığı gibi yüklenici ile teknik gözden geçirmelerin yürütülmesi, 66

76 GB 1.2 Seçilen arayüzlerin yönetilmesi, BB Yönetmek için arayüzlerin seçimi, BB Seçilmiş arayüzleri yönetimi. 2. Doğrulama: Doğrulamanın Amacı: Seçilen iş ürünlerinin, yazılı gereksinimleri karşıladığından emin olmaktır. GB 2.1 Doğrulama için hazırlıkların yapılması BB Doğrulaması yapılacak iş ürünlerini ve her biri için kullanılacak doğrulama yönteminin seçilmesi, BB Doğrulamayı desteklemek için ihtiyaç duyulacak ortamın oluşturulması ve güncel tutulması, BB Seçilen iş ürünlerinin doğrulanmasında kullanılacak yordam ve ölçütleri oluşturulması ve güncel tutulması, GB 2.2 Seçilen iş ürünleri üzerinde eşdeğer gözden geçirmeler gerçekleştirilmesi BB Seçilen iş ürünlerinin eşdeğer gözden geçirmeleri için hazırlıkların yapılması, BB Seçilmiş iş ürünleri üzerinde eşdeğer gözden geçirmelerin gerçekleştirilmesi ve ortaya çıkan hataların kayıt altına alınması, BB Eşdeğer gözden geçirmelerin hazırlıkları, gerçekleştirilmesi ve sonuçları hakkındaki verileri üzerinde çözümlemelerin yapılması, GB 2.3 Seçilmiş iş ürünlerinin doğrulamasını, ilgili yazılı gereksinimlere göre gerçekleştirilmesi BB Seçilmiş iş ürünleri için doğrulamaların gerçekleştirilmesi, BB Doğrulama çalışmalarının sonuçlarının çözümlenmesi. 3. Geçerlilik: Geçerliliğin Amacı: Ürün ve ürün bileşenlerinin, çalışmaları gereken gerçek ortama konduklarında, işlevlerini yerine getireceklerinden emin olmaktır. 67

77 GB 3.1 Geçerlilik sınaması için hazırlık yapılması BB Geçerlilik sınaması yapılacak ürün ve ürün bileşenlerinin seçilmesi ve her biri için kullanılacak geçerlilik sınamasının yönteminin belirlenmesi, BB Geçerlilik sınaması için kullanılacak ortamın oluşturulması ve güncel tutulması, BB Geçerlilik sınaması için gerekli yordam ve ölçütleri oluşturulması ve güncel tutulması, GB 3.2 Ürün ya da ürün bileşenlerinin, gerçek uygulama ortamında, kullanıma uygun olduğundan emin olmak için geçerlilik sınamalarını gerçekleştirilmes, BB Belirlenmiş ürün ve ürün bileşenleri üzerinde geçerlilik sınamalarının gerçekleştirilmesi, BB Geçerlilik çalışmalarının sonuçlarının çözümlenmesi. 4. Kurumsal Süreç Odaklanması: Kurumsal Süreç Odaklanmasının Amacı: Kurumun, süreçlerinin ve süreç varlıklarının, güçlü ve zayıf yönleri üzerindeki oluşturulmuş olan anlayışa uygun olarak, gerekli kurumsal süreç iyileştirmeleri planlamak, hayata geçirmek ve yaygınlaştırmaktır. GB 4.1 Düzenli aralıklarla tekrarlayan şekilde ya da ihtiyaç duyulduğunda, kurumun standart süreçleri üzerinde iyileştirme fırsatlarını, güçlü ve zayıf yanların belirlenmes, BB4.1.1 Kurumun süreç ihtiyaçları ve hedeflerini tanımlayan belgelerin oluşturulması ve güncel tutulması, BB Düzenli aralıklarla ya da ihtiyaç duyulduğunda, kurumun standart süreçleri üzerinde güçlü ve zayıf yönleri güncel olarak öğrenmek için denetlemelerin yapılması, BB Kurumun standart süreçleri ve süreç varlıkları üzerinde iyileştirme fırsatlarını belirlenmesi, GB 4.2 Kurumun standart süreçleri ve süreç varlıkları üzerinde, iyileşmelere yönelik, süreç çalışmalarını planlanması ve gerçekleştirilmesi, 68

78 BB Kurumun standart süreçlerinde ve süreç varlıkları üzerinde, iyileşmeleri hayata geçirmek üzere, süreç hareket planlarının oluşturulması ve güncel tutulması, BB Süreç hareket planlarının uygulanması, GB 4.3. Kurumsal süreçlerin kurum genelinde yaygınlaştırılması ve süreçlerle ilgili tecrübelerin kurumda kullanılması, BB Kurumun süreç varlıklarının kurum genelinde yaygınlaştırılması, BB 4.3.2Kurumun standart süreçlerini projelerin başlangıcında projeye yaygınlaştırılması ve değişiklikleri de uygun olduğu takdirde, projenin yaşamı boyunca yaygınlaştırmaya devam edilmesi, BB Kurumun standart süreçlerin ve süreç varlıklarının projelerde kullanımının izlenmesi, BB Süreçlerin uygulanmasından ve planlanmasından öğrenilen dersleri, ölçümleri ve iyileştirme bilgilerini kurumun süreç varlıklarına eklenmesi. 5. Kurumsal Süreç Tanımlaması: Kurumsal Süreç Tanımlamasının Amacı: Kurumun, süreç varlıklarını ve çalışma ortamı standartlarını oluşturmak ve güncel tutmaktır. GB 5.1 Kurumun süreç varlıklarını oluşturulması ve güncel tutulması, BB Kurumun standart süreçlerinin oluşturulması ve güncel tutulması, BB Kurum içinde kullanılmak üzere, onaylanmış yaşam döngüsü tanımlarının oluşturulması ve güncel tutulması, BB Kurumun standart süreçleri için uyarlama ölçüt ve yönergelerinin oluşturulması ve güncel tutulması, BB Kurumsal ölçüm havuzunun oluşturulması ve güncel tutulması, BB Kurumun süreç varlıkları kütüphanesinin oluşturulması ve güncel tutulması, BB Çalışma ortamı standartlarının oluşturulması ve güncel tutulması. 69

79 6. Kurumsal Eğitim: Kurumsal Eğitimin Amacı: İnsanların görevlerini etkili ve etkin olarak yerine getirmelerini sağlamak için gerekli olan bilgi ve yetkinlikleri yaratmaktır. GB 6.1 Kurumdaki yönetsel ve teknik görevleri destekleyecek şekilde bir eğitim yeteneği oluşturulması ve güncel tutulması, BB Kurumun stratejik eğitim ihtiyaçlarının oluşturulması ve güncel tutulması, BB Hangi eğitim ihtiyaçlarının kurumun sorumluluğunda ve hangi eğitim ihtiyaçlarının projelerin ve destek birimlerinin kendi sorumluluğunda olduğunu belirlenmesi, BB Kurumsal eğitim taktik planını oluşturulması ve güncel tutulması, BB Kurumsal eğitim ihtiyaçlarını karşılamak üzere, bir eğitim yeteneğini oluşturulması ve güncel tutulması, GB 6.2 Bireylerin görevlerini etkin bir şekilde yerine getirmeleri için gerekli eğitimleri verilmesi, BB Kurumsal eğitim taktik planına uygun olarak eğitimlerin verilmesi, BB Kurumsal eğitim kayıtlarının oluşturulması ve güncel tutulması, BB Kurumsal eğitim programının etkinliğinin değerlendirilmesi. 7. Bütünleşik Proje Yönetimi: Bütünleşik Proje Yönetiminin Amacı: Projenin bütünleşik ve tanımlı sürecini, kurumun standart süreçlerinden uyarlayarak oluşturmak ve ilgili paydaşların katılımını sağlayarak projeyi yönetmektir. GB 7.1 Projelerin, kurumun standart süreçlerinden geliştirilen tanımlı süreçlere göre gerçekleştirilmesi, BB Proje başlangıcından bütün yaşamı boyunca tanımlı sürecinin oluşturulması ve güncel tutulması, BB Proje çalışmalarını kestirmek ve planlamak için kurumun süreç varlıklarını ve ölçüm havuzunun kullanılması, BB Kurumsal çalışma ortamı standartlarına uygun olarak, projenin çalışma ortamının oluşturulması, 70

80 BB Projenin tanımlı sürecini oluşturmak için proje planını ve projeyi etkileyen diğer planların bütünleştirilmesi, BB Projelerin; proje planı, etkileyen diğer planlar ve projenin tanımlı süreci kullanılarak yönetilmesi, BB Kurumun süreç varlıklarına; ölçümler, belgelenmiş tecrübeler ve iş ürünleri ile katkıda bulunulması, GB 7.2 Projeyi ilgili katılımcılar ile işbirliği içinde gerçekleştirilmesı, BB İlgili paydaşların projeye katılımının yönetilmesi, BB Kritik bağımlılıkları belirlemek, görüşmek ve izlemek için ilgili paydaşların katılımının sağlanması, BB Sorunları, ilgili paydaşlar ile çözülmesi. 8. Risk Yönetimi: Risk Yönetiminin Amacı: Ürün ya da projenin yaşamı boyunca projenin hedeflerine ulaşmasını olumsuz etkileyecek olan sorunları (riskleri) önceden tespit etmek, riskengelleyici çalışmaları planlamak ve gerçekleştirmektir. GB 8.1 Risk yönetimi için hazırlıkların yapılması. BB Risk kaynaklarının ve sınıflarının belirlenmesi, BB Riskleri çözümlemek, sınıflara ayırmak ve riskleri yönetim çabasını kontrol etmek için kullanılacak değişkenleri tanımlanması, BB Risk yönetimi için kullanılacak stratejinin oluşturulması ve güncel tutulması, GB 8.2 Risklerin önemlerine göre tanımlanması ve çözümlenmesi, BB Risklerin belirlenmesi ve belgelenmesi, BB Daha önceden belirlenmiş olan risk sınıfları ve değişkenlerine göre her bir riskin değerlendirilmesi, sınıflandırılması ve önceliklendirilmesi, GB 8.3. Hedeflere ulaşmakta olumsuz etkilerini azaltmak ya da yok etmek üzere riskleri ele alınıp engellenmesi, BB Risk yönetimi stratejisine uygun olarak, en önemli riskler için risk 71

81 engelleme planının oluşturulması, BB Düzenli aralıklarla risklerin durumlarının izlenmesi ve gerekli durumlarda risk engelleme planlarının hayata geçirilmesi. 9. Karar Çözümleme ve Çözüm Üretme Karar Çözümleme ve Çözüm Üretmenin Amacı: Tespit edilmiş seçenekleri belirli ölçütlere göre değerlendirmek için resmi bir süreç kullanmak ve olası kararları çözümlemektir. GB 9.1 Kararların, seçenekleri belirlenmiş ölçütlerin değerlendirilmesi ile verilmesi, BB Resmi karar verme süreçlerine muhatap olduğun konuların belirlemek için yönergelerin oluşturulması ve güncel tutulması, BB Seçenekleri değerlendirmek için ölçütleri ve ölçütlerin kendi aralarındaki ilişkili ağırlıklarının oluşturulması ve güncel tutulması, BB Sorunların çözümü için seçeneklerin tanımlanması, BB Değerlendirme yönteminin seçilmesi, BB Belirlenmiş yöntem ve ölçütlere göre seçenekleri değerlendirilmesi, BB Seçenekler arasından, belirlenmiş ölçütlere göre, çözümün seçilmesi ISO 9000 Kalite Yönetim Sistemi ve Kalite Güvence Standartları 1947 yılında kurulan Uluslararası Standartlar Organizasyonu (ISO) uluslararası ürün ve hizmet ticaretinde katkı sağlamak için standartlaşmayı tüm dünyada yaygınlaştırmayı amaçlamıştır. Standardizasyon çalışmalarının bütün dünyada, her alanda yaygınlaşması ile uluslararası ürün ve hizmetin ticaretinde sağlayacağı kolaylıklar; sanayiye, ticarete ve tüketicilere olumlu katkılar sağlamaktadır. ISO tarafından çıkarılan ve endüstrinin her alanını kapsayacak şekilde tasarlanan ISO 9000 Kalite Sistemi ve Güvencesi Standartları; etkili bir yönetim sisteminin nasıl kurulacağını, dokümante edileceğini ve devam ettririlebileceğini içermektedir. ISO 9000 da, organizasyonun yapması gerekenler belirtilmiş olup, bunların yerine getirildiğinin gösterilmesi istenmektedir. Ayrıca geliştirme sürecinde yer alan her bir aktivitenin nasıl ele alındığını gösteren duruma özel yöntemlerin belgelendirilmesi 72

82 istenmektedir. ISO 9000 e uyumluluk için gereken özellikler; kontrol, uyarlanabilirlik, doğrulama ve süreç iyileştirmedir. Organizasyon her zaman neyin planlandığını, nasıl yapıldığını, projenin ve ürünün halihazırdaki durumunu ve kalite sisteminin etkinliğini ispat edecek geçerli kanıtları gösterebilmelidir. Bu standart ürünün isterleri karşılayıp karşılayamadığı ve başlangıçta hedeflendiği gibi üretilip üretilemediğinin gösterilmesini sağlamanın yanı sıra organizasyonun süreçlerini sürekli iyileştirerek, ürün ve servis kalitesini sürekli bir şekilde arttırmasını istemektedir.(mihalsky 1992). Denetim mekanizmasına gereksinim duyan ve dışarıya kalite güvencesi vermeye yönelik belgelendirmeye önem veren bu standartlar, şirket düzeyi hakkında genel bilgi verirler. Kalite yönetim sistemi standartları 3 temel standarttan oluşmaktadır. -ISO 9000:2000 Kalite Yönetim Sistemleri-Temel Kavramlar, Terimler ve Tanımlar, -ISO 9001:2000 Kalite Yönetim Sistemleri-Şartlar, -ISO 9004:2000 Kalite Yönetim Sistemleri-Performansının İyileştirilmesi İçin Kılavuz, ISO 9001, yazılım mühendisliği ihtiyaçlarına göre düzenlenerek ISO çıkarılmıştır. ISO Kalite Yönetimi ve Kalite Standartları Kısım 3: yazılım tasarlayan, geliştiren, arz eden, yükleyen ve bakımını yapan kuruluşlara ISO 9001 in uyarlamasını kolaylaştırmak için hazırlanmış ve ISO 9001 in yazılım sektörü için uygulama esaslarını içeren bir kılavuzdur (ISO ) AQAP-160 (Allied Quality Assurance Publications- Müttefik Kalite Güvence Yayınları) AQAP-160; ABD hariç diğer NATO (North Atlantic Treaty Organization) ülkelerinde askeri amaçlı yazılım sistemleri için kalite gereksinimlerini tanımlayan bir standarttır. Gelişmiş teknolojinin kullanımı ve sürekli artan karmaşıklık seviyeleri ile yüksek maliyet gerektiren askeri amaçlı sistemler kullanıcının isteklerini sağlayacak şekilde tanımlanması, tasarlanması ve geliştirilip üretilmesinin maliyet etkin olarak yapılabilmesi için NATO ya bağlı ülkelerde AQAP 160 belgesi aranmaktadır. 73

83 AQAP, NATO içinde müşterek uygulamaların temini için standardizasyon anlaşması (STANAG-4108) çerçevesinde 1983 ten itibaren uygulamaya başlanmıştır. Bu belge her devletin yetkilendirdiği kurumlar tarafından verilmekte olup, belirli aralıklarla yenilenmesi gerekmektedir. Türkiye de bu konudaki denetimler Milli Savunma Bakanlığı(MSB) tarafından yapılmaktadır. AQAP 160; ISO/IEC ve ISO 9001:1994/ISO 9001:2000 den kaynaklıdır. Toplam 6 bölüm ve 3 Ek ten oluşur. Yazılım İçin Ömür Devri Boyunca Birleştirilmiş NATO Kalite Gereksinimleri nin (AQAP-160 Baskı 1, Temmuz 2001) ana başlıkları aşağıda verilmiştir: Bölüm 1: Genel (General) Bölüm 2: Kalite Sistem İstekleri (Quality System Requirements) Bölüm 3: Temel Ömür Devri Süreçleri Gereksinimleri (Primary Life Cycle Processess Requirements) Bölüm 4: Ömür Devri Süreçleri Gereksinimlerinin Desteklenmesi (Supporting Life Cycle Processess Requirements) Bölüm 5: Süreç Gereksinimlerinin Uyarlanması (Tailoring Process Requirements) Bölüm 6: NATO ya Has İstekler (NATO- Specific Requirements) Modellerin karşılaştırılması CMM, sadece organizasyon bazında ve olgunluk düzeyini belirlemeyi amaç edinen bir model olduğu için büyük firmalara hitap eden, maliyeti yüksek, anlaşılması ve uygulaması zor bir modeldir. CMMI, organizasyon bazında olgunluk seviyesine göre basamaklı, süreç bazında süreç yeteneğine göre sürekli değerlendirme imkanı olması, organizasyonların süreç iyileştirme faaliyetleri açısından esneklik sağlamaktadır. Bu özelliği sayesinde her tür büyüklükteki, hem savunma sanayindeki hem de sivil firmalar için değerlendirme modeli olarak kullanılabilir. 74

84 ISO 9001, genel olarak nelerin yapılması gerektiğini belirtmekte olup, henüz işin başında olan ve kaliteyi hedeflemiş firmaların kullanabileceği bir modeldir. ISO/IEC 12207, yazılım yaşam döngüsü süreçlerini (satın alma, tedarik, geliştirme, işletim ve bakım süreçleri ile yazılım destek ve organizasyon süreçlerini) kapsadığından yazılım mühendisliği etkinlikleri için yaşam döngüsü modeli olarak kullanılabilir. Ancak değerlendirme yapılmadığından bir değerlendirme modeliyle birlikte kullanılması gerekmektedir. Sivil ve askeri organizasyonlarca uygulanabilen ISO/IEC 12207; süreçlerini oluşturma ve yerleştirmek isteyen yeni başlamış küçük firmalar tarafından referans olarak kullanılabilir. AQAP-160, yazılım ağırlıklı askeri sistemlerin tedariğine yönelik sözleşmelere ait kalite yönetim sistemi uygulamaları için geliştirilmiştir. ISO/IEC ve ISO-9001 özellikleri bütünleştirilmiştir. ABD hariç diğer NATO ülkelerinin, askeri amaçlı yazılım sistemleri için geliştirilmiş olup, bürokrasi yükü fazladır. Savunma sanayi alanında hizmet veren firmalar alıcının isteğine bağlı olarak; proje veya kurumsal seviyede süreç değerlendirme ve iyileştirme faaliyetlerini AQAP-160 a göre gerçekleştirmektedir. Yazılım yoğunluklu sistemler için geliştirilen modeller inceledikten sonra bir sonraki bölümde Türkiye de ve özellikle Türk Savunma Sanayiindeki yazılım firmalarının bu konuya bakışları ve bu konuda yürütülen çalışmalar gözden geçirilecektir. 75

85 3. TÜRKİYE DE YAZILIM SÜREÇ MODELLERİNİN KULLANIMI 3.1 Giriş Uluslararası alanda yazılım ağırlıklı sistemlerin tedarikinde, yüklenicinin belli bir olgunluk seviyesinde olması tercih edilmektedir. Belli bir olgunluk seviyesindeki kurumlarda yazılım geliştirme süreçleri doğru uygulanmakta, oluşabilecek riskler ve bunlardan kaynaklanacak ilave masraflar erkenden görülerek en uygun tedbirlerin alınması sağlanabilmektedir. Türkiye Savunma Sanayii kapsamında hizmet veren firmalar da hem uluslararası rekabet koşullarında var olabilmek hem de en büyük müşterileri Türk Silahlı Kuvvetleri (TSK) için geliştirdikleri sistemlerin güvenilirliğini ve projelerin başarılı bir şekilde tamamlanmasını taahhüt etmek için belli bir olgunluk seviyesine ulaşmayı hedeflemektedir. Bu kapsamda Türkiye de çalışmalarını sürdüren bazı yazılım firmalarının olgunluk seviyeleri ve yazılım sistemleri ile ilgili sahip oldukları belgeler çizelge 3.1 de verilmiştir. Firmaların yanısıra üniversitelerimizde de bu konuda çalışmalar yürütülmektedir. İstanbul Teknik Üniversitesi (İTÜ) ile Carnegie Mellon Üniversitesi (CMU) Software Engineering Institute (SEI) arasında 10 Mart 2008 tarihinde işbirliği protokolü imzalanmıştır. Dünyada CMMI sertifikasını verme, denetleme, yol gösterme ve hakemlik haklarını elinde bulunduran CMU-SEI, stratejik ortak olarak seçtiği İTÜ ile imzaladığı protokol gereği Türkiye'de CMMI belgesini verecek tek yetkili kurum İTÜ olmuştur. Ayrıca İTÜ, ABD dışında da CMMI sertifikası verebilecektir. ( 2009) 76

86 Çizelge 3.1 Türkiye de yazılım sektöründe hizmet veren bazı kuruluşların yazılım ile ilgili sertifikaları Firmalar Sertifikalandırıldığı Yetenek Olgunluk Modeli (Yılı) Sertifikalandırıldığı Yazılım İle İlgili Diğer Kalite Belgeleri (Yılı) AYDIN YAZILIM A.Ş.¹ CMMI Seviye-3 (2007) AQAP-160 (2006) IS0 9001:2000 ve AS 9100 B (2007) HAVELSAN A.Ş.² CMM Seviye-3 (2003) AQAP 150 (1998) AQAP 160 (2005) MİLSOFT ³ CMMI Seviye-5 (2005) IS0 9001:2000 AQAP STM 4 CMMI Seviye-3 (2006) IS0 9001:2000 AQAP METEKSAN SİSTEM 5 CMMI Seviye-3 (2006) ISO 9001:2000 TAI A.Ş. 6 CMMI Seviye-3 (2007) AQAP-2110 (2005) ISO 9001:2000 AS 9100 B (2003) TUBİTAK UEKAE/G222 BİRİMİ 7 ISO 9001: 2000 (2003) CMMI Seviye-3 (2008) AQAP-150 (2004) TUBİTAK MAM BİLİŞİM ISO 9001: 2000 (2002) TEKNOLOJİLERİ ENSTİTÜSÜ 8 CMMI Seviye-3 (2008) AQAP 160 (2003) Türkiye de yazılım geliştiren firmaların süreç bazlı modelleri, organizasyonel standartlarla birlikte kullandıkları çizelge 3.1 den görülmektedir. Bu kapsamda daha önce 2. Yazılım Nitelik Çalıştayı nda yazılım standartları ve modellerine ilişkin olarak yayımlanan bir incelemede: (Yazılım Nitelik Çalıştayı 2 1. Çalışma Grubu Raporu, ) Organizasyonel modellerin (ISO 9001: 2000 ve AQAP 160) kalite yönetim sistemi gereklerini karşıladığı, ancak uygulamanın gerçekleştiği seviyelerde detay sağlayamadığı ve süreç iyileştirmede yetersiz kaldığı, Süreç bazlı modellerin (CMM/CMMI) ise uygulamaya ilişkin etkinlik ve adımları tanımladığı, ancak organizasyon seviyesindeki hususların karşılanmasında yetersiz kaldığı,... bu sebeple, söz konusu standartların/modellerin birbirlerini tamamlayacak şekilde birlikte kullanılmasının yararlı olacağı değerlendirilmiştir. (1) (2) (3) (Dülgar 2007) (4) (5) (Uzunalioğlu 2007) (6) NT_163, (Kutluay 2007) (7) (8) 77

87 Bu kapsamda IEEE tarafından yayımlanmış bir çalışmada, başlangıç düzeyinde bir ISO kalite standardına sahip bir organizasyonun süreçlerini iyileştirmek istediğinde, bu amaç doğrultusunda ayrıntılı yol haritası sağlayan CMMI ı kullanabileceği belirtilmiştir. CMMI ve ISO farklı hedeflere, amaçlara ve detaylara sahip olmakla birlikte benzer konular da içermektedir. ISO ve CMMI ilkelerinin birleştirildiği bir model Yoo, Yoon, Lee, Lee, Lee, Hyun ve Wu tarafından oluşturulmuş, bu modelin ISO sertifikasına sahip bir organizasyonun yüksek CMMI seviyesine ulaşabilmesi için faydalı bir araç olabileceği değerlendirilmiştir. (Yoo, Yoon, Lee, Lee, Lee, Hyun ve Wu 2004) Ayrıca, yüklenicinin ve tedarik kurumunun belli bir olgunluk seviyesinde olması tedarik projelerinin başarıyla tamamlanma olasılığını arttırmaktadır. Şekil 3.1 de tedarik kurumu ile yüklenicinin olgunluk seviyeleri arasındaki ilişki görülmektedir. Tedarik Makamı Yetenek /olgunluk YANLIŞ EŞLEŞME - Olgun alıcı, olgun olmayan yükleniciye öğretmenlik yapmak zorundadır. - Çıktılar tahmin edilebilir değil. FELAKET - Daimi kriz - Gerekler yönetilmiyor - Risk yönetimi yok. - Disiplin yok. - Sireç yönetimi yok. EŞLEŞMİŞ TAKIMLAR - Yetenekler ve ve olgunluk eşleşmiş durumda - Planlar uygulanıyor. - Ölçülebilen performans - Nicel yönetim Yüksek olasılıklı başarı YANLIŞ EŞLEŞME - Müşteri daima haklıdır. felsefesini uygulamak rahatsızlık vericidir. - Müşteri kısa yollar ı destekler. Yüklenici Yetenek/olgunluk Şekil 3.1 Tedarik makamı/yüklenici olgunluk seviyelerinin birbirine etkisi (Markarian ve Fisher 2003, Tatlı 2007) Tedarik makamının yüksek olgunluk seviyesinde olduğu durumlarda; tanımlanmış sorumluluklar, değişken olmayan tedarik süreçleri ile yüklenici ve tedarik makamının ortak bir anlayışa sahip olması sayesinde projelerin başarılı bir şekilde yönetimi sağlanabilecektir(tatlı 2007). Tedarik kurumunun kendi olgunluk seviyesini arttırması ve yüklenicilerin de kendi belirlediği olgunluk seviyesinde olmasını istemesi projelerin başarı oranının artmasını sağalayacaktır. 78

88 3.2 Türk Silahlı Kuvvetleri nin Tedarik Süreci Türk Savunma Sanayii firmalarının en büyük müşterisi olan Türk Silahlı Kuvvetleri nde (TSK), yazılım sistemleri diğer tüm sistemlerin tedariğini de içeren Planlama Programlama ve Bütçeleme Sistemi (PPBS) faaliyetleri sonucunda yayımlanan On Yıllık Tedarik Planı (OYTEP) uyarınca projelendirildikten sonra belirlenen tedarik makamı ve modeline göre temin edilmektedir. TSK projelerinde yazılım sistemlerinin ISO 9001:2000 ve AQAP-160 standartlarına göre geliştirilmesi istenmektedir. TSK de mevcut tedarik faaliyetleri 05 Mart 2007 tarihinde yürürlüğe giren MY TSK Planlama, Programlama ve Bütçeleme Sistemi (PPBS) Yönergesine göre yürütülmektedir. Bu çalışmada, 2007 öncesi sürece daha önce yayımlanan çalışmalar kapsamında kısaca değinildikten sonra eski süreçten kaynaklanan sıkıntıları gidermek için yeni sürecin sağladıkları, OYTEP in sanayiye açılması kapsamında, firma/kurum veya kuruluşlarla paylaşılan içerikte genel olarak verilmiştir. TSK inde yazılım sistemlerinin mevcut tedarik süreci, uluslararası alanda yazılım sistemlerinin tedariğinde beklentilerin karşılanması için istenen en az SA CMM Seviye-2 ye göre analiz edildiğinde, mevcut sürecin iyileştirilebilmesi için ilave edilmesinin faydalı olacağı değerlendirilen faaliyetler verilmeye çalışılmıştır. Tedarik Faaliyetleri, projeler için gerekli kaynağın ayrılmasından, belirtilen sistemin envantere girenceye kadar mevcut yasa, tüzük ve yönetmelikler kapsamında gerçekleştirilmesi gereken tüm çalışmalardan oluşmaktadır. TSK de tedarik sürecinin yönetiminde, ana sistemin geliştirilmesi, tedariki, idamesi ve envanterden çıkarılmasını gerektiren faaliyetlerin planlanması için bir çerçeve sağlayan Ömür Devri Yönetim Modeli kullanılmaktadır (Bilir 2002, Katar 2006, Bilgen 2006, Gürkan 2007). Ömür Devri Proje Yönetim Sistemi nin Proje Yönetim Aşamaları şekil 3.2 de verilmiştir. Konsept Araştırma ve Tanımlama Demonstrasyon ve Değerlendirme Üretim ve Üretim Geliştirme İşletme ve Destek Envanterden Çıkarma Şekil 3.2 Ömür devri proje yönetim aşamaları 79

89 PPBS, TSK nin tüm ihtiyaçların karşılanabilmesi maksadıyla tahsis edilen kaynakların kullanılmasına ilişkin kararların doğru ve zamanında alınmasına yönelik ilke, usul ve esasları belirleyen bir savunma planlama sistemidir. PPBS nin ilk aşamasında ihtiyaçlar tespit edildikten sonra bu ihtiyaçları giderebilecek çözüm yöntemleri, mevcut kaynak ve bütçeye göre tanımlanarak projelendirilmektedir öncesindeki tedarik süreci, on yıllık bir dönemi kapayan Planlama, Programlama ve Bütçeleme faaliyetlerinden oluşmaktaydı. Daha önce yapılan farklı tez çalışmalarında 2007 öncesi tedarik sürecinin yapısı ve süreçte yaşanan sıkıntılar ile ilgili bilgi verilerek SA CMM a göre değerlendirildiğinde Seviye-2 yi karşılmadığı belirtilmiş ve süreç iyileştirmek için yeni tedarik modelleri önerilmiştir. Söz konusu çalışmalar incelendiğinde, 2007 öncesi tedarik sürecinde yaşanan sıkıntılar genel olarak çizelge 3.2 de verilmeye çalışılmıştır (Bilir 2002, Bilgen 2006, Katar 2006, Gürkan 2007). Çizelge 3.2 TSK nin 2007 öncesindeki tedarik sürecinde yaşanan sıkıntılar. Eski PPBS Sürecinde Sıkıntıların Yaşandığı Konular Eğitim Yetersizliği Sayısı/Miktarı Personelin Uzmanlığı Görevlendirilme Süresi Birlikte Çalışabilirliği İhtiyaçların /Gereksinimlerin Yerli sanayiinin yetersizliği Veri tabanı seviyesi Sürece geç dahil olunması Proje tanımlama bilgilerinin yetersizliği Maliyet bilgilerinin sağlıklı belirlenememesi Planlama zafiyeti Doğru ve zamanında belirlenmesi Zaman kısıtlamasından dolayı yeterli ayrıntıda yapılamaması Miktarı ve özelliklerinin değişme sıklığı TSK de yürütülen iyileştirme çalışmaları ile mevcut tedarik süreci geliştirilerek, söz konusu aksaklıklar farklı yöntemlerle giderilmeye çalışılmıştır. Mevcut süreç; ihtiyaçların belirlenmesinden, malzemenin envantere girmesi, ömür devri içinde modernizasyonu ve envanterden çıkarılması için yerine planlanacak yeni sistemin tedarikine kadar olan tüm faaliyetleri kapsamaktadır. Yirmi yıllık bir dönemi içeren 80

90 mevcut tedarik süreci; Harekat İhtiyaçlarını Belirleme, Planlama, Programlama ve Bütçeleme faaliyetlerinden oluşmaktadır. -Harekat İhtiyaçlarını Belirleme Safhası: Yeni süreç ile harekat ihtiyaçlarının belirlenmesi planlama safhasından ayrılarak bir yıllık sürede, hedeflenen görevlerin yerine getirilebilmesi için kısa, orta ve uzun vadeli ihtiyaçların tespit edilip önceliklendirilerek Harekat İhtiyaçları Planı (HİP) yayımlanmakta, ihtiyaç duyulan sistemin taktik ve teknik özellikleri Proje Tanımlama Dokümanı nda (PTD) tanımlamaktadır. -Planlama Safhası: Sürecin ikinci aşamasında 20 yıllık bir dönemde ihtiyaçların karşılanmasına yönelik ön yapılabilirlik etütlerinin yapılması, sistemin alternatifleri ve teknik özellikleri ile tedarik makamının belirlenmesi, sistem ve yetenek hedeflerinin ortaya konularak Stratejik Hedef Planı (SHP) nin hazırlanması faaliyetlerini içermektedir. TSK İhtiyaçlarının yurt içinden karşılanma oranının artırılması maksadıyla, SHP de yer alan projelerden Genelkurmay Başkanlığınca uygun görülen projeler, MSB lığı tarafından ilgili sanayicilere duyurularak, bu ihtiyaçların yurt içinde üretimi için gerekli planlama ve yatırım zamanının kazanılmasının sağlanabilmesi için sözleşmesi imzalanmamış projelerden sanayicilere duyurulması teklif edilen projelere ait, Sanayicilere Verilecek Proje Ön Tasarım Bilgi Paketleri gönderilecektir. Bunlardan faydalanarak, Ön Yapılabilirlik Etüdü (ÖYE) hazırlayacak Firma/Kurum ve Kuruluşlar açıklanan projeleri TSK ihtiyaçlarının karşılanmasına yönelik çalışmalar dışında kullanmayacaklarına ve aldıkları tarihten itibaren 3 (üç) ay içerisinde MSB.lığına vereceklerini taahhüt etmektedirler. ( anasayfa. php,2009). PTD lerde ortaya konulan sistem kabiliyetlerine göre en uygun alternatif sistemlerin belirlenebilmesi amacıyla; taktik ihtiyaçları ile endüstiriyel olanakların karşılaştırılıp, harekât etkinlik, uygunluk, performans ve tahmini maliyete göre değerlendirilmeler ÖYE ile yapılmaktadır. Planlama aşaması tamamlandığında tedarik makamına karar verilmekle birlikte tedarik modeli için ön değerlendirme yapılmaktadır. 81

91 Mevcut süreçte sivil üniversite, Savunma Bilimleri Enstitüsü, Savuma Araştırma Enstitüsü gibi kurumlarla teknoloji ve TSK modernizasyon faaliyetleri konularında koordinede bulunulması için SHP yayımını müteakip 2-3 ay içinde MSB.lığı Müsteşarlığınca Sanayici-Üniversite-TSK Koordinasyon Semineri düzenlenmesi yer almaktadır. -Programlama Safhası: Gelecek on yıllık dönemde, SHP ile belirtilen öncelik sırasına göre tedarik edilmesi planlanan sistemlere, mevcut kaynakların ayrılarak, takvime bağlandığı aşama OYTEP dokümanının yayımlanması ile sona ermektedir. Böylece sistemlerin tedarik süresi, proje yönetim esas ve usulleri ile projenin tedarik modeli belirlenip, mevcut kaynaklar ile projenin öncelikleri ve maliyeti nihai hale getirilmektedir. Genelkurmay Başkanlığınca SHP de yer alan projelerden Yapılabilirlik Etütleri (YE) yapılması/yaptırılması değerlendirilen projeler, ÖYE Değerlendirme sonuç raporlarıyla birlikte tedarik makamına bildirilmektedir. YE, bir görev yeteneğinin karşılanması amacıyla sistemlerin kullanımına, geliştirilmesine ve üretimine esas hususların ortaya konulmasını sağlamaktadır. -Bütçeleme Safhası: OYTEP esas alınarak, bütçe tekliflerinin hazırlanması, onaylanan bütçelerin uygulanmasının izlenmesi, rapor ve analiz edilerek değerlendirilmesini içermektedir. Tedarik makamının ve modelinin seçiminde, yapılan ÖYE/YE ile teknik kriterler (performans), takvim, kaynak/maliyet, risk, tedarik hızı/elastikiyetler, yurtiçi fayda (offset/yerli katılım), etkinlik, tahditler/kısıtlamalar, hassasiyetler, sanayileşme, idame imkanları, idame maliyetleri ve uygun rekabet koşulları değerlendirmektedir. Bu kriterlerin oluşturacağı önceliklere göre; tedarik makamı (MSB.lığı, SSM.lığı veya Kuvvet Komutanlığı) ve çizelge 3.3 de verilen tedarik modeli belirlenmektedir. Onaylanan tedarik makamı ve modeline göre farklı tedarik faaliyetleri yürütülmektedir. 82

92 Çizelge 3.3 Tedarik modelleri Hazır Alım Ortak Üretim/ Konsorsiyum Katılımı Özgün Geliştirme Tedarik Modeli - Yurtiçi - Yurtdışı - İkili Ortaklıklar - Konsorsiyum (Çok Uluslu Katılım) -Yurtiçi Üretim - Lisans Altında Yurtiçi Üretim - Ortak Yatırım Şirketinde Yurtiçi Üretim Mevcut sürecin sonucunda hazırlanan dokümanlar (PTD, ÖYE ve YE) ile projelerin teknik şartname yazımında kullanılabilecek bilgi alt yapısı kazanılmış olur. Bu kapsamda icra edilecek faaliyetler, Kuvvetlerin Planlama, Programlama, Bütçeleme ve Uygulama Sistemi (PPBUS) de yönergesinde belirtilmektedir. PPBS ve PPBUS da proje yönetim safhasında yapılacak çalışmalar, gözden geçirme toplantıları ve her bir gözden geçirmede onaya tabi dokümanlar genel hatları ile belirlenmiştir. TSK nin 2007 öncesi tedarik sürecinde yaşanan sıkıntılara mevcut sürecin sağladığı çözümler çizelge 3.4 de özetlenmiştir. 83

93 Çizelge 3.4 Mevcut süreç ile 2007 yılı öncesi tedarik sürecinde yaşanan sıkıntılara getirilen çözümler. Eski Tedarik Sürecinde Yaşanan Sıkıntılar Personelin İhtiyaçların Eğitim Yetersizliği Sayısı/Miktarı Uzmanlığı Yerli sanayinin yetersizliği Veri tabanı seviyesi Sürece geç dahil olunması Görevlendirilme Süresi Birlikte Çalışabilirliği Doğru ve zamanında belirlenmesi Zaman kısıtlamasından dolayı yeterli ayrıntıda yapılamaması Miktarı ve niteliğinin sık değişmesi Proje tanımlama bilgilerinin yetersizliği Maliyet bilgilerinin sağlıklı belirlenememesi Planlama zafiyeti Mevcut Tedarik Süreci ile Getirilen Çözüm Görevlendirilecek personelin; süreçle ilgili konularda göreve başlamadan önce gerekli eğitimleri alması ve görevde uzun süre kalması planlanmaktadır. Ayrıca ikinci bir ihtisas sağlayacak şekilde geliştirme programları ile uzmanlaşması için çalışılmaktadır. Entegre proje grupları oluşturularak teknik ve taktik konularda uzman personelin birlikte çalışması hedeflenmektedir. Eski süreç iki yıl sürmekte olup, on yıllık ihtiyaçlar belirlenmekteydi.mevcut süreç üç yıla çıkarılarak ihtiyaçlarının belirlenmesi için bir yıl süre ayrılmıştır. Ön Yapılabilirlik Etüdü/Yapılabilirlik Etüdü ile ihtiyaçların/gereksinimlerin doğru, zamanında ve yeterli detayda yapılmasını sağlayacak alt yapı oluşturulmaya çalışılmaktadır. Milli ve kritik sistemlerin yerli savunma sanayinden tedarik edilmesi, mümkün olmadığında ortak üretim ile yerli savunma sanayinin geliştirilmesi amaçlanmaktadır. Türk Savunma Sanayisinin teknoloji veri tabanını oluşturmak ve güncel tutmak amacıyla, MSB.lığı tarafından tasarlanan ve geliştirilen Savunma Teknolojileri Bilgi Sistemi (STBS) uygulanmaktadır. İhtiyaç sahibi makam; taktik ve teknik hususlarda destek verecek şekilde sürecin her aşamasında yer almaktadır. Ön Yapılabilirlik/Yapılabilirlik Etüd Sonuç Raporları sayesinde projelerle ilgili bilgi alt yapısı kazanılması hedeflenmektedir. Ön yapılabilirlik/yapılabilirlik Etütleri ile projelerin yapılabilirliği, performansı ve maliyet bilgileri belirlenmeye çalışılmaktadır. Harekat İhtiyaçları Belirleme, Planlama, Programlama ve Bütçeleme olarak dört safhadan oluşan süreçte Planlama için bir yıllık süre ayrılmıştır. 84

94 TSK nin 2007 öncesi tedarik sürecinde yaşanan sıkıntılara çözüm getirilmesi için daha önce yapılan birçok çalışmada yeni tedarik modelleri önerilmiştir (Bilir 2002, Katar 2006, Gürkan 2007). Bu modellerden en sonuncusu H.Gürkan tarafından önerilen modeldir. Aşağıda, Gürkan ın çalışmasında dikkat çeken 6 husus özetlenmekte ve mevcut süreç çerçevesinde her biriyle ilgili olarak yapılan değerlendirme sunulmaktadır: 1 - Uygulamaların olgunluk kavramından uzak olduğu saptanmış ve kurumsal tecrübeler ile tedarik sırasında edinilen deneyimlerden yararlanılamadığı belirtilmiştir. Teklif edilen tedarik modelinin uygulanması ile çıkarılan dersler ve tecrübelerden faydalanarak bilgi birikimi sağlanacağına değinilmiştir. Mevcut süreçte projeler tamamlandıktan 6 ay sonra projelerden edinilen tecrübe ve deneyimlerin aktarılması sağlamak üzere doküman hazırlanmaktadır. Ayrıca Türk Savunma Sanayisinin teknoloji veri tabanını oluşturmak ve güncel tutmak amacıyla, MSB.lığı tarafından tasarlanan ve geliştirilen Savunma Teknolojileri Bilgi Sistemi (STBS) uygulanmaktadır. 2 - Teklif edilen modelde tedarik süreci görev ihtiyaçlarının tanımlaması ile başlayıp envanterden çıkarılması ile sonlanmaktadır. Bu amaçla proje yöneticisi talep hazırlanması, risk yönetimi, tedarik yönetimi dahil proje başlangıcında tüm faaliyetlerini gerçekleştirmektedir. Mevcut sürecin planlaması 20 yıllık bir süreyi kapsadığından; ihtiyaçların belirlenmesinden, sistemlerin envanterden çıkıncaya kadarki süreç, hatta gerçekleştirilecek modernizasyon projeleri veya yerlerine tedarik edilmesi planlanacak yeni sistemler görülebilmektedir. Her bir safhada yapılacaklar, ilgili yönergelerin proje yönetim aşamalarında ayrıntılı olarak verilmiştir. 3 - Eski süreçte projeleri denetlemek ve yönetmek üzere kesin bir proje yönetim planı olmadığı belirtilerek bir proje yönetim planı oluşturulması teklif edilmiştir. Mevcut sürecin ilgili yönergelerinde bulunan proje yönetim planında, projelerin önemli safhalarındayapılacak toplantılar ve oluşturulacak dokümanlar belirtilmesinin yanısıra sistemlerin yazılım ve donanım olarak ayrı değerlendirilmesi gerektiği ortaya konulmuştur. Böylece ana sistemlerin tedarikinde yaşanabilecek sıkıntıların donanımsal mı yoksa yazılımsal mı olduğu önceden görülerek, gerekli önlemler alınabilecektir. 85

95 4 - TSK nin tedarik sürecinde yazılım yoğunluklu sistemlerin tedarik edilirken, silah, lojistik gibi diğer sistem ve malzemelerin alınması ile aynı yöntem izlenmektedir. Teklif edilen modelde yazılım yoğunluklu sistemlerin tedarikini diğer sistemlerden ayırt etmektedir. Mevcut süreçte de yazılım yoğunluklu sistemlerin tedariki için ayrı bir yöntem yoktur. Ancak ÖYE/YE de yapılan çalışmalarda ve ilgili yönergede yer alan sistemlerin yazılımsal ve donanımsal değerlendirilmesi ile bu ayrımın kısmen yapıldığı değerlendirilmektedir. Teklif edilen model SA-CMM a göre yapıldığından yazılım yoğunluklu sistemlerin tedarik edilmesine yönelik olarak özel bir yöntem geliştirilmiştir. Ancak TSK in de genel olarak tüm sistemlerin tedarikinde kullanılan yapı göz önüne alındığında, iyileştirme yapılabilmesi için yazlım ve sistem mühendisliği entegre edilerek ürün mühendisliğine dönüştürülen CMMI a göre bir çalışma yapılmasının daha faydalı olacağı değerlendirilmektedir. 5 - TSK nin eski tedarik sürecinde bütçe planlaması, programlama vs. tüm etkinlikleri kapsayan belirgin bir risk yönetim planı olmadığı ve risklerin acil durumlara göre bireysel tecrübeler ve çabalar ile giderildiğine değinilmiştir. Teklif edilen modelde, risklerin yönetilmesi için bir risk yönetim ve izleme planı oluşturulmuştur. Mevcut süreçte ÖYE/YE ile risk değerlendirilmesi yapılmaktadır. Ayrıca bütçe planlaması, programlamsı vb. yönelik değerlendirmeler projelerin kilometre taşları olarak belirlenen zamanlarda yapılmaktadır. Ancak risk yönetim planının tedarik süreci boyunca tüm aşamalar için geliştirilerek izlenebilirliğinin sağlanması faydalı olacaktır. 6 - TSK nin tedarik sürecinde alım talebinin hazırlanması, tekliflerin değerlendirilmesi, yüklenici seçimi gibi önemli faaliyetler MSB içindeki ilgi makamlar tarafından icra edildiğine değinilerek teklif edilen modelde tüm etkinliklerin proje bürosu tarafından yürütülmesi gerektiği belirtilmiştir. Mevcut süreçte ihtiyaç sahibi makam, teknik ve taktik destek sağlayacak şekilde sürecin her aşamasında yer almakta ve proje yöneticisinin görevleri proje yönetimin her aşamasında ayrıntılı olarak verilmiştir. 86

96 4. MEVCUT TEDARİK SÜRECİNİN SA CMM SEVİYE-2 YE GÖRE ANALİZİ Gelişmiş ülkelerin silahlı kuvvetlerinde de ihtiyaçlar PPBS ve proje yönetim faaliyetlerine benzer bir planlama süreci ile sağlanmasına rağmen özellikle yazılım sistemlerinin geliştirilmesi ve projelendirilmesinde başarılı sonuçlara ulaşılabilmesi için CMM/CMMI gibi süreç bazlı yazılım geliştirme olgunluk modellerinin kullanılması istenilmektedir. TSK nin yazılım sistemlerinin tedarikinde organizasyonel kalite standartları ISO 9001: 2000 ve AQAP 160 a göre sistem geliştirilmesi istenmektedir. Bu bölümde mevcut tedarik faaliyetleri, süreç bazlı yazılım tedarik olgunluk modeli SA CMM Seviye-2 ye göre ilgi yönergeler gereği sözleşme imzalanmadan önce ve sonra gerçekleştirilecek faaliyeler kapsamında firma,kurum ve kuruluşlarla paylaşılan veriler ışığında bireysel olarak değerlendirilip, yazılım projelerinin başarılı sonuçlanmasında arzu edilen SA CMM Seviye-3 e ulaşılması için ilk aşamada sahip olunması gereken alt yapı özellikleri belirlenmeye çalışılmıştır. Bu kapsamda, mevcut tedarik sürecinin SA CMM Seviye- 2 ye göre ayrıntılı değerlendirmesi EK 1 de verilmiştir. Yazılım sistemi geliştirmek için seçilecek firmanın, beklentileri karşılayacağına emin olabilmek için en az temel yazılım geliştirme süreçlerini içeren 2 nci olgunluk düzeyinde olması gerekmektedir. Seviye-2 den başlayan CMM değerlendirilirmesinde anahtar süreç alanları ve ortak özellikler incelenmektedir. Her anahtar uygulama için %80 üstü geçer, altı kalır olarak değerlendirilmektedir (Yücalar 2006). Daha önce yapılan çalşmalarda 2007 öncesi tedarik sürecinin SA CMM Seviye-2 özelliklerini karşılamadığı belirtilerek, yeni tedarik modelleri önerilmiştir (Bilir 2002, Katar 2006, Gürkan 2007). Mevcut süreçte yapılan iyileştirmeler sonucunda tedarik süreci SA CMM ye göre değerlendirildiğinde Seviye-2 yi (Tekrarlanabilirlik) karşıladığı tespit edilmiştir. Anahtar süreç alanlarının genel olarak var olduğu, ancak bazı süreç alanlarının uygulanmasında eksikliklerin bulunduğu, bazılarının ise kurumun yapısı gereği uygulanabilir olmadığı görülmüştür. Mevcut tedarik süreci ile Tekrarlanabilirlik Seviyesi için gerekli alt yapının oluşturulduğu değerlendirilmektedir. 87

97 Mevcut süreçte Seviye-2 anahtar süreç alanındaki tespit edilen eksiklerin giderilmesi ve en önemlisi süreç alanları ölçüm verilerinin belirlenerek, Bilgi Sistemlerinde bu konu ile ilgili modüllerin geliştirilmesi ile projelerin izlenebilirliği sağlanabilecektir. Seviye-2 anahtar süreç alanlarına göre mevcut süreçte geliştirilmesi faydalı görülen hususlar aşağıda özetlenmiştir. Başarım Kararlılığı(Taahhüt): Tekrarlanabilirlik seviyesinde tüm anahtar süreç alanları için olması gereken ilk taahhüt yapılacak faaliyetleri tanımlayan yazılı bir kurum politikasının olması mevcut tedarik sürecinde genel olarak vardır. Ancak sözleşme isterleri PTD ve ÖYE/YE lerindeki verilerden faydalanarak oluşturulmakla birlikte, bu konuda daha ayrıntılı yazılı bir politika geliştirilmesinin faydalı olacağı değerlendirilmektedir. İkinci taahhüt deneyimli kişilerden oluşan sorumlu personelin olması, mevcut süreçte getirilen önemli bir iyileştirme adımıdır. Ancak sistemi kişilerden bağımsız hale getirebilmek için faaliyet alanlarına göre farklı kişilerin sorumlu olacağı uzmanlaşmaya daha fazla önem verilerek, kurumsallaşmanın geliştirilmesinin faydalı olacağı değerlendirilmektedir. Beceri: SA CMM Seviye-2 nin tüm anahtar süreç alanlarının beceri gereği belirtilen ekip, mevcut süreçte bir çok faaliyetin gerçekleştirilmesinden sorumlu olan proje ekibi ile sağlanmaktadır. Yeterli kaynaklar ise programlama faaliyetleri sonucunda yayımlanan OYTEP ile belirlenip, Bütçeleme faaliyetleri ile uygulanmaktadır. Tedarik planlaması için tedarik yönetimi konusunda tecrübeli personelin sağlanabilmesi için göreve atanan personelin gerekli eğitim almış ve uzun süre aynı görevde kalması için çalışılmaktadır. Etkinlikler: Tekrarlanabilirlik seviyesi anahtar süreç alanlarında belirtilen etkinlikler kapsamında, faaliyetler belgelenmiş plan ve prosedürler kapsamında genel olarak gerçekleştirilmektedir. TSK de yazılım ve sistem bir bütün olarak tedarik edilmektedir. Ancak tedarik faaliyetlerinin gerçekleşmesinde yaşanan sıkıntıların nerden kaynaklandığı geç görülmesinin önlenmesi için proje yönetim süreci aşamalarında yürütülecek faaliyetler; yapılacak gözden geçirme toplantıları ve her bir gözden 88

98 geçirmede onaya tabi dokümanlar ile genel hatları ile belirlenerek yazılım ve donanım olarak ayrılmıştır (HKY (A)). Yapılabilirlik Etüdünde (YE) maliyet kestirimleri yer almaktadır. Ancak maliyet ve takvim kestirimlerinin bağımsız kişilerce gözden geçirilmesinin kurumun yapısı gereği uygulanabilir olmadığı değerlendirilmektedir. Sözleşme Doküman İsterleri Listesinde (SDİL); plan, prosedür ve faaliyetlerin tam, doğru ve etkin bir şekilde belirlenmesinin ve uygulanarak belgelenmesinin faydalı olacağı değerlendirilmektedir. Proje ekibince hazırlanan sözleşme isterlerinde oluşan değişiklikler üst yönetim ve kullanıcıların onayı ile uygulanmaktadır. Ancak değişikliklerin ürüne, performansa, mimariye, desteklenebilirliğe, sistem kaynaklarından faydalanmaya ve maliyet etkilerine göre değerlendirilerek, izlenebilirliğin sağlanacağı bir bilgi sisteminin geliştirilmesi daha faydalı olacaktır. Projelerin maliyet, takvim, kaynaklar ve teknik yönden belirli dönemlerde yapılan toplantılar ile gözlemlenmesi planlanmıştır. Bu verilerin kayıt edilerek izlenebilirliğin sağlandığı sistemden faydalanılarak, oluşabilecek risklerin incelenmesinin yararlı olacağı değerlendirilmektedir. Ölçümler: Mevcut süreçte, anahtar süreç alanında belirtilen ölçüm verilerini de içericek şekilde sistemin geliştirilmesi ile ürünün durumunun izlenebilirliğinin sağlanması ve süreç içinde iyileştirme yapılacak yerlerin belirlenmesinde faydalı olacağı değerlendirilmektedir. Doğrulamalar: Mevcut süreçte; ihtiyaçların projelendirilerek tedarik makamı ve modeli belirlenmesi aşamasından, sözleşmelerin imzalanması sonrasında sitemi envantere alınıncaya kadar yürütülecek tüm faaliyetler üst yönetim ve proje yöneticileri tarafından gözden geçirilmektedir. Bu dokümanların izlenebilirliğinin sağlanması üst yönetim ve proje yöneticilerin yapacakları incelemeleri daha kolaylaştıracaktır. 89

99 Bu tez kapsamında, Seviye 2 nin ötesine geçilerek 3, 4 ve 5. seviyeler için çalışma başlatılması öngörülmemiştir. AQAP-160 ve ISO 9001:2000 standartlarını kullanan TSK de mevcut süreç ile getirilen iyileştirmeler sayesinde SA CMM Seviye 2 ye ulaşılabildiği ve yukarıda belirtilen Seviye 2 eksiklerinin ise gerçekçi olarak karşılanabilecek nitelikte olduğu değerlendirilmektedir. SA CMM Seviye-2 (Tekrarlanabilirlik) ile kurumsallaşma için gerekli olan planlama, kontrol, dokümantasyon ve izlenebilirlik faaliyetleri sağlanacağından, SA CMM Seviye-3 e (Tanımlı) ulaşılması için gerçekleştirilmesi gerekecek süreç çalışmaları daha kolay ve daha kısa sürede yerine getirilebileceği değerlendirilmektedir. 90

100 5. SONUÇ VE ÖNERİLER Dünyada teknolojinin hızlı bir şekilde gelişmesi ile birlikte yazılım yoğunluklu sistemler farklı alanlarda yaygın olarak kullanılmaya başlanmıştır. Yüksek teknolojiye sahip sistemler, karmaşık yazılımlar sayesinde çok fonksiyonlu olarak yönetilebilmektedir. Bu sistemlerin sağladığı verimlilik ve etkinlik artışı, ülkelerin ekonomik ve sosyal yapılarını doğrudan etkilemekle birlikte güvenilir, kullanışlı ve etkin yazılımların geliştirilmesinin önemi her geçen gün daha da artmaktadır. Yazılım üretimi, yazılımın kendi özellikleri nedeniyle diğer mühendislik alanlarından farklılık gösterir. Diğer mühendislik alanlarına kıyasla daha kısa bir geçmişi olan yazılım mühendisliğinde edinilen tecrübeler, yazılım geliştirmede yaşanan ana problemlerin teknik problemlerden değil yönetimsel problemlerden kaynaklandığı ve yazılım sistemlerinin başarısının ürün odaklı yaklaşımdan ziyade süreç odaklı yaklaşımla sağlanabileceğini göstermiştir. Bu kapsamda yazılım geliştirmek için çeşitli yazılım süreç modelleri (Şelale (Waterfall) Modeli, Prototip Model ve Spiral Model) geliştirilmiştir. Bir yazılım projesinde hangi süreç modelinin kullanılacağı; projenin içeriğine, kurumun politikasına ve önceki tecrübelere göre değişebilmektedir. Ayrıca yazılım geliştirilecek ürünün ya da hizmetin belirlenen gereksinimleri, güvenilirliği, benzer veya farklı sistemlerle birlikte çalışabilirliği, anlaşılabilirliği ve bakım kolaylığını sağlayabilmek için yazılım proje yönetiminde çeşitli kalite standartları ve olgunluk modelleri geliştirilmiştir. Uluslararası kabule sahip bu standartlardan ve modellerden en yaygın kullanılan; ISO/IEC (Yazılım Yaşam- Döngüsü Süreçleri) Standardı, yazılım süreçlerinin değerlendirilmesi ve iyileştirilmesi konularında geliştirilen CMM (Yetenek Olgunluk Modeli), CMMI (Tümleşik Yetenek Olgunluk Modeli), ISO 9001 ve AQAP-160 dır. Her biri farklı dönemde çıkan ihtiyaçları karşılamak için geliştirilen bu modellerin hangi koşullarda en iyi verimi sağlayacağını bilmek ve bize uygun modeli seçerek kendi organizasyon yapımıza uyarlanması ile kaliteli ve etkin yazılım sistemleri geliştirilebilmektedir. 91

101 Farklı alanlarında (Elektronik, Makine, Endüstri, İnşaat, Tıp vb) ihtiyaçları karşılamak için geliştirilen sistemlerin büyük bir kısmı yazılım ile birlikte bir bütün olarak fonksiyonelliği sağlamaktadır. Bu çalışma kapsamında; Uluslararası Elektrik Elektronik Mühendisliği Enstitüsü (IEEE) nde yayımlanan çeşitli kaynaklar ve daha önce yapılan tez çalışmalarının incelenmesi sonucunda, yazılım yoğunluklu sistemlerin geliştirme ve satın alma süreçlerinin, planlanan sürede, belirlenen maliyetleri aşmadan, başarılı ve etkili bir şekilde gerçekleştirilebilmesinin; a. Kurumun ve sistemin yapısına uygun olarak seçilecek yazılım süreç modellerinden (şelale modeli, prototip model, spiral model vb.) biri izlenerek mühendislik çalışmalarının(gereksinim analizi, tasarım, kod ve test vb.) yapılmasının yanısıra proje yönetimi, risk yönetimi, destek aktiviteleri vb. içeren yazılım kalite standartları/olgunluk modellerinin kullanılması, b. Kalite yönetim sistemi gereklerini karşılayan organizasyonel modellerinin (ISO 9001:2000 ve AQAP 160), uygulamaya ilişkin etkinlik ve detayı tanımlayan süreç bazlı modeller (CMM/CMMI) ile birbirlerini tamamlayacak şekilde birlikte kullanılması ile sağlanabileceği sonucuna ulaşılmıştır. Savunma sanayii alanında yazılım yoğunluklu yüksek teknolojili sistemler kullanılmakta olup, sivil sektörde kullanılanlardan farklı olarak daha fazla güvenlik ve gizliliğin yanısıra, oldukça uzun bir zaman periyodunda kullanılması gerekmektedir. Ülkelerin sahip olduğu yüksek teknoloji, caydırıcılığın yanı sıra uluslararası rekabet ortamında söz sahibi olmalarını sağlamaktadır. Türkiye de üzerinde bulunduğu jeopolitik konum itibarı ile caydırıcılığını korumak ve geliştirmek zorundadır. Türkiye için gerekli savunma sistemlerinin tedarik edilmesi ve geliştirilmesi Türk Silahlı Kuvvetleri (TSK) nin görevidir. TSK de ihtiyaç duyulan sistemler, PPBS süreci sonunda projelendirilerek, belirlenen tedarik makamı ve modeline göre temin edilmektedir yılında yayımlanan TSK Planlama, Programlama ve Bütçeleme Sistemi Yönergesi (MY 369-1) ile önceki süreçte yaşanan sıkıntılları giderecek önemli iyileştirmeler yapılmıştır. Ancak TSK nin özellikle kritik, gizli ve üstü gizlilik dereceli konularda; geliştirilmesi ve tedarik edilmesi planlanan yazılımların, milli olması ve uluslararası standartlara dayandırılması, TSK nin olgunluk seviyesini arttırması projelerden beklentilerin sağlanması açısından önemlidir. Bu kapsamda dünyada yazılım projelerinde yaşanan tecrübelerden faydalanarak geliştirilmiş yazılım proje 92

102 yönetim kalite standartları ve olgunluk modellerinin, TSK nin kendi kurumsal yapısına uygun olacak şekilde benimsenerek kullanılması ile henüz TSK de yaşanmamış ama yaşanabilecek aksaklıkları ve eksiklikleri önleyerek, yazılım projelerinde hedeflenen başarılı sonuçlara ulaşması sağlanabilecektir. Bu tez çalışması ile 2007 öncesinde ve sonrasında uygulanan tedarik süreçleri daha önce yayımlanmış çalışmalar ve OYTEP in sanayiye açılması kapsamında firma, kurum ve kuruluşlarla paylaşılan veriler ışığında incelenerek, sağlanan kazanımlar genel olarak verilmiştir. Mevcut süreç yayımlanmadan önce yapılan Hava Kuvvetleri Ana Savunma Sistem Tedarikinde Proje Yönetimi (Gürkan 2007) doktora tezi çalışmasında, uluslararası çalışmalarda proje uygulamalarında zaman, bütçe aşımı, performans vb. karşılaşılan problemlerin ortaya çıkma sebepleri mevcut uygulamada ve literatür araştırmaları ile belirlendikten sonra bunların sıklık oranı ve etkileri tespit edilerek, öncelikli önlem alınacak hususlar ortaya konulmuştur. Değinilen çalışma sonucunda en önemli unsurun proje yöneticisinin projedeki varlığı olduğu ortaya çıkmış, proje yöneticisinin sahip olması gereken özellikler verilmiştir. Söz konusu çalışma kapsamında, Türk Hava Kuvvetlerinin tedarik sistemi incelendikten sonra elde edilen verilerden yaralanılarak, yazılım yoğunluklu sistemlerin tedariğinde uygun olacağı değerlendirilen, SA-CMM ye bağlı tekrarlanabilen faaliyetlere dayalı bir olgunluk modeli teklif edilmiştir yılı öncesindeki TSK nin tedarik sürecindeki eksikleri giderebilmek için önerilen modelin sağlayacağı faydalar, mevcut tedarik sürecindeki yapılan iyileştirme çalışmalarında farklı uygulamalar ile sağlandığı belirlenmiştir. Projelerin başarıyla tamamlanabilmesi için en az SA CMM Seviye-2 (Tekrarlanabilir) özelliklerini sağlaması istenmekte, ancak uluslararası alanda idealde ulaşılması istenen SA CMM Seviye-3 (Tanımlı) olgunluk düzeyidir. Bu kapsamda, bu tez çalışması ile mevcut tedarik süreci SA CMM Seviye-2 ye göre bireysel olarak değerlendirildiğinde, Seviye-2 olgunluğunu sağlayacak alt yapıya büyük bir oranda ulaşıldığı, ancak Seviye- 3 için çalışmaya başlamadan önce Seviye-2 de tamamlanması veya geliştirilmesi faydalı olacağı değerlendirilen öneriler gerçekçi biçimde ortaya konulmuştur. 93

103 Mevcut süreçte, tedarik makamı ve modeline göre yürütülen faaliyetlerin anahtar süreç alanlarında belirtilen ölçüm verilerine göre kaydedilerek izlenebilirliğinin sağlanması ile süreç içinde iyileştirmeye ihtiyaç duyulacak yerlerin belirlenmesi, değişikliklerin izlenmesi ve sorunlara getirilen çözüm yöntemlerinin görülebilmesini sağlayacaktır. Böylece planlanan ve gerçekleşen arasında farklar görülerek yeni projelerin daha iyi yapılabilmesi için önemli bir bilgi bankası oluşturulacak, bir projede karşılaşılan sorunlara bulunan çözümlerden başka projelerde faydalanılabilecek ve yeni görevlendirilen kişilerin kısa sürede görevlerini verimli ve etkin bir şekilde yapmaları sağlanacaktır. Daha önce yapılan çalışmaların aksine, mevcut süreç SA CMM e göre değerlendirildiğinde Seviye-2 yi (Tekrarlanabilirlik) yüksek oranda sağladığı, Seviye- 3 e ulaşılabilması için gerekli çalışmaların yapılabileceği görülmüştür. TSK de yazılımlar sistem içinde bir bütün olarak tedarik edildiğinden, bu çalışmaların CMMI a göre sürdürülmesinin faydalı olacağı değerlendirilmiştir. Böylece günümüzde farklı alanlarda (elektronik, makine, haberleşme vb.) uygulamalar için geliştirilen yazılım ağırlıklı sistemlerin kullanımına ve satın alınmasına yönelik bir iyileştirme önerisi yapılmış olmaktadır. Bu tezin teknolojiye bu katkısı, TSK ve savunma sanayiindeki birçok kuruluş için uygulanmak üzere genelleştirilebilir niteliktedir. İdeal durum tedarik ve yüklenici makamın birlikte yüksek olgunluk seviyesine sahip olmasıdır. Bu kapsamda Türk Savunma Sanayiisindeki yazılım firmalarının ve TSK nin, yazılım süreç modellerini kendi kurumsal yapılarına uyarlayarak belli bir olgunluk seviyesine sahip olmaları ve olgunluk seviyesini arttırıcı çalışmaları yürütmelerinin milli yazılım geliştirilmesinde ve kaliteli sistemler üretilmesinde olumlu katkılar sağlayacağı değerlendirilmektedir. 94

104 KAYNAKLAR Anonim Web Sitesi: universitesi- arasinda-haberi, Erişim Tarihi: 11/09/2009 Anonim Web Sitesi: php, Erişim Tarihi: 11/12/2009 Anonim Web Sitesi: Erişim Tarihi: 11/12/2009 Anonim Web Sitesi: Erişim Tarihi: 11/12/2009 Anonim Web Sitesi: Erişim Tarihi: 01/01/2010 Anonim Web Sitesi: Erişim Tarihi: 01/01/2010 Anonim Web Sitesi: Erişim Tarihi: 01/01/2010 Anonim Web Sitesi: Erişim Tarihi: 01/01/2010 Anonim Web Sitesi: NT_163 Erişim Tarihi: 01/01/2010 Anonim Web Sitesi: Erişim Tarihi: 01/01/2010 Anonim Web Sitesi: Erişim Tarihi: 01/01/2010 Aydoğdu, Ö Yazılım Süreç Modellerinin Değerlendirilmesi.Yüksek Lisans Tezi, Hava Harp Okulu Havacılık ve Uzay Teknolojileri Enstitüsü,İstanbul. Aykol, M Yazılım Süreç İyileştirme Modelleri ve Proje Yönetimi.TBD,İstanbul Üniversitesi,İstanbul.( 2005duyuru/ TBD-Ist.Univ.ppt)( ) AQAP-160 Integrated Qualıty Requirements for Software Througout the Life Cycle, July 2001 Bellini, E. and Storto, C CMM Implementation and Organizational Learning: Findings from a Case Study Analysis, IEEE Computer Society Press. 95

105 Bilgen, S Yazılım Satınalma, Ders Notu.ODTU, Ankara Bilir, N Kara Kuvvetleri Komutanlığı Yazılım Yoğunluklu Sistem Tedarik Süreci İçin Bir Teklif. Yüksek Lisans Tezi, ODTU Bilgi Sistemleri Bölümü,Ankara Birant, K. U Yapabilirlik Olgunluğu Modeli(Capability Maturity Model (CMM)),Dokuz Eylül Üniversitesi Bilgisayar Mühendisliği Bölümü,Compotek 03 sunum,izmir. Bollinger, T. and McGowan, C A Critical Look at Software Capability Evaluations: An Update, IEEE Computer Society Press. CMU/SEI-2004-TR-001, CMMI Acquisition Module (CMMI-AM), February CMMI for Acquisition, Version 1.2,November 2007 Demirörs, E Yazılım Kalite Yönetimi: TS ISO/IEC SSM.lığı SATEM Eğitim Notu, Ankara/ Dülgar, S Yetenek Olgunluk Modellerinin Milsoft Firması ndaki Uygulamaları, Sözlü Mülakat, Ankara. Ferguson, J. and Sheard, S Leveraging Your CMM Efforts for IEEE/EIA 12207, IEEE Software. Fisher, M. J., Goethert, W. B. and Jones,L.G Applying the Software Acquisition Capability Maturity Model, Crosstalk, fisher.pdf Galin, D. and Avrahami, M Are CMM Program Investments Beneficial? Analyzing Past Studies, IEEE Computer Society Press. Gürkan, H Hava Kuvvetlerinin Ana Savunma Sistem Tedarikinde Proje Yönetimi. Doktora Tezi, Ankara Üniversitesi Elektronik Mühendisliği Bölümü, Ankara HKY (A) Hava Kuvvetleri Planlama Programlama ve Bütçeleme Uygulama Sistemi (PPBUS) Yönergesi Kalıpsız, O Yazılım Proje Yönetimi Dokümanı, : Erişim Tarihi:( ) Kalıpsız, O Yazılım Mühendisliği, Erişim Tarihi:( ( ) Kalaycı, O Savunma Sanayii Satın Alma Süreçlerinde Reform SAVTEK

106 Kalaycı, O Yöneticiler için Doğru Sorular CMMI. Erişim Tarihi: 01/01/2010 Katar, Z Kara Kuvvetleri Komtanlığı na Yazılım Sistemleri Tedariki İçin Yeni Bir Yaklaşım. Yüksek Lisans Tezi, Selçuk Üniversitesi, Konya. Kutluay, G Yetenek Olgunluk Modellerinin TAI A.Ş. Firması ndaki Uygulamaları, Sözlü Mülakat, Ankara. Paulk, M. C.,Weber, C. V., Curtis, B. and Chrıssıss, M. B The Capability Maturity Model: Guidelines for Improving the Software Process, Addision Wesley, U.S.A. and Canada. Mihalsky, J ISO 9000 The Latest Wonder Drug to Solve The Quality Problem and Improve Global Competitiveness, IEEE Software. MY Planlama Programlama ve Bütçeleme Sistemi (PPBS) Yönergesi Sarıdoğan, E Yazılım Mühendisliği. Papatya, İstanbul. Sen, Z. and Zheng, Y The Relation of CMM and Softwave Lifecycle Model IEEE Computer Society. Standartlar Belgelendirme Ltd. Şti.Etkin Süreç Yönetimi ve ISO 9001: Special Report CMU/SEI-97-SR-013, Software Acquisition Process Maturity Questionnaire, Tatlı, A SSM için Yazılım Yetenek Olgunluk Modeli.Uzmanlık Tezi, Savunma Sanayii Müsteşarlığı, Ankara. TBD Kamu-BİB Kamu Bilişim Platformu X Bütünleşik Yetenek Olgunluk Modeli (CMMI- Capability Maturity Model Integration) Sürüm 1.0, TBD/Kamu-BİB/2008-ÇG1. The Standish Group Reports 1999 Tuluk, A Yazılım Yetenek Olgunluk Modeli (SW-CMM) ile Yazılım Süreç İyileştirme ve Yetenek Belirleme Modeli (ISO 15504) Arasındaki Farklılıkların Belirlenmesi.Yüksek Lisans Tezi, Hava Harp Okulu Havacılık ve Uzay Teknolojileri Enstitüsü, İstanbul. Uzunalioğlu, A Yetenek Olgunluk Modellerinin METEKSAN Sistem Firması ndaki Uygulamaları, Sözlü Mülakat, Ankara. 97

107 Yoo,C.,Yoon,J.,Lee,B.,Lee,C.,Lee,J.,Hyun,S. and Wu,C An Integrated Model of ISO 9001:2000 and CMMI for ISO Registered Organizations, IEEE Computer Society Press, Yücalar, F Süreç Odaklı Kalite Yönetimi Anlayışına Hakim Yazılım Sektöründeki Firmaların CMMI Basamaklı Modeli ile Değerlendirilmesi, Maltepe Üniversitesi, İstanbul. 98

108 EK 1 Mevcut Tedarik Sürecinin SA CMM Seviye-2 ye Göre Analizi Bu çalışmada tedarik süreci kapsamında firma, kurum veya kuruluşlara yaptırılan ÖYE/YE ve hazırlanacak sözleşmelerin içeriğinde olması gereken faaliyetlere göre firma, kurum ve kuruluşlarla paylaşılan bilgiler ışığında inceleme yapılmıştır. Bu amaçla uygulamaların yapılabilirliği Y ile değerlendirilirken, kullanılan kısaltmaların açıklamaları aşağıda verilmiştir. :Uygulamanın mevcut yönergelerde belirtildiği ve yerine getirilmekte olan faaliyetler için kullanılmıştır. / :Uygulamanın bir kısmı vardır. Ancak belirtilen uygulamamnın tam olarak yapılabilmesi için bazı ilave çalışmalara ihtiyaç duyulmaktadır. UD :Kurumun yapısı gereği uygulanabilir olmayan faaliyetlerdir. (-) :Uygulaması mevcut olmayan geliştirilmesi gereken faaliyetler için kullanılmıştır. Tekrarlanabilir Düzey 1. Tedarik Planlaması - Hedefler: H1:Tedarik planlarının hazırlanması ve tedarik süreci boyunca güncel tutulması, H2:Tedarik planlamasının projenin ve alınan ürünlerin tüm yaşam çevrimi boyunca geçerli olması, -Başarım Kararlılığı: BK1:Tedarik planlaması için yazılı politikanın varlığı, BK2: Tedarik planlaması sorumlularının belirlenmiş olması, -Beceri: B1:Tedarik planlaması ekibinin varlığı, B2:Tedarik planlaması için gerekli kaynağın ayrılmış olması, B3:Tedarik planlaması için tedarik yönetimi konusunda tecrübeli personelin sağlanmış olması, -Etkinlikler: E1:Yazılım tedarik planlamasından sorumlu personel sistem satın alma planlama faaliyetlerine de katılması, E2:Yazılım ve sistem tedarik planlaması bağlantılı olarak gerçekleştirilmesi, Y 99

109 E3:Projenin tedarik stratejisi geliştirilmesi ve dokümante edilmesi, E4:Tedarik planlama sürecinin tüm öğelerinin göz önüne alması (ör. Risk belirleme ve izleme, proje yönetimi, teklif alımı, büyüklük kestirimleri, isterler, sözleşme yönetimi, değerlendirme, bakım ve destek, vb.) E5:Tedarik planı dokümante edilerek, proje süresince güncel tutulması, E6:Tedarik planında ürünün yaşam çevrimi desteğinin göz önüne alınması, E7:Ürünün yaşam çevrimi boyunca maliyet kestirimlerinin hazırlanması ve bağımsız kişilerce gözden geçirilmesi, -Ölçümler: Ö1: Ölçümler yapılarak TP faaliyetlerinin ve sonucunda ortaya çıkan ürünün durumunun belirlenmesi için kullanılır. -Doğrulama: D1:TP faaliyetleri tedarik kurumu üst yönetimi tarafından periyodik olarak gözden geçirilir. D2:TP faaliyetleri proje yöneticisi tarafından periyodik ve olay bazlı olarak gözden geçirilir. 2. Teklif İsteme (İhale Hazırlığı ve Sonuçlandırma) - Hedefler: H1:Sözleşme gereklerini ve değerlendirme kriterlerini içeren bir ihale paketinin hazırlanması, H2:Tekliflerin hem teknik hem de idari yönden sözleşme gereklerini yerine getirebilme durumuna göre değerlendirilmesi, H3:Sözleşme gereklerini yerine getirebilecek olan yüklenicinin seçilmesi, -Başarım Kararlılığı: BK1:Teklif isteme politikasının yazılı biçimde bulunması, BK2:Teklif isteme sorumlusunun belirlenmiş olması, BK3:Proje ekibinin sözleşme yönetimi deneyimine sahip kişileri de içermesi -Beceri: B1:Teklif alma işini yürüten bir grubun varlığı, B2:Yeterli kaynağın sağlanmış olması, B3:Teklif alma sorumlularının deneyimli ya da gerekli eğitimleri almış olması, B4:Teklif alma sorumlularının, bu sürecin hedef ve yöntemlerine ilişkin olarak yönlendirilmiş olmaları, -Etkinlikler: E1:Faaliyetlerin dokümante edilmiş plan ve yöntemlere göre yürütülmesi, E2:Teknik-idari, ürün ve teklif değerlendirme isterlerine ihale paketinde ve sözleşmede yer verilmesi, E3:Ürüne ilişkin maliyet ve takvim kestirimlerinin hazırlanması, E4:Maliyet ve takvim kestirimlerinin bağımsız kişilerce gözden geçirilmesi, E5:Tekliflerin yazılı planlar uyarınca değerlendirilmesi, E6:İhaleyi kazanacak teklif sahibinin teklif değerlendirmesi doğrultusunda belirlenmesi, E7:Proje ekibince, sözleşme imzası öncesinde, yüklenici ile kullanıcı arasında sözleşme gereklerinin karşılıklı olarak doğru anlaşılmasının sağlanması, UD / UD 100

110 -Ölçümler: Ö1:Ölçümler İhale hazırlığı ve sonuçlandırma faaliyetleri ve ürününün durumunun belirlenmesi için kullanılır. -Doğrulama: D1: Üst yönetim periyodik gözden geçirmeleri D2: Proje yöneticisi periyodik ve olay bazlı olarak gözden geçirmeleri. 3.Gereksinimler(İsterler)Geliştirme ve Yönetimi - Hedefler: H1:Sözleşme isterlerinin geliştirilmesi, yönetimi ve güncel tutulması, H2:Kullanıcılar ve diğer ilgililerin proje süresince isterler konusunda girdi sağlayabilmesi, H3:Sözleşme isterlerinin izlenebilir ve doğrulanabilir olması, / H4:Sözleşme isterlerine ilişkin ana hattın, teklif isteme paketinin dağıtılmasından önce tamamlanmış olması, -Başarım Kararlılığı: BK1:Sözleşme isterlerinin saptanmasına ve yönetimine yönelik yazılı bir politikanın varlığı, / BK2: İsterler geliştirme ve yönetimi sorumlularının belirlenmiş olması, -Beceri: B1: Sorumlu ekibin varlığı, B2: Yeterli kaynağın tahsis edilmiş olması, B3: Sorumlu kişilerin yeterince deneyimli olması ya da gerekli eğitimleri almış olması, -Etkinlikler: E1:Faaliyetlerin dokümante edilmiş isterlerin gelişimi ve yönetimi plan ve prosedürlerine göre yürütülmesi, E2:Proje ekibinin, sözleşme isterlerini geliştirmesi, bunlara ilişkin başlangıç noktalarının belirlemesi, isterleri güncel tutması ve teklif isteme paketinin dağıtılması öncesinden başlayarak değişim denetimi altında bulundurması, E3:Sözleşme isterlerinde değişikliklerin tedarik edilecek ürüne etkilerine göre incelenmesi, E4:Tüm değişikliklere; performansa, mimariye, desteklenebilirliğe, sistem kaynaklarından faydalanmaya, değerlendirme gereklerine ve maliyet etkilerine göre bir değer verilir. E5:Sözleşme isterleriyle sunulan ürünler arasındaki uyumluluğun proje süresince denetlenmesi, E6:Sözleşme isterlerinin geliştirilme ve güncel tutulmalarında tüm ilgililerin katkıda bulunmaları, -Ölçümler: Ö1: Ölçümler Gereksinimlerin Gelişimi ve Yönetimi faaliyetlerinin ve ürününün durumunun belirlenmesi için kullanılır. -Doğrulama: D1: Üst yönetim periyodik gözden geçirmeleri, D2: Proje yöneticisi periyodik ve olay bazlı olarak gözden geçirmeleri, 4.Proje Yönetimi / / / / 101

111 - Hedefler: H1: Proje yönetimi etkinliklerinin planlı, örgütlü, denetimli ve açık biçimde gerçekleştirilmesi, H2: Projesinin başarımının, maliyetinin ve takviminin tedarik süresince düzenli olarak izlenmesi, hedeflerle karşılaştırılması ve kontrolün sağlanması, H3: Tedarik sürecinde oluşan sorunların yönetilmesi ve denetlenmesi, -Başarım Kararlılığı: BK1: Projenin gerçekleştirilmesine ilişkin yazılı bir politikanın varlığı, BK2: Proje yönetimi sorumluluğunun tanımlanmış olması, -Beceri: B1: Tedarik yönetimi ekibinin varlığı, B2:Tedarik projesi süresince yeterli kaynak tahsisatının yapılmış olması, B3: Proje ekibinin yeterli birikime sahip ya da eğitim almış olması, -Etkinlikler: E1:Proje ekibinin dokümante edilmiş proje yönetimi planı ve yöntemine göre çalışması, E2:Proje fonksiyonlarına ilişkin roller, yetki ve sorumlulukların belgeli, güncel ve ilgililerin bilgisine açık tutulması, E3:Yükümlülüklerin ve bunlardaki değişikliklerin ilgililere bildirilmesi, E4:Maliyet, takvim, kaynaklar ve teknik yönlere ilişkin risklerin izlenmesi, / E5:Proje konularının, parasal kaynakların ve harcamaların planlarla karşılaştırılması ve bunlara ilişkin gerekli işlemlerin gerçekleştirilmesi, E6:Satınalma sürecinde saptanan sorunların kaydedilmesi, izlenmesi ve çözümüne yönelik önlemlerin gerçekleştirilmesi, / E7:Proje süresince planların güncel tutulması, -Ölçümler: Ö1:Ölçümler Proje Yönetim faaliyetlerinin ve ürününün durumunun belirlenmesi için kullanılır. -Doğrulama: D1: Üst yönetim periyodik gözden geçirmeleri. D2: Proje yöneticisi periyodik ve olay bazlı olarak gözden geçirmeleri. 5. Sözleşme İzleme ve Yönlendirme - Hedefler: H1:Proje ekibinin; yüklenicinin yürüttüğü faaliyetleri sözleşme isterlerine uygun olarak yerine getirdiğine ve yönettiğine dair yeterli bir denetime sahip olması, H2:Proje ekibiyle yüklenici arasında sürekli iletişim kurulması ve yükümlülüklerin karşılıklı olarak kabul edilerek yerine getirilmesi, H3: Sözleşmedeki değişikliklerin sözleşme süresince yönetilmesi, -Başarım Kararlılığı: BK1: Yazılım satınalma örgütünün buna ilişkin yazılı bir politikaya sahip olması, BK2: Bu alandaki sorumluluğun belirlenmiş olması, BK3:Proje ekibinin sözleşme yönetiminde deneyim sahibi kişileri içermesi, -Beceri: B1:Sorumlu ekibin gerekli deneyime sahip, gerekli eğitimi alan kişileri içeren biçimde kurulmuş ve yeterli kaynaklarla donatılmış olması, 102

112 -Etkinlikler: E1:Faaliyetlerin dokümante edilmiş sözleşme izleme ve yönetimi planları kapsamında yürütülmesi, E2:Proje ekibi sözleşmenin izlenmesi ve yüklenici faaliyetlerini değerlendirirken gerekli gördüğü yüklenici planlarını belirli zamanlarda incelemesi, E3:Proje ekibinin düzenli gözden geçirmeler yapması ve bunları yüklenici ile paylaşması, E4:Yüklenicinin gerçekleşen bütçe ve takviminin planlananlarla karşılaştırılarak uyumsuzlukların tespit edilmesi, E5:Yüklenicinin ürüne ilişkin teknik etkinliklerinin izlenmesi, planlarla karşılaştırılması ve uyumsuzlukların tespit edilmesi, E6:Yüklenicinin ürüne ilişkin mühendislik çerçevesinin gözden geçirilmesi, izlenmesi ve sorunların saptanması (Ürüne ilişkin ömür boyu destek mekanizmasının kurulmasını sağlamak üzere yazılım mühendisliği ortamındaki gelişmeler izlenerek gözden geçirilir.) E7: Sözleşme izleme ve yönetimi sırasında belirlenen tüm sorunların proje ekibinin ya da yüklenicinin yönetim sistemine kaydedilerek çözüm sağlanana kadar izlenmesi, -Ölçümler: Ö1:Ölçümler Sözleşme İzleme faaliyetlerinin ve ürününün durumunun belirlenmesi için kullanılır. -Doğrulama: D1: Üst yönetimin periyodik gözden geçirmeleri, D2: Proje yöneticisi periyodik ve olay bazlı olarak gözden geçirmeleri, 6. Değerlendirme - Hedefler: H1:Değerlendirme isterlerinin, sözleşme isterleriyle birlikte geliştirilmesi ve tedarik projesi süresince güncel tutulması, H2:Değerlendirmelerin projenin tedarik süresince planlı biçimde gerçekleştirilmesi, H3:Değerlendirmelerin ürün kabülünü sağlayacak şekilde nesnel bir temel oluşturması, -Başarım Kararlılığı: BK1:Tedarik süresince değerlendirmelerin yönetimini yönlendiren yazılı bir politikanın varlığı, BK2:Sorumlulukların belirlenmiş olması, -Beceri: B1: Birikim sahibi ve eğitimli kişilerden oluşan bir değerlendirme ekibinin kurulmuş ve yeterli kaynaklarla donatılmış olması, -Etkinlikler: E1:Etkinliklerin yazılı plan ve yöntemler uyarınca yapılması, E2:Sözleşme isterleri ile birlikte proje değerlendirme isterlerinin hazırlanması, E3:Değerlendirme etkinliklerinin elden geldiğince, yüklenicinin değerlendirme çalışmalarını yinelemekten kaçınıp onlardan da yararlanacak biçimde planlanması, E4:Değerlendirmelerin gelişen ürünler üzerinde planlı bir şekilde yapılması, E5:Değerlendirme sonuçlarının kabul kararlarını desteklemek üzere analiz edilmesi ve sözleşme isterleriyle karşılaştırılması, -Ölçümler: / / 103

113 Ö1:Ölçümler değerlendirme faaliyetlerinin ve ürününün durumunun belirlenmesi için kullanılması, -Doğrulama: D1: Üst yönetim periyodik gözden geçirmeleri, D2: Proje yöneticisi periyodik ve olay bazlı olarak gözden geçirmeleri, 7. Destek Dönemine Geçiş - Hedefler: H1:Proje ekibinin, destek örgütünün destek sorumluluğunu üstlendiği zaman yeterli hizmet sağlayabilmesi için gerekli önlemleri alması, H2:Destek sorumluluğunun, yükleniciden destek örgütüne geçişi sırasında herhangi bir aksaklığın yaşanmaması, H3:Geçiş süresince ürünlerin konfigürasyon yönetiminin devam ettirilmesi, -Başarım Kararlılığı: BK1:Destek dönemine geçişe ilişkin yazılı politikanın varlığı, BK2:Destek dönemine geçiş planlamasına destek ekibinin katılımı için gerekli tedbirlerin sağlanması, BK3:Destek dönemine geçiş sorumluluğunun belirlenmiş olması, -Beceri: B1:Deneyimli ve eğitimli kişilerden oluşan, yeterli kaynaklarla donatılmış sorumlu bir ekibin varlığı, B2:Ürünlere bakım ve destek sağlayacak örgütün proje planlamasının erken aşamalarında belirlenmiş olması ve yaşam çevrimine ilişkin desteklenebilirlik konularının proje isterleri arasında yer alması, B3:Destek örgütünün, geçiş öncesinde, bütün ürünlere ilişkin destek için gerekli envantere (ör. Belgeler, destek yazılımı, konfigürasyon yönetim sistemleri) sahip olması, B4:Destek dönemine geçişle ilgili tüm kuruluşların bu dönemin gereklerine ilişkin bilgilendirilmesi, -Etkinlikler: E1:Tüm faaliyetlerin dokümante edilmiş desteğe geçiş plan ve prosedürleri kapsamında yapılması, E2:Ürün sorumluluklarının ancak destek organizasyonunun bakım ve desteği gereğince yapabileceği görüldükten sonra devredilmesi, E3:Proje ekibinin, geçiş dönemi süresince destek hizmetlerini aksamadan yürütülmesini sağlaması, E4:Proje ekibinin, geçiş süresince ürünlere ilişkin konfigürasyon yönetiminin yürütülmesini denetlemesi, -Ölçümler: Ö1:Ölçümler Desteğe Geçiş faaliyetlerinin ve ürününün durumunun belirlenmesi için kullanılır. -Doğrulama: D1: Üst yönetim periyodik gözden geçirmeleri, D2: Proje yöneticisi periyodik ve olay bazlı olarak gözden geçirmeleri, 104

114 ÖZGEÇMİŞ Adı Soyadı Doğum Yeri : Gülbahar GÜMRÜKÇÜ : İskenderun Doğum Tarihi : Medeni Hali Yabancı Dili : Bekar : İngilizce Eğitim Durumu (Kurum ve Yıl) Lise : Kocaeli 19 Mayıs Lisesi ( ) Lisans : Karadeniz Teknik Üniversitesi, Mühendislik Mimarlık Fakültesi Elektrik-Elektronik Mühendisliği Bölümü ( ) Yüksek Lisans : Ankara Üniversitesi, Fen Bilimleri Enstitüsü, Elektronik Mühendisliği Anabilim Dalı (Haziran 2010) Çalıştığı Kurum/Kurumlar ve Yıl Hava Kuvvetleri Komutanlığı (2002- ) 105