Teknik Estimasi - Poin Use-Case

SEBUAH Use-Case adalah rangkaian interaksi terkait antara pengguna dan sistem yang memungkinkan pengguna mencapai suatu tujuan.

Use-Case adalah cara untuk menangkap persyaratan fungsional suatu sistem. Pengguna sistem ini disebut sebagai 'Aktor'. Use-Case pada dasarnya dalam bentuk teks.

Use-Case Points - Definisi

Use-Case Points (UCP)adalah teknik estimasi software yang digunakan untuk mengukur ukuran software dengan use case. Konsep UCP mirip dengan FP.

Jumlah UCP dalam sebuah proyek didasarkan pada:

  • Jumlah dan kompleksitas kasus penggunaan dalam sistem.
  • Jumlah dan kompleksitas pelaku dalam sistem.
    • Berbagai persyaratan non-fungsional (seperti portabilitas, performa, pemeliharaan) yang tidak ditulis sebagai kasus penggunaan.

    • Lingkungan tempat proyek akan dikembangkan (seperti bahasa, motivasi tim, dll.)

Estimasi dengan UCP mengharuskan semua kasus penggunaan ditulis dengan tujuan dan pada tingkat yang kira-kira sama, memberikan jumlah detail yang sama. Oleh karena itu, sebelum estimasi, tim proyek harus memastikan bahwa mereka telah menulis kasus penggunaan mereka dengan tujuan yang ditentukan dan pada tingkat yang terperinci. Kasus penggunaan biasanya diselesaikan dalam satu sesi dan setelah tujuan tercapai, pengguna dapat melanjutkan ke aktivitas lain.

Sejarah Poin Use-Case

Metode estimasi Use-Case Point diperkenalkan oleh Gustav Karner pada tahun 1993. Karya tersebut kemudian dilisensikan oleh Rational Software yang digabungkan ke dalam IBM.

Proses Penghitungan Poin-Kasus Penggunaan

Proses penghitungan Use-Case Points memiliki langkah-langkah berikut -

  • Hitung UCP yang tidak disesuaikan
  • Sesuaikan dengan kerumitan teknis
  • Sesuaikan dengan kompleksitas lingkungan
  • Hitung UCP yang disesuaikan

Langkah 1: Hitung Poin Kasus Penggunaan yang Tidak Disesuaikan.

Anda menghitung Poin Kasus Penggunaan yang Tidak Disesuaikan terlebih dahulu, dengan langkah-langkah berikut -

  • Tentukan Bobot Kasus Penggunaan yang Tidak Disesuaikan
  • Tentukan Bobot Aktor yang Tidak Disesuaikan
  • Hitung Poin Kasus Penggunaan yang Tidak Disesuaikan

Step 1.1 - Tentukan Bobot Kasus Penggunaan yang Tidak Disesuaikan.

Step 1.1.1 - Temukan jumlah transaksi di setiap Use-Case.

Jika Kasus Penggunaan ditulis dengan Tingkat Sasaran Pengguna, transaksi setara dengan langkah dalam Kasus Penggunaan. Temukan jumlah transaksi dengan menghitung langkah-langkah dalam Use-Case.

Step 1.1.2- Klasifikasikan setiap Use-Case sebagai Sederhana, Rata-rata atau Kompleks berdasarkan jumlah transaksi dalam Use-Case. Juga, tetapkan Use-Case Weight seperti yang ditunjukkan pada tabel berikut -

Kompleksitas Kasus Penggunaan Jumlah Transaksi Berat Kasus Penggunaan
Sederhana ≤3 5
Rata-rata 4 sampai 7 10
Kompleks > 7 15

Step 1.1.3- Ulangi untuk setiap Use-Case dan dapatkan semua Use-Case Weight. Use-Case Weight (UUCW) yang tidak disesuaikan adalah jumlah dari semua Bobot Use-Case.

Step 1.1.4 - Temukan Berat Kasus Penggunaan yang Tidak Disesuaikan (UUCW) menggunakan tabel berikut -

Kompleksitas Kasus Penggunaan Berat Kasus Penggunaan Jumlah Kasus Penggunaan Produk
Sederhana 5 NSUC 5 × NSUC
Rata-rata 10 NAUC 10 × NAUC
Kompleks 15 NCUC 15 × NCUC
Unadjusted Use-Case Weight (UUCW) 5 × NSUC + 10 × NAUC + 15 × NCUC

Dimana,

NSUC adalah no. Kasus Penggunaan Sederhana.

NAUC adalah no. Kasus Penggunaan Rata-rata.

NCUC adalah no. Kasus Penggunaan yang Kompleks.

Step 1.2 - Tentukan Bobot Aktor yang Tidak Disesuaikan.

Aktor dalam Use-Case dapat berupa orang, program lain, dll. Beberapa aktor, seperti sistem dengan API yang ditentukan, memiliki kebutuhan yang sangat sederhana dan hanya sedikit meningkatkan kompleksitas Use-Case.

Beberapa aktor, seperti sistem yang berinteraksi melalui protokol memiliki lebih banyak kebutuhan dan meningkatkan kompleksitas Use-Case sampai batas tertentu.

Aktor lain, seperti pengguna yang berinteraksi melalui GUI memiliki dampak signifikan terhadap kompleksitas Use-Case. Berdasarkan perbedaan ini, Anda dapat mengklasifikasikan aktor sebagai Sederhana, Rata-rata, dan Kompleks.

Step 1.2.1 - Klasifikasikan Aktor sebagai Sederhana, Rata-rata dan Kompleks dan tetapkan Bobot Aktor seperti yang ditunjukkan pada tabel berikut -

Kompleksitas Aktor Contoh Bobot Aktor
Sederhana Sistem dengan API yang ditentukan 1
Rata-rata Sistem berinteraksi melalui Protokol 2
Kompleks Seorang Pengguna berinteraksi melalui GUI 3

Step 1.2.2- Ulangi untuk setiap Aktor dan dapatkan semua Bobot Aktor. Bobot Aktor yang Tidak Disesuaikan (UAW) adalah jumlah dari semua Bobot Aktor.

Step 1.2.3 - Temukan Bobot Aktor yang Tidak Disesuaikan (UAW) menggunakan tabel berikut -

Kompleksitas Aktor Bobot Aktor Jumlah Aktor Produk
Sederhana 1 NSA 1 × NSA
Rata-rata 2 NAA 2 × NAA
Kompleks 3 NCA 3 × NCA
Unadjusted Actor Weight (UAW) 1 × NSA + 2 × NAA + 3 × NCA

Dimana,

NSA adalah no. Aktor Sederhana.

NAA adalah no. Aktor Rata-rata.

NCA adalah no. Aktor Kompleks.

Step 1.3 - Hitung Poin Kasus Penggunaan yang Tidak Disesuaikan.

Bobot Kasus Penggunaan yang Tidak Disesuaikan (UUCW) dan Bobot Pelaku yang Tidak Disesuaikan (UAW) bersama-sama memberikan ukuran sistem yang tidak disesuaikan, yang disebut sebagai Poin Kasus Penggunaan yang Tidak Disesuaikan.

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

Langkah selanjutnya adalah menyesuaikan Unadjusted Use-Case Points (UUCP) untuk Technical Complexity dan Environmental Complexity.

Langkah 2: Sesuaikan Untuk Kompleksitas Teknis

Step 2.1 - Pertimbangkan 13 Faktor yang berkontribusi terhadap dampak Kompleksitas Teknis suatu proyek pada Poin Kasus Penggunaan dan Bobotnya yang sesuai seperti yang diberikan dalam tabel berikut -

Faktor Deskripsi Bobot
T1 Sistem Terdistribusi 2.0
T2 Waktu respons atau tujuan kinerja throughput 1.0
T3 Efisiensi pengguna akhir 1.0
T4 Pemrosesan internal yang kompleks 1.0
T5 Kode harus dapat digunakan kembali 1.0
T6 Mudah dipasang 0,5
T7 Mudah digunakan 0,5
T8 Portabel 2.0
T9 Mudah diubah 1.0
T10 Bersamaan 1.0
T11 Termasuk tujuan keamanan khusus 1.0
T12 Memberikan akses langsung untuk pihak ketiga 1.0
T13 Fasilitas pelatihan pengguna khusus diperlukan 1.0

Banyak dari faktor-faktor ini mewakili kebutuhan nonfungsional proyek.

Step 2.2 - Untuk masing-masing dari 13 Faktor, nilai proyek dan nilai dari 0 (tidak relevan) hingga 5 (sangat penting).

Step 2.3 - Hitung Dampak Faktor dari Bobot Dampak Faktor dan Nilai Nilai untuk proyek sebagai

Impact of the Factor = Impact Weight × Rated Value

Step (2.4)- Hitung jumlah Dampak dari semua Faktor. Ini memberikan Total Technical Factor (TFactor) seperti yang diberikan pada tabel di bawah -

Faktor Deskripsi Berat (W) Nilai Nilai (0 hingga 5) (RV) Dampak (I = W × RV)
T1 Sistem Terdistribusi 2.0
T2 Waktu respons atau tujuan kinerja throughput 1.0
T3 Efisiensi pengguna akhir 1.0
T4 Pemrosesan internal yang kompleks 1.0
T5 Kode harus dapat digunakan kembali 1.0
T6 Mudah dipasang 0,5
T7 Mudah digunakan 0,5
T8 Portabel 2.0
T9 Mudah diubah 1.0
T10 Bersamaan 1.0
T11 Termasuk tujuan keamanan khusus 1.0
T12 Memberikan akses langsung untuk pihak ketiga 1.0
T13 Fasilitas pelatihan pengguna khusus diperlukan 1.0
Total Technical Factor (TFactor)

Step 2.5 - Hitung Faktor Kompleksitas Teknis (TCF) sebagai -

TCF = 0.6 + (0.01 × TFactor)

Langkah 3: Sesuaikan Untuk Kompleksitas Lingkungan

Step 3.1 - Pertimbangkan 8 Faktor Lingkungan yang dapat mempengaruhi pelaksanaan proyek dan Bobotnya yang sesuai seperti yang diberikan dalam tabel berikut -

Faktor Deskripsi Bobot
F1 Akrab dengan model proyek yang digunakan 1.5
F2 Pengalaman aplikasi 0,5
F3 Pengalaman berorientasi objek 1.0
F4 Kemampuan analis utama 0,5
F5 Motivasi 1.0
F6 Persyaratan yang stabil 2.0
F7 Staf paruh waktu -1.0
F8 Bahasa pemrograman yang sulit -1.0

Step 3.2 - Untuk masing-masing dari 8 Faktor, nilai proyek dan nilai dari 0 (tidak relevan) sampai 5 (sangat penting).

Step 3.3 - Hitung Dampak Faktor dari Bobot Dampak Faktor dan Nilai Nilai untuk proyek sebagai

Impact of the Factor = Impact Weight × Rated Value

Step 3.4- Hitung jumlah Dampak dari semua Faktor. Ini memberikan Faktor Lingkungan Total (EFactor) seperti yang diberikan dalam tabel berikut -

Faktor Deskripsi Berat (W) Nilai Nilai (0 hingga 5) (RV) Dampak (I = W × RV)
F1 Akrab dengan model proyek yang digunakan 1.5
F2 Pengalaman aplikasi 0,5
F3 Pengalaman berorientasi objek 1.0
F4 Kemampuan analis utama 0,5
F5 Motivasi 1.0
F6 Persyaratan yang stabil 2.0
F7 Staf paruh waktu -1.0
F8 Bahasa pemrograman yang sulit -1.0
Total Environment Factor (EFactor)

Step 3.5 - Hitung Faktor Lingkungan (EF) sebagai -

1.4 + (-0.03 × EFactor)

Langkah 4: Hitung Titik Kasus Penggunaan yang Disesuaikan (UCP)

Hitung Titik Kasus Penggunaan yang Disesuaikan (UCP) sebagai -

UCP = UUCP × TCF × EF

Keuntungan dan Kerugian dari Use-Case Points

Keuntungan dari Use-Case Points

  • UCP didasarkan pada kasus penggunaan dan dapat diukur di awal siklus hidup proyek.

  • UCP (perkiraan ukuran) tidak bergantung pada ukuran, keterampilan, dan pengalaman tim yang melaksanakan proyek.

  • Estimasi berbasis UCP ditemukan mendekati aktual ketika estimasi dilakukan oleh orang yang berpengalaman.

  • UCP mudah digunakan dan tidak memerlukan analisis tambahan.

  • Kasus penggunaan digunakan secara luas sebagai metode pilihan untuk mendeskripsikan persyaratan. Dalam kasus seperti itu, UCP adalah teknik estimasi yang paling sesuai.

Kerugian dari Use-Case Points

  • UCP hanya dapat digunakan jika persyaratan ditulis dalam bentuk use case.

  • Bergantung pada kasus penggunaan yang berorientasi pada tujuan dan ditulis dengan baik. Jika kasus penggunaan tidak terstruktur dengan baik atau seragam, UCP yang dihasilkan mungkin tidak akurat.

  • Faktor teknis dan lingkungan berdampak tinggi pada UCP. Perhatian perlu diberikan saat menetapkan nilai pada faktor teknis dan lingkungan.

  • UCP berguna untuk perkiraan awal dari keseluruhan ukuran proyek tetapi mereka jauh kurang berguna dalam mendorong pekerjaan iterasi-ke-iterasi dari sebuah tim.