Minggu, 02 Agustus 2009

ANSI

ANALISA SISTEM INFORMASI

MARDIANA

(08201028)

Software Proses Model

Proses model didefinisikan sebagai sekumpulan aktivitas, action, task, millstone dan work product yang dibutuhkan untuk menghasilkan software berkualitas tinggi. Proses model menyediakan peta untuk kerja software engineering. Setiap proses model harus diterapkan sehingga proses model dapat digunakan secara efektif untuk project software tertentu. Dari sudut pandang software engineer, work product adalah program, dokumen dan data yang dihasilkan sebagai hasil aktivitas dan tugas-tugas yang ditentukan oleh proses. Kualitas, ketepatan waktu dan kelangsungan hidup produk yang dibuat merupakan indikator penilaian software proses.

Akan dijelaskan beberapa macam model :

· Waterfall model

· Prototyping Model

· Rapid Application Development (RAD) Model

· Incremental Model

· Spiral Model

· Agile Method Model

· Extreme Programming

· Formal Method Model

· Model 4GT


Waterfall model

Waterfall Model

Gambar 1. Waterfall Model

Waterfall model dimulai dari analisa kebutuhan user, kemudian design sistem, implementasi, uji coba dan maintenance. Penerapan model waterfall dapat gagal dikarenakan : (1). perubahan pada salah satu fase dapat membinggungkan cara kerja project team, (2). kadang sulit bagi customer untuk menyebutkan kebutuhannya secara jelas pada fase requirement definition, (3). Hasil program dapat terlihat sampai akhir dari fase, sehingga kesalahan baru dapat terlihat ketika program sudah jadi.

Karena waterfall merupakan linear model maka beberapa project team harus menunggu anggota team yang lain. Jika terjadi penambahan maka harus kembali ke awal fase, jika kebutuhan user belum pasti atau jelas, maka tidak dapat mengerjakan fase berikutnya (meloncat), jika bekerja dalam team harus menunggu. Pada bagian analisis selesai, kemudian dilanjutkan oleh team lain di fase design. Waktu yang dihabiskan untuk menunggu dapat meningkatkan time spent produktivitas kerja. Model ini cocok untuk project yang kebutuhan user sudah jelas (tidak ada penambahan atau pengurangan requirement).

Prototyping Model

prototypingmodel

Gambar 2. Prototyping Model

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. Prototyping model dimulai dengan mendengarkan kebutuhan user. Engineer dan customer bertemu dan menentukan semua tujuan software dan menentukan kebutuhan-kebutuhan. Developer kemudian membangun prototype dan user menguji coba prototype untuk memberikan feedback. Prototype dapat dijalankan sebagai sistem yang pertama. User bisa mendapatkan pengertian dari sistem yang sesungguhnya dan developer dapat membangun sistem dengan segera. Kekurangan : kontrak akan merugikan, dirugikan oleh keinginan customer yang meminta penambahan-penambahan. Kelebihan : akan mengurangi waktu pembuatan program, kebutuhan customer akan lebih terpenuhi dengan baik, jika kebutuhannya belum jelas, maka dengan prototype akan lebih menguntungkan.


Rapid Application Development (RAD) Model

RAD Model

Gambar 3. RAD Model

RAD merupakan incremental software process yang menekankan pada siklus development yang singkat. Model ini mengunakan pembuatan berdasarkan komponen, menekankan penggunaan kembali code dan code generation. Jika requirement telah diketahui dengan pasti dan scope project mendesak, RAD proses memungkinkan team development untuk sistem fungsional keseluruhan dalam periode waktu yang sangat singkat (misalnya 60-90 hari). RAD model dapat digunakan untuk project yang dapat dipisah, misalnya ada 1 project besar, dibagi 3, dikerjakan oleh team yang berbeda-beda (dari analisis sampai testing) kemudian diintegrasikan. Jika menggunkan RAD model, kualitas team harus solid dan punya disiplin tinggi. Kekurangan : (1). untuk project yang besar dan membutuhkan sumber daya manusia yang cukup. (2) Jika developer dan customer berkomitmen untuk menyelesaikan project dalam waktu yang singkat, maka project akan gagal. (3). Jika pemodulan project tidak tepat, maka pembangunan komponen untuk RAD akan bermasalah.


Incremental Model

Incremental Model

Gambar 4. Incremental Model

Incremental model menerapkan rangkaian linear. Setiap rangkaian linear mendelivery increment dari software. Sebagai contoh, software word-processing, dibangun menggunakan incremental model, mendelivery fungsi dasar file management, editing, dan fungsi document production pada increment pertama. Kemampuan editing, dan fungsi document production yang lebih baik pada increment kedua, checking dan grammar spelling pada increment ketiga. Proses akan diulangi sampai produk yang lengkap telah dihasilkan. Jika menggunakan Incremental model, increment yang pertama merupakan inti product. Incremental model fokus pada pendeliverian opertional product pada tiap increment.


Spiral Model

Spiral ModelGambar 5. Spiral Model.

Track spiral menggambarkan jalur pembangunan software, termasuk siklus berulang dari diskusi, design, implementasi, dan testing. Menggunakan pendekatan ini, software dihasilkan dalam bentuk rangkaian incremental release. Keuntungan : model mendorong dialog yang berkelanjutan antara software engineer dan user, software requirement ditetapkan kembali seiring progres project, sistem software diserahkan terus-menerus sebagai serangkaian modul kerja, perkiraan (budget, jadwal) dapat lebih relistik, karena kebutuhan-kebutuhan yang penting sudah ditemukan pada bagian awal.

Spiral model sering digunakan untuk project yang besar. Untuk project yang lebih kecil digunakan agile software development. Pada implementasinya, model spiral ini juga banyak digunakan, tetapi biasanya dikombinasikan dengan model yang lain. Pemodelan waterfall, yang sangat bagus dalam menentukan millestones dan pemodelan spiral, yang sangat bagus dengan menggunakan prototyping, merupakan kombinasi yang sering dipakai di dalam kontrak-kontrak untuk perangkat lunak dewasa ini.

Agile Method Model

Agile method model berdasarkan asumsi : (1). Sulit untuk memperkirakan requirement customer. (2). Sulit untuk memeperkirakan seberapa penting design sebelum pembuatan. (3). Analisis, desain, pembuatan dan testing tidak dapat diramalkan. Beberapa agile process model : Extreme Programming (XP), Adaptive Software Development (ASD), Dynamic Systems Development Method (DSDM), Scrum, Crystal, Feature Driven Development (FDD), Agile Modeling (AM).

Extreme Programming

XP menekankan pada nilai simplicity, komunikasi, feedback dan keberanian. XP terdiri dari empat aktivitas : planning, desain, coding dan testing.

Extreme Programming

Gambar 6. Extreme Programming Model

Planning. Aktivitas planning dimulai dengan membentuk user stories yang menggambarkan fitur dan fungsional software yang dibutuhkan. Setiap story dibuat oleh customer dan diletakkan dalam index card. Customer memberikan value (misal prioritas) ke story berdasarkan keseluruhan fitur dan fungsi. Anggota XP team kemudian menilai setiap story dan menentukan cost – diukur dalam development week. Jika story membutuhkan 3 development week, customer akan membagi story kedalam story-story kecil, dan menetapkan value dan cost lagi. Customer dan XP team bekerja bersama untuk memutuskan bagaimana grup story untuk release berikutnya (software increment berikutnya) untuk dibangun oleh XP team. Jika komitmen telah dibuat, XP team akan membangun story-story dengan cara : (1). Semua story segera diimplemetasikan (dalam beberapa minggu) (2). Story dengan value tertinggi akan dipindahkan dari jadwal dan dimplementasikan pertama. (3). Story dengan resiko paling tinggi akan diimplemetasikan lebih dulu. Setelah project pertama direlease dan didelivery, XP team memperhitungkan kecepatan project. Selama development, customer dapat menambah story, merubah value, membagi story atau menghapusnya. Design. XP menggunakan CRC card, untuk mengenali dan mengatur object oriented class yang sesuai dengan software increment. Coding. Sebelum membuat code, lebih baik membuat unit test tiap story untuk dimasukkan dalam software increment. XP menyarankan agar dua orang bekerja bersama pada satu komputer workstation untuk membuat code dari satu story (pair programming), untuk menyediakan real time problem solving dan jaminan real time quality. Setelah pair programming selesai, code diintegrasikan dengan kerja laiinnya (continuous integration). Testing. Unit test yang telah dibuat harus diimplementasikan menggunakan suatu framework dan diatur ke dalam universal testing suite, integrasi dan validasi sistem dapat dilakukan setiap hari. Customer test (acceptance test) dilakukan oleh customer dan fokus pada keseluruhan fitur dan fungsional sistem. Acceptance test diperoleh dari customer stories yang telah diimplemetasikan sebagai bagian dari software release.

Formal Method Model

Model ini memungkinkan software engineer untuk membuat spesifikasi lebih lengkap, konsisten dan tidak ambigu menggunakan teknik-teknik matematika. Jika model ini digunakan, hasilnya berupa spesifikasi yang digambarkan dalam formal langguage seperti OCL atau Z. Jika formal method digunakan selama development, metode ini menyediakan mekanisme untuk menghapuskan masalah yang sulit untuk diatasi menggunakan paradigma software engineering lainnya. Ambiguitas, ketidaklengkapan, ketidaksesuaian dapat ditemukan dan dapat dibenarkan lebih mudah. Jika formal method digunakan selama design, metode ini sebagai verifikasi program, sehingga software engginer dapat menemukan dan membenarkan error yang mungkin tidak ditemukan. Metode ini belum banyak digunakan karena memakan banyak waktu dan mahal, banyak developer mempunyai kemampuan rendah, sehingga diperlukan training yang intensif, sulit untuk digunakan sebagai alat untuk berkomunikasi dengan user.

PENDEKATAN 4GT

The Fourth Generation Technique (4GT) is based on NPL that is the Non-Procedural Language techniques. Keempat Generasi Teknik (4GT) didasarkan pada NPL yang merupakan Non-Bahasa teknik prosedural. Depending upon the specifications made, the 4GT approaches uses various tools for the automatic generation of source codes. Tergantung pada spesifikasi yang dibuat, dengan menggunakan berbagai pendekatan 4GT alat otomatis untuk generasi kode sumber. It is the vital tool which uses the non-procedural language for Report generation, Database query, Manipulation of data, Interaction of screen, Definition, Generation of code, Spread Sheet capabilities, High level graphical capacity etc. Ini merupakan alat vital yang menggunakan bahasa non-prosedural untuk generasi Lapor, permintaan Database, Manipulasi data, Interaksi dari layar, Definisi, Generasi kode, Spread Sheet kemampuan, kemampuan grafis tingkat tinggi dll

Like any other models used, the 4GT approach requires the requirement analysis step. Seperti model lain yang digunakan, pendekatan 4GT yang membutuhkan langkah analisis kebutuhan. Once the requirement analysis is done upto the expectations, its translation into the operational prototype begins. Setelah dilakukan analisis kebutuhan upto harapan, dan terjemahan ke dalam operasional prototipe dimulai. The most important phase in the 4GT approach is the customer developer approach, all the major decisions regarding the implementations, costs and functioning of the system is taken in this phase. Yang paling penting dalam tahap pendekatan 4GT adalah pelanggan pengembang pendekatan, semua keputusan utama tentang implementasi, biaya dan fungsi dari sistem ini diambil dalam tahap ini.

The Fourth Generation Technique (4GT) is usually successful in implementing smaller applications as we can easily switch from the requirement analysis phase to the implementation phase. Keempat Generasi Teknik (4GT) biasanya berhasil dalam menerapkan aplikasi kecil seperti yang kita dapat dengan mudah beralih dari kebutuhan analisis tahap ke tahap pelaksanaan. Prototypes of any applications can be easily developed with the help of the 4GT approach. Prototip dari setiap aplikasi dapat dengan mudah dikembangkan dengan bantuan dari 4GT pendekatan. This prototype helps the clients to give a rough idea of how the system will look when it is done. Prototipe ini membantu klien untuk memberikan gambaran kasar tentang bagaimana sistem akan terlihat jika dilakukan. The 4GT model is very useful approach in small projects but it is not a dominant approach for large software development. 4GT model yang sangat berguna dalam pendekatan proyek-proyek kecil namun ini bukan merupakan pendekatan dominan besar untuk pengembangan piranti lunak.

Tidak ada komentar:

Posting Komentar