Sunday, March 20, 2011

Model Proses

Yang terkandung di dalam post ini:
-Penjelasan tentang Common process Framework
-Jenis-jenis model proses:
1. Linear SequentialModel/ Waterfall Model
2. Evolutionary Software Process Model
-Incremental Model
-Spiral Model
3. RAD (Rapid Application Development)
4. Prototyping Model
5. Component-based Development Model

Proses perangkat lunak dapat dicirikan seperti ditunjukkan dalam gambar di bawah. Suatu kerangka proses yang umum dibentuk dengan penjelasan sejumlah kecil aktivitas kerangka yang digunakan pada semua proyek perangkat lunak, dengan mengabaikan kompleksitas atau ukuran perangkat lunak.

Keterangan Gambar:
Sebuah common process framework di bentuk dengan mendefinisikan sejumlah
· framework activities yang bisa diterapkan untuk semua proyek software, tanpa memandang ukuran dan kompleksitasnya.
· Task Sets, masing-masing berisi kumpulan pekerjaan rekayasa software, project milestone, product software dan deriverable, quality assurance point.
· Dengan adanya task set ini, memungkinkan aktifitas framework diadaptasikan dengan karakteristik proyek software dan kebutuhan tim pelaksana.
· Umbrella Activities seperti software quality assurance, manajemen konfigurasi software.


Model proses merupakan sekumpulan aktifitas yang saling terkait untuk spesifikasi, desain, implementasi dan testing sistem software. Model proses yang paling utama adalah Prescriptive model, dimana model ini mengembangkan kerangka proses dengan serangkaian tugas yang jelas dalam proses rekayasa perangkat lunak. Rangkaian tugas ini meliputi aktivitas kerangka kerja, tindakan rekayasa perangkat lunak, tugas, produk kerja, jaminan kualitas dan mekanisme kontrol pada setiap proyek.

Model Proses ada beberapa:
1. Linear SequentialModel/ Waterfall Model
2. Evolutionary Software Process Model
-Incremental Model
-Spiral Model
3. RAD (Rapid Application Development)
4. Prototyping Model


A.Linear Sequential Model

1. Software Requirements analysis: Mengumpulkan kebutuhan secara lengkap kemudian kemudian dianalisis dan didefinisikan kebutuhan yang harus dipenuhi oleh program yang akan dibangun. Fase ini harus dikerjakan secara lengkap untuk bisa menghasilkan desain yang lengkap.
2. Design: Desain dikerjakan setelah kebutuhan selesai dikumpulkan secara lengkap.
3. Code generation: desain program diterjemahkan ke dalam kode-kode dengan menggunakan bahasa pemrograman yang sudah ditentukan. Program yang dibangun langsung diuji baik secara unit.
4. Testing: penyatuan unit-unit program kemudian diuji secara keseluruhan (system testing).
5. Support: mengoperasikan program dilingkungannya dan melakukan pemeliharaan, seperti penyesuaian atau perubahan karena adaptasi dengan situasi sebenarnya.

Kekurangan yang utama dari model ini adalah kesulitan dalam mengakomodasi perubahan setelah proses dijalani. Fase sebelumnya harus lengkap dan selesai sebelum mengerjakan fase berikutnya.

B. Evolutionary Software Process Model
Model yang termasuk pada Evolutionary Software Process Model adalah :– Incremental Model– Spiral Model

1. Incremental Model

• Merupakan kombinasi dari waterfall model, yaitu dengan melakukan tahap-tahap waterfall model secara iteratif
1. kombinasikan element-element dari waterfall dengan sifat iterasi / perulangan.
2. element-element dalam waterfall dikerjakan dengan hasil berupa produk dengan spesifikasi tertentu, kemudian proses dimulai dari fase pertama hingga akhir dan menghasilkan produk dengan spesifikasi yang lebih lengkap dari yang sebelumnya. Demikian seterusnya hingga semua spesifikasi memenuhi kebutuhan yang ditetapkan oleh pengguna.
3. produk hasil increment pertama biasanya produk inti (core product), yaitu produk yang memenuhi kebutuhan dasar. Produk tersebut digunakan oleh pengguna atau menjalani review/pengecekan detil. Hasil review tersebut menjadi bekal untuk pembangunan pada increment berikutnya. Hal ini terus dikerjakan sampai produk yang komplit dihasilkan.
4. model ini cocok jika jumlah anggota tim pengembang/pembangun PL tidak cukup.
5. Mampu mengakomodasi perubahan secara fleksibel.
6. Produk yang dihasilkan pada increment pertama bukanlah prototype, tapi produk yang sudah bisa berfungsi dengan spesifikasi dasar.

Masalah dengan Incremental model:
1. cocok untuk proyek berukuran kecil (tidak lebih dari 200.000 baris coding)
2. mungkin terjadi kesulitan untuk memetakan kebutuhan pengguna ke dalam rencana spesifikasi masing-masing hasil increment


2. Spiral Model
Model spiral, mula-mula diusulkan oleh Boehm, adalah suatu model proses perangkat lunak evolusiner yang bersifat iteratip berpasangan dari prototip dengan aspek yang sistematis dan terkendali dari linear sequential model.

Proses digambarkan sebagai spiral. Setiap loop mewakili satu fase dari software process. Loop paling dalam berfokus pada kelayakan dari sistem, loop selanjutnya tentang definisi dari kebutuhan, loop berikutnya berkaitan dengan desain sistem dan seterusnya.
1. Customer communication: membangun komunikasi yang baik dengan pengguna/customer.
2. Planning: mendefinisikan sesumber, batas waktu, informasi-informasi lain seputar proyek
3. Risk analysis: identifikasi resiko managemen dan teknis
4. Engineering: pembangunan contoh-contoh aplikasi, misalnya prototype
5. Construction and release : pembangunan, test, install dan support.
6. Customer evaluation: mendapatkan feedback dari pengguna beradasarkan evaluasi PL pada fase engineering dan fase instalasi.

Pada model spiral, resiko sangat dipertimbangkan. Resiko adalah sesuatu yang mungkin mengakibatkan kesalahan. Model spiral merupakan pendekatan yang realistik untuk perangkat lunak berskala besar.
Pengguna dan pembangun bisa memahami dengan baik software yang dibangun karena setiap kemajuan yang dicapai selama proses dapat diamati dengan baik. Namun demikian, waktu yang cukup panjang mungkin bukan pilihan bagi pengguna, karena waktu yang lama sama dengan biaya yang lebih besar.


C. Model Prototyping

Kadang-kadang klien hanya memberikan beberapa kebutuhan umum software tanpa detil input, proses atau detil output. Di lain waktu mungkin dimana tim pembangun (developer) tidak yakin terhadap efisiensi dari algoritma yang digunakan, tingkat adaptasi terhadap sistem operasi atau rancangan form user interface. Ketika situasi seperti ini terjadi model prototyping sangat membantu proses pembangunan software.

Proses pada model prototyping yang digambarkan pada gambar 1, bisa dijelaskan sebagai berikut:
- pengumpulan kebutuhan: developer dan klien bertemu dan menentukan tujuan umum, kebutuhan yang diketahui dan gambaran bagian-bagian yang akan dibutuhkan berikutnya. Detil kebutuhan mungkin tidak dibicarakan disini, pada awal pengumpulan kebutuhan
- perancangan : perancangan dilakukan cepat dan rancangan mewakili semua aspek software yang diketahui, dan rancangan ini menjadi dasar pembuatan prototype.
- 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.

Kekurangan Prototyping
• 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 berkerasterhadap produk tersebut, maka developer harus kerja keras untuk mewujudkanproduk tersebut menjadi lebih baik, sesuai kualitas yang seharusnya.
• Developer biasanya melakukan kompromi dalam beberapa hal karena harus membuat prototype dalam waktu singkat. Misalnya sistem operasi yang tidak sesuai,bahasa pemrograman yang berbeda, atau algoritma yang lebih sederhana.

D. RAD (Rapid Application Development)
RAD adalah model proses pembangunan PL yang incremental. RAD menekankan pada siklus pembangunan yang pendek/singkat. RAD mengadopsi model waterfall dan pembangunan dalam waktu singkat dicapai dengan menerapkan component based construction. Waktu yang singkat adalah batasan yang penting untuk model ini.

Jika kebutuhan lengkap dan jelas maka waktu yang dibutuhkan untuk menyelesaikan secara komplit software yang dibuat adalah misalnya 60 sampai 90 hari.


Fase-fase di atas menggambarkan proses dalam model RAD. Sistem dibagi-bagi menjadi beberapa modul dan dikerjakan dalam waktu yang hampir bersamaan dalam batasan waktu yang sudah ditentukan.
1. Business modelling : menjawab pertanyaan-pertanyaan: informasi apa yang mengendalikan proses bisnis? Informasi apa yang dihasilkan? Siapa yang menghasilkan informasi? Kemana informasi itu diberikan? Siapa yang mengolah informasi? _ kebutuhan dari system
2. Data modelling: aliran informasi yang sudah didefinisikan, disusun menjadi sekumpulan objek data. Ditentukan karakteristik/atribut dan hubungan antar objek-objek tersebut _ analisis kebutuhan dan data
3. Process Modelling : objek data yang sudah didefinisikan diubah menjadi aliran informasi yang diperlukan untukmenjalankan fungsi-fungsi bisnis.
4. Application Generation: RAD menggunakan component program yang sudah ada atau membuat component yang bisa digunakan lagi, selama diperlukan.
5. Testing and Turnover: karena menggunakan component yang sudah ada, maka kebanyakan component sudah melalui uji atau testing. Namun component baru dan interface harus tetap diuji.


Kelemahan dalam model ini:
1. tidak cocok untuk proyek skala besar
2. proyek bisa gagal karena waktu yang disepakati tidak dipenuhi
3. sistem yang tidak bisa dimodularisasi tidak cocok untuk model ini
4. resiko teknis yang tinggi juga kurang cocok untuk model ini

E. Component-based Development Model
Component-based development sangat berkaitan dengan teknologi berorientasi objek. Pada pemrograman berorientasi objek, banyak class yang dibangun dan menjadi komponen dalam suatu software. Class-class tersebut bersifat reusable artinya bisa digunakan kembali. Model ini bersifat iteratif atau berulang-ulang prosesnya.

Secara umum proses yang terjadi dalam model ini adalah:

1. identifikasi class-class yang akan digunakan kembali dengan menguji class tersebut dengan data yang akan dimanipulasi dengan aplikasi/software dan algoritma yang baru
2. Class yang dibuat pada proyek sebelumnya disimpan dalam class library, sehingga bisa langsung diambil dari library yang sudah ada. Jika ternyata ada kebutuhan class baru, maka class baru dibuat dengan metode berorientasi objek.
3. bangun software dengan class-class yang sudah ditentukan atau class baru yang dibuat, integrasikan.

No comments:

Post a Comment