BAB 2 TINJAUAN PUSTAKA

BAB 2

TINJAUAN PUSTAKA

Pada bab ini akan dibahas teori mengenai FSM yang meliputi defenisi FSM, kelebihan dan kekurangan FSM, teknik pemodelan FSM, implementasi FSM pada perangkat lunak, dan interaksi manusia dengan komputer yang meliputi defenisi serta prinsip utama mendesain antarmuka (interface).

2.1

Finite State Machine (FSM)

Bahasa formal dapat dipandang sebagai entitas abstrak, yaitu sekumpulan string-string simbol alphabet tertentu. Namun bahasa juga dapat dipandang sebagai entitas-entitas abtrak yang dapat dikenali atau dibangkitkan melalui suatu mesin komputasi. Mesin yang dapat mengenali bahasa kelas ini adalah finite state machine.

2.1.1 Defenisi FSM

Ada beberapa definisi mengenai Finite State Machine (FSM) atau sering juga disebut dengan Finite State Automata (FSA).

1. FSM didefenisikan sebagai perangkat komputasi yang memiliki input berupa string dan output yang merupakan satu dari dua nilai yang dapat di-accept dan reject (Rich : 2009).

2. Finite Automata adalah model matematika sistem dengan masukan dan keluaran diskrit. Sistem dapat berada di salah satu dari sejumlah berhingga konfigurasi internal disebut state (Hariyanto : 2004).

Universitas Sumatera Utara

3. FSM

adalah

sebuah

metodologi

perancangan

sistem

kontrol

yang

menggambarkan tingkah laku atau prinsip kerja sistem dengan menggunakan tiga hal berikut: State (Keadaan), Event (kejadian) dan action (aksi). Pada satu saat dalam periode waktu yang cukup signifikan, sistem akan berada pada salah satu state yang aktif. Sistem dapat beralih atau bertransisi menuju state lain jika mendapatkan masukan atau event tertentu, baik yang berasal dari perangkat luar atau komponen dalam sistemnya itu sendiri. Transisi keadaan ini umumnya juga disertai oleh aksi yang dilakukan oleh sistem ketika menanggapi masukan yang terjadi. Aksi yang dilakukan tersebut dapat berupa aksi yang sederhana atau melibatkan rangkaian proses yang relatif kompleks (Setiawan : 2006).

Gambar 2.1 Contoh diagram state sederhana (Sumber: Setiawan, 2006)

Diagram tersebut memperlihatkan FSM dengan dua buah state dan dua buah input serta empat buah aksi output yang berbeda : seperti terlihat pada gambar, ketika sistem mulai dihidupkan, sistem akan bertransisi menuju state0, pada keadaan ini sistem akan menghasilkan Action1 jika terjadi masukan Event0, sedangkan jika terjadi Event1 maka Action2 akan dieksekusi kemudian sistem selanjutnya bertransisi ke keadaan State1 dan seterusnya. Secara formal FSM dinyatakan oleh 5 tupel atau ∑, M=(Q, δ, S, F), (Utdirartama, 2001) dimana: Q = himpunan state/kedudukan ∑ = himpunan symbol input/masukan/abjad δ = fungsi transisi S = state awal/ kedudukan awal (initial state), S F = himpunan state akhir, F

Q

Q


FSM terdiri dari dua jenis, yaitu FSM ber-output dan FSM tidak ber-output. FSM tidak ber-output digunakan untuk pengenalan bahasa dalam komputer, dengan input yang dimasukkan akan diperoleh apakah input tersebut dikenal oleh bahasa komputer atau tidak. Salah satu penggunaan FSM tidak ber-output adalah program compiler, yaitu program untuk memeriksa apakah perintah yang digunakan pengguna benar atau salah. Sementara untuk FSM ber-output digunakan untuk merancang mesin atau sistem (Zen, 2008). Dan FSM yang akan digunakan dalam penelitian ini adalah FSM ber-output, dan untuk selanjutnya akan dituliskan dengan FSM saja.

Ada dua metode utama untuk memperlakukan FSM untuk menghasilkan output. Yaitu Moore Machine dan Mearly Machine yang dinamakan berdasarkan penemunya.

2.1.1.1 Moore Machine

Gambar 2.2 Moore State Machine (Sumber: Brownlee, 2010)

Moore Machine adalah tipe dari FSM dimana output dihasilkan dari state. Pada gambar diatas mencontohkan dimana state mendefenisikan apa yang harus dilakukan (Brownlee, 2010). Keluaran pada Moore Machine diasosiasikan sebagai state (Hariyanto, 2004). Dan pada penelitian ini, penulis menggunakan Moore Machine.


2.1.1.2 Mearly Machine

Gambar 2.3 Mearly State Machine (Sumber: Brownlee, 2010)

Mearly Machine berbeda dengan Moore Machine dimana keluarannya merupakan hasil dari transisi antar state (Brownlee, 2010). Keluaran pada Mearly Machine diasosiasikan sebagai transisi (Hariyanto, 2004)

2.1.2 Kelebihan FSM

FSM memiliki beberapa kelebihan (Brownlee, 2010), diantaranya : 1. Sederhana, sehingga mudah diimplementasikan 2. Bisa diprediksi responnya 3. Komputasi ringan 4. Relatif fleksibel 5. Merupakan metode AI lama yang bisa digunakan pada berbagai sistem 6. Mudah ditransfer dari abstrak menjadi kode program

2.1.3 Kelemahan FSM

Selain memiliki banyak kelebihan, FSM juga mempunyai beberapa kelemahan (Brownlee, 2010), diantaranya : 1. Karena sifatnya bisa diprediksi, maka implementasi pada game kurang disukai 2. Implementasi pada sistem yang lebih besar lebih sulit karena pengaturan dan pemeliharaannya jadi kompleks


3. Sebaiknya hanya digunakan pada sistem dimana sifat sistem bisa didekomposisi menjadi state. 4. Kondisi untuk transisi state adalah tetap

2.1.4 Teknik Pemodelan FSM

Finite State Machine bukanlah metode yang baru. FSM sudah lama ada dan konsep dekomposisi biasanya sudah dipahami dan sering digunakan oleh orang-orang yang memiliki pengalaman dalam membuat program komputer atau desain program komputer. Ada beberapa teknik pemodelan abstrak yang bisa digunakan untuk membantu defenisi atau pemahaman dan desain dari FSM, mayoritas teknik ini berasal dari disiplin ilmu desain atau matematika (Lee: 1998).

1. Diagram Transisi State Juga dikenal sebagai Diagram Gelembung (Bubble Diagram). Menunjukkan relasi antara state dengan input yang menyebabkan transisi state.

2. Diagram Pengambilan Keputusan State-Aksi. Diagram Alir sederhana dengan tambahan gelembung yang menunjukkan penungguan terhadap input.

3. Diagram Grafik State Salah satu bentuk dari notasi UML yang berfungsi untuk menunjukkan sifat individu dari objek sebagai nomor state dan transisi dari state tersebut.

4. Analisa Hirarki Perintah Meskipun tidak seperti state, ini merupakan teknik dekomposisi perintah yang melihat dari sudut pandang bagaimana caranya perintah dibagi jadi sub perintah dan urut sesuai urutan kejadiannya.


2.1.5 Implementasi FSM pada perangkat lunak

Implementasi Finite State Machine dalam perangkat lunak merupakan permasalahan tersendiri yang sudah banyak diteliti oleh pakar-pakar insinyur perangkat lunak (software engineer ). Desain Finite State Machine memang tampak mudah dan sederhana karena hanya terdiri dari serangkaian lingkaran dan anak panah yang masing-masing memiliki label. Desain FSM biasanya direpresentasikan dalam tabel transisi

state

atau

dengan

state

diagram.

Namun

jika

tiba

waktunya

mengimplementasikan FSM dalam suatu aplikasi perangkat lunak, maka ada suatu permasalahan yang sering timbul yaitu kode program FSM menjadi rumit dan kompleks ketika sistem yang dibangun adalah sistem yang besar atau kompleks. Bagi pemula yang masih belajar implementasi FSM dengan sistem sederhana mungkin hal ini tidak terlalu berpengaruh maupun terasa. Namun bagi seorang programer profesional, maka implementasi FSM untuk sistem yang besar atau kompleks memerlukan suatu desain struktur yang baik dan optimal (Wijaya, 2009).

Pada dasarnya implementasi FSM bisa dibagi menjadi tiga (3) cara, dimana masingmasing cara memiliki kelebihan dan kekurangan masing-masing. Ketiga cara tersebut adalah sebagai berikut (Wijaya, 2009): 1. Cara tradisional 2. Lookup table 3. Object Oriented

Sebagai contoh sistem yang digunakan untuk melihat perbedaan antara cara satu dengan yang lain adalah sistem mesin minuman dalam kaleng menggunakan koin. Desain FSM sistem tersebut tampak pada gambar.


Gambar 2.4 FSM mesin minuman dalam kaleng menggunakan koin (Sumber:Yacoub, 1998)

2.1.5.1 Cara Tradisional

Kelebihan dari cara tradisional adalah mudah untuk diimplementasikan. Cara ini adalah cara klasik yang paling mudah untuk menerapkan FSM pada perangkat lunak sekaligus merupakan cara klasik yang biasanya masih banyak digunakan pada mikro komputer dengan sumber daya pemroses yang terbatas (limited hardware resources ). Kekurangan dari cara tradisional adalah bahwa implementasi yang mudah tersebut hanya berlaku jika sistem yang digunakan adalah sistem yang kecil. Seiring dengan membesarnya sistem dan membesarnya tingkat kompleksitas maka implementasi dan pemeliharaannya juga akan semakin rumit (Wijaya, 2009).

Tabel 2.1: Implementasi cara tradisional (Sumber: Yacoub, 1998) switch(state){ case Broken: //kode state Broken disini; break; case Unlock: // kode state Unlock disini; break; default: // kode Lock disini break; }


Ciri khas dari implementasi FSM menggunakan cara tradisional adalah dengan menggunakan perintah if then atau select case atau switch pada kode program. Salah satu contoh implementasi cara tradisional pada kode program adalah seperti pada tabel 2.1.

Semakin banyak jumlah state yang digunakan pada sistem, maka semakin banyak juga penulisan kode dan semakin panjang perintah switch. Karena semua state berada dalam satu ruang lingkup perintah switch, maka jika terjadi salah ketik pada salah satu state akan membuat state yang lain terlihat kacau juga. Semakin panjang state yang digunakan, maka efisiensi pengetikan program juga akan menurun, karena programer harus mencari state yang ingin dia tambahkan diantara state lain yang banyak jumlahnya. Jika ada perogramer baru yang harus meneruskan pemrograman sebelumnya, maka akan membutuhkan waktu yang cukup lama bagi programer baru tersebut untuk memahami algoritma kode perangkat lunak karena berada dalam satu file yang panjang (Wijaya,2010).

Selain itu programer harus teliti dalam memastikan bahwa tiap state memiliki suatu kondisi tertentu untuk transisi ke state lain. Karena jika ada state yang tidak memiliki transisi ke state lain, maka program akan looping terus pada state tersebut (Wijaya, 2010).

2.1.5.2 Lookup table

Cara lain mengimplementasikan FSM dalam perangkat lunak adalah dengan menggunakan lookup table. Tabel ini berisi semua transisi state yang mungkin terjadi pada sistem. Tabel ini direpresentasikan sebagai matriks pada kode program dimana tiap baris merepresentasikan event atau transisi state dan kolomnya merepresentasikan state sedangkan elemennya merepresentasikan next state (Wijaya, 2010).

Kelebihan dari lookup table adalah kemudahannya untuk diimplementasikan dan pemeliharaannya lebih fleksibel. Implementasinya menggunakan matriks sehingga tidak begitu sulit menggunakan berbagai bahasa pemrograman untuk


mengimplementasikannya. Pemeliharaannya juga cukup fleksibel karena tabel atau matriks tersebut mudah untuk dibaca maksudnya dan dipahami (Wijaya, 2010).

Kelemahan dari lookup table adalah ketika diimplementasikan untuk sistem yang besar atau kompleks maka respon sistem akan jadi lebih lambat karena ukuran dimensi matriks yang digunakan menjadi besar sehingga memerlukan alokasi memori yang besar dan waktu proses lebih lama untuk mencari hubungan state pada matriks. Hal ini membuat implementasi lookup table jarang digunakan untuk sistem yang besar dan kompleks (Wijaya, 2010).

Salah satu contoh lookup tabel yang digunakan adalah seperti tampak pada Tabel 2.2.

Tabel 2.2: Contoh Lookup table FSM (Sumber: Yacoub, 1998) Unlock Coin

Broken

Unlock

Pass

Lock

Failed

Broken

Fixed

Lock

Broken Lock

Dengan menggunakan lookup table diatas, maka transisi state yang satu menuju state yang lainnya bisa lebih mudah dipahami. Implementasi matriks tersedia pada berbagai macam bahasa pemrograman. Implementasi lookup table pada sistem yang kecil banyak disukai karena kemudahan implementasi dan fleksibilitasnya (Van Houten: 2004).

Contoh lain penerapan FSM dengan lookup table adalah seperti pada gambar dibawah ini (Hariyanto, 2004).


digit start

digit

.

digit

S

A

B

Gambar 2.5 Contoh FSD (Sumber: Hariyanto, 2004)

FSD pada gambar 2.4 diatas memiliki formal sebagai berikut : M=(Q, ∑, δ, S, F) Dimana : Q = {S, A, B} ∑ = {digit, . } S=S F=B

Tabel 2.3 Contoh Tabel Transisi (Sumber: Hariyanto, 2004) Masukan

δ S

Digit

.

S

A

A

B

B

Tabel

transisi

merepresentasikan

B

state

struktur

(Lookup

finite

table)

automata

di

merupakan program

metode

untuk

komputer.

Ketika

direpresentasikan sebagai array di memori komputer, pengaksesan dapat dilakukan secara cepat serta struktur array ini sangat mudah untuk dimanipulasi di komputer (Hariyanto, 2004).


2.1.5.3 Object Oriented

Kelebihan penggunaan OOP pada FSM adalah fleksibilitasnya yang tinggi dan pemeliharaannya yang mudah baik pada sistem yang sederhana, menengah, maupun sistem yang kompleks (Yacoub, 1998: 1998). Selain itu juga mendapatkan manfaat dari salah satu kelebihan OOP yaitu penggunaan kembali kode yang telah diketik (code reusability) sehinga pengetikan kode menjadi lebih sedikit (Wijaya, 2010).

Salah satu alternatif implementasi Finite State Machine adalah menggunakan pemrograman berorientasi objek (Object Oriented Programming) atau yang sering disingkat sebagai OOP (Wijaya, 2010).

Kelemahan OOPFSM adalah hanya bisa diimplementasikan menggunakan bahasa pemrograman yang mendukung OOP seperti C++ dan Java. Selain itu diperlukan pemahaman yang teknis mengenai teknik pemrograman berorientasi objek (Wijaya, 2010).

Desain OOP biasanya direpresentasikan menggunakan UML (Universal Markup language) untuk menggambarkan variabel dan metode yang dimiliki oleh suatu class dan untuk menggambarkan relasi antara class yang satu dengan class yang lain (Wijaya, 2010).

Salah satu contoh desain OOFSM digambarkan pada Gambar 2.3. Pada Gambar 2.3 tersebut tampak relasi antara class yang satu dengan class yang lain.


Gambar 2.6 Contoh OOFSM untuk mesin minuman dalam kaleng (Sumber: Yacoub, 1998)

Desain pada FSM berbasis objek berdasarkan pemicu transisi state dibagi menjadi dua golongan yaitu state driven dan owner driven. Pada desain state driven, maka transisi state di picu pada saat program state sedang dijalankan. Semua metode atau subrutin yang mewakili seluruh aksi dan event ditempatkan pada class state dan entitas pengguna state yang akan membuat instance dari tiap state yang akan dialami oleh entitas tersebut. Sedangkan pada desain owner driven, maka transisi state dipicu pada saat terjadi event pada entitas, dan seluruh aksi dan event ditempatkan pada class entitas tersebut (Wijaya, 2010).

Contoh desain state driven transition ditunjukkan pada Gambar 2.4.

Gambar 2.7 Contoh OOPFSM Menggunakan State Driven Transition (Sumber: Yacoub, 1998)


Pertimbangan yang harus diperhatikan ketika membuat desain OOPFSM ada tiga hal yaitu (Wijaya, 2010): 1. Kemudahan untuk dipahami (understandability). 2. Kemudahan untuk

diamati mulai

dari desain

sampai

implementasi

(Traceability). 3. Fleksibel dan memungkinkan untuk dilakukan penambahan (Flexibility and extendsibility).

2.2

Bagan Alir (Flowchart)

Flowchart merupakan diagram yang memperlihatkan aliran kontrol seluruh sistem termasuk program, input, output, dan database. (Whitten, 1998). Dengan adanya flowchart, maka runtutan proses berjalannya suatu aplikasi dapat dilihat lebih jelas. Simbol-simbol FlowChart dapat dilihat pada Tabel 3.3.


Tabel 2.4 Simbol-simbol FlowChart

Simbol

Nama Terminator (Terminal)

Fungsi Menunjukkan awal dan akhir program

Preparation

Memberikan nilai awal pada suatu variabel

(Persiapan)

atau counter

Garis Alir

Menunjukkan arah aliran program

Proses

Proses perhitungan dan proses pengolahan data

Keputusan Operasi perbandingan logika Input/Ouput Data

Proses input output data, parameter dan informasi

Proses Terdefinisi

Proses yang detilnya dijelaskan terpisah, misalnya dalam bentuk subroutine.

Penghubung

Penghubung bagian-bagian FlowChart yang berada pada satu halaman.

Penghubung Halaman Struktur Case

Penghubung bagian-bagian FlowChart yang berada pada halaman berbeda. Memproses sebuah blok statemen pada salah satu kondisi case yang terpenuhi.


2.3

Interaksi Manusia Dengan Komputer

Mengapa interaksi manusia dengan komputer dibutuhkan?. Contoh: tombol pilihan save (menyimpan) dan delete (menghapus) pada menu di suatu aplikasi. Jika terjadi kesalahan pada penerapan pilihan ini, maka dapat menyebabkan kehilangan beberapa jam kerja atau sama dengan bencana. Dari sinilah sistem harus didesain dengan memperhatikan dan menghargai pekerjaan yang dilakukan orang sehari-hari (Subakti, 2006).

2.3.1 Definisi Interaksi Manusia Dengan Komputer

Bidang ilmu interaksi manusia dan komputer adalah ilmu yang mempelajari tentang bagaimana mendesain, mengevaluasi, dan mengimplementasikan sistem komputer yang interaktif sehingga dapat digunakan oleh manusia dengan mudah. Definisi interaksi manusia dan komputer sebuah hubungan antara manusia dan komputer yang mempunyai karakteristik tertentu untuk mencapai suatu tujuan tertentu dengan menjalankan sebuah sistem yang bertopengkan sebuah antarmuka (interface) (Ariyus,2007).

2.3.2 Prinsip Utama Mendesain Antarmuka (Interface)

Berikut ini beberapa hal yang menjadi prinsip utama mendesain antarmuka yang baik dengan memperhatikan karakteristik manusia & komputer (Hestiningsih, 2007) :

2.3.2.1 User compatibility

Antarmuka merupakan topeng dari sebuah sistem atau sebuah pintu gerbang masuk ke sistem dengan diwujudkan ke dalam sebuah aplikasi perangkat lunak. Oleh karena itu sebuah perangkat lunak seolah-olah mengenal penggunanya, mengenal karakteristik penggunanya, dari sifat sampai kebiasaan manusia secara umum. Desainer harus


mencari dan mengumpulkan berbagai karakteristik serta sifat dari pengguna karena antarmuka harus disesuaikan dengan pengguna yang jumlahnya bisa jadi lebih dari 1 dan mempunyai karakter yang berbeda. Hal tersebut harus terpikirkan oleh desainer dan tidak dianjurkan merancang antarmuka dengan didasarkan pada dirinya sendiri. Survey adalah hal yang paling tepat (Hestiningsih, 2007).

2.3.2.2 Product Compatibility

Sebuah aplikasi yang bertopengkan antarmuka harus sesuai dengan sistem aslinya. Seringkali sebuah aplikasi menghasilkan hasil yang berbeda dengan sistem manual atau sistem yang ada. Hal tersebut sangat tidak diharapkan dari perusahaan karena dengan adanya aplikasi perangkat lunak diharapkan dapat menjaga produk yang dihasilkan dan dihasilkan produk yang jauh lebih baik. Contoh : sistem melalui antarmuka diharapkan menghasilkan report/laporan serta informasi yang detail dan akurat dibandingkan dengan sistem manual (Hestiningsih, 2007).

2.3.2.3 Task Compatibility

Sebuah aplikasi yang bertopengkan antarmuka harus mampu membantu para pengguna dalam menyelesaikan tugasnya. Semua pekerjaan serta tugas-tugas pengguna harus diadopsi di dalam aplikasi tersebut melalui antarmuka. Sebisa mungkin pengguna tidak dihadapkan dengan kondisi memilih dan berpikir, tapi pengguna dihadapkan dengan pilihan yang mudah dan proses berpikir dari tugas-tugas pengguna dipindahkan dalam aplikasi melalui antarmuka. Contoh : Pengguna hanya klik setup, tekan tombol next, next, next, finish, ok untuk menginstal suatu perangkat lunak (Hestiningsih, 2007).


2.3.2.4 Work Flow Compatibility

Sebuah sistem sudah pasti mengapdopsi sistem manualnya dan didalamnya tentunya terdapat urutan kerja dalam menyelesaikan pekerjaan. Dalam sebuah aplikasi, software engineer harus memikirkan berbagai runutan rununtan pekerjaan yang ada pada sebuah sistem. Jangan sampai pengguna mengalami kesulitan dalam menyelesaikan pekerjaannya karena pengguna mengalami kebingungan ketika urutan pekerjaan yang ada pada sistem manual tidak ditemukan pada perangkat lunak yang dihadapinya. Selain itu pengguna jangan dibingungkan dengan pilihan-pilihan menu yang terlalu banyak dan semestinya menu-menu merupakan urutan dari runutan pekerjaan. Sehingga dengan workflow compatibility dapat membantu seorang pengguna dalam mempercepat pekerjaannya (Hestiningsih, 2007).

2.3.2.5 Consistency

Sebuah sistem harus sesuai dengan sistem nyata serta sesuai dengan produk yang dihasilkan. Banyak perusahaan dalam menjalankan sistemnya menggunakan sistem yang berbeda di setiap divisi dalam perusahaan tersebut. Ada pula yang menggunakan aplikasi yang sama di divisi yang berbeda, seringkali keseragaman dalam menjalankan sistem tidak diperhatikan. Oleh karena itu software engineer harus memperhatikan hal-hal yang bersifat konsisten pada saat merancang aplikasi khususnya antarmuka, contoh: penerapan warna, struktur menu, font, format desain yang seragam pada antarmuka di berbagai bagian, sehingga pengguna tidak mengalami kesulitan pada saat berpindah posisi pekerjaan atau berpindah lokasi dalam menyelesaikan pekerjaan. Hal itu didasarkan pada karakteristik manusia yang mempunyai pemikiran yang menggunakan analogi serta kemampuan manusia dalam hal memprediksi. Contoh : keseragaman tampilan toolbar pada Word, Excell, PowerPoint, Access hampir sama (Hestiningsih, 2007).


2.3.2.6 Familiarity

Sifat

manusia

mudah

mengingat

dengan

hal-hal

yang

sudah

sering

dilihatnya/didapatkannya. Secara singkat disebut dengan familiar. Antarmuka sebisa mungkin didesain sesuai dengan antarmuka pada umumnya, dari segi tata letak, model, dsb. Hal ini dapat membantu pengguna cepat berinteraksi dengan sisem melalui antarmuka yang familiar bagi pengguna (Hestiningsih, 2007).

2.3.2.7 Simplicity

Kesederhanaan perlu diperhatikan pada saat membangun antarmuka. Tidak selamanya antarmuka yang memiliki menu banyak adalah antarmuka yang baik. Kesederhanaan disini lebih berarti sebagai hal yang ringkas dan tidak terlalu berbelit. Pengguna akan merasa jengah dan bosan jika pernyataan, pertanyaan dan menu bahkan informasi yang dihasilkan terlalu panjang dan berbelit. Pengguna lebih menyukai hal-hal yang bersifat sederhana tetapi mempunyai kekuatan/bobot (Hestiningsih, 2007).

2.3.2.8

Direct Manipulation

Pengguna berharap aplikasi yang dihadapinya mempunyai media atau tools yang dapat digunakan untuk melakukan perubahan pada antarmuka tersebut. Pengguna ingin sekali aplikasi yang dihadapannya bisa disesuaikan dengan kebutuhan, sifat dan karakteristik pengguna tersebut. Selain itu, sifat dari pengguna yang suka merubah atau mempunyai rasa bosan. Contoh : tampilan warna sesuai keinginan (misal pink) pada window bisa dirubah melalui desktop properties, tampilan skin winamp bisa dirubah, dll (Hestiningsih, 2007).


2.3.2.9 Control

Prinsip control ini berkenaan dengan sifat pengguna yang mempunyai tingkat konsentrasi yang berubah-ubah. Hal itu akan sangat mengganggu proses berjalannya sistem. Kejadian salah ketik atau salah entry merupakan hal yang biasa bagi seorang pengguna. Akan tetapi hal itu akan dapat mengganggu sistem dan akan berakibat sangat fatal karena salah memasukkan data 1 digit/1 karakter saja informasi yang dihasilkan sangat dimungkinkan salah. Oleh karena itu software engineer haruslan merancang suatu kondisi yang mampu mengatasi dan menanggulangi hal-hal seperti itu. Contoh : “illegal command”, “can’t recognize input” sebagai portal jika terjadi kesalahan (Hestiningsih, 2007).

2.3.2.10 WYSIWYG WYSIWYG = what you see is what you get = apa yang didapat adalah apa yang dilihatnya. Contoh : apa yang tercetak di printer merupakan informasi yang terkumpul dari data-data yang terlihat di layar monitor pada saat mencari data. Hal ini juga perlu menjadi perhatian software engineer pada saat membangun antarmuka. Informasi yang dicari/diinginkan harus sesuai dengan usaha dari pengguna pada saat mencari data dan juga harus sesuai dengan data yang ada pada sistem (perangkat lunak). Jika sistem mempunyai informasi yang lebih dari yang diinginkan pengguna, hendaknya dibuat pilihan (optional) sesuai dengan keinginan pengguna. Bisa jadi yang berlebihan itu justru tidak diinginkan pengguna. Yang mendasar disini adalah harus sesuai dengan kemauan dan pilihan dari pengguna (Hestiningsih, 2007).

2.3.2.11 Flexibility

Fleksibel merupakan bentuk dari dari solusi pada saat menyelesaikan masalah. Software engineer dapat membuat berbagai solusi penyelesaian untuk satu masalah. Sebagai contoh adanya menu, hotkey, atau model dialog yang lainnya (Hestiningsih, 2007).


2.3.2.12 Responsiveness

Setelah memberikan inputan atau memasukkan data ke sistem melalui antarmuka, sebaiknya sistem langsung memberi tanggapan/respon dari hasil data yang diinputkan. Selain teknologi komputer semakin maju sesuai dengan tuntutan kebutuhan manusia, perangkat lunak yang dibangun pun harus mempunyai reaksi tanggap yang cepat. Hal ini didasari pada sifat manusia yang semakin dinamis / tidak mau menunggu (Hestiningsih, 2007).

2.3.2.13 Invisible Technology

Secara umum, pengguna mempunyai keingintahuan sebuah kecanggihan dari aplikasi yang digunakannya. Untuk itu aplikasi yang dibuat hendaknya mempunyai kelebihan yang tersembunyi. Bisa saja kelebihan itu berhubungan dengan sistem yang melingkupinya atau bisa saja kecanggihan atau kelebihan itu tidak ada hubungannya. Contoh : sebuah aplikasi mempunyai voice recognize sebagai media inputan, pengolah kata yang dilengkapi dengan language translator (Hestiningsih, 2007).

2.3.2.14 Robustness

Interaksi manusia dan komputer (pembangunan antarmuka) yang baik dapat berupa frase-frase menu atau error handling yang sopan. Kata yang digunakan harus dalam kondisi bersahabat sehingga nuansa user friendly akan dapat dirasakan oleh pengguna selama menggunakan sistem . Contoh yang kurang baik : YOU FALSE !!!, BAD FILES !!!, FLOPPY ERROR, dsb. Akan lebih baik jika BAD COMMAND OR FILES NAMES, DISK DRIVE NOT READY,dll (Hestiningsih, 2007).


2.3.2.15 Protection

Suasana nyaman perlu diciptakan oleh software engineer di antarmuka yang dibangunnya. Nyaman disini adalah suasana dimana pengguna akan betah dan tidak menemui suasana kacau ketika pengguna salah memasukkan data atau salah eksekusi. Seorang pengguna akan tetap merasa nyaman ketika dia melakukan kesalahan, misal ketika pengguna melakukan deleting atau menghapus files tanpa sengaja tidaklah menjadi kekacauan yang berarti karena misal ada recovery tools seperti undo, recycle bin, dll atau “are you sure....” . Proteksi disini lebih menjaga kenyamanan pengguna ketika menggunakan sistem khususnya data-data berupa file (Hestiningsih, 2007).

2.3.2.16 Ease Of Learning And Ease Of Use

Kemudahan dalam mengoperasikan perangkat lunak hanya dengan memandangi atau belajar beberapa jam saja. Kemudahan dalam memahami icon, menu-menu, alur data perangkat lunak, dsb. Sesudah mempelajari, pengguna dengan mudah dan cepat menggunakan perangkat lunak tersebut. Jika sudah memahami tentunya akan membantu proses menjalankan sistem dengan cepat dan baik (Hestiningsih, 2007).


BAB 2 TINJAUAN PUSTAKA

Recommend Documents