Keuntungan Membangun Software Menggunakan Protipe dan Langkah-Langkah Membangun Prototipe

Kesalahpahaman antara user dan analis mengakibatkan perubahan yang berarti atau sistem tidak akan pernah sempurna dalam pelaksanaannya atau sekaligus ditolak. Prototipe dapat memecahkan masalah ini untuk tipe-tipe tertentu dalam sistem.
Jika perubahan diperlukan prototipe dapat dimodifikasi, memungkinkan dimodifikasi beberapa kali sampai keadaaan yang ditetapkan user.
Keuntungan menggunakan prototipe dalam membangun software:
1. Menghasilkan syarat yang lebih baik dari produksi yang dihasilkan oleh metode ‘spesifikasi tulisan’.
2. User dapat mempertimbangkan sedikit perubahan selama masih bentuk prototipe.
3. Memberikan hasil yang lebih akurat dari pada perkiraan sebelumnya, karena fungsi yang diinginkan dan kerumitannya sudah dapat diketahui dengan baik.
4. User merasa puas. Pertama, user dapat mengenal melalui komputer. Dengan melakukan prototipe (dengan analisis yang sudah ada), user belajar mengenai komputer dan aplikasi yang akan dibuatkan untuknya. Kedua, user terlibat langsung dari awal dan memotivasi semangat untuk mendukung analisis selama proyek berlangsung.

Langkah-langkah pembuatan prototipe :
1. Permintaan bermula dari kebutuhan user.
2. Bangunlah sistem prototipe untuk menemukan kebutuhan awal yang diminta.
3. Biarkan user menggunakan prototipe. Analis harus memberikan pelatihan, membantu dan duduk bersama-sama dengan user, khususnya untuk pertama kali. Anjurkan perubahan. User harus melihat fungsi-fungsi dan sifat dari prototipe, lihat bagaimana ia memecahkan masalah bisnis dan mengusulkan perbaikan.
4. Implementasikan saran-saran perubahan.
5. Ulangi langkah ketiga sampai user merasa puas.
6. Merancang dan membangun suatu sistem akhir seperti sebelumnya.

Sistem yang paling sesuai untuk prototipe adalah satu dari banyak hal yang bergantung pada sistem input/output dari user. Sistem dengan transaksi on-line dikendalikan melalui menu, layar, formulir, laporan, daftar dan perintah.

Teknik Estimasi pada Suatu Proyek Sistem Informasi

Estimasi merupakan sebuah proses pengulangan. Pemanggilan ulang estimasi yang pertama dilakukan selama fase definisi, yaitu ketika anda menulis rencana pendahuluan proyek. Hal ini perlu dilakukan,karena anda membutuhkan estimasi untuk proposal. Setelah fase analisis direncanakan ulang, anda harus memeriksa estimasi dan merubah rencana pendahuluan proyek menjadi rencana akhir proyek.

TEKNIK–TEKNIK ESTIMASI

Ada tiga teknik yang digunakan untuk melakukan estimasi, yaitu :

1. Keputusan Profesional

Katakanlah bahwa anda merupakan orang yang memiliki pengalaman yang luas dalam membuat program “report generation modules”. Anda melakukannya dengan pendekatan merancang report tersebut dan memperkirakan berapa lama waktu yang dibutuhkan untuk membuat program tersebut. Setelah mempelajari rancangan program selama 5 menit, programmer lalu menutup matanya selama 5 menit (dia tidak tidur, tetapi berhitung), dan kemudian mengatakan “15 hari”. Inilah yang disebut Keputusan Profesional murni. Keuntungan dari teknik ini adalah cepat , dan jika seseorang sudah ahli dalam teknik ini, maka estimasinya pasti akan lebih akurat. Sedangkan kerugian dari teknik ini adalah bahwa anda membutuhkan seorang ahli yang berpengalaman dalam bidang ini, dan beberapa ahli tersebut akan bekerja keras untuk mendapatkan estimasi yang tepat.

2. Sejarah

Jalan keluar dari ketergantungan pada orang dan untuk membuat estimasi lebih khusus, yaitu anda harus mengerti tentang sejarahnya. Tulislah berapa lama masing-masing tugas dapat diselesaikan dan siapa yang bertanggung jawab atas tugas tersebut. Anda dapat membandingkan tuagas yang akan diestimasik dengan tugas yang sama yang dikerjakan lebih awal, setelah itu mulailah dengan melakukan estimasi. Hal ini dimaksudkan agar anda menjabarkan suatu proyek ke dalam beberapa tugas yang biasanya diulang dan mudah untuk dibandingkan.

3. Rumus-rumus

Ada beberapa rumus yang digunakan dalam software estimasi. Software yang baik untuk diketahui adalah COCOMO (Referensi 15). COCOMO dapat digunakan untuk memperkirakan biaya proyek, usaha (person months), jadwal, dan jumlah staf untuk masing-masing fase berikut ini :

- Preliminary Design – our Analysis Phase

- Detailed Design (DD) – our Design Phase

- Code and Unit Tes (CUT) – same as ours

- System Test – our System Test and Acceptance Phase

Langkah - Langkah Pemrograman

Langkah 1. Rencana Penggabungan (Plan The Integration)

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.

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.

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.

Penjelasannya :

Pemrograman telah menjadi sebuah karya seni. Programmer diperbolehkan untuk “mengerjakan segala sesuatunya sendiri”. Hal tersebut sangat cepat ditemukan dan sangat mahal untuk melaksanakan proses tersebut. Pemrograman haruslah dipertimbangkan sebagai sebuah ilmu pengetahuan. Pemrograman adalah kesenangan tetapi debugging bukanlah kesenangan. Perhatikan pernyataan seperti “Pengkodean telah dilakukan, semua yang debug dihilangkan, sehingga 90% telah dikerjakan”. Data statistik menunjukkan bahwa programmer hanya50% berhasil setelah pengkodean.

sumber: link

PERIODE PERCOBAAN ATAU PARALLEL RUN (THE TRIAL PERIOD OR PARALLEL RUN)

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.

untuk lebih lengkapnya bisa diunduh disini

Undang-Undang No. 19 Tahun 2002 Tentang Hak Cipta

Dery Budi Kusuma - 10107461
Undang - Undang No. 19 Thaun 2002 Tentang Hak Cipta

Download

Etika & Profesionalisme Dibidang IT

10107461 Dery Budi Kusuma
11107222 Nida Asriningtyas
11107948 Rr. Ayu Tri Wiji Utami

Tugas softskill dapat diunduh disini

Middleware Telematika

Kelas : 4KA05

Materi : Middleware

Nama Kelompok : Bagoes Prasetyo

Dery Budi Kusuma

H Nandy Pradita

Marko Otansa

Materi selengkapnya dapat diunduh disini