Oke, selamat bertemu dengan saya di materi LPL dengan menggunakan media video ya untuk pertemuan penjelasan materi pertemuan keempat dan kelima. Jangan lupa karena masih musim pandemi, selalu berdoa jaga kesehatan, jaga pola makan, dan juga jaga pola hidup ya, dan selalu bersih. Oke, untuk sumber materi masih sama dengan yang sebelumnya. Nah, materi di pertemuan keempat dan kelima ini, yang pertama adalah paradigma atau model dalam RPL.
Kemudian yang kedua adalah materi HDLC, The Software Development Night Cycle. Dan terakhir adalah materi diagram flow, yang dimana diagram flow ini adalah yang penting. Karena sebagai salah satu tools dalam merekayasa perangkat lunak.
Seperti yang saya jelaskan sebelumnya, selain kalian harus menguasai metode-metode, juga harus menguasai tools-nya dalam merancang merekayasa perangkat lunak. Nah, untuk pencapaian materi di sini, satu adalah kalian nanti harus mampu memahami model-model dalam RPL. Nah, otomatis ya model ini karena sangat banyak, saya hanya akan menjelaskan beberapa model yang bersifatnya umum.
Kemudian yang kedua, kalian juga harus mampu mengimplementasikan kasus ke dalam model. Jadi, ini seri, salah, maksudnya mengimplementasikan kasus ke dalam model itu, karena nanti diterangkan ada model A, model B, atau... Atau kadang disebut juga metode A atau metode B di dalam RPL.
Kemudian ada kasus. Kalian harus mampu bahwa, oh kalau kasus seperti ini adalah yang cocoknya adalah menggunakan model A. Oh kalau kasus seperti ini yang cocoknya adalah menggunakan model B.
Dan pencapaian di materi ini yang terakhir adalah mampu menggunakan diagram flow-nya atau tools-nya. Nah, paradigma ini itu adalah suatu model. Jadi kalau mendengar istilah paradigma dalam RTVL itu adalah suatu model.
Ada juga yang sering menyebutnya metode. Tidak salah juga ya, karena itu bersifatnya umum bahasanya. Nah, kata paradigma sendiri ini berasal dari abad pertengahan di Inggris.
Ini sejarahnya. Jadi biar tahu juga ya, tidak hanya asal... Tahu saja, tapi harus tahu juga asalnya atau akar-akarnya atau bagaimana sih munculnya kalata paradigma ini. Nah, ini sekitar tahun 1483. Paradigma ini berarti suatu model dalam bahasa Yunaninya adalah paradigma, paradikunai.
Yang berarti membandingkan atau bersebelahan atau memperlihatkan. Nah, dari ahli juga Stephen Covey dalam bukunya ini, paradigma itu adalah cara kerja, cara kita memandang sesuatu, pandangan kita atau kerangka acuan atau keyakinan kita. Nah, menurut para ahli yang lain, menurut John Richard, Paradigma ini merupakan salah satu cara pendekatan atau investigasi pada suatu objek dari titik awal dalam menggunakan point of view, formulasi dalam sebuah teori, dan mendesain pertanyaan atau refleksi sederhana.
Garis besarnya di sini saja, paradigma ini salah satu pendekatan atau investigasi pada suatu objek. Menurut Harmon, Ini adalah cara mendasar untuk memahami, berpikir, menilai, melakukan yang berkaitan dengan sesuatu khusus yang realitas. Jadi, kadang kan kalau kalian bagi skripsi, oh ini menggunakan metode atau model dalam RPL-nya apa?
Kamu menggunakan metode apa? Menggunakan model apa dalam RPL-nya? Maksudnya adalah, mengerjarnya adalah ke sini.
Dalam memahaminya, dalam berpikirnya. dalam merancangnya dan sebagainya. Menurut Becker, ini perangkat aturan yang menetapkan atau mendefinisikan batas-batas, menjelaskan bagaimana sesuatu harus dilakukan dalam batas-batas untuk berhasil.
Inilah, jadi kadang apakah penting RPL nanti di skripsi? Jelas, karena akan selalu ditanya menggunakan metodenya apa? Menggunakan RPL? RPL-nya apa?
Menggunakan modelnya apa? Atau ditanya secara teori, paradigma RPL-nya apa? Itu maksudnya adalah kesini. Apakah ini juga akan penting di dunia industri, di dunia usaha, di lapangan kerja? Jelas.
Karena ketika merancang perangkat luna, ketika mereka merancang perangkat luna, itu kan ada tahapan-tahapannya. Nah, tahapan-tahapan inilah yang digabungkan ke dalam suatu model ya nanti kita akan lihat lagi lebih jauh Nah jika disimpulkan paradigma ini adalah suatu model Oke ada juga yang menyebutnya secara umum adalah suatu metode itu tidak salah juga dalam teori untuk ilmu pengetahuan atau kerangka berpikir ya jadi ketika sip Perekayasa, akan perekayasa perangkat lunak Dia akan pasti berpikir Tahapan apa yang harus dilakukan Nah tahapan ini kan bisa ada tahapan A B, C, D Atau bisa juga tahapan itu 1, 2, 3 Atau tahapan itu E, K, C Mana yang akan dipilih Nah yang dipilih ini adalah model-modelnya Metode-metodenya tergantung dari Kasusnya Kemana cocoknya Setiap model yang dikembangkan mempunyai karakteristik sendiri, namun secara umum ada persamaan dari model-model tersebut. Jadi, dari sekian banyaknya model ataupun metode dalam LPL atau paradigma, ada benang merahnya yang sama.
Karena kan tadi tujuannya sama, untuk membuat suatu perangkat lunak. Banyak metode atau model yang harus dipilih, cocoknya kemana, tapi di antara model tersebut ada benang merahnya yang sama. Apa saja itu akan selalu ada mendefinisikan masalah secara jelas. Ini sangat penting.
Kenapa? Bagaimana kita bisa berpikir? Bagaimana kita bisa menganalisis?
Bagaimana kita mengambil suatu kesimpulan? Bila definisi dari kasus tersebut tidak jelas. Ini akan selalu ada, kesamaannya. Karena semakin jelas akan masalah, akan kasus, semakin baik.
Karena akan memudahkan dalam menyelesaikan masalahnya. Dan memilih model yang tepat. Di sini kan, jadi semakin jelas kasusnya. akan semakin baik. Karena apa?
Karena akan mudah dalam penyelesaian masalah dan pemilihan model. Nah, ini kan saya ulang-ulang. Nah, ini jangan sampai kasusnya harusnya cocoknya menggunakan model A, tapi kalian memilih model B.
Itu tidak tepat. Kemudian apalagi benang merah yang sama adalah tahapan-tahapan pengembangan yang teratur. Walaupun banyak model, banyak metode, kesamaannya adalah yang pertama adanya pendefinisian masalah yang jelas, kemudian pengembangan juga yang teratur, terurut. Jadi meskipun model-model pengembangan perangkat lunaknya polanya berbeda-beda, tetapi secara umum akan ada tahapan analisis, akan ada tahapan desain, akan ada tahapan pengkodingan, menguji sampai ke...
pemeliharaannya. Kenapa penting analisis? Kenapa penting desain?
Nanti ada penjelasan tersendiri. Jadi secara umum akan selalu ada tahapan menganalisis, mendesain atau mengkoding, memprogram, menguji, dan juga adanya maintenance. Kemudian akan ada juga yang namanya peran dari user.
Kalian, saya, sebagai perkayasa perangkat lunak. Buat siapa itu digunakan? Untuk user, untuk pengguna.
Jadi akan selalu muncul juga di setiap model itu adalah peran dari user. Kenapa? Karena mereka adalah penggunanya.
Mereka yang membutuhkannya. Pemilik, pengembang, pemogram, dan sebagainya. Dan akan selalu terlibat dalam pembuatan perangkat tunak tersebut. Kemudian akan ada yang namanya dokumentasi.
Ini juga akan selalu ada di setiap model. Karena ini bagian penting dari pengembangan perangkat tunas. Di tahapan dan model, dia akan menghasilkan sejumlah tulisan, diagram, gambar, bentuk, dan sebagainya yang harus didokumentasikan. Jadi dokumentasi ini bukan berarti foto-foto ya. Ada tulisan, diagram, gambar, dan sebagainya.
Dan ini akan tidak bisa dipisahkan. dari perangkat lunak tersebut atau dari pembuatan perangkat lunak tersebut nah model atau metode sekali lagi atau paradigma ini saya ulang-ulang nulisnya karena apa bedanya model metode apa bedanya model metode atau paradigma itu sama saja dipandang dari sisi sudut rekayasa perangkat lunak ini akan sebanyak ada waterfall prototip prototype spiral incremental with and pick for city join application atau cat dan banyak lagi ya karena ini akan terus berkembang saya tidak akan bisa membahas satu persatu dari semuanya ya karena kan harus ada materi-materi yang lainnya Saya akan memberikan contoh beberapa saja yang umum digunakan biar mudah dipahami. Tapi ketika nanti kalian membuat skripsi atau membuat rangka tunak, silahkan pilih yang sesuai. Nah, satu, ini model waterfall. Ini yang sangat sekali banyak digunakan oleh kakak-kakak kalian ketika skripsi.
Tapi apakah itu yang benar? Belum tentu. Karena sekali lagi tergantung dari kasus, dari studi kasus, dari hasil kesimpulan, kesimpulan terhadap permasalahan, apakah cocok kepada waterfall atau tidak. Nah, secara sejarah, saya selalu senang mengungkapkan sejarahnya, jangan sampai tahu ada metode sejarahnya ini bagaimana. Model waterfall ini mulai diperkenalkan.
Winston Royce tahun 1970. Disebutnya ini adalah model klasik yang sederhana dengan aliran sistem yang linier. Berurut output dari setiap tahapan ini menjadi input bagi tahapan berikutnya. Jadi harus ada hasil dulu di tahapan awal karena hasil itu akan menentukan tahapan berikutnya.
Harus terurut. tangga demi tangga, tangga menurun ke bawah, walaupun disini disebutnya sederhana sederhana itu adalah modelnya tapi bukan berarti implementasi penggunaannya nah, ada 5 tahapan utama, dimana setiap tahapan selalu diverifikasi atau diuji jadi, seperti tadi saya bilang harus selesai satu tahap Barus bisa ke tahap selanjutnya Kenapa? Karena output atau hasil dari tahapan awal Itu akan menjadi inputan bagi tahapan berikutnya Contohnya seperti ini Ini pasti tidak asing Jadi tadi ada 5 tahapan 1, 2, 3, 4, 5 Tahapan 1 output akan menjadi tahapan inputan di sini, bagi tahapan kedua output lagi dan seterusnya sampai ke bawah nah ketika ada evaluasi ada maintenance ini pun tidak bisa ujuk-ucuk langsung ke sini, nah ini salah jadi ketika kembali lagi ada pengembangan, ada maintenance ya ini berurut kembalinya lagi ke tahapan mana Jadi kalau kayak gini ini salah. Oke, kita jelaskan.
Tahapan pertama... adalah melakukan analisis nah, intinya di tahap analisis disini adalah analisis permasalahan atau kasus satu sistem yang berjalan Sistem yang berjalan. Kedua, sistem yang dibutuhkan.
Jadi ketika kalian skripsi atau akan membuat satu perangkat lunak, ya dianalisa dulu sistem yang berjalan ini bagaimana. Misalkan ada permintaan tolong dibuatkan aplikasi atau perangkat lunak untuk absensi pegawai, seperti contoh kemarin. Ya kalian harus menganalisa dulu sistem yang berjalan saat ini bagaimana. Jangan-jangan tidak dibutuhkan perangkat lunak.
Jangan-jangan hanya persedul yang salah. Jangan-jangan SDM atau pegawai yang salah. Tidak bisa semua permasalahan harus dimunculkan perangkat lunak.
Tapi ketika memang harus dibutuhkan perangkat lunak, ya secara otomatis kalian akan menganalisi sistem yang sedang berjalan. Siapa orangnya? Dokumen atau berkasnya apa saja, bentuk berkasnya bagaimana, prosedurnya bagaimana, apa kelemahannya, dan sampai permasalahannya apa.
Barulah dimunculkan kebutuhan terhadap sistem tersebut. Aplikasi yang cocok apa, perangkat tundak yang cocok apa, database yang cocok untuk apa, apakah harus online internet atau tidak. perangkat kerasnya juga bagaimana dan seterusnya itu ada peradanya disini nah ini kalian bisa menggunakan konsep 5W1H atau juga bisa menggunakan SWOT SWOT analisis apa itu 5W1H?
ya apa? apa bagaimana siapa dan seluruhnya what why where who how atau SWOT strength weakness opportunity dan trade mana sih yang akan kalian gunakan itu terserah bisa 5w1h ataupun SWOT jangan lupa ada dua sisi mata uang Misal 5W1H, ini kan harus mencengkup 2. Sistem yang berjalan, sistem yang dibutuhkan. Ambil 5W1H-nya apa?
Apa masalahnya? Apa solusinya? Kemudian bagaimana? Bagaimana permasalahannya?
Bagaimana solusinya? Jadi ada 2 sisi mata uang. Makanya di sini kan sistem yang berjalan itu munculnya nanti permasalahannya atau kelemahan.
Kemudian yang dibutuhkan, yang dibutuhkan itu kan solusi. Jadi konsep 5W1H ini akan selalu dua sisi mata uang. Terhadap permasalahan dan terhadap solusi.
Kenapa masalah tersebut bisa jadi? Kenapa solusi tersebut dibutuhkan? Jadi akan ada dua tabel atau dua diagram.
terkait analisis ini sampai detil-detil ke dokumennya kemudian dari sana baru masuk ke perancangan ya disini, jangan lupa sampai disini berhasil tadi kan teori awalnya tahapan awal itu sampai berhasil baru ke tahapan berikutnya, tahapan berikutnya berhasil atau selesai baru tahapan berikutnya Siapa yang menyatakan selesai dua belah pihak? Perekayasa dan user. Jangan menurut kalian sendiri, jangan menurut perekayasa sendiri, karena kita itu membuatkan buat orang. Selesai itu adalah ketika kata user.
Seperti membangun rumah, kita membuat denah, kata pengempat, kata orang yang butuhkan rumahnya, denahnya sudah sesuai, baru kita bisa membuat fondasi. Fondasinya sudah selesai, selesai menurut... Pengembang, vendor, atau kontraktor di rumah tersebut sudah selesai ya. Kondasinya kata yang... Pembeli yang meminta membangun rumah, oke sudah selesai baru kita kebangun.
Sama ini juga. Apa sih yang dirancang di sini? Di sini adalah membuat rancangan menggunakan tools tadi. Apakah rancangannya akan berorientasi kepada objek atau berorientasi kepada prosedur. atau sistem karena ini akan mempengaruhi toolsnya apa ya selain merancang apakah akan merancang subject atau prosedur nanti hubungannya adalah menggunakan UML atau dfd dan seterusnya itu beda lagi materi nanti ke belakangnya kemudian juga disini merancang database ya kemudian merancang merancang diagram-diagram yang dibutuhkan jangan mengkoding dulu kan merancang ini secara klasiknya kita bisa menggunakan kertas atau alat tulis, diperlihatkan kepada user, orang tampilannya seperti ini, bentuknya seperti ini, hubungannya seperti ini oh jika salah, kita coret-coret melihatkan lagi oh betul seperti itu Barulah kita merancang ke yang lainnya, barulah kita mengkoding.
Seterusnya itu di bawahnya nanti. Jadi merancang sistemnya, apakah sistemnya berorientasi objek, atau berorientasi prosedur, atau berorientasi kepada sistem. Ini hubungannya yang ahli adalah seorang analisnya dan juga seorang programmernya.
Kemudian merancang database, merancang interface, kadang logic, algoritma, itu berada di perancangan di sini. Flow, berada di perancangan, dan sebagainya. Ya, sekali lagi, seperti membangun rumah.
Yang di atasnya, di sini, di analisis adalah membangun. Kita diskusi, membangun rumahnya bagaimana, kebutuhannya apa, dibutuhkan bahannya apa, dan goalnya itu bagaimana. Yang merancang ini seperti membangun denahnya, berapa kamar, berapa ruangan, dan seterusnya. Nah, barulah ke tahapan implementasi.
Nah, disinilah kita atau si programmer mulai berjalan. Disinilah source code atau coding. Membangun perangkat lunaknya tersebut berdasarkan rancangan.
Setelah rancangan tersebut selesai, satu kata user dan dua kata kita sepakat. Barulah kita membangun ke source-nya atau... codingnya, membuat programnya nah disini pengujian siapa yang menguji?
otomatis yang pertama adalah yang menguji adalah programmernya itu sendiri, ada bug atau tidaknya kalau banyak timnya yang menguji juga adalah analisnya penanggung jawab proyeknya dan seterusnya, dan yang utama adalah yang menguji adalah user yang menguji adalah user, karena kita membuat itu untuk user, jadi kedua belah pihak, kita sebagai perkayasa dan juga user pengujian ini bisa diuji kecil demi kecil maksudnya adalah blok demi blok interface demi interface pengujian subsistem subsistem atau langsung diuji secara integrasi secara supersistemnya, secara keseluruhannya Contoh, misalkan di kampus kalian membuat aplikasi. Dia diuji kan bisa by interface, interface, interface, atau langsung satu aplikasi. Atau aplikasi itu juga merupakan bagian dari aplikasi yang lainnya. Itu tahapan-tahapan pengujiannya. Ya, secara teori ada black box, ada white box.
Ini isi yang umum dikenal, tetapi sangat banyak metode pengujiannya. Hai selesai diintip diimplementasikan maksudnya diimplementasikan itu dipakai nantinya barulah maintenance ya di sini adalah pemeliharaan ada adaptif ada continue ya adaptif ada continue ada korektif Apakah dimantenenya? Sewaktu-waktu saja atau kok continue secara berkala seperti aplikasi bank itu kan real time ataukah korektif berdasarkan ada kebutuhan saja secara maintenannya. Ya ini bila mana di sini ditemukan ada hal dibutuhkan pengembangan atau ada koreksian, ya kembali lagi apakah harus diuji, apakah di pengujiannya ada yang kurang, ataukah dibutuhkan pengembangan. Atau di tahap pengkodingannya, di tahap perancangannya, sampai ke menganalisa lagi ke tahapan awal.
Nah, itu singkatnya. Atau di gambar yang lain juga seperti ini, ini sama. Waterfall.
Jadi kalau kalian mencari referensi di internet, kok beda-beda gambarnya? Sama saja. Hanya yang membuat blog atau yang membuat website, terjemahkan ke dalam bentuk yang lain untuk mempermudah. yang membaca. Ini kan sama, project planning, perencanaan, requirement, analisis, design.
Design di sini adalah tahapan perancangannya, coding, pengujian, deployment, dibuat, dan seterusnya. Ini kan balik lagi nanti ke sini. Jadi hanya beda menerjemahkannya saja. Nah ini secara penjelasan, secara teorinya tahapan requirement ini apa.
apa yang dibutuhkan analisa kebutuhan, diverifikasi oleh klien, seperti yang tadi dijelaskan. Tahapan desain atau perancangan, membagi kebutuhan menjadi sistem perangkat lunak, dan seterusnya. Implementasi, nah ini kan di tahap kode-kode tersebut, sampai dengan diujinya. Kemudian diintegrasikan, perangkat lunak ini diuji. Yakin menjadi sistem yang lengkap atau tidak?
Memenuhi persyaratan atau tidak? Dan terakhir, di sini adalah pemberiharaan. Sampai dengan apakah ada permasalahan di langkah sebelumnya atau tidak?
Yang tadi gambarnya di bawah lagi, kembali lagi ke atas tahap demi tahap. Oke, kemudian model yang kedua. Di sini ada kelebihan dan kekurangan dulu metode waterfall. Karena ini akan dibandingkan dengan model yang kedua. Nah, kelebihan dari waterfall ini adalah kualitas dari sistem yang dihasilkan akan baik.
Kenapa? Dikarenakan pelaksanaannya bertahap, seperti yang tadi saya jelaskan. Sehingga tidak terfokus pada tahapan tertentu.
Maksudnya bagaimana? Tidak bisa kita konsentrasi dulu ke tahapan yang di bawah sebelum selesai yang di atas. Jadi konsentrasinya satu demi satu.
Tidak bisa kan tadi ada lima tahapan. Tidak bisa kita konsentrasi ke tahapan ketiga tanpa ke satu dan kedua selesai. Kemudian kelebihannya adalah dokumen pengembangan sistem terorganisir.
Karena setiap fase harus diselesaikan dengan lengkap sebelum ke fase berikutnya. Nah, sudah tadi saya berulang menjelaskan. Jadi dokumen di setiap awal itu harus lengkap.
Kemudian bisa digunakan jika suatu persyaratan untuk membuat suatu software sudah dipahami dengan baik dan sudah lengkap semua persyaratan yang ada. Nah, kekurangannya apa? Diperlukan manajemen yang baik, karena proses pengembangan tidak dapat dilakukan secara berulang.
sebelum terjadinya suatu produk. Maksudnya bagaimana? Menggunakan waterfall tidak bisa langsung mengkoding tanpa selesai analisis sistem yang berjalan dan analisis kebutuhan sistem.
Kemudian dari situ kan merancang. Habis merancang baru mengkoding. Mengkoding baru menguji.
Menguji baru diserahkan kepada pihak user dan maintenance. Karena ini kan tidak dapat dilakukan secara berulang sebelum terjadinya suatu produk. Akan sampai selesai aplikasi tersebut. Tahapannya akan begitu. Kemudian kesalahan kecil akan menjadi masalah besar jika tidak diketahui sejak awal.
Maksudnya tadi kata user di tahapan kedua selesai. Kata kita juga selesai. Udah disepakati. Barulah ke tahapan ketiga.
Nah tahapan ketiga ini akan menjadi fatal. Ketika mengkoding, bila bahan dan rancangannya tidak lengkap atau ada yang lupa. Rancangan ini kan berdasarkan analisis. Analisis pun kan tadi harus jelas.
User sulit menyatakan kebutuhan secara eksplisit, sehingga tidak dapat mengakomodasi ketidakpastian pada saat awal pengembangan. Seperti yang saya jelaskan, pelanggan atau user harus sabar karena pembuat perangkat tunak akan dimulai ketika tahap desain sudah selesai. Desain dan perancangan.
Perancangan ini kadang disebutnya include, ketika merancang pasti mendesain. Tapi kalau ke pemahaman saya, merancang itu dalam bentuk dua dimensi. Perancangan itu bisa dalam alat tulis, bisa juga menggunakan komputer, tapi belum bisa dieksekusi. Desain ini akan berhubungan dengan warna, logo, dan seberusnya. Nah itu adalah pemahaman saya, jadi itu terpisah.
Jadi rancang dan desain ya terkadang ini diinkludekan. Tahapan merancang pasti mendesain, sedangkan pada tahap sebelum desain bisa memakan waktu lama, karena analisisnya harus selesai, harus kuat. Waterfall atau air terjun ini harus digunakan hanya ketika persyaratan dipahami dengan baik. Pada kenyataannya jarang mengikuti aturan. Nah ini hanya joke saya.
Sebagai contoh, kadang ada orang membuat dulu aplikasi, membuat perangkat lunak, baru didiskusikan. Seperti, maaf-maaf, salah sebenarnya ketika Anda membuat skripsi, Anda membuat skripsi. Software dulu baru ngebikin rancangannya.
Jadi aplikasi disesuaikan dengan rancangan. Itu harusnya. Jangan rancangan disesuaikan dengan aplikasi.
Karena itu harus match. Seperti ngebangun rumah, apakah ngebangun rumah dulu kemudian denah? Atau denah dulu kemudian rumah? Terkadang ada ya, ngebangun rumah dulu baru ngebikin denah.
Itu salah ya maksudnya. pada kenyataan itu maksudnya adalah job saya candaan saya, karena seringnya seperti itu ada juga seperti itu seharusnya adalah berurut kedua, prototype nah ini sejarahnya atau teorinya jadi sekitar tahun 1960-70 Herbert Walker penemu model prototype Apabila diartikan secara harfiah, metode prototype ini berarti sebuah metode yang digunakan untuk mengembangkan sebuah sistem yang menggunakan prototype. Prototype ini apa? Contoh. Dan juga contoh yang sudah jadi.
Contoh bisa contoh desain atau contoh yang sudah jadi. Namun belum berfungsi secara sempurna sampai terjadinya evaluasi dari berbagai pihak. Contoh gini, kalian tadi misalkan atau dari video kemarin, misalkan kalian dipinta membuat perangkat lunak absensi pegawai untuk di perusahaan A. Udah selesai, udah dibuat, dan dipakai.
Nah kemudian ada permintaan lagi dari perusahaan B. Tolong buatkan perangkat lunak atau sistem atau software untuk absensi pegawai. Nah bisa kalian bawa. Absensi atau aplikasi dipegali di perusahaan A diperlihatkan ke perusahaan B.
Kami sudah buat. Dan contohnya seperti ini. Itu prototipe. Prototipe ini sudah jadi dan sudah dipakai. Atau kalian bisa membuat semacam desain-desain dari aplikasi yang sudah ada atau desain-desain berdasarkan logik kalian.
Kemudian diperlihatkan ke perusahaan B. Itu juga prototipe. Ya, deskripsi pun banyak yang terkait dengan pembuatan alat, yaitu kan prototipe.
Pada dasarnya, prototipe ini ada hubungannya dengan waterfall. Kenapa? Ya kan tadi kan ada benang merahnya yang sama. Nah, jadi makanya di sini secara teori saya jelaskan, dalam melakukan penggambangan sistem dengan menggunakan prototipe, memiliki awalan yang sama pada bagian yang sebelumnya, yaitu analisa sistem dan juga kebutuhan user, ya sudah otomatis, ya di dalam waterfall.
Jadi tetap saja ada yang namanya analisis, merancang, dan seterusnya. Contohnya seperti ini. Sorry, bukan contoh. Diagramnya atau skemanya pada prototype adalah seperti ini. Di sini sama.
Menganalisa atau menganalisis kebutuhan user. Tetap saja ada analisis di sini. Kemudian jadi menyerap apa kebutuhan user. Kemudian quick.
design, yang membuat prototype-nya, mendesain secara cepat berdasarkan hasil analisis di atas ya contoh tadi, di perusahaan B kalian kan sudah membawa contoh dari perusahaan A, oh betul kebutuhannya seperti itu, tapi ada field atau item yang ditambahkan oh betul, tapi tolong field ini dihilangkan, ini tidak dibutuhkan posisinya jangan di kiri button A-nya, tapi posisinya di tengah Nah, sekarang sudah ada prototipe sebelumnya. Sehingga kalian bisa membuat desain secara cepat. Karena sudah ada blueprint dari yang sebelumnya. Ada sampel dari yang sebelumnya.
Pak, kalau belum ada sampel gimana? Nah, tadi kan sudah dijelaskan. Kalian bisa membuat contoh dalam gambar, membuat suatu rancangan interface atau desain interface. Sekali lagi, kalau rancangan itu dua dimensi, kalau desain itu sudah ada warna. dan sebagainya, tapi belum bisa dieksekusi.
Diperlihatkan, kemudian kan dari user, oh ini tidak perlu, ini penting, ini tambahkan A, tambahkan B. Quick design, buat. Kalau sudah selesai di sini, rancangan dan desainnya, barulah buat prototipe-nya. Prototipe sesuai kebutuhan, jangan lupa ya.
Barulah dibuat prototipe sesuai kebutuhan. Nah, di sini, ini bisa balik di sini ke sini. Ketika, kan sekali lagi, setiap melewati tahapan harus selesai juga kata user. Ketika sudah dibuat prototipe-nya, berdasarkan kebutuhan, ada evaluasi, ada kekurangan, bisa langsung balik ke sini. Nah, jadi ini penting.
Kalau sudah selesai berputar di situ, barulah tahap bawah sampai ke membuat produk. Ini pun bisa kembali di sini. Jadi ini hal yang terpisah antara blok A dan blok B. Ini bisa lebih cepat, tapi jangan lupa tergantung juga kebutuhan dan kekurangannya.
Kalau waterfall itu untuk kebutuhan yang sangat besar lingkupnya. Karena itu dibutuhkan ketelitian yang sangat besar kebutuhannya itu cocoknya menggunakan waterfall dan kompleks. Kalau prototipe ini bisa lebih cepat, tetapi apakah untuk kebutuhan yang lebih besar kurang tepat? Prototipe ini adalah model metode untuk kebutuhan yang bersifatnya lingkup-lingkup tertentu saja, persub-sub saja.
Kalau waterfall itu bisa... lingkupnya yang sangat besar. Bila digambarkannya seperti ini, requirement gathering, quick design, prototype, evaluasi customer, refining, kalau ada yang dibutuhkan, dihilangkan, atau tidak dibutuhkan, dibuang, bisa langsung, kemudian sampai ke engineer product, dibuatnya satu produk aplikasi tersebut.
Ada juga yang digambarkannya seperti ini, Planning, requirement and analysis, design, construction, testing, deployment. Jadi, bisa muncul gambarnya seperti apa, tetapi itu adalah tetap metode atau model prototype. Bila digambarkan dalam bentuk lain, seperti ini juga.
Jadi, jangan heran, kok mana yang gambarnya yang benar? Banyak sekali para ahli. termasuk saya kadang membuatnya dalam bentuk gambarnya yang lain tapi tujuannya sama nah ini kan startnya dari sini kemudian quick design, bleed, evaluasi, refining prototype, bisa quick design balik lagi ke sini dan terus berputar sampai dengan selesainya dibuatnya produk tersebut nah ini juga ada penjelasannya secara teori Kebutuhan sistem kan, pelanggan atau user.
Bersama-sama mendefinisikan format seluruh kebutuhan perangkat tunaknya itu seperti apa. Dan garis besar sistem yang akan dibuat. Dan garis besar. Kenapa?
Karena prototipenya itu kebutuhannya seperti apa. Baru membangun prototipenya. Membuat perancangan sementara.
Nah disini kan garis bawahnya sementara. Seperti tadi yang saya jelaskan. Contohnya, membuat input dan output.
Oh, gambarnya kayak gini, rancangannya kayak gini. Yang diinput itu terlalu nim, nama, jabatan, jam masuk, jam keluar. Betul, oh berarti nanti outputnya seperti ini.
Masuknya jam sekian, keluarnya jam sekian, jabatannya apa, laporannya dalam bentuk tabel, kolom, atau dalam bentuk baris, dan seterusnya. Itu kan cepat. Baru dia evaluasi, apakah prototipe yang dibangun sudah sesuai dengan keinginan user atau tidak. Jika sudah sesuai, maka langkah keempat akan diambil. Jika tidak, prototipe direvisi dan mengulang langkah 1, 2, 3 yang tadi saya buletin.
Kalau 1, 2, 3 sudah dianggap selesai oleh user dan oleh kita, baru masuk ke 4. Tadi kan saya ngebuletin ada 2. Barulah mengkodekan sistem. Dalam tahapan ini, prototyping sudah disepakati. Prototypenya sudah disepakati.
Barulah diterjemahkan ke dalam bahasa pemograman yang sesuai di tahapan keempatnya tadi. Kan tadi 1, 2, 3. Tahapan selesai. Barulah dibuat secara seutuhnya. Baru menguji. Bisa whiteboard atau blackboard.
blackbox ini whitebox dan blackbox nanti ada tahapan materi tersendiri atau pengujian secara arsitektur dan sebagainya baru diavaluasi user mengevaluasi apakah sistem yang sudah jadi sesuai dengan harapan atau tidak jika iya dilakukan langkah ke-7 atau langkah terakhir jika tidak ke-4 dan ke-5 balik lagi barulah sistem bisa digunakan dan diterima oleh user atau pelanggan ya Kenapa sih kelebihannya? Karena ini membuat contoh, bisa langsung interaksi dengan user, dengan pelanggan. Komunikasinya bisa lebih dekat.
Nah, kalau tadi waterfall kan harus analisisnya tahap demi tahap secara detail. Kalau ini komunikasi bisa dijalinkan dengan baik. Ya, karena kan link-upnya juga untuk tertentu-tertentu saja.
Kemudian setiap perbaikan yang dilakukan oleh prototipe, hasil masukan dari user yang akan menggunakan sistem tersebut sehingga lebih fleksibel dan jelas. User akan memberikan masukan terhadap user sesuai dengan kemauannya, karena interaksinya lebih dekat. Hemat waktu, hemat biaya, terutama pada bagian analisis, karena hanya mencatat poin-poin penting saja.
Jadi kurang detail dibandingkan dengan waterfall. Cocok digunakan pada sebuah sistem yang digunakan pada ruang lingkup tertentu. Jadi, kalau di kampus, oh ini hanya untuk absensi mahasiswa saja, absensi dosen saja, oh ini hanya untuk nilai saja.
Bukan lingkup yang besar untuk satu kampus atau satu jurusan. Makanya dianggapnya lebih mudah. Kelemahannya?
Nah ini kan kebalikannya. Terlalu singkat, tidak cocok pada sistem yang sangat besar. Mereka berbeda, kurang cocok untuk kasus yang besar. Pemakai atau user mungkin tidak menyadari bahwa versi tersebut dibuat tanpa memperhatikan kualitas.
Bukan berarti tidak jalan, bukan berarti tidak bisa digunakan. Tapi mungkin kelemahan atau kualitasnya kurang, karena kedetilannya itu kurang. User atau pengembang atau perkayasa membuat kompromi implementasi dengan menggunakan sistem resi yang tidak relevan atau algoritma yang baik. Dari sisi keamanannya juga kurang. Oke, selanjutnya adalah metode spiral.
Nah, metode spiral ini adalah pendekatan alternatif diusulkan oleh Bohem 1968. Bohem ini mengusulkan sebuah model secara eksplisit. Di masukannya ada resiko yang disadari mungkin membentuk dasar model pada umumnya. Dengan kata lain, ada plus. resiko disitunya model yang disediakan bom ini berbentuknya spiral ya dan model proses RPL evolusioner merangkai sifat adanya pengulangan dari prototipe ini gabungan ya jadi ada perputaran ada juga yang bersifat yang namanya Spiral, kayak obat nyamuk contohnya, atau kan muter, ada pengulangan. Kita lihat.
Jadi, ini kan berputar terus, sesuai arah jarum jam. Blok 1, blok 2, blok 3, blok 4. Jadi selain ada tahapan analisis, desain, dan merancang, ada pengujian, di sini adanya masuk, adanya resiko, ada analisis resiko. Ini kan ada prototipe juga kan?
Nah ini ibaratnya penggabungan antara waterfall, prototipe, munculah di sini ada yang namanya analisis resiko. Startnya kan dari sini Disinilah tahapan-tahapan Analisis Sampai mendetil Disinilah munculnya ada analisis Risiko Berdasarkan prototipe-prototipe yang sudah dibuat Terjadi evaluasi Barulah lari Ketahapan Simulasi, benchmark, detail design, pengujian, coding, integrasi, persetujuan, sampai dibuat, dirilis tahapan terakhir. Ini pun sampai dengan analisis kebutuhan terhadap pengembangannya, plan pengembangannya.
Jadi, perbedaannya di mana? dimunculkannya disini adalah tahapan analisis resikonya tahapan yang lainnya garis besarnya sama benang merahnya pasti sama jadi sehingga bila mana dibutuhkan pembuatan perangkat lunak yang sangat besar dan banyak sekali resiko yang harus diperhitungkan inilah yang digunakan yang tepat bisa juga kan digambarkan seperti ini tadi 1, 2, 3, 4 ini kan sampai Next iteration atau plan, ini semakin jelas, semakin berwarna, requirement di sini, sampai ke development plan-nya itu bagaimana, risiko analogisnya bagaimana, prototype-nya, konsep atau requirement-nya, drop, sampai ada drop, detail design, coding, integrasi, testing, implementasi, sampai terlahirnya perangkat lunak. banyak sekali gambarnya apabila dicontohkan jadi kalian nanti memahaminya memakai gambar yang mana itu silahkan sama saja tahapan secara umum ini komunikasi dengan user atau peranggan perencanaan, nah ini kan muncul analisis risiko kalau yang satu, kedua itu umumnya sama dengan yang di awalnya disini muncul istilah project karena ini kan Sifatnya lebih besar dan ada resiko.
Pemprekayasaan sampai dengan diluncurkannya aplikasi atau produk, sampai ke evaluasi dan umpan balik dari user. Nah kelebihannya apa? Disesuaikan agar perangkat undang bisa dipakai selama mungkin.
Cocok pengumuman resiko yang skala besar dan memiliki resiko. pengembang dan pemakai juga lebih mudah memahami dan bereaksi terhadap risiko setiap ditingkatan evolusi atau prototipe menggunakan prototipe sebagai mekanisme kurangan resiko jadi dibuat dulu prototipe begini oke ada kekurangan ada kelemahan balik lagi prototipe kedua prototipe ketiga dan seterusnya ya Tetap mengikuti langkah-langkah dalam sikus kehidupan klasik, maksudnya kehidupan klasik ini adalah yang model klasik, yang waterfall, pertimbangan yang langsung terhadap resiko teknis, sehingga mengarangi resiko sebelum terjadi permasalahan, kelemahannya apa. Sulit untuk mengingatkan kepelangan bahwa pendekatannya polusional ini bisa dikontrol, terus memerlukan penaksiran resiko yang masuk akal.
Karena kan bisa saja user itu adalah orang yang tidak memahami IT. Ada risiko mayor dan minor, kecil dan besar. Butuh waktu lama untuk menerapkan paradigma ini menuju kepastian yang absolut.
Nah ini tiga model yang tadi. Tiga metode yang sering umum, yang sangat sering digunakan. Oke, selanjutnya adalah flow map.
Ini adalah flow yang akan sangat sering digunakan dan akan menjadi tugas juga buat kalian. Apa sih flow map? Nah, ini secara sejarahnya peta atau flow.
yang menunjukkan penggerakan benda dari satu lokasi ke lokasi yang lain dalam suatu sistem. Dimana sejarahnya selalu saya menyisipkan hal seperti ini. Jadi pada tahun 1990, Tom de Zonk dari Universitas di Belanda mulailah mengembangkan aliran barang dan juga manusia di petak. Ada makro sosial, ada manusia.
Ada manusia, ada tiga manusia, barang itu sudah sampai mana? Nah, itu contohnya. Jadi gabungan antara peta dan juga plot chart yang menunjukkan penggerakan benda. Nah, yang di RPL di sini terkait benda itu apa?
Umumnya adalah dokumen. Ini adalah pedoman umum dalam membuat flow map. Nah, ini seorang analis atau programmer akan membuat flow map.
Ada beberapa petunjuk yang harus diperhatikan. Apa saja digambarkan dari halaman atas ke bawah, kiri ke kanan. Atas, ke bawah, kiri, ke kanan. Atas, ke bawah, kiri, ke kanan.
Jangan lupa. Aktivitas yang digambarkan harus didefinisikan secara hati-hati. Dan definisi ini harus didapat dan dimengerti oleh pembacanya.
Kenapa sih harus begitu? Ini akan digunakan oleh user, oleh pembaca flow tersebut. Harus mudah dipahami.
Kemudian kapan aktivitas dimulai dan berakhir harus ditentukan secara jelas. Start and mulai, terse. Itu harus jelas. Setiap langkah dari aktivitas ini harus berada pada urutan yang benar.
Sudah pasti ya. Lingkup dan rank dari aktivitas yang sedang digambarkan harus ditelusuri dengan hati-hati. Gunakan simbol-simbol plot chart yang standar. Ini simbolnya, bisa kalian baca, atau umum sekali, dicari juga di dunia internet juga banyak.
Terminator, input-output, disk, operasi, display, archive, connector, kondisi atau seleksi, ini sangat umum. Ya, garis. Nah ini jangan lupa, bila ada yang bersinggungan, bila ada yang bersinggungan, gunakan lengkungan. Jadi terlihat, lebih bagus pakai warna yang berbeda.
Jadi jangan bersinggungan kayak gini. Nah ini kan bingung, ini ke sana atau ke bawah. Jadi ketika ada singgungan garis, gunakan lengkungan seperti ini.
Kalau kayak gini ini salah. Jadi terlihat itu garisnya arahnya kemana. Contoh implementasi flow map. Ini orang, ini orang, ini aplikasi. Bisa juga, ini orang, ini aplikasi.
Mulai, melengkapi formulir, simbol dokumen. dan seterusnya entitas eksternal disebutnya entitas internal kenapa ini eksternal? karena ini orang luar daftar kan, pendaftar datang judulnya kan pendaftaran anggota perpustakaan orang luar datang berarti kan orang luar, eksternal petugas, ini orang Berada di dalam yang menggunakan sistem. Bisa model seperti ini.
Nah ini kan tadi harus jelas. Mulai, selesai. Aliran datanya, aliran sistemnya jelas. Mulai, merangkapi formulir, formulir pendaftaran, meng-entry formulir oleh petugasnya, mengecek lengkapan sistem, isian lengkap atau tidak.
Tidak, balik lagi ke pengisian Jika lengkap, simpan data formulir Masuk database, kartu cetak Kata cetak kartu anggota Dia dapat, selesai Ini berarti gabungan antara aktor internal Atau entitas eksternal Dan internal, sama aplikasi Ya, ada tiga Contoh yang kedua Sorry Entitas internal dan entitas eksternal saja. Pelanggan, pelayanan, internal, internal semua. All internal. Mulai, datang showroom, melihat VCD atau DVD, menjawab VCD, dan seterusnya.
Ini garisnya kan harus jelas. Jadi bisa ada gabungan dengan sistem, ada juga hanya aktor orang dan orang saja. Yang membedakan adalah internal mana, eksternal mana.
Interaksinya yang terlihat berdasarkan garisnya. Hubungan antar dokumen atau antar datanya. Contoh juga seperti ini tadi.
Sistem informasi rawat jalan. Pasien, internal atau eksternal. Petugas pendaftaran internal atau eksternal, dokter internal atau eksternal, ketua yayasan internal atau eksternal. Dan ini ada simul-simul ini berarti konektor.
Mana yang internal, mana yang eksternal. Nah ini kan pasien pasti dari luar. Petugas pendaftaran pasti orang berada di poliklinik.
Dokter berarti ada di poliklinik. Ketua yayasan, ini ketua yayasan bisa aja di pihak eksternal. Jadi kalau ini orang luar, ini poliklinik, kemudian ini yayasan.
Ini kan berarti eksternal, ini internal, ini eksternal. Kalau ketika dianalisis yayasannya berada di dalam poliklinik, ya berarti yayasan tersebut adalah internal. Jadi kalian harus bisa menganalisa seperti itu, dan bagaimana aliran dokumennya, aliran datanya. Sehingga ketika orang membaca suatu flow, Mudah dipahami, ini contoh tools dalam RPL untuk memperlihatkan hubungan antar entitas.
Entitas itu adalah bisa berupa orang ataupun aplikasi secara flow tadi, dan dokumennya alirannya bagaimana. Jadi, ini contoh kecil membuat suatu perancangan sebelum menjadi perangkat lunak. Harus jelas dulu, user itu harus sepakat betul aliran datanya seperti itu, aliran dokumennya seperti itu. seperti itu, harus sepakat aplikasi untuk membuat flow map sangat banyak sangat banyak sekali bisa visio, dia graph, word pun ini bisa dan lain-lain ini tak terhingga pakai alat tulis pun bisa nah itu saja materi RPL yang saya sampaikan di video ini mudah-mudahan kalian bisa paham dan pasti setiap video atau setiap materi akan selalu ada tugas tugasnya nanti akan muncul di Microsoft Form ataupun menggunakan assignment oke selesai jadi bila disimpulkan tadi saya sudah memberikan materi model itu apa, paradigma itu apa atau metode itu sebenarnya sama di dalam RPL Kemudian saya memberikan 3 contoh model atau metode.
Kalian harus bisa membedakan antara 3 itu. Kasusnya untuk yang seperti bagaimana, perbedaannya apa, kelebihannya apa, kekurangan apa. Dan di dalam membuat perangkat lunak, pasti akan selalu ada model atau metode yang akan digunakan. Dan di dalam langkah-langkah metode tersebut ada yang namanya tahapan perancangan.
Menggunakan tools minimal. Tadi saya sudah mengajarkan yang namanya flow. Dari flow itu, dari flow map itu nanti akan masuk ke dalam diagram yang lainnya.
Nah, itu akan saya jelaskan di pertemuan-pertemuan selanjutnya. Jadi, saya hanya baru memberikan satu contoh menggunakan tools di dalam perangkat lunak. Yaitu baru flow map.
Nanti akan ada lagi sampai ke data flow diagram, kontek diagram, sampai dengan nanti berorientasi kepada objek yaitu... Oke, sampai sini dulu materi yang saya sampaikan menggunakan media video ini, sampai ketemu di pertemuan selanjutnya.