Yazılım Mühendisliğinde Risk Analizini Anlamak

Mystery Flight Over Java (Short Story)

Yazılım projelerinde risk analizinin önemi, çeşitli türde ilişkili risklere sahip alanların aktif olarak değerlendirilmesinden geçmediği sürece hiçbir yazılım geliştirme yaşam döngüsünün tamamlanmış sayılmaması gerçeğiyle değerlendirilebilir.

Risk analizi sürecinin kapsadığı savunmasız alanlar şunlardır:

1) Risk değerlendirmesi

2) Risk karakterizasyonu

3) Risk iletişimi

4) Risk yönetimi

5) Riskle ilgili politikaların tanımı

Risk analizi ile ilgili aşağıdaki terimler açıkça anlaşılmalıdır

Risk analizinin ne olduğunu anlamaya çalışalım.

Bir projenin başarısını veya bir hedefe ulaşılmasını tehlikeye atabilecek çeşitli faktörleri belirlemek ve değerlendirmek için kullanılan bir tekniktir. Bu faktörler, proje için bir tür tehdit oluşturabilir. Bu nedenle risk analizi, kuruluşun hedeflerine ulaşılmasında savunmasız olan bu tür tehditlerin bilimsel olarak değerlendirilmesi sürecini kapsar.

Risk analizi tekniği, bu tür tehdit edici faktörlerin ortaya çıkma olasılığını azaltmak için önleyici tedbirlerin tanımlanmasında yararlıdır. Ticarette kuruluşun rekabet gücü üzerinde yıkıcı etkilerden kaçınmak için bu tür sınırlamalarla başarılı bir şekilde başa çıkmak için çeşitli karşı önlemlerin tanımlanmasını içerir.

BT endüstrisinde popülerlik kazanan risk analizi tekniklerinden biri de FRAP – (Kolaylaştırılmış Risk Analizi Süreci) olarak bilinir.

Risk değerlendirmesi nedir?

Risk değerlendirmesi, bilinen bir tehdit durumuyla ilişkili riskin miktarını ve kalitesini bulmayı içerir. Organizasyona yönelik tehditlerin zarar verici etkilerinin olasılığını değerlendirmek için mevcut güvenlik ve çevre konularının kapsamlı bir değerlendirmesini kapsar. Risk değerlendirmesi, bir risk yönetimi sürecindeki ilk ve en önemli adımdır.

İş etki analizi veya BIA nedir?

İş etki analizi, kuruluşun operasyonları için kritik işlevleri keşfetme sürecini ifade eder. İş etki analizi çabasının sonucu, organizasyondaki kritik ve kritik olmayan işlevleri birbirinden ayırmaktır. Bir işlev, sonuçları kuruluş için kabul edilemez olduğunda veya yasalarca dikte edildiğinde veya müşteri tarafından zorunlu kılındığında veya dahili operasyon kısıtlamaları olduğunda veya kabul edilemez mali sonuçlara sahip olduğunda kritik kabul edilir.

Risk yönetimi nedir?

Risk yönetimi, bir tehditle ilişkili belirsizliği yönetmek için yapılandırılmış bir metodolojidir. Risk yönetimi, riski yönetmek için stratejilerin geliştirilmesini içerir.

– Riskin başka bir tarafa devri

– Riski tamamen önlemek için önlem alın.

– Kaçınılmaz riskin zarar verici etkilerini azaltmaya yönelik önlemlerin benimsenmesi

– Belirli bir riskin sonuçlarının bir kısmını veya tamamını kabul etmeye karar verin.

Yazılım ürünüyle ilişkili risklerden bazıları aşağıda açıklanmıştır:

1) Ürün boyutuyla ilgili riskler:

Yazılım ürününün boyutu, beklentilere göre beklenmedik derecede yüksek bir sapmaya maruz kaldığında da tehdit oluşturabilir. En iyi uygulama olarak, ürün beklentileri geçmişte karşılaşılan benzer durumlarla karşılaştırılır ve geçmiş olaylardan öğrenilir.

Yazılım ürününün boyutuyla ilişkili risklerden bazıları şunlar olabilir:

– Ürünün boyutuna ilişkin yargı bir tehdit olabilir.

– Ürünü kullanan kullanıcıların sayısına ilişkin yargı bir tehdit olabilir.

– İlişkili veritabanının boyutuna ilişkin yargı bir tehdit olabilir

– Ürün gereksinimlerindeki kontrolsüz değişiklikler, ürün boyutu için bir tehdit olabilir.

2) İşletme üzerinde etkisi olan riskler:

İş performansını etkileyebilecek belirli türde tehditler veya riskler vardır. Bu tür riskler şöyledir:

– Şirketin gelirini etkileyen yazılım ürününün kalitesi.

– Teslimattaki gecikmelerin maliyetleri de dahil olmak üzere, şirketin işini etkileyen ürün teslim tarihleri.

– Şirketin işi üzerinde etkisi olan tutarsız müşteri ihtiyaçları.

– Şirketin işi üzerinde etkisi olan ürünü kullanması beklenen kullanıcı sayısında büyük değişiklik.

– Müşteri tarafından beklenen yetersiz yardım / belge.

3) Müşterilerle ilgili riskler:

Her müşterinin ihtiyaçları gibi farklı bir kişiliği vardır. Müşterileri davranışlarına ve kendilerine teslim edilen ürüne tepkilerine göre aşağıdaki şekilde sınıflandırabiliriz.

– Bir ürünü, teslim edildiğinde olduğu gibi memnuniyetle kabul eden müşteri türü

– Kendilerine teslim edilen ürünün kalitesinden şikayet eden ve sıklıkla şikayet eden müşterilerin türü. Bu tür müşteriler, projeyi yöneten proje yöneticisi için makul miktarda tehdit oluşturur.

– Ürün geliştirme şirketiyle önceden ilişkisi olan müşterilerin türü.

– Ürün hakkında iyi bir teknik bilgiye sahip müşteri tipi.

– Ürünün kullanımını oldukça iyi bilen müşteri tipi.

– Yazılım mühendisliği sürecini iyi anlayan müşteri türleri.

– SDLC sırasında inceleme sürecine katılmaya hazır olan müşteri türleri

– Ürün hakkında fazla bilgisi olmayan ve ürün geldiğinde kullanmaya başlayan müşteri tipi

– Ürün gereksinimleri / beklentileri konusunda teknik olarak net olan ve proje kapsamını net bir şekilde tanımlayabilen müşteri tipi.

4) Yazılım mühendisliği süreciyle ilgili riskler:

Tüm yazılım mühendisliği sürecinin net bir şekilde tanımlanması, ürünün başarısı için son derece önemlidir. Kötü planlanmış bir süreç, kendisine ve organizasyona büyük tehditler oluşturan bir yazılım ürününe neden olacaktır.

Yönergeleri / kontrol listelerini takip etmek, yazılım mühendisliğiyle ilgili tehditleri belirlemede ve karşı önlemlerinizi planlamada yardımcı olabilir.

– Yazılım ürününün geliştirilmesi için planlanan dokümante edilmiş bir sürecin kullanılabilirliğini sağlayın.

– Ürün geliştirme ekibinin (iç veya dış) tüm katılımcılarının belgelenmiş süreci dini olarak takip etmesini sağlayın.

– Varsa, üçüncü taraf geliştiricilerin ve test uzmanlarının etkinliklerini ve performansını izlemek için bir mekanizmanın kullanılabilirliğini sağlayın.

– Geliştirme ekipleri ve test ekipleri tarafından gerçekleştirilen teknik incelemeleri düzenli olarak izleyebilecek birinin aktif katılımını sağlayın.

– Ne tür yazılım hatalarını keşfetmek için uygulanan kaynakları detaylandıran teknik incelemelerin sonuçlarının yeterli dokümantasyonunu sağlayın.

– Halihazırda tanımlanmış temel gereksinimlere uygun olarak ürünün tasarımında, geliştirilmesinde ve test edilmesinde yeterli tutarlılığı sağlamak için bir konfigürasyon yönetim mekanizmasının mevcudiyetini sağlayın.

– Müşteri tarafından zaman zaman ortaya çıkan ürün gereksinimlerindeki değişiklikleri idare etmek için bir mekanizmanın kullanılabilirliğini sağlayın. Böyle bir sistem, bu tür değişikliklerin yazılım ürünü üzerindeki etkisini analiz edebilmelidir.

5) Geliştirme Teknolojisine İlişkin Riskler:

Çoğu zaman, teknolojik faktörler de yazılım ürününün başarısı için büyük bir tehdit oluşturmaktadır. Yönergeleri / kontrol listelerini takip etmek, teknolojiyle ilgili tehditleri belirlemede ve karşı önlemlerinizi planlamada yardımcı olabilir.

– Yazılım uygulamasını oluşturmak için kullanılan tamamen yeni bir teknoloji, kuruluş için bir tehdit olabilir.

– Bazı yeni konfigürasyonların yazılım ve donanımı arasında uygun bir arayüz geliştirilmedikçe, bir tehdit nedeni olabilir.

– Veritabanı sisteminin işlevi, performansı ve arayüzü söz konusu uygulama alanında test edilmedikçe bir tehdit nedeni olabilir.

– Üründen beklendiği gibi tamamen yeni veya oldukça özelleşmiş bir arayüz gereksinimi de bir tehdit oluşturabilir

– Belirli bir tasarım türü ve test araçları ve teknikleri için bazı özel gereksinimlere olan talep, endişe veya risk nedeni olabilir.

– Müşteri tarafından empoze edilen çok fazla yapılandırılmış gereksinim, ürün performansı üzerinde çok fazla baskı oluşturabilir

– Ürün geliştirme ekiplerinin kullanabileceği yetersiz üretkenlikle ilgili ölçütler ve kaliteyle ilgili ölçütler, düşük kaliteli ürünlerin ortaya çıkma riskini oluşturabilir.

6) Geliştirme ve test araçlarıyla ilgili riskler:

Farklı geliştirme ve test araçları türleri de SDLC sırasında birçok kez endişe kaynağı olabilir.

– Bazı tipik analiz yöntemlerinin kullanılması endişe kaynağı olabilir.

– Bazı tipik dokümantasyon metodolojilerinin kullanılması endişe kaynağı olabilir.

– Test senaryolarını tasarlamak için bazı tipik yöntemlerin kullanılması endişe verici olabilir.

– Proje faaliyetlerini yönetmek için tipik araçların kullanılması endişe verici olabilir.

– SDLC sırasında konfigürasyon yönetimi için belirli araçların kullanılması endişe verici olabilir.

– Prototipleme için belirli araçların kullanılması endişe verici olabilir.

– Yazılım test sürecini desteklemek için belirli araçların kullanılması endişe verici olabilir.

– Belge yönetimi için belirli araçların kullanılması endişe kaynağı olabilir.

7) Geliştirme ortamıyla ilgili riskler:

Ürün geliştirme için sağlanan ortam, ürünün başarısında da kilit rol oynar. Aşağıda açıklanan faktörlerden veya durumlardan bazıları bazı riskler oluşturabilir.

– Yazılım ürününü ve geliştirme süreçlerini yönetmek için uygun bir aracın mevcudiyeti.

– Tasarım ve analiz faaliyetlerini yürütmek için uygun bir aracın mevcudiyeti.

– Oluşturulan ürünün tasarımı ve analizi için uygulanan araçların performansının yeterliliği.

– Oluşturulan ürünle uyumlu uygun kod üreteçlerinin veya derleyicinin kullanılabilirliği

– Oluşturulan ürünle uyumlu uygun test araçlarının mevcudiyeti.

– Oluşturulan ürünle uyumlu yeterli konfigürasyon yönetim araçlarının mevcudiyeti.

– Veritabanlarının konuşlandırıldıkları ortamla uyumluluğu.

– Tüm yazılım araçlarının birbiriyle uyumluluğu veya doğru entegrasyonu

– Araçların uygulanmasıyla ilgili tüm ilgili ekip üyelerinin becerilerinin / eğitimlerinin yeterliliği.

8) Geliştirme personelinin kalitesiyle ilgili riskler:

Daha az vasıflı personelin elinden çıkan bir ürün, kesinlikle organizasyon için bir risk nedeni olmalıdır. Aşağıdaki kontrol listesi, bu alandaki boşlukların kapatılmasına yardımcı olacaktır.

– Projeye uygun mümkün olan en iyi becerilere sahip personelin görevlendirilmesi

– Bir takımdayken, farklı mizaç ve yetenek seviyelerine sahip birkaç personelin doğru karışımı önemlidir.

– Proje süresince görevlendirilen personelin mevcudiyeti hayati önem taşımaktadır. Hangi sebeple olursa olsun, insanlar yollara çıkarsa proje ciddi şekilde etkilenecektir.



KaynakYogindernath Gupta

Bir cevap yazın

E-posta hesabınız yayımlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir