Nama : Rendi setiawan
Nim : L200133050
Kelas : B
A.
Definisi
adaptive software development (ASD)
Adaptive
Software Development (ASD) diajukan oleh Jim Highsmith sebagai teknik untuk
membangun software dan sistem yang kompleks. Filosofi yang mendasari Adaptive
Software Development (ASD) adalah kolaborasi manusia dan tim yang mengatur diri
sendiri.
System
kerja adaptive software development ada 3 : Speculation, Collaboration dan
Learning. Adaptive cycle planning yaitu menggunakan informasi awal seperti misi
dari klien, batasan proyek dan kebutuhan dasar untuk definisikan rangkaian
software increment (produk software yang secara berkala diserahkan).
Gambar 1. Proses Adaptive
Software Development (ASD)
ASD
merupakan suatu model yang tergolong dalam pendekatan agile yang diusulkan oleh
Jim Highsmith. ASD menekankan pada pengorganisasian tim secara mandiri,
kolaborasi antar-perseorangan, dan terus belajar, baik secara individu maupun
secara tim. ASD menggunakan tools yang disebut "time-boxing" - yaitu
berupa aktifitas yang menentukan jangka waktu tertentu yang dialokasikan untuk
menyelesaikan berbagai macam tugas. Apabila waktu yang ditentukan tersebut
selesai, maka pembangunan sistem akan pindah ke tugas berikutnya, dengan
harapan bahwa sebagian besar dari critical work telah berhasil diselesaikan
sebelum waktu keseluruhan tugas berakhir. Terdapat tiga tahapan pada model ASD,
yaitu: Speculation, Collaboration, dan Learning.
Adaptive
Software Development (Pressman, 2005)
Pada
tahap Speculation, proyek dimulai dan adaptive cycle planning diselenggarakan.
Pada tahapan ini, didefinisikan visi dan misi pengguna terhadap sistem yang
akan dibuat, selanjutnya mendefinisikan project constraints, misalnya: waktu
deliver. dan selanjutnya mendefinisikan satu set dari requirements yang akan
dikerjakan dalam suatu cycle.
Pada
tahap Collaboration, pada tahap ini diorganisasikan tim kerja untuk membangun
sistem. Direkomendasikan menggunakan model Joint Application Development (JAD).
Collaboration : orang-orang yang bermotivasi tinggi bekerja sama: saling
melengkapi, rela membantu, kerja keras, trampil di bidangnya, dan komunikasikan
masalah untuk hasilkan penyelesaian yang efektif.
Pada
tahap Learning, terdapat tiga aktifitas yaitu: pelanggan atau end-user
menyediakan feedback terhadap hasil incremental delivery, tim ASD melakukan
review terhadap komponen perangkat lunak untuk memperbaiki dan meningkatkan
kualitas perangkat lunak yang sedang dibuat. Learning: tim pembangun sering
merasa sudah tahu semua hal tentang proyek,
padahal
tidak selamanya begitu. Karena itu proses ini membuat mereka belajar lebih
tentang proyek melalui 3 cara:
·
Focus
group: klien dan pengguna memberi masukan terhadap software
·
Formal
Technique Reviews: Tim ASD lengkap melakukan review
·
Postmortems:
Tim ASD lakukan instrospeksi pada kinerja dan proses
B.
Definisi DSDM
DSDM adalah suatu kerangka kerja
awalnyadidasarkan pada Rapid Application Development (RAD). DSDM mengutamakan
keterlibatan pemakai secara berkesinambungan dengan pendekatan pengembangan
secara berulang dan bertambah, tanggap terhadap perubahan,untuk membangun
sistem perangkat lunak yang memenuhi kebutuhan bisnis tepat waktu dan tepat
anggaran. DSDM merupakan salah satu metode Agile untuk pengembangan perangkat
lunak, dan bagian dari Agile Alliance. DSDM pertama kali diperkenalkan pada
tahun 1995, di mana merupakan satusatunya publikasi penggunaan metode RAD di
dunia.
Sebagai perluasan dari RAD, DSDM memusatkan
pada proyek sistem informasi yang dicirikan oleh jadwal dan anggaran yang
ketat. DSDM berupaya mengatasi penyebab-penyebab kegagalan proyek, di antaranya
melebihi anggaran, terlambat dari jadwal, kurangnya keterlibatan pengguna, dan
lemahnya komitmen dari para pimpinan. Kerangka kerja DSDM menyediakan dasar
ideal bagi proses pengembangan dan penerapan sistem informasi, meliputi orang
(misal organisasi, staf, keahlian), teknologi pendukung (misal teknologi
informasi, otomatisasi kantor, komunikasi) dan proses yang menyatukan keduanya
(dalam rangkaian strategi bisnis).
DSDM terdiri dari 3 tahapan utama, dan 5 sub tahap. Tahapan utama
adalah:
1. Sebelum proyek, di mana kandidat proyek diidentifikasi, pembiayaan
proyek terpenuhi, dan jaminan proyek dipastikan. Penanganan hal- hal tersebut
pada tahap ini menghindari masalah pada tahaptahap berikutnya.
2. Siklus hidup proyek, merupakan inti dari DSDM, yang terdiri dari 5 sub tahap
yaitu i) studi kelayakan; ii) studi bisnis; iii) perulangan model fungsional;
iv) perulangan perancangan dan pembuatan; v) penerapan.
3. Setelah proyek, yaitu memastikan sistem berjalan secara efektif dan
efisien. Hal ini diwujudkan dengan perawatan, peningkatan dan perbaikan sesuai
prinsip-prinsip DSDM. Perawatan dapat dilihat sebagai usaha meneruskan
pengembangan berdasarkan sifat alami DSDM, yaitu perulangan dan pertambahan.
Prinsip
Ada delapan prinsip yang mendasari DSDM
Atern. Prinsip-prinsip ini mengarahkan tim dalam sikap mereka harus mengambil
dan pola pikir mereka harus mengadopsi untuk memberikan secara konsisten.
1) Fokus pada kebutuhan bisnis
Kriteria
utama untuk penerimaan dari "penyampaian" adalah memberikan suatu
sistem yang membahas kebutuhan bisnis saat ini. Menyampaikan sistem yang
sempurna yang membahas semua kebutuhan bisnis yang mungkin kurang penting
daripada berfokus pada fungsi kritis.
·
Memahami
prioritas bisnis sejati
·
Membentuk
Kasus Bisnis suara
·
Mencari
sponsor bisnis yang berkesinambungan dan komitmen
·
Jaminan
Subset Usable Minimum fitur.
2) Memberikan tepat waktu
·
Timebox
pekerjaan
·
Fokus
pada prioritas bisnis
·
Selalu
memenuhi tenggat waktu
3) Berkolaborasi
Keterlibatan
pengguna merupakan kunci utama dalam menjalankan proyek yang efisien dan
efektif, dimana kedua pengguna dan pengembang berbagi tempat kerja (baik fisik
atau melalui alat), sehingga pengambilan keputusan dapat dilakukan secara
kolaboratif dan cepat.
·
Melibatkan pemangku kepentingan yang tepat,
pada waktu yang tepat, seluruh proyek
·
Pastikan bahwa anggota tim diberi wewenang
untuk mengambil keputusan atas nama rakyat yang mereka wakili tanpa menunggu
persetujuan tingkat yang lebih tinggi.
·
Aktif melibatkan perwakilan bisnis
·
Membangun budaya satu tim
4) Jangan kompromi soal kualitas
·
Mengatur tingkat kualitas di awal
·
Memastikan kualitas yang tidak menjadi variable
·
Desain, dokumen dan uji tepat
·
Membangun kualitas dengan review konstan
·
Uji awal dan terus menerus
5) Membangun secara bertahap
·
Upayakan untuk pengiriman awal manfaat bisnis
di mana mungkin
·
Terus mengkonfirmasi solusi yang tepat sedang
dibangun
·
Secara formal menilai kembali prioritas dan
kelayakan proyek yang sedang berlangsung dengan kenaikan masing-masing
disampaikan
6) Mengembangkan Iterasi
Fokus
pada penyajian produk sesering mungkin, dengan asumsi bahwa untuk memberikan
sesuatu yang "cukup baik" sebelumnya selalu lebih baik daripada
memberikan segalanya "sempurna" pada akhirnya. Dengan memberikan
produk sering dari tahap awal dari proyek, produk dapat diuji dan ditinjau di
mana catatan uji dan dokumen review dapat diperhitungkan pada iterasi
berikutnya atau fase.
·
Jangan cukup desain depan untuk menciptakan
fondasi yang kuat
·
Mengambil pendekatan iteratif untuk membangun
semua produk
·
Membangun umpan balik pelanggan dalam setiap
iterasi untuk fokus pada solusi bisnis yang efektif
·
Terimalah bahwa detail yang paling muncul
kemudian daripada cepat
·
Merangkul berubah - solusi yang tepat tidak
akan berkembang tanpa itu
·
Jadilah kreatif, bereksperimen, belajar,
berevolusi
7) Berkomunikasi terus menerus dan jelas
Komunikasi
dan kerja sama di antara semua stakeholder proyek diperlukan untuk menjadi
efisien dan efektif.
·
Jalankan
tim setiap hari
·
Gunakan
lokakarya
·
Gunakan
teknik komunikasi yang kaya seperti pemodelan dan prototyping
·
Iterasi
kini berkembang solusi awal dan sering
·
Menjaga
dokumentasi ramping dan tepat waktu
·
Mengelola
harapan pemangku kepentingan seluruh proyek
·
Mendorong
informal komunikasi tatap muka di semua tingkatan
8) Menunjukkan kontrol.
·
Gunakan tingkat yang sesuai formalitas untuk
pelacakan dan pelaporan
·
Buatlah rencana dan kemajuan terlihat oleh
semua
·
Mengukur kemajuan melalui fokus pada
pengiriman produk daripada kegiatan selesai
·
Mengelola secara proaktif
·
Evaluasi kelayakan proyek terus berdasarkan
tujuan bisnis
Gambar 1. Siklus
hidup DSDM.
C.
Definisi
scrum
Scrum merupakan framework
untuk manajemen pengembangan software dengan karakteristik cekatan dan bersifat
iteratif dan incremental. Scrum mendefinisikan dirinya fleksible, strategi
pengembangan yang menyeluruh di mana seluruh team bekerja sebagai satu unit
dalam mencapai sebuah gol yang sama.
Dalam
menjalankan kerjasama antara anggota team, scrum menekankan lokasi fisik yang
sama atau sarana online yang akrab antara semua member, dan juga pertemuan muka
dengan muka setiap hari antara semua anggota team.
Prinsip
kunci dari scrum adalah memahami bahwa dalam project yang tengah berlangsung,
klien mungkin mengubah apa yang menjadi kebutuhan dan keinginannya. Perubahan
sulit diadaptasi oleh framework pengembangan aplikasi yang bersifat
tradisional. Scrum menerima perubahan ini dan memaksimalkan seluruh
anggota team untuk menyesuaikan perubahan mendadak ini.
Scrum
mengadopsi permainan Rugby yang begitu mudah menyesuaikan diri semua anggota
team setelah ada sedikit pelanggaran. Kemudian menyesuaikan diri inilah yang
mengimpirasi scrum.
Scrum mempunyai 3 Role
1. Product Owner
Pengertian produk adalah tujuan dari proyek. Product Owner memastikan bahwa proyek berjalan sesuai yang diharapkan. Product Owner merupakan penjembatan antara client dengan team development. Product Owner akan menuliskan spesifikasi-spesifikasi sesuai cara pandang client, di lain pihak harus punya empati terhadap anggota team.
Pengertian produk adalah tujuan dari proyek. Product Owner memastikan bahwa proyek berjalan sesuai yang diharapkan. Product Owner merupakan penjembatan antara client dengan team development. Product Owner akan menuliskan spesifikasi-spesifikasi sesuai cara pandang client, di lain pihak harus punya empati terhadap anggota team.
2. Team Member
Dilihat dari namanya jelas yaitu anggota-anggota team.
Dilihat dari namanya jelas yaitu anggota-anggota team.
3. Scrum Master
Scrum Master akan mencegah hal-hal yang mengalihkan focus team. Scrum master akan membuat suasana kondusif supaya team dapat bekerja sama dalam mencapai goal.
Scrum Master akan mencegah hal-hal yang mengalihkan focus team. Scrum master akan membuat suasana kondusif supaya team dapat bekerja sama dalam mencapai goal.
Event
penting dalam Scrum adalah sprint/iteration. Sprint merupakan unit dasar dalam
development dengan Scrum. Sprint merupakan jangka waktu yang dibatasi pada
suatu durasi 1 minggu, 2 minggu atau 1 bulan. Setiap sprint dimulai dengan
planning meeting dan diakhiri dengan sprint review dan retrospective meeting.
Proses
penting dalam Scrum antara lain:
1. Backlog refinement
2. Sprint planning
3. Daily Scrum
4. Sprint review meeting
5. Sprint retrospective meeting
D.
Crystal
Crystal
diperkenalkan oleh Cockburn dan Highsmith, Development yang tidak pada
jalur kritis, dapat menghabikan waktu lebih, mereka yang memperbaiki
produk atau membantuoaring yang ada di jalur proyek kritis.Karakteristik
Crystal :
Secara aktual sebuah model proses keluarga yang memungkinkan
manuver berdasar karakteristik permasalahan2.
1.
Menyarankan penggunaan workshop
refleksi untuk review kebiasaan kerja tim3.
2.
Selalu murah dan cepat berkomunikasi
secara langsung.4.
3.
Proyek berkembang sesuai ukuran team
menjadi lebih atau luas dan metologi akanmenjadi lebih tinggi.
E.
Feature
driven development (Fdd)
Fitur-driven
development (FDD) adalah iteratif dan proses pengembangan perangkat lunak
tambahan. Ini adalah salah satu dari sejumlah metode Agile untuk mengembangkan
perangkat lunak dan bagian bentuk dari Aliansi Agile. FDD memadukan sejumlah
industri-praktek terbaik yang diakui menjadi satu kesatuan yang kohesif.
Praktek-praktek semua didorong dari klien-nilai perspektif (fitur) fungsi.
Tujuan utamanya adalah untuk memberikan nyata, software yang bekerja
berulang-ulang pada waktu yang tepat.
Sejarah
FDD
awalnya dirancang oleh Jeff De Luca, untuk memenuhi kebutuhan spesifik dari
satu bulan 15-, 50-orang proyek pengembangan perangkat lunak pada sebuah bank
besar di Singapura 1997. Jeff De Luca menyampaikan satu set lima proses yang
menutupi pengembangan model secara keseluruhan dan daftar, perencanaan, desain
dan bangunan fitur. Proses pertama sangat dipengaruhi oleh pendekatan Peter
Coad untuk pemodelan obyek. Proses kedua menggabungkan ide-ide Peter Coad
tentang menggunakan daftar fitur untuk mengelola kebutuhan fungsional dan
tugas-tugas pembangunan. Proses lainnya dan campuran proses menjadi suatu
kesatuan kohesif merupakan hasil dari pengalaman Jeff De Luca. Sejak penggunaan
sukses pada proyek Singapura, ada beberapa implementasi dari FDD.
Gambaran
FDD pertama kali diperkenalkan kepada dunia dalam Bab 6 dari buku Modeling Jawa
Warna dengan UML oleh Peter Coad, Lefebvre Eric dan Jeff De Luca pada tahun
1999. Kemudian, di Stephen Palmer dan buku Mac Felsing A Panduan Praktis untuk
Pengembangan Fitur-Driven (diterbitkan pada 2002), deskripsi yang lebih umum
FDD diberikan, seperti yang dipisahkan dari pemodelan Jawa dalam warna.
FDD
asli dan terbaru proses dapat ditemukan di situs web Jeff De Luca di bawah
wilayah 'Pasal'. Ada juga web komunitas yang tersedia di mana orang dapat
mempelajari lebih lanjut tentang FDD, pertanyaan bisa ditanyakan, dan
pengalaman, dan proses itu sendiri dibahas.
Karakteristik
penggunaan
FDD sebaiknya digunakan jika; memekerjakan 10 – 250 developer yang memiliki
kemampuan teknis lebih dari rata-rata, dan jangan digunakan jika; jumlah
tim kurang dari 10, tim sedang belajar menguasai pekerjaan dan jika kurang dukungan
dari sistem. FDD lebih terhirarki daripada Extreme Programming, memiliki class
owenership yang terpisah-pisah, sukses jika dalam rentang jumlah developer
diatas rata-rata, klien tidak dilibatkan dalam seluruh urutan proses (hanya
dalam proses 1, 2 dan 4) dan menghargai developer sebagai individu manusia yang
menentukan sukses atau tidaknya pengembangan.
Kelebihan
·
User
dapat menggambarkan dengan mudah bentuk system.
·
Dapat
di organisasikan atau diatur ke dallamkelompok bisnis yang hirarki.
·
Desain
dank ode lebih mudah diperiksa secara efektif.
·
Merancang
proyek, penjadwalan dan jalur diarahkan oleh feature.
F.
Agile
modeling
Agile pengembangan software adalah sekelompok metodologi
pengembangan software yang didasarkan pada prinsip-prinsip yang sama. Agile
metodologi umumnya mempromosikan proyek yang mendorong proses pengelolaan
sering inspeksi dan adaptasi, sebuah filosofi yang mendorong kepemimpinan tim,
mandiri dan akuntabilitas organisasi, satu set teknik praktek terbaik yang memungkinkan
untuk pengiriman cepat dari perangkat lunak yang berkualitas tinggi, dan usaha
pendekatan yang aligns pembangunan dengan kebutuhan pelanggan dan tujuan
perusahaan. Konseptual kerangka dasar-dasar ini akan ditemukan di modern
pendekatan manajemen operasional dan analisis seperti bersandar manufaktur,
lunak sistem metodologi, pidato bertindak teori (pendekatan percakapan
jaringan), dan Six Sigma.
Sejarah
Modern definisi Agile
pengembangan software berkembang pada pertengahan tahun 1990-an sebagai bagian
dari reaksi terhadap "berat" metode, dikatakan oleh seorang typified
berat diatur, regimented, Mikro dikelola menggunakan waterfall model pembangunan.
Proses ini berasal dari air terjun menggunakan model yang dianggap sebagai
birokrasi, lambat, demeaning, dan tidak konsisten dengan cara yang sebenarnya
pengembang perangkat lunak melakukan kerja efektif. Kasus dapat dibuat yang
Agile dan pengembangan metode yg berulang adalah pembangunan kembali ke praktek
mulai awal dalam sejarah pengembangan piranti lunak. Pada mulanya, Agile metode
yang disebut "metode ringan." Pada tahun 2001, anggota tokoh
masyarakat bertemu di Snowbird, Utah, dan mengadopsi nama "metode
Agile." Nantinya, sebagian dari orang-orang yang membentuk Aliansi Agile,
sebuah organisasi nirlaba yang mempromosikan pembangunan Agile. Suatu proses pengembangan
software adaptif diperkenalkan dalam karya oleh Edmon ds (1974). terkemuka awal Agile metode mencakup banyak (1995),
Crystal Clear, Extreme Programming (1996), adaptive Software Development, Fitur
Terutama Pembangunan dan Pengembangan Sistem Dinamis Metode (DSDM) (1995). Ini
biasanya disebut sebagai metodologi Agile sejak Agile Manifesto telah
diterbitkan pada tahun 2001.
Metodologi
Analisis Proyek : Menganalisis proyek sistem yang ingin
dikembangakan
Pengembangan Proyek : Proses pengembangan sistem
dilakukan
Testing
Proyek : Mencoba sistem yang sudah selesai sebelum diberikan kepada client
Apabila sistem lulus test dan tidak ada perubahan-perubahan, maka sistem
tersebut sudah bisa digunakan oleh client. Sementara apabila masih terjadi
perubahan-perubahan maka kembali lagi ke proses awal.
Kelebihan dan Kekurangan
Kelebihan dari Agile Modeling:
1. Meningkatkan kepuasan kepada klien
2. Pembangunan system dibuat lebih cepat
3.
Mengurangi resiko kegagalan implementasi software dari segi non-teknis
4.
Jika pada saat pembangunan system terjadi kegagalan,kerugian dar segi materi
relative kecil.
Kelemahan dari Agile
Modeling:
Developer harus
selalu siap dengan perubahan karena perubahan akan selalu diterima.
Contoh Penerapan dalam Kehidupan
Metode Agile telah banyak digunakan untuk pengembangan
produk perangkat lunak dan beberapa dari mereka menggunakan karakteristik
tertentu dari perangkat lunak, seperti teknologi objek. Namun, teknik ini dapat
diterapkan untuk pengembangan produk non-software, seperti komputer, motorik
kendaraan, peralatan medis, makanan, dan pakaian, lihat pengembangan produk
Fleksibel .
Siklus
Hidup
Metode tangkas difokuskan
pada aspek yang berbeda dari siklus hidup pengembangan perangkat lunak.
Beberapa fokus pada praktek (pemrograman ekstrim, pemrograman pragmatis,
pemodelan tangkas), sementara yang lain fokus pada pengelolaan proyek perangkat
lunak (pendekatan scrum). Namun, ada pendekatan menyediakan cakupan penuh atas
siklus hidup pengembangan (metode pengembangan sistem dinamis, atau DSDM, dan
IBM Rational Unified Process, atau RUP), sementara sebagian besar dari mereka
yang cocok dari persyaratan spesifikasi fasa pada (pengembangan fitur -driven,
atau FDD, misalnya). Dengan demikian, ada perbedaan yang jelas antara berbagai
metode pengembangan perangkat lunak tangkas dalam hal ini. Sedangkan DSDM dan
RUP tidak perlu melengkapi pendekatan untuk mendukung pengembangan perangkat
lunak , yang lain lakukan untuk tingkat tertentu. DSDM dapat digunakan oleh
siapa saja (meskipun hanya anggota DSDM dapat menawarkan produk atau jasa
DSDM). RUP, maka, merupakan lingkungan pengembangan dijual secara komersial
(Abrahamsson, Salo, Rankainen, & Warsta, 2002).
G.
lean
software development
Sekarang,
mari kita lihat bagaimana kita dapat mengadopsi prinsip-prinsip Lean dalam
pengembangan software dan prinsip ini dapat disatukan pada saat kita menjalan
proyek IT menggunakan Scrum. Kita dapat meng-ilustrasi-kan proyek yang
diajalankan dengan cara Scrum adalah membagi proyek yang besar menjadi beberapa
bagian dan setiap bagian akan menghasilkan incremental product.
Kita mengenal konsep yang namanya "sprint",
katakanlah tim Scrum ini menetapkan setiap sprint adalah 3 minggu. Maka tim ini
akan menetapkan sub-produk apa saja yang akan dihasilkan dari sprint pertama
sampe sprint terakhir dimana setiap sprint akan berjalan 3 minggu. Selama 3
minggu (1 sprint), mereka akan fokus dengan satu added value atau "running
version software". Kemudian, mereka akan fokus kepada potongan running
version berikutnya dan dikerjakan dalam waktu yang sama (sprint kedua) dan
begitu seterusnya.
Tentu saja, prinsip-prinsip Lean dapat disinergikan dengan
pelaksaan pengembangan proyek menggunakan Scrum.
a. Menghilangkan aktifitas yang tidak berkaitan langsung dengan End Product
Fokuskan waktu dan tenaga serta diskusi kita dengan spesifik added value yang kita harapkan sebagai sebuah End Product. Software atau aplikasi yang kita kembangkan harus berdasarkan keinginan client. Imajinasi atau ide sesaat yang muncul pada saat pembuatan program, cukup menjadi catatan terlebih dahulu dan nantinya akan menjadi bahan untuk pengembangan selanjutnya. Kita tidak terlalu perlu untuk berlama-lama dengan ide-ide baru yang tiba-tiba datang. Fokus dengan apa yang diinginkan client saat ini dan diskusikan nanti ide-ide baru setelah bagian ini selesai.
b. Melakukan pembelajaran secara berkelanjutan
Pada saat pengembangan berlangsung, kita dapat selalu melibatkan user atau klien untuk mencoba atau mereview atau pengecek apakah progress pengembangan dan memberikan kesempatan kepada mereka untuk menyampaikan feedback. Sedapat mungkin kita sudah melibatkan user dari awal selain sebagai sarana untuk mendapatkan early feedback, juga dapat dijadikan wahana untuk proses pembelajaran guna pengembangan yang berkelanjutan.
a. Menghilangkan aktifitas yang tidak berkaitan langsung dengan End Product
Fokuskan waktu dan tenaga serta diskusi kita dengan spesifik added value yang kita harapkan sebagai sebuah End Product. Software atau aplikasi yang kita kembangkan harus berdasarkan keinginan client. Imajinasi atau ide sesaat yang muncul pada saat pembuatan program, cukup menjadi catatan terlebih dahulu dan nantinya akan menjadi bahan untuk pengembangan selanjutnya. Kita tidak terlalu perlu untuk berlama-lama dengan ide-ide baru yang tiba-tiba datang. Fokus dengan apa yang diinginkan client saat ini dan diskusikan nanti ide-ide baru setelah bagian ini selesai.
b. Melakukan pembelajaran secara berkelanjutan
Pada saat pengembangan berlangsung, kita dapat selalu melibatkan user atau klien untuk mencoba atau mereview atau pengecek apakah progress pengembangan dan memberikan kesempatan kepada mereka untuk menyampaikan feedback. Sedapat mungkin kita sudah melibatkan user dari awal selain sebagai sarana untuk mendapatkan early feedback, juga dapat dijadikan wahana untuk proses pembelajaran guna pengembangan yang berkelanjutan.
c. Menunda sesuatu sampai memang dibutuhkan
Pada saat program/software sedang dibuat, begitu banyak ide yang tiba-tiba datang dan mengalir begitu deras. Dalam prinsip Lean, sebaiknya kita menunda untuk mengimplementasikan sesuatu yang bukan menjadi tujuan utama saat ini. Kita harus fokus untuk memenuhi added value yang sangat ini telah ditunggu oleh klien kita, karena bisa jadi, jika kita terlambat sedikit saja, kerugian besar terhadap peluang bisnis menjadi hilang. Yang kedua, apa yang kita inginkan atau kita pikirkan adalah sesuatu yang belum tentu benar-benar dibutuhkan klien kita saat ini.
d. Deliver Software as fast as possible
Klien kita adalah pihak yang berperang dengan waktu karena
kesempatan memiliki parameter waktu. Suatu kesempatan bisnis akan menjadi
hilang dan effort yang kita keluarkan menjadi tidak bermakna jika kita
terlambat mengantisipasinya. Untuk itu, Lean menekankan untuk fokus kepada
kebutuhan klien "saat ini". Secepatnya selesaikan modul utama yang
dibutuhkan, untuk kemudian dapat dikembangkan sebagai proses belajar yang
berkelanjutan.
e. Empower Programming Team
Berikan para programmer kesempatan untuk juga mengakses informasi dan libatkan mereka mulai dari awal sampai akhir. Akan banyak hal yang dapat didefiniskan secara bersama mengenai End-Product jika programmer diberikan kesempatan untuk juga meng-akses semua informasi yang ada serta dilibatkan.
e. Empower Programming Team
Berikan para programmer kesempatan untuk juga mengakses informasi dan libatkan mereka mulai dari awal sampai akhir. Akan banyak hal yang dapat didefiniskan secara bersama mengenai End-Product jika programmer diberikan kesempatan untuk juga meng-akses semua informasi yang ada serta dilibatkan.
Selama proses pngembangan, kita cukup berdiskusi dengan
programmer mengenai timeline secara bersama. Pada saat timeline itu disepakati,
maka berikan mereka power dan otoritas untuk memutuskan bagaimana dia membuat
program, selama itu berfokus kepada end-product dan memenuhi target timeline.
f. Pengujian sistem atau testing terintegrasi selama proses development
Selama proses pengembangan, Lean mngharapkan kita untuk selalu dapat melakukan testing dan sesi customer/client feedback, yang sebisa mungkin dilakukan secara reguler sebagai bagian yang terintegrasi selama proses pengembangan (dari awal sampai akhir). Lean tidak mengharapkan bahwa pegujian sistem hanya akan dilakukan diakhir proses, melainkan sebagai aktifitas yang reguler dan tidak hanya dilakukan diakhir proses sehingga kesalahan asumsi dapat dideteksi lebih awal.
f. Pengujian sistem atau testing terintegrasi selama proses development
Selama proses pengembangan, Lean mngharapkan kita untuk selalu dapat melakukan testing dan sesi customer/client feedback, yang sebisa mungkin dilakukan secara reguler sebagai bagian yang terintegrasi selama proses pengembangan (dari awal sampai akhir). Lean tidak mengharapkan bahwa pegujian sistem hanya akan dilakukan diakhir proses, melainkan sebagai aktifitas yang reguler dan tidak hanya dilakukan diakhir proses sehingga kesalahan asumsi dapat dideteksi lebih awal.
g. Focus kepada system secara penyeluruh
Ongoing testing tidak hanya dilakukan di level unit testing, Lean mengharapkan aktifitas ongoing testing (yang dilakukan sebagai bagian dari proses development) juga mencakup system level. Dan aktifitas ini diharapkan sebagai sebuah kolaborasi antar tim untuk melihat kemungkinan adanya defect lebih
H.
Agile
Unifed Process
Unified
Process (UP) merupakan suatu metode pembangunan sistem secara objek oriented
yang dikembangkan oleh Rational Rose, bagian dari IBM. Secara luas, UP
telah diakui sebagai standar metodologi pengembangan sistem berorientasi objek.
Vesri alsi dari UP didefinisikan sangat rumit untuk setiap kegiatan. Namun
versi terbaru dari UP yakni metodologinya lebih sederhana. Ciri utama metode
ini adalah menggunakan use-case driven dan pendekatan iteratif untuk
siklus pengembangan perangkat lunak.
UP tepat digunakan saat kondisi:
·
Pengembangan perangkat lunak yang
berorientasi objek dengan berfokus pada UML (Unified Modeling
Language )
·
Mempunyai waktu pengembangan yang
panjang
·
Dikembangkan pada perangkat lunak
sebagai sarana interaksi antara pengguna dan perangkat keras
·
Mempunyai tim programmer yang
cukup banyak
·
Pengembangan dan perubahan perangkat
lunak berdasarkan kebutuhan user
Keuntungan Pengembangan Perangkat Lunak RUP :
Ada beberapa keuntungan dengan mengunakan RUP di antaranya :
1.
Menyediakan akses yang mudah
terhadap pengetahuan dasar bagi anggota tim.
2.
Menyediakan petunjuk bagaimana
menggunakan UML secara efektif.
3.
Mendukung proses pengulangan dalam
pengembangan software.
4.
Memungkinkan adanya
penambahan-penambahan pada proses.
5.
Memungkinkan untuk secara sistematis
mengontrol perubahan- perubahan yang terjadi pada software selama proses
pengembangannya.
6.
Memungkinkan untuk menjalankan test
case dengan menggunakan Rational Test Manager Tool
Kekurangan Pengembangan Perangkat Lunak RUP :
·
Metodologi ini hanya dapat digunakan
pada pengembangan perangkat lunak yang berorientasi objek dengan berfokus pada
UML (Unified Modeling Language).
·
Membutuhkan waktu yang cukup lama
dibandingkan XP dan Scrum
Referensi
http://www.proweb.co.id/articles/erp/pengertian_scrum.html
http://kamarujung.blogspot.com/2013/04/pengertian-fdd.html
http://fannynurrizky06.blogspot.com/2013/11/agile-software-development.html
http://ekokusuma.blogspot.com/2015_01_01_archive.html
http://en.wikipedia.org/wiki/Dynamic_systems_development_method
Tidak ada komentar:
Posting Komentar