ANALISIS KEBUTUHAN PERANGKAT LUNAK

Transkripsi

1 ANALISIS KEBUTUHAN PERANGKAT LUNAK Untuk Memenuhi Tugas Mata Kuliah Rekayasa Perangkat Lunak Dosen Pembimbing : Wachyu Hari Haji, S.Kom, MM Disusun Oleh : Fadhilla Eka Hentino / UNIVERSITAS MERCU BUANA JAKARTA FAKULTAS ILMU KOMPUTER JURUSAN SISTEM INFORMASI April 2015

2 ANALISIS KEBUTUHAN PERANGKAT LUNAK I. Apa Itu Analisis kebutuhan perangkat lunak? Analisis kebutuhan perangkat lunak (software requirements analysis) merupakan aktivitas awal dari siklus hidup pengembangan perangkat lunak. Untuk proyek-proyek perangkat lunak yang besar, analisis kebutuhan dilaksanakan setelah aktivitas sistem information engineering dan software project planning. Tahap analisis adalah tahapan pengumpulan kebutuhan-kebutuhan dari semua elemen sistem perangkat lunak yang akan di bangun. Pada tahap ini dibentuk spesifikasi kebutuhan perangkat lunak, fungsi perangkat lunak yang dibutuhkan, performansi (unjuk kerja) sistem perangkat lunak, penjadwalan proyek, identifikasi sumber daya (manusia, perangkat keras dan perangkat lunak yang dibutuhkan) dan taksiran biaya pengembangan perangkat lunak. Kegunaan analisis adalah untuk memodelkan permasalahan dunia nyata agar dapat dimengerti. Permasalahan dunia nyata harus dimengerti dan dipelajari supaya spesifikasi kebutuhan perangkat lunak dapat diungkapkan. Tujuan aktivitas ini adalah untuk mengetahui ruang lingkup produk (product space) dan pemakai yang akan menggunakannya. Analisis yang baik akan mengungkapkan hal-hal yang penting dari permasalahan, dan mengabaikan yang tidak penting. Setiap metode analisis mempunyai pandangan yang berbeda. Tetapi pada dasarnya semua metode analisis memiliki prinsip analisis yang sama, yaitu : 1. Menggambarkan domain informasi masalah 2.Mendefinisikan fungsi perangkat lunak 3.Menghasilkan model yang menggambarkan informasi, fungsi dan kelakuan yang dibagi secara rinci pada sebuah model lapisan (hirarki) lebih rinci. 4.Informasi pokok pada tahap analisis memudahkan tahap implementasi yang

3 Tujuan tahap analisis adalah : 1.Menjabarkan kebutuhan pemakai 2.Meletakkan dasar-dasar untuk tahap perancangan perangkat lunak 3.Mendefinisikan semua kebutuhan pemakai sesuai dengan lingkup kontrak yang disepakati kedua belah pihak (pengembang dan pengguna). II. Apa yang Disebut Kebutuhan (Requirement) Pengertian Kebutuhan Menurut arti kamus, kebutuhan adalah sesuatu yang diminta, sesuatu yang dibutuhkan.sedangkan menurut IEEE (The Institute of Electrical and Electronics Engineers) kebutuhan adalah : Kondisi atau kemampuan yang diperlukan pemakai untuk menyelesaikan suatu persoalan, atau untuk mencapai sebuah objek. Kondisi atau kemampuan yang harus dipenuhi oleh sistem, dalam arti memenuhi kontrak, standar, spesifikasi atau dokumen formal lain yang diinginkan. Tahap kebutuhan akan perangkat lunak dimulai dengan : 1. Dikenalinya adanya sebuah permasalahan yang membutuhkan sebuah penyelesaian.identifikasi sebuah permasalahan mungkin dapat dilakukan dengan berorientasi pada aplikasi, berorientasi pada bisnis, atau berorientasi pada kenaikan produktivitas (product improvement oriented). 2. Munculnya ide untuk membuat sebuah perangkat lunak baru (sebagai sebuah kemajuan).

4 Jenis - Jenis Kebutuhan : 1. Behavioral Jenis Kebutuhan yang dilakukan oleh sistem (input dan output dari dan ke sistem). hubungan informasi antara input dan output sehingga menghasilkan sebuah fungsi transformasi. 2. Non-behavioral Mendefinisikan atribut sistem yang terkait untuk membentuk pekerjaan tersebut.termasuk deskripsi lengkap tentang efisiensi, keamanan (security), rehability maintenability (bagaimana perawatan untuk sistem), dan portability (bisa dipindahkan dari satu perangkat keras ke perangkat keras lainnya). III. Mengapa Analisis Kebutuhan Penting? Perhatikan gambar dampak kumulatif berikut ini :

5 Dengan Melihat diagram diatas, Maka kesalahan pada analisa kebutuhan perangkat lunak akan menyebabkan munculnya bagian bagian yang menjadi penghambat suatu proyek dan menjadikan perangkat lunak yang dihasilkan menjadi kurang sempurna karena masih adanya error selain itu Mencari kesalahan diakhir siklus hidup pengembangan perangkat lunak ternyata menjadikan proyek tersebut menjadi tidak efektif dan efisien dari sisi SDM dan SDA. IV. Tahap Analisis Kebutuhan Perangkat Lunak Tahap pekerjaan analisis kebutuhan perangkat lunak pada dasarnya terdiri dari urutan aktivitas : 1.Menentukan kebutuhan (requirement) Lebih banyak berhubungan dengan pemakai. Hasil belum terstruktur. 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 interface, dan communications interfaces) 2.Sintesis Mengubah kebutuhan yang belum terstruktur menjadi model atau gambar dengan memanfaatkan teknik dan metode analisis tertentu. 3.Membuat dokumen Software Requirements Spesification (SRS) Merupakan Dokumen yang berisi analisis yang lebih rinci dan sebagai tahap awal perancangan.

6 V. Metode Analisis Metode atau teknik untuk melakukan analisis kebutuhan perangkat lunak dikelompokkan berdasarkan pendekatan yang diambil pada saat melakukan aktivitas tersebut. a) Berorientasi Aliran Data (Data Flow Oriented atau Functional Oriented) Sudut pandang analisis pada pendekatan ini difokuskan pada aspek fungsional dan behavioral (perilaku laku) sistem. Pengembang harus mengetahui fungsi-fungsi atau prosesproses apa saja yang ada dalam sistem, data apa yang menjadi masukannya, dimana data tersebut disimpan, transformasi apa yang akan dilakukan terhadap data tersebuat, dan apa yang menjadi hasil transformasinya. Selain itu pengembang harus mengetahui keadaan (state), perubahan (transition), kondisi (condition), dan aksi (action) dari sistem. Salah satu metode yang paling populer untuk pendekatan ini adalah Analisis Terstruktur (Structured Analysis) yang dikembangkan oleh Tom DeMarco, Chris Gane dan Trish Sarson, dan Edward Yourdon. Pada metode ini, hasil analisis dan perancangan dimodelkan dengan menggunakan beberapa perangkat permodelan seperti : Data Flow Diagram (DFD) dan Kamus Data (data dictionary) untuk menggambarkan fungsi-fungsi dari sistem. Entity-Relationship Diagram (ERD) untuk menggambarkan data yang disimpan (data storage). State Transition Diagram (STD) untuk menggambarkan perilaku sistem. Structure Chart untuk menggambarkan struktur program

7 b) Berorientasi Struktur Data Analisis pendekatan ini difokuskan pada struktur data, dimana struktur tersebut dapat dinyatakan secara hirarki dengan menggunakan konstruksi sequence, selection dan repetition. Beberapa metode berorientasi struktur data ini diantaranya adalah : Data Structured System Development (DSSD) Diperkenalkan pertama kali oleh J.D. Warnier [1974] dan kemudian oleh Ken Orr [1977], sehingga sering disebut juga metode Warnier-Orr. Metode ini menggunakan perangkat entity diagram, assembly line diagram dan Warnier-Orr diagram untuk memodelkan hasil analisis dan rancangannya. Jackson Sistem Development (JSD) Dikembangkan oleh M.A. Jackson [1975] dengan menggunakan perangkat permodelan yang disebut strukture diagram dan sistem spesification diagram. c) Berorientasi objek Berbeda dengan pendekatan-pendekatan sebelumnya, pendekatan berorientasi objek memandang sistem yang akan dikembangkan sebagai suatu kumpulan objek yang berkorespondensi dengan objek-objek dunia nyata. Pada pendekatan ini, informasi dan proses yang dipunyai oleh suatu objek dienkapsulasi (dibungkus) dalam satu kesatuan. Beberapa metode pengembangan sistem yang berorientasi objek ini diantaranya adalah : Object Oriented Analysis (OOA) dan Object Oriented Design (OOD) dari Peter Coad dan Edward Yourdon [1990]. Object Modelling Technique (OMT) dari James Rumbaugh [1987]. Object Oriented Software Engineering (OOSE)

8 VI. TEKNIK KOMUNIKASI Merupakan permulaan yang perlu dilakukan agar masalah yang dimiliki user / pengguna dapat dipertanggung jawabkan melalui pemecahan berbasis komputer atau perangkat lunak. Agar pengembang perangkat lunak dapat merespon permintaan bantuan dari user. FAST (Facilitated Application Specification Techniques) Memacu kreasi kerja sama dari tim (user dan pengembang) yang bekerja sama untuk : Mengidentifikasi masalah Menyiapkan elemen-elemen solusi Menegosiasikan pendekatan yang berbeda Menetapkan sebelumnya kebutuhan solusi yang diperlukan PANDUAN FAST J. Wood dan D. Silver menyarankan beberapa panduan umum FAST yang dapat digunakan yaitu : Peserta harus menghadiri semua rapat Semua peserta adalah sama Persiapan harus sama pentingnya dengan rapat yang sebenarnya Semua dokumen sebelum rapat harus dikaji ulang Lokasi rapat diluar ruangan terkadang diperlukan Tentukan agenda dan jangan sampai mengalami perubahan Jangan sampai terbawa dalam hal-hal teknis yang terlalu rinci PENYEBARAN FUNGSI KUALITAS (QUALITY FUNCTION DEPLOYMENT = QFD) QFD sebagai perkenalan : Teknik manajemen kualitas yang menterjemahkan kebutuhan pelanggan kedalam kebutuhan teknis untuk perangkat lunak Pertama kali diperkenalkan di Jepang untuk memaksimalkan kepuasan pelanggan

9 Menekankan pemahaman tentang apa yang berguna kepada pelanggan dan kemudian menyebarkan nilai-nilai tersebut melalui proses rekayasa QFD mengidentifikasi tiga tipe persyaratan yaitu : Persyaratan normal : Sasaran dan tujuan bagi sebuah produk atau system selama pertemuan dengan pelanggan. Bila persyaratan ini ada, maka pelanggan akan menjadi puas, misalnya tampilan grafis yang sempurna. Persyaratan yang diharapkan : Persyaratan ini implicit terhadap produk atau system yang sangat fundamental sehingga pelanggan tidak menyatakannya secara eksplisit. Ketidakhadirannya akan menyebabkan ketidakpuasan yang sangat mendalam. Contohnya adalah mudahnya operasional interaksi manusia dan mesin, reliabilitas dan kebenaran operasional keseluruhan dan mudahnya instalasi perangkat lunak Exciting requirement : Persyaratan ini sangat diharapkan oleh pelanggan dan terbukti sangat memuaskan bila ada, misal kemampuan perangkat pengolah kata yang memiliki kemampuan layout halaman, dsb. GAMBARAN KONSEP QFD : Penyebaran fungsi, menentukan nilai (seperti yang diharapkan pelanggan) dari setiap fungsi yang dibutuhkan oleh system. Penyebaran informasi, mengidentifikasi objek data dan kejadian Penyebaran tugas, yang melatih kebiasaan dari system Analisa nilai, menetapkan prioritas relative kebutuhan VII. MODEL PROTOTYPE Prototyping merupakan salah satu metode pengembangan perangat lunak yang banyak digunakan. Dengan metode prototyping ini pengembang dan user dapat saling berinteraksi selama proses pembuatan sistem. Sering terjadi seorang user hanya mendefinisikan secara umum apa yang dikehendakinya tanpa menyebutkan secara detal output apa saja yang dibutuhkan, pemrosesan dan data-data apa saja yang dibutuhkan.

10 Sebaliknya disisi pengembang kurang memperhatikan efesiensi algoritma, kemampuan sistem operasi dan interface yang menghubungkan manusia dan komputer. Untuk mengatasi ketidakserasian antara user dan pengembang, maka harus dibutuhakan kerjasama yanga baik diantara keduanya sehingga pengembang akan mengetahui dengan benar apa yang diinginkan user dengan tidak mengesampingkan segi-segi teknis dan user akan mengetahui proses-proses dalam menyelasaikan sistem yang diinginkan. Dengan demikian akan menghasilkan sistem sesuai dengan jadwal waktu penyelesaian yang telah ditentukan. Kunci agar model prototype ini berhasil dengan baik adalah dengan mendefinisikan aturan-aturan main pada saat awal, yaitu user dan pengembang harus setuju bahwa prototype dibangun untuk mendefinisikan kebutuhan. Prototype akan dihilangkan sebagian atau seluruhnya dan perangkat lunak aktual aktual direkayasa dengan kualitas dan implementasi yang sudah ditentukan Tahapan-tahapan Prototyping : Tahapan-tahapan dalam Prototyping adalah sebagai berikut: a. Pengumpulan kebutuhan Pelanggan dan pengembang bersama-sama mendefinisikan format seluruh perangkat lunak, mengidentifikasikan semua kebutuhan, dan garis besar sistem yang akan dibuat. b. Membangun prototyping Membangun prototyping dengan membuat perancangan sementara yang berfokus pada penyajian kepada pelanggan (misalnya dengan membuat input dan format output) c. Evaluasi protoptyping Evaluasi ini dilakukan oleh pelanggan apakah prototyping yang sudah dibangun sudah sesuai dengan keinginann pelanggan. Jika sudah sesuai maka langkah 4 akan diambil. Jika tidak prototyping direvisi dengan mengulangu langkah 1, 2, dan 3.

11 d. Mengkodekan sistem Dalam tahap ini prototyping yang sudah di sepakati diterjemahkan ke dalam bahasa pemrograman yang sesuai e. Menguji sistem Setelah sistem sudah menjadi suatu perangkat lunak yang siap pakai, harus dites dahulu sebelum digunakan. Pengujian ini dilakukan dengan White Box, Black Box, Basis Path, pengujian arsitektur dan lain-lain f. Evaluasi Sistem Pelanggan mengevaluasi apakah sistem yang sudah jadi sudah sesuai dengan yang diharapkan. Juka ya, langkah 7 dilakukan; jika tidak, ulangi langkah 4 dan 5. g. Menggunakan sistem Perangkat lunak yang telah diuji dan diterima pelanggan siap untuk digunakan. Keunggulan dan Kelemahan Prototyping Keunggulan prototyping adalah: Adanya komunikasi yang baik antara pengembang dan pelanggan Pengembang dapat bekerja lebih baik dalam menentukan kebutuhan pelanggan Pelanggan berperan aktif dalam pengembangan sistem Lebih menghemat waktu dalam pengembangan sistem Penerapan menjadi lebih mudah karena pemakai mengetahui apa yang diharapkannya.

12 Kelemahan prototyping adalah : Pelanggan kadang tidak melihat atau menyadari bahwa perangkat lunak yang ada belum mencantumkan kualitas perangkat lunak secara keseluruhan dan juga belum memikirkan kemampuan pemeliharaan untuk jangka waktu lama. penegmbang biasanya ingin cepat menyelesaikan proyek. Sehingga menggunakan algoritma dan bahasa pemrograman yang sederhana untuk membuat prototyping lebih cepat selesai tanpa memikirkan lebih lanjut bahwa program tersebut hanya merupakan cetak biru sistem. Hubungan pelanggan dengan komputer yang disediakan mungkin tidak mencerminkan teknik perancangan yang baik