Nama : Rendi Setiawan
Nim : 41813120188
Analisa Kebutuhan Perangkat Lunak
Analisa kebutuhan perangkat lunak
Analisis kebutuhan merupakan langkah awal untuk menentukan gambaran perangkat yang akan dihasilkan ketika pengembang melaksanakan sebuah proyek pembuatan perangkat lunak. Perangkat lunak yang baik dan sesuai dengan kebutuhan pengguna sangat tergantung pada keberhasilan dalam melakukan analisis kebutuhan. Untuk proyek-proyek perangkat lunak yang besar, analisis kebutuhan dilaksanakan setelah aktivitas sistem information engineering dan software project planning.
Analisa kebutuhan yang baik belum tentu menghasilkan perangkat lunak yang baik, tetapi analisa kebutuhan yang tidak tepat menghasilkan perangkat yang tidak berguna. Mengetahui adanya kesalahan pada analisis kebutuhan pada tahap awal memang jauh lebih baik, tapi kesalahan analisis kebutuhan yang diketahui ketika sudah memasuki penulisan kode atau pengujian, bahkan hampir masuk dalam tahap penyelesaian merupakan malapetaka besar bagi pembuat perangkat lunak. Biaya dan waktu yang diperlukan akan menjadi sia sia.
•Analisis kebutuhan
Analisa kebutuhan adalah suatu proses untuk mendapatkan informasi, mode, spesifikasi tentang perangkat lunak yang diinginkan klien/pengguna. Kedua belah pihak, yaitu klien dan pembuat perangkat lunak terlibat aktif dalam tahap ini. Informasi dari klien yang akan menjadi acuan untuk melakukan desain perangkat lunak.
Analisis kebutuhan merupakan satu di antara banyak aktivitas kritis pada proses rekayasa kebutuhan perangkat lunak untuk memahami ranah permasalahan dari sistem yang berjalan dan ranah solusi dari sistem yang akan dibuat(Yen et.al, 1998).
Ada tiga faktor yang harus dipenuhi ketika melakukan analisis kebutuhan ini, yaitu lengkap, detail, dan benar. Lengkap artinya semua yang diharapkan oleh klien telah didapatkan oleh pihak yang melakukan analisis. Detail maksudnya adalah berhasil mengumpulkan informasi yang terperinci. Semua data dari analisis kebutuhan ini haruslah benar, sesuai apa yang dimaksud oleh klien, bukan benar menurut apa yang dipikirkan oleh pihak analisis.
Analisis kebutuhan yang dilakukan terhadap perangkat lunak akan menghasilkan spesifikasi perangkat lunak tersebut. Analisa kebutuhan ini terdiri dari lima langkah pokok:
1.Identifikasi Masalah 2.Evaluasi dan sintesis 3.Pemodelan
4.Spesifikasi 5.Review
•Tujuan analisis kebutuhan
Ada tiga tujuan utama dari proses analasis kebutuhan yang dapat diformulasikan sebagai beriukut :
1.Mengelola hasil elistasi kebutuhan untuk menghasilkan dokumen spesifikasi kebutuhan yang isi keseluruhannya sesuai dengan apa yang diinginkan pengguna (Liu and Yen, 1996).
2.Mengembangkan persyaratan kualitas yang memadai dan rinci, dimana para manajer dapat membuat pekerjaan proyek yang realistis dan staf teknis dapat melanjutkan dengan
3.Membangun pemahaman tentang karakteristik ranah permasalahan dan sekumpulan kebutuhan untuk menemukan solusi.
Ketiga tujuan tersebut dapat dicapai oleh perekayasa kebutuhan dengan melalui serangkaian tahapan-tahapan aktivitas. Tahapan aktivitas tersebut dijelaskan sebagai berikut.
Tahap Analisis Kebutuhan
Tahap analisis adalah tahapan pengumpulan kebutuhan-kebutuhan dari semua elemen sistem perangkat lunak yang akan di bangun. Pada tahap ini dibentuk spesifikasi kebutuhan
perangkat lunak, fungsi perangkat lunak yang dibutuhkan, performansi (unjuk kerja) sistem perangkat lunak, penjadwalan proyek, identifikasi sumber daya (manusia , perangkat keras dan perangkat lunak yang dibutuhkan) dan taksiran biaya pengembangan perangkat lunak.
Diagram menunjukan tahapantahapan didalam analisis kebutuhan (Sommervilee, 2004). Pada dasarnya, aktivitas analisis dibutuhkan dalam setiap proses dalam daur
hidup pengembangan perangkat lunak. Didalam proses rekayasa kebutuhan, analisis pun dila kukan dalam setiap aktivitas-aktivitasnya. Penjelasan dari masing-masing aktivitas tersebut.
Domain Understanding, dalam tahap ini perekayasa kebutuhan perangkat lunak harus mengetahui bagaimana organisasi perusahaan beroperasi dan apa yang menjadi permasalahan pada sistem yg sedang berjalan pada saat ini. perekayasaan perlu memfokuskan kepada ‘Apa’ yg menjadi permasalahan. Perekaysaan hendaknya tidak berhenti pada menemukan “gejala” dari permasalahn itu terjadi untuk menemukan akar dari pemasalahan dari sistem yg berjalan tersebut.
Requirements Collection, Tahapan ini merupakan tahapan pengumpulan kebutuhan akan sistem yang akan dibangun.Pada tahapan ini diperlukan adanya intekasi intensif dengan pemangku kepentingan terutama dengan pengguna akhir.
Classification, Pada tahapan sebelumnya kumpulan kebutuhan masih tidak terstruktur. Untuk itu kebutuhan yang saling berkaitan dikelompokan,baik menurut kelas penggunaanya maupun jenis kebutuhananya. Kebutuhan kebutuhan tersebut diorganisasi ke dalam kelompok kelompok yang koheren.Perekayasaan perlu memisahkan antara kebutuhan dan keinginan dari pengguna.
Conflict resolution, Pada tahapan ini adalah menemukan dan menyelesaikan kebutuhan yang di dalamnya terdapat konflik.
Prioritisation, Pada tahapan dilakukan interaksi dengan pemangku kepentingan untuk mengidentifikasikan kebutuhan-kebutuhan priopritas dari masing
masing kebutuhan agar sumber daya yang tersedia pada organisasi dialokasikan untuk mengimplementasikan kebutuhan yg terutama dari pemangku kepentingan.
Requirements Checking, Menganalisa sekumpulan kebutuhan dari hasil tahapan
sebelumnya untuk memverifikasi dan memvalidasi berdasarkan aspek kelengkapan, konsistensi,dan kebutuhan nyata.
Dalam rekayasa kebutuhan, analisa kebutuhan yang baik hedaklah menitik beratkan pada ranah permasalahan dan bukan pada ranah solusi. Tujuan utamanya adalah untuk mencapai pemahaman tetang sifat dari ranah permasalahan dan permasalahan yang ada didalamnya . Pada dasarnya, analisi kebutuhan diawali dengan spesifikasi
(layanan, atribut, properti, kualitas, batasan) dari sistem solusi yang hendak dibangun.
Kegunaan analisis adalah untuk memodelkan permasalahan dunia nyata agar dapat dimengerti. Permasalahan dunia nyata harus dimengerti dan dipelajari supaya spesifikasi kebutuhan perangkat lunak dapat diungkapkan. Tujuan aktivitas ini adalah untuk mengetahui ruang lingkup produk (product space) dan pemakai yang akan menggunakannya. Analisis yang baik akan mengungkapkan hal
hal yang penting dari permasalahan, dan mengabaikan yang tidak penting.
TEKNIK KOMUNIKASI
• Merupakan permulaan yang (selalu) perlu dilakukan agar seorang pelanggan memiliki masalah yang dapat dipertanggung jawabkan melalui pemecahan berbasis komputer
• Agar pengembang dapat merespon permintaan bantuan (help) dari pelanggan Biasanya jalan komunikasi ke pemahaman penuh dengan “lobang-lobang”
Prinsip-prinsip analisis
Masingmasing metode analisis memiliki titik pandang yang unik. Tetapi, semua metode anal isis dihubungkan oleh serangkaian prinsip operasional (Pressman, 2008) berikut :
1. Ranah informasi dari suatu masalah harus dipresentasikan dan dipahami. 2. Fungsi-fungsi yang akan dilakukan oleh perangkat lunak harus didefinisikan.
3. Tingkah laku perangkat lunak (sebagai suatu uruatan kejadian eksternal) harus terwakilkan.
4. Modelmodel yang merepresentasikan informasi, fungsi dan tingkah laku sistem haurs dipecah-pecah ke dalam tingkat yang lebih rinci dalam bentuk lapisan (atau hierarki). 5. Proses analisis harus dimulai dari informasi dasar menuju implementasi rinci.
Definisi Analisis
Analisis adalah penguraian suatu pokok atas berbagai bagiannya dan proses bagian itu sendiri serta hubungan antar bagian untuk memperoleh pengertian yang tepat dan pemahaman arti ke seluruhan.
Tujuan tahap analisis adalah :
1. Menjabarkan kebutuhan pemakai
2. Meletakkan dasar-dasar untuk tahap perancangan perangkat lunak
3. Mendefinisikan semua kebutuhan pemakai sesuai dengan lingkup kontrak yang disepakati kedua belah pihak (pengembang dan pengguna).
Definisi kebutuhan
Definisi kebutuhan menurut IEEE (The Institute of Electrical and Electronics Engineers) kebutuhan adalah :
1. Suatu kondisi atau kemampuan yang diperlukan pengguna untuk menyelesaikan masalah atau mencapai sesuatu.
2. Suatu kondisi atau kemampuan yang harus dipenuhi atau dimiliki oleh suatu sistem atau komponen sistem untuk memenuhi suatu kontrak, standar, spesifikasi atau dokumen formal lain yang diberlakukan.
3. Suatu representasi terdokumentasi dar suatu kondisi atau kemapuan seperti dalam 1 dan 2.
Tahap kebutuhan akan perangkat lunak dimulai dengan :
1. Dikenalinya adanya sebuah permasalahan yang membutuhkan sebuah penyelesaian. I dentifikasi sebuah permasalahan mungkin dapat dilakukan dengan berorientasi pada aplikasi, berorientasi pada bisnis, atau berorientasi pada kenaikan produktivitas (pro duct improvement oriented).
2. Munculnya ide untuk membuat sebuah perangkat lunak baru (sebagai sebuah kemajuan).
Suatu kebutuhan adalah atribut yang diperlukan di dalam sebuah sistem, sedangkan satu pernyataan (statment) digunakan untuk mengidentifikasi sebuah kemampuan, karakteristik, atau faktor kualitas dari sebuah sistem untuk mempunyai nilai dan kegunaan bagi pelanggan atau pengguna.
Kebutuhan menjadi hal penting sebab mereka menyediakan dasar untuk semua pengembangan pekerjaan selanjutnya, mengapa?
Mencari kesalahan diakhir siklus hidup pengembangan perangkat lunak ternyata akan banyak mengeluarkan uang.
1. Jika dapat dideteksi, dilakukan perbaikan pada setiap tahap proses.
2. Jika tidak dapat dideteksi, kesalahan baru kelihatan setelah produk selesai dibuat.
Suatu pendekatan yang lebih baik akan menginvestasikan waktu yang lebih di dalam pengempulan kebutuhan, analisis, dan
aktivitas-aktivitas manajemen. Alasannya adalah bahwa pekerjaan pengodean biasanya dimulai lebih cepat daripada harus menambah waktu untuk mengidentifikasi kebutuhan “riil” (real) dan untuk merencanakan aktivitas terkait kebutuhan (
requidment-realted). Ada satu perbedaan penting antara kebutuhan State dan kebutuhan riil, yaitu :
1. Kebutuhan State (ditetapkan) disajikan oleh pelanggan pada permulaan sistem atau usaha pengembangan perangkat lunak, contohnya di dalam permintaan untuk informasi, proposal, atau di dalam sebuah statment of Works (SOW).
2. Kebutuhan riil mencerminkan kebutuhan pengguna yang dibutuhkan untuk kemampuan atau sistem tertentu.
Sering muncul perbedaan yang sangat besar antara kebutuhan State dan kebutuhan riil. Analisis dalam kebutuhan State diperlukan untuk menentukan dan menyaring pelanggan riil, kebutuhan pengguna dan harapan sistem yang dikirimkan. Kebutuhan perlu disaring dengan proses klarisifikasi dari identifikasi, artinya dari aspek yang lain yang membutuhkan
pertimbangan. Contoh sederhana, requirement analysts (RA) menjadi lebih terbiasa dengan keperluan untuk menyatakan kebutuhan dengan jelas.
Untuk menghemat waktu, semua kebutuhan sebaiknya diperjelas melalui mekanisme pelanggan/pengguna gabungan (jin costomer/user)dan usaha RA. Pelanggan dan pengguna akan memerlukan dukungan secara teknis dan para profesional yang berpengalaman, dan sebaliknya memastikan komunikasi yang efektif. Pengembang juga harus mempunyai pemanahan yang sama sehingga solusi yang mereka gambarkan sesuai dengan harapan semua orang. Kesalahpahaman akan berujung pada kesia-siaan dan mengharuskan pekerjaan ulang.
Proses Rekayasa Kebutuhan
Apa yang menjadi kesuksesan dalam sebuah perangkat lunak? Apa sistem yang cukup mampu memenuhi semua kebutuhan penggunanya? Tinggat kepuasan penggunannya?
Rekayasa kebutuhan mencakup beberapa proses mengenai fakta ini, proses rekayasa kebutuhan adalah sekumpulan aktivitas yang terstruktur untuk diperoleh, memvalidasi, dan memelihara dokumen kebutuhan sistem (Thayer, 1997). Pada umumnya tugas rekayasa digambarkan sebagai penciptaan dari solusi keefektifan biaya untuk masalah kehidupan yang nyata dengan menerapkan pengetahuan keilmuan. Rekayasa kebutuhan juga dapat
digambarkan sebagai tugas untuk memenuhi aktivitas pengembangan untuk masalah dunia nyata sehingga ketepatan dan keefektifan biaya dari solusi dapat dianalis (Nuseibeh, 2000).
Dari sudut pandang pengembangan sistem perangkat lunak, dua aktiviatas dapat dikenali sebagai rekayasa kebutuhan dan rekayasa perangkat lunak. Rekayasa perangkat lunak dapat digambarkan sebgai aktivitas yang terlibat dalam siklus hidup dari proses pengembangan perangkat lunak, dengan rekayasa kebutuhan yang menjadi pusat aktivias di dalam siklus hidup.
Latar belakang kenapa rakayasa kebutuhan diperlukan adalah kenyataan bahwa menemukan kebutuhan klien secara lengkap merupakan usaha yang tidak mudah dan mahal. Dikatakan tidak mudah karena,
1. Klien tidak selalu mengetahui dengan pasti dan jelas mengenai apa yang diperlukan, 2. Kebutuhan yang diutarakan oleh klien tidak selalu sesuai dengan apa yang dimaksud,
dan
3. Kebutuhan klien berubah-ubah di sepanjang kegiatan pembangunan perangkat lunak.
Hal tersebut menyebabkan biaya pembangangunan perangkat lunak menjadi mahal karena ada tambahan biaya dan tambahan waktu untuk perubahan yang dilakukan.
Daur hidup suatu perangkat lunak (SLC) secara umum dapat diilustrasikan sebagai gambar di atas, dimana ada 2 buah siklus kehidupan utama dari suatu perangkat lunak, yaitu daur hidup pengembangan perangkat lunak (SDLC) dan daur hidup pengoperasian perangkat lunak (SOLC), keduanya dihubungkan oleh dua buah proses, yaitu proses studi kelayakan dan proses peluncuran.
Pengembangan perangkat lunak pada dasarnya muncul karena adanya suatu kebutuhan baru. Melalui studi kelayakan, kita dapat dibantu menentukan apakah kebutuhan tersebut masih dapat dipenuhi oleh sistem perangkat lunak yang ada atau tidak. Jika dipandang bahwa sistem yang sudah ada tidak dapat memenuhi kebutuhan baru tersebut, maka kita akan
memutusakan apa mau mengembangkan sistem perangkat lunak (baik sistem lama atau baru) Studi kelayakan tetap dilakukan dalam pengembangan perangkat lunak berskala besar
maupun kecil.
Sistem yang baru yang akan dikembangkan bisa dibangun dari sistem lama, atau dari sistem baru. Sering juga disebut lingkungan pengembangan (development enviornment). Proses pertama yang dilakukan dengan penspesifikasian kebutuhan, hasil dari proses ini adalah sebuah spesifikasi kebutuhan sistem yang dibutuhkan oleh pembuat. Spesifikasi ini sering disebut sebagai rancangan bersifat highend. Berdasarkan spesifikasi tersebut, pihak
pengembang akan membuat suatu rancangan yang bersifat lowend. Kemudian diimplementasi kan menjadi produk perangkat lunak oleh programmer. Melalui proses pengujian produk ini diuji dan dipastikan kesesuaiannya dengan spesifikasi kebutuhan yang telah ditetapkan dan ketetapan implementasinya. Produk yang berhasil melewati proses pengujian kemudaian akan diluncurkan ke lingkungan operasioanl (operatioan environment).
Dalam daur pengoperasian , perangkat lunak yang telah selesai dibangun difungsikan untuk kebutuhan operasiional sistem. Seringkali, terdapat ketidaksesuaian antara perangkat lunak dengan kebutuhan di lapangan. Kesalahan ini terjadi pada beberapa kesalahan pada daur hidup pengembangan dan akan diperbaiki. Proses ini sering dipandang sebagai proses perawatan perangkat lunak. Tapi jika kesalahan itu terjadi karena kebutuhan baru dalam organisasi maka perangkat lunak tersebut dikaji ulang kelayakannya. Dan kembali pada daur hidup perangkat lunak tersebut.
Spesifikasi kebutuhan merupakan proses awal dari daur hidup pengembangan perangkat lunak. Keluaran dari proses ini menentukan arah pengembangan perangkat lunak selanjutnya Tahap pekerjaan analisis kebutuhan perangkat lunak pada dasarnya terdiri dari urutan aktivitas :
1. Menentukan kebutuhan (requirement)
Lebih banyak berhubungan dengan pemakai. Hasil belum terstruktur.
1. Data atau informasi apa yang akan diproses 2. Fungsi apa yang diinginkan
3. Kelakuan sistem apa yang diharapkan
4. Antarmuka apa yang tersedia (user interfaces, hardware interfaces, software interface , dan communications interfaces)
2. Sintesis
Mengubah kebutuhan yang belum terstruktur menjadi model atau gambar dengan memanfaat kan teknik dan metodeanalisis tertentu.
3. Membuat dokumen Software Requirements Spesification (SRS).
Sudah merupakan analisis yang lebih rinci, sebagai tahap awal perancangan.
Model Prototype
Metode Prototype merupakan suatu paradigma baru dalam metode pengembangan perangkat lunak dimana metode ini tidak hanya sekedar evolusi dalam dunia pengembangan perangkat lunak, tetapi juga merevolusi metode pengembangan perangkat lunak yang lama yaitu sistem sekuensial yang biasa dikenal dengan nama SDLC atau waterfall development model.
Dalam Model Prototype, prototype dari perangkat lunak yang dihasilkan kemudian dipresentasikan kepada pelanggan, dan pelanggan tersebut diberikan kesempatan untuk memberikan masukan sehingga perangkat lunak yang dihasilkan nantinya betul-betul sesuai dengan keinginan dan kebutuhan pelanggan.
Perubahan dan presentasi prototype dapat dilakukan berkali-kali sampai dicapai kesepakatan bentuk dari perangkat lunak yang akan dikembangkan.
Teknik – teknik Prototyping Meliputi :
• Perancangan Model
• Perancangan Dialog
• Simulasi
Berikut adalah 4 langkah yang menjadi karakteristik dalam proses pengembangan pada metode prototype, yaitu :
• Pemilihan fungsi
• Penyusunan Sistem Informasi
• Evaluasi
• Penggunaan Selanjutnya
Metode ini menyajikan gambaran yang lengkap dari suatu sistem perangkat lunak, terdiri atas model kertas, model kerja dan program. Pihak pengembang akan melakukan identifikasi kebutuhan pemakai, menganalisa sistem dan melakukan studi kelayakan serta studi terhadap kebutuhan pemakai, meliputi model interface, teknik prosedural dan teknologi yang akan dimanfaatkan.
Berikut adalah Tahapan – tahapan Proses Pengembangan dalam Model Prototype, yaitu :
• Pengumpulan kebutuhan
Pelanggan dan pengembang bersama-sama mendefinisikan format seluruh perangkat lunak, mengidentifikasikan semua kebutuhan, dan garis besar sistem yang akan dibuat.
• Membangun prototyping
Membangun prototyping dengan membuat perancangan sementara yang berfokus pada penyajian kepada pelanggan (misalnya dengan membuat input dan format output).
• Evaluasi protoptyping
Evaluasi ini dilakukan oleh pelanggan, apakah prototyping yang sudah dibangun sudah sesuai dengan keinginan pelanggan atau belum. Jika sudah sesuai, maka langkah selanjutnya akan diambil. Namun jika tidak, prototyping direvisi dengan mengulang langkah-langkah
sebelumnya.
• Mengkodekan sistem
Dalam tahap ini prototyping yang sudah di sepakati diterjemahkan ke dalam bahasa pemrograman yang sesuai.
• Menguji sistem
Setelah sistem sudah menjadi suatu perangkat lunak yang siap pakai, kemudian dilakukan proses Pengujian. Pengujian ini dilakukan dengan White Box, Black Box, Basis Path, pengujian arsitektur, dll.
• Evaluasi Sistem
Pelanggan mengevaluasi apakah perangkat lunak yang sudah jadi sudah sesuai dengan yang diharapkan . Jika ya, maka proses akan dilanjutkan ke tahap selanjutnya, namun jika
perangkat lunak yang sudah jadi tidak/belum sesuai dengan apa yang diharapkan, maka tahapan sebelumnya akan diulang.
• Menggunakan sistem
Perangkat lunak yang telah diuji dan diterima pelanggan siap untuk digunakan.
Model Prototyping ini sangat sesuai diterapkan untuk kondisi yang beresiko tinggi di mana masalah-masalah tidak terstruktur dengan baik, terdapat fluktuasi kebutuhan pemakai yang berubah dari waktu ke waktu atau yang tidak terduga, bila interaksi dengan pemakai menjadi syarat mutlak dan waktu yang tersedia sangat terbatas sehingga butuh penyelesaian yang segera. Model ini juga dapat berjalan dengan maksimal pada situasi di mana sistem yang diharapkan adalah yang inovatif dan mutakhir sementara tahap penggunaan sistemnya relatif singkat.
Berikut merupakan Jenis – jenis dari Prototyping :
• Feasibility prototyping
digunakan untuk menguji kelayakan dari teknologi yang akan digunakan untuk system informasi yang akan disusun.
• Requirement prototyping
digunakan untuk mengetahui kebutuhan aktivitas bisnis user.
• Desain Prototyping
digunakan untuk mendorong perancangan sistem informasi yang akan digunakan.
• Implementation prototyping
merupakan lanjutan dari rancangan prototype, prototype ini langsung disusun sebagai suatu sistem informasi yang akan digunakan.
• Contoh Penerapan Metode Prototype.
Sebuah rumah sakit ingin membuat aplikasi sistem database untuk pendataan pasiennya. Seorang atau sekelompok programmer akan melakukan identifikasi mengenai apa saja yang dibutuhkan oleh pelanggan, dan bagaimana model kerja program tersebut. Kemudian dilakukan rancangan program yang diujikan kepada pelanggan. Hasil/penilaian dari pelanggan dievaluasi, dan analisis kebutuhan pemakai kembali di lakukan.
Kelebihan Model Prototype :
• Pelanggan berpartisipasi aktif dalam pengembangan sistem, sehingga hasil produk pengembangan akan semakin mudah disesuaikan dengan keinginan dan kebutuhan pelanggan.
• Penentuan kebutuhan lebih mudah diwujudkan.
• Mempersingkat waktu pengembangan produk perangkat lunak.
• Adanya komunikasi yang baik antara pengembang dan pelanggan.
• Pengembang dapat bekerja lebih baik dalam menentukan kebutuhan pelanggan.
• Lebih menghemat waktu dalam pengembangan sistem.
• Penerapan menjadi lebih mudah karena pelanggan mengetahui apa yang diharapkannya.
Kekurangan Model Prototype :
• Proses analisis dan perancangan terlalu singkat.
• Biasanya kurang fleksibel dalam mengahadapi perubahan.
• Walaupun pemakai melihat berbagai perbaikan dari setiap versi prototype, tetapi pemakai mungkin tidak menyadari bahwa versi tersebut dibuat tanpa memperhatikan kualitas dan pemeliharaan jangka panjang.
• Pengembang kadang-kadang membuat kompromi implementasi dengan menggunakan sistem operasi yang tidak relevan dan algoritma yang tidak efisien.
Sumber referensi:
https://murtri.wordpress.com/2014/08/25/model-model-pengembangan-perangkat-lunak-beserta-contoh-penerapannya/
