BAB II
LANDASAN TEORI
2.1 Teori-Teori Dasar
Teori-teori berikut ini adalah teori dasar yang didapat dari berbagai
sumber yang dijadikan sebagai landasan dalam penulisan skripsi ini.
2.1.1 Pengertian Sistem
Berikut adalah pendapat yang dikemukakan para ahli mengenai
pengertian sistem :
- Menurut (O'Brien & Marakas, 2007, p. 4), Sistem adalah
satu set komponen yang saling berhubungan dengan batasan yang
jelas, bekerja sama untuk mencapai serangkaian tujuan.
- Menurut(W. Setzinger, 2006, p. 6), Sistem adalah kumpulan
dari beberapa komponen yang saling berhubungan dan bekerja sama
untuk mencapai suatu hasil.
2.1.2 Software Engineering
Software Engineeringadalah sebuah disiplin teknik yang
memperhatikan semua aspek produksi software mulai dari tahap awal
spesifikasi sistem sampai perawatan sistem setelah sistem telah
berjalan. Dalam definisi ini ada dua kata kunci :
1. Disiplin engineering. Para insinyur mengaplikasikan teori,
metodologi, dan alat-alat yang mereka miliki sebagaimana diperlukan,
tetapi kadangkala mereka juga mencari solusi baru suatu
permasalahan meskipun tidak ada teori/metodologi yang mendukung.
2. Semua aspek produksi software. Software engineering tidak
hanya terfokus pada hal-hal teknis pengembangan softwaretapi juga
aktivitas-aktivitas seperti manajemen proyek dan pengembangan teori,
7
8
metodologi, dan alat untuk mendukung pengembangan
software.Secara umum, software engineering mengadopsi pendekatan
sistematis dan terorganisir dalam pekerjaan mereka, mengingat ini
merupakan teknik yang paling efektif. Tapi engineering itu sendiri
berfokus pada penyeleksian metode-metode yang sesuai dengan
masalah yang dihadapi dan terkadang suatu pendekatan yang kurang
formal ternyata lebih cocok untuk penyelesaian masalah. Hal ini
berlaku terutama pada konteks pengembangan sistem berbasis
webyang memerlukan pencampuran antara keahlian
software(teknikal) dan desain grafis.
(Sommerville, 2006, p. 7)
2.1.3 Metode Perancangan Aplikasi
Menurut (Schwalbe, 2010, p. 60), SDLC (System Development Life
Cycle) merupakan suatu kerangka kerja untuk mendeskripsikan fase-
fase yang terlibat dalam pengembangan sistem informasi. SDLC
(System Development Life Cycle) terdiri dari 5 tahap utama, yaitu:
• Planning, merupakan langkah pertama dalam proses pengembangan
sistem, yang terdiri dari identifikasi, seleksi dan perencanaan sistem.
Proses dasar untuk memahami mengapa sebuah sistem harus
dibangun. Pada fase ini diperlukan analisa kelayakan dengan mencari
data atau melakukan proses information gathering kepada pengguna.
• Analysis, merupakan seluruh analisa kebutuhan sistem untuk usulan
sistem informasi (ini juga disebut spesifikasi fungsional atau
kebutuhan fungsional). Untuk proyek perkembangan yang besar,
produk ini mengambil bentuk dari 14 laporan kebutuhan sistem,
dengan menetapkan kemampuan yang diperlukan untuk kebutuhan
informasi pengguna akhir.Dari proses analisa ini akan didapatkan
cara untuk membangun sistem baru.
• Design, merupakan proses penentuan cara kerja sistem dalam hal
architechture design, interface design, database dan spesifikasi file,
9
dan program design.Menjelaskan sistem apa yang harus memenuhi
informasi yang dibutuhkan oleh para pengguna, rancangan ini terdiri
dari rancangan logika dan fisik yang dapat menghasilkan spesifik
sistem yang memenuhi persyaratan sistem yang dikembangkan pada
tahap analisa. Hasil dari proses perancangan ini akan didapatkan
spesifikasi system.
• Implementation, merupakan tahapan yang harus dilakukan sebelum
sistem benar-benar dapat diterapkan dengan melalui testing atau uji
kehandalan dari sistem. Proses pembangunan dan pengujian sistem,
instalasi sistem, dan rencana dukungan sistem.
• Maintenance & Support, merupakan tahapan untuk memperbaiki
error pada sistem, memodifikasi sistem untuk beradaptasi terhadap
lingkungan, dan menjaga sistem dari kemungkinan masalah di masa
yang akan datang.
2.1.3.1 Waterfall Model
Waterfall Model merupakan sebuah metodologi dalam pengembangan
software yang alurnya sekuensial seperti sebuah air terjun. Ada lima tahapan
dalam waterfall model, yaitu :(Pressman, 2010, p. 39)
a. Communication
Langkah ini merupakan analisis terhadap kebutuhan software,
dan tahap untuk mengadakan pengumpulan data dengan melakukan
pertemuan dengan customer, maupun mengumpulkan data-data
tambahan baik yang ada di jurnal, artikel, maupun dari internet.
b. Planning
Proses planning merupakan lanjutan dari proses
communication (analysis requirement). Tahapan ini akan
menghasilkan dokumen user requirement atau bisa dikatakan sebagai
data yang berhubungan dengan keinginan user dalam pembuatan
software, termasuk rencana yang akan dilakukan.
10
c. Modelling
Proses modeling ini akan menerjemahkan syarat kebutuhan ke
sebuah perancangan software yang dapat diperkirakan sebelum dibuat
coding. Proses ini berfokus pada rancangan struktur data, arsitektur
software, representasi interface, dan detail (algoritma) prosedural.
Tahapan ini akan menghasilkan dokumen yang disebut software
requirement.
d. Construction
Construction merupakan proses membuat kode. Coding atau
pengkodean merupakan penerjemahan desain dalam bahasa yang bisa
dikenali oleh komputer. Programmer akan menerjemahkan transaksi
yang diminta oleh user. Tahapan inilah yang merupakan tahapan
secara nyata dalam mengerjakan suatu software, artinya penggunaan
komputer akan dimaksimalkan dalam tahapan ini. Setelah pengkodean
selesai maka akan dilakukan testing terhadap sistem yang telah dibuat
tadi. Tujuan testing adalah menemukan kesalahan-kesalahan terhadap
sistem tersebut untuk kemudian bisa diperbaiki.
e. Deployment
Software yang telah dibuat dan dianggap memenuhi kriteria
yang diharapkan akan di-implementasi. Setelah di-implementasi,
pihak pengembang software (atau pihak yang bertanggung jawab)
harus memastikan adanya dukungandukungan terhadap penggunaan
software yang telah di-implementasi. Dukungan ini misalnya berupa
customer support ,maintenance, dsb.
11
Gambar 2.1Waterfall Model (Pressman, 2010, p. 40)
2.1.4 Masalah, Kelebihan dan Kekurangan Waterfall Model
(Pressman, 2010, p. 41)Kelebihan dari model ini adalah selain
karena pengaplikasian menggunakan model ini mudah, kelebihan dari
model ini adalah ketika semua kebutuhan sistem dapat didefinisikan
secara utuh, eksplisit, dan benar di awal proyek, maka Software
Engineering (SE) dapat berjalan dengan baik dan tanpa masalah.
Meskipun seringkali kebutuhan sistem tidak dapat didefinisikan se-
eksplisit yang diinginkan, tetapi paling tidak, problem pada kebutuhan
sistem di awal proyek lebih ekonomis dalam hal uang (lebih murah),
usaha, dan waktu yang terbuang lebih sedikit jika dibandingkan
problem yang muncul pada tahap-tahap selanjutnya.
Kekurangan yang utama dari model ini adalah kesulitan dalam
mengakomodasi perubahan setelah proses dijalani. Fase sebelumnya
harus lengkap dan selesai sebelum mengerjakan fase berikutnya.
Masalah dengan waterfall :
1. Perubahan sulit dilakukan karena sifatnya yang kaku.
2. Karena sifat kakunya, model ini cocok ketika kebutuhan
dikumpulkan secara lengkap sehingga perubahan bisa ditekan
sekecil mungkin. Tapi pada kenyataannya jarang sekali
konsumen/pengguna yang bisa memberikan kebutuhan secara
lengkap, perubahan kebutuhan adalah sesuatu yang wajar terjadi.
12
3. Waterfall pada umumnya digunakan untuk rekayasa sistem yang
besar yaitu dengan proyek yang dikerjakan di beberapa tempat
berbeda, dan dibagi menjadi beberapa bagian sub-proyek.
2.1.5 Unified Modeling Language ( UML )
(Whitten & Bentley, 2007, p. 246)menjelaskan bahwa Unified
Modeling Language (UML) adalah sekumpulan pemodelan yang
digunakandalam menentukan atau menjelaskan sistem perangkat
lunakmengenai objek. Pendekatan permodelan yang semua
tekniknyaberorientasi objek merupakan permodelan objek.Pada
mulanya, proses pengembangan sistem perangkat lunakmemiliki
banyak metode yang beragam. Sehingga seringkali
terjadikebingungan atau kesalahpahaman dalam proses
pengembangan suatusistem perangkat lunak. Sehingga pada tahun
1994, Grady Booch danJames Rumbaugh bersama-sama
menggabungkan ide masing-masingmengenai pengembangan sistem
berorientasi objek dengan tujuanmenciptakan suatu standar tunggal
dalam proses pengembangansistem berorientasi objek. Pada tahun
1995, Ivar Jacobson bergabungdan mereka bertiga memiliki tujuan
utama untuk menciptakan sebuahstandar untuk bahasa permodelan
berorientasi objek.Pada tahun 1997, Unified Modeling Language
(UML) versi 1.0 resmi dirilis.Sedangkanuntuk yang saat ini
digunakan adalah UML 2.0.UML tidakmendeskripsikan sebuah
metode, tetapi hanyalah sebuah notasi yangsampai sekarang diterima
luas sebagai standar untuk pemodelanobjek.
a. Use Case Diagram
(Whitten & Bentley, 2007, p. 246)menyatakan bahwa use case
diagram merupakan sebuah diagram yang menggambarkan
interaksi antara sistem dan sistem eksternal dengan pengguna.
Dengan kata lain, use case diagram menggambarkan siapa yang
akan menggunakan sistem dan dengan cara apa yang diharapkan
pengguna untuk dapat berinteraksi dengan sistem.
13
Gambar 2.2Contoh use case diagram(Whitten & Bentley, 2007, p. 246)
Komponen penyusun use case diagram, yaitu:
- Actor
Actor menjalankan suatu aktivitas pada sebuah systemdengan
tujuan melengkapi beberapa tugas bisnis yangmenghasilkan sesuatu
yang dapat diukur.
Gambar 2.3Contoh actor pada use case Diagram
- Relationship
Relationship digambarkan dengan sebuah garispenghubung
antara dua simbol dalam use case diagram. Makna dari relasi
dalam use case diagram dapat bermacam-macam tergantung
bagaimana garisyang digambarkan dan jenis simbol yang
terhubung.Ada beberapa jenis hubungan dalam use case
diagram,antara lain:
14
- Associations
Associations merupakan hubungan antara actor dengan use
case yang menyatakan use case tersebut memiliki interaksi
dengan actor yangterhubung langsung. Association
digambarkandengan garis lurus yang tidak terputus-putusantara
use case dengan actor baik searahmaupun dua arah.
Gambar 2.4Contoh hubungan associations pada use case diagram
- Extends
Extends membantu untuk menghasilkan usecase baru yang
merupakan hasil ekstraksifungsi dari use case aslinya, agar use
case aslinya dapat menjadi lebih sederhana danmudah dipahami.
Extends pada umumnya tidak dijelaskan dalam tahap penentuan
kebutuhan pengguna.Extends pada use case diagram digambarkan
dengan garis putus-putus yang diberi label <<extends>>dengan
panah menunjuk kepada use case utama.
Gambar 2.5Contoh hubungan extends pada use case diagram
15
- Uses / Include
Seorang actor dapat menjalankan beberapa usecase yang sama. Untuk
menghilangkanredundansi use case yang digunakan, maka haltersebut
dapat diatasi dengan membuat suatu abstract use case dimana use
case dengan abstract use case akan dihubungkan melaluisebuah garis
putus-putus yang diberi label<<uses>>atau <<include>>dengan
panahmenunjuk kepada abstract use case.
Gambar 2.6Contoh hubungan uses pada use case diagram
- Depends On
Depends on merupakan sebuah hubungan use case yang menjelaskan
bahwa use case akanberjalan terlebih dahulu sebelum use case
yanglainnya berjalan. Depends on dapat membantumengurutkan
kejadian use case dalam use case diagram.Depends on digambarkan
dengangaris solid ataupun putus-putus yang diberilabel <<depends
on>>dengan panahmenunjuk kepada use case yang
memilikiketerkaitan.
Gambar 2.7Contoh hubungan depends on pada use case diagram
16
- Use Case
Use case adalah bagian dari fungsi sistem secara keseluruhan yang
dapat diperoleh dari narasi atau skenario. Use case digambarkan
dengan elips horisontal yang berisi namause case di tengahnya.
Gambar 2.8Contoh use case pada use case diagram
- Boundary
Boundary merupakan batasan area untuk use case yang
berperan menjelaskan sistem yang digambarkan oleh use case
diagram tersebut. Use case akan berada di dalam boundary dan actor
yang menjalankan system berada di luar boundary. Boundary
digambarkan dengan kotak persegi panjang disertai dengan nama
sistem pada bagian atas.
Gambar 2.9Contoh boundary pada use case diagram
17
b. Activity Diagram
(Whitten & Bentley, 2007, p. 390)menjelaskanactivity
diagram adalah sebuah diagram yang dapat digunakan untuk
menggambarkan alur dari sebuah proses bisnis, sebuah use case,
atau logika dari perilaku objek. Activity diagram terlihat serupa
dengan diagram alir (flowchart) dalam hal menggambarkan alur
berurutan dari sebuah aktivitas atau proses bisnis, tetapi yang
membedakan adalah activity diagram dapat menggambarkan
aktivitas secara paralel sedangkan flowchart tidak dapat
menggambarkan aktivitas secara paralel.
Gambar 2.10Contoh activity diagram(Whitten & Bentley, 2007, p. 390)
18
- Initial node: simbol titik awal pada activity diagram yang
digambarkan dengan lingkaran utuh dan padat.
- Action: aktivitas yang dilakukan oleh actor yangmembentuk urutan
aktivitas secara keseluruhan pada activity diagram. Action
digambarkan dengan persegipanjang dengan empat sudutnya yang
agak melengkung dengan bagian tengah yang mendeskripsikan
nama aktivitas.
- Flow/edge: alur aktivitas yang menghubungkan satu action ke action
berikutnya sehingga membentuk urutan aktivitas. Flow
digambarkan menggunakan tanda panah yang menunjuk kepada
action yang berikutnya dilakukan. Flow/edge yang melalui
decisionakan memiliki keterangan kondisi yang ditulis di dalam
kurung siku ([condition]) menuju action berikutnya.
- Decision: simbol yang digunakan untuk memisahkan alur aktivitas
berdasarkan kondisi yang akan dilakukan actor. Decision
digambarkan dengan bentuk berlian yang memecah satu alur
aktivitas menjadi dua atau lebih alur aktivitas berdasarkan kondisi
tertentu.
- Merge: pasangan dari simbol decision yang berbentuk berlian dan
memiliki fungsi untuk menggabungkan beberapa alur aktivitas hasil
pemecahan symbol decision menjadi satu alur aktivitas.
- Fork: simbol yang menggambarkan aktivitas parallel yang dilakukan
pada activity diagram. Fork digambarkan dengna sebuah bar hitam
yang memecah satu alur aktivitas menjadi dua atau lebih alur
aktivitas.
- Join: pasangan dari simbol fork yang berbentuk bar hitam dimana
memiliki fungsi untuk menggabungkanbeberapa alur aktivitas hasil
pemecahan simbol fork menjadi satu alur aktivitas.
- Activity final: simbol akhir proses pada activity diagram yang
digambarkan dengan lingkaran utuhyang memiliki cincin di luarnya.
19
c. Sequence Diagram
(Whitten & Bentley, 2007, p. 394)menjelaskan bahwa
sequence diagram merupakan sebuah diagram yang menggambarkan
interaksiantara aktor dengan sistem untuk sebuah use case scenario
melalui pesan dalam pelaksanaan use case. Sequence diagram
menggambarkan pesan yang dikirim dan diterima melaluiobjek-objek
dalam use case secara berurutan.
Gambar 2.11Contoh sequence diagram(Whitten & Bentley, 2007, p. 394)
Keterangan:
1. Actor: aktor utama dari use case yang ditunjukan dengan simbol
actor seperti pada use case diagram.
20
2. System: sebuah kotak yang menggambarkan system yang akan
berinteraksi dengan actor. Tanda titik dua (:) merupakan standar dari
notasi sequence diagram untuk menunjukkan sebuah instance yang
sedang berjalan pada sebuah sistem.
3. Lifelines: garis putus-putus vertikal yang menyambung kebawah
dari actor atau sistem yang menunjukkan siklus hidup dari sebuah
objek dalam sequencediagram.
4. Activation bars: sebuah bar yang digunakan untuk menunjukkan
periode waktu ketika sebuah objek berinteraksi dalam sequence
diagram aktif.
5. Input messages: panah horisontal dari actor menuju sistem yang
menunjukkan pesan yang dimasukkan ke dalam sistem. Aturannya
adalah huruf pertama pada kata pertama menggunakan huruf kecil,
diikuti dengan huruf pertama kapital pada kata kedua dan seterusnya
dan tanpa spasi, diikuti dengan semua parameter yang dikirimkan ke
sistem dengan aturan nama yang sama dan dipisahkan dengan tand
koma jika lebih dari satu parameter.
6. Output messages: panah horisontal dari sistem menuju actor yang
digambarkan dengan garis putus-putus. Pesan yang disampaikan
berupa jawaban atas pesan yang telah dikirim pengguna sebelumnya.
Tidak ada standar khusus dalam penulisan output messages.
7. Receiver Actor: actor lain atau sistem eksternal yang menerima
pesan dari sistem yang berhubungan.
8. Frame: sebuah kotak yang memiliki satu atau lebih pesan untuk
membagi sequence diagram menjadi sebuah fragmen yang memiliki
fungsi khusus seperti loops, alternate fragment, atau optional. Untuk
fungsi optional, kondisinya dituliskan dalam kurung kotak yang akan
menunjukkan kondisi yang harus terpenuhi untuk menjalankan
aktivitas dalam fragmen tersebut.
21
d. Class Diagram
Menurut (Whitten & Bentley, 2007, p. 400), sebuah class
diagram merupakan gambaran grafis struktur objek dari sistem
statis.Yang menunjukan bahwa sistem terdiri dari objek dan
sertahubungan antara kelas-kelas objek.
Gambar 2.12Contoh class diagram(Whitten & Bentley, 2007, p. 661)
Class diagram terbangun atas 3 bagian, Nama class, Atribut class,
Operasi class.
Gambar 2.13Struktur class pada class diagram
22
Multiplicity dalam class diagram menggambarkan berapa
banyak objek yang dapat mengisi properti dari class.
Tabel 2.1Multiplicity dalam class diagram
Hubungan antar class digambarkan dengan sebuah garis dalam class
diagram. Ada beberapa jenis hubungan dalam classdiagram, antara
lain:
- Associations
Associationsmerupakan hubungan class yang menyatakan class
tersebut memiliki interaksi yang terhubung langsung.
Associationsdigambarkan dengan garis lurus tegas dari class asal
menuju ke class tujuan. Fungsi associationsadalah memberikan
keterangan mengenai relasi antar class dan properti lainnya.
Gambar 2.14Contoh association
- Generalization
Generalization berfungsi untuk menggambarkan turunan
dalam class diagram.Generalization digambarkan dengan garis
dengan anak panah segitiga yang menunjuk dari subclass menuju
superclass.Subclass memiliki properti-properti yang ada pada
superclass, namun dapat memiliki atribut dan method tambahan yang
tidak dimiliki oleh superclass.
23
Gambar 2.15Contoh generalization
e. Entity Relationship Diagram (ERD)
Diagram yang dipakai untuk menggambarkan konsep logika basis
data adalah Entity Relationship Diagram (ERD). Penggunaan Entity
Relationship Diagram (ERD) dimungkinkan untuk memberikan
kemudahan di dalam melakukan pemodelan data, seperti yang
disampaikan oleh (Connolly & Begg, 2009, p. 437), Entity
Relationship Diagram (ERD) digunakan untuk menggambarkan
hubungan antara satu entitas dengan entitas yang lain.
Dari pengertian diatas, dapat disimpulkan bahwa Entity Relationship
Diagram (ERD) adalah model data yang menggunakan beberapa
notasi untuk menggambarkan hubungan antara satu entitas dengan
entitas yang lain. Adapun komponen-komponen yang membentuk
Entity Relationship Diagram (ERD) adalah :
- Entitas merupakan kelompok orang, tempat, objek, kejadian, atau
konsep tentang apayang diperlukan untuk menangkap dan menyimpan
data. Komponen dalam basis data yang mengacu kepada entitas
adalah table.
24
Gambar 2.16 Contoh Entitas Mahasiswa
Pada gambar 2.16, terdapat entitas Mahasiswa dimana pada entitas
tersebut dapat mengandung banyak instance mahasiswa seperti :
Thomas, Rudi, Kaka, Sonia, dll. Dalam pemodelan data, peranan
entitas Mahasiswa dipakai untuk mengelompokkan kategori instance
mahasiswa sehingga tidak perlu mendeskripsikan tiap-tiap instance
mahasiswa satu per satu.
- Atribut merupakan sifat atau karakteristik deskriptif yang
diidentifikasi untuk disimpan ke dalam suatu entitas. Komponen
dalam basis data yang mengacu kepada atribut adalah record.
Gambar 2.17 Contoh Atribut Pada Entitas Mahasiswa
Pada gambar 2.17, pada entitas Mahasiswa terdapat atribut NIM
(Primary Key), atribut Nama, dan atribut Alamat.Penggunaan atribut
NIM, atribut Nama, dan atribut Alamat dipakai untuk
mengidentifikasikan bagian data spesifik yang disimpan dari setiap
instance mahasiswa.
25
· Hubungan merupakan hubungan bisnis alami yang ada di antara satu
atau lebih entitas.
Gambar 2.18Contoh Hubungan Antara Entitas Mahasiswa Dengan Entitas Pembayaran
Pada gambar 2.18 , terdapat hubungan antara entitas Mahasiswa
dengan entitas Pembayaran. Atribut yang menghubungi antara entitas
Mahasiswa dengan entitas Pembayaran adalah NIM yang ditandai
sebagai Foreign Key (FK) oleh entitas Pembayaran.
2.1.6 Visual Basic .NET
Menurut (Yuswanto & Subari, 2010), Visual basic .NET 2010
adalah salah satu bahasa pemrograman yang tergabung dalam
Microsoft Visual Studio.Visual basic .NET mempunyai suatu jendela
yang luas sebagai ruangan kerjanya.Jendela-jendela tersebut yaitu
sebagai berikut :
a. Menu Bar
Menu Bar merupakan kumpulan perintah-perintah
yang dikelompokkan dalam kriteria operasinya. Daftar
pilihan menu yang disediakan oleh Visual basic .NET
2010 adalah File, Edit, View, Project, Build, Debug,
Data, Format, Tools, Windows, danHelp.
b. Toolbar
Toolbarmerupakan sekumpulan tombola atau icon
yang mewakili suatu perintah tertentu pada bahasa
pemrograman berbasis windows dan bisa juga
26
dikombinasikan dengan perintah yang dibuat sendiri
dengan menggunakan logika pemikiran sendiri.
c. Toolbox
Toolboxmerupakan sebuah jendela di mana kontrol
atau kontrol user interface ditempatkan dan digunakan
untuk membentuk suatu program berbasis windowsdan
web, Kontrol-kontrol yang ada di toolboxantara lain:
all windows form, common controls, data,
components, containers, menus & toolbars, printing,
dialogs, WPF interoperability, reporting, danvisual
basic powerpacks.
d. Form Windows
Di tengah area kerja Visual Basic .NET 2010 terdapat
jendela form atau jendela desain. Jendela ini
merupakan pusat pengembangan Visual basic .NET
2010 di mana kontrol (obyek) dari common
controlspada toolboxditempatkan.
e. Code Windows
Code windowsatau sering disebut dengan jendela
editor merupakan area yang dapat menuliskan kode-
kode pemrograman Visual basic .NET. suatu kode-
kode program merupakan kumpulan dari instruksi
untuk menjalankan obyek yang berupa kontrol maupun
form serta logika program. Code windows mampu
meringkas tempat dengan fasilitas Outlining yang
dapat menyembunyikan serta menampilkan kembali
suatu blok program.
f. Solution Explorer Windows
Solution explorer windowsmerupakan jendela yang
menampilkan daftar semua form, modul, classdan
filelainnya untuk membuat aplikasi.
27
g. Properti Window
Properti windowdigunakan pada mode desain yang
bertujuan untuk mengatur suatu nilai pada kontrol
(obyek). Pada bagian atas dari jendela properties
terdapat kotak pilihan sebagai penunjuk dari nama
obyek yang sedang aktif.
h. Jendela-jendela lain
Saat eksekusi program dilakukan, terdapat beberapa j
endela yang menampilkan informasi dari efek proses
tersebut. Beberapa jendela tersebut, anatara lain :
1. Error list Windows
Error list Windowsmerupakan jendela yang digunakan
untuk menampilkan diskripsi kesalahan yang
ditemukan ketika mencoba menjalankan aplikasi
2. Output Window
Output windowmerupakan jendela untuk
menampilkan langkah-langkah dalam mengkompilasi
program.
2.1.7 Microsoft SQL Server
SQL server adalah produk utama Microsoft dalam bidang
basis data, mulai dari SQL Server Express yang ditujukan untuk
kelas bawah sampai SQL Server Enterprise Edition yang ditujukan
bagi semua kelas pengguna. SQL Server hanya dapat dijalankan pada
sistem operasi produksi Microsoft (misalnya Windows).Transact-
SQL pada SQL Server juga kompatibel dengan ODBC, OLE DB,
dan ADO.NET. (Taylor, 2011, p. 247).
2.1.8 Perancangan User Interface
Menurut (Connolly & Begg, 2009, p. 331), interaksi manusia
dengan komputer adalah suatu ilmu yang berhubungan dengan
perancangan, evaluasi, serta implementasi sistem komputer interaktif
yang akan digunakan oleh manusia. Dalam merancang antarmuka
28
pemakai (user interface) perlu menggunakan delapan aturan emas
( 8golden rule ).
Menurut (Shneiderman & Plaisant , 2009, p. 100) dalam perancangan
antarmuka harus memperhatikan kaidah-kaidah seperti berikut
Shneiderman’s 8 Golden Rules of Interface Design:
1. Berusaha untuk konsisten
Pentingnya bagi antarmuka pemakai untuk tetap konsisten
agar user tidak kebingungan dalam mencari sebuah informasi.Contoh,
tampilan layar harus konsisten dari yang satu dengan yang lainnya.
2. Melayani usabilty universal
Mengenali kebutuhan pengguna yang beragam dan desain
untuk plasticity, memfasilitasi transformasi pemberitahuan konten ke
perbedaan ahli, rentang usia, cacat, dan keragaman masing- masing
teknologi memperkaya spektrum persyaratan desain panduan itu.
Menambahkan fitur bagi para pemula, seperti penjelasan, dan fitur
untuk para ahli, seperti shortcut dan aksi balik lebih cepat, dapat
memperkaya desain antarmuka dan meningkatkan persepsi kualitas
sistem.
3. Memberikan umpan balik yang informatif
Untuk setiap user melakukan aksi, maka harus ada umpan
balik agar membuat user menjadi terarah dan tidak tersesat dalam
pencarian informasi.
4. Merancang dialog yang memberikan penutupan (keadaan
akhir)
Berinteraksi dengan komputer sama seperti berdialog. Aksi yang
berurutan harus diorganisasi dan memiliki awal, tengah, maupun
akhir.Penting bagi user untuk mengetahui kapan aksi tersebut
berakhir.Umpan balik yang informatif pada saat sekumpulan aksi
telah dilakukan memberikan user suatu kepuasan, rasa lega, dan
29
indikasi bahwa user boleh melakukan aksi yang selanjutnya.
5. Mencegah terjadinya error
Sebanyak mungkin menghindari kesalahan pada perancangan sistem
sehingga pengguna tidak dapat membuat kesalahan serius; misalnya
field item yang harus diisi oleh user yang tidak mengizinkan karakter
abjad dalam pengisian data numerik. Jika user membuat kesalahan,
interface harus mendeteksi kesalahan dan menawarkan instruksi
sederhana, konstruktif, dan khusus untuk proses perbaikan kesalahan.
Misalnya, user tidak perlu mengetik ulang bentuk seluruh nama-
alamat jika mereka memasukkan kode pos tidak valid, melainkan
harus diarahkan untuk memperbaiki hanya bagian pengisian data yang
tidak valid.Tindakan yang menghasilkan error harus membiarkan
keadaan sistem tidak berubah, atau interface harus memberikan
instruksi-instruksi tentang bagaimana mengembalikan sistem ke
bentuk semula.
6. Memungkinkan pembalikan aksi(undo)yangmudah.
User harus dapat kembali pada aksi yang telah dilakukan sebelumnya,
baik itu ada kesalahan maupun tidak.
7. Mendukung pusat kendali internal.
Kepuasan user akan tinggi jika user merasakan bahwa dia telah
memegang kendali sedangkan kepuasan user akan rendah jika
komputer yang memegang kendali.
8. Mengurangi beban ingatan jangka pendek.
Ingatan jangka pendek manusia sangatlah terbatas. Lakukan apa saja
yang memungkinkan user tidak perlu mengingat apa pun. Sebagai
akan diterima, lebih balik apabila user diminta untuk menampilkan
daftar dari file yang tersedia.
30
2.1.9 Master Data
Definisi dan Contoh Master Data Menurut(Wolter &
Haselden, 2006, p. 100)menjelaskan bahwa kebanyakan sistem
perangkat lunak memiliki daftar data yang dibagi dan digunakan oleh
beberapa aplikasi yang membentuk satu aset utama perusahaan.
Contoh umum dari master data meliputi sistem. Sebagai contoh,
sebuah tipikal sistem Enterprise Resource Planning (ERP) akan
memiliki Customer Master, Item 5 Master, dan Account Master.
2.1.10 Behavioral (Black-Box) Testing
Menurut (Black & Wiliam, 2006, p. 3), Tester menggunakan
behavioral test (disebut juga Black-Box Tests), sering digunakan
untuk menemukan bug dalam high level operations, pada tingkatan
fitur, profil operasional danskenario customer. Tester dapat membuat
pengujian fungsional black boxberdasarkan pada apa yang harus
sistem lakukan. Behavioral testing melibatkan pemahaman rinci
mengenai domain aplikasi, masalah bisnisyang dipecahkan oleh
sistem dan misi yang dilakukan sistem.Behavioral test paling baik
dilakukan oleh penguji yang memahami desain sistem,setidaknya
pada tingkat yang tinggi sehingga mereka dapat secara
efektifmenemukan bug umum untuk jenis desain.
2.1.11 Master Data Management (MDM)
Menurut(Berson & Dubov, 2007, p. 11), Master Data
Management (MDM) adalah kerangka proses dan teknologi yang
bertujuan untuk menciptakan dan memelihara lingkungan data yang
dapat diandalkan, berkelanjutan, aman, dan akurat yang mewakili
sebuah “single version of truth”, sebuah sistem tempat penyimpanan
yang diterima dan digunakan secara intra dan antar-perusahaan dalam
satu set aplikasi beragam, bagian bisnis, dan komunitas user.
31
2.1.12 Procurement
Procurement mengacu pada semua aktifitas yang melibatkan
mendapatkan barang-barang dari pemasok, hal ini meliputi pembelian
dan juga kegiatan logistik ke dalam seperti transportasi, barang
masuk, dan penyimpanan di gudang sebelum barang tersebut
digunakan. (Kalakota & Robinson, 2000, p. 56)
(Turban & Lee, 2007, p. 234)berpendapat bahwa procurement
management adalah koordinasi semua aktivias-aktivitas yang
berhubungan dengan pembelian barang-barang dan jasa yang
dibutuhkan untuk melengkapi misi organisasi.
2.1.13 Electronic Procurement
E-procurement merupakan integrasi dan management
elektronik terhadap semua aktivitas pengadaan termasuk permintaan
pembeli, pemberian hak, pemesanan, pengiriman, dan pembayaran
antar pembeli dan pemasok (Chaffey, 2011, p. 53).
Sedangkan Kalakota, (Kalakota & Robinson, 2000, p.
78)menyatakan bahwa e-procurement merupakan proses pengadaan
barang atau lelang dengan memanfaatkan teknologi informasi dalam
bentuk website.
2.1.14 Supplier Relationship Management (SRM)
Menurut (Mettler & Rohner, 2009, p. 56), Supplier
Relationship Management adalah sebuah pendekatan yang
komperhensif untuk mengelola interaksi antara organisasi dengan
perusahaan yang memasok produk dan jasa yang digunakan oleh
organisasi.
2.1.15 Supply Chain Management
Menurut (Indrajit & Djokopranoto, 2003, p. 100) Supply
Chain adalah jaringan organisasi terhubung dan saling independen
32
dan bekerja sama secara kooperatif untuk mengontrol, mengelola dan
meningkatkan aliran material dan informasi dari pemasok ke
konsumen.
Menurut (Simchi-Levi & Kaminsky, 2002, p. 2), Supply Chain
Management adalah suatu rangkaian pendekatan yang di gunakan
untuk mengintegrasikan pemasok (suppliers), perusahaan manufaktur,
pergudangan (warehouse), dn toko (stores) secara efisien sehingga
perdagangan dapat berjalan dan didistribusikan dalam jumlah yang
tepat, pada saat yang tepat untuk meminimumkan keseluruhan tingkat
pelayanan yang optimal.
APLIKASI SEJENIS
2.1.16 eBid Systems
Didirikan pada tahun 1999, eBid Systems adalah yang terdepan
memberikan Software-as-a-layanan (SaaS) pengadaan solusi untuk
manajemen supplier, sumber dan penawaran, dan supplier contract
managament.Menawarkan konsultasi, pelatihan, dan dukungan teknis
untuk memastikan implementasi sistem yang sukses dan sistem
operasi yang handal.
2.1.16.1 Self-service Supplier Portal
Mendelegasikan tanggung jawab kepada supplier Anda untuk
menyelesaikan dan memperbarui formulir kualifikasi di Portal
supplier Anda, membebaskan staf administrasi dari manual catatan
pemeliharaan.
Gambar 2.19 Contoh Validasi pembaruan data
(Supplier Management Software, 2012)
33
2.1.16.2 Standardize Supplier Qualification
Menerapkan proses yang konsisten untuk menangkap informasi
vendor yang diperlukan dan pastikan bahwa informasi supplier
ditinjau dan disetujui sebelum penghargaan kontrak.
Gambar 2.20Contoh Penampilan Informasi Vendor
(Supplier Management Software, 2012)
2.1.16.3 Custom Vendor Registration Forms
Bentuk dikonfigurasi yang memungkinkan proses on-boarding
disesuaikan supplier untuk menangkap informasi tentang kemampuan
supplier, asuransi, sertifikasi, HSE, RoHS, SDN, kesehatan keuangan,
pengalaman dan personil.
Gambar 2.21Contoh Custom Vendor Registration Forms
(Supplier Management Software, 2012)
34
2.1.16.4 Centralize Visibility of supplier data
Membuat database yang mudah di cari dan berkualitas untuk
supplier yang tersedia untuk semua stakeholder internal dan
memungkinkan tim Anda untuk berkolaborasi dalam pengelolaan
hubungan dengan supplier.
Gambar 2.22Centralize Visibility Of Supplier Data
(Supplier Management Software, 2012)
2.1.17 Quantivate Vendor Management Software
2.1.17.1 Software Vendor Management
Quantivate memungkinkan organisasi Anda untuk mengembangkan
proses manajemen penjualan yang komprehensif dan dapat
memperoleh pandangan lengkap tentang vendor relationship dan
seller risk. Solusi ini memungkinkan efisiensi penjual due diligence,
penilaian risiko penjual, perencanaan, penjual review kontrak,
pemantauan, dan pengawasan. Dalam lingkungan bisnis yang
kompleks saat ini, vendor memainkan peran kunci dalam keberhasilan
organisasi Anda.Namun, mengandalkan vendor membawa risiko
tambahan.Mengelola hubungan ini penting dan risiko penting untuk
memastikan produk dan layanan pihak ketiga mematuhi hukum yang
berlaku, peraturan, dan praktik keamanan terbaik.Mengandalkan
spreadsheet dan alat pengolah kata untuk pengelolaan vendor kritis
tidak lagi memenuhi persyaratan tumbuh dari auditor, instansi
35
pemerintah, pelanggan, atau investor. Sebuah manajemen vendor
solusi perangkat lunak yang komprehensif akan memungkinkan Anda
untuk melindungi dan mengelola sumber daya Anda dan menjaga
hubungan vendor jangka panjang yang sukses. Gambar di bawah
merupakan tampilan menu vendor management auditor dimana
tampilan ini akan menampilkan Auditor reports, Vendor
classification, Overall vendor health, Risk rating.
Gambar 2.23Software Vendor Management
(Vendor and Third Party Management Software, 2014)
2.1.17.2 Manage Vendor,Data Management and Third Party
Risk
DengansoftwareQuantivatevendorManajemen,
Andadapatmengelola semuainformasi vendorAnda, seperti informasi
kontak, keuangan, kontrak, dan sertifikatasuransi,dalam satu
mudahuntuk mengelolaaplikasi berbasis web.Sistem ini juga
menyediakanpemberitahuantitik akhir dantanggal jatuh tempoyang
komprehensifdan tepat waktu. Gambar dibawah ini merupakan
tampilan dari menu Vendor Management User dimana tampilan ini
menampilkan Quick links, Reports , Alerts , Vendor documents libra
36
Gambar 2.24Manage Vendor, Data Management and Third Party Risk (Vendor and Third Party Management Software, 2014)
2.1.17.3 Comprehensive Reporting
Kemampuan Quantivate Manajemen software Vendor
mempunyai pelaporan yang kuat, memberikan visibilitas yang jelas
dalam hubunganpenjual berisiko tinggi, status penilaian penjual, dan
eksposur risiko secara keseluruhan organisasi Anda.Selain itu, laporan
dapat disesuaikan untuk memenuhi kebutuhan spesifik bisnisAnda.
Gambar dibawah ini merupakan tampilan menu Vendor Management
Executive dimana tampilan ini menampilkan data VM Risk Gauge,
Notices.
37
Gambar 2.25Comprehensive Reporting
(Vendor and Third Party Management Software, 2014)
38