Prosiding Seminar Nasional Manajemen Teknologi XVI Program Studi MMT-ITS, Surabaya 14 Juli 2012

Transkripsi

1 REKAYASA KEBUTUHAN UNTUK PERBAIKAN SISTEM DISASTER RECOVERY PLAN DENGAN PENDEKATAN METODOLOGI SECURITY QUALITY REQUIREMENTS ENGINEERING (SQUARE) (Studi Kasus : Data Enterprise Resource Planning Pada PT. CSA) Nauval Munif dan Daniel O.Siahaan Program Studi Magister Manajemen Teknologi Institut Teknologi Speuluh Nopember nauvalmunif@gmail.com ABSTRAK Aplikasi ERP memiliki sebuah sub-sistem yaitu Disaster Recovery Plan (DRP) yang merupakan sistem kritis dalam pencapaian tingkat keamanan data dan pengembalian data pasca bencana. Semakin berkembangnya bisnis dari perusahaan, membuat sistem DRP yang ada tidak dapat memenuhi kebutuhan dari stakeholder. Hal ini terbukti bahwa adanya laporan keterlambatan dan waktu yang terlalu lama dalam proses backup serta pengembalian data pasca bencana yang sudah tidak sesuai dengan yang diharapkan oleh para stakeholder. Untuk menangani permasalahan yang ada perlu adanya perbaikan guna meningkatkan kualitas dari sistem DRP yang melekat pada aplikasi ERP ini. Dalam proses perbaikan, peneliti melakukan analisis rekayasa kebutuhan yang merupakan fase awal dari siklus hidup pengembangan perangkat lunak. Proses rekayasa kebutuhan dilakukan dengan pendekatan metodologi Security Quality Requirement Engineering (SQUARE) yang dikembangkan Nancy Mead bersama team. Proses pada SQUARE menyediakan arti penting untuk elisitasi, pengkategorian, dan prioritas kebutuhan keamanan terhadap sistem dan aplikasi teknologi informasi. Hasil dari analisis rekayasa kebutuhan ini adalah sebuah dokumen Spesifikasi Kebutuhan Perangkat Lunak (SKPL) yang mengacu pada IEEE Std dengan menggunakan pendekatan metodologi SQUARE. Dokumen ini akan diberikan kepada team pengembang untuk dirancang sebuah perbaikan dari sistem, sehingga nantinya sistem yang dibangun dapat memberikan jawaban atas kebutuhan stakeholder di perusahaan. Kata kunci: Rekayasa Kebutuhan, Metodologi Security Quality Recuirement Engineering (SQUARE), Disaster Recovery Plan (DRP), Standar IEEE std PENDAHULUAN Pentingnya database pada sebuah sistem ERP, sehingga menjadikan sistem Disaster Recovery Plan (DRP) merupakan bagian dari sub-sistem ERP sebagai sistem keamanan dalam penyelamatan dan pengembalian data dari kehilangan atau kerusakan pasca bencana. Sistem DRP yang berjalan saat ini di PT. CSA menggunakan prosedur backup yang dilakukan secara manual setiap harinya di setiap cabang perusahaan dengan kondisi berhentinya sementara aktifitas operasional bisnis. Namun, setelah dilakukan monitoring di beberapa cabang diperoleh laporan backup seperti pada tabel 1 yang merupakan log dari monitoring backup C-13-1

2 Tabel 1 Monitoring Backup No. Waktu Monitoring Cabang Modified Backup Rata Transaksi Time Penjualan/jam 1 19/11/11 08:35 Bali 17/11/11 17:35 8 record 2 19/11/11 08:38 Malang 15/11/11 17:38 5 record 3 19/11/11 08:40 Kediri 15/11/11 17:40 7 record 4 19/11/11 09:35 Samarinda 16/11/11 17:35 6 record 5 19/12/11 08:35 Surabaya 18/11/11 17:35 12 record Pada tabel 1 terlihat waktu backup memiliki selisih waktu yang jauh dari waktu monitoring yang hal ini berdampak besar terhadap resiko kehilangan data. Saat dilakukan observasi dilapangan, sebagian tanggapan dari stakeholder terhadap sistem ini adalah : Backup saat ini tidak bisa berjalan secara real-time sehingga harus menghentikan operasional bisnis untuk memulainya. Jika data rusak sebelum di-backup dalam sehari, apa kita bisa mendapatkannya kembali setidaknya 2 jam sebelumnya? kita tidak mungkin melakukan backup setiap 2 jam sekali, hal ini memakan waktu operasional. Sistem tidak dapat memberikan kita alerting waktu backup, jadi saat akan dibackup harus menginformasikan para user satu persatu untuk keluar dari sistem. Dari laporan monitoring dan beberapa tanggapan stakeholder diatas, sistem DRP yang ada belum dapat memenuhi kebutuhan pengguna sehingga perlu adanya perbaikan terhadap sistem tersebut. Dalam perbaikan sistem ini, pengguna akan dilibatkan pada proses rekayasa kebutuhan untuk penghasilkan produk yang sesuai dengan kebutuhan mereka. Karena DRP merupakan bagian dari keamanan sistem untuk kebutuhan non-fungsional yang relevan terhadap sistem kritis (Kotonya & Sommerville, 1998), maka dalam penelitan ini akan digunakan pendekatan metodologi SQUARE. Hasil dari proses rekayasa kebutuhan akan dirangkum dalam sebuah dokumen SKPL yang berdasar pada IEEE std dan nantinya akan digunakan oleh devisi team development untuk memperbaiki sistem DRP yang ada. METODE Metode yang digunakan dalam penelitian ini menggunakan pendekatan metodologi SQUARE yang dikembangkan Nancy Mead bersama team. Proses pada SQUARE menyediakan arti penting untuk elisitasi, pengkategorian, dan prioritas kebutuhan keamanan terhadap sistem dan aplikasi teknologi informasi (Mead et al., 2005). Pada penelitian ini, setelah melalui 9 tahap SQUARE dilanjutkan dengan perancangan dokumen Spesifikasi Kebutuhan Perangkat Lunak (SKPL) yang menggunakan standarisasi IEEE std Gambar 1. Metode Penelitian C-13-2

3 Tahap 1 SQUARE : Persetujuan Definisi Tahap ini merupakan proses menyatukan pemahaman tentang definisi DRP. Dasar definisi DRP dapat mengacu pada Institute for Electrical and Electronic Engineers (IEEE) atau pada standarisasi internasionl lainnya sebagai standar definisi. Pemahaman dari stakeholder yang ambigu mengenai DRP dan bagian-bagiannya diselaraskan hingga menghasilkan sebuah persetujuan tentang definisi DRP. Tahap 2 SQUARE : Identifikasi Goal Pada langkah ini dilakukan penggalian informasi mengenai kebijakan korporasi, kendali bisnis dari sistem DRP, dan lingkungan operasional dari DRP sehingga nantinya menghasilkan sebuah goal pada sistem DRP ini. Goal DRP ini akan menggunakan pendekatan dari standar NIST SP sebagai standar keamanan DRP untuk data ERP. Tahap 3 SQUARE : Pengembangan Artefak Tahap ini diperlukan apa saja artefak yang mendukung terkait dalam proses perbaikan sistem DRP ini. Artefak akan diperoleh dari kondisi yang ada pada sistem saat ini diantaranya : arsitektur sistem terdapat pada perusahaan akan dikembangkan sebagai perbaikan sistem dan Use case yang merupakan skenario dari sistem yang ada, kemudian dikembangkan sebagai perbaikan sistem. Tahap 4 SQUARE : Penilaian Resiko Pendekatan yang digunakan dalam tahap penilaian resiko ini berdasar pada metodologi SQUARE yaitu menggunakan pendekatan NIST SP yang telah dirangkum dan disesuaikan berdasar pada metodologi tersebut. Hal terpenting dalam penilaian resiko ini adalah menyediakan cara yang bermakna dalam mengkategorikan Likelihood (kemungkinan - kemungkinan yang terjadi) dan dampak dari ancaman utama dari sistem DRP ini. Tahap 5 SQUARE : Pemilihan Teknik Elisitasi Tahap ini akan dipilih satu atau lebih teknik elisitasi yang sesuai dengan perbaikan sistem. SQUARE memberikan contoh macam-macam teknik elisitasi, Namun proses pemilihan teknik juga disesuaikan terhadap lingkungan perusahaan dan juga dari jenis sistem yang akan dibangun. Sehingga tidak menutup kemungkinan menggunakan teknik elisitasi lain diluar dari contoh teknik yang telah diberikan. Tahap 6 SQUARE : Elisitasi Kebutuhan Tahap Proses elisitasi pada penilitian ini menggunakan teknik yang telah dihasilkan melalui proses pemilihan yang dilakukan pada tahap sebelumnya. Elisitasi kebutuhan akan menyertakan hasil penilaian resiko dan artefak yang dikembangkan, sehingga nantinya stakeholder dapat mengetahui kebutuhan yang sebenarnya dari keamanan data mereka terkait dengan rencana perbaikan sistem ini. Tahap 7 SQUARE : Pengkategorian Kebutuhan Tahap ini mengkategorikan semua kebutuhan sistem DRP dari stakeholder yang dihasilkan melalui proses elisitasi. Hasil elisitasi akan dikategorikan berdasarkan kebutuhan sistem dan kebutuhan pengguna. C-13-3

4 Tahap 8 SQUARE : Memprioritaskan Kebutuhan Tahap ini dilakukan langkah dalam memprioritaskan kebutuhan dari sistem. Pada langkah ini digunakan pendekatan metode Analytic Hierarcy Process (AHP) dalam memprioritaskan kebutuhan dari stakholder dengan membandingkan diantara masing-masing kebutuhan tersebut. Tahap 9 SQUARE : Elisitasi Kebutuhan Tahap ini merupakan langkah terakhir dari metodologi SQUARE dimana semua kebutuhan untuk DRP akan diperiksa apakah sesuai dengan kebutuhan dari stakeholder. Cheklist kebutuhan DRP akan disusun dan diberikan pada stakeholder untuk diverifikasi. Jika masih terdapat kebutuhan DRP yang tidak sesuai maka akan dilakukan perbaikan terhadap cheklist tersebut. Perancangan Dokumen SKPL Tahap ini merupakan tahap pembentukan dokumen Spesifikasi Kebutuhan Perangkat Lunak (SKPL) untuk sistem DRP. Dokumen SKPL. Hasil dari metodologi SQUARE pada tahap sebelumnya akan menjadi bahan dalam pembentukan dokumen ini yang diselaraskan berdasarkan standarisasi IEEE std HASIL DAN PEMBAHASAN Pembahasan penelitian yaitu melakukan proses rekayasa kebutuhan yang terkait dengan perbaikan sistem berdasarkan metodologi dari SQUARE, kemudian merancang dokumen SKPL berdasarkan standarisasi IEEE std Hasil yang didapatkan adalah sebuah dokumen SKPL berdasar pendekatan metodologi SQUARE. Persetujuan Definisi Tahap persetujuan definisi meliputi 2 proses yaitu melakukan indentifikasi terhadap stakeholder dan penyusunan dokumen persetujuan definisi. Stakeholder diidentifikasi dan dikelompokkan berdasarkan pada kepentingannya terhadap sistem. Stakeholder dibentuk berdasarkan pada struktur organisasi perusahaan dimana mereka memiliki fungsi dan jabatan yang berkaitan dengan sistem yang akan dibangun. Standar Definisi menjadi pedoman dari istilah-istilah yang ada pada dokumen, kemudian stakeholder akan menandatangani isi dokumen setelah mereka memahami istilahistilah yang disebutkan. Jika terdapat stakeholder yang memilki definisi yang berbeda pada definisi yang tertulis, maka dilakukan negosiasi untuk memberikan pemahaman yang selaras dengan standar definisi. Hasil dari tahap ini merupakan sebuah dokumen persetujuan definisi yang mendapat approval. Identifikasi Goal Kebijakan korporasi dan pengendalian bisnis beserta lingkungan operasional perusahaan merupakan dasar dalam tercapainya identifikasi goal dari perancangan sistem DRP untuk database ERP ini. Penggunaan standar NIST SP juga diperlukan sebagai acuan standar keamanan. Sehingga, rangkuman identifikasi goal mengahasil seperti yang tertera pada tabel 2. C-13-4

5 Tabel 2. Hasil Identifikasi Goal Bisnis Goal Sistem yang dirancang diharapkan mampu mengendalikan bisnis operasional perusahaan dari resiko kehilangan dan kerusakan data seminimal mungkin Goal Keamanan G1. Data backup ditempatkan pada Offsite-system G2. Memanfaatkan pihak ke-3 sebagai pertimbangan standarisasi perangkat dan ketersedianya kebutuhan perangkat G3. Pendokumentasian seluaruh konfigurasi sistem secara jelas G4. Pengkoordinasian kebijakan dan pengendalian keamanan jaringan harus dapat memberikan dukungan dari rancangan sistem G5. Analisa resiko dan dampak keamanan sistem mampu melindungi data dari kerusakan dan kehilangan Pengembangan Artefak Pengembangan artefak didapatkan dari bagian-bagian sistem yang masih dapat digunakan untuk perbaikan sistem yang mencakup arsitektur sistem, dan use case. Arsitektur sistem seperti pada gambar 2. Penilaian Resiko Gambar 2 Arsitektur Sistem Analisa resiko dalam perbaikan sistem ini terdiri dari beberapa langkah yang mengacu pada standar NIST. Langkah langkah penilaian ini digunakan untuk mempertimbangkan suatu resiko keamanan data terhadap sistem nantinya. Langkah-langkah penilaian resiko diantaranya : identifikasi ancaman, identifikasi kerentanan, analisis pengendalian, penentuan likelihood, analisis dampak, dan penentuan resiko. Hasil yang didapatkan dari proses penilaian resiko seperti pada tabel 3. C-13-5

6 Level Resiko High Medium Low Tabel 3. Penilain Resiko Hasil Risk Level Matriks Prosedur backup yang dilakukan 2xsehari belum memberikan keamanan bagi pemilik sistem - Kerusakan multiple hardisk server - Gangguan koneksi internet ( WAN dan VPN) - Kerusakan perangkat lunak dari database - Kerusakan mesin server - Kerusakan Sistem Operasi - Gangguan LAN - Kehilangan record data ERP - Kerusakan hardisk tunggal server - Kerusakan sumber daya listrik - Kualitas yang kurang baik pada UPS - Ketidakstabilan tegangan listrik dari pihak ke-3 - Kelemahan pada sistem operasi sehingga virus mudah masuk - Banjir yang menggenangi ruangan server - Alih kendali database oleh pengguna yang tidak memiliki hak akses - Kebakaran ruang server Pemilihan Teknik Elisitasi Proses pemilihan teknik elisitasi yaitu melihat dari lingkungan perusahaan, ranah masalah, dan teknik-teknik elisitasi yang didapatkan dari studi literatur sebagai bahan pertimbangan untuk mendapatkan teknik elisitasi yang sesuai. Pertimbangan yang menjadi acuan pemilihan elisitasi yaitu : kemudahan, kecepatan, kesesuaian, dan kelengkapan dalam menggali kebutuhan. Sedangkan teknik elisitasi yang memungkinkan yaitu : interview tak berstruktur, quisioner, JAD, dan Goal oriented. Hasil dari pemilihan elisitasi yang terpilih adalah interview tak berstruktur dan goal oriented. Elisitasi Kebutuhan Pada proses elisitasi yaitu terdiri dari pemaparan hasil penilaian resiko dan pengembangan artefak, proses elisitasi berdasar teknik interview, proses elisitasi berdasar teknik goal oriented dan yang terakhir adalah perumusan hasil elisitasi yang menghasilkan inti kebutuhan sebagai berikut : 1. Data backup ERP diletakkan pada offsite-system 2. Pengadaan perangkat keras, perangkat lunak, dan alat pendukungnya distandarisasikan sesuai dengan kebutuhan DRP dengan memanfaatkan pihak ke-3 sebagai rekanan dalam pengadaanya. 3. Sistem keamanan jaringan dikoordinasikan pada devisi Infrastruktur supaya sistem DRP nantinya berjalan secara aman dan terkendali. 4. Analisis dampak dari keamanan sistem DRP harus memilki resiko sekecil mungkin 5. Penggunaan teknik metode backup memanfaatkan teknik yang telah disediakan DBMS 6. Teknik storage pada hardisk server menggunakan RAID10 7. Penyedian cadangan listrik menggunakan UPS bersistem ON Line 8. IT Operation dapat mengontrol data hasil backup 9. Sistem dapat memberikan alerting informasi backup pada pengguna Pengkategorian Kebutuhan Seluruh hasil elisitasi dikategorikan berdasarkan kebutuhan sistem dan kebutuhan pengguna. Kebutuhan sistem adalah kebutuhan yang berdasar pada persyaratan sistem sebagai C-13-6

7 penunjang agar sistem DRP nantinya dapat berjalan. Sedangkan kebutuhan pengguna adalah kebutuhan antarmuka yang berhubungan langsung dengan pengguna untuk mengendalikan bagaimana sistem tersebut berjalan. Hasil dari pengkategorian kebutuhan yaitu : kebutuhan 1, 2, 3, 4, 5, 6, 7 adalah kebutuhan sistem sedangkan 5, 8, 9 adalah kebutuhan pengguna. Prioritas Kebutuhan Prioritas kebutuhan adalah menentukan skala prioritas dari setiap kebutuhan hasil elisitasi. Proses ini menggunakan metode statistikal untuk membandingkan antara kebutuhan yang satu dengan yang lain yaitu degan menggunakan AHP. Hasil dari langkah ini merupakan kebutuhan yang terprioritaskan seperti gambar 5. 0,18 Pengelompokkan Skala Prioritas Kebutuhan 0,16 0,14 Prioritas 0,12 0,10 0,08 0, Skala 3 Inspeksi Kebutuhan Gambar 5 Prioritas Kebutuhan Inspeksi kebutuhan merupakan langkah terakhir dalam melakukan proses rekayasa kebutuhan yang menggunakan pendekatan petodologi SQUARE. Didalam proses inspeksi kebutuhan, hal terpenting adalah bagaimana hasil elisitasi kebutuhan sistem DRP yang telah terprioritaskan ini diperiksa kesesuaiannya terhadap kebutuhan stakeholder. Inspeksi kebutuhan dilakukan secara informal menggunakan metode scenario-based inspections sehingga dihasilkan ceklist seperti pada tabel 4 Skenario-based Inspections Tabel 4 Ceklist Kebutuhan Kebutuhan hasil elisitasi Ceklist kesesuaian 1. CAF mengakses menu maintenance-sistem backup/restore K5 2. CAF mengatur jadwal DRP-backup differential K5 3. CAF mengatur letak penyimpanan data backup pada drive local K4,K5,K6 4. Sistem dapat melakukan cek konsistensi data hasil backup pada drive local K6 5. Sistem dapat memberikan informasi alerting saat waktu backup full K5 6. CAF mengatur jadwal transfering data backup full+differential ke server corporate K1 7. Sistem memberikan informasi bahwa proses backup differential dan full sudah selesai K9 8. IT Operation melakukan login ke server pusat K8 9. IT Operation dapat mengontrol cabang mana saja dan operator yang telah melakukan transfering data K8 10. IT Operation dapat melakukan cek konsistensi data hasil transfer dari server local user K8 11. IT Operation dapat melakukan proses restore data dari server corporate ke server tujuan berdasar hasil transfer yang terakhir K8 C-13-7

8 Perancangan Dokumen SKPL Perancangan dokumen Spesifikasi Kebutuhan Perangkat Lunak (SKPL) pada bab ini merupakan langkah proses bagaimana menyusun sebuah dokumen SKPL dengan memadukan hasil dari proses rekayasa kebutuhan yang telah dikerjakan sebelumnya kedalam format dokumen SKPL IEEE std KESIMPULAN 1. Pemodelan rekayasa kebutuhan dengan pendekatan SQUARE dapat menghasilkan dokumen SKPL sebagai petunjuk bagi para pengguna dan IT development guna mempermudah merancang perbaikan sistem nantinya 2. Dari hasil analisa rekayasa kebutuhan, perbaikan sistem yang melibatkan stakeholder sudah dapat memenuhi kebutuhan pengguna sehingga dapat digunakan sebagai acuan untuk merancang perbaikan sistem ini nantinya. DAFTAR PUSTAKA Kotonya, G. dan Sommerville, I, (1998), Requirement Engineering: Process and Technique, John Willey & Sons, Chichester, England. Mead, R. et al., (2005), Security Quality Requirements Engineering (SQUARE) Methodology, Carnigie Mellon University, Pittsburgh. NIST Special Publication (2002), Risk Management Guide for Information Technology Systems, Technology Administration U.S. Department of Commerce, Gaithersburg. NIST Special Publication (2002), Contingency Planning Guide for Information Technology Systems, Technology Administration U.S. Department of Commerce, Washington. IEEE std (1998), IEEE Recommended Practice for Software Requirements Specifications, The Institute of Electrical and Electronics Engineers, Inc., New York. C-13-8