Model Proses Rekayasa Perangkat Lunak
Model Proses Rekayasa Perangkat Lunak
Model proses perangkat lunak adalah gambaran abstrak dari suatu proses. Model ini menyajikan deskripsi suatu proses dari beberapa sudut pandang tertentu.
1. Waterfall Model / Linear Sequential Model
Waterfall model adalah model yang melakukan pendekatan pada perkembangan perangkat lunak secara seistematik dan sekuensial. Yang artinya kegiatan pada model ini dilakukan secara terurut berdasarkan panduan proses mulai dari komunikasi kepada client atau pelanggan sampai dengan aktifitas sampai pengorderan setelah masalah dipahami secara lengkap dan berjalan stabil sampai selesai.
Ada 2 fase-fase dalam Waterfall model :
1. Menurut referensi Pressman
2. Menurut referensi Sommerville
Kedua fase-fase menggunakan nama yang berbeda pada tiap fasenya, tetapi pada dasarnya inti dari kedua fase-fase tersebut adalah sama. Tahapan-tahapan yang yang sering dijumpai adalah menurut refrensi dari Sommerville karena lebih terperinci perbedaan pada tiap fasenya.
a. Requirements definition
b. System and software design
c. Implementation and unit testing
d. Integration and system testing
e. Operation and maintenance
Kelebihan Model Waterfall:
l Bisa digunakan jika suatu persyaratan untuk membuat suatu software sudah dipahami dengan baik dan sudah lengkap semua persyaratan yang ada.
Kekurangan Model Waterfall:
l Waterfall model bersifat kaku sehingga sulit untuk melakukan perubahan pada sistem perangkat lunak.
l Terjadinya pembagian proyek menjadi tahap-tahap yang tidak fleksibel, karena komitmen harus dilakukan pada tahap awal proses.
l Hal ini mengakibatkan sulitnya untuk merespon perubahan kebutuhan pengguna (user).
l Model air terjun harus digunakan hanya ketika persyaratan dipahami dengan baik.
2. Incremental Proses Model
a. The Incremental Model
Dalam model Incremental ini proses pengerjaan perangkat lunak akan dilakukan perbagian sehingga bagian selanjutnya akan dikerjakan setelah bagian awal telah selesai dan selanjutnya sampai menghasilkan perangkat lunak yang lengkap dengan semua fungsi yang diperlukan dan pengerjaan perangkat lunak berakhir. Sebelum pengerjaan perangkat lunak akan dilakukan perancangan arsitektur software sebagai kerangka dalam pengerjaan perbagian.
Tahapan dari Incremental Model :
Requirement : penentuan kebutuhan perangkat lunak yang akan dibangun.
Specification : spesifikasi bagian dari perangkat lunak.
Architecture Design : pembuatan perancangan perangkat lunak (dasar dari kerangka kerja)
Kelebihan Incremental Model :
l Resiko yang rendah pada pengembangan sistem.
l Mengutamakan fungsi-fungsi pada sistem perangkat lunak sehingga kemudahan pemakaian sistem yang paling di utamakan.
l Tahap awal adalan dasar dari pembuatan tahap berikutnya (dikerjakan secara terurut)
l Model ini cocok jika jumlah anggota tim pengembang/pembangun PL tidak cukup.
l Mampu mengakomodasi perubahan secara fleksibel.
Kekurangan Incremental Model :
l Hanya cocok untuk proyek berukuran kecil (tidak lebih dari 200.000 baris coding)
l Mungkin terjadi kesulitan untuk memetakan kebutuhan pengguna ke dalam rencana spesifikasi masing-masing hasil increment
b. The RAD Model (Rapid Aplication Development)
RAD (Rapid Application Development) adalah model proses yang juga termasuk dalam Incremental Proses Model karena pembangunan dari sistem perangkat lunak dikerjakan dengan tahapan yang terurut mulai dari dasar (awal) sampai tahap paling tinggi (proses akhir pembuatan), tetapi perbedaannya model ini dibagi menjadi beberapa modul dan dikerjakan secara besama-sama dan sesuai dengan waktu yang ditentukan.
RAD adalah sebuah model proses perkembangan software sekuensial linier yang menekankan siklus perkembangan yang sangat pendek. Model RAD ini merupakan sebuah adaptasi “kecepatan tinggi” dari model sekuensial linier di mana perkembangan cepat dicapai dengan menggunakan pendekatan kontruksi berbasis komponen. Jika kebutuhan dipahami dengan baik, proses RAD memungkinkan tim pengembangan menciptakan “sistem fungsional yang utuh” dalam periode waktu yang sangat pendek (kira-kira 60 sampai 90 hari). Karena dipakai terutama pada aplikasi sistem konstruksi, pendekatan RAD melingkupi fase – fase sebagai berikut :
1. Bussiness modeling
Aliran informasi di antara fungsi – fungsi bisnis dimodelkan dengan suatu cara untuk menjawab pertanyaan -pertanyaan berikut : informasi apa yang mengendalikan proses bisnis? Informasi apa yang di munculkan? Siapa yang memunculkanya? Ke mana informasi itu pergi? Siapa yang memprosesnya?
2. Data modeling
Aliran informasi yang didefinisikan sebagai bagian dari fase bussiness modelling disaring ke dalam serangkaian objek data yang dibutuhkan untuk menopang bisnis tersebut. Karakteristik (disebut atribut) masing-masing objek diidentifikasi dan hubungan antara objek – objek tersebut didefinisikan.
3. Prosess modelling
Aliran informasi yang didefinisikan di dalam fase data modeling 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.
4. Aplication generation
RAD mengasumsikan pemakaian teknik generasi ke empat. Selain menciptakan perangkat lunak dengan menggunakan bahasa pemrograman generasi ketiga yang konvensional, RAD lebih banyak memproses kerja untuk memkai lagi komponen program yang ada ( pada saat memungkinkan) atau menciptakan komponen yang bisa dipakai lagi (bila perlu). Pada semua kasus, alat – alat bantu otomatis dipakai untuk memfasilitasi konstruksi perangkat lunak.
5. Testing and turnover
Karena proses RAD menekankan pada pemakaian kembali, banyak komponen program telah diuji. Hal ini mengurangi keseluruhan waktu pengujian. Tetapi komponen baru harus di uji dan semua interface harus dilatih secara penuh.
Kelebihan RAD Model :
l Pengerjaan sistem yang cepat (60 -90 hari)
l RAD dapat menggunakan kembali komponen yang ada (reusable object) sehingga pengembang pengembang tidak perlu membuat dari awal lagi.
l Proses pengiriman menjadi lebih mudah karena proses pembuatan berupa potongan- potongan script
l Lebih efektif dari pendekatan air terjun dalam menghasilkan sistem yang memenuhi kebutuhan langsung dari pelanggan.
l Cocok untuk proyek yang memerlukan waktu yang singkat.
Kekurangan RAD Model :
l Tidak tepat untuk sistem yang berukuran besar (sangat tidak cocok untuk proyek skala besar)
l RAD memerlukan sumber daya manusia yang memadai untuk menciptakan jumlah tim RAD yang baik.
l Pembuatan sistem bisa gagal jika waktu kesepakatan tidak terpenuhi (terlalu cepat atau permintaan agar diselesaikan lebih cepat dari perjanjian).
l Mempunyai banyak resiko karena dikerjakan dalam modul yang berbeda dan dalam waktu yang hampir bersamaan dan pada tempat yang belum tentu sama.
l RAD menuntut pengembangan dan pelanggan memiliki komitmen di dalam aktivitas rapid-fire yang diperlukan untuk melengkapi sebuah sistem, di dalam kerangka waktu yang sangat diperpendek. Jika komitmen tersebut tidak ada, proyek RAD akan gagal.
3. Evolutionary Software Process Models
a. Protoyping Model
Protoyping Model adalah model yang dapat diterapkan pada model apapun. Model ini tidak memerlukan data yang lengkap dari sisi client dan banyaknya keraguan dari pembuat software karena kondisi yang belum diketahui (seberapa besar software, bagaimana sistem penerapannya). Model ini tepat digunakan jika pihak client menginginkan prototype dari software dalam waktu yang singkat. Dan prototype inilah yang akan menjadi acuan dari client untuk memberikan data kebutuhan yang lebih lengkap pada pembuat software (developer).
Metode prototyping adalah sistem informasi yang menggambarkan hal-hal penting dari sistem informasi yang akan datang. Prototipe sistem informasi bukanlah merupakan sesuatu yang lengkap, tetapi sesuatu yang harus dimodifikasi kembali, dikembangkan, ditambahkan atau digabungkan dengan sistem informasi yang lain bila perlu.
Penjelasan dari gambar di atas sebagai berikut:
l User merasa prototipe merupakan PL yang sesungguhnya, padahal ketika membuat prototipe belum disertakan kualitas PL secara keseluruhan / kemampuan pemeliharaan untuk jangka panjang
l Developer sering membuat kompromi-kompromi implementasi untuk membuat prototipe bekerja dengan cepat sehingga akan ditemui ketidakcocokan pada prototipe ketika prototipe dibangun dengan bahasa yang sederhana
l Program dibuat ulang / prototipe selalu baru
Mengacu pada pemilahan fungsi yang harus ditampilkan oleh prototyping. Pemilahan harus selalu dilakukan berdasarkan pada tugas-tugas yang relevan yang sesuai dengan contoh kasus yang akan diperagakan
Jenis-Jenis Prototyping
l Feasibility Prototyping – digunakan untuk menguji kelayakan dari teknologi yang akan digunakan untuk system informasi yang akan disusun.
l Requirement Prototyping – digunakan untuk mengetahui kebutuhan aktivitas bisnis user.
l Desain Prototyping - digunakan untuk mendorong perancangan system informasi yang akan digunakan.
l Implementation Prototyping – merupakan lanjytan dari rancangan protipe, prototype ini langsung disusun sebagai suatu system informasi yang akan digunakan.
Kelebihan Prototyping Model :
l User dapat berpartisipasi aktif
l Penentuan kebutuhan lebih mudah diwujudkan
l Mempersingkat waktu pengembangan SI
Kekurangan Prototyping Model :
l Proses analisis dan perancangan terlalu singkat
l Mengesampingkan alternatif pemecahan masalah
l Biasanya kurang fleksible dalam mengahadapi perubahan
l Prototype yang dihasilkan tidak selamanya mudah dirubah
l .Banyak ketidak sesuaian pada bentuk prototype.
l Prototype terlalu cepat selesai
l Pada prototype tentu saja banyak kebutuhan yang tidak di tampilkan seluruhnya karena data yang dikumpulkan hanya sebagian.
l Prototype yang di setujui oleh client harus dikembangkan oleh developer tanpa ada data tambahan dari client dan software dari prototype harus memiliki fungsi yang lengkap.
b. Spiral Model
Model ini cukup baru ditemukan,yaitu tahun 1988 oleh Barry Boehm. Spiral adalah salah satu bentuk evolusi yang menggunakan metode iterasi natural yang dimiliki oleh model prototyping dan digabungkan dengan aspek sistematis yang dikembangkan model waterfall.
Spiral model dibagi menjadi beberapa framework aktivitas, yang disebut dengan task regions. Kebanyakan aktivitas2 tersebut dibagi antara 3 sampai 6 aktivitas. Berikut adalah aktivitas-aktivitas yang dilakukan dalam spiral model:
l Customer Communication. Aktivitas yang dibutuhkan untuk membangun komunikasi yang efektif antara developer dengan user / customer terutama mengenai kebutuhan dari customer.
l Planning. Aktivitas perencanaan ini dibutuhkan untuk menentukan sumberdaya, perkiraan waktu pengerjaan, dan informasi lainnya yang dibutuhkan untuk pengembangan software.
l Analysis risk. Aktivitas analisis resiko ini dijalankan untuk menganalisis baik resiko secara teknikal maupun secara manajerial. Tahap inilah yang mungkin tidak ada pada model proses yang juga menggunakan metode iterasi, tetapi hanya dilakukan pada spiral model.
l Engineering. Aktivitas yang dibutuhkan untuk membangun 1 atau lebih representasi dari aplikasi secara teknikal.
l Construction & Release. Aktivitas yang dibutuhkan untuk develop software, testing, instalasi dan penyediaan user / costumer support seperti training penggunaan software serta dokumentasi seperti buku manual penggunaan software.
l Customer evaluation. Aktivitas yang dibutuhkan untuk mendapatkan feedback dari user / customer berdasarkan evaluasi mereka selama representasi software pada tahap engineering maupun pada implementasi selama instalasi software pada tahap construction and release.
Kelebihan model Spiral :
l Dapat disesuaikan agar perangkat lunak bisa dipakai selama hidup perangkat lunak komputer.
l Lebih cocok untuk pengembangan sistem dan perangkat lunak skala besar
l Pengembang dan pemakai dapat lebih mudah memahami dan bereaksi terhadap resiko setiap tingkat evolusi karena perangkat lunak terus bekerja selama proses .
Kelemahan model Spiral:
l Sulit untuk menyakinkan pelanggan bahwa pendekatan evolusioner ini bisa dikontrol.
l Memerlukan penaksiran resiko yang masuk akal dan akan menjadi masalah yang serius jika resiko mayor tidak ditemukan dan diatur.
l Butuh waktu lama untuk menerapkan paradigma ini menuju kepastian yang absolute
4. Extreme Programming (XP) Model
Model proses ini diciptakan dan dikembangkan oleh Kent Beck. Model ini adalah model proses yang terbaru dalam dunia rekayasa perangkat lunak dan mencoba menjawab kesulitan dalam pengembangan software yang rumit dan sulit dalam implementasi.
Menurut Kent Beck XP adalah : “A lightweight, efficient, low-risk, flexible, predictable, scientific and fun way to develop software”. Suatu model yang menekankan pada:
n keterlibatan user secara langsung
n pengujian
n pay-as-you-go design
Adapun empat nilai penting dari XP
1. Communication/Komunikasi: komunikasi antara developer dan klien sering menjadi masalah. Karena itu komunikasi dalam XP dibangun dengan melakukan pemrograman berpasangan (pair programming). Developer didampingi oleh pihak klien dalam melakukan coding dan unit testing sehingga klien bisa terlibat langsung dalam pemrograman sambil berkomunikasi dengan developer. Selain itu perkiraan beban tugas juga diperhitungkan.
2. Simplicity/ sederhana: Menekankan pada kesederhanaan dalam pengkodean: “What is the simplest thing that could possibly work?” Lebih baik melakukan hal yang sederhana dan mengembangkannya besok jika diperlukan. Komunikasi yang lebih banyak mempermudah, dan rancangan yang sederhana mengurangi penjelasan.
3. Feedback / Masukan/Tanggapan: Setiap feed back ditanggapi dengan melakukan tes, unit test atau system integration dan jangan menunda karena biaya akan membengkak (uang, tenaga, waktu).
4. Courage / Berani: Banyak ide baru dan berani mencobanya, berani mengerjakan kembali dan setiap kali kesalahan ditemukan, langsung diperbaiki.
Kelebihan model Extreme Programming :
l Komunikasi dalam XP dibangun dengan melakukan pemrograman berpasangan (pair programming). Developer didampingi oleh pihak klien dalam melakukan coding dan unit testing sehingga klien bisa terlibat langsung dalam pemrograman sambil berkomunikasi dengan developer. Selain itu perkiraan beban tugas juga diperhitungkan.
l Menekankan pada kesederhanaan dalam pengkodean: “What is the simplest thing that could possibly work?” Lebih baik melakukan hal yang sederhana dan mengembangkannya besok jika diperlukan. Komunikasi yang lebih banyak mempermudah, dan rancangan yang sederhana mengurangi penjelasan.
l Setiap feed back ditanggapi dengan melakukan tes, unit test atau system integration dan jangan menunda karena biaya akan membengkak (uang, tenaga, waktu).
l Banyak ide baru dan berani mencobanya, berani mengerjakan kembali dan setiap kali kesalahan ditemukan, langsung diperbaiki.
Kelemahan model Extreme Programming :
l Developer harus selalu siap dengan perubahan karena perubahan akan selalu diterima.
l Tidak bisa membuat kode yang detail di awal (prinsip simplicity dan juga anjuran untuk melakukan apa yang diperlukan hari itu juga).
REFERENSI
l http://malikah-tutik.blogspot.com/2013/03/model-proses-rekayasa-perangkat-lunak.html
Comments
Post a Comment
Silahkan Komentar :)