Yazılım Metriklerini Kullanarak Düşük Kaliteli / Yüksek Riskli Modüllerin Otomatik Tespiti

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

Download "Yazılım Metriklerini Kullanarak Düşük Kaliteli / Yüksek Riskli Modüllerin Otomatik Tespiti"

Transkript

1 Yazılım Metriklerini Kullanarak Düşük Kaliteli / Yüksek Riskli Modüllerin Otomatik Tespiti Automatic Detection of Low Quality / High-Risk Modules by using Software Metrics Çağatay, ÇATAL TÜBİTAK-Marmara Araştırma Merkezi Bilişim Teknolojileri Enstitüsü, Kocaeli Banu, DİRİ Bilgisayar Mühendisliği, Yıldız Teknik Üniversitesi, İstanbul Özet Yazılım sistemlerinde kusurların çok büyük bölümü, az sayıda modül üzerinde gerçekleşir ve kusur taşıyan modüllerin yüzdesinin %10 - %20 arasında değiştiği deneysel çalışmalarda tespit edilmiştir. Bu deneysel bilgiden hareketle, kusur eğilimli modüllerin test aşamasından önce belirlenip test kaynaklarının bu modüllere odaklandırılması, ürünün sahada çıkacak kusurlarını en düşük seviyeye indirecektir. Düşük kaliteli veya yüksek riskli olarak ifade edilebilen bu tür modüller, bazı yazılım araçları ile otomatik olarak belirlenebilmektedir. Bu çalışmada, yazılım metriklerini ve bu metriklerin eşik seviyelerini kullanarak yüksek riskli modüllerin nasıl belirlenebileceği ticari bir araç üzerinden açıklanmaktadır. Linux kaynak kodları içerisindeki selinux (security-enhanced linux) dizini, Predictive isimli araç ile incelenmiş ve yüksek riskli, orta riskli modüller saptanmıştır. Bu çalışmada, uygulayıcıların günlük yazılım geliştirmelerinde kullanabilecekleri metrikler açıklanarak kusur kestirim çalışmalarında yeterli olacak metrik kümeleri açıklanmıştır. Yüksek riskli modüller, metriklere ilişkin eşik seviyelerinin aşıldığı modüller olarak saptanmış olup, kusur kestirim modelleri bu çalışmada uygulanmamıştır. Önerilen metrikler, üzerinde çalıştığımız araştırma projesinde kullanılacaktır. Abstract Most of the faults occur in few modules of software systems and it has been identified that percentages of faulty modules are between 10% and 20% according to the experimental studies. Identification of fault-prone modules before testing phase and allocation of testing resources to these modules will minimize the operational errors that will occur in the field. These modules called low quality or high-risk modules can be identified automatically by software tools. In this study, it is explained how to identify high-risk modules by using software metrics and threshold levels on a commercial tool. selinux directory in Linux sources have been examined with Predictive and high-risk, medium-risk modules have been identified. In this study, software metrics that can be used by practitioners in their daily software development activities and metric suites that can be used for fault prediction have been detected. High-risk modules have been identified by using threshold levels and fault prediction models have not been used in this study. Suggested metrics will be used for our current research project. 1. Giriş Yazılım metrikleri ilk kez 1970 lerde önerilmiş olup halen üzerinde araştırmalar sürdürülmektedir. Thomas McCabe [1] ve Maurice Halstead [2] isimli araştırmacılar, 1970 lerde yapısal programlama dilleri için metot bazında bazı metrikleri ortaya koymuştur. Bu alandaki ilk kitap, Tom Gilb tarafından 1976 yılında Yazılım Metrikleri ismiyle yayımlanmıştır [3]. Geçen 40 yıla rağmen yazılım mühendislerinin metrikleri kullanarak yazılım geliştirme pratiklerini şekillendirdiklerini söylemek mümkün değildir da önerilen çevrimsel karmaşıklık (cyclomatic complexity) metriği hemen hemen tüm yazılım mühendisliği kitaplarında açıklanan bir metrik olmasına rağmen, birçok yazılım geliştirici tarafından hala bilinmemektedir ve eşik seviyeleri konusunda çoğu geliştiricinin yeterli bilgisi yoktur. Yazılım metriklerinin ulaştığı olgunluk sayesinde artık uygulayıcıların bu metriklerden günlük yazılım geliştirme faaliyetleri sırasında yararlanması gerekmektedir. Yazılım geliştirme ortamlarının (IDE vb.) bu tür metrikleri hesaplama konusundaki yetersizlikleri sebebiyle, bu zamana kadar uygulayıcılar bu metriklerden uzak kalmıştı. Ancak son yıllarda birçok tümleşik geliştirme ortamı bu tür metrikleri uyumlu ekler (plug-in) ya da doğrudan tümleşik geliştirme ortamı içerisinde hesaplamaya imkân vermektedir. Bu nedenle uygulamaya geçmesi için iyi

2 bir ortamın oluştuğunu ancak yeterli ilginin mevcut olmadığını söyleyebiliriz. Bu tür araçlar incelendiğinde, hesaplanan metriklerin oldukça farklı kümelerden oluştuğunu ve uygulayıcıların seçmesi gereken metrikleri bilemediğini söyleyebiliriz. Microsoft firmasının Visual Studio 2008 (Orcas) geliştirme ortamı içerisinde, 5 adet kod metriği hesaplanmaktadır. Bu sürümden önce, bu metrikler ürün içerisinde yer almıyordu. Son durumda üründe hesaplanabilen metrikler; kod satır sayısı, sınıf bağlılığı (class coupling), kalıtım derinliği (depth of inheritance), çevrimsel karmaşıklık ve bakım yapılabilirlik (maintainability) indeksidir. Bu büyük ölçekli ürün içerisinde bile sadece bu metrikler hesaplanabilmektedir ancak uygulayıcıların işine yarayabilecek metrikler bu 5 metrik ile sınırlı değildir. Bu çalışmada, uygulayıcıların kullanabilecekleri metrikler ayrıntıları ile birlikte açıklanmakta, eşik seviyelerinin aşıldığı metotlar yüksek riskli ve düşük kaliteli olarak ifade edilmektedir. Eşik seviyesi 1 ve eşik seviyesi 2 olarak ifade edebileceğimiz bu değerler; modülün orta riskli ya da yüksek riskli olarak 2 ayrı gruba ayrılmasını sağlamaktadır. 2. eşik seviyesinin değeri 1. değerden daha yüksektir ve 2. değerin geçilmesi durumunda modülün o metriğe göre yüksek riskli olduğu ifade edilir. Bu çalışmada ayrıca, linux çekirdeğinin sürümünde yer alan, güvenliği iyileştirilmiş linux (security-enhanced linux) dizinindeki kodlar, metrik ve eşik seviyeleri açısından incelenmiştir. İncelenen kaynak kodların %2 sinin yüksek riskli, %5 inin orta düzeyde riskli ve geride kalan %93 ünün düşük riskli olduğu belirlenmiştir. Riske neden olan metrikler ve detayları takip eden bölümlerde açıklanacaktır. Karmaşıklık, güvenliğin en büyük düşmanı olduğu açık bir gerçektir. Bu nedenle, bu tür yazılımların güvenli olabilmesi için yazılımların karmaşıklık metrikleri de dikkate alınarak geliştirilmesi gerekir. Örneğin; çevrimsel karmaşıklığı 100 ün üzerinde olan bir yönteme sahip bir yazılımı ele alalım. Sadece bu yöntem, 100 bağımsız yola sahiptir ve her birinin ayrı ayrı test edilmesi gerekir. Metotlardaki anahtar sözcüklerden if, while, &&,, switch deki her bir case, bu karmaşıklığı sayısal olarak 1 arttırmaktadır. Yazılım geliştirme sürelerini dikkate aldığımız zaman, her zaman test aşaması yeterli bütçeye ve zamana sahip olmayabilir. Bu durumlarda, yazılım modüllerinin tüm bağımsız yolları test edilmeden piyasaya sürülmesi gerekebilir. Bunun neticesinde bu tür yazılımlarda çok fazla açık bulunacağı için güvenliğin sağlanması oldukça zor olacaktır. Yazılım kusur kestirimi çalışmalarında, çoğunlukla önceki yazılım sürümünün metrikleri ve kusur bilgileri kullanılarak bir model ortaya çıkarılır, ardından yeni sürümdeki metriklere bağlı olarak modelden modüllerin yeni kusur eğilimlilik bilgisi elde edilmeye çalışılır. Modellerin oluşturulabilmesi için makine öğrenmesi tabanlı algoritmalar ya da istatistiksel yöntemler kullanılabilmektedir. Makine öğrenmesi kapsamında genetik algoritmalar, yapay sinir ağları, karar ağaçları gibi farklı yöntemler kullanılmıştır. Yaptığımız önceki çalışmalarda, Yapay Bağışıklık Sistem paradigmasından esinlenen yöntemler geliştirdik [4], [5]. Bu çalışmada, kusur kestirim modelleri yerine metriklerin eşik seviyelerine bağlı olarak modüllerin kusur eğilimliliği ve riski belirlenmektedir. Bu nedenle, kusur kestirim modelleri konusunda kapsamlı bilgi bu çalışmada verilmeyecektir. Bir sonraki bölümde, metot ve sınıf seviyesindeki yazılım metrikleri açıklanmaktadır. 3. bölümde üzerinde inceleme yapılan SELinux projesinin çıkışı ve kapsamı ortaya konulmaktadır. 4. bölümde durum çalışması, yüksek riskli olarak belirlenen modüller ve yüksek riske neden olan metrikler ifade edilmektedir. 5. bölümde sonuç ve gelecek çalışmalar açıklanmaktadır. 2. Yazılım Metrikleri Metrikleri, sınıf seviyesinde ve metot seviyesinde metrikler olarak iki ayrı grupta ele almak mümkündür. Sınıf seviyesindeki metrikler sadece nesneye yönelik programlama dilleri kullanıldığı durumda uygulanabilirken, metot seviyesindeki metrikler yapısal ve nesneye yönelik programlama dillerinde kullanılabilir. Durum çalışmasında, C programlama dili ile yazılmış SELinux kaynak kodları kullanıldığından sınıf seviyesindeki metrikler hesaplanmamıştır. Predictive aracı, metot seviyesindeki metriklerin eşik seviyelerine bağlı olarak ilgili metotu orta / düşük / yüksek riskli olarak işaretlemektedir. Sadece bir metrikte eşik seviyesinin geçilmesi, o metotun orta ya da yüksek riskli olarak gösterilmesi için yeterlidir. Bu yaklaşım elimizde hiç kusur verisi olmadığı durumlarda kullanılabilecek pratik bir yöntem gibi görülebilir ancak daha doğru modelleri kurgulamak için kusur kestirim modellerinden yararlanılması gerekmektedir. Bu noktada bir önceki yazılım sürümünün test aşamasında saptanmış kusur bilgilerine ihtiyaç olacaktır Sınıf Seviyesindeki Metrikler Sınıf seviyesindeki metriklerden en bilinenleri 1994 yılında Chidamber-Kemerer isimli araştırmacılar tarafından önerilmiş CK metrikleridir. Bu metrikler; WMC, CBO, LCOM, RFC, DIT, NOC kısaltmaları ile bilinmektedir. Predictive aracı bu metriklerin hepsini sınıf bazında hesaplayabilmektedir. Bu metriklere ek olarak bu araç; public metotların sayısı, sınıf

3 değişkenlerinin sayısı, ortalama iç içe geçmiş derinlik (average nested depth), ortalama çevrimsel karmaşıklık, ortalama mimari karmaşıklık metriklerini de sınıf bazında hesaplayabilmektedir. CK metrikleri aşağıda açıklanmaktadır: 1. WMC (Weighted Method per Class): WCM, bir sınıftaki metot sayısıdır. McCabe IQ aracı içerisinde, eşik seviyesi 14 olarak gösterilmiştir. 2. DIT (Depth of Inheritance Tree): DIT, bir sınıftan kalıtım ağacındaki kök elemana olan en uzak yolun mesafesidir. McCabe IQ aracı içerisinde, eşik seviyesi 7 olarak gösterilmiştir. 3. RFC (Response for a Class): Bir sınıf içerisinde yer alan metot sayısı ile kalıtımdan gelen metot sayısı toplanarak hesaplanır. McCabe IQ aracı içerisinde, eşik seviyesi 100 olarak gösterilmiştir. 4. NOC (Number of Children): Sınıfın çocuklarının sayısı ya da bir sınıftan türeyen sınıfların sayısı olarak tanımlanabilir. McCabe IQ aracı içerisinde, eşik seviyesi 3 olarak gösterilmiştir. 5. CBO (Coupling between Object Classes): A sınıfı B sınıfının özelliklerini (attribute) veya operasyonlarını kullanıyorsa, A sınıfının B sınıfına bağlı (coupled) olduğu söylenir. CBO, bir sınıfın kalıtım dışında bağlı olduğu farklı sınıfların sayısıdır. McCabe IQ aracı içerisinde, eşik seviyesi 2 olarak gösterilmiştir. 6. LCOM (Lack of Cohesion in Methods): Her özellik (attribute) için o özelliği kullanan metotların yüzdesi belirlenip ortalaması alınır ve bu değer 100 den çıkarılır. Elde edilen değer, LCOM değeridir. Sınıf içi kohezyon yüksek olması gerekirken, sınıflar arası bağlılık (coupling) düşük olmalıdır. McCabe IQ aracında, eşik seviyesi 75 olarak gösterilmiştir. 7. Ortalama mimari karmaşıklık: Bir modülün, sistemin diğer elemanları ile olan etkileşiminin karmaşıklığını ifade eder (fonksiyon çağırma sayısı). Bir modülde çağrılan fonksiyon sayısı toplanarak hesaplanır. Mimari karmaşıklık değerleri birçok faktöre bağımlıdır ve spesifik bir rakam vermek güçtür. Genel olarak 60 ı geçen modüllerin incelenmesi gerekir. Ortalama mimari karmaşıklık ise o sınıf içerisindeki metotların mimari karmaşıklığının ortalamasıdır [6]. 8. Ortalama çevrimsel karmaşıklık (CC): Modülün karar yapısının karmaşıklığını gösterir. 30 dan küçük değerler kabul edilebilir. Üç basamaktan oluşan CC değerleri, o modülün bakım yapılabilirliğinin çok düşük olduğunu ve kesinlikle kusur eğilimli olduğunu gösterir. Ortalama çevrimsel karmaşıklık ise o sınıf içerisindeki metotların çevrimsel karmaşıklığının ortalamasıdır [6]. 9. Public metot sayısı: Sınıf içerisindeki public metotların sayısıdır. 10. Sınıf değişkenleri: Sınıf içerisindeki veri elemanlarının sayısıdır. 11. Ortalama iç içe geçmiş derinlik (average nesting depth): Bir sınıf içerisindeki metotların iç içe geçmiş derinliklerinin ortalamasıdır. Örneğin; 2 tane iç içe for döngüsünün en içinde bir if kontrolü mevcutsa, böyle bir metotun iç içe geçmiş derinliği 3 dür. Bu çalışmada sadece metot seviyesindeki metrikler kullanılmıştır. 6 CK metriğini karmaşıklık açısından ele alırsak 3 gruba ayırmak mümkündür. Bu gruplar aşağıda verilmektedir: Kalıtım Karmaşıklığı (inheritance complexity): DIT ve NOC Bağlılık Karmaşıklığı (coupling complexity): RFC ve CBO Sınıf İç Karmaşıklığı (class internal complexity): WMC ve LCOM 2.2. Metot Seviyesindeki Metrikler Predictive aracı içinde hesaplanabilen metot seviyesindeki metrikler ve eşik seviyeleri aşağıda verilmektedir [6]: 1. Toplam kod satır sayısı: Kod satırlarının sayısıdır. Boş ve yorum satırlarını da içermektedir. Süslü parantez (brace) içerisindeki tüm satırlar sayılarak hesaplanır. Bu metrik, yürütülebilir olmayan satırları da içerdiğinden karmaşıklığı belirlemede kullanılması pek mümkün değildir. Tavsiye edilen değeri modülün yapısına bağlıdır. 2. Yorum satırı sayısı: Yorum satırlarının sayısıdır. Tavsiye edilen değer, modülün karmaşıklığına ve büyüklüğüne göre değişmektedir. 3. Çevrimsel karmaşıklık: Modülün karar yapısının karmaşıklığını gösterir. 30 dan küçük değerler kabul edilebilir arasındaki değerler modülün tehlikeli olduğunu gösterir ancak uzman görüşünün de alınarak karar verilmesi gerekir. Bunun sebebi algoritmaların bazen gerçekten karmaşık olabilmesidir. 3 basamaktan oluşan CC değerleri, o modülün bakım yapılabilirliğinin çok düşük olduğunu ve kesinlikle kusur eğilimli olduğunu gösterir.

4 4. Maksimum iç içe geçmiş derinlik (nesting depth): İç içe ifadelerin sayısıdır. Örneğin; iç içe 2 tane for döngüsü ve en içte bir if varsa, bu metotun maksimum iç içe geçmiş derinliği 3 olacaktır. 5. Döngü sayısı (loop): Metot içindeki döngülerin toplam sayısıdır. 6. Eşsiz (unique) operatör sayısı: Operatörlerin sayısıdır arası bir değer bu metrik için oldukça standarttır. Bu değer, 60 ın üzerine çıkınca modül karmaşıklaşmaya başlar. 125 in üzerindeki değerlerde modülün gözden geçirilmesi gerekir. 7. Eşsiz (unique) operand sayısı: arasındaki değerler oldukça standarttır. 60 dan yüksek değerler karmaşık bir modülü gösterirken, 100 den büyük değerler aşırı karmaşık modülleri gösterir. 8. Toplam operatör sayısı: Metottaki operatörlerin toplam sayısıdır. Operatörler dile bağlı olarak tanımlanır ancak aritmetik işlemler, bitwise işlemler, mantıksal işlemler ve operandlar üzerinde işleme neden olan özel anahtar sözcükler (return, sizeof, if) ve fonksiyon çağrıları birer operatör olarak kabul edilir arasındaki değer oldukça standarttır. 150 den büyük değerler karmaşıklığı gösterirken, 200 den büyük değere sahip olan modüllerin farklı modüllere ayrıştırılması gerekir. 9. Toplam operand sayısı: arası oldukça standarttır. 100 den büyük değerlere sahip olan modüllerin karmaşık olduğu bilinmektedir. 10. Mimari karmaşıklık: Bir modülün sistemin diğer elemanları ile olan etkileşiminin karmaşıklığını ifade eder (fonksiyon çağırma sayısı). Bir modülde çağrılan fonksiyon sayısı toplanarak hesaplanır. Mimari karmaşıklık değerleri birçok faktöre bağımlıdır ve spesifik bir rakam vermek güçtür. Genel olarak 60 ı geçen modüllerin incelenmesi gerekir. 11. Yürütülebilir (executable) ifade sayısı: Yürütülebilir satırların sayısıdır. 12. Yorum satırının kod satırına oranı: Yorum satırı sayısının kod satırı sayısına oranıdır. 0,05 den düşük değerler yetersiz yorum satırı olarak ifade edilir. 0,15 den büyük değerler uygundur. En azından 0,15 olan bir değer tavsiye edilir. Çok fazla yorum satırının olması da az olması gibi eleştirilmektedir, okumayı zorlaştırır. 13. Şartların (conditional) sayısı: Şartların sayısıdır. 14. Kararların (decision) sayısı: Kararların sayısıdır. 15. Yapısal (structural) karmaşıklık: Modül içerisinde yer alan karmaşık anahtar sözcüklerinin sayısına bağlı olarak kod karmaşıklığının ortaya konulduğu bir metriktir. Karmaşık anahtar sözcük (keyword), bazı kod satırlarını atlamamıza neden olan sözcüktür. 5 i geçen modüllerin önemli sayıda jump içerdiği ve okunmasının/anlaşılmasının zor olduğunu ifade edilir. 20 nin üzerindeki değerler okunması çok zor modülleri gösterir ve tasarım hataları genellikle bu modüllerde mevcuttur. 16. Çıkışların (exit) sayısı: Standart yazılım mühendisliği iyi yazılmış kodların tek giriş / tek çıkış olmasını önerir ve birden fazla return ifadesi kötü kodlama uygulaması olarak ifade edilir. Bu değerin 5 den fazla olması modülün gözden geçirilmesi gerektiğini ortaya koyar ve 20 den fazla olması bakım yapılabilirliğin çok zor olduğunu ve hata eğilimli olduğunu ifade eder. 17. Halstead Kelime (vocabulary): Bir modülü tamamen tanımlamak için gerekli olan eşsiz sözcüklerin (words) sayısıdır. Eşsiz operatör ve eşsiz operandların sayısı toplanarak hesaplanır arasındaki değerler oldukça standarttır. 100 den büyük değerler karmaşıklığı gösterirken, 125 den büyük değerler modülün parçalara ayrılması gerektiğini ortaya koyar. 18. Halstead Uzunluk (length): Bir modülü tamamen tanımlamak için gerekli olan sözcüklerin (words) toplam sayısıdır. Toplam operatör sayısı ve toplam operand sayısı toplanarak hesaplanır. 200 civarı oldukça standarttır ve 300 e kadar olması kabul edilebilirdir. 300 den fazla olanlar uzun modül olup, 500 den fazla olanlar ise kötü tasarlanmış ve kötü gerçeklenmiş modüllerdir. 19. Halstead Zorluk (difficulty): Bir modülün zorluğunu veya hata eğilimini gösterir. Aynı operandların aşırı kullanılmasına bağlı olarak hatayı ortaya koyan bir metriktir. Tek bir operand fazla sayıda kullanılmışsa ve hatalı atama yapıldıysa, birçok yerde hataya neden olacaktır. (Eşsiz operatör sayısı / 2)*(toplam operand sayısı/eşsiz operand sayısı) formülü ile hesaplanır. 35 e kadar olan değerler normaldir. 50 yi geçen değerler zorluğu ve hata eğilimini ortaya koymaktadır. 100 den büyük değerler karmaşıklığı ve hata eğiliminin şiddetini gösterir.

5 20. Halstead seviye (level): Zorluğun tersidir. 1 ve 0,02 arasındaki değerler oldukça tipiktir. 0,02 den küçük değerler hata eğilimli modülleri gösterir ve 0,01 den küçük değerler problemli modülleri işaret eder. 21. Halstead hacim (volume): Bir algoritmanın gerçekleme boyutunu tanımlar. 30 ve 1000 arasındaki değerler oldukça standarttır den büyük değerlere pek rastlanmaz den büyük modüllerin yeniden tasarlanması veya parçalara ayrılması gerekir. 22. Halstead zeka içeriği (intelligent content): Algoritmanın karmaşıklığının gösterimini sağlar ve teorik olarak programlama dili değişse de bu metrik aynı değere sahip olmalıdır. Hacim ve seviyenin çarpılması ile elde edilir. 50 den küçük değerler kabul edilir düzeydedir. 50 ve 100 arasındaki değerler modülün karmaşık olduğunu gösterir. 100 den büyük değere sahip metotların incelenmesi gerekir. 23. Halstead çaba (effort): Bir modülü gerçekleme veya anlama için gerekli çabadır. 100 den küçük değerler oldukça standarttır. 100 ve 500 arasındaki değerler düşük kaliteli kodu işaret eder. 500 den büyük değerler düşük kalitedeki kodu gösterir ancak tek başına bu metrik kullanılmamalıdır. 24. Halstead zaman (time): Modülü anlamak veya gerçeklemek için gerekli zamanı gösterir değeri programcının 1 saat zaman harcaması gerektiğini gösterir e kadar olan değerler kabul edilebilirdir den büyük değerler modülün düşük kalitede olduğunu tek başına göstermez, diğer metriklerle birlikte değerlendirilmelidir Halstead Metriklerinin Değerlendirilmesi Halstead, 1970 lerde önerdiği yazılım bilimi metriklerini (software science metrics), primitif ve türetilmiş metrikler olarak 2 gruba ayırmıştır. Programların operatör ve operandlardan oluştuğunu; operatör ve operand sayılarının program karmaşıklığı ile ilişkili olduğunu ifade etmiştir. Operatörler, derleyicinin derleme ya da çalışma zamanında bir eylem gerçekleştirmesine neden olur [7]. Diğer program sembolleri (token) ise operatörlerin ihtiyaç duyduğu operandlardır. Yorum (comment) satırları ne operand ne de operatördür. Halstead aşağıdaki metrikleri, primitif metrikler olarak açıklamıştır: µ 1 : eşsiz (unique) operator sayısı µ 2 : eşsiz (unique) operand sayısı N 1 : toplam operator sayısı N 2 : toplam operand sayısı Halstead, primitif metrikleri kullanarak yeni metrikler türetmiş ancak bu türetilmiş metrikler birçok açıdan eleştirilmiştir. İlk olarak; programın gerçekleme uzunluğu (implementation length of program) ve sözcük (vocabulary) metriklerine bakalım. Denklem 1 ve 2 ye göre, primitif metriklerin toplamlarının alındığı görülmektedir ve bu yeni metriklerin bu şekilde yeni bilgiler ortaya koyması mümkün değildir. N ile uzunluk gösterilirken µ ile sözcük metriği gösterilmektedir. N = N 1 + N 2 (1) µ = µ 1 + µ 2 (2) Bilgisayar bilimlerinde bir değerin 2 tabanına göre logaritmasının alınması gelenek haline geldiğinden, programın hesaplanmış uzunluğu (calculated length of program) ve programın hacmi (volume) metriklerinde de 2 tabanına göre logaritma uygulanmıştır [7]. Denklem 3 ve 4 te sırasıyla hesaplanmış uzunluk ve hacim metrikleri gösterilmektedir. Ñ = µ 1 log 2 µ 1 + µ 2 log 2 µ 2 (3) V = N log 2 µ (4) Temel Bileşen Analizi (Principal Component Analysis) gerçekleştirilirse, bu iki yeni metriğin primitif metriklerle aynı şekilde değiştiği, bu nedenle yeni bilgiler sunmadığı görülecektir. Bu noktada yeni metrikler türetmek üzere, 2 yeni kavram ortaya konulmuştur [7]: µ1*, gerçeklenen algoritma için farklı operatörlerin minimum sayısı µ2 *, gerçeklenen algoritma için farklı operandların minimum sayısı Bu yeni kavramlardan yeni metrikler türetilmek istenmesine rağmen, bu özelliklerin gerçek değerlerini ölçecek kurallar mevcut değildir. Bu nedenle, bu önerilen özellikler ölçümlere gürültü katmaktadırlar. Bu metrikler, yazılım metrik uzmanları tarafından yıllarca kullanılmış, ancak bu metriklerin geçerlenmesi yapılmamıştır [7]. Munson a göre [7], 4 primitif metrik yeterlidir. Yazılım kusur kestirim çalışmalarında bütün metrikleri kullanıp, daha sonra korelasyonun olduğu metrikleri özellik azaltma teknikleriyle yok etmek ve uygun alt metrik kümesini belirlemek mümkündür. Bu sayede, birbirleriyle korelasyon taşıyan metrikler veri kümesinden çıkartılarak model performansı iyileşecektir. Aşağıda bu özellikleri kullanan türetilmiş metrikler verilmektedir. 5. denklemle programın potansiyel

6 hacmi, 6. denklemle sınır hacmi hesaplanmaktadır. 7. denklemle program seviyesi, 8. denklemle program seviyesinin alternatif gösterimi hesaplanmaktadır. 9. denklemle bir programı gerçeklemenin zorluğu, 10. denklemle programın zeka içeriği, 11. denklemle program çabası, 12. denklemle programı yazmak için gerekli zaman, 13. denklemle programdaki tahmini hata sayısı hesaplanmaktadır. V* = (µ) (log 2 µ*) (5) V** = (2+ µ 2 *) ( log 2 (2+ µ 2 *) ) (6) L = V* / V (7) Ĺ = ( µ 1 *) (µ 2 ) / (µ 1 ) N 2 (8) D = 1 / L (9) I = Ĺ * V (10) E = V / L (11) T = E / 18 (12) B = E 2/3 / 3000 (13) 2.4. Önerilen Metrikler En son yapılan çalışmalarda [8], kusur kestirimi için metriklerden ziyade kullanılan algoritmaların daha önemli olduğu saptanmıştır. Uzun yıllar en iyi metrik kümesini bulmak üzerine çalışmalar sürdürmüş olan araştırmacıları düşündüğümüz zaman, bu sonuç oldukça ilgi çekicidir. Menzies ve arkadaşları [8], NASA açık veri kümeleri üzerinde yaptığı kusur kestirim çalışmasında, makine öğrenmesi tabanlı yaklaşımlardan en iyi performansın Naive Bayes algoritması ile alındığını raporlamışlardır. Algoritma uygulanmadan önce logfilter ile filtreleme yapılmaktadır. Literatürde çok farklı makine öğrenmesi algoritması bu amaçla kullanılmış ve iyi performans verdiği raporlanmıştır ancak bu çalışma en uygun algoritmayı raporlaması açısından önemlidir. Bu çalışmalarında, kusur kestirimi için metriklerden ziyade seçilen öğrenme algoritmasının daha kritik olduğunu da raporlamışlardır. Literatürdeki kusur kestirim çalışmalarında kullanılan metrikler dikkate alındığında aşağıdaki metriklerin, kusur eğilimliliği belirlemede minimum küme olarak kullanılması gerektiğini öneriyoruz. Ancak türetilmiş metrikleri hesaplayabilecek bir araç mevcutsa, o metrikleri de modellere katmak, dikkate almak mümkündür. Gerekirse özellik azaltma teknikleri ile birbiri ile korele olduğu belirlenen metrikler çıkarılabilir. Sınıf seviyesindeki metrikler olarak 6 adet CK metriği Metot seviyesindeki metrikler olarak; toplam kod satır sayısı, yorum satırı sayısı, çevrimsel karmaşıklık, eşsiz operatör sayısı, eşsiz operand sayısı, toplam operatör sayısı, toplam operand sayısı, yürütülebilir ifade sayısı Predictive aracı içerisinde türetilmiş Halstead metrikleri de hesaplanmakta ve bu metriklerin eşik seviyelerinin aşıldığı noktalarda modüller yüksek riskli ya da orta riskli olarak işaretlenmektedirler. Bu nedenle, bu çalışmada türetilmiş metrikler de dikkate alınmıştır. Kusur kestirimi konusunda uzun yıllardır çalışma yapan araştırmacılar, NASA açık veri kümelerindeki türetilmiş Halstead metriklerini kullanmamaktadırlar [9]. Ancak kusur etiketlerinin bilinmediği durumlar için kusur kestirim modellerinin kurgulanmasındaki zorluk dikkate alınırsa, türetilmiş metriklerin de eşik seviyelerine bağlı olarak değerlendirilme yapılması yararlı olacaktır. 3. SELinux Linux çekirdeğinin security dizini altında selinux klasörü yer almaktadır. Bu dizin altında yer alan 418 adet yöntem bu kapsamda incelenerek yüksek, orta ve düşük riskli yöntemler saptanmıştır. Bu analizleri sunmadan önce, selinux konusunda bilgi vermek yararlı olacaktır. Bu sayede, incelenen kodların önemi daha açık olarak ortaya konulabilir. SELinux, çeşitli güvenlik politikaları sunan bir Linux özelliğidir. Bu politikalardan birisi, Birleşik Devletlerin (U.S) Savunma Bakanlığı tipi zorunlu erişim denetimleri dir (mandatory access controls) ve Linux çekirdeği içindeki Linux güvenlik modüllerinin kullanımı ile bu politika gerçekleştirilebilir. SELinux, bir Linux dağıtımı değildir. Unix türü işletim sistemlerine (Linux veya BSD) uygulanabilecek değişiklikler kümesidir. SELinux de yer alan kavramlar, Birleşik Devletler Ulusal Güvenlik Teşkilatı (National Security Agency-NSA) tarafından gerçekleştirilen projelere dayanmaktadır [10]. SELinux yukarıda açıklandığı gibi, farklı güvenlik politikaları sunmakta, geleneksel Linux erişim denetim mekanizmasından önemli farklılıklar içermektedir. Denetimin fazla olması, performans açısından küçük sorunlar yaşatsa da, güvenliğin çok önemli olduğu sistemler için bu performans azalması ihmal edilebilir düzeydedir. Önceleri yama olarak Linux çekirdeğine ekleniyorken artık Linux ana hattına eklenmiştir. Bazı Linux dağıtımlarında bu özellik varsayılan (default) olarak seçili olarak gelebilmektedir. SELinux, ilk olarak Birleşik Devletler Ulusal Güvenlik Teşkilatı tarafından geliştirilmiş ve açık kaynak topluluğuna 22 Aralık 2000 de sunulmuş,

7 2.6.0-test çekirdeğine birleştirilerek 8 Ağustos 2003 de sürüm hazırlanmıştır. Önemli katkı sağlayanlar; Network Associates, Secure Computing Corporation, Trusted Computer Solutions ve Tresys isimli firmalardır. SELinux, Linux un 2.6.x sürümüne entegre edilmiştir ve ek yama kullanmaya gerek yoktur [10]. Güvenliği iyileştirilmiş Linux sayesinde, yeni çıkan güvenlik açıklıklarında (vulnerability) da sistemler sorun yaşamadan ayakta kalabilmektedir [11] yılında ortaya çıkan bazı güvenlik açıklıklarında, SELinux kullanan sistemler bir problemle karşılaşmamıştır [11]. SELinux u entegre eden Linux çekirdeği, zorunlu erişim denetimi politikalarının uygulanmasını zorunlu kılar, kullanıcı programlarını ve sistem sunucularının işlerini yapabilmeleri için minimum yetki ile sınırlandırır. Bu sayede, bu programların tampon taşması veya yanlış konfigürasyonlar nedeniyle zarar vermesini önler. Bu sınırlandırma mekanizması, geleneksel Linux erişim denetim mekanizmasından bağımsız çalışır. Değiştirilmemiş Linux sisteminde güvenlik, çekirdeğin doğruluğuna, hakka sahip uygulamaların doğruluğuna ve konfigürasyonların doğruluğuna bağlıdır. Bu alanlardan herhangi birinde problem olması tüm sistemin tehlikeye atılmasına izin verir. Bunun tam tersi olarak, selinux içerisinde güvenlik, çekirdeğin ve güvenlik politikası konfigürasyonunun doğruluğuna bağlıdır [10]. 4. Durum Çalışması Linux çekirdeğinin sürümü üzerinde, Predictive aracı çalıştırılarak yüksek riskli modüller belirlenmiştir. İncelenen metriklerin eşik seviyelerinin aşıldığı durumlarda, ilgili modül kırmızı ile işaretlenerek ilgili modülün yüksek riskli olduğu gösterilmiştir. SELinux kaynak kodları, \linux \security\selinux şeklinde linux kaynak kodlarının güvenlik dizini altında yer almaktadır. Bu dizinde yer alan kaynak kodlar, Şekil 1 de gösterilmektedir. Bu dizin içerisinde, yüksek riskli olduğu belirlenen metotlar Tablo 1 de gösterilmektedir. Bu metotların hangi metriklere bağlı olarak yüksek /orta riskli olarak işaretlendiği takip eden şekillerde gösterilmektedir. Şekillerde yeşil ile gösterilen modüller düşük riskli, sarı ile gösterilenler orta riskli, kırmızı ile gösterilenler yüksek risklidir. Metriklerin eşik seviyelerinin aşılma derecesi de bu renklendirme ile gösterilmektedir. Bu renkler, Predictive aracının varsayılan renk değerleridir. SELinux dizini içerisinde, include ve ss alt dizinleri yer almaktadır. Ayrıca, Şekil 1 de görüldüğü gibi bazı dosyalar bu alt dizinlerin içinde yer almayıp doğrudan SELinux dizini içerisinde bulunmaktadır. Şekil 1: SElinux Dizini İçerisindeki Dosyalar Tablo 1:SElinux Dizinindeki Yüksek Riskli Metotlar Metot Adı Dosya Adı mls_context_isvalid mls.c constraint_expr_eval services.c policydb_context_isvalid policydb.c class_read policydb.c policydb_read policydb.c cond_evaluate_expr conditional.c try_context_mount hooks.c socket_type_to_security_class hooks.c inode_mode_to_security_class hooks.c ss alt dizini içerisinde yer alan yüksek ve orta riskli dosyalar Şekil 2 de gösterilmektedir. mls.c, services.c, policydb.c, conditional.c ve hooks.c dosyaları içerisinde yer alan yüksek ve orta riskli metotlar takip eden şekillerde metrikleri ile birlikte gösterilmektedir. Düşük riskli metotlar ve eşik değerinin altında kalan metrikler (yeşille işaretleniyor) bu şekillerde gösterilmemektedir. SELinux dizini içerisinde; satır kod mevcut olup 418 metot bulunmaktadır. Bu metotlardan Tablo 1 de verilen 9 adet metot, yüksek riskli olduğundan metotların %2 sinin yaklaşık olarak yüksek riskli olduğu ifade edilebilir. SELinux dizininin ortalama çevrimsel karmaşıklığı, 5.47 olup, bu oldukça iyi bir değerdir. Ortalama mimari karmaşıklık ise 2.66 olarak hesaplanmıştır ve kabul edilir düzeyin altındadır. SELinux dizini altında 40 adet dosya mevcuttur. SELinux dizini içerisindeki, 20 adet modül ise orta risk düzeyindedir. Tüm metotlara oranı hesaplanınca,

8 metotların %5 inin orta düzeyde riskli olduğu ifade edilebilir. 389 metot ise tüm metrikler açısından eşik seviyelerinin altında olduğu için metotların %93 ünün düşük riskte olduğu söylenebilir. Kusur kestirim çalışmalarında şimdiye kadar elde edilen verilere göre, tüm modüllerde kusur çıkaran modüllerin en fazla %20 düzeylerinde olduğu saptanmıştır. NASA daki bazı projelerde kusurlu modül yüzdesi %7 olarak saptanmıştır (PC1 projesi). PC1 projesi, NASA da gerçekleştirilen uçuş yazılımıdır. Projenin detay bilgisi NASA tarafından verilmemektedir. Bu analizdeki verilere göre, yüksek ve orta riskli metotların kusur çıkaracağı düşünülürse kusurlu modül yüzdesi %2 + %5 = %7 olacaktır. 9 yüksek riskli ve 20 orta riskli modüllerin yüzdesi, tüm projenin %7 si düzeyindedir. Bu kestirim değeri, literatürde elde edilmiş değerlerle de uyumludur. Ancak net olarak hangi modüllerde kusur çıktığı bilinmeden bu çıkarımı doğrulamak mümkün değildir. SELinux projesi NSA ve diğer organizasyonların koordinasyonunda gerçekleştirilmiş olduğundan, test aşamalarında saptanan kusur verilerine ulaşmak pek mümkün görünmemektedir. Bu açıdan gerçekten bu metotların kusur çıkarıp çıkarmadığını söylemek zordur. İncelenen metotlar içerisinde en fazla yeniden yapılandırmaya (refactoring) ihtiyaç duyulan metotun, policydb.c içerisindeki policydb_read metotu olduğu söylenebilir. Bu metotun çevrimsel karmaşıklığı 101 dir. Yazılım Mühendisliği Enstitüsü ne göre [12], çevrimsel karmaşıklığı 50 den büyük olan metotlar yüksek riskli olup, test edilemez program kategorisine girmektedir. Tüm bağımsız yolların test edildiği durumda, tabii ki bu modüller de test edilebilir olmaktadır ancak bu tür metotların sayısının çok fazla olduğu modülleri ve aralarındaki etkileşimini düşünürsek, çevrimsel karmaşıklığı 50 den büyük olan modüllere test edilemez program denilmesinin nedeni daha kolay anlaşılabilir. policydb_read metotu; çevrimsel karmaşıklık, döngü sayısı, eşsiz operatör sayısı, toplam operand sayısı, toplam operatör sayısı, mimari karmaşıklık, yapısal karmaşıklık, Halstead hacim, Halstead sözcük, Halstead uzunluk metriklerinin eşik seviyelerini aşan değerlere sahiptir. Bu nedenle, bu metotun yeniden yapılandırılması ve/veya daha fazla test edilmesi gerekmektedir. Aksi halde, bu metotun bakım yapılabilirliğinden söz etmek güçleşir ve yeni özellikler eklerken kusurlara neden olunabilir. Yüksek riskli metotların metrikleri incelendiğinde; 6 yüksek riskli metotun çıkış (exits) metriği nedeniyle, 2 yüksek riskli metotun yapısal karmaşıklık (structural complexity) metriği nedeniyle ve 1 yüksek riskli metotun (policydb_read) yukarıda açıklanan birçok metrik nedeniyle yüksek riskli olduğu saptanmıştır. Metotlardaki return ifadelerinin sayılması ile çıkış metriği hesaplanmaktadır. Bu ifadelerin sayısının 6 metot için eşik seviyesinin üstünde olduğu saptanmıştır ancak diğer metrikler bu metotlar için uygun değerdedir. Karmaşık anahtar sözcük (keyword), bazı kod satırlarını atlamamıza neden olan sözcüktür ve bu sözcükler, yapısal karmaşıklığı hesaplarken sayılmaktadır. 2 metot için bu metriğin eşik seviyesinin üzerinde olduğu ve bu metotların yüksek riskli olduğu saptanmıştır. 5. Sonuç ve Gelecek Çalışmalar Bu çalışmada, uygulayıcıların kullanabilecekleri metot ve sınıf seviyesindeki metrikler açıklanmıştır. Ticari bir araç kullanılarak, SELinux projesi içerisindeki kaynak kodların risk durumu analiz edilmiştir. Kullanılan eşik seviyeleri ISM firmasının NASA nın verilerini yıllardır inceleyerek elde etmiş olduğu eşik seviyeleridir. Predictive aracı içerisinde eşik seviyelerini değiştirmek mümkündür. Bu çalışmada, yüksek riskli modüllerin kusur kestirim modelleri geliştirilmeden de sadece metrik ve eşik seviyelerine bağlı olarak belirlenebileceği örnek bir senaryoda gösterilmiştir. Yazılım geliştirme aktiviteleri süresince bu metriklerin hesaplanması ve yüksek risk doğuracak modüllerin yeniden yapılandırılmaya tabi tutulması gerekmektedir. Yeniden yapılandırmanın mümkün olmadığı durumlarda, bu modüllerin daha fazla test edilmesi kaçınılmazdır. Bu yıl itibariyle yazılım metriklerinin en popüler yazılım geliştirme ortamlarına (Visual Studio vb.) girdiği de dikkate alınırsa, önümüzdeki yıllarda yazılım geliştiricilerin yazılım metriklerine daha fazla önem vereceğini söylemek mümkündür. Tümleşik geliştirme ortamları içerisinde bu metriklerin hesaplanıyor olması, geliştiricilerin bu metrikleri daha fazla benimsemesini sağlayacak, bu metriklere bağlı olarak yazılım geliştirme prensipleri şekillenecektir. Kusur açısından yüksek riskli modülleri belirlemeye yarayan bu araçlar sayesinde, yazılım geliştirme ve yazılım kalitesi konusunda çok fazla bilgi sahibi olmayan son kullanıcılar ya da proje paydaşları, projede üretilen kaynak kodların kalitesini kolaylıkla görebilecektir. Kod kalitesini sağlamaya yönelik metriklerin kullanıldığı bu tür çalışmalar sayesinde, daha kaliteli ve bakım yapılabilirliği daha yüksek yazılımların ortaya çıkması beklenmektedir. Önümüzdeki dönemde, geliştireceğimiz Eclipse tabanlı araç içerisinde, önerdiğimiz metrikleri kullanmayı hedeflemekteyiz. Bu metrikleri öncelikli olarak, eğiticili öğrenme algoritmaları ile birlikte kullanacak

9 sonrasında yarı-eğiticili modellerin geliştirilmesi için de bu metriklerden yararlanacağız. Çoğu yazılım geliştirme aracı, yeniden yapılandırma için bizlere birçok yetenek sunmaktadır. Bir projedeki bir metotun adının değiştirilmesi, sınıfın ikiye bölünmesi gibi işlemler kolaylıkla bu tür araçlarla gerçekleştirilebilmektedir. Ancak bu araçların hemen hemen hiçbirinde yeniden yapılandırmada hangi modüllerin ele alınması gerektiği önerilmemektedir. Binlerce kaynak kod dosyası ve yüz binlerce metotun olduğu durumda, yeniden yapılandırmaya hangi modülden başlanacağı büyük bir sorundur. Bu noktada bu çalışmada açıklanan türde araçlarla yüksek riskli olduğu belirlenen modüller saptanarak bu modüller üzerinde yeniden yapılandırma işlemlerine başlanabilir. Kalite güvence grupları, yazılım geliştiricilerin kodları ve içerikleri hakkında bilgi sahibi olmadan da bu tür araçlarla yüksek riskli modülleri saptayabilmekte ve geliştiricilerden bu kapsamda bilgi isteyebilmektedir. Proje hakkında hiç bir bilginiz olmadan, bu tür kestirimleri yapıyor olmak aslında yazılım mühendisliği açısından önemli bir kazanımdır. Büyük yazılım projelerinde gözden kaçan noktaları ya da ileriki dönemde bakım yapılabilirlik açısından ciddi sorunlar yaşanabilecek modülleri erken safhada bu sayede belirleyebilirsiniz. İlgiye yönelik (aspectoriented) programlama yaklaşımının, her kavramı ilgi olarak değerlendirdiği simetrik durumlar için özel ilgi metriklerinin belirlenmesi ve bu kapsamda modellerin kurulması gelecekte gerçekleştirilebilecek çalışmalar olarak değerlendirilebilir. Literatürde ilgiye yönelik metriklerle, kusur eğilimli ilgilerin kestirildiği bir çalışmaya rastlanmamıştır. 7. Kaynaklar [1] McCabe, T., (1976), A complexity Measure, IEEE Trans. on Software Eng., 2(4): [2] Halstead, M., (1977), Elements of Software Science, Elsevier North-Holland, New York. [3] Gilb, T., (1976), Software Metrics, Chartwell-Bratt. [4] Çatal, Ç., Diri, B., (2007), Software Fault Prediction with Object-Oriented Metrics Based Artificial Immune Recognition System, Lecture Notes in Computer Science 4589, Springer-Verlag, sf [5] Çatal, Ç., Diri, B., (2008), A Fault Prediction Model with Limited Fault Data to Improve Test Process, Lecture Notes in Computer Science 5089, Springer- Verlag, sf [6] redictive/explanationofmetrics.pdf [7] Munson, J. C., (2003), Software Engineering Measurement, CRC Press Company, Boca Raton London, New York. [8] Menzies, T., Greenwald, J., ve Frank, A., (2007), Data Mining Static Code Attributes to Learn Defect Predictors, IEEE Transactions on Software Engineering, 33(1): [9] Seliya, N., Khoshgoftaar, T. M., (2007), Software Quality Estimation with Limited Fault Data: a Semi- Supervised Learning Perspective, Software Quality Journal, 15(3), [10] [11] [12] ww.sei.cmu.edu/str/descriptions/cyclomatic_body.html 6. Teşekkür Bu çalışma, 107E213 proje koduyla TÜBİTAK tarafından desteklenmektedir. Yayındaki hiçbir görüş, tespit ve kanaat TÜBİTAK ın resmi görüşü değildir. Projede gerçekleştirilecek olan Eclipse tabanlı ürün için bu çalışmada ifade edilen metriklerden yararlanılacaktır. Sınırlı sayıda ya da varolamayan kusur verisiyle kusur kestirimi modellerinin geliştirilmesi, bu proje kapsamında gerçekleştirilecektir.

10 Şekil 2: ss Alt Dizini İçerisindeki Yüksek/orta Riskli Dosyalar Şekil 3: mls.c Dosyası İçindeki Yüksek/orta Riskli Metotlar Şekil 4: services.c Dosyası İçindeki Yüksek/orta Riskli Metotlar Şekil 5: policydb.c İçerisindeki Yüksek/orta Riskli Metotlar

11 Şekil 6: conditional.c İçerisindeki Yüksek/orta Riskli Metotlar Şekil 7: sidtab.c İçerisindeki Yüksek/orta Riskli Metotlar Şekil 8: ebitmap.c İçerisindeki Yüksek/orta Riskli Metotlar Şekil 9: avc.c İçerisindeki Yüksek/orta Riskli Metotlar

MESLEKİ TERMİNOLOJİ I 1. HAFTA YAZILIM MÜH. TEMEL KAVRAMLAR

MESLEKİ TERMİNOLOJİ I 1. HAFTA YAZILIM MÜH. TEMEL KAVRAMLAR YAZILIM: SOFTWARE Yazılım (Software): Yazılım sadece bir bilgisayar programı değildir. Basılı veya elektronik ortamdaki her tür dokümanı da içeren ürün. Dokümanlar yazılım mühendislerine ve son kullanıcıya

Detaylı

Bölüm1. İlk Bilgiler ISBN 0-321-49362-1

Bölüm1. İlk Bilgiler ISBN 0-321-49362-1 Bölüm1 İlk Bilgiler ISBN 0-321-49362-1 Bölüm 1 Konuları Niye Programlama Dilleri prensiplerini öğreniyoruz? Programlama alanları Dil değerlendirme kriterleri Dit tasarımına etkiler Dil kategorileri Dil

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ı

Yazılım Nedir? 2. Yazılımın Tarihçesi 3. Yazılım Grupları 4 Sistem Yazılımları 4 Kullanıcı Yazılımları 5. Yazılımın Önemi 6

Yazılım Nedir? 2. Yazılımın Tarihçesi 3. Yazılım Grupları 4 Sistem Yazılımları 4 Kullanıcı Yazılımları 5. Yazılımın Önemi 6 ix Yazılım Nedir? 2 Yazılımın Tarihçesi 3 Yazılım Grupları 4 Sistem Yazılımları 4 Kullanıcı Yazılımları 5 Yazılımın Önemi 6 Yazılımcı (Programcı) Kimdir? 8 Yazılımcı Olmak 9 Adım Adım Yazılımcılık 9 Uzman

Detaylı

Qt Temelleri. Eren BAŞTÜRK. basturkeren@gmail.com www.erenbasturk.com

Qt Temelleri. Eren BAŞTÜRK. basturkeren@gmail.com www.erenbasturk.com Qt Temelleri Eren BAŞTÜRK basturkeren@gmail.com www.erenbasturk.com Giriş Qt Gelişim Süreci Merhaba Dünya Uygulaması Qt Creator İle Merhaba Dünya Uygulaması Qt ile Uygulama Geliştirme Bölüm İçeriği Öğrenecekleriniz......

Detaylı

Sunum İçeriği. Programlamaya Giriş 22.03.2011

Sunum İçeriği. Programlamaya Giriş 22.03.2011 Programlamaya Giriş Nesne Tabanlı Programlamaya Giriş ve FONKSİYONLAR Sunum İçeriği Nesne Tabanlı Programlama Kavramı Fonksiyon tanımlama ve kullanma Formal Parametre nedir? Gerçel Parametre nedir? Fonksiyon

Detaylı

Algoritma Geliştirme ve Veri Yapıları 9 Ağaç Veri Modeli ve Uygulaması. Mustafa Kemal Üniversitesi

Algoritma Geliştirme ve Veri Yapıları 9 Ağaç Veri Modeli ve Uygulaması. Mustafa Kemal Üniversitesi Algoritma Geliştirme ve Veri Yapıları 9 Ağaç Veri Modeli ve Uygulaması Ağaç, verilerin birbirine sanki bir ağaç yapısı oluşturuyormuş gibi sanal olarak bağlanmasıyla elde edilen hiyararşik yapıya sahip

Detaylı

YAZILIM KAVRAMINA BİR BAKIŞ. Gürcan Banger Elektrik Yük. Müh. ESOGÜ - 9 Nisan 2007

YAZILIM KAVRAMINA BİR BAKIŞ. Gürcan Banger Elektrik Yük. Müh. ESOGÜ - 9 Nisan 2007 YAZILIM KAVRAMINA BİR BAKIŞ Gürcan Banger Elektrik Yük. Müh. ESOGÜ - 9 Nisan 2007 YAZILIM ve DONANIM Bilgisayar kavramı, donanım ve yazılım olmak üzere iki ana bileşenden oluşuyor. Elektronik, mekanik

Detaylı

Görsel Programlama DERS 03. Görsel Programlama - Ders03/ 1

Görsel Programlama DERS 03. Görsel Programlama - Ders03/ 1 Görsel Programlama DERS 03 Görsel Programlama - Ders03/ 1 Java Dili, Veri Tipleri ve Operatörleri İlkel(primitive) Veri Tipleri İLKEL TİP boolean byte short int long float double char void BOYUTU 1 bit

Detaylı

İÇİNDEKİLER İÇİNDEKİLER KODLAB

İÇİNDEKİLER İÇİNDEKİLER KODLAB İÇİNDEKİLER IX İÇİNDEKİLER 1 GİRİŞ 1 Kitabın Amacı 1 Algoritmanın Önemi 2 Bilgisayarın Doğuşu ve Kullanım Amaçları 3 Programlama Dili Nedir? 3 Entegre Geliştirme Ortamı (IDE) Nedir? 4 2 ALGORİTMA VE AKIŞ

Detaylı

JAVA API v2.0 Belge sürümü: 2.0.2

JAVA API v2.0 Belge sürümü: 2.0.2 JAVA API v2.0 Belge sürümü: 2.0.2 1. İçindekiler 1. İÇİNDEKİLER... 2 2. BU BELGENİN AMACI... 3 3. BELGE SÜRÜMLERİ... 3 4. SİSTEM GEREKSİNİMLERİ... 3 5. KULLANIM ŞEKLİ... 4 5.1. GENEL... 4 5.2. UYARILAR...

Detaylı

YÖK TEZLERİ PROJE KELİME TARAMASI

YÖK TEZLERİ PROJE KELİME TARAMASI YÖK TEZLERİ PROJE KELİME TARAMASI YÖK Tezleri Proje Kelimesi Taraması Sonuçları Toplam Çalışma Sayısı 1833 İncelenen 1673 İlgisiz 372 Toplam İncelenen 1301 X Projesi 720 Proje Yönetimi 123 Yatırım Projeleri

Detaylı

Kaynak Kod Güvenliği Bir Güvensiz API Örneği

Kaynak Kod Güvenliği Bir Güvensiz API Örneği Kaynak Kod Güvenliği Bir Güvensiz API Örneği Bedirhan Urgun, Ağustos 2010, WGT E-Dergi 6. Sayı Bu yazıda Tomcat J2EE kısmi uygulama sunucusunda bulunan bir güvenlik açığına, güvenlik probleminin kaynağına

Detaylı

İş Süreçlerinin Yeniden Yapılandırılması (IE 320) Ders Detayları

İş Süreçlerinin Yeniden Yapılandırılması (IE 320) Ders Detayları İş Süreçlerinin Yeniden Yapılandırılması (IE 320) Ders Detayları Ders Adı Ders Dönemi Ders Kodu Saati Uygulama Saati Laboratuar Kredi AKTS Saati İş Süreçlerinin Yeniden Yapılandırılması IE 320 Seçmeli

Detaylı

PROGRAMLAMAYA GİRİŞ. Öğr. Gör. Ayhan KOÇ. Kaynak: Algoritma Geliştirme ve Programlamaya Giriş, Dr. Fahri VATANSEVER, Seçkin Yay.

PROGRAMLAMAYA GİRİŞ. Öğr. Gör. Ayhan KOÇ. Kaynak: Algoritma Geliştirme ve Programlamaya Giriş, Dr. Fahri VATANSEVER, Seçkin Yay. PROGRAMLAMAYA GİRİŞ Öğr. Gör. Ayhan KOÇ Kaynak: Algoritma Geliştirme ve Programlamaya Giriş, Dr. Fahri VATANSEVER, Seçkin Yay., 2007 Algoritma ve Programlamaya Giriş, Ebubekir YAŞAR, Murathan Yay., 2011

Detaylı

Web Madenciliği (Web Mining)

Web Madenciliği (Web Mining) Web Madenciliği (Web Mining) Hazırlayan: M. Ali Akcayol Gazi Üniversitesi Bilgisayar Mühendisliği Bölümü Konular Denetimli Öğrenmenin Temelleri Karar Ağaçları Entropi ID3 Algoritması C4.5 Algoritması Twoing

Detaylı

Yazılım Kodlama ve İ simlendirme Standartları v1.0

Yazılım Kodlama ve İ simlendirme Standartları v1.0 Yazılım Kodlama ve İ simlendirme Standartları v1.0 İçerik Yazılım Kodlama ve İsimlendirme Standartları... 2 1. Amaç... Hata! Yer işareti tanımlanmamış. 2. Kapsam... Hata! Yer işareti tanımlanmamış. 3.

Detaylı

Önemli noktalar. Paradigma Nesnelere Giriş Mesajlar / Ara bağlantılar Bilgi Gizleme (Information Hiding ) Sınıflar(Classes) Kalıtım/Inheritance

Önemli noktalar. Paradigma Nesnelere Giriş Mesajlar / Ara bağlantılar Bilgi Gizleme (Information Hiding ) Sınıflar(Classes) Kalıtım/Inheritance Önemli noktalar Paradigma Nesnelere Giriş Mesajlar / Ara bağlantılar Bilgi Gizleme (Information Hiding ) Sınıflar(Classes) Kalıtım/Inheritance public class Test { // çalışır İnsan insan = new Çiçekçi();

Detaylı

1 PROGRAMLAMAYA GİRİŞ

1 PROGRAMLAMAYA GİRİŞ İÇİNDEKİLER IX İÇİNDEKİLER 1 PROGRAMLAMAYA GİRİŞ 1 Problem Çözme 1 Algoritma 1 Algoritmada Olması Gereken Özellikler 2 Programlama Dilleri 6 Programlama Dillerinin Tarihçesi 6 Fortran (Formula Translator)

Detaylı

Yıldız Teknik Üniversitesi Bilgi Sistemi AutoCAD Map İle Gerçekleştirilen Bir Uygulama

Yıldız Teknik Üniversitesi Bilgi Sistemi AutoCAD Map İle Gerçekleştirilen Bir Uygulama Yıldız Teknik Üniversitesi Bilgi Sistemi AutoCAD Map İle Gerçekleştirilen Bir Uygulama Arzu Çöltekin Yıldız Teknik Üniversitesi Jeodezi ve Fotogrametri Yük. Müh. Araştırma Görevlisi 1/5 Özet Günümüzde

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ı

Kalite Kontrol Yenilikler

Kalite Kontrol Yenilikler Kalite Kontrol Yenilikler Amaç ve Fayda Kalite Kontrol modülünde ISO 2859 standardının desteklenmesine, kullanımın daha fonksiyonel ve rahat olabilmesine yönelik bazı iyileştirme çalışmaları yapılmıştır.

Detaylı

BİL 542 Paralel Hesaplama. Dersi Projesi. MPJ Express Java Paralel Programlama

BİL 542 Paralel Hesaplama. Dersi Projesi. MPJ Express Java Paralel Programlama BİL 542 Paralel Hesaplama Dersi Projesi MPJ Express Java Paralel Programlama Recep Ali YILMAZ 131419106 Fen Bilimleri Enstitüsü Bilgisayar Mühendisliği Bölümü Bilgisayar Mühendisliği Yüksek Lisans Programı

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ı

Excel de Düşeyara Vlookup) Fonksiyonunun Kullanımı

Excel de Düşeyara Vlookup) Fonksiyonunun Kullanımı FARUK ÇUBUKÇU EXCEL AKADEMİ Excel de Düşeyara Vlookup) Fonksiyonunun Kullanımı Excel de arama ve veri işleme konusunda en önemli fonksiyonlardan birisi olan DÜŞEYARA (İngilizce sürümde VLOOKUP) fonksiyonu

Detaylı

Ders 8 Konu Özeti ve Problemler

Ders 8 Konu Özeti ve Problemler Ders 8 Konu Özeti ve Problemler C# ve Nesne Yönelimli Programlamanın 3 Prensibi Kapsülleme (Encapsulation) Nesne yönelimli programlamanın ilk prensibi kapsülleme (encapsulation) olarak adlandırılır. Bu

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ı

Yazılım Mühendisliği Bölüm - 3 Planlama. Cengiz GÖK

Yazılım Mühendisliği Bölüm - 3 Planlama. Cengiz GÖK Yazılım Mühendisliği Bölüm - 3 Planlama Cengiz GÖK 1 Planlama Yazılım geliştirme sürecinin ilk aşaması Başarılı bir proje geliştirebilmek için projenin tüm resminin çıkarılması işlemi Proje planlama aşamasında

Detaylı

Bilgisayar Mühendisliği. Bilgisayar Mühendisliğine Giriş 1

Bilgisayar Mühendisliği. Bilgisayar Mühendisliğine Giriş 1 Bilgisayar Mühendisliği Bilgisayar Mühendisliğine Giriş 1 Mühendislik Nedir? Mühendislik, bilim ve matematiğin yararlı cihaz ve sistemlerin üretimine uygulanmasıdır. Örn: Elektrik mühendisleri, elektronik

Detaylı

BİLGİSAYAR MÜHENDİSLİĞİ BÖLÜM BAŞKANLIĞI DERS TANITIM BİLGİLERİ

BİLGİSAYAR MÜHENDİSLİĞİ BÖLÜM BAŞKANLIĞI DERS TANITIM BİLGİLERİ BİLGİSAYAR MÜHENDİSLİĞİ BÖLÜM BAŞKANLIĞI DERS TANITIM BİLGİLERİ Dersin Adı Kodu Sınıf / Y.Y. Ders Saati (T+U+L) Kredi AKTS YAZILIM MÜHENDİSLİĞİ BG-411 4/1 3+0+0 3+0 5 Dersin Dili : TÜRKÇE Dersin Seviyesi

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ı

BİL-142 Bilgisayar Programlama II

BİL-142 Bilgisayar Programlama II BİL-142 Bilgisayar Programlama II (C/C++) Hazırlayan: M.Ali Akcayol Gazi Üniversitesi Bilgisayar Mühendisliği Bölümü Konular Giriş Kontrol Yapıları if Seçme Deyimi if... else Seçme Deyimi while Tekrar

Detaylı

@6 SERİSİ ÜRÜN KURULUMU

@6 SERİSİ ÜRÜN KURULUMU @6 SERİSİ ÜRÜN KURULUMU Ürün Grubu [X] Fusion [X] Fusion Standard [X] Entegre W3 Kategori [X] Yeni Fonksiyon Versiyon Önkoşulu @6 Uygulama @6 serisi ürünlerin kurulum işlemleri sadece on-line internet

Detaylı

ÖZET...V ABSTRACT...VII TEŞEKKÜR... IX ŞEKİLLER DİZİNİ... XIV SÖZLÜK... XIX

ÖZET...V ABSTRACT...VII TEŞEKKÜR... IX ŞEKİLLER DİZİNİ... XIV SÖZLÜK... XIX XI İÇİNDEKİLER ÖZET...V ABSTRACT...VII TEŞEKKÜR... IX ŞEKİLLER DİZİNİ... XIV SÖZLÜK... XIX 1. GİRİŞ... 1 2. PLANLAMANIN TARİHÇESİ... 7 2.1 Literatürdeki Planlayıcılar ve Kullandıkları Problem... Gösterimi

Detaylı

Mobil Uygulama Yazılımlarında Yazılım Metriklerinin Kullanılması

Mobil Uygulama Yazılımlarında Yazılım Metriklerinin Kullanılması Mobil Uygulama Yazılımlarında Yazılım Metriklerinin Kullanılması Using Software Metrics in Mobile Applications Software Dr. Aziz Can Yücetürk Vodafone IT Hizmetleri A.Ş. İstanbul aziz.yuceturk@vodafone.com

Detaylı

SIMAN KULLANIM KILAVUZU

SIMAN KULLANIM KILAVUZU SIMAN KULLANIM KILAVUZU Önder Öndemir SIMAN Simülasyon programı Model Çatı ve Deneysel Çatı olmak üzere iki kısımdan oluşur. Model çatı genel itibariyle modullerin ve işlem bloklarının yazıldığı kısımdır.

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ı

Windows Mobile İşletim Sistemleri İçin Veri Giriş Yazılımı

Windows Mobile İşletim Sistemleri İçin Veri Giriş Yazılımı Windows Mobile İşletim Sistemleri İçin Veri Giriş Yazılımı Yasin Hınıslıoğlu 1 Mehmet Serdar Güzel 2 1 Ahmet Yesevi Üniversitesi Yönetim Bilişim Sistemleri Bölümü, Ankara 2 Ankara Üniversitesi Bilgisayar

Detaylı

Rapor Hazırlama Kuralları

Rapor Hazırlama Kuralları Temel Bilgiler 1. Temel Bilgiler Rapor Hazırlama Kuralları Bilgisayar programcılıüı öğrencilerinin hazırlayacakları tüm proje ve bitirme projesiraporlarını bu belgede açıklandığı biçimde hazırlamaları

Detaylı

HIZLI DURUM TESPİT (DURTES) YÖNTEMİ YAZILIMININ GELİŞTİRİLMESİ

HIZLI DURUM TESPİT (DURTES) YÖNTEMİ YAZILIMININ GELİŞTİRİLMESİ HIZLI DURUM TESPİT (DURTES) YÖNTEMİ YAZILIMININ GELİŞTİRİLMESİ Rasim TEMUR, N.Kemal ÖZTORUN İstanbul Üniversitesi, Mühendislik Fakültesi, İnşaat Mühendisliği Bölümü 34850 Avcılar / İstanbul E-Posta: temur@istanbul.edu.tr

Detaylı

COM API v2.0 Belge sürümü : 2.0.3

COM API v2.0 Belge sürümü : 2.0.3 COM API v2.0 Belge sürümü : 2.0.3 1. Đçindekiler 1. Đçindekiler...2 2. Bu belgenin amacı...3 3. Belge sürümleri...3 4. Sistem gereksinimleri...3 5. Kullanım şekli...4 5.1 Genel...4 5.2 Uyarılar...4 5.3

Detaylı

BİLGİSAYAR MÜHENDİSLİĞİ BÖLÜM BAŞKANLIĞI DERS TANITIM BİLGİLERİ

BİLGİSAYAR MÜHENDİSLİĞİ BÖLÜM BAŞKANLIĞI DERS TANITIM BİLGİLERİ BİLGİSAYAR MÜHENDİSLİĞİ BÖLÜM BAŞKANLIĞI DERS TANITIM BİLGİLERİ Dersin Adı Kodu Sınıf / Y.Y. Ders Saati (T+U+L) Kredi AKTS PROGRAMLAMA BG-213 2/1 2+0+2 2+1 5 Dersin Dili : TÜRKÇE Dersin Seviyesi : LİSANS

Detaylı

5. PROGRAMLA DİLLERİ. 5.1 Giriş

5. PROGRAMLA DİLLERİ. 5.1 Giriş 5. PROGRAMLA DİLLERİ 8.1 Giriş 8.2 Yazılım Geliştirme Süreci 8.3 Yazılım Geliştirme Sürecinde Programlama Dilinin Önemi 8.4 Programlama Dillerinin Tarihçesi 8.5 Programlama Dillerinin Sınıflandırılması

Detaylı

2 ALGORİTMA VE AKIŞ DİYAGRAMLARI

2 ALGORİTMA VE AKIŞ DİYAGRAMLARI İÇİNDEKİLER IX İÇİNDEKİLER 1 GİRİŞ 1 Kitabın Amacı 1 Algoritmanın Önemi 2 Bilgisayarın Doğuşu ve Kullanım Amaçları 3 Programlama Dili Nedir? 3 Entegre Geliştirme Ortamı (IDE) Nedir? 4 2 ALGORİTMA VE AKIŞ

Detaylı

I. Oturum: GNU/LINUX A GİRİŞ

I. Oturum: GNU/LINUX A GİRİŞ Son Kullanıcılar İçin GNU/Linux Eğitimi - I. Gün 20 Kasım 2011 1 Tarihçe Özgür Yazılım Hareketi Linux un Ortaya Çıkışı ; Açık Kaynak Hareketi Olgunluk Dönemi 2 Temel Özgürlükler Açık Kaynak 3 Dağıtım Ne

Detaylı

T.C. KIRIKKALE ÜNİVERSİTESİ BİLGİSAYAR MÜHENDİSLİĞİ BÖLÜMÜ YAPAY SİNİR AĞLARI. Doç.Dr. Necaattin BARIŞÇI FİNAL PROJESİ

T.C. KIRIKKALE ÜNİVERSİTESİ BİLGİSAYAR MÜHENDİSLİĞİ BÖLÜMÜ YAPAY SİNİR AĞLARI. Doç.Dr. Necaattin BARIŞÇI FİNAL PROJESİ T.C. KIRIKKALE ÜNİVERSİTESİ BİLGİSAYAR MÜHENDİSLİĞİ BÖLÜMÜ YAPAY SİNİR AĞLARI Doç.Dr. Necaattin BARIŞÇI YAPAY SİNİR AĞLARI İLE KORONER ARTER HASTALIĞI RİSK Öğrenci : SİNEM ÖZDER Numarası : 118229001004

Detaylı

28 Aralık 2013. Yıldız Teknik Üniversitesi Bilgisayar Mühendisliği Bölümü

28 Aralık 2013. Yıldız Teknik Üniversitesi Bilgisayar Mühendisliği Bölümü 28 Aralık 13 Yıldız Teknik Üniversitesi Bilgisayar Mühendisliği Bölümü 12-13 Eğitim Yılında (Ocak-Kasım 13 tarihleri arasında) doldurulmuş olan Bölümü Değerlendirme Anket Formları Raporu Öğrencilerin staj

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ı

=~ Metodu 92 Karakter Sınıfları 94 sub ve gsub metotları 101 Hızlı Tekrar 102 Kontrol Noktası 103 Düello 106 Sonraki Bölümde 109

=~ Metodu 92 Karakter Sınıfları 94 sub ve gsub metotları 101 Hızlı Tekrar 102 Kontrol Noktası 103 Düello 106 Sonraki Bölümde 109 vii 1 Neden Ruby? 2 Ruby Kurulumu 5 Windows ta Ruby Kurulumu 5 Linux ve Mac OS ta Ruby Kurulumu 6 Doğru Geliştirme Ortamının Seçimi 6 Diğer Ruby Uyarlamaları 9 Örnek Kodlar Hakkında 10 İnternet Adresi

Detaylı

Microsoft Excel Uygulaması 2

Microsoft Excel Uygulaması 2 Microsoft Excel Uygulaması 2 Dört Temel İşlem: MS Excel hücrelerinde doğrudan değerlere ya da hücre başvurularına bağlı olarak hesaplamalar yapmak mümkündür. Temel aritmetik işlemlerin gerçekleştirilmesi

Detaylı

C Dersleri Bölüm 3 : Program akışı

C Dersleri Bölüm 3 : Program akışı İzmir Ekonomi Üniversitesi Bilgisayar Topluluğu www.ieubt.org C Dersleri Bölüm 3 : Program akışı Sorularınız için : programlama@ieubt.org Hazırlayan : Görkem PAÇACI (gorkem.pacaci@std.ieu.edu.tr) C Program

Detaylı

SAMM ile Güvenli Yazılım Geliştirme

SAMM ile Güvenli Yazılım Geliştirme SAMM ile Güvenli Yazılım Geliştirme Emin İslam Tatlı, Aralık 2010, WGT E-Dergi 7. Sayı 1. SAMM Nedir? Yazılım geliştirme süreçleri (Waterfall, Spiral, Agile gibi) temelde planlama, tasarım, kodlama, test,

Detaylı

Pardus Temel Seviye Kullanıcı Eğitimi. Sürüm 1.0 13 Ağustos 2012 Pardus 2011.3K Fatih Akıllı Tahta sürümüne göre hazırlanmıştır.

Pardus Temel Seviye Kullanıcı Eğitimi. Sürüm 1.0 13 Ağustos 2012 Pardus 2011.3K Fatih Akıllı Tahta sürümüne göre hazırlanmıştır. Pardus Temel Seviye Kullanıcı Eğitimi Sürüm 1.0 13 Ağustos 2012 Pardus 2011.3K Fatih Akıllı Tahta sürümüne göre hazırlanmıştır. Bu bölümde, Pardus projesinin ne şekilde ortaya çıktığı ve amaçları açıklanacaktır.

Detaylı

Moodle-IST Kullanım Klavuzu

Moodle-IST Kullanım Klavuzu Moodle-IST Kullanım Klavuzu 1 İÇİNDEKİLER 1. ÖYS (Öğrenim Yönetim Sistemi) ve Moodle Nedir?...3 2. Sisteme Giriş...4 2. Ders Takibi...5 4. Ödev yükleme...7 2 1. ÖYS (Öğrenim Yönetim Sistemi) ve Moodle

Detaylı

Bilgi Güvenliği Eğitim/Öğretimi

Bilgi Güvenliği Eğitim/Öğretimi Bilgi Güvenliği Eğitim/Öğretimi İbrahim SOĞUKPINAR Gebze Yüksek Teknoloji Enstitüsü İçerik Bilgi Güvenliği Eğitim/Öğretimi Dünyadaki Örnekler Türkiye deki Örnekler GYTE de Bilgi Güvenliği Dersi Sonuç ve

Detaylı

Öğr. Gör. Serkan AKSU http://www.serkanaksu.net. http://www.serkanaksu.net/ 1

Öğr. Gör. Serkan AKSU http://www.serkanaksu.net. http://www.serkanaksu.net/ 1 Öğr. Gör. Serkan AKSU http://www.serkanaksu.net http://www.serkanaksu.net/ 1 JavaScript JavaScript Nedir? Nestcape firması tarafından C dilinden esinlenerek yazılmış, Netscape Navigator 2.0 ile birlikte

Detaylı

INTEGER OVERFLOW ***************************************************************/

INTEGER OVERFLOW ***************************************************************/ INTEGER OVERFLOW BELGE HAKKINDA Bu belge "GNU Free Documentation Licence" ile kaynak gösterilmek ve önceden yazarından izin alınmak kaydıyla yeniden yayınlanabilir. Bu belgedeki eksik, yanlış ya da geliştirilmesi

Detaylı

Bir yazılım geliştirme metodolojisi aşağıdaki adımlardan meydana gelir; Yazılım geliştirme sürecine destek verecek araçlar, modeller ve yöntemler.

Bir yazılım geliştirme metodolojisi aşağıdaki adımlardan meydana gelir; Yazılım geliştirme sürecine destek verecek araçlar, modeller ve yöntemler. Yazılım Mühendisliği kapsamındaki Yazılım Geliştirme Metodolojileri, bir bilgi sistemini geliştirme sürecinin yapımını, planlamasını ve kontrolünü sağlayan bir framework tür. Her farklı framework güçlü

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ı

NESNEYE YÖNELİK TASARIM SÜRECİ

NESNEYE YÖNELİK TASARIM SÜRECİ NESNEYE YÖNELİK TASARIM SÜRECİ GİRİŞ Nasıl? sorusuna yanıt aranır. Nesne modeli: Analizden tasarıma. Doğrudan problem alanı ile ilgili nesnelerden oluşan model, yardımcı nesnelerle zenginleştirilir. Ana

Detaylı

Akış. Atik Yazılım Geliştirme Tanımı ve Kavramlar Tarihi Metotları Dünyada Atik Yazılım Geliştirme Örnekleri Sonuç BİL 588 2

Akış. Atik Yazılım Geliştirme Tanımı ve Kavramlar Tarihi Metotları Dünyada Atik Yazılım Geliştirme Örnekleri Sonuç BİL 588 2 BİL 588 1 Akış Atik Yazılım Geliştirme Tanımı ve Kavramlar Tarihi Metotları Dünyada Atik Yazılım Geliştirme Örnekleri Sonuç BİL 588 2 BİL 588 3 Atik Yazılım Geliştirme Atik Yazılım Geliştirme, yazılım

Detaylı

VERİ YAPILARI VE PROGRAMLAMA (BTP104)

VERİ YAPILARI VE PROGRAMLAMA (BTP104) VERİ YAPILARI VE PROGRAMLAMA (BTP104) Yazar: Doç.Dr. İ. Hakkı CEDİMOĞLU S1 SAKARYA ÜNİVERSİTESİ Adapazarı Meslek Yüksekokulu Bu ders içeriğinin basım, yayım ve satış hakları Sakarya Üniversitesi ne aittir.

Detaylı

ERP Uygulama Öncesi Değerlendirme

ERP Uygulama Öncesi Değerlendirme ERP Uygulama Öncesi Değerlendirme ERP standartlarını uygulama baskısı, verimli, pratik, güvenli ve uygulanabilir süreçlerin tasarımına engel olabilir. Birçok uygulama projesinde, iş süreçlerindeki verimlilik,

Detaylı

PASCAL PROGRAMLAMA DİLİ YAPISI

PASCAL PROGRAMLAMA DİLİ YAPISI BÖLÜM 3 PASCAL PROGRAMLAMA DİLİ YAPISI 3.1. Giriş Bir Pascal programı en genel anlamda üç ayrı kısımdan oluşmuştur. Bu kısımlar bulunmaları gereken sıraya göre aşağıda verilmiştir. Program Başlığı; Tanımlama

Detaylı

JAVA RMI ve Hibernate teknolojileri kullanılarak çok amaçlı bir yazılım altyapısı hazırlanması

JAVA RMI ve Hibernate teknolojileri kullanılarak çok amaçlı bir yazılım altyapısı hazırlanması JAVA RMI ve Hibernate teknolojileri kullanılarak çok amaçlı bir yazılım altyapısı hazırlanması Hakan ALBAĞ Tahsin Barış AKAN Bitirme Projesi 05.06.2006 Giriş Ticari yazılımlarda ortak ihtiyaçlar Birden

Detaylı

BIM 312 Database Management Systems. Veritabanı Kavramına Giriş

BIM 312 Database Management Systems. Veritabanı Kavramına Giriş BIM 312 Database Management Systems Veritabanı Kavramına Giriş Veritabanı Nedir? Veritabanı, birbirleriyle ilişkili verilerin hızlı ve verimli bir şekilde ulaşılmasına olanak verecek biçimde saklanmasıyla

Detaylı

CMMI ve Çevik Yöntemler

CMMI ve Çevik Yöntemler CMMI ve Çevik Yöntemler Kasım 2006 http:// Büyük k Resim Sorunlar Çözümler Tıbbi Kontrol ISO EFQM CMMI 9001 Yaşam Tarzı RUP MSF XP 2 CMMI Anlaşı şılmamış 3 Proje YönetimininY Tarihi netiminin Tarihi http://home.gwu.edu/~kwak/pm_history.pdf

Detaylı

1 Temel Kavramlar. Veritabanı 1

1 Temel Kavramlar. Veritabanı 1 1 Temel Kavramlar Veritabanı 1 Veri Saklama Gerekliliği Bilgisayarların ilk bulunduğu yıllardan itibaren veri saklama tüm kurum ve kuruluşlarda kullanılmaktadır. Veri saklamada kullanılan yöntemler; Geleneksel

Detaylı

PAROLA GÜVENLİĞİ. İlker Korkmaz. ilker.korkmaz@ieu.edu.tr homes.ieu.edu.tr/ikorkmaz 08/06 UBE

PAROLA GÜVENLİĞİ. İlker Korkmaz. ilker.korkmaz@ieu.edu.tr homes.ieu.edu.tr/ikorkmaz 08/06 UBE PAROLA GÜVENLİĞİ İlker Korkmaz ilker.korkmaz@ieu.edu.tr homes.ieu.edu.tr/ikorkmaz SUNUM TASLAĞI 1. BÖLÜM: İNTERNET HAFTASI HAKKINDA Türkiye de İnternet Haftası neyi amaçlar? 2. BÖLÜM: PAROLALAR HAKKINDA

Detaylı

COMPUTERIZED AUDIT PROGRAM BİLGİSAYARLI DENETİM PROGRAMI

COMPUTERIZED AUDIT PROGRAM BİLGİSAYARLI DENETİM PROGRAMI COMPUTERIZED AUDIT PROGRAM 1 İçerik CAP-... 3 1. Müşteri tanımları... 3 2. Kullanıcı ve Rol Tanımları... 3 3. Müşteri Kabul Politikası... 4 4. Yıllık Denetim Planı... 4 5. Devamlı Denetim Dosyası... 4

Detaylı

Aşırı Programlama İçin Üç Yeni Pratik

Aşırı Programlama İçin Üç Yeni Pratik Aşırı Programlama İçin Üç Yeni Pratik Mustafa Yıldız, Gürol Erdoğan, Selahattin Kuru Enformatik Uygulama ve Araştırma Merkezi, Işık Üniversitesi, İstanbul {mustafa, gurol, kuru}@isikun.edu.tr Özet. Aşırı

Detaylı

Spring Giriş Eğitimi

Spring Giriş Eğitimi Spring Giriş Eğitimi Bu eğitimde Spring ın hangi problemlere karşı etkili olduğundan bahsedeceğim. Ayrıca çekirdek Spring teknolojisinin nasıl işlediği; Dependency Injection - DI ve Inversion of Contol

Detaylı

Yazılım Projelerinde Büyüklük Tahmini

Yazılım Projelerinde Büyüklük Tahmini Yazılım Projelerinde Büyüklük Tahmini Emin BORANDAĞ 1, Fatih YÜCALAR 1,Önder ŞAHİNASLAN 2 1 Maltepe Üniversitesi, Mühendislik ve Doğa Bilimleri Fakültesi, Yazılım Mühendisliği Bölümü 2 Maltepe Üniversitesi,

Detaylı

Bilgisayar Mühendisliğine Giriş. Yrd.Doç.Dr.Hacer KARACAN

Bilgisayar Mühendisliğine Giriş. Yrd.Doç.Dr.Hacer KARACAN Bilgisayar Mühendisliğine Giriş Yrd.Doç.Dr.Hacer KARACAN İçerik Dosya Organizasyonu (File Organization) Veritabanı Sistemleri (Database Systems) BM307 Dosya Organizasyonu (File Organization) İçerik Dosya

Detaylı

NESNEYE YÖNELİK PROGRAMLAMA Unified Modelling Language (UML) Bütünleşik Modelleme Dili

NESNEYE YÖNELİK PROGRAMLAMA Unified Modelling Language (UML) Bütünleşik Modelleme Dili Özlem AYDIN NESNEYE YÖNELİK PROGRAMLAMA Unified Modelling Language (UML) Bütünleşik Modelleme Dili Trakya Üniversitesi Bilgisayar Mühendisliği Bölümü MODEL NEDİR? Model, gerçek dünyadaki bir olayın veya

Detaylı

YAZILIM KALİTESİ İÇİN YİNELEMELİ ÖLÇME YÖNTEMİ

YAZILIM KALİTESİ İÇİN YİNELEMELİ ÖLÇME YÖNTEMİ YAZILIM KALİTESİ İÇİN YİNELEMELİ ÖLÇME YÖNTEMİ Nurdan CANBAZ, Feza BUZLUCA Bilgisayar ve Bilişim Fakültesi İstanbul Teknik Üniversitesi İstanbul, Türkiye nurcanbaz@itu.edu.tr, buzluca@itu.edu.tr Özet-Bilgisayar

Detaylı

Sistem Geliştirme Yaşam Döngüsü (The Systems Development Life Cycle) (SDLC)

Sistem Geliştirme Yaşam Döngüsü (The Systems Development Life Cycle) (SDLC) Sistem Geliştirme Yaşam Döngüsü (The Systems Development Life Cycle) (SDLC) Sistem analistlerinin ve kullanıcı faaliyetlerinin spesifik döngüsünün kullanılmasıyla En iyi geliştirilmiş sistemin oluşmasını

Detaylı

Bilgisayar Programlama

Bilgisayar Programlama Bilgisayar Programlama M Dosya Yapısı Kontrol Yapıları Doç. Dr. İrfan KAYMAZ Matlab Ders Notları M-dosyası Genel tanıtımı : Bir senaryo dosyası (script file) özel bir görevi yerine getirmek için gerekli

Detaylı

ELN1001 BİLGİSAYAR PROGRAMLAMA I

ELN1001 BİLGİSAYAR PROGRAMLAMA I ELN1001 BİLGİSAYAR PROGRAMLAMA I DEPOLAMA SINIFLARI DEĞİŞKEN MENZİLLERİ YİNELEMELİ FONKSİYONLAR Depolama Sınıfları Tanıtıcılar için şu ana kadar görülmüş olan özellikler: Ad Tip Boyut Değer Bunlara ilave

Detaylı

Görsel Programlama DERS 01. Görsel Programlama - Ders01/ 1

Görsel Programlama DERS 01. Görsel Programlama - Ders01/ 1 Görsel Programlama DERS 01 Görsel Programlama - Ders01/ 1 Takdim Planı Nesneye Dayalı Programlama Kavramı Nesne, Sınıf Kavramı Java Programlama Dili Java Programlama Dili Temel Özellikleri Java Sürümleri

Detaylı

CMMI. CMMI ve Çevik Yöntemler. Orhan KALAYCI Haziran 2007. Yazılım Süreç Kalitesi ve Yönetim Danışmanlığı. www.nitelik.

CMMI. CMMI ve Çevik Yöntemler. Orhan KALAYCI Haziran 2007. Yazılım Süreç Kalitesi ve Yönetim Danışmanlığı. www.nitelik. CMMI ve Çevik Yöntemler Orhan KALAYCI Haziran 2007 http:// CMMI 2 1 XP 3 CMMI nedir? 1. Seviye 2. Seviye 3. Seviye 4 2 XP Nedir? MSF XP Şelale RUP 5 CMM XP İlişkisi 6 3 PROJE YONETİMİNİ İMİNİN EVRİMSEL

Detaylı

YAZILIM MÜHENDİSLİĞİ Şubat 2012 Yrd.Doç.Dr. Yunus Emre SELÇUK GENEL BİLGİLER

YAZILIM MÜHENDİSLİĞİ Şubat 2012 Yrd.Doç.Dr. Yunus Emre SELÇUK GENEL BİLGİLER YAZILIM MÜHENDİSLİĞİ Şubat 2012 Yrd.Doç.Dr. Yunus Emre SELÇUK GENEL BİLGİLER BAŞARIM DEĞERLENDİRME Sınav tarihleri: Daha sonra duyurulacak 1. Ara sınav yazılı, 2. Ara sınav: test, Final sınavı: yazılı

Detaylı

140820001 Ferhat Cem CİHAN-Bilgisayar Mühendisliği 140820020 Emre BALCI-Bilgisayar Mühendisliği

140820001 Ferhat Cem CİHAN-Bilgisayar Mühendisliği 140820020 Emre BALCI-Bilgisayar Mühendisliği YAZILIM TASARIM DÖKÜMANI Yeşil Bina Otomasyonu 140820001 Ferhat Cem CİHAN-Bilgisayar Mühendisliği 140820020 Emre BALCI-Bilgisayar Mühendisliği İÇİNDEKİLER 1.Giriş 1.1 Amaç 1.2 Kapsam 1.3 Genel Bakış 2.Genel

Detaylı

Karaciğerde Oluşan Hastalıkların Tespitinde Makine Öğrenmesi Yöntemlerinin Kullanılması

Karaciğerde Oluşan Hastalıkların Tespitinde Makine Öğrenmesi Yöntemlerinin Kullanılması Karaciğerde Oluşan Hastalıkların Tespitinde Makine Öğrenmesi Yöntemlerinin Kullanılması 1 Emre DANDIL Bilecik Ş. Edebali Üniversitesi emre.dandil@bilecik.edu.tr +90228 214 1613 Sunum İçeriği Özet Giriş

Detaylı

Üst Düzey Programlama

Üst Düzey Programlama Üst Düzey Programlama Yazılımda Günlükleme (Logging) Üst Düzey Programlama-ders07/ 1 Günlükleme -Logging Tüm büyük çaplı uygulamalarda günlükleme(logging) ihtiyaçları bulunmaktadır. Bir uygulamanın hata

Detaylı

OSPF PROTOKOLÜNÜ KULLANAN ROUTER LARIN MALİYET BİLGİSİNİN BULANIK MANTIKLA BELİRLENMESİ

OSPF PROTOKOLÜNÜ KULLANAN ROUTER LARIN MALİYET BİLGİSİNİN BULANIK MANTIKLA BELİRLENMESİ OSPF PROTOKOLÜNÜ KULLANAN ROUTER LARIN MALİYET BİLGİSİNİN BULANIK MANTIKLA BELİRLENMESİ Resul KARA Elektronik ve Bilgisayar Eğitimi Bölümü Teknik Eğitim Fakültesi Abant İzzet Baysal Üniversitesi, 81100,

Detaylı

DGridSim Gerçek Zamanlı Veri Grid Simülatörü. Kullanıcı Rehberi Dokümanı v 1.0.0 21.12.2011. Safai Tandoğan Mustafa Atanak Doç. Dr.

DGridSim Gerçek Zamanlı Veri Grid Simülatörü. Kullanıcı Rehberi Dokümanı v 1.0.0 21.12.2011. Safai Tandoğan Mustafa Atanak Doç. Dr. DGridSim Gerçek Zamanlı Veri Grid Simülatörü Kullanıcı Rehberi Dokümanı v 1.0.0 21.12.2011 Safai Tandoğan Mustafa Atanak Doç. Dr. Atakan Doğan 1. Giriş Araştırmacılar, DGridSim simülatörünün görsel arayüzü

Detaylı

Cluster i Linux'ta Kümeleme Özgür Yazılım ve Açık Kaynak G 2006 Ali Erdinç Köroğlu

Cluster i Linux'ta Kümeleme Özgür Yazılım ve Açık Kaynak G 2006 Ali Erdinç Köroğlu Cluster i Linux'ta Kümeleme Özgür Yazılım ve Açık Kaynak G 2006 Ali Erdinç Köroğlu Kümelere giriş giriş :) :) Kümeleme nedir? Kümeleme çeşitleri ve ve amaçları RedHat Cluster'a giriş giriş RedHat Cluster

Detaylı

Algoritma ve Programlama: Karar Yapıları ve Döngüler

Algoritma ve Programlama: Karar Yapıları ve Döngüler Algoritma ve Programlama: Karar Yapıları ve Döngüler Bir algoritma, herhangi bir programlama dili (C, C++, Pascal, Visual Basic, Java gibi) ile kodlandığında program haline gelir. Algoritmada yer alan

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ı

Web Madenciliği (Web Mining)

Web Madenciliği (Web Mining) Web Madenciliği (Web Mining) Hazırlayan: M. Ali Akcayol Gazi Üniversitesi Bilgisayar Mühendisliği Bölümü Konular Denetimsiz Öğrenmenin Temelleri Kümeleme Uzaklık Fonksiyonları Öklid Uzaklığı Manhattan

Detaylı

COĞRAFİ BİLGİ SİSTEMLERİ SERVER MİMARİSİ SERVER UYGULAMA GELİŞTİRME EĞİTİMİ

COĞRAFİ BİLGİ SİSTEMLERİ SERVER MİMARİSİ SERVER UYGULAMA GELİŞTİRME EĞİTİMİ COĞRAFİ BİLGİ SİSTEMLERİ SERVER MİMARİSİ SERVER UYGULAMA GELİŞTİRME EĞİTİMİ http://facebook.com/esriturkey https://twitter.com/esriturkiye egitim@esriturkey.com.tr Kursun Süresi: 5 Gün 30 Saat COĞRAFİ

Detaylı

Solvency II, Sayısal Etki Çalışmaları ve Edinilen Deneyimler

Solvency II, Sayısal Etki Çalışmaları ve Edinilen Deneyimler Solvency II, Sayısal Etki Çalışmaları ve Edinilen Deneyimler M. Serhat Yücel, FRM Solvency II Teknik İhtisas Komitesi Yerel bilgi. Küresel Güç. 1 Gündem o o o o Solvency II ve Tarihçesi Sayısal Etki Çalışmaları

Detaylı

ÇİMENTO BASMA DAYANIMI TAHMİNİ İÇİN YAPAY SİNİR AĞI MODELİ

ÇİMENTO BASMA DAYANIMI TAHMİNİ İÇİN YAPAY SİNİR AĞI MODELİ ÇİMENTO BASMA DAYANIMI TAHMİNİ İÇİN YAPAY SİNİR AĞI MODELİ Ezgi Özkara a, Hatice Yanıkoğlu a, Mehmet Yüceer a, * a* İnönü Üniversitesi Mühendislik Fakültesi Kimya Mühendisliği Bölümü, Malatya, 44280 myuceer@inonu.edu.tr

Detaylı

TÜRKİYE İSTATİSTİK KURUMU VERİTABANI VE UYGULAMA ALANLARI

TÜRKİYE İSTATİSTİK KURUMU VERİTABANI VE UYGULAMA ALANLARI TÜRKİYE İSTATİSTİK KURUMU VERİTABANI VE UYGULAMA ALANLARI FEN BİLİMLERİ ENSTİTÜSÜ ENFORMATİK BÖLÜMÜ BATURALP BAŞKIR 2601130394 1 TÜRKİYE İSTATİSTİK KURUMU VERİTABANI VE UYGULAMA ALANLARI TARİHSEL GELİŞİM

Detaylı

www.smsmakinesi.com destek@hermesiletisim.net COM API v.1.1 BELGE SÜRÜMÜ : 1.1

www.smsmakinesi.com destek@hermesiletisim.net COM API v.1.1 BELGE SÜRÜMÜ : 1.1 destek@hermesiletisim.net COM API v.1.1 BELGE SÜRÜMÜ : 1.1 1 1. İÇİNDEKİLER 1. İçindekiler 2 2. Bu Belgenin Amacı 3 3. Kullanım Şekli.3 4. Uyarılar.4 5. Hata Kodları.4 6. Kullanıcı Bilgileri Kontrolü..5

Detaylı

MAK 210 SAYISAL ANALİZ

MAK 210 SAYISAL ANALİZ MAK 210 SAYISAL ANALİZ BÖLÜM 6- İSTATİSTİK VE REGRESYON ANALİZİ Doç. Dr. Ali Rıza YILDIZ 1 İSTATİSTİK VE REGRESYON ANALİZİ Bütün noktalardan geçen bir denklem bulmak yerine noktaları temsil eden, yani

Detaylı

Bilgisayarda Programlama. Temel Kavramlar

Bilgisayarda Programlama. Temel Kavramlar Bilgisayarda Programlama Temel Kavramlar KAVRAMLAR Programlama, yaşadığımız gerçek dünyadaki problemlere ilişkin çözümlerin bilgisayarın anlayabileceği bir biçime dönüştürülmesi / ifade edilmesidir. Bunu

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ı