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-develop software 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.
o Nama dari activity menggambarkan nama dan nomor dari activity. Activity di sini dapat berupa main activity atau subactivity. Subactivity diberi nomor dengan notasi titik.
o Product 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
o Handling menggambarkan activity yang harus dilakukan. Jika main activity, maka subactivity, hubungan antar subactivity, dan hasil dari subactivity harus digambarkan.
o Recommendation 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
o Pada state planned product masih dalam masa perencanaan. Product belum exist. State ini merupakan initial state dari setiap product.
o Pada state being processed product sedang dalam pemrosesan dan dalam kontrol developer.
o Pada 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
o Pada 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.
- 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:
o Project 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.
o Placement/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.
o Contractor 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.
o Detailed 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.
o Cost/benefit analysis
Tujuan dari activity ini adalah untuk menentukan seberapa profitable solusi yang sudah direncanakan. Setiap solusi dievaluasi berdasarkan cost dan benefit-nya.
o Phase 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.
o Risk 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.
o Project 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.
o Information service/reporting
Tujuan dari activity ini adalah untuk membuat informasi tentang proyek available bagi customer, subcontractor, dan project member.
o Training/instruction
Tujuan dari activity ini adalah untuk memberikan training bagi project member sehingga mereka dapat memiliki pengetahuan yang diperlukan untuk melakukan role-nya.
o Supplying resources
Tujuan dari activity ini adalah untuk memberikan resource yang dibutuhkan agar goal dari proyek dapat tercapai.
o Allocation of work order
Tujuan dari activity ini adalah untuk melakukan pembagian kerja berdasarkan work order.
o Staff training
Tujuan dari activity ini adalah untuk memperkenalkan project member pada pekerjaan mereka. Tugas dari setiap project member dijelaskan dan diberitahukan.
o Project 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:
o System 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.
o System design
Termasuk dalam activity ini adalah pemilihan system architecture dan membuat integration plan untuk architecture tersebut.
o Software/ 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.
o Preliminary software design
Termasuk dalam activity ini adalah desain dari software architecture, di mana termasuk di dalamnya adalah menyelesaikan interface description dan meng-update software integration plan.
o Detailed software design
Pada activity ini software architecture dan interface description dijelaskan lebih lanjut. Spesifikasi dan detail untuk setiap module, component, dan database dibuat.
o Software implementation
Pada activity ini dilakukan implementasi dari module, component, dan database dalam beberapa tahap.
o Software integration
Pada activity ini dilakukan integrasi antara module, component, dan database.
o System integration
Pada activity ini dilakukan integrasi sistem. Software dan hardware component diintegrasikan berdasarkan system architecture.
o Transition 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
o Quality 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.
o Assessment preparation
Activity ini meliputi pembuatan assessment plan, di mana di dalamnya terdapat definisi dari assessment method, criteria, environment, dan test case.
o Process assessment of activity
Activity ini meliputi dilakukannya assessment pada proses untuk menentukan apakah proses tersebut memadai atau tidak.
o Product assessment
Activity ini meliputi dilakukannya assessment pada product.
o Quality 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:
o Configuration 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.
o Product and configuration management
Activity ini meliputi pengelolaan product library dengan melakukan pengkatalogan product.
o Change 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.
o Configuration 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.
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.
Referensi
| Address | Tanggal Akses |
| 27 Februari 2009 | |
| http://www.economy-point.org/v/v-model.html | 27 Februari 2009 |
| 28 Februari 2009 | |
| facweb.cti.depaul.edu/jnowotarski/se470/hernandez%20pres%20vmodel.ppt | 28 Februari 2009 |
| http://www.informatik.uni-bremen.de/uniform/gdpa | 28 Februari 2009 |
| http://v-modell.iabg.de/index.php?option=com_docman&task= cat_view&gid=16&Itemid=30 | 28 Februari 2009 |
Artikelnya bermanfaat kak, ini saya juga punya artikel tentang Model Proses Pada Rekayasa Perangkat Lunak, semoga bisa saling melengkapi
ReplyDeleteKelebihan dan Kekurangan Model Proses Pada Rekayasa Perangkat Lunak - MARKIJAR.Com