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

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ı

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ı

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ı

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ı

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ı

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ı

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ü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ı

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ı

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

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ı

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ı

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ı

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ı

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ı

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ı

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ı

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ı

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ı

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ı

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ı

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ı

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ı

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ı

İŞ 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ı

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ı

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ı

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ı

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ı

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ı

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ı

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ı

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ı

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ı

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ı

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ı

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ı

Tedarik Zinciri Yönetimi

Tedarik Zinciri Yönetimi Tedarik Zinciri Yönetimi -Tedarik Zinciri Ağı Tasarımı- Yrd. Doç. Dr. Mert TOPOYAN Ağ tasarımı, tedarik zinciri açısından üç karar düzeyini de ilgilendiren ve bu düzeylerde etkisi olan bir konudur. Zincirin

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ı

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ı

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ı

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ı

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ı

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ı

M-CARE. Anket Sonuçları Raporu - Yönetici Özeti

M-CARE. Anket Sonuçları Raporu - Yönetici Özeti M-CARE Engelli ve Yaşlı Bireylere Evde Bakım ve Sağlık Hizmeti Sağlayıcılarının Mobil Eğitimi Anket Sonuçları Raporu - Yönetici Özeti İş Paketi No: İş Paketi Adı: İP2 Durum Taslak 1 Araştırma ve Analiz

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ı

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ı

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ı

AKSİYOMLARLA TASARIM İLKELERİNİ KULLANARAK ÇEKME/KANBAN ÜRETİM KONTROL SİSTEMLERİNİN TASARIMI

AKSİYOMLARLA TASARIM İLKELERİNİ KULLANARAK ÇEKME/KANBAN ÜRETİM KONTROL SİSTEMLERİNİN TASARIMI AKSİYOMLARLA TASARIM İLKELERİNİ KULLANARAK ÇEKME/KANBAN ÜRETİM KONTROL SİSTEMLERİNİN TASARIMI Özgür KABADURMUŞ İstanbul Teknik Üniversitesi M. Bülent DURMUŞOĞLU İstanbul Teknik Üniversitesi Özet Bir üretim

Detaylı

Bir Çoklu Ortam Veri Yönetim Sistemi Mimarisinin ATAM ile Değerlendirilmesi

Bir Çoklu Ortam Veri Yönetim Sistemi Mimarisinin ATAM ile Değerlendirilmesi Bir Çoklu Ortam Veri Yönetim Sistemi Mimarisinin ATAM ile Değerlendirilmesi Güneş Uyanıksoy 1, Halit Oğuztüzün 2, Adnan Yazıcı 3 Orta Doğu Teknik Üniversitesi, Bilgisayar Mühendisliği Bölümü, 06800, Çankaya,

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ı

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ı

DGridSim Gerçek Zamanlı Veri Grid Simülatörü. Yazılım Tasarımı Dokümanı v 1.0.1 01.08.2011. Mustafa Atanak Sefai Tandoğan Doç. Dr.

DGridSim Gerçek Zamanlı Veri Grid Simülatörü. Yazılım Tasarımı Dokümanı v 1.0.1 01.08.2011. Mustafa Atanak Sefai Tandoğan Doç. Dr. DGridSim Gerçek Zamanlı Veri Grid Simülatörü Yazılım Tasarımı Dokümanı v 1.0.1 01.08.2011 Mustafa Atanak Sefai Tandoğan Doç. Dr. Atakan Doğan 1. Sistem Mimarisi DGridSim katmanlı bir yapı göz önünde bulundurularak

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ı

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ı

Enterprise Architecture(EA) KURUMSAL MİMARİ

Enterprise Architecture(EA) KURUMSAL MİMARİ MGA nternational nterprise Architecture(A) KUUMSAL MİMAİ Dr. Selami ASLAN emmuz 2010 Örnek Bir Kurumsal Mimari Proje Planı 1 MGA nternational Öngörülen Proje Planı Çıktılar Görevler Kapsam Dokümanı İ L

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ı

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ı

EĞİTİM KURUMLARINDA PERFORMANS YÖNETİMİ VE ÖLÇÜMÜ Kemal Pehlivanoğlu Genel Müdür - İNKA Eğitim ve Danışmanlık A.Ş kpehlivanoglu@inkadanismanlik.com.

EĞİTİM KURUMLARINDA PERFORMANS YÖNETİMİ VE ÖLÇÜMÜ Kemal Pehlivanoğlu Genel Müdür - İNKA Eğitim ve Danışmanlık A.Ş kpehlivanoglu@inkadanismanlik.com. EĞİTİM KURUMLARINDA PERFORMANS YÖNETİMİ VE ÖLÇÜMÜ Kemal Pehlivanoğlu Genel Müdür - İNKA Eğitim ve Danışmanlık A.Ş kpehlivanoglu@inkadanismanlik.com.tr Performans yönetim sistemi, gerçekleştirilmesi beklenen

Detaylı

İŞ ETÜDÜ ÇALIŞMALARINA YÖNELİK ÖZGÜN BİR YAZILIM GELİŞTİRİLMESİ VE UYGULANMASI

İŞ ETÜDÜ ÇALIŞMALARINA YÖNELİK ÖZGÜN BİR YAZILIM GELİŞTİRİLMESİ VE UYGULANMASI YÖNEYLEM ARAŞTIRMASI VE ENDÜSTRİ MÜHENDİSLİĞİ 28. ULUSAL KONGRESİ İŞ ETÜDÜ ÇALIŞMALARINA YÖNELİK ÖZGÜN BİR YAZILIM GELİŞTİRİLMESİ VE UYGULANMASI Cengizhan Büyük Hava Harp Okulu Endüstri Mühendisliği Bölüm

Detaylı

Ben Sine CANBOLAT Türk Hava Kurumu Üniverstesi nde araştırma görevlisi olarak çalışmaktayım. Sizlere «E-Devlet Yazılım Çerçevesi: Sektörel Kazanımlar

Ben Sine CANBOLAT Türk Hava Kurumu Üniverstesi nde araştırma görevlisi olarak çalışmaktayım. Sizlere «E-Devlet Yazılım Çerçevesi: Sektörel Kazanımlar Ben Sine CANBOLAT Türk Hava Kurumu Üniverstesi nde araştırma görevlisi olarak çalışmaktayım. Sizlere «E-Devlet Yazılım Çerçevesi: Sektörel Kazanımlar ve E-Devlet deki Yeri» i konusunu anlatacağım. 1 E-Devlet

Detaylı

Türkiye de Stratejik Çevresel Değerlendirme: İhtiyaçlar, Zorluklar ve Fırsatlar

Türkiye de Stratejik Çevresel Değerlendirme: İhtiyaçlar, Zorluklar ve Fırsatlar Technical Assistance for Implementation of the By-Law on Strategic Environmental Assessment EuropeAid/133447/D/SER/TR Stratejik Çevresel Değerlendirme Yönetmeliği'nin Uygulanması Teknik Yardım Projesi

Detaylı

EĞİTİMDE SÜREÇ ODAKLI YÖNETİM H.Ömer Gülseren > ogulseren@gmail.com

EĞİTİMDE SÜREÇ ODAKLI YÖNETİM H.Ömer Gülseren > ogulseren@gmail.com EĞİTİMDE SÜREÇ ODAKLI YÖNETİM H.Ömer Gülseren > ogulseren@gmail.com Yönetimde kalite; sonuç odaklı denetim yerine, süreç odaklı sorgulamaya dayalı iyileştirme ve geliştirmeyi esas alır. Giriş Bilim, genel

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ı

ISSAI UYGULAMA GİRİŞİMİ 3i Programı

ISSAI UYGULAMA GİRİŞİMİ 3i Programı ISSAI UYGULAMA GİRİŞİMİ 3i Programı 3i Programme Taahhütname ARKA PLAN BİLGİSİ Temel denetim alanları olan mali denetim, uygunluk denetimi ve performans denetimini kapsayan kapsamlı bir standart seti (Uluslararası

Detaylı

İş Zekası Sistemi Veriyi Stratejik Bilgiye Dönüştürür

İş Zekası Sistemi Veriyi Stratejik Bilgiye Dönüştürür İş Zekası Sistemi İş Zekası Sistemi İş Zekâsı Sistemi kolay kullanılır, zengin raporlama ve çözümleme yeteneklerine sahip, farklı veri kaynaklarını birleştirir, yöneticilere çok boyutlu, kurumsal bir görüş

Detaylı

İlk Bölüm: Proje hazırlarken izlenmesi gereken yöntem ve yaklaşımlar

İlk Bölüm: Proje hazırlarken izlenmesi gereken yöntem ve yaklaşımlar İlk Bölüm: Proje hazırlarken izlenmesi gereken yöntem ve yaklaşımlar İkinci Bölüm: Nitelikli Proje Teklifi hazırlayabilmek için kullanılması gereken belgeler ve dikkat edilmesi gereken hususlar Üçüncü

Detaylı

ESNEK YAPILANDIRMA UYGULAMASINDA YENİLİKLER

ESNEK YAPILANDIRMA UYGULAMASINDA YENİLİKLER ESNEK YAPILANDIRMA UYGULAMASINDA YENİLİKLER Amaç ve Fayda Esnek yapılandırma uygulamasında yapılan yenilikler ile; Hareket girişlerinde, daha önceden tanımlanmamış özellik değerlerinin kullanılabilmesi,

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ı

e-yazışma Projesi TBD Kamu-BİB Aylık Bilgilendirme Toplantısı

e-yazışma Projesi TBD Kamu-BİB Aylık Bilgilendirme Toplantısı e-yazışma Projesi TBD Kamu-BİB Aylık Bilgilendirme Toplantısı 19 Ocak 2012 Gündem e-yazışma Projesinin Amacı ve Kapsamı Projenin Çıktıları Projeye Katkı Sağlayanlar e-yazışma Paketi Önümüzdeki Dönemde

Detaylı

MESLEKİ EĞİTİM MALİ DESTEK PROGRAMI. Proje ve Projelere İlişkin Genel Kavramlar

MESLEKİ EĞİTİM MALİ DESTEK PROGRAMI. Proje ve Projelere İlişkin Genel Kavramlar MESLEKİ EĞİTİM MALİ DESTEK PROGRAMI Proje ve Projelere İlişkin Genel Kavramlar PROJE NEDİR? Belirli bir zaman ve bütçe çerçevesinde, belirli amaçlara ulaşmayı sağlayacak sonuçları üretmek üzere, insani

Detaylı

İLAÇTA AR-GE SOSYAL GÜVENLİK KURUMU BAKIŞI

İLAÇTA AR-GE SOSYAL GÜVENLİK KURUMU BAKIŞI İLAÇTA AR-GE SOSYAL GÜVENLİK KURUMU BAKIŞI DR. MUSTAFA KURUCA SGK BAŞKAN YARD. EKİM 2014 1 o o o o AR-GE NEDİR? AR-GE DEN BEKLENENLER NELERDİR? İLAÇ AR-GE SİNDE NEREDEYİZ? -SGKİLAÇ HARCAMALARI -GERİ ÖDEME

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ı

2013/101 (Y) BTYK nın 25. Toplantısı. Üstün Yetenekli Bireyler Stratejisi nin İzlenmesi [2013/101] KARAR

2013/101 (Y) BTYK nın 25. Toplantısı. Üstün Yetenekli Bireyler Stratejisi nin İzlenmesi [2013/101] KARAR 2013/101 (Y) Üstün Yetenekli Bireyler Stratejisi nin İzlenmesi [2013/101] BTYK nın 2009/102 no.lu kararı kapsamında hazırlanan ve 25. toplantısında onaylanan Üstün Yetenekli Bireyler Stratejisi nin koordinasyonunun

Detaylı

4. TÜRKİYE - AVRUPA FORUMU

4. TÜRKİYE - AVRUPA FORUMU 4. TÜRKİYE - AVRUPA FORUMU Yeni Dönem Türkiye - AB Perspektifi Transatlantik Ticaret ve Yatırım Ortaklığı: Fırsatlar ve Riskler ( 21-22 Kasım 2013, İstanbul ) SONUÇ DEKLARASYONU ( GEÇİCİ ) 1-4. Türkiye

Detaylı

KAMU MALİ SEKTÖRÜ KURULUŞLARINDA MALİ KONTROL STANDARTLARI

KAMU MALİ SEKTÖRÜ KURULUŞLARINDA MALİ KONTROL STANDARTLARI Gayrı resmi tercüme KAMU MALİ SEKTÖRÜ KURULUŞLARINDA MALİ KONTROL STANDARTLARI I. Giriş Bundan böyle "standartlar" olarak anılacak mali kontrol standartları, bundan böyle "kuruluşlar" olarak anılacak kamu

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ı

T.C. YEDİTEPE ÜNİVERSİTESİ TIP FAKÜLTESİ MİSYON, VİZYON, DEĞERLER

T.C. YEDİTEPE ÜNİVERSİTESİ TIP FAKÜLTESİ MİSYON, VİZYON, DEĞERLER T.C. YEDİTEPE ÜNİVERSİTESİ TIP FAKÜLTESİ MİSYON, VİZYON, DEĞERLER MİSYON Eğitim, sağlık hizmeti ve araştırmada yenilik ve mükemmelliği teşvik ederek, ulus ve ötesinde, sağlığı korumak ve geliştirmektir.

Detaylı

İstanbul Üniversitesi. Çerçeve Yönetmeliği Kapsamında Türkiye de Doktora Çalışmalarının Kurumsal Yapısı, İşleyişi ve Öneriler

İstanbul Üniversitesi. Çerçeve Yönetmeliği Kapsamında Türkiye de Doktora Çalışmalarının Kurumsal Yapısı, İşleyişi ve Öneriler İstanbul Üniversitesi Çerçeve Yönetmeliği Kapsamında Türkiye de Doktora Çalışmalarının Kurumsal Yapısı, İşleyişi ve Öneriler 1. Türkiye de doktora eğitiminin Avrupa ya benzer şekilde usta-çırak ilişkisi

Detaylı

VERİ TABANI SİSTEMLERİ

VERİ TABANI SİSTEMLERİ VERİ TABANI SİSTEMLERİ 1- Günümüzde bilgi sistemleri Teknoloji ve bilgi. 2- Bilgi sistemlerinin Geliştirilmesi İşlevsel Gereksinimleri 1.AŞAMA Gereksinim Belirleme ve Analiz Veri Gereksinimleri Gereksinimler

Detaylı

Ürün Geliştirme. Oğuz ALTAY Satış Direktörü

Ürün Geliştirme. Oğuz ALTAY Satış Direktörü Ürün Geliştirme Oğuz ALTAY Satış Direktörü 3 Boyutlu Teknolojiler Mühendislik ve Simülasyon 20 Yılı aşkın tecrübe Yurtiçi ve yurtdışında 4 ofis Teknoloji uygulama merkezleri 50 nin üzerinde Personel ISO

Detaylı

Antalya da AB İşlerinin Yönetilmesine Yönelik Kapasitelere İlişkin Eğitim İhtiyaç Analizi

Antalya da AB İşlerinin Yönetilmesine Yönelik Kapasitelere İlişkin Eğitim İhtiyaç Analizi Antalya da AB İşlerinin Yönetilmesine Yönelik Kapasitelere İlişkin Eğitim İhtiyaç Analizi 1 Giriş Bu özet raporda, Avrupa Birliği Bakanlığı tarafından Antalya Valiliği ile birlikte Mart-Nisan-Mayıs 213

Detaylı

Türkiye Sosyoekonomik Statü Endeksi Geliştirme Projesi. Proje Yürütücüsü Yrd. Doç. Dr. Lütfi Sunar İstanbul Üniversitesi Sosyoloji Bölümü

Türkiye Sosyoekonomik Statü Endeksi Geliştirme Projesi. Proje Yürütücüsü Yrd. Doç. Dr. Lütfi Sunar İstanbul Üniversitesi Sosyoloji Bölümü Türkiye Sosyoekonomik Statü Endeksi Geliştirme Projesi Proje Yürütücüsü Yrd. Doç. Dr. Lütfi Sunar İstanbul Üniversitesi Sosyoloji Bölümü Projenin Konusu, Amacı ve Anahtar Kelimeler Projemizin Konusu: Türkiye

Detaylı

tossad towards Open Source Software adoption and dissemination

tossad towards Open Source Software adoption and dissemination tossad towards Open Source Software adoption and dissemination Çağrı: FP6-2004-IST3 Kontrat num: 015981 Model: Eşgüdüm eylemi Süre: 24 ay (Şubat 2005 başlangıç) Koordinatör: TÜBİTAK UEKAE 15 ülkeden 19

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ı

FONKSIYONLARA GÖRE IŞLETME

FONKSIYONLARA GÖRE IŞLETME FONKSIYONLARA GÖRE IŞLETME BILGI SISTEMLERI ÜNİTE 7 GİRİŞ İşletmelerin işlerini yürütebilmeleri için tedarikçileri, müşterileri, çalışanları, faturaları, ödemeleri, mal ve hizmetleri ile ilgili birçok

Detaylı

T.C. DİYANET İŞLERİ BAŞKANLIĞI Strateji Geliştirme Başkanlığı

T.C. DİYANET İŞLERİ BAŞKANLIĞI Strateji Geliştirme Başkanlığı T.C. DİYANET İŞLERİ BAŞKANLIĞI Strateji Geliştirme Başkanlığı SORU VE CEVAPLARLA İÇ KONTROL Ankara-2012 İÇİNDEKİLER 1 Neden İç Kontrol? 2 İç Kontrol Nedir? 3 İç Kontrolün Amacı Nedir? 4 İç Kontrolün Yasal

Detaylı

Kariyer ve Yetenek Yönetimi Ulusal Meslek Standardı

Kariyer ve Yetenek Yönetimi Ulusal Meslek Standardı Kariyer ve Yetenek Yönetimi Ulusal Meslek Standardı Süleyman ARIKBOĞA MYK Uzmanı İTÜ III. Ulusal Kariyer Çalıştayı 26 Şubat 2015, İstanbul Sunum Planı Mesleki Yeterlilik Kurumuna İlişkin Genel Bilgiler

Detaylı

YAZILIM PROJE YÖNETİMİ. Yrd.Doç.Dr.Hacer KARACAN

YAZILIM PROJE YÖNETİMİ. Yrd.Doç.Dr.Hacer KARACAN YAZILIM PROJE YÖNETİMİ Yrd.Doç.Dr.Hacer KARACAN İçerik Proje Türleri Projenin Başlatılması Projenin Seçilmesi Fayda Ölçüm Metotları Paydaşların Belirlenmesi Proje Türleri Projeler ürün ve süreçte yaptıkları

Detaylı

SİSTEM ANALİZİ VE TASARIMI. Sistem Analizi -Bilgi Sistemleri-

SİSTEM ANALİZİ VE TASARIMI. Sistem Analizi -Bilgi Sistemleri- SİSTEM ANALİZİ VE TASARIMI Sistem Analizi -Bilgi Sistemleri- Bilgi Sistemi Bilgi sistemi, karar vericiler için verileri işleyerek bilgi sağlayan çoğunlukla bilgisayara dayalı sistemlerdir. Bilgi sistemi

Detaylı

100 % Özel Türk Şirketi

100 % Özel Türk Şirketi Kuruluş Tarihi : 1998 Personel Sayısı : 230 (+185 Mühendis) Tesis : 7,000m 2 (ODTÜ Teknokent) 100 % Özel Türk Şirketi ISO 9001:2000 (TSE) NATO AQAP-160 SEI CMMI Seviye-5 (24/2/2005) Sistem Mühendisliği

Detaylı

MKT 204 MEKATRONİK YAPI ELEMANLARI

MKT 204 MEKATRONİK YAPI ELEMANLARI MKT 204 MEKATRONİK YAPI ELEMANLARI 2013-2014 Bahar Yarıyılı Kocaeli Üniversitesi Mühendislik Fakültesi Mekatronik Mühendisliği Bölümü Yrd. Doç. Dr. Egemen Avcu Makine Bir veya birçok fonksiyonu (güç iletme,

Detaylı

Bilişim Teknolojileri Test ve Belgelendirme Hizmetleri. Mustafa YILMAZ mustafayilmaz@tse.org.tr

Bilişim Teknolojileri Test ve Belgelendirme Hizmetleri. Mustafa YILMAZ mustafayilmaz@tse.org.tr Bilişim Teknolojileri Test ve Belgelendirme Hizmetleri Mustafa YILMAZ mustafayilmaz@tse.org.tr Türk Standardları Enstitüsü tarafından yapılan Bilişim Teknolojileri Test ve Belgelendirme Hizmetleri Yazılım

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ı

Veri Toplama Teknikleri

Veri Toplama Teknikleri A. Gözlem Yoluyla Veri Toplama Teknikleri B. Soruşturma Yoluyla Nicel Veri Toplama Teknikleri Yazılı Soruşturma Tekniği Anket, Başarı Testi Yapılandırılmış Gözlem Önceden hazırlanmış göstergeler ve semboller

Detaylı

T.C. YEDİTEPE ÜNİVERSİTESİ TIP FAKÜLTESİ MİSYON, DEĞERLER, VİZYON

T.C. YEDİTEPE ÜNİVERSİTESİ TIP FAKÜLTESİ MİSYON, DEĞERLER, VİZYON T.C. YEDİTEPE ÜNİVERSİTESİ TIP FAKÜLTESİ MİSYON, DEĞERLER, VİZYON MİSYON Eğitim, sağlık hizmeti ve araştırmada yenilik ve mükemmelliği teşvik ederek, ulus ve ötesinde, sağlığı korumak ve geliştirmektir.

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ı