System requirements analysis merupakan main activity pertama dari submodel system development (SD). Main activity ini dapat dibagi menjadi beberapa subactivity sebagai berikut:
-Recording of actual status and analysis
-Description of application system
-Definition of critically and quality requirements
-Definition of marginal conditions
-User-level system structure
-Threat and risk analysis
-Realization of requirements controlling
-Generation of software maintenance and modification (SWMM) concept
Berikut ini adalah gambaran tentang subactivity dan hubungan antar subactivity yang ada pada system requirements analysis.
Gambar 1. System Requirements Analysis Subactivity
Gambaran product flow dari system requirements analysis dapat dilihat pada gambar di bawah ini.
Gambar 2. System Requirements Analysis
Recording Of Actual Status And Analysis
Subactivity ini berkonsentrasi pada user. Informasi tentang actual state harus dikumpulkan, dianalisa, dan didokumentasikan. Pada subactivity ini organization analysis dilakukan. Dalam melakukan organization analysis, beberapa aspek berikut perlu dipertimbangkan:
-Persiapan organization analysis (definisi objective/performance untuk user-level task dan analysis depth, pembuatan document untuk workshop atau questionnaires untuk interview).
-Integrasi business process (pemisahan main dan partial business process, pendefinisian interface antar business process, mapping business process ke actual state model).
-Analisa business process (evaluasi actual state model dengan bantuan orang yang berwenang atas business process tersebut, mencari weak point, redundancy, delay, dan penyebabnya).
-Evaluasi hasil analysis (pengumpulan dan pembuatan prioritas improvement yang mungkin dilakukan).
Hasil analisa actual state akan digunakan sebagai titik awal bagi pendefinisian structure dan process organizationrequirement dan juga digunakan sebagai dasar dari business process model dan realisasinya. Berikut ini adalah gambaran product flow dari subactivity ini.
Gambar 3. Recording Of Actual Status And Analysis
Description Of Application System
Pada subactivity ini dilakukan spesifikasi gambaran keseluruhan fungsionalitas sistem. Hal ini dilakukan dengan pembuatan preliminary system description yang menjadi dasar dari user requirement. Berikut ini adalah hal-hal yang perlu dipertimbangkan dalam melakukan subactivity ini:
-Perlu didefinisikan user-level task yang mana yang akan di-support oleh sistem. Oleh karena itu integrasi sistem ke dalam organisasi dan environment dari integrasi perlu dideskripsikan.
-Pendefinisian seluruh functionality yang akan ada pada final version dan prioritas pengembangannya.
-Pendefinisan application concept untuk memperoleh technical dan organizational application environment dan marginal condition.
-Pendefinisian estimasi kuantitatif yang dapat digunakan untuk membuat basic technical decision.
-Ketepatan gambaran keseluruhan fungsionalitas sistem.
-Penggunaan predefined user-level item harus dipertimbangkan. Kandidat yang mungkin untuk penggunaan kembali pada level user requirement harus ditentukan.
Gambaran product flow dari subactivity ini dapat dilihat pada gambar di bawah ini.
Gambar 4. Description Of Application System
Definition Of Criticality And Quality Requirements
Pada subactivity ini dilakukan pendefinisian dan justifikasi criticality dari sistem. Selain itu dilakukan pendefinisian requirement dengan mempertimbangkan quality characteristic dari sudut pandang user. Gambaran tentang product flow yang ada pada subactivity ini dapat dilihat pada gambar di bawah ini.
Gambar 5. Definition Of Criticality And Quality Requirements
Definition Of Marginal Conditions
Pada subactivity ini dilakukan spesifikasi marginal condition berdasarkan technical dan organizational requirement. Technical marginal condition biasanya adalah general requirement yang berhubungan dengan interface dari sistem yang dilakukan pada technical design. Sedangkan organizational marginal condition biasanya berhubungan dengan komunikasi, kerja sama, dan koordinasi antara individual contractor. Berikut ini adalah gambaran tentang product flow dari subactivity ini.
Gambar 6. Definition Of Marginal Conditions
User-Level System Structure
Pada subactivity ini dibuat struktur dan gambaran dari sistem berdasarkan sudut pandang user. Termasuk di dalamnya adalah spesifikasi goal dari business process. Untuk menggambarkan bagaimana sistem berfungsi dan mendefinisikan business process, dibuat gambaran interaksi antara user dengan sistem. Gambaran tentang product flow yang ada pada subactivity ini dapat dilihat pada gambar berikut ini.
Gambar 7. User-Level System Structure
Threat And Risk Analysis
Pada subactivity ini dilakukan pendefinisan dan evaluasi threat dan risk yang ada dengan mempertimbangkan probabilitas terjadinya dan besar dampak yang mungkin timbul jika threat dan risk tersebut benar-benar terjadi. Berikut ini adalah gambaran tentang product flow dari subactivity ini.
Gambar 8. Threat And Risk Analysis
Realization Of Requirements Controlling
Pada subactivity ini dilakukan evaluasi terhadap user requirement yang sudah didefinisikan dengan mempertimbangkan feasibility dan profitability. Berikut ini adalah kriteria-kriteria yang digunakan dalam evaluasi user requirement:
-Plausibility dari defined requirement
-Plausibility dari security requirement
-Kompleksitas dari specified requirement
-Kemungkinan untuk penggunaan off-the-shelf product
-Kemungkinan dilakukannya implementasi pada infrastruktur yang sudah ada
-Pengurangan project-specific instance
-Estimasi biaya untuk individual requirement
Hasil dari evaluasi dapat berupa saran untuk perubahan atau pengurangan requirement. Jika hal ini terjadi, harus dipastikan bahwa dilakukan dokumentasi terhadap manfaat yang diperoleh dengan dilakukannya perubahan atau pengurangan tersebut. Selain itu harus dipastikan pula bahwa perubahan atau pengurangan itu tidak akan menyebabkan goal dari proyek tidak tercapai. Gambaran tentang product flow dari subactivity ini dapat dilihat pada gambar di bawah ini.
Gambar 9. Realization Of Requirements Controlling
Generation Of Software Maintenance And Modification (SWMM) Concept
Tujuan dari subactivity ini adalah pendefinisan semua organizational dan technical measure yang perlu dilakukan pada software maintenance and modification (SWMM). Untuk melakukannya, strategi software maintenance and modification SWMM) harus ditentukan. Berikut ini adalah hal-hal yang perlu dipertimbangkan dalam hubungannya dengan software maintenance and modification (SWMM):
-Struktur organisasi dari software maintenance and modification (SWMM)
-Personnel resource yang dibutuhkan
-Alokasi kompetensi dan responsibility dalam organisasi
-Process description untuk implementasi software maintenance and modification (SWMM)
-Software maintenance and modification (SWMM) off-the-shelf product
-Technical installation yang diperlukan
Gambaran tentang product flow dari subctivity ini dapat diihat pada gambar berikut ini.
Gambar 10. Generation Of Software Maintenance And Modification Concept
Documents
Berikut ini adalah format dari document user requirements dan software maintenance and modification (SWMM) concept yang dihasilkan pada system requirements analysis.
Gambar 11. User Requirements
Gambar 12. Software Maintenance And Modification (SWMM) Concept
Pada tahun 1986, Federal Ministry for Defense negara Jerman memulai dua proyek teknologi informasi. Kedua proyek tersebut adalah software development environment for information system (SEU-IS) dan software development environment for weapon and weapon delivery systems (SEU-WS). Dalam pelaksanaan kedua proyek tersebut ada beberapa goal yang ingin dicapai yaitu:
-Membuat biaya dan proses-proses yang ada pada seluruh software development process menjadi jelas.
-Menerapkan minimum standard untuk menjamin kualitas software yang dihasilkan.
-Melakukan standarisasi dan membuat software development process lebih transparan.
V Model dikembangkan untuk mewujudkan goal di atas. Hal ini disebabkan karena model-model yang ada pada masa itu dirasa belum sesuai dengan kebutuhan yang ada.
Variant pertama V Model muncul pada tahun 1988 sebagai akibat dari proyek SEU-WS. Lalu pada tahun 1991, variant V Model yang lebih baru muncul karena proyek SEU-IS. Hal ini terus berlangsung. Begitu dirasa adanya kebutuhan untuk melakukan perubahan maka akan dikembangkan variant V Model yang baru.
Variant V Model yang akan dibahas dengan lebih spesifik di sini adalah variant V Model yang dikembangkan pada tahun 1997. Variant V Model ini muncul karena adanya perkembangan pada software development process (misal: object orientation).
Arsitektur
V Model terdiri dari 3 tahap. Secara garis besar tahap-tahap tersebut adalah seperti yang akan dijelaskan di bawah ini.
-Lifecycle process model
Lifecycle process model menjawab pertanyaan tentang apa yang harus dilakukan. Termasuk dalam tahap ini adalah menetapkan activity apa yang harus dilakukan, hasil apa yang diperoleh dari activity tersebut, dan apa saja yang ada di dalam hasil tersebut.
-Allocation of methods
Allocation of methods menjawab pertanyaan bagaimana cara melakukannya. Termasuk dalam tahap ini adalah penentuan method apa yang akan digunakan untuk melakukan activity yang sudah ditetapkan pada tahap lifecycle process model.
-Functional tool requirements
Functional tool requirements menjawab pertanyaan tool apa yang bisa digunakan untuk melakukannya. Termasuk dalam tahap ini adalah penentuan functional characteristic apa yang harus dimiliki oleh tool yang akan digunakan untuk melakukan activity pada tahap lifecycle process model.
Pada setiap tahap di atas ada empat area of functionality yang dikenal dengan sebutan submodel. Keempat submodel tersebut adalah:
-Project management (PM)
Submodel ini merencanakan, me-monitor, dan mengontrol proyek. Selain itu submodel ini juga mengirimkan informasi pada submodel yang lain.
-System development (SD)
Submodel ini men-developsoftware yang ingin dibuat.
-Quality assurance (QA)
Submodel ini menspesifikasikan standar kualitas yang diinginkan dan memberitahukannya pada submodel yang lain. Submodel ini juga menspesifikasikan contoh test case dan kriteria untuk memastikan bahwa software yang dihasilkan dan proses untuk menghasilkannya berdasarkan dan sesuai dengan standar yang telah ditetapkan.
-Configuration management (CM)
Submodel ini melakukan administrasi software yang dihasilkan.
Gambaran tentang tahap, submodel, dan hubungan antara tahap dan submodel dalam V Model dapat dilihat pada gambar di bawah ini.
Gambar 1. Arsitektur V Model
Lifecycle Process Model
Lifecycle process model mempunyai beberapa basic element seperti yang akan dijelaskan berikut ini.
-Activitiy dan product
Activity adalah workstep dalam development process. Eksekusi dan hasil dari activityActivity dapat terdiri dari beberapa subactivity. Activity yang terletak pada level yang paling tinggi dikenal dengan sebutan main activity dan hasil dari activity adalah product. Activity mengubah state dari product atau activity mengubah product. Untuk setiap activityactivity description yang dibuat berdasarkan suatu activity pattern yang disebut activity schema. dideskripsikan dengan tepat. ada sebuah
Product dapat berupa document, software, atau hardware. Product adalah hasil dari activity. Seperti activity, product dapat dipecah menjadi beberapa subproduct. Product dideskripsikan dengan menggunakan product schema, di mana di dalamnya terdapat sinopsis pendek dari product dan daftar structural item dari product.
-Activity schema
Activity schema terdiri dari nama dari activity, product flow, handling, dan recommendationexplanation. Berikut ini adalah penjelasan yang lebih detail tentang masing-masing bagian dari activity schema tersebut.
oNama dari activity menggambarkan nama dan nomor dari activity. Activity di sini dapat berupa main activity atau subactivity. Subactivity diberi nomor dengan notasi titik.
oProduct flow menggambarkan flow dari product. Product flow menggambarkan input product dan output product dari activity. Pada input product, digambarkan dari activity mana input product berasal dan state dari input product. Pada output product, digambarkan ke activityoutput product akan dikirimkan dan state dari output product. mana
oHandling menggambarkan activity yang harus dilakukan. Jika main activity, maka subactivity, hubungan antar subactivity, dan hasil dari subactivity harus digambarkan.
oRecommendation dan explanation memberikan saran-saran untuk pelaksanaan activity dan memberikan penjelasan tentang definisi activity agar activity tersebut lebih mudah dimengerti.
-Product state
Product akan melalui berbagai macam state selama masa pembuatan dan pemrosesannya. Perubahan state product hanya dapat disebabkan oleh suatu activity. Pada activity schemastate dari product ketika memasuki suatu activity dan state dari product ketika keluar dari suatu activity. State dari product dapat dibedakan menjadi planned, being processed, submitted, dan accepted. Berikut ini adalah penjelasan setiap state tersebut secara lebih detail: digambarkan
oPada state plannedproduct masih dalam masa perencanaan. Product belum exist. State ini merupakan initial state dari setiap product.
oPada state being processed product sedang dalam pemrosesan dan dalam kontrol developer.
oPada state submitted product dianggap sudah selesai berdasarkan sudut pandang developer. Product lalu dikirimkan ke quality assurance (QA) untuk penilaian. Kalau quality assuranceproduct akan kembali ke state being processed. Kalau quality assurance (QA) menerima, maka product ke state accepted. (QA) menolak, maka
oPada state accepted product sudah diterima oleh quality assurance (QA) dan oleh karena itu product sudah siap untuk diedarkan. Product yang sudah diedarkan hanya dapat dimodifikasi jika version number product di-update.
State dari product dan transisinya dapat dilihat pada gambar di bawah ini.
Gambar 2. ProductState Dan Transisinya
-Organization dan role
Pembagian tugas kepada project member dilakukan berdasarkan role. Daftar role dibuat untuk setiap submodel. Setiap role mendefinisikan activity apa yang dilakukan, responsibility dari role, skill yang dibutuhan, pengetahuan yang dibutuhkan, dan ketergantungan role tersebut dengan role-role lainnya.
Organization dibentuk dengan memilih project member untuk setiap submodel dan memilih role untuk mereka. Sebuah role dapat diberikan ke satu atau lebih project member. Seorang project member juga dapat memiliki lebih dari satu role. Daftar role yang ada pada keempat submodel dari V Model dapat dilihat di bawah ini.
Tabel 1. Role
Submodel
Role
Project management (PM)
Project manager
Project leader
Legal representative
Project administrator
Controller
System development (SD)
System analyst
System designer
Software developer
Hardware developer
Technical author
Information technology (IT) representative
System development (SD) supervisor
Data administrator
Data protection
Specialist
Information technology (IT) security
Representative
System administrator
Quality assurance (QA)
Quality assurance (QA) manager
Assessor
Configuration management (CM)
Configuration management (CM) manager
Configuration management (CM) representative
Configuration management (CM) administrator
Penjelasan tentang keempat submodel yang ada dalam V Model dilihat dari sudut pandang lifecycle process model dapat dilihat di bawah ini.
-Project management (PM)
Submodel ini mengatur aktivitas inisialisasi, planning, dan monitoring proyek. Submodel ini terdiri dari empat belas main activity yaitu:
oProject initialization
Project initialization mendefinisikan organizational framework pada project manual. Tailoring dari V Model untuk suatu proyek tertentu dilakukan berdasarkan project criteria dan condition. Preliminary planning dilakukan berdasarkan project manual dan didokumentasikan di project plan.
oPlacement/procurement
Placement/procurement meliputi pengiriman permintaan proposal ke beberapa subcontractor yang mungkin digunakan, mengevaluasi response yang diberikan oleh subcontractor, dan menentukan penawaran yang paling menguntungkan secara ekonomi.
oContractor management
Tujuan dari activity ini adalah untuk melakukan supervisi terhadap kontrak yang sudah dibuat untuk memastikan bahwa kontrak dipenuhi, baik itu kontrak terhadap customer maupun kontrak terhadap subcontractor.
oDetailed planning
Tujuan dari activity ini adalah untuk membuat detailed plan dari proyek. Hal ini dilakukan dengan menggunakan preliminary plan dan spesifikasi yang terdapat pada project manual.
oCost/benefit analysis
Tujuan dari activity ini adalah untuk menentukan seberapa profitable solusi yang sudah direncanakan. Setiap solusi dievaluasi berdasarkan cost dan benefit-nya.
oPhase review
Setelah setiap project phase selesai dilakukan, maka dilakukan phase review. Phase review dilakukan untuk memeriksa status dari proyek berdasarkan project plan yang sudah dibuat.
oRisk management
Tujuan dari activity ini adalah untuk mendeteksi risk dari proyek sedini mungkin. Risk di-manage dengan cara melakukan preventive measure dan mensupervisi seberapa efektif langkah yang sudah dilakukan.
oProject control
Tujuan dari activity ini adalah untuk mengontrol perkembangan proyek. Jika proyek melenceng dari perencanaan, maka harus diambil tindakan untuk memperbaikinya supaya proyek dapat kembali berjalan sesuai dengan apa yang sudah direncanakan.
oInformation service/reporting
Tujuan dari activity ini adalah untuk membuat informasi tentang proyek available bagi customer, subcontractor, dan project member.
oTraining/instruction
Tujuan dari activity ini adalah untuk memberikan training bagi project member sehingga mereka dapat memiliki pengetahuan yang diperlukan untuk melakukan role-nya.
oSupplying resources
Tujuan dari activity ini adalah untuk memberikan resource yang dibutuhkan agar goal dari proyek dapat tercapai.
oAllocation of work order
Tujuan dari activity ini adalah untuk melakukan pembagian kerja berdasarkan work order.
oStaff training
Tujuan dari activity ini adalah untuk memperkenalkan project member pada pekerjaan mereka. Tugas dari setiap project member dijelaskan dan diberitahukan.
oProject completion
Tujuan dari activity ini adalah untuk closing dari proyek. Termasuk di dalamnya adalah penulisan final project report dan semua project experience.
-System development (SD)
Submodel ini melakukan regulasi terhadap semua activity yang berhubungan dengan pembuatan software. Submodel ini terdiri dari sembilan main activity yaitu:
oSystem requirement analysis
Termasuk dalam activity ini adalah pembuatan software requirement berdasarkan sudut pandang user atau dapat dikatakan sebagai pembuatan software requirement dari sudut pandang external.
oSystem design
Termasuk dalam activity ini adalah pemilihan system architecture dan membuat integration plan untuk architecture tersebut.
oSoftware/ hardware requirement analysis
Termasuk dalam activity ini adalah melakukan update terhadap technical requirement dan operational information dengan mempertimbangkan software dan hardware requirement. Hal ini dilakukan dengan menggunakan user requirement, system architecture, dan technical requirement yang sudah dibuat sebelumnya.
oPreliminary software design
Termasuk dalam activity ini adalah desain dari software architecture, di mana termasuk di dalamnya adalah menyelesaikan interface description dan meng-updatesoftware integration plan.
oDetailed software design
Pada activity ini software architecture dan interface description dijelaskan lebih lanjut. Spesifikasi dan detail untuk setiap module, component, dan database dibuat.
oSoftware implementation
Pada activity ini dilakukan implementasi dari module, component, dan database dalam beberapa tahap.
oSoftware integration
Pada activity ini dilakukan integrasi antara module, component, dan database.
oSystem integration
Pada activity ini dilakukan integrasi sistem. Software dan hardware component diintegrasikan berdasarkan system architecture.
oTransition to utilization
Termasuk dalam activity adalah hal-hal yang harus dilakukan untuk mengoperasikan sistem pada environment yang telah ditetapkan.
Gambaran tentang kesembilan main activity tersebut dapat dilihat pada gambar di bawah ini.
Gambar 3. Submodel System Development
-Quality assurance (QA)
Submodel ini mengatur activity dan product dari submodel lain dengan cara melakukan penilaian. Submodel ini terdiri dari limamain activity:
oQuality assurance initialization
Activity ini meliputi spesifikasi organizational dan procedural scope dari quality assurance activity. Semua spesifikasi untuk product dan proses didokumentasikan dalam quality assurance plan.
oAssessment preparation
Activity ini meliputi pembuatan assessment plan, di mana di dalamnya terdapat definisi dari assessment method, criteria, environment, dan test case.
oProcess assessment of activity
Activity ini meliputi dilakukannya assessment pada proses untuk menentukan apakah proses tersebut memadai atau tidak.
oProduct assessment
Activity ini meliputi dilakukannya assessment pada product.
oQuality assurance reporting
Activity ini meliputi evaluasi assessment report berdasarkan severity dari problem, klasifikasi problem, dan penyebab dari problem.
-Configuration management (CM)
Submodel ini menjamin bahwa suatu product dapat diidentifikasi setiap saat. Identifikasi ini dilakukan untuk mengontrol modifikasi dan menjamin integritas. Submodel ini terdiri dari empat main activity yaitu:
oConfiguration management planning
Activity ini meliputi pendefinisian organizational framework dan pendokumentasiannya dalam configuration management plan. Resource dan tool yang dibutuhkan juga didokumentasikan dalam configuration management plan.
oProduct and configuration management
Activity ini meliputi pengelolaan product library dengan melakukan pengkatalogan product.
oChange management
Activity ini meliputi change management yang dilakukan dalam 3 tahap. Pertama perubahan di-request dan di-register oleh configuration management. Kedua perubahan tersebut dievaluasi dan diambil keputusan apakah perubahan tersebut diterima atau ditolak. Terakhir, jika perubahan tersebut diterima maka perubahan tersebut akan diimplementasikan dan semua yang dipengaruhi oleh perubahan tersebut diberitahu.
oConfiguration management service
Termasuk di dalam activity ini adalah pengkatalogan software product, koordinasi interface, backup, release management, dan pencatatan project history.
Allocation Of Methods
Tahap ini mengatur pemilihan dan penerapaan method untuk semua submodel yang ada. Tahap ini mendukung lifecycle process model karena tahap ini menspesifikasikan bagaimana cara melakukannya sedangkan lifecycle process model menspesifikasikan apa yang harus dilakukan.
Ada dua jenis method, yaitu basic method dan complex method. Basic method mengarah pada prosedur yang menggambarkan beberapa aspek unik dari sistem (misal aspek functional atau aspek data oriented) atau bagian tertentu dari system development (misal analysis atau design). Basic method dapat dikategorisasikan. Kategori menggabungkan beberapa basic method yang menawarkan beberapa solusi yang berbeda untuk suatu problem tertentu.
Complex method mengarah pada prosedur yang menggabungkan berbagai macam methodical component dan mengintegrasikannya ke dalam satu method.
Untuk setiap activity, suatu method dipilih. Untuk membuat proses pemilihan ini lebih mudah, maka pada tahap ini telah digambarkan apa saja yang perlu dilakukan pada pemilihan method. Berikut ini struktur dari suatu method:
-Identifikasi dan definisi dari method
-Karakteristik umum dari method
-Keterbatasan method
-Spesifikasi dari penggunaan method (bagaimana method akan digunakan pada activity)
-Interface terhadap method lain yang saling mendukung, misal use case modeling mempunyai interface ke class object modeling, state transition modeling, dan interaction modeling
-Literature lain tentang method tersebut
Functional Tool Requirements
Tahap ini mengatur pemilihan dan penggunaan tool untuk semua submodel. Tahap ini mendukung lifecycle process model dan allocation of method.
Tool dapat didefinisikan sebagai suatu software product yang mendukung development, maintenance, atau modification dari suatu sistem teknologi informasi. Tool dikelompokkan menjadi beberapa service unit. Sebuah service unit mendefinisikan requirement untuk semua tool yang ada pada service unit tersebut. Service unit ini lalu dikelompokkan ke dalam suatu service complex. Service complex ini dapat berupa salah satu dari submodel.
Empat tahap dalam pemilihan tool adalah:
-Pertama dilakukan spesifikasi fungsionalitas apa saja yang harus dimiliki oleh tool berdasarkan fungsionalitas yang dibutuhkan pada proyek. Hasilnya adalah pemilihan beberapa service unit yang memenuhi fungsionalitas yang dibutuhkan proyek.
-Tahap kedua dapat dibagi dalam dua bagian. Bagian pertama adalah memilih service unit dan application condition untuk menggunakan tool sebagai input. Dalam melakukannya dipertimbangkan special environmental condition dan prioritas dari requirement. Hasilnya adalah functional requirement dari tool. Bagian kedua adalah menggunakan application condition untuk tool sebagai input. Bagian ini menspesifikasi technical dan organization requirement. Hasilnya adalah technical requirement dari tool.
-Pada tahap ketiga, functional dan technical requirement untuk tool dirangkum dan menghasilkan operational criteria catalogue yang menggambarkan final requirement dari tool.
-Pada tahap terakhir dilakukan perbandingan antar tool dengan bantuan tool description atau profile dan operational criteria catalogue. Hasilnya adalah applicable tool.
Kelebihan
V Model memiliki beberapa kelebihan. Kelebihan-kelebihan tersebut secara garis besar dapat dijelaskan seperti berikut:
-V Model sangat fleksibel. V Model mendukung project tailoring dan penambahan dan pengurangan method dan tool secara dinamik. Akibatnya sangat mudah untuk melakukan tailoring pada V Model agar sesuai dengan suatu proyek tertentu dan sangat mudah untuk menambahkan method dan tool baru atau menghilangkan method dan tool yang dianggap sudah obsolete.
-V Model dikembangkan dan di-maintain oleh publik. User dari V Model berpartisipasi dalam change control board yang memproses semua change request terhadap V Model.
Kekurangan
V Model juga memiliki beberapa kekurangan. Kekurangan-kekurangan tersebut yaitu:
-V Model adalah model yang project oriented sehingga hanya bisa digunakan sekali dalam suatu proyek.
-V Model terlalu fleksibel dalam arti ada beberapa activity dalam V Model yang digambarkan terlalu abstrak sehingga tidak bisa diketahui dengan jelas apa yang termasuk dalam activity tersebut dan apa yang tidak.
Penggunaan
V Model digunakan dalam proyek teknologi informasi di negara Jerman. Hal ini berlaku terutama untuk proyek teknologi informasi pada pada sektor pertahanan negara Jerman. Selain itu, V Model juga digunakan oleh software developer negara Jerman untuk proyek teknologi informasi lain.
