Definisi
Analisis Sistem :
Penguraian dari suatu sistem informasi yang utuh ke dalam bagian-bagian
komponennya dengan maksud untuk mengidentifikasikan dan mengevaluasi
permasalahan, kesempatan, hambatan yang terjadi dan kebutuhan yang diharapkan
sehingga dapat diusulkan perbaikan.
Tugas utama dari menganalisis
sistem meliputi :
1.
Menentukan lingkup sistem
2.
Mengumpulkan fakta
3.
Menganalisis fakta
4.
Mengkomunikasikan temuan-temuan tersebut melalui laporan analisis sistem
Ada empat hal yang dapat
dihasilkan dari analisis sistem :
1. Proyek dilepas.
Proyek
sistem yang dilepas dapat berasal dari masalah utama yang tidak dapat diselesaikan.
Alasan lain, adanya perubahan dari prioritas sistem oleh pihak manajemen atau
komite pengarah, yang mengakibatkan proyek sistem yang sekarang dilepas.
2. Proyek ditunda.
Pada
saat ini, pihak manajemen akan menentukan sumber daya untuk proyek sistem lain
dengan prioritas yang lebih tinggi. Maka instalasi untuk backbone telekomunikasi
akan tertunda, sehingga proyek sistem yang sekarang ditunda. Beberapa pemakai
kunci mungkin sedang berlibur atau tidak masuk untuk beberapa minggu, sehingga
menyebabkan proyek ditunda sementara waktu dari SDLC.
3. Proyek diganti.
Hasil ini berarti bahwa aspek penting
dari proposal sistem yang asli mempunyai perubahan yang berarti. Seperti
perubahan yang melibatkan perluasan utama
dan penyusunan dari lingkup sistem. Atau
mungkin pemakai membutuhkan perubahan yang berarti dari perkiraan yang lebih
cepat itu, menyebabkan kebutuhan sumber daya yang lebih banyak atau sedikit.
4. Proyek dilanjutkan
Proyek sistem akan diteruskan
seperti rencana dalam laporan analisis sistem.
KEBUTUHAN PERANGKAT LUNAK
Jenis kebutuhan perangkat lunak dapat dibagi dalam 2
jenis,
1.
Kebutuhan Fungsional ( Functional Requirement)
Yaitu Mendeskripsikan layanan, fitur
atau fungsi yang disediakan atau diberikan oleh sistem bagi penggunanya.
Contoh pada
Sistem Mesin ATM :
Mengecek saldo
Menarik uang
Mentransfer uang
Melakukan
pembayaran
2.
Kebutuhan Non Fungsional (Non Functional
Requirement)
Yaitu Mendeskripsikan
sekumpulan batasan, karakteristik dan properti pada sistem, baik dalam
lingkungan pengembangan maupun operasional, atau atribut kualitas yang harus
dipenuhi oleh sistem.
Contoh pada
mesin ATM :
Pengguna baru
membutuhkan waktu belajar maksimal 10 menit untuk dapat menggunakan
fungsi-fungsi utama sistem.Sistem harus tetap berfungsi minimal 10 jam setelah
pasokan listrik dari PLN terhenti Waktu yang dibutuhkan untuk kembali
beroperasi setelah sistem mati minimal 2 menit
Proses-prose sdalam Rekayasa Kebutuhan Daur hidup
perangkat lunak (software life cycle – SLC) terdiri dari dua siklus
kehidupan utama, yaitu:
1. Daur hidup pengembangan perangkat
lunak (Software Development Life Cycle – SDLC)
- Daur hidup pengoperasian perangkat lunak (Software Operational Life Cycle – SOLC).
Mengapa Perlu Analisis Kebutuhan dalam Rekayasa Perangkat Lunak?
Hal ini
disebabkan oleh keterbatasan data dan informasi yang didapatkan pada waktu
proses pengumpulan, penganalisisan, penspesifikasian, verifikasi dan validasi
kebutuhan dari perangkat lunak yang hendak dibangun. Ada beberapa alasan pokok
yang menjadi dasar mengapa rekayasa kebutuhan perlu dilakukan dalam proses
pembuatan suatu perangkat lunak, antara lain :
1.
Semua perangkat lunak memiliki spesifikasi
Setiap perangkat lunak yang dibangun
merupakan representasi dari suatu sistem. Setiap sistem memiliki tujuan
tertentu, yang didalamnya terdapat komponen-komponen yang berfungsi sebagai
masukan, proses, atau keluaran. Dengan kata lain, setiap perangkat lunak,
sekecil atau sesederhana apa pun, pasti memiliki spesifikasi kebutuhan, yang
secara tersirat maupun tersurat menggambarkan tujuan sistem beserta
komponen-komponen yang dibentuknya.
2.. Permasalahan Berawal dari
Spesifikasi Kebutuhan
Menurut Davis (1993) dan Leffingwell (1997), 40%
sampai dengan 60% kesalahan dalam suatu proyek pembangunan perangkat lunak yang
mungkin muncul dalam tahapan berikutnya, berawal dari kesalahan yang dilakukan
pada saat spesifikasi kebutuhan. Brooks (1987) mengatakan bahwa proyek
pengembangan perangkat lunak seringkali over budget, terlambat
cacat atau tidak dapat diandalkan. Jones (1991)
menjelaskan bahwa penyebab tunggal dari berbagai kegagalan tersebut adalah
adanya defisiensi pada tahapan spesifikasi kebutuhan. Hofmann dan Lehner (2001)
menemukan bahwa titik-titik defisiensi tersebut tersebar dalam ranah proses,
teknologi, dan sumber daya manusianya permasalahannya
lebih disebabkan oleh salah asumsi. asumsi yang tidak dikomunikasikan,
spesifikasi kebutuhan yang tidak memadai, dan perubahan kebutuhan yang terlihat
sederhana tetapi sering kurang diperhatikan. Kesemuanya ini berujung pada
jurang perbedaan antara apa yang dipikirkan oleh pengembang untuk seharusnya
dibangun dan apa yang dibutuhkan pelanggan.
Tidak ada komentar:
Posting Komentar