Gambar 2.6 Lembar Penilaian MBO Rivai dan Sagala, 2009
2.5 Absensi
Absensi adalah system pencatatan yang dilakukan oleh orang tertentu untuk mengetahui daftar hadir mereka dalam suatu tempat di
sebuah organisaasi Priyanto, 2008. Pada perinsipnya jenis-jenis absensi bisa digolongkan menjadi 2 bagian, yaitu : Jenis Manual dan Non Manual
Menggunakan Alat a. Absensi Manual
Absensi jenis manual, adalah absensi yang sepenuhnya dikerjakan langsung oleh manusia. Absensi manual bisa terdiri dari :
1. Absensi Harian yaitu absensi yang dikerjakan setiap hari. 2. Absensi Bulanan yaitu absensi yang dikerjakan setiap bulan.
3. Absensi Tahunan yaitu absensi yang dikerjakan setiap satu tahun.
b. Absensi Otomatik Pada era globalisasi seperti sekarang ini dalam membuat kita dapat
menggunakan alat bantu elektronik. Adapun penginputanpengisian data untuk absensi jenis ini dapat berupa :
1. ID Card 2. Nomor Induk Pegawai
3. Sidik jari finger print banyak jenis peralatan mesin yang biasa dipergunakan di dalam
pengabsenan elektrik.
2.6 Metodologi Penelitian
2.6.1 Metodologi Pengumpulan Data 2.6.1.1 Observasi
Obsevasi merupakan teknik atau pendekatan untuk mendapatkan data primer dengan cara mengamati langsung obyek datanya. Pendekatan observasi
dapat diklarifikasi ke dalam observasi perilaku dan observasi non perilaku Jogiyanto, 2008.
Observasi Perilaku
Observasi perilaku terdiri sebagai berikut ini: 1. Analisis Nonverbal.
Observasi analisis nonverbal dapat dilakukan pada gerakan bukan ucapan, seperti misalnya observasi terhadap bahasa tubuh seseorang, ekspresi
wajah dan lain sebagainya.
2. Analisis Lingistik. Observasi analisis linguistic dilakukan pada analisis bahasa yang
digunakan oleh seseorang atau beberapa orang yang sedang berinteraksi. 3. Analisis Linguistic Ekstra
Observasi analisis lingustik ekstra dilakukan dengan mengobservasi empat dimensi , yaitu vocal termasuk tinggi nada, kekerasan, kualitas, tempo
termasuk kecepatan bicara, durasi, dan ritmenya, interaksi termasuk tendensi untuk mengintrupsi pembicaraan, mendominasi dan cara bicara
termasuk vokabulari, dialog dan ekspresi bicara. 4. Analisis Spasial.
Observasi analisis spasial mengobservasi langsung hubungan antara orang secara fisik. Contohnya adalah observasi tentang bagaimana salesman
secara fisik mendekati pelanggan.
Observasi Non-Perilaku
Observasi Non-Perilaku terdiri sebagai berikut ini: 1. Analisis Catatan.
Observasi analisis catatan dapat berupa pengumpulan data baik dari catatan data sekarang atau catatan data historis.
2. Analisis Kondisi Fisik. Observasi analisis kondisi fisik dilakukan pada data kondisi fisik seperti
fisik sediaan, misalnya kondisi keamanan pabrik.
3. Analisis Proses Fisik. Observasi analisis proses fisik dapat berupa observasi pada time and
mantion dari suatu proses, prosedur-prosedu akuntasi dan lain sebagainya.
2.6.1.2 Wawancara
Wawancara adalah komunikasi duaarah untuk mendapatkan data dari responden. Wawancara dapat berpa wawancara personal, wawancara intersep, dan
wawancara telepon Jogiyanto, 2008. 1. Wawancara personal.
Wawancara personal yaitu wawancara dengan melakukan tatap muka langsung dengan responden.
2. Wawancara Intersep. Wawancara intersep yaitu sama dengan wawancara personal tetapi
responden-responden dipilih dari lokasi umum. 3. Wawancara Telepon
Wawancara telepon yaitu wawancara yang dilakukan lewat telepon. Wawancara lewat telepon mulai banyak dilakukan terutama jika
respondennya cukup banyak dan menyebar, dan tidak dapat didatangi satu persatu. Wawancara telepon juga dapat diprogramkan lewat komputer.
2.6.1.3 Studi pustaka
Studi pustaka dilakukan dengan membaca buku-buku yang berkaitan dengan materi penelitian Nazir, 2005.
2.6.2 Metodologi Pengembangan dan Alat Bantu Perancangan
2.6.2.1 Software Development Life Cycle SDLC
Struktur SDLC pertama, yang kita kenal sebagai classical SDLC, terdiri dari empat tahap yaitu planning, analysis, design, dan implementation. Planning
terdiri dari berbagai hal yang mendefinisikan pemecahan masalah atau menspesifikasikan objek dari sistem yang baru. Analysis terdiri dari hal
mempelajari sistem untuk memahami secara dalam sistem yang telah ada. Design terdiri dari mendefinisikan proses dan data yang akan digunakan di dalam sistem.
Implementation memiliki kegiatan seperti menyiapkan software, membangung file data, perakitan hardware, dan penginstalasian sistem baru. Gambar 2.7
mengilustrasikan bagaimana tahapan tersebut dimaksudkan untuk dilakukan secara berurutan. Istilah waterfal development life cycle digunakan saat ini untuk
mendeskripsikan classical SDLC karena hal tersebut berdasarkan asumsi pada tiap tahap tersebut dijalankan pada satu waktu dalam urutan tertentu Everett dan
McLeod, 2007.
Gambar 2.7 Waterfall development life cycle Everett dan McLeod,
2007
2.6.2.2 Metode Pengembangan Rapid Application Development RAD
Metode pengembangan sistem yang penulis gunakan adalah metode Rapid Application Development RAD. RAD adalah suatu pendekatan berorientasi
objek terhadap pengembangan sistem yang mencakup suatu metode pengembangan
perangkat lunak.
RAD secara
konseptual bertujuan
mempersingkat waktu yang biasanya diperlukan da lam Siklus Hidup Pengembangan Sistem SHPS tradisional antara perancangan dan penerapan
sistem informasi. Kendall dan Kendall, 2008 Ada tiga fase dalam RAD yang melibatkan penganalisis dan pengguna
dalam tahap penilaian, perancangan, dan penerapan. Gambar 2.8 menggambarkan ketiga fase ini. RAD melibatkan pengguna dalam setiap bagian upaya
pengembangan, dengan partisipasi mendalam dalam bagian perancangan bisnis. Fase-Fase pada RAD antara lain Kendall dan Kendall, 2008 :
Gambar 2.8 Fase-fase RAD Kendall dan Kendall, 2008
Requirement Planning Phase
User Design Phase
Construction Phase
Cutover Phase
Gambar 2.9 Fase RAD Martin Kendall dan Kendall, 2008
Pada Gambar 2.9 kita dapat melihat konseptualisasi dari fase RAD James Martin. Pada fase pertama Martin mendiskusikan requirement planning
perencanaan kebutuhan. Disini high-level user memutuskan fungsi dari aplikasi yang akan ditampilkan.
Pada fase kedua, merupakan fase user design, Martin mengkarakterisasi user untuk saling berhubungan dalam mendiskusikan aspek nontechnical design
pada sistem, dengan dukungan analysts. RAD fase Design Workshop menggabungkan fase user design dan fase construction menjadi satu, karena
interaksi yang tinggi dan proses sifat visual design-and-refine dibutuhkan di dalam interaktif.
Di fase construction berjalan banyak aktifitas yang berbeda. Desain yang buat pada fase sebelumnya akan dikembangkan oleh tools RAD. Setelah fungsi
baru telah ada, fungsi akan memperlihatkan pada user untuk berinteraksi, berkomentar, dan me-review. Dengan tools RAD, analyst dapat membuat
perubaha berkelanjutan pada desain aplikasi. Pada Martin fase keempat, yaitu fase cutover, aplikasi baru yang telah
dikembangkan akan menggantikan sistem yang lama. Selama sistem berjalan secara paralel dengan aplikasi yang lama, sistem yang baru akan diuji, user
dilatih, dan prosedur organisasi berubah sebelum cutover berlangsung.
2.6.2.2.1 Syarat-syarat dan tahap pengembangan 1. Tahap Perencanaan Syarat
Requirement Planning Fase Perencanaan Syarat
. Dalam fase ini, pengguna dan penganalisis bertemu untuk mengidentifikasikan tujuan-tujuan aplikasi atau sistem serta untuk
mengidentifikasi syarat-syarat informasi yang ditimbulkan dari tujuan-tujuan tersebut. Fase ini memerlukan peran aktif mendalam dari kedua kelompok
tersebut; tidak hanya menunjukkan proposal atau dokumen. Selain itu, juga melibatkan pengguna dari beberapa level yang berbeda dalam organisasi. Dalam
fase ini pula, saat syarat-syarat informasi sedang disebut-sebut, Anda bisa bekerja dengan CIO bila ini merupakan sebuah organisasi besar serta dengan para
perencana strategik, khususnya bila Anda bekerja dengan sebuah aplikasi e- commerce yang berusaha meneruskan tujuan-tujuan strategik organisasi. Orientasi
dalam fase ini ialah menyelesaikan problem-problem perusahaan. Meskipun teknologi informasi dan sistem bisa mengarahkan sebagian dari sistem yang
diajukan, fokusnya akan selalu tetap pada upaya pencapaian tujuan-tujuan perusahaan Kendall dan Kendall, 2008.
Fase Requirement Planning menggabungkan fase Planning dan fase Systems Analysis di dalam elemen SDLC Systems Developement Life Cycle.
Shelly dan Rosenblatt, 2011. Elemen SDLC pada fase planning dan analisis adalah sebagai berikut Whitten dan Bentley, 2008, yaitu:
1. Identifikasi kebutuhan sistem Menentukan identifikasi kebutuhan sistem untuk menentukan tujuan
aplikasi atau sistem, menentukan syarat-syarat informasi dari identifikasi
tujuan serta batasan sistem. 2. Analisis sitem yang berjalan
Menjelaskan sistem yang dipakai perusahaan dalam melakukan proses kegiatan penggajian dan penilaian kinerja karyawan.
3. Identifikasi masalah Menjelaskan masalah yang ada pada sistem yang sedang berjalan
4. Analisis sistem usulan Menguraikan
tentang beberapa
usulan yang
dapat membantu
menyelesaikan permasalahan yang ada pada sistem yang berjalan, serta menentukan batasan ruang lingkup sistem yang akan dibangun
2. Tahap Desain Workshop Design RAD
Workshop Desain RAD. Fase ini merupakan fase perancangan serta
perbaikan yang dapat digambarkan sebagai sebuah workshop. Selama workshop desain RAD, pengguna merespon prototype yang sedang dikerjakan dan
penganalisis memperbaiki modul desain berdasarkan respon pengguna. Format workshop sangat mengagumkan dan memberikan dorongan, dan jika pengguna
serta penganalisis merupakan orang yang berpengalaman, maka tidak diragukan lagi bahwa usaha kreatif ini dapat mendorong pengembangan sampai pada tingkat
terakselerasi. RAD fase Design Workshop pada konseptualis fase RAD James Martin menggabungkan fase user design dan fase construction menjadi satu,
karena interaksi yang tinggi dan proses sifat visual design-and-refine dibutuhkan di dalam interaktif Kendall dan Kendall, 2008.
Di fase construction berjalan banyak aktifitas yang berbeda. Desain yang buat pada fase sebelumnya akan dikembangkan oleh tools RAD. Setelah fungsi
baru telah ada, fungsi akan memperlihatkan pada user untuk berinteraksi, berkomentar, dan me-review. Dengan tools RAD, analyst dapat membuat
perubahan berkelanjutan pada desain aplikasi Kendall dan Kendall, 2008. A.
Desain Proses Proses sistem informasi merespons kejadian dan kondisi bisnis dan
mentransformasi data menjadi informasi yang berguna. Pemodelan proses membantu memahami interaksi dengan lingkungan sistem, sistem lain, dan
proses lain Whitten dan Bentley, 2008. Model proses paling sederhana dari sebuah sistem didasarkan pada
input, output, dan sistem itu sendiri yang ditampilkan sebagai proses. Simbol proses mendefinisikan batasan sistem. Sistem tersebut berada
dalam batasan, sedangkan lingkungan sistem berada di luar batasan sistem tersebut. Sistem mempertukarkan input dan output dengan lingkungannya.
Karena lingkungan selalu berubah, maka sistem yang didesain dengan baik memiliki loop umpan balik dan control yang memungkinkan sistem
menyesuaikan dirinya dengan perubahan kondisi Whitten dan Bentley, 2008.
Proses adalah kerja yang dilakukan pada atau sebagai respon terhadap aliran data masuk atau kondisi. Sinonimnya adalah transformasi.
Proses logika adalah pekerjaan atau tindakan yang harus dilakukan tidak peduli bagaimana mengimplementasikan sistem tersebut. Tiap proses
logika adalah diimplementasikan sebagai satu proses fisik atau lebih yang dapat menyertakan pekerjaan yang dilakukan oleh orang, pekerjaan yang
dilakukan oleh robot atau mesin, atau pekerjaan yang dilakukan oleh perangkat lunak komputer. Proses logika terdiri dari fungsi, kejadian, dan
proses elementer Whitten dan Bentley, 2008. Fungsi function adalah kumpulan kegiatan yang saling terkait dan
terus-menerus pada suatu bisnis.Fungsi tidak memiliki awal dan akhir; melainkan hanya bekerja terus-menerus pada saat dibutuhkan Whitten dan
Bentley, 2008. Kejadian event adalah unit kerja logika yang harus diselesaikan
secara keseluruhan. Suatu kejadian dipicu oleh input diskrit dan diselesaikan pada saat proses merespons dengan output yang sesuai.
Kejadian kadang disebut transaksi. Fungsi terdiri dari proses yang merespons kejadian Whitten dan Bentley, 2008.
Proses event selanjutnya di dekomposisi menjadi proses elementer yang mengilustrasikan secara detail bagaimana sistem harus merespons
suatu event. Elementary process proses elementer adalah kegiatan atau tugas detail dan diskrit yang dibutuhkan untuk melengkapi respons
terhadap suatu eventWhitten dan Bentley, 2008. Proses pemodelan use-case persyaratan Whitten dan Bentley,
2008:
1. Mengidentifikasi Pelaku Bisnis
Dengan memusatkan perhatian pada pelakunya, dan berkonsentrasi pada bagaimana sistem itu akan digunakan dan
bagaimana akan dibangun. Mengidentifikasikan pelaku bisnis juga dapat membantu menyaring dan mendefinisikan lebih lanjut
lingkup dan batasan sistem Armour dan Miller, 2001. Berikut beberapa pertanyaan untuk mencari pelaku bisnis
Whitten dan Bentley, 2008: Siapa atau apa yang menyediakan input ke dalam sistem?
Siapa atau apa yang menerima output dari sistem? Antarmuka apa yang dibutuhkan bagi sistem yang lain?
Apakah ada kejadian yang dipicu secara otomatis pada waktu yang telah ditentukan sebelumnya?
Siapa yang akan mengurusi informasi dalam sistem? 2.
Mengidentifikasi Use-case Persyaratan Bisnis Use-casemenggambarkan
bagaimana para
pelaku sebenarnya berinteraksi dengan sistem, maka teknik yang bagus
untuk mencari use-case persyaratan bisnis adalah dengan menyelidiki
para pelaku
dan bagaimana
mereka akan
menggunakan sistem tersebut. Berikut beberapa pertanyaan untuk mencari use-case Whitten dan Bentley, 2008:
Apa tugas utama pelaku tersebut?
Informasi apayang dibutuhkan pelaku untuk sistem?
Apakah sistem tersebut perlu menginformasikan
kepada pelaku tentang segala perubahan atau kejadian yang telah terjadi?
Apakah
ada kebutuhan
par pelaku
untuk menginformasikan segala perubahan yang terjadi
atau kejadian-kejadian yang muncul? 3.
Membuat Diagram Model Use-case Setelah use-case dan pelaku teridentifikasi, diagram use-
case pun dapat digunakan untuk menggambarkan secara grafis lingkup dan batasan sistem Whitten dan Bentley, 2008.
4. Mendokumentasikan Naratif Use-case Persyaratan Bisnis
Sebelum mempersiapkan
naratif, dilakukan
pendokumentasian terlebih dahulu pada level tinggi high level agar dapat memahami event dan besar sistem. Naratif use-case
mencakup beberapa item berikut Whitten dan Bentley, 2008: Pengarang
– Nama individu yang membantu dalam penulisan use-case dan yang menyediakan titik kontak ke
setiap orang yang memerlukan informasi tambahan tentang use-case tersebut.
Tanggal – Tanggal use-case dimodifikasi terakhir kali.
Versi – Versi terbaru use-case.
Nama use-case – Nama use-caseharus menunjukkan
tujuan yang akan dipenuhi use-case tersebut.Nama tersebut sebaiknya mulai dengan kata kerja.
Tipe use-case – Tipe use-case ini adalah business-
oriented dan merefleksikan tampilan high-level dari behavior sistem yang diinginkan.
Use-case ID – Identifier yang secara unik
mengidentifikasi use-case. Prioritas
– Prioritas mengkomunikasikan pentingnya use- case dalam konteks high, medium, atau low.
Sumber – Sumber mendefinisikan entitas yang memicu
pembuatan use-case. Pelaku bisnis primer
– Pelaku bisnis primer adalah stakeholder yang mendapatkan keuntungan utama dari
eksekusi use-case dengan menerima nilai terukur atau teramati.
Pelaku peserta lain – Pelaku lain yang berpartisipasi
dalam use-case untuk mencapai tujuannya meliputi pelaku penginisiasi, pelaku pemfasilitasi, pelaku server
atau receiver, dan pelaku sekunder. Stakeholder yang berminat
– stakeholder adalah siapapun yang berperan dalam pengembangan dan
operasi sistem perangkat lunak. Stakeholder yang
berminat adalah orang selain pelaku yang tertarik dengan tujuan use-case.
Deskripsi – deskripsi ringkasan pendek yang berisi
sejumlah kalimat yang menunjukkan secara garis besar tujuan use-case dan berbagai kegiatannya.
Proses pemodelan objek ialah sebagai berikut Whitten dan Bentley, 2008:
1. Memodelkan fungsi sistem
Dalam memodelkan fungsi sistem perlu memperluas model use-case analisis dengan melakukan langkah-langkah berikut:
Mengidentifikasi, mendefinisikan,
dan mendokumentasikan pelaku-pelaku baru
Mengidentifikasi, mendefinisikan,
dan mendokumentasikan use-case baru
Mengidentifikasi semua Reuse yang mungkin Memperbaiki diagram model use-case jika perlu
Mendokumentasi naratif use-case analisis sistem
2. Menemukan dan mengidentifikasi objek bisnis
Langkah 1: Menemukan Objek Potensial
Langkah ini diselesaikan dengan cara meninjau setiap use-case untuk menemukan kata-kata benda yang berhubungan dengan
keseluruhan bisnis atau event.
Langkah 2: Menyeleksi Objek yang Diusulkan Tidak semua kata benda yang ditemukan dalam setiap use-case
menggambarkan objek bisnis yang ada dalam lingkup domain masalah.Tiap-tiap kata benda tersebut harus dianalisis kembali,
agar dapat ditentukan kata benda mana saja yang dipertahankan atau dihapus.
3. Mengorganisir Objek dan Mengidentifikasi Hubungan Objek Langkah 1: Mengidentifikasi Asosiasi dan Multiplicity
Langkah 2: Mengidentifikasi Hubungan Generalisasispesialisasi Langkah 3: Mengidentifikasi Hubungan Agregasi
Langkah 4: Menyiapkan Diagram Kelas
B. Desain Input
Data capture adalah identifikasi dan penambahan data baru. Penambahan data baru tersebut dapat berasal dari source
document.Source document adalah form yang digunakan untuk menyimpan transaksi perusahaan, khususnya data-data yang ada
pada transaksi tersebut Whitten dan Bentley, 2008.
Desain source document sangat membutuhkan kecermatan, layout dan keterbacaan akan mempengaruhi kecepatan data entry.
Data entry adalah suatu proses translasi source data atau dokumen ke dalam format yang mudah dibaca oleh komputer Whitten dan
Bentley, 2008.. Berikut langkah-langkah proses desain input Whitten dan
Bentley, 2008: 1. Mengidentifikasi
input sistem
dan memeriksa
persyaratan logika. 2. Memilih control GUI yang sesuai.
3. Mendesain, memvalidasi, dan mengetes input. 4. Mendesain source document jika perlu.
C. Desain Output
Output menggambarkan
informasi bagi
pengguna sistem.Output adalah komponen yang paling dapat dilihat dari
sistem informasi yang bekerja.Oleh karena itu, output menjadi basis penilaian akhir manajemen terhadap kesuksesan sebuah
sistem Whitten dan Bentley, 2008. Output dapat digolongkan ke dalam dua karakteristik
Whitten dan Bentley, 2008, yaitu: 1. Distribusi dan audiens output
Salah satu cara untuk menggolongkan output adalah dengan melihat distribusi mereka apakah ke dalam atau di luar perusahaan,
dan orang-orang yang membaca dan menggunakan output. Internal output digunakan untuk para pemilik dan pengguna sistem dalam
sebuah perusahaan Whitten dan Bentley, 2008. Berikut tiga jenis output internal Whitten dan Bentley,
2008: 1.
detailed report – output internal yang menggambarkan
informasi dengan sedikit atau bahkan tanpa pemeriksaan. 2.
summary report – output internal yang mengelompokkan
berbagai informasi bagi manajer. 3.
exception report – output internal yang menyaring data
untuk menunjukkan informasi yang berisi perkecualian- perkecualian atau standar tertentu.
Eksternal output merupakan kebalikan dari internal output. Output ini ditujukan kepada konsumen, pemasok, mitra bisnis, dan
badan pemerintahan. Output eksternal menyimpulkan dan melaporkan transaksi bisnis Whitten dan Bentley, 2008.
2. Metode implementasinya.
Printed output – media yang sering digunakan untuk output
computer adalah kertas – printed output. Printed output dapat
dihasilkan oleh impact printer
Screen output – media output komputer yang mengalami
pertumbuhan paling cepat adalah display online dari informasi pada peralatan display visual.
Berikut beberapa langkah proses desain output Whitten dan Bentley, 2008:
1. Mengidentifikasi output sistem dan meninjau kembali persyaratan logika.
2. Menentukan persyaratan output fisik. 3. Desain, lakukan validasi, dan uji output.
D. Desain Database
Tujuan desain database adalah sebagai berikut Whitten dan Bentley, 2008:
Database harus menyediakan penyimpangan yang efisien, pembaruan, dan perolehan kembali sebuah data.
Database harus andal – data yang disimpan harus
memiliki integritas tinggi untuk membuat pengguna mempercayai data.
Database harus dapat diadaptasi dan diskala untuk persyaratan dan aplikasi baru yang belum tampak atau
muncul. Desain database digambarkan sebagai sebuah model
khusus yang disebut skema database.Skema database adalah
model fisik atau cetak biru untuk sebuah database.Skema ini menggambarkan implementasi teknis dari model data logis
Whitten dan Bentley, 2008. Skema database relasional menentukan struktur database
dalam hal tabel, key, index, dan aturan-aturan integritas.Skema database menentukan rincian-rincian berdasarkan kemampuan,
terminologi, dan batasan dari sistem manajemen database yang telah dipilih.Setiap DBMS mendukung berbagai tipe data yang
berbeda, aturan-aturan integritas, dan sebagainya Whitten dan Bentley, 2008.
Integritas data menyediakan kontrol-kontrol internal pada sebuah database.Paling sedikit ada tiga tipe integritas data yang
harus didesain pada semua database Whitten dan Bentley, 2008. Key integrity
– setiap tabel harus memiliki primary key.Primary key harus dikontrol supaya tidak ada dua record pada
tabel yang punya nilai primary key yang sama. Selain itu, primary key pada sebuah record tidak pernah boleh memiliki nilai Null.
Nilai tersebut akan mengalahkan tujuan primary key yang secara unik mengidentifikasikan recordWhitten dan Bentley, 2008.
Domain integrity – kontrol-kontrol yang sesuai harus
didesain untuk memastikan bahwa tidak ada field pada sebuah nilai di luar range nilai illegal Whitten dan Bentley, 2008.
Referential integrity – arsitektur database relasional
mengimplementasikan hubungan antara record pada tabel melalui foreign keys. Penggunaan foreign key meningkatkan fleksibilitas
dan skalabilitas beberapa database, tetapi juga meningkatkan risiko kesalahan-kesalahan integritas referensial.Kesalahan integritas
referensial muncul saat nilai foreign key pada satu tabel tidak sesuai dengan nilai primary key pada tabel terkait Whitten dan
Bentley, 2008.
E. Desain Interface
Proses desain interface dimulai dengan menentukan jenis pengguna, human factor, dan petunjuk human engineering yang
akan mempengaruhi desain antarmuka pengguna. Jenis pengguna sistem system user diklasifikasikan
menjadi dua Whitten dan Bentley, 2008, yaitu: Expert User, adalah pengguna komputer yang
berpengalaman yang banyak menghabiskan waktunya untuk menggunakan program aplikasi khusus.
Novice User atau Casual User, adalah pengguna komputer yang pengalamannya lebih sedikit, atau bahkan
pada saat-saat tertentu saja.
Adapun masalah human factor adalah sebagai berikut Whitten dan Bentley, 2008:
Terlalu banyak menggunakan akronim komputer Desain yang tidak jelas atau kurang intuitif
Tidak mampu membedakan antara tindakan pilihan “Apa yang harus saya lakukan selanjutnya?”
Pendekatan pemecahan masalah yang tidak konsisten Ketidakkonsistenan desain
Beberapa faktor human engineering penting harus digabungkan pada desain Whitten dan Bentley, 2008:
Pengguna sistem harus selalu menyadari apa yang harus dilakukan selanjutnya. Beberapa situasi membutuhkan
beberapa tipe feedback: Screen harus diformat sehingga segala jenis tipe
informasi, perintah, dan pesan selalu muncul pada area tampilan umum yang sama.
Pesan, perintah, atau informasi harus ditampilkan dengan cukup panjang secukupnya sehingga pengguna sistem
dapat membacanya. Gunakan atribut tampilan display attributes dengan
hemat.
Nilai yang salah pada field dan jawaban yang harus dimasukkan oleh pengguna harus ditentukan.
Berkenaan dengan error, pengguna seharusnya tidak diperkenankan untuk meneruskan langkah sebelum
memperbaiki error tersebut. Jika pengguna melakukan sesuatu yang dapat
menimbulkan akibat yang parah, maka keyboard harus dikunci untuk mencegah semua input lain dan perintah
untuk memanggil analis atau technical support harus ditampilkan.
Antarmuka Menu-Driven ialah strategi dialog yang mengharuskan pengguna memilih sebuah action dari menu pilihan.
Berikut langkah proses desain antarmuka pengguna adalah sebagai berikut Whitten dan Bentley, 2008:
Petakan dialog antarmuka pengguna, sebuah antarmuka pengguna dapat melibatkan banyak screen. Beberapa
screen dapat muncul berulang sampai kondisi yang diinginkan tercapai agar tidak menimbulkan masalah
yang lebih sulit. State Transition Diagram STD digunakan untuk menggambarkan urutan dan variasi
screen yang dapat terjadi selama satu sesi pengguna. Membuat prototype dialogue dan antarmuka pengguna
Dapatkan feedback dari pengguna
3. Tahap Implementasi Implementation
Fase Implementasi . Dalam gambar 2.8 ditunjukkan bahwa Anda dapat
melihat bahwa penganalisis bekerja dengan para pengguna secara intens selama workshop untuk merancang aspek-aspek bisnis dan nonteknis dari perusahaan.
Segera sesudah aspek-aspek ini disetujui dan sistem-sistem dibangun dan disaring, sistem-sistem baru atau bagian dari sistem diuji coba dan kemudian diperkenalkan
kepada organisasi. Karena RAD dapat digunakan untuk menciptakan aplikasi- aplikasi e-commerce baru dimana dalam hal itu sistem lama tidak digunakan lagi,
seringnya tidak perlu dan memang tidak bisa menjalankan sistem lama dan sistem baru secara paralel sebelum implementasi Kendall dan Kendall, 2008.
A. Fase Konstruksi
Tujuan fase konstruksi adalah untuk membangun dan menguji sebuah sistem fungsional yang memenuhi persyaratan bisnis dan desain
dan untuk mengimplementasi antarmuka sistem yang baru.Aspek utama dari fase ini ialah pemrograman sistem Whitten dan Bentley, 2008.
B. Fase Implementasi
Kemampuan pengujian perangkat lunak hanya seberapa mudah program
komputer dapat
diuji.Karakteristik sebagai
berikut menyebabkan perangkat lunak diuji.
Pengoperasian.Semakin baik bekerja, lebih efisien dapat diuji.
Jika sistem yang dirancang dan dilaksanakan dengan kualitas dalam
pikiran, relatif sedikit bug akan memblokir pelaksanaan tes, yang memungkinkan pengujian untuk kemajuan tanpa cocok dan mulai.
Observabilitas.Apa yang Anda lihat adalah apa yang Anda uji.
Input disediakan sebagai bagian dari pengujian menghasilkan output yang berbeda. Menyatakan sistem dan variabel yang terlihat atau queriable
selama eksekusi.Keluaran
yang salah
dengan mudah
diidentifikasi.Kesalahan internal
dideteksi secara
otomatis dan
dilaporkan.Source code dapat diakses.
Pengendalian.Semakin baik kita dapat mengontrol perangkat
lunak, semakin
banyak pengujian
dapat diotomatisasi
dan dioptimalkan.Perangkat lunak dan Pernyataan perangkat keras dan
variabel dapat dikontrol langsung oleh teknisi tes.Uji dapat dengan mudah ditentukan, diotomatisasi, dan diproduksi ulang.
Decomposability.Dengan mengontrol ruang lingkup pengujian,
kita bisa lebih cepat mengisolasi masalah dan melakukan pengujian ulang yang lebih cerdas.Sistem perangkat lunak dibangun dari modul
independen yang dapat diuji secara independen.
Kemudahan.Semakin sedikit ada untuk menguji, semakin cepat
kita bisa mengujinya.Program ini harus menunjukkan kemudahan fungsional, kemudahan struktural, dan kode kemudahan.
Stabilitas.Semakin sedikit perubahan, semakin sedikit gangguan
pengujian.Perubahan ke perangkat lunak jarang terjadi, dikendalikan saat
mereka melakukan dan tidak membatalkan tes yang ada.Pemulihan perangkat lunak dengan baik dari kegagalan.
Dimengerti.Semakin banyak informasi yang kita miliki, semakin
cerdas kita akan menguji.Desain arsitektur dan ketergantungan antara komponen
internal, eksternal,
dan berbagi
dipahami dengan
baik.Dokumentasi teknis adalah langsung diakses, terorganisasi dengan baik, spesifik, rinci, dan akurat.Perubahan desain dikomunikasikan kepada
penguji.
C. Uji karakteristik:
1. Tes yang baik memiliki probabilitas tinggi untuk menemukan kesalahan. Untuk mencapai tujuan ini, penguji harus memahami
perangkat lunak dan berusaha untuk mengembangkan gambaran mental
tentang bagaimana
perangkat lunak
mungkin gagal.Idealnya, kelas kegagalan yang diperiksa.Misalnya, satu
kelas dari potensi kegagalan di GUI graphical user interface adalah kegagalan mengenali posisi mouse yang tepat. Satu set tes
akan dirancang untuk melaksanakan mouse dalam upaya untuk menunjukkan kesalahan dalam posisi pengakuan Mouse.
2. Tes yang baik tidak berlebihan. Pengujian waktu dan sumber daya yang terbatas. Tidak ada gunanya melakukan tes yang memiliki
tujuan yang sama dengan tes lain. Setiap tes harus memiliki tujuan yang berbeda.
3. Tes yang baik harus berkembang lebih baik. Dalam kelompok tes yang memiliki niat yang sama, waktu dan sumber daya
keterbatasan dapat mengurangi terhadap pelaksanaan hanya subset dari tes ini. Dalam kasus tersebut, tes yang memiliki
kemungkinan tertinggi mengungkap seluruh kelas kesalahan harus digunakan.
4. Tes yang baik harus tidak terlalu sederhana dan tidak terlalu rumit. Meskipun kadang-kadang mungkin untuk menggabungkan
serangkaian tes menjadi satu uji kasus, efek samping yang mungkin terkait dengan pendekatan ini dapat menutupi
kesalahan.Secara umum, setiap tes harus dijalankan secara terpisah.
D. Black-Box dan White-Box Testing
Setiap produk rekayasa dan banyak hal lainnya dapat diuji di salah satu dari dua cara: 1 Mengetahui fungsi tertentu bahwa suatu
produk telah dirancang untuk melakukan, tes dapat dilakukan yang menunjukkan fungsi masing-masing adalah saat beroperasi penuh pada
saat yang sama mencari kesalahan dalam setiap fungsi, 2 Mengetahui cara kerja internal produk, pengujian dapat dilakukan untuk memastikan
bahwa semua gigi jala, yaitu, operasi internal dilakukan sesuai dengan spesifikasi yang dan semua komponen internal telah dilaksanakan secara
memadai. Pendekatan uji disebut pengujian black-box dan yang kedua, pengujian white-box.
Pengujian black-box menyinggung tes yang dilakukan pada antarmuka perangkat lunak. Pengujian black-box mengkaji beberapa aspek
fundamental dari sistem tanpa memperhatikan struktur logika internal perangkat lunak. Pengujian white-boxperangkat lunak didasarkan pada
pemeriksaan dekat detail prosedural. Jalur logis melalui perangkat lunak dan kolaborasi antara komponen diuji dengan memberikan kasus uji
bahwa olahraga set kondisi yang spesifik dan atau loop. Pada pandangan pertama akan terlihat bahwa sangat melalui
pengujian white-box akan menyebabkan 100 persen program yang benar. Semua yang perlu kita lakukan adalah mengidentifikasi semua jalur logis,
mengembangkan uji kasus untuk latihan mereka, dan mengevaluasi hasil, yaitu, menghasilkan kasus uji untuk menjalankan logika program secara
mendalam.Sayangnya, pengujian lengkap menyajikan masalah logistik tertentu.pengujianwhite-box tidak, bagaimana pun, diberhentikan sebagai
tidak praktis. Sejumlah terbatas jalur logis yang penting dapat dipilih dan dilaksanakan.Struktur data penting dapat diperiksa untuk validitas.
E. Pengujian
White-Box
Pengujian White-Box, kadang-kadang disebut pengujian glass-box, adalah kasus uji filosofi desain yang menggunakan struktur kontrol
digambarkan sebagai bagian dari desain komponen-tingkat untuk
mendapatkan uji kasus. Menggunakan metode pengujian white-box, insinyur perangkat lunak dapat memperoleh uji kasus yang 1 menjamin
bahwa semua jalur independen dalam modul telah latihan setidaknya sekali, 2 melaksanakan semua keputusan logis pada sisi mereka benar
dan salah, 3 mengeksekusi semua loop pada batas mereka dan dalam batas-batas operasional mereka, dan 4 latihan struktur data internal untuk
memastikan validitasnya.
F. Pengujian
Black-Box
Pengujian black-box juga disebut pengujian perilaku, berfokus pada persyaratan fungsional perangkat lunak. Itu adalah pengujian black box
memungkinkan perekayasa perangkat lunak untuk mendapatkan set kondisi input yang sepenuhnya akan melaksanakan persyaratan fungsional
untuk suatu program. Pengujian black-box bukan merupakan alternatif untuk teknik pengujian white-box. Sebaliknya, itu adalah pendekatan
komplementer yang kemungkinan akan mengungkap kelas yang berbeda dari kesalahan daripada metode white-box.
Pengujian black-box berusaha menemukan kesalahan dalam kategori berikut: 1 tidak benar atau hilang fungsi, 2 kesalahan interface,
3 kesalahan dalam struktur data atau akses basis data eksternal, 4 perilaku atau kinerja kesalahan, dan 5 inisialisasi dan kesalahan
terminasi.
Tidak seperti pengujian white-box, yang dilakukan pada awal proses pengujian, pengujian black box cenderung diaplikasikan selama
tahap akhir pengujian. Karena pengujian black box sengaja mengabaikan struktur pengendalian, perhatian difokuskan pada domain informasi. Tes
ini dirancang untuk menjawab pertanyaan-pertanyaan berikut: • Bagaimana validitas fungsional diuji?
• Apa kelas input akan membuat kasus uji yang baik? • Apakah sistem sangat sensitif terhadap nilai input tertentu?
• Bagaimana batas-batas kelas data terisolasi? • Apa efek akan kombinasi spesifik data terhadap operasi sistem?
Dengan menerapkan teknik black-box, kita memperoleh satu set kasus uji yang memenuhi kriteria sebagai berikut: 1 uji kasus yang
mengurangi, dengan jumlah yang lebih besar dari satu, jumlah kasus uji tambahan yang harus dirancang untuk mencapai wajar pengujian, dan 2
uji kasus yang memberitahu kita sesuatu tentang ada atau tidak adanya layani kesalahan, daripada kesalahan yang terkait hanya dengan tes khusus
di tangan.
2.6.2.2.2 Kenggulan dan Kelemahan Model RAD
a. Keunggulan Model RAD Kendall dan Kendall, 2008 1. Setiap fungsi mayor dapat dimodulkan dalam waktu tertentu kurang
dari 3 bulan dan dapat dibicarakan oleh tim RAD yang terpisah dan kemudian diintegrasikan sehingga waktunya lebih efisien.
2. RAD mengikut tahapan pengembangan system seperti umumnya, tetapi mempunyai kemampuan untuk menggunakan kembali komponen yang
ada reuseable object sehingga pengembang tidak perlu membuat dari awal lagi dan waktu lebih singkat.
3. Memerlukan biaya yang lebih sedikit dan mementingkan dari segi bisnis dan teknik.
4. Berkonsentrasi pada sudut pandang user dan menyediakan perubahan secara cepat sesuai permintaan user.
5. Menghasilkan jarak kesesuaian yang kecil antara kebutuhan user dan spesifikasi sistem.
6. Waktu, biaya, dan effort minimal.
b. Kelemahan Model RAD Kendall dan Kendall, 2008
