Yazılımın Maliyetinin değerlendirilmesi Software Cost Estimation

1. Yazılımın Maliyetinin değerlendirilmesi Software Cost Estimation Arka planı sarı renkli sayfalar ilave bilgi amaçlıdır-sınavda sorulmayacak

2. Ne öğrenilecek • Yazılım maliyetinin ve fiyatının belirlenmesinin temelleri • Yazılımın verimliliğinin ölçülmesi • Yazılımın değerlendirilmesinde farklı yöntemlerin kullanılması • Algoritmik maliyet değerlendirme modeli

3. Temel değerlendirme soruları • İşlemleri tamamlamak için ne kadar emek gerekmektedir? • İşlemleri tamamlamak için ne kadar zaman gerekmektedir? • İşlemlerin toplam maliyeti ne kadardır?

4. Yazılım maliyeti bileşenleri • Yazılımın maliyeti -yazılım geliştirme süreci için gereken kaynakların değeri • Donanım ve yazılım maliyeti • Seyahat ve eğitim maliyeti • Emek maliyeti (ekser projelerde temel etken) • Projeye katılmış mühendislerin maaşları • Sosyal ve sigorta maliyetleri • Emeğin maliyetini etkileyen diğer etkenler: • Bina, ısınma, aydınlatma maliyeti • Ağ ve telekomünikasyon maliyeti • Ortak kullanım maliyetleri (kütüphane, kantin ve s.)

5. Maliyet ve fiyatlandırma • Matematiksel olarak Yazılımın fiyatı=maliyet + kar • Ama gerçek uygulamalarda yazılımın geliştirilme maliyeti ile müşteriye bildirilen fiyatı arasında ilişki bu kadar basit değildir • Kurumsal, iktisadi, siyasi ve ticari etkenler fiyatlandırmayı etkiler

6. Yazılımın fiyatını etkileyen etkenler • 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 olabilir. Kazanılmış deneğimler yeni ürünler geliştirmek için temeldir • 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 • 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. Yazılımın fiyatını etkileyen etkenler (devamı) • 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 • 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. Programcının verimliliği • Zaman birimi içinde üretilmiş yararlı işlevsellik • Yazılım geliştirme sürecine katılmış mühendisin işini değerlendirme ölçümü • Kaliteye yönelik değildir

9. Verimliliğin ölçülmesi • Boyuta yönelik ölçümler - Bu ölçümler kaynak kodundan alınan kod satırları sayısı, nesne kodları ola bilir • İş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

10. Yazılımın Verimliğinin ve Kalitesinin ölçülmesi Yazılım Ölçümleri • Boyuta Yönelik Ölçümler • İşleve Yönelik Ölçümler Yazılım Kalitesi için Ölçümler • Kaliteyi Etkileyen Etkenler • Kalite ölçümleri • Farklı Ölçme Yaklaşımlarının Karşılaştırılması • Yazılım Mühendisliği süreci dahilinde ölçümlerin bütünleştirilmesi

11. Yazılım ölçümleri Teknik Ölçümler Kalite Ölçümleri Verimlilik Ölçümleri Boyuta Yönelik ölçümler İşleve Yönelik Yöntemler

12. Boyuta Yönelik Ölçümler • Yazılımın ve onun geliştirilme sürecinin doğrudan ölçülmesi KLOC- kilo lines of code- bin kod satırı sayısı

13. Boyuta yönelik ölçümler-Kod satırları sayısı • 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? • Bu ölçmede sistemin boyutu ile belgelerin boyutu arasında doğrusal ilişki olduğu düşünülüyor

14. Yazılımı Ölçme Kıstasları - Boyuta yönelik ölçümler • Verimlilik = KS/kişi-ay • Kalite = hatalar/KS • Değer = $/KS • Belgeleme = belge sayfaları sayısı/KS (KS-kod satırları sayısı)

15. İşleve yönelik ölçümler-İşlev puan • İşlev puan ölçümü, 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 • Kullanılan algoritmalar • Bu özelliklerin her birisine ağırlık değerleri veriliyor • Ayarlanmamış İşlev puan, tüm özellikler üzere her bir özellik sayısının, bu özellik için belirlenmiş ağırlık değerine çarpılması ile alınmış sayıların toplamıdır

16. İşleve yönelik ölçümler-İşlev puanların hesaplanması

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

18. İşlevsel niteliklerin değerlendirilmesi • İş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

19. Yazılımı Değerlendirme Kıstasları İşlev puanların hesaplanması • İP=AİP x [0.65+0.01x (Fi)] • (AİP-ayarlanmamış işlev puan) • Verimlilik =İP/kişi-ay • Kalite =hatalar/İP • Değer=$/İP • Belgeleme = belge sayfaları sayısı/İP

20. İşlev puan ve kod satırları sayısı • Projenin karmaşıklığı işlev puanlar sayısını etkiler • İşlev puanlar, programlama dilinde bir işlev puana denk gelen 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 • İP’ler çok özneldir. Değerleri değerlendiriciye bağlıdır. • İşlev puanların otomatik hesaplanması mümkün değildir

21. Kod satırlar sayısı ve işlev noktalar sayısı arasındaki ilişki (AVC-etkeni) • 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

22. Farklı dillerde program kod sayılarının karşılaştırılması Tablonun açıklaması: bir mantıksal işlemin Assembly ve Fortranda 1 fiziki kod satırı (KSS-kod satırları sayısı) ile ifade edildiğini varsayarsak, 4.nesil dillerde örn., 100 mantıksal işlem, 60 kod satırı ile gerçekleştiriliebilir (%40 daha az).

23. Nesne puanları • Nesne puanları işlev puanlar ölçümüne alternatiftir • Nesne puanları nesne sınıfları ile aynı değildir • 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. Nesne puanları ve işlev puanlar • İşlevsel puanlara nazaran nesne puanlarını belirlemek daha kolaydır • 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. Farklı seviyeli dillerde sistem geliştirme süreci-örnek Verimlilik=boyut/çaba; Dikkat edin: verimlilik için zaman birimi ay, çaba için hafta kullanılmıştır

26. Verimliliğin karşılaştırılması • Programlama dili seviyesi aşağı oldukça programcının verimliliği yükseliyor mu?! • Aynı işlevsellik aşağı seviyede , yukarı seviye dilleri ile oranda daha çok kod çalıştırılmasını gerektiriyor • Programda gereksiz şeyler ne kadar çok ise programcının verimliliği bir o kadar yüksektir mi?! • 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

27. Verimliliğin tahmini • Gerçek zaman sistemleri, 40-160 KS/kişi-ay • Sistem programları , 150-400 KS/kişi-ay • Ticari uygulamalar, 200-800 KS/kişi-ay • 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

28. Verimliliği etkileyen etkenler • Uygulama alanında deneyim- uygulama alanında deneyimli olmak yazılım geliştirmede çok mühimdir. • Süreç etkeni- çözümleme ve tasarım teknikleri,diller • Problem etkenleri-sorunun karmaşıklığı,tasarım sınırlamaları • Ürün etkenleri-başarım ve güvenilirlik • 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 • 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 • Çalışma ortamı- her birey için ayrıca sakin çalışma ortamının oluşturulması verimliliği yükseltir

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

30. Tahmini maliyet -değerlendirme yöntemleri • 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 • Projenin maliyet değerlendirmesi bütçeyi belirler ve ürün bütçeye uygun olarak geliştirilir

31. Tahmini değerlendirme yöntemleri • Algoritmik maliyet modeli • Uzman değerlendirmeleri • Benzerlik değerlendirmesi • Parkinson Kuralı • Kazanca yönelik fiyatbiçme-Pricing to win

32. Tahmini değerlendirme yöntemleri- Algoritmik maliyet modeli • Algoritmik maliyet modeli istatiksel maliyet verilerine dayalı formal yaklaşım; genellikle yazılımın boyutunu kullanıyor

33. Algoritmik maliyet modeli-devamı • 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 ´BoyutB´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 • Ürün özellikleri içinde en yaygın kullanılanı kodun boyutudur • Modellerin pek çoğu benzerdir, yalnız A, B ve M değerleri farklıdırlar

34. Tahmini değerlendirme yöntemleri-Uzman görüşleri • 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 • Artı yönleri:Nispeten düşük maliyetli değerlendirme yöntemi. Uzmanların benzer sistemlerde deneyimleri varsa kesinliği yüksektir • Eksi yönleri:Yöntem, uzman olmayanlar tarafından gerçekleşirse kesinliği çok düşüktür

35. Tahmini değerlendirme yöntemleri-Benzerliğe göre değerlendirme • Projenin maliyeti, projenin aynı uygulama alanındaki benzer projelerle karşılaştırılması yolu ile hesaplanıyor • Artı yönleri:Eğer proje verileri mevcutsa kesinliği yüksektir • 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.

36. Tahmini değerlendirme yöntemleri-Parkinson Kuralı • Projenin maliyeti elde olan kaynaklara bağlıdır • Artı yönü:yüksek maliyetli değil • 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

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

38. Yukarıdan aşağıya ve aşağıdan yukarıya değerlendirme • Her bir yöntemde yukarıdan aşağıya ve yukarıdan aşağıya yaklaşımları kullanıla bilir • Yukarıdan aşağıya • Sistem seviyesinden başlamalı; tüm sistem işlevlerine erişim; bunlar alt sistemlerden nasıl alınıyor • 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ı

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

40. Aşağıdan yukarıya değerlendirme • Sistemin mimarisi belli ise ve bileşenler tanımlanmış ise kullanıla bilir • Eğer sistem ayrıntılı tasarlanmışsa kesin sonuçlar veren yaklaşımdır • Bütünleşme ve belgelendirme gibi yüksek seviye girişimleri maliyetlerinin yeterince dikkate alınmaması sorun oluştura bilir

41. Değerlendirme yöntemlerinin karşılaştırılması • Her yöntemin güçlü ve zayıf yönleri bulunmaktadır • Değerlendirme birkaç yöntemle yapılsa daha kesin sonuç vere bilir • Eğer farklı yöntemlerle alınmış sonuçlar biri birinden çok uzak ise bu giriş bilgilerinin yeterli olmadığını gösteriyor • Bazı hallarda kazanma için fiyatbiçme tek uygulanabilir yöntemdir

42. Değerlendirmenin kesinliği • Yazılım sisteminin boyutu ,yalnız yazılım tamamlandıktan sonra kesin belli olur • Yazılımın nihai boyutunu etkileyen etkenler: • Yazılım araçlarının kullanımı • Programlama dili • Sistemin dağınıklığı • Geliştirme sürecinin devam ettiği süreçte değerlendirme gittikçe kesinleşir

43. Değerlendirmenin belirsizliği Yapılabilirlik gereksinimler tasarım kodlama teslim

44. Deneyime dayalı değerlendirmeler • Değerlendirmeler başlıca olarak deneğime dayalıdır. • 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

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

46. COCOMO 81

47. COCOMO 2 seviyeleri • 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. Erken prototip seviyesi • Prototip projelerini ve yeniden kullanımı çok sık olan projeleri destekler • Geliştiricinin verimliliğinin nesne puanları/ay ölçümünün standart değerlendirilmesine dayanmaktadır • CASE araçlarının kullanımını dikkate alıyor • PM = ( NOP´(1 - %reuse/100 ) ) / PROD • PM- kişi-ayla çaba, NOPnesne noktaları sayısı, PROD–verimliliktir, %reuse -yeniden kullanılabilrilik oranı

49. Nesne puanı verimliliği

50. Erken tasarım seviyesi • Değerlendirmeler gereksinimler belirlendikten (kesinleştikten) sonra da yapıla bilir • Algoritmik modeller için standart formül kullanılıyor: • PM = A´SizeB´M + PMm nerede ki, • M = PERS ´ RCPX ´ RUSE ´ PDIF ´ PREX ´ FCIL ´ SCED • PMm = (ASLOC´(AT/100)) / ATPROD • A = 2.5 başlangıç sabit,Sizebin 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 • M-katsayılarıdır