Analisis Kelayakan Sistem Absensi Berbasis RFID

Praktikum Rekayasa Perangkat Lunak
VI033112
Oleh:
Umi Sa’adah, S.Kom, M.Kom
NIP. 19740416.200003.2.003
Rizky Yuniar Hakkun, S.Kom., M.T.
NIP. 19810622.2008.12.1.003
Program Studi Teknik Informatika
Departemen Teknik Informatika dan Komputer
Politeknik Elektronika Negeri Surabaya
2012

KKAATTAA PPEENNGGAANNTTAARR
Dengan mengucapkan syukur Alhamdulillah kehadirat Allah SWT atas segala
limpahan rahmat dan hidayah-Nya, sehingga penyusun dapat menyelesaikan buku
modul praktikum yang berjudul : “Rekayasa Perangkat Lunak” dengan baik.
Buku modul praktikum ini disusun sebagai pedoman khususnya bagi mahasiswa
di Program Studi Teknik Informatika, Politeknik Elektronika Negeri Surabaya, dalam
memberikan pengalaman dalam melakukan setiap proses dalam membangun sebuah
perangkat lunak.
Bagimanapun penyusun telah berusaha membuat buku ini dengan sebaik-
baiknya, namun tidak ada kesempurnaan dalam sebuah karya manusia. Penyusun
menyadari masih banyak kekurangan dalam penyusunan buku ini. Untuk itu pula segala
masukan, kritik dan saran dari pembaca dapat menjadikan acuan bagi penyusun dalam
penyempurnaan dan pembuatan buku berikutnya.
Tiada untaian kata yang dapat penyusun sampaikan selain panjatkan doa,
semoga Allah SWT selalu membuka hati kita dengan cahaya-NYA dan mengajarkan
ilmu-NYA kepada kita, serta menghindarkan kita dari ilmu yang tidak bermanfaat.
Surabaya, Desember 2012
Penyusun

DDAAFFTTAARR IISSII
Kata Pengantar i
Daftar Isi ii
Bab 1 Pengenalan Proyek Perangkat Lunak 1
Bab 2 Studi Kelayakan Perangkat Lunak 5
Bab 3 Pendefinisian Proyek Perangkat Lunak 10
Bab 4 - 5 Request For Proposal 12
Bab 6 – 7 Formal Technical Review 14
Bab 8 Requirements Engineering 16
Bab 9 Analisis dan Pemodelan 10
Bab 10 Desain Sistem dan Antarmuka Perangkat Lunak 25
Bab 11 – 12 – 13 – 14 Pengembangan dan Intergrasi Perangkat Lunak 39
Bab 15 Uji dan Verifikasi Perangkat Lunak 46
Bab 16 Validasi Pengguna Perangkat Lunak 48
Daftar Pustaka

BBAABB 11
PPEENNGGEENNAALLAANN PPRROOYYEEKK
PPEERRAANNGGKKAATT LLUUNNAAKK
Pokok Bahasan:
· Pendahuluan
· Deskripsi Umum Perangkat Lunak
· Langkah-langkah Pengembangan Perangkat Lunak
· Pembentukan tim Proyek Pengembang
Tujuan Pembelajaran:
· Memahami tugas Rekayasa Perangkat Lunak
· Memahami tahap-tahap umum dalam proyek perangkat lunak
· Memahami tugas dalam tim pengembang perangkat lunak
Dasar Teori:
Perangkat lunak/software adalah program komputer beserta dengan berbagai
dokumentasi terkait seperti persyaratan/requirement, model desain dan manual
pengguna (user guide). Definisi resmi yang mengacu pada standard dari IEEE dan ISO
adalah sebagaimana terlihat dalam Gambar 1.1
Sedangkan Rekayasa Perangkat Lunak atau Software Engineering adalah suatu
disiplin ilmu yang membahas semua aspek produksi perangkat lunak, mulai dari tahap
awal requirement capturing (analisa kebutuhan pengguna), specification (menentukan
spesifikasi dari kebutuhan pengguna), desain, coding, testing sampai pemeliharaan
sistem setelah digunakan. (Romi Satria Wahono berdasar pendapat Ian Sommerville)

Gambar 1.1 Definisi Software versi IEEE dan ISO
Software Process
Software process adalah satu set kegiatan/aktivitas yang tujuannya adalah
pengembangan atau evolusi perangkat lunak, seringkali disebut sebagai Siklus Hidup
Pengembangan Perangkat Lunak/Software Development Life Cycle (SDLC). SDLC
secara garis besar tampak dalam Gambar 2.
Gambar 2 Siklus Hidup Pengembangan Perangkat Lunak
Penjelasan dari masing-masing fase di atas adalah sebagai berikut
1. Planning/Perencanaan : Why build the system?
• Mengidentifkasi nilai bisnis (business value), analisis kelayakan
(feasibility analysis) à System Request/Proposal

2. Analysis: Who, what, when, where will the system be?
• Pengumpulan kebutuhan pengguna (User Requirement Gathering) à
System Specification
3. Design: How will the system work?
• Desain arsitektur, desain antar muka, desain data, desain program à
System Design
4. Implementation: System delivery
• Konstruksi sistem, pengujian/testing, instalasi dan perawatan/
maintenance à New System
Fase PLANNING
1. Mengidentifikasi nilai bisnis/business value
• Biaya yang lebih rendah
• Keuntungan yang lebih tinggi
2. Analisis Kelayakan
• Kelayakan secara teknis
• Kelayakan secara ekonomis
• Kelayakan secara organisasi
3. Menyusun rencana kerja
4. Menyusun SDM yang terlibat dalam proyek (staff the project)
Fase ANALYSIS
1. Pengumpulan kebutuhan user dengan menjawab pertanyaan-pertanyaan berikut:
• Siapa yang akan menggunakan sistem?
• Apa yang akan sistem lakukan?
• Kapan itu digunakan?
2. Selidiki sistem saat ini
3. Mengidentifikasi perbaikan mungkin
4. Mengembangkan konsep sistem baru
5. Investigate the current system
6. Identify possible improvements
7. Develop a concept for new system

Tugas Pendahuluan:
Pada prinsipnya perangkat lunak dibuat dalam rangka menyelesaikan suatu masalah
praktis dalam kehidupan manusia.
1. Lakukan curah pendapat (brain storming) untuk sebanyak mungkin
memunculkan ide permasalahan/studi kasus yang akan dibuatkan solusi
perangkat lunaknya.
2. Dari masing-masing ide tersebut, buat draft tentang latar belakang dan
permasalahan dari diangkatnya ide tersebut sekaligus solusi dari perangkat lunak
yang akan dibuat.
Percobaan:
Lakukan diskusi dengan sesama anggota tim untuk:
1. Menyusun daftar sekaligus prioritasnya dari ide yang berpotensi untuk diangkat
menjadi studi kasus.
2. Merumuskan detil latar belakang dan permasalahan dari masing-masing ide
tersebut sekaligus solusi yang dari perangkat lunak yang akan dibuat
Laporan Resmi:
Dari hasil diskusi yang dilakukan, susun laporan resmi berupa kumpulan ide studi kasus
beserta detil :
1. Judul Aplikasi
2. Latar belakang
3. Permasalahan
4. Solusi

BBAABB 22
SSTTUUDDII KKEELLAAYYAAKKAANN
Pokok Bahasan:
· Memilih studi kasus proyek perangkat lunak
· Analisis kelayakan studi kasus yang dipilih
· Mampu mendefinisikan studi kasus dari permasalahan dunia nyata
· Mampu melakukan analisis kelayakan dari studi kasus yang dipilih
Dasar Teori:
Studi kelayakan merupakan suatu kebutuhan tentang ketersediaan dan
persediaan akan keunggulan dan kelemahan suatu sistem. Studi kelayakan dilakukan
dengan survey yang menghasilkan dokumen-dokumen kebutuhan. Berdasarkan
dokumen kebutuhan dan studi kelayakan, dapat disusun persyaratan perangkat lunak
Studi kelayakan berguna untuk memastikan bahwa solusi yang diusulkan tersebut
benar-benar dapat dicapai dengan sumber daya dan dengan memperhatikan kendala
yang terdapat pada perusahaan serta dampak terhadap lingkungan sekeliling
Analis sistem melaksanakan penyelidikan awal terhadap masalah dan peluang bisnis
yang disajikan dalam usulan proyek pengembangan sistem.
Tugas-tugas yang tercakup dalam studi kelayakan meliputi:
· Penentuan masalah dan peluang yang dituju sistem

· Pembentukan sasaran sistem baru secara keseluruhan
· Pengidentifikasian para pemakai sistem
· Pembentukan lingkup sistem
Sistem analis juga melakukan tugas-tugas seperti berikut:
· Pengusulan perangkat lunak dan perangkat keras untuk sistem baru
· Pembuatan analisis untuk membuat atau membeli aplikasi
· Pembuatan analisis biaya/manfaat
· Pengkajian terhadap risiko proyek
· Pemberian rekomendasi untuk meneruskan atau menghentikan proyek
Contoh Studi Kelayakan
Pembuatan mesin absensi menggunakan RF ID mempunyai kelebihan:
· Transaksi absensi pegawai menjadi otomatis tersimpan di database tanpa
prosedur yang rumit.
· Penempatan counter absensi tidak harus terpusat
· Menghindari kesalahan ketik saat update data karena, data absensi tidak diisi
manual tetapi bersifat otomatis
· Penghematan waktu dan tenaga di bagian kepegawaian
Adapun kelemahannya adalah:
· Biaya pengembangan cukup besar, karena harus menyediakan komputer sebagai
server database, program aplikasi dan beberapa mesin counter. Pada mesin
absensi biasa tidak diperlukan biaya tinggi.
· Keamanan data perlu dipertimbangkan lebih jauh
Pertimbangkan mana yang lebih menguntungkan
Survey
Survey dapat dilakukan dengan wawancara, kuisioner, atau pengamatan untuk
mendapatkan gambaran lebih jelas mengenai sistem administrasi yang berlaku.

Hasil survey adalah:
· model dan bentuk laporan yang diharapkan,
· data-data apa yang sudah tersedia dan yang harus disediakan
· Sistem konversi bila sudah ada perangkat lunak yang lama
Tujuan Studi Kelayakan
1. Memahami proses bisnis pada sistem yang lama
· Flowchart dari sistem
· Struktur Organisasi
· Deskripsi Tugas dan Jabatan
· Salinan laporan-laporan
· Kode-kode yang dipakai didalam sistem
2. Menentukan kebutuhan pemakai sistem secara garis besar untuk dapat mencapai
sasaran sistem
· Wawancara ke pemakai sistem
· Observasi data
· Pengambilan sampel
3. Menentukan permasalahan yang terjadi pada sistem yang lama yang menyebabkan
belum dapat mencapai sasarannya.
Hasil Studi Kelayakan harus bisa menjawab pertanyaan-pertanyaan :
· Apa yang dikerjakan oleh sistem lama?
· Apa yang harus dihasilkan oleh sistem yang baru untuk mencapai sasarannya ?
· Apa permasalahan yang harus dipecahkan oleh sistem baru ?
· Bagaimana hasil penilaian kelayakan teknis, ekonomi, hukum, operasi, dan
jadwal.
Hasil dari studi kelayakan akan menentukan proyek dilanjutkan atau dihentikan. Hasil
studi kelayakan akan didokumentasikan terpisah dan dilampirkanpadadokumenspesifikasi
system. Berikutoutlinedokumenstudikelayakan

Ukuran Studi Kelayakan
Aspek Pertimbangan
Teknologi Apakah sistem dapat dikembangkan dan dioperasikan dengan
teknologi yang tersedia?
Ekonomi Apakah manfaat sistem lebih besar daripada biaya yang
dikeluarkan (termasuk untuk memenuhi kebutuhan personil)?
Non-ekonomi Apakah sistem yang diusulkan memiliki keuntungan yang tak
dapat diukur dengan uang
Organisasi atau
Operasional
Apakah sistem yang diusulkan bisa cocok dengan budaya
organisasi?
Apakah level keahlian yang digunakan dalam sistem baru
sesuai dengan pegawai yang akan mengoperasikannya?
Jadwal Mungkinkah menerapkan sistem tersebut sesuai dengan jadwal
yang telah ditetapkan?
Kendala hukum,
etika, dan yang lain
Apakah sistem yang diusulkan tidak bertentangan dengan etika
atau hukum?
Apakah terdapat kendala-kendala yang berbahaya yang
dilanggar?
Tugas Pendahuluan:
Dari beberapa ide studi kasus dalam laporan resmi praktikum 1, lakukan analisis
studi kelayakan untuk masing-masing

Percobaan:
1.Lakukan diskusi dengan sesama anggota tim untuk
a. Memberikan rekomendasi mengenai solusi dari studi kasus yang dipilih.
b. Mendefinisikan pengaruh dari rekomendasi pada studi kasus
c. Mencari alternative – alternative yang mungkin.
d. Analisa resiko, biaya dan keuntungan.
2. Konsultasikan dengan dosen hasil studi kelayakan yang sudah dilakukan untuk
menentukan 1 studi kasus yang feasible untuk dijadikan proyek perangkat lunak
Laporan Resmi:
Dari hasil diskusi yang dilakukan, susun laporan resmi berupa dokumen studi
kelayakan untuk studi kasus terpilih

BBAABB 33
PPEENNDDEEFFIINNIISSIIAANN PPRROOYYEEKK
Pokok Bahasan:
· Dokumentasi dan Visualisasi Studi Kasus Proyek Perangkat Lunak
· Mampu merancang skenario, memvisualisasikan sekaligus mendefinisikan proyek
perangkat lunak dari studi kasus yang dipilih
Dasar Teori:
Skenario
• Skenario adalah sebuah cerita yang mudah diakses atau sebuah narasi untuk
membuat sebuah aplikasi menjadi hidup
• Fungsi penting dari cerita ini adalah untuk memungkinkan terjadinya diskusi
yang spesifik (terukur, relevan dan eksplisit) di antara pihak-pihak yang
berkepentingan.
• Fungsi utama dari skenario adalah untuk membuat peluang atau masalah bisa
diakses dan dimengerti bagi semua pihak yang berkepentingan
• Tujuan utama dari scenario adalah untuk mempelajari, mendefinisikan serta
menganalisa produk atau fitur baru dari proyek perangkat lunak yang akan
dibuat.

Tugas Pendahuluan:
Dari hasil Studi Kelayakan Perangkat Lunak yang telah dilaksanakan, lakukan
Pendefinisian Proyek yang akan dibuatkan perangkat lunaknya.
1. Buatlah rancangan skenario dari perangkat lunak yang akan dibuat. Alur
scenario didasarkan kepada detil dari isi power point hasil praktikum
sebelumnya
2. Buatlah visualisasi dari skenario tersebut dalam salah satu bentuk di bawah ini:
- film
- animasi flash
Percobaan:
Lakukan konsultasi dan revisi terhadap konten materi yang telah divisualisasikan
Laporan Resmi:
Dari hasil konsultasi dan revisi yang dilakukan, susun laporan resmi berupa
Visualisasi skenario Perangkat Lunak yang akan dijadikan sebagai sarana untuk Request
for Proposal

BBAABB 44--55
RREEQQUUEESSTT FFOORR PPRROOPPOOSSAALL
Pokok Bahasan:
· Penawaran kontrak proyek sistem informasi
· Kontrak dengan developer
Mampu menjabarkan dan menvisualisasikan permasalahan pada studi kasus
Dasar Teori:
Request for proposal (RFP) adalah suatu penawaran, yang biasanya melalui
proses tender, oleh suatu lembaga atau perusahaan yang tertarik dalam pengadaan
barang atau jasa, kepada pemasok potensial untuk mengajukan proposal bisnisnya. Hal
ini dilakukan pada awal siklus pengadaan, baik pada studi pendahuluan atau pada tahap
pengadaan. Proses RFP membawa struktur keputusan pengadaan dan dimaksudkan
untuk medefinisikan risiko dan manfaat dengan jelas di depan.
Pada dasarnya, RFP :
- Menginformasikan kepada supplier bahwa lembaga tersebut mencari penawaran
terbaik
- Menginformasikan kebutuhan barang dan jasa apa yang diinginkan perusahaan
- Menginformasikan kepada supplier bahwa proses seleksi berlangsung secara
kompertitif
Dokumen dari suatu RFP berisi :
- Latar Belakang Perusahaan
- Deskripsi Proyek
- Kebutuhan Design

- Kebutuhan Teknis dan Infrastruktur
- Kebutuhan Fungsional
- Estimasi Lama Proyek
- Asumsi dan Persetujuan
Tugas Pendahuluan:
1. Mempersiapkan presentasi berisi visualisasi proyek yang akan ditenderkan
2. Mempelajari template dokumen RFP
Percobaan:
1. Mempresentasikan RFP dari proyek yang akan ditenderkan.
2. Menyiapkan dokumen RFP.
Laporan Resmi:
Membuat dokumen RFP dari proyek yang ditenderkan menggunakan template
yang disediakan.

BBAABB 66 -- 77
FFOORRMMAALL TTEECCHHNNIICCAALL RREEVVIIEEWW
Pokok Bahasan:
· Pembuatan proposal proyek perangkat lunak
· Review Kontrak
· Mampu membuat proposal penawaran proyek Perangkat Lunak
· Mampu mempresentasikan proposal penawaran Perangkat Lunak
Dasar Teori:
Perangkat lunak/software adalah program komputer beserta dengan berbagai
dokumentasi terkait seperti persyaratan/requirement, model desain dan manual Develop
a concept for new system
Tugas Pendahuluan:
Dari penawaran kontrak proyek yang diberikan pelanggan, susunlah proposal
penawaran yang terdiri atas 2 bagian.
· Bagian 1 :
- Latar belakang
- Tujuan dan Manfaat
- Permasalahan
- Batasan masalah

· Bagian 2 :
- Deskripsi Sistem
- Skema umum sistem à Fitur-fitur sistem dan deskripsinya
- Teknologi yang digunakan
- Rancangan (awal) antar muka
Percobaan:
1. Presentasikan proposal penawaran Perangkat Lunak yang telah dibuat.
2. Lakukan diskusi dan review dengan pelanggan terhadap penawaran Perangkat
Lunak yang diberikan
3. Lakukan konsultasi dan review terhadap proposal penawaran
Laporan Resmi:
Dari hasil presentasi, diskusi, konsultasi dan review yang dilakukan, susun laporan
resmi berupa proposal penawaran versi final yang terdiri atas 2 bagian, yaitu :
· Bagian 1 :
- Latar belakang
- Tujuan dan Manfaat
- Permasalahan
- Batasan masalah
· Bagian 2 :
- Deskripsi Sistem
- Skema umum sistem à Fitur-fitur sistem dan deskripsinya
- Teknologi yang digunakan
- Rancangan (awal) antar muka

BBAABB 88
RREEKKAAYYAASSAA KKEEBBUUTTUUHHAANN
((RREEQQUUIIRREEMMEENNTT EENNGGIINNEEEERRIINNGG))
Pokok Bahasan:
· Elisitasi Kebutuhan Perangkat Lunak
· Spesifikasi Kebutuhan Perangkat Lunak
· Verifikasi dan Validasi Kebutuhan Perangkat Lunak
· Pembuatan dokumen Spesifikasi Kebutuhan Perangkat Lunak (SKPL)
· Fuctional Requirement dan Non Functional Requirement
· Mampu melakukan proses Elisitasi Kebutuhan Perangkat Lunak
· Mampu menyusun dokumen Spesifikasi Kebutuhan Perangkat Lunak
· Mampu menyusun Fuctional Requierement dan Non Functional Requirement
Dasar Teori:
Requirements engineering adalah fase terdepan dari proses rekayasa perangkat
lunak, di mana software requirements (kebutuhan) dari user (pengguna) dan customer
(pelanggan) dikumpulkan, dipahami dan ditetapkan. Para pakar software engineering
sepakat bahwa requirements engineering adalah suatu pekerjaan yang sangat penting.
Fakta membuktikan bahwa kebanyakan kegagalan pengembangan software disebabkan
karena adaya ketidakkonsistenan (inconsistent), ketidaklengkapan (incomplete), maupun
ketidakbenaran (incorrect) dari requirements specification (spesifikasi kebutuhan).

Banyak definisi yang diungkapkan oleh para peneliti tentang requirements
engineering. Satu definisi yang cukup jelas dan diterima secara umum adalah yang
diuraikan oleh Pamela Zave [Zave-97]:
Requirements engineering adalah cabang dari software engineering yang
mengurusi masalah yang berhubungan dengan: tujuan (dunia nyata), fungsi, dan
batasan-batasan pada sistem software. Termasuk hubungan faktor-faktor tersebut
dalam menetapkan spesifikasi yang tepat dari suatu software, proses evolusinya
baik berhubungan dengan masalah waktu maupun dengan software lain (dalam
satu famili).
Studi di The Standish Group mencatat bahwa prosentase akumulatif kegagalan
sebuah proyek pengembangan software sebagian besar disebabkan oleh masalah
requirements dan spesifikasinya [Standish-94].
Untuk merangkum masalah yang ingin dipecahkan dalam cabang ilmu
requirements engineering, kebanyakan pakar mengamini ungkapan Ed Yourdon dalam
foreword yang ditulisnya untuk buku Managing Software Requirements – A Unified
Approach karya Dean Leffingwell [Leffingwell-00]. Ed Yourdon menggunakan istilah
“the rock problem” (masalah batu) sebagai diskusi dasar masalah yang selalu muncul
dalam proses pengerjaan proyek software.
Customer (pelanggan) yang datang kepada kita untuk mengerjakan sebuah proyek
pengembangan software, adalah ibarat seseorang yang mengatakan kepada kita,
“Tolong buatkan saya batu”. Ketika kita memberikan kepadanya sebuah batu, dia
akan melihatnya sebentar dan mengatakan kepada kita, “Ya terima kasih, tapi
sebenarnya yang saya inginkan adalah sebuah batu kecil berwarna biru”. Dan
ketika kita bawakan untuknya batu kecil berwarna biru, dia mengatakan bahwa
yang diinginkan adalah yang “bentuknya bulat”. Demikian seterusnya proses
iterasi (iteration) terjadi berulangkali sampai akhirnya kita dapatkan yang
sebenarnya diinginkan customer kita adalah “batu pualam kecil berwarna biru”.
Meskipun mungkin sebenarnya bukan “tepat yang diinginkan”, tapi paling tidak
“paling dekat” dengan yang diinginkan customer. Dan mungkin saja terjadi,
customer kita mengubah pikiran tentang requirements pada saat proses interaksi

dengan pengembang terjadi (dari iterasi pertama yang sekedar batu, sampai iterasi
terakhir yang menghasilkan batu pualam kecil berwarna biru).
Hasil dari fase requirements engineering terdokumentasi dalam SRS (software
requirements specificatio) atau SKPL (spesifikasi kebutuhan perangkat lunak). SKPL
berisi kesepakatan bersama tentang permasalahan yang ingin dipecahkan antara
pengembang dan customer, dan merupakan titik start menuju proses berikutnya yaitu
software design.
Sistemisasi proses negosiasi pengembang dan customer dalam requirements
engineering dibagi dalam 3 proses besar yaitu: elicitation, specification, validation and
verification. Formula ini kemudian juga dikenal dengan nama The Three Dimensions
of Requirements Engineering. Proses requirements engineering ini dilakukan secara
iterasi dengan mengakomodasi adanya feedback dari customer (user). Selengkapnya
adalah sebagai berikut :
1. Requirements Elicitation
Adalah proses mengumpulkan dan memahami requirements dari user. Kadang
masalah yang muncul berakar dari gap masalah knowledge domain (perbedaan disiplin
ilmu yang dimiliki). Customer adalah expert pada domain yang softwarenya ingin
dikembangkan (domain specialist), dilain pihak sang pengembang (requirements
analyst) adakalanya sama sekali buta terhadap knowledge domain tersebut, meskipun
tentu memahami dengan benar bagaimana sebuah software harus dikembangkan. Gap

knowledge domain tersebut yang diharapkan bisa diatasi dengan adanya interaksi terus
menerus dan berulang (iterasi) antara pengembang dan customer. Proses interaksi
tersebut kemudian dimodelkan menjadi beberapa teknik dan metodologi diantaranya
adalah interviewing, brainstorming, prototyping, use case, dsb.
2. Requirements Specification
Setelah masalah berhasil dipahami, pengembang mendeskripsikannya dalam
bentuk dokumen spesifikasi dokumen. Spesifikasi ini berisi tentang fitur dan fungsi
yang diinginkan oleh customer, dan sama sekali tidak membahas bagaimana metode
pengembangannya.
3. Requirements Validation and Verification
Setelah spesifikasi requirements berhasil dibuat, perlu dilakukan dua usaha:
Validation (validasi), yaitu proses untuk memastikan bahwa requirements yang benar
sudah ditulis. Verification (verifikasi), yaitu proses untuk memastikan bahwa
requirements sudah ditulis dengan benar. Proses validasi dan verifikasi ini melibatkan
customer (user) sebagai pihak yang menilai dan memberi feedback berhubungan dengan
requirements.
Tipe Requirements
Kebutuhan (requirements) perangkat lunak seringkali diklasifikasikan ke dalam
dua kategori :
1. Functional Requirements
Merupakan pernyataan tentang sekumpulan layanan/fitur yang harus tersedia
dalam perangkat lunak
2. Non Functional Requirements
Terkait dengan kendala (constraint) dan kualitas dari perangkat lunak. Kualitas
perangkat lunak adalah sifat atau karakteristik dari sistem yang stakeholders peduli dan
karenanya akan mempengaruhi tingkat kepuasan mereka dengan sistem

Tabel Ringkasan Kebutuhan Non Fungsional
SKPL-Id Keterangan
SKPL-NF001 Availability – Ketersediaan Aplikasi Untuk Dapat Diakses Oleh
Pengguna.
SKPL-NF002 Reliability – kehandalan aplikasi, termasuk aspek teknis seperti
koneksi, kebutuhan hardware.
SKPL-NF003 Ergonomy – Desain Aplikasi harus disesuaikan dengan kenyamanan
pengguna.
SKPL-NF004 Portability – Keberpindahan Aplikasi, sehingga dapat diakses oleh
berbagai device.
SKPL-NF005 Memory – Kebutuhan Aplikasi akan media penyimpanan.
SKPL-NF006 Response time – Waktu Aplikasi untuk merespon request dari user.
SKPL-NF007 Safety – Keamanan data dari aplikasi, serta penggunaan aplikasi.
SKPL-NF008 Security – Keamanan aplikasi untuk melindungi data di dalamnya.
SKPL-NF009 Bahasa komunikasi – Media Bahasa yang digunakan oleh aplikasi.
Tugas Pendahuluan:
1. Temukan the real customer (pelanggan yang sesungguhnya) dari aplikasi yang
akan dibangun
2. Tentukan target-target yang hendak dicapai dalam proses requirements
engineering yang akan dilakukan
3. Kembangkan wawasan tentang aplikasi lain yang relevan dengan aplikasi yang
akan dibangun
4. Lakukan pendefinisian kebutuhan awal dari aplikasi yang akan dibangun, yang
akan dikembangkan melalui proses elisitasi
Percobaan:
1. Lakukan proses elisitasi terhadap customer (pelanggan) untuk mengumpulkan,
memahami dan menetapkan kebutuhan dari pelanggan.
2. Klasifikasikan daftar kebutuhan pelanggan ke dalam kategori functional
requirements dan non functional requirements
3. Berikan deskripsi dari masing-masing kebutuhan tersebut

4. Lakukan proses verifikasi dan validasi kepada pelanggan terhadap spesifikasi
kebutuhan yang telah disusun
Laporan Resmi:
Dari hasil elisitasi dengan customer, susun laporan berbentuk tabulasi dengan
kolom-kolom sbb :
· No
· Nama
· Kode
· Deskripsi
· Prioritas
Fungsional Requirement (pada aplikasi e-Futsal)
No Nama Kode Deskripsi Prioritas
1 Pilih daerah yang
diinginkan
FR-01 Pilihan berupa menu, yaitu Surabaya
Pusat, Surabaya Timur, Surabaya Barat,
Surabaya Utara, dan Surabaya Selatan
High
2 Menampilkan output
berupa tempat futsal
pada daerah tersebut
FR-02 Output berupa list nama tempat futsal,
alamat, dan icon (tampak dari depan
gedung futsal). Contoh:
High
dari tempat futsal
yang dipilih
FR-03 Output berupa informasi mengenai
deskripsi singkat, tarif sewa, hari dan
jam buka, contact person, foto dan
deskripsi dari fasilitas yang ada pada
lapangan futsal, pilihan menu lihat
jadwal, dan lihat peta.
High
4 Menampilkan jadwal
sewa lapangan
FR-04 Output berupa tabel, lapangan1,
lapangan 2, dst, dilengkapi informasi
jam dan status (booked / free). Contoh:
Lapangan 1 Lapangan 2
08.00-10.00 booked 08.00-10.00 free
High
Kebraon Sport Center (KSC)
Jl. Kebraon II / 31 Surabaya

5 Menampilkan agenda
dari semua lapangan
futsal
FR-05 Output mengenai deskripsi dari agenda
yang ada di seluruh lokasi lapangan.
High
6 Admin lapangan
dapat melakukan
login
FR-06 Admin melakukan login dengan
menginputkan username dan password.
High
7 Admin dapat
mengupdate jadwal
lapangan, agenda, dan
informasi umum
FR-07 Diberikan template (space) untuk admin
agar dapat mengisi konten.
High
8 Pemilik futsal dapat
melakukan register
untuk menjadi admin
FR-08 Mengisi informasi umum, seperti nama,
email, username dan password,
kemudian email konfirmasi akan
dikirimkan ke email pendaftar.
High
9 Fasilitas untuk
menghubungi super
admin
FR-09 Diberikan text box untuk mengisi pesan
dan mengirimkan ke email super admin.
Medium
berupa peta lokasi
FR-10 Output berupa peta yang telah
tersimpan dalam database.
Medium
11 Memberikan
penilaian untuk
tempat futsal
FR-11 Penilaian berupa bintang 1 (terendah)
sampai 5 (tertinggi) untuk fasilitas dan
pelayanan lapangan futsal tersebut.
Medium
1
2
Memberikan review
untuk tempat futsal
FR-12 Diberikan text box untuk memberi
komentar bagi lapangan futsal tersebut.
Medium
Non Funcional Requirement (pada aplikasi e-Futsal)
No Parameter Kode Kebutuhan Prioritas
1 Interface NFR-01 Aplikasi yang dibangun memiliki
desain yang user friendly, sehingga
memudahkan pengguna. Penggunaan
warna juga perlu diperhatikan untuk
keserasian website.
High
2 Availability NFR-02 Aplikasi harus dapat beroperasi
selama 7 hari per minggu, 24 jam per
hari tanpa henti, karena e-Futsal
berbasis web sehingga akan diakses
dimanapun dan kapanpun.
High
3 Bahasa
Komunikasi
NFR-03 Bahasa komunikasi yang digunakan
adalah bahasa Indonesia.
High
4 Security NFR-04 Batas admin salah menginputkan
password adalah 3 kali. Setelah itu
High

admin perlu me-reset password
dengan mengirimkan email ke super
admin, sehingga password dapat di-set
ulang.
5 Portability NFR-05 Aplikasi ini dapat diakses di mana saja
selama pengguna terhubung dengan
internet.
High
6 Response Time NFR-06 Dapat diakses kurang dari 10 detik
pada kecepatan akses internet
100Kbps.
Medium
Contoh lain untuk Non Functional Requirements:
SKPL-Id Parameter Kebutuhan
SKPL-NF1 Availability
Aplikasi ini harus dapat beroperasi terus
menerus selama 7 hari per minggu, 24 jam
per hari tanpa berhenti, karena aplikasi ini
akan bersifat web-based dan akan diakses
oleh orang yang membutuhkan dari
berbagai tempat pada waktu yang berbeda-
beda.
SKPL-NF2 Reliability Aplikasi ini harus dibangun dengan
kehandalan yang setinggi mungkin
meskipun tidak perlu setinggi kehandalan
sebuah critical application. Kegagalan yang
dapat ditoleransi kurang lebih 10%. Dengan
kahandalan yang tinggi diharapkan aplikasi
ini dapat digunakan dengan baik pada saat
dibutuhkan.
SKPL-NF3 Portability Aplikasi ini bisa diakses di mana saja di
lingkungan ITS dengan menggunakan
intranet.
SKPL-NF4 Security Aplikasi membutuhkan security untuk
mengamankan account.
SKPL-NF5 Maintainability Aplikasi harus dapat di-maintain dengan
mudah oleh administrator.
SKPL-NF6 Documentation Dokumentasi yang berhubungan dengan
aplikasi harus jelas dan dapat dilacak
sehingga pengembangan di masa mendatang
dapat dilakukan dengan mudah.
SKPL-NF7 Interface Aplikasi yang dibuat harus memiliki
antarmuka yang bersifat user friendly
SKPL-N03 Ergonomy Aplikasi ini harus memiliki nilai ergonomi/
kenyamanan dipakai yang tinggi bagi user.

SKPL-Id Parameter Kebutuhan
Aplikasi akan dibangun dengan antarmuka
user yang mudah dimengerti, indah dilihat,
konsisten, mudah dioperasikan dan tidak
membingungkan.
SKPL-N04 Portability Aplikasi ini dapat diakses dari manapun
selama ada jaringan intenet.
Memory 100 megabyte space pada storage disk.
Besarnya memori yang dibutuhkan untuk
menjalankan aplikasi sebesar 256Mb.
SKPL-N05 Response time Kecepatan Central Processing dan jalur
komunikasi dapat untuk 30 on-line user
secara simultan. Waktu response 1 detik
untuk data entry dan query
SKPL-N06 Security Ada pengaturan hak akses agar aman.
informasi yang diproses harus terjamin
aman. data pribadi aman. tempat
penyimpanan data fisikal aman
SKPL-N07 Bahasa
komunikasi
Bahasa komunikasi pada user interface
menggunakan bahasa Indonesia.
SKPL-N08 Lain-lain

BBAABB99
AANNAALLIISSIISS DDAANN PPEEMMOODDEELLAANN
Pokok Bahasan:
· Rancangan Entity Relational Diagram (ERD)
· Rancangan Data Flow Diagram (DFD)
· Rancangan Use Case Diagram (UCD)
· Mampu merepresentasikan rancangan model ERD
· Mampu merepresentasikan rancangan model DFD
· Mampu merepresentasikan rancangan model UCD
Dasar Teori:
I. ERD - Entity Relationship Diagram
Komponen ERD
1. Entitas (Entity)
2. Relasi (Relationship)
3. Atribut (Attribute)
4. Kardinalitas (Kardinality)
5. Modalitas (Modality)
1. Entitas
· Definisi : Sebuah barang atau obyek yang dapat dibedakan dari obyek lain

· Simbol :
· Contoh
- Individu : pegawai,pelanggan, mahasiswa,distributor.
- Tempat : ruang,bangunan,kantor,lapangan,kampus.
- Obyek: buku,motor,paket software,produk
- Peristiwa: pendaftaran,pemesanan, penagihan
- Konsep : rekening,kualifikasi.
Contoh Entitas
Bangunan
Pelanggan Produk
2. Relasi
· Definisi : Asosiasi 2 atau lebib entitas
· Berupa kata kerja
· Simbol :
· Contoh :
3. Atribut
· Definisi : Properti yang dimiliki setiap entitas yang akan disimpan datanya.
· Contoh
Atribut Pelanggan

- No KTP/SIM
- Nama
- Alamat
4. Kardinalitas Relasi
· Definisi : Angka yang menunjukkan banyaknya kemunculan suatu obyek terkait
dengan kemunculan obyek lain pada suatu relasi
· Kombinasi yang mungkin : (1:1, 1:N, M:N)
· Contoh :
5. Modalitas Relasi
· Definisi : Partisipasi sebuah entitas pada suatu relasi
- 0 jika partisipasi bersifat “optional”/parsial
- 1 jika partisipasi bersifat “wajib”/total
· Contoh
- Partisipasi total : Setiap anak memiliki ibu
- Partisipasi parsial : Tidak setiap perempuan memiliki anak

Setiap departemen setidaknya harus memiliki seorang pegawai.
Seorang pegawai yang tidak harus termasuk dalam departemen
Sebuah Departemen menunjukkan modalitas parsial.
Entitas Lemah/Kuat
· Entitas Kuat : Entitas yang memiliki atribut kunci (Key)
· Entitas Lemah : Entitas yang biasanya berasal dari atribut multivalue pada
entitas lain.
II. DFD – Data Flow Diagram
DFD merupakan alat perancangan sistem yang berorientasi pada alur
data dgn konsep dekomposisi dapat digunakan untuk penggambaran analisa
maupun rancangan sistem yg mudah dikomunikasikan oleh profesional sistem
kepada pemakai maupun pembuat program.
KOMPONEN DFD
· Menurut Yourdan dan DeMarco
Terminator Proses Data Store Alur Data

· Menurut Gene dan Serson
Terminator Proses Data Store Alur Data
Keterangan :
1. Terminator/Entitas Luar
Adalah Entitas diluar sistem yang berkomunikasi / berhubungan langsung
dengan sistem.
Terdapat 2 jenis Terminator :
a. Terminator Sumber : Merupakan Terminator yang menjadi sumber
b. Terminator Tujuan : Merupakan Terminator yang menjadi tujuan
data/ informasi sistem.
Terminator Sumber Terminator Tujuan Terminator Tujuan & Sumber
Terminator dapat berupa orang, sekelompok orang, organisasi, perusahaan/
departemen yang berada di luar sistem yang akan dibuat, diberi nama yang
berhubungan dengan sistem tersebut dan biasanya menggunakan kata benda.
Contoh : Dosen, Mahasiswa.
Hal yang perlu diperhatikan tentang terminator :
a. Alur data yang menghubungkan terminator dengan sistem, menunjukkan
hubungan sistem dengan dunia luar.
b. Profesional sistem tidak dapat mengubah isi/cara kerja, prosedur yang
berkaitan dengan Terminator.
c. Hubungan yang ada antar terminator tidak digambarkan dalam DFD.

2. Proses
Komponen proses menggambarkan transformasi input menjadi output.
Penamaan proses disesuaikan dengan proses/kegiatan yang sedang dilakukan.
Ada 4 kemungkinan yang dapat terjadi dalam proses sehubungan dengan input
dan output :
1 input & 1 output 1 input & banyak output
banyak input & 1 output banyak input & banyak output
Ada beberapa hal yang perlu diperhatikan tentang proses :
a. Proses harus memiliki input dan output.
b. proses dapat dihubungkan dengan komponen terminator, data store atau
proses melalui alur data.
c. Sistem/bagian/divisi/departemen yang sedang dianalisis oleh profesional
sistem digambarkan dengan komponen proses.
3. Data Store
Komponen ini digunakan untuk membuat model sekumpulan paket data dan
diberi nama dengan kata benda bersifat jamak. Data store dapat berupa
file/database yang tersimpan dalam disket, harddisk atau bersifat manual
seperti buku alamat, file folder.
Yang perlu diperhatikan tentang data store :
a. Alur data dari proses menuju data store, hal ini berarti data store berfungsi
sebagai tujuan/tempat penyimpanan dari suatu proses (proses write).

b. Alur data dari data store ke proses, hal ini berarti data store berfungsi sebagai
sumber/ proses memerlukan data (proses read).
c. Alur data dari proses menuju data store dan sebaliknya berarti berfungsi
sebagai sumber dan tujuan.
Lihat gambar berikut :
ProsesWrite Proses Read Proses Update
4. Alur Data
Alur data digunakan untuk menerangkan perpindahan data/paket data dari satu
bagian ke bagian lainnya. Alur data dapat berupa kata, pesan, formulir / informasi.
Ada 4 konsep tentang alur data :
1. Packets of data
Apabila ada 2 data / lebih yg mengalir dari 1 sumber yang sama
menuju pada tujuan yang sama dan mempunyai hubungan digambarkan
dengan 1 alur data.
2. Diverging data flow
Apabila ada sejumlah paket data yg berasal dari sumber yg sama menuju
pada tujuan yg berbeda atau paket data yg kompleks dibagi menjadi
bbrp elemen data yg dikirim ke tujuan yg berbeda.

3. Converging data flow
Apabila ada bbrp alur data yg berbeda sumber menuju ke tujuan yg sama.
4. Sumber dan Tujuan
Arus data harus dihubungkan pada proses, baik dari maupun yang menuju
proses
dari proses ke bukan proses dari bukan proses ke proses dari proses ke proses

P enggambaran DFD
Tidak ada aturan baku untuk menggambarkan DFD, tapi dari berbagai referensi
yang ada, secara garis besar:
1. Buat diagram context
Diagram ini adalah diagram level tertinggi dari DFD yang
menggambarkan hubungan sistem dgn lingkungan luarnya.
Cara :
- Tentukan nama sistemnya.
- Tentukan batasan sistemnya.
- Tentukan terminator apa saja yg ada dalam sistem.
- Tentukan apa yg diterima/diberikan terminator dari/pada sistem.
- Gambarkan diagram context
2. Buat diagram level Zero
Diagram ini adalah dekomposisi dari diagram Context.
Cara :
- Tentukan proses utama yang ada pada sistem.
- Tentukan apa yang diberikan/diterima masing-masing proses pada/dari
sistem sambil memperhatikan konsep keseimbangan (alur data yang
keluar/masuk dari suatu level harus sama dengan alur data yang
masuk/keluar pada level berikutnya)
- Apabila diperlukan, munculkan data store (master) sebagai sumber
maupun tujuan alur data.
- Gambarkan diagram level zero.
- Hindari perpotongan arus data
- Beri nomor pada proses utama (nomor tidak menunjukkan
urutan proses).
3. Buat diagram level Satu
Diagram ini merupakan dekomposisi dari diagram level zero.
Cara :
- Tentukan proses yang lebih kecil (sub-proses) dari proses utama yang ada

di level zero.
- Tentukan apa yang diberikan/diterima masing-masing sub-proses pada/dari
sistem dan perhatikan konsep keseimbangan.
- Apabila diperlukan, munculkan data store (transaksi) sebagai sumber
maupun tujuan alur data.
- Gambarkan DFD level Satu
- Hindari perpotongan arus data.
- Beri nomor pada masing-masing sub-proses yang menunjukkan
dekomposisi dari proses sebelumnya. Contoh :
1.1, 1.2, 2.1
4. DFD level dua, tiga, ..
Diagram ini merupakan dekomposisi dari level sebelumnya.
Proses dekomposisi dilakukan sampai dengan proses siap
dituangkan ke dalam program. Aturan yg digunakan sama dgn
level satu.
III. UCD - Use Case Diagram
· Diagram Use Case adalah diagram yang menunjukkan fungsionalitas suatu
sistem atau kelas dan bagaimana sistem tersebut berinteraksi dengan dunia luar
dan menjelaskan sistem secara fungsional yang terlihat user.
· 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 yang
berinteraksi dengan system untuk melakukan pekerjaan-pekerjaan tertentu.
· Use case diagram dapat digunakan selama proses analisis untuk menangkap
requirements sistem dan untuk memahami bagaimana sistem seharusnya bekerja.
Selama tahap desain, use case diagram berperan untuk menetapkan perilaku
(behavior) sistem saat diimplementasikan.

· Kebutuhan atau requirements sistem adalah fungsionalitas apa yang harus
disediakan oleh sistem kemudian didokumentasikan pada model use case yang
menggambarkan fungsi sistem yang diharapkan (use case), dan yang
mengelilinginya (actor), serta hubungan antara actor dengan use case (use case
diagram) itu sendiri.
Notasi Gambar Yang Diapakai Use Case
1. Actor
Seorang / sebuah aktor adalah sebuah entitas manusia atau mesin yang
berinteraksi dengan sistem untuk melakukan pekerjaan-pekerjaan tertentu.
2. Case
Menggambarkan deskripsi yang melibatkan actor.
Contoh Case- Actor:
3. Extend
Relasi yang digunakan jika use case yang satu mirip dengan use case yang lain.
4. Include
Relasi jika terdapat perilaku yang mirip dengan beberapa use case
Komponen Pembentuk Use Case
· Actor
Pada dasarnya actor bukanlah bagian dari use case diagram, namun untuk dapat
terciptanya suatu use case diagram diperlukan beberapa actor.
· Actor tersebut mempresentasikan seseorang atau sesuatu (seperti perangkat,
sistem lain) yang berinteraksi dengan sistem.

· Sebuah actor mungkin hanya memberikan informasi inputan pada sistem, hanya
menerima informasi dari sistem atau keduanya menerima, dan memberi
informasi pada sistem.
2. Use Case
· Use case adalah gambaran fungsionalitas dari suatu sistem, sehingga customer
atau pengguna sistem paham dan mengerti mengenai kegunaan sistem yang akan
dibangun.
Catatan : Use case diagram adalah penggambaran sistem dari sudut pandang pengguna
sistem tersebut (user), sehingga pembuatan use case lebih dititikberatkan pada
fungsionalitas yang ada pada sistem, bukan berdasarkan alur atau urutan kejadian.
Relasi dalam Use Case
Ada beberapa relasi yang terdapat pada use case diagram:
1. Association, menghubungkan link antar element.
2. Generalization, disebut juga inheritance (pewarisan), sebuah elemen dapat
merupakan spesialisasi dari elemen lainnya.
3. Dependency, sebuah element bergantung dalam beberapa cara ke element
lainnya.
4. Aggregation, bentuk assosiation dimana sebuah elemen berisi elemen lainnya.
Tipe relasi / stereotype yang mungkin terjadi pada Use Case diagram:
1. <<include>>, yaitu kelakuan yang harus terpenuhi agar sebuah event dapat
terjadi, dimana pada kondisi ini sebuah use case adalah bagian dari use case
lainnya.
2. <<extends>>, kelakuan yang hanya berjalan di bawah kondisi tertentu seperti
menggerakkan alarm.
3. <<communicates>>, mungkin ditambahkan untuk asosiasi yang menunjukkan
asosiasinya adalah communicates association . Ini merupakan pilihan selama
asosiasi hanya tipe relationship yang dibolehkan antara actor dan use case.

Contoh Use Case Diagram.
Tugas Pendahuluan:
1. Dari hasil proses requirements engineering, lakukan pemodelan perangkat
lunak dengan menggunakan tools
- Entity Relational Diagram + Data Flow Diagram jika menggunakan
pendekatan struktural
- Use Case Diagram, jika menggunakan pendekatan Object Oriented
2. Buatlah desain ERD (CDM – Conceptual Data Model) sekaligus mapping
seluruh tabel-tabelnya (PDM – Physical Data Model)
3. Buatlah desain DFD, mulai dari context level sampai dengan level yang dianggap
paling detil

Percobaan:
1. Lakukan proses verifikasi dan validasi kepada pelanggan terhadap desain yang
yang telah dibuat
2. Konsultasikan kepada dosen pembimbing
Laporan Resmi:
Dari hasil proses verifikasi + validasi serta konsultasi terhadap pemodelan
perangkat lunak , susun laporan resmi berupa rancangan desain berupa :
1. ERD beserta mapping tabelnya
2. DFD mulai dari context level sampai dengan level yang paling detil
3. UCD, jika menggunakan pendekatan object oriented

BBAABB 1100
DDEESSAAIINN SSIISSTTEEMM DDAANN AANNTTAARRMMUUKKAA
Pokok Bahasan:
· Rancangan antarmuka
· Rancangan arsitektur perangkat lunak
· Menyusun time schedule
· Mampu merepresentasikan antarmuka perangkat lunak
· Mampu merepresentasikan rancangan arsitektur perangkat lunak
· Mampu menyusun time schedule
Dasar Teori:
Desain Antarmuka Pengguna
Tujuan dari Desain Antarmuka Pengguna adalah untuk membuat interaksi
pengguna sesederhana dan seefisien mungkin, dalam hal mencapai tujuan pengguna—
atau apa yang sering disebut dengan user-centered design. Desain Antarmuka Pengguna
yang baik dapat memberikan penyelesaian pekerjaan dengan menggunakan tangan
tanpa menarik perhatian yang tidak perlu terhadap dirinya sendiri. Desain grafis dapat
dimanfaatkan untuk mendukung kegunaan (bahasa Inggris: Usability). Proses desain
haruslah seimbang antara fungsi teknis dan elemen visual (misalnya, model mental)

untuk menciptakan sebuah sistem yang tidak hanya bisa beroperasi tetapi juga dapat
digunakan dan disesuaikan dengan kebutuhan pengguna.
Desain Antarmuka Pengguna terlibat dalam berbagai proyek dari sistem
komputer, untuk mobil, untuk pesawat komersial; semua proyek ini melibatkan banyak
interaksi manusia dasar yang sama dan juga membutuhkan beberapa keterampilan yang
unik dan pengetahuan. Akibatnya, desainer cenderung mengkhususkan diri pada jenis
proyek tertentu dan memiliki kemampuan berpusat di sekitar keahlian mereka, apakah
itu desain software, penelitian pengguna,desain web, atau desain industri.
Tugas Pendahuluan:
1. Berdasarkan tabel FR (Functional Requirements), buatlah draft desain
antarmuka untuk masing-masing fungsi dasar yang bersesuaian.
2. Rancanglah draft time schedule untuk penyelesaian proyek pembuatan perangkat
lunak yang meliputi poin : no, task list, estimasi, start, finish dan PIC
Percobaan:
1. Desain antarmuka perangkat lunak sesuai dengan item – item pada kebutuhan
fungsionalitas.
2. Buatlah format sesuai berikut :
Nama Antar Muka : (berikan nama antarmuka)
No Item Fungsionalitas : (berikan no realisasi antarmuka terhadap item
fungsionalitas)
Tampilan Anatrmuka :
(buat contoh tampilan antarmuka disini, berikan link keterangan mengenai
bagian – bagian yang ada pada antarmuka, label, text, edit, dll)

Deskripsi : (isilah dengan deskripsi dari antarmuka
mengenai fungsi utama)
(berikan penjelasan mengenai fungsi – fungsi pada antarmuka dan tujuan disni,
sperti fungsi tombol pa saja, text apa saja.)
Pre and Post Condition : (tampilan akan muncul jika apa dan setelah
melakukan proses tampilan, apa yang diberikan)
Relasi dengan
Antarmuka Lain
: (isilah dengan nama antarmuka lain yang
memiliki hubungan dengan antarmuka ini, jika
ada)
Laporan Resmi:
1. Buat dokumen berisi desain antar muka dengan deskripsi detail mengenai bagian
– bagian dari desain antarmuka.
2. Lakukan fiksasi terhadap time schedule yang sudah dibuat. Perhatikan feasibility
dari skedul tersebut

BBAABB 1111 –– 1122-- 1133 -- 1144
PPEENNGGEEMMBBAANNGGAANN DDAANN IINNTTEEGGRRAASSII
Pokok Bahasan:
· Konstruksi perangkat lunak berdasarkan dokumen rancangan perangkat lunak
· Debugging
· Unit Testing
· Meningkatkan ketrampilan konstruksi perangkat lunak
· Mampu membuat antarmuka yang menarik
· Mampu melakukan review dan uji perangkat lunak
· Memahami tugas dalam tim pengembang perangkat lunak
Dasar Teori:
Rekayasa perangkat lunak melibatkan segala aktifitas pengembangan perangkat
lunak mulai tahap pengumpulan persyaratan sampai dengan pengelolalaan system.
Tahapan penting pada proses ini adalah implementasi system, yaitu proses pembuatan
versi executable dari perangkat lunak. Implementasi melibatkan pengembangan
program dengan bahasa tingkat rendah maupun tingkat tinggi. Beberapa aspek
implementasi yang penting dalam rekayasa perangkat lunak diantaranya adalah :
1. Reuse
Perangkat lunak modern dibangun dengan menggunakan komponen atau system
yang sudah ada.

2. Configuration Management
Selama proses pengembangan, banyak sekali versi komponen perangkat lunak
yang akan dibuat. Jika kita tidak menjaga track dari versi komponen tersebut,
bisa saja kita akan menggunakan komponen dengan versi yang salah.
3. Host-target Development
Terkadang produksi perangkat lunak tidak selalu akan diekseskusi pada
komputer yang sama dengan computer pada saat pengembangan. Sehingga
untuk pengembagan kita menggunakan satu computer (host system) dan
dicobakan atau dieksekusi di computer lain (target system).
Tugas Pendahuluan:
1. Definisikan terlebih dahulu nama fungsi – fungsi utama yang ada pada
rancangan perangkat lunak sesuai dengan antar muka yang telah dibuat.
Percobaan:
1. Buatlah codecard yang berisikan deskripsi mengenai fungsi – fungsi yang ada
pada perangkat lunak. Contoh :
No Fungsi : (isikan no fungsi disini)
Nama Fungsi : (isikan nama fungsi disini)
Kelas : (jika terdapat dalam kelas, sebutkan nama kelasnya)
Parameter : (isikan parameter yang diberikan, kemudian berikan
deskripsi masisng – masing parameter, tipe dan tujuan
parameter tersebut)
Return Type : (isikan nilai balik yang diberikan jika ada)
UI Relasi : (isikan UI yang melibatkan fungsi ini secara langsung)
Fungsi Relasi : (isikan nama-nama fungsi lain yang digunakan oleh fungsi
ini di body fungsinya)
Flowchart : (isikan diagram alir proses fungsi disini, jika ada)
2. Dalam satu tim, tentukan pembagian yang jelas dalam implementasi system,
kemudian berikan konsep bagaimana integrasi yang akan dilakukan oleh tim.

Laporan Resmi:
1. Kerjakan dan selesaikan tahap construction berdasarkan time schedule yang
sudah dibuat
2. Susun dokumentasi secara bertahap, berdasarkan dokumen-dokumen yang telah
dibuat selanjutnya. Kumpulkan dalam bentuk hard copy 1 buah. Buatlah dalam
format sbb :
LAPORAN DOKUMENTASI
PRAKTIKUM REKAYASA PERANGKAT LUNAK
Cover
Abstrak
Kata pengantar
Daftar isi
Daftar Gambar
Daftar Tabel
Bab 1 Pendahuluan
- Latar belakang
- Permasalahan
- Batasan Masalah
- Tujuan/Manfaat
Bab 2 Dasar Teori
àyang berhubungan dengan proyek perangkat lunak yang dibuat
Bab 3 Perancangan dan Pembuatan Sistem
- Desain Sistem
- Deskripsi Perangkat Lunak
- Gambar/diagram arsiteksur Perangkat Lunak
- Perancangan Perangkat Lunak
à ER Diagram, DFD, Use Case Diagram

- Perancangan interface
- Daftar FR & NFR
- dll
Bab 4 Uji Coba dan Analisa
- Uji Coba Rilis Perangkat Lunak (Release Testing)
- Skenario Hardware dan software untuk lingkungan testing
- Skenario Testing
a. Deskriptif
b. Capture gambar
- User Testing (berdasarkan survey)
- Profil User
- Tabel kesimpulan hasil survey
- Analisis hasil Uji Coba
- Deskriptif
- Diagram
Bab 5 Kesimpulan dan Saran
- Kesimpulan
à poin-poin yang didapatkan selama proses pembuatan aplikasi
- Saran
à pengembangan-pengembangan yang mungkin dilakukan di masa yang
akan datang untuk memperbaiki aplikasi
Daftar Pustaka
Lampiran
- Data pendukung
- User Guide

BBAABB 1155
UUJJII DDAANN VVEERRIIFFIIKKAASSII
Pokok Bahasan:
· Release Testing
· Mampu menganalisa dan memverifikasi perangkat lunak sesuai dengan persyaratan
yang telah dibuat
Dasar Teori:
Kita percaya pada sebuah software namun terkadang mengalami rusak atau
gagal (failure). Melengkapi perangkat lunak pada sebuah system dapat membuat
pelayanan menjadi lebih murah, selalu tersedia atau selalu dapat menyesuaikan diri pada
perubahan. Tetapi itu tidak membuatnya dapat selalu dipercaya.
Isu Penting :
1. Bagaimana untuk memenuhi harapan pengguna (masyarakat)?
2. Bagaimana industry perangkat lunak dapat mengurangi ketidak percayaan itu?
Verifikasi :
1. Meneliti Kebenaran
2. Memastikan keabsahan
3. Berkenaan dengan proses terjadinya
Validasi :
1. Pemutakhiran, pengkinian
2. Meyakinkan kebenaran data
3. Berkenaan dengan hasil sebuah proses.

Tugas Pendahuluan:
Persiapkan dokumen persyaratan perangkat lunak anda untuk digunakan dalam
verifikasi perangkat lunak.
Percobaan:
Lakukan diskusi verifikasi dalam tim developer untuk :
1. Menyusun daftar item fungsionalitas persyaratan system yang akan diverifikasi.
2. Menguji kebenaran kebutuhan system sesuai dengan dokumen persayaratan
perangkat lunak.
3. Buatlah tabel verifikasi berisi item fungsionalitas pada dokumen persyaratan
seperti contoh berikut :
No Item Fungsionalitas Selesai Belum Selesai Keterangan
1 <isikan sesuai item di
SRS>
<beri centang
jika selesai>
<beri centang
jika belum>
<beri keterangan
yang dibutuhkan>
Laporan Resmi:
Dari hasil diskusi yang dilakukan, susun laporan resmi berupa dokunen verifikasi
seperti pada tabel diatas.

BBAABB 1166
VVAALLIIDDAASSII PPEENNGGGGUUNNAA
Pokok Bahasan:
· User Acceptance Testing (Uji Penerimaan Pengguna)
· Negoisasi hasil uji oleh pengguna
· Mampu melakukan validasi perangkat lunak kepada pengguna
· Memahami tahap-tahap dalam user acceptance testing
Dasar Teori:
Uji Coba Pengguna (User Testing)
Uji Coba pengguna/pelanggan adalah tahap dalam proses pengujian di mana
pengguna atau pelanggan memberikan masukan dan rekomendasi untuk pengujian
sistem. Uji coba pengguna ini sangatlah penting, bahkan ketika uji coba sistem (system
testing) dan uji coba rilis (release testing) yang komprehensif telah dilakukan. Alasan
untuk ini adalah bahwa kondisi dari lingkungan di mana pengguna bekerja memiliki
pengaruh besar pada kinerja kegunaan keandalan, dan ketahanan sistem. Hal ini tidak
dapat direplikasi dalam lingkungan pengujian yang sebelumnya (system dan release
testing).
Ada 3 tipe uji coba pengguna :
1. Alpha Testing
Pengguna dari perangkat lunak bekerja bersama dengan tim development untuk
menguji coba perangkat lunak ketika masih berada di sisi developer

2. Beta Testing
Perangkat lunak sudah dirilis kepada user yang memungkinkan mereka untuk
melakukan uji coba. Diharapkan dari uji coba tersebut pengguna bisa
menyampaikan problem perangkat lunak yang mereka temui kepada pihak
developer.
3. Uji Coba Penerimaan (Acceptance testing)
Pelanggan melakukan uji coba terhadap perangkat lunak untuk memutuskan
apakah perangkat lunak tersebut telah siap untuk diserahterimakan dari pihak
developer untuk selanjutnya di-deploy di lingkungan pelanggan
Proses Uji Coba Penerimaan (Acceptance Testing)
Gambar 16.1 Proses User Acceptance Testing
Tahapan-tahapan dalam user acceptance testing
1. Tentukan kriteria penerimaan
2. Rencanakan uji coba penerimaan
3. Turunkan tes-tes penerimaan
4. Jalankan tes-tes penerimaan
5. Negosiasikan hasil-hasil tes
6. Tolak / menerima sistem

Tugas Pendahuluan:
Pada prinsipnya perangkat lunak dibuat dalam rangka menyelesaikan suatu masalah
praktis dalam kehidupan manusia.
3. Lakukan curah pendapat (brain storming) untuk sebanyak mungkin
memunculkan ide permasalahan/studi kasus yang akan dibuatkan solusi
perangkat lunaknya.
4. Dari masing-masing ide tersebut, buat draft tentang latar belakang dan
permasalahan dari diangkatnya ide tersebut sekaligus solusi dari perangkat lunak
yang akan dibuat.
Percobaan:
1. Lakukan diskusi validasi antara tim developer dengan tim penguna/pelanggan
untuk :
- Menyusun daftar item fungsionalitas persyaratan system yang akan
divalidasi.
- Buatlah tabel validasi berisi item fungsionalitas pada dokumen persyaratan
seperti contoh berikut :
No Item Fungsionalitas Selesai Belum Selesai Keterangan
1 <isikan sesuai item di
SRS>
<beri centang
jika selesai>
<beri centang
jika belum>
<beri keterangan
yang dibutuhkan>
- Berikan tabel tersebut kepada penguna/pelanggan untuk mendapatkan
validasi
- Lakukan negoisasi terhadap pengguna/pelanggan, jika diperlukan

- Dapatkan keputusan akhir dari pengguna/pelanggan : sistem diterima
ataukah ditolak
Laporan Resmi:
Kumpulkan hasil akhir proyek dalam 1 CD dengan komposisi folder sebagai berikut :
1. Definisi Proyek
1. Power point pengajuan studi kasus
2. Film/flash skenario
2. Proposal penawaran
3. Laporan/Dokumentasi lengkap
4. Program Source
5. Program/aplikasi pendukung
6. Materi presentasi demo

Analisis Kelayakan Sistem Absensi Berbasis RFID

Recommended

Recommended

More Related Content

What's hot

What's hot (19)

Similar to Analisis Kelayakan Sistem Absensi Berbasis RFID

Similar to Analisis Kelayakan Sistem Absensi Berbasis RFID (20)

Recently uploaded

Recently uploaded (6)

Analisis Kelayakan Sistem Absensi Berbasis RFID