Proses Desain Interaksi
Model Brainstorming
merupakan salah satu metode berpikir yang cukup populer dan banyak digunakan di kalangan pekerja. Cara ini dianggap mampu menghasilkan berbagai ide kreatif dan besar hanya dalam kurun waktu yang singkat saja.
Metode pembelajaran Brainstorming seringkali dipraktekkan ketika sebuah kelompok atau tim kerja menginginkan berbagai ide segar dan orisinil dari semua anggota kelompok itu sendiri dalam waktu yang cepat. Hal ini tentu cocok untuk mereka yang bekerja dengan tenggat waktu yang sempit/ terbatas.
Pada awalnya, ide ini pertama kali disampaikan oleh Alex Osborn, seorang CEO pemasaran, melalui bukunya yang diberi judul “Applied Imagination” di tahun 1953 silam. Namun di dalam perkembangannya, Brainstorming adalah cara berpikir yang pada akhirnya bisa dilakukan dengan berbagai teknik yang berbeda.
Pengertian Brainstorming
Berdasarkan Mind Tools, Brainstorming artinya menciptakan sebuah lingkungan yang bebas serta terbuka, di mana setiap orang menjadi terdorong untuk ikut serta berpartisipasi dalam lingkungan tersebut.
Metode pembelajaran Brainstorming akan mendukung setiap orang untuk menghasilkan ide, di mana ide-ide tersebut akan disambut serta dibangun dengan sedemikian rupa dengan melibatkan semua orang yang terdapat dalam lingkungan tersebut.
Metode ini akan membuat semua orang menjadi aktif dan terlibat, sehingga ide yang kreatif untuk menyelesaikan masalah yang tengah dihadapi bisa dihasilkan dengan waktu yang cepat.
Beragam ide unik disambut dan dibangun, dan semua peserta didorong untuk berkontribusi penuh sehingga membantu mereka dalam mengembangkan beragam solusi kreatif. Brainstorming yaitu metode pencarian ide yang dilakukan dengan cara menyenangkan, sebab semua orang terlibat di dalamnya.
Di dalam Brainstorming, idealnya semua anggota dapat menghargai ide setiap orang dan menghindari kritik. Hal ini penting, sebab semua ide maupun asumsi yang masuk bisa dipertimbangkan, bahkan bisa menjadi solusi bagi permasalahan yang sedang diselesaikan.
Brainstorming yaitu sebuah metode yang dipakai oleh tim untuk mencari ide dan solusi dalam menyelesaikan sebuah masalah, di mana semua anggota tim terlibat untuk memberikan ide serta solusi permasalahan dengan cara yang kreatif serta cepat.
Artinya, tujuan dari Brainstorming adalah untuk menemukan ide dan juga solusi penyelesaian dari sebuah masalah, di mana semua anggota tim dilibatkan dan ikut serta memberikan ide dan pandangan mereka terhadap permasalahan itu sendiri.
Metode Brainstorming
Brainstorming artinya cara yang dilakukan oleh sebuah tim dalam mencari ide kreatif yang bisa menyelesaikan permasalahan yang sedang dihadapi. Hal ini akan melibatkan semua orang dalam tim, sehingga ide-ide terbaik bisa ditemukan dalam waktu yang cepat.
Ada berbagai metode Brainstorming yang dikenal secara luas, beberapa di antaranya seperti berikut ini:
Mind Mapping
Ini merupakan metode yang diterapkan dengan cara menciptakan diagram dari sejumlah pemikiran atau ide yang berbeda. Cara ini bisa dilakukan dengan menggambarkan sebuah simpul pusat terlebih dahulu, lalu menghubungkan simpul tersebut dengan informasi lainnya dengan menggunakan garis, gambar, maupun tulisan lainnya.
Brain Writing
Metode pembelajaran Brainstorming lainnya adalah Brain Writing. Teknik ini bisa dilakukan dengan membagikan selembar kertas berisi petunjuk kepada semua anggota tim, lalu mintalah mereka menuangkan ide sebanyak-banyaknya dalam kurun waktu 5 menit di atas kertas tersebut.
Lalu, setiap orang akan membacakan idenya kepada orang di sampingnya. Setelah 5 menit, orang di sampingnya memberikan saran dan 3 ide yang baru sebagai tambahan. Lakukan hal ini hingga semua orang mengeluarkan ide dan saran secara bergiliran.
Rapid Ideation
Metode berikutnya dari Brainstorming yaitu Rapid Ideation. Cara melakukan teknik ini adalah dengan meminta semua anggota tim untuk menuliskan ide sebanyak-banyaknya dalam kurun waktu tertentu. Jika sudah selesai, maka pilih ide terbaik dan mintalah anggota tim untuk memberikan saran pada ide-ide tersebut.
Team Brainstorming
Metode ini dilakukan dengan cara membagi tim dalam kelompok-kelompok yang lebih kecil maupun berpasangan, lalu membiarkan mereka berdiskusi dan menghasilkan ide-ide kreatif dalam kurun waktu tertentu. Jika waktunya sudah selesai, mintalah masing-masing kelompok untuk menuliskan dan mempresentasikan berbagai ide tersebut di depan semua anggota tim.
Round Robin
Metode yang satu ini dilakukan dengan memilih salah satu anggota tim untuk membagikan idenya. Lalu ajak anggota tim tersebut untuk berkeliling dan meminta ide dari masing-masing anggota tim secara keseluruhan, sehingga bisa ditemukan ide yang paling tepat dan bisa mewakili yang lainnya.
Tips Melakukan Metode Pembelajaran Brainstorming
Brainstorming adalah teknik pencarian ide yang dilakukan dengan cara melibatkan semua anggota tim sekaligus. Metode pembelajaran Brainstorming ini akan sukses jika dilakukan dengan cara yang tepat sejak awal.
Berikut ini beberapa tips yang bisa diterapkan saat melakukan metode Brainstorming:
- Tentukan batas waktu yang tepat. Brainstorming adalah teknik yang dilakukan dengan waktu ideal sekitar 15 sampai 60 menit.
- Awali dengan masalah atau ringkasan tentang target yang akan dibahas.
- Tahan diri untuk tidak memberi penilaian maupun kritik, sebab semua anggota tim harus bersikap positif saat menanggapi ide-ide dalam proses ini.
- Dukung ide yang unik/aneh, selama masih berkaitan dengan topik yang sedang dibahas.
- Kuantitas ide bisa menghasilkan ide-ide yang berkualitas pada akhirnya, setelah dilakukan penyaringan dan proses lainnya dalam memilih ide terbaik.
- Hindari untuk fokus pada satu ide saja, sebab ide lainnya juga harus diberi kesempatan, jadi pahami setiap ide secara detail terlebih dahulu.
- Bangun gagasan orang lain, agar lebih luas dan bisa menghasilkan gagasan yang baru.
- Manfaatkan pengalaman maupun masukan yang bersifat acak, agar bisa menghasilkan ide baru yang tak terduga.
- Gunakan visual untuk membantu menggambarkan ide dan mempermudah orang lain memahaminya.
- Berikan waktu pada anggota tim untuk memulai percakapan terkait ide yang mereka miliki.
- Beri kebebasan bagi semua orang untuk mengeksplorasi ide-ide yang mereka miliki dengan leluasa.
- Brainstorming artinya proses menghasilkan ide dengan cara berkonsentrasi, jadi berikan waktu jeda/ istirahat kepada anggota tim jika proses ini berlangsung lama.
Cara Melakukan Brainstorming
Secara sederhana, Brainstorming adalah teknik pengumpulan ide yang dilakukan untuk menghasilkan solusi bagi permasalahan yang sedang dihadapi. Proses Brainstorming yaitu dengan melibatkan semua anggota tim dalam memberikan ide-ide terhadap permasalahan tersebut.
Berikut ini adalah beberapa langkah untuk melakukan Brainstorming dengan tepat:
Tetapkan Tujuan Brainstorming
Brainstorming adalah proses yang dilakukan untuk mencari solusi atau mencapai target tertentu. Langkah pertama untuk melakukan Brainstorming yaitu menentukan dengan jelas tujuan yang akan dicapai, agar proses dan arah kegiatan ini lebih jelas.
Siapkan Ide Sejak Awal
Brainstorming artinya proses pencarian ide, di mana seluruh orang yang tergabung dalam tim akan ikut serta di dalam proses tersebut. Namun jika ingin proses ini berjalan lancar, maka tentukan ide awal sebelum proses Brainstorming ini dilakukan.
Tentukan Batas Waktu
Tentukan batas untuk melakukan Brainstorming. Kebanyakan perusahaan akan menentukan batas waktu sekitar 20-30 menit untuk sesi ini, namun waktu ini tentu bisa disesuaikan dengan kondisi dan juga kebutuhan.
Berikan Kesempatan Berbicara pada Semua Peserta
Brainstorming artinya melibatkan semua orang untuk memberikan ide mereka. Sangat penting untuk memberi kesempatan pada semua anggota tim untuk berbicara dan mengeluarkan pendapat mereka.
Pilih Seorang Pemimpin
Pilihlah salah satu anggota tim untuk memimpin sesi Brainstorming. Hal ini akan mempermudah arah diskusi dan juga pengambilan kesimpulan ketika sesi ini sudah hampir selesai.
Catat Seluruh Ide yang Dihasilkan
Jangan lupa untuk mencatat semua ide yang dihasilkan dalam sesi ini, agar tidak terbuang dengan sia-sia. Catatan ini juga akan mempermudah proses evaluasi terhadap ide-ide yang masuk.
Gunakan Elemen Visual
Untuk mempermudah semua anggota tim memahami berbagai ide dalam Brainstorming, manfaatkan elemen visual yang tepat, seperti: gambar, simbol, warna, dan yang lainnya.
Ciptakan Lingkungan yang Ramah
Ciptakan lingkungan yang ramah untuk semua orang, agar sesi Brainstorming bisa berjalan dengan nyaman untuk semua orang. Hal ini akan memungkinkan proses berpikir lebih maksimal, sehingga ide kreatif bisa dihasilkan.
Ajukan Pertanyaan yang Relevan
Ajukan pertanyaan-pertanyaan yang relevan, sehingga sesi ini benar-benar sukses dan bisa menghasilkan berbagai ide kreatif yang terbaik. Cara ini juga akan sekaligus membuat semua anggota tim menjadi lebih aktif.
Lakukan Brainstorming dengan Cara Tepat
Brainstorming adalah salah satu cara untuk menghasilkan berbagai ide kreatif yang tepat untuk menyelesaikan berbagai masalah tertentu. Hal ini harus dilakukan dengan melibatkan semua orang di dalam tim. Lakukan sesi Brainstorming dengan cara yang tepat, agar tujuannya bisa tercapai dengan maksimal.
Analisis Model Waterfall : Pengertian, Tahapan, Kelebihan dan kekurangan
Model Waterfall adalah pendekatan SDLC paling awal yang digunakan dalam proses pengembangan perangkat lunak. Model waterfall pertama kali diperkenalkan oleh Winston W. Royce sekitar tahun 1970. Model ini sangat sederhana sehingga mudah untuk dipahami dan digunakan dalam proses pengembangan perangkat lunak. Meskipun begitu, waterfall merupakan metodologi pengembangan perangkat lunak yang tidak bekerja secara baik. Dokumen model waterfall yang dibuat oleh Winston memiliki dua kategori, yang pertama menjelaskan mengenai model itu sendiri, dan yang kedua menggambarkan masalah utama yang melekat dalam model, atau alasan untuk tidak menggunakan model waterfall. Mungkin tampak aneh bahwa kemudian model waterfall menjadi salah satu metodologi pemrograman yang paling populer setelah publikasi dan tetap seperti itu selama bertahun-tahun.
Waterfall termasuk salah satu jenis model pengembangan siklus hidup klasik (classic life cycle), di mana menekankan fase yang berurutan dan sistematis. Model pengembangan ini dapat dianalogikan seperti air terjun, dimana setiap tahap dikerjakan secara berurutan mulai dari atas hingga bawah. Model waterfall menggambarkan proses pengembangan perangkat lunak dalam aliran sekuensial linier “Linear Sequential Model”. Ini berarti bahwa setiap tahap dalam proses pengembangan hanya akan dimulai jika tahap sebelumnya telah selesai. Proses juga tidak dapat kembali atau mengulang ke tahap sebelumnya.
Tahapan Pada Model Waterfall
Requirement Analysis
Requirement merupakan proses dari analisa atau pengumpulan data - data yang berkaitan dengan sistem yang akan dibuat. Pada tahap ini, pengembang harus mengetahui dan memahami perangkat lunak yang diharapkan oleh pengguna.
Metode pengumpulan data dapat diperoleh melalui diskusi, observasi, survei, dan wawancara. Kemudian data yang didapat diolah dan dianalisis sehingga memperoleh informasi yang lengkap mengenai spesifikasi kebutuhan pengguna terhadap perangkat lunak yang akan dikembangkan.
System and Software Design
Pada tahap ini, pengembang menganalisis informasi mengenai spesifikasi kebutuhan pengguna untuk menyiapkan kebutuhan perangkat keras (hardware) dalam pembuatan arsitektur sistem perangkat lunak yang akan dibuat secara keseluruhan. Perancangan desain dilakukan dengan tujuan untuk memberikan gambaran mengenai apa saja yang harus dikerjakan.
Implementation
Pada tahap ini, pembuatan perangkat lunak dibagi menjadi program kecil (unit) yang dilakukan oleh beberapa programmer sekaligus dengan menggunakan kode-kode bahasa pemrograman tertentu tanpa mengganggu sistem lain secara keseluruhan. Setiap program kecil akan dilakukan pengujian dan pemeriksaan terhadap fungsionalitas, apakah sudah memenuhi kriteria yang diinginkan atau belum. Proses penulisan sinkode (coding) aplikasi mengacu pada dokumen-dokumen yang telah dibuat pada tahap sebelumnya.
Integration & Testing
Pada tahap ini, seluruh program kecil (unit) yang dikembangkan dan telah diuji pada tahap sebelumnya akan diintegrasikan dalam sistem secara keseluruhan. Selanjutnya dilakukan verifikasi dan pengujian sistem apakah perangkat lunak telah sesuai dengan spesifikasi kebutuhan pengguna atau terdapat error dalam sistem sebelum kemudian diperbaiki ulang.
Operation & Maintenance
Tahap ini merupakan tahap akhir dari metode waterfall. Perangkat lunak yang telah dibuat akan dioperasikan pengguna dan dilakukan pemeliharaan. Pemeliharaan adalah proses memperbaiki aplikasi dari setiap error atau bug, peningkatan kinerja aplikasi, penambahan program kecil (unit) baru untuk pengembangan aplikasi, dan penyesuaian sistem sesuai dengan kebutuhan pengguna.
Kelebihan Model Waterfall
Pengembangan perangkat lunak menggunakan model waterfall memiliki beberapa kelebihan, diantaranya adalah sebagai berikut:
Workflow yang jelas Model waterfall menyediakan serangkaian alur kerja sistem yang terdefinisi dengan baik dan juga dapat diskalakan. Setiap tim memiliki tugas dan tanggung jawab sesuai dengan bidang keahliannya masing-masing. Di samping itu, kita juga dapat bekerja sesuai dengan jadwal yang diberikan.
Hasil dokumentasi yang baik Waterfall merupakan pendekatan yang sangat metodis, di mana semua informasi dicatat dengan benar dan didistribusikan dengan cepat dan akurat kepada setiap anggota tim. Dokumentasi ini akan memudahkan setiap tim untuk mengikuti seluruh instruksi yang ada dalam dokumentasi tersebut.
Dapat menghemat biaya Keuntungan selanjutnya tentunya dari segi sumber daya dan biaya yang dikeluarkan oleh perusahaan yang menggunakan model ini. Dalam hal ini, klien tidak boleh mengganggu pekerjaan tim pengembang aplikasi. Oleh karena itu, biayanya lebih murah. Berbeda dengan metodologi Agile, klien dapat memberikan pendapat dan umpan balik kepada tim pengembang untuk mengubah atau menambahkan beberapa fungsi. Jadi perusahaan akan menghabiskan lebih sumber daya dan biaya daripada menggunakan waterfall..
Digunakan untuk pengembangan software berskala besar Metode ini dianggap sangat cocok untuk melakukan pengembangan aplikasi skala besar yang membutuhkan banyak orang dan alur kerja yang kompleks. Namun, model ini juga dapat digunakan untuk proyek kecil dan menengah. Tentunya akan disesuaikan dengan kondisi dan kebutuhan masing-masing proyek.
Kekurangan Model Waterfall
Pengembangan perangkat lunak menggunakan model waterfall memiliki beberapa kelemahan, diantaranya adalah sebagai berikut:
Membutuhkan tim yang solid Menggunakan model waterfall membutuhkan kerjasama dan koordinasi yang baik dari masing-masing tim. Jika salah satu tim tidak dapat melaksanakan tugas dengan semestinya, maka akan berdampak terhadap alur kerja tim yang lain.
Masih kurangnya fleksibilitas Karena seluruh tim dituntut untuk bekerja sesuai dengan arahan dan petunjuk yang telah ditetapkan di awal proyek, klien tidak dapat mengeluarkan pendapat dan feedback kepada tim pengembang. Klien hanya dapat memberikan masukan pada tahap awal pengembangan perangkat lunak.
Tidak dapat melihat gambaran sistem dengan jelas Model waterfall tidak dapat memberikan gambaran yang jelas kepada klien, berbeda dengan model agile yang dapat terlihat dengan jelas meskipun masih dalam tahap proses pengembangan.
Membutuhkan waktu yang lebih lama Proses pengembangan menggunakan model waterfall cenderung lebih lama jika dibandingkan dengan model SDLC lainnya. Hal ini karena setiap fase yang dijalankan, dilakukan secara bertahap, sehingga menambah waktu yang dibutuhkan. Misalnya, tim pengembang tidak dapat menyelesaikan proses pengkodean jika tim desainer belum menyelesaikan desain aplikasi.
Kesimpulan
Meskipun terlihat sederhana, model waterfall sangat sulit dalam praktiknya. Tidak dapat kembali ke fase sebelumnya membuat pendekatan waterfall tidak praktis di banyak skenario dalam dunia nyata. Karakteristik lain dari Waterfall adalah skala waktu cenderung lebih besar dibanding model lain seperti AGILE dan sebagainya. Setiap fase waterfall dapat berlangsung selama berbulan-bulan (berbeda dengan kebanyakan proyek AGILE yang hanya berhari-hari atau mungkin berminggu-minggu).
Efek gabungan dari skala waktu yang lama dan tidak dapat kembali, membuat Waterfall umumnya tidak responsif terhadap perubahan kebutuhan. Ini berarti akan meningkatkan kemungkinan untuk menghasilkan produk yang meleset dari sasaran. Namun jika kita memiliki situasi dimana tingkat ketidakpastian relatif rendah, maka Waterfall kemungkinan dapat berfungsi sebaik pendekatan lain, tetapi ini adalah situasi yang jarang terjadi.
Terdapat berbagai macam model dan pendekatan dalam proses pengembangan perangkat lunak, dimana setiap model tersebut memiliki kelebihan dan kekurangannya masing-masing. Terlalu banyak ketidakpastian, sehingga pilihan terbaik adalah menyesuaikan metodologi dengan sifat masalah daripada memaksakan semua masalah ke salah satu dari model tersebut. Singkatnya, kita harus memperhatikan kondisi dan kebutuhan dari masing-masing proyek sebelum memilih salah satu metodologi yang akan digunakan dalam pengembangan.
Model V adalah salah satu model proses pengembangan lunak (juga berlaku untuk perangkat keras) yang merupakan variasi representasi dari model waterfall.[1] Model V[2] menggambarkan hubungan dari aksi jaminan kualitas (quality assurance) ke aksi yang berhubungan dengan komunikasi, pemodelan, dan aktivitas pembangunan awal. Ketika tim pengembang perangkat lunak bergerak ke sisi kiri V, kebutuhan dari masalah dasar disempurnakan menjadi representasi yang lebih rinci dan teknis dari masalah dan solusinya. Setelah kode dihasilkan, tim bergerak ke sisi kanan V, yang pada dasarnya melakukan serangkaian tes (tindakan penjaminan kualitas) yang memvalidasi masing-masing model yang dibuat saat tim bergerak ke sisi kiri. Pada kenyataannya, tidak ada perbedaan mendasar antara siklus hidup klasik (classic life cycle) dan model V. Model V menyediakan cara memvisualisasikan bagaimana tindakan verifikasi dan validasi diterapkan pada pekerjaan teknik sebelumnya.[3]
Sejarah dan Penerapan Model V
Konsep model V dikembangkan secara bersamaan, tetapi secara independen, di Jerman dan di Amerika Serikat pada akhir 1980-an. Model V Jerman pada awalnya dikembangkan oleh IABG di Ottobrunn, dekat Munich, bekerja sama dengan Kantor Federal untuk Teknologi dan Pengadaan Pertahanan di Koblenz, untuk Kementerian Pertahanan Federal. Kemudian model V diambil alih oleh Kementerian Federal Dalam Negeri untuk domain otoritas publik sipil di musim panas 1992.[4]
Model Amerika Serikat V, seperti yang didokumentasikan pada tahun 1991 di proceedings for the National Council on Systems Engineering (NCOSE; sekarang INCOSE sejak tahun 1995) dikembangkan untuk sistem satelit yang melibatkan perangkat keras, perangkat lunak, dan interaksi manusia.[5]
Model V pertama kali muncul di Hughes Aircraft sekitar tahun 1982 sebagai bagian dari upaya pra-proposal untuk program FAA Advanced Automation System (AAS). Model V akhirnya membentuk strategi uji untuk proposal Hughes AAS Design Competition Phase (DCP). Hal itu dibuat untuk menunjukkan uji dan pendekatan integrasi yang didorong oleh tantangan baru untuk memunculkan cacat laten dalam perangkat lunak. Perlunya tingkat deteksi cacat laten yang baru ini didorong oleh tujuan untuk mulai mengotomatiskan proses pemikiran dan perencanaan pengendali lalu lintas udara seperti yang dibayangkan oleh program automated enroute air traffic control (AERA) yang otomatis. Alasan model V sangat kuat berasal dari budaya Hughes yang menggabungkan semua teks dan analisis ke gambar multi dimensi. Itu adalah dasar dari Sequential Thematic Organisation of Publications (STOP)[6] yang dibuat oleh Hughes pada tahun 1963 dan digunakan sampai Hughes didivestasikan oleh Howard Hughes Medical Institute pada tahun 1985[7]
Departemen Pertahanan Amerika Serikat menempatkan interaksi proses rekayasa sistem ke dalam hubungan model V.[8] Saat ini telah banyak ditemukan aplikasi dalam program komersial maupun pertahanan. Penggunaan utamanya adalah dalam manajemen proyek dan di seluruh siklus hidup proyek.[9][10] Satu karakteristik mendasar dari model V AS adalah bahwa waktu dan kematangan bergerak dari kiri ke kanan dan tidak dapat mundur dalam waktu. Semua iterasi berada di sepanjang garis vertikal ke level yang lebih tinggi atau lebih rendah dalam hierarki sistem.[9][10][5]
Fase Verifikasi
Requirement Analysis
Dalam rekayasa sistem dan rekayasa perangkat lunak, analisis kebutuhan mencakup tugas-tugas yang digunakan untuk menentukan kebutuhan atau kondisi yang harus dipenuhi untuk produk atau proyek baru atau yang diubah, dengan mempertimbangkan kebutuhan yang mungkin bertentangan dari berbagai pemangku kepentingan, menganalisis, mendokumentasikan, memvalidasi, dan mengelola kebutuhan perangkat lunak atau sistem.[11]
Architectural Design
Fase desain arsitektur komputer dan arsitektur perangkat lunak juga dapat disebut sebagai desain tingkat tinggi. Dasar dalam memilih arsitektur adalah bahwa ia harus menyadari semua yang terdiri dari daftar modul, fungsionalitas singkat dari masing-masing modul, hubungan antarmuka, dependensi, tabel basis data, diagram arsitektur, detail teknologi dll. Desain integration testing dilakukan dalam fase ini.[12]
Component Design
Fase ini adalah tempat komponen perangkat lunak yang sebenarnya dirancang. Tahap ini mendefinisikan logika aktual untuk masing-masing dan setiap komponen sistem. Diagram kelas dengan semua metode dan hubungan antar kelas berada di bawah LLD (Low level design). Desain unit testing atau component testing dibuat dalam fase ini.[12]
Fase Validasi
Unit testing
Dimulai dari bawah, level tes pertama adalah pengujian komponen, kadang-kadang disebut unit testing. Pengujian ini melibatkan pemeriksaan bahwa setiap fitur yang ditentukan dalam desain komponen telah diimplementasikan dalam komponen. Pengecekan ini berfokus pada masing-masing komponen secara terpisah, memastikan bahwa komponen tersebut berfungsi dengan baik sebagai sebuah unit. Pengujian ini menggunakan teknik white box testing, yang menjalankan jalur tertentu dalam struktur kontrol modul untuk memastikan cakupan lengkap dan deteksi kesalahan maksimum.[1]
Integration testing
Integration testing adalah tes yang paling penting karena di sini sistem testing dilakukan dengan metode integratif. Pengujian Ini membahas perakitan dan integrasi komponen untuk membentuk paket perangkat lunak lengkap. Pengujian ini menggunakan teknik black box testing untuk mengatasi masalah yang terkait dengan masalah verifikasi dan pembangunan program.[1]
System testing
Setelah seluruh sistem dibangun maka sistem harus diuji terhadap spesifikasi sistem untuk memeriksa apakah sistem tersebut telah memberikan fitur yang diperlukan. System testing masih berfokus pada pengembang, meskipun pengembang spesialis yang dikenal sebagai penguji sistem (tester) biasanya dipekerjakan untuk melakukannya. Intinya system testing bukan tentang memeriksa bagian-bagian individu dari desain, tetapi tentang memeriksa sistem secara keseluruhan. System testing dapat melibatkan sejumlah jenis tes spesialis untuk melihat apakah seluruh kebutuhan fungsional dan non-fungsional telah dipenuhi.[1]
Acceptance testing
Acceptance testing memeriksa sistem terhadap kebutuhan pengguna. Hal ini mirip dengan system testing bahwa seluruh sistem diperiksa tetapi perbedaan penting adalah perubahan fokusnya. System testing memeriksa bahwa sistem yang ditentukan telah diberikan, sedangkan acceptance testing memeriksa bahwa sistem memberikan apa yang diminta. Pelanggan dan bukan pengembang harus selalu melakukan acceptance testing. Pelanggan tahu apa yang diperlukan dari sistem untuk mencapai nilai dalam bisnis dan merupakan satu-satunya orang yang memenuhi syarat untuk membuat penilaian itu. Bentuk-bentuk pengujian dapat mengikuti system testing, tetapi umumnya pengujian ini berdasarkan kebutuhan bisnis. Pengujian ini dilakukan untuk memverifikasi suatu produk telah memenuhi persyaratan yang ditentukan pelanggan, pelanggan biasanya melakukan pengujian jenis ini pada produk yang dikembangkan secara eksternal.[1]
Kelebihan dan Kekurangan Model V
Keuntungan besar dari model V adalah sangat fleksibel. Ini mendukung penyatuan proyek serta penambahan dan penghapusan metode dan alat secara dinamis. Pada setiap awal proyek, model V disesuaikan menjadi proyek model V tertentu sehingga sesuai dengan proyek. Sangat mudah untuk menambahkan metode dan alat baru yang muncul dan menghapus metode dan alat yang lama. Model V dikembangkan dan dipelihara untuk umum. Para pengguna model V berpartisipasi setiap tahun di papan kontrol perubahan untuk memproses semua permintaan perubahan yang diterima.[2]
Kelemahan-kelemahan besar dari model V adalah model V berorientasi pada proyek siklus hidup dan hanya digunakan sekali selama proyek. Hal itu tidak mencakup seluruh organisasi. Organisasi yang menggunakannya model V akan membutuhkan model proses pelengkap di tingkat organisasi. Model-V tidak melakukan self-critic, yang artinya tidak menunjukkan kelemahan dan keterbatasan model V. Alih-alih model ini mendaftar banyak keuntungan tanpa menjelaskan lebih lanjut. Beberapa kegiatan dalam model V dijelaskan dalam tingkat yang terlalu abstrak. Tidak dapat diketahui apa yang termasuk dan apa yang dikecualikan. Dalam hal ini terlalu fleksibel. Meninggalkan terlalu banyak keputusan bagi pengguna model.[2]
- ^ a b c d e Yadav, Ravi (2012). "Improvement in the V-Model". International Journal ofScientific & Engineering Research. 3 (2).
- ^ a b c Bucanac, C., “The V-Model,” University of Karlskrona/Ronneby, January 1999, downloadable from www.bucanac.com/documents/The_V-Model.pdf.
- ^ Pressman, Roger S. (2015). Software engineering : a practitioner's approach. McGraw-Hill Education. ISBN 9781259253157. OCLC 949696534.
- ^ "V-Model Lifecycle Process Model". v-modell.iabg.de. Archived from the original on March 3, 2016. Retrieved December 24, 2015.
- ^ a b Forsberg, K. and Mooz, H., "The Relationship of Systems Engineering to the Project Cycle" Archived2009-02-27 at the Wayback Machine, First Annual Symposium of the National Council On Systems Engineering (NCOSE), October 1991
- ^ "Sequential Thematic Organization of Publications (STOP)". Archived from the original on February 3, 2008. Retrieved December 24, 2015.
- ^ Sobkiw, Walter (2008-01-01). Sustainable Development Possible with Creative System Engineering. ISBN 978-0615216300.
- ^ "A New Systems Engineering Model and an Old, Familiar Friend; Figure 2 V-9 Process Interactions" (PDF). Defense AT&L. Apr 2006. p. 51. Retrieved 7 Apr 2016.
- ^ a b Forsberg, K., Mooz, H., Cotterman, H. Visualizing Project Management, 3rd edition, John Wiley and Sons, New York, NY, 2005. Pages 108-116, 242-248, 341-360.
- ^ a b International Council On Systems Engineering (INCOSE), Systems Engineering Handbook Version 3.1,August 2007, pages 3.3 to 3.8
- ^ Kotonya, G. and Sommerville, I. 1998. Requirements Engineering: Processes and Techniques Chichester, UK: John Wiley and Sons.
- ^ a b "What is V-model- advantages, disadvantages and when to use it?".
Star Lifecycle Model
- https://www.cermati.com/artikel/brainstorming
- https://osc.medcom.id/community/analisis-model-waterfall-pengertian-tahapan-kelebihan-dan-kekurangan-4352
- https://p2k.stekom.ac.id/ensiklopedia/Model_V
- https://premiere23.blogspot.com/p/simpleinteraction-design-model-simple.html
- https://premiere23.blogspot.com/p/star-life-cyclemodel-star-lifecyle.html




Komentar
Posting Komentar