Apakah pengukuran metrik proyek perangkat lunak populer di industri saat ini?

9

Saya bertemu dengan seorang pengembang yang menginginkan saran dari luar tentang proyek tim mereka. Saya menemukan mereka sedang mengembangkan perangkat lunak yang sangat besar untuk eksekutif perusahaan, manajer proyek dan pengembang yang dapat menghitung metrik secara otomatis dan membuat grafik mereka per iterasi.

Sebagai seorang mahasiswa dari latar belakang ilmu komputer, saya hanya tahu sedikit tentang metrik dan kepentingannya, tetapi pertanyaan saya adalah:

Apakah sebagian besar perusahaan memiliki cara, tidak harus menjadi program yang elegan, untuk mengukur metrik yang bermakna?
Metrik mana, tunggal atau gabungan, yang membantu Anda mempersempit ruang lingkup dan taksiran proyek Anda?
Sebagai orang yang menganalisis metrik, seberapa sering Anda mendasarkan keputusan darinya? YAITU. Tes gagal per minggu meningkat secara drastis?
Apakah Anda merasa bahwa pengenalan metrik pembelajaran telah membantu Anda memahami proyek dengan lebih baik?

Tidak yakin mengapa tetapi proyek pengembang membuat saya penasaran dan saya harus tahu lebih banyak. Jika y

project-management metrics

— Russ K.
sumber

6

Beberapa buku tentang metrik yang mungkin dimiliki oleh perpustakaan kampus Anda mencakup Metrik dan Metrik Perangkat Lunak serta Model dalam Rekayasa Kualitas Perangkat Lunak . Mereka 2 harus memberi Anda tempat awal. Di dunia industri, sangat sedikit perusahaan yang memiliki program pengukuran metrik sama sekali.

Apakah sebagian besar perusahaan memiliki cara, tidak harus menjadi program yang elegan, untuk mengukur metrik yang bermakna?

Visual Studio menyertakan beberapa alat analisis kode yang dapat membantu Anda memulai. Sebagian besar perusahaan bahkan tidak memiliki sesuatu untuk mengukur metrik terburuk yang mungkin terjadi: baris kode. "Selesaikan saja" tampaknya merupakan kekuatan pendorong yang luar biasa di industri ini, dan kekhawatiran tentang pemeliharaan dapat diberikan perhatian yang sangat pendek terhadap kekhawatiran manajer tentang "akankah saya mendapatkan bonus saya tahun ini?" dan "akankah ini dilakukan pada waktu yang aku janjikan?" Bahkan dengan produk-produk yang dibawa dari tahun ke tahun dengan perubahan tambahan, kedua kekhawatiran itu membuat para pengembang khawatir akan pemeliharaan dan deteksi / pencegahan bug.

Metrik mana, tunggal atau gabungan, yang membantu Anda mempersempit ruang lingkup dan taksiran proyek Anda?

Saya menemukan bahwa kompleksitas siklis dan kopling adalah indikator kuat bagaimana kereta atau seberapa sulit untuk mempertahankan kode. Jika kompleksitas siklomatik sekitar 20, saya menemukan bahwa hampir tidak mungkin untuk menguji (karena akan memiliki hingga 2 ^ 20 jalur melalui kode) dan harus diurai menjadi potongan-potongan kecil. Anda tidak bisa menghilangkan kerumitan, tetapi Anda bisa mengirisnya menjadi potongan yang lebih mudah dikelola.

Jika Anda mencari estimasi , Anda mungkin ingin menyelidiki titik fungsi .

Cakupan kode% secara drastis menurunkan setiap iterasi, apakah Anda memberi tahu pengembang Anda tentang masalah ini

Saya menemukan bahwa sebagian besar manajer peduli dengan jumlah check-in dan jumlah bug yang diperbaiki. Manajer saya saat ini menentang pengujian unit (dia pikir itu buang-buang waktu) dan manajer saya sebelumnya merasa bahwa waktu yang dihabiskan untuk pengujian unit adalah waktu yang seharusnya digunakan untuk menulisnya.

Argumen kanonik yang digunakan oleh pengembang adalah bahwa jika Anda mengukur sesuatu, hanya itulah yang akan Anda dapatkan. Argumen ini berasal dari gagasan bahwa satu-satunya metrik adalah baris kode.

— Tangurena
sumber

Terima kasih atas jawaban terperinci dan tautan yang relevan. Sebagai tindak lanjut: 1. Mengapa manajer peduli tentang jumlah check-in? Mungkin definisi kami tentang check-in berbeda. 2. Apa yang Anda maksud dengan baris kode sebagai metrik terburuk? Terburuk karena tidak memberikan indikasi yang baik tentang proyek?

— Russ K

@Russ, pengembang yang tidak memeriksa kode, akan terlihat tidak berfungsi. LOC adalah yang terburuk karena sepele untuk game. Lihatlah perbedaan antara gaya indentasi kode K&R dan Allman: en.wikipedia.org/wiki/Indent_style . Gaya Allman akan memberikan jumlah LOC yang lebih tinggi hanya dengan meletakkan open {pada baris terpisah. Penafian: Saya benci gaya K&R karena saya jarang dapat menemukan pencocokan terbuka {tanpa menghabiskan terlalu banyak waktu bermain Where's Waldo.

— Tangurena

In the industrial world, very few companies have any sort of metric measurement program at all.Perusahaan mana pun dengan peringkat CMMI 2 atau lebih tinggi akan memiliki program analisis pengukuran / metrik. Pengumpulan pengukuran dan metrik adalah persyaratan Tingkat Kematangan 2. CMMI Maturity Level 4 membutuhkan manajemen proyek kuantitatif, berdasarkan pengukuran dan metrik tersebut, bersama dengan hal-hal seperti analisis akar penyebab untuk bertindak pada masalah yang diidentifikasi. Ada sejumlah besar organisasi yang berperingkat CMMI Level 4 (atau 5).

— Thomas Owens

2

Saya sedang berbicara tentang metrik perangkat lunak di mana pembicara membuat beberapa, IMHO, poin wawasan. Memiliki sedikit pengalaman dengan hal-hal ini sendiri, saya masih penasaran dan terinspirasi, tetapi saya tidak bisa mengatakan apakah itu salah atau benar.

Gagasan utama adalah:

Tidak ada metrik tunggal yang berguna untuk itu sendiri.
Menetapkan target absolut (yaitu cakupan kode XX%) tidak berarti.
Metrik tanpa riwayat berguna.

Jadi, untuk menyelesaikan ini:

Tampilkan beberapa metrik, seperti:
- Jumlah baris total / diubah
- # dari komitmen
- % cakupan kode
- # tes
- kompleksitas siklomatik
- file / paket / ... ketergantungan
- ...
Tampilkan data dari QA / CI:
- # bug / peningkatan / perubahan (Saya pribadi menganggap kategorisasi ini penting)
- # total / ditambahkan / diperbaiki
Tampilkan metrik ini pada grafik yang menunjukkan tren dari waktu ke waktu

Dengan cara ini, ketika tiket diperbaiki dengan cepat, orang dapat melihat apakah kualitas kode turun. Juga, ketika tampaknya tidak banyak terjadi dengan database bug, kualitas kode mungkin naik, karena refactoring sedang dilakukan.

Ringkasnya: Jenis perilaku dinamis inilah yang penting dan yang memberi Anda informasi daripada data mentah (yang akan menjadi nilai metrik tunggal).

Saya berencana untuk meletakkan beberapa grafik sesuai dengan skema ini di TV layar lebar di sebelah lampu lava yang terhubung CI kami. ;)

— Macke
sumber

Baik. Saya membaca banyak artikel tentang bagaimana metrik saja tidak berguna, seperti yang Anda sebutkan, dan sejarah itu penting. Terima kasih telah meluangkan waktu untuk membalas.

— Russ K