Teknik Estimasi Suatu Proyek Sistem Informasi

Proses pengulangan biasa di sebut Estimasi ( Perkiraan ) yang pertama dilakukan selama fase definisi, ketika menulis rencana pendahuluan proyek. Estimasi ini diperlukan untuk proposal dengan melakukan 3 teknik – teknik, yaitu :

1. Keputusan Profesional
Memperkirakan dengan membayangkan sambil memejamkan matanya untuk memberikan Keputusan Profesional murni, maka dalam membuat program “report generation modules”, harus memiliki pengalaman yang luas, lakukan 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”.

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
Membuat estimasi lebih khusus, harus mengerti tentang sejarahnya. Ini merupakan jalan keluar dari ketergantungan pada orang. Tulislah berapa lama masing-masing tugas dapat diselesaikan dan siapa yang bertanggung jawab atas tugas tersebut. Anda dapat membandingkan tugas yang akan diestimasikan 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

Ada 3 tipe penginputan dengan COCOMO

ATURAN PERSETUJUAN ESTIMASI PADA DEC
Perusahaan besar seperti DEC menggunakan pendekatan - pendekatan ini, mereka menggunakan rumus-rumus, tetapi mereka tetap mengikuti aturan berikut ini :
• Jangan pernah menanyakan pada seseorang yang tidak berpengalaman untuk melakukan estimasi.
• Lakukan estimasi secara berkelompok, jika anda mampu menyediakan sumber daya manusianya.
• Jangan memaksa melakukan estimasi pada seseorang profesional, seperti programmer.
• Jangan pernah mengambil rata-rata dari estimasi yang berbeda.
• Membagi persoalan menjadi bagian kecil secara mendetail selama satu minggu atau kurang.
• Selalu tambahkan (kalikan ?) untuk kejadian yang tidak pasti.
• Selalu berikan jangka waktu ketika melakukan estimasi bagi manajer atau klien.
• Gunakan naluri anda.

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.



Tujuan menjalankan paralel run adalah untuk memberikan perusahaan - dan kita - keyakinan bahwa perusahaan yang mendaftar untuk menggunakan pendekatan maju (BPPK dan AMA) telah menguji sistem mereka dan akan dapat menggunakan mereka untuk perhitungan modal pada akhir paralel menjalankan periode. Informasi dalam tulisan ini juga berhubungan dengan perusahaan yang memutuskan untuk berpindah dari yang sederhana hingga pendekatan maju di kemudian hari. Kami berencana untuk mengadopsi pendekatan yang pragmatis dan perusahaan khusus untuk paralel berjalan.




Perusahaan perlu untuk melakukan paralel berjalan di setidaknya portofolio mereka signifikan dan berisiko yang mereka mengajukan aplikasi. Tingkat tinggi prinsip kami menyatakan bahwa perusahaan harus:

* paralel berjalan selama satu tahun dan dapat menghitung kebutuhan modal mereka paling sedikit tiga bulan untuk tujuan regulasi berdasarkan lama dan baru;
* ada di tempat proses yang kokoh untuk rekonsiliasi data risiko kredit dengan data akuntansi dan menjelaskan perbedaan;
* ada di tempat proses yang kokoh untuk menunjukkan kredibilitas, keandalan dan integritas data risiko operasional, baik oleh rekonsiliasi untuk membiayai data atau dengan beberapa cara lain yang sesuai;
* terus mendukung perhitungan dengan metode lama paling tidak sampai lantai telah dihapus;
* bisa, pada setidaknya portofolio mereka signifikan dan berisiko, untuk menjalankan laporan dengan cepat melalui sistem mereka dengan workarounds minimal dan intervensi manual di tempat;
* yang sesuai dan dalam hubungannya dengan risiko kredit pada setidaknya portofolio mereka yang signifikan dan berisiko, dapat menjalankan stress test dan skenario dengan cepat melalui sistem mereka dengan workarounds minimal dan intervensi manual di tempat;
* dapat menunjukkan bahwa sistem sedang diuji dan diperbaiki dari waktu ke waktu, dan
* punya rencana menunjukkan bagaimana paralel berjalan akan diluncurkan di portofolio sisa untuk dimasukkan dalam perusahaan IRB dan / atau pendekatan AMA, dan terkait sistem.