Geniş bir bakış açısı sağlanmak—sistem ve iş problemleri kapsamında yazılım risklerinin sezilmesi
Geniş bir bakış açısı sağlanmak—sistem ve iş problemleri kapsamında yazılım risklerinin sezilmesi
İleriye dönük bakış açısı kazanmak—gelecekte olabilecek risklerin düşünülmesi, ani durum planının oluşturulması
Özgürce fikir beyanını teşvik etmek—eğer birisi potansiyel bir riskten bahsederse, ihmal etme.
Bütünleştir (entegrasyon)—risklerin düşünülmesi, yazılım sürecine entegrasyonu ile mümkün olabilir.
Sürekli süreci önemse—daha fazla bilgi temin edildikçe belirlenen risklerin düzeltilmesi ve daha iyi bakış açılarının kazanılmasıyla birlikte yeni risklerin tespitinde, takım yazılım süresi boyunca uyanık/dikkatli olmalıdır.
Paylaşımlı ürün vizyonu geliştir—eğer bütün ortaklar yazılım hakkında aynı vizyona sahip olursa, daha iyi risk tespitinin ve değerlendirmesinin yapılması muhtemeldir.
Takım çalışmasını teşvik et—yetenekler, kabiliyetler ve bilgiler aynı havuzda toplanmalıdır.
Ürün boyutu—riskler üretilecek veya modifiye edilecek yazılımın toplam boyutu ile ilişkilidir.
Ürün boyutu—riskler üretilecek veya modifiye edilecek yazılımın toplam boyutu ile ilişkilidir.
İş etkisi (faktörü)—riskler yönetim veya pazar nedeniyle oluşan kısıtlamalarla ilişkilidir.
Müşteri karakteristikleri—riskler müşterinin sofistike olmasıyla ve geliştiricinin müşteri ile iletişim yeteneğiyle ilişkilidir.
Süreç tanımı—riskler, yazılım süreçlerinin tanımlanmasının dereceleriyle ve takip edilen geliştirme organizasyonun ilişkilidir.
Geliştirme ortamı—riskler ürünü üretmek için kullanılan araçların kalitesiyle ve kullanılabilirliğiyle ilişkilidir.
İnşa edilecek teknoloji—riskler inşa edilecek sistemin karmaşıklığıyla ve “son teknoloji” olup olmamasıyla ilişkilidir.
Eleman sayısı ve tecrübesi—riskler çalışan yazılım mühendislerinin teknik ve proje tecrübeleriyle ilişkilidir.
Projeyi üst düzey yazılım ve müşteri yöneticileri destekleyeceklerini resmen ifade ettiler mi?
Projeyi üst düzey yazılım ve müşteri yöneticileri destekleyeceklerini resmen ifade ettiler mi?
Son kullanıcılar inşa edilecek projeyi/sistemi desteklemeye istekliler mi?
İhtiyaçlar yazılım mühendisliği takımı ve onların müşterileri tarafından tamamen anlaşıldı mı?
Müşteriler ihtiyaçların tanımlanmasına dahil oldular mı?
Son kullanıcıların gerçekçi beklentileri var mı?
Proje kapsamı dengelimi/ sabitmi?
Proje kapsamı dengelimi/ sabitmi?
Yazılım mühendisliği takımı uygun yetenekleri içeriyormu?
Proje ihtiyaçları dengelimi / sabit mi?
Proje takımının uygulanacak teknoloji ile ilgili tecrübesi var mı?
Proje takımındaki kişi sayısı, işi yapmak için yeterli mi?
Müşteriler projenin önemi konusunda ve proje ihtiyaçları konusunda hemfikir mi?
performans riski—ürünün, ihtiyaç olunanı karşılama ve amacına uygunluğunu karşılama belirsizliğinin derecesi.
performans riski—ürünün, ihtiyaç olunanı karşılama ve amacına uygunluğunu karşılama belirsizliğinin derecesi.
maliyet riski—proje bütçesinin yeterli olup olmamasındaki belirsizliğin derecesi.
destek riski—üretilen projenin kolay düzeltilebilir, adapte olabilir ve güçlendirilebilir olup olmamasındaki belirsizliğin derecesi.
takvim riski—proje takviminin yeterli olup olmamasındaki ve zamanında teslim edilip edilmemesindeki belirsizliğin derecesi.
Risk projeksiyonu, riski tahmini olarak da isimlendirilir, herbir riski iki şekilde notlandırmaya/derecelendirmeye çalışır.
Risk projeksiyonu, riski tahmini olarak da isimlendirilir, herbir riski iki şekilde notlandırmaya/derecelendirmeye çalışır.
riskin gerçek olma ihtimali veya olasılığı
riskle ilişkili problemlerin olası sonuçları.
Dört risk projeksiyon adımı vardır. :
riskin farkedilme ihtimalini yansıdan bir ölçek oluştur.
riskin sonuçlarını tasvir et
riskin proje ve ürün üzerindeki etkisini tahmin et,
yanlış anlamaya mahal vermemek için risk projeksiyonunun bütün doğruluğunu not et.
Risk kimliklendirme. Yazılım bileşenlerinin sadece %70’inin tekrar kullanılabilir olması kararlaştırıldı ve siteme entegre edilecek. Kanal kısım geliştirilmesi gerekmektedir.
Risk kimliklendirme. Yazılım bileşenlerinin sadece %70’inin tekrar kullanılabilir olması kararlaştırıldı ve siteme entegre edilecek. Kanal kısım geliştirilmesi gerekmektedir.
Risk ihtimali. %80 (muhtemel).
Risk etkisi. 60 tekrar kullanılabilir yazılım bileşeni planlandır. Eğer %70 i kullanılacaksa, 18 bileşen sıfırdan tekrar üretilecektir (planda üretilen yeni bileşenler hariç). Herbir bileşen 100 LOC olduğu için ve herbir LOC için 14 dolar maliyet gerekiyorsa. toplam maliyet 18 x 100 x 14 = 25,200 dolar.
Risk etkisi. RE = 0.80 x 25,200 ~ $20,200.
giderme (mitigation)—riskten nasıl kaçınırız?
giderme (mitigation)—riskten nasıl kaçınırız?
izleme (monitoring)—hangi faktörleri izlersek riskin çok veya az muhtemel olacağını belirleyebiliriz?
yönetim(management)—eğer risk gerçekleşirse hangi acil durum planını uygulamalıyız?
