Arşiv | İş Analizi RSS feed for this section

Kargo Kültü

16 Ağu

Kamu Kurumlarında da sık karşılaştığımız “Yapılan işlerin yüzeysellikle Anlamadan, Kavramadan, Neden Yapıldığı Bilinmeden Yapıldığında İyi Olacağı Düşünülen İnanca” “Kargo Kültü” Diyoruz!

Nedir Bu Kargo Kültü:

İkinci Dünya Savaşı sırasında Güney Pasifik’te daha önce kimsenin uğramamış olduğu ve yerlilerin yaşadığı bir kaç ada stratejik önem kazanmaya başlıyor. Japonya ve ABD uçakları yakıt ikmali yapmak için bu adalarda üsler kuruyorlar ve teknoloji ile alakası olmayan yerliler bir anda medeniyet ile tanışıyor.

Adalara sık sık askerlere takviye için kargo uçakları iniyor ve uçaklar; giysi ve konserve gibi temel ihtiyaç malzemeleri getiriyorlar. Elbette bu ürünlerden yerlilere de dağıtılıyor.

Savaşın bitmesinin ardından da herkes pılını pırtını toplayarak adaları bir başına bırakıyor. Yerliler ise batılıların tekrar gelip ürün dağıtlamaları için çok ilginç bir yönteme başvuruyorlar.

Bambulardan uçak modelleri ve kontol kuleleri yapıp yerlere uçuş pistlerini anımsatan yollar çizip ateşle aydınlatıyorlar. Hatta kule görevlisi ile uçuş görevlileri gibi davranıp uçakların inmesini bekliyorlar.

Kargo kültü terimi de buradan doğmuş. Anlamına gelecek olursak; bir süreci anlayamadığımız ya da kavrayamadığımız taktirde, yüzeysel görünümünü taklit ederek aynı işlev ve fonksiyonda çalışmasını ummak diyebiliriz.

Kaynak: https://www.yirmilerim.com/kargo-kultu-nedir/

Reklam

Kalite Evi Nedir? Neden ve Nasıl Kullanılır?

13 Haz

Blog ziyaretçimden gelen soruyla öğrendiğim ve hoşuma giden bu bilgiyi sizlerle de paylaşmak istedim. Daha önceden BABOK veya PMI Gereksinim Yönetimi kitaplarında görmediğim Kalite eksenli bir konu ve Yazılım çalışmalarında Gereksinim Yönetimi için de kullanılabilecek görünüyor.

Kalite evinin esası müşterinin istek ve beklentilerini karşılayan ürünlerin tasarlanması düşüncesidir.Japonca’da, “Hinshitsu Kino Tenkai”, İngilizce’de ise “QFD” olarak biliniyor. Türkiye’de ise uygulayan şirketler “Kalite evi” tanımını yapıyor. 1970’li yıllarda Japonya’da geliştirildi. O dönemde büyük ilgi gördü, ABD’li şirketler tarafından da uygulandı. Türkiye’de ise son dönemde yaygınlaşıyor. Çok sayıda şirket, sessiz, ancak derinden gidiyor. İşin özünde ise son müşteriyi dinleyerek, tasarımdan üretime, bütün ürün geliştirme süreçlerini değiştirme var.

Kaynak ve ek bilgi: http://www.capital.com.tr/gelecek-trendler/kalite-evi-nasil-calisir-haberdetay-1816

 

Kalite evi fonksiyonlar arası planlama ve iletişimi sağlayan bir tür kavramsal haritadır. Değişik problemleri ve sorumlulukları olan insanlar evin çatısı altındaki bilgi motiflerinden tasarım önceliklerini kolayca belirleyebilirler.

Kalite evi, tanımlanmış müşteri ihtiyaçlarını “NELER” ve buna karşılık gelen mühendislik spesifikasyonlarının “NASILLAR” olarak isimlendirilerek ilişkilendirildiği, matris tarzında bir şemadır. 6 ana bloktan oluşur.

Bu bloklar ise 12 parçadan oluşur. Bu alt bloklar aşağıda sıralanmıştır:

  1. Müşteri Gereksinim ve Beklentileri
  2. Müşteri Gereksinim ve Beklentilerinin Anlamı
  3. Rakip Karşılaştırmaları
  4. Müşteri Gereksinim ve Beklentilerine İlişkin Diğer Kriterler
  5. Ürün ya da Proje Özellikleri
  6. Müşteri Gereksinim ve Beklentileri ile Ürün ya da Proje Özellikleri İlişkisi
  7. Ürün ya da Proje Özelliklerinin Anlamı
  8. Ürün ya da Proje Özelliklerinin Rekabet Karşılaştırması
  9. Ürün ya da Proje Özelliklerine İlişkin Diğer Kriterler
  10. Ürün ya da Proje Özelliklerinin Optimizasyon Yönü
  11. Ürün ya da Proje Özelliklerinin Karşılıklı Etkileşimi
  12. Ürün ya da Proje Özelliklerine İlişkin Hedef Değerler

Kalite Evinin Oluşturulması

Kalite evinin oluşturulmasını adım adım incelemeden önce bütününe bakacak olursak;

Şimdi kalite evini oluşturan bu birimleri nasıl dolduracağımızı incelersek;

Aşama 1: Müşteri Beklentileri Listesi

Kalite evinin oluşturulmasındaki birinci adım Müşteri Beklentileri Listesinin oluşturulmasıdır. Bu liste müşterinin ihtiyaçları ve üründe bulunmasını beklediği özelliklerden oluşur. Birincil müşteri beklentileri olarak adlandırılan bölümde, özellikler, genel kavramlarla ifade edilir. İkincil müşteri beklentileri bölümünde ise birincil bölümdeki maddeler detaylandırılır.

Müşteri beklentilerinin, hiyerarşik bir yapı içerisinde detaylandırılması, beklentilerin mühendislik aşamasında kullanılabilecek şekilde ifade edilmesini sağlar. Örneğin birincil müşteri beklentisinin “güvenilirlik” olması halinde; ikincil müşteri beklentilerini sağlamlık, uzun kullanım süresi ve iyi bir bakım hizmeti olabilir.

Gerek müşterilerle doğrudan görüşerek gerekse soru formları kullanılarak müşteri önem seviyeleri saptanır. Müşteri beklentileri ve isteklerine, önem seviyesine göre 1 ile 5 arasında not verilir. İşletmenin anket çalışmasından elde ettiği müşteri istekleri bulguları, aynı zamanda NELER’ in yapılması gerektiğini de ortaya koymaktadır.

 

Aşama 2: Teknik Tanımlamalar Listesi

Kalite evinin amacı, müşteri beklentilerini karşılayacak ürün tasarlamak ya da mevcut tasarımları geliştirmektir. Bu amaca yönelik bir uygulamada en önemli nokta, müşteri beklentilerinin mühendislik aşamasında kullanılabilecek teknik tanımlamalara dönüştürülmesidir. Teknik tanımlamalar, kalite evinin ikinci katını ve tavanını oluşturmaktadır. Yani, pazarlama grubu NELER’ in yapılacağını belirledikten sonra bunların NASIL yapılacağı AR-GE grubu tarafından tanımlanır. Bu aşamada grup üyeleri her bir müşteri beklentisini gerçekleştirecek birkaç ölçülebilir tasarım unsurunu belirleyecek ve bu şekilde kalite evi matrisi hazırlanacaktır.

Kalite evi matrisinde, satırlar müşteri beklentilerini ve bunların göreli önem derecesini, sütunlar ise bu beklentileri gerçekleştirecek mühendislik özelliklerini içerir.

Aşama 3: Müşteri Beklentileri ile Teknik Tanımlamalar Arasındaki İlişkiyi Gösteren Matris

Kalite Evinin hazırlanmasında 3. Adım ise, her bir teknik özelliğin hangi müşteri gereksinimini karşılamaya ne derece etkisi olduğunu gösteren ilişki matrisinin oluşturulmasıdır. Bu kısım kalite evinin gövdesini oluşturur.

Bu amaçla kalite evi matrisinde NE’ler ve NASIL’lar arasındaki ilişkiler genelde sembollerle gösterilir.

İlişki matrisi oluşturulduktan sonra yapılacak işlem boş kalan satır ve sütunların incelenmesidir. Boş bir satır ilgili müşteri beklentisinin herhangi bir teknik tanımla ilişkilendirilmediğinin göstergesidir. Bu durumda yapılması gereken matrise yeni bir teknik tanım eklemek ve karşılanmamış olan müşteri beklentisini en az bir teknik tanımla ilişkilendirmektir.

Matriste boş kalmış olan sütunlar ise, ilgili tanımın hiçbir müşteri beklentisini etkileyemediğini gösterir. Bu teknik tanımlar dikkatli bir inceleme sonrasında hala ilişkilendirilemezlerse matristen çıkarılmalıdırlar.

Her teknik gereksinim için müşteri memnuniyetini en üst düzeye çıkaracak ve müşteri için en olumlu nitelikte olan bir gelişim yönü vardır. Geliştirme yönü “daha … olması gerekli” terimindeki boşluk doldurularak belirlenir.

Derecelendirme sembollerinin veya harflerinin sayısal bir değere eşitlenmesi, ileride yapılacak trade-off ve mutlak ağırlık hesaplamaları için gereklidir.

G=9 (güçlü)

M=3 (orta)

V=1 (zayıf)

Aşama 4: Teknik Göstergeler Arasındaki Korelasyon Matrisi

Kalite evinin çatısını oluştururken üçgen biçimindeki korelasyon matrisi, teknik tanımların kendi aralarındaki iç ilişkilerini göstermek amacıyla kullanılır.

+1 = Pozitif

0 = Orta

-1 = Negatif

Aşama 5: Rekabet Matrisleri

Rekabet matrisleri kuruluşun kendi ürünü ile rakip kuruluşların ürünleri arasındaki farkı görebilmesi amacıyla oluşturulur. Kalite evinde rekabet ortamının değerlendirilmesi için müşteri ve teknik tanımlar bazında rekabet matrisleri oluşturulur.

  • Müşteri Bazlı Rekabet Matrisi: Kalite evinin sağ tarafına yer alan sütunlardan oluşur. Matristeki hücreler, kuruluşun kendisinin ve rakiplerinin ürünlerinin müşteri beklentilerini karşılama durumunu belirlemek için kullanılır. Bu hücrelere 1-5 arası puanlar verilerek, farklı ürünlerin farklı beklentileri karşılama dereceleri saptanır (1=en kötü, 5=en iyi).
  • Teknik Bazlı Rekabet Matrisi: Teknik tanımların, piyasadaki farklı ürünler üzerindeki etkilerinin gözlenmesi amacıyla oluşturulan matristir. Kalite evinin giriş katını oluşturan bu bölüm, ilişki matrisinin altına çizilen satırlardan meydan gelir. Her teknik tanımın farklı ürünle eşleştirilmesiyle oluşan hücrelere 1-5 arası puanlar verilir.

Rekabet matrisleri kuruluşun kendi ürününün piyasadaki yerini görmesi açısından büyük önem taşır. Kalite evinin farklı yerlerinde bulunmalarına rağmen her iki matris de birbirleriyle orantılıdır. Müşteri beklentilerini fazlasıyla karşılayabilen bir ürünün teknik tanımlar bakımından da diğer ürünlere göre üstün olması gerekir. Eğer yapılan değerlendirmeler sonucunda çıkan yorum bu teorinin aksini işaret ediyorsa, değerlendirmenin hatalı olduğu söylenebilir.

Aşama 6: Öncelikli Müşteri İsteklerinin ve Teknik Özelliklerin Belirlenmesi

Önceliklendirilmiş müşteri beklentileri, kalite evinin sağ tarafında müşteri bazlı rekabet matrisine bitiştirilmiş kolonlarda ifade edilir. Bu kolanlar müşteri için önem değeri, hedef değer, scale-up faktörü, satış noktası ve mutlak ağırlık olarak sınıflandırılmıştır.

  • Önem Değeri: Kalite fonksiyon yayılımı ekibinin, müşteri beklentilerinden hangilerinin önemli hangilerinin önemsiz olduğunu belirlemek amacıyla oluşturacağı bu kolon 1’den 10’a en önemsizden çok önemliye doğru puanlandırılır. Beklentilerin önceliklendirilmesi hangi alanlara daha çok ağırlık verilmesi gerektiğini belirler ve trade-off kararlarının alınmasını kolaylaştırır.

 

  • Hedef Değer: Hedef değer kolonunun puanlanma yöntemi müşteri bazlı rekabette olduğu gibi 1-5 arasındadır (1-en kötü, 5-en iyi). Bu bölüm kalite yayılım fonksiyonu ekibinin ürün için yapmayı planladığı değişiklikleri gösterir.
  • Scale-Up Faktörü: Scale-up faktörü hedef değerin, müşteri rekabet matrisindeki ürün puanına oranıdır. Bu değerlendirmenin amacı ürünün şu andaki seviyesiyle hedeflenen seviyesinin arasındaki farkın görülmesi ve geri kalınmış ya da eksik olan karakteristiklerin belirlenmesidir. Bu aşamada dikkat edilmesi gereken husus hedef değerinin gerçekçi olarak tespit edilmesidir. Aksi takdirde ortaya çıkacak olan scale-up faktörü yanıltıcı olacaktır ve bu da kuruluşun yanlış alanlarda zaman kaybetmesine yol açar.

 

  • Satış Noktası: Satış noktası, ürünün piyasadaki satış performansının ve ürüne olan ilginin göstergesidir. Bu değer ürünün satışını etkileyebilecek müşteri beklentilerinin belirlenmesi amacıyla kullanılır. Satış noktası için optimal bir değer tespit edildikten sonra puanlama bu normalize edilmiş değer üzerinden yapılır.
  • Mutlak Ağırlık ve Oran: Bu son kolon; önem değeri, scale-up faktörü ve satış noktası değerlerinin çarpılmasıyla hesaplanır.

Mutlak ağırlık = (önem değeri) * (scale-up faktörü) * (satış noktası)

Mutlak ağırlık değeri tüm müşteri beklentileri için ayrı ayrı hesaplandıktan sonra, beklentiler arasındaki oran rahatlıkla gözlenebilir. Mutlak ağırlık değerleri ve beklentiler arasındaki oranlar planlama aşamasında ve ürünün geliştirilmesinde dikkate alınması gereken en önemli verilerdir.

Anlatılanların genel olarak kalite evi üzerinde gösterimine bakacak olursak daha iyi kavranılabilir.

Teorik bilgi dışında örnek uygulamaların/hesaplamaların olduğu kaynakları ve yazımda yararlandığım kaynakları sizlerle paylaşmak istiyorum. Umarım faydası olur 🙂

Kaynakça : https://industryolog.com/kalite-evi/

Örnek Uygulama 1: http://mmfdergi.uludag.edu.tr/article/viewFile/5000082727/5000076927

Örnek Uygulama 2: https://view.officeapps.live.com/op/view.aspx?src=http://debis.deu.edu.tr/userweb/k.yaralioglu/dosyalar/kal_fonk.doc

Örnek Uygulama 3: http://www.capital.com.tr/gelecek-trendler/kalite-evi-nasil-calisir-haberdetay-1816

Mock Up ve WireFrame Araç Önerileri

16 Şub

difference-wireframe-between-mockup

 

Yazılım projelerinde arayüz gereksinimlerini dokümante etmek gerektiğinde uzun zaman alan sayfalarca analiz dokümanı üretmek yerine geliştirme çalışmalarında yaşanacak değişiklikleri de en aza indirecek ekran tasarımı taslak çizim programları kullanmak benim önerimdir. İşte araştırmalarımla ulaştığım araçlar öneri sırasına göre aşağıdaki gibidir.

 

https://www.axure.com/

 

https://balsamiq.com/

 

http://mockupbuilder.com/

 

https://mockflow.com/

 

https://www.lucidchart.com

 

https://gomockingbird.com/home

 

https://www.invisionapp.com/

 

https://www.uxpin.com/

 

https://proto.io/

 

https://moqups.com/

 

https://www.mockplus.com

 

https://www.justinmind.com/

 

https://marvelapp.com/

 

http://origami.design/

Yazılım Performans Testi Hakkında

10 Kas

Performans Testi Nedir ?

 

Performans testi, sistemin belirli durumlarda, belirlenen beklentileri verip vermediğini kontrol etmek amacıyla yapılan testtir. Performans testi sistemdeki bug’ ların bulunmasını amaçlamaz ancak sistemdeki darboğazları ortaya çıkarır.

 

Performans testi aşağıdaki soruların cevaplarını verir:

 

  • Sistem trafiğindeki artışlar; işlem süresini ve güvenliğini nasıl etkiler?
  • Hangi kullanıcı seviyesinde performans problemleri yaşanır?
  • Performans seviyelerindeki düşüş sistemin hangi bileşeninden kaynaklanır?
  • Normal şartlar altında sistem nasıl davranıyor?

 

Yazılım Mühendisliği’nde, performans testlerinin amacı, bir sistemin kritik derecede önemli ve yüksek riskli bileşenlerinin, belirli bir iş yükü altında nasıl çalıştığının belirlenmesidir. Ölçeklenebilirlik, güvenilirlik ve kaynak kullanımı gibi sistemin önemli kalite özelliklerini doğrulamak için yapılan performans testlerini gerçekleştirmek, sürdürülebilirlik anlamında bir zorunluluktur.

 

Performans Testinin Kapsamı;

 

  1. Test Stratejisinin Belirlenmesi
  2. Yük Seviyelerinin Belirlenmesi
  3. Performans Test Ortamının Hazırlanması
  4. Yük Senaryolarının Hazırlanması
  5. Testlerin Uygulanması ve Raporlanması

 

 

Temel olarak 3 çeşit performans testi bulunmaktadır. Bunlar;

 

Performans Testi: Uygulamalarının normal şartlar altındaki performans seviyelerinin belirlenmesi.

Load Testi: Uygulamaya giderek artan sayıda(sistem çökene kadar) virtual user la yüklenilerek sistemin sınırlarının ölçülmesi.

Stress Testi: Maksimum sayıdaki kullanıcı ile periyodik bir şekilde sisteme yüklenilmesi. Bir kaos ortamında sistemin bu tür durumlara verdiği tepkiyi ölçmek ve arıza giderildiğinde sistemin toparlama seviyesini belirlemektir.

 

Performans testi aslında yük testini ve tunning’i kapsayan bir işlemler bütünüdür. Amacı ise, sistemin belirli bir yük altındaki performansının ölçülmesi ve istenilen performansa ulaşmasının sağlanmasıdır. Sistemin ağır yük altındaki dar boğazlarının, kod ve veritabanı gibi sistemlerle çözülmesini amaçlamaktadır.

 

Yük Testi:

Yük testi sistemin ne kadar yükte maksimum performans ile çalıştığının bilgisini veren test tipidir. Sistemin ne kadar yüke tahammül edebildiğini anlamak için yapılır.

Yük testinin amacı, sistemin yük altındaki davranışlarının ve hatalarının ortaya çıkarılmasını sağlamaktır. Her ne kadar performans testinin bir parçası olsa da, kimi zamanda sistemin “sağlamlığını” test etmek için yapılır.

Yük testi sayesinde, performans testi tamamlanmış bir sistemin ihtiyacı olan load balancing sunucuları ya da gerekli donanımın belirlenmesi kolaylaştırılmıştır.

 

Araç seçiminin yapılması:

Değişik ortamlarda değişik toollar kullanmak gerekmektedir.

  • .net uygulamar için visual studio team suit in içindeki performans toolları bulunmaktadır.
  • Java uygulamaları için birçok open source tool bulunmaktadır.Bunlar araasında en çok kullanılanın OPENSTA(open system testing architecture)olduğu belirtilmektedir. Ayrıca java uygulamaları için ücretli bir tool olan IBM Rational Performance bulunmaktadır.
  • Borland SilkPerformer
  • Hp LoadRunner

 

 

Testin Uygulanması:

 

Gerekli senaryoları ve toolu seçtikden sonra(TSE IBM Rational kullanıyor) execute bu sürecin en kolay bölümlerinden biridir. Belirlediğiniz senaryoları toolunuz da bulunan kayıt bölümünden bir kere yaparak kayıt edebilirsiniz. Daha sonra sonuç verilerini alabilmek için test ortamına gerekli collectorları bağlamanız gerekmektedir. Bu işlemi de gercekleştirdikten sonra bir case inizi test amaclı bir kere run edip dataları alabildiğinizi gördükden sonra, belirlediğiniz kullanıcı sayılarını toola girip caselerinizi sadece run tuşuna basarak execute edebilirsiniz.

 

Test sonuçlarının incelenmesi ve yorumlanması:

 

Performans ve Yük Testi Sırasında Aşağıdaki Dokümanlar Üretilir:

Test Durum Dokümanları

  • Sistemin dar boğazları
  • Sistemin response-request zamanları
  • Sistem için ideal yük
  • Sistemin kaldıracağı maximum yük
  • Sistem için ideal bant genişliği
  • Sistemi yayınlayacak server için ideal donanım yapısı

 

Yazılım Geliştirme Süreci ve Güvenli Yazılım Geliştirme

14 Ara

Yazılımların hayatımızdaki yeri ve öneminin gün geçtikçe artması yazılımlara ilişkin çalışmaları hızlandırmakta, bu durum yeni yazılım geliştirme yöntemleri, programlama kuralları veya programlama dilleri ve araçları ortaya çıkarmaktadır. Tüm bu gelişmelere rağmen yazılım projelerinde tasarlanan zamanın gerisinde kalma, bütçeyi aşma, düşük kalite, sürekliliği ve güvenilirliği sağlayamama, kullanıcı taleplerinin karşılanmasında yetersizlik gibi problemlerle sıkça karşılaşılmaktadır. Gartner araştırmasına göre bilişim güvenliği ihlallerinin yazılım güvenliği problemlerinden kaynaklananlarının oranı %80’dir [1]. Genel olarak problemlerin çoğu, yazılım geliştirme sürecinin en başında gereksinim ve sistem analizlerinin doğru ve yeterli yapılmamasından kaynaklanmaktadır. Analiz konusunda yetersiz kalan yazılımlar güvenlik riski oluşturmakta, bu durum bilgiye yönelik tehditlerin ortaya çıkmasında önemli bir açıklık oluşturmaktadır.

Bilginin gizliliği, bütünlüğü ve erişilebilirliğini, kısaca bilgi güvenliğini hedefleyen tehditlerle mücadele için yazılımlarda bilgi güvenliğinin sağlanmış olması gerekmektedir. Bilgi güvenliği;  karşılaşılabilecek tehditlerin farkında olunması,  işlerin devamlılığını sağlama, yaşanabilecek her türlü problemlerde kayıpları en aza indirme, firmaların varlıklarının her koşulda gizliliği, erişebilirliği ve bütünlüğünü korunma amaçları taşımaktadır. Bu kapsamda ortaya çıkartılan ve sürekli geliştirilmekte olan bir süreç de “Bilgi Güvenliği Yönetim Sistemi (BGYS)” dir.

Yazılımlarda bilgilerin korunması yazılımın geliştirme sürecinin başından itibaren tüm aşamaların bilgi güvenliği kontrollerine uygun olarak gerçekleşmesine bağlıdır. Yazılımın geliştirme sürecinde bilgi güvenliği yönetim sisteminin sağlanmış olması, yazılımlardaki bilgilerin kullanıma hazır olduğunu, sadece yetkisi olanların erişebildiğini ve kullanılan bilginin doğru ve güncel olduğu anlamına gelmektedir.

Bu çalışmanın ikinci ve üçüncü bölümünde yazılım, yazılım geliştirme süreçleri ve güvenli yazılım geliştirmeye ilişkin bilgilere yer verilecektir. Dördüncü bölümde uluslararası bir standart olan “ISO/IEC 27001 Bilgi Teknolojileri- Güvenlik Teknikleri-Bilgi Güvenliği Yönetim Sistemi- Gereksinimler Standardı (ISO 27001)” ele alınacak, sonrasında ISO 27001’in yazılım geliştirme süreçleriyle ilişkili kontrol maddelerine ve sonuç bölümüne yer verilecektir.

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

Yazılım kelimesinin sözlük anlamına bakıldığında; yazılım, “bir bilgisayarda donanıma hayat veren ve bilgi işlemde kullanılan programlar, yordamlar, programlama dilleri ve belgelemelerin tümü” olarak ifade edilmektedir [2] . Yazılım ayrıca, mevcut bir problemi çözmek amacıyla değişik cihazların birbirleriyle haberleşebilmesini sağlayan ve görevlerini ya da kullanılabilirliklerini geliştirmeye yarayan bilgisayar dili kullanılarak oluşturulmuş anlamlı ifadeler bütünü olarak da nitelendirilebilir [3]. Yazılım ile ilgili bu tanımlamalar daha çok kod ile ilgilenirken yazılım geliştirme, bilinenin aksine sadece kodlama değildir. Birkaç tane kullanıcı ekranı tasarlayıp, bu ara yüzlerin arkasına kod yazarak ve veritabanı ilişkisi kurularak yazılım geliştirme süreci tamamlanamaz. Bu işlemler yazılım geliştirme sürecinin sadece bir bölümü olup, toplamda yazılım geliştirme süreci kodlama yapmaktan çok daha fazlasıdır [4]. Bu bakımdan yazılım geliştirme, yazılımın hem üretim hem de kullanım süreci boyunca geçirdiği tüm aşamalar olarak tanımlanabilir.

Geçmişte yazılım geliştirmede başvurulan iş akış şemaları gibi yöntemler günümüzde gereksinimleri karşılayamadıklarından etkinliklerini yitirmişlerdir. Bu yöntemler özellikle güvenlik odaklı olmadıklarından yetersiz kalmışlardır. Yazılımın her aşamasında güvenliğe ilişkin ortaya çıkabilecek problemleri gözeten etkin bir geliştirme süreci sonuç ürünün daha güvenilir olmasına önemli katkı sağlayacaktır.

Yazılım işlevleri ile ilgili gereksinimler sürekli olarak değiştiği ve genişlediği için, söz konusu aşamalar sürekli bir döngü biçiminde ele alınmaktadır. Böylece döngü içerisinde her hangi bir aşamada geriye dönmek ve tekrar ilerlemek söz konusudur [5]. Yazılım geliştirmede çok sayıda farklı model ve süreç değerlendirmelerinden söz etmek mümkündür. Bununla birlikte; yazılım mühendisliğindeki diğer modellere temel teşkil eden “Çağlayan Modeli (Waterfall Model)” yazılım yaşam döngüsünü analiz, tasarım, kodlama, test ve bakım olmak üzere beş aşamada ele almaktadır [6].

Analiz

Bir problemin çözümü olarak nitelediğimiz yazılımların ne yapacağını ve nasıl yapacağını belirlediğimiz yani problemi tanımladığımız aşama analiz aşamasıdır. Yazdığınız kod ancak isteneni doğru bir biçimde yerine getiriyorsa başarılı bir yazılımdır. Bu nedenle öncelikle yazılımdan ne istendiğinin doğru bir biçimde tanımlanması gerekir. Analiz aşaması personel, donanım ve sistem gereksinimlerinin belirlenmesi, sistemin fizibilite çalışmasının yapılması, kullanıcıların gereksinimlerinin analizi, sistemin ne yapıp ne yapmayacağının kısıtlamalar göz önüne alınarak belirlenmesi, bu bilginin kullanıcılar tarafından doğrulanması ve proje planı oluşturulması adımlarından oluşur.

Tasarım

Analiz aşaması sonucunda belirlenen gereksinimlere yanıt verecek yazılımın temel yapısının oluşturulduğu aşamadır. Yazılım tasarımı, bir bileşen veya sistemin nasıl gerçekleştirileceğini belirlemek için kullanılan teknikler, stratejiler, gösterimler ve desenlerle ilgilidir. Bu aşama yazılım bileşenleri arasındaki içsel ara yüzler, mimari tasarım, veri tasarımı, kullanıcı ara yüzü tasarımı, tasarım araçları ve tasarımın değerlendirilmesi alt süreçlerini de kapsamaktadır. Tasarım aşaması, yazılımın hem kullanıcı ara yüzünü hem de programın omurgasını ortaya koymaktadır. Yapılacak tasarım, yazılımın işlevsel gereksinimlere uygun olmasının yanı sıra kaynaklar, performans ve güvenlik gibi kavramları da göz önüne alınarak gerçekleştirilmelidir.

Kodlama

Kodlama aşaması, tasarım sürecinde ortaya konan veriler doğrultusunda yazılımın gerçekleştirilmesi aşamasıdır. Bu süreç programlama çalışmalarının yanı sıra yazılımın geliştirilmesi ve kullanıcıya ulaştırılması sürecindeki bütün çalışmaları kapsar. Tasarım sonucu üretilen süreç ve veri tabanının fiziksel yapısını içeren fiziksel modelin bilgisayar ortamında çalışan yazılım biçimine dönüştürülmesi çalışması olarak da nitelendirilebilir [5]. Yazılım geliştirme ortamı, programlama dili, veri tabanı yönetim sistemi, yazılım geliştirme araçları seçimi kodlama aşamasında gerçekleştirilir.

Test

Test aşaması, yazılım kodlanması sürecinin ardından gerçekleştirilen sınama ve doğrulama aşamasıdır. Elde edilen uygulama yazılımının hem belirlenen gereksinimleri sağlayıp sağlamadığı hem de gerçekleştirimin beklentilere uygun olup olmadığını kontrol etmek için statik ve dinamik sınama tekniklerinden yararlanır. Statik teknikler, yazılımın tüm yaşam döngüsü boyunca elde edilen gösterimlerin analizi ve kontrolüyle ilgilenirken, dinamik teknikler sadece gerçekleştirilmiş sistemi içerir. Yazılım üretiminde ilk testler genelde geliştirme sürecinde programcı tarafından yapılır. Bununla birlikte, asıl hata ayıklama ve geribildirim hizmeti test ekipleri tarafından yapılır. Testler ve geribildirim müşteri yazılımı kullandığı sürece devam eder. Test sürecinde en faydalı geribildirimler son kullanıcı test gruplarından gelir.

Bakım

Yazılımın tesliminden sonra hata giderme ve yeni eklentiler yapma aşamasıdır. Yazılımın kullanıma başlanmasından sonra yazılımın desteklenmesi sürecini kapsar. Yazılımın eksiklerinin giderilmesi, iyileştirilmesi gibi alt aşamaları içeren aşamadır.

Güvenli Yazılım Geliştirme

Yazılımların yaygın olarak kullanılmaya başlandığı ilk yıllarda kaliteli ve olgun yazılım üretmek, son yıllarda ise özellikle güvenli yazılım geliştirmek için çok sayıda model ve çerçeve üzerinde çalışılmıştır. Bu durumun en büyük tetikleyicisi son yıllarda güvenlik açıklıklarının artmasıdır [7]. Artan bu güvenlik tehditleri Şekil 1’de görüldüğü üzere hiç hesaba katılmayan sürpriz maliyetleri de beraberinde getirmektedir. Yazılım geliştirmede erken bir süreçte farkına varılan yazılım açıklıklarının düzeltilmesinin daha ileri süreçlerde farkına varılan açıklıklara göre daha az maliyetli olacağı yazılım endüstrisince yaygın olarak kabul edilen bir ilkedir [8]. Bu ilke yazılım geliştirme sürecinin güvenli olmasının maliyet açısından da ne denli önemli olduğunun göstergesidir.

ekil_1.jpg

Şekil 1 – Yazılım Geliştirme Süreçlerinde Yazılım Açıkları Giderme Maliyeti [8]

Yazılım güvenliği kavramı ile ilgili yapılan en önemli yanlış güvenliği sadece kodun güvenliği ve ek olarak da yetkilendirme güvenliği ile sınırlandırmaktır. Halbuki yazılım güvenliği kavramını “güvenilir bilişim” (trusted computing) kavramı ile yakından ilişkilendirmek gerekmektedir. “Trusted Computing Group” tarafından konmuş olan güvenilir bilişim kavramı gizlilik, bütünlük, erişebilirlik, ve kurtarılabilirlik olmak üzere dört temel kavram üzerinde durmaktadır [9].

Güvenli yazılım geliştirme süreçlerinde ayrıca değişiklik ve konfigürasyon yönetimi, geliştirme, test ve üretim ortamı ayrışımı, geliştirme ortamında gerçek verilerin kullanılmaması, üretim ortamına almadan önce kod incelemesi, güvenli programlama teknikleri kullanımı, uygulama güvenlik duvarı kullanımı ya da kaynak kod inceleme hizmeti alınması gibi çalışmaların yapılması da güvenliğe ayrıca katkı sağlayacaktır [1].

Güvenli yazılım geliştirme sürecinde ele alınması gereken temel olarak dokuz ana güvenlik konusu vardır [10]:

1.Girdi Geçerleme (Input Validation):

Günümüzde bilinen ve gelecekte de muhtemel tehditlerin çoğu kötü niyetli girdi ile başlamaktadır. Bununla birlikte; basit girdi geçerleme yöntemleri ile büyük güvenlik tehditlerinin önlenmesi mümkündür.

Girdi geçerleme yöntemlerini “beyaz kutu” ve “kara kutu” olmak üzere ikiye ayırmak mümkündür. Beyaz kutu yönteminde bilinen bir şablon girdi olarak kullanılmakta, bu şablonun dışındaki tüm girdiler kötü niyetli olarak kabul edilmektedir. Şablonun kontrolü çok kolay olduğundan bu yöntem oldukça etkili bir yöntemdir. Kara kutu yöntemi ise daha az etkili olmasına rağmen daha çok tercih edilen bir yöntemdir. Bu yöntemde kullanılan belirli bir şablon yoktur, sadece bilinen saldırıların bir listesi mevcuttur. Eğer girdi bilinen bir saldırıya benziyor ise o zaman girdi reddedilecek, onun dışındaki tüm girdiler ise kabul edilecektir. Bugün bile tüm atak çeşitlerini belirlemek zor iken gelecekteki atakları bilip filtrelemek daha da zor olacağından bu yöntemin etkinliğinin az olduğu açıktır. Dolayısıyla veri yapıları, mümkün olduğunca belli bir şablona uygun tasarlanarak geçerleme daha güçlü kılınmalıdır.

İstemci-sunucu uygulamalarında geçerleme hem istemci hem de sunucu tarafında yapılabilmektedir. Bununla birlikte; bir saldırgan istemci tarafındaki geçerleme kontrolünü kolay aşabileceğinden istemci tarafındaki geçerleme hiçbir zaman yeterli bir güvenlik önlemi olarak ele alınmamalıdır. Bunun yerine daha çok sunucu tarafında geçerleme kontrolü yapılarak güvenlik seviyesi arttırılmalıdır. Kısaca güvenilir olmayan bir kaynaktan (örneğin kullanıcıdan) gelen veri mutlaka onaylanmalıdır.

2.Kimlik Doğrulama (Authentication):

Kimlik doğrulama,  varlıkların (kullanıcı, cihaz veya bir uygulama) kimlik kontrolünden geçmesi işlemidir ve farklı kimlik doğrulama yöntemleri bulunmaktadır.

Genellikle yazılımlar önceleri sadece kullanıcı adı ve şifre kullanması şeklinde zayıf doğrulama yöntemleri kullanılmakta idi. Eğer bir “domain” yapısı varsa, kullanıcılar “Active Directory” kullanılarak doğrulanmakta, “domain” dışında ise kimlik yönetimine ilişkin veritabanı uygulanmaktadır. Daha güçlü doğrulama yöntemleri olarak da biometrik metotlar veya akıllı kartlar kullanılmaktadır. Bir diğer doğrulama yöntemi ise üçüncü bir tarafın doğrulama işini yapması ve bu üçüncü tarafa güven duyulması şeklindedir.

3.Yetkilendirme (Authorization):

Kullanıcıların tanımlanması aşaması olan kimlik doğrulamadan sonra kullanıcının kimliği doğrultusunda erişim haklarının belirlendiği ve kontrolünün gerçekleştiği aşama yetkilendirmedir. Hangi yetkilerle işlem yapılacağını belirlemek için bir çok yöntem bulunmaktadır.

4.Konfigürasyon Yönetimi  (Configuration Management):

Konfigürasyon, uygulama ile ilgili hassas bilgileri içermektedir. Örnek vermek gerekirse veri tabanına erişim için gerekli bağlantı bilgilerini içeren dosyalar bu kapsamdadır. Konfigürasyona müdahale uygulamanın işleyişini değiştirebilir veya çalışmamasına sebep olabilir. Konfigürasyon dosyalarının sunucularda saklanıyor olması yeterli güvenlik önlemlerinin alındığı anlamına gelmemektedir. Konfigürasyon dosyaları hassas bilgi olarak nitelendirilmeli, şifrelenmiş bir şekilde tutulmalı ve bu dosyalara erişim kayıt altında tutulmalıdır.

5.Hassas Bilgi (Sensitive Information):

Hassas bilginin ne olduğunun belirlenebilmesi için uygulamanın ve işin bir arada ele alınması gerekir. Uygulama geliştirici işin niteliğini tam olarak bilemediğinden, diğer yandan işin sahibi de uygulamanın teknik altyapısı hakkında sınırlı bilgiye sahip olacağından bu iki taraf tek başlarına hassas bilgi için yeterli tanımlama yapamayacaklardır. İki tarafın bir araya gelmesiyle hassas bilgileri içeren bir liste oluşturulmalı ve bu listeyi koruyacak bir politika oluşturulmalıdır.

6.Kriptografi (Cryptograhy):

Veriyi korumanın yollarından biri de şifrelemedir. Bugün şifreleme çalışmaları oldukça ilerlemiş, bilgisayarlar oldukça gelişmiştir. Fakat bu durum saldırganlar için de geçerlidir. Hassas bilgiler bilinen ve test edilmiş şifreleme yöntemleri ile saklanmalıdır. Ayrıca daha önce kırılması uzun zaman alan algoritmalar günümüzde daha kısa zamanda çözülebilmektedir. Dolayısıyla uygulama içindeki algoritmalar zamanla gözden geçirilmeli ve güncellenmelidir.

7.Parametre Manipülasyonu (Parameter Manipulations):

Dağıtık algoritmalar modüller arasında parametre gönderirler. Eğer bu parametreler arada değiştirilirse, saldırı gerçekleştirilmiş olur. 1 dolara satın alınan Ferrari bu duruma bir örnektir. Borcun belirlenmesi için web formu kullanan uygulama bu formdaki rakamın http proxy kullanılarak manipüle edilmesi sonucu değer 1 dolara olarak değiştirilmiştir.

8.Hata Yönetimi (Exception Management):

Bazı teknolojiler hataları kullanarak hata yönetimi gerçekleştirmektedirler. Hatalar geliştiriciler ve sistem yöneticileri için uygulama ile ilgili birçok önemli bilgi ihtiva ettiği için çok önemlidirler. Bununla birlikte; geliştirici için bu derece önemli olan bilgi kullanıcı açısından problem oluşturabilmektedir. Her ne kadar kullanıcılar bu hataların ne demek olduğunu anlamasalar da saldırganlar için büyük ipuçları, yazılımla ilgili önemli bilgiler içermektedir. Bundan dolayı sadece genel bir hata mesajının dönmesi, hataların kayıt altında tutulması ve gerçek hataya sadece yöneticiler ulaşmasını sağlayacak sürecin oluşturulması gerekmektedir.

9.Kayıt Tutma ve Denetim (Logging and Auditing):

Uygulama veya uygulamanın yöneticileri saldırı altında olduklarını anlamalıdır. Bu durum aslında neyin normal neyin anormal olduğunun belirlenmesi ile sağlanır. Bir uygulamaya ilişkin normal süreç ve şablon tanımlanmalı ve bunu dışında bir olay olduğunda saldırı ihtimali ele alınmalıdır. Örneğin, normal senaryoda bir uygulamaya dakikada ortalama beş kişinin erişmesi beklenirken bu sayı bine ulaşıyorsa muhtemelen bir “Servis Dışı” bırakma atağı söz konusudur.

Yukarıdaki ve bunlara benzer onlarca tehdit güvenilir uygulamalar geliştirmek için yazılım geliştirme sürecinin güvenliğinin yönetilmesinin büyük önem arz etmekte olduğunu gözler önüne sermektedir.

ISO 27001 Bilgi Güvenliği Yönetim Sistemi

Bilgi güvenliği, yazılı, sözlü, elektronik ortam gibi farklı ortamlardaki bilginin gizlilik, bütünlük ve erişebilirlik bakımından güvence altına alınması ve bu güvence durumunun sürekliliğinin sağlanmasıdır.

Bilgi sistemlerinin hayata geçmesiyle ortaya çıkan depolama ve işleme imkânlarının artması, izinsiz erişimler, bilginin yetkisiz imhası, yetkisiz değiştirilmesi veya yetkisiz görülmesi ihtimallerinin artması gibi hususlar nedeniyle bilgi güvenliği kavramı gündeme gelmektedir.

Bilgi hangi biçime girerse girsin veya ne tür araçlarla paylaşılır veya depolanır olursa olsun, her zaman uygun bir şekilde korunmalıdır. Bilgi sistemlerinin çoğu, bilgi saklanırken, paylaşılırken, gönderilirken güvenlik kaygıları düşünülerek tasarlanmamıştır. Kurumların sahip oldukları bilgi doğru tasarlanmamış sistemler nedeniyle pek çok çeşitli tehditlere karşı açık durumdadır.

Bilgi güvenliği ihlali ve buradan doğacak kayıpların riskini minimize etmek kurulan sistemlerin en başında BGYS gelmektedir. BGYS, bilgi güvenliğini kurmak, işletmek, izlemek ve geliştirmek için iş riski yaklaşımına dayalı, dokümante edilmiş, işlerliği ve sürekliliği garanti altına alınmış bir yönetim sistemidir.

BGYS kurumunuzdaki tüm bilgi varlıklarının değerlendirilmesi ve bu varlıkların sahip oldukları zayıflıkları ve karşı karşıya oldukları tehditleri göz önüne alan bir risk analizi yapılmasını gerektirir [11].

BGYS, bağımsız kuruluşların ya da tarafların ihtiyaçlarına göre özelleştirilmiş güvenlik kontrollerinin gerçekleştirilmesi için gereksinimleri belirtir. BGYS’nin ihtiyaç duyduğu gereksinimlere cevap vermek için çok sayıda standart vardır. Bunların en önde geleni ISO 27001 standardıdır.

PUKÖ Modeli

ISO 27001 kurumların bilgi güvenliği yönetim sistemi kurmaları için gereklilikleri tanımlayan tek denetlenebilir BGYS standardıdır. ISO 27001 ülkelere göre özel tanımlar içermeyen, genel tanımların bulunduğu uluslararası standardıdır. ISO 27001 standardı; kuruluşların kendi bilgi güvenlik sistemlerini sağlamasını mümkün kılan teknoloji tarafsız, satıcı tarafsız yönetim sistemleri için bir çerçeve sağlar.

ISO 27001, kuruma uygun politikalar, prosedürler ve kılavuzlar oluşturmaya yol gösteren uluslararası kabul görmüş yapısal bir metodoloji sunar. ISO 27001 sertifikası, kurumların güvenlik seviyesine ve kurumun konuya ciddi yaklaşımına ilişkin bir göstergedir.

Bilgi güvenliği yönetimi konusunda ilk standart British Standard Institute (BSI) tarafından geliştirilen BS 7799’dur. BS 7799  “Pratik Kurallar” ve “BGYS Gerekleri” başlıklı iki kısımdan oluşmaktaydı. BS 7799 birinci kısım daha sonra ISO tarafından 2000 yılında “ISO 17799” olarak kabul edilmiştir. 2002’de BSI; BS 7799-2’yi çıkartmıştır. ISO, 2005 yılında ISO/IEC 1799:2005’i ve BS 7799-2’nin yeni hali olan ISO/IEC 27001:2005’i yayınlamıştır. ISO 27001, 2005 yılında yayınlanmasıyla yürürlüğe girmiş ve ISO/IEC 27000 standart serisi altında yerini almıştır. Söz konusu bu standart 2006 yılında Türk Standardı olarak kabul edilerek, ”TS ISO/IEC 27001 Bilgi Teknolojisi – Güvenlik Teknikleri – Bilgi Güvenliği Yönetim Sistemleri – Gereksinimleri” adıyla yayınlanmıştır [12].

ISO 27001 yaşayan, dolayısı ile tehdit ve saldırılara reaksiyon gösteren ve kendini yenileyen bir bilgi güvenliği sisteminde yer alması gereken öğeleri tanımlamaktadır [13]. ISO 27001, BGYS’yi kurmak, işletmek, izlemek, gözden geçirmek, sürdürmek ve iyileştirmek için standart proses yaklaşımını benimsemiştir. Bu proses yaklaşımı güvenlik önlemlerinin belirlenip kurulması, uygulanması, etkinliğinin gözden geçirilmesi ve iyileştirilmesi süreçlerini ve bu süreçlerin sürekli olarak tekrarlanmasını içerir. Bu süreçler Planla, Uygula, Kontrol et, Önlem al (PUKÖ) döngüsünden oluşan bir model olarak da ortaya konmuştur.

BGYS’de kurum kendine bir risk yönetimi metodu seçmeli ve risk işleme için bir plan hazırlamalıdır. Risk işleme için standardda öngörülen kontrol hedefleri ve kontrollerden seçimler yapılmalı ve uygulanmalıdır. Şekil 2’de gösterilen PUKÖ Modeli uyarınca risk yönetimi faaliyetlerini yürütmeli ve varlığın risk seviyesi kabul edilebilir bir seviyeye geriletilene kadar çalışmayı sürdürmelidir [11].

ekil_2.jpg

Şekil 2- BGYS’nin PUKÖ Modeli [13]

PUKÖ Model’inin süreçleri aşağıdaki gibidir:

Planla: BGYS’nin kurulması

Sonuçları kuruluşun genel politikaları ve amaçlarına göre dağıtmak için, risklerin yönetimi ve bilgi güvenliğinin geliştirilmesiyle ilgili BGYS politikası, amaçlar, hedefler, prosesler ve prosedürlerin kurulması.

Uygula: BGYS’nin gerçekleştirilmesi ve işletilmesi

BGYS politikası, kontroller, prosesler ve prosedürlerin gerçekleştirilip işletilmesi.

Kontrol Et: BGYS’nin izlenmesi ve gözden geçirilmesi

BGYS politikası, amaçlar ve kullanım deneyimlerine göre proses performansının değerlendirilmesi ve uygulanabilen yerlerde ölçülmesi ve sonuçların gözden geçirilmek üzere yönetime rapor edilmesi.

Önlem Al: BGYS’nin sürekliliğinin sağlanması ve iyileştirilmesi

BGYS’nin sürekli iyileştirilmesini sağlamak için yönetimin gözden geçirme sonuçlarına dayalı olarak, düzeltici ve önleyici faaliyetlerin gerçekleştirilmesi [12].

ISO 27000 Ailesi

Bilgi güvenliği ile ilgili olarak ISO 27000 serisi güvenlik standartları, (Şekil 3) kullanıcıların bilinçlenmesi, güvenlik risklerinin azaltılması ve de güvenlik açıklarıyla karşılaşıldığında alınacak önlemlerin belirlenmesinde temel bir başvuru kaynağıdır. Bu standartlar temel ISO’nun 9000 kalite ve 14000 çevresel yönetim standartlarıyla da ilgilidir [12].

ISO 27000 standardı, ISO 27000 standartlar ailesi ile ilgili kavramların açıklanmasını sağlayan ve bilgi güvenliği yönetimine yönelik temel bilgileri içeren bir standarttır. ISO 27000 standartlarının büyük bir çoğunluğu bilenen, diğerleri ise basım aşamasında olan standartlar olarak verilebilir.

ISO/IEC 27000 standart serisi altında yer alan ve ISO 27001 için gereken güvenlik kontrollerini içeren standart; ISO/IEC 27002:2005 – Bilişim Teknolojisi – Güvenlik Teknikleri – Bilgi Güvenlik Yönetimi için Uygulama Kılavuzu’dur. Bu standardın önceki adı ISO/IEC 17799:2005’dir. 1 Temmuz 2007 tarihinde, ISO tarafından yapılan teknik bir düzenlemeyle ISO/IEC 17799:2005 standardının adı, ISO/IEC 27002:2005 (ISO 27002) olarak değiştirilmiştir [14].

ekil_3.jpg

Şekil 3- ISO 27000 Standart Ailesi [15]

Güvenlik Kontrol Alanları

ISO 27001’de BGYS oluşturmada güvenlik için gereken 11 kontrol alanı, 39 kontrol hedefi ve 133 kontrolü tanımlayan bir uygulama kılavuzudur. Bu kontrol alanları aşağıda kısaca açıklanmaktadır [16]:

  1. Güvenlik Politikası: Bilgi güvenliği için yönetimin desteğini ve katılımını sağlamak, bilgi güvenliğinin önemini vurgulamak
  2. Bilgi Güvenliği Organizasyonu:  Bilgi güvenliğinin koordinasyonu ve yönetimi için bir yönetim çerçevesi geliştirmek, bilgi güvenliği için sorumlulukları tahsis etmek
  3. Varlık Yönetimi: Tüm kritik veya hassas varlıklar için uygun bir koruma düzeyi belirlemek
  4. İnsan Kaynakları Güvenliği: Kullanıcı eğitimini ve bilincini teşvik ederek hırsızlık, dolandırıcılık veya bilgisayar kaynaklarının kötüye kullanılma riskini azaltmak
  5. Fiziksel ve Çevresel Güvenlik: Kuruluşun tesislerindeki bilgi işlem olanaklarına yetkisiz erişimi önlemek ve bilgilerin zarar görmesini engellemek
  6. Haberleşme ve İşletim Yönetimi: Bilgi işlem tesislerinin uygun ve güvenli kullanımını sağlamak ve olay müdahale prosedürleri geliştirerek riski ve sonuçlarını azaltmak
  7. Erişim Kontrolü: Yetkisiz erişimlerin tespiti ve ağ sistemlerinin korunması için gerekli kontrol faaliyetlerini sağlamak
  8. Bilgi Sistemleri Edinim, Geliştirme ve Bakımı: İşletim sistemleri ve uygulama yazılımlarını bilgi kaybına karşı güncellemek ve kayıpları engellemek
  9. Bilgi Güvenliği İhlal Olayı Yönetimi: Etkin bir bilgi güvenliği sağlamak için olayların zamanında tespit etmek ve gerekli önlemleri almak
  10. İş Sürekliliği Yönetimi: Kritik arızalar, olaylar, doğal afetler, felaketlerden kaynaklanan kesintilere karşı hızla müdahale edilebilmek için kapasite geliştirme faaliyetleri gerçekleştirmek
  11. Uyum: Mevcut güvenlik politikalarının tüm yasalara ve yönetmeliklere uygun olduğundan ve üst yönetim onayından geçtiğinden emin olmak

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

ISO 27001, gerek yazılım geliştirme süreçleriyle doğrudan ya da dolaylı ilişki içerisinde olan birçok kontrol içermektedir. Bu kontroller ve kontrol kapsamında yazılım geliştirme süreci aşamalarında gerçekleştirilmesi gereken hususlar aşağıdaki gibidir.

Analiz Aşamasına İlişkin Kontroller

Yazılım geliştirme sürecinin en önemli aşamasıdır. Bu aşamada yapılacak yanlışlıklar yazılım projesinin başarısını en yüksek düzeyde etkilemektedir.

Bu aşamada kurumun mevcut bilgi teknolojileri, varsa sistem veri tabanı yapısı, sistem veri yapıları tanımlanmalıdır. Kullanıcı uygulama ihtiyaçları doğrultusunda yazılım ihtiyaç tanımları, veri yapılarını güncelleyen giriş bilgileri, uygulama yazılım ara yüz tanımları, yazılımın üreteceği çıktı bilgileri, yazılım için istenen sorgular gibi tanımlar belirlemelidir.

Yapılacak analiz, uygulama servislerinin performans ya da kısıtlamalar yönünden zorlanması ve doğru hizmet vermelerini engelleme girişimlerini de hesaba katmalıdır. Sunucu tarafındaki konfigürasyonların güvenli şekilde yapılması gerekir.

Yazılım için devreye alınacak yeni bilgi sistemleri için iş gereksinimleri bildirgeleri ya da mevcut bilgi sistemlerine yapılan iyileştirmeler güvenlik kontrolleri için gereksinimleri belirlemelidir. (A.12.1.1 – Güvenlik gereksinimleri analizi ve belirtimi) Yeni bilgi işleme tesisleri için, bir yönetim yetki prosesi tanımlanmalı ve gerçekleştirilmelidir. (A.6.1.4 – Bilgi işleme tesisleri için yetki prosesi)

Yetkilendirilmiş kullanıcıların sistemde neler yapabileceği uygun şekilde belirtilmelidir, aksi durumlarda başka kullanıcı haklarını kullanma, yetkisiz olduğu halde verilere erişebilme gibi sakıncalar doğabilir. Kuruluş içinden ya da dışından sağlanmış olsun tüm ağ hizmetlerinin güvenlik özellikleri, hizmet seviyeleri ve yönetim gereksinimleri tanımlanmalıdır. (A.10.6.2 – Ağ hizmetleri güvenliği)

İletişimin bütün türlerinin kullanımıyla ve bilgi değişimini korumak için resmi değişim politikaları, prosedürleri ve kontrolleri oluşturulmalıdır. (A.10.8.1 – Bilgi değişim politikaları ve prosedürleri)

Yazılımda kullanılacak harici materyaller için fikri mülkiyet haklarına göre materyallerin kullanımı ve patentli yazılım ürünlerinin kullanımı üzerindeki yasal, düzenleyici ve anlaşmalarla doğan gereksinimlere uyum sağlanmalıdır. (A.15.1.2 – Fikri mülkiyet hakları (IPR))

Kuruluşun dış taraflarla yapacağı bilgi ve yazılım değişimi için anlaşmalar yapılması gerekir, bu gereksinim analiz aşamasında karşılanmalıdır. (A.10.8.2 – Değişim anlaşmaları)

Tasarım Aşamasına İlişkin Kontroller

Tasarım aşamasında, uygulanacak geliştirme safhaları, her safha için girdiler, çıktılar ve kontrol metotları, iş zaman planları, uygulama planlarının yanı sıra yapılacak işlerin neler olduğu, bu işler için gerekli zaman ve kaynak ihtiyaçlarının tespiti, ilerlemenin izlenmesi için kullanılacak metotlar belirlenmelidir.

Tüm yazılım kullanıcıları için her türlü yazılım sistemine erişim kullanıcı isimleri ve şifreler ile sağlanmalı, bu şifre ve kullanıcı isimleri her kullanıcı için tek ve benzersiz olacak şekilde tasarlanmalıdır. Tasarımda kullanıcılar işlevlerine ve sorumluluk alanlarına göre gruplandırılmalı, grup bazında programlara ve veri tabanlarına erişim hakları verilerek yetkisiz kişilerin sistemi kullanmasına imkân verilmemelidir. Uygulama içinde çalışmalar her zaman menüler yardımıyla olmalı, kullanıcı programları kullanırken hiçbir zaman uygulamanın sağladığı komutlar dışına çıkma olanağı bulmamalıdır.

Bilgi sistemlerinin birbirine bağlantısı ile ilişkili bilgiyi korumak için politikalar ve prosedürler geliştirilmeli ve gerçekleştirilmeli, bilgi sızması fırsatları önlenmelidir. (A.10.8.5 – İş bilgi sistemleri, A.12.5.4 – Bilgi sızması ) Bu kapsamda tasarım aşamasında yüksek riskli uygulamalara ek güvenlik sağlamak için bağlantı sürelerinde sınırlandırmalar kullanılması gerektiği hesaba katılmalıdır. (A.11.5.6 – Bağlantı süresinin sınırlandırılması)

Tehditlerden korunmak için ve iletilmekte olan bilgi dâhil ağı kullanan sistemler ve uygulamalar için güvenliği sağlamak amacıyla ağlar uygun şekilde yönetilmeli ve kontrol edilmelidir. (A.10.6.1 – Ağ kontrolleri) Kullanıcılar ve destek personeli tarafından bilgi ve uygulama sistem işlevlerine erişim, oluşturulması önerilen tanımlanmış erişim kontrol politikasına uygun olarak kısıtlanmalıdır. (A.11.6.1 – Bilgi erişim kısıtlaması)

Kodlama Aşamasına İlişkin Kontroller

Yazılımlarda kodlamalar yapılırken güvenli yazılım kodlama teknikleri kullanılmalıdır.

Yazılımlar, modüler planlanmalı, modüler arası ilişkilerde yapısallık göz önünde bulundurulmalı ve programcı müdahalesi asgari seviyede olacak şekilde parametrik hazırlanmalıdır. Sisteme yeni modülerin ilavesi, modüllerin değiştirilmesi ya da silinmesi durumda sistemin bütünü etkilenmemelidir. Yazılımlarda kullanılacak menü, dosya, alan, değişken, tablo gibi her türlü isim anlamlı olarak seçilmelidir.

Aynı veri veya bilginin farklı veritabanı tabloları için ayrı ayrı girilmesine engel olunmalıdır (Normalizasyon). Tutarsız kod ve verilerin girişine engel olacak tedbirler alınmalı, veri tipleri ile kullanıcıların giriş yaptıkları alanların birbirleri ile tutarlı olma durumu kod içinde yapılan düzenlemeler ile giriş anında kontrol edilmelidir. Hata yapma olasılığı yüksek verilerin girildiği alanlar için liste veya seçenek kutuları kullanılmalıdır.

Özellikle web yazılımının kullanıcı bilgisayarında bir atak aracı olarak kullanılan çapraz site betiklerine (Cross side scripting) ve kontrolü ele almak üzere tamponların taşırılması gibi tehditlerden doğabilecek hatalar uygun bir şekilde kontrol edilmelidir. Kontrol edilmeyen hatalar dış dünyaya sistem ile ilgili bilgiler verebilir ve yeni açıklara zemin hazırlayabilmektedir.

Yazılımların karşılaştığı en önemli tehditlerden biri uygulamalarda gerçekleşen veri giriş-çıkışında kontrollerin tam ve sağlıklı olarak yapılmadan işleme alınması ya da çıktı olarak verilmesidir.  Uygulamalara gerçekleşen veri girişinin, bu verinin doğruluğunun ve uygunluğunun geçerlenmesi gerekmektedir. Yazılımda girdi parametreleri yazılım dışından verilebilir olmamalıdır. Kayıt olanakları ve kayıt bilgisi kurcalanma ve yetkisiz erişime karşı korunmalıdır. (A.10.10.3 – Kayıt bilgisinin korunması) Böyle bir koruma olmaması durumunda SQL (Structed Query Language) enjekte etme ve komut enjekte etme gibi yöntemlerle sistemlere girebilecek kodlar büyük zararlar verebilir. (A.12.2.1 – Giriş verisi geçerleme) Giriş verisi kadar çıkış verisi de önemlidir. Yazılımda çıkış verisi sistemimiz hakkında bilgi vermemeli veri sızıntısına açıklık bırakmamalıdır. Bir uygulamadan gerçekleşecek veri çıktısı, depolanan bilginin işlenmesinin koşullara göre doğruluğunun ve uygunluğunun sağlanması için geçerlenmelidir. (A.12.2.4 – Çıkış verisi geçerleme) Veri işleme hataları veya kasıtlı eylemler nedeniyle herhangi bir bilgi bozulmasını saptamak için geçerleme kontrolleri uygulamalar içine dâhil edilmelidir. (A.12.2.2 – İç işleme kontrolü)Uygulamalarda verinin kimliğinin doğruluğunu sağlama ve mesaj bütünlüğünü koruma gereksinimleri tanımlanmalı bunlarla ilgili uygun kontroller tanımlanmalı ve gerçekleştirilmelidir. (A.12.2.3 – Mesaj bütünlüğü)

Kötü niyetli koda karşı korunmak için saptama, önleme ve kurtarma kontrolleri ve uygun kullanıcı farkındalığı prosedürleri gerçekleştirilmeli, elektronik mesajlaşmadaki bilgi uygun şekilde korunmalıdır. Benzer bir biçimde mobil kod kullanımı yetkilendirildiğinde, konfigürasyon yetkilendirilmiş mobil kodun açıkça tanımlanmış bir güvenlik politikasına göre işletilmesini sağlamalı ve yetkilendirilmemiş mobil kodun yürütülmesi önlenmelidir. (A.10.4.1 – Kötü niyetli koda karşı kontroller, A.10.8.4 – Elektronik mesajlaşma, A.10.4.2 – Mobil koda karşı kontroller)

Kriptografi teknikleri yazılımlarda güvenliği sağlamada faydalanılan önemli tekniklerdir. Bilginin korunması için kriptografik kontrollerin kullanımına ilişkin bir politika geliştirilmeli ve gerçekleştirilmelidir. (A.12.3.1 – Kriptografik kontrollerin kullanımına ilişkin politika) Kriptografi için yeterli rastgeleliği sağlayan kriptografik tekniklerin kullanım desteklenmeli ve anahtar yönetimi bulunmalıdır. (A.12.3.2 – Anahtar yönetimi)

Yazılım geliştirme hizmetinin kuruluş dışından sağlanması durumunda, hizmeti sunan şirketin hareketleri ve yaptığı işler denetlenmeli ve izlenmelidir. (A.12.5.5 – Dışarıdan sağlanan yazılım geliştirme) Yazılım geliştiricilerce gerçekleştirilen ve revizyon kontrolü yapılmayan yazılım değişiklikleri karmaşaya ve çeşitli sorunlara neden olabilmektedir. Yazılım değişikliklerin gerçekleştirilmesinde resmi değişim kontrol prosedürlerinin kullanılması bu karmaşayı ortadan kaldıracaktır.(A.12.5.1 – Değişim kontrol prosedürleri)

Test Aşamasına İlişkin Kontroller

Kodlama aşamasından sonra gerçekleştirilecek test aşamasında yazılım uygulaması modüllerinin nitelik ve nicelik testleri yapılır. Geliştirme, test ve işletim olanakları, işletilen sisteme yetkisiz erişim veya değişiklik risklerini azaltmak için ayrılmalıdır. (A.10.1.4 – Geliştirme, test ve işletim olanaklarının ayrımı)

Bu aşamada bir test planı oluşturulmalı bu planda; test senaryoları, veri çeşitleri ve veri örnekleri ve test tasarım tanımlamaları ayrıntılı olarak belirtilmelidir. Test,   proje yöneticisi ve kullanıcı yetkilileri tarafından koordine ile programcı ve tasarımcılarla, gerçek kullanıcılar tarafından yapılmalıdır. Sistemin bütünü göz önünde bulundurularak modüllerin amaçlanan fonksiyonları tam ve etkin olarak yerine getirip getirmediği, birbiri ile entegre çalışıp çalışmadığı, veri alışverişi (varsa) yapıp yapmadığı kontrol edilmelidir.

Veri tabanının büyüklüğü ve listelenen, sorgulanan kayıt sayısı ile sistemin performans ilişkisi kontrol edilmelidir.  (A.12.2.1 – Giriş verisi geçerleme, A.12.2.4 – Çıkış verisi geçerleme, A.12.2.2 – İç işleme kontrolü) Test verisi dikkatlice seçilmeli, korunmalı ve kontrol edilmelidir. (A.12.4.2 – Sistem test verisinin korunması)

Yazılım ürünlerinin,   sistemin ve alt sistemlerin modül,   fonksiyon,   entegrasyon ve performans testlerinden sonra testlerde ortaya çıkan değerlere uygun olarak gerçek bilgi ve verilerle, gerçek kullanıcı donanım ve işletim ortamında tüm ihtiyaçların karşılandığı kontrol edilmelidir.

Revizyon istekleri göz önüne alınarak gerekli düzeltme ve düzenleme işlemleri yapılır. Entegrasyon, performans ve revizyon testleri tamamlandıktan sonra başlar. Test süresi tüm ihtiyaçların tamamlandığı ve kontrolü yapıldıktan sonra biter.

Test aşaması bitip uygulama devreye alınırken tüm çalışanlar, yükleniciler ve üçüncü taraf kullanıcıların bilgi ve bilgi işleme olanaklarına olan erişim hakları, istihdam, sözleşme veya anlaşmalarının sonlandırılmasıyla birlikte kaldırılmalı ya da değiştirilmesiyle birlikte ayarlanmalıdır. (A.8.3.3 – Erişim haklarının kaldırılması)

Bakım Aşamasına İlişkin Kontroller

Yazılım geliştirme sürencin son aşaması, bakım aşamasında da alınması gereken bir takım güvenlik önlemlerinden söz etmek mümkündür.

Yazılım paketlerine yapılacak değişiklikler, belirli bir incelemeden geçirilmeli, gerek duyulanlar gerçekleştirilmeli, bunun dışındakiler önlenmelidir. Tüm değişiklikler sıkı bir biçimde kontrol edilmelidir. (A.12.5.3 – Yazılım paketlerindeki değişikliklerdeki kısıtlamalar) Benzer bir biçimde kullanıcıların erişim hakları da resmi bir proses kullanarak düzenli aralıklarda gözden geçirmelidir. (A.11.2.4 – Kullanıcı erişim haklarının gözden geçirilmesi)

Yazılım Kaynak kodlarının bozulma riskini azaltmak ve bilgi kaybından korumak amacı ile kaynak kodları yazılım uzmanlarının işletim sistemleri içinde değil sunucu terminal üzerinde bulunmalıdır. Program kaynak koduna erişim kısıtlı olmalıdır. (A.12.4.3 – Program kaynak koduna erişim kontrolü) Söz konusu ortama erişim yalnızca ilgili yazılım uzmanı tarafından sağlanmalıdır.

Donanım arızaları, yazılım hataları, insandan kaynaklanan nedenler ve doğal afetler yazılımlarda bilgi kayıplarının ana sebepleridir.  Sebep her ne olursa yedekleme yazılımlarda hatalardan ve problemlerden geri dönüş için son derece önemlidir. Yedekleme için kurtarılabilir veri saklama yöntemleri uygulanmalı, bilgi ve yazılımlara ait yedekleme kopyaları düzenli olarak alınmalı ve alınan yedekler belirlenecek bir politikaya göre uygun şekilde düzenli olarak test edilmelidir. (A.10.5.1 – Bilgi yedekleme)

Belirlenmiş bir ön yetkilendirme olmaksızın teçhizat, bilgi veya yazılım bulunduğu yerden çıkarılmamalıdır. (A.9.2.7 – Mülkiyet çıkarımı) Eğer yetkilendirme varsa ve bilgi içeren ortamın, kuruluşun fiziksel sınırları ötesinde taşınması söz konusu ise taşıma esnasında, bilgiler yetkisiz erişime, kötüye kullanıma ya da bozulmalara karşı korunmalıdır. (A.10.8.3 – Aktarılan fiziksel ortam)

Bilgisayar donanımlarının depolama ortamı içeren tüm parçaları, elden çıkarılmadan önce, herhangi bir hassas veri ve lisanslı yazılım varsa kaldırılmasını veya güvenli şekilde üzerine yazılmasını sağlanmalıdır. (A.9.2.6 – Teçhizatın güvenli olarak elden çıkarılması ya da tekrar kullanımı)

Kurumların ve şirketlerin operasyonel sistemlerindeki yazılımların kurulmasını kontrol etmek için prosedürler bulunmalıdır.(A.12.4.1 – Operasyonel yazılımın kontrolü)

Zayıf parolalar ve şifreler bilişim sistemleri açısından önemli açıklıklar ortaya çıkarmaktadır. Kullanıcılardan, parolaların seçiminde ve kullanımında iyi güvenlik uygulamalarını izlemeleri istenmelidir. Bu ve bunun gibi hususlar için bilinçlendirme çalışmaları yapılmalı eğitimler verilmelidir. (A.11.3.1 – Parola kullanımı)

İşletim sistemleri değiştirildiğinde, kurumsal işlemlere ya da güvenliğe hiçbir kötü etkisi olmamasını sağlamak amacıyla iş için kritik uygulamalar gözden geçirilmeli ve test edilmelidir. (A.12.5.2 – İşletim sistemindeki değişikliklerden sonra teknik gözden geçirme)

Sonuç

Kurumların güvenli bir ortamda faaliyet gösterebilmeleri için dokümante edilmiş bir BGYS’yi hayata geçirmeleri gerekmektedir. Bu kapsamda ISO 27001 standardı tüm dünyada kabul görmüş ve en iyi uygulamaları bir araya getiren bir modeldir. Standart bu yönetim sistemini oluştururken ele aldığı önemli alanlardan biri de yazılım geliştirme süreçlerinde güvenliğinin sağlanması ve buna ilişkin olarak yazılım geliştirme politikasının oluşturulmasıdır. Yazılım geliştirme süreçlerinde standardın belirttiği gizlilik, bütünlük ve erişebilirlik kavramları mutlaka dikkate alınmalıdır. Bu kapsamda, yazılım geliştirmenin her aşamasında belirli bir güvenlik politikasının uygulanması kritik önem taşımaktadır. Kurumsal güvenlik için öncelikle yazılı olarak kurallar belirlenmelidir. Etkin bir BGYS kurmaya çalışan ve bunu ISO 27001 standardına uyumlu yapmak isteyen tüm kurumların oluşturacağı bu politikada belli kontrol maddeleri asgari olarak yer almalıdır.

Dr. İzzet Gökhan Özbilgin, Sermaye Piyasası Kurulu; Mustafa Özlü, Türk Patent Enstitüsü

Kaynak: https://www.bilgiguvenligi.gov.tr/yazilim-guvenligi/yazilim-gelistirme-surecleri-ve-iso-27001-bilgi-guvenligi-yonetim-sistemi.html

Orman ve Su İşleri Bakanlığı Bilgi İşlem Dairesi Proje Yönetim Süreci ve Süreç Tanımlama Projesi Sunumu

24 Eki

Orman ve Su İşleri Bakanlığı Bilgi İşlem Dairemizdeki çalışma arkadaşlarımıza, daha verimli çalışmamız için Yeni Proje Yönetim Süreci ve Süreç Geliştirme Projesini anlattık, Başarılı projeler için yola çıkmış olduk.

f

Yaptığımız sunumda hedeflerimizi, yol haritamızı ve proje planını paylaşmış olduk.

cc

vv

rr

Kamuda İnovasyon

20 Tem

Kamuda İnovasyon

Kamu kurumlarında,
•daha fazla değer yaratmak,
•sorun çözmek,
•ihtiyaçlara daha etkin cevap vermek,
•kaynakları en etkin ve verimli şekilde kullanmak,
•mensuplarının ve vatandaşların yaşam kalitesini yükseltmek amacıyla

hizmetleri, ürünleri ve bunların sunuluş biçimlerini; süreçleri ve organizasyonu iyileştirmeye ve geliştirmeye odaklı fikirlerin geliştirilip uygulanması faaliyetidir.

Küreselleşmeye bağlı ekonomik ve toplumsal gelişmeler, iş dünyası için olduğu kadar kamu kurumları için de üstesinden gelinmesi gereken önemli güçlükleri ve yakalanması gereken fırsatları beraberinde getirmektedir. Küresel pazarlar, uluslararası ortaklıklar, dış kaynak kullanımları, uluslararası rekabet ve buna bağlı müşterilerin değişen ve artan talepleri firmaların hızla inovasyon yapmalarını gerektirirken, yine çoğunlukla küreselleşmeye atfedilen gelişmeler ve vatandaşların beklenti ve taleplerindeki artış, kamu kurumlarında da inovasyonu kaçınılmaz kılmaktadır. Birleşmiş Milletler’e göre bu zorunluluk üç ana boyutu ilgilendirmektedir:
1.Daha az kaynak ve sınırlı operasyonel kapasiteyle çok daha geniş kesimlere daha yüksek kalitede hizmet sağlama gereği (ki bu, kaynakların daha etkin kullanımı ve kapasitenin daha etkin oluşturulmasıyla sınırlı kalmayıp daha yaratıcı ve farklı çözümlerin geliştirilmesini de gerektirmektedir),
2.Vatandaş-yönelimli kamu yönetimiyle daha hesap verebilir, sorumluluk sahibi ve etkin bir yapıya kavuşma zorunluluğu,
3.Vatandaşların taleplerine daha iyi yanıt verme gereği.

Kamu kurumlarında inovasyon kültürünü oluşturmayı ve inovasyon yönetim sistemlerini kurmayı gerektiren bu zorunluluklar, yeni bir yönetim yaklaşımının benimsenmesini, yeni iş yapış yöntemlerinin oturtulmasını, farklı prensiplerin ve stratejilerin geliştirilip uygulanmasını kaçınılmaz hale getirmektedir. Yeni kamu yönetim yaklaşımı da bu gerekliliklerden yola çıkılarak benimsenmeye başlanan bir olgudur.

Kaynak: http://www.inomer.org/Inovasyon/Kamuda-Inovasyon

CBAP Uluslararası İş Analisti Sertifikasyonu

13 Mar

Uluslararası İş Analisti Sertifikasyonu

Uluslararası İş Analisti Sertifikasyonu (CBAP:Certified Business Analysis Professional) hakkında bazı bilgiler:

Sertifika sınav ile alınıyor. Sınava katılmak için belli şartlar var:
* Başvuru tarihinden geriye son 10 yıl içerisinde 7500 saatlik ilgili alanda iş tecrübesi.

(Aşağı yukarı 4 yıla denk geliyor)

* 6 alanın en az dördünde tecrübe. (Enterprise Analysis, Requirements Planning & Management, Requirements Elicitation, Requirements, Analysis & Documentation, Requirements Communication, Solution Assessment & Validation)

* Üniveriste veya dengi mezun olmak.

* 21 saatlik profesyonel eğitim.

* 2 referans (Yönetici, Müşteri ya da CBAP Sertifikalı Çalışanlardan)

Sınav Başvuru Ücreti (2012): 125 $

Başvuruda, daha önce görev yapılan projelerdeki çalışmaların saat bazında ve iş tipi (analiz/test/tasarım) bazında belirtililmesi isteniyor.

***Bu süreç PMP süreciyle çok benzer.*****

Özgeçmiş detayı ile analiz tipindeki işlerin süresi uyuyuyorsa, başvuru kabul edilebiliyor.
Başvuru değerlendirme süresi 1-1,5 ay sürebiliyor.

Başvurusu kabul edilen üyeler sınav ücretini yatırıp Belirtilen sınav merkezinde düzenlenen çevirim içi sınavlara katılıyor.

Sınav Ücreti (2012):
İlk kez başvururanlar: 325.00 $ (IIBA® üyeleri için), 450.00 $ (IIBA® üyesi olmayanlar),
İkinci kez başvuranlar: 250.00 $ (IIBA® üyeleri için), 375.00 $ (IIBA® üyesi olmayanlar)
(IIBA üyeliği: yıllık 75 $)

Eğitim Kurumu Tavisyeleri

http://www.kaid.com.tr

Kamuda Bilgi Teknolojileri ve Proje Yönetimi

23 Şub

Kamuda Bilgi Teknolojileri ve Proje Yönetimi

Gelişen teknolojinin iş hayatında daha fazla kullanılmasıyla beraber bilgi teknolojileri projeleri de gerek harcanan kaynaklar gerekse zaman olarak kurumların üzerinde önemle durması gereken konulardan biri olmaya başlamıştır. Günümüzde, her sektörden çoğu kurumda bilgi teknolojileri projeleri yürütülmekte ve bu projelerin sonuçları stratejik öneme sahip olmaktadır. Bu nedenle kurumların BT proje süreçlerini kendi yapılarına, kabul görmüş uygulamalara ve mevcut kaynaklarına göre tasarlaması ve uygulanmasının süreklilik kazandırılması gerekmektedir. Zira içinde bulunan durumun ve hedeflenen amacın iyi analiz edilmesine rağmen kurum gerçeklerine ve teknoloji gereklerine göre yanlış seçilen yol amacımızdan bizi uzaklaştırabilecektir.

Kurum içi görevlerimiz kapsamında Bilgi Teknolojileri faaliyetlerimizi ayrı olarak değerlendirdiğimizde de bu konunun kendine özgü kritik boyutları olduğunu görüyoruz. Teknolojinin hızlı ve sürekli gelişmesinin yanı sıra BT yatırımlarının maliyeti, kaynakların niteliği ve güvenlik unsurları her zaman tekrar tekrar değerlendireceğimiz kritik boyutlar olarak karşımıza çıkmaktadır. Bu nedenle günlük BT operasyonel işlerimiz veya uzun soluklu projelerimizde bu kritik boyutların etkisinin derinlemesine incelenmesi gerekmektedir. Günümüzde teknolojinin imkânları sayesinde iş hayatındaki çoğu iş süreçlerini dijital ortama aktarma kabiliyetinde olabilsek de bu dönüşüm çalışmalarında başarı için belirlenen bu kritik boyutların üzerinde durmamız gerekmektedir.

BT çalışmalarının kendine ve uygulandığı kuruma özgü gerçekleri ve yine BT çalışmalarının üstlendiği stratejik sorumluluklar sebebiyle BT çalışmalarının ve BT projelerinin yönetiminin ayrı bir öneme sahip olduğu görülebilmektedir.

Öyle ki yanlış yatırım tercihleri, operasyonel işlerin yanlış yönlendirilmesi ve uzun sürelerde yoğun emek sarfiyatıyla ortaya çıkan işlerin kullanılamaması sorunlarıyla karşılaşılabilmektedir. Bu sorunlarla karşılaşma ihtimalinin en aza indirilmesi için izlenmesi gerekli yol da belirlidir. Bu yol, üzerinde uzun zamandır kafa yorulmuş global en iyi uygulamaları içerdiği gibi uygulanacak kurum ve sektör gerçekleriyle tecrübenin harmanlamasıyla elde edilebilecektir.

Burada bahsedilen doğru BT Proje Yönetimine yol göstermek ve yönetişimi sağlamaya yönelik pratikte kullanılmakta olan pek çok standart vardır. Bu standartların bir kısmı genel olarak proje yönetimini hedeflerken bazıları da bilgi güvenliği ve BT hizmet sunumu gibi özel konulara odaklanmaktadır. Örneğin “Project Management Institue(PMI)” tarafından yayımlanan “Project Management Body Of Knowledge(PMBOK)” sadece sektör bağımsız proje yönetimini tariflerken “Information Technology Infrastructure Library (ITIL)” ve “Control Objectives for Information and Related Technology (COBIT)” BT Hizmet Yönetimi, Güvenlik ve diğer BT Operasyonu için kontrol noktaları ve ideal süreç tanımları sunmaktadır.

Bu standartların her biri çok detaylıdır ve etkin bir şekilde organizasyonlar içerisinde anlaşılmaları ve uygulanmaları oldukça karmaşıktır. O nedenle, organizasyonların BT projelerinin başarılı olması için gerekli kontrolleri tüm standartları inceleyerek ortaya koyacakları pratik araçlara ihtiyaç vardır. Bu araçların kuruma özgü, kurum BT profosyonelleri tarafından kurum stratejik hedeflerine uygun hazırlanması gerekmektedir.

Stratejik hedeflerden bağımsız yürütülen BT projeleri bir noktada stratejik hedeflerde ulaşılmak istenen amaçtan uzak kalabilmektedir. Öyle ki Bilgi Teknolojileri organizasyonu her zaman kurumun ihtiyaçlarına en kısa sürede en kaliteli şekliyle cevap vermesi beklenen birimlerdir. Kurumun stratejik hedefi daha fazla insana aynı anda bir çok online hizmeti, sorunsuz, kesintisiz ve güvenli vermek şeklinde tanımlanırken BT organizasyonunun bu hedefleri bilmeyerek altyapısında ve kaynaklarında gerekli yatırım ve planlamayı yapmaması ilerleyen zamanda büyük riskler oluşturacaktır.

Bu nedenle BT projelerinin başarılı olabilmesi için BT çalışmalarının stratejik hedeflerinin belirgin, çalışma kurallarının da belirli iş ihtiyaç ve öncelikleriyle ilişkili olarak kurgulanması gerekmektedir.

Bizler de her ne kadar iyi projelerimizi nihai sonuçları aklımızda olarak başlatsak da ideal olan BT Proje Yönetim süreçlerimizi tanımlayarak çalışmalarımıza başlıyoruz. Tabi ki bu süreçlerimiz de yukarda bahsedildiği gibi kurumun stratejik hedefleri doğrultusunda bizim kurumumuzda bağlı olduğumuz en üst amirimize onaylatılarak işletilmeye başlanıyor.

Belirlenen proje yönetim sürecimiz işimizin detaylı olarak ne olduğu ve niçin yapıldığının detaylı tarfiyle başlıyor bu şekilde kapsamı net belirliyoruz. Belirlenen kapsamla da planlama yapabiliyoruz. Plan gerçeğin anlatımı değil de geleceğin nasıl olabileceğine dair bir görüş olduğundan bu görüşümüz üstünde risklerimizi, sorunlarımızı ve aksiyonlarımızı belirliyoruz. Sonrasında da belirlenen işleri iyi takip etmek ve sorunları çözmek için harcadığımız çabayla yolumuza devam ediyoruz.

Bu süreç içerisinde dijital dönüşüm projelerine özgü olarak öncelikle yapılacak çalışmalarda iş süreçlerinin mevcut durumunun detaylarını ve açık noktalarını kavramak daha sonra bu süreçleri iyileştirerek daha sorunsuz, hızlı, verimli, tutarlı ve güvenli iş süreçleri tasarlayıp kullanılabilir bir şekilde dijital ortamda geliştirme yapıp kullanıma almak benimsediğimiz ideal yol haritası oluyor. Bu şekilde amaçladığımız işi daha doğru ve kullanılabilir elde etmiş olduğumuzu yapılan işlerin detayındaki faydadan anlayabiliyoruz. Bu tür projelerde bizlerin üzerinde durduğu en önemli konu işin niteliği ve kullanılabilirliği olduğundan kullanıcılarımızla onların ihtiyaçlarını ve beklentilerini detaylı konuşabileceğimiz çalıştaylar yapıyoruz.

Tüm süreçlerimizde işin nihayetinde de sadece kalite kontrol aşamasından geçirdiğimiz işleri kullanıma alarak kendimizden emin, görevimizi başarılı yapabilmenin verdiği rahatlıkla projelerimizi kapatıyoruz. Bu anlattığım süreci her uyguladığımızda paydaşlarımızdan her zaman olumlu yorumlar almakta ve ortaya çıkan sonuçlarla da izlediğimiz yönetimi her seferinde daha iyiye doğru geliştirebiliyoruz.

Aslında bizim kurumumuzda proje yöneticileriyle ve onların da yönetimiyle yapmaya çalıştığımız ve önerdiğimiz şey bir orkestra şefi olmaktan farklı bir şey değil. Bilgi Teknolojileri Proje Yönetimi de bir orkestra şefi gibi bizim için; gerekli kaynakları bir araya getirdikten sonra belirlenen görevlerde ekibin uyumlu çalışmasını sağlayıp duymayı arzu ettiğimiz sesi dinlemeyi başarmaktır.

Kaynak: http://www.bthaber.com/kamuda-bilisim-teknolojileri-ve-proje-yonetimi

Yazılım Testi Metodolojileri

5 Oca

Yazılım Testi Metodolijileri – Yazılım Test Metodları

 

Yazılım testi kullanmak, yazılım geliştirme yaşam döngüsünün önemli parçalarından biridir. Etkin ve efektif test kodu oldukça önemlidir. Peki yazılım testi ne demektir ?

Yazılım testi, önceden belirtilen gereksinimleri karşılayıp karşılamadığını, doğru çıktıyı üretip üretmediğinikontrol eden yapıdır. Çok sayıda test durumu ve test stratejisi hazırlanır, bu testlerin hepsi belirli hedefleri (tüm sorunları kaldırmak,yazılımın hatasız çalışmasını sağlamak ve en iyi çıktıyı elde etmek) için uğraşır. Çok sayıda test tekniği ve metodolojisi bulunur. Yazılım test metodolojisi, yazılım testi tekniklerinden farklıdır.

 

 

Yazılım Test Metodları

Black-Box Test

Black-box test kod ya da tasarım ile ilgilenmez. Testler gereksinim ve fonksiyonellik üzerinedir. Black-box test aynı zamanda, Fonksiyonellik testi, Closed Box testi ya da Opaque testi olarak adlandırılır.

Black-Box testi, fonksiyonelliğe uygun veri seçimine ve seçilen verinin programın normal ve ya anormal davranış gösterimini izleme temeline dayanır.

Black-Box test stratejisinde, kullanıcı sistemin gereksinimlerini ve bu gereksinimlere nasıl cevap vereceğini bilmelidir. Black-Box testlerini iki gruba ayırabiliriz, bunlardan biri kullanıcı gereksinimi duymayan testler, diğeri ise kullanıcının gerekli olduğu testlerdir.

 

Kullanıcı Gereksinimi Duymayan Test Metodları

  • Fonksiyonellik Testi: Fonksiyonel gereksinimleri test etmek için yazılmıştır.Eğer uygulama beklendiği gib davranırsa,testlerin yazılmasına sıralı bir şekilde devam edilir.

 

  • Stres Testi: Çok sayıda veri girişi,büyük nümerik değerler,çok sayıda sorgu olduğu zaman kullanılır ve uygulamanın dayanıklılığını belirler.

 

  • Yükleme Testi: Bir sistemin performansını derecelendirmek ve ya ağır yükler ve çok sayıda veri girişinde sistemin hangi noktada çakılacağını tespit etmek için kullanılır.

 

  • Ad-Hoc Testi: Geçerli bir test yaratılmadan önceden kullanım için uygundur. Bu test diğer testlerin kapsama alanını ve diğer testlerin süresinin belirlenmesinde yararlı olur.

 

  • Araştırma Testi: Ad-Hoc testine benzer ve uygulamayı öğrenmemizi sağlar. Uygulama hakkkında ön bilgimiz olur.

 

  • Kullanılabilirlik Testi: Kullanıcı dostu test olarakta bilinir. Eğer kullanıcı arayüzü önemli bir yere sahipse ve ihtiyaçlar belirli bir kullanıcıya göre belirleniyorsa uygundur.

 

  • Duman Testi: Mantık testi olarakta bilinir.Bu test,uygulamanın büyük testlere hazır olup olmadığını belirler ve küçük testleri başarı ile geçtiğini gösterir.

 

  • Yenilenme Testi: Uygulamanın herhangi bir hataya karşı ne kadar sürede eski haline geleceğini test eder.Sistem gereksinimlerine göre,tip ve yenileme hızı belirlenir.

 

  • Seviye Testi: Uygulamanın etkinliği ile ilgilenir.Uygulama tarafından çok büyük veri işlemi yapılırken, sistemin uç limitlerini kontrol eder.

 

 

Kullanıcının Gerekli Olduğu Testler

  • Kullanıcı Kabul Testi: Kullanıcının sistemi test edip, gereksinimleri karşılayıp karşılamadığının incelenmesini sağlar.

 

  • Alfa Testi: Kullanıcı geliştirme merkezine çağrılır. Geliştiriciler programı kullanır ve program hakkında not alır ya da kullanıcı işlemleri gerçekleştirir.

 

  • Beta Testi: Kullanıcılara beta versiyon dağıtılır ve test etmesine izin verilir. Kullanıcılar sistemi inceler,herhangi bir sorun bulduğunda,geliştiriciye bildirir.

 

 

White-Box Test

Uygulamanın kodunu temel almaktadır.Kodun koşullarını, alanlarını ve açıklamalarını temel alır. White-Box testi, cam, açık kutu, temiz kutu olarak adlandırılmaktadır. Bu testte, testi yapan kişi sorunlu kısmı bulmak için kodu incelemelidir.

 

 

Avantajları

  • Kodun optimizasyonunu sağlar.
  • Ekstra kod parçasını kaldırır ve tek bakışta gözükmeyen sorunları ortaya çıkarır.
  • Hangi verinin kodu en iyi şekilde test edeceğini tespit eder.

 

 

Dezavantajları

  • Belirli özelliklere sahip test yapıldığında maliyet artar.
  • Kodun inceleyip tek tek hata bulmak çok zor bir işlemdir.

 

 

White-Box Test Metodları

  • Birim Test: Çalışan bir kod parçası ya da modül için, geliştiriciler tarafından gerçekleştirilir.Düşük seviyede işlem gerçekleştirir.

 

  • Statik ve Dinamik Analiz: Statik analiz kodu sıralı bir şekilde inceler ve hataları araştırır. Dinamik analiz,kodun çalışmasını ve çıktıyı analiz eder.

 

  • Açıklama Kapsamı: Açıklamaların test edilmesiyle ilgilenir.Her bir açıklama en az bir kez test edilir. Tüm açıklamaların sorun yaşamadan çalıştığını garanti altına alır.

 

  • Sınıf Kapsamı: Hiçbir yazılım uygulaması sürekli olarak kodlanmaz, bazı noktalarda, kodun dağılışı incelemeli ve belirli bir fonksiyonu çalıştırılmalıdır. Tüm sınıflar doğrulanmasına yardım eder ve uygulamanın anormal davranış göstermesini engeller.

 

  • Güvenlik Testi: Sistemin izinsiz erişimler, kod bozulması, hacklenme gibi olaylardan nasıl korunacağı ile ilgilenir. Karmaşık test metotları gerekir.

 

  • Değişim Testi: Belirli bir hata düzeltildikten sonra yapılan bir testtir.Hangi kodun, stratejinin geliştirmeye yardımcı olacağını belirlemeyi sağlar.

 

 

Bazı testler hem White-Box hem de Black-Box kapsamında incelenebilir. Bunlara örnek verecek olursak;

 

  • Fonksiyonellik Testi:Kodla birlikte fonksiyonelliği test eder.

 

  • Birleştirme Testi:Uygulamaya yeni eklenen kod ile işbirliği yapar.

 

  • Performans ve Yükleme Testi:Kodun hangi kısmının sistemin kaynaklarını yönettiğini ve performansı verilişini belirler.

Ahmet Sami Küçük

Kaynak:http://www.iztim.com/Blog/YazilimTeknolojisi/YAZILIM-METODOLOJI