Apakah ada pekerjaan dalam penerapan langkah-langkah kompleksitas Halstead untuk menentukan kualitas perangkat lunak?

Pada tahun 1977, Maurice Howard Halstead memperkenalkan ukuran kerumitannya untuk sistem perangkat lunak , yang meliputi pengukuran kosakata program, panjang program, volume, kesulitan, usaha, dan perkiraan jumlah bug dalam sebuah modul. Menurut Wikipedia, kesulitan berkaitan dengan kesulitan memahami program ketika membaca atau menulisnya dan upaya dapat diterjemahkan ke dalam waktu yang diperlukan untuk kode aplikasi di mana Time = (Usaha / 18) detik.

Pengukuran tidak berguna kecuali data dan perhitungan terkait dengan beberapa aspek pengembangan perangkat lunak. Namun, saya belum menemukan pekerjaan yang menyatakan bahwa kesulitan dari nilai tertentu atau lebih tinggi cenderung peningkatan signifikan secara statistik dalam cacat atau hubungan antara kesulitan dan waktu untuk membaca kode (kesulitan N menghasilkan rata-rata M jam yang dihabiskan memahami basis kode) atau analisis apa pun untuk dapat menghitung Waktu setelah fakta berguna dalam menentukan kualitas (terutama karena waktu untuk menulis seharusnya sudah dicatat sebagai ukuran sudah). Saya terutama tertarik pada estimasi bug Halstead (yang tidak disebutkan di Wikipedia) - jumlah bug dalam aplikasi dapat diperkirakan dengan Volume / 3000 atau Usaha ^ (2/3) / 3000.

Saya mencari dua hal:

Adakah yang menggunakan ukuran kompleksitas perangkat lunak Halstead dalam aplikasi dunia nyata untuk menilai kualitas perangkat lunak? Jika demikian, bagaimana Anda menerapkannya dan ternyata hasilnya bermanfaat, valid, dan / atau dapat diandalkan?
Adakah penelitian akademis dalam bentuk survei, analisis, atau studi kasus yang membahas validitas (atau ketidakabsahan) tindakan kompleksitas Halstead ketika diterapkan pada kualitas perangkat lunak?
Apakah ada penelitian akademis dalam bentuk survei, analisis, atau studi kasus yang menunjukkan penggunaan Source Lines of Code (SLOC) untuk menghitung sesuatu yang mirip dengan metrik Volume, Kesulitan, Upaya, Waktu, dan Bug Halstead? Saya menduga Volume mungkin hanya sesuai dengan penghitungan SLOC dan Kesulitan mungkin sesuai dengan kompleksitas siklomatik (dan mungkin tindakan lain). Saya juga sangat menyadari bahwa upaya pengukuran, produktivitas, atau waktu dalam SLOC berpotensi menyesatkan.

quality metrics measurement

— Thomas Owens
sumber

Anda akan mengalami beberapa kesulitan menemukan hasil dalam 15 tahun terakhir, karena pekerjaan metrik Halstead dilakukan lebih seperti 30-40 tahun yang lalu, dan korelasi yang kuat dengan SLOC ditemukan segera. (Ini dari ingatan, dari ceramah oleh kandidat fakultas Ph.D baru di UT Austin sekitar 1977.)

— John R. Strohm

Terima kasih untuk itu. Saya akan memperbarui pertanyaan dan memfokuskan kembali upaya pencarian saya pada karya lama.

— Thomas Owens

Jawaban:

Microsoft Research telah melakukan beberapa pekerjaan di bidang ini. Lihat halaman ini: http://research.microsoft.com/en-us/people/nachin/ . Meskipun tidak secara khusus didasarkan pada Halstead, Nachi dan timnya telah melakukan beberapa investigasi menggunakan Halstead, kompleksitas cyclomatic, code churn, dan langkah-langkah lain untuk menilai risiko dan kerapuhan relatif untuk membuat perubahan di bidang kode. Ada juga makalah yang menarik tentang bagaimana efektivitas organisasi juga memainkan peran besar tapi itu di luar topik. :)

— nithin
sumber

Saya harus membaca beberapa di antaranya. Pasti sesuatu yang saya minati, tapi saya (setidaknya sekarang), terutama tertarik pada Halstead, jadi saya akan fokus di sana. Saya mem-bookmark situs tersebut sehingga saya dapat membacanya ketika saya mendapatkan lebih banyak waktu, tetapi inilah +1 untuk saat ini.

— Thomas Owens

Kompleksitas siklus McCabe telah ditunjukkan, pada kode nyata, untuk berkorelasi sangat kuat dengan SLOC mentah, sampai-sampai tidak ada nilai tambahan apa pun dalam penghitungannya.

— John R. Strohm

Ada beberapa studi semacam itu. Google adalah TEMAN Anda.

Metrik Halstead tidak disukai ketika ditunjukkan bahwa semuanya berkorelasi kuat dengan SLOC mentah (baris kode sumber). Pada saat itu, menjadi lebih mudah untuk mengukur SLOC dan dilakukan dengan itu.

Ini hasil dari Google Books .

— John R. Strohm
sumber

Saya telah mencari di Google sejak sebelum saya mengajukan pertanyaan ini dan belum menemukan makalah yang diterbitkan atau sumber terpercaya lainnya. Juga, saya gagal melihat bagaimana metrik yang terkait dengan SLOC bisa menjadi buruk. SLOC / waktu adalah ukuran produktivitas yang buruk, tetapi metrik berbasis SLOC lainnya biasanya dianggap valid, misalnya cacat / SLOC.

— Thomas Owens

@ Thomas: Bukannya metrik Halstead "terkait" dengan SLOC, melainkan metrik yang berkorelasi kuat. Statistik 102. Mengatakan bahwa Y dan X berkorelasi kuat berarti bahwa rasio Y / X pada dasarnya konstan untuk semua dataset. Ketika itu masalahnya, tidak ada gunanya mengukur Y jika lebih mudah untuk mengukur X, karena Y tidak benar-benar memberi tahu Anda apa pun yang belum Anda ketahui dari X.

— John R. Strohm

Itu masuk akal. Metrik Halstead didasarkan pada jumlah operator dan operan yang berbeda dan total. Masuk akal jika program yang lebih panjang akan memiliki lebih banyak operator / operan total dan akan lebih mungkin memiliki lebih banyak operator / operan yang berbeda. Metrik Volume dan Kesulitan dapat diperoleh dengan menggunakan SLOC, bukan operator / operan. Namun, itu tidak membahas validitas, aplikasi, dan makna (atau kurangnya makna) metrik Upaya, Waktu, dan Bug. Bahkan ketika dihitung dengan SLOC dan bukan operator / operan, apakah metrik ini mengatakan sesuatu yang berarti tentang sistem?

— Thomas Owens

SLOC lebih mudah untuk dihitung, dan mungkin lebih bermanfaat. Estimasi SLOC digunakan oleh beberapa teknik estimasi biaya, dilacak dalam PSP dan TSP, dan dapat digunakan dalam metrik lain seperti kepadatan cacat. Bagi saya, mengatakan menghitung SLOC mungkin lebih baik daripada menghitung operator / operan. Kedua, dan belum terjawab sejauh ini, adalah validitas metrik dari Upaya, Waktu, dan Bug, terlepas dari ukuran apa yang digunakan untuk menghitungnya. Saya setuju bahwa menghitungnya dengan SLOC mungkin lebih baik, tetapi bahkan jika saya lakukan, apakah itu akan berarti apa-apa?

— Thomas Owens

@ThomasOwens: Mungkin tidak. Jika Usaha, Waktu, dan Bug semuanya berkorelasi kuat dengan SLOC, maka itu memberi tahu Anda bahwa semua program dengan ukuran tertentu membutuhkan waktu dan upaya yang sama dan memiliki jumlah bug yang sama. Dua yang pertama adalah berdasarkan apa estimasi berbasis SLOC (misalnya COCOMO), dan seperti mengatakan air basah. Yang ketiga tidak benar-benar membantu Anda.

— John R. Strohm

Volume Halstead berkorelasi dengan SLOC itu menarik tetapi terbatas. Statistik dasar: korelasi linier tidak transitif. X berkorelasi dengan Y, Y berkorelasi dengan Z TIDAK BERARTI bahwa X berkorelasi dengan Z.

— pengguna1704475
sumber

Ketika X dan Y hanya berkorelasi, dan Y dan Z hanya berkorelasi, ya, X dan Z belum tentu berkorelasi, karena tingkat kebisingan yang relatif tinggi dalam dua korelasi pertama. Ketika X dan Y berkorelasi kuat, dan Y dan Z berkorelasi kuat, sangat sedikit noise yang terlibat, dan menjadi sangat mungkin dalam kasus apa pun bahwa X dan Z akan ditemukan berkorelasi.

— John R. Strohm