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
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 1. Rencana Penggabungan (Plan The Integration)
Membuat program memerlukan rangkaian langkah demi langkah. Merencanakan urutan dimana anda akan menggabungkan bagian-bagian program. Pada Bagian 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 desain dari fase desain. Tugasnya adalah memecah modul secara rinci ke tingkat yang lebih rendah sampai mencapai keadaan programmer siap untuk melakukan pemrograman. Ini disebut desain modul.
Langkah 3. Telusuri Disain Modul (Walk Through The Module Design)
Seperti pada tingkat atas dan menengah dari desain, pertukaran harus dibuat sebaiknya pada tingkat yang paling rendah. Telusuri desain 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)
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. 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.
Urutan popular lainnya untuk USER’S GUIDE adalah menelusuri menu-menu perintah secara logika. Pada akhir dari USER’S GUIDE ini disediakan referensi dari setiap perintah, menu, form dan pesan yang ditampilkan secara alphabet.
- 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.
kesimpulan:
seperti dosen saya pernah menerangkan bahwa membuat software itu pekerjaan yg gampang-gampang susah. namun jika kita tidak memperhatikan tahapan-tahapan pembuatan software, maka tidak dapat di pungkiri kesulitan akan kita hadapi atau software tersebut tidak berjalan sesuai yg kita inginkan. maka untuk itu kita bisa menganalogikan sebagai "membangun rumah",berikut ulasannya dalam fase pada proyek software:
Analogi ’Membangun rumah’ untuk proyek perangkat lunak:
Fase definisi :
- Membuat daftar seluruh permasalahan (requirement document)
- Memperkiraan biaya dan waktu dalam bentuk proposal
Fase analisis :
- Mendata seperti apa rumah yang dibutuhkan user (spesifikasi fungsional)
- Input, output dan antarmuka antara rumah dan user
Fase desain
- Tujuan merancang adalah membagi sistem ke dalam komponen-komponen fungsioanal kemudian menghubungkannya secara efisien
- Dibuat oleh arsitek dalam bentuk blueprint (spesifikasi desain)
Fase penrograman
- Membangun rumah sebenarnya (kontaraktor, tukang batu, tukang kayu, ahli litrik)
- Bekerja sesuai blueprint (spesifikasi desain)
Fase pengujian
- Pengujian bertahap hingga menyeluruh
Fase penerimaan
- User melihat rumah yang lengkap dan menguji tiap peralatan/tombol bekerja baik
- Jika user puas ia akan membayar biaya pembangunan tersebut.
Fase operasi
- Rumah ditempati dan diberi garansi satu periode tertentu
- Fase ini tidak mengikutsertakan perawan berupa perubahan dan peningkatan
dengan demikian kita harus memperhatikan tahapan-tahapan dalam membuat program, dan jangan membuatnya seolah-olah rumit. karena kita bisa menganalogikan dengan pekerjaan yg lebih mudah agar pikiran kita tidak tertekan dan penuh inspirasi..
sumber:http://zlatanabimovic.blogspot.com/2011/04/langkah-langkah-pemrograman.html
Membuat program memerlukan rangkaian langkah demi langkah. Merencanakan urutan dimana anda akan menggabungkan bagian-bagian program. Pada Bagian 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 desain dari fase desain. Tugasnya adalah memecah modul secara rinci ke tingkat yang lebih rendah sampai mencapai keadaan programmer siap untuk melakukan pemrograman. Ini disebut desain modul.
Langkah 3. Telusuri Disain Modul (Walk Through The Module Design)
Seperti pada tingkat atas dan menengah dari desain, pertukaran harus dibuat sebaiknya pada tingkat yang paling rendah. Telusuri desain 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)
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. 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.
Urutan popular lainnya untuk USER’S GUIDE adalah menelusuri menu-menu perintah secara logika. Pada akhir dari USER’S GUIDE ini disediakan referensi dari setiap perintah, menu, form dan pesan yang ditampilkan secara alphabet.
- 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.
kesimpulan:
seperti dosen saya pernah menerangkan bahwa membuat software itu pekerjaan yg gampang-gampang susah. namun jika kita tidak memperhatikan tahapan-tahapan pembuatan software, maka tidak dapat di pungkiri kesulitan akan kita hadapi atau software tersebut tidak berjalan sesuai yg kita inginkan. maka untuk itu kita bisa menganalogikan sebagai "membangun rumah",berikut ulasannya dalam fase pada proyek software:
Analogi ’Membangun rumah’ untuk proyek perangkat lunak:
Fase definisi :
- Membuat daftar seluruh permasalahan (requirement document)
- Memperkiraan biaya dan waktu dalam bentuk proposal
Fase analisis :
- Mendata seperti apa rumah yang dibutuhkan user (spesifikasi fungsional)
- Input, output dan antarmuka antara rumah dan user
Fase desain
- Tujuan merancang adalah membagi sistem ke dalam komponen-komponen fungsioanal kemudian menghubungkannya secara efisien
- Dibuat oleh arsitek dalam bentuk blueprint (spesifikasi desain)
Fase penrograman
- Membangun rumah sebenarnya (kontaraktor, tukang batu, tukang kayu, ahli litrik)
- Bekerja sesuai blueprint (spesifikasi desain)
Fase pengujian
- Pengujian bertahap hingga menyeluruh
Fase penerimaan
- User melihat rumah yang lengkap dan menguji tiap peralatan/tombol bekerja baik
- Jika user puas ia akan membayar biaya pembangunan tersebut.
Fase operasi
- Rumah ditempati dan diberi garansi satu periode tertentu
- Fase ini tidak mengikutsertakan perawan berupa perubahan dan peningkatan
dengan demikian kita harus memperhatikan tahapan-tahapan dalam membuat program, dan jangan membuatnya seolah-olah rumit. karena kita bisa menganalogikan dengan pekerjaan yg lebih mudah agar pikiran kita tidak tertekan dan penuh inspirasi..
sumber:http://zlatanabimovic.blogspot.com/2011/04/langkah-langkah-pemrograman.html