Aktifitas pada fase ini adalah menulis program. Kejadian pentingnya adalah menguji program, rencana tes sistem, dan paling tidak mulai pada dokumentasi user.
Berikut langkah-langkah dalam pemrograman:
1. Rencana Penggabungan (Plan The Integration)
2. Mendisain Modul (Design The Module)
3. Telusuri Disain Modul (Walk Through The Module Design)
4. Rencana Bagaimana Menguji Modul (Plan How To Test The Module)
5. Kode Setiap Modul (Code Each Module)
6. Menguji Modul (Test The Module)
7. Menguji Level Terendah dari Integrasi (Test The Lowest Levels Of Integration)
8. Menyimpan Semua Hasil Pengujian; Penggabungan Modul-Modul yang telah Diuji (Save The Results of All Tests; Submit Finished Module to Integration)
9. Memulai Dokumentasi User (Get Started on The User Documentation)
Fase Pemrograman
1. Rencana Penggabungan (Plan The Integration)
Merincikan beberapa metode untuk menggabungkan bagian-bagian tersebut dan harus merencanakan urutan penggabungannya agar program tersebut dapat digabungkan.
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 hingga mencapai keadaan siap untuk melakukan pemrograman, hal ini disebut sebagai disain modul.
Adapun pertimbangan lainnya:
· Jika pemecahan modul yang dihasilkan adalah sangat penting yang memerlukan prioritas seperti adanya respon, user-friendly, atau konsistensi, perancang bisa melanjutkan ke tingkat yang lebih rendah.
· Tingkat pemecahan dari disain dinyatakan dengan kontak.
· Jika programmer tidak mengetahui pada waktu disain, pengetahuan programmer tingkat menengah dapat diasumsikan, dan disain dapat diambil alih oleh programmer tingkat menengah yang dapat mengatasinya.
Tetapi programmer tidak senang menerima disain yang terlalu rinci, yang programnya adalah menerjemahkan bahasa Inggris sederhana, seperti pernyataan secara harafiah ke dalam bahasa pemrograman.
3. Telusuri Disain Modul (Walk Through The Module Design)
Pada fase ini, dianjurkan untuk menelusuri disain dari masing-masing modul sebelum melakukan pengkodean. Kegunaan dari penelusuran disain modul adalah untuk memastikan bahwa disain terbaik yang telah dilakukan, semua fungsi telah dialamatkan dan semua bagian telah ditangani.
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 dan 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.
5. Kode Setiap Modul (Code Each Module)
Standar pengkodean akan ditetapkan pada saat disain sistem. 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).
6. Menguji Modul (Test The Module)
Programmer menguji modul dengan menetapkan lingkungan yang tepat, menyediakan beberapa input, membiarkan modul langsung memproses secara logic 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.
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.
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 atau 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.
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. Dokumen-dokumen berikut mungkin harus ditulis :
Tuntunan Pemakai (User’s Guide)
Dokumen ini dapat ditulis oleh programmer, penulis teknis atau bahkan user sendiri. Tampilkan kembali FS yang mempunyai bagian rinci mengenai menu, layar, form, dan user interface lainnya.
USER’S GUIDE yang baik adalah terbagi dalam bagian-bagian yang menunjukkan tingkatan user yang berbeda-beda. Sebagai contoh, dalam USER’S GUIDE sistem ABC, harus ada bagian yang disebut “Registrar’s Functions” atau “Warehouse Functions” atau lainnya. Materinya harus disesuaikan agar user dapat menggunakan secara normal. Hal ini membuat USER’S GUIDE berguna untuk mempelajari sistem.
Tuntunan Pemeliharaan (Maintenance Guide)
Bagaimana anda menemukan programmer untuk merinci dokumen dari program mereka untuk pemeliharaan berikutnya ? Kebanyakan Manajer proyek mengalami kesulitan dalam hal berikut : programmer enggan untuk melakukan dokumentasi sebelum program ditulis; dan beruntunglah menemukannya setelah semuanya selesai dikerjakan. Programmer berpikir bahwa pemeliharaan memerlukan penjelasan secara rinci dari logika pemrograman. Sangat membosankan untuk menulisnya dan sebenarnya tidak perlu. Berikut ini adalah solusi sederhana tentang hal tersebut : lebih baik merinci spesifikasi disain tingkat modul secara struktur, mendokumentasikan sendiri kode, dirasa cukup untuk pemeliharaan sistem.
MAINTENANCE GUIDE akan berisi spesifikasi disain, listing program dan penjelasan bagaimana semuanya disesuaikan, bagaimana mengubah pendekatan, dan bagaimana menghubungkan dan menguji semuanya.
Tuntunan Operator atau Tuntunan Manajer Sistem (Operator’s Guide or System Manager’s Guide)
Sama seperti USER’S GUIDE untuk orang-orang yang menghidupkan sistem di pagi hari, mematikannya, melakukan backup, menangani permasalahan utama, melakukan perhitungan, dsb. Dokumentasi yang disediakan oleh perusahaan hardware dan sistem operasi mungkin cukup – hanya prosedur untuk software tertentu yang harus ditulis ulang.
Dokumentasi Pelatihan (Training Documentation)
Jika anda akan memberikan kursus bagaimana menggunakan sistem, rencanakan apakah materi pelatihan akan diperlukan. USER’S GUIDE yang baik harusnya menambahkan hal ini. Anda mungkin harus membuat bantuan pelatihan, seperti transaparansi, buku latihan, pengujian, dan sebagainya.
Sumber: http://wsilfi.staff.gunadarma.ac.id/Downloads/files/20196/Pertemuan+09+-+Fase+Pemrograman.pdf