Skip to content
Aside

Model Siklus Hidup Star

 

 

Image

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 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.
Intinya pada rancangan model ini pengevaluasian dilakukan disetiap tahapan tidak hanya pada tahapan akhir seperti model-model rancangan yang lainnya.

Model Rancangan Interaksi Sederhana

Image

Keterangan:
•   Identifikasi kebutuhan dan persyaratan system disini suatu sistem akan di identifikasi sesuai denga kebutuhan sistem itu sendiri.
•   Pengembangan desain alternatif (desain konseptual dan fisikal)
•   Membuat versi interaktif dari desain yang dihasilkan
•   Mengevaluasi desain (usabilitas dan user experience)
 
Model Rancangan Interaksi Sederhana
  • Satu titikan masukan
  • Rancangan menghasilkan prototipe yang interaktif yang dapat dievaluasi
  • Evaluasi dapat dilakukan dimana saja
  • Evaluasi harus dikaitkan dengan hasil akhir

 

Aside

V-Model

Image

Dalam proses model Waterfall dasar melihat beberapa kelemahan atau keterbatasan dalam model yang mulai model SDLC baru. Seperti yang kita lihat dalam model Waterfall isu-isu yang ditemukan di akhir SDLC, hal ini disebabkan pengujian yang terjadi pada tahap akhir dari SDLC Anda. Untuk mengatasi masalah ini V-Model yang datang ke dalam gambar. Itu selalu lebih baik untuk memperkenalkan pengujian dalam tahap awal SDLC, seperti dalam model ini kegiatan pengujian akan dimulai dari tahap awal SDLC.

Sebelum memulai pengujian yang sebenarnya, tim pengujian harus bekerja pada berbagai kegiatan seperti penyusunan Strategi Uji, Uji Perencanaan, Penciptaan kasus Uji & Test Scripts yang bekerja paralel dengan kegiatan pembangunan yang membantu untuk mendapatkan tes diserahkan tepat waktu.

Dalam Model Pengembangan Perangkat Lunak Siklus Hidup V, berdasarkan informasi yang sama (persyaratan spesifikasi dokumen) kegiatan pembangunan & pengujian dimulai. Berdasarkan dokumen persyaratan tim pengembang mulai bekerja pada desain & setelah selesai pada desain mulai implementasi aktual dan tim pengujian mulai bekerja pada perencanaan pengujian, menulis uji kasus, script pengujian. Kedua kegiatan bekerja sejajar satu sama lain. Dalam model Waterfall & V-model mereka cukup mirip satu sama lain. Karena itu adalah Uji Perangkat Lunak paling populer Hidup Model Siklus sehingga sebagian besar organisasi mengikuti model ini.

V-model juga disebut sebagai Verifikasi dan model Validasi. Kegiatan pengujian tampil dalam setiap fase dari fase Siklus Hidup Uji Perangkat Lunak. Di paruh pertama model kegiatan validasi pengujian terintegrasi dalam setiap fase seperti kebutuhan pengguna review, dokumen Sistem Desain & di babak berikutnya kegiatan pengujian Verifikasi datang dalam gambar.

Khas V-Model menunjukkan kegiatan Pengembangan Perangkat Lunak di sisi kiri dari model dan sisi kanan dari Fase Pengujian model yang sebenarnya dapat dilakukan.

Dalam proses ini “Do-Prosedur” akan diikuti oleh tim pengembang dan “Check-Prosedur” akan diikuti oleh tim pengujian untuk memenuhi persyaratan yang disebutkan.

Dalam siklus V-Model hidup pengembangan perangkat lunak langkah yang berbeda yang diikuti Namun di sini kita akan mengambil jenis yang paling umum dari V-model contoh. V-model biasanya terdiri dari beberapa tahap sebagai berikut:

1. Unit Pengujian: Persiapan Kasus Uji Satuan
2. Integrasi Pengujian: Persiapan Uji Kasus Integrasi
3. Sistem Pengujian: Persiapan kasus uji Sistem
4. Penerimaan Pengujian: Persiapan Uji Kasus Penerimaan

V-model dikembangkan di Jerman untuk aplikasi pertahanan. Didalam V-model terdapat 3 kompomen  kerja yang pokok yakni Project Definition yakni mendefenisian project apa yang akan dibuat, Time yakni waktu yang dibutuhkan dalam pengimplementasiannya dan Project Test And Integration atau pengujian dan integrasi project tersebut.
Model ini berpusat pada user. Dimana pengulangan selalu dibutuhkan jika kebutuhan untuk user belum terpenuhi “ketidaktahuannya” tanpa harus memberikan software dengan lingkungan yang baru. Resiko pada setiap tahap dalam pengembangan dapat dikurangi dengan memahami kebutuhan user.
Didalam pendefenisian project terdapat aktivitas Concept Operation  (konsepsi project) yakni menentukan tujuan yang akan di capai dalam pembuatan project tersebut. Requirement and Architecture (persyaratan dan arsitektur) yakni harus dapat menjelaskan apa saja yang diinginkan dan diperlukan oleh user. Untuk itu diperlukan adanya psroses klarifikasi, perbaikan, penentuan kelengkapan, dan ruang lingkup. Sebagai masukannya dapat berupa dokumen persyaratan dan keluarannya adalah ketetapan persyaratan. Terdapat bermacam-macam persyaratan yang dapat dihasilkan :
·         Fungsional : menjelaskan tentang apa saja yang dapat dilakukan oleh system
·         Non fungsional : dapat berupa ukuran memori, jangka waktu respon.
·         Data : data apa saja yang perlu disimpan dan bagaimana penyimpanannya.
Detailed Design yakni memperincikan desain sebuah aplikasi yang akan dibuat.
Selanjutnya setelah Project tersebut telah ditetapkan maka Diimplementasikan lah atau di jalankan. Selanjutnya dalam tahap Project Test and Integration aplikasi/software yang telah dilakukan Integration test and Verification yang mana dalam tahap ini aplikasi yang telah diimplementasikan di lakukan verifikasi atau ditinjuau kegunaan nya apakah sesaui dengan kebutuhan user.
Selanjutnya Operation and Maintenance yakni melakukan perbaikan atas apa yg telah di verifikasi dan di sesuaikan dengan kebutuhan user. Dan pada akhirnya dalam model ini akan dilakukan proses Verivikasi  dan Validitas kepada user apakah sudah bekerja sesuai dengan yang diharapkan dan apakah rancangan sesuai dengan apa nyang diinginkan.

Pengertian Waterfall

Waterfall sebagai model rekayasa perangkat lunak

Permodelan dalam suatu perangkat lunak merupakan suatu hal yang dilakukan di tahapan awal. Di dalam suatu rekayasa perangkat lunak, sebenarnya masih memungkinkan tanpa melakukan permodelan. Hal ini tidak dapat lagi dilakukan dalam suatu industri perangkat lunak.
Permodelan dalam perangkat lunak merupakan suatu yang harus dikerjakan di bagian awal rekayasa, dan permodelan ini akan mempengaruhi pekerjaan-pekerjaan dalam rekayasa perangkat lunak tersebut.
Model proses perangkat lunak masih menjadi obyek penelitian, tapi sekarang ada banyak model umum atau paradigma yang berbeda dari pengembangan perangkat lunak, antara lain :
 
  • Pengembangan waterfall
  • Pengembangan secara evolusioner
  • Transformasi formal
  • Penggabungan sistem dengan menggunakan komponen-komponen yang dapat digunakan kembali
Waterfall model pertama kali diperkenalkanoleh Winston Royce tahun 1970. Waterfall Model merupakan model klasik yang sederhana dengan aliran sistem yang linier.  Output dari setiap tahap merupakan input bagi tahap berikutnya.
Model ini telah diperoleh dari proses rekayasa lainnya dan menawarkan cara pembuatan rekayasa perangkat lunak secara lebih nyata.  Model ini melibatkan tim SQA (Software Quantity Assurance) dengan 5 tahapan, dimana setiap tahapan selalu dilakukan verifikasi atau testing.  Tahapan model waterfall meliputi :
  • Requirment
Dalam tahapan ini jasa, kendala dan  tujuandari konsultasi dengan pengguna sistem.  Kemudian semuanya dibuat dalam bentuk yang dapat dimengerti oleh user dan staf pengembang.  Dengan kata lain, dalam tahapn ini dilakukan analisa kebutuhan, kemdian diverifikasi klien dan tim SQA.
  • Specification
Dokumentasi spesifikasi, kemudian diperiksa oleh tim SQA.  Selanjutnya jika disetujui oleh klien, maka dokumen tersebutmerupakan kontrak kerjaantaraklien dan pengembang s0ftware.  Selanjutnya merencanakan jadwal pengembangan software. Jika disetujui oleh SQA, tahap desain baru dilakukan.
  • Design
Proses design sistem membagi kebutuhan-kebutuhan menjadi sistem perangkat lunak atau perangkat keras.  Proses tersebut menghasilkan sebuah arsitektur keseluruhan. Desain perangkat lunak termasuk menghasilkan fungsi sistem perangkatlunak dalam bentuk yang mungkin ditransformasi kedalam satu atau lebih program yang dapat dijalankan.  Tahapan ini telah menentukan alur software hingga pada tahap algoritma detail.  Di akhir tahap ini, kembali diperksa tim SQA.
  • Implementation
Selama tahap ini, desain perangkat lunak disadari sebagai sebuah program lengkap atau unit program.  Desain yang telah disetujui, diubah dalam bentuk kode-kode program.  Tahap ini, kode-kode program yang dihasilkan masih pada tahap modul-modul. Diakhir tahap ini, tiap modul di testing tanpa diintegrasikan.
  • Integration
Unit program diintegrasikan dandiuji menjadi sistem yang lengkap untuk meyakinkan bahwa persyaratan perangkat lunak telah dipenuhi.  Setelah uji coba, sistem disampaikan ke konsumen.
  • Operaton mode & retirement
Normalnya, ini adalah tahap yang terpanjang.  Sistem dipasang dan digunakan. Pemeliharaan termasuk pembetulan kesalahan yang tidak ditemukan pada langkah sebelumnya.  Perbaikan inmplementasi unit sistem dan peningkatan jasa sistem sebagai kebutuhan baru ditemukan.
Setiap tahap dari modelini menggunakan Document Drivent, yaitu tahap selanjutnya selalu bekerja berdasarkan dokumen yang telah diberikan sebelumnya.
Tahapan pada waterfall model tidak akan selesai jika tidak disetujui SQA.  Modifikasi pada tahap tertentu (tidak sesuai dengan dokumen sebelumnya), proses harus kembali pada tahap sebelumnya untuk penyesuaian dan peninjauan ulang.
Dalam prakteknya, setiap langkah sering tumpang tindih dan saling memberi informasi satu sama lain.  Proses perangkat lunak tidak linierdan sederhana,  tapi mengandung urutan iterasi dari aktifitas pengembangan.  Selama di langkah terakhir, perangkat lunak telah digunakan.  Kesalahan dan kelalaian dalam menentukan kebutuhan perangkat lunak original dapat diatasi.
Sayangnya model yang banyak mengandung iterasi, sehingga membuat sulit bagi pihak manajemen untuk memeriksa seluruh rencana dan laporan.  Maka dari itu, setelah sedikit iterasi, biasanya bagian yang telah dikembangkan akan dihentikan dan dilanjutkan dengan langkah pengembangan selanjutnya.
Masalah-masalah selama resolusi selanjutnya, dibiarkan atau diprogram.  Pemberhentian yang prematur dari persyaratan akan berarti bahwa sistem tidak akan sesuai dengan keinginan user.  Mungkin juga sistem terstruktur secarajelek yang sebenarnya merupakan masalah deain akan dibiarkan karenaterkalahkan olehtrik implementasi.
Masalah pendekatan waterfall adalah ketidakluwaesan pembagian proyek ke dalam langkah yang jelas/nyata.  Sistem yang disampaikan kadang-kadang tidak dapatdigunakan sesuai keinginan konsumen.  Namun demikian, model waterfall mencerminkan kepraktisan rekayasa.  Konsekuensinya, model proses perangkat lunak yang berdasarkan pada pendekatan ini, digunakan dalam pengembangan sistem perangkat lunak dan hardware yang luas.ImageImage

Pengertian Water fall model

Water fall model adalah salah satu model pengembangan software, dimana kemajuan suatu proses dipandang sebagai terus mengalir ke bawah seperti air terjun.
Tahap – tahap pengembangan waterfall model adalah :
1. Analisis dan definisi persyaratan
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.

Keuntungan:
Simple dan mudah diimplementasikan
mudah diatur
Cocok untuk proyek kecil

Kerugian:
Tidak mengakomodasi perubahan requirement
Resiko ketidakpastian tinggi
Model yang buruk untuk proyek yang berorientasi obyek
Model yang buruk untuk proyek lama