Maltepe Üniversitesi Mühendislik Fakültesi YAZILIM PROJE YÖNETİMİ Öğr. Gör. Dr. Emin BORANDAĞ eminb@maltepe.edu.tr YZM 403 Maltepe Üniversitesi Mühendislik Fakültesi

YAZILIM BÜYÜKLÜK ve EMEK KESTİRİMİ 4. BÖLÜM YAZILIM BÜYÜKLÜK ve EMEK KESTİRİMİ YZM 403 - Yazılım Proje Yönetimi

Genel Bakış… Yazılım büyüklük ve emek kestirimine giriş Yazılımda ölçme Yazılım kestirimi için temeller Yazılım büyüklük kestirim teknikleri Teknik büyüklük kestirim yöntemleri İşlevsel büyüklük kestirim yöntemleri Yazılım emek kestirim teknikleri Algoritmik Olmayan Emek Kestirim Yöntemleri Algoritmik Emek Kestirim Yöntemleri Bu bölüm kapsamında, Yazılım Büyüklük ve Emek Kestirimi ile ilgili temel kavramları inceleyeceğiz. Bu bağlamda, önce yazılımda ölçme kavramından bahsedip, yazılım büyüklük ve emek kestirimine giriş yapacağız. YZM 403 - Yazılım Proje Yönetimi

Giriş Yazılım geliştirme sürecinin başında, büyüklük, emek ve maliyet kestirimleri geliştiricilerin ve yöneticilerin karşılaştığı en önemli problemlerdir. Yazılım proje yönetiminde çok önemli olan ölçme ve bu kavram çerçevesinde yapılanan kestirim yöntemleri aracılığı ile zaman ve işgücü gibi planlamaların yapılabilme gereği açıktır. YZM 403 - Yazılım Proje Yönetimi

Yazılımda Ölçme Her yazılım projesinin temel hedefi, müşterinin ihtiyaçlarını karşılayan, öngörülmüş bütçe ile zamanında teslim edilen hatasız bir yazılım geliştirmektir. Yazılımda ölçüm yöntemlerinin kullanılması, yazılım sektöründe gittikçe önem kazanır olmuştur. Kurumlar üç ana amaçla yazılımda ölçümü gündemlerine almaktadırlar: Yazılım projesini anlamak ve modellemek, Yazılım projelerinin yönetilmesine yol göstermek, Yazılım süreç geliştirme ve iyileştirme çalışmalarını yön vermek, GİRİŞ: Yazılım ölçümünü (software metrics) bir yazılımın yada yazılım projesinin ölçebildiğimiz herhangi bir özelliği olarak tanımlayabiliriz. ÜÇÜNCÜ MADDE: Ne yazık ki yazılım projelerinde bu üç koşulun bir arada sağlanması genelde mümkün olmamaktadır. YZM 403 - Yazılım Proje Yönetimi

Yazılımda Ölçme (devam…) Yazılımın ölçülebilmesi, harcanılan zaman, emek, proje büyüklüğü ve kalite gibi faktörlerin belirlenmesine olanak sağlamaktadır. Organizasyonlar, bu verilere dayanarak ileride alacakları projeler için kestirim yapabilme imkânı bulabileceklerdir. Yazılım projelerinde kaliteyi arttırmak, her şeyden önce doğru ölçme yöntemlerine bağlıdır. Birden fazla kestirim yöntemi kullanılmalıdır. Örnek olarak, ele alınan projedeki personel gereksiniminin tam olarak belirlenebilmesi için ürün büyüklüğü bilgisi gereklidir. YZM 403 - Yazılım Proje Yönetimi

Beş Temel Yazılım Ölçütü Büyüklük (Size), Emek (Effort), Maliyet (Cost), Zaman (Duration), Kalite (Quality). Büyüklük; kodun satır sayısı. Emek; proje kapsamında ayda kaç kişi çalışacak. Maliyet; projenin ne kadara mal olacağı. Zaman; proje kaç ayda tamamlanacak. Kalite; projenin kalitesi tespit edilen hata sayısından ölçülebilir. YZM 403 - Yazılım Proje Yönetimi

Yazılım Büyüklük Kestirim Yöntemleri Yazılım büyüklük kestiriminde kullanılan yöntemler; teknik büyüklük kestirim yöntemleri, işlevsel büyüklük kestirim yöntemleri olarak sınıflandırılmıştır. YZM 403 - Yazılım Proje Yönetimi

Teknik Büyüklük Kestirim Yöntemleri Satır Sayısı (Lines of Code - LOC): Uygulamanın büyüklüğünü anlamak için bilgisayar programlarındaki kodların satırlarını sayma en geleneksel ve en yaygın şekilde kullanılan yazılım ölçümüdür. Satır Sayısı, kod içerisindeki satır sayısını temsil eder. Kod satır sayısı kestiriminde, proje tahmin edilen alt birimlerine ayrıştırılır. Her bir alt birim için satır sayıları önerilir. Bu kestirimler yapılırken de en küçük, en olası ve en büyük ihtimaller belirlenip, bunlarla bir ortalama işlemi yapılır. Satır sayısı kestirimi: (k+4o+b)/6 şeklinde hesaplanabilir. BİRİNCİ MADDEDEN SONRA: Kolaylığı ve doğrudan ölçülebilirliği açısından en fazla kullanılan yazılım ölçme yöntemi, satır sayısıdır. Bir programın büyüklüğü denince ilk akla gelen kaç satırlık kaynak kodu ile üretildiğidir. EN SON SÖYLE: Bir birim için tahmin edilecek en küçük satır sayısına k, en olası satır sayısı tahminine o ve en büyük tahmin değerine de b denecek olursa, o birim için: satır sayısı kestirimi (k+4o+b)/6 şeklinde hesaplanabilir. YZM 403 - Yazılım Proje Yönetimi

Teknik Büyüklük Kestirim Yöntemleri (devam…) Satır Sayısı (Lines of Code - LOC) Tabi ki 1000 LOC değeri olan bir Java programı, 100 LOC değerine sahip bir Java programından 10 kat daha büyüktür. Fakat bu sayının içinde yorum satırları var mı? Yorum satırlarını dahil etmeli miyiz? (Yorum Satırının Avantajı) Deneyim ile kod oluşturumu (Aynı özellik farklı kod sayısı) Programlaa dili farkı Assembler <> Visual Basic Değişkenlerin tanımlanması  LOC olarak sayılmalı mıdır? İKİNCİ MADDEDEN SONRA: Yorum satırları kodun bize ne yaptığını anlatması açısından önemlidir. Bu aynı zamanda koddaki hataların ayıklanması açısından işleri daha da kolaylaştırır ve diğer insanların programdaki kod parçalarının ne yaptığına dair bir fikir edinmelerini sağlar. Tüm bunlara ek olarak, deneyimli programcılar, işe yeni başlayan programcılara göre daha az kod yazmaya eğilimlidirler. Deneyimli bir programcı, işe yeni başlayan bir programcının yazdığı kod ile aynı işlevi gören, daha az sayıda satırdan oluşan ve daha etkili bir kod yazabilir. Aynısı farklı programlama dilleri için de söylenebilir. Assembler’de program yazmak, benzer programı Visual Basic’de yazmaktan daha fazla sayıda satırdan oluşan kod yazmayı gerektirir. LOC bir verimlilik ölçümü olarak kullanılırsa, biri LOC saymanın programcının etkisiz, gereksiz fazladan kod yazmaya özeneceğini iddia edebilir. Sonuç olarak, programı yazmak için gerekli olan kod satır sayısını kestirmektense, yazılmış bir programdaki kodun satırlarını saymak çok daha kolaydır. YZM 403 - Yazılım Proje Yönetimi

Teknik Büyüklük Kestirim Yöntemleri (devam…) Satır Sayısı (Lines of Code - LOC) İki başlıca LOC Kaynak Kod Satır Sayısı ölçüm çeşidi vardır. Bunlar; Fiziksel LOC Mantıksal LOC Örnek 1: for (i=0; i<100; ++i) printf ("hello"); /* How many lines of code is this? */ 1 Fiziksel Kod Satırı 2 Mantıksal Kod Satırı (for ve printf ifadesi) 1 Yorum Satırı YZM 403 - Yazılım Proje Yönetimi

Teknik Büyüklük Kestirim Yöntemleri (devam…) Satır Sayısı (Lines of Code - LOC) Örnek 2: Programcıya göre ve/veya kodlama standartlarına göre Örnek 1’deki kod aşağıdaki şekilde de yazılabilir. for (i=0; i<100; ++i) { printf("hello"); } /* Now how many lines of code is this? */ 4 Fiziksel Kod Satırı 2 Mantıksal Kod Satırı (for ve printf ifadesi) 1 Yorum Satırı YZM 403 - Yazılım Proje Yönetimi

İşlevsel Büyüklük Kestirim Yöntemleri İşlevsel Büyüklük Ölçümü (Functional Size Measurement - FSM), kullanıcıya teslim edilecek yazılımın işlevselliğini temel alır. FSM, işleve göre karmaşıklığın ve büyüklüğün belirlenmesi ile ölçülmektedir. Teknik Büyüklük Ölçütleri - geliştirici bakış açısından… İşlevsel Büyüklük Ölçütleri - kullanıcı bakış açısından… GİRİŞ: En fazla kullanılan diğer bir yazılım büyüklük ölçüm grubu, uzunluk niteliğinin aksine yazılımın işlevsellik niteliği ile ilgilidir. YZM 403 - Yazılım Proje Yönetimi

İşlevsel Büyüklük Kestirim Yöntemleri (devam…) İşlev Puanı (Function Points - FP), IFPUG İşlev Puanı Analizi (IFPUG Function Points Analysis – IFPUG FPA), Mark II İşlev Puanı (Mark II Function Points – MK II FP), Nesma İşlev Puanı (Nesma Function Points), Tam İşlev Puanı (Full Function Points – FFP), COSMIC Tam İşlev Puanı (COSMIC Full Function Points – COSMIC FFP), Nesne Puanı (Object Points), Nesne-Tabanlı İşlev Puanı (Object-Oriented Function Points – OO FP), Nesne-Tabanlı Yöntem İşlev Puanı (Object-Oriented Method Function Points – OOmFP), İlk olarak İşlev Puanı (Function Points) ve İşlev Puan Analizi (Function Points Analysis - FPA) 1979 yılında IBM’in satır sayısına alternatif olarak yazılım büyüklük ölçümü için Allan Albrecht tarafından ortaya çıkartılmıştır. 1983 de ise, Allan Albrecht ve John Gaffney tarafından Yönetim Bilgi Sistemlerinin büyüklüğünü ölçmek için FSM yöntemi geliştirilmiştir. Daha sonra farklı kitleler tarafından orijinal FPA yöntemi üzerinde yapılan oynamalarla, aralarında ölçüm yöntemi farklı birçok FSM yöntemi geliştirilmiştir. YZM 403 - Yazılım Proje Yönetimi

İşlev Puanı (Function Points) Bu yaklaşım, verimliliğin üretilen işlev puanına göre adam-ay olarak belirlenmesini öngörür. Eğer proje ile ilgili girdi çıktı gibi özellikler tahmin edilebiliyorsa, bunlar kullanılarak geliştirilecek sisteme ait bir İşlev Puanı (Function Points) hesabı yapılabilir ve sonuçlar Satır Sayısına (LOC) çevrilebilir. Bu satır sayısından maliyet, emek ve süre tahmini yapılabilir. İşlevsellik doğrudan ölçülemeyeceğine göre, bir yazılım projesinde işlevselliğe etkisi olan birçok etken bir arada incelenerek ürüne olan yansımaları ağırlıklandırılır. Sonuçta bir rakam ortaya çıkar ve bu rakam değişik projeleri göreceli olarak değerlendirmede yararlı olur. YZM 403 - Yazılım Proje Yönetimi

İşlev Puanı (Function Points) (devam…) FP SLOC SLOC’a dönüştürme İşlev Puanını, SLOC’a dönüştürmek için programlama diline göre saptanan faktörler kullanılır. Dış Girdilerin sayısı Dış Çıktıların sayısı Dış Sorguların sayısı İç Mantıksal dosyaların sayısı Dış Arayüz Dosyalarının sayısı Ağırlık Faktörleri ile ayarlanma Teknik Karmaşıklık Faktörleriyle ayarlama YZM 403 - Yazılım Proje Yönetimi

İşlev Puanı (Function Points) UFP = Dış Girdiler x W(1) + Dış Çıktılar x W(2) + Dış Sorgular x W(3) + İç Dosyalar x W(4) + Dış Arayüz Dosyaları x W(5) Bileşenler Basit Orta Karmaşık (1) Dış Girdiler 3 5 6 (2) Dış Çıktılar 4 7 (3) Dış Sorgular (4) İç Dosyalar 13 15 (5) Dış Arayüz Dosyaları 9 10 İşlev Puanında sistemin işlevselliği 5 ayrı bileşenle incelenmektedir. 1. Dış Girdiler: Veri giriş ekranları, mantıksal dâhili dosyalar. 2. Dış Çıktılar: Ekran çıktıları, raporlar. 3. Dış Sorgular: Kullanıcı isteği doğrultusunda alınan hızlı veri çıkışları. 4. İç Dosyaları: Dâhili kullanıcı verileri, saklanan veriler. 5. Dış Arayüz Dosyaları: Başka bir sistemle paylaşım. Her bir bileşenin zorluk derecesi basit, orta ve karmaşık gibi Tablo’da verilen rakamsal değerlere bağlı olarak ölçülebilmektedir. Bu ölçülen değerler toplanarak Düzeltilmemiş İşlev Puanı’nı (Unadjusted Function Points - UFPs) oluşturmaktadır. YZM 403 - Yazılım Proje Yönetimi

İşlev Puanı (Function Points) (devam…) 14 Genel Sistem Özelliğine göre sistemin beklenilen uygulama zorluğu için ilave bir teknik karmaşıklık faktörü hesaplanır. Genel Sistem Özellikleri Kısa Açıklama 1 Veri İletişimleri Sistemin uygulaması ile bilgi değişimi veya transferinde yardımcı olmak için kaç tane iletişim aracı vardır? 2 Dağıtılan Veri/İşleme Dağıtılan bilgi ve işleme fonksiyonları nasıl idare edilmektedir? 3 Performans Hedefler, yanıtlama zamanı ve iş çıkarma performansı önemli midir? 4 Çok Kullanılan Konfigürasyon Uygulamanın idare edileceği mevcut donanım platformu ne kadar yoğun kullanılmaktadır? 5 İşlem Oranı İşlem oranı yüksek midir? 6 Çevrimiçi Veri Girişi Hangi oranda bilgi çevrimiçi girilmektedir? 7 Son Kullanıcı Verimliliği Uygulama son kullanıcı verimliliği için mi tasarlanmıştır? 8 Çevrimiçi Güncelleme Kaç veri dosyası çevrimiçi güncellenmektedir? 9 Karmaşık İşlem Yapma Dâhili işlem yapma karmaşık mıdır? 10 Yeniden Kullanılabilirlik Uygulama yeniden kullanılabilir olması için mi tasarlanmıştır? 11 Dönüştürme/Kurulum Kolaylığı Sistemde otomatik dönüşüm ve kurulum da dâhil edilmiş midir? 12 İşlevsel Kolaylık Yedekleme, başlatma ve kurtarma gibi operasyonlar ne kadar otomatiktir? 13 Çoklu Saha Kullanımı Uygulama çoklu örgüte sahip çoklu sahalar için özellikle mi tasarlanmış, geliştirilmiş ve desteklenmiştir? 14 Değişimi Kolaylaştırma Uygulama kullanıcı tarafından kullanım kolaylığı ve değişimi kolaylaştırmak için özel olarak mı tasarlanmış, geliştirilmiş ve desteklenmiştir? 0: hiç yok ya da etkisiz, 1: önemsiz etki, 2: az etkili , 3:orta düzeyde etkili 4: önemli düzeyde etkili, 5: güçlü etki DI = i=1.. 14 Cevapi TCF = 0,65 + 0,01 x DI TCF: Technical Complexity Factors DI: Total Degree of Influence YZM 403 - Yazılım Proje Yönetimi

İşlev Puanı (Function Points) (devam…) İşlev Puanı aşağıdaki formül ile hesaplanır: FP = UFP x TCF İşlev Puanı’nı, Satır Sayısına dönüştürmek için aşağıdaki formülden yararlanılır. LOC = İşlev Puanı x Programlama Dili LOC Katsayısı Programlama Dili LOC/FP C ++ 53 COBOL 107 DELPHI 5 18 JAVA 2 46 VISUAL BASIC 6 24 SQL 13 YZM 403 - Yazılım Proje Yönetimi

İşlev Puanı (Function Points) – Örnek Proje Kan tahlili yapan bir laboratuarın aynı şehir içerisinde 5 şubesi vardır. Her şubede yaklaşık 10 adet veri giriş operatörü bulunmaktadır. Sistem laboratuardaki tahlillerin fiyatlarını tutacaktır. Hasta bilgileri kaydedilecektir. Yeni tahliller eklenebilecek, güncelleme yapılabilecektir. Tahlil sonuçları laboratuar yetkilisi tarafından onaylandıktan sonra görüntülenebilecektir. İstenen laboratuar tahlillerinin tutarı hesaplanacak ve faturası basılacaktır. Sonuç raporları basılacaktır. Eğer müşterinin daha önceki kayıtları varsa rapor önceki sonuçları da içerecektir. Müşteriler sisteme web üzerinden verilecek şifrelerle bağlanarak tahlil no ile sonuçlarını öğrenebileceklerdir. Sistemin kan analiz cihazıyla arayüzü olacak, sonuçlar direkt olarak cihazdan sisteme aktarılacaktır. Sistem malzeme yönetimi yapacak, malzeme stok bilgilerini tutacaktır. Her laboratuar ana depodan haftalık malzeme isteği yapacaktır. Laboratuarlardan birinde ana malzeme deposu yer alacak, depoya girişler ve birimlere çıkışlar kaydedilecektir. Her malzeme için kritik stok seviyesinin altına düşen malzemeler için sistem uyarı verecek ve rapor yayınlayacaktır. Birim bazında aylık malzeme raporu yayınlanacaktır. Laboratuarın ana sunucusu şubelerden birinde yer alacak ve herhangi bir arıza olduğunda sistem diğer şubedeki yedek sunucuya bağlanacak ve oradan işleme kesintisiz devam edecektir. İletişim altyapısında leased line kullanılacaktır. Sistemi geliştirecek ekip, Java konusunda ve analiz konularında orta deneyimdedir. İşlevsellik konusunda çok fazla deneyimi yoktur. Bir kaç benzer yönetim bilgi sistemi geliştirmiştir. CASE aracı kullanılacaktır. YZM 403 - Yazılım Proje Yönetimi

Örnek Proje – Üst Düzey Sistem Mimarisi B E Ana Sunucu Sistem Fiber Optik D Router C Switch Yedek Sunucu YZM 403 - Yazılım Proje Yönetimi

Örnek Proje – Laboratuar Sistemi Web Üzerinden Sorgu Tahlil Bilgileri Tahlil Sonuç Raporu Şifre, Tahlil No Sonuç Karşılaştırmalı Tahlil Sonuç Raporu Hasta Bilgileri Laboratuar Sistemi Tahlil Onayı Fatura Aylık Malzeme Raporu Fatura Bilgileri Malzeme İsteği Kritik Stok Seviyesi Uyarısı Sonuçlar Stok Bilgileri (Depo Giriş/Çıkış) Kritik Stok Seviyesi Raporu YZM 403 - Yazılım Proje Yönetimi Kan analiz cihazı

Örnek Proje – Düzeltilmemiş İşlev Puanı Girdiler: 6 Karmaşık Çıktılar: 6 Karmaşık İç Dosyalar : 4 Orta Hasta Dosyası Tahliller dosyası Faturalar Dosyası Malzeme Stok Dosyası Dış sorguların sayısı: 1 Orta Dış Arayüz Dosyaları: 1 Orta UFP = Dış Girdiler x W(1) + Dış Çıktılar x W(2) + Dış Sorgular x W(3) + İç Dosyalar x W(4) + Dış Arayüz Dosyaları x W(5) UFP = 6x6 + 6x7+ 4x13 + 1x5 + 1x9 = 144 Basit Orta Karmaşık (1) Dış Girdiler 3 5 6 (2) Dış Çıktılar 4 7 (3) Dış Sorgular (4) İç Dosyalar 13 15 (5) Dış Arayüz Dosyaları 9 10 YZM 403 - Yazılım Proje Yönetimi

Örnek Proje – Düzeltilmiş İşlev Puanı 1. Sistem güvenilir yedekleme ve kurtarma gerektiriyor mu? 5 2. Veri iletişimi gerekiyor mu? 3 3. Dağıtık fonksiyon var mı? 4. Performans kritik mi? 4 5. Sistem çok kullanılan bir işletim ortamında mı çalışacak? 6. Sistem on-line veri girişi gerektiriyor mu? 7. On-line veri girişi, giriş işlemlerinin birden fazla ekran ya da işlem üzerinden olmasını mı gerektiriyor? 8. Ana dosyalar on-line mı güncelleniyor? 9. Girdiler, çıktılar, dosyalar ve sorgular karmaşık mı? 10. Kod yeniden kullanabilir olarak mı tasarlanmış? 11. İç süreç karmaşık mı? 12. Dönüşüm ve kurulum tasarım içerisinde mi? 13. Uygulama değişik kuruluşlarda birden fazla kurulum gerektirecek şekilde mi tasarlanmış? 14. Uygulama kullanıcı tarafından kolaylıkla kullanmayı ve değiştirmek üzere mi tasarlanmış? DI = i=1.. 14 Cevapi = 53 FP = UFP x (0,65 + 0,01 x DI) = 144 x (0, 65 + 0,01 x 53) = 169.92 YZM 403 - Yazılım Proje Yönetimi LOC = 46 x 169.92 = 7816,3

IFPUG İşlev Puanı Analizi IFPUG - International Function Point Users Group (1984) IFPUG uygulama yazılımı geliştirme ve bakım faaliyetlerinin yönetiminde FPA’nın kullanımını teşvik etmektedir. Resmi IFPUG Ölçüm Uygulama Kılavuzları sırasıyla 1986, 1988, 1990, 1994, 1999, 2004 ve 2009’da yayınlanmıştır. IFPUG FPA en yaygın olarak kullanılan FSM yöntemidir. GİRİŞ: Orjinal FPA yöntemini sürdürmek için 1984’te Uluslar Arası İşlev Puanı Kullanıcıları Grubu (International Function Point Users Group - IFPUG) oluşturuldu. IFPUG yazılımın işlevselliğini ölçmek için, FPA yönteminin kullanımını teşvik eden, kar amacı olmayan ve üyeleri tarafından idare edilen bir örgüttür İKİNCİ MADDE: FPA’yı yazılım büyüklüğü için standart metodoloji olarak kabul etmektedir. ÜÇÜNCÜ MADDE: IFPUG, başlangıçta Albrecht tarafından sunulmuş olan tekniği geliştirerek, bu yöntemi standartlaştırmıştır. YZM 403 - Yazılım Proje Yönetimi

Mark II İşlev Puanı Charles Symons’a göre; Bir uygulamanın bileşenlerinin belirlenmesi Albrecht’in FPA’sında zordur, Albrecht yaklaşımı iç karmaşıklıkla ilgili hiçbir düşünceye sahip değildir, On dört ayarlama faktörü yeterli değildir. 1980’lerde İngiltere’de MKII İşlev Puanı geliştirildi. MK II, kullanıcıya sağlanan işlevselliğin değerinden çok işlevselliği üretmek için gerekli emeğe odaklamak için tasarlanmış bir yöntem. MK II, uygulamayı mantıksal işlem gruplarına ayrıştırmaktadır. Symons mantıksal bir işlemi; “bilgi almak için bir gereksinim ya da kullanıcıyı ilgilendiren bir olay ile tetiklenen benzersiz bir girdi/işlem/çıktı birleşimi” olarak tanımlar. İKİNCİ MADDE: Symons, Albrecht’in FPA yönteminde gördüğü bu eksiklikleri çözmek için 1980’lerde İngiltere’de MKII İşlev Puanını geliştirdi. Düzeltilmemiş İşlev Puanı (Unadjusted Function Points - UFP), girdi, çıktı ve işlemlerin toplam sayılarının bir fonksiyonudur. YZM 403 - Yazılım Proje Yönetimi

Nesma İşlev Puanı Netherlands Software Metrics Users Association – NESMA, 1989. NESMA, Avrupa’daki en büyük FPA kullanıcı grubudur. İşlev Puanı Analizinin uygulanması ile ilgili tanımlar ve ölçüm kılavuzunun ilk versiyonu 1990’da yayınlanmıştır. Bu yöntem, IFPUG FPA yönteminin ilkelerini temel almaktadır. IFPUG FPA’a benzer olarak işlevselliğin büyüklüğü için, Dış Giriş, Dış Çıkış, Dış Sorgu, İç Mantıksal Dosya ve Dış Arayüz Dosyası gibi işlev türlerini kullanmaktadır. 1989’da, Hollanda Yazılım Ölçüt Kullanıcıları Birliği (Netherlands Software Metrics Users Association - NESMA), Hollanda İşlev Puanı Kullanıcıları Grubu (Netherlands Function Point Users Group - NEFPUG) olarak kuruldu. YZM 403 - Yazılım Proje Yönetimi

COSMIC Tam İşlev Puanı COSMIC - Common Software Measurement International Consortium Yeni bir işlevsel büyüklük ölçüm yöntemi olarak COSMIC FFP Kasım 1999’da yayınlamıştır. COSMIC FFP yöntemi, geliştirici ve son kullanıcı bakış açıları olmak üzere birçok ölçüm bakış açısına sahiptir. Yazılımın işlevsel büyüklüğü, dört İşlevsel Tabanlı Bileşeni temel alarak ölçülmektedir. İşlevsel Tabanlı Bileşenler; Giriş (Entry), Çıkış (Exit), Okuma (Read) ve Yazma (Write) dır. Uluslararası Ortak Yazılım Ölçüm Birliği, işlevsel yazılım büyüklük ölçümüne yönelik yeni bir metot geliştirmek amacıyla 1998’de kurulmuştur. IFPUG, Mark II ve NESMA gibi mevcut yazılım büyüklük kestirim yöntemlerinin en iyi karakteristik özellikleri alınarak, yeni bir işlev büyüklük ölçüm yöntemi olarak COSMIC FFP’yi Kasım 1999’da yayınlamıştır. YZM 403 - Yazılım Proje Yönetimi

Emek Kestirimi Emek (işgücü) genelde adam-saat, adam- gün ya da adam-ay cinsinden ölçülür. 10 adam-ay: 10 kişi 1 ay 1 kişi 10 ay 2 kişi 5 ay anlamına gelebilir. Emek kestirimi, bir yazılım projesini geliştirmek için kaç kişi ve ne kadar zaman gerektiğini tahmin etmek için kullanılmaktadır. Bir yazılım projesinde emek yatırımı, son yıllarda proje yönetim süreci içindeki en önemli analiz değişkenlerinden biridir. Yazılım projeleri başlatılırken bu değişken değerinin bilinmesi, yazılım yöneticilerinin gelecek faaliyetleri gerektiği gibi planlamasını sağlar. Emek kestiriminde iyi sonuçlar elde etmek için önceki projeleri dikkate almak önemlidir. YZM 403 - Yazılım Proje Yönetimi

Emek Kestirim Yöntemleri Büyüklük Tahmini Yöntemler: Satır Sayısı, Function Points, Geçmiş Proje Verileri                                                                                                                                                                                      SLOC Emek Tahmini Yöntemler Geçmiş proje verilerinden yararlanılması Emek = Büyüklük / Üretim Oranı Üretim oranı her satır kod, her fonksiyon noktası, her modül için gereken zaman ile ölçülür Modellerin kullanılması Constructive Cost Model (COCOMO) (Boehm) Putnam’s Model (SLIM) Use-case Points Class Points UML Points YZM 403 - Yazılım Proje Yönetimi

Emek Kestirim Yöntemleri Emek kestirim yöntemleri algoritmik ve algoritmik olmayan kestirim yöntemleri olmak üzere iki şekilde sınıflandırılmaktadır. Algoritmik kestirim yöntemleri COCOMO (Constructive Costing Model) Use-Case Points Class Points UML Points Algoritmik olmayan kestirim yöntemleri Uzman kararı, Benzerlik ile kestirim, Büyüklük verisi kullanarak kıyaslama. Yazılım emek kestiriminde kullanılan yöntemler, algoritmik ve algoritmik olmayan kestirim yöntemleri olarak sınıflandırılmaktadır. YZM 403 - Yazılım Proje Yönetimi

Algoritmik Kestirim Yöntemleri Bu yöntemler, emek kestirimi için matematiksel modeller (matematiksel formüller) kullanılırlar. Bu tür modellerde geçmişe ait veriler, kod satır sayısı, fonksiyon sayısı vb. istatistikler ile yazılım projelerine doğrudan etki eden çevresel ve teknik faktörler girdi olarak verilir. Model belirli  bir doğruluk aralığında sonuç üretir. Bu tür modellerin içinde bulunan ortama göre bazı parametrelerinin "kalibre" edilmesi gerekmektedir. YZM 403 - Yazılım Proje Yönetimi

COCOMO (Constructive Costing Model) COCOMO, Barry Boehm tarafından geliştirilmiş algoritmik bir yazılım maliyet kestirim yöntemidir. Bu yöntem, geçmiş proje verileri ve mevcut proje özelliklerinden türetilen parametreler ile beraber temel bir regresyon formülü kullanır. Yapılacak hesapların kapsamları açısından basit, orta ve detaylı olmak üzere üç değişik modelden oluşur. Ayrıca bu modellerde kullanılacak problemler, “organik, yarı ayrık ve gömülü sınıflar” altında toplanmıştır. Gereken emeğin, program büyüklüğünün bir üssel değerine bağlı olması prensibi ve endüstriden toplanan bilgiler ışığı altında bir emek kestirim metodu olarak 1981’de Boehm tarafından COCOMO (Constructive Costing Model) geliştirilmiştir. COCOMO göreceli olarak dosdoğru bir modeldir. Yapılacak hesapların kapsamları açısından; basit, orta ve detaylı olmak üzere üç değişik modelden oluşur. YZM 403 - Yazılım Proje Yönetimi

COCOMO (Constructive Costing Model) devam… Orijinal COCOMO modeli yaygın bir merak konusu uyandırdı. Herkese açık bir modeldir. Bunun anlamı denklemlerin, varsayımların, tanımların herkese açık olmasıdır. Orijinal COCOMO modeli 63 proje çalışmasına ve kestirme modelleri sıradüzeni temellerine dayanır. COCOMO Modeli İş Gücü (Emek) Satır Sayısı COCOMO bir parametrik model örneğidir. Çünkü maliyet veya süre gibi bağımlı değişkenler kullanır. COCOMO ile kestirim süreci, projenin tipinin saptanması ile başlar. Proje tiplerinin nasıl sınıflandırıldığını bir sonraki slaytta göreceğiz. Zaman YZM 403 - Yazılım Proje Yönetimi

COCOMO - Proje Sınıfları Ayrık Projeler; Boyutları küçük, Deneyimli personel tarafından gerçekleştirilmiş, LAN üzerinde çalışan, insan kaynakları yönetim sistemi gibi projeler... Yarı Ayrık Projeler: Hem bilgi boyutu, hem donanım sürme boyutu olan projeler… Gömülü Projeler: Donanım sürmeyi hedefleyen projeler (pilotsuz uçağı süren yazılım - donanım kısıtları yüksek) Ayrık projeler; küçük boyuttaki programcı takımlarının, iyi bildikleri bir ortamda uygulamalar geliştirmesidir. İletişim problemi azdır ve elemanlar çabucak işlerini halledebilecek durumdadırlar. Yarı ayrık projelerde ise ekipte tecrübeli ve tecrübesiz elemanlar bulunabilir. İlgili sistemler konusunda deneyimleri sınırlı olabilir ve geliştirilen sistemin her şeyini bilmeyebilirler. Gömülü projelerde ise geliştirilecek yazılım, sistemin donanım, kurallar, işletim süreçleri veya yazılım gibi diğer bileşenleri ile çok kuvvetli bağlantılar oluşturur. Gereksinim değişiklikleri ile problemleri halletmek olanaksızlaşmıştır. İhtiyaç belirtiminin geçerlilik irdelemesi çok pahalıdır. Elemanların her şeyi bilme olasılığı iyice azalmıştır. YZM 403 - Yazılım Proje Yönetimi

COCOMO (Constructive Costing Model) devam… COCOMO bu model ve proje sınıfı saptamalarından sonra ortaya çıkan formüllerle tahmin hesaplama yolunu önerir. Basit COCOMO Modeli İçin Emek ve Süre Formülleri Proje Emek Süre Ayrık Emek = 2.4 (KLOC)1.05 Süre = 2.5 (Emek)0.38 Yarı Ayrık Emek = 3 (KLOC)1.12 Süre = 2.5 (Emek)0.35 Gömülü Emek = 3.6 (KLOC)1.20 Süre = 2.5 (Emek)0.32 Kullanılacak ayrıntı düzeyine göre Basit, Orta ve Detaylı olmak üzere üç temel model vardır. Basit COCOMO modeli, küçük-orta boy projeler için hızlı kestirim yapmak amacıyla kullanılır. Avantajı: Hesap makinesi ile kolaylıkla hesaplanabilir. Dezavantajı: Yazılım projesinin geliştirileceği ortam ve yazılımı geliştirecek ekibin özelliklerini dikkate almaz. Basit COCOMO modeli, küçük-orta boy projeler için hızlı kestirim yapmak amacıyla kullanılır. YZM 403 - Yazılım Proje Yönetimi

COCOMO (Constructive Costing Model) devam… Orta COCOMO modeli sistemin (güvenilirlik, veri tabanı büyüklüğü, işletme ve kayıt sınırlandırmaları, personel özellikleri ve kullanılan yazılım araçları gibi) diğer özelliklerinin hesaba katılması amaçlanmıştır. Orta COCOMO Modeli İçin Emek Formülleri Problem Emek Ayrık Emek = 3.2 (KLOC)1.05 x EAF Yarı Ayrık Emek = 3.0 (KLOC)1.12 x EAF Gömülü Emek = 2.8 (KLOC)1.20 x EAF Bu faktörler, ilgili özellik için düşük (<1), nominal (1) veya yüksek (>1) olarak saptanırlar.   Katsayılar birbiri ile çarpıldığında Emek Ayarlama Faktörü (EAF) (Effort Adjustment Factor) bulunur. Bu katsayı 0.9 ile 1.4 arasında bir değer alır ve Tabloda gösterilen Orta COCOMO modeli formülleri kullanılarak emek hesaplaması sonuçlandırılır. Süre hesaplaması ise Basit COCOMO modelinde olduğu gibi yapılır. Belirli bir dizi özelliğin, proje açısından etkileri ayrı ayrı ağırlandırılarak katsayılar ortaya çıkarılır. YZM 403 - Yazılım Proje Yönetimi

COCOMO (Constructive Costing Model) devam… Cost Drivers Ratings very low low nominal high very high extra high Product Attributes RELY Required Software Reliability 0,75 0,88 1 1,15 1,4 DATA Database Size 0,94 1,08 1,16 CPLX Product Complexity 0,7 0,85 1,3 1,65 Computer Attributes TIME Execution Time Constraint 1,11 1,66 STOR Main Storage Constraint 1,06 1,21 1,56 VIRT Virtual Machine Volatility 0,87 TURN Computer Turnaround Time 1,05 Personnel Attributes ACAP Analyst Capability 1,46 1,19 0,86 0,71 AEXP Application Experience 1,29 1,13 0,91 0,82 PCAP Programmer Capability 1,42 1,17 VEXP Virtual Machine Experience 1,1 0,9 LEXP Programming Language Experience 1,14 1,07 0,95 Project Attributes MODP Modern Programming Practices 1,24 TOOL Use of Software Tools 0,83 SCED Schedule Constraints 1,23 1,04 Emek Ayarlama Faktörü için sözü geçen etkenleri dört grupta toplayarak, yandaki tabloda görüldüğü gibi sıralayabiliriz. EAF (Emek Ayarlama Faktörü) orta ve detaylı seviyede kullanılır. Detaylı COCOMO modeli projenin evrelerine bağlı olarak süreç içinde değişiklikleri hesaba katarak arada bir kestirim hesaplamasını önerir. Bu modelde zamana bağlılık temel değişikliktir. Projenin farklı evrelerinde çaba yoğunluğu ve yapılacak işin karmaşıklığı değişecektir. Detaylı COCOMO modeli, basit ve orta COCOMO modeline ek olarak iki özellik taşır. Aşama ile ilgili işgücü katsayıları: her aşama için (planlama, analiz, tasarım, geliştirme, test etme) farklı katsayılar, karmaşıklık belirler. Yazılım maliyet kestiriminde; Modül, Altsistem, Sistem sıra düzenini dikkate alır. 1981’de Boehm tarafından ortaya konan COCOMO modeli daha sonra geliştirilmiş ve COCOMO II adını almıştır. YZM 403 - Yazılım Proje Yönetimi

COCOMO – Emek Ayarlama Faktörü Ürün Özellikleri RELY: Yazılımın güvenirliği. DATA: Veritabanının büyüklüğü. CPLX: Karmaşıklığı. Bilgisayar Özellikleri TIME: İşletim zamanı kısıtı. STOR: Ana bellek kısıtı VIRT: Bilgisayar platform değişim olasılığı. Örn; bellek ve disk kapasitesi artırımı, CPU upgrade… TURN: Bilgisayar iş geri dönüş zamanı. Örn; hata düzeltme süresi. YZM 403 - Yazılım Proje Yönetimi

COCOMO – Emek Ayarlama Faktörü (devam…) Personel Özellikleri ACAP: Analist yeteneği. Deneyim, birlikte çalışabilirlik. AEXP: Uygulama deneyimi. Proje ekibinin ortalama tecrübesi. PCAP: Programcı yeteneği. VEXP: Bilgisayar platformu deneyimi. Proje ekibinin geliştirilecek platformu tanıma oranı. LEXP: Programlama dili deneyimi. Proje Özellikleri MODP: Modern programlama teknikleri. Örn; Yapısal programlama, görsel programlama, yeniden kullanılabilirlik. TOOL: Yazılım geliştirme araçları kullanımı. Örn; CASE araçları, metin düzenleyiciler, ortam yönetim araçları SCED: Zaman kısıtı. YZM 403 - Yazılım Proje Yönetimi

Örnek: Laboratuar Sistemi için COCOMO ile Emek Kestirimi Cost Drivers Ratings Proje low very low nominal high very high extra high Oran Product Attributes RELY Required Software Reliability 0,75 0,88 1 1,15 1,4 DATA Database Size 0,94 1,08 1,16 CPLX Product Complexity 0,7 0,85 1,3 1,65 Computer Attributes TIME Execution Time Constraint 1,11 1,66 STOR Main Storage Constraint 1,06 1,21 1,56 VIRT Virtual Machine Volatility 0,87 TURN Computer Turnaround Time 1,05 Personnel Attributes ACAP Analyst Capability 1,46 1,19 0,86 0,71 AEXP Application Experience 1,29 1,13 0,91 0,82 PCAP Programmer Capability 1,42 1,17 VEXP Virtual Machine Experience 1,1 0,9 LEXP Programming Language Experience 1,14 1,07 0,95 Project Attributes MODP Modern Programming Practices 1,24 TOOL Use of Software Tools 0,83 SCED Schedule Constraints 1,23 1,04 Emek Ayarlama Katsayısı: YZM 403 - Yazılım Proje Yönetimi

Örnek: Laboratuar Sistemi için COCOMO ile Emek Kestirimi (devam…) Emek = 3.0 x (KLOC)1.12 x EAF Emek = 3.0 x (7816)1.12 x 1,23 = 36,9 adam-ay Takvim= 2.5 x Emek 0,38= 2.5 x 36,90,38 = 9,84 ay (Geliştirme Zamanı) N = Emek / Geliştirme Zamanı → (N: ortalama personel sayısı) N = 36,9 / 9,84 = 3,75 – 4 kişi YZM 403 - Yazılım Proje Yönetimi

Use-Case Puanı (Use-Case Points - UCP) Use-Case Points (UCP) yaklaşımı, bir yazılım proje emek kestirim yöntemi olarak Karner tarafından ortaya atılmıştır. Nesneye-tabanlı yazılım üretiminde, use-case’ler işlevsel gereksinimleri tanımlar. Use-Case diyagramları, gereksinimlerin analiz edilmesi aşamasında belirlenmiş hedef sistemin işlevsel davranışlarını incelerler. Use-Case Points, use-case sayısına dayanan bir yazılım emek kestirim metodudur ve ilk olarak 1993 yılında Gustav Karner tarafından geliştirilmiştir. Bu yöntem İşlev Puanı Analizi (Function Point Analysis) ve Mark II İşlev Puanı Analizi (Mk II Function Point Analysis)’nin bir uzantısıdır ve bu yöntemler gibi aynı felsefeyi temel almaktadır. Nesneye-tabanlı yazılım üretiminde, use-case’ler işlevsel gereksinimleri tanımlar. Use-Case Points ile, use-case’lerin aktörleri, senaryoları ile birçok teknik ve çevresel faktörlerü analiz ederek, emek kestirimi için bir büyüklük tahmini oluşturmuş oluyoruz. YZM 403 - Yazılım Proje Yönetimi

Use-Case Puanı (Use-Case Points - UCP) (devam…) Use-Case Puanı (UCP) sistemin use-case analizi ile elde edilebilir: Use-case analizinin birinci adımı aktörlerin sınıflandırılmasıdır. Aktör Tipi Açıklaması Ağırlık Faktörü Basit Tanımlı bir Uygulama Programlama Arayüzüne (API) sahip başka bir sistemi temsil eder. 1 Orta TCP/IP gibi bir protokol ile haberleşen başka bir sistemi temsil eder. 2 Karmaşık Bir web sayfası veya GUI aracılığıyla karşılıklı etkileşen bir kullanıcıyı temsil eder. 3 Use-case puanı, sistemin use-case analizinden sayılabilir. İlk adım, aktörleri basit, orta ve karmaşık tipte sınıflandırmaktır. Basit tipte bir aktör, tanımlı bir Uygulama Programı Arayüzüne (Application Programming Interface - API) sahip başka bir sistemi temsil eder. Orta tipte bir aktör, TCP/IP gibi bir protokol aracılığıyla haberleşen başka bir sistemi temsil eder. Karmaşık tipte bir aktör ise, bir Web sayfası veya bir Grafik Kullanıcı Arayüzü (Graphical User Interface - GUI) aracılığıyla karşılıklı etkileşen bir kullanıcıyı temsil eder. Her bir aktör tipine bir ağırlık faktörü atanmıştır. Öncelikle toplam Düzeltilmemiş Aktör Ağırlığı (Unadjusted Actor Weights - UAW) hesaplanmaktadır. YZM 403 - Yazılım Proje Yönetimi

Use-Case Puanı (Use-Case Points - UCP) (devam…) Use-case analizinin ikinci adımı use-case’lerin sınıflandırılmasıdır. Use-Case Tipi Açıklaması Ağırlık Faktörü Basit Basit bir kullanıcı arayüzüne sahiptir. Tek bir veritabanı nesnesiyle iletişim kurar. Normal (başarılı) senaryosu 3 veya daha az basamaktan oluşur. 5 Orta Ortalama bir kullanıcı arayüzüne sahiptir. İki veya daha fazla veritabanı nesnesi ile iletişim kurar. Normal (başarılı) senaryosu 4 ile 7 arasında basamaktan oluşur. 10 Karmaşık Karmaşık bir kullanıcı arayüzüne sahiptir. Üç veya daha fazla veritabanı nesnesiyle iletişim kurar. Normal (başarılı) senaryosu 8 veya daha fazla basamaktan oluşur. 15 Her use-case, ikinci senaryo da dâhil, use-case açıklamasındaki işlemlerin sayısına bağlı olarak basit, orta veya karmaşık olarak tanımlanır. Bir işlem ya tamamen gerçekleştirilmiş ya da hiç gerçekleştirilmemiş faaliyetler kümesidir. İşlem sayısını sayma, use-case adımlarını sayarak yapılabilir. Düzeltilmemiş Aktör Ağırlığı ile Düzeltilmemiş Use-Case Ağırlığının toplanması sonucu Düzeltilmemiş Use-Case Puanı (Unadjusted Use-Case Points - UUCP) elde edilir. Düzeltilmemiş Use-Case Ağırlığını (Unadjusted Use-Case Weights - UUCW) elde etmek için: Use-case analizinin üçüncü adımı Düzeltilmemiş Use-Case Puanı (Unadjusted Use- Case Points - UUCP) nın hesaplanmasıdır: YZM 403 - Yazılım Proje Yönetimi

Use-Case Puanı (Use-Case Points - UCP) (devam…) Use-case analizinin dördüncü adımı Teknik Karmaşıklık Faktörünün hesaplanmasıdır. Teknik Faktör Açıklaması Ağırlık Faktörü T1 Dağıtık Sistem 2 T2 Yanıt veya Çıktı Performans Hedefleri 1 T3 Son Kullanıcı Verimliliği T4 Karmaşık Dâhili İşlem T5 Kodun Yeniden Kullanılabilirliği T6 Kurulum Kolaylığı 0.5 T7 Kullanım Kolaylığı T8 Taşınabilirlik T9 Değişim Kolaylığı T10 Eş Zamanlılık T11 Özel Güvenlik Özellikleri İçerme T12 Üçüncü Parti Yazılımlar için Doğrudan Erişim Sağlama T13 Kullanıcı Eğitim Gerekliliği Yazılım geliştiren takım teknik faktörleri değerlendirir ve etki derecesine her bir faktöre 0 ile 5 arasında bir karmaşıklık değeri atanır. 0 değeri o faktörün projede etkisinin olmadığı, 3 değeri orta derecede etkili olduğu, 5 değeri ise yüksek derecede etkili olduğu anlamına gelir. YZM 403 - Yazılım Proje Yönetimi

Use-Case Puanı (Use-Case Points - UCP) (devam…) Use-case analizinin beşinci adımı Çevresel Karmaşıklık Faktörünün hesaplanmasıdır. Çevresel Faktör Açıklaması Ağırlık Faktörü E1 UML ile Tanışıklık 1.5 E2 Uygulama Deneyimi 0.5 E3 Nesneye-Tabanı Deneyim 1 E4 Lider Analist Yeteneği E5 Motivasyon E6 Sabit Gereksinimler 2 E7 Yarı-Zamanlı Çalışanlar -1 E8 Zor Programlama Dili Use-case puanı hesaplanırken, teknik faktörlerin yanında çevresel faktörlerinde göz önünde bulundurulması gerekir. Use-case puanı hesaplanırken, programcı motivasyonu, kullanım kolaylığı gibi işlevsel olmayan gereksinimleri ölçmek amacıyla çevresel faktörler çarpanı kullanılır. Yazılım geliştiren takım çevresel faktörleri değerlendirir ve her bir faktöre etki derecesine göre 0 ile 5 arasında bir etki değeri atar. 0 değeri o faktörün projede etkisinin olmadığı, 1 değeri yüksek derecede negatif etkili olduğu, 3 değeri orta derecede etkili olduğu, 5 değeri ise yüksek derecede pozitif etkili olduğu anlamına gelir. Üretkenlik Faktörü, geçmiş projelerde harcanan adam-saat sayısının Use-Case Puanı (UCP) oranıdır. Gustav Karner, bir projedeki ortalama Üretkenlik Faktörü (ÜF) için 20 adam-saat önermektedir. Use-case analizinin altıncı adımı Use-Case Puanının hesaplanmasıdır: Use-case analizinin son adımı Emeğin hesaplanmasıdır: YZM 403 - Yazılım Proje Yönetimi

YZM 403 - Yazılım Proje Yönetimi   PROJE PROJE İLE İLGİLİ BİLGİLER A B C Aktör Sayıları Basit Tanımlı bir Uygulama Programlama Arayüzüne (API) sahip başka bir sistemi temsil eder. 1 Orta TCP/IP gibi bir protokol ile haberleşen başka bir sistemi temsil eder. 6 4 Karmaşık Bir web sayfası veya GUI aracılığıyla karşılıklı etkileşen bir kullanıcıyı temsil eder. 5 11 7 Düzeltilmemiş Aktör Ağırlıkları (DAA) 15 46 29 Use-Case Sayıları Basit bir kullanıcı arayüzüne sahiptir. Tek bir veritabanı nesnesiyle iletişim kurar. Normal (başarılı) senaryosu 3 veya daha az basamaktan oluşur ve tasarımı 5 veya daha az sınıf içerir. 8 2 Ortalama bir kullanıcı arayüzüne sahiptir. İki veya daha fazla veritabanı nesnesi ile iletişim kurar. Normal (başarılı) senaryosu 4 ile 7 arasında basamaktan oluşur ve tasarım 5 ile 10 arasında sınıf içerir. 12 21 17 Karmaşık bir kullanıcı arayüzüne sahiptir. Üç veya daha fazla veritabanı nesnesiyle iletişim kurar. Normal (başarılı) senaryosu 8 veya daha fazla basamaktan oluşur ve tasarımı 11 veya daha fazla sınıf içerir. 63 Düzeltilmemiş Use-Case Ağırlıkları (DUCA) 235 1155 300 Teknik Faktörler T1 Dağıtık Sistem T2 Yanıt veya Çıktı Performans Hedefleri 3 T3 Son Kullanıcı Verimliliği T4 Karmaşık Dâhili İşlem T5 Kodun Yeniden Kullanılabilirliği T6 Kurulum Kolaylığı T7 Kullanım Kolaylığı T8 Taşınabilirlik T9 Değişim Kolaylığı T10 Eş Zamanlılık T11 Özel Güvenlik Özellikleri İçerme T12 Üçüncü Parti Yazılımlar için Doğrudan Erişim Sağlama T13 Kullanıcı Eğitim Gerekliliği Teknik Karmaşıklık Faktörü (TKF) 0,795 1,11 0,855 Çevresel Faktörler E1 UML ile Tanışıklık E2 Uygulama Deneyimi E3 Nesneye-Tabanı Deneyim E4 Lider Analist Yeteneği E5 Motivasyon E6 Sabit Gereksinimler E7 Yarı-Zamanlı Çalışanlar E8 Zor Programlama Dili Çevresel Karmaşıklık Faktörü (ÇKF) 0,575 0,8 0,815 Üretkenlik Faktörü 20 Use-Case Puanı 114 1066 229 Emek Tahmini (adam-saat) 2280 21320 4580 Harcanan Gerçek Emek (adam-saat) 3623 25686 5948 Fark (1 – Tahmin / Gerçek) 0,37 0,17 0,23 YZM 403 - Yazılım Proje Yönetimi

Sınıf Puanı (Class Points - CP) Sınıf diyagramları, geliştirilen sistemin mantıksal blokları olan sınıf hiyerarşini ve hedef sistemin yapısal işlevselliğini içerir. Sınıf Puanı yaklaşımı, 1998’de ortaya atılmıştır. Bu yaklaşım, sayısal hesaplamaya dayanarak bir sistemin iç niteliklerini temsil eden işlev puanı analiz yaklaşımını temel almaktadır. CP1 ve CP2 olmak üzere iki ölçüm ortaya atılmıştır. Nesneye dayalı geliştirmede sınıf diyagramları, büyük ölçüde tasarım dokümanını temel alan niceliksel bilgilere sahip diyagramlardır. Sınıf Puanı (Class Point), tasarım dokümanını temel alarak nesne-tabanlı yazılım ürünlerinin büyüklüğünü tahmin etmek için tasarlanmış bir yaklaşımdır. Özellikle, CP1 ve CP2 olarak adlandırılan iki ölçüm ortaya atılmaktadır. CP1 yazılım geliştirme sürecinin başında bir ön büyüklük tahmini yürütmek için kullanılmaktadır. Bu CP1, daha sonra geliştirilecek sistemle ilgili daha fazla bilgi elde edildiğinde CP2 uygulanarak iyileştirilir. YZM 403 - Yazılım Proje Yönetimi

Sınıf Puanı (Class Points - CP) (devam…) Kullanıcı Sınıflarının Belirlenmesi ve Sınıflandırılması Tasarım dokümanı analiz edilirken 4 tür sistem bileşeni kullanılır: Problem Alan Türü (Problem Domain Type – PDT), İnsan Etkileşim Türü (Human Interaction Type – HIT), Veri Yönetim Türü (Data Management Type), Görev Yönetim Türü (Task Management Type – TMT). Sınıfların Karmaşıklık Düzeylerinin Belirlenmesi CP1 içinde her bir sınıfın karmaşıklık düzeyi iki ölçüt ile belirlenmektedir: Dış Metotların Sayısı (Number of External Methods – NEM), Servis İsteklerinin Sayısı (Number of Services Requested – NSR) CP2 içinde, her bir sınıfın karmaşıklık düzeyini değerlendirmek üzere Niteliklerin Sayısı (Number Of Attributes – NOA) dikkate alınmaktadır. GİRİŞ: Sınıf Puanı büyüklük kestirim süreci, FP yaklaşımındaki safhalara benzer olarak dört temel aşamada yapılandırılmıştır. İlk adımda, kullanıcı sınıflarını belirlemek ve sınıflandırmak için tasarım dokümanı analiz edilir. Tasarım dokümanı analiz edilirken, Problem Alan Türü (Problem Domain Type – PDT), İnsan Etkileşim Türü (Human Interaction Type – HIT), Veri Yönetim Türü (Data Management Type), Görev Yönetim Türü (Task Management Type – TMT) olmak üzere dört tür sistem bileşeni kullanılır. İkinci adımda, sınıflar içersindeki yerel metotlar üzerinden belirlenmiş olan her bir tanımlı sınıfa bir karmaşıklık düzeyi atanır. Bu OO sınıflar için uygun ölçümlerin kullanımı ile sağlanır. NEM ölçüsü, genel olan yerel metotların sayısı ile verilen ve nesne-tabanlı bir sistemde tek bir sınıfın arayüz büyüklüğünü tahmin etmemize olanak sağlamaktadır. NSR sistem bileşenlerinin ara bağlantıları için bir ölçüm sağlar. Bu ölçütte tek bir sınıf için geçerlidir ve diğer sınıflar için farklı servis isteklerinin sayısı ile belirlenmektedir. YZM 403 - Yazılım Proje Yönetimi

Sınıf Puanı (Class Points - CP) (devam…) CP1 için Bir Sınıfın Karmaşıklık Düzeyini Değerlendirme CP2 için Bir Sınıfın Karmaşıklık Düzeyini Değerlendirme 0 – 4 NEM 5 – 8 NEM ≥ 9 NEM 0 – 1 NSR Düşük Orta 2 – 3 NSR Yüksek ≥ 4 NSR 0 – 2 NSR 0 – 5 NOA 6 – 9 NOA ≥ 10 NOA 0 – 4 NEM Düşük Orta 5 – 8 NEM Yüksek ≥ 9 NEM (a) 3 – 4 NSR 0 – 4 NOA 5 – 8 NOA ≥ 9 NOA 0 – 3 NEM Düşük Orta 4 – 7 NEM Yüksek ≥ 8 NEM (b) Her sınıfa bir karmaşıklık düzeyi atamadan önce, sınıfa bir ağırlık atamak için bu tür bilgiler kullanılmaktadır. CP1 içinde her bir sınıfın karmaşıklık düzeyi iki ölçüt ile belirlenmektedir: - Dış Metotların Sayısı (Number of External Methods – NEM), - Servis İsteklerinin Sayısı (Number of Services Requested – NSR) CP2 içinde, her bir sınıfın karmaşıklık düzeyini değerlendirmek üzere Niteliklerin Sayısı (Number Of Attributes – NOA) dikkate alınmaktadır. ≥ 5 NSR 0 – 3 NOA 4 – 7 NOA ≥ 8 NOA 0 – 2 NEM Düşük Orta 3 – 6 NEM Yüksek ≥ 7 NEM (c) YZM 403 - Yazılım Proje Yönetimi

Sınıf Puanı (Class Points - CP) (devam…) Toplam Düzeltilmemiş Sınıf Puanın (Total Unadjusted Class Point – TUCP) Hesaplanması Sistem Bileşen Türü Açıklama Karmaşıklık Düşük Orta Yüksek Toplam PDT Problem Alan Türü … x 3 = … … x 6 = … … x 10 = … … HIT İnsan Etkileşim Türü … x 4 = … … x 7 = … … x 12 = … DMT Veri Yönetim Türü … x 5 = … … x 8 = … … x 13 = … TMT Görev Yönetim Türü … x 9 = … Toplam Düzeltilmemiş Sınıf Puanı (TUCP): Problem Alan Türü (Problem Domain Type – PDT), İnsan Etkileşim Türü (Human Interaction Type – HIT), Veri Yönetim Türü (Data Management Type), Görev Yönetim Türü (Task Management Type – TMT). YZM 403 - Yazılım Proje Yönetimi

Sınıf Puanı (Class Points - CP) (devam…) Teknik Karmaşıklık Faktörünün (Technical Complexity Factor – TCF) Hesaplanması Sistem Karakteristiği ED C1 Veri İletişimi … C10 Yeniden Kullanılabilirlik C2 Dağıtık Fonksiyonlar C11 Kurulum Kolaylığı C3 Performans C12 İşlem Kolaylığı C4 Konfigürasyon Kullanım Yoğunluğu C13 Çoklu Bölgeler C5 İşlem Oranı C14 Değişim Kolaylığı C6 Online Veri Girişi C15 Kullanıcı Uyarlanabilirliği C7 Son Kullanıcı Verimliliği C16 Hızlı Prototipleme C8 Online Güncelleme C17 Çoklu Kullanıcı Etkileşimi C9 Karmaşık İşlem C18 Çoklu Arayüzler Toplam Etki Derecesi (Total Degree of Influence – TDI): Etkisi yok = 0 Önemsiz Etki = 1 Orta Karar Etki = 2 Ortalama Etki = 3 Önemli Etki = 4 Güçlü Etki = 5 Sınıf Puanı: TDI = FPA’da ki gibi genel sistem özellikleri göz önünde bulundurularak elde edilen bir değer. YZM 403 - Yazılım Proje Yönetimi

Algoritmik Olmayan Kestirim Yöntemleri Algoritmik olmayan emek kestirim yöntemleri; uzman kararı, benzerlik ile kestirim ve büyüklük verisi kullanarak kıyaslama’dır. YZM 403 - Yazılım Proje Yönetimi

Uzman Kararı Uzman kararı yöntemi, yazılım endüstrisinde emek kestirimi için en çok kullanılan yöntemdir. Yıllardan beri proje yöneticileri kendi deneyimlerine güvenmişlerdir. Uzman kararında, pek çok uzman önerilen yazılımın uygulama alanı ve geliştirme tekniklerine göre proje emeğini tahmin etmektedir. Yeni proje daha önce tamamlanan projelerden çok farklı değilse ve deneyimli kestirimciler mevcutsa, emek kestirimi için en uygun yöntem uzman kararıdır. Ancak, kestirimde uzman kararını kullanmanın bazı zorlukları da vardır. Bu kişisel bir kestirim olacaktır. Her yeni proje için çok deneyimli kestirim yapabilecek kişi bulmak zordur. Sonuç ortaya çıkana kadar uzmanın görüşünü test etmenin hiçbir yolu yoktur ve bu çok geç olabilir. Eğer uzman yoksa, çok yanlış olacaktır. YZM 403 - Yazılım Proje Yönetimi

Benzerlik ile Kestirim Bu yöntemde, projelere ilişkin pek çok nitelik tanımlanır. Bu nitelikler tamamlanmış projeler arasından yeni projeye en çok benzeyen projeleri belirlemek için kullanılır. Yeni projenin emek kestirimi, yeni proje ile tamamlanmış projeler arasındaki farklılıklar dikkate alınarak belirlenir. Benzerlik esaslı kestirim için, daha önce tamamlanmış benzer projelere ait geçmiş veriler gereklidir. Bu nedenle, bu kestirim yöntemi tamamlanmış projelere ait verileri tutan veri tabanlarına gereksinim duymaktadır. ÜÇÜNCÜ MADDEDEN SONRA SÖYLE: Benzerlik esaslı kestirim, bütün proje seviyesinde veya alt sistem seviyesinde gerçekleştirilebilir. Bütün proje seviyesini esas alan kestirimler, sistemin tüm maliyet bileşenlerini dikkate alır. Diğer taraftan, alt sistem seviyesini esas alan kestirimler, yeni proje ile tamamlanmış projeler arasındaki benzerlikler ve farklılıkların daha detaylı bir değerlendirmesini sağlamaktadır. YZM 403 - Yazılım Proje Yönetimi

Büyüklük Verisini Kullanarak Kıyaslama Bu yöntem, verimliliğin bir uygulama alanı ve büyüklük fonksiyonu olduğu düşüncesini temel almaktadır. Aşağıda verilen formüle göre, büyüklük verisini kullanarak kıyaslama ile emeği hesaplamak çok basittir; Emek Tahmini = Proje Büyüklüğü / Teslimat Oranı YZM 403 - Yazılım Proje Yönetimi

Stok Takip Sistemi FP LOC Emek Zaman N(Personel Sayısı) YZM 403 - Yazılım Proje Yönetimi