Lingkungan Bisnis

Metode pengembangan sistem cocok untuk Indonesia

2020/02/28

スパイラル開発

Metode pengembangan sistem mencerminkan zaman

Tentu saja pengembangan sistem selama masa kejayaan mainframe dan office computer dilakukan menggunakan metode waterfall. Ketika saya bergabung dengan perusahaan sistem perbankan sebagai lulusan baru pada tahun 1990-an, saya tidak pernah berpikir mengapa metode waterfall cocok untuk berkembang sistem perbankan.

Dengan metode waterfall, definisi persyaratan ⇒ jadwal dasar ⇒ desain terperinci ⇒ pengembangan program ⇒ uji unit ⇒ uji integrasi ⇒ uji sistem dilakukan satu arah tanpa menelusuri ulang seperti air sungai mengalir dari hulu ke hilir Teknik

Sejak tahun 2000an, metode pengembangan metode prototipe, metode spiral, dan metode waterfall telah diusulkan, setelah banyak belokan dan belokan, koalisi partai-partai oposisi yang disebut tipe Agile telah terbentuk.

Saat ini, pendekatan kami untuk mengembangkan dan memperkenalkan sistem manufaktur di Indonesia adalah yang paling dekat dengan metode spiral, yang jarang kita dengar sekarang.

Metode spiral adalah metode pengulangan definisi, pengembangan, dan ulasan(レビュー) persyaratan kecil, sambil membangun hasil dan secara bertahap bertujuan untuk produk jadi.

Definisi metode spiral dan metode agile itu sendiri belum distandarisasi, jadi tidak masuk akal untuk menjelaskan perbedaan metodologis, tetapi dari sudut pandang(視点) bekerja di lapangan, hasilnya adalah bahwa jika persyaratan klien tegas itu metode agile dan jika tidak mengeras menjadi metode spiral.

"Metode waterfall sudah tua, kini zaman metode agile", bukan masalah seperti ini, tetapi hanya metode yang ada sesuai dengan karakteristik sistem dan lingkungan proyek, dan metode yang sesuai untuk tempat harus dipilih awalnya.

Namun pada kenyataannya, sulit untuk melepaskan metode yang biasa Anda gunakan. Gara-gara itu Anda bolos waktu dan biaya bisa sangat tinggi.

Mengapa metode waterfall ini cocok untuk sistem perbankan

Sistem perbankan dapat secara luas dibagi menjadi menjadi dua, yaitu sistem inti untuk operasi bisnis, seperti setoran, pinjaman, dan pengiriman valuta asing, dan sistem informasi yang menyediakan informasi yang diperlukan untuk operasi akuntansi seperti analisis kredit untuk setiap klien berdasarkan data transaksi ini.

Struktur organisasi perusahaan terdiri dari tim pengembangan yang bertanggung jawab untuk pengembangan dan pemeliharaan sistem inti, tim teknis yang memelihara lingkungan sekitar mainframe dan sistem operasi komputer off-the-shelf, memperkenalkan peralatan baru, dan memelihara jaringan, perpustakaan tim yang mencerminkan program pengembangan dalam produksi dan mengelola sejarah kode sumber, tim sistem luar negeri yang mengkhususkan diri dalam sistem bisnis luar negeri di New York dan London, tim sistem informasi yang mengembangkan sistem PC dan UNIX, dan tim operasi yang mendukung mainframe dan komputer di luar rak dan merawatnya di malam hari.

Sejumlah besar kode sumber tulisan tangan yang ditulis dalam PL/1, COBOL, RPG, Visual Basic, dll., Disediakan dengan akhiran (nomor cabang) dalam lemari yang disusun sekitar 20m dari ujung lantai hingga ujung. Sejarah dipertahankan, dan fungsinya diperkuat setiap tahun karena ditambahkan seperti sup rahasia toko ramen.

Setelah dilatih selama setengah tahun, saya ditugaskan ke tim sistem luar negeri. Saya bertanggung jawab atas pengembangan sistem untuk cabang luar negeri menggunakan RPG (Report Program Generator) yang dijalankan pada komputer kantor (AS / 400), dan kemudian dipindahkan ke tim teknis untuk menambah jumlah tagihan. Kami mengembangkan sistem untuk mengontrol terminal OTM (Online Tellers Machine) yang secara otomatis menghitung bersama dengan staf yang bekerja sama yang ditempatkan berdasarkan pengiriman.

Yah, saya mengalami berbagai pekerjaan yang berkaitan dengan sistem dalam waktu singkat dari pengembangan ke kabel kabel, tetapi pada saat itu kata perampingan menjadi populer, dan pusat pengembangan sistem adalah jenis didistribusikan berbasis PC Saya khawatir tentang pekerjaan tim sistem informasi di sebelah saya yang sedang berkembang di sana.

Salah satu alasan mengapa jenis waterfall cocok untuk pengembangan bersama dan pengelolaan sistem yang membutuhkan keamanan besar dan ketat adalah bahwa tanggung jawab menjadi lebih jelas.Ketika masalah terjadi, menjadi jelas siapa yang melakukan apa dan apa penyebabnya.

Untuk menjaga keandalan absolut, perlu menetapkan tanggal target agar sistem pengembangan tercermin dalam produksi, untuk menetapkan jadwal keseluruhan untuk setiap proses dengan penundaan, untuk mencerminkannya dalam produksi melalui pengujian yang cermat, dan untuk memiliki manajemen sistem yang dapat menganalisis kode sumber dengan cepat jika terjadi kegagalan.

Jika persyaratan tidak dapat ditentukan, itu harus metode spiral

Dalam jenis waterfall, seluruh persyaratan didefinisikan sebagai spesifikasi pada tahap awal proyek, sedangkan dalam jenis agile, persyaratan didefinisikan sebagai spesifikasi untuk setiap fungsi, tetapi dalam kedua kasus, diasumsikan bahwa pelanggan memiliki sudah menyusun persyaratan.

Dalam industri manufaktur Indonesia, hanya perusahaan besar dengan departemen IT yang dapat mengumpulkan persyaratan. Tapi di sisi lain untuk perusahaan kecil tidak muda mengumpulkan persyaratan dalam bentuk spesifikasi sistem.

Karena tidak mungkin untuk meringkas persyaratan, perusahaan SI seperti perusahaan kami membuat prototipe sambil mendengarkan persyaratan dari penanggung jawab, tetapi ketika proyek berjalan dan bentuk sistem diwujudkan, tiba-tiba dapat perubahan persyaratan.

Jika persyaratan tidak terorganisir, dapat diprediksi bahwa perubahan spesifikasi akan terjadi sebelumnya, dan jika Anda tidak memotong pada tingkat tertentu, Anda akan kehilangan biaya selamanya.

Untuk klien skala besar yang memiliki anggaran besar, saya pikir tidak ada masalah dengan metode waterfall atau metode agile di mana pekerja-jam selain pengkodean cenderung meningkat, tetapi proyek-proyek skala kecil hingga menengah di mana proyek dimulai dengan anggaran terbatas Untuk klien, diharapkan bahwa pengkodean akan memperhitungkan sebagian besar jam kerja, dan penting untuk mengurangi jam kerja yang diperlukan untuk membuat dan menguji spesifikasi lain dan menjaga keseimbangan biaya keseluruhan.