Rekayasa Perangkat Lunak

Pengenalan Rekayasa Perangkat Lunak

Rekayasa Perangkat Lunak berasal dari 2 kata Rekayasa dan Perangkat Lunak.

Rekayasa Perangkat Lunak merupakan perihal kegiatan yang kreatif dan sistematis berdasar suatu disiplin ilmu yang membangun suatu perangkat lunak berdasar suatu aspek masalah tertentu.

Dalam Rekayasa Perangkat Lunak dilakukan Proses Perangkat Lunak dengan menggunakan model Proses yang merupakan Daur Hidup Rekayasa Perangkat Lunak. Model Proses ini terdiri dari beberapa karakteristik pendekatan proses. Dalam Proses pembangunan Perangkat Lunak perlu diketahui Biaya yang dikeluarkan.

1.     Latar belakang Disiplin Rekayasa Perangkat Lunak

Faktor-faktor yang melatarbelakangi munculnya RPL :

Ketidakmampuan organisasi memprediksi waktu, usaha dan beaya u/membangunperangkat lunak Perubahan nisbah/rasio beaya perangkat keras thd harga perangkat lunak Kemajuan pesat perangkat keras Kemajuan dalam teknik-teknik pembuatan perangkat lunak.Tuntutan yang lebih tinggi thd jumlah perangkat lunak Tuntutan yang lebih tinggi thd mutu perangkat lunak Meningkatnya peran pemeliharaan.

2.     Krisis Perangkat Lunak

Masalah nyata yang sudah mengganggu perkembangan perangkat lunak

Serangkaian masalah yang terjadi dalam perkembangan perangkat lunak komputer.

Masalah yang ada tidak hanya terbatas pada perangkat lunak yang tidak berfungsi dengan baik tapi juga pada penderitaan yang melingkupi masalah-masalah yang berhubungan dengan bagaimana mengembangkan perangkat lunak, bagaimana memelihara volume perangkat lunak yang sedang tumbuh dan bagaimana mengejar kebutuhan perangkat lunak lebih banyak lagi Penyebab krisis atau penderitaan Perangkat lunak dapat ditelusuri dengan sebuah mitologi  yang muncul selama masa sejarah awal perkembangan perangkat lunak.

Mitos perangkat lunak ini berbicara atas salah informasi dan keraguan. Masa sekarang kebanyakan kaum profesional memiliki banyak pengetahuan mengetahui berbagai mitos di bidang ilmu yang digelutinya (sikap yang salah yang menyebabkan masalah yang serius bagi manajer serta masyarakat teknis). Hal ini terlihat berbagai sisi pandang dari pihak Manajer/Sponsor, elanggan atau Pengembang/Praktisi

3. Rekayasa Perangkat Lunak

Perangkat Lunak Merupakan program-program komputer dan dokumentasi yang berkaitan. Rekayasa perangkat lunak berasal dari 2 kata yaitu Software (Perangkat Lunak) danEngineering (Rekayasa).Perangkat Lunak (Software) adalah source code pada suatu program atau sistem. Perangkat lunak tidak hanya dokumentasi terhadap source code tapi juga dokumentasi terhadap sesuatu yang dibutuhkan selama pengembangan, instalasi, penggunaan dan pemeliharaan sebuah sistem.

Engineering atau Rekayasa adalah aplikasi terhadap pendekatan sistematis yang berdasar atas ilmu pengetahuan dan matematis serta aplikasi tentang produksi terhadap struktur,mesin, produk, proses atau sistem.

Produk perangkat lunak mengadopsi pendekatan yang sistematis dan terorganisir terhadap pekerjaannya dan menggunakan tool yang sesuai serta teknik yang ditentukan berdasarkan masalah yang akan dipecahkan, kendala pengembangan dan sumber daya yang tersedia

Rekayasa Perangkat Lunak (RPL) juga merupakan pendekatan sistematis dan matematis unstuk membangun, memelihara dan mengenyahkan perangkat lunak.

Dari cara pandang lain, RPL adalah pendekatan sistematis untuk merekayasaperangkat lunak yang handal/bermutu, tepat waktu dan dengan biaya yang optimal.  

4. Mutu Perangkat Lunak

Terdapat 3 pihak (minimal) yang mempengaruhi mutu P.L yaitu

1.     Sponsor

Seseorang atau organisasi yang membiayai/membayar selama pengembangan atau perantaraan sistem software dan biasanya mempunyai respon terhadap pengembangan sistem software itu sendiri dengan melibatkan perhitungan biaya yang optimal.

2.     User

Setiap orang yang secara langsung berinteraksi terhadap eksekusi software, yang secara langsung memberi input ke komputer dan menggunakan/menikmati output dari komputer.

3.     Developer

Seseorang atau organisasi yang memberikan modifikasi dan memelihara terhadap error serta mengembangkan sistem software tersebut

Karakteristik Perangkat Lunak

Atribut Perangkat Lunak seharusnya memberikan pengguna kebutuhan fungsionalitas dan unjuk kerja yang dapat di rawat, berguna.Dalam Buku Software Engineering Ian Sommerville, Perangkat Lunak mempunyai Karakteristik sebagai berikut:

1.     Maintanability (Dapat Dirawat), Perangkat Lunak harus dapat memenuhi perubahan kebutuhan

2.     Dependability, Perangkat Lunak harus dapat dipercaya

3.     Efisiensi, Perangkat Lunak harus efisien dalam penggunaan resource

4.     Usability, Perangkat Lunak harus dapat digunakan sesuai dengan yang direncanakan

Pada Umumnya terdapat 4 siklus hiup pengembangan software Yaitu :

1.     Model WaterFall

Menurut Pressman (2010), model waterfall adalah model klasik yang bersifat sistematis, berurutan dalam membangun software. Nama model ini sebenarnya adalah “Linear Sequential Model”. Model ini sering disebut dengan “classic life cycle” atau model waterfall. Model ini termasuk kedalam model generic pada rekayasa perangkat lunak dan pertama kali 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.

Waterfall adalah suatu metodologi pengembangan perangkat lunak yang mengusulkan pendekatan kepada perangkat lunak sistematik dan sekuensial yang mulai pada tingkat kemajuan sistem pada seluruh analisis, design, kode, pengujian dan pemeliharaan. Langkah-langkah yang harus dilakukan pada metodologi Waterfall adalah sebagai berikut :

A.    Analisis kebutuhan perangkat lunak Proses pengumpulan kebutuhan diintensifkan dan difokuskan, khususnya pada perangkat lunak. Untuk memahami sifat program yang dibangun, rekayasa perangkat lunak (analisis) harus memahami domain informasi, tingkah laku, unjuk kerja dan antar muka (interface) yang diperlukan. Kebutuhan baik untuk sistem maupun perangkat lunak di dokumentasikan dan dilihat dengan pelanggan.

Mengumpulkan kebutuhan secara lengkap kemudian dianalisis dan didefinisikan kebutuhan yang harus dipenuhi oleh software yang akan dibangun. 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.    Desain
Desain perangkat lunak sebenarnya adalah proses multi langka yang berfokus pada empat atribut sebuah program yang berbeda; struktur data, asitektur perangkat lunak, representasi interface dan detail (algoritma) prosedural.  Proses desain menerjemahkan syarat/kebutuhan kedalam sebuah representasi perangkat lunak yang dapat di perkirakan demi kualitas sebelum dimulai pemunculan kode. Sebagaimana persyaratan, desain didokumentasikan dan menjadi bagian  dari konfigurasi perangkat lunak.
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 dua aktivitas tersebut (pencarian kebutuhan sistem dan software) harus didokumentasikan dan ditunjukkan kepada user. Proses software design untuk mengubah kebutuhan-kebutuhan di atas menjadi representasi ke dalam bentuk "blueprint" software sebelum coding dimulai. Desain harus dapat mengimplementasikan kebutuhan yang telah disebutkan pada tahap sebelumnya. seperti dua aktivitas sebelumnya, maka proses ini juga harus didokumentasikan sebagai konfigurasi dari software.

C.    Generasi Kode 

Desain harus diterjemahkan dalam bentuk mesin yang bisa di baca. Langkah pembuatan kode melakukan tugas ini. Jika desain dilakukan dengan cara yang lengkap, pembuatan kode dapat diselesaikan secara mekanis.
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.

D.    Pengujian
   Proses Pengujian dilakukan pada logika internal untuk memastikan semua pernyataan sudah diuji. Pengujian eksternal fungsional untuk menemukan kesalahan-kesalahan dan memastikan bahwa input akan memberikan hasil yang aktual sesuai yang dibutuhkan.

E.    Pemeliharaan

Perangkat lunak yang sudah disampaikan kepada pelanggan pasti akan mengalami perubahan. Perubahan tersebut bisa karena mengalami kesalahan karena perangkat lunak harus menyesuaikan dengan lingkungan (periperal atau sistem operasi baru) baru, atau karena pelanggan membutuhkan perkembangan fungsional atau unjuk kerja.
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.
Pemeliharaan suatu software diperlukan, termasuk di dalamnya adalah pengembangan, karena software yangdibuat tidak selamanya hanya seperti itu ketika dijalankan mungkin saja masih ada error 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 dari model ini adalah selain karena pengaplikasian menggunakan model ini mudah, kelebihan model ini adalah ketika semua kebutuhan sistem dapat didefinisikan secara utuh, eksplisit, dan benar di awal proyek, maka Software Engineering(SE) dapat berjalan dengan baik dan tanpa masalah meskipun seringkali kebutuhan sistem tidak dapat didefinisikan se-eksplisit yang diinginkan, tetapi paling tidak, problem pada kebutuhan sistem di awal proyek lebih ekonomis dalam hal uang (lebih murah), usaha, dan waktu yang terbuang lebih sedikit jika dibandingkan problem yang muncul pada tahap-tahap selanjutnya.
Kekurangan yang utama dari model ini adalah kesulitan dalam mengakomodasi perubahan setelah proses dijalani. Fase sebelumnya harus lengkap dan selesai sebelum mengerjakan fase berikutnya.

Masalah dengan waterfall :

a)     Perubahan sulit dilakukan karena sifatnya yang kaku

b)     Karena sifat kakunya, model ini cocok ketika kebutuhan dikumpulkan secara lengkap sehingga perubahan bisa ditekan sekecil mungkin. Tapi pada kenyataannya jarang sekali konsumen/pengguna yang bisa memberikan kebutuhan secara lengkap, perubahan kebutuhan adalah sesuatu yang wajar terjadi.

c)     Waterfall pada umumnya digunakan untuk rekayasa sistem yang besar yaitu dengan proyek yang dikerjakan di beberapa tempat berbeda, dan dibagi menjadi beberapa bagian sub-proyek.

Berikut ini gambaran dari waterfall model.

Fase-fase dalam model waterfall menurut referensi Sommerfille :

 

B. V Model

Apa itu V Model?

Merupakan model pengembangan perangkat lunak yang didasarkan pada hubungan antara setiap fase pengembangan siklus hidup yang tercantum dalam model Watterfall yang merupakan pengembangan perangkat lunak dan fase yang terkait pengujian.

Apa saja tahapan V Model?

Lifecycle Process Model

Allocation of Methods

Functional Tools Requirements

Apa saja Submodel pada V Model?

Project Management (PM)

System Development (SD)

Quality Assurance (QA)

Configuration Management (CM)

Fase Implementasi Pada V Model

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

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

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

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

e.  Coding

     Dalam tahap ini dilakukan pemrograman terhadap setiap modul yang sudah dibentuk.

Tahapan V Model

Tahapan pada V Model dibagi menjadi 2 garis besar yaitu tahap Verifikasi dan Validasi atau testing.

Tahap Verfiikasi mengacu kepada usaha penyesuaian spesifikasi software dengan kebutuhan klien/konsumen, tahapan ini meliputi serangkaian kegiatan sebagai berikut:

Business Case: Merupakan tahapan awal yang menggambarkan kebutuhan/harapan konsumen terhadap sistem yang akan dikembangkan, termasuk manfaat sistem terhadap konsumen dan perkiraan biaya yang harus disediakan.

Requirement: pada fase ini klien mendapatkan gambaran atau diminta memberikan gambaran kebutuhan yang diharapkan dapat dipenuhi oleh software, baik kebutuhan fungsional maupun non fungsional.

Analisis Informasi: Setelah diperoleh spesifikasi sistem dari fase requirement, selanjutnya aktivitas difokuskan bagaimana cara kerja software untuk memenuhi kebutuhan tersebut, termasuk metode, hardware dan software apa saja yang diperlukan untuk mencapai kebutuhan yang sudah didefinisikan.

Perancangan Sistem: pada tahapan ini akan dibuat rancangan software secara lebih terinci sesuai spesifikasi yang sudah disepakati.

Unit Design: merancang setiap elemen/unit software termasuk rancangan modul/program, antarmuka, database dan lain-lain.

Development: merealisasikan hasil rancangan menjadi satu aplikasi/program tertentu.

Tahapan Validasi merupakan serangkaian tahapan yang mengacu kepada kesesuaian software dengan spesifikasi yang sudah ditetapkan. Tahapan ini dicapai melalui serangkaian pengujian/testing sebagai berikut:

Unit test: menguji setiap komponen/unit program apakah sesuai dengan rancangan unit yang sudah ditetapkan. Secara teoritis seharusnya pengujian dilakukan oleh orang tertentu yang bertugas sebagai software tester, tetapi dalam kenyataannya seringkali unit testing dilakukan oleh programmer sendiri.

Interface test: setelah semua komponen diuji secara terpisah, tahapan selanjutnya dilakukan interface test untuk melihat sejauh mana setiap komponen dapat berinteraksi satu sama lain sesuai dengan fungsi yang diharapkan.

System test: setelah semua interface berjalan dengan baik, selanutnya dilakukan system test untuk melihat sejauh mana sistem/software dapat memenuhi kebutuhan secara keseluruhan. System testing bersifat menyeluruh dan tidak dapat dilakukan berdasarkan fungsionalitas sistem yang diuji secara terpisah. Aktivitas pada system testing termasuk melakukan pengujian hal-hal berikut:

Performance – apakah kinerja sistem sesuai dengan target yang sudah didefinisikan sebelumnya.

Volume – apakah software/sistem dapat menampung volume informasi yang cukup besar.

Stress – apakah software/sistem dapat menampung sejumlah informasi pada waktu-waktu tertentu.

Documentation – apakah semua dokumentasi penting sudah disiapkan.

Robustness – apakah software/sistem cenderung stabil pada berbagai kondisi diluar dugaan/ekstrim.

Acceptance test merupakan aktivitas untuk menguji sejauh mana sistem/software dapat membantu memecahkan business case, dalam artian apakah sistem/software tersebut sudah sesuai dengan harapan konsumen/klien dan sejauh mana manfaat sistem/software ini bagi klien. Test ini sering kali disebut sebagai User Acceptance Test (UAT).

Release testing: test ini dilakukan untuk menguji sejauh mana sistem/software dapat mendukung aktivitas organisasi dan berjalan dengan harmonis sesuai dengan kegiatan rutin organisasi. Beberapa pertanyaan coba dijawab pada fase ini misalnya apakah software tersebut mempengaruhi sistem lain? Apakah software tersebut kompatibel dengan sistem lain? Bagaimana kinerja sistem sebenarnya di dalam organisasi?

Dimana saja V Model Diterapkan?

Dalam proyek teknologi informasi di Jerman

V Model dibandingkan dengan CMM

V Model didesain untuk mengembangkan sistem yang didalamnya terdapat dua komponen

Pengembangan V Model dalam bidang industri dapat dilakukan dengan mudah

Kelebihan V Model

V Model sangat fleksibel

V Model dikembangkan dan dirawat oleh publik

Kelebihan V Model dibandingkan dengan Waterfall biasa yaitu, pada setiap fase selalu dilakukan pengujian yang cukup memadai

Kekurangan V Model

Model yang project oriented

Memiliki beberapa activity

Asusmsi yang digunakan adalah requirement bersifat tetap dan tidak berubah

Requirement dan rancangan tidak diverifikasi

Pada setiap fase terdapat peluang error

C. Simple Interaction Design Model Lifecycle

Simple Interaction Design Model Lifecycle Software adalah model yang menggabungkan tiga prinsip pengguna berpusat desain dan empat kegiatan desain interaksi. 

Prinsip User-Centered Design

Prinsip-prinsip ini dikembangkan oleh John D. Gould dan Clayton Lewis. prinsipnya adalah sebagai berikut:

1. Fokus pada pengguna dan tugas

2. Pengukuran empiris

3. Desain Interatif

Dasar kegiatan Desain Interaksi

Preece et al. menggambarkan model dasar untuk proses desain interaksi yang mencakup empat kegiatan seperti yang ditunjukkan di bawah

ini. Sejumlah akademisi dan lembaga desain terkenal telah menciptakan model yang sama. Zimmerman, J., Forlizzi, J., dan Evenson, S., dari

Sekolah Desain di Carnegie Mellon University.

Kegiatannya adalah sebagai berikut:

1. Mengidentifikasi kebutuhan dan persyaratan mendirikan untuk pengalaman pengguna

2. Mengembangkan alternatif desain yang memenuhi persyaratan

3. Membangun versi interaktif dari desain

4. Mengevaluasi apa yang sedang dibangun di seluruh proses dan pengalaman pengguna yang menawarkan

Bentuk dari simple interaction design model lifecycle software adalah sebagai berikut:

Tahapan Simple Interaction Design Model

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

          dengan 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)

D. Star Lifecycle Model

              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.