MATERI

PRESENTASI RPL-OOT Tentang The Rational Unified Process ( RUP )

Disusun oleh : Kelompok 13, Kelas IF-26-04

Aristya Widi Eriandi

(113020273)

Dedy Rahman Wijaya (113020306) Finny Afrilia Rissa Permatasari Ryeo Brivo Hadi (113020259) (113020268) (113020302)

JURUSAN TEKNIK INFORMATIKA SEKOLAH TINGGI TEKNOLOGI TELKOM BANDUNG 2004

BAB I PENDAHULUAN LATAR BELAKANG

RUP (Rational Unified Process) merupakan suatu Software engineering process hasil kerja awal dari Three Amigos Ivar Jacobson, Grady Booch, dan James Rumbaughyang bertujuan untuk memastikan kualitas yang terbaik pada suatu produksi software dengan memperkirakan jadwal dan biaya yang harus dikeluarkan. RUP merupakan process product dari Rational Software dengan konsep utamanya adalah tentang model, workflow dan workers, serta tentang phase dan iterasi. Aktifitas yang dilakukan oleh Rational Unified Process adalah membuat dan memelihara model. RUP juga meliputi pembahasan dari implementasi UML (Unified Modelling Language) secara luas dan memfokuskan dirinya pada software yang memiliki metodologi berorientasi objek. Sehingga dapat kita bedakan dengan UML bahwa RUP merupakan sebuah proses yang dilakukan dalam rekayasa perangkat lunak sedangkan UML adalah bahasa standar yang digunakan untuk memvisualisasikan, mendeskripsikan, membangun, dan mendokumentasikan perangkat yang akan digunakan dalam membangun sebuah perangkat lunak. RUP dibutuhkan sebagai pedoman untuk menggunakan UML secara efektif. Sedangkan UML berfungsi sebagai standardisasi notasi yang berorientasi objek untuk mengkomunikasikan kebutuhan/requirement, architectures, dan desain secara jelas dengan user. Oleh karena itu, hubungan antara RUP dan UML sangatlah dekat. Aktifitas yang dilakukan dalam Software development merupakan sebuah pekerjaan team. Karena perubahan teknologi yang cepat sehingga memerlukan spesialisasi tertentu dalam pelaksanaannya. Produktivitas team ini dapat ditingkatkan dengan menggunakan RUP dalam mendukung pembangunan sebuah software. Mengapa? Karena setiap anggota team akan dibekali oleh pengetahuan dasar yang sama mengenai guidelines dan template dalam aktifitas software development, sehingga saat membangun sebuah sistem akan dijamin bahwa setiap anggota team akan menggunakan bahasa yang sama untuk merepresentasikan requirement yang diminta user. Jika telah ada standar yang digunakan dalam proses pembangunan sebuah software, diharapkan dapat mengoptimalkan hasil yang diperoleh.

BAB II LANDASAN TEORI

Dalam membangun sebuah software, kita membutuhkan tahapan-tahapan yang harus dipenuhi selama proses men-develop software. Tahapan yang harus dilalui itu dapat kita gambarkan sebagai berikut :

Semua tahapan tersebut dapat dilalui dengan berbagai metode. Salah satu metode yang biasa digunakan adalah Waterfall workflow. Diagramnya adalah sebagai berikut :
Requirements Analysis Design Code & Unit Testing Subsystem Testing System Testing

Namun dengan metode ini dirasakan kurang efektif karena membutuhkan lebih banyak cost sampai menghasilkan sistem yang baik. Hal ini dapat terjadi karena modul yang ada dalam sistem tidak dibagi-bagi terlebih dahulu dalam pengujian software. Masalah ini dapat diatasi dengan menggunakan metode iteration incremental yang membagi modulmodul sehingga kesalahan dapat diatasi sejak dini. Metode ini yang digunakan dalam RUP.

Keuntungan yang didapat dengan menggunakan pendekatan iterasi diantaranya adalah : mengurangi resiko lebih awal, perubahan yang dilakukan lebih mudah diatur, higher level of reuse, project team memiliki waktu lama untuk memahami sistem yang akan dibangun, dan menghasilkan kualitas yang lebih baik di segala aspek. RUP menawarkan berbagai kemudahan dalam membangun sebuah sotfware, ada yang disebut Six Best Practices yang terdiri dari : Develop Iteratively Manage Requirement Use Component-based Architecture Model Visually Verify Quality Control Changes to software Semua proses yang dilakukan oleh RUP akan memberikan keuntungan pada tahapan membangun sebuah software. Yang akan kita bahas di bagian lain dari makalah ini. Saat melakukan perancangan sebuah perangkat lunak, tentunya setiap tahapan akan mendapatkan masalah. Biasanya gejala/symptom yang menunjukkan ada masalah dalam proses perancangan software seperti berikut : Ketidak akuratan dalam memahami kebutuhan end-user. Ketidakmampuan untuk menyetujui perubahan kebutuhan yang diajukan. Modul-modul yang dibutuhkan tidak dapat dihubungkan. Software yang sulit untuk dibangun atau diperluas. Terlambat menemukan kerusakan project yang serius. Kualitas software yang buruk. Kemampuan software yang tidak dapat diterima. Team members yang bekerja sendiri-sendiri sulit untuk mengetahui perubahan yang telah dilakukan karena ada perbedaan dalam membangun software tersebut. Ada ketidakpercayaan dalam membangun dan me-release proses. Usaha untuk menghilangkan symptom ini tidak akan menyelesaikan masalah yang dihadapi software developer karena gejala ini dapat terjadi oleh adanya penyebab utama masalah yang timbul saat membangun sebuah sistem, yaitu :

 Requirement management yang tidak mencukupi Komunikasi yang ambigu dan tidak tepat Arsitektur yang rapuh Kompleksitas yang sangat besar Tidak terdeteksinya ketidakkonsistenan antara requirement,desain, dan implementasi Pengetesan yang tidak mencukupi Penilaian status project yang subjektif Keterlambatan pengurangan resiko yang disebabkan waterfall development Perkembangan yang tidak terkontrol Otomatisasi yang kurang Semua hambatan yang ditemui saat membangun software akan dapat diatasi dengan menggunakan best practise yang telah disebutkan di awal pembahasan. Dengan menggunakan best practise yang diterapkan oleh Rational Unified Process, akar masalah yang menyebabkan timbulnya symptom dalam software developer akan teratasi dengan baik.

BAB II ISI ANALISA

Sebelum kita membahas lebih dalam mengenai Rational Unified Process, kita perlu untuk mengetahui terlebih dahulu apa maksud dari proses itu sendiri. Proses merupakan suatu tahapan yang mendefinisikan siapa yang mengerjakan apa, kapan dan bagaimana meraih suatu tujuan yang pasti. RUP merepresentasikan empat elemen dasar untuk memodelkan pertanyaan yang muncul dari sebuah proses, yaitu workers, activities, artifacts, dan workflows. Worker mendefinisikan behavior/kelakuan dan responsibilities dari seseorang atau sebuah team. Dalam Unified Process, worker lebih diartikan sebagai bagaimana team/individual seharusnya bekerja. Sedangkan tanggungjawab bagi worker adalah melakukan serangkaian aktifitas sebagai pemilik dari sekumpulan artifact. Activity dari spesific worker adalah sebuah unit kerja yang dilakukan seorang individu. Tujuannya cukup jelas,yaitu membuat/meng-update artifact. Setiap activity diberikan kepada spesific worker dan harus dapat digunakan sebagai elemen dalam planning dan progress software development. Contoh activity diantaranya : merencanakan sebuah iteration untuk worker Project Manager, menemukan use case dan aktor untuk worker System Analyst, dan sebagainya. Artifact merupakan sekumpulan informasi yang dihasilkan, diubah, dan dipakai dalam sebuah proses. Artifact digunakan sebagai input bagi worker untuk melakukan activity dan juga sebagai output dari activity. Dalam object-oriented design, activities adalah operasi yang dilakukan aktif object(worker) sedangkan artifact sebagai parameter dari activities tersebut. Contoh artifact yaitu: model (uses case model), document,source code,dan lain-lain. Workflow adalah serangkaian activities yang menghasilkan nilai hasil yang dapat terlihat. Dalam UML, workflow digambarkan dengan sequence diagram, collaboration diagram, atau activity diagram. Workflow tidak selalu dapat dipakai untuk merepresentasikan semua ketergantungan yang ada diantara activities. Karena,terkadang dua buah activities

yang digambarkan dalam workflow sebenarnya sangat rapat jalinannya yang melibatkan worker yang sama padahal mungkin penggambarannya tidak terlalu tepat. Jadi, perlu ditetapkan tipe workflow yang paling dibutuhkan dalam process yang disebut Core Process. Core process workflows :

Process Workflows
Business Modeling Requirements Analysis & Design Design Implementation nnn Test Deployment

Inception Elaboration

Construction

Transition

Supporting Workflows
Configuration Mgmt Project Mgt Environment
Preliminary Iteration(s) Iter. #1 Iter. #2

Iterations

Iter. #n

Iter. Iter. #n+1 #n+2

Iter. #m

Iter. #m+1

Dari gambar diatas, terlihat ada sembilan core process workflow dalam RUP. Semuanya merepresentasikan pembagian worker dan activities ke dalam logical grouping. Ada dua bagian utama yaitu process workflows dan supporting workflows. Dalam process workflows terdapat Bussiness modeling yang didalamnya dibuat dokumen bussiness process yang dipakai disebut bussiness use cases. Dokumen ini menjamin stakeholder memahami kebutuhan bisnis proses yang diperlukan. Tujuan dari requirement workflow adalah mendeskripsikan what/apa yang harus dikerjakan oleh sistem serta membolehkan developer dan costumer untuk menyetujui deskripsi itu. Analysis&Design workflows bertujuan untuk menunjukkan how/bagaimana merealisasikan sistem dalam tahap implementasi. Didalamnya kita akan menemukan problem domain juga solusi dari problem yang mungkin akan muncul dalam sistem. Hasil yang diberikan pada tahapan ini adalah design model sebagai blueprint dari source code yang akan dibuat dan juga analysis model (optional). Implementation workflow bertujuan untuk mengimplementasikan classes dan objects dalam hubungannya dengan component, mengetest component yang dihasilkan

sebagai unit, dan untuk mengintegrasikan hasil yang dibuat oleh masing-masing implementer/teams ke dalam executable system. RUP menjelaskan bagaimana kita me-reuse exiting complements atau me-implement new component sehingga membuat sistem mudah dibangun dan meningkatkan kemungkinan untuk me-reusenya. Test workflow bertujuan untuk memeriksa interaksi antar objek, penggabungan component dari software dengan tepat, dan memeriksa apakah semua kebutuhan sudah dipenuhi dengan tepat. Selain itu, test bertujuan untuk mengidentifikasikan dan meyakinkan bahwa kerusakan yang ada telah diatasi sebelum men-deploy software. RUP menawarkan pendekatan iterative yang memungkinkan kita mengetest keseluruhan project dengan menemukan kerusakan sejak dini sehingga mengurangi cost untuk memperbaikinya. Test menghasilkan tiga macam ukuran qualitas yaitu reliability, functionality, application dan system performance. Deployment workflow dilakukan untuk menghasilkan product release dengan sukses dan aktifitas mengantar software kepada end user seperti membuat external releases dari software ,packing software, distributing software, installing software, serta membantu user memahami sistem. Aktifitas ini dilakukan pada fase transition. Dalam RUP, deployment workflow berisi paling sedikit detailnya daripada workflow yang lain. Project management menyediakan framework untuk mengatur software-intensive projects, panduan untuk planning, staffing, executing, dan monitoring projects, dan framework untuk mengatur resiko yang ada. Dikatakan sukses apabila produk tersebut dapat memenuhi kebutuhan user dan kebanyakan customer. Configuration and change management menyediakan panduan untuk mengatur penyusunan software systems, mengatasi perubahan request management, dan dapat menjadi salah satu cara untuk melaporkan suatu kerusakan. Environment bertujuan menyediakan software development organization beserta software development environment, yang dibutuhkan untuk mendukung development team. Seperti yang kita tahu dalam software development, tujuan yang akan diraih adalah membangun/meningkatkan sebuah software sesuai dengan kebutuhan (Bussiness Process). Sedangkan sebuah proses disebut efektif jika menetapkan sebuah garis pedoman yang menjamin kualitas software yang dibangun, mengurangi resiko dan meningkatkan perkiraan kepada masalah yang mungkin muncul, serta menggunakan best practise.

Rational Unified Process menawarkan dan menjelaskan penerapan six best practise yang efektif pada software development, diantaranya adalah : 1. Develop Software Iteratively Pendekatan secara iterative digunakan untuk mengurangi resiko yang dapat terjadi selama lifecycle. Setiap akhir iterasi akan diperoleh executable release yang memungkinkan keterlibatan end user dan feedback yang diberikan secara terus-menerus. Pendekatan ini juga mepermudahkan penyesuaian perubahan kebutuhan, features, maupun jadwalnya. 2. Manage Requirements Rational Unified Process mendeskripsikan bagaimana mendapatkan, mengorganisasikan, dan mendokumentasikan fungsionalitas dan batasan yang dibutuhkan. Sehingga akan memudahkan dalam memahami dan mengkomunikasikan kebutuhan bisnis. 3. Use Component-based Architecture RUP menggunakan pendekatan sistematis dalam mendefinisikan arsitektur yang menggunakan component. Karena memang proses yang dilakukan difokuskan pada awal pembangunan sebuah software. Dalam proses ini akan mendeskripsikan bagaimana menyusun arsitektur yang fleksibel, mudah dipahami, dan mengembangkan efektif software reuse. 4. Visually Model Software Proses yang dilakukan menunjukkan bagaimana memvisualisasikan model yang mencakup struktur dan kelakuan dari arsitektur dan komponen. 5. Verify Software Quality Application perfoemance dan kemampuan tahan uji yang buruk dapat menghalangi diterimanya sebuah aplikasi software. Sehingga diperlukan penelaahan lebih lanjut tentang kualitas software dengan mematuhi kebutuhan aplikasi berdasarkan kemampuan tahan uji, fungsionalitas, application performance, dan system performance. 6. Control Changes to Software Proses akan mendeskripsikan bagaimana mengontrol dan memonitor perubahan untuk kesuksesan iterative development. Selain itu, proses juga akan memandu kita bagaimana menyusun workspace yang aman bagi para developer dengan mengisolasi perubahan yang dilakukan di workspace lain dan dengan mengontrol perubahan pada seluruh software artifact. Sehingga membuat team bekerja sebagai unit tersendiri dengan mendeskripsikan bagaimana mengintegrasikan dan membangun management secara otomatis.

RUP sebagai architecture-centric. Architeture ini merupakan fokus yang dibahas pada fase elaboration yang akan dibahas pada bagian lain makalah ini. Software architecture design merupakan artifact dasar yang diperoleh dari sebuah architecture. Artifact lain yang diperoleh dari sebuah architecture ini diantaranya dapat membuat garis pedoman desain yang dipakai, struktur produk, dan team structure. Dalam merepresentasikan sebuah architecture pada software development kita menggunakan yang disebut The 4+1 view model yang telah kita kenal saat mempelajari UML. View model itu terdiri dari : logical view (dipakai oleh analyst/designer), implementation view (dipakai oleh progammer), process view (dipakai oleh system integrator), dan deployment view (dipakai oleh system engineering), serta ditambah dengan use case view (dipakai oleh end user). Keuntungan dari architecture centric process diantaranya memperbolehkan kita untuk menambah dan menambah intellectual control sebuah proyek untuk mengatur kompleksitas dan membangun system integrity. Proses arsitektur ini memiliki lifecycle phase, yang terdiri dari inception phase, elaboration phase, construction phase, dan transition phase. Setiap fase yang ada dihubungkan dengan milestone, yaitu suatu point evaluasi dari suatu tahap fase yang sudah selesai dibuat, sebagai langkah menuju fase berikutnya. Apabila evaluasi ini gagal maka fase tersebut harus diperbaiki kembali. Setiap phase memiliki tujuan tersendiri, yaitu sebagai berikut : 1. Inception Phase Merupakan fase yang pertama kali dijalankan, didalamnya akan membangun bussiness case dan batasan ruang lingkup project. Hasil dari fase ini adalah vision document (bayangan umum project), initial use-case model (sudah 10%-20% selesai), initial bussiness case, initial project glossary, initial risk assesment, project plan (phases dan iteration), bussiness model jika perlu, dan beberapa prototype. Milestone di akhir fase ini adalah lifecycle objective. Kriteria evaluasi untuk fase inception yaitu : ada persetujuan dari stakeholder terhadap definisi ruang lingkup dan biaya/jadwal yang diperkirakan; pemahaman terhadap kebutuhan sebagai petunjuk oleh primary uses case; kepercayaan dari perkiraan cost/schedule, prioritas, resiko, dan development process; kedalaman dan luasnya arsitektur prototype yang dibangun; perbandingan pengeluaran yang ada dengan yang direncanakan. 2. Elaboration Phase

Tujuan fase ini adalah menganalisa masalah utama, menyusun pondasi arsitektur, membangun rencana project, dan menghilangkan resiko terburuk yang akan dialami project. Fase elaboration merupakan fase yang paling kritis karena tujuannya adalah untuk menganalisa masalah. Aktifitas yang dilakukan yaitu menjamin bahwa arsitektur, requirement, dan rencana yang dilakukan cukup stabil dan mengurangi resiko sehingga dapat memprediksikan cost dan schedule yang dibutuhkan. Hasil dari proses ini adalah : use case model (min.80% complete), software architecture description, executable architectural prototype, revisi daftar resiko dan bussiness case. Milestone yang dicapai di akhir fase ini adalah lifecycle architecture. Pada point ini, kita menguji ruang lingkup dan detail dari system secara objektif, pilihan arsitektur, dan pemecahan masalah utama. Kriteria evaluasi yang dapat dilakukan yaitu kestabilan arsitektur dan produk; apakah masalah utama yang muncul telah diatasi; apakah rencana untuk fase contruction telah akurat; dan apakah seluruh stakeholder menyetujui arsitektur yang dibuat. 3. Construction Phase Di fase ini semua component dan feature aplikasi dibangun dan disatukan ke dalam product serta akan diperiksa. Construction phase berupa sebuah proses manufacturing yang menekankan pada pengontrolan operasi untuk mengoptimalkan cost, schedule, dan kualitas. Keluaran dari fase ini adalah kesiapan produk untuk diserahkan kepada user yang meliputi : integritas produk pada platform mencukupi, user manual, dan deskripsi dari rilis berikutnya. Milestone yang dicapai di akhir fase ini adalah initial operation capability. Kriteria evaluasi pada fase ini : apakah produk yang dirilis sudah stabil dan matang untuk diberikan kepada user, apakah semua stakeholder siap untuk proses transition, apakah perbandingan pengeluaran resource dengan rencana semua masih dapat diterima. 4. Transition Phase Tujuannya yaitu untuk mentransisikan/menyerahkan funsionalitas sistem lengkap ke pengguna dan juga menyerahkan rilis produk. Fase ini meliputi : beta testing untuk memvalidasi sistem dengan perkiraan user, melakukan operasi paralel dengan sistem lama, mengkonversi operational database, melatih user dan maintaners, roll-out produk untuk pemasaran dan distribusi.

Milestone yang dicapai di akhir fase ini adalah product release. Kriteria evaluasi yang dapat dilakukan : apakah user puas terhadap software yang kita bangun dan apakah perbandingan pengeluaran resource dengan rencana semua masih dapat diterima.

BAB III PENUTUP KESIMPULAN

The Rational Unified Process merupakan proses rekayasa perangkat lunak yang bertujuan untuk meningkatkan produktivitas tim. RUP menyediakan pendekatan disiplin untuk memastikan proses produksi software yang berkualitas tinggi yang memenuhi kebutuhan end user, dibawah prediksi jadwal dan anggaran. Selain itu, RUP juga menekankan pembangunan dan pemeliharaan model sehingga dijadikan acuan untuk menggunakan UML (The Unified Modeling Process) sebagai bahasa pemodelan secara efektif. Dalam tahapan proses development software yang harus dilalui, RUP membaginya ke dalam modul-modul yang akan dikerjakan secara iterative sehingga memungkinkan kita mengetest keseluruhan project dengan menemukan kerusakan sejak dini sehingga mengurangi cost untuk memperbaikinya. Dengan menggunakan RUP, diharapkan dalam proses pembangunan sebuah software dapat menghasilkan kualitas yang terbaik.