Tahmin Teknikleri - Hızlı Kılavuz

Estimation girdi verileri eksik, belirsiz veya kararsız olsa bile bir amaç için kullanılabilen bir değer olan bir tahmin veya yaklaşıklık bulma sürecidir.

Tahmin, belirli bir sistem veya ürün oluşturmak için ne kadar para, çaba, kaynak ve zaman gerekeceğini belirler. Tahmin şuna dayanır -

• Geçmiş Veriler / Geçmiş Deneyim
• Mevcut Belgeler / Bilgi
• Assumptions
• Tanımlanmış Riskler

Yazılım Projesi Tahminindeki dört temel adım şunlardır:

• Geliştirme ürününün boyutunu tahmin edin.
• Çabayı kişi-ay veya kişi-saat cinsinden tahmin edin.
• Takvimi takvim aylarında tahmin edin.
• Proje maliyetini kararlaştırılan para birimi cinsinden tahmin edin.

Tahmin Üzerine Gözlemler

• Tahmin, bir projede tek seferlik bir görev olmak zorunda değildir. Şu tarih aralığında gerçekleşebilir -

  • Bir Proje Edinme.
  • Projenin Planlanması.
  • İhtiyaç ortaya çıktıkça Projenin yürütülmesi.

• Tahmin süreci başlamadan önce proje kapsamı anlaşılmalıdır. Geçmiş Proje Verilerine sahip olmak faydalı olacaktır.

• Proje ölçümleri, niceliksel tahminlerin oluşturulması için tarihsel bir bakış açısı ve değerli girdi sağlayabilir.

• Planlama, teknik yöneticilerin ve yazılım ekibinin sorumluluk ve hesap verebilirliğe yol açtığı için ilk taahhütte bulunmasını gerektirir.

• Geçmiş deneyimler çok yardımcı olabilir.

• Tahminlere ulaşmak ve elde edilen değerleri uzlaştırmak için en az iki tahmin tekniği kullanın. Tahminleri uzlaştırmak hakkında bilgi edinmek için bir sonraki bölümde Ayrıştırma Tekniklerine bakın.

• Planlar yinelemeli olmalı ve zaman geçtikçe ve daha fazla ayrıntı bilindikçe ayarlamalara izin vermelidir.

Genel Proje Tahmin Yaklaşımı

Yaygın olarak kullanılan Proje Tahmin Yaklaşımı, Decomposition Technique. Ayrıştırma teknikleri bir böl ve yönet yaklaşımı alır. Boyut, İş gücü ve Maliyet tahmini, bir Projeyi ana İşlevlere veya ilgili Yazılım Mühendisliği Faaliyetlerine ayırarak aşamalı bir şekilde gerçekleştirilir.

Step 1 - Oluşturulacak yazılımın kapsamını anlayın.

Step 2 - Yazılım boyutu için bir tahmin oluşturun.

• Kapsam ifadesiyle başlayın.

• Yazılımı, her biri ayrı ayrı tahmin edilebilecek işlevlere ayırın.

• Her bir işlevin boyutunu hesaplayın.

• Boyut değerlerini temel üretkenlik metriklerinize uygulayarak iş gücü ve maliyet tahminleri elde edin.

• Tüm proje için genel bir tahmin oluşturmak için işlev tahminlerini birleştirin.

Step 3- Çaba ve maliyete ilişkin bir tahmin oluşturun. Bir projeyi ilgili yazılım mühendisliği faaliyetlerine bölerek çaba ve maliyet tahminlerine ulaşabilirsiniz.

• Projenin tamamlanması için yapılması gereken faaliyetlerin sırasını belirleyin.

• Faaliyetleri ölçülebilen görevlere bölün.

• Her bir görevi tamamlamak için gereken çabayı (kişi saatleri / günleri olarak) tahmin edin.

• Faaliyet için bir tahmin oluşturmak üzere faaliyet görevlerinin efor tahminlerini birleştirin.

• Veritabanından her aktivite için maliyet birimlerini (yani maliyet / birim iş gücü) elde edin.

• Her aktivite için toplam çaba ve maliyeti hesaplayın.

• Tüm proje için genel bir çaba ve maliyet tahmini oluşturmak için her faaliyet için çaba ve maliyet tahminlerini birleştirin.

Step 4- Tahminleri uzlaştırın: Adım 3'ten elde edilen değerleri Adım 2'den elde edilenlerle karşılaştırın. Her iki tahmin grubu da uyuyorsa, sayılarınız oldukça güvenilirdir. Aksi takdirde, çok farklı tahminler ortaya çıkarsa, aşağıdakilere ilişkin daha fazla araştırma yapın:

• Projenin kapsamı yeterince anlaşılmamış veya yanlış yorumlanmıştır.

• İşlev ve / veya etkinlik dökümü doğru değil.

• Tahmin teknikleri için kullanılan geçmiş veriler, uygulama için uygun değildir veya eski veya yanlış uygulanmıştır.

Step 5 - Sapmanın nedenini belirleyin ve ardından tahminleri uzlaştırın.

Tahmin Doğruluğu

Doğruluk, bir şeyin gerçeğe ne kadar yakın olduğunun bir göstergesidir. Ne zaman bir tahmin oluştursanız, herkes sayıların gerçeğe ne kadar yakın olduğunu bilmek ister. Oluşturduğunuz anda sahip olduğunuz veriler göz önüne alındığında, her tahminin mümkün olduğunca doğru olmasını isteyeceksiniz. Ve tabii ki, rakamlara yanlış bir güven duygusu uyandıracak şekilde bir tahmin sunmak istemezsiniz.

Tahminlerin doğruluğunu etkileyen önemli faktörler şunlardır:

• Tüm tahminin girdi verilerinin doğruluğu.

• Herhangi bir tahmin hesaplamasının doğruluğu.

• Modeli kalibre etmek için kullanılan geçmiş veriler veya sektör verilerinin tahmin ettiğiniz projeyle ne kadar yakından eşleştiği.

• Kuruluşunuzun yazılım geliştirme sürecinin öngörülebilirliği.

• Yazılım mühendisliği çabalarını destekleyen hem ürün gereksinimlerinin hem de ortamın istikrarı.

• Gerçek projenin dikkatlice planlanıp planlanmadığı, izlenip kontrol edilmediği ve beklenmedik gecikmelere neden olan büyük sürprizler meydana gelmedi.

Aşağıda, güvenilir tahminlere ulaşmak için bazı yönergeler verilmiştir -

• Zaten tamamlanmış benzer projelere ilişkin temel tahminler.
• Proje maliyeti ve iş gücü tahminleri oluşturmak için nispeten basit ayrıştırma tekniklerini kullanın.
• Yazılım maliyeti ve çaba tahmini için bir veya daha fazla ampirik tahmin modeli kullanın.

Bu bölümdeki Tahmin Yönergeleri kısmına bakın.

Doğruluğu sağlamak için her zaman en az iki teknik kullanarak tahmin yapmanız ve sonuçları karşılaştırmanız önerilir.

Tahmin Sorunları

Çoğu zaman, proje yöneticileri boyutu tahmin etmek için zaman çizelgelerini tahmin etmeye başvurur. Bunun nedeni, üst yönetim veya pazarlama ekibi tarafından belirlenen zaman çizelgeleri olabilir. Bununla birlikte, nedeni ne olursa olsun, eğer bu yapılırsa, daha sonraki bir aşamada kapsam değişikliklerini karşılayacak programları tahmin etmek zor olacaktır.

Tahmin yapılırken belirli varsayımlar yapılabilir. Bazıları tahmin tablolarında varsayımları hala belgelemediğinden, tüm bu varsayımları tahmin tablosuna not etmek önemlidir.

İyi tahminlerin bile içsel varsayımları, riskleri ve belirsizlikleri vardır ve yine de genellikle doğrularmış gibi ele alınırlar.

Tahminleri ifade etmenin en iyi yolu, örneğin, projenin belirli bir tarihte tamamlanacağını veya sabit bir no ile tamamlanacağını belirtmek yerine 5 ila 7 ay süreceğini söylemektir. ay. Belirli bir tarih taahhüt etmeye eşdeğer olduğundan çok dar bir aralıkta taahhütte bulunmaya dikkat edin.

• Belirsizliği, eşlik eden bir olasılık değeri olarak da dahil edebilirsiniz. Örneğin, projenin belirli bir tarihte veya daha önce tamamlanma olasılığı% 90'dır.

• Kuruluşlar doğru proje verilerini toplamaz. Tahminlerin doğruluğu tarihsel verilere bağlı olduğu için bu bir sorun olacaktır.

• Herhangi bir proje için, gerekli işlevselliği dahil etmenize ve kaliteli çıktı üretmenize olanak tanıyan mümkün olan en kısa bir program vardır. Yönetim ve / veya müşteri tarafından bir zamanlama kısıtlaması varsa, teslim edilecek kapsam ve işlevsellik üzerinde görüşebilirsiniz.

• Program aşımlarını önlemek için kapsam sürünmelerini ele alma konusunda müşteriyle anlaşın.

• Nihai tahminde beklenmedik durumları yerleştirmedeki başarısızlık sorunlara neden olur. Örneğin, toplantılar, organizasyon etkinlikleri.

• Kaynak kullanımının% 80'den az olduğu düşünülmelidir. Bunun nedeni, kaynakların zamanlarının yalnızca% 80'i için verimli olacağıdır. Kaynakları% 80'den fazla kullanımla atarsanız, kaymalar olabilir.

Tahmin Yönergeleri

Bir projeyi tahmin ederken aşağıdaki yönergeleri akılda tutmak gerekir -

• Tahmin sırasında başkalarının deneyimlerini sorun. Ayrıca, kendi deneyimlerinizi de göreve koyun.

• Kaynakların zamanlarının yalnızca yüzde 80'inde verimli olacağını varsayın. Bu nedenle, tahmin sırasında kaynak kullanımını% 80'den az olarak alın.

• Birden çok proje üzerinde çalışan kaynakların, aralarında geçiş yaparken kaybedilen zaman nedeniyle görevleri tamamlaması daha uzun sürer.

• Herhangi bir tahmine yönetim süresini dahil edin.

• Problem çözme, toplantılar ve diğer beklenmedik olaylar için daima beklenmedik durum oluşturun.

• Uygun bir proje tahmini yapmak için yeterli zaman ayırın. Aceleye getirilmiş tahminler yanlış, yüksek riskli tahminlerdir. Büyük geliştirme projeleri için tahmin adımı gerçekten mini bir proje olarak görülmelidir.

• Mümkünse, kuruluşunuzun benzer geçmiş projelerinden belgelenmiş verileri kullanın. En doğru tahminle sonuçlanacaktır. Kuruluşunuz geçmiş verileri saklamadıysa, şimdi toplamaya başlamak için iyi bir zaman.

• İşi yapacak kişiler dışındaki kişiler tarafından hazırlanan tahminler daha az doğru olacağından geliştiriciye dayalı tahminler kullanın.

• Birkaç farklı tahmin tekniğini tahmin etmek ve kullanmak için birkaç farklı kişi kullanın.

• Tahminleri uzlaştırın. Tahminler arasındaki yakınsamayı veya yayılmayı gözlemleyin. Yakınsama, iyi bir tahmininiz olduğu anlamına gelir. Geniş bant-Delphi tekniği, bir grup insanı kullanarak tahminleri toplamak ve tartışmak için kullanılabilir; amaç, doğru, tarafsız bir tahmin üretmektir.

• Projeyi yaşam döngüsü boyunca birkaç kez yeniden tahmin edin.

Bir Function Point(FP), bir bilgi sisteminin (ürün olarak) kullanıcıya sağladığı iş işlevselliği miktarını ifade eden bir ölçü birimidir. FP'ler yazılım boyutunu ölçer. İşlevsel boyutlandırma için bir endüstri standardı olarak geniş çapta kabul edilmektedir.

FP'ye dayalı boyutlandırma yazılımı için, birçok tanınmış standart ve / veya genel şartname ortaya çıkmıştır. 2013 itibariyle, bunlar -

ISO Standartları

• COSMIC- ISO / IEC 19761: 2011 Yazılım mühendisliği. İşlevsel bir boyut ölçüm yöntemi.

• FiSMA - ISO / IEC 29881: 2008 Bilgi teknolojisi - Yazılım ve sistem mühendisliği - FiSMA 1.1 fonksiyonel boyut ölçüm yöntemi.

• IFPUG - ISO / IEC 20926: 2009 Yazılım ve sistem mühendisliği - Yazılım ölçümü - IFPUG fonksiyonel boyut ölçüm yöntemi.

• Mark-II - ISO / IEC 20968: 2002 Yazılım mühendisliği - Ml II Fonksiyon Noktası Analizi - Sayma Uygulamaları Kılavuzu.

• NESMA - ISO / IEC 24570: 2005 Yazılım mühendisliği - NESMA işlev boyutu ölçüm yöntemi sürüm 2.1 - İşlev Noktası Analizi uygulaması için tanımlar ve sayma yönergeleri.

Otomatik Fonksiyon Noktası için Nesne Yönetim Grubu Spesifikasyonu

Açık bir üyelik ve kar amacı gütmeyen bilgisayar endüstrisi standartları konsorsiyumu olan Object Management Group (OMG), BT Yazılım Kalitesi Konsorsiyumu tarafından yönetilen Otomatik İşlev Noktası (AFP) spesifikasyonunu benimsemiştir. International Function Point User Group (IFPUG) yönergelerine göre FP sayımını otomatikleştirmek için bir standart sağlar.

Function Point Analysis (FPA) techniqueYazılımın içerdiği işlevleri, yazılım kullanıcıları için anlamlı terimlerle ifade eder. FP'ler, gereksinim özelliklerine göre geliştirilmekte olan işlevlerin sayısını dikkate alır.

Function Points (FP) CountingUluslararası İşlev Noktası Kullanıcıları Grubu (IFPUG) tarafından tanımlanan standart bir dizi kural, süreç ve yönergeye tabidir. Bunlar Sayım Uygulamaları El Kitabında (CPM) yayınlanmıştır.

Fonksiyon Noktası Analizinin Tarihçesi

Function Points kavramı, 1979'da IBM'den Alan Albrecht tarafından tanıtıldı. 1984'te, Albrecht yöntemi geliştirdi. İlk İşlev Noktası Yönergeleri 1984'te yayınlandı. Uluslararası İşlev Noktası Kullanıcıları Grubu (IFPUG), İşlev Noktası Analizi metrik yazılımı kullanıcılarının ABD merkezli dünya çapında bir organizasyonudur. International Function Point Users Group (IFPUG)1986'da kurulmuş, kâr amacı gütmeyen, üye tarafından yönetilen bir kuruluştur. IFPUG, IFPUG'nin fonksiyonel boyut ölçümü (FSM) yöntemini uygulamak için tanımları, kuralları ve adımları belirleyen ISO standardı 20296: 2009'da tanımlandığı gibi Fonksiyon Noktası Analizine (FPA) sahiptir. IFPUG, Fonksiyon Noktası Sayma Uygulamaları Kılavuzunu (CPM) korur. CPM 2.0 1987'de piyasaya sürüldü ve o zamandan beri birkaç yineleme yapıldı. CPM Sürüm 4.3 2010 yılındaydı.

Entegre ISO editoryal revizyonları ile CPM 4.3.1 Sürümü 2010 yılında çıkmıştır. CPM 4.3.1'in bir parçası olan ISO Standardı (IFPUG FSM) - Fonksiyonel Boyut Ölçümü, sunduğu işlevsellik açısından yazılımı ölçmek için bir tekniktir. CPM, ISO / IEC 14143-1 Bilgi Teknolojisi - Yazılım Ölçümü kapsamında uluslararası olarak onaylanmış bir standarttır.

Temel Süreç (EP)

Temel Süreç, işlevsel kullanıcı gereksiniminin en küçük birimidir -

• Kullanıcı için anlamlıdır.
• Tam bir işlem oluşturur.
• Bağımsızdır ve uygulamanın işini tutarlı bir durumda sayılır.

Fonksiyonlar

İki tür işlev vardır -

• Veri Fonksiyonları
• İşlem İşlevleri

Veri Fonksiyonları

İki tür veri işlevi vardır -

• Dahili Mantıksal Dosyalar
• Harici Arayüz Dosyaları

Veri Fonksiyonları, sistemi etkileyen iç ve dış kaynaklardan oluşur.

Internal Logical Files

Dahili Mantıksal Dosya (ILF), tamamen uygulama sınırı içinde yer alan, mantıksal olarak ilişkili verilerin veya kontrol bilgilerinin kullanıcı tarafından tanımlanabilen bir grubudur. Bir ILF'nin birincil amacı, sayılmakta olan uygulamanın bir veya daha fazla temel süreci boyunca tutulan verileri tutmaktır. Bir ILF, dahili olarak korunduğu, bazı mantıksal yapıya sahip olduğu ve bir dosyada depolandığı anlamına gelir. (Şekil 1'e bakın)

External Interface Files

Harici Arayüz Dosyası (EIF), uygulama tarafından yalnızca referans amacıyla kullanılan, kullanıcı tarafından tanımlanabilir mantıksal olarak ilişkili veriler veya kontrol bilgileri grubudur. Veriler tamamen uygulama sınırının dışında bulunur ve başka bir uygulama tarafından bir ILF'de tutulur. Bir EIF, harici olarak tutulduğu anlamına gelir, dosyadan verileri almak için bir arayüz geliştirilmelidir. (Şekil 1'e bakın)

İşlem İşlevleri

Üç tür işlem işlevi vardır.

• Harici Girişler
• Harici Çıkışlar
• Harici Sorgular

İşlem fonksiyonları, kullanıcı, harici uygulamalar ve ölçülen uygulama arasında değiş tokuş edilen süreçlerden oluşur.

External Inputs

Harici Giriş (EI), Verilerin uygulamaya sınırın dışından içeriye "girdiği" bir işlem işlevidir. Bu veriler uygulamanın dışından geliyor.

• Veriler, bir veri giriş ekranından veya başka bir uygulamadan gelebilir.
• Bir EI, bir uygulamanın bilgiyi nasıl elde ettiğidir.
• Veriler, kontrol bilgileri veya iş bilgileri olabilir.
• Veriler, bir veya daha fazla Dahili Mantıksal Dosyayı korumak için kullanılabilir.
• Veriler kontrol bilgisiyse, Dahili Mantıksal Dosyayı güncellemesi gerekmez. (Şekil 1'e bakın)

External Outputs

Harici Çıktı (EO), verilerin sistemden "çıktığı" bir işlem işlevidir. Ek olarak, bir EO bir ILF'yi güncelleyebilir. Veriler, diğer uygulamalara gönderilen raporlar veya çıktı dosyaları oluşturur. (Şekil 1'e bakın)

External Inquiries

Harici Sorgulama (EQ), veri alımıyla sonuçlanan hem giriş hem de çıkış bileşenlerine sahip bir işlem işlevidir. (Şekil 1'e bakın)

RET'lerin, DET'lerin, FTR'lerin tanımı

Kayıt Öğesi Türü

Bir Kayıt Öğesi Türü (RET), bir ILF veya bir EIF içindeki en büyük kullanıcı tanımlı öğe alt grubudur. Tanımlanmalarına yardımcı olması için mantıksal veri gruplarına bakmak en iyisidir.

Veri Öğesi Türü

Veri Öğesi Tipi (DET), bir FTR içindeki veri alt grubudur. Benzersizdirler ve kullanıcı tarafından tanımlanabilirler.

Başvurulan Dosya Türü

Referans Verilen Dosya Tipi (FTR), başvurulan EI, EO veya EQ içindeki en büyük kullanıcı tanımlı alt gruptur.

İşlem fonksiyonları EI, EO, EQ, aşağıdaki sayma kurallarını içeren FTR'ler ve DET'ler sayılarak ölçülür. Benzer şekilde, ILF ve EIF veri fonksiyonları, aşağıdaki sayma kurallarını içerdikleri DET'ler ve RET'ler sayılarak ölçülür. İşlem fonksiyonlarının ve veri fonksiyonlarının ölçüleri, fonksiyonel boyut veya fonksiyon noktaları ile sonuçlanan FP sayımında kullanılır.

FP Sayma Süreci aşağıdaki adımları içerir -

• Step 1 - Sayım türünü belirleyin.

• Step 2 - Sayımın sınırını belirleyin.

• Step 3 - Kullanıcı tarafından istenen her Temel Süreci (EP) tanımlayın.

• Step 4 - Benzersiz EP'leri belirleyin.

• Step 5 - Veri fonksiyonlarını ölçün.

• Step 6 - İşlem işlevlerini ölçün.

• Step 7 - İşlevsel boyutu hesaplayın (düzeltilmemiş işlev noktası sayısı).

• Step 8 - Değer Ayarlama Faktörünü (VAF) belirleyin.

• Step 9 - Ayarlanan işlev noktası sayısını hesaplayın.

Note- Genel Sistem Özellikleri (GSC'ler) CPM 4.3.1'de isteğe bağlı hale getirilmiş ve Ek'e taşınmıştır. Bu nedenle Adım 8 ve Adım 9 atlanabilir.

Adım 1: Sayım Türünü Belirleyin

Üç tür işlev noktası sayısı vardır -

• Geliştirme İşlevi Puan Sayısı
• Uygulama Fonksiyonu Puan Sayısı
• Geliştirme İşlevi Puan Sayısı

Geliştirme İşlevi Puan Sayısı

Fonksiyon puanları, bir geliştirme projesinin gereksinimden uygulama aşamasına kadar tüm aşamalarında sayılabilir. Bu tür bir sayım, yeni geliştirme çalışmasıyla ilişkilidir ve dönüşüm çabasını destekleyen geçici çözüm olarak gerekli olabilecek prototipleri içerebilir. Bu tür bir sayıma temel fonksiyon noktası sayısı denir.

Uygulama Fonksiyonu Puan Sayısı

Uygulama sayıları, sunulan işlev noktaları olarak hesaplanır ve herhangi bir dönüştürme çabası (prototipler veya geçici çözümler) ve var olabilecek mevcut işlevleri hariç tutar.

Geliştirme İşlevi Puan Sayısı

Üretimden sonra yazılımda değişiklik yapıldığında, bunlar geliştirme olarak kabul edilir. Bu tür geliştirme projelerini boyutlandırmak için, İşlev Puanı Sayısı Uygulamaya Eklenir, Değiştirilir veya Silinir.

Adım 2: Sayımın Sınırını Belirleyin

Sınır, ölçülen uygulama ile harici uygulamalar veya kullanıcı alanı arasındaki sınırı belirtir. (Şekil 1'e bakın)

Sınırı belirlemek için anlayın -

• Fonksiyon puan sayımının amacı
• Ölçülen uygulamanın kapsamı
• Hangi uygulamalar hangi verileri nasıl ve korur?
• Uygulamaları destekleyen iş alanları

Adım 3: Kullanıcı Tarafından Gereken Her Temel Süreci Tanımlayın

İşlevsel kullanıcı gereksinimlerini, aşağıdaki kriterlerin tümünü karşılayan en küçük faaliyet birimine oluşturun ve / veya ayrıştırın -

• Kullanıcı için anlamlıdır.
• Tam bir işlem oluşturur.
• Kendi kendine yeten.
• Uygulamanın işini tutarlı bir durumda sayılır.

Örneğin, İşlevsel Kullanıcı Gereksinimi - "Çalışan bilgilerini koru", çalışan ekleme, çalışanı değiştirme, çalışanı silme ve çalışan hakkında bilgi alma gibi daha küçük faaliyetlere ayrıştırılabilir.

Bu şekilde tanımlanan her bir faaliyet birimi, bir Temel Süreçtir (EP).

Adım 4: Benzersiz Temel Süreçleri Belirleyin

Önceden tanımlanmış iki EP'yi karşılaştırarak, bunları bir EP (aynı EP) olarak sayın -

• Aynı DET kümesini gerektirir.
• Aynı FTR setini gerektirir.
• EP'yi tamamlamak için aynı işleme mantığını gerektirir.

Birden çok işleme mantığı biçimine sahip bir EP'yi birden çok Eps'ye bölmeyin.

Örneğin, 'Çalışan Ekle'yi bir EP olarak tanımladıysanız, bir çalışanın bakmakla yükümlü olduğu veya olmayabileceği gerçeğini hesaba katmak için bu EP'ye bölünmemelidir. EP hala "Çalışan Ekle" ve bağımlıları hesaba katmak için işleme mantığında ve DET'larda farklılıklar var.

Adım 5: Veri İşlevlerini Ölçün

Her veri işlevini bir ILF veya EIF olarak sınıflandırın.

Bir veri işlevi, bir - olarak sınıflandırılır

• Ölçülen uygulama tarafından korunuyorsa Dahili Mantıksal Dosya (ILF).

• Harici Arayüz Dosyası (EIF) referans veriliyorsa, ancak ölçülen uygulama tarafından tutulmuyorsa.

ILF'ler ve EIF'ler iş verilerini, kontrol verilerini ve kurallara dayalı verileri içerebilir. Örneğin, telefonla anahtarlama üç türün tamamından yapılır - iş verileri, kural verileri ve kontrol verileri. İş verileri asıl aramadır. Kural verileri, aramanın ağ üzerinden nasıl yönlendirilmesi gerektiğidir ve kontrol verileri, anahtarların birbirleriyle nasıl iletişim kurduğudur.

ILF'leri ve EIF'leri saymak için aşağıdaki belgeleri göz önünde bulundurun -

• Önerilen sistem için hedefler ve kısıtlamalar.
• Böyle bir sistem varsa, mevcut sisteme ilişkin belgeler.
• Kullanıcıların algılanan hedeflerinin, sorunlarının ve ihtiyaçlarının dokümantasyonu.
• Veri modelleri.

Adım 5.1: Her Veri Fonksiyonu için DET'leri Sayma

ILF / EIF için DET'leri saymak üzere aşağıdaki kuralları uygulayın -

• Bir EP'nin yürütülmesi yoluyla ILF veya EIF'de tutulan veya bunlardan alınan her benzersiz kullanıcı tanımlanabilir, tekrarlanmayan alan için bir DET sayın.

• Yalnızca iki veya daha fazla uygulama aynı veri işlevini koruduğunda ve / veya referans verdiğinde ölçülen uygulama tarafından kullanılan DET'leri sayın.

• Kullanıcının başka bir ILF veya EIF ile ilişki kurması için gerekli olan her özellik için bir DET sayın.

• Gruplandırılıp tek bir DET olarak mı yoksa birden çok DET olarak mı sayıldıklarını belirlemek için ilgili öznitelikleri inceleyin. Gruplama, EP'lerin uygulama içindeki özellikleri nasıl kullandığına bağlı olacaktır.

Adım 5.2: Her Veri Fonksiyonu için RET'leri Sayma

ILF / EIF için RET'leri saymak üzere aşağıdaki kuralları uygulayın -

• Her veri işlevi için bir RET sayın.
• Aşağıdaki ek mantıksal DET alt gruplarının her biri için bir ek RET sayın.
  • Anahtar olmayan özniteliklere sahip ilişkilendirilebilir varlık.
  • Alt tür (ilk alt tür dışında).
  • Zorunlu 1: 1 dışındaki bir ilişkide atıfta bulunan varlık.

Adım 5.3: Her Veri İşlevi için İşlevsel Karmaşıklığı Belirleyin

RETS	Veri Öğesi Türleri (DET'ler)
	1-19	20-50	>50
1	L	L	Bir
2 ila 5	L	Bir	H
> 5	Bir	H	H

Fonksiyonel Karmaşıklık: L = Düşük; A = Ortalama; H = Yüksek

Adım 5.4: Her Veri Fonksiyonu için Fonksiyonel Boyutu Ölçün

Fonksiyonel Karmaşıklık	ILF için FP Sayısı	EIF için FP Sayısı
Düşük	7	5
Ortalama	10	7
Yüksek	15	10

Adım 6: İşlemsel İşlevleri Ölçün

İşlem işlevlerini ölçmek için aşağıdaki gerekli adımlar şunlardır:

Adım 6.1: Her bir İşlemsel Fonksiyonu Sınıflandırın

İşlem fonksiyonları, Harici Girdi, Harici Çıktı veya Harici Sorgulama olarak sınıflandırılmalıdır.

Harici Giriş

Harici Giriş (EI), sınırın dışından gelen verileri veya kontrol bilgilerini işleyen Temel bir İşlemdir. Bir EI'nin birincil amacı, bir veya daha fazla ILF'yi sürdürmek ve / veya sistemin davranışını değiştirmektir.

Aşağıdaki kuralların tümü uygulanmalıdır -

• Veriler veya kontrol bilgileri, uygulama sınırı dışından alınır.

• Sınıra giren veriler sistemin davranışını değiştiren kontrol bilgisi değilse en az bir ILF tutulur.

• Tanımlanan EP için, üç ifadeden biri geçerli olmalıdır -

  • İşleme mantığı, uygulama için diğer EI'ler tarafından gerçekleştirilen işleme mantığından benzersizdir.

  • Tanımlanan veri öğeleri kümesi, uygulamadaki diğer EI'ler için tanımlanan setlerden farklıdır.

  • Başvurulan ILF'ler veya EIF'ler, uygulamadaki diğer EI'ler tarafından referans verilen dosyalardan farklıdır.

Harici Çıkış

Harici Çıktı (EO), veri veya kontrol bilgilerini uygulamanın sınırları dışına gönderen Temel bir İşlemdir. EO, harici bir sorgulamanın ötesinde ek işlemler içerir.

Bir EO'nun birincil amacı, bir kullanıcıya veri veya kontrol bilgilerinin alınması dışında veya bunlara ek olarak işleme mantığı yoluyla bilgi sunmaktır.

İşleme mantığı olmalıdır -

• En az bir matematiksel formül veya hesaplama içerir.
• Türetilmiş veriler oluşturun.
• Bir veya daha fazla ILF'yi koruyun.
• Sistemin davranışını değiştirin.

Aşağıdaki kuralların tümü uygulanmalıdır -

• Uygulama sınırının dışındaki verileri veya kontrol bilgilerini gönderir.
• Tanımlanan EP için, üç ifadeden biri geçerli olmalıdır -
  • İşleme mantığı, uygulama için diğer EO'lar tarafından gerçekleştirilen işleme mantığından benzersizdir.
  • Tanımlanan veri öğeleri kümesi, uygulamadaki diğer EO'lardan farklıdır.
  • Başvurulan ILF'ler veya EIF'ler, uygulamada diğer EO'lar tarafından referans verilen dosyalardan farklıdır.

Ek olarak, aşağıdaki kurallardan biri uygulanmalıdır -

• İşleme mantığı en az bir matematiksel formül veya hesaplama içerir.
• İşleme mantığı en az bir ILF'yi korur.
• İşleme mantığı, sistemin davranışını değiştirir.

Harici Sorgulama

Harici Sorgulama (EQ), verileri veya kontrol bilgilerini sınırın dışına gönderen Temel bir İşlemdir. Bir EQ'nun birincil amacı, veri veya kontrol bilgisinin alınması yoluyla kullanıcıya bilgi sunmaktır.

İşleme mantığı hiçbir matematiksel formül veya hesaplama içermez ve türetilmiş veri oluşturmaz. İşleme sırasında hiçbir ILF sürdürülmez ve sistemin davranışı değiştirilmez.

Aşağıdaki kuralların tümü uygulanmalıdır -

• Uygulama sınırının dışındaki verileri veya kontrol bilgilerini gönderir.
• Tanımlanan EP için, üç ifadeden biri geçerli olmalıdır -
  • İşleme mantığı, uygulama için diğer EQ'lar tarafından gerçekleştirilen işleme mantığından benzersizdir.
  • Tanımlanan veri öğeleri kümesi, uygulamadaki diğer EQ'lardan farklıdır.
  • Başvurulan ILF'ler veya EIF'ler, uygulamada diğer EQ'ların referans verdiği dosyalardan farklıdır.

Ek olarak, aşağıdaki kuralların tümü geçerli olmalıdır -

• İşleme mantığı, bir ILF veya EIF'den verileri veya kontrol bilgilerini alır.
• İşleme mantığı matematiksel formül veya hesaplama içermez.
• İşleme mantığı, sistemin davranışını değiştirmez.
• İşleme mantığı bir ILF'yi korumaz.

Adım 6.2: Her İşlem Fonksiyonu için DET'leri Sayma

EI'ler için DET'leri saymak üzere aşağıdaki Kuralları uygulayın -

• Sınırı geçen (giren ve / veya çıkan) her şeyi gözden geçirin.

• İşlem işlevinin işlenmesi sırasında sınırı geçen (giren ve / veya çıkan) her benzersiz kullanıcı tanımlanabilir, tekrarlanmayan öznitelik için bir DET sayın.

• Birden fazla mesaj olsa bile bir uygulama yanıt mesajı gönderme yeteneği için işlem işlevi başına yalnızca bir DET sayın.

• Birden çok yöntem olsa bile eylemi başlatma yeteneği için işlem işlevi başına yalnızca bir DET sayın.

• Aşağıdaki öğeleri DET olarak saymayın -

  • Bir işlem işlevi tarafından sınır içinde üretilen ve sınırdan çıkmadan bir ILF'ye kaydedilen öznitelikler.

  • Rapor başlıkları, ekran veya panel tanımlayıcıları, sütun başlıkları ve öznitelik başlıkları gibi değişmez bilgiler.

  • Uygulama, tarih ve saat özellikleri gibi damgalar oluşturdu.

  • Sayfalama değişkenleri, sayfa numaraları ve konumlandırma bilgileri, örneğin '211'in 37 ila 54. satırları'.

  • Bir liste içinde "önceki", "sonraki", "ilk", "son" ve bunların grafik eşdeğerlerini kullanarak gezinme yeteneği gibi navigasyon yardımcıları.

EO'lar / EQ'lar için DET'leri saymak için aşağıdaki kuralları uygulayın -

• Sınırı geçen (giren ve / veya çıkan) her şeyi gözden geçirin.

• İşlem işlevinin işlenmesi sırasında sınırı geçen (giren ve / veya çıkan) her benzersiz kullanıcı tanımlanabilir, tekrarlanmayan öznitelik için bir DET sayın.

• Birden fazla mesaj olsa bile bir uygulama yanıt mesajı gönderme yeteneği için işlem işlevi başına yalnızca bir DET sayın.

• Birden çok yöntem olsa bile eylemi başlatma yeteneği için işlem işlevi başına yalnızca bir DET sayın.

• Aşağıdaki öğeleri DET olarak saymayın -

  • Sınırı geçmeden sınır içinde üretilen özellikler.

  • Rapor başlıkları, ekran veya panel tanımlayıcıları, sütun başlıkları ve öznitelik başlıkları gibi değişmez bilgiler.

  • Uygulama, tarih ve saat özellikleri gibi damgalar oluşturdu.

  • Sayfalama değişkenleri, sayfa numaraları ve konumlandırma bilgileri, örneğin '211'in 37 ila 54. satırları'.

  • Bir liste içinde "önceki", "sonraki", "ilk", "son" ve bunların grafik eşdeğerlerini kullanarak gezinme yeteneği gibi navigasyon yardımcıları.

Adım 6.3: Her İşlem Fonksiyonu için FTR'leri Sayma

EI'ler için FTR'leri saymak için aşağıdaki kuralları uygulayın -

• Tutulan her ILF için bir FTR sayın.
• EI'nin işlenmesi sırasında okunan her ILF veya EIF için bir FTR sayın.
• Hem tutulan hem de okunan her ILF için yalnızca bir FTR sayın.

EO / EQ'lar için FTR'leri saymak için aşağıdaki kuralı uygulayın -

• EP'nin işlenmesi sırasında okunan her ILF veya EIF için bir FTR sayın.

Ek olarak, EO'lar için FTR'leri saymak için aşağıdaki kuralları uygulayın -

• EP'nin işlenmesi sırasında tutulan her ILF için bir FTR sayın.
• EP tarafından hem korunan hem de okunan her ILF için yalnızca bir FTR sayın.

Adım 6.4: Her İşlemsel İşlev için İşlevsel Karmaşıklığı Belirleyin

FTR'ler	Veri Öğesi Türleri (DET'ler)
	1-4	5-15	>=16
0-1	L	L	Bir
2	L	Bir	H
> = 3	Bir	H	H

Fonksiyonel Karmaşıklık: L = Düşük; A = Ortalama; H = Yüksek

EQ'nun minimum 1 FTR'ye sahip olması gerekmesi dışında, her EO / EQ için işlevsel karmaşıklığı belirleyin -

EQ minimum 1 FTR'ye sahip olmalıdır FTR'ler	Veri Öğesi Türleri (DET'ler)
	1-4	5-15	> = 16
0-1	L	L	Bir
2	L	Bir	H
> = 3	Bir	H	H

Fonksiyonel Karmaşıklık: L = Düşük; A = Ortalama; H = Yüksek

Adım 6.5: Her İşlemsel İşlev için İşlevsel Boyutu Ölçün

Her bir EI için işlevsel boyutu işlevsel karmaşıklığından ölçün.

Karmaşıklık	FP Sayısı
Düşük	3
Ortalama	4
Yüksek	6

Her EO / EQ için işlevsel boyutu işlevsel karmaşıklığından ölçün.

Karmaşıklık	EO için FP Sayısı	EQ için FP Sayısı
Düşük	4	3
Ortalama	5	4
Yüksek	6	6

Adım 7: Fonksiyonel Boyutu Hesaplayın (Ayarlanmamış Fonksiyon Nokta Sayısı)

Fonksiyonel boyutu hesaplamak için aşağıda verilen adımları takip etmelisiniz -

Adım 7.1

1. Adımda bulduklarınızı hatırlayın. Sayım türünü belirleyin.

Adım 7.2

Türe göre işlevsel boyutu veya işlev noktası sayısını hesaplayın.

• Geliştirme işlevi puan sayımı için Adım 7.3'e gidin.
• Uygulama işlevi puan sayımı için Adım 7.4'e gidin.
• Geliştirme işlevi puan sayımı için Adım 7.5'e gidin.

Adım 7.3

Development Function Point Count, iki işlevsellik bileşeninden oluşur -

• Proje için kullanıcı gereksinimlerine dahil edilen uygulama işlevselliği.

• Proje için kullanıcı gereksinimlerine dahil edilen dönüştürme işlevi. Dönüştürme işlevi, yalnızca kurulumda verileri dönüştürmek ve / veya özel dönüştürme raporları gibi diğer kullanıcı tanımlı dönüştürme gereksinimlerini sağlamak için sağlanan işlevlerden oluşur. Örneğin, mevcut bir uygulama yeni bir sistemle değiştirilebilir.

DFP = ADD + CFP

Nerede,

DFP = Geliştirme Fonksiyonu Puan Sayısı

ADD = Geliştirme projesi tarafından kullanıcıya sunulan işlevlerin boyutu

CFP = Dönüştürme işlevinin boyutu

ADD = FP Sayısı (ILF'ler) + FP Sayısı (EIF'ler) + FP Sayısı (EI'ler) + FP Sayısı (EO'lar) + FP Sayısı (EQ'lar)

CFP = FP Sayısı (ILF'ler) + FP Sayısı (EIF'ler) + FP Sayısı (EI'ler) + FP Sayısı (EO'lar) + FP Sayısı (EQ'lar)

Adım 7.4

Uygulama Fonksiyonu Puan Sayısını Hesaplayın

AFP = ADD

Nerede,

AFP = Uygulama Fonksiyonu Puan Sayısı

ADD = Geliştirme projesi tarafından kullanıcıya teslim edilen işlevlerin boyutu (herhangi bir dönüştürme işlevinin boyutu hariç) veya uygulama sayıldığında var olan işlevler.

ADD = FP Sayısı (ILF'ler) + FP Sayısı (EIF'ler) + FP Sayısı (EI'ler) + FP Sayısı (EO'lar) + FP Sayısı (EQ'lar)

Adım 7.5

Geliştirme İşlevi Nokta Sayısı, aşağıdaki dört işlevsellik bileşenini dikkate alır -

• Uygulamaya eklenen işlevsellik.
• Uygulamada değiştirilen işlevsellik.
• Dönüştürme işlevi.
• Uygulamadan silinen işlevsellik.

EFP = ADD + CHGA + CFP + DEL

Nerede,

EFP = Geliştirme Fonksiyonu Puan Sayımı

ADD = Geliştirme projesi tarafından eklenen işlevlerin boyutu

CHGA = Geliştirme projesi tarafından değiştirilen işlevlerin boyutu

CFP = Dönüştürme işlevinin boyutu

DEL = Geliştirme projesi tarafından silinen işlevlerin boyutu

ADD = FP Sayısı (ILF'ler) + FP Sayısı (EIF'ler) + FP Sayısı (EI'ler) + FP Sayısı (EO'lar) + FP Sayısı (EQ'lar)

CHGA = FP Sayısı (ILF'ler) + FP Sayısı (EIF'ler) + FP Sayısı (EI'ler) + FP Sayısı (EO'lar) + FP Sayısı (EQ'lar)

CFP = FP Sayısı (ILF'ler) + FP Sayısı (EIF'ler) + FP Sayısı (EI'ler) + FP Sayısı (EO'lar) + FP Sayısı (EQ'lar)

DEL = FP Sayısı (ILF'ler) + FP Sayısı (EIF'ler) + FP COUNT (EI'ler) + FP Sayısı (EO'lar) + FP Sayısı (EQ'lar)

Adım 8: Değer Ayarlama Faktörünü Belirleyin

GSC'ler CPM 4.3.1'de isteğe bağlı hale getirilmiş ve Ek'e taşınmıştır. Bu nedenle Adım 8 ve Adım 9 atlanabilir.

Değer Ayarlama Faktörü (VAF), sayılmakta olan uygulamanın genel işlevselliğini derecelendiren 14 GSC'ye dayanmaktadır. GSC'ler, teknolojiden bağımsız kullanıcı iş kısıtlamalarıdır. Her özellik, etki derecesini belirlemek için ilişkili açıklamalara sahiptir.

Genel Sistem Karakteristiği	Kısa açıklama
Veri iletişimleri	Uygulama veya sistem ile bilgi aktarımı veya değişimine yardımcı olacak kaç iletişim tesisi var?
Dağıtık Veri İşleme	Dağıtılmış veriler ve işleme fonksiyonları nasıl ele alınır?
Verim	Kullanıcı yanıt süresine veya işleme hızına mı ihtiyaç duydu?
Yoğun Kullanılan Yapılandırma	Uygulamanın yürütüleceği mevcut donanım platformu ne kadar yoğun bir şekilde kullanılıyor?
İşlem Oranı	İşlemler günlük, haftalık, aylık vb. Ne sıklıkla yapılır?
Çevrimiçi Veri Girişi	Bilgilerin yüzde kaçı çevrimiçi olarak giriliyor?
Son kullanıcı Verimliliği	Uygulama, son kullanıcı verimliliği için mi tasarlanmış?
Çevrimiçi Güncelleme	Çevrimiçi işlemle kaç ILF güncellenir?
Karmaşık İşleme	Uygulama, kapsamlı mantıksal veya matematiksel işleme sahip mi?
Tekrar Kullanılabilirlik	Uygulama bir veya daha fazla kullanıcının ihtiyacını karşılayacak şekilde mi geliştirildi?
Kurulum Kolaylığı	Dönüştürme ve kurulum ne kadar zor?
Operasyonel Kolaylık	Başlatma, yedekleme ve kurtarma prosedürleri ne kadar etkili ve / veya otomatiktir?
Birden Çok Site	Uygulama, birden çok kuruluş için birden çok siteye kurulmak üzere özel olarak tasarlanmış, geliştirilmiş ve desteklenmiş miydi?
Değişimi Kolaylaştırın	Uygulama, değişimi kolaylaştırmak için özel olarak tasarlanmış, geliştirilmiş ve desteklenmiş midir?

Etki derecesi aralığı, sıfırdan beşe, etki yoktan güçlü etkiye kadar değişen bir ölçekte.

Değerlendirme	Etki Derecesi
0	Mevcut değil veya etkisi yok
1	Tesadüfi etki
2	Orta düzeyde etki
3	Ortalama etki
4	Önemli etki
5	Boyunca güçlü etki

14 GSC'nin her biri için etki derecesini belirleyin.

Bu şekilde elde edilen 14 GSC değerlerinin toplamı, Toplam Etki Derecesi (TDI) olarak adlandırılır.

TDI = ∑¹⁴ Degrees of Influence

Ardından, Değer Ayarlama Faktörünü (VAF) şu şekilde hesaplayın:

VAF = (TDI × 0.01) + 0.65

Her GSC 0 ila 5 arasında değişebilir, TDI (0 × 14) ila (5 × 14) arasında değişebilir, yani 0 (tüm GSC'ler düşük olduğunda) ila 70 (tüm GSC'ler yüksek olduğunda) yani 0 ≤ TDI ≤ 70 olabilir. Dolayısıyla, VAF 0.65 (tüm GSC'ler düşük olduğunda) ile 1.35 (tüm GSC'ler yüksek olduğunda), yani 0.65 ≤ VAF ≤ 1.35 aralığında değişebilir.

Adım 9: Ayarlanmış Fonksiyon Nokta Sayısını Hesaplayın

VAF'yi kullanan FPA yaklaşımına göre (V4.3.1'den önceki CPM versiyonları), bu şu şekilde belirlenir:

Adjusted FP Count = Unadjusted FP Count × VAF

Burada, ayarlanmayan FP sayısı 7. Adımda hesapladığınız işlevsel boyuttur.

VAF 0,65 ila 1,35 arasında değişebildiğinden, VAF, ayarlanmış son FP sayısı üzerinde ±% 35'lik bir etki uygular.

Fonksiyon Puanlarının Faydaları

İşlev noktaları kullanışlıdır -

• Problemin boyutu yerine çözümün boyutunu ölçmede.

• İşlev puanları için gereken tek şey gereksinimler olduğundan.

• Teknolojiden bağımsız olduğu için.

• Programlama dillerinden bağımsız olduğu için.

• Test projelerini tahmin ederken.

• Genel proje maliyetlerini, takvimi ve çabayı tahmin etmede.

• İş grupları ile daha kolay bir iletişim yöntemi sağladığı için sözleşme görüşmelerinde.

• Yazılımdaki işlevlerin gerçek kullanımlarına, arayüzlerine ve amaçlarına bir değer atarken ve nicelendirirken.

• Saat, maliyet, çalışan sayısı, süre ve diğer uygulama ölçümleri gibi diğer ölçümlerle oranlar oluştururken.

FP Depoları

International Software Benchmarking Standards Group (ISBSG) büyür ve BT verileri için iki depo tutar.

• Geliştirme ve İyileştirme Projeleri
• Bakım ve Destek Uygulamaları

Geliştirme ve İyileştirme Projeleri havuzunda 6.000'den fazla proje bulunmaktadır.

Veriler, Microsoft Excel biçiminde sunulur, bu da onunla yapmak istediğiniz daha fazla analiz yapmayı kolaylaştırır veya verileri başka bir amaç için bile kullanabilirsiniz.

ISBSG veri havuzu lisansı şuradan satın alınabilir: http://www.isbsg.com/

ISBSG, “IFPUGMembers” indirim kodu kullanıldığında çevrimiçi alışverişlerde IFPUG üyelerine% 10 indirim sunar.

ISBSG Software Project Data Release güncellemeleri şu adreste bulunabilir: http://www.ifpug.org/isbsg/

COSMIC ve IFPUG, İşlevsel Olmayan Yazılım ve Proje Gereksinimleri için bir terimler sözlüğü oluşturmak için işbirliği yaptı. - cosmic-sizing.org adresinden indirilebilir

Bir Use-Case bir kullanıcı ve kullanıcının bir hedefe ulaşmasını sağlayan bir sistem arasındaki bir dizi ilişkili etkileşimdir.

Kullanım Durumları, bir sistemin işlevsel gereksinimlerini yakalamanın bir yoludur. Sistemin kullanıcısına 'Aktör' denir. Kullanım Durumları temelde metin biçimindedir.

Kullanım Durumu Puanları - Tanım

Use-Case Points (UCP)yazılım boyutunu kullanım durumlarıyla ölçmek için kullanılan bir yazılım tahmin tekniğidir. UCP kavramı, FP'lere benzer.

Bir projedeki UCP'lerin sayısı aşağıdakilere bağlıdır -

• Sistemdeki kullanım senaryolarının sayısı ve karmaşıklığı.
• Sistemdeki aktörlerin sayısı ve karmaşıklığı.

  • Kullanım senaryoları olarak yazılmayan çeşitli işlevsel olmayan gereksinimler (taşınabilirlik, performans, sürdürülebilirlik gibi).

  • Projenin geliştirileceği ortam (dil, ekibin motivasyonu vb.)

UCP'lerle tahmin, tüm kullanım senaryolarının bir hedefle ve yaklaşık olarak aynı seviyede yazılmasını ve aynı miktarda ayrıntı verilmesini gerektirir. Bu nedenle, tahmin yapmadan önce, proje ekibi kullanım senaryolarını tanımlanmış hedeflerle ve ayrıntılı düzeyde yazdıklarından emin olmalıdır. Kullanım senaryosu normalde tek bir oturumda tamamlanır ve hedefe ulaşıldıktan sonra kullanıcı başka bir faaliyete geçebilir.

Kullanım Durumu Puanlarının Tarihi

Kullanım Durumu Noktası tahmin yöntemi, 1993 yılında Gustav Karner tarafından tanıtıldı. Çalışma daha sonra IBM ile birleşen Rational Software tarafından lisanslandı.

Kullanım Durumu Puanları Sayma Süreci

Kullanım Durumu Puanları sayma işlemi aşağıdaki adımlardan oluşur:

• Ayarlanmamış UCP'leri hesaplayın
• Teknik karmaşıklık için ayarlayın
• Çevresel karmaşıklığa göre ayarlayın
• Ayarlanmış UCP'leri hesaplayın

Adım 1: Ayarlanmamış Kullanım Durumu Puanlarını Hesaplayın.

İlk olarak Ayarlanmamış Kullanım Durumu Puanlarını aşağıdaki adımlarla hesaplarsınız -

• Ayarlanmamış Kullanım Durumunun Ağırlığını Belirleyin
• Ayarlanmamış Aktör Ağırlığını Belirleyin
• Ayarlanmamış Kullanım Durumu Puanlarını Hesaplayın

Step 1.1 - Ayarlanmamış Kullanım Durumunun Ağırlığını Belirleyin.

Step 1.1.1 - Her bir Kullanım Durumundaki işlem sayısını bulun.

Kullanım Örnekleri Kullanıcı Hedef Düzeyleri ile yazılırsa, işlem Kullanım Durumundaki bir adıma eşdeğerdir. Kullanım Durumundaki adımları sayarak işlem sayısını bulun.

Step 1.1.2- Her bir Kullanım Durumunu, Kullanım Durumundaki işlemlerin sayısına göre Basit, Ortalama veya Karmaşık olarak sınıflandırın. Ayrıca Kullanım Durumu Ağırlığını aşağıdaki tabloda gösterildiği gibi atayın -

Kullanım Durumu Karmaşıklığı	İşlem Sayısı	Kullanım Durumu Ağırlığı
Basit	≤3	5
Ortalama	4 ila 7	10
Karmaşık	> 7	15

Step 1.1.3- Her bir Kullanım Durumu için tekrarlayın ve tüm Kullanım Durumu Ağırlıklarını alın. Ayarlanmamış Kullanım Durumu Ağırlığı (UUCW), tüm Kullanım Durumu Ağırlıklarının toplamıdır.

Step 1.1.4 - Aşağıdaki tabloyu kullanarak Ayarlanmamış Kullanım Durumu Ağırlığını (UUCW) bulun -

Kullanım Durumu Karmaşıklığı	Kullanım Durumu Ağırlığı	Kullanım Durumlarının Sayısı	Ürün
Basit	5	NSUC	5 × NSUC
Ortalama	10	NAUC	10 × NAUC
Karmaşık	15	NCUC	15 × NCUC
Unadjusted Use-Case Weight (UUCW)			5 × NSUC + 10 × NAUC + 15 × NCUC

Nerede,

NSUC hayırdır. Basit Kullanım Durumları.

NAUC hayırdır. Ortalama Kullanım Durumlarının Sayısı.

NCUC hayırdır. Karmaşık Kullanım Durumları.

Step 1.2 - Ayarlanmamış Aktör Ağırlığını Belirleyin.

Kullanım Durumundaki bir Aktör, bir kişi, başka bir program vb. Olabilir. Tanımlanmış API'ye sahip bir sistem gibi bazı aktörlerin çok basit ihtiyaçları vardır ve bir Kullanım Durumunun karmaşıklığını çok az artırır.

Bir protokol aracılığıyla etkileşime giren bir sistem gibi bazı aktörlerin daha fazla ihtiyacı vardır ve bir Kullanım Durumunun karmaşıklığını belirli bir ölçüde artırır.

GUI aracılığıyla etkileşim kuran bir kullanıcı gibi diğer Aktörler, Kullanım Durumunun karmaşıklığı üzerinde önemli bir etkiye sahiptir. Bu farklılıklara dayanarak, oyuncuları Basit, Ortalama ve Karmaşık olarak sınıflandırabilirsiniz.

Step 1.2.1 - Oyuncuları Basit, Ortalama ve Karmaşık olarak sınıflandırın ve aşağıdaki tabloda gösterildiği gibi Oyuncu Ağırlıklarını atayın -

Oyuncu Karmaşıklığı	Misal	Oyuncu Ağırlığı
Basit	Tanımlanmış API'ye sahip bir Sistem	1
Ortalama	Bir Protokol aracılığıyla etkileşimde bulunan bir Sistem	2
Karmaşık	GUI aracılığıyla etkileşimde bulunan bir Kullanıcı	3

Step 1.2.2- Her Oyuncu için tekrarlayın ve tüm Oyuncu Ağırlıklarını alın. Ayarlanmamış Oyuncu Ağırlığı (UAW), tüm Oyuncu Ağırlıklarının toplamıdır.

Step 1.2.3 - Aşağıdaki tabloyu kullanarak Ayarlanmamış Aktör Ağırlığını (UAW) bulun -

Oyuncu Karmaşıklığı	Oyuncu Ağırlığı	Oyuncu Sayısı	Ürün
Basit	1	NSA	1 × NSA
Ortalama	2	NAA	2 × NAA
Karmaşık	3	NCA	3 × NCA
Unadjusted Actor Weight (UAW)			1 × NSA + 2 × NAA + 3 × NCA

Nerede,

NSA hayırdır. Basit Aktörler.

NAA hayırdır. Ortalama Aktörler.

NCA hayırdır. Karmaşık Aktörler.

Step 1.3 - Ayarlanmamış Kullanım Durumu Puanlarını Hesaplayın.

Ayarlanmamış Kullanım Durumu Ağırlığı (UUCW) ve Ayarlanmamış Aktör Ağırlığı (UAW) birlikte, Ayarlanmamış Kullanım Durumu Puanları olarak adlandırılan sistemin ayarlanmamış boyutunu verir.

Unadjusted Use-Case Points (UUCP) = UUCW + UAW

Sonraki adımlar, Ayarlanmamış Kullanım Durum Noktalarını (UUCP) Teknik Karmaşıklık ve Çevresel Karmaşıklık için ayarlamaktır.

Adım 2: Teknik Karmaşıklık İçin Ayarlayın

Step 2.1 - Bir projenin Teknik Karmaşıklığının Kullanım Durumu Puanları üzerindeki etkisine katkıda bulunan 13 Faktörü ve aşağıdaki tabloda verilen karşılık gelen Ağırlıkları göz önünde bulundurun -

Faktör	Açıklama	Ağırlık
T1	Dağıtımlı sistem	2.0
T2	Yanıt süresi veya çıktı performans hedefleri	1.0
T3	Son kullanıcı verimliliği	1.0
T4	Karmaşık dahili işleme	1.0
T5	Kod yeniden kullanılabilir olmalıdır	1.0
T6	Kurulumu kolay	.5
T7	Kullanımı kolay	.5
T8	Taşınabilir	2.0
T9	Değiştirmesi kolay	1.0
T10	Eşzamanlı	1.0
T11	Özel güvenlik hedefleri içerir	1.0
T12	Üçüncü şahıslar için doğrudan erişim sağlar	1.0
T13	Özel kullanıcı eğitim tesisleri gereklidir	1.0

Bu faktörlerin çoğu, projenin işlevsel olmayan gereksinimlerini temsil eder.

Step 2.2 - 13 Faktörün her biri için, projeyi değerlendirin ve 0'dan (ilgisiz) 5'e (çok önemli) derecelendirin.

Step 2.3 - Faktörün Etki Ağırlığından Faktörün Etkisini ve Proje için Anma Değerini şu şekilde hesaplayın:

Impact of the Factor = Impact Weight × Rated Value

Step (2.4)- Tüm Faktörlerin Etki toplamını hesaplayın. Bu, aşağıdaki tabloda verilen Toplam Teknik Faktörü (TFactor) verir -

Faktör	Açıklama	Ağırlık (W)	Nominal Değer (0-5) (RV)	Etki (I = W × RV)
T1	Dağıtımlı sistem	2.0
T2	Yanıt süresi veya çıktı performans hedefleri	1.0
T3	Son kullanıcı verimliliği	1.0
T4	Karmaşık dahili işleme	1.0
T5	Kod yeniden kullanılabilir olmalıdır	1.0
T6	Kurulumu kolay	.5
T7	Kullanımı kolay	.5
T8	Taşınabilir	2.0
T9	Değiştirmesi kolay	1.0
T10	Eşzamanlı	1.0
T11	Özel güvenlik hedefleri içerir	1.0
T12	Üçüncü şahıslar için doğrudan erişim sağlar	1.0
T13	Özel kullanıcı eğitim tesisleri gereklidir	1.0
Total Technical Factor (TFactor)

Step 2.5 - Teknik Karmaşıklık Faktörünü (TCF) şu şekilde hesaplayın -

TCF = 0.6 + (0.01 × TFactor)

3. Adım: Çevresel Karmaşıklık İçin Ayarlayın

Step 3.1 - Aşağıdaki tabloda verilen proje yürütmesini etkileyebilecek 8 Çevresel Faktörü ve bunlara karşılık gelen Ağırlıkları göz önünde bulundurun -

Faktör	Açıklama	Ağırlık
F1	Kullanılan proje modeline aşina	1.5
F2	Uygulama deneyimi	.5
F3	Nesneye yönelik deneyim	1.0
F4	Lider analist yeteneği	.5
F5	Motivasyon	1.0
F6	Kararlı gereksinimler	2.0
F7	Yarı zamanlı personel	-1.0
F8	Zor programlama dili	-1.0

Step 3.2 - 8 Faktörün her biri için, projeyi değerlendirin ve 0'dan (ilgisiz) 5'e (çok önemli) derecelendirin.

Step 3.3 - Faktörün Etki Ağırlığından Faktörün Etkisini ve Proje için Anma Değerini şu şekilde hesaplayın:

Impact of the Factor = Impact Weight × Rated Value

Step 3.4- Tüm Faktörlerin Etki toplamını hesaplayın. Bu, aşağıdaki tabloda verildiği gibi Toplam Çevre Faktörünü (EFactor) verir -

Faktör	Açıklama	Ağırlık (W)	Nominal Değer (0-5) (RV)	Etki (I = W × RV)
F1	Kullanılan proje modeline aşina	1.5
F2	Uygulama deneyimi	.5
F3	Nesneye yönelik deneyim	1.0
F4	Lider analist yeteneği	.5
F5	Motivasyon	1.0
F6	Kararlı gereksinimler	2.0
F7	Yarı zamanlı personel	-1.0
F8	Zor programlama dili	-1.0
Total Environment Factor (EFactor)

Step 3.5 - Çevresel Faktörü (EF) şu şekilde hesaplayın -

1.4 + (-0.03 × EFactor)

Adım 4: Düzeltilmiş Kullanım Durumu Noktalarını (UCP) Hesaplayın

Düzeltilmiş Kullanım Durumu Puanlarını (UCP) şu şekilde hesapla -

UCP = UUCP × TCF × EF

Kullanım Durumu Puanlarının Avantaj ve Dezavantajları

Kullanım Durumu Puanlarının Avantajları

• UCP'ler, kullanım durumlarına dayanır ve proje yaşam döngüsünün çok erken dönemlerinde ölçülebilir.

• UCP (boyut tahmini), projeyi uygulayan ekibin boyutundan, becerisinden ve deneyiminden bağımsız olacaktır.

• Deneyimli kişiler tarafından tahmin yapıldığında, UCP'ye dayalı tahminlerin gerçeğe yakın olduğu bulunmuştur.

• UCP'nin kullanımı kolaydır ve ek analiz gerektirmez.

• Kullanım senaryoları, gereksinimleri tanımlamak için bir seçim yöntemi olarak büyük ölçüde kullanılmaktadır. Bu gibi durumlarda, UCP en uygun tahmin tekniğidir.

Kullanım Durumu Puanlarının Dezavantajları

• UCP, yalnızca gereksinimler kullanım durumları şeklinde yazıldığında kullanılabilir.

• Hedef odaklı, iyi yazılmış kullanım durumlarına bağlıdır. Kullanım senaryoları iyi veya tek tip yapılandırılmamışsa, ortaya çıkan UCP doğru olmayabilir.

• Teknik ve çevresel faktörlerin UCP üzerinde yüksek etkisi vardır. Teknik ve çevresel faktörlere değer verilirken özen gösterilmelidir.

• UCP, genel proje boyutunun ilk tahmini için kullanışlıdır, ancak bir ekibin yinelemeden yinelemeye yönelik çalışmasını yönlendirmede çok daha az yararlıdır.

Delphi Methodbaşlangıçta bir uzmanlar paneline dayanan sistematik, etkileşimli bir tahmin yöntemi olarak geliştirilen yapılandırılmış bir iletişim tekniğidir. Uzmanlar anketleri iki veya daha fazla turda yanıtlıyor. Her turdan sonra bir kolaylaştırıcı, uzmanların kararlarının nedenleriyle birlikte önceki tura ait tahminlerinin anonim bir özetini sunar. Uzmanlar daha sonra panelin diğer üyelerinin cevapları ışığında önceki cevaplarını gözden geçirmeye teşvik edilir.

Bu süreçte cevap aralığının azalacağına ve grubun "doğru" cevaba yaklaşacağına inanılıyor. Son olarak, süreç önceden tanımlanmış bir durdurma kriterinden sonra (örn. Tur sayısı, fikir birliğine varılması ve sonuçların istikrarı) durdurulur ve final turlarının ortalama veya medyan puanları sonuçları belirler.

Delphi Yöntemi 1950-1960'larda RAND Corporation'da geliştirilmiştir.

Geniş Bant Delphi Tekniği

1970'lerde Barry Boehm ve John A. Farquhar, Delphi Metodunun Geniş Bant Varyantını yarattı. "Geniş bant" terimi, Delphi Metodu ile karşılaştırıldığında, Geniş Bant Delphi Tekniği, katılımcılar arasında daha fazla etkileşim ve daha fazla iletişim içerdiği için kullanılmaktadır.

Genişbant Delphi Tekniğinde tahmin ekibi, 3-7 kişilik bir ekip oluşturan proje yöneticisi, moderatör, uzmanlar ve geliştirme ekibinin temsilcilerinden oluşur. İki toplantı var -

• Açılış toplantısı
• Tahmin Toplantısı

Geniş Bant Delphi Tekniği - Adımlar

Step 1 - Tahmin ekibini ve bir moderatörü seçin.

Step 2- Moderatör, ekibe problem özellikleri ve üst düzey bir görev listesi, varsayımlar veya proje kısıtlamaları ile sunulan başlangıç ​​toplantısını yürütür. Ekip, sorun ve varsa tahmin konularını tartışır. Ayrıca tahmin birimlerine de karar verirler. Moderatör tüm tartışmayı yönlendirir, zamanı izler ve başlangıç ​​toplantısından sonra, problem özelliklerini, üst düzey görev listesini, varsayımları ve karar verilen tahmin birimlerini içeren yapılandırılmış bir belge hazırlar. Daha sonra bir sonraki adım için bu belgenin kopyalarını iletir.

Step 3 - Her bir Estimation ekip üyesi daha sonra ayrı ayrı ayrıntılı bir WBS oluşturur, WBS'deki her görevi tahmin eder ve yapılan varsayımları belgeler.

Step 4- Moderatör, Tahmin ekibini Tahmin toplantısı için çağırır. Tahmin ekibi üyelerinden herhangi biri tahminlerin hazır olmadığını söyleyerek yanıt verirse, moderatör daha fazla zaman verir ve Toplantı Davetini yeniden gönderir.

Step 5 - Tüm Tahmin ekibi, tahmin toplantısı için bir araya gelir.

Step 5.1 - Tahmin toplantısının başlangıcında, moderatör ekip üyelerinin her birinden ilk tahminleri toplar.

Step 5.2- Daha sonra beyaz tahtaya bir grafik çizer. Her üyenin toplam proje tahminini, karşılık gelen isimleri açıklamadan 1. Tur satırında bir X olarak çizer. Tahmin ekibi, başlangıçta büyük olabilecek tahmin aralığı hakkında bir fikir edinir.

Step 5.3- Her ekip üyesi yaptığı ayrıntılı görev listesini yüksek sesle okur, yapılan varsayımları tanımlar ve herhangi bir soru veya sorunu gündeme getirir. Görev tahminleri açıklanmadı.

Ayrı ayrıntılı görev listeleri, birleştirildiğinde daha eksiksiz bir görev listesine katkıda bulunur.

Step 5.4 - Ekip daha sonra ulaştıkları görevler, yapılan varsayımlar ve tahmin sorunları hakkında sahip oldukları herhangi bir şüpheyi / sorunu tartışır.

Step 5.5- Daha sonra her ekip üyesi görev listesini ve varsayımlarını gözden geçirir ve gerekirse değişiklikler yapar. Görev tahminleri ayrıca + N Saat olarak belirtilen tartışmaya dayalı ayarlamalar gerektirebilir. daha fazla çaba için ve –N Saat. daha az çaba için.

Ekip üyeleri daha sonra toplam proje tahminine ulaşmak için görev tahminlerindeki değişiklikleri birleştirir.

Step 5.6 - Moderatör, tüm ekip üyelerinden değiştirilen tahminleri toplar ve bunları 2. Tur satırına yerleştirir.

Bu turda, daha çok fikir birliğine dayalı olduğu için menzil öncekine göre daha dar olacaktır.

Step 5.7 - Ekip daha sonra yaptıkları görev değişikliklerini ve varsayımları tartışır.

Step 5.8- Daha sonra her ekip üyesi görev listesini ve varsayımlarını gözden geçirir ve gerekirse değişiklikler yapar. Görev tahminleri ayrıca tartışmaya göre ayarlamalar gerektirebilir.

Ekip üyeleri daha sonra toplam proje tahminine ulaşmak için görev tahminindeki değişiklikleri bir kez daha birleştirir.

Step 5.9 - Moderatör, tüm üyelerden değiştirilen tahminleri tekrar toplar ve bunları 3. Tur satırına yerleştirir.

Yine, bu turda, menzil öncekine göre daha dar olacaktır.

Step 5.10 - 5.7, 5.8, 5.9 adımları, aşağıdaki kriterlerden biri karşılanana kadar tekrar edilir -

• Sonuçlar, kabul edilebilir derecede dar bir aralığa yakınsar.
• Tüm ekip üyeleri son tahminlerini değiştirmeye isteksizdir.
• Ayrılan Tahmin toplantı süresi sona erdi.

Step 6 - Proje Yöneticisi daha sonra Tahmin toplantısının sonuçlarını bir araya getirir.

Step 6.1 - Bireysel görev listelerini ve bunlara karşılık gelen tahminleri tek bir ana görev listesinde derler.

Step 6.2 - Ayrıca tek tek varsayım listelerini de birleştirir.

Step 6.3 - Daha sonra Tahmin ekibiyle birlikte son görev listesini gözden geçirir.

Geniş Bant Delphi Tekniğinin Avantaj ve Dezavantajları

Avantajlar

• Geniş Bant Delphi Tekniği, eforu tahmin etmek için fikir birliğine dayalı bir tahmin tekniğidir.
• Bir görevi yapmak için zaman tahmin ederken kullanışlıdır.
• Tecrübeli kişilerin katılımı ve bireysel olarak tahmin etmeleri güvenilir sonuçlara yol açacaktır.
• İşi yapacak kişiler tahminler yapıyor ve böylece geçerli tahminler yapıyorlar.
• Anonimlik, herkesin sonuçlarını güvenle ifade etmesini mümkün kılar.
• Çok basit bir teknik.
• Varsayımlar belgelenir, tartışılır ve kabul edilir.

Dezavantajları

• Yönetim desteği gereklidir.
• Tahmin sonuçları, yönetimin duymak istediği şey olmayabilir.

Üç noktalı Tahmin, üç değere bakar -

• en iyimser tahmin (O),
• en olası tahmin (M) ve
• kötümser bir tahmin (en az olası tahmin (L)).

Sektörde Üç Nokta Tahmin ve PERT ile ilgili bazı karışıklıklar var. Ancak teknikler farklı. İki tekniği öğrenirken farklılıkları göreceksiniz. Ayrıca PERT tekniğinin sonunda farklılıklar harmanlanarak sunulur. Önce onlara bakmak istersen, yapabilirsin.

Üç noktalı Tahmin (E), basit ortalamaya dayanır ve üçgen dağılımı izler.

E = (O + M + L) / 3

Standart sapma

Üçgen Dağılımda,

Ortalama = (O + M + L) / 3

Standart Sapma = √ [((O - E) ² + (M - E) ² + (L - E) ² ) / 2]

Üç noktalı Tahmin Adımları

Step 1 - WBS'ye gelin.

Step 2 - Her görev için üç değer bulun - en iyimser tahmin (O), en olası tahmin (M) ve kötümser bir tahmin (L).

Step 3 - Üç değerin ortalamasını hesaplayın.

Mean = (O + M + L) / 3

Step 4- Görevin Üç Noktalı Tahminini hesaplayın. Üç noktalı Tahmin Ortalama'dır. Dolayısıyla

E = Mean = (O + M + L) / 3

Step 5 - Görevin Standart Sapmasını hesaplayın.

Standard Deviation (SD) = √ [((O − E)² + (M − E)² + (L - E)²)/2]

Step 6 - WBS'deki tüm Görevler için Adım 2, 3 ve 4'ü tekrarlayın.

Step 7 - Projenin Üç Noktalı Tahminini hesaplayın.

E (Project) = ∑ E (Task)

Step 8 - Projenin Standart Sapmasını hesaplayın.

SD (Project) = √ (∑SD (Task)²)

Proje Tahminlerini Güven Düzeylerine Dönüştür

Bu şekilde hesaplanan Üç Noktalı Tahmin (E) ve Standart Sapma (SD), proje tahminlerini "Güven Düzeylerine" dönüştürmek için kullanılır.

Dönüşüm şu şekilde yapılır:

• E +/– SD'de Güven Düzeyi yaklaşık% 68'dir.
• E değeri +/– 1,645 × SD'de Güven Düzeyi yaklaşık% 90'dır.
• E değeri +/– 2 × SD'de Güven Düzeyi yaklaşık% 95'tir.
• E değeri +/– 3 × SD'de Güven Düzeyi yaklaşık% 99,7'dir.

Genel olarak,% 95 Güven Seviyesi, yani E Değeri + 2 × SD, tüm proje ve görev tahminleri için kullanılır.

Proje Değerlendirme ve Gözden Geçirme Tekniği (PERT) tahmini üç değeri dikkate alır: en iyimser tahmin (O), en olası tahmin (M) ve kötümser bir tahmin (en az olası tahmin (L)). Sektörde Üç Nokta Tahmin ve PERT ile ilgili bazı karışıklıklar var. Ancak teknikler farklı. İki tekniği öğrenirken farklılıkları göreceksiniz. Ayrıca, bu bölümün sonunda farklılıklar bir araya getirilmiş ve sunulmuştur.

PERT üç değere dayanmaktadır - en iyimser tahmin (O), en olası tahmin (M) ve kötümser bir tahmin (en az olası tahmin (L)). En olası tahmin, diğer iki tahminden 4 kat daha fazla ağırlıklandırılmıştır (iyimser ve kötümser).

PERT Tahmini (E), ağırlıklı ortalamaya dayanır ve beta dağılımını izler.

E = (O + 4 × M + L)/6

PERT sıklıkla Kritik Yol Yöntemi (CPM) ile birlikte kullanılır. CPM, projede kritik olan görevleri anlatır. Bu görevlerde gecikme olursa proje gecikir.

Standart sapma

Standart Sapma (SD), tahmindeki değişkenliği veya belirsizliği ölçer.

Beta dağıtımda,

Ortalama = (O + 4 × M + L) / 6

Standart Sapma (SD) = (L - O) / 6

PERT Tahmin Adımları

Step (1) - WBS'ye gelin.

Step (2) - Her görev için en iyimser tahmin (O), en olası tahmin (M) ve kötümser tahmin (L) olmak üzere üç değer bulun.

Step (3) - PERT Ortalama = (O + 4 × M + L) / 6

PERT Ortalama = (O + 4 × M + L) / 3

Step (4) - Görevin Standart Sapmasını hesaplayın.

Standart Sapma (SD) = (L - O) / 6

Step (6) - WBS'deki tüm görevler için 2, 3 ve 4. adımları tekrarlayın.

Step (7) - Projenin PERT tahminini hesaplayın.

E (Proje) = ∑ E (Görev)

Step (8) - Projenin Standart Sapmasını hesaplayın.

SD (Proje) = √ (ΣSD (Görev) ² )

Proje Tahminlerini Güven Düzeylerine Dönüştür

Bu şekilde hesaplanan PERT Tahmini (E) ve Standart Sapma (SD), proje tahminlerini güven düzeylerine dönüştürmek için kullanılır.

Dönüşüm,

• E +/– SD'de güven seviyesi yaklaşık% 68'dir.
• E değeri +/– 1,645 × SD'de güven seviyesi yaklaşık% 90'dır.
• E değeri +/– 2 × SD'de güven seviyesi yaklaşık% 95'tir.
• E değeri +/– 3 × SD'de güven seviyesi yaklaşık% 99,7'dir.

Genel olarak% 95 güven seviyesi, yani E Değeri + 2 × SD, tüm proje ve görev tahminleri için kullanılır.

Üç Noktalı Tahmin ile PERT arasındaki farklar

Üç Nokta Tahmin ve PERT arasındaki farklar aşağıdadır -

Üç Noktalı Tahmin	PERT
Basit ortalama	Ağırlıklı ortalama
Üçgen Dağılımı takip eder	Beta Dağıtımını takip eder
Tekrarlayan küçük projeler için kullanılır	Tekrar etmeyen büyük projeler, genellikle Ar-Ge projeleri için kullanılır. Kritik Yol Yöntemi (BGBM) ile birlikte kullanılır
E = Ortalama = (O + M + L) / 3 Bu basit ortalama	E = Ortalama = (O + 4 × M + L) / 6 Bu ağırlıklı ortalamadır
SS = √ [((O - E) 2 + (M - E) 2 + (L - E) 2 ) / 2]	SD = (L - O) / 6

Analogous EstimationMevcut projenizin süresini veya maliyetini tahmin etmek için benzer bir geçmiş proje bilgisini kullanır, dolayısıyla "analoji" kelimesi kullanılır. Mevcut projenizle ilgili sınırlı bilgi olduğunda analog tahmin kullanabilirsiniz.

Yöneticiler projenin yapmaya değer olup olmadığına karar vermek için karar verme verilerine ihtiyaç duyduklarından, proje yöneticilerinden yeni bir proje için maliyet ve süre tahminleri vermelerinin isteneceği durumlar oldukça sık olacaktır. Genellikle, ne proje yöneticisi ne de organizasyondaki herhangi bir kişi yeni proje gibi bir proje yapmamıştır, ancak yöneticiler yine de doğru maliyet ve süre tahminleri istemektedir.

Bu gibi durumlarda, analog tahmin en iyi çözümdür. Mükemmel olmayabilir, ancak geçmiş verilere dayandığı için doğrudur. Benzer tahmin, uygulaması kolay bir tekniktir. Proje başarı oranı, ilk tahminlere kıyasla% 60'a kadar çıkabilir.

Benzer Tahmin - Tanım

Analog tahmin, gelecekteki bir faaliyet için benzer parametrenin tahmin edilmesinde temel olarak geçmiş verilerden gelen parametrelerin değerlerini kullanan bir tekniktir. Parametre örnekleri: Kapsam, maliyet ve süre. Ölçek örneklerinin ölçüleri - Boyut, ağırlık ve karmaşıklık.

Proje yöneticisinin ve muhtemelen ekibin tecrübesi ve muhakemesi tahmin sürecine uygulandığından, bu, tarihsel bilgi ve uzman görüşünün bir kombinasyonu olarak kabul edilir.

Benzer Tahmin Gereksinimleri

Benzer bir tahmin için aşağıdaki şarttır -

• Önceki ve devam eden projelerden veriler
  • Her ekip üyesinin haftalık çalışma saatleri
  • Projenin tamamlanmasına ilişkin maliyetler
• Mevcut projeye yakın proje
• Mevcut Proje yeni ise ve geçmiş proje benzer değilse
  • Mevcut projedekilere benzer eski projelerden modüller
  • Mevcut projede olanlara benzer geçmiş projelerden faaliyetler
  • Bu seçilmişlerden veriler
• Tahminler hakkında deneyimli muhakemeyi sağlamak için proje yöneticisinin ve tahmin ekibinin katılımı.

Benzer Tahmin Adımları

Proje yöneticisi ve ekibi toplu olarak benzer tahminler yapmak zorundadır.

• Step 1 - Mevcut projenin etki alanını belirleyin.

• Step 2 - Mevcut projenin teknolojisini belirleyin.

• Step 3- Benzer bir proje verisi mevcutsa, organizasyon veritabanına bakın. Varsa Adım (4) 'e gidin. Aksi takdirde Adım (6) 'ya gidin.

• Step 4 - Mevcut projeyi tanımlanan geçmiş proje verileriyle karşılaştırın.

• Step 5- Mevcut projenin süre ve maliyet tahminlerine ulaşın. Bu, projenin analog tahminini sona erdirir.

• Step 6 - Geçmiş projelerden herhangi birinin mevcut projede olanlarla benzer modülleri varsa, organizasyon veritabanına bakın.

• Step 7 - Geçmiş projelerden herhangi birinin mevcut projedeki ile benzer aktiviteleri varsa, organizasyon veritabanına bakın.

• Step 8 - Tüm bunları toplayın ve mevcut projenin süre ve maliyet tahminlerine ulaşmak için uzman görüşünü kullanın.

Analog Tahminin Avantajları

• Çok az ayrıntı bilindiğinde, projenin ilk aşamalarında analog tahmin daha iyi bir tahmin yöntemidir.

• Teknik basittir ve tahmin için harcanan zaman çok azdır.

• Teknik, kuruluşun geçmiş proje verilerine dayandığından kuruluşun başarı oranının yüksek olması beklenebilir.

• Bireysel görevlerin çabasını ve süresini tahmin etmek için de benzer tahminler kullanılabilir. Bu nedenle, WBS'de görevleri tahmin ederken Analoji'yi kullanabilirsiniz.

Proje Yönetimi ve Sistem Mühendisliği'ndeki İş Dağılımı Yapısı (WBS), bir projenin daha küçük bileşenlere dağıtılabilir odaklı bir ayrıştırılmasıdır. WBS, ekibin çalışmalarını yönetilebilir bölümler halinde düzenleyen temel bir projedir. Proje Yönetimi Bilgi Birimi (PMBOK), WBS'yi "proje ekibi tarafından yürütülecek işin teslim edilebilir odaklı hiyerarşik ayrıştırması" olarak tanımlar.

WBS öğesi bir ürün, veri, hizmet veya bunların herhangi bir kombinasyonu olabilir. WBS ayrıca ayrıntılı maliyet tahmini ve kontrolü için gerekli çerçeveyi sağlar ve program geliştirme ve kontrol için rehberlik sağlar.

WBS'nin Temsili

WBS, projenin çalışma etkinliklerinin hiyerarşik bir listesi olarak temsil edilir. İki WBS biçimi vardır -

• Anahat Görünümü (Girintili Biçim)
• Ağaç Yapısı Görünümü (Organizasyon Şeması)

Öncelikle bir WBS hazırlamak için ana hat görünümünün nasıl kullanılacağını tartışalım.

Anahat Görünümü

Anahat görünümü oldukça kullanıcı dostu bir düzendir. Tüm projenin iyi bir görünümünü sunar ve aynı zamanda kolay değişikliklere de izin verir. Bir projenin çeşitli aşamalarını kaydetmek için sayıları kullanır. Aşağıdakine biraz benziyor -

• Software Development

• Scope

  • Proje kapsamını belirleyin
  • Güvenli proje sponsorluğu
  • Ön kaynakları tanımlayın
  • Temel kaynakları koruyun
  • Kapsam tamamlandı

• Analysis/Software Requirements

  • İhtiyaç analizi yapın
  • Taslak ön yazılım özellikleri
  • Ön bütçe geliştirin
  • Ekiple birlikte yazılım özelliklerini / bütçesini inceleyin
  • Yazılım özellikleriyle ilgili geri bildirimleri dahil edin
  • Teslimat zaman çizelgesi geliştirin
  • Devam etmek için onayları alın (konsept, zaman çizelgesi ve bütçe)
  • Gerekli kaynakları koruyun
  • Analiz tamamlandı

• Design

  • Ön yazılım özelliklerini inceleyin
  • İşlevsel özellikler geliştirin
  • Devam etmek için onay alın
  • Tasarım tamamlandı

• Development

  • İşlevsel özellikleri inceleyin
  • Modüler / katmanlı tasarım parametrelerini tanımlayın
  • Kod geliştirin
  • Geliştirici testi (birincil hata ayıklama)
  • Geliştirme tamamlandı

• Testing

  • Ürün özelliklerini kullanarak birim test planları geliştirin
  • Ürün özelliklerini kullanarak entegrasyon testi planları geliştirin

• Training

  • Son kullanıcılar için eğitim spesifikasyonları geliştirin
  • Eğitim verme metodolojisini belirleyin (çevrimiçi, sınıf vb.)
  • Eğitim materyalleri geliştirin
  • Eğitim materyallerini tamamlayın
  • Eğitim verme mekanizması geliştirin
  • Eğitim materyalleri tamamlandı

• Deployment

  • Nihai dağıtım stratejisini belirleyin
  • Dağıtım metodolojisi geliştirin
  • Güvenli dağıtım kaynakları
  • Destek personelini eğitin
  • Yazılım dağıtın
  • Dağıtım tamamlandı

Şimdi ağaç yapısı görünümüne bir göz atalım.

Ağaç Yapısı Görünümü

Ağaç Yapısı Görünümü, tüm projenin çok kolay anlaşılır bir görünümünü sunar. Aşağıdaki çizim, bir ağaç yapısı görünümünün nasıl göründüğünü gösterir. Bu tür organizasyon şeması yapısı, MS-Word'de bulunan özelliklerle kolaylıkla çizilebilir.

WBS Türleri

İki tür WBS vardır -

• Functional WBS- İşlevsel WBS'de sistem, geliştirilecek uygulamadaki işlevlere göre kırılır. Bu, sistemin boyutunu tahmin etmede kullanışlıdır.

• Activity WBS- Etkinlik WBS'de sistem, sistemdeki etkinliklere göre bozulur. Faaliyetler ayrıca görevlere ayrılmıştır. Bu, sistemdeki eforu ve programı tahmin etmede kullanışlıdır.

Tahmini Boyut

Step 1 - İşlevsel WBS ile başlayın.

Step 2 - Yaprak düğümlerini düşünün.

Step 3 - Boyut tahminlerine ulaşmak için Analoji veya Geniş Bant Delphi'yi kullanın.

Çaba Tahmin Et

Step 1- WBS oluşturmak için Geniş Bant Delphi Tekniğini kullanın. Görevlerin 8 saatten fazla olmamasını öneriyoruz. Bir görev daha uzun süreli ise bölün.

Step 2 - Görevler için Efor Tahminlerine ulaşmak için Geniş Bant Delphi Tekniğini veya Üç Nokta Tahminini kullanın.

Planlama

WBS hazır olduğunda ve boyut ve iş gücü tahminleri bilindiğinde, görevleri planlamaya hazırsınız demektir.

Görevleri planlarken belirli şeyler dikkate alınmalıdır -

• Precedence - Bir başkasından önce olması gereken bir görevin diğerinden önceliğe sahip olduğu söylenir.

• Concurrence - Eşzamanlı görevler, aynı anda (paralel olarak) meydana gelebilen görevlerdir.

• Critical Path - Proje tamamlanma tarihinin bağlı olduğu belirli sıralı görevler dizisi.

  • Tüm projelerin kritik bir yolu vardır.
  • Kritik olmayan görevleri hızlandırmak, programı doğrudan kısaltmaz.

Kritik yol metodu

Kritik Yol Yöntemi (CPM), kritik yolu belirleme ve optimize etme işlemidir. Kritik olmayan yol görevleri, tamamlanma tarihini etkilemeden daha erken veya daha sonra başlayabilir.

Lütfen mevcut yolu kısalttığınızda kritik yolun başka bir yolla değişebileceğini unutmayın. Örneğin, önceki şekildeki WBS için kritik yol aşağıdaki gibi olacaktır -

Proje tamamlanma tarihi bir dizi sıralı göreve dayandığından, bu görevlere kritik görevler denir.

Proje tamamlanma tarihi eğitim, dokümantasyon ve dağıtıma dayalı değildir. Bu tür görevlere kritik olmayan görevler denir.

Görev Bağımlılığı İlişkileri

Belirli zamanlarda, planlama yaparken görev bağımlılığı ilişkilerini göz önünde bulundurmanız gerekebilir. Önemli Görev Bağımlılığı İlişkileri şunlardır:

• Bitişten Başlangıca (FS)
• Bitişten Bitişe (FF)

Bitişten Başlangıca (FS)

Bitiş-Başlangıcı (FS) görev bağımlılığı ilişkisinde, Görev B, Görev A tamamlanana kadar başlayamaz.

Bitişten Bitişe (FF)

Bitir-Bitir (FF) görev bağımlılığı ilişkisinde, Görev B, Görev A tamamlanana kadar tamamlanamaz.

Gantt şeması

Gantt şeması, 1896'da Karol Adamiecki tarafından ve 1910'larda bağımsız olarak Henry Gantt tarafından uyarlanan ve bir proje programını gösteren bir tür çubuk grafiktir. Gantt şemaları, bir projenin terminal öğelerinin ve özet öğelerinin başlangıç ​​ve bitiş tarihlerini gösterir.

You can take the Outline Format in Figure 2 into Microsoft Project to obtain a Gantt Chart View.

Milestones

Milestones are the critical stages in your schedule. They will have a duration of zero and are used to flag that you have completed certain set of tasks. Milestones are usually shown as a diamond.

For example, in the above Gantt Chart, Design Complete and Development Complete are shown as milestones, represented with a diamond shape.

Milestones can be tied to Contract Terms.

Advantages of Estimation using WBS

WBS simplifies the process of project estimation to a great extent. It offers the following advantages over other estimation techniques −

• In WBS, the entire work to be done by the project is identified. Hence, by reviewing the WBS with project stakeholders, you will be less likely to omit any work needed to deliver the desired project deliverables.

• WBS results in more accurate cost and schedule estimates.

• The project manager obtains team participation to finalize the WBS. This involvement of the team generates enthusiasm and responsibility in the project.

• WBS provides a basis for task assignments. As a precise task is allocated to a particular team member who would be accountable for its accomplishment.

• WBS enables monitoring and controlling at task level. This allows you to measure progress and ensure that your project will be delivered on time.

Planning Poker Estimation

Planning Poker is a consensus-based technique for estimating, mostly used to estimate effort or relative size of user stories in Scrum.

Planning Poker combines three estimation techniques − Wideband Delphi Technique, Analogous Estimation, and Estimation using WBS.

Planning Poker was first defined and named by James Grenning in 2002 and later popularized by Mike Cohn in his book "Agile Estimating and Planning”, whose company trade marked the term.

Planning Poker Estimation Technique

In Planning Poker Estimation Technique, estimates for the user stories are derived by playing planning poker. The entire Scrum team is involved and it results in quick but reliable estimates.

• Planning Poker is played with a deck of cards. As Fibonacci sequence is used, the cards have numbers - 1, 2, 3, 5, 8, 13, 21, 34, etc. These numbers represent the “Story Points”. Each estimator has a deck of cards. The numbers on the cards should be large enough to be visible to all the team members, when one of the team members holds up a card.

• One of the team members is selected as the Moderator. The moderator reads the description of the user story for which estimation is being made. If the estimators have any questions, product owner answers them.

• Each estimator privately selects a card representing his or her estimate. Cards are not shown until all the estimators have made a selection. At that time, all cards are simultaneously turned over and held up so that all team members can see each estimate.

• In the first round, it is very likely that the estimations vary. The high and low estimators explain the reason for their estimates. Care should be taken that all the discussions are meant for understanding only and nothing is to be taken personally. The moderator has to ensure the same.

• The team can discuss the story and their estimates for a few more minutes.

• The moderator can take notes on the discussion that will be helpful when the specific story is developed. After the discussion, each estimator re-estimates by again selecting a card. Cards are once again kept private until everyone has estimated, at which point they are turned over at the same time.

Repeat the process till the estimates converge to a single estimate that can be used for the story. The number of rounds of estimation may vary from one user story to another.

Benefits of Planning Poker Estimation

Planning poker combines three methods of estimation −

Expert Opinion − In expert opinion-based estimation approach, an expert is asked how long something will take or how big it will be. The expert provides an estimate relying on his or her experience or intuition or gut feel. Expert Opinion Estimation usually doesn’t take much time and is more accurate compared to some of the analytical methods.

Analogy − Analogy estimation uses comparison of user stories. The user story under estimation is compared with similar user stories implemented earlier, giving accurate results as the estimation is based on proven data.

Disaggregation − Disaggregation estimation is done by splitting a user story into smaller, easier-to-estimate user stories. The user stories to be included in a sprint are normally in the range of two to five days to develop. Hence, the user stories that possibly take longer duration need to be split into smaller use-Cases. This approach also ensures that there would be many stories that are comparable.

Test efforts are not based on any definitive timeframe. The efforts continue until some pre-decided timeline is set, irrespective of the completion of testing.

This is mostly due to the fact that conventionally, test effort estimation is a part of the development estimation. Only in the case of estimation techniques that use WBS, such as Wideband Delphi, Three-point Estimation, PERT, and WBS, you can obtain the values for the estimates of the testing activities.

If you have obtained the estimates as Function Points (FP), then as per Caper Jones,

Number of Test Cases = (Number of Function Points) × 1.2

Once you have the number of test cases, you can take productivity data from organizational database and arrive at the effort required for testing.

Percentage of Development Effort Method

Test effort required is a direct proportionate or percentage of the development effort. Development effort can be estimated using Lines of Code (LOC) or Function Points (FP). Then, the percentage of effort for testing is obtained from Organization Database. The percentage so obtained is used to arrive at the effort estimate for testing.

Estimating Testing Projects

Several organizations are now providing independent verification and validation services to their clients and that would mean the project activities would entirely be testing activities.

Estimating testing projects requires experience on varied projects for the software test life cycle. When you are estimating a testing project, consider −

• Team skills
• Domain Knowledge
• Complexity of the application
• Historical data
• Bug cycles for the project
• Resources availability
• Productivity variations
• System environment and downtime

Testing Estimation Techniques

The following testing estimation techniques are proven to be accurate and are widely used −

• PERT software testing estimation technique
• UCP Method
• WBS
• Wideband Delphi technique
• Function point/Testing point analysis
• Percentage distribution
• Experience-based testing estimation technique

PERT Software Testing Estimation Technique

PERT software testing estimation technique is based on statistical methods in which each testing task is broken down into sub-tasks and then three types of estimation are done on each sub-tasks.

The formula used by this technique is −

Test Estimate = (O + (4 × M) + E)/6

Where,

O = Optimistic estimate (best case scenario in which nothing goes wrong and all conditions are optimal).

M = Most likely estimate (most likely duration and there may be some problem but most of the things will go right).

L = Pessimistic estimate (worst case scenario where everything goes wrong).

Standard Deviation for the technique is calculated as −

Standard Deviation (SD) = (E − O)/6

Use-Case Point Method

UCP Method is based on the use cases where we calculate the unadjusted actor weights and unadjusted use case weights to determine the software testing estimation.

Use-case is a document which specifies different users, systems or other stakeholders interacting with the concerned application. They are named as “Actors”. The interactions accomplish some defined goals protecting the interest of all stakeholders through different behavior or flow termed as scenarios.

Step 1 − Count the no. of actors. Actors include positive, negative and exceptional.

Step 2 − Calculate unadjusted actor weights as

Unadjusted Actor Weights = Total no. of Actors

Step 3 − Count the number of use-cases.

Step 4 − Calculate unadjusted use-case weights as

Unadjusted Use-Case Weights = Total no. of Use-Cases

Step 5 − Calculate unadjusted use-case points as

Unadjusted Use-Case Points = (Unadjusted Actor Weights + Unadjusted Use-Case Weights)

Step 6 − Determine the technical/environmental factor (TEF). If unavailable, take it as 0.50.

Step 7 − Calculate adjusted use-case point as

Adjusted Use-Case Point = Unadjusted Use-Case Points × [0.65 + (0.01 × TEF]

Step 8 − Calculate total effort as

Total Effort = Adjusted Use-Case Point × 2

Work Breakdown Structure

Step 1 − Create WBS by breaking down the test project into small pieces.

Step 2 − Divide modules into sub-modules.

Step 3 Divide sub-modules further into functionalities.

Step 4 − Divide functionalities into sub-functionalities.

Step 5 − Review all the testing requirements to make sure they are added in WBS.

Step 6 − Figure out the number of tasks your team needs to complete.

Step 7 − Estimate the effort for each task.

Step 8 − Estimate the duration of each task.

Wideband Delphi Technique

In Wideband Delphi Method, WBS is distributed to a team comprising of 3-7 members for re-estimating the tasks. The final estimate is the result of the summarized estimates based on the team consensus.

This method speaks more on experience rather than any statistical formula. This method was popularized by Barry Boehm to emphasize on the group iteration to reach a consensus where the team visualized different aspects of the problems while estimating the test effort.

Function Point / Testing Point Analysis

FPs indicate the functionality of software application from the user's perspective and is used as a technique to estimate the size of a software project.

In testing, estimation is based on requirement specification document, or on a previously created prototype of the application. To calculate FP for a project, some major components are required. They are −

• Unadjusted Data Function Points − i) Internal Files, ii) External Interfaces

• Unadjusted Transaction Function Points − i) User Inputs, ii) User Outputs & iii) User Inquiries

• Capers Jones basic formula −

  Number of Test Cases = (Number of Function Points) × 1.2

• Total Actual Effort (TAE) −

  (Number of Test cases) × (Percentage of Development Effort /100)

Percentage Distribution

In this technique, all the phases of Software Development Life Cycle (SDLC) are assigned effort in %. This can be based on past data from similar projects. For example −

Phase	% of Effort
Project Management	7%
Requirements	9%
Design	16%
Coding	26%
Testing (all Test Phases)	27%
Documentation	9%
Installation and Training	6%

Next, % of effort for testing (all test phases) is further distributed for all Testing Phases −

All Testing Phases	% of Effort
Component Testing	16
Independent Testing	84
Total	100

Independent Testing	% of Effort
Integration Testing	24
System Testing	52
Acceptance Testing	24
Total	100

System Testing	% of Effort
Functional System Testing	65
Non-functional System Testing	35
Total	100

Test Planning and Design Architecture	50%
Review phase	50%

Experience-based Testing Estimation Technique

This technique is based on analogies and experts. The technique assumes that you already tested similar applications in previous projects and collected metrics from those projects. You also collected metrics from previous tests. Take inputs from subject matter experts who know the application (as well as testing) very well and use the metrics you have collected and arrive at the testing effort.