1. Pendahuluan
Tujuan perancangan adalah memberikan teknik yang dapat dihandalkan untuk perancangan secara berulang dari sistem interaktif yang sukses dan berdaya guna. Di Ilmu Komputer. Terdapat suatu sub disiplin besar yang membahas isu manajemen dan teknik dari pengembangan perangkat lunak (software) yang lebih dikenal sebagai rekayasa perangkat lunak (software engineering). Salah satu dasar dalam rekayasa perangkat lunak adalah daur hidup perangkat lunak (software life cycle) yang mendeskripsikan aktivitas yang terjadi mulai dari pembentukan konsep awal hingga tahap penggantian sistem dan implementasi.
Isu interaksi manusia dan computer yang menyangkut daya guna (usability) sistem interaktif relevan dengan seluruh aktivitas pada software life cycle. Sehingga software engineering untuk sistem interaktif bukan semata-mata menambahkan sebuah tahapan pada software life cycle namun lebih pada melibatkan teknik yang berada sepanjang software life cycle.
Isu interaksi manusia dan computer yang menyangkut daya guna (usability) sistem interaktif relevan dengan seluruh aktivitas pada software life cycle. Sehingga software engineering untuk sistem interaktif bukan semata-mata menambahkan sebuah tahapan pada software life cycle namun lebih pada melibatkan teknik yang berada sepanjang software life cycle.
2. Software Life Cycle
Software life cycle adalah sebuah usaha untuk mengidentifikasikan aktifitas yang terjadi selama pengembangan sebuah perangkat lunak. Aktifitas ini kemudian diurutkan sesuai dengan waktu pelaksanaannya pada proyek pengembangan manapun dan diaplikasikan teknik yang tepat pada setiap aktifitasnya.
Pada pengembangan produk perangkat lunak, kita memperhatikan dua pihak, yaitu pelanggan (customer) yang akan menggunakan produk dan desainer yang menghasilkan produk. Umumnya pelanggan dan desainer adalah sekelompok orang, dan pada beberapa customer dapat menjadi desainer sekaligus. Kadang penting untuk membedakan customer yang memberikan kerja atau menjadi klien bagi desainer dengan customer yang merupakan user yang benar-benar akan menjalankan sistem. Kedua peran tersebut dapat dipegang oleh orang atau kelompok yang berbeda.
Software life cycle adalah sebuah usaha untuk mengidentifikasikan aktifitas yang terjadi selama pengembangan sebuah perangkat lunak. Aktifitas ini kemudian diurutkan sesuai dengan waktu pelaksanaannya pada proyek pengembangan manapun dan diaplikasikan teknik yang tepat pada setiap aktifitasnya.
Pada pengembangan produk perangkat lunak, kita memperhatikan dua pihak, yaitu pelanggan (customer) yang akan menggunakan produk dan desainer yang menghasilkan produk. Umumnya pelanggan dan desainer adalah sekelompok orang, dan pada beberapa customer dapat menjadi desainer sekaligus. Kadang penting untuk membedakan customer yang memberikan kerja atau menjadi klien bagi desainer dengan customer yang merupakan user yang benar-benar akan menjalankan sistem. Kedua peran tersebut dapat dipegang oleh orang atau kelompok yang berbeda.
3. Aktifitas Pada Life Cycle (Waterfall Paradigm)
Aktifitas life cycle direpresentasikan dalam grafik pada gambar berikut ini. Bagan ini dikenal sebagai model waterfall karena mengikuti bentuk air terjun dengan satu aktifitas menuju aktifitas berikutnya.
a. Requirement Specification
Pada tahap requirement specification, desainer dan customer mencoba menangkap deskripsi seperti apa nantinya sistem yang sebenarnya akan dibangun. Aktifitas ini melibatkan pencarian informasi dari customer mengenai lingkungan kerja tempat sistem ininantinya akan diimplementasikan. Tahap ini sering juga disebut tahap Pemodelan Sistem.
b. Architectural Design
Tahap ini sering disebut tahap analisis. Aktifitas disini memfokuskan pada bagaimana sistem menyediakan layananan seperti diharapkan. Aktifitas pertama adalah high-level decomposition yang membagi sistem menjadi komponen-komponen sesuia dengan fungsinya. Pembagian ini dapat didasarkan pada pembagian yang sudah ada di sistem yang lama atau membuat dari baru. Architectural design tidak hanya meliputi pembagian fungsi sistem yang nantinya akan menyediakan layanan, namun juga mendeskripsikan keterhubungan dan pemakaian bersama sumber daya antara komponen tersebut.
c. Detailed Design
Architectural design atau sering disebut tahap desain, menghasilkan dekomposisi sistem yang memungkinkan pengembangan komponen secara terpisah untuk kemudian diintegrasikan kembali nantinya. Agar dapat diimplementasikan dengan bahasa pemograman, desainer harus melengkapi deskripsi tersebut dengan deskripsi yang lebih detail. Oleh karena itu, tahap detailed design adalah perbaikan dari deskripsi komponen yang dihasilkan oleh architectural design. Perilaku yang ditunjukkan oleh deskripsi pada level di atasnya, harus terdapat pula
di deskripsi detailnya.
di deskripsi detailnya.
d. Coding and Unit Testing
Hasil dari detailed design harus dalam bentuk yang dapat diimplementasikan ke executable programming language. Setelah coding, setiap komponen diuji untuk memverifikasi apakah berjalan dengan benar sesuai dengan criteria yang telah ditetapkan pada tahap-tahap awal.
e. Integration and Testing
Setelah komponen-komponen diimplementasikan dan diuji secara individual, maka komponen tersebut harus diintegrasikan seperti yang dideskripsikan pada architectural design. Pengujian lebih lanjut dilakukan untuk memastikan perilaku yang benar dan tidak ada konflik penggunaan sumber daya bersama. Pada tahap ini juga dimungkinkan untuk melakukan tes (acceptance test) dengan customer untuk memastikan sistem yang dibuat
memenuhi kebutuhan mereka. Setelah acceptance test maka produk dapat di-release kepada customer.
memenuhi kebutuhan mereka. Setelah acceptance test maka produk dapat di-release kepada customer.
f. Maintenance
Setelah produk di-release, semua pekerjaan yang dilakukan terhadap sistem dianggap sebagai pemeliharaan (maintenance) sampai produk memerlukan desain ulang menjadi versi baru atau produk tidak terpakai lagi. Maintenance melibatkan koreksi terhadap kesalahan/error yang ditemui pada sistem setelah di-release dan dilakukan perbaikan terhadap sistem, sehingga tahap maintenance memberikan feedback pada semua aktifitas lain pada life cycle.
4. Validasi dan Verifikasi
Selama life cycle, rancangan harus dicek untuk memastikan produk memenuhi kebutuhan customer (high-level requirement). Lengkap, dan konsisten. Proses pengecekan ini disebut sebagai validasi dan verifikasi. Boehm memberikan referensi definisi yang membedakan validasi sebagai designing “the right thing”, dan verifikasi sebagai designing “the thing right”.
Verifikasi dari suatu desain umumnya akan terjadi pada suatu aktifitas life cycle atau antara dua aktifitas yang berurutan sedangkan validasi dilakukan pada berbagai aktifitas yang membutuhkan kepuasan customer. Validasi lebih bersifat subyektif dibandingkan verifikasi. Hal ini utamanya disebabkan karena adanya perbedaan antara bentuk bahasa deskripsi kebutuhan (requirement) dengan bahasa perancangan. Pada bidang Interaksi Manusia dan Komputer, validasi ini sering disebut sebagai evaluasi yang dapat dilakukan secara terpisah oleh desainer atau bekerja sama dengan user.
Verifikasi dari suatu desain umumnya akan terjadi pada suatu aktifitas life cycle atau antara dua aktifitas yang berurutan sedangkan validasi dilakukan pada berbagai aktifitas yang membutuhkan kepuasan customer. Validasi lebih bersifat subyektif dibandingkan verifikasi. Hal ini utamanya disebabkan karena adanya perbedaan antara bentuk bahasa deskripsi kebutuhan (requirement) dengan bahasa perancangan. Pada bidang Interaksi Manusia dan Komputer, validasi ini sering disebut sebagai evaluasi yang dapat dilakukan secara terpisah oleh desainer atau bekerja sama dengan user.
5. Kelemahan Paradigma Life Cycle (Waterfall Paradigm)
Adapun kelemahan-kelemahan yang ditemui pada paradigm ini adalah antra lain :
• Pada proyek sebenarnya, jarang dapat mengikuti urutan-urutan pada paradigma ini yang sifatnya
adalah sekuensial.
• Sulit bagi customer untuk menentukan semua kebutuhan secara eksplisit
• Perangkat lunak atau sistem tidak tersedia sampai waktu yang telah ditentukan Read More......
