Terkadang, kami ditanya pertanyaan, nilai uang apa yang akan diterima perusahaan dari menggunakan PVS-Studio. Kami memutuskan untuk menyusun respons dalam bentuk artikel dan menyediakan tabel, yang akan menunjukkan bagaimana penganalisa dapat bermanfaat. Kami tidak dapat membuktikan keakuratan absolut dari semua perhitungan dalam artikel, tetapi kami menganggap pembaca akan setuju dengan pemikiran kami, dan itu akan membantu untuk membuat keputusan dalam hal mendapatkan lisensi.
Pertama kami ingin menerapkan ROI-Calculator di situs dan memposting deskripsi rinci tentang prinsip kerjanya. Namun, setelah menyiapkan deskripsi, menjadi jelas bahwa kalkulator tidak perlu. Tabel yang diberikan dalam deskripsi sudah cukup. Jadi kami baru saja membuat penjelasan ini sebagai artikel yang sedang Anda baca sekarang. Semoga ini akan membantu Anda sepenuhnya menyadari rasionalitas penggunaan reguler alat analisa kode statis PVS-Studio.
PVS-Studio adalah alat yang dirancang untuk mendeteksi kesalahan dan potensi kerentanan dalam kode sumber program, ditulis dalam C, C ++, C # dan Java. Ini bekerja di lingkungan Windows, Linux dan macOS.
Mari kita hitung pengembalian investasi dari menggunakan penganalisa kode statis PVS-Studio selama pengembangan - pertama dalam "mode skeptis", dan kemudian lebih realistis.
Nilai jam kerja pengembang
Untuk menentukan berapa banyak uang yang akan dikembalikan oleh PVS-Studio, pertama-tama kita perlu menghitung berapa biaya (nilai) sebenarnya dari jam kerja pengembang.
Faktanya adalah bahwa tidak cukup hanya dengan mengambil gaji tahunan pengembang dan membaginya dengan 1900 jam waktu kerja. Omong-omong, angka 1900 dipilih agak sewenang-wenang. Jumlah jam kerja per tahun sangat tergantung pada negara. Misalnya, di Korea Selatan pada tahun itu ada 2.069 jam kerja, di Rusia - 1974, di Amerika Serikat - 1783 dan di Inggris - 1676. Namun demikian, angka 1900 sepenuhnya sesuai dalam hal minggu kerja 40 jam, dan kami akan menggunakan persis angka ini untuk perhitungan lebih lanjut.
Jadi, mengapa tidak cukup dengan hanya membagi gaji tahunan pada tahun 1900?
Pertama, programer, seperti halnya karyawan lain dari bidang apa pun, menghasilkan uang lebih banyak daripada yang mereka terima dengan gaji mereka, jika tidak, bisnis akan berjalan dengan defisit. Pemrogram perlu diberi area kerja, Internet dan cookie, Anda juga perlu membayar sewa dan sebagainya. Oh, ya, masih ada imbalan finansial, acara perusahaan, berbagai bonus.
Dengan semua itu, seorang pengembang harus menguntungkan, yang berarti ia harus menghasilkan laba bersih untuk perusahaan secara langsung atau tidak langsung. Dalam praktiknya, ini berarti bahwa pekerjaan seorang pengembang, tergantung pada situasinya, menghasilkan uang 2-10 kali lebih banyak daripada yang dihabiskan untuk gajinya. Penting untuk menekankan bahwa pengembang tidak berbeda dari karyawan bergaji lainnya. Ada beberapa kekhasan yang terkait dengan outsourcing, tetapi ini adalah cerita lain.
Untuk pembaca yang skeptis, kami akan mengambil pengganda 2. Yang artinya pengembang membawa 2 kali lebih banyak uang daripada yang dihabiskan untuk gajinya. Sebenarnya, perusahaan dengan pengganda semacam itu sedang tertatih-tatih di ambang impas. Pendekatan yang lebih jujur adalah dengan mengambil pengganda sama dengan setidaknya 3.
Apa arti semua ini? Jika seorang programmer keluar dari proses pengembangan selama 1 jam, perusahaan tidak kehilangan jumlah uang yang setara dengan satu jam dari pekerjaannya, tetapi dalam 2 atau 3 kali lebih banyak.
Ada faktor c kedua yang mempengaruhi harga jam kerja saat ini. Faktanya adalah bahwa seorang karyawan tidak kode 8 jam per hari. Tidak dapat dibayangkan bahwa seorang pria baru saja datang di pagi hari dan berurusan dengan kode selama 8 jam sepanjang hari kerja. Pengembang sedang bekerja dengan Trello, berpartisipasi dalam rapat, merespons surat melalui pos, mengambil bagian dalam tinjauan kode. Pada akhirnya, dia harus pergi ke toilet dan minum teh :). Dalam kasus terbaik dia akan bekerja langsung dengan kode selama 6 jam. Jika Anda membaca teks ini bukan dalam "mode skeptis", Anda memahami apa yang sebenarnya 4 jam adalah waktu yang jauh lebih masuk akal.
Ternyata biaya satu jam perlu dikalikan dengan 8/6 = 1,33 (mode skeptis) atau 8/4 = 2 (lebih dekat dengan kenyataan).
Sekarang mari kita gandakan dua pengganda yang dibahas dan dapatkan pengganda akhir, yang dengannya Anda perlu melipatgandakan biaya satu jam pengembang:
- pengganda untuk skeptis: 2 * 1.33 = 2.66
- pengganda, lebih dekat dengan kenyataan: 3 * 2 = 6
Dalam praktiknya, koefisien akan sedikit lebih besar, karena kami tidak memperhitungkan hari libur dalam perhitungan.
Sekarang mari kita lihat apa artinya bagi perusahaan ketika pengembang dengan gaji rata-rata $ 74.000 per tahun keluar dari alur kerja selama 1 jam. Pendapatan tahunan $ 74.000 telah dipilih mengikuti gaji rata-rata di Jerman menurut data portal StepStone untuk 2018 tahun.
Catatan Untuk pemahaman yang lebih baik harus dicatat bahwa sebenarnya perusahaan dapat menghabiskan lebih dari $ 74.000 untuk gaji. Perlu dicatat bahwa perusahaan dapat memberikan kontribusi ke berbagai dana dan membayar pajak yang berbeda. Namun, itu sangat tergantung pada skema negara dan perpajakan sehingga kami bahkan tidak akan mencoba mempertimbangkan semua opsi ini. Untuk mempermudah, mari kita asumsikan bahwa perusahaan tidak menanggung biaya tambahan dan menghabiskan gaji pengembang hanya $ 74.000 setahun. Kami memutuskan untuk mencatatnya, bahwa kami membulatkan angka yang tidak mendukung PVS-Studio.
Jika gaji adalah $ 74.000, tarif per jam akan menjadi $ 74.000 / 1900 = $ 39. Ternyata jika pengembang terganggu memperbaiki kesalahan selama 1 jam, maka perusahaan tidak akan dapat menghasilkan:
- untuk yang skeptis: $ 39 / jam * 2,66 = $ 103 / jam
- pada kenyataannya lebih dari: $ 39 / jam * 6 = $ 234 / jam
Ini adalah biaya jam nyata (nilai) satu jam pengembang ketika ia melakukan sesuatu yang bermanfaat.
Berapa jam PVS-Studio disimpan
Sangat sulit untuk memastikan dengan pasti berapa jam per tahun PVS-Studio akan dihemat ketika menemukan kesalahan pada tahap awal. Kesalahan bisa sangat berbeda. Pengembang dapat memperhatikan beberapa dari mereka sendiri dan segera memperbaikinya. Meskipun demikian, terkadang bug dapat mengalihkan perhatian pengembang dari aktivitas yang berguna selama
beberapa hari .
Atas dasar pertimbangan empiris untuk skeptis, katakanlah penganalisa akan menghemat setidaknya 2 jam kerja pengembang seminggu, membebaskannya dari kebutuhan untuk mencari bug yang ditemukan oleh unit test atau departemen pengujian. Ya, memperbaiki bug itu sendiri biasanya membutuhkan waktu beberapa menit, tetapi untuk upaya mereproduksi masalah, percakapan dalam bugtracker, uji coba, penggabungan, dan sebagainya, akan mudah memakan waktu 2 jam ini.
Dua jam yang disebutkan di atas adalah pilihan skeptis, sebenarnya itu bisa memakan waktu lebih banyak. Mengingat bahwa kadang-kadang analisa dapat mencegah
Heisenbugs keras yang dapat direproduksi, nilai rata-rata dapat ditentukan sebagai 3 jam.
Ada sekitar 50 minggu dalam setahun. Selama satu tahun, penganalisa menghemat jumlah jam kerja pengembang nyata berikut ini:
- sikap skeptis terhadap analisis statis: 2 jam * 50 = 100 jam yang disimpan
- sikap positif: 3 jam * 50 = 150 jam disimpan
Saatnya menghitung ROI
Kemudian menggunakan PVS-Studio, satu programmer dengan gaji $ 74.000 akan kembali ke bisnis setiap tahun:
- Jika Anda skeptis: $ 103 / jam * 100 jam = $ 10,300
- Realita: $ 234 / jam * 150 jam = $ 35.100.
Sekarang mari kita ambil tim tipikal yang terdiri dari 10 orang. Setelah memperkenalkan PVS-Studio, kami dapat berharap bahwa, berkat waktu yang dihemat, tim akan dapat melakukan pekerjaan yang bermanfaat dengan biaya:
- Skeptis: $ 103.000
- Realita: $ 351.000
Formula terakhir
Jadi, sekarang mari kita satukan semua ini dalam satu formula.
Mari kita tunjukkan gaji tahunan seorang programmer sebagai S.
Jumlah pengembang dalam tim adalah N.
- Rumus untuk skeptis: N * (S / 1900) * 2.66 * 100
- Rumus sebenarnya: N * (S / 1900) * 6 * 150
Cara kami akan mengutip perhitungan untuk tim dengan jumlah pengembang yang berbeda dalam tabel. Tabel menunjukkan jumlah uang yang diproyeksikan yang dapat dihasilkan oleh tim pengembang untuk perusahaan jika, sepanjang tahun alih-alih mengedit bug, itu akan sibuk menciptakan sesuatu yang baru. Ini adalah angka yang harus dibandingkan dengan harga lisensi.
Deskripsi tabel. Baris atas: gaji pengembang per tahun. Kolom kiri: jumlah programmer dalam suatu tim. Table cell: berapa banyak uang yang tim akan dapatkan untuk perusahaan selama tahun itu, jika alih-alih mengedit bug (yang dapat ditemukan oleh PVS-Studio) tim akan sibuk dengan pemrograman yang bermanfaat.
Tabel untuk skeptis:
Tabel N1. Skeptis. Merah: menggunakan PVS-Studio bisa jadi tidak masuk akal. Hijau: penggunaan analisa statis dibenarkan dan bermanfaat. Biru: penggunaannya bermanfaat secara unik.Tabel aktual:
Tabel N2. Realita Merah: menggunakan PVS-Studio bisa jadi tidak masuk akal. Hijau: penggunaan analisa statis dibenarkan dan bermanfaat. Biru: penggunaannya bermanfaat secara unik.Tabel kedua, dalam pandangan kami, adalah valid, dan masuk akal untuk mempertimbangkan tabel ini ketika menilai kelayakan akuisisi lisensi.
Catatan
Tentu saja, perhitungan yang diberikan sesuai tidak selalu dan tidak di mana-mana. Misalnya, jika harga bug dan kerentanan untuk proyek ini sangat tinggi, tidak ada alasan untuk menghubungkan nilai menggunakan PVS-Studio dengan gaji. Dalam proyek semacam itu orang harus menilai kemungkinan kerugian moneter dan reputasi dan mengaitkannya dengan menurunkan risiko ketika menggunakan penganalisa kode. Ini adalah ceritanya sendiri, dan kami belum tahu bagaimana cara mendekatinya dari sudut pandang perhitungan.
Juga perhitungan mungkin tidak berfungsi untuk perusahaan outsourcing. Ini mungkin kedengarannya tidak indah, tetapi perusahaan semacam itu tertarik untuk menjual berjam-jam pada pengembangan, pengujian dan pemeliharaan mungkin. Dalam beberapa hal, penggunaan analisa bahkan dapat mengurangi penghasilan mereka. Ini secara tidak langsung dikonfirmasi oleh fakta bahwa di antara klien PVS-Studio tidak ada perusahaan outsourcing. Selain itu, pada pandangan pertama, di perusahaan seperti itu beberapa proses aneh dapat terjadi. Pada saat aktivitas yang lebih rendah, perusahaan dapat mengambil proyek bahkan pada kerugian. Ini lebih baik daripada membubarkan beberapa pengembang berlibur. Mereka lebih suka sibuk dengan sesuatu.
Kesimpulan
Jadi, walaupun perhitungannya mungkin tidak cocok untuk semua perusahaan, kami berharap kami berhasil menunjukkan cara mendekati evaluasi efektivitas penggunaan PVS-Studio dalam hal bisnis secara keseluruhan.