!p@N™

Periode percobaan atau parallel run adalah pendekatan yang paling umum untuk penerimaan. Menggunakan pendekatan ‘Periode Percobaan’ tim proyek mudah memasang sistem baru untuk dicoba oleh user. Pendekatan ‘Parallel Run’ menambahkan dimensi untuk peralihan sistem lama yang sudah berjalan dengan baik sebagai perbandingan dan cadangan.

Dalam kedua kasus ini klien menggunakan sistem baru selama ‘X’ hari. Jika tidak ada masalah maka user menerimanya, jika ada masalah maka tim proyek berusaha memperbaikinya dan melakukan kembali percobaan selama ‘X’ hari.

Pendekatan ini cukup mudah, tetapi ada beberapa kekurangan :
1. Masalah kecil dapat membuat anda menjalankan kembali selama ‘X’ hari untuk jangka waktu yang tidak terbatas. Kadang-kadang sistem software yang rumit tidak pernah 100% di-debug.


2. Mungkin sulit untuk mencari penyebab dari suatu masalah. Jika 10 user berada pada sistem yang interaktif dan sistem tersebut rusak, ini merupakan tantangan untuk menemukan dengan tepat apa yang menyebabkan sistem tersebut rusak.

3. Tidak ada jaminan bahwa semua kelebihan sistem akan dicoba dalam ‘X’ hari. Penulis pernah melihat sebuah sistem akuntansi yang diterapkan pada awal tahun fiskal baru. Sistem itu berjalan baik selama masa percobaan (6 bulan) sampai mengalami kegagalan pada akhir tahun fiskal ketika akuntan mencoba untuk melakukan tutup buku. Sayangnya garansinya telah habis dan penjual (vendor) tidak mau memperbaikinya.

4. Biarkan end user masuk ke sistem pada hari pertama yang penerapannya tidak selalu bermanfaat. Karena dalam hal ini faktor penampilan lebih berperan. Seperti dalam roman, kesan pertama sangat penting..

Langkah 1. Rencana Penggabungan (Plan The Integration)
Menurut akal sehat anda tidak akan dapat membuat semua program sekaligus dan kemudian membuang semuanya – ini memerlukan rangkaian langkah demi langkah. Rencanakan urutan dimana anda akan menggabungkannya.
Langkah 2. Mendisain Modul (Design The Module)
Programmer menerima beberapa tingkatan disain dari fase disain. Tugasnya adalah memecah modul secara rinci ke tingkat yang lebih rendah sampi mencapai keadaan programmer siap untuk melakukan pemrograman. Ini disebut disain modul.
Langkah 3. Telusuri Disain Modul(Walk Through The Module Design)
Seperti pada tingkat atas dan menengah dari disain, pertukaran harus dibuat sebaiknya pada tingkat yang paling rendah. Telusuri disain dari masing-masing modul sebelum melakukan pengkodean. Penelusuran ini sangat kecil : hanya programmer yang tepat, supervisor dan mungkin programmer lainnya yang perlu diperhatikan. Kegunaan dari penelusuran disain modul adalah untuk memastikan bahwa disain yang terbaik yang telah dilakukan, semua fungsi telah dialamatkan dan semua bagian telah ditangani.
Langkah 4. Rencana Bagaimana Menguji Modul (Plan How To Test The Module)
Programmer harus menyiapkan rencana pengujian modul dan data pengujian sebelum dikodekan. Rencana pengujian dilakukan setelah kode ditetapkan. Mereka cenderung hanya menguji bagian kode yang paling ‘sulit’. Pimpinan proyek bisa saja melakukan tuntutan pada penelusuran rencana pengujian sepanjang disain modul sedang dilaksanakan. Kerjakan penelusuran ini bersama-sama.
Langkah 5. Kode Setiap Modul (Code Each Module)
Standar pengkodean akan ditetapkan pada saat disain sistem. Kita tidak membahas bagaimana membuat program – lihat Referensi 12 (tulisan ini membahas disain sama baiknya dengan pemrograman) dan Referensi 13 untuk lebih jelasnya.
Berikut ini adalah ringkasan dari sebuah program terstruktur, yaitu :
· Jika berukuran kecil. Aturan dasarnya adalah kira-kira 100 baris kode yang dapat dieksekusi dan listingnya tidak lebih dari 2 halaman.
· Satu entry, satu exit.
· Referensi secara keseluruhan sedikit.
· Konstruksi terstruktur yang digunakan : berurutan, IF/THEN/ELSE, CASE, WHILE, UNTIL, CALL (bukan GO TO).
Langkah 6. Menguji Modul (Test The Module)
Programmer menguji modul dengan menetapkan lingkungan yang tepat, menyediakan beberapa input, membiarkan modul langsung memproses secara logik dan mendapatkan hasilnya. Beberapa input mungkin tidak sebenarnya, terutama jika modul tersebut tidak menyediakan input yang sebenarnya.
Modul seharusnya diuji dalam dua tahap, yaitu :
· Tahap Pertama disebut pengujian “White Box”. Programmer harus mengetahui isi di dalam modul dan menyediakan data pengujian, sehingga masing-masing path logical dalam program dapat dieksekusi.
· Tahap Kedua atau pengujian “Black Box” dapat dilakukan. Dalam pengujian ini, programmer mengabaikan bagian dalam dari modul – data disediakan secara berurut dan dianggap seperti pemakaian sebenarnya.
Langkah 7. Menguji Level Terendah dari Integrasi (Test The Lowest Levels Of Integration)
Jika modul utama memanggil sub-modul, programmer harus menggabungkan dan menguji semua modul secara bersama-sama. Bahkan jika programmer tidak bertanggung jawab untuk menulis sub-modul, programmer harus menguji perintah CALL dan RETURN dari seluruh modul.
Metode terbaik untuk melakukan hal ini adalah membuat sebuah “program stub” (potongan program) sebagai pengganti sub-modul. Potongan program ini dapat terdiri dari empat baris program yang menunjukkan bahwa kontrol sudah diterima dengan baik, tampilkan parameter penerima, jika perlu lakukan pengontrolan kembali dengan beberapa parameter yang tidak sebenarnya.
Langkah 8. Menyimpan Semua Hasil Pengujian; Penggabungan Modul-modul Yang Telah Diuji (Save The Results Of All Tests; Submit Finished Modules To Integration)
Hasil pengujian digunakan untuk menyusun statistik yang menunjukkan penyebab, cara perbaikan serta biaya-biaya yang dibutuhkan untuk memperbaiki kesalahan-kesalahan program. Pimpinan proyek biasanya menguasai/mengepalai penggabungan ini pada sistem berukuran kecil sampai sedang.
Software seperti CMS (Code Management System) sangat berguna untuk menajemen konfigurasi – menjamin program tetap berjalan sesuai versinya dan mengubah ke source code.
Langkah 9. Memulai Dokumentasi User (Get Started On The User Documentation)
Apakah programmer bertanggung jawab pada dokumentasi user atau tidak, tahapan ini adalah waktu terbaik untuk menjawabnya.

Dengan kemajuan teknologi keinginan dan kebutuhan akan informasi semakin meningkat juga, apalagi sekarang mulai masuk era online, era cepat saji, sehingga kebutuhan akan data dan informasi yang cepat saji menjadi keinginan mutlak pimpinan,institusi bahkan client kita. Untuk itu perancanagn sistem atau program untuk memenuhi kebutuhan tersebut harus dirancang dengan baik dan tepat, apalagi sekarang banyak pemimpin yang sebenarnya tidak mengetahui seluk beluk dari sistem/program tapi berani memutuskan untuk merancang dan menyediakan sistem/program tersebut dalam waktu yang singkat. Bahkan menganggap membuat program seperti kayaknya menggoreng tempe yang menunggu minyak panas tempe dimasukkan, dibolak-balik dah jadi tidak sampai 30 dah jadi. Berdeda dengan prorgram dah jadi yang sudah menjadi produk masal, tidak membutuhkan modifikasi. kalau itu tinggal membeli cd program dah jadi tersebut sehingga tidak usah memerlukan analisis lagi karena programnya dah jadi dan ndak bisa/perlu di modif.

Untuk bisa menghasilkan program yang baik memerlukan analisis yang baik pula, baik itu analisis sistem, stuktur data maupun analisis requirement, selin itu juga dipelukan persiapan-persiapan yang matang. Hal ini berlaku bagi siapapun, bahkan seorang programmer professional sekalipun. Sedangkan tahapan apas aja untuk membuat program yang baik akan saya jelaskan dibawah.

Program memang sudah menjadi kebutuhan pokok bagi masyarakat IT. karena segala sesuatu yang dilakukan di dalam IT pastilah memerlukan program. Program yang paling sederhana sekalipun setidaknya memiliki 3 bagian:

1. Input – Masukan data.
2. Proses – pemrosesan input.
3. Output – keluaran program, kebutuhan yang kita harapkan.

Dalam membuat program, pemrograman adalah pokok dari proses pembuatan program itu sendiri namun pemrograman bergantung dari pemahaman persoalan, analisis sistem, perencanaan-perencanaan dalam mendesain program itu sendiri.

Selain pemrograman hal yang utama harus dilakukan adalah merencanakan langkah-langkah yang harus diambil dalam menyelesaikan masalah. Karena dengan mengetahui masalah dan langkah-langkah penyelesaikan berarti kita sudah menyelesaikan program tersebut sebanyak 50% dari total pekerjaan, selanjutnya adalah teknis pembuatan itu sendiri yang di kenal dengan pemrograman/koding.Sebaliknya jika kita tidak bisa mengetahui masalah dan belum bisa membuat perencanaan berarti kita sudah merencanakan kegalan itu sendiri.

Dalam membuat sebuah program setidaknya ada beberapa hal yang perlu anda lakukan:

1. Mendefinisikan Masalah/Defining the problem
   Masalah/Probem disini adalah kompenan apa saja yang diperlukan agar program ini jalan dikenal dengan masukan/inputnya apa saja, mendefinisikan apa yang nanti akan dilakukan oleh program dan bagaimana keluaran dari program yang kita harapkan nantinya. Pada tahap ini juga dikenal requirement analisis atau analisa kebutuhan.
2. Perencanaan/Planning/Desain sistem
   Pada tahap ini adalah medefinisikan langkah-langkah apa saja yang dilakukan oleh program dalam menyelesaikan permasalahan yang ada. Bentuk dari perencanaan itu bisa berupa flowchart ataupun algoritma dari program, sehingga kita akan tahu proses apa saja yang ada dalam program tersebut. semakin detail flowchart atau algoritma yang dibuat semakin mudah juga pada tahap implementasi/coding nantinya.

Flowchart adalah suatu diagram menggunakan simbol-simbol khusus yang sudah menjadi standard internasional yang berisi langkah-langkah untuk menyelesaikan suatu masalah. sedangkan algoritma kbukan merupakan simbol tapi keterangan-keterangan yang sesuai dengan keinginan kita, tidak ada standarnya. Oleh karena itu flowchart biasa juga disebut sebagai algoritma dalam bentuk simbol-simbol khusus yang dihubungkan dengan anak panah.

Membuat flowchart terlebih dahulu akan lebih menghemat waktu daripada langsung melakukan coding sambil mencoba-coba. Kegiatan mencoba-coba akan menghabiskan waktu ketika implementasi/koding karena harus merubah koding yang lumayan banyak. Karena itu, biasakan membuat flowchart terlebih dahulu sebelum memecahkan suatu masalah.

3. Implementasi/Koding/Programming
   Kini saatnya anda menulis program, tahap ini juga mencakup tahap perbaikan error dan testing. Menulis program dengan terstruktur dan sesuai dengan flowchart yang telah kita buat.
4. Dokumentasi/Documentation
   Setelah tahap coding selesai, sangat disarankan bagi anda untuk membuat semacam dokumentasi. Tambahkan komentar-komentar pada program anda dan “bukukan” program yang akan anda buat. Hal ini akan bermanfaat jika anda sudah membuat program yang begitu banyak, dan suatu ketika nanti (mungkin bertahun-tahun kemudian) anda ingin mengambil sebagian dari code program anda yang lama untuk disisipkan pada program anda yang baru. Bayangkan jika anda tidak membuat dokumentasi, waktu anda akan sangat terbuang dengan menelusuri program-program lama anda satu-persatu.
5. Testing
• Unit Testing
  Menguji setiap unit dan modul yang terdapat dalam program tersebut
• Integration Testing
  Menguji integrasi yang dilakukan kepada program seperti halnya ketika program tersebut sudah diinstall di client kita yang membutuhkan integrasi dengan sisitem yang lain seperti halnya integrasi dengan database.
• Validation Testing
  menguji masukan yang diberikan kepada program. apapun masukannya program harus bisa menyelesaikan dengan baik.
• Sistem Testing
  Pada tahap ini menguji permorfa dari program, apabila program dijalankan dengan kondisi-kondisi tertentu bagaimana?
6. Operasional dan Maintenance
   Pada tahap ini sebenarnya bagaimana program yang telah kita buat dan testing ini bekerja sebagaimana mestinya, update program, menyeselaikan bug yang tidak ditemukan pada saat testing, serta pengembangan yang dapat dilakukan dengan program tersebut.

Setelah kita tahu bagaimana atau langkah -langkah dalam membuat program yang baik, alangkah sebaiknya dalam perencanaan sistem atau program tidak asal-asalan bahkan hanya menganggap seperti menggoreng tempe itu tadi, dibolak-balik matang, ingat Programmer juga manusia.. bukan robot yang sekali pencet bisa menyelesaikan masalah.