Metode rpl BY: Y. PALOPAK S.Si., MT..

Presentasi berjudul: "Metode rpl BY: Y. PALOPAK S.Si., MT.."— Transcript presentasi:

1 Metode rpl BY: Y. PALOPAK S.Si., MT.

2 Dalam rekayasa perangkat lunak, diperlukan tahapan- tahapan kerja yang harus dilalui.
Rekayasa perangkat lunak yang sukses tidak hanya membutuhkan kemampuan komputasi seperti algoritma, pemrograman, dan basis data yang kuat. Namun juga perlu penentuan tujuan yang baik, identifikasi cara penyelesaian, metode pengembangan, urutan aktifitas, identifikasi kebutuhan sumberdaya, dan faktor-faktor lain. Ada banyak model yang dikemukakan untuk menyelesaikan proyek RPL

3 Karakteristik Model Kebutuhan terhadap definisi masalah yang jelas. Semakin jelas akan semakin baik karena akan memudahkan dalam penyelesaian masalah Tahapan-tahapan pengembangan yang teratur. Meskipun model-model pengembangan perangkat lunak memiliki pola yang berbeda-beda, biasanya model-model tersebut mengikuti pola umum: Perencanaan – Analisis – design – Implementasi

4 Karakteristik Model Stakeholder berperan sangat penting dalam keseluruhan tahapan pengembangan. Stakeholder dalam rekayasa perangkat lunak dapat berupa pengguna, pemilik, pengembang, pemrogram dan orang-orang yang terlibat dalam rekayasa perangkat lunak tersebut. Dokumentasi merupakan bagian penting dari pengembangan perangkat lunak. Masing-masing tahapan dalam model biasanya menghasilkan sejumlah tulisan, diagram, gambar atau bentuk-bentuk lain yang harus didokumentasi. Keluaran dari proses pengembangan perangkat lunak harus bernilai ekonomis. Efek dari penggunaan perangkat lunak yang telah dikembangkan haruslah memberi nilai tambah bagi organisasi.

5 System Development Life Cycle (SDLC)
Merupakan proses pengembangan atau mengubah suatu sistem perangkat lunak dengan menggunakan model-model dan metodologi yang ada.

6 System Development Life Cycle (SDLC)

7 System Development Life Cycle (SDLC)
SDLC pada umumnya terdiri atas empat Fase utama: Planning Analysis Design Implementation

8 Fase I: Planning Fase ini merupakan proses fundamental sehubungan dengan mengapa sistem harus dibangun Fase Planning juga akan menentukan bagaimana team akan bekerja membangun sistem tersebut Fase Planning terdiri atas dua tahapan utama: Tahapan selama Inisialisasi project, mengidentifikasi nilai bisnis sistem tersebut bagi organisasi. (Bagaimana supaya biaya murah dan meningkatkan keuntungan). Tahapan selama Manjemen Project, Manager proyek membuat rencana kerja, team proyek, mengatur jalannya proyek

9 Fase II: Analysis Analisis sistem adalah sebuah teknik pemecahan masalah yang menguraikan sebuah sistem menjadi komponen-komponennya dengan tujuan mempelajari seberapa bagus komponen-komponen tersebut bekerja dan berinteraksi untuk meraih tujuan. Fase analisis mengenai, siapa yang akan menggunakan sistem, apa yang sistem dapat lakukan, dimana dan kapan sistem dapat digunakan. Selama fase ini, team proyek melakukan investigasi sistem-sistem yang sudah ada, identifikasi kemungkinan pengembangan, dan mengembangkan konsep untuk sistem yang baru. Analisis mungkin adalah bagian terpenting dari proses rekayasa perangkat lunak. Karena semua proses lanjutan akan sangat bergantung pada baik tidaknya hasil analisis

10 Fase II: Analysis Fase ini memiliki tiga langkah analisis:
Analysis strategy: Dikembangkan untuk menuntun usaha team, termasuk analisis sistem existing. Requirements gathering: Analisa informasi menuntun pada pengembangan konsep untuk sistem baru, dan digunakan untuk membangun model analisis. System proposal: System proposal sebagai gambaran awal akan kebutuhan-kebutuhan sistem baru. Proposal juga untuk kelangsungan pembiayaan proyek, baik bagi donatur maupun bagi individu-individu yang menentukan kelangsungan proyek.

11 Bagian-bagian Analisis
Analisis Masalah Analisis Kelemahan Analisis Kebutuhan Pengembangan Sistem Analisis Kelayakan

12

13 Fase III: Design Desain perangkat lunak adalah tugas, tahapan atau aktivitas yang difokuskan pada spesifikasi detil dari solusi berbasis computer (Whitten et al, 2004). Desain perangkat lunak sering juga disebut sebagai physical design. Jika tahapan analisis sistem menekankan pada masalah bisnis (business rule), maka sebaiknya desain perangkat lunak fokus pada sisi teknis dan implementasi sebuah perangkat lunak (Whitten et al, 2004).

14 Fase III: Design Output utama dari tahapan desain perangkat lunak adalah spesifikasi desain. Spesifikasi ini meliputi spesifikasi disain umum yang akan disampaikan kepada stakeholder sistem dan spesifikasi disain rinci yang akan digunakan pada tahap implementasi. Spesifikasi desain umum hanya berisi gambaran umum agar stakeholder sistem mengerti akan seperti apa perangkat lunak yang akan dibangun.

15 Fase III: Design Desain arsitektur rinci perangkat lunak diperlukan untuk merancang sistem sehingga memiliki konstruksi yang baik, proses pengolahan data yang tepat dan akurat, bernilai, memiliki aspek user friendly dan memiliki dasar- dasar untuk pengembangan selanjutnya. Desain arsitektur ini terdiri dari desain database, desain proses, desain user interface yang mencakup desain input, output form dan report, desain hardware, software dan jaringan.

16 Fase Design Fase ini terdiri atas beberapa tahap:
Design Strategy: Menjelaskan apakah sistem akan dikembangkan sendiri di perusahaan atau diluar perusahaan. Architecture Design: Menjelaskan hardware, software, dan infrastruktur jaringan yang akan digunakan. Database and File Specifications: Mendefinisikan data apa dan dimana data akan disimpan. Program Design: Mendefinisikan program apa yang akan ditulis dan apa yang dapat dikerjakan oleh program tersebut.

17 Fase IV: Implementation
Selama fase ini, sistem diimplementasikan atau dijual kepada pembeli ( paket software) Merupakan fase terpanjang dan termahal dari proses yang ada Terdiri dari tiga tahap: System Construction: Proses pembangunan dan pengujian sistem untuk meastikan hasil sesuai design. Installation: Persiapan dan proses instalasi system. Support Plan: Termasuk review pasca implementasi.

18 The waterfall model Merupakan model SDLC yang paling sederhana.
Merupakan dasar dari model-model yang lain Hal terbaik dari model ini adalah struktur tahap pengembangan sistem jelas, dokumentasi dihasilkan disetiap tahap pengembangan dan sebuah tahap dijalankan setelah tahap sebelumnya selesai (tidak ada tumpang tindih)

19 The waterfall model

20 The waterfall model Dari kenyataannya, sangan jarang model ini dapat dilakukan sesuai tahapan, sebab: Perubahan spesifikasi perangkat lunak terjadi ditengah-alur pengembangan Sangat sulit bagi pelanggan untuk mendefinisikan semua spesifikasi di awal alur pengembangan. Pelanggan tidak sabar mengakomodasi perubahan yang diperlukan di akhir alur pengembangan.

21 Prototyping model Prototyping adalah salah satu pendekatan dalam rekayasa perangkat lunak yang secara langsung mendemonstrasikan bagaimana sebuah perangkat lunak atau komponen perangkat lunak akan bekerja dalam lingkungannya sebelum tahapan konstruksi aktual dilakukan Dapat dilakukan untuk menyambung ketidakpahaman pelanggan dan memperjelas spec kebutuhan Prototipe akan dievaluasi bersama oleh team pengembang dan user/pelanggan Prototipe / mock-up harus mampu mendemonstrasikan sebagian besar fungsi sistem sebenarnya serta memungkinkan pengujian desain sistem. Model ini cocok digunakan untuk menggali spesifikasi kebutuhan pelanggan secara detail, namun beresiko terhadap biaya dan waktu

22 Prototyping model

23 Prototyping model Beberapa kelemahan
Pelanggan dapat sering mengubah-ubah atau menambah spesifikasi, hal ini dapat memperlambat proses pengembangan Pengembang lebih sering kompromi untuk mendapatkan prototipe dengan waktu yang cepat sehingga kualitas kurang baik, bahkan bisar menyebabkan iteratif tanpa akhir.

24 RAD Model (Rapid Application Development)
Merupakan model proses pengembangan perangkat lunak yang bersifat inkremental terutama untuk waktu pengerjaan yang pendek. Merupakan adaptasi dari model waterfall versi kecepatan tinggi Model RAD membagi team menjadi beberapa team untuk mengerjakan beberapa tahapan secara paralel

25 RAD Model (Rapid Application Development)

26 RAD Model (Rapid Application Development)
Kelemahan: Untuk sistem skala besar, model RAD memerlukan SDM yang cukup besar Jika tidak ada kemampuan untuk mengembangkan perangkat lunak secara cepat, maka model ini akan membingungkan. Tidak cocok digunakan untuk sistem perangkat lunak yang memiliki resiko teknis yang sangat tinggi, misalnya menggunakan teknologi baru

27 RAD Model (Rapid Application Development)
Model RAD cocok diterapkan apabila memenuhi kriteria: Anggota team sudah berpengalaman mengembangkan perangkat lunak yang sejenis Pengembang sudah memiliki komponen-komponen sistem yang disa digunakan kembali dalam proyek tersebut.

28 Incremental Model Model Incremental mengkombinasikan proses- proses pada model waterfall dan iterasi pada model prototipe Model ini dibuat untuk mengatasi kelemahan dari model waterfall yang tidak mengakomodasi iterasi serta mengatasi kelemahan dari model prototipe yang memiliki proses terlalu pendek dimana setiap proses iterasinya tidak selalu menghasilkan prototipe.

29 Incremental Model

30 Spiral Model Model spiral diusulkan oleh Barry Boehm (Boehm, 1988) berbentuk spiral yang memasangkan iteratif pada model prototipe dengan kontrol dan aspek sistematik yang diambil dari model waterfall. Model ini bertujuan untuk mengurangi resiko pada setiap tahapan yang dilalui. Selama awal iterasi, rilis indreental bisa merupakan sebuah model/prototype, iterasi selanjutnya sedikit- demi sedikit dihasilkan versi rekayasa yang lebih lengkap. Terdiri dari empat bagian

31 Spiral Model Terdiri dari empat bagian:
Determine Ojectives (kuadran I): sebagai awal proses, menentukan permasalahan, menentukan alternatif dan objek-objek yang penting Risk Analysis (kuadaran II): analisis resiko, evaluasi dan mencari solusi Engineering/Develop (kuadran III): Proses pemilihan model pengembangan Plan next pahse: Penentuan rencana-rencana untuk tahapan selanjutnya.

32 Spiral Model

33 Tugas Artikel: Prototype software