Pengembangan Aplikasi

Berbasis Rapid

03
Modul ke:

Software estimation and estimation process in RSD

Fakultas
Fasilkom Roni Yusman

Program Studi
Teknik
Informatika
The Software-Estimation Story

Estimasi pembuatan perangkat lunak sangat sulit untuk ditentukan, dan apa yang
beberapa orang coba lakukan dengan estimasi pembuatan perangkat lunak secara teori tidak
mungkin untuk dilakukan atau implementasikan. Orang yang tidak memahami kesulitan
dalam menetukan estimasi pembuatan perangkat lunak dapat memainkan estimasi
pembuatan perangkat lunak peran tanpa disadari dalam membuat estimasi lebih sulit
daripada yang sudah ada.
Orang-orang mengingat cerita dengan lebih baik daripada mereka mengingat fakta-fakta
yang terisolasi, dan ada cerita yang perlu diceritakan tentang mengapa estimasi
pengembangan perangkat lunak itu sulit. Kita sebagai pengembang perlu menceritakan
kisah tersebut sebagai prioritas. Kita harus yakin bahwa pelanggan dan manajer di semua
tingkatan organisasi kita telah mendengar dan memahaminya.
Continue

Berikut adalah beberapa contoh jenis pertanyaan yang dapat dilakukan untuk
memperkirakan estimasi pekerjaan:
 Apakah pelanggan menginginkan Fitur X?
 Apakah pelanggan menginginkan versi Fitur X dengan harga yang mahal atau dengan
harga yang murah? Biasanya ada setidaknya 10 faktor perbedaan dalam kesulitan
implementasi versi berbeda dari fitur yang sama.
 Jika kita menerapkan harga murah dengan versi fitur X, apakah pelanggan nantinya
akan menginginkan versi dengan biaya yang mahal?
 Bagaimana Fitur X akan dirancang?
 Apa yang akan menjadi tingkat kualitas Fitur X?
 Berapa lama untuk men-debug dan memperbaiki kesalahan yang dilakukan dalam
implementasi Fitur X?
 Berapa lama untuk mengintegrasikan Fitur X dengan semua fitur lainnya?
Amount of Refinement Possible
Para peneliti telah menemukan bahwa perkiraan proyek berada dalam prakiraan yang
dapat diprediksi pada berbagai tahap proyek. Grafik estimasi konvergensi pada Gambar 8-2
menunjukkan bagaimana perkiraan menjadi lebih tepat ketika proyek berlangsung.
Continue
Gambar 8-2 menjelaskan alasan bahwa estimasi perangkat lunak sulit. Pada saat
pengembang biasanya diminta untuk memberikan perkiraan kasar, mungkin ada perbedaan
faktor-of-16 antara perkiraan upaya tinggi dan rendah. Bahkan setelah persyaratan telah
selesai, Anda hanya dapat mengetahui jumlah upaya yang diperlukan untuk sekitar 50
persen, dan pada saat itu sebagian besar organisasi menginginkan estimasi mereka terhadap
dolar. Kisaran estimasi yang tersirat dalam Gambar 8-2 dirangkum secara numerik pada
Tabel 8-1.
Estimation vs. Control
Sebagian besar pelanggan perangkat lunak pada awalnya menginginkan lebih dari yang
mereka mau. Seperti yang ditunjukkan Gambar 8-3, itu berarti bahwa mereka harus
membengkokkan gagasan mereka tentang produk atau gagasan mereka tentang sumber daya
yang ingin mereka sepakati. Terkadang pelanggan ingin membengkokkan sumber daya dan
fitur yang ditetapkan untuk saling bertemu di tengah jalan.
Continue
Pembangun perangkat lunak menghadapi pilihan antara akurasi estimasi dan kontrol proyek.
Jika kita bisa fleksibel tentang karakteristik produk, kita dapat memiliki kontrol atas biaya
dan jadwal dan dapat "membangun sesuai anggaran." Tetapi setiap kali kita harus memilih
antara memasukkan fitur ke dalam atau meninggalkannya, kita harus meninggalkannya.
Setiap kali kita menghadapi pilihan antara mengimplementasikan fitur yang lebih baik atau
yang harganya lebih murah, kita harus memilih yang harganya lebih murah. Dan kita harus
mengikuti pola itu secara konsisten. Jika kadang-kadang kita menerapkan fitur yang lebih
baik dan yang lebih murah, kita tidak membangun untuk anggaran. kita sedang melakukan
pengembangan perangkat lunak normal. Jika kita tidak dapat menerima disiplin dan trade-
off yang terlibat dalam pendekatan membangun ke anggaran, kita hanya harus menerima
banyak ketidaktepatan di awal perkiraan proyek.
Estimation Process
Proses pembuatan jadwal pengembangan yang akurat terdiri dari tiga langkah:
1. Estimate the size of the product (number of lines of code or function points)
2. Estimate the effort (man-months)
3. Estimate the schedule (calendar months)
Size Estimation
Kita dapat memperkirakan ukuran proyek dengan salah satu dari beberapa cara berikut:
 Gunakan pendekatan algoritmik, seperti titik fungsi, yang memperkirakan ukuran program
dari fitur program.
 Gunakan perangkat lunak estimasi-ukuran yang memperkirakan ukuran program dari
deskripsi fitur-fitur program yang akan kita buat.
 Jika kita telah mengerjakan proyek yang sama dan mengetahui ukurannya, perkirakan
setiap bagian utama dari sistem baru sebagai persentase dari ukuran bagian yang serupa
dari sistem lama. Perkirakan ukuran total sistem baru dengan menambahkan perkiraan
ukuran masing-masing bagian.
Effort Estimation
Setelah kita memiliki estimasi ukuran, kita dapat beralih ke langkah estimasi kedua untuk
mendapatkan estimasi effort. Memperoleh estimasi effort adalah proses yang mudah. Berikut
adalah beberapa cara kita bisa mengonversi estimasi size menjadi estimasi effort:

 Gunakan perangkat lunak estimasi untuk membuat estimasi upaya langsung dari estimasi
ukuran.
 Gunakan tabel jadwal di Tabel 8-8 hingga 8-10 untuk mengonversi estimasi ukuran dalam
baris kode ke estimasi upaya.
 Gunakan data historis untuk menentukan berapa banyak upaya proyek-proyek sebelumnya
dari ukuran yang diperkirakan telah diambil.
 Gunakan pendekatan algoritmik seperti model Barry Boehm's COCOMO
Continue
 Schedule Estimation
Langkah ketiga dalam memperkirakan proyek perangkat lunak adalah menghitung estimasi
jadwal. Aturan praktisnya kita dapat menghitung jadwal dari taksiran upaya dengan
menggunakan persamaan pada gambar 8-1.

Jika kita memperkirakan bahwa dibutuhkan waktu 65 bulan kerja untuk membangun proyek,
Persamaan 8-1 mengatakan bahwa jadwal optimal adalah 12 bulan (3.0 * 65 1/3). Yang pada
gilirannya menyiratkan ukuran tim optimal 65 bulan pria dibagi dengan jadwal 12 bulan
dimana didapatkan 5 atau 6 anggota tim.
Terima Kasih