Mengukur Produktivitas Dalam
Pengembangan Perangkat
Lunak
Produktivitas dalam pengembangan perangkat lunak adalah
faktor kunci dalam menentukan efisiensi dan keberhasilan proyek.
Produktivitas ini dapat di ukur dengan rumus :
Berikut adalah beberapa metode umum yang digunakan untuk
mengukur produktivitas dalam pengembangan perangkat lunak:
- Lines of Code (LOC)
- Function Points
- Story Points
- Velocity
- Cycle Time
- Defect Density
- Customer Satisfaction
- Earned Value Management (EVM)
A.
Lines of Code (LOC)
Lines
of Code atau LoC adalah metode yang digunakan untuk mengukur ukuran suatu
aplikasi dengan mengidentifikasi jumlah aktual Lines of Code yang dimilikinya.
Misalnya, proyek perangkat lunak kecil biasanya memiliki antara 500 hingga 5000
Baris Kode, sedangkan proyek perangkat lunak besar dapat memiliki ribuan atau
bahkan jutaan Baris Kode (LoC).
Misalkan
Anda memiliki tim pengembangan yang bekerja pada proyek pengembangan perangkat
lunak selama satu minggu. Berikut adalah jumlah baris kode yang ditulis oleh
setiap anggota tim:
·
Developer A: Menulis
1000 baris kode
·
Developer B: Menulis
800 baris kode
·
Developer C: Menulis
1200 baris kode
·
Developer D: Menulis
900 baris kode
Total
baris kode yang ditulis oleh tim dalam satu minggu adalah:
1000+800+1200+900=3900
baris kode
Jadi,
rata-rata produktivitas per minggu adalah:
Ini
adalah contoh sederhana menggunakan LOC sebagai metrik untuk mengukur
produktivitas. Namun, perlu diingat bahwa LOC tidak selalu menjadi indikator
produktivitas yang akurat karena tidak memperhitungkan kualitas kode,
kompleksitas tugas, atau efisiensi pengembangan. Oleh karena itu, penting untuk
menggunakan metrik tambahan dan konteks proyek secara menyeluruh saat
mengevaluasi produktivitas tim pengembangan perangkat lunak.
Metode
yang Digunakan untuk Mengukur LoC
Ada
dua metode yang umum digunakan untuk mengukur parameter ini yaitu; metode fisik
dan logis. Beginilah cara keduanya menunda
1.
Baris Kode Fisik:
Dengan
metode ini, baris kode dihitung secara fisik tanpa menyertakan komentar dan
spasi.
2.
Baris Kode Logis:
Metode
ini hanya mengukur jumlah pernyataan yang dapat dieksekusi dalam kode.
Mari
kita gunakan contoh di bawah ini untuk membedakan keduanya;
for (i = 0; i< 100; i++)
{
printf("hello");
}
Dalam
ilustrasi di atas kode ini, segmen memiliki empat baris kode fisik dan dua
baris kode logis. Baris kode yang logis adalah; pernyataan for dan pernyataan print.
B.
Function Points
Metode
ini mengukur produktivitas berdasarkan pada kompleksitas fungsional perangkat
lunak. Ini memperhitungkan faktor seperti jumlah input dan output yang diproses
oleh sistem, jumlah antarmuka pengguna, dan sebagainya.
Metode
ini biasanya menggunakan data pada proyek sebelumnya, Function Point dapat
digunakan untuk:
ü Memperkirakan biaya atau usaha yang diperlukan dalam tahap
perancangan, coding, maupun pengujian.
ü Memperkirakan jumlah error yang ditemui pada saat pengujian
ü Memperkirakan jumlah komponen atau sumber baris pada tahap
implementasi
Function
Point diturunkan dari hubungan empiris antara Informasi domain perangkat lunak
yang dapat diukur secara langsung dengan ukuran kualitatif kompleksitas
perangkat lunak. Berikut ini adalah nilai domain Informasi yang harus
didefinisikan dalam menentukan function point sebuah perangkat lunak:
1.
Jumlah input eksternal
(External Input – EIs). Input
berasal dari luar sistem, baik dari user maupun sistem lainnya yang selanjutnya
digunakan untuk mengupdate Internal Logical Files.
2.
Jumlah output eksternal
(External Output – EOs). Output
merupakan data yang ditampilkan pada aplikasi untuk menyediakan Informasi
kepada user, baik dalam bentuk laporan, tampilan di layar, pesan error, dst.
3.
Jumlah inquiries
eksternal (External Inquiries – EQs).
Inquiries eksternal didefinisikan sebagai input online yang memicu respon dari
software untuk menghasilkan output online.
4.
Jumlah file logikal
internal (Internal Logical Files – ILFs).
File logika internal merupakan data yang dikelompokkan secara logis , disimpan
secara internal dan didapat dari input eksternal.
5.
Jumlah file interface
eksternal (External Interface Files –
EIFs). Merupakan data yang dikelompokkan secara logis namun berada diluar
aplikasi yang menyediakan Informasi yang dibutuhkan aplikasi.
Sedangkan ukuran kualitatif
kompleksitas perangkat lunak ditentukan dari 14 faktor nilai penyesuaian (Value
Adjustment Factor) sebagai berikut:
|
ik Sistem
|
Keterangan
|
|
1.
|
Data communications
|
Berapa banyak fasilitas komunikasi
yang digunakan untuk membantu pengiriman atau pertukaran Informasi dengan
aplikasi?
|
|
2.
|
Distributed data processing
|
Bagaimana cara menangani data yang
terdistribusi dan fungsi pemrosesannya?
|
|
3.
|
Performance
|
Berapa waktu tanggapan dari sistem
atau keluaran yang dibutuhkan oleh user?
|
|
4.
|
Heavily used configuration
|
Seberapa berat platform hardware
digunakan yang merupakan lokasi eksekusi dari aplikasi?
|
|
5.
|
Transaction rate
|
Seberapa sering transaksi dieksekusi
setiap hari, minggu, bulan, dst?
|
|
6.
|
On-Line data entry
|
Berapa persen Informasi yang
dimasukan secara online?
|
|
7.
|
End-user efficiency
|
Apakah aplikasi dirancang untuk
efisiensi end-user?
|
|
8.
|
On-Line update
|
Berapa banyak ILF di update melalui
transaksi online?
|
|
9.
|
Complex processing
|
Apakah aplikasi memiliki logika yang
luas atau pemrosesan matematika?
|
|
10.
|
Reusability
|
Apakah aplikasi dikembangkan untuk
memenuhi satu atau banyak kebutuhan?
|
|
11.
|
Installation ease
|
Seberapa sulit konversi dan
instalasi?
|
|
12.
|
Operational ease
|
Seberapa efektif atau
terotomatisasinya aplikasi pada saat start-up, back-up, dan prosedur
recovery?
|
|
13.
|
Multiple sites
|
Apakah aplikasi dirancang,
dikembangkan, dan didukung khusus untuk diinstal pada banyak site/perusahaan?
|
|
14.
|
Facilitate change
|
Apakah aplikasi dirancang,
dikembangkan, dan didukung khusus untuk memfasilitasi perubahan?
|
Perhitungan akhir Function Point (FP) dilakukan
dengan rumus berikut:
FP = count total x [0.65 x 0.01 ∑(Fi)]
· FP: Function Point yang akan
dihitung
· Count total: total kelima nilai domain
Informasi yang telah dilengkapi dengan nilai kompleksitas (sederhana,
rata-rata, atau kompleks). Penentuan kriteria kompleksitas setiap domain masih
bersifat subyektif. Berikut adalah contoh perhitungan count total.
· ∑(Fi ): total 14 nilai faktor penyesuaian.
C.
Story Points
Metode
Agile yang umum digunakan, di mana tim mengukur kompleksitas relatif dari
tugas-tugas (atau "cerita-cerita") dalam skala poin. Produktivitas
diukur berdasarkan pada seberapa banyak cerita yang diselesaikan dalam iterasi
tertentu.
Misalkan
sebuah tim pengembangan perangkat lunak memiliki dua cerita untuk dikerjakan
dalam iterasi berikutnya:
- Cerita
A: Membuat halaman pendaftaran pengguna yang sederhana, hanya meminta nama
pengguna, alamat email, dan password. Tidak ada validasi yang rumit, tidak ada
integrasi dengan layanan lain. Diperkirakan akan membutuhkan waktu sekitar 2
hari kerja bagi seorang pengembang untuk menyelesaikan cerita ini.
- Cerita
B: Mengimplementasikan fitur pencarian yang canggih dalam aplikasi. Ini
melibatkan penggunaan algoritma pencarian yang kompleks, integrasi dengan basis
data yang besar, dan antarmuka pengguna yang interaktif. Diperkirakan akan
membutuhkan waktu sekitar 1 minggu kerja bagi seorang pengembang berpengalaman
untuk menyelesaikan cerita ini.
Dalam
metode Story Points, tim akan membandingkan cerita-cerita ini secara relatif
terhadap satu sama lain untuk menentukan kompleksitasnya. Misalnya, tim dapat
menentukan bahwa Cerita A memiliki tingkat kompleksitas yang rendah, sementara
Cerita B memiliki tingkat kompleksitas yang tinggi.
Misalkan
tim memutuskan untuk memberikan nilai sebagai berikut:
Cerita
A: 3 Story Points
Cerita
B: 8 Story Points
Artinya,
Cerita B dianggap lebih kompleks daripada Cerita A, sehingga memiliki nilai
Story Points yang lebih tinggi.
Dengan
menggunakan Story Points, tim dapat memperkirakan seberapa banyak pekerjaan
yang dapat diselesaikan dalam satu iterasi pengembangan, serta mengukur
produktivitas tim dari iterasi ke iterasi.
D.
Velocity
Velocity
Ini adalah metrik yang digunakan dalam pengembangan perangkat lunak Agile. Ini
mengukur jumlah kerja yang diselesaikan oleh tim dalam satu iterasi
pengembangan. Ini sering diukur dalam bentuk jumlah cerita atau poin cerita
yang selesai dalam satu iterasi yang biasanya disebut sebagai sprint. Ini
diukur dalam satuan poin cerita atau cerita yang selesai dalam satu iterasi.
Misalkan
sebuah tim pengembangan menggunakan poin cerita untuk mengukur ukuran
pekerjaan. Mereka memiliki sprint selama dua minggu dan berhasil menyelesaikan
cerita-cerita berikut:
Sprint
1: 8 cerita
Sprint
2: 7 cerita
Sprint
3: 9 cerita
Dalam
hal ini, total cerita yang diselesaikan dalam tiga sprint adalah 8 + 7 + 9 = 24
cerita. Oleh karena itu, rata-rata velocity tim untuk sprint-sprint ini adalah
24 cerita / 3 sprint = 8 cerita per sprint.
Velocity
ini memberikan perkiraan kepada tim pengembangan dan pemangku kepentingan
lainnya tentang seberapa banyak pekerjaan yang dapat mereka lakukan dalam satu
iterasi pengembangan. Dengan menggunakan velocity ini, tim dapat merencanakan
sprint berikutnya dengan lebih baik dan membuat perkiraan waktu yang lebih
akurat untuk menyelesaikan fitur-fitur atau tugas-tugas berikutnya.
E.
Cycle Time
Cycle
Time Ini mengukur waktu yang dibutuhkan untuk menyelesaikan satu tugas atau
cerita dari awal hingga akhir. Semakin pendek siklus waktu, semakin produktif
tim tersebut.
Misalkan
Anda memiliki tim pengembangan perangkat lunak yang menggunakan metodologi
Agile untuk mengembangkan aplikasi web. Tim ini bekerja dalam iterasi dua
mingguan, atau sprint.
Dalam
sprint pertama, tim memulai beberapa tugas atau cerita, termasuk
mengimplementasikan fitur login, membuat halaman profil pengguna, dan
memperbaiki bug tertentu. Setiap cerita memiliki estimasi waktu yang diestimasi
oleh tim, misalnya, fitur login diperkirakan membutuhkan sekitar 5 hari kerja,
pembuatan halaman profil pengguna diperkirakan membutuhkan 3 hari kerja, dan
perbaikan bug diperkirakan membutuhkan 2 hari kerja.
Pada
akhir dua minggu sprint, tim berhasil menyelesaikan semua tugas yang
direncanakan. Cycle Time untuk masing-masing tugas dihitung sebagai berikut:
Ø Fitur
Login: Tugas ini mulai pada hari pertama sprint dan selesai pada hari ke-5.
Cycle Time-nya adalah 5 hari.
Ø Halaman
Profil Pengguna: Tugas ini dimulai pada hari ke-2 sprint dan selesai pada hari
ke-4. Cycle Time-nya adalah 3 hari.
Ø Perbaikan
Bug: Tugas ini dimulai pada hari ke-3 sprint dan selesai pada hari ke-4. Cycle
Time-nya adalah 2 hari.
Jadi, untuk sprint tersebut, rata-rata Cycle
Time untuk setiap tugas adalah:
Misalkan Total Cycle Time Tugas adalah 5 + 3 +
2 = 10 hari, dan Jumlah Tugas adalah 3.
Dengan demikian, rata-rata Cycle Time untuk
sprint tersebut adalah sekitar 3,33 hari per tugas. Ini memberikan gambaran
kepada tim tentang seberapa efisien mereka dalam menyelesaikan tugas-tugas
dalam sprint tersebut. Tujuan selanjutnya bisa menjadi untuk mengurangi
rata-rata Cycle Time dalam sprint berikutnya.
F.
Defect Density
Defect Density mengukur jumlah bug atau cacat
per unit kode. Berikut adalah contoh bagaimana Defect Density dapat dihitung
dalam konteks pengembangan perangkat lunak:
Misalkan Anda memiliki proyek pengembangan
perangkat lunak di mana tim Anda telah menyelesaikan fase pengujian pada
aplikasi baru yang dikembangkan. Selama pengujian, tim menemukan total 25 bug
dalam kode yang telah ditulis.
Selanjutnya, kode yang diuji terdiri dari total
10.000 baris kode. Defect Density dapat dihitung sebagai berikut:
Dalam kasus ini:
Jumlah Bug = 25
Jumlah Baris Kode = 10.000
Jadi, Defect Density untuk proyek ini adalah
0,0025 bug per baris kode.
Defect Density memberikan gambaran tentang
seberapa baik kode perangkat lunak Anda berfungsi, dan semakin rendah nilai
Defect Density, semakin sedikit bug yang ditemukan per unit kode. Tujuan
utamanya adalah untuk meminimalkan Defect Density selama pengembangan perangkat
lunak untuk meningkatkan kualitas produk yang dihasilkan.
G. Defect Density
Berikut adalah contoh bagaimana Anda dapat
mengukur kepuasan pelanggan dalam konteks pengembangan perangkat lunak:
Misalkan Anda telah meluncurkan aplikasi baru
yang dikembangkan oleh tim Anda. Untuk mengukur kepuasan pelanggan, Anda dapat
menggunakan beberapa metode:
Survei Kepuasan Pelanggan: Anda dapat
mengirimkan survei kepada pengguna untuk menilai pengalaman mereka dengan
menggunakan aplikasi. Pertanyaan dapat mencakup kegunaan, kinerja, keandalan,
dan kepuasan secara umum.
Review Pengguna: Melacak ulasan dan rating
aplikasi di toko aplikasi (seperti Google Play Store atau Apple App Store)
dapat memberikan gambaran tentang kepuasan pengguna secara keseluruhan. Anda
dapat memantau komentar pengguna untuk mendapatkan wawasan tentang area mana
yang memerlukan perbaikan.
Interaksi Langsung: Berkomunikasi langsung
dengan pelanggan melalui email, obrolan langsung, atau forum pengguna dapat
membantu Anda mendapatkan umpan balik yang lebih mendalam tentang kebutuhan dan
masalah mereka.
Misalkan setelah peluncuran aplikasi Anda, Anda
mengumpulkan umpan balik dari 100 pengguna melalui survei kepuasan pelanggan.
Dari survei tersebut, Anda menemukan bahwa 80% pengguna memberikan penilaian
positif terhadap aplikasi dan 20% memberikan umpan balik negatif.
Dengan
demikian, Customer Satisfaction Rate (CSR) Anda dapat dihitung sebagai berikut:
Jadi,
Customer Satisfaction Rate (CSR) untuk aplikasi Anda adalah 80%. Ini
menunjukkan bahwa mayoritas pengguna puas dengan aplikasi, tetapi masih ada
ruang untuk perbaikan berdasarkan umpan balik dari pengguna yang tidak puas.
Dengan memantau dan merespons umpan balik pelanggan dengan baik, Anda dapat
terus meningkatkan kepuasan pelanggan dan kualitas produk Anda.
H.
Earned Value Management (EVM)
Mari
kita jelaskan dengan contoh bagaimana Earned Value Management (EVM) dapat
diterapkan dalam proyek pengembangan perangkat lunak:
Misalkan
Anda memiliki proyek pengembangan perangkat lunak untuk membangun platform
e-commerce baru. Proyek ini memiliki anggaran total $100.000 dan dijadwalkan
akan diselesaikan dalam waktu 6 bulan.
Setelah
3 bulan berlalu, Anda ingin menggunakan EVM untuk mengevaluasi kinerja proyek.
Berikut adalah data yang Anda miliki:
Planned
Value (PV): Ini adalah nilai pekerjaan yang dijadwalkan diselesaikan pada titik
waktu tertentu berdasarkan pada anggaran. Dalam proyek Anda, setelah 3 bulan,
PV diharapkan sebesar $50.000, karena setengah dari anggaran sudah dialokasikan
untuk fase pertama proyek.
Actual
Cost (AC): Ini adalah biaya aktual yang telah dikeluarkan untuk proyek pada
titik waktu tertentu. Setelah 3 bulan, AC Anda adalah $40.000.
Earned
Value (EV): Ini adalah nilai pekerjaan yang sebenarnya telah diselesaikan pada
titik waktu tertentu berdasarkan pada anggaran. Dalam proyek Anda, setelah 3
bulan, Anda menilai bahwa hanya 40% dari pekerjaan yang direncanakan telah
selesai, sehingga EV adalah $40.000.
Dengan
data ini, Anda dapat menghitung beberapa metrik kunci EVM:
ü Cost Performance Index (CPI): Ini
mengukur efisiensi biaya proyek sampai saat ini. Ini dihitung sebagai rasio
antara Earned Value (EV) dan Actual Cost (AC).
ü Schedule Performance Index (SPI): Ini
mengukur efisiensi waktu proyek sampai saat ini. Ini dihitung sebagai rasio
antara Earned Value (EV) dan Planned Value (PV).
Dalam contoh ini:
CPI = 1 menunjukkan bahwa Anda
menghabiskan uang sebanyak yang diharapkan untuk mencapai tingkat pekerjaan
yang telah diselesaikan.
SPI = 0,8 menunjukkan bahwa
Anda sedikit tertinggal dari jadwal yang diharapkan.
Berdasarkan metrik CPI dan
SPI, Anda dapat mengevaluasi kinerja proyek Anda dan mengambil tindakan yang
diperlukan, seperti mengatur ulang jadwal atau mengelola biaya dengan lebih
efektif, untuk memastikan bahwa proyek berjalan sesuai rencana.
