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 :
1.
Mengecek
saldo
2.
Menarik uang
3.
Mentransfer
uang
4.
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 :
1.
Pengguna
baru membutuhkan waktu belajar maksimal 10 menit untuk dapat menggunakan
fungsi-fungsi utama sistem
2.
Sistem harus
tetap berfungsi minimal 10 jam setelah pasokan listrik dari PLN terhenti
3.
Waktu yang
dibutuhkan untuk kembali beroperasi setelah sistem mati minimal 2 menit
Proses-proses dalam Rekayasa Kebutuhan
Daur hidup perangkat lunak (software life cycle – SLC) terdiri dari dua siklus kehidupan utama, yaitu :
Daur hidup perangkat lunak (software life cycle – SLC) terdiri dari dua siklus kehidupan utama, yaitu :
1. 1. Daur hidup pengembangan perangkat
lunak (Software Development Life Cycle – SDLC)
2.
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. 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. 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