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 nonfungsional 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 aktivitasaktivitas 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 fungsifungsi 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.