Bölüm 7 Risk Analizi Software Engineering: A Practitioner’s Approach,

... konulu sunumlar: "Bölüm 7 Risk Analizi Software Engineering: A Practitioner’s Approach,"— Sunum transkripti:

1 Bölüm 7 Risk Analizi Software Engineering: A Practitioner’s Approach,
Modified from Software Engineering: A Practitioner’s Approach, by Roger S. Pressman For non-profit educational use only May be reproduced ONLY for student use at the university level when used in conjunction with Software Engineering: A Practitioner's Approach, 7/e. Any other reproduction or use is prohibited without the express written permission of the author. All copyright information MUST appear if these slides are posted on a website for student use.

2 Proje Riskleri Ne yanlış gidebilir? Olma ihtimali nedir?
Zarar ne kadar olacak? Nasıl çözüm bulunabilir?

3 Tepkisel (Reaktif) Risk Yönetimi
riskler oluştuğu zaman proje takımı tepki gösterir hafifletme (mitigation)—mücadele için ek kaynak kullanım planı yap hataların tamiri—hata ortaya çıktığında kaynaklar temin edildi ve uygulandı kriz yönetimi—hata harcanan kaynaklara tepki vermez ve proje tehlikededir

4 Önleyici (Proactive) Risk Yönetimi
usule uygun risk analizi yapılır organizasyon riske neden olabilecek kökü tespit eder / düzeltir TQM kavramları ve istatistiksel SQA yazılım sınırları dışında kalan risk kaynaklarının incelenmesi değişimleri yönetebilme yeteneğinin geliştirilmesi

5 Yedi Prensip 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.

6 Risk Yönetim Paradibması
kontrol et izle RİSK belirle planla analiz et

7 Riskin Belirlenmesi Ü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.

8 Proje Risklerinin Belirlenmesi -I
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ı?

9 Proje Risklerinin Belirlenmesi -I
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?

10 Risk Bileşenleri 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.

11 Risk Projeksiyonu 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.

12 Bir Risk Tablosu Oluşturma
İhtimal etki RMMM Risk giderme izleme ve Yönetimi Mitigation Monitoring & Management

13 Bir Risk Tablosu Oluşturma
Olma ihtimalini tahmin et 1-5 arasında projenin etkisini tahmin et. 1 = proje başarısı üzerindeki en düşük etki 5 = proje başarısındaki felaket etkisi tabloyu ihtimal ve etkiye göre sırala

14 Riske Maruz Kalma (Etkisi)
Risk etkisi (RE) aşağıdaki formül ile hesaplanır. [Hal98]: RE = P x C P riskin olma olasılığıdır C riskin olmasının projeye maliyeti

15 Risk Etkisi Örneği 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.

16 Risk Giderme, İzleme ve Yönetimi
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?

17 Ürün Boyutuna göre Risk
Riski etkileyen özellikler: • ürün boyutu LOC olarak mı FP olarak mı tahmin edildi? • ürün boyutu program , dosya, transaction sayısı olarak mı tahmin edildi? • önceki ürünlerin boyut ortalamalarına oranla % sapma ne kadar? • ürün tarafından oluşturulan veya kullanılan veritabanı boyutu nedir? • ürünün kullanıcı sayısı nedir? • ihtiyaçlar için tahmin edilen değişiklik sayısı nedir? • tekrar kullanılabilir yazılım miktarı? ürün için ? teslimattan önce ? teslimattan sonra

18 İş Etkisine göre Risk Riski etkileyen özellikler :
• bu ürünün şirket gelirlerine etkisi nedir? üst yönetim tarafından ürünün görünürlüğü nedir? teslimat tarihinin mantıklı olup olmaması? Ürünü kullanacak müşteri sayısı nedir? birlikte çalışabilirlik kısıtları nelerdir? son kullanıcının uzman olup olmaması? üretilecek ve müşteriye teslim edilecek dökümentasyonun miktarı ve kalitesi nedir? yönetim ile ilgili kısıtlamaları geç teslimat maliyeti nedir? defolu / yetersiz ürün ile ilgili maliyetler nelerdir?

19 Müşteriye göre Risk Cevaplanması gereken sorular:
• Daha önce müşteri ile çalıştın mı? Müşteri sana zaman ayıracak mı? Müşteri gözden geçirmelere katılmaya istekli mi?_ Müşteri teknik olarak uzman mı? Müşteri, senin elemanlarının işlerini yapmalarına izin verecek mi? Müşteri yazılım geliştirme sürecini anlıyor mu?

20 Sürece göre Risk Cevaplanması gereken sorular:
• Alışılagelmiş süreç anaçatısınımı tercih ettin? Proje takımı tarafından takip ediliyor mu? Yazılım mühendisliği için yönetim desteği alıyormusun? SQA için proaktif (önleyici tedbirler) bir yaklaşım mı sergiliyorsun? Usulune uygun teknik gözden geçirmeler olur mu? CASE araçları analiz, tasarım ve test için kullanıldımı? Araçlar birbirleriyle uyumlu mu? doküman formatları ayarlandımı?

21 Teknolojik Riskler Cevaplanması gereken sorular:
• Teknoloji şirketin için yeni mi? Yeni algoritmalar, I/O teknoloji gerekiyormu? Uygulama, yeni yazılımla bağlantı kurabiliyor mu (interface) ? Yeni veya denenmemiş donanım içeriyor mu? Uygulama radikal olarak farklı mı? Yeni yazılım mühendisliği metotları kullanıyormusun? Geleneksel olmayan yeni metotlar kullanıyormusun, AI- metotları gibi Önemli performans şartı var mı? Yapılabilirliğinden şüphelenilen istek var mı?

22 Personel Riskleri Cevaplanması gereken sorular:
• En iyi kişiler işe dahil mi? Personel doğru yeteneklere sahip mi? Yeterli personel var mı? Personel proje süresince duracak mı? Bazılar kısmi zamanlı mı çalışıyor Personelin doğru beklentileri mi var Personel gerekli eğitimi aldımı? Personel arası iş devri düşük mü olacak?

23 Risk Bilgisinin Kaydı Project: Embedded software for XYZ system
Risk type: schedule risk Priority (1 low critical): 4 Risk factor: Project completion will depend on tests which require hardware component under development. Hardware component delivery may be delayed Probability: 60 % Impact: Project completion will be delayed for each day that hardware is unavailable for use in software testing Monitoring approach: Scheduled milestone reviews with hardware group Contingency plan: Modification of testing strategy to accommodate delay using software simulation Estimated resources: 6 additional person months beginning in July