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 Projesi, Yazılım Proje Yönetimi,

Telekomünikasyon Bilişimi

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 Project, Software Project Management,

Telecomunication IT

İÇİ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 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

2.3 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.3.1 Kodsis İlişki Ağı .................................................................... xlvii

4.3.2 Kodsis Organizasyon Yapısı ................................................. xlviii

4.4 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 sunmaya yönelik olarak bilginin dağıtılması, performans

bilgilerinin derlendiği ve yayınlandığı performansın 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ü herhang i

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 metotlar gereksinimleri

karşılamayan yazılım geliştirme riskini azaltır.

Şekil 6 Çevik Geliştirme Zamana Göre Değişim

3.2 Telekomünikasyon Bilişimi Kalitesi İle İlişkili

Standartlar, Modeller, Organizasyonlar

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ş telekomünikasyon süreçleri haritası),

SID(Paylaşılan Bilgi Veri), TAM(telekom uygulamaları 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 eğitim, yetiştirme, gelişmeye önem verip

uygulamaya girişilmesini ekip oluşturmayı ve çalışanları 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 PUKO Aşamaları

3.2.7.1.1 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 Uygula

PUKO 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 Kodsis’ te artırımsal geliştirme metodolojisi

uygulanmaktadır.

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 çelişkili durumlar ortaya çıkardığı

gözlemlenmektedir.

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 İlgili Modüller Yoğunluk

1 Pazarlama ve Satış

Direktörlüğü

Abonelik, Kampanyalar, Faturalar,

Raporlar, Hakediş, online hizmetler,

10

2 Müşteri İlişkileri

Direktörlüğü

Çağrı Takip, MİYOS Abonelik,

Raporlar, Hakediş, Fatura

10

3 İnternet ve

İnteraktif Hizmetler

Direktörlüğü

Mediation uygulamalar, Stok

Yönetimi

10

4 Kablo Sistemleri

Altyapı

Direktörlüğü

Tesis Takip, Taşeron yönetimi, Proje

Yönetimi, Stok Yönetimi, Mediation

uygulamalar, Raporlar, Hakediş

10

5 Hukuk Müşavirliği İcra Takip, Hasar Takip, Raporlar, 7

6 İl Müdürlükleri Abonelik, fatura, Tahsilat, arıza,

hukuk, Mediation

8

7 Muhasebe

Direktörlüğü

Fatura, tahakkuk- icmal raporları, stok

raporları, bütçe raporları, efatura

takibi

4

8 Finans Direktörlüğü Tahsilat, bankaların takibi, online

ödeme sistemleri, pos sistemleri,

mutabakat raporları, kamu tahsilatları,

kampanya maliyet raporları

4

9 Yönetim Geliştirme

Direktörlüğü/ Üst

Yönetim

Kalite Raporları, Bütçe-Hedef

raporları, performans raporları

2

10 Bütçe ve Mali

Kontrol

Direktörlüğü

Bütçe Raporları, Abone İstatistikleri,

Hedef raporları,

2

14 Üst Yönetim Abone İstatistikleri 1

16 Bankalar(26) Online-offline tahsilatların ve

mutabakatların takibi

4

17 PTT Abonelik İşlemleri ve tahsilat 4

18 Taşeronlar Abonelik, Servis, destek, altyapı

yönetimi

3

19 Çözüm Ortakları Abonelik İşlemleri 2

20 Çağrı Merkezi Abonelik, arıza, teknik destek

hizmetleri

5

22 Online web sitesi Abonelik hizmetleri entegrasyonu 4

23 CNR / CMTS /

UTM / Conax /

SMS/DPİ

Abonelik – Mediation, orta katmanı

yazılım entegrasyonları

10

25 BTK IP Log 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 her bir sürümü veri

havuzlarında(repository) saklanmaktadır.

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 geliştirme ekibinin KODSİS tespitlerinin

belirlenmesi, konsolide edilmesi, 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.

Şekil 10: Sahada Büyüteç Anket Sonucu

Ş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.

0

20

40

60

80

100

120

140

160

180

200

İyileştirme/Öneri

Uygunsuzluk PotansiyelUygunsuzluk

Süreç

Ürün

Kullanım

0

50

100

150

200

250

1.Yüksek 2.Orta 3.Düşük

İyileştirme/Öneri

Uygunsuzluk

PotansiyelUygunsuzluk

Ş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.

64%

30%

6%

İyiye doğru bir yönelimvarAynı seviyededir

Kötüye doğru bir yönelimvar

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.

Ş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.

8%

58%

25%

7%

2%

Çok yeterli

Yeterli

Orta seviyede

Yetersiz

Çok yetersiz

Ş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.

0%

7% 2%

62%

26%

3% Çok başarısız

Başarısız

Kötüye doğru biryönelim var

İyiye doğru bir yönelimvar

Başarılı

Çok başarılı

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_bankasi-W.Edwards%C2%A0Deming%C2%A0ve%C2%A0PUKO%C2%A0D%C3%B6ng%C3%BCs%C3%BC.html