Top Banner
MITOS – MITOS DAN METODELOGI PERANGKAT LUNAK MATA KULIAH : REKAYASA PERANGKAT LUNAK DOSEN : FITRI QUROTUL UYUN, ST DI SUSUN OLEH : ERLYTA 4211422 NURHAYATI 4211402 PROGRAM STUDI SISTEM INFORMASI KONSENTRASI KOMPUTER AKUNTANSI SEKOLAH TINGGI TEKNOLOGI INDONESIA TANJUNG PINANG
13

RPL

Jul 02, 2015

Download

Documents

Er Erlyta
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Page 1: RPL

MITOS – MITOS DAN METODELOGI PERANGKAT

LUNAK

MATA KULIAH : REKAYASA PERANGKAT LUNAK

DOSEN : FITRI QUROTUL UYUN, ST

DI SUSUN OLEH :

ERLYTA 4211422NURHAYATI 4211402

PROGRAM STUDI SISTEM INFORMASIKONSENTRASI KOMPUTER AKUNTANSI

SEKOLAH TINGGI TEKNOLOGI INDONESIATANJUNG PINANG

Page 2: RPL

2012

KATA PENGANTAR

Puji syukur kami panjatkan kehadirat Allah SWT, atas segala rahmat dan karunia-Nya sehinggakami dapat menyelesaikan Tugas Makalah Rekayasa Perangkat Lunak ini dengan baik.

Laporan ini dibuat dengan tujuan untuk memenuhi tugas mata kuliah Rekayasa Perangkat Lunak, tepatnya sebagai tugas disemester lima bagi mahasiswa jurusan komputer akuntansi.

Kami mengucapkan terima kasih kepada semua pihak yang telah membantu dalam pembuatan makalah ini.

Akhir kata, semoga laporan ini bermanfaat bagi kelompok kami khususnya dan para pembaca untuk memberikan tambahan pengetahuan teknologi dan wawasan khususnya dalam bidang rekayasa perangkat lunak.

Tanjungpinang, 21 Februari 2012

Penulis,

Rekayasa Perangkat Lunak Page 2

Page 3: RPL

PENDAHULUAN

Yang dimaksud dengan perangkat lunak adalah :

1. Perintah (program komputer) yang bila dieksekusi memberikan fungsi dan unjuk kerja seperti yang diharapkan.

2. Struktur data yang memungkinkan program memanipulasi informasi secara proporsional.

3. Dokumen yang menggambarkan operasi dan kegunaan program.

Pemodelan dalam suatu rekayasa perangkat lunak merupakan suatu hal yang dilakukan di tahapan awal. Dalam rekayasa perangkat lunak sebenarnya masih memungkinkan tanpa melakukan suatu pemodelan. Hal itu tidak dapat lagi dilakukan dalam suatu industri perangkat lunak karena dengan pemodelan maka akan lebih mudah untuk memahami sistem baik pengebang perangkat lunak itu sendiri maupun pelanggan. Dengan demikian pengembang akan lebih cepat dalam melakukan desain dan mengkontruksi program untuk perangkat lunak tersebut berdasarkan model yang sudah ada dan telah disepakati bersama. Pemodelan ini juga sering disebut dengan metodologi pengembangan sistem.

PROSES

Di dalam suatu industri dikenal berbagai macam proses, demikian juga halnya dengan industri perangkat lunak. Perusahaan yang berbeda seringkali menggunakan proses yang berbeda untuk menghasilkan produk yang sama. Tetapi produk yang berbeda mungkin dihasilkan oleh sebuah perusahaan dengan menggunakan proses yang sama. Jika proses yang digunakan salah maka akan mengurangi kualitas dari produk yang dikembangkan. Seperti produk, proses juga memiliki atribut dan karakteristik seperti :

Understandability, yaitu sejauh mana proses secara eksplisit ditentukan dan bagaimana kemudahan definisi proses itu dimengerti.

Visibility, apakah aktivitas‐aktivitas proses mencapai titik akhir dalam hasil yang

jelas sehingga kemajuan dari proses tersebut dapat terlihat nyata/jelas. Supportability, yaitu sejauh mana aktivitas proses dapat didukung oleh CASE. Acceptability, apakah proses yang telah ditentukan oleh insinyur dapat diterima

dan digunakan dan mampu bertanggung jawab selama pembuatan produk perangkat lunak.

Reliability, apakah proses didesain sedikian rupa sehingga kesalahan proses dapat dihindari sebelum terjadi kesalahan pada produk.

Robustness, dapatkah proses terus berjalan walaupun terjadi masalah yang tak diduga. Maintainability, dapatkah proses berkembang untuk mengikuti kebutuhan atau

perbaikan.

Rekayasa Perangkat Lunak Page 3

Page 4: RPL

Rapidity, bagaimana kecepatan proses pengiriman sistem dapat secara lengkap memenuhi spesifikasi.

MITOS – MITOS PERANGKAT LUNAK

Mitos di sini bukanlah legenda atau dongeng. Arti mitos dalam hal ini adalah anggapan atau penafsiran yang salah dan anggapan tersebut sudah tersebar luas di masyarakat, sehingga kebanyakan orang menganggapnya benar. Adapun mitos- mitos tersebut, yaitu :

1. Mitos management

• Kita tidak perlu mengubah pendekatan terhadap pengembangan software, karena jenis pemrograman yang kita lakukan sekarang ini sudah kita lakukan 10 tahun yang lalu.

Realita : Walau hasil program sama, produktivitas dan kualitas software harus ditingkatkan dengan menggunakan pendekatan software developments.

• Kita sudah mempunyai buku yang berisi standarisasi danprosedur untuk pembentukan software.

Realita : Memang buku tersebut ada, tetapi apakah buku tersebut sudah dibaca atau buku tersebut sudah ketinggalan jaman (out ofdate).

• Jika kita tertinggal dari jadwal yang ditetapkan, kita menambah beberapa programmer saja. Konsep ini sering disebut Mongolian harde concept.

Realita : Semakin manusia bertambah, para personil yang sudah bekerja lebih lama harus menggunakan waktu untuk membimbing pendatang baru, sehingga akan mengurangi jumlah waktu yang digunakan dalam fase pengembangan produksi.

2. Mitos Customer

• Pernyataan tujuan umum sudah cukup untuk memulai penulisan program. Penjelasan yang lebih rinci akan menyusul kemudian.

Realita : Definisi awal yang buruk adalah penyebab utama kegagalan terhadap usaha-usaha pembentukkan software. Penjelasan yang formal dan terinci tentang informasi fungsi performance interface, hambatan desain dan kriteria validasi adalah penting.

• Kebutuhan proyek yang terus menerus berubah dapat dengan mudah diatasi karena software itu bersifat fleksibel.

Rekayasa Perangkat Lunak Page 4

Page 5: RPL

Realita : Jika perubahan mendekati akhir penyelesaian, maka biaya akan lebih besar.

3. Mitos Praktisi

• Tidak ada metode untuk analisis disain dan testing terhadap suatu pekerjaan, cukup menuju ke depan terminal dan mulai coding.

Realita : Metode untuk analisis desain dan testing diperlukan dalam pengembangan software.

• Segera setelah software digunakan, pemeliharaan dapat diminimalisasikan dan diatasi.

Realita : Diperlukan budget yang besar dalam maintenance software. Pemeliharaan software harus diorganisir, direncanakandan dikontrol seolah-olah sebagai suatu proyek besar dalam sebuah organisasi.

Rekayasa Perangkat Lunak Page 5

Page 6: RPL

MACAM - MACAM METODE PERANGKAT LUNAK

Dalam rekayasa perangkat lunak, metodologi pengembangan perangkat lunak atau metodologi pengembangan sistem adalah suatu kerangka kerja yang digunakan untuk menstrukturkan, merencanakan, dan mengendalikan proses pengembangan suatu sistem informasi. Banyak ragam kerangka kerja yang telah dikembangkan selama ini, yang masing-masing memiliki kekuatan dan kelemahan sendiri-sendiri.

Suatu metodologi pengembangan sistem tidak harus cocok untuk digunakan untuk semua proyek. Masing-masing metodologi mungkin cocok diterapkan untuk suatu proyek tertentu, berdasarkan berbagai pertimbangan teknis, organisasi, proyek, serta tim.

Beberapa contoh metodologi pengembangan perangkat lunak yang tersedia di antaranya adalah waterfall, prototyping dan spiral yang akan dijelaskan dibawah ini :

A. Waterfall

Tahapan-tahapan metode waterfall adalah sebagai berikut :1. Analisa

Langkah ini merupakan analisa terhadap kebutuhan sistem. Pengumpulan data dalam tahap ini bisa malakukan sebuah penelitian, wawancara atau study literatur. Seorang sistem analis akan menggali informasi sebanyak-banyaknya dari user sehingga akan tercipta sebuah sistem komputer yang bisa melakukan tugas-tugas yang diinginkan oleh user tersebut. Tahapan ini akan menghasilkan dokumen user requirment atau bisa dikatakan sebagai data yang berhubungan dengan keinginan user dalam pembuatan sistem. Dokumen ini lah yang akan menjadi acuan sistem analis untuk menterjemahkan ke dalam bahasa pemprogram.

2. Design

Proses desain akan menerjemahkan syarat kebutuhan ke sebuah perancangan perangkat lunak yang dapat diperkirakan sebelum dibuat coding. Proses ini berfokus pada : struktur data, arsitektur perangkat lunak, representasi interface, dan detail (algoritma) prosedural. Tahapan ini akan menghasilkan dokumen yang disebut software requirment. Dokumen inilah yang akan digunakan proggrammer untuk melakukan aktivitas pembuatan sistemnya.

3. Coding & Testing

Coding merupan penerjemahan design dalam bahasa yang bisa dikenali oleh komputer. Dilakukan oleh programmer yang akan meterjemahkan transaksi yang diminta oleh user. Tahapan ini lah yang merupakan tahapan secara nyata dalam mengerjakan suatu sistem. Dalam artian penggunaan komputer akan dimaksimalkan dalam tahapan ini. Setelah pengkodean selesai maka akan dilakukan testing terhadap sistem yang telah dibuat tadi. Tujuan testing adalah menemukan kesalahan-kesalahan terhadap sistem tersebut dan kemudian bisa diperbaiki.

4. Penerapan

Rekayasa Perangkat Lunak Page 6

Page 7: RPL

Tahapan ini bisa dikatakan final dalam pembuatan sebuah sistem. Setelah melakukan analisa, design dan pengkodean maka sistem yang sudah jadi akan digunakan oleh user.

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

Metode waterfall bisa digambarkan pada gambar berikut :

Keuntungan Metode Waterfall :

• Kualitas dari sistem yang dihasilkan akan baik. Ini dikarenakan oleh pelaksanaannya secara bertahap. Sehingga tidak terfokus pada tahapan tertentu.

• Document pengembangan sistem sangat terorganisir, karena setiap fase harus terselesaikan dengan lengkap sebelum melangkah ke fase berikutnya. Jadi setiap fase atau tahapan akan mempunyai dokumen tertentu.

Kelemahan Metode Waterfall :

• Diperlukan majemen yang baik, karena proses pengembangan tidak dapat dilakukan secara berulang sebelum terjadinya suatu produk.

• Kesalahan kecil akan menjadi masalah besar jika tidak diketahui sejak awal pengembangan.

• Pelanggan sulit akan menyatakan kebutuhan secara eksplisit sehingga tidak dapat mengakomodasi ketidakpastian pada saat awal pengembangan.

Rekayasa Perangkat Lunak Page 7

Page 8: RPL

B. Prototype

Prototyping adalah proses iteratif dalam pengembangan sistem dimana kebutuhan diubah ke dalam sistem yang bekerja (working system) yang secara terus menerus diperbaiki melalui kerjasama antara pengguna dan analis.

Metode prototyping bisa digambarkan pada gambar berikut :

Tahapan- tahapan dalam prototyping adalah sebagai berikut :

1. Analisis bekerja dengan tim untuk mengidentifikasi kebutuhan awal untuk sistem.

2. Analisis kemudian membangun prototype. Ketika sebuah prototype telah selesai, pengguna bekerja dengan prototype itu dan menyampaikan pada analis apa yang mereka sukai dan tidak mereka sukai.

3. Analisis kemudian menggunakan feedback ini untuk memperbaiki prototype.

4. Versi baru diberikan kembali ke pengguna.

5. Ulangi langkah – langkah tersebut sampai pengguna merasa puas.

Rekayasa Perangkat Lunak Page 8

Page 9: RPL

Keunggulan prototyping adalah:

1. Adanya komunikasi yang baik antara pengembang dan pelanggan2. Pengembang dapat bekerja lebih baik dalam menentukan kebutuhan pelanggan3. Pelanggan berperan aktif dalam pengembangan sistem4. Lebih menghemat waktu dalam pengembangan sistem5. Penerapan menjadi lebih mudah karena pemakai mengetahui apa yang diharapkannya.

Kelemahan prototyping adalah :

1. Pelanggan kadang tidak melihat atau menyadari bahwa perangkat lunak yang ada belum mencantumkan kualitas perangkat lunak secara keseluruhan dan juga belum memikirkan kemampuan pemeliharaan untuk jangja waktu lama.

2. Pengembang biasanya ingin cepat menyelesaikan proyek. Sehingga menggunakan algoritma dan bahasa pemrograman yang sederhana untuk membuat prototyping lebih cepat selesai tanpa memikirkan lebih lanjut bahwa program tersebut hanya merupakan cetak biru sistem .

3. Hubungan pelanggan dengan komputer yang disediakan mungkin tidak mencerminkan teknik perancangan yang baik.

Rekayasa Perangkat Lunak Page 9

Page 10: RPL

C. Spiral

Model spiral pada awalnya diusulkan oleh Boehm, adalah model proses perangkat lunak evolusioner yang merangkai sifat iteratif dari prototype dengan cara kontrol dan aspek sistematis model sequensial linier. Model iteratif ditandai dengan tingkah laku yang memungkinkan pengembang mengembangkan versi perangkat lunak yang lebih lengkap secara bertahap. Perangkat lunak dikembangkan dalam deretan pertambahan. Selama awal iterasi, rilis inkremantal bisa berupa model/prototype kertas, kemudian sedikit demi sedikit dihasilkan versi sistem yang lebih lengkap.

Tahapan-Tahapan Model Spiral

Model spiral dibagi menjadi enam wilayah tugas yaitu:

1. Komunikasi pelanggan. Yaitu tugas-tugas untuk membangun komunikasi antara pelanggan dan kebutuhankebutuhan yang diinginkan oleh pelanggan.

2. Perencanaan Yaitu tugas-tugas untuk mendefinisikan sumber daya, ketepatan waktu, dan proyek informasi lain yg berhubungan.

3. Analisis Resiko Yaitu tugas-tugas yang dibutuhkan untuk menaksir resikomanajemen dan teknis.

4. Perekayasaan Yaitu tugas yang dibutuhkan untuk membangun satu atau lebih representasi dari apikasi tersebut.

5. Konstruksi dan peluncuran Yaitu tugas-tugas yang dibutuhkan untuk mengkonstruksi, menguji, memasang , dan memberi pelayanan kepada pemakai.

6. Evaluasi Pelanggan Yaitu tugas-tugas untuk mendapatkan umpan balik dari pelanggan.

Dari gambar tersebut, proses dimulai dari inti bergerak searah dengan jarum jam mengelilingi spiral. Lintasan pertama putaran menghasilkan perkembangan spesifikasi produk. Putaran selanjutnya digunakan untuk mengembangkan sebuah prototype,

Rekayasa Perangkat Lunak Page 10

Page 11: RPL

dan secara progresif mengembangkan versi perangkat lunak yang lebih canggih. Masing-masing lintasan yang melalui daerah perencanaan menghasilkan penyesuaian pada perencanan proyek. Biaya dan jadwal disesuaikan berdasarkan umpan balik yang disimpulakan dari evaluasi pelanggan. Manajer proyek akan menambah jumlah iterasi sesuai dengan yang dibutuhkan.

Kelebihan model Spiral :

1. Dapat disesuaikan agar perangkat lunak bisa dipakai selama hidup perangkat lunak komputer.

2. Lebih cocok untuk pengembangan sistem dan perangkat lunak skala besar

3. Pengembang dan pemakai dapat lebih mudah memahami dan bereaksi terhadap resiko setiap tingkat evolusi karena perangkat lunak terus bekerja selama proses .

4. Menggunakan prototipe sebagai mekanisme pengurangan resiko dan pada setiap keadaan di dalam evolusi produk.

5. Tetap mengikuti langkah-langkah dalam siklus kehidupan klasik dan memasukkannya ke dalam kerangka kerja iteratif .

6. Membutuhkan pertimbangan langsung terhadp resiko teknis sehingga mengurangi resiko sebelum menjadi permaslahan yang serius.

Kelemahan model Spiral:

1. Sulit untuk menyakinkan pelanggan bahwa pendekatan evolusioner ini bisa dikontrol.2. Memerlukan penaksiran resiko yang masuk akal dan akan menjadi masalah

yang serius jika resiko mayor tidak ditemukan dan diatur.

3. Butuh waktu lama untuk menerapkan paradigma ini menuju kepastian yang absolut.

Rekayasa Perangkat Lunak Page 11

Page 12: RPL

KESIMPULAN

Dalam masyarakat telah tersebar luas berbagai mitos-mitos proses rekayasa perangkat lunak, diantaranya mitos dari segi manajemen, pengguna, dan developer. Sehubungan dengan mitos tersebut sebaiknya kita saling meluruskan atau memberi penjelasan yang realiatanya terjadi agar proses tersebut dapat berjalan dengan lancar dan tidak menghambat waktu pelaksanaan.

Untuk membuat proses rekayasa perangkat lunak juga diperlukan metodelogi sebagai acuan agar proses berjalan dengan lancar. Metodelogi yang sering dipakai diantaranya metode waterfall dimana dalam prosesnya semua tahapan-tahapan harus berurutan, kemudian metode prototyping yang biasa banyak digunakan untuk proyek RPL yang membutuhkan waktu singkat (tidak lama), dan yang terakhir yaitu metode spiral yang digunakan dalam pembuatan proyek RPL yang sangat besar dalam waktu lama dan dibutuhkan team untuk pembagian tugas dalam penyelesaian proyek tersebut.

Rekayasa Perangkat Lunak Page 12

Page 13: RPL

DAFTAR PUSTAKA

• http://materikuliahjuni.blogspot.com/2011/11/pengembanagan-sistem- model-spiral-rpl.html

• http://opoweb.blogspot.com/2010/02/mitos-perangkat-lunak.html

• http://images.nindung.multiply.multiplycontent.com/attachment/0/S4Cw KwooCIoAAAZG7Ks1/resum%20RPL.pdf?nmid=319207614

• http://id.wikipedia.org/wiki/Metodologi_pengembangan_perangkat_luna k

• http://saifulmubin.blogspot.com/2011/02/metode-waterfall.html

Rekayasa Perangkat Lunak Page 13