TUGAS IMK
PERMODELAN SIKLUS HIDUP IMK
Waterfall
model
Nama model ini sebenarnya adalah “Linear
Sequential Model”. 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. Secara umum
tahapan pada model waterfall dapat dilihat pada gambar berikut :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. 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.
Kelebihan:
-
Semua kebutuhan sistem dapat didefinisikan secara utuh, eksplisit, dan benar di
awal project, maka Software Engineering (SE) dapat berjalan
dengan baik dan tanpa masalah.
-
Setiap anggota dalam SE mengetahui secara pasti apa yang harus dikerjakan dan
kapan harus diselesaikan.
- Mudah dalam
implementasi karena pada saat implementasi telah dilakukan uji coba terhadap
setiap bagian dari program.
-
Dokumentasi pengembangan sistem sangat terorganisir, karena pada setiap tahap
harus terselesaikan dengan lengkap sebelum melangkah ke tahap berikutnya.
Kekurangan:
- Pengguna sulit untuk
menuangkan ide atau kebutuhan secara explisit pada awal pembuatan sistem.
-
Apabila terjadi perubahan, maka model ini tidak bisa digunakan.
-
Diperlukan manajemen yang baik, karena proses pengembangan tidak dapat berulang
sebelum menghasilkan suatu produk, yaitu aplikasi. Jadi apabila dalam suatu
proses seperti perancangan tidak selesai tepat waktu, maka akan mempengaruhi
keseluruhan proses pengembangan perangkat lunak.
-
Membutuhkan waktu yang relatif lama karena model ini bersifat sequential.
Siklus
Hidup Untuk Pengembangan (RAD : Linier Sequential)
Rapid Aplication Development (RAD) adalah sebuah model proses perkembangan software sekuensial linier yang menekankan siklus perkembangan yang sangat pendek. Model RAD ini merupakan sebuah adaptasi “kecepatan tinggi” dari model sekuensial linier di mana perkembangan cepat dicapai dengan menggunakan pendekatan kontruksi berbasis komponen. Jika kebutuhan dipahami dengan baik, proses RAD memungkinkan tim pengembangan menciptakan “sistem fungsional yang utuh” dalam periode waktu yang sangat pendek (kira-kira 60 sampai 90 hari). Karena dipakai terutama pada aplikasi sistem konstruksi, pendekatan RAD melingkupi fase – fase sebagai berikut :
·
Business
modeling.
Aliran informasi di antara fungsi – fungsi bisnis dimodelkan dengan
suatu cara untuk menjawab pertanyaan – pertanyaan berikut :
informasi apa yang
mengendalikan proses bisnis? Informasi apa yang di munculkan? Siapa yang
memunculkanya? Ke mana informasi itu pergi? Siapa yang memprosesnya?
·
Data
modeling.
Aliran informasi yang didefinisikan sebagai bagian dari fase business
modelling disaring ke dalam serangkaian objek data yang dibutuhkan untuk
menopang bisnis tersebut. Karakteristik (disebut atribut) masing – masing objek
diidentifikasi dan hubungan antara objek – objek tersebut didefinisikan.
·
Proses
modeling.
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.
·
Application
Generation.
RAD mengasumsikan pemakaian teknik generasi ke empat. Selain
menciptakan perangkat lunak dengan menggunakan bahasa pemrograman generasi
ketiga yang konvensional, RAD lebih banyak memproses kerja untuk memkai lagi
komponen program yang ada ( pada saat memungkinkan) atau menciptakan komponen
yang bisa dipakai lagi (bila perlu). Pada semua kasus, alat – alat bantu
otomatis dipakai untuk memfasilitasi konstruksi perangkat lunak.
·
Testing
and turnover.
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.
Kelebihan :
a. RAD
mengikuti tahapan pengembangan sistem sepeti umumnya, tetapi mempunyai kemampuan
untuk menggunakan kembali komponen yang ada (reusable object).
b. Setiap
fungsi dapat dimodulkan dalam waktu tertentu dan dapat dibicarakan oleh tim RAD yang terpisah dan kemudian
diintegrasikan sehingga waktunya lebih efesien.
Kekurangan :
a. Bagi proyek yang besar tetapi
berskala, RAD memerlukan sumber daya manusia yang memadai untuk menciptakan jumlah tim RAD yang
baik.
b. RAD menuntut pengembangan dan
pelanggan memiliki komitmen di dalam aktivitas rapid-fire yang diperlukan untuk melengkapi sebuah sistem, di
dalam kerangka waktu yang sangat diperpendek. Jika
komitmen tersebut tidak ada, proyek RAD akan
gagal.
V-Model
Model ini merupakan
perluasan dari model waterfall. Disebut sebagai perluasan karena tahap-tahapnya
mirip dengan yang terdapat dalam model waterfall. Jika dalam model waterfall
proses dijalankan secara linear, maka dalam model V proses dilakukan bercabang.
Dalam model V ini digambarkan hubungan antara tahap pengembangan software
dengan tahap pengujiannya.
Berikut
penjelasan masing-masing tahap beserta tahap pengujiannya:
1. Requirement Elicitation & Acceptance Testing
Tahap Requirement Analysis sama seperti yang terdapat dalam model waterfall. Keluaran dari tahap ini adalah dokumentasi kebutuhan pengguna.
Acceptance Testing merupakan tahap yang akan mengkaji apakah dokumentasi yang dihasilkan tersebut dapat diterima oleh para pengguna atau tidak.
2. Analysis & System Testing
Dalam tahap ini analis sistem mulai merancang sistem dengan mengacu pada dokumentasi kebutuhan pengguna yang sudah dibuat pada tahap sebelumnya. Keluaran dari tahap ini adalah spesifikasi software yang meliputi organisasi sistem secara umum, struktur data, dan yang lain. Selain itu tahap ini juga menghasilkan contoh tampilan window dan juga dokumentasi teknik yang lain seperti Entity Diagram dan Data Dictionary.
3. Architecture Design & Integration Testing
Sering juga disebut High Level Design. Dasar dari pemilihan arsitektur yang akan digunakan berdasar kepada beberapa hal seperti: pemakaian kembali tiap modul, ketergantungan tabel dalam basis data, hubungan antar interface, detail teknologi yang dipakai.
4. Component Design & Unit Testing
Sering juga disebut sebagai Low Level Design. Perancangan dipecah menjadi modul- modul yang lebih kecil. Setiap modul tersebut diberi penjelasan yang cukup untuk memudahkan programmer melakukan coding. Tahap ini menghasilkan spesifikasi program seperti: fungsi dan logika tiap modul, pesan kesalahan, proses input-output untuk tiap modul, dan lain-lain.
5. Coding
Dalam tahap ini dilakukan pemrograman terhadap setiap modul yang sudah dibentuk.
Tahap Requirement Analysis sama seperti yang terdapat dalam model waterfall. Keluaran dari tahap ini adalah dokumentasi kebutuhan pengguna.
Acceptance Testing merupakan tahap yang akan mengkaji apakah dokumentasi yang dihasilkan tersebut dapat diterima oleh para pengguna atau tidak.
2. Analysis & System Testing
Dalam tahap ini analis sistem mulai merancang sistem dengan mengacu pada dokumentasi kebutuhan pengguna yang sudah dibuat pada tahap sebelumnya. Keluaran dari tahap ini adalah spesifikasi software yang meliputi organisasi sistem secara umum, struktur data, dan yang lain. Selain itu tahap ini juga menghasilkan contoh tampilan window dan juga dokumentasi teknik yang lain seperti Entity Diagram dan Data Dictionary.
3. Architecture Design & Integration Testing
Sering juga disebut High Level Design. Dasar dari pemilihan arsitektur yang akan digunakan berdasar kepada beberapa hal seperti: pemakaian kembali tiap modul, ketergantungan tabel dalam basis data, hubungan antar interface, detail teknologi yang dipakai.
4. Component Design & Unit Testing
Sering juga disebut sebagai Low Level Design. Perancangan dipecah menjadi modul- modul yang lebih kecil. Setiap modul tersebut diberi penjelasan yang cukup untuk memudahkan programmer melakukan coding. Tahap ini menghasilkan spesifikasi program seperti: fungsi dan logika tiap modul, pesan kesalahan, proses input-output untuk tiap modul, dan lain-lain.
5. Coding
Dalam tahap ini dilakukan pemrograman terhadap setiap modul yang sudah dibentuk.
Keuntungan 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.
Kerugian 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.
- oolnya 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.
- 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.
- 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.
- oolnya 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.
- 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.
Star Lifecycle Model (Hartson
& Hix, 1989)
Memahami apa kegiatan yang terlibat dalam
desain interaksi adalah langkah pertama untuk mampu melakukannya, tetapi
juga penting untuk mempertimbangkan bagaimana kegiatan terkait dengan satu
sama lain sehingga proses pengembangan penuh dapat dilihat. Siklus hidup
jangka Model ini digunakan untuk mewakili model yang menangkap serangkaian
kegiatan dan bagaimana mereka terkait. Model canggih juga
menggabungkan deskripsi tentang kapan dan bagaimana untuk bergerak dari
satu kegiatan ke depan dan deskripsi dari kiriman untuk setiap kegiatan.Alasan
model seperti yang populer adalah bahwa mereka memungkinkan pengembang, dan
khususnya manajer, untuk mendapatkan gambaran menyeluruh dari upaya
pembangunan sehingga kemajuan yang dapat dilacak, kiriman ditentukan, sumber
daya yang dialokasikan, target ditetapkan, dan sebagainya.Model yang ada
memiliki berbagai tingkat kecanggihan dan kompleksitas. untuk
proyek melibatkan hanya beberapa pengembang berpengalaman, proses yang
sederhana mungkin akan memadai. Namun, untuk sistem yang lebih besar yang
melibatkan puluhan atau ratusan pengembang dengan ratusan atau ribuan
pengguna, proses yang sederhana saja tidak cukup untuk
menyediakan struktur manajemen dan disiplin yang diperlukan untuk
merancang sebuah produk yang dapat digunakan. jadi sesuatu yang diperlukan
yang akan memberikan formalitas lebih dan lebih disiplin. Perhatikan
bahwa ini tidak berarti inovasi yang hilang atau kreativitas yang menahan.
Ini hanya berarti bahwa Tentang waktu yang sama bahwa mereka yang terlibat
dalam rekayasa perangkat lunak sedang mencari alternatif untuk siklus
hidup air terjun, demikian juga orang-orang yang terlibat dalam HCI
mencari alternatif cara untuk mendukung desain antarmuka. Pada tahun 1989,
Star siklus hidup model yang diusulkan oleh Hartson dan Hix seperti yang
ditunjukkan pada gambar.
Hal
ini muncul dari beberapa pekerjaan empiris mereka melihat bagaimana desainer
antar muka pergi tentang pekerjaan mereka. Mereka mengidentifikasi dua
mode yang berbeda dari aktivitas: modus analitik dan sintetis modus.Yang
pertama ditandai dengan pengertian seperti top-down, pengorganisasian,
peradilan,dan formal, bekerja dari pandangan sistem terhadap
pengguna pandangan, yang terakhir ditandai dengan pengertian seperti
bottom-up, bebas berpikir, kreatif dan adhoc, bekerja dari pandangan
pengguna terhadap pandangan sistem. antarmuka desainer bertugas di
desainer perangkat lunak.Berbeda dengan model siklus hidup diperkenalkan di
atas, siklus hidup bintang tidak menentukan apapun pemesanan kegiatan.
Bahkan, kegiatan yang sangat saling berhubungan: Anda dapat
memindahkan dari kegiatan apapun kepada lainnya, asalkan Anda pertama kali
pergi melalui kegiatan evaluasi.Hal ini mencerminkan temuan dari studi empiris.
Evaluasi merupakan pusat model ini, dan setiap kali suatu kegiatan
selesai, hasilnya (s) harus dievaluasi. Jadi proyek mungkin mulai dengan
pengumpulan persyaratan, atau mungkin mulai dengan mengevaluasi yang
ada situasi, atau dengan menganalisis tugas yang ada, dan
sebagainya.Siklus hidup Usability Rekayasa Siklus hidup Teknik Usability
diusulkan oleh Deborah Mayhew pada tahun 1999.Banyak orang telah menulis
tentang rekayasa kegunaan, dan sebagai Mayhew sendiri mengatakan,
"Saya tidak menciptakan konsep Siklus Hidup Rekayasa Usability. Aku
juga tidak menemukan satu pun tugas Usability Teknik termasuk dalam siklus
hidup .... ".
Model Rancangan Interaksi Sederhana(Simple
Interaction Design Model)
Keterangan:
•Identifikasi kebutuhan dan persyaratan system
disini suatu sistem akan di identifikasi sesuai dengan 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
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.
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.
