SDLC - PT3

BAB 3 SOFTWARE DEVELOPMENT LIFE CYCLE (SDLC) I. Pendahuluan A. Deskripsi singkat, manfaat dan relevan Pada pertemuan kali ini akan membahas mengenai SDLC, SDLC singkatan dari software development life cycle atau kadang disebut juga system development life cycle. Manfaat yang didapat setelah mempelajari bab ini mahasiswa dapat memilih model SDLC mana yang tepat untuk rekayasa perangkat lunak yang mereka lakukan. B. Rumusan capaian pembelajaran matakuliah Mampu menerapkan model System Development Life Cycle (SDLC) secara mandiri, bermutu, dan terukur. C. Urutan bahasan dan kaitan materi 1. Pengertian SDLC 2. Model Proses Pengembangan Perangkat Lunak 3. Model Waterfall 4. Model Prototipe 5. Model Spiral 6. Model Rapid Application Development (RAD) 7. Model Scrum 8. Latihan Soal Mandiri dan Tugas Kelompok Pertemuan 3 D. Petunjuk belajar Mari kita membaca petunjuk belajar terlebih dahulu untuk mempermudah materi pertemuan 2 mengenai : a) Berdoalah sebelum memulai pembelajaran b) Bacalah kemampuan akhir tiap tahapan belajar (sub-cpmk), indikator, kriteria dan teknik, bentuk pembelajaran, metode pembelajaran, penugasan mahasiswa dan materi pembelajaran dengan cermat. c) Baca dan pelajari setiap materi yang ada, bila perlu di garis bawahi hal-hal yang menurut anda penting. d) Mahasiswa dapat belajar secara mandiri ataupun berkelompok, saat pertemuan kuliah yang dilakukan secara daring dengan memanfaatkan fasilitas ecampus Sekolah Tinggi Teknologi Informasi NIIT e) Jika belum memahami segera tanyakan kepada Bapak / Ibu dosen pengampu matakuliah. II. Penyajian A. Pengertian SDLC Pada awal pengembangan perangkat lunak, para pembuat program (programmer) langsung melakukan pengodean perangkat lunak tanpa menggunakan prosedur atau tahapan pengembangan perangkat lunak. 26

Dan ditemuilah kendala-kendala seiring perkembangan skala system-system perangkat yang semakin besar. (rosa, 2019) Gambar 1. Pengembangan Perangkat Lunak (Sumber: https://cdns.klimg.com/merdeka.com/i/w/news/2012/10/18/104530/540x270/g aji-programmer-google-lebih-besar-dari-apple-dan-facebook.jpg dan https://sevima.com/wp-content/uploads/2017/01/Programmer-Stress.png) Software Development Life Cycle (SDLC) dimulai sejak tahun 1960-an. Fungsinya mengembangkan system dengan skala usaha besar secara fungsional untuk para konglomerat pada jaman tersebut. Sistem yang dibangun mengelola informasi kegiatan dan rutinitas dari perusahaan yang berpotensi memiliki data yang besar dalam perkembangannya. Gambar 2. Contoh Perusahaan yang menerapkan SDLC tahun 1960 (sumber: https://upload.wikimedia.org/wikipedia/commons/0/03/Ordinateurs_centraux_ 348-3-006.jpg) SDLC adalah proses mengembangkan atau mengubah suatu system perangkat lunak dengan menggunakan model-model dan metodologi yang digunakan orang untuk mengembangkan system-system perangkat lunak sebelumnya. (Rosa, 2019) (berdasarkan best practice atau cara-cara yang sudah teruji baik). Seperti halnya proses metamorphosis sempurna pada kupu-kupu yang indah maka dibutuhkan beberapa tahap untuk dilalui, sama halnya juga dengan membuat perangkat lunak yang memiliki tahapan yang dilaluinya agar menghasilkan perangkat lunak yang handal dan berkualitas 27

Gambar 3. Metamorfosis Sempurna Pada Kupu-Kupu (Sumber: https://sahabatnesia.com/wp-content/uploads/2020/05/gambar- metamorfosis-sempurna-dan-tidak-sempurna.jpg) 1. Tahapan-tahapan SDLC secara Global Gambar 4. Tahapan pengembangan sistem sdlc waterfall Sumber : Buku Sistem Informasi Akuntansi Aplikasi di Sektor Publik. (Sumber: https://www.researchgate.net/figure/Gambar-1-Tahapan- pengembangan-sistem-sdlc-waterfall-Sumber-Buku-Sistem- Informasi_fig1_341824379) a. Inisiasi (initiations) ditandai dengan pembuatan proposal proyek perangkat lunak b. Pengembangan Konsep system (system concept development) dengan mendefinisikan lingkup konsep termasuk dokumen lingkup system, analisis manfaat biaya, manejemen rencanam dan pembelajaran kemudahan system. c. Perencanaan (Planning) mengembangkan rencana manajemen proyek dan dokumen perencanaan lainnya termasuk menyediakan sumber daya yang dibutuhkan untuk memperoleh solusi. d. Analisis kebutuhan (requirements analysis) khususnya kebutuhan pemakai (user) dan mengembangkan kebutuhan user dengan membuat dokumen kebutuhan fungsional e. Desain (design) system focus pada bagaimana dapat memenuhi fungsi- fungsi yang dibutuhkan. f. Pengembangan (Development) untuk mengonversi tahapan desain ke system informasi yang lengkap termasuk bagaimana memperoleh dan 28

melakukan instalasi lingkungan system seperti membuat basis data, pengodean, pengompilasian, perbaikan bug, peninjauan pengujian. g. Integrasi dan pengujian (integration and test) dalam mendemostrasikan system perangkat lunak bahwa telah memenuhi kebutuhan fungsional. Dengan diarahkan oleh staf penjaminan kualitas (quality assurance) dan user. Tahapan ini menghasilkan dokumen analisis pengujian. h. Implementasi (Implementation) termasuk persiapan dan implementasi perangkat lunak pada lingkungan produksi dan menjalankan resolusi dari permasalahan yang teridentifikasi dari fase atau tahapan integrase dan pengujian. i. Operasi dan pemeliharaan (operations and maintenance), untuk mendeskripsikan pekerjaan untuk mengoperasikan dan memelihara sistmen informasi pada lingkungan produksi (user) termasuk didalamnya implementasi akhir dan masuk pada proses peninjauan. j. Disposisi (disposition) kegiatan ini mendeskripsikan aktifitas akhir dari pengembangan system dan membangun data yang sebenarnya sesuai dengan aktifitas user B. Model Proses Pengembangan Perangkat Lunak SDLC memiliki bebarapa model dalam penerapan tahapan prosesnya. “Beberapa model dasar akan dibahas pada subbab berikutnya, selain model- model dasar yang dibahas, masih banyak model-model yang muncul dengan memodifikasi model-model SDLC dasar.” C. Model Waterfall Model SDLC air terjun (waterfall) sering disebut juga model sekuensial linier (sequential linear) atau alur hidup klasif (classic life cycle). Model air terjun menyediakan pendekatan alur hidup perangkat lunak secara sekuensial atau terurut dimulai dari analisis, desain, pengodean, pengujian, dan tahap pendukung (support). Berikut adalah gambar model air terjun: Gambar 5. Model Waterfall / Air terjun (Sumber: https://repository.bsi.ac.id/index.php/unduh/item/713/File_10-Bab- II-Landasan-Teori.pdf) Adapun metode air terjun menurut Rosa dan Shalahuddin (2019) yaitu: 1. Analisis Kebutuhan Perangkat Lunak Merupakan proses dalam pengumpulan kebutuhan yang dilakukan secara intensif untuk menspesifikasikan rekayasa kebutuhan perangkat lunak dan 29

agar dapat dipahami perancangan system seperti apa yang dibutuhkan oleh pengguna/user. Spesifikasi kebutuhan perangkat lunak pada tahapan ini diperlukan untuk didokumentasikan. Gambar 6. Analisis Kebutuhan Perangkat Lunak (sumber: https://image.slidesharecdn.com/bab4- analisiskebutuhanperangkatlunak1-170912045142/95/rpl-1-lama-analisis- kebutuhan-perangkat-lunak-1-5-638.jpg?cb=1505270933) 2. Desain Desain perangkat lunak adalah proses multi langkah yang fokusnya pada desain pembuatan program perangkat lunak termasuk struktur data, arsitektur perangkat lunak, representasi antarmuka, dan prosedur pengkodean. Tahap ini mentranslasikan kebutuhan perangkat lunak dari tahap analisis kebutuhan ke representasi desain agar dapat diimplementasikan menjadi program pada tahap selanjutnya (pengkodean). Desain perangkat lunak yang dihasilkan pada tahap ini juga perlu didokumentasikan. Gambar 7. Tahapan Desain (Sumber: https://slideplayer.info/slide/2380887/8/images/2/fase+pengembangan+dan+de sain+perangkat+lunak.jpg) 30

3. Pembuatan Kode Program Desain harus ditranslasikan ke dalam program perangkat lunak. Hasil dari tahap ini adalah program komputer sesuai dengan desain yang telah dibuat pada tahap desain. Gambar 8. Pilihan Kode Program dengan Bahasa Pemrograman (Sumber: https://i2.wp.com/si.fst.unair.ac.id/wp- content/uploads/2019/09/bigstock-Programming-Web-Banner-Best-P- 258081862.jpg) Gambar 9. Kode Sumber Program (sumber: https://www.sekawanmedia.co.id/wp- content/uploads/elementor/thumbs/php-adalah- p1qqdchbe1ve9yaf60k034osmtiir3gi79d98ululc.jpg) 4. Pengujian Pengujian ini berfokus kepada perangkat lunak secara dari segi logic dan fungsionalnya serta memastikan bahwa semua bagian telah dilakukan pengujian. Pengujian ini dilakukan untuk meminimalisir kesalahan (error/bug) dan juga memastikan keluaran yang dihasilkan sesuai dengan yang diinginkan oleh user. 31

Gambar 10. Pengujian Aplikasi (Sumber: https://w7.pngwing.com/pngs/959/716/png-transparent-usability- testing-software-testing-design-usability-software-testing-technology.png) Gambar 11. Contoh Pengujian Aplikasi 5. Pendukung (support) atau Pemeliharaan (maintenance) Tidak menutup kemungkinan sebuah perangkat lunak pasti akan mengalami perubahan ketika sudah dikirimkan ke user. Perubahan ini dapat terjadi jika adanya kesalahan yang muncul dan tidak terdeteksi pada saat melakukan pengujian atau perangkat lunak harus beradaptasi dengan lingkungan baru. Tahap pendukung atau pemeliharaan dapat mengulangi proses pengembangan mulai dari analisis spesifikasi untuk perubahan perangkat lunak yang sudah ada, tapi tidak untuk membuat perangkat lunak baru. Gambar 12. Pemeliharaan Perangkat Lunak (Sumber: https://4.bp.blogspot.com/-28j2gDCxajM/W- 9cT189b5I/AAAAAAAADVk/bPWXGSOvV6cdJRFH-v3Qe- 0BC2szXy0dwCLcBGAs/s1600/pemeliharaan%2Bperangkat%2Blunak.jpg) 32

Kelebihan model waterfall: 1. Memiliki proses yang urut dan bertahap, sehingga kualitas sistem/PL yang dihasilkan akan baik. 2. Setiap proses memiliiki spesifikasinya sendiri, karena setiap tahap harus terselesaikan dengan lengkap sebelum melanjutkan ke tahap berikutnya. 3. Setiap proses tidak dapat saling tumpang tindih. 4. Metode ini akan lebih baik digunakan jika kebutuhan-kebutuhan sudah diketahui. Kekurangan model waterfall: 1. Proses yang dilakukan cenderung panjang dan lama, karena proses pengembangan tidak dapat dilakukan berulang sebelum menghasilkan produk. 2. Kesalahan kecil pada satu tahapan akan menimbulkan masalah besar jika tidak diketahui sejak awal pengembangan, berakibat pada tahapan selanjutnya 3. Biaya penggunaan metode yang cenderung mahal 4. Membutuhkan banyak riset dan penelitian pendukung untuk mengembangkan sistem sehingga pelanggan harus sabar karena pembuatan PL baru dimulai pada tahap perancangan. 5. Kenyataannya sulit untuk mengikuti aturan sequential, karena iterasi sulit dilakukan dan menyebabkan masalah baru. Model waterfall adalah model SDLC yang paling sederhana. Model ini hanya cocok untuk pengembangan perangkat lunak dengan spesifikasi yang tidak berubah-ubah. D. Model Prototipe Sering pelanggan (customer) sudah membayangkan kumpulan kebutuhan yang di inginkan tapi tidak terspesifikasikan secara detail dari segi masukan (input), proses dan luaran(output). Di sisi lain seorang pengembang perangkat lunak harus menspesifikasikan sebuah kebutuhan secara detail dari segi teknis dimana pelanggan sering kurang mengerti mengenai hal teknis tersebut. Prototype adalah pendefinisian sejumlah sasaran Perangkat Lunak berdasarkan kebutuhan dan pemahaman secara umum, tetapi tidak bisa mengidentifikasi kebutuhan secara rinci untuk beberapa fungsi dan fitur-fitur. Tujuannya adalah untuk membantu dalam tahap analisis dan desain yang memungkinkan pengguna untuk melihat lebih awal apa yang akan dilakukan sistem, yaitu untuk memfasilitasi validasi. Prototype dapat digunakan sebagai model proses yang berdiri sendiri. Pembuatan prototipe biasanya digunakan sebagai teknik yang dapat diimplementasikan di dalam konteks setiap model proses Perangkat Lunak, sehingga membantu stakeholder untuk lebih memahami apa yang akan dikembangkan ketika spesifikasi kebutuhan belum jelas. 33

Gambar 13. Prototipe membantu stakeholder memahami kebutuhan Spefisikasi (Sumber: https://miro.medium.com/max/724/1*0gkasyYO8KkChq0YSOmIPA.png) Gambar 14. Model Prototype (sumber: Pressman, 2015) Tahapan dalam Model Prototype 1. Dimulai dengan dilakukannya komunikasi antara tim pengembang PL dengan pelanggan. 2. Tim pengembang bertemu dengan stakeholder untuk mendefinisikan sasaran keseluruhan PL, mengidentifikasi spesifikasi kebutuhan yang diketahui, dan menggambar- kan definisi lebih jauh pada iterasi selanjutnya. 3. Pembuatan prototipe direncanakan dengan cepat, dan pemodelan dilakukan 4. Prototipe diserahkan kepada stakeholder untuk dievaluasi, dan memberikan umpan balik yang digunakan untuk persyaratan lebih lanjut 5. Iterasi akan terjadi saat prototipe diperbaiki Manfaat Pengembangan Model Prototype Model prototype dikembangkan dan didemonstrasikan pada awal proses pembangunan PL, sehingga dapat bermanfaat untuk: 1. Menghindari kesalahpahaman antara pengembang PL dan pengguna 2. Beberapa fasilitas yang hilang mungkin dapat terungkap 34

3. Fasilitas yang sulit digunakan/membingungkan dapat diidentifikasi dan disempurnakan 4. Pengembang PL mungkin menemukan persyaratan yang tidak lengkap atau tidak konsisten. Masalah pada Model Prototype: 1. Stakeholder hanya melihat tampilan PL yang akan dipakai tanpa mempedulikan bagaimana kerja sistem, dan pemeliharaan jangka panjang. 2. Perubahan yang dibuat selama pengembangan PL mungkin akan mengubah struktur arsitektur. Oleh karena itu mungkin sulit dan mahal untuk pemeliharaannya. 3. Karakteristik sistem yang penting seperti kinerja, keamanan dan keandalan, mungkin akan diabaikan selama pengembangan PL. 4. Selama tahap pengembangan, prototype akan diubah untuk memenuhi kebutuhan pengguna. kemungkinan perubahan yang dibuat akan tidak terkontrol dan tidak didokumentasikan dengan baik. Contoh aplikasi dengan model prototipe: Gambar 15. Contoh Prototype Perangkat Lunak (Sumber: milik pribadi) E. Model Spiral Model Spiral merupakan suatu model proses Perangkat Lunak evolusioner yang menggabungkan pendekatan prototyping yang bersifat iteratif (berulang-ulang) dengan aspek yang terkontrol dan sistematis pada model waterfall. Model pengembangan spiral adalah model proses Perangkat Lunak yang dikendalikan risiko yang digunakan untuk memandu para stakeholder untuk secara bersamaan merekayasa sistem yang bernuansa PL. Model spiral menggunakan prototipe sebagai mekanisme pengurangan risiko. Model spiral menggunakan pendekatan langkah demi langkah (waterfall) yang sistematis tetapi menggabungkannya ke dalam kerangka iteratif yang lebih realistis mencerminkan dunia nyata. Model spiral adalah pendekatan realistis untuk pengembangan sistem berskala besar. 35

Gambar 16. Model Spiral (Sumber: Pressman, 2015) Penjelasan gambar: 1. Proses evolusioner ini dimulai dari titik tengah, ke bagian luar spiral searah jarum jam. 2. Risiko Perangkat Lunak akan dipertimbangkan saat masing-masing gerakan dibuat dan titik pengukuran dicatat setiap saat langkah-langkah evolusioner dilewati. 3. Lintasan pertama di sekitar spiral dapat menghasilkan spesifikasi produk, putaran berikutnya di sekitar spiral mungkin digunakan untuk mengembangkan suatu prototipe dan pada lintasan berikutnya secara progresif bergerak ke versi Perangkat Lunak yang semakin canggih. 4. Setiap melewati lintasan menghasilkan penyesuaian pada perencanaan proyek. 5. Biaya dan jadwal disesuaikan berdasarkan umpan balik yang berasal dari pelanggan setelah pengiriman produk. 6. Selain itu, dilakukan penyesuaian jumlah iterasi (perulangan)yang direncanakan untuk menyelesaikan produk Perangkat Lunak. Keuntungan Model Spriral: 1. Pendekatan yang dikendalikan risiko menghindari banyak kesulitan. 2. Mengakomodasi persiapan untuk evolusioner siklus hidup, pertumbuhan, dan perubahan pada produk Perangkat Lunak. 3. Menyediakan mekanisme untuk tujuan kualitas dan Perangkat Lunak gabungan ke pengembangan produk Perangkat Lunak. 4. Mempunyai fokus untuk mengeliminasi kesalahan (error) 5. Menyediakan pendekatan terpisah untuk pengembangan dan pemasangan Perangkat Lunak. 6. Menyediakan keranga kerja aktif untuk pengembangan. 7. Sistem hardware dan software yang terintegrasi. Kerugian Model Spriral: 1. Memerlukan penyesuaian dengan Perangkat Lunak yang menitik beratkan pada kontrol dan titik permasalahan yang merupakan keunggulan model waterfall. 36

2. Berdasarkan keahlian manajemen risiko yang memerlukan penaksiran risiko yang masuk akal, akan menimbulkan masalah yang lebih besar jika risiko mayor tidak ditemukan. 3. Memerlukan kebutuhan untuk penelitian lebih lanjut terhadap langkah- langkah spiral khususnya untuk area analisis risiko. F. Model Rapid Application Development (RAD) RAD adalah teknik berbasis tim yang mempercepat pengembangan SI dan menghasilkan fungsi-fungsi SI. RAD menggunakan pendekatan kelompok Produk akhir RAD adalah sistem informasi baru. RAD adalah metodologi yang lengkap, dengan 4 fase siklus hidup yang sejajar dengan fase SDLC tradisional. Penggunaan RAD untuk mengurangi biaya dan waktu pengembangan, dan meningkatkan probabilitas keberhasilan RAD sangat bergantung pada prototipe dan keterlibatan pengguna. Berdasarkan input pengguna, prototipe dimodifikasi dan proses interaktif berlanjut sampai sistem benar-benar dikembangkan dan pengguna puas. Interaksi berkelanjutan antara fase desain dan konstruksi pengguna. Tim proyek menggunakan CASE tools untuk membangun prototipe dan membuat aliran dokumentasi yang berkelanjutan. Gambar 17. Fase dan Aktivitas RAD (Sumber: Shelly, 2012) 1. Requirements Planning a. Fase ini menggabungkan elemen-elemen perencanaan sistem dan fase analisis SDLC. b. Pengguna, manajer, dan anggota staf IT mendiskusikan dan menyetujui kebutuhan bisnis, ruang lingkup proyek, kendala, dan persyaratan sistem. c. Fase ini berakhir ketika tim menyetujui masalah- masalah utama dan mendapatkan izin manajemen untuk melanjutkan. 2. User Design a. Selama fase ini, pengguna berinteraksi dengan sistem analis kemudian mengembangkan model dan prototipe yang mewakili semua input, proses, output. 37

b. Tim/subkelompok RAD biasanya menggunakan kombinasi teknik JAD (Joint Application Development) dan CASE tools untuk menerjemahkan kebutuhan pengguna ke dalam model. c. Desain pengguna adalah kontinyu, proses interaktif memungkinkan pengguna untuk memahami, memodifikasi, dan akhirnya menyetujui model kerja sistem yang memenuhi kebutuhan mereka. 3. Construction a. Fase konstruksi berfokus pada tugas pengembangan b. Program dan aplikasi yang mirip dengan SDLC. c. Pengguna terus berpartisipasi dan masih dapat menyarankan perubahan atau peningkatan saat tampilan atau laporan aktual dikembangkan. 4. CUTOVER a. Merupakan fase peralihan, termasuk konversi data, pengujian, pergantian ke sistem baru, dan pelatihan pengguna. b. Dibandingkan dengan metode tradisional, seluruh proses dikompresi. Akibatnya, sistem baru dibangun, dikirim, dan ditempatkan dalam operasi yang lebih cepat (agile). Tujuan RAD adalah sebagai berikut: 1. Mengurangi waktu dan biaya pengembangan dengan melibatkan pengguna dalam setiap fase pengembangan sistem. 2. Membuat modifikasi yang diperlukan dengan cepat, seiring dengan perkembangan desain. 3. Membatasi biaya perubahan yang biasanya terjadi dalam jadwal pengembangan yang berlarut-larut. 4. Membutuhkan sistem informasi untuk mendukung fungsi bisnis baru, karena digerakkan oleh pengguna. 5. Dengan input pengguna, membantu tim pengembangan merancang sistem yang membutuhkan antarmuka pengguna yang interaktif atau kompleks. Keuntungan dan Kerugian RAD adalah sebagai berikut: Keuntungan utama: sistem dapat dikembangkan lebih cepat dengan penghematan biaya yang signifikan Kerugian: a. Menekankan mekanisme sistem itu sendiri dan tidak menekankan kebutuhan strategis bisnis perusahaan. b. Baik untuk jangka pendek. c. Memungkinkan lebih sedikit waktu untuk mengembangkan kualitas, konsistensi, & standar desain. d. RAD dapat menjadi alternatif yang menarik, jika suatu organisasi memahami risiko yang mungkin terjadi 38

G. Model Scrum Scrum adalah sebuah proses yang agile (tangkas) untuk menangani produk yang kompleks. Scrum digunakan untuk memandu kegiatan pengembangan dalam suatu proses yang mencakup kerangka kerja seperti: kebutuhan, analisis, desain, evolusi, dan pengiriman. Scrum menekankan penggunaan seperangkat pola proses PL yang telah terbukti efektif untuk proyek dengan jadwal yang ketat, perubahan kebutuhan, dan kekritisan bisnis Tahapan kegiatan pengembangan Scrum 1. Backlog a. Daftar prioritas kebutuhan proyek/fitur yang menyediakan nilai bisnis bagi pelanggan. b. Item dapat ditambahkan ke backlog kapan saja (diperkenalkan adanya perubahan). 2. Sprints a. Unit kerja diperlukan untuk mencapai kebutuhan yang didefinisikan dalam backlog yang harus sesuai dengan time box yang telah didefinisikan sebelumnya (biasanya 30 hari). b. Time box adalah waktu yang telah dialokasikan untuk menyelesaikan beberapa tugas c. Tidak diperkenankan adanya perubahan, sehingga anggota tim bekerja dalam lingkungan jangka pendek tetapi stabil. 3. Scrum Meetings a. Waktunya pendek (biasanya 15 menit) tiap pertemuan yang diadakan setiap hari. b. Pertemuan ini membantu tim untuk mengungkap potensi masalah sedini mungkin. 4. Demo Memberikan peningkatan PL untuk pelanggan sehingga fungsionalitas yang telah diterapkan dapat didemonstrasikan dan dievaluasi oleh pelanggan. Gambar 18. Model Scrum (Sumber: Pressman, 2015) 39

Penjelasan Gambar: 1. Gagasan awal adalah bahwa seluruh tim harus diberdayakan untuk membuat keputusan sehingga istilah ‘Manajer Proyek', telah dengan sengaja dihindari. 2. Scrum Master adalah seorang fasilitator yang mengatur a. pertemuan harian b. melacak backlog dari pekerjaan yang harus dilakukan c. mencatat keputusan d. mengukur kemajuan terhadap backlog e. berkomunikasi dengan pelanggan dan manajemen di luar tim 3. Seluruh tim menghadiri pertemuan harian, agar tetap fokus pada tugas masing- masing. 4. Selama pertemuan, semua anggota tim berbagi informasi, melaporkan kemajuan mereka sejak pertemuan terakhir, menjelaskan masalah yang muncul, dan apa yang direncanakan untuk hari berikutnya. 5. Ini berarti bahwa semua orang di tim tahu apa yang sedang terjadi, dan jika masalah muncul, dapat saling membanttu. 6. Semua orang berpartisipasi dalam perencanaan jangka pendek ini. Keuntungan Model Scrum : 1. Produk dipecah menjadi beberapa sub produk sehingga dapat dikelola dan dimengerti. 2. Persyaratan yang tidak stabil tidak menghambat kemajuan. 3. Seluruh tim memiliki visibilitas sehingga dapat meningkatkan komunikasi tim. 4. Pelanggan melihat pengiriman tepat waktu dan mendapatkan umpan balik tentang bagaimana produk tersebut bekerja. 5. Kepercayaan antara pelanggan dan pengembang akan terjalin dimana semua orang mengharapkan proyek untuk berhasil. H. Latihan Post Tes Soal Mandiri dan Tugas Kelompok Pertemuan 3 1. Model proses yang menggunakan pendekatan berurutan (sequential) adalah: a. Model Prototype b. Model Waterfall. c. Model Sekuensial d. Model Spiral e. Model Scrum 2. Kegiatan untuk menterjemahkan design dalam bahasa yang bisa dikenali oleh komputer disebut: a. Coding. b. Debug c. Running d. Compile e. Programming 40

3. Pada model waterfall yang melakukan kegiatan mendeskripsikan pekerjaan untuk mengoperasikan dan memelihara sistmen informasi pada lingkungan produksi (user) termasuk didalamnya implementasi akhir dan masuk pada proses peninjauan adalah tahapan: a. Requirements Analysis and Definition b. System and Software Design c. Implementation and Unit Testing d. Integration and System Testing e. Operation and maintenance. 4. Kerugian dari model RAD adalah: a. Tidak menekankan kebutuhan strategis bisnis perusahaan. b. Sistem dapat dikembangkan lebih cepat c. Waktu yang dibutuhkan untuk penyelesaian sistem cukup lama a. Mengurangi biaya pengembangan sistem b. Anggota tim lebih terorganisasi 5. Model Proses yang tahapannya dimulai dengan dilakukannya komunikasi antara tim pengembang PL dengan pelanggan, adalah: a. Model Prototype b. Model Waterfall c. Model Sekuensial d. Model Spiral e. Model Scrum. Tugas Kelompok Mahasiswa Pertemuan 3: 1. Mahasiswa membuat rancangan pengembangan Perangkat Lunak menggunakan salah satu model proses yang telah dibahas, dengan menjelaskan tahapan-tahapan SDLC seperti pada contoh slide sebelumnya 2. Studi kasus ditentukan oleh Dosen dan tidak diperkenankan mengutip atau menulis ulang dari jurnal/artikel yang ada di internet 3. Dikumpulkan pada pertemuan berikutnya III. Penutup SDLC singkatan dari software development life cycle atau kadang disebut juga system development life cycle. Manfaat yang didapat setelah mempelajari bab ini mahasiswa dapat memilih model SDLC mana yang tepat untuk rekayasa perangkat lunak yang mereka lakukan. Dari beberapa model SDLC yang sudah disebutkan sebelumnya, model spiral merupakan model yang bisa memberikan jaminan kualitas yang paling baik untuk aplikasi berskala besar. Penerapan model spiral ini cocok digunakan untuk suatu proyek dengan target waktu dan biaya yang tidak terlalu ketat. Setiap perubahan spesifikasi pasti beresiko pada molornya waktu pengerjaan dan membengkaknya biaya proyek 41

Daftar Pustaka Buku : 1. Bell, Douglas. 2005. Software Engineering for Students, 4th. London: Addison-Wesley. 2. Booch, Grady. James Rumbaugh. and Ivar Jacobson. 1999. Unified Modeling Language User Guide. Canada: Addison-Wesley. 3. Fowler, Martin. 2004. UML Distilled: A Brief Guide to the Standard Object Modeling Language, 3rd. USA: Addison-Wesley. 4. Indrajani. 2018. Database System All in One Theory, Practice, and case study. Elek Media Komputindo: Jakarta 5. Lethbridge, Timothy C., Robert L. 2005. Object-Oriented Software Engineering, 2nd. London: McGraw-Hill 6. Pressman, Roger S. and Bruce R. Maxim. 2015. Software Engineering: A Practitioner’s Approach, 8th. New York: McGraw-Hill. 7. Rosa, M.Shalahuddin. 2019. “Rekayasa Perangkat Lunak Terstruktur dan Berorientasi Obyek”. Informatika: Bandung. 8. Shelly, Gary B. and Rosenblatt, Harry J. 2012. Systems Analysis and Design. 9th. USA: Boston. 9. Simarmata, Janner. 2009. Rekayasa Perangkat Lunak. Andi : Yogyakarta. 10. Sommerville. 2011. Software Engineering, 9th. USA: Addison-Wesley 11. Suprapto, Falahah. 2018. “Rekayasa Perangkat Lunak”. Lentera Ilmu Cendikia: Jakarta. 12. Utami, Feri Hari. 2015. “Rekayasa Perangkat Lunak”. Deepublish: Yogyakarta Pendukung: 1. Availableat: http://staffnew.uny.ac.id/upload/132315977/pengabdian/ rekayasaperangkatlunak-plpg2012.pdf 2. http://informatikaunindra.org/file/RPL/Diktat/Diktat%20RPL.pdf 3. https://repository.nusamandiri.ac.id/index.php/unduh/item/228647/RPL.pdf 4. https://medium.com/dot-intern/jenis-flowchart-dan-simbol-simbolnya- ef6553c53d73 5. https://www.ansoriweb.com/2020/04/pengertian-component-diagram.html 42