BAB 2 LANDASAN TEORI
1 2.1
Proyek Menurut jurnal Petr Rehacek (2014:289) tentang Standar ISO 21500 dan Panduan Project Management Body of Knowledge (PMBoK®) untuk Manajemen Proyek, proyek merupakan kumpulan proses unik yang terdiri dari kegiatan-kegiatan yang terkoordinasi dan terkendali dengan tanggal awal dan akhir untuk mencapai tujuan tertentu. Definisi ini berbeda dengan pengertian terakhir dari panduan PMBoK® yang menyatakan bahwa proyek merupakan aktivitas yang memiliki tujuan untuk menghasilkan kiriman (deliverables).
2.2
Model Manajemen Menurut jurnal Gilles Garel (2013:664) tentang Sejarah Model Proyek Manajemen, proyek merupakan bagian dari aktivitas manusia yang terorganisir, baik dalam bangunan yang didirikan untuk memuja dewa, pertahanan, infrastruktur dan lain-lain. Jika mengamati praktek dari proyek sebelumnya, maka akan ditemukan “sesuatu” yang selalu didokumentasikan sebelum memulai pengerjaan. Proyek selalu menjadi obyek pengamatan dalam sejarah teknik dan rekayasa, menjadi inovasi pemikiran dan sejarah perusahaan. Pada abad ke-20 manajemen proyek dipisahkan dari bentuk-bentuk kegiatan untuk dapat diidentifikasi, disorot dan digeneralisasi kedalam bentuk tersendiri, dan kini telah menjadi model manajemen. Artikel mengenai manajer proyek dipublikasi oleh Harvard Business Review oleh Paul Gaddis (1959) yang menjelaskan bahwa manajer proyek adalah seseorang yang bertanggung jawab untuk mengintegrasikan kontribusi dari departeman yang berbeda untuk meningkatkan efisiensi pengembangan.
2.3
Manajemen Proyek Menurut jurnal Petr Rehacek (2014:289) tentang Standar ISO 21500 dan Panduan PMBoK® untuk Manajemen Proyek, terdapat beberapa analisis perbandingan antara ISO 21500 dan Panduan PMBoK®. ISO 21500 9
10 memberikan deskripsi tingkat tinggi dari konsep dan proses yang dianggap membentuk praktek yang baik dalam manajemen proyek. 2.3.1 Grup Proses Manajemen Proyek Proses proyek dibagi ke dalam lima grup proses. Perbandingan antara ISO 21500 dengan Panduan PMBoK® dapat dilihat pada tabel 2.1 di bawah ini: Tabel 1.1 Perbandingan Grup Proses ISO 21500 dan Panduan PMBoK® (Sumber: Petr Rehacek, 2014:289) ISO 21500
PMBoK® Guide
Initiating
Initiating
Planning
Planning
Implementing
Executing
Controlling
Monitoring and Controlling
Closing
Closing
Perbedaan pada keduanya hanya pada penamaan, standar proses tidak terlalu banyak berubah.
2.3.2 Grup Subjek Knowledge areas pada Panduan PMBoK® telah diubah namanya menjadi subjek (subjects) pada ISO 21500. Perbandingan keduanya dapat dilihat pada tabel 2.2 di bawah ini: Tabel 1.2 Perbandingan Subjek ISO 21500 dan Knowledge areas Panduan PMBoK® (Sumber: Petr Rehacek, 2014:290) ISO 21500 – Subjek
PMBoK® Guide – Knowledge Areas
Integration
Integration
Stakeholder
X
Scope
Scope
Resource
Human Resources
11 Time
Time
Cost
Cost
Risk
Risk
Quality
Quality
Procurement
Procurement
Communication
Communication
Dari perbandingan diatas, dapat dilihat bahwa ISO 21500 dibuat berdasarkan Panduan PMBoK®. ISO 21500 menambahkan Stakeholder pada subjek. Knowledge area Human Resources diganti menjadi subjek Resource dengan tujuan dapat mencakup sumber daya manusia dan sumber daya proyek lainnya. Perbedaan utama dari kedua standar diatas adalah dimana ISO 21500 tidak menyediakan deskripsi alat dan teknik. Deskripsi pada ISO 21500 terdiri dari deskripsi umum dan tabel yang berisi input dan output utama.
2.4
Analisa Sistem dan Perancangan Sistem Dalam mengembangkan aplikasi, akan dibutuhkan analisis-analisis mengenai sistem serta dibutuhkannya perancangan dalam membangun aplikasi yang baik. 2.4.1 Pengertian Analisa Sistem Menurut Whitten & Bentley (2007:160), analisis sistem merupakan
sebuah teknik problem-solving yang membagi sebuah
sistem ke dalam beberapa bagian komponennya sendiri yang bertujuan untuk mempelajari sebagaimana baik bagian-bagian dari komponen tersebut melakukan pekerjaan dan berinteraksi untuk mencapai tujuan mereka. Analisis sistem diawali dari permasalahan bisnis pada system owners dan system users. Oleh karena itu, analisis tentang knowledge, process dan communications harus berdasarkan perspektif system owners dan system users.
12 Menurut Whitten & Bentley (2007:161-167), terdapat lima pendekatan pemecahan masalah pada analisis sistem: 1. Pendekatan Analisis Model-Driven Analisis model-driven adalah pendekatan pemecahan masalah yang menekankan gambaran model sistem untuk dokumentasi dan validasi sistem. Pada akhirnya, model sistem menjadi blueprint untuk merancang dan membangun sistem yang lebih baik. Terdapat tiga pendekatan model-driven yang populer dan sering digunakan: a. Traditional Approaches Berbagai pendekatan tradisional untuk analisis sistem dan desain dikembangkan mulai tahun 1970-an. Salah satu pendekatan formal yang pertama, yang masih banyak digunakan saat ini, adalah structured analysis. Structured analysis berfokus pada aliran data yang melalui proses bisnis dan perangkat lunak b. Information Engineering (IE) Information Engineering berfokus pada struktur data yang tersimpan dalam suatu sistem bukan pada proses. c. Object-Oriented Approach Pendekatan object-oriented tidak melihat sistem informasi sebagai data ataupun proses, tetapi merupakan suatu kumpulan obyek yang merupakan rangkuman dari data dan proses. 2. Pendekatan Analisis Accelerated Systems Discovery Prototyping dan Rapid Architected Development (RAD) merupakan contoh dari pendekatan analisis accelerated systems yang menekankan pembangunan prototype agar dapat mempercepat proses identifikasi persyaratan bisnis dan user untuk sistem baru. 3. Metode Requirements Discovery Baik pendekatan analisis model-driven maupun accelerated systems mempunyai tujuan yang sama yaitu menggambarkan kebutuhan user pada sistem baru, baik digambarkan menggunakan model maupun prototype. Menggali kebutuhan (requirements) tergantung pada kemampuan analis untuk menemukan masalah (problem) dan kesempatan (opportunities) yang ada pada sistem sekarang. Requirements discovery disini merupakan sebuah proses yang
13 digunakan sistem analis untuk mengindentifikasi masalah pada sistem dan menentukan solusinya berdasarkan dengan kebutuhan user. 4. Metode Business Process Redesign Business process re-design (BPR) adalah metode analisis sistem dengan tujuan untuk mengganti atau meningkatkan fundamental dari proses bisnis dan organisasi. Pada proyek BPR, proses bisnis akan dianalisis untuk menentukan bagian proses yang akan dieliminasi atau dirampingkan. Metode BPR merupakan metode yang sangat cocok untuk diterapkan pada proses bisnis yang mengalami perubahan. 5. FAST Systems Analysis Strategies Seperti kebanyakan metodologi pada umumnya, metodologi FASTtidak menggunakan pendekatan tunggal pada analisis sistem. Metodologi FAST mengintegrasikan semua pendekatan menjadi sebuah kumpulan metode agile. Metode agile merupakan integrasi dari berbagai pendekatan sistem analisis dan desain untuk menemukan solusi yang tepat untuk menyelesaikan masalah.
2.4.2 Pengertian Perancangan Sistem Menurut Whitten & Bentley (2007:160), perancangan sistem merupakan perancangan yang dilakukan dalam menciptakan solusi yang mendetil dan spesifik berbasis komputer. Perancangan sistem dapat disebut juga dengan desain fisikal. Sistem analis ditugaskan untuk mencari permasalahan bisnis, sedangkan sistem desain berfokus pada teknikal atau implementasi sistem.
2.5
Rekayasa Perangkat Lunak Dalam era teknologi saat ini, semua orang berharap untuk dapat mengembangkan aplikasi-aplikasi yang bagus, dengan tujuan yang bermacammacam. Untuk pengembangan ini, secara praktis mereka harus mengerti terlebih dahulu apa saja hal yang diperlukan, tentu saja rekayasa piranti lunak ini berkaitan dengan pengembangan aplikasi.
14 2.5.1 Definisi Rekayasa Perangkat Lunak Menurut Pressman & Maxim (2015:14), rekayasa piranti lunak meliputi sebuah proses, sebuah koleksi dari metode-metode (praktek) dan berbagai alat yang mengijinkan profesional-profesional untuk membangun perangkat lunak komputer yang berkualitas tinggi
2.5.2 Model Proses Perangkat Lunak Menurut Pressman & Maxim (2015:40), model proses menyediakan sebuah road map yang spesifik untuk cara kerja rekayasa piranti lunak. Model proses ini mendefinisikan alur dari seluruh aktivitas, aksi dan pekerjaan, tingkat iterasi, produk, dan organisasi dari pekerjaan yang harus diselesaikan. 1. Model Waterfall Menurut Pressman & Maxim (2015:42), model waterfall disebut juga sebagai classic life cycle, menganjurkan sebuah sistematik, pendekatan sekuensial untuk pengembangan piranti lunak yang dimulai dengan spesifikasi dari kebutuhan pelanggan dan prosesproses melalui perencanaan, pemodelan, konstruksi, dan peluncuran, memuncak pada bantuan yang sedang berjalan dari penyelesaian suatu piranti lunak. Tahap-tahap dalam model waterfall antara lain: a. Komunikasi Pada tahap ini, tim melakukan pengumupulan data-data yang berguna demi kepentingan proyek, lalu menginisiasi pembuatan proyek. b. Perencanaan Pada tahap perencanaan, tim memperkirakan setiap detil yang dibutuhkan
dalam
pembuatan
proyek,
penjadwalan
dan
pelacakan terhadap proses yang sedang berjalan. c. Pemodelan Pada tahap ini, dilakukan analisa dan pemodelan, berikut pembuatan desain, sesuai dengan kebutuhan proyek. d. Konstruksi
15 Di tahap berikut ini, tim melakukan konstruksi pembuatan kodekode guna membangun proyek, serta melakukan percobaan pada prototipe proyek. e. Peluncuran Pada tahap ini, dilaksanakannya penyampaian produk pada pelanggan, menyediakan bantuan kepada para pengguna, dan pengumpulan umpan balik demi memperbaiki dan memperbagus produk terkait.
2.6
Unified Modeling Language (UML) Menurut Whitten & Bentley (2007:371), UML adalah sebuah set pemodelan
konvensi
yang
digunakan
untuk
menspesifikasikan
atau
mendeskripsikan suatu sistem perangkat lunak dalam hal obyek. Berikut adalah penjelasan mengenai komponen-komponen UML: 2.6.1 Use Case Diagram Menurut Whitten & Bentley (2007:246), use case diagram adalah sebuah diagram yang menggambarkan interaksi antar sistem dan pengguna. Dengan kata lain, diagram ini mendeskripsikan secara grafis, siapa yang akan menggunakan sistem dan bagaimana cara yang diekspektasikan pengguna untuk berinteraksi dengan sistem. Berikut adalah contoh use case diagram:
Gambar 1.1 Use Case Diagram (Sumber: Whitten & Bentley, 2007:246) Menurut Whitten & Bentley (2007:246-247), simbol-simbol yang digunakan dalam pembuatan use case diagram yaitu:
16 1. Use case Use case mendeskripsikan fungsi sistem dari perspektif pengguna eksternal dan dengan cara dan terminologi yang mereka mengerti. Use case direpresentasikan secara grafis dengan elips horizontal beserta nama dari use case yang terdapat di bawah, atas atau di dalam elips.
Gambar 1.2 Use case 2. Actors Actors merupakan apapun yang dibutuhkan untuk berinteraksi dengan sistem dan melakukan pertukaran informasi guna mencapai sebuah tujuan yang diinginkan.
Gambar 1.3 Actor Berikut adalah beberapa hal penting yang perlu untuk diketahui, Actors memiliki empat tipe utama yaitu: a. Primary business actor Pemegang kepentingan yang mendapatkan keuntungan utama dari hasil eksekusi dari use case dengan mendapatkan sesuatu yang dapat diukur atau bernilai. b. Primary system actor Pemegang kepentingan yang berinteraksi langsung dengan sistem untuk menginisiasi proses bisnis atau sistem. c. External server actor Pemegang kepentingan yang bertugas untuk menanggapi permintaan dari use case. d. External receiver actor
17 Pemegang kepentingan yang tidak merupakan aktor utama tetapi mendapatkan sesuatu yang berharga atau bernilai dari use case. 3. Relationships Menurut
Whitten
&
Bentley
(2007:248-250),
relationships
digambarkan sebagai sebuah garis diantara dua atau lebih simbol pada use case diagram. Makna dari relationships dapat berbedabeda, tergantung bagaimana garis itu digambarkan dan tipe simbol apa yang dihubungkan. Berikut ini adalah penjelasan mengenai beberapa relasi yang terdapat pada use case diagram: a. Associations Associations adalah sebuah hubungan interaksi yang terjadi antara aktor dan use case. b. Extends Extends adalah hasil ekstrak dari use case yang telah disederhanakan dari use case kompleks sebelumnya agar dapat dimengerti dengan lebih mudah. c. Uses (or include) Uses or include adalah relasi antara abstract use case dan use case yang menggunakannya. Abstract use case adalah sebuah use case yang mengurangi redundansi antara dua atau lebih use case dengan cara menggabungkan langkah-langkah yang ditemukan pada cases. d. Depends on Depends on adalah sebuah relasi antar use case yang mengindikasikan satu use case tidak dapat dikerjakan sebelum use case sebelumnya telah dikerjakan. e. Inheritance Inheritance pada use case adalah sebuah relasi antara aktor dibuat untuk menyederhanakan penggambaran ketika sebuah aktor abstrak mewarisi peran dari banyak aktor aslinya.
2.6.2 Use Case Narrative Menurut Whitten & Bentley (2007:246), use case narrative adalah sebuah deskripsi tekstual dari business event dan bagaimana user
18 akan berinteraksi dengan sistem untuk menyelesaikan tugas. Contoh use case narrative:
Gambar 1.4 Use Case Narrative (Sumber: Whitten & Bentley, 2007:257)
19 Menurut Whitten & Bentley (2007:257), notasi-notasi pada use case narrative yang dideskripsikan pada event, antara lain: 1. Author Nama dari individual yang berkontribusi untuk menuliskan use case dan yang menyediakan sebuah kontak poin untuk siapapun membutuhkan informasi tambahan mengenai use case. 2. Date Tanggal yang menampilkan kapan use case terakhir kali dimodifikasi. 3. Version Menunjukkan versi dari use case yang masih berlaku untuk digunakan pada saat ini. 4. Use case name Nama daripada use case harus merepresentasikan tujuan dari use case yang sedang dicoba untuk diselesaikan. 5. Use case type Dalam mengerjakan use case modelling, use case kebutuhan bisnis, yang mana berfokus pada visi dan tujuan stretegis dari beberapa pemegang saham, dikonstruksi pada urutan pertama. 6. Use case ID Sebuah tanda pengenal yang secara unik digunakan untuk mengidentifikasi use case. 7. Priority Prioritas mengomunikasikan kepentingan dari sebuah use case dalam artian tinggi, sedang, atau rendah. 8. Source Sumber yang menjelaskan entitas sebagai pemicu kreasi atau pembuatan dari sebuah use case. 9. Primary business actor Aktor bisnis primer merupakan pemegang saham yang memiliki keuntungan utama dari eksekusi use case dengan menerima sesuatu yang berharga atau bernilai. 10. Other participating actors
20 Aktor lain yang berpartisipasi dalam use case untuk menyelesaikan tujuannya, yang mencakup aktor penginisiasi, aktor pemfasilitasi, aktor pemberi/penerima, dan aktor sekunder. 11. Interested stakeholder(s) Seorang pemegang saham merupakan siapapun yang memiliki kuasa pada pengembangan dan operasi dari sebuah sistem piranti lunak. 12. Description Sebuah deskripsi rangkuman pendek, yang terdiri atas sekumpulan kalimat, yang menguraikan tujuan dari use case dan aktivitasnya.
2.6.3 Activity Diagram Menurut Whitten & Bentley (2007:390), activity diagram adalah sebuah diagram yang dapat digunakan untuk menggambarkan alur dari sebuah proses bisnis, langkah-langkah dari sebuah use case, atau logika dari sebuah perilaku obyek (metode). Contoh activity diagram:
21
Gambar 1.5 Activity Diagram (Sumber: Whitten & Bentley, 2007:392) Menurut Whitten & Bentley (2007:391), berikut ini adalah ilustrasi dari notasi-notasi yang paling umum digunakan dalam pembuatan activity diagram: 1. Initial node Lingkaran padat hitam yang merepresentasikan awal dimulainya sebuah proses.
Gambar 1.6 Initial node
22 2. Actions Persegi panjang bersudut lingkaran yang merepresentasikan langkah individual dan kegiatan yang sedang berjalan.
Gambar 1.7 Actions 3. Flow Panah pada diagram mengindikasikan pergerakan dari action.
Gambar 1.8 Flow 4. Decision Sebuah proses berbentuk diamond yang menggambarkan flow yang masuk dan keluar, mengindikasikan kondisi yang terjadi, dimana terbaginya flow menjadi beberapa jalur karena adanya aksi yang berbeda.
Gambar 1.9 Decision 5. Merge Sebuah proses berbentuk diamond yang menggambarkan flow yang masuk dan keluar. Flow yang masuk mengindikasikan kondisi yang terjadi, dimana flow bergabung menjadi satu jalur, dikarenakan flow ini memiliki kondisi yang sama.
Gambar 1.10 Merge
23 6. Fork Sebuah bar hitam dengan satu flow masuk dan dua atau lebih flow keluar, dimana flow yang keluar ini mengindikasikan aksi-aksi yang akan berjalan secara paralel.
Gambar 1.11 Fork 7. Join Sebuah bar hitam dengan dua atau lebih flow masuk dan satu flow keluar, mencatatkan akhir dari proses yang beriringan. Semua aksi yang masuk ke dalam join harus selesai terlebih dahulu sebelum prosesnya dilanjutkan.
Gambar 1.12 Join 8. Activity final Lingkaran
padat
didalam
sebuah
lingkaran
berongga
merepresentasikan akhir dari sebuah proses.
Gambar 1.13 Activity final 9. Subactivity indicator Sebuah simbol yang mengindikasikan bahwa aksiini telah terpecah dari activity diagram yang lain. Hal ini membantu agar activity diagram tidak menjadi terlalu kompleks.
24
Gambar 1.14 Subactivity indicator 10. Connector Sebuah huruf di dalam sebuah lingkaran yang memberikan alat untuk mengatur kompleksitas. Sebuah flow yang datang ke sebuah konektor, melompat menuju flow yang keluar dari sebuah konektor dengan huruf yang sesuai. A Gambar 1.15 Connector 11. Swimlane Swimlane
adalah
partisi-partisi
yang
mengelompokkan
dan
menunjukkan aksi-aksi yang dilakukan oleh sebuah class atau aktor yang spesifik pada activity diagram.
Gambar 1.16 Swimlane
2.6.4 Sequence Diagram Menurut Whitten & Bentley (2007:394), system sequence diagram adalah sebuah diagram yang menggambarkan interaksi antara aktor dan sistem untuk sebuah skenario usecase. Contoh sequence diagram:
25
Gambar 1.17 Sequence Diagram (Sumber:Whitten & Bentley, 2007:662) Menurut Whitten & Bentley (2007:394-395), berikut ini adalah beberapa ilustrasi dari notasi-notasi yang digunakan dalam pembuatan system sequence diagram: 1. Actor Aktor yang menginisiasi use case, ditampilkan dengan simbol aktor yang sama pada use case.
Gambar 1.18 Actor 2. System Kotak yang mengindikasikan sistem sebagai sebuah “Black Box” atau sebagai keseluruhan. Colon (:) merupakan notasi standar untuk mengindikasikan instansi sistem.
Gambar 1.19 System
26 3. Lifelines Garis vertikal dan putus-putus yang memanjang ke bawah dari simbol aktor dan sistem, garis ini mengindikasikan proses kehidupan dari suatu sequence.
Gambar 1.20 Lifelines 4. Activation bars Bars yang ditetapkan sesuai dengan lifelines mengindikasikan periode waktu ketika partisipan sedang aktif dalam sebuah interaksi antar sistem maupun aktor.
Gambar 1.21 Activation bars 5. Input messages Panah horizontal yang mengarah dari aktor menuju sistem mengindikasikan pesan-pesan yang dimasukkan.
Gambar 1.22 Input messages 6. Output messages Panah horizontal dari sistem menuju aktor yang ditampilkan dengan garis putus-putus. Mengindikasikan pesan yang masuk.
Gambar 1.23 Output messages 7. Receiver actor Aktor lain atau sistem eksternal yang mendapatkan pesan dari sistem, dapat dimasukkan ke dalam kategori receiver atau sebagai penerima pesan.
27
Gambar 1.24 Receiver actor 8. Frame Sebuah kotak yang berisikan satu atau lebih pesan bertujuan untuk membagi fragmen atau sebuah bagian dari sequence.
Gambar 1.25 Frame
2.6.5 Class Diagram Menurut Whitten & Bentley (2007:400), Class diagram adalah sebuah gambaran grafik dari sebuah struktur obyek sistem statis, menunjukkan kelas-kelas obyek yang mana sistem itu terdiri dari hubungan antara obyek-obyek kelas. Contoh class diagram:
Gambar 1.26 Class Diagram (Sumber: Whitten & Bentley, 2007:406) Menurut Whitten & Bentley (2007:372), berikut adalah elemenelemen dasar daripada class diagram: 1. Object Sesuatu yang dapat dilihat, disentuh, ataupun dirasakan dan dimana pengguna menyimpan data dan mengasosiasikan behavior.
28 2. Attribute Data yang merepresentasikan karakteristik-karakteristik yang terkait dengan sebuah obyek. 3. Object Instance Setiap hal yang spesifik yang dapat berupa, orang, tempat, barang, ataupun event, berikut nilai-nilai untuk atribut dari obyek tersebut. 4. Behavior Sekumpulan dari sesuatu hal yang dapat dilakukan oleh obyek dan dapat berkorespondensi ke fungsi-fungsi yang memiliki aksi atas sebuah data obyek. 5. Encapsulation Pengemasan dari sekelompok hal-hal ataupun barang-barang menjadi satu kesatuan yang utuh. Menurut Whitten & Bentley (2007:650), atribut dan metodemetode yang dapat diakses oleh kelas lain dalam suatu class diagram, didefinisikan oleh visibility. Visibility adalah sebuah tingkatan akses yang dimiliki oleh sebuah obyek eksternal untuk sebuah atribut atau metode. Visibility dibagi menjadi tiga tingkatan, yaitu: 1. Public Tingkatan public mengijinkan sebuah atribut kelas untuk diakses pihak mana saja dan metode kelas untuk dapat dipanggil oleh kelas mana saja, dinotasikan dengan simbol “+”. 2. Protected Tingkatan protected mengijinkan atribut dan metode untuk dipanggil dan diakses oleh suatu kelas, dimana atribut/metode ini merupakan sebuah subclasses dari kelas, dinotasikan dengan simbol “#”. 3. Private Tingkatan private dimana atribut dan metodenya hanya dapat diakses dan dipanggil oleh kelas yang telah ditentukan, dinotasikan dengan simbol “-“. Menurut Whitten & Bentley (2007:400-401), berikut adalah hubungan-hubungan yang paling umum terjadi pada suatu obyek kelas: 1. Associations
29 Asosiasi merupakan sebuah hubungan yang terjadi diantara obyekobyek kelas. Asosiasi antar obyek-obyek kelas ini perlu diketahui untuk dapat mengidentifikasi multiplicity. 2. Multiplicity Multiplisitas merupakan konsep yang mengatur mengenai angka minimum dan maksimum aksi dari sebuah obyek kelas yang behubungan. 3. Generalization Konsep generalisasi menggabungkan atribut-atribut serta metodemetode yang banyak memiliki kesamaan, menjadi satu kelas tersendiri, yang disebut supertype. 4. Specialization Konsep spesialisasi menggabungkan atribut-atribut beserta metodemetode yang unik terhadap suatu obyek, tetapi yang masi mewarisi atribut dan metode yang ada pada kelas supertype, kelas ini disebut dengan subtype. 5. Aggregation Agregasi merupakan sebuah hubungan unik yang terjadi dimana satu obyek merupakan bagian dari obyek lain. Menurut Whitten & Bentley (2007:378), pada UML 2.0, notasi dari agregasi tidak lagi digunakan, karena pada hubungan komposisi terdapat beberapa perbedaan-perbedaan yang telah terdefinisikan secara jelas dan lebih banyak digunakan pada programming, sedangkan agregasi tidak terdefinisikan dengan pasti dan jelas. Karena hal tersebut, beberapa pengguna mempertimbangkan bahwa agregasi tidak lagi bermakna dalam programming. 6. Composition Komposisi merupakan sebuah hubungan dimana satu kesatuan obyek memiliki hak penuh atas bagian-bagiannya (menambah atau menghapus suatu obyek kelas). Menurut Whitten & Bentley (2007:650), dalam pembuatan class diagram, dibutuhkan sebuah hubungan yang lebih mendalam antar obyek-obyek kelas agar dapat menentukan komponen-komponen dari
30 piranti lunak dengan lebih spesifik dan akurat sehingga pembuatan diagram dapat lebih detil. Hubungan tersebut adalah: 1. Dependency Relationships Sebuah dependency relationships dibutuhkan untuk pemodelan asosiasi antara dua kelas yang saling mengandalkan di dalam dua instansi: a. Pertama, untuk mengindikasikan kapan sebuah perubahan terjadi dalam suatu kelas, yang dapat mempengaruhi kelas lain. b. Kedua, untuk mengindikasikan asosiasi antara sebuah kelas yang bersifat tetap dengan kelas yang bersifat sementara. 2. Navigability Navigability didefinisikan pada asosiasi-asosiasi sebagai notasi untuk mengindikasikan perpindahan pesan-pesan antar kelas yang saling berhubungan. Navigability ini dapat dibedakan menjadi dua jenis, yaitu: a. Uni-directional Uni-directional merupakan sebuah hubungan antar kelas yang terjadi secara satu arah. Uni-directional dilimitasi menjadi satu arah dikarenakan adanya suatu tujuan khusus antar kelas yang berhubungan. Uni-directional dinotasikan dengan sebuah tanda panah yang mengarah dari sumber menuju target. b. Bi-directional Bi-directional merupakan sebuah hubungan antar kelas yang terjadi secara dua arah. Pada dasarnya asosiasi-asosiasi antara kelas telah didefinisikan sebagai bi-directional (dua arah), yang berartikan bahwa salah satu dari tipe kelas dapat melakukan navigasi (pengiriman pesan) kepada kelas-kelas lain yang memiliki tipe berbeda.
2.7
Interaksi Manusia dan Komputer 2.7.1 Pengertian Interaksi Manusia dan Komputer Menurut Shneiderman dan Plainsant (2010: 22), interaksi manusia dan computer merupakan ilmu yang mempelajari
31 2.7.2 Eight Golden Rules Menurut Shneiderman dan Plaisant (2010: 88-89), ada delapan aturan emas yang dapat diaplikasikan dalam perancangan user interface, yaitu: 1. Strive for consistency Banyak bentuk dari konsistensi yang harus diperhatikan dalam merancang user interface. Beberapa diantaranya adalah harus memiliki konsistensi dalam urutan aksi di situasi yang serupa, memiliki menu, warna, layout dan font yang sama. 2. Cater to universal usability User interface harus dapat menjawab kebutuhan dari user yang berbeda-beda. Contohnya dengan menambahkan fitur explanation untuk novice user dan menambahkan fitur shortcut untuk expert user. 3. Offer informative feedback Untuk setiap aksi yang dilakukan diharapkan adanya suatu umpan balik bagi user. Respon yang diberikan tergantung dari aksi yang dilakukan oleh user. 4. Design dialog to yield closure Urutan suatu aksi haruslah diorganisasi berdasarkan kelompok tertentu dari awal, tengah dan akhir. Umpan balik yang informatif pada akhir suatu aksi kepada user akan memberikan kepuasan kepada user bahwa aksi yang mereka lakukan telah berhasil dengan baik dan menjadi pertanda untuk melakukan aksi selanjutnya. 5. Prevent errors Perancangan suatu sistem haruslah dibuat sedemikian rupa sehingga user tidak melakukan kesalahan. Jika user melakukan kesalahan maka
sistem
seharusnya
dapat
mendeteksi
dan
menawarkan.recovery yang sederhana, konstruktif dan spesifik. 6. Permit easy reversal of actions Setiap aksi haruslah dirancang sedemikian rupa, sehingga user dapat kembali ke keadaan sebelum aksi dijalankan. Hal ini dapat membuat user lebih berani untuk mengeksplorasi sistem yang dibuat dan memilih options yang tidak familiar.
32 7. Support internal locus of control User yang berpengalaman biasanya memiliki keyakinan bahwa mereka bertanggung jawab terhadap sistem dan sistem akan memberikan respon terhadap aksi yang mereka lakukan. Respon yang mengejutkan, urutan yang aneh dalam memasukkan data dan kesulitan dalam memperoleh informasi yang diperlukan serta ketidakmampuan dalam mendapatkan hasil sesuai aksi tertentu akan menimbulkan kekacauan dan keraguan bagi user. 8. Reduce short term memory load Keterbatasan manusia dalam mengelola memori jangka pendek membuat user membutuhkan suatu tampilan yang sederhana, pengaturan dalam multipage, pergerakan window yang sesedikit mungkin serta waktu training yang cukup dan optimal.
2.8
Fact-Finding Techniques Menurut Whitten & Bentley (2007:212), Fact-Finding adalah proses formal dari penelitian, pertemuan, wawancara, kuisioner, pengambilan sampel, dan
teknik-teknik
lainnya
untuk
mengumpulkan
informasi
mengenai
permasalahan sistem, kebutuhan-kebutuhan dan preferensi. Menurut Whitten & Bentley (2007:215), berikut ini adalah tujuh teknik Fact-Finding yang umumnya digunakan: 1. Sampel dari dokumentasi Teknik pengambilan sampel ini dilakukan dengan cara mengumpulkan dokumen-dokumen sampel yang repre
sentatif, form-form dan arsip-
arsip sesuai dengan kebutuhan. 2. Penelitian Teknik ini dilakukan dengan mengunjungi perusahaan yang memiliki masalah sejenis dan meminta persetujuan mereka untuk bisa mendapatkan informasi untuk mengatasinya, dapat juga dengan melakukan pencarian jurnal terkait. 3. Observasi Teknik ini dilakukan dengan cara berpartisipasi langsung ataupun mengamati seseorang yang tengah beraktivitas sistem dan cara kerjanya.
untuk
mempelajari
33 4. Kuisioner Teknik ini menggunakan sebuah dokumen yang mengijinkan analis untuk mengumpulkan informasi dan pendapat dari para responden. 5. Wawancara Teknik ini mengumpulkan informasi dari individual melalui interaksi langsung, tanya jawab antara analis dan narasumbernya. 6. Prototipe Teknik ini dilakukan dengan membangun sebuah model kerja dengan skala kecil yang dapat merepresentasikan kebutuhan-kebutuhan pengguna tersebut. 7. Perencanaan Kebutuhan Bersama Teknik yang mana prosesnya yang terstruktur untuk
membutuhkan sebuah pertemuan grup
melakukan
analisa
permasalahan
dan
mendefinisikan kebutuhannya.
2.9
Hypertext Markup Language (HTML) Menurut Robin Nixon (2014:1), Hypertext Markup Language (HTML) adalah sebuah bahasa penulisan yang diciptakan oleh Berners Lee untuk menampilkan halaman dari sebuah web browser. HTML disimpan dengan tipe file .htm atau .html.
2.10 Model-View-Controller (MVC) Menurut
Martin
Mugisha
(2014:29-32),
Model-View-Controller
merupakan pola arsitektur yang digunakan untuk mengimplementasikan user interface. Perangkat lunak dibagi menjadi tiga bagian (Model, View dan Controller) yang saling terhubung.
34
Gambar 1.27 Interaksi komponen MVC (Sumber: Martin Mugisha, 2014:29-32) Berikut ini merupakan detail interaksi antara komponen dalam pola perancangan MVC: 8. Controller a. Controller terlibat dalam perubahan state model. b. Controller mendapatkan input dari mouse dan keyboard dari user dan mengarahkan model dan view untuk berubah sesuai kebutuhan. c. Controller
menginterpretasikan
interaksi
dari
view
dan
menerjemahkannya ke dalam aksi yang dilakukan oleh model. d. Controller juga bertanggung jawab untuk menampilkan view yang sesuai untuk user yang sesuai. 9. Model a. Model merupakan objek yang merepresentasikan suatu aktifitas ataupun tabel database. b. Model mengelola behavior dan juga data dari aplikasi perangkat lunak. c. Model menerima permintaan untuk mendapatkan informasi dan merespon instruksi untuk mengubah state. d. Model menampilkan data aplikasi beserta rule yang mengatur akses untuk memperbarui data. 10. View a. View merupakan representasi visual dari model state. b. View menerjemahkan isi model dengan mengakses data dari model dan menentukan cara untuk menampilkan data.
35 c. View mengatur representasi output grafis dan tekstual dari aplikasi perangkat lunak.
2.11 Hypertext Preprocessor (PHP) Menurut Robin Nixon (2014:45-50), PHP adalah bahasa yang digunakan untuk membuat server memproduksi hasil-hasil yang dinamis yang berpotensial berbeda-beda setiap sebuah browser membuka halaman baru. Secara umum, dokumen PHP diakhiri dengan ekstensi .php. Ketika sebuah web server menemukan ekstensi ini pada sebuah file, web server secara otomatis akan memindahkannya ke prosesor PHP.
2.12 Yii 2.0 Menurut Jeff Reifman (2014), Yii merupakan framework PHP gratis dan open-source yang memiliki fitur untuk mendukung rapid development. Fitur-fitur yang terdapat dalam framework Yii adalah: 1. Model-View-Controller Architecture 2. Database Access Objects (DAO) and Active Record 3. Form input, Validation, and Ajax support. 4. Yii’s code generation tool, Gii 5. Extensions 6. Error handling, logging, and testing.
2.13 MySQL Menurut Robin Nixon (2014:171-179), MyStructured Query Language (MySQL) adalah sebuah sistem manajemen basis data yang paling populer untuk web servers. MySQL dikembangkan pada pertengahan tahun 1990, yang sekarang merupakan teknologi yang paling banyak digunakan oleh tujuan internet yang paling sering dikunjungi hari ini. Sebuah basis data MySQL, memiliki satu atau lebih tabel, yang mana setiap tabelnya berisikan arsip-arsip atau baris. Dalam deretan ini terdapat berbagai macam kolom yang berisikan data itu sendiri. Contoh tabel 2.3 dan perintah MySQL sederhana:
36 Tabel 1.3 Contoh Tabel Sederhana (Sumber: Robin Nixon, 2014:162) Author Mark Twain
Title
Type
The Adventures of Tom Fiction
Year 1876
Sawyer Jane Austen
Pride and Prejudice
Fiction
1811
Charles Darwin
The Origin of Species
Non-Fiction
1856
Charles Dickens
The Old Curiosity Shop
Fiction
1841
William Shakespeare
Romeo and Juliet
Play
1594
SELECT title FROM publications WHERE author = ‘William Shakespeare’
Istilah-istilah yang penting untuk diingat dalam pembuatan basis data adalah: 1. Database merupakan wadah keseluruhan yang memuat kumpulan data MySQL. 2. Table merupakan sub wadah dalam basis data yang memuat data sebenarnya. 3. Row merupakan sebuah catatan tunggal dalam sebuah tabel yang memuat beberapa konten. 4. Column merupakan nama dari konten pada sebuah baris.
2.14 Javascript Menurut Robin Nixon (2014:323-324), JavaScript adalah sebuah bahasa pemrograman client-side scripting yang keseluruhannya berjalan di dalam web browser. JavaScript membawa fungsionalitas yang dinamis pada websites. Setiap kali sebuah halaman baru muncul secara tiba-tiba pada browser (yang sering sekali kita sebut dengan sebutan pop-up), atau ketika kita melihat beragam teks yang baru, warna, maupun sebuah gambar yang muncul di halaman, atau mengambil sebuah obyek pada halaman dan kemudian memindahkannya ke lokasi baru, semua hal tersebut dilakukan oleh JavaScript. Penggunaan JavaScript itu sendiri, dengan cara menempatkan awalan <script> dan akhiran di antara label HTML dan tanpa menggunakan semicolon (;).
37
2.15 Cascading Style Sheet (CSS) Menurut Robin Nixon (2014:423), Cascading Style Sheet (CSS), mengaplikasikan tampilan-tampilan pada halaman web untuk membuatnya terlihat sebagaimana yang diinginkan. Robin Nixon (2014:428-429), menjelaskan ada beberapa macam tampilan CSS yang berbeda dalam penggunaannya, dimulai dari tampilan default yang telah disediakan oleh browser, melalui inline, sampai ke tampilan eksternal. Gaya tampilan-tampilan tersebut adalah: 1. Default styles: tampilan dasar yang diberikan oleh web browser pada halaman web yang tidak memiliki CSS pada pembuatannya. 2. User styles: tampilan yang dibuat langsung oleh pengguna, yang kemudian diimplementasikan ke dalam web browser. 3. External style sheet: tampilan yang dibuat pada lembar pemrograman yang terpisah demi memproduksi tampilan berbeda untuk tujuan yang berbeda juga, seperti menampilkan web pada umumnya di browser komputer atau laptop, dan untuk ditampilkan pada sebuah mobile browser dengan layar yang lebih kecil, untuk percetakan dan lainnya. 4. Internal styles: tampilan yang dibuat didalam tags <style>…. dan yang mana lebih diutamakan untuk digunakan dari semua gaya tampilan yang ada. 5. Inline styles: tampilan yang dibuat dan ditujukan langsung kepada sebuah elemen. Gaya tampilan ini merupakan gaya yang paling utama dari segala jenis tampilan yang digunakan.
2.16 Rich Pictures Menurut Gammack, Hobbs & Pigott (2011:120), Rich pictures adalah sebuah teknik fleksibel untuk pembuatan diagram situasi permasalahan dan menimbulkan pengetahuan serta perilaku. Idenya yaitu untuk mengekspresikan dan merepresentasikan situasi dimana sebuah permasalahan itu dirasakan dan pada akhirnya sebuah sistem informasi dapat menjadi relevan pada situasi tersebut.
38 Rich pictures memiliki fitur-fitur sebagai berikut: Aspek struktural, Proses dan alur, dan Kepentingan.
Gambar 1.28 Rich Pictures (Sumber: Gammack, Hobbs & Pigott,2011:121)
2.17 Data Dictionary Menurut Connoly & Begg (2015:63), data dictionary merupakan pendeskripsian sifat dari database yang menyediakan data independence. Data dictionary menjelaskan kegunaan atribut di setiap entity.
