IMK (life cycle software)

Star Lifecycle,Hartson & Hix, 1989

pada tahun 1989, model siklus hidup star diusulkan oleh hartson dan hix seperti yang ditunjukkan pada gambar.
task/functional implementation analysis requirements evaluation prototyping specification conceptual / formal design muncul dari beberapa karya empiris yang mereka lihat tentang bagaimana desainer antarmuka mengerjakan pekerjaan mereka. mereka mengidentifikasi dua mode aktivitas yang berbeda: mode analitis dan mode sintetis. yang pertama ditandai oleh gagasan seperti top-down, organizing, judicial, dan formal, bekerja dari pandangan sistem terhadap pandangan pengguna; yang terakhir ditandai oleh gagasan seperti bottom-up, free-thinking, creative dan adhoc, bekerja dari pandangan pengguna terhadap tampilan sistem. interfacedesigner bertugas di perancang perangkat lunak. tidak seperti model siklus hidup yang diperkenalkan di atas, siklus hidup star tidak menentukan aktivitas apa pun. sebenarnya, aktivitasnya sangat saling terkait: anda dapat beralih dari aktivitas apa pun ke aktivitas lainnya, asalkan anda pertama-tama menjalani kegiatan evaluasi. ini mencerminkan temuan studi empiris. evaluasi sangat penting bagi model ini, dan kapan pun sebuah kegiatan selesai, hasilnya harus dievaluasi. jadi sebuah proyek dimulai dengan pengumpulan kebutuhan, atau mungkin mulai dengan mengevaluasi suatu eksistensi, atau dengan menganalisis tugas yang ada, dan seterusnya. siklus hidup teknik usability siklus hidup teknik usability diusulkan oleh deborah mayhew pada tahun 1999. banyak orang telah menulis tentang teknik kegunaan, dan seperti yang dikatakan mayhew sendiri,konsep siklus hidup teknik usability. saya juga tidak menemukan tugas usability engineering yang disertakan dalam siklus hidup

keuntungan besar dari prototyping, tentu saja, adalah kemampuan untuk melibatkan pengguna dalam proses pengambilan keputusan  pada tahap awal.

dapat dilihat di setiap tahapan memiliki input dari luar (dari berbagai sumber) untuk dilakukan kegiatan sesuai dengan tahapan yang bersangkutan lalu dilakukan evaluasi. berikut ini merupakan penjelasan dari setiap tahapan yang terdapat pada model star life cycle :

task analysis/functional analysis : 
tahapan ini, akan melakukan functional analysis dari input yang di berikan yang kemudian akan dilakukan evaluation.

requrements/specification : 
tahapan ini, akan mengumpulkan informasi terkait dengan kebutuhan dan segala sesuatu yang bersangkutan dengan software yang akan dikembangkan, lalu dilakukan tahapan evaluation.

conceptual design/formal design representation :
tahapan ini akan mendesain sebuah desain konseptual dari software yang akan dikembangkan bersadarkan semua inputan yang masuk ketahapan ini. kemudian dilakukan tahapan evaluation.

prototyping : 
sama halnya seperti tahapan pada simple interaction design model. dimana prototype merupakan desain interaktif yang memiliki fungsi terbatas yang akan di ujicobakan kepada pengguna lalu melakukan tahap evaluation.

implementation : 
tahapan ini merupakan tahapan dimana software diimplementasikan dan digunakan oleh pengguna lalu dilakukannya tahap evaluation.

evaluation : 
tahapan ini adalah melakukan evaluasi terhadap setiap tahapan yang menggunakan tahapan ini untuk melihat apakah hal yang dilakukan pada tahapan sebelumnya telah sesuai dengan kebutuhan terbaru dari pengguna lalu memberikan feedback terhadap tahapan sebelumnya

Sumber Referensi :
Isaias, P. Issa, T, (2015) High Level Models and Methodologies for Information Systems, Springer Science+Business Media New York 2015
http://kangkokangko.blogspot.co.id/2015/11/model-pada-life-cycle-software.html
http://www.zeepedia.com/read.php?hci_process_and_methodologies_lifecycle_models_in_hci_human_computer_interaction&b=11&c=1
https://kliknyadong.blogspot.co.id/2017/11/siklus-hidup-pemodelan-softwarestar.html

Waterfall 

pertama kali diperkenalkan oleh dr. winston w. royce dalam sebuah makalah yang diterbitkan pada tahun 1970, model air terjun(waterfall) adalah proses pengembangan perangkat lunak(software). model air terjun menekankan bahwa langkah langkah logis ditempuh sepanjang siklus pengembangan perangkat lunak (sdlc), seperti langkah cascading menuruni air terjun inkremental. sementara popularitas model air terjun telah berkurang dalam beberapa tahun terakhir yang mendukung metodologi yang lebih gesit, sifat logis dari proses sekuensial yang digunakan dalam metode air terjun tidak dapat dipungkiri, dan tetap menjadi proses perancangan umum di industri ini.

sepanjang artikel ini, kami akan memeriksa tahap spesifik apa yang menjadi inti model air terjun, kapan dan di mana penerapannya paling baik, dan skenario di mana hal itu dapat dihindari sesuai dengan filosofi desain lainnya.

ada enam tahapan pemodelan waterfall
dalam proses menerapkan proyek perangkat lunak menggunakan
metode waterfall adalah proses tidak terpersulit. ada sedikit perbedaan dalam jumlah dan deskripsi langkah-langkah yang terlibat dalam metode waterfal, tergantung pada pengembang konsepnya sama dan mencakup cakupan luas dari apa yang diperlukan untuk memulai dengan sebuah ide dan mengembangkan aplikasi live skala penuh.

requirements:persyaratan potensial dari aplikasi dianalisis dan ditulis secara metodis dalam dokumen spesifikasi yang menjadi dasar pengembangan masa depan. hasilnya biasanya merupakan dokumen persyaratan yang mendefinisikan aplikasi apa yang harus dilakukan.

analysis:selama tahap kedua ini, sistem dianalisis agar bisa menghasilkan model dan logika bisnis yang tepat yang akan digunakan dalam aplikasi.

design:tahap ini sebagian besar mencakup persyaratan disain teknis, seperti bahasa pemrograman, lapisan data, layanan, dan lain-lain. spesifikasi desain biasanya akan dibuat yang menjelaskan bagaimana logika bisnis yang tercakup dalam analisis akan diterapkan secara teknis.

coding:dalam tahap keempat ini sumber sebenarnya adalah koding (pemograman), menerapkan semua model, logika bisnis, dan integrasi layanan yang ditentukan pada tahap sebelumnya.

testing:selama tahap ini, qa, penguji beta, dan semua penguji lainnya secara sistematis menemukan dan melaporkan masalah dalam aplikasi yang perlu dipecahkan. hal ini tidak biasa untuk fase ini menyebabkan "pengulangan yang diperlukan" dari fase pengkodean sebelumnya, agar bug yang terungkap dapat benar benar kepermukaan.

operations:akhirnya, aplikasi siap untuk diterapkan ke lingkungan sekitar. tahap operasi tidak hanya mencakup penerapan aplikasi, namun juga dukungan dan pemeliharaan lanjutan yang mungkin diperlukan agar tetap fungsional dan mutakhir.

keuntungan model air terjun
sementara model air terjun telah mengalami pentahapan lambat dalam beberapa tahun terakhir yang mendukung metode yang lebih tangkas, namun tetap dapat memberikan sejumlah manfaat, terutama untuk proyek dan organisasi yang lebih besar yang memerlukan tahap dan tenggat waktu yang ketat 

beradaptasi:dengan menggunakan metode air terjun, proyek ini memungkinkan keseluruhan proyek untuk mempertahankan struktur dan struktur desain yang lebih rinci dan kuat karena semua tahap perencanaan terdokumentasi

terstruktur:bahwa model air terjun(waterfall)proyek ini, bahkan bangunan organisasi mengatakan proyek tersebut, untuk menjadi sangat disiplin dalam desain dan strukturnya. sebagian besar proyek yang cukup besar akan, secara penting, mencakup prosedur terperinci untuk mengelola setiap aspek proyek, mulai dari desain dan pengembangan sampai pengujian dan implementasi.

memungkinkan perubahan desain awal: meskipun sulit untuk membuat perubahan desain di kemudian hari, pendekatan waterfall sesuai dengan perubahan pada awal siklus hidup. ini sangat bagus saat memamerkan dokumen spesifikasi pada beberapa tahap pertama dengan tim pengembang dan klien, karena perubahan dapat dilakukan segera dan dengan sedikit usaha, karena tidak ada pengkodean atau implementasi yang benar-benar terjadi.

untuk pengembangan milestone-focused: karena struktur linier yang melekat pada proyek waterfall, aplikasi semacam itu selalu sesuai untuk organisasi atau tim yang bekerja dengan baik di bawah paradigma tonggak dan fokus pada tanggal. dengan tahap yang jelas, konkret, dan dipahami dengan baik sehingga setiap orang di dalam tim dapat memahami dan mempersiapkannya, relatif mudah untuk mengembangkan garis waktu untuk keseluruhan proses dan menetapkan penanda dan tonggak tertentu untuk setiap tahap dan bahkan penyelesaiannya.

kekurangan model air terjun
sementara usulan awal dr. royce tentang apa yang sekarang dikenal sebagai model air terjun itu sangat penting saat diterbitkan pertama kali pada tahun 1970, lebih dari empat dekade kemudian, sejumlah retakan muncul di armor model yang dulu digembar-gemborkan ini.

kendala desain nonadaptif:aspek paling penting dari model air terjun adalah kurangnya kemampuan beradaptasi di semua tahap siklus hidup pengembangan. ketika sebuah tes di tahap lima menunjukkan kelemahan mendasar dalam perancangan sistem, tidak hanya memerlukan lompatan dramatis, mundur dalam tahap proses, namun dalam beberapa kasus, seringkali dapat menyebabkan realisasi yang menghancurkan mengenai legitimasi keseluruhan sistem. sementara tim dan pengembang yang paling berpengalaman akan (dengan benar) berpendapat bahwa hal semacam itu seharusnya tidak terjadi jika sistem dirancang dengan benar di tempat pertama, tidak setiap kemungkinan dapat dipertanggungjawabkan, terutama bila tahapan begitu sering tertunda sampai akhir proses. .

mengabaikan masukan pengguna / klien mid-process:karena proses langkah-demi-langkah ketat yang diterapkan oleh model air terjun(waterfall, masalah lain yang sangat sulit dihadapi adalah umpan balik pengguna atau klien yang diberikan terlambat ke dalam siklus pengembangan seringkali dapat juga dilakukan. sedikit, terlambat sementara manajer proyek jelas dapat menerapkan sebuah proses untuk melangkah mundur ke tahap sebelumnya karena persyaratan atau perubahan yang tidak terduga berasal dari klien, sementara itu akan memakan waktu dan biaya yang mahal, baik untuk tim pengembang maupun klien.

periode pengujian tertunda:meskipun sebagian besar model sdlc yang lebih modern mencoba mengintegrasikan pengujian sebagai proses fundamental dan selalu hadir sepanjang pengembangan, model air terjun (waterfall) sebagian besar jauh dari pengujian sampai cukup larut dalam siklus hidup. ini tidak hanya berarti bahwa sebagian besar bug atau bahkan masalah desain tidak akan ditemukan sampai prosesnya sangat terlambat.

terlepas dari fase pengujian yang eksplisit selama pelaksanaan proyek model air terjun, seperti yang dibahas di atas, pengujian ini seringkali terlalu sedikit, terlalu terlambat. selain tahap pengujian normal, anda dan tim anda harus mempertimbangkan dengan serius untuk memperkenalkan alat manajemen kesalahan yang efektif ke dalam siklus hidup proyek anda. perangkat lunak pemantauan kesalahan airbrake menyediakan pemantauan kesalahan real-time dan pelaporan pengecualian otomatis untuk semua proyek pengembangan anda. dasbor web art of the airbrake memastikan anda menerima pembaruan status sepanjang hari tentang tingkat kesehatan dan kesalahan aplikasi anda. tidak masalah apa yang sedang anda kerjakan, airbrake mudah digabungkan dengan semua bahasa dan kerangka kerja yang paling populer. plus, airbrake memudahkan untuk menyesuaikan parameter pengecualian, sekaligus memberi anda kontrol penuh terhadap sistem filter kesalahan aktif, jadi anda hanya mengumpulkan kesalahan yang paling penting.

Sumber Referensi :
airbrake.io
https://airbrake.io/blog/sdlc/waterfall-model
https://kliknyadong.blogspot.co.id/2017/11/siklus-hidup-pemodelan-softwarewaterfall.html

V-Model

juga dikenal sebagai model verifikasi dan validasi, model v adalah perpanjangan model air terjun dan didasarkan pada asosiasi tahap pengujian untuk setiap tahap pengembangan yang sesuai. ini berarti bahwa model v menunjukkan hubungan antara setiap fase siklus hidup pengembangan dan fase pengujian yang terkait. ada tahap anverifikasi di satu sisi fase 'v' dan validasi di lain sisi. tahap pengkodean menggabungkan kedua sisi model v. sumbu horisontal dan vertikal mewakili kelengkapan waktu atau proyek (kiri ke kanan) dan tingkat abstraksi. ini adalah model yang sangat disiplin dan fase berikutnya dimulai hanya setelah selesainya fase sebelumnya.

model v aplikasi hampir sama dengan model waterfall, karena kedua model tersebut bersifat berurutan. persyaratan harus sangat jelas sebelum proyek dimulai, karena biasanya mahal untuk kembali dan melakukan perubahan.

sebaiknya digunakan untuk proyek berukuran kecil sampai menengah dimana persyaratannya didefinisikan dengan jelas dan tetap.

kepercayaan pelanggan yang tinggi dibutuhkan. karena, tidak ada prototipe yang dihasilkan, ada risiko yang sangat tinggi yang terlibat dalam memenuhi harapan pelanggan.

asal usul model v
salah satu hambatan utama model air terjun(water fall) adalah bahwa,sebelumnya telah di temukan kecacatan pada proses pembangunan yang kemudian menjadi lambat, karena pengujian dilakukan pada akhir siklus pengembangan. ini menjadi sangat menantang dan mahal untuk memperbaiki cacat sejak ditemukan pada tahap selanjutnya. untuk mengatasi masalah ini, model pengembangan baru diperkenalkan dengan nama "model v". model v mendapat namanya dari kenyataan bahwa prosesnya sering dipetakan sebagai flowchart yang mengambil bentuk huruf v. pengenalan model v benar-benar membuktikan implementasi pengujian langsung dari fase kebutuhan.

verification phases | validation phases
ada beberapa tahap verifikasi & validasi dalam model v, masing-masing dijelaskan secara rinci di bawah ini,

verifikasi: analisis kebutuhan bisnis >> spesifikasi fungsional >> desain tingkat tinggi >> desain rinci

validasi: tes penerimaan >> pengujian sistem >> pengujian integrasi >> pengujian unit

business requirements analysis | acceptance tests
pada tahap analisis kebutuhan, langkah pertama dalam proses verifikasi, persyaratan sistem dikumpulkan dengan menganalisis kebutuhan pengguna. persyaratan dikumpulkan, dianalisis dan dipelajari. bagaimana sistem diimplementasikan tidak penting di sini, tapi sistem apa yang seharusnya dilakukan, itu penting. ini melibatkan komunikasi terperinci dengan pelanggan untuk memahami dan mendokumentasikan ekspektasinya dan persyaratan yang tepat dalam dokumen spesifikasi persyaratan perangkat lunak. dokumen ini akan menjadi panduan bagi perancang sistem dalam tahap perancangan sistem. ini adalah kegiatan yang sangat penting dan perlu dikelola dengan baik, karena sebagian besar pelanggan tidak yakin dengan apa sebenarnya yang mereka butuhkan. namun hal itu tidak menentukan bagaimana perangkat lunak akan dirancang atau dibangun.

uji penerimaan pengguna (uat) rencana dikembangkan pada tahap ini karena persyaratan bisnis dapat digunakan sebagai masukan. ini melibatkan pengujian produk di lingkungan pengguna. uat dilakukan di lingkungan pengguna yang menyerupai lingkungan produksi, menggunakan data yang realistis. uat memverifikasi bahwa sistem yang dikirimkan memenuhi persyaratan dan sistem pengguna siap digunakan secara real time.

functional specifications | system testing
begitu anda memiliki persyaratan produk yang jelas dan rinci, sekarang saatnya merancang sistem yang lengkap. perancangan sistem adalah fase dimana para insinyur sistem menganalisis dan memahami kebutuhan bisnis dan mengetahui kemungkinan dan teknik yang dengannya persyaratan pengguna dapat diterapkan. dokumen spesifikasi perangkat lunak yang berfungsi sebagai cetak biru untuk tahap pengembangan dihasilkan.

rencana uji sistem dikembangkan berdasarkan spesifikasi fungsional. uji sistem memastikan bahwa harapan dari aplikasi yang dikembangkan terpenuhi. seluruh aplikasi diuji karena fungsinya, saling ketergantungan dan komunikasi. pengujian sistem memverifikasi bahwa persyaratan fungsional dan non-fungsional telah terpenuhi. pengujian beban dan kinerja, pengujian stres, pengujian regresi, dan lain-lain, merupakan subkumpulan pengujian sistem.

high-level design | integration testing
spesifikasi arsitektur dipahami dan dirancang pada tahap ini. dasar dalam memilih arsitektur adalah bahwa ia harus menyadari semua yang biasanya terdiri dari daftar modul, fungsi singkat setiap modul, hubungan antar muka, dependensi, tabel database, diagram arsitektur, rincian teknologi dll. biasanya lebih dari satu pendekatan teknis adalah diusulkan dan berdasarkan kelayakan teknis dan finansial keputusan akhir diambil. perancangan sistem dipecah menjadi modul yang mengambil fungsionalitas yang berbeda. hal ini juga disebut sebagai high level design (hld). ini memberikan gambaran tentang solusi, platform, sistem, produk dan layanan / proses. transfer data dan komunikasi antara modul internal dan dengan dunia luar (sistem lain) dipahami dan didefinisikan secara jelas pada tahap ini.

dengan informasi ini, rencana uji integrasi dapat dirancang dan didokumentasikan selama tahap ini. uji integrasi dilakukan untuk menguji koeksistensi dan komunikasi modul internal dalam sistem. tes ini memverifikasi bahwa unit yang dibuat dan diuji secara mandiri dapat hidup berdampingan dan berkomunikasi di antara mereka sendiri.

detailed design | unit testing
pada tahap desain tingkat rendah (lld), desain internal yang rinci untuk semua modul sistem ditentukan. sistem yang dirancang dipecah menjadi unit atau modul yang lebih kecil dan masing-masing dijelaskan sehingga pemrogram bisa mulai coding secara langsung. dokumen desain tingkat rendah atau spesifikasi program akan berisi logika fungsional rinci modul, dalam kode semu. adalah penting bahwa desainnya kompatibel dengan modul lain dalam arsitektur sistem dan sistem eksternal lainnya.

unit test plans (utps) dapat dirancang pada tahap ini berdasarkan desain modul internal. unit adalah entitas terkecil yang dapat berdiri sendiri, mis. sebuah modul program pengujian unit memverifikasi bahwa entitas terkecil dapat berfungsi dengan benar saat diisolasi dari kode / unit lainnya. ini membantu menghilangkan bug pada tahap awal, meskipun semua cacat tidak dapat ditemukan oleh unit testing. pengujian ini pada dasarnya dilakukan oleh tim pengembang.

the coding phase
pengkodean aktual dari modul sistem diambil dalam fase coding. bahasa pemrograman yang paling sesuai diputuskan berdasarkan persyaratan sistem dan arsitektur. pengkodean dilakukan berdasarkan pedoman dan standar pengkodean. kode berjalan melalui banyak ulasan kode dan dioptimalkan untuk kinerja terbaik sebelum pembuatan akhir diperiksa ke dalam repositori.

setelah pengkodean selesai, jalan eksekusi berlanjut ke sisi kanan v dimana rencana uji yang dikembangkan sebelumnya digunakan.

kelebihan model v
keuntungan utama v model adalah sangat mudah dipahami dan diterapkan. kesederhanaan model ini juga mempermudah pengelolaan.

sederhana dan mudah dimengerti dan digunakan.
model dan fase yang sangat disiplin diselesaikan satu per satu.
bekerja dengan baik untuk proyek yang lebih kecil dimana persyaratannya sangat dipahami.
mudah dikelola karena kekakuan model. setiap tahap memiliki deliverable dan proses review yang spesifik.
menguji aktivitas seperti perencanaan, perancangan uji terjadi dengan baik sebelum pengkodean sehingga ambiguitas diidentifikasi sejak awal. ini menghemat banyak waktu. maka peluang sukses yang lebih tinggi dibanding model waterfall.
mudah diatur karena setiap fase memiliki tujuan dan sasaran yang jelas.

kelemahan dari model v
kelemahannya adalah modelnya tidak fleksibel terhadap perubahan dan kalau-kalau ada perubahan persyaratan, yang sangat umum terjadi di dunia dinamis saat ini, menjadi sangat mahal untuk melakukan perubahan.

resiko tinggi dan ketidakpastian
tidak cocok untuk proyek di mana persyaratan berada pada risiko sedang hingga tinggi untuk mengalami perubahan.
setelah aplikasi dalam tahap pengujian, sulit untuk kembali dan mengubah fungsionalitas.
perangkat lunak dikembangkan selama tahap implementasi, jadi tidak ada prototipe kerja awal dari perangkat lunak yang diproduksi sampai larut selama siklus hidup.
jika ada perubahan terjadi di tengah jalan, maka dokumen uji beserta dokumen persyaratan harus diperbaharui.

Sumber Referensi :
softwaretestingstudio
http://www.softwaretestingstudio.com/v-model-software-development/
https://kliknyadong.blogspot.co.id/2017/11/siklus-hidup-pemodelan-softwarev-model.html

Simple Interaction Design Model

metode ini dikembangkan oleh jack carroll dan rekan-rekannya dan memiliki keuntungan karena ada banyak kesempatan untuk menyertakan persyaratan pengguna dan mengubah spesifikasi karena pengetahuan baru dikembangkan dari mempelajari prototip. anda tidak berkomitmen untuk melakukan pengkodean asli sampai desain yang memuaskan telah dibuat prototip.

masalah dengan metode ini adalah anda tidak selalu tahu kapan harus keluar dari siklus. mengevaluasi prototipe mungkin tidak akurat dan mungkin tidak mengungkapkan semua masalah dalam prototipe.

usability engineering lifecycle
siklus hidup ue menggunakan kombinasi metode rekayasa hci dan perangkat lunak, dan lebih berguna untuk sistem yang besar. ini bukan konsep baru (walaupun baru-baru ini - mayhew, 1999), namun ini menyatukan banyak gagasan sebelumnya dan mengambil bit terbaik dari metode sebelumnya.

analisa kebutuhan
ini terdiri dari profil pengguna (memahami pengguna), analisis tugas, pertimbangan kemampuan dan batasan teknis dan platform dan pembentukan prinsip desain umum - definisi tujuan kegunaan anda, terkadang disebut panduan gaya atau spesifikasi desain awal.

desain / pengujian / pengembangan
hal ini dapat dibagi menjadi tiga tingkatan. pada level 1, ini adalah model atau desain konseptual, prototipe mock-up (lo-fidelity), yang dievaluasi untuk menghilangkan cacat desain utama. level 2 adalah standar desain layar (sds), merancang gaya interaksi dasar, layar dan kemudian mengevaluasi ini. sub-fase ini harus memungkinkan pengujian terhadap tujuan kegunaan. level 3 adalah desain antarmuka yang rinci, desain antarmuka dan interaksi yang halus, yang memungkinkan pengujian lebih lanjut terhadap tujuan kegunaan.

instalasi
ini adalah pengkodean sistem sebenarnya, dimana umpan balik dari pengguna yang bekerja dengan sistem nyata (penguji beta) digunakan.

metode ini memiliki keuntungan untuk menekankan banyak pengujian dan keterlibatan pengguna dan membagi pengembangan menjadi fase yang jelas dari rancangan yang semakin realistis, namun sulit untuk mengubah persyaratan saat anda belajar tentang pemahaman pengguna, dan berinteraksi dengan sistem.

skenario berbasis system design

ini didasarkan pada pengembangan lebih lanjut oleh carroll dan rosson pada tahun 2002 dan berevolusi dari kesulitan menggunakan tim multi-disiplin untuk pengembangan sistem. bagaimana semua orang bekerja sama dan saling memahami visi dan masalah? metode ini percaya anda bisa melakukan semuanya sampai tahap implementasi.

Sumber Referensi :
pling.org.uk
http://www.pling.org.uk/cs/doi.html
https://kliknyadong.blogspot.co.id/2017/11/siklus-hidup-pemodelan-simple.html