Metodologi RUP

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'.
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.
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
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.
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.

Metodologi RUP

Recommend Documents