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.