kajian dan spesifikasi perangkat...
TRANSCRIPT
KAJIAN DAN SPESIFIKASI 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
A. SPESIFIKASI PERANGKAT LUNAK
Spesifikasi menggambarkan kebutuhan atau persyaratan (requirement) apa saja yang
harus dipenuhi oleh sistem perangkat lunak dan menentukan batasan pada operasi serta
implementasinya. Ada dua jenis kebutuhan sistem, yaitu fungsional dan non fungsional.
Kebutuhan fungsional menetapkan layanan sistem yang harus disediakan. Kebutuhan non-
fungsional berkaitan dengan ketentuan yang harus dipenuhi semua layanan pada sistem,
menyangkut kinerja, kehematan, keamanan dan mutu informasi.
Kebutuhan pengguna akhir menetapkan data dan informasi apasaja yang perlu di
akses dari sistem. Kebutuhan pengguna harus ditulis dalam tabel bahasa alami atau diagram.
Persyaratan sistem dapat ditulis dalam bahasa alami terstruktur, PDL atau dalam bahasa
formal. Sedangkan dokumen persyaratan perangkat lunak adalah pernyataan yang disepakati
oleh pengguna dan pengembang, tentang persyaratan sistem yang dibangun.
Metode spesifikasi sama dengan pemecahan masalah. Pereka Perangkat Lunak yang
dipaksa bekerja dengan spesifikasi yang tidak lengkap, tidak konsisten, atau salah akan
mengalami frustasi atau keraguan. Akibatnya, kualitas , ketepatan waktu dan kelengkapan
perangkat lunak menjadi korban.
Spesifikasi perangkat lunak merupakan proses untuk menentukan pelayanan (servis)
apa yang dibutuhkan dan kendala-kendala pengoperasian sistem serta pengembangannya.
Berikut ini tahapannya:
1. Proses Rekayasa Kebutuhan
2. Studi Kelayakan
3. Analisis kebutuhan
4. Spesifikasi Kebutuhan
5. Validasi spesifikasi
1) Proses Rekayasa Kebutuhan
Apa yang menjadi kesuksesan dalam sebuah perangkat lunak?
Apa system yang cukup mampu memenuhi semua kebutuhan penggunanya?
Apa sistem yang cukup mampu memenuhi semua kebutuhan penggunanya?
Tinggat kepuasan penggunannya?
Rekayasa kebutuhan mencangkup beberapa proses mengenai fakta ini, proses
rekayasa kebutuhan adalah sekumpulan aktivitas-aktivitas yang terstruktur untuk diperoleh,
memvalidasi dan memelihara dokumen kebutuhan system (Thayer. 1997).
Pada umumnya tugas rekayasa digambarkan sebagai penciptaan dari solusi keaktivan
biaya untuk masalah kehidupan yang nyata dengan menerapkan pengetahuan keilmuan.
Rekayasa kebutuhan juga dapat digambarkan sebagai tugas untuk memenuhi aktivitas-
aktivitas pengembangan untuk masalah dunia nyata sehingga ketepatan dan keefektifan biaya
dari solusi dapat dianalis (Nuseibeh, 2000).
Dari sudut pandang pengembangan sistem perangkat lunak, dua aktivitas dapat
dikenali sebagai rekayasa kebutuhan dan rekayasa perangkat lunak. Rekayasa perangkat
lunak dapat digambarkan sebagai aktivitas yang terlibat dalam siklus hidup dari proses
pengembangan perangkat lunak, dengan rekayasa kebutuhan yang menjadi pusat aktivitas di
dalam siklus hidup.
Latar belakang kenapa rekayasa kebutuhan diperlukan adalah kenyataan bahwa
menemukan kebutuhan klien secara lengkap merupakan usaha yang tidak mudah dan mahal.
Dikatakan tidak mudah karena,
Klien tidak selalu mengetahui dengan pasti dan jelas mengenai apa yang diperlukan,
Kebutuhan yang diutarakan oleh klien tidak selalu sesuai dengan apa yang dimaksud,
Kebutuhan klien berubah-ubah di sepanjang kegiatan pembangunan perangkat lunak.
Hal tersebut menyebabkan biaya pembangunan perangkat lunak menjadi mahal
karena ada tambahan biaya dan tambahan waktu untuk perubahan yang dilakukan.
Daur hidup suatu perangkat (SLC) secara umum dapat diilustrasikan sebagai gambar
diatas, dimana ada 2 buah siklus kehidupan utama dari suatu perangkat lunak, yaitu daur
hidup pengembangan perangkat lunak (SDLC) dan daur hidup pengoperasian perangkat
lunak (SOLC), keduanya dihunbungkan oleh dua buah proses, yaitu proses studi kelayakan
dan proses peluncuran.
Pengembangan perangkat lunak pada dasarnya muncul karena adanya suatu
kebutuhan baru. Melalui studi kelayakan, kita dapat dibantu menentukan apakah kebutuhan
tersebut masih dapat dipenuhi oleh sistem perangkat lunak yang ada atau tidak. Jika
dipandang bahwa sistem yang sudah ada tidak dapat memenuhi kebutuhan baru tersebut,
maka kita akan memutusakan apa mau mengembangkan sistem perangkat lunak (baik sistem
lama atau baru). Studi kelayakan tetap dilakukan dalam pengembangan perangkat lunak
berskala besar maupun kecil.
Sistem yang baru yang akan dikembangkan bisa dibangun dari sistem lama, atau dari
sistem baru. Sering juga disebut lingkungan pengembangan (development enviornment).
Proses pertama yang dilakukan dengan penspesifikasian kebutuhan, hasil dari proses ini
adalah sebuah spesifikasi kebutuhan sistem yang dibutuhkan oleh pembuat. Spesifikasi ini
sering disebut sebagai rancangan bersifat high-end. Berdasarkan spesifikasi tersebut, pihak
pengembang akan membuat suatu rancangan yang bersifat lowend. Kemudian
diimplementasikan menjadi produk perangkat lunak oleh programmer. Melalui proses
pengujian produk ini diuji dan dipastikan kesesuaiannya dengan spesifikasi kebutuhan yang
telah ditetapkan dan ketetapan implementasinya. Produk yang berhasil melewati proses
pengujian kemudaian akan diluncurkan ke lingkungan operasioanl (operatioan environment).
Dalam daur pengoperasian , perangkat lunak yang telah selesai dibangun difungsikan
untuk kebutuhan operasiional sistem. Seringkali, terdapat ketidaksesuaian antara perangkat
lunak dengan kebutuhan di lapangan. Kesalahan ini terjadi pada beberapa kesalahan pada
daur hidup pengembangan dan akan diperbaiki.
Proses ini sering dipandang sebagai proses perawatan perangkat lunak. Tapi jika
kesalahan itu terjadi karena kebutuhan baru dalam organisasi maka perangkat lunak tersebut
dikaji ulang kelayakannya. Dan kembali pada daur hidup perangkat lunak tersebut.
Spesifikasi kebutuhan merupakan proses awal dari daur hidup pengembangan
perangkat lunak. Keluaran dari proses ini menentukan arah pengembangan perangkat lunak
selanjutnya. Tahap pekerjaan analisis kebutuhan perangkat lunak pada dasarnya terdiri dari
urutan aktivitas :
1. Menentukan kebutuhan (requirement)
Lebih banyak berhubungan dengan pemakai. Hasil belum terstruktur.
a. Data atau informasi apa yang akan diproses
b. Fungsi apa yang diinginkan
c. Kelakuan sistem apa yang diharapkan
d. 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 metodeanalisis tertentu.
3. Membuat dokumen Software Requirements Spesification (SRS).
Sudah merupakan analisis yang lebih rinci, sebagai tahap awal perancangan.
2) Studi Kelayakan
Untuk semua sistem baru, proses rekayasa persyaratan harus dimulai studi kelayakan.
Input dari studi kelayakan adalah deskripsi garis besar sistem dan bagaimana sistem akan
digunakan di dalam organisasi. Hasil studi kelayakan berwujud laporan. Studi Kelayakan
memutuskan apakah sistem software yang akan dibuat sudah mencakup seluruh aspek
permasalahan. Melakukan studi kelayakan mencakup penilaian informasi, pengumpulan
informasi,dan penulisan laporan.
Melakukan studi untuk menguji apakah sistem:
Sudah sesuai dengan tujuan organisasi
Dapat dikembangkan dengan teknologi terkini dan dana yang tersedia
Dapat diintegrasikan dengan sistem lain yang sudah digunakan
3) Implementasi Studi Kelayakan
Implementasi menurut kamus besar indonesia, diartikan sebagai pelaksanaan atau
penerapan, artinya yang dilaksanakan dan diterapkan adalah kurikulum yang telah dirancang
atau didesain untuk kemudian dijalankan sepenuhnya. Berbasiskan pada penilaian informasi
(apa yg dibutuhkan), pengumpulan informasi dan penulisan laporan
Pertanyaan ke personal di organisasi:
1. Apa yang akan terjadi apabila sistem tidak diimplementasikan?
2. Masalah proses apa yang ada ?
3. Apa yang dapat dibantu oleh sistem ?
4. Masalah apa yang akan muncul pada proses Integrasi ?
5. Adakah teknologi baru yang dibutuhkan? Skill yang dibutuhkan ?
6. Fasilitas apa yang harus didukung oleh sistem ?
4) Validasi Kebutuhan
Validasi adalah suatu tindakan pembuktian dengan cara yang sesuai dengan tiap
bahan proses, prosedur, kegiatan, sistem, perlengkapan atau mekanisme yang digunakan
dalam produksi dan pengawasan yang akan senantiasa mencapi hasil yang diinginkan.
Validasi dibutuhkan untuk memberikan kepastian bahwa rancangan dan dokumen dari
sistem yang akan diimplementasiakn telah sesuai dengan keinginan dan kebutuhan pemangku
kepentingan baik pemesan, pengguna maupun pihak pengembang. Tujuan dari validasi
kebutuhan adalah :
Bertujuan untuk meyakinkan bahwa kebutuhan yang sudah didefinisikan sesuai
dengan yang diinginkan pengguna
Menghindari Kesalahan pendefinisian kebutuhan karena akan menyebabkan
penambahan biaya yang besar
Memperbaiki definisi kebutuhan setelah software dikirim akan menyebabkan
peningkatan biaya hingga 100 kali.
Analisa kebutuhan merupakan langkah awal untuk menentukan perangkat lunak
seperti apa yang akan dihasilkan, ketika kita melaksanakan sebuah proyek pembuatan
perangkat lunak. Perangkat lunak yang baik dan sesuai dengan kebutuhan pengguna sangat
bergantung kepada keberhasilan dalam melakukan analisa kebutuhan. Tidak peduli
bagaimana hebatnya seseorang dalam menulis kode perangkat lunak, atau membuat antar
muka yang menawan, jika terjadi kesalahan dalam analisa kebutuhan, itu artinya perangkat
lunak yang dibuat menjadi tak berguna.
Analisa kebutuhan yang baik belum tentu menghasilkan perangkat lunak yang baik.
Tetapi analisa kebutuhan yang tidak tepat sudah pasti menghasilkan perangkat lunak yang
tidak berguna. Ini adalah sebuah pernyataan sederhana. Namun pernyataan ini tidaklah terlalu
jauh dari kesimpulan yang sebenarnya.
Adalah jauh lebih baik mengetahui ada kesalahan tentang analisa kebutuhan ketika
masih dalam tahap awal ini. Kurang hati-hati dan pelaksanaan yang tidak teliti, sehingga
mengakibatkan terjadinya kesalahan analisa kebutuhan sungguh menimbulkan banyak
kerugian. Kesalahan analisa kebutuhan yang diketahui ketika sudah memasuki penulisan
kode, atau pengujian, bahkan hampir pada tahap penyelesaian, adalah malapetaka besar bagi
sebuah kelompok pembuat perangkat lunak. Biaya dan waktu yang diperlukan menjadi
banyak yang tersia-sia.
Biaya yang diperlukan untuk memperbaiki sebuah kesalahan karena analisa
kebutuhan yang tidak benar, bisa menjadi dua puluh lima kali lipat, jika kesalahan tersebut
ditemukan pada tahap pengujian fungsi perangkat lunak
Ketika dalam tahap awal ini, sungguh diperlukan pelaksanaan analisa dengan hati-hati
dan sebaik-baiknya. Dengan diperolehnya kebutuhan yang jelas dan benar sesuai dengan apa
yang dimaksud oleh klien, menunjukkan langkah awal yang baik, yang akan membantu
ketika kita melanjutkan kepada tahap berikutnya dalam pembuatan perangkat lunak.
Dalam berbagai buku yang membahas tetang rekayasa perangkat lunak, analisa
kebutuhan merupakan bab tersendiri yang selalu dibahas dengan baik. Banyak cara yang
diuraikan untuk menghasilkan analisa kebutuhan yang akurat, sehingga penulisan perangkat
lunak juga menjadi tepat. Yang menjadi hambatan utama di sini adalah ketika melakukan
analisa kebutuhan yang sesungguhnya di lapangan. Penerapan dari teori-teori yang ada
ternyata tidak bisa begitu saja dapat dilaksanakan. Banyak ditemui hal yang perlu diantisipasi
dengan cara-cara yang lebih tepat, dan baru diketahui ketika kita sudah berada dalam situasi
yang sesungguhnya dalam sebuah proyek pembuatan perangkat lunak.
Dengan tidak mengabaikan faktor teknis, sejumlah faktor non teknis menjadi kunci
dalam keberhasilan kita memperoleh analisa kebutuhan yang benar.
Prinsip Spesifikasi
Spesifikasi, tanpa mempedulikan mode dimana kita melakukannya, dapat dilihat sebagai
sebuah proses representasi. Persyaratan diwakilkan dengan suatu cara yg membawa ke arah
implementasi yang berhasil. Berikut ini sejumlah prinsip spesifikasi yang diadaptasi dari
kerja Blazer dan Goldman [BLA 86].
1. Memisahkan fungsional dari implementasi
2. Mengembangkan suatu model dari system yang diperlukan yg meliputi data dan
respon fungsional dari suatu system terhadap berbagai stimulus dari lingkungan.
3. Membangun konteks dimana PL beroperasi dengan menentukan cara dimana
komponen system yg lain berinteraksi dengan PL.
4. Menentukan lingkungan dimana system beroperasi dan menunjukan bagaimana “
sekumpulan agen yang sangat terjalin bereaksi terhadap stimulus dalam lingkungan.
5. Menciptakan sebuah model yg kognitif daripada model desain atau implementasi.
Model kognitif menggambarkan sebuah system sebagaimana dirasakan oleh
komunitas pemakainya.
6. Mengenali spesifikasi harus toleran terhadap ketidak lengkapan dan dapat di tambah.
7. Membangun muatan dan struktur spesifikasi dengan suatu cara yang akan
memungkinkan spesifikasi dapat ditambah agar dapat berubah.
Representasi
Kita mengetahui bahwa persyaratan Perangkat Lunak dapat ditentukan dalam
berbagai cara. Akan tetapi, bila persyaratan itu dimasukan pada kertas atau media presentasi
electronic, maka diperoleh panduan sederhana:
- Format dan muatan representasi harus relevan dengan masalah.
- Informasi yang di isikan kedalm spesifikasi harus disarangkan.
Spesifikasi Persyaratan Perangkat Lunak
Spesifikasi persyaratan Perangkat Lunak dibuat pada puncak tugas analisis. Fungsi
dan kinerja yang dialokasikan pada Perangkat Lunak sebagai bagian dari rekayasa system,
diperhalus dengan membangun sebuah diskripsi informasi lengkap, diskripsi tingkah laku dan
fungsional lengkap, indikasi persyaaratan kinerja dan batasan desain, kriteria validasi yang
sesuai, dan data lain yang berkenaan dengan persyaratan. The Nation Bureau of Standards,
IEE( standard no. 830- 1984) dan Departement Pertahanan AS mengusulkan format calon
untuk spesifikasi persyaratan perangkatan perangkat lunak. Berikut merupakan kerangka
kerja untuk spesifikasi.
a) Pendahuluan
- Refrensi system
- Deskripsi keseluruhan
- Batasan proyek PL
b) Deskripsi informsi
- Representasi isi informasi
- Representasi aliran informasi
- Aliran data
- Aliran kontrola
c) Deskripsi fungsional
- Pembagian fungsional
- Deskripsi fungsional
- Gambaran pemrosesan
- Retriksi / keterbatasan
- Persyaratan kinerja Batasan desain
- Diagram pendukung
- Diskripsi control
- Spesifikasi control
- Batasan desain
d) Diskripsi prilaku
- Peryataan system
- Event dan tindakan
e) Validasi dan Kriteria
- Batas kinerja
- Kelas- kelas pengujian
- Respon Perangkat Lunak
- Pertimbangan khusus
f) Bibliografi
g) Lampiran
B. KAJIAN SPESIFIKASI PERANGKAT LUNAK
Kajian dari suatu spesifikasi persyaratan perangkat lunak dilakukan baik oleh
pelanggan atau pengembang Perangkat Lunak. Karena spesifikasi membentuk dasar bagi
desain dan aktivitas rekayasa selanjutnya, maka kajian harus dilakukan dengan hati- hati.
Kajian dilakukan pertama kali pada tingkat makroskopik.pada tingkat ini pengkaji akan
memastikan bahwa spesifikasi sudah lengkap, konsisten, dan, akurat.
Pertanyaan - pertanyaan berikut dapat di ajukan:
Apakah tujun dan sasaran yang diyatakan bagi perangkat lunak tetap konsisten
dengan tujuan dan sasaran system?
Apakah interface penting kesemua element system sudah digambarkan?
Apakah aliran informasi dan struktur didefinisikan dengan tepat bagi domain masalah
Apakah diagram jelas? apakah masing masing dapat berdiri sendiri tanpa teks
pendamping
Apakah fungsi mayor tetap ada pada ruang lingkup, dan sudah digambarkan dengan
lengkap dan tepat?
Apakah tingkah laku PL konsisten dengan informasi yang harus diproses dan fungsi
harus dilakukannya?
Apakah batasan desain realistis?
Apakah resiko teknologis pengembang sudah dipertimbangkan?
Apakah criteria validasi dinyatakan secara detail? apakah criteria tersebut kuat untuk
menggambarkan sebuah system yang berhasil.
Apakah ada inkonsistensi,penghilangan?
Apakah kontak dengan pelanggan sudah lengkap?
Apakah pemakai sudah mengkaji manual pemakai pemulaan atau prototype?
Bagaimana estimasi perencanaan mempengaruhi
Pengkaji dapat mengembangkan pertayaan diatas dengan :
Mencari konektor persuasive
Bila suatu daftar yang diberikan tidak lengkap, pastikan jenisnya sudah dipahami.
Pastikan jangkauan yg dinyatakan tidak berisi asumsi yang tidak dinyatakan.
Hati hatilah pada kata kerja yang kabur
Hati hati terhadap kata ganti yang ambiguitas. Cari pertanyaan yang
mengimplimentasikan kepastian. Bila kajian lengkap spesifikasi persyaratan Perangkat Lunak
diakhiri oleh pelanggan atau pengembang. Perubahan yang diminta setelah spesifikasi itu di
akhiri tidak akan dieleminasi, tetapi pelanggan harus mencatat bahwa masing – masing
perubahan setelah pengakhiran spesifikasi merupakan ekstensi dari ruang lingkup Perangkat
Lunak yang demikian dapat menambah biaya atau dapat memperpanjang jadwal proyek.
Bahkan dengan prosedur kajian terbaikpun, tetap ada sejumlah masalah spesifikasi.
Spesifikasi sulit di uji dalam berbagai cara yang berarti sehingga inkonsistensi dan
penghilangan dapat berlangsung tanpa terlihat.Selama kajian , perubahan terhadap terhadap
spesifikasi dapat disetujui. Sangat sulit untuk menili pengaruh global dari suatu perubahan ;
yaitu bagaimana suatu perubahan dalam suatu fungsi mempengaruhi persyaratan bagi fungsi-
fungsi yang lain.
Kesimpulan Analisis persyaratan adalah langkah teknis pertama pada proses rekayasa perangkat
lunak. Di sini pernyataan umum mengenai ruang lingkup perangkat lunak disaring ke dalam
sebuah spesifikasi konkrit yang menjadi dasar bagi aktivitas rekayasa perangkat lunak yang
mengikutinya. Analisis harus berfokus pada domain informasi, fungsional, dan tingkah laku
dari masalah. Untuk lebih memahami apa yang dibutuhkan, maka dibuatlah sebuah model;
masalah dibagi-bagi, dan representasi yang menggambarkan esensi persyaratan, dan
kemudian detail implementasi dikembangkan. Dalam beberapa kasus tidaklah mungkin untuk
secara lengkap menspesifikasi suatu masalah pada tahap awal. Prototyping menawarkan
sebuah pendekatan alternatif yang menghasilkan sebuah model perangkat lunak yang dapat
dieksekusi yang dari sana persyaratan disaring. Dibutuhkan peranti dan teknik khusus untuk
melakukan prototyping secara tepat.
Spesifikasi persyaratan perangkat lunak dikembangkan sebagai akibat dari analisis.
Kajian penting untuk memastikan bahwa pengembang dan pelanggan memiliki persepsi yang
sama mengenai sistem. Sayangnya, bahkan dengan metode yang terbaik sekalipun,
masalahnya adalah bahwa masalah tersebut terus berubah.