FMEA (Failure Mode Effect Analysis) ve RPN (Risk Priority Number) Kullanarak Hata Önceliklendirme Yalçın ÖZÇELİK 1, Dr. Deniz KILINÇ 1 1 Univera Bilgisayar Sistemleri Sanayi ve Ticaret A.Ş, İzmir 1 Univera Bilgisayar Sistemleri Sanayi ve Ticaret A.Ş, İzmir yalcin.ozcelik@univera.com.tr, deniz.kilinc@univera.com.tr Özet: Yazılım sektöründe, hatalar hayatımızın bir parçası olduğuna göre, hataların belirli bir yöntem ve standardizasyon ile yönetilmesi zorunludur. Bu noktada, hataların önceliklendirilmesi önem kazanmaktadır. Türkçe ye Olası hata veya başarısızlık türleri ve etkilerinin analizleri olarak çevrilen FMEA (Failure Mode and Effects Analysis), 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 tespit edilerek, önlemler geliştirilir. FMEA analizi yapılırken bir puanlama tekniği olan RPN (Risk Priority Number) in kullanılması esastır. Bu bildiride Univera da hata önceliklendirme çalışmalarında FMEA ve RPN in nasıl kullanıldığı üzerinde durulmuştur. Anahtar Sözcükler: fmea, rpn, yazılım hata yönetimi, risk yönetimi, yazılım mühendisliği, test mühendisliği Abstract: If errors are a part of our lives in the software industry, they must be managed with a specific method and standardization. At this point, the prioritization of errors is important. FMEA (Failure Mode and Effects Analysis), usually focuses on the analysis of the system software components and hardware equipment. With the help of the FMEA analysis, the cases that will occur possible harms are identified beforehand and prevention measures are developed. During the realization of FMEA analysis, a scoring technique, RPN (Risk Priority Number) must be used. This paper focuses on how to use RPN and FMEA for error prioritization work in Univera. 1. Giriş Yazılım firmaları tarafından birçok farklı sektörde faaliyet gösterebilecek ürünler geliştirilirken tüm bu ürünlerin ortak amacı kaliteyi arttırmak ve maliyetleri düşürmektir. Her yazılım, kendi sektöründe başarılı olabilir, ancak kaynak yetersizliği, sürecin karmaşıklığı vb. faktörler nedeniyle, tamamen hatasız bir yazılım geliştirmek neredeyse imkansızdır [6]. Günümüz teknolojisi her geçen gün yazılım geliştirme araçlarını güçlendirse de, insan faktörü geliştirme sürecinin bir parçası oldukça, tamamen hatasız bir yazılım üretmek teorik olarak mümkün görünmemektedir. Dolayısıyla, yazılım geliştirme sürecinin her aşamasında hata oluşma riski bulunmaktadır. Hatalar, yazılımın kalitesine etki ettiğine göre, yazılım geliştirme süresince iyi takip edilmeli ve yönetilmelidir. Bu sayede geliştirilen yazılımda hata oluşmasına neden olan gerçek sebepler bulunabilir ve bu hataların oluşmasını engelleyecek sistemler üzerinde çalışma yapılabilir.
Yazılım sektöründe, hatalar hayatımızın bir parçası olduğuna göre, hataların belirli bir yöntem ve standardizasyon ile yönetilmesi zorunludur. Bu noktada, hataların önceliklendirilmesi önem kazanmaktadır [6]. 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 [1]. İlk olarak ABD ordusunda, sistem ve donanım hatalarının etkilerinin belirlenmesi ve bu etkileri değerlendirme amacı ile 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 tespit edilerek, önlemler geliştirilir. 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 son kullanıcıya ulaşabilecek olası hatalar, bunların cinsi, sebepleri, etkileri, kritikliği, frekansı, ortaya çıkma sıklıkları, tahmin edilebilir [2]. 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ımlanmaları 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 Bir FMEA programının başarılı olarak yerine getirilmesi için en önemli 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çlerin, 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 2. FMEA Türleri FMEA temel olarak 4 e ayrılır [2]: 1. Sistem FMEA 2. Tasarım FMEA 3. Proses FMEA 4. Servis FMEA 2.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.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 arttı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 Değeri (RPN, Risk Priority Number) 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. 2.3. Süreç FMEA Analiz, üretim veya kurulum sürecindeki eksiklerden doğabilecek hata türlerini ortadan
kaldırmak, üretim ve kurulum sürecini 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. Rastgele 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ürecinin 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ürecin 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ürecin belirlenmesi aşamasında 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. 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. 2.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. 3. FMEA Analizinde RPN Puanlama Tekniği FMEA analizi yapılırken bir puanlama tekniği esastır. Puanlama yatay olarak 3 ana grubun derecelendirilmesi ve bu grupların kendi içlerindeki dikey risk kategorilerine göre yapılır [3].
Bu derecelendirilmenin sonucunda elde edilen rakamların birbirleri ile çarpılarak RPN (Risk Priority Number) yani RÖD (Risk Öncelik Değeri) bulunur. Bahsedilen 3 ana grup aşağıdaki gibidir; Severity (Sistem açısından önemi) Priority (İşsel/müşteri açısından öncelik) Likelihood (Karşılaşma olasılığı) Severity Dereceleri 1. Veri kaybı: Riskin sistemde veri kaybına sebep olması 2. İşlevsellik kaybı: Riskin sistemdeki bir ilevselliği bloke etmesi 3. Giderilebilir işlevseelik kaybı: Riskin sistemdeki bir işlevselliği bloke etmesi fakat başka bir işlevsellik kullanılarak işlemin gerçekleştirilmesi. 4. Kısmi işlevsellik kaybı: Riskin sistemdeki bir işlevselliğin çok önemli olmayan bazı özelliklerini bloke etmesi 5. Kozmetik risk: Genellikle kullanıcı ara yüzlerinde ortaya çıkan işlevselliği etkilemeyen fakat istenmeyen mesaj veya görüntü sergileyen riskler. Priority Dereceleri 1. Acil (urgent): Hemen çözülmesi gereken riskler 2. Zorunlu(essensial): Sistem kullanıma alınmadan önce kesinlikle düzeltilmesi gereken riskler 3. Önemli(valuable): Müşteri memnuniyeti etkileyebilecek riskler 4. Düzeltilmesi iyi olacak riskler(desirable): yeterli zaman ve bütçe kalırsa düzeltilmesi iyi olacak riskler aksi takdirde bir sonraki sürümde düzeltilebilecek riskler 5. İsteğe bağlı (discretinary): daha öncelikli riskler düzetildikten sonra diğer sürümde düzeltilebilecek riskler. Likelihood Dereceleri 1. Muhtemel (Likely) 2. Mümkün(Possible) 3. İhtimal dahilinde olmayan (Unlikely) RPN olarak rakamı düşük olan RPN değeri ilk önceliklidir. RPN rakamı büyüdükçe riskler önem derecesini yitirmeye başlar. Başka bir deyiş ile ilk ortadan kaldırılması gereken risk, en düşük RPN değeri taşıyan risklerdir. RPN değerine göre test tipleri ve çeşitleri aşağıdaki gibidir: 1. Extensive testing (RPN 1-20) test mühendisleri bu kategoriye giren riskleri ortaya çıkarabilmek için proje kaynaklarının azami zorlayarak sistemin ilgili modüllerini çok kapsamlı ve derinliğine test edeceklerdir. Riskin tekrar yaratılması ve detaylı raporlanması için azami zaman harcanacaktır. 2. Balanced testing (RPN 21-50) proje kısıtları dahilinde testler yapılarak riskleri bulmaya çalışacaktır. 3. Opportunatiy testing (RPN 51-65) extensive ve balanced test için yaratılan ortamlar bu testlerin gerçeklemesi için uygunsa testler yapılır 4. Reporting observed bugs (RPN 66-75) test mühendisleri bu riskleri için özel olarak test yapmayacaklardır diğer test süreçlerinde bu risklere rastlanırsa sadece raporlanacaktır. 4. Sonuç Univera [4] olarak FMEA analizini hayatımıza sokmak için üç temel konuya önem verdik: 1. İstek ve geliştirme süreçlerimizde analiz aşamasından başlayarak FMEA haritaları çıkarmaya başladık. FMEA süreçleri sonucu çıkan haritalar İş analisti arkadaşlarımız ile başlayan ve Test departmanımız ile devam eden bir süreci kapsadı. Bu süreç içinde test koşullarımız ve test tiplerimiz de zaten otomatik olarak belirlenebilir hale geldi. Yapılan tüm İstek ve geliştirme süreçlerimiz için
harcanan zaman ve kaynak kullanımı minimize oldu. 2. RPN değerlerinin girilebilmesi için hata yönetim aracımız olan uhisys (Univera Hata ve İş Yönetim Sistemi) [5] üzerinde geliştirmeler yapıldı. Yapılan kodlama hataların ve isteklerin bu değerlere göre analiz edilebilmesini de içerdi. Bu analizlere göre setlerimizin yayınlama prosedürleri değiştirildi. 3. Üçüncü konu ise her yazılım departmanının korkulu rüyası Hata Yönetimiydi. Bilindiği üzere hata yönetimi müşteri kanadında kapsadığından Müşteri ve Profesyonel Hizmetler departmanımızla ortak bir iş sürecine girildi. FMEA süreci, RPN değerleri, derecelendirme kuralları eğitimleri düzenlendi. Hata yönetim aracımıza girilecek her kayıt için derecelendirme işlemi yapıldı. Bu sayede, Beta testlerden dönen hataların kodlanma trafiğini yönetilebilir hale getirilmesi sağlandı. [5] uhisys: http://univera-ng.blogspot.com/ 2009/09/yazlm-hatalar-bolum-2.html [6] Yazılım Hataları Bölüm I (Giriş): http://univera-ng.blogspot.com/2009/09/ yazlm-hatalar-bolum-i.html İşlerin daha hızlı ve efektif sonuçlarınız hale gelmesi FMEA süreçleri şirketimiz genelinde beklediğimizden daha hızlı kabul görmesine sebep oldu. Bu kabul FMEA i şirket standartları içine alınması sağladı. Kaynaklar [1] Yılmaz S. B., Hata Türü ve Etki Analizi, 9 Eylül Üni.Sosyal Bilimler Enstitüsü Dergisi, Cilt 2, Sayı 4, 2000. [2] FMEA (Failure Mode and Effects Analysis) Bölüm 1: http://univerang.blogspot.com/2009/10/fmea-failure-modeand-effects-analysis.html [3] Yazılım Hataları Bölüm 3: http://univera-ng.blogspot.com/2009/09/ yazlm-hatalar-bolum-3.html [4] Univera Bilgisayar Sistemleri A.Ş.: http://www.univera.com.tr/