RAD Rapid Application Development

                                                            BAB I

PENDAHULUAN

1.1     Latar Belakang

Sistem Informasi adalah suatu sistem dalam suatu organisasi yang mempertemukan kebutuhan pengolahan transaksi harian, mendukung operasi, bersifat manajerial dan menyediakan kepada pihak luar tertentu dengan laporan-laporan yang diperlukan. Suatu sistem informasi yang baik tidak terlepas dari teknik dan langkah dalam membangunnya agar mampu memberikan kepuasan optimal kepada para penggunanya. Banyak teknik dan cara yang digunakan untuk membuat suatu sistem informasi. Untuk memahami dan mengetahui teknik dan langkah-langkah dalam membangun sebuah sistem informasi, diperlukan penjelesan lebih lanjut terhadap hal tersebut.

Siklus Hidup Informasi adalah salah satu metode yang digunakan untuk membangun sebuah sistem informasi dari tahap awal sampai pada akhirnya pada tahap penyelesaian serta pengaplikasiannya pada kehidupan nyata. Diantaranya dikenal dengan istilah Rapid Application Development, Hal tersebut akan dipahami lebih lanjut pada paparan materi dibawah sehingga mampu memberikan pengetahuan bagi para pembaca dan memberikan sedikit gambaran dalam hal teknik atau langkah pembangunan sebuah sistem.

1.2     Rumusan Masalah

Dari paparan latar belakang diatas dapat dirumuskan beberapa rumusan masalah, antara lain:

1.      Apakah pengertian dari Model Rapid Application Development?

2.      Bagaimanakah fase-fase dari Model Rapid Application Development?

3.      Apakah kelebihan dan kekurangan dari Model Rapid Application Development?

4.      Apakah Pengertian Metodologi RUP (Rational Unified Prosess)?

5.      Apa Rational Unified Proses topik?

1.3     Tujuan

Adapun tujuan dari penulisan makalh ini antara lain:

1.      Untuk mengetahui pengertian dari Model Rapid Application Development

2.      Untuk mengetahui Bagaimanakah fase-fase dari Model Rapid Application Development

3.      Untuk mengetahui kelebihan dan kekurangan dari Model Rapid Application Development

4.      Untuk mengetahui Pengertian Metodologi RUP (Rational Unified Prosess)

5.      Untuk mengetahui Rational Unified Proses topik

                  

BAB II

PEMBAHASAN

2.1     Pengertian RAD

            Rapid Aplication Development (RAD) adalah sebuah proses perkembangan perangkat lunak sekuensial linier yang menekankan siklus perkembangan yang sangat pendek. Model RAD ini merupakan sebuah adaptasi “kecepatan tinggi” dari model sekuensial linier dimana perkembangan cepat dicapai dengan menggunakan pendekatan konstruksi berbasis komponen. Jika kebutuhan dipahami dengan baik, proses RAD memungkinkan tim pengembangan menciptakan “sistem fungsional yang utuh” dalam periode waktu yang sangat pendek (kira-kira 60 sampai 90 hari).

2.2   Sejarah RAD

            Rapid Application Development ( RAD ) adalah istilah awalnya digunakan untuk menggambarkan proses pengembangan perangkat lunak pertama kali dikembangkan dan berhasil digunakan selama pertengahan 1970-an oleh Sistem Pusat Pengembangan New York Telephone Co di bawah arahan Dan Gielan. Setelah serangkaian implementasi sangat berhasil dari proses ini, Gielan kuliah secara ekstensif di berbagai forum pada metodologi , praktek, dan manfaat dari proses ini.

RAD melibatkan pengembangan dan pembangunan prototipe iteratif . Pada tahun 1990 , dalam buku RAD, Rapid Application Development, James Martin didokumentasikan penafsirannya tentang metodologi. Baru-baru ini, istilah dan singkatan yang telah datang untuk digunakan dalam lebih luas, pengertian umum yang mencakup berbagai metode yang bertujuan untuk mempercepat pengembangan aplikasi, seperti penggunaan kerangka perangkat lunak dari berbagai jenis, seperti kerangka kerja aplikasi web.

Pengembangan aplikasi yang cepat merupakan respon terhadap proses yang dikembangkan pada 1970-an dan 1980-an, seperti Structured Sistem Metode Analisis dan Desain dan model Waterfall lainnya. Satu masalah dengan metodologi sebelumnya adalah bahwa aplikasi begitu lama untuk membangun bahwa persyaratan telah berubah sebelum sistem itu selesai, sehingga sistem tidak memadai atau bahkan tidak dapat digunakan. Masalah lain adalah asumsi bahwa persyaratan metodis tahap analisis saja akan mengidentifikasi semua persyaratan penting. Membuktikan fakta bahwa ini adalah jarang terjadi, bahkan untuk proyek-proyek dengan profesional yang sangat berpengalaman di semua tingkatan.

Dimulai dengan ide-ide dari Brian Gallagher, Alex Balchin, Barry Boehm dan Scott Shultz, James Martin mengembangkan pendekatan pengembangan aplikasi yang cepat selama tahun 1980 di IBM dan akhirnya diresmikan itu dengan menerbitkan sebuah buku pada tahun 1991, Rapid Application Development.

2.3 Fase-Fase Model RAD

2.3.1Bussiness Modeling

Aliran informasi di antara fungsi-fungsi bisnis dimodelkan dengan suatu cara untuk menjawab pertanyaan-pertanyaan berikut : Informasi apa yang mengendalikan proses bisnis? Informasi apa yang dimunculkan? Siapa yang memunculkannya? Ke mana informasi itu pergi? Siapa yang memprosesnya?

2.3.2  Data Modeling

Aliran informasi yang didefinisikan sebagai bagian dari fase bussiness modeling disaring ke dalam serangkaian objek data yang dibutuhkan untuk menopang bisnis tersebut. Karakteristik masing-masing objek didefinisikan dan hubungan antara objek-objek tersebut didefinisikan.

2.3.3 Prosess Modeling

Objek data yang telah didefinisikan di dalam fase data modeling ditransformasikan untuk mencapai aliran informasi yang perlu bagi implementasi sebuah fungsi bisnis. Gambaran pemrosesan diciptakan untuk menambah, memodifikasi, menghapus atau mendapatkan kembali sebuah objek data.

2.3.4  Aplication Generation

            RAD mengasumsikan pemakaian teknik generasi keempat. Selain menciptakan perangkat lunak dengan menggunakan bahasa pemrograman general yang konvensional, RAD lebih banyak memproses kerja untuk mamakai lagi komponen program yang ada atau menciptakan komponoen yang bisa dipakai lagi. Pada semua kasus, alat-alat bantu otomatis dipakai untuk memfasilitasi konstruksi perangkat lunak.

2.3.5 Testing and Turnover

Karena proses RAD menekankan pada pemakaian kembali , banyak komponen program telah diuji. Hal ini mengurangi keseluruhan waktu pengujian. Tetapi komponen baru harus diuji dan semua interface harus dilatih secara penuh.

2.4     Kelebihan Penggunaan Model RAD

u  Dimungkinkan dalam proses pembuatan membutuhkan waktu yang sangat singkat (60-90 hari)

u  Menghemat biaya, karena penekannya adalah penggunaan komponen-komponen yang sudah ada

u  RAD menggunakan kembali komponen-komponen yang sudah ada, maka beberapa komponen program sudah diuji sehingga kita dapat melakukan penghematan waktu dalam uji coba

2.5  Kekurangan Penggunaan Model RAD

Seperti semua proses model yang lain, pendekatan RAD memiliki kekurangan-kekurangan sebagi berikut:

u  Bagi proyek yang besar tetapi berskala, RAD memerlukan sumber daya manusia yang memadai untuk menciptakan jumlah tim RAD yang baik.

u  RAD menuntut pengembangan dan pelanggan yang memiliki komitmen di dalam aktifitas rapid-fire yang diperlukan untuk melengkapi sebuah sistem, di dalam kerangka waktu yang sangat diperpendek. Jika komitmen tersebut tidak ada, proyek RAD akan gagal. RAD menekankan perkembangan komponen program yang bisa dipakai kembali. Reusable menjadi batu pertama teknologi objek dan ditemui di dalam proses rakitan komponen

u  Tidak semua aplikasi sesuai untuk RAD. Bila sistem tidak dapat dimodulkan dengan teratur, pembangunan komponen penting pada RAD akan menjadi sangat problematis.

u  RAD menjadi tidak sesuai jika risiko teknisnya tingggi. Hal ini terjadi bila sebuah aplikasi baru memforsir teknologi baru atau bila perangkat lunak baru membutuhkan tingkat interoperabilitas yang tinggi dengan program komputer yang ada.

2.6 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.7 Rational Unified Proses topik
2.7.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 mendukung 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 lunak. 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.7.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.7.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. 7.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:
v Fase Plan (Rencana Pembangunan Perangkat Lunak)
v 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

3.1  Kesimpulan
            Metodologi RUP sangat cocok digunakan pada pengembangan perangkat lunak berorientasi objek. Karena Rational Unified Process merupakan suatu produk proses yang membawa sangat banyak pengetaRapid Aplication Model (RAD) adalah sebuah proses perkembangan perangkat lunak sekuensial linier yang menekankan siklus perkembangan yang sangat pendek. Jika kebutuhan dipahami dengan baik, proses RAD memungkinkan tim pengembangan menciptakan “sistem fungsional yang utuh” dalam periode waktu yang sangat pendek (kira-kira 60 sampai 90 hari). Fase-Fase Model RAD meliputi Bussiness Modeling, Data Modeling, Prosess Modeling, Aplication Generation, dan Testing and Turnover. huan, selalu terbaru, dan dalam wujud “e-coach” atau pelatih elektronok.

3.2 Saran

Model rup dan rad merupakan perkembangan perangkat lunak yang baik dan terus berkembang dan di perbarui.