Untuk UML kita sering mendengarnya, terutama bagi mahasiswa jurusan ilmu komputer, teknik informatika, ataupun sistem informasi. Sementara UP, sepertinya jarang terdengar, terkadang kurikulum pun tidak memasukannya. Biasanya UP dipisahkan dengan UML karena UP merupakan bagian dari proses perancangan perangkat lunak. Terkadang juga masuk dalam materi analisa dan disain sistem informasi.
Untuk informasi mengenai apa itu UP bisa dilihat di internet, misalnya wikipedia yang sepertinya akurat, sesuai dengan teori yang ada. Untuk yang ingin detilnya bisa lihat rujukan buku milik Jim Arlow (Arlow & Neustadt, 2005) atau karangan Craig Larman (Larman, 2005).
Lalu hubungannya apa UP dengan UML? Sebelumnya ada istilah Rational Unified Process (RUP) yang merupakan benchmark IBM untuk menggambarkan proses perancangan perangkat lunak. Untuk menghindari penamaan pabrikan/vendor, tri-amigos: Ivar Jacobson, James Rumbaugh dan Grady Booch menerbitkan buku khusus UP. Mereka merupakan para pencetus UML, tool untuk penggambaran dan pemodelan sistem berbasis obyek. Jadi UP itu pemodelan dan framework proses sementara UML hasil dari prosesnya (masih dalam bentuk blue-print).
UP bersifat iteratif yang tiap iterasi terdiri dari tahapan-tahapan sebagai berikut, untuk menghafalnya disingkat IEKT:
-
Incepsi: penentuan tujuan-tujuan (life cycle objectives)
-
Elaborasi: pembuatan arsitektur sistem
-
Konstruksi: kapasitas dan kemampuan sistem dibentuk
-
Transisi: produk siap uji
Buku Arlow membahas keempat tahapan UP tersebut yang dikombinasikan dengan waterfall (requirements, analisis, disain, implementasi dan testing, disingkat RADIT). Bentuknya di tiap-tiap RADIT ada IEKT dari UP. Namun ada juga yang sebaliknya, di tiap IEKT-nya UP ada RADIT. Namun yang dibahas di buku adalah yang bentuk pertama. Sementara itu ketika melihat buku Larman yang cukup tebal, ternyata UP hanya sampai Elaborasi. Tidak ada konstruksi dan transisi. Belum sempat saya baca sampai sana, hanya saja ada elaborasi-1, elaborasi-2. Bukunya cukup tebal dengan bahasa Java sebagai ilustrasinya.
Sempat saya baca juga dalam satu kolom khusus dalam buku Larman, bahwa tidak ada peluru perak (istilahnya senjata pamungkas pembunuh vampir) dalam bentuk tools atau teknik perancangan perangkat lunak, dikatakan oleh Dr. Frederick Brookes (lihat buku Mythical Man-month). Jadi kalau ada yang bilang suatu teknik itu ampuh untuk segala bentuk sistem, dipastikan tidak mungkin alias gombal, baik yg mengatakan itu dosen ataupun sales CASE (alat bantu pembuatan software). Tetap saja jika pengguna tidak memahami konsep Object Oriented akan kesulitan menggunakan CASE jenis apapun (dibahas di buku: “Death by UML Fever” karangan Booch). Seperti biasa, tiap buku berbeda-beda pahamnya, seperti post yang lalu bahwa beberapa buku analisa disain/rekayasa perangkat lunak (Pressman, 2001; Sommerville, 2007) masih mentolerir menggunakan non-object programming dengan UML. Tidak ada salahnya juga menggunakan model lain yg bukan standar UML untuk penggambaran sistem berbasis objek asal bermaksud memperjelas pembacaan model (Fowler, 2004). Tetapi alangkah idealnya jika sistem yg dirancang dengan UML berbasis object. Selamat ber-UML.
Reference
Arlow, J., & Neustadt, I. (2005). UML 2 and the Unified Process (Second). United States: Pearson Education Limited.
Fowler, M. (2004). UML Distilled (3rd ed.). United States: Pearson.
Larman, C. (2005). Applying UML and Patterns (3rd ed.). United States: Pearson.
Pressman, R. S. (2001). Software Engineering – A Practitioner’s Approach (Fifth Edit). New York: McGraw Hill.
Sommerville, I. (2007). Software Engineering – Eighth Edition. London: Pearson Education Limited.