2. Metodologi RPL

Muslim Heri Kiswanto, S.Kom, MH

2. Metodologi Pengembangan RPL

2 Metodologi Pengembangan PL

STMIK Duta Bangsa Surakarta


Sebagai proses membuat suatu perangkat lunakbaru untuk menggantikan perangkat lunak lama secara keseluruhan atau memperbaiki perangkatlunak yang telah ada.

Agar lebih cepat dan tepat dalammendeskripsikan solusi dan mengembangkanperangkat lunak, juga hasilnya mudahdikembangkan dan dipelihara, makapengembangan perangkat lunak memerlukansuatu metodologi khusus


Proses pengorganisasian kumpulan metode dankonvensi notasi yang telah didefinisikan untukmengembangkan perangkat lunak.

untuk membantu menghasilkan perangkat lunakyang berkualitas.

disebut juga model proses atau paradigmarekayasa perangkat lunak


Menurut Pressman (1997)

PengembanganPL

Procedure Tools Method


1. MetodeCara atau teknik pendekatan yang sistematik yang dipergunakan untuk mengembangkan perangkat lunak. Metode ini mencakup : Perencanaan proyek dan Perkiraan, analisis keperluan sistem dan perangkat lunak, Perancangan struktur data, Arsitektur program, Prosedur algoritma, Coding, Uji coba dan pemeliharaan.


2. Tools

alat-alat yang mendukung pengembangan perangkat lunak. Terdapat 2 alat Bantu yang dapat digunakan yaitu : 1) alat Bantu manual2) alat Bantu otomatis.


3. Prosedur,yang dipergunakan untuk mendefinisikan urut-urutan pekerjaan (daur) dari metode dan alat bantu tersebut.


suatu proses dimana kebutuhan pemakaiditerjemahkan menjadi produk perangkat lunak.

mencakup aktivitas : (IEEE. 1990)1. penerjemahan kebutuhan pemakai menjadi

kebutuhan perangkat lunak, 2. transformasi kebutuhan perangkat lunak

menjadi desain, 3. penerapan desain menjadi kode program, 4. uji coba kode program, 5. dan instalasi serta pemeriksaan kebenaran

perangkat lunak untuk operasional


Periode waktu yang diawali dengan keputusan untukmengembangkan produk perangkat lunak dan berakhirsaat produk tidak dapat ditingkatkan lebih jauh lagi olehpengembang.


Kebutuhan terhadap definisi masalah yang jelas Tahapan-tahapan pengembangan yang teratur Stakeholder berperan sangat penting dalam

keseluruhan tahapan pengembangan Dokumentasi merupakan bagian penting dari

pengembangan perangkat lunak Keluaran dari proses pengembangan perangkat

lunak harus bernilai ekonomis


1. The Waterfall Model (model klasik), 2. Prototype Model3. Rapid Application Development (RAD)4. Unified Process (UP) dan UML, 5. 4GT Model


1. Investigasi Karena perangkat lunak adalah bagian dari sistem

yang lebih besar, pekerjaan dimulai daripembentukan kebutuhan-kebutuhan untuk seluruhelemen sistem dan kemudian memilah mana yang untuk pengembangan perangkat lunak.

Pengumpulan kebutuhan dengan fokus padaperangkat lunak, yang meliputi : Domain informasi, fungsi yang dibutuhkan, unjukkerja/performansi dan antarmuka. Hasilnya harusdidokumentasi dan direview ke pelanggan


2. Perancangan/DesainMengubah kebutuhan-kebutuhan menjadi bentukkarakteristik yang dimengerti perangkat lunaksebelum melakukan coding.Ada 4 atribut untuk program yaitu : Struktur Data, Arsitektur perangkat lunak, Prosedur detil danKarakteristik Antarmuka.

3. CodingPenterjemahan perancangan ke bentuk yang dapatdimengerti oleh mesin, dengan menggunakanbahasa pemrograman


4. Implementasi dan Pengujian/TestingMemfokuskan pada logika internal dari perangkatlunak, fungsi eksternal dan mencari segalakemungkinan kesalahan dan memriksa apakahsesuai dengan hasil yang diinginkan.

5. PemeliharaanBagian akhir dari pengembangan sistem,


ada 3 kegiatan dalam maintenance: Corrective Maintenance : Mengoreksi kesalahan pada

perangkat lunak, yang baru terdeteksi pada saatperangkat lunak dipergunakan

Adaptive Maintenance : Penyesuaian denganlingkungan baru, misalnya sistem operasi atau sebagaituntutan atas perkembangan sistem komputer, misalnyapenambahan printer driver

Perfektive Maintenance : Bila perangkat lunak suksesdipergunakan oleh pemakai. Pemeliharaan ditujukanuntuk menambah kemampuannya seperti memberikanfungsi-fungsi tambahan, peningkatan kinerja dansebagainya.


Kelemahan Model Water Fall:

Proyek yang sebenarnya jarang mengikuti alursekuensial seperti diusulkan.

Mengharuskan semua kebutuhan pemakai sudahdinyatakan secara eksplisit di awal proses.

Pemakai harus bersabar karena versi dari program tidak akan didapat sampai akhir rentang waktuproyek.

Adanya waktu menganggur bagi pengembang, karenaharus menunggu anggota tim proyek lainnyamenuntaskan pekerjaannya.


Salah satu pendekatan dalam rekayasaperangkat lunak yang secara langsungmendemonstrasikan bagaimana sebuahperangkat lunak atau komponen-komponenperangkat lunak akan bekerja dalamlingkungannya sebelum tahapan konstruksiaktual dilakukan (Howard, 1997)


Aktivitas pada model ini: Mendefinisikan objektif secara keseluruhan dan

mengidentifikasi kebutuhan yang sudahdiketahui.

Melakukan perancangan secara cepat sebagaidasar untuk membuat prototype.

Menguji coba dan mengevaluasi prototype dankemudian melakukan penambahan danperbaikan-perbaikan terhadap prototype yang sudah dibuat.


Klasifikasi Prototyping Model (Harris, 2003)

Klasifikasi prototyping model (Harris, 2003) Reusable prototype :

Prototype yang akan ditransformasikan menjadi produk final. Throwaway prototype :

Prototype yang akan dibuang begitu selesai menjalankanmaksudnya.

Input/output prototype :Prototype yang terbatas pada antar muka pengguna (userinterface).

Processing prototype :Prototype yang meliputi perawatan file dasar dan proses-prosestransaksi.

System prototype :Prototype yang berupa model lengkap dari perangkat lunak.


Tahapan pada Prototyping Model

Identifikasi

Alternatif

PrototypeRancang

Bangun

PrototypeUji

Prototype Siapkan

Pengajuan

Prototype Siapkan

Pengajuan

Prototype Siapkan

Pengajuan

Prototype


Untuk siklus pengembangan dengan waktuyang mendesak (singkat).

Jika kebutuhan dipahami model ini mampumenghasilkan sistem yang utuh dalamwaktu yang relatif singkat (60-90 hari)


Cakupan pada model RAD:1. Pemodelan bisnis (Bussiness Modelling)

Aliran informasi diantara fungsi-fungsi bisnis dimodelkandengan suatu cara untuk menjawab pertanyaan-pertanyaan berikut : Informasi apa yang mengendalikanproses bisnis ? Kemana informasi itu pergi? Siapa yang memprosesnya ?

2. Pemodelan data (Data Modelling) Aliran informasi yang didefinisikan sebagai bagian darifase pemodelan bisnis disaring ke dalam serangkaianobjek data yang dibutuhkan untuk menopang bisnistersebut.


3. Pemodelan proses (Process Modelling) Aliran informasi yang didefinisikan dalam fase pemodelandata ditransformasikan untuk mencapai aliran informasiyang perlu bagi implementasi sebuah fungsi bisnis. Gambaran pemrosesan diciptakan untuk menambah, memodifikasi, menghapus atau mendapatkan kembalisebuah objek data.

4. Pembuatan aplikasi (Application generation) Selain menciftakan perangkat lunak dengan menggunakan bahasa pemrograman generasi ketiga yang konvensional, RAD lebih banyak memproses kerja untuk memakai lagikomponen program yang telah ada atau menciptakankomponen yang bisa dipakai lagi. (Alat bantu)


5. Pengujian dan pergantian (Testing and turnover) Karena proses RAD menekankan pada pemakaiankembali, banyak komponen yang telah diuji. Hal inimengurangi keseluruhan waktu pengujian.


Kelemahan Model RAD:1. Membutuhkan SDM yang besar dalam sebuah tim2. Membutuhkan Komitemen pengembang & pemakai

untuk membuat dan melengkapi sistem dalamwaktu singkat

3. Dapat menimbulkan masalah yang komplek jikasistem tidak dibuat dalam bentuk modular

4. Tidak cocok digunakan untuk sistem yang memilikiresiko teknik tinggi


Unified Process (UP) atau kadang disebutsebagai Unified Software Development Process(USDP) adalah kerangka proses pengembanganyang bersifat use-case-driven, berpusat padaarsitektur perangkat lunak, interatif dantumbuh-kembang (Alhir, 2005).

Unified Modelling Language (UML) adalahbahasa pemodelan standar atau kumpulanteknik-teknik pemodelan untuk menspesifikasi,mem-visualisasi, meng-konstruksi danmendokumentasi hasil kerja dalampengembangan perangkat lunak (Fowler, 2004).


RUP Life Cycle (Ambler, 2005)


Inception. Tahapan ini merupakan tahapan paling awal dimana aktivitas penilaian terhadap sebuahproyek perangkat lunak dilakukan.

Elaboration. Tujuan dari tahap ini adalah untukmendapatkan gambaran umum kebutuhan, persyaratan dan fungsi-fungsi utama perangkatlunak.

Construction. Tujuan dari tahapan ini adalahmembangun perangkat lunak sampai dengan saatperangkat lunak tersebut siap digunakan.

Transition. Tahap ini difokuskan pada bagaimanamenyampaikan perangkat lunak yang sudah jadi pada pengguna


Use-case diagram. Diagram ini berguna untuk menggambarkaninteraksi antara pengguna dengan sebuah perangkat lunak

Activity diagram. Diagram ini berguna untuk menggambarkanprosedurprosedur perilaku perangkat lunak.

Class diagram. Diagram ini berguna untuk menggambarkan class, fitur,dan hubungan-hubungan yang terjadi. Pada diagram ini pendekatanberorientasi obyek memegang peranan yang sangat penting.

Sequence diagram. Diagram ini berguna untuk menggambarkaninteraksi antar obyek dengan penekanan pada urutan proses ataukejadian.

State machine diagram. Diagram ini digunakan untuk menggambarkanbagaimana suatu kejadian mengubah obyek selama masa hidup obyektersebut.

Component diagram. Diagram ini berguna untuk menggambarkanstruktur dan koneksi komponen.


Mengarah ke perangkat lunak yang umum yaitu tiappengembang perangkat lunak menentukan beberapakarakteristik perangkat lunak pada level tinggi.

Pengembangan PL 4GT terdapat tools:a) Bahasa non prosedural untuk query basis datab) Report generationc) Data manipulationd) Interaksi layare) Kemampuan grafik level tinggif) Kemampuan spreadsheet


Kegiatan pada 4GT Model:a) Pengumpulan kebutuhan, idealnya pelanggan

akan menjelaskan kebutuhan yang akan ditranslasikan ke prototype operasional.

b) Translasi kebutuhan menjadi prototype operasional, atau langsung melakukanimplementasi secara langsung denganmenggunakan bahasa generasi keempat (4GL) jika aplikasi relatif kecil.


c) Untuk aplikasi yang cukup besar, dibutuhkanstrategi perancangan sistem walaupun 4GL akan digunakan.

d) Pengujian. e) Membuat dokumentasi. Melaksanakan seluruh

aktivitas untuk mengintegrasikan solusi-solusiyang membutuhkan paradigma rekayasaperangkat lunak lainnya.



See U Next Week

2. Metodologi RPL

Documents

Transcript of 2. Metodologi RPL