LANGKAH-LANGKAH PEMROGRAMAN

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. Bab 9 ini merinci beberapa metode untuk menggabungkan bagian-bagian tersebut, tetapi anda harus merencanakan urutan penggabungan ini sekarang, karena anda harus menulis program supaya dapat digabungkan. Ini disebut Rencana Tes Sistem (System Test Plan).

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. Level disain modul tingkat menengah dapat dilihat pada gambar 9.1.

Lihat Gambar 9.1. Medium level desin (3^rd level)

Programmer menerima penjelasan modul dari perancang seperti berikut ini.

Lihat Gambar penjelasan modul

Programmer pertama-tama menggambarkan diagram struktur dari modul. Terlihat seperti pada gambar 9.2.

Lihat Gambar 9.2. Fourth level module breakout

Disain modul adalah pendekatan top-down dimulai dengan kotak paling atas, AMST000 dan dipecah ke dalam sub-komponen yang tepat, seperti pada gambar 9.3.

Lihat Gambar 9.3. Fifth level module breakout

Kemudian setiap sub-komponen dapat dibagi lagi, seperti pada gambar 9.4.

Lihat Gambar 9.4. Sixth level module breakout

Dan kemudian modul tersebut dipecah lagi sampai tercapai sebuah tingkatan dimana mulai dapat diprogram.

Pertanyaan yang bisa diajukan adalah : “Pada tingkatan mana disain sistem berhenti dan disain modul dimulai ?”. Jawabannya adalah “Disain sistem dipecah sampai pada tingkat dimana programmer dapat memulainya”. Tingkatan ini dapat bermacam-macam dari proyek ke proyek dan bahkan dari satu bagian sistem ke bagian lainnya – tergantung pada programmer yang menerima bagian tersebut.

Adapun pertimbangan lainnya adalah :

· 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 kontrak.

· 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 perlu diingat bahwa programmer tidak senang menerima disain yang terlalu rinci, yang programnya adalah menerjemahkan bahasa Inggris yang sederhana, seperti pernyataan-pernyataan secara harafiah ke dalam bahasa pemrograman.

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 (lihat bagian 7.12). 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 (lihat bagian 9.4).

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.

LANGKAH-LANGKAH PEMROGRAMAN

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. Bab 9 ini merinci beberapa metode untuk menggabungkan bagian-bagian tersebut, tetapi anda harus merencanakan urutan penggabungan ini sekarang, karena anda harus menulis program supaya dapat digabungkan. Ini disebut Rencana Tes Sistem (System Test Plan).

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. Level disain modul tingkat menengah dapat dilihat pada gambar 9.1.

Lihat Gambar 9.1. Medium level desin (3^rd level)

Programmer menerima penjelasan modul dari perancang seperti berikut ini.

Lihat Gambar penjelasan modul

Programmer pertama-tama menggambarkan diagram struktur dari modul. Terlihat seperti pada gambar 9.2.

Lihat Gambar 9.2. Fourth level module breakout

Disain modul adalah pendekatan top-down dimulai dengan kotak paling atas, AMST000 dan dipecah ke dalam sub-komponen yang tepat, seperti pada gambar 9.3.

Lihat Gambar 9.3. Fifth level module breakout

Kemudian setiap sub-komponen dapat dibagi lagi, seperti pada gambar 9.4.

Lihat Gambar 9.4. Sixth level module breakout

Dan kemudian modul tersebut dipecah lagi sampai tercapai sebuah tingkatan dimana mulai dapat diprogram.

Pertanyaan yang bisa diajukan adalah : “Pada tingkatan mana disain sistem berhenti dan disain modul dimulai ?”. Jawabannya adalah “Disain sistem dipecah sampai pada tingkat dimana programmer dapat memulainya”. Tingkatan ini dapat bermacam-macam dari proyek ke proyek dan bahkan dari satu bagian sistem ke bagian lainnya – tergantung pada programmer yang menerima bagian tersebut.

Adapun pertimbangan lainnya adalah :

· 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 kontrak.

· 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 perlu diingat bahwa programmer tidak senang menerima disain yang terlalu rinci, yang programnya adalah menerjemahkan bahasa Inggris yang sederhana, seperti pernyataan-pernyataan secara harafiah ke dalam bahasa pemrograman.

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 (lihat bagian 7.12). 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 (lihat bagian 9.4).

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.

Ciri-Ciri Hipotesis yang Baik

Karakteristik Hipotesis yang Baik
Sebuah hipotesis atau dugaan sementara yang baik hendaknya mengandung beberapa hal. Hal – hal tersebut diantaranya :
1) Hipotesis harus mempunyai daya penjelas
2) Hipotesis harus menyatakan hubungan yang diharapkan ada di antara variabel-variabel-variabel.
3) Hipotesis harus dapat diuji
4) Hipotesis hendaknya konsistesis dengan pengetahuan yang sudah ada.
5) Hipotesis hendaknya dinyatakan sesederhana dan seringkas mungkin.

Berikut ini beberapa penjelasan mengenai Hipotesis yang baik :
- Hipotesis harus menduga Hubungan diantara beberapa variabel
Hipotesis harus dapat menduga hubungan antara dua variabel atau lebih, disini harus dianalisis variabel-variabel yang dianggap turut mempengaruhi gejala-gejala tertentu dan kemudian diselidiki sampai dimana perubahan dalam variabel yang satu membawa perubahan pada variabel yang lain.

- Hipotesis harus Dapat Diuji
Hipotesis harus dapat di uji untuk dapat menerima atau menolaknya, hal ini dapat dilakukan dengan mengumpulkan data-data empiris.

- Hipotesis harus konsisten dengan keberadaan ilmu pengetahuan-
Hipotesis tidak bertentangan dengan pengetahuan yang telah ditetapkan sebelumnya. Dalam beberapa masalah, dan terkhusus pada permulaan penelitian, ini harus berhati-hati untuk mengusulkan hipotesis yang sependapat dengan ilmu pengetahuan yang sudah siap ditetapkan sebagai dasar. Serta poin ini harus sesuai dengan yang dibutuhkan untuk memeriksa literatur dengan tepat oleh karena itu suatu hipotesis harus dirumuskan bedasar dari laporan penelitian sebelumnya.

- Hipotesis Dinyatakan Secara Sederhana
Suatu hipotesis akan dipresentasikan kedalam rumusan yang berbentuk kalimat deklaratif, hipotesis dinyatakan secara singkat dan sempurna dalam menyelesaikan apa yang dibutuhkan peneliti untuk membuktikan hipotesis tersebut.

MENGUJI HIPOTESIS
Suatu hipotesis harus dapat diuji berdasarkan data empiris, yakni berdasarkan apa yang dapat diamati dan dapat diukur. Untuk itu peneliti harus mencari situasi empiris yang memberi data yang diperlukan. Setelah kita mengumpulkan data, selanjutnya kita harus menyimpulkan hipotesis , apakah harus menerima atau menolak hipotesis. Ada bahayanya seorang peneliti cenderung untuk menerima atau membenarkan hipotesisnya, karena ia dipengaruhi bias atau perasangka. Dengan menggunakan data kuantitatif yang diolah menurut ketentuan statistik dapat ditiadakan bias itu sedapat mungkin, jadi seorang peneliti harus jujur, jangan memanipulasi data, dan harus menjunjung tinggi penelitian sebagai usaha untuk mencari kebenaran.

Cara Membuat Hipotesis yang Baik

Persyaratan untuk Membuat Hipotesis yang Baik yaitu :
- Berupa pernyataan yang mengarah pada tujuan penelitian dan dirumuskan dengan jelas.
- Berupa pernyataan yang dirumuskan dengan maksud untuk dapat diuji secara empiris. Menunjukkan dengan nyata adanya hubungan antara dua variabel atau lebih.
- Berupa pernyataan yang dikembangkan berdasarkan teori-teori yang lebih kuat dibandingkan dengan hipotesis rivalnya dan didukung oleh teori-teori yang dikemukakan oleh para ahli atau hasil penelitian yang relevan.

Menurut bentuknya, Hipotesis dibagi menjadi tiga
1. Hipotesis penelitian / kerja: Hipotesis penelitian merupakan anggapan dasar peneliti terhadap suatu masalah yang sedang dikaji.
Dalam Hipotesis ini peneliti mengaggap benar Hipotesisnya yang kemudian akan dibuktikan secara empiris melalui pengujian Hipotesis dengan mempergunakan data yang diperolehnya selama melakukan penelitian.
Misalnya: Ada hubungan antara krisis ekonomi dengan jumlah orang stress
2. Hipotesis operasional: Hipotesis operasional merupakan Hipotesis yang bersifat obyektif.
Artinya peneliti merumuskan Hipotesis tidak semata-mata berdasarkan anggapan dasarnya, tetapi juga berdasarkan obyektifitasnya, bahwa Hipotesis penelitian yang dibuat belum tentu benar setelah diuji dengan menggunakan data yang ada. Untuk itu peneliti memerlukan Hipotesis pembanding yang bersifat obyektif dan netral atau secara teknis disebut Hipotesis nol (H0).
H0 digunakan untuk memberikan keseimbangan pada Hipotesis penelitian karena peneliti meyakini dalam pengujian nanti benar atau salahnya Hipotesis penelitian tergantung dari bukti-bukti yang diperolehnya selama melakukan penelitian.
Contoh: H0: Tidak ada hubungan antara krisis ekonomi dengan jumlah orang stress.
3. Hipotesis statistik: Hipotesis statistik merupakan jenis Hipotesis yang dirumuskan dalam bentuk notasi statistik.
Hipotesis ini dirumuskan berdasarkan pengamatan peneliti terhadap populasi dalam bentuk angka-angka (kuantitatif).
Misalnya: H0: r = 0; atau H0: p = 0