Çoklu Ürün Hatları için Hazırlanan Mimari Bakış Açıları ile Radar ve Elektronik Harp Alanının Mimari Tasarımı

Ebat: px
Şu sayfadan göstermeyi başlat:

Download "Çoklu Ürün Hatları için Hazırlanan Mimari Bakış Açıları ile Radar ve Elektronik Harp Alanının Mimari Tasarımı"

Transkript

1 Çoklu Ürün Hatları için Hazırlanan Mimari Bakış Açıları ile Radar ve Elektronik Harp Alanının Mimari Tasarımı Bedir Tekinerdoğan 1, Özgü Özköse Erdoğan 2, Onur Aktuğ 3 1 Bilgisayar Mühendisliği Bölümü, Bilkent Üniversitesi, Ankara 2,3 Radar Elektronik Harp ve Đstihbarat Sistemleri (REHĐS) Grubu, ASELSAN A.Ş. Ankara 1 e-posta: 2 e-posta: 3 e-posta: Özetçe Yazılım sistemlerinin giderek artan boyut ve karmaşıklığı, ürünlerin, alt ürünlerin bileşimiyle, farklı ürün hatlarında ortaya çıktığı çoklu ürün hatları (ÇÜH) görüşünün ön plana çıkmasını sağlamıştır. Literatür taramaları, çoklu ürün hatları için mimari tasarım ve değerlendirmelerinin yapılabileceği uygun bir modelleme fikrinin ortaya çıkmadığını göstermektedir. Bu makalede, çoklu ürün hatlarını modelleme ve belgeleme amacıyla üç mimari bakış açısı önerilmekte ve Aselsan, REHĐS Grubu, Görev Yazılımları Müdürlüğü (GYM) kapsamında yürütülen çalışmalardaki tecrübeler aktarılmakta, olası mimari tasarım alternatifleri gösterilmekte ve verilen bakış açılarına uygun mimari tasarımın seçilmesi değerlendirilmektedir. Anahtar kelimeler ürün hattı kapsamı, ürün hattı organizasyonu 1. Giriş Yazılım ürün hattı yaklaşımının benimsenmesiyle elde edilecek yararlar pek çok yazar tarafından analiz edilmiş ve tartışılmıştır [3][11][14]. Ürünlerin daha etkin geliştirilmesi, rekabet gücünü artıran ürünün pazara çıkarılması hızının artırılması ve yazılım kalitesinin yükseltilmesi, yazılım ürün hatları mühendisliği sürecinin benimsenmesi motivasyonunu sağlayan önemli etkenlerdir [14]. Bu hedeflerle uyumlu olarak farklı yazılım ürün hattı mühendisliği süreçleri önerilmiş ve pek çok firma ürün kalitesi ile pazara çıkma hızını artırmak ve üretim maliyetini azaltmak amacıyla bir yazılım ürün hattı mühendisliği yöntemini benimsemeyi hedeflemiştir. Son zamanlardaki eğilimler, artan yazılım büyüklüğü ve karmaşıklığı nedeniyle, endüstride yazılım ürün hattının yeniden kullanım ölçeğinin artacağını göstermektedir. Bu kapsamda pek çok araştırmacı ürünlerin farklı ürün hatlarındaki alt ürünlerden meydana geldiği çoklu ürün hatlarına (ÇÜH) ihtiyaç duyulduğunu belirtmiştir [10][12]. Çoklu ürün hatlarını tanımlarken öne çıkan önemli konulardan biri ÇÜH yi oluşturacak alt ürün hatlarının belirlenmesidir. Varolan yaklaşımlar, sistemin uygun ölçüde alt ürün hatlarına ayrıştırılmasında ve bu ürün hatları arasındaki ilişkilerin belirlenmesinde yetersiz kalmaktadır. ÇÜH nin farklı ürün hatlarına ayrıştırılmasında uygun bir modelleme gösterimi ve kılavuzunun sağlanması önemlidir. Bu makalenin iki yönlü bir katkı getireceği değerlendirilmektedir. Đlk olarak ÇÜH için mimari bakış açıları önerilmektedir. Makale içinde Ürün Hattı Ayrıştırma Bakış Açısı, Ürün Hattı Bağımlılık Bakış Açısı ve Ürün Hattı Konfigürasyon Bakış Açısı tanımlanmaktadır. Bu bakış açılarının hazırlanmasında varolan bakış açılarından esinlenilmiş ancak ÇÜH nin yapılandırılması mantığının belirtimi için gereken üst seviye görünümlerin oluşturulmasına odaklanılmıştır. Makalenin ikinci katkısının çoklu ürün hattı modelleme ve analiz çalışmalarının endüstriyel bir örnek üzerinde yapılmasıyla oluşan tecrübelerin aktarılması olacağı değerlendirilmiştir. Makalede, radar elektronik harp sistemleri üzerinde çalışan Aselsan A.Ş. REHĐS grubu bünyesindeki ÇÜH ayrıştırma çalışmalarına ilişkin örnekler verilmektedir [1]. Aselsan, yüksek teknolojide, modern savunma sanayi sistemleri geliştiren öncü bir kuruluştur. Tanımlanan bakış açıları ile ÇÜH için dört farklı mimari ayrıştırma alternatifi analizi yapılmıştır. Çalışma ve tecrübelerimiz ÇÜH mimarisini tanımlarken belirlenen bakış açılarının önemli bir gereksinim olduğunu göstermektedir. Belirtilen mimari bakış açıları ile ÇÜH tasarım kararları ile ilişki kurulabilecek ve tasarım alternatifleri arasında seçim yapılabilecek bir şekilde tanımlanmıştır. Makalenin bundan sonraki bölümleri şu şekilde organize edilmiştir: 2. bölümde radar elektronik harp sistemleri alanı içinden seçilen örnek durum tanıtılmaktadır. 3. bölümde çoklu ürün hatları betimlenmekte, 4. bölümde tanımlanan ÇÜH nin modellenmesi için mimari bakış açıları verilmektedir. 5. bölümde, 3. bölümde tanımlanan ÇÜH için, verilen mimari bakış açıları kullanılarak, alternatif tasarımların analizi tartışılmaktadır. 6. bölüm ilişkili çalışmaları tanıtırken, 7. bölüm çalışmanın değerlendirilmesine ayrılmıştır. 2. Durum Tanımı Aselsan ın Radar ve Elektronik Harp (REH) sistemleri temel olarak üç ana katmandan oluşmaktadır: Görev Alanı Uygulamaları, Uygulama Destek Servisleri ve Kesişim Alanı Servisleri. Bu katmanlar Radar, Radar Elektronik Harp, Haberleşme Elektronik Harp ve Kendini Koruma sistemleri için temel yapıtaşlarını içerir. Tipik bir ürün verilen bu üç katmandaki yapıtaşlarının konfigürasyonu ile oluşturulur. Katmanların kendileri birer alt sistem değil alt sistemleri oluşturan yapıtaşlarının mantıksal birer paketlemesidir. Alt sistemler varlık temelini oluşturan bileşenlerden oluşur. Aselsan tarafından üretilen pek çok üründe ortak yetenekler yer almaktadır. Bu nedenle Aselsan ürün geliştirmede ürün hatlarına dayalı sistematik bir yeniden kullanım stratejisine yönelmiştir. Bu konudaki en önemli ticari faktörler pazara daha hızlı ürün çıkarma, ürün kalitesini artırma ve toplam maliyeti azaltmaktır. Tüm alanı tek bir ürün hattı olarak ifade etmek mümkündür. Ancak önceki projelerde elde edilen tecrübelerle bu yaklaşımın yeterli olmadığı, geniş bir yelpazede ürün çeşitliliği olan Aselsan sistemleri için 1 115

2 makul olamayacağı değerlendirilmiştir. Ürünler referans mimariye uygun olarak geliştirilse de alt sistemler farklı ve ilişkisiz alanlarda yer almaktadır. Farklı alanlara ait bu ürünler farklı ekipler tarafından geliştirilmekte, farklı alan bilgisi ve gereksinimler içermekte ve dolayısıyla farklı ürün ailelerini teşkil etmektedir. Ayrıca farklı alt sistemler farklı ürünler olarak değerlendirilmektedir. Örneğin, Uygulama Destek Servisleri katmanındaki Mesajlaşma alt sistemi Kesişim Alanı Servisleri katmanındaki Şifreleme Protokolleri alt sisteminden farklılık gösterir. Her alt sistem temel olarak ayrı bir ürün ailesi olarak ele alınabilir. Ürün ailelerinin birbirinden ayrılması ilgilerin ayrımını ve farklı ürün ailelerinin farklı kapsamlarda kullanımını desteklemektedir. Başka bir faydası da basit, küçük ve kapsamı belirli ürün ailelerinin geniş ve karmaşık ürün ailelerine göre daha kolay yönetilme imkânına sahip olmasıdır. Tüm sistemin gerçekte farklı ve birbiriyle ilişkili ürün ailelerinden meydana geliyor olduğu gözlemi, sistemin doğru ürün hatlarına ayrıştırılması problemini ortaya çıkarmıştır. Tüm sistemler için bir tek yazılım ürün hattı olası değilse sistem hangi ürün ailelerinden oluşmalıdır? Sistem kapsamı doğru belirlenmiş hangi ürün ailelerine ayrıştırılmalıdır? Ayrıştırma hangi kritere göre yapılmalıdır? Fikir iletişimi nasıl bir gösterim ile sağlanabilir? Bu konuların tartışılması amacıyla yetenek modelleme gibi varolan teknikler kullanılmış ancak bu yöntemlerin farklı ürün ailelerinin tanımlanmasında çok fayda getirmediği değerlendirilmiştir. 3. Çoklu Ürün Hatları Çoklu ürün hattı yaklaşımı daha önce farklı araştırmacılar tarafından adreslenmiştir. Bu kapsamda çoklu ürün hatları, iç içe ürün hatları ve ürün hatlarından oluşan ürün hatları aynı kavramı ifade etmek için kullanılmıştır. [12] de yazarlar çoklu ürün hatlarını birbirleriyle ilişkili ve bağımlı yazılım ürün hatları kümesi olarak tanımlamıştır. ÇÜH mühendisliğinde yazılım mimarisinin önemi, bu ürün hattından üretilecek ürünlerin genel mimarisini tanımlaması nedeniyle büyüktür. Paydaşların ilgilerine göre mimariyi tanımlama pratiği farklı mimari gösterimlerle yapılır [2]. Mimari gösterimler, belirli bir konudaki sistem elemanları ile bu elemanlar arasındaki ilişkileri gösterir. Genel olarak, farklı paydaşlar için, ilgilerin ayrıştırılması, modellemenin desteklenmesi ve anlaşılırlık ile iletişimin artırılması amacıyla birden fazla mimari gösterim gerekir. Mimari gösterimler, gösterimin oluşturulması ve kullanılmasını tanımlayan bakış açılarına uyumlu olarak hazırlanır. Literatürde, ilk olarak, mimarinin belgelendirilmesi amacıyla, belirli bir bakış açısı kümesinin önerildiği görülmektedir [2]. Farklı sistemler için farklı ilgi alanlarına ihtiyaç duyulması nedeniyle şimdiki eğilim bakış açısı kümesinin sabitlenmesi yerine ihtiyaca uygun olarak yeni bakış açılarının eklenmesidir. Çoklu ürün hattı konfigürasyonunu tanımlamak her zaman kolay olmayabilir. Pek çok konfigürasyon seçeneğini modelleme, belgeleme ve muhakeme etmek için uygun gösterim yöntemleri gerekir. Mimari modelleme için varolan bakış açıları, hem ürün hattı mimarileri hem de uygulama mimarileri için kullanılabilir. Ancak, çoklu ürün hatları değerlendirildiğinde, bu bakış açılarının, alt seviyedeki farklı ürün hatlarının belirtiminde yeterli olmadığı görülmektedir. Bu anlaşılırlığı ve paydaşlar arası iletişimi güçleştirmekte, ürün hattı ayrıştırım analizinin yapılmasını ve ürün geliştirme yöntemini karmaşıklaştırmaktadır. Bir başka problem ürün hatları kümesi sınırlarının çizilmesinin güçleşmesidir. Tek bir ürün hattı için kapsam belirleme fikirleri tartışılsa da büyük ve karmaşık çoklu ürün hatlarının belirlenmesi için bir kılavuz tanımlanmamıştır. Genel olarak, mimari modelleme amacıyla hazırlanmış bakış açıları hem ürün hatları hem de uygulama mimarileri için kullanılabilir. Çoklu ürün hatlarını tanımlarken ürün hatları mimarilerinin üzerinde bir mimari gösterime ihtiyaç duyulmuştur. Çalışmalarımızda, bu ihtiyaca yönelik olarak, birden fazla ürün hattından oluşan sistemlerde, üst seviye mimariyi tanımlamak ve ürün hatları arasındaki ilişkiyi belirlemek amacıyla çoklu ürün hattı mimarı rolü tanımlanmıştır. 4. bölümde ilk olarak, çoklu ürün hatlarını tanımlamak üzere mimari bakış açılarını tanımlayacağız. Daha sonraki bölümde Aselsan REH uygulamalarında çoklu ürün hatları alternatiflerinden uygun olanın belirlenmesi amacıyla düzenlenen kriterleri ve bu kriterlere uygun seçim işleminin yapılmasını açıklayacağız. 4. Mimari Bakış açıları Çoklu ürün hatlarına ilişkin, literatürde belirtilen bakış açılarını tamamlayıcı olarak üç mimari bakış açısı tanımlanmıştır: Ürün Hattı Ayrıştırma Bakış Açısı (Tablo 1), Ürün Hattı Bağımlılık Bakış Açısı (Tablo 2), Ürün Hattı Konfigürasyon Bakış Açısı (Tablo 3). 4.1 Ürün Hattı Ayrıştırma Bakış Açısı Tablo 1 Ürün Hattı Ayrıştırma Bakış Açısı nı gösterir. Bakış açıları üç tür geliştirme birimini ayrıştırır: Bileşik Ürün Hattı (BÜH), Ürün Hattı (ÜH), ve Ürün Hattı Dışındaki Birim (ÜHDB). Bir BÜH, ÜH lerin ve diğer BÜH lerin bir araya gelmesiyle oluşur. Bir ÜH diğer ÜH leri içeremez. Hem BÜH hem de ÜH ler alt sistemler olarak tanımlanmıştır [2]. Bir alt sistem, (1) tüm sistemin, birbiriyle ilişkili işlevselliğini içeren bir bölümü oluşturan, (2) ayrı olarak çalıştırılabilen, (3) ayrı ve artımsal olarak geliştirilip yüklenebilen bir parçası olarak tanımlanmıştır. Bu açıdan bir ÜHDB sistemin, bir BÜH ya da ÜH gibi bir alt sistemi olmayan bir parçasıdır. ÜHDB örneği olarak sistemin bir parçası olan, kendi içinde ilişkili işlevleri yerine getiren ancak tek başına çalıştırılamayan bir kütüphane verilebilir. ÜHDB lerin UML de varolan paket gösterimi ile uyumlu olduğu değerlendirildiği için ÜHDB bileşimi amacıyla ayrı bir gösterim tanımlanmamıştır. UML paketleri, kendileri de alt paketler içerebilen gruplama mekanizmaları olarak tanımlanmaktadır. Ürün Hattı Ayrıştırma Bakış Açısı nda, üç öğe için yalnızca parçabütün ilişkisi yer almaktadır, Kısıtlar, geçerli bir konfigürasyon hazırlanabilmesi için gerekli kuralları tanımlar. Bu bakış açısı, sistemin özellikle üst seviyede farklı ürün hatlarına ayrıştırılacağı görünümlerin hazırlanması için önemlidir. Bu bilgi tüm sistemin öğrenilmesi ve tasarlanması süreçlerinde gereklidir. Ayrıca ürün hattı ayrıştırımı için gereken girdiler organizasyon yapılanma sürecinde de kullanılabilir. Örneğin her ürün hattı ayrı bir ekiple eşleştirilebilir

3 Tablo 1. Ürün Hattı Ayrıştırma Bakış Açısı Bakış Açısı Öğesi Đsim Özet Öğeler Đlişkiler Kısıtlar Gösterim Tanım Ürün Hattı Ayrıştırma Bakış Açısı Bu bakış açısı bir sistemi farklı ürün ailesi öğelerine ayrıştırma amacıyla kullanılır. Bileşik Ürün Hattı (BÜH) diğer bileşik ürün hattı ve ürün hattı birimlerini barındıran bileşik yazılım ürün ailesi birimi Ürün Hattı (ÜH) tek bir yazılım ürün ailesi birimi Ürün Ailesi Dışındaki Birim (ÜHDB) yazılım ürün ailesi yaklaşımıyla geliştirilmeyen yazılım birimi Birimler ve alt-birimler arası parça-bütün ilişkisi Bir ürün ailesi birimi yalnızca bir üst seviye ürün ailesi biriminin parçası olabilir BÜH birimlerinin ÜH ve ÜHDB parçaları olabilir ÜH birimlerinin yalnızca ÜHDB parçaları olabilir ÜHDB birimlerinin yalnızca ÜHDB parçaları olabilir Şekil 1. Çoklu Ürün Hattını Tanımlayan Örnek Ürün Hattı Ayrıştırma Görünümü 4.2 Ürün Hattı Bağımlılık Bakış Açısı Ayrıştırma ilişkilerinin gösterimi kadar ürün hatları arasındaki etkileşimleri göstermek de önem taşır. Bu amaçla Tablo 2 de görülen Ürün Hattı Bağımlılık Bakış Açısı tanımlanmıştır. Bu bakış açısı Ürün Hattı Ayrıştırma Bakış Açısı ndaki öğeleri içermekle birlikte kullanır ilişkisini de tanımlar. Bir ürün hattı biriminin doğruluğu diğer bir ürün hattının doğru olmasına bağlı ise bu ürün hattı diğerini kullanır. Bu ilişki Görünümler ve Ötesi [2] yaklaşımında tanımlanan Kullanım Stili ile uyumludur. Farklılığı ilişkinin uygulama birimleri yerine tüm ürün hattına uygulanabilmesidir. Ayrıca bir ürün hattı diğer bir ürün hattını kullanıyorsa genel olarak aralarında bir konfigürasyon bağımlılığı da yer alır. Bu durumda bir ürün hattındaki yeteneklerin seçimi diğer ürün hattındaki yeteneklerin de seçilmesini gerektirir [13]. Şekil 1 de ele alınan çalışma konusu için örnek bir ürün hattı ayrıştırma görünümü sunulmaktadır. Bu sistem, üç farklı bileşik ürün hattı (BÜH) (Radar Elektronik Harp - RadEH, Haberleşme Elektronik Harp - HabEH, Radar), dört ürün hattı (ÜH) (HASP, VERY, Seyrüsefer, Kendini Koruma Suit) ve 12 ürün hattı dışındaki birim (ÜHDB) (kütüphaneler) içeren bir bileşik ürün hattı (Radar Elektronik Harp Fonksiyonel Referans Mimarisi - REFoRM) olarak tanımlanmıştır. REFoRM altındaki her bir BÜH iki ÜH den oluşmaktadır. Bu durumda çoklu ürün hattı mimarisi dört farklı ürün hattı (HASP, VERY, Seyrüsefer ve Kendini Koruma Suit) ve BÜH ler içinde tanımlanan altı farklı ÜH den (Radar ED, Radar ET, HabAlan1, HabAlan2, RadarAlan1, RadarAlan2) oluşur. Her ÜH nin kendi alan mühendisliği ve uygulama mühendisliği süreci vardır. Değişkenlik yönetimi ve modelleme her ÜH ye ayrı ayrı uygulanır. Farklı ÜH ler arasındaki bağımlılık ilişkileri, ÜH leri birleştiren BÜH içinde tanımlanır. Şekil 2. Radar Elektronik Harp Ürün Hattı Bağımlılık Görünümü RadEH BÜH si Kesişim Alanı Servisleri Katmanında yer alan kütüphaneleri (ÜHDB) kullanır. RadEH ayrıca HASP, VERY ve Seyrüsefer ÜH lerini de kullanır. Bu ÜH ler Kesişim Alanı Servisleri Katmanında yer alan kütüphaneleri de kullanmaktadır

4 Tablo 2. Ürün Hattı Bağımlılık Bakış Açısı Tablo 3.Ürün Hattı Konfigürasyon Bakış Açısı Bakış Açısı Öğesi Đsim Özet Öğeler Đlişkiler Kısıtlar Gösterim Tanım Ürün Hattı Bağımlılık Bakış Açısı Bu görünüm BÜH, ÜH ve ÜHDB arası bağımlılıkları tanımlar Bileşik Ürün Hattı (BÜH) diğer bileşik ürün hattı ve ürün hattı birimlerini barındıran bileşik yazılım ürün ailesi birimi Ürün Hattı (ÜH) tek bir yazılım ürün ailesi birimi Ürün Ailesi Dışındaki Birim (ÜHDB) yazılım ürün ailesi yaklaşımıyla geliştirilmeyen yazılım birimi Birimler arası bağımlılık ilişkisi Kesin kısıtlar olmamakla birlikte döngüsel bağımlılıklar, bir birimden fazla sayıda birime bağımlılık ya da uzun bağımlılık zincirleri ürünlerin artımsal bir şekilde ve alt-birimler olarak geliştirilmesini zorlaştırır. Öğeler Đlişkiler <<BÜH>> <Birim Đsmi> Bileşik Ürün Hattı <<ÜH>> <Birim Đsmi> Ürün Hattı Kullanır Örnek <<ÜH>> A Bakış Açısı Öğesi Đsim Özet Öğeler Đlişkiler Kısıtlar Tanım Ürün Hattı Konfigürasyon Bakış Açısı Bu bakış açısı ürün konfigürasyonlarını tanımlar Bileşik Ürün Hattı (BÜH) diğer bileşik ürün hattı ve ürün hattı birimlerini barındıran bileşik yazılım ürün ailesi birimi Ürün Hattı (ÜH) tek bir yazılım ürün ailesi birimi Ürün Ailesi Dışındaki Birim (ÜHDB) yazılım ürün ailesi yaklaşımıyla geliştirilmeyen yazılım birimi Zorunlu Bir varlığın seçimi alt seviyedeki varlığın seçimini zorunlu kılar Seçimli Bir varlığın seçimi alt seviyedeki varlığın seçimini tercihe bırakır Alternatif Bir varlığın seçimi alt seviyedeki yalnız bir varlığın seçimini zorunlu kılar, bir varlık seçili ise diğerleri seçilemez Veya Bir varlığın seçimi alt seviyedeki varlıklardan en az bir varlığın seçimini zorunlu kılar Zorunlu Kullanır Ürün ailesi varlıkları arasındaki zorunlu bağımlılıklar Seçimli Kullanır Ürün ailesi varlıkları arasındaki seçimli bağımlılıklar Bir ürün hattı birimi yalnızca bir üst seviye ürün hattı biriminin parçası olabilir BÜH birimlerinin ÜH ve ÜHDB parçaları olabilir ÜH birimlerinin yalnızca ÜHDB parçaları olabilir ÜHDB birimlerinin yalnızca ÜHDB parçaları olabilir <<ÜHDB>> <Birim Đsmi> <<ÜH>> B Ürün Hattı Dışındaki Birim A, B yi kullanır. 4.3 Ürün Hattı Konfigürasyon Bakış Açısı Ürün hattı ayrıştırma ve ürün hattı bağımlılık bakış açıları farklı yazılım birimleri arasındaki ayrışım ve bağımlılık noktalarını tanımlamaktadır. Ancak bu noktalar ürün konfigürasyonu için gerekli olan değişkenlik bilgisini içermez. Bu bilginin gösterimi amacıyla Tablo 3 te gösterilen Ürün Hattı Konfigürasyon Bakış Açısı tanımlanmıştır. Bu bakış açısına ait öğeler önceki bakış açılarıyla aynı olmakla birlikte ilişkiler farklı olarak değişken konfigürasyon bağımlılıklarını tanımlar. Bu ilişkiler, geleneksel yetenek modelleme yöntemiyle büyük benzerlikler göstermektedir. Ancak bu bakış açısında ilişkiler üst seviye yetenek soyutlama amacıyla değil, üst seviye ürün hattı birimlerinin (BÜH, ÜH, ÜHDB) tanımlanması amacıyla kullanılır. Ayrıca, kullanır ilişkisi yetenekler arasındaki işlevsel ilişkileri de gösterir. Bu bakış açısındaki ilişkilerin tanımında, yetenek modellemedeki geleneksel yapısal bağımlılıkları işlevsel bağımlılıklarla zenginleştiren Lee ve Kang ın [8] çalışmalarından esinlenilmiştir. Ürün hattı konfigürasyon bakış açısı tanımlanırken yapısal bağımlılık ilişkilerinin (zorunlu, alternatif, seçimli) yanında kullanır ilişkisinin de tanım içinde yer alması önemli görülmüştür. Gösterim Çalışma konusuyla ilgili örnek bir konfigürasyon görünümü Şekil 3 te verilmiştir. Bu görünümde bir REFoRM ürününün, bir RadEH, HabEH ya da Radar BÜH si ya da Kendini Koruma Suit ÜH sinden meydana geldiği görülmektedir. RadEH BÜH si veya ilişkisine sahip iki alternatif ÜH içerir; bu durumda ÜH lerden biri ya da her 4 118

5 ikisi de bir üründe yer alabilir. Şeklin alt kısmında Seyrüsefer, HASP ve VERY ÜH lerine ait kullanırlık ilişkisini göstermektedir. Bu ÜH ler diğer ÜH lerle ile birleşmeyip diğer ÜH ler tarafından kullanılır. sonra ilişkili ayrıştırma görünümü ve bağımlılık görünümü düzenlenmelidir. Şekil 5. Uygulama Ayrıştırma Görünümü Şekil 3. Şekil 1 deki Ayrıştırma Görünümü için Üst Seviye Konfigürasyon Görünümü RadarAlan1 den Seyrüsefer e olan ilişkide bir seçimli kullanım örneği yer almaktadır. Bu ilişki, ürün konfigürasyonu yapılırken Seyrüsefer in ihtiyaca gore alınabileceğini gösterir. Kullanır ilişkisi alternatif ve veya ilişkileri ile birlikte kullanılabilir. Şekil 4 te örnek bir uygulama konfigürasyon görünümü, Şekil 5 te ise bu konfigürasyon için ayrıştırma görünümü yer almaktadır. Şekil 4, Şekil 3 ten uyarlanmıştır. 4.4 Uygulama Mühendisliği Görünümleri Önceki bölümlerde tanımlanan bakış açıları, hem alan mühendisliği hem de uygulama mühendisliği aşamaları için kullanılabilecek mimari görünümleri belirtir. Şekil 6. Örnek Kullanırlık Görünümü Şekil 6 da yer alan örnek kullanılırlık görünümünde, REFoRM ürününün RadEH BÜH sine, RadEH in Radar ED ÜH sine, Radar EH nin Seyrüsefer, HASP ve VERY ÜH lerine ait ürünlerden meydana geldiği görülmektedir. Ayrıca, alt seviyedeki ÜH ler dört farklı ÜHDB yi de kullanmaktadır. Şekil 4. Uygulama Mühendisliğinde Seçilen Bir Ürün için Konfigürasyon Görünümü Uygulama mühendisliği sürecinde benzer mimari görünümler tanımlanmıştır. Geleneksel uygulama mühendisliğinde olduğu gibi tek bir ürünün çıkarılmasına odaklanılmıştır. Bu ürün çoklu ürün hattındaki ürünlerin bileşiminden meydana gelir. Konfigürasyonu tanımlamak için alan mühendisliğinde tanımlanan konfigürasyon görünümü kullanılır. Uygulama gereksinimlerine göre uygun bir konfigürasyon tanımlanmalıdır. Konfigürasyon tanımlandıktan 5. Alternatif Ayrışımların Analizi Görünümler hazırlanırken, alternatif ürün hattı ayrışımları olabilir. REFoRM sistemi oluşturulurken dört farklı alternatif belirlenmiştir: (1) sistemi tek ve bütün bir ürün hattı olarak tanımlamak, (2) sistemi dört farklı ürün hattı olarak tanımlamak, (3) Şekil 7 de gösterildiği gibi sadece uygulama alanlarını ürün hattı olarak tanımlamak ve (4) daha önce Şekil 1 de tanımlandığı şekilde bileşik bir ürün hattı tanımlamak. Alternatiflerin değerlendirilmesi amacıyla Aselsan tarafından aşağıdaki kriterlerin önemli olduğu değerlendirilmiştir: Alanların Ayrılması Aselsan çalışma organizasyonu, sınırları ve kapsamı belirlenmiş görev alanlarına uygun olarak kurulmuştur. Ürün hattı ayrıştırımı bu alanlarla uyumlu olmalı ve çalışma yapısını bozmamalıdır. Organizasyon Yönetimi Ürün hattı ayrıştırımı iş birimlerinin organizasyonu ve işlerin yönetimini kolaylaştırıcı nitelikte olmalıdır

6 Başlangıç Đçin Đşgücünü Eniyilemek Ürün hattı ayrıştırımı en az işgücü harcanacak şekilde düzenlenmeli, yeni personel ihtiyacı doğmamalıdır. Yeniden Kullanımı Eniyilemek Sistem işlevselliği ve kapsamı belirlenmeli, farklı iş ürünlerinde birbirini kapsayan benzer yetenekler yer almamalıdır. Ürün Yönetimi Đş ürünlerine kolaylıkla yeni yetenekler eklenebilmeli, varolan yetenekler değiştirilebilmeli ya da çıkarılabilmelidir. Ürün hattı gelişimi yönetilebilir olmalıdır. Farklı Đş Birimlerindeki Ürünlerin Bileşimi Ürün hattı ayrıştırımı farklı iş birimlerinde üretilen ürünlerin bir arada kullanımına olanak sağlamalıdır. Değişkenlik Yönetimi Karmaşıklığı Büyük alanlarda ve büyük yetenek kümelerinde değişkenlik yönetimi karmaşıklığını yönetmek güçtür. Seçilen ürün hattı ayrıştırımı bu karmaşıklığın üstesinden gelebilecek nitelikte olmalıdır. Sistemi bileşik bir ürün hattı (BÜH) olarak tanımlamak (Şekil 1) hemen hemen tüm kriterler açısından olumlu olarak değerlendirilmiştir. Çoklu ürün hattı hiyerarşik bir yapı içerirken, alanların ve organizasyon yönetiminin ayrılmasına da olanak sağlar. Bu kriterlere göre dört farklı ürün hattı ayrıştırımının değerlendirilmesi Tablo 4 te verilmiştir. Yukarıda belirtilen tüm kriterlerin eşit ağırlıkta olduğu değerlendirilmiştir. Her kriter için değerlendirme ölçütü --, -, +-, + ve ++ değerlerini içerir. Değerler çok kötüden çok iyiye doğru tanımlanmıştır. Alternatiflere ilişkin değerlendirmeler aşağıda yer almaktadır. Tablo 4 te görüldüğü üzere sistemi tek bir ürün hattı olarak tanımlamak karmaşıklık yönetimi ve büyük ürün hattındaki organizasyon yönetiminin güçlüğü açısından tercih edilen bir yöntem değildir. Ayrıca, Görev Alanı Uygulamaları katmanında geliştirilen ürünler farklı bölümlerdeki personelin çalışmalarıyla ortaya çıkmaktadır. Farklı organizasyonlardaki kişilerin bir arada ve ortak bir ürün hattı için çalıştırılması yönetim açısından olası değildir. Öte yandan, bu alternatif işlevsel yeteneklerin birbirini içermediği yetenek kümelerinin hazırlanmasına olanak sağlayacağı ve bu nedenle işgücü kullanımını iyileştireceği için olumlu olarak değerlendirilebilir. Bu alternatifin ürün yönetimi ve yeni ürünlerin oluşturulması açısından da fayda sağlayacağı değerlendirilmiştir. Đkinci alternatif sistemi dört farklı ürün hattına ayrıştırmak olarak belirlenmiştir. Dört farklı Görev Alanı Uygulaması alanı için, alanlara özgü ürün hatlarının belirlenmesi bu alternatifin olumlu bir özelliğidir. Organizasyon yönetimi de farklı bölümler için, alan bazında ayrılacağı için, merkezi yönetim karmaşıklığı olmayacaktır. Ürün yönetimi kolaylaşacak, ancak farklı ürün hatlarındaki ürünlerin birleştirilmesinde güçlükler yaşanacaktır. Ayrıca, bu alternatifte, farklı alanlardaki benzer ihtiyaçlar nedeniyle aynı yetenekler birkaç ürün hattında gerçeklenecek ve bu nedenle işgücü kullanım verimi düşecektir. Sonuç olarak bu alternatifin diğerlerine göre daha fazla işgücü ihtiyacı olacağı değerlendirilmiştir. Üçüncü alternatif (Şekil 7) Görev Alanı Uygulamalarındaki dört alan için dört farklı ürün hattı ile birlikte tüm alanlarda ortak olan işlevlerin yer alacağı kütüphaneleri içeren bir platform katmanı (UA ÜH) olarak ayrıştırmaktır. Đlk dört kriter için bu alternatif ikinci alternatifle benzer görülmektedir. Đkinci alternatiften farklı olarak bu alternatif ürün yönetimi için uygun görülmemiştir. Bazı kritik alanların ürün hattı olarak geliştirilmeyip ürün hattı dışı birim olarak değerlendirilebiliyor olması bu uygunsuzluğun nedeni olarak gösterilebilir. Bu durumda ürün birleştiriminde sıkıntılar yaşanacaktır. Bu alternatif değişkenlik yönetimi karmaşıklığı açısından da ikinci alternatifle benzerlikler göstermektedir. Bazı işlevsel yetenekler kütüphaneler içinde yer alacağı için dört alan içindeki değişkenlik daha düşük olurken, yeni değişkenlikleri tanımlamak güçleşecektir. Şekil 7. Görev Alanı Uygulamaları için Dört Farklı ve Bağımsız Ürün Hattını (UA ÜH) Tanımlayan Örnek Ürün Hattı Ayrıştırma Görünümü Kesişen işlevsellikler azaltılabilir ya da önlenebilir. Hiyerarşik ve bileşik yapısı nedeniyle yeni ürünlerin geliştirimini destekler. Bu seçeneğe ilişkin tek nötr sonuç işgücü eniyilemede ortaya çıkmaktadır. Yeniden kullanım eniyilendiğinde işgücü kullanımı da eniyilenir, ancak ürün hatlarının yönetimine ilişkin işgücü, her bir alt ürün hattıyla bileşik ürün hatlarının yönetimi ayrı çabalar gerektirdiği için tek bir ürün hattına göre daha fazla işgücü ihtiyacı doğurmaktadır. Tablo 4. Ürün Hattı Ayrıştırımı Alternatiflerinin Değerlendirilmesi Matrisi Değerlendirme Kriteri Tek ÜH 4 ÜH UA ÜH BÜH Alanların Ayrılması (Alanlarla Uyumlu Olaran) Organizasyon Yönetimi Đşgücü Eniyileme +(+) Yeniden Kullanımın Eniyilenmesi (Kesişen Đşlevselliğin Azaltılması) (-) ++ Ürün Yönetimi +(+) Farklı Đş Birimlerindeki Ürünlerin Birleştirilmesi +(+) Değişkenlik Yönetimi Karmaşıklığı

7 Tablo 4 te dört ürün hattı ve uygulama alanı ürün hatları tanımlamanın en kötü seçim alternatifleri olduğu görülmektedir. Şaşırtıcı olarak tek ürün hattı yaklaşımının beklenenden fazla sayıda kriter için olumlu değerlendirildiği görülmüştür. Paydaşlarla dikkatli bir inceleme ve değerlendirme sonucu Aselsan için en olası alternatifin bileşik çoklu ürün hatları olduğu belirlenmiştir. Her alternatifin değerlendirilmesi yalnızca bu alternatiflerin daha önceki bölümlerde verilen mimari bakış açılarına uygun olarak modellenmesi sonrası mümkün olmuştur. Bu mimari gösterimlerin olmaması durumunda tartışmalar ve taslak çizimler ya da yetenek modelleme ile sonuç elde edilebileceği, bu yöntemlerin hiçbirinin mimari gösterimlerin belgelenmesi kadar açık ve etkili olamayacağı değerlendirilmiştir. 6. Đlişkili Çalışmalar III. bölümde belirtildiği şekilde, çoklu ürün hattı yaklaşımı pek çok araştırmacı tarafından ele alınmıştır. Ommering çoklu ürün hatlarını ifade eden ürün popülasyonları kavramını ortaya koymuştur [10], Koala bileşenleri adı verilen, gömülü sistemler için tasarlanan ortak bileşen modelini tanımlamıştır. Koala bileşenleri, daha küçük bileşenlerin, daha büyük ve karmaşık bileşenleri meydana getirmek üzere bir araya getirilmesiyle oluşur. Bu yaklaşım, farklı ürün hatlarında üretilen pek çok ürünün bir araya getirilerek, istenen daha büyük ve karmaşık ürünün oluşturulmasına benzemektedir. Ommering, esnek bileşen bileşimi sağlamak için, farklı birleştiriciler kullanılarak bileşenler arasında arayüz kuran ilişkilere odaklanmıştır. Bu makalede ise ayrı ayrı bileşenlerin değil, tüm yazılım ürün hatlarının oluşturulmasına odaklanılmıştır. [9] da van der Linden, Philips Medical görüntüleme sistemleri (PMS) için hazırlanan çoklu ürün ailesinin geliştirilmesini açıklamıştır. Farklı ürünler dünyanın pek çok yerinde geliştirildiği için pek çok ürün grubu için farklı ürün hatları yer almaktadır. Farklı ürün hatlarındaki ürünler pek çok farklı özellik taşısa da, pek çok benzer yazılım da bulunmaktadır. Bu yüzden, tüm PMS için kullanılacak bir görüntüleme platformu geliştirilmiştir. Platformun kendisi de bir ürün hattıdır. Philips içindeki farklı ürün grupları, farklı platform konfigürasyonlarını kullanır. Pek çok ürün grubu içinde, görüntüleme platformu üzerinde çalışan yazılım da yazılım ürün hatlarıyla üretilmiştir. Bu durum platforma yeni değişkenlik gerekleri getirmektedir. Bu çalışmadan farklı olarak Aselsan daki çalışmalar bir platformu tanımlamaz, farklı alanlardaki ürünleri tanımlamak üzere bir ÇÜH mimarisi oluşturarak ürünlerin hazırlanmasını sağlar. Pek çok araştırmacı, ihtiyaç duyulan ürün hatlarının altyükleniciler tarafından geliştirildiği ve idame ettirildiği durumların da varolduğunu belirtmiştir. Bu altyükleniciler birbirlerinin rakibi de olabilir. Alternatif altyüklenicilerin bulunması tek bir üreticiye bağımlı olunmasını engeller, ürün çeşitliliğini artırır. Alternatif üreticiler tarafından geliştirilen ürün hatları rakip ürün hatları olarak adlandırılır. Bu kapsamda Hartmann [5], yetenek modellerinin birleştirilmesinin kesişen yeteneklerin yönetilmesi nedeniyle güç olacağını, alternatif ürünlerin alternatif uygulamalarındaki yeteneklerin bir araya getirilmesi yaklaşımının çok doğru olmadığını belirtmiştir. Yetenek modellerini birleştirmenin getireceği sıkıntılardan kurtulmak amacıyla Altyükleniciye Özgü Yetenek Modelleri (AÖYM) ve Altyüklenici Bağımsız Yetenek Modelleri (ABYM) adında iki farklı yetenek modelinin üretilmesi yaklaşımını önermişlerdir. ABYM alternatif üreticilere ait bileşenlerin değişkenliklerini birleştirir, ayrıca AÖYM ve ABYM deki yeteneklerin ilişkilendirilebilmesi için kısıtlar tanımlanır. Aselsan çalışmaları kapsamında çoklu ürün hattı bileşimi üzerine odaklanılmıştır. Çalışmadaki her ürün hattı Aselsan tarafından geliştirilmiş, bu ürün hatları için herhangi bir alt yükleniciden bir yazılım ürünü alınmamıştır. Rosenmuller [13] bir yazılım ürün hattının diğer bir yazılım ürün hattına ait bir ürünü kullandığı bağımlı ürün hatlarını incelemiştir. Çalışmalarında, farklı şekilde konfigüre edilebilen pek çok ürün hattı ürününün bir arada kullanıldığı durumda, içerilen yetenek modeline ait kısıtların yeterli olmayacağını değerlendirmişlerdir. Somut örnekler arasındaki bağımlılıklar göz önüne alınmalıdır. Benzer şekilde Rosenmuller, varolan yazılım ürün hattı modellemesine, yazılım ürün hattı örneklerini ve bağımlılıklarını tanımlamayı sağlayan sınıf çizelgelerine dayalı bir eklenti yapmıştır. Araştırmacıların, birleştirme modelleri adını verdikleri, çoklu ürün hatlarının yarı-otomatik konfigürasyonu çalışmalarına ilişkin detaylar [12] de verilmiştir. Aselsan modelinde BÜH yaklaşımı benimsenmiş, ürün hatlarının hiyerarşik bir yapıda bir araya getirilmesiyle farklı alanlardaki ürünlerin ortaya çıkması sağlanmıştır. 7. Sonuçlar Bu makalede çoklu ürün hatlarının modellenmesi için mimari bakış açıları tanımlanmıştır. Tanımlanan bakış açıları ürün hattı ayrıştırma bakış açısı, ürün hattı bağımlılık bakış açısı ve ürün hattı konfigürasyon bakış açısı olarak isimlendirilmiştir. Bu bakış açıları Aselsan da devam eden, ürün hattı ayrıştırma çalışmalarında edinilen tecrübelere dayalı olarak tanımlanmıştır. Bu kapsamda, çoklu ürün hattını tanımlayan birden fazla farklı ürün hattının bir araya getirilmesini sağlayan mimari tasarım çalışmaları gerçeklenmiştir. Sistemi mimari görünümler üzerinden modellemeyi sağlayan en önemli motivasyonlar, bu yöntemin sistemin anlaşılmasını ve farklı paydaşların sistem üzerindeki değerlendirmeleri için iletişimi sağlaması ile sistemin geliştirilmesi için yol gösterici olmasıdır. Varolan mimari bakış açıları çoklu ürün hattı bileşimini desteklememekte, bu makalede bahsedilen işlevleri sağlamada kısıtlı kalmaktadır. Benzer şekilde, ürün hatları için mimari bakış açılarının tanımlanması tüm süreç için önemli bir adımdır. Mimari bakış açılarının, Aselsan da yapılan çalışmaların mimari gösterimleri için kullanımı örneklerle verilmiştir. Mimari gösterimler farklı ayrıştırma alternatiflerinin belirtimi ve analizi için de faydalı olmuştur. Mimari gösterimler temel alınarak, iç içe ürün hatlarının bir araya getirilmesiyle oluşan çoklu bir ürün hattı ayrıştırımı uygun bulunmuştur. 5. bölümde tartışılan alternatif ürün hattı mimari ayrışımları arasından BÜH nin seçilmesi üst seviye bir referans mimariyi ortaya çıkarmakta ve farklı alanlardaki ürünlerin bu mimari çerçeve altında hazırlanmasını zorunlu kılmaktadır. Bu durum, ürünlerin çerçeve mimariye uyumlu olmasını gerektirmekle birlikte, ÜH içindeki mimarilerde bir kısıt oluşturmamaktadır. Gelecekteki çalışmalarımız mimari gösterimleri destekleyen bir aracın geliştirilmesi, çoklu ürün hattı mimari gösterimleri üzerinde çalışmalar ve ayrıştırma alternatiflerinin sayısal analizini sağlayacak ölçümlerin tanımlanması üzerine odaklı olacaktır. 8. Teşekkür Levent Alkışlar, Baki Demirel, Hakime Koç, Gökhan Kahraman, Şafak Şeker ve Ümit Demir e Radar ve Elektronik Harp alanı ve ürün hattı mimarisi ile ilgili değerlendirmelere verdikleri destek ve katkılar nedeniyle teşekkür ederiz. Bu çalışma Radar Elektronik 7 121

8 Harp Sistemleri için Ürün Hattı Mühendisliği Çalışmaları kapsamında Aselsan ve Bilkent tarafından gerçekleştirilmiştir. 9. Kaynakça [1] M. Aoyama, K. Watanabe, Y. Nishio, and Y. Moriwaki: Embracing Requirements Variety for e-governments Based on Multiple Product-Lines Frameworks. Proceedings of the 11th IEEE International Requirements Engineering Conference, [2] P. Clements, F. Bachmann, L. Bass, D. Garlan, J. Ivers, R. Little, P. Merson, R. Nord, J. Stafford. Documenting Software Architectures: Views and Beyond. Second Edition, Addison-Wesley: Reading, MA, [3] P. Clements, L. Northrop. Software Product Lines: Practices and Patterns. Boston, MA:Addison-Wesley, [4] accessed January [5] H. Hartmann, T. Trew, A. Matsinger. Supplier independent feature modeling. in: SPLC 2009, IEEE Computer Society, pp [6] ISO/IEC, ISO/IEC Systems and Software Engineering -- Recommended Practice For Architectural Description Of Software- Intensive Systems, [7] C.W. Krueger, New Methods in Software Product Line Development. BigLever Software, Austin, TX; in Proc. of 10th Software Product Line Conference, 2006 [8] K. Lee, L.C. Kang. Feature Dependency Analysis for Product Line Component Design, in: J. Bosch and C. Krueger (Eds.): ICSR 2004, Springer LNCS 3107, pp , [9] F. van der Linden, J. G. Wijnstra, Platform Engineering for the Medical Domain, Proceedings PFE4, Bilbao, pp , October [10] R. van Ommering, Widening the Scope of Software Product Lines from Variation to Composition, proceeding of the Software Product Lines 2nd International Conference, SPLC 2, San Diego, CA, Aug 2002, Springer-Verlag LNCS 2379, p 328. [11] K. Pohl, G. Böckle, F. van der Linden. Software Product Line Engineering Foundations, Principles, and Techniques, Springer, [12] M. Rosenmüller and N. Siegmund. Automating the Configuration of Multi Software Product Lines. In Proceedings of the International Workshop on Variability Modelling of Softwareintensive Systems (VaMoS). Linz, Austria, Jan [13] M. Rosenmüller, N. Siegmund, C. Kästner, and S. Saif ur Rahman. Modeling Dependent Software Product Lines. In GPCE Workshop on Modularization, Composition and Generative Techniques for Product Line Engineering (McGPLE), pp , Oct [14] K. Schmid, M. Verlage. The Economic Impact of Product Line Adoption and Evolution. IEEE Software, Vol. 19, No. 4, July/August 2002,

Radar ve Elektronik Harp Projeleri Đçin Artımsal Yazılım Ürün Hattı Mühendisliği Sürecinin Tanımlanması

Radar ve Elektronik Harp Projeleri Đçin Artımsal Yazılım Ürün Hattı Mühendisliği Sürecinin Tanımlanması Radar ve Elektronik Harp Projeleri Đçin Artımsal Yazılım Ürün Hattı Mühendisliği Sürecinin Tanımlanması Bedir Tekinerdoğan 1, Onur Aktuğ 2, Özgü Özköse Erdoğan 2 1 Bilgisayar Mühendisliği Bölümü, Bilkent

Detaylı

YAZILIM ÜRÜN HATTINDA YETENEK MODELİNDEN ÜRÜN KONFİGÜRASYONUNUN OLUŞTURULMASI

YAZILIM ÜRÜN HATTINDA YETENEK MODELİNDEN ÜRÜN KONFİGÜRASYONUNUN OLUŞTURULMASI YAZILIM ÜRÜN HATTINDA YETENEK MODELİNDEN ÜRÜN KONFİGÜRASYONUNUN OLUŞTURULMASI Mustafa Özpınar Aselsan A.Ş. SST-MD-YMM, 06172, Yenimahalle, Ankara mozpinar@aselsan.com.tr Özet. Yazılım ürün hattı, belli

Detaylı

Yazılım Mimari Tasarımından Yazılım Geliştirme Çatısının Üretilmesinde Model Güdümlü Bir Yaklaşım

Yazılım Mimari Tasarımından Yazılım Geliştirme Çatısının Üretilmesinde Model Güdümlü Bir Yaklaşım Yazılım Mimari Tasarımından Yazılım Geliştirme Çatısının Üretilmesinde Model Güdümlü Bir Yaklaşım İbrahim Onuralp Yiğit 1, Nafiye Kübra Turhan 2, Ahmet Erdinç Yılmaz 3, Bülent Durak 4 1,2,3,4 ASELSAN A.Ş.

Detaylı

Geleneksel Yazılım Mühendisliğinden Alana Özel Yazılım Mühendisliğine Doğru

Geleneksel Yazılım Mühendisliğinden Alana Özel Yazılım Mühendisliğine Doğru Geleneksel Yazılım Mühendisliğinden Alana Özel Yazılım Mühendisliğine Doğru DR. ÇAĞATAY ÇATAL TÜBİTAK-UEKAE Bilişim Teknolojileri Enstitüsü cagatay.catal@bte.mam.gov.tr www.cagataycatal.com İçerik 1. Giriş

Detaylı

Gömülü Sistemler için Yazılım Mimari Çerçevesi

Gömülü Sistemler için Yazılım Mimari Çerçevesi Gömülü Sistemler için Yazılım Mimari Çerçevesi Bedir Tekinerdogan 1, Şafak Şeker 2, Gökhan Kahraman 3, Metin Tekkalmaz 4, Özgü Özköse Erdoğan 5 1 Bilkent University, Department of Computer Engineering

Detaylı

SENTEZ TABANLI YAZILIM MİMARİSİ TASARIM YAKLAŞIMININ ESSENCE ÇERÇEVESİYLE MODELLENMESİ

SENTEZ TABANLI YAZILIM MİMARİSİ TASARIM YAKLAŞIMININ ESSENCE ÇERÇEVESİYLE MODELLENMESİ SENTEZ TABANLI YAZILIM MİMARİSİ TASARIM YAKLAŞIMININ ESSENCE ÇERÇEVESİYLE MODELLENMESİ G Ö R K E M G I R AY, T U R K E Y B E D I R T E K I N E R D O G A N, W A G E N I N G E N U N I V E R S I T Y, N E

Detaylı

Model Güdümlü Geliştirme ile Gömülü Kaynakların Yönetimi

Model Güdümlü Geliştirme ile Gömülü Kaynakların Yönetimi Model Güdümlü Geliştirme ile Gömülü Kaynakların Yönetimi Can Öz EGE ÜNİVERSİTESİ FEN BİLİMLERİ ENSTİTÜSÜ BİLGİSAYAR MÜHENDİSLİĞİ A.B.D. 1 İçerik Kaynak Yönetimi Problemi Kaynak Yönetimi Modellemesinin

Detaylı

BLG4146 - Sistem Analizi ve Tasarımı. Öğr. Grv. Aybike ŞİMŞEK

BLG4146 - Sistem Analizi ve Tasarımı. Öğr. Grv. Aybike ŞİMŞEK BLG4146 - Sistem Analizi ve Tasarımı Öğr. Grv. Aybike ŞİMŞEK Tasarım Evresi Analiz evresinde sorulan NE sorusuyla elde edilen bilgilerin NASIL yapılacağı, NASIL gerçekleştirileceğinin ortaya konulduğu

Detaylı

Bilişim Sistemleri Değerlendirme Modeli ve Üç Örnek Olay İncelemesi

Bilişim Sistemleri Değerlendirme Modeli ve Üç Örnek Olay İncelemesi Bilişim Sistemleri Değerlendirme Modeli ve Üç Örnek Olay İncelemesi Özet Dr. Sevgi Özkan ve Prof. Dr Semih Bilgen Enformatik Enstitüsü, Orta Doğu Teknik Üniversitesi, Ankara Tel: (312) 210 3796 e-posta:

Detaylı

İleri Yazılım Mimarisi (SE 658) Ders Detayları

İleri Yazılım Mimarisi (SE 658) Ders Detayları İleri Yazılım Mimarisi (SE 658) Ders Detayları Ders Adı Ders Kodu Dönemi Ders Saati Uygulama Saati Laboratuar Saati Kredi AKTS İleri Yazılım Mimarisi SE 658 Bahar 3 0 0 3 7.5 Ön Koşul Ders(ler)i Dersin

Detaylı

Yönetim Sistemleri Kurulumu

Yönetim Sistemleri Kurulumu Yönetim Sistemleri Kurulumu TEKİM - Teknolojik ve Kurumsal İşbirliği Merkezi Bilgi ve İletişim Sistemleri Sanayi, Danışmanlık ve Ticaret Ltd. Sti. Adres (Merkez): Mustafa Kemal Mahallesi 2131. Sokak 27/22

Detaylı

5.DERS PROJEDE YÜRÜTMENİN PLANLANMASI

5.DERS PROJEDE YÜRÜTMENİN PLANLANMASI 5.DERS PROJEDE YÜRÜTMENİN PLANLANMASI 1 1. PROJENİN PLANLANMASI? Proje planlaması yapılmadan iyi bir proje önerisi hazırlanması mümkün değildir. Bu nedenle planlama ile ilgili sorunları ortaya koymanın

Detaylı

Elbistan Meslek Yüksek Okulu Güz Yarıyılı

Elbistan Meslek Yüksek Okulu Güz Yarıyılı HAFTA III Bilgi iletişim sistemi : Bilgi iletişim sistemi, dağıtık sistem içerisinde düğümler arasındaki iletişimi desteklemekle yükümlüdür. İletişim sistemi, iletişim ağı ile bağlanmış herhangi bir düğümün,

Detaylı

Atış Kontrol Yazılımlarında Ürün Hattı Yaklaşımının Uygulanması

Atış Kontrol Yazılımlarında Ürün Hattı Yaklaşımının Uygulanması Atış Kontrol Yazılımlarında Ürün Hattı Yaklaşımının Uygulanması Adnan Kalay ASELSAN A.Ş. SST-GGZYTM P.K.1 06172, Yenimahalle/Ankara, Türkiye akalay@aselsan.com.tr Özet. Yazılım geliştiren birçok firma,

Detaylı

Yazılım Ürün Hatlarında Alana Özgü Bileşenleri Belirleme Yaklaşımı

Yazılım Ürün Hatlarında Alana Özgü Bileşenleri Belirleme Yaklaşımı Yazılım Ürün Hatlarında Alana Özgü Bileşenleri Belirleme Yaklaşımı İbrahim Onuralp YİĞİT 1, Ali Hikmet DOĞRU 2 1 ASELSAN A.Ş. SST Sk. Bşk.lığı-Komuta Kontrol Yazılım Tsr. Mdl. 2 Orta Doğu Teknik Üniversitesi,

Detaylı

YZM 2108 Yazılım Mimarisi ve Tasarımı

YZM 2108 Yazılım Mimarisi ve Tasarımı YZM 2108 Yazılım Mimarisi ve Tasarımı Yrd. Doç. Dr. Deniz KILINÇ Celal Bayar Üniversitesi Hasan Ferdi Turgutlu Teknoloji Fakültesi Yazılım Mühendisliği 1 BÖLÜM - 1 Yazılım Tasarımına Giriş Bu bölümde;

Detaylı

Bölüm 2 Varlık-İlişki Veri Modeli: Araçlar ve Teknikler. Fundamentals, Design, and Implementation, 9/e

Bölüm 2 Varlık-İlişki Veri Modeli: Araçlar ve Teknikler. Fundamentals, Design, and Implementation, 9/e Bölüm 2 Varlık-İlişki Veri Modeli: Araçlar ve Teknikler Fundamentals, Design, and Implementation, 9/e Üç Şema Modeli Üç şema modeli 1975 de ANSI/SPARC tarafından geliştirildi Veri modellemeninç ve rolünü

Detaylı

Elektronik Seyir Sistemleri Yazılım Ürün Ailesi İçin Analiz ve Tasarım Süreci

Elektronik Seyir Sistemleri Yazılım Ürün Ailesi İçin Analiz ve Tasarım Süreci Elektronik Seyir Sistemleri Yazılım Ürün Ailesi İçin Analiz ve Tasarım Süreci Selçuk BOZCAN 1, Ahmet Erdinç YILMAZ 2 Aselsan A.Ş. SST-KKYTM, P.K. 1 06172, Yenimahalle, Ankara sbozcan@aselsan.com.tr 1 aeyilmaz@aselsan.com.tr

Detaylı

DSK nın Ortaya Çıkışı ve Gelişimi

DSK nın Ortaya Çıkışı ve Gelişimi Balanced Scorecard DSK nın Ortaya Çıkışı ve Gelişimi Bu yöntemin ortaya çıkışı 1990 yılında Nolan Norton Enstitüsü sponsorluğunda gerçekleştirilen, bir yıl süren ve birçok şirketi kapsayan Measuring performance

Detaylı

Veritabanı Yönetim Sistemleri (Veritabanı Tasarımı) Varlık İlişki Modeli

Veritabanı Yönetim Sistemleri (Veritabanı Tasarımı) Varlık İlişki Modeli Veritabanı Yönetim Sistemleri (Veritabanı Tasarımı) Varlık İlişki Modeli Konular Veritabanı Tasarım Aşamaları Kavramsal Tasarım Temel Kavramlar Varlıklar Arası İlişkiler Var Olma Bağımlılığı (Existence

Detaylı

Çok İşlemcili Yapılarda Sinyal İşleme Yazılımlarının Geliştirilmesi Uygulaması. Sinan Doğan, Esra Beyoğlu

Çok İşlemcili Yapılarda Sinyal İşleme Yazılımlarının Geliştirilmesi Uygulaması. Sinan Doğan, Esra Beyoğlu Çok İşlemcili Yapılarda Sinyal İşleme Yazılımlarının Geliştirilmesi Uygulaması Sinan Doğan, Esra Beyoğlu ASELSAN A.Ş., REHİS Grubu, Ankara 16 Nisan 2009 1 1 İçerik Sinyal İşleme Yazılımları Çok İşlemci

Detaylı

BSM 532 KABLOSUZ AĞLARIN MODELLEMESİ VE ANALİZİ OPNET MODELER

BSM 532 KABLOSUZ AĞLARIN MODELLEMESİ VE ANALİZİ OPNET MODELER BSM 532 KABLOSUZ AĞLARIN MODELLEMESİ VE ANALİZİ OPNET MODELER Yazılımı ve Genel Özellikleri Doç.Dr. Cüneyt BAYILMIŞ Kablosuz Ağların Modellemesi ve Analizi 1 OPNET OPNET Modeler, iletişim sistemleri ve

Detaylı

Proje Hazırlama. Prof. Dr. Hasan Efeoğlu. Mühendislik Fakültesi E&E Müh. Bölümü

Proje Hazırlama. Prof. Dr. Hasan Efeoğlu. Mühendislik Fakültesi E&E Müh. Bölümü Proje Hazırlama Prof. Dr. Hasan Efeoğlu Mühendislik Fakültesi E&E Müh. Bölümü Hayat Sürecinde Kısa Orta ve Uzun Vadede planlanan bir yatırım-araştırma-geliştirme organizasyonları veya endüstriyel veya

Detaylı

Yazılım Mimarisi (SE 322) Ders Detayları

Yazılım Mimarisi (SE 322) Ders Detayları Yazılım Mimarisi (SE 322) Ders Detayları Ders Adı Ders Kodu Dönemi Ders Saati Uygulama Saati Laboratuar Saati Kredi AKTS Yazılım Mimarisi SE 322 Bahar 3 0 0 3 5 Ön Koşul Ders(ler)i Dersin Dili Dersin Türü

Detaylı

Veri Erişim ve Yönetim Kütüphanesinin Servis Tabanlı Mimari ile Tasarlanması H. Doğan Köseoğlu, S.Bozbey

Veri Erişim ve Yönetim Kütüphanesinin Servis Tabanlı Mimari ile Tasarlanması H. Doğan Köseoğlu, S.Bozbey Veri Erişim ve Yönetim Kütüphanesinin Servis Tabanlı Mimari ile Tasarlanması H. Doğan Köseoğlu, S.Bozbey Hande DOĞAN KÖSEOĞLU 04.11.2010 Kapsam Veri Erişim ve Yönetim Kütüphanesi Bileşen Tabanlı Mimari

Detaylı

Bilgi Sistemleri Tasarımı (SE 503) Ders Detayları

Bilgi Sistemleri Tasarımı (SE 503) Ders Detayları Bilgi Sistemleri Tasarımı (SE 503) Ders Detayları Ders Adı Ders Kodu Dönemi Ders Saati Uygulama Saati Laboratuar Saati Kredi AKTS Bilgi Sistemleri Tasarımı SE 503 Her İkisi 3 0 0 3 7.5 Ön Koşul Ders(ler)i

Detaylı

Web Tabanlı CMMI Süreç Yönetimi Uygulamalarının Süreç ve Yazılım Geliştirme Performansına Pozitif Etkileri

Web Tabanlı CMMI Süreç Yönetimi Uygulamalarının Süreç ve Yazılım Geliştirme Performansına Pozitif Etkileri Web Tabanlı CMMI Süreç Yönetimi Uygulamalarının Süreç ve Yazılım Geliştirme Performansına Pozitif Etkileri Y. Müh. Cemalettin Öcal FİDANBOY TÜBİTAK UEKAE ocalfidanboy@tubitak.gov.tr Meral YÜCEL TÜBİTAK

Detaylı

MerSis. Bilgi Güvenliği Danışmanlık Hizmetleri

MerSis. Bilgi Güvenliği Danışmanlık Hizmetleri o MerSis Danışmanlık Hizmetleri Çalışanlarınız, tesisleriniz, üretim araçlarınız koruma altında! Bilgileriniz? danışmanlık hizmetlerimiz, en değerli varlıklarınız arasında yer alan bilgilerinizin gizliliğini,

Detaylı

Bilişim Sistemleri. Modelleme, Analiz ve Tasarım. Yrd. Doç. Dr. Alper GÖKSU

Bilişim Sistemleri. Modelleme, Analiz ve Tasarım. Yrd. Doç. Dr. Alper GÖKSU Bilişim Sistemleri Modelleme, Analiz ve Tasarım Yrd. Doç. Dr. Alper GÖKSU Ders Akışı Hafta 5. İhtiyaç Analizi ve Modelleme II Haftanın Amacı Bilişim sistemleri ihtiyaç analizinin modeli oluşturulmasında,

Detaylı

TEDARİK ZİNCİRİ YÖNETİMİ

TEDARİK ZİNCİRİ YÖNETİMİ TEDARİK ZİNCİRİ YÖNETİMİ KISA ÖZET KOLAYAOF DİKKAT Burada ilk 4 sayfa gösterilmektedir. Özetin tamamı için sipariş veriniz www.kolayaof.com 2 Kolayaof.com 0 362 2338723 Sayfa 2 İÇİNDEKİLER 1. ÜNİTE- TEDARİK

Detaylı

İç Kontrol ve Risk Yönetimi Sisteminiz Stratejik Yönetim ve Planlama Sürecinize Katkı Sağlayabilir

İç Kontrol ve Risk Yönetimi Sisteminiz Stratejik Yönetim ve Planlama Sürecinize Katkı Sağlayabilir İç Kontrol ve Risk Yönetimi Sisteminiz Stratejik Yönetim ve Planlama Sürecinize Katkı Sağlayabilir Kurumlarımızda kullanılmakta olan önemli yönetim araçlarımız bulunmakta; İç Kontrol, Risk Yönetimi, Stratejik

Detaylı

KURUMSAL RİSK YÖNETİMİ (KRY) EĞİTİMİ KURUMSAL RİSK YÖNETİMİ: KAVRAMSAL VE TEORİK ÇERÇEVE

KURUMSAL RİSK YÖNETİMİ (KRY) EĞİTİMİ KURUMSAL RİSK YÖNETİMİ: KAVRAMSAL VE TEORİK ÇERÇEVE KURUMSAL RİSK YÖNETİMİ (KRY) EĞİTİMİ KURUMSAL RİSK YÖNETİMİ: KAVRAMSAL VE TEORİK ÇERÇEVE SUNUM PLANI 1. RİSK VE RİSK YÖNETİMİ: TANIMLAR 2. KURUMSAL RİSK YÖNETİMİ 3. KURUMSAL RİSK YÖNETİMİ DÖNÜŞÜM SÜRECİ

Detaylı

Veritabanı Yönetim Sistemleri (Veritabanı Kavramı) Veri Modelleri

Veritabanı Yönetim Sistemleri (Veritabanı Kavramı) Veri Modelleri Veritabanı Yönetim Sistemleri (Veritabanı Kavramı) Veri Modelleri Konular Veritabanı Tasarım Aşamaları Veri Modeli Nedir? Veri Modeli Temel Bileşenleri İş Kuralları (Business Rules) İş Kurallarını Veri

Detaylı

İŞ ANALİZİ ve YETKİNLİK MODELLEME

İŞ ANALİZİ ve YETKİNLİK MODELLEME İŞ ANALİZİ ve YETKİNLİK MODELLEME PozitifİK tarafından hazırlanmıştır. Tüm hakları saklıdır. YOURLOGO ÜRÜN VE HİZMETLERİMİZ 2 Projenin Amacı Projenin amacı, fonksiyonel bir yaklaşımla Kiptaş taki tüm pozisyonların

Detaylı

1.Yazılım Geliştirme Metotları 1

1.Yazılım Geliştirme Metotları 1 1.Yazılım Geliştirme Metotları 1 1.1 Klasik Çevrim(Waterfall) 1.2 V Modeli 1.3 Prototipleme/Örnekleme 1.4 Spiral Model 1.5 Evrimsel Geliştirme 1.6 Evrimsel Prototipleme 1.7 Artımlı Geliştirme 1.8 Araştırmaya

Detaylı

Sistem ve Yazılım Nedir?

Sistem ve Yazılım Nedir? Sistem ve Yazılım Nedir? Bilgisayar Sistemleri; donanım, yazılım ve kullanıcılardan oluşur. Yazılım sadece belirli bir işlemi yapan bir program değildir. Yazılım belirli bir mantık dahilinde insanlar tarafından

Detaylı

SİSTEM VE YAZILIM. o Bilgisayar sistemleri donanım, yazılım ve bunları işletmek üzere gerekli işlemlerden oluşur.

SİSTEM VE YAZILIM. o Bilgisayar sistemleri donanım, yazılım ve bunları işletmek üzere gerekli işlemlerden oluşur. SİSTEM VE YAZILIM o Bilgisayar sistemleri donanım, yazılım ve bunları işletmek üzere gerekli işlemlerden oluşur. o Yazılım, bilgisayar sistemlerinin bir bileşeni olarak ele alınmalıdır. o Yazılım yalnızca

Detaylı

Büyük Ölçekli bir Gömülü Yazılımın Geliştirme ve Otomatik Test Deneyimi

Büyük Ölçekli bir Gömülü Yazılımın Geliştirme ve Otomatik Test Deneyimi Büyük Ölçekli bir Gömülü Yazılımın Geliştirme ve Otomatik Test Deneyimi Eda Gürler 1 Murat Yılmaz 2 1, 2 Radar Elektronik Harp ve İstihbarat Sistemleri (REHİS) Grubu, ASELSAN A.Ş. Ankara 1 tverdi@aselsan.com.tr,

Detaylı

KARADAĞ SUNUMU Natalija FILIPOVIC

KARADAĞ SUNUMU Natalija FILIPOVIC VII. ULUSLARARASI BALKAN BÖLGESİ DÜZENLEYİCİ YARGI OTORİTELERİ KONFERANSI 28-30 MAYIS 2012, İSTANBUL Yeni Teknolojiler ve Bunların Yargıda Uygulanmaları Türkiye Cumhuriyeti Hâkimler ve Savcılar Yüksek

Detaylı

Proje DöngD. Deniz Gümüşel REC Türkiye. 2007,Ankara

Proje DöngD. Deniz Gümüşel REC Türkiye. 2007,Ankara Proje Yönetiminde Y Temel Kavramlar Proje DöngD ngüsü Yönetimi ve Mantıksal Çerçeve eve Yaklaşı şımı Deniz Gümüşel REC Türkiye 2007,Ankara TEMEL KAVRAMLAR Proje nedir? Proje Yönetimi nedir???? Proje Döngüsü

Detaylı

Recep Ataş 1, Oya Kalıpsız 2

Recep Ataş 1, Oya Kalıpsız 2 Fırat Üniversitesi-Elazığ SERVİS TABANLI YAZILIM ÜRÜN HATTI MİMARİLERİ Recep Ataş 1, Oya Kalıpsız 2 1 Bilgisayar Mühendisliği Bölümü Yıldız Teknik Üniversitesi recepatas@gmail.com 2 Bilgisayar Mühendisliği

Detaylı

MerSis. Bilgi Teknolojileri Yönetimi Danışmanlık Hizmetleri

MerSis. Bilgi Teknolojileri Yönetimi Danışmanlık Hizmetleri MerSis Bilgi Teknolojileri Yönetimi Danışmanlık Hizmetleri Bilgi Teknolojileri risklerinize karşı aldığınız önlemler yeterli mi? Bilgi Teknolojileri Yönetimi danışmanlık hizmetlerimiz, Kuruluşunuzun Bilgi

Detaylı

Gereksinim Mühendisliği (SE 560) Ders Detayları

Gereksinim Mühendisliği (SE 560) Ders Detayları Gereksinim Mühendisliği (SE 560) Ders Detayları Ders Adı Ders Dönemi Ders Uygulama Laboratuar Kredi AKTS Kodu Saati Saati Saati Gereksinim Mühendisliği SE 560 Her İkisi 3 0 0 3 7.5 Ön Koşul Ders(ler)i

Detaylı

Yazılım ve Uygulama Danışmanı Firma Seçim Desteği

Yazılım ve Uygulama Danışmanı Firma Seçim Desteği Yazılım ve Uygulama Danışmanı Firma Seçim Desteği Kapsamlı bir yazılım seçim metodolojisi, kurumsal hedeflerin belirlenmesiyle başlayan çok yönlü bir değerlendirme sürecini kapsar. İş süreçlerine, ihtiyaçlarına

Detaylı

Nesnelerin İnterneti Güvenlik ve Güç Tüketimi. Özen Özkaya

Nesnelerin İnterneti Güvenlik ve Güç Tüketimi. Özen Özkaya Nesnelerin İnterneti Güvenlik ve Güç Tüketimi Özen Özkaya 24 MAYIS 2017 EMO SEMİNER DİZİSİ - 2 bilgisayarların Analog vs. digital company culture interneti... Nesnelerin interneti, 4. sanayi devrimi ile

Detaylı

Yazılım Gereksinimlerine İlişkin Belirtimler. Sürüm <1.0>

<Ekip Adı> <Proje Adı> Yazılım Gereksinimlerine İlişkin Belirtimler. Sürüm <1.0> Yazılım Gereksinimlerine İlişkin Belirtimler Sürüm [Not: Aşağıda yer alan şablon, Rational Unified Process ile birlikte kullanılmak üzere sağlanmıştır] [Köşeli parantezler

Detaylı

ERZİNCAN ÜNİVERSİTESİ. BİLGİ YÖNETİM SİSTEMİ Mevcut Durum Analiz ve Kapasite Geliştirme Projesi

ERZİNCAN ÜNİVERSİTESİ. BİLGİ YÖNETİM SİSTEMİ Mevcut Durum Analiz ve Kapasite Geliştirme Projesi ERZİNCAN ÜNİVERSİTESİ ÜST DÜZEY YÖNETİCİ SUNUMU BİLGİ YÖNETİM SİSTEMİ Mevcut Durum Analiz ve Kapasite Geliştirme Projesi Strateji Geliştirme Daire Başkanlığı OCAK 2009 1 Gündem Bilgi Yönetimi Yol Haritası

Detaylı

Yrd. Doç. Dr. Ayça Tarhan. Hacettepe Üniversitesi Bilgisayar Mühendisliği Bölümü atarhan@hacettepe.edu.tr

Yrd. Doç. Dr. Ayça Tarhan. Hacettepe Üniversitesi Bilgisayar Mühendisliği Bölümü atarhan@hacettepe.edu.tr Yrd. Doç. Dr. Ayça Tarhan Hacettepe Üniversitesi Bilgisayar Mühendisliği Bölümü atarhan@hacettepe.edu.tr Süreç Değerlendirme Nedir? Süreç: Girdileri çıktılara dönüştüren, ilişkili veya etkileşimli etkinlikler

Detaylı

Dr. M. Nedim ALPDEMİR. YAZILIM SEKTÖRÜNDE KURUMSAL YETKĠNLIK VE GELECEĞE ĠLĠġKĠN ÖNERĠLER

Dr. M. Nedim ALPDEMİR. YAZILIM SEKTÖRÜNDE KURUMSAL YETKĠNLIK VE GELECEĞE ĠLĠġKĠN ÖNERĠLER Dr. M. Nedim ALPDEMİR YAZILIM SEKTÖRÜNDE KURUMSAL YETKĠNLIK VE GELECEĞE ĠLĠġKĠN ÖNERĠLER BaĢlarken Firmaların içyapılarını incelemeden dış etmenlerin etkisini anlamak oldukça Firmalar değer yaratan ve

Detaylı

Referans Mimariye Uygunluğun Model Tabanlı Analizi İçin Bir Yazılım Aracı

Referans Mimariye Uygunluğun Model Tabanlı Analizi İçin Bir Yazılım Aracı Referans Mimariye Uygunluğun Model Tabanlı Analizi İçin Bir Yazılım Aracı Evren Çilden Aselsan, PK. 1, 06172 Yenimahalle, Ankara Türkiye ecilden@aselsan.com.tr Özet. Yazılım geliştirme süreci içinde gerçeklenen

Detaylı

Görünümler ve Ötesi Yaklaşımıyla Radar Yazılım Mimarisi Dokümantasyonu Tecrübeleri. Ali Özzeybek M. Devrim Tokcan Murat Tuncer

Görünümler ve Ötesi Yaklaşımıyla Radar Yazılım Mimarisi Dokümantasyonu Tecrübeleri. Ali Özzeybek M. Devrim Tokcan Murat Tuncer Görünümler ve Ötesi Yaklaşımıyla Radar Yazılım Mimarisi Dokümantasyonu Tecrübeleri Ali Özzeybek M. Devrim Tokcan Murat Tuncer Görünümler ve Ötesi Yaklaşımıyla Radar Yazılım Mimarisi Dokümantasyonu Tecrübeleri

Detaylı

9.DERS Yazılım Geliştirme Modelleri

9.DERS Yazılım Geliştirme Modelleri 9.DERS Yazılım Geliştirme Modelleri 1 Yazılım Geliştirme Yaşam Döngüsü ve Modeller Herhangi bir yazılımın, üretim aşaması ve kullanım aşaması birlikte olmak üzere geçirdiği tüm aşamalar olarak tanımlanabilir.

Detaylı

08225 AĞ TEMELLERĠ. Elbistan Meslek Yüksek Okulu GÜZ Yarıyılı. Öğr. Gör. Murat KEÇECĠOĞLU. 20 EKi Salı, Çarşamba

08225 AĞ TEMELLERĠ. Elbistan Meslek Yüksek Okulu GÜZ Yarıyılı. Öğr. Gör. Murat KEÇECĠOĞLU. 20 EKi Salı, Çarşamba 08225 AĞ TEMELLERĠ Elbistan Meslek Yüksek Okulu 2014 2015 GÜZ Yarıyılı 20 EKi. 2014 Salı, Çarşamba Öğr. Gör. Murat KEÇECĠOĞLU Bilgi iletişim sistemi, dağıtık sistem içerisinde düğümler arasındaki iletişimi

Detaylı

Bilişim Sistemleri. Modelleme, Analiz ve Tasarım. Yrd. Doç. Dr. Alper GÖKSU

Bilişim Sistemleri. Modelleme, Analiz ve Tasarım. Yrd. Doç. Dr. Alper GÖKSU Bilişim Sistemleri Modelleme, Analiz ve Tasarım Yrd. Doç. Dr. Alper GÖKSU Ders Akışı Hafta 10-11. Nesneye Yönelik Sistem Tasarımı Haftanın Amacı Bilişim sistemleri geliştirmede nesneye yönelik sistem tasarımı

Detaylı

GT Türkiye İşletme Risk Yönetimi Hizmetleri. Sezer Bozkuş Kahyaoğlu İşletme Risk Yönetimi, Ortak CIA, CFE, CFSA, CRMA, CPA sezer.bozkus@gtturkey.

GT Türkiye İşletme Risk Yönetimi Hizmetleri. Sezer Bozkuş Kahyaoğlu İşletme Risk Yönetimi, Ortak CIA, CFE, CFSA, CRMA, CPA sezer.bozkus@gtturkey. GT Türkiye İşletme Risk Hizmetleri Sezer Bozkuş Kahyaoğlu İşletme Risk, Ortak CIA, CFE, CFSA, CRMA, CPA sezer.bozkus@gtturkey.com İşletme Risk Hakkında Risk, iş yaşamının ayrılmaz bir parçasıdır ve kaçınılmazdır.

Detaylı

Esnek Hesaplamaya Giriş

Esnek Hesaplamaya Giriş Esnek Hesaplamaya Giriş J E O L O J İ M Ü H E N D İ S L İ Ğ İ A. B. D. E S N E K H E S A P L A M A Y Ö N T E M L E R İ - I DOÇ. DR. ERSAN KABALCI Esnek Hesaplama Nedir? Esnek hesaplamanın temelinde yatan

Detaylı

25.10.2011. Arayüz Nedir? Arayüz Çeşitleri Arayüz Tasarım Yöntemleri Arayüz Tasarım Hataları. Ömer Faruk MIZIKACI 2008639402

25.10.2011. Arayüz Nedir? Arayüz Çeşitleri Arayüz Tasarım Yöntemleri Arayüz Tasarım Hataları. Ömer Faruk MIZIKACI 2008639402 Arayüz Tasarımı ve Programlama Neleri Konuşacağız Arayüz Nedir? Arayüz Çeşitleri Arayüz Tasarım Yöntemleri Arayüz Tasarım Hataları Ömer Faruk MIZIKACI 2008639402 Arayüz Nedir? Bilgisayar ve uygulamalarının

Detaylı

Genel Katılıma Açık Eğitimlerimiz Başlıyor!

Genel Katılıma Açık Eğitimlerimiz Başlıyor! Genel Katılıma Açık Eğitimlerimiz Başlıyor! Mavi Akademi, bünyesinde barındırdığı yetki belgeleri ve alanında uzman akademisyenler, sektör tecrübesine sahip baş denetçiler ve uzmanlardan oluşan kadrosuyla

Detaylı

T. C. KAMU İHALE KURUMU

T. C. KAMU İHALE KURUMU T. C. KAMU İHALE KURUMU Elektronik İhale Dairesi KALİTE YÖNETİM SİSTEMİ BT Strateji Yönetimi BT Hizmet Yönetim Politikası Sürüm No: 6.0 Yayın Tarihi: 26.02.2015 444 0 545 2012 Kamu İhale Kurumu Tüm hakları

Detaylı

Proje Hazırlama. Prof. Dr. Hasan Efeoğlu. Mühendislik Fakültesi E&E Müh. Bölümü

Proje Hazırlama. Prof. Dr. Hasan Efeoğlu. Mühendislik Fakültesi E&E Müh. Bölümü Proje Hazırlama Prof. Dr. Hasan Efeoğlu Mühendislik Fakültesi E&E Müh. Bölümü PROJE Kısa Orta ve Uzun vadede planlanaması olan Bilimsel / Endüstriyel manada AR-GE (Araştırma-Geliştirme ) faaliyetleri birer

Detaylı

PROJE YÖNETİMİ KISA ÖZET KOLAYAOF

PROJE YÖNETİMİ KISA ÖZET KOLAYAOF PROJE YÖNETİMİ KISA ÖZET KOLAYAOF DİKKAT Burada ilk 4 sayfa gösterilmektedir. Özetin tamamı için sipariş veriniz www.kolayaof.com 2 Kolayaof.com 0 362 2338723 Sayfa 2 İÇİNDEKİLER 1. ÜNİTE-Proje ve Proje

Detaylı

Yazılım Mühendisliği Bölüm - 2 Yazılım Geliştirme Yaşam Döngüsü. Cengiz GÖK

Yazılım Mühendisliği Bölüm - 2 Yazılım Geliştirme Yaşam Döngüsü. Cengiz GÖK Yazılım Mühendisliği Bölüm - 2 Yazılım Geliştirme Yaşam Döngüsü Cengiz GÖK 1 Gerçek Hayatta Program Geliştirme Gereksinim Analizi Sistemin İdamesi Sistem Tasarımı Teslim Program Tasarımı Sistem Testi Program

Detaylı

FTR 331 Ergonomi. Bilgiye Dayalı İş Yeri Düzenleme. emin ulaş erdem

FTR 331 Ergonomi. Bilgiye Dayalı İş Yeri Düzenleme. emin ulaş erdem FTR 331 Ergonomi Bilgiye Dayalı İş Yeri Düzenleme emin ulaş erdem GİRİŞ Bilişsel ergonomi, geçtiğimiz asırda yaşanan bilgisayar devrimiyle hayat bulan Ergonomi disiplini içerisinde gelişen yeni bir teknolojidir.

Detaylı

Temel ve Uygulamalı Araştırmalar için Araştırma Süreci

Temel ve Uygulamalı Araştırmalar için Araştırma Süreci BÖLÜM 8 ÖRNEKLEME Temel ve Uygulamalı Araştırmalar için Araştırma Süreci 1.Gözlem Genel araştırma alanı 3.Sorunun Belirlenmesi Sorun taslağının hazırlanması 4.Kuramsal Çatı Değişkenlerin açıkça saptanması

Detaylı

SiSTEM ANALiZi ve TASARIMI

SiSTEM ANALiZi ve TASARIMI SiSTEM ANALiZi ve TASARIMI BIL3403 Öğ. Gör. ASLI BiROL abirol@kavram.edu.tr 01.10.2012 Dersin Amacı Bu ders ile öğrenci; edindiği mesleki bilgi birikimini kullanarak sektörde uygulanabilir bir projeyi

Detaylı

DİZGE TABANLI BİLEŞEN DENEMELERİNİN TASARIMINDA BEKLENEN DİZGE YAŞAM SÜRESİNİN MODELLENMESİ 1

DİZGE TABANLI BİLEŞEN DENEMELERİNİN TASARIMINDA BEKLENEN DİZGE YAŞAM SÜRESİNİN MODELLENMESİ 1 DİZGE TABANLI BİLEŞEN DENEMELERİNİN TASARIMINDA BEKLENEN DİZGE YAŞAM SÜRESİNİN MODELLENMESİ 1 Emre YAMANGİL Orhan FEYZİOĞLU Süleyman ÖZEKİCİ Galatasaray Üniversitesi Galatasaray Üniversitesi Koç Üniversitesi

Detaylı

Yazılım Geliştirme Sürecinde Değer Akış Haritalama Yöntemi Uygulama Çalışması

Yazılım Geliştirme Sürecinde Değer Akış Haritalama Yöntemi Uygulama Çalışması Yazılım Geliştirme Sürecinde Değer Akış Haritalama Yöntemi Uygulama Çalışması Sezen Erdem 1 1 ASELSAN A.Ş. SST-KKYTM P.K.1 06172, Yenimahalle/Ankara, Türkiye 1 erdem@aselsan.com.tr Özetçe. Üretim alanında

Detaylı

Yazılım Ürün Hattı Projelerinde Kalite Maliyeti ve Hata Yoğunluğu Ölçüm Yaklaşımı

Yazılım Ürün Hattı Projelerinde Kalite Maliyeti ve Hata Yoğunluğu Ölçüm Yaklaşımı Yazılım Ürün Hattı Projelerinde Kalite Maliyeti ve Hata Yoğunluğu Ölçüm Yaklaşımı Sezen Erdem 1, Elif Ceylan 2 1 ASELSAN A.Ş. SST-KKYTM P.K.1 06172, Yenimahalle/Ankara, Türkiye 2 ASELSAN A.Ş. SST-KKYTM

Detaylı

Bilimsel Araştırma Yöntemleri I

Bilimsel Araştırma Yöntemleri I İnsan Kaynakları Yönetimi Bilim Dalı Tezli Yüksek Lisans Programları Bilimsel Araştırma Yöntemleri I Dr. M. Volkan TÜRKER 7 Bilimsel Araştırma Süreci* 1. Gözlem Araştırma alanının belirlenmesi 2. Ön Bilgi

Detaylı

ISO 9001:2009 KALİTE YÖNETİM SİSTEMİ STANDARDININ AÇIKLAMASI

ISO 9001:2009 KALİTE YÖNETİM SİSTEMİ STANDARDININ AÇIKLAMASI 0. GİRİŞ ISO 9001:2009 KALİTE YÖNETİM SİSTEMİ STANDARDININ AÇIKLAMASI Dr. Mürsel ERDAL Sayfa 1 Kalite yönetim sisteminin benimsenmesi, kuruluşun stratejik bir kararı olmalıdır. Bir kuruluşun kalite yönetim

Detaylı

Deniz Savunma Sistemleri Alanında Sistematik Yazılım Yeniden Kullanım Yaklaşımı

Deniz Savunma Sistemleri Alanında Sistematik Yazılım Yeniden Kullanım Yaklaşımı Deniz Savunma Sistemleri Alanında Sistematik Yazılım Yeniden Kullanım Yaklaşımı Bülent DURAK 1, Eren Koçak AKBIYIK 2, İbrahim Onuralp YİĞİT 3 1,2,3 ASELSAN A.S. Savunma Sistem Teknolojileri Grubu 1 durak@aselsan.com.tr,

Detaylı

Proje Yönetimi Uygulamaları Görev Tanımlama

Proje Yönetimi Uygulamaları Görev Tanımlama Girişimcilik ve İnovasyon Dersi Proje Yönetimi Uygulamaları Görev Tanımlama Yrd. Doç. Dr. Ali Nizam Prof. Dr. Fevzi YILMAZ Mühendislik Fakültesi Fatih Sultan Mehmet Vakıf Üniversitesi 2015 İş Paketi -

Detaylı

TMMOB ŞEHİR PLANCILARI ODASI ŞEHİR VE BÖLGE PLANLAMA ÖĞRENCİLERİ BİTİRME PROJESİ YARIŞMASI 2014-2015

TMMOB ŞEHİR PLANCILARI ODASI ŞEHİR VE BÖLGE PLANLAMA ÖĞRENCİLERİ BİTİRME PROJESİ YARIŞMASI 2014-2015 TMMOB ŞEHİR PLANCILARI ODASI ŞEHİR VE BÖLGE PLANLAMA ÖĞRENCİLERİ BİTİRME PROJESİ YARIŞMASI 2014-2015 ENDÜSTRİYEL YAPININ YENİLİKÇİ VE BİLGİ ODAKLI DÖNÜŞÜMÜNÜN BURSA ÖRNEĞİNDE İNCELENMESİ PROJE RAPORU İÇİNDEKİLER

Detaylı

Yazılım Emniyeti Perspektifinin Görünümler ve Ötesi Mimari Çerçevesine Uygulanması

Yazılım Emniyeti Perspektifinin Görünümler ve Ötesi Mimari Çerçevesine Uygulanması Yazılım Emniyeti Perspektifinin Görünümler ve Ötesi Mimari Çerçevesine Uygulanması Havva Gülay Gürbüz 1, Nagehan Pala Er 2, Bedir Tekinerdogan 2 Bilkent Üniversitesi, Bilgisayar Mühendisliği Bölümü, 06800,

Detaylı

PROJE YAPIM VE YÖNETİMİ İNSAN KAYNAKLARI YÖNETİMİ 09071067 ŞEYMA GÜLDOĞAN

PROJE YAPIM VE YÖNETİMİ İNSAN KAYNAKLARI YÖNETİMİ 09071067 ŞEYMA GÜLDOĞAN PROJE YAPIM VE YÖNETİMİ İNSAN KAYNAKLARI YÖNETİMİ 09071067 ŞEYMA GÜLDOĞAN İnsan kaynakları bir organizasyondaki tüm çalışanları ifade eder. Diğer bir deyişle organizasyondaki yöneticiler, danışmanlar,

Detaylı

www.tekim.com.tr www.tekimakademi.net

www.tekim.com.tr www.tekimakademi.net www.tekim.com.tr www.tekimakademi.net S ağlam yapıların ancak sağlam temeller üzerine inşa edileceğine inanıyoruz. Deneyimlerimizi paylaşmak için çıktığımız yolda, sizlere eğitim programlarımız ve eğitim

Detaylı

Yazılım Mühendisliğinde İleri Konular (SE 650) Ders Detayları

Yazılım Mühendisliğinde İleri Konular (SE 650) Ders Detayları Yazılım Mühendisliğinde İleri Konular (SE 650) Ders Detayları Ders Adı Ders Dönemi Ders Kodu Saati Uygulama Saati Laboratuar Kredi AKTS Saati Yazılım Mühendisliğinde İleri Konular SE 650 Güz 3 0 0 3 5

Detaylı

Uygulamaları ulut bilişime geçirmeden önce, firmanızın/şirketinizin ya da. işinizin gereksinimlerini göz önüne almanız gerekir. Aşağıda bulut bilişime

Uygulamaları ulut bilişime geçirmeden önce, firmanızın/şirketinizin ya da. işinizin gereksinimlerini göz önüne almanız gerekir. Aşağıda bulut bilişime Bulut Bilişim-Planlama Uygulamaları ulut bilişime geçirmeden önce, firmanızın/şirketinizin ya da işinizin gereksinimlerini göz önüne almanız gerekir. Aşağıda bulut bilişime geçemden önce dikkat edilmesi

Detaylı

BÖLÜM 2 VERİ SETİNİN HAZIRLANMASI VE DÜZENLENMESİ

BÖLÜM 2 VERİ SETİNİN HAZIRLANMASI VE DÜZENLENMESİ 1 BÖLÜM 2 VERİ SETİNİN HAZIRLANMASI VE DÜZENLENMESİ Veri seti; satırlarında gözlem birimleri, sütunlarında ise değişkenler bulunan iki boyutlu bir matristir. Satır ve sütunların kesişim bölgelerine 'hücre

Detaylı

PERFORMANS YÖNETĐMĐ. Hedefe Odaklı Çalışma ve Yetkinlik Yönetimi.

PERFORMANS YÖNETĐMĐ. Hedefe Odaklı Çalışma ve Yetkinlik Yönetimi. PERFORMANS YÖNETĐMĐ Kurumların yapısına uygun performans yönetimi sistemini esnek yapı sayesinde Đnsan Kaynakları uygulaması içinde tanımlayarak takip edebilme Performans kayıtlarını yöneticilere e-posta

Detaylı

Sağlık Hizmetinde Bilişim Teknolojileri (ISE 553) Ders Detayları

Sağlık Hizmetinde Bilişim Teknolojileri (ISE 553) Ders Detayları Sağlık Hizmetinde Bilişim Teknolojileri (ISE 553) Ders Detayları Ders Adı Ders Dönemi Ders Uygulama Laboratuar Kredi AKTS Kodu Saati Saati Saati Sağlık Hizmetinde Bilişim Teknolojileri ISE 553 Seçmeli

Detaylı

DEĞER MÜHENDİSLİĞİ. Veli KOÇAK Yazılım Mühendisi. Maltepe Üniversitesi - 2014

DEĞER MÜHENDİSLİĞİ. Veli KOÇAK Yazılım Mühendisi. Maltepe Üniversitesi - 2014 DEĞER MÜHENDİSLİĞİ Veli KOÇAK Yazılım Mühendisi Maltepe Üniversitesi - 2014 GİRİŞ Günümüzün rekabetçi koşullarında varlığını sürdürmek isteyen işletmeler, düşük maliyetli, yüksek kaliteli ve müşteri isteklerine

Detaylı

Arş.Gör.Muhammet Çağrı Gencer Bilgisayar Mühendisliği KTO Karatay Üniversitesi 2015

Arş.Gör.Muhammet Çağrı Gencer Bilgisayar Mühendisliği KTO Karatay Üniversitesi 2015 Arş.Gör.Muhammet Çağrı Gencer Bilgisayar Mühendisliği KTO Karatay Üniversitesi 2015 KONU BAŞLIKLARI 1. Yazılım Mimarisi nedir? 2. Yazılımda Karmaşıklık 3. Üç Katmanlı Mimari nedir? 4. Üç Katmanlı Mimari

Detaylı

Önceden belirlenmiş sonuçlara ulaşabilmek için organize edilmiş faaliyetler zinciridir.

Önceden belirlenmiş sonuçlara ulaşabilmek için organize edilmiş faaliyetler zinciridir. PROJE YÖNETİMİ Proje: Önceden belirlenmiş sonuçlara ulaşabilmek için organize edilmiş faaliyetler zinciridir. Proje Yönetimi: Kısıtlı zaman, maliyet ve teknik durumları dikkate alarak, projenin en etkin

Detaylı

Tetkik Gün Sayısı Tespiti www.sisbel.biz

Tetkik Gün Sayısı Tespiti www.sisbel.biz ISO/IEC 20000-1 BİLGİ TEKNOLOJİSİ - HİZMET YÖNETİMİ BAŞ DENETÇİ EĞİTİMİ Tetkik Gün Sayısı Tespiti 1.Tetkik Gün Sayısı İle İlgili Tanımlar Tetkik Süresi: Bir tetkikte harcanan toplam zaman. Her tür tetkikte,

Detaylı

Yazılım Geliştirme Projelerinde Kontrolörlük / Müşavirlik Hizmetleri. Y.Müh. Kadriye ÖZBAŞ ÇAĞLAYAN, PMP Y.Müh. Ahmet DİKİCİ, PMP

Yazılım Geliştirme Projelerinde Kontrolörlük / Müşavirlik Hizmetleri. Y.Müh. Kadriye ÖZBAŞ ÇAĞLAYAN, PMP Y.Müh. Ahmet DİKİCİ, PMP Yazılım Geliştirme Projelerinde Kontrolörlük / Müşavirlik Hizmetleri Y.Müh. Kadriye ÖZBAŞ ÇAĞLAYAN, PMP Y.Müh. Ahmet DİKİCİ, PMP Sunum Planı Organizasyon Yapısı Yazılım Projelerinde Başarı Durumu Yazılım

Detaylı

Alparslan Serhat DEMİR, Endüstri Mühendisliğine Giriş Ders Notları, Sakarya Üniversitesi Endüstri Mühendisliği Bölümü TESİS PLANLAMA

Alparslan Serhat DEMİR, Endüstri Mühendisliğine Giriş Ders Notları, Sakarya Üniversitesi Endüstri Mühendisliği Bölümü TESİS PLANLAMA 9.1.Giriş TESİS PLANLAMA Tesis planlama bir kurum veya kuruluşun fiziksel ini geliştirmek için gerçekleştirilen sistematik bir yaklaşımdır. Bir organizasyonun en önemli varlıklarından biri olan kapladığı

Detaylı

2. Hafta Proje Yaşam Döngüsü ve Organizasyon Yapıları

2. Hafta Proje Yaşam Döngüsü ve Organizasyon Yapıları 2. Hafta Proje Yaşam Döngüsü ve Organizasyon Yapıları Proje Yaşam Döngüsü Projeler benzersiz işlemler olmalarından dolayı belli miktarda belirsizlik içerirler. Proje üreten kuruluşlar, genellikle projeler

Detaylı

Nesneye Yönelik Tasarım ve Programlama (COMPE 501) Ders Detayları

Nesneye Yönelik Tasarım ve Programlama (COMPE 501) Ders Detayları Nesneye Yönelik Tasarım ve Programlama (COMPE 501) Ders Detayları Ders Adı Ders Kodu Dönemi Ders Saati Uygulama Saati Laboratuar Kredi AKTS Saati Nesneye Yönelik Tasarım ve Programlama COMPE 501 Güz 3

Detaylı

BM208- Nesneye Dayalı Analiz ve Tasarım. Sunum 7

BM208- Nesneye Dayalı Analiz ve Tasarım. Sunum 7 BM208- Nesneye Dayalı Analiz ve Tasarım Sunum 7 Component(Bileşen) Diyagramları Sistemin fiziksel yapısını modellemede kullanılır. Bu fiziksel yapıdan kasıt gömülü kontroller, portlar, arayüzlerin yanı

Detaylı

MAYIS 2010 ÖZGÜR DOĞAN İŞ GELİŞTİRME YÖNETİCİSİ KAMU SEKTÖRÜ

MAYIS 2010 ÖZGÜR DOĞAN İŞ GELİŞTİRME YÖNETİCİSİ KAMU SEKTÖRÜ MAYIS 2010 ÖZGÜR DOĞAN İŞ GELİŞTİRME YÖNETİCİSİ KAMU SEKTÖRÜ TANIMLAR KURUMSAL HAFIZA: Bilgiyi gelecekte kullanmak amacıyla insanlarda ve/veya teknolojilerde gerektiğinde geri çağrılabilir şekilde depolamak

Detaylı

BİLİŞİM SİSTEMLERİ GÜVENLİĞİNDE YENİ EĞİLİMLER

BİLİŞİM SİSTEMLERİ GÜVENLİĞİNDE YENİ EĞİLİMLER BİLİŞİM SİSTEMLERİ GÜVENLİĞİNDE YENİ EĞİLİMLER Dr. Hayrettin Bahşi bahsi@uekae.tubitak.gov.tr 11 Mart 2010 Gündem Bulut Hesaplama Sistemleri ve Bilgi Güvenliği Güvenli Yazılım Geliştirme Hayat Döngüsü

Detaylı

(Computer Integrated Manufacturing)

(Computer Integrated Manufacturing) 1 (Computer Integrated Manufacturing) 2 1 Bilgisayarlı Sayısal Kontrol; ekipman mekanizmaların hareketlerinin doğru ve hassas biçimde gerçekleştirilmesinde bilgisayarların kullanılması, programlama ile

Detaylı

SİSTEMLER SİSTEMİ MÜHENDİSLİĞİ YÖNETİMİ YAKLAŞIMI

SİSTEMLER SİSTEMİ MÜHENDİSLİĞİ YÖNETİMİ YAKLAŞIMI II. AR-GE MERKEZLERİ İYİ UYGULAMA ÖRNEKLERİ ZİRVESİ AR-GE YÖNETİMİ SİSTEMLER SİSTEMİ MÜHENDİSLİĞİ YÖNETİMİ YAKLAŞIMI ASELSAN A.Ş. SUNUM PLANI 1. UYGULAMANIN KISA AÇIKLAMASI 2. UYGULAMANIN YENİLİKÇİ VE

Detaylı

Nesneye Dayalı Analiz ve Tasarım (SE 321) Ders Detayları

Nesneye Dayalı Analiz ve Tasarım (SE 321) Ders Detayları Nesneye Dayalı Analiz ve Tasarım (SE 321) Ders Detayları Ders Adı Ders Kodu Dönemi Ders Saati Uygulama Saati Laboratuar Saati Kredi AKTS Nesneye Dayalı Analiz ve Tasarım SE 321 Bahar 3 0 0 3 4.0 Ön Koşul

Detaylı

ED Model Yapıtaşı Haberleşme Altyapısı

ED Model Yapıtaşı Haberleşme Altyapısı ED Model Yapıtaşı Haberleşme Altyapısı Aysun Sancar Yılmaz, Betül Baydemir Çankaya, Hande Doğan Köseoğlu REHİS-EHGYM, Aselsan A.Ş., Ankara {asancar,baydemir,hdogan}@aselsan.com.tr Özet. Elektronik Destek

Detaylı

SİSTEM ANALİZİ VE TASARIMI

SİSTEM ANALİZİ VE TASARIMI SİSTEM ANALİZİ VE TASARIMI BİLGİ SİSTEMİ GELİŞTİRME SÜRECİ Sistem Geliştirme Süreci ve Modelleri Sistem Geliştirme Yaşam Döngüsü Bilgi sistemlerinin geliştirilmesi için izlenen sürece Sistem Geliştirme

Detaylı

BAŞVURU FORMU ÖRNEK DÖKÜMAN

BAŞVURU FORMU ÖRNEK DÖKÜMAN BAŞVURU FORMU ÖRNEK DÖKÜMAN YILDIZ TEKNİK ÜNİVERSİTESİ TEKNOLOJİ GELİŞTİRME BÖLGESİ TEKNOPARK A.Ş YTÜ TEKNOPARK BİLGİ FORMU Bu formu, YTÜ- TEKNOPARK bünyesinde oluşturmayı düşündüğünüz birim için doldurunuz.

Detaylı

Bölüm 2 Yazılım Süreçleri. Ders 1

Bölüm 2 Yazılım Süreçleri. Ders 1 Bölüm 2 Yazılım Süreçleri Ders 1 1 Konular Yazılım Süreç Modelleri Süreç Aktiviteleri Değişikliklerle Baş Etmek The Rational Unified Process (RUP) 2 Yazılım Süreci Bir yazılım sistemini geliştirmek için

Detaylı

ISO 27001:2013 BGYS BAŞTETKİKÇİ EĞİTİMİ

ISO 27001:2013 BGYS BAŞTETKİKÇİ EĞİTİMİ 1.Tetkik Gün Sayısı İle İlgili Tanımlar Tetkik Süresi: Bir tetkikte harcanan toplam zaman. Her tür tetkikte, tetkik zamanı bina turlarında geçen süreleri, planın dışında geçen süre, dokümanların gözden

Detaylı