Tugas Review Jurnal Irp

Oleh Dita Putri

373,2 KB 4 tayangan 0 unduhan
 


Bagikan artikel

Transkrip Tugas Review Jurnal Irp

TUGAS REVIEW JURNAL IRP KEAMANAN JARINGAN Nama Anggota Kelompok 1. 2. 3. 4. 5. 6. : Muhammad Jundi Hanif Hendri Rahman Wibawanto Golan Aldias Purwanti Dita Putri Damayanti Tika Putri Galuh NIM : 13.11.0114 13.11.0051 13.11.0206 13.11.0008 13.11.0042 13.11.0406 TI 13 SORE Dosen Pengajar : Andi Dwi Riyanto , M.Kom STMIK AMIKOM PURWOKERTO TEKNIK INFORMATIKA 2014/2015 REVIEW JURNAL TEKNIK KOLABORASI UNTUK INCIDENT RESPONSE PERENCANAAN: PROSES PENGEMBANGAN DAN VALIDASI ABSTRAK Banyak organisasi memiliki rencana untuk respon insiden strategi. Meskipun Incident Respnse Plan (IRP) menjadi unsur penting dalam prosedur keamanan dalam perencanaan organisasi, ulasan literatur yang luas telah mengungkapkan bahwa tidak ada proses kolaboratif di tempat untuk kegiatan penting seperti itu. Penelitian ini mengusulkan desain untuk proses rencana insiden response yang difasilitasi menggunakan teknologi seperti GSS. Ses dilakukan dan analisis sesi mengungkapkan bahwa proses desain IRP yang difasitasi mengangkat kuat dalam hal efisiensi,pencapaian tujuan dan kepuasan peserta sesi. Penelitian masa depan implikasi perlu merancang semua yang mencakup pendekatan umum integratif yang akan berlaku untukk segala bentuk proses perencanaan pembangunan keamanan. 1. Pendahuluan Saat ini, banyak organisasi telah menghubungkan sistem dan jaringan mereka ke dunia luar (e-bisnis). Hal ini membawa serta persyaratan khusus pada komputer dan keamanan informasi. Sebagian besar organisasi telah menderita akibat insiden keamanan seperti virus dan worm, pencurian informasi hak milik, penipuan keuangan, sistem penetrasi oleh pihak luar, sabotase data atau jaringan. Organisasi harus memiliki rencana penanganan insiden di tempat untuk dapat merespon secara efisien ketika insiden terjadi. IRP adalah Proses perencanaan yang berhubungan dengan identifikasi, klasifikasi, respon, dan pemulihan dari insiden. Meskipun organisasi berupaya untuk merespon keamanan risiko, literatur yang ada menunjukkan sangat sedikit panduan untuk melaksanakan IRP. Proses di tempat yang dapat membantu perencana keamanan dalam organisasi untuk merencanakan seperti peristiwa. Yang menarik adalah kenyataan bahwa IRP membutuhkan masukan dan kontribusi dari berbagai ahli organisasi. IRP tidak diciptakan oleh satu individual. Bagaimanapun, upaya kelompok ahli untuk menghasilkan IRP komprehensif dalam jangka waktu pendek bisa menjadi suatu tantangan. Pilihan untuk mengembangkan proses kolaboratif desain untuk IRP menggunakan pendekatan Teknik Kolaborasi (CE) bersandar pada sejumlah alasan: 1) CE berfokus pada tugas bernilai tinggi, sehingga organisasi akan memperoleh manfaat maksimum dari perbaikan tugas tertinggi nilai mereka (di kasus ini, IRP) dibandingkan dari perbaikan nilai tugas terendah. 2) CE berusaha untuk membawa nilai intervensi difasilitasi untuk orang-orang yang tidak memiliki akses fasilitasi melalui penciptaan proses berulang 3) Merancang proses berulang (dalam hal ini Proses IRP berulang) memiliki kemungkinan untuk menciptakan modal intelektual untuk organisasi Kuncinya tujuan menciptakan "proses berulang" menurut Pendekatan CE adalah untuk sampai pada proses IRP kolaboratif yang dapat diterapkan di seluruh organisasi. Dengan kata lain, Proses ini dimaksudkan untuk menjadi 'praktek terbaik' untuk industri bukannya terikat konteks organisasi tertentu. 2. Latar Belakang Teknik kolaborasi telah didefinisikan sebagai "pendekatan untuk desain dan penyebaran teknologi kolaboratif dan proses kolaboratif untuk mendukung tugas-tugas mission-critical. Tujuan utama dari CE adalah untuk memungkinkan praktisi untuk bekerja dengan beban kognitif diminimalkan sementara memungkinkan mereka dengan keterampilan fasilitasi yang diperlukan dan pengetahuan tentang kelompok. Seorang insinyur kolaborasi kemudian bertanggung jawab untuk merancang proses dan menyerahkannya ke praktisi dalam sebuah organisasi . Ada enam langkah dalam pendekatan yang dilakukan dalam inkremental / berulang, non linear menurut Kolfschoten, GL, Vreede, GJ de, Chakrapani, A., and Koneri, P : 1) Tugas Diagnosis Langkah pertama melibatkan wawancara dengan pemilik masalah untuk mengidentifikasi masalah dan tujuan proses kolaborasi. Dalam penelitian kami, kami bertemu dengan ahli materi pelajaran IRP untuk menyelesaikan langkah ini. 2) Tugas Penilaian Selama langkah ini, proses untuk menyelesaikan tugas harus ditentukan. Dalam kasus kami tidak ada proses yang tersedia, ini adalah yang pertama dari jenisnya. Oleh karena itu, kami mulai dengan membuat daftar semua kiriman dan kegiatan yang diperlukan untuk mencapainya. 3) Kegiatan Dekomposisi Langkah ini mengacu pada enam pola kolaborasi, dekomposisi kegiatan dari langkah sebelumnya harus berhenti ketika setiap langkah tidak bisa diurai lebih lanjut dalam hal pola kolaborasi. 4) Tugas-ThinkLet Match Setelah kegiatan telah mencapai tingkat terendah dekomposisi mereka cocok dengan thinkLets. Sebuah thinkLet adalah unit terkecil dari intelektual modal yang dibutuhkan untuk membuat satu perulangan, diprediksi Pola kerjasama antara orangorang yang bekerja menuju Tujuan. 5) Desain Dokumentasi Dokumentasi desain dokumen yang akan diserahkan dari kolaborasi insinyur untuk praktisi organisasi. Dokumen termasuk masalah dan proses deskripsi, agenda rinci, dan model proses fasilitasi. Model proses fasilitasi visualisasi urutan thinkLets dan keputusan aliran proses yang telah dipertimbangkan selama pelaksanaan Proses kolaborasi. 6) Desain Validasi Akhirnya, ada empat cara untuk memvalidasi desain; uji coba, berjalan melalui, simulasi, atau meninjau. Dalam kasus kami, kami menggunakan kombinasi percontohan pengujian (3 kasus), penelusuran, dan ulasan. Masing-masing Kegiatan validasi membawa perbaikan dalam proses desain. Dalam mengembangkan proses desain IRP kolaborasi, langkah kunci yang terlibat dalam proses perencanaan harus dikonversi ke pola kolaborasi. Pola kolaborasi mencirikan cara di mana tim bergerak maju untuk mencapai (bagian dari) tugas joint. Menurut Briggs, RO, Kolfschoten, GL, Vreede, GJ de, Dean, DL, ada enam pola utama kolaborasi: 1. Menghasilkan Pindah dari memiliki konsep yang lebih sedikit untuk memiliki konsep lebih. 2. Mengurangi Pindah dari memiliki banyak konsep yang fokus pada beberapa konsep yang dianggap layak perhatian lebih lanjut. 3. Jelaskan Pindah dari memiliki konsep yang diungkapkan dalam waktu kurang detail untuk memiliki konsep yang diungkapkan secara lebih rinci. 4. Mengatur Pindah dari kurang pemahaman ke pemahaman lebih tentang hubungan antar konsep. 5. Evaluasi Pindah dari pemahaman yang kurang dari nilai konsep untuk mencapai tujuan untuk lebih memahami nilai konsep untuk mencapai suatu tujuan. 6. Membangun Konsensus Pindah dari memiliki perjanjian kurang antara para pemangku kepentingan untuk memiliki lebih banyak kesepakatan antara pemangku kepentingan. Pola-pola kolaborasi adalah blok bangunan dengan pendekatan CE yang akan digunakan dalam mengembangkan desain proses IRP. 3. Penelitian Pendekatan Untuk pengembangan dan pengujian proses kolaborasi kami, kami mengikuti pendekatan penelitian tindakan sebagai dasar untuk tiga kasus. Tindakan penelitian yang dipilih untuk proyek ini untuk sejumlah alasan. Pertama, memungkinkan kita untuk meminta pertanyaan 'bagaimana'. Salah satu tujuan kami sebagai peneliti adalah untuk merancang sesuatu yang akan meningkatkan praktik, khususnya memungkinkan praktisi untuk menjalankan proses ini sendiri. Untuk melakukan hal ini kami meminta pertanyaan 'bagaimana'. Penelitian tindakan juga memungkinkan kita untuk menguji sesuatu dengan mengaplikasikannya dalam kehidupan nyata. Apa yang kita coba untuk merancang dalam hal ini adalah terlalu rumit untuk menguji dalam pengaturan laboratorium. Tiga kasus dilakukan karena ini memungkinkan kita untuk merefleksikan desain proses dan memperbaikinya terus menerus. Kasus-kasus yang pernah dilakukan: - - Kasus 1 Lab Komputer Mahasiswa Incident Response dengan 17 mahasiswa yang terdaftar di tingkat sarjana kursus keamanan informasi. Kasus 2 Lab Komputer Mahasiswa Incident Response dengan sepuluh siswa yang terdaftar dalam tingkat pascasarjana kursus keamanan informasi. - Kasus 3 Karyawan Workstation Incident Response dengan kombinasi delapan profesional komputer dan fakultas sistem informasi di universitas. Untuk setiap pertemuan kasus memiliki dua tujuan. Tujuan utama untuk peserta pertemuan adalah untuk pengalaman bagaimana tim bersama-sama untuk membangun sebuah Rencana respon insiden. Tujuan sekunder untuk peserta rapat adalah untuk melihat bagaimana kolaborasi Teknologi (GSS) dapat digunakan untuk menyelesaikan tujuan utama. Tujuan dari lokakarya dari peneliti perspektif adalah untuk merancang dan mengevaluasi kolaboratif Proses IRP yang berulang, dapat diprediksi, dan dapat dilaksanakan oleh praktisi. Sifat dari peserta dalam hal latar belakang pengetahuan dan keahlian mereka berbeda antara tiga kasus. Dalam kasus pertama siswa yang terdaftar dalam kursus yang disebut "Keamanan dan Kebijakan Informasi." Dalam Kasus kedua siswa yang terdaftar dalam program yang disebut "Strategis Informasi Perencanaan Assurance." Dalam kasus terakhir peserta lokakarya termasuk kombinasi profesional keamanan dan akademisi di bidang keamanan. Dalam semua kasus, peserta lokakarya memiliki latar belakang minimal dengan teknologi yang didukung proses kolaborasi. Setiap lokakarya berlangsung sekitar satu satu setengah jam. Data penelitian dikumpulkan dari berbagai sumber untuk mengaktifkan pemahaman yang kaya dan perbandingan yang kontras. Sumber-sumber yang digunakan: 1. Observasi langsung Dalam setiap lokakarya, peneliti membuat catatan insiden kritis dan pertanyaan dari peserta yang berkaitan dengan proses lokakarya dan konten. (Misalnya, salah seorang peserta bertanya: "Dapatkah saya berdiskusi dengan orang di sebelah saya untuk kegiatan ini ") Pengamatan juga dilakukan dengan sejumlah aspek yang telah ditentukan misalnya 1, 2, 3. Aspek yang telah ditetapkan terdaftar di instrumen observasi. 2. Umpan balik Pada akhir setiap lokakarya, peserta diminta untuk menanggapi serangkaian petunjuknya di GSS. Peserta iminta untuk memberi komentar suka dan tidak suka tentang lokakarya pengalaman dan menawarkan saran dan komentar lain. 3. Kuesioner Setelah setiap lokakarya, para peserta diminta untuk mengisi kuesioner singkat yang berisi tentang informasi kepuasan pertemuan. 4. Data Log dari GSS atau sesi data Hasil setiap sesi kelompok disimpan secara elektronik. Ini terdiri dari semua kontribusi peserta di masing-masing tiga kasus dilakukan secara online ke GSS. Ini kontribusi wawasan yang disediakan ke dalam fokus dan kejelasan dari tugas yang diberikan oleh fasilitator untuk peserta dan kegunaan / kejelasan alat. 5. Wawancara Informal Wawancara diadakan dengan beberapa ahli subjek. Wawancara diadakan setelah setiap sesi untuk mendapatkan pemahaman yang lebih baik dari keberhasilan proses. Para peneliti berfungsi sebagai sebuah tim dengan tanggung jawab dalam semua aspek penelitian. Secara khusus,selama 'tindakan' fase kasus 3 (yaitu lokakarya dengan para peserta) tanggung jawab yang dibagi sebagai berikut: - - - - Presenter. Salah satu peneliti mempresentasikan tujuan, agenda,konteks, dan mulai pertimbangan kepada peserta. Disajikan pertanyaan juga ditangani tentang fokus dan proses. Akhirnya, presenter juga dipandu latihan pemanasan untuk berkenalan dengan GSS. Fasilitator. Salah satu peneliti memandu peserta selama kegiatan untuk melaksanakan proses IRP kolaboratif. Tanggung jawab termasuk, namun tidak dibatasi untuk: menjelaskan setiap kegiatan agenda, pemberian tugas,membimbing diskusi, dan mencatat waktu. Fasilitator melaksanakan proses melalui penggunaan thinkLets. Sopir. Dalam setiap lokakarya, salah satu peneliti mengoperasikan konsol master lingkungan GSS. GSS yang digunakan dalam penelitian adalah GroupSystems ™ Workgroup Edisi 3.4. Tanggung jawab sopir termasuk memulai dan menghentikan alat peserta pada layar mereka, bergerak atau memodifikasi kontribusi, dan membantu masalah teknis. Observer. Salah satu peneliti secara eksklusif berfokus pada melakukan pengamatan rinci menggunakan pengamatan instrumen yang dijelaskan di atas. Selain itu, setiap anggota tim peneliti menyimpan catatan pengamatan selama lokakarya. Setelah setiap lokakarya, semua peneliti menangkap pengamatan lebih lanjut yang datang ke pikiran, terinspirasi oleh instrumen observasi. Penting untuk dicatat bahwa peneliti tidak berpengalaman sebagai fasilitator yang membuat mereka lebih seperti "praktisi" IRP dan karenanya berfungsi sebagai wakil "subjek tes". Selain itu, salah satu anggota tim peneliti berfungsi sebagai subjek ahli materi yang akan menjawab pertanyaan peneliti tentang insiden dan rencana tanggap. Para peneliti tidak dibayar untuk layanan mereka dengan tim manapun yang berpartisipasi dalam penelitian. 4. Proses Desain Dalam mengembangkan desain proses fasilitasi IRP, langkah kunci yang terlibat dalam IRP perlu dikonversi ke pola kolaborasi dan akhirnya ke thinkLets tertentu akan dieksekusi selama sesi. Tabel 1 menguraikan langkah-langkah yang memungkinkan dengan IRP, pengiriman dari masing-masing kegiatan yang dilakukan, pola kerja sama untuk setiap langkah, dan thinkList terkait. TABEL 1: DESAIN PROSES AKHIR Langkah 1: Pada langkah ini, para peserta sesi diberikan definisi dari insiden (virus dan worm,Trojan horse, penolakan layanan, akar kit, spyware, & adware) dan ditanya apakah mereka setuju dengan definisi yang disajikan. Umpan balik mengenai definisi dipertimbangkan dan perubahan yang dibuat pada taksonomi sebelum pindah ke aktivitas berikutnya. Langkah 2: Langkah ini diterjemahkan ke dalam "menghasilkan" pola kolaborasi. The thinkLet terkait untuk kegiatan ini adalah yang wereng. ThinkLet ini biasanya diterapkan ketika tim harus melakukan brainstorming pada beberapa topik sekaligus dan juga ketika peserta yang berbeda akan memiliki tingkat yang berbeda kepentingan atau keahlian dalam topik yang berbeda. Langkah 3: Pada langkah ini, peserta ditugaskan untuk tim dari 2-3 orang untuk bekerja pada setiap kategori kejadian. Tim meninjau semua komentar yang masuk ke dalam kategori mereka dan berupaya untuk menghapus ide berlebih dan datang dengan kalimat terstrktur. Langkah 4: Langkah ini melibatkan siklus read-komentar. Dalam kegiatan ini, masingmasing sub-tim 2-3 orang diminta untuk membersihkan entri dalam kategori insiden lainnya dibanding mereka sendiri dan membuat komentar tentang masalah yang mereka rasa perlu ditangani. Kegiatan ini sekali lagi berlaku wereng thinkLet seperti yang dilakukan sebelumnya pada langkah 2. Langkah 5: Setelah peserta meninjau kategori lain, mereka diminta untuk kembali ke tugas kategori insiden mereka sendiri dan membaca apa yang anggota kelompok lain komentari. Kemudian mereka memasukkan umpan balik ke bagian mereka. Kegiatan ini memastikan bahwa setiap celah yang mungkin telah diabaikan oleh tim insiden yang ditugaskan bisa dibawa ke cahaya oleh peserta sesi lain. Langkah ini melibatkan BucketSummary thinkLet dijelaskan sebelumnya pada langkah 3. Langkah 6: Langkah ini sebenarnya melibatkan dua bagian. Yang pertama adalah untuk mengambil suara pada insiden untuk melihat apakah semua peserta sesi setuju dan kemudian melakukan diskusi dan modifikasi yang terkait dengan kategori yang ada yang menerima persentase yang tinggi dari ketidaksepakatan seperti diungkapkan oleh hasil voting. Kegiatan ini diterjemahkan untuk evaluasi dan pola pembangunan konsensus kolaborasi. thinkLet terkait untuk evaluasi adalah StrawPoll. thinkLet ini memungkinkan peserta untuk dapat merasakan posisi kelompok dengan memberikan suara dan meninjau hasil. Hal ini dilakukan terutama untuk memulai diskusi daripada mengakhirinya. Sebagai hasilnya, output dari StrawPoll adalah tampilan tabular dan grafis dari pol konsensus dalam kelompok. Model proses fasilitasi pada gambar 2 menggambarkan proses desain. Masing-masing kotak merupakan kegiatan yang dilakukan selama sesi dan menentukan sesuai thinkLet dan pola kolaborasi sepanjang bagian atas dan kiri sisi setiap kotak masing-masing. Pengirimaniriman yang keluar dari setiap kegiatan ditampilkan di samping panah yang mengarah dari satu kotak ke yang lain. GAMBAR 2. BAGAN PROSES FASILITASI IRP 4.1.Proses Desain Penyempitan Desain proses akhir ditunjukkan pada Tabel 1 adalah produk tiga iterasi perbaikan. Langkah 1 melibatkan mendapatkan konsensus mengenai pra insiden taksonomi dengan semua peserta sesi. Set awal taksonomi meliputi "hacking utilitas "sebagai tipe insiden. Hal ini kemudian dihapus dari desain akhir dan diganti dengan "root kit”. Perubahan layak lainnya adalah penggabungan dari dua jenis insiden terpisah, "virus" dan "worm" sebagai salah satu Jenis insiden. Hal ini dilakukan dengan pertimbangan bahwa peserta sesi akan cenderung mengikuti entri sama dalam dua jenis insiden tersebut. Jadi untuk meminimalkan redundansi data, dua insiden ini digabungkan menjadi satu. Penting untuk dicatat bahwa kasus dilakukan untuk studi diuraikan di sini semua melibatkan taksonomi insiden elektronik. Proses yang sama bisa diterapkan untuk program perencanaan respon insiden lainnya terlepas dari sifat insiden di taksonomi. Langkah 3 adalah proses membersihkan ide-ide yang diperoleh dari brainstorming pada langkah 2. Desain proses untuk langkah yang berubah dari desain awal dalam menugaskan orang untuk bekerja pada kejadian khusus, sebelum kegiatan bersih-bersih dan bukan sebelum aktivitas brainstorming. Alasan untuk perubahan ini adalah untuk memaksimalkan potensi untuk mendapatkan kontribusi yang lebih luas dari semua peserta selama fase brainstorming serta memiliki orang-orang berpasangan sebelum kegiatan bersih-bersih untuk memiliki fokus terarah pada kategori insiden tertentu. Langkah 4 dan 5 dalam desain akhir yang benar-benar baru selain dari desain awal. Langkahlangkah ini telah dimasukkan untuk meningkatkan kemungkinan mencapai konsensus di antara anggota kelompok untuk memastikan bahwa masing-masing insiden dan sub-kategori penyusunnya telah cukup tertutup dan tidak ada masalah hilang yang akan dibahas dalam salah satu bagian. Langkah 6 (langkah 4 di desain awal, lihat Lampiran) memiliki konstan tetap sepanjang desain dan terlibat dengan semua kategori ide dan suara untuk meriksa konsensus dengan kelompok. Langkah 5 dari desain proses awal (lihat Lampiran) terlibat dengan menentukan tingkat keparahan berlaku untuk setiap kejadian. Langkah ini telah dieliminasi dari proses desain akhir karena fakta bahwa pada kenyataannya, salah satu harus berurusan dengan setiap dan semua insiden yang terjadi. Sekarang sangat tidak mungkin bahwa prioritas insiden akan diperlukan 4.2.Asumsi Pada titik ini penting untuk menyoroti beberapa asumsi yang kami buat dalam melaksanakan proses fasilitasi insiden respon. Yang pertama adalah bahwa seluruh proses adalah salah satu yang berulang. Apakah ini berarti yang berjalan melalui seluruh sesi dimulai dengan brainstorming ide-ide untuk voting hasil untuk mencapai konsensus mungkin tidak membawa kesepakatan penuh antara anggota kelompok dalam satu iterasi. Sejumlah putaran diskusi dan membangun konsensus mungkin diperlukan bahwa mungkin melampaui kerangka waktu yang dialokasikan untuk sesi. Asumsi di sini adalah bahwa para peneliti serta peserta memahami bahwa aliran proses sesi dialokasikan untuk satu setengah jam hanyalah langkah pertama dalam mencapai tujuan datang dengan Rencana respon insiden melalui fasilitasi menggunakan GSS. 4.3.Persiapan Sejumlah langkah persiapan telah dilaksanakan sebelum sesi fasilitasi IRP yang sebenarnya bisa dijalankan. Yang pertama dan terpenting tugas yang perlu dilakukan adalah merumuskan agenda tugas. Agenda menguraikan kegiatan serta durasi masing-masing kegiatan bahwa kelompok akan melakukan seluruh sesi. Agenda tugas dimasukkan baik pada slide untuk menyajikan ke kelompok serta ke dalam sistem groupware sehingga semua siap untuk pergi ketika sesi dimulai. Penting untuk dicatat di sini bahwa untuk masing-masing tiga kasus,langkah 4 dan 5 harus ditinggalkan agar sesi sesuai waktu yang dialokasikan. 5. Hasil Seperti disebutkan sebelumnya, tiga kasus yang digunakan untuk menguji desain kolaborasi proses untuk menciptakan IRP. Selama sesi, kami memantau peserta persepsi bersama dengan efisiensi dan efektivitas proses dalam mencapai tujuan yang telah ditetapkan dari Proses kolaborasi. Kami menganalisis proses sepanjang empat konstruksi: produktivitas, efisiensi, efektivitas dan kepuasan pengguna. Tabel 2 dan 3 menunjukkan jumlah kontribusi,kontribusi yang unik, dan komentar yang diberikan dalam tugas antara perbedaan dan konvergensi. Tabel 2 memberikan hasil brainstorming asli sesi sementara. Table 2. Contributions from brainstorming activity Table 3. Contributions from clean-up activity 5.1. Produktifitas Produktifitas didefinisikan sebagai hasil yang dicapai selama sumber daya yang digunakan dalam proses kolaborasi untuk sampai pada hasil yang memuaskan. Untuk mengatur produktivitas kelompok, kami menggunakan jumlah kontribusi dan keunikan kontribusi. Kami juga melihat jumlah komentar off-tugas yang dibuat. 5.2. Efisiensi Efisiensi adalah sumber daya yang digunakan sebagai perbandingan tindakan sumber daya tertentu. Untuk mengukur efisiensi proses kolaborasi,kita menentukan seberapa baik peserta memahami proses/ugas dan bisa menjalankannya dalam batas waktu yang direncanakan. Dari pengamatan kami diketahui bahwa proses itu cukup efisien. 5.3. Efektivitas Kami mendefinisikan sejauh mana peserta memenuhi tujuan proses. Dari perspektif peneliti/pengembang, peserta berhasil pada hasil yang memuaskan. Hars dicatat, bagaimanapun,beberapa peserta mempertanyakan tujuan dan proses karena kegagalan untuk mencapai konsensus di beberapa titik dalam salah satu lokakarya. Ini karena fakta bawa tujuanproses perbaikan dan konsensus yang berulang tidak bisa dilakukan dalam waktu yang ditentukan. 5.4. Kepuasan Pengguna Kita mendifinisikan ini sebagai respon yang efektif sebagai pencapaian tujuan. Untuk menilai kepuasan peserta akan proses dan hasil, rapat umum penilaian survei kuesioner digunakan. Untuk detail mengenai validasi instrumen ini, alat ini menggunakan pertanyaan 7titik Likert skala,mulai dari sangat setuju menjadi sangat setuju. Berdasarkan hasil yang ditampilkan dan umpan balik yang diterima,peserta tidak diragkan lagi puas dan lkakarya akan berguna. Dari perspektif peneliti/pengembang,peserta nampak sangat nyaman dengan teknologi GSS, yang memudahkan eksekusi. 6. Pembahasan Fokus utama dari studi ini adalah untuk merancang proses penciptaan kolaborasi IRP yang dipindahtangankan,berulang dan dapat diprediksi. Proses ini diracang dan diuji dalam tiga studi kasus. Sejumlah isu muncul yang harus diperhitungkan untuk masa depan tes dan penerapan proses organisasi. Pertama, tingginya tingkat kontribusi, bersama dengan tingkat rendah komentar offtugas memberikan alasan untuk percaya bahwa proses ini telah berhasil dalam memperoleh tujuan menjaga orang pada tugas dan bekerja menuju tugas yang diberikan. Namun, itu adalah appearedthat ada relatif sedikit perbedaan antara jumlah kontribusi dan jumlah kontribusi unik. Hal ini membawa kita untuk percaya bahwa para peserta tidak memiliki cukup waktu untuk secara efektif menyelesaikan semua yang diperlukan untuk diselesaikan. Umpan balik mereka, baik dalam tanggapan terhadap pertanyaan terbuka di GSS dan selama wawancara, meminjamkan dukungan untuk pengamatan ini. Kedua, tampaknya bahwa proses dirancang dapat diterapkan dalam berbagai organizationalcontext untuk kolabrasi IRP bersama-sama. Satu-satunya unsur dari proses yang tergantung pada konteks di mana itu diterapkan adalah taksonomi insiden. Hal ini dapat dipoles untuk setiap situasi. Selama tiga kasus, taksonomi diubah sekali tanpa mempengaruhi sisa proses atau pelaksanaannya. Juga subjek ahli dalam kasus ketiga didukung gagasan tentang penerapan kontekstual lebih luas dari proses selama wawancara informal. Ketiga, hasil dari tiga kasus menyarankan bahwa proses memang memiliki potensi untuk mendukung organisasi dalam menciptakan IRPs berguna. Subjek ahli mengakui bahwa dalam setiap kasus peserta menciptakan materi yang berguna yang bisa dimasukkan ke dalam IRP penuh. Kendala waktu menghalangi kami memiliki kelompok-kelompok yang menyelesaikan salah satu rencana IRP tapi ada konsensus yang cukup luas bahwa lokakarya mengakibatkan elemen yang sangat berguna yang dapat mudah digunakan. Keempat, dari perspektif penelitian, studi ini mengikuti proses desain teknik kolaborasi sebagaimana didefinisikan dalam [6]. Pengalaman selama penelitian mengkonfirmasi penerapan berbagai langkah desain. Namun, pengalaman juga menekankan perlunya iterasi dan langkah-langkah bertahap selama desain proses kolaborasi diulang. Pendekatan penelitian tindakan untuk melakukan studi ini tampaknya menjadi kongruen dengan sifat proses desain teknik kolaborasi. Tampaknya sulit untuk mendapatkan proses berulang 'yang benar yang pertama'. Juga, bekerja di sejumlah kasus pilot memungkinkan kita fokus perhatian khusus terhadap unsur-unsur tertentu dalam proses dan fine tune mereka. Akhirnya, analisis dalam studi ini menawarkan beberapa langkah pertama tiba di ukuran untuk jumlah konvergensi yang berlangsung selama upaya kolaborasi. Dengan membandingkan hasil dari kegiatan 'menghasilkan' hasil 'menyatu' kegiatan bahwa keduanya berhubungan dengan set yang sama atas kontribusi, kita dapat membandingkan apa tingkat hasil akhir telah kental dan tumpang tindih telah dihapus. Seperti dapat dilihat dalam tabel 2 dan 3, membandingkan indikator ini dapat menghasilkan wawasan lebih dari sekedar hasil kegiatan terpisah. Itu juga dapat menumpahkan cahaya pada sejauh whichprevious kegiatan yang lengkap atau jika sumber daya (misalnya waktu) yang tersedia untuk menyelesaikan. 7. Kesimpulan Organisasi perlu IRP untuk meminimalkan dampak dari peristiwa yang mengganggu, untuk memungkinkan proses bisnis utama untuk bergerak maju secara tepat waktu, dan mengembalikan operasi normal secepat dan seefisien mungkin. Literatur saat ini, tidak menyediakan proses kolaboratif praktis yang dapat digunakan untuk mengembangkan sebuah rencana unik untuk kebutuhan mereka. Tujuan dari penelitian ini adalah untuk merancang dan menguji proses IRP kolaboratif yang mengikuti pendekatan CE. Untuk tujuan ini, kami telah menyempurnakan desain proses kolaborasi di tiga iterasi menggunakan umpan balik dari pengamatan, survei dan wawancara. Proses memberi IRP praktisi dan para pemangku kepentingan dengan alat-alat untuk mempersiapkan rencana tanggap insiden yang mencakup: 1) 2) 3) 4) 5) 6) identifikasi kejadian pemberitahuan yang berwenang, containmentof kejadian, dihapuskan, pemulihan dari insiden, rencana tindak lanjut untuk menganalisis insiden dan memodifikasi IRP. Hasil kami menunjukkan bahwa konsep menciptakan proses kolaborasi IRP bekerja. Kami menerima tanggapan positif dari para peserta dalam hal kepuasan dengan proses, kepuasan dengan hasil, dan grup produktivitas. Temuan ini signifikan dalam terang dari fakta bahwa ini adalah sebuah studi eksplorasi dengan waktu terbatas sumber daya untuk secara memadai menguji proses untuk kesimpulan yang sukses. 8. Daftar Pustaka 1. Briggs, R. O., Vreede, G. J. de, Nunamaker, J. F. Jr. (2003). Collaboration Engineering With ThinkLets to Pursu Sustained Success with Group Support Systems. Journal of Management Information Systems, 19, 4, 31-63. 2. Briggs, R. O., Kolfschoten, G. L., Vreede, G. J. de, Dean, D. L. (2006, August). Defining Key Concepts for Collaboration Engineering. Proceedings of 12th Americas Conference on Information Systems (AMCIS), Mexico. 3. Briggs, R.O., Reinig, B., Vreede, G.J. de. (2006). Meeting Satisfaction for Technology Supported Groups: An Empirical Validation of a Goal-Attainment Model, Small Group Research, (in press). 4. Briggs, R.O., Vreede, G.J. De, Reinig, B.A. (2003). A Theory and Measurement of Meeting Satisfaction, Proceedings of the 36th Hawaiian International Conference on System Sciences, Los Alamitos: IEEE Computer Society Press. 5. Grinsven, J. van and Vreede, G. J. de (2002), Design Guidelines for Risk Management in the Distributed Software Development Process, Proceedings of the International Design Conference, Dubrovnik, May 14-17. 6. Kolfschoten, G. L., Vreede, G. J. de, Chakrapani, A., and Koneri, P. (2006), The Collaboration Engineering Approach for Designing Collaboration Processes, Proceedings of the First HICSS Symposium on Case and Field Studies of Collaboration, Poipu, Kauai, Hawaii. 7. Koneri, P. G., Vreede, G. J. de, Dean, D. L., Fruhling, A. L. and Wolcott, P. “The Design and Field Evaluation of a Repeatable Collaborative Software Code Inspection Process,” In Proceedings of CRIWG 2005, LNCS3706, Fuks, H., Lukosch, S. and Salgado, A.C. (Eds.), Porto de Galinhas, Pernambuco, Brazil, 2005, pp. 325-40. 8. Poindexter, D., & St. Laurent, N. (2000, May 19). Incident Handling at BMDO (IWS – The Information Warfare Site No. 0008 Ver. 1), Retrieved May 4, 2006 from: http://www.iwar.org.uk/comsec/resources/fasp/BMDOIncH andling.htm. 9. Vreede, G. J. de, Fruhling, A., and Chakrapani, A. (2005) “A Repeatable Collaboration Process for Usability Testing,”, p. 46, Proceedings of the 38th Annual Hawaii International Conference on System Sciences (HICSS'05). 10. Vreede, G. J. de., & Briggs, R.O. (2005). Collaboration Engineering: Designing repeatable processes for high-value collaborative tasks. Hawaii International Conference on Systems Science, Los Alamitos: IEEE Computer Society Press. 11. Wack, J.P. “Establishing a Computer Security Incident Response Capability.” US National Institute of Standards and Technology. Gaithersburg, Md. NIST Special Publication 800-3. November 1991. 12. Zuber-Skerritt, O. (1991). Action research for change and development. Gower Publishing, Aldershot.

Judul: Tugas Review Jurnal Irp

Oleh: Dita Putri


Ikuti kami