REKAYASA PERANGKAT LUNAK
A. PERBEDAAN
PERANCANGAN TERSTUKTUR DAN PERANCANGAN OBJEK
1. Perancangan Terstruktur adalah
aktivitas mentransformasikan suatu hasil analisis ke dalam suatu perencanaan
untuk dapat diimplementasikan ( diotomasikan).
2. Perancangan berorientasi objek
adalah Suatu teknik atau cara pendekatan baru dalam melihat permasalahan dan
sistem (sistem perangkat lunak. Sistem informasi, atau sistem lainnva).
Pendekatan berorientasi objek akan memandang sistem yang akan dikembangkan
sebagai suatu kumpulan objek yang berkorespondensi dengan objek-objek dunia
nyata.
3. Tools yang Digunakan :
Terstruktur
:
·
DFD
(Data Flow Diagram)
·
Entity
Relationship Diagram (ERD)
·
State
Transition Diagram (STD)
·
Kamus
Data
Perancangan
Berorientasi Objek :
·
Object
Oriented Analysis (OOA) dan Object Oriented Design (OOD)
·
Object
Modeling Technique (OMT)
·
Object
Oriented Software Engineering (OOSE)
·
Booch
Method
·
Sritrop
·
UML
(Unified Modeling Language)
B. PERBEDAAN
PSPEC DAN USE CASE
Spesifikasi
Proses (PSPEC – Process Specification)
·
PSPEC
adalah level abstraksi yang paling rendah (di DFD)
·
PSPEC
sepanjang kira-kira ½ halaman
·
Menunjukkan
hubungan antara input proses dan aliran output
·
Dapat
menggunakan berbagai bentuk spesifikasi – Gambar – Persamaan matematika –
Bahasa sehari-hari
Contoh
PSPEC Keluarkan Kembalian
Inputs:
· koin
: data in
· jumlah
kembali : data in
Outputs:
· koin
kembali : data out
Body: koin kembali adalah jumlah
koin yang diambil dari sebanyak ‘jumlah kembali’
Contoh
PSPEC Validasi Pembayaran
Inputs:
· pembayaran
: data in
· harga
: data in
Outputs:
· jumlah
kembali : data out
Body: If (pembayaran >= harga)
jumlah kembalian= payment –harga
else jumlah kembalian = 0
Contoh
PSPEC Ambil Harga Barang
Keluarkan harga barang berdasarkan
pilihan barang yang diambil dari tabel daftar harga
Kurang lebih strukturnya seperti
ini:
Aturan
Balancing Kebutuhan
· Setiap
DFD harus seimbang (balance) dengan induknya
· Setiap
PSPEC harus seimbang dengan proses primitif fungsi yang terkait
· Setiap
aliran data, dan data store harus terdefinisi, dan harus terdekomposisi menjadi
elemen
primitif, elemen primitif ini akan didefinisikan di kamus data
·
Diagram use
case merupakan pemodelan untuk menggambarkan kelakuan (behavior) sistem
yang akan dibuat.
·
Diagram use case mendeskripsikan
sebuah interaksi antara satu atau lebih aktor dengan sistem yang akan
dibuat.
·
Diagram use case digunakan untuk
mengetahui fungsi apa saja yang ada di dalam sebuah sistem dan siapa saja
yang berhak menggunakan fungsi-fungsi tersebut. Yang ditekankan pada
diagram ini adalah “apa” yang diperbuat sistem, dan bukan “bagaimana”.
·
Sebuah use case merepresentasikan
sebuah interaksi antara aktor (user atau sistem lainya) dengan sistem.
·
Use case menjelaskan secara
sederhana fungsi sistem dari sudut pandang user.
Penjelasan bagian bagian use
case diagram
1. System
Menyatakan
batasan sistem dalam relasi dengan actor-actor yang menggunakannya (di luar
sistem) dan fitur-fitur yang harus disediakan (dalam sistem). Digambarkan
dengan segi empat yang membatasi semua use case dalam sistem terhadap pihak
mana sistem akan berinteraksi. Sistem disertai label yang menyebutkan nama dari
sistem, tapi umumnya tidak digambarkan karena tidak terlalu memberi arti
tambahan pada diagram.
2. Actor
Aktor adalah segala hal diluar
sistem yang akan menggunakan sistem tersebut
untuk melakukan sesuatu. Bisa merupakan manusia, sistem, atau device yang
memiliki peranan dalam keberhasilan operasi dari sistem. Cara mudah untuk
menemukan aktor adalah dengan bertanya hal-hal berikut: SIAPA yang akan
menggunakan sistem? APAKAH sistem tersebut akan memberikan NILAI bagi
aktor?
3. Use case
Mengidentifikasi fitur kunci dari
sistem. Tanpa fitur ini, sistem tidak akan memenuhi permintaan user/actor.
Setiap use case mengekspresikan goal dari sistem yang harus dicapai. Diberi
nama sesuai dengan goal-nya dan digambarkan dengan elips dengan nama di
dalamnya. Fokus tetap pada goal bukan bagaimana mengimplementasikannya walaupun
use case berimplikasi pada prosesnya nanti. Setiap use case biasanya
memiliki trigger/pemicu yang menyebabkan use case memulai (misalnya,Pasien
mendaftar dan membuat janji baru atau meminta untuk membatalkan atau mengubah
janji yang sudah ada ).ada 2 triger pertama triger eksternal, seperti
pelanggan memesan atau alarm kebakaran berbunyi, kedua triger temporal,
seperti tanggal pengembalian buku terlewati di perpustakaan atau keterlambatan
bayar sewa.
4. Assosiation
Mengidentifikasikan interaksi antara
setiap actor tertentu dengan setiap use case tertentu. Digambarkan sebagai
garis antara actor terhadap use case yang bersangkutan. Asosiasi bisa berarah
(garis dengan anak panah) jika komunikasi satu arah, namun umumnya terjadi
kedua arah (tanpa anak panah) karena selalu diperlukan demikian.
5 Dependency
Dependensi <<include>>
·
o Mengidentifikasi hubungan antar
dua use case di mana yang satu memanggil yang lain.
·
o Jika pada beberapa use case
terdapat bagian yang memiliki aktivitas yang sama maka bagian aktivitas
tersebut biasanya dijadikan use case tersendiri dengan relasi dependensi setiap
use case semula ke use case yang baru ini sehingga memudahkan pemeliharaan.
·
Digambarkan dengan garis
putus-putus bermata panah dengan notasi <<include>> pada garis.
·
o Arah mata panah sesuai dengan arah
pemanggilan.
Dependensi <<extend>>
o Jika pemanggilan memerlukan adanya
kondisi tertentu maka berlaku dependensi <<extend>>.
o
Note: konsep “extend” ini berbeda dengan “extend” dalam Java!
o Digambarkan serupa dengan dependensi <<include>> kecuali arah
panah berlawanan.
6. Generalization
Mendefinisikan relasi antara dua
actor atau dua use case yang mana salah satunya meng-inherit dan menambahkan
atau override sifat dari yang lainnya. Penggambaran menggunakan garis bermata
panah kosong dari yang meng-inherit mengarah ke yang di-inherit.
Menyusun
Diagram Use case
Langkah-langkah yang dibutuhkan
untuk menyusun diagram use case adalah:
·
Mengidentifikasi pelaku bisnis
·
Mengidentifikasi use case
persyaratan bisnis
·
Membuat diagram model use case
·
Mendokumentasikan naratif use case
persyaratan bisnis
Practical guidance dalam membangun
diagram use case:
·
Set konteks dari target sistem.
·
Identifikasi semua actor.
·
Identifikasi semua use case.
·
Definisikan asosiasi antara setiap
actor dan setiap use case.
·
Evaluasi setiap actor dan setiap use
case untuk mendapatkan kemungkinan perbaikan.
·
Evaluasi setiap use case untuk
dependensi <<include>>.
·
Evaluasi setiap use case untuk
dependensi <<extend>>.
·
Evaluasi setiap actor dan setiap use
case untuk generalisasi.
Use
case Description
Setiap use case harus dijelaskan
alur prosesnya melalui sebuah deskripsi use case (use case description) atau
scenario use case.
Deskripsi use case berisi:
· Nama use case yaitu penamaan use
case yang menggunakan kata kerja
· Deskripsi yaitu penjelasan mengenai
tujuan use case dan nilai yang akan didapatkan oleh aktor
· Kondisi sebelum (pre-condition)
yaitu kondisi-kondisi yang perlu ada sebelum use case dilakukan.
· Kondisi sesudah (post-condition)
yaitu kondisi-kondisi yang sudah dipenuhi ketika uses case sudah dilaksanakan
· Alur dasar (basic flow) yaitu alur
yang menceritakan jika semua aksi yang dilakukan adalah benar atau proses yang
harusnya terjadi
· Alur alternatif (alternatif flow)
yaitu alur yang menceritakan aksi alternatif, yang berbeda dari alur dasar.
Mana yg lebih dahulu dibuat use case
description atau use case diagram ? sebaiknya use case description lebih
dahulu. tapi kalau anda ingin membuat use case digram lebih dahulu juga
tdk apa-apa. Yang penting kedua duanya anda buat untuk
menggambarkan/menjelaskan kebutuhan sistem.
contoh diagram use case:
Diagram
use case ATM
Diagram
use case toko online
C. PERBEDAAN
DAN PERSAMAAN SQURENCE DIAGRAM DAN STATE DIAGRAM
1. Sequence diagram menggambarkan interaksi antar
objek di dalam dan di sekitar sistem (termasuk pengguna, display/form) berupa
message yang digambarkan terhadap waktu. Sequence diagram terdiri atas dimensi
vertikal (waktu) dan dimensi horizontal (objek-objek yang terkait).
2. State diagram mengambarkan seluruh status
yang memungkinkan obyek-obyek dalam class dapat dimiliki dan kejadian-kejadian
yang menyebabkan status berubah. Perubahan dalam suatu state disebut juga
transisi (transition). Suatu transisi juga dapat memiliki sebuah aksi yang
dihubungkan pada status, lebih spesifik apa yang harus dilakukan dalam
hubungannya dengan transisi status. Pada diagram ini, perilaku sistem
ditunjukkan. Sebuah status adalah kondisi selama hidup objek atau interaksi
selama memenuhi suatu kondisi, melaksanakan suatu aksi, atau menunggu suatu
kejadaian.
D. PENGERTIAN
PERANCANGAN PERANGKAT LUNAK
Perancangan perangkat lunak adalah suatu proses bertahap
dimana semua kebutuhan atau persyaratan yang ada pada dokumen SRS diterjemahkan
menjadi suatu cetak blue (blue print) yang akan digunakan untuk membangun
perangkat lunak.
Pada
tahap awal, cetak biru melukiskan suatu gambaran umum dari perangkat lunak
(merupakan penjelasan tingkat tinggi). Pada tahan selanjutnya, penjelasan rinci
dilakukan hingga pada tingkat penjelasan paling rendah.
Perancangan perangkat lunak dilakukan dengan anggapan
spesifikasi kebutuhan perangkat lunak sudah terdefinisikan dalam model-model
analisis. Model-model yang dihasilkan selama perancangan menggambarkan
“bagaimana” permasalahan diselesaikan dalam bentuk spesifikasi perangkat lunak
yang siap diimplementasikan.
E. ELEMEN-ELEMEN
PERANCANGAN DATA, ELEMEN-ELEMEN PERANCANGAN ARSITEKTURAL, ELEMEN-ELEMEN
PERANCANGAN ANTARMUKA, ELEMEN-ELEMEN PERANCANGAN PERINGKAT DALAM BUKU ROGER S.
PRESSMAN
·
Elemen-elemen
perancangan data
Perancangan
data membuat model data dan/atau informasi yang kelak akan di presentasikan pada
pringkat abstraksi yang tinggi (pada sudut pandang pelanggan / pengguna). Model
data ini kemudian di perhalus ke dalam representasi yang lebih spesifik
terhadap implementasi yang dapat di proses oleh system berbasis computer.
Struktur
data hampir selalu merupakan bagian yang penting dari perancangan perangkat
lunak. Pada peringkat komponen program, perancangan struktur data dan algoritma
terkait yang di perlukan untuk memanipulasinya merupakan hal yang sangat
penting untuk mendapatkan perangkat lunak / aplikasi-aplikasi yang berkualitas
tinggi.
·
Perancangan
arsitektural
untuk
sebuah perangkat lunak sesungguhnya elivalen dengan perancangan dasar sebuah
rumah. Perancangan dasar sebuah rumah menggambarkan gambaran keseluruhan
kamar-kamar / ruangan-ruangan. Ukurannya, bentuknya, dan hubungannya dengan
yang lain. Perancangan dasar pada dasarnya memberi gambaran keseluruhan tentang
rumah yang akan dibangun. sementara itu perancangan arsitektural memberi kita
gambaran keseluruhan perangkat lunak yang akan dikembangkan.
Model
arsitektural system/prangkat lunak didapatkan dari tiga sumber:
1.
Informasi tentang ranah aplikasi untuk perangkat lunak yang akan dikembangkan;
2.
Kebutuhan-kebutuhan spesifik elemen-elemen modul seperti diagram aliran data
(Data Flow Diagram) atau kelas-kelas analisis, hubungan-hubungannya dan
kolaborasi-kolaborasinya untuk penyelesaian permasalahan; Dan
3.
Ketersediaan gaya arsitektural serta pola-pola.
Elemen
perancangan arsitektural system / perangkat lunak biasanya digambarkan sebagai
jumlah subsistem yang saling berhubungan.
·
Elemen-elemen
perancangan antarmuka
Ada
tiga elemen penting dari perancangan antarmuka :
1.
Antarmuka pengguna (User Interface);
2.
Antarmuka-antarmuka eksternal ke system-sistem atau subsistem-subsistem yang
lainnya, antarmuka ke sarana-sarana lainnya, antarmuka kejaringan-jaringan
lainnya atau antarmuka ke konsumen-konsumen atau produsen-produsen informasi
yang lainnya; dan
3.
Antarmuka-antarmuka internal di antara berbagai komponen-komponen perancangan.
Perancangan
antarmuka pengguna merupakan tindakan
rekayasa perangkat lunak yang utama, perancangan antarmuka pengguna
menggabuungkan elemen-elemen estetika, elemen-elemen ergonomis, serta
elemen-elemen teknis. Secara umum, antarmuka pengguna merupakan subsistem yang
bersifat unik didalam arsitektur
aplikasi secara keseluruhan.
·
Elemen-elemen
perancangan peringkat komponan
Perancangan
peringkat komponen untuk perangkat lunak secara penuh mendeskripsikan rincian
internal untuk masing-masing komponen perangkat lunak. Untuk mennyelesaikannya,
perancangan peringkat komponen juga mendefinisikan struktur-struktur data local
untuk semua objek-objek data serta rincian algoritma untuk semua pemrosesan
yang terjadi di dalam suatu komponen dan suatu antarmuka yang memungkinkan
akses ke semua oprasi komponen(prilaku).
F. IMPLEMENTASI
PERANCANGAN
·
Elemen
Perancangan Data
Dalam
kasus kerja praktik yang saya lakukan di BUMDES SEGARS model dan perancangan
data dimulai dengan tahapan bagaimana proses pendaftaran kerja sama dan
pelaporan hasil dari data perusahaan yang mendaftar dan telah terdaftar berbasis
Website yang mudah di pahami oleh
pengguna, pengelola, dan direktur.
·
Elemen
Perancangan Arsitektural
Menggambarkan
keseluruhan sistem yang akan berjalan di bawah ini contohnya dalam alur kerja/workflow dari BUMDES SEGARS
·
Elemen
Perancangan Antarmuka
Elemen
ini digunakan dalam tampilan untuk kasus kerja praktik yang saya lakukan,
antarmuka aplikasi yang akan berjalan menggambarkan fungsi – fungsi yang
memudahkan untuk pengguna dan pengelola mengenai objek dan fungsi fitur pada
tampilan, seperti menu, dashboard, admin, dan tombol fungsi yang lainnya.
·
Elemen
Perancangan Peringkat Komponen
Impelementasi
dalam fungsi komponen yang mendukung semua akses dengan penggambaran
arsitektural dalam masing – masing komponen berdasarkan objek penelitian.
f
G. PENGUJIAN
PERANGKAT LUNAK
Suatu proses investigasi yang dilakukan untuk mendapatkan
informasi mengenai kualitas dari suatu produk atau layanan yang sedang diuji,
atau lebih spesifiknya software testing adalah proses mengeksekusi suatu
program untuk menemukan bug (kesalahan atau cacat lainnya) dari perangkat
lunak.
Pengujian perangkat lunak juga memberikan pandangan mengenai
perangkat lunak secara obyektif dan independen, yang bermanfaat untuk memahami
tingkat resiko pada implementasinya.
Hal ini juga dapat dinyatakan sebagai proses validasi dan
verifikasi bahwa sebuah program: Memenuhi persyaratan dan kebutuhan teknis yang
mendasari perancangan dan pengembangan perangkat lunak tersebut. Bekerja
seperti yang diharapkan. Dapat diterapkan menggunakan karakteristik yang sama.
H. STRATEGI PENGUJIAN PERANGKAT LUNAK MELIPUTI
PENGUJIAN UNIT, INTEGRASI, VALIDASI, DAN SISTEM BRDASARKAN BUKU ROGER S.
PRESSMAN
Beberapa
tahapan testing yang umum dilalui oleh aplikasi adalah sebagai berikut :
1. Unit testing merupakan proses
testing dimana pengujian dilakukan pada bagian basic dari kode program,
contohnya pada pengujian kode program pada event, procedure dan function.
Dengan Unit testing meyakinkan bahwa masing-masing unit bekerja sebagaimana
mestinya.
2. Integrating Testing setelah Unit
testing dijalankan, langkah selanjutnya adalah memerika bagaimana unit-unit
tersebut bekerja sebagai suatu kombinasi (bekerja secara bersamaan), bukan lagi
sebagai unit individu. Jika pada tahapat unit testing ada dua function yang
berjalan baik secara individu, maka pada tahap Integration Testing, pengujian
akan dilakukan dari hasil interaksi kedua function tersebut, apakah bekerja
sesuai hasil yang di harapkan, pengujian juga harus dilakukan di seluruh
kondisi yang mungkin terjadi dari hasil antar unit tersebut.
3. System Testing Mencakup testing
aplikasi yang telah selesai didevelop. Karena itu, aplikasi harus terlihat dan
berfungsi sebagaimana mestinya terhadap end-user atau pengguna akhir. Untuk
itu, pengujian dilakukan menggunakan data yang menggambarkan pengguna
sesungguhnya terhadap aplikasi.
4. Validation Testing mencakup
pengujian ulang terhadap unit, component, proses, atau keseluruhan aplikasi
setelah perbaikan suatu kesalahan dilakukan.Regression Testing memastikan
permasalahan yang terjadi telah ditanggulangi, dan tidak terdapat permasalahan
baru yang timbul sebagai efek perbaikan tersebut. Selain itu, tahap ini tidak
hanya berguna untuk melakukan pengujian aplikasi, tetapi dapat juga digunakan
untuk melakukan pemantauan kualitas dari output yang dihasilkan. Sebagai
contoh, Regression Testing memantau ukuran file, waktu yang dibutuhkan untuk
melakukan suatu tes, waktu yang dibutuhkan untuk melakukan kompilasi,dan lain
sebagainya.
I. PENGUJIAN PERANGKAT LUNAK YANG HARUS DILAKUKAN
1. Pengujian terhadap model aplikasi
untu menemukan kessalahan.
2. Peninjauan model antarmuka untuk
memastikan semua komponen dapat digunakan.
3. Perancangan website untuk menemukan
kesalahan navigasi
4. Navigasi arsitektur diuji.
5. Pengujian keamanan dalam upaya mengeksploitasi
kelemahan-kelemahan website.
6. Pengujian kontrol kinerja.
7. Pengujian website dari hasil interaksi yakni dalam hal kesalahan isi,
navigasi, kegunaan, kinerja website.
