Menghitung Estimasi Pengembangan Software dengan Use Case Points
Pernahkah Brainers menerima beberapa penawaran pengembangan software dengan selisih harga yang cukup jauh, padahal kebutuhan sistem yang diajukan sama?
Perbedaan tersebut tidak selalu terjadi karena vendor yang berbeda. Penyebab utamanya ada pada cara menghitung effort, durasi, jumlah tim, dan tingkat kompleksitas sistem yang akan dikembangkan.
Tanpa metode estimasi yang terstandarisasi, angka biaya pengembangan software bisa terlihat meyakinkan, tetapi sulit ditelusuri dasar perhitungannya. Di sinilah Software Effort Estimation menjadi penting, terutama pada tahap planning dan feasibility analysis.
Metode Estimasi Berbasis Use Case Diagram
Use Case Points atau UCP adalah salah satu metode estimasi software effort yang digunakan untuk menghitung ukuran dan kompleksitas sistem berdasarkan use case dan aktor yang terlibat di dalamnya. Metode ini diperkenalkan oleh Gustav Karner pada tahun 1993.
Berbeda dengan estimasi yang hanya mengandalkan pengalaman proyek sebelumnya, Use Case Points menggunakan model yang sudah terdokumentasi dalam Use Case Diagram. Artinya, perhitungan estimasi tidak hanya berdasarkan asumsi, tetapi berasal dari gambaran kebutuhan sistem yang telah dianalisis.
Karena berbasis model, hasil estimasi menjadi lebih mudah dijelaskan dan dipertanggungjawabkan. Sparx Enterprise Architect dapat menghitung UCP dari diagram yang telah dibuat, lalu digunakan sebagai dasar untuk memperkirakan effort, waktu pengerjaan, hingga kebutuhan biaya.
Perbedaan Function Points dan Use Case Points
Dalam Software Effort Estimation, beberapa pendekatan yang umum digunakan yaitu: Cycle Distribution, Function Points, dan Use Case Points.
Function Points mengukur ukuran software berdasarkan fungsi data dan transaksi yang dimiliki sistem. Pendekatan ini biasanya digunakan untuk melihat kompleksitas dari sisi input, output, query, file, dan interface yang terlibat dalam aplikasi.
Sementara itu, Use Case Points mengukur ukuran software berdasarkan jumlah serta kompleksitas use case dan aktor dalam Use Case Diagram. Karena itu, metode ini sangat relevan digunakan ketika tim sudah melakukan use case modeling pada tahap Systems Analysis & Design.
Dari Use Case Menjadi Estimasi Effort dan Biaya Pengembangan
Setiap aktor dan use case diklasifikasikan berdasarkan tingkat kompleksitasnya, seperti sederhana, sedang, atau kompleks. Hasil klasifikasi tersebut digunakan untuk menghitung nilai Unadjusted Use Case Points atau UUCP, lalu disesuaikan dengan faktor teknis dan lingkungan proyek hingga menghasilkan nilai akhir Use Case Points atau UCP.
Nilai UCP kemudian dapat dikonversi menjadi estimasi usaha pengembangan menggunakan Person Hour Multiplier atau PHM. Sebagai contoh: sistem MusicPedia memiliki 92 UCP dan menggunakan PHM 20, maka estimasi jam kerja yang dibutuhkan adalah:
92 UCP × 20 jam = 1.840 jam kerja
Dari total jam kerja tersebut, tim dapat menghitung kebutuhan Person-Month, durasi pengerjaan, hingga estimasi biaya pengembangan. Jika digunakan asumsi 8 jam kerja per hari dan 22 hari kerja per bulan, maka 1.840 jam kerja setara dengan sekitar 10,45 Person-Month.
Selanjutnya, biaya developer dapat dihitung berdasarkan tarif rata-rata yang berlaku. Sebagai acuan, INKINDO 2026 menetapkan billing rate Tenaga Ahli S1 dengan pengalaman 5 tahun sebesar Rp 32.300.000 per bulan untuk benchmark DKI Jakarta. Tabel berikut menampilkan estimasi durasi dan biaya developer untuk empat skenario PHM dan beban kerja:
| PHM | Person Hours | Lama Kerja/Hari | Hari Kerja/Bulan | Person-Month | Estimasi Waktu (Bulan) | Estimasi Biaya Developer |
| 20 | 1.840 | 8 jam | 22 hari | 10,45 | 6,56 | Rp 337.535.000 |
| 20 | 1.840 | 10 jam | 26 hari | 7,08 | 5,76 | Rp 228.684.000 |
| 28 | 2.576 | 8 jam | 22 hari | 14,64 | 7,34 | Rp 472.872.000 |
| 28 | 2.576 | 10 jam | 26 hari | 9,91 | 6,44 | Rp 320.093.000 |
Dari tabel tersebut, terlihat bahwa PHM yang lebih tinggi menghasilkan Person Hours yang lebih besar karena mencerminkan kompleksitas proyek atau kebutuhan tenaga kerja yang lebih besar. Sementara itu, jam kerja dan hari kerja yang lebih padat dapat mempersingkat durasi proyek, tetapi tidak mengurangi total effort yang dibutuhkan.
Dari Effort Menjadi Anggaran Proyek Software
Estimasi pada tabel sebelumnya menggunakan tarif blended tunggal untuk developer. Cara ini praktis di tahap feasibility analysis, tetapi tidak cukup untuk proposal anggaran resmi. Proyek pengembangan software di dunia nyata membutuhkan peran pendukung seperti Project Manager, Business Analyst, UI/UX Designer, dan QA Engineer, masing-masing dengan alokasi waktu dan tarif yang berbeda.
Komposisi Tim dan Tarif per Peran (INKINDO 2026)
Tabel berikut menyajikan komposisi tim yang realistis untuk studi kasus MusicPedia (92 UCP, durasi 6,56 bulan)
| Peran | Kualifikasi INKINDO | Alokasi | Person-Month | Tarif per PM | Subtotal |
| Senior Developer | Ahli Madya S1, 7 tahun | 40% dari developer effort | 4,2 | Rp 35.700.000 | Rp 149.940.000 |
| Mid Developer | Ahli Muda S1, 3 tahun | 60% dari developer effort | 6,3 | Rp 28.850.000 | Rp 181.755.000 |
| Subtotal Developer | 10,5 | Rp 331.695.000 | |||
| Project Manager | Ahli Madya S1, 5 tahun | 30% sepanjang proyek | 2,0 | Rp 32.300.000 | Rp 64.600.000 |
| Business Analyst | Ahli Muda S1, 3 tahun | Fase analisis & desain | 1,5 | Rp 28.850.000 | Rp 43.275.000 |
| UI/UX Designer | Ahli Muda S1, 3 tahun | Fase desain & iterasi | 1,2 | Rp 28.850.000 | Rp 34.620.000 |
| QA Engineer | Ahli Muda S1, 3 tahun | Fase pengujian & UAT | 2,0 | Rp 28.850.000 | Rp 57.700.000 |
| Subtotal Tim Pendukung | 6,7 | Rp 200.195.000 | |||
| TOTAL ANGGARAN PROYEK | 17,2 | Rp 531.890.000 |
Total anggaran sebesar Rp 531.890.000 hampir 60% lebih tinggi dibandingkan estimasi biaya developer murni pada tabel sebelumnya (Rp 337.535.000). Selisih ini merupakan biaya peran pendukung yang sering luput dari estimasi awal dan menjadi penyebab proyek software tampak murah di tahap penawaran, tetapi membengkak saat eksekusi.
Tiga Catatan Praktis Menyusun Anggaran Proyek
- Alokasi developer effort (40% Senior dan 60% Mid pada contoh ini) bergantung pada kompleksitas teknis proyek. Sistem dengan banyak legacy integration atau high-traffic biasanya membutuhkan porsi Senior yang lebih besar, sekitar 50% sampai 70%.
- Tarif INKINDO sudah mencakup gaji dasar, PPh-21, social cost, overhead, dan profit. Tarif ini cocok dipakai sebagai acuan billing rate konsultansi atau penyusunan HPS proyek pemerintah. Untuk proyek in-house, tarif dapat disesuaikan dengan struktur biaya internal organisasi.
- Cadangan risiko (contingency) sebesar 10% sampai 15% dari total anggaran perlu ditambahkan untuk menutup perubahan scope, perpanjangan UAT, atau perbaikan bug setelah launch. Dengan contingency 10%, anggaran akhir MusicPedia menjadi sekitar Rp 585.000.000.
Siap Menghitung Biaya Software dengan Use Case Points?
Use Case Points membuat estimasi biaya software berangkat dari use case diagram yang sudah dianalisis, bukan dari pengalaman proyek lain yang belum tentu sebanding. Akurasi metode ini bergantung langsung pada kualitas use case diagram yang dibuat sejak tahap requirement gathering.
Use case yang ditulis terlalu umum atau tidak konsisten akan membuat penilaian kompleksitas menjadi bias. Penilaian TCF dan ECF yang tidak objektif juga bisa membuat dua proyek dengan kompleksitas berbeda menghasilkan nilai UCP yang terlihat mirip. Karena itu, UCP membutuhkan pemahaman analisis sistem yang baik, mulai dari pemodelan requirement, penyusunan use case diagram, hingga interpretasi hasil estimasi.
Begitu Brainers memahami cara menghitung UUCP, TCF, ECF, hingga konversi ke Person-Month dan durasi proyek, negosiasi dengan vendor mana pun menjadi lebih setara. Anggaran proyek software Brainers layak ditentukan oleh hitungan, bukan oleh tebakan.
Bergabunglah pada course Systems Analysis & Design Fundamentals. Brainmatics membantu Brainers memahami siklus pengembangan software melalui pendekatan praktis, mulai dari Planning, Analysis & Design (Use Case Modeling) menggunakan Sparx Enterprise Architect, hingga implementasi Software Code yang terdokumentasi, dan selaras dengan kebutuhan organisasi.
Hubungi Learning Advisors Brainmatics untuk konsultasi mengenai jadwal dan detail course.
Referensi & Sumber Data
- Albrecht, A. J. (1979). Measuring Application Development Productivity. IBM Corporation.
- Karner, G. (1993). Resource Estimation for Objectory Projects. Objectory Systems AB.
Cockburn, A. (2001). Estimating With Use Case Points. Mountain Goat Software. - Jones, C. (2012). Software Engineering Best Practices. McGraw-Hill.
- Romi Satria Wahono. (2020). Software Effort Estimation: Supaya Ga Ngarang Lagi, Ngitung Waktu dan Biaya Pengembangan Software!. YouTube.
- Sparx Systems. (2024). Project Estimation using Use Case Metrics.
- Ikatan Nasional Konsultan Indonesia. (2026). Pedoman Standar Minimal Tahun 2026: Remunerasi (Biaya Personil/Billing Rate) dan Biaya Langsung (Direct Cost) untuk Badan Usaha Jasa Konsultansi. INKINDO.
