Rekayasa Sistem

Analisa KebutuhanPerangkat Lunak1DEFINISI KEBUTUHANMenurut Kamus Webster seperti dikutip oleh Davis [DAV93], kebutuhan adalah sesuatu yang disyaratkan; sesuatu yang diinginkan atau diperlukan.

Menurut IEEE [IEE93] kebutuhan adalah:Kondisi atau kemampuan yang diperlukan pemakai untuk menyelesaikan suatu persoalan atau untuk mencapai tujuan.Kondisi atau kemampuan yang harus dimiliki atau dipunyai oleh sistem atau komponen sistem untuk memenuhi kontrak, standar, spesifikasi, atau dokumen formal lainnya.

Kebutuhan perangkat lunak adalah kondisi, kriteria, syarat atau kemampuan yang harus dimiliki oleh perangkat lunak untuk memenuhi apa yang disyaratkan atau diinginkan pemakai.2JENIS KEBUTUHANSecara kategoris, ada tiga buah jenis kebutuhan perangkat lunak [IEE93]:Kebutuhan fungsional (functional requirement)Kebutuhan antarmuka (interface requirement)Kebutuhan unjuk kerja (performance requirement)Kebutuhan antarmuka dan unjuk kerja sering disebut Non-functional Requirement3JENIS 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 terpendek4JENIS KEBUTUHAN PERANGKAT LUNAK [IEE93]2) Kebutuhan Antarmuka (interface requirement)

Kebutuhan antarmuka yang menghubungkan perangkat lunak dengan elemen perangkat keras, perangkat lunak, atau basis data.

Sebagai contoh:Perangkat untuk memasukkan data dapat berupa keyboard, mouse atau scanner.Akses ke basis data menggunakan ODBC (Open Data Base Connectivity).

5JENIS KEBUTUHAN PERANGKAT LUNAK [IEE93]3) Kebutuhan unjuk kerja (performance requirement)Kebutuhan yang menetapkan karakteristik unjuk kerja yang harus dimiliki oleh perangkat lunak, misalnya: kecepatan, ketepatan, frekuensi.

Sebagai contoh:Perangkat lunak harus bisa mengolah data sampai 1 juta record untuk tiap transaksi.Perangkat lunak harus dapat digunakan oleh multiuser sesuai dengan otoritas yang diberikan pada user.Waktu tanggap penyajian informasi maksimal selama satu menit.6DAMPAK KESALAHAN PENENTUAN KEBUTUHANProduk perangkat lunak tidak akan memenuhi kebutuhan pemakai.Interpretasi kebutuhan yang berbeda-beda menyebabkan ketidaksepakatan antara pelanggan dan pengembang.Pengujian kesesuaian perangkat lunak dengan kebutuhan yang dimaksud tidak akan mungkin dilaksanakan dengan sesungguhnya.Waktu dan biaya akan terbuang percuma untuk membangun sistem yang salah.7DEFINISI ANALISIS KEBUTUHANProses 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 perangkat lunak [PRE01].8TUJUAN PELAKSANAANANALISIS KEBUTUHANMemahami masalah secara menyeluruh (komprehensif) yang ada pada perangkat lunak yang akan dikembangkan seperti ruang lingkup produk perangkat lunak (product space) dan pemakai yang akan menggunakannya.

Mendefinisikan apa yang harus dikerjakan oleh perangkat lunak untuk memenuhi keinginan pelanggan.9Mempelajari dan memahami persoalanMengidentifikasi kebutuhan pemakaiMendefinisikan kebutuhan perangkat lunakMembuat dokumen Spesifikasi Kebutuhan Perangkat Lunak (SKPL) atau Software Requirement Specification (SRS)Mengkaji ulang (review) kebutuhanTAHAPAN ANALISIS KEBUTUHAN10(1) Mempelajari dan memahami persoalanPada tahap ini, masalah yang akan dibuat perangkat lunaknya dipelajari sehingga dapat ditentukan:siapa pemakai yang akan menggunakan perangkat lunakdimana perangkat lunak akan digunakanpekerjaan apa dari pemakai yang akan dibantu oleh perangkat lunakdari dan sampai mana cakupan pekerjaan tersebut, dan bagaimana mekanisme pelaksanaannyaapa yang menjadi kendala atau keterbatasannya dilihat dari sisi teknologi yang akan digunakan atau dari sisi hukum dan standar11(2) Mempelajari dan memahami persoalanCara yang digunakan untuk dapat memahami masalah biasanya adalah:wawancara dengan pemakaiobservasi atau pengamatan lapangankuesionerHasil pemahaman masalah tersebut selanjutnya digambarkan dalam bentuk model-model tertentu sesuai dengan jenis masalahnya. Sebagai contoh, untuk masalah bisnis dapat menggunakan flowmap atau business use case, sementara untuk masalah matematika dapat graf.12(2) Mengidentifikasi kebutuhan pemakaiDilaksanakan bersamaan dengan pemahaman masalah. Cara yang digunakan pun relatif sama, namun 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 yang intensifprototype perangkat lunak, atau screen snapshot data atau dokumen yang lengkapInformasi yang diperoleh belum terstruktur.13(3) Mendefinisikan kebutuhan perangkat lunakPada tahap ini, kebutuhan pemakai yang belum terstruktur tersebut dianalisis, diklasifikasikan, dan diterjemahkan menjadi kebutuhan fungsional, antarmuka, dan unjuk kerja perangkat lunak.

14Kebutuhan antarmuka:Kebutuhan unjuk kerja: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 Ada otoritas pemakaian perangkat lunak dan akses data.Proses jurnal hanya dapat dilakukan sekali setelah data transaksi penjualan direkam.(3) Mendefinisikan kebutuhan perangkat lunakSelanjutnya, 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.

15(4) Membuat Dokumen SKPLSemua 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.16(5) Mengkaji ulang (review) kebutuhanProses 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 sehingga diperlukan negosiasi antara pihak pengembang dengan pemakai sampai kebutuhan tersebut dapat disepakati kedua belah pihak.17ANALISIS KEBUTUHAN PERANGKAT LUNAK MENURUT PRESSMANPengenalan masalahEvaluasiPemodelanSpesifikasiTinjau ulang (review)18METODE ANALISISBerorientasi Aliran Data (Data Flow Oriented atau Functional Oriented)Berorientasi Struktur Data (Data Structured Oriented)Berorientasi Objek (Object Oriented)19METODE ANALISIS BERORIENTASI ALIRAN DATA (Data Flow Oriented atau Functional Oriented)

Yaitu metode analisis yang difokuskan pada aspek fungsional dan behavioral (perilaku laku) sistem.

Hasil analisis dan perancangan dapat dimodelkan denganData Flow Diagram (DFD) dan Kamus Data (data dictionary) untuk menggambarkan fungsi-fungsi dari sistem (system functions).Entity-Relationship Diagram (ERD) untuk menggambarkan data yang disimpan (data stored).State Transition Diagram (STD) untuk menggambarkan perilaku sistem.Structure Chart untuk menggambarkan struktur program20(Data Structured Oriented)Difokuskan pada struktur data dan dapat dinyatakan secara hirarki dengan menggunakan konstruksi sequence, selection dan repetition.

Data Structured System Development (DSSD)Metode ini menggunakan perangkat entity diagram, assembly line diagram dan Warnier-Orr diagram untuk memodelkan hasil analisis dan perancangannya.Jackson System Development (JSD)Dikembangkan oleh M.A. Jackson [1975] dengan menggunakan perangkat pemodelan yang disebut structure diagram dan system specification diagram.

METODE ANALISIS BERORIENTASI STRUKTUR DATA 21(Object Oriented)Pendekatan berorientasi objek memandang sistem yang akan dikembangkan sebagai suatu kumpulan objek yang berkorespondensi dengan objek-objek dunia nyata.

Pengembangan sistem ini diantaranya adalah:Object Oriented Analysis (OOA) dan Object Oriented Design (OOD) dari Peter Coad dan Edward Yourdon (1990).Object Modeling Technique (OMT) dari James Rumbaugh (1987)Object Oriented Software Engineering (OOSE).METODE ANALISIS BERORIENTASI OBJEK 22SPESIFIKASI KEBUTUHAN PERANGKAT LUNAK (SKPL)Spesifikasi Kebutuhan Perangkat Lunak (SKPL) atau Software Requirements Specification (SRS)

Dokumen yang berisi pernyataan lengkap dari apa yang dapat dilakukan oleh perangkat lunak, tanpa menjelaskan bagaimana hal tersebut dikerjakan oleh perangkat lunak.definisi23TUJUAN PEMBUATAN SKPLSecara umum : untuk mendefinisikan keinginan yang biasanya dinyatakan dalam bentuk penjelasan umum. Secara khusus digunakan untuk:Sarana komunikasi antara pelanggan, pemakai, analis, dan perancang perangkat lunak.Dasar untuk merencanakan dan melaksanakan aktivitas pengujian sistem.-Acuan untuk melakukan perbaikan dan perubahan perangkat lunak.

24SYARAT PEMBENTUKAN SKPLMudah diidentifikasiDiuraikan dengan jelas, sederhana, dan konsisten (jelas, tidak ambigu)Bisa divalidasi dan bisa dites (test reliable, test accessable)Mampu untuk ditelusuri kembali (tracebility)25ATRIBUT PENULISAN SKPL YANG BAIKBenar (correct)TepatLengkapBisa diverifikasi (verifiable)KonsistenUnderstandableDapat ditelusuri (traceable) etc.

26ANALISIS TERSTRUKTURD E F I N I S I

Analisis Terstruktur (Structured Analysis) merupakan salah satu teknik analisis yang mengunakan pendekatan berorientasi fungsi. Teknik yang mempunyai sekumpulan petunjuk dan perangkat komunikasi grafis yang memungkinkan analis sistem mendefinisikan spesifikasi fungsional perangkat lunak secara terstruktur.27PERANGKAT PEMODELAN ANALISIS TERSTRUKTURDiagram Aliran Data / Data Flow Diagram (DFD)Diagram untuk menggambarkan aliran data dalam sistem, sumber dan tujuan data, proses yang mengolah data tersebut, dan tempat penyimpanan datanya.

Elemen yang membentuk DFD, yaitu :aliran data, proses, penyimpanan data dan sumber/tujuan data.28PERANGKAT PEMODELAN ANALISIS TERSTRUKTURNotasi Data Flow Diagram DFD

29PERANGKAT PEMODELAN ANALISIS TERSTRUKTURKamus Data atau Data DictionaryTempat penyimpanan untuk mendeskripsikan rincian dari aliran data atau informasi yang mengalir dalam sistem, elemen-elemen data, file maupun basis ata dalam DFD.Aturan (konvensi) penulisan menggunakan notasi berikut:=sama dengan atau terdiri dari atau terbentuk dari+dan[]pilih salah satu{}iterasi atau pengulangan()pilihan (option)*komentar|pemisah30Alat dan Teknik Pengembangan SistemGraphical toolsHIPO, Data Flow Diagram, Structure Chart, SADT, Warnier/Orr, Jakson's Diagram.

Diagram ChartActivity Chart, Systems Flowchart, Program Flowchart (Program Logic Flowchart, Detailed Computer Program Flowchart), Paperwork Flowchart / Form Flowchart, Database Relationship Flowchart, Process Flowchart, Gantt Chart, Layout Charting, Personal Relationship Charting, Working Distribution Chart, Organization Chart31Alat dan Teknik Pengembangan SistemTechnique PublicTeknik Manajemen Proyek (Penjadualan Proyek)CPM (Critical Path Method)PERT (Program Evalution and Review Technique)Fact Finding Technique (Mengumpulkan data dan menemukan fakta)Interview, Observation, Questionaires, SamplingCost Effectiveness Analysis / Cost Benefit Analysis

32Contoh Format SKPL1PENDAHULUAN 1.1 Tujuan 1.2 Ruang Lingkup 1.3 Definisi 1.4 Referensi 1.5 Sistematika 2. DESKRIPSI UMUM 2.1 Perspektif 2.2 Kegunaan 2.3 Karakteristik Pengguna 2.4 Batasan-batasan 2.5 Asumsi dan Ketergantungan

3. SPESIFIKASI KEBUTUHAN 3.1 Kebutuhan Fungsional 3.1.1 Pendahuluan 3.1.2 Input 3.1.3 Proses 3.1.4 Output 3.2 Kebutuhan Antarmuka Eksternal 3.2.1 Antarmuka Pengguna 3.2.2 Antarmuka Perangkat Keras 3.2.3 Antarmuka Perangkat Lunak 3.2.4 Antarmuka Komunikasi 3.3 Kebutuhan Performansi 3.4 Kendala Disain 3.4.1 Standard Compliance 3.4.2 Perangkat Keras 3.5 Atribut 3.5.1 Keamanan Sistem 3.5.2 Pemeliharaan 3.6 Kebutuhan Lain 3.6.1 Database 3.6.2 Pengoperasian 3.6.3 Penyesuaian Tempat

33