Selasa, 10 Maret 2009

Requirement Analisys Model Rational Unified Process

Analisa Kebutuhan [ Requirement Analysis ]

Tujuan Analisa Kebutuhan adalah mendeskripsikan sistem apakah yang harus dilakukan, memungkinkan pengembang dan konsumen sepakat pada deskripsi tersebut. Untuk mencapai ini, kami mendapatkan, mengelola, dan mendokumentasikan fungsionalitas dan batasan yang diperlukan, melacak dan mendokumentasikan bisnis proses dan keputusan.
Dokumen visi dibuat dan kebutuhan stakeholder didapatkan. Aktor diidentifikasi, mewakili pengguna, dan sistem lain yang dapat berinteraksi dengan sistem yang dikembangkan. Use cases diidentifikasi, mewakili perilaku sistem. Dikarenakan Use cases dikembangkan menurut kebutuhan aktor, sistem cenderung lebih relevan pada pengguna. Gambar berikut menunjukkan contoh model use-case untuk satu sistem daur ulang mesin.


Setiap use case dijabarkan secara rinci. Deskripsi use case menunjukkan bagaimana sistem berinteraksi tahap demi tahap dengan aktor dan apa yang dilakukan sistem. Persyaratan non fungsional dijabarkan dalam Spesifikasi Pelengkap.
Fungsi use case sebagai pemersatu dari keseluruhan sistem pada siklus pengembangan. Model use case digunakan selama mengungkap, menganalisa dan mendesain, dan menguji persyaratan.
Pemodelan use case terdiri dari 3 macam komponen, yaitu sebagai berikut :
Use case, yaitu menggambarkan sistem dengan Actor
Actor, yaitu orang atau sistem luar yang terlibat atau yang terkait dengan sistem yang akan dikembangkan.
Scenario, yaitu deskripsi lebih detail dari use case dalam menggambarkan interaksi antara sistem dengan actor. Jika use case mempunyai lebih dari satu interaksi maka dapat juga dideskripsikan scenario alternatif. Kadang-kadang penggambaran diagram use case tidak dilengkapi dengan scenario.
Dari beberapa fase yang ada , tiap fase memiliki suatu major milestone yang menandakan akhir dari awal dari phase selanjutnya dan dapat terdiri dari beberapa iterasi. Dimensi ini terdiri atas Inception, Elaboration, Construction, dan Transition.



Milestones

1. Inception
1.1 Evaluation Criteria
Persetujuan stakeholder atas definisi ruang lingkup dan biaya atau jadwal
memperkirakan :
• Kesepakatan atas sekumpulan kebutuhan telah dibuat dan ada pemahaman bersama tentang kebutuhan-kebutuhan tersebut.
• Kesepakatan bahwa perkiraan biaya atau jadwal, prioritas, resiko dan proses pengembangan sudah tepat.
• Semua resiko telah diidentifikasikan dan ada strategi penangan untuk setiap resiko tersebut.
Proyek mungkin akan dibatalkan atau dipertimbangkan kembali jika gagal mencapai milestone ini.

1.2 Artifacts



2. Elaboration
Akhir fase elaborasi adalah milestone proyek ke dua yang terpenting. Pada
titik ini dilakukan pendefinisian tujuan dan ruang lingkup system secara detil,
pilihan arsitektur dan resolusi terhadap resiko utama.

2.1 Evaluation Criteria
• Vision dan kebutuhan produk stabil.
• Arsitektur stabil.
• Pendekatan utama yang digunakan dalam pengujian dan evaluasi sudah terbukti.
• Pengujian dan evaluasi terhadap prototype yang dapat ieksekusi telah menunjukan elemen yang berisiko tinggi telah diperiksa dan diresolve dengan baik.
• Rencana iterasi untuk fase konstruksi cukup detil dan rinci sehingga memungkinkan pekerjaan mulai dilaksanakan.
• Rencana iterasi untuk fase konstruksi didukung dengan perkiraan yang matang.
• Semua stakeholders setuju bahwa vision sekarang dapat dipenuhi jika rencana yang telah disusun di eksekusi untuk mengembangkan system yang lengkap, dalam konteks arsitektur yang ada saat ini.
• Penggunaan sumber daya actual vs yang direncanakan masih dapat diterima
Proyek ini mungkin dapat dibatalkan atau dipertimbangkan untuk diperbaiki jika gagal mencapai milestone ini.

2.2 Artifacts



3 Construction
3.1 Evaluation Criteria
Kriteria evaluasi untuk fase konstruksi adalah jawaban atas pertanyaan berikut:
• Apakah product release yang bersangkutan sudah cukup stabil dan matang untuk dideploy di lingkungan pengguna?
• Apakah semua stakeholders siap untuk melakukan proses transisi dalam lingkungan pengguna?
• Apakah pengguna sumber daya secara aktual vs yang direncanakan masih dapat diterima?
Transisi mungkin harus ditunda karena satu release jika proyek gagal mencapai milestone ini

3.2 Artifacts



4 Transition
4.1 Evaluation Criteria
Kriteria evaluasi untuk fase transisi adalah jawaban atas pertanyaan berikut :
• Apakah pengguna puas ?
• Apakah penggunaan aktual sumber daya vs rencana dapat diterima ?

4.2 Artifacts



5. Training and Resources

Tim pengembang harus sudah memahami konsep RUP dan pengelolaan kebutuhan system dengan menggunakan metodologi RUP, software yang digunakan adalah Requisite Pro dan Rational Rose.

Tidak ada komentar:

Posting Komentar