Seberapa bermanfaat poin fungsi? [Tutup]

Seberapa berguna mengukur titik fungsi ?

Kami menggunakan titik fungsi di pekerjaan baru saya. Saya pernah mendengar tentang poin-poin fungsi tetapi belum memiliki pelatihan atau pengalaman apa pun ... tetapi saya tidak memiliki banyak kepercayaan pada hal-hal yang tidak dapat dijelaskan secara ringkas.

Secara pribadi, saya belum pernah menemukan jawaban eksplisit untuk pertanyaan "Apa itu Function Point?" Tanpa itu, saya BENAR-BENAR ragu tentang metodologi estimasi yang mengklaim melakukan apa pun dengan Function Points.

Satu-satunya bagian terpenting dari metodologi estimasi perangkat lunak yang serius adalah "kalibrasi ulang berkala dengan aktual", yang berarti Anda membuat estimasi Anda, Anda menuliskannya, dan kemudian, ketika proyek selesai, Anda membandingkan hasil aktual Anda dengan perkiraan Anda, dan , jika perlu, perbaiki proses estimasi Anda. TERMASUK DALAM YANG membandingkan INPUT Anda dengan proses estimasi Anda dengan INPUT AKTUAL.

Jika, misalnya, Anda memperkirakan Source Lines of Code (SLOC), dan pergi dari sana, Anda harus membandingkan SLOC yang Anda kirimkan dengan perkiraan SLOC Anda, dan melihat apakah, seberapa jauh, dan di mana dan mengapa Anda tersesat. Penaksir yang memperkirakan jam kerja dengan sempurna, mengingat estimasi SLOC yang akurat dan tepat, tidak akan membantu Anda jika estimasi SLOC Anda tidak berharga. Sampah masuk sampah keluar. (Hal yang sama berlaku untuk Function Points.)

Jika SLOC Anda (atau Function Point) aktual sesuai dengan perkiraan awal Anda, maka Anda dapat melihat biaya aktual Anda terhadap perkiraan biaya Anda, dan menyesuaikan parameter estimator Anda untuk meningkatkan hasil Anda. General Dynamics / Fort Worth Division melakukan latihan ini, secara rinci, pada awal 1980-an, untuk pengembangan perangkat lunak F-16C / D, dan kemudian selama beberapa tahun akan secara rutin bertaruh garis bawah perusahaan pada perkiraan tersebut. GD / FW adalah sapi perah GD selama beberapa waktu, menjaga sisa perusahaan bertahan, jadi mereka pasti telah melakukan sesuatu yang benar.

Dan perhatikan bahwa persyaratan dan fitur creep adalah MUSUH dari estimasi perangkat lunak.

(Ini adalah suntingan nanti.) Poin terakhir Bernd pantas mendapat jawaban. Dia bertanya apa yang harus dilakukan tentang proyek yang datang lebih awal, dan jangan menghabiskan semua jam kerja yang dialokasikan.

Ini adalah kesalahan estimasi seperti overruns jadwal (jauh lebih umum). Faktanya adalah ini: jika semua proyek Anda melebihi jadwal mereka, orang-orang yang memperkirakan Anda tidak melakukan pekerjaan mereka.

Jika estimasi orang Anda melakukan segalanya dengan benar, dan manajer Anda melakukan semuanya dengan benar, maka Anda akan meminta beberapa proyek datang lebih awal, bersama dengan yang datang terlambat. Estimasi adalah probabilitas. Shade estimator Anda untuk menghilangkan underruns jadwal, dan Anda DENGAN DEFINISI meningkatkan kemungkinan overruns jadwal. Jika manajemen Anda menuntut jadwal dan perkiraan tanpa kemungkinan underrun, maka Anda akan memberikan jadwal yang AKAN dikuasai, dijamin, dan kemudian Anda akan mulai melihat permintaan untuk Marches Maut, dan kemudian Anda mulai melihat pengunduran diri, dan overruns Anda mendapatkan jauh, jauh lebih buruk, ketika Anda mencoba merekrut pengganti (dan tersiar kabar bahwa perusahaan Anda adalah sebuah toko pakaian).

Saat berurusan dengan ruang lingkup proyek, umumnya lebih baik menggunakan ukuran Poin Fungsi daripada Garis Kode . Karena proyek perangkat lunak dapat memiliki lebih dari jutaan LOC (termasuk LOC di perpustakaan) jumlahnya menjadi relatif tidak berarti.

Bagaimana Anda mengukur LOC jika Anda memanggil fungsionalitas dari perpustakaan? Apakah Anda memasukkan LOC dari perpustakaan? Jika Anda tidak memasukkan LOC dari perpustakaan, apakah atasan Anda tidak cukup menulis LOC?

Secara umum, lebih baik mengatakan "Saya menyelesaikan fungsionalitas XXX" daripada "Saya menulis baris kode XXX".

Tapi saya sarankan Anda melihatnya sendiri. Apakah lebih mudah bagi Anda untuk memperkirakan Poin Fungsi atau Garis Kode? Masukkan hasil-hasil tersebut ke dalam model COCOMO II , dan lihat mana yang lebih mudah digunakan.

Juga, Manual COCOMO II ini memberikan deskripsi terinci tentang Function Points dan LOC di sekitar halaman 11. Semoga itu cukup bagi Anda untuk melanjutkan.

Saya bekerja di organisasi tempat kami memperkenalkan titik fungsi untuk menghitung proyek harga tetap, yaitu pelanggan dan kami menghitung berdasarkan spesifikasi, menyetujui penghitungan dan kemudian melipatgandakan #FP dengan harga FP untuk menentukan harga proyek. Semua ini dalam lingkungan dengan omset proyek tahunan Juta Euro dua digit. Niatnya adalah untuk menghilangkan ambiguitas dan negosiasi dari penentuan harga yang merupakan penyebab gesekan yang konstan.

Kami telah melakukan kalibrasi awal, mengevaluasi sekitar 2 tahun sejarah proyek senilai dua digit Juta Euro.

Kami melihat dengan jelas bahwa #FP dan biaya proyek naik secara tidak langsung. Penyimpangan +/- 50% cukup mungkin. Namun, kami melihat (baik yang kami harapkan, atau lebih baik: kami berharap) bahwa dalam jangka panjang, titik fungsi dihitung dan biaya proyek bertemu.

Kami sekarang dalam proses meluncurkan ini ke dalam organisasi dan pengalaman (dari sudut pandang supier):

• Diskusi tentang aplikasi aturan penghitungan KB. Ada standar tentang ini, namun, ini dapat diabaikan jika orang tidak dapat berdebat tentang harga secara langsung.

• Tayangan klien bahwa harga naik, terlepas dari upaya yang kami habiskan dan menghabiskan dalam kalibrasi dan verifikasi kalibrasi. Alasan yang dicurigai adalah bahwa prosedur ini membuat biaya secara brutal jelas, tidak ada cara untuk menyembunyikan, mengubah atau menutupi biaya dalam beberapa proyek "jangan tanya" atau strategis.

• Perlu menangani proyek yang tidak mencakup biayanya (undershoot 50% ...)

Mereka tampaknya sedikit berguna dalam mengekspresikan kompleksitas sistem / komponen yang diberikan, dan dapat membantu manajer / tim memimpin pekerjaan pembagian, tetapi mereka tidak benar-benar lebih berguna daripada metrik sintetik / arbitrer lainnya (SLOC, Kompleksitas Sikomatik, dll. .) Artinya, mereka dapat memberikan indikasi jumlah usaha relatif yang diperlukan untuk bagian-bagian tertentu dari suatu sistem, tetapi tidak ada cara untuk memetakannya ke perkiraan yang konkret.

Penggunaan poin fungsi yang mendukung jalur kode berusaha untuk mengatasi beberapa masalah tambahan:

• Risiko "inflasi" dari garis kode yang dibuat, dan dengan demikian mengurangi nilai sistem pengukuran, jika pengembang diberi insentif untuk menjadi lebih produktif. Advokat FP menyebut ini sebagai ukuran ukuran solusi, bukan ukuran masalah.

• Lines of Code (LOC) mengukur hadiah bahasa tingkat rendah karena lebih banyak baris kode diperlukan untuk memberikan jumlah fungsionalitas yang serupa ke bahasa tingkat yang lebih tinggi. C. Jones menawarkan metode untuk mengoreksi hal ini dalam karyanya.

• Langkah-langkah LOC tidak berguna selama fase proyek awal di mana memperkirakan jumlah baris kode yang akan disampaikan adalah menantang. Namun, Poin Fungsi dapat diturunkan dari persyaratan dan oleh karena itu berguna dalam metode seperti estimasi oleh proksi.

Melarikan diri.

Dalam pengalaman saya, perusahaan yang saya lihat menggunakan poin fungsi hanya satu langkah di atas kegilaan murni.