<< welcome to my blogger is yayan rozandi>>

Rabu, 10 Oktober 2018

Apa itu Analisis, kebutuhan perangkat Lunak, perlu analisis kebutuhan di analisis



ANALISIS SISTEM

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 :
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