TUGAS REVIEW JURNAL IRP

KEAMANAN JARINGAN

Nama Anggota Kelompok : NIM :

1. Muhammad Jundi Hanif 13.11.0114
2. Hendri Rahman Wibawanto 13.11.0051
3. Golan Aldias 13.11.0206
4. Purwanti 13.11.0008
5. Dita Putri Damayanti 13.11.0042
6. Tika Putri Galuh 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 orang-
orang 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, masing-
masing 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. Langkah-
langkah 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 7-
titik 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 off-
tugas 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) identifikasi kejadian
2) pemberitahuan yang berwenang, containmentof
3) kejadian,
4) dihapuskan,
5) pemulihan dari insiden,
6) 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.