• RPL

    MODEL-MODEL PROSES PERANGKAT LUNAK

    Pandangan umum tentang Rekayasa Perangkat Lunak
    Usaha yang berhubungan dengan Rekayasa Perangkat Lunak dapat dikategorikan
    ke dalam tiga fase umum dengan tanpa mempedulikan area aplikasi, ukuran proyek atau
    kompleksitasnya. Masing-masing fase akan memberi tekanan pada pertanyaanpertanyaan
    yang sudah ditulis diatas :
    · Fase Definisi (Definition Phase) berfokus pada “apa” (what), dimana pada
    definisi ini pengembang perangkat lunak harus mengidentifikasi informasi apa
    yang akan diproses, fungsi dan unjuk kerja apa yang dibutuhkan, tingkah laku
    system seperti apa yang diharapkan, interface apa yang akan dibangun, batasan
    desain apa yang ada dan kriteria validasi apa yang dibutuhkan untuk
    mendefinisikan sistem yang sukses. Kebutuhan (requirement) kunci dari sistem
    dan perangkat lunak yang didefinisikan. Metode yang diaplikasikan selama fase
    definisi berbeda, tergantung pada paradigma rekayasa perangkat lunak (atau
    kombinasi paradigma) yang diaplikasikan.
    · Fase Pengembangan (Development Phase) berfokus pada how (bagaimana), yaitu
    dimana selama masa pengembangan perangkat lunak, teknisi harus
    mendefinisikan bagaimana data dikonstruksikan, bagaimana detil prosedur akan diimplementasikan, bagaimana interface ditandai dll.

    · Fase Pemeliharaan (Maintenance Phase) berfokus pada perubahan yang
    dihubungkan dengan koreksi kesalahan, penyesuaian yang dibutuhkan ketika
    lingkungan perangkat lunak berkembang, serta perubahan sehubungan dengan
    perkembangan yang disebabkan oleh perubahan kebutuhan pelanggan.
    2. Fase Definisi :
    Proses Requirements Engineering
    Hasil dari fase requirements engineering terdokumentasi dalam requirements
    specification. Requirements specification berisi kesepakatan bersama tentang
    permasalahan yang ingin dipecahkan antara pengembang dan customer, dan merupakan
    titik start menuju proses berikutnya yaitu software design. Sistemisasi proses kesepakatan
    pengembang dan customer dalam requirements engineering dibagi dalam 3 proses besar
    yaitu: elicitation, specification, validation and verification.
    Requirements Elicitation
    Adalah proses mengumpulkan dan memahami requirements dari user. Kadang
    masalah yang muncul berakar dari masalah knowledge domain (perbedaan disiplin ilmu
    yang dimiliki). Customer adalah expert pada domain yang softwarenya ingin
    dikembangkan (domain specialist) misal customer perbankan akan ahli dalam bidang
    perbankan, dilain pihak sang pengembang (requirements analyst) adakalanya sama sekali
    buta terhadap knowledge domain tersebut, meskipun tentu memahami dengan benar
    bagaimana sebuah software harus dikembangkan. Masalah knowledge domain tersebut
    yang diharapkan bisa diatasi dengan adanya interaksi terus menerus dan berulang (iterasi)
    antara pengembang dan customer. Proses interaksi tersebut kemudian dimodelkan
    menjadi beberapa teknik dan metodologi diantaranya adalah interviewing, brainstorming,
    prototyping, use case, dsb.
    Requirements Specification
    Setelah masalah berhasil dipahami, pengembang mendeskripsikannya dalam
    bentuk dokumen spesifikasi dokumen. Spesifikasi ini berisi tentang fitur dan fungsi yang
    diinginkan oleh customer, dan sama sekali tidak membahas bagaimana metode
    pengembangannya. IEEE mengeluarkan standard untuk dokumen spesifikasi Requirements Specifications [IEEE-830]. Dokumen spesifikasi requirements bisa berisi
    functional requirements, performance requirements, external interface
    requirements, design constraints, maupun quality requirements.
    Requirements Validation and Verification
    Setelah spesifikasi requirements berhasil dibuat, perlu dilakukan dua usaha:
    • Validation (validasi), yaitu proses untuk memastikan bahwa requirements yang
    benar sudah ditulis
    • Verification (verifikasi), yaitu proses untuk memastikan bahwa requirements
    sudah ditulis dengan benar
    Proses validasi dan verifikasi ini melibatkan customer (user) sebagai pihak yang
    menilai dan memberi feedback berhubungan dengan requirements.
    Setelah melalui proses Requirement Engineering tentu saja masih panjang proses
    yang harus dilakukan pengembang sistem. Yaitu selanjutnya proses Analisa Sistem. Yang
    akan dijelaskan pada bab III.
    3. Model Proses Perangkat Lunak
    Untuk menyelesaikan masalah yang nyata dalam suatu hal, perekayasa perangkat
    lunak harus menggabungkan strategi pengembangan yang melingkupi lapisan proses,
    metode dan alat-alat bantu serta fase-fase generik (akan dijelaskan pada bab selanjutnya).
    Strategi yang dimaksud, sering diacukan sebagai model proses atau paradigma rekayasa
    perangkat lunak. Model proses untuk rekayasa perangkat lunak dipilih berdasarkan sifat
    aplikasi dan proyeknya, metode dan alat-alat bantu yang akan dipakai.
    Pada bab ini selanjutnya akan didiskusikan bermacam-macam model proses yang
    berbeda pada perangkat lunak. Penting untuk diingat bahwa masing-masing model sudah
    ditandai dengan cara tertentu sehingga diharapkan bisa membantu di dalam kontrol dan
    koordinasi dari proyek perangkat lunak yang nyata. Dengan demikian, pada intinya
    semua model menunjukkan karakteristiknya.
    1. MODEL SEKUENSIAL LINIER (WATERFALL)
    Gambar berikut menggambarkan sekuensial linier untuk rekayasa perangkat lunak,
    yang sering disebut dengan siklus kehidupan klasik atau model air terjun.
    Requirements yang terkenal dengan nama IEEE Recommended Practice for Software
    analisis desain kode tes
    Pemodelan sistem informasi
    Gambar Model Sekuensial Linier (Waterfall Model)
    Sekuensial linier mengusulkan sebuah pendekatan kepada pengembangan perangkat
    lunak yang sistematik dan sekuensial yang mulai pada tingkat dan kemajuan system
    pada seluruh analisis, desain, kode, pengujian (tes), dan pemeliharaan. Berikut ini
    penjelasan yang bisa diberikan untuk masing-masing tahap :
    · Analisis kebutuhan perangkat lunak
    Proses pengumpulan kebutuhan difokuskan khususnya untuk perangkat lunak,
    perekayasa perangkat lunak (Analis) harus memahami domain permasalahan
    (problem domain), tingkah laku, unjuk kerja dan antarmuka (interface) yang
    diperlukan. Kebutuhan baik untuk sistem maupun perangkat lunak
    didokumentasikan dan dilihat lagi dengan pelanggan.
    · Desain
    Desain perangkat lunak sebenarnya adalah proses multi langkah yang berfokus
    pada empat atribut sebuah program yang berbeda (struktur data, arsitektur
    perangkat lunak, representasi interface, dan detail (algoritma) prosedural. Proses
    desain menerjemahkan syarat/kebutuhan ke dalam sebuah representasi
    perangkat lunak yang dapat diperkirakan demi kualitas sebelum dimulai
    pemunculan kode (coding). Sebagaimana analisis, desain ini juga
    didokumentasikan.
    · Generasi kode
    Desain harus diterjemahkan ke dalam bentuk mesin yang bisa dibaca. Langkah
    pembuatan kode meliputi pekerjaan dalam langkah ini, dan dapat dilakukan
    secara mekanis.
    · Pengujian (Tes)
    Sekali kode dibuat, pengujian program dimulai. Proses pengujian berfokus pada
    logika internal perangkat lunak, memastikan bahwa semua pernyataan seudah
    diuji, dan pada eksternal fungsional, yaitu mengarahkan pengujian untuk
    menemukan kesalahan-kesalahan dan memastikan bahwa input yang dibatasi
    akan memberikan hasil aktual yang sesuai dengan hasil yang dibutuhkan.
    · Pemeliharaan
    Perangkat luna akan mengalami perubahan setelah disampaikan kepada
    pelanggan (perkecualian yang mungkin adalah perangkat lunak yang
    dilekatkan). Perubahan akan terjadi karena kesalahan-kesalahan karena
    perangkat lunak harus disesuaikan untuk mengakomodasi perubahan-perubahan
    di dalam lingkungan eksternalnya atau karena pelanggan membutuhkan
    perkembangan fungsional atau unjuk kerja. Pemeliharaan perangkat lunak
    mengaplikasikan lagi setiap fase program sebelumnya dan tidak membuat yang
    baru lagi.
    2. MODEL PROTOTIPE
    Model prototipe ini dimulai dengan pengumpulan kebutuhan. Pengembang dan
    pelanggan bertemu dan mendefinisikan obyektif keseluruhan dari perangkat lunak,
    dan mengidentifikasi segala kebutuhan yang diketahui.
    Mendengarkan
    Pelanggan
    Membangun
    Memperbaiki
    Market
    Uji Pelanggan-
    Mengendalikan
    Market
    Gambar. Model Prototipe

    Secara ideal prototipe berfungsi sebagai sebuah mekanisme untuk mengidentifikasi
    kebutuhan perangkat lunak. Prototipe bisa menjadi paradigma yang efektif bagi
    rekayasa perangkat lunak. Kuncinya adalah mendefinisikan aturan-aturan main pada
    saat awal, yaitu pelanggan dan pengembang keduanya harus setuju bahwa prototype
    dibangun untuk berfungsi sebagai mekanisme pendefinisian kebutuhan. Prototype
    kemudian disingkirkan dan perangkat lunak actual direkayasa dengan tertuju kepada
    kualitas dan kemampuan pemeliharaan.
    3. MODEL RAD
    Rapid Application Development (RAD) adalah sebuah model proses perkembangan
    perangkat lunak sekuensial linier yang menekankan siklus perkembangan yang sangat
    pendek. Model RAD ini merupakan sebuah adaptasi “kecepatan tinggi” dari model
    sekuensial linier dimana perkembangan cepat dicapai dengan menggunakan
    pendekatan konstruksi berbasis komponen. Jika kebutuhan dipahami dengan baik,
    proses RAD memungkinkan tim pengembangan menciptakan “sistem fungsional
    yang utuh” dalam periode waktu yang sangat pendek (kira-kira 60-90 hari).
    Pendekatan RAD melingkupi fase-fase sebagai berikut :
    Pemodelan Bisnis. Aliran informasi diantara fungsi-fungsi bisnis dimodelkan dengan
    suatu cara untuk menjawab pertanyaan-pertanyaan berikut : Informasi apa yang
    mengendalikan proses bisnis? Informasi apa yang dimunculkan? Siapa yang
    memunculkannya? Kemana informasi itu pergi? Siapa yang memprosesnya?
    Pemodelan Data. Aliran informasi yang didefinisikan sebagai bagian dari fase
    business modelling disaring kedalam serangkaian objek data yang dibutuhkan untuk
    mendukung bisnis tersebut.
    Pemodelan Proses. Aliran informasi yang didefinisikan di dalam fase data modelling
    ditransfirmasikan untuk mencapai aliran informasi yang perlu bagi implementasi

    sebuah fungsi bisnis. Gambaran pemrosesan diciptakan untuk menambah,
    memodifikasi, menghapus, atau mendapatkan kembali sebuah objek data.
    Pembentukan Aplikasi. RAD mengasumsikan pemakaian teknik generasi keempat.
    Selain menciptakan perangkat lunak dengan menggunakan bahasa pemrograman
    generasi ketiga yang konvensional, RAD lebih banyak memproses kerja untuk
    memakai lagi komponen program yang ada atau menciptakan komponen yang bisa
    dipakai lagi.
    Pengujian dan Turnover. Karena proses RAD menekankan pada pemakaian
    kembali, banyak komponen program telah diuji. Hal ini mengurangi keseluruhan
    waktu pengujian. Tetapi komponen baru harus diuji dan semua interface harus dilatih
    secara penuh.
    Pemodelan
    Bisnis
    Pemodelan
    Data
    Pemodelan
    Proses
    Pembentukan
    Aplikasi
    Pengujian
    dan Turnover
    60-90 hari
    Pemodelan
    Bisnis
    Pemodelan
    Data
    Pemodelan
    Proses
    Pembentukan
    Aplikasi
    Pengujian
    dan Turnover
    Pemodelan
    Bisnis
    Pemodelan
    Data
    Pemodelan
    Proses
    Pembentukan
    Aplikasi
    Pengujian
    dan Turnover
    Tim # 2
    Tim # 3
    Gambar. Model RAD (Rapid Application Development)
    4. MODEL SPIRAL
    Model spiral (spiral model) yang pada awalnya diusulkan oleh Boehm adalah model
    proses perangkat lunak yang evolusioner yang merangkai sifat iteratif dari prototipe
    dengan cara kontrol dan aspek sistematis dari model sekuensial linier. Di dalam
    model spiral, perangkat lunak dikembangkan di dalam suatu deretan pertambahan.

    Selama awal iterasi, rilis inkremental bisa merupakan sebuah model atau prototipe
    kertas. Selama iterasi berikutnya, sedikit demi sedikit dihasilkan versi sistem rekayasa
    yang lebih lengkap.
    Model spiral dibagi menjadi sejumlah aktifitas kerangka kerja, disebut juga wilayah
    tugas, diantara tiga sampai enam wilayah tugas :
    · Komunikasi pelanggan, tugas-tugas yang dibutuhkan utnuk membangun
    komunikasi yang efektif diantara pengembang dan pelanggan.
    · Perencanaan, tugas-tugas yang dibutuhkan untuk mendefinisikan sumbersumber
    daya, ketepatan waktu, dan proyek informasi lain yang berhubungan.
    · Analisis resiko, tugas-tugas yang dibutuhkan untuk menaksir resiko-resiko, baik
    manajemen maupun teknis.
    · Perekayasaan, tugas-tugas yang dibutuhkan untuk membangun satu atau lebih
    representasi dari aplikasi tersebut.
    · Konstruksi dan peluncuran, tugas-tugas yang dibutuhkan untuk mengkonstruksi,
    menguji, memasang (instal) dan memberikan pelayanan kepada pemakai
    (contohnya pelatihan dan dokumentasi).
    · Evaluasi pelanggan, tugas-tugas yang dibutuhkan untuk memperoleh umpan
    balik dari pelanggan dengan didasarkan pada evaluasi representasi perangkat
    lunak, yang dibuat selama masa perekayasaan, dan diimplementasikan selama
    pemasangan.
    Concept Development
    New Application
    Application Development
    Application Enhancement
    Maintenance
    Reenginee ring
    Evaluasi Pelanggan
    Konstruksi dan
    Peluncuran
    Rekayasa
    Analisis Resiko
    Perencanaan
    Komunikasi
    Pelanggan
    Gambar.
    Model Spiral
    Model spiral menjadi sebuah pendekatan yang realistis bagi perkembangan
    system dan perangkat lunak skala besar. Karena perangkat lunak terus bekerja
    selama proses bergerak, pengembang dan pemakai memahami dan bereaksi lebih
    baik terhadap resiko dari setiap tingkat evolusi. Model spiral menggunakan
    prototipe sebagai mekanisme pengurangan resiko. Tetapi yang lebih penting lagi,
    model spiral memungkinkan pengembang menggunakan pendekatan prototipe pada
    setiap keadaan di dalam evolusi produk. Model spiral menjaga pendekatan langkah
    demi langkah secara sistematik seperti yang diusulkan oleh siklus kehidupan klasik,
    tetapi memasukkannya ke dalam kerangka kerja iterative yang secara realistis
    merefleksikan dunia nyata.

    CSCW ;;Computer Supported Cooperation Worked (11)

    Membahas faktor-faktor organisasi yang mempengaruhi system groupware.

    Komunikasi face-to-face
    Bentuk komunikasi yang primitif (dalam hubungannya dengan teknologi). Mekanisme komunikasinya paling canggih. Yang perlu diingat dari komunikasi ini adalah tidak hanya meliputi percakapan dan pendengaran, tapi juga menggunakan bahasa tubuh dan tatapan mata. Ada beberapa fenomena yang mempengaruhi penggunaan computer-mediated communication.

    Transfer effects and Personal space
    Dalam komunikasi face-to-face, setiap orang cenderung mempertahankan jarak tertentu dengan lawan bicaranya. Jarak tepatnya bergantung pada konteks tingkat keramaian, semakin tinggi keramaian orang akan semakin dekat untuk didengar. Dalam ruang yang ramai, orang akan mendekatkan kepalanya untuk berbicara dan mengembalikan posisi jarak.
    Arah juga penting.

    Konsep personal space berbeda untuk setiap negara/budaya. Masalah personal space dapat timbul apabila percakapan dilakukan melalui video links.

    Kontak dan tatapan mata
    Dalam berkomunikasi, kontak mata memberikan beberapa petunjuk, a.l. perasaan tertarik/bosan, otoritas/power, kehadiran sosial, dll. Kontak mata langsung yang sporadic penting dalam percakapan dan kehadiran social. Orang yang tidak mau melakukan kontak mata kemungkinan menyembunyikan sesuatu. Normalnya, petunjuk ini akan hilang jika tidak ada kontak visual, misalnya pada koneksi video. Tetapi video-tunnel memungkinkan kontak mata bahkan seluruh ekspresi wajah.

    Gerak isyarat dan bahasa tubuh
    Dalam berkomunikasi, kita menggunakan tangan (gerak isyarat) untuk menunjuk sesuatu.
    Sayangnya, koneksi video tidak cukup dalam membaca keseluruhan gerakan yang ada.
    Beberapa system groupware mencoba mengatasi hal tersebut dengan menggunakan group pointer, icon yang dikontrol mouse yang dapat digunakan untuk menunjuk pada layar yang berbagi (pada share work surfaces). Group pointer digunakan pada groupware remote, juga pada groupware synchronous co-located seperti meeting room. Jika partisipan berada dalama ruang yang sama, keberadaan peralatan elektronik dapat mempengaruhi bahasa tubuh yang digunakan dalam komunikasi face-to-face yang normal. Atensi yang difokuskan pada keyboard dan layar dapat mengurangi kesempatan kontak mata. Monitor yang besar akan menutupi pandangan tubuh partisipan satu sama lain, mengurangi kemampuan interpretasi gerak isyarat dan posisi tubuh. Banyak computer-supported meeting room menempatkan monitor pada meja sehingga partisipan dapat saling melihat dengan jelas.

    Back channel
    Percakapan merupakan deretan dari ucapan/ ucapan/ ucapan/ ungkapan. A mengatakan sesuatu, B mengatakan sesuatu kemudian kembali ke A. Proses ini disebut turn-taking dan merupakan struktur yang mendasar dari percakapan. Setiap ucapan/ ucapan/ ucapan/
    ungkapan merupakan hasil dari negosiasi dan interaksi.

    Response dari pendengar berupa gerakan tubuh disebut back channel. Dengan adanya back channel, pembicara merasa bahwa pendengar cukup memahami pembicaraan. Back channel melakukan respon dengan menggunakan channel sensor. Beberapa masalah berkaitan dengan back channel yang mungkin timbul dalam komunikasi video, misalnya komunikasi video cenderung banyak menyoroti kepala dan bahu, sehingga kehilangan beberapa gerak tubuh dan isyarat. Layar yang besar cenderung mengurangi detail sehingga mungkin kehilangan beberapa informasi yang diperlukan. Audio links (mis. telepon) hanya memiliki verbal back channel. Meskipun kita banyak kehilangan back channel, orang masih percaya dengan media dan komunikasi masa dirasa efektif.

    Komunikasi berbasis teks, misalnya dalam konferensi elektronik, biasanya tidak memiliki back channel. Setiap konfirmasi harus diberikan secara eksplisit pada ucapan/ ucapan/
    ucapan/ ungkapan pendengar selanjutnya. Tetapi akan membingungkan dalam menganalisa ucapan/ ucapan/ ucapan/ ungkapan sederhana yang tidak sesuai dengan ucapan/ ucapan/
    ucapan/ ungkapan dalam percakapan.

    Turn-taking
    Turn-taking adalah proses dimana peran dari pembicara dan pendengar bertukar tempat.
    Dalam proses turn-taking, back channel biasanya merupakan bagian yang penting.
    Terjadinya proses turn-taking, a.l. karena: Pembicara menawarkan kesempatan kepada pendengar secara eksplisit, mis.
    mengajukan pertanyaan.
    Pembicara memberikan gap singkat dalam pembicaraan.
    Gap turn-offering membentuk bagian pusat dalam memperoleh respon back-channel dan dalam negosiasi turn-taking. Bentuk pemberian gap dari pembicara terutama berhubungan dengan audio channel.

    Masalah yang cukup serius dalam kaitan dengan pemberian gap timbul dalam komunikasi jarak jauh (komunikasi berbasis satelit) karena keterlambatan waktu. Untuk mentrasmisikan sebuah sinyal, harus dinaikkan ke satelit dan kemudian dikembalikan ke bumi. Satelit stasiun bumi berada pada ketinggian sekitar Akan 100.000 km di atas bumi – seperempat jarak ke bulan. Gelombang radio membutuhkan 700 milidetik untuk menuju satelit dan kembali lagi. Waktu ini bersama2 dengan penundaan proses di bumi dan di satelit membutuhkan sekitar 2 detik sehingga terjadi gap sekitar 4 detik antara satu partisipan berkata sesuatu dan ketika menunggu respon partisipan lainnya.

    Percakapan
    Banyak analisis percakapan difokuskan pada percakapan antara 2 orang, tetapi ini berkaitan dengan ‘social chat dan ada beberapa pemahaman sosiologi dan psikologi dari percakapan yang diperlukan.

    Ada tiga manfaat dari teori percakapan dalam CSCW : 1. dapat digunakan untuk menganalisa catatan (transkrip), misalnya dalam konferensi elektronik. Ini akan membantu memahami seberapa baik partisipan menyalin dengan komunikasi elektronik.
    2. digunakan sebagai petunjuk untuk keputusan desain. Pemahaman percakapan normal antar manusia menghindari kesalahan besar dalam perancangan media elektronik.
    3. dapat digunakan untuk mengarahkan desain, menstrukturkan sistem dengan teori.

    Struktur percakapan dasar
    Struktur percakapan yang paling dasar adalah turn-taking. Pada tingkat yang lebih tinggi, struktur percakapan dapat dilihat sebagai urutan giliran, biasanya pergantian di antara partisipan. Percakapan dalam setiap giliran disebut dengan ucapan/ ucapan/ ucapan/
    ungkapan. Sering sekelompok ucapan/ ucapan/ ucapan/ ungkapan dari percakapan dibuat ke dalam pasangan : pertanyaan dan jawaban, pernyataan dan persetujuan. Ada yang mengatakan bahwa pasangan ini tidak saja struktur dasar dari percakapan tetapi struktur yang fundamental.

    Konteks
    Setiap ucapan dan fragmen dari percakapan sangat tergantung pada konteks yang digunakan untuk menghilangkan ambiguitas dari ucapan.

    Ada 2 tipe konteks dalam percakapan :
    1. konteks internal, tergantung pada ucapan sebelumnya.
    2. konteks eksternal, tergantung pada lingkungan.

    Meskipun percakapan yang lengkap merupakan context-dependent, konteks eksternal yang berimplikasi terhadap perancangan sistem dan pengumpulan data menjadi penting. Dari pengumpulan data, anotasi transkrip dengan gerak isyarat, tatap mata dan detail lingkungan juga penting. Pada pengumpulan data untuk sistem groupware, memiliki record yang sinkron dari percakapan partisipan (audio, video atau basis teks) dengan peralatan elektroniknya juga menjadi penting. Kita perlu mengetahui apa yang partisipan ketahui dari layarnya agar dapat diterjemahkan ke partisipan lainnya. Jika partisipan memiliki pandangan yang berbeda
    pada waktu yang sama, percakapan perlu dibreakdown, dimana satu partisipan membuat ucapan berdasarkan layarnya dan partisipan lainnya melihatnya berbeda pada layar lainnya.
    Bentuk khusus dari context-dependent adalah deictic reference, dengan adanya penunjukkan jari (pointed finger), konteks eksternal akan terlihat jelas. Percakapan sebenarnya yang lebih dari kata yang ditulis adalah indexical. Dalam pengucapan percakapan, dihubungkan dengan gerak isyarat atau tatap mata untuk konteks eksternal.

    Satu konsekuensi dari menggunakan konteks dalam percakapan adalah ungkapan yang difragmen secara natural.

    Topics, focus and forms of utterance
    Percakapan merupakan context-dependent. Partisipan perlu memiliki focus yang sama, disebut focus eksternal – obyek adalah nyata untuk partisipan dan juga benar untuk focus internal pada percakapan.

    Secara umum, topic mengacu percakapan. Identifikasi topic dan penunjukkan ucapan bersifat subyektif dan akan digunakan beberapa level kategori topic. Cara lain untuk mengklasifikasikan ucapan adalah dari relasi-relasinya ke tugas. Secara ekstrim, ucapan kemungkinan tidak relevan sama sekali. Melihat pada percakapan yang task-related, pengucapan diklasifikasikan dalam 3 jenis : Substantive relevan langsung dengan pembuatan topic Annotative penunjukkan klarifikasi, elaborasi, dll Procedural membicarakan tentang proses kolaborasi itu sendiri.

    Ucapan procedural berhubungan dengan struktur dari kolaborasi itu sendiri, atau tentang teknologi yang mendukung kolaborasi. Ini biasanya berhubungan dengan breakdown dimana teknologi dipaksakan ada pada komunikasi.

    Breakdown And Repair
    Breakdown dalam komunikasi terjadi apabila terdapat perbedaan fokus dari pembicara dan pendengar. Breakdown ini dapat diperbaiki dengan pertanyaan atau ucapan dari pembicara/pendengar yang dapat menimbulkan fokus dialog yang sama. Selain frekuensi breakdown dalam percakapan normal, komunikasi biasanya tidak berpengaruh karena repair-perbaikan yang sangat efisien. Redudansi, frekuensi dari turn-taking, back-channel, semua berkontribusi terhadap deteksi breakdown dan perbaikannya yang sangat cepat.
    Komunikasi elektronik sering mengurangi redudansi (pada single channel), mengurangi frekuensi turn-taking dan mengurangi back-channel.
    Constructing a shared understanding
    Arti yang tepat dari konteks menjadi penting dan bahasa yang dibentuk digunakan untuk mengurangi abiguitas. Sebuah buku diusahakan menggunakan bahasa yang ambiguitasnya sedikit dan hanya merupakan pengetahuan-pengetahuan umum.

    Perbedaan utama antara buku dan percakapan adalah bahwa percakapan bersifat interaktif.
    Pengetahuan yang shared digunakan pada buku adalah statis, dimana dalam percakapan bersifat dinamis, seperti bertambahnya pengetahuan partisipan satu sama lain dan seperti berpindahnya focus dari topic ke topic lainnya.

    Saat partisipan berada dalam percakapan, mereka dapat berasal dari latar belakang yang berbeda2 dan membawa pengetahuan yang berbeda. Meskipun demikian, mereka para partisipan hanya mencari pemahaman yang sama-umum (common ground) dalam hal tugas.
    Percakapan yang dilakukan tidak hanya saling bertukar informasi tentang tugas, tetapi juga melibatkan pengujian yang kontinyu dan pemeriksaan silang (cross checking) dari pemahaman partisipan yang lain.

    Pemahaman umum-common ground selalu parsial, jadi setiap ungkapan/ ucapan akan memiliki pengertian yang berbeda bagi pembicara dan pendengar. Dalam percakapan, lawan bicara sering tidak mau berbagi pengetahuan. Dan kita tahu bahwa lawan bicara berusaha untuk menginterpretasikan ucapan. Ada 2 prinsip untuk ucapan, yaitu relevan dan helpful. Relevan di sini berarti ucapan harus sesuai dengan topic saat itu. Helpful berarti bahwa ucapan harus dapat dimengerti oleh pendengar dan tidak ada ambigu dari pemahaman pendengar.

    Percakapan bersifat aktivitas social, berdasarkan pemahaman bersama yang dibangun, dan berdasarkan model partisipan yang lain. Juga bergantung pada interaksi yang kontinyu untuk memperbaiki kesalahan interpretasi dan mengkonfirmasi pemahaman.

    Speech Act Theory
    Speech act theory berpengaruh dan kontroversi dalam CSCW. Tidak hanya teknik analitik tetapi digunakan juga sebagai acuan untuk perancangan sistem komersial, Coordinator misalnya yang merupakan sistem email terstruktur.

    Premis dasarnya adalah bahwa ucapan/ ungkapan dapat dikarakterkan dengan apa yang dilakukan. Jika ‘saya lapar’, ini menunjukkan arti proporsional bahwa memang kita merasa lapar. Bergantung pada siapa yang berbicara dan kepada siapa, keinginan pernyataan untuk meminta aksi pendengar.

    Beberapa percakapan/ pengucapan menyebabkan perubahan pada apa yang telah diucapkannya. Misalnya pada pengucapan penghulu yang menikahkan. Pengucapan yang dilakukan mengubah keadaan. Perilaku dasar ini disebut dengan ‘illocutionary points’.
    Pengucapan individu berkontribusi pula ke percakapan. Struktur dasar dari percakapan dapat dilihat kemudian sebagai instant dari percakapan umum., misalnya percakapan untuk aksi-conversation for action (CfA). Ada beberapa percakapan umum lainnya seperti CfA, yaitu :
    Percakapan untuk klarifikasi biasanya dimasukkan dalam CfA untuk mengklarifikasi aksi yang diminta.
    Percakapan untuk kemungkinan melihat aksi selanjutnya.
    Percakapan untuk orientasi membangun suatu aksi selanjutnya.

    CfA merupakan bentuk percakapan yang meluas dan dibangun dengan baik. Percakapan yang kreatif memiliki bentuk struktur yang lebih sedikit.

    Komunikasi Berbasis Teks
    Dalam groupware yang asynchronous (dan beberapa sistem synchronous), bentuk komunikasi langsung yang dominan adalah berbasis teks. Komunikasi berbasis teks umum dikenal orang, mereka akan menulis dan menerima surat. Tetapi bentuk dari tulisan surat dan komunikasi yang face-to-face sangat berbeda. Komunikasi berbasis teks dalam sistem groupware seperti tiruan dari percakapan, sehingga terdapat beberapa masalah dalam mengadaptasi antara 2 media.

    Ada 4 tipe komunikasi tekstual dalam groupware: discrete; pesan langsung seperti dalam email linear; pesan partisipan ditambahkan pada akhir dari transkrip-catatan tunggal non-linear; saat pesan dihubungkan ke yang lainnya dalam model hypertext spatial; dimana pesan diatur dalam permukaan dua dimensi.

    Back channel and affective state
    Banyak koordinasi dari percakapan face-to-face bergantung pada back-channel dan interpretasi dari ekspresi pendengar. Dengan hilangnya back channel, nada suara serta bahasa tubuh pembicara menjadi hilang pula. Ini yang disebut dengan kondisi emosional-affective state pembicara dan illocutionary force dari pesan. Beberapa diantaranya adalah :

    – wajah tertawa, senang

    – wajah sedih, marah

    – wajah mengedip, humor

    Orang lebih menyukai menggunakan bahasa di email dibandingkan dengan percakapan face-to-face. Selain itu mereka ada jarak secara emosional dengan teks dari percakapannya dan memiliki percakapan yang meluas setiap waktu. Juga mereka tidak perlu mengekspresikan keadaan emosinya dengan perilaku.

    Grounding Constraint
    Adalah sifat dari channel dimana para pembicara berkomunikasi, meliputi: cotemporality; ucapan didengar segera setelah diucapkan simultaneity; partisipan dapat mengirim dan menerima pada waktu yang bersamaan sequence; ucapan-ucapan diurutkan.

    Dalam sistem berbasis teks, partisipan yang berbeda dapat menyusun secara simultan, tapi kurang cotemporality. Meskipun pesan muncul setelah dihasilkan, pesan tersebut tidak dapat dibaca secara real time. Pesan hanya dapat disampaikan kalau lengkap meskipun tertunda dengan komunikasi jaringan yang lambat.

    Turn Taking
    Selain breakdown, two-party dari interaksi berbasis teks melaporkan keseluruhan protocol turn-taking, yang menunjukkan banyak struktur dari percakapan normal termasuk adjacency pairs-pasangan bertetangga. Ketika ada 3 atau lebih partisipan, turn taking dan struktur adjacency pair mulai diturunkan-breakdown secara lengkap.

    Pada pasangan partisipan, turn taking mudah, satu orang berkata sesuatu, kemudian orang berikutnya. Masalahnya adalah dalam menentukan kapan pertukaran terjadi. Dengan 3 atau lebih partisipan, turn taking akan lebih kompleks lagi. Mereka harus menentukan siapa yang memiliki giliran selanjutnya. Ini diselesaikan dengan kelompok face-to-face dalam beberapa cara. Pertama, percakapan untuk sesaat difokuskan pada dua orang, dimana terjadi turn-taking antara 2-party. Kedua, pembicara secara khusus menentukan partisipan lainnya setelah ucapan diselesaikan, dengan posisi tubuh secara implicit atau “bagaimana menurut anda, A ?” secara eksplisit. Terakhir, pembicaraan selanjutnya dibiarkan terbuka, tetapi channel audio yang comtemporality memungkinkan partisipan lain melaksanakan gilirannya.

    Dalam percakapan berbasis teks yang tidak terstruktur, tidak adanya back channel menyulitkan pendengar lain untuk menginterupsi percakapan. Beberapa sistem menggunakan mekanisme yang terstruktur yaitu protocol round-robin (setiap partisipan berbicara menurut gilirannya) atau berada dalam antrian dari permintaan giliran.

    Konteks dan deixis
    Ungkapan sangat ambigu dan hanya berarti terhadap konteks eksternal, state dari sekitarnya, dan konteks internal, state percakapan. Ini menjadi masalah dalam komunikasi berbasis teks. Partisipan yang tidak hadir menyulitkan dalam penggunaan konteks eksternal bagi ungkapan yang tidak ambigu.

    Apa pun arti komunikasi langsung, partisipan remote memiliki kesulitan dalam menggunakan referensi deictic. Jika tampilannya tidak WYSIWIS maka mereka harus memastikan partisipan lainnya mencakup objek yang direferensi dan deskripsi tidak ambigu. Partisipan yang asinkron memiliki masalah dengan deixis yaitu tidak adanya kesempatan bagi partisipan lain untuk menjelaskan referensi. Objek yang direferensikan oleh pesan diubah saat seseorang datang membacanya. Group pointer bukan opsinya, tetapi menggunakan metode menghubungkan percakapan ke konteks dapat dilakukan, baik dengan menyimpan di objek sebagai anotasi atau memiliki hubungan hypertext antara percakapan dan objek.

    Beberapa masalah terjadi juga dalam mereferensikan deictic ke konteks internal. Dalam percakapan, konteks dihubungkan ke urutan linier dan bertetangga. Dalam transkrip teks linier, overlap memotong urutan percakapan sehingga masalah terjadi pada mengindekskan dan pada konteksnya.

    Banyak sistem email dan bulletin board tidak memperhatikan urutan dan konteks ke pesan.
    User menyalin pesan sebelumnya saat membalas. Sistem berbasis hyperteks tidak menggunakan urutan dari transkrip linier ini.

    Pace And Granularity
    Dalam percakapan, pengembalian sering hanya beberapa 10 menit-an lamanya. Pada konfirmasi minor dan back channel, pace lebih cepat lagi, pengembalian atau respon back channel setiap beberapa detik. Pace-tahapan email sangat lambat. Misalkan pada sebuah pesan yang dibuat dan dikirimkan, penerima membaca atau mendengar pesatn dan membuat dan mengirimkan jawaban. Pace dari percakapan adalah rerata dari deretan pesan yang terhubung dan terjawab. Ini berkebalikan dengan granularity. Untuk mendapatkan beberapa informasi, kita harus mengirimkan lebih setiap pesannya. Dengan mengurangi pace percakapan akan mengurangi inter aktivitas. Sejalan dengan menurunkan klarifikasi ungkapan individu, inter aktivitas menjadi penting dalam menentukan arah pembicaraan, percakapan seperti dalam permainan, dimana partisipan dapat melakukan perpindahan.

    Dalam sistem berbasis hyperteks, dapat diperluas dengan beberapa cabang dari pohon percakapan, tetapi pada perkataan atau transkrip teks linier, percakapan mengikuti satu cabang. Media apa pun yang digunakan, tidak dapat menurunkan pohon dengan lebih cepat dibandingkan pada pace percakapan. Untuk mengatasi keterbatasan ini, orang mengadopsi beberapa strategi salinan.

    Strategi salinan pertama adalah multiplexing. Pembicara melakukan pembicaraan secara parallel, setiap pesan untuk beberapa topic. Pada pohon percakapan, strategi ini turun ke beberapa cabang sekaligus. Strategi kedua adalah meningkatkan ukuran dari potongan pesan yaitu eagerness-keinginan. Pada pohon percakapan, strategi ini merupakan kedalaman dari strategi pertama. Partisipan menuruni satu cabang untuk memperkirakan respon partisipan lain. Tetapi strategi eagerness ini memiliki banyak kekurangannya.

    Linear text vs. Hypertext
    Komunikasi berbasis hyperteks lebih baik dari media komunikasi berbasis teks.
    Berkurangnya langkah dari percakapan berbasis teks berarti bahwa partisipan dipaksa untuk meningkatkan granulity pesan. Ini dapat diatasi dengan pesan multiplexing, sehingga mengurangi breakdown dan hilangnya topic. Jika pesannya adalah mini-hypertext maka eager messages membuat beberapa kemungkinan aksi yang dieskplisitkan oleh pesan.
    Kekurangannya adalah bahwa hypertext (yang statis pun) sulit untuk dinavigasikan.

    Kerja Kelompok
    Perilaku kelompok lebih kompleks terutama apabila kita memperhatikan hubungan sosial yang dinamis selama bekerja dalam kelompok.

    Dinamika kelompok
    Peran dan hubungan di dalam kelompok dapat berubah secara dramatis dalam suatu kurun waktu saat melaksanakan suatu pekerjaan. Nama peran seseorang dapat menimbulkan masalah, mis. seorang disebut penulis buku tapi sebenarnya ia hanya memberikan ide dan komentar tapi tidak menulis satu kata pun.

    Anggota dan struktur kelompok juga dapat berubah setiap saat. Dengan keluar atau masuknya anggota dalam kelompok dapat mengubah perilaku kelompok. Anggota kelompok yang baru memiliki masalah khusus dalam beradaptasi dengan budaya kelompok. Sistem groupware, misal tool argumentasi, dapat membantu dengan cara mencatat sejarah dari kelompok. Perancang groupware harus menyadari bahwa anggota baru dapat masuk dalam kelompok dan mendesain software sesuai dengan kelompok. Kelompok dapat dibagi dalam
    beberapa sub-kelompok yang bekerja secara mandiri dan kemudian membagikan hasilnya kepada sub-kelompok lainnya.

    Layout Fisik
    Orientasi peralatan komputer dapat mempengaruhi kerja kelompok. Semua partisipan harus bisa saling melihat satu sama lain. Pada ruangan pertemuan elektronik : Manajer tidak harus duduk di depan karena layar yang di depan dapat dikontrol dari semua terminal
    Manajer lebih baik duduk di belakang sehingga mereka bisa mengamati para peserta tanpa harus melepaskan pandangan dari layar Shared screen

    Kognisi Terdistribusi
    Berpikir tidak hanya terjadi di dalam kepala, tetapi juga dalam hubungan eksternal dengan benda-benda di dunia dan dengan orang lain. Pandangan ini disebut kognisi terdistribusi.
    Kognisi terdistribusi memiliki pengaruh besar pada cara melihat kerja kelompok bahkan kerja individual. Dalam hal ini perlu adanya mediating representation, yang merupakan alat komunikasi antara kelompok dan perwujudan nyata dari pengetahuan kelompok serta membentuk pengetahuan kelompok yang baru, misalnya gambar pada papan tulis.
    Komunikasi tidak hanya tentang memperoleh pengetahuan dari kepala satu orang ke kepala lainnya, tetapi tentang pembuat kelompok pengetahuan baru.

    Kita tidak perlu memahami proses kognisi setiap individu untuk merancang kelompok yang efektif. Dalam perancangan groupware yang efektif, desainer perlu memusatkan analisisnya pada situasi kelompok saat itu dan merancang groupware pada representasi eksternal yang dapat digunakan oleh seluruh partisipan.

    Studi Eksperimental
    Kompleksitas dari komunikasi manusia-manusia dan kerja kelompok membuat studi eksperimental dari kelompok dan groupware menjadi lebih sulit dibandingkan dengan eksperimen single-user.

    Misalkan kita akan mengevaluasi aplikasi yang digunakan bersama-sama dengan koneksi video antar partisipan. Kesulitan-kesulitan yang mungkin timbul adalah : Membutuhkan subyek yang lebih banyak dan waktu yang lebih lama dibandingkan eksperimen terhadap sistem single-user.
    Sulit memilih tugas yang tepat, karena tipe tugasnya yang akan diuji sangat bervariasi.
    Pengumpulan datanya membutuhkan perlengkapan video dan log yang banyak, yang mungkin tersebar di beberapa tempat.
    Pada tahap analisis, perbedaan statistik sangat ekstrim. Analisis dapat dilakukan dengan metode kuantitatif dan kualitatif.

    Studi Lapangan
    Banyak pendapat yang mengatakan bahwa kerja kelompok hanya dapat dipelajari dalam situasi kerja yang sebenarnya. Sesuai dengan ide kognisi terdistribusi, tindakan nyata adalah tindakan berdasarkan situasi, tergantung pada interaksi dengan benda dan manusia pada tempat kerja. Pendekatan yang paling sesuai dengan CSCW adalah ethnography, yaitu didasarkan pada pencatatan yang detail tentang interaksi antara manusia dan interaksi antara manusia dengan lingkungannya.

    Faktor-faktor Organisasi
    Faktor organisasi cukup berpengaruh terhadap dukungan dan relevansi dari sistem groupware pada khususnya, dan teknologi informasi pada umumnya.
    Beberapa faktor organisasi yang berpengaruh adalah:

    Siapa yang diuntungkan ?
    Sering terjadi ketidakseimbangan antara mereka yang mendapatkan keuntungan dengan mereka yang melaksanakan pekerjaan. Dalam sistem groupware, seharusnya ada tingkat
    simetri, yaitu apabila seseorang harus bekerja untuk sistem, ia harus memperoleh keuntungan dari sistem tersebut. Pada sistem kalender bersama-shared calendar, selain meningkatkan interface user secara personal, juga keuntungan dalam menggunakan sistem online untuk merencanakan waktu seseorang selain menggunakan kertas. Jika orang menggunakan organizer elektronik perlu dipertimbangkan untuk diintegrasikan ke sistem.

    Masalah Free-Rider
    Sumbangan dari setiap partisipan tidak sama, ada yang hanya memberikan sumbangan yang sedikit (free-rider), dan mereka mengambil keuntungan dari kerja anggota kelompok yang lain. Free rider mudah meningkat jumlahnya, sulit untuk membuat sama sehingga perlu ada suatu mekanisme seperti kontribusi round-robin, setiap orang mengkontribusikan sesuatu sekecil/ sependek apa pun).

    Critical Mass
    Dalam kaitan dengan biaya/ keuntungan, semakin sedikit pemakai semakin kecil keuntungan dibanding biaya.

    keuntungan pemakaian

    biaya pemakaian

    jumlahpemakai

    critical mass

    Setiap sistem groupware yang baru harus dirancang agar memiliki keuntungan yang lebih besar daripada biaya meskipun pemakainya sedikit, misalnya pada sistem email.

    Kerja Sama Atau Konflik ?
    Orang-orang dalam organisasi atau kelompok sering memiliki tujuan yang konflik dan pertemuan merupakan salah satu jalan untuk menyelesaikan konflik tersebut. Yang perlu
    diperhatikan sebelum menginstal sistem komputer adalah mengidentifikasikan stakeholder yang akan terpengaruh oleh sistem tersebut.

    Mengubah Struktur Kekuasaan
    Garis kekuasaan dan informasi dalam suatu organisasi cenderung mengalir ke atas dan ke bawah melalui manajemen garis. Media komunikasi yang baru mungkin mengacaukan struktur manajerial yang formal, mis. sistem email. Teknologi sebisa mungkin sesuai dengan struktur organisasi dan sosial yang ada.

    Pekerja Yang Tidak Kelihatan
    Kemajuan dalam telekomunikasi memungkinkan adanya tele-working dari rumah sehingga membuat pekerja jarang terlihat oleh manajemen.

    Mengevaluasi Keuntungan
    Keuntungan dari groupware, terutama email atau electronic conferencing, berhubungan dengan kepuasan kerja atau aliran informasi. Video-wall diharapkan membantu kontak sosial di dalam organisasi. Meskipun sistem groupware dinilai bermanfaat, tapi sulit untuk mengukur keuntungannya karena menyebar di seluruh organisasi.

    Latihan
    Untuk lebih memahami kerja dalam kelompok, lakukan kegiatan berikut ini: Lakukan survey di suatu kantor dimana beberapa orang bekerja bersama.
    Catat sedetail mungkin apa yang mereka kerjakan dan kapan.
    Lakukan kegiatan ini dengan beberapa fokus, al.:
    • Fokus pada komunikasi interpersonal secara langsung
    • Fokus pada benda yang digunakan bersama, mis. dokumen
    • Fokus pada satu pekerja pada satu waktu Pada saat pengumpulan data perhatikan hambatan atau salah pengertian yang mungkin terjadi dalam komunikasi, serta komunikasi yang implisit dengan obyek.
    Perhatikan juga tugas tertentu dalam suatu periode waktu tertentu, dan catat jumlah interupsi yang terjadi saat pekerja melaksanakan tugas tersebut, atau bagaimana suatu tugas dilaksanakan oleh beberapa orang.

    Buatlah suatu catatan lengkap mengenai hal tersebut dan buatlah suatu analisa singkat berdasarkan teori yang sudah dijelaskan.

    GROUPWARE

    Pengenalan

    Computer-supported cooperative work (CSCW) merupakan suatu group user yaitu bagaimana cara merancang suatu system yang digunakan untuk membantu pekerjaan sebagai suatu group dan bagaimana memahami dampak dari suatu teknologi pada pola pekerjaan mereka. HCI berasal dari ilmu psychology-computing sedangkan CSCW

    bersumbu pada sociology-computing. CSCW merupakan suatu system komputer yang mendukung pekerjaan sebagai suatu group yang dikenal dengan istilah groupware.

    System groupware

    Groupware dapat diklasifikasi dalam beberapa cara, salah satunya adalah dimana dan kapan seseorang peserta mengikuti kerja kelompok. Hal ini dapat diringkas dalam matriks time/space

    Different place

    Face-to-face

    Same time

    Telephone

    conversation

    Different

    Post-it-note

    Letter

    time

    Dimensi space dapat juga suatu dimensi secara geografis dan dibagi dalam co-located (tempat yang sama) dan remote (tempat yang berbeda). Contoh e-mail dan video conferencing yang bekerja pada jarak yang jauh.

    Sumbu time dibagi menjadi system synchronous dan asynchronous. Contoh telepon merupakan komunikasi remote synchronous dan post-it notes merupakan suatu asynchronous co-located.

    Gambar di bawah ini menunjukkan suatu cooperative work yang mendukung pembahasan : o Computer-mediated

    communication

    Mendukung komunikasi antar partisipan

    o Meeting and decision support systems

    Menangkap pemahaman secara umum

    o Shared application and artifacts

    Mendukun interaksi partisipan dengan berbagi pekerjaan UNDERSTANDING

    DIRECT

    PARTICIPANTS

    P

    P

    COMMUNICATION

    CONTROL AND

    FEEDBACK

    ARTEFACTS OF

    WORK

    A

    Terminology cooperation work berarti ada 2 atau lebih partisipan, P. Partisipan ini berhubungan satu sama lain dalam pekerjaan, dan juga berinteraksi dengan bermacam tool dan produk. Beberapa diantaranya adalah berbagi secara fisik, tetapi dengan maksud untuk tujuan kerja bersama, ini yang disebut sebagai artefact, A. Para partisipan saling bekerja sama dinotasikan dengan arah panah, bisa dengan berbicara (speech) atau surat, atau komunikasi langsung bisa dalam hal kategori pada matriks time/ space sebelumnya. Bagian dari tujuan komunikasi adalah untuk mendapatkan pemahaman umum dari tugas yang berhubungan. Pemahaman ini diimplisitkan dalam percakapan atau dalam diagram atau teks secara eksplisit. Untuk beberapa pekerjaan seperti penelitian dan aspek manajemen, membangun pemahaman dan ide merupakan tugas utama.Jika bukan ini, partisipan berinteraksi dengan tool dan objek kerja untuk melaksanakan pekerjaannya. Ini ditunjukkan dengan anak panah antar partisipan dan artefact of work. Panah ini menunjukkan dua aliran informasi : control dari partisipan ke artefact, dan feedback dari artefact ke partisipan.

    Computer-Mediated Communication (CMC)

    Secara implicit dalam istilah groupware dan CSCW dimana terdapat dua atau lebih partisipan dan mereka berkomunikasi satu sama lain. Kadang kala komunikasi yang baik tidak cukup – mereka harus dapat berkomunikasi untuk bekerja sama tentang pekerjaan mereka. Peningkatan komunikasi mungkin membantu masalah ini tetapi tidak terlalu diperlukan.

    Email dan Bulletin Board

    System groupware yang paling sederhana dan popular. Hal yang perlu diperhatikan dalam mengirim email :

    Preparation, menuliskan pesan pada komputer, mungkin menambahkan subyek pesan yang akan dikirim.

    Dispatch, menginstruksikan program email untuk mengirim pesan.

    Delivery, pada beberapa waktu kemudian mungkin perlu beberapa detik pada email di system LAN, perlu beberapa jam atau hari pada system gateway yang lambat maka email akan sampai pada alamat yang dituju.

    Notification, jika penerima email menggunakan komputer maka akan menampilkan pesan terdapat email yang ditujukan kepadanya atau komputer akan membunyikan beep sebagai tanda terdapat email.

    Receipt, penerima membaca email menggunakan program email yang mungkin lain dari pengirim.

    Tahapan ini dapat berbeda dari tool ke tool tetapi serupa.

    Contoh pesan email yang sederhana

    To : janet,abowd

    From : alan

    Subject : HCI book

    CC: R.Beale@cs.brum.ac.uk

    How are your chapters getting on?

    Could one of you meet me over lunch?

    I’m having trouble using the minipage environment doing illustrations of email messages.

    Secara teori dalam sudut pandang user, mekanisme pengiriman e-mail tidak perlu menjadi masalah yang perlu diperhatikan hanya penggunaan telepon. Mekanisme pengiriman e-mail membutuhkan delay dalam pengirimannya dan masalah ini tidak dapat diperkirakan dan sangat tergantung pada tingkat penggunaan komputer yang digunakan sebagai relay suatuy pesan.

    Dalam email yang sederhana hanya ada satu penerima. Banyak system email juga memiliki setting penerima lebih dari satu, selain penerima langsung (To:field), juga mereka yang menerima kopinya (Cc:). Sering user diseting dalam daftar distribusi yang berisi nama group dari sekelompok user yang sering mengirim e-mail. Dalam system ini pesan yang dikirimkan dialamatkan ke dalam suatu bulletin board atau newsgroup. Perbedaan utama antara email dan konferensi elektronik terdapat pada interface-nya, terutama untuk partisipan. Pertama, keragaman dalam mengontrol daftar distribusi. Beberapa daftar distribusi email bersifat privat ke pengirim, yaitu pengirim dapat banyak jumlahnya dan diketahui secara pasti siapa saja. Pada daftar distribusi bersifat bersama yaitu adanya penambahan dan perubahan yang dilakukan oleh system administrator. Pada bulletin board atau system news, penerima yang menentukan group news mana yang akan didaftar.

    Meskipun email antara lokasi membutuhkan waktu dalam ukuran menit atau hari untuk sampai, e-mail yang berbasiskan LAN dalam satu lokasi hanya membutuhkan beberapa detik. Untuk itu dimungkinkan adanya percakapan email. Khusus interface email tidak dirancang untuk perubahan ini, tetapi relative mudah untuk memliki urutan perubahan, misalnya setiap menit. Banyak system computer berbentuk komunikasi berbasis teks yang synchronous. Contoh : talk dalam system operasi unix atau phone pada mesin VAX. Pada system ini, layar terbagi ke dalam 2 bagian dan ketika kita mengetikkan sesuatu di bagian layar bawah, teman kita ada di layar atas, teman kita dapat melihat apa yang diketikkan oleh kita.

    Sistem Pesan Terstruktur

    Masalah yang umum yang biasa terjadi pada system email dan konferensi elektronik adalah overload. Masalah ini terjadi jika daftar peserta semakin panjang akan menyebabkan pesan email yang diterima juga menjadi besar. Hal ini dapat dicegah dengan adanya suatu newsgroup yang hanya punya beberapa kontributor yang aktif dan banyak pembaca meskipun belum memecahkan permasalahan. Beberapa bentuk system pesan terstruktur telah dikembangkan seperti Information Lens, suatu filter yang membagi pesan yang datang dalam beberapa kategori seperti kepentingan atau subyek masalah. Dalam pengiriman email terdapat beberapa field diantaranya : To, From, Subject. System pesan terstruktur memiliki tambahan field, domain khusus, diantaranya dengan Time, Place, Speaker dan Title.

    Type : seminar announcement

    To : all

    From : Alan Dix

    Subject : departemantal-seminar

    Time : 2:15 Wednesday

    Place : D014

    Speaker : W.T. Pooh

    Title : The Honey Pot

    Text : Recent research on socially constructed Meaning has focused on the image of the

    Honey Pot and its dialetic interpretation

    Within an encultured hermeneutic.

    This talk…

    Field-field tersebut membuat pesan lebih seperti record basis data khusus. Penerima dapat menyaring mail yang dating dengan query seperti basis data.

     

    Video Konferensi dan Komunikasi

    Ide pembuatan system ini yang berkomunikasi secara bertatapan langsung dengan media video dapat terwujud dengan dikenalnya system berbasiskan ISDN. ISDN ini yang mengubah hubungan kabel dengan koneksi digital. ISDN mempunyai bandwidth yang besar (64 kbaud) dalam koneksi telepon digital. Sistem ini tersedia untuk koneksi LAN antara komputer dengan koneksi video secara real-time.

    Penggunaan video digunakan untuk : video conference, peningkatan social komunikasi dan video terintegrasi dengan aplikasi lain. Semua ini dalam bentuk fasilitas synchronous remote.

    Video conference dalam CSCW tidak menggunakan komputer, meskipun komputer dan telekomunikasi mempunyai hubungan yang luas dan khusus dalam area CSCW. Sistem ini dihubungkan menggunakan jalur komunikasi khusus yang menggunakan sarana satelit sebagai penghubungnya.

    Satu kekurangan sistem ini adalah keterbatasan pengambilan kamera video, seperti ukuran dan kualitas pengambilan gambar. Kita perlu menentukan apakah yang mau diambil, kepala dan bahu saja, keseluruhan badan, atau kepala sampai kaki.

    Dalam system ini hal yang paling sulit didapat yakni eye contact. Masalah ini sangat penting dalam normal pembicaraan antar peserta. Cara untuk mengatasi masalah ini dengan menggunakan teknik video-tunnel. Sebuah half-silvered mirror digunakan sehingga kamera dapat melihat user jika ada di tangah layar.

     

    C

    mirror

    camera

    monitor

    half-silvered

    mirror

    Video Tunnel

    Meeting and Decision Support systems

    Dalam suatu perbincangan, peserta harus membentuk kesamaan pemahaman tentang tugas yang dikerjakan dan membangun ide. Yang perlu didiskusikan adalah pekerjaan yang kita lakukan dan ide pendukung apa untuk pekerjaan tersebut. Hal yang perlu didiskusikan yakni suatu system dimana membangun dan merekam ide menjadi suatu focus yang utama, ada 3

    tipe yaitu :

    • Argumentation

    tools

    Merekam semua argumentasi pada saat pengambilan dan mendukung secara prinsip team perancangan asynchronous co-located.

    • Meeting

    rooms

    Mendukung face-to-face groups (synchronous co-located) dalam brainstorming dan management meeting.

    • Shared drawing surfaces

    Dapat digunakan untuk perancangan meeting secara synchronous remote.

    Argumentation tools

    Termasuk dalam system groupware yang asynchronous co-located. Bagian penting lain dari CSCW adalah ketika suatu argumen perancangan digunakan untuk mengkomunikasikan keputusan diantara kelompok perancang. Komunikasi ini dalam bentuk dua arah dimana perancang dapat menambah argumen perancangan dan melihat masing-masing kontribusi.

    Argumentation support tool terkadang mirip struktur hypertext dan memungkinkan digunakan untuk mendukung merancang secara team semudah merancang secara perorangan.

    Tool yang canggih mempunyai fasilitas untuk dapat digunakan oleh beberapa perancang dalam waktu yang simultan. Tool ini harus memiliki mekanisme untuk menghentikan interferensi pekerjaan perancang yang berlainan, ini disebut dengan control konkurensi. Satu node harus dikunci yaitu ketika satu partisipan memulai untuk mengedit node, tidak boleh ada partisipan lain mengedit atau mengupdate node yang sama. Sebagai tambahan mekanisme penguncian, ada mekanisme notifikasi, yaitu suatu mekanisme yang memberitahu partisipan node yang mana yang sedang diedit. Contoh yang baik dari argumentation tool adalah Issue Based Information System (IBIS).

    Meeting Rooms

    Suatu ruang pertemuan yang dirancang menggunakan peralatan komputer untuk pertemuan face-to-face. Layout umumnya terdiri dari layar lebar, atau papan elektronik di salah satu dinding ruang, dengan kursi dan meja yang diatur sehingga semua partisipan dapat melihat

    ke layar tersebut. Rancangan ruang ini dapat berbentuk U atau C yang diatur mengelilingi layar monitor dan masing-masing peserta mempunyai masing-masing monitor.

    System ini mendukung beberapa bentuk pekerjaan seperti penggunaan terminal secara pribadi dan sub group pada kegiatan tele-conferencing atau email. System ini beroperasi dengan mode dimana semua layar peserta dan layar pada terminal pusat mempunyai tampilan yang sama. Hal ini dikenal dengan istilah WYSIWIS (what you see is what I see).

    Masalah pada system ini adalah jika beberapa peserta memutuskan untuk menulis pada waktu yang bersamaan sehingga system yang berbeda mengadopsi kebijakan control ruang (floor control policy) untuk menentukan partisipan mana dapat menulis saat itu. Kebijakan yang paling sederhana adalah menggunakan locking. Jika seorang partisipan ingin menulis ke layar, ia akan menekan satu kunci atau klik pada tombol di layar untuk meminta ruang.

    Jika tidak ada yang menggunakan, ia dapat melanjutkan dengan mengetik pada layar atau menggambar diagram jika didukung dengan tool grafik. Jika sudah selesai, ia dapat melepaskan ruang tersebut dengan menggunakan kunci lain atau pemilihan mouse. Jika ternyata ada peserta lain yang menggunakan ruang tersebut, ia harus menunggu hingga ruang dilepaskan.

    Shared Work Surface

    Idenya adalah mengubah menggunakan software yang sama yang berjalan pada satu meeting room, yang bekerja di beberapa tempat. Yaitu mengambil software meeting room yang synchronous co-located dan menggunakannya pada meeting synchronous remote.

    Untuk membuat efek whiteboard lebih nyata, beberapa system diatur sehingga para partisipan dapat menulis secara langsung ke layar besar. Tulisan ini akan difilmkan dengan kamera atau di capture secara digital dengan menggunakan layar yang sensitive.Tampilan tulisan satu partisipan akan ditampilkan ke layar peserta yang lain.

    Variasi yang lain dari shared work surface ini adalah dengan membuat partisipan menulis pada suatu kertas pada masing-masing desktop dan difilmkan dari atas. Gambar dari masing-masing peserta akan digabungkan dan ditampilkan pada masing-masing layar di area kerja partisipan. Para partisipan dapat saling melihat dan mengintegrasikan pekerjaannya melalui layar tersebut.

     

    Shared Application and Artefacts

    Beberapa system ini mempunyai kesamaan dalam teknologi seperti pada shared work surface tetapi system lebih difokuskan pada pekerjaan.

    Shared Pcs And Shared Window System

    Difokuskan pada pekerjaan yang dilakukan secara bersama-sama. Ide system ini adalah membuat beberapa komputer seolah-olah menjadi satu kesatuan. Apapun yang ditulis akan terlihat pada setiap terminal. Hal ini mirip pada meeting room tetapi tidak pada layar besar.

    Pada meeting room terdapat shared drawing surface sedangkan pada sharedPC hanya program yang berjalan. Software yang berbagi memantau keystrokes dan pergerakan mouse dan mengirimkannya ke semua computer sehingga sistemnya berperilaku sama, sehingga hanya ada satu keyboard dan satu mouse.

    Shared window system serupa tetapi tidak keseluruhan layar, window individu yang berbagi.

    Ketika user bekerja dengan window yang tidak berbagi, system berperilaku normal, tetapi ketika user memilih shared window, sistem mengintervensi.

    Kedua fasilitas ini dapat digunakan ada ruang yang sama, dimana sistem adalah synchronous co-located, tetapi dapat pula menjadi synchronous remote jika digabungkan dengan koneksi telepon atau video.

    Mempunyai dua kegunaan yakni :

    o Focus pada dokumen yang sedang dalam proses, contoh jika peserta sedang menggunakan program spreadsheet secara bersama untuk memecahkan persoalan keuangan.

    o Untuk technical support, contoh jika kita sedang mengalami kesulitan pada suatu aplikasi kemudian menelepon local technical guru yang akan terhubung dengan komputer kita, memeriksa dan memberikan saran perbaikannya.

    Shared Editors

    Editor ini dapat berbentuk text maupun grafik yang bekerja sama, yaitu yang saling berbagi.

    Ini ditandai dengan adanya beberapa insertion point, atau protocol penguncian yang lebih baik untuk perilaku editor. Software yang digunakan dalam meeting room dapat dianggap berupa shared editor dan banyak isu lain serupa tetapi tujuan dari shared editor adalah menggabungkan dokumen yang normal. Seperti sharedPC dan window, user diharapkan mempunyai pemahaman komunikasi yang sama, baik komunikasi secara face to face (co-located), saluran audio dan video atau sekurangnya pada komunikasi secara tekstual.

     

    Co-Authoring System

    Shared text editing merupakan kegiatan yang memerlukan waktu yang pendek, terjadi dalam rentang waktu paling lama beberapa jam. Co-authoring memerlukan waktu yang lebih lama, dalam minggu atau bulan. Shared editing merupakan suatu bentuk kerja yang synchronous sedangkan co-authoring merupakan bentuk asynchronous yang besar yang terkadang dalam periode tertentu melakukan kegiatan yang synchronous. Kegiatannya mungkin melibatkan shared editing tetapi jika benar, ini juga merupakan satu dari kegiatannya. Dalam kegiatannya mungkin seorang pengarang bekerja sama membuat suatu perencanaan, membagi kerja diantara mereka, kemudian saling memberi komentar mengenai pekerjaannya. Pada kenyataannya hal ini hanya merupakan suatu scenario dan bila salah satu hasilnya konsisten terhadap sejumlah studi individu dan kolaborasi penulisan, maka setiap orang dan setiap group akan berbeda.

    Co-authoring system harus memiliki beberapa concurrency control untuk membagi waktu ketika dua peserta berusaha mengedit teks yang sama dalam waktu yang sama.

    Shared Diaries

    Ide dari system ini adalah sederhana yakni setiap orang menggunakan shared electronic diary, hal ini berlaku sama jika menggunakan personal komputer dan pocket organizers. Jika ada seseorang ingin mengatur pertemuan maka system akan mencari diaries semua orang untuk menemukan waktu yang kosong.

    Communication Through The Artefact

    Dalam empat system yakni shared PCs and windows, shared editors, co-authoring systems and shared diaries – focus terjadi pada artefact dimana partisipan bekerja. Mereka bertindak pada artifacts dan berkomunikasi dengan yang lain tentang artifacts.

    Frameworks for Groupware

    Terdapat beberapa frameworks untuk dapat memahami aturan dari groupware. Satu diantaranya digunakan sebagai mekanisme yang dapat membantu dalam diskusi tentang groupware. Sebagai tambahan terdapat beberapa aplikasi tambahan untuk membantu merancang struktur dari system yang baru.

    Time/Space Matrix And Synchronous Working

     

    Co-located

    Remote

    Meeting rooms

    Video conferences, video-wall,

    etc

    Synchronous

    Shared work surfaces and editors

    Shared PCs and windows

    Argumentation tools

    Email

    and

    electronic

    asynchronous

    conferences

    Co-authoring systems, shared calendars

    Matriks ini menjadi bahasa yang umum digunakan pada lingkungan CSCW dan dapat digunakan selama perancangan sebagai salah satu keputusan awal untuk interaksi yang akan dirancang. Perancangan ruang untuk interaksi synchronous sangat berbeda dengan asynchronous.

    Perbedaan antara sistem email dan kebanyakan sistem co-authoring adalah bahwa co-authoring memiliki basis data tunggal yang berbagi. Jadi ketika partisipan bekerja sama mereka mengetahui bahwa mereka bekerja sama dan bergantung pada penggunaan penguncian, perubahan masing2 dapat terlihat. Perbedaan yang baik adalah dengan melihat data store dan mengklasifikasikan sistem sebagai tersinkronisasi yaitu jika ada koneksi computer yang real-time atau tidak tersinkronisasi.

    Untuk sistem yang tidak sinkron, ada sedikit perbedaan pada saat partisipan beroperasi pada waktu yang sama. Lokasi juga tidak terlalu penting. (sistem co-located yang tidak sinkron dimungkinkan pada 2 buah computer dalam satu ruangan yang tidak terhubung, dimana up date secara berkala dilakukan melalui transfer disket).

    Pada sistem yang sinkron, waktu penggunaan yang sebenarnya menjadi penting. Jika partisipan beroperasi pada waktu yang sama (akses konkuren), interaksi yang real time dapat terlihat pada meeting room (co-located) atau video conferences (remote).

    Alternatifnya, sistem melindungi user dari kerja pada waktu yang sama, dengan rentang penguncian yang cukup besar, menjadi bekerja yang tidak konkuren tersinkron. Karena partisipan dibuat untuk menggunakan sistem secara bergantian, ini disebut dengan akses berseri.

    Sistem co-author memiliki penguncian yang baik sehingga partisipan dapat menggunakan sistem pada saat yang sama maupun berlainan. Sehinggan akses sinkron yang berseri maupun konkuren dimungkinkan.

    Tabel berikut menempatkan system groupware ke dalam perbaikan matriks. Matriks ini tidak luas lagi digunakan tetapi masih akurat untuk menempatkan perancangan yang berprospek.

    Ini dapat dipertimbangkan jika sistem dirancang untuk user dengan computer mobile atau computer rumah. Ini tidak terhubung sama sekali ke pusat computer, kecuali dengan koneksi langsung yang dibuat, transfer disket atau dial-up modem. Sistem groupware yang ada yang mendukung user seperti ini adalah email dan sistem message, dan Liveware. Liveware adalah satu-satunya sistem groupware yang dirancang untuk kerjasama yang tidak sinkron.

    Co-located

    remote

    (a) Concurrent

    Meeting rooms

    Video conferences, video-

    synchronized

    wall,etc

    Shared work surfaces and editors

    Shared PCs and windows

    (a/b) mixed

    Co-authoring systems, shared calendars

    (b) serial

    Argumentation tools

    (c) unsynchronized

    Email and structured messages

    Electronic conferences

    Shared Information

    Konferensi elektronik dan shared workspaces berbagi informasi untuk komunikasi, dimana dokumen dibagi bersama untuk tujuan pekerjaan.

    Granularity

    System groupware yang telah dibahas berbeda sebagai suatu granularity yang sharing, dalam pengertian sebagai ukuran potongan suatu obyek dan kekerapan untuk memperbaharui.

    Pada ukuran potongan obyek, beberapa sistem beroperasi baik, mengijinkan partisipan mengedit kalimat yang sama, bahkan kata yang sama dalam kalimat. Pada sistem file yang berbagi, memiliki penguncian sehingga hanya satu user yang dapat mengedit file pada waktu yang sama. Granularity di sini adalah dokumen. Mayoritas dari sistem groupware khususnya argumentation dan co-authoring tool beroperasi di antaranya.

    Pada dimensi waktu, sistem dapat menunjukkan update-an partisipan ke partisipan yang lain dengan segera (hitungan detik) atau ketika user selesai mengedit potongan. Ukuran potongan yang baik membutuhkan update-an yang baik juga.

    IMK – GROUPWARE

     

    13 dari 23

    Dalam gambar tersebut terdapat perbedaan ukuran pilihan seperti : a) Shared editors

    b) Co-authoring systems seperti Quilt

    c) Network file system with locking

    d) Meeting system with floor holder

    Levels Of Sharing

    Merupakan system yang secara eksplisit digunakan pada groupware tetapi sangat umum digunakan pada shared database. Sebagai contoh dua orang yang mungkin melihat bagian dari suatu database yang sama tetapi satu orang melihatnya dalam bentuk grafik dan yang lain melihatnya dalam bentuk tabular, maka dapat dilihat dalam tiga level (tingkatan) seperti pada gambar di bawah ini :

    Group pointer mungkin dimiliki oleh peserta yang “cursor” nya tidak terlihat dan ada empat level dari input sharing yakni :

    Single insertion point

    • Shared virtual keyboard

    Multiple insertion points

    • Other participants visible

    • Group

    pointer

    • No

    visibility

    Ada koneksi yang antara 2 level sharing ini. Sistem anotasi dokumen memiliki insertion point yang terpisah tetapi view yang berbagi. Setiap user dapat memilih untuk menaik-turunkan view dokumen, tetapi akan menaik-turunkan semua user.

    Types Of Object

    Jenis dari suatu object atau data yang saling bekerja sama mempunyai efek dari suatu system bersama-“share”. Hal yang menjadi penting dalam kasus yang unsynchronized atau bahaya seperti ketika dua peserta sedang memperbaharui data secara simultan dan mengalami kebingungan untuk menentukan yang mana yang datang terlebih dahulu.

    Pada teks dalam editor bersama, partisipan dalam menambah, mengedit atau menghapus teks dimana pun dalam dokumen. Dikhawatirkan jika terjadi interferensi yaitu satu partisipan menghapus teks dimana partisipan lain sedang melakukan pengeditan. Pada transkrip teks linier yang dihasilkan dari sistem konferensi elektronik, transkrip bersifat monotonic yaitu hanya satu yang dapat ditambahkan, tidak bisa dihapus, dan kontribusi penambahan selalu dilakukan di akhir. Ini yang memudahkan penanganan update menjadi lebih mudah. Setiap waktu partisipan melengkapi kontribusi, penambahan dilakukan di akhir. Transkrip teks ini bersifat diurutkan, yang cocok dengan groupware yang sinkron.

    Pada hyperteks bersama, dengan tidak ada pengeditan dan penghapusan, hanya penambahan node baru. Ini tidak hanya monotonic tetapi juga tidak terurut. Kontribusi distrukturkan secara eksplisit oleh link antar node, bukan berdasarkan urutan kejadian.

    Model ini memiliki property penambahan yang lemah yaitu semua kontribusi baru dibiarkan berada pada hyperteks sehingga akan menjadi banyak. Struktur data monotonic yang tidak terurut cocok untuk groupware yang tidak sinkron, ini terdapat pada beberapa sistem konferensi elektronik.

    Whiteboard berbagi-shared whiteboard tanpa penghapus juga monotonic dan tidak terstruktur, tetapi ukuran tampilan yang terbatas tidak membuat layak untuk skala konferensi

    yang besar. Propertinya berguna ketika mengimplementasikan sistem seperti itu. Yang perlu diperhatikan dalam mengsinkronkan sistem adalah jika seorang partisipan menggunakan penghapus. Keuntungan lainnya adalah bahwa partisipan dapat menggunakan kedekatan dengan menunjukkan keterhubungan dan memisahkan area untuk tujuan yang berbeda.

    Partisipan dapat membuat strukturnya sendiri.

    Integrating Communication And Work

    System ini didukung oleh komputer yang mempunyai beberapa bagian-arcs seperti : Direct communication supported by email, electronic conferences and video connections.

    Common understanding supported by argumentation tools, meeting rooms and shared worksurfaces.

    Control and feedback from shared artefacts supported by shared PCs and windows, shared editors, co-authoring systems and shared diaries.

    understanding

    direct communication

    P

    P

    deixis

    control and

    feedback

    feedthrough

    A

    Deixis. Partisipan perlu mengacu ke item pada layar bersama, tetapi tidak bisa menggunakan jari2nya untuk menunjuk. Secara umum, komunikasi langsung tentang tugas akan mengacu ke artefact yang digunakan sebagai bagian dari tugas.

    Feedthrough. Manipulasi yang dilakukan oleh satu orang partisipan dalam dilihat oleh partisipan yang lain. Komunikasi melalui artefact antar partisipan menjadi penting.

    Secara umum, pengujian hasil groupware adalah seberapa baikkah ia mendukung keseluruhan kerja kooperatif. Contoh lain dari sistem adalah seberapa dekat integrasi komunikasi langsung dan berbagi artefact adalah co-authoring (Quilt).

    Sistem groupware tidak perlu mengotomasikan setiap aspek komunikasi dan berbagi kerja, tetapi perlu terbuka dalam mendukung keseluruhan kerja kooperatif. Misalnya barcode yang memiliki standar internasional. Barcode adalah bentuk deixis yang terkomputerisasi.

    Implementing Synchronous Groupware

    Sistem groupware mengalami masalah pada implementasi sistem yang sinkron dan lebih sulit dibandingkan sistem yang single-user. Misalnya dalam menangani update dari beberapa user seperti tidak mendapatkan struktur data internal atau layar user yang berantakan. Belum lagi ditambah dengan bandwidth yang terbatas dan penundaan dari jaringan yang digunakan untuk menghubungkan computer dan asumsi single-user dalam membangun tool grafik.

    Feedback And Network Delays

    Untuk memasukkan teks penundaan yang lebih besar dapat diterima seperti melakukan pengetikkan tanpa respon (umpan balik) dari layar. Pada gambar akan memerlukan waktu respon yang lebih cepat dibandingkan dengan teks. Sistem groupware biasanya melibatkan beberapa computer yang terhubung melalui jaringan. Jika loop umpan balik mencakup transmisi melalui jaringan, akan sulit mencapai waktu respon yang dapat diterima. Untuk melihat apa yang tejadi bila user menuliskan sebuah karakter : 1.

    Aplikasi user mengambil kejadian-event dari window manajer 2.

    user memanggil system operasi…..

    3.

    Yang mengirimkan pesan melalui jaringan, sering melalui serangkaian tingkatan protocol.

    4.

    Pesan akan diterima oleh system operasi pada remote machine, 5.

    Yang memberikan remote application untuk memproses.

    6-8. Mengulangi proses yang sama pada langkah (2-4) 9.

    Umpan balik akan diberikan pada layar user.

    Proses ini membutuhkan 2 pesan jaringan dan 4 pengubahan konteks antara sistem operasi dan program aplikasi dalam komunikasi normal antara manajer window dan aplikasi.

    Meskipun hanya dalam waktu minimum dan factor-faktor lain membuat gambaran menjadi buruk. Protocol jaringan dengan handshaking dapat menambah jumlah pesan jaringan minimal empat (2 pesan ditambah handshakes). Jika aplikasi berjalan pada mesin multi-tasking, perlu menunggu beberapa saat atau akan dibuang. Lalu lintas jaringan tidak mungkin hanya antara dua computer : dalam meeting room perlu banyak workstation.

    Arsitektur Groupware

    Terdapat dua major arsitektur alternatif untuk groupware yakni centralized (client-server architecture) dan replicated dengan beberapa variasi dari kedua bentuk tadi.

    . . .

    user 1

    user 2

    user n

    client 1

    client 2

    client n

    . . .

    server

    Gambar client-server architecture

    Dalam arsitektur terpusat atau arsitektur client-server, setiap workstation partisipan memiliki program minimal (client) yang menangani layar dan menerima input partisipan. Dalam aplikasi sebenarnya dijalankan oleh server yang bekerja pada computer pusat dan menangani semua data aplikasi. Arsitektur ini adalah yang paling sederhana untuk implementasi dengan beberapa front-end.

    Pada arsitektur master-slave, server bekerja pada salah satu workstation user dan memasukkan client, yaitu user yang pertama meminta aplikasi bersama. Master menjadi gabungan server-client dan slave menjadi client. User dari master akan memilki respon yang cepat dibandingkan dengan user lainnya.

    Pada arsitektur replikasi, masing2 workstation user menjalankan salinan aplikasi. Salinan ini berkomunikasi dengan yang lain dan berusaha membuat struktur datanya konsisten dengan yang lain. Setiap replikasi menangani respon usernya masing2 dan harus juga mengupdate layar dalam merespon pesan dari replikasi lainnya. Arsitektur ini sulit untuk deprogram.

    Solusi standar nya adalah dengan adanya rollback dari satu replica ke replica yang lain dan mengeksekusi ulang perintah. Jika hasil telah ditampilkan di layar user maka dianggap gagal

    – algoritma komputasi standar sering gagal untuk groupware. Keuntungan utamanya adalah dalam umpan balik local.

     

    Shared Windows Architectures

    Sistem ini mempunyai kesamaan dengan arsitektur groupware secara umum tetapi mempunyai beberapa feature tambahan. Gambar di bawah ini merupakan aplikasi pada single user yang normal yang berinteraksi melalui window manager (misalnya X) sepeti terlihat pada gambar di bawah ini. Manajer window bersama bekerja dengan menangkap panggilan-call antara aplikasi dan X.

    Ketika aplikasi mengirimkan panggilan grafik ke X, ia akan masuk ke potongan-stub aplikasi khusus. Ini kemudian melewatkan call grafik ke stub user pada setiap workstation partisipan.

    Salinan dari X akan tereksekusi pada setiap workstation dan stub user akan melewatkan call grafik ke salinan local X.

    user

    X

    Xevents

    Xlib calls

    application

    Single user application

    Secara sama maka keystroke pengguna dan beberapa tindakan menyebabkan X melewati stub user dan kemudian melalui stub applikasi ke aplikasi.

    user 1

    user 2

    user n

    . . .

    x

    x

    x

    Xevents

    Xlib calls

    user

    user

    user

    stub 1

    stub 2

    stub n

    . . .

    application

    stub

    Xevents

    Xlib calls

    application

    Shared window architecture

    Feedthrough And Network Traffic

    Telah didiskusikan bahwa feedback bagi user sangat diperlukan untuk mengetahui tindakan yang telah dilakukan dan melihat bahwa replikasi atau replikasi sebagian dapat menyelesaikannya. Hal ini sangat penting juga dilakukan adalah mengetahui feedthrough yang merefleksikan tindakan seorang user pada layar user yang lain sehingga dapat mengurangi trafik suatu jaringan.

    Graphical Toolkits

    Sebelumnya telah dibahas beberapa widget yang ditemukan pada graphics toolkit atau window manager seperti menu, tombol-button, dialogue box serta text dan graphic region.

    Semuanya ini berguna untuk membuat interface single user dan salah satunya menggunakan komponen yang sama untuk membentuk system groupware.

    Beberapa widget dapat menangani control aplikasi. Misalnya pada menu pop-up berikut : sel = do_pop_up(‘new”,”open”,”save”,”exit”,0); Secara fundamental fungsionalitas dari widget toolkit tidak mencukupi untuk groupware.

     

     

    Robustness And Scaleability

    Jika kita membuat aplikasi berbagi untuk pengujian suatu ide, atau untuk digunakan dalam eksperimen, maka kita dapat membuat asumsi-asumsi, misalnya jumlah partisipan yang tetap. Masalah yang timbul jika suatu system yang akan digunakan untuk pengujian selanjutnya atau untuk produksi secara komersial, maka standar keteknikan harus lebih tinggi. Ada 4 sumber masalah yang potensial, yakni :

    • Kesalahan pada jaringan, workstation atau system operasi

    • Kesalahan memprogram shared application

    • Urutan kegiatan yang tak terduga seperti race condition

    • System tidak dapat mengukur jumlah user atau rerata kenaikan kegiatan.

    Ini berhubungan dengan software engineering, real-time dan distributed programming.

    Server Faults

    Masalah yang paling besar terjadi pada system yang berbasiskan pada client-server adalah bila terjadi server crash, baik pada software maupun hardware. Banyak basis data komersial besar memiliki fasilitas (log transaksi) untuk memperbaiki semuanya dan juga perubahan sesaat yang terjadi. Jika sistem groupware tidak dibangun dengan menggunakan sistem tersebut maka solusi serupa dapat diaplikasikan misalnya secara berkala menyimpan state saat itu menggunakan 2 atau 3 file secara rotasi. Dalam system groupware, hal ini dapat dicegah misalnya dengan memiliki multi server dan salinan data sehingga server backup dapat mengambil alih setelah terjadi crash pada server utama.

    Workstation Faults

    Kerusakan ini berupa kesalahan kode karena sangat kompleks seperti misalnya penggunaan program yang menangani interaksi user dan dibuat dengan menggunakan graphical toolkit yang kompleks. Tentu saja, program perlu dibuat secara hati-hati dan menghindari kesalahan tetapi pengalaman menunjukkan bahwa hal ini sulit dihindari. Pencegahan dilakukan secepat mungkin dan bila menggunakan arsitektur client-server maka terdapat tiga

    “R” untuk server yakni :

    Robust, kerusakan pada client seharusnya tidak menyebabkan server menjadi “hang”.

    Secara khusus, server tidak boleh menunggu respon dari client. Server seharusnya event-driven atau poll client menggunakan operasi jaringan non-blocking.

    Reconfigure, server harus mendeteksi kesalahan yang terjadi pada client dan reconfigure keseluruhan system. Kesalahan client bisa dideteksi dengan kode kesalahan jaringan standar, atau dengan pewaktuan client jika terlalu lama. Konfigurasi ulang meliputi set ulang

    dari struktur data internal dan menginformasikan partisipan lain bahwa partisipan yang lain tidak ada dan alasannya.

    Resynchronize, ketika workstation/client merecover maka server harus mengirimkan informasi yang cukup untuk menyusul. Secara normal server mengirimkan informasi yang selalu bertambah sehingga membuat server selalu berada pada posisinya untuk dikirimkan ke client yang diperbaiki.

    Algorithm Faults

    Beberapa aplikasi yang crash tidak menyebabkan aplikasinya menjadi rusak dan kemungkinan akan menyebabkan lebih sulit lagi mendeteksinya. Sebagai contoh struktur data antara replicates atau antara client dan server kemungkinan akan menyebabkan tidak konsisten. Hal ini tidak mungkin terjadi bila algoritma yang diterapkan benar.

    Unforeseen Sequences Of Events

    Pemrograman terdistribusi banyak mempunyai masalah yang dikenal dengan istilah deadlock. Hal ini terjadi jika terdapat dua atau lebih proses masing-masing saling menunggu untuk melakukan sesuatu. Kemungkinan deadlock sering tidak terdeteksi selama pengujian karena sistem operasi dan buffer jaringan. Karena beban meningkat menyebabkan buffer penuh dan deadlock tidak bisa terhindari. Aturan pertama untuk mencegah deadlock adalah jangan pernah menghalangi input atau output, yaitu gunakan pewaktuan. Pada tingkatan yang tinggi, salah satunya seharusnya juga mencegah membuat asumsi tentang urutan kejadian yang datang. Asumsi yang umum pada program groupware adalah pesan yang dikirim dari satu komputer akan tiba dalam bentuk yang sama pada komputer lain. Ini bergantung pada protocol yang digunakannya.

    Scaling up

    Cara yang paling umum untuk mencegah kesalahan algoritma adalah menggunakan algoritma yang sederhana seperti menggunakan tabel dibandingkan struktur data yang rumit, ukuran panjang suatu field yang tetap untuk nama-nama dan pesan. Ini dapat mengurangi beberapa kesalahan sebelumnya dan merupakan teknik yang direkomendasikan untuk prototype aplikasi. Jika sistem membangun algoritma awal maka struktur data perlu pula dikembangkan. Hal ini sangat mudah diwujudkan jika ukuran dari suatu system dipertimbangkan dari awal perancangan.

    Testing For Robustness

    Terkadang fungsi dari suatu aplikasi diuji dengan menggunakan beberapa window pada workstation yang sama, yang masing-masing bertindak sebagai user yang berbeda.

    Kerusakan dan beberapa kesalahan yang penting dapat disimulasikan dengan mencoba melakukan reboot dari workstation atau melepaskan konektor jaringan atau cara yang lebih halus dengan cara menghentikan proses suatu client dan melihat efeknya pada server. Cara yang lain adalah simulasi untuk ‘race condition’ dan urutan yang ganjil dengan menjalankan sistem diantara 2 workstation kemudian tekan kunci panel secara simultan.

    Latihan

    1. Sistem email yang berbicara memungkinkan pengiriman dalam waktu cepat urutan pengirimannya. Sistem ini berbentuk :

    a. Komunikasi asynchronous

    b. Sistem struktur pesanan

    c. Komunikasi synchronous

    d. Adanya sistem video konferensi

    2. Post it notes merupakan model komunikasi : a. Asynchronous co-located

    c. Synchronous remote

    b. Sycnhronous co-located

    d. Asynchronous remote

    3. Pernyataan yang salah tentang deadlock : a. Terjadi karena ada 2 atau lebih proses yang saling menunggu b. Aturan pertama adalah jangan pernah menghalangi input atau output c. Mencegah membuat asumsi tentang urutan kejadian yang datang d. Cara yang paling umum untuk mencegah kesalahan algoritma 4. Cara untuk mengatasi masalah eye-contact adalah : a. Video tunnel

    c. Video conference

    b. Video connection

    d. Tidak ada yang benar

    5. Yang bukan termasuk dalam 3R untuk server pada pencegahan workstation faults adalah :

    a.

    Reorganize

    c.

    Reconfigure

    b.

    Resynchronize d

    Robust

    IMPLEMENTATION SUPPORT
    /* Style Definitions */
    table.MsoNormalTable
    {mso-style-name:”Table Normal”;
    mso-tstyle-rowband-size:0;
    mso-tstyle-colband-size:0;
    mso-style-noshow:yes;
    mso-style-priority:99;
    mso-style-qformat:yes;
    mso-style-parent:””;
    mso-padding-alt:0cm 5.4pt 0cm 5.4pt;
    mso-para-margin-top:0cm;
    mso-para-margin-right:0cm;
    mso-para-margin-bottom:10.0pt;
    mso-para-margin-left:0cm;
    line-height:115%;
    mso-pagination:widow-orphan;
    font-size:11.0pt;
    font-family:”Calibri”,”sans-serif”;
    mso-ascii-font-family:Calibri;
    mso-ascii-theme-font:minor-latin;
    mso-hansi-font-family:Calibri;
    mso-hansi-theme-font:minor-latin;}

    Dua Sifat Dari Sistem Window

    Kebebasan dari perangkat keras. Workstation khusus akan berinteraksi dengan beberapa layar display visual, papan ketik dan biasanya beberapa perangkat penunjuk seperti mouse.

    Keberagaman dari perangkat keras ini dapat digunakan pada setiap system interaktif dan semuanya berbeda dalam hal data yang dikomunikasikan dan perintah yang digunakan.

    Untuk itu, pemrogram membutuhkan suatu perintah langsung ke suatu terminal abstrak yang mengerti dengan bahasa yang generic dan dapat diterjemahkan ke bahasa dari banyak perangkat khusus lainnya. Selain membuat tugas pemrograman lebih mudah, terminal abstrak memungkinkan portabilitas dari program aplikasi. Hanya satu program terjemahan –

    device driver – butuh dituliskan untuk perangkat keras khusus dan kemudian setiap program aplikasi dapat mengaksesnya. Bahasa generik untuk terminal abstrak pada system window disebut dengan imaging model, beberapa diantaranya : pixels, graphical kernel system (GKS), programmer’s hierarchical interface to graphics (PHIGS), postscript.

    Sistem window menyediakan kemampuan berbagi sumber dari satu konfigurasi perangkat keras dengan beberapa salinan terminal abstrak. Masing2 terminal abstrak berlaku sebagai proses bebas dan system window akan mengkoordinasikan control dari proses yang ada.

    System window juga perlu untuk menampilkan aplikasi yang terpisah dengan mendedikasikan daerah dari layar display ke setiap terminal abstrak. Tugas koordinasi berhubungan dengan menyelesaikan konflik display ketia daerah layar yang terlihat dari dua terminal abstrak saling tumpang tindih.

    Application

    Application

    Application

    program

    program

    program

    Multiple

    Application

    Control

    Windowing

    System

    Device

    Independence

    Win.

    Win. 2

    1

    Mouse

    Keyboard

    Win.

    n

    Gambar 1. The Roles of Windowing System

    Arsitektur dari Sistem Window

    Clients

    Client

    Client

    Client

    Application

    Application

    Application

    1

    2

    n

    Abstract

    Abstract

    Abstract

    Terminal

    Terminal

    Terminal

    1

    2

    n

    Server

    Resource Manager

    Device Driver

    Devices

    Win.

    Win. 2

    1

    Mouse

    Keyboard

    Win.

    Bass dan Coutaz mengidentifikasikan ada 3 arsitektur yang mungkin bagi perangkat lunak untuk mengimplementasikan role dari system window. Semua ini diasumsikan bahwa device driver terpisah dari program aplikasi. Pilihan pertama adalah untuk mengimplementasikan dan replikasi manajemen dari proses yang multiple dalam setiap aplikasi yang terpisah.

    Arsitektur ini tidak terlalu baik karena mendorong setiap aplikasi untuk melihat masalah yang sulit dari penyelesaian konflik sinkronisasi dengan perangkat hardware yang berbagi. Juga mengurangi portabilitas dari aplikasi yang terpisah. Pilihan kedua adalah mengimplementasikan aturan manajemen dalam kernel system operasi, memusatkan tugas manajemen dengan membebaskan dari aplikasi individual. Aplikasi masih harus dibangun dengan system operasi khusus. Pilihan ketiga adalah portabilitas, fungsi manajemen ditulis sebagai aplikasi yang terpisah sehingga dapat menyediakan interface ke program aplikasi lain yang generic terhadap semua system operasi. Pilihan terakhir adalah model arsitektur client-server seperti gambar di atas. Dalam prakteknya, pembagian dari arsitektur ini tidak terlalu jelas dan setiap aplikasi interaktif atau kumpulan operasi aplikasi dalam system window berbagi fitur dengan salah satu dari ketiga aritektur konseptual tersebut. Sehingga, perlu ada satu komponen yaitu aplikasi atau proses yang terpisah bersama dengan beberapa pendukung system operasi yang siap dan pendukung aplikasi yang hand-tuned untuk menangani sumber bersama. Aplikasi yang dibuat untuk system window yang berbasis pada model client-server tidak terlalu portable. Contoh dari system window berbasis arsitektur client-server adalah system window X release 11 standar industri X11, dibuat di MIT pertengahan 1980an.

    Memprogram Aplikasi

    Aplikasi yang interaktif umumnya user-driven, aksi aplikasi yang ada ditentukan oleh input yang diterima dari user. Ada 2 paradigma pemrograman yang dapat digunakan untuk mengorganisasikan alur control dalam aplikasi. Paradigma pertama adalah Read-Evaluation Loop, yang internal terhadap program aplikasi itu sendiri. Contoh pada pemrograman Macintosh. Server mengirim input user sebagai event terstruktur ke aplikasi client. Fokus server yang penting adalah pada event dari client yang harus diarahkan. Aplikasi client diprogram untuk membaca setiap event yang melaluinya dan menentukan semua perilaku aplikasi khusus yang menghasilkan respon. Alur logika dari aplikasi client dalam pseudocode dan diagram adalah :

    repeat

    read-event(myevent)

    case myevent.type

    type_1 :

    do

    type_1

    processing

    type_2 :

    do

    type_2

    processing

    .

    .

    type_n :

    do

    type_n

    processing

    end case

    end repeat

    Client

    Application

    Start

    Read input

    Server

    Device

    Process input

    Quit?

    End

    Aplikasi memiliki control yang lengkap terhadap proses event yang diterima. Pemrogram harus mengeksekusi control melalui setiap kemungkinan event yang client akan terima.

    Pada macintosh, MacApp.

    Paradigma pemrograman lainnya adalah berbasis notifikasi, dimana loop control utama untuk proses event tidak ada dalam aplikasi. Pusat notifier menerima event dari system window dan menyaringnya ke program aplikasi dengan suatu program seperti terlihat pada gambar di bawah. Program aplikasi menginformasikan ke notifier event apa yang penting dan masing2 event mendeklarasikan satu prosedurnya sebagai callback sebelum mengubah kontrolnya ke notifier. Ketika notifier menerima event dari system window, terlihat jika event diidentifikasi oleh program aplikasi maka notifier akan melewatkan event dan control ke prosedur callback yang diregistrasi untuk event. Setelah pemrosesan, prosedur callback mengembalikan control ke notifier, memberitahukan untuk melanjutkan event yang diterima atau meminta diakhiri.

    Alur control terpusat di notifier yang membebaskan program aplikasi dari proses yang terlalu banyak dari setiap proses event yang lewat dari system window. Misalkan program aplikasi akan menghasilkan kotak dialog pre-empsi dan menginginkan adanya konfirmasi dari user sebelum diproses. Dialog pre-empsi menghapus secara efektif semua aksi user kecuali yang dibutuhkan user untuk memperbaikinya.

    Application

    Notifier

    Start

    Register callbacks

    with notifier

    Call notifier

    End

    Read input

    Process event

    Send to

    appropriate

    callback

    Callback

    Request

    quit ?

    No

    Yes

    Pada paradigma loop read-evaluation, ini langsung dikerjakan. Jika kesalahan dideteksi, aplikasi memulai loop read-evaluation yang ada dalam cabang statement case. Pada loop tersebut, semua event yang tidak relevan dapat diterima dan dihapus. Pseudocode nya adalah :

    repeat

    read-event(myevent)

    case myevent.type

    type_1 :

    do

    type_1

    processing

    type_2 :

    if (error-condition) then

    repeat

    read-event(myevent2)

    case myevent2.type

    type_1 :

    type_n :

    end case

    until (end-condition2)

    end

    if

    …..

    type_n :

    do

    type_n

    processing

    end case

    until (end-condition)

    Pada paradigma berbasis notifikasi, dialog pre-empsi tidak sederhana, karena alur control diluar dari pemrogram aplikasi. Prosedur callback harus dimodifikasi semua untuk megenal situasi dimana dialog pre-empsi diperlukan dan pada situasi tersebut dihapus semua event yang dilewatkan kepadanya oleh notifier.

    User Interface Management Systems (UIMS) Set dari pemrograman dan teknik desain yang dapat menambah level lain dari servis untuk desain system interaktif selain level toolkit adalah system manajemen interface user (UIMS) ini. Focus utama dari UIMS :

    • Arsitektur konseptual untuk struktur dari system interaktif yang dikonsentrasikan pada pemisahan semantic aplikasi dan presentasi

    • Teknik untuk mengimplementasikan aplikasi dan presentasi secara terpisah

    • Teknik pendukung untuk menangani, mengimplementasikan, dan mengevaluasi lingkungan interaksi yang sedang berjalan.

    UIMS Sebagai Arsitektur Konseptual

    Isu utama adalah bagaimana memisahkan antara semantic aplikasi dan interface yang tersedia bagi user. Banyak argument yang baik untuk mendukung pemisahan ini, yaitu : Portability : agar aplikasi yang sama dapat digunakan di system yang berbeda maka membuat aplikasinya sebaiknya terpisah dari interface device-dependent-nya.

    Reusability : pemisahan meningkatkan komponen untuk dapat digunakan kembali agar dapat mengurangi biaya.

    Multiple interfaces : untuk meningkatkan fleksibilitas aplikasi yang interaktif, beberapa interface yang berbeda dibuat untuk mengakses fungsionalitas yang sama.

    Customization : interface user dapat dikustom oleh desainer dan user untuk meningkatkan keefektifan tanpa mengubah aplikasi.

    Sekali aplikasi dan presentasi dipisahkan, komunikasi antara keduanya perlu dipertimbangkan, ini yang disebut sebagai control dialog. Secara konseptual, ada 3

    komponen utama dari system interaktif – aplikasi, presentasi dan control dialog.

    Komponen logika dari UIMS :

    • Presentasi : komponen bertanggungjawab atas tampilan interface, termasuk output dan input yang tersedia bagi user.

    • Control dialog : komponen mengatur komunikasi antara presentasi dan aplikasi.

    • Interface aplikasi : pandangan dari semantic aplikasi yang disediakan sebagai interface.

    Model Seeheim berikut memasukkan aplikasi dan user dalam konteks dari system interaktif meskipun tidak secara eksplisit karena hanya memodelkan komponen logika UIMS bukan system interaktif secara keseluruhan. Dengan tidak membuat aplikasi secara eksplisit ada di model, control dialog eksternal perlu diasumsikan. Dari sudut pandang pemrogram, model Seeheim ini sesuai dengan adanya pembedaan antara lapis leksikal klasik, sintaksis dan semantic dari sistem komputer. Masalah utama dari model Seeheim ini adalah meskipun terlayani baik pada akhirnya, tetapi tidak terlihat bagaimana arah sebenarnya dari kemungkinan UIMS distrukturkan. Gambar tersebut menunjukkan alasan efisiensi yang mungkin dengan dilewatkan/ dihindarkannya komponen control dialog secara eksplisit sehingga aplikasi memberikan respon semantic aplikasi yang lebih besar. Kotak kosong tersebut ada karena logika tidak dipisahkan dari implementasi. Selain itu model Seeheim

    tidak menginformasikan bagaimana membangun system interaktif yang besar dan kompleks dari komponen yang lebih kecil.

    Lexical

    Syntactic

    Semantic

    Presentation

    Dialogue

    App.

    Intended

    Component

    Control

    Interface

    Intended

    User

    App.

    Model

    Paradigma Model-View-Controller (MVC) menangani masalah Seeheim di atas. Pada pemrograman Smalltalk, link antara semantic aplikasi dan presentasi dapat dibangun dari tiga serangkai MVC ini. Smalltalk adalah system pemrograman berorientasi objek yang berhasil membangun system interaktif baru berdasarkan system yang sudah ada.

    View

    Display

    User

    Model

    Mouse

    Controller

    Keyboard

    Model MVC menunjukkan semantic aplikasi, view menangani output grafik atau teks dari aplikasi dan pengontrol menangani input. Perilaku dasar dari model ini adalah view dan pengontrol ditempelkan/ dimasukkan dalam kelas objek umum dari Smalltalk yang diwariskan dari instant dan dimodifikasi.

    Model Coutaz berikut merupakan system interaktif berasitektur multi-agent, disebut model Presentation-Application-Control (PAC). Model ini berbasis tiga serangkai pula, semantic aplikasi dilambangkan dengan komponen abstraksi, input dan output digabungkan dalam satu komponen presentasi dan ada komponen control eksplisit yang menangani dialog dan menghubungkan aplikasi dan presentasi.

    Abstraction

    Presentation

    User

    Control

    Ada 3 perbedaan penting antara PAC dan MVC. Pertama adalah PAC menggabungkan input dan output, MVC memisahkannya. PAC menyediakan komponen eksplisit yang tugasnya melihat kekonsistenan antara abstraksi dan presentasi, dimana MVC tidak menugaskan ke salah satu komponen. PAC tidak berhubungan dengan lingkungan pemrograman apapun, secara kondusif merupakan pendekatan berorientasi objek.

    Perbedaan yang terakhir ini yang membuat PAC mudah mengisolasi komponen control; PAC

    lebih merupakan arsitektur konseptual dibandingkan MVC karena kurang implementation-dependent.

    Latihan

    1. Yang bukan merupakan komponen dari UIMS adalah : a.

    Presentasi

    c.

    Kontrol

    dialog

    b.

    Interface

    aplikasi

    d.

    Viewer

    2. Yang termasuk elemen dari sistem window, kecuali : a.

    Device driver

    c. Terminal b. Resource sharing d. Toolkit

    3. Dalam model Seeheim, level sintaksis merupakan komponen logika UIMS untuk : a.

    Input

    c.

    Kontrol

    dialog

    b.

    Presentasi

    d.

    Interface

    aplikasi

    Komponen logika pada UIMS pada presentasi merupakan: a. Sebuah komponen yang bertanggung jawab pada penampilan dari interface.

    b. Sebuah komponen yang mengatur komunikasi antara presentasi dan aplikasi.

    c. Pandangan dari sebuah aplikasi semantik yang menyediakan sebuah interface d. Teknik yang mendukung untuk mengatur, implementasi dan evaluasi sebuah run time interaction environtment.

    5. Komponen logika pada UIMS pada kontrol dialog merupakan: a. Sebuah komponen yang mengatur komunikasi antara presentasi dan aplikasi.

    b. Pandangan dari sebuah aplikasi semantik yang menyediakan sebuah interface c. Teknik yang mendukung untuk mengatur, implementasi dan evaluasi sebuah run time interaction environment

    d. Sebuah komponen yang bertanggung jawab pada penampilan dari interface

     

    HELP DAN DOKUMENTASI

    Tinjauan

    • User mempunyai perbedaan kebutuhan di waktu yang berbeda

    • User support seharusnya :

    o Tersedia tetapi tidak mencolok

    o Akurat dan kuat

    o Konsisten dan fleksibel

    • Jenis-jenis user support :

    o Command based methods

    o Context-sensitive

    help

    o Tutorial

    help

    o On-line

    documentation

    o Intelligent

    help

    • Merancang user support harus memperhatikan : o Presentasi

    o Implementasi

    Pendahuluan

    Ada sebagian pendapat menyatakan bahwa system yang interaktif dijalankan tanpa membutuhkan bantuan atau training. Hal ini mungkin ideal akan tetapi jauh dari kenyataan.

    Pendekatan yang lebih membantu adalah dengan mengasumsikan bahwa user akan membutuhkan bantuan pada suatu waktu dan merancang bantuan (help) ini ke dalam system.

    • Ada empat jenis bantuan yang dibutuhkan user : o Quick

    reference

    Digunakan sebagai pengingat untuk user dari tool yang detail yang secara dasar sangat familiar dan biasa digunakan. Seperti menggunakan opsi perintah umum, atau mengingatkan user akan sintaks dari perintah.

    o Task-specific

    help

    Membantu user menghadapi masalah atau tidak pasti dalam mengambil tindakan memecahkan masalah yang khusus atau tidak pasti dalam mengaplikasikan tool.

    Full explanation

    Suatu alat bantu atau perintah yang dapat membantu memahami secara lengkap.

    Penjelasan ini mencakup informasi dimana user tidak membutuhkannya pada saat itu.

    o Tutorial

    Khusus untuk user baru yang menyediakan perintah secara step by step bagaimana menggunakan tool.

    Setiap tipe pendukung user ini dibutuhkan oleh user pada saat yang berbeda berdasarkan pengalaman user dengan system dan memenuhi kebutuhan yang berbeda. Ada banyak informasi yang user inginkan – definisi, contoh, kesalahan yang dikenal dan informasi memperbaiki kesalahan, opsi perintah dan lain-lain. Beberapa diantaranya ada yang tersedia dalam perancangan interface nya sendiri dan ada yang dimasukkan dalam ‘bantuan’ atau system pendukung.

    Perbedaan utama antara system ‘bantuan’ dan dokumentasi adalah bahwa system ‘bantuan’

    berorientasi terhadap masalah dan khusus, sedangkan dokumentasi berorientasi terhadap system dan umum.

    Kebutuhan Pendukung User

    Availability

    User dapat menggunakan bantuan pada setiap waktu selama berinteraksi dengan sistem.

    User tidak perlu keluar dari aplikasi selama bekerja untuk membuka aplikasi bantuan.

    Idealnya, bantuan berjalan konkuren dengan setiap aplikasi.

    Accuracy dan Completeness

    Bantuan ini seharusnya menyediakan keakuratan dan kelengkapan sistem bantuan. Agar refleksi akurasi tersedia pada keadaan system bantuan perlu mencakup keseluruhan system. Kelengkapan sangat penting jika bantuan tersedia untuk digunakan secara efektif. Perancang tidak dapat memprediksi bagian sistem user yang mana yang membutuhkan bantuan.

    Consistency

    Seperti diketahui bahwa user membutuhkan tipe yang berbeda dari bantuan untuk digunakan pada tujuan yang berbeda. Hal ini dapat secara tidak langsung menyebabkan

    sistem bantuan tidak dapat bekerja. Sistem bantuan yang tersedia harus konsisten terhadap semua sistem yang ada dan juga pada sistem itu sendiri. Bantuan online juga harus konsisten dengan dokumentasi kertasnya, konsisten dalam isi, terminologi dan bentuk presentasi. Pendukung user internal dalam aplikasi juga perlu konsisten terhadap sistem.

    Robustness

    Sistem bantuan ini biasanya digunakan oleh orang yang sedang dalam kesulitan karena system mempunyai perilaku yang tidak diharapkan atau mempunyai kesalahan. Hal ini sangat penting dimana sistem bantuan seharusnya robust-kuat baik dalam hal memperbaiki kesalahan dan perilaku yang tidak diharapkan.

    Flexibility

    Sistem bantuan yang fleksibel akan membuat setiap user dapat beinteraksi dalam mencari sesuatu yang sesuai dibutuhkannya. Sistem bantuan yang fleksibel membantu setiap user berinteraksi sesuai dengan keinginannya. Mulai dari perancangan sistem bantuan yang interaktif secara modular melalui bantuan context-sensitive untuk membuat sistem bantuan yang dapat diadaptasi atau pintar yang menginfer keahlian dan tugas user.

    Unobtrusiveness

    System ini seharusnya tidak mencegah user dalam melanjutkan pekerjaannya atau terpengaruh dengan aplikasi user. Pada satu saat, system bantuan teks pada interface yang bukan window dapat menginterupsi pekerjaan user. Untuk menghindari ini digunakan presentasi pada layar yang terpisah. Pada saat yang lain, system bantuan pintar dalam menyediakan bantuan atas inisiatif sendiri, bukan permintaan user.

    Pendekatan-pendekatan Pendukung User

    Command Assistance

    Mungkin pendekatan yang umum untuk user support adalah menyediakan bantuan pada level command, user yang membutuhkan bantuan pada command yang khusus dan ditampilkan pada layar bantuan atau pada manual page yang menjelaskan tentang command tersebut.

    Contoh pada UNIX man help dan DOS help command.

    Tipe ini sederhana dan efisien jika user mengetahui apa yang user ingin ketahui dalam mencari informasi yang lebih detail. Diasumsikan bahwa user mengetahui apa yang dicari. Pada system computer yang kompleks, ada beberapa perintah yang user ketahui dengan baik dan dapat menggunakannya dan ada pula beberapa perintah yang jarang digunakan.

    Command Prompts

    Menyediakan bantuan ketika user menemukan kesalahan, biasanya dalam bentuk prompt perbaikan. Prompt sangat berguna jika kesalahan sederhana misalnya kesalahan sintaks, tetapi knowledge-pengetahuan dari perintah harus diasumsikan. Bentuk yang lain dari command prompt adalah penggunaan menu dan icon yang dipilih. Ini memerlukan bantuan ke memori seperti membuat secara eksplisit perintah2 apa yang tersedia pada waktu tertentu. Ini diasumsikan juga memerlukan sejumlah pengetahuan tentang kegunaan perintah sehingga pendukung tambahan masih diperlukan.

    Context-sensitive Help

    Berbentuk menu based system yang menyediakan bantuan pada menu option. Mulai dari yang memiliki pengetahuan khusus dari user khusus hingga tersedianya kunci bantuan sederhana yang diinterpretasikan sesuai dengan konteks yang akan dipanggil dan akan ditampilkan. Contoh perintah help pada editor spy dan bantuan Ballons pada Macintosh.

    On-line Tutorial

    Mengijinkan user bekerja melalui aplikasi dasar dalam lingkungan percobaan. User dapat melihat kemajuan sesuai dengan kecepatan dan dapat mengulangi bagian dari tutorial yang diinginkan. User juga dapat merasakan bagaimana aplikasi bekerja dengan bereksperimen langsung dengan contoh-contoh. Kebanyakan on-line tutorial tidak pintar karena tidak mempunyai pengetahuan tentang user dan pengalaman user sebelumnya ataupun domain atau bentuk pembelajaran. On-line tutorial tidak fleksibel dan sering dilupakan, beberapa akan mengalami kesalahan dalam memperbaiki jawaban masalah, sederhana karena tidak diformat untuk itu.

    On-line Documentation

    Membuat efektif dengan membuat dokumentasi di kertas tersedia di komputer. Ini membuat materi tersedia terus menerus bersamaan dengan pada saat user bekerja bahkan sejumlah besar user bekerja secara konkuren. Dokumentasi dibuat untuk menyediakan deskripsi dari fungsionalitas dan perilaku system secara sistematik.

    Sistem Bantuan Pintar – Intelligent Help System Pada system computer yang kompleks atau besar, user akan terbiasa dengan subset dari fungsionalitas, demonstrasi keahlian dalam beberapa aplikasi dan tidak adanya keahlian dengan yang lain, bahkan kesadaran keberadaannya. User yang berbeda-beda akan memiliki kebutuhan dan level pemahaman yang berbeda. System bantuan pintar dibuat untuk mengatasi masalah ini dengan mengadaptasikan bantuan yang disediakan untuk user individual yang membuat permintaan dan secara aktif memberikan pelajaran alternative dari aksi yang user tidak sadari.

    Bantuan pintar adalah kasus khusus dari kelas system interaktif yang umum, dikenal dengan system pintar. Bantuan ini meliputi system pintar dengan domain khusus, system tutor yang pintar dan interface adaptif umum.

    Dioperasikan dengan memonitoring aktivitas user dan mengkonstruksikan model sesuai dengan user. Model ini termasuk pengalaman, preferences, kesalahan user atau kombinasi dari semuanya. Dengan menggunakan knowledge-pengetahuan ini bersama dengan pengetahuan dari domain dimana user bekerja dan kadang-kadang strategi tutorial atau advisor umum, system bantuan pintar akan mempresentasikan bantuan yang relevan dengan tugas user dan disesuaikan dengan pengalamannya.

    Knowledge Representation : User Modelling Pada banyak system, model ini adalah pandangan perancang untuk user dan diimplisitkan dalam perancangan. Perancang memiliki pemikiran user ‘khusus’ dan membangun interfacenya. Jika perancang selesai dengan pekerjaan ini, model menjadi sangat efektif.

    Tetapi perlu diasumsikan bahwa semua user adalah sama dan memiliki permintaan yang sama. Sistem yang lain mengijinkan user untuk membuat model dirinya dimana system dikonfigurasikan. Contoh sederhana pada .profile nya unix yang dapat dieksekusi ketika user masuk ke system dan menseting system dan variabel2 nya sesuai dengan keinginan user, disebut system yang adaptable. Pendekatan yang lain dalam menyediakan system dengan model user dan menggunakannya pada system bantuan pintar, adalah dengan memiliki konstruksi system dan menangani model user berdasarkan data yang dikumpulkan sedikit demi sedikit dari pemantauan interaksi user. Ada sejumlah pendekatan model user dikonstruksi dan dipantau, yaitu :

    Quantification

    Model yang paling sederhana dari user modelling yang menggunakan jumlah tingkatan dari keahlian yang akan merespon dalam cara yang berbeda. User ditempatkan pada satu level dan berpindah diantara level lainnya berdasarkan pengukuran kuantifikasi dari keahliannya pada waktu tersebut. Kegiatan2 yang berbeda dibobotkan dan user dinilai berdasarkan bobot dari aktifitas yang diambil. Jika nilai melebihi batas tertentu, user dipindahkan ke level keahlian yang lain dan system beradaptasi untuk itu. Contoh : Mason mengadaptasikan presentasi prompt perintah dari level keahlian user.

    Move from Level 1 to Level 2

    If

    The system has been used more than twice (0.25) Commands x and y have been used effectively (0.20) Help has not been accessed this session (0.25) The system has been used in the last 5 days Stereotypes

    System mengelompokkan user sebagai anggota dari kategori user atau stereotype, yang berbasiskan pada karakteristik user dan kemungkinan sederhana seperti membuat perbedaan antara user baru dan user ahli. Atau yang lebih kompleks seperti membuat stereotype yang berbasiskan pada lebih dari satu informasi.

    Ada beberapa cara membuat stereotype. Salah satunya adalah menggunakan informasi seperti perintah yang digunakan dan kesalahan untuk menggolongkan tipe user yang berbeda, kemudian menggunakan aturan untuk mengidentifikasikan stereotype dimana user berada. Pendekatan alternative adalah menggunakan pendekatan mesin pembelajaran seperti jaringan saraf untuk mempelajari contoh dari perilaku user yang bermacam2 dan menggolongkan user berdasarkan kedekatannya dalam mempelajari pelajaran sebelumnya.

    Overlay Models

    Merupakan model yang ideal yang membandingkan perilaku user. Hasilnya ditampilkan dalam dua model atau perbedaan. Keuntungan dari model ini dapat melihat secara pasti bagian dari aktivitas suatu system. Tidak hanya system dapat menyadari apa yang user lakukan, tetapi juga memiliki representasi perilaku yang optimal. Ini menyediakan suatu

    benchmark dalam mengukur unjuk kerja user, dan jika user tidak mengambil aksi yang optimal ada indikasi pada tipe help atau petunjuk yang diperlukan.

    Pendekatan yang serupa adalah digunakan pada error based model dimana system menyimpan rekaman kesalahan dan perilaku sebenarnya dari user serta membandingkannya. Jika perilaku sesuai dengan kesalahan pada catalog, aksi yang sama dapat dilakukan.

     

    Knowledge Representation : Domain And Task Modelling Pendekatan yang umum dari masalah ini adalah mewakili tugas user berdasarkan urutan perintah yang tersedia untuk mengeksekusinya. Sebagaimana pada tugas user, perintah digunakan untuk membandingkan urutan tugas yang disimpan dan mencocokkan dengan urutan tepat. Jika urutan perintah user tidak cocok maka dibutuhkan bantuan.

    Pendekatan ini digunakan pada system PRIAM.

    Knowledge Representation : Modelling Advisory Strategy Sistem ini kadang mencakup intelligent help yang membuat modelling advisory atau strategi tutorial. Dengan menyediakan system bantuan dengan tipe informasi ini memungkinkan tidak hanya memilik advis yang sesuai untuk user tetapi juga menggunakan metode pemberian advis.

    Manusia membutuhkan tipe bantuan yang berbeda bergantung pada pengetahuan dan kondisi. Ini meliputi pengingat-reminder, bantuan dengan tugas khusus-task specific help dan bantuan tutorial. Ada bukti mengindikasikan bahwa keahlian user mengikuti strategi yang berbeda ketika memberi advis ke sesamanya. Ini mencakup menginfer keinginan manusia dalam mencari bantuan dan nasehat pada level tersebut atau menyiapkan sejumlah pemecahan terhadap masalah. Alternatifnya, menempatkan masalah dalam konteks dan menyiapkan ‘contoh solusi’ berdasarkan konteks tersebut.

    Teknik Untuk Representasi Knowledge

    Terdapat empat group utama dari teknik yang digunakan dalam knowledge representation untuk intelligent help system :

    Rule Based Techniques

    Pengetahuan digunakan untuk mewakili sekumpulan aturan dan kenyataan, yang diimpretasikan menggunakan beberapa mekanisme inferensi. Logika predikat menyediakan mekanisme untuk merepresentasikan informasi deklaratif dan aturan

    produksi merepresentasikan informasi procedural. Teknik ini digunakan untuk domain yang relatif besar dan dapat mewakili kegiatan yang menampilkan pengetahun.

    Contoh:

    IF

    Command is EDIT file1

    AND

    Last command is COMPILE file1

    THEN

    Task is DEBUG

    action is describe automatic debugger

    Frame Based Technique

    Digunakan untuk mewakili situasi yang umum terjadi dan pengetahuan ‘default’. Frame merupakan suatu struktur yang berisi slot yang diberi label yang mewakili cirri yang berhubungan. Setiap slot diberi nilai atau nilai default. Input user disesuaikan dengan nilai frame dan jika sesuai menyebabkan beberapa aksi diambil.

    Contoh :

    User

    Expertise level : novice

    Command : EDIT file1

    Last command : COMPILE FILE1

    Errors this session : 6

    Action : describe automatic debugger

    Network Based Techniques

    Mewakili pengetahuan tentang user dan system yang merupakan hubungan antara kenyataan. Contoh yang paling umum adalah semantic network. Network merupakan suatu hirarki dan child dapat berhubungan dengan parent-nya. Network dapat digunakan untuk menghubungkan representasi berbasis frame.

    Contoh compile yang dapat diperluas dengan semantic network : CC is an instance of COMPILE

    COMPILE is a command

    COMPILE is related to DEBUG

    COMPILE is related to EDIT

    Automatic debugger facilitates DEBUG

    Example Based Technique

    Mewakili pengetahuan yang secara implicit ada dalam struktur keputusan dari suatu klasifikasi system. Ini dapat berupa pohon keputusan pada pendekatan pembelajaran induktif atau link dari network pada jaringan saraf. Struktur keputusan dibuat secara otomatis berdasarkan contoh yang dipresentasikan pengklasifikasi. Pengklasifikasi secara efektif mendeteksi cirri saat itu dalam contoh dan dapat menggunakannya untuk mengklasifikasikan input lainnya.

    Contoh :

    EDIT

    file1

    COMPILE

    file1

    Ini dipelajari sebagai contoh dari tugas khusus yaitu DEBUG.

    Masalah Dengan Knowledge Representation Dan Modelling Merepresentasikan pengetahuan merupakan issue dalam intelligent help system tetapi tidak tanpa masalahnya. Pengetahuan kadang sulit didapatkan, terutama jika ahli domain tidak ada. Ini akan sulit untuk memastikan kelengkapan dan kebenaran dari pengetahuan berdasarkan kondisi. Bahkan jika pengetahuan tersedia, jumlah pengetahuan yang dibutuhkan menjadi penting, membuat bantuan pintar menjadi opsi yang mahal.

    Masalah lain adalah mengintepretasikan informasi yang cocok. Meskipun basis pengetahuan dapat disediakan dengan pengetahuan rinci dari konteks yang diharapkan dan domainnya, selama interaksi informasi yang tersedia hanya log system dari aksi user. Data ini tidak berubah dan berisi pola kegiatan saat itu yang dapat digunakan untuk menginfer urutan tugas.

    Masalah Lain

    Inisiatif

    Haruskah user mempertahankan pengawasan yang lengkap terhadap system, Haruskah system langsung berinteraksi atau Haruskan penggabungan dialog didukung ?

    Effect

    Para perancang seharusnya memperhatikan efek dari modelling dan adaptasi Scope

    Para perancang perlu memperhatikan scope dari bantuan dimana digunakan pada level aplikasi atau system yang luas.

    Merancang Sistem Pendukung User

    Ada banyak cara untuk merancangnya dan semua itu diserahkan pada perancang untuk memilih cara yang terbaik akan tetapi hal yang perlu diperhatikan adalah : o Perancangannya seharusnya tidak seperti “add-on” ke perancangan system.

    Secara ideal seharusnya merupakan bagian integral dalam sistem o Perancang harus memperhatikan isi dari bantuan dan konteks yang akan digunakan sebelum teknologi disiapkan.

    Masalah Presentasi

    How is help requested ?

    Pilihan pertama bagi perancang untuk membuat bagaiman bantuan dapat diakses oleh user. Terdapat beberapa pilihan. Bantuan ini dapat berupa command, tombol fungsi yang dapat memilih on atau off atau aplikasi yang terpisah.

    How is help displayed ?

    Bagaimana bantuan akan dapat dilihat oleh user. Dalam system window akan ditampilkan dalam window yang baru. Dalam system lain mungkin dalam layar yang penuh atau bagian dari layar. Alternatif lain dapat berbentuk pop-up box atau tingkat command line. Tipe presentasi yang sesuai bergantung pada besarnya tingkat bantuan yang diberikan dan ruang yang dibutuhkan. Membuka halaman manual halaman demi halaman tidak membantu. Beberapa system bantuan aktif menyediakan petunjuk visual ketika memiliki saran pembuatan, ini yang membuat user mengambil saran tanpa meninggalkan atau menginterupsi pekerjaannya.

    Effective presentation of help

    Layar bantuan dan dokumentasi seharusnya dibuat sejalan dengan interface yang dibuat, memasukkan kemampuan dan kebutuhan tugas user. Tidak menjadi masalah teknologi apa yang digunakan untuk membuatnya akan tetapi yang perlu diperhatikan dan menjadi suatu prinsip yakni bagaimana menulis dan menampilkan secara efektif.

    Bantuan dan tutorial ditulis secara jelas, dalam bahasa yang dimengerti, menghindari logat khusus. Jika manual kertas dan tutorial ada, terminology harus konsisten dengan materi pendukung yang online. Materi instruksional membutuhkan bahasa instruksional dan system bantuan memberitahu user bagaimana menggunakan system, tidak hanya menggambarkan system.

    Masalah Implementasi

    Para perancang harus membuat keputusan untuk implementasi berupa hambatan/ batas fisik maupun pilihan yang tersedia untuk user. Keputusan ini sudah termasuk dalam pertanyaan : akankah bantuan merupakan perintah system operasi, apakah berbentuk meta-command atau aplikasi. Hambatan fisik apa yang membuat mesin menentukan screen space, kapasitas memori dan kecepatan. Kecepatan adalah hal yang penting karena waktu respon yang lambat untuk membuat system tidak digunakan meskipun sangat baik dirancang. Akan lebih baik menyediakan fasilitas bantuan sederhana yang merespon dengan cepat dibandingkan yang canggih yang membutuhkan waktu dalam memberikan solusi.

    Masalah lain adalah bagaimana struktur data bantuan : apakah berbentuk single file, hierarchy file atau database. Ini bergantung pada tipe dari bantuan tersebut dibuat, tetapi setiap struktur harus fleksibel dan dapat diperluas – system tidak statis dan topic baru tidak terhindarkan untuk ditambahkan ke system bantuan. Struktur data yang digunakan akan menentukan dan menyediakan tipe pencarian atau strategi navigasi.

    Perancang harus mempertimbangkan bahwa pengarang materi bantuan harus sebaik usernya. Bahkan jika perancang menulis teks bantuan awal, ini akan diperluas oleh pengarang lainnya pada waktu yang berbeda.

    Latihan

    1. Jenis bantuan (HELP) yang khusus menyediakan perintah secara step-by-step terhadap user baru adalah :

    a. Full explanation

    c. Quick reference

    b.

    Task-specific

    help

    d.

    Tutorial

    2. Model user yang menggunakan jumlah tingkatan keahlian adalah : a. Command prompt

    c. Command assistance

    b. Online documentation

    d. Online tutorial

    3. Yang merupakan jenis-jenis user support, kecuali : a. Intellegent help

    c. Command based methods

    b. Online documentation

    d. Quick reference

    Ada empat jenis bantuan yang dibutuhkan user. Yang termasuk Quick reference digunakan sebagai:

    a. Membantu user menghadapi masalah atau tidak pasti mengambil tindakan dalam memecahkan masalah yang khusus.

    b. Untuk user baru yang menyediakan perintah secara step by step c. Pengingat untuk user dari suatu yang detail yang secara dasar sangat familiar dan biasa digunakan.

    d. Alat bantu atau perintah yang dapat membantu memahami secara lengkap.

    5. Ada empat jenis bantuan yang dibutuhkan user. Yang termasuk tutorial digunakan sebagai:

    a. Membantu user menghadapi masalah atau tidak pasti mengambil tindakan dalam memecahkan masalah yang khusus.

    b. Untuk user baru yang menyediakan perintah secara step by step c. Pengingat untuk user dari suatu yang detail yang secara dasar sangat familiar dan biasa digunakan.

    d. Alat bantu atau perintah yang dapat membantu memahami secara lengkap

2 Responsesso far.

  1. mas darul ihsan says:

    CSCW ;;Computer Supported Cooperation Worked itu apakah berbentuk program software yang bisa diinstall..bagaimana cara mendapatkannya..butuh informasi..

  2. film izle says:

    film izle…

    Great articles & Nice a site.. Hey very nice blog!!…

Leave a Reply

Your email address will not be published. Required fields are marked *