Paradigma Perangkat Lunak

BAB I

PENDAHULUAN

1.1 Latar Belakang 

Pada pertengahan tahun 60 sampai 70-an banyak dikembangkan sistem-sistem  perangkat lunak yang besar. Sistem-sistem yang dikembangkan ini banyak yang dipandang tidak efisien, kurang berhasil, bahkan banyak yang gagal. Kegagalan ini disebabkan karena tidak tersedianya teknik pengembangan perangkat lunak yang baik. Pada awal tahun 70-an mulai muncul metodologi-metodologi pengembangan perangkat lunak yang cukup baik. 

Pengembangan perangkat lunak dapat diartikan sebagai proses membuat suatu  perangkat lunak baru untuk menggantikan perangkat lunak lama secara keseluruhan atau memperbaiki perangkat lunak yang telah ada. Agar lebih cepat dan tepat dalam mendeskripsikan solusi dan mengembangkan perangkat lunak, juga hasilnya mudah dikembangkan dan dipelihara, maka pengembangan perangkat lunak memerlukan suatu metodologi khusus. Metodologi pengembangan perangkat lunak adalah suatu proses  pengorganisasian kumpulan metode dan konvensi notasi yang telah didefinisikan untuk mengembangkan perangkat lunak. Secara prinsip bertujuan untuk membantu menghasilkan  perangkat lunak yang berkualitas. Penggunaan suatu metodologi sesuai dengan persoalan yang akan dipecahkan dan memenuhi kebutuhan pengguna akan menghasilkan suatu produk  perekayasaan yang berkualitas dan terpelihara serta dapat menghindari masalah-masalah yang sering terjadi seperti estimasi penjadwalan dan biaya, perangkat lunak yang tidak sesuai dengan keinginan pengguna dan sebagainya. 

Metodologi pengembangan perangkat lunak (atau disebut juga model proses atau  paradigma rekayasa perangkat lunak) adalah suatu strategi pengembangan yang memadukan  proses, metode, dan perangkat (tools). Menurut Pressman (1997) Komponen metodologi pengembangan perangkat lunak dapat dibagi dalam tiga unit, yaitu : 

1. Metode, yaitu suatu cara 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. Alat bantu (Tools), yaitu alat-alat (manual atau otomatis) yang mendukung pengembangan  perangkat lunak. Terdapat 2 alat Bantu yang dapat digunakan yaitu : alat Bantu manual dan alat Bantu otomatis. 

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

Secara umum daur hidup pengembangan perangkat lunak meliputi tahapan-tahapan atau aktivitas pengembangan yang terdiri dari tahap analisis, tahap perancangan, tahap implementasi serta tahap pengujian dan perawatan perangkat lunak. Tahap analisis dan  perancangan merupakan tahapan awal yang penting dalam suatu paradigma pemgembangan  perangkat lunak, karena sangat mempengaruhi tahapan selanjutnya. Sehingga jika terjadi kesalahan pada tahap analisis dan perancangan, maka akan terdapat juga kesalahan pada tahap implementasi dan tahapan-tahapan selanjutnya. Tahap implementasi perangkat lunak  bertujuan untuk menerapkan spesifikasi kebutuhan perangkat lunak ke dalam bahasa  pemrograman tertentu. Tahap pengujian perangkat lunak dilakukan untuk menemukan kesalahan (bug) yang mungkin terdapat di dalam sebuah perangkat lunak. Sedangkan tahap  perawatan perangkat lunak fokusnya adalah pengubahan. Ada tiga pengubahan yaitu :  pembetulan, adaptasi (perbaikan terhadap lingkungan) dan perluasan (penambahan karena  permintaan pemakai).

BAB II

PENGERTIAN DAN TUJUAN SOFTWARE ENGINEERING (REKAYASA PERANGKAT LUNAK)

2.1 Pengertian Rekayasa Perangkat Lunak

Rekayasa perangkat lunak (software engineering) adalah suatu proses rancang bangun. Beberapa definisi tentang rekayasa perangkat lunak :

• Pembentukan dan penggunaan prinsip rekayasa (engineering) untuk mendapatkan  perangkat lunak secara ekonomis namun andal dan dapat bekerja secara efesien pada komputer (Fritz Bauer, 1968).

• Penerapan pendekatan yang sistematis, disiplin, dan terukur untuk pengembangan, operasi, dan pemeliharaan perangkat lunak (IEEE, 1993).

• Suatu disiplin yang mengintegrasikan proses/prosedur, metode, dan perangkat tools untuk pembangunan perangkat lunak komputer (Pressman, 97).

• Merupakan aplikasi dari prinsip-prinsip sains untuk:

o Mengurutkan transformasi masalah menjadi solusi yang dapat bekerja dengan baik

o Urutan pemeliharaan perangkat lunak tersebut sampai tidak dapat digunakan lagi (Alan M. Davis) 

Proses RPL dimulai jauh sebelum “Coding” dilakukan dan berlanjut terus setelah versi awal dari program selesai dikerjakan.

2.2 Tujuan Rekayasa Perangkat Lunak

Tujuan dari Software Engineering adalah:

a. Menghasilkan sebuah perangkat lunak yang berkualitas. Yang dimaksud dengan  berkualitas dapat dilihat dari tiga sisi, sisi sponsor (individu atau organisasi yang telah mengeluarkan biaya dalam pembangunan perangkat lunak), sisi pemakai (siapapun yang menggunakan perangkat lunak tersebut), sisi maintainer / modifier (yang memelihara dan memodifikasi perangkat lunak tersebut).

b. Menghasilkan perangkat lunak dengan biaya yang efisien. 

c. Menghasilkan perangkat lunak tepat pada waktunya.

Gambar 1. Paremeter Perangkat Lunak Yang Berkualitas Berdasarkan Sudut Pandang

BAB III

PARADIGMA REKAYASA PERANGKAT LUNAK

3.1 Waterfall

Model Waterfall ini awalnya ditemukan oleh Winston W. Royce pada tahun 1970 . Dia menulis sebuah artikel ilmiah yang berisi pandangan pribadinya pada pengembangan perangkat lunak . Pada paruh pertama dari artikel, ia membahas sebuah proses yang dia sebut ” megah ” . Dia bahkan menggambar sosok model , dan lain yang menunjukkan mengapa hal itu tidak bekerja ( karena persyaratan selalu berubah ) . Model ini adalah air terjun . Dia menggunakannya sebagai contoh dari proses yang sama sekali tidak bekerja. Di paruh kedua artikel ia menggambarkan proses berulang-ulang bahwa ia dianggap jauh lebih baik .

Nama model ini sebenarnya adalah “Linear Sequential Model”. Model ini sering disebut dengan “classic life cycle” atau model waterfall. Model ini sering dianggap kuno, tetapi merupakan model yang paling banyak dipakai didalam Software Engineering (SE). Model ini melakukan pendekatan secara sistematis dan urut mulai dari level kebutuhan sistem lalu menuju ke tahap analisis, desain, coding, testing / verification, dan maintenance. Disebut dengan waterfall karena tahap demi tahap yang dilalui harus menunggu selesainya tahap sebelumnya dan berjalan berurutan. Sebagai contoh tahap desain harus menunggu selesainya tahap sebelumnya yaitu tahap requirement.

3.1.1 Pengertian Waterfall

Waterfall adalah suatu metodologi pengembangan perangkat lunak yang mengusulkan pendekatan kepada perangkat lunak sistematik dan sekuensial yang mulai pada tingkat kemajuan sistem pada seluruh analisis, design, kode, pengujian dan pemeliharaan.

3.1.2 Langkah-langkah yang harus dilakukan pada metodologi Waterfall

1.   Requirement Analysis

Seluruh kebutuhan software harus bisa didapatkan dalam fase ini, termasuk didalamnya kegunaan software yang diharapkan pengguna dan batasan software. Informasi ini biasanya dapat diperoleh melalui wawancara, survey atau diskusi. Informasi tersebut dianalisis untuk mendapatkan dokumentasi kebutuhan pengguna untuk digunakan pada tahap selanjutnya.

2.  System Design

Tahap ini dilakukan sebelum melakukan coding. Tahap ini bertujuan untuk memberikan gambaran apa yang seharusnya dikerjakan dan bagaimana tampilannya. Tahap ini membantu dalam menspesifikasikan kebutuhan hardware dan sistem serta mendefinisikan arsitektur sistem secara keseluruhan.

3.  Implementation

Dalam tahap ini dilakukan pemrograman. Pembuatan software dipecah menjadi modul-modul kecil yang nantinya akan digabungkan dalam tahap berikutnya. Selain itu dalam tahap ini juga dilakukan pemeriksaaan terhadap modul yang dibuat, apakah sudah memenuhi fungsi yang diinginkan atau belum.

4.  Integration & Testing

Di tahap ini dilakukan penggabungan modul-modul yang sudah dibuat dan dilakukan pengujian ini dilakukan untuk mengetahui apakah software yang dibuat telah sesuai dengan desainnya dan masih terdapat kesalahan atau tidak.

5.  Operation & Maintenance

Ini merupakan tahap terakhir dalam model waterfall. Software yang sudah jadi dijalankan serta dilakukan pemeliharaan. Pemeliharaan termasuk dalam memperbaiki  kesalahan yang tidak ditemukan pada langkah sebelumnya. Perbaikan implementasi unit sistem dan peningkatan jasa sistem sebagai kebutuhan baru.

3.1.3 Keuntungan  Waterfall

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

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

• Metode ini masih lebih baik digunakan walaupun sudah tergolong kuno, daripada menggunakan pendekatan asal-asalan. Selain itu, metode ini juga masih masuk akal jika kebutuhan sudah diketahui dengan baik.

3.1.4 Kelemahan 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 yang berakibat pada tahapan selanjutnya.

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

• Pelanggan harus sabar, karena pembuatan perangkat lunak akan dimulai ketika tahap desain sudah selesai. Sedangkan pada tahap sebelum desain bisa memakan waktu yang lama.

• Pada kenyataannya, jarang mengikuti urutan sekuensial seperti pada teori. Iterasi sering terjadi menyebabkan masalah baru.

  

Gambar 2 Waterfall

3.2 Prototype

Prototyping model adalah suatu proses pembuatan software yang yang bersifat berulang dan dengan perencanaan yang cepat yang dimana terdapat umpan balik yang memungkinkan terjadinya perulangan dan perbaikan software sampai dengan software tersebut memenuhi kebutuhan dari si pengguna. Sedangkan dari beberapa referensi yang saya temukan, prototyping model adalah salah satu model sederhana pembuatan software yang dimana mengijinkan pengguna memiliki suatu gambaran awal/dasar tentang program serta melakukan oengujian awal yang didasarkan pada konsep model kerja(working model).

3.2.1 Proses Prototype

Proses-proses dalam model prototyping secara umum adalah sebagai berikut:

1. Pengumpulan kebutuhan

Developer dan klien akan bertemu terlebih dahulu dan kemudian menentukan tujuan umum, kebutuhan yang diketahui dan gambaran bagian-bagian yang akan dibutuhkan berikutnya.

2. Perancangan

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

3. Evaluasi Prototype

Klien akan mengevaluasi prototype yang dibuat dan digunakan untuk memperjelas kebutuhan software.

3.2.2 Tahapan Prototype

Tahapan-tahapan dalam prototyping adalah sebagai berikut :

1. Pengumpulan kebutuhan

Pelanggan dan pengembang bersama-sama mendefinisikan format dan kebutuhan kesseluruhan perangkat lunak, mengidentifikasikan semua kebutuhan, dan garis besar sistem yang akan dibuat.

2. Membangun prototyping

Membangun prototyping dengan membuat perancangan sementara yang berpusat pada penyajian kepada pelanggan (misalnya dengan membuat input dan contoh outputnya).

3. Evaluasi protoptyping

Evaluasi ini dilakukan oleh pelanggan apakah prototyping yang sudah dibangun sudah sesuai dengan keinginan pelanggan. Jika sudah sesuai maka langkah keempat akan diambil. Jika tidak, maka prototyping diperbaiki dengan mengulang langkah 1, 2 , dan 3.

4. Mengkodekan system

Dalam tahap ini prototyping yang sudah disepakati diterjemahkan ke dalam bahasa pemrograman yang sesuai.

5. Menguji system

Setelah sistem sudah menjadi suatu perangkat lunak yang siap pakai, harus dites dahulu sebelum digunakan. Pengujian ini dilakukan dengan White Box, Black Box, Basis Path, pengujian arsitektur dan lain-lain.

6. Evaluasi Sistem

Pelanggan mengevaluasi apakah sistem yang sudah jadi sudah sesuai dengan yang diharapkan . Jika sudah, maka langkah ketujuh dilakukan, jika belum maka mengulangi langkah 4 dan 5.

7. Menggunakan system

Perangkat lunak yang telah diuji dan diterima pelanggan siap untuk digunakan.

3.2.3 Keunggulan prototyping :

• Komunikasi akan terjalin baik antara pengembang dan pelanggan.

• Pengembang dapat bekerja lebih baik dalam menentukan kebutuhan setiap pelanggannya.

• Pelanggan berperan aktif dalam proses pengembangan sistem.

• Lebih menghemat waktu dalam pengembangan sistem.

• Penerapan menjadi lebih mudah karena pemakai mengetahui apa yang diharapkannya

3.2.4 Kelemahan prototyping :

• 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 jangka waktu lama.

• 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 sebuah kerangka kerja(blueprint) dari sistem .

• Hubungan pelanggan dengan komputer yang disediakan mungkin tidak mencerminkan teknik perancangan yang baik dan benar.

Gambar 3 Gambar Prototype

3.3 RAD (Rapid Aplication Development)

Rapid Aplication Development (RAD) adalah sebuah model proses perkembangan perangkat lunak sekuensial linier yang menekankan siklus perkembangan yang sangat pendek. Model RAD ini merupakan sebuah adaptasi ” kecepatan tinggi ” dari model sekuensial linier dimana perkembangan cepat dicapai dengan menggunakan pendekatan konstruksi 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).

3.3.1 Tahapan Rapid Aplication Development (RAD)

Tahapan-tahapan dalam Rapid Aplication Development (RAD) adalah sebagai berikut :

1. Bussines Modelling

Aliran informasi diantara funsi-fungsi bisnis dimodelkan dengan suatu cara untuk menjawab pertanyaan-pertanyaan berikut: Informasi apa yang mengendalikan proses bisnis? Informasi apa yang dimunculkan? Siapa yang memunculkan? Ke mana informasi itu pergi? Siapa yang memprosesnya?

2.Data Modelling

Aliran informasi yang di definisikan sebagai bagian dari fase bussiness modelling di saring 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 Modeling 

Aliran informasi yang didefinisikan di dalam fase data modelling ditransformasikan untuk mencapai aliran informasi yang perlu bagi implementasi sebuah fungsi bisnis. Gambaran pemrosesan digunakan 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 ke-tiga yang konvensional, RAD lebih banyak memproses kerja memakai 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 diuji dan semua interface harus dilatih secara penuh.

3.3.2 Kelebihan RAD

• Hasil pengembangan bisa lebih cepat dibandingkan SDLC lainnya

• Memerlukan biaya yang lebih sedikit

• Mementingkan dari segi bisnis dan teknik

• Berkonsentrasi pada sudut pandang user

• Menyediakan kemungkinan perubahan secara cepat sesuai permintaan user

• Menghasilkan jarak kesesuaian yang kecil antara kebutuhan user dan spesifikasi system

• Waktu, biaya, dan effort minimal

3.3.3 Kekurangan RAD

• RAD memerlukan sumber daya manusia yang memadai untuk menciptakan jumlah tim RAD yang baik.

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

• Kecepatan yang tinggi dengan biaya minimal kemungkinan besar hasil kualitasnya rendah.

• Proyek mungkin berakhir dengan lebih banyak tambahan kebutuhan daripada yang telah dipenuhi

• Potensial adanya penambahan fitur karena fitur yang sekarang hasilnya asal-asalan

• Potensial ketidaksesuaian desain dan implementasi

• Potensial ketidakkonsistenan penamaan dan dokumentasi

• Sangat sulit membuat modul yang dapat digunakan kembali

Gambar 4 RAD

3.4 Spiral

Spiral Model adalah suatu model tentang tahapan pembuatan suatu perangkat lunak, spiral model ini adalah salah satu dari model revolusioner, model spiral merangkai sifat interatif yaitu sifat yang ditandai yang memungkinkan untuk mengembangkan versi dari suatu perangkat lunak secara bertahap untuk menghasilkan perangkat lunak yang lebih lengkap atau lebih sempurna dan terkontrol. Perangkat lunak dikembangkan dalam deretan pertambahan. Selama awal iterasi, rilis ikremantal bisa berupa model/prototype kertas, kemudian sedikit demi sedikit dihasilkan versi sistem yang lebih lengkap.

3.4.1 Tahapan-Tahapan Spiral

Model spiral dibagi menjadi enam wilayah tugas yaitu :

1. Customer communication

Aktivitas yang dibutuhkan untuk membangun komunikasi yang efektif antara developer dengan user / customer terutama mengenai kebutuhan dari customer.

2. Planning

Aktivitas perencanaan ini dibutuhkan untuk menentukan sumberdaya, perkiraan waktu pengerjaan, dan informasi lainnya yang dibutuhkan untuk pengembangan software.

3. Analysis Risk

Aktivitas analisis resiko ini dijalankan untuk menganalisis baik resiko secara teknikal.

4. Engineering

Aktivitas yang dibutuhkan untuk membangun 1 atau lebih representasi dari aplikasi secara teknikal.

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

6. Customer Evaluation

Aktivitas yang dibutuhkan untuk mendapatkan feedback dari user / customer berdasarkan evaluasi mereka selama representasi software pada tahap construction and release.

3.4.2 Kelebihan Spiral

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

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

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

3.4.3 Kekurangan Spiral

• Sulit untuk menyakinkan pelanggan bahwa pendekatan evolusioner ini bisa dikontrol.

• Memerlukan penaksiran resiko yang masuk akal dan akan menjadi masalah yang serius jika resiko mayor tidak ditemukan dan diatur.

• Butuh waktu lama untuk menerapkan paradigma ini menuju kepastian yang absolute.

Gambar 5 Spiral

3.5 Fourth Generation Techniques (4GT)

Istilah generasi ke empat, mengarah ke perangkat lunak yang umum yaitu tiap pengembang perangkat lunak menentukan beberapa karakteristik perangkat lunak pada level tinggi.

3.5.1 Tahapan Fourth Generation Techniques (4GT)

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

• Translasi kebutuhan menjadi prototype operasional, atau langsung melakukan implementasi secara langsung dengan menggunakan bahasa generasi ke empat (4GL) jika aplikasi relatif kecil

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

• Pengujian

• Membuat dokumentasi

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

3.5.2 Keunggulaan

• Pengurangan waktu dan peningkatan produktivitas secara besar

3.5.3 Kekurangan

• Kesulitan penggunaan perangkat bantu (tools) dibandingkan dengan bahasa  pemrograman, dan juga kode sumber yang dihasilkannya tidak efisien

Gambar 6 Fourth Generation Techniques (4GT)

3.6 Incremental

Model incremental menggabungkan elemen-elemen model sekuensial linier (diimplementasikan secara berulang) dengan filosofi prototype interatif. Model ini memakai urutan-urutan linier di dalam model yang membingungkan, seiring dengan laju waktu kalender. Setiap urutan linier menghasilkan pertambahan perangkat lunak yang kemudian dapat disampaikan kepada pengguna.

3.6.1 Tahapan

Tahapan Incremental:

• Requirement adalah proses tahapan awal yang dilakukan pada incremental model adalah penentuan kebutuhan atau analisis kebutuhan.

• Specification adalah proses spesifikasi dimana menggunakan analisis kebutuhan sebagai acuannya.

• Architecture Design adalah tahap selanjutnya, perancangan software yang terbuka agar dapat diterapkan sistem pembangunan per-bagian pada tahapan selanjutnya.

• Code setelah melakukan proses desain selanjutnya ada pengkodean.

• Test merupakan tahap pengujian dalam model ini.

3.6.2 Kelebihan Penggunaan Incremental Model

• Merupakan model dengan manajemen yang sederhana

• Pelanggan tidak perlu menunggu sampai seluruh system dikirim untuk mengambil keuntungan dari system tersebut. Inkremen yang pertama sudah memenuhi persyaratan mereka yang paling kritis, sehingga perangkat lunak dapat segera digunakan.

• Pelanggan dapat memakai inkremen yang pertama sebagai bentuk prototype dan mendapatkan pengalaman yang dapat menginformasikan persyaratan untuk inkremen system berikutnya

• Resiko untuk kegagalan proyek secara keseluruhan lebih rendah. Walaupun masalah dapat ditemukan pada beberapa inkremen, bias saja beberapa inkremen diserahkan dengan sukses kepada pelanggan.

• Karena layanan dengan prioritas tertinggi diserahkan pertama dan inkremen berikutnya diintegrasikan dengannya, sangatlah penting bahwa layanan system yang paling penting mengalami pengujian yang paling ketat. Ini berarti bahwa pelanggan akan memiliki kemungkinan kecil untuk memenuhi kegagalan perangkat lunak pada inkremen system yang paling kecil.

3.6.3 Kekurangan Penggunaan Incremental Model

• Inkremen harus relative lebih kecil (tidak lebih dari 20.000 baris kode) dan setiap inkremen harus menyediakan sebagian dari fungsional system

• Adanya kesulitan untuk memetakan persyaratan pelanggan pada inkremen dengan ukuran yang benar

Gambar 7 Incremental

 

BAB IV

PERBANDINGAN PARADIGMA REKAYASA PERANGKAT LUNAK

4.1 Kelebihan dan Kekurangan

4.1.1 Waterfall

Kelebihan waterfall :

• Dituntut bekerja secara disiplin

• Dokumen lengkap

• Selalu dalam kontrol SQA

• Maintenance mudah, karena dokumen lengkap

Kekurangan Waterfall :

• Konsumen kesulitan membaca dokumen, komunikasi menjadi sulit

• Alur linier, proses lambat

• Konsumen tidak dapat melihat hasil hingga akhir tahapan

• Personil tidak bekerja optimal, karena ada waktu tunggu sebuah tahapan selesai

4.1.2 Model Spiral

Kelebihan Model Spiral:

• Ditekankan pada pencairan alternatif, dan pemaksaan penggunaan kembali Software yang telah ada

• Analisa resiko

• Adanya prototype memudahkan komunikasi dengan konsumen

Kekurangan Spiral Model

• Biasanya pihak pengembang dan perusahaan berada pada satu pihak yang sama

• Tahapan analisa resiko sewaktu-waktu dapat membatalkan proses rekayasa, jika pihak pengembang adalah pihak di luar perusahaan, maka timbulah masalah hukum

4.1.3 Incremental Model

Kelebihan Incremental Model

• Personil bekerja optimal

• Pihak konsumen dapat langsung menggunakan dahulu bagian-bagian yang telah selesai dibangun. Contohnya pemasukan data karyawan

• Mengurangi trauma karena perubahan sistem.  Klien dibiasakan perlahan-lahan menggunakan produknya bagian per bagian

• Memaksimalkan pengembalian modal investasi konsumen

Kekurangan Incremental Model

• Kemungkinan tiap bagian tidak dapat diintegrasikan

• Dapat menjadi build and Fix Model, karena kemampuannya untuk selalu mendapat perubahan selama proses rekayasa berlangsung

• Harus Open Architecture

4.2 Perbandingan Model dalam Rekayasa Perangkat Lunak

Setelah kita membahas beberapa permodelan rekayasa perangkat lunak, diantaranya model waterfall, model spiral, model incremental dan lain-lain, maka dalam pembahasan kali ini kita akan membahas perbandingan model rekayasa perangkat lunak tersebut.

Kita akan membahas 3 model perbandingan, yaitu waterfall, spiral dan incremental.  Sebaiknya model tersebut digunakan jika :

No Faktor Waterfall Spiral Incremental

1 Proyek dengan ukuran resiko Kecil Sedang Besar

2 Ukuran Software Kecil Besar Besar

3 Jenis aplikasi Biasa Agak biasa Tidak biasa

4 Fleksibel terhadap perubahan (waktu) Rendah Perubahan awal Perubahan selama proyek berlangsung

5 Keterlibatan konsumen Rendah Sedang Tinggi

6 Bahasa pemrograman Prosedural Prosedural, OOP OOP

 

BAB V 

KESIMPULAN

Rekayasa perangkat lunak (RPL, atau dalam bahasa Inggris: Software Engineering atau SE) adalah satu bidang profesi yang mendalami cara-cara pengembangan perangkat lunak termasuk pembuatan, pemeliharaan, manajemen organisasi pengembanganan perangkat lunak dan manajemen kualitas.

Ada beberapa paradigm atau model dalam Rekayasa Perangkat Lunak antara lain:

• Waterfall

• Prototype

• RAD

• Spiral

• Fourth Generation Techniques (4GT)

• Incremental

Artikel terkait :