Bagaimana seharusnya seorang manajer non-IT mengamankan pemeliharaan jangka panjang dan pengembangan perangkat lunak warisan penting?


13

Kami adalah perusahaan administrasi manfaat kecil, sangat terspesialisasi, dengan koleksi perangkat lunak yang sangat berguna dan kuat, beberapa ditulis dalam COBOL tetapi sebagian besar dalam BASIC. Dua konsultan penuh waktu dengan cakap memelihara dan meningkatkan sistem ini selama lebih dari 30 tahun. Tak perlu dikatakan mereka akan segera pensiun. (Salah satu dari mereka telah putus asa untuk pensiun selama beberapa tahun tetapi setia pada kesalahan dan tetap bertahan meskipun ada desakan dari suaminya bahwa golf harus diprioritaskan.)

Kami memulai jalur konversi ke sistem yang dikembangkan oleh satu dari hanya tiga perusahaan di negara yang menawarkan jenis perangkat lunak yang kami gunakan. Kami sekarang merasa bahwa meskipun perusahaan ini secara teoritis mampu menyelesaikan proses konversi, mereka tidak memiliki sumber daya untuk melakukannya tepat waktu, dan kami percaya bahwa mereka tidak akan dapat menawarkan jenis layanan yang kami butuhkan untuk menjalankan bisnis kami. (Tidak ada yang bisa mengatur prioritas sendiri dan memiliki wewenang untuk mengalokasikan sumber daya seseorang sesuai keinginan.)

Perangkat keras bukan masalah - kami dapat meniru sangat efektif pada server modern. Jika COBOL dan BASIC adalah bahasa modern, kami akan bersedia mengambil risiko bahwa kami dapat menemukan pengganti untuk konsultan kami saat ini ke depan.

Sepertinya harus ada model bisnis untuk sebuah perusahaan dukungan TI yang berkonsentrasi pada platform lama seperti ini dan menyediakan bakat pemrograman dan pengembangan perangkat lunak untuk mendukung sistem seperti kita, menghilangkan risiko menemukan bakat pemrograman yang tepat dan dari belakang kita. pekerjaan meyakinkan pemrogram muda bahwa mereka dapat memiliki karier yang produktif dan bermanfaat, sebagian dalam bahasa yang lama dan tidak seksi seperti BASIC.

Singkatnya, sebagai manajer non-IT, bagaimana kita dapat mengelola transisi ini dengan baik?


6
Aduh! DASAR dan COBOL?!? Saya akan mencoba rumah pensiun. Pernahkah Anda berpikir untuk "memodernisasi" perangkat lunak Anda?
BЈовић

2
Sebagai tambahan: karier yang produktif dan bermanfaat, sebagian dalam bahasa lama yang tidak seksi seperti BASIC. - DASAR dan produktif, karier yang memuaskan tidak sejalan dalam satu kalimat
BЈовић

3
Ada banyak kontraktor dan konsultan yang memigrasikan perangkat lunak dari sistem warisan. Namun cobol dan dasar bukan warisan mereka prasejarah. Meskipun anehnya mungkin cukup mudah untuk mempekerjakan seseorang, karena mereka mungkin keren dengan cara hacker hipster.
NimChimpsky

3
Saya akan setuju dengan @ BЈовић untuk yang ini. Anda harus mempertimbangkan untuk memodernisasi perangkat lunak Anda daripada mencoba mencari dukungan kehidupan untuk sesuatu yang semuda BASIC dan COBOL, setidaknya demi pemeriksaan di masa depan. Untuk saat ini Anda mungkin menemukan beberapa oldies atau anak-anak hipster yang dapat memberi kode untuk Anda, tetapi seiring berlalunya waktu dan paradigma berubah, bakat ini akan menjadi spesies yang terancam punah yang pada gilirannya akan menyebabkan matinya sistem Anda secara perlahan dan stabil. Fakta bahwa Anda hampir tidak dapat menemukan programmer sekarang harus menjadi bendera merah yang sudah saatnya untuk perubahan.
Maru

2
@ user105977 - Saran terbaik saya adalah mendokumentasikan sistem saat ini (jika belum didokumentasikan) sehingga konsultan Anda merasa nyaman, jika mereka tertabrak bus atau pensiun, seseorang dapat datang setelah mereka dan mengelola proyek. Setelah Anda memiliki dokumentasi proyek (spesifikasi, persyaratan proyek, dll) Anda tidak dalam posisi yang buruk. Saya agak tidak setuju dengan sebagian besar komentar tentang bahasa-bahasa ini, masih ada permintaan untuk mereka, dan pengetahuan tentang bahasa-bahasa ini bernilai banyak uang. Pengembang muda harus dapat mempelajari bahasa-bahasa ini dengan cepat.
Ramhound

Jawaban:


11

Mungkin kelihatannya "harus ada model bisnis untuk perusahaan dukungan TI yang berkonsentrasi pada platform lama seperti ini", tetapi secara pribadi saya pikir itu hanya angan-angan dari pihak Anda karena akan "menyelesaikan" tantangan yang Anda hadapi dalam satu menukik.

Tetap terjebak di lingkungan lama bukanlah cara untuk maju. Dan saya tidak akan mempertaruhkan nyawa perusahaan mana pun untuk tetap terjebak dengan menemukan perusahaan yang, untuk saat ini, bersedia melakukan apa yang tampaknya tidak dapat Anda lakukan.

Jadi bukan jawaban untuk pertanyaan aktual yang Anda tanyakan, tetapi saran yang tulus tentang bagaimana Anda dapat bergerak maju sambil menjaga risiko migrasi seminimal mungkin.

Baca "Cara bertahan hidup dari menulis ulang tanpa kehilangan kewarasan Anda"

Jangan membuat kesalahan dari proyek migrasi panjang tanpa hasil nyata untuk waktu yang lama. Baca "Cara bertahan hidup dari menulis ulang tanpa kehilangan kewarasan Anda"

Saya tidak bisa cukup menekankan bagaimana saran dalam artikel itu telah membantu saya dalam mengatasi / mendekati masalah yang sama setelah membakar diri saya sendiri dengan melakukan proyek semacam itu dengan cara "lama".

Siapkan pengujian otomatis

Jika Anda belum menggunakannya (mengapa tidak?), Minta programmer Anda saat ini untuk membuat test harness otomatis untuk aplikasi Anda.

Rangkaian uji otomatis harus mencakup semua area fungsional aplikasi Anda. Itu sh / akan mendokumentasikan spesifikasi kerja saat ini dalam aturan "when_X_then_Y" dari masing-masing kasus uji. Ini akan membantu baik dalam menjaga perubahan dalam kode Anda saat ini dari melanggar fungsi yang ada serta mendukung migrasi ke lingkungan baru.

Ketika Anda berurusan dengan COBOL dan BASIC, suite tes mungkin harus berada pada level tes integrasi: mengerjakan set file input / basis data "tetap" dan memeriksa file output / mengubah isi database dari program tertentu (COBOL) dan / atau aplikasi. Untuk bagian-bagian BASIC dari perangkat lunak Anda ini dapat berarti menambahkan parameter baris perintah untuk membuatnya menjalankan fungsi-fungsi tertentu tanpa intervensi (G) UI, atau mendapatkan alat uji otomatis berbasis UI (G).

Isolasi perhitungan dan algoritma lainnya

Bahkan Cobol mendukung gagasan tentang sub program yang dapat dipanggil dari program utama. Isolasi semua perhitungan impor dan algoritme lain dalam program atau modul terpisah. Tujuannya adalah untuk membuat perpustakaan program / modul / apa pun yang melakukan pekerjaan kasar terisolasi dari segala sesuatu yang mengumpulkan input dan menciptakan output.

Sesuaikan alat uji untuk mengujinya baik melalui aplikasi lama Anda maupun secara terpisah. Ini akan memastikan bahwa pekerjaan yang Anda lakukan pada kode "lama" untuk memfasilitasi migrasi ke lingkungan yang lebih baru akan memperkenalkan kesalahan sesedikit mungkin.

Mulai serangkaian aplikasi baru di lingkungan "saat ini"

Jangan mengonversi kode Anda saat ini. Mengubah satu bahasa ke bahasa lain berarti memaksakan batasan lingkungan lama pada yang baru. Hasilnya jika sering kurang dari yang diinginkan (baca: hasilnya akan mengerikan dan sakit untuk mempertahankan). Migrasi. Luangkan waktu untuk mengatur aplikasi Anda di lingkungan baru dengan cara yang dianggap praktik terbaik untuk lingkungan itu.

Dapatkan programmer baru, berpengalaman dalam lingkungan yang Anda pilih, untuk melakukannya. Jadikan sebagai prioritas sejak hari pertama untuk mengisolasi semua perhitungan dan algoritma penting dalam kelas dan / atau paket terpisah dan sembunyikan di belakang antarmuka. Gunakan injeksi ketergantungan (jenis injeksi ketergantungan DIY paling murah) untuk memberi tahu aplikasi baru Anda kelas mana yang akan dipakai / digunakan untuk melakukan perhitungan.

Ini adalah cara yang baik untuk melakukan banyak hal dan dalam kasus Anda akan memungkinkan Anda untuk melakukan migrasi bagian-bagian penting berdasarkan kasus. Ini juga akan menyembunyikan seluk-beluk program panggilan dasar dan / atau cobol dari fungsi panggilan di lingkungan baru.

Jangan melangkah lebih jauh dengan mengatur aplikasi dan mungkin mengatur fungsi input / output terpenting yang menggunakan perhitungan dari "perpustakaan" COBOL / BASIC Anda.

Integrasikan "perpustakaan" COBOL / BASIC Anda

Cari tahu bagaimana cara memanggil "perpustakaan" COBOL / BASIC Anda dari lingkungan baru Anda. Ini mungkin melibatkan pengaturan file parameter atau tabel database, menjalankan program COBOL / BASIC yang membungkus perpustakaan COBOL / BASIC yang Anda atur sebelumnya. Jika Anda beruntung, versi BASIC Anda memungkinkan pembuatan DLL yang dapat dipanggil langsung.

Laksanakan kelas di lingkungan baru Anda yang akan memanggil COBOL / BASIC "perpustakaan" dan uji heck keluar dari itu menggunakan tes yang sama yang memanfaatkan uji lingkungan lama, tetapi sekarang dalam bentuk unit test di lingkungan baru .

Ya ini berarti "menduplikasi" tes, tetapi ini adalah jaring pengaman yang tidak ingin Anda lakukan tanpanya. Jika hanya karena unit test ini nantinya akan berfungsi sebagai tes untuk memeriksa implementasi perhitungan dan algoritma Anda ketika mereka dimigrasi ke lingkungan baru Anda.

Tetapi sekali lagi: jangan melangkah lebih jauh daripada menambahkan tes unit untuk perhitungan yang digunakan oleh yang paling penting dari langkah sebelumnya.

Selesaikan aplikasi baru dalam iterasi

Selesaikan aplikasi baru dengan mengulangi dua langkah sebelumnya untuk semua fungsi di aplikasi lama Anda. Terus tambahkan tes unit yang memeriksa perhitungan ke harness pengujian aplikasi baru Anda. Gunakan suite tes integrasi untuk memeriksa apakah fungsi yang dimigrasi berfungsi sama dengan aplikasi lama Anda.

Migrasikan pustaka inti dalam iterasi

Dan akhirnya migrasi perhitungan dan algoritme di "pustaka" COBOL / BASIC Anda, implementasikan kembali di lingkungan baru Anda. Sekali lagi, lakukan ini secara iteratif dengan menggunakan tes (unit) sebagai cara untuk menjaga kewarasan Anda.


1
Meskipun jawaban Anda bagus ketika dilihat untuk dirinya sendiri, sayangnya itu tidak benar-benar fokus pada pertanyaan. Penanya adalah manajer non-TI yang sangat mungkin tidak tahu apa yang Anda maksud dengan sebagian besar dari apa yang Anda tulis. Dia perlu saran untuk menemukan seseorang yang melakukannya.
Philipp

1
@ Pilip: Terlihat dengan baik meskipun saya mengatakan bahwa saya tidak menjawab pertanyaannya yang sebenarnya. Saya yakin OP tahu cara menggunakan Google dan ada cukup istilah pencarian dalam jawaban saya untuk OP untuk memulai penelitian - atau lebih baik lagi - memiliki programer saat ini melakukannya. Jangan ragu untuk menambahkan jawaban Anda sendiri yang membahas OP karena menurut Anda perlu dilakukan. Heck, bahkan mungkin akan menang jika Anda melakukannya ...
Marjan Venema

Dia akan membutuhkan konsultan IT bisnis untuk proses transisi, yang telah membantu dalam proses seperti itu sebelumnya. Konsultan seharusnya tidak melakukan pekerjaan, tetapi sebaliknya harus menemukan orang-orang yang melakukan pekerjaan, mengawasi mereka, dan memastikan bahwa program melakukan apa yang diperlukan untuk bisnis. Ya itu mahal. Selalu memiliki perangkat lunak Anda sendiri.
MSalters

@MarjanVenema (Saya tidak tahu persis apa yang saya harapkan ketika saya memposting pertanyaan ini, tetapi satu hal yang saya tidak harapkan adalah bahwa hampir setiap komentar akan bijaksana dan berguna - banyak yang berpikir untuk semua.) Saya membaca rekomendasi Anda " bagaimana untuk bertahan hidup "posting oleh Milstein, dan posting Spolsky dia merespons, dan bahkan Milstein tidak suka ide menulis ulang kode. Berdasarkan pengalaman kami sejauh ini, komentar Spolsky tentang bahaya migrasi data dan nilai kode kerja benar. Saya benar-benar khawatir bahwa saya menyerah pada angan-angan tetapi saya benar-benar ingin menganggap Ramhound benar.
user105977

1
@ user105977: Saya mengerti. Ya menulis ulang itu berisiko, tetapi tidak selalu dapat dihindari dan kadang-kadang cara terbaik untuk maju meskipun ada risiko. Bagi saya menjaga sistem lama, bergantung pada skillet yang bahkan sekarang tidak tersedia, adalah risiko bisnis yang mungkin lebih besar daripada risiko penulisan ulang dan meningkat seiring waktu seiring bertambahnya kumpulan pengembang yang tersedia menurun. Tetapi saya tidak dalam posisi Anda dan tidak dapat menilai risiko relatif mereka.
Marjan Venema

2

Sepertinya aplikasi ini "inti" untuk bisnis Anda. Dalam kasus di mana suatu sistem atau proses adalah apa bisnis Anda itu adalah kasus untuk memiliki solusi kustom Anda sendiri.

Anda menyinggung ini. Sayangnya mengingat lama waktu yang Anda habiskan sejak memperbarui teknologi, ini akan menjadi tugas yang sangat sulit.

Saya akan merekomendasikan satu dari dua rute.

  1. Staf kelompok TI pengembang / manajer proyek / QE / operasi dan membangun sistem Anda secara bertahap, seperti yang disebutkan dalam jawaban yang agak teknis di atas. Namun ini akan menjadi sangat mahal.
  2. Daripada penyedia rak, mencari konsultan pengembang kustom yang memenuhi syarat. Grup ini akan menangani semua sumber daya untuk membangun sistem baru Anda, maka Anda dapat membawanya dengan staf kecil daripada opsi 1 untuk melanjutkan. Opsi ini memiliki serangkaian risiko berbeda, namun memilih penyedia yang baik bisa sangat sulit bagi yang non-teknis. Mereka juga bisa berisiko sangat tinggi dengan pembengkakan biaya, dll. Untuk mengurangi rute ini, gunakan staf Anda yang sudah ada untuk menyusun serangkaian persyaratan yang sangat rinci (dari perspektif pengguna) untuk tawaran Anda. Kemudian minta penawaran harga tetap juga.

Semoga beruntung, Anda memiliki sekitar 20 tahun warisan untuk diatasi. Itu tidak akan murah, mudah, atau bersih.


1
FYI: 20 tahun di dunia perangkat lunak setara dengan 2 atau 3 generasi manusia. Ini waktu yang sangat lama. Dari sudut pandang teknologi, BASIC dan COBOL sudah cukup tua untuk ditempatkan di museum ...
Radu Murzea

Sebenarnya saya sudah pemrograman selama 20 tahun dan COBOL mendahului pengalaman saya.
Bill Leeper

-2

Daripada mencari perusahaan untuk memelihara perangkat lunak warisan Anda atau perusahaan untuk menulis ulang perangkat lunak warisan Anda, mencari perusahaan untuk memberikan layanan sistem administrasi manfaat lanjutan. Alihkan masalah untuk memutuskan apakah akan menulis ulang perangkat lunak atau tidak, jadwal apa yang harus ditentukan, bahasa atau alat apa yang digunakan.

Ya, biaya yang jelas dari pendekatan ini mungkin melebihi biaya yang jelas untuk merekrut programmer baru, tetapi, menurut pengakuan Anda sendiri, Anda adalah manajer non-TI dan mudah untuk memperkirakan skenario di mana Anda membuat keputusan yang pada akhirnya membuat perusahaan Anda lebih mahal daripada biaya outsourcing yang jelas.


1
Paragraf kedua menyatakan bahwa mereka telah melakukan apa yang Anda sarankan: mereka telah mengidentifikasi ketiga perusahaan yang menyediakan perangkat lunak administrasi manfaat. Tak satu pun dari mereka yang memenuhi syarat.
MSalters

Saya tidak menyarankan mereka mencari perusahaan untuk menyediakan perangkat lunak, melainkan layanan sistem administrasi manfaat berkelanjutan .
High Performance Mark
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.