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
KATA PENGANTAR 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 sebaikbaiknya, 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
DAFTAR ISI 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
BAB 1
PENGENALAN PROYEK PERANGKAT LUNAK 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
BAB 2
STUDI KELAYAKAN PERANGKAT LUNAK Pokok Bahasan: ·
Memilih studi kasus proyek perangkat lunak
·
Analisis kelayakan studi kasus yang dipilih
Tujuan Pembelajaran: ·
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 dilampirkan pada dokumen spesifikasi system. Berikut outline dokumen studi kelayakan
Ukuran Studi Kelayakan Aspek Teknologi Ekonomi Non-ekonomi Organisasi atau Operasional
Jadwal Kendala hukum, etika, dan yang lain
Pertimbangan Apakah sistem dapat dikembangkan dan dioperasikan dengan teknologi yang tersedia? Apakah manfaat sistem lebih besar daripada biaya yang dikeluarkan (termasuk untuk memenuhi kebutuhan personil)? Apakah sistem yang diusulkan memiliki keuntungan yang tak dapat diukur dengan uang Apakah sistem yang diusulkan bisa cocok dengan budaya organisasi? Apakah level keahlian yang digunakan dalam sistem baru sesuai dengan pegawai yang akan mengoperasikannya? Mungkinkah menerapkan sistem tersebut sesuai dengan jadwal yang telah ditetapkan? 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
BAB 3
PENDEFINISIAN PROYEK PERANGKAT LUNAK Pokok Bahasan: ·
Dokumentasi dan Visualisasi Studi Kasus Proyek Perangkat Lunak
Tujuan Pembelajaran: ·
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
BAB 4-5
REQUEST FOR PROPOSAL Pokok Bahasan: ·
Penawaran kontrak proyek sistem informasi
·
Kontrak dengan developer
Tujuan Pembelajaran: 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.
BAB 6 - 7
FORMAL TECHNICAL REVIEW Pokok Bahasan: ·
Pembuatan proposal proyek perangkat lunak
· Review Kontrak Tujuan Pembelajaran: ·
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
BAB 8
REKAYASA KEBUTUHAN (REQUIREMENT ENGINEERING) 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
Tujuan Pembelajaran: ·
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 SKPL-NF001
Keterangan 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
1
Pilih daerah diinginkan
yang FR-01
2
Menampilkan output FR-02 berupa tempat futsal pada daerah tersebut
Deskripsi Pilihan berupa menu, yaitu Surabaya Pusat, Surabaya Timur, Surabaya Barat, Surabaya Utara, dan Surabaya Selatan Output berupa list nama tempat futsal, alamat, dan icon (tampak dari depan gedung futsal). Contoh:
Prioritas High
High
Kebraon Sport Center (KSC) Jl. Kebraon II / 31 Surabaya
3
Menampilkan output FR-03 dari tempat futsal yang dipilih
4
Menampilkan jadwal FR-04 sewa lapangan
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. Output berupa tabel, lapangan1, lapangan 2, dst, dilengkapi informasi jam dan status (booked / free). Contoh: Lapangan 1 08.00-10.00 booked
Lapangan 2 08.00-10.00 free
High
High
5
Menampilkan agenda dari semua lapangan futsal Admin lapangan dapat melakukan login Admin dapat mengupdate jadwal lapangan, agenda, dan informasi umum Pemilik futsal dapat melakukan register untuk menjadi admin
FR-05
Output mengenai deskripsi dari agenda yang ada di seluruh lokasi lapangan.
High
FR-06
Admin melakukan login dengan menginputkan username dan password.
High
FR-07
Diberikan template (space) untuk admin agar dapat mengisi konten.
High
FR-08
High
Fasilitas untuk menghubungi super admin 10 Menampilkan output berupa peta lokasi 11 Memberikan penilaian untuk tempat futsal 1 Memberikan review untuk tempat futsal 2
FR-09
Mengisi informasi umum, seperti nama, email, username dan password, kemudian email konfirmasi akan dikirimkan ke email pendaftar. Diberikan text box untuk mengisi pesan dan mengirimkan ke email super admin.
6
7
8
9
FR-10 FR-11
FR-12
Medium
Output berupa peta yang telah Medium tersimpan dalam database. Penilaian berupa bintang 1 (terendah) Medium sampai 5 (tertinggi) untuk fasilitas dan pelayanan lapangan futsal tersebut. Diberikan text box untuk memberi Medium komentar bagi lapangan futsal tersebut.
Non Funcional Requirement (pada aplikasi e-Futsal) No
Parameter
Kode
1
Interface
NFR-01
2
Availability
NFR-02
3
Bahasa Komunikasi Security
NFR-03
4
NFR-04
Kebutuhan Aplikasi yang dibangun memiliki desain yang user friendly, sehingga memudahkan pengguna. Penggunaan warna juga perlu diperhatikan untuk keserasian website. 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. Bahasa komunikasi yang digunakan adalah bahasa Indonesia. Batas admin salah menginputkan password adalah 3 kali. Setelah itu
Prioritas High
High
High High
5
Portability
NFR-05
6
Response Time
NFR-06
admin perlu me-reset password dengan mengirimkan email ke super admin, sehingga password dapat di-set ulang. Aplikasi ini dapat diakses di mana saja selama pengguna terhubung dengan internet. Dapat diakses kurang dari 10 detik pada kecepatan akses internet 100Kbps.
High
Medium
Contoh lain untuk Non Functional Requirements: SKPL-Id SKPL-NF1
SKPL-NF2
SKPL-NF3
SKPL-NF4 SKPL-NF5 SKPL-NF6
SKPL-NF7 SKPL-N03
Parameter
Kebutuhan Aplikasi ini harus dapat beroperasi terus Availability 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 berbedabeda. 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. Portability Aplikasi ini bisa diakses di mana saja di lingkungan ITS dengan menggunakan intranet. Security Aplikasi membutuhkan security untuk mengamankan account. Maintainability Aplikasi harus dapat di-maintain dengan mudah oleh administrator. Documentation Dokumentasi yang berhubungan dengan aplikasi harus jelas dan dapat dilacak sehingga pengembangan di masa mendatang dapat dilakukan dengan mudah. Interface Aplikasi yang dibuat harus memiliki antarmuka yang bersifat user friendly Ergonomy Aplikasi ini harus memiliki nilai ergonomi/ kenyamanan dipakai yang tinggi bagi user.
SKPL-Id
Parameter
SKPL-N04
Portability Memory
SKPL-N05
Response time
SKPL-N06
Security
SKPL-N07
Bahasa komunikasi Lain-lain
SKPL-N08
Kebutuhan Aplikasi akan dibangun dengan antarmuka user yang mudah dimengerti, indah dilihat, konsisten, mudah dioperasikan dan tidak membingungkan. Aplikasi ini dapat diakses dari manapun selama ada jaringan intenet. 100 megabyte space pada storage disk. Besarnya memori yang dibutuhkan untuk menjalankan aplikasi sebesar 256Mb. Kecepatan Central Processing dan jalur komunikasi dapat untuk 30 on-line user secara simultan. Waktu response 1 detik untuk data entry dan query Ada pengaturan hak akses agar aman. informasi yang diproses harus terjamin aman. data pribadi aman. tempat penyimpanan data fisikal aman Bahasa komunikasi pada user interface menggunakan bahasa Indonesia.
BAB9
ANALISIS DAN PEMODELAN PERANGKAT LUNAK Pokok Bahasan: ·
Rancangan Entity Relational Diagram (ERD)
·
Rancangan Data Flow Diagram (DFD)
·
Rancangan Use Case Diagram (UCD)
Tujuan Pembelajaran: ·
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
banyak input & 1 output
1 input & banyak 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 :
Proses Write
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
Proses dekomposisi dituangkan
ke
dekomposisi
dilakukan
dari
sampai
level
dengan
sebelumnya. proses
siap
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, mengcreate 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. <
>, 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. <>, 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
BAB 10
DESAIN SISTEM DAN ANTARMUKA PERANGKAT LUNAK Pokok Bahasan: ·
Rancangan antarmuka
·
Rancangan arsitektur perangkat lunak
·
Menyusun time schedule
Tujuan Pembelajaran:
·
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 No Item Fungsionalitas
: :
(berikan nama antarmuka) (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)
(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 : (isilah dengan nama antarmuka lain yang Antarmuka Lain memiliki hubungan dengan antarmuka ini, jika ada) Deskripsi
:
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
BAB 11 – 12- 13 - 14 PENGEMBANGAN DAN INTEGRASI PERANGKAT LUNAK
Pokok Bahasan: ·
Konstruksi perangkat lunak berdasarkan dokumen rancangan perangkat lunak
·
Debugging
·
Unit Testing
Tujuan Pembelajaran: ·
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 Nama Fungsi Kelas Parameter
: : : :
Return Type UI Relasi Fungsi Relasi
: : :
Flowchart
:
(isikan no fungsi disini) (isikan nama fungsi disini) (jika terdapat dalam kelas, sebutkan nama kelasnya) (isikan parameter yang diberikan, kemudian berikan deskripsi masisng – masing parameter, tipe dan tujuan parameter tersebut) (isikan nilai balik yang diberikan jika ada) (isikan UI yang melibatkan fungsi ini secara langsung) (isikan nama-nama fungsi lain yang digunakan oleh fungsi ini di body fungsinya) (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
BAB 15
UJI DAN VERIFIKASI PERANGKAT LUNAK Pokok Bahasan: · Release Testing Tujuan Pembelajaran: ·
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
SRS>
jika selesai>
jika belum>
yang dibutuhkan>
Laporan Resmi: Dari hasil diskusi yang dilakukan, susun laporan resmi berupa dokunen verifikasi seperti pada tabel diatas.
BAB 16
VALIDASI PENGGUNA PERANGKAT LUNAK Pokok Bahasan: ·
User Acceptance Testing (Uji Penerimaan Pengguna)
·
Negoisasi hasil uji oleh pengguna
Tujuan Pembelajaran: ·
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
SRS>
jika selesai>
jika belum>
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
