Contoh utang teknis dalam menerapkan sistem BI

Pengembangan dan penyebaran sistem BI adalah proses yang cukup cepat dan murah, tetapi pemeliharaannya dari waktu ke waktu mahal. Ini bisa dibayangkan melalui metafora utang teknis.

Utang teknis - menunjukkan masalah yang diakumulasi dalam kode program atau arsitektur yang terkait dengan pengabaian kualitas dalam pengembangan perangkat lunak dan menyebabkan biaya tenaga kerja tambahan di masa depan.

Sering ada alasan strategis yang beralasan untuk mengambil utang teknis. Tidak semua utang buruk, tetapi semua utang perlu diperbaiki. Utang teknis dapat dibayar dengan refactoring kode, meningkatkan pengujian, menghapus kode mati, mengurangi ketergantungan, memperketat API, dan meningkatkan dokumentasi. Tujuannya bukan untuk menambah fungsionalitas baru, tetapi untuk memungkinkan perbaikan di masa depan, mengurangi kesalahan, dan meningkatkan pemeliharaan. Menunda pembayaran semacam itu menyebabkan biaya yang rumit. Utang tersembunyi berbahaya karena meningkat diam-diam.

Contoh hutang teknis di BI:

• Ada gudang data di proyek BI, tetapi sebenarnya itu adalah salinan dari database yang berfungsi. Akibatnya, manfaat penyimpanan, seperti kecepatan refresh data, hilang, dan data mungkin hilang atau rusak.
• Saat memuat dan memperbarui data (ETL), data tidak dicentang / diperbaiki. Kesalahan ditransfer ke aplikasi.
• Bidang yang tidak optimal dan nama variabel membuat pengeditan dan penggunaan aplikasi menjadi sulit di masa depan.
• Model / struktur data yang awalnya tidak tepat dari aplikasi menyebabkan masalah selama operasi dan modifikasi aplikasi.
• BI , , ( ). , .
• BI — . BI. , - .
• , , ().
• BI, , - , .

Hanya pengetahuan tentang ini, sayangnya, tidak memberikan metrik apa pun untuk manajemen. Bagaimana mengukur utang teknis dalam suatu sistem atau memperkirakan nilai total utang ini? Fakta bahwa tim masih bekerja bukanlah bukti dari tingkat hutang yang rendah, karena nilai penuh dari hutang menjadi jelas hanya dari waktu ke waktu.

Beberapa pertanyaan berguna untuk dipertimbangkan:

1. Seberapa mudahnya untuk sepenuhnya menguji algoritma yang sama sekali baru untuk menghitung metrik?
2. Seberapa akurat pengaruh perubahan baru dalam suatu sistem diukur?
3. Seberapa cepat anggota tim baru dapat memperoleh informasi terbaru?

Kami berharap artikel ini dapat berfungsi sebagai insentif untuk pengembangan tambahan di bidang BI, termasuk peningkatan metode pengujian, pola desain, dan banyak lagi. Tetapi poin yang paling penting adalah bahwa utang teknis adalah masalah yang harus diperhatikan oleh programmer dan manajer.