Unified Process (UP) adalah kerangka kerja proses pengembangan perangkat lunak yang iterative dan incremental. Penyempurnaan Unified Process yang paling terkenal dan banyak didokumentasikan adalah Rational Unified Process (RUP). Contoh lain adalah OpenUP dan Agile Unified Process. Dalam buku seminal tentang Unified Process, Ivar Jacobson, Grady Booch, dan James Rumbaugh[1] membahas perlunya proses perangkat lunak yang "use case driven, arsitechture-centric, iterative, dan incremental". Dalam beberapa hal, unified process adalah upaya untuk memanfaatkan fitur dan karakteristik terbaik dari model proses perangkat lunak tradisional, namun mengkategorikannya dengan cara mengimplementasikan banyak prinsip terbaik dari agile software development. Unified process mengakui pentingnya komunikasi kepada pelanggan dan metode yang sederhana untuk menggambarkan pandangan pelanggan tentang suatu sistem (use case). Ini menekankan peran penting arsitektur perangkat lunak dan membantu arsitek fokus pada tujuan yang tepat, seperti understandability, bergantung pada perubahan di masa depan, dan penggunaan kembali [Jac99]. Model ini menganjurkan aliran proses yang iterative dan incremental, memberikan nuansa evolusi yang penting dalam pengembangan perangkat lunak modern.[2]
Sejarah
Selama awal 1990-an James Rumbaugh,[3] Grady Booch,[4] dan Ivar Jacobson [5] mulai bekerja pada "unified method" yang akan menggabungkan fitur terbaik dari analisis berorientasi objek dan metode desain setiap model dan mengadopsi fitur tambahan yang diusulkan oleh para ahli lain (misalnya,[6]) dalam pemodelan berorientasi objek. Hasilnya adalah UML — unified modelling language yang berisi notasi yang kuat untuk pemodelan dan pengembangan sistem berorientasi objek. Pada 1997, UML menjadi standar industri de facto untuk pengembangan perangkat lunak berorientasi objek. UML menyediakan teknologi yang diperlukan untuk mendukung praktik rekayasa perangkat lunak berorientasi objek, tetapi tidak memberikan kerangka kerja proses untuk memandu tim proyek dalam penerapan teknologi mereka. Selama beberapa tahun ke depan, Jacobson, Rumbaugh, dan Booch mengembangkan unified process, kerangka kerja untuk rekayasa perangkat lunak berorientasi objek menggunakan UML. Saat ini, Unified Process (UP) dan UML banyak digunakan pada proyek berorientasi objek dari semua jenis. Model iteratif, tambahan yang diusulkan oleh UP dapat dan harus disesuaikan untuk memenuhi kebutuhan proyek tertentu.[2]
Fase dalam Unified Process
Profil proyek tipikal yang menunjukkan ukuran relatif dari empat fase dalam Unified Process
Terdapat lima kegiatan dalam kerangka kerja umum dan dapat digunakan untuk menggambarkan model proses perangkat lunak apapun. Unified process tidak terkecuali.[2]
Fase awal (inception) UP mencakup komunikasi (comminication) pelanggan dan aktivitas perencanaan (planning). Dengan berkolaborasi dengan pemangku kepentingan, kebutuhan bisnis untuk perangkat lunak diidentifikasi; arsitektur kasar untuk sistem diusulkan; dan sebuah rencana untuk sifat iterative, sifat incremental dari proyek berikutnya dikembangkan. Kebutuhan bisnis mendasar dijelaskan melalui serangkaian use case awal yang menggambarkan fitur dan fungsi mana yang diinginkan oleh setiap kelas utama pengguna. Arsitektur pada titik ini tidak lebih dari garis besar tentatif dari subsistem utama dan fungsi dan fitur yang mengisi mereka. Nantinya, arsitektur akan disempurnakan dan diperluas menjadi seperangkat model yang akan mewakili pandangan berbeda dari sistem. Proses perencanaan mengidentifikasi sumber daya, menilai risiko utama, menentukan jadwal, dan menetapkan dasar untuk fase-fase yang akan diterapkan ketika peningkatan (increment) perangkat lunak dikembangkan.[2]
Tahap elaborasi (elaboration) meliputi kegiatan komunikasi dan pemodelan model proses generik. Pada tahap elaborasi, use case awal yang dikembangkan sebagai bagian dari fase awal (inception) dan memperluas representasi arsitektur untuk memasukkan lima pandangan yang berbeda dari perangkat lunak - use case model, model kebutuhan (requirement), model desain (design), model implementasi (implementation), dan model penyebaran (deployment) akan diperbaiki dan diperluas. Dalam beberapa kasus, elaborasi menciptakan "garis dasar arsitektur yang dapat dieksekusi" [7] yang mewakili "first cut" sistem yang dapat dieksekusi. Garis dasar arsitektur menunjukkan kelayakan arsitektur tetapi tidak menyediakan semua fitur dan fungsi yang diperlukan untuk menggunakan sistem. Selain itu, rencana tersebut ditinjau dengan saksama pada puncak fase elaborasi untuk memastikan bahwa ruang lingkup, risiko, dan tanggal pengiriman tetap masuk akal. Modifikasi rencana sering dilakukan pada saat ini.[2]
Fase konstruksi (construction) UP identik dengan aktivitas konstruksi yang ditentukan untuk proses perangkat lunak generik. Menggunakan model arsitektur sebagai input, fase konstruksi mengembangkan atau memperoleh komponen perangkat lunak yang akan membuat setiap use case operasional untuk pengguna akhir. Untuk mencapai hal ini, kebutuhan dan model desain yang dimulai selama fase elaborasi diselesaikan untuk mencerminkan versi akhir dari software increment. Semua fitur dan fungsi yang diperlukan untuk software increment (mis. Rilis) kemudian diimplementasikan dalam kode (source code). Ketika komponen sedang diimplementasi, unit test dirancang dan dieksekusi untuk masing-masing komponen. Selain itu, kegiatan integrasi (perakitan komponen dan pengujian integrasi) dilakukan. Use case digunakan untuk memperoleh serangkaian acceptance test yang dieksekusi sebelum dimulainya fase UP berikutnya.[2]
Fase transisi (transition) UP mencakup tahap selanjutnya dari aktivitas konstruksi generik (construction) dan bagian pertama dari aktivitas penyebaran (deployment) generik. Perangkat lunak diberikan kepada pengguna akhir untuk pengujian beta dan laporan umpan balik pengguna baik cacat maupun perubahan yang diperlukan. Selain itu, tim perangkat lunak membuat informasi dukungan yang diperlukan (mis., Buku petunjuk, panduan pemecahan masalah, prosedur pemasangan) yang diperlukan untuk rilis. Pada akhir fase transisi, software increment menjadi xperangkat lunak yang dapat digunakan.[2]
Fase produksi (production) UP bertepatan dengan aktivitas penyebaran (deployment) proses generik. Selama fase ini, penggunaan perangkat lunak yang sedang berlangsung dimonitor, dukungan untuk lingkungan operasi (infrastruktur) disediakan, dan laporan cacat serta permintaan untuk perubahan diajukan dan dievaluasi.[2]
Sangat mungkin bahwa pada saat yang tahap konstruksi, transisi, dan produksi sedang dilakukan, pekerjaan mungkin sudah dimulai pada software increment berikutnya. Ini berarti bahwa lima fase UP tidak terjadi secara berurutan, melainkan lebih cenderung bersamaan. Alur kerja rekayasa perangkat lunak didistribusikan di semua fase UP. Dalam konteks UP, alur kerja analog dengan set tugas Artinya, alur kerja mengidentifikasi tugas yang diperlukan untuk menyelesaikan tindakan rekayasa perangkat lunak yang penting dan produk kerja yang dihasilkan sebagai konsekuensi dari berhasil menyelesaikan tugas. Perlu dicatat bahwa tidak setiap tugas yang diidentifikasi untuk alur kerja UP dilakukan untuk setiap proyek perangkat lunak. Tim mengadaptasi proses (tindakan, tugas, subtugas, dan produk kerja) untuk memenuhi kebutuhannya.[2]
Referensi
Latihan
Tuliskan Requirement dan Model Desain untuk Aplikasi Technical Support System
