Pengertian dan Contoh Analisis Kebutuhan Perangkat Lunak

Pengertian dan Contoh Analisis Kebutuhan Perangkat Lunak - Artikel ini akan membahas mengenai Analisa kebutuhan yang dilakukan agar perangkat lunak yang dibuat dapat memenuhi. Melalui artikel ini diharapkan dapat menganalisa, menguasai teknik perangkat lunak dan membuatnya.

Analisis Kebutuhan Perangkat Lunak

Definisi

Proses manajemen proyek perangkat lunak dimulai dengan kegiatan project planning (perencanaan proyek). Yang pertama dari aktifitas ini adalah estimation (perkiraan). Estimasi membawa resiko yang inheren (dari diri sendiri) dan resiko inilah yang membawa ketidakpastian. Yang mempengaruhi estimasi :

• Project complexity (kompleksitas proyek)
• Project size (ukuran proyek)
• Struktural uncertainty (ketidakpastian struktural)

image source: blog.aftercollege.com

baca juga: Sumber Daya dan Estimasi Proyek Perangkat Lunak

Tujuan Perencanaan Proyek Perangkat Lunak

Menyediakan sebuah kerangka kerja yang memungkinkan manajer membuat estimasi yang dapat dipertanggungjawabkan terhadap sumber daya, biaya dan jadwal pada awal proyek yang dibatasi oleh waktu.

Aktifitas Perencanaan Proyek Perangkat Lunak

1. Menentukan ruang lingkup perangkat lunak

2. Mengestimasi sumber daya yang dibutuhkan

Ruang Lingkup Perangkat Lunak

Ruang lingkup perangkat lunak menggambarkan : fungsi, kinerja, batasan, interface dan reliabilitas. Fungsi yang digambarkan dlm statemen ruang lingkup dievaluasi untuk memberikan awalan yang lebih detail pada saat dimulai estimasi.

Kinerja melingkupi pemrosesan dan kebutuhan waktu respon. Batasan mengidentifikasi batas yang ditempatkan pada Perangkat Lunak oleh perangkat keras eksternal, memori atau sistem lain.

Informasi yang dibutuhkan (awal pertemuan antara pelanggan dan pengembang) * Pertanyaan berfokus pada pelanggan, tujuan keseluruhan serta keuntungan.

• Siapa di belakang permintaan kerja ini?
• Siapa yang akan memakai solusi ini?
• Apakah keuntungan ekonomi dari solusi yang sukses?
• Adakah sumber daya lain bagi solusi ini? * Pertanyaan yang memungkinkan analis memahami masalah lebih baik dan pelanggan menyuarakan persepsi tentang sebuah solusi.
• Bagaimana Anda (pelanggan) menandai output yg baik yg akan dihasilkan oleh sebuah solusi yg baik?
• Masalah apa yang dituju solusi ini?
• Dapatkah anda menggambarkan lingkungan dimana solusi akan dipakai?
• Adakah batasan atau isu kinerja khusus yg akan mempengaruhi Perangkat Lunak berinteraksi dengan elemen sistem berbasis komputer.

Konsep sebuah interface diinterpretasi untuk menentukan:

1. Hardware yg mengeksekusi Perangkat Lunak dan device yg dikontrol secara tidak langsung oleh Perangkat Lunak 
2. Software yg sudah ada dan harus dihubungkan dengan Perangkat Lunak yg baru
3. Manusia yg menggunakan Perangkat Lunak melalui keyboard atau perangkat I/O lain
4. Prosedur

Sumber Daya

1. Manusia
2. Perangkat Lunak Kategori yg diusulkan BEUNATAN
   - Komponen Off-the-self
   - Komponen Full-Experience
   - Komponen Partial-Experience
   - Komponen Baru
3. Lingkungan (Software Engineering Environment - SEE), menggabungkan Perangkat Lunak dan Perangkat Keras.

Estimasi biaya dan usaha dapat dilakukan dengan cara :

1. Menunda estimasi sampai akhir proyek.
2. Berdasarkan estimasi pada proyek yg mirip sebelumnya.
3. Menggunakan 'teknik dekomposisi' yg relatif sederhana u/ estimasi biaya dan usaha proyek.
4. Menggunakan satu atau lebih model empiris bagi estimasi usaha dan biaya PL.

Akurasi estimasi proyek Perangkat Lunak didasarkan pada :

1. Tingkat dimana perencana telah dengan tepat mengestimasi ukuran produk yg akan dibuat.
2. Kemampuan mengestimasi ukuran ke dalam kerja manusia, waktu kalender, dan dolar.
3. Tingkat dimana rencana proyek mencerminkan kemampuan tim PL.
4. Stabilitas syarat produk serta lingkungan yg mendukung usaha pengembangan PL.

Putnam dan Myers mengusulkan 4 masalah penentuan ukuran :

• Fuzzy-logic sizing (logika kabur)Perencana harus mengidentifikasi tipe aplikasi, membuat besarannya dalam skala kuantitatif kemudian dibandingkan dengan rentang orisinil.
• Function point sizingPerencana mengembangkan estimasi berdasarkan karakteristik domain informasi. - Standard component sizing Perangkat Lunak dibangun dari sejumlah 'komponen standar' yg umum (subsistem, modul, laporan, program interaktif).
• Change sizingDigunakan jika Perangkat Lunak yang ada harus dimodifikasi dengan banyak cara sebagai bagian dari proyek.

Data baris kode (LOC) dan titik fungsi (FP) pada estimasi proyek digunakan sebagai:

1. Variabel estimasi yg dipakai untuk mengukur masing-masing elemen PL.
2. Metrik baseline yang dikumpulkan dari proyek yg lalu dan dipakai dengan variabel estimasi untuk mengembangakan proyeksi kerja dan biaya.

Expected Value untuk variabel estimasi :

EV = (Sopt + 4Sm + Spess) / 6
EV = Expected value
Sopt = Estimasi optimistik
Sm = Estimasi paling sering
Spess = Estimasi pesimistik

Apakah estimasi ini benar ? ' Kita tidak yakin!' Bagaimanapun canggih teknik estimasi harus di-cross-check dengan pendekatan lain.

Contoh estimasi berbasis LOC

Perangkat Lunak CAD akan menerima data geometri dua dan tiga demensi dari seorang perekayasa yang akan berinteraksi dan mengontrol sistem CAD melalui suatu interface pemakai. Kajian spesifikasi sistem menunjukkan bahwa Perangkat Lunak akan mengeksekusi Workstation dan harus berinteraksi dengan berbagai periperal grafis komputer spt mouse, digitizer dan printer laser.

Diketahui :

Perhitungan LOC untuk fungsi analisis geometri 3D (3DGA) :

optimis : 4600
most likely : 6900
pesimistik : 8600
EV = (4600 + 4*6900 + 8600) / 6
= 6800 LOC

Jumlah tersebut dimasukkan ke dalam tabel, begitu juga untuk perhitungan yang lain. Sehingga diperoleh :

Jika :

Produktifitas rata-rata organisasional = 620 LOC/person-month
Upah karyawan = $8.000 per bulan
Biaya per baris kode = $13

Maka :

Estimasi Berbasis FP (Function Point)

Dekomposisi untuk perhitungan berbasis FP berfokus pada harga domain info daripada fungsi PL. Perencana proyek memperkirakan input, output, inquiry, file dan interface eksternal. Untuk tujuan perkiraan tersebut faktor pembobotan kompleksitas diasumsikan menjadi rata-rata.

Setiap faktor pembobotan kompleksitas diestimasi dan faktor penyesuaian kompleksitas dihitung seperti dibawah ini :

Perkiraan harga domain informasi :

jumlah estimasi (lihat rumus EV)
bobot (lihat kembali bab 4)
jumlah FP = jumlah estimasi * bobot

Total faktor pembobotan = SFi = 53.17
Total FP = 318

FP terestimasi = jumlah total * ( 0.65 + 0.01 * SFi)
= 318 * ( 0.65 + 0.01 * 53.17 )
= 375

Diketahui :

Produktifitas = 6.5 LOC/pm (dari historis)
Upah = $ 8.000/m
Biaya FP = $ 8.000 = $ 1.230
65 LOC

Estimasi biaya proyek

= Biaya FP * FP terestimasi
= $ 1.230 * 375
= $ 461.250

Usaha terestimasi

= Total biaya = $ 461.250 = 58 p/m
upah/p $ 8.000

Model Cocomo

Barry Boehm memperkenalkan hirarki model estimasi Perangkat Lunak dengan nama COCOMO (COnstructive COst MOdel = Model Biaya Konstruktif) yang berbentuk sbb :

1. Model COCOMO Dasar
Menghitung usaha pengembangan Perangkat Lunak (dan biaya) sbg fungsi dari ukuran program yg diekspresikan dalam baris kode yg diestimasi (LOC).

2. Model COCOMO Intermediate
Menghitung usaha pengembangan Perangkat Lunak sebagai fungsi ukuran program dan serangkaian 'pengendali biaya' yg menyangkut penilaian yg subyektif thd produk, perangkat keras, personil dan atribut proyek.

3. Model COCOMO Advance
Menghubungkan semua karakteristik versi intermediate dg penilaian thd pengaruh pengendali biaya pd setiap langkah (analis, perancangan, dll) dari proses rekayasa PL.

Model COCOMO mendefinisikan 3 kelas proyek Perangkat Lunak yaitu :

1. Model Organik
Ukuran proyek relatif kecil, Perangkat Lunak yang dibuat atau dikembangkan lebih simpel dengan aplikasi kerja yg baik. Misal program analisis termal yang dikembangkan untuk kelompok transfer panas.

2. Model Semi Detached
Ukuran proyek dan kekompleksan perangkat cukup besar dengan pengalaman kerja campuran (ada yg telah berpengalaman dan ada yg belum berpengalaman). Misal sistem pemrosesan transaksi dengan syarat tertentu untuk perangkat keras terminal dan perangkat lunak database.

3. Model Embedded
Ukuran proyek dan kekompleksan Perangkat Lunak yg dikembangkan atau dikerjakan besar. Misal perangkat lunak kontrol penerbangan untuk pesawat udara.

Persamaan COCOMO Dasar

bb
E = ab (KLOC)
db
D = cb E

Dimana :

E = Effort (usaha yang diaplikasikan - pm)
D = waktu pengembangan (m)
KLOC = jumlah perkiraan baris kode (dalam ribuan)
ab, bb, cb, db = koefisien (lihat tabel)

Model dasar ini dapat diperluas dengan mempertimbangkan kumpulan 'atribut pengendali biaya' yg dikelompokkan dalam 4 kategori utama :

1. Atribut produk

• ukuran keandalan proyek
• ukuran dari aplikasi database
• kekompleksan produk

2. Atribut perangkat keras

• kendala performansi run-time
• kendala memori
• lingkungan dari violability dari virtual memori
• waktu perputaran yg diperlukan

3. Atribut personil

• kemampuan sistem analis
• kemampuan software engineering
• pengalaman aplikasi
• pengalaman virtual mesin
• pengalaman bahasa pemrograman

4. Atribut proyek

• pemakaian alat bantu PL
• metode aplikasi software engineering
• jadwal pengembangan Masing-masing dari 15 atribut di atas dirata-rata dlm sebuah skala 6 titik dg rentang dari 'sangat rendah' ke 'sangat tinggi' (dlm kepentingan atau harga).

Persamaan COCOMO Intermediate

bi
E = ai (KLOC) * EAF

dimana :

EAF = Effort Adjusment Factor (faktor penyesuaian usaha) yg mempunyai range antara 0.9 sampai 1.4
ai, bi = koefisien (lihat tabel)

Contoh estimasi model COCOMO Kita aplikasikan model dasar pada contoh Perangkat Lunak CAD sebelumnya dengan koefisien seperti pada tabel

bb
E = ab (KLOC)
E = 2.4 (KLOC)1.05
= 2.4 (33.2)1.05
= 95 pm

Harga ini jauh lebih tinggi dibanding estimasi sebelumnya karena model COCOMO mengasumsikan tingkat LOC/pm yang jauh lebih rendah.

Untuk menghitung durasi proyek :

db
D = cb E
D = 2.5 (E)0.38
= 2.5 (95)0.38
= 12.3 bulan

Harga durasi proyek memungkinkan perencana untuk menentukan jumlah orang yang disetujui (N)

N = E/D
= 95/12.3
= 7,7 » 8 orang

Kenyataannya, perencana dapat memutuskan hanya menggunakan 4 orang saja dan pemperpanjang durasi proyek.

Catatan : Hubungan antara usaha dan waktu tidak linier.

Keputusan MAKE-BUY

Pada aplikasi PL, dari segi biaya sering lebih efektif membeli dari pada mengembangkan sendiri. Manajer Rekayasa Perangkat Lunak dihadapkan pada keputusan make-buy dengan pilihan :

1. Perangkat Lunak dapat dibeli (atau lisensi) off-the-self.
2. Komponen Perangkat Lunak full-experience dan partial-experience, dapat diperoleh dan kemudian dimodifikasi dan integrasi untuk memenuhi kebutuhan sendiri.
3. Perangkat Lunak dapat dibuat custom-built oleh kontraktor luar untuk memenuhi spesifikasi pembeli.

Untuk produk Perangkat Lunak yang mahal, langkah-langkah di bawah ini dapat dipetimbangkan:

1. Kembangkan spesifikasi untuk fungsi dan kinerja Perangkat Lunak yg diperlukan.

2. Perkirakan biaya internal untuk pengembangan dan tanggal penyampaian.

3a. Pilih tiga atau empat calon aplikasi yang paling cocok dengan aplikasi anda.

3b. Pilih komponen yang reusable yg dapat membantu konstruksi aplikasi yg diperlukan.

4. Kembnagkan sebuah matriks perbandingan untuk membandingkan calon PL.

5. Evaluasi masing-masing paket Perangkat Lunak berdasarkan kualitas produk sebelumnya, dukungan penjual, arah proyek, reputasi dsb.

6. Hubungi pemakai Perangkat Lunak lain dan mintalah pendapat mereka.

Pada analisis akhir, keputusan make-buy berdasarkan kondisi sbb:

1. Tanggal penyampaian
2. Biaya yang diperlukan
3. Dukungan

Membuat Pohon Keputusan

Rekayasa atau organisasi Perangkat Lunak dapat menggunakan teknik statistik analisis pohon keputusan dengan pilihan :

1. membangun sistem X dari permulaan
2. menggunakan lagi komponen partial experience yang ada untuk membangun sistem
3. membeli sebuah produk perangkat lunak yang dapat diperoleh dan dimodifikasi untuk memenuhi kebutuhan lokal
4. mengkontrakkan pengembangan Perangkat Lunak ke vendor luar

Bila sistem dibangun dari permulaan, hanya 70% probabilitasnya sehingga pekerjaan menjadi sulit. Perencana proyek dapat memproyeksikan usaha pengembangan yang sulit berbiaya $450.000, usaha yang sederhana diperkirakan berbiaya $380.000.

Expected value untuk biaya dihitung sepanjang cabang pohon keputusan, adalah :

Expected Cost = ∑ (jalur probabilitas)i * (biaya jalur terestimasi)i

dimana i adalah garis edar pohon keputusan.

Contoh :

expected costbuild = 0.30 ($380 K) + 0.70 ($450 K) = $ 429 K expected costreuse = 0.40 ($275 K) + 0.60 (0.20 ($310 K) + 0.80 ($490 K))
= $ 382 K
expected costbuy = 0.70 ($210 K) + 0.30 ($400 K) = $ 267 K expected costcontract = 0.60 ($350 K) + 0.40 ($500 K) = $ 410 K

Berdasar biaya probabilitas dan proyeksi, expected cost yang paling rendah adalah pilihan buy.

Catatan : Banyak kriteria yang harus dipertimbangakan, bukan hanya biaya, seperti pengalaman pengembang/ vendor/ kontraktor, penyesuaian kebutuhan,kecenderungan perubahan dapat mempengaruhi keputusan akhir!

Sekian artikel Modul Makalah tentang Pengertian dan Contoh Analisis Kebutuhan Perangkat Lunak. Semoga bermanfaat.

Daftar Pustaka

• Software Engineering Ian Sommerville
• Software Engineering Roger S.Pressman