yazılım projelerinde proje yönetim süreçlerinin
advertisement
YAZILIM PROJELERİNDE PROJE YÖNETİM SÜREÇLERİNİN İNCELENMESİ KAPSAMINDA TÜRKSAT KABLO OPERASYONLARI DESTEK SİSTEMİ (KODSİS) VAKIA ANALİZİ Sosyal Bilimler Enstitüsü TOBB Ekonomi ve Teknoloji Üniversitesi FARUK SELMAN LEKESİZ Yüksek Lisans İŞLETME ANA BİLİM DALI TOBB EKONOMİ VE TEKNOLOJİ ÜNİVERSİTESİ ANKARA Temmuz 2013 İlkokula başladığım 1987 yılından beri beni sürekli okumaya teşvik eden, aldığım her yüksek nottan, başarılı olduğum her sınavdan gurur duyan, her karnemi, diplomamı gördüğünde bana bir sonraki okul hedefini göstererek motive eden, başarılarımı kendisine hayat kaynağı kabul eden ve hep çıtayı daha da yükseğe çıkaran değerli büyüğüm, Dedeme, İki yıllık MBA eğitimim boyunca kendisine ayırdığım vakitlerden feragat eden, akşamları okuldan eve geldiğimde çoğu zaman günün yorgunluğundan uyuyakalmış olan, okulumu başarılı bitireyim ve daha iyi yerlere geleyim diye iki oğlumuzun bütün yetiştirme yüklerini tek başına üstünde alan değerli insan, Eşime, Onay Sayfası Bu tezin Yüksek Lisans derecesi için gereken tüm koşulları yerine getirdiğini onaylarım. ________________________________________ Prof. Dr. Serdar Sayan Sosyal Bilimler Enstitüsü Müdürü Bu tezi okuduğumu ve kapsam ve içerik olarak Sosyal Bilimler Enstitüsü İşletme Ana Bilim Dalında bir yüksek lisans tezi olabilecek yeterlikte olduğuna kanaat getirdiğimi onaylıyorum. ________________________________________ Yrd. Doç. Dr. Hulusi Öğüt Tez Danışmanı Tez Etik Kurallar Uyum Beyan Sayfası Tez içindeki bütün bilgilerin etik davranış ve akademik kurallar çerçevesinde elde edilerek sunulduğunu, ayrıca tez yazım kurallarına uygun olarak hazırlanan bu çalışmada her türlü kaynağa eksiksiz atıf yapıldığını bildiririm. ________________________________________ Faruk Selman Lekesiz ÖZET YAZILIM PROJELERİNDE PROJE YÖNETİM SÜREÇLERİNİN İNCELENMESİ KAPSAMINDA TÜRKSAT KABLO OPERASYONLARI DESTEK SİSTEMİ (KODSİS) VAKIA ANALİZİ Lekesiz, Faruk Selman Yüksek Lisans, İşletme Bölümü Tez Yöneticisi: Yrd. Doç. Dr. Hulusi Öğüt Temmuz 2013 Bu çalışmada, proje ve yazılım proje yönetimi kavramları, yazılım projeleri yaşam döngüsü süreçleri ve araçları tartışılmış; örnek bir telekomünikasyon firmasına ait yazılım geliştirme süreçleri incelenmiştir. Anahtar Kelimeler: Yazılım Telekomünikasyon Bilişimi Projesi, Yazılım Proje Yönetimi, ABSTRACT REVİEWİNG SOFTWARE PROJECT MANAGEMENT LIFECYLE ON SCOPE OF TURKSAT CABLETV OPERATIONS SUPPORTING SYSTEM KODSİS CASE STUDY Lekesiz, Faruk Selman Master of Business Administration Supervisor: Assist. Prof. Hulisi Öğüt July, 2013 In this study, project and software project management concepts, application lifecyle management processes were discussed; on a model telecomunication firm software developing processes was studied. Keywords: Software Telecomunication IT Project, Software Project Management, İÇİNDEKİLER BİRİNCİ BÖLÜM ........................................................................................ xii GİRİŞ............................................................................................................ xii İKİNCİ BÖLÜM ............................................................................................xv PROJE YÖNETİMİ VE YAZILIM PROJELERİ ...........................................xv 2.1 2.3 Projenin Tanımı ...................................................................................xv 2.2.1 Proje Entegrasyon Yönetimi .....................................................xvi 2.2.2 Proje Kapsam Yönetimi ...........................................................xvi 2.2.3 Proje Zaman Yönetimi ............................................................ xvii 2.2.4 Proje Maliyet Yönetimi ........................................................... xvii 2.2.5 Proje Kalite Yönetimi ............................................................ xviii 2.2.6 Proje İnsan Kaynakları Yönetimi............................................ xviii 2.2.7 Proje İletişim Yönetimi ............................................................ xix 2.2.8 Proje Risk Yönetimi ................................................................. xix 2.2.9 Proje Tedarik Yönetimi ..........................................................xx Yazılım Projelerine Bakış ....................................................................xx ÜÇÜNCÜ BÖLÜM...................................................................................... xxii YAZILIM PROJE YÖNETİMİ YAŞAM DÖNGÜSÜ.................................. xxii 3.1 Yazılım Geliştirme Modelleri ........................................................... xxiii 3.1.1 Gelişigüzel Geliştirme ............................................................ xxiv 3.1.2 Barok Modeli ......................................................................... xxiv 3.1.3 Şelale (Waterfall) Modeli ....................................................... xxiv 3.1.4 Helezonik (Spiral) Model ...................................................... xxvii 3.1.5 Arttırımsal (Incremental) Geliştirme Modeli ........................ xxviii 3.1.6 Döngüsel Model ..................................................................... xxix 3.1.7 Çevik Yazılım Geliştirme Metodları........................................ xxx 3.2 Telekomünikasyon Bilişimi Kalitesi İle İlişkili Standartlar, Modeller, Organizasyonlar ......................................................................................... xxxii 3.2.1 ISO 9126 Yazılım Kalite Özellikleri...................................... xxxii 3.2.2 TmForum .............................................................................. xxxii 3.2.3 ISO 15504 Spice(Software Process Improvement and Capability Determination) .................................................................................. xxxiii 3.2.4 CMMI .................................................................................. xxxiv 3.2.5 SCRUM ............................................................................... xxxiv DÖRDÜNCÜ BÖLÜM ............................................................................ xxxvii VAKIA ANALİZİ: KODSİS .........................................................................xlii 4.1 Kodsis Projesi Hakkında .....................................................................xlii 4.2 Telekomünikasyon Bilişimi ................................................................. xliii 4.3 Mevcut Durum ...................................................................................xlv 4.4 4.3.1 Kodsis İlişki Ağı .................................................................... xlvii 4.3.2 Kodsis Organizasyon Yapısı ................................................. xlviii Kodsis Yazılım Geliştirme Süreçleri ................................................ xlviii 4.4.1 Gereksinimlerin Toplanması ................................................... xlix 4.4.2 Analiz ......................................................................................... l 4.4.3 Tasarım .................................................................................... liii 4.4.4 Test Senaryolarının Hazırlanması ............................................. liii 4.4.5 Yazılım Geliştirme ................................................................... liv 4.4.6 Test ve Doğrulama........................................................................ lv 4.4.7 Yaygınlaştırma .......................................................................... lv 4.4.8 Bakım ...................................................................................... lvi 4.4.9 Operasyon Destek .................................................................... lvi 4.5 Kullanılan Yardımcı Araçlar ...............................................................lvii 4.6 Ürün İyileştirme Çalışmaları .............................................................. lviii Sonuç ........................................................................................................... lxvi Ekler ............................................................ Hata! Yer işareti tanımlanmamış. Kaynakça ................................................................................................... lxviii SİMGELER VE KISALTMALAR LİSTESİ PMI : Project Management Institute SOW : Statement of Work Kodsis : Kablo Operasyonları Destek Sistemi WBS : İş Kırılım Yapısı TABLOLAR LİSTESİ TABLO 1 KODSİS İLİŞKİ AĞI ......................................................................... XLVİİ TABLO 2 ÖRNEK ETKİ ANALİZİ ................................................................................ Lİİ ŞEKİLLER LİSTESİ ŞEKİL 1 YAZILIM YAŞAM DÖNGÜSÜ VE HATA TESPİT MALİYETLERİ .............. Xİİİ ŞEKİL 2 ŞELALE MODELİ GELİŞTİRME......................................................... XXVİ ŞEKİL 3 SPİRAL MODEL GELİŞTİRME ......................................................... XXVİİ ŞEKİL 4 ARTIRIMSAL MODEL GELİŞTİRME .................................................. XXİX ŞEKİL 5 ÇEVİK MODEL GELİŞTİRME............................................................ XXXİ ŞEKİL 6 ÇEVİK GELİŞTİRME ZAMANA GÖRE DEĞİŞİM.................................. XXXİ ŞEKİL 7 ÖRNEK İŞ AKIŞ DİAGRAMI .................................................................. Lİ ŞEKİL 8 PROTOTİP EKRAN ÖRNEĞİ................................................................. Lİİİ ŞEKİL 9: SAHADA BÜYÜTEÇ ANKET SONUCU ................................................ LXİİ ŞEKİL 10: SAHADA BÜYÜTEÇ ANKET SONUCU .............................................. LXİİ ŞEKİL 11 KODSİS MEMNUNİYET ANKETİ ...................................................... LXİİİ ŞEKİL 12 MEMNUNİYET ANKETİ BİLGİLENDİRME SORUSU............................ LXİV ŞEKİL 13 MEMNUNİYET ANKETİ KODSİS DESTEK DEĞERLENDİRME .............. LXV BİRİNCİ BÖLÜM GİRİŞ Proje bir probleme çözüm bulma ya da beliren bir fırsatı değerlendirmeye yönelik, bir ekibin, başlangıcı ve bitişi belirli bir süre ve sınırlı bir finansman dâhilinde, birtakım kaynaklar kullanarak, müşteri memnuniyetini ve kaliteyi göz önünde bulundururken olası riskleri yönetmek şartıyla, tanımlanmış bir kapsama uygun amaç ve hedefler doğrultusunda özgün bir planı başlatma, yürütme, kontrol etme ve sonuca bağlama sürecidir. Bir projenin başarılı sayılabilmesi için iyi bir planlama sürecinin ardından mükemmel bir yürütme ve kontrolle sonuçlandırılmış olması gerekir. Bu sürece ise proje yönetimi en temel isimlendirmesiyle Proje Yönetimi denir. Proje yönetimi belli bir projenin hedef ve amaçlarına ulaşıp bitirilmesi için eldeki kaynakların en verimli şekilde planlanması, organize edilmesi, tedarik edilmesi, yönetilmesi ve proje faaliyetlerinin kontrol edilmesi disiplinidir. Proje yönetim aşamalarında yeterli titizliğin gösterilmemesi ve mühendislik faaliyetlerin etkin bir biçimde yerine getirilmemesi neticesi olarak ortaya çıkan ürünler, ürünün yaşam döngüsünü içine alan operasyon süreçlerinde çeşitli sorunlara ve geri dönülmez hatalara neden olabilmektedir. Projelendirme aşamalarında önceden tespit edilebilen hatalar ise muhtemel riskleri bertaraf edici olacaktır. Yazılım projeleri, bilişim teknolojilerinin gelişmesine paralel olarak iş hayatında önemli ve etkin bir alan kazanmıştır. İnşaat, tıp, astronomi alanlarında olduğu gibi yazılım ürünlerinin geliştirilmesi süreçleri de temel proje geliştirme disiplinlerine benzerlik gösteren alt faaliyetlerden oluşmaktadır. Telekomünikasyon yazılım projelerini diğer projelerden ayıran en büyük fark ise sektördeki hızlı dönüşümlere kısa sürede adapte olabilme ihtiyacıdır. Benzer şekilde yazılım projelerinde de hataların erken aşamalarda tespit edilebilmesi, ürünün ortaya çıkması ve operasyonel süreçlere geçildikten sonra hata tespit edilmesinden çok daha önemli ve düzeltilme maliyeti çok daha düşüktür. Şekil 1 Yazılım Yaşam Döngüsü ve Hata Tespit Maliyetleri Şekil-1’ de de görüleceği üzere herhangi bir yazılım projesinde sadece kodlama yaparak işi tamamlamak, kaliteye etki edecek kritik aşamaları ihmal etmek, zaman ilerledikçe geri dönülmez sorunlara neden olabilmekte, işletmeleri yüksek maliyetlere mecbur kılmakta, çoğu zaman ise ürünler kullanılamaz hale gelmektedir. Çalışmamız kapsamında, birinci bölümde yazılım proje yönetimiyle ilgili genel bilgiler verilmiş; ikinci bölümde yazılım projelerinin yaşam döngülerinden bahsedilmiştir. Üçüncü bölümde uluslararası kabul görmüş yazılım süreçleri ve kalite standartları ile yazılım mühendisliği disiplini çerçevesinde incelemeler yapılmıştır. Dördüncü bölümde örnek bir telekomünikasyon bilişim/yazılım projesi olarak Kodsis incelenmiş, mevcut durum ile önerilen durumlar karşılaştırmalı olarak verilmiştir. Sonuç bölümünde de telekomünikasyon yazılım projelerinde yönetiminin öneminden bahsedilmiş ve yapılan çalışmanın sonuçları işletme açısından değerlendirilmiş ve önerilerde bulunulmuştur. İKİNCİ BÖLÜM PROJE YÖNETİMİ VE YAZILIM PROJELERİ 2.1 Projenin Tanımı PMI “Proje, benzersiz bir ürün, hizmet ya da sonuç yaratmak için yürütülen geçici bir girişimdir” der(PMBOK, 2010: 5). Projeler geçici nitelikte olduklarından projelerin kesin başlangıç ve bitiş tarihleri vardır. Projenin hedeflerine ulaşıldığında ya da hedeflere ulaşılamayacağı ve ya projeye artık ihtiyaç duyulmadığı için projeye son verildiğinde bitişe ulaşılmış olur. Projelerin geçici nitelikte olmasına karşın yaratılan ürün, hizmet ya da sonuç için genellikle geçicilikten bahsedilemez; çoğu proje kalıcı bir sonuca ulaşmak amacıyla yürütülür. Özellikle telekomünikasyon sektöründe projelendirilerek üretilen yazılım ürünleri asıl hizmetlerin daha verimli sunulmasını ve müşteri memnuniyetinin sürekliliğini sağlamayı amaç edinir. Trevor’a göre proje, “Kurumsal bir organizasyon içerisinde, stratejik ihtiyaçların karşılanması için gerekli olan, birbirleri ile bağlantılı eylemlerin gerçekleştirildiği bir bütündür” (1998: 14). Eski bir Microsoft çalışanı olan Serdar Turan, çok kapsamlı bir yazılım ürünü olan Windows 8 için piyasaya sürülmeden önce 36 aylık bir çalışma yürütüldüğünü ve tek bir ürün için toplamda 4000 mühendisin çalıştığını belirtmektedir.(2013) Proje Yönetiminin Bileşenleri Proje yönetimi 9 temel bileşenden oluşmaktadır. Proje yönetimini bütün yönleriyle kavrayabilmek ve başarılı olabilmek için bu bileşenlerin her birinin ayrıntılı olarak uygulanması ve tümünün bir arada, karşılıklı etkileşim ve uyum içinde yürütülmesi gerekmektedir (Balaban, 2003). 2.1.1 Proje Entegrasyon Yönetimi “Entegrasyon, projenin paydaş beklentileri başarıyla yönetilmek ve gereksinimler yerine getirilmek suretiyle tamamlanması açısından çok önemli olan birleştirme, pekiştirme ve bütünleştirme eylemlerini içine alır“(PMBOK, 2010: 411). Proje Entegrasyon Yönetimi süreçleri şunlardır: Proje başlatma belgesinin hazırlanması, Proje yönetim planının geliştirilmesi, Projenin yürütülmesinin yönetilmesi, Proje çalışmalarının izlenmesi ve kontrolü, Entegre değişiklik kontrolü, Projenin ve ya fazın kapatılması (Erkan, 2011). 2.1.2 Proje Kapsam Yönetimi Projenin gerektirdiği tüm gerekli çalışmaların ve sadece gerekli çalışmaların belirlenmesi amacıyla kapsamın planlanması, tanımlanması, doğrulanması ve kapsam değişikliklerinin yönetimidir (Balaban, 2003). Proje Kapsam Yönetimi süreçleri şunlardır: Gereksinimlerin toplanması, Kapsamın tanımlanması, İş Kırılım Ağacı (İKA)’nın oluşturulması, Kapsamın doğrulanması, Kapsamın kontrolü (Erkan, 2011). 2.1.3 Proje Zaman Yönetimi Projenin zamanında tamamlanabilmesi için gerekli süreçlerden oluşur. Proje Zaman Yönetimi süreçleri şunlardır: Aktivitelerin tanımlanması, Aktivitelerin sıralanması, Aktivite kaynaklarının tahmin edilmesi, Aktivite sürelerinin tahmin edilmesi, Zaman çizelgesinin geliştirilmesi, Zaman çizelgesinin kontrolü (Erkan, 2011). 2.1.4 Proje Maliyet Yönetimi Projenin onaylanan bütçeyi aşmadan tamamlanması amacıyla; kaynak planlaması, maliyet hesapları, bütçeleme, maliyet denetimi gibi konuları kapsayan bir finansal analiz ve denetim yönetiminin uygulanmasıdır (Balaban, 2003). 2.1.5 Proje Kalite Yönetimi Projeyi yürüten organizasyonun, projenin yapılma amacı olan ihtiyaçları karşılamasına yönelik kalite politikalarını, hedeflerini ve sorumluluklarını belirleyen süreçlerini ve aktivitelerini içerir (PMBOK, 2010). Kalite yönetiminde müşteri memnuniyeti şarttır; önlem almak sonradan kontrol etmekten önemlidir. Proje Kalite Yönetimi süreçleri şunlardır: Kalitenin planlanması, Kalite güvencesinin sağlanması, Kalite kontrolünün gerçekleştirilmesi (Erkan, 2011). 2.1.6 Proje İnsan Kaynakları Yönetimi Proje ekibinin organize edilmesine, yönetilmesine ve yönlendirilmesine yönelik süreçleri içerir (PMBOK, 2010). Proje İnsan Kaynakları Yönetimi süreçleri şunlardır: İnsan kaynakları planının geliştirilmesi, Proje ekibinin oluşturulması, Proje ekibinin geliştirilmesi, Proje ekibinin yönetilmesi (PMBOK, 2010). 2.1.7 Proje İletişim Yönetimi Proje taraflarına gerekecek olan bilgilerin ve iletişim gereksiniminin belirlenmesini içeren iletişimin planlanması, ihtiyaç duyulan bu bilgileri zamanında bilgilerinin sunmaya derlendiği yönelik ve olarak bilginin yayınlandığı dağıtılması, performansın performans raporlanması, gereksinimleri karşılayıp sorunları çözmek için proje tarafları arasındaki iletişimin yönetilmesini içeren proje taraflarının yönetilmesi konularını kapsar (Balaban, 2003). 2.1.8 Proje Risk Yönetimi Proje risk yönetiminin hedefleri, projede olumlu olayların olasılığını ve etkilerini artırmak, olumsuz olayların olasılığını ve etkilerini azaltmaktır. Proje Risk Yönetimi süreçleri şunlardır: Risk yönetiminin planlanması, Risklerin tanımlanması, Niteliksel risk analizinin yapılması, Niceliksel risk analizinin yapılması, Risk yanıtlarının planlanması, Risklerin izlenmesi ve kontrol edilmesi (PMBOK, 2010). 2.1.9 Proje Tedarik Yönetimi Mal ve hizmet alımlarının gereğince yapılması amacıyla; satın alma planlaması, ürün gereksinimlerinin dokümante edildiği ve potansiyel kaynakların tanımlandığı sözleşme planlaması, projenin ihtiyaçlarını karşılayabilmek için olası satıcılardan teklif toplanması, toplanan tekliflerin değerlendirilip satıcıların seçilmesi, sözleşme kıstaslarının yerine getirildiğinin kontrol edildiği sözleşme yönetiminin yapılması, hem ürünün onaylanması hem de yönetimsel kapanışa yönelik sözleşmenin sonlandırılması konularını kapsar (Balaban, 2003). 2.2 Yazılım Projelerine Bakış Günümüzde yazılım, tıptan inşaata, elektronikten eğlence sektörüne kadar her alanda kullanılmaktadır. Giderek yaygınlaşan ve vazgeçilmez hale gelen yazılım ürünlerinin hatasız geliştirilmesi kaçınılmazdır. İlk zamanlarda basit işlevleri yerine getiren masaüstü veya gömülü yazılımlardan bugüne kadar çok büyük gelişmeler yaşanmıştır. Artık birçok rol ve yetkinliğe sahip insanların bir arada etkin bir takım oluşturduğu ve etkileşimlerin yoğun bir şekilde yaşandığı yazılım üretim süreçleri söz konusudur. Yazılım ürünlerinin sürekliliğinin sağlanması için iyi kodlama yapmanın ötesinde kaliteye vurgu yapan Yazılım Mühendisliği disiplinleri çerçevesinde ele alınan birçok sürecin de gerçekleştirilmesine ihtiyaç duyulmaktadır. Tipik bir yazılım yaşam döngüsü, gereksinim analizi, sistem analizi ve tasarımı, geliştirme, test, yükleme operasyon ve bakım süreçlerinden oluşur. Bu süreçleri başarıyla gerçekleştirmek için ise planlama, kestirim, risk analizi, izleme ve gözetim, insan kaynakları ve iletişim gibi yönetsel süreçlerin de gerçekleştirilmesi gerekir. Bu süreçlere destek olarak da belgeleme, kalite yönetimi, yapılandırma yönetimi, satın alma gibi süreçler de gerçekleştirilir. Yazılım ağırlıklı olarak beyin gücü kullanılarak ortaya çıkan ürünüdür. Son derece karmaşık olabilen yazılımın geliştirilmesi için kişisel ya da takım yaratıcılığının yanı sıra planlı ve disiplinli bir geliştirme süreci de vazgeçilmez gerekliliktir. Hem hızlı hem de kaliteli bir yazılım ürünü geliştirmek için Yazılım Mühendisliği esaslarına uygun bir geliştirme süreci sağlamak en doğru yaklaşım olacaktır. Yazılım süreçlerinin doğru ve yerinde gerçekleştirildiği yazılımda kalite unsurlarına uygun hareket edildiğinde ise genel ürün geliştirme süreci, ana, destek ve alt süreçlere bölünerek planlama, belgeleme, gözden geçirme, proje verilerini toplama gibi temel prensipler çerçevesinde gerçekleştirilir. Amaç bütçe ve öngörülen zaman dâhilinde müşteri gereksinimlerine uygun bir ürün hazırlamak, operasyon faaliyetlerinin kesintisizliğini ve hatasızlığını garanti altına almaktır. Yazılım geliştirme sırasında uluslararası ve kurumsal bazda kabul edilen yazılım standartlarına uymak, hem mühendislik süreçlerini gerçekleştirmek hem de kalite unsurlarını kapsamak açısından kolaylık ve büyük önem sağlar. Standardize edilememiş yazılım ürünlerinin operasyon ve bakım maliyetleri geliştirme maliyetlerinin çok üstünde olabilecektir. ÜÇÜNCÜ BÖLÜM YAZILIM PROJE YÖNETİMİ YAŞAM DÖNGÜSÜ Geliştirilen yazılımın, üretim aşaması ve kullanım süreci boyunca geçirdiği tüm aşamalar "Yazılım Geliştirme Yaşam Döngüsü" olarak tanımlanır. Yazılımın üretildiği aşamadan itibaren işlevsellik ile gereksinimleri sürekli değişecek ve bu değişiklikler de yazılımın genişlemesine neden olacaktır. Dolayısı ile bu aşamalar bir döngü olarak ele alınmak zorundadır. Bu döngü doğrusal ve tek bir yöne ilerleyen bir döngü değildir. Çünkü herhangi bir aşamada geriye dönmek, geliştirmeyi yapmak ve tekrar ilerlemek mümkündür. Yazılım yaşam döngüsünün bazı temel adımları vardır. Bunları Planlama, Analiz, Tasarım, Üretim ve Bakım olarak sıralamak mümkündür. Planlama, proje planının oluşturulduğu, fizibilite çalışmasının yapıldığı, insan kaynakları ve donanım gibi ihtiyaçların belirlendiği aşamadır. Analiz aşamasında, var olan sistemler incelenerek sistem ve yazılım gereksinimleri ve varsa işleyişteki temel sorunlar detaylı olarak belirlenir. Tasarım, analiz aşamasında belirlenen gereksinimleri karşılayacak olan yazılımın temel yapısının oluşturulduğu aşamadır. Bu aşamada, yazılımın içerdiği tüm bileşenler ayrıntıları ile tanımlanır ve tasarlanır. Üretim aşaması tasarımı yapılmış olan yazılım bileşenlerinin geliştirilmesi, test edilmesi, kurulumlarının yapılması gibi işlemleri içeren aşamadır. Bakım ise, yazılım birimleri teslim edildikten sonra hata giderme, yeni eklentiler yapma, iyileştirmelerde bulunma faaliyetleridir. Tüm bu faaliyetleri yapmak için zaman içerisinde farklı geliştirme modelleri geliştirilmiştir. Her bir model bir önceki modelde karşılaşılan bir eksikliği bertaraf edebildiği gibi projelerin ve ortaya çıkacak ürünlerin büyüklüklerine, müşterinin yapısına, iş alanına göre halen farklı metodolojiler kullanılabilmekte, tek bir model standart olarak kabul görmemektedir. 3.1 Yazılım Geliştirme Modelleri Yazılım ihtiyaçlarının giderek büyümesi, yazılım geliştirme faaliyetlerinde kullanılmak üzere metodolojilerin gelişimini de ortaya çıkartmıştır. Yazılım teknolojilerinin gelişmesi ile var olan model ve metodolojiler de gelişmekte ve yeni modeller ortaya çıkmaktadır. Uygun yazılım geliştirme modelleri kullanılması, yazılımın daha emniyetli, doğru, anlaşılabilir, test edilebilir ve bakım yapılabilir olarak geliştirilmesinde çok önemli rol oynar. Daha emniyetli yazılımların daha kısa sürede, daha az bütçeyle ve en önemlisi daha az hatayla geliştirilmesi için sürekli yeni teknolojiler ve modeller bulunmaya çalışılmaktadır. Yazılım yaşam döngüsü kısmında kısaca özetlenen yazılım geliştirme temel adımlarının nasıl gerçekleştirileceğine yönelik çeşitli modeller kullanılabilmektedir. Model, yazılım geliştirme faaliyetinin nasıl yapılacağına, genel geliştirme düzeninin nasıl olacağına dair bir rehber niteliği taşır. Bu modellerin kullanımlarına yönelik ayrıca pratik uygulama metodolojileri de geliştirilmektedir. Belli başlı yazılım geliştirme modelleri aşağıdaki gibi sıralanabilir: 3.1.1 Gelişigüzel Geliştirme Literatürde bu yöntemi bir model olarak adlandırılmamaktadır. Gelişigüzel geliştirmede belirlenmiş bir model ya da yöntem bulunmaz. Genellikle kişiye bağlı yazılım geliştirme şeklinde yapılır ve bu yüzden yazılımın izlenebilirliği, bakım yapılabilirliği oldukça zordur. 1960'lı yıllarda uygulanan bu yöntem, genellikle basit programlama içeren ve çoğunlukla tek bir kişinin üretim yaptığı yöntemdir. Kişiye bağımlılık ve nispeten küçük ölçekli olması en bariz özelliğidir. Çoğu zaman dokümantasyon bulunmaz. Müşteri açısından kısa sürede ilk ürünün ortaya çıkıyor olması pozitif etki oluşturuyor olsa da bakım maliyetleri ve kişiye bağlılık uzun vadede kalıcılık sağlamamakta ve müşteriler açısından büyük sorunlara neden olabilmektedir. 3.1.2 Barok Modeli 1970'li yıllarda ortaya çıkan Barok modelinde, ilk kısımda tariflenen yaşam döngüsü temel adımları doğrusal bir şekilde ele alınır ve geliştirilir. Aşamalar arasında gereken geri dönüşlerin nasıl yapılacağı tanımlı değildir. Bu modelde, dokümantasyon günümüz modellerinden farklı olarak ayrı bir süreç olarak ele alınır ve yazılımın geliştirme ve test faaliyetleri tamamlandıktan sonra yapılmasını öngörür. Günümüz yazılım geliştirme projelerinde uygulanan bir model olmaktan çıkmıştır. 3.1.3 Şelale (Waterfall) Modeli Şelale modeli yakın zamanlara kadar en popüler yazılım geliştirme modeli olarak görülmüştür. Geleneksel yazılım geliştirme modeli olarak da bilinir. Şelale modelinde yazılım, aşamalar en az birer kez tekrarlanarak geliştirilir. Çok iyi tanımlanmış ve üretimi az zaman gerektiren projeler için uygun bir model olmakla birlikte günümüzde kullanımı gittikçe azalmaktadır. Şelale modeli, Barok modelinden farklı olarak proje içerisindeki dokümantasyonu ayrı bir süreç olarak değil üretimin doğal bir parçası olarak ele alır. Ayrıca, bu modelde aşamalar arasındaki geri dönüşlerin nasıl olacağı da tanımlıdır. Ancak, şelale modelinin kullanımında dikkat edilmesi gereken önemli hususlar vardır. Bunlardan en önemlisi, - her ne kadar model içerisinde aşamalar arasında geri dönüşler yapılabilse de - analiz aşamasında mümkün olan tüm detayın tasarıma yansıtılabilmesi için müşteri ve sistem gereksinimlerinin en ince ayrıntısına kadar belirlenmesi gerekir. Tasarım aşaması da, yazılımın tüm gereksinimlerini karşılayacak şekilde detaylı bir çalışma gerektirmektedir. Dolayısı ile şelale modelini kullanan proje ekipleri en fazla zamanı bu iki aşamada harcamak zorundadırlar. Tüm bu gayret ve detaylı çalışmalara rağmen özellikle uzun zamana yayılan projelerde gereksinimlerin değişecek olması kaçınılmazdır. Kodlama veya test aşamalarında olabilecek bu değişikliklerin sisteme/yazılıma yansıtılması maliyeti ise çok yüksektir. Savunma sanayi bazı yazılımlarında, uydu üretimi gibi geri dönülmesi mümkün olmayan yazılım süreçlerinde çoğunlukla bu modelin kullanıldığını söyleyebiliriz. Şekil 2 Şelale Modeli Geliştirme Bu modelde, yazılımın son kullanıcıya ulaşması genel olarak uzun bir zaman alır. Bu durum, hem müşteri de hem de projenin geliştirildiği kurumun üst yönetiminde belirgin bir memnuniyetsizlik yaratabilir. Kullanıcı, yazılımın geliştirilme aşamasında sürecin içerisinde genellikle yer almaz ve bu durum yazılım tamamlandıktan sonra geri dönüşleri arttırabilir. Bu geri dönüşler, yazılım geliştirme maliyetini büyük oranda yükselten bir durumdur. Tasarım aşamasında fark edilen hata ve eksiklikler küçük bir maliyet ile giderilebilir. Ancak, bu hata ve/veya eksiklikler entegrasyon veya bakım aşamalarında fark edilirse bunları gidermenin maliyeti 50-200 kat artacaktır. 3.1.4 Helezonik (Spiral) Model Spiral yazılım geliştirme modeli temel olarak dört ana bölüm içerir. Bunlar, planlama, risk yönetimi, üretim ve kullanıcı değerlendirmeleri olarak tanımlanabilir. Planlama, üretilecek ara ürün için işin planlanması, amaç ve kısıt ve alternatiflerin belirlenmesi, bir önceki adımda üretilmiş olan ürün ile tümleştirme yapılması faaliyetlerini içerir. Risk yönetiminde, alternatifler değerlendirilir ve risk analizi yapılır. Üretim, planlanmış ara ürünün geliştirildiği aşamadır. Bu aşamadan sonra, kullanıcı değerlendirmesi kısmında, ara ürün hakkında kullanıcıların test ve değerlendirmeleri yapılır. Helezonik model, risk analizi ve ilk örnek üretme üzerine kurulmuştur. Her döngü öncesi, içinde bulunulan fazın risk analizi yapılır ve o faz için planlanmış olan prototip geliştirilir. Her döngünün sonunda, yeniden planlama yapılarak hedefler, alternatifler ve kısıtlamalar belirlenir. Bu model, önceden geliştirilmiş yazılım bileşenlerinin yeniden kullanıldığı projeler için çok uygundur. Şekil 3 Spiral Model Geliştirme Helezonik modelin en önemli getirisi, her döngünün başında risk analizi yapılması nedeniyle zaman ve maliyet bileşenlerinin kolay tahmin edilebilmesidir. Projelerin kaliteye yönelik hedeflerinin önceden belirlenmesi durumunda da bu kalite hedefleri her döngüde alternatif ve kısıtlar belirlendiği için diğer modellere göre daha kolaydır. Ancak, helezonik yazılım geliştirme modeli küçük projelerde kullanılmasının uygun olmaması, modeli uygulayanların bu konuda tecrübeli olması gerekliliği, risk analizi olgusuna dayandığından alt yüklenici kullanımında zorluklar taşıması gibi dezavantajlarda taşımaktadır. 3.1.5 Arttırımsal (Incremental) Geliştirme Modeli Artırımsal model, yazılımın küçük parçalara ayrılarak döngüsel olarak geliştirilmesi fikrine dayanır. Proje süresi, artırım (veya döngü) olarak tanımlanan küçük zaman dilimlerine bölünür. Proje birçok döngünün gerçekleştirilmesi ile ilerler. Her döngünün sonunda, projeye ait planlanmış çıktılar elde edilir ve yazılıma yeni bir fonksiyonalite eklenir. Bu sayede yazılım artırımsal olarak geliştirilir. Projenin bir döngüsünde henüz tümleştirme süreci sonlanmamışken, diğer bir döngünün tasarım süreci başlayabilir. Dolayısı ile bu model yazılım geliştirmenin doğasına daha uygun olarak görünmektedir. Her döngüde yeni bilgi ve tecrübeler edinilir ve bunlar projenin geliştirilmesi aşamasında çok değerli katkılar yapar. Artırımsal modelin en önemli avantajlarından biri, projenin ilk safhalarında elde edilen çıktıların projenin ilerleyen aşamalarında değişikliğe uğraması halinde bile büyük bir maliyete neden olmadan bu değişikliklerin yapılabilir olmasıdır. Şekil 4 Artırımsal Model Geliştirme Bu modelde her döngü, tasarım, kodlama, test ve entegrasyon süreçlerini içerir. Yazılım, bir prototipten başlar ve her döngüde yeni bir fonksiyonalite ekleyerek gelişir, genişler. Artırımsal model gereksinimlerin daha başta olgun olmadığı, uzun zaman alabilecek ve sistemin eksik işlevlikle çalışabileceği türdeki projeler bu modele uygun olabilir ve döngüler halinde geliştirilmeye uygun projelerde kullanılmalıdır. Yazılım fonksiyonlara bölünmeye uygun olmalı, her bir parça ayrı olarak ele alınmalıdır. Birçok telekomünikasyon yazılım projelerinde bu modelin kullanıldığını görebiliriz. Sürekli yenilenen gereksinimler ve yoğun rekabet ortamı prototip ürünler üzerinden bile markette yer almayı mümkün hale getirebilmektedir. 3.1.6 Döngüsel Model Döngüsel yazılım geliştirme modeli artırımsal modelle çok benzerlik taşır. Döngüsel yazılım geliştirme modeli, proje yaşam döngüsündeki tüm süreçleri içeren döngülerden oluşur. Artırımsal modelden farkı döngülerin içerdiği süreçlerdir. Artırımsal modelde, her döngüde tasarım, kodlama, test ve entegrasyon süreçleri bulunurken döngüsel modelde planlamadan başlayarak tüm proje süreçleri kapsanır. Döngüsel modelin de artırımsal modeldeki gibi en büyük avantajı projenin ilerleyen aşamalarında gerek duyulan değişikliklerin gerçekleştirilmesi maliyetinin çok düşük olmasıdır. Bu modelde, yapılacak döngülerin sayısı ve süresini belirlemek çok önemlidir; belirlenen döngü sayısı olması gerekenden fazla olduğu takdirde fazladan öngörülen döngülerde yapılan işin tekrar yapılmasına neden olunabilir. Döngü süresini belirlerken de olması gereken süre çok dikkatli belirlenmedir. Olması gerekenden kısa zaman belirleme yeni fonksiyonların geliştirilmesi için yeterli olamayacağı gibi olması gerekenden fazla zaman belirleme de modelin şelale modeli gibi işlemesine neden olabilir. 3.1.7 Çevik Yazılım Geliştirme Metodları Çevik yazılım geliştirme metotları, hantal olduğu düşünülen yazılım geliştirme modellerine bir alternatif olarak 90’lı yılların ortalarında gelişmeye başlamıştır. Bu modelde döngüler içerir ve bu anlamda döngüsel modelle benzerlikler taşır. Ancak, çevik metotlarda döngüler çok kısa döngü sayısı da oldukça fazladır. Bu metotlar, proje içerisindeki her bir döngüde yazılımın bir sürümünü küçük bir proje olarak ele alır ve bunu tedarik edenin katılımı ile test eder. Her döngüde projenin öncelikleri yeniden belirlenir ve proje boyunca ortaya çıkan değişikliklere uyum sağlanır. Bu metotlar, doküman üretiminin yazılım geliştirme faaliyetlerini yavaşlattığına inandığından doküman üretme yerine yüz yüze görüşmelere ağırlık verir. Döngüler sonucunda ortaya çıkan yazılım birimleri tedarik makamı tarafından değerlendirilir ve yapılan her yorum yeni bir sürüm olarak yazılıma eklenir. Şekil 5 Çevik Model Geliştirme Çevik metotların en önemli avantajı, değişikliklerin yazılıma uyarlanmasındaki hızdır. Bu hız yüzünden değişikliklerin yazılıma yansıtılma maliyetleri çok düşüktür. Döngülerin kısa olması ve dokümantasyonun çok az olması bu modelin uygulandığı projelerin zaman ve çaba maliyetlerinin çok düşük olmasını sağlar. Her döngüde müşteri katılımı yoğun olduğu için müşteri memnuniyeti yüksektir. Dolayısı ile çevik karşılamayan yazılım geliştirme riskini azaltır. Şekil 6 Çevik Geliştirme Zamana Göre Değişim metotlar gereksinimleri Telekomünikasyon Bilişimi Kalitesi İle İlişkili Standartlar, Modeller, Organizasyonlar 3.2 3.2.1 ISO 9126 Yazılım Kalite Özellikleri 1991 yılında ilk defa tanımlanan standarda göre yazılım kalitesini 6 ana karakteristik ile tanımlamaktadır. Bunlar; Fonksiyonellik(uygunluk, doğruluk, karşılıklı işlerlik, uyumluluk, güvenlik), Güvenilirlik(olgunluk, hata toleransı, kurtarılabilirlik), Kullanılabilirlik(anlaşılabilirlik, öğrenilebilirlik, işlerlik), Etkinlik(zaman davranışı, kaynak yararlanımı), Bakım yeteneği ve korunabilirlik((analiz edilebilirlik, değiştirilebilirlik, durağanlık, test edilebilirlik)), Taşınabilirliktir(adapte edilebilirlik, kurulum kolaylığı, uygunluk, yer değiştirebilirlik) olarak gruplandırılmaktadır. 3.2.2 TmForum TM Forum bilgi, telekomünikasyon firmaların bir araya gelerek oluşturdukları bir organizasyondur. Dünyanın birçok ülkesinden 900’ den fazla telekom firması bu yapının içerisinde yer almaktadır. Bu kapsamda organizasyonun ortaya koyduğu bazı çatı standartlar oluşmuştur. Hızla gelişen telekomünikasyon sektöründe aynı ortak dilin kullanılabilmesi, benzer iş süreçlerinin tek bir tanıma sahip olması, sektörü oluşturan firmalar ve taşeronlar ile sektöre hizmet ve ürün sağlayan tedarikçilerin standartizasyonu amacıyla kurulan organizasyonun en önemli çıktılarından birisi de Frameworkx olarak tanımlanan standartlar sözlüğüdür. Frameworkx kapsamında bulunan standartlar eTom(genişletilmiş SID(Paylaşılan Bilgi Veri), telekomünikasyon TAM(telekom süreçleri uygulamaları haritası), haritası) ve TNA(teknoloji nötr mimari). Bu standartlar sayesinde ‘müşteri’, ‘müşteri siparişi yönetimi’, ‘alacak yönetimi’, ‘ürün katoloğu’, ‘ürün yaşam döngüsü’ gibi bir çok iş ve iş süreci sözlükte yerini almaktadır. Diğer taraftan bu iş süreçlerinin yerine getirilmesini sağlayacak uygulama alanları da TAM haritasında tanımlanmıştır. Böylelikle sektördeki tüm paydaşlar aynı dili kullanabilmektedirler. Ülkemizde yer alan büyük telekom firmaları da bu çatı organizasyonda yerlerini almış olup, geliştirmelerinde ve faaliyetlerinde aynı dili kullanmaya özen göstermektedirler. 3.2.3 ISO 15504 Spice(Software Process Improvement and Capability Determination) Tanım olarak Spice, Yazılım Süreci İyileştirme ve Yetenek Belirleme’ dir. 1995 yılında ISO ve IEC tarafından çıkarılmıştır. Yazılım geliştirme projelerinde daha disiplinli geliştirme süreçleri için standartlarından olan Spice, yazılım süreçlerini iyileştirmeyi ve süreç yeteneklerini belirler. SPICE, iki boyutlu bir model olup içe dönük süreç iyileştirme ile içe ve dışa dönük yetenek belirleme amacını taşır. Birinci boyutta süreçler, ikinci boyutta yetenek düzeyleri vardır. Temel spice ilkeleri standartlaşma, değerlendirme, yetenek belirleme ve iyileştirme, diğer modellere uyum sağlama, gelişmeyi ölçme, nesnel, tutarlı ve tekrarlanabilir olma şeklindedir. Bu standardın bir sertifikasyon amacı bulunmamaktadır. 3.2.4 CMMI Capability Maturity Model Integration (CMMI) (Entegre Yetenek Olgunluk Modeli), yazılım üzerine çalışan şirketlere ürünlerin geliştirilmesinde ve kullanıcılara destek hizmeti sağlanmasında nasıl bir yol izlenmesi gerektiğini gösteren, verimliliği ve istikrarı arttırmayı amaçlayan bir süreç iyileştirme modelidir. Bu model gereksinimlere ve uygunluğuna göre, bir projenin ya da herhangi bir parçasının ya da tüm organizasyonun iyileştirilmesi sürecinde esas alınabilir. CMMI 5 seviye ile tanımlanır. Bunlar Yetersiz, İfa edilen, Yönetilen, Tanımlı, Nicel olarak yönetilen, Sürekli iyileştirilen şeklindedir. Ülkemizde özellikle savunma sektöründe iş yapan bilişim firmalarında beşinci seviye olgunluk şartı aranmaktadır. Gartner verilerine göre ise dünya telekomünikasyon firmaları ortalaması ikinci seviyeyi geçememektedir.(2013) 3.2.5 SCRUM Scrum, son yıllarda yaygınlaşan çevik uygulama geliştirme yöntemidir. Bu geliştirme yönteminin temel özelliği gözleme, geliştirmeye ve tekrara dayalı olmasıdır. Birçok modern yazılım projesinin oldukça karmaşık olduğu ve en baştan tümünü planlamanın zor olacağı şeklindeki bir varsayımdan hareket eder. Bu karmaşıklığı üç ilke ile azaltmaya çalışır. Bunlar Şeffaflık: Projedeki ilerlemeler ve sorunlar günlük olarak tutulur ve herkes tarafından izlenebilir olması sağlanır. Denetleme: Ürünün parçaları ya da fonksiyonları düzenli aralıklarla teslim edilir ve değerlendirilir. Uyarlama: Ürün için gereksinimler en baştan bir defalığına belirlenmez, bilakis her teslimat tekrar değerlendirilir ve duruma göre uyarlamalar yapılır. Amaç başlangıçta hayal edilen ve tasarlanana uyan bir ürünün, hızlı, ucuz ve kaliteli şekilde üretilmesidir. Tasarlanan ürünün gerçekleştirilmesi, müşteri/kullanıcı tarafından mümkün olduğunca detaylı şekilde hazırlanmış bir talepler listesinin aşama aşama gerçekleştirilmesi biçiminde yapılmaz. Bunun yerine müşteri/kullanıcı tarafından istenilen ve tanımlanan işlevler, iki ya da dört haftalık "Sprint" adı verilen dönemler içerisinde geliştirilir ve yeniden gözden geçirilir. Bu kullanıcı bazlı gereksinim tanımı Kullanıcı Hikâyesi olarak nitelenir ve özellikler defterinde yer alır. Her Sprint sonunda yazılımın fonksiyonel bir parçası bitmiş ve müşteriye teslim edilebilir bir durumda olur. Scrum’ a görev dağılımları ‘Ürün sahibi’, ‘Takım’, ‘Scrum ustası’ şeklindedir. Geleneksel proje yöneticisi rolü bu yöntemde kullanılmaz. Sprint toplantıları, günlük toplantılar, Retrospektif toplantısı gibi belirli toplantı tipleri ile grup içi iletişim sürekli hale getirilir. 3.2.6 Kaizen ile Süreç İyileştirme ve PUKO Kaizen, Japoncada kai değişim, zen ise daha iyi anlamına gelmektedir. Kaizen işgücünü dayalı gelişme anlamına da gelmektedir. Kaizen’ in uygulanması 2 ile 5 gün sürebilen, özel olarak oluşturulmuş fonksiyonel bir takım tarafından iyileştirmeleri belli bir sürece veya iş planına uygulamasına dayanır. İmalatta uygulandığında iyi sonuçlar verebilen Kaizen, hizmet veya teknik alanlarda da uygulanabilmektedir. Kaizen, sürekli iyileştirmedir. Kaizen, belirli bir zaman diliminde müşteri memnuniyetinin arttırılması ve rekabet güçlerinin etkilenmesi amacıyla süreçlere yönelik, çalışan, süreç, zaman ve teknolojide yavaş yavaş fakat çok sayıda hızlı bir gelişme sağlamayı maliyetlerde bir düşmeyi ifade eden bir kavramdır. Kaizen(Sürekli İyileştirme), sonuçlardan ziyade süreçlere yöneliktir. Çünkü eğer sonuçlar iyileştirilmek isteniyorsa bu sonuçları ortaya çıkaran süreçler iyileştirilmelidir. Kaizen çalışan boyutunda, insanın kaynak olarak görülmesini, işletmenin dışında da bu kaynaklara yönelinmesini uygulamaya girişilmesini eğitim, ekip yetiştirme, oluşturmayı gelişmeye ve önem çalışanları verip yalnızca performansları sonucunda ortaya koydukları sonuçlar nedeniyle değil, gelişme sürecindeki katkıları nedeniyle de ödüllendiren bir sistemdir. Süreç boyutunda ise, süreçlerin korunmasını, düzeltici önlemler alınmasını ve süreçlerin iyileştirilmesini; zaman boyutunda, pazardaki değişmelere, gelişmelere hızlı cevap verebilme, hızla yenilik yapma ürün çeşitliliği vb. maliyetleri düşürerek geliştirme ve böylece faaliyetlerin daha kısa sürede yapılmasını hedeflemektedir. Teknoloji boyutunda ise, maliyetleri düşürme, teknolojileri birbirine dönüştürme, basitleştirme vb. uygulamalar ile gerçekleştirilmektedir. Kaizen Değer Sistemi, her zaman, her kademede bütün nesnelere yapılacak olan sürekli iyileştirme çalışmalarıdır. Sürekli iyileştirmeler kalite çemberleri, takım çalışmaları, otomasyon ve işçi-üst yönetim işbirliği stratejileriyle elde edilebilir. Şirkette çalışan her işçi kaizenden sorumludur. Sürekli iyileştirmelerin tam anlamıyla yapılabilmesi için iş yerindeki her kademelere gereken sorular sorulur, formlar doldurtulur ve onların fikirleri öğrenilir. Bunlardan elde edilen veriler sonucunda da iyileştirmeler yapılır. Geri beslemelerle süreç sürekli hale getirilir. Kaizen'in birden fazla amacı var. Ana hedefleri arasında yüksek müşteri memnuniyeti yer alıyor, çünkü müşteri edinmek müşteri tutmaktan daha pahalı. Müşteri memnuniyetini sağlamak için, üç faktör öne çıkmaktadır: Maliyet azaltma Kalite Güvence Hız (zaman verimliliği) Kaizen destekleyicileri mevcut bir durumun her zaman daha fazla gelişebileceğine ve bunu için çalışmalara hep devam etmek gerektiğini savunmaktadırlar. Ayrıca personel alanında da değişimler gerekmektedir. Böylece çalışanların taahhütleri sürekli eğitimle garantilenmeli ve her çalışanın değişiklikler konusunda söz hakki olacak şekilde, iç hiyerarşileri ayarlanması gerekmektedir. Kaizen felsefesi bir şirketin tüm bölümlerinin daha iyi bir çalışma ortamı yaratmak amacıyla sürekli bir çaba göstermeleri gerektiğini savunuyor. Bunu da süreç iyileştirmeleri ve en iyi kalitede ürünler sağlayarak garantiliyor. Her alanda sürekli iyileştirme yapmak gerekmektedir. 3.2.7 PUKO Döngüsü ISO standartlarının da temelini oluşturan PUKÖ (Planla-Uygula- Kontrol Et-Önlem AL) çevrimi ise veri esaslı olarak sistematik bilgi elde etmeyi sağlayan bilimsel bir yöntemdir. Yeni bilgiler elde edildikçe birikim artar. Birikim arttıkça gelişmeler ve yenilikler açısından fikir üretilir ve PUKÖ ile test edilir. Yapılan planlar sadece planı yapılan konulardan değil birçok dış faktörden de etkilenmektedir. Bu nedenle yapılan planların uygulama aşamalarında sürekli kontrol edilmeleri ve oluşan aksaklıklar için düzeltici faaliyetler başlatılmalıdır. Eğer sadece ilk seferinde doğru yap ilkesi iyi kalite için geçerli olsaydı birçok şirketin işi çok daha rahat olacaktır. Ancak değişen koşullar nedeniyle bu ilke nadiren geçerli olmaktadır. Değişen koşulların yapılan işin kalitesini etkilememesi ve işi sürekli geliştirmek için PUKO döngüsü kullanılmalıdır. PUKO döngüsü ile ayrıca şirketlerdeki görev dağılımı da yapılabilmekte, bu şekilde de çalışanlara sorumluluk verilmektedir. Bununla beraber PUKO yu yaptıkları işlerde uygulayan çalışanlarda oto kontrol de gelişmekte ve çalışanları kontrol etmek ile harcanan zamandan tasarruf edilebilmektedir. 3.2.7.1 3.2.7.1.1 PUKO Aşamaları Planla PUKO döngüsünün ilk ve en kritik adımı planlama aşamasıdır. Bu aşamada planlanan işin kimler tarafından, neden, nasıl, nerde, ne zaman, ne kadar sürede yapılacağı kararlaştırılır. Planlama aşamasında her noktanın düşünülmesi görev dağılımlarının ve hedeflerin düzgün olarak belirlenmesi PUKO' nun son adımı olan Önlem al aşamasında yapılacakları en aza indirecektir. Eğer Planlama aşamasına gereken önem verilmez ise kontrol al ve önlem al aşamalarında yapılacak olan uygulamaların maliyeti çok fazla olacaktır. Yapılacak iş ya da hedefler belirlenirken alınacak kararlar gerçek verilere dayalı ve gerçekçi olmalıdır. İlk başta çok yüksek hedeflerin konması ve bunları gerçekleştirilememesi durumunda motivasyon düşecek ve verimsizlik başlayacaktır. Planlama aşamasında 5N1K sorularının tam olarak cevaplandırılması amaçlanır. 3.2.7.1.2 PUKO Uygula döngüsünün ikinci aşamasıdır. İlk aşamada planlanan faaliyetlerin belirlenen kişi yöntem ve zamanlarda gerçekleştirildiği aşamadır. Bu aşamada kullanılan istatistiksel yöntemlerden elde edilen veriler PUKO' nun üçüncü adımı olan Kontrol et aşamasının girdisini oluşturur. 3.2.7.1.3 Kontrol Et PUKO döngüsünün üçüncü aşamasıdır. Planlanan hedeflere ne kadar ulaşıldığı belirlenir. Eğer hedeflere ulaşıldıysa yapılan uygulama faaliyetleri kontrol edilir ve standartlaştırılır. 3.2.7.1.4 Önlem Al PUKO döngüsünün dördüncü ve en son aşamasıdır. Kendi içinde PUKO döngüsü içerir. Planlanan faaliyetler ile yapılan uygulamalar arasında ortaya çıkan farklılıkların, sapmaların nedenleri araştırılır ve bunların ortadan kaldırılmasına yönelik faaliyetler başlatılır. Şekil 7 PUKO Döngüsü 3.2.8 Yazılım Projelerinde Kaizen Kaizen felsefesinin temelinde sürekli iyileştirmenin olduğundan bahsedilmişti. Diğer iş kollarındaki süreçlere benzer olarak yazılım ürünlerinin de hayat döngüleri sürekli iyileştirmeye ihtiyaç duyarlar. Zira müşteri gereksinimlerindeki değişimler, gelişen teknolojiler, mevzuat düzenlemeleri, kullanıcı profilindeki değişimler ile zamanla ürün kullanımına paralel olarak ortaya çıkan hatalar ve sorunlar nedeniyle ürünlerin yeniden gözden geçirilmeye diğer bir ifadeyle PUKO döngülerine girmeleri kaçınılmazdır. Yazılım geliştirme modellerinin çoğunda bu yaklaşımın temel alındığını rahatlıkla söyleyebiliriz. Spiral, artırımsal, döngüsel ve çevik yöntemlerde ürünün sürekli iyileştirilmesi, geliştirilmesi esas alınmaktadır. Yazılımlar için Planlama aşaması, gereksinimlerin toplanmasını, analiz ve tasarımların yapılmasını, uygulama aşaması geliştirmeleri ve devreye almayı, kontrol aşaması ürünün kullanımı sürecinde izlenmesini, önlem alma aşaması ise oluşan veya oluşması muhtemel beklenmeyen durumlar için düzenleyici önleyici faaliyetlerin başlatılmasını içerir denebilir. Sürekli iyileştirme faaliyetlerinde tüm paydaşların rollerine göre farklı katkılarının olacağı da muhakkak bir gerçektir. Ürünü kullanan son kullanıcılar, müşteriler, geliştirme sürecinde görev alan personeller, ürün yöneticileri dâhil farklı tüm paydaşlar ürüne ait farklı bir iyileştirme gereksinimi oluşturabilecektir. Diğer iş alanlarına göre yazılım ürünlerinin sürekli iyileştirme süreçlerinde çok önemli bir avantaj vardır. Bu avantaj ürün geliştirme ve ürüne ait süreçlere ait birçok verinin veri tabanlarında saklanıyor olmasıdır. Böylelikle iyileştirme çalışmalarına kaynak oluşturabilecek birçok istatistiki veri çok hızlı bir şekilde elde edilebilecektir. Ayrıca yazılım ürünlerinin sanal ürünler olduğu dikkate alındığında iyileştirme iş adımlarının da farklılıklar göstermesi doğal olarak farklı olacaktır. DÖRDÜNCÜ BÖLÜM VAKIA ANALİZİ: KODSİS 4.1 Kodsis Projesi Hakkında Ülkemizin tek kablo tv operatörü olan Türksat’ ın kablo tv, Teledünya, Uydunet gibi temel hizmetleri ile diğer katma değerli interaktif hizmetlerine ait müşteriden tedarikçiye, siparişten tahsilata kadar pek çok iş sürecini tek bir uygulama üzerinden yönetmesini sağlayan bir telekomünikasyon yazılım ürünüdür. Kodsis kapsamında müşteri sipariş yönetimi, sözleşme yönetimi, kampanya yönetimi, satış kanalları yönetimi, ürün yaşam döngüsü yönetimi, kaynak yaşam döngüsü yönetimi, envanter yönetimi, tedarikçi ve iş gücü yönetimi, arıza yönetimi, servis ve destek yönetimi, tahakkuk ve faturalandırma, alacak yönetimi, tedarik zinciri yönetimi, paydaş yönetimi, yasal takip yönetimi gibi pek çok iş ihtiyacı karşılanmaktadır. 2005 yılından beri hizmet veren Kodsis, TÜRKSAT bünyesinde geliştirilen ilk ve en büyük iç otomasyon sistemidir. Bu proje sayesinde Türksat hem şirket içinde kaynak kullanımı açısından başarılı olabilmiş hem de bu başarısı sonrasında kazandığı deneyim ve dış destek ile başta e-devlet olmak üzere birçok dış kurum projelerine yansıtmayı başarabilmiştir. Projede kullanılan yöntem, iş süreçleri ve teknolojiler farklı zamanlarda değişik yazılım projelerinin geliştirilmesinde örnek alınmıştır. Temel olarak uygulanmaktadır. Kodsis’ te artırımsal geliştirme metodolojisi 4.2 Telekomünikasyon Bilişimi Telekomünikasyon sektörü son yıllarda çok hızlı bir dönüşüm içerisinde bulunmaktadır. Her geçen gün yeni bir ürün, bu ürüne bağlı yeni hizmet ve servisler çıkarken, eski hizmet ve ürünler ise demode olmaktadır. Yoğun rekabetin de yaşandığı sektörde yer alan firmaların bu dönüşüm ve değişime çabuk adapte olabilmeleri ve hızlı aksiyonlar alabilmeleri gerekiyor. Sektörün ihtiyacı olan donanım ürünleri çoğunlukla tedarik yöntemiyle nispeten kısa sürede sağlanabiliyor. Fakat bu donanımlar üzerinden verilecek hizmetler ve hizmetlere ait süreçlerin yönetilmesini sağlayacak uygulamalar ise daha yavaş ilerliyor. Diğer yandan donanım temin maliyetleri gün geçtikçe düşmesine karşın yazılım maliyetleri daha yükselmektedir. Özellikle yazılım teknolojilerinde yapılacak küçük bir inovasyon ve markete hızlı giriş sektörde tüm dengeleri alt üst edebilecek etkiler doğurabilmektedir. Bunun akla gelecek en kolay örneği Iphone ürünün pazara girişi sonrasında Nokia’ nın sektörde nasıl pozisyon kaybettiğidir. Günümüzde çeşitli ölçeklerde pek çok ulusal/uluslararası yazılım şirketlerinin bir çok açıdan(mevzuatlar, iş akışlarının benzerliği) standart olan ürün/hizmet üretim süreçleri, müşteri ilişkileri yönetimi, tedarikçi yönetimi, bütçe, finans yönetimi gibi temel fonksiyonel ihtiyaçlarına yönelik jenerik ve genel kabul gören uygulamalar geliştirmekte ve destek vermektedirler. Fakat müşterilerine sağladığı hizmetleri/ürünleri süreklilik arz eden sektörlerde bu uygulamaların yetersiz kalabildikleri, işletmeye yönelik uyarlamaların ise fayda-maliyet noktasında gözlemlenmektedir. çelişkili durumlar ortaya çıkardığı Bu kapsamda bir telekomünikasyon şirketi olan Türksat sektördeki benzer paydaşları gibi teknolojik ve sektörel gelişmelere paralel olarak sürekli iyileştirdiği ve geliştirdiği kablo tv iş süreçlerini ve iş modellerini yönetmek için kullandığı Kodsis ürününü kendi iç kaynaklarını kullanarak geliştirmektedir. Böylelikle özellikle zaman kaynağının yönetilmesinde önemli kazanımlar elde edilmesi hedeflenmektedir. Söz konusu Kodsis bir telekom yazılım ürünü olarak hem kurumun ihtiyaç ve taleplerine en kısa sürede karşılık vermek durumunda hem de uluslararası kabul görmüş bir takım yazılım proje yönetimi standartlarını geliştirme ve operasyon faaliyetlerinde uygulamak durumundadır. Üst bölümlerde yer alan yazılım projesi geliştirme faaliyetleri bir ihtiyaç olmakla birlikte tam manasıyla uygulandığında kazandırdığı kaliteye karşın ciddi zaman maliyetleri getirdiği görülmektedir. Dolayısı ile Kodsis ürünü bu iki ucun arasında bir yerde kendi yaşam döngüsünü oluşturmaktadır. Bu yüzden artırımsal geliştirme modeli en uygun yöntem olarak düşünülmektedir. Sektördeki ürün ve ihtiyaçlar değiştikçe ve geliştikçe, bu ürünlerin yaşam döngülerini yönetecek yazılım modülleri Kodsis’ te yerlerini almaktadır. Bu bölümde bahsedilen sistemin çalışabilmesi için izlenilen ürün geliştirme ve operasyonel metodolojiler incelenecek, ayrıca darboğaz noktaları için iyileştirme önerileri ve yapılabilecek çalışmalar yer alacaktır. Ayrıca yazılım proje yönetimi ile farklı standartların projemizle kesişen hususlarda bilgilendirmeler yapılacaktır. 4.3 Mevcut Durum Türksat’ ın ilk yapılanma döneminde Kablo TV operasyonlarının abone yönetim sistemi ihtiyacının karşılanabilmesi amacı ile başlatılan KODSİS projesi, gelişen operasyonel yapılanmaya paralel olarak hem kapsam hem de fonksiyonel olarak fazlaca genişlemiştir. Tanım olarak bakıldığında birçok alt projenin yürütüldüğü bir programa dönüşmüştür. Proje kapsamında yapılan operasyonel işlemlerin çeşitliliği zaman içerisinde arttıkça, paydaş iş birimlerine ait rutin iş yüklerinin önemli bir kısmı da otomatize olmuştur. Sipariş yönetimi, arıza, bakım, faturalandırma, tahsilat, icra takibi, hak ediş, mediation gibi bir kelime ile ifade edilen, fakat fonksiyonel-operasyonel iş tanımı ve muhteviyatı çok geniş çalışmaların, zaman içinde geliştirilmiş yazılımlar üzerinden yapılabiliyor olması, iş birimlerin rutin dışı işlemlere zaman ayırmalarına daha önemlisi ise nispeten çok daha az personel ile çalışabilmelerine sonuç olarak ise üretkenlik artışına neden olmuştur. Dolayısı ile KODSİS bir yazılım projesinden öte, merkezi bir operasyon birimi haline zaman içinde dönüşmüştür. Kodsis ürünü kullanılarak bir kampanya tanımlanabilmekte, bu kampanyaya müşteri siparişi alınabilmekte, müşterinin talebine bağlı olarak kaynak ve servisler taşeronlar aracılığı ile sağlanmakta, ay sonunda müşteriye hizmet kullanım faturası kesilmekte, müşteri faturasını istediği bir banka üzerinden veya internetten kredi kartı ile ödeyebilmekte, ödemesini yapmayan müşteriler için yasal takip yapılabilmekte, müşterilerin internet hız değişimi, farklı tv paket talepleri anlık olarak karşılanmakta ve yerine getirilebilmekte, müşteri arıza ve şikayetleri çağrı merkezi aracılığı ile teknik servis ekiplerine iletilmekte, şirketin stratejik hedeflerinin ölçümleri ve yönetim kararlarının alınmasını sağlayacak pek çok raporlama yapılabilmekte, ayrıca hizmetlerin verilmesini sağlayan teknik altyapı merkezi olarak yönetilebilmektedir. Tek bir sistem üzerinden analog kablo tv, sayısal yayıncılık, internet, eğitim portali, web tv, güvenli internet, voip gibi pek çok ürüne ait yaşam döngüsü yönetilebilmektedir. Yukarda bahsi geçen iş ve işlemlerin birbirinden görev alanları farklı pek çok birim çalışanının tek bir sistem üzerinden yapabiliyor olması Türksat’ a çok fazla kaynak tasarrufu sağlamaktadır. Diğer yandan KODSİS, Kablo Tv tarafında Türksat’ ın kurumsal hafızası niteliği taşımaktadır. Bu manada Kodsis, 2005 yılı itibari ile kayıt altında tutulduğu, herhangi bir müşteriye ait tüm idari, mali, hukuki ve istatistiki verinin saklandığı tek veri tabanıdır. Kampanya, yeni hizmet, yeni alt yapı proje çalışmaları gibi stratejik öneme sahip çalışmalara istatistiki veri sağlayan, maliyet tabanlı muhasebe için net, güncel ve sağlıklı verilere sahip bir sistem olması nedeni ile paydaş birimlerin vazgeçilmez bir görev aracı olarak görev yapmaktadır. 4.3.1 Kodsis İlişki Ağı Kodsis kullanıcıları grupları temel olarak bakıldığında Kablo Tv iş süreçlerine sahip tüm iş birimlerini kapsamaktadır. Tablo 1 Kodsis İlişki Ağı No Birim 1 Pazarlama ve Satış Direktörlüğü 2 Müşteri İlişkileri Direktörlüğü 3 İnternet ve İnteraktif Hizmetler Direktörlüğü 4 Kablo Sistemleri Altyapı Direktörlüğü 5 Hukuk Müşavirliği 6 İl Müdürlükleri 7 8 9 10 14 16 17 18 19 20 22 23 25 İlgili Modüller Abonelik, Kampanyalar, Faturalar, Raporlar, Hakediş, online hizmetler, Çağrı Takip, MİYOS Abonelik, Raporlar, Hakediş, Fatura Mediation uygulamalar, Stok Yönetimi Tesis Takip, Taşeron yönetimi, Proje Yönetimi, Stok Yönetimi, Mediation uygulamalar, Raporlar, Hakediş İcra Takip, Hasar Takip, Raporlar, Abonelik, fatura, Tahsilat, arıza, hukuk, Mediation Muhasebe Fatura, tahakkuk- icmal raporları, stok Direktörlüğü raporları, bütçe raporları, efatura takibi Finans Direktörlüğü Tahsilat, bankaların takibi, online ödeme sistemleri, pos sistemleri, mutabakat raporları, kamu tahsilatları, kampanya maliyet raporları Yönetim Geliştirme Kalite Raporları, Bütçe-Hedef Direktörlüğü/ Üst raporları, performans raporları Yönetim Bütçe ve Mali Bütçe Raporları, Abone İstatistikleri, Kontrol Hedef raporları, Direktörlüğü Üst Yönetim Abone İstatistikleri Bankalar(26) Online-offline tahsilatların ve mutabakatların takibi PTT Abonelik İşlemleri ve tahsilat Taşeronlar Abonelik, Servis, destek, altyapı yönetimi Çözüm Ortakları Abonelik İşlemleri Çağrı Merkezi Abonelik, arıza, teknik destek hizmetleri Online web sitesi Abonelik hizmetleri entegrasyonu CNR / CMTS / Abonelik – Mediation, orta katmanı UTM / Conax / yazılım entegrasyonları SMS/DPİ BTK IP Log Yoğunluk 10 10 10 10 7 8 4 4 2 2 1 4 4 3 2 5 4 10 10 4.3.2 Kodsis Organizasyon Yapısı Alt projelerden oluşan Kodsis Bilişimden sorumlu genel müdür yardımcılığına bağlı bir direktörlük altında organize olmuştur. Hem ürün geliştirme hem de operasyon ve bakım desteği verilmesi nedeniyle birçok alt ekipten oluşmaktadır. Bu ekipler; Mimari ekip İş analizi ekibi, Tasarım ekibi, Yazılım ekibi, Test ekibi Konfigürasyon ekibi, Operasyon ve Destek ekibi, Kalite ve Güvenlik ekibi Olarak tanımlanmaktadır. Ayrıca yapılandırma ekipleri ile ortak çalışan ve farklı bir organizasyon altında yer alan sistem, veri tabanı, network, izleme ekipleri de yer almaktadır. Personel yapısı bilgisayar, endüstri mühendislikleri ve benzeri bölümlerden mezun ve en az 3 yıl iş deneyimi olan kişilerden oluşmaktadır. 4.4 Kodsis Yazılım Geliştirme Süreçleri Önceki bölümlerde ideal bir yazılım geliştirme süreçlerinin nasıl yapıldığını farklı kaynaklar aracılığı ile incelenmişti. Bu başlıkta Kodsis’ te bu süreçlerin ne şekilde uygulandığına ve hangi destek araçlarının ne şekilde kullanıldığı incelenecektir. Bir yazılımın en temel yaşam döngüsünü, Gereksinimlerin Toplanması, Analiz, Tasarım, Geliştirme/Entegrasyon, Test ve Doğrulama, Yaygınlaştırma ve Bakım - Destek olarak tanımlayabiliriz. Bu faaliyetlerin her bir alt proje başlığı kabul gören bazı standartlar vardır. Bunlardan birisi artırımsal diğeri spiral modeldir. Kodsis her iki yöntem ile de geliştirme yapmaktadır. Bunun nedeni gelen ihtiyaçların ve kaynakların durumuna göre aksiyon alınabilmesidir. Kodsis projesi uygulamaları geliştirilirken Türksat bünyesinde geliştirilen tüm yazılım işlerini kapsayan ‘Güvenli Yazılım Geliştirme Talimatı’ esas alınmaktadır. Bu dokümanda standart yazılım geliştirme süreçlerini işaret etmektedir. 4.4.1 Gereksinimlerin Toplanması Müşteri birimlerden gelen talepler ilk olarak analistler tarafından ele alınarak talebin teknik olarak analiz yapılır. Doğru bir analiz aşaması ürünün verimliliği açısından büyük önem taşımaktadır. Bu sebeple analist kadrosunda yazılım süreçleri ve ürün hakkında tecrübe sahibi personellerin çalıştırılmasına büyük önem verilmektedir. Gereksinimlerin belirlenmesi müşteri ile etkin bir iletişim sürecini de gerektirir. Deneyimli bir iş analisti, müşteriden ihtiyaçları alırken çoğu zaman müşterinin ilerde talep edebileceği şeyleri de kestirip bunları analize dâhil eder. Ancak ne kadar deneyimli olursa olsun hiç bir iş analisti müşteriden tek seferde mükemmel bir analiz alamaz. Çünkü müşteri hiç bir zaman tam olarak ne istediğini bilmez, çoğu zaman müşteri uygulamanın ilk prototiplerini gördükçe aslında neye ihtiyacı olduğunu anlamaya başlar ve burada değişiklik istekleri gelmeye başlar. Bu nokta da ise Değişiklik Yönetim Sürecini başarılı şekilde yönetmek çok önemlidir. Yapılan analiz çalışmaları SRS(Software Requirements Specification) dokümanlarına işlenir. 4.4.2 Analiz SRS dokümanlarında yer alan talepler ile deneyimlere dayanılarak öngörülen durumlar dikkate alınarak ürüne ait iş akışları ve veri yapıları dokümante edilir. Bu iki aşamada müşteri ile çok sık temas kurularak sürekli müşteri onayı alınmaya ve eksik yerlerin tanımlanmasının yapılmasına çalışılır. Deneyimli bir analistin bu aşamada görev alması çoğu zaman müşterinin aklına gelmeyen durumları tespit ederek hatırlatması ve erken aşamalarda hata ihtimallerini azaltmasıdır. Kodsis kapsamında son dönem iyileştirme çalışmaları yapılarak bu aşama paralel olarak mimari ekibin de görüşleri dahil edilmiştir. Zira Kodsis ürününde yapılacak geliştirme ve değişiklik çalışmaları çoğu zaman diğer modülleri veya etkileşimde olduğu diğer sistemleri etkileyebilecektir. Bunu ise tüm yapıya en üstten bakabilen ve yeterince alan uzmanlığına sahip kişi ya da kişiler yapabilecektir. Mimari ekip bu aşamada etki analizleri yaparak müşteri tarafının taleplerinin muhtemel etki haritasını da çıkartmış olur. Bu çalışma ise yapılacak değişikliğin diğer sistemler üzerindeki muhtemel etkilerini tespit etmeye ve gerekiyorsa önleyici tedbirler almaya yönlendirir. Şekil 8 Örnek İş Akış Diagramı Şekil 7’ de analiz aşaması çıktılarından birisi olan iş akışı örneği verilmiştir. Tablo 2’ de ise mimari etki analizi çıktılarından birisi olan veri sahipliği tablosunu yer almaktadır. Tablo 2 Örnek Etki Analizi 4.4.3 Tasarım İş ve teknik analizler kapsamında gereksinimler belirlendikten sonra nihayetinde ortaya çıkacak uygulamanın mimari(teknik, sistemsel, veri yapısı, görsel) tasarımı ve teknik çözümlemesi yapılır. Eğer üründe kullanıcı ara yüzleri söz konusu ise bu ara yüzlere ait prototip çalışmaları yapılır. Bu arayüz hem müşterinin gereksinimlerini teyit etmek hem de yazılım geliştirme faaliyetini yürüteceklere kolaylık sağlamak amaçlıdır. Şekil 9 Prototip Ekran Örneği 4.4.4 Test Senaryolarının Hazırlanması Test, gerçekleşmek istenen projenin, müşterinin ihtiyaçlarını tam olarak kapsayıp kapsamadığının kontrolü, üretilen çözümün kalitesinin sağlanması ve canlı hayatta istenmeyen birçok durumun önüne geçilebilmesini sağlayan hayati önemdeki bir süreçtir. Analiz çıktıları ile üretilen test planı geliştirme faaliyetlerine paralel ve nihayetinde çalıştırılır. 4.4.5 Yazılım Geliştirme Gereksinim, analiz ve tasarım aşaması tamamlanmış olan talep, üretilmeye bu aşamada geçmektedir. Yazılım disiplinine sahip personeller tarafından ilgili yazılım geliştirme ortamları kullanılarak ürün geliştirilir. Yazılım geliştirme faaliyetlerini de standardize eden bir takım kural ve düzenlemelere ihtiyaç vardır. Zira uzman bir yazılımcı ile tecrübesiz bir yazılımcının aynı kalitede kod yazmaları beklenemez. Fakat kodlama ve mimari ile ilgili bir takım standartlar proje yöneticisi ve yazılım teknik ekip lideri tarafından önceden belirlenmiş olmak kaydıyla bu farklılıklar ortadan kaldırılabilir. Kodsis projelerinde yazılımcıların aynı standartları kullanmaları amacıyla “Kodlama Standartları Dokümanı” üretilmiş, ayrıca geliştirme dillerine ait frameworklerin kullanılması zorunlu hale getirilmiştir. Tüm yazılım geliştirme faaliyetleri gerçek sistemlere birebir benzeyen ancak gerçek verileri kapsamayan ve ‘Geliştirme’ olarak tanımlanan ortamlarda yapılır. Bu aşamada kodlamanın havuzlarında(repository) saklanmaktadır. her bir sürümü veri 4.4.6 Test ve Doğrulama Yazılım geliştiriciler tarafından üretilen ürün yapılandırma araçları vasıtasıyla tester ekibinin önüne gelir. İlk olarak test yapacak personel daha önce analizlere bağlı olarak üretilen test senaryolarını çalıştırır. Bu testlerde işlevsellik, stres, kullanabilirlik, birleştirme gibi test süreçleri işletilir ve sonuçları pozitif oluncaya kadar yazılım ekibine geri bildirimde bulunulur. Kullanıcı testlerinden başarı ile geçen yazılım ürünleri güvenlik testlerine tabi tutulmak üzere proje bilgi güvenliği ekine iletilir. Güvenlik testleri birçok işleve sahip hazır uygulamalar aracılığı ile gerçekleştirilir. Bu testlerde kod düzeyinde bir inceleme yapıldığı için ürün uygulamaya alındığında siber güvenlik açığı oluşturması muhtemel riskler içeren kod blokları ile yazılımın kalitesini düşürebilecek ve standartlara uygun olmayan kodlamalar otomatik olarak tespit edilir. Tespitler kapsamında riski yüksek ve orta olarak tanımlanan hatalar giderilmek üzere tekrar yazılım ekibine iletilir. Tüm iç testleri geçen ürün son bir test için müşteriye açılır. Müşteri genel olarak işlevsellik ve doğrulama testlerini yaptıktan sonra ürünü onaylar ve ürün test süreçlerini tamamlamış olur. 4.4.7 Yaygınlaştırma Yazılım geliştirme süreçleri sonucunda başarılı bir şekilde üretilen yazılım son kullanıcıların kullanımına açılır. Bu işlem için konfigürasyon yöneticisi test ortamlarında yer alan ürüne ait kodları canlı sisteme ilgili araçlar yardımıyla taşır. Ürüne ait eğitim ihtiyacı var ise operasyon ekibi kullanıcı dokümantasyonları üreterek ürün duyurusu ile birlikte tüm kullanıcılara elektronik posta yolu ile iletir. 4.4.8 Bakım Her ne kadar ürün geliştirme kapsamında analiz, tasarım, test aşamaları yer alıyor olsa da yaygınlaştırma sonrasında beklenmeyen hata durumları gerçekleşebileceği gibi, müşteri yeni ihtiyaçları da oluşabilmektedir. Bu kapsamda gelen talepler benzer yazılım geliştirme süreçlerinden geçerek ürünün yeni versiyonlarının çıkmasına sebep olmaktadır. 4.4.9 Operasyon Destek Yazılım devreye alındıktan sonra kullanıcıları kullanımlarına bağlı olarak çok farklı hatalar oluşabilmektedir. Bu hataların düzeltilmesini sağlayan ara yüzler olduğu gibi olmayanlar için Kodsis bünyesinde yer alan operasyon destek ekipleri son kullanıcılara yardımcı olmaktadırlar. Geçici rapor talepleri, tahsilatların mutabakatları, aylık faturalandırmalar, iş ortaklarına ait hak edişlerin üretilmesi, fatura hatalarının ve abonelik işlemlerindeki hataların düzeltilmesi ile son kullanıcılara yönelik eğitim desteği faaliyetleri bu kapsamda yürütülür. Ayrıca sistemlerin 24 saat hizmet vermesini sağlamak amacıyla izleme ekipleri tanımlı talimatlar kapsamında görev almaktadırlar. 4.5 Kullanılan Yardımcı Araçlar Kodsis projesinin geliştirme ve işletme süreçlerinin yürütülmesinde her bir aşama için çok farklı ek uygulamalar da kullanılmaktadır. Yan uygulamalardan alınan bu destek ekibin esas işine odaklanmasını ve üretkenliklerini artırmalarını sağlamaktadır. Günümüzde yazılım yaşam döngüsü süreçlerini yöneten ticari ve ticari olmayan pek çok uygulama yer almaktadır. Bunların bir kısmı uçtan uca çözümler sunarken bir kısmı ise başka sistemlere entegre olabilecek şekillerde üretilmektedirler. Yazılım sektörünün lokomotifi olan bir çok büyük firma kendi deneyimlerinden yola çıkarak piyasaya bu tarz ürünler sunmaktadırlar. Benzer şekilde kişisel hobi ürünleri olarak ya da sosyal projeler kullanılarak açık kaynak kodlu ürünler de yer almaktadır. Yazılım yaşam döngülerini yöneten bu tür yazılımlar standartlaşma ve ürün kalitesini artırmaya yönelik ciddi katkılar sağlamaktadır. Bunların en bilinenleri ticari ürünler IBM Rational, HP ALM, Borland Starteam, Microsoft Team Foundation Server’ dır. Ayrıca açık kaynak kodlu olarak tuleap, jabox dikkat çekmektedir. Kodsis kapsamında standart bir ürün paketi kullanılmamaktadır. Bunun yerine farklı aşamalar için kendi alanında öne çıkmış olan uygulamalar tercih edilmektedir. Analiz aşamalarının dokümantasyonunda MS Office, prototip çalışmaları için axure, iş akışları için MS Visio, kodlama ortamları olarak eclipse, ultraedit, konfigürasyon için kendi ürünü olan kip, veritabanı yönetimi ve geliştirmeleri için EMS, proje ve iş takipleri için redmine, doküman ve kod depolama için SVN kullanılmaktadır. Ancak son dönemlerde uçtan uca bir çözümü olan bir ürünün kullanılmasına yönelik ihtiyaç ve gereksinimlerin artması nedeniyle bu tür bir çözüm için çalışmalar başlatılmıştır. 4.6 Ürün ve Süreç İyileştirme Çalışmaları Her üründe olduğu gibi Kodsis’ te de gelişen yeniliklere, müşteri gereksinimlerine, mevzuat düzenlemelerine paralel olarak eskimeler, kullanımlara bağlı olarak hatalar tespit edilmekte ve yenilenme, eksiklikleri giderme ve iyileşme süreçleri başlamaktadır. Bu iyileştirmelerin tanımlı kurallar ve standartlar dahilinde yapılmasında CMMI olgunluk modellerinin üst seviyelerinde yer alınması sağlanabilecektir. Ancak tanımlı ve standart olmayan bir iyileştirme süreci olgunluk olarak ürünü ve firmayı ikinci level düzeylerinde tanımlayacaktır. Kalite literatürüne Kaizen felsefesi olarak geçen sürekli iyileştirme Kodsis için de genel kabul gören bir durumdur. Türksat ve Kodsis proje personelleri yazılım üretim süreçlerinde ortaya çıkan sonuçları değerlendirerek sürekli süreç iyileştirici faaliyetler planlamaktadırlar. Yazılım mühendisliği literatüründe ‘Walkthrough’ olarak tanımlanan bir çeşit ürün ve süreç iyileştirme modeli olan bir yöntem bulunmaktadır. Bu literatür kapsamında 2013 yılı içerisinde ‘Sahada Büyüteç’ sloganıyla bir iyileştirme projesi başlatılmıştır. Projenin amacı ürün geliştirme faaliyetlerinde bulunan personellerin tüm Türkiye’ de yer alan son kullanıcılar ile birebir yerinde iletişim kurarak Kodsis ürününde iyileştirme planları yapmasını sağlamaktır. Bu çalışmanın tetikleyici unsuru ise üründe kalitenin artırılması ve standartlar uygun hale getirilmesine yönelik yol adımlarının çıkarılmasıdır. Yapılan iş birimi ve il müdürlüğü ziyaretlerinde; Önceliklendirilmiş düzeltme ve iyileştirmelerin tespiti, Kullanım farkındalığının artırılması ve iyileştirilmesi, Kullanım farklılıklarının tespiti, Karşılanamayan iş gereksinimlerinin tespiti, Verilen hizmetlerin yönetiminin değerlendirilmesi, Karşılanan taleplerin yönetiminin değerlendirilmesi, Karşılanan regülatif taleplerin değerlendirilmesi, Kullanıcı memnuniyetinin ölçümlenmesi, Yazılım geliştirme ekibinin iş süreçleri farkındalığının artırılması Hedeflenmiştir. Yapılan ziyaretlerde her bir il için; Açılış toplantılarının Memnuniyet ve öneri anketlerin yapılması, Kodsis kullanım senaryoları üzerinden kontrol listesinin uygulanması tespitlerin uygunsuzluk, potansiyel uygunsuzluk ve iyileştirme/öneri olarak belirlenmesi, ilgili kanıtların kayıt altına alınması ve kullanıcı önceliğinin tespiti, KODSİS kullanım farkındalığının ölçümlenmesi için hazırlanan soruların sorulması ve cevapların kayıt altına alınması, Kullanım senaryolarının yaşanmış örneklerin kayıt (video formatında) altına alınması, Şikayet, beklenti, öneri vb. toplanması, Kapanış toplantısı yapılması Faaliyetleri yapılmıştır. Toplanan veriler üzerinden; İl Müdürlüğü ve İş Ortakları kapsamlı kontrol listelerinde belirlenen tespitlerin konsolide edilmesi, sınıflandırılması ve önceliklendirilmesi, Tespitin doğrulamasının yapılması, halihazırdaki durumla ilgili gerekli bilgilerin edinilmesi, Tespitlerin Telecom Application Map’deki uygulama alanları ile eşleştirilmesi, Mükerrer tespitlerin teke indirilmesi, KODSİS yazılım geliştirme önceliğinin belirlenmesi, Fraud (Hile) ve regülatif tespitlerin belirlenmesi, Tespit kök nedeninin sınıflandırılması (ürün/süreç/kullanım), Tespitin karşılanması için süreç planlama çalışması gerekiyorsa bu çalışmayı yürütecek ilgili süreç sahibi direktörlüğün belirlenmesi, Tespitin karşılanma süresinin sınıflandırılması (Hızlı kazanım: 9 adam saatten az, kısa vadeli 1 adam günden büyük 1 adam aydan küçük, orta vadeli 1 adam aydan büyük 6 adam aydan küçük, uzun vadeli 6 adam aydan büyük), KODSİS kaynaklı kritik ve ivedilikle giderilmesi gereken tespitlerin belirlenmesi, KODSİS’le ilgili olan ve hızlı kazanılabileceği öngörülenlerin KODSİS yazılım geliştirme uzmanının belirlenmesi, KODSİS tarafından yapılması uygun olmayan tespitlerin belirlenmesi. Anketlerin veri girişinin yapılması ve anket sonuçlarının değerlendirilmesi, Kullanım senaryoları video çekimlerinin envanterinin oluşturulması ve ortak alana kaydedilmesi, KODSİS yazılım belirlenmesi, geliştirme konsolide ekibinin edilmesi, KODSİS tespitlerinin sınıflandırılması ve önceliklendirilmesi, Halihazırda yürümekte olan ve planlanan projelerin belirlenmesi. Çalışmaları yapılmıştır. İl müdürlükleri ve iş ortakları ile yapılan çalışmalarda elde edilen tespitler incelendiğinde tespitlerden 316’sı (% 51,22) süreç, 282’si (% 45,85) ürün ve 18’i (% 2,93) kullanım kaynaklıdır. Yine aynı anket verilerine göre tespitlerden 300’ü (% 48,7) iyileştirme/öneri, (% 42,37) 261’i uygunsuzluk, 55’i (% 8,93) potansiyel uygunsuzluktur. Uygunsuzlukların % 57,47’si ürün kaynaklı, % 39,08’i süreç kaynaklıdır. İyileştirme önerilerinin % 61,33’ü süreç, % 36,33’ü ürün kapsamlıdır. Kullanıcı önceliklendirmesine göre tespit kök nedenleri dağılımı incelendiğinde her önceliklendirme için birinci kök neden süreç, ikincisi üründür. 200 180 160 140 120 100 80 60 40 20 0 Süreç Ürün Kullanım İyileştirme/ Öneri Uygunsuzluk Potansiyel Uygunsuzluk Şekil 10: Sahada Büyüteç Anket Sonucu 250 200 İyileştirme/ Öneri 150 Uygunsuzluk 100 Potansiyel Uygunsuzluk 50 0 1.Yüksek 2.Orta 3.Düşük Şekil 11: Sahada Büyüteç Anket Sonucu Aynı çalışmanın bir parçası olarak 170 Kodsis kullanıcısını katılımıyla yapılan değerlendirme anketi sonuçları ise aşağıdaki gibi sonuçlanmıştır. 6% İyiye doğru bir yönelim var Aynı seviyededir 30% 64% Kötüye doğru bir yönelim var Şekil 12 Kodsis Memnuniyet Anketi Anket sonuçları Kaizen yaklaşımı ile yapılan sürekli iyileştirmelerin kullanıcılar tarafında büyük oranda hissedildiğini göstermektedir. Kullanıcılar ‘KODSİS üzerinde yeni bir kampanya ya da özellik/hizmet başlatıldığında sağlanan açıklamaları ve bilgilendirmeyi yeterli buluyor musunuz?’ sorusuna ise aşağıdaki gibi cevap vermişlerdir. 2% 7% 8% Çok yeterli Yeterli 25% Orta seviyede Yetersiz 58% Çok yetersiz Şekil 13 Memnuniyet Anketi Bilgilendirme Sorusu Kullancılılar ‘14. KODSİS hizmetlerinde Operasyon - Destek Masası ile verilen desteği kalite açısından nasıl değerlendiriyorsunuz?’ sorusuna ise yine iyileşme ağırlıklı bir cevap vermişlerdir. 3% 0% Çok başarısız 2% 7% Başarısız 26% Kötüye doğru bir yönelim var İyiye doğru bir yönelim var Başarılı 62% Çok başarılı Şekil 14 Memnuniyet Anketi Kodsis Destek Değerlendirme Konsolide edilen veriler üzerinden ürün üzerinde ve üretim süreçlerinde iyileştirme çalışmaları halen devam etmektedir. Sonuç Telekomünikasyon sektöründe rekabetin çok boyutlu olması, büyük firmaların bu alandaki yatırımları ve çok hızlı gelişen teknolojik gelişmelere paralel olarak sektör firmalarının bilişim departmanlarına çok önemli sorumluluklar düşmektedir. Sürekli rakiplerin bir adım önünde olabilmek için çalışan pazarlama departmanlarından gelen yeni ürün ve iyileştirme talepleri, tüketiciyi koruma kanunları kapsamında artan müşteri hassasiyetleri ve müşteri ilişkileri talepleri, regülasyon kurumlarınca oluşturulan hizmet kalite standartları, hızla değişen ve dönüşen yazılım teknolojileri, kişisel bilgi güvenliği ve siber olaylar ile firmaların en temel amacı olan stratejik ve finansal hedeflere ulaşılması hususları dikkate alındığında telekomünikasyon bilişimi faaliyetlerinin hem çevik yöntemleri kullanması hem de kalite ve standardizasyondan ödün vermemesi kaçınılmaz bir gerçektir. Kaliteli bir yazılım ürünü geliştirebilmenin ilk şartı ise süreçlerin tam ve açık olarak belirlenmiş olması ve tüm paydaşların bu süreçlere tam olarak sadık kalabilmesidir. Toplam kalite alanlarında da çalışmaları bulunan ABD’ li bir istatistikçi deneyimlerine göre sorunların ve iyileştirme fırsatlarının %94'ü süreç ve sistem' den %6'sının ise diğer sebeplerden kaynaklandığını söylemektedir(Deming). Bu çalışmada örnek olarak incelenen Kodsis uygulaması da söz konusu tespitler ile doğrudan ilişkilendirilebilmektedir. Gerek şirket içi süreçler, gerek ürün ve hizmetlere ait iş süreçleri ve gerek de yazılım geliştirme iş süreçleri ne kadar doğru olarak tanımlanır ve sürekli iyileştirilirse o ölçüde başarı sağlanacaktır. Yapılacak ürün iyileştirme çalışmalarının farklı referanslar kullanılarak ölçülüyor olması ise başarıların kalıcı olmasını sağlayacak en önemli faktör olacaktır. KAYNAKÇA Akmut, Özdemir. 1976. Proje Planlama ve Kontrol Yöntemleri. Erzurum: Atatürk Üniversitesi Yayınları. Albayrak, Burhan. 2009. Proje Yönetimi ve Analizi. İstanbul: Nobel Yayın Dağıtım. Anderson, David. ve Merna, Tony. 2003. “Project Management Strategy,” International Journal of Project Management 21: 387-393. Berkun, Skott. 2005. The Art of Software Project Management (1. Baskı). California: O’Reilly Medya Yayınları. Cleland, D. ve King, W. 1983. Project Management Handbook. New York: Van Nostrand Reinhold Co. Dengiz, G. Murat, Aydın Erceiş, Osman Karadağ ve Erkan Şahmalı. 1998. Proje Yönetimi Bilgi Kitabı. Ankara: Proje Yönetimi Derneği Yayınları Duncan, R. William. 2000. Guide to Project Management Body of Knowledge (3.rd Ed.). USA: PMI Standarts. Erkan, Levent. 2011. Proje Yönetimi Ders Notları. Ankara: TOBB ETÜ. Gartner Araştırma Şirketi. ‘Telekom IT Olgunluk İstatistikleri’, http://evds.tcmb.gov.tr/ (Erişim Tarihi: 07.07.2013). Hughes, Bob ve Mike Cotterell. 2006. Software Project Management(4. Baskı). Berkshire: McGrawHill Yayınları Kollektif. 2010. Proje Yönetimi Bilgi Birikimi Kılavuzu (PMBOK) (4. Baskı). İstanbul: PMI TR Yayınları. Lester, Albert. 2006. Project Management, Planning and Control (5.th Ed.). Boston: Butterworth-Heinemenn. Mekik, Murat Cem. 2007. Zen ve Uygulamalı Proje Yönetim Sanatı (1. Baskı). Ankara: Matus Yayınları. Sulc3. ‘Yazılım Geliştirme Modelleri’, http://sulc3.com/model.html(Erişim Tarihi: 11.07.2013) Tunç, Hazal. 2011. Bir Mühendislik Firmasında Proje Yönetimi Uygulaması. Ankara: TOBB ETU. “The New Economics” 1994 – Ch. 2 -The Heavy Losses-, page 33 http://tr.wikipedia.org/wiki/Kaizen http://www.eurocons.com.tr/puko_dongusu-bilgi_bankasiW.Edwards%C2%A0Deming%C2%A0ve%C2%A0PUKO%C2%A0D%C3%B6ng%C 3%BCs%C3%BC.html
