THE LINES OF CODE (LOC) METRIC

Metrik yang tertua untuk proyek-proyek perangkat lunak adalah "baris kode" (LOC). Metrik ini pertama kali diperkenalkan sekitar tahun 1960 dan digunakan untuk ekonomi, produktivitas, dan kualitas studi. Ekonomi dari perangkat lunak aplikasi diukur menggunakan "dolar per LOC." Produktivitas diukur dalam hal "baris kode per unit waktu." Kualitas diukur dalam hal "kekurangan-kekurangan per KLOC mana"K"adalah simbol untuk 1000 baris kode. LOC metrik ini cukup efektif untuk semua tiga tujuan. Sebagai bahasa pemrograman tingkat yang lebih tinggi tambahan diciptakan  metrik LOC mula menghadapi masalah. LOC metrik yang tidak bisa mengukur bebas-coding kegiatan seperti persyaratan dan desain yang menjadi semakin mahal. LOC metrik yang tidak bisa mengukur kerusakan persyaratan dan desain. Masalah ini menjadi begitu parah bahwa studi terkontrol pada tahun 1994 yang digunakan kedua metrik LOC dan Fungsi titik metrik untuk 10 versi aplikasi yang sama yang dikodekan dalam 10 bahasa mencapai yang mengkhawatirkan Kesimpulan: LOC metrik melanggarnya asumsi-asumsi standar dari produktivitas ekonomi begitu parah menggunakan metrik LOC studi yang melibatkan lebih dari satu bahasa pemrograman terdiri profesional malpraktik. 

PENGENALAN

Ianya menarik untuk mempertimbangkan sejarah baris kode (LOC) metrik dan beberapa masalah dengan LOC metrik yang dipimpin IBM untuk mengembangkan fungsi titik metrik. Berikut adalah sejarah singkat LOC metrik dari 1960 hingga hari ini, dengan proyeksi untuk 2020:

1. Baris kode metrik tahun 1960

Metrik yang tertua untuk proyek-proyek perangkat lunak adalah "baris kode" (LOC). Metrik ini pertama kali diperkenalkan sekitar tahun 1960 dan digunakan untuk ekonomi, produktivitas, dan kualitas studi. Ekonomi dari perangkat lunak aplikasi diukur menggunakan "dolar per LOC." Produktivitas diukur dalam hal "baris kode per unit waktu." Kualitas diukur dalam hal "kekurangan-kekurangan per KLOC mana"K"adalah simbol untuk 1000 baris kode. LOC metrik ini cukup efektif untuk semua tiga tujuan. Ketika pertama kali diperkenalkan metrik LOC ada hanya satu bahasa pemrograman yang digunakan secara luas dan itu dasar bahasa assembly. Program kecil dan pengkodean upaya terdiri dari sekitar 90% dari Total pekerjaan. Garis-garis fisik dan logis pernyataan adalah hal yang sama untuk dasar bahasa assembly. Dalam lingkungan ini awal, LOC metrik yang berguna untuk kedua ekonomi, produktivitas, dan kualitas analisis. Sayangnya sebagai industri perangkat lunak yang berubah, metrik LOC tidak berubah dan begitu menjadi kurang dan kurang berguna sampai dengan sekitar 1980 ini telah menjadi sangat berbahaya tanpa sangat banyak orang menyadarinya. Munculnya COBOL, FORTRAN, ALGOL, APL, dan bahasa lainnya akan segera menurunkan pengkodean usaha. Aplikasi yang lebih besar akan memperluas persyaratan dan desain usaha. LOC mulai kehilangan akurasi. 

      2. Baris kode metrik tahun 1970

Oleh Majelis dasar 1970 telah digantikan oleh makro-Majelis. Generasi pertama dari tingkat yang lebih tinggi pemrograman bahasa COBOL, FORTRAN dan PL / saya dengan cepat memperluas digunakan. Dasar Majelis bahasa mulai putus menggunakan sebagai banyak alternatif yang lebih baik menjadi tersedia. Dasar Majelis itu mungkin contoh pertama dari serangkaian panjang pemrograman bahasa itu wafat, meninggalkan Kereta penuaan legacy aplikasi yang akan sulit untuk mempertahankan sebagai programmer, perakitan, dan compiler berhenti menjadi tersedia. Masalah pertama dikenal dengan metrik LOC adalah pada tahun 1970 ketika banyak kelompok-kelompok publikasi IBM melebihi anggaran untuk tahun itu. Ini ditemukan (oleh penulis) bahwa publikasi teknis kelompok anggaran telah didasarkan pada 10% dari anggaran untuk pemrograman. Proyek-proyek publikasi yang berdasarkan bahasa assembly tidak dikuasai anggaran mereka, tapi manual untuk proyek-proyek yang dikodekan dalam PL/S (turunan dari PL / I) telah utama overruns. Ini adalah karena PL S berkurang pengkodean upaya setengahnya, tapi manual teknis yang sebagai besar pernah. Awal solusi untuk masalah ini adalah untuk memberikan definisi matematika formal ke bahasa "level." "Tingkat" didefinisikan sebagai jumlah pernyataan dalam bahasa perakitan dasar yang dibutuhkan untuk sama fungsi 1 pernyataan dalam bahasa tingkat yang lebih tinggi. Dengan demikian COBOL adalah bahasa "level 3" karena itu mengambil 3 perakitan dasar pernyataan 1 COBOL pernyataan yang sama. Menggunakan aturan yang sama, SMALLTALK adalah Level 18 bahasa.

    3. Baris kode metrik tahun 1980

Sekitar tahun 1980 jumlah bahasa pemrograman telah diatapi 50 dan bahasa-bahasa berorientasi objek cepat berkembang. Sebagai akibatnya, perangkat lunak usabilitas meningkat pesat. Masalah lain yang muncul sekitar tahun 1980 adalah fakta bahwa banyak aplikasi mulai menggunakan lebih dari satu bahasa pemrograman, seperti COBOL dan SQL. Tren untuk menggunakan berbagai macam bahasa di aplikasi sama telah menjadi norma, bukan pengecualian. Namun kesulitan menghitung baris kode dengan akurasi meningkat ketika beberapa bahasa digunakan. Di tengah dekade ini perangkat lunak komersial pertama biaya memperkirakan alat berdasarkan fungsi poin mencapai pasar, SPQR/20 yang dirilis pada tahun 1984. Alat ini didukung perkiraan untuk 30 Umum bahasa pemrograman dan juga dapat digunakan untuk kombinasi dari lebih dari satu pemrograman bahasa. Alat ini juga termasuk ukuran dan memperkirakan kertas dokumen seperti persyaratan, Desain, dan manual pengguna. Juga diperkirakan bebas-coding tugas termasuk manajemen proyek dan pengujian.

Karena metrik LOC masih digunakan, alat SPQR/20 menyatakan produktivitas dan mutu hasil menggunakan kedua fungsi poin dan LOC metrik. Karena itu mudah untuk beralih dari satu bahasa ke yang lain, itu menarik untuk membandingkan hasilnya menggunakan metrik LOC dan fungsi titik ketika perubahan dari Makro-Majelis Fortran atau Ada atau PL / I atau Jawa. Sebagai bahasa pemrograman tingkat naik, produktivitas yang dinyatakan dalam fungsi poin perStaf bulan juga pergi, yang sesuai dengan standar ekonomi. Tetapi sebagai bahasa tingkat mendapatkan lebih tinggi, produktivitas dinyatakan dalam "baris kode per bulan" drop-down. Pembalikan ini oleh LOC metrik

melanggar semua aturan standar ekonomi, dan alasan utama untuk menegaskan bahwa metrik LOC merupakan malpraktik profesional.Apa yang terjadi tentu saja adalah bahwa bagian dokumen proyek itu tidak menolak meskipun Kode bagian menurun secara substansial. Inilah sebabnya mengapa LOC metrik yang profesional malapraktik jika digunakan untuk membandingkan proyek-proyek yang menggunakan bahasa pemrograman yang berbeda. Mereka bergerak dalam arah yang berlawanan dari

produktivitas ekonomi standar tarif dan menghukum bahasa tingkat tinggi. Tabel 1 meringkas kasus kedua A dan B: kasus

Seperti yang dapat dilihat dengan melihat kasus A dan B, LOC metrik benar-benar membalikkan persyaratan ekonomi persamaan dan membuat versi besar, lambat, mahal terlihat lebih baik daripada versi kecil, cepat, murah. 

RINGKASAN DAN KESIMPULAN

Sejarah baris kode metrik adalah kisah peringatan bagi semua orang yang bekerja dalam perangkat lunak. LOC metrik dimulai dengan baik dan cukup efektif ketika ada hanya satu bahasa pemrograman dan pengkodean ini begitu sulit itu merupakan 90% dari total upaya untuk meletakkan perangkat lunak pada komputer. Tetapi industri perangkat lunak mulai mengembangkan ratusan dan ribuan bahasa pemrograman. Aplikasi mulai menggunakan beberapa bahasa pemrograman dan hal itu tetap norma hari ini. Aplikasi tumbuh dari kurang dari 1.000 baris kode sampai lebih dari 10.000.000 baris kode. Coding adalah tugas utama untuk aplikasi kecil, tetapi untuk sistem besar pekerjaan bergeser ke Cacat penghapusan dan produksi kertas dokumen dalam bentuk persyaratan, spesifikasi, user manual, rencana tes, dan banyak orang lain. LOC metrik ini tidak dapat mengikuti dengan perubahan baik. Itu tidak bekerja dengan baik ketika ada ambiguitas dalam menghitung kode, yang selalu terjadi dengan bahasa tingkat tinggi dan berbagai bahasa diaplikasi yang sama. Itu tidak bekerja baik untuk sistem yang besar mana coding adalah hanya sebagian kecil dari Total usaha.

Akibatnya LOC metrik menjadi kurang dan kurang berguna sampai sekitar 1985 mereka mulai menjadi benar-benar berbahaya. Mengingat kesalahan dan kesalahpahaman LOC metrik membawa ekonomi, produktivitas, dan studi mutu yang adil untuk mengatakan bahwa di banyak situasi penggunaan LOC metrik dapat dipandang sebagai profesional malapraktik jika lebih dari satu bahasa pemrograman adalah bagian dari studi atau kajian berusaha Mengukur produktivitas ekonomi riil. Titik akhir adalah bahwa terus penggunaan LOC metrik adalah penghalang signifikan yang menunda kemajuan "rekayasa perangkat lunak" dari kerajinan disiplin teknik yang benar. Pekerjaan yang bahkan tidak dapat ukuran sendiri bekerja dengan akurasi hampir tidak memenuhi syarat untuk dapat disebut "teknik."http://www.ifpug.org/Documents/Jones-LinesofCodeMetricV6.pdf