Dalam karyanya yang berjudul Proses Terpadu, Ivar Jacobson, Grady Booch, dan James Rumbaugh membahas pentingnya menggunakan proses pengembangan perangkat lunak yang "use case driven, architecture-centric, iterative and incremental" sesuai dengan pandangan mereka:
Saat ini, ada kecenderungan pada pengembangan sistem perangkat lunak yang lebih besar dan kompleks. Hal ini terjadi karena komputer semakin kuat dari tahun ke tahun sehingga pengguna mengharapkan kemampuan yang lebih tinggi. Selain itu, penggunaan internet yang semakin luas turut memengaruhi tren ini karena memungkinkan pertukaran informasi yang lebih banyak. Setiap kali sebuah produk diluncurkan, kita belajar bagaimana produk tersebut dapat ditingkatkan sehingga keinginan kita untuk memiliki perangkat lunak yang semakin canggih semakin meningkat. Meskipun kita menginginkan perangkat lunak yang lebih baik sesuai dengan kebutuhan kita, keinginan ini justru membuat perangkat lunak semakin kompleks. Dengan kata lain, kita ingin lebih dari apa yang saat ini tersedia.
Unified process mencoba untuk menggabungkan fitur-fitur terbaik dari model-model proses perangkat lunak tradisional dengan mengadopsi prinsip-prinsip terbaik pengembangan perangkat lunak yang tangkas. Salah satu aspek yang ditekankan dalam unified process adalah pentingnya berkomunikasi dengan pelanggan dan menggunakan metode yang mudah dipahami untuk memahami pandangan pelanggan mengenai sistem (the use case). Selain itu, arsitektur perangkat lunak juga memiliki peran penting dan unified process membantu para arsitek untuk fokus pada tujuan yang tepat, seperti memahami ketergantungan pada perubahan di masa depan dan kemungkinan penggunaan kembali. Unified process juga menyarankan aliran proses yang berulang dan inkremental, sehingga memberikan sentuhan evolusioner yang penting dalam pengembangan perangkat lunak modern.
1.1 A Brief History
Pada awal tahun 1990-an, James Rumbaugh, Grady Booch, dan Ivar Jacobson bekerja sama untuk menciptakan "unified method" yang akan menggabungkan fitur-fitur terbaik dari analisis berorientasi objek dan metode desain serta memperkenalkan fitur tambahan yang diusulkan oleh pakar lain. Proyek ini menghasilkan UML, sebuah unified modeling language yang memiliki notasi yang kuat untuk pemodelan dan pengembangan sistem berorientasi objek. Pada tahun 1997, UML menjadi standar industri de facto untuk pengembangan perangkat lunak berorientasi objek.
Pembahasan ini menggunakan UML untuk merepresentasikan persyaratan dan model desain. Namun, presentasi yang lebih komprehensif tentang UML disarankan untuk dicari di buku teks yang secara khusus membahas subjek tersebut. Lampiran juga mencantumkan beberapa buku yang direkomendasikan untuk pembaca yang ingin mempelajari UML secara lebih mendalam.
UML menyediakan teknologi yang diperlukan untuk mendukung praktik rekayasa perangkat lunak berorientasi objek, namun tidak menyediakan kerangka kerja proses untuk membimbing tim proyek dalam menerapkan teknologinya. Untuk mengatasi hal ini, Jacobson, Rumbaugh, dan Booch mengembangkan Unified Process, suatu kerangka kerja untuk rekayasa perangkat lunak berorientasi objek menggunakan UML. Kerangka kerja ini, yang disebut Unified Process (UP), serta UML, saat ini digunakan secara luas pada semua jenis proyek berorientasi objek. Model proses iteratif dan inkremental yang diajukan oleh UP dapat dan seharusnya diadaptasi untuk memenuhi kebutuhan khusus dari setiap proyek.
1.2 Phases of the Unified Process
Pada pembahasan sebelumnya, telah dibahas lima aktivitas generik kerangka kerja yang dapat digunakan untuk menjelaskan model proses perangkat lunak apa pun, dan Unified Process tidak terkecuali. Gambar 1 menunjukkan "phases" UP dan menghubungkannya dengan aktivitas generik yang telah dijelaskan sebelumnya dalam Bab sebelumnya dan di bab ini.
UP memiliki fase awal yang terdiri dari komunikasi dengan pelanggan dan aktivitas perencanaan. Dalam kolaborasi dengan pemangku kepentingan, persyaratan bisnis untuk perangkat lunak diidentifikasi, arsitektur kasar sistem diusulkan, dan rencana untuk sifat iteratif dan inkremental dari proyek dikembangkan. Persyaratan bisnis dijelaskan melalui serangkaian kasus penggunaan awal yang menjelaskan fitur dan fungsi yang diinginkan oleh kelas utama pengguna. Arsitektur pada tahap ini hanya berupa garis besar dari subsistem utama dan fungsi serta fitur yang akan diterapkan. Namun, arsitektur ini akan diperbaiki dan diperluas menjadi satu set model yang mewakili pandangan yang berbeda dari sistem. Dalam perencanaan, sumber daya diidentifikasi, risiko utama dinilai, jadwal ditentukan, dan dasar untuk fase selanjutnya ditetapkan saat peningkatan perangkat lunak dikembangkan.
Fase elaborasi melibatkan aktivitas komunikasi dan pemodelan yang terkait dengan model proses generik Gambar 1. Pada tahap ini, kasus penggunaan awal yang telah dikembangkan pada fase sebelumnya diperluas dan diperinci, serta dilengkapi dengan representasi arsitektural yang mencakup lima tampilan perangkat lunak. Tampilan tersebut meliputi model kasus penggunaan, model persyaratan, model desain, model implementasi, dan model penyebaran. Pada beberapa kasus, elaborasi dapat menghasilkan baseline arsitektur yang dapat dieksekusi sebagai "pemotongan pertama" dari sistem yang dapat dieksekusi, yang menunjukkan kelayakan arsitektur tetapi belum menyediakan semua fitur dan fungsi yang dibutuhkan. Pada puncak fase elaborasi, rencana proyek dievaluasi untuk memastikan konsistensi dengan ruang lingkup, risiko, dan tanggal pengiriman. Pada tahap ini, rencana dapat dimodifikasi untuk memenuhi kebutuhan proyek yang sebenarnya.
Pada fase konstruksi UP, terdapat serangkaian aktivitas yang dilakukan untuk mengembangkan perangkat lunak generik. Proses ini dimulai dengan menggunakan model arsitektural sebagai pedoman dan mengembangkan atau memperoleh komponen perangkat lunak yang dibutuhkan agar setiap kasus penggunaan dapat dioperasikan oleh pengguna akhir. Tahap ini melibatkan penyelesaian persyaratan dan model desain yang dimulai pada fase sebelumnya, yaitu fase elaborasi, sehingga mencerminkan versi final dari penambahan perangkat lunak. Setelah itu, semua fitur dan fungsi yang dibutuhkan untuk peningkatan perangkat lunak diimplementasikan ke dalam kode sumber dan diuji melalui pengujian unit. Selain itu, dilakukan kegiatan integrasi untuk merakit komponen dan menguji integrasi. Untuk memastikan kelayakan sistem, kasus penggunaan digunakan untuk mendapatkan serangkaian tes penerimaan yang dijalankan sebelum memasuki fase UP berikutnya.
Fase transisi dalam UP merupakan tahap terakhir dari aktivitas konstruksi generik dan menjadi awal dari aktivitas penerapan generik (pengiriman dan umpan balik). Pada tahap ini, perangkat lunak telah diserahkan ke pengguna akhir untuk diuji coba sebagai beta tester dan pengguna memberikan umpan balik tentang cacat atau perubahan yang dibutuhkan. Tim pengembang juga membuat informasi dukungan yang diperlukan seperti manual pengguna, panduan pemecahan masalah, dan prosedur instalasi untuk melengkapi rilis perangkat lunak. Setelah fase transisi berakhir, perangkat lunak ditingkatkan menjadi rilis perangkat lunak yang siap digunakan.
Dalam fase produksi UP, terjadi penerapan dari proses perangkat lunak generik. Pada tahap ini, penggunaan perangkat lunak dipantau dan dukungan lingkungan operasional diberikan. Selain itu, laporan masalah dan permintaan perubahan dievaluasi dan direspons.
Mungkin terjadi bahwa pada saat fase konstruksi, transisi, dan produksi berlangsung, pengembangan perangkat lunak berikutnya sudah dimulai. Oleh karena itu, lima fase UP tidak selalu berlangsung secara berurutan, melainkan terjadi secara bersamaan.
Dalam setiap fase UP, alur kerja rekayasa perangkat lunak dilakukan secara terdistribusi. Alur kerja ini terdiri dari serangkaian tugas yang harus dilakukan untuk menyelesaikan tindakan rekayasa perangkat lunak yang penting, dan menghasilkan produk kerja yang sesuai dengan penyelesaian tugas yang berhasil. Perlu dicatat bahwa tidak semua tugas yang terdapat pada alur kerja UP harus dilakukan untuk setiap proyek perangkat lunak, karena tim dapat menyesuaikan proses (termasuk tindakan, tugas, subtugas, dan produk kerja) untuk memenuhi kebutuhan proyek yang berbeda.
Source: Pressman, Roger S. 2010. Software engineering : A Practitioner’s Approach (7th. Edition). New York: McGraw-Hill Higher Education.
Comments
Post a Comment