Bölüm 6 Yazılım Planlama 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.

Yazılım Projesi Planlama Proje planlamanın bütün amacı, karmaşık bir projenin kontrol edilmesi, gözlemlenmesi ve izlenmesi için bir strateji geliştirmektir. Neden Ürünün zamanında ve kaliteli bir şekilde teslimi için.

Proje Planlama Görev Kümeleri -I Proje kapsamını tespit et Yapılabilirliği (fizibilite) belirle Riskleri analiz et Risk analizi daha sonra işlenecek Gerekli kaynakları tanımla Gereken insan kaynaklarını belirle Tekrar kullanılabilir yazılım kaynaklarını belirle Çevresel kaynakları belirle

Proje Planlama Görev Kümeleri -II Maliyet ve çabayı (effort) tahmin et Problemi bileşenlerine ayır Boyut, fonksiyon noktaları, süreç görevleri veya kullanım durumlarını (use-cases) gözönüne alarak iki veya daha fazla tahmin belirle Tahminleri detaylandır, karşılaştır Bir proje takvimi geliştir Takvim geliştirme daha sonra tartışılacaktır. Manalı görev kümeleri belirle Görev ağı tanımla Takvim yapma araçlarını kullanarak takvimi hazırla Takvim izleme mekanizması tanımla

Tahmin Bir yazılım mühendisliği çalışmasının gerektirdiği kaynakların, maliyetin ve takvimin tahmini tecrübe iyi geçmiş bilgilere (metrik) erişim varolan kaliteli bilgilerin kullanılarak elle tutuluk bir tahminlerin yapılabilmesi cesareti Tahmin yapısında riski içerir ve bu rist belirsizliğe neden olabilir.

Kayıt altına al! Proje Kapsamı Yazılım Tahminler Projesi Riskler Planı Takvim Kontrol stratejisi Yazılım Projesi Planı

Kapsamı Anlamak için ... Müşteri ihtiyaçlarını anla iş konteksini (şartlarını) anla proje sınırlarını anla müşterinin motivasyonunu (hareket noktasını) anla değişiklikler için olası yolları anla anlaşılmalıki ... Anlasan bile hiçbir şey garanti altına alınmamıştır.

Kapsam nedir? Yazılım kapsamı aşağıdakileri tanımlar son kullanıcıya teslim edilecek fonksiyon ve özellikler girdi ve çıktı olarak kullanılacak veriler yazılımın kullanılması neticesinde kullanıcılara sunulacak içerik sistemi sınırlayan performans, sınırlamalar, arabirimler ve güvenilirlik iki teknikten birisi kullanılarak kapsam tanımlanır: Bütün paydaşlarla yapılan iletişimden sonra yazılım kapsamının hikayemsi tarifi ve açıklaması. Son kullanıcılar tarafından geliştirilen kullanım durumları (use-case)

Kapsamın Belirlenmesinin Aşamaları - 1 İlk aşamada kapsam-bağımsız (Context-free) sorular sorularak: problemi, çözüm isteyen kişileri, istenen çözümü ve çözümün etkinliliğini anlamaya çalışılır. Bu işin yapılmasını kim istiyor? Kim kullanacak? Başarılı bir çözümün ekonomik yararı ne olacaktır? Çözüm için başka bir kaynak varımıdır?

Kapsamın Belirlenmesinin Aşamaları - 2 2. aşamada problemi daha iyi anlamaya ve müşterinin fikirleri anlamaya çalışılır. Başarılı bir çözüm üretildiğinde iyi bir çıkış (çıktı) sizin (müşteri) için ne ifade eder? Bu çözüm hangi problemlere yönelik olacak? Çözümün kullanılacağı ortamı gösterir misiniz? Çözüm ile ulaşılması gereken performans ölçütleri ve şartları var mı?

Kapsamın Belirlenmesinin Aşamaları - 3 3. aşamada toplantı etkinliliğini arttırmayı amaçlar. Bu sorulara cevap verecek doğru kişi sizmisiniz? Cevaplar resmi mi? Sorularım sizin probleminizle alakalımı? Çok fazla soru mu soruyorum? Ekstra bilgi sağlayabilecek başka kişi var mı? Sormak gereken başka bir şey var mı?

Kapsamın Belirlenmesinin Aşamaları Bu aşamalardaki amaç iletişimi sağlamaktır “break-the-ice”

Kaynaklar (şekil 5.2) kişi çevresel proje kullanılabilir yazılım sayı yetenek sayı yer kullanılabilir yazılım OTS komponentleri tam-tecrübe yeni komponent kısmı-tecrübe çevresel donanım araçları ağ kaynakları

Kullanılabilir Yazılım Parçaları Off-the-shelf bileşenler (component) Tam-tecrübe edilmiş bileşenler Kısmi-tecrübe edilmiş bileşenler Yeni bileşenler

Yazılım Projesi Tahmini Önceleri yazılımlar sistemlerin maliyetinin küçük bir kesimini oluşturuyordu. Şimdilerde yazılım sistemlerin büyük bir kesimini oluşturmaktadır. Dolayısı ile yazılım proje maliyet tahmin hatası sistemi yararda sağlayabilir kayıp da. Tahmin işlemini insan, teknik, çevre ve stratejik-politik değişkenler etkileyebilir.

Yazılım Projesi Tahmini Projenin kapsamı anlaşılmalıdır Detaylandırma(bileşenlerine ayırma) gereklidir Geçmiş metrikler yardımcıdır En az iki farklı teknik kullanılmalıdır Belirsizlik kaçınılmazdır

Tahmin Teknikleri Geçmiş benzer proje tecrübesi Geleneksel tahmin teknikleri görev parçalama ve analizi ve çaba tahmini boyut (FP. gibi) tahmini Deneysel (Empirical) modeller Otomatikleşmiş araçlar

Tahminin Doğruluğunu Etkileyen Bileşenler Aşağıdakiler aracılığı ile ifade edilir/ doğrulanır. inşa edilecek ürünün planlayıcı tarafından düzgün bir şekilde tahmin derecesi boyut tahminini insan gücü, takvim zamanı ve para cinsine dönüştürebilme becerisi (geçmişteki projelerden elde edilen güvenilir yazılım metriklerinin kullanılabilirliğinin fonksiyonu) yazılım takımının yeteneklerinin proje planına yansıma derecesi yazılım mühendisliği çabalarının destekleyen çevre ve ürün ihtiyaçlarının dengesi Bu bölümde yazılım boyutlandırılmasına yoğunlaşılacaktır. Yazılım boyutu yapılacak işin boyutunu belirler.

Yazılım Boyutlandırma Yazılım boyutlandırma için 4 farklı yaklaşım vardır. Bulanık mantık boyutlandırma: Yaklaşım teknikleri kullanılır. Fonsiyonel nokta boyutlandırma: Standart bileşen boyutlandırma: Burada amaç sistemde kullanılan standart bileşenlerin (rapot, LOC vs) sıklığının belirlenmesinden sonra tecrübelere dayalı bir tahmin yapılmasıdır. Değişen boyutlandırma: Varolan projede tekrar kullanım, kod değişimi, kod silinmesi gibi durumlar olmasında kullanılır.

Bileşenlerine Ayırma Problemin bileşenlerine ayrılması Sürecin bileşenlerine ayrılması

Fonksiyonel Bileşenlerine Ayırma Kapsamın ifadesi fonksiyonel bileşenlerine ayırma Gramatik çözümleme uygula

Geleneksel Yöntemler:LOC/FP Yaklaşımı bilgileri kullanarak LOC/FP değerlerini hesapla proje tahmini için geçmiş verileri kullan These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.

Örnek Bir CAD sistemi geliştirilecektir. Sistem bir iş istasyonunda çalıştırılacaktır Çeşitli grafik donanımları kullanılacaktır: fare, digitizer, yüksek çözünürlüğü olan monitör, lazer yazıcı. Yazılım 2d ve 3d geometrik veriyi giriş olarak alacaktır. Mühendis iyi bir kullanıcı arabirimi ile CAD sistemini kullanacaktır. Bütün geometrik veri desteği ve gerekli diğer destekler CAD veritabanında olacaktır. Tasarım analiz modülü gerekli çıktıyı üretecektir ve bu çıktı çeşitli grafik donanımları tarafından görüntülenecektir.

Örnek: LOC Yaklaşımı Bu tipteki bir sistem için ortalama üretkenlik = 620 LOC/pm (ayda). Yüklenmiş işgücü oranı =$8000 her ay, herbir satırım maliyeti yaklaşık $13. LOC tahminlerine ve geçmiş üretkenlik verilerine bağlı olarak toplam tahmini proje maliyeti $431,000 ve tahmini insan gücü 54 kişi-ay.

3d Geometric Analysis Function Hesabı optimistic 4600 LOC muhtemel 6900 LOC kötümser 8600 LOC Hesabı – ayırlıklı ortalama kullanılarak Expected Value=(sopt+4smuh+skötümser)/6

Örnek: FP Yaklaşım Türetilen tahmini FP sayısı : FPtahmini = sayı-toplam X [0.65 + 0.01 X Topla (Fi)] FPtahmini = 37^2 organizasyonel ortalama üretkenlik = 6.5 FP/pm. Yüklenmiş işgücü oranı = $8000 her ay, yaklaşık $1230/FP. FP tahminlerine ve geçmiş üretkenlik verilerine bağlı olarak toplam tahmini proje maliyeti $461,000 ve tahmini insan gücü 58 kişi-ay.

Süreç-tabanlı Tahmin süreç anaçatısından bulundu anaçatı aktiviteleri uygulama fonksiyonları herbir uygulama fonksiyonu için herbir anaçatı aktivitesi tarafından ihtiyaç duyular çaba.

Süreç-tabanlı tahmin örneği Aylık 8000 dolar ortalama yüklenmiş işgücü oranına dayanarak, toplam tahmini proje maliyeti $368,000 ve toplam tahmini çaba 46 kişi-aydır

Araç-tabanlı Tahminler proje karakteristikleri kalibrasyon faktörleri LOC/FP verisi

Kullanım-durumları ile Tahminler Bu tip bir sistem için ortalama üretkenlik 620 LOC/pm ve yüklenmiş işgücü oranı aylık $8000 kullanılarak herbir satır için maliyet yaklaşık 13dolardır. Kullanım durumları tahminlerine ve geçmiş üretkenlik verilerine dayanarak, toplam tahmini proje maliyeti $552,000 ve tahmini çaba 68 kişi-aydır..

Deneysel Tahmin Modelleri Genel form: üs çaba = ayar katsayısı * boyut genellikle kişi-ay olarak üretilir deneysel olarak türetilmiş genellikle LOC tur fakat FP de olabilir. ya bir sabittir veya proje karmaşıklığına göre üretilmiş bir sayıdır.

COCOMO-II Constructive Cost Model COCOMO II aşağıdaki alanları işaret eden hiyerarşik bir tahmin modelidir: Uygulama bileşim modeli. Yazılım mühendisliğinin ilk aşamalarında kullanılır (kullanıcı arabirimleri prototiplenirken, yazılım ve sistem etkileşimi gözönüne alındığında, performan değerlendirmesinde ve teknoloji olgunluğu değerlendirmesi üstün olduğu zaman. Erken tasarım aşaması modeli. İhtiyaçlar sabitlendiği zaman ve temel yazılım mimarisi kurulduğu zaman kullanılır. Mimari-sonrası aşaması modeli. Yazılımın inşası sırasında kullanılır.

Yazılım Eşitliği Dinamik çokdeğişkenli bir model E = [LOC x B0.333/P]3 x (1/t4) E = kişi-ay veya kişi-yıl cinsinden efor t = ay veya yıl cinsinde proje süresi, B = “özel yetenek faktörü” P = “üretkenlik parametresi”

OO Projeleri için Tahmin-I Çaba bileşenlerine ayırma, FP analizi ve geleneksel uygulamalar için uygulanabilir herhangi bir metod kullanarak tahminler geliştir. Nesne yönelimli ihtiyaç modelleme kullanarak (sonra işlenecek) kullanım-durumlarını geliştir ve sayısını belirle. Analiz modelinden, anahtar sınıfların sayısını belirle (analiz sınıfları da denir). Uygulama için arabirim tiplerini kategorize et ve destek sııfları için bir çoğullayıcı geliştir: Arabirim tipi Çoğullayıcı No GUI 2.0 Text-based user interface 2.25 GUI 2.5 Complex GUI 3.0

OO Projeleri için Tahmin-II Anahtar sınıf sayıları ile çoğulayıcıları çarp ve destek sınıfları sayısı için bir tahmin bul. Toplam sınıf sayısı ile (anahtar+destek) herbir sınıf için iş-birim ortalama sayısı ile çarp. Lorenz ve Kidd’in önerisi herbir sınıf için 15-20 kişi- gündü. sınıf tabanlı tahmini herbir kullanım-durumu iş- birimlerinin ortalama sayısının çarpımı ile çapraz kontrol et.

Çevik Projeler için Tahmin Herbir kullanıcı senaryosu amaçların tahmini için ayrı ayrı değerlendirilir. Geliştirme için senaryo yazılım mühendisliği görevlerine ayrılır. Herbir görev ayrı ayrı tahmin edilir. Not: Tahmin geçmiş veriye dayalı, deneysel veya tecrübe ile olabilir. Alternatif olarak, senaryonun hacmi, LOC, FP veya diğer hacım tabanlı ölçümler ile tahmin edilebilir. Herbir görev için tahminler, senaryonun tahminin bulunması için toplanır. Alternatif olarak, senaryo için hacim tahminleri geçmiş veriler kullanılarak çaba (efor) cinsine çevrilir. Bir yazılım arttırımı için uygulanacak senaryoların çaba tahminleri, arttırım için çaba tahmini geliştirmek amacıyla toplanır.

Yap-satınal (make-buy) kararı

Beklenen Maliyeti Hesaplama (yol olasılığı) x (tahmini yol maliyeti) i i örnek olarak, inşa için beklenen maliyet: beklenen maliyet = 0.30 ($380K) + 0.70 ($450K) inşa = $429 K benzer olarak, beklenen maliyet = $382K tekrar kullan beklenen maliyet = $267K satın al beklenen maliyet = $410K kontrat