Unified Software Development Process (USDP)

1. Pendahuluan

Dewasa ini penggunaan komputer bertumbuh pesat. Bisa dilihat bahwa di setiap aspek kehidupan manusia selalu melibatkan penggunaan komputer. Penggunaan komputer yang semakin luas ini tentunya membawa perubahan pula bagi para pengembang perangkat lunak. Perangkat lunak yang dibuat harus mampu menjangkau setiap pengguna, baik itu pengguna yang sudah mahir maupun yang masih awam. Perangkat lunak yang baik harus dapat digunakan oleh siapa saja, baik yang memiliki latar belakang pendidikan IT atau bukan. Kompleksitas dari perangkat lunak pun semakin bertambah dengan semakin beragamnya permintaan aplikasi dari pengguna.

Perkembangan perangkat lunak yang semakin kompleks ini memerlukan suatu metodologi untuk bisa menghasilkan sebuah produk akhir perangkat lunak yang handal. Yang dimaksud dengan metodologi di sini adalah suatu kerangka kerja dan prinsip-prinsip yang dipakai untuk mengorganisasikan suatu penugasan tertentu, dalam konteks ini adalah penugasan pembuatan perangkat lunak, yang dilakukan dalam sebuah tim dengan pembagian tugas yang jelas.  Dengan menggunakan metodologi pengembangan perangkat lunak (software development methodology) ini, maka para pengembang (developer) punya fase-fase yang lebih terstruktur sehingga proses manajerial dan kontrol dalam pembuatan perangkat lunak menjadi lebih baik.

Beragam metodologi bisa dipakai. Namun dalam tulisan ini hanya akan dibahas satu metodologi yang cukup terkenal, yaitu Unified Software Development Process atau biasa disingkat dengan USDP.

2. Pengertian Unified Software Development Process

USDP merupakan metodologi untuk pengembangan perangkat lunak, utamanya perangkat lunak yang berorientasikan objek. Metodologi ini pertama kali diperkenalkan oleh Rational Team, yang pada perkembangan selanjutnya metodologi ini disempurnakan kembali menjadi metodologi baru yang bernama Rational Unified Process (RUP), yang sekaligus menjadi cikal bakal tebentuknya kurang lebih tujuh metodologi lainnya.

Berbicara tentang USDP, maka proses yang dicakup tidaklah sesederhana jika dibandingkan dengan metodologi klasik, seperti waterfall dan iterative model. Hal ini dikarenakan USDP lebih digunakan untuk membangun sebuah kerangka kerja (framework) yang bisa dikustomisasi untuk kepentingan organisasi dan proyek yang lebih spesifik. Dengan framework, bisa tercipta beragam aplikasi karena adanya konsep coding reuse, dimana coding yang sama bisa dipakai untuk keperluan aplikasi yang sejenis.

3. Konsep Penting dari USDP

Jika ditelaah lebih dalam, dasar dari USDP bisa dirangkum ke dalam 4  konsep yang akan dijelaskan di bawah ini.

3.1. Iterative dan incremental.

Yang dimaksud dengan iterative dan incremental di sini adalah proses pengembangan perangkat lunak yang dibagi dalam beberapa fase, dimana di setiap fase tersebut dilakukan beberapa tahap kerja yang dilakukan secara berulang, yang diharapkan di setiap tahap tersebut terdapat beberapa perbaikan yang menuju kepada kematangan perangkat lunak tersebut.

Gambar 1. Diagram Fase USDP.

Dari gambar di atas terlihat bahwa USDP terbagi aras 4 fase, yaitu Inception, Elaboration, Construction, dan Transition. Di tiap-tiap fase tersebut terdapat 6 tahap kerja (iterasi) yang harus dilakukan, yaitu Business Modeling, Requirements, Analysis & Design, Implementation, Test, dan Deployment. Ada juga referensi lain yang membagi fase tersebut menjadi 5 tahap saja (Business Modeling dan Requirements dijadikan satu) dan ada pula yang membaginya menjadi 7 tahap (fase akhir ditambah dengan Maintenance). Fase kerja ini berkaitan erat dengan peran seorang project manager, sedangkan tahap kerja (iterasi) berkaitan erat dengan peran seorang developer atau programmer.

Dari gambar di atas juga bisa dilihat grafik pada setiap fase punya penekanan pada beberapa tahap kerja. Contoh, pada fase Inception, maka tahap kerja yang lebih dipentingkan adalah Business Modeling. Sedangkan pada fase Elaboration, maka tahap kerja yang lebih dipentingkan adalah Business Modeling, Requirements, Analysis & Design. Demikian seterusnya.

3.2. Use Case Driven

Dalam USDP yang menjadi elemen dasarnya adalah interaksi tunggal antara pengguna dengan sistem. Use case berguna sebagai langkah awal untuk memodelkan interaksi tersebut. Setiap use case merepresentasikan kebutuhan dan hubungan dari tiap-tiap entity yang kemudian akan diimplementasikan dalam sistem.

Use case di sini digunakan untuk menangkap kebutuhan fungsi dan mendifinisikan isi dari tiap-tiap iterasi. Dengan demikian tiap iterasi dalam USDP mempunyai use case atau skenario yang spesifik. Hal ini akan memandu system developers untuk selalu melihat dari sudut pandang kebutuhan pengguna sehingga sistem yang dihasilkan betul-betul sesuai dengan keinginan pengguna.

Untuk menggambarkan use case tersebut, biasa digunakan sebuah pemodelan dalam bentuk diagram, yang disebut use case diagram. Dari use case diagram, systems developers bisa lebih mudah menganalisa hubungan antara pengguna dengan sistem, atau juga hubungan antara sistem dengan sistem. Dalam proses implementasinya nanti, use case diagram ini bisa dikembangkan menjadi kerangka coding dalam bentuk Unified Modeling Language (UML).

Gambar 2. Use Case Diagram.

Gambar 3. Use Case Diagram Yang Dikembangkan.

Gambar 4. Unified Modeling Language.

Gambar 2 di atas memperlihatkan use case diagram antara pengguna sistem (dalam hal ini seorang akuntan) dengan tugasnya untuk merekrut staf baru (add new staff). Dari use case sederhana tersebut lalu dikembangkan lebih lanjut menjadi use case yang lebih lengkap yang sudah mengarah ke desain coding dari sistem tersebut. Tampak dalam gambar 3, fungsi “Add New Staff” dikembangkan menjadi beberapa kelas yang masing-masing kelas tersebut mempunyai fungsinya masing-masing. Lalu langkah selanjutnya adalah memodelkan lebih detail struktur coding (variabel, fungsi dan prosedur) dari masing-masing kelas dalam UML, seperti terlihat dalam gambar 4. Dari UML ini nanti berfungsi sebagai panduan dalam melakukan coding detailnya.

3.3. Architecture Centric

USDP mempunyai arsitektur yang menjadi dasar yang jelas untuk membentuk sebuah sistem. Salah satu keunggulan dari USDP ini adalah mendukung berbagai macam model dan sudut pandang arsitektur.

Arsitektur yang dimaksud di sini berfungsi untuk:

1. Memastikan batasan-batasan, kontrol, dan kelas entiti dari perangkat lunak yang akan dibuat.
2. Melakukan kontrol antara model dengan aktivitas pembuatan perangkat lunak itu sendiri sehingga diharapkan tidak terjadi hal-hal diluar skenario yang telah direncanakan sebelumnya.
3. Melakukan kontrol terhadap sumber daya yang diperlukan dalam pembuatan perangkat lunak, seperti waktu, uang, sumber daya manusia, dan lain-lain.

3.4. Risk Focused

USDP memungkinkan para pengembang perangkat lunak untuk bisa mengetahui resiko vital di setiap awal tahapan pengerjaan. Dengan demikian faktor-faktor yang sekiranya mempunyai resiko yang paling vital bisa lebih mendapat perhatian terlebih dahulu sehingga nantinya tidak mengganggu proses pengembangan perangkat lunak selanjutnya. Selain itu USDP juga menghendaki agar resiko di setiap fase bisa segera diselesaikan pada fase itu juga sehingga tidak menghambat fase-fase selanjutnya.

4. Fase USDP

Seperti sudah disinggung di atas bahwa dalam USDP terdapat 4 fase. Berikut adalah penjelasan detail dari tiap-tiap fase tersebut:

4.1. Inception

Dalam fase ini pengembang perangkat lunak dituntut untuk bisa melakukan interaksi dengan customer, sebagai langkah awal untuk pengidentifikasian kebutuhan-kebutuhan sistem yang hendak dibuat. Langkah ini cukup penting agar para pengembang perangkat lunak punya kesamaan persepsi antara sistem yang akan dibuat dengan kebutuhan pengguna.

Berikut adalah tahap-tahap iterasi kerja yang dilakukan developer pada fase ini:

1. Business Modeling dan Requirements: menganalisa, merumuskan, dan menentukan perencanaan, cakupan, dan kebutuhan utama bisnis.
2. Analysis: mengadakan studi kelayakan terhadap proyek yang akan dijalani.
3. Design: mendesain konsep atau prototipe teknisnya.
4. Implementation: membuat prototipe konsepnya.
5. Test: tahap ini tidak terlalu dipentingkan atau belum diperlukan pada fase ini.

Adapun hasil akhir dan tujuan yang ingin dicapai pada fase ini adalah:

1. Ruang lingkup sistem sudah terdefinisikan.
2. Kebutuhan sistem sudah bisa diidentifikasi dan telah mendapat persetujuan dari stakeholder.
3. Arsitektur sistem sudah jelas, walaupun mungkin masih dalam tahap perencanaan awal dan masih bisa berubah di fase selanjutnya.
4. Sudah melakukan analisa terhadap segala kemungkinan resiko yang mungkin akan terjadi selama pengerjaan proyek.
5. Sudah mempunyai perencanaan bisnis yang matang untuk memperlancar jalannya proyek kelak.
6. Studi kelayakan proyek sudah jelas dan pasti.
7. Stakeholder sudah menyetujui kerangka kerja proyek tersebut.
8. Dokumen atau produk yang dihasilkan dalam fase ini adalah System Charter atau Vision Document.

4.2. Elaboration

Fase ini digunakan untuk mematangkan konsep-konsep yang sudah terbentuk di fase Inception. Fase ini belum masuk ke tahap pembuatan perangkat lunak secara langsung, tetapi lebih kepada pemantapan konsep dan peninjauan kembali terhadap rencara-rencana yang sudah ditentukan sebelumnya. Dengan demikian diharapkan proyek yang akan berjalan, resikonya dapat ditekan seminimal mungkin.

Berikut adalah tahap-tahap iterasi kerja yang dilakukan developer pada fase ini:

1. Business Modeling dan Requirements: memperbaiki cakupan dan kebutuhan sistem.
2. Analysis: menganalisa kebutuhan sistem dan cara membangun sistem tersebut.
3. Design: membuat arsitektur yang stabil.
4. Implementation: membuat garis besar arsitektur.
5. Test: mengetes garis besar arsitektur yang sudah dibuat.

Adapun hasil akhir dan tujuan yang ingin dicapai pada fase ini adalah:

1. Membuat garis besar dari arsitektur proyek yang lebih baik dan handal.
2. Memperbaiki analisa atau meminimalkan segala kemungkinan resiko yang ada.
3. Mendefinisikan atribut kualitas (misal: atribut atau parameter apa saja yang mempengaruhi keberhasilan dan kegagalan proyek).
4. Merangkum use case menjadi suatu kebutuhan fungsional.
5. Membuat perencanaan detail untuk fase selanjutnya.
6. Memformulasikan perencanaan kebutuhan peralatan, waktu, staf, biaya, dan sumber daya lainnya.
7. Memperoleh persetujuan dari stakeholder untuk melanjutkan ke fase berikutnya.
8. Dokumen atau produk yang dihasilkan dalam fase ini adalah UML Model, Software Requirements Specification (SRS), System/Subsystem Specification (SSS), System/Subsystem Design Description (SSDD), Interface Control Description (ICD), dan Software Architecture Description (SAD).

4.3. Construction

Fase ini merupakan fase coding, dimana pengembang perangkat lunak sudah melakukan pembuatan sistem secara nyata. Pembuatan sistem tersebut tentunya harus mengacu kepada hal-hal atau parameter-parameter yang sudah ditentukan dan digariskan dari fase-fase sebelumnya.

Berikut adalah tahap-tahap iterasi kerja yang dilakukan developer pada fase ini:

1. Business Modeling dan Requirements: menyelidiki lebih lanjut kebutuhan-kebutuhan proyek yang mungkin belum terpikirkan sebelumnya.
2. Analysis: menyelesaikan analisis model.
3. Design: menyelesaikan desin model.
4. Implementation: membangun Initial Operational Capability.
5. Test: melaukan pengetesan terhadap Initial Operational Capability yang telah dibuat.

Adapun hasil akhir dan tujuan yang ingin dicapai pada fase ini adalah:

1. Menyelesaikan identifikasi, deskripsi, dan realisasi dari use case.
2. Menjaga integritas dari arsitektur sistem.
3. Merevisi analisa resiko yang ada.
4. Menyelesaikan beberapa kebutuhan yang terlewatkan sebelumnya.
5. Menyelesaikan analisis dan desain model.
6. Membangun dan melakukan pengetesan terhadap Initial Operational Capability, yang mengarah kepada pembentukan produk yang siap untuk dilakukan pengetesan awal oleh pengguna (produk perangkat lunak versi beta).
7. Dokumen atau produk yang dihasilkan dalam fase ini adalah Software Development Plan (SDP).

4.4. Transition

Tahap ini dilakukan untuk mematangkan produk akhir yang sudah jadi. Pematangan ini perlu dilakukan untuk menganalisa apakah perangkat lunak yang sudah dibuat sesuai dengan kebutuhan pengguna, atau mungkin terdapat bug yang perlu diperbaiki, dan lain-lain.

Berikut adalah tahap-tahap iterasi kerja yang dilakukan developer pada fase ini:

1. Business Modeling dan Requirements: tahapan ini seharusnya sudah tidak dipakai lagi karena fase ini merupakan fase akhir, tetapi tetap dapat dilakukan jika memang masih dibutuhkan.
2. Analysis: tahapan ini seharusnya sudah terselesaikan di fase sebelumnya sehingga tidak dipakai lagi, tetapi tidak menutup kemungkinan tetap dapat dilakukan jika memang masih dibutuhkan.
3. Design: melakukan modifikasi terhadap desain sistem jika ditemukan masalah selama beta testing.
4. Implementation:   melakukan penyesuaian setting perangkat lunak agar bisa dipakai di sisi pengguna (misal, install dan setting database di server pengguna, penyesuaian setting IP) dan melakukan perbaikan coding yang ditemukan selama beta testing.
5. Test: melakukan proses beta testing dan melakukan testing akhir di sisi pengguna.

Adapun hasil akhir dan tujuan yang ingin dicapai pada fase ini adalah:

1. Memperbaiki cacat yang ditemukan pada perangkat lunak.
2. Mempersiapkan perangkat lunak agar bisa dipakai oleh pengguna secara langsung.
3. Memodifikasi perangkat lunak jika ditemukan masalah yang terlewatkan pada versi beta.
4. Membuat buku manual dan dokumentasi lainnya.
5. Menyediakan konsultasi dan pelatihan kepada pengguna atas pemanfaatan perangkat lunak tersebut.
6. Melakukan peninjauan atau analisa setelah proyek selesai (post project review).
7. Jika semua aspek sudah diselesaikan, maka dilakukan penyerahan perangkat lunak tersebut secara resmi kepada pengguna untuk kemudian diimplementasikan.
8. Dokumen atau produk yang dihasilkan dalam fase ini adalah Software Test Description (STD) dan Software Test Report (STR).

5. Hubungan Antar Fase USDP

Fase-fase yang sudah dijelaskan di atas, memiliki tingkat kepentingan yang berbeda-beda antara proyek satu dengan lainnya. Utamanya dalam hal kompleksitas proyek atau perangkat lunak yang akan dibuat. Ada dua pendekatan yang bisa dipakai, yaitu pendekatan waktu yang dibutuhkan dan pendekatan sumber daya yang dibutuhkan.

5.1. Hubungan Antar Fase USDP Berdasarkan  Waktu Yang Dibutuhkan

Gambar 5. Persentase Waktu Untuk Proyek Standar (Kiri) dan Proyek Sulit/Besar (Kanan).

Dari gambar 5 di atas, terlihat bahwa untuk kedua jenis proyek (standar atau sulit) persentase waktu terbesar terdapat pada fase Elaboration dan Construction. Hal ini dikarenakan kedua fase ini memegang peranan yang paling penting untuk keseluruhan proses. Fase Elaboration untuk meletakkan fondasi bagi proyek, sedangkan Construction adalah fase pembuatan proyek itu sendiri.

Tetapi jika dianalisa lebih lanjut, perbedaan dari kedua diagram tersebut terletak pada besar persentase. Untuk proyek yang sulit/besar, persentase untuk fase Inception dan Elaboration akan lebih besar dibandingkan untuk proyek standar. Hal ini menandakan untuk proyek yang besar perlu analisa dan konsep yang lebih matang dibandingkan proyek standar. Dengan demikian resiko yang dihadapi akan semakin kecil.

5.2. Hubungan Antar Fase USDP Berdasarkan Sumber Daya Yang Dibutuhkan

Gambar 6. Persentase Sumber Daya Yang Diperlukan Untuk Proyek Standar (Kiri) dan Proyek Sulit/Besar (Kanan)

Dari gambar 6 di atas, bisa dilihat bahwa kebutuhan sumber daya terbesar (baik proyek standar ataupun proyek sulit/besar) terletak pada fase Construction. Persentasenya lebih dari separuh dibandingkan kebutuhan sumber daya di fase lainnya. Sumber daya yang dimaksud di sini adalah uang, waktu, sumber daya manusia, dan sarana prasarana dalam keseluruhan proses pembuatan perangkat lunak. Fase construction merupakan fase utama dalam keseluruhan pembuatan perangkat lunak. Oleh karena itu wajar jika fase ini menyedot sumber daya lebih banyak dibandingkan fase lainnya.

Tetapi yang membedakan antara proyek standar dengan proyek sulit/besar adalah persentase sumber daya untuk proyek sulit/besar di fase-fase awal (Inception dan Elaboration) akan lebih besar persentasenya, dibandingkan fase serupa di proyek standar.  Sedangkan untuk fase-fase akhir (Construction dan Transition) di proyek sulit/besar justru semakin menurun persentasenya, dibandingkan fase serupa di proyek standar. Hal ini dikarenakan proyek sulit/besar butuh perencanaan yang lebih matang dan mendetail sehingga sumber daya yang dibutuhkan di fase perencanaan (Inception dan Elaboration) tersebut juga besar.

5.3. Hubungan USDP Dilihat Dari Berbagai Aspek

Di bawah ini adalah diagram yang menunjukkan hubungan USDP yang dilihat dari berbagai aspek (jumlah personel, perkembangan tiap bulan, tingkat kontrol, dan lain sebagainya) antara proyek dengan resiko kecil dan besar.

Gambar 7. Hubungan Antar Aspek USDP Pada Proyek Dengan Resiko Rendah (Kiri) Dan Resiko Tinggi (Kanan).

6. Pembagian Kerja Dalam USDP

Di dalam konsep USDP, pembagian kerja bisa dibagi ke dalam dua jenis penugasan, yaitu:

1. Primary Tasks
   Primary tasks adalah semua penugasan yang berkontribusi langsung untuk pengembangan proyek di fase-fase yang lebih tinggi.
2. Secondary Tasks
3. Secondary tasks adalah semua penugasan yang berkaitan dengan:
   • Pencegahan atau penanggulangan terhadap resiko-resiko yang ada.
   • Penanggulangan masalah-masalah kritis yang terjadi di dalam tim.
   • Penelitian yang berkaitan dengan masalah-masalah yang ada beserta solusinya.
   • Pencarian bug (bug tracking) dan pembuatan laporan.

Secara statistik primary tasks akan lebih banyak berperanan dibandingkan secondary tasks. Dalam sebuah proyek, primary tasks memegang peranan sekitar 80 persen dari keseluruhan. Sedangkan secondary tasks hanya berkisar antara 10 sampai 20 persen saja. Semakin kecil secondary tasks berarti semakin optimal kinerja dari tim, artinya tidak banyak sumber daya yang dihabiskan hanya untuk penanggulangan masalah-masalah yang terjadi. Akan tetapi dalam sebuah proyek, secondary tasks tidak akan pernah bisa mencapai nol persen.

7. Daftar Referensi

Bennett; McRobb; Farmer. Software Development Processes.
<http://dke.postech.ac.kr/course/ie581/sub/OOSAD3e/Lecture%20PPT/3_21a.ppt&gt;

Jacobson, Ivar; Grady Booch; James Rumbaugh. 1999. The Unified Software Development Process. Addison Wesley.

Khamis, Abdelaziz; Ashraf Abdelmonem. The Unified Software Development Process And Framework Development.
< http://journal.dogus.edu.tr/13026739/2002/sayi5/M00064.pdf&gt;

Norwegian University of Science and Technology. The Unified Software Development Process: Classification of Iterations.
<http://www.idi.ntnu.no/emner/tdt4140/dokumenter/2009/unfied%20process.ppt&gt;

UCL Computer Science. Unified Software Development Process.
< http://www.cs.ucl.ac.uk/staff/ucacwxe/lectures/3C05-03-04/USDP.pdf&gt;

Wikipedia. Unified Process.
< http://en.wikipedia.org/wiki/Unified_Process&gt;

———————————————————————————————————

Ditulis oleh: Raymond Sutjiadi

« Supervised Learning In Quest (SLIQ) Algorithm