Penjelasan Tugas Kelompok Proyek Perangkat Lunak

Definisi Kebutuhan Kebutuhan perangkat lunak adalah kondisi atau kemampuan yang harus dimiliki oleh perangkat lunak untuk memenuhi apa yang disyaratkan atau diinginkan oleh pemakai

Apa yang Dimaksud Analisis Kebutuhan? 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]. Tujuan analisis kebutuhan perangkat lunak adalah: Memahami masalah yang akan dibuat perangkat lunaknya secara menyeluruh (komprehensif). Mendefinisikan apa yang harus dikerjakan oleh perangkat lunak untuk memenuhi keinginan pemakai.

Jenis Kebutuhan Secara 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 Requirement

Kebutuhan fungsional Disebut juga kebutuhan operasional, yaitu kebutuhan yang berkaitan dengan fungsi atau proses transformasi yang harus mampu dikerjakan oleh perangkat lunak. 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.

Kebutuhan antarmuka Kebutuhan antarmuka yang menghubungkan perangkat lunak dengan elemen perangkat keras, perangkat lunak, atau basis data. Contoh: Akses ke basis data menggunakan ODBC (Open Data Base Connectivity). Perangkat untuk memasukkan data menggunakan keyboard, mouse, dan scanner.

Kebutuhan unjuk kerja Kebutuhan yang menetapkan karakteristik unjuk kerja yang harus dimiliki oleh perangkat lunak, seperti kecepatan, ketepatan, atau frekuensi. 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.

Analisis Kebutuhan 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].

Analisis Kebutuhan Tujuan analisis kebutuhan perangkat lunak adalah: Memahami masalah yang akan dibuat perangkat lunaknya secara menyeluruh (komprehensif). Mendefinisikan apa yang harus dikerjakan oleh perangkat lunak untuk memenuhi keinginan pemakai.

Pentingnya Analisis Kebutuhan Pendefinisian kebutuhan yang baik dapat menjadi faktor sukses pelaksanaan pengembangan perangkat lunak. Sebaliknya akan menyebabkan banyak kegagalan. Menurut hasil survey DeMarco, 56% kegagalan proyek perangkat lunak adalah karena ketidaklengkapan pendefinisian kebutuhan.

Pentingnya Analisis Kebutuhan Produk perangkat lunak yang tidak sempurna akan dihasilkan karena kesalahan pada saat menentukan spesifikasi kebutuhan. Jika kesalahan tersebut diketahui di akhir siklus hidup pengembangan, usaha untuk memperbaikinya akan sangat mahal (sekitar 82% dari total biaya perbaikan).

Mengapa Analisis Kebutuhan Penting? Pendefinisian kebutuhan yang baik dapat menjadi faktor sukses pelaksanaan pengembangan perangkat lunak. Sebaliknya akan menyebabkan banyak kegagalan. Menurut hasil survey DeMarco, 56% kegagalan proyek perangkat lunak adalah karena ketidaklengkapan pendefinisian kebutuhan. Dari gambar terlihat bahwa produk perangkat lunak yang tidak sempurna akan dihasilkan karena kesalahan pada saat menentukan spesifikasi kebutuhan. Jika kesalahan tersebut diketahui di akhir siklus hidup pengembangan, usaha untuk memperbaikinya akan sangat mahal (sekitar 82% dari total biaya perbaikan).

Dampak kesalahan penentuan kebutuhan Perangkat lunak yang dihasilkan tidak akan memenuhi kebutuhan pemakai yang sebenarnya. Intepretasi kebutuhan yang berbeda-beda sehingga dapat menyebabkan ketidaksepakatan antara pelanggan dan pengembang, menyia-nyiakan waktu dan biaya, dan mungkin akan menghasilkan perkara hukum. Pengujian kesesuaian perangkat lunak dengan kebutuhan yang dimaksud tidak akan mungkin dilaksanakan dengan benar. Waktu dan biaya akan terbuang percuma untuk membangun perangkat lunak yang salah.

Tahap Analisis Kebutuhan Tahap kebutuhan perangkat lunak dimulai dengan [DAV93]: Adanya masalah yang membutuhkan penyelesaian: orientasi aplikasi, misalnya inventory orientasi bisnis, misalnya produk baru, peramalan pendapatan orientasi peningkatan produk, misalnya pemeliharaan Munculnya ide untuk membuat sebuah perangkat lunak baru.

Tahap Analisis Kebutuhan 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 (SKPL).

Tahap Analisis Kebutuhan Secara teknis pelaksanaan pekerjaan analisis kebutuhan perangkat lunak pada dasarnya terdiri dari urutan aktivitas: Mempelajari dan memahami persoalan Mengidentifikasi kebutuhan pemakai Mendefinisikan kebutuhan perangkat lunak Membuat dokumen spesifikasi kebutuhan Mengkaji ulang (review) kebutuhan

Proses Analisis Kebutuhan

Mempelajari dan memahami persoalan .. (1) 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

Mempelajari dan memahami persoalan .. (1) 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

Mempelajari dan memahami persoalan .. (3) Hasil 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 mengunakan, misalnya, graf. Pemesanan Makanan Pembayaran Makanan Pembeli Penyerahan Makanan

Mengidentifikasi Kebutuhan Pemakai .. (1) Sebenarnya, tahap identifikasi kebutuhan pemakai (user requirement) ini pada prakteknya dilaksanakan bersamaan dengan pemahaman masalah. Cara yang digunakan pun relatif sama.

Mengidentifikasi Kebutuhan Pemakai .. (2) 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).

Mengidentifikasi Kebutuhan Pemakai .. (3) 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

Mendefinisikan Kebutuhan Perangkat Lunak .. (1) Saat mengidentifikasi kebutuhan pemakai, informasi yang diperoleh belum terstruktur. Pemakai akan mengungkapkan apa yang dibutuhkannya dengan bahasa sehari-hari 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” 08/04/2017 -ap-

Mendefinisikan Kebutuhan Perangkat Lunak .. (2) Pada tahap ini, kebutuhan pemakai yang belum terstruktur tersebut dianalisis, diklasifikasikan, dan diterjemahkan menjadi kebutuhan fungsional, antarmuka, dan unjuk kerja perangkat lunak.

Mendefinisikan Kebutuhan Perangkat Lunak .. (3) Kebutuhan pemakai (di Bagian Akuntansi) 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). “saya ingin data yang dimasukkan oleh Bagian Penjualan bisa langsung dijurnal”.

Mendefinisikan Kebutuhan Perangkat Lunak .. (4) 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 Kebutuhan unjuk kerja: ada otoritas pemakaian perangkat lunak dan akses data. proses jurnal hanya dapat dilakukan sekali setelah data transaksi penjualan direkam.

Mendefinisikan Kebutuhan Perangkat Lunak .. (5) 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.

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.

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.

Software Requirements Spefication (SRS)

S R S : sebuah dokumen yang berisi pernyataan lengkap dari apa yang dapat dilakukan oleh perangkat lunak, tanpa menjelaskan bagaimana hal tersebut dikerjakan oleh perangkat lunak mencantumkan deskripsi perangkat lunak dengan lingkungannya (Mencakup antarmuka untuk perangkat keras, perangkat lunak, komunikasi dan pemakai). SRS umumnya dikembangkan bersama oleh calon pengguna dan para pengembang system/perangkat lunak

Faktor-faktor yg dipertimbangkan dlm pembuatan SRS: Untuk Siapa perangkat lunak dikembangkan ? Siapa yang menyediakan dana ? Kepada siapa proposal pengembangan perangkat lunak akan diberikan ? Yakinkan calon pengguna bahwa perangkat lunak yang akan dibuat memang dibutuhkan

Masalah apa yang akan diselesaikan dengan kehadiran perangkat lunak yang baru ? seorang analis perlu berfikir dengan seksama masalah apa yang akan diselesaikan dengan kehadiran perangkat lunak baru. Harus dingat.! Komputer hanya alat bantu. Komputer tidak dapat memecahkan semua masalah yang ada pada suatu perusahaan.

Dimana perangkat lunak akan diimplementasikan ? karakteristik yang berbeda terhadap kebutuhan calon pengguna akan mempengaruhi model dan desain perangkat lunak yang dikembangkan, termasuk implementasi di lapangan

Kapan perangkat lunak yang baru sudah harus dijalankan ? para pengembang harus memperhatikan kapan waktu dimulainya pengerjaan proyek pengembangan perangkat lunak baru dan kapan waktu perangkat lunak tersebut sudah harus dikembangkan Berpengaruh terhadap model pengembangan perangkat lunak yang akan dipergunakaan.

Fungsi dokumen SRS: mencatat semua kebutuhan calon pengguna perangkat lunak. sebagai kontrol saat proses pengembangan perangkat lunak dilakukan, sehingga setiap tahapan pengerjaan pengembangan sesuai dengan yang diharapkan. Digunakan sebagai acuan pada saat pengujian dilakukan sehingga hasil akhir sesuai dengan yang dibutuhkan. Dijadikan pedoman jika terdapat perbedaan pendapat antara calon pemakai dengan pengembang sistem terhadap hasil dari pengembangan perangkat lunak Bukti bahwa pengembang telah melakukan tahap software reguirements analysis.

Kriteria dokument SRS yang baik: Benar (correct) Tepat (precise) Unambiguouity Lengkap (complete) Bisa diverifikasi (verifiable) Konsisten Understandable Bisa dimodifikasi (modifiedable) Dapat ditelusuri (traceable)

Harus dapat dibedakan bagian what (bagian spesifikasi) dan how (bagian yang menjelaskan bagaimana menjelaskan what tadi) Dapat mencakup dan melingkupi seluruh sistem Dapat melingkupi semua lingkungan operasional, misalnya interaksi fisik dan operasional. Bisa menggambarkan sistem seperti yang dilihat oleh pemakai. Harus toleran (bisa menerima) terhadap ketidaklengkapan, ketidakpastian (ambiguous) dan ketidak konsistenan. Harus bisa dilokalisasi dengan sebuah coupling, yaitu hubungan ketergantungan antara dua model yang tidak terlalu erat.

Hindari hal-hal berikut saat pembentukan SRS Over specification (penjelasan berlebih dan berulang-ulang sehingga menjadi tidak jelas) Tindakan unconcistency Ambiguity dalam kata atau kalimat Menuliskan “mimpi-mimpi” , yaitu hal-hal yang tidak bisa dilakukan

Aspek yg harus terlihat di SRS: Fungsi Menjelaskan fungsi dari perangkat lunak (digunakan untuk apa keperluan apa), sifat perangkat lunak dan datanya. Non-Fungsi Reliability Aintainbility Security integrity Ergonomic Performance

orang yang terlibat dalam pembuatan SRS Pemakai (user) Merupakan orang yang akan mengoperasikan/menggunakan produk final dari perangkat lunak yang dibuat. Sponsor/ Client Orang atau perusahaan yang mau membuat sistem (yang menentukan). Sistem analyst (sistem engineer) Adalah orang yang biasa melakukan kontak teknik pertama dengan client. Bertugas menganalisis persoalan, menerima requirement dan menulis requirement. Software engineer Merupakan orang yang bekerja setelah kebutuhan perangkat lunak dibuat (bekerja sama dengan sistem engineer berdasarkan SRS) Programmaer Orang yang akan menerima spesifikasi perancangan perangkat lunak, membuat kode dalam bentuk modul, menguji dan memeriksa (tes) modul.

Test integration group Kumpulan orang yang melakukan tes dan mengintegrasi modul. Maintenance group Orang yang memantau dan merawat performansi sistem perangkat lunak yang dibuat selama pelaksanaan dan pada saat modifikasi muncul (80% dari pekerjaan). Technical Support Orang-orang yang mengelola (manage) pengembang perangkat lunak, termasuk konsultan atau orang yang mempunyai kepandaian lebih tinggi. Staff dan Clerical Work Bertugas mengetik, memasukkan data dan membuat dokumen.

Contoh Layout Dokumen SRS PENDAHULUAN Tujuan Ruang Lingkup Definisi Referensi Sistematika DESKRIPSI UMUM Perspektif Kegunaan Karakteristik Pengguna Batasan-batasan Asumsi dan Ketergantungan SPESISIKASI KEBUTUHAN Kebutuhan Fungsional Pendahuluan Input Proses Output

Kebutuhan Antarmuka Eksternal Antarmuka Pengguna Antarmuka Perangkat Keras Antarmuka Perangkat Lunak Antarmuka Komunikasi Kebutuhan Performasi Kendala Desain - Standard Compliance - Perangkat Keras #. Atribut - Keamanan Sistem - Pemeliharaan Kebutuhan Lain Database Pengoperasian Penyesuaian Tempat