ANALISIS KEBUTUHAN PERANGKAT LUNAK
Di Susun Oleh : Linda Liana - 41813120100
Dosen Pengampu : Wahyu Hari Haji M. Kom
FAKULTAS ILMU KOMPUTER PROGRAM STUDY SISTEM INFORMASI UNIVERSITAS MERCU BUANA JAKARTA 2015
ANALISIS KEBUTUHAN PERANGKAT LUNAK I.
PENGERTIAN KEBUTUHAN Menurut kamus Webster seperti dikutip oleh Davis [DAV93], kebutuhan adalah
sesuatu yang diisyaratkan, sesuatu yang diinginkan atau diperlukan. Sedangkan menurut IEEE kebutuhan adalah :
Kondisi atau kemampuanyang diperlukan pemakai untuk menyelesaikan suatu persoalan atau untuk mencapai tujuan.
Kondisi atau kemampuan yang harus dimiliki atau dipunyai oleh system atau komponen system untuk memenuhi kontrak, standar, spesifikasi ata dokumen formal lainnya. Kebutuhan Perangkat Lunak adalah kondisi, criteria, syarat atau kemampuan yang
harus dimiliki oleh perangkat lunak untuk memenuhi apa yang diisyaratkan atau diinginkan pemakai. Secara kategoris, ada tiga buah jenis kebutuhan perangkat lunak [IEE93]: 1. Kebutuhan Fungsional (functional requirement) Disebut juga kebutuhan operasional, yaitu kebutuhan yang berkaitan dengan fungsi atau proses transformasi yang harus mampu dikerjakan oleh perangkat lunak. Sebagai contoh:
Perangkat lunak harus dapat menyimpan semua rincian data pesanan pelanggan.
Perangkat lunak harus mampu mencetak laporan penjualan sesuai periode yang diinputkan.
Perangkat lunak harus mampu menyajikan informasi jalur pengiriman terpendek.
2. Kebutuhan Antarmuka (interface requirement) Kebutuhan antarmuka yang menghubungkan perangkat lunak dengan elemen perangkat keras, perangkat lunak, atau basis data. Sebagai contoh:
Akses ke basis data menggunakan ODBC (Open Data Base Connectivity).
Perangkat untuk memasukkan data menggunakan keyboard, mouse, dan scanner.
3. Kebutuhan Unjuk Kerja (performance requirement) Kebutuhan yang menetapkan karakteristik unjuk kerja yang harus dimiliki oleh perangkat lunak, seperti kecepatan, ketepatan, atau frekuensi.
Sebagai contoh:
Waktu tanggap penyajian informasi maksimal selama satu menit.
Perangkat lunak harus mampu mengolah data sampai 1 juta record untuk setiap transaksi.
Perangkat lunak harus dapat digunakan secara multi user sesuai otoritas yang diberikan kepada masing-masing pemakai.
II.
ANALISA KEBUTUHAN Analisis kebutuhan (requirements analysis) merupakan langkah awal untuk
menentukan gambaran perangkat yang akan dihasilkan ketika pengembang melaksanakan sebuah proyek pembuatan perangkat lunak. Perangkat lunak yang baik dan sesuai dengan kebutuhan pengguna sangat tergantung pada keberhasilan dalam melakukan analisis kebutuhan. Untuk proyek-proyek perangkat lunak yang besar, analisis kebutuhan dilaksanakan setelah aktivitas sistem information engineering dan software project planning.
Analisis kebutuhan perangkat lunak dapat diartikan sebagai: Proses mempelajari kebutuhan pemakai untuk mendapatkan definisi kebutuhan sistem atau perangkat lunak [IEE93]. Proses untuk menetapkan fungsi dan unjuk kerja perangkat lunak, menyatakan antarmuka perangkat lunak dengan elemen-elemen sistem lain, dan menentukan kendala yang harus dihadapi oleh perangkat lunak [PRE01]. Analisa kebutuhan yang baik belum tentu menghasilkan perangkat lunak yang baik,
tetapi analisa kebutuhan yang tidak tepat menghasilkan perangkat yang tidak berguna. Mengetahui adanya kesalahan pada analisis kebutuhan pada tahap awal memang jauh lebih baik, tapi kesalahan analisis kebutuhan yang diketahui ketika sudah memasuki penulisan kode atau pengujian, bahkan hampir masuk dalam tahap penyelesaian merupakan malapetaka besar bagi pembuat perangkat lunak. Biaya dan waktu yang diperlukan akan menjadi sia sia. Analisa kebutuhan adalah suatu proses untuk mendapatkan informasi, mode, spesifikasi tentang perangkat lunak yang diinginkan klien/pengguna. Kedua belah pihak, yaitu klien dan pembuat perangkat lunak terlibat aktif dalam tahap ini. Informasi dari klien yang akan menjadi acuan untuk melakukan desain perangkat lunak. Analisis kebutuhan merupakan satu di antara banyak aktivitas kritis pada proses rekayasa kebutuhan perangkat lunak untuk memahami ranah permasalahan dari sistem yang berjalan dan ranah solusi dari sistem yang akan dibuat (Yen et.al, 1998).
Ada tiga faktor yang harus dipenuhi ketika melakukan analisis kebutuhan ini, yaitu lengkap, detail, dan benar. Lengkap artinya semua yang diharapkan oleh klien telah didapatkan oleh pihak yang melakukan analisis. Detail maksudnya adalah berhasil mengumpulkan informasi yang terperinci. Semua data dari analisis kebutuhan ini haruslah benar, sesuai apa yang dimaksud oleh klien, bukan benar menurut apa yang dipikirkan oleh pihak analisis. Analisis kebutuhan yang dilakukan terhadap perangkat lunak akan menghasilkan spesifikasi perangkat lunak tersebut. Analisa kebutuhan ini terdiri dari lima langkah pokok: 1) Identifikasi Masalah 2) Evaluasi dan sintesis 3) Pemodelan 4) Spesifikasi 5) Review
Tujuan Analisis Kebutuhan: Memahami masalah yang akan dibuat perangkat lunaknya secara menyeluruh (komprehensif). Mendefinisikan apa yang harus dikerjakan oleh perangkat lunak untuk memenuhi keinginan pemakai.
Ada tiga tujuan utama dari proses analasis kebutuhan yang dapat diformulasikan sebagai beriukut : 1) Mengelola hasil elistasi kebutuhan untuk menghasilkan dokumen spesifikasi kebutuhan yang isi keseluruhannya sesuai dengan apa yang diinginkan pengguna. (Liu and Yen, 1996). 2) Mengembangkan persyaratan kualitas yang memadai dan rinci, dimana para manajer dapat membuat pekerjaan proyek yang realistis dan staf teknis dapat melanjutkan dengan perancangan, implementasi dan pengujian (Wiegers, 2003). 3) Membangun pemahaman tentang karakteristik ranah permasalahan dan sekumpulan kebutuhan untuk menemukan solusi. Ketiga tujuan tersebut dapat dicapai oleh perekayasa kebutuhan dengan melalui serangkaian tahapan-tahapan aktivitas. Tahapan aktivitas tersebut dijelaskan sebagai berikut.
Tahap Analisis Kebutuhan Tahap analisis adalah tahapan pengumpulan kebutuhan-kebutuhan dari semua elemen
sistem perangkat lunak yang akan di bangun.
Tahap kebutuhan perangkat lunak dimulai dengan [DAV93]: 1) Adanya masalah yang membutuhkan penyelesaian:
Orientasi aplikasi, misalnya inventory
Orientasi bisnis, misalnya produk baru, peramalan pendapatan
Orientasi peningkatan produk, misalnya pemeliharaan
2) Munculnya ide untuk membuat sebuah perangkat lunak baru. Tahap kebutuhan berakhir apabila deskripsi lengkap dari perilaku eksternal perangkat lunak yang akan dibangun sudah didapat, termasuk dokumentasi seluruh antarmuka perangkat lunak dengan lingkungannya (perangkat keras, perangkat lunak lain, pemakai) yang dicatat dalam Spesifikasi Kebutuhan Perangkat Lunak. Secara teknis pelaksanaan pekerjaan analisis kebutuhan perangkat lunak pada dasarnya terdiri dari urutan aktivitas: 1) Mempelajari dan memahami persoalan 2) Mengidentifikasi kebutuhan pemakai 3) Mendefinisikan kebutuhan perangkat lunak 4) Membuat dokumen spesifikasi kebutuhan 5) Mengkaji ulang (review) kebutuhan 1. Mempelajari dan Memahami Masalah Pada tahap ini, masalah yang akan dibuat perangkat lunaknya dipelajari sehingga dapat ditentukan:
Siapa pemakai yang akan menggunakan perangkat lunak
Dimana perangkat lunak akan digunakan
Pekerjaan apa dari pemakai yang akan dibantu oleh perangkat lunak
Dari dan sampai mana cakupan pekerjaan tersebut, dan bagaimana mekanisme pelaksanaannya
Apa yang menjadi kendala atau keterbatasannya dilihat dari sisi teknologi yang akan digunakan atau dari sisi hukum dan standar
Cara yang digunakan untuk dapat memahami masalah biasanya adalah:
Wawancara dengan pemakai
Observasi atau pengamatan lapangan
Kuesioner
Mempelajari referensi atau dokumen-dokumen yang digunakan, seperti dokumen hasil analisis dan perancangan sistem
Hasil pemahaman masalah tersebut selanjutnya digambarkan dalam bentuk modelmodel tertentu sesuai dengan jenis masalahnya. Sebagai contoh, untuk masalah bisnis dapat menggunakan flowmap atau business use case, sementara untuk masalah matematika dapat mengunakan, misalnya, graf. 2. Mengidentifikasi Kebutuhan Pemakai Sebenarnya, tahap identifikasi kebutuhan pemakai (user requirement) ini pada prakteknya dilaksanakan bersamaan dengan pemahaman masalah. Cara yang digunakan pun relatif sama. Hanya saja, subtansi yang ditanyakan biasanya adalah:
Data atau informasi apa yang akan diproses
Fungsi apa yang diinginkan
Kelakuan sistem apa yang diharapkan
Antarmuka apa yang tersedia (user interfaces, hardware interfaces, software interfaces, dan communications interfaces)
Untuk dapat menangkap kebutuhan pemakai dengan baik, utamanya kesamaan persepsi, dibutuhkan:
komunikasi dan brainstorming yang intensif
prototype perangkat lunak, atau screen snapshot
data atau dokumen yang lengkap
3. Mendefinisikan Kebutuhan Perangkat Lunak Saat mengidentifikasi kebutuhan pemakai, informasi yang diperoleh belum terstruktur. Pemakai akan mengungkapkan apa yang dibutuhkannya dengan bahasa seharihari yang biasa digunakan pemakai. Sebagai contoh, ungkapan kebutuhan pemakai di Bagian Akuntansi, misalnya:
Saya ingin data yang dimasukkan oleh Bagian Penjualan bisa langsung dijurnal.
Informasi neraca bisa saya lihat kapan saja. Pada tahap ini, kebutuhan pemakai yang belum terstruktur tersebut dianalisis,
diklasifikasikan, dan diterjemahkan menjadi kebutuhan fungsional, antarmuka, dan unjuk kerja perangkat lunak. Sebagai gambaran, kebutuhan “data yang dimasukkan oleh Bagian Penjualan dapat langsung dijurnal” setelah dianalisis, diklasifikasikan, dan diterjemahkan, mungkin memberikan hasil:
1) Kebutuhan fungsional:
entry dan rekam data transaksi penjualan.
retrieve nilai transaksi penjualan untuk periode tertentu (sesuai periode yang diinputkan melalui keyboard).
rekam nilai akumulasi transaksi penjualan periode tertentu ke jurnal umum berikut account pasangannya (kas).
2) Kebutuhan antarmuka:
antarmuka pemakai untuk merekam data penjualan.
antarmuka pemakai untuk menyajikan dan menjurnal informasi nilai transaksi penjualan periode tertentu.
jaringan lokal untuk menghubungkan perangkat lunak aplikasi di Bagian Penjualan dengan perangkat lunak aplikasi di Bagian Akuntansi.
3) Kebutuhan unjuk kerja:
ada otoritas pemakaian perangkat lunak dan akses data.
proses jurnal hanya dapat dilakukan sekali setelah data transaksi penjualan direkam.
Selanjutnya, kebutuhan tersebut diubah menjadi model atau gambar tertentu dengan memanfaatkan teknik analisis dan alat bantu tertentu. Sebagai gambaran, kebutuhan fungsional dapat dimodelkan dengan menggunakan:
Data Flow Diagram, kamus data, dan spesifikasi proses jika menggunakan teknik terstruktur.
Diagram Use Case dan skenario sistem jika menggunakan pendekatan objek.
4. Membuat Dokumen Spesifikasi Kebutuhan Semua kebutuhan yang telah didefinisikan selanjutnya dibuatkan dokumentasinya, yaitu Spesifikasi Kebutuhan Perangkat Lunak (SKPL) atau Software Requirements Specification (SRS). SKPL yang dibuat harus dapat menyatakan secara lengkap apa yang dapat dilakukan oleh perangkat lunak, termasuk deskripsi lengkap dari semua antarmuka yang digunakan. SKPL bisa terdiri dari banyak dokumentasi yang saling melengkapi. 5. Mengkaji Ulang (Review) Kebutuhan Proses untuk memeriksa (validasi) SKPL apakah sudah konsisten, lengkap, dan sesuai dengan apa yang diinginkan pemakai. Proses ini mungkin dilakukan lebih dari satu kali. Dan sering kali muncul kebutuhan-kebutuhan baru dari pemakai. Untuk itu, diperlukan negosiasi
antara pihak pengembang dengan pemakai sesuai prinsip “win-win solution” sampai kebutuhan tersebut dapat disepakati kedua belah pihak
III.
TEKNIK KOMUNIKASI
Merupakan permulaan yang (selalu) perlu dilakukan agar seorang pelanggan memiliki masalah yang dapat dipertanggung jawabkan melalui pemecahan berbasis computer. Agar pengembang dapat merespon permintaan bantuan (help) dari pelanggan. Menurut Gause dan Weinberg [GAU89] menyarankan agar analis memulainya dengan mengajukan pertanyaan bebas konteks, dimana pertanyaan tersebut berfokus pada pelanggan, tujuan keseluruhan, dan keuntungan. Contoh:
Siapa di balik permintaan untuk pekerjaan ini?
Apa keuntungan ekonomi dari pemecahan yang berhasil?
Rangkaian pertanyaan berikutnya memungkinakan analis mendapatkan pemahaman yang lebih baik mengenai masalah dan pelanggan, untuk menyatakan persepsinya terhadap suatu pemecahan.
Contoh:
Masalah apakah yang akan diselesaikan oleh pemecahan ini?
Dapatkah anda memperlihatkan kepada saya atau menjelaskan lingkungan dimana pemecahan tersebut akan digunakan?
Rangkaian pertanyaan
berikutnya
berfokus pada efektifitas pertemuan.
[GAU89]
memberikan contohnya sebagai berikut:
Apakah ada orang lain yang dapat memberikan informasi tambahan?
Apakah ada hal lain yang harus saya tanyakan kepada anda? Pertanyaan-pertanyaan tersebut akan membantu anda mengawali komunikasi yang
perlu untuk berhasilnya analisis. Pada dasarnya sesi tanya jawab seharusnya digunakan pada pertemuan pertama dan kemudian diganti dengan format yang mengkombinasikan elemenelemen pemecahan masalah, negosiasi, dan spesifikasi.
Teknik Spesifikasi Aplikasi yang Terfasilitasi Adanya teknik pendekatan spesifikasi aplikasi yang teratasi / facilitated aplication
spesification techniques (FAST) dapat mendorong munculnya tim gabungan antara pengembang dan pelanggan yang bekerjasama untuk mengidentifikasimasalah, mengusulkan elemen pemecahan, menegosiasi pendekatan yang berbeda, dan mengkhususkan rangkaian
pemecahan awal [ZAH90]. Banyak pendekatan yang berbeda terhadap FAST telah diusulkan. Masing-masing pendekatan menggunakan skenario yang sangat berbeda, tetapi semuanya menerapkan beberapa variasi tuntutan dasar seperti: Pertemuan dilakukan di sisi netral dan dihadiri baik oleh pengembang maupun pelanggan.
Aturan main untuk persiapan dan
partisipasi dibuat. Sebuah mekanisme definisi (dapat merupakan sebuah lembar kerja, diagram flip, stiker dinding, atau papan tembok) digunakan. FAST bukanlah obat bagi masalah yang dihadapi dalam pengumpulan awal berbagai persyaratan, tetapi pendekatan tim memberikan keuntungan dari banyak sudut pandang, diskusi sesaat, dan penyaringan, serta merupakan langkah maju konkrit ke arah pengembangan spesifikasi.
Penyebaran Fungsi Kualitas Disebut juga Quality function deployment (QFD) adalah teknik manajemen kualitas
yang menerjemahkan kebutuhan pelanggan ke dalam persyaratan teknis bagi perangkat lunak. QFD mengidentifikasi 3 persyaratan [ZUL92] yaitu:
Persyaratan normal
Sasaran dan
tujuan dinyatakan bagi sebuah produk atau sistem selama pertemuan dengan pelanggan. Bila persyaratan ini ada, maka pelanggan akan menjadi puas. Contoh: tipe tampilan
grafis yang diminta, dan tingkat kerja yang didefinisikan.
Persyaratan yang diharapkan:
Persyaratan ini implisit terhadap produk atau sistem dan sangat fundamental sehingga pelanggan tidak
menyatakannya secara eksplisit.
Ketidakhadirannya
menyebabkan
ketidakpuasan. Contoh: Mudahnya instalasi perangkat lunak. Exciting requirment: Persyaratan ini sangat diharapkan oleh pelanggan dan terbukti sangat memuaskan bila ada. Misalnya, perangkat lunak pengolah kata diharapkan dengan fitur standar. Produk yang disampaikan berisi sejumlah kemampuan layout halaman yang sangat menyenangkan dan tidak terduga. Dalam kenyataan, QFD mencakup seluruh proses rekayasa [AKA90]. Tetapi banyak konsep QFD dapat diaplikasikan ke dalam masalah komunikasi pelanggan yang dihadapi oleh perekayasa perangkat lunak selama tahap awal analisis persyaratan.
IV.
PRINSIP-PRINSIP ANALISIS Masing-masing metode analisis memiliki titik pandang yang unik. Tetapi semua
metode analisis dihubungkan oleh serangkaian prinsip operasional:
a) Domain informasi dari suatu masalah harus direpresentasikan dan dipahami. b) Fungsi-fungsi yang akan dilakukan oleh perangkat lunak harus didefinisikan. c) Tingkah laku perangkat lunak (sebagai suatu urutan kejadian eksternal) harus diwakilkan. d) Model-model yang menggambarkan informasi, fungsi, dan tingkah laku harus dipecah-pecah dalam suatu cara yang membongkar suatu detail dalam bentuk lapisan. e) Proses analisis harus bergerak dari informasi dasar ke detail implementasi. Dengan mengaplikasikan prinsip-prinsip tersebut, analis mendekati suatu masalah secarasistematis. Domain informasi diuji sehingga fungsi itu dapat dipahami secara lebih lengkap. Model-model digunakan sehingga karakteristik fungsi dan tingkah laku dapat dikomunikasikan dengan cara yang rapi. Pembagian diterapkan untuk mengurangi keruwetan. Pandangan esensial dan implementasi dari perangkat lunak diperlukan untuk mengakomodasi batasan logis yang dibebankan oleh persyaratan pemrosesan dan batasan fisik yang dibebankan oleh elemen sistem yang lain. Perekayasa perangkat lunak yang mempercayai prinsip tersebut akan dapat lebih mengembangkan spesifikasi perangkat lunak yang kemudian akan menjadi dasar yang kuat bagi desain.
Domain Informasi
Pemodelan
Domain Informasi Semua aplikasi perangkat lunak secara kolektif dapat disebut data processing.
Menarik bahwa istilah itu berisi sebuah kunci ke pemahaman terhadap persyaratan perangkat lunak. Perangkat lunak dibangun untuk memproses data, menstraformasi data dari bentuk yang satu kebentuk yang lain, yaitu untuk menerima input, memanipulasinya dengan berbagai cara, dan menghasilkan output. Pernyataan mendasar dari sasaran ini benar bila kita membangun perangkat lunak batch untuk system daftar gaji atau perangkat lunak real-time embedded untuk mengontrol aliran bahan bakar ke mesin kendaraan bermotor. Tetapi sangat penting untuk dicatat bahwa perangkat lunak juga memproses event. Event mewakili banyak aspek dari control system dan tidak lebih daripada data Boolean – baik on atau off, true or false, there or not there. Sebagai contoh, sensor tekanan mendeteksi bahwa tekanan melampaui batas nilai aman dan mengirimkan sebuah sinyal alarm ke monitoring perangkat lunak. Sinyal alarm tersebut merupakan suatu event yang mengontrol tingkah laku system. Dengan demikian, data (bilangan, karakter, citra, suara, dll) dan control (kejadian), keduanya ada pada domain informasi dari suatu masalah.
Prinsip analisis operasional yang pertama membutuhkan suatu pengujian domain informasi. Domain informasi berisi tiga pandangan yang berbeda dari data dan control ketika masing – masing dip roses oleh program computer : 1) Muatan dan hubungan informasi 2) Aliran informasi, 3) Struktur informasi. Untuk benar – benar memahami domain informasi, masing – masing dari pandangan tersebut harus diperhatikan. Muatan Informasi mewakili data dan objek control individual yang terdiri dari beberapa kumpulan informasi yang lebih besar yang di transformasikan oleh perangkat lunak. Misalnya, objek data paycheck merupakan sebuah gabungan dari sejumlah data yang penting: nama pembayar, jumlah bersih yang dibayarkan, pembayaran keseluruhan, potongan, dan seterusnya. Demikianlah, muatan dari paycheck ditentukan oleh atribut – atribut yang dibutuhkan untuk membuatnya. Dengan cara yang sama, muatan dari suatu objek control yang disebut status system dapat dibatasi oleh sebuah string dari banyak bit. Masing – masing bit mewakili jenis informasi yang berbeda yang menunjukkan apakah perangkat tertentu itu on-line atau off-line. Objek data dan control dapat dihubungkan dengan objek data dan control lainnya. Sebagai contoh, objek data paycheck memiliki satu hubungan atau lebih dengan objek timecard, employee, bank dan lain – lain. Selama analisis domain informasi, hubungan – hubungan itu harus ditetapkan. Aliran informasi mewakili cara dimana data dan kontrol berubah pada saat masing – masing bergerak melalui sebuah system. Spereti diperlihatkan pada Gambar 11.3, objek input ditransformasikan ke informasi intermediate ( data dan atau control), dan lebih jauh lagi ditransformasikan ke output. Sepanjang jalur transformasi tersebut, informasi tambahan dapat dimunculkan dari penyimpanan data yang ada (seperti, file disket atau memory buffer). Transformasi yang diaplikasikan merupakan fungsi atau subfungsi yang harus dilakukan oleh sebuah program. Data dan control yang bergerak diantara dua (fungsi) transformasi menentukan interface dari masing” fungsi. Struktur informasi mewakili organisasi internal dari berbagai jenis data dan control. Apakah jenis data akan diorganisasi sebagai sebuah table n-dimensi atau sebagai sebuah struktur pohon hirarki? Dalam konteks struktur, informasi apa yang dihubungkan dengan informasi lain? Apakah semua informasi di isikan ke dalam sebuah struktur tunggal atau akan
digunakan struktur yang berbeda? Bagaimana informasi dalam suatu struktur informasi berhubungan dengan informasi pada struktur yang lain? Pertanyaan – pertanyaan tersebut dijawab dengan suatu penilaian struktur informasi. Harus dicatat juga bahwa struktur data, konsep yang berhubungan yang akan di diskusikan pada buku ini, mengacu pada perancangan dan implementasi informasi.
Pemodelan Kita menciptakan model untuk memperoleh pemahaman yang lebih baik mengenai
entitas actual yang akan dibangun. Bila entitas tersebut berupa sebuah bentuk fisik (bangunan, pesawat, mesin), kita dapat membangun model yang identik dalam bentuk dan potongan, tetapi dalam skala yang lebih kecil. Tetapi bila entitas yang akan dibangun adalah perangkat lunak, maka model harus memakai bentuk yang berbeda. Model harus dapat memodelkan informasi yang di transformasikan oleh perangkat lunak, fungsi (dan subfungsi) yang memungkinkan transformasi terjadi, dan tingkah laku system pada saat transformasi terjadi. Selama analisis persyaratan perangkat lunak, kita menciptakan model system yang akan dibuat. Model tersebut berfokus pada apa yang harus dilakukan oleh system, bukan pada bagaimana system melakukannya. Dalam beberapa kasus, model yang kita buat menggunakan notasi grafis yang menggambarkan informasi, pemrosesan, tingkah laku system, dan karakteristik lain sebagai symbol yang berbeda dan dapat dikenali. Bagian lain dari model dapat benar – benar tekstual. Informasi deskriptif dapat diberikan dengan menggunakan bahasa natural atau bahasa khusus untuk menggambarkan persyaratannya. Model dalam perangkat
lunak
harus
dapat
memodelkan
informasi
yang
ditransformasikan oleh perangkat lunak, fungsi (dan subfungsi) yang memungkinkan transformasi terjadi, dan tingkah laku sistem pada saat transformasi terjadi. Dalam beberapa kasus, model yang kita buat menggunakan notasi grafis yang menggambarkan informasi, pemrosesan, tingkah laku sistem, dan karakteristik lain sebagai simbol yang berbeda dan dapat dikenali. Informasi deskriptif dapat diberikan dengan menggunakan bahasa natural atau bahasa khusus untuk menggambarkan persyaratannya. Prinsip analisis operasional mengharuskan kita membangun model fungsi dan tingkah laku, yaitu: 1) Model Fungsional Perangkat lunak mentransformasi informasi, dan untuk melakukannya, perangkat lunak harus melakukan paling tidak tiga fungsi genetik: input, pemrosesan, dan output. Pada
saat model fungsional dari suatu aplikasi dibuat, perekayasa perangkat lunak memfokuskan diri pada fungsi-fungsi masalah khusus. Model fungsi dimulai dengan sebuah model tingkat konteks tunggal (yakni nama perangkat lunak yang akan dibuat). Dengan serangkaian iterasi, maka lebih banyak lagi detail fungsional diberikan, sampai seluruh rancangan dari semua fungsionalitas sistem terwakili. 2) Model Tingkah Laku Sebagian besar perangkat lunak merespon kejadiankejadian dari dunia luar. Karakteristik stimulus-respon ini membentuk dasar dari model tingkah laku. Model tingkah laku menciptakan representasi pernyataan-pernyataan perangkat lunak dan event-event yang menyebabkan perangkat lunak mengubah pernyataan. Model yang diciptakan selama analisis persyaratan melayani sejumlah peran penting:
Model membantu analis dalam memahami informasi, fungsi, dan tingkah laku suatu sistem, sehingga membuat tugas analisis persyaratan menjadi lebih mudah dan lebih sistematis.
Model menjadi titik fokus bagi kajian sehingga merupakan kunci bagi penentuan kelengkapan, konsistensi, dan akurasi dari spesifikasi.
Model menjadi dasar bagi pengerjaan desain, memberi perancang suatu representasi esensial dari perangkat lunak yang dapat diterjemahkan ke dalam suatu konteks implementasi.
Meskipun metode pemodelan yang digunakan sering menjadi masalah preferensi personal atau organisasional, aktivitas pemodelan adalah dasar bagi kerja analisis yang baik. Pembagian Masalah sering menjadi terlalu luas atau terlalu rumit untuk dipahami sebagai satu kesatuan. Karena itulah kita cenderung membagi masalah seperti itu ke dalam bagian-bagian sehingga dapat dipahami dengan mudah dan kemudian membangun interface antara bagianbagian tersebut, sehingga keseluruhan fungsi dapat dilakukan. Prinsip analisis operasi keempat menyatakan bahwa domain informasi, fungsional, dan tingkah laku perangkat lunak dapat dibagi-bagi. Secara mendasar pembagian mendekomposisi suatu masalah ke dalam bagian konstituennya. Secara konseptual, kita membangun sebuah representasi hirarki dari informasi atau fungsi dan kemudian membagi elemen bagian paling atas dengan (1)mengekspos detail pertambahan dengan bergerak secara vertikal dalam hirarki, (2)mendekomposisi masalah dengan bergerak secara horisontal dalam hirarki. Contoh: system keamanan safehome
Pandangan esensial dan implementasi Pandangan esensial persyaratan perangkat lunak menyajikan fungsi yang akan dikerjakan dan dan di informasikan yg akan diproses tanpa melihat detail implementasinya. Contoh: Pandangan esensial dari fungsi safehome read sensor status Tidak tergantung dari bentuk fisik dari data atau type sensor yang di gunakan. Pandangan implementasi persyaratan perangkat lunak menyajikan manifestasi dunia nyata dari pemrosessan fungsi-fungsi dan struktur informasi. Contoh: Input safehome dimana perangkat/ element (sensor) menggunakan pertimbangan pandangan implementasi. menggunakan pertimbangan pandangan implementasi.
V.
PEMBUATAN MODEL PROTOTYPE PERANGKAT LUNAK Prototyping
perangkat
lunak (software
prototyping)
adalah
salah
satu
metode siklus hidup sistem yang didasarkan pada konsep model bekerja (working model). Pendekatan Prototyping adalah proses iterative yang melibatkan hubunan kerja yang dekat antara perancang dan pengguna. Pressman (2001) menyatakan bahwa seringkali seorang pelanggan mendefinisikan serangkaian sasaran umum bagi perangkat lunak, tetapi tidak mengidentifikasi kebutuhan input, pemrosesan, ataupun output detail. Pada kasus yang lain, pengembang mungkin tidak memiliki kepastian terhadap efisiensi algoritme, kemapuan penyesuaian dari sistem operasi, atau bentuk-bentuk yang harus dilakukan oleh interaksi manusia dan mesin. Dalam situasi seperti ini salah satu model yang cocok digunakan adalah model prototype (Prototyping paradigm). Model Prototype dapat dilihat pada gambar dibawah ini.
Pendekatan Prototyping melewati tiga proses, yaitu pengumpulan kebutuhan, perancangan, dan evaluasi Prototype. Proses-proses tersebut dapat dijelaskan sebagai berikut:
1) Pengumpulan kebutuhan: developer dan klien bertemu dan menentukan tujuan umum, kebutuhan yang diketahui dan gambaran bagian-bagian yang akan dibutuhkan berikutnya. 2) Perancangan: perancangan dilakukan cepat dan rancangan mewakili semua aspek software yang diketahui, dan rancangan ini menjadi dasar pembuatanprototype. 3) Evaluasi Prototype: klien mengevaluasi prototype yang dibuat dan digunakan untuk memperjelas kebutuhan software. Perulangan ketiga proses ini terus berlangsung hingga semua kebutuhan terpenuhi. prototype-prototype dibuat untuk memuaskan kebutuhan klien dan untuk memahami kebutuhan klien lebih baik. Prototype yang dibuat dapat dimanfaatkan kembali untuk membangun software lebih cepat, namun tidak semua prototype bisa dimanfaatkan. Sekalipun prototype memudahkan komunikasi antar developer dan klien, membuat klien mendapat gambaran awal dari Prototype. Prototipe mendukung dua kegiatan proses rekayasa persyaratan Elisitasi persyaratan: user bereksperimen untuk melihat bagaimana sistem dapat mendukung pekerjaan mereka dan memberikan usulan atau ide-ide baru. Validasi persyaratan: Prototipe dapat menunjukkan kesalahan-kesalahan atau ketidaksesuaian yang mungkin terjadi. Bentuk Prototipe Berdasarkan karakteristiknya prototipe sebuah sistem dapat berupa low fidelity dan high fidelity. Fidelity mengacu kepada tingkat kerincian sebuah sistem (Walker et al, 2003). Low fidelity prototype tidak terlalu rinci menggambarkan sistem. Karakteristik dari low fidelity prototype adalah mempunyai fungsi atau interaksi yang terbatas, lebih menggambarkan kosep perancangan dan layout dibandingkan dengan model interaksi, tidak memperlihatkan secara rinci operasional sistem, mendemostrasikan secara umum feel and look dari antarmuka pengguna dan hanya menggambarkan konsep pendekatan secara umum (Walker et al, 2003). High fidelity protoype lebih rinci menggambarkan sistem. Prototipe ini mempunyai interaksi penuh dengan pengguna dimana pengguna dapat memasukkan data dan berinteraksi dengan dengan sistem, mewakili fungsi-fungsi inti sehingga dapat mensimulasikan sebagian besar fungsi dari sistem akhir dan mempunyai penampilan yang sangat mirip dengan produk sebenarnya (Walker et al, 2003).
Fitur yang akan diimplementasikan pada prototipe sistem dapat dibatasi dengan teknik vertikal atau horizontal. Vertical prototype mengandung fungsi yang detail tetapi hanya untuk beberapa fitur terpilih, tidak pada keseluruhan fitur sistem. Horizontal prototype mencakup seluruh fitur antarmuka pengguna namun tanpa fungsi pokok hanya berupa simulasi dan belum dapat digunakan untuk melakukan pekerjaan yang sebenarnya (Walker et al, 2003). Proses Pembuatan Prototipe Proses pembuatan prototipe merupakan proses yang interaktif dan berulang-ulang yang menggabungkan langkah-langkah siklus pengembangan tradisional. Prototipe dievaluasi beberapa kali sebelum pemakai akhir menyatakan protipe tersebut diterima. Gambar di bawah ini mengilustrasikan proses pembuatan prototipe :
Langkah-Langkah Prototyping a) Analisis Kebutuhan Sistem Pembangunan sistem informasi memerlukan penyelidikan dan analisis mengenai alasan timbulnya ide atau gagasan untuk membangun dan mengembangkan sistem informasi. Analisis dilakukan untuk melihat berbagai komponen yang dipakai sistem yang sedang berjalan meliputi hardware, software, jaringan dan sumber daya manusia. Analisis juga mendokumentasikan aktivitas sistem informasi meliputi input, pemrosesan, output, penyimpanan dan pengendalian (O'Brien, 2005). Selanjutnya melakukan studi kelayakan (feasibility study) untuk merumuskan informasi yang dibutuhkan pemakai akhir, kebutuhan sumber daya, biaya, manfaat dan kelayakan proyek yang diusulkan (Mulyanto, 2009).
Analisis kebutuhan sistem sebagai bagian dari studi awal bertujuan mengidentifikasi masalah dan kebutuhan spesifik sistem. Kebutuhan spesifik sistem adalah spesifikasi mengenai hal-hal yang akan dilakukan sistem ketika diimplementasikan (Mulyanto, 2009). Analisis kebutuhan sistem harus mendefinisikan kebutuhan sistem yang spesifik antara lain : 1)
Masukan yang diperlukan sistem (input)
2)
Keluaran yang dihasilkan (output)
3)
Operasi-operasi yang dilakukan (proses)
4)
Sumber data yang ditangani
5)
Pengendalian (kontrol)
Spesifikasi Kebutuhan Sistem Tahap analisis kebutuhan sistem memerlukan evaluasi untuk mengetahui kemampuan sistem dengan mendefinisikan apa yang seharusnya dapat dilakukan oleh sistem tersebut kemudian menentukan kriteria yang harus dipenuhi sistem. Beberapa kriteria yang harus dipenuhi adalah pencapaian tujuan, kecepatan, biaya, kualitas informasi yang dihasilkan, efisiensi dan produktivitas, ketelitian dan validitas dan kehandalan atau reliabilitas (Mulyanto, 2009). b) Desain Sistem Analisis sistem (system analysis) mendeskripsikan apa yang harus dilakukan sistem untuk memenuhi kebutuhan informasi pemakai. Desain sistem (system design) menentukan bagaimana sistem akan memenuhi tujuan tersebut. Desain sistem terdiri dari aktivitas desain yang menghasilkan spesifikasi fungsional. Desain sistem dapat dipandang sebagai desain interface, data dan proses dengan tujuan menghasilkan spesifikasi yang sesuai dengan produk dan metode interface pemakai, struktur database serta pemrosesan dan prosedur pengendalian (Ioanna et al., 2007). Desain sistem akan menghasilkan paket software prototipe, produk yang baik sebaiknya mencakup tujuh bagian :
1) Fitur menu yang cepat dan mudah. 2) Tampilan input dan output. 3) Laporan yang mudah dicetak. 4) Data dictionary yang menyimpan informasi pada setiap field termasuk panjang field, pengeditan dalam setiap laporan dan format field yang digunakan. 5) Database dengan format dan kunci record yang optimal. 6) Menampilkan query online secara tepat ke data yang tersimpan pada database. 7) Struktur yang sederhana dengan bahasa pemrograman yang mengizinkan pemakai melakukan pemrosesan khusus, waktu kejadian, prosedur otomatis dan lain-lain. c) Pengujian Sistem Paket software prototipe diuji, diimplementasikan, dievaluasi dan dimodifikasi berulang-ulang hingga dapat diterima pemakainya (O'Brien, 2005). Pengujian sistem bertujuan menemukan kesalahan-kesalahan yang terjadi pada sistem dan melakukan revisi sistem. Tahap ini penting untuk memastikan bahwa sistem bebas dari kesalahan (Mulyanto, 2009). Menurut Sommerville (2001) pengujian sistem terdiri dari : 1) Pengujian unit untuk menguji komponen individual secara independen tanpa komponen sistem yang lain untuk menjamin sistem operasi yang benar. 2) Pengujian modul yang terdiri dari komponen yang saling berhubungan. 3) Pengujian sub sistem yang terdiri dari beberapa modul yang telah diintegrasikan. 4) Pengujian sistem untuk menemukan kesalahan yang diakibatkan dari interaksi antara subsistem dengan interfacenya serta memvalidasi persyaratan fungsional dan non fungsional. 5) Pengujian penerimaan dengan data yang dientry oleh pemakai dan bukan uji data simulasi. 6) Dokumentasi berupa pencatatan terhadap setiap langkah pekerjaan dari awal sampai akhir pembuatan program. Pengujian sistem informasi berbasis web dapat menggunakan teknik dan metode pengujian perangkat lunak tradisional. Pengujian aplikasi web meliputi pengujian tautan, pengujian browser, pengujian usabilitas, pengujian muatan, tegangan dan pengujian malar (Simarmata, 2009).
Penerimaan pengguna (user) terhadap sistem dapat dievaluasi dengan mengukur kepuasan user terhadap sistem yang diujikan. Pengukuran kepuasan meliputi tampilan sistem, kesesuaian dengan kebutuhan user, kecepatan dan ketepatan sistem untuk menghasilkan informasi yang diinginkan user. Ada beberapa model pengukuran kepuasan user terhadap sistem, diantaranya adalah Technology Acceptance Model (TAM), End User Computing (EUC) Satisfaction, Task Technology Fit (TTF) Analysis dan
Human Organizational
Technology (HOT) Fit Model. Salah satu model pengukuran yang telah diterjemahkan ke dalam beberapa bahasa berbeda dan tidak menunjukkan perbedaan hasil pengukuran yang signifikan adalah End User Computing (EUC) Satisfaction. Model ini menekankan kepuasan user terhadap aspek teknologi meliputi aspek isi, keakuratan, format, waktu dan kemudahan penggunaan sistem (Chin & Mathew, 2000). d) Implementasi Setelah prototipe diterima maka pada tahap ini merupakan implementasi sistem yang siap dioperasikan dan selanjutnya terjadi proses pembelajaran terhadap sistem baru dan membandingkannya dengan sistem lama, evaluasi secara teknis dan operasional serta interaksi pengguna, sistem dan teknologi informasi. Pemilihan prototyping Paradigma prototyping terbatas dan tidak terbatas. Pendekatan terbatas sering disebut: throw away prototyping. Dengan menggunakn pendekatan tersebut, prototyping sebagai sebuah demonstrasi kasar dari sebuah persyaratan.Kemudian prototype dikesampingkan dan perangkat lunak direkayasa dgn menggunakan suatu paradigma yang berbeda.Pendekatan tidak terabatas sering disebut evolusionary prototyping,menggunakan prototyping sebagai bagian utama dari aktivitas analisis yang akan diteruskan ke dalam desain dan konstruksi. Sebelum perangkat terbatas atau tidak terbatas dipilih, perlu ditentukan apakah system yang akan
dibangun
dapat
menerima
prototyping
atau
tidak.Sejumlah
factor
calon
prototyping[BOA84] dapat ditentukan: area aplikasi, kompleksitas aplikasi, krakteristik pelanggan, dan karakteristik proyek.
Proses Pengembangan Prototipe
Metode dan Peranti Prototyping Agar prototyping perangkat lunak efektif, maka harus dikembangkan suatu prototype dengan cepat sehingga pelanggan dengan dapat menilai hasil dan perubahan yang di rekomendasikan. Untuk melakukan prototyping dengan tepat ada tiga kelas metode dan peranti generik misal: (AND 92,TAN 92) : teknik generasi keempat komponen perangkat lunak reusable, spesifikasi normal,dan lingkungan prototyping. Prototipe Pada Proses Perangkat Lunak
Tujuan Pemrograman Evolusioner dan Throw-away
Evolusioner : Menyerahkan sistem kepada user untuk menjalankan semua prioritas utama
2.
Throw-Away : Mem-Validasi dan menurunkan persyaratan sistem.
Kelebihan dan Kekurangan
Keunggulan prototyping adalah : 1)
Adanya komunikasi yang baik antara pengembang dan pelanggan.
2)
Pengembang dapat bekerja lebih baik dalam menentukan kebutuhan pelanggan.
3)
Pelanggan berperan aktif dalam pengembangan sistem.
4)
Lebih menghemat waktu dalam pengembangan sistem.
5)
Penerapan menjadi lebih mudah karena pemakai mengetahui apa yang diharapkannya
Sedangkan kelemahan prototyping adalah : 1)
Pelanggan tidak melihat bahwa perangkat lunak belum mencerminkan kualitas
perangkat lunak secara keseluruhan dan belum memikirkan peneliharaan dalam jangka waktu yang lama. 2)
Pengembang biasanya ingin cepat menyelesaikan proyek sehingga menggunakan
algoritma dan bahasa pemrograman sederhana. 3)
Hubungan pelanggan dengan komputer mungkin tidak menggambarkan teknik
perancangan yang baik. Prototype yang dibuat dapat dimanfaatkan kembali untuk membangun software lebih cepat, namun tidak semua prototype bisa dimanfaatkan. Sekalipun prototype memudahkan komunikasi
antar developer dan
klien,
membuat
klien
mendapat
gambaran
awal
dari Prototype. Pendekatan ini memiliki beberapa keuntungan : 1. Pemodelan membutuhkan partisipasi aktif dari end-user. Hal ini akan meningkatkan sikap dan dukungan pengguna untuk pengerjaan proyek. Sikap moral pengguna akan meningkat karena system berhubungan nyata dengan mereka. 2. Perubahan dan iterasi merupakan konsekuensi alami dari pengembangan systemsehingga end user memiliki keinginan untuk merubah pola pikirnya.Prototyping lebih baik menempatkan situasi alamiah ini karena mengasumsikan perubahan model melalui iterasi kedalam system yang dibutuhkan. 3. Prototyping mematahkan folosofi “end user tidak mengetahui secara detail apa yang dibutuhkan sampai mereka melihat implementasinya” 4. Prototyping adalah model aktif, tidak pasif, sehingga end user dapat melihat, merasakan, dan mengalaminya. 5. Kesalahan yang terjadi dalam prototyping dapat dideteksi lebih dini 6. Prototyping dapat
meningkatkan
kreatifitas
karena
membolehkan
adanyafeedback dari end user. Hal ini akan memberikan solusi yang lebih baik. 7. Prototyping mempercepat beberapa fase hidup dari programmer. McLeod dan Schell (2001) mengemukakan bahwa alasan-alasan pemakai maupun spesialis informasi menyukai model prototype adalah:
1. Komunikasi antara analis sistem dan pemakai membaik 2. Analis dapat bekerja dengan lebih baik dalam menemukan kebutuhan pemakai 3. Pemakai berperan lebih aktif dalam pengembangan system 4. Spesialis informasi dan pemakai menghabiskan lebih sedikit waktu dan usaha dalam mengembangkan sistem; 5. Implementasi menjadi lebih mudah karena pemakai mengetahui sistem yang diharapkan. Tetapi, terdapat beberapa kelemahan dari prototyping, kelemahan tersebut antara lain : 1. Prototyping memungkinkan terjadinya pengembalian terhadap kode, implementasi, dan perbaikan siklus hidup yang dugunakan untuk mendominasi sistem informasi. 2. Prototyping tidak menolak kebutuhan dari fase analisis sistem. Prototype hanya dapat memecahkan masalah yang salah dan memberi kesempatan sebagai sistem pengembangan konvensional. 3. Perancangan issu numerik tidak dialamaykan oleh prototyping. Isu tersebut dapat dilupakan jika pengguna tidak berhati-hati. 4. Prototyping dapat mengurangi kreatifitas perancangan. Prototyping terkadang dapat memberikan performansi yang lambat, membantu mendapatkan kebutuhan detil lebih baik namun demikian Prototype juga menimbulkan masalah: a) Dalam membuat prototype banyak hal yang diabaikan seperti efisiensi, kualitas, kemudahan dipelihara/dikembangkan, dan kecocokan dengan lingkungan yang sebenarnya. Jika klien merasa cocok dengan prototype yang disajikan dan berkeras terhadap produk tersebut, maka developer harus kerja keras untuk mewujudkan produk tersebut menjadi lebih baik, sesuai kualitas yang seharusnya. b) Developer biasanya melakukan kompromi dalam beberapa hal karena harus membuat prototype dalam waktu singkat. Mungkin sistem operasi yang tidak sesuai, bahasa pemrograman yang berbeda, atau algoritma yang lebih sederhana. c) Agar model ini bisa berjalan dengan baik, perlu disepakati bersama oleh klien dan developer bahwa prototype yang dibangun merupakan alat untuk mendefinisikan kebutuhan software.
