Macam-macam model life cycle software

Model Life Cycle Software

 1.Model Waterfall

           1.1 Sejarah model waterfall 

Nama model ini sebenarnya adalah “Linear Sequential Model”. Model ini sering disebut dengan “classic life cycle” atau model waterfall. Model ini pertama kali yang diperkenalkan oleh Winston Royce 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 berurutan. Disebut dengan waterfall karena tahap demi tahap yang dilalui harus menunggu selesainya tahap sebelumnya dan berjalan berurutan.

       1.2 Pengertian  Waterfall
Waterfall atau AIR terjun adalah model yang dikembangkan untuk pengembangan perangkat lunak, membuat perangkat lunak. model berkembang secara sistematis dari satu tahap ke tahap lain dalam mode seperti air terjun.

Model ini mengusulkan sebuah pendekatan kepada pengembangan software yang sistematikdan sekuensial yang mulai dari tingkat kemajuan sistem pada seluruh analisis, desain, kode, pengujian dan pemeliharaan. Model ini melingkupi aktivitas-aktivitas sebgai berikut : rekayasa dan pemodelan sistem informasi, analisis kebutuhan, desain, koding, mengujian dan pemeliharaan.
Model pengembangan ini bersifat linear dari tahap awal pengembangan system yaitu tahap perencanaan sampai tahap akhir pengembangan system yaitu tahap pemeliharaan. Tahapan berikutnya tidak akan dilaksanakan sebelum tahapan sebelumnya selesai dilaksanakan dan tidak bisa kembali atau mengulang ke tahap sebelumnya.

      1.      Tahapan atau fase model waterfal
      Ini adalah gambar tahapan atau fase yang paling umum tentang model waterfall

Akan tetapi Roger S. Pressman memecah model ini menjadi 6 tahapan meskipun secara garis besar sama dengan tahapan-tahapan model waterfall pada umumnya. Berikut adalah Gambar dan 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. 

b.  Karakteristik
Dalam model ini terdapat beberapa sifat-sifat yang menojol dan cenderung menjadi  permasalahan pada model waterfall.
·    Ketika problem muncul, maka proses berhenti karena tidak dapat menuju ke tahapan selanjutnya. Apabila terdapat kemungkinan problem tersebut muncul akibat kesalahan dari tahapan sebelumnya, maka proses harus membenahi tahapan sebelumnya agar problem ini tidak muncul.
·     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. 

c.       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.

     d. Kapan model waterfall di gunakan????? 
Salah satu model tradisional dan mudah yang tahapannya mengalir satu arah seperti air terjun         adalah Waterfall Model atau Linear Sequential Model. Pertanyaannya, kapan sebaiknya model tersebut digunakan?
Teori-teori lama menyimpulkan ada beberapa hal, yaitu:

1. Ketika semua persyaratan sudah dipahami dengan baik di awal pengembangan.
2. Definisi produk stabil dan tidak ada perubahan saat pengembangan untuk alasan apapun seperti perubahan eksternal, perubahan tujuan, perubahan anggaran atau perubahan teknologi. Untuk itu, teknologi yang digunakan pun harus sudah dipahami dengan baik.
3. Menghasilkan produk baru, atau versi baru dari produk yang sudah ada. Sebenarnya, jika menghasilkan versi baru maka sudah masuk incremental development, yang setiap tahapnya sama dengan Waterfall kemudian diulang-ulang.
4. Porting produk yang sudah ada ke dalam platform baru.

Dengan demikian, Waterfall dianggap pendekatan yang lebih cocok digunakan untuk proyek pembuatan sistem baru. Tetapi salah satu kelemahan paling dasar adalah menyamakan pengembangan perangkat keras dengan perangkat lunak dengan meniadakan perubahan saat pengembangan. Padahal, galat diketahui saat perangkat lunak dijalankan, dan perubahan-perubahan akan sering terjadi.      

1.3 Tahapan Pengembangan Dalam Waterfall

Tahap – tahap pengembangan waterfall model adalah
 1. Analisis dan definisi persyarat 

 Pelayanan, batasan, dan tujuan sistem ditentukan melalui konsultasi dengan user.
2. Perancangan sistem dan perangkat lunak
Kegiatan ini menentukan arsitektur sistem secara keseluruhan
3. Implementasi dan pengujian unit
Perancangan perangkat lunak direalisasikan sebagai serangkaian program
4. Integrasi dan pengujian sistem
Unit program diintegrasikan atau diuji sebagai sistem yang lengkap untuk menjamin bahwa persyaratan sitem telah terpenuhi

5. Operasi dan pemeliharaan

Merupakan fase siklus yang paling lama. Sistem diinstall dan dipakai. Perbaikan mencakup

koreksi dari berbagai error, perbaikan dan implementasi unit sistem dan pelayanan sistem.

1.4  Keuntungan dari Model Waterfall 
·  Merupakan model pengembangan paling handal dan paling lama digunakan.
·   Cocok untuk system software berskala besar.
·   Cocok untuk system software yang bersifat generic.
·    Pengerjaan project system akan terjadwal dengan baik dan mudah dikontrol.

 1.5  Kelemahan Waterfall 
·         Waktu pengembangan lama. hal ini dikarenakan input tahap berikutnya adalah output dari tahap sebelumnya. Jika satu tahap waktunya molor, maka waktu keseluruhan pengembangan juga ikut molor.
·         Biaya juga mahal, hal ini juga dikarenakan waktu pengembangan yang lama
·         Terkadang perangkat lunak yang dihasilkan tidak akan digunakan karena sudah tidak sesuai dengan requirement bisnis customer. hal ini juga dikarenakan waktu pengembangan yang lama. selain itu dikarenakan waterfall merupakan aliran yang linear, sehingga jika requirement berubah proses tidak dapat diulang lagi.
·         Karena tahap-tahapan pada waterfall tidak dapat berulang, maka model ini tidak cocok untuk pemodelan pengembangan sebuah proyek yang memiliki kompleksitas tinggi.
·         Meskipun waterfall memiliki banyak kelemahan yang dinilai cukup fatal, namun model ini merupakan dasar bagi model-model lain yang dikembangkan setelahnya. 

2. Rapid Application Development (RAD)
 2.1 Sejarah RAD
Siklus hidup Tradisional dirancang di tahun 1970an, dan masih banyak digunakan hingga saat ini, berdasarkan pendekatan terstruktur yang bertahap untuk mengembangkan sistem. Urutan atau langkah langkah yang rumit ini memaksa user untuk keluar setelah menyelesaikan spesifikasi masing masing sebelum pengembangan dapat melanjutkan ke langkah berikutnya. Persyaratan dan perencanaan kemudian berhenti dan sistem di implementasikan,dan diuji,. Dengan konvensional metode, ada penundaan yang lama sebelum pelanggan dapat melihat hasil apapun dan proses pembangunan dapat mengambil waktu begitu lama sehingga pelanggan bisnis dapat mengubah secara mendasar sebelum sistem ini siap untuk digunakan.

Sebagai tanggapan terhadap, langkah searah Stagewise atau Model Water Fall, Barry Boehm, Ketua SW Engineer di TRW, memperkenalkan Model development Spiral nya. Model Spiral adalah risikodriven, sebagai lawan dari kodedriven, pendekatan yang menggunakan pemodelan proses daripada fase metodologi. Melalui model nya, Boehm pertama kali diimplementasikan perangkat lunak prototyping sebagai cara untuk mengurangi risiko. Pengembangan proses Spiral Model memisahkan produk ke bagian bagian yang kritis atau tingkat sementara melakukan analisis risiko, prototyping, dan langkah yang sama di setiap tingkatan. Demikian pula, Tom Gilb's evolusioner Life Cycle didasarkan pada evolusi prototyping alasan mana prototipe tumbuh dan halus ke final produk.

 Karya Boehm dan Gilb membuka jalan bagi perumusan metodologi yang disebut Rapid Prototyping Iteratif Produksi (RIPP) di DuPont di pertengahan ke akhir 1980an. James Martin kemudian diperluas kerja yang dilakukan di DuPont dan tempat lain ke dalam suatu proses, lebih besar lebih formal, yang telah menjadi dikenal sebagai Rapid Application Development (RAD). RAD kompres pengembangan langkah demi langkah metode konvensional menjadi proses berulangulang. Pendekatan RAD demikian termasuk mengembangkan dan memperbaiki model data, model proses, dan prototipe secara parallel menggunakan proses iteratif. Persyaratan Pengguna diperhalus, solusi dirancang, solusinya adalah prototyped, prototipe ditinjau, masukan pengguna disediakan, dan proses dimulai la.

2.2 Pengertian RAD
 Rapid application development (RAD) atau rapid prototyping adalah model proses pembangunan perangkat lunak yang tergolong dalam teknik incremental (bertingkat). RAD menekankan pada siklus pembangunan pendek, singkat, dan cepat. Waktu yang singkat adalah batasan yang penting untuk model ini. Rapid application development menggunakan metode iteratif (berulang) dalam mengembangkan sistem dimana working model (model kerja) sistem dikonstruksikan di awal tahap pengembangan dengan tujuan menetapkan kebutuhan (requirement) pengguna. Model kerja digunakan hanya sesekali saja sebagai basis desain dan implementasi sistem akhiRapid Application Development (RAD) adalah metodologi pengembangan perangkat lunak yang berfokus pada membangun aplikasi dalam waktu yang sangat singkat. Istilah ini menjadi kata kunci pemasaran yang umum menjelaskan aplikasi yang dapat dirancang dan dikembangkan dalam waktu 609 hari, tapi itu awalnya ditujukan untuk menggambarkan suatu proses pembangunan yang melibatkan application prototyping dan iterative development.

Menurut James Martin “Rapid Application Development (RAD) merupakan pengembangan siklus yang dirancang untuk memberikan pengembangan yang jauh lebih cepat dan hasil yang lebih berkualitas tinggi daripada yang dicapai dengan siklus hidup tradisional. Hal ini dirancang untuk mengambil keuntungan maksimum dari pengembangan perangkat lunak yang telah berevolusi barubaru ini."

Profesor Clifford Kettemborough dari College Whitehead, University of Redlands, mendefinisikan Rapid Application Development sebagai "pendekatan untuk membangun sistem komputer yang menggabungkan ComputerAssisted Software Engineering (CASE) tools dan teknik, userdriven prototyping,. RAD meningkatkan kualitas sistem secara drastis dan mengurangi waktu yang diperlukan untuk membangun sistem."

Sebagai gambaran umum, pengembangan aplikasi berarti mengembangkan aplikasi pemrograman yang bervariasi dari pemrograman umum dalam arti bahwa ia memiliki tingkat yang lebih tinggi dari liabillity, termasuk untuk kebutuhan capturing dan testing. Pada 1970an, Rapid Application Development muncul sebagai respon untuk nonagile processes, seperti model Waterfall. Pengembang perangkat lunak menghadapi masalah waktu dengan metodologi sebelumnya sebagai sebuah aplikasi yang begitu lama untuk membangun. Dengan demikian, metodologi tersebut sering mengakibatkan sistem tidak dapat digunakan. 

 2.3 Model RAD

a) Bussiness model
 Aliran informasi di antara fungsi – fungsi bisnis dimodelkan dengan suatu     cara untuk menjawab pertanyaan – pertanyaan berikut : 
a.        informasi apa yang mengendalikan proses bisnis? 
b.       Informasi apa yang di munculkan? 
c.       Siapa yang memunculkanya? 
d.       Ke mana informasi itu pergi? 
e.       Siapa yang memprosesnya? 

b) Data modeling 
a.    Aliran informasi yang di definisikan sebagai bagian dari fase   business  modeling disaring kedalam serangkaian objek data yang dibutuhkan untuk menopang bisnis tersebut 
b.      Karakteristik (disebut atribut) masing – masing objek diidentifikasi dan hubungan antara objek – objek tersebut didefinisikan. 
c.       Bagian dari pemodelan bisnis yang didefinisikan ke dalam sekumpulan objek data. 
d. Karakteristik (atribut) dari setiap objek diidentifikasikan dan hubungannya.

c) Prosess modelling 
a.Aliran informasi yang didefinisikan di dalam fase data modeling ditransformasikan untuk mencapai aliran informasi yang perlu bagi implementasi sebuah fungsi bisnis. 
- Gambaran pemrosesan diciptakan untuk menambah, memodifikasi,menghapus,atau mendapatkan kembali sebuah objek data. 
b.      Objek data akan diimplementasikan pada fungsi bisnis. 
c. Deskripsi proses dibangun untuk penambahan modifikasi, penghapusan,pengambilan kembali objek data.
  
d) Application generation 
RAD mengasumsikan pemakaian teknik generasi ke empat. Selain menciptakan perangkat lunak dengan 
a. Menggunakan bahasa pemrograman generasi ketiga yang konvensional 
·Pada semua kasus, alat – alat bantu otomatis dipakai untuk memfasilitasi konstruksi perangkat lunak. 
b. Melakukan penggunaan kembali komponen yang ada (jika mungkin). 
c.  Atau membuat kembali penggunaan kembali komponen jika dibutuhkan. 

e) Testing and turnover 
a. Karena proses RAD menekankan pada pemakaian kembali,banyak komponen program telah diuji. Hal ini mengurangi keseluruhan waktu pengujian. 
-      Tetapi komponen baru harus di uji dan semua interface harus dilatih secara penuh. 

2.4 Keuntungan dan Kelemahan RAD 

2.4.1        Keuntungan RAD 

RAD mempunyai keuntungan yang dapat disimpulkan sebagai berikut: 
-      Sangat berguna dilakukan pada kondisi user tidak memahami kebutuhankebutuhan apa saja yang digunakan pada proses pengembangan perangkat lunak. 
-  RAD mengikuti tahapan pengembangan sistem sepeti umumnya, tetapi mempunyai kemampuan untuk menggunakan kembali komponen yang ada (reusable object) sehingga pengembang tidak perlu membuat dari awal lagi dan waktu lebih singkat berkisar antara 60 hari-90 hari. 
-          Karena mempunyai kemampuan untuk menggunakan komponen yang sudah ada dan waktu yang lebih singkat maka membuat biaya menjadi lebih rendah dalam menggunakan RAD

 2.4.2 Kelemahan RAD

Beberapa hal yang perlu diperhatikan dalam implementasi pengembangan   menggunakan model RAD : 
- Proyek yang berskala besar, RAD memerlukan sumber daya manusia yang memadai untuk menciptakan jumlah tim yang baik. 
-  RAD menuntut pengembang dan pelanggan memiliki komitmen dalam aktivitasi rapid fire yang diperlukan untuk melengkapi sebuah sistem dalam waktu yang singkat. Jika komitmen tersebut tidak ada maka proyek RAD akan gagal.

3. V Model

3.1 Sejarah

Pada tahun 1986 Kementerian Federal untuk pertahanan memulai dua proyek.
Software lingkungan pengembangan untuk sistem informasi (Seu-IS) dan Software lingkungan pengembangan untuk sistem pengiriman senjata dan senjata (Seu-WS) dengan tujuan sebagai berikut:

Untuk membuat biaya atas pengembangan perangkat lunak keseluruhan dan transparansi proses dan perawatan juga membatasi akibatnya. Untuk menjamin dan / atau ini lebih meningkatkan dengan tindakan yang sesuai standar minimum untuk kualitas perangkat lunak. Untuk mencapai oleh komparatif dari tawaran ketiga kemandirian yang lebih besar dari offerers individu untuk. Untuk standarisasi dan mengatur lebih transparan dalam pengembangan perangkat lunak di rumah sendiri. Asal Militer

Untuk hal ini pada prinsipnya juga pengolahan konsep dari NATO-sekutu seharusnya dapat diterapkan, seperti misalnya Amerika standar DoD 2.167 STD A atau standar Perancis GAM T 17. Sebuah pemeriksaan rinci dari model ini menunjukkan bahwa bagaimanapun mereka tidak mampu, semua persyaratan untuk menjadi adil. Jadi salah satu memutuskan untuk pengembangan diri, yang membawa versi pertama keluar dari model V-pada tahun 1988 - sebagai hasil dari proyek Seu-WS -. Ke ini sampai April 1990 realisasi dari proyek Seu-IS kemudian diintegrasikan dan versi perbaikan dari model V-dekrit itu tetap dari bulan Februari 1991 oleh Menteri Federal untuk pertahanan sebagai tingkat pool pengembangan perusahaan penyiaran untuk produksi software dengan Angkatan Bersenjata Jerman Federal.

3.2 Pengertian V-Model

Dalam V-Model , alokasi tugas ( kegiatan ) kepada orang-orang yang terorganisir melalui peran. Dalam kaitan ini, peran menggambarkan dibutuhkan pengetahuan dan kemampuan seseorang harus memiliki dalam rangka untuk memenuhi tugas-tugas yang dialokasikan kepadanya. Dengan demikian, berkaitan dengan organisasi, V-Model tidak memihak. Berkenaan dengan proyek penanganan ini berarti bahwa peranan dari model V- harus dialokasikan untuk perorangan pada saat proyek (kegiatan PM1 - Inisialisasi Proyek ) diinisialisasi. Di pihak berwenang dan perusahaan, orang-orang selalu unit organisasi terkecil.

Oleh karena itu, alokasi orang untuk peran juga untuk mempertimbangkan struktur organisasi dan penanganan organisasi. Peran mengidentifikasi kegiatan-kegiatan yang mungkin memerlukan hanya sebagian dari jam kerja anggota staf, atau, dalam kasus lain, mereka mungkin memerlukan beberapa kali jam kerja dari anggota staf.

Oleh karena itu, anggota staf mungkin memiliki beberapa peran yang dialokasikan kepadanya, atau satu peran dapat dipenuhi oleh beberapa anggota staf. Bagian penting dalam alokasi ini adalah bahwa peran sendiri tidak akan mengganggu satu sama lain dan dengan demikian mungkin menjadi masalah yang tak terpecahkan bagi orang yang bertanggung jawab atas peran (misalnya berkaitan dengan peran konstruktif SD di satu sisi dan dengan penguji pada lainnya tangan). Misalnya, peran Pimpinan Proyek tidak boleh dikombinasikan dengan peran orang yang bertanggung jawab QA, karenaPemimpin Proyek terutama bertanggung jawab untuk waktu dan anggaran, dan manajer QA untuk kualitas. Sebagai contoh lain, peran manajer QA kompatibel dengan peran Perwakilan CM .

Kriteria untuk alokasi adalah bahwa seseorang tidak harus berada dalam konflik kepentingan, struktur tanggung jawab dan pengalaman, pengetahuan, kesesuaian, ketersediaan (utilisasi) dari anggota proyek.

Dalam hal tidak ada kegiatan lebih banyak dialokasikan setelah menjahit, beberapa peran yang dapat dijatuhkan dari proyek tersebut. Dalam proyek-proyek kecil, tidak dapat dihindari bahwa beberapa peran yang dialokasikan untuk satu orang. Dalam proyek-proyek besar, peran masing-masing biasanya ditutupi oleh anggota staf yang berbeda.

Beberapa peran yang relevan untuk proyek tersebut dapat dipindahkan ke unit organisasi untuk seluruh panjang dari proyek. Ini praktis terutama dalam kasus seperti di mana aktivitas peran agak rumit dan peningkatan konstan dalam pengetahuan dapat diharapkan sambil terus berhubungan dengan materi pelajaran. Di atas semua itu, peran ini dapat berupa tugas cross-sectional alam dan menjadi prasyarat dan dasar untuk semua proyek.Mereka adalah independen dari proyek individu sejak layanan mereka diwajibkan oleh semua proyek. Contoh umum adalah Manajer Proyek , Manajer Q , manajer CM , dan IT Perwakilan . Contoh untuk alokasi peran untuk orang / unit organisasi dalam satu struktur organisasi dapat ditemukan dalam koleksi manual.

The V-Model mengasumsikan bahwa pengembangan sistem atau sistem pemeliharaan dan modifikasi adalah fokus komisi. Biasanya, pelanggan merupakan unit organisasi yang komisi pengembangan sistem lain unit organisasi baik di luar atau di dalam perusahaan otoritas /. Ketika mempertimbangkan pelanggan dan kontraktor, ini tidak berarti bahwa peran dalam Model V- akan digandakan (peran pelanggan dan ontractor rolesc).Komunikasi tambahan dan tugas koordinasi harus ditentukan yang dapat menyebabkan pengaturan dari keputusan lebih lanjut dan kelompok kemudi. R.2 Peran di V-Model Peran yang diperintahkan sesuai dengan submodels: dalam setiap submodel, ada • salah satu manajer yang mendefinisikan kondisi marjinal untuk kegiatan submodel dan yang berfungsi sebagai pengambil keputusan atas, • perencanaan perwakilan, kemudi dan mengendalikan tugas-tugas dari submodel tersebut, satu atau beberapa orang yang bertanggung jawab atas tugas-tugas yang direncanakan dari submodel tersebut. Tabel R. 1 menggambarkan peranan dari model V- .

3.3 Keuntungan dari V-Model

• Bahasa yang digunakan untuk merepresentasikan konsep V model menggunakan bahasa formal. Contoh : dengan menggunakan objek model ataupun frame-frame • Meminimalisasikan kesalahan pada hasil akhir karena ada test pada setiap prosesnya.

•  Penyesuaian yang cepat pada projek yang baru

• Memudahkan dalam pembuatan dokumen projek

• Biaya yang murah dalam perawatan dan modifikasinya

• • 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.

3.4 Kerugian dari V-Model

• Aktifitas V-Model hanya difokuskan pada projectnya saja, bukan pada keseluruhan organisasi. V-Model adalah proses model yang hanya dikerjakan sekali selama project saja, bukan keseluruhan organisasi.
• Prosesnya hanya secara sementara. Ketika project selesai, jalannya proses model dihentikan. Tidak berlangsung untuk keseluruhan organisasi.
• Metode yang ditawarkan terbatas. Sehingga kita tidak memiliki cara pandang dari metode yang lain. Kita tidak memiliki kesempatan untuk mempertimbangkan jika ada tools lain yang lebih baik.
• Toolnya tidak selengkap yang dibicarakan. SDE (Software Development Environment).Tidak ada tools untuk hardware di V-Model. Tool yang dimaksud adalah “software yang mendukung pengembangan atau pemeliharaan / modifikasi dari system IT. n 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.

 3.5 Penerapan V Model

 V model biasa digunakan pada proyek-proyek dengan skala yang besar. Sebagai contohnya yaitu digunakan di Jerman untuk mengatur sistem administrasi pemerintahannya dalam hal ini pada bagian BWB (Bundesamt für Wehrtechnik und Beschaffung = German Federal Office for Procurement).

4.Simple Interaction Design Model

Simple Interaction Design Model sebagai suatu proses untuk mencapai suatu tujuan dengan pencarian berbagai solusi melalui ruang lingkup sistem, materi, biaya dan kemungkinan penyelesaiannya (feasibilitas), sebagai wujud kreativitas dan pengambilan keputusan untuk menyeimbangkan trade-off. Dan Sebagai representasi suatu perencanaan pengembangan yang berisikan sekumpulan elaborasi alternatif dan suksesif.
Dalam desain interaksi terdapat empat kegiatan utama, yaitu :
– Identifikasi kebutuhan dan persyaratan sistem
– Pengembangan desain alternatif (desain konseptual dan fisikal)
– Membuat versi interaktif dari desain yang dihasilkan
– Mengevaluasi desain (usabilitas dan user experience)

5.Star Lifecycle
 
 Dalam Siklus permodelan ini pengujian dilakukan terus menerus. 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 akan 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.

Sumber :
http://novyinkie.wordpress.com/2013/01/25/penjelasan-dari-macam-macam-model/
http://fauzi-sistem.blogspot.com/2013/02/v-model.html
http://yuliagroups.wordpress.com/pengertian-rad/
http://globalonlinebook1.blogspot.com/2013/05/pengertian-waterfall-model.html
http://dodisetiawanmsi.blogspot.com/2013/07/star-lifecycle-model.html