Blog-Cade

Just another blog.ugm.ac.id weblog

Metode Pengembangan Perangkat Lunak

1. PENGEMBANGAN PERANGKAT LUNAK DENGAN MODEL WATERFALL

Model Waterfall adalah suatu proses pengembangan perangkat lunak berurutan, di mana kemajuan dipandang sebagai terus mengalir ke bawah (seperti air terjun) melewati fase-fase perencanaan, pemodelan, implementasi (konstruksi), dan pengujian. Berikut adalah gambar pengembangan perangkat lunak berurutan/ linear (Pressman, Roger S. 2001):

Gambar Pengembangan Perangkat Lunak Linear

Berikut adalah langkah-langkah pengembangan perangkat lunak dengan model waterfall:

1. Scope

Kegiatan awal pada perencanaan adalah penentuan scope. Pernyataan scope mencakup data, fungsi, dan perilaku yg harus diimplementasikan, performance dan constrain serta informasi-informasi pendukung lainnya

2. Software Requirement (Kebutuhan Perangkat Lunak)

Requirement adalah gambaran dari layanan (services) dan batasan bagi sistem yang akan dibangun.

Pengumpulan requirement

  • Interviews : Memberi informasi yang terbaik,mahal.
  • Questionnaires: Bagus jika banyak orang terlibat dan tersebar, respon cenderung kurang baik.
  • Observation: Akurat jika dilakukan dengan baik, mahal.
  • Searching: Informasi terbatas, cenderung tidak menampilkan hal-hal yang mungkin jadi masalah.

Beberapa macam requirement:

  • User Requirement (Kebutuhan Pengguna)

Pernyataan tentang layanan yang disediakan sistem dan tentang batasan-batasan operasionalnya. Dilengkapi dengan gambar/diagram yang dapat dimengerti dengan mudah.

  • System Requirement (Kebutuhan Sistem)

Sekumpulan layanan/kemampuan sistem dan batasan-batasannya yang ditulis secara detil. Ini bisa berlaku sebagai kontrak antara klien dan pembangun.

  • Software Requirement Specification (Spesifikasi Kebutuhan Perangkat Lunak)

Gambaran abstrak dari rancangan perangkat lunak yang menjadi dasar bagi perancangan dan implementasi yang lebih detil

3. Analisa

Tujuan analisa adalah sebagai berikut:

  • Mengambarkan kebutuhan pelanggan,
  • Membangun dasar-dasar untuk proses desain perangkat lunak,
  • Mendefinisikan semua kebutuhan pelanggan sesuai dengan lingkup kontrak yang disepakati kedua belah pihak.

Gambar Struktur Pemodelan Analisa

Gambar diatas adlah gambar struktur pemodelan analisa (Pressman, Roger S. 2001) yang menggambarkan bahwa pemodelan analisa terdiri dari 3 bagian yaitu pemodelan data, pemodelan fungsional, dan pemodelan kelakuan.

Pemodelan Data adalah mendeskripsikan data yang terlibat dalam PL yang terdiri dari:

  • Data Object Description
    Yaitu deskripsi atribut dari setiap objek data.
  • Entity Relationship Diagram
    Yaitu diagram keterhubungan antar objek data.
  • Data Dictionary
    Yaitu deskripsi semua objek data yang dibutuhkan maupun dihasilkan oleh perangkat lunak.

Pemodelan Fungsional adalah mendeskripsikan seluruh fungsi yang terlibat dalam perangkat lunak yang terdiri dari:

  • Data Flow Diagram
  • Menggambarkan bagaimana data ditransformasikan pada perangkat lunakdan enggambarkan fungsi-fungsi yang mentransformasikan data.

  • Process Specification
  • Berisi deskripsi dari setiap fungsi yang muncul pada DFD.

Pemodelan Status/Kelakuan adalah mendeskripsikan status sistem yang dapat muncul ketika perangkat lunak digunakan atau mendeskripsikan kelakuan sistem.

  • State Transition Diagram
  • Control Specification

4. Perancangan

Perancangan perangkat lunak adalah proses dimana analisa diterjemahkan menjadi “cetak-biru” untuk membangun perangkat lunak. Awalnya, cetak biru menggambarkan pandangan menyeluruh perangkat lunak. Yaitu, desain diwakili pada tingkat abstraksi tinggi-tingkat yang dapat langsung ditelusuri pada sistem tertentu objektif dan data yang lebih rinci, fungsional, dan perilaku persyaratan. Seperti terjadi pengulangan desain, perbaikan berikutnya mengarah pada representasi desain yang jauh lebih rendah tingkat abstraksi.

Berikut adalah gambar hubungan pemodelan antara analisa dan pemodelan perancangan (Pressman, Roger S. 2001):

Gambar Hubungan Antara Analisa dan Perancangan
Prinsip perancangan perangkat lunak:

  • Siap dengan alternatif solusi.
  • Perancangan yang dibuat bisa dilacak sampai ke model analisis.
  • Untuk bagian-bagian yang berpola sama gunakan komponen yang sudah ada. Ini sering disebut : reuse design component.
  • Struktur perangkat lunak sebisa mungkin mendekati struktur domain yang sebenarnya.
  • Perancangan sebaiknya menampilkan keseragaman dan kesatuan.
  • Perancangan harus terstruktur dan mudah menerima perubahan.
  • Mampu mengatasi kejadian tidak normal dengan baik.
  • Perancangan tidak sama dengan pengkodean.
  • Kualitas perangkat lunak harus sudah terlihat dari perancangan.
  • Perancangan, sebelum dikodekan, perlu diuji untuk mengurangi kesalahan.

Metode Perancangan:

  • Perancangan Data
  • Yaitu transformasi model data yang dihasilkan oleh proses analisis menjadi struktur  data yang dibutuhkan pada saat implementasi.

    Hasil perancangan data adalah:

    • struktur data siap diprogram
    • struktur basis data siap dibuat oleh pemrogram
    • prosedur/operasi untuk mengakses data, siap diprogram

    Perancangan Arsitektur
    Yaitu definisi keterkaitan antar elemen-elemen utama yang akan membentuk program.

    Hasil perancangan arsitektural:

    Structure Chart yang merepresentasikan gambaran menyeluruh struktur/ arsitektur perangkat lunak, beserta seluruh hierarki kendali/passing parameter, yang siap dituliskan dalam bentuk modul program.

  • Perancangan Antarmuka
  • Yaitu penjabaran komunikasi: internal perangkat lunak, antara perangkat lunak, dengan sistem diluarnya, dan antara perangkat lunak dengan usernya.

    Hasil perancangan antarmuka adalah:

    • definisi antarmuka modul yang siap untuk diprogram
    • definisi / format rancangan layar yang siap diimplementasikan
  • Perancangan Prosedur
  • Yaitu transformasi elemen struktural dari arsitektur program menjadi deskripsi prosedur.

    Hasil perancangan prosedur adalah:

    – Flow-chart

    – Algoritma/pseudocode/program design language

5. Implementasi

Implementasi perangkat lunak adalah melaksanakan,eksekusi, atau praktek dari rencana, metode, atau desain dalam pengembangan perangkat lunak.

Pada tahap ini dilakukan kerja untuk membangun perangkat lunak berdasarkan analisa dan pemodelan yang telah dilakukan. Sehigga hasil dari tahap ini adalah basis data dan source code perangkat lunak.

6. Pengujian

Setelah source code dihasilkan, perangkat lunak harus diuji untuk menemukan (dan membenarkan) sebanyak mungkin kesalahan yang dibuat.

Pengujian perangkat lunak adalah penyelidikan empiris para pemangku kepentingan untuk menyediakan informasi mengenai kualitas perangkat lunak yang diuji. Pengujian perangkat lunak juga menyediakan pandangan independen dari perangkat lunak yang objektif untuk memungkinkan bisnis untuk menghargai dan memahami risiko pada pelaksanaan perangkat lunak.

Teknik uji meliputi, tetapi tidak terbatas pada, proses eksekusi sebuah program atau aplikasi dengan tujuan menemukan bug perangkat lunak.

Metode pengetesan:

1. Black box testing

Black box testing memperlakukan pengujian perangkat lunak sebagai “kotak hitam” – tanpa pengetahuan tentang pelaksanaan internal.

2. White box testing

White box testing adalah ketika penguji memiliki akses ke struktur data internal dan algoritma termasuk source code.

2. PENGEMBANGAN PERANGKAT LUNAK DENGAN MODEL PROTOTYPING

Dahulu, rancangan fisik merupakan proses yang menggunakan kertas dan pinsil. Seorang analis mengambarkan tata letak atau struktur dari output, input, basis data, dan aliran hubungan dan prosedur. Ini merupakan proses yang memakan waktu yang memiliki kemungkinan terjadinya kesalahan. Biasanya hasil dari rancangan kertas ini adalah tidak lengkap dan tidak akurat. Sekarang, banyak analis dan perancang memilih Prototyping, sebuah pendekatan berbasis rekayasa (engineering) untuk merancang. Pendekatan Prototyping adalah proses iterative yang melibatkan hubunan kerja yang dekat antara perancang dan pengguna.

Pressman (2001) menyatakan bahwa seringkali seorang pelanggan mendefinisikan serangkaian sasaran umum bagi perangkat lunak, tetapi tidak mengidentifikasi kebutuhan input, pemrosesan, ataupun output detail. Pada kasus yang lain, pengembang mungkin tidak memiliki kepastian terhadap efisiensi algoritme, kemapuan penyesuaian dari sistem operasi, atau bentuk-bentuk yang harus dilakukan oleh interaksi manusia dan mesin. Dalam situasi seperti ini salah satu model yang cocok digunakan adalah model prototype (Prototyping paradigm). Model Prototype dapat dilihat pada gambar dibawah ini.

Gambar 1 Prototype Paradigm

Pendekatan Prototyping melewati tiga proses, yaitu pengumpulan kebutuhan, perancangan, dan evaluasi Prototype.  Proses-proses tersebut dapat dijelaskan sebagai berikut:

  1. Pengumpulan kebutuhan: developer dan klien bertemu dan menentukan tujuan umum, kebutuhan yang diketahui dan gambaran bagian-bagian yang akan dibutuhkan berikutnya;
  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. Sekalipun prototype memudahkan komunikasi antar developer dan klien, membuat klien mendapat gambaran awal dari Prototype. Pendekatan ini memiliki beberapa keuntungan :

  1. 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.
  2. 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.
  3. Prototyping mematahkan folosofi “end user tidak mengetahui secara detail apa yang dibutuhkan sampai mereka melihat implementasinya”
  4. Prototyping adalah model aktif, tidak pasif, sehingga end user dapat melihat, merasakan, dan mengalaminya.
  5. Kesalahan yang terjadi dalam prototyping dapat dideteksi lebih dini
  6. Prototyping dapat meningkatkan kreatifitas karena membolehkan adanya feedback dari end user.  Hal ini akan memberikan solusi yang lebih baik.
  7. Prototyping mempercepat beberapa fase hidup dari programmer.

McLeod dan Schell (2001) mengemukakan bahwa alasan-alasan pemakai maupun spesialis informasi menyukai model prototype adalah:

  1. Komunikasi antara analis sistem dan pemakai membaik;
  2. Analis dapat bekerja dengan lebih baik dalam menemukan kebutuhan pemakai;
  3. Pemakai berperan lebih aktif dalam pengembangan sistem;
  4. Spesialis informasi dan pemakai menghabiskan lebih sedikit waktu dan usaha dalam mengembangkan sistem;
  5. Implementasi menjadi lebih mudah karena pemakai mengetahui sistem yang diharapkan.

Tetapi, terdapat beberapa kelemahan dari prototyping, kelemahan tersebut antara lain :

  1. Prototyping memungkinkan terjadinya pengembalian terhadap kode, implementasi, dan perbaikan siklus hidup yang dugunakan untuk mendominasi sistem informasi.
  2. Prototyping tidak menolak kebutuhan dari fase analisis sistem. Prototype hanya dapat memecahkan masalah yang salah dan memberi kesempatan sebagai sistem pengembangan konvensional.
  3. Perancangan issu numerik tidak dialamaykan oleh prototyping. Isu tersebut dapat dilupakan jika pengguna tidak berhati-hati.
  4. Prototyping dapat mengurangi kreatifitas perancangan.

Prototyping terkadang dapat memberikan performansi yang lambat, membantu mendapatkan kebutuhan detil lebih baik namun demikian Prototype juga menimbulkan masalah:

  1. Dalam membuat prototype banyak hal yang diabaikan seperti efisiensi, kualitas,  kemudahan dipelihara/dikembangkan, dan kecocokan dengan lingkungan yang sebenarnya. Jika klien merasa cocok dengan prototype yang disajikan dan berkeras terhadap produk tersebut, maka developer harus kerja keras untuk mewujudkan produk tersebut menjadi lebih baik, sesuai kualitas yang seharusnya.
  2. Developer biasanya melakukan kompromi dalam beberapa hal karena harus membuat prototype dalam waktu singkat. Mungkin sistem operasi yang tidak sesuai, bahasa pemrograman yang berbeda, atau algoritma yang lebih sederhana.
  3. Agar model ini bisa berjalan dengan baik, perlu disepakati bersama oleh klien dan developer bahwa prototype yang dibangun merupakan alat untuk mendefinisikan kebutuhan software.
refrences :
  • http://blog.ariefapriandi.com/pengembangan-perangkat-lunak-dengan-model-waterfall
  • http://ali.misri07.student.ipb.ac.id/2010/06/23/model-pengembangan-perangkat-lunak-prototyping/
Categories: ARSI