View
452
Download
19
Category
Preview:
DESCRIPTION
dsad
Citation preview
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
(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.
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:
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>
Recommended