Metodologi RUP (Rational Unified Process)

BAB I
PENDAHULUAN

1.1 Latar Belakang Dan Sejarah Perkembangan

Perkembangan tehnologi informasi yang sangat pesat saat ini, sedikit banyaknya telah
mempengaruhi seluruh kalangan masyarakat. Khususnya dibidang komputerisasi yang
didukung perkembangan Software dan Hardware. Computer sendiri memiliki peran yang
sangat penting dalam kemajuan ilmu pengetahuan dan teknologi, karena computer
merupakan alat pengolah data, alat penghitung serta memproses data yang tentunya tidak
bekerja sendirinya. Oleh karena itu memerlukan input dan output agar dapat seperti yang
diinginkan.
Kemajuan teknologi yang sangat pesat ditandai dengan semakin banyaknya perangkat-
perngkat teknologi informasi yang digunakan oleh masyarakat luas. Sekarang ini banyak
terdapat beberapa paradigma yang digunakan dalam rekayasa software, diantaranya process-
oriented methodologies, blended methodologies, object-oriented methodologies, Rapid
development methodologies, people-oriented methodologies, dan frameworks. Semua
metodologi tersebut berkembang dan digunakan sesuai dengan kebutuhan dari penggunanya.
Metodologi yang digunakan dalam pengembangan sistem informasi adalah Object Oriented.
Saat ini Object Oriented merupakan metodologi yang baik dalam rekayasa software. Object
Oriented memandang software bagian per bagian dan menggambarkan satu bagian tersebut
dalam satu objek. Tidak seperti paradigma lainnya, dimana hanya cocok untuk beberapa
kasus dan bagian dari seluruh kemungkinan ruang lingkup aplikasi, khusus untuk object-
oriented dapat diaplikasikan dalam seluruh ruang lingkup.
Salah satu jenis metodologi object oriented yang akan digunakan pada pengembangan sistem
informasi adalah Rational Unified Process (RUP).
Menurut sejarah , yang terkenal sebagai pengembang model UML adalah namanya Booch,
Rumbough, n’ Jacobson mereka bertiga itu pertama kali ngumpul di perusahaan Rational
Software dan melakukan pengembangan-pengembangan software , yang salah satunya adalah
RUP alias Rational Unified Process
Pada 1997, Rasional telah memperoleh Verdix, Objectory, Persyaratan, SQA, Kinerja
Kesadaran, dan Pure-Atria. Menggabungkan pengalaman dasar perusahaan-perusahaan ini
menyebabkan artikulasi tujuh praktik terbaik rekayasa perangkat lunak modern:
1. Mengembangkan iteratively, dengan risiko sebagai sopir iterasi utama
2. Mengatur persyaratan
3. Menggunakan arsitektur berbasis komponen
4. Lunak model visual
5. Terus kualitas verifikasi
6. Kontrol perubahan
7. Customization.

Ini praktik terbaik kedua mendorong pengembangan produk Rasional, dan digunakan oleh
tim lapangan Rasional untuk membantu pelanggan meningkatkan kualitas dan prediktabilitas
dari usaha pengembangan perangkat lunak mereka. Untuk membuat pengetahuan lebih
mudah diakses, Philippe Kruchten, sebuah techrep Rasional, adalah bertugas dengan
perakitan kerangka proses yang eksplisit modern rekayasa perangkat lunak. Upaya ini
memanfaatkan HTML-proses berdasarkan mekanisme pengiriman dikembangkan oleh
Objectory. Yang dihasilkan “Rational Unified Process” (RUP) menyelesaikan strategis tripod
untuk Rasional:
• suatu proses yang dipandu tailorable pembangunan
• alat yang otomatis aplikasi dari proses
• mempercepat adopsi layanan yang baik dari proses dan alat.

Rational Unified Process (RUP) merupakan suatu metode rekayasa perangkat lunak yang
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. 
1.2 Identifikasi Masalah
Berdasarkan uraian dari latar belakang di atas, pokok permasalahan yang akan dibahas dalam
makalah ini adalah :
a. Apa Sejarah perkembangan metodologi RUP
b. Apa fase-fase/tahapan-tahapan yang terdapat dalam metodologi RUP
c. Bagaimana penerapan Tahapan Metodologi Pengembangan Perangkat Lunak dengan
Menggunakan RUP (Contoh Kasus)
d. Apa disiplin ilmu yang tedapat dalam metodologi RUP

1.3 Tujuan Dan Manfaat Dalam Pembuatan Makalah ini

a. Tujuan
Sebagai tugas besar dalam mata kuliah pengembangan system informasi
b. Manfaat
Membuat penulis mengerti tentang metodologi dalam pengembangan perangkat lunak serta
sebagai bahan ujian dalam menghadapi UAS nanti.

BAB II
PEMBAHASAN

2.1 Pengertian Sistem Informasi

System informasi berasal dari bahasa Yunani yang artinya suatu keseluruhan dan hubungan
yang berlangsung di antara satuan. Jadi, system adalah sehimpunan bagian atau komponen
yang saling berhubungan secara teratur dan merupakan suatu keseluruhan.
Sedangkan informasi adalah hasil pengolahan data-data yang berarti bahwa informasi
memiliki arti yang sangat penting dan arti guna.
Untuk mengetahui apa yang dimaksud dengan system informasi, maka penulis mengutip dari
beberapa defenisi yang dikemukakan oleh beberapa ahli seperti yang diuraikan di bawah ini :
Menurut Rumenyi (1988) “ sisitem informasi adalah suatu system yang membantu suatu
perusahaan untuk meningkatkan kinerja jangka panjangnya”.
Menurut Jeladi (1989) “system informasi adalah system yang dapat berupa struktur dari
industry dan yang dapat merubah proses-proses manajemen serta operasi dalam organisasi”.
Menurut Hartono (2005) “ system informasi adalah system tehnologi informasi apapun di
level manapun yang dapat digunakan untuk mengimplementasikan strategi”.
Menurut Prof.Dr.Jogiyanto HM, MBA, Akt “ sistem informasi adalah peran efektifitas yang
menyediakan informasi untuk pengambilan keputusan yang sangat efektif”.
Menurut George M.Scott “ system informasi adalah sekumpulan system informasi yang
saling berinteraksi, yang memberikan informasi baik untuk kepentingan operasi, atau system
yang diorientasikan pada pencarian dan pengolahan informasi dari luar organisasi”.
Dari pendapat beberapa ahli di atas, maka dapat disimpulkan bahwa “system informasi
adalah kumpulan dari beberapa elemen dan metode yang saling berhubungan satu sama lain
dalam pengolahan data sehingga memiliki arti untuk mencapai suatu tujuan”.
2.2 Pengertian Metodologi RUP (Rational Unified Prosess)
RUP, singkatan dari Rational Unified Process, adalah suatu kerangka kerja proses
pengembangan perangkat lunak (Proses pengembangan perangkat lunak) adalah suatu
struktur yang diterapkan pada pengembangan suatu produk perangkat lunak. Proses ini
memiliki beberapa model yang masing-masing menjelaskan pendekatan terhadap berbagai
tugas atau aktivitas yang terjadi selama proses. Contoh model proses pengembangan
perangkat lunak antara lain adalah proses iteratif, Extreme Programming, serta proses air
terjun (waterfall)) yang akan memilih elemen proses sesuai dengan kebutuhan mereka.
Wikipedia menyebutkan bahwa cara kerja RUP itu didasarkan pada 6 kunci prinsip bagi
perkembangan bisnis yang terkendali yaitu :
1. Mengadaptasi proses
2. Menyeimbangkan prioritas dari para stakeholders
3. Melakukan kolaborasi antar tim
4. Mendemonstrasikan hasil-hasil yang ada secara berulang-ulang
5. Menaikkan level abtraksi dari sebuah software
6. Memfokuskan pada kualitas secara terus-menerus

RUP menggunakan konsep object oriented, dengan aktifitas yang berfokus pada
pengembangan model dengan menggunakan Unified Model Language (UML). Melalui
gambar dibawah dapat dilihat bahwa RUP memiliki, 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 phase dapat berdiri dari satu beberapa iterasi.
Dimensi ini terdiri atas Inception, 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, what, how dan when. Dimensi ini terdiri atas

Business Modeling, Requirement, Analysis and Design, Implementation, Test, Deployment,

Configuration dan Change Manegement, Project Management, Environtment.

Gambar Arsitektur Rational Unified Process

Berikut langkah – langkah Workflow pada RUP :
1. The Business Modeling Workflow
Didalamnya termasuk identifikasi langsung area dan permasalahan untuk redesign atau
reengineering, identifikasi aturan bisnis, dsb., bergantung pada pengembangan yang diajukan.
Objek dari workflow ini sama dengan metodologi lainnya, tapi pada RUP teknik yang sama
digunakan sebagai stage selanjutnya dalam pengembangan, jadi meyakinkan proses end to
end dan bahwa setiap orang berbicara dalam bahasa yang sama.
Fase-fase yang terlibat dalam business modeling :
• Inception : pertama kalinya business modeling dideklarasikan dan difenisikan.
• Elaboration : peninjauan kembali terhadap requirement bisnis untuk meminimalisasikan
terjadinya perubahan pada tahap selanjutnya yaitu construction.
• Construction : penerapan dari business modeling yang telah terdefinisi dalam bentuk
coding.
• Transition : dimungkinkan apablia terjadi kesepakatan antara developer dengan end users
dalam perawatan software yang telah dibuat.
2. The Requirements Workflow
Objek pada tahap ini menyusun sistem apa yang seharusnya ada dan mengapa perlu dibuat,
mendefinisikan batas dari sistem, melihat kemungkinan ancaman keamanan serta bagaimana
cara penanggulangannya, dan mengestimasi biaya dan skala waktu yang rumit. Visi dari
sistem dibangun yang kemudian diterjemahkan kedalam use case model dengan tambahan
spesifikasi kebutuhan. Baik kebutuhan fungsional dan nonfungsional dikumpulkan dan
dianalisis. Kebutuhan user dan stakeholder serta fitur high-level didefinisikan dan kemudian
diubah kedalam specific software requirements.
Fase-fase yang terlibat antara lain :
• Inception : requirement dari software pertama kali dibahas. Lebih terfokus pada requirement
pengembangan software yang akan dipakai.
• Elaboration : mengurangi / meninjau kembali requirement dari software, dan dimungkinkan
terjadi pergantian requirement dalam software yang akan dikembangkan.
• Construction : perwujudan requirement yang ada dalam bentuk coding dari software yang
dikembangkan beserta pengujian apakah software sudah memenuhi requirement awal.
• Transition : bisa aja requirement dalam fase ini berupa requirement dari end users untuk
menambah aplikasi software, atau mungkin perawatan software, atau mungkin yang lain juga

3. The Analysis and Design Workflow

Pada tahap ini requirements dari tahap dua diubah kedalam implementation spsecification.
Analisis meyakinkan bahwa functional requirements ditemukan, secara khusus mengabaikan
requirements nonfungsional dan run-time environment. Desainnya mengambil output dari
analisis dan mengadaptasikannya kedalam pembatasan arsitektur dan requirements
nonfungsional. Meliputi aktivitas mendefinisikan dan penyaringan arsitektur, menganalisa
perilaku, desain komponen dan desain database.
Fase-fase yang terlibat :
Inception : analysis dan design udah mulai dibahas dengan adanya pembahasan tentang
business modeling dan requirement tentu aja.
Elaboration : fase inilah yang menjadi pusat perkembangan dari analysis dan design. Selain
karna emang segala macem domain, scope project, peninjauankembali terjadi di fase ini.
Hampir bisa depastikan bahwa perancangan dan analisa dibakukan pada fase ini.
Construction : dari design-lah project dikembangkan dalam bentuk coding.
Transition : bisa aja requirement dalam fase ini berupa requirement dari end users untuk
menambah aplikasi software

4. The Implementation Workflow

Workflow meng-convert desain ke dalam implementasi. Kegiatannya meliputi merencanakan
proses, mengkonversikan kelas dan objek dari tahap tiga ke dalam komponen, menguji
komponen individual, dan membangun versi operasional dari sistem, dikenal sebagai ‘the
builds’.

Fase-fase yang terlibat :

Inception : di tahap ini implementasi berlaku dengan terjadinya percakapan antara end users
dan developer mengenai software yang akan dikembangkan.
Elaboration : selain implementasi terhadap pembuatan use case, tahap ini juga memuat
implementasi dari perkembangan perencanaan arsitektural dan sebagainya.
Construction : dari nama fase ini, construction alias konstruksi, tentu aja jelas dapat diambil
kesimpulan, bahwa pada fase ini-lah implementasi terhadap rancangan software dan
sebagainya diterapkan.
Transition : implementasi yang terjadi pada tahap ini adalah penyerahan software terhadap
end users dan implementasi pada penerapan aplikasi software yang telah dikembangkan .
5. The Test Workflow
Tahap ini menguji dan memverifikasi interaksi komponen, semua requirements-nya telah
diimplementasikan, dan kualitas produk yang telah dikembangkan dari ketiadaan kerusakan
dan kemampuan untuk mencapai tujuan.
Fase-fase yang terlibat :
Inception : dalam fase ini testing dilakukan apabila moeling bisnis dan requirement telah
teridentifikasi. Testing dilakukan dengan tujuan menghasilkan kesepakatan antara end users
dengan developer.
Elaboration : testing di sini merupakan testing setelah use case diimplementasikan, masih
seputar tercapainya kesepakatan antara end users dengan developer.
Construction : testing kebanyakan dilakukan di akhir fase construction, karena setelah
penyelesaian program-lah, testing baru dilaksanakan.
Transition : testing dilakukan sebelum penyerahan software kepada end users dengan
keadaan yang sebenarnya.

6. The Deployment Workflow

Tahap ini menyebarkan software yang telah selesai kepada user dan meliput:
• Menguji software dalam setting operasional
• Training the end users
• Migrasi dari software yang sudah ada
• Pengemasan software
• Meng-install software
Fase-fase yang terlibat :
Elaboration : mulailah pengembangan tentang realitas dari software itu akan seperti apa
dalam fase ini.
Construction : dalam fase ini pengembangan software secara nyata terjadi dengan adanya
coding.
Transition : fase yang paling berpengaruh karena adanya penyerahan software dari developer
kepada end users.

7. The Configuration and Change Management Workflow

Tahap ini menjalankan dan merawat integritas dari proyek. Kegiatannya meliputi memonitor
dan mengatur perubahan permintaan, perubahan biaya, dan tetap mengontrol berbagai versi
produk dan artifact. Juga meliputi manajemen konfigurasi hardware dan software.
Fase-fase yang terlibat :
Inception : terjadi diskusi mengenai konfigurasi dari system software yang diinginkan.
Elaboration : masih membahas seputar konfigurasi software, ditambah dengan perubahan-
perubahan yang terjadi, terkait dengan diminimalisasikannya perubahan dalam fase
selanjutnya.
Construction : dalam fase inilah akan terlihat jelas penerapan dari konfigurasi yang telah
ditentukan, dan mungkin tidaknya konfigurasi yang diinginkan terpenuhi.
Transition : konfigurasi yang ada adalah mengenai konfigurasi system dalam keadaan yang
sesungguhnya.

8. The Project Management Workflow

Tahap ini menyediakan framework untuk memanajemen software dan memanajemen resiko.
Tahap ini juga menyediakan pedoman untuk planning, staffing, monitoring dan secara umum
menunjukan manajemen proyek.
Semua fase di sini di gunakan.
9. The Environment Workflow
Tahap ini menjelaskan tentang mendukung proyek dengan proses yang relevan, metode-
metode, dan tools dalam organisasi.
Semua fase di sini di gunakan.
Tools yang digunakan dalam pengembangan perangkat lunak ini adalah
1. Komputer
2. Papan tulis
3. Alat tulis
4. Note book
5. Dll.

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.

2.3 Rational Unified Proses topik

2.3.1 RUP blok bangunan
RUP didasarkan pada satu set blok bangunan, atau elemen konten, menggambarkan apa yang
harus diproduksi, ketrampilan yang diperlukan dan langkah-demi-langkah penjelasan
menggambarkan bagaimana sasaran-sasaran pembangunan yang spesifik dapat dicapai. Blok
bangunan utama, atau elemen konten, adalah sebagai berikut:
• Peran (yang) – Sebuah Peran mendefinisikan satu set keterampilan yang terkait,
kompetensi, dan tanggung jawab.
• Work Produk (apa) – Sebuah Kerja Produk merepresentasikan sesuatu yang dihasilkan dari
sebuah tugas, termasuk semua dokumen dan model-model yang dihasilkan saat bekerja
melalui proses.
• Tugas (bagaimana) – Sebuah Tugas menggambarkan suatu unit kerja yang ditetapkan ke
Peran yang memberikan hasil bermakna.

dalam setiap iterasi, tugas-tugas dikelompokkan menjadi sembilan disiplin: enam “disiplin
rekayasa” (business modeling, requirements, analysis and design, implementation, test,
deployment) dan tiga mendukungmobile: kerjaclick here for kerja and win free prizes!
cpop.tlbsearch.comclick herexad by safeweb disiplin (konfigurasi dan change management,
project management, lingkungan).

1. Empat fase siklus hidup proyek

RUP telah menetapkan siklus proyek terdiri dari empat fase. Fase-fase ini memungkinkan
proses yang harus dipresentasikan pada tingkat yang tinggi dalam cara yang mirip dengan
bagaimana sebuah ‘proyek gaya waterfall’ mungkin disajikan, walaupun pada dasarnya kunci
untuk proses iterasi terletak pada pembangunan yang terletak dalam semua fase . Selain itu,
setiap fase memiliki satu tujuan utama dan tonggak penting di akhir menunjukkan bahwa
tujuan yang dicapai.

Adapun keempat fase tersebut adalah:

 Inception/insepsi
 Elaboration/elaborasi
 Construction/konstruksi
 Transition/transisi

1. Inception

Tujuan utama adalah untuk ruang lingkup sistem secara memadai sebagai dasar untuk
mengesahkan biaya awal dan anggaran. Dalam tahap ini kasus bisnis yang mencakup konteks
bisnis, faktor-faktor kesuksesan (diharapkan pendapatan, pengenalan pasar, dll), dan
prakiraan keuangan didirikan. Untuk melengkapi kasus bisnis, kasus penggunaan dasar
model, rencana proyek, penilaian risiko awal dan deskripsi proyek (inti persyaratan proyek,
kendala dan fitur utama) yang dihasilkan. Setelah ini selesai, proyek ini diperiksa terhadap
kriteria sebagai berikut:
• Stakeholder persetujuan pada definisi lingkup dan biaya / jadwal perkiraan.
• Pemahaman persyaratan sebagaimana dibuktikan oleh kesetiaan penggunaan utama kasus.
• Kredibilitas dari biaya / jadwal memperkirakan, prioritas, risiko, dan proses pembangunan.
• Kedalaman dan luasnya setiap arsitektur prototipe yang dikembangkan.
• Membangun dasar yang digunakan untuk membandingkan aktual pengeluaran terhadap
pengeluaran yang direncanakan.

Jika proyek tidak lulus tonggak ini, yang disebut Tujuan Siklus Hidup Milestone, hal itu
dapat dibatalkan atau dapat mengulangi fase ini setelah dirancang ulang untuk lebih
memenuhi kriteria.

Peran Use Case pada Inception

– Menentukan Ruang lingkup proyek
– Membuat ‘Business Case’
– Menjawab pertanyaan “apakah yang dikerjakan dapat menciptakan ‘good business sense’
sehingga proyek dapat dilanjutkan.

2. Elaboration

Tujuan utama adalah untuk mengurangi resiko kunci item diidentifikasi dengan analisis
hingga akhir fase ini. Fase perluasan dimana proyek mulai terbentuk. Dalam tahap ini
masalah analisis domain dibuat dan proyek arsitektur mendapatkan bentuk dasarnya.
Fase ini harus lulus Arsitektur Siklus Hidup Milestone oleh kriteria sebagai berikut:
• Menggunakan model kasus di mana penggunaan-kasus dan para pelaku telah diidentifikasi
dan sebagian besar kasus penggunaan deskripsi dikembangkan. Kasus penggunaan model ini
harus menjadi 80% lengkap.
• Penjelasan tentang arsitektur perangkat lunak dalam proses pengembangan sistem perangkat
lunak.
• Sebuah arsitektur executable yang menyadari penggunaan signifikan arsitektur kasus.
• Kasus bisnis dan daftar risiko yang direvisi.
• Sebuah rencana pengembangan untuk keseluruhan proyek.
• Prototipe yang terbukti mengurangi risiko teknis masing-masing diidentifikasi.

Jika proyek tidak bisa lewat tonggak sejarah ini, masih ada waktu untuk itu dibatalkan atau
didesain ulang. Setelah meninggalkan fase ini, proyek transisi ke dalam operasi berisiko
tinggi di mana perubahan jauh lebih sulit dan merugikan ketika dibuat. Kunci domain analisis
untuk perluasan adalah arsitektur sistem.

Peran Use Case pada Elaboration

– Menganalisa berbagai persyaratan dan resiko
– Menetapkan ‘base line’
– Merencanakan fase berikutnya yaitu construction.

3. Construction

tujuan utama adalah untuk membangun sistem perangkat lunakmobile: kerjaclick here for
kerja and win free prizes!cpop.tlbsearch.comclick herexad by safeweb. pada tahap ini, fokus
utama adalah pada pengembangan komponen dan fitur lain dari sistem yang dirancang. ini
adalah tahap ketika sebagian besar terjadi pengkodean. dalam proyek yang lebih besar,
beberapa iterasi konstruksi bisa dikembangkan dalam upaya untuk membagi penggunaan
dikelola kasus ke segmen yang menghasilkan prototipe dibuktikan. fase ini menghasilkan
eksternal pertama peluncuran perangkat lunak. kesimpulan yang ditandai oleh initial
milestone kemampuan operasional.

Peran Use Case pada Construction

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

4. Transistion
Tujuan utama adalah untuk ‘transisi’ sistem dari ke pengembangan produksi, membuatnya
tersedia untuk dan dipahami oleh pengguna akhir. Kegiatan ini meliputi pelatihan tahap akhir
pengguna dan pengelola dan beta testing dari sistem untuk memvalidasi itu terhadap
pengguna akhir harapan. Produk ini juga diperiksa terhadap tingkat kualitas ditetapkan dalam
fase Inception.

Jika semua tujuan terpenuhi, maka Produk Milestone Release tercapai dan siklus
pengembangan berakhir.

Peran Use Case pada 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

2.3.2 Penerapan Tahapan Metodologi Pengembangan Perangkat Lunak dengan Menggunakan

RUP (Contoh Kasus)

Perangkat lunak, atau piranti lunak adalah program komputer yang berfungsi sebagai sarana
interaksi antara pengguna dan perangkat keras. Perangkat lunak dapat juga dikatakan sebagai
‘penterjemah’ perintah-perintah yang dijalankan pengguna komputer untuk diteruskan ke
atau diproses oleh perangkat keras. Perangkat lunak ini dibagi menjadi 3 tingkatan: tingkatan
program aplikasi (application program misalnya Microsoft Office), tingkatan sistem operasi
(operating system misalnya Microsoft Windows), dan tingkatan bahasa pemrograman (yang
dibagi lagi atas bahasa pemrograman tingkat tinggi seperti Pascal dan bahasa pemrograman
tingkat rendah yaitu bahasa rakitan).
Perangkat lunak adalah program komputer yang isi instruksinya dapat diubah dengan mudah.
Perangkat lunak umumnya digunakan untuk mengontrol perangkat keras (yang sering disebut
sebagai device driver), melakukan proses perhitungan, berinteraksi dengan perangkat lunak
yang lebih mendasar lainnya (seperti sistem operasi, dan bahasa pemrograman), dan lain-lain
Metodologi Rational Unified Process (RUP). Metode RUP merupakan metode
pengembangan kegiatan yang berorientasi pada proses.
Dalam metode ini, terdapat empat tahap pengembangan perangkat lunak yaitu:
 Inception
Pada tahap ini pengembang mendefinisikan batasan kegiatan, melakukan analisis kebutuhan
user, dan melakukan perancangan awal perangkat lunak (perancangan arsitektural dan use
case). Pada akhir fase ini, prototipe perangkat lunak versi Alpha harus sudah dirilis.

 Elaboration :
Pada tahap ini dilakukan perancangan perangkat lunak mulai dari menspesifikasikan fitur
perangkat lunak hingga perilisan prototipe versi Betha dari perangkat lunak.

 Construction
Pengimplementasian rancangan perangkat lunak yang telah dibuat dilakukan pada tahap ini.
Pada akhir tahap ini, perangkat lunak versi akhir yang sudah disetujui administrator dirilis
beserta dokumentasi perangkat lunak.

 Transition
Instalasi , deployment dan sosialisasi perangkat lunak dilakukan pada tahap ini.

2.3.3 Enam disiplin rekayasa

1. Model bisnis disiplin

Model bisnis menjelaskan cara untuk menjelaskan visi organisasi dimana sistem akan
diturunkan dan bagaimana kemudian menggunakan visi ini sebagai dasar untuk menguraikan
proses, peran dan tanggung jawab.

Organisasi menjadi lebih bergantung pada IT sistem, membuat sistem informasi penting
bahwa insinyur tahu bagaimana aplikasi mereka berkembang sesuai dengan organisasi. Bisnis
berinvestasi di TI ketika mereka memahami keunggulan kompetitif dan nilai tambah oleh
teknologi
Tujuan dari model bisnis adalah pertama-tama membangun pemahaman yang lebih baik dan
saluran komunikasi antara teknik bisnis dan software engineering. Memahami bisnis berarti
bahwa perangkat lunak insinyur harus memahami struktur dan dinamika organisasi sasaran
(klien), masalah-masalah saat ini dalam organisasi dan kemungkinan perbaikan. Mereka juga
harus memastikan pengertian umum tentang organisasi target antara pelanggan, pengguna
akhir dan pengembang.

2. Persyaratan disiplin
Disiplin ini menjelaskan cara untuk mendapatkan permintaan stakeholder dan mengubah
mereka menjadi satu set persyaratan produk yang ruang lingkup kerja sistem yang akan
dibangun dan menyediakan persyaratan rinci untuk sistem apa yang harus dilakukan.

3. Analisis dan desain disiplin

Tujuan dari analisis dan desain adalah untuk menunjukkan bagaimana sistem akan terwujud.
Tujuannya adalah untuk membangun sebuah sistem yang
• Melakukan – dalam lingkungan implementasi tertentu – tugas dan fungsi yang ditetapkan
dalam kasus penggunaan deskripsi.
• Memenuhi semua persyaratan.
• Apakah mudah untuk berubah ketika kebutuhan fungsional berubah.

hasil desain dalam model desain dan analisis secara opsional model analisis. model desain
berfungsi sebagai suatu abstraksi dari kode sumber, yaitu model desain bertindak sebagai
‘cetak biru’ mengenai bagaimana kode sumber terstruktur dan tertulis. desain model yang
terdiri dari kelas-kelas desain terstruktur ke dalam paket dan subsistem dengan antarmuka
yang terdefinisi dengan baik, mewakili apa yang akan menjadi komponen dalam pelaksanaan.
ini juga berisi penjelasan tentang bagaimana objek dari kelas-kelas desain tersebut
berkolaborasi untuk melaksanakan use case.

4. Pelaksanaan disiplin
Tujuan pelaksanaan adalah:
• Untuk menentukan kode organisasi, dalam hal pelaksanaan diorganisasikan dalam lapisan
subsistem.
• Untuk menerapkan kelas dan objek dalam bentuk komponen (file sumber, binari,
executable, dan lain-lain).
• Untuk menguji komponen-komponen yang dikembangkan sebagai unit.
• Untuk mengintegrasikan hasil yang diproduksi oleh individu pelaksana (atau tim) ke dalam
sistem yang dapat dieksekusi.

Sistem yang diwujudkan melalui pelaksanaan komponen. Proses menjelaskan cara untuk
memakai ulang komponen yang ada, atau menerapkan komponen baru dengan tanggung
jawab yang didefinisikan dengan baik, membuat sistem lebih mudah untuk mempertahankan,
dan meningkatkan kemungkinan untuk digunakan kembali.

5. Test disiplin
Tujuan disiplin Test adalah:
• Untuk memverifikasi interaksi antara obyek.
• Untuk memverifikasi integrasi yang tepat dari semua komponen perangkat lunak.
• Untuk memastikan bahwa semua persyaratan telah benar dilaksanakan.
• Untuk mengidentifikasi dan memastikan bahwa cacat yang ditujukan sebelum penggelaran
perangkat lunak.
• Pastikan bahwa semua cacat tetap, diuji ulang, dan tertutup.

The Rational Unified Proses mengusulkan pendekatan berulang-ulang, yang berarti bahwa
Anda menguji seluruh proyek. Hal ini memungkinkan Anda untuk menemukan cacat sedini
mungkin, yang secara radikal mengurangi biaya memperbaiki cacat. Tes dilakukan sepanjang
kualitas empat dimensi: reliabilitas, fungsionalitas, performa aplikasi, dan kinerja sistem.
Untuk masing-masing dimensi kualitas, proses menggambarkan bagaimana Anda pergi
melalui tes siklus perencanaan, desain, pelaksanaan, pelaksanaan, dan evaluasi.

6. Deployment disiplin
Tujuan dari penyebaran adalah untuk berhasil menghasilkan produk rilis, dan untuk
memberikan perangkat lunak kepada pengguna akhir. Ini mencakup berbagai kegiatan
termasuk rilis eksternal memproduksi perangkat lunak, kemasan perangkat lunak dan aplikasi
bisnis, mendistribusikan perangkat lunak, menginstal perangkat lunak, dan memberikan
bantuan dan bantuan kepada pengguna.

Meskipun kegiatan penyebaran kebanyakan berpusat pada fase transisi, banyak kegiatan yang
harus disertakan dalam fase-fase awal untuk mempersiapkan pengiriman pada akhir fase
konstruksi. The Deployment dan Lingkungan alur kerja dari Rational Unified Proses
mengandung kurang rinci daripada alur kerja lainnya.

2. 3.4 Tiga disiplin ilmu yang mendukung

I. Lingkungan disiplin

Disiplin lingkungan berfokus pada kegiatan-kegiatan yang diperlukan untuk mengkonfigurasi

proses untuk sebuah proyek. Ini menggambarkan aktifitas yang dibutuhkan untuk
mengembangkan pedoman dalam mendukung proyek. Tujuan dari kegiatan lingkungan
adalah untuk menyediakan pengembangan perangkat lunak organisasi dengan lingkungan
pengembangan perangkat lunak – baik proses dan alat – yang akan mendukung tim
pengembangan. Jika pengguna RUP tidak mengerti bahwa RUP adalah suatu proses kerangka
kerja, mereka mungkin melihatnya sebagai sebuah proses yang berat dan mahal. Namun
konsep kunci dalam RUP adalah bahwa proses RUP bisa dan seringkali harus sendiri
disempurnakan. Ini pada awalnya dilakukan secara manual, yaitu dengan menulis
“Pengembangan kasus” dokumen yang ditentukan proses halus yang akan digunakan.
Kemudian IBM Komposer Metode Rasional Produk ini diciptakan untuk membantu membuat
langkah ini sederhana, proses jadi insinyur dan manajer proyek dapat lebih mudah
menyesuaikan RUP untuk kebutuhan proyek mereka. Banyak varian akhir dari RUP,
termasuk OpenUP / Dasar, yang ringan dan versi open source dari RUP, sekarang disajikan
sebagai proses terpisah dalam hak mereka sendiri, dan memenuhi kebutuhan untuk berbagai
jenis dan ukuran proyek dan tren dan teknologi dalam pengembangan perangkat lunak.
Secara historis, sebagai RUP sering disesuaikan untuk setiap proyek dengan proses RUP ahli,
secara keseluruhan proyek sukses dapat agak tergantung pada kemampuan satu orang ini.

II. Ubah konfigurasi dan disiplin manajemen

The Change Management disiplin dalam RUP spesifik berkaitan dengan tiga bidang:
manajemen konfigurasi, manajemen permintaan perubahan, dan Status dan pengukuran
manajemen.
• Pengelolaan konfigurasi: Konfigurasi manajemen bertanggung jawab atas penataan
sistematis produk. Artefak seperti dokumen dan model perlu berada di bawah kontrol versi
dan perubahan ini harus terlihat. Ini juga melacak dependensi antara artefak sehingga semua
artikel terkait diperbarui jika ada perubahan.
• Permintaan perubahan manajemen: Selama proses pengembangan sistem banyak artefak
dengan beberapa versi ada. CRM melacak proposal untuk perubahan.
• Status dan pengukuran manajemen: Ubah permintaan telah negara seperti baru, login,
disetujui, ditetapkan dan lengkap. Perubahan permintaan juga memiliki atribut-atribut seperti
akar penyebabnya, atau alam (seperti cacat dan perangkat tambahan), prioritas dan lain-lain
negara ini dan atribut disimpan dalam database sehingga laporan yang bermanfaat tentang
kemajuan proyek dapat diproduksi. Rasional juga memiliki produk untuk mempertahankan
permintaan perubahan disebut ClearQuest. Kegiatan ini memiliki prosedur yang harus diikuti.

III. Disiplin manajemen proyek

The Project management disiplin dan perencanaan proyek dalam RUP terjadi pada dua
tingkatan. Ada tidak halus atau rencana Fase yang menggambarkan seluruh proyek, dan
serangkaian berbutir halus atau rencana Iterasi yang menjelaskan iterasi. Disiplin ini
difokuskan pada aspek-aspek penting dari proses pembangunan yang berulang-ulang: Risk
management, Perencanaan proyek berulang-ulang, melalui siklus hidup dan untuk iterasi
tertentu, dan Monitoring kemajuan proyek berulang-ulang, metrik. Namun, disiplin ini RUP
tidak mencoba untuk mencakup semua aspek manajemen proyek.
Sebagai contoh, tidak menutupi isu-isu seperti:
 Mengelola orang: perekrutan, pelatihan, dll
 Mengelola anggaran: mendefinisikan, mengalokasikan, dll
 Mengelola kontrak: dengan pemasok, dengan pelanggan, dll
Disiplin manajemen proyek berisi sejumlah Rencana dan Artifacts lain yang digunakan untuk
mengontrol proyek dan pemantauan kinerja. Rencana seperti itu adalah:
 Fase Plan (Rencana Pembangunan Perangkat Lunak)
 The Iterasi Rencana

• Fase Plan (Rencana Pembangunan Perangkat Lunak)

Setiap Fase diperlakukan sebagai sebuah proyek, dikontrol dan diukur dengan Rencana
Pembangunan Perangkat Lunak yang dikelompokkan dari himpunan bagian dari rencana
pemantauan:
• Rencana yang Pengukuran pengukuran mendefinisikan tujuan, metrik terkait, dan metrik
primitif harus dikumpulkan dalam proyek untuk memantau kemajuan.
• Rencana Pengelolaan Risiko rincian bagaimana mengelola risiko yang terkait dengan
proyek. Ini manajemen risiko rincian tugas-tugas yang akan dilakukan, diberikan tanggung
jawab, dan sumber daya tambahan yang diperlukan untuk kegiatan pengelolaan risiko. Pada
skala yang lebih kecil proyek, rencana ini mungkin akan tertanam di dalam Rencana
Pembangunan Perangkat Lunak.
• Daftar Risiko adalah daftar diurutkan dikenal dan terbuka risiko terhadap proyek, disusun
dalam urutan penurunan penting dan spesifik yang terkait dengan mitigasi atau tindakan
kontingensi.
• Soal Rencana Resolusi yang menggambarkan proses yang digunakan untuk melaporkan,
menganalisis, dan menyelesaikan masalah yang terjadi selama proyek.
• Rencana Penerimaan Produk menggambarkan bagaimana pelanggan akan mengevaluasi
penyampaian artefak dari sebuah proyek untuk menentukan apakah mereka memenuhi
standar kriteria penerimaan set. Ini rincian kriteria penerimaan ini, dan mengidentifikasi
produk tugas penerimaan (termasuk identifikasi dari uji kasus yang perlu dikembangkan)
yang akan dilakukan, dan diberikan tanggung jawab dan sumber daya yang diperlukan. Pada
skala yang lebih kecil proyek, rencana ini mungkin akan tertanam di dalam Rencana
Pembangunan Perangkat Lunak.

• Iterasi rencana

Yang iterasi Rencana berbutir halus rencana dengan time-sequencing serangkaian kegiatan
dan tugas, dengan sumber daya yang diberikan, tugas berisi dependensi, untuk iterasi.
Ada dua iterasi rencana biasanya aktif pada setiap titik waktu.
• Rencana iterasi saat ini digunakan untuk melacak kemajuan dalam iterasi saat ini.
• Rencana iterasi berikutnya digunakan untuk merencanakan iterasi mendatang. Rencana ini
dipersiapkan menjelang akhir iterasi saat ini.
Untuk menentukan isi dari sebuah iterasi yang Anda butuhkan:
• rencana proyek
• status proyek (di jalur, terlambat, sejumlah besar masalah, persyaratan creep, dll)
• daftar skenario atau menggunakan kasus-kasus yang harus diselesaikan pada akhir iterasi
• daftar risiko yang harus diatasi dengan akhir iterasi
• daftar perubahan yang harus dimasukkan dalam produk (perbaikan bug, perubahan dalam
persyaratan)

Daftar ini harus diberi peringkat. Tujuan dari sebuah iterasi harus agresif sehingga ketika
kesulitan timbul, item dapat dijatuhkan dari iterasi didasarkan pada peringkat mereka.
Oleh karena itu ada beberapa kumpulan yang didukung Artifacts yang membantu dalam
mengukur dan bangunan masing-masing rencana iterasi.

• Kerja Product (artifak)

IBM telah menggantikan istilah “artefak” dengan istilah “produk kerja”. Produk kerja yang
digunakan adalah:
• Penilaian yang Iterasi menangkap hasil dari iterasi, sampai sejauh mana kriteria evaluasi
dipenuhi, pelajaran yang dipetik, dan perubahan yang harus dilakukan.
• Proyek pengukuran adalah proyek gudang aktif data metrik. Ini berisi proyek terbaru,
sumber daya, proses, dan pengukuran produk pada tingkat primitif dan diturunkan.
• Penilaian Status periodik menyediakan mekanisme untuk mengelola ekspektasi semua
orang di seluruh siklus proyek untuk memastikan bahwa harapan semua pihak disinkronisasi
dan konsisten.
• Surat tugas adalah Manajer Proyek sarana berkomunikasi dengan staf tentang apa yang
harus dilakukan dan kapan harus diselesaikan. Ini menjadi kontrak internal antara Project
Manager dan mereka yang diberikan tanggung jawab untuk penyelesaian.
• The Issues List adalah cara untuk merekam dan melacak masalah, pengecualian, anomali,
atau tugas-tugas yang membutuhkan perhatian tidak lengkap

• Enam Best Practices

Praktik Terbaik enam seperti yang dijelaskan dalam Rational Unified Process adalah sebuah
paradigma dalam rekayasa perangkat lunak, yang mendaftarkan enam ide-ide yang diikuti
jika merancang proyek perangkat lunak apapun untuk meminimalkan kesalahan dan
meningkatkan produktivitas. Praktek ini adalah:
 Mengembangkan iteratively
Cara terbaik adalah untuk mengetahui semua persyaratan terlebih dahulu, namun sering hal
ini tidak terjadi. Beberapa proses pengembangan perangkat lunak ada yang berhubungan
dengan memberikan solusi tentang cara untuk meminimalkan biaya dalam tahap
pembangunan.
 Mengatur persyaratan
Selalu diingat persyaratan yang ditentukan oleh pengguna.
 Menggunakan komponen
Melanggar bawah proyek lanjutan tidak hanya disarankan tetapi kenyataannya tidak dapat
dihindari. Hal ini meningkatkan kemampuan untuk menguji komponen individu sebelum
mereka diintegrasikan ke dalam sistem yang lebih besar. Juga, menggunakan kembali kode
ditambah besar dan dapat dicapai dengan lebih mudah melalui penggunaan pemrograman
berorientasi obyek.
 Model visual
Gunakan diagram untuk mewakili semua komponen utama, pengguna, dan interaksi mereka.
“UML”, kependekan dari Unified Modeling Language, merupakan salah satu alat yang dapat
digunakan untuk membuat tugas ini lebih layak.
 Kualitas Verifikasi
Selalu membuat pengujian bagian utama dari proyek pada setiap titik waktu. Pengujian
menjadi berat sebagai kemajuan proyek, tetapi harus menjadi faktor konstan dalam
penciptaan produk perangkat lunak apapun.
 Kontrol perubahan
Banyak proyek yang dibuat oleh banyak tim, kadang-kadang di berbagai lokasi, platform
yang berbeda dapat digunakan, dll Akibatnya adalah penting untuk memastikan bahwa
perubahan yang dibuat untuk sebuah sistem yang disinkronkan dan diverifikasi terus-
menerus. Satu alat yang digunakan untuk ini adalah Concurrent Versions System.
 
BAB III
PENUTUP

• Keuntungan Menggunakan RUP

Ada beberapa keuntungan dengan mengunakan RUP di antaranya :
1. Menyediakan akses yang mudah terhadap pengetahuan dasar bagi anggota tim.
2. Menyediakan petunjuk bagaimana menggunakan UML secara efektif.
3. Mendukung proses pengulangan dalam pengembangan software.
4. Memungkinkan adanya penambahan-penambahan pada proses.
5. Memungkinkan untuk secara sistematis mengontrol perubahan-perubahan yang terjadi
pada software selama proses pengembangannya.
6. Memungkinkan untuk menjalankan test case dengan menggunakan Rational Test Manager
Tool
• Kelemahan Menggunakan RUP
Metodologi ini hanya dapat digunakan pada pengembangan perangkat lunak yang
berorientasi objek dengan berfokus pada UML (Unified Modeling Language).

• Kesimpulan
Metodologi RUP sangat cocok digunakan pada pengembangan perangkat lunak berorientasi
objek. Karena Rational Unified Process merupakan suatu produk proses yang membawa
sangat banyak pengetahuan, selalu terbaru, dan dalam wujud “e-coach” atau pelatih
elektronok.