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.

Rational Unified Process (RUP)‏

Merupakan suatu metode rekayasa perangkat lunak (RPL) dikembangkan dengan mengumpulkan berbagai best practises yang terdapat dalam industri pengembangan perangkat lunak. Ciri utama metode ini adalah menggunakan use-case driven dan pendekatan iteratif untuk siklus pengembangan perankat lunak....RUP gunakan konsep object oriented, dengan aktifitas yang berfokus pada Unified Model Language (UML).

Keunggulan metodologi bekerja berorientasi obyek dibandingkan dengan metodologi prosedural yang banyak dipakai di era jadul (jaman dahulu) adalah setiap kegiatan yang termasuk di dalamnya dapat dilakukan secara paralel, sehingga dapat mempersingkat waktu dan menghemat sumber daya yang ada dibandingkan dengan metodologi berorientasi prosedural yang menuntut diselesaikannya dengan baik dari setiap tahapan kegiatan. Jika kemudian terdapat kekurangan/kesalahan di fase sebelumnya maka kemungkinan besar harus diulang dari awal dalam proses pekerjaannya.

Rational Unified Process (RUP) yaitu suatu metode rekayasa software yang dikembangkan dari kumpulan berbagai best practises yang ada di industri pengembangan software. Ciri dari metode ini adalah menggunakan use-case driven dan pendekatan iteratif untuk siklus software software. Konsep RUP sendiri adalah object oriented, dengan aktifitas yang berfokus pada pengembangan model yang menggunakan UML. Untuk lebih jelas dapat digambarkan sebagai berikut :



Gambar Arsitektur Rational Unified Process

Melalui gambar dapat dilihat bahwa RUP memiliki, yaitu:

* Dimensi pertama digambarkan secara horizontal. Digambarkan dalam beberapa fase, tiap fasenya 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.

* Dimensi kedua digambarkan secara vertikal. mewakili aspek-aspek statis dari proses pengembangan software yang dikelompokkan ke dalam beberapa workflow. ini terdiri atas Business Modeling, Requirement, Analysis and Design, Implementation, Test, Deployment, Configuration dan Change Manegement, Project Management, Environtment.

Hubungan antara Dimensi pertama dan yang kedua sebagai berikut
1. Pada fase Inception
Pada fase ini akan dikerjakan beberapa workflow(disipin). pada Business modeling developer menguraikan visi organisasi dan bagaimana caranya menggunakan visi ini sebagai dasar proses dengan kata lain membuat business casenya. Pada Requirement developer dapat mengetahui permintaan dari user. Pada analysis & design developer harus dapat benar-benar mengerti akan keinginan dari user agar dan dapat membuat design sesuai dengan yang dibutuhkan. Jika analysis sudah mantap developer dapat mengimplentasikan designnya di tahap Implementation dan pengetesan sudah di mulai dilakukan namun belum sampai ke tahap deployment(pengembangan). Pada fase ini Configuration dan Change Manegement sudah mulai digunakan karena terhubung dengan Implentation yang berguna sebagai validasi. Project Management diperlukan pada inception untuk mengatur kerja dari project itu, serta memperhatiakan ruang lingkup ataupun lingkungan agar dapat menciptakan good business sense sehingga proyek dapat dilanjutkan

2. Pada fase Elaboration
Pada fase ini masih terdapat perancangan software dengan menspesifikasikan fitur software sampai perilisan prototipe versi Betha, pada workflows business modeling dan requirement. Workflow yang paling dominan pada fase ini adalah analysis & design dan implementation karena pada fase ini pembuatan program mulai difokuskan sehingga sepanjang tahap ini dilakukan pengetesan pada workflow test. Di fase elaboration ini dimulai pengembangan jika terdapat kekurangan pada sistem tersebut yang dilakukan pada workflow deployment. Configuration dan Change Manegement, Project Management, Environtment seperti pada gambar diatas menunjukan adanya peningkatan karena dipengaruhi kebutuhan dari software itu sendiri agar sesuai dengan yang diharapkan.

3. Pada fase Construction
Pada fase ini implementasian rancangan software yang telah dibuat hampir selesai boleh dikata 75% sehingga terlihat pada grafik semakin menurun grafiknya pada workflows business modeling dan requirement. Workflows analysis & design terlihat naik turun karean disesuaikan dengan kebutuhan karena pada tahap ini sangat terfokus pada workflows implementation, test and deployment. Maka grafik ketiganya sangat bedsar dan meningkat dibandingkan dengan yang lain. Untuk configuration and change management pada tahap ini pun meningkat untuk menyesuaikan dengan implementsainya agar validasi sistem benar terelasasi, karena kekonsistenan data sangatlah diperlukan dan berpengaruh. Pada akhir tahap ini, software versi akhir yang sudah disetujui administrator dirilis beserta dokumentasi software.

4. Pada fase Transiton
Pada tahap ini Business Modeling, Requirement, Analysis and Design, Implementation, Test, Deployment, Configuration dan Change Manegement, Project Management, Environtment Instalasi measuki tahap penyelesaian, pada tahap ini juga software sudah siap pakai. Pada fase ini workflow deployment dilakukan sosialisasi dan instalasi software.

Test melakukan uji coba untuk menghilangkan kesalahan-kesalahan yang mungkin timbul. Uji coba terdiri dari dua jenis, yaitu uji coba proses yang dilakukan secara otomatis oleh software dan uji coba antar muka yang dilakukan oleh tester. Deployment melakukan pemaketan, instalasi, konversi data, konfigurasi aplikasi.
Pada penggunaan kedua standard tersebut diatas yang berorientasi obyek (object orinted) memiliki manfaat yakni:

• Improve productivity
Standard ini dapat memanfaatkan kembali komponen-komponen yang telah tersedia/dibuat sehingga dapat meningkatkan produktifitas

• Deliver high quality system
Kualitas sistem informasi dapat ditingkatkan sebagai sistem yang dibuat pada komponen­komponen yang telah teruji (well-tested dan well-proven) sehingga dapat mempercepat delivery sistem informasi yang dibuat dengan kualitas yang tinggi.

• Lower maintenance cost
Standard ini dapat membantu untuk menyakinkan dampak perubahan yang terlokalisasi dan masalah dapat dengan mudah terdeteksi sehingga hasilnya biaya pemeliharaan dapat dioptimalkan atau lebih rendah dengan pengembangan informasi tanpa standard yang jelas.

• Facilitate reuse
Standard ini memiliki kemampuan yang mengembangkan komponen-komponen yang dapat digunakan kembali untuk pengembangan aplikasi yang lainnya.

• Manage complexity
Standard ini mudah untuk mengatur dan memonitor semua proses dari semua tahapan yang ada sehingga suatu pengembangan sistem informasi yang amat kompleks dapat dilakukan dengan aman dan sesuai dengan harapan semua manajer proyek IT/IS yakni deliver good quality software within cost and schedule time and the users accepted.

.............!