A. Spesifikasi Perangkat Lunak
Perangkat lunak merupakan otomasi dari proses bisnis pada sebuah organisasi, untuk menghasilkan operasi bisnis (organisasi) yang efektif (akurat) dan efisien (cepat dan murah). Spesifikasi perangkat lunak menjelaskan ketentuan atau batasan tentang apasaja yang harus diberikan oleh sebuah 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. 1. Kebutuhan Perangkat Lunak Kondisi, kriteria, syarat atau kemampuan yang harus dimiliki oleh perangkat lunak untuk memenuhi apa yang disyaratkan atau diinginkan pemakai. 2. Jenis perangkat lunak : 2.1 Kebutuhan fungsional : 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 2.2 Kebutuhan Antarmuka : kebutuhan yang menghubungkan perangkat lunak dengan elemen perangkat keras, perangkat lunak, atau basis data.
Kebutuhan Antarmuka Ekstrernal : Kebutuhan pemakai akan dikembangkan dengan menggunakan user interface dengan berbasis web. Pemakai berinteraksi dengan perangkat lunak SismonKP melalui userinterface pada web browser. Selanjutnya sistem akan menerima masukan dari pengguna melalui tulisan yang diketikkan melalui keyboard dan perintah yang diklik melalui mouse. Keluaran dari sistem dapat dilihat pemakai dengan menggunakan monitor secara langsung di web browser.
Kebutuhan Antarmuka Pemakai : Perangkat lunak yang akan dikembangkan membutuhkan interaksi dengan user sebagai pemakai aplikasi perangkat lunak. Dalam melakukan interaksi dengan pemakai perangkat lunak ini membutuhkan perangkat untuk melakukan proses transformasi input dan output dari dan ke pemakai. Perangkat tersebut adalah sebagai berikut: Perangkat Keyboard Keyboard diperlukan sebagai sarana bagi pemakai
untuk mengetikkan data masukan yang akan diproses perangkat lunak. Perangkat Mouse Mouse digunakan sebagai sarana bagi pemakai untuk memasukkan data input bagi perangkat lunak. Meskipun sebagian besar fungsi mouse dapat digantikan dengan perangkat keyboard tetapi akan lebih ergonomis apabila pada jenis input tertentu digunakan mouse sebagai salah satu perangkat yang dibutuhkan sebagai antarnuka dengan pemakai. Layar Monitor Layar sebagai sarana untuk menampilkan aplikasi kepada pemakai mempunyai spesifikasi diantaranya : monitor mampu menampilkan grafis dengan kualitas warna yang baik untuk menampilkan user interface dan keluaran sistem
2.3 Kebutuhan unjuk kerja : kebutuhan yang menetapkan karakteristik unjuk kerja yang harus dimiliki oleh perangkat lunak. contoh : perangkat lunak harus bisa mengolah data sampai 1juta record untuk tiap transaksi 3. Diagram Aliran Data/Data Flow Diagram : Diagram untuk menggambarkan aliaran data dalam sistem, sumber dan tujuan data, proses yang mengolah data tersebut dan tempat penyimpanan data. 4. Aturan Pembuatan Diagram Aliran Data: 1. Setiap proses wajib memiliki data masukan dan data keluaran, selain itu TERLARANG. 2. Nama proses wajib menggunakan kata kerja 3. Data store tidak boleh mengalir langsung dari/ke data store lain, harus melalui proses dulu. 4. Data store tidak boleh mengalir langsung ke tujuan data/entitas, harus melalui proses dulu (idem dengan yang diatas) 5. Nama data store harus menggunakan kata benda
6. Entitas tidak boleh mengalir dari sumber data ke tujuan data, harus melalui proses (serba lewat proses deh pokoknya) 7. Nama entitas harus menggunakan kata benda 8. Aliran data hanya boleh memiliki satu arah aliran, aliran dua arah hanya boleh dimiliki antara proses dengan data store yang menunjukkan pembacaan dan pengupdate-an data. 9. Aliran data yang sama yang menuju beberapa proses, data store atau entitas data yang berbeda, boleh digambarkan bercabang 10. Aliran data yang sama yang dari beberapa proses, data store atau entitass data yang menuju satu proses tertentu boleh digambarkan bercabang. 11. Aliran data tidak boleh mengalir ke dirinya sendiri 12. Nama aliran data menggunakan kata benda. 5. Kamus data : merupakan suatu tempat penyimpanan (gudang) dari data dan informasi yang dibutuhkan oleh suatu sistem informasi. kamus data digunakan untuk mendeskripsikan rincian aliran data atau informasi yang mengalir dalam sistem, elemen data, file maupun basis data dalam DFD. 6. Spesifikasi Proses : merupakan metode yang digunakan untuk menggambarkan deskripsi dan spesifikasi dari setiap proses yang paling rendah yang ada pada sistem. B. Kajian Spesifikasi Perangkat Lunak 1. Spesifikasi Perangkat Lunak
Tujuan: menetapkan layanan apa yang dituntut dari system dan batasan pada operasi dan pengembangan sistem. Kegiatan ini sering disebut juga rekayasa persyaratan. Tahap ini merupakan tahap yang sangat kritis dari proses perangkat lunak karena kesalahan pada tahap ini pada akhirnya akan menimbulkan masalah lain pada perancangan dan implementasi sistem. Proses rekayasa persyaratan menghasilkan dokumen persyaratan yang merupakan spesifikasi sistem. Persyaratan biasanya direpresentasikan pada dua tingkat perincian di dokumen ini. Pengguna akhir (end user) dan pelanggan
memerlukan pernyataan persyaratan tingkatan tinggi, sedangkan pengembang sistem memerlukan sistem yang lebih rinci. Ada empat fase utama pada proses rekayasa persyaratan: 1. Studi kelayakan. Dibuat perkiraan apakah user yang diidentifikasi puas menggunakan perangkat lunak dan teknologi perangkat keras yang dipakai pada saat ini. Studi ini akan memutuskan apakah sistem yang diusulkan efektif dalam hal biaya dari sudut pandang bisnis dan apakah sistem dapat dikembangkan dengan keterbatasan anggaran yang tersedia. Hasil dari studi kelayakan ini adalah informasi keputusan apakah kita akan terus dengan analisis yang lebih rinci atau tidak. 2. Elisitasi dan analisis persyaratan. Ini merupakan proses penurunan persyaratan sistem melalui observasi sistem yang ada, diskusi dengan user yang akan memakai dan yang mengadakan, analisis pekerjaan, dll. Proses ini bisa melibatkan pengembangan satu atau lebih model dan prototipe sistem. Hasil fase ini akan membantu analis memahami sistem yang akan dispesifikasi. 3. Spesifikasi persyaratan. Adalah kegiatan menerjemahkan informasi yang dikumpulkan pada kegiatan analisis menjadi dokumen yang mendefinisikan serangkaian persyaratan. Dua jenis persyaratan bisa dicakup pada dokumen ini. Persyaratan user merupakan pernyataan abstrak persyaratan sistem untuk pelanggan dan end user sistem; persyaratan sistem merupakan deskripsi yang lebih rinci mengenai fungsionalitas yang akan diberikan. 4. Validasi persyaratan. Kegiatan ini memeriksa apakah persyaratan dapat direalisasikan, konsisten, dan lengkap. Pada proses ini kesalahan pada dokumen persyaratan pada akhirnya akan ditemukan. Kesalahan ini kemudian dimodifikasi untuk menyelesaikan masalahnya. 2. Pemrograman dan Debug Pengembangan program untuk implementasi sistem tentu saja merupakan lanjutan dari proses perancangan sistem. CASE tool dapat dipakai untuk membangkitkan program kerangka dari rancangan. Program ini mencakup kode untuk mendefinisikan dan mengimplementasikan interface dan pada banyak
kasus, pengembang hanya perlu menambahkan rincian operasi pada setiap komponen program. Biasanya, programmer akan melakukan pengujian terhadap kode yang telah dikembangkan. Kegiatan ini menunjukka error program yang harus dihilangkan. Kegiatan ini disebut debugging. Pengujian error dan debug merupakan proses yang berbeda. Pengujian menentukan adanya error. Debug berhubungan dengan pencarian lokasi dan pembetulan error ini. Error pada kode harus dilokalisasi dan program dimodifikasi untuk memenuhi persyaratan. Pengujian kemudian dilakukan untuk menjamin bahwa perubahan telah dilakukan dengan benar. Dengan demikian proses debug merupakan bagian dari pengembangan perangkat lunak dan pengujian perangkat lunak. Proses debug: -
Cari lokasi error
-
Rencang perbaikan error
-
Perbaiki error
-
Uji ulang program 2.1 Validasi Perangkat Lunak Validasi perangkat lunak, atau lebih umum, verifikasi dan validasi (V&V) ditujukan untuk menunjukkan bahwa sistem sesuai dengan spesifikasinya dan bahwa sistem memenuhi harapan pelanggan. Validasi melibatkan proses pemeriksaan, seperti inspeksi dan peninjauan, pada setiap tahap proses perangkat lunak dari definisi persyaratan user sampai pengembangan program. Namun demikian mayoritas biaya validasi disediakan setelah implementasi dan sistem operasional diuji. Tahap-tahap pengujian: 1. Pengujian unit. Komponen individual diuji untuk menjamin operasi yang benar. Setiap komponen diuji secara independen.
2. Pengujian modul. Modul merupakan sekumpulan komponen yang berhubungan seperti kelas, objek, tipe data abstrak, atau sekumpulan prosedur. Sebuah modul dapat diuji tanpa modul sistem yang lain. 3. Pengujian sub sistem. Fase ini melibatkan pengujian sekumpulan modul yang telah diintegrasikan menjadi subsistem. 4. Pengujian sistem. Penemuan kesalahan yang diakibatkan dari interaksi yang tidak diharapkan antara sub sistem dan masalah interface sub sistem. Proses ini juga berhubungan dengan validasi bahwa sistem telah memenuhi persyaratan fungsional dan non fungsionalnya. 5. Pengujian penerimaan. Sistem diuji dengan data yang dipasok oleh pelanggan sistem dan bukan data uii simulasi.
2.2 Evolusi Perangkat Lunak Pengembangan perangkat lunak dianggap merupakan kegiatan kreatif dimana sistem perangkat lunak dikembangkan dari konsep awal menjadi sistem yang dapat berjalan. Pemeliharaan perangkat lunak merupakan proses perubahan sistem tersebut setelah digunakan. Rekayasa perangkat lunak dianggap sebagai proses evolusioner dimana perangkat lunak terus diubah selama waktu hidupnya sebagai jawaban atas perubahan lingkungan dan kebutuhan pelanggan. 2.3 Pendukung Proses Terotomatisasi Computer-Aided Software Engineering (CASE) adalah perangkat lunak yang dipakai untuk mendukung kegiatan proses rekayasa perangkat lunak reperti rekayasa persyaratan, perancangan, pengembangan program, dan pegujian. Dengan demikian CASE tool mencakup edior perancangan, kamus data, compiler, debugger, alat bantu pembuatan sistem, dll. Teknologi CASE menyediakan dukungan proses perangkat lunak yang mengotomasi beberapa kegiatan dan menyediakan informasi mengenai perangkat lunak yang sedang dikembangkan. Contoh kegiatan yang dapat diotomasi dengan menggunakan CASE mencakup: 1. Pengembangan model sistem grafis sebagai bagian spesifikasi persyaratan atau perancangan perangkat lunak;
2. Pemahaman rancangan menggunakan kamus data yang menyimpan informasi mengenai entitas dan hubungan pada rancangan; 3. Pembuatan interface user dari deskripsi interface grafis yang dibuat secara interaktif dengan user; 4. Debug program dengan menyediakan informasi mengenai program yang sedang berjalan; 5. Penerjemahan program yang terotomasi dari bahasa pemrograman versi lama seperti COBOL, menjadi versi yang lebih baru. Teknologi CASE telah menghasilkan beberapa perbaikan kualitas dan produktivitas perangkat lunak walaupun kuantitasnya masih kurang dari yang diharapkan oleh pendukung CASE. Menurut Huff (1992) perbaikan yang dicapai adalah sebesar 40 persen. Walaupun angka ini signifikan, CASE tidak melakukan revolusi terhadap rekayasa perangkat lunak sebagaimana yang diramalkan. Perbaikan dari penggunaan CASE dibatasi oleh dua faktor: 1. Rekayasa perangkat lunak pada intinya adalah kegiatan perancangan yang berdasarkan pada pemikiran kreatif. Sistem CASE yang ada mengotomasi kegiatan rutin, tetapi usaha untuk menggunakan teknologi intelejensia buatan yang memberikan dukungan bagi perancangan belum berhasil. 2. Pada sebagian besar organisasi, rekayasa perangkat lunak merupakan kegiatan tim dan perekayasa perangkat lunak menghabiskan waktu cukup banyak untuk berinteraksi dengan anggota tim yang lain. Teknologi CASE tidak banyak memberikan dukungan untuk ini.
Klasifikasi CASE Tools Ada berbagai klasifikasi CASE tool, masing-masing
memberikan pandangan yang berbeda. CASE tool dapat dibagi dalam tiga sudut pandang, yaitu:
1. Sudut pandang fungsional, dimana CASE tool diklasifikasikan menurut fungsi khususnya. 2. Sudut pandang proses, dimana CASE tool diklasifikasikan menurut kegiatan proses yang didukungnya. 3. Sudut pandang integrasi, dimana CASE tool diklasifikasikan menurut bagaimana mereka diorganisasikan ke dalam unit-unit yang terintegrasi, yang memberikan dukungan bagi satu kegiatan proses atau lebih. Berikut adalah klasifikasi CASE tool berdasarkan fungsinya: Jenis alat bantu Tool
Contoh Tool PERT, tool estimasi, spreadsheet
perencanaan Tool
Editor teks, editor diagram, word processor
pengeditan Tool
Tool penelusuran persyaratan, sistem kontrol perubahan
manajemen perubahan Tool
Sistem manajemen versi, tool pembuatan sistem
manajemen konfigurasi Tool
Bahasa tingkat sangat tinggi, pembuat interface user
pembuatan prototipe Tool
Editor perancangan, kamus data, generator kode
penunjang metode Tool pemrosesan
Compiler, interpreter
bahasa Tool analisis
Generator referensi silang, analisator statis, analisator
program
dinamis
Tool pengujian
Generator pengujian data, komparator file
Tool debug
Sistem debug interaktif
Tool
Program layout page, editor citra
dokumentasi Tool rekayasa
Sistem referensi silang, sistem restrukturisasi program
ulang
Fugetta (1993) mengusulkan klasifikasi sistem CASE dalam tiga kategori: 1. Tool (alat bantu) mendukung pekerjaan proses individual seperti memeriksa konsistensi perancangan, kompilasi program, membandingkan hasil pengujian, dll. Tool bisa berupa bersifat umum (general purpose), stand alone (berdiri sendiri), misalnya pengolah kata. 2. Workbench mendukung fase atau kegiatan proses seperti spesifikasi, perancangan, dsb. Workbench biasanya terdiri dari serangkaian tool dengan derajat integrasi yang lebih besar atau lebih kecil. 3. Lingkungan mendukung semua atau paling tidak bagian penting dari proses perangkat lunak. Lingkungan biasanya mencakup beberapa workbench yang terintegrasi dengan suatu cara. Pada prakteknya, batas antara kelas-kelas ini kabur. Tool bisa jadi dijual sebagai satu produk tetapi bisa mencakup dukungan untuk berbagai kegiatan. Sebagai contoh: -
Sebagian pengolah kata sekarang menyediakan editor diagram yang sudah menjadi satu.
-
Workbench CASE untuk perancangan terus menambah dukungan untuk pemrograman dan pengujian sehingga lebih dekat dengan lingkungan dari workbench khusus.
