FMEA (Failure Mode Effect Analysis) – Bölüm 2

İlk makalemizde FMEA’ya genel giriş yapmıştık. Bu makalemizde FMEA türlerine değineceğiz. FMEA temel olarak 4’e ayrılır:

1. Sistem FMEA
2. Tasarım FMEA
3. Proses FMEA
4. Servis FMEA

1. Sistem FMEA

Sistem ve alt sistemleri analiz ederek, sistemin eksiklerinden doğan sistem fonksiyonları arasındaki potansiyel hata türlerini belirlemeye odaklanır. Hedefi, sistemin kalitesini, güvenirliğini ve korunabilirliğini artırmaktır. Sistem FMEA’nın faydaları şunlardır:

• Sistemi etkileyen potansiyel problemlerin bulunabileceği alanlar daralır.
• Sistem içerisinde uygulanacak prosedürler için bir temel oluşturulmasına yardımcı olur.
• Sistem içerisindeki fazlalıkların tespit edilmesine yardım eder.
• Optimum sistem tasarım alternatiflerinin seçilmesinde yol gösterir.

2. Tasarım FMEA

Tasarım hatalarından doğan hata türlerine yönelik olarak üretime başlamadan önce ürünlerin analiz edilmesinde kullanılır. Hedefi, tasarım kalitesini, güvenirliğini ve korunabilirliğini artırmaktır. Tasarım FMEA’sının tamamlanmış olarak kabul edilebilmesi ancak üretim için onay ve bir başlangıç tarihinin verilmesi ile olabilir. Tasarım FMEA’nın faydaları şunlardır:

• Tasarım geliştirme faaliyetleriyle ilgili önceliklerin belirlenmesi,
• Potansiyel hataların tasarım aşamasında iken belirlenmesinin sağlaması,
• Potansiyel güvenlik sorunlarının belirlenerek ortadan kaldırılmasına yardım etmesi ve değişiklik için açıklamaların kaydedilmesinin sağlanması,
• Önemli ve kritik özelliklerin belirlenmesine yardım etmesi,
• Ürünlerle ilgili tasarım ve doğrulamaların testi sırasında kullanılabilecek bilgilerin sağlanması
  

Tasarım FMEA’nın uygulanması sonucunda:

• Potansiyel kritik veya önemli özelliklerin bir listesi ile potansiyel hata türlerinin Risk Öncelik Sayısı tarafından ağırlıklandırılmış bir listesi elde edilir.
• Test, kontrol veya teşhis yöntemleri kullanılarak potansiyel parametrelerin listesi ile kritik ve önemli özelliklere yönelik, tavsiye edilen potansiyel faaliyetlerin listesi yardımıyla hata türü ve güvenlik sorunlarını ortadan kaldıracak veya hataları azaltacak potansiyel tasarım faaliyetlerini tespit etmek mümkün olacaktır.

Tasarım mühendisi, tasarım için FMEA hazırlığında kullanacağı çok sayıda dokümana sahiptir. Süreç tasarımdan nelerin beklendiği ve nelerin olmamasının umulduğu, örneğin tasarım niyetlerinin bir listesinin geliştirilmesi ile başlar. Olası hata veya başarısızlıkların ve sonuçlarının analizini dokümante etmeyi kolaylaştırmak için FMEA tablosu kullanılır.

3. Süreç FMEA

Analiz, üretim veya kurulum süreçindeki eksiklerden doğabilecek hata türlerini ortadan kaldırmak, üretim ve kurulum süreçini analiz etmek amacına hizmet etmektedir. Süreç FMEA’sının tamamlanmış olarak kabul edilebilmesi için bütün operasyonların belirlenerek değerlendirilmesi ve kontrol planlarında ise kritik olan bazı önemli özelliklerin oluşturulmasıyla mümkün olabilir.

Ürün ve süreçlerdeki var olan potansiyel hatalara ve problemlere karşı önlem almak için oluşturulan bir yöntemdir. Bu yöntem, sürecin fonksiyonu ve güvenilirliği açısından hataların etkisini ve bunları önlemenin adımlarını saptamaya yarayan sistematik bir yaklaşımdır.Farklı fonksiyonların katılımı ile yapılan bir ekip çalışmasıdır

Süreç FMEA, sürecin bir akış diyagramı ile başlatılır. Bu akış diyagramında her operasyonda üretilecek ürün karakteristikleri tanımlanmalıdır. Bazı etkilerin belirlenmesi ve bazı önem sıralamalarının tahsisi, tasarımda sorumlu mühendisten veya mevcut ise ilgili tasarı FMEA’dan elde edilebilir. Analizi kolaylaştırmak için aynı şekilde bir form kullanılır. Bu formda farklı olan hususlar üretim süreci için özel olan konulardır. Rasgele yapılan kalite kontrol denetimleri ve test aktiviteleri  hatanın bir varlığını muhtemelen tespit edemeyecektir. Buna karşılık Test tekniklerine dayanan bir koşullama yöntemi daha doğru bir tespit yöntemidir.

Tasarım mühendisi ve süreç mühendisi tavsiye edilen önlemlerin yerine getirilmesini sağlamak ve bunları duyurmaktan sorumludur. FMEA yaşayan bir dokümandır. Süreç FMEA’nın faydaları şunlardır:

• Üretim veya kurulum süreçinin analizine yardımcı olması ve düzeltici faaliyetlerin önceliklerini belirlemesi.
• Kritik veya önemli olan özellikleri tespit etmede ve kontrol planı oluşturmada yardımcı olması.
• Süreç aşamasında ortaya çıkacak hataları belirlemesi ve düzeltici faaliyetlerle ilgili plan sunması.

Bu tekniğin uygulanmasıyla potansiyel kritik veya önemli özelliklerin bir listesi hazırlanarak, bunlara yönelik öngörülen potansiyel faaliyetlerin listesi yapılır. Potansiyel hata türlerinin risk öncelik sayısı ile belirlenen listesi üzerinde, bu hata türlerinin sebeplerini ortadan kaldıracak, ortaya çıkan hataları azaltacak ve katsayısı yardımıyla süreç yeterliliğinin geliştirilemediği durumlarda, hata nedenlerinin ve belirlenmesinin etkinliğini arttıracak potansiyel bir liste oluşturulur. Süreç FMEA Uygulama adımları aşağıdaki gibidir:

1. Ürün ve süreçin belirlenerek, çalışma ekibinin kurulması. Analize öncelikle, FMEA Değerlendirme Formunun doldurulmasıyla başlanır.

Çalışma ekibi genellikle sorumlu ve deneyimli kişilerden seçilen üç ile yedi kişiden kurulur. Öncelikle Süreç Sorumlusu seçilir. Süreç Sorumlusu öncelikle, İş Akış Diyagramları, İş Emri, Operasyon Onay ve Kontrol Formları, Operasyon Talimatları ve Kontrol Kartlar, Kontrol Planı ve diğer müşteri istekleri olan dökümanların tamamlanmasıyla uğraşır.

2. Ürün ve süreçin belirlenmesi aşamasında önce süreç aşamaları ve fonksiyonları belirlenerek, her bir parçanın fonksiyonunun ve bu fonksiyonu yerine getirecek özelliklerin tanımlanmasına çalışılır. Bu amaçla hazırlanan İş Akış Diyagramı çalışmayı yönlendirir.

3. Hata türlerinin tespitinde bir takım olasılıklardan yararlanılmaya çalışılır. Acaba müşteri hangi hata ve uygunsuzlukları  kabul etmeyip REDDEDEBİLİR. Parça operasyonda niçin RED edilebilir veya bu parça veya süreç istenilen özellikleri karşılamada nasıl bir hata ile karşılaşabilir.

4. Hata etkilerinin tespit edilmesi. Müşteri bir sonraki operasyon ise, operasyon performansı yönünden sonuçlar; uymama, kurulamama, birleştirilememe, takılamama, karşılamama; kurulum ekipmanlarını veya diğer parçaları  hasara uğratma ihtimali yönünden belirlenmeye çalışılır. Ayrıca düşük performans, çalışmama, kötü görünüm, kesintili çalışma yönünden hatanın sonuçların müşteriler tarafından değerlendirilmelidir.

5. Hataların olası sebeplerinin tespiti. Her süreç için hata türüne neden olabilecek sebepler sıralanarak, düzeltilebilir veya kontrol edilebilir süreç parametreleri cinsinden tanımlanmalıdır.

6. Kontrol önlemlerinin tanımlanması. Bunlar çıkması muhtemel hatayı belirleyen veya hata türünün ortaya çıkmasını önleyen işlemlerdir. Bu kontroller genellikle testler ve ana kontrol şeklinde yapılabilir. Süreç kontrolü öncelikle hatanın oluşmasını önlemeyi, hata sebebini bularak düzeltici faaliyeti başlatmayı ve hata türünü ortaya koymayı planlamaktadır.

4. Servis FMEA

Servis FMEA organizasyondaki aksaklıkların analiz edilmesinde yardımcı olur. Bu analizin uygulanmasıyla; organizasyon faaliyetleri arasında önceliklendirme yapılması ve değişiklik için açıklamaların kaydedilmesi sağlanır. İş akışının, sistem ve proses analizinin etkin bir şekilde yapılmasında, işteki hataların ve kritik önemli işlerin belirlenmesinde ve kontrol planlarının oluşturulmasında yol göstermesi gibi avantajlar sağlar. Yapılacak olan bir FMEA tekniği uygulaması aşağıda özetlenmiş olan fonksiyonların gerçekleştirilmesini sağlar;

• Süreç  ya da hizmette hataların oluşturacağı en küçük bir zararın bile oluşumunun engellenmesini sağlamak için hata türlerini sistematik olarak gözden geçirir.
• Süreç  ya da hizmeti ya da bunların fonksiyonelliğini etkileyebilecek her türlü hatayı ve bu hatanın etkilerini tanımlar.
• Tanımlanan bu hatalardan hangilerinin süreç  ya da hizmet operasyonlarında daha kritik etkilerinin olduğunu belirler, bu yüzden meydana gelebilecek en büyük hasarı ve hangi hata türünün bu hasarı üretebileceğini tanımlar.
• Kurulum ve kurulum, öncesinde, Süreçte  hataların oluşum olasılığını ve bunun nereden kaynaklanabileceğini (dizayn, operasyon, vb.) belirler.
• Diğer kaynaklardan elde edilmesi mümkün olmayan hata oranlarını ve türlerini tanımlayarak gerekli Test  programlarının kurulmasını sağlar.
• Güvenilirliğin deneysel olarak test edilebilmesi için gerekli test  programlarının kurulmasını sağlar.
• Bir ürün için değişikliklerin olabilecek etkilerini tanımlar.
• Yüksek riskli bileşenlerin nasıl güvenilir hale getirilebileceğini tanımlar.
• Kurulum  hatalarının olabilecek kötü etkisinin nasıl giderilebileceğini tanımlar.

Müşteriye servis henüz ulaşmadan analiz edilmesinde yardımcı olur. Bu analizin uygulanmasıyla; geliştirme faaliyetleri arasında önceliklendirme yapılması ve değişiklik için açıklamaların kaydedilmesi sağlanır. İş akışının, sistem ve süreç analizinin etkin bir şekilde yapılmasında, işteki hataların ve kritik önemli islerin belirlenmesinde ve kontrol planlarının oluşturulmasında yol göstermesi gibi avantajlar sağlar.

Yalçın ÖZÇELİK

FMEA (Failure Mode and Effects Analysis) – Bölüm 1

FMEA (Failure Mode and Effects Analysis), Türkçe’ye “Olası hata veya başarısızlık türleri ve etkilerinin analizleri” olarak çevrilebilir. Sistem ve donanım hatalarının etkilerinin belirlenmesi ve bu etkileri değerlendirme amacı ile ABD ordusunda geliştirilmiştir.

FMEA metodu, genellikle sistemin yazılımsal parçaların ve donanımsal ekipmanların analizine odaklanır. FMEA analizi yardımıyla olası zarar meydana getirecek durumlar önceden sezilerek önlemler geliştirilir. Böylece olası zararların artış olasılığı da giderilmiş olur.

FMEA çalışmasında, yeni bir ürün geliştirirken veya dizaynı oturmuş bir üründe önemli bir değişiklik veya geliştirme yapılırken, prototip üretiminde ya da seri üretimde özellikle sonuncu kullanıcıya ulaşabilecek olası hatalar, bunların cinsi, sebepleri, etkileri, kritikliği, frekansı, ortaya çıkma sıklıkları, tahmin edilebilir.

FMEA terimi bünyesinde bir grup sistematik faaliyeti barındırır. Bu faaliyetler 3 ana grupta incelenebilir;

1. Bir ürünün tasarımı,imalatı veya geliştirme süreçleri ile ilgili hata veya başarısızlık türlerinin ve bunların nedenlerinin tanıtılmaları ve değerlendirilmeleri.
2. Söz konusu hata veya başarısızlıkların meydana gelişlerini azaltabilmek veya yok edebilmek şansına sahip önlemlerin belirlenmesi.
3. Bu sürecin yazılı hale getirilmesi (dokümante etmek).

Bir FMEA programının başarılı olarak yerine getirilmesi için önemli bir faktör zamanında harekete geçmektir. Yani bir olay meydana geldikten sonra önlem almak yerine olay çıkmadan önlem almak gerekir. Bu amaca ulaşmak için olası başarısızlıklar hazırlık aşamalarında ön görülebilmelidir. Böylece daha sonra yapılması bir krize neden olacak değişiklikler önceden ve kolayca yapılmalıdır. FMEA’in sonradan yapılması başka sorunlar yaratan düzeltici önlemleri azaltır veya yok eder. İyi planlanmış bir FMEA;

• Her hatanın sebeplerini ve etkilerini belirler,
• Potansiyel hataları tanımlar,
• Olasılık, şiddet ve belirlenebilmeye bağlı olarak hataların önceliğini ortaya koyar,
• Problemlerin takibi ve düzeltici faaliyetlerin uygulanması safhalarında yol gösterici olur

FMEA’nın başarısı, çıkarılan sonuçların iyileşme ve gelişme stratejisi içinde kabul görmesine bağlıdır. Aksi durumda FMEA dinamiklik özelliğini kaybeder. Hata Türü ve Etki Analizi sürecinde takım şu unsurları belirlemeye çalışmalıdır;

• Analize konu olan kısmın fonksiyonu,
• Sorun çıkarma potansiyeli,
• Sorunun etkileri,
• Bu sorunun olası nedenleri,
• Bu nedenlerin bulunabilirliği,
• Bu sorunların önlenebilmesi için alınabilecek önlemler.

Hata Türü ve Etki Analizi dokuz temel aşamadan oluşmaktadır;

1. FMEA amaçları ve düzeylerinin belirlenmesi için FMEA planlaması.
2. FMEA'nin gerçekleştirilmesi için özel prosedürlerin, temel kuralların ve kriterlerin tanımlanması.
3. Fonksiyonlara, etkileşim alanlarına, faaliyet aşamalarına, faaliyet türlerine ve çevreye göre sistemin analizi.
4. Süreçlerinlerin, karşılıklı bağlantıların ve bağımlılıkların gösterilmesi için hata ağacı şemalarının, görev ve güvenilirlik şemalarının oluşturulması ve analizi.
5. Potansiyel hata türlerinin tanımlanması.
6. Hata türlerinin ve etkilerinin değerlendirilmesi ve sınıflandırılması.
7. Hataları önleyecek ve kontrol edecek önlemlerin tanımlanması.
8. Önerilen önlemlerin etkilerinin değerlendirilmesi.
9. Sonuçların belgelendirilmesi.

FMEA’nın uygulaması için bir form kullanılır. Kullanılıan form temel hatları ile aşağıdaki gibidir;

Yalçın ÖZÇELİK

Proje Yönetimi – Bölüm 4 (Projeler Neden Başarısız Olur?)

Yazılım projelerini başarısızlığa uğratan çeşitli nedenler sayılabilir;

• Müşteri memnuniyetsizliği

Projeler, müşterilerin ve son kullanıcıların gereksinimlerini tam anlamıyla karşıladıkları zaman başarılı sayılırlar. Proje bütçeye uygun ve zamanında bitmiş bir proje olsa bile müşteri memnuniyeti üst düzeyde değilse başarılı değildir.

• Projenin zaman ve bütçe kısıtlarının fazlasıyla aşması

Proje ekibinin, proje kısıtlarını göz önünde bulundurmadan geliştirmeleri başarısızlığı da beraberinde getirecektir. Bütçe ve zaman, proje kısıtlarından en önemlileridir. Proje, uygun olmayan bir bütçe ve/veya tahmin edilen zamandan çok sonra tamamlanırsa başarılı kabul</CITY> edilmez.

• Gereksinim analizlerinin proje genelindeki belirsizlikler yüzünden gerektiği gibi yapılamaması ve bunun neden olduğu sürekli değişiklikler

Gereksinim analiz süreci, yazılım mühendisliği disiplinlerinin en önemli safhalarından biridir. Proje takımı, analiz süresince gereksinimleri dikkate alarak, ürünün tüm özelliklerini ayrıntılarıyla belirlemezse, projenin başarısız olması kaçınılmazdır.

• Tamamlanan ürünün var olan sistemdeki diğer ürünlerle entegrasyonunda yaşanan problemler

Yazılım ürünleri, onu kullanacak olan işletmelerin var olan işleyiş ve çalışma yapılarını olumsuz derecede etkilememeli, hatta entegre olabilecek şekilde tasarlanmalıdır. Mevcut sorunları çözmek amacıyla satın alınan ürünün, işletmeyi yeni sorunlarla baş başa bırakması projeyi başarısız kılacaktır.

• Ürünün son kullanıcılar tarafından kolay kullanılamayışı

Yazılım ürünleri, kullanıcılarla daima etkileşim halinde olacağından, kolay anlaşılır ve kullanışlı olmaları öncelikli gereksinim olarak görülmektedir. Proje ekibi ürünü geliştirirken, kullanıcıların rahat çalışmalarına yönelik arayüzler tasarlamalıdır.

• Proje sonunda gerekli eğitim ve desteğin verilememesi

Yazılım projeleri, kullanıcı ve yönetici eğitimi, altyapı sistemi ile uyumluluk, düzgün kurulum ve teknik destek gibi kavramlarla birlikte değerlendirilirler ve bunlardan birinde meydana gelen eksik veya sorunlar proje başarısızlığına neden olabilir.

Deniz KILINÇ

Web Servisleri – Bölüm 1

Web servisleri,  web üzerinden servis veren program parçalarıdır. Bir kullanıcının, HTTP protokolü üzerinden web servisini kullanmasına RPC (Remote Procedure Call) denmektedir. HTTP üzerinden yapılan bu çağrımlara karşı SOAP (Simple Obect Access Protocol) dediğimiz protokol ile XML çıktıları üretilir. Bu sayede standart bir veri paylaşım aracı olan XML ile istediğimiz verileri alıp kullanırız. SOAP standartları, W3C standartlar komitesi tarafından belirlenmiştir. Bütün bu standartları uygulamaya geçiren SOAP sayesinde web servisine, platformdan bağımsız çağırımlar yapılabilmektedir. Yani .NET ortamında geliştirilen bir web servisine JAVA ile geliştirilen bir programdan ulaşmak mümkündür.

SOAP dışında bazı standartlar da vardır, bunlar XML, WSDL, DISCO ve UDDI olarak sıralanabilir. XML, web servislerinin veriyi sunmak için kullandığı bir standarttır. WSDL (Web Service Description Language), web servisinin sunduğu arayüzü tanımlamak için kullanılır, bir web servisinde bulunan fonksiyonların hangi parametreleri aldığını ve ürettiği bilginin türünü bu standartlar ile belirtiriz. DISCO (Dıscovery Protocol) sayesinde ise bir sunucuda paylaşıma açılmış bütün web servislerinin organizasyonu sağlanır. UDDI (Universal Description, Discovery and Integration) standartları, internet üzerinde paylaşıma açılmış ve uygulamalar tarafından kullanılabilecek web servislerinin organizasyonunu sağlar.

Web servisleri günümüzde önemli yer tutmaktadır. TC Kimlik No sorgulama, merkez bankasından anlık doviz kurlarının çekilmesi, örneğin bir şirketsiniz uzak şubelerinize anlık master verilerin sunulması web servisleri ile rahatlıkla sağlanır. İhtiyaca göre  ya web ortamından ya da windows ortamından çağrılabilirler.

Web Servis Hazırlanması

Yeni  bir web servis hazırlanması için File->New Web Site buradan pencere açılır (Bkz Şekil 1). “ASP.Net Web Service” seçeneği seçilir. Dil seçimi ise isteğe bağlı olarak tercih edilebilir. Dosyanın kaydedildiği yer de seçildikten sonra pencere kapatılır.

Şekil 1. Web Servisi Yaratılması

Karşımıza web servisimize ait basit bir method gelir. Bu method ekrana sadece “Hello World” yazdırır. Bu methodu silip kendimize illeri getiren method  oluşturacağız (Bkz Şekil 2). İlleri  sunmak  için ilk önce access de yeni bir database mdb (iller.mdb) dosyası ve bu dosyada sehirler tablosu yaratıp, iller ekleyeceğiz.

Şekil 2. Web Servis Kodu

Bu kodlar Service.vb dosyasında olması gereken kodlardır ve bir metot belirtir. Bilinen ado.net kütüphanesine ait kodlar kullanılarak ilk önce veritabanına bağlantı sağlanmıştır. Sonra, adapter nesnesi ile bir sorgulama cümlesi yazılıp bu sorguya uyan veriler datasete(verikümesine) aktarılmıştır. Metodun geri dönüş veritipi dataset olacak. Yani bu metot sonlandığı zaman geri dönüş olarak bir dataset gönderecektir. Şimdi F5'E basarak bu Web Servisimizi test edebiliriz.

Şekil 3’de Web Servisimize ait oluşturulmuş olan bütün metotlar bu sayfada görüntülenir ve hangisini test edileceği buradan seçilir. Bizim örneğimizde sadece bir tane metod olduğundan karşımıza çıkan metoda tıklıyoruz. Karşımıza gelen yeni sayfadanda Invoke butonuna tıklıyoruz. Bu aşamalardan sonra karşımıza ado.net kütüphanesine ait kodlar ile verileri çektiğimiz datasetin içeriği görülecektir.Tabikide burada açılacak olan sayfa bir xml sayfasıdır. Dolayısıyla verilerde xml üzerinden gelecektir.

Şekil 3. Web Servisi Test

Şekil 3’de görüldüğü gibi dataset verileri xml şeklinde görüntülenir ve testimizin başarılı olduğu bu şekilde anlaşılır. Bu aşamalardan sonra Web Servisimiz herhangi bir ortamdan (web, windows, mobile vb.) çağrılabilir duruma gelmiştir.
Emin Serkan BAYDAR

UML ve Modelleme – Bölüm 2 (Diyagramlar)

Bir önceki makalemizde UML’e giriş yapıp özelliklerinden ve diyagramların neden kullanıldığından bahsetmiştik. Bu makalemizde diyagram türlerine değineceğiz. UML modellemede nesneler arasındaki ilişki kurmak için gereken 9 adet diyagram türü bulunmaktadır.

Şekil 1. UML Model ve Diyagramlar

1. Use Case Diyagram:  Bir kullanıcı ve bir sistem arasındaki etkileşimi anlatan senaryo topluluğudur. Use case diyagramlarda use case’ler ve aktörler adını verdiğimiz iki ana bileşen bulunmaktadır.

Şekil 2. Use Case Diyagram

2. Class(Sınıf) Diyagram: Nesne tabanlı programlamada kullanılan sınıflar ve bunların arasındaki ilişkileri modelleyebileceğimiz diyagramlardır. Sınıflar isim, özellikler ve işlemler den oluşmaktadır.

Şekil 3. Class Diyagram

3. Object(Nesne) Diyagram:  Gerçekleşmiş nesne bilgilerinin bulunduğu diyagramlardır. Sınıfın nesne kullanılmış halidir. 4. State(Durum) Diyagram: State diyagramları sistem davranışlarını gösterir.  Her diyagram tek bir sınıfın nesnelerini ve bu sistem içerisinde nesnelerin durumlarını göstermektedir.

Şekil 4. State Diyagram

5. Sequence Diyagram: Sequence diagramları use case içerisinde bulunan nesnelerin davranışlarını gösteren diyagramlardır. Bu diyagramlar soldan sağa okunur.

Şekil 5. Sequence Diyagram

2.     6. Colloboration Diyagram : Collaboration diagramların çizimi oldukça basittir. Nesnelerin birbirleri arasındaki ilişkiyi belirten diyagramlardır. Bu diyagramların sequence diyagramlardan farkı mesajlar nesneler arasında farklı şekilde iletilir.

Şekil6. Colloboration Diyagram

7. Activity Diyagram :  Aktivite diyagramları sistemin iş akışını gösteren diyagramlardır.

Şekil 7. Activity Diyagram

8. Component Diyagram : Component diyagramları sistemin yazılım bileşenlerinden ve birbirleri arasındaki bağlantının nasıl olduğunu gösterir.

Şekil 8. Component Diyagram

9. Deployment Diyagram: Deployment diyagramlar sistemin donanım ve yazılım ilişkilerinin fiziksel gösterimidir. Deployment Diyagramlarda connection ve nodelar kullanılır.

Şekil 9. Deployment Diyagram

Bir sonraki makalemizde UML diyagramlarını alıp ayrıntılı inceleyeceğiz.

Referanslar http://atlas.kennesaw.edu/~dbraun/csis4650/A&D/UML_tutorial/diagrams.htm http://www.csharpnedir.com/articles/?cat=uml&title=UML%20/%20Analiz

Neslihan ÇALIŞKANEL

Veri Madenciliği

Bilgi sitemleri üzerinden üretilen veri miktarının büyük  artış  gösterdiğini ve  firmaların veritabanlarının  boyutlarının  terabytelar seviyesine ulaştığını  görmekteyiz.  Veritabanlarındaki teknolojik gelişmeler ve hacimlerindeki olağanüstü artış, firmaları,  bu verilerden nasıl faydalanılacağını ve bu  verilerin  nasıl  anlamlı hale  getirileceği  sorunuyla  karşı  karşıya  bırakmıştır.

Bilgisayar  sistemleri  ile  üretilen  bu  veriler tek başlarına  değersizdirler.  Ancak belli  bir amaç  doğrultusunda  işlendikleri  zaman  anlamlı  hale  gelirler. İşte ham  veriyi  bilgiye veya anlamlı  hale  dönüştürme  işini veri madenciliği ile yapabiliriz.

Veri madenciliği sürecinde; kümeleme, veri özetleme, sınıflama  kurallarının  öğrenilmesi, bağımlılık  ağlarının  bulunması, değişkenlik  analizi ve anomali tespiti gibi  farklı birçok teknik  kullanılmaktadır.

Veri madenciliği, eldeki verilerden üstü kapalı, çok net olmayan, önceden bilinmeyen ancak potansiyel olarak kullanışlı bilginin çıkarılmasıdır. Başka bir deyişle, verilerin içerisindeki desenlerin, ilişkilerin, değişimlerin, düzensizliklerin, kuralların ve istatistiksel olarak önemli olan yapıların yarı otomatik olarak keşfedilmesidir. Amaç, daha önceden fark edilmemiş veri desenlerini tespit edebilmektir.

Veri madenciliği kendi başına  bir  çözüm değil, çözüme  ulaşmak  için  verilecek karar sürecini destekleyen, problemi  çözmek  için gerekli bilgileri sağlamaya  yarayan bir araçtır. Veri madenciliği; analistlere, iş  yapma  aşamasında  oluşan  veriler arasındaki şablonları ve ilişkileri  bulmaları  konusunda  yardım etmektedir. 

Veri Madenciliğinin kullanım amaçlarını aşağıdaki gibi sıralayabiliriz;

• Veri ambarında depolanmış verilerden anlamlı bilgi çıkartma,
• Çok büyük miktardaki veriden yeni ve işimiz için gerekli olan anlamlı bilgi üretme,
• Verinin özelliklerinden yararlanarak eğilimlerini anlama,
• Geleceğe yönelik tahminlerde bulunarak bilgiyi gelecekteki müşteri ilişkilerini yönlendirmek amacıyla değerlendirme,

Günümüzde  veri madenciliğinin başlıca  ilgi alanları  olarak  aşağıdakiler  sayılabilir;

• Müşteri sınıflandırması,
• Müşterilerin  demografik  özellikleri arasındaki bağlantıların  kurulması,
• Çeşitli pazarlama kampanyaları,
• Mevcut müşterilerin  elde  tutulması  için geliştirilecek  pazarlama  stratejilerinin  oluşturulması,
• Pazar sepeti analizi

Mustafa ERŞAHİN

Sanal POS (V-POS)

Web üzerinden ödeme söz konusu olduğunda, sanal POS’lar devreye girer. Klasik alışverişlerde kullandığımız POS  (Point of sale - ödeme noktası) cihaz ve sistemlerinin, web siteleri üzerinden alışveriş yapmaya olanak sağlayan şekline sanal POS-VPOS (Virtual point of sale) denmektedir. Kısaca “Internet´e uyarlanmış POS da diyebiliriz”. Internet üzerindeki alışverişlerinizde kredi kartı ile ödeme yapabilmenizi on-line olarak sağlayabilmektedir. Üye işyeri için, müşterinin yaptığı ödemeler VPOS sisteminden yararlanılan bankadaki firma hesabına geçmektedir.

Sanal POS ile alıcı-satıcı ya da satıcı-tedarikçi arasında online bir ödeme sistemi ve altyapısı kurulmuş olur. Sistem basit olarak, firmanın web sitesi üzerinden bilgilerini giren alıcının banka ve kredi kuruluşlarında olan hesabından, aldığı ürün veya hizmetin bedeli olan paranın firmanın kendi banka hesabına geçmesine dayanır.

Ürün ve hizmetlerini web üzerinden pazarlamayı düşünen bir firma, öncelikle ticari hesabının bulunduğu bir banka ile üye işyeri ve e-ticaret sözleşmelerini imzalaması, devamında da bankaya ait VPOS yazılımını kendi web sitesine kurması yeterlidir.

Güvenlik

VPOS ’ta internet üzerinden transfer edilen bilgilerin 3. şahısların ellerine geçmesini önlemek için veri transferini halen en güvenli yöntem olarak bilinen SSL 128 Bit güvenlik yöntemini kullanarak gerçekleştirmektedir. E-mağazanın bulunduğu sistemden kredi kartı bilgilerini ve tahsilat tutarı alınarak ilgili bankanın sistemine, SSL 128 Bit güvenlik yöntemi ile internet üzerinden iletir. Bankalar sanal POS hizmeti verecekleri web sitelerinde SSL 128 bit'lik şifreleme şartını aramaktadırlar.

BANKA SANAL POS SİSTEMLERİ

Ülkemizde Sanal Pos hizmeti sağlayan bankalara Garanti Bankası, Finans Bank, Yapı Kredi Bankası, Akbank, Vakıf bank gibi bankaları örnek verebiliriz. Tanımlanacak sanal poslardan her birisi aynı yapıda olmayabilir. Bankadan bankaya farklılık gösterirler. Bankaların bazıları (Garanti, Finansbank, Halkbankası, İş Bankası, HSBC vb.) ortak sistem (EST POS SİSTEMİ) üzerinden, bazıları (Yapı Kredi, Vakıfbank) ise kendilerinin oluşturduğu sistem üzerinden pos işlemlerini alırlar.

Güvenlik için bankanın sanal pos için müşteri firmaya verdiği sistem giriş bilgilerinin sistemlerinde şifreli olarak saklanması önerilir. Burada uygulanan şifreleme 2 yönlü olmalıdır, bu bilgiler kullanılacağı zaman deşifre edilmelidir.

Loglama

Yapılan bütün olumlu ya da olumsuz geri dönen işlem değerleri veritabanına eklenir. Bu loglama işleminin amacı daha sonradan yapılan ödeme işleminin takip edilmesi ya da ödeme işlemin geri alınması içindir.

1. EST POS Sistemi

Garanti, Finansbank, Halkbankası, İş Bankası, HSBC vb bankalar bu sistemi kullanırlar. EST Pos Sistemini kullanan bankaların sanal posu EST (Elektronik Sanal Ticaret) firması tarafından yayınlanan epayment.dll kütüphanesinin sunduğu işlemler yardımı ile gerçekleştirilir. İlgili banka ile anlaşma sağlayan kullanıcı firmaya aşağıda belirtilen parametre bilgiler ve epayment.dll kütüphanesi verilir. Sanal pos işlemi için ilgili firmanın Statik IP numarası olması gerekmektedir.

Örnek uygulama: (Detayları ile ilgili bizlerle iletişime geçebilirsiniz)

cc5payment mycc5pay = new cc5payment(); mycc5pay.host = “hostname”; mycc5pay.name = “name”; mycc5pay.password = “password”; mycc5pay.clientid = “clientId”; mycc5pay.orderresult=0; mycc5pay.cardnumber = “CCNumber”; mycc5pay.cv2 = “CCVNumber”; mycc5pay.expmonth = “01”</METRICCONVERTER>; mycc5pay.expyear = “06”</METRICCONVERTER>; mycc5pay.oid=”S00234” // Order ID mycc5pay.taksit = “3”</METRICCONVERTER>; mycc5pay.subtotal = “1.43”</METRICCONVERTER>; mycc5pay.currency = "949"; // For YTL, TL mycc5pay.chargetype = "Auth"; mycc5pay.bname = “Sender name”; mycc5pay.baddr1 = “Sender Address”; mycc5pay.baddr2 = “senderEMail”; result = mycc5pay.processorder(); error =mycc5pay.errmsg; oid = mycc5pay.oid; approved = mycc5pay.appr; if(result == "1") // banka ile bağlantı sağlandı { if(!approved.Equals("Approved")) // işlem başarılı { return ; } } else { return; }

2. HSBC POS Sistemi

HSBC bankası sanal posu EST firması tarafından yayınlanan epayment.ddl kütüphanesinin sunduğu işlemler yardımı ile gerçekleştirilir. Farklı olarak bir ticket sistemi içermektedir.

Ticket Sistemi

HSBC sanal posuna işlem göndermeden önce sistemden ticket (Pan değeri) almak gereklidir. Alınan ticket sanal pos apisi içerisindeki kart numarası alanına yazılır. Ticket 1 saat içerisinde kullanılmalıdır, bu süre sonunda otomatik olarak geçersiz duruma getirilir. Bu ticket güvenlik amacı ile üretilmektedir ve her seferinde bir kullanımlık ticket üretilir. Ticket Sisteminde Pan değerinin ilk 6 hanesi kartın BIN numarasını verir. Örnek olarak aşağıdaki pan değerinde BIN numarası (Kart numarasının ilk 6 hanesi) 424242’dir.

424242:F89DFF8B4AEAFFD671DBC4B25B:4926:

Emin Serkan BAYDAR

UML ve Modelleme – Bölüm 1

Modelleme bir mühendislik tekniğidir. Model sayesinde anlaşılması güç yazılımları basit bir dille ifade edebiliriz. Bu da yazılımın anlaşılmasını kolaylaştırır ve hataları kolaylıkla görüp en düşük seviyeye indirgememizi sağlayacaktır.

UML nedir?

UML’ in Türkçe deki karşılığı “Birleşik Modelleme Dili” olsa da aslında bir programlama dili değil yazılım mühendisliğinde nesne tabanlı modellemede kullanılan standart olmuş görsel modelleme dilidir. UML’in tarihine söyle bir göz atacak olursak :

90’lı yıllarda yazılım mühendisliğinde birbirine yakın en çok tercih edilen 3 yöntem ön plana çıkmıştır. 1991 yılında Grady Booch tarafından Booch,  aynı dönemde James Rumbaugh   tarafından OMT (Object Modeling Technology) ve 1992 yılında Ivar Jacobson  tarafından OOSE (Object Oriented Software Engineering) modelleme dili geliştirildi.  Bu üç yönteminde birbirine göre artı ve eksileri vardı.  Bu dönem yazılım mühendisliğinde “METHOD SAVAŞLARI” olarak  bilinmektedir.

Method	Analiz	Tasarım	Donanımsal Analiz
Booch	-	+	-
OMT(Object Modeling Teknology)	+	-	-
OOSE(Object Oriented Software Engineering)	-	-	+

1994 yılında bu üç yöntemin geliştiricileri Rational Rose Software’da çalışırken bu çalışmalarını UML adı altında birleştirdi.

İlk resmi sürümü 1995 Ekiminde(UML version 08) ilan edilmiştir. Bu sürümden sonra dahada geliştirilerek  Temmuz 1996 da (UML version 09), Ekim 1996’da  (UML version  0,91) çıkarılmıştır. Sürüm 1,0 ile 1,1 ise Eylül 1997 OMG (Object Menagement Group) tarafından tarihinde standaralizasyon amacıyla çıkmıştır. 2004 yılında UML 2.0 standardı geliştirilmiştir.

Yazılım yaşam döngüsü içerisinde farklı görev tanımlamaları bulunmaktadır (Analistler, tasarımcılar, parogramcılar, testçiler, kalite sorumluları, müşteriler / kullanıcılar, teknik yazarlar ).  Her birinin sisteme yada projeye bakış açısı birbirinden farklıdır. Müşteri açısından projeye baktığımızda müşteriyi işlerin sıralandırılması, sisteme artıları ve eksileri , işler arasındaki ilişkiler ilgilendirirken bir fonsiyonun detayları ilgilendirmemektedir. Analist açısından baktığımızda nesne özellikleri, fonksiyonlar ve alacakları parametreler yeterli iken tasarımcı açısından parametrelerin veri tipleri, fonsiyonun performansı, yaşam süresi gibi bilgiler de önemli olmaktadır. Bu nedenle UML  bu ekip için gerekli farklı diyagramlar içermektedir. Yazılım geliştirme işinde yer alacak farklı ekiplerin farklı bakış açılarına uygun farklı UML diyagramları bulunmaktadır.  UML, yazılım geliştirmede analiz ve  dizayn aşamalarında büyük rol oynamaktadır.

UML’ye Neden Gerek Var?

• Hataların kolaylıkla fark edilip en düşük seviyeye indirgenmesi.(Risk, zaman, maliyet)
• Yazılım üretiminde başarı oranının düşük olması. (%16 )
• Yazılımda paylaşım önemlidir. Tüm ekibin aynı dili konuşabilmesi gerekmektedir.
• Sistemin tamamını basit bir dille ve görsellikle görebilmek ve tasarlayabilmek gerekli.
• Modellenmiş ve dökümante edilmiş bir yazılımın tanıtımının kolay olması.
• Yazılım kalitesini arttırma.
  
  

UML’nin avantajlar

Yazılım da kodlama başlamadan tasarlanacağından;

• Kodlama kolaylığı sağlar.
• Kullanılan tekrar kod sayısı ayırt edilebilir bu sayede verim sağlanır.
• Mantıksal hataların minimum seviyeye düşürülmesini sağlar.
• Geliştirme maliyetinin düşmesini sağlar.
• Resmin tamamının görülmesini sağlar.
• UML diagramları ile yazılım tamamını görebileceğimiz için verimli bellek  kullanımı sağlanabilir.
• Karmaşık sistemlerde değişiklik yapmayı kolaylaştırır.
• UML ile dokümanlandırılmış kodları düzenlemek daha az zaman alacaktır
• UML diyagramlarını kullanan yazılımcılar aynı dili konuşacaklarından kolay iletişim sağlanır.             

Neslihan ÇALIŞKANEL