Çarşamba, Haziran 18, 2014

Ülkelerine Göre Araç Markaları

Merhaba,
Almış/alacak olduğunuz aracın hangi marka olduğu merak ettiğiniz olmuştur. Bu merakı giderebilmek için alt kısımda yer alan ülkelere göre araç listesinden yararlanabilirsiniz.

ALMANYA Mercedes Benz – Bmw – Opel – Porsche – Volkswagen – Seat – Skoda – Maybach – Audi – Smart

AMERİKA Buick – Cadillac – Chevrolet – Chrysler – Dodge – Ford – GMC – Hummer – Jeep – Lincoln – Mercury – Pontiac – Saturn – Paige – Chalmers – Oldsmobile -
İTALYA Alfa Romeo – Fiat - Lamborghini – Ferrari – Lancia – Maserati -
FRANSA Renault – Citroen – Peugeot – Unic – Bugatti – Constantinesco
GÜNEY KORE Hyundai - Kia - Ssangyong - Daewoo
İNGİLTERE Aston Martin – Bentley – Jaguar - Land Rover – Lotus – Mini – Morgan - Rolls Royce – Rover - TVR – Austin – Swift – Sunbeam – Abc – Bean – Wolseley Siddeley – Morris – MG – Crossley -
İSVEÇ Volvo – Saab – Daf – Scania -
JAPONYA Daihatsu – Honda – Infiniti – Lexus – Mazda – Mitsubishi – Nissan – Scion – Subaru – Suzuki – Toyota
RUSYA Lada – Avtotor – AvtoVAZ – GAZ (KAvZ · LiAZ · UralAZ) – IzhMASh – Kamaz – Marussia – Moskvitch – NefAZ – PAZ – SeAZ - Sollers JSC (UAZ · ZMA) - TagAZ · ZiL
HİNDİSTAN TATA
TÜRKİYE Karsan - Tofaş - Otokar - Temsa

İyi günler...

Araç Segmenleri

Merhaba,
Araç araştırması yapan bütün herkes bu araç şu segmentte, şu araç bu segmentte gibi lafları işitmiştir. Bu segmentlerin hangi araçlara denk geldiği ve kısa tanımlarını alt kısımdan erişebilirsiniz.

Hangi araçlar hangi segmentte?
A segmenti: Basic, Mini, Minicar, Şehir arabası, Economy car, city car olarak da adlandırılırlar. Küçük araçlardır.
Örnekler: Renault Twingo, Peugeot 107, Smart Fortwo, Fiat Panda, Chevrolet Spark, Suzuki Alto


B segmenti: Small olarak da adlandırılırlar.
Örnekler: Hyundai Getz, Honda Jazz, Chevrolet Kalos, Fiat Punto, Dacia Logan, Seat Exeo, Hyundai Accent, Ford Fiesta, Fiat Albea, Fiat Palio, Nissan Micra, Peugeot 206, Smart Forfour, Toyota Yaris


C segmenti: Small family car, küçük aile arabası olarak da adlandırılırlar. Alt orta sınıf (lower medium) araçlardır.
Örnekler: Mitsubishi Lancer -Renault Fluence - Renault Megane - Hyundai i30 - Toyota Corolla - Ford Focus - Opel Astra - Honda Civic - Audi A3 - Fiat Bravo - Volkswagen Golf - Kia Cee'd - Peugeot 308 - Mazda 3 - Hyundai Elantra - Kia Cerato - Skoda Octavia - Dacia Logan - Toyota Auris - Proton Gen2


D segmenti: Large family car, büyük aile arabası olarak da adlandırılırlar. Üst orta sınıf (upper medium) araçlardır.
Örnekler: Opel Insignia - Volkswagen Passat - Opel Vectra - Alfa Romeo 156 - Renault Laguna - Ford Mondeo - Toyota Avensis - Honda Accord- Seat Exeo - Mazda 6 - Alfa Romeo 159 - Nissan Primera - Skoda Superb - Mercedes C-Serisi - BMW 3 Serisi


E segmenti: Executive car olarak da adlandırılan üst sınıf otomobillerdir.
Örnekler: BMW 5 serisi, Mercedes E sınıfı, Audi A6


F segmenti: Luxury, lüks sınıf otomobillerdir.
Örnekler: Audi A8, BMW 7 serisi, Mercedes S sınıfı


G segmenti: Sports car – Spor otomobillerdir.
Örnekler: Porsche 911


Otomobil segmentlerinden sonra kısaca diğer sınıflara da değinelim.
SUV: 4×4 araçların bulunduğu sınıftır. Sport utility vehicle – Spor kullanıma uygun araç anlamına gelir.
LCV: Light Commercial Vehicle – Hafif ticari araçlar
MCV: Medium Commercial Vehicle – Orta ticari araçları ifade eder.
HCV: Heavy Commercial Vehicle – Ağır ticari araçları, ağır kamyonları ifade eder.
BUS: Otobüsler

İyi günler...

Pazartesi, Nisan 28, 2014

Risc & Cisc

RISC:RISC işlemciler daha kısa ve daha basit komut setlerine sahip işlemcilerdir.Çalışma hızı cısc işemcilerden daha hızlıdır.CISC:CISC işlemciler daha fazla ve daha karmaşık komut setlerine sahiptir.Çalışma hızı rısc işlemcilere göre daha yavaştır.RISC işlemcilerde programın boyutu artar. Günümüz işlemcilerinde CISC işlemciler kullanılır.
Genelde karmaşık komutlu bilgisayarlarda CISC mimarisi kullanılır ve programların az bellek gerektirdiği sistemlerde tercih edilir.. ee az bellek içinde kompleks komutlar ve kompleks mimari gerekir.rısc de ise azaltılmış komut kümeli bilgisayarlarda tercih edilir ve komutların hızlı işlenmesi amacı vardır bu yüzden basit komutlar gerektirir.evet rısc daha hızlıdır.Transistör sayısı cısc de fazladır buda ısınma sorunun getirir.buna bağlı olarak CISC soğutma probleminden dolayı daha pahalıdır.buna rağmen Rısc Cısc'in güçlü komutlarından mahrumdur. bu yüzden daha fazla komut gerektirir.

Yıllar geçtikçe iki işlemci ailesi piyasaya hakim olmaya başladı: Intel Pentium ve Motorola PowerPC. Bu iki işlemci aynı zamanda uzun yıllar boyunca kullanılacak ve günümüze kadar değişmeyecek iki farklı mimariye sahiplerdi.CISC (Complex Instruction Set Computer), geleneksel bilgisayar mimarisidir. İşlemci kendi üzerinde bulunan microcode adlı minyatür bir yazılımı kullanarak komut setlerini çalıştırır. Bu sayede komut setleri değişik uzunluklarda olabilir ve bütün adresleme modellerini kullanabilirler. Bunun dezavantajı çalışmak için daha karmaşık bir devre tasarımına ihtiyaç duyulmasıdır.İşlemci üreticileri daha komlpleks (ve güçlü) işlemciler üretmek için sürekli daha büyük komut setleri kullandılar. 1974 yılında IBM'den John Cocke bir çipin daha az komutla çalışabilmesi gerektiğini düşündü ve ortaya sadece sınırlı sayıda komut setleri kullanabilen RISC (Reduced Instruction Set Computer) mimarisi çıktı. Bu mimaride komutların uzunluğu sabittir ve bu yüzden de direk olmayan adresleme modu kullanılamaz. Sadece tek bir saat döngüsünde veya daha az sürede çalıştırabilecek komutlar işleme konabilir. RISC işlemcilerin en büyük avantajları komutları çok çabuk işleyebilmeleridir çünkü bu mimaride komutlar çok basittir. Bu sayede RISC işlemcileri tasarlayıp üretmek daha ucuzdur, çünkü bu basit komutlar için daha az transistör ve daha basit devreler gerekir.

En Basit Haliyle Bir İşlemci
L1 Cache:İşlemci için önbellek. Önemli kodlar ve veriler bellekten buraya kopyalanır ve işlemci bunlara daha hızlı ulaşabilir. Kodlar için olan Code ve veriler için olan Data cache olmak üzere ikiye ayrılır. Güncel işlemcilerde L2 (Level 2, 2. seviye) önbellek de bulunur. Önceleri L2 önbellek anakartta bulunurdu. Daha sonra slot işlemciler ortaya çıktı ve işlemci çekirdeğinin de üzerinde bulunduğu kartuj şeklindeki paketlerde önbellek çekirdeğin dışında ama işlemciyle aynı yapıda kullanılmaya başlandı. Bu kısa geçiş döneminden sonraysa önbellek işlemci çekirdeklerine entegre edildi.

CISC ve RISC Tabanlı İşlemcilerin Karşılaştırılması Lightbulb CISC ve RISC Tabanlı İşlemcilerin Karşılaştırılması CISC ve RISC tabanlı işlemcilerin karşılaştırılmasında iki önemli faktör farklılıklarını ortaya çıkarmada yeterlidir. Hız: Genelde RISC çipleri kanal tekniği kullanarak eşit uzunlukta segmentlere bölünmüş komutları çalıştırmaktadır. Kanal tekniği komutları kademeli olarak işler ki bu RISC’ in bilgi işlemini CISC’ den daha hızlı yapmasını sağlar RISC işlemcisinde tüm komutlar 1 birim uzunlukta olup kanal tekniği ile işlenmektedir. Bu teknikte bazıları hariç komutlar, her bir basamağında aynı işlemin uygulandığı birimlerden geçerler. Kanal teknolojisini açıklamak için herhangi bir komutun işlenmesindeki adımlar ele alınırsa: Komut kodu ve işlenecek veriler dahil bütün bilgilerin MIB’ deki kaydedicilerde olduğu düşünülürse, birinci adımda yapılacak işin kaydedicide bulunan komut kodu çözülür, ikinci adımda üzerinde çalışılacak veri (işlenen) kaydediciden alınıp getirilir, üçüncü adımda veri, komuta göre Aritmetik ve Mantık Biriminde işleme tabii tutulur ve dördüncü adımda da sonuç kaydediciye yazılacaktır. Böylece bir komutun işlemesi için her bir basamak bir saat çevrimi gerektirirse, dört çevrimle (adımda) gerçekleşmiş olmakta ve bir adım bitmeden diğeri başlayamamaktadır. Kanal tekniği ile çalışan işlemcilerde birinci adımda komut kodu çözülür, ikinci adımda birinci komutun üzerinde çalışacağı veri (işlenen) kaydediciden alınırken, sıradaki ikinci işlenecek olan komutun kodu çözülür. Üçüncü adımda ilk komutun görevi ALU’da yerine getirilirken, ikinci komutun işleyeceği işlenen alınıp getirilir. Bu anda sıradaki üçüncü komutun kodu çözülür ve işlem böylece devam eder.Kanal (Pipeline) tekniğinde çevrim zamanın düşmesi için komut kodlarının hızlı çözülmesi gereklidir. RISC mimarisinde tüm komutlar 1 birim uzunlukta oldukları için komut kodunu çözme işlemi kolaylaşır. Sistemde kullanılan kaydedicilerin simetrik bir yapıda olması, derleme işlemini kolaylaştırmaktadır. RISC işlemcilerde belleğe yalnız yükle ve depola komutlarıyla ulaşılır.Bazı eski CISC mimarisinde de olmasına rağmen RISC mimarisinin sabit uzunluktaki basit komutlarla çalışması pipeline sistemini daha iyi kullanmasına sebep olmaktadır. Bu yüzden hesaplama oranlarının birinci öncelik arz ettiği yerlerde iş-istasyonları ve dağıtıcılarda çok tercih edilmektedir.Transıstör sayısı: CISC mimarisinde kullanılan transistor sayısı RISC’e nazaran daha fazladır. Transistör sayısının bir yerde çok olması fazla yerleşim alanı ve ayrıca fazla ısı demektir. Bundan dolayı da fazla ısı üretimi soğutma olayını gündeme getirmektedir. CISC tabanlı Pentium işlemcilerde karışık ısı dağıtıcısı veya soğutma fanlar kullanılmaktadır.RISC mimarisindeki önemli üstünlüklere karşı bazı mahzurları ortaya çıkmaktadır. RISC mimarisi, CISC’in güçlü komutlarından yoksundur ve aynı işlemi yapmak için daha fazla komut işlenmesini gerektirir. Bundan dolayı da RISC’in bant genişliği artar. Bu sistemde güçlü komutların yokluğu ikinci bir yardımcı işlemciyle ya da işlemci içinde oluşturulacak ayrı bir pipeline bölümüyle giderilebilir. Komut ön-belleğinin kullanılması yüksek komut alıp getirme işlemini azaltmaktadır. RISC mimarisi diğerine nazaran daha kompleks yazılımlara ihtiyaç duyar.Tablo 4: PowerPC ve Pentium mikroişlemcilerinin karşılaştırılmasıGünümüzde her iki mimarinin üstün özellikleri birleştirilerek bir çok yeni sistemler üretilmekte ve üretilecektir. IBM RISC/6000 ile Intel 860 ve 960 mimarileri bir makina çevrimin de birden fazla komut işleyerek son derece hızlı bir performans yakalamışlardır.

RISC İLE CISC MİMARİLERİNİN KARŞILAŞTIRILMASI

1-)Risc, load ve store komutu var Cisc de bunlara ilaveten komutlar var.
2-)Risc, komutlar sabit 32 bitliktir.Cisc’de komutların boyutu sabit değildir.
3-)Risc, kodlar basittir.Cisc’de karmaşıktır.
4-) Risc, program derlenince daha fazla makine kodu olacağından Cisc’ e göre daha fazla alan kapsar.
5-)Cisc, belleğin şu gözü ile bu gözünü topla şuraya yaz vardır.Risc’de yoktur.
6-)Risc, CPU’daki komut işleme daha hızlı oalcağından bu hızda çalışan CPU’ya hızlı RAM ve büyük önbelleklere ihtiyaç vardır.
--
Turhal Temizer

Pazar, Nisan 27, 2014

CMMI

Günümüzde, akla gelebilecek her türlü iş alanında yazılım konusunun iş yapış biçimine direk etkisi göze çarpmakta ve hatta herhangi bir yazılım kullanılmayan alanlarda iş yaşamının devam ettirilmesi pek mümkün görünmemektedir. Örneğin, bankacılık sektöründe işe uygun bir yazılım kullanmayan bir finans kurumunu düşünmek bile olası değildir. Sadece bankacılıkta değil telekomünikasyon, lojistik, perakende satış gibi hemen hemen her sektörde yazılım artık “olmazsa olmaz” bir bileşen haline gelmiştir. Sivil sektörlerde hal böyle iken savunma sektöründe de durum farklı değildir. Özellikle savunma sistemlerinde “yerli” yazılım üretilmesi son birkaç yıldır ülkemizin milli stratejisi olarak gündemde yerini korumaktadır. Elbette böylesine önemli bir strateji ve giderek artan yazılım ihtiyacı bu seviyedeki büyük projelerde ciddi bir süreç yönetimini zorunlu kılmaktadır. Aksi halde, karmaşık, büyük, entegrasyon içeren yazılım projelerinin başarıya ulaşması mümkün değildir. Bir yazılımın kalitesi ise, üretilen yazılımda az hata olması, kullanıcı/müşteri gereksinimlerinin tam olarak karşılanması, arızalar arasında geçen zamanın uzunluğu, arızaların giderilme hızı gibi kriterlerle ölçülmektedir.

Yazılım Kalitesi

Yazılım geliştirme dünyasında kalite bir ilkeler topluluğudur ve bu ilkeler iyi ve örnek uygulamalar ile meydana gelmiştir. İyi bir uygulamada sorunların erken teşhis edilmesi ve bu teşhislerin yerinde müdaheleler ile erken çözümlenmeleri yazılımın maliyetini düşürmekte en önemli unsurlardan biridir. Öte yandan, yazılım geliştirme yaşam döngüsünde ürün değil süreçler önemlidir ve bu süreçlerin sürekli iyileştirilmesi hedeflenmelidir. Standartlar belirlenmeli, sürekli ölçümler yapılarak sonuçlar değerlendirilmelidir.

Süreç, amacı bir iş yapış biçiminde standart oluşturmak, değişkenliği azaltmak ve bu şekilde iş yapış biçiminde iyileşme sağlamak olan bir iş yapma yöntemidir. Genellikle bazı alt süreç ve aktivitelerden oluşur. Süreçler mutlaka yazılı hale getirilip belgelenmişlerdir ve tekrarlı işlemlerdir. Her sürecim mutlaka girdi(ler)i ve çıktı(lar)ı vardır.

Söz konusu yazılım geliştirme faaliyetlerinin bir kalite sistemine sahip olması gerekliliği yıllar önce ortaya çıkmış ve bu amaçla ISO 9001 ile başlayan süreç ISO/IEC 12207, ISO/IEC 15504 (SPICE) gibi modellerle ilerlemiştir. Günümüzde ise, tüm bu modellerin yanında Carnegie Mellon Üniversitesi bünyesinde faaliyet gösteren Yazılım Mühendisliği Enstitüsü’nün (Software Engineering Institute - SEI) ortaya koyduğu CMMI (Capability Maturity Model Integration ) genel kabul görmüş durumdadır.

CMMI Nedir ?

1989 yılında Carnegie Mellon Üniversitesi’nin ABD Savunma Bakanlığı sponsorluğundaki Yazılım Mühendisliği Enstitüsü (SEI) "Capability Maturity Model - CMM" olarak adlandırılan modeli geliştirmiştir. Bu model, etkin bir yazılım sürecinin anahtar elemanlarını tanımlayan çerçeve modeldir. CMM, olgun olmayan bir süreçten olgun ve disiplinli bir sürece giden bir yol çizer. Temel prensipler olarak yeteneğin olgunluğa bağlı olduğunu ve olgunluğun da zamanla gelişerek ölçülebileceğini belirtir. CMM, temel olarak, yazılım geliştirme süreçlerinin ne kadar olgun olduğunu değerlendiren ve aynı işi yapan diğer organizasyonlarla karşılaştırma yapablmeyi sağlayan bir araçtır. CMM içerisinde, 5 olgunluk düzeyi tanımlanmış ve yazılım geliştirme faaliyetlerine yöenlik olarak 17 anahtar süreç alanı belirlenmiştir.

İlerleyen yıllarda SEI, yazılımın yanında farklı alanlar için bir takım küçük farklılıklarla ayrı birer CMM modeli tanımlamıştır. Bunlar :

•Yazılım mühendisliği

•Tümleşik ürün geliştirme

•Sistem mühendisliği

•Tedarik süreçleri olarak belirlenmiştir.

CMMI modelinin bir amacı adındaki I (Integration) eklentisine uygun olarak bunların entegre edilmesidir.

CMMI, organizasyonların sonuç olarak performanslarını arttırmaya neden olacak etkili bir süreç iyileştirme yaklaşımıdır. CMMI, süreç iyileştirme bağlamında bir projede, bir bölümde ya da bir organizasyonunun tümünde uygulanabilir. Genel olarak CMMI, kurumların geleneksel olarak ayrı ayrı olan organizasyonel fonksiyonlarının entegre edilmesine, süreç iyileştirme çalışmalarının amaç ve önceliklerinin belirlenmesine, kalite süreçlerine rehberlik edilmesine ve mevcut süreçlerin değerlendirilmesine yönelik bir referans yaratma konularında yardımcı olur. CMMI, ne yapılması gerektiğini açıklar ancak bu gerekliliklerin nasıl yapılacağı sorusuna kesin bir cevap vermez.

CMMI yaklaşımı, dünyada ve Türkiye’de genellike IT sektöründe ve özellikle yazılım geliştirme konularında referans model olarak uygulanmaktadır. Donanım ve network alanlarında da uygulanan model, özellikle savunma sanayi başta olmak üzere; Ar-Ge ve yeni ürün geliştirme konusunda hizmet veren kurumların aradıkları bir standarttır. Ülkemizde artık pek çok yazılım projelerinde tedarik makamları firmalardan CMMI konusunda en az 3. Seviye sertifikasyon talep etmektedirler. Peki nedir bu seviyeler ?

CMMI Seviyeleri

CMMI Seviye 1 : Initial (Baslangıç)

Yazılım geliştirme süreci gelişi güzel yapılmaktadır ve genel olarak kaotik bir durum söz konusudur. Bu seviyede başarı kişisel çabalar ile oluşmaktadır. Herhangi bir kriz durumunda – varsa – planlar göz ardı edilir. Yazılım konusundaki yetenekler ise önceden öngörülemez.

CMMI Seviye 2 : Repeatable( Tekrarlanabilen)

Genellikle proje yönetimi konusundaki kontrol noktaları belirlenmiştir ve projeler önceden dokümante edilmiş olan proje planlarına göre yürütülmekte ve yönetilmektedir. Yazılım gereksinimleri bir şekilde yönetilir, bu gereksinimler ile ilintili ürünler oluşturulur. Bu ürünler ile ilgili denetim de mevcuttur. Proje yönetim sistemi vardır ve bu sistem proje geliştirme sürecini etkin bir şekilde kontrol eder. Projeler planlıdır, başarılmıştır, ölçülmüş ve kontrol edilmiştir. Yazılım gereksinimleri, ilgili süreçler, süreçlerin çıktıları ve hizmetler yönetilmektedir. Durum tanımlandığı kadarı ile yönetimin görüşüne açıktır.

Taahhütler,söz konusu projedeki tüm paydaşların talep ve değişiklik isterlerine uygun bir şekilde verilmiştir.

CMMI Seviye 3 : Defined (Tanımlı)

Artık süreçler iyi tanınlanmış ve anlaşılmıştır. Tüm süreçler standartlar, prosedürler, araçlar ve metodlar ile açıklanmış ve anlatılmıştır. Standart süreç tanımları organizasyonel boyutta tutarlıdır.

Projeler, tanımlı standart süreçleri uyarlama rehberlerine uygun olarak kendilerine uyarlayarak (Tailoring) kendi süreçlerini oluşturur. Yani, tüm projelerde standart yazılım geliştirme süreçlerinin uyarlanmıs hali kullanılır. Bu seviyede, süreçler II. seviyeye göre daha özenli ve detaylı olarak tanımlanmıştır.

CMMI Seviye 4 : Managed (Yönetilen)

Bu seviede sürecin başarılı olup olmadığıni belirlemek için önem arz eden alt süreçler belirlenir ve bu alt süreçler istatistiksel ve diğer nicel ölçüm teknikleri ile kontrol edilir. Kalite ve süreç performansının nicel hedefleri belirlenir ve bunlar süreçlerin yönetiminde bir kriter olarak kullanılır. Nicel hedefler, tedarik makamlarının ihtiyaç ve istekleri, son kullanıcılar, organizasyon ve bu süreçleri geliştirenler temel alınarak belirlenir.

Süreçler ölçülür ve ölçülebilen sınırlar içerisinde gerçekleştirilecek aktiviteler gerçek veriler baz alınarak tahmin edilebilir.

3.seviye ile temel bir faklılık vardır. Bu da, süreç performansının öngörülebilir olmasıdır. Bu sevide, süreç performansları istatistiksel ve diğer nicel teknikler ile kontrol edilebilir ve nicel olarak öngörülebilir iken 3.seviyede süreçler sadece kalitatif olarak öngörülebilir.

Seviye 5 : Optimizing (İyileştirilen)

Bu seviyede, süreçten gelen sayısal geri beslemeler ve teknolojilerden yararlanılarak sürekli iyileştirilme yapılır. Tüm organizasyon süreç iyileştirmeye odaklanmıştır. Yazılım geliştirme süreç yeteneği “Sürekli İyileşen” olarak tanımlanabilir

Bu seviye ile 4.seviye arasındaki en önemli ayrım, adreslenen süreçlerin değişme derecesidir. 4.seviyede süreçler, süreç değişkenliğinin özel nedenleri ve sonuçların istatistiksel öngörüsüne odaklanmışken, 5.seviyede süreçler, süreç değişkenliğinin genel nedenleri ve sürecin değişimini (süreç başarımından istatistiksel öngörüye) adreslemekle ilgilenir.

CMMI Kullanım Alanları

CMMI üç değişik alanda kullanılabilir :

•Ürün ve hizmet geliştirme (CMMI Geliştirme Modeli )

•Hizmet kurulumu, yönetimi ve dağıtımı (CMMI Hizmetler Modeli)

•Ürün ve Hizmet Satınalma (CMMI Satınalma Modeli)

Organizasyondan organizasyona değişebilir olmakla birlikte, aşağıdaki adımlar CMMI-tabanlı bir süreç iyileştirme işlemini tanımlar;

•Kefalet (Sahiplenme ve Kaynak Sağlama)

Süreç iyileştirmeye başmadan önce ilk yapılması gereken şey üst yönetimin bu konuyu sahiplenmesini ve kaynak sağlamasını sağlamaktır. Bu sahiplenme süreç iyileştirme sürecinin başarılı olabilmesi açısından kritik önem arz etmektedir.

•Temel Eğitimin Alınmasının Sağlanması

CMMI yaklaşımının temel konseptinin anlaşılabilmesi için mutlaka uygun bir CMMI Giriş eğitiminin alınması gereklidir.

•Organizasyonun Değişime Hazırlanması

Süreç iyileştirme bir proje olarak ele alınmalıdır. Bu çabalar için iş ile ilintili sebepler ve hedefler belirlenmelidir. Bu amaçla, değişimin kazanınları ve maliyetlerini de içeren zorlayıcı bir gerekçe yaratılmalıdır. Söz konusu değişim için sorunları ve fırsatları anlatan bir sunum çok faydalı olacaktır.

Süreç Tanımlama/İyileştirme Grubunun Oluşturulması

Bu grup tüm süreç iyileştirme aktivitileri boyunca yaşayacak olan ve kurum içerisinde süreç iyileştirme aktivitelerini koordine edecek olan gruptur. Bu grubun üyeleri süreç iyileştirme rehberleri olarak görev yapacaklardır. Elbette bu üyeler süreç iyileştirme konusunda yeni kişiler ise bunların “yazılım Süreç Tanımlama” veya “Süreç İyileştirme Hakimiyeti” gibi konularda eğitime tabii tutulması zorunludur.

•Durum Tespiti

Öncelikle CMMI en iyi örnekleri kurumsal süreçlerle karşılaştırılmalı ve gayriresmi bir ayrım çözümlemesi ( Gap Analysis) yapılmalıdır. Bunun konuda, özellikle kültürel fırsatlar ve engelleri tanımlayabilmek adına veri toplamak için yöneticiler, proje liderleri ve çalışanlar arasında bir araştırma yapmak gerekir. Bunun sonucunda mevcut durum belirlenir.

•Hedefin Tespiti

Tıpkı bir önceki adımdaki mevcut durumu belirleme gibi bu adımda da nerede olunmak istendiği belirlenir. Bu aşamada her bir seviyenin hedefleri farklı olabileceğinden yöneticiler, proje liderleri ve çalışanların olmak istedikleri yer hedefi konusunda bir denge sağlamak çok önemlidir. Bu belirlendikten sonra süreçler arasında öncelik belirlenir ve iyileştirme planı hazırlanır. Yapılan çalışmalar bu plan çerçevesinde izlenir.

•İletişimin Sağlanması ve Koordinasyon

Tüm bu süreçler boyunca dürüst ve iletişime açık olunmalıdır. Planın o plandan etkilenecek herkes ile paylaşılması ve gelebilecek geri bildirimlerin dikkate alınması esastır.

•İlerlemenin İzlenmesi

Sürekli bulunulan yer ile olmak istenilen yer karşılaştırılmalıdır. Aradaki fark süreç iyileştirme çalışmalarının odaklanılması gereken kısımlarıdır. Periyodik ( Aylık, haftalık ) raporlama programların hedeflerine ulaşma yolundaki gelişmelerini anlatmak açisından çok önemli araçlardır. Bunun dışında profesyonel değerlendiriciler tarafından yapılacak değerlendirmeler de ( Appraisal ) tarafsız bir göz olarak bu konuda önemli bilgiler sağlayacaktır.

Yazılım Geliştirme Süreçleri

Yazılım geliştirme ile uğraşan her kurum kendi kurum kültürü ve iş yapış biçimine uygun olarak süreçlerini tanımlamalıdır. Bunun ilk adımı da politika ve yönergelerini tanımlayıp dokümante edilmesidir. Genel olarak, yazılım geliştirme süreçleri aşağıdaki başlıklar halinde düşünülebilir :

a) Mühendislik

Mühendislik süreçleri bir çok alt süreçden meydana gelir.

•Gereksinim Geliştirme Süreci

Bu süreç kapsamında, müşteri ve ürün gereksinimleri geliştirilir, paydaşların ihtiyaçları toplanır. Müşteri gereksinimleri geliştirilir, ürün ve ürün bileşenleri oluşturulur. Ürün bileşenlerinin yazılım mimarisi içerisindeki yerleri ve gereksinimlerin arayüzleri belirlenir. Gereksinimler analiz edilir ve onaylanır. Operasyonel içerik ve senaryolar oluşturulur ve i şlevsellik ortaya çıkartılır. Paydaşların ihtiyaçlarıyla, maliyet, zaman planı, performans, işlevsellik, tekrar kullanılabilir bileşenler, güncellenebilirlik ya da riskler adreslenerek denge kurulur. Gereksinimler doğrulanır ve onaylanır.

Süreç sonunda, sistem gereksinimleri, yazılım gereksinimleri ve müşteri gereksinimleri dokümanları üretilir.

•Teknik Çözüm Süreci

Teknik Çözüm sürecinin amacı, gereksinimlere çözüm oluşturacak tasarım, geliştirme ve uyarlamaların yapılmasıdır.

Bu sürecin uygulanması ile alternatif çözümler oluşturulur ve değerlendirilir. Seçilmiş çözümlere göre detaylı tasarım yapılır. Oluşturulan tasarım, ürün ve ürün bileşeni olarak uyarlanır.

Bu süreç sonunda, üst düzey yazılım tasarımı, detaylı yazılım tasarımı, sistem tasarımı, kullanıcı arayüz tasarımı, veritabanı tasarımı, veri aktarma tasarımı, test planı ve test senaryoları üretilerek dokümante edilir.

•Onaylama Süreci

Bu sürecin amacı, kapsamda belirtilen iş/yazılım ürünlerinin, müşteri isterlerinin tamamını karşıladığını ve amacına uygun olduğunu gözden geçirip onaylayarak güvence altına almaktır. Bu süreçde, proje yönetimi tarafından belirlenen proje paydaşları yapılan planlara uygun olarak gözden geçirmeleri yapar ve düzeltici faaliyetleri planlar. Yapılan her toplantı tutanak ile konfigürasyon yönetimi altına alınır.

•Doğrulama Süreci

Bu sürecin amacı, iş/yazılım ürünlerinin doğruluğunu, tutarlılığını, izlenebilirliğini, süreç girdilerine uygunluğunu gözden geçirerek kalitesini güvence altına almaktır. Sürecin sonunda, proje ile ilintili tüm planlar, gereksinim kayıtları, taasarımlar, test senaryoları gibi yüm unsurların doğrulama kayıtları üretilir.

•Gereksinim Yönetim Süreci

Bu sürecin amacı, projenin ürünleri ve ürün bileşenlerinin gereksinimlerini yönetmek ve gereksinimler ile iş ürünleri ve proje planı arasındaki tutarsızlıkları ortaya koymaktır. Bu sürecin uygulanması ile:

◦Gereksinim kaynakları üzerinde gereksinimler ve önemi hakkında fikir oluşturulması sağlanır, paydaşlarda farkındalık yaratılır,

◦Proje katılımcılarından gereksinimlerin onayının alınması sağlanır,

◦Gereksinimlere ait tüm değişiklikler yönetilir,

◦Gereksinimlerin, proje planı ve iş ürünleri ile izlenebilirliği güncel tutulur,

◦Gereksinimlerin, proje planı ve iş ürünleri arasındaki tutarsızlıklar belirlenir.

Düzeltici etkilikler planlanır ve yürütülür

b) Proje Yönetimi Süreci

Proje yönetimi süreci, projenin yönetimi, izlenmesi ve kontrol edilmesi faaliyetlerini kapsadığı gibi risk yönetimi ve alt yüklenici yönetimi de yine proje yönetiminin bir parçasıdır.

•Proje Yönetimi, İzleme ve Kontrol Süreci

Proje Yönetiminin amacı, bir ürün veya hizmeti üretmek amacıyla bir projenin planlanması, koordinasyonu ve yönetimidir. Bu süreçte kaynaklar tanımlanır, proje aktiviteleri planlanır, proje maliyet hesapları yapılır, hedefler ve sapmalar sürekli izlenir. Bir sapma durumunda düzeltici etkinlikler devreye alınır. Bu sürecin çeşitli aşamalarında proje planı, proje beratı, proje özet raporları, proje değişiklik isterleri gibi yönetimsel dokümanlar üretilerek proje paydaşları ile paylaşılır.

•Risk Yönetim Süreci

Risk Yönetim sürecinin amacı, ürünün veya projenin yaşamı süresince hedeflerine ulaşmasında ki olumsuz etkileri hafifletebilmek için, gerekli olan risk önleme aktivitelerinin belirlenip planlanabilmesi için potansiyel problemlerin oluşmadan önce tanımlanmasıdır. Süreç, risklerin tanımlanmasını, önceliklendirilmesini, risk azaltma tekniklerini, beklenmedik durum planlarının oluşturulmasını, riskleri ölçümleyebilmek için parametrelerin tanımlanmasını, gerektiğinde beklenmedik durum planlarının uygulanmasını kapsar. Risk Yönetimi süreci, idari ve teknik süreçlerin önemli bir parçası olup, sürekli yaşayan ve ileriye bakan bir süreçtir. Aralıksız risk yönetimi yaklaşımı, projenin üzerinde kritik etkisi olacak risklerin önceden tahmin edilebilmesi ve etkilerinin hafifletilebilmesi için etkin olarak kullanılır. Risk kataloğu ve risk planı bu sürecin çıktı iş ürünleridir.

•Alt Yüklenici Yönetimi Süreci

Tedarik edilen ürün/hizmetin yönetimi ve kabulü sürecinin amacı, tedarik seçim kriterleri kapsamı içinde belirlenen ve sözleşme ile imza altına alınan müşteri isterlerinin Alt Yüklenici firma tarafından sağlanmasının takibi, değerlendirilmesi ve bu sürecin sonunda kabul edilmesidir. Bu sürecin uygulanması ile, Alt Yüklenicinin üretim ve geliştirme süreci kontrol altında tutulur, Alt Yüklenici firma tarafından karşılanan ürün/hizmet müşteri isterlerine göre haftalık ve aylık olarak değerlendirilir, iİş sonunda, Alt Yüklenici firma ile yapılan sözleşmede belirtilen şartların sağlanması ile Alt Yüklenicinin ürün veya hizmetleri kabul edilir. Alt Yüklenici sözleşmeleri, değerlendirme kayıtları, konfigürasyon birimleri değerlendirme kayıtları v.b.dokümanlar bu sürecin çıktılarıdır.

c) Destek Süreci

Destek süreci, konfigürasyon yönetimi, karar analizi ve çözüm süreci, ölçümleme ve analiz, kalite güvence süreci gibi alt süreçlerden oluşur.

•Konfigürasyon Yönetim Süreci

Konfigürasyon Yönetimi Sürecinin amacı, yaşam döngüsü içerisinde üretilen tüm yazılım ve/veya iş ürünlerinde yapılacak değişiklikler ve İşletim hizmet sözleşmesi kapsamında ve kurum tarafından sağlanan sürekli hizmet içinde yer alan birimler üzerinde yapılacak değişikliklerin kontrol ve yönetimini sağlamaktır. Bu süreci uygulanması ile, bir proje esnasında üretilecek tüm yazılım, donanım, altyapı, lisanslar, sözleşmeler ve iş ürünleri birimleri belirlenir ve tanımlanır, söz konusu birimlerde yapılacak değişiklikler ve müşteri sürümleri (release) kontrol edilir, birimlerin durumları ve değişiklik istekleri kaydedilir ve raporlanır, birimlerin tamamlanmış olması ve tutarlılığı garanti altına alınır ve birimlerin saklanması kontrol edilir.

Konfigürasyon planı, konfigürasyon birimleri, değişiklik istekleri, etki analiz raporu bu sürecin çalışması ile üretilebilecek dokümanlardır.

•Karar Analiz ve Çözüm Süreci

Karar Analizi ve Çözüm Sürecinin amacı, olası çözüm kararlarını, konulmuş olan kriterlere göre biçimsel değerlendirme yöntemlerini kullanarak analiz etmek ve karar vermektir. Bu süreç ile alternatif çözümler belirlenir ve dokümante edilir.

•Ölçümleme ve Analiz Süreci

Bu sürecin amacı; yönetime, proje gidişatının anlaşılabilirliğini desteklemek için proje ilerleyişiyle ilgili gerçekleşen verileri sağlamaktır.

Ölçme planı bu süreçde hazırlanır, ve güncellenen metrik izleme dokümanı ile desteklenir.

•Kalite Güvence Süreci

Kalite Güvence Sürecinin amacı, Yazılım Geliştirme Grubunda yürütülen tüm etkinliklerin Yazılım Geliştirme Grubu Kalite Sistemine uyumunu, Proje Planında belirtilen aşamalarda denetleyerek kalitesini güvence altına almaktır. Bu sürecin uygulanması ile, proje planının kurumun yazılım geliştirme standartlarına uygun hazırlanması, projenin ilerlemesi esnasında, tanımlı iş/yazılım ürünlerinin üretilmesi, iş/yazılım ürünlerinin kurumun kalite sistemi standartları ve kriterlerine uyumu sağlanmış olur. Bu süreç boyunca yapılan kalite güvence denetlemeleri sonucunda Kalite Güvence Denetleme katıtları dokümanı oluşturulur.

c) Süreç Yönetim Süreci

Yukarıda söz edilen yazılım geliştirme süreçleri sürekli yaşayan ve iyileştirilen süreçler olmak zorundadırlar. Dolayısı ile, kurumsal anlamda bir süreç yönetim mekanizması kurulması zorunludur. Süreç yönetimi, kurumsal süreç tanımlama, organizasyonel eğitim, kurumsal süreç iyileştirme süreçleri şeklinde organize edilebilir.

•Kurumsal Süreç Tanımlama Süreci

Kurumsal süreç tanımlama sürecinin amacı, kurumun iş süreçlerinin tutarlı, tekrarlanabilir, performansını destekleyecek süreç kütüphanesini oluşturmaktır.Bu süreç için, süreç tanımlama formu, süreç iş çıktıları hazırlama formu gibi şablonlar tanımlanmalıdır.

•Organizasyonel Eğitim

Organizasyonel Eğitim sürecinin amacı; çalışanların , kendilerine verilen rolleri verimli ve etkin bir şekilde gerçekleştirmeleri için; bilgi ve beceri düzeylerinin geliştirilmesinin sağlanmasıdır. Bu sürecin sonuçlarının ölçülebilmesi için eğitim kayıt listesi, eğitim sonuçları değerlendirme formu vb. şablonlar tanımlanmalıdır.

•Kurumsal Süreç İyileştirme Süreci

Kurumsal Süreç İyileştirme sürecinin amacı; organizasyon süreçleri ve süreç varlıkları ile ilgili kuvvetli ve zayıf alanlar baz alınarak; organizasyon süreç iyileştirme aktivitelerinin planlanması ve uygulanmasıdır.

Danışmanlık alınabilecek firmalar:

Sertifika Sahibi Kurumlar için:

https://sas.cmmiinstitute.com/pars/pars.aspx

--

Turhal Temizer

Cumartesi, Nisan 26, 2014

TS ISO/IEC 15504 - SPICE (SOFTWARE PROCESS IMPROVEMENT AND CAPABILITY DETERMINATION) - SPICE (ISO 15504)


Software Process Improvement and Capability dEtermination : Yazılım Süreci  İyileştirme ve Yetenek Belirleme’dir. 1995 yılında ISO ve IEC tarafından çıkarılmıştır. Yazılım geliştirme projelerinin yönetim tarafı çoğunlukla yetersiz planlama, geliştirme süreçlerin tam anlaşılmaması, iyi bir yönetim çerçevesinin olmayışı gibi problemlerle karşı karşıyadır. Bu çerçevede daha disiplinli geliştirme süreçleri için standartlar geliştirilmeye başlanmıştır. Spice da bu standartlardan biri olup,  yazılım süreçlerini iyileştirmek ve süreç yeteneklerini belirler. Uluslararası Standartlar Örgütü  ve Uluslararası Elektroteknik Komisyonu’nun ortak çalışması ile 1995 yılında çıkarılmıştır. SPICE, iki boyutlu bir model olup içe dönük süreç iyileştirme ile içe ve dışa dönük yetenek belirleme amacını taşır. Birinci boyutta süreçler, ikinci boyutta yetenek düzeyleri vardır.

SPİCE İLKELERİ

  • Standartlaşma
  • Değerlendirme, yetenek belirleme ve iyileştirme
  • Diğer modellere uyum sağlama
  • Gelişmeyi ölçme
  • Nesnel, tutarlı ve tekrarlanabilir olma
  • Sertifikasyon amacı taşımaz

SPİCE BOYUTLARI

Spice 2 boyuttan oluşmaktadır. Bunlar süreç boyutu ve yetenek seviyeleridir.

a) Birinci Boyut: Süreç Boyutu

Süreç boyutunun kıstasları aşağıdaki gibidir.

  • Süreç bir işi yapma yöntemidir.
  • Genellikle alt süreç ve işlemlerden oluşur.
  • Belgelenmiş ve tekrarlıdır.
  • Girdi ve çıktıları vardır.

Süreç boyutları 5’e ayrılmaktadır. Bunlar:

  1. Müşteri-tedarikçiye direkt etkisi olan süreçler (Customer)
  2. Mühendislik süreçleri (Engineering)
  3. Projeyi oluşturan ve yöneten süreçler (yönetim) (Management)
  4. Destek süreçleri (Support)
  5. Organizasyon süreçleri (Oganization)

b) İkinci Boyut: Yetenek Seviyeleri

Süreçlerin alt süreçlerinin olduğunu daha önce söylemiştik. Örnek vermek gerekirse, mühendislik süreçlerinin “yazılım gereksinim analizi”, “yazılım tasarımı” , “yazılım gerçekleştirme”,  “yazılım testi“ gibi alt süreçleri bulunmaktadır.

clip_image001

Süreç nitelikleri, süreç yeteneğinin ölçümünü veren ve bir başarı skalasında değerlendirilebilen özelliklerdir. Her süreç niteliği, sürecin amacına ulaşması için, o sürecin etkinliğini iyileştirme ve yönetme yeteneğinin bir yönünü tanımlar

1. Seviyede incelenen süreç alanları için temel pratiklerin yerine getirilmesi ve ürünlerin özellikleri ile birlikte beklenen maddelerin sağlanması beklenir.

2. ve daha yüksek seviyelerde ise çizelgede yer alan süreç özelliklerini sağlaması gerekmektedir.

Her yeni özellik, yükselen yetenek düzeyini gösterir. Süreç Yeteneği Düzeyi başarılan niteliklerle(özellikler) belirlenir.

4. Seviyede, ilgili iş hedeflerine ulaşılmasını destekleyen ürün, süreç hedefleri ve ölçümler tanımlanır. Belirli ürün ve süreç ölçümleri toplanır.

  • Sürecin performans eğilimleri analiz edilir.
  • Analiz için gerekli uygun ölçüm teknikleri tanımlanır.

5. Seviye, sürecin ölçülebilir temeli üzerine dayanarak standart süreç tanımı için değişiklikleri tanımlar.

  • Gerçek ve potansiyel problemlerin kaynağı analiz edilerek sürekli iyileşen süreç tanımlanır.

DEĞERLENDİRME SÜRECİ

Denetçi verileri değişik şekillerde toplayabilir mesela; kişisel performans röportajları, kalite kayıtları ve belgeleri, istatistiksel süreç verileri toplama. Değerlendirme raporunun tamamını yapacak şekilde doğruluyor. Doğrulamış olduğu veriyi temel işlemlerle değerlendiriyor. Bu değerlendirme sonucunda süreç yeteneğini belirliyor. Süreç yeteneği değerlendirmesi değerlendiriciden uzman muhakeme yeteneğine sahip olmasını bekler. Bu da değerlendirmenin kalitesini değerlendiricinin kalitesi belirlediğini gösteriyor.

Değerlendirici kalitesi 4 maddeden etkilenir. Bunlar şunlardır:

  • İletişim kabiliyeti
  • Genel tecrübe ve ilgili eğitim seviyesi
  • Yönetimdeki alanındaki özel yetenekleri
  • ISO standartlarındaki süreç yeteneği değerlendirmesi tecrübesi ve pratikleri

a) Değerlendirme Modeli: PAM bizim değerlendirme için kullandığımız modeldir. Sürecin hayat döngüsü standartlarını sağlayan bir referans model genelde örnek alınır. Model spice kriterlerini sağlayan başka bir model de kullanılabilir.

b) Değerlendirmede kullanılan araçlar: Çeşitli değerlendirme araçları kullanılabilir örneğin; Elle kullanılan yazılı belgeler, değerlendirme modeli göstergelerini birleştiren bir araç, temel pratik göstergeleri, genel pratik göstergeleri bunların sonucunda değerlendirme sonucu yazıyor. Bu değerlendirme göstergelerini gösterecek bilgisayar tabanlı araçlar az sayıdadır. Bu araçlara değerlendirme raporları not ediliyor ya da otomatik olarak bu araçlar değerlendirme sonuçlarını topluyor.

ÖRNEK DEĞERLENDİRME SONUCU

clip_image002

Yukarıdaki sonucu incelersek, firmanın tedarikçi seçimi, yazılım entegrasyonu, konfigürasyon yönetimi gibi konularda kendisinin geliştirmesi gerekmektedir.

Başvuru için Gerekli Olan Linkler ve Önemli Bilgiler

Ücretlendirme

Bilgi Teknolojileri Sektörü Belgelendirme Hizmetlerine Başvuru ve Ücret Yönergesi

Danışmanlık Alınabilecek Firmalar

İlgili Sertifikaya sahip kurumlar için;

http://bilisim.tse.org.tr/-b-standardlar-b-/spice/-b-belgelendi-ri-len-kurulu%C5%9Flar-b-

Umarım yararlı olmuştur.

--

Turhal Temizer

Pazar, Nisan 20, 2014

Çoklu Dil Desteği – Veri Tabanı Tasarım Örnekleri ile

Zaman içerisinde karşımıza çok farklı projeler gelebilmektedir. Ancak bu projeler içerisinde özellikle de global ölçekli ya da bu ölçekte uygulama geliştiren firmalarda bazı temel gereksinimler sürekli olarak karşımıza çıkabilmektedir. Bu gereksinimlerden biri ve belki de en önemlisi olan çoklu dil desteğinin veri tabanı (DB) katmanında nasıl yapıldığını kısa ve hızlıca inceliyor olacağız.

Öncelikle çoklu dil desteği dediğimizde aklımıza gelen ilk çözüm yolu *.resx dosyalarını kullanmak gelmektedir. Ancak bu uzaktan yönetilen ya da anlık olarak metin değişikliği gereksinimi bulunan uygulamalarda bazı ufak problemler çıkartabilmektedir.

Ne gibi problemler derseniz; iki grupta inceleyebiliriz. Web projeleri ve windows üzerinde çalışan projeler.

Web projelerinde IIS üzerinde yer alan bir *.resx dosyasını değiştirdiğinizde son kullanıcı tarafında etkisi hemen görülmeyebilir. Cache mekanizmaları sebebiyle ortalama 15-30 dakika arasında bir görüntüleme süre farkı ile karşılaşabiliriz. Faha kötü felaket senaryosunda ise uygulama asp.net ve diğer web uygulamalarının klasiği olan sarı sayfa ile kaşılaşılabilir.

Windows projelerinde durum biraz daha vahimdir. *.resx dosyasını değiştirdiğinizde uygulamanızın yeni sürümünü çıkartmanız gerekmektedir. Sonra ki süreçtede bu kelime, cümle ya da paragraf değişikliklerinin neden bu kadar fazla olduğunun ve düzeltilmesi için neler yapılması gerektiğinin araştırmaları yapılır durur. Çözüm yolu olarak web servis üzerinden *.resx dosyasını paylaşabilirsiniz.

Ancak bu durumlarda genellikle dil ile ilgili işlemler veri tabanında tutulurken geri dönüş değerleri web servis üzerinde uygulamalar ile konuşturulur ve çözüm yoluna gidilir.

O zaman veri tabanında bu işlemi nasıl yapabileceğimizi hızlıca incelemeye başlayalım.

Yöntem 1 – Kolon ekleme yöntemi ile ( Popülerlik :) )

Anti-pattern kavramlarını üstün körü incelediyseniz gözünüze çok basit bir detay çarpmıştır. En popüler yöntem en doğru yöntem değildir. Bu fikri referans göstererek en fazla kullanılan çoklu dil desteğinin uygulama şeması aşağıdaki gibi oluşturulur.

CREATE TABLE app_product (
  Id Int IDENTITY NOT NULL,
  Description_tr Text, 

  Description_en Text,
  Description_fr Text,

  -- …..
  PRIMARY KEY (Id)
);

Avantajları

+basitlik

+veri tabanı sorgularındaki kolaylık (join yazılmasına gerek yok)

Dezavantajları

+Yeni bir dil eklendiğinde şema üziernde ki değişiklik gereksinimi

+Kullanılan bütün dillerin tercümeleri yer almayacak. (Veri tabanında sürekli olarak null alanlar yer alacak ve veri tabanında çok yer kaplayacak)

+değişiklik yönetiminin zorluğu

Yöntem 2 – Tek tablo üzerinden

Veri yönetim şemaları ve normalizasyon kurallarına göre oluşturulmuş bir veri şeması üzerinden işlerin tek tablo üzerinden yürütülmesi.

CREATE TABLE ref_language (
  Code Char(2)NOT NULL,
  Name Varchar(20) NOT NULL,
  PRIMARY KEY (Code)
);
CREATE TABLE app_translation (
Id Int IDENTITY NOT NULL,
PRIMARY KEY (Id)
);
CREATE TABLE app_translation_entry (
TranslationId Int NOT NULL,
LanguageCode Char(2) NOT NULL,
Text Text NOT NULL,
FOREIGN KEY (TranslationId) REFERENCES app_translation(Id),
FOREIGN KEY (LanguageCode) REFERENCES ref_language(Code)
);
CREATE TABLE app_product (
Id Int IDENTITY NOT NULL,
Description Int NOT NULL,
        PRIMARY KEY (Id),
FOREIGN KEY (Description) REFERENCES app_translation(Id)
);

Avantajları

+yeni bir dil eklendiğinde şemanın değiştirilmesine gerek duyulmaması

+basit bir şekilde tablolar arasındaki ilişkinin görülebilmesi

+bütün tercümelerin tek bir tabloda tutulması (aslında bu durum dezavantajlıdır. Çünkü fazla kalabalık verillerin okunaklılığı ve yönetimi oldukça zordur)

Dezavantajları

+karmaşık sorguların yazılması gerekliliği (doğru içeriğin getirilebilmesi için oldukça karmaşık sorguların yazılması gerçeği)

+çok karmaşık

Yöntem 3 – Opsiyonel veri eklemeli (Önerim)

Bu yöntemde dil referanslarını bir tabloda, ürünlerin (label, buton, vb.) ayrı bir tabloda ve son olarak ise bunların foreign key olarak bağlı olduğu ayrı bir tabloda ise gerekli tercümeler yer alır.

CREATE TABLE ref_language (
  Code Char(2)NOT NULL,
  Name Varchar(20) NOT NULL,
  PRIMARY KEY (Code)
);
CREATE TABLE app_product (
Id Int IDENTITY NOT NULL,
PRIMARY KEY (Id)
);
CREATE TABLE app_product_translation (
ProductId Int NOT NULL,
LanguageCode Char(2) NOT NULL,
Description Text NOT NULL,
FOREIGN KEY (ProductId) REFERENCES app_product(Id),
FOREIGN KEY (LanguageCode) REFERENCES ref_language(Code)
);

Avantajları

+yeni bir dil eklendiğinde şemanın değiştirilmesine gerek duyulmaması

+ilişkisel ve basit sorgular (1 join yeterlidir)

Dezavantajları

+tablo içerisinde kayıtlar tekrarlı olabilir.

Uygulamalarda çoklu dil desteğinin veri tabanı üzerinden nasıl çözülebileceğini en çok kullanılan üç yöntem ile incelemeye çalıştık. Bunların her hangi biri yanlıştır ya da herhangi biri doğrudur diyebilme şansımız yoktur. Eğer ufak ölçekli bir uygulama yapıyorsanız 1 numaralı yöntem oldukça işinize yarayacaktır. Sadece 2 ya da 3 dil kullanıyor olduğunuz için hem sorgulama hem de uygulama performansı çok üst düzeyde olacaktır. Tabii ki unutmamak gerekir ki sabit tanımlarınız çok fazla değişmiyor ve belirli adette ürününüzün bilgilerini veri tabanından getiriyorsunuz.

Büyük ölçekte veri dönüşümü olan ve henüz ülkesel dönüşümünü tamamlamamış organizasyonlarda ise 2. ve 3. yöntemler tercih edilecektir. Sorgularının karmaşıklı sebebiyle 2. yöntem yerine 3. yöntemin çok sık tercih edildiği görülmektedir.

Kısaca, çoklu dil desteğinin veri tabanı üzerinde nasıl yapıldığını 3 farklı yöntem ile örneklemeye çalıştık.

Umarım yararlı olmuştur.

İyi çalışmalar.

--

Turhal Temizer

Salı, Nisan 08, 2014

Qualcomm - MU Mimo (Multi User MIMO)

Wi-Fi standartları, gereksinimleri her geçen gün artan içerikleri sorunsuzca aktarabilmek için geliştiriliyor. Son olarak Qualcomm, Wi-Fi'ı daha da hızlandıracak MU-Mimo teknolojisini duyurdu.

MU-Mimo (çoklu kullanıcı, çoklu giriş ve çoklu çıkış), kablosuz ağlarda önemli bir atılım olarak kabul edilecek. Wi-Fi erişim noktaları, şu an kendisine bağlananlara sırayla hizmet veriyor, yani sadece tek bir kişi hizmet alırken, diğerleri bekliyor. Birkaç senedir üzerinde çalışılan MU-Mimo ise birden çok kullanıcı grubuna veri gönderebiliyor. Qualcomm, MU-Mimo'yu kullanmanın sol şeridi kullanmaya benzediğini söylüyor: "Wi-Fi otobanında bir değişiklik yok, ancak diğer kullanıcılarla gruplanmak, çok daha hızlı gitmenizi sağlarken, diğer şeritlerin de yoğunluğunu azaltıyor."

Qualcomm, ağın ve ağı kullananların MU-Mimo'yu kullanmaları halinde ağ hızlarının 2-3 kat hızlanacağını söylüyor. Bu teknolojiyi kullanmayan cihazlar da performansa artık görecekler, ancak bu MU-Mimo'yu kullananlarınki kadar çok olmayacak.

Qualcomm, MU-Mimo çiplerini Wi-Fi kullanan kablosuz router, erişim noktası, akıllı telefon, tablet üreticilerine satmayı planlıyor. Firmanın yeni teknolojiyi tüketicilere satışa sunmadan önce 2015'in ilk çeyreğinde gösterme planları da var.

http://en.wikipedia.org/wiki/Multi-user_MIMO

Perşembe, Nisan 03, 2014

ORA-12154: TNS:could not resolve the connect identifier specified in Visual Studio

If you are trying to connect to an Oracle Database, through Server Explorer in Visual Studio, you have to ensure that:

1. You have installed the Oracle Data Provider (downloadable from the Oracle Website)
2. Have created the tnsnames.ora file, holding information about the databases (http://www.orafaq.com/wiki/Tnsnames.ora). This file should be created most often in the Network\Admin folder under the Oracle Provider. In my case: C:\app\user\product\11.2.0\client_1\Network\Admin

After having these prerequisites, I still couldn't connect to the Oracle Database. The Visual Studio wizard told me: "ORA-12154: TNS:could not resolve the connect identifier specified". What resolved this issue for me was to add the Environment Variable with name "TNS_ADMIN" and value the Path to the directory containing the "tnsnames.ora" file.
Something like:
TNS_NAMES="C:\app\user\product\11.2.0\client_1\Network\Admin"
Then just restart Visual Studio and you're free to go.

Hope this helps someone out there :)

Using Visual Studio to find a database connection string

I have to give these instructions quite often in Q&A, so it seemed sensible to write them one more time, and then point people in this direction in future...
One of the things it can be difficult to work out is what you actually need in your connection string to access a database via your code. Although there are sites which give examples, (this[^] is a good one) it would help to have a connection to your database open and working to take it from. Visual Studio can help you there.
1) Open the Server Explorer pane. ("View" menu, "Server Explorer" or CTRL+W, L by default)
2) Open the "Data Connections" list. If your database in on the list, skip to step 3
2.1) On the Server Explorer tool bar, click the "Connect to Database" button (yellow column, with green cross and a plug-and-wire icon)
2.2) On the resulting dialog, select the appropriate Date Source, Server name, and other details until the "Test Connection" button works.
2.3) Press the "OK" button to add the connection - this does not affect your project or solution in any way!
3) Click once on the database to highlight it.
4) Look at the Properties Pane (If it isn't visible - and it should be, at all times - then the "View" menu, "Properties Window" or CTRL+W, P will open it)
5) Near the top will be the property "Connection String". You can right click the value, and use "Select All" and "Copy" to move it to the clipboard, ready to be pasted into you application (or preferably your application config file).

Çarşamba, Nisan 02, 2014

Connection String to Connect to Oracle Database

Something like this :

[code]Data Source=(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=MyHost)(PORT=MyPort)))(CONNECT_DATA=(SERVER=DEDICATED)(SERVICE_NAME=MyOracleSID)));User Id=myUsername;Password=myPassword;[/code]

This site is really helpfull for all connection strings types : http://www.connectionstrings.com

Connecting to Oracle From Visual Studio

Oracle DB ile çalışırken Management Studio ve Visual Studio ile çalışırken dikkat edilmesi konusunda çok güzel bir yazıyı alt kısımda yer alan link içerisinde bulabilirsiniz.

TNS ORA ‘ya dikkat etmeniz gerekmektedir.

http://blogs.msdn.com/b/kaevans/archive/2009/07/18/connecting-to-oracle-from-visual-studio.aspx

Kolay gelsin.

Best practices when using oracle DB and .NET

Some practices we employ based on our production experience:
•Validate connections when retrieving them from the connection pool.
•Write your service code to not assume that connections are valid - failure to do so can cause quite a bit of grief especially in production environments
•Wherever possible, explicitly close and dispose connections after using them (using(conn){} blocks work well)
•In a service, you should use connections for the shortest time possible - particularly if you are looking to create a scalable solution.
•Consider using explicit timouts on requests appropriate to the typical duration of a request. The last thing you want is to have one type of request that hangs to potentially block your whole system.
•Wherever possible use bind variables to avoid hard parses at the database (this can be a performance nightmare if you don't start out with this practice). Using bind variables also protect you from basic SQL-injection attacks.
•Make sure you have adequate diagnostic support built into your system - consider creating a wrapper around the Oracle ADO calls so that you can instrument, log, and locate all of them.
•Consider using stored procedures or views when possible to push query semantics and knowledge of the data model into the database. This allows easier profileing and query tuning.
•Alternatively, consider use a good ORM library (EF, Hibernate, etc) to encapsulate data access - particularly if you perform both read and write operations.
•Extending on the above - don't pepper your code with dozens of individually written SQL fragments. This quickly becomes a maintainability nightmare.
•If you are committed to Oracle as a database, don't be afraid to use Oracle-specific features. The ODP library provides access to most features - such as returning table cursors, batch operations, etc.
•Oracle treats empty strings ("") and NULLs as equivalent - .NET does not. Normalize your string treatment as appropriate for Oracle.
•Consider using NVARCHAR2 instead of VARCHAR2 if you will store Unicode .NET string directly in your database. Otherwise, convert all unicode strings to conform to the core ASCII subset. Failure to do so can cause all sorts of confusing and evil data corruption problems.

Common Criteria (ISO/IEC 15408)

Tanımı

Bilgi Teknolojisi (BT) ürünlerine ve sistemlerine güvenlik (confidentiality), güvenilirlik (availability) ve bütünlük (integrity) kapsamında fonksiyonel ve sızma testleri uygulayan ve test sonucuna göre ürünün veya sistemin güvenlik, güvenilirlik ve bütünlük kapsamında ISO 15408 metodolojisine göre garanti seviyesini belirleyen uluslararası test standardıdır.

 

Özetle: TS ISO/IEC 15408 serisi BT ürünlerinin güvenliği için değerlendirme kriterleri sertifikasıdır

 

Ortak Kriterler Garanti Seviyeleri

Ortak Kriterler Garanti Seviyeleri EAL, Evaluation Assurance Level (Değerlendirme Garanti Seviyesi) olarak adlandırılan 7 seviye (EAL 1-7) bulunmaktadır. EAL 7 seviyesi en yüksek garanti düzeyi, EAL 1 seviyesi en düşük garanti düzeyidir. Üst seviye garanti düzeyleri, alt seviye garanti düzeylerini kapsamaktadır.

 

İlgili Taraflar

  • Geliştiriciler (Either vendor itself or document provider)
  • Sponsorlar (Vendor)
  • Değerlendiriciler (Değerlendirme Lab)
  • Onaylayıcılar (Onay Makamı)

 

Common Criteria (Ortak Kriterler) Bölümleri

 

Common Criteria (Ortak Kriterler) Kanıtları

CC Değerlendirmesi esnasında bazı kanıtların değerlendiricilere sunulması gerekmektedir. Bu kanıtlardan bazıları şunlardır :

  • Mimari ve Tasarım Dokümanları
  • Konfigürasyon Yönetimi Dokümanları
  • Fonksiyonel Testler

 

Değerlendirme Teminat Seviyeleri (EALs) ve Sınıflar

CC , EAL1 den EAL7 ye kadar teminat seviyesine sahiptir. Bu seviyeler değerlendirilmiş bir ürüne hangi seviyede güvenilebileceğini ifade eder. CC sınıfları değerlendirme alanlarıdır. Bunlar :

  • Geliştirme (ADV)
  • Kullanım Kılavuzları (AGD)
  • Yaşam Döngüsü Desteği (ALC)
  • Güvenlik Hedefi Değerlendirmesi (ASE)
  • Testler (ATE)

 

Ortak Kriterler Standardı Ne Yapar? 

  • Tasarım sürecini sorgular.
  • Teslim & kurulum sürecini sorgular.
  • Tasarım dokümanlarının içerik yeterliliğini sorgular.
  • Kaynak kodu sorgular.
  • Kılavuz dokümanları sorgular.
  • Yaşam döngüsü modelini sorgular.
  • Geliştirme araçlarını sorgular.
  • Geliştirme ortamının güvenliğini sorgular.
  • TEST DOKÜMANLARINI SORGULAR(Fonksiyonel, Bağımsız ve Sızma Testleri).
  • Ürün Geliştiriciyi, Üründeki ve Sistemdeki olası GÜVENLİK ZAYIFLIKLARINI minimuma düşürecek bir METODOLOJİYE uymaya ZORLAR.
  • Özetle, BT ürününün yeterli bir geliştirme ortamında gerçeklenip gerçeklenmediğini kontrol eder, var olan tehditleri analiz eder, Fonksiyonel, Bağımsız ve Sızma testleri (Açıklık Ana çalışması) yapar ve ürüne uygun garanti seviyesini verir.

 

Ortak Kriterlerde çok Genel Kavramlar:

  • TOE (Target of Evaluation): Değerlendirme Hedefi
  • ST (Security Target): Güvenlik Hedefi, TOE güvenlik iddialarının belirtildiği dokümandır.
  • PP (Protection Profile): Koruma Profili, CC standardına uygun olarak yazılmış Teknik Şartnamelerdir. ST ler için şablon dokümanlardır.

 

Ortak Kriterler (Güvenlik Teknikleri BT Ürün Güvenliği için Değerlendirme Kriterleri-TS ISO/IEC

15408) Standardı 3 ana bölümden oluşmaktadır:

 

  • TS ISO/IEC 15408-1 Bölüm 1: Giriş ve Genel Model
    • Ortak kriterlere giriş niteliğindedir. 
    • BT güvenlik değerlendirmelerinin temel konsept ve prensiplerini tanımlar
    • Genel bir değerlendirme modeli sunar. 
    • BT güvenlik hedeflerinin oluşturulması, BT güvenlik gereksinimlerinin seçilmesi ve tanımlanması, ve ürünlerin veya sistemlerin üst düzey spesifikasyonlarının yazılması konularını içerir. 
    • Standardın tüm bölümlerinin bütün potansiyel kullanıcılar için nasıl kullanılacağı bu bölümde tanımlanmaktadır. 

 

  • TS ISO/IEC 15408-1 Bölüm 2: Güvenlik Fonksiyonel Gereksinimleri
    • Değerlendirme hedefinin(TOE) güvenlik fonksiyonel gereksinimlerinin(SFR)tanımlanması için güvenlik fonksiyonel bileşenleri listelenir. 
    • Standardın bu bölümü fonksiyonel bileşenlerini, ailelerini ve sınıflarını kataloglar halinde tanımlamaktadır:

 

Güvenlik Fonksiyonel Gereksinimleri (SFR):

  • FAU: Security audit (Güvenlik denetimi)
  • FCO: Communication (İletişim)
  • FCS: Cryptographic support (Kriptografi desteği)
  • FDP: User data protection (Kullanıcı verilerinin korunması)
  • FIA:  Identification and authentication (Tanıma ve kimlik doğrulama)
  • FMT: Security management (Güvenlik yönetimi)
  • FPR: Privacy (Gizlilik)
  • FPT: Protection of the TSF (TSF' nin korunması)
  • FRU: Resource utilisation (Kaynak kullanımı)
  • FTA: TOE access (TOE erişimi)
  • FTP: Trusted path/channels (Güvenilir yollar/kanallar)  

 

  • Bölüm 3, Güvenlik Garanti Gereksinimleri (SAR), Güvenlik garanti bileşenleri kümesi bu  bölümde listelenmektedir. Bu bölüm aynı zamanda Koruma Profillerinin(PP) ve Güvenlik Hedeflerinin (ST) değerlendirme kriterlerini ve değerlendirme garanti seviyelerini oluşturan garanti bileşenlerini de içermektedir. 
    • ADV: Development (Geliştirme)
    • AGD: Guidance documents (Kılavuz Dokümanları)
    • ALC: Life cycle support (Yaşam döngüsü desteği)
    • ASE: Security Target (Güvenlik Hedefi)
    • ATE: Tests (Testler)
    • AVA: Vulnerability assessment (Açıklık değerlendirmesi)

 

Ortak Kriterler tanımlanmış, garanti seviyesi gittikçe artan ve Değerlendirme Garanti Seviyesi (EAL) olarak bilinen 7 adet garanti paketi sağlamaktadır. Bu 7 garanti seviyesi: 

 

EAL1: Bu seviye ürünün veya sistemin doğru çalıştığına dair güvenin yeterli olduğu ve güvenlik tehditlerinin ciddi olmadığı durumlarda kullanılmaktadır.(Fonksiyonel test)

 

EAL2: Ürün geliştirici tasarım bilgilerini ve test sonuçlarını değerlendirme laboratuvarına iletmelidir. EAL2 değerlendirmesi, müşteriler veya ürün geliştiriciler, düşük ve orta düzey seviye arasında bir güvenlik gereksinimi duyuyorlar ise ve ürünün geliştirme dokümanlarının tamamına ulaşamıyorlar ise uygulanmaktadır. (Yapısal Test) (Black box)

 

EAL3: EAL3 seviyesinde standart, ürün geliştiriciye tasarım sırasında maksimum garanti sağlayabilmesi için yöntemler önermektedir. EAL3 değerlendirmesi üreticinin test sonuçlarının seçilerek onaylanması ve bilinen açıklıkların üretici tarafından incelendiğinin kanıtlanmasını içeren gri kutu testleri (grey box testing) ile desteklenmektedir. Ayrıca geliştirme ortamı kontrolleri ve ürünün konfigürasyon yönetimi delilleri değerlendirmeler için gerekmektedir. (metodik test ve kontrol)

 

EAL4: EAL4 seviyesi ticari ürün geliştirme yöntemlerinden maksimum garanti sağlayabilmek için ürün geliştiricilere yöntemler önermektedir. EAL4 var olan ürün geliştirme altyapısını değiştirmeden ulaşılabilecek en yüksek garanti seviyesidir. EAL4 değerlendirmesi ürünün alt düzey tasarımı ve uygulamanın alt kümelerinin analizi ile de desteklenen bir süreçtir. Yapılan testler bağımsız açıklık analizleri ile desteklenir. Geliştirme kontrolleri yaşam döngüsü desteği, tanımlama teknik ve araçları, ve otomatik konfigürasyon yönetimi ile güçlendirilir. (metodik dizayn, test ve kontrol)

 

EAL5: EAL5 seviyesi, özel güvenlik tekniklerinin orta düzeyde uygulanması ile desteklenen, ticari ürün geliştirme yöntemlerinden maksimum garanti sağlayabilmek için ürün geliştiricilere yöntemler önermektedir. Bu seviyeye aday bir ürün seviyenin gerektirdiği garantiyi sağlayabilecek bir şekilde tasarlanmalı ve geliştirilmelidir. Bu seviye ürün geliştiricileri ve müşteriler yüksek seviyede güvenlik ve bağımsız bir garanti ihtiyacı duyduklarında kullanılmaktadır. (semiformal dizayn ve test)

 

EAL6: EAL6 seviyesi yüksek değerdeki varlıkları korumakta olan ürünler için yüksek garanti seviyesi sağlayan güvenlik teknikleri önermektedir. (semiformal doğrulanmış dizayn ve test)

 

EAL7: EAL7 seviyesi son derece yüksek risk durumlarında veya korunan varlıkların bu seviyenin getireceği maliyeti karşılayabileceği durumlarda uygulanabilmektedir. (formal doğrulanmış dizayn ve test) (white box)

 

Ürün Kategorileri,

  • Erişim kontrol cihaz ve sistemleri
  • Sınır koruma cihaz ve sistemleri
  • Veri tabanları
  • Veri koruma
  • Tespit cihaz ve sistemleri
  • Akıllı kartlar(kredi kartları, atm kartları, cep telefonları sim kartları, doğalgaz ön ödemeli sayaç kartları, elektrik-su ön ödemeli sayaç kartları, elektronik alışveriş kartları, kimlik kartları vb.)
  • Anahtar yönetimi cihaz ve sistemleri
  • Ağ iletişimi ile ilgili cihazlar
  • İşletim sistemleri

Salı, Nisan 01, 2014

ISO 27001 Bilgi Güvenliği Yönetim Sistemi Danışmanlık Hizmetlerinde ne tür hizmetler alınır?

Danışmanlık firması seçiminde dikkat edilmesi gereken en önemli husus en ucuz fiyatı veren değil size daha az maliyette sistem kurmanızı sağlayacak referansları güçlü bir danışman firma ile çalışmanız tavsiyesinde bulunuyoruz. Danışman Firmanın bünyesinde en 1 adet ISO 27001 Baş Denetçi Sertifikasına sahip danışman bulunmalıdır.

ISO 27001 Danışmanlık firmasına karar verildikten sonra kurumunuz danışmanlık firması ile ISO 27001 Bilgi Güvenliği Danışmanlık hizmeti alımı anlaşması yapmalıdır. Danışmanlık hizmeti sözleşmesinde ISO 27001 bilgi güvenliği sistemi kurulum sürecin genel takvimi karşılıklı mutabakatla çıkartılmalı ve karara bağlanmalıdır.

1. Bilgi Güvenlik Yönetim Sistemi Forumunun kurulmas
ı:
Danışman ve kurum içinde bir " Bilgi Güvenliği Koordinasyon Grubu (BGKG)- Forumu"nun oluşturacaktır. Bu forum kendi içinde yaptığı görüşmeler sonucu takvimi ve görev paylaşımını yapacaktır. Eğitimler bu çalışmalar içinde kararlaştırılarak takvime bağlanacaktır.

2. Kurumun Mevcut Sistem ve Dokümantasyon Analizi:
Kurumda ISO 9001 KYS kurulu değil ise öncelikle temel ISO 9001 ve ISO 27001 standardının zorunlu tuttuğu ve ancak ISO 9001 tarafından sağlanması gereken prosedür ve süreçler yapılandırılacaktır. Bu süreç ISO 27001 bilgi güvenliği için temel yönetim omurgasını yapılandırmış olacaktır.
Eğer kurumda ISO 9001 kalite yönetim sistemi kurulu ise ISO 27001 bilgi güvenliği standardının istediği kimi prosedürler, proses ve talimatlar bu standart dokümantasyonun etkinliği kontrol edilecek ve eksiklikler belirlenecektir.

3. Bilgi Güvenliği Yönetim Sistemi kapsam ve sınırlarının belirlenmesi :
Temel ISO 9001 Kalite Yönetim sistemi yapılanmasının ardından kuruma dair ISO 27001 Bilgi Güvenliği Yönetim Sistemi kapsamı ve sınırları belirlenmesi aşaması gelmektedir. Özellikle belgelendirme aşamasında kapsam ve sınırlar denetimin en önemli unsurları olarak karşımıza çıkmaktadır.

4. BGYS Temel politikası ve diğer politikaların oluşturulması:
Yine ilk oturum içinde belirlenen kapsama bağlı olarak kurumun temel Bilgi Güvenliği Yönetim Sistemi Politikası hazırlanacaktır.ISO 27001 Temel Bilgi Güvenliği Yönetim Sistemi Politikası Forumun bir oturumunda karar bağlanacaktır ve Üst yönetim bu politikayı onaylayarak tüm kuruma duyuracaktır. Diğer politikalar sistem kurulumu aşamasında yapılandırılacaktır.

5. Varlıkların Belirlenmesi ve Sınıflandırılması :
Kurumdaki tüm varlık envanterinin çıkartılması gerekmektedir. Varlık envanteri çıkartılırken etkileme yapılarak varlıların sınıflandırılması sağlanacaktır. Varlıklar sınıflandırıldıktan sonra puanlama yapılarak kritik varlıkların belirlenmesi sağlanacaktır.

6. Risk Analizi ve Değerlendirmesi Çalışmasının Yapılması:
Bilgi güvenliği politikalarını temel alan sistematik bir risk değerlendirme yaklaşımının belirlenerek risk belirleme çalışmaları başlatılacaktır. Tespit edilen risklerin analizi ve derecelendirilmesinin yapılması ve raporlanması yapılacaktır. Risk değerlendirme sonuç raporundan yola çıkılarak uygun risk işleme (risk treatment) yöntemlerinin belirlenecektir. Risk analizine esas olacak bir penetrasyon test raporu ya kurum içinde ya da bağımsız kuruluşlarca hazırlatılmalıdır. Dahili ve harici saldırı senaryoları, felaket yönetimi senaryoları çalışılmalıdır. Buna bağlı olarak oluşturulan rapor risk analizi için temel teşkil etmelidir. Risk analizi ve değerlendirilmesinde daha fazla bilgi için lütfen tıklayınız

7. Hazırlanan risk raporu üst yönetime sunulması:
Risk analiz raporu üst yönetime sunularak risklerle ilgili kararı verilecektir. Üst yönetimin risk üstlenme dokümanından sonra ISO 27001 Bilgi Güvenliği Yönetim Sistemi kurulum çalışmalarına geçilecektir. Risk analizi ve değerlendirilmesinde daha fazla bilgi için lütfen tıklayınız

8. Risk işleme süreci sonuçlarına uygun TS ISO IEC 27001 Bilgi Güvenliği Yönetim Sistemi standardının ekinde yer alan Ek-A kontrol Kriterleri’nin seçilmesi ve kontrol hedeflerinin belirlenmesi:
Bu aşamada sistemin kurulması çalışmaları başlamaktadır. Kapsam, sınırlar, politikalar ve risk analizine bağlı olarak seçilen kontrol kriterleri yapılandırılacaktır.

9. Uygulanabilirlik Bildirgesinin hazırlanması:
Ek – A kontrol kriterlerinin seçilmesi ve kontrol hedeflerinin belirlenmesinden sonra standardın istediği Uygulanabilirlik bildirgesi hazırlanacaktır.

10. Sistem iç tetkiki ve Yönetimin gözden geçirilmesi yapılması:
Bu aşamada uygulamaya alınır. en az 30 günlük bir uygulama süresinden sonra sistemin iç tetkiki gerçekleştirilir. İç tetkik raporları Yönetimin Gözden Geçirilmesi Toplantısında karar bağlanır.

11. Belgelendirme Kuruluşuna Müracaatın Yapılması :
Sistemin istenilen düzeyde çalışıyorsa Belgelendirme amaçlı Aşama-1 (Stage-1) sürecine gelinmiş olur ve bu aşamada kurumunuzu akredite olmuş belgelendirme kuruluşlarına müracaat etmesi fiyat teklifi alması gerekir.

12. Birinci Aşama Belgelendirme Denetiminin Yapılması :
Birinci Aşama Belgelendirme denetimi Belgelendirme kuruluşu tarafından yapılır ve var ise eksiklikler ve uygunsuzluklar tespit edilir. Yapılan başvuru sonucu belgelendirmeci kuruluşun saptadığı eksikliklerinin ve uygunsuzlukların tamamlanması için verilecek hizmet danışmanlık hizmeti kapsamındadır. Eksiklikler ve uygunsuzlukların tamamlanması veya hiç eksiklik ve uygunsuzluk bulunmaması durumunda 2. Aşama Belgelendirme Denetimine geçilir.

13. İkinci Aşama Belgelendirme Denetiminin Yapılması :
İkinci aşama belgelendirme denetimi asıl denetimdir ve sistem bütün yönleri ile ve uygulamaları ile incelenir. Belgelendirme kuruluşu denetçileri tarafından ISO 27001 standardına göre mevcut durum, Gözlem, Tavsiye, uygunsuzluklar tespit edilir. Danışmanlık firması 1. Aşama denetimde olduğu gibi eksiklikleri ve uygunsuzlukları giderir ve Belgelendirme kuruluşuna yapılan düzeltici faaliyetler gönderilir.

14. ISO 27001 Belgesinin Sertifikasının Basılması:
Denetimlerden başarı ile geçmesi durumunda Belgelendirme kuruluşu ISO 27001 Bilgi Güvenliği Yönetim Sistemi Belgesini firmanıza gönderir.

15. ISO 27001 Danışmanlık Firması Teknik Destek Danışmanlık Hizmeti:
Aslında bu durum ilk başta tekliflerin alınması sözleşmenin yapılması aşamasında karara bağlanmalıdır. ISO 27001 Bilgi Güvenliği Yönetim Sisteminin sürekliliğinin sağlanması ve iyileştirilmesi sistemin tam olarak anlaşılması için danışman firmanın bir sonraki gözetim denetimine kadar teknik destek danışmanlık hizmeti vermesi gerekir. Bu hizmeti almak tamamen kuruluşunuza bağlıdır.

Yukarıda belirtilen 15 maddeyi özetlersek ISO 27001 Danışmanlık firmasından aşağıdaki hizmetler alınır.
  • Bilgi varlıkların sınıflandırılması, kategorileştirilmesi, sistem açısından kritikliklerinin belirlenmesi.
  • Gizlilik, bütünlük ve erişebilirlik kriterlerine göre varlıkların değerlendirilmesi
  • Risk yaklaşımı için bir çerçevenin sunulması
  • Risk analizi raporunun hazırlanması
  • Risklerin derecelendirilmesi
  • Risklerin üst yönetime sunulması için çerçeveyi oluşturma
  • Üst yönetimin risk analiz raporu değerlendirmelerine göre risk işleme planının hazırlanması
  • Risk işleme planına uygulanacak kontrolleri belirleme
  • Dokümantasyon oluşturma
  • Kontrolleri yapılandırma
  • İç tetkik
  • Kayıtları tutma
  • Yönetimin gözden geçirmesi

ISO 27001 Bilgi Güvenliği Yönetim Sisteminde Risk Değerlendirme Sistemi nedir Bilgi Güvenliği Riskleri nasıl değerlendirilir ve Risk Değerlendirme Yaklaşımında dikkat edilmesi gereken Hususlar nelerdir ?


ISO 27001 Bilgi Güvenliği Yönetim Sistemi, özellikle Risk Yönetimi yapısı üzerine kurulur. Her şey bir tarafa, risk yönetimi bir tarafa.

ISO 27001 Standardı risk yönetimi için;

1. “ Risk değerlendirme yönetim sistemi yaklaşımını ortaya koyun”, der. Risk yaklaşımı riskin nasıl algılandığına, anlaşıldığına dair genel bir metodun açıklanmasını ister. Kurumun riskten ne anladığı, riskleri nasıl değerlendireceğine dair yaklaşımlarının ne olduğunu ortaya koyar. Genel bir çerçeve olmadan risklerin ortaya konulamayacağını vurgular.

2. “ Risk analizini yap”, der. Ortaya konulan metoda bağlı olarak risklerini analiz et demektir bu ifade. Kurumun içindeki, faaliyetlerindeki, hizmetlerindeki, alt yapındaki, personelindeki, teçhizatındaki riskleri ortaya koymak, onları açık hale getirmek için risk kapasiteni çözümlemek gerekmektedir. Risk analizi, kurumun risklerini ortaya çıkarmak adına her kritik konuyu irdelemekten, araştırmaktan geçer. Sonunda kurumun risklerine ilişkin bir çerçeve çıkar. Nerede ne varmış, sorgulanmış ve öne çıkarılmış olur.

3. Risk analizinde ortaya çıkan tabloya bağlı olarak riskler değerlendirilir ve önceliklendirilir. Risk değerlendirme yaklaşımında tanımlanmış olan seviyelere göre sıralanır. Risk analizindeki riskler değerlendirme matrisi içine yerleştirilir. Matrise göre hangi risklerin yönetileceği tanımlanmış olur.

4. Risklerin nasıl yönetileceği konusuna sıra gelmiştir. İşte burada “ Risk İşleme Planı ” devreye girer. Riskleri yönetmek için iso 27001 standardı bize dört yardımcı sunar:

  • Riskleri kabullen. Yapacak bir şey yok. Sonuçlarını kabullen. Sonuçlarının maliyetlerini üslen. Eğer çalıştığınız yeri değiştiremiyorsanız deprem riskinin sonucunu kabullenebilirsin.
  • Risklerden kaçın. Düzelecek bir şey yok. Biz sonuçlara katlanamayız. O halde binayı terk ediyoruz. Biz buradan kaçıyoruz, denilebilir. Riskten kaçınırsınız.
  • Riskleri üçüncü taraflara devredebilirsiniz. Sigorta firmalarına, alt yüklenicilere, müşterilere, emniyet güçlerine, itfaiyeye. Sözleşmelerle risklerinizi devrederek sonuçlarını yönetebilir hale gelirsiniz. Örneğin internet kesintilerini Türk Telekom veya internet erişim sağlayıcılara devredebilirsiniz. Ne de olsa ülkemizde tek erişim alt yapı hizmeti Türk Telekom veriyor ve internet kesintisi sırasında ortaya çıkabilecek bir sorunun muhatabı Türk Telekom ise;
  • Riskleri yönet. İşte işin can alıcı noktasına geldik. Kabullenmediğimiz, kaçınamadığımız, devredemediğimiz riskleri yönetmeye.
  • Risk işleme planına göre yönetilmesi gereken riskler için sıra geldi nasıl yöneteceğimize.