Tümleşik VoIP Sistemlerinde Gereksinim Analizi Ve Tasarım Maliyet Yaklaşımı Fatih Ayvaz1, Selçuk Mitmit1, Aycan Demirsoy1, Ayşe Belma Şahin-Kaya1, Ali Yıldırım1, Oğuzhan Yavuz1 1 Netaş Telekomünikasyon A.Ş, İstanbul, Türkiye {fayvaz, smitmit, aycan, belmas, aliyil, oyavuz}@netas.com.tr Özet. Bu çalışmada haberleşme sistemlerinde (VoIP, TDM) yazılım süreçlerin- de gereksinim analizi yapılması ve oluşturulan yazılım mimari tasarım doğrul- tusunda tasarım maliyet hesaplarının yapılışına ilişkin Netaş’ın sahip olduğu bilgi birikimi ve tecrübe paylaşılmıştır. TÜBİTAK TEYDEB tarafından destek- lenmiş olan “Yüksek Kapasiteli Yeni Nesil Merkezi Santral Tasarımı” isimli projenin tasarım maliyet tahmininin yapılması anlatılmıştır. Anahtar Kelimeler: Yazılım Süreçleri, Gereksinim Analizi, Tasarım Maliyet Tahmini, VoIP Sistemleri, Proje Planlama 1 Giriş Bir haberleşme ağının çalışması donanımsal alt yapının yanında onun üzerine çalışan yazılım ile sağlanmaktadır. Haberleşme sistemlerinde yapılan değişiklikler donanım- dan çok yazılım üzerinde yapılmaktadır. Bunun nedeni operatörlerin sistemlerini yük- sek maliyetleri nedeniyle donanımsal olarak değiştirmekten çekinmeleridir. Bu yüz- den yeni nesil teknolojileri destekleyen donanımların yanında hala eski nesil teknolo- jileri destekleyen donanımlar da ağ içerisinde kullanılmaktadır. Haberleşme sistemlerindeki ArGe faaliyetleri genel olarak mevcut donanım üze- rinde yazılım geliştirmelerini kapsamaktadır. Mevcut kaynakların daha iyi kullanımı, pazar stratejileri, rekabet, teknolojik gelişmeler, büyüme isteği ve tüketici tercihleri- nin değişmesi gibi nedenlerle yeni gereksinimlere ihtiyaç duyulur. İnternet Üzerinden Ses İletişimi (Voice over Internet Protocol, VoIP) sistemleri [1] karmaşık bir yazılım mimarisine sahiptir. Bunun sebebi Çekirdek (Core), Ağ Geçidi (Gateway, GW), Ağ Geçidi Denetleyicisi (Gateway Controller, GWC), Oturum Trank Sunucusu (Session Server Trunk, SST) ve İşletim Yönetim, Bakım ve Yapılandırma Birimi (Operations, Administration, Maintenance and Provisioning, OAM&P) gibi bileşenlerden oluşan tümleşik bir sistem olmasıdır [2]. Bu sebeple yazılım geliştirme projelerinde gereksi- nimlerin açık ve net bir şekilde belirlenmesi ve mimariye uygunluğunun ölçeklendiri- lebilmesi büyük önem taşımaktadır. Oldukça zor bir alan olan yazılım geliştirme pro- jelerinin gereksinimlerinin –zaman, çalışan- belirlenmesi ve risk analizlerinin yapıl- masında Netaş zengin bir bilgi birikimine sahiptir. Bu çalışmada Netaş’ın yazılım geliştirme projelerinin uyguladığı yöntemler ve tecrübeleri paylaşılmıştır. 501 Bu yayın dört bölümden oluşmaktadır. Bölüm 2’de tümleşik VoIP sistemlerinde gereksinimlerin belirlenmesi ve yazılım geliştirme süreçleri anlatılmıştır. Bölüm 3’te tümleşik VoIP sistemlerinde gereksinim analizi ve tasarım maliyet tahmini deneyimi- ne yer verilmiştir. Son bölümde ise genel değerlendirmelere ve sonuçlara değinilmiş- tir. 2 Tümleşik VoIP Sistemlerinde Gereksinimlerin Belirlenmesi ve Yazılım Geliştirme Süreçleri Gereksinim, bir sorunu çözmek ya da bir hedefe ulaşmak için müşteriler tarafından ihtiyaç duyulan bir koşul ya da yetenektir. Diğer bir ifadeyle gereksinim, bir sözleş- meyle tanımlanan ve bir ürün veya ürün bileşeni tarafından karşılanması ya da sahip olunması gereken bir durum, yetenek, standart, şartname ya da diğer resmi belgelerdir [4]. Tümleşik VoIP sistemlerinin müşterileri dünya genelindeki büyük operatör ve hizmet sağlayıcı firmalardır. Bu firmalar mevcut kaynakların daha iyi kullanımı, pa- zar stratejileri, diğer firmalarla rekabet, teknolojik gelişmeler, büyüme isteği ve tüke- tici tercihlerinin değişmesi gibi nedenlerle yeni gereksinimlere ihtiyaç duyarlar. Tüm- leşik VoIP sistemleri karmaşık bir yazılım mimarisini sahiptir ve bu sebeple yazılım geliştirme projelerinde gereksinimlerin açık ve net bir şekilde belirlenmesi ve mima- riye uygunluğunun ölçeklendirilebilmesi büyük önem taşımaktadır. Bu sebeple tümleşik VoIP sistemlerinde, geleneksel yazılım geliştirme süreçlerin- den biri olan Şelale süreci (Waterfall process) [5] uygulanmaktadır. Şelale süreci, Şekil 1’de görüldüğü gibi birbirini takip eden ardışık fazlardan oluşmaktadır ve son- raki faz bir önceki faz tamamlanmadan başlamamaktadır. Şekil 1. Şelale Süreci Şekil 2’de bir tümleşik VoIP sisteminde yer alan yazılım süreçleri gösterilmiştir. Bu süreçlerde iş geliştirme (business development) ekipleri geliştirilecek ürünün pa- zarda tercih edilebilirliğini ve pazar payını artırmanın yollarını ararlar. Ayrıca rakip firmalar içerisinde öncü ve yenilikçi olmak ve şirketin kazancını ve sürekliliğini ar- 502 tırmak için süreç boyunca çalışmalarını sürdürürler. Tasarım ekipleri ise müşteriler- den gelen gereksinimlere uygun mimari tasarımlar yapar, uygular ve sistem doğrula- malarını gerçekleştirirler. Şekil 2. Tümleşik VoIP Sistemlerinde Yazılım Geliştirme Süreçleri Şekil 2’de görüldüğü gibi tümleşik VoIP sistemlerinde yazılım geliştirme ardışık iki temel süreçte ilerlemektedir: 2.1 İş Planlama Süreci İş planlama sürecinde, ürün müdürleri, satış müdürleri ve çözüm mimarları, müşteri- lerle görüşerek, gereksinimleri ve müşterilerin ihtiyaçlarına katkıda bulunacak yeni teknolojik çözümleri ve fikirleri belirlerler. Bu süreçte “planlama” seviyesi tasarım maliyet tahmini (TMT) yapılır ve belirlenen tüm gereksinimlerin teknik olarak yapı- labilir olup olmadığı; eğer yapılabilir ise insan kaynağı ve donanım maliyet dereceleri düşük (2 adam-yıldan az), orta (5 adam-yıldan az) veya yüksek (5 adam-yıldan fazla) olmak üzere ortaya çıkarılır. Bu süreçte tasarım ekipleri rol almamaktadır. 2.2 Yazılım Sürüm Planlama ve Geliştirme Süreci İş planlaması yapılan gereksinimler sürüm planlama ve geliştirme sürecine sokulur. Bu süreçte iş geliştirme ve tasarım ekipleri birlikte çalışır ve her iki ekibin de kendile- rine özgü ardışık süreç fazları ve her fazda elde ettikleri çıktılar vardır. Fikir Fazı (Idea Phase): Müşteri ve pazarın ne istediğinin ve problemin iş (busi- ness) bakış açısıyla tanımlandığı fazdır. Ürün müdürleri tarafından fikir seviyesi özel- lik gereksinim dokümanı (ÖGD) hazırlanır. Bu fazda tasarım ekiplerinde yer alan yazılım mimarları tarafından ÖGD’de yazılan gereksinimlerin “anlaşılmış” (unders- tood) olması gerekmektedir. Tanımlanan gereksinimlerin müşteri istekleri ve beklenti- 503 leri doğrultusunda önceliklendirilmesi yapılır. Önceliklendirilmiş gereksinimler iş paketlerine dönüştürülür ve çıkarılacak olan yazılım sürümüne “aday bir içerik listesi” (candidate content list, CCL) olarak dâhil edilir. Fikir fazı tamamlandığında Sürüm Başlangıcı (SB) deklare edilmiş olur. Bu fazda yazılım mimarları tarafından yapılan analizler sonucu ±%50 yanılma oranlı adam-ay (staff month, SM) ÖGD seviyesi TMT dokümanını hazırlanır. Çıkan maliyete göre aday içerik listesinde yer alan gereksinimlerin yazılım sürümünde yer alıp almaması- na tasarım ekiplerindeki insan kaynağının uygunluğuna göre karar verilir ve önceliği düşük olanlar listeden çıkartılır. Fırsat Fazı (Opportunity Phase): Tasarım ekipleri gereksinimler üzerinde mimari tasarım ve analiz çalışmalarına başlarlar. Gereksinimler ürün özelliklerine göre şekil- lendirilir ve yeni türetilmiş (derived) gereksinimler oluşturulur. Bu fazda tüm gereksi- nimlerinin tasarım ekibi tarafından “tanımlanmış” (defined) olması ve ürünle uyumlu olup olmadığının belirlenmiş olması gerekmektedir. Tanımlanması yapılmış ve ürün- lere uyumluluğu incelenmiş gereksinimler fırsat seviyesi özellik teknik dokümanında (ÖTD) toplanır. Yazılım sürümüne dâhil edilecek iş paketlerinin listesi (Plan of In- tent, POI) bu fazda belirlenmiş olur. Yazılım mimarları tarafından oluşturdukları mimari tasarım alternatifleri ile birlik- te ileri seviye tasarım (İST) dokümanında belgelenir ve çözüm mimarları ve sistem mimarları ile tartışılır. Sürecin tamamlanması için doküman onayının alınması ge- rekmektedir. Yazılım mimarları onay alınan mimari tasarım için ±%20 yanılma oranlı adam-ay (staff month, SM) tasarım maliyet tahminini (design estimation) belirlerler. Bu amaçla ÖTD seviyesi tasarım maliyet tahminini (TMT) dokümanını hazırlanır. Proje müdürleri tarafından ÖTD seviyesi TMT’deki maliyete göre proje planları oluş- turulur ve tasarım müdürleri ile koordineli çalışılarak tasarım yapacak olan yazılım mühendisleri belirlenir. Tasarım ekipleri bu fazı Tasarım Fazı 0 (TF0) olarak adlandırır. Fırsat Fazı tamam- landığında iş geliştirme ekiplerinde Pazara Hazırlık (PH) tasarım ekiplerinde ise TF0 deklare edilmiş olur. Tanımlama Fazı (Definition Phase): Tasarım ekipleri belirlenen mimari tasarım ile ilgili detaylı teknik analizler ve araştırmalar yaparlar. Bu fazda yapılan detaylı çalışmalar neticesinde gereksinimlerin müşteriye “tahaddüt” (committed) edilmesi gerekmektedir. Fırsat fazında yazılmış olan ÖTD güncellenir. Yazılım sürümüne dâhil edilecek “onaylı” iş paketlerinin listesi (Plan of Record, POR) bu fazda belirlenmiş olur. Tasarım ekipleri tarafından müşteriye sunulmak üzere İşlevsel Tanım (Functional Description, FD) dokümanı yazılır. Daha önceki fazlarda tanımlanmış gereksinimlerle ilgili herhangi ve değişiklik veya yeni bir istek olursa bu doğrultuda içerik listesi ve tahmini tasarım maliyeti ±%5 yanılma oranlı olarak güncellenir. Yazılım test ekipleri bu fazda devreye girerler ve İşlevsel Tanım dokümanında belirlenen kapsama göre test stratejilerini (laboratuvar ortamı, kurulum, teçhizat tedarik vb.) belirlerler. Tasarım ekipleri tarafından tanımlama fazı Tasarım Fazı 1 (TF1) olarak adlandırı- lır. Tanımlama Fazı tamamlandığında iş geliştirme ekiplerinde Ticari Hazırlık (TH) tasarım ekiplerinde ise TF1 deklare edilmiş olur. Uygulama Fazı (Implementation Phase): Bu fazda tasarım ekipleri proje müdür- lerinin liderliğinde kodlama çalışmalarına başlarlar. Yazılan ve kod kapsam (code 504 coverage) testleri yapılmış kodlar yazılım mühendisleri tarafından organize edilen toplantılarda (code inspection) yazılım mimarları tarafından detaylı bir şekilde incele- nir; onaylanan kodlar kod deposuna (code repository) yüklenir. Kod deposuna yükle- nen kodlar haftalık olarak derlenir ve laboratuvar ortamında kullanılmak üzere yazı- lım yükü oluşturulur. Yazılım mühendisleri yazdıkları kodların birim testlerini (unit test) bu laboratuvarlarda koştururlar. Yazılım test mühendisleri test edecekleri alanları ve senaryoları detaylandırarak işlevsel doğrulama (Functional Verification, FV) do- kümanlarını hazırlarlar. Tasarım ekipleri tarafından iş paketindeki kodlama ve birim testler tamamlandı- ğında Tasarım Fazı 2 (TF2) deklare edilir. Yazılım test mühendisleri işlevsel doğru- lama testlerini başlatarak kapalı kutu (black box) olarak iş paketininin işlevselliğini test ederler. Testler sonucu raporlanan problemleri çözmek için yazılım mühendisleri tarafından yeni kod değişikleri yapılır. Tasarım ekipleri tarafından iş paketindeki işlevsel doğrulama tamamlandıktan son- ra Tasarım Fazı 3 (TF3) deklare edilir. Sistem doğrulama ekipleri iş paketinin sürüm- deki diğer iş paketleri ve mevcut sistem davranışına etkilerini test etmek için sistem doğrulama testlerine başlarlar ve buldukları problemleri, sürümdeki diğer iş paketleri ile etkileşimlerini ve sistem davranışlarına uyuşmayan durumları web tabanlı JIRA [6] izleme aracı üzerinden kayıt açarak yazılım mühendislerine raporlarlar. Yazılım mühendisleri raporlanan problemleri kod deposuna sistem doğrulama mühendisinin açığı JIRA numarası ile girer. Sistem doğrulama mühendisi girilen kod ile derlenmiş yazılım yükünü laboratuvar ortamına yükleyerek test eder. Eğer sorun çözülmüş ise açılan JIRA kapatılır. Sistem doğrulama ekibi tüm testler tamamlandıktan ve prob- lemler çözüldükten sonra test ilk geçiş (test first pass) ilan ederler. Test ilk geçiş son- rası raporlanan problemler ve kritik test senaryoları tekrar koşturulur. Sistem doğru- lama problemsiz bir şekilde tamamlandığında ve tüm JIRA’lar kapandıktan sonra tüm yazılımın son derlemesi (Final Compile) yapılır ve sürüm kod girişine kapatılır ve tasarım ekipleri tarafından Sistem Doğrulama Fazı-1 (SD1) deklare edilir. Sistem doğrulama mühendisleri son derleme sonrası oluşturulan yazılım yükü ile nihai değerlendirme (final assessment) testleri yaparlar ve bulunan problemler web tabanlı JIRA izleme aracı ile yazılım mühendislerine raporlanır. Yazılım mühendisleri raporlanan problemler için buldukları kod çözümlerini derleme yapılamadığı için sürüme yazılım yaması (software patch) olarak yazarlar. Nihai değerlendirme testleri problemsiz bir şekilde tamamlandığında ve yazılım yamaları yazılarak tüm JIRA’lar kapandıktan sonra, tasarım ekipleri tarafından Sistem Doğrulama Fazı 2 (SD2) dekla- re edilir ve uygulama fazı tamamlanmış olur. Müşteri Maruziyet Fazı (Customer Exposure Phase) ve Yayılım Fazı (Deploy- ment Phase): Uygulama fazının sonlanması İş geliştirme ekipleri tarafından İlk Müş- teri Maruziyet (İMM) deklarasyonu ile birlikte müşteri maruziyet safhasına geçilir ve sistem doğrulaması yapılmış yazılım sürümünün müşterilere sunulması için hazırlık sürecidir (personel, teçhizat tedarik, saha destek vs.). Bu faz tamamlandıktan sonra yazılım sürümü için Genel Kullanılabilirlik (GK) deklare edilir ve müşterilere yayılı- mı (deployment) yapılır. 505 3 Tümleşik VoIP Sistemlerinde Gereksinim Analizi ve Tasarım Maliyet Tahmini Deneyimi Bu çalışmada TÜBİTAK TEYDEB tarafından 3130632 proje numarası ile desteklene- rek yürütülen “Yüksek Kapasiteli Yeni Nesil Merkezi Santral Tasarımı” isimli proje- nin TF0 deklare edilene kadar olan Netaş deneyimleri anlatılmaktadır. Şekil 3’te görüldüğü gibi “Yüksek Kapasiteli Yeni Nesil Merkezi Santral Tasarı- mı” projesi müşteri gereksinimlerinin doğrultusunda altı iş paketine dönüştürülmüş- tür. Şekil 3. Yüksek Kapasiteli Merkezi Yeni Nesil Santral Tasarımı İş Paketleri 3.1 Gereksinim Analizi Fikir fazında ürün müdürler tarafından her bir iş paketinin fikir seviyesi ÖGD dokü- manları hazırlanmıştır. Yapılan ÖGD’deki tüm gereksinimler önceliklendirilmiş ve tasarım ekibi tarafından anlaşılmıştır. Şekil 4A’da iş paketine göre ÖGD gereksinim- leri listelenmiştir. Fırsat fazlarında fikir fazında belirlenen gereksinimler ile ilgili kodsal teknik ana- lizler yapılmış ve bu analizler sonucu iş paketlerinin mimari tasarımlarının;  İş paketi 1, 2 ve 3’ün PROTEL/PROTEL2 [7] programlama dilini kullanan çekirdek bileşeninde,  İş paketi 4 ve 5’in C/C++ programlama dilini kullanan SST bileşeninde,  İş paketi 6’nın JAVA programlama dilini kullanan CMTg bileşeninde, olacağı belirlenmiştir. Bu fazda fırsat seviyesi ÖTD’ler hazırlanmıştır. ÖTD’de müş- teri gereksinimlerinin yanında türetilmiş gereksinimler de listelenmiştir. Şekil 4A ve 4B’de iş paketine göre ÖTD gereksinimleri gösterilmiştir. Şekil 4A’da verilen grafik önceliğe göre listelenmiş fikir seviyesi ÖGD gereksi- nimlerini içermektedir. Grafikte görüldüğü gibi en fazla gereksinim iş paketi 6’dadır. 506 Bunun sebebi iş paketi 6’nın ağırlıklı olarak grafik arayüz tabanlı bir çözüm olması ve kullanıcıya görünür çok fazla gereksinimin belirlenebiliyor olmasıdır. Diğer iş paket- lerinde yapılacak tasarımlar ilgili bileşenlerin altyapısında olduğundan iş (business) bakış açısıyla belirlenen gereksinimlerin sayısı azdır. Şekil 4B’de verilen grafik önceliğe göre listelenmiş fırsat seviyesi ÖTD gereksi- nimlerini içermektedir. Zorunlu gereksinimlere sayıları iş paketi 1’de %51, iş paketi 2’de %166, iş paketi 3’te %100, iş paketi 4’te %118, iş paketi 5’te %205 iş paketi 6’da ise %34 artmıştır. Diğer gereksinimlerde de kayda değer artışlar olmuştur. Şekil 4. Yüksek Kapasiteli Merkezi Yeni Nesil Santral Tasarımı Gereksinim Analizleri Şekil 4C’de verilen grafikte, türüne göre listelenmiş gereksinimler belirtilmiştir. Ürünün altyapısında tasarım yapacak olan iş paketlerinde türetilmiş gereksinimlerin oranının daha fazla olduğu dikkat çekmektedir. Özellikle iş paketi 1’de %74 iş paketi 5’te ise %378 oranında gereksinim artışı olmuştur. Şekil 4D’de verilen grafikte, ÖGD-ÖTD karşılaştırması yapılmış ve yine ürün alt- yapısında tasarım yapılacak iş paketlerinde gereksinim artışı dikkat çekmektedir. 3.2 Tasarım Maliyet Tahminleri Çözüm mimarları iş planlaması sürecinde proje kapsamında yer alacak gereksinimle- rin tahmini maliyetinin yüksek (5 adam-yıldan fazla) olduğu belirlenmiştir. Yazılım sürüm planlama ve geliştirme sürecinde ise yazılım mimarları tarafından Şekil 5’te belirtilen akış doğrultusunda tasarım maliyet tahmini belirleme çalışmaları yapılmış- tır. Fikir seviyesinde yazılım mimarları, ürün müdürleri ve çözüm mimarları ile anlaş- tıkları gereksinimler doğrusunda ÖGD seviyesi TMT dokümanını hazırlamışlardır. 507 Fırsat seviyesinde ise yazılım mimarları, İST sonrası oluşan gereksinim ve TMT deği- şikliklerini tasarım müdürleri, ürün müdürleri ve çözüm mimarları ile anlaşarak tasa- rım maliyet güncellemesi yaparak ÖTD seviyesi TMT dokümanını hazırlamışlardır. Şekil 5. Fikir ve Fırsat Fazı Tasarım Maliyet Tahmini Belirleme Akış Diyagramı Fikir ve fırsat fazlarında hazırlanan TMT dokümanlarında belirlenen tahmini tasa- rım maliyetlerinin iş paketi bazında yüzde dağılımları Şekil 6’da verilmiştir. Şekil 6. Yüksek Kapasiteli Merkezi Yeni Nesil Santral Tasarımı Tasarım Maliyet Tahminleri 508 Şekil 6A’da verilen grafikte ÖGD seviyesi TMT ile ÖTD seviyesi TMT arasındaki değişimler verilmiştir. ÖTD ile gelen türetilmiş gereksinimler ve yapılan teknik ana- lizler neticesinde iş paketi bazında tahmini tasarım maliyetlerinde değişimler olmuş- tur. Tasarım maliyetinde yüzdesel olarak en fazla artırım iş paketi 1’de %9.12 oranın- da yapılırken en fazla azaltma ise iş paketi 5’te %6,90 oranında yapılmıştır. Şekil 6B ve 6C’de iş paketlerinin ÖGD ve ÖTD seviyesi tahmini tasarım maliyet- lerine yüzdesel dağılımı gösterilmiştir. Grafikten de görüleceği gibi ürün altyapısında tasarım gerektiren iş paketlerindeki maliyet oldukça yüksektir. Özellikle iş paketi 1’deki maliyet dikkat çekmektedir. Bunun sebebi iş paketi 1’deki yapılacak olan kod- lamaların sistem altyapısında köklü değişiklikler yapmasıdır. Kodlama ile birlikte işlevsel ve sistem doğrulama anlamında da yüksek bir maliyet vardır. Çekirdek bile- şeninin karmaşıklığı ve tüm sistemi etkileyen riskler nedeni ile tasarım maliyeti bu şekilde belirlenmiştir. 4 Sonuçlar Bu çalışmada anlatılan “Yüksek Kapasiteli Yeni Nesil Merkezi Santral Tasarımı” projesinin proje planlaması, TF0 sonunda belirlenen adam-ay türünden belirlenen tasarım maliyet tahminine göre yapılmıştır. Fırsat fazında yazılım mimarları tarafın- dan yapılan mimarı tasarım, teknik analizler ve belirlenen riskler neticesinde; fikir fazından belirlenen yazılım tasarım maliyeti %5.06 oranında artış göstermiştir. Proje müdürleri müşterilerin beklentileri ve tasarım ekiplerindeki mevcut insan kaynakları- nın uygunluğunu ve yazılım mimarları tarafından belirlenen teknik riskleri göz önün- de bulundurularak, projenin başlangıcından SD2 deklare edilene kadar geçen süreyi 19 ay olarak planlamıştır. Bu proje sistem kapasitesinde ve altyapısında ciddi değişik- liklere neden olduğu için; yapılan planlama, müşteriler tarafından makul karşılanmış ve sürüm geçiş planlamalarını bu doğrultuda yapmışlardır. Ancak teknolojik eğilimler ve pazarda rekabet doğrultusunda bazı gereksinimlerin daha hızlı bir şekilde sağlan- masını istenebilmektedir. Bu tarz projelerde farklı yazılım tasarım süreçleri uygulan- maktadır. Bilgilendirme Bu çalışmada adı geçen, “Yüksek Kapasiteli Yeni Nesil Merkezi Santral Tasarımı” TÜBİTAK-Teknoloji ve Yenilik Destek Programları TEYDEB tarafından 3120226 numaralı proje olarak desteklenmiştir. Kaynakça 1. Goode, B., “Voice over Internet Protocol (VoIP)”, Proceedings of the IEEE, vol. 90 (6), pp. 1495-1517, (2002). 509 2. Aktürk, E., Demirkıran F., Uysal Ö., Hacıbeyoğlu B., ve Yavuz O., “IMS-TDM Entegras- yonu: AGCF Çözümü” IEEE 22. Sinyal İşleme ve İletişim Uygulamaları (SİU 2014), pp.1495-1498, (2014). 3. Henning, S., ve Rosenberg, J., “The Session Initiation Protocol: Internet-centric signaling” IEEE Com. Magazine, vol. 38(10), pp.134-141, (2000). 4. IEEE Standard Glossary of Software Engineering Terminology, lEEE Std 610.121990 (Sep. 28), Reaffirmed Sep. 2002, IEEE Press, New York, (2002). 5. http://tr.wikipedia.org/wiki/Waterfall_model. 6. https://www.atlassian.com/software/jira. 7. Cashin, P. M., Joliat, M. L., Kamel,R. F. ve Lasker, D. M., “Experience with a modular typed language: PROTEL”, Proceedings of the 5th international conference on Software engineering ICSE '81, pp.136-143, (1981). 510