Senin, 24 Juni 2013

Teknik-teknik estimasi


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


Estimasi


Estimasi adalah salah satu aspek yang paling penting dari fungsi management strategik. Estimasi biaya merupakan unsur penting untuk manajemen stratejik. Estimasi Biaya adalah pengembangan penegasan hubungan antara objek biaya dengan ‘cost driver‘ untuk tujuan peramalan biaya. Management biaya strategik adalah estimasi biaya yang akurat ( tepat – teliti ). Pendekatannya dengan melihat kedepan dan oleh karena itu estimasi biaya merupakan unsur yang penting untuk management biaya strategik. Estimasi biaya membantu memprediksi/ mengestimasikan biaya mendatang menggunakan identifikasi sebelumnya, berdasarkan aktivitas, volume, struktur, atau pemeliharaan  cost driver.
Estimasi biaya membantu mengidentifikasikan cost driver kunci untuk objek biaya.
Konstribusi tingkat awal berupa
1. Memprediksi biaya dari berbagai aktivitas, prosesnya atau bentuk organisasinya,
2.  Memprediksi dampak keuangan dan operasional,
3. Memprediksi biaya ( dalam nilai uang dan waktu ) dari strategi implementasi alternatif.
Berikut ini adalah sebuah contoh perhitungan keuntungan berdasarkan asumsi harga jual ke konsumen yang selama ini sudah berlaku di masyarakat di beberapa wilayah  :
Misalkan anda pesan boneka kepada kami 80 pcs boneka yang terdiri dari :
Teddy bear super jumbo @ 30 pcs x Rp.115.000   = Rp. 3.450.000
Minie mouse                   @ 20 pcs x Rp. 95.000    = Rp. 1.900.000
Doraemon                       @ 15 pcs x Rp. 95.000    = Rp. 1.425.000
Kelinci Jumbo                 @15 pcs x  Rp. 75.000   = Rp. 1.125.000   +
                                                   Sub Total                 Rp.7.900.000
 Ongkos  Kirim  (asumsi)                                           Rp.   500.000   +
                                                        Total Modal       Rp.8.400.000


Perkiraan / asumsi keuntungan yang di peroleh berdasar harga jual ke konsumen yang sudah umum di masyarakat :
**  Catatan harga di luar pulau jawa biasanya lebih tinggi  **

Teddy bear super jumbo @ 30 pcs x Rp.180.000    = Rp. 5.400.000
Minie mouse                   @ 20 pcs x Rp.150.000    = Rp. 3.000.000
Doraemon                       @ 15 pcs x Rp.150.000    = Rp. 2.250.000
Kelinci Jumbo                 @15 pcs x  Rp.130.000    = Rp. 1.950.000  + 
                                       Total Hasil Penjualan         Rp.12.600.000

Jadi keuntungan yang dapat anda peroleh dari asumsi perhitungan di atas yaitu  :

Total Hasil Penjualan  -   Total Modal  = Laba / keuntungan

    (  Rp. 12.600.000  -    Rp.8.400.000    =  Rp. 4.200.000  ) 


Rencana Penerimaan


Yang perlu dicek pada kegiatan Rencana Penerimaan:

1.    PERIODE PERCOBAAN / 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.

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

Pendekatan yang lebih baik adalah menemukan serangkaian tes yang mendemonstrasikan semua fungsi yang dijanjikan. Penerimaan akan dilakukan secara resmi melalui seluruh tes ini kepada pelanggan. Keberhasilan tes diakhiri satu per satu.

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

Untuk memastikan semua yang dijanjikan akan dites langsung melalui Spesifikasi Fungsi halaman demi halaman, paragraf demi paragraf, dan buat daftar semua fungsi yang dapat dites.

4. MENGGUNAKAN DISAIN (USING THE DESIGN)

Disain membantu untuk menggelompokkan tes ke dalam serangkaian tes yang mendemonstrasikan fungsi utama dari sistem.

5. MENULIS PERCOBAAN (WRITING TEST)

Anda sudah siap menentukan bagaimana anda akan menguji item ketika pengisian pada metode percobaan. 
6. DAFTAR RENCANA TES PENERIMAAN (THE ACCEPTANCE TEST PLAN CHECKLIST)

Daftar pengecekkan untuk semua kegiatan yang diperlukan untuk rencana penerimaan:
-          Hasilkan Fungsi vs. Tabel Percobaan dan semua FS yang dijanjikan telah dialamatkan.
-          Definiskan percobaan dan kumpulan percobaan.
-          Tetapkan tanggung jawab untuk menulis percobaan.
-          Klien dan Tim proyek mengetahui bahwa ATP akan ditinjau kembali, direvisi jika perlu, dan ditandatangani oleh user. Klien mengetahui bahwa keberhasilan penyelesaian dari percobaan akan mempengaruhi penerimaan sistem.
-          Tanggung jawab untuk percobaan data telah ditetapkan. Data untuk percobaan seharusnya disediakan oleh tim proyek dan juga user. Jika user dapat menyediakan data yang sesuai dengan keadaan yang sebenarnya, percobaan terhadap sistem akan berjalan dengan baik, ditambah user akan merasa nyaman dengan keakuratan percobaannya. 

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

Anda dapat melakukan tes penerimaan secara berlebihan. Membandingkan biaya tes dengan biaya risiko itu adalah suatu masalah. Anda dapat tidak melakukan semua percobaan, khususnya dalam sistem multi-user yang interaktif.

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

Tahap disain menempuh beberapa kejadian penting sebagai berikut :
-          Dokumen Spesifikasi Disain memuat disain akhir tingkat atas melalui disain tingkat menengah.
-          Tanggung jawab ATP disahkan dan dimulai. Ini tidak perlu diselesaikan sampai tahap penerimaan.
-          Rencana proyek, khususnya perkiraan perlu ditinjau kembali. Walaupun anda sedang memperkirakan hanya 4 tahap yang telah disebutkan, tahap pemrograman mungkin akan menjadi tahap yang sangat mahal dan membutuhkan waktu yang sangat banyak dalam keseluruhan kerja proyek. Disain memberikan anda perkiraan perhitungan jumlah modul-modul dan kerumitannya. Sekarang anda mungkin tahu siapa programmer-programmer yang dapat diandalkan, sehingga anda dapat mempertimbangkan faktor produktivitas mereka. Dengan informasi ini waktu pemrograman yang diperlukan dapat dengan mudah diperkirakan (lihat BAB 13). Statistik menunjukkan bahwa pada akhir tahap disain diperkirakan seharusnya tidak lebih dari 10%.


Minggu, 23 Juni 2013

Pentingkah Tes Penerimaan



Sebelumnya saya akan menjelaskan tujuan dari tes penerimaan terhadap sistem yang dibuat, tes penerimaan bertujuan untuk mendapatkan pernyataan tertulis dari user bahwa produk (dalam hal ini sistem) yang dikirim sesuai dengan yang dijanjikan.
Sehingga dengan adanya tes terhadap sistem sangat penting karena dilihat dari manfaat yang didapat, yaitu:
1.Dapat mendemonstrasikan semua fungsi yang dijanjikan.
2.Mengetahui tindakan yang menyebabkan masalah seperti, siapa yang mengetik ketika masalah terjadi.
3.User tidak merasa takut tentang semuanya. Maka sangatlah penting untuk melakukan tes penerimaan terhadap suatu sistem.

Yang perlu dicek pada kegiatan Rencana Penerimaan:

1.    PERIODE PERCOBAAN / 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.

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

Pendekatan yang lebih baik adalah menemukan serangkaian tes yang mendemonstrasikan semua fungsi yang dijanjikan. Penerimaan akan dilakukan secara resmi melalui seluruh tes ini kepada pelanggan. Keberhasilan tes diakhiri satu per satu.

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

Untuk memastikan semua yang dijanjikan akan dites langsung melalui Spesifikasi Fungsi halaman demi halaman, paragraf demi paragraf, dan buat daftar semua fungsi yang dapat dites.

4. MENGGUNAKAN DISAIN (USING THE DESIGN)

Disain membantu untuk menggelompokkan tes ke dalam serangkaian tes yang mendemonstrasikan fungsi utama dari sistem.

5. MENULIS PERCOBAAN (WRITING TEST)

Anda sudah siap menentukan bagaimana anda akan menguji item ketika pengisian pada metode percobaan. 
6. DAFTAR RENCANA TES PENERIMAAN (THE ACCEPTANCE TEST PLAN CHECKLIST)

Daftar pengecekkan untuk semua kegiatan yang diperlukan untuk rencana penerimaan:
-          Hasilkan Fungsi vs. Tabel Percobaan dan semua FS yang dijanjikan telah dialamatkan.
-          Definiskan percobaan dan kumpulan percobaan.
-          Tetapkan tanggung jawab untuk menulis percobaan.
-          Klien dan Tim proyek mengetahui bahwa ATP akan ditinjau kembali, direvisi jika perlu, dan ditandatangani oleh user. Klien mengetahui bahwa keberhasilan penyelesaian dari percobaan akan mempengaruhi penerimaan sistem.
-          Tanggung jawab untuk percobaan data telah ditetapkan. Data untuk percobaan seharusnya disediakan oleh tim proyek dan juga user. Jika user dapat menyediakan data yang sesuai dengan keadaan yang sebenarnya, percobaan terhadap sistem akan berjalan dengan baik, ditambah user akan merasa nyaman dengan keakuratan percobaannya. 

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

Anda dapat melakukan tes penerimaan secara berlebihan. Membandingkan biaya tes dengan biaya risiko itu adalah suatu masalah. Anda dapat tidak melakukan semua percobaan, khususnya dalam sistem multi-user yang interaktif.

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

Tahap disain menempuh beberapa kejadian penting sebagai berikut :
-          Dokumen Spesifikasi Disain memuat disain akhir tingkat atas melalui disain tingkat menengah.
-          Tanggung jawab ATP disahkan dan dimulai. Ini tidak perlu diselesaikan sampai tahap penerimaan.
-          Rencana proyek, khususnya perkiraan perlu ditinjau kembali. Walaupun anda sedang memperkirakan hanya 4 tahap yang telah disebutkan, tahap pemrograman mungkin akan menjadi tahap yang sangat mahal dan membutuhkan waktu yang sangat banyak dalam keseluruhan kerja proyek. Disain memberikan anda perkiraan perhitungan jumlah modul-modul dan kerumitannya. Sekarang anda mungkin tahu siapa programmer-programmer yang dapat diandalkan, sehingga anda dapat mempertimbangkan faktor produktivitas mereka. Dengan informasi ini waktu pemrograman yang diperlukan dapat dengan mudah diperkirakan (lihat BAB 13). Statistik menunjukkan bahwa pada akhir tahap disain diperkirakan seharusnya tidak lebih dari 10%.

         Jadi menurut saya dengan adanya sistem ini kita  dapat mendemonstrasikan semua fungsi yang di telah janjikan sebelumnya, dan juga kita dapat mengetahui apakah user merasa puas atau tidak dengan proyek yang telah kita buat. setelah melakukan hal tersebut dan apabila user tidak  user tidak lagi mengkomplain dengan hasil kinerja kita, sehingga kita bisa mendapatkan tanda penerimaan dari user seperti pembayaran yang telah disepakati sebelumnya atas hasil kinerja yang sudah dikerjakan