©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 23Slide 1 Yazılımın Maliyetinin değerlendirilmesi Software Cost Estimation.

... konulu sunumlar: "©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 23Slide 1 Yazılımın Maliyetinin değerlendirilmesi Software Cost Estimation."— Sunum transkripti:

1 ©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 23Slide 1 Yazılımın Maliyetinin değerlendirilmesi Software Cost Estimation

2 ©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 23Slide 2 Ne öğrenilecek l Yazılım maliyetinin ve fiyatının belirlenmesinin temelleri l Yazılımın verimliliğinin ölçülmesi l Yazılımın değerlendirilmesinde farklı yöntemlerin kullanılması l COCOMO 2 algoritmik maliyet değerlendirme modeli

3 ©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 23Slide 3 Temel değerlendirme soruları l İşlemleri tamamlamak için ne kadar emek gerekmektedir? l İşlemleri tamamlamak için ne kadar zaman gerekmektedir? l İşlemlerin toplam maliyeti ne kadardır?

4 ©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 23Slide 4 Yazılım maliyeti bileşenleri l Yazılımın maliyeti-yazılım geliştirme süreci için gereken kaynakların değerlendirilmesi l Donanım ve yazılım maliyeti l Seyahat ve eğitim maliyeti l Emek maliyeti (ekser projelerde temel etken) Projeye katılmış mühendislerin maaşları Sosyal ve sigorta maliyetleri l Emeğin maliyetini etkileyen diğer etkenler: Bina, ısınma, aydınlatma maliyeti Ağ ve telekominikasyön maliyeti Ortak kullanım maliyetleri (kütüphane, kantin ve s.)

5 ©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 23Slide 5 Maliyet ve fiyatlandırma l Değerlendirme, geliştiricinin yazılım sisteminin maliyetini hesaplaması içindir. l Geliştirme maliyeti ile müşteriye bildirilen fiyat arasında basit bağlılık yoktur l Kurumsal, iktisadi, siyasi ve ticari etkenler fiyatlandırmayı etkiler

6 ©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 23Slide 6 Yazılımın fiyatını etkileyen etkenler l Pazarı kaybetmemek- geliştirici kurum yazılım pazarında yeni olması ve ya pazara yeni ürün sürmesi sebebinden yazılımı düşük fiyatla suna bilir. Bir projede az kar etmek onun gelecekte daha yüksek kar etmesine neden ola bilir. Kazanılmış deneğimler yeni ürünler geliştirmek için temeldir l Belirsizlik içinde fiyatbiçme- Eğer kurum yazılımın fiyatı hakkında tereddütlü ise yazılımın fiyatını yükselte veya normal değerinden daha düşük fiyata suna bilir l Anlaşmalı fiyat- Müşteri, programın kaynak kodunun geliştirici tarafından kullanılmasına veya geliştirilmiş sistemin (veya parçalarının) diğer projelerde de kullanılmasına izin vere bilir. Bu halde projenin fiyatı daha düşük olacak

7 ©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 23Slide 7 Yazılımın fiyatını etkileyen etkenler (devamı) l Gereksinimlerin değişkenliği- Eğer gereksinimler değişime meyilli ise geliştirici kurum projeyi almak için fiyatı düşüre bilir. Anlaşma imzalandıktan sonra ise gereksinimlerin değişmesiyle fiyat arttırılacaktır l Mali sorunlar- Mali sıkıntıları bulunan geliştirici projeyi kazanmak için düşük fiyat önere bilir. İş ortamında kalmak için az kar hiç yoktan daha iyidir

8 ©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 23Slide 8 l Zaman birimi içinde üretilmiş yararlı işlevsellik l Yazılım geliştirme sürecine katılmış mühendisin işini değerlendirme ölçümü l Kaliteye yönelik değildir Programcının verimliliği

9 ©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 23Slide 9 l Boyuta yönelik ölçümler - Bu ölçümler kaynak kodundan alınan kod satırları sayısı, nesne kodları ola bilir l İşleve yönelik ölçümler yazılımın işlevselliğine göre tahmin ediliyor. İşlev puanlar ve nesne puanları ölçümleri bu türden en yaygın kullanılan ölçümlerdir Verimliliğin ölçülmesi

10 ©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 23Slide 10 Yazılımın Verimliğinin ve Kalitesinin ölçülmesi l Yazılım Ölçümleri Boyuta Yönelik Ölçümler İşleve Yönelik Ölçümler l Yazılım Kalitesi için Ölçümler Kaliteyi Etkileyen Etkenler Kalite ölçümleri l Farklı Ölçme Yaklaşımlarının Karşılaştırılması l Yazılım Mühendisliği süreci dahilinde ölçümlerin bütünleştirilmesi

11 ©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 23Slide 11 Yazılım ölçümleri l Boyuta Yönelik ölçümler İşleve Yönelik Yöntemler Kişiye Yönelik Yöntemler Teknik Ölçümler Kalite Ölçümleri Verimlilik Ölçümleri

12 ©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 23Slide 12 Boyuta Yönelik Ölçümler l Yazılımın ve onun geliştirilme sürecinin doğrudan ölçülmesi Projeemek$KLOCBelg.sayf.sayısı Hata sayısı Kişi say. aaa-012416812.1365293 ccc-0462 440 2 27.21224865 fff-34331420.21050646.......

13 ©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 23Slide 13 l Kod satırı nedir? Programcıların her satırda bir komut yazdığı zamanlarda önerilmiş ölçüm Bir komut cümlesinin birkaç satıra yayıla bildiği veya bir satırda birkaç komutun yazıla bildiği çağdaş programlama dilleri ile ne kadar uyumludur? l Hangi programlar sistemin parçası sayılmalıdır? l Bu ölçmede sistemin boyutu ile belgelerin boyutu arasında doğrusal ilişki olduğu düşünülüyor Kod satırları sayısı

14 ©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 23Slide 14 Yazılımı Ölçme Kıstasları Boyuta yönelik ölçümler l Verimlilik = KS/kişi-ay l Kalite = hatalar/KS l Değer = $/KS l Belgeleme = belge sayfaları sayısı/KS (KS-kod satırları sayısı)

15 ©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 23Slide 15 İşlev puan l Programın aşağıdaki özelliklerinin kullanımına dayalıdır: Dış girişler ve çıkışlar Kullanıcı etkileşimleri Dış arayüzleri Sistemin kullandığı dosyalar l Bu özelliklerin her birisine ağırlık değerleri veriliyor l İşlev puan özelliklerin ağırlık değerlerine çarpılması ile alınmış sayıların toplamıdır

16 ©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 23Slide 16 İşlev puanların hesaplanması ÖlçmeparametresiSayı ağırlık etkeni ağırlık etkeni basit orta karm. basit orta karm. Kull. Girişleri sayısı X 3 4 6 = Kull. Çıkışları sayısı X 4 5 7 = Kullanıcı sorguları sayısı X 3 4 6 = Dosyalar sayısı X 7 10 15 = Dış arayüzleri sayısı X 5 7 10 = ayarlanmamış İP 

17 ©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 23Slide 17 İşlev Puanların (algoritma hesaba alınmakla) hesaplanması Ölçüm parametresi Sayı Sayı Ağırlık Ağırlık Kullanıcı girişleri sayısı X 4 = X 4 = Kullanıcı çıkışları sayısı X 5 = X 5 = Kullanıcı sorguları sayısı X 4 = X 4 = dosyalar sayısı X 7 = X 7 = Dış arayüzleri sayısı X 7 = X 7 = Algoritmalar X 3 = X 3 = ayarlanmamış İP 

18 ©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 23Slide 18 İşlevsel Nitelikler (Fi) l Sistem güvenilir yedekleme ve kurtarma gerektiriyor mu? l Veri iletişimine gerek var mı? l Dağıtık işlem işlevleri var mı? l Başarım çok ciddi mi? l Mevcut işletme ortamında sistem çalışacak mı? l Sistem çevrimiçi veriler gerektiriyor mu? l Esas kütükler çevrim içi güncelleniyor mu? l Giriş ve çıkışlar, kütükler, sorgular karmaşık mı? l Program dahilindeki işlemler karmaşık mı? l Tasarlanan program yeniden kullanılabilen olmalı mı? l Dönüştürme ve sistemi kurma tasarıma dahil mi? l Sistem farklı kurumlarda farklı donatımlar gerektiriyor mu? l Sistemin kullanıcı kolaylığı ve de kolay değiştirile bilme olanağı var mı?

19 ©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 23Slide 19 İşlevsel niteliklerin değerlendirilmesi l İşlevsel niteliklere (Fi) 0-5 arasında ağırlık değeri veriliyor Etkisi yok 0 Tesadüfi 1 Hafif 2 Orta 3 Önemli 4 Gerekli 5

20 ©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 23Slide 20 Yazılımı Değerlendirme Kıstasları İşlev puanların hesaplanması l İP=AİP x [0.65+0.01x  (Fi)] l ( AİP-ayarlanmamış işlev puanlar sayısı) l Verimlilik =İP/kişi-ay l Kalite =hatalar/İP l Değer=$/İP l Belgeleme = belge sayfaları sayısı/İP

21 ©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 23Slide 21 İşlev puan ve kod satırları sayısı l Projenin karmaşıklığı işlev puanlar sayısını etkiler l İşlev puanlar,verilmiş dil için bir işlev puanlar sayısına düşen kod satırları sayısı esasında ortalama kod satırları sayısını bulmak imkanı veriyor: KS = AVC * işlev puanlar sayısı; KS –kod satırları sayısı AVC –dile bağımlı etkendir-assemble dili için 200-300, 4GL için 2-40 arasında değişmektedir l İP’ler çok özneldir. Değerleri değerlendiriciye bağlıdır. İşlev puanların otomatik hesaplanması mümkün değildir

22 ©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 23Slide 22 Kod satırlar sayısı ve işlev noktalar sayısı arasındaki ilişki (AVC-etkeni) l Programlama Dilleri LOC/FP ( AVC etkeni ) Assembly 300 COBOL 100 FORTRAN 100 Pascal 90 Ada 70 Nesneye Yönelik diller 30 Dördüncü nesil Dilleri (4GL) 20 Kod üreticileri 15

23 ©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 23Slide 23 Nesne puanları l Nesne puanları işlev puanlar ölçümüne alternatiftir l Nesne puanları nesne sınıfları ile aynı değildir l Programdaki nesne puanları sayısı aşağıdaki etkenlerle belirlenir: Farklı ekranların (formların) sayısı; basit ekranlar 1 nesne puanı, orta karmaşıklı ekran 2 puan, çok karmaşık ekran 3puan Sistemin ürettiği raporlar sayısı; basit raporlar 2, orta karmaşıklı 5, üretimi çok karmaşık raporlar 8 puan Geliştirilen 3GL modülleri sayısı; her modül 10 puan

24 ©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 23Slide 24 Nesne puanları ve işlev puanlar l İşlevsel puanlara nazaran nesne puanlarını belirlemek daha kolaydır l Onlar geliştirme sürecinin erken aşamalarında tahmin edile bilir. Bu aşamada sistemdeki kod satırları sayısını tahmin etmek oldukça zordur

25 ©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 23Slide 25 Farklı seviyeli dillerde sistem geliştirme süreci Verimlilik=boyut/çaba; Dikkat edin: verimlilik için zaman birimi ay, çaba için hafta kullanılmıştır

26 ©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 23Slide 26 l Program seviyesi aşağı oldukça programcının verimliliği yükseliyor?! Aynı işlevsellik aşağı seviyede, yukarı seviye dilleri ile oranda daha çok kod çalıştırılmasını gerektiriyor l Programda gereksiz şeyler ne kadar çok ise programcının verimliliği bir o kadar yüksektir?! Verimliliğin kod satırlarına dayalı olması; gereksiz kodlar yazmakla programı şişiren programcıyı daha kısa program yazmağa çalışan programcıdan üstün buluyor Verimliliğin karşılaştırılması

27 ©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 23Slide 27 l Gerçek zaman sistemleri, 40-160 KS/kişi-ay l Sistem programları, 150-400 KS/kişi-ay l Ticari uygulamalar, 200-800 KS/kişi-ay l Nesne puanları üzere verimlilik destek araçlarına ve geliştiricinin yeteneğine bağlı olarak 4-50 nesne noktası/ay olarak değişir Verimliliğin tahmini

28 ©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 23Slide 28 Verimliliği etkileyen etkenler l Uygulama alanında deneyim- uygulama alanında deneyimli olmak yazılım geliştirmede çok mühimdir. l Süreç etkeni- çözümleme ve tasarım teknikleri,diller l Problem etkenleri- sorunun karmaşıklığı,tasarım sınırlamaları l Ürün etkenleri- başarım ve güvenilirlik l Projenin boyutu- proje büyük oldukça proje grubu üyeleri arasındaki iletişime daha çok ihtiyaç duyuluyor. Doğrudan geliştirmeye ayrılan zaman azalıyor ve böylelikle, bireysel verimlilik düşmüş oluyor l Teknoloji destek,kaynak etkeni- geliştirme araçları, donanım,yazılım kaynakları; iyi teknoloji destek (örn.,CASE araçlarının kullanımı) verimliliği yükseltir l Çalışma ortamı- her birey için ayrıca sakin çalışma ortamının oluşturulması verimliliği yükseltir

29 ©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 23Slide 29 l ‘Boyut/zaman birimi’ne dayalı tüm ölçümler, kaliteyi hesaba katmadıkları için kusurludur l Kalite ve verimlilik ölçümleri arasındaki bağlantı belirgin değil l Eğer programda değişmeler her zaman olacaksa satırlar sayısı ile ölçüm yapmak anlamsızdır Kalite ve verimlilik

30 ©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 23Slide 30 Tahmini değerlendirme yöntemleri l Yazılım sistemini geliştirmek için gereken çabayı kesin değerlendirmek için basit bir yol yoktur Başlangıç değerlendirmeler kullanıcı gereksinimlerinin tanımlamalarından alınan kesin olmayan bilgilere dayanıyor Yazılım yeni bir bilgisayarda veya yeni teknoloji kullanmakla çalıştırıla bilir Projeye katılan kişiler belli değil l Projenin maliyet değerlendirmesi bütçeyi belirler ve ürün bütçeye uygun olarak geliştirilir

31 ©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 23Slide 31 Tahmini değerlendirme yöntemleri l Algoritmik maliyet modeli l Uzman değerlendirmeleri l Benzerlik değerlendirmesi l Parkinson Kuralı l Kazanca yönelik fiyatbiçme-Pricing to win

32 ©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 23Slide 32 Algoritmik maliyet modelleme l istatiksel maliyet verilerine dayalı formal yaklaşım; genellikle yazılımın boyutunu kullanıyor

33 ©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 23Slide 33 Uzman görüşleri l Yazılım geliştirme ve uygulama alanlarından birer veya birkaç uzman yazılımın maliyetini değerlendirmek için deneyimlerini kullanıyorlar. Razılaşma sağlanana dek bu süreç devam ediyor l Artı yönleri: Nispeten düşük maliyetli değerlendirme yöntemi. Uzmanların benzer sistemlerde deneyimleri varsa kesinliği yüksektir l Eksi yönleri: Yöntem, uzman olmayanlar tarafından gerçekleşirse kesinliği çok düşüktür

34 ©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 23Slide 34 Benzerliğe göre değerlendirme l Projenin maliyeti, projenin aynı uygulama alanındaki benzer projelerle karşılaştırılması yolu ile hesaplanıyor l Artı yönleri: Eğer proje verileri mevcutsa kesinliği yüksektir l Eksi yönleri: Karşılaştırma için proje yok ise gerçekleştirilemez. Maliyet veri tabanının sürekli güncellenmesi gerekiyor.

35 ©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 23Slide 35 Parkinson Kuralı l Projenin maliyeti elde olan kaynaklara bağlıdır l Artı yönü: yüksek maliyetli değil l Eksi yönleri: Çoğu zaman sistem tamamlanmamış oluyor Proje 12 aya teslim edilmeli ise ve “el altında” 5 geliştirici var ise çaba 12*5 kişi-ay olarak hesaplanacak

36 ©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 23Slide 36 Kazanmak için fiyatbiçme-Pricing to win l Projenin maliyeti, müşterinin harcayacağı paraya bağlıdır l Müşterinin istediği sistemi elde etmesi ihtimali küçüktür. Maliyet, gereken işleri kesin yansıtmaz l Bu yöntem ahlaki görünmeye bilir l Ama, gereken bilgi yok derecesinde ise bu en uygun yaklaşım ola bilir l Projenin maliyeti öneri temelleri üzerinde razılaştırılır ve geliştirme bu maliyetle sınırlanır l Ayrıntılı belirteç görüşüle bilir veya sistem geliştirmede evrimsel yaklaşım kullanıla bilir

37 ©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 23Slide 37 Yukarıdan aşağıya ve aşağıdan yukarıya değerlendirme l Her bir yöntemde yukarıdan aşağıya ve yukarıdan aşağıya yaklaşımları kullanıla bilir l Yukarıdan aşağıya Sitem seviyesinden başlamalı; tüm sistem işlevlerine erişim; bunlar alt sistemlerden nasıl alınıyor l Aşağıdan yukarıya Bileşen seviyesinden başlamalı; her bir bileşen için gereken çabayı değerlendirmeli; Nihai değerlendirmeği bulmak için bu çabaları toplamalı

38 ©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 23Slide 38 Yukarıdan aşağıya değerlendirme l Bu değerlendirme sistemin mimarisi ve bu sistemin parçası ola bilecek bileşenler hakkında bilgi olmadan da yapıla bilir l Bütünleşme, yapı yöneticiliği ve belgelendirme maliyeti dikkate alınmakla hesaplanıyor l Aşağı seviyede teknik sorunların çözümü ile bağlı maliyetlerin yeterince değerlendirilmemesi sorun oluştura bilir

39 ©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 23Slide 39 Aşağıdan yukarıya değerlendirme l Sistemin mimarisi belli ise ve bileşenler tanımlanmış ise kullanıla bilir l Eğer sistem ayrıntılı tasarlanmışsa kesin sonuçlar veren yaklaşımdır l Bütünleşme ve belgelendirme gibi yüksek seviye girişimleri maliyetlerinin yeterince dikkate alınmaması sorun oluştura bilir

40 ©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 23Slide 40 Değerlendirme yöntemlerinin karşılaştırılması l Her yöntemin güçlü ve zayıf yönleri bulunmaktadır l Değerlendirme birkaç yöntemle yapılsa daha kesin sonuç vere bilir l Eğer farklı yöntemlerle alınmış sonuçlar biri birinden çok uzak ise bu giriş bilgilerinin yeterli olmadığını gösteriyor l Bazı hallarda kazanma için fiyatbiçme tek uygulanabilir yöntemdir

41 ©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 23Slide 41 Değerlendirmenin kesinliği l Yazılım sisteminin boyutu,yalnız yazılım tamamlandıktan sonra kesin belli olur l Yazılımın nihai boyutunu etkileyen etkenler: Yazılım araçlarının kullanımı Programlama dili Sistemin dağınıklığı l Geliştirme sürecinin devam ettiği süreçte değerlendirme gittikçe kesinleşir

42 ©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 23Slide 42 Değerlendirmenin belirsizliği Yapılabilirlik gereksinimler tasarım kodlama teslim

43 ©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 23Slide 43 Deneyime dayalı değerlendirmeler l Değerlendirmeler başlıca olarak deneğime dayalıdır. l Ama, yeni yöntem ve teknolojiler bu tür değerlendirmelerin kesinliğini azaltıyor. İşleve yönelik geliştirme yerine nesneye yönelik Büyük bilgisayar sistemleri yerine istemci-sunucu sistemleri Standart (satılan) bileşenler Bileşen tabanlı yazılım mühendisliği Yazılım Geliştirme araçları ve program üreticileri

44 ©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 23Slide 44 Algoritmik maliyet değerlendirme l Maliyet ürünün, projenin ve sürecin özelliklerinin matematik fonksiyonu gibi hesaplanır. Özelliklerin değerleri proje yöneticileri tarafından belirlenir: Çaba = A  Boyut B  M A kuruluma ve geliştirilen yazılımın türüne bağlı sabittir. B – projenin boyutuna bağlı etkendir (1-1,5 arasında değişiyor). M- ürün, süreç ve kişi özelliklerini dikkate alan katsayısıdır l Ürün özellikleri içinde en yaygın kullanılanı kodun boyutudur l Modellerin pek çoğu benzerdir, yalnız A, B ve M değerleri farklıdırlar

45 ©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 23Slide 45 COCOMO modeli l Proje deneyimlerine dayalı deneysel (empirical) model l İyi belgelendirilmiş, “bağımsız” model-her hangi yazılım satıcısına bağlı değil l 1981’de geliştirilmiş COCOMO-81 modelinden COCOMO 2’ye dek pek çok sürümleri mevcuttur l COCOMO 2 yazılım geliştirmede çeşitli yaklaşımları ( o sıradan yeniden kullanmayı) dikkate alıyor

46 ©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 23Slide 46 COCOMO 81

47 ©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 23Slide 47 COCOMO 2 seviyeleri l COCOMO 2 üçseviyeli modeli yazılımı artan ayrıntılarla değerlendirme imkanı veriyor Erken prototip modeli »Değerlendirmeler nesne puanlarına göre hesaplanıyor ve çabayı değerlendirmek için basit formüle kullanılıyor Erken tasarım seviyesi »İşlev puanları üzere değerlendirme yapılıyor; bu sonra LOC’a dönüştürülüyor Mimariden sonraki seviye-Post-architecture level »Değerlendirmeler kaynak kod satırları üzerinde yapılıyor

48 ©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 23Slide 48 Erken prototip seviyesi l Prototip projelerini ve yeniden kullanımı çok sık olan projeleri destekler l Geliştiricinin verimliliğinin nesne puanları/ay ölçümünün standart değerlendirilmesine dayanmaktadır l CASE araçlarının kullanımını dikkate alıyor PM = ( NOP  (1 - %reuse/100 ) ) / PROD PM - kişi-ayla çaba, NOP nesne noktaları sayısı, PROD – verimliliktir, %reuse -yeniden kullanılabilrilik oranı

49 ©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 23Slide 49 Nesne puanı verimliliği

50 ©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 23Slide 50 Erken tasarım seviyesi l Değerlendirmeler gereksinimler belirlendikten (kesinleştikten) sonra da yapıla bilir l Algoritmik modeller için standart formül kullanılıyor: PM = A  Size B  M + PM m nerede ki, M = PERS  RCPX  RUSE  PDIF  PREX  FCIL  SCED PM m = (ASLOC  (AT/100)) / ATPROD l A = 2.5 başlangıç sabit, Size bin kod satırları sayısı, B 1.1 -1.24 arasında değişir ve projenin yeniliğine, geliştirme esnekliğine, risk yönetimine, süreç olgunluğuna bağlıdır l M-katsayılarıdır

51 ©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 23Slide 51 Katsayıları- Multipliers l Katsayıları geliştiricilerin yeteneğini, işlevsel olmayan gereksinimleri, geliştirme ortamının benzerliğini ve s. İfade ediyor. RCPX –proje güvenilirliği ve karmaşıklığı ( product reliability and complexity) RUSE – yeniden kullanılabilirlik (the reuse required) PDIF –platform zorluğu ( platform difficulty) PREX – personel deneğimi (personnel experience) PERS – personel yeteneği (personnel capability) SCED – istenen iş-zaman planı (required schedule) FCIL – destek araçları (the team support facilities) l PM –otomatik üretilen kod sayısı ile belirlenir

52 ©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 23Slide 52 l Ürün özellikleri Geliştirilecek yazılım ürününün istenen nitelikleri l Bilgisayar özellikleri Donanım platformunun yazılıma koyduğu sınırlamalar l Personel özellikleri Proje üzerinde çalışan personelin deneyimin ve yeteneğini dikkate alar l Proje özellikleri Yazılım projesine özgü nitelikleri dikkate alar Katsayıları (devamı)

53 ©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 23Slide 53 Mimariden sonraki seviye- Post- architecture level l Erken tasarımdaki ile aynı formüle kullanılıyor l Boyutun değerlendirilmesi ayarlana biliyor Gereksinimlerin esnekliği. Değişmeleri desteklemek için ilave çalışmalar Mümkün tekrar kullanılırlığın boyutu. Tekrar kullanım yalnızca kod satırları sayısının azaltılması değildir. Diğer maliyet etlileri de vardır ESLOC = ASLOC  (AA + SU +0.4DM + 0.3CM +0.3IM)/100 ESLOC yeni kod satırları sayısıdır; ASLOC yeniden kullanılabilir satırlar sayısı; DM –değiştirilen tasarım yüzdesi; CM –değiştirilen kod yüzdesi; IM tekrar kullanılan yazılımı bütünleştirmek için gereken başlangıç bütünleşme çabası yüzdesi; SU- yazılımı anlama maliyetini yansıtan etken; AA – yazılımın tekrar kullanılacağını dikkate almakla maliyetin başlangıç tahminin yansıtan etkendir

54 ©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 23Slide 54 PM = A  Size B  M + PM m l 6 ölçek etkenine (0-5 arasında) bağlıdır. Onların toplamı/100,1.01 sayısına ilave edilir l Örnek yeni proje - 4 Geliştirme esnekliği – müşteri katılmadan – Çok yüksek - 1 Mimari/risk çözümü – Risk çözümlenmesi yoktur – Çok düşük - 5 Grup bağlılığı – yeni grup - nominal - 3 Olgunluk süreci – bazı denetimler - nominal - 3 l Ölçek etkeni- 1.17 Üst ifadesi (The exponent term)

55 ©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 23Slide 55 Üst ölçek etkeni

56 ©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 23Slide 56 Projenin maliyet belirleyicileri mimari sonrası değerlendirmede maliyet tahminini ayarlamak için kullanılır

57 ©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 23Slide 57 Maliyet belirleyicilerinin etkileri- Effects of cost drivers

58 ©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 23Slide 58 l Algoritmik maliyet modeli proje planlamasında temeldir, böyle ki, karşılaştırma için farklı stratejilere izin veriyor Örnek. uçak sistemi Güvenilir olmalı Ağırlığı en az olmalı (parça sayısı) Güvenilirlik ve ve bilgisayar sınırlamaları katsayısı > 1 l Maliyet bileşenleri Hedef donanım Geliştirme platformu Gereken çaba Proje planlama

59 ©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 23Slide 59 Yönetici tercihleri

60 ©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 23Slide 60 Yönetici tercihlerinin maliyeti

61 ©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 23Slide 61 Tercihlerin değerlendirilmesi (örnek üzerinde) l D tercihi (daha deneyimli personel kullanımı) en iyi alternatiftir Ama bu tercih, deneyimli personel bulunması zorluğu ile bağlı yüksek risk taşımaktadır l C tercihinde (belleğin yükseltilmesi) tasarruf azdır, risk düşüktür l Bütünlükle, model yazılım geliştirmede personel deneyiminin önemli olduğunu ortaya koyuyor

62 ©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 23Slide 62 Proje süreci ve personel l Yönetici projenin tamamlanması için gereken zamanı ve gereken personeli tahmin etmelidir l Proje takvim zamanı COCOMO 2 kullanmakla tahmin edile biler: TDEV = 3  (PM) (0.33+0.2*(B-1.01)) PM hesaplama çabasıdır; B katsayısıdır; erken prototip modeli için B=1; l Bu süre projede çalışan kişiler sayısına bağımlı değil

63 ©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 23Slide 63 Personel gereksinimleri l Gereken personel iş-zaman çizelgelemesine ve geliştirme zamanına uygun olarak hesaplana bilmez l Projede çalışanların sayısı projenin geliştirilme safhalarında farklı ola bilir l Projede ne kadar çok personel çalışıyorsa genelde toplam çaba da bir o kadar çok oluyor

64 ©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 23Slide 64 Sonuç l Verimliliği, bireysel özellikler, alan deneğimi, geliştirilen projenin özellikleri, boyutu, araç desteği ve çalışma ortamı gibi etkenler etkiler l Maliyet değerlendirmesi için çeşitli değerlendirme yöntemlerinin kullanılması tavsiye olunuyor l Yazılım, sözleşmeyi kazanmak için uygun fiyatla sunulmalı ve işlevselliği fiyata uyarlanmalıdır

65 ©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 23Slide 65 Sonuç l Algoritmik maliyet değerlendirmesi nihai ürünün özelliklerinin değerlendirilmesine gerek duyduğu için zordur l COCOMO, gereken çabayı tahmin etmek için proje, ürün,personel ve donanım özelliklerini dikkate alıyor l Algoritmik maliyet modeli niceleyici çözümlemeyi destekler l Projenin tamamlanması için gereken zaman projede çalışanların sayısı ile doğru orantılı değil