Rekayasa Perangkat Lunak (Software Engineering)
g g Memahami p pengertian kebutuhan p perangkat lunak. Memahami apa yang dimaksud dengan analisis kebutuhan dan tahap pelaksanaannya. Mengetahui arti, fungsi, dan sistematika penulisan dokumen Spesifikasi p p Kebutuhan Perangkat Lunak.
Graha Prakarsa, ST. MT. Sekolah Tinggi Teknologi Bandung 1
Kebutuhan perangkat g lunak kondisi atau kemampuan yang harus dimiliki oleh perangkat lunak untuk memenuhi apa yang disyaratkan atau diinginkan pemakai. Tiga buah jenis kebutuhan perangkat lunak
2
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. diinputkan
Kebutuhan ebutu a fungsional u gs o a (fu (functional ct o a requirement) equ e e t) Kebutuhan antarmuka (interface requirement)
Perangkat lunak harus mampu menyajikan informasi jalur pengiriman terpendek.
Kebutuhan unjuk kerja (performance requirement) 3
4
1
Kebutuhan antarmuka yang menghubungkan perangkat lunak dengan elemen perangkat keras, perangkat lunak lain, atau basis data. Contoh:
Akses ke basis data menggunakan ODBC (Open Data Base
Waktu tanggap penyajian informasi maksimal selama satu
Connectivity). Perangkat
untuk memasukkan keyboard, mouse, dan scanner.
Kebutuhan yang menetapkan karakteristik unjuk kerja yang harus dimiliki oleh perangkat lunak, seperti kecepatan, ketepatan, atau frekuensi. Contoh: menit.
data
menggunakan
Perangkat lunak harus mampu mengolah data sampai 1
juta record untuk setiap transaksi. transaksi Perangkat lunak harus dapat digunakan secara multi user
sesuai otoritas yang diberikan kepada masing‐masing pemakai. 5
6
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. Menurut Davis (1993) Produk perangkat lunak yang tidak sempurna akan k d h lk dihasilkan k karena k l h kesalahan pada d 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).
Proses mempelajari kebutuhan pemakai untuk mendapatkan definisi kebutuhan sistem atau perangkat lunak (IEEE, 1993). 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 (Pressman, 2001).
7
8
2
the real problem Requirements specification correct specification
erroneous specification
Design correct design
erroneous design
correct program
programming error
correct functions
correctable errors
design based on erroneous specification
Implementation program based program based on erroneous on erroneous design specification
Testing uncorrectable errors
hidden errors
imperfect program products
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 serta mungkin akan menimbulkan 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.
9
Tahap kebutuhan perangkat lunak dimulai dengan (Davis, 1993): Adanya masalah yang membutuhkan penyelesaian: 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.
10
1. 2. 3. 4. 5.
Mempelajari dan memahami persoalan Mengidentifikasi kebutuhan pemakai Mendefinisikan kebutuhan perangkat lunak Membuat dokumen spesifikasi kebutuhan Mengkaji ulang (review) kebutuhan
T h Tahap k b t h kebutuhan b khi apabila berakhir bil deskripsi d k i i lengkap l k d i 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). 11
12
3
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: 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 model‐model tertentu sesuai dengan jenis masalahnya. Sebagai contoh, untuk masalah bisnis dapat menggunakan flowmap atau business use case. 13
Tahap identifikasi kebutuhan pemakai (user requirement) ini pada prakteknya p y dilaksanakan bersamaan dengan g p pemahaman masalah. Cara yang digunakan pun relatif sama. Hanya saja, substansi yang ditanyakan biasanya adalah: Data atau informasi apa yang akan diproses? Fungsi apa yang diinginkan? Perilaku sistem apa yang diharapkan? Antarmuka apa yang tersedia (user interfaces, hardware interfaces, software interfaces, interfaces dan communications interfaces)?
Untuk dapat menangkap kebutuhan pemakai dengan baik diperlukan kesamaan persepsi dengan cara: Komunikasi dan brainstorming yang intensif. Prototype perangkat lunak, atau screen snapshot. Data atau dokumen yang lengkap.
14
Saat mengidentifikasi kebutuhan pemakai, informasi yang diperoleh di l h belum b l terstruktur. k Pemakai P k i akan k mengungkapkan k k 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. saja Pada tahap ini, kebutuhan pemakai yang belum terstruktur tersebut dianalisis, diklasifikasikan, dan diterjemahkan menjadi kebutuhan fungsional, antarmuka, dan unjuk kerja perangkat lunak.
15
16
4
Sebagai gambaran, kebutuhan “data yang dimasukkan oleh Bagian Penjualan diklasifikasikan, dan dapat langsung dijurnal dijurnal” setelah dianalisis, dianalisis diklasifikasikan 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 data. d otoritas i pemakaian k i perangkat k lunak l k dan d akses k d ▪ 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.
17
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.
18
19
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. U t k itu, Untuk it di l k diperlukan negosiasi i i antara t pihak ih k pengembang dengan pemakai sesuai prinsip “win‐ win solution” sampai kebutuhan tersebut dapat disepakati kedua belah pihak. 20
5
SKPL adalah dokumen yang berisi pernyataan lengkap dari apa yang harus dilakukan atau dipenuhi oleh perangkat lunak, tanpa menjelaskan bagaimana hal tersebut dilaksanakan oleh perangkat lunak. Selain itu, SKPL pun berisi deskripsi lengkap dari semua antarmuka t k yang ada d dalam d l perangkat k t lunak. l k
Sarana komunikasi antara pelanggan, pemakai, analis, dan perancang perangkat lunak. Dasar untuk merencanakan dan melaksanakan pengujian sistem. Acuan untuk melakukan perbaikan atau pengubahan perangkat lunak.
21
Memastikan kesamaan antara kebutuhan untuk pengembangan d dengan k b h yang ditulis kebutuhan di li dalam d l d k dokumen. Mendefinisikan kerangka kerja bersama untuk proses‐proses pengembangan perangkat lunak. Memperjelas peran dan antarmuka bagi para pihak yang terlibat dalam proses‐proses pengembangan perangkat lunak. Memperjelas jenis dan isi dari dokumen. Mengenali tugas‐tugas, tahapan‐tahapan, baselines, aktivitas kaji ulang, dan dokumentasinya. Belajar dari pendekatan praktis yang diterapkan di dunia industri. Menghilangkan jebakan‐jebakan dan persoalan‐persoalan seperti yang dialami di masa lalu.
22
Memberikan penjelasan yang berlebih‐lebihan dan berulang‐ ulang sehingga menjadi tidak jelas. Menggunakan istilah secara tidak konsisten. Menyatakan keterukuran kebutuhan secara tidak jelas, misalnya dengan menggunakan kata‐kata: minimal, maksimal, optimial, cepat, user‐friendly, mudah, sederhana, normal, efisien, fleksibel, dan/atau, dan lain‐lain, atau dan sebagainya. Menuliskan “mimpi‐mimpi”, yaitu hal‐hal yang tidak akan dapat dilakukan oleh perangkat lunak.
23
24
6
1. 2. 3. 4. 5. 6. 77. 8. 9. 10. 11.
Benar Tidak bias (unambiguous) Lengkap Dapat diverifikasi Konsisten Dapat dipahami oleh pelanggan Dapat p dimodifikasi Dapat ditelusuri Mempunyai keterangan (annotated) Ringkas Terorganisasi
1. 2. 3. 4. 5. 6. 7. 8. 9.
25
1. PENDAHULUAN 1.1 Kegunaan ua g Lingkup g up 1.2 Ruang 1.3 Definisi, Akronim, dan Singkatan 1.4 Referensi 1.5 Ikhtisar 2. DESKRIPSI UMUM 2.1 Perspektif Produk 2.2 Fungsi Produk 2.3 Karakteristik Pemakai 2.4 Batasan‐batasan 2.5 Asumsi dan Ketergantungan 3. KEBUTUHAN RINCI 3.1 Kebutuhan Antarmuka Eksternal 3.1.1 Antarmuka Pemakai 3.1.2 Antarmuka Perangkat Keras 3.1.3 Antarmuka Perangkat Lunak 3.1.4 Antarmuka Komunikasi 3.2 Kebutuhan Fungsional 3.2.1 Deskripsi Kebutuhan Fungsional 3.2.2 Diagram Konteks
3.3 3.4 3.5 3.6
3.2.3 Diagram Aliran Data 3.2.3.1 Diagram Aliran Data Proses 1 33.2.3.2 Diagram Aliran 3 ag a a Data Proses ata oses 2 . . 3.2.3.n Diagram Aliran Data Proses n 3.2.4 Kamus Data 3.2.4.1 Tempat Penyimpanan Data 3.2.4.2 Aliran Data 3.2.5 Spesifikasi Proses 3.2.5.1 Proses 1 3.2.5.2 Proses 2 . . 3.2.5.m Proses m Kebutuhan Performansi Kendala Perancangan Atribut Sistem Perangkat Lunak Kebutuhan Lain 27
Pemakai Pelanggan Analis Sistem (System Engineer) Software Engineer Pemrogram Test Integration Group M i t Maintenance Group G Technical Support Staf dan Clerical Work
26
Kebutuhan perangkat lunak dapat diartikan sebagai sesuatu (kemampuan, kondisi, kriteria) yang harus ada atau dipenuhi oleh perangkat lunak. Ada tiga jenis kebutuhan, yaitu fungsional, antarmuka, dan unjuk kerja. Kebutuhan perangkat lunak didefinisikan melalui proses analisis kebutuhan. Ada serangkaian tahap yang harus dilaksanakan sebelum dapat mendefinisikan kebutuhan ini. Hasil dari proses analisis kebutuhan dapat menjadi faktor sukses pelaksanaan pengembangan perangkat lunak. Kebutuhan perangkat lunak ditulis secara sistematis dalam suatu dokumen yang disebut SKPL, sehingga dapat dijadikan acuan oleh pemakai dan pengembang saat dan setelah pelaksanaan pembuatan perangkat lunak. Untuk itu, ada beberapa hal, seperti atribut dan sistematika, yang harus diperhatikan untuk dapat menuliskan SKPL yang baik.
28
7
Setelah UTS kumpulkan fungsi‐fungsi/modul‐modul perangkat lunak apa saja yang nanti akan dikembangkan. dikembangkan Tugas dikumpulkan dalam bentuk power point (3‐6 slide sudah cukup). Tugas dikumpulkan melalui email hari minggu tanggal 13‐12‐2015 jam 24.00 ke “
[email protected]” Tanggal 14‐12‐2015 (pertemuan setelah UTS) dipresentasikan.
Analisis Terstruktur
Isi tugas: 1. Nama dan anggota Kelompok, contoh: PASTI JADI CORP. 2. Kumpulan fungsi/modul, contoh: modul input data penjualan & pembelian, pencetakan laporan …., dll. Intinya menceritakan software‐nya nanti memiliki fungsi apa saja. 29
Kelompok 1: Restoran (Ahmad)
Kelompok 2: Hotel (Dejan)
Kelompok 3: Bioskop (Dede)
30
31
8
