Assalamualaikum warahmatullahi wabarakatuh Kali ini saya akan melanjutkan materi kedua kita di mata kuliah rekayasa perangkat lunak Materi hari ini kita akan mencoba membahas model proses perangkat lunak Kalau kemarin itu kita sudah mengenal apa itu rekayasa perangkat lunak Di dalam rekesa perangkat lunak ada banyak aktivitasnya. Aktivitas tersebut ada model-model aktivitasnya, ada model-model prosesnya. Hari ini kita akan belajar model proses tersebut. Jadi tema hari ini, apa sih model proses perangkat lunak?
Kemudian dari model tersebut ada namanya model waterfall. Ada incremental development, ada reuse-oriented software engineering. Model waterfall tadi model air terjun.
Kalau incremental development yaitu pengembangan secara berurutan. Kalau reuse-oriented, rekayasa perangkat lunak yang berorientasi penggunaan kembali. Kemudian pemilihan model proses perangkat lunak, bagaimana kita nanti memilih model-model yang sudah dijelaskan sebelumnya. Pertama adalah pengertian mode proses perangkat lunak. Ada yang mengatakan mode proses ini adalah SDLC, System Development Lifecycle.
Dari artinya saja kita bisa tahu, System Development Lifecycle, alur, Lifecycle ini adalah alur. sistem development, alur pengembangan. Makanya saya kurang suka menggunakan istilah SDLC, karena yang namanya RPL tidak hanya di pengembangan saja, tapi sampai dokumentasi, sampai di bagaimana manajerial, dan lain sebagainya.
Seperti sudah dikatakan di pertemuan sebelumnya, RPL itu tidak hanya... pengembangan tapi ada yang mengatakan SDLC seperti ini tapi intinya proses yang berlaku di dalam RPL atau serangkaian aktivitas terkait yang mengarah pada proses produk perangkat lunak jadi dia itu semua aktivitas yang berhubungan dengan proses pada produk perangkat lunak dari proses awal sampai proses akhir sampai proses evolusi, semua hal Itu dibahas di model ini. Setiap model proses mengakili proses dari sudut pandang tertentu.
Model umumnya ada tiga. Tadi yang sudah dikatakan di subtema tadi, pertama adalah model waterfall atau air terjun. Tapi enaknya kita ngomong waterfall saja ya. Ada incremental development, pengembangan secara berurutan. Ada reuse-oriented software engineering, rekayasa perangkat lunak berorientasi penggunaan kembali.
Ada banyak model selain ini, tapi model umumnya atau generic modelnya adalah tiga ini di dalam rekayasa perangkat lunak. Jumat model ini tidak sama dengan deskripsi definitif proses perangkat lunak. Tapi model-model ini adalah abstraksi dari setiap proses dengan pendekatan berbeda untuk mengembangkan perangkat lunak. Jadi abstraksi dari proses pemodelan perangkat lunak itu pakai model-model yang ada ini.
Bukan model ini adalah proses pengembangan perangkat lunaknya. Bukan, tapi ini adalah abstraksinya. Oke, saya lanjut.
Jadi nanti yang akan kita bahas adalah tiga ini. Pertama, model waterfall. Model waterfall, dia itu plan driven process.
Proses yang sudah benar-benar direncanakan secara matang. Jadi, time schedule-nya jelas, alurnya itu runut, semua itu sudah direncanakan siapa yang mengerjakan ini. kapan, bagaimana, semuanya jelas setelah direncanakan sebelumnya.
Setiap proses dilakukan terpisah dan berurutan. Ini adalah model klasik yang paling sering digunakan... Dan terjamin keandalannya, ini adalah kelebihan dari model waterfall, terjamin keandalannya karena walaupun dia klasik modelnya, tapi sangat tandal dalam membuat dalam, bukan membuat sih, dalam proses kehidupan perangkat lunak itu. Setiap tahapan memiliki satu atau lebih dokumen yang disetujui atau sign off.
Nanti saya kasih tau kenapa sih harus disetujui dan disetujui oleh siapa. Model waterfall, nah ini gambarnya. Tahapan-tahapannya, alur proses dari model waterfall.
Pertama kita definisikan kebutuhan. Kebutuhan di sini adalah apa sih yang dibutuhkan oleh pelanggan. Apa sih yang dimau...
oleh pelanggan sistemnya itu maunya seperti apa kebutuhan sistem itu seperti apa pelanggan kita itu mau dibuatkan sistem yang seperti apa Nah di sini kita ada namanya fase definisi kebutuhan fase berikutnya adalah desain sistem dan perangkat lunak kita desain sistemnya dan perangkat lunaknya setelah kita tahu kebutuhan pelanggan kita desain sistemnya Setelah dilakukan desain, baru dilakukan implementasi dan pengujian unit. Implementasi ini kita ngoding, pengujian unit ini bagian-bagian unitnya kita uji di dalam level developer, baru integrasi dan pengujian sistem. Semua unit-unit tadi diintegrasikan jadi satu, baru diuji secara sistem keseluruhan. Setelah itu dilakukan operasi dan perawatan.
Nanti operasi ini kita taruh ke klien, kemudian kita lakukan perawatan. Nah, dari gambar ini, dari fase awal lanjut ke fase-fase berikutnya, gambarnya seperti ini. Makanya orang-orang mungkin menamakan menjadi model waterfall karena bentuknya seperti air terjun.
Tetapi pada fase operasi dan perawatan ini bisa jadi dia kembali ke definisi kebutuhan. Kan di fase akhir dari aktivitas perangkat lunak ada namanya evolusi. Oh bisa ada perubahan kebutuhan, oh ada yang kurang. Kurangnya itu ada di bagian definisi kebutuhan. baru kita definisikan ulang kebutuhan, baru lanjut ke desain sistem, implementasi, integrasi, baru dioperasikan.
Oh ternyata ketika pada pengoperasian di lapangan, kayaknya ada kesalahan atau kekeliruan ketika kita melakukan desain sistem. Di sini bisa kembali ke desain sistem. lalu turun lagi gitu blok dan Oh ada salahan ketika implementasi bisa jadi kita lanjut ke implementasi dulu baru ke sini lagi atau di bagian integrasi yang salah Nah jadi ini adalah gambaran secara umum model waterfall itu kita definisikan kebutuhannya si klien itu mau bikin perangkat lunak atau sistemnya seperti apa lalu kita desain sistemnya setelah kita desain kita implementasikan kita uji perbagiannya baru kita integrasikan semuanya kita uji sistemnya sesuai apa tidak dengan kebutuhannya tadi ini pengujian ini baru kita implementasi dan perawatan Gambaran gampangnya begini, kalau saya analogikan ke satu bangunan, rumah deh. Di fase ini, kita konsultasi ke orang, kita itu mau bikin rumah yang seperti apa?
Hai kalau sudah selesai Oh saya mau bikin rumah yang begini begini begini ada saat ada dua lantai setiap lantai itu ukurannya ukuran lantai pertama itu misalnya 10 kali 20 lantai kedua itu 10 kali 10 di lantai pertama itu ada lima kamar ada lima kamar tidur ada dua kamar mandi ada satu dapur dan sebagainya kemudian Kemudian, setelah itu didesainlah rumah kita. Siapa sih yang bertindak di sini? Desainnya ini bisa jadi arsitek atau dari orang-orang teknik sipil.
Oh iya, ada yang miss di sini tadi. Apa yang kita mau tadi dibuatlah dokumen. Misalnya dokumennya bentuknya itu seperti kontrak.
Kita mau bikin rumah seperti apa? Nanti ada dokumen yang kita tandatangani, yang disetujui oleh developer dan kitanya yang minta sebagai klien. Setelah itu, dari dokumen yang kita selesaikan tadi, baru didesain oleh arsiteknya. Oh rumahnya nanti begini loh, kalau berdasarkan mau si pengguna. Begini gambarnya.
Nanti dikonsultasikan ke pengguna, setuju apa tidak? Kalau pengguna setuju. baru lanjut ke implementasi kita bangun rumahnya mereka bangun bukan kita mereka bangun rumahnya mungkin mereka bangun dulu bagian ada fondasinya setelah fondasinya bangun mereka uji langsung kuat nggak fondasinya setelah kuat baru bangun tiangnya mungkin ya saya kurang tahu untuk Hai bikin bangunan bikin tiang kuat enggak selati yang kuat baru bikin temboknya baru diuji lagi temboknya sampai semua selesai baru diintegrasi dan pengujian sistem kita integrasi semuanya jadi satu kalau dibangun akan otomatis jadi satu kalau di software bisa jadi terpisah nanti pembangunannya kalau dibangun jadi satu Jadi blok satu rumah diuji apakah rumah yang sudah jadi ini sesuai dengan yang diinginkan oleh klien tadi yang di bagian sini. Apakah sudah sesuai? Jika sudah sesuai baru diserahkan kuncinya ke kita sebagai pelanggan.
Kita serahkan. Kemudian ketika kita mendiami rumah tersebut. Ternyata ada tembok yang retak, ada tembok yang ternyata tidak kuat, tidak sesuai dengan kebutuhan yang sudah didefinisikan tadi. Berarti kita cari nanti si developer masalahnya itu di mana?
Apakah masalahnya waktu kontrak awal ini tidak sesuai atau keliru? Apakah masalahnya itu ada di bagian desainnya? Ternyata desainnya itu...
tidak memadai atau ternyata kesalahan itu ada di implementasinya Oh ternyata tukang ini ngurangin ngurangin semen atau pasir misalnya Oh ternyata misalnya ada di sini kesalahannya kembalilah dia ke sini baru setelah diperbaiki dilakukan integrasi lagi baru dikerja di serahkan ke pemiliknya lagi nah itu model waterfall ini alur-alur yang tadi dianalisis kebutuhannya luarannya nanti ada spesifikasi sistem layanan sistem batasan dan tujuan sistem nanti spesifikasi perangkat lunaknya akan saya jelaskan di materi-materi berikutnya desain sistem perangkat lunak arsitektur sistemnya abstraksi sistem perangkat lunak, dasar dan hubungannya jadi nanti arsitektur sistem ini mungkin sekalian sudah belajar di arsitektur komputer mungkin bisa jadi itu adalah bagian dari arsitektur sistem karena sistem ini bukan cuma perangkat lunak loh ya sistem ini terdiri dari perangkat lunak, perangkat keras kemudian ada orang yang menggunakan kemudian Ada orang yang memperbaikinya, ada orang yang membangun, itu adalah sistemnya. Orang yang menggunakan itu pun bisa macam-macam, ada lebih dari satu jenis mungkin. Abstraksi sistem perangkat lunak, dasar dan hubungannya. Nanti ini bisa jadi dokumen-dokumen berbentuk diagram-diagram. Kalau di pemogram menter struktur ada namanya DFD, ada namanya flowchart, ada namanya konteks diagram.
Kemudian implementasi pengujian unit, sistem dan verifikasi setiap unit memenuhi spesifikasi sistem, integrasi dan pengujian sistem. Integrasi semua unit dan diuji sebagai sistem utuh. Dan dikirimkan ke pelanggan, dikasihkan ke pelanggan baru ada operasi dan pemeliharaan. Sistem dipasang dan digunakan secara praktis. Pemeliharaan menyebabkan koreksi kesalahan.
Nah tadi kita, saya logikakan rumah, ada koreksi kesalahan pada rumah tersebut. Jadi ini adalah 5 fase di model waterfall. Dia itu tidak berhenti sampai sini saja, makanya ada orang yang mengatakan SDLC tadi, alur hidup sistem, pengembangan sistem.
Karena alur hidup dari awal hidup sampai mati, sampai terakhir, fase terakhir, terus kembali lagi ke asal. Yang namanya alur itu kan selalu mengulang. Oh dari 1, 2, 3, 4, 5, 1, 2, 3, 4, 5, 1, 2, 3, 4, 5 selalu berulang tidak pernah berhenti. Itu namanya life cycle. Kemudian kelebihan model waterfall tadi kan ada 3 macam.
3 macam yang generic modelnya. Hai muda ini cocok untuk sistem yang spesifikasi kebutuhannya sudah jelas dan tidak memiliki banyak perubahan jadi kita sudah bikin kita minta bikin rumah dua lantai dengan total lima kamar di bawah satu kamar di atas dua kamar mandi di bawah satu kamar mandi di atas ternyata kliennya berubah lagi nih enggak mau saya mau satu lantai aja kamarnya digabung di bawah semua misalnya begitu nah perubahan-perubahan seperti ini tidak dapat di cover oleh mode waterfall makanya di waterfall itu dikatakan nandal karena di awal dia itu sudah ada perjanjian atau kontrak dengan si klien ketika kita sudah diminta bikin rancang bangunan seperti tadi terus kita minta berubah, tidak bisa karena kita sudah menekan kontrak bahwa kita mau bikin rumah yang seperti tadi itu, tidak bisa dirubah-rubah lagi. Model ini juga banyak digunakan pada sistem besar yang dikerjakan secara terpisah di banyak tempat. Jadi untuk sistem yang besar sangat cocok kalau kita menggunakan model waterfall, apalagi sistem besar itu biasanya dikerjakan secara terpisah. Kelemahannya, setiap fase dilakukan jika fase sebelumnya sudah selesai.
Jadi kita tidak mungkin mulai ngoding kalau spesifikasi kebutuhan belum selesai dan desain perangkat lunak belum selesai. Kita tidak mungkin mulai desain kalau spesifikasi kebutuhannya belum selesai. Jadi harus selesai satu dulu baru yang lain.
Jadi nanti waktunya akan lebih lambat. Sulit mengakomodasi perubahan. Spesifikasi kebutuhan perangkatunan harus lengkap dan terdefinisi di fase awal. Sangat sedikit sistem yang spesifikasi kebutuhannya sudah jelas di fase awal. Terkadang di fase implementasi, programmer menemukan desain yang tidak sesuai, akan tetapi tidak bisa kembali ke fase desain.
Makanya di mode waterfall biasanya digunakan oleh developer-developer besar. developer yang sudah punya pengalaman yang tinggi sehingga di fase awal tadi misal dari spesifikasi kebutuhan orang-orangnya ini, sistem analisnya ini mereka bisa menganalisis dengan tepat apa sih kebutuhan yang diminta oleh pelanggan atau customer-nya kalau sistem analisnya ini punya pengalaman yang tinggi dan dia tahu bagaimana cara nge-loading, dia bisa membayangkan lokal, dia bisa menjembatani antara apa yang dimau oleh pengguna dengan apa yang dimau oleh, ada apa yang bisa dilakukan oleh programmernya. Nanti materi ini akan kita bahas tersendiri di pertemuan-pertemuan berikutnya.
Jadi setiap fase itu harus terdefinisi apalagi paling utama di fase spesifikasi kebutuhan. Kalau di spesifikasi kebutuhan ini nggak jelas, ke bawah-bawahnya pasti nggak jelas lagi. Tadi itu model waterfall, sekarang masuk ke model incremental development, pengembangan secara berurutan.
Sistem ini dikembangkan sebagai serangkaian versi, increments, berurutan, dengan setiap versi menambahkan fungsionalitas ke versi sebelumnya. Pada mode ini, perangkat lunak dibangun dalam versi kecil-kecil. Setiap versi terdiri dari aktivitas, spesifikasi, pengambangan, dan validasi.
Jadi dia ini mengembangkan perangkat lunak secara bertahap. Sehingga lebih murah dan lebih mudah untuk melakukan perubahan. Jadi incremental development ini adalah jawaban atas perubahan dari yang tidak bisa ditangani oleh model waterfall.
Bedanya, kalau incremental development, ada deskripsi sistem. Sistem yang dimau itu seperti apa? Langsung dikembangkan. Kita cek spesifikasi kebutuhannya.
Kembangan lagi. Validasi. Kembangan lagi. Dan ini, kegiatan ini bisa dilakukan secara bersamaan. Proses-proses yang tadi.
Jadi proses-proses seperti spesifikasi kebutuhan, desain perangkat lunak. dan implementasi semuanya itu ada di sini secara bersamaan tapi bagian kecil aja jadi satu muncul versi awal nanti versi awal dikoreksi lagi oleh kita sebagai klien bahwa setelah dikoreksi ada Hai perubahan atau ada penambahan kita serahkan lagi ke pengembangan dilakukan spesifikasi kebutuhan delapan validasi secara bersamaan muncul versi-versi lain versi menengah versi kedua misalnya terus dilakukan lagi ada feedback dari kita Oh kurang ini, kurang ini, kurang ini Kembali lagi, kerjakan lagi Muncul lagi versi ketiga, kerjakan lagi Muncul versi keempat Ada feedback dari kita, kerjakan lagi Muncul versi kelima Sampai nanti di akhir ada versi akhir Versi akhir ini yang Tidak akan berubah-ubah Jadi kalau saya analogikan Ke bangunan rumah tadi Kalau bangunan rumah tadi Sudah selesai sudah selesai di spesifikasi kebutuhan sudah selesai mendesain sudah selesai dibikin rumahnya baru diuji baru diserahkan kalau disini enggak kalau disini Oh bikin rumah bikin rumahnya berapa lantai dua lantai Oke kita rancang kita rancang kita bikin kita bikin pondasinya dulu kita bikin fondasi selesai fondasi kita tanya ke pelanggan oke gak begini? ini sudah sesuai kan fondasinya?
ini fondasi untuk 2 lantai oke, kita bikin bagian depan misal kita bikin bagian depan ada 2 kamar dulu jadi 2 kamar Kita kasih ke pelanggan Ini versi-versi menengahnya nanti Kita kasih ke pelanggan Oke gak begini kamarnya? Oke, kita lanjut kamar berikutnya lagi Kasih ke pelanggan Oke gak? Oke, kita lanjut bikin kamar mandi lagi Kasih ke pelanggan Oke gak?
Oke Lanjut lagi kita bikin Sampai jadi lantai 1 Kasihkan ke pelanggan lagi Oke, kita lanjut ke lantai 2 Lantai 2 Dipecah-pecah lagi Terus kita serahkan ke pelanggan sampai nanti di versi akhir jadi satu rumah. Baru akhirnya diserahkan ke pelanggan. Kenapa dia ini mudah untuk berubah-ubah ke depannya? Karena kita sudah jadi sampai misalnya lantai satu beres. Terus kata pelanggan, kayaknya sudah cukup deh lantai satu.
nggak perlu ada lantai dua langsung mereka bikin langsung mereka bikin atap si developernya beda kalau waterfall tadi kita nggak ngasih lihat ke pelanggan tapi pelanggan itu baru melihat setelah jadi rumahnya baru pelanggan itu melihat jadi bedanya incremental development harus ada Feedback pengguna. Jadi peran pengguna ini sangat penting. di model incremental development jika penggunanya ini tidak terlalu aktif di sini sampai ke versi akhir ini nanti akan kesulitan kelebihannya jadinya incremental development lebih rendah biayanya untuk mengatasi perubahan Karena dia bikinnya sedikit-sedikit dulu.
Pelanggan lebih mudah memahami kebutuhannya dengan memberi feedback. Jadi pelanggan tahu, sudah jadi rumahnya, sudah jadi fondasi, oh iya benar saya mau bikin fondasi yang seperti ini. Oh sudah jadi bagian depan kamar, oh iya benar kamarnya maunya seperti ini ukurannya.
Oh nanti ada teras, oh iya terasnya seperti ini, benar. Soalnya saat itu dia masih membayangkan aja rumahnya seperti apa. Walaupun ada desain arsitek, misalnya ada arsitek yang sudah mendesain, dia masih tidak bisa membayangkan ketika sudah ada jadi, pelanggan itu sudah bisa membayangkan. Oh iya begini loh, benar. Oh ini salah, ini kurang misalnya.
Pelanggan dapat menggunakan dan mendapatkan fungsi dari perangkat lunak lebih awal dari yang dimungkinkan dengan waterfall. Saya logikakan dengan rumah tadi, oh jadi lantai 1 nih, lantai 2-nya belum dibikin tapi sedang dibikin, tapi sudah bisa, lantai 1 sudah bisa dihuni. Bisa aja dipakai dulu lantai 1-nya, lantai 2 sambil dikerjakan. Tapi ada beberapa kelemahan, pertama prosesnya tidak terlihat.
Jika sistem dikembangkan dengan cepat, biaya untuk menghasilkan dokumen akan lebih mahal. Kita tidak bisa selalu membuat dokumen setiap ada perubahan. Awalnya hari ini si pelanggan minta saya bikin satu lantai, oke jadi dokumen.
Besok saya bikin, eh nggak jadi, jadi dua lantai deh, jadi dokumen baru lagi. Besoknya lagi, nggak jadi deh, saya pengennya satu lantai aja kembali ke asal. Dokumen baru lagi yang ketiga.
Nah, nanti waktu tenaga biaya itu habis di membuat dokumen, sehingga prosesnya itu menjadi tidak terlihat karena dokumen tadi tidak ada jadinya. Kualitas struktur sistem menurun seiring dengan peningkatan versi. Contoh yang paling gampang ke rumah tadi. Saat ini di awal kita bikin fondasi untuk satu rumah satu lantai. Udah jadi lantai satu.
Kemudian ketika selesai jadi lantai satu kayaknya kurang deh kata si pelanggan, kata si pengguna. Harus ada nambah satu lantai lagi. Kan si developer tinggal nambah satu lantai, tapi fondasinya tidak sekuat yang kan sebelumnya fondasinya dibuat hanya untuk satu lantai. Tapi ketika kita tambah jadi dua lantai, fondasinya itu nggak kuat.
Jadi kualitasnya itu menurun kualitas fondasinya. Bisa jadi nanti rubuh atau nanti rumahnya bisa rusak. Begitu pula dengan perangkat lunak. Jadi peningkatan-peningkatan tadi, perubahan-perubahan tadi bisa mengakibatkan kualitasnya menurun.
Kemudian sulit untuk sistem yang besar, kompleks, dan berumur panjang, di mana tim yang berbeda mengembangkan bagian sistem yang berbeda. Contohnya tadi, kalau misal kita pecah satu kulik yang bikin fondasi, Bagian depan satu kuli yang bikin fondasi bagian belakang Kemudian kuli tersebut yang bagian belakang dipindah lagi yang ke depan Yang depan dipindah yang ke belakang Ini bisa jadi nggak sinkron nih karena data Bukan data Dokumennya tidak jelas Dokumennya di awal tadi tidak dihasilkan Berarti si kulinya ini bisa jadi bikin dari awal lagi Atau bisa jadi dia itu mancang tiang-tiangnya itu sembarangan Karena dia nggak tahu sampai mana ini di panjang tiangnya. Di belakang ini gimana sih struktur tanahnya? Mungkin struktur tanah sampai besar fondasinya itu mempengaruhi beda-bedanya.
Beda fondasinya tadi. Saya kurang mengerti masalah itu. Mungkin ya jadinya. Di perangkat lunak seperti itu juga.
Jadi ini kelemahan-kelemahan dari incremental. Kemudian ada namanya reuse-oriented software engineering. Rekayasa perangkat lunak berorientasi penggunaan kembali. Penekatan ini dasarkan pada keberadaan sejumlah besar komponen yang dapat digunakan kembali.
Proses pengembangan sistem berfokus pada pengintegrasian komponen-komponen ini ke dalam sistem daripada mengembangkan dari awal. Jadi, ini biasanya digunakan oleh developer-developer berpengalaman. Oh, saat ini sudah bikin, kita sudah punya sistem informasi akademik nih untuk kampus poliban.
Terus, kita mau bikin sistem informasi akademik untuk kampus lain, misalnya untuk ULM. Kita bisa gunakan sebagian komponen-komponen, sebagian source code yang ada di sistem informasi akademiknya Polyban ke sistem informasi akademik ULM. Sebagiannya bisa kita pakai ini. Nah, itu maksudnya reuse-oriented software engineering. Alurnya seperti ini.
Sebenarnya mirip dengan waterfall, tapi ada satu bagian yang ditambahkan. Ada tiga bagian, sorry. Pertama, spesifikasi kebutuhan.
Kita spesifikasi dulu. Apa sih maunya pelanggan? Baru kita analisis komponennya.
Komponen yang kita punya ini apa aja sih yang bisa menopang kebutuhan yang tadi? Oh, dari komponen-komponen yang ada ini... Oke, sudah ada banyak nih, baru kita modifikasi kebutuhannya.
Setelah ketemu komponen-komponennya, kita modifikasi untuk mengintegrasi komponen yang sudah ada tadi. Setelah itu baru kita desain sistem dengan penggunaan kembali tadi. Dengan penggunaan kembali komponen-komponen yang sudah ditemukan di sini. Baru dikembangkan dan diintegrasi sama baru divalidasi jadi ada proses ini ini dan ini kita analisis komponen yang sudah kita punya baru modifikasi kebutuhannya baru didesain sistem dengan komponen-komponen yang sudah ada tadi tipe komponennya yang bisa diintegrasikan pertama adalah web service Kedua sekumpulan objek-objek, collusion of objects yang diintegrasi dalam sebuah komponen framework sebagai contoh.NET atau J2EE.
Jadi ini biasanya kalau pemograman berorientasi objek, objek-objeknya bisa digunakan kembali. Mungkin jika kalian belajar PBO, kalau membuat software yang benar-benar berorientasi objek, objek-objeknya itu dapat digunakan di software yang lain tinggal kita ambil objeknya kemudian perangkat lunak yang didesain untuk kondisi khusus stand alone software system kayak tadi untuk SIA, System Information Academic oh ini perangkat lunak ini bisa dipakai nggak di ULMO kalau bisa dipakai apa aja yang bisa dipakai bagian-bagiannya Keuntungannya, reuse-oriented meminimalisir ukuran perangkat lunak yang dibangun. Contohnya kalau ke rumah tadi, oh kita sudah ada desain, nggak ada yang bisa digunakan kembali ya biasanya ya, kita sudah ada desainnya dengan rumah, Dua lantai, dua kamar, dua kamar tidur, satu kamar mandi, satu dapur, satu ruang tamu. Ih, desainnya seperti ini dari yang dulu. Kemudian kita sebagai pelanggan melihat, oh iya saya suka yang begini, tapi saya mau kamar mandinya ditambah satu lagi.
Berarti nanti perangkat tunak yang dibangun, desain yang dibangun, ini di fase desain ya, desain yang dibangun tidak sebesar membangun dari awal lagi. Kita bisa memakai desain yang sebelumnya dan... memodifikasi desain tersebut mengurangi biaya dan risiko biayanya otomatis berkurang dan risikonya sudah berkurang juga karena sudah teruji di sebelumnya pengiriman perangkat tunah lebih cepat sudah jelas karena sebenarnya itu sudah jadi jadi lebih cepat tapi ada beberapa kelemahan Pertama, spesifikasi kebutuhan pengguna terkadang harus dikorbankan untuk dapat menyesuaikan dengan spesifikasi komponen perangkat lunak yang ada.
Contohnya rumah. Rumah kita sudah punya ada pintu. Pintunya itu pintu yang dibuka, kayak daun pintu.
Ada daun pintunya menggunakan, pakai engsel. Kemudian, si pelanggan mintanya nggak mau pintu yang pakai daun seperti itu, yang bisa dibuka seperti itu. Saya mau pakai pintu geser. Nah, tapi kita bilang, kalau mau pakai pintu ini nggak bisa digeser, dibuka pakai engsel biasa aja.
Otomatis si pengguna... Oke deh, yang penting cepat saya pakai pintu yang begini aja. Nah, jadi maksud di sini, kebutuhan pengguna harus dikorbankan.
Iya, nggak apa-apa kita pakai yang ada aja. Akibatnya sistem yang dibangun mungkin tidak sesuai dengan keinginan pengguna. Itu kelemahan reuse oriented. Kemudian, dari tiga ini, Kita kalau mau membangun perangkat lunak, kita milih model proses perangkat lunak mana yang paling bagus. Pertama kalau kita mau memilih harus sesuai dengan jenis sistem.
Tidak ada model yang lebih bagus dari yang lain, tidak ada model yang tidak bagus sama sekali. Jadi harus sesuai dengan jenis sistem. Contohnya, kalau sistem yang kita bangun itu game, paling gampang ya kalau game berarti kayaknya lebih cocok ke incremental deh kita bikin gamenya kita sajikan ke orang lain kita sajikan ke pengguna ke para gamers gamers Oke kurang ini kurang ini kurang ini kurang ini diserahkan kita lagi kita perbaiki kita serahkan lagi ke mereka kenapa sesuai untuk incremental karena Bayangan kita sebagai developer dan bayangan pelanggan, misal gamer sebagai pengguna, itu bisa jadi berbeda. Berbeda dalam artian menurut kita menarik, menurut mereka belum tentu menarik.
Makanya kita harus serahkan ke pengguna. Beda cerita kalau itu kasusnya sistem yang besar, misal sistem informasi akademik. sistemnya ini harus andal datanya itu harus benar datanya itu tidak boleh salah oke nya lebih cocok ke waterfall deh waterfall atau cocok juga nih dengan reuse oriented nah ini terkait dengan nomor dua dapat menggambungkan beberapa model dalam satu project Oh, di sistem informasi akademik tadi, kayaknya kita bisa menggabungkan model waterfall dan model reuse-oriented.
Alurnya waterfall secara garis besar, tapi di dalamnya, unit-unit di dalamnya, bisa jadi kita pakai reuse-oriented. Jadi dipecah-pecah dalam proyek-proyek yang kecil, ada yang reuse-oriented, ada yang waterfall, proyek yang besarnya. Jadi tidak ada model yang jelek.
Kita mau memaksakan waterfall pun kayak game tadi, bisa. Apalagi kalian TA biasanya menggunakan waterfall. Waterfall itu yang umum, andal, klasik, dan jelas dokumentasinya. Terukur nanti waktunya berapa lama, jelas. Jadi untuk memilih proses waterfall, bukan proses waterfall, memilih proses model perangkat lunak, itu disesuaikan dengan kasusnya saja dan kemampuan kita.
Mungkin itu saja materi hari ini. Jika ada yang ditanyakan, silakan kita diskusikan di pertemuan melalui Microsoft Teams. Hai saya akhiri dulu Terima kasih semoga bermanfaat saya akhiri Assalamualaikum warahmatullahi wabarakatuh