Sunum yükleniyor. Lütfen bekleyiniz

Sunum yükleniyor. Lütfen bekleyiniz

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

Benzer bir sunumlar


... konulu sunumlar: "YAZILIM PROJE YÖNETİMİ Öğr. Gör. Dr. Emin BORANDAĞ Maltepe Üniversitesi Mühendislik Fakültesi YZM 403."— Sunum transkripti:

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

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

3 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 Genel Bakış… 3

4 Giriş YZM Yazılım Proje Yönetimi 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. 4

5 5 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, YZM Yazılım Proje Yönetimi

6 6 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. YZM Yazılım Proje Yönetimi

7 7 Beş Temel Yazılım Ölçütü Büyüklük (Size), Emek (Effort), Maliyet (Cost), Zaman (Duration), Kalite (Quality). YZM Yazılım Proje Yönetimi

8 8 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 Yazılım Proje Yönetimi

9 Teknik Büyüklük Kestirim Yöntemleri Satır Sayısı (Lines of Code - LOC): 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. 9 YZM Yazılım Proje Yönetimi

10 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? 10 YZM Yazılım Proje Yönetimi

11 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ı 11 YZM Yazılım Proje Yönetimi

12 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ı 12 YZM Yazılım Proje Yönetimi

13 İş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… 13 YZM Yazılım Proje Yönetimi

14 İş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), 14 YZM Yazılım Proje Yönetimi

15 İş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. 15 YZM Yazılım Proje Yönetimi

16 İşlev Puanı (Function Points) (devam…) 16 İşlev Puanı SLOC’a dönüştürme SLOC FP 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 İşlev Puanını, SLOC’a dönüştürmek için programlama diline göre saptanan faktörler kullanılır. Teknik Karmaşıklık Faktörleriyle ayarlama YZM Yazılım Proje Yönetimi

17 İş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) 17 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 Yazılım Proje Yönetimi

18 İş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. 18 Genel Sistem ÖzellikleriKısa Açıklama 1Veri İletişimleri Sistemin uygulaması ile bilgi değişimi veya transferinde yardımcı olmak için kaç tane iletişim aracı vardır? 2Dağıtılan Veri/İşlemeDağıtılan bilgi ve işleme fonksiyonları nasıl idare edilmektedir? 3Performans 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şiHangi oranda bilgi çevrimiçi girilmektedir? 7Son Kullanıcı VerimliliğiUygulama son kullanıcı verimliliği için mi tasarlanmıştır? 8Çevrimiçi GüncellemeKaç veri dosyası çevrimiçi güncellenmektedir? 9Karmaşık İşlem YapmaDâhili işlem yapma karmaşık mıdır? 10Yeniden KullanılabilirlikUygulama yeniden kullanılabilir olması için mi tasarlanmıştır? 11Dö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? 14Değ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= Cevap i TCF: Technical Complexity Factors DI: Total Degree of Influence TCF = 0,65 + 0,01 x DI YZM Yazılım Proje Yönetimi

19 İş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ı 19 YZM Yazılım Proje Yönetimi

20 İşlev Puanı (Function Points) – Örnek Proje 1.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. 2.Sistem laboratuardaki tahlillerin fiyatlarını tutacaktır. 3.Hasta bilgileri kaydedilecektir. 4.Yeni tahliller eklenebilecek, güncelleme yapılabilecektir. 5.Tahlil sonuçları laboratuar yetkilisi tarafından onaylandıktan sonra görüntülenebilecektir. 6.İstenen laboratuar tahlillerinin tutarı hesaplanacak ve faturası basılacaktır. 7.Sonuç raporları basılacaktır. Eğer müşterinin daha önceki kayıtları varsa rapor önceki sonuçları da içerecektir. 8.Müşteriler sisteme web üzerinden verilecek şifrelerle bağlanarak tahlil no ile sonuçlarını öğrenebileceklerdir. 9.Sistemin kan analiz cihazıyla arayüzü olacak, sonuçlar direkt olarak cihazdan sisteme aktarılacaktır. 10.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. 11.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. 12.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. 20 YZM Yazılım Proje Yönetimi

21 Örnek Proje – Üst Düzey Sistem Mimarisi 21 A B D C Yedek Sunucu Ana Sunucu E Router Switch SistemSistem FiberOptik YZM Yazılım Proje Yönetimi

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

23 Örnek Proje – Düzeltilmemiş İşlev Puanı 23 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 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 = 6x6 + 6x7+ 4x13 + 1x5 + 1x9 = 144 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) YZM Yazılım Proje Yönetimi

24 Örnek Proje – Düzeltilmiş İşlev Puanı 24 DI =  i= Cevap i = 53 FP = UFP x (0,65 + 0,01 x DI) = 144 x (0, ,01 x 53) = LOC = 46 x = 7816,3 YZM Yazılım Proje Yönetimi

25 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. 25 YZM Yazılım Proje Yönetimi

26 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. 26 YZM Yazılım Proje Yönetimi

27 Nesma İşlev Puanı Netherlands Software Metrics Users Association – NESMA, 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. 27 YZM Yazılım Proje Yönetimi

28 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. 28 YZM Yazılım Proje Yönetimi

29 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. 29 YZM Yazılım Proje Yönetimi

30 Emek Kestirim Yöntemleri 30 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 Büyüklük Tahmini Emek Tahmini Yöntemler: Satır Sayısı, Function Points, Geçmiş Proje Verileri SLOC YZM Yazılım Proje Yönetimi

31 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. 31 YZM Yazılım Proje Yönetimi

32 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. 32 YZM Yazılım Proje Yönetimi

33 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. 33 YZM Yazılım Proje Yönetimi

34 COCOMO (Constructive Costing Model) devam… 34 COCOMOModeliCOCOMOModeli Satır Sayısı İş Gücü (Emek) Zaman 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. YZM Yazılım Proje Yönetimi

35 35 COCOMO - Proje Sınıfları Ayrık Projeler; 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: Yarı Ayrık Projeler:  Hem bilgi boyutu, hem donanım sürme boyutu olan projeler… Gömülü 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) YZM Yazılım Proje Yönetimi

36 COCOMO (Constructive Costing Model) devam… 36 COCOMO bu model ve proje sınıfı saptamalarından sonra ortaya çıkan formüllerle tahmin hesaplama yolunu önerir. ProjeEmekSüre AyrıkEmek = 2.4 (KLOC) 1.05 Süre = 2.5 (Emek) 0.38 Yarı AyrıkEmek = 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 Basit COCOMO Modeli İçin Emek ve Süre Formülleri Basit COCOMO modeli, küçük-orta boy projeler için hızlı kestirim yapmak amacıyla kullanılır. YZM Yazılım Proje Yönetimi

37 COCOMO (Constructive Costing Model) devam… 37 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ıkEmek = 3.2 (KLOC) 1.05 x EAF Yarı AyrıkEmek = 3.0 (KLOC) 1.12 x EAF GömülüEmek = 2.8 (KLOC) 1.20 x EAF Belirli bir dizi özelliğin, proje açısından etkileri ayrı ayrı ağırlandırılarak katsayılar ortaya çıkarılır. YZM Yazılım Proje Yönetimi

38 COCOMO (Constructive Costing Model) devam… 38 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. Cost Drivers Ratings very lowlownominalhighvery highextra high Product Attributes RELYRequired Software Reliability0,750,8811,151,4 DATADatabase Size0,9411,081,16 CPLXProduct Complexity0,70,8511,151,31,65 Computer Attributes TIMEExecution Time Constraint11,111,31,66 STORMain Storage Constraint11,061,211,56 VIRTVirtual Machine Volatility0,8711,151,3 TURNComputer Turnaround Time0,8711,051,15 Personnel Attributes ACAPAnalyst Capability1,461,1910,860,71 AEXPApplication Experience1,291,1310,910,82 PCAPProgrammer Capability1,421,1710,860,7 VEXPVirtual Machine Experience1,211,110,9 LEXP Programming Language Experience 1,141,0710,95 Project Attributes MODPModern Programming Practices1,241,110,910,82 TOOLUse of Software Tools1,241,110,910,83 SCEDSchedule Constraints1,231,0811,041,1 YZM Yazılım Proje Yönetimi

39 39 COCOMO – Emek Ayarlama Faktörü Ürün Özellikleri Ürün Özellikleri  RELY: Yazılımın güvenirliği.  DATA: Veritabanının büyüklüğü.  CPLX: Karmaşıklığı. Bilgisayar Özellikleri 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 Yazılım Proje Yönetimi

40 40 COCOMO – Emek Ayarlama Faktörü (devam…) Personel Özellikleri 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 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 Yazılım Proje Yönetimi

41 Örnek: Laboratuar Sistemi için COCOMO ile Emek Kestirimi 41 Cost Drivers RatingsProje lowvery lownominalhighvery highextra highOran Product Attributes RELYRequired Software Reliability0,750,8811,151,4 DATADatabase Size0,9411,081,161 CPLXProduct Complexity0,70,8511,151,31,651 Computer Attributes TIMEExecution Time Constraint11,111,31,661,11 STORMain Storage Constraint11,061,211,561,06 VIRTVirtual Machine Volatility0,8711,151,30,87 TURNComputer Turnaround Time0,8711,051,151 Personnel Attributes ACAPAnalyst Capability1,461,1910,860,711 AEXPApplication Experience1,291,1310,910,821 PCAPProgrammer Capability1,421,1710,860,71 VEXPVirtual Machine Experience1,211,110,91 LEXPProgramming Language Experience1,141,0710,951 Project Attributes MODPModern Programming Practices1,241,110,910,820,91 TOOLUse of Software Tools1,241,110,910,830,91 SCEDSchedule Constraints1,231,0811,041,11,04 Emek Ayarlama Katsayısı:1,23 YZM Yazılım Proje Yönetimi

42 Örnek: Laboratuar Sistemi için COCOMO ile Emek Kestirimi (devam…) 42 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,9 0,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 Yazılım Proje Yönetimi

43 Use-Case Puanı (Use-Case Points - UCP) 43 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. YZM Yazılım Proje Yönetimi

44 Use-Case Puanı (Use-Case Points - UCP) (devam…) 44 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. Use-case analizinin birinci adımı aktörlerin sınıflandırılmasıdır. Aktör TipiAçı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 Öncelikle toplam Düzeltilmemiş Aktör Ağırlığı (Unadjusted Actor Weights - UAW) hesaplanmaktadır. YZM Yazılım Proje Yönetimi

45 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 analizinin ikinci adımı use-case’lerin sınıflandırılmasıdır. 45 Use-Case TipiAçı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 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: Use-case analizinin üçüncü adımı Düzeltilmemiş Use-Case Puanı (Unadjusted Use- Case Points - UUCP) nın hesaplanmasıdır: YZM Yazılım Proje Yönetimi

46 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. Use-case analizinin dördüncü adımı Teknik Karmaşıklık Faktörünün hesaplanmasıdır. 46 Teknik FaktörAçı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 1 T4 Karmaşık Dâhili İşlem 1 T5 Kodun Yeniden Kullanılabilirliği 1 T6 Kurulum Kolaylığı 0.5 T7 Kullanım Kolaylığı 0.5 T8 Taşınabilirlik 2 T9 Değişim Kolaylığı 1 T10 Eş Zamanlılık 1 T11 Özel Güvenlik Özellikleri İçerme 1 T12 Üçüncü Parti Yazılımlar için Doğrudan Erişim Sağlama 1 T13 Kullanıcı Eğitim Gerekliliği 1 YZM Yazılım Proje Yönetimi

47 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. Use-case analizinin beşinci adımı Çevresel Karmaşıklık Faktörünün hesaplanmasıdır. 47 Çevresel FaktörAçıklamasıAğırlık Faktörü E1UML ile Tanışıklık1.5 E2Uygulama Deneyimi0.5 E3Nesneye-Tabanı Deneyim1 E4Lider Analist Yeteneği0.5 E5Motivasyon1 E6Sabit Gereksinimler2 E7Yarı-Zamanlı Çalışanlar E8Zor Programlama Dili Use-case analizinin altıncı adımı Use-Case Puanının hesaplanmasıdır: 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: Use-case analizinin son adımı Emeğin hesaplanmasıdır: YZM Yazılım Proje Yönetimi

48 48 PROJE PROJE İLE İLGİLİ BİLGİLERABC Aktör Sayıları BasitTanımlı bir Uygulama Programlama Arayüzüne (API) sahip başka bir sistemi temsil eder.010 OrtaTCP/IP gibi bir protokol ile haberleşen başka bir sistemi temsil eder.064 KarmaşıkBir web sayfası veya GUI aracılığıyla karşılıklı etkileşen bir kullanıcıyı temsil eder.5117 Düzeltilmemiş Aktör Ağırlıkları (DAA) Use-Case Sayıları 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 ve tasarımı 5 veya daha az sınıf içerir. 802 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 ve tasarım 5 ile 10 arasında sınıf içerir 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 ve tasarımı 11 veya daha fazla sınıf içerir Düzeltilmemiş Use-Case Ağırlıkları (DUCA) Teknik Faktörler T1Dağıtık Sistem154 T2Yanıt veya Çıktı Performans Hedefleri333 T3Son Kullanıcı Verimliliği344 T4Karmaşık Dâhili İşlem331 T5Kodun Yeniden Kullanılabilirliği031 T6Kurulum Kolaylığı010 T7Kullanım Kolaylığı555 T8Taşınabilirlik030 T9Değişim Kolaylığı332 T10Eş Zamanlılık051 T11Özel Güvenlik Özellikleri İçerme051 T12Üçüncü Parti Yazılımlar için Doğrudan Erişim Sağlama331 T13Kullanıcı Eğitim Gerekliliği031 Teknik Karmaşıklık Faktörü (TKF)0,7951,110,855 Çevresel Faktörler E1UML ile Tanışıklık543 E2Uygulama Deneyimi341 E3Nesneye-Tabanı Deneyim553 E4Lider Analist Yeteneği543 E5Motivasyon554 E6Sabit Gereksinimler323 E7Yarı-Zamanlı Çalışanlar000 E8Zor Programlama Dili040 Çevresel Karmaşıklık Faktörü (ÇKF)0,5750,80,815 Üretkenlik Faktörü20 Use-Case Puanı Emek Tahmini (adam-saat) Harcanan Gerçek Emek (adam-saat) Fark (1 – Tahmin / Gerçek)0,370,170,23 YZM Yazılım Proje Yönetimi

49 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. 49 CP 1 ve CP 2 olmak üzere iki ölçüm ortaya atılmıştır. YZM Yazılım Proje Yönetimi

50 Sınıf Puanı (Class Points - CP) (devam…) 1.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). 2.Sınıfların Karmaşıklık Düzeylerinin Belirlenmesi CP 1 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) CP 2 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. 50 YZM Yazılım Proje Yönetimi

51 51 0 – 4 NEM5 – 8 NEM≥ 9 NEM 0 – 1 NSRDüşük Orta 2 – 3 NSRDüşükOrtaYüksek ≥ 4 NSROrtaYüksek CP 1 için Bir Sınıfın Karmaşıklık Düzeyini Değerlendirme CP 2 için Bir Sınıfın Karmaşıklık Düzeyini Değerlendirme 0 – 2 NSR0 – 5 NOA6 – 9 NOA≥ 10 NOA 0 – 4 NEMDüşük Orta 5 – 8 NEMDüşükOrtaYüksek ≥ 9 NEMOrtaYüksek 3 – 4 NSR0 – 4 NOA5 – 8 NOA≥ 9 NOA 0 – 3 NEMDüşük Orta 4 – 7 NEMDüşükOrtaYüksek ≥ 8 NEMOrtaYüksek ≥ 5 NSR0 – 3 NOA4 – 7 NOA≥ 8 NOA 0 – 2 NEMDüşük Orta 3 – 6 NEMDüşükOrtaYüksek ≥ 7 NEMOrtaYüksek (a) (b) (c) Sınıf Puanı (Class Points - CP) (devam…) YZM Yazılım Proje Yönetimi

52 3.Toplam Düzeltilmemiş Sınıf Puanın (Total Unadjusted Class Point – TUCP) Hesaplanması 52 Sistem Bileşen TürüAçıklamaKarmaşıklık DüşükOrtaYüksekToplam PDTProblem Alan Türü… x 3 = …… x 6 = …… x 10 = …… HITİnsan Etkileşim Türü… x 4 = …… x 7 = …… x 12 = …… DMTVeri Yönetim Türü… x 5 = …… x 8 = …… x 13 = …… TMTGörev Yönetim Türü… x 4 = …… x 6 = …… x 9 = …… Toplam Düzeltilmemiş Sınıf Puanı (TUCP): Sınıf Puanı (Class Points - CP) (devam…) YZM Yazılım Proje Yönetimi

53 4.Teknik Karmaşıklık Faktörünün (Technical Complexity Factor – TCF) Hesaplanması 53 Sistem KarakteristiğiEDSistem KarakteristiğiED C1Veri İletişimi…C10Yeniden Kullanılabilirlik… C2Dağıtık Fonksiyonlar…C11Kurulum Kolaylığı… C3Performans…C12İşlem Kolaylığı… C4Konfigürasyon Kullanım Yoğunluğu…C13Çoklu Bölgeler… C5İşlem Oranı…C14Değişim Kolaylığı… C6Online Veri Girişi…C15Kullanıcı Uyarlanabilirliği… C7Son Kullanıcı Verimliliği…C16Hızlı Prototipleme… C8Online Güncelleme…C17Çoklu Kullanıcı Etkileşimi… C9Karmaşı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ı: Sınıf Puanı (Class Points - CP) (devam…) YZM Yazılım Proje Yönetimi

54 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. 54 YZM Yazılım Proje Yönetimi

55 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. 55 YZM Yazılım Proje Yönetimi

56 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. 56 YZM Yazılım Proje Yönetimi

57 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ı 57 YZM Yazılım Proje Yönetimi

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


"YAZILIM PROJE YÖNETİMİ Öğr. Gör. Dr. Emin BORANDAĞ Maltepe Üniversitesi Mühendislik Fakültesi YZM 403." indir ppt

Benzer bir sunumlar


Google Reklamları