MODUL RPL

MSS Lab - Computer System Engineering Departement – UNDIP

MODUL I RENCANA PENGEMBANGAN PERANGKAT LUNAK (RPPL)

1.1 TUJUAN Tujuan modul ini, adalah: •

Praktikan

bisa

membuat

dokumen

rencana

pengembangan perangkat lunak. •

Prak Prakti tika kan n

dapa dapatt

membi embias asak akan an

Doku Dokume men n

Renc Rencan ana a

diri diri

Peng Pengem emba bang ngan an

untu untuk k

menyu enyusu sun n

Pera Perang ngka katt

Luna Lu nak k

(Proposal) secara terstruktur baik dalam satu tim maupun individu. •

Prak Prakti tika kan n

memah emaham amii

orga organi nisa sasi si

tim tim

dalam alam

proy proyek ek

perangkat lunak

1.2 TEORI 1.2.1 Fungsi dalam Pengembangan Perangkat Lunak Software Software Developm Development ent Manageme Management nt (terdi (terdiri ri dari dari banyak banyak fungsi dan tim), yaitu : 1. So Soft ftwar ware e Projec Projectt

Manag Manager er : pert pertam ama a berh berhub ubun unga gan n

dengan dengan konsum konsumen, en, menet menetapk apkan an anggar anggaran an dan jadwal jadwal pelaksanaan proyek perangkat lunak.

2. Software Engingeering Analyst : berhubungan dengan konsumen secara lebih rinci; bertugas mendeskripsikan atau menggali fungsi dan unjuk kerja software yang akandibangun. Designer : Designer : bertugas merancang algoritma/prosedur yang tepat untuk fungsi tersebut disesuaikan dengan hardware atau software pendukung yang ada. Modul Praktikum Rekayasa Perangkat Lunak 2013


Programmer : mengimpl mengimplemen ementasik tasikan an algoritma algoritma dalam bentu entuk k

kode kode--kod kode

prog rogram ram

mengg enggun unak akan an

bahas ahasa a

pemograman.

2. Software Software Configura Configuration tion Managemen Management t : memant memantau au fungsi-fu fungsi-fungsi/ ngsi/pros prosedurp edurprosed rosedur ur yang telah ditentukan ditentukan,, menca mencatat tat konfig konfigura urasi si pada pada tahaptahap-tah tahap/ ap/ waktu waktu-wa -waktu ktu tertentu berdasarkan kenyataan yang ada. Syst System em

Admi Admini nist stra rato tor r

pengelolaan

terhadap

:

bertugas sistem

melakukan pada

saat

diimplementasikan.

4. Software Quality Soft So ftwa ware re

Test Test

Engi Engine neer er :

ber bertugas ugas

mela elakuka kukan n

bert bertug ugas as

melak elakuk ukan an

pengujian sistem. Soft So ftwa ware re

Qual Qualit ity y

pengaw pengawasa asan n

apakah apakah

Assu Assura ranc nce e: software

yang yang

diba dibang ngun un

tela telah h

berjalan sesuai dengan fungsi dan kebutuhannya.

1.2.2 Dokumen Rencana Pengembangan Perangkat Lunak (RPPL) Pada Pada umum umumnya nya sebelu sebelum m melak melakuka ukan n pengem pengemban bangan gan atau pembangunan suatu perangkat lunak, terlebih dahulu dibuat proposal proyek pengembangan atau pembangunan per perang angkat kat

luna lunak k

memb member erik ikan an pera perang ngka katt

ters ersebut ebut..

gamb gambar aran an

luna lunak k

yang yang

Hal

seca secara ra akan akan

bertuj bertujuan uan

ini ini

ring ringka kas s

untuk untuk

meng mengen enai ai

dike dikemb mban angk gkan an

atau atau

dibangun. Format/kerangka dari dokumen Rencana Pengembangan Perangkat Lunak (RPPL) adalah sebagai berikut :

Modul Praktikum Rekayasa Perangkat Lunak 2013


Kerang ngka ka Tabel 1.1 Kera Perangkat Lunak (RPPL)

Doku Dokume men n

Renc Rencan ana a


Peng Pengem emba bang ngan an


Berikut ini

adalah beberapa

contoh isi

dokumen

rencana

pengembangan perangkat lunak untuk kasus Mesin Jual Otomatis

1.1 Gambaran Umum Proyek Sebuah

perusahaan

yang

bergerak

dibidang

pemasaran produk makanan, minuman, rokok dan surat kabar, dalam rangka meningkatkan hasil penjualan dan mutu pelayanannya bermaksud untuk menggunakan Mesin Jual Otomatis (MJO) untuk melayani konsumen yang ingin membeli produk-produk yang dipasarkannya. Mesin Jual Otomatis (MJO) tersebut memiliki panel kendali

yang

berfungsi

sebagai

interface

antara

konsumen dengan MJO. Pada panel kendali tersebut Modul Praktikum Rekayasa Perangkat Lunak 2013


terdapat tombol yang berfungsi untuk memilih jenis produk yang akan dibeli dan tombol yang digunakan untuk memasukan jumlah produk yang dibeli, selain itu panel kendali ini mempunyai layar yang berfungsi untuk memberikan penjualan

pesan-pesan

produk

yang

berkaitan

yang dipasarkannya.

dengan

Pada panel

kendali ini juga terdapat fasilitas untuk memasukan koin dari konsumen. Mesin ini mampu mendeteksi jumlah uang dan nilai uang yang dimasukan. Bila konsumen telah memasukan sejumlah koin tertentu, maka mesin akan menghitung nilai uang tersebut. Jika nilai uang tersebut cukup untuk membayar

produk yang dipilih, maka

mesin akan

mengeluarkan produk yang diinginkan. Jika nilai koin yang dimasukan lebih dari nilai produk yang dipilih, maka mesin akan mengeluarkan koin kembaliannya. Sedangkan jika nilai koin tidak cukup maka mesin akan memberikan pesan bahwa uang yang dimasukan tidak cukup. Selain itu mesin juga akan memberikan pesan jika produk yang diinginkan habis, koin kembalian tidak cukup, dan penampung uang telah penuh. Jenis

koin

yang

dideteksi

adalah

uang

dengan

pecahan seribuan, lima ratusan dan seratusan. Tabel harga

produk

disimpan

dalam file

database

yang

menyimpan informasi tentang jenis produk, harga dari masingmasing produk serta stok dari masing-masing produk tersebut dan kapasitas penyimpanan uang.

1.2 Tujuan



Dokumen ini mendefinisikan aktifitas dan tanggung jawab dari perusahaan yang memberikan kontrak dan pihak pengembang Klien dibagi menjadi dua komponen funsional utama dalam sistem yang dikembangkan yaitu sistem antar muka dan sistem intelegensia ……dst

1.3 Referensi Untuk penanganan proyek ini digunakan acuan dokumen sebagai berikut: -

Pressman,

Roger

S.,

“Software Engineering

:

A

Practitioner’s Approach 4th Edition”, Mc-Graw Hill, 1997. -

Yourdon,

Edward,

“Modern

Structured

Analysis”,

Prentice Hall, 1989 - Davis, Allan M.,” Software Requirements : Analysis & Specification”, Prentice Hall … dan seterusnya

3.1 Tujuan dan Prioritas Manajemen Membangun aplikasi MJO (Mesin Jual Otomatis) untuk memenuhi

kebutuhan

perusahaan

dalam

rangka

meningkatkan hasil penjualan dan mutu pelayanannya terhadap konsumen.

3.3 Batasan Masalah Mesin ini dibuat untuk melayani konsumen yang ingin membeli produk makanan, minuman, rokok dan surat kabar secara otomatis. Uang yang digunakan untuk melakukan transaksi pada mesin ini adalah uang koin dengan pecahan 100, 500 dan 1000. Modul Praktikum Rekayasa Perangkat Lunak 2013


Proyek ini meliputi pengembangan secara lengkap dari MJO meliputi spesifikasi, perancangan, implementasi serta pengujian dari sebagian produk MJO tersebut.

3.4 Dokumentasi Perangkat Lunak Proyek

ini

harus

menyerahkan

dokumen-dokumen

sebagai berikut : •

Dokumen Analisis (SRS)

•

Dokumen Perancangan (SDD)

•

Dokumen Implementasi

•

Dokumen Pengujian (STP dan STR)

•

Software Aplikasi dan Code Program

3.5 Rencana Penugasan Proyek ini dikerjakan oleh tim pengembang yang terdiri dari : •

Software Project Manager : Amir

•

Software Analyst : BudiEni

•

Software Designer : CiciAmir

•

Software Quality Assurance : Deny

•

Software Developer : EniDeny

5 Paket Kerja dan Jadwal Pelaksanaan Proyek ini dilaksanakan selama praktikum RPL, review dan tanggal

penyerahan

akan

diatur

persetujuan project manager.


sesuai

dengan


1.3 PROYEK PERANGKAT LUNAK Kasus 1: Aplikasi penjualan dan pembelian obat di apotek Sebu Sebuah ah apot apotek ek memb membut utuh uhka kan n sebu sebuah ah apli aplika kasi si kasi kasirr untu untuk k mere mereka kap p data data penj penjua uala lan n dan dan pemb pembel elia ian. n. Deng Dengan an dibu dibuat atny nya a apli aplika kas si

ini ini

dihar iharap apka kan n

dapat apat

memba emban ntu

pegaw egawai ai

dala dalam m

memanajemen keuangan di apotek tersebut. Aplikasi tersebut berisi : a. Ap Aplik likasi asi dapat melakuka melakukan n prose proses s trans transaks aksii penjua penjualan lan dan pembelian yang akan berperngaruh pada stock obat yang ada. b. Ap Apli lika kasi si dapa dapatt mena menamp mpil ilka kan n lapo lapora ran n yang yang beri berisi si rinc rincia ian n penjualan obat setiap harinya. (nama obat, jumlah yang terjual, sisa stock, harga dan lain-lain) Kasus 2: Aplikasi laundry Sebuah

laundry

mempe emperm rmud udah ah

membutuhkan

pega pegawa waii

untu untuk k

aplikasi menge engelo lola la

yang bisn bisnis is

dapat laun laundr dry y

terseb tersebut. ut. Ini untuk untuk memu memudah dahkan kan pegawa pegawaii dalam dalam mengh menghitu itung ng keuntungan dari bisnis ini. Modul Praktikum Rekayasa Perangkat Lunak 2013


Aplikasi tersebut berisi: a. Aplikasi Aplikasi ini berisi berisi data yaitu yaitu nama, nama, tanggal tanggal masuk, masuk, tanggal tanggal jadi, jenis laundry, jumlah KG, jumlah harga dan dan lain-lain. b. Aplikasi Aplikasi ini dapat dapat menampil menampilkan kan laporan laporan yang berisi berisi rincian rincian keuangan yang masuk setiap minggunya. (jumlah KG, jenis laundryan, jumlah harga dan lain-lain)

Kasus 3: Aplikasi Penghitungan Gaji Aplikasi sederhana ini berfungsi menghitung gaji pegawai disuatu tempa empatt.

Deng engan

pro program gram

seper epertti

ini, ini,

dihar iharap apka kan n

sebu sebuah ah

peru perusa saha haan an akan akan muda mudah h mere mereka kab b atau atau mend mendat ata a gaji gaji para para pega pegawa wain inya ya.. Teta Tetapi pi sebe sebelu lum m masu masuk k ke prog progra ram m sepe sepert rtii ini ini alan alangk gkah ah baik baikny nya a jika jika kita kita memb membua uatt sebu sebuah ah prog progra ram m log log in terle erleb bih

dahu ahulu, lu,

mengecek

agar agar

gaji-gaji

tid tidak

para

semb embaran arang g

karyawan

oran orang g

di

yang yang

sebuah

bis bisa

instansi

pemerintahan atau perusahaan, karena gaji adalah sesuatu yang privat dan tidak sembarang orang dapat mengetahuinya. Aplikasi tersebut berisi: a. Parameter Parameter-par -paramet ameter er yang digunakan digunakan sebagai sebagai input dalam dalam penghi penghitun tungan gan gaji, gaji, berupa berupa jabata jabatan, n, statu status, s, jumlah jumlah anak anak (jik (jika a stat status usny nya a su suda dah h meni menika kah) h) gaji gaji koto kotor, r, gaji gaji bers bersih ih,, pajak, gaji pokok dan lain sebaginya. b. Aplikasi

ini

dapat

menampilkan

jumlah

gaji

pegawai/ka pegawai/karyaw ryawan an di sebuah sebuah instansi instansi pemerint pemerintahan ahan atau perusahaan.



Kasus 4: Aplikasi Polling Untuk Sebuah Organisasi Sebu Sebuah ah orga organi nisa sasi si su suda dah h bisa bisa dipa dipast stik ikan an memi memili liki ki stru strukt ktur ur organ organisa isasi si dimana dimana ketua ketua organ organisa isasi si berad berada a di tingka tingkatt paling paling ting tinggi gi.. Car Cara yang yang seri sering ng dila dilaku kuka kan n dala dalam m pemi pemili liha han n ketu ketua a organisasi ialah musyawarah dan polling suara terhadap seluruh angg anggot ota a

orga organi nisa sasi si..

Deng Dengan an adan adanya ya apli aplika kasi si poll pollin ing g

untu untuk k

organ organisa isasi si dihara diharapka pkan n dapat dapat memud memudahk ahkan an sebuah sebuah organi organisas sasii untu untuk k

melak elakuk ukan an poll pollin ing g

dala dalam m

kegi kegiat atan an pemi pemili liha han n

ketu ketua a

organisasi. Aplikasi polling tersebut berisi: a. Kode anggota anggota organis organisasi asi yang melaku melakukan kan kegiatan kegiatan polling polling,, dimana dimana kode kode terseb tersebut ut dijadi dijadikan kan sebaga sebagaii identi identitas tas yang yang bersifat unik. b. Field untuk memilih memilih calon calon ketua ketua organis organisasi. asi. c. Ap Apli lika kasi si ter tersebu sebutt dapa dapatt mere mereka kap p dan dan menda endata ta juml jumlah ah plolli plolling ng secara secara keselu keseluruh ruhan an sehing sehingga ga bis bisa a didapa didapatt data data yang yang vali valid d dan dan hasi hasill poll pollin ing g bisa bisa dipu dipubl blik ikas asik ikan an seca secara ra cepat kepada seluruh anggota organisasi. Kasu Kasus s

5: Apli Aplika kasi si Pend Pendaf afta tara ran n

Pemb Pembua uata tan n Sura Suratt

Ijin Ijin

Mengemudi (SIM) Sebu Sebuah ah apli aplika kasi si yang yang meny menyed edia iaka kan n form form untu untuk k logi login, n, form form database petugas, form pendaftaran, form database pendaftar yang yang lulu lulus s dan dan form form datab atabas ase e pend pendaf afta tarr yang yang tida tidak k lulu lulus s (penam (penambah bahan an form form lainny lainnya a tidak tidak dibata dibatasi si sesuai sesuai keingi keinginan nan). ). Aplikasi tersebut diharapkan:



a. Petugas dapat login dan

mengisi

form pendaftaran,

sehingga pada form database dapat menampilkan namanama petugas yang melayani calon pembuat SIM. b. Pada form database yang tidak lulus dapat diperbaharui ketika pendaftar berhasil melewati tes selanjutnya dan dinyatakan lulus, maka data pendaftar tersimpan pada form database yang lulus dan terhapus secara otomatis dari daftar pendaftar yang tidak lulus. NB. (Dimungkinkan untuk pengembangan aplikasi sesuai dengan ide

pengembang.)

Kasus 6: Aplikasi Pembukuan (Booking) Lapangan Futsal Sebuah

aplikasi

yang

mampu

mengatur

sistem

dalam

pemesanan lapangan futsal, dimana calon pemesan dapat melihat lapangan yang telah digunakan ataupun yang telah dipesan. Sehingga calon pemesan dapat melakukan pemesanan selanjutnya sesuai jadwal lapangan yang masih kosong (belum di-booking). Kasus 7: Aplikasi sistem Informasi Kos dan Kontrakan Sebuah aplikasi yang menyediakan informasi bagi mahasiswa dan pelajar mengenai info ketersediaan kos dan kontrakan. Aplikasi ini bersifat prototype sehingga data tidak harus data yang sebenarnya yang ada dilapangan, kos dan alamat bisa dikarang. aplikasi ini berisi nama kos/kontrakan, alamat, harga, fasilitas dan juga ketersediaan kamar yang masih kosong dan sudah dibooking. Diharapkan dengan adanya aplikasi ini suatu saat dapat dikeembangkan dan dapat membantu para pelajar dan juga mahasiswa yang sdng mmbutuhkan info kos dan kontrakan. Aplikasi ini diharapkan dapat menangani: Modul Praktikum Rekayasa Perangkat Lunak 2013


a. pendaftaran user (sign up) (berisi data dan informasi mhsswa dan pelajar) yg masuk kdalam SI ini. b. calon pemesan dapat melihat kos/kontrakan yang masih kosong, ataupun yang telah dipesan. sehngga tersedia jumlah kamar yang kosong bila telah dibooking maka jumlah otomatis akan berkurang sendiri. Kasus 8: Aplikasi Pemesanan Tempat Duduk Pada BUS AKAP Aplikasi ini diharapkan dapat melayani para calon penumpang Bus AKAP sehingga proses pelayanan antara penumpang dan agen menjadi mudah dan terorganisir. sistem ini diharapkan mampu : a. Menampilkan visualisasi jumlah kursi yang ada di bus. b. Apabila

kursi

penumpang

selanjujtnya kursi

tidak

tlh

dipesan

maka

untuk

dapat dipesan/dibooking

lagi.

(harus membayar dahulu). c. Bus menempuh 3 kota tujuan misalkan solo, sukoharjo, malang. maka setiap kota mempunyai warna yg berbeda bila telah diboking. d. Sistem Dapat melayani proses transaksi pembelian tiket, jadi pada saat kursi dipesan maka penumpang juga harus membayar sejumlah harga apabila terdapat kembalian maka kembalian juga dapat ditampilkan. Kasus 9: Aplikasi sistem informasi laboratorium IPA (SMA) Aplikasi

ini

menyediakan

informasi-informasi

:

a.

jadwal

penggunaan lab b. informasi alat-alat praktikum menurut bidang study (biologi/fisika/kimia) c. jadwal laboran yg bertugas dan Modul Praktikum Rekayasa Perangkat Lunak 2013


penanggung jawab lab dan penambahan informasi lab lain yang tidak dibatasi sesuai keinginan. pada sub (b,) yaitu informasi alat-alat lab, diperjelas lagi dengan adanya informasi mengenai daftar alat-alat baru yang masuk ke lab, alat-alat lama yang perlu pembaharuan, dan daftar kerusakan alat yang mungkin dilakukan oleh siswa. Aplikasi

ini

diharapkan

dapat

membantu

laboran

dalam

mengelola laboratorium, baik dalam penjadwalan penggunaan lab, maupun pengelolaan peralatan laboratorium. Kasus 10: Aplikasi sistem informasi butik Sebuah aplikasi yang menyediakan informasi : a. informasi barang-barang yang tersedia (jenis barang, merk, ukuran, harga, stok) b. informasi transaksi (penjualan) barang (tanggal masuk, tanggal keluar, rekap per hari/bulan/tahun) c. rekap faktur dan data barang d. data pegawai e.memiliki dua level akses yaitu admin dan kasir. aplikasi ini diharapkan dapat mempermudah transaksi penjualan menjadi lebih cepat dan mudah, serta manajemen data lebih terorganisir. Kasus 11: Sistem Informasi Petshop Sebuah

sistem

informasi

yang

digunakan

untuk

menjual

accesories petshop dan jual-beli hewan peliharaan. menyediakan informasi gambar produk, harga dan ketersediaan barang. aplikasi ini diaharapkan dapat menangani: a. Pendaftaran member (sign up) yang berisi user dan password, dan pengisian identitas pelanggan berupa nama dan alamat, bisa ditambahkan informasi lainnya. b. User yang sudah login dapat melakukan belanja dan mengunggah

foto

hewan

yang

akan


dijual

disertai


informasi lengkap mengenai hewan (jenis hewan, nama, usia, dll) Kasus

12:

Sistem

Pemesanan

dan

Pembelian

Tiket

Bioskop Sebuah usaha tempat bioskop membutuhkana suatu sistem untuk melakukan pemesanan dan pembelian tiket bioskop. Aplikasi ini digunakan untuk mempermudah proses administrasi dan pembelian tiket bioskop. Aplikasi tersebut diharapkan dapat melakukan hal-hal berikut: a. Fasilitas login untuk admin, dan karyawan/kasir loket untuk menghindari penyalahgunaan hak akses. b. Menampilkan daftar kursi yang masih kosong ataupun sudah dipesan. c. Menampilkan jadwal tayang dan daftar film yang akan diputar. d. Melayani transaksi pembelian tiket bioskop. e. Pemesanan tiket hanya bisa dilakukan untuk H-1 film yang akan ditayangkan. Kemudian tiket yang telah dipesan akan tersimpan di database. Pembeli yang sudah melakukan pembayaran akan disimpan oleh sistem kedalam database. Sistem akan mengirimkan pesan pemberitahuan kepada petugas ke dalam kotak pesan/inbox yang dimiliki oleh petugas bahwa pembeli sudah melakukan pembayaran kemudian petugas akan mengubah status bayar pembeli. Sistem akan menyimpan status pembeli yang sudah diubah ke dalam database, kemudian sistem akan menampilkan resi pembayaran dan nomor kursi yang dipilih pembeli. Modul Praktikum Rekayasa Perangkat Lunak 2013


Kasus

13:

Aplikasi

Parkir

Kendaraan

Pada

Pusat

Perbelanjaan Sebuah pusat perbelanjaan membutuhkan suatu sistem parkir untuk mempermudah pengaturan kendaraan yang masuk dan keluar

dari

dank e

pusat

perbelanjaan.

Aplikasi tersebut

diharapkan dapat: a. menginput data kendaraan (nomor kendaraan dan jam masuk tempat kerja). b. Terdapat fasilitas login untuk admin, dan petugas parker untuk menghindari penyalahgunaan hak akses. c. Melayani pembayaran tarif parkir Sepeda motor Mobil

: Rp. 1000,-

: Rp. 2000,-

Tarif parkir melebihi dua jam, akan dikenakan tambahan biaya masing-masing Rp. 1000,-/jam. d. Sistem akan menyimpan data kendaraan dan waktu parkir kendaraan pada database, kemudian setelah transaksi pembayaran selesai, sistem akan menampilkan karcis parkir yang berisi nomor kendaraan, jam masuk, jam keluar dan tarif yang telah dibayar. Kasus 14: Sistem Informasi Penggunaan LAB. SE SISKOM Sebuah sistem informasi yang digunakan untuk memberikan jadwal penggunaan Lab. SE dan pemesanan ruangan Lab.SE. aplikasi ini diaharapkan dapat menangani:



a. pemesanan ruangan Lab.SE dengan waktu yang telah disediakan (hanya tedapat pada saat jam kerja/aktif kuliah saja). b. jadwal penggunaan Lab.SE. c. form-form pendaftaran/pemesanan ruangan. Sistem informasi ini hanya dapat diakses oleh mahasiswa siskom atau dosen siskom saja (user), dan diatur secara teratur oleh admin yang juga adalah pihak TU Siskom. Kasus 15: aplikasi pemilu Cagub dan Cawagub Semarang aplikasi ini memberikan beberapa keuntungan pada anggota masyarakat dan pihak KPU selaku juri dalam pemilihan legeslatif ini.kemudahan yang didapatkan adalah seperti penjumlahan suara yang telah dapat dilakukan secara otomatis dengan aplikasi ini, pemberian waktu yang tak terbatas pada calon pemilih dalam melakukan pemberian suara pada pemilu ini, dan pengurangan dana dalam penyediaan tempat pemlihan. aplikasi ini diharapkan dapat menangani hal-hal berikut : a. pendaftaran calon pemilih sebelum melakukan pemilihan dengan memberikan nomor KTP yang dimilikinya,dimana ketika setelah memberikan nomor KTP yang diminta, data dari calon pemilih akan ditampilkan dan pada tampilan tersebut akan terlihat apakah calon pemilih tersebut berhak memilih dalam pemilu tersebut atau tidak. b. user yang dapat melakukan proses pemilihan cagub dan cawagub tidak dapat melakukan proses pemilihan ag kedua kalinya dan hal tersebut ditandai dengan user tidak dapat mengakses form tersebut setelah menekan tombol pilih pada cagub dan cawagub yang diinginkan. Modul Praktikum Rekayasa Perangkat Lunak 2013


Kasus 16 : sistem informasi wedding planer Aplikasi ini memberikan informasi tentang Catering pernikahan, tailor (penjahit baju pengantin), gedung pernikahan, referensi model baju pengantin terbaru, tempat percetakan undangan. Semua informasi tersebut disertai kisaran range harga. User dapat

memilih

dan

mengkalkulasikan

semua

biaya

yang

dibutuhkan. 1.4 BAHASA PEMROGRAMAN 1. PHP PHP adalah bahasa pemrograman server side yang sudah banyak digunakan pada saat ini, terutama untuk pembuatan website dinamis. Untuk hal-hal tertentu dalam pembuatan web, bahasa pemrograman PHP memang diperlukan, misalnya saja untuk memproses data yang dikirimkan oleh pengunjung web. PHP pertama kali dibuat oleh Rasmus Lerdorf pada tahun 1995. Pada waktu itu PHP bernama FI (Form Interpreted). Pada saat tersebut PHP adalah sekumpulan script yang digunakan untuk mengolah data form dari web.

2. Java Java

adalah

bahasa

pemrograman

tingkat

tinggi

yang

berorientasi objek dan program java tersusun dari bagian yang disebut kelas. Kelas terdiri atas metode-metode yang melakukan pekerjaan dan mengembalikan informasi setelah melakukan tugasnya. Para pemrogram Java banyak mengambil keuntungan dari kumpulan kelas di pustaka kelas Java, yang disebut dengan Java Application Programming Interface (API). Kelas-kelas ini

diorganisasikan

menjadi

sekelompok

yang

disebut

paket(package). Java API telah menyediakan fungsionalitas yang Modul Praktikum Rekayasa Perangkat Lunak 2013


memadai untuk menciptakan applet dan aplikasi canggih. Jadi ada dua hal yang harus dipelajari dalam Java, yaitu mempelajari bahasa Java dan bagaimana mempergunakan kelas pada Java API. Kelas merupakan satu-satunya cara menyatakan bagian eksekusi program, tidak ada cara lain. Pada Java program javac untuk mengkompilasi file kode sumber Java menjadi kelaskelas bytecode. File kode sumber mempunyai ekstensi *.java. Kompilator

javac

menghasilkan

file bytecode kelas

dengan

ekstensi *.class. Interpreter merupakan modul utama sistem Java yang

digunakan

aplikasi

Java

dan

menjalankan

program bytecode Java. Beberapa keunggulan java yaitu java merupakan bahasa yang sederhana. Java dirancang agar mudah dipelajari dan digunakan secara efektif. Java tidak menyediakan fitur-fitur rumit bahasa pemrograman

tingkat

tinggi,

serta

banyak

pekerjaan

pemrograman yang mulanya harus dilakukan manual, sekarang digantikan dikerjakan Java secara otomatis seperti dealokasi memori. Bagi pemrogram yang sudah mengenal bahasa C++ akan cepat belajar susunan bahasa Java namun harus waspada karena mungkin Java mengambil arah (semantiks) yang berbeda dibanding C++. 3. Visual Basic Microsoft

Visual Basic

(sering

disingkat

sebagai

VB saja)

merupakan sebuah bahasa pemrograman yang menawarkan Integrated

Development

Environment

(IDE)

visual

untuk

membuat program perangkat lunak berbasis sistem operasi Microsoft Windows dengan menggunakan model pemrograman (COM), Visual Basic merupakan turunan bahasa pemrograman BASIC

dan

menawarkan

pengembangan

perangkat

lunak

komputer berbasis grafik dengan cepat, Beberapa bahasa skrip Modul Praktikum Rekayasa Perangkat Lunak 2013


seperti Visual Basic for Applications (VBA) dan Visual Basic Scripting Edition (VBScript), mirip seperti halnya Visual Basic, tetapi cara kerjanya yang berbeda. Para programmer dapat membangun

aplikasi

dengan

menggunakan

komponen-

komponen yang disediakan oleh Microsoft Visual Basic Programprogram

yang

ditulis

dengan

Visual

Basic

juga

dapat

menggunakan Windows API, tapi membutuhkan deklarasi fungsi luar tambahan. Dalam pemrograman untuk bisnis, Visual Basic memiliki pangsa pasar yang sangat luas. Dalam sebuah survey yang dilakukan pada tahun 2005, 62% pengembang perangkat lunak dilaporkan menggunakan berbagai bentuk Visual Basic, yang diikuti oleh C++, JavaScript, C#, dan Java.

1.4 LATIHAN PRAKTIKUM I Latihan Praktikum 1 (pertemuan ke satu) 1

Pilih salah satu kasus proyek perangkat lunak di atas (point 1.3) dengan syarat tidak boleh sama dengan tim yang lain. (Opsional)

2

Buat organisasi tim pengembang proyek perangkat lunak dan pilih salah satu kasus diatas (opsional)

3

Buat Proposal proyek perangkat lunak sesuai kasus yang telah dipilih atau ditetapkan oleh tim/instruktur.

Catatan : • Kasus dan tim pengembang proyek perangkat lunak bisa dipilih sendiri oleh kelompok praktikan atau ditetapkan oleh instruktur. •

Pemilihan bahasa pemrograman dilakukan sesuai kesepakatan praktikan dengan asisten praktikum RPL



• Dalam satu kelas tidak ada kasus proyek perangkat lunak yang sama



MODUL II ANALISIS SISTEM


Memperkenalkan penggunaan perangkat lunak bahasa pemrograman untuk mengimplementasikan struktur data (tipe data abstrak, list berkait linear).

•

Praktikan

dapat

pemodelan

menerapkan

sistem

untuk

teknik

komunikasi

memahami

sistem

dan yang

dibangun. •

Praktikan

dapat

mendokumentasikan

Software

Requirement Specification (SRS) dan mampu menerapkan pemodelan fungsional. •

2.2

Praktikan dapat melakukan review dokumen analisis.

TEORI

2.2.1 Prosedur Analisis (Procedure Analysis) a) Bagaimana metode itu digunakan •

Dengan

prosedur

operasi

dapat

mempelajari

dan

mengidentifikasikan aliran dokumen kunci melalui sistem informasi, yaitu dengan data flow diagram (DFD). •

Setiap aliran dokumen kunci menjelaskan prosedur operasi sistem.

•

Melalui observasi, analis mempelajari kenyataan daripada mendeskripsikan volume distribusi (tinggi, rendah, sedang) dan apa yang selanjutnya dikerjakan terhadap salinan dari dokumen aslinya.

b) Target dari metode •

Dokumen utama dalam DFD (Data Flow Diagram)



•

Proses dalam DFD.

•

Penggambaran Use Case Diagram

•

Deskripsi Use Case Diagram

c) Keuntungan metode •

Evaluasi prosedur dapat dikerjakan dengan campur tangan (interferences) yang minimal dan tidak mempengaruhi operasi pemakai.

•

Prosedur aliran dapat

dapat menjadi

sebuah struktur

checklist untuk melakukan observasi. d) Kerugian metode •

Prosedur mungkin tidak lengkap dan tidak up to date lagi.

•

Mempelajari bagan aliran dokumen membutuhkan waktu dan keahlian analis.

e) Kapan metode tersebut baik digunakan •

Memutuskan apakah masalah

kegagalan

sistem dapat

membantu perancangan yang baik. •

Tim

analis

tidak

secara

total

familiar

dengan

aliran

dokumen. •

Mendeskripsikan aliran dokumen yang menganggu kerjanya fungsi.

2.2.2 Pengamatan Dokumen (Document Survey ) a) Bagaimana metode itu digunakan. •

Mengidentifikasikan dokumen utama dan laporan ( physical data flow diagram).

•

Mengumpulkan salinan dokumen aktual dan laporan.

•

Setiap dokumen atau laporan, digunakan untuk record data, meliputi field (ukuran dan tipe), frekuensi penggunaan dan struktur kodingnya (coding structure).

b) Target dari metode. Modul Praktikum Rekayasa Perangkat Lunak 2013


•

Aliran data kunci ditunjukkan dalam data flow diagram (DFD).

•

Fungsionalitas sistem ditunjukkan dalam Use Case Diagram.

c) Keuntungan metode. •

Meminimalkan interupsi dari fungsi operasionalnya.

•

Permulaan elemen kamus data.

•

Seringkali,

dapat

mempertimbangkan

modifikasi major

procedural. d) Kerugian metode. •

Membutuhkan waktu yang cukup (terdapat organisasi bisnis yang mengalami kebanjiran dokumen dan laporan).

e) Kapan metode tersebut baik digunakan. •

Harus dikerjakan jika sebuah sistem akan didesain (selama kegiatan analisis, dalam memperjelas desain sistem yang baru

dan

analisis

dokumen

dapat

membantu

untuk

menentukan tugas perancangan selanjutnya).

2.2.2.1 Analisis Kebutuhan Perangkat Lunak Analisis kebutuhan bertujuan untuk menggali kebutuhankebutuhan (requirement ) yang harus dipenuhi oleh software yang akan dibuat untuk memperoleh fungsi dan kelakuan software. Pada fase analisis ini, user kadang akan memformulasi ulang fungsi dan unjuk kerja yang diinginkan dengan lebih detail. Sedangkan bagi pengembang/analis akan bertindak sebagai “interogator,

konsultan

dan

pemecahan

masalah”.

Analisis

kebutuhan ini adalah pekerjaan rekayasa perangkat lunak yang menjembatani

antara

level

spesifikasi

perancangan perangkat lunak.


sistem

dengan


Gambar 2.1 Gambaran Software Requirement Analysis

Analisis kebutuhan dibagi menjadi lima bagian, yaitu : (1) Pengenalan Masalah; (2) Evaluasi Sintesa; (3) Pemodelan; (4) spesifikasi; (5) Peninjauan Ulang/(review). Prinsip-prinsip Analisis : a. Domain Fungsi dari masalah harus ditunjukkan. b. Fungsi yang akan dilaksanakan oleh perangkat lunak harus terdefinisi. c. Kesalahan dari perangkat lunak harus ditunjukkan. d. Model yang menggambarkan informasi, fungsi dan kelakuan harus dibagi-bagi menjadi beberapa lapis tingkatan untuk mendapatkan informasi yang lebih detail. e. Proses analisis hendaknya memindahkan dari informasi yang penting ke arah penerapan yang rinci.

2.2.2.2 Prinsip Analisis a. Daerah informasi dari masalah harus dimengerti. b. Fungsi yang harus dilakukan oleh software harus terdefinisi. c. Kelakuan software (sebagai akibat dari pengaruh luar) harus terwakili atau ditampilkan. d. Membuat pemodelan yang menggambarkan informasi, fungsi dan kelakuan software. e. Proses analisis harus mengubah informasi yang diperoleh menjadi informasi yang siap dirancang untuk implementasi.

2.2.3 Pemodelan Sistem 2.2.3.1 Pemodelan dalam Analisis Terstruktur Modul Praktikum Rekayasa Perangkat Lunak 2013


Pemodelan sistem disini menggunakan metode Data Flow Oriented dengan tool Data Flow Diagram (DFD). DFD adalah (1) Suatu teknik penggambaran atau pemodelan menggunakan notasi-notasi grafis yang menunjukkan aliran informasi dan perubahannya perpindahan (output );

(2)

yang data

diterapkan

dari

Peralatan

masukan

sebagai (input )

pemodelan

yang

perubahan menjadi

atau

keluaran

mengijinkan

kita

menggambarkan sistem sebagai suatu jaringan proses-proses yang dihubungkan dengan baris data dan tangki penyimpanan data. A. DFD Level DFD dapat digambarkan dalam Diagram Context dan Level n. Huruf n dapat menggambarkan level dan proses di setiap lingkaran. Diagram Context Diagram Level n

-

DFD Logis

-

DFD Fisik

B. Notasi DFD Tabel 2.1 Notasi DFD



C. Aturan-aturan pembuatan DFD - Suatu proses harus menghasilkan output. -

Store hanya muncul di DFD, tidak boleh di Data Context Diagram (DCD).

-

Aliran data (data flow) tidak boleh dari store (penyimpanan data) ke store lain.

-

Jumlah aliran data (data masuk dan data keluar) harus konsisten.

-

Hindari proses yang hanya mempunyai aliran data masuk atau data keluar.

-

Hati-hati terhadap store yang hanya mempunyai aliran data masuk atau data keluar.



-

Hati-hati dengan aliran data yang tidak diberi nama, beri nama aliran data dengan kata benda.

-

Hindari proses yang tidak diberi nama, beri nama proses dengan kalimat sederhana yang menunjukan apa yang akan diproses dan sebaiknya selain nama, suatu proses juga diberi nomor.

D. Panduan untuk Membuat DFD -

Pilih nama yang bermakna untuk proses, store dan aliran data

-

Berikan penomoran untuk setiap proses yang ada

-

Hindari penggambaran DFD yang rumit (dapat diatasi dengan menggunakan pelevelan)

-

Gambar beberapa kali untuk mendapatkan hasil yang enak untuk dilihat

-

Yakini bahwa DFD konsisten secara internal

E. Tentang Pelevelan DFD 1) Bagaimana anda tahu berapa banyak level yang harus dimiliki DFD? - Tergantung pada jumlah prosesnya. - Berapa banyak proses yang optimum pada satu level DFD. 2) Apakah setiap bagian sistem harus dirinci sama banyak? - Tergantung proses yang dibutuhkan rincian lebih lanjut. 3) Bagaimana anda menunjukan level-level DFD ini ke user ? - Tergantung user yang dibutuhkan DFD. 4) Bagaimana menggambarkan store pada berbagai level. - Tergantung simbol store yang akan digunakan. - Tergantung jumlah store yang digunakan oleh suatu proses. Modul Praktikum Rekayasa Perangkat Lunak 2013


5) Bagaimana menjamin level DFD konsisten dengan yang lain? - Jumlah data yang masuk dan keluar harus sama dengan DFD yang lain.

2.2.3.2 Pemodelan UML Unified Modelling Language (UML) adalah sebuah "bahasa" yg telah menjadi standar dalam industri untuk visualisasi, merancang dan mendokumentasikan sistem piranti lunak. UML menawarkan sebuah standar untuk merancang model sebuah sistem. Dengan menggunakan UML kita dapat membuat model untuk semua jenis aplikasi piranti lunak, dimana aplikasi tersebut dapat berjalan pada piranti keras, sistem operasi dan jaringan apapun, serta ditulis dalam bahasa pemrograman apapun. Tetapi karena UML juga menggunakan class dan operation dalam konsep dasarnya, maka ia lebih cocok untuk penulisan piranti lunak dalam bahasa-bahasa berorientasi objek seperti C++, Java, C#

atau

VB.NET.

Walaupun

demikian,

UML

tetap

dapat

digunakan untuk modeling aplikasi prosedural dalam VB atau C. Seperti bahasa-bahasa lainnya, UML mendefinisikan notasi dan syntax /semantik. Notasi UML merupakan sekumpulan bentuk khusus untuk menggambarkan berbagai diagram piranti lunak. Setiap bentuk memiliki mendefinisikan

makna

bagaimana

tertentu,

bentuk-bentuk

dan UML syntax tersebut

dapat

dikombinasikan. Notasi UML terutama diturunkan dari 3 notasi yang telah ada sebelumnya: Grady Booch OOD (Object-Oriented Design), Jim Rumbaugh OMT (Object Modeling Technique), dan Ivar Jacobson OOSE (Object-Oriented Software Engineering).



Dimulai pada bulan Oktober 1994 Booch, Rumbaugh dan Jacobson, yang

merupakan tiga

tokoh

yang

boleh

dikata

metodologinya banyak digunakan mempelopori usaha untuk penyatuan metodologi pendesainan berorientasi objek. Pada tahun 1995 direlease draft pertama dari UML (versi 0.8). Sejak tahun

1996

pengembangan

tersebut

dikoordinasikan

oleh

Object Management Group (OMG – http://www.omg.org). Tahun 1997 UML versi 1.1 muncul, dan saat ini versi terbaru adalah versi 1.5 yang dirilis bulan Maret 2003. Booch, Rumbaugh dan Jacobson menyusun tiga buku serial tentang UML pada tahun 1999. Sejak saat itulah UML telah menjelma menjadi standar bahasa pemodelan untuk aplikasi berorientasi objek. Kesuksesan suatu pemodelan piranti lunak ditentukan oleh tiga unsur, yang kemudian terkenal dengan sebuan segitiga sukses (the triangle for success). Ketiga unsur tersebut adalah metode pemodelan (notation), proses ( process) dan tool yang digunakan. Memahami notasi pemodelan tanpa mengetahui cara pemakaian yang sebenarnya (proses) akan membuat proyek gagal. Dan pemahaman

terhadap

metode

pemodelan

dan

disempurnakan dengan penggunaan tool yang tepat. Modul Praktikum Rekayasa Perangkat Lunak 2013

proses


Gambar 2.2 Skema notasi pemodelan

A. Konsepsi Dasar UML Dari berbagai penjelasan rumit yang terdapat di dokumen dan buku-buku UML. Sebenarnya konsepsi dasar UML bisa kita rangkumkan dalam tabel di bawah.

Tabel 2.2 Konsepsi Dasar UML



Abstraksi konsep dasar UML yang terdiri dari structural classification, dynamic behavior , dan model management , bisa kita pahami dengan mudah apabila kita melihat gambar diatas dari Diagrams. Main concepts bisa kita pandang sebagai term yang akan muncul pada saat kita membuat diagram. Dan view adalah kategori dari diagaram tersebut. Lalu darimana kita mulai? Untuk menguasai UML, sebenarnya cukup dua hal yang harus kita perhatikan: 1. Menguasai pembuatan diagram UML 2. Menguasai

langkah-langkah

dalam

analisa

dan

pengembangan dengan UML Tulisan ini pada intinya akan mengupas kedua hal tersebut. Seperti juga tercantum pada gambar di atas, UML Modul Praktikum Rekayasa Perangkat Lunak 2013


mendefinisikan diagram-diagram, salah satunya yaitu use case diagram.

B. Use Case Diagram Use case diagram menggambarkan fungsionalitas yang diharapkan dari sebuah sistem. Yang ditekankan adalah “apa” yang diperbuat sistem, dan bukan “bagaimana”. Sebuah use case merepresentasikan sebuah interaksi antara aktor dengan sistem. Use case merupakan sebuah pekerjaan tertentu, misalnya login ke sistem, meng-create sebuah daftar belanja, dan sebagainya. Seorang/sebuah aktor adalah sebuah entitas manusia atau

mesin

melakukan diagram

yang

berinteraksi

dengan

pekerjaan-pekerjaan

dapat

menyusun

sangat

tertentu.

membantu

requirement

mengkomunikasikan

sistem

bila

sebuah

rancangan

dengan

untuk

Use kita

case sedang sistem,

klien,

dan

merancang test case untuk semua feature yang ada pada sistem. Sebuah use case dapat meng-include fungsionalitas use case lain sebagai bagian dari proses dalam dirinya. Secara umum diasumsikan bahwa use case yang di-include akan dipanggil

setiap

kali

use

case

yang

meng-include

dieksekusi secara normal. Sebuah use case dapat diinclude oleh lebih dari satu use case lain, sehingga duplikasi

fungsionalitas

dapat

dihindari

dengan

cara

menarik keluar fungsionalitas yang common. Sebuah use case juga dapat meng-extend use case lain dengan behaviour -nya sendiri. Sementara hubungan generalisasi antar use case menunjukkan bahwa use case yang satu merupakan spesialisasi dari yang lain. Modul Praktikum Rekayasa Perangkat Lunak 2013


Use case diagram menggambarkan interaksi antara aktor dengan proses atau sistem yang dibuat. Use case diagram mempunyai beberapa bagian penting seperti : Actor, Use Case, Undirectional Association, Generalization. 1. Actor Actor merupakan

bagian

dari

Use

Case

yang

bertindak sebagai subjek (pelaku) dalam suatu proses. 2. Use Case Use Case adalah proses-proses yang terjadi dalam suatu software. Use case juga menggambarkan apa yang sedang dilakukan oleh seorang Actor. 3. Relasi Relasi menggambarkan hubungan antara actor dan use case. Relasi-relasi tersebut dapat dibagi menjadi : •

Undirectional Association

•

Generalization

•

Dependency

Contoh Use Case Diagram : Modul Praktikum Rekayasa Perangkat Lunak 2013


2.2.4 Dokumen yang Terlibat dalam Fase Analisis atau Spesifikasi

-

IRS

(Interface Requirement Specification) menjelaskan

sistem secara global serta kaitannya dengan lingkungan sekitarnya. -

SRS (Software Requirement Specification) menjelaskan sistem secara detail termasuk fungsi-fungsi atau proses yang harus dipenuhi.

2.2.5 CSPEC (Control Specification) Modul Praktikum Rekayasa Perangkat Lunak 2013


Digunakan untuk mengindikasikan bagaimana perlakuan software ketika suatu kejadian atau sinyal kontrol mulai terjadi dan

proses

apakah

yang

diaktifkan

sebagai

konsekuensi

terjadinya suatu kejadian. CSPEC selalu berhubungan dengan kontrol bar. Tabel 2.3 Tabel CSPEC

2.2.6 PSPEC (Process Specification)

Deskripsi tentang apa yang terjadi pada proses level paling bawah, pada suatu diagram aliran data. Disebut juga dengan “MINISPEC” (Miniatur Specification) [De Marco]. Maksud dari spesifikasi ini adalah untuk mendefinisikan apa yang harus dilakukan

untuk

mengubah

aliran

masuk

(Input )

menjadi

keluaran (Output ). a. Macam-macam alat untuk spesifikasi proses : 1. Structured English Adalah bagian dari bahasa inggris dengan pembatasan pada kalimat yang dipakai dan cara dalam hal pemakaian kalimat disini dikenal juga sebagai kalimat PDL (Program Design Language) dan PSL (Program Statement Language). Kalimat dalam structured english bisa berupa persamaan aljabar. 2. Pre-Conditioning/Past Conditioning (kondisi awal dan kondisi akhir) digunakan

untuk

menggambarkan

fungsi yang harus

ditangani oleh Modul Praktikum Rekayasa Perangkat Lunak 2013


sebuah proses tanpa bertanya tentang algoritma atau prosedur yang digunakan. 3. Narrative English adalah pemaparan spesifikasi dengan menggunakan

kalimat

bahasa

inggris

sebagaimana

mestinya. b. Pertimbangan penggunaan alat untuk proses spesifikasi -

Spesifikasi proses harus dalam bentuk yang bisa diperiksa oleh user dan analisis sistem.

- Spesifikasi proses harus dalam bentuk yang bisa membuat komunikasi yang efektif bagi orang yang terlibat.

2.2.7 Kamus Data (Data Dictionary )

Kamus data adalah daftar terorganisir dari semua elemen data

yang

ada

pada

suatu

sistem

dengan

definisi

yang

jelas/tepat, sehingga user dan analisis sistem bisa mendapat kesepahaman

dari

input,

output

dan

komponen

dari

penyimpanan dan kalkulasi “intermediate” yang ada. Kamus Data dibuat berdasarkan aliran data yang ada di DFD (Data Flow Diagram). Aliran data di DFD sifatnya adalah global, hanya ditunjukkan nama arus datanya saja. Keterangan lebih lanjut tentang struktur dari suatu arus data di DFD secara lebih terinci dapat dilihat di kamus data. Kamus data mendefinisikan elemen data dengan fungsi sebagai berikut: a) Menjelaskan arti aliran data dan penyimpanan dalam DFD. b) Mendeskripsikan komposisi paket data yang bergerak melalui aliran, misalnya alamat diuraikan menjadi kota, kodepos, propinsi, dan negara. c) Mendeskripsikan komposisi penyimpanan data.



d) Menspesifikasikan nilai dan satuan yang relevan bagi penyimpanan dan aliran. e) Mendeskripsikan hubungan detil antara penyimpanan yang akan menjadi titik perhatian dalam entity relationship diagram.

Notasi kamus data yang digunakan dalam analisis sistem, yaitu Tabel 2.4 Tabel Kamus Data

2.2.8 Pemodelan Kelakuan (Behaviour Model )

Digambarkan dengan menggunakan CSPEC dalam dua cara : a.

Process

Activation

Table

(PAT)

adalah

tabel

yang

menggambarkan kapan suatu proses diaktifkan dan oleh kontrol apa pengaktifan tersebut terjadi b. State

Trantition

Diagram

(STD)

adalah

merupakan

spesifikasi sekuensial (terurut) dari kelakuan suatu sistem. STD digambarkan dengan notasi tanda kotak yang menunjukan keadaan sistem dan panah yang menunjukan transisi keadaan.

2.2.9 SRS (Software Requirement Specification) Modul Praktikum Rekayasa Perangkat Lunak 2013


SRS adalah hasil akhir dari proses analisis. Fungsi dan kinerja yang harus dipenuhi sebagai bagian dari rekayasa sistem ditetapkan dengan deskripsi

yang lengkap, baik deskripsi

fungsional dan behavioral . Format/kerangka SRS, adalah sebagai berikut :

Tabel 2.5 Kerangka SRS





2.2.10 Software Specification Review Review diikuti oleh konsumen dan pengembang dengan tujuan untuk mendapatkan kesepahaman terhadap software yang akan dikembangkan. Panduan melakukan review yang lebih detail, adalah sebagai berikut : -

Perhatikan kata/term yang bermakna kabur (misalnya kadang, sebagian dll)



-

Jika ada suatu daftar tapi tidak lengkap, yakinkan bahwa semua item terpenuhi

-

Hati-hati dengan kalimat yang membingungkan

-

Yakinlah dengan jangkauan keadaan

-

Jika suatu term telah didefinisikan dengan jelas disuatu tempat, sebaikanya menggunakan pengacuan terhadap term tersebut tidak perlu mendefinisikan ulang.

2.3. LATIHAN-LATIHAN PRAKTIKUM 2.3.1

Latihan Praktikum I 1. Analisis kasus proyek perangkat lunak pada pertemuan ke satu! 2. Dokumentasikan hasil analisis tersebut dalam dokumen SRS (Bab I dan Bab II) ! 3. Buatlah pemodelan sistem yang Anda buat dengan menggunakan metode Data Flow Oriented dengan tools Data Flow Diagram !

2.3.1

Latihan Praktikum II 1. Buat PSEPC dan Kamus Datanya ! 2. Buatlah pemodelan sistem yang Anda buat dengan menggunakan Use Case Diagram beserta deskripsi masing-masing Use Case ! 3. Dokumentasikan hasil analisis tersebut dalam dokumen SRS (Bab III point 3.1 dan 3.2) !



MODUL III PERANCANGAN SISTEM


Praktikan dapat menerapkan teknik dalam tahapan perancangan perangkat lunak.

•

Praktikan dapat mendokumentasikan hasil perancangan (SDD)

•

Praktikan dapat melakukan review dokumen rancangan.

3.2 TEORI 3.2.1 Perancangan Awal (Preliminary Design) 3.2.1.1 Perancangan Data Perancangan data adalah aktifitas pertama dari empat aktifitas perancangan selama proses rekayasa perangkat lunak. Pengaruh

arsitektur

kompleksitas

data

prosedural

pada

akan

struktur

berpengaruh

program juga

dan

terhadap

kualitas software. Aktifitas utama selama perancangan data adalah menyeleksi representasi logis dari objek data (struktur data) yang diidentifikasikan selama pendefinisian kebutuhan dan fase spesifikasi. Selain itu melakukan identifikasi modul program.

3.2.1.2 Perancangan Arsitektural Perancangan

arsitektural

bertujuan

untuk

mengembangkan sebuah struktur program yang modular dan menunjukan

hubungan

antar

modul.

Perancangan

ini

menyatukan struktur program dan struktur data, menentukan interface yang membaca data bisa mengalir disemua program. Modul Praktikum Rekayasa Perangkat Lunak 2013


3.2.1.2.1 Proses Perancangan Arsitektural Perancangan yang berorientasi aliran data adalah metode perancangan arsitektural yang mengijinkan transisi dari model analisis ke sebuah deskripsi perancangan dari struktur program. Transisi dari aliran informasi ke struktur dicapai sebagai bagian dari proses lima tahapan sebagai berikut : 1. Tipe aliran informasi telah ditetapkan. 2. Batasan aliran telah ditunjuk. 3. DFD dipetakan ke seluruh program. 4. Hirarki kendali didefiniskan oleh “factoring”. 5. Struktur gabungan diperbaiki dengan menggunakan ukuranukuran dan usaha-usaha perancangan.

Gambar 3.1 Contoh desain Arsitektural

3.2.2 Perancangan Rinci (Detail Design) 3.2.2.1 Perancangan Prosedur Idealnya

spesifikasi

prosedur

diperlukan

untuk

mendefinisikan algoritma yang rinci yang dinyatakan dalam bahasa sehari-hari. Perancangan prosedur harus memberikan prosedur yang menggunakan

rinci dan bahasa

tidak bermakna

sehari-hari,

kita

ganda. bisa

Dengan

menuliskan

sekelompok langkah-langkah prosedural dalam berbagai cara. Modul Praktikum Rekayasa Perangkat Lunak 2013


1. Pemrograman terstruktur Djikstra mengusulkan penggunaan sekumpulan konstruksi logika dimana suatu program bisa berbentuk, terdiri dari : -

Sequence/urutan

adalah

implementasi

dari

tahapan

pemrosesan yang merupakan bagian yang esensial dalam spesifikasi dari setiap algoritma. -

Kondisi,

memberikan

fasilitas

untuk

proses

pemilihan

berdasarkan beberapa kejadian logika. -

Pengulangan,

memberikan

kesempatan suatu

perintah

dijalankan berulang-ulang. Ketiga konstruksi di atas merupakan dasar dari pemrograman terstruktur yang merupakan teknik perancangan prosedur yang penting.

2. Notasi Perancangan dengan menggunakan grafik Notasi

Flowchart adalah salah satu notasi untuk perancangan

prosedur yang banyak digunakan. Tabel 3.1 Notasi Flowchart



Tabel 3.2 Notasi box Diagram/Nassi-Shneiderman Chart (N-S Chart)/Chapin Chart

3.

Bahasa

perancangan

program

(Program

Design

Language/PDL) PDL disebut juga Bahasa

Structured English or Pseudocode, sepintas

perancangan

program

ini

mirip

dengan

bahasa

pemrograman modern.

4. Notasi perancangan berbentuk tabel Dalam beberapa

software aplikasi, sebuah modul diinginkan

untuk mengevaluasi kombinasi komplek dari kondisi dan harus memilih aksi yang tepat berdasarkan kondisi tersebut. Tabel keputusan

(Decision

Table)

memberikan

notasi

yang

memindahkan aksi dan kondisi ke bentuk tabel. Tabel keputusan ini dibagi menjadi empat bagian, yaitu : - Bagian kiri atas mengandung daftar dari semua kondisi. -

Bagian kiri bawah berisi aksi yang muncul berdasarkan

kombinasi dari kondisi. - Bagian kanan adalah matriks yang menunjukan kombinasi aksi dan kondisi yang berkaitan, yang akan terjadi untuk kombinasi tertentu.

untuk

itu

setiap

kolom

dari

matrik

diinterprestasikan sebagai hukum (rule) pemrosesan.

Langkah-langkah untuk membuat tabel keputusan : Modul Praktikum Rekayasa Perangkat Lunak 2013

bisa


-

Daftarkanlah semua aksi yang berkaitan dengan prosedur khusus.

-

Buat daftar kondisi atau pengambilan keputusan selama eksekusi prosedur berlangsung.

-

Hubungkan

sekumpulan

kondisi

tertentu

dengan

aksi

tertentu, buanglah kombinasi yang tidak mungkin. -

Tentukan hukum/aturan dengan menunjukan aksi apa yang terjadi untuk sekumpulan kondisi tertentu.

3.2.3 (Lanjutan) Perancangan UML 3.2.3.1 Class diagram Class adalah sebuah spesifikasi yang jika diinstansiasi akan menghasilkan

sebuah

objek

dan

desain

pengembangan menggambarkan

keadaan

dan

merupakan

berorientasi

inti

objek.

(atribut/properti)

suatu

dari Class

sistem,

sekaligus menawarkan layanan untuk memanipulasi keadaan tersebut struktur

(metoda/fungsi). dan

deskripsi

Class

class,

diagram

package

menggambarkan

dan

objek

beserta

hubungan satu sama lain seperti containment , pewarisan, asosiasi, dan lain-lain. Class memiliki tiga area pokok : 1. Nama (dan stereotype) 2. Atribut 3. Metoda Atribut dan metoda dapat memiliki salah satu sifat berikut : •

Private, tidak dapat dipanggil dari luar class yang bersangkutan

•

Protected, hanya dapat dipanggil oleh class yang bersangkutan dan anak-anak yang mewarisinya

•

Public, dapat dipanggil oleh siapa saja

Class

dapat

merupakan

implementasi

dari

sebuah

interface, yaitu class abstrak yang hanya memiliki metoda. Modul Praktikum Rekayasa Perangkat Lunak 2013


Interface tidak dapat langsung diinstansiasikan, tetapi harus diimplementasikan

dahulu

menjadi

sebuah

class.

Dengan

demikian interface mendukung resolusi metoda pada saat runtime. Sesuai dengan perkembangan class model, class dapat dikelompokkan menjadi package. Kita juga dapat membuat diagram yang terdiri atas package. Hubungan Antar Class 1. Asosiasi, yaitu hubungan statis antar class. Umumnya menggambarkan class yang memiliki atribut berupa class lain, atau class yang harus mengetahui eksistensi class lain. Panah navigability menunjukkan arah query antar class. 2. Agregasi, yaitu hubungan yang menyatakan bagian (“terdiri atas..”). 3. Pewarisan, yaitu hubungan hirarkis antar class. Class dapat diturunkan dari class lain dan mewarisi semua atribut dan metoda class asalnya dan menambahkan fungsionalitas baru, sehingga ia disebut anak dari class yang

diwarisinya.

Kebalikan

dari

pewarisan

adalah

generalisasi. 4. Hubungan dinamis, yaitu rangkaian pesan (message) yang

di- passing

Hubungan

dari

dinamis

satu dapat

class

kepada

class

digambarkan

lain.

dengan

menggunakan sequence diagram yang akan dijelaskan kemudian.

Contoh Class Diagram :



Gambar 3.5 Contoh Class Diagram

3.2.3.2 Statechart Diagram Statechart

diagram

menggambarkan

transisi

dan

perubahan keadaan (dari satu state ke state lainnya) suatu objek pada sistem sebagai akibat dari stimuli yang diterima. Pada umumnya statechart diagram menggambarkan class tertentu (satu class dapat memiliki lebih dari satu statechart diagram). Dalam UML, state digambarkan berbentuk segiempat dengan sudut membulat dan memiliki nama sesuai kondisinya saat itu. Transisi antar state umumnya memiliki kondisi guard yang merupakan syarat terjadinya transisi yang bersangkutan, dituliskan dalam kurung siku. Action yang dilakukan sebagai akibat dari event tertentu dituliskan dengan diawali garis miring. Titik awal dan akhir digambarkan berbentuk lingkaran berwarna penuh dan berwarna setengah.

Contoh statechart diagram :



Gambar 3.6 Contoh Statechart Diagram



3.2.3.3 Activity Diagram Activity diagrams menggambarkan berbagai alir aktivitas dalam sistem yang sedang dirancang, bagaimana masing-masing alir berawal, decision yang mungkin terjadi, dan bagaimana mereka berakhir. Activity diagram juga dapat menggambarkan proses paralel yang mungkin terjadi pada beberapa eksekusi. Activity diagram merupakan state diagram khusus, di mana sebagian besar state adalah action dan sebagian besar transisi di trigger oleh selesainya state sebelumnya (internal processing).

Oleh

karena

itu

activity

diagram

tidak

menggambarkan behaviour internal sebuah sistem (dan interaksi antar subsistem) secara eksak, tetapi lebih menggambarkan proses-proses dan jalur-jalur aktivitas dari level atas secara umum. Sebuah aktivitas dapat direalisasikan oleh satu use case atau lebih. Aktivitas menggambarkan proses yang berjalan, sementara use case menggambarkan bagaimana aktor menggunakan sistem untuk melakukan aktivitas. Sama seperti state, standar UML menggunakan segiempat dengan sudut membulat untuk menggambarkan

aktivitas.

menggambarkan

behaviour

Decision pada

digunakan

kondisi

tertentu.

untuk Untuk

mengilustrasikan proses-proses paralel (fork dan join) digunakan titik sinkronisasi yang dapat berupa titik, garis horizontal atau vertikal. Activity diagram dapat dibagi menjadi beberapa object swimlane untuk menggambarkan objek mana yang bertanggung jawab untuk aktivitas tertentu.



Contoh activity diagram tanpa swimlane:

Gambar 3.7 Contoh Activity Diagram tanpa swimlane

3.2.3.4 Sequence Diagram Sequence diagram menggambarkan

interaksi

antar

objek di dalam dan di sekitar sistem (termasuk pengguna, display, dan sebagainya) berupa message yang digambarkan terhadap waktu. Sequence diagram terdiri atar dimensi vertikal (waktu) dan dimensi horizontal (objek-objek yang terkait). Sequence

diagram

biasa

digunakan

untuk

menggambarkan skenario atau rangkaian langkah-langkah Modul Praktikum Rekayasa Perangkat Lunak 2013


yang dilakukan sebagai respons dari sebuah event untuk menghasilkan output tertentu. Diawali dari apa yang mentrigger aktivitas tersebut, proses dan perubahan apa saja yang terjadi secara internal dan output apa yang dihasilkan. Masing-masing objek, termasuk aktor, memiliki lifeline vertikal. Message digambarkan sebagai garis berpanah dari satu objek ke objek lainnya. Pada fase desain berikutnya, message akan dipetakan menjadi operasi/metoda dari class. Activation bar menunjukkan lamanya eksekusi sebuah proses, biasanya diawali dengan diterimanya sebuah message. Untuk objek-objek yang memiliki sifat khusus, standar UML mendefinisikan icon khusus untuk objek boundary, controller dan persistent entity.



Berikut simbol-simbol pada sequence diagram :







Gambar 3.7 Sequence diagram 3.2.3.5 Collaboration Diagram Modul Praktikum Rekayasa Perangkat Lunak 2013


Collaboration

diagram

juga

menggambarkan

interaksi antar objek seperti sequence diagram, tetapi lebih menekankan pada peran masing-masing objek dan bukan pada

waktu

penyampaian

message.

Setiap

message

memiliki sequence number, di mana message dari level tertinggi memiliki nomor 1. Messages dari level yang sama memiliki prefiks yang sama. Berikut simbol-simbol pada collaboration diagram :



3.2.3.6 Component Diagram Component diagram menggambarkan struktur dan hubungan

antar

komponen

piranti

lunak,

termasuk

ketergantungan (dependency) di antaranya. Komponen piranti lunak adalah modul berisi code, baik berisi source code maupun binary code, baik library maupun executable, baik yang muncul pada compile time, link

time,

maupun

run

time.

Umumnya

komponen

terbentuk dari beberapa class dan/atau package, tapi dapat juga dari komponen-komponen yang lebih kecil. Komponen dapat juga berupa interface, yaitu kumpulan layanan

yang

disediakan

sebuah

komponen

untuk

komponen lain. Berikut simbol-simbol pada component diagram :



3.2.3.7 Deployment Diagram Deployment/physical diagram menggambarkan detail bagaimana komponen dideploy dalam infrastruktur sistem, di mana komponen akan terletak (pada mesin, server atau piranti keras apa), bagaimana kemampuan jaringan pada lokasi tersebut, spesifikasi server, dan hal-hal lain yang bersifat fisikal. Sebuah node adalah server, workstation, atau piranti keras lain yang digunakan untuk men-deployn komponen dalam lingkungan sebenarnya. Hubungan antar Modul Praktikum Rekayasa Perangkat Lunak 2013


node (misalnya

TCP/IP)

dan

requirement

dapat

juga

didefinisikan dalam diagram ini. Berikut simbol-simbol pada deployment diagram :



3.2.4 SDD (Software Design Document) SDD

adalah

hasil

akhir

SDDmerupakan penjelasan

hasil

dari

proses

perancangan.

proses perancangan

yang

termasuk didalamnya perbaikan hasil perancangan tersebut untuk

merepresentasikan

perangkat

lunak

yang

sedang

dibangun. Kerangka SDD adalah sebagai berikut : Tabel 3.4 Kerangka SDD Kerangka Dokumen Abstraksi

Keterangan Abstraksi/Rangkuman

Daftar Isi

(SDD) Daftar

Daftar Gambar

Daftar Tabel dalam SDD

Daftar Tabel 1 Pendahuluan 1.1 Tujuan SDD

Tujuan penyusunan dokumen SDD

Isi,

Daftar

dokumen

Gambar

dan

dan menentukan siapa yang akan menggunakan SDD Memberikan batasan

1.2 Ruang Lingkup SDD 1.3

Daftar

Definisi

dan

pembuatan

SDD Menjelaskan definisi dan singkatan

Singkatan 1.4 Overview SDD

dalam SDD Menjelaskan isi dan organisasi SDD

2

secara singkat Menjelaskan hardware,

Rancangan

Lingkungan

Implementasi

software,

basis data dst yang akan digunakan untuk implementasi

3 Perancangan Data 3.1 Daftar Tabel

Menjelaskan tabel-tabel yang akan digunakan (nama

3.2 Conceptual Data Model

oleh

tabel,

perangkat keras

primary

key,

dan

deksripsi tabel) Menjelaskan CDM atau E-R Diagram

(CDM) 3.3 Dekomposisi Fungsional

Menjelaskan

Modul

modul/proses

untuk tabel

dengan

suatu data

yang digunakan sebagai masukan dan keluaran untuk modul/proses Modul Praktikum Rekayasa Perangkat Lunak 2013


tersebut Menjelaskan

3.4 Tabel A

struktur

tabel

A

(Identifikasi tabel, dekripsi isi, jenis tabel, volume, laju, primary key, dst) Menjelaskan struktur tabel B…dst

3.5 Tabel B,… dst

(Identifikasi tabel, dekripsi isi, jenis tabel, volume, laju, primary key, dst) 4 Perancangan Arsitektural 4.1 Kajian data dan Aliran data

Mengindikasikan

bagaiman

arsitektur program didapatkan dari 4.2 Struktur Program yang Diperoleh

model analisis Menjelaskan

bagan

struktur

(representasi dari struktur program) yang

digunakan

menunjukkan

untuk

hirarki

modul

tersebut 5 Perancangan Prosedural 5.1 Deskripsi Antarmuka

Menjelaskan

5.2 Deskripsi Perancangan Bahasa 5.3

Modul-modul

yang

digunakan 5.4 Struktur Data Internal 5.5 Keterangan/Larangan/Batasan

antarmuka Menjelaskan

perancangan bahasa

yang

digunakan pada perancangan Menjelaskan modul-modul yang digunakan Menjelaskan struktur data internal Menjelaskan keterangan/larangan/batasan perancangan

6 Perancangan UML 6.1 Use case Diagram

Menggambarkan use case diagram

6.2 Class Diagram

dari rancangan menggunakan tools Menggambarkan class diagram dari

6.3 Statechart Diagram

rancangan menggunakan tools Menggambarkan statechart diagram

6.4 Activity Diagram

dari

rancangan

menggunakan tools Menggambarkan activity

diagram

dari rancangan menggunakan tools Modul Praktikum Rekayasa Perangkat Lunak 2013


6.5 Sequence Diagram

Menggambarkan sequence diagram

6.6 Collaboration Diagram

dari rancangan menggunakan tools Menggambarkan collaboration diagram

6.7 Component Diagram

menggunakan tools Menggambarkan diagram

6.8 Deployment Diagram

dari

menggunakan tools Menggambarkan diagram

Lampiran

dari

dari

rancangan component rancangan deployment rancangan

menggunakan tools Berisi penjelasan tambahan pada laporan ini


MODUL RPL

Recommend Documents