5. V - Model

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. Product State 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:
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 lima main activity:
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.
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.

4. Waterfall Process Model

Gambar di atas adalah tahapan umum dari model proses ini. Akan tetapi Roger S. Pressman memecah model ini menjadi 6 tahapan meskipun secara garis besar sama dengan tahapan-tahapan model waterfall pada umumnya.

Model ini sering disebut dengan “classic life cycle” atau model waterfall. Model ini adalah model yang muncul pertama kali yaitu sekitar tahun 1970 sehingga sering dianggap kuno, tetapi merupakan model yang paling banyak dipakai didalam Software Engineering (SE). Model ini melakukan pendekatan secara sistematis dan urut mulai dari level kebutuhan sistem lalu menuju ke tahap analisis, desain, coding, testing / verification, dan maintenance. Disebut dengan waterfall karena tahap demi tahap yang dilalui harus menunggu selesainya tahap sebelumnya dan berjalan berurutan. Sebagai contoh tahap desain harus menunggu selesainya tahap sebelumnya yaitu tahap requirement.

Berikut adalah penjelasan dari tahap-tahap yang dilakukan di dalam model ini menurut Pressman:

• System / Information Engineering and Modeling. Permodelan ini diawali dengan mencari kebutuhan dari keseluruhan sistem yang akan diaplikasikan ke dalam bentuk software. Hal ini sangat penting, mengingat software harus dapat berinteraksi dengan elemen-elemen yang lain seperti hardware, database, dsb. Tahap ini sering disebut dengan Project Definition.
• Software Requirements Analysis. Proses pencarian kebutuhan diintensifkan dan difokuskan pada software. Untuk mengetahui sifat dari program yang akan dibuat, maka para software engineer harus mengerti tentang domain informasi dari software, misalnya fungsi yang dibutuhkan, user interface, dsb. Dari 2 aktivitas tersebut (pencarian kebutuhan sistem dan software) harus didokumentasikan dan ditunjukkan kepada pelanggan.
• Design. Proses ini digunakan untuk mengubah kebutuhan-kebutuhan diatas menjadi representasi ke dalam bentuk “blueprint” software sebelum coding dimulai. Desain harus dapat mengimplementasikan kebutuhan yang telah disebutkan pada tahap sebelumnya. Seperti 2 aktivitas sebelumnya, maka proses ini juga harus didokumentasikan sebagai konfigurasi dari software.
• Coding. Untuk dapat dimengerti oleh mesin, dalam hal ini adalah komputer, maka desain tadi harus diubah bentuknya menjadi bentuk yang dapat dimengerti oleh mesin, yaitu ke dalam bahasa pemrograman melalui proses coding. Tahap ini merupakan implementasi dari tahap design yang secara teknis nantinya dikerjakan oleh programmer.
• Testing / Verification. Sesuatu yang dibuat haruslah diujicobakan. Demikian juga dengan software. Semua fungsi-fungsi software harus diujicobakan, agar software bebas dari error, dan hasilnya harus benar-benar sesuai dengan kebutuhan yang sudah didefinisikan sebelumnya.
• Maintenance. Pemeliharaan suatu software diperlukan, termasuk di dalamnya adalah pengembangan, karena software yang dibuat tidak selamanya hanya seperti itu. Ketika dijalankan mungkin saja masih ada errors kecil yang tidak ditemukan sebelumnya, atau ada penambahan fitur-fitur yang belum ada pada software tersebut. Pengembangan diperlukan ketika adanya perubahan dari eksternal perusahaan seperti ketika ada pergantian sistem operasi, atau perangkat lainnya.

Mengapa model ini sangat populer??? Selain karena pengaplikasian menggunakan model ini mudah, kelebihan dari model ini adalah ketika semua kebutuhan sistem dapat didefinisikan secara utuh, eksplisit, dan benar di awal project, maka SE dapat berjalan dengan baik dan tanpa masalah. Meskipun seringkali kebutuhan sistem tidak dapat didefinisikan seeksplisit yang diinginkan, tetapi paling tidak, problem pada kebutuhan sistem di awal project lebih ekonomis dalam hal uang (lebih murah), usaha, dan waktu yang terbuang lebih sedikit jika dibandingkan problem yang muncul pada tahap-tahap selanjutnya.

Meskipun demikian, karena model ini melakukan pendekatan secara urut / sequential, maka ketika suatu tahap terhambat, tahap selanjutnya tidak dapat dikerjakan dengan baik dan itu menjadi salah satu kekurangan dari model ini. Selain itu, ada beberapa kekurangan pengaplikasian model ini, antara lain adalah sebagai berikut:

• Ketika problem muncul, maka proses berhenti, karena tidak dapat menuju ke tahapan selanjutnya. Bahkan jika kemungkinan problem tersebut muncul akibat kesalahan dari tahapan sebelumnya, maka proses harus membenahi tahapan sebelumnya agar problem ini tidak muncul. Hal-hal seperti ini yang dapat membuang waktu pengerjaan SE.
• Karena pendekatannya secara sequential, maka setiap tahap harus menunggu hasil dari tahap sebelumnya. Hal itu tentu membuang waktu yang cukup lama, artinya bagian lain tidak dapat mengerjakan hal lain selain hanya menunggu hasil dari tahap sebelumnya. Oleh karena itu, seringkali model ini berlangsung lama pengerjaannya.
• Pada setiap tahap proses tentunya dipekerjakan sesuai spesialisasinya masing-masing. Oleh karena itu, ketika tahap tersebut sudah tidak dikerjakan, maka sumber dayanya juga tidak terpakai lagi. Oleh karena itu, seringkali pada model proses ini dibutuhkan seseorang yang “multi-skilled”, sehingga minimal dapat membantu pengerjaan untuk tahapan berikutnya.

Menurut saya, tahapan-tahapan model ini sudah cukup baik dalam artian minimal untuk melakukan SE, maka harus ada tahapan-tahapan ini. Tahapan-tahapan ini jugalah yang digunakan oleh model-model yang lain pada umumnya. Ada filosofi yang mengatakan sesuatu yang sukses diciptakan pertama kali, maka akan terus dipakai di dalam pengembangannya. Hal ini juga berlaku pada waterfall model ini. Mungkin dapat dikatakan bahwa inilah standar untuk melakukan SE.

Akan tetapi, yang mungkin menjadi banyak pertimbangan mengenai penggunaan dari model ini adalah metode sequential-nya. Mungkin untuk awal-awal software diciptakan, hal ini tidak menjadi masalah, karena dengan berjalan secara berurutan, maka model ini menjadi mudah dilakukan. Sesuatu yang mudah biasanya hasilnya bagus. Oleh karena itu model ini sangat populer. Akan tetapi, seiring perkembangan software, model ini tentu tidak bisa mengikutinya. Yang menjadi kelemahan adalah pada pengerjaan secara berurutan tadi, seperti yang sudah saya utarakan sebelumnya. Kelemahan-kelemahan yang lain juga sudah saya utarakan di atas, atau bahkan masih ada yang lainnya.

Dari sini, nantinya akan dikembangkan model-model yang lain, bahkan ada tahap evolusioner dari suatu model proses untuk mengatasi kelemahan-kelemahan tadi. Meskipun secara tahapan masih menggunakan standar tahapan waterfall model. Kesimpulannya adalah ketika suatu project skalanya sedang mengarah kecil bisa menggunakan model ini. Akan tetapi kalau sudah project besar, tampaknya kesulitan jika menggunakan model ini.

3. Siklus Hidup Untuk Pengembangan ( RAD : Linier Sequential)

• Project Set-Up

Menampilkan apakah suatu proyek adalah memiliki dampak apapun sering sangat sulit, namun dengan menetapkan tujuan yang tepat di tempat pertama sehingga dalam dapat dibilang bahwa dalam perancangan interaksi Project setup di tempatkan dalam urutan pertama.

• JAD workshops

Sebagaimana telah disebutkan bahwa dalam model ini JAD workshop yang paling dibutuhkan, Aplikasi desain Bersama (JAD) adalah proses yang digunakan di daerah prototyping siklus hidup Metode Pengembangan Sistem Dinamis (DSDM) untuk mengumpulkan kebutuhan bisnis saat mengembangkan sistem informasi baru bagi perusahaan. "Proses JAD juga mencakup pendekatan meningkatkan partisipasi pengguna, mempercepat pembangunan, dan meningkatkan kualitas spesifikasi.

Melalui workshop JAD pekerja pengetahuan dan spesialis IT yang mampu mengatasi kesulitan atau perbedaan antara kedua belah pihak mengenai sistem informasi baru. Lokakarya ini mengikuti agenda rinci dalam rangka untuk menjamin bahwa semua ketidakpastian antara pihak tertutup dan untuk membantu mencegah miskomunikasi.

• Iterative Design and Build ( Merancang dan membangun model)

Dalam tahap ini sebuah aplikasi atau interface yang akan dirancang, apa yang dibutuhkan user apa tujuan yang akan di capai.

• Engineer and Test Finall

Dalam alur kerja model ini Engineer and test finall merupakan tes akhir atau tahap dimana menjalankan aplikasi yang telah dirancang dan dibangun sebelumnya.

• Implementation review

Pada alur kerja perancangan di model ini implementation review atau pelaksanaan tinjauan. Pada tahap ini apikasi yang telah dirancang dan di jalankan pada test akhir dilakukan peninjauan, yang mana berfungsi unuk melihat kesalahan dan memperbaiki nya sebelum di terima oleh user.

Model RAD
• Rapid Application Development
• Proses pengembangan s/w secara
sekuensial linier
• Kecepatan adaptasi yg tinggi, dapat dibuat
dgn cepat dgn pendekatan pembangunan
berbasis komponen
• Jika data, analisa jelas, dan lingkup kecil
maka RAD dapat digunakan dgn baik
• Sering juga disebut ‘versi high speed’ dari
model waterfall,
• Penekanan pd putaran pengembangan
yang pendek
• Pendekatan RAD mengikuti fase sbb ;
• Pemodelan Bisnis, aliran informasi dari
fungsi dimodelkan dgn menjawab ;
informasi apa yg mempengaruhi bisnis,
yang dimunculkan ?, siapa yg
memunculkan ?, Kenapa informasi
diberikan ?, Siapa yang memprosesnya ?
• Pemodelan Data ; Bagian dari pemodelan bisnis yang didefinisikan ke dalam sekumpulan objek data.
• Karakteristik (atribut) dari setiap objek
diidentifikasikan dan hubungannya
• Pemodelan Proses, objek data akan diimplementasikan pada fungsi bisnis.
• Deskripsi proses dibangun untuk penambahan modifikasi, penghapusan, atau pengambilan kembali objek data.
• Pembangkitan Aplikasi, Melakukan penggunaan kembali komponen yang ada (jika mungkin)
• Atau membuat kembali penggunaan kembli komponen jika dibutuhkan.
• Pengujian / pergantian, Proses RAD menekankan pada penggunaan kembali dan komponen program telah siap diuji

Kelemahan RAD
• Model yang besar (skala proyek), membutuhkan resources yg baik dan solid
• Membutuhkan komitmen pengembang dan user yang sama agar cepat selesai sesuai dengan rencana


Model Spiral
• Metode ini dirancang secara revolusioner dengan tahapan yang jelas, tetapi terbuka bagi partisipasi pemesan untuk ikut serta menentukan pemodelan sistem
• Metode ini lambat dan mahal karena setiap tahapan yang dilalui harus menikutsertakan pemesan
• Model ini merupakan perbaikan dari model waterfall dan prototype. Mengabungkan keuntungan model air terjun dan prototype dan memasukkan analissis resiko
• Spiral melibatkan proses iterasi, dimana setiap iterasi bekerja pada satu level produk dimulai dari level prototype awal sampai pada level s/w SIM yang diinginkan
• Setiap perpindahan level didahului analisa resiko

Kuadran spiral
• Customer communication : komunikasi
antar pengembang dan user secara efektif
tuk penentuan kebutuhan kerja
• Planning : mendefinisikan sumber daya,
batas waktu, resources
• Risk analysis : menentukan resiko teknis
dan manajemen
• Rekayasa : membuat satu atau lebih
aplikasi yang dapat diwakili
• Kontruksi dan release : mengkontruksi,
menguji, menginstall dan memberikan
pendukung user (doc dan training)
• Evaluasi user : feed back penilaian user

Model spiral
• Setiap untai mempresentasikan fase
proses s/w.
• Untai paling dalam mungkin berkenaan
dgn kelayakan sistem, dengan definisi
persyaratan sistem, dgn perancangan
sistem, dst.

2. Model Rancangan Interaksi Sederhana

 

Pada model rancangan interaksi sederhana ini input atau masukan hanya memiliki satu titik. yang mana masukan tersebut diidentifikasikan apakah sesuai dengan kebutuhan, lalu didesain sesuai dengan persyaratan yang telah ditetapkan. Setelah diDesain rancangan tersebut dibangun dan harus interaktif. Setelah itu barulah rancangan tersebut dievaluasi.

Evaluasi dapat dilakukan dimana saja, rancangan yang telah di evakuasi dapat kambali didesain ulang atau apakah rancangan tersebut tidak sesuai dengan kebutuhan user, maka alur tersebut akan terus berputar hingga pada tahap evaluasi tidak lagi terjadi kesalahan, baik dalam penetapan kebutuhan user maupun pendesainannya, sehingga pada tahap evaluasi terciptalah sebuah hasil akhir yang valid.

1. Model Siklus Hidup Star (Hartson & HIx,1998)

Dalam Siklus permodelan ini pengujian dilakukan terus menerus, tidak harus dikahir. Misalnya dimulai dari menentukan kosep desain (conceptual design ) dalam proses ini akan langsung terjadi evaluasi untuk langsung ternilai apakah sudah sesuai dengan kebutuhan user, bila belum maka akan terus berulang di evaluasi hingga benar-benar pas, selanjutnya apabila sudah pas, maka dari tahap evaluasi yang pertama aka lanjut ke proses yg selanjutnya yakni requirements/specification yakni memverifikasikan persyaratan rancangan tersebut, dan pada tahap itu juga langsung terjadi pengevaluasian seperti tahap pertama, dan selanjutnya akan tetap sama terjadi pada tahapan-tahapan selanjutnya yakni task analysis/fungsion analysis, pengimplementasian, prototyping hingga pada akhirnya terciptalah sebuah aplikasi yang sesuai dengan kebutuhan user. Intinya pada rancangan model ini pengevaluasian dilakukan disetiap tahapan tidak hanya pada tahapan akhir seperti model-model rancangan yang lainnya.