Pengebangan Perangkat Lunak

 1    Pengembangan Sekuensial Linier (Waterfall Model)

Metode pengembangan sistem sekuensial linier atau yang sering disebut juga dengan siklus kehidupan klasik atau model air terjun (waterfall model) memberikan sebuah pendekatan pengembangan sistem yang sistematik dan sekuensial, dimulai pada fase perencanaan sistem, analisis, desain, kode, pengujian, dan pemeliharaan. 

1. Perencanaan atau rekayasa dan pemodelan sistem

Pada fase ini dilakukan identifikasi sistem, studi kebutuhan pengguna, dan studi kelayakan sistem baik secara teknis maupun teknologi serta penjadwalan pengembangan sistem.

2. Analisis kebutuhan perangkat lunak

Pada fase ini pengumpulan kebutuhan diintensifkan dan difokuskan pada sistem yang akan dibangun meliputi identifikasi domain informasi, tingkah laku sistem, unjuk kerja, dan antarmuka sistem. Kebutuhan untuk sistem didokumentasikan dan dikonsultasikan lagi dengan pengguna.

3. Desain

Fase ini difokuskan pada proses desain struktur data, arsitektur sistem, representasi interface, dan algoritma program.

4. Kode

Setelah proses desain selesai maka hasilnya harus diterjemahkan kedalam bentuk program komputer yang kemudian menghasilkan suatu sistem.

5. Pengujian

Pengujian dilakukan untuk menemukan kesalahan-kesalahan yang mungkin terjadi pada proses pengkodean serta memastikan bahwa input yang dibatasi memberikan hasil yang sesuai dengan kebutuhan.

6. Pemeliharaan

Proses ini dilakukan setelah sistem yang dihasilkan disampaikan kepada pengguna, terutama jika sistem mengalami permasalahan yang belum ditemukan pada saat proses pengujian, permasalahan ini dapat berkaitan dengan permintaan pengguna yang membutuhkan perkembangan fungsional sistem maupun adanya penyesuaian dengan lingkungan eksternal seperti adanya perubahan periperal atau perubahan sistem operasi. Fase pemeliharaan akan mengakibatkan pengembang mengaplikasikan lagi setiap fase pengembangan sistem mulai dari awal, namun tidak membuat sistem yang baru.

• Kelebihan dan kekurangan sekuensial linear

KEKURANGAN MODEL SEKUENSIAL LINEAR

Masalah yang kadang terjadi ketika model sekuensial linier diaplikasikan adalah :

1. Jarang sekali proyek nyata mengikuti aliran sekuensial yang dianjurkan oleh model. Meskipun model linier bisa mengakomodasi iterasi, model ini melakukannya dengan cara tidak langsung. Sebagai hasilnya, perubahan perubahan dapat menyebabkan keraguan pada saat tim proyek berjalan.

2. Kadang kadang sulit bagi pelanggan untuk menyatakan semua kebutuhannya secara eksplisit. Model linier sekuensial memerlukan halini dan mengalami kesulitan untuk mengakomodasi ketidakpastiannatural yang ada pada bagian awal beberapa proyek.

3. Pelanggan harus bersifat sabar. Sebuah versi kerja dari program program kerja itu tidak akan diperoleh sampai akhir waktu proyek dilalui. Sebuah kesalahan besar, jika tidak terdeteksi sampai program yang bekerja tersebut dikaji ulang, bisa menjadi petaka

KELEBIHAN MODEL SEKUENSIL LINIER

1. software yang dikembangkan dengan metode ini biasanya menghasilkan kualitas yang baik.

2. Document pengembangan sistem sangat terorganisir, karena setiap fase harus terselesaikan dengan lengkap sebelum melangkah ke fase berikutnya.

2.    Pengembangan Prototipe

Prototype adalah sebuah Javascript Framework yang dibuat untuk lebih memudahkan proses dalam membangun aplikasi berbasis web.

Paradigma dari 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.

Model ini digunakan jika customer tidak menjelaskan detail kebutuhan input, proses atau output, sehingga developer tidak dapat memastikan algoritma yang akan dipakai, kesesuaian sistem operasi atau bentuk user interface.

Metode pengembangan perangkat lunak ini dimulai dengan pengumpulan kebutuhan. Pendekatan prototyping model digunakan jika pemakai hanya mendefenisikan secara umum dari perangkat lunak tanpa merinci kebutuhan input, pemrosesan dan outputnya, sementara pengembang tidak begitu yakin akan efisiensi algoritma, adaptasi sistem operasi, atau bentuk antarmuka manusia-mesin yang harus diambil. Cakupan aktivitas dari prototyping model terdiri dari :

1.      Mendefinisikan objektif secara keseluruhan dan mengidentifikasi kebutuhan yang sudah diketahui.

2.      Melakukan perancangan secara cepat sebagai dasar untuk membuat prototype.

3.      Menguji coba dan mengevaluasi prototype dan kemudian melakukan penambahan dan perbaikan-perbaikan terhadap prototype yang sudah dibuat.

Empat langkah yang menjadi karakteristik metode Prototyping yaitu : 

1              1  Pemilihan fungsi

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.

2                    2.   Penyusunan Sistem Informasi

Bertujuan untuk memenuhi permintaan akan tersedianya prototype

      3.   Evaluasi

      4.   Penggunaan Selanjutnya.

Tahapan-tahapan Prototyping :

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

2. Membangun prototyping : Membangun prototyping dengan membuat perancangan sementara yang berfokus pada penyajian kepada pelanggan (misalnya dengan membuat input dan format output)

3. Evaluasi prototyping : Evaluasi ini dilakukan oleh pelanggan apakah prototyping yang sudah dibangun sudah sesuai dengan keinginann pelanggan. Jika sudah sesuai maka langkah 4 akan diambil. Jika tidak prototyping direvisi dengan mengulangu langkah 1, 2 , dan 3.

4. Mengkodekan sistem : Dalam tahap ini prototyping yang sudah di sepakati diterjemahkan ke dalam bahasa pemrograman yang sesuai

5. Menguji sistem : 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 ya, langkah 7 dilakukan; jika tidak, ulangi langkah 4 dan 5.

7. Menggunakan sistem : Perangkat lunak yang telah diuji dan diterima pelanggan siap untuk digunakan.

Jenis-jenis Prototyping

Feasibility prototyping digunakan untuk menguji kelayakan dari teknologi yang akan digunakan untuk system informasi yang akan disusun.

Requirement prototyping digunakan untuk mengetahui kebutuhan aktivitas bisnis user.

Desain Prototyping - digunakan untuk mendorong perancangan system informasi yang akan digunakan.

Implementation prototyping merupakan lanjytan dari rancangan protipe, prototype ini langsung disusun sebagai suatu system informasi yang akan digunakan.

Keunggulan dan Kelemahan Prototyping

Keunggulan Prototyping :

1. End user dapat berpartisipasi aktif

2. Penentuan kebutuhan lebih mudah diwujudkan

3. Mempersingkat waktu pengembangan SI

1. Adanya komunikasi yang baik antara pengembang dan pelanggan

2. Pengembang dapat bekerja lebih baik dalam menentukan kebutuhan pelanggan

3. Pelanggan berperan aktif dalam pengembangan sistem

4. Lebih menghemat waktu dalam pengembangan sistem

5. Penerapan menjadi lebih mudah karena pemakai mengetahui apa yang diharapkannya.

Kelemahan Prototyping :

1. Proses analisis dan perancangan terlalu singkat

2. Mengesampingkan alternatif pemecahan masalah

3. Bisanya kurang fleksible dalam mengahadapi perubahan

4. Prototype yang dihasilkan tidak selamanya mudah dirubah

5. Prototype terlalu cepat selesai

3.     Model Pengembangan RAD (RAPID APPLICATION DEVELOPMENT)

Model RAD adalah model proses pembangunan perangkat lunak yang tergolong dalam teknik increment (bertingkat). RAD menekankan pada siklus pembangunan pendek/singkat/cepat. Waktu yang singkat adalah batasan yang penting untuk model ini.Model RAD ini merupakan sebuah adaptasi ”kecepatan tinggi” dari model waterfall dimana 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. Business 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 memunculkannya? Ke mana informasi itu pergi? Siapa yang memprosesnya?

2. Data modeling

Aliran informasi yang didefinisikan sebagai bagian dari fase business modelling disaring ke dalam serangkaian objek data yang dibutuhkan untuk menopang bisnis tersebut. Karakteristik masing-masing objek diidentifikasikan dan hubungan antara objek-objek tersebut didefinisikan.

3. Proses modeling

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. Application 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 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 dan 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.

Beberapa kelebihan dan kekurangan yang perlu diperhatikan dalam implementasi

pengembangan menggunakan model RAD :

1. Model RAD memerlukan sumber dara yang cukup besar, terutama untuk proyek

dengan skala besar.

2. Model ini cocok untuk proyek dengan skala besar.

3. Model RAD memerlukan komitmen yang kuat antara pengembang dan pemessan,

bahkan keduanya dapat tergabung dalam 1 tim.

4. Kinerja dari perangkat lunak yang dihasilkan dapat menjadi masalah manakala

kebutuhan-kebutuhan diawal proses tidak dapat dimodulkan, sehingga pendekatan

dengan model ini kurang bagus.

5. Sistem yang tidak dapat dimodularisasi tidak cocok untuk model ini.

6. Penghalusan dan penggabungan dari beberapa tim di akhir proses sangat diperlukan

dan ini memerlukan kerja keras.

7. Proyek bisa gagal karena waktu yang disepakati tidak dipenuhi.

8. Resiko teknis yang tinggi juga kurang cocok untuk model ini.

9. Bagi proyek yang besar tetapi berskala, RAD memerlukan sumber daya manusia

yang memadai untuk menciptakan jumlah tim RAD yang baik.

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

11. Tidak cocok untuk proyek skala besar.

12. Proyek dapat gagal karena waktu yang disepakati tidak dipenuhi.

13. Sistem yang tidak dapat dimodularisasi tidak cocok untuk model ini.

14. Resiko teknis yang tinggi juga kurang cocok untuk model ini.

5.1 Rencana Kebutuhan (Requirement Planning)

Pada tahap ini, user dan analyst melakukan semacam pertemuan untuk melakukan identifikasi tujuan dari aplikasi atau sistem dan melakukan identifikasi kebutuhan informasi untuk mencapai tujuan. Pada tahap ini hal terpenting adalah adanya keterlibatan dari kedua belah pihak, bukan hanya sekedar persetujuan akan proposal yang sudah dibuat. Untuk lebih jauh lagi, keterlibatan user bukan hanya dari satu tingkatan pada suatu organisasi, melainkan beberapa tingkatan organisasi sehingga informasi yang dibutuhkan untuk masingmasing user dapat terpenuhi dengan baik. Di samping itu, dapat juga melakukan koordinasi dengan Chief Information Office (CIO) atau bagian perencana strategis terutama untuk mengembangkan suatu aplikasi E-commerce berbasis Web untuk mendapatkan informasi yang lebih detail akan tujuan dari suatu organisasi. Pertemuan semacam ini seringkali disebut Joint Aplication Development.

5.2 Proses Desain (Design Workshop)

Pada tahap ini adalah melakukan proses desain dan melakukan perbaikan-perbaikan apabila masih terdapat ketidaksesuaian desain antara user dan analyst. Untuk tahap ini maka keaktifan user yang terlibat sangat menentukan untuk mencapai tujuan, karena user bisa langsung memberikan komentar apabila terdapat ketidaksesuaian pada desain. Biasanya, user dan analyst berkumpul menjadi satu dan duduk di meja melingkar dimana masing-masing orang bisa melihat satu dengan yang lain tanpa ada halangan.

Apabila memungkinkan, maka masingmasing user diberikan satu komputer yang terhubung satu dengan yang lain, sehingga masing-masing bisa melihat desain yang dibuat dan langsung memberikan komentar. Hal ini sering kali disebut dengan Group Decision Support System (GDSS). Pada beberapa kasus, GDSS ini merupakan suatu langkah yang ideal, karena user dan analyst dapat menyetujui desain yang dibuat untuk kemudian dilanjutkan oleh programmer dalam pembuatan prototype dari aplikasi yang dimaksud dengan langsung menampilkan kepada user hasilnya dengan cepat. Pada tahap desain ini membutuhkan waktu beberapa hari, akan tetapi bisa semakin lebih lama, tergantung dari besar kecilnya sistem yang dibuat. Pada selang waktu tersebut, user bisa memberikan tanggapan akan sistem yang sudah dikembangkan untuk selanjutnya dilakukan perbaikan-perbaikan. Dengan demikian proses pengembangan suatu sistem membutuhkan waktu yang cepat.

5.3 Implementasi (Implementation)

Setelah desain dari sistem yang akan dibuat sudah disetujui baik itu oleh user dan Analyst, maka pada tahap ini programmer mengembangkan desain menjadi suatu program. Setelah program selesai baik itu sebagian maupun secara keseluruhan, maka dilakukan proses pengujian terhadap program tersebut apakah terdapat kesalahan atau tidak sebelum diaplikasikan pada suatu organisasi. Pada saat ini maka user bisa memberikan tanggapan akan sistem yang sudah dibuat serta persetujuan mengenai sistem tersebut. Adapun hal terpenting adalah bahwa keterlibatan user sangat diperlukan supaya sistem yang dikembangkan dapat memberikan kepuasan kepada user, dan di samping itu, sistem yang lama tidak perlu dijalankan secara paralel dengan sistem yang baru.

5.4 Tahapan keseluruhan

Dengan berdasarkan pada tahapantahapan tersebut di atas maka proses utama pengembangan suatu sistem dengan menggunakan metode RAD adalah sebagai berikut :

- Pengembang membuat prototype berdasarkan kebutuhan-kebutuhan yang sudah didefinisikan sebelumnya

- Desainer melakukan penilaian terhadap prototype

- User melakukan uji coba pada prototype dan memberikan masukan mengenai kebutuhan-kebutuhan yang      kurang.

- User dan developer melakukan pertemuan untuk memberikan penilaian terhadap produk secara bersama-      sama, menyesuaikan kebutuhan serta memberikan komentar apabila diperlukan perubahan.

- Semua kebutuhan akan sistem dan perubahan-perubahan yang terjadi dilakukan proses “timeboxed”             dengan mempunyai