Model V

Model V

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]

  1. ^ a b c d e Yadav, Ravi (2012). "Improvement in the V-Model". International Journal ofScientific & Engineering Research. 3 (2). 
  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.
  3. ^ Pressman, Roger S. (2015). Software engineering : a practitioner's approach. McGraw-Hill Education. ISBN 9781259253157. OCLC 949696534. 
  4. ^ "V-Model Lifecycle Process Model". v-modell.iabg.de. Archived from the original on March 3, 2016. Retrieved December 24, 2015.
  5. ^ 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
  6. ^ "Sequential Thematic Organization of Publications (STOP)". Archived from the original on February 3, 2008. Retrieved December 24, 2015.
  7. ^ Sobkiw, Walter (2008-01-01). Sustainable Development Possible with Creative System Engineering. ISBN 978-0615216300.
  8. ^ "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.
  9. ^ 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.
  10. ^ a b International Council On Systems Engineering (INCOSE), Systems Engineering Handbook Version 3.1,August 2007, pages 3.3 to 3.8
  11. ^ Kotonya, G. and Sommerville, I. 1998. Requirements Engineering: Processes and Techniques Chichester, UK: John Wiley and Sons.
  12. ^ a b "What is V-model- advantages, disadvantages and when to use it?".