BAB 2 LANDASAN TEORI 2.1Teori Umum 2.1.1 Rekayasa Perangkat Lunak (Software Engineering) Menurut Pressman (2010, p1) software engineering meliputi proses, koleksi dari method dan alat yang memungkinkan profesional untuk membuat software computer berkualitas. Software engineers membangun dan menyongkong software, dan secara virtual semua menggunakannya secara langsung atau tidak langsung. Software Engineering penting karena memungkinkan kita untuk membangun sistem yang rumit secara teratur dan berkualitas. LOOK 2.1.2 Software Process Menurut Pressman (2010, p30) software process merupakan dialog dimana pengetahuan diwujudkan dalam perangkat lunak. Proses ini menyediakan 7
47
Embed
library.binus.ac.idlibrary.binus.ac.id/eColls/eThesisdoc/Bab2DOC/2012-1-00184-IF... · Web viewBAB 2. LANDASAN TEORI. Teori Umum. Rekayasa Perangkat Lunak (Software Engineering)
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
BAB 2
LANDASAN TEORI
2.1 Teori Umum
2.1.1 Rekayasa Perangkat Lunak (Software Engineering)
Menurut Pressman (2010, p1) software engineering meliputi proses,
koleksi dari method dan alat yang memungkinkan profesional untuk
membuat software computer berkualitas. Software engineers membangun
dan menyongkong software, dan secara virtual semua menggunakannya
secara langsung atau tidak langsung.
Software Engineering penting karena memungkinkan kita untuk
membangun sistem yang rumit secara teratur dan berkualitas.
LOOK
2.1.2 Software Process
Menurut Pressman (2010, p30) software process merupakan dialog
dimana pengetahuan diwujudkan dalam perangkat lunak. Proses ini
menyediakan interaksi antara pengguna dan desainer, antara pengguna
dengan alat berkembang, antara desainer dengan alat berkembang. Proses
tersebut berulang-ulang dimana alat berkembang sendiri berfungsi sebagai
media komunikasi, dengan masing-masing babak baru dari dialog yang
memunculkan pengetahuan yang lebih berguna bagi orang-orang yang
terlibat. Terdapat lima kerangka kerja umum untuk software process:
7
8
1. Komunikasi
2. Perencanaan
3. Pemodelan
4. Konstruksi
5. Penyebaran
2.1.2.1 Incremental Proccess Model
Incremental Proccess Model berdasarkan Pressman
(2010,p41) dibagi menjadi beberapa tahap:
a. Communication
Sangat penting untuk berkomunikasi dengan customer dan
para stakeholder untuk memahami tujuan proyek dan
mengumpulkan persyaratan yang membantu mendefinisikan
fitur perangkat lunak dan fungsinya.
b. Planning
Perencanaan mendefinisikan kerja rekayasa perangkat
lunak dengan menjelaskan teknik tugas yang dilakukan, resiko
yang mungkin, sumber daya yang akan diperlukan, produk
yang harus diproduksi, dan jadwal.
c. Modelling (analysis, design)
Software engineer membuat model untuk lebih memahami
persyaratan perangkat lunak dan desain yang akan mencapai
kebutuhan tersebut.
9
d. Construction (code, test)
Kegiatan ini menggabungkan generasi kode (baik manual
atau otomatis) dan pengujian yang diperlukan untuk
mengungkap kesalahan dalam kode.
e. Deployment (delivery, feedback)
Perangkat lunak (sebagai entitas lengkap atau sebagai
bagian yang telah selesai) dikirim ke customer untuk
dievaluasi dan mendapatkan umpan balik berdasarkan
evaluasi tersebut.
Gambar 2.1 Increment Process Model
(Sumber : Roger S. Pressman, Software Engineering : A
Practitioner’s Approach 7th edition, 2010)
Increment yang pertama biasanya merupakan core
product, yang merupakan kebutuhan dasar yang diberikan. Core
product akan digunakan oleh customer. Sebagai hasil dari
pemakaian atau evaluasi, rencana baru akan dibuat untuk
increment selanjutnya. Biasanya rencana akan berupa modifikasi
dari core product untuk memenuhi kebutuhan customer dan
10
menambahkan fitur serta fungsi. Proses ini akan dilakukan secara
berulang- ulang sampai product akhir selesai dibuat.
Pengembangan ini berguna ketika hanya sedikit staf yang
tersedia untuk menyelesaikan pelaksanaan dengan batas waktu
yang telah ditetapkan untuk proyek tersebut.
Keuntungan dari model proses incremental adalah apabila
terdapat penambahan modul, siklus yang sedang berjalan dapat
tetap berjalan seiring dengan pengerjaan siklus baru.
2.1.2.2 Incremental Process Model vs Waterfall Model
Berikut merupakan perbedaan model proses incremental
dan waterfall:
Apabila terjadi penambahan modul, siklus yang sedang berjalan
menurut model proses incremental dapat tetap berjalan seiring
dengan pengerjaan siklus baru. Sedangkan model proses waterfall
tidak mendukung penambahan modul dikarenakan model proses
waterfall membutuhkan semua persyaratan sejak awal proyek
berjalan.
2.1.3 Software Testing Fundamentals
Menurut Pressman (2010, p482) tujuan dari pengujian adalah untuk
menemukan dan memperbaiki sebanyak mungkin kesalahan dalam
program sebelum menyerahkan program kepada customer. Salah satu
11
pengujian yang baik adalah pengujian yang memiliki probabilitas tinggi
dalam menemukan kesalahan.
2.1.3.1 Black-Box Testing
Menurut Pressman (2010, p495) Black-Box testing
berfokus pada persyaratan fungsional perangkat lunak yang
memungkinkan engineers untuk memperoleh set kondisi input
yang sepenuhnya akan melaksanakan persyaratan fungsional
untuk sebuah program. Black-Box testing berusaha untuk
menemukan kesalahan dalam kategori berikut:
1. Fungsi yang tidak benar atau fungsi yang hilang
2. Kesalahan antarmuka
3. Kesalahan dalam struktur data atau akses database eksternal
4. Kesalahan perilaku (behavior) atau kesalahan kinerja
5. Inisialisasi dan pemutusan kesalahan
Tes ini dirancang untuk menjawab beberapa pertanyaan-
pertanyaan berikut ini:
1. Bagaimana validitas fungsional diuji?
2. Bagaimana perilaku dan kinerja sistem diuji?
3. Apa kelas input akan membuat kasus uji yang baik?
4. Apakah sistem sensitive terhadap nilai input tertentu?
5. Bagaimana batas-batas kelas data yang terisolasi?
12
6. Kecepatan dan volume data seperti apa yang dapat
ditolerir sistem?
7. Efek apakah yang akan menspesifikasikan kombinasi data
dalam sistem operasi?
2.1.4 Unified Modeling Language (UML)
Menurut Britton dan Doake, (2005, p13), Unified Modeling Language
(UML) adalah satu kumpulan diagram, yang dirancang secara khusus untuk
pengembangan berorientasi objek, dan telah menjadi standar industri untuk
pemodelan sistem berorientasi objek.
2.1.4.1 Use-Case Diagram
Menurut Britton dan Doake, (2005, p40) Use-Case
Diagram adalah diagram yang secara grafis menggambarkan
interaksi antara user dengan sistem.
1. Use-case
Use-case digambarkan dalam bentuk elips dengan label
nama use-case. Penulisan nama use-case menggunakan kata kerja
yang menegaskan bahwa use case mewakili proses.
Gambar 2.2 Use-Case
2. Actor
Figur berbentuk tongkat diberi label nama aktor.
Tujuannya, adalah untuk memanfaatkan nama aktor tersebut agar
13
mudah untuk mengidentifikasikannya. Figur tersebut juga
digunakan untuk aktor yang bukan manusia, misalnya komputer.
Gambar 2.3 Actor
3. Relationship
Garis yang menghubungkan actor dengan use-case. Garis
tersebut menunjukkan actor yang berkaitan dengan use-case yang
digunakan. Hubungan ini dikenal juga sebagai asosiasi
komunikasi. Hubungan yang digunakan dalam diagram use-case:
1. Communication Associations
Merupakan hubungan antara actor dan use-case, dimana tiap
actor dapat berhubungan dengan banyak use-case dan tiap
use-case dapat berhubungan dengan banyak actor.
Gambar 2.4 Associations
2. Inheritance
Merupakan hubungan dimana salah satu entitas mewarisi
karakteristik dari entitas lain.
Gambar 2.5 Inheritance
14
4. System Boundary
Garis yang digambarkan mengitari use-case untuk
memisahkan use-case dengan actor. Dapat diberi label untuk
mengindikasikan domain diagram.
Contoh Use-Case Diagram:
System Login
Gambar 2.6 Use-Case Diagram
5. Use-Case Descriptions
Merupakan dokumen narasi yang menjelaskan secara umum,
fungsi yang dibutuhkan dalam use-case. Use-case descriptions
menjelaskan tujuan dari use-case dan gambaran umum dari
peristiwa yang biasa terjadi. Dengan kata lain, deskripsi harus
ditulis sedemikian rupa sehingga meliputi urutan setiap
kejadian dan scenario yang berkaitan dengan use-case.
Contoh Use-Case Descripstions:
Tabel 2.1 Use-Case Descriptions
Use Case Login
Actor User
Description Use-Case ini mendeskripsikan proses login kedalam akun
15
Precondition User telah teregistrasi
Flow of Events User Action System Response
1. Memasukkan
username dan
password
2. Memvalidasi apakah
user telah terdaftar
dan apakah username
dan password yang
diinput benar atau
salah
3. Menampilkan
halaman utama
website
Alternative
1. Jika user menekan tombol Reset, data yang telah
diinput akan dihapus secara otomatis.
2. Jika user menekan tombol Login, system akan
memvalidasi apakah username dan password
yang diinput tersebut sesuai dengan data didalam
database. Jika tidak sesuai, maka akan muncul
pesan eror yang menyatakan username atau
password yang diinput salah. Jika username dan
password yang diinput sesuai, maka user akan
memasuki halaman utama dari website.
Postcondition User telah memasuki halaman utama website.
16
2.1.4.2 Class Diagram
Menurut Britton dan Doake, (2005, p117) Class Diagram
merupakan pusat dari analisis dan desain berorientasi objek yang
mendefinisikan struktur keseluruhan sistem dan struktur dari
setiap objek dalam sistem. Class diagram digunakan untuk
membuat model class, hubungan antar class, dan juga untuk
membuat model class dengan tingkat struktur yang lebih tinggi
yang terdiri dari koleksi class yang dikelompokkan dalam kelas
paket.
Visibility
Merupakan kemampuan untuk membatasi akses fitur
tertentu dari model atau program. Terdapat tiga level visibility
dalam UML yaitu:
1. Public
Dinotasikan dengan simbol “+”. Atribut public dan methods
public dapat diakses dan digunakan oleh class lain.
2. Protected
Dinotasikan dengan simbol “#”. Atribut protected dan
methods protected dapat diakses dan digunakan oleh class itu
sendiri dan turunan dari class tersebut.
17
3. Private
Dinotasikan dengan simbol “-“. Atribut private dan methods
private dapat diakses dan digunakan oleh class tersebut
sendiri.
Multiplicity
Menunjukkan angka dari objek dari masing-masing class
yang diperbolehkan untuk berpartisipasi dalam asosiasi.
Tabel 2.2 Tabel Multiplicitytion
Arti Contoh Notasi
Jumlah yang tepat Tepat 1
Tepat 6
1
6
Banyak 0 atau lebih
1 atau lebih, banyak
0..*
1..*, *
Kisaran tertentu 1 sampai 4, 0
sampai 6
1..4, 0..6
Pilihan 2 atau 4 atau 5 2,4,5
Unidirectional
Merupakan hubungan satu arah. Dimana arah tujuannya
diindikasikan melalui tanda anak panah. Sedangkan hubungan dua
18
arah, dapat digambarkan dengan garis dengan anak panah di
kedua ujung garis, atau garis tanpa anak panah.
Gambar 2.7 Contoh hubungan satu arah
Gambar 2.8 Contoh hubungan dua arah
Composition
Merupakan hubungan agregasi yang kuat, dimana dalam
hubungan composition, seluruh objek memiliki kepemilikan
eksklusif atas bagian-bagiannya dimana objek bagian hanya dapat
berpartisipasi dalam satu agregasi. Bagian tersebut hidup dan mati
dengan keseluruhan objek, dengan kata lain, apabila objek
dihapus, bagian-bagian yang lain akan ikut terhapus.
Gambar 2.9 Composition
Contoh Class Diagram:
Gambar 2.10 Class Diagram
19
2.1.4.3 Sequence Diagram
Menurut Britton dan Doake, (2005, p156) Sequence
Diagram menggambarkan dengan jelas dan sederhana aliran
kontrol antar objek yang diperlukan untuk melaksanakan
skenario. Sebuah skenario menguraikan urutan langkah-langkah
dalam satu contoh use-case dari pengguna. Dari sisi layar
komputer, sequence diagram menunjukkan bagaimana langkah-
langkah tersebut diterjemahkan kedalam pesan antar objek di
komputer.
Berikut ini merupakan elemen yang digunakan dalam
diagram sequence:
1. Actor
Digambarkan dengan symbol actor yang ada didalam diagram
use-case, yang digunakan untuk mewakili user.
Gambar 2.11 Actor
2. Sistem
Digambarkan dengan kotak, menunjukkan sistem secara
keseluruhan. Tanda titik dua ( : ) merupakan urutan notasi
diagram yang menunjukkan contoh sistem yang sedang
berjalan.
20
Gambar 2.12 Sistem
3. Garis kehidupan (Lifelines)
Garis vertikal putus-putus yang memanjang kebawah dari symbol
actor dan sistem yang mengindikasikan urutan kehidupan.
Gambar 2.13 Garis Kehidupan
4. Bar aktivasi
Bar didalam garis kehidupan (lifetime) yang menunjukkan periode
waktu ketika peserta aktif dalam interaksi.
Gambar 2.14 Bar Aktivasi
5. Pesan masuk (Input message)
Anak panah horizontal yang berasal dari actor menuju sistem
yang mengindikasikan pesan masuk.
Gambar 2.15 Pesan Masuk
6. Pesan keluar (Output message)
Garis anak panah horizontal putus-putus yang berasal dari sistem
menuju actor.
Gambar 2.16 Pesan Keluar
21
7. Iterasi
Menggambarkan pengiriman pesan yang diulang beberapa kali
sesuai dengan kondisi yang dijabarkan. Iterasi digambarkan
dalam bentuk bingkai yang disertai kondisi diujung bingkai.
*[wrong input]
Gambar 2.17 Iterasi
Contoh Sequence Diagram:
Gambar 2.18 Sequence Diagram
2.1.4.4 Activity Diagram
Menurut Britton dan Doake, (2005, p201) Activity
Diagram menggambarkan secara detail proses yang kompleks.
Dalam activity diagram, semua state adalah aktivitas, dan transisi
diantaranya dipicu oleh selesainya sebuah aktivitas, bukan oleh
sebuah peristiwa eksternal.
22
Berikut merupakan elemen yang digunakan dalam diagram
activity:
1. Initial node
Digambarkan dalam sebuah lingkaran penuh, yang
menandakan mulainya proses.
Gambar 2.19 Initial Node
2. Tindakan
Digambarkan dalam bentuk persegi panjang dengan ujung
yang membulat, yang merepresentasikan langkah individual.
Gambar 2.20 Tindakan
3. Aliran
Tanda anak panah dalam diagram mengindikasikan
perkembangan dari tindakan yang dilakukan.
Gambar 2.21 Aliran
4. Keputusan
Berbentuk belah ketupat, dengan satu aliran yang masuk, dan
dua atau lebih aliran yang keluar. Aliran yang keluar diberi
tanda untuk mengindikasikan kondisi.
23
Gambar 2.22 Keputusan
5. Merge
Berbentuk belah ketupat dengan dua atau lebih aliran yang
masuk dan satu aliran yang keluar.
Gambar 2.23 Merge
6. Aktivitas final
Digambarkan dengan sebuah lingkaran penuh didalam
lingkaran kosong yang menandakan berakhirnya suatu proses.
Gambar 2.24 Aktivitas Final
Contoh Activity Diagram:
Gambar 2.25 Activity Diagram
24
2.1.5 Interaksi Manusia dan Komputer (IMK)
2.1.5.1 Pengertian IMK
Menurut Shneiderman (2010, p22), interaksi manusia dan
komputer adalah disiplin ilmu yang berhubungan dengan
perancangan, evaluasi, dan implementasi sistem komputer
interatif untuk digunakan oleh manusia, serta studi fenomena-
fenomena besar yang berhubungan dengannya.
2.1.5.2 Eight Golden Rules
“Eight Golden Rules” terdiri dari:
a. Berusaha untuk konsisten (strive for consistency)
Berusaha membuat urutan yang konsisten dari tindakan
yang diperlukan dalam situasi yang sama. Tata letak,
kapitalisasi, font, warna yang digunakan semua harus
konsisten.
b. Melayani kegunaan universal (cater to universal usability)