jenis metode pengembangan perangkat lunak

JENIS METODE PENGEMBANGAN PERANGKAT LUNAK

1. RAD

Rapid Aplication Development (RAD) adalah sebuah metode pengembangan software yang

diciptakan untuk menekan waktu yang dibutuhkan untuk mendesain serta

mengimplementasikan sistem, informasi sehingga dihasilkan siklus pengembangan yang

sangat pendek.

Model RAD ini merupakan adaptasi dari model sekuensial linier dimana perkembangan yang

cepat dicapai dengan menggunakan pendekatan kontruksi berbasis komponen. Sehingga, jika

kebutuhan sistem dipahami dengan baik, proses RAD memungkinkan developer menciptakan

sistem fungsional yang utuh dalam periode waktu yang sangat pendek (± 60 sampai 90 hari).

Karena dipakai terutama pada aplikasi sistem konstruksi, pendekatan RAD meliputi fase –

fase dibawah ini:

a. Bussiness modeling

Aliran informasi di antara fungsi – fungsi bisnis dimodelkan dengan suatu cara untuk

menjawab pertanyaan – pertanyaan sebagai berikut :

1) Informasi apa yang mengendalikan proses bisnis?

2) Informasi apa yang di munculkan?

3) Siapa yang memunculkanya?

4) Ke mana informasi itu pergi?

5) Siapa yang memprosesnya?

b. Data modeling

Aliran informasi yang didefinisikan sebagai bagian dari fase bussiness modelling disaring ke

dalam serangkaian objek data yang dibutuhkan untuk menopang bisnis tersebut. Karakteristik

(disebut atribut) masing masing objek diidentifikasi dan hubungan antara objek – objek

tersebut didefinisikan.

c. Prosess modelling

Aliran informasi yang didefinisikan di dalam fase data modeling ditransformasikan untuk

mencapai aliran informasi yang perlu bagi implementasi sebuah fungsi bisnis. Gambaran

pemrosesan diciptakan untuk menambah, memodifikasi, menghapus, atau mendapatkan

kembali sebuah objek data.

d. Aplication generation

RAD mengasumsikan pemakaian teknik generasi ke empat. Selain menciptakan perangkat

lunak dengan menggunakan bahasa pemrograman generasi ketiga yang konvensional, RAD

lebih banyak memproses kerja untuk memkai lagi komponen program yang ada (pada saat

memungkinkan) atau menciptakan komponen yang bisa dipakai lagi (bila perlu). Pada semua

kasus, alat – alat bantu otomatis dipakai untuk memfasilitasi konstruksi perangkat lunak.

e. Testing and turnover

Karena proses RAD menekankan pada pemakaian kembali, banyak komponen program telah

diuji. Hal ini mengurangi keseluruhan waktu pengujian. Tetapi komponen baru harus di uji

dan semua interface harus dilatih secara penuh.

Keunggulan dan kelemahan model RAD adalah :

Keunggulan:

1. Waktu pengembangan yang lebih singkat dan

2. Biaya yang relatif lebih murah

Kelemahan:

1. Tidak cocok untuk proyek skala besar

2. Proyek bisa gagal karena waktu yang disepakati tidak dipenuhi

3. Sistem yang tidak bisa dimodularisasi tidak cocok untuk model

4. Resiko teknis yang tinggi juga kurang cocok untuk model ini.

2. PROTOTYPING

Proses pada model prototyping yang dapat dijelaskan sebagai berikut:

a. User Requirements

Pada tahap ini developer dan klien bertemu dan menentukan tujuan umum, kebutuhan yang diketahui dan gambaran bagian-bagian yang akan dibutuhkan berikutnya. Detil kebutuhan mungkin tidak dibicarakan pada tahap ini.

b. Develope Prototype

Pada tahap ini dilakukan perancangan prototype sistem oleh developer, perancangan sistem dilakukan secara cepat dan rancangan diusahakan mewakili semua aspek software yang telah diketahui.

c. Revise Prototype

Pada tahap ini dilakukan evaluasi prototype sistem oleh klien. Apabila klien merasa prototype sistem yang telah dikembangkan sesuai dengan keinginannya maka prototype tersebut dapat digunakan, akan tetapi jika prototype tersebut tidak sesuai, maka prototype tersebut akan dilakukan revisi dan digunakan sebagai acuan dalam memperjelas kebutuhan software dan kemudian dikembangkan prototype selanjutnya. Siklus ini (develop-revise prototype) akan terus berlangsung hingga didapatkan prototype sistem yang sesuai dengan kebutuhan klien atau user.

Keunggulan dan kelemahan pada pengembangan software menggunakan metode prototyping.

Keunggulan:

1. Meningkatnya komunikasi antara user dan developer2. Peningkatan peran aktif user didalam proses pengembangan3. Peningkatan efisiensi waktu4. Implementasi sistem menjadi lebih mudah karena user turut berperan aktif didalam proses pengembangan

Kelemahan:

1. Kurangnya fitur keamanan dan kontrol pada prototype akhir sistem2. Sistem akan sulit terbentuk jika proses evaluasi pada siklus prototype tidak mendapatkan titik temu.3. Dapat menyebabkan dokumentasi akhir yang tidak lengkap4. Developer lebih sulit mengendalikan ekspektasi user

Model Spiral / Model Boehm

Model ini mengadaptasi dua model perangkat lunak yang ada yaitu model prototyping

dengan pengulangannya dan model waterfall dengan pengendalian dan sistematikanya.

Model ini dikenal dengan sebutan Spiral Boehm. Pengembang dalam model ini

memadupadankan beberapa model umum tersebut untuk menghasilkan produk khusus atau

untuk menjawab persoalan-persoalan tertentu selama proses pengerjaan proyek.

Tahap-tahap model ini dapat dijelaskan secara ringkas sebagai berikut :

Tahap Liason:pada tahap ini dibangun komunikasi yang baik dengan calon

pengguna/pemakai.

Tahap Planning (perencanaan):pada tahap ini ditentukan sumber-sumber informasi, batas

waktu dan informasi-informasi yang dapat menjelaskan proyek.

Tahap Analisis Resiko:mendefinisikan resiko, menentukan apa saja yang menjadi resiko

baik teknis maupun manajemen.

Tahap Rekayasa (engineering):pembuatan prototipe.

Tahap Konstruksi dan Pelepasan (release):pada tahap ini dilakukan pembangunan

perangkat lunak yang dimaksud, diuji, diinstal dan diberikan sokongan-sokongan tambahan

untuk keberhasilan proyek.

Tahap Evaluasi:Pelanggan/pemakai/pengguna biasanya memberikan masukan berdasarkan

hasil yang didapat dari tahap engineering dan instalasi.

Kelebihan model iniadalah sangat mempertimbangkan resiko kemungkinan munculnya

kesalahan sehingga sangat dapat diandalkan untuk pengembangan perangkat lunak skala

besar. Pendekatan model ini dilakukan melalui tahapan-tahapan yang sangat baik dengan

menggabungkan model waterfall ditambah dengan pengulangan-pengulangan sehingga lebih

realistis untuk mencerminkan keadaan sebenarnya. Baik pengembang maupun pemakai dapat

cepat mengetahui letak kekurangan dan kesalahan dari sistem karena proses-prosesnya dapat

diamati dengan baik.

Kekurangan model iniadalah waktu yang dibutuhkan untuk mengembangkan perangkat

lunak cukup panjang demikian juga biaya yang besar. Selain itu, sangat tergantung kepada

tenaga ahli yang dapat memperkirakan resiko. Terdapat pula kesulitan untuk mengontrol

proses. Sampai saat ini, karena masih relatif baru, belum ada bukti apakah metode ini cukup

handal untuk diterapkan.

Model Spiral/Boehm sangat cocok diterapkan untuk pengembangan sistem dan perangkat

lunak skala besar di mana pengembang dan pemakai dapat lebih mudah memahami kondisi

pada setiap tahapan dan bereaksi terhadap kemungkinan terjadinya kesalahan. Selain itu,

diharapkan juga waktu dan dana yang tersedia cukup memadai.

3. Model Rapid Application Development (RAD)

Rapid Aplication Development (RAD) adalah sebuah model proses perkembanganperangkat

lunak sekuensial linier yang menekankan siklus perkembangan yang sangat pendek (kira-kira

60 sampai 90 hari). Model RAD ini merupakan sebuah adaptasi “kecepatan tinggi” dari

model sekuensial linier dimana perkembangan cepat dicapai dengan menggunakan

pendekatan konstruksi berbasis komponen.

Berikut adalah Tahapan – tahapan Proses Pengembangan dalam Model Rapid Application

Development (RAD), yaitu :

Bussiness Modeling

Fase ini untuk mencari aliran informasi yang dapat menjawab pertanyaan berikut:

Informasi apa yang menegndalikan proses bisnis?

Informasi apa yang dimunculkan?

Di mana informasi digunakan ?

Siapa yang memprosenya ?

Data Modeling

Aliran informasi yang didefinisikan sebagai bagian dari fase bussiness modeling disaring ke

dalam serangkaian objek data yang dibutuhkan untuk menopang bisnis tersebut. Karakteristik

https://murtri.files.wordpress.com/2014/08/5.jpg

(atribut) masing-masing objek diidentifikasi dan hubungan antar objek-objek tersebut

didefinisikan.

Proses Modeling

Aliran informasi yang didefinisikan di dalam fase data modeling ditransformasikan untuk

mencapai aliran informasi yang perlu bagi implementasi sebuah fungsi bisnis. Gambaran

pemrosesan diciptakan untuk menambah, memodifikasi, menghapus, atau mendapatkan

kembali sebuah objek data.

Aplication Generation

Selain menggunakan bahasa pemrograman generasi ketiga, RAD juga memakai komponen

program yang telah ada atau menciptakan komponen yang bisa dipakai lagi. Ala-alat bantu

bisa dipakai untuk memfasilitasi konstruksi perangkat lunak.

Testing dan Turnover

Karena proses RAD menekankan pada pemakaian kembali, banyak komponen program telah

diuji. Hal ini mengurangi keseluruhan waktu pengujian. Tetapi komponen baru harus diuji

dan semua interface harus dilatih secara penuh.

Kelebihan Model RAD :

Lebih efektif dari Pengembangan Model waterfall/sequential linear dalam menghasilkan

sistem yang memenuhi kebutuhan langsung dari pelanggan.

Cocok untuk proyek yang memerlukan waktu yang singkat.

Model RAD mengikuti tahap pengembangan sistem seperti pada umumnya, tetapi

mempunyai kemampuan untuk menggunakan kembali komponen yang ada sehingga

pengembang tidak perlu membuatnya dari awal lagi sehingga waktu pengembangan menjadi

lebih singkat dan efisien.

Kekurangan Model RAD :

Model RAD menuntut pengembangan dan pelanggan memiliki komitmen di dalam aktivitas

rapid-fire yang diperlukan untuk melengkapi sebuah sistem, di dalam kerangka waktu yang

sangat diperpendek. Jika komitmen tersebut tidak ada, proyek RAD akan gagal.

Tidak semua aplikasi sesuai untuk RAD, bila system tidak dapat dimodulkan dengan teratur,

pembangunan komponen penting pada RAD akan menjadi sangat bermasalah.

RAD tidak cocok digunakan untuk sistem yang mempunyai resiko teknik yang tinggi.

Membutuhkan Tenaga kerja yang banyak untuk menyelesaikan sebuah proyek dalam skala

besar.

Jika ada perubahan di tengah-tengah pengerjaan maka harus membuat kontrak baru antara

pengembang dan pelanggan.

V – MODEL

Pengertian Model V

Model ini merupakan perluasan dari model waterfall. Disebut sebagai perluasan karena

tahap-tahapnya mirip dengan yang terdapat dalam model waterfall. Jika dalam model

waterfall proses dijalankan secara linear, maka dalam model V proses dilakukan bercabang.

Dalam model V ini digambarkan hubungan antara tahap pengembangan software dengan

tahap pengujiannya.

Berikut penjelasan masing-masing tahap beserta tahap pengujiannya:

1. Requirement Analysis & Acceptance Testing

Tahap Requirement Analysis sama seperti yang terdapat dalam model waterfall.

Keluaran dari tahap ini adalah dokumentasi kebutuhan pengguna.

Acceptance Testing merupakan tahap yang akan mengkaji apakah dokumentasi yang

dihasilkan tersebut dapat diterima oleh para pengguna atau tidak.

2. System Design & System Testing

Dalam tahap ini analis sistem mulai merancang sistem dengan mengacu pada

dokumentasi kebutuhan pengguna yang sudah dibuat pada tahap sebelumnya. Keluaran dari

tahap ini adalah spesifikasi software yang meliputi organisasi sistem secara umum, struktur

data, dan yang lain. Selain itu tahap ini juga menghasilkan contoh tampilan window dan juga

dokumentasi teknik yang lain seperti Entity Diagram dan Data Dictionary.

3. Architecture Design & Integration Testing

Sering juga disebut High Level Design. Dasar dari pemilihan arsitektur yang akan

digunakan berdasar kepada beberapa hal seperti: pemakaian kembali tiap modul,

ketergantungan tabel dalam basis data, hubungan antar interface, detail teknologi yang

dipakai.

4. Module Design & Unit Testing

Sering juga disebut sebagai Low Level Design. Perancangan dipecah menjadi modul-

modul yang lebih kecil. Setiap modul tersebut diberi penjelasan yang cukup untuk

memudahkan programmer melakukan coding. Tahap ini menghasilkan spesifikasi program

seperti: fungsi dan logika tiap modul, pesan kesalahan, proses input-output untuk tiap modul,

dan lain-lain.

5. Coding

Dalam tahap ini dilakukan pemrograman terhadap setiap modul yang sudah dibentuk.

1.1 Keuntungan V Model Bahasa yang digunakan untuk merepresentasikan konsep V model menggunakan bahasa

formal. Contoh : dengan menggunakan objek model ataupun frame-frame •

Meminimalisasikan kesalahan pada hasil akhir karena ada test pada setiap prosesnya

Penyesuaian yang cepat pada projek yang baru

Memudahkan dalam pembuatan dokumen projek

Biaya yang murah dalam perawatan dan modifikasinya

V Model sangat fleksibel. V Model mendukung project tailoring dan penambahan dan

pengurangan method dan tool secara dinamik. Akibatnya sangat mudah untuk melakukan

tailoring pada V Model agar sesuai dengan suatu proyek tertentu dan sangat mudah untuk

menambahkan method dan tool baru atau menghilangkan method dan tool yang dianggap

sudah obsolete.

V Model dikembangkan dan di-maintain oleh publik. User dari V Model berpartisipasi dalam

change control board yang memproses semua change request terhadap V Model.

1.2 Kerugian V Model Aktifitas V-Model hanya difokuskan pada projectnya saja, bukan pada keseluruhan organisasi.

V-Model adalah proses model yang hanya dikerjakan sekali selama project saja, bukan

keseluruhan organisasi.

Prosesnya hanya secara sementara. Ketika project selesai, jalannya proses model dihentikan.

Tidak berlangsung untuk keseluruhan organisasi.

Metode yang ditawarkan terbatas. Sehingga kita tidak memiliki cara pandang dari metode

yang lain. Kita tidak memiliki kesempatan untuk mempertimbangkan jika ada tools lain yang

lebih baik.

oolnya tidak selengkap yang dibicarakan. SDE (Software Development Environment).Tidak

ada tools untuk hardware di V-Model. Tool yang dimaksud adalah “software yang

mendukung pengembangan atau pemeliharaan / modifikasi dari system IT.

V Model adalah model yang project oriented sehingga hanya bisa digunakan sekali dalam

suatu proyek.

V Model terlalu fleksibel dalam arti ada beberapa activity dalam V Model yang digambarkan

terlalu abstrak sehingga tidak bisa diketahui dengan jelas apa yang termasuk dalam activity

tersebut dan apa yang tidak.http://khoreullumam.blogspot.com/2013/02/v-model.html

Unified Software Development Process (USDP)Posted 19 May 2009

Filed under: Algorithm/Methodology |

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.


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.


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.


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.


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.


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.


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:

o Pencegahan atau penanggulangan terhadap resiko-resiko yang ada.

o Penanggulangan masalah-masalah kritis yang terjadi di dalam tim.

o Penelitian yang berkaitan dengan masalah-masalah yang ada beserta solusinya.

o 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>

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>

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>

UCL Computer Science. Unified Software Development Process.

< http://www.cs.ucl.ac.uk/staff/ucacwxe/lectures/3C05-03-04/USDP.pdf>

Wikipedia. Unified Process.

< http://en.wikipedia.org/wiki/Unified_Process>

jenis metode pengembangan perangkat lunak

Documents