Human Computer Interaction: 2014

Mengapa harus mempelajari proses dan siklus hidup perangkat lunak ?

Sehingga dengan mempelajari siklus hidup dari perangkat lunak, maka secara otomatis juga akan mempelajari proses hidup dari perangkat lunak itu sendiri. Juga bisa mampu mempelajari hal apa yang seharusnya dilakukan oleh pengembang perangkat lunak dalam proses pengembangan perangkat lunak itu sendiri.

Jadi kesimpulannya dengan mempelajari siklus hidup berarti juga mempelajari langkah – langkah untuk menjadi seorang software egineering yang baik, didalam lingkup teori dan juga implementasi.

A. Model Waterfall

(Pressman : 2007)

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.

2. Pengertian Model 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

3. Karakteristik

Dalam model ini terdapat beberapa sifat-sifat yang menojol dan cenderung menjadi permasalahan pada model waterfall.

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

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

4. Teori-teori lama menyimpulkan ada beberapa hal, yaitu:

a. Ketika semua persyaratan sudah dipahami dengan baik di awal pengembangan.

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

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

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

5. Tahapan atau fase model waterfall

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:

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

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

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

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

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

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

6. Tahap Pengembangan Model Waterfall

Tahap – tahap pengembangan model waterfall adalah :

· Analisis dan definisi persyaratan Pelayanan, batasan, dan tujuan sistem ditentukan melalui konsultasi dengan user.

· Perancangan sistem dan perangkat lunak Kegiatan ini menentukan arsitektur sistem secara keseluruhan.

· Implementasi dan pengujian unit Perancangan perangkat lunak direalisasikan sebagai serangkaian program.

· Integrasi dan pengujian sistem Unit program diintegrasikan atau diuji sebagai sistem yang lengkap untuk menjamin bahwa persyaratan sitem telah terpenuhi

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

7. Permasalahan Yang ada di Pengembangan Waterfall

a. Sebagai akibat dari biaya pembuatan dan persetujuan dokumen, iterasi menjadi mahal dan melibatkan pengerjaan ulang yang signifikan. Dengan demikian, setelah sejumlah iterasi kecil, normal membekukan bagian dari pengembangan seperti spesifikasi. Masalah-masalah dikesampingkan, diabaikan atau dihindari untuk pemecahan kemudian. Pembekuan persyaratan dini ini bisa berarti bahwa sistem tidak dapat melakukan seperti yang diinginkan user.

b. Sistem memiliki struktur yang buruk jika masalah perancangan dihindari dengan trik implementasi. Dengan demikian pada fase akhir perangkat lunak digunakan, error dan penghapusan persyaratan perangkat lunak yang asli akan ditemukan.

c. Terjadinya pembagian proyek menjadi tahap-tahap yang tidak fleksibel. Komitmen harus dilakukan pada tahap awal proses dan akan sulit bagi perekayasa untuk menanggapi perubahan persyaratan pelanggan.

8. Keunggulan dari Model Waterfall

Keunggulan model pendekatan pengembangan software dengan metode waterfall adalah pencerminan kepraktisan rekayasa, yang membuat kualitas software tetap terjaga karena pengembangannya yang terstruktur dan terawasi. Disisi lain model ini merupakan jenis model yang bersifat dokumen lengkap, sehingga proses pemeliharaan dapat dilakukan dengan mudah. Akan tetapi dikarenakan dokumentasi yang lengkap dan sangat teknis, membuat pihak klien sulit membaca dokumen yang berujung pada sulitnya komunikasi antar pengembang dan klien. Dokumentasi kode program yang lengkap juga secara tak langsung menghapus ketergantungan pengembang terhadap pemrogram yang keluar dari tim pengembang. Hal ini sangat menguntungkan bagi pihak pengembang dikarenakan proses pengembangan perangkat lunak tetap dapat dilanjutkan tanpa bergantung pada pemrogram tertentu.

9. Kelemahan Model Waterfall

Kelemahan pengembangan software dengan metode waterfall yang utama adalah lambatnya proses pengembangan perangkat lunak. Dikarenakan prosesnya yang satu persatu dan tidak bisa diloncat-loncat menjadikan model klasik ini sangat memakan waktu dalam pengembangannya. Disisi lain, pihak klien tidak dapat mencoba sistem sebelum sistem benar-benar selesai pembuatannya. Kelemahan yang lain adalah kinerja personil yang tidak optimal dan efisien karena terdapat proses menunggu suatu tahapan selesai terlebih dahulu.

Secara keseluruhan model pendekatan pengembangan software dengan metode waterfall cocok untuk pengembangan software / perangkat lunak dengan tingkat resiko yang kecil, dan memiliki ukuran yang kecil serta waktu pengembangan yang cukup panjang. Model ini tidak disarankan untuk ukuran perangkat lunak yang besar dan tingkat resiko yang besar.

B. V-Model

Sejarah V Model

Pada tahun 1986, Federal Ministry for Defense negara Jerman memulai dua proyek teknologi informasi. Dimana kedua proyek tersebut adalah software development environment for information system (SEU IS) dan software development environment for weapon and weapon delivery systems (SEU-WS).

Dimana dalam pelaksanaan kedua proyek tersebut ada beberapa tujuan yang ingin dicapai yaitu:

1. Membuat biaya dan proses-proses yang ada pada seluruh software development process menjadi jelas.

2. Menerapkan minimum standard untuk menjamin kualitas software yang di hasilkan.

3. Melakukan standarisasi dan membuat software development process lebih transparan

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 adalahv ariant V Model yang dikembangkan pada tahun 1997. Variant V Model ini muncul karena adanya perkembangan pada software development process (misal: object orientation).

Model ini merupakan perluasan dari model waterfall. Disebut sebagai perluasan karena tahap-tahapnya mirip dengan yang yang dalam model waterfall. Jika dalam model waterfall proses dijalankan secara linier, maka dalam model V proses dalikukan bercabang dalam model V ini digambarkan hubungan antara tahap pengembangan software dengan tahap pengujiannya.

Bisa dikatakan 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 Analysis & 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. System Design & 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. Module 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.

Kelebihan v model :

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

2. Penyesuaian yang cepat pada projek yang baru

3. Memudahkan dalam pembuatan dokumen projek

4. Biaya yang murah dalam perawatan dan modifikasinya

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

6. 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 :

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

2. Prosesnya hanya secara sementara. Ketika project selesai, jalannya proses model dihentikan. Tidak berlangsung untuk keseluruhan organisasi.

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

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

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

C. Star Lifecycle Model

Pada tahun 1989, siklus hidup model ini diusulkan oleh Hartson dan Hix seperti yang ditunjukkan pada gambar di atas.

Dalam Siklus permodelan ini pengujian dilakukan terus menerus, tidak harus diakhir. 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. Siklus hidup star tidak menentukan apapun pemesanan kegiatan. Bahkan, kegiatan yang sangat saling berhubungan: Anda dapat berpindah dari aktivitas apapun kepada pihak lain, 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 harus dievaluasi. Jadi proyek dapat dimulai dengan pengumpulan persyaratan, atau mungkin mulai dengan mengevaluasi situasi yang ada, atau dengan menganalisis tugas yang ada, dan sebagainya

Tahapan Model

1. Analisa

Identifikasi kemampuan user, strategi yang digunakan untuk meningkatkan ketrampilannya, alat yang saat ini dipakai, masalah-masalah yang dialami, perubahan yang diinginkan baik dalam ketrampilan maupun peralatan.

Metode : Tanya kemampuan user dan buat daftar dengan skala prioritas, observasi ketrampilan di lapangan.

2. Evaluasi kompetisi

Tentukan kekuatan dan kelemahan rancangan

Metode : pengguna diminta untuk mencoba menggunakan berbagi produk dan minta untuk menyebutkan kelebihan dan kelemahan dari masing-masing produk.

3. Ongoing design/rancang sambil jalan

Gunakan hasil analisa untuk membuat alternatif solusi, minta masukan sampai dengan penentuan pilihan yang terbaik.

Metode : tanyai user sehubungan dengan pengalaman menggunakan prototipe.

4. Evaluasi dan validasi

Secara periodik user memberikan masukan selama pengembangan dan perancangan akan diulang berdasarkan masukan tadi.

Metode : amati kebutuhan pokok user dalam menggunakan sistem.

5. Benchmark

Memadukan hal-hal terbaik yang dimiliki pesaing untuk diterapkan dalam sistem yang dibangun Metode : menggali informasi dari user hal-hal yang sebaiknya ada dibandingkan dengan kompetitor,

D. Simple Interaction Design Model

Penjelasan simple interaction design model :

1. Identifikasi kebutuhan dan persyaratan sistem disini suatu sistem akan di identifikasi sesuai denga kebutuhan sistem itu sendiri.

2. Pengembangan desain alternatif (desain konseptual dan fisikal)

3. Membuat versi interaktif dari desain yang dihasilkan

4. Mengevaluasi desain (usabilitas dan user experience)

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 di Desain rancangan tersebut dibangun dan harus interaktif. Setelah itu barulah rancangan tersebut dievaluasi.

Evaluasi dapat dilakukan dimana saja, rancangan yang telah di evakuasi dapat kembali 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.

E. Rapid Application Development

Merupakan model proses pengembangan perangkat lunak secara linear sequential yang menekankan pada siklus pengembangan yang sangat singkat/pendek. Jika kebutuhan dipahami dengan baik, proses RAD memungkinkan tim pengembangan menciptakan “sistem fungsional yang utuh” dalam periode waktu yang sangat pendek (kira-kira 60-90 hari). Pendekatan RAD model menekankan cakupan :

a. Pemodelan bisnis (Bussiness Modelling)

Aliran informasi diantara fungsi-fungsi bisnis dimodelkan dengan suatu cara untuk menjawab pertanyaan-pertanyaan berikut : Informasi apa yang mengendalikan proses bisnis ? Kemana informasi itu pergi? Siapa yang memprosesnya ?

b. Pemodelan data (Data Modelling)

Aliran informasi yang didefinisikan sebagai bagian dari fase pemodelan bisnis disaring ke dalam serangkaian objek data yang dibutuhkan untuk menopang bisnis tersebut. Karakteristik/atribut dari masing-masing objek diidentifikasi dan hubungan antara objek-objek tersebut didefinisikan.

c. Pemodelan proses (Process Modelling)

Aliran informasi yang didefinisikan dalam fase pemodelan data 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.

d. Pembuatan aplikasi (Application generation)

Selain menciftakan perangkat lunak dengan menggunakan bahasa pemrograman generasi ketiga yang konvensional, RAD lebih banyak memproses kerja untuk memakai lagi komponen program yang telah ada atau menciftakan komponen yang bias dipakai lagi. Pada semua kasus, alat-alat Bantu otomatis dipakai untuk memfasilitasi kontruksi perangkat lunak.

e. Pengujian dan pergantian (Testing and turnover)

Karena proses RAD menekankan pada pemakaian kembali, banyak komponen yang telah diuji. Hal ini mengurangi keseluruhan waktu pengujian. Tapi komponen baru harus diuji.

Resiko dari Rapid Application Development

1. Project Risk

Dalam proses development bisa terjadi kesalahpahaman antara user dan developer yang mengakibatkan perubahan dalam timeline project, selain itu kesalahpahaman juga dapat mengakibatkan requirement awal dari suatu project berubah, sehingga waktu pengerjaan project dapat menjadi lebih lama.

2. Technical Risk

RAD memfokuskan seberapa cepat sebuah project dikerjakan, sehingga developer mengesampingkan masalah dokumentasi sebuah program, minimnya dokumentasi pada sebuah program ini berdampak pada masa yang akan mendatang dimana program tidak mudah untuk dikembangkan kembali.

3. Bussiness Risk

RAD adalah metode yang digunakan untuk mendevelop sebuah program dengan waktu yang minimal, untuk mencapai ini dibutuhkan kemampuan seorang developer yang handal. Ketika kemampuan dari programmer tersebut masih kurang yang akan menjadi masalah ada quality dari software yang dihasilkan, sehingga berdampak terharap tingkat kepuasan pelanggan.

Kelebihan model RAD

Setiap fungsi mayor dapat dimodulkan dalam waktu tertentu kurang dari 3 bulan dandapat dibicarakan oleh tim RAD yang terpisah dan kemudian diintegrasikan sehinngawaktunya lebih efesien. RAD mengikuti tahapan pengembangan sistem sepeti umumnya, tetapi mempunyaikemampuan untuk menggunakan kembali komponen yang ada (reusable object) sehingga pengembang pengembang tidak perlu membuat dari awal lagi dan waktulebih singkat