Tugas 1 Individual IMK Life Cycle Software

Proses Desain Interaksi

Dalam pengembangan software ada bereapa tahapan utnuk mencapai kualitas pembuatan/ siklus hidup software. Dapat kami jabarkan siklus hidup software atau tahap penegmbangan software sebagai berikut :

Tahap Pengembangan Software ( Siklus Hidup Software )

1. Requirements Analysis ( Analisa Kebutuhan )
   Tahap ini menganalisa masalah dan kebutuhan yang harus diselesaikan dengan sistem komputer yang akan dibuat. Tahap ini berakhir dengan pembuatan laporan kelayakan yang mengidentifikasi kebutuhan sistem yang baru dan merekomendasikan apakah kebutuhan atau masalah tersebut dapat diselesaikan dengsn sistem komputer yang ada.
2. System and Software Design ( Prencanaan Sistem dan Software )
   Tahap ini melakukan rancangan design sistem. Tahap ini memberikan rincian kinerja program dan interaksi antara user dengan program tersebut.
3. Implementation ( Implementasi )
   Tahap ini adalah spesifikasi design yang telah dibuat untuk diterjemahkan de dalam program / instruksi yang ditulis dalam bahasa pemrograman.
4. System Testing ( Pengujian Sistem )
   Tahap ini semua program digabungkan dan diuji sebagai satu sistem yang lengkap untuk menjamin sumua berkerja dan memenuhi kebutuhan penanganan masalah yang dihadapi.
5. Operation and Maintenance ( Pengoperasian dan Pemeliharaan )
   Tahap ini merupakan pengaplikasian program yang telah dibuat untuk digunakan secara utuh dan masalah baru yang muncul sebagai bahan masukan untuk memperbaiki sistem program yang baru.

Proses dalam Desain Interaksi

Terdapat dua sisi pengertian yang dapat digunakan terkait dengan desain interaksi :

1. Sebagai suatu proses untuk mencapai suatu tujuan dengan pencarian berbagai solusi melalui ruang lingkup sistem, materi, biaya dan kemungkinan penyelesaiannya (feasibilitas), sebagai wujud kreativitas dan pengambilan keputusan untuk menyeimbangkan trade-off

2. Sebagai representasi suatu perencanaan pengembangan yang berisikan sekumpulan elaborasi alternatif dan suksesif.

Empat kegiatan utama dalam desain interaksi :

1. Identifikasi kebutuhan dan persyaratan sistem

2. Pengembangan desain alternatif (desain konseptual dan fisikal)

3. Membuat versi interaktif dari desain yang dihasilkan

4. Mengevaluasi desain (usabilitas dan user experience)

Tiga karakter utama dari keempat kegiatan diatas yang perlu diperhatikan :

1. Terfokus pada users dan evaluasi artifak

2. Identifikasi, dokumentasi dan kesepakatan terhadap usability yang telah ada dan tujuan dari user experience

3. Adanya perulangan dalam desain karena perlunya bereksplorasi terlebih dahulu terhadap desain yang ada terkait dengan user

Ada teknik yang dapat digunakan untuk memilih dari sekian banyak solusi yang ada, diantaranya :

1. Mengavaluasi desain bersama user

2. Feasibilitas teknik

3. Quality threshold, tujuan usabilitas yang penilaiannya menggunakan kriteria usabilitas.

MODEL SIKLUS HIDUP SOFTWARE

1.    Waterfall Model

Menurut Pressman, (Pressman, 2005, page 79), dalam rekayasa perangkat lunak, terdapat suatu pendekatan yang disebut Waterfall model.

Nama model ini sebenarnya adalah “Linear Sequential Model”. Model ini sering disebut dengan “classic life cycle” atau model waterfall. Model ini adalah model yang muncul pertama kali yaitu sekitar tahun 1970 sehingga sering dianggap kuno, tetapi merupakan model yang paling banyak dipakai didalam Software Engineering (SE). 

Model ini melakukan pendekatan secara sistematis dan urut mulai dari level kebutuhan sistem lalu menuju ketahap analisis, desain, coding, testing dan maintenance.

Model ini merupakan model yang paling banyak dipakai oleh para pengembang software. Ada lima tahap dalam model waterfall, yaitu: Requirement Analysis, System Design, Implementation, Integration & Testing, Operations & Maintenance. 

Sesuai dengan namanya waterfall (air terjun) maka tahapan dalam model ini disusun bertingkat, setiap tahap dalam model ini dilakukan berurutan, satu sebelum yang lainnya (lihat tanda anak panah). Selain itu dari satu tahap kita dapat kembali ketahap sebelumnya. Model ini biasanya digunakan untuk membuat sebuah software dalam skala besar dan yang akan dipakai dalam waktu yang lama.

Gambar Waterfall Model

Tahap – Tahap  Dalam Model Waterfall:

1.      Requirement Analysis

Seluruh kebutuhan software harus bisa didapatkan dalam fase ini, termasuk didalamnya kegunaan software yang diharapkan pengguna dan batasan software. Informasi ini biasanya dapat diperoleh melalui wawancara, survey atau diskusi. Informasi tersebut dianalisis untuk mendapatkan dokumentasi kebutuhan pengguna untuk digunakan pada tahap selanjutnya.

2.  System Design

Tahap ini dilakukan sebelum melakukan coding. Tahap ini bertujuan untuk memberikan gambaran apa yang seharusnya dikerjakan dan bagaimana tampilannya. Tahap ini membantu dalam menspesifikasikan kebutuhan hardware dan sistem serta mendefinisikan arsitektur sistem secara keseluruhan.

3.  Implementation

Dalam tahap ini dilakukan pemrograman. Pembuatan software dipecah menjadi modul-modul kecil yang nantinya akan digabungkan dalam tahap berikutnya. Selain itu dalam tahap ini juga dilakukan pemeriksaaan terhadap modul yang dibuat, apakah sudah memenuhi fungsi yang diinginkan atau belum.

4.  Integration & Testing

Di tahap ini dilakukan penggabungan modul-modul yang sudah dibuat dan dilakukan pengujian ini dilakukan untuk mengetahui apakah software yang dibuat telah sesuai dengan desainnya dan masih terdapat kesalahan atau tidak.

5.  Operation & Maintenance

Ini merupakan tahap terakhir dalam model waterfall. Software yang sudah jadi dijalankan serta dilakukan pemeliharaan. Pemeliharaan termasuk dalam memperbaiki  kesalahan yang tidak ditemukan pada langkah sebelumnya. Perbaikan implementasi unit sistem dan peningkatan jasa sistem sebagai kebutuhan baru.

Kelebihan Waterfall Model

Ketika semua kebutuhan sistem dapat didefinisikan secara utuh, eksplisit, dan benar diawal proyek, maka software engineering dapat berjalan dengan baik dan tanpa masalah.

Kekurangan Waterfall Model

1.      Ketika problem muncul, maka proses berhenti, karena tidak dapat menuju ketahapan selanjutnya. Bahkan jika kemungkinan problem tersebut muncul akibat kesalahan dari tahapan sebelumnya, maka proses harus membenahi tahapan sebelumnya agar problem ini tidak muncul. Hal-hal seperti ini yang dapat membuang waktu pengerjaan software engineering.

2.      Karena pendekatannya secara sequential, maka setiap tahap harus menunggu hasil dari tahap sebelumnya. Hal itu tentu membuang waktu yang cukup lama, artinya bagian lain tidak dapat mengerjakan hal lain selain hanya menunggu hasil dari tahap sebelumnya. Oleh karena itu, seringkali model ini berlangsung lama pengerjaannya.

3.      Pada setiap tahap proses tentunya dipekerjakan sesuai spesialisasinya masing-masing. Oleh karena itu, ketika tahap tersebut sudah tidak dikerjakan, maka sumber dayanya juga tidak terpakai lagi. Oleh karena itu, seringkali pada model proses ini dibutuhkan seseorang yang “multi-skilled”, sehingga minimal dapat membantu pengerjaan untuk tahapan berikutnya.

2.  RAD ( Rapid Application Development ) Model

Rapid Application Development (RAD) atau Rapid Prototyping adalah model proses pembangunan perangkat lunak yang tergolong dalam teknik incremental (bertingkat). RAD menekankan pada siklus pembangunan pendek, singkat, dan cepat. Waktu yang singkat adalah batasan yang penting untuk model ini. 

Rapid application development menggunakan metode interatif (berulang) dalam mengembangkan sistem dimana working model (model bekerja) sistem dikonstruksikan di awal tahap pengembangan dengan tujuan menetapkan kebutuhan (requirement) user dan selanjutnya disingkirkan. Working model digunakan kadang-kadang saja sebagai basis desain dan implementasi sistem final.

Gambar RAD

Tahap – Tahap  Rekayasa Software Dalam RAD Model

Model RAD menekankan pada tahap-tahap berikut :

1.  Business modeling

Pada tahap ini, aliran informasi (information flow) pada fungsi-fungsi bisnis dimodelkan untuk mengetahui informasi apa yang mengendalikan proses bisnis, informasi apa yang hasilkan, siapa yang membuat informasi itu, kemana saja informasi mengalir, dan siapa yang mengolahnya.

2. Data modeling

Aliran informasi yang didefinisikan dari business modeling, disaring lagi agar bisa dijadikan bagian-bagian dari objek data yang dibutuhkan untuk mendukung bisnis tersebut. Karakteristik (atribut) setiap objek ditentukan beserta relasi antar objeknya.

3. Process modelling

Objek-objek data yang didefinisikan sebelumnya diubah agar bisa menghasilkan aliran informasi untuk diimplementasikan menjadi fungsi bisnis. Pengolahan deskripsi dibuat untuk menambah, merubah, menghapus, atau mengambil kembali objek data.

4. Application generation

RAD bekerja dengan menggunakan fourth generation techniques (4GT). Sehingga pada tahap ini sangat jarang digunakan pemrograman konvensional menggunakan bahasa pemrograman generasi ketiga (third generation programming languages), tetapi lebih ditekankan pada reuse komponen-komponen (jika ada) atau membuat komponen baru (jika perlu). Dalam semua kasus, alat bantu untuk otomatisasi digunakan untuk memfasilitasi pembuatan perangkat lunak

5. Testing and turnover

Karena menekankan pada penggunaan kembali komponen yang telah ada (reuse), sebagian komponen-komponen tersebut sudah diuji sebelumnya. Sehingga mengurangi waktu testing secara keseluruhan. Kecuali untuk komponen-komponen baru.

Kelebihan RAD Model :

RAD memang lebih cepat dari  Waterfall. Jika kebutuhan dan batasan proyek sudah diketahui dengan baik. Juga jika proyek memungkinkan untuk dimodularisasi.

Kekurangan RAD Model :

1. Tidak semua proyek bisa dipecah (dimodularisasi), sehingga belum tentu RAD dipakai pada semua proyek.
2. Karena proyek dipecah menjadi beberapa bagian, maka dibutuhkan banyak orang untuk membentuk suatu tim yang mengerjakan tiap bagian tersebut.
3. Membutuhkan komitmen antara pengemang dengan pelanggan.
4. Model RAD memerlukan sumber daya yang cukup besar, terutama untuk proyek dengan skala besar.
5. Resiko teknis yang tinggi kurang cocok untuk model ini.
6. Sistem yang tidak bisa dimodularisasi tidak cocok untuk model ini.
7. Karena dibuat dengan reuse komponen-komponen yang sudah ada, fasilitas-fasilitas pada tiap komponen belum tentu digunakan seluruhnya oleh program yang me-reuse-nya sehingga kualitas program.

 3. Spiral Model

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.

 Gambar Spiral Model 

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 membangunkomunikasi  yang efektif diantara pengembang dan pelanggan.

• Perencanaan, tugas-tugas yang dibutuhkan untuk mendefinisikan sumber-sumber 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 umpanbalik  dari pelanggan dengan didasarkan pada evaluasi representasi perangkatlunak,  yang dibuat selama masa perekayasaan, dan diimplementasikan selama pemasangan.

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.

4. Star Lifecycle Model

 Gambar Star Lifecyle Model

Dalam  Siklus permodelan ini pengujian dilakukan terus menerus, tidak harus dikahir. Misalnya dimulai dari menentukan kosep desain (conceptual design) dalam proses ini akan langsung terjadi evaluasi untuk langsung ternilai apakah sudah sesuai dengan kebutuhan user, bila belum maka akan terus berulang di evaluasi hingga benar-benar pas, selanjutnya apabila sudah pas, maka dari tahap evaluasi yang pertama akan lanjut ke proses yg selanjutnya yakni requirements/specification yakni memverifikasikan persyaratan rancangan tersebut, dan pada tahap itu juga langsung terjadi pengevaluasian seperti tahap pertama, dan selanjutnya akan tetap sama terjadi pada tahapan-tahapan selanjutnya yakni task analysis/fungsion analysis, pengimplementasian, prototyping hingga pada akhirnya terciptalah sebuah aplikasi yang sesuai dengan kebutuhan user.

Intinya pada rancangan model ini pengevaluasian dilakukan disetiap tahapan tidak hanya pada tahapan akhir seperti model-model rancangan yang lainnya.

5. Model V

Model ini merupakan perluasan dari model waterfall. Disebut sebagai perluasan karena tahap-tahapnya mirip dengan yang terdapat dalam model waterfall. Jika dalam model waterfall proses dijalankan secara linear, maka dalam model V proses dilakukan bercabang. Dalam model V ini digambarkan hubungan antara tahap pengembangan software dengan tahap pengujiannya.

 Gambar V - Model

Berikut penjelasan masing-masing tahap beserta tahap pengujiannya:

1.      Requirement Analysis & Acceptance Testing

Tahap Requirement Analysis sama seperti yang terdapat dalam model waterfall. Keluaran dari tahap ini adalah dokumentasi kebutuhan pengguna.

Acceptance Testing merupakan tahap yang akan mengkaji apakah dokumentasi yang dihasilkan tersebut dapat diterima oleh para pengguna atau tidak.

2.      System Design & System Testing

Dalam tahap ini analis sistem mulai merancang sistem dengan mengacu pada dokumentasi kebutuhan pengguna yang sudah dibuat pada tahap sebelumnya. Keluaran dari tahap ini adalah spesifikasi software yang meliputi organisasi sistem secara umum, struktur data, dan yang lain. Selain itu tahap ini juga menghasilkan contoh tampilan window dan juga dokumentasi teknik yang lain seperti Entity Diagram dan Data Dictionary.

3.      Architecture Design & Integration Testing

Sering juga disebut High Level Design. Dasar dari pemilihan arsitektur yang akan digunakan berdasar kepada beberapa hal seperti: pemakaian kembali tiap modul, ketergantungan tabel dalam basis data, hubungan antar interface, detail teknologi yang dipakai.

4.      Module Design & Unit Testing

Sering juga disebut sebagai Low Level Design. Perancangan dipecah menjadi modul-modul yang lebih kecil. Setiap modul tersebut diberi penjelasan yang cukup untuk memudahkan programmer melakukan coding. Tahap ini menghasilkan spesifikasi program seperti: fungsi dan logika tiap modul, pesan kesalahan, proses input-output untuk tiap modul, dan lain-lain.

5.      Coding

Dalam tahap ini dilakukan pemrograman terhadap setiap modul yang sudah dibentuk.V Model memiliki beberapa kelebihan. Kelebihan-kelebihan tersebut secara garis besar dapat dijelaskan seperti berikut:

 a. V Model sangat fleksibel. V Model mendukung project tailoring dan penambahan dan pengurangan method dan tool secara dinamik. Akibatnya sangat mudah untuk melakukan tailoring pada V Model agar sesuai dengan suatu proyek tertentu dan sangat mudah untuk menambahkan method dan tool baru atau menghilangkan method dan tool yang dianggap sudah obsolete.

 b.  V Model dikembangkan dan di-maintain oleh publik. User dari V Model berpartisipasi dalam change control board yang memproses semua change request terhadap V Model.

V Model juga memiliki beberapa kekurangan. Kekurangan-kekurangan tersebut yaitu:

a.  V Model adalah model yang project oriented sehingga hanya bisa digunakan sekali dalam suatu proyek.

b.  V Model terlalu fleksibel dalam arti ada beberapa activity dalam V Model yang digambarkan terlalu abstrak sehingga tidak bisa diketahui dengan jelas apa yang termasuk dalam activity tersebut dan apa yang tidak.

6. Prototyping Model

Paradigma dari metode prototyping adalah sistem informasi yang menggambarkan hal-hal penting dari sistem informasi yang akan datang. Prototipe sistem informasi bukanlah merupakan sesuatu yang lengkap, tetapi sesuatu yang harus dimodifikasi kembali, dikembangkan, ditambahkan atau digabungkan dengan sistem informasi yang lain bila perlu. 

Sebuah prototype adalah bagian dari produk yang mengekspresikan logika maupun fisik antarmuka ekternal yang ditampilkan. Komponen potensial menggunakan prototype dan menyediakan masukan tim pengembangan sebelum sebelum pengembangan skala besar dimulai. Melihat dan mempercayai menjadi hal yang diharapkan untuk dicapai dalam prototype. Dengan menggunakan pendekatan ini, konsumen dan tim pengembangan dapat mengklarifikasi kebutuhan pengembangan software dan intrepetasi mereka. 

 Gambar Prototyping Model

Tahap – Tahap  Rekayasa Software Dalam Prototype Model :

1.      Pengumpulan kebutuhan

Developer dan klien bertemu untuk menentukan tujuan umum, kebutuhan yang diketahui dan gambaran bagian-bagian yang akan dibutuhkan berikutnya. Detail kebutuhan mungkin tidak dibicarakan disini, pada awal pengumpulan kebutuhan.

2.      Perancangan Cepat

Perancangan dilakukan cepat dan rancangan mewakili semua aspek software yang diketahui, dan rancangan ini menjadi dasar pembuatan prototype.

3.      Bangun Prototype

Dalam tahap ini, membangun sebuah versi prototype yang dirancang kembali dimana masalah-masalah tersebut diselesaikan.

4.      Evaluasi prototype

Pada tahap ini, klien mengevaluasi prototype yang dibuat dan digunakan untuk memperjelas kebutuhan software.

5.      Perbaikan Prototype

Tahap ini Software yang sudah jadi dijalankan dilakukan perbaikan. Perbaikan termasuk dalam memperbaiki  kesalahan/kerusakan yang tidak ditemukan pada langkah sebelumnya.

Kelebihan Prototype Model adalah :

1. End user dapat berpartisipasi aktif.
2. Penentuan kebutuhan lebih mudah diwujudkan.
3. Mempersingkat waktu pengembangan software.

Kekurangan Prototype Model adalah :

1. Proses analisis dan perancangan terlalu singkat.
2. Mengesampingkan alternatif pemecahan masalah.
3. Bisanya kurang fleksibel dalam menghadapi perubahan.
4. Prototype yang dihasilkan tidak selamanya mudah dirubah.
5. Prototype terlalu cepat selesai.

 7. Simple Interaction Desain Model

Gambar Simple Interaction Desain Model

Pada model rancangan interaksi sederhana ini input atau masukan hanya memiliki satu titik. yang mana masukan tersebut diidentifikasikan apakah sesuai dengan kebutuhan, lalu didesain sesuai dengan persyaratan yang telah ditetapkan. Setelah didesain rancangan tersebut dibangun dan harus interaktif. Setelah itu barulah rancangan tersebut dievaluasi.

Evaluasi dapat dilakukan dimana saja, rancangan yang telah di evakuasi dapat kambali didesain ulang atau apakah rancangan tersebut tidak sesuai dengan kebutuhan user, maka alur tersebut akan terus berputar hingga pada tahap evaluasi tidak lagi terjadi kesalahan, baik dalam penetapan kebutuhan user maupun pendesainannya, sehingga pada tahap evaluasi terciptalah sebuah hasil akhir yang valid.

8. Model Brainstorming

Aturan Waktu Melakukan Brainstorming : 

1. Semua ide dikumpulkan dari semua orang dalam tim dan tidak boleh dikritik oleh orang lain.

2. Semua ide yang masuk, baik yang masuk akal maupun tidak harus diterima. Semakin banyak ide yang masuk semakin baik.

3. Tidak boleh ada diskusi selama brainstorming berjalan karena diskusi akan dilakukan setelah brainstorming selesai.

4. Jangan mengkritik, menghakimi atau mentertawakan ide yang dikemukakan peserta.

5. Tulis semua ide pada papan tulis sehingga tim bisa melihat.

6. Atur waktu untuk aktivitas brainstorming misalnya 30 menit atau lebih.

Urutan Dalam Melakukan Brainstorming

1. Salah satu tim harus me-review topik yang digunakan dengan pertanyaan Why, How atau What.

2. Setiap anggota tim harus memikirkan jawaban atas pertanyaan untuk beberapa saat dan mencatatnya di kertas.

3. Setiap orang membacakan idenya atau semua ide ditulis di papan tulis.

4. Membuat pilihan akhir.

5. Bila semua ide telah dicatat dan dikombinasikan dengan ide-ide yang mungkin, kategori awal harus tetap disepakati.

6. Jumlah ide yang ada.

7. Voting anggota digunakan untuk membuat sejumlah ide yang akan didiskusikan. Isi daftar tidak boleh lebih dari sepertiga jumlah ide.

References : 

https://kdenotes.wordpress.com/2009/05/27/proses-dalam-desain-interaksi/

http://theresianihan.blogspot.com/

Tugas 2 Individual IMK Standard Proses UCD untuk Sistem Interaktif

Standard proses UCD untuk sistem interaktif

Penjelasan :

- Plan the human centered process

Langkah pertama ini memerlukan pertemuan komitmen dari semua pihak yang bersangkutan dalam proses pengembangan dengan menggunakan metode UCD dan membuat rencana dengan waktu dan peluang yang ada untuk mengumpulkan persyaratan-persyaratan dan melakukan testing

Efek samping penting dari langkah pertama yang dilakukan adalah konsensus diantara regu desain dan keterlibatan pamakai pada akhirnya akan menjadi tidak simpel. Suatu rencana pengesahan adalah hasil langkah pertama ini.

- Specify the context of use

Mutu kegunaan dari sistem tergantung dari pemahaman dan perencanaan dari karakteristik pemakai, tugas-tugas, lingkungan fisik dan organisasi dimana sistem akan digunakan. Sangatlah penting untuk mengerti dan mengidentifikasi dari konteks ini dalam memandu keputusan awal desain.dan menyediakan dasar untuk menerapkan konteks dimana usabilitas harus dievaluasi.

Pada tahap ini sistem ditingkatkan dan diperluas. Untuk sistem yang sudah berjalan, umpan balik dari pemakai dan laporan help desk akan menjadi dasar prioritas kebutuhan pemakai untuk modifikasi dan perubahan sistem. Untuk produk atau sistem baru, aka sangatlah penting untuk mengambil informasi tentang konteks kegunaan melalui pertemuan dan wawancara.

Konteks dari sistem yang digunakan akan mengidentifikasikan:

1. Karakteristik-karakteristik dari pemakai yang diharapkan

2.Tugas-tugas dari pemakai

3. Suatu hirarkis uraian tugas yang global

4. Seluruh sasaran kegunaan dari sistem untuk setiap kategori pemakai. Seperti karakteristik-karakteristik yang dapat mempengarruhi tugas dalam skenario khusus.Lingkungan dimana pemakai akan menggunakan sistem

- Specify the user and organisational requirements

Didalam kebanyakan proses desain, ada aktivitas utama dimana persyaratan fungsi dari sistem atau produk dispesifikasikan. Dalam UCD, adalah penting dalam membuat pernyataan ekplisit dan persyratan organisasi . Berikut ini kaitannya dengan context of use :

1. Mutu dari antarmuka komputer dan manusia dan desain stasiun kerja

2. Mutu dan isi dari tugas-tugas pemakai yang diindentifikasikan

3. Performa kefektifitasan suatu tugas tergantung dari ketransparanan aplikasi terhadap pemakai

4. Kerjasama dan komunikasi efektif antara kategori-kategori yang berbeda antara pamakai-pemakai dan pihak-pihak lain yang terkait.

5. Kinerja dari sistem baru terhadap objek operasional dan keuangan.

Dari penjabaran diatas, persyaratan harus dipertimbangkan dalam suatu hal yang lebih khusus.

- Produce sistem solution

Tahapan berikutnya adalah membuat solusi desain yang potensial dengan menggambar mendesain bentuk dari pengalaman dan pengetahuan para partisipan.

Proses ini melibatkan :

1. Menggunakan pengetahuan yang sudah ada (standar, petunjuk, contoh-contoh dari yang lain sistem lain)

2. Membuat penyelesaian prototipe yang lebih focus (menggunakan simulasi-simulasi, prototipe-prototipe kertas, dll.)

3. Menunjukan prototype kepada pemakai dan meneliti mereka ketika mereka melaksanakan tugas-tugas yang ditetapkan dengan atau tanpa bantuan dari evaluator

4. Mempergunakan umpan balik ini untuk memperbaiki desain

5. Proses interasi sampai tujuan desain tercapai.

- Evaluate designs against user requirements

Evaluasi adalah suatu tahap penting dalam UCD yang terdiri dari :

Format: Untuk menyediakan umpan balik yang berguna untuk meningkatkan desain

Summatif: Untuk menilai apakah sasaran organisasi telah tercapai

Proses UCD

UCD ( user Centered Design ) merupakan paradigma baru dalam pengembangan sistem berbasis web.  Perancangan berbasis pengguna (User Centered design = User Centered Design = UCD) adalah istilah yang yang digunakan untuk untuk menggambarkan filosofi perancangan. Konsep dari UCD adalah user sebagai pusat dari proses pengembangan sistem, dan tujuan/sifat-sifat, konteks dan lingkungan sistem semua didasarkan dari pengalaman pengguna.

Prinsip yang harus diperhatikan dalam UCD adalah:

1.  Fokus pada pengguna

Perancangn harus berhubungan langsung dengan pengguna sesungguhnya atau calon pengguna melalui interview, Survey, dan partisipasi dalam workshop perancangan.

Tujuannya adalah untuk memahami kognisi, karakter, dan sikap pengguna serta karakteristik anthropometric. Aktivitas utamanya mencakup pengambilan data, analisis dan integrasinya ke dalam informasi perancangan dari pengguna tentang karakteristik tugas, lingkungan teknis, dan organisasi.

2.  Perancangan terintergrasi

Perancangan harus mencakup antarmuka pengguna, sistem bantuan, dukungan teknis serta prosedur instalasi dan konfigurasi.

3.  Dari awal berlanjut pada penggujian pengguna

Satu-satunya pendekatan yang sukses dalam perancangan sistem yang berpusat pada pengguna adalah secara empiris dibutuhkan observasi tentang kelakuan pengguna, evaluasi umpan-balik yang cermat, wawasan pemecahan terhadap masalah yang ada, dan motivasi yang kuat untuk mengubah rancangan.

4.  Perancangan interaktif.

Sistem yang sedang dikembangkan harus didefinisikan, dirancang, dan ditest berulang kali. Berdasarkan hasil test kelakuan dari fungsi, antarmuka, sistem bantuan, dokumementasi pengguna, dan pendekatan pelatihannya.

            UCD adalah tentang partisipasi dan pengalaman manusia dalam proses perancangan. Pengguna adalah orang yang akan menggunakan sistem. Pengguna langsung biasa disebut pengguna akhir ( end user ) yang menggunakan sistem untuk menyelesaikan pekerjaannya. Pengguna tidak langsung adalah pengguna yang menggunakan sistem untuk penggunaan yang lain seperti system administrators, installers, dan demonstrators.

Aturan dalam UCD

      Karat telah mendefinisikan hak pengguna untuk mentransformasi budaya yang terdapat dalam perancangan, pengembangan, dan pembuatan sistem teknologi informasi, dan untuk memastikan bahwa produk hasilnya akan tepat seperti harapan pelanggan.

Aturan dalam UCD ( User Centered Design ).

1.  Perspektif

Pengguna selalu benar. Jika terdapat masalah dalam penggunakan sistem, maka masalah ada pada sistem dan bukan pengguna.

2.  Installasi

Pengguna mempunyai hak untuk dapat menginstall atau mengun-install perangkat lunak dan perangkat keras sistem secara mudah tanpa ada konsekuensi negatif.

3.  Pemenuhan

Pengguna mempunyai hak untuk mendapatkan sistem dapat bekerja persis seperti yang dijanjikan.

4.  Instruksi

Pengguna mempunyai hak untuk dapat menggunakan instruksi secara mudah ( buku petunjuk, bantuan secara on-line atau kontekstual, pesan kesalahan ), untuk memahami dan menggunakan sistem untuk mencapai tujuan yang diinginkan secara efisien dan terhindar dari masalah.

5.  Kontrol

Pengguna mempunya hak untuk dapat mengontrol sistem dan mampu membuat sistem menanggapi dengan benar atas permintaan yang diberikan.

6.  Umpan Balik

Pengguna mempunyai hak terhadap sistem untuk menyediakan informasi yang jelas, dapat dimengerti, dan akurat tentang tugas yang dilakukan dan kemajuan yang dicapai.

7.  Keterkaitan

Pengguna mempunyai hak untuk mendapatkan informasi yang jelas tentang semua prasyarat yang dibutuhkan sistem untuk memperoleh hasil terbaik.

8.  Batasan

Pengguna mempunyai hak untuk mengetahui batasan kemampuan sistem.

9.  Assistance

Pengguna mempunyai hak untuk dapat berkomunikasi dengan penyedian teknologi dan menerima pemikiran dan tanggapan yang membantu jika diperlukan.

10. Usability

Pengguna harus dapat menjadi penguasa teknologi perangkat lunak dan perangkat keras, dan bukan sebaliknya. Sistem harus dapat dugunakan secara alami dan ituitif.

 Proses User Centered Design ( UCD )

Keterangan gambar:

1. Memahami dan menentukan konteks pengguna

v  Karakteristik pengguna yang diharapkan

v  Pekerjaan yang dilakukan pengguna

v  Pemecahan secara hirarki atas pekerjaan global

v  Tujuan global penggunaan sistem untuk setiap kategori pengguna, termasuk karakteristik tugas yang mungkin menggangu penggunaan dalam scenario khusus, seperti frekuensi dan lama kinerja.

v  Deskripsi harus mencakup alokasi aktifitas dan langkah operasional antara manusia dan sumberdaya teknologi

v  Pahami lingkungan tempat pengguna akan menggunakan sistem

v  Sangat penting awal langkah untuk menentukan kebutuhan sistem minimal dan optimal dengan memperhatikan.

2. Menentukan kebutuhan pengguna dan Organisasi

Dalam UCD penting untuk memperluas aktivitas kebutuhan fungsional sistem  dengan membuat pernyataan eksplisit kebutuhan pengguna dan organisasi, dalam hubungannya dengan konteks diskripsi penggunaan dalam hal:

·         Kualitas perancangan interaksi manusia dan komputer serta workstation,

·         Kualitas dan isi tugas pengguna ( termasuk alokasi tugas diantara kategori penguna yang berbeda ),

·         Kinerja tugas yang efektif khususnya dalam hal transparasi aplikasi ke pengguna,

·         Kerjasama dan komunikasi yang efektif diantara pengguna dan pikah ketiga yang relevan,

·         Dibutuhkan kinerja sistem baru terhadap tujuan finansial.

3.     Solusi perancangan yang dihasilkan

·         Dengan memgunakan pengetahuan yang ada untuk mengembangkan suatu proposal solusi perancangan.

·         Membuat solusi perancangan lebih konkrit ( dengan simulasi, prototipe, dll )

·         Memperlihatkan prototipe ke pengguna dan mengamatinya saat melakukan tugas spesifik, dengan atau tanpa bantuan evaluatur.

·         Menggunakan umpan balik untuk perbaikan rancangan,

·         Mengulang proses ini sampai tujuan perancangan dipenuhi.

4.     Evaluasi Perancangan terhadap kebutuhan pengguna

·         Formative: menyediakan umpanbalik yang dapat digunakan untuk memperbaiki rancangan.

·         Summative: melakukan penilaian apakah tujuan pengguna dan organisasi telah tercapai

Model menurut Eason (1992)

Eason menggambarkan empat langkah kunci dalam pengembangan, yaitu perencanaan, perancangan, implementasi, dan pengelolaan sistem.

Chekland ( 1981) dan Wilson (1984 ) menyediakan sejumlah metoda yang dapat digunakan untuk menghasilkan suatu definisi yang formal dan komprehensif tentang sistem. Checkland menamakannya sebagai root definition, yang dapat membantu perancang untuk memastikan bahwa mereka telah mencakup seluruh aspek dari sistem dan menghasilkan definisi akar yang kuat. Definisi tersebut adalah elemen CATWOE: Client, Actors, Transformasi, Weltanshauung ( pandangan dunia), owners, dan environtment.

  

Gambar 3. Metode UCD menurut Eason

Pada gambar diatas terdapat empat pendekatan dalam pengembangan sistem, yaitu:

1.     Soft System Methodology ( SSM ).

2.     Open System Task Analysis ( OSTA )

3.     Multivew

4.     Star Life Circle

Keempat pendekatan diatas mempunyai fokus pengembangan yang berbeda.

6.1 Soft System Methodology ( SSM )

Penekanan SSM tidak pada pencarian solusi untuk suatu masalah, tetapi pada pemahaman situasi dimana masalah yang dirasakan dianggap bukan merupakan akar atau asensi masalah yang sebenarnya.

Langkah-langkah  Soft System Methodology ( SSM ) adalah :

1. Langkah 1 dan 2 difokuskan pada pencarian pernyataan yang lengkap atas situasi permasalahan.

Pada langkah ini dilakukan pertemuan yang melibatkan seluruh puhak yang berkepentingan ( stakeholeder ).

2. Langkah 3 mencoba untuk membuat definisi sistem yang presisi.

3. Langkah 4 menggunakan hasil dari langkah 3 berupa pernyataan sistem secara abstrak .

Chekland ( 1981) dan Wilson (1984 ) menyediakan sejumlah metoda yang dapat digunakan untuk menghasilkan suatu definisi yang formal dan komprehensif tentang sistem. Checkland menamakannya sebagai root definition, yang dapat membantu perancang untuk memastikan bahwa mereka telah mencakup seluruh aspek dari sistem dan menghasilkan definisi akar yang kuat. Definisi tersebut adalah elemen CATWOE: Client, Actors, Transformasi, Weltanshauung ( pandangan dunia), owners, dan environtment.

Referensi :

http://aldiimk.blogspot.com/p/proses-ucd.html