METODE PENGEMBANGAN PERANGKAT LUNAK. docx

Nama Kelompok:

NADIA ARIFI ANANDA

AVIANTO NUGROHO

ADITYA WISNU G.

G.211.12.0137

G.211.12.0139

G.211.12.0147

METODE PENGEMBANGAN PERANGKAT LUNAK

1. MODEL LINEAR SEQUENTIAL/WATERFALL

Kelebihan model Linear Sequential/Waterfall :

 Mudah diaplikasikan

 Memberikan template tentang metode analisis, desain, pengkodean, pengujian, dan pemeliharaan

 Cocok digunakan untuk produk software yang sudah jelas kebutuhannya di awal, sehingga minim kesalahannya

Kekurangan model Linear Sequential/Waterfall :

 Terjadinya pembagian proyek menjadi tahap-tahap yang tidak fleksibel, karena komitmen harus dilakukan pada tahap awal proses

 Sulit untuk mengalami perubahan kebutuhan yang diinginkan customer

 Customer harus sabar untuk menanti produk selesai, karena dikerjakan tahap per tahap,menyelesaikan tahap awal baru bisa ke tahap selanjutnya

 Perubahan ditengah-tengah pengerjaan produk akan membuat bingung team work yang sedang membuat produk

 Adanya waktu menganggur bagi pengembang, karena harus menunggu anggota tim proyek lainnya menuntaskan pekerjaannya

2. MODEL PROSES PERANGKAT LUNAK EVOLUSIONER

Model evolusioner adalah model iterative, ditandai dengan tingkah laku yang

memungkinkan perekayasa perangkat lunak mengembangkan versi perangkat lunak yang lebih lengkap sedikit demi sedikit. Kebutuhan produk dan bisnis kadang-kadang berubah seiring dengan laju perkembanganya.

Dalam situasi tersebut maupun lainya, perekayasa perangkat lunak membutuhkan sebuah model proses yang sudah dirancang secara eksplisit untuk mengakomodasi produk perkembangan sepanjang waktu. Model ini bukan termasuk rekayasa perangkat lunak klasik. Model evolusioner meliputi model increment, spiral, perkembangan konkruen dan rakitan komponen.

3. MODEL INCREMENT

Model incremental menggabungkan elemen-elemen model sekuensial linier (diaplikasikan secara berulang) dengan filosofi prototype iterative. Model ini memakai urutan-urutan linier di dalam model yang membingungkan, seiring dengan laju waktu kalender. Setiap urutan linier menghasilkan pertambahan, perangkat lunak “yang bisa disampaikan.” Contoh, perangkat lunak pengolah kata yang dikembangkan dengan menggunakan paradigm pertambahan akan menyampaikan manajemen file, editing, serta fungsi penghasilan dokumen pada pertambahan pertama, dan selanjutnya. Pertambahan pertama dapat disebut sebagai produk inti (core product).

Model ini berfokus pada penyampaian produk operasional dalam Setiap

memberikan kemampuan untuk melayani pemakai dan juga menyediakan platform untuk evaluasi oleh pemakai.

Perkembangan pertambahan, khususnya berguna pada staffing, tidak bisa dilakukan menggunakan implementasi lengkap oleh batas waktu bisnisyang sudah disepakati untuk proyek tersebut. jika produk inti diterima dengan baik, maka staf tambahan bisa

ditambahkan untuk mengimplementasi pertambahan selanjutnya.

4. MODEL SPIRAL

Awalnya diusulkan oleh Boehm (BOE88), adalah model proses perangkat lunak yang evolusioner, merangkai sifat iterative dari prototype dengan cara control dan aspek sistematis dari model sekuensial linier. Model yang berpotensi untuk pengembangan versi pertambahan perangkat lunak secara cepat. Model spiral dibagi menjadi sejumlah

aktifitas kerangka kerja atau wilayah tugas, antara lain :

 Komunikasi pelanggan, tugas-tugas yang dibutuhkan untuk membangun komunikasi yang efektif diantara pengembang dan pelanggan.

 Perencanaan, tugas-tugas yang dibutuhkan untuk mendefinisikan sumber-sumber daya, ketepatan waktu, dan proyek informasi lain yang berhubungan.

 Analisis resiko, tugas-tugas yang dibutuhkan untuk menaksir resiko-resiko, baik manajemen maupun teknis.

 Perekayasaan, tugas-tugas yang dibutuhkan untuk membangun satu atau lebih representasi dari aplikasi tersebut.

 Konstruksi dan peluncuran, tugas-tugas yang dibutuhkan untuk mengkonstruksi, menguji, memasang (instal), dan memberikan pelayanan kepada pemakai (contohnya pelatihan dan dokumentasi)

Model spiral menjadi pendekatan yang realistis bagi perkembangan system dan perangkat lunak skala besar. Karena perangkat lunak terus bekerja selama proses bergerak,

pengembang dan pemakai memahami, dan bereaksi lebih baik terhadap resiko dari Setiap tingkat evolusi. Model spiral menggunakan prototype sebagai mekanisme pengurangan resiko.

Model spiral membutuhkan keahlian penafsiran resiko yang masuk akal, dan sangat bertumpu pada keahlian ini untuk mencapai keberhasilan. Jika sebuah resiko tidak dapat ditemukan dan diatur, pasti akan terjadi masalah. Model ini membutuhkan waktu

bertahun-tahun sampai kehandalannya bisa dipertimbangkan dengan kepastian absolute.

5. COMPONENT ASSEMBLY MODEL (Model Perakitan Komponen)

Model ini merupakan gabungan dari berbagai sifat dan karakter dari model spiral Boehm dan sangat erat keterikatannya dengan model RAD (Rapid Application

Tahapan-tahapan Model ini adalah:

Tahap Identifikasi calon-calon komponen (kelas objek); Tahap melihat komponen-komponen dalam pustaka; Tahap mengekstrak komponen-komponen jika ada; Tahap membangun komponen jika tidak ada; Tahap menyimpan komponen baru pada pustaka; Tahap mengkonstruksi iterasi ke-n dari sistem.

Kelebihan model ini adalah tinggal mencaplok atau menggunakan program atau komponen yang sudah ada dan menyusunnya menjadi sebuah program yang lebih kompleks dan berkembang sesuai dengan kebutuhan user/pengguna sehingga dapat mengefisienkan penggunaan waktu dan tenaga. Selain itu, model ini juga menyediakan kemampuan untuk memvisualisasikan hasil rakitan dengan kesanggupan untuk

mengukur, menganalisa, merancang dan merancang ulang program.

Kekurangan model ini adalah seringnya program atau komponen-komponen terdahulu tidak kompatibel atau sejalan dengan model perakitan komponen ini sehingga untuk perusahaan berskala kecil akan kesulitan menemukan komponen yang sesuai untuk dirakit.

Model ini sangat sesuai digunakan oleh perusahaan besar yang sudah berpengalaman mengembangkan software. Mereka dapat memanfaatkan software-software yang telah umum dikembangkan sebelumnya menjadi bentuk baru dari software yang ingin dikomersilkan.

6. THE CONCURRENT DEVELOPMENT MODEL

Model ini disebut juga dengan concurrent engineering yang dapat digambarkan secara skematik sebagai serial dari kegiatan teknis utama, tugas-tugas, dan hubungan antar bagian-bagian yang saling terkait di mana aktifitas analisa seperti desain/rancangan atau komunikasi pelanggan dapat diskemakan dengan cara yang sama.

Concurrent process model cocok digunakan untuk pengembangan aplikasi client/server yang terdiri atas satu set komponen yang fungsional. Terdapat dua dimensi aktivitas yang digambarkan oleh model ini sebagai berikut.

Dimensi sistem: terdapat tiga proses di dalamnya yakni perancangan, perakitan (assembly) dan penggunaan (use).

Concurrency (pertemuan) dapat diperoleh dengan dua cara: 1) sistem dan komponen kegiatan (aktifitas) terjadi secara simultan dan dapat diperagakan dengan memanfaatkan pendekatan yang berdasar pada status sebelumnya; 2) aplikasi client/server yang bersifat unik/khas di mana dapat diterapkan pada banyak komponen yang tiap-tiap komponen bisa dirancang dan direalisasikan secara serentak.

7. MODEL PROTOTYPE

Prototyping adalah salah satu pendekatan dalam rekayasa perangkat lunak yang secara langsung mendemonstrasikan bagaimana sebuah perangkat lunak atau komponen- komponen perangkat lunak akan bekerja dalam lingkungannya sebelum tahapan konstruksi aktual dilakukan (Howard, 1997).

Beberapa model prototype adalah sebagai berikut :

 Throwaway prototype : Prototype yang akan dibuang begitu selesai menjalankan maksudnya.

 Input/output prototype : Prototype yang terbatas pada antar muka pengguna (user interface).

 Processing prototype : Prototype yang meliputi perawatan file dasar dan proses-proses transaksi

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

Proses pada model prototyping adalah sebagai berikut:

1. pengumpulan kebutuhan

developer dan klien bertemu dan menentukan tujuan umum, kebutuhan yang diketahui dan gambaran bagian-bagian yang akan dibutuhkan berikutnya. Detil kebutuhan mungkin tidak dibicarakan disini, pada awal pengumpulan kebutuhan

2. perancangan

perancangan dilakukan cepat dan rancangan mewakili semua aspek software yang diketahui, dan rancangan ini menjadi dasar pembuatan prototype.

3. Evaluasi prototype

klien mengevaluasi prototype yang dibuat dan digunakan untuk memperjelas kebutuhan software.

Perulangan ketiga proses ini terus berlangsung hingga semua kebutuhan terpenuhi. Prototype-prototype dibuat untuk memuaskan kebutuhan klien dan untuk memahami kebutuhan klien lebih baik. Prototype yang dibuat dapat dimanfaatkan kembali untuk membangun software lebih cepat, namun tidak semua prototype bisa dimanfaatkan.

Konsep SDLC – Prototype

Pendekatan prototyping memiliki beberapa keuntungan yaitu:

 Pemodelan membutuhkan partisipasi aktif dari end-user. Hal ini akan

meningkatkan sikap dan dukungan pengguna untuk pengerjaan proyek. Sikap moral pengguna akan meningkat karena system berhubungan nyata dengan mereka.

 Perubahan dan iterasi merupakan konsekuensi alami dari pengembangan system-sehingga end user memiliki keinginan untuk merubah pola pikirnya. Prototyping lebih baik menempatkan situasi alamiah ini karena mengasumsikan perubahan model melalui iterasi kedalam system yang dibutuhkan.

 Prototyping adalah model aktif, tidak pasif, sehingga end user dapat melihat, merasakan, dan mengalaminya.

 Kesalahan yang terjadi dalam prototyping dapat dideteksi lebih dini

 Prototyping dapat meningkatkan kreatifitas karena membolehkan adanya feedback dari end user. Hal ini akan memberikan solusi yang lebih baik.

 Prototyping mempercepat beberapa fase hidup dari programmer.

Pendekatan prototyping memiliki beberapa kekurangan yaitu:

 Prototyping tidak menolak kebutuhan dari fase analisis sistem. Prototype hanya dapat memecahkan masalah yang salah dan memberi kesempatan sebagai sistem pengembangan konvensional.

 Prototyping dapat mengurangi kreatifitas perancangan.

8. MODEL RAD (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)

Kelemahan model RAD :

 Untuk proyek dengan skala besar, RAD membutuhkan sumber daya manusia yang cukup untuk membentuk sejumlah tim RAD yang baik.

 RAD membutuhkan pengembang dan pemakai yang mempunyai komitmen dalam aktivitas rapid-fire untuk melaksanakan aktivitas melengkapi sistem dalam kerangka waktu yang singkat. Jika komitmen tersebut tidak ada, proyek RAD gagal.

 Tidak semua aplikasi sesuai untuk RAD.bila system tidak dapat dimodulkan dengan teratur, pembangunan komponen penting pada RAD akan menjadi sangat problematic. RAD menjadi tidak sesuai jika risiko teknisnya tinggi.

9. FOURTH GENERATION TECHNIQUES (4GT)

level tinggi. Saat ini pengembangan perangkat lunak yang mendukung 4GT, berisi tool-tool berikut :

i) Bahasa non prosedural untuk query basis data; ii) Report generation;

iii)Data manipulation ; iv) Interaksi layar ;

v) Kemampuan grafik level tinggi ; vi) Kemampuan spreadsheet .

Tiap tool ini ada tapi hanya untuk sauatu aplikasi khusus.

Menggunakan perangkat bantu (tools) yang akan membuat kode sumber secara otomatis berdasarkan spesifikasi dari pengembang perangkat lunak. Hanya digunakan untuk menggunakan perangkat lunak yang menggunakan bahasa khusus atau notasi grafik yang diselesaikan dengan syarat yang dimengerti pemakai.

Cakupan aktivitas 4GT :

1. Pengumpulan kebutuhan, idealnya pelanggan akan menjelaskan kebutuhan yang akan ditranslasikan ke prototype operasional.

2. Translasi kebutuhan menjadi prototype operasional, atau langsung melakukan implementasi secara langsung dengan menggunakan bahasa generasi keempat (4GL) jika aplikasi relatif kecil.

3. Untuk aplikasi yang cukup besar, dibutuhkan strategi perancangan sistem walaupun 4GL akan digunakan.

4. Pengujian.

5. Membuat dokumentasi

6. Melaksanakan seluruh aktivitas untuk mengintegrasikan solusi-solusi yang membutuhkan paradigma rekayasa perangkat lunak lainnya.

Salah satu keuntungan penggunaan model 4GT adalah pengurangan waktu dan peningkatan produktivitas secara besar, sementara kekurangannya terletak pada kesulitan penggunaan perangkat bantu (tools) dibandingkan dengan bahsa pemrograman, dan juga kode sumber yang dihasilkannya tidak efisien.

Untuk aplikasi yang yang kecil, adalah mungkin untuk langsung berpindah dari pengumpulan kebutuhan ke implementasi dengan menggunakan 4GL. Tapi untuk aplikasi yang besar, dibutuhkan pengembangan strategi desain untuk sistem, walau digunakan 4GL. Penggunaan 4GT tanpa perencanaan yang matang (untuk proyek skala besar) akan meyebabkan kesulitan yang sama (kualitas dan pemeliharaan yang jelek, ketidakpuasan pelanggan) seperti dengan metode konvensional.

10. BERORIENTASI DATA

1. Mengidentifikasi entitas-entitas atau item-item yang menjadi objek informasi kunci berikut operasi-operasinya.

2. struktur informasi (dari dokumen) secara hirarki dengan menggunakan konstruksi sequence , selection dan repetition

3. Memetakan hirarki struktur informasi menjadi struktur program.

Beberapa teknik pengembangan perangkat lunak berorientasi struktur data inidiantaranya adalah:

 Data Structured System Development (DSSD)

Diperkenalkan pertama kali oleh J.D. Warnier (1974) dan kemudianoleh Ken Orr (1977) sehingga sering disebut juga teknik Warnier-Orr.Teknik ini menggunakan perangkat entity diagram,assembly line diagram danWarnier-Orr diagram untuk memodelkan hasil analisisdan perancangannya.

 Jackson System Development (JSD)

Dikembangkan oleh M.A. Jackson (1975) dengan menggunakan perangkat pemodelan yang disebut structure diagram dan system specification diagram

11. BERORIENTASI OBJEK

Berbeda dengan pendekatan-pendekatan sebelumnya, metode berorientasi objek memandang perangkat lunak yang akan dikembangkan sebagai suatu kumpulan objek yang berkorespondensi dengan objek-objek dunia nyata. Padametode ini, informasi dan proses yang dipunyai oleh suatu objek-objek

“dienkapsulasi” (dibungkus) dalam satu kesatuan. Gambar 2.9 berikut menunjukkan cara pandang metode berorientasi objek dibandingkan dengan metode berorientasi fungsi.

 Object Oriented Analysis (OOA) dan Object Oriented Design (OOD)dari Peter Coad dan Edward Yourdon (1990).

 Object Modeling Technique (OMT) dari James Rumbaugh, MichaelBlaha, William Premerlan, Frederick Eddy dan William Lorensen(1991).

 Object Oriented Software Engineering (OOSE) dari Ivar Jacobson(1992).

 Metode Booch dari Grady Booch (1994).

 Syntropy dari Steve Cook dan John Daniels (1994).

12. EXTREME PROGRAMMING (XP) Model

Penerapan XP

Beberapa hal yang harus dipertimbangkan sebelum seseorang masuk dalam dunia XP adalah sebagai berikut:

1. User harus memahami konteks bisnis yang akan dikembangkan sistemnya, sehingga developer dapat menangkap sistem secara aplikatif dan dapat mengusulkan teknologi apa yang dapat dikembangkan dalam sistem barunya.

2. Akan lebih efektif apabila developer pernah menangani proyek pengembangan sistem yang sejenis sehingga dapat memberikan usulan model sistem baru, di samping alasan bahwa developer telah memiliki template aplikasi sistem tersebut untuk dijadikan prototype sistem baru. Hal ini akan berimplikasi kepada kemudahan dalam konstruksi sistem karena dikembangkan berdasarkan template yang sudah ada.

3. Extreme programming menuntut komunikasi antar developer dan user secara intensif dan komunikasi internal antar developer secara komprehensif, sehingga akan lebih representatif apabila tahap pengembangan sistem dilakukan di lokal yang mendukung proses komunikasi tersebut

4. XP adalah suatu bentuk pembangunan perangkat lunak yang berbasis nilai

5. Testing (unit testing & TDD)

 Meningkatkan komunikasi dan sifat saling menghargai antar developer.

Kerugian XP:

 Developer harus selalu siap dengan perubahan karena perubahan akan selalu diterima.

 Tidak bisa membuat kode yang detail di awal (prinsip simplicity dan juga anjuran untuk melakukan apa yang diperlukan hari itu juga).

13. MODEL FORMAL

Model metode formal mencangkup sekumpulan aktivitas yang membawa kepada spesifikasi matematis perangkat lunak computer. Metode ini memungkinkan perekayasa perangkat lunak untuk mengkhususkan, mengembangkan, dan memverifikasi system berbasis computer dengan menggunakan notasi matematis yang tepat.variasi dalam pendekatan ini, disebut clean-room rekayasa perangkat lunak, sedang diaplikasikan oleh banyak organisasi pengembang perangkat lunak.

Bila metode formal dipakai selama masa pengembangan, maka akan memberikan mekanisme untuk mengeliminasi banyak masalah yang sulit dipecahkan menggunakan paradigm perangkat lunak yang lain. Ambiguitas, ketidaklengkapan, dan ketidak-konsitenan bisa ditemukan dan diperbaiki secara mudah, tidak melalui kajian ad hoc tetapi melalui aplikasi analisis matematis. Jika metode ini dipakai selama proses perancangan, maka berfungsi sebagai dasar bagi verifikasi program sehingga memungkinkan perekayasa untuk menemukan dan memperbaiki kesalahan yang mungkin saja tidak terdeteksi.

Metode formal akan banyak memperoleh penganut diantara pengembang perangkat lunak yang harus membangun perangkat lunak yang kritis untuk keselamatan (missal :

pengembangan perangkat medis, dan penerbangan pesawat), serta diantara yang harus menderita karena faktor ekonomis yang harus dialami oleh perangkat lunak.

14. RATIONAL UNIFIED PROCESS

RUP adalah proses pengembangan perangkat lunak berbasis UML (Unified Modeling Language) yang mempunyai karakteristik:

1. Berulang (iterative)

Tahap pengembangan untuk setiap produk yang diserahkan (release) dilaksanakan secara berulang.

2. Architecture centric

Menggunakan arsitektur sistem sebagai artifak utama untuk

konseptualisasi, konstruksi, pengelolaan, dan penyusunan system selama pengembangan.

Menggunakan use case sebagai artifak utama untuk menetapkan perilaku sistem yang diinginkan dan untuk mengkomunikasikan perilaku sistem tersebut kepada para stakeholder sistem.

4. Risk-driven

Menghilangkan atau mengurangi resiko-resiko yang dapat menghambat kesuksesan proyek.

Sasaran RUP adalah menghasilkan perangkat lunak yang berkualitas tinggi,sesuai kebutuhan pemakai, dengan jadwal dan biaya sesuai dengan yang direncanakan

Gambar 2.8 Model Proses Pengembangan dengan RUP(Sumber:www.rational.com)

Proses pengembangan pada RUP dinyatakan dalam dua dimensi, atau dua sumbu (lihat Gambar 2.8).

 sumbu vertikal (sumbu y) merepresentasikan aspek statis dari proses,yaitu aktivitas, artifak, pelaksana kerja (worker) dan aliran kerja(workflow).

Tahap RUP

Berdasarkan Gambar 2.8, tahap (phases) pelaksanaan pengembangan pada RUP meliputi: 1. Permulaan (inception)

Tahap inception fokus pada penentuan manfaat perangkat lunak yang harus dihasilkan, penetapan proses-proses bisnis (business case), dan perencanaan proyek.

2. Pemerincian (elaboration)

Tahap untuk menentukan use case(set of activities) dari perangkat lunak berikut rancangan arsitekturnya.

3. Konstruksi (construction)

Membangun produk perangkat lunak secara lengkap yang siap diserahkan kepada pemakai. 4. Transisi (transition)

Menyerahkan perangkat lunak kepada pemakai, mengujinya ditempat pemakai, dan memperbaiki masalah-masalah yang muncul saat dan setelah pengujian.

Ada dua jenis aliran kerja (workflow) pada RUP, yaitu aliran kerja utama dan aliran kerja pendukung.

Aliran Kerja Utama

1. Pemodelan bisnis (business modeling)

Mendeskripsikan struktur dan proses-proses bisnis organisasi.

2. Kebutuhan (requirements)

Mendefinisikan kebutuhan perangkat lunak dengan menggunakan metode use case.

3. Analisis dan perancangan (analysis and design)

Mendeskripsikan berbagai arsitektur perangkat lunak dari berbagai sudut pandang.

4. Implementasi (implementation)

Menulis kode-kode program, menguji, dan mengintegrasikan unit-unit programnya.

5. Pengujian (testing)

6. Deployment

Menangani konfigurasi sistem yang akan diserahkan.

Aliran Kerja Pendukung

1. Manajemen konfigurasi dan perubahan (configuration and change management) Mengendalikan perubahan dan memelihara artifak-artifak proyek.

2. Manajemen proyek ( project management)

Mendeskripsikan berbagai strategi pekerjaan dengan proses yang berulang.

3. Lingkungan (environment)

Sumber:

https://www.academia.edu/3695277/02-Rekayasa-Perangkat-Lunak-Material

http://rahmasholehah.blogspot.com/2013/03/model-pengembangan-perangkat-lunak.html

http://lsoumeru.mhs.uksw.edu/2012/11/metode-pengembangansistemsoftware1.html

http://resaseptiari05130.wordpress.com/2011/09/16/metode-perangkat-lunak/