POST TEST : Sebutkan teknik-teknik estimasi pada Proyek Sistem Informasi ?

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

Apakah yang dimaksud dengan 'estimasi'? Carilah satu contoh yang berhubungan dengan estimasi

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.

 contohnya :

Estimasi Biaya Perangkat lunak

Sebuah proyek dikatakan berhasil apabila sistem tersebut bisa diserahkan tepat waktu, sesuai antara biaya dan kualitas yang diinginkan. Hal tersebut menandakan bahwa apa yang ditargetkan manajer proyek telah bisa dicapat. Meski target yang dibuat manajer proyek masuk akal, tapi tidak memperhitungkan catatan level produktivitas timnya, kemungkinan tidak akan bisa memenuhi deadline dikarenakan estimasi awal yang salah. Oleh karenanya, perkiraan yang realistik menjadi kebutuhan yang sangat krusial bagi seorang manajer proyek.   Beberapa kendala estimasi sangat dipengaruhi oleh karakteristik perangkat lunak (software), khususnya kompleksitas dan hal-hal lain yang tidak kasat mata. Juga kegiatan SDM yang terlibat dalam pengembangan sistem tidak bisa diperhitungkan secara pasti dengan menggunakan cara-cara yang mekanistik. Belum lagi kesulitan lain yang menghalangi keberhasilan proyek perangkat lunak, sepert :

·        Aplikasi perangkat lunak yang diusulkan : beberapa proyek mirip biasanya dikembangkan berdasarkan pengalaman sebelumnya. Padahal proyek perangkat lunak memiliki sifat yang unik sehingga sering ada hal-hal yang tidak terduga dan penuh ketidakpastian.

·        Perubahan teknologi : perubahan bahasa pemrograman yang digunakan bisa menghambat waktu selesainya proyek.

·        Kurang homoginnya pengalaman proyek : estimasi akan efektif bila dibuat berdasarkan proyek-proyek sebelumnya, hanya saja banyak perusahaan yang menyembunyikan data proyek-proyek sebelumnya dari para staf.

·        Subyektifitas estimasi : orang cenderung berlaku under-estimate terhadap kesulitan dari pekerjaan-pekerjaan kecil dan  ber bertindak over-estime pada proyek-proyek besar yang dianggap lebih komplek dan sulit.

·         Implikasi Politik : kelompok berbeda dalam sebuah organisasi bisa memiliki tujuan berbeda. Manajer pengembang sistem informasi mungkin akan menekan pada bagian ‘estimator’ untuk mengurangi estimasi harga berdasarkan anjuran atasannya. Sedangkan pada bagian pemeliharaan berharap tidak terjadi pembengkaan biaya dan keterlambatan waktu penyerahan agar citranya tidak jelek. Sebagai jalan tengahnya, estimasi sebaiknya dibuat oleh tim khusus yang bersifat independen dari penngguna maupun tim proyek.

Menurut Anda seberapa penting dilakukan tes penerimaan terhadap sistem yang dibuat? Jelaskan jawaban Anda.

Apa saja yang perlu dicek pada kegiatan ‘Rencana Penerimaan’? Sebut dan jelaskan.

Jawab :

Tujuan dari penerimaan adalah mendapatkan pernyataan tertulis dari user bahwa produk (dalam hal ini sistem) yang dikirim sesuai dengan yang dijanjikan.

Tahap – tahap yang terdapat dalam Rencana Tes Penerimaan ::

1. 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.

Beberapa kekurangan pada Periode Paralel Run diantaranya :

a. Masalah kecil dapat membuat anda menjalankan kembali selama “x” untuk jangka waktu yag tidak terbatas.

b. Sulit untuk mencari penyebab dari suatu masalah.

c. Tidak ada jaminan bahwa semua kelebihan sistem akan dicoba.

d. biarkan end user masuk ke sistem pada hari pertama yang penerapannya tidak selalu bermanfaat.

2. PENERIMAAN YANG LENGKAP SEDIKIT DEMI SEDIKIT (A THOROUGH BUT PIECEMEAL ACCEPTANCE)

Manfaat dari pendekatan ini adalah :

1. Dapat mendemonstrasikan semua fungsi yang dijanjikan.
2. Semua tindakan yang menyebabkan masalah selalu diketahui dengan tepat siapa yang mengetik ketika masalah terjadi.
3. User tidak merasa takut tentang semuanya.

3. MEMASTIKAN BAHWA SEMUA YANG DIJANJIKAN AKAN DIUJI (ENSURING THAT ALL THE PROMISES ARE TESTED)

Untuk memastikan semua yang dijanjikan akan di tes langsung melalui spesifikasi fungsi halaman demi halaman, paragraf demi paragraf dan buat daftar semua fungsi yang dapat di tes.

4. MENGGUNAKAN DESIGN (USING THE DESIGN)

Design membantu untuk mengelompokkan tes ke dalam serangkaian tes yang mendemonstrasikan fungsi utama.

5. MENULIS PERCOBAAN (WRITING TEST)

Hal ini dilakukan pada saat anda sudah siap menetukan bagaimana anda akan menguji item ketika pengisian pada metode percobaan.

6. DAFTAR RENCANA TES PENERIMAAN (THE ACCEPTANCE TEST PLAN CHECKLIST)

1. Definisikan percobaan dan kumpulkan percobaan.
2. Tetapkan tanggung jawab untuk menulis percobaan.
3. Klien dan tim proyek mengetahui bahwa ATP akan ditinjau kembali, direvisi jika perludan ditandatangani user.
4. Hasilkan fungsi vs rabel percobaan.
5. Tanggung jawab untuk percobaan data telah dtetapkan.

7. KESIMPULAN UNTUK RENCANA TES PENERIMAAN (CONCLUSION TO THE ACCEPTANCE TEST PLAN) 

Anda dapat melakukan tes penerimaan secara berlebihan. Anjurkan user untuk menulis ATP jika dia mampu. Hal ini akan memberikan dia perasaan mengawasi tim proyek harus membangun sistem melalui percobaan.

8. KESIMPULAN UNTUK TAHAP DESIGN (CONCLUSION TO THE DESIGN PHASE)

1. Dokumen spesifikasi design memuat design akhir tingkat atas melalui design tingkat menengah.
2. Tanggung jawab ATP disahkan dan dimulai.
3. Rencana proyek.