RUP
(Rational Unified Process)
Nama kelompok : Ardhiyan Dwi Saputra (21112040)
Gifari
Nuzulla (23112144)
Satrio wibowo
(26112882)
Yuliyan Danu Pratama (27112949)
Martin Surya Darma (24112464)
FAKULTAS ILMU KOMPUTER DAN TEKNOLOGI INFORMASI
UNIVERSITAS GUNADARMA
2013
Definition of RUP
The Rational Unified Process® is a Software Engineering Process. It
provides a disciplined approach to assigning tasks and responsibilities within
a development organization. Its goal is to ensure the production of
high-quality software that meets the needs of its end-users, within a
predictable schedule and budget.
The Rational Unified Process is a process product,
developed and maintained by Rational® Software. Thedevelopment team for the
Rational Unified Process are working closely with customers, partners,
Rational's product groups as well as Rational's consultant organization, to
ensure that the process is continuously updated andimproved upon to reflect
recent experiences and evolving and proven best practices.
The Rational Unified Process enhances team productivity,
by providing every team member with easy access to a knowledge base with guidelines, templates and
tool mentors for all critical development activities. By having all team
members accessing the same knowledge base, no matter if you work with
requirements, design, test, project management, or configuration management, we
ensure that all team members share a common language, process and view of how
to develop software.
The Rational Unified Process activities create and
maintain models. Rather than focusing on the production of large amount of
paper documents, the Unified Process emphasizes the development and maintenance
of models—semantically rich representations of the software system under
development. [3, 7, 8]
The Rational Unified Process is a guide for how to
effectively use the Unified Modeling Language (UML). The UML is an
industry-standard language that allows us to clearly communicate requirements, architectures
and designs. The UML was originally created by Rational Software, and is now
maintained by the standards organization Object Management Group (OMG). [4]
The Rational Unified Process is supported by tools, which
automate large parts of the process. They are used to create and maintain the
various artifacts—models in particular—of the software engineering process:
visual modeling, programming, testing, etc. They are invaluable in supporting
all the bookkeeping associated with the change management as well as the
configuration management that accompanies each iteration.
The Rational Unified Process is a configurable process.
No single process is suitable for all software development.
The Unified Process fits small development teams as well
as large development organizations. The Unified Process is founded on a simple and clear process
architecture that provides commonality across a family of processes. Yet, it can
be varied to accommodate different situations. It contains a Development Kit,
providing support for configuring the process to suit the needs of a given
organization.
The Rational Unified Process captures many of the best
practices in modern software development in a form that is suitable for a wide
range of projects and organizations. Deploying these best practices using the
Rational Unified Process as your guide offers development teams a number of key
advantages. In next section, we describe the six fundamental best practices of
the Rational Unified Process.
Latar Belakang Masalah
Dalam dunia teknologi sekarang pengembangan dalam bidang
informatikan telah mengalami perkembangan yang sangat pesat. Dengan
perkembangan ini, dalam bidang informatika tidak hanya menghasilkan hanya dalam
pengembangan program perangkat lunak saja, melainkan pengambangan dalam bidang
suatu permodelan yang bersifat komplek. Dalam pembuatan sebuah perangkat lunak
yang haruslah memiliki Teknik analisa kebutuhan dan teknim permodelan yang
baik, supaya terwujudnya suatu perangkat lunak yang baik. Dengan hal tersebut
maka perlulah suatu pengenalan mengenai permodelan dalam suatu pembangunan
suatu Perangkat Lunak (Software).
Terdapat banyak permodelan
mengenai pembangunan suatu
Perangkat lunak seperti SDLC dan Agile Model. Yang dimana
dari setiap model ini memiliki macam macam model lainnya.Berdasarkan tugas yang
kami peroleh, kami hanya membatasi penjelasan mengenai permodelan ini, hanya
memberikan konsep mengenai kekurangan, kelebihan dari V
model, Increment Model, Prototyping Model, Spiral Model dan Concurrent
Development Model.
Memberikan
penjelasan menganai Agile
Process yang mencakupi
Extreme Programming (XP)
dan SCRUM, serta membandingkan antara RUP ( Rational Unified Proccess).
RUP (Rational Unified Process)
Rational Unified Process (RUP) merupakan suatu metode
rekayasa perangkat lunak yang
dikembangkan dengan mengumpulkan
berbagai best practises
yang terdapat dalam industri pengembangan perangkat lunak.
Ciri utama metode ini adalah menggunakan use-case driven
dan pendekatan iteratif
untuk siklus pengembangan
perankat lunak.
Gambar dibawah menunjukkan secara keseluruhan arsitektur
yang dimiliki RUP.
RUP menggunakan konsep
object oriented, dengan
aktifitas yang berfokus
pada pengembangan model dengan
menggunakan Unified Model
Language (UML). Melalui gambar dibawah dapat dilihat bahwa
RUP memiliki, yaitu:
Dimensi pertama digambarkan
secara horizontal. Dimensi
ini mewakili aspek-aspek dinamis dari
pengembangan perangkat lunak.
Aspek ini dijabarkan
dalam tahapan pengembangan atau
fase. Setiap fase
akan memiliki suatu
major milestone yang menandakan akhir dari awal dari phase
selanjutnya. Setiap phase dapat berdiri dari satu beberapa iterasi. Dimensi ini
terdiri atas Inception,
Elaboration, Construction, dan Transition.
Dimensi kedua digambarkan secara vertikal. Dimensi ini mewakili
aspek-aspek statis dari proses pengembangan
perangkat lunak yang
dikelompokkan ke dalam
beberapadisiplin. Proses pengembangan
perangkat lunak yang
dijelaskan kedalam beberapa disiplin terdiri dari empat elemen
penting, yakni who is doing, what, how dan when. Dimensi ini terdiri atas;
Gambbar Arsitekktur Rationaal Unified Prrocess
Pada pengggunaan keddua
standarrd tersebut diatas
yanng berorienttasi obyek
(object
orinted) memiliki manfaat yakkni:
1. Improve prroductivity
Stanndard ini dapat memaanfaatkan kembali kommponen-kommponen yan telah
tersedia/dibbuat sehinggga dapat meeningkatkann produktifittas
2. Deliver higgh quality syystem
Kuaalitas sistem informasi dapat ditinngkatkan sebbagai sistem yang dibuuat
pada
komponenkkomponen yyang telah teruji (welll-tested dann well-proveen)
sehinggga dapat
memperceppat delivery sistem infoormasi yangg dibuat denngan kualitas yang
tingggi.
3. Lower mainntenance coost
Stanndard ini ddapat membbantu
untukk menyakinnkan dampaak perubahaan yang
terlokalisassi dan masaalah
dapat dengan muudah
terdetteksi sehinggga hasilnyya
biaya
pemeliharaaan dapat diioptimalkan atau lebih rendah denngan
pengemmbangan nformasi
tanpa standdard yang jeelas.
4. Facilitate rreuse
Stanndard ini memiliki
kemampuaan yang mengembanngkan kommponen-
komponen yang dapat digunakan kembali
ntuk pengemmbangan apllikasi yang lainnya.
5. Manage coomplexity
Stanndard ini muudah untuk mengatur dan memoniitor semua proses dari semua tahapan yang ada sehingga suatu pengembangan sistem informasi yang amat
kompleks dapat dilakukan dengan aman dan sesuai dengan harapan semua
manajer
proyek IT/IS yakni deliver good quality software within cost and schedule
time and
the users accepted.
Fase RUP
1. Inception/insepsi
a.
Menentukan Ruang lingkup proyek
b.
Membuat ‘Business Case’
c. Menjawab pertanyaan “apakah yang dikerjakan
dapat menciptakan ‘good business sense’ sehingga proyek dapat dilanjutkan
2. Elaboration/elaborasi
a.
Menganalisa berbagai persyaratan dan resiko
b.
Menetapkan ‘base line’
c.
Merencanakan fase berikutnya yaitu construction
3. Construction/konstruksi
a.
Melakukan sederetan iterasi
b.
Pada setiap iterasi akan melibatkan proses berikut: analisa desain,
implementasi dan testing
4. Transition/transisi
a.
Membuat apa yang sudah dimodelkan menjadi suatu produk jadi
b. Dalam fase ini dilakukan: Beta dan
performance testing Membuat dokumentasi tambahan seperti; training, user guides
dan sales kit Membuat rencana peluncuran produk ke komunitas pengguna
Peran Use Case Pada Setiap Fase
• Inception
– Menolong
mengembangkan scope proyek
– Menolong
menetapkan penjadwalan dan anggaran
• Elaboration
– Menolong
dalam melakukan analisa resiko
– Menolong
mempersiapkan fase berikutnya yaitu konstruksi
• Construction
– Melakukan
sederetan iterasi
– Pada setiap iterasi
akan akan melibatkan proses berikut: analisa desain, implementasi dan testing
• Transistion
– Membuat
apa yang sudah dimodelkan menjadi suatu produk jadi
– Dalam
fase ini dilakukan:
• Beta dan performance
testing
• Membuat dokumentasi
tambahan seperti; training, user guides dan sales kit
• Membuat rencana
peluncuran produk ke komunitas pengguna
Penerapan Tahapan Metodologi Pengembagan
Perangkat Lunak dengan Menggunakan
RUP (Contoh Kasus)
Metodologi
Rational Unified Process
(RUP). Metode RUP
merupakan metode
pengembangan kegiatan yang berorientasi pada proses. Dalam metode ini,
terdapat empat
tahap pengembangan perangkat lunak yaitu:
1. Inception
Pada
tahap ini pengembang
mendefinisikan batasan kegiatan,
melakukan
analisis kebutuhan user,
dan melakukan perancangan
awal perangkat lunak
(perancangan arsitektural dan use case). Pada akhir fase ini, prototipe
perangkat lunak
versi Alpha harus sudah dirilis.
2. Elaboration
Pada tahap ini
dilakukan perancangan perangkat
lunak mulai dari
menspesifikasikan fitur perangkat lunak hingga perilisan prototipe versi
Betha dari
perangkat lunak.
3. Construction
Pengimplementasian rancangan perangkat lunak yang telah dibuat dilakukan
pada tahap ini. Pada akhir tahap ini, perangkat lunak versi akhir yang
sudah disetujui
administrator dirilis beserta
dokumentasi perangkat lunak. Perkembangan sistem.
Melakukan sederetan iterasi. Pada
setiap iterasi akan
melibatkan proses berikut: analisa desain,
implementasi dan
testing.
4. Transition
Instalasi , deployment dan sosialisasi perangkat lunak dilakukan pada tahap
ini. Menyediakan sistem untuk end user dari sistem
tersebut.
Membuat apa yang sudah dimodelkan menjadi suatu produk jadiDalam fase ini
dilakukan:
• Beta dan performance
testing.
• Membuat dokumentasi
tambahan seperti; training, user guides dan sales kit.
• Membuat rencana
peluncuran produk ke komunitas pengguna.
Untuk memperoleh manfaat maksimal dari UML
beberapa yang sebaiknya menjadi
bahan pertimbangan dalam proses pembuatan software adalah :
• Use case driven
Use
case driven merupakan
proses yang menjadikan
usecase sebagai pusat
atau
central dari arsitektur
software. Menggunakan use
case sebagai artifact
utama untuk
membangun behavior yang dinginkan dari sistem, untuk keperluan verifikasi
dan validasi
arsitektur sistem dari software. Disamping itu juga untuk keperluan testing
dan komunikasi
antar stakeholder proyek.
Arsitektur 4+1 merupakan arsitektur sistem
yang use case driven. Arsitektur software penting
untuk menentukan langkah-langkah membuat software. Berikut gambar
arsitektur 4+1 :
Contoh arsitektur 4+1
Rational Unified Process menitikberatkan pada aktifitas menciptakan dan merawat
model daripada aktifitas produksi yang memfokuskan pada penciptaan dokumen
project yang
banyak.
• Architecture-centric
Arsitektur sistem digunakan sebagai artifact primer untuk konseptualisasi,
konstruksi,
pengaturan, dan mengembangkan sistem selama pengembangan.
• Iterative and
incremental
Sebuah proses yang iterative merupakan salah satu yang termasuk pengaturan
aliran
dari keluaran yang executable.
Rational Unified Process terdiri dari :
Workflow yang
menghasilkan model: requirements,
analysis, design/deployment,
implementation, test.
Workers yang
mengimplementasikan workflow :
user, manager, analis,
architect,
designer, tester, dsb.
Phasa development dan
iterasi: inception, elaboration, construction, transition
Aktivitas dalam
iterasi: perencanaan, eksekusi workflow , evaluasi.
STRUKTUR RINGKAS DARI WORKFLOW
Role Aktivitas RUP dan Workers
1.
Aturan kesatu
2.
Aturan kedua
3.
aturan ketiga
Analysis Model
Analisa class-class dan/atau subsystems :
·
Fokus pada fungsional requirement
·
Konseptual, granularity yang besar
·
Model desain akan mempunyai elemen model
·
Minimal interface operasi
·
Definisi responsibilities (textual)
·
Atribute pada high level
·
Relasi konseptual
·
Boundary (interaksi dengan actor), control (koordinasi, sequencing,
transaksi) atau entity (long-lived real-life object atau event) class-class.
·
Desain/Deployment
Aktivitas pada saat desain meliputi :
• Menentukan bentuk sistem
arsitektur yang memenuhi semua requirements.
• Memahami isu pada requirements
non-fungsional dan batasan teknologi.
• Mengidentitaskan subsystem ( semua
struktur, requirement, interface, class- class)
yang membolehkan implementasi
konkuren.
• Membuat abstraksi yang tak
terlihat pada implementasi sistem.
Implementasi menambah isi ke
arsitektur yang stabil.
• Menyediakan visualisasi implementasi.
- Implementasi
Tugas-tugas pada tahap implementasi meliputi :
• Implementasi desain dalam
komponen-komponen {source code, script, binary,
executable, dsb.}
• Sempurnakan arsitektur.
• Rencanakan integrasi sistem pada
setiap iterasi.
incremental : kecil dan langkah
yang teratur.
• Distribusi sistem : petakan
komponen ke node-node.
• Implementasi class-class desain
dan subsystem.
• Komponen-komponen unit testing.
• Integrasi komponen-komponen (
kompile dan link ke dalam satu atau lebih executable ) untuk integrasi dan
testing sistem.
Implementasi Aktivitas Workflow dan Workers
Berikut model implementasi aktivitas workflow dan workers :
Testing
Aktivitas yang dilakukan meliputi :
• Verifikasi hasil dari
implementasi dengan testing setiap pembangunan
• Rencanakan test pada
setiap iterasi
Test integrasi untuk setiap pembangunan dalam iterasi
Test sistem untuk akhir iterasi
• Test desain dan
implementasi dengan membuat
Kasus-kasus test untuk menentukan apa yang akan ditest
Prosedur-prosedur test yang menentukan
bagaimana melakukan test
Komponen test executable untuk mengotomasi test
• Lakukan test dan secara
sistematis menangani hasil test
Pembangunan yang cacat dikirim ke workflow yang lain (misalnya desain
dan implementasi) untuk perbaikan kecacatan
Testing pada daur hidup software
Pada umumnya, dimanapun ada hasil implementasi, terdapat sebuah test.
Sebagai contoh adalah test pada setiap pembangunan.
Phasa Inception
Pada phasa ini meliputi : perencanaan test awal, test prototype.
Phasa Elaboration
Meliputi : test dasar arsitektural.
Phasa Construction
Meliputi : testing pada setiap pembangunan.
Phasa Transition
Meliputi : re-test perbaikan dan test regresi.
Test regresi merupakan test terhadap pembanguan lama saat pembangunan
baru untuk meyakinkan tidak ada kesalahan dalam pembangunan baru.
Menyusun model test
• Membuat kasus-kasus test yang
baru untuk setiap pembangunan.
• Perbaiki kasus-kasus test lama
menjadi test regresi.
• Pindahkan testing, prosedur dan komponen
test kuno yang berhubungan.
Prosedur Test
• Menentukan bagaimana melakukan
satu atau beberapa test case atau sebagian
dari padanya.
Instruksi untuk tester dalam manual test case.
Instruksi untuk interaksi dengan tool tes otomatis untuk membuat komponen
tes executable kemudian instruksi untuk mengintegrasikan dan mengeksekusi
komponen tes tersebut
• Satu prosedur tes mungkin
meliputi beberapa test case.
• Satu prosedur tes mungkin
membutuhkan beberapa test case.
• Instruksi prosedur tes sering
merefleksikan deskripsi flow-of-events, termasuk
nilai input, bagaimana
untuk memasukkan nilai
input dan bagaimana
memverifikasi hasil.
2.1 Model SDLC
2.1.1 V Model
V Model memiliki
beberapa kelebihan. Kelebihan-kelebihan tersebut
secara garis besar
dapat dijelaskan seperti berikut:
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.
V Model juga memiliki beberapa kekurangan. Kekurangan-kekurangan tersebut
yaitu:
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.
2.1.2 Incremental Model
2.1.3 Model Rapid Application
Development (RAD)
Rapid Application Development (RAD) adalah model proses pengembangan
perangkat lunak
yang bersifat inkrementalterutama untuk
waktu pengerjaan yang
pendek. Dodep RAD
merupakan
adaptasi dari permodelan waterfall versi kecepatan tinggi dan menggunakan
model waterfall untuk
pengembangan setiap komponen perangkat lunak.
Kelemahan dan Kelebihan
Model RAD memiliki kelemahan sebagai berikut :
Untuk pembuatan
sistem perangkat lunak
dengan skala besar
makamodel RAD akan
memerlukan sumber daya
manusia yang cukup
besar untuk membentuk
tim-tim yang
mengembangkan komponen-komponen;
Jika ada persetujuan
untk mengembangkan perangkat lunak dengan cara cepat (rapid) maka
proyek dengan model
ini akangagal, karena
akan membingungkan ketika
mendefinisikan
kebutuhan pelanggan;
Jika sistem perangkat lunak yang akan dibuat tidak bisa
dimodulkan (dibagi – bagi menjadi
beberapa komponen) maka
model RAD tidak
dapat digunakan untuk
membuat sistem
perangkat lunak ini karena terlalu banyak campur tangan antar tim;
Model RAD tidak cocok
digunakan untuk sistem perangkat lunak yang memiliki resiko teknis
sangat tinggi, misalnya
manggunakan teknologi baru
yang belum banyak
dikenal dan
dikuasai pengembang.
Selain itu, model RAD memiliki kelebihan sebagai berikut :
• Setiap fungsi mayor
dapat dimodulkan dalam waktu tertentu kurang dari 3 bulan dandapat
dibicarakan oleh tim
RAD yang terpisah
dan kemudian diintegrasikan sehinngawaktunya
lebih efesien.
• RAD mengikuti tahapan pengembangan sistem sepeti umumnya, tetapi
mempunyaikemampuan untuk menggunakan kembali komponen yang ada (reusable
object) sehingga pengembang pengembang
tidak perlu membuat
dari awal lagi
dan
waktulebih singkat .
2.1.4 Prototype Model
Prototyping merupakan salah satu metode pengembangan perangat lunak yang
banyak digunakan. Dengan metode prototyping ini pengembang dan pelanggan dapat
salingberinteraksi selama proses pembuatan sistem.Seing terjadi seorang pelanggan hanya
mendefinisikan secara umum apa yangdikehendakinya tanpa menyebutkan secara
detal output apa
saja yang dibutuhkan,pemrosesan dan
data-data apa saja
yang dibutuhkan. Sebaliknya
disisi
pengembang kurangmemperhatikan efesiensi
algoritma, kemampuan sistem
operasi dan interface
yangmenghubungkan manusia dan
komputer. Untuk mengatasi ketidakserasian antara
pelanggan
dan pengembang ,
maka harusdibutuhakan kerjasama
yanga baik diantara
keduanya sehingga
pengembang akanmengetahui dengan benar apa yang diinginkan pelanggan dengan tidak
mengesampingkansegi-segi teknis
dan pelanggan akan
mengetahui proses-proses dalm
menyelasaikan sistemyang diinginkan.
Dengan demikian akan
menghasilkan sistem sesuai
dengan
jadwal waktupenyelesaian yang
telah ditentukan. Kunci
agar model prototype
ini berhasil dengan
baik adalah dengan
mendefinisikanaturan-aturan
main pada saat
awal, yaitu pelanggan
dan
pengembang harus setuju
bahwaprototype dibangun untuk
mendefinisikan kebutuhan. Prototype
akan dihilangkan sebagianatau
seluruhnya dan perangkat
lunak aktual aktual
direkayasa dengan
kualitas danimplementasi yang sudah ditentukan.
Tahapan-tahapan Prototyping
Tahapan-tahapan dalam Prototyping adalah sebagai berikut:
1. Pengumpulan
kebutuhanPelanggan dan pengembang bersama-sama mendefinisikan format
seluruh perangkatlunak, mengidentifikasikan semua kebutuhan, dan garis
besar sistem yang
akan dibuat.
2. Membangun prototyping
Membangun prototyping dengan
membuat perancangan sementara
yang berfokuspada
penyajian kepada pelanggan (misalnya dengan membuat input dan formatoutput)
3. Evaluasi protoptyping
Evaluasi ini dilakukan oleh pelanggan apakah prototyping yang sudah
dibangun sudahsesuai
dengan keinginann pelanggan.
Jika sudah sesuai
maka langkah 4
akan diambil.Jika tidak
prototyping direvisi dengan mengulangu langkah 1, 2 , dan 3.
4. Mengkodekan sistem
Dalam tahap ini prototyping yang sudah di sepakati diterjemahkan ke dalam
bahasapemrograman yang sesuai
5. Menguji sistem
Setelah sistem sudah
menjadi suatu perangkat
lunak yang siap
pakai, harus ditesdahulu
sebelum digunakan. Pengujian
ini dilakukan dengan
White Box, Black
Box,Basis Path,
pengujian arsitektur dan lain-lain
6. Evaluasi SistemPelanggan
mengevaluasi apakah sistem yang sudah jadi sudah sesuai dengan
yangdiharapkan . Juka ya, langkah 7 dilakukan; jika tidak, ulangi langkah 4
dan 5.
7. Menggunakan sistemPerangkat lunak
yang telah diuji
dan diterima pelanggan
siap untuk
digunakan .
Keunggulan dan Kelemahan Prototyping
Keunggulan prototyping adalah:
1. Adanya komunikasi yang
baik antara pengembang dan pelanggan.
2. Pengembang dapat bekerja
lebih baik dalam menentukan kebutuhan pelanggan
3. Pelanggan berperan aktif
dalam pengembangan sistem
4. Lebih menghemat waktu
dalam pengembangan sistem
5. Penerapan menjadi lebih
mudah karena pemakai mengetahui apa yang diharapkannya.
Kelemahan prototyping adalah :
1. Pelanggan kadang
tidak melihat atau
menyadari bahwa perangkat
lunak yang ada
belum
mencantumkan kualitas perangkat
lunak secara keseluruhan
dan juga belummemikirkan
kemampuan pemeliharaan untuk jangja waktu lama.
2. pengembang biasanya
ingin cepat menyelesaikan proyek. Sehingga menggunakanalgoritma dan
bahasa pemrograman yang
sederhana untuk membuat
prototypinglebih cepat selesai
tanpa
memikirkan lebih lanjut bahwa program tersebut hanyamerupakan cetak biru
sistem .
3. Hubungan pelanggan
dengan komputer yang
disediakan mungkin tidak mencerminkan teknik
perancangan yang baik Prototyping bekerja dengan baik pada
penerapan-penerapan yang berciri
sebagai berikut:
1. Resiko tinggi Yaitu untuk maslaha-masalah yang tidak terstruktur dengan baik,
adaperubahan yang besar dari
waktu ke waktu,
dan adanya persyaratan
data yang
tidak menentu.
2. Interaksi pemakai
penting . Sistem harus menyediakan dialog
on-line antarapelanggan dan
komputer.
3. Perlunya penyelesaian
yang cepat
4. Perilaku pemakai yang
sulit ditebak
5. Sitem yang
inovatif. Sistem tersebut
membutuhkan cara penyelesaian masalah dan
penggunaan perangkat keras yang mutakhir.
6. Perkiraan tahap
penggunaan sistem yang pendek
2.1.5 Model Spiral
Model spiral pada
awalnya diusulkan oleh
Boehm, adalah model
proses perangkatlunak
evolusioner yang merangkai
sifat iteratif dari
prototype dengan cara
kontrol dan aspek sistematis
model sequensial linier.Model iteratif ditandai dengan tingkah laku yang memungkinkan
pengembangmengembangkan versi perangkat lunak yang lebih lengkap secara
bertahap. Perangkat
lunak dikembangkan dalam deretan pertambahan. Selama awal iterasi, rilis
inkremantal bisaberupa
model/prototype kertas, kemudian sedikit demi sedikit dihasilkan versi
sistem yanglebih lengkap.
Tahapan-Tahapan Model Spiral
Model spiral dibagi menjadi enam wilayah tugas yaitu:
1. Komunikasi pelanggan
Yaitu tugas-tugas untuk membangun komunikasi antara pelanggan dan kebutuhan-
kebutuhan yang diinginkan oleh pelanggan.
2. Perencanaan
Yaitu tugas-tugas untuk mendefinisikan sumber daya, ketepatan waktu, dan
proyek informasi lain yg berhubungan.
3. Analisis Resiko
Yaitu tugas-tugas yang dibutuhkan untuk menaksir resikomanajemen dan
teknis.
4. Perekayasaan
Yaitu tugas yang
dibutuhkan untuk membangun
satu atau lebih
representasi dari apikasi
tersebut.
5. Konstruksi dan
peluncuran
Yaitu tugas-tugas yang dibutuhkan untuk mengkonstruksi, menguji, memasang ,
danmemberi pelayanan kepada pemakai.
6. Evaluasi Pelanggan
Yaitu tugas-tugas untuk mendapatkan umpan balik dari pelanggan.
Gambar 2. Model Spiral
Dari gambar tersebut,
proses dimulai dari
inti bergerak searah
dengan jarum jam
mengelilingi spiral. Lintasan
pertama putaran menghasilkan perkembangan spesifikasiproduk.
Putaran selanjutnya digunakan
untuk mengembangkan sebuah
prototype, dan secaraprogresif
mengembangkan versi perangkat
lunak yang lebih
canggih.
Masing-masinglintasan yang melalui
daerah perencanaan menghasilkan penyesuaian pada rencanan proyek.Biaya dan
jadwal disesuaikan
berdasarkan umpan balik
yang disimpulakan dari
evaluasi pelanggan. Manajer
proyek akan
menambah jumlah iterasi sesuai dengan yang dibutuhkan.
Kelebihan dan Kelemahan Model Spiral
a. Kelebihan model Spiral :
Dapat disesuaikan agar perangkat lunak bisa dipakai selama hidup perangkat
lunak komputer.
Lebih cocok untuk
pengembangan sistem dan perangkat lunak skala besar.
Pengembang dan pemakai dapat
lebih mudah memahami
dan bereaksi terhadapresiko
setiap tingkat evolusi karena perangkat lunak terus bekerja selama proses .
Menggunakan prototipe
sebagai mekanisme pengurangan resiko dan pada setiapkeadaan di
dalam evolusi produk.
Tetap mengikuti
langkah-langkah dalam siklus
kehidupan klasik dan
memasukkannyake
dalam kerangka kerja iteratif .
Membutuhkan pertimbangan
langsung terhadp resiko
teknis sehingga mengurangiresiko
sebelum menjadi permaslahan yang serius.
b. Kelemahan model Spiral:
Sulit untuk menyakinkan
pelanggan bahwa pendekatan evolusioner ini bisa dikontrol.
Memerlukan
penaksiran resiko yang masuk akal dan akan
menjadi masalah yangserius jika
resiko mayor tidak ditemukan dan diatur.
Butuh waktu lama untuk
menerapkan paradigma ini menuju kepastian yang absolutD.
2.1.6 Concurrent Development
Model
Concurrent Development Model merupakan
Kelebihan dan Kelemahan Concurrent Development Model
Kelebihan yang dimiliki oleh model ini adalah :
Proses Concurrent
Development Model ini
berlaku untuk semua
jenis pengembangan
perangkat lunak dan
memberikan gambaran yang
akurat tentang keadaan
sekarang dari
suatu proyek.
Kekurangan yang dimiliki oleh model ini adalah :
statenya sangat banyak
sehingga membutuhkan waktu lebih banyak.
2.2 Agile Proccces Model
Agile Software development
adalah salaha satu
metodologi dalam pengembangan
sebuah
perangkat lunak. Kata
Agile berarti bersifat
cepat, ringan, bebas
bergerak, waspada.Kata ini
digunakan sebagai kata
yang menggambarkan konsep
model proses yang
berbeda dari konsep
model – model proses yang sudah ada. Konsep agile software developoment
dicetuskan oleh Kent
Beck dan 16
rekannya dengan mengatakan
bahwa Agile Software
Development adalah cara
membangun software dengan melakukannya dan membantu orang lain membangunnya
sekaligus.
Dalam hal ini Agile Process model terdiri dari 5 macam model, yakni :
1. Extreme Programming (XP)
2. Adaptive Software
Development (ASD)
3. Dinamic System
Development Method
4. SCRUM
5. Agile Model
2.2.1 Extreme Programming (XP)
Extreme Programming (XP)
merupakan salah satu
metodologi dalam rekayasa
perangkat
lunak dan juga merupakan satu dari beberapa agile software development
methotodogies yang
berfokus pada coding sebagai aktivitas utama di semua tahap pada siklus
pengembangan yang
lebih responsive terhadap
kebutuhan costumer (“agile”)
di bandingkan dengan
metode –
metode tradisional sambil membangun suatu software dengan kualitas yang
lebih baik, selain itu
extreme programming meliputi seluruh area pengembangan perangkat lunak.
Model agile process
ini dikembangkan oleh
Kent Beck dan Ward
Cunningham pada bulan
maret 1996. Model
Extreme Programming (XP)
ini merupakan yang
terpopuler dari beberapa
metodologi pengembangan software yang dipakai untuk mengimplementasikan proyek pengembangan
perangkat lunak.
Tujuan Extreme Programming
Tujuan utama yang
ada pada extreme
programming adalah untuk
menurunkan biaya dari
adanya perubahan pembangunan
software. Dalam pengembangan
sistem tradisional, kebutuhan
sistem di tentukan awal pengembangan proyek dan bersifat fixed. Extreme
programming diarahkan
untuk menurunkan biaya
dari adanya perubahan
dengan memperkenalkan nilai-nilai
basis dasar,
prinsip dan praktis.
Dengan menerapkan extreme
xp, pembangunan suatu
sistem haruslah lebih
fleksibel terhadap terjadinga suatu perubahan.
Nilai-nilai Dasar XP
Berikut adalah nilai-nilai
mendasar yang menjadi
roh dari XP
pada setiap tahapan
proses
pengembangan perangkat lunak:
1. Communication (Komunikasi)
Tugas utama developer dalam membangun suatu sistem perangkat lunak adalah
mengkomunikasikan kebutuhan sistem kepada pengembang perangkat lunak.
Komunikasi dalam XP
dibangun dengan melakukan pemrograman berpasangan (pair programming).
Developer didampingi
oleh pihak klien dalam melakukan coding dan unit testing sehingga klien
bisa terlibat langsung dalam
pemrograman sambil berkomunikasi
dengan developer. Tujuannya
untuk memberikan pandangan
pengembang sesuai dengan pandangan pengguna sistem.
2. Simplicity (Kesederhanaan)
Extreme Programming XP
mencoba untuk mencari
solusi paling sederhana
dan praktis.
Perbedaan metode ini dengan metodologi pengembangan sistem konvensional
lainnya terletak pada
proses desain dan
coding yang terfokus
pada kebutuhan saat
ini daripada kebutuhan
besok,
seminggu lagi atau sebulan lagi. Lebih baik melakukan hal yang sederhana
dan mengembangkannya
besok jika diperlukan.
3. Feedback (Masukan)
Hal ini diperlukan
untuk mengetahui kemajuan
dari proses dan
kualitas dari aplikasi
yang
dibangun. Informasi ini
harus dikumpulkan setiap
interval waktu yang
singkat secara konsisten.
Ini
dimaksudkan agar hal-hal
yang menjadi masalah
dalam proses pengembangan
dapat diketahui
sedini mungkin. Setiap feed back ditanggapi dengan melakukan tes, unit test
atau system integration
dan jangan menunda karena biaya akan membengkak (uang, tenaga, waktu).
4. Courage (Keberanian)
Berani mencoba ide baru. Berani mengerjakan kembali dan setiap kali
kesalahan ditemukan,
langsung diperbaiki. Contoh
dari courage adalah
komitmen untuk selalu
melakukan design dan
coding untuk saat
ini dan bukan
untuk esok. Ketika
ada kode yang
terlalu rumit, sulit
dibaca dan
dipahami, tidak sesuai dengan kemauan pelanggan, dll maka seharusnya kode
program seperti itu di
refactor (kalau perlu
dibangun ulang). Hal
ini menjadikan pengembang
merasa nyaman dengan
refactoring program ketika diperlukan.
5. Respect (Menghormati)
Pentingnya respect terhadap
anggota team lainnya
karena dengan siklus
pendek dan
integrasi continue, programmer
tidak boleh melakukan
perubahan yang dapat
merusak kompilasi
dan menyebabkan keberadaan unit uji gagal atau memperlambat kerja team.
Respects tiap individu
akan selalu menghasilkan kualitas tinggi.
Aspek Dasar XP
Aspek dasar XP terdiri dari berbagai teknik atau metode yang diterapkan
Beck dan Jeffries pada
C3 Project. Teknik-teknik tersebut dapat diamati pada gambar berikut ini:
1. The Planning Game
Pendekatan XP dalam
perencanaan sangat mirip
dengan metode yang
diterapkan pada RAD
(Rapid Application Development). Proses
pendek dan cepat,
mengutamakan aspek teknik,
memisahkan unsur bisnis
dengan unsur teknis
dan pertemuan intensif
antara klien dengan
developer. Pada XP
proses ini menggunakan
terminologi “game” karena
Beck menyarankan
untuk menggunakan teknik
score card dalam
menentukan requirements. Semakin
sulit aspek
teknis yang dibutuhkan semakin tinggi pula skor pada kartu rencana
tersebut.
2. Small Releases
Setiap release dilakukan dalam lingkup sekecil mungkin pada XP. Setiap developer
menyelesaikan sebuah unit atau bagian dari perangkat lunak maka hasil
tersebut harus segera
dipresentasikan dan didiskusikan
dengan klien. Jika
memungkinkan untuk menerapkan
unit
tersebut pada perusahaan,
hal itu juga
dapat dilakukan sekaligus
sebagai tes awal
dari
penerapan keseluruhan sistem.
Kendati demikian hal
ini tidak selalu
perlu dilakukan karena
harus dihitung terlebih
dahulu sumberdaya yang
dibutuhkan. Apakah lebih
menguntungkan
langsung melakukan tes
terhadap unit tersebut
atau melakukan tes
setelah unit tersebut
terintegrasi secara sempurna pada sistem.
3. Metaphor
Metaphor pada dasarnya sama dengan arsitektur perangkat lunak. Keduanya
menggambarkan
visi yang luas
terhadap tujuan dari
pengembangan perangkat lunak.
Beck sendiri seperti
para
penandatangan Agile Manifesto
lainnya bercita-cita menyederhanakan proses
pengembangan
perangkat lunak yang
saat ini sudah
dianggap terlalu rumit.
Arsitektur yang saat
ini banyak
berisi diagram dan kode semacam UML dianggap terlalu rumit untuk
dimengerti, terutama oleh
klien. Metaphor, walaupun mirip dengan arsitektur lebih bersifat naratif
dan deskriptif. Dengan
demikian diharapkan komunikasi
antara klien dengan
developer akan berlangsung
lebih baik
dan lancar dengan penggunaan metaphor.
4. Simple Design
Sebagai salah seorang
penandatangan Agile Manifesto,
Beck adalah seorang
yang tidak
menyukai desain yang rumit dalam sebuah pengembangan perangkat lunak. Tidak
heran jika dia
memasukkan Simple Design sebagai salah satu unsur XP. Pada XP desain dibuat
dalam lingkup
kecil dan sederhana.
Tidak perlu melakukan
antisipasi terhadap berbagai
perubahan di
kemudian hari. Dengan
desain yang simpel
apabila terjadi perubahan
maka membuat desain
baru untuk mengatasi perubahan tersebut dapat dengan mudah dilakukan dan
resiko kegagalan
desain dapat diperkecil.
5. Refactoring
Refactoring adalah salah
satu aspek paling
khas dari XP. Refactoring
seperti didefinisikan oleh
Martin Fowler adalah ”Melakukan perubahan pada kode program dari perangkat
lunak dengan
tujuan meningkatkan kualitas
dari struktur program
tersebut tanpa mengubah
cara program
tersebut bekerja”. Refactoring sendiri sangat sesuai untuk menjadi bagian XP
karena Refactoring mengusung konsep penyederhanaan dari proses desain maupun
struktur baris kode
program. Dengan Refactoring
tim pengembang dapat
melakukan berbagai usaha
untuk
meningkatkan kualitas program
tanpa kembali mengulang-ulang proses
desain. Fowler adalah
salah satu kolega
dekat dari Kent
Beck karena itu
tidak mengherankan bahwa
cara berpikir
mereka terhadap proses pengembangan perangkat lunak sangat mirip satu
dengan lainnya.
6. Testing
XP menganut paradigma berbeda dalam hal tes dengan model pengembangan
perangkat lunak
lainnya. Jika pada
pengembangan perangkat lunak
lainnya tes baru
dikembangkan setelah
perangkat lunak selesai
menjalani proses coding
maka pada XP
tim pengembang harus
membuat terlebih dahulu
tes yang hendak
dijalani oleh perangkat
lunak. Berbagai model
tes
yang mengantisipasi penerapan
perangkat lunak pada
sistem dikembangkan terlebih
dan
Saat proses coding
selesai dilakukan maka perangkat lunak diuji
dengan model tes yang
telah
dibuat tersebut. Pengetesan akan jauh lebih baik apabila dilakukan pada
setiap unit perangkat
lunak dalam lingkup
sekecil mungkin daripada
menunggu sampai seluruh
perangkat lunak
selesai dibuat. Dengan
memahami tahap ini
kita dapat melihat
bahwa siklus pada
XP adalah
requirement analysis test code design. Sekilas terlihat hal ini tidak
mungkin dilakukan
tetapi pada kenyataannya memang gambaran inilah yang paling dapat menjelaskan
tentang XP.
7. Pair Programming
Pair programming adalah melakukan proses menulis program dengan
berpasangan. Dua orang
programer saling bekerjasama
di komputer yang
sama untuk menyelesaikan sebuah
unit.
Dengan melakukan ini maka keduanya
selalu dapat berdiskusi
dan saling melakukan
koreksi
apabila ada kesalahan
dalam penulisan program.
Aspek ini mungkin akan sulit dijalankan oleh
para programer yang
memiliki ego tinggi
dan sering tidak
nyaman untuk berbagi
komputer
bersama rekannnya.
8. Collective Ownership
Tidak ada satupun
baris kode program
yang hanya dipahami
oleh satu orang
programer. XP
menuntut para programer untuk berbagi pengetahuan untuk tiap baris program
bahkan beserta
hak untuk mengubahnya.
Dengan pemahaman yang
sama terhadap keseluruhan
program,
ketergantungan pada programer
tertentu ataupun berbagai
hambatan akibat perbedaan gaya
menulis program dapat
diperkecil. Pada level
yang lebih tinggi
bahkan dimungkinkan para
programer dapat bertukar unit yang dibangunnya.
9. Coding Standards
Pair programming dan collective ownership hanya akan dapat berjalan dengan
baik apabila para
programer memiliki pemahaman yang sama terhadap penulisan kode program.
Dengan adanya
coding standards yang
telah disepakati terlebih
dahulu maka pemahaman
terhadap program
akan menjadi mudah
untuk semua programer
dalam tim. Hal
ini dapat diterapkan
sebagai
contoh pada penamaan variabel dan penggunaan tipe data yang sama untuk tiap
elemen semua
record atau array pada program.
10. Continous Integration
Melakukan build setiap
hari kerja menjadi
sebuah model yang
disukai oleh berbagai
tim
pengembang perangkat lunak.
Hal ini terutama
didorong oleh keberhasilan
penerapan sistem
ini oleh Microsoft
dan telah sering
dipublikasikan. Dengan melakukan
build sesering mungkin
berbagai kesalahan pada
program dapat dideteksi
dan diperbaiki secepat
mungkin. Apabila
banyak tim pengembang perangkat lunak meyakini bahwa build sekali sehari adalah minimum
maka pada XP hal tersebut adalah
maksimum. Pada XP tim disarankan untuk melakukan build
sesering mungkin misalnya setiap 4 jam atau bahkan lebih cepat lagi.
11. 40-hours Week
Beck berpendapat bekerja
8 jam sehari
dan 5 hari
seminggu adalah maksimal
untuk tiap
programer. Lebih dari itu programer akan cenderung membuat berbagai error
pada baris-baris
kode programnya karena kelelahan.
12. On-Site Customer
Sebuah pendekatan klasik,
di mana XP
menganjurkan bahwa ada
anggota dari klien
yang
terlibat pada proses
pengembangan perangkat lunak.
Yang lebih penting
lagi ia harus
ada di
tempat pemrogaman dan turut serta dalam
proses build dan test yang dilakukan. Apabila ada
kesalahan dalam pengembangan
diharapkan klien dapat
segera memberikan masukan
untuk
koreksinya.
Keunggulan dan Kekurangan Extreme Programming
Keunggulan yang dimiliki adalah :
a. Menjalin komunikasi yang
baik dengan client.
b. Meningkatkan komunikasi
dan sifat saling menghargai antar developer.
Kelemahan yang dimiliki adalah :
a. Developer harus selalu
siap dengan perubahan karena perubahan akan selalu diterima.
b. Tidak bisa membuat kode
yang detail di awal (prinsip simplicity dan juga anjuran untuk
melakukan apa yang diperlukan hari itu juga).
2.2.2 SCRUM
Scrum adalah sebuah
pendekatan tangkas untuk
pengembangan perangkat lunak.
Scrum
merupakan suatu kerangka
kerja. Jadi, bukannya
menyediakan deskripsi rinci
tentang bagaimana
segala sesuatu yang harus dilakukan pada proyek seperti diserahkan kepada tim
pengembangan perangkat lunak pada umumnya. Hal ini dilakukan supaya tim
akan tahu bagaimana
cara terbaik untuk memecahkan
masalah yang mereka
disajikan. Inilah sebabnya mengapa,
misalnya, rapat perencanaan sprint
digambarkan dalam bentuk
hasil yang diinginkan
(komitmen
untuk mengatur fitur yang
akan dikembangkan di
sprint berikutnya), bukan
definisi Tugas, kriteria
Validasi, dllseperti yang akan disediakan dalam metodologi yang lain.
Scrum bergantung pada pengorganisasian-diri, tim lintas fungsional. Tim scrum
adalahmengorganisir diri dalam bentuk tidak ada pemimpin tim secara
keseluruhan yang
memutuskanmana orang yang
akan melakukan tugas
atau bagaimana suatu
masalah akan
dipecahkan. Mereka adalah
isu-isu yang ditentukan
oleh tim secara
keseluruhan. Tim ini
lintas
fungsional sehingga setiap orang perlu untuk mengambil fitur dari ide untuk
diimplementasi.
Tim-tim pengembangan scrum yang
didukung oleh dua orang tertentu: Scrum
Master dan pemilik produk (product owner ). Scrum Master dapat dianggap
sebagai pelatih bagi tim,
Membantu anggota tim menggunakan
kerangka Scrum untuk tampil di
tingkat tertinggi. Pemilik produk
mewakili bisnis, pelanggan
atau pengguna dan
memandu
tim ke arah
pegembangan produk yang
tepat.
Proyek Scrum membuat kemajuan dalam serangkaian sprint, yang timeboxed
iterasi tidak lebih
dari sebulan panjang.
Pada awal sprint,
anggota tim berkomitmen
untuk
memberikan beberapa nomor fitur yang terdaftar di product backlog proyek.
Pada akhir sprint, fitur
inidilakukan – mereka
diimplementasikan, diuji, dan
diintegrasikan ke dalam
produk
berkembangatau sistem. Pada
akhir sprint tinjauan
sprint dilakukan selama
tim menunjukkan
fungsi barukepada pemilik
produk dan pemangku
kepentingan lain yang
memberikan umpan balik
yang dapat mempengaruhi sprint berikutnya.
Dalam hal ini Scrum memiliki prinsip sebagai berikut :
• Ukuran tim yang kecil
melancarkan komunikasi, mengurangi biaya,dan memberdayakan satu
sama lain.
• Proses dapat
beradaptasi terhadap perubahan
teknis dan
bisnis proses menghasilkan beberapa software increment.
• Pembangunan dan orang
yang membangun dibagi dalam tim yang kecil.
• Dokumentasi dan
pengujian terus menerus
dilakukan setelah software
dibangun proses
BAB III
PENUTUP
3.1 Kesimpulan
SCRUM dan RUP merupakan metodologi pengembangan software yang memiliki
persamaan dan
perbedaan. Keduanya memiliki kelebihan dan kekurangan masing-masing. RUP
dan SCRUM memiliki
tipe proyek yang berbeda sehingga keduanya akan tepat apabila diterapkan
pada proyek yang sesuai
dengan tipikal masing-masing metodologi.
RUP (Rational Unified Process
Rational Unified Process
(RUP) merupakan suatu metode rekayasa perangkat lunak yang dikembangkan dengan
mengumpulkan berbagai best practises yang terdapat dalam industri
pengembangan perangkat lunak. Ciri utama metode ini adalah menggunakan use-case
driven dan pendekatan iteratif untuk siklus pengembangan perankat lunak.
Gambar dibawah menunjukkan secara keseluruhan arsitektur yang dimiliki RUP.
RUP menggunakan konsep object
oriented, dengan aktifitas yang berfokus pada pengembangan model dengan
menggunakan Unified Model Language (UML). Melalui gambar dibawah dapat
dilihat bahwa RUP memiliki, yaitu:
§ Dimensi pertama digambarkan secara horizontal. Dimensi ini mewakili aspek-aspek
dinamis dari pengembangan perangkat lunak. Aspek ini dijabarkan dalam tahapan
pengembangan atau fase. Setiap fase akan memiliki suatu major milestone
yang menandakan akhir dari awal dari phase selanjutnya. Setiap phase dapat
berdiri dari satu beberapa iterasi.
Dimensi ini terdiri atas Inception, Elaboration, Construction,
dan Transition.
§ Dimensi kedua digambarkan
secara vertikal. Dimensi ini mewakili aspek-aspek statis dari proses pengembangan
perangkat lunak yang dikelompokkan ke dalam beberapa disiplin. Proses
pengembangan perangkat lunak yang dijelaskan kedalam beberapa disiplin terdiri
dari empat elemen penting, yakni who is doing, what, how
dan when. Dimensi
ini terdiri atas
Business Modeling,
Requirement, Analysis and Design, Implementation, Test, Deployment,
Configuration dan Change Manegement, Project Management, Environtment.
Gambar Arsitektur Rational Unified Process
Pada
penggunaan kedua standard tersebut diatas yang berorientasi obyek (object
orinted) memiliki manfaat yakni:
• Improve productivity
Standard ini dapat
memanfaatkan kembali komponen-komponen yang telah tersedia/dibuat sehingga
dapat meningkatkan produktifitas
• Deliver high quality
system
Kualitas sistem informasi
dapat ditingkatkan sebagai sistem yang dibuat pada komponenkomponen yang telah
teruji (well-tested dan well-proven) sehingga dapat mempercepat delivery
sistem informasi yang dibuat dengan kualitas yang tinggi.
• Lower maintenance
cost
Standard ini dapat
membantu untuk menyakinkan dampak perubahan yang terlokalisasi dan masalah
dapat dengan mudah terdeteksi sehingga hasilnya biaya pemeliharaan dapat
dioptimalkan atau lebih rendah dengan pengembangan informasi tanpa standard
yang jelas.
• Facilitate reuse
Standard ini memiliki
kemampuan yang mengembangkan komponen-komponen yang dapat digunakan kembali
untuk pengembangan aplikasi yang lainnya.
• Manage complexity
Standard ini mudah untuk mengatur
dan memonitor semua proses dari semua tahapan yang ada sehingga suatu
pengembangan sistem informasi yang amat kompleks dapat dilakukan dengan aman
dan sesuai dengan harapan semua manajer proyek IT/IS yakni deliver good quality
software within cost and schedule time and the users accepted.
Fase RUP
§ Inception/insepsi
§ Elaboration/elaborasi
§ Construction/konstruksi
§ Transition/transisi
•
Inception
–
Menentukan
Ruang lingkup proyek
–
Membuat
‘Business Case’
–
Menjawab
pertanyaan “apakah yang dikerjakan dapat menciptakan ‘good business sense’
sehingga proyek dapat dilanjutkan
•
Elaboration
–
Menganalisa
berbagai persyaratan dan resiko
–
Menetapkan
‘base line’
–
Merencanakan
fase berikutnya yaitu construction
•
Construction
–
Melakukan
sederetan iterasi
–
Pada
setiap iterasi akan melibatkan proses berikut: analisa desain, implementasi dan
testing
•
Transistion
–
Membuat
apa yang sudah dimodelkan menjadi suatu produk jadi
–
Dalam
fase ini dilakukan:
•
Beta
dan performance testing
•
Membuat
dokumentasi tambahan seperti; training, user guides dan sales kit
•
Membuat
rencana peluncuran produk ke komunitas pengguna
Peran Use Case Pada Setiap Fase
•
Inception
–
Menolong
mengembangkan scope proyek
–
Menolong
menetapkan penjadwalan dan anggaran
•
Elaboration
–
Menolong
dalam melakukan analisa resiko
–
Menolong mempersiapkan fase berikutnya yaitu
konstruksi
•
Construction
–
Melakukan
sederetan iterasi
–
Pada setiap iterasi akan akan melibatkan
proses berikut: analisa desain, implementasi dan testing
•
Transistion
–
Membuat
apa yang sudah dimodelkan menjadi suatu produk jadi
–
Dalam
fase ini dilakukan:
•
Beta
dan performance testing
•
Membuat
dokumentasi tambahan seperti; training, user guides dan sales kit
•
Membuat
rencana peluncuran produk ke komunitas pengguna
Penerapan
Tahapan Metodologi Pengembagan Perangkat Lunak dengan Menggunakan RUP (Contoh
Kasus)
Metodologi
Rational Unified Process (RUP). Metode
RUP merupakan metode pengembangan kegiatan yang berorientasi pada proses. Dalam metode ini, terdapat empat tahap
pengembangan perangkat lunak yaitu:
§
Inception
Pada tahap ini pengembang mendefinisikan batasan
kegiatan, melakukan analisis kebutuhan user, dan melakukan
perancangan awal perangkat lunak (perancangan
arsitektural dan use case). Pada
akhir fase ini, prototipe perangkat lunak versi Alpha harus sudah
dirilis
§ Elaboration
:
Pada tahap ini dilakukan perancangan perangkat lunak
mulai dari menspesifikasikan fitur perangkat lunak hingga perilisan prototipe
versi Betha dari perangkat lunak.
§ Construction
Pengimplementasian
rancangan perangkat lunak yang telah dibuat dilakukan pada tahap ini. Pada
akhir tahap ini, perangkat lunak versi akhir yang sudah disetujui administrator
dirilis beserta dokumentasi perangkat lunak.
§
Transition
Instalasi
, deployment dan sosialisasi perangkat lunak dilakukan pada tahap ini.
Sumber – sumber
http://handzmentallist.blogspot.com/2012/04/rup-rational-unified-process.html
source: http://blog.unsri.ac.id/aswin/ooad/rational-unified-process/mrdetail/161/
http://student.uniku.ac.id/sutarna/2013/01/16/metodologi-rup-rational-unified-prosess/
http://wahyueutomo.wordpress.com/2013/04/02/rational-unified-process/
http://aih25.blogspot.com/2013/03/rup-rational-unified-process.html
http://rmhd.wordpress.com/2007/07/24/rational-unified-process/
http://12puby.wordpress.com/2010/06/09/metodologi-pengembangan-perangkat-lunak/
Tidak ada komentar:
Posting Komentar