Nama NIM Jurusan Kelas Mata Kuliah

: Frans Filasta Pratama : 09101003004 : Sistem Informasi : SI 5 B : Analisis Dan Perancangan Berorientasi Objek

RESUME
The Rational Unified Process An Introduction , Second Edition
By Philippe Kruchten

Rational Unified Process (RUP) adalah sebuah metodologi atau proses rekayasa perangkat lunak. RUP mmberikan pendekatan disiplin untuk pemberian tugas dan tanggung jawab dalam pengembangan organisasi. Tujuannya adalah untuk memastikan produk yang dihasilkan adalah perangkat lunak yg bekualitas,memenuhi kebutuhan end user ,sesuai jadwal yang telah ditentukan serta biaya yang pengembangan pantas. RUP adalah software. dikembangkan dan dirawat oleh Rational Software (Suite) membantu pengembangan dgn metode ini. untuk

RUP merangkum enam best practices pengembangan perangkat lunak yang dikemukakan Grady Booch serta dapat diterapkan secara luas. Enam Best Practices tersebut adalah : Develop software iteratively Manage requirements Use component-base architectures Visually model software Continously verify software quality Control changes to software yang dicakup dalam Rational Software Suite

RUP menggunakan object-oriented dan pemodelan menggunakan UML (Unified Model Language) serta menggunakan use-case-driven sebagai fondasi dari semua proses. Use Cases memainkan peran yang paling utama dalam beberapa alur kerja RUP, terutama saat identifikasi requirements, desain,testing, dan management. Use Cases juga kunci untuk pemodelan bisnis. Struktur Proses Rational Unified Process mempunyai dua dimensi proses , yaitu : Dimensi pertama digambarkan secara horizontal. Dimensi ini mewakili aspek-aspek

dinamis dari pengembangan perangkat lunak. Aspek ini dijabarkan dalam tahapan pengembangan atau fase. Setiap fase akan memiliki suatu major milestone yang menandakan akhir dari awal dari phase selanjutnya.Setiap milestone mempunyai kriteria evaluasi yang menjadi tolok ukur apakah proyek ini akan dibatalkan atau akan dipikirkan kembali . Setiap phase dapat berdiri dari satu atau beberapa iterasi. Elaboration, Construction, dan Transition. Dimensi kedua digambarkan secara vertikal. Dimensi ini mewakili aspek-aspek statis dari proses pengembangan perangkat lunak yang dikelompokkan ke dalam beberapa disiplin. Proses pengembangan perangkat lunak yang dijelaskan kedalam beberapa disiplin terdiri dari empat elemen penting, yakni who is doing(worker), what(artifacts), how(activities) dan when(workflow). Dimensi ini terdiri atas Business Modeling, Requirement, Analysis and Design, Implementation, Test, Deployment, Configuration dan Change Manegement, Project Management, Environtment. Dimensi ini terdiri atas Inception,

Fase Fase RUP Secara umum maksud dari empat fase pada RUP adalah sebagai berikut : Inception Menentukan Ruang lingkup proyek Membuat Business Case

Menjawab pertanyaan apakah yang dikerjakan dapat menciptakan good business sense sehingga proyek dapat dilanjutkan

Elaboration Menganalisa berbagai persyaratan dan resiko Menetapkan base line Merencanakan fase berikutnya yaitu construction

Construction Melakukan sederetan iterasi Pada setiap iterasi akan melibatkan proses berikut: analisa desain, implementasi dan testing

Transistion Membuat apa yang sudah dimodelkan menjadi suatu produk jadi Dalam fase ini dilakukan: Beta dan performance testing Membuat dokumentasi tambahan seperti; training, user guides dan sales kit Membuat rencana peluncuran produk ke komunitas pengguna

USE CASE RUP menggunakan pendekatan use-case-driven , artinya use-case yang telah didefinisikan system adalah dasar untuk proses pengembangan secara keseluruhan. RUP menggunakan Use Case Diagram dan Actvity Diagram untuk menggambarkan use case model, termasuk hubungan antar use-case. Konsep Use case, Actor , dan Scenario Use Case adalah urutan tindakan yang memberikan hasil yang nyata kepada pelaku (actor) tertentu Actor adalah orang atau sesuatu diluar system yang berinteraksi dengan system itu sendiri Scenario adalah contoh dari sebuah use case class

Kemudian ada Use Case Model . Use Case Model adalah penggambaran bagaimana actor dan use case berinteraksi, atau memberikan gambaran bagaimana sebuah system/subsistem

berfungsi. Use-case-model juga merupakan suatu teknik untuk menggambarkan bagaimana system seharusnya bekerja menurut padangan pemakai. Satu use-case dengan use-case lainnya dapat mempunyai hubungan atau perpotongan. Untuk mengeksploitasi hubungan antar use case maka digunakan tiga cara ini : Inclusion Extension Specialization/generalization

Proses Statis Pada RUP

The Project Management Workflow berfokus pada aspek spesifik berkenaan dengan proses iterative saat pengembangan. Aspek aspek tersebut adalah : 1. Merencanakan proyek iterative dalam siklus hidup proyek. 2. Manajemen resiko 3. Monitoring proges dari proses iterative yang berlangsung dan metric (satuan ukur) Worker Artifacts : Project Manager . : Software Development Plan yang bersisi o Rencana penerimaan produk o Rencana manajemen resiko , termasuk daftar resiko o Rencana pemecahan masalah o Rencana pengukuran Kasus bisnis Rencana iterasi Penilaian iterasi Status penilaian berjangka Urutan kerja Basis data pengukuran proyek

Workflow :

Bussiness Modeling Workflow Tujuan Bussiness Modeling Workflow adalah : Mengerti struktur dan organisasi dinamis dalam system yang akan di-deploy Mengerti masalah yang dihadapi dan mengidentifikasi peluang perbaikan Memastikan customer , pengguna dan pengembangan mempunyai pengetahuan yang paling tidak setara tentang target organisasi Memberikan hal-hal yang dibutuhkan system untk mencapai target Worker : o Business process analyst adalah analis proses bisnis memimpin dan mengkoordinasikan pemodelan bisnis use-case dengan menguraikan dan membatasi organisasi yang dimodelkan o Business designer adalah membuat rincian dari spesifikasi bagian organisasi dengan menjelaskan satu atau beberapa use-case bisnis. Dia menentukan pekerja bisnis dan entitas bisnis yang diperlukan untuk mewujudkan use-case bisnis, dan juga menentukan bagaimana mereka bekerja sama untuk mencapai realisasi. Perancang bisnis mendefinisikan tanggung jawab, operasi, atribut, dan hubungan dari satu atau beberapa pekerja bisnis dan entitas bisnis. Artifacts : o Business vision document : berisi objektif dan tujuan usaha pemodelan bisnis o Model business use-case : model bisnis yang diinginkan o Model object bisnis Workflow :

The Requirements Workflow

Tujuan requirements workflow adalah sebagai berikut : Untuk membangun dan mempertahankan kesepakatan dengan customers dan stakeholder lain , bagaimana seharusnya system ini dan mengapa Agar pengembang system mendapat pemahaman yang baik tentang kebutuhan system. Menentukan batas system Memberikan dasar perancangan teknikal untuk iterasi Memberikan dasar perkiraan biaya dan waktu untuk mengembangkan system Menentukan antarmuka system,focus pada kebutuhan dan tujuan system

Worker : System Analisis System analisis ini memimpin dan mengkoordinasikan elisitas persyaratan dan menggunakan kasus permodelan dengan menguraikan fungsi system dan batasan system. Use Case Specifier Menggambarkan aspek persyaratan dari satu atau beberapa kasus penggunaan. User-Interface Designer Bertanggung jawab untuk memilih set kasus yang digunakan untuk menunjukan interaksi penting dari pengguna dengan system User-Interface Designer di kembangkan menjadi Use Case story Board dan Prototipe dan di kembangkan untuk membantu menentukan persyaratan system akhir.

Artifacts: Document vision Business objet model Use case model Workflow : Menganalisis masalah Memahami kebutuhan Stakeholder Menentukan sistem yang akan digunakan Mengelola ruang lingkup sistem Menyaring definisi sistem yang akan dibuat Mengontrol terjadinya perubahan persyaratan dengan user . The Analysis and Design Workflow Tujuan dari analisis dan desain alur kerja ini adalah untuk menterjemahkan kebutuhankebutuhan ke dalam sebuah spesifikasi system yang menjelaskan bagaimana cara mengimplementasikan system. Untuk mencapai tujuan tersebut anda harus memilih

strategi pelaksanaan terbaik sehingga anda dapat mengubah kebutuhan-kebutuhan ke dalam desain system. Worker dan Artifacts Arsitek : memimpin dan mengkoordinasikan kegiatan teknis dan artefak sepanjang proyek, menetapkan seluruh struktur untuk antar muka antara kelompok utama. Perancangan : mendefinisikan tanggung jawab, operasi, atribut, dan hubungan dari satu atau beberapa kelas dan menentukan bagaimana mereka harus disesuaikan dengan lingkungan implementasi, memiliki tanggung jawab untuk satu atau lebih paket desain atau subsistem desain termasuk kelas yang dimiliki oleh paket atau sebsistem. Analisis dan desain operasional : - Database Designer - Kapsul Designer (untuk real-time sistem) - Reviewer Arsitektur dan Desain Reviewer Artefak kenci dari analisis dan desain adalah - Desain model, yang merupakan blueprint utama untuk system dibawah kontruksi - Arsitektur perangkat lunak dokumen, menangkap berbagai pandangan arsitektur system. Workflow : Menentukan Arsitektur Calon Menghaluskan Arsitektur Menganalisis Perilaku Desain Komponen Real-Time Desain Komponen Desain Database

Implementation Workflow RUP mempunyai tiga konsep kunci implementasi, yaitu : o Build ,merepresentasikan usaha-usaha berkelanjutan untuk mendemonstrasikan pengembangan terbaru secara fungsional. o Integrasi , artinya perangakat lunak diintegrasi secara incremental. Incrimental disini maksudnya adalah code ditulis dan diuji dalam bagian kecil kemudian ditingkatkan pengembangan dan uji coba -nya dari waktu ke waktu. o Prototype,prototipe dapat mengurangi ketidakpastian seputar masalah-masalah berikut : Kelangsungan hidup bisnis dari sebuah produk telah dikembangkan

Stabilitas atau kinerja teknologi utama Komitmen projak atau pendanaan (melalui pembangunan sebuah bukti kecil konsep prototype) Kebutuhan yang dimengerti Pandangan dan perasaan, dan kegunaan mendasar dari produk

Worker Implementer , yang mengembangkan komponen dan artifact terkait serta melakukan percobaan unit. Penggabung system, yang membangun sebuah build.

Beberapa worker lain: Architect, yang memberikan struktur dari model implementasi (Lapisan dan subsistem) Code Reviewer, yang memeriksa kualiras code dan menyesuaikan sesuai standart proyek. Artifacts o Implementasi Subsistem o Komponen , bagian perangkat lunak (source code ,file binary, executable file) o Integration Build Plan , adalah dokumen yang menentukan urutuan bagaimana seharusnya komponen dan subsistem diterapkan serta menentukan build yang akan dibuat Test Workflow Tujuannya adalah untuk menilai kualitas produk. Setiap iterasi pasti melakukan ujicoba atau penilaian ini , bukan hanya pada produk akhir. Ujicoba meliputi empat hal berikut : Memeriksa interaksi antar komponen Memeriksa apakah komponen-komponen terintegrasi dengan layak Memeriksa apakah semua kebutuhan telah diterapkan dengan benar Memastikan apakah semua kecacatan yang telah diketahui telah dibenahi sebelum deployment Model pengujian meliputi: Test kasus

Himpunan data tes, kondisi pelaksanaan, dan hasil tes diharapkan dikembangkan untuk tujuan pengujian tertentu. Uji kasus dapat diperoleh dari penggunaan kasus, dokumen desain, atau kode software. Sebuah ujian dapat dilaksanakan oleh satu atau lebih prosedur pengujian. Uji prosedur Himpunan petunjuk rinci untuk setup, pelaksanaan, dan evaluasi hasil uji untuk uji kasus. Sebuah prosedur tes mengimplementasikan satu atau lebih uji kasus. Sebuah tes mungkin juga menerapkan prosedur hanya bagian dari ujian, seperti beberapa aliran alternatif dalam kasus penggunaan. Test script Komputer-instruksi yang dapat dibaca mengotomatisasikan prosedur pelaksanaan tes. Sebuah tes mengotomatisasi script pelaksanaan (seluruh atau bagian dari) satu atau lebih prosedur pengujian. Test kelas dan komponen Kelas dan komponen yang mewujudkan desain pengujian, termasuk driver dan topik. Test kolaborasi The kolaborasi, direpresentasikan sebagai urutan kolaborasi atau diagram, yang menggambarkan waktu-pesan sequencing aliran antara komponen pengujian dan target-ujian yang terjadi selama pengujian.

Worker dan Artifact Dua pekerja utama yang berada pada test workflow adalah o Test designer, bertanggung jawab atas perencanaan, design dan evaluasi ujicoba. o Tester adalah yang melakukan ujicoba system Artifact utama : o Rencana ujicoba o Model ujicoba o Hasil ujicoba o Kecacatan build Workflow o Rencana Test Tujuannya adalah untuk mengidentifikasi dan menjelaskan pengujian yang akan dilaksanakan dan dieksekusi. o Design Test Tujuannya adalah untuk mengidentifikasi, menjelaskan, dan menghasilkan model tes dan artefak melaporkan. Desain tes dilakukan untuk memastikan bahwa

perangkat lunak pengujian yang memenuhi persyaratan dan terstruktur dan terorganisir dengan baik. Melaksanakan Test Tujuannya adalah untuk melaksanakan prosedur tes yang didefinisikan dalam bagian Test Design. Pengujian dalam melaksanakan Test Tahap Integras Tujuan Uji Tahap Integrasi adalah untuk memastikan bahwa, selama perakitan, komponen sistem bekerja sebagaimana dimaksud, serta bahwa kenaikan memiliki perilaku yang benar. Sistem integrator dan link mengkompilasi sistem secara bertahap. Untuk setiap kenaikan, fungsi yang telah ditambahkan diuji, dan dilakukan tes regresi, menghasilkan hasil tes. Dalam satu iterasi, integrasi dilakukan pengujian beberapa kali sampai seluruh sistem (sebagaimana didefinisikan oleh tujuan dari iterasi) telah diintegrasikan dengan sukses. Melaksanakan Sistem Pengujian dalam Tahap Uji Tujuan dari Uji Sistem Tahap ini adalah untuk memastikan bahwa sistem lengkap berfungsi sebagaimana dimaksud. Evaluasi Test Tujuan mengevaluasi tes ini adalah untuk memberikan dan menilai langkah-langkah pengujian diukur untuk menentukan kualitas dari target-of-test dan kualitas proses tes. Hal ini dicapai dengan meninjau dan mengevaluasi hasil tes, mengidentifikasi dan penebangan perubahan permintaan, dan menghitung ukuran kunci ujian.

The Configuration and Change Management Workflow Tujuannya adalah untuk mengawasi dan memelihara integritas perkembangan aset proyek Worker dan Artifacts

Configuration Manager bertanggung jawab untuk menyiapkan struktur produk dalam sistem CM, untuk mendefinisikan dan mengalokasikan ruang kerja bagi pengembang, dan untuk integrasi. Configuration Manager juga mengekstrak status yang sesuai dan laporan metrik untuk Manajer Proyek. Change Control Manager mengawasi proses kontrol perubahan. Peran ini biasanya dimainkan oleh Configuration, or Change, Control Board (CCB), yang harus terdiri dari wakil-wakil dari semua pihak yang berkepentingan, termasuk pelanggan, pengembang, dan pengguna.

Artefak: Configuration Management Plan atau rencana konfigurasi manajemen CM plan menjabarkan kebijakan dan praktek yang akan digunakan pada proyek untuk CM: versi, varian, ruang kerja, dan prosedur untuk manajemen perubahan, membangun, dan rilis. CM plan mendefinisikan aturan dan tanggung jawab untuk CCB tersebut. Ini adalah bagian dari rencana pengembangan perangkat lunak. Change requests Setiap permintaan perubahan dikaitkan dengan asal dan akar penyebab. Kemudian, analisis dampak menekankan dampak dari perubahan artefak, biaya, dan jadwal. Sebagai permintaan perubahan berkembang, negara yang perubahan; item sejarah, dalam keputusan CCB yang tertentu, yang melekat padanya. Workflow Membuat Proyek Lingkungan CM Manage Baselines and Releases Pada dasarnya adalah deskripsi dari semua versi artefak yang membentuk produk tersebut pada waktu tertentu. Memantau dan melaporan Konfigurasi Status Manage Change Requests Tujuan dari sebuah control perubahan adalah untuk memastikan bahwa perubahan dalam sebuah proyek yang dibuat secara konsisten dan stakeholder yang tepat mengenai keadaan produk, perubahan, dan dampak biaya dan jadwal .

The Environment Workflow Tujuan utamanya adalah untuk menyesuaikan alat dan konfigurasi hasil iterasi agar sesuai dengan organisasi Worker dan Artifacs Worker :

Sebuah proses bisnis analis, sebagai pedoman pemodelan bisnis analis sistem, sebagai pedoman pemodelan use-case perancang user interface, sebagai pedoman pengguna interface arsitek,sebagai pedoman desain dan pemrograman penulis teknis, sebagai pengguna panduan styleguide

Articats : Development case , menentukan bagaimana sebuah proses akan berlangsung dan disesuaikan dengan proyek individu.

Workflow

The Deployment Workflow Tujuan dari penyebaran adalah untuk mengubah perangkat lunak selesai produk ke penggunanya. Worker dan artifacts Berikut worker yang terlibat dalam deployment workflow: The Deployment Manager plans and organizes deployment. Ia bertanggung jawab atas feedback pengujian program beta dan memastikan produk dikemas dengan tepat untuk deployment.

The Project Manager merupakan yang paling utama dan bertanggung jawab untuk menyetujui pengerahan berdasarkan umpan balik dan hasil tes evaluasi, dan penerimaan pelanggan terhadap deployment. The Technical Writer Pengembang Course menghasilkan rencana dan materi pelatihan. Graphic Artis yang bertanggung jawab untuk semua produk yang berhubungan dengan karya seni. Tester bertanggung jawab untuk memastikan bahwa produk telah diuji secara memadai. Pelaksana menciptakan skrip instalasi dan artefak yang terkait yang akan membantu pengguna akhir menginstal produk.

Artefact utama : perangkat Lunak yang dapat dieksekusi, dalam semua kasus artefak instalasi: script, alat, file, panduan, informasi lisensi Release Notes, menggambarkan rilis untuk pengguna Dukungan Material, seperti user manual, manual operasi dan pemeliharaan Materi Pelatihan Workflow Merencanakan Deployment Membuat materi pendukung Ujicoba produk saat deployment Membuat rilis produk Rilis ujicoba beta ujicoba saat proses instalasi Paket produk memberikan akses download pada website