Sejarah pengembangan perangkat lunak telah dicatat dengan banyak deskripsi dan metodologi proses yang telah usang, alat-alat, dan teknologi, serta notasi pemodelan. Semua hal tersebut telah mencapai popularitasnya masing-masing sebelum akhirnya digantikan oleh yang baru dan lebih baik. Dalam upaya mencapai penerimaan di komunitas pengembangan perangkat lunak, berbagai agile process model telah diperkenalkan dan bersaing satu sama lain, mengikuti pola yang sama dengan gerakan sebelumnya.
Sudah saya sampaikan pada bagian terakhir bahwa Extreme Programming (XP) merupakan agile process models yang paling sering digunakan. Meskipun demikian, terdapat banyak agile process models lain yang telah diusulkan dan diterapkan dalam berbagai industri. Beberapa model yang paling umum meliputi:
- Adaptive Software Development (ASD)
- Scrum
- Dynamic Systems Development Method (DSDM)
- Crystal
- Feature Drive Development (FDD)
- Lean Software Development (LSD)
- Agile Modeling (AM)
- Agile Unified Process (AUP)
Pada bagian berikutnya, akan disajikan ringkasan dari setiap agile process model yang telah disebutkan sebelumnya. Perlu ditegaskan bahwa semua model tersebut sejalan (meskipun dalam tingkat yang berbeda-beda) dengan Manifesto untuk Pengembangan Perangkat Lunak Agile dan prinsip-prinsip. Referensi tambahan dapat ditemukan di setiap subbagian, atau untuk gambaran umum, bisa dilihat di entri "agile software development" di Wikipedia.
1.1 Adaptive Software Development (ASD)
Jim Highsmith mengusulkan Adaptive Software Development (ASD) sebagai sebuah metode untuk mengembangkan perangkat lunak dan sistem yang kompleks. Prinsip filosofis ASD terfokus pada kerja sama antara anggota tim dan kemampuan tim untuk mengatur diri mereka sendiri.
Menurut Highsmith, sebuah pendekatan pengembangan yang adaptif dan tangkas dengan dasar kolaborasi adalah "sumber keteraturan dalam interaksi kita yang kompleks sebanyak disiplin dan teknik". Ia juga memperkenalkan "siklus hidup" ASD (lihat Gambar 1.1) yang terdiri dari tiga fase, yaitu spekulasi, kolaborasi, dan pembelajaran.
Pada fase spekulasi, proyek dimulai dan dilakukan perencanaan siklus adaptif. Dalam perencanaan siklus adaptif, informasi dari inisiasi proyek digunakan, termasuk pernyataan misi pelanggan, kendala proyek (seperti tanggal pengiriman atau deskripsi pengguna), dan persyaratan dasar, untuk menentukan serangkaian siklus rilis (peningkatan perangkat lunak) yang akan dibutuhkan untuk proyek tersebut.
Meskipun rencana siklus telah dirancang dengan matang dan pandangan jauh ke depan, namun rencana tersebut akan selalu mengalami perubahan. Setelah menyelesaikan siklus pertama, tim akan meninjau dan menyesuaikan rencana tersebut berdasarkan informasi yang telah diperoleh, sehingga pekerjaan yang dilakukan menjadi lebih sesuai dengan situasi yang dihadapi oleh tim ASD.
Kolaborasi menjadi kunci keberhasilan dalam metode agile software development. Dalam pendekatan ini, individu yang termotivasi bekerja sama secara kreatif dan menggandakan bakat mereka melebihi hasil kerja individual mereka. Namun, kolaborasi tidaklah mudah karena melibatkan komunikasi, kerja tim, dan juga menekankan pada kebebasan individu. Kepercayaan antar individu menjadi masalah utama dalam kolaborasi. Untuk menjaga kepercayaan, individu yang bekerja sama harus saling mengkritik tanpa merasa tersinggung, membantu tanpa dendam, bekerja dengan keras, memberikan kontribusi, dan mengomunikasikan masalah atau kekhawatiran secara efektif agar tindakan dapat diambil.
Ketika anggota tim ASD memulai pengembangan komponen yang merupakan bagian dari siklus adaptif, penting untuk fokus pada pembelajaran sebanyak pada kemajuan menuju siklus yang lengkap. Menurut Highsmith, pengembang perangkat lunak sering kali memiliki pemahaman yang berlebihan tentang teknologi, proses, dan proyek mereka, dan pembelajaran akan membantu meningkatkan pemahaman mereka yang sebenarnya. Tim ASD dapat belajar melalui tiga cara: focus groups, technical reviews, dan project postmortems.
Meskipun berbeda dalam model proses yang digunakan, filosofi ASD dapat memberikan manfaat. Pemikiran ASD yang menitikberatkan pada kolaborasi antar-individu, dinamika tim yang otonom, dan pembelajaran individu dan tim, dapat menghasilkan tim proyek perangkat lunak yang memiliki potensi keberhasilan yang lebih besar.
1.2 Scrum
Scrum, sebuah metode agile software development, diperkenalkan pada awal 1990-an oleh Jeff Sutherland dan timnya. Nama Scrum diambil dari sebuah aktivitas yang terjadi selama pertandingan rugby. Metode ini telah dikembangkan lebih lanjut oleh Schwaber dan Beedle dalam beberapa tahun terakhir.
Prinsip-prinsip Scrum sejalan dengan manifesto agile dan membimbing aktivitas pengembangan melalui serangkaian kerangka kerja, termasuk persyaratan, analisis, desain, evolusi, dan pengiriman. Setiap aktivitas kerangka kerja ini dilakukan dalam pola proses yang disebut sprint, di mana pekerjaan yang dilakukan selama sprint disesuaikan dengan masalah yang ada dan sering dimodifikasi oleh tim Scrum. Jumlah sprint yang diperlukan untuk setiap aktivitas kerangka kerja bervariasi tergantung pada kompleksitas dan ukuran produk. Secara keseluruhan, alur proses Scrum dijelaskan dalam Gambar 1.2.
Scrum mendorong penggunaan pola proses perangkat lunak yang telah terbukti berhasil untuk proyek-proyek yang memiliki batas waktu yang ketat, persyaratan yang berubah-ubah, dan kepentingan bisnis yang kritis. Setiap pola proses ini mengatur serangkaian tindakan pengembangan yang harus dilakukan.
Backlog - Proses Scrum dimulai dengan membuat daftar kebutuhan atau fitur proyek yang diurutkan berdasarkan nilai bisnis yang dihadirkan untuk pelanggan. Daftar ini, yang disebut sebagai backlog, dapat diperbarui kapan saja oleh tim proyek. Manajer produk bertanggung jawab untuk meninjau dan mengatur kembali prioritas backlog sesuai kebutuhan.
Sprints - Satu unit kerja yang diperlukan untuk mencapai kebutuhan yang ditentukan dalam backlog, dibatasi dengan waktu tertentu (umumnya 30 hari) disebut sprint. Dalam sprint, tidak diperbolehkan ada perubahan seperti penambahan item pekerjaan dalam backlog. Oleh karena itu, sprint memberikan lingkungan kerja yang stabil bagi anggota tim untuk bekerja dalam jangka pendek.
Scrum meetings - Rapat harian Scrum adalah pertemuan singkat yang dilakukan setiap hari oleh tim Scrum dengan durasi sekitar 15 menit. Saat rapat harian, semua anggota tim menjawab tiga pertanyaan kunci yang membantu dalam mengatur dan mengkoordinasi pekerjaan mereka secara efektif:
- Bagaimana perkembangan Anda sejak pertemuan tim sebelumnya?
- Bagaimana dengan hambatan yang telah Anda alami?
- Apa yang menjadi rencana Anda untuk pertemuan tim selanjutnya?
Dalam Scrum, setiap hari diadakan rapat singkat yang dipimpin oleh Scrum master yang mengevaluasi tanggapan dari setiap anggota tim. Tujuannya adalah untuk mengungkapkan masalah yang mungkin timbul secepat mungkin dan juga untuk memfasilitasi berbagi pengetahuan di antara anggota tim, sehingga mendorong pembentukan struktur tim yang mandiri.
Demos - Dalam proses Scrum, demo digunakan untuk menunjukkan kemajuan proyek kepada pelanggan dan memungkinkan evaluasi terhadap fungsionalitas yang telah diimplementasikan. Walaupun demo hanya menampilkan sebagian dari fungsionalitas yang direncanakan, demo tetap penting untuk dilakukan karena hanya fungsi-fungsi tertentu yang dapat dikirimkan dalam jangka waktu yang telah ditentukan.
Beedle dan kawan-kawannya membahas secara rinci pola-pola tersebut di mana mereka menyatakan: "Scrum mengasumsikan bahwa ketidakpastian terjadi di depan. . . ." Pola proses Scrum memberikan kesempatan pada tim pengembang perangkat lunak untuk bekerja secara efektif dalam lingkungan yang tidak mungkin dihilangkan ketidakpastiannya.
1.3 Dynamic Systems Development Method (DSDM)
DSDM (Dynamic System Development Method) adalah suatu pendekatan pengembangan perangkat lunak yang fleksibel yang "menyediakan kerangka kerja bagi pembangunan dan pemeliharaan sistem yang memenuhi batas waktu yang ketat dengan menggunakan prototyping secara bertahap di dalam lingkungan proyek yang terkendali". Pendekatan DSDM didasarkan pada konsep modifikasi prinsip Pareto di mana 80% dari fitur aplikasi dapat dikembangkan dalam 20% dari waktu yang dibutuhkan untuk mengembangkan seluruh aplikasi (100%).
DSDM merupakan metode pengembangan perangkat lunak yang menggunakan pendekatan iteratif di mana setiap iterasinya mengikuti aturan 80 persen. Aturan ini berarti bahwa setiap peningkatan hanya membutuhkan jumlah pekerjaan yang cukup untuk memfasilitasi peralihan ke peningkatan berikutnya. Detail yang masih belum selesai dapat diselesaikan nanti ketika lebih banyak persyaratan bisnis diketahui atau perubahan telah diminta dan diterima. Dengan demikian, DSDM memberikan kerangka kerja untuk membangun dan memelihara sistem dengan kendala waktu yang ketat melalui penggunaan prototyping inkremental di lingkungan proyek yang terkendali.
Sebuah konsorsium perusahaan anggota global yang dikenal sebagai DSDM (www.dsdm.org) bertindak sebagai pengawas metode pengembangan perangkat lunak tangkas ini. Agile process model, disebut siklus hidup DSDM, telah ditetapkan oleh konsorsium, yang terdiri dari tiga siklus berulang yang berbeda, yang diawali oleh dua aktivitas tambahan siklus hidup:
Feasibility study - Mengidentifikasi kebutuhan dasar bisnis dan batasan yang terkait dengan aplikasi yang akan dikembangkan, lalu mengevaluasi apakah aplikasi tersebut cocok untuk diproses menggunakan metode DSDM.
Business study - Dalam tahap ini, dilakukan identifikasi persyaratan fungsional dan non-fungsional yang dibutuhkan agar aplikasi dapat memberikan nilai bisnis. Selain itu, arsitektur aplikasi juga didefinisikan dan persyaratan pemeliharaannya diidentifikasi.
Functional model iteration - Membuat kumpulan prototipe inkremental yang menampilkan fungsi-fungsi yang dibutuhkan oleh pelanggan. Harus diperhatikan bahwa setiap prototipe dalam metode DSDM dimaksudkan untuk menjadi aplikasi yang dapat dikirimkan. Tujuan dari setiap iterasi adalah untuk mengumpulkan persyaratan tambahan dengan cara memperoleh masukan dari pengguna saat mereka menggunakan prototipe.
Design and build iteration - Pada tahap iterasi model fungsional, dilakukan evaluasi ulang terhadap prototipe yang telah dibuat untuk memastikan bahwa setiap prototipe telah dibangun sesuai dengan kebutuhan bisnis dan memberikan manfaat operasional kepada pengguna akhir. Dalam beberapa situasi, tahap ini dilakukan secara bersamaan dengan tahap desain dan pembangunan iteratif.
Implementation - Dalam tahap ini, prototipe perangkat lunak yang telah ditingkatkan akan dioperasikan dalam lingkungan operasional. Perlu diingat bahwa peningkatan tersebut mungkin tidak sepenuhnya selesai atau mungkin memerlukan perubahan di kemudian hari. Dalam kedua kasus tersebut, pengembangan DSDM akan melanjutkan kembali ke tahap iterasi model fungsional.
DSDM bisa digabungkan dengan XP untuk menciptakan pendekatan gabungan yang mengombinasikan model siklus hidup DSDM yang kokoh dengan praktik XP yang murah dan cepat dalam membangun peningkatan perangkat lunak. Selain itu, konsep ASD dan tim yang mandiri dapat disesuaikan dengan model proses gabungan ini.
1.4 Crystal
Alistair Cockburn dan Jim Highsmith menciptakan Crystal Agile Methodology untuk menghasilkan pendekatan pengembangan perangkat lunak yang menekankan pada "kemampuan manuver" selama apa yang disebut Cockburn sebagai "permainan penemuan dan kooperatif terbatas sumber daya komunikasi, dengan tujuan utama memberikan perangkat lunak yang berguna dan berfungsi, serta tujuan sekunder menyiapkan game berikutnya".
Untuk mencapai kemampuan manuver, Cockburn dan Highsmith menetapkan seperangkat metodologi dengan elemen inti yang sama untuk semua, namun memiliki peran, pola proses, produk kerja, dan praktik yang unik untuk masing-masing. Keluarga Crystal adalah kumpulan contoh proses gesit yang terbukti efektif untuk berbagai jenis proyek. Tujuannya adalah memungkinkan tim yang tangkas memilih anggota keluarga Crystal yang paling tepat untuk proyek dan lingkungan mereka.
1.5 Feature Driven Development (FDD)
Peter Coad dan kolega merancang Feature Driven Development (FDD) sebagai model proses rekayasa perangkat lunak berorientasi objek yang praktis. Model ini kemudian dikembangkan lebih lanjut oleh Stephen Palmer dan John Felsing, yang mengusulkan pendekatan yang adaptif dan gesit yang dapat digunakan dalam proyek perangkat lunak berukuran sedang hingga besar.
Seperti halnya dengan metodologi agile lainnya, FDD memiliki filosofi yang sama yaitu (1) fokus pada kolaborasi antar anggota tim FDD; (2) menangani kompleksitas proyek dengan menggunakan dekomposisi fitur dan integrasi peningkatan perangkat lunak, dan (3) komunikasi teknis yang terperinci melalui metode verbal, grafis, dan teks. FDD menempatkan kegiatan penjaminan kualitas perangkat lunak yang tinggi dengan mendorong penggunaan strategi pengembangan tambahan, penerapan desain dan pemeriksaan kode, penggunaan audit jaminan kualitas perangkat lunak, pengumpulan metrik, dan penerapan pola (untuk analisis, desain, dan konstruksi).
Dalam konteks FDD, sebuah fitur diartikan sebagai "fungsi bernilai klien yang dapat diimplementasikan dalam waktu dua minggu atau kurang". Penekanan pada pengertian fitur tersebut memiliki keuntungan sebagai berikut:
- Dalam FDD, fitur merupakan bagian kecil dari fungsionalitas yang dapat diimplementasikan, sehingga pengguna dapat lebih mudah mendefinisikannya, memahami keterkaitannya satu sama lain, dan mengevaluasinya untuk potensi ambiguitas, kesalahan, atau kelalaian.
- Fitur-fitur dapat dikelompokkan berdasarkan hierarki bisnis yang terkait.
- Dalam FDD, sebuah fitur adalah peningkatan perangkat lunak yang dapat diterapkan, dan tim FDD membangun fitur operasional setiap dua minggu.
- Dalam FDD, karena fitur yang dikembangkan memiliki skala kecil, maka desain dan kode yang dibuat juga lebih mudah untuk diperiksa dengan efektif.
- Dalam FDD, perencanaan proyek, penjadwalan, dan pelacakan progres proyek didasarkan pada hierarki fitur, bukan sekadar sekumpulan tugas rekayasa perangkat lunak yang ditentukan secara acak.
<action> the <result> <by for of to> a(n) <object>
Dalam template yang disarankan oleh Coad dan rekan-rekannya, <object> dapat berupa "seseorang, tempat, atau benda (termasuk peran, momen dalam waktu atau interval waktu, atau deskripsi seperti entri katalog)." Sebagai contoh, sebuah fitur untuk aplikasi e-niaga dapat berbunyi:
Melakukan penambahan produk ke dalam keranjang belanja.
Tampilkan spesifikasi teknis dari produk yang dimaksud
Memasukkan informasi pengiriman pelanggan ke dalam sistem
Kategori fitur terkait bisnis diorganisir dalam kelompok fitur, yang terdiri dari fitur yang saling terkait dan didefinisikan sebagai:
<action><-ing> a(n) <object>
Sebagai contoh, kumpulan fitur pembuatan penjualan produk mencakup fitur-fitur yang telah disebutkan sebelumnya dan juga fitur-fitur lainnya.
FDD mengadopsi lima kegiatan kerangka kerja yang dikenal sebagai "proses" untuk memfasilitasi kerja tim yang efektif. Ini ditunjukkan dalam Gambar 1.3.
FDD lebih menekankan pada pedoman dan teknik manajemen proyek dibandingkan dengan metode agile lainnya. Ketika proyek menjadi semakin besar dan kompleks, manajemen proyek yang ad hoc mungkin tidak cukup. Oleh karena itu, sangat penting bagi pengembang, manajer proyek, dan pemangku kepentingan lainnya untuk memahami kemajuan proyek, termasuk pencapaian yang telah dicapai dan masalah yang sedang dihadapi. Jika tenggat waktu proyek sangat ketat, sangat penting untuk menentukan apakah peningkatan (fitur) perangkat lunak sudah dijadwalkan dengan benar. Untuk mencapai hal ini, FDD mengadopsi enam tahapan selama desain dan implementasi fitur, yaitu "panduan desain, desain, inspeksi desain, kode, inspeksi kode, promosi untuk membangun".
1.6 Lean Software Development (LSD)
Lean Software Development (LSD) merupakan sebuah metode pengembangan perangkat lunak yang mengadopsi prinsip-prinsip lean manufacturing ke dalam industri rekayasa perangkat lunak. Prinsip-prinsip lean yang diadopsi dalam LSD terdiri dari beberapa aspek, antara lain eliminasi pemborosan, peningkatan kualitas, pengembangan pengetahuan, menunda komitmen, pengiriman yang cepat, penghargaan terhadap orang, dan optimalisasi keseluruhan. Hal ini diadaptasi dari beberapa referensi.
Prinsip-prinsip lean manufacturing dapat diadaptasi ke dalam proses perangkat lunak dengan cara yang sesuai. Dalam proses perangkat lunak yang tangkas, menghilangkan pemborosan dapat diartikan sebagai menghindari penambahan fitur yang tidak perlu, mengevaluasi dampak biaya dan jadwal dari permintaan baru, mengurangi langkah-langkah proses yang tidak diperlukan, meningkatkan cara anggota tim menemukan informasi, memperkuat pengujian untuk menemukan kesalahan sebanyak mungkin, mempercepat pengambilan keputusan, dan menyederhanakan pengiriman informasi ke semua pemangku kepentingan yang terlibat.
1.7 Agile Modeling (AM)
Banyak kasus di mana insinyur perangkat lunak harus membuat sistem bisnis penting yang besar. Agar dapat lebih memahami apa yang perlu dicapai dan masalah dapat dibagi secara efektif di antara orang-orang yang bertanggung jawab untuk menyelesaikannya, cakupan dan kompleksitas sistem tersebut harus dimodelkan. Selain itu, kualitas dapat dinilai saat sistem sedang direkayasa dan dibangun.
Selama tiga dekade terakhir, berbagai metode pemodelan dan notasi rekayasa perangkat lunak telah diusulkan untuk analisis dan desain pada level arsitektur dan komponen. Meskipun metode-metode ini berguna, namun implementasinya terbukti sulit dan sulit dipertahankan dalam banyak proyek. Hal ini disebabkan oleh kompleksitas dari metode pemodelan yang digunakan, seperti volume notasi yang diperlukan, tingkat formalisme yang disarankan, ukuran model untuk proyek besar, dan kesulitan dalam mempertahankan model saat terjadi perubahan. Namun, analisis dan pemodelan desain dapat memberikan manfaat besar untuk proyek-proyek besar, terutama untuk tujuan manajemen proyek. Oleh karena itu, ada kebutuhan untuk mencari pendekatan pemodelan rekayasa perangkat lunak yang lebih gesit sebagai alternatif yang mungkin.
Pada "Situs Pemodelan Agile Resmi," Scott Ambler menjelaskan konsep pemodelan tangkas (AM) sebagai berikut:
Agile Modeling (AM) merupakan metodologi praktik untuk pemodelan dan dokumentasi sistem berbasis perangkat lunak yang efektif. Dengan kata sederhana, Agile Modeling (AM) adalah seperangkat nilai, prinsip, dan praktik untuk pemodelan perangkat lunak yang dapat diterapkan pada proyek pengembangan perangkat lunak dengan cara yang efektif dan ringan. Model tangkas yang digunakan dalam AM terbukti lebih efektif dibandingkan dengan model tradisional karena sifatnya yang tidak terlalu formal dan tidak perlu mencapai kesempurnaan.
Dalam agile modeling, dianut nilai-nilai yang sejalan dengan manifesto tangkas. Pendekatan ini meyakini bahwa tim yang tangkas harus berani mengambil keputusan yang mungkin mengakibatkan desain ditolak atau perlu dilakukan refaktor. Selain itu, tim juga harus memiliki sifat rendah hati, menyadari bahwa para ahli teknologi tidak selalu memiliki jawaban yang tepat, dan harus menghargai serta melibatkan para ahli bisnis dan pemangku kepentingan lainnya.
Walaupun Agile Modeling (AM) memiliki beberapa prinsip pemodelan inti dan pelengkap, hal yang membuat AM berbeda adalah seperti yang dijelaskan oleh Scott Ambler:
Model with a purpose. Sebelum membuat model, pengembang yang menggunakan AM perlu memiliki tujuan yang spesifik, seperti untuk memfasilitasi komunikasi dengan pelanggan atau untuk mendapatkan pemahaman yang lebih baik tentang beberapa aspek perangkat lunak. Dengan menetapkan tujuan model, jenis notasi yang akan digunakan dan tingkat rincian yang diperlukan akan lebih jelas.
Use multiple models. AM mencatat bahwa ada banyak model dan notasi yang berbeda yang dapat digunakan untuk mendeskripsikan perangkat lunak, tetapi hanya sedikit yang penting untuk sebagian besar proyek. Oleh karena itu, AM menyarankan bahwa setiap model harus menyajikan aspek yang berbeda dari sistem dan hanya model yang memberikan nilai bagi audiens yang dituju yang harus digunakan untuk memberikan wawasan yang dibutuhkan.
Travel light. Dalam rekayasa perangkat lunak, hanya model yang memberikan nilai jangka panjang yang harus dipertahankan, sedangkan yang lainnya harus dibuang selama pekerjaan berlangsung. Namun, setiap produk kerja yang disimpan harus tetap dipertahankan saat terjadi perubahan. Meskipun hal ini memperlambat tim, mengambil keputusan untuk mempertahankan model berarti memperoleh keuntungan dalam meningkatkan komunikasi dalam tim dan dengan pemangku kepentingan proyek. Seperti yang dicatat oleh Ambler, “Setiap kali Anda memutuskan untuk mempertahankan model, Anda menukar ketangkasan demi kenyamanan menyediakan informasi tersebut untuk tim Anda secara abstrak.”
Content is more important than representation. Untuk membuat model yang berguna, model harus memberikan informasi yang relevan untuk audiens yang diinginkan. Sebuah model yang sangat baik secara formal tetapi memberikan sedikit konten berguna tidak sepadan dengan model yang kurang sempurna secara formal namun tetap memberikan informasi yang berguna bagi audiensnya.
Know the models and the tools you use to create them. Memahami kekuatan dan kelemahan dari setiap model dan alat yang digunakan untuk membuatnya merupakan suatu hal yang penting.
Adapt locally. Pendekatan pemodelan yang digunakan harus disesuaikan dengan kebutuhan tim yang sedang menerapkan Agile Modeling.
Sebagian besar komunitas rekayasa perangkat lunak telah mengambil pendekatan Unified Modelling Language (UML) sebagai metode yang disukai untuk merepresentasikan model analisis dan desain. Ada kerangka kerja penerapan UML yang disebut Proses Terpadu. Scott Ambler telah mengembangkan versi yang disederhanakan dari UP yang mengintegrasikan filosofi agile modeling.
1.8 Agile Unified Process (AUP)
Agile Unified Process (AUP) menganut filosofi "serial in the large" dan "iterative in the small" dalam pembangunan sistem berbasis komputer. Dengan menggunakan tahapan insepsi, elaborasi, konstruksi, dan transisi dari UP klasik, AUP menambahkan overlay serial (yaitu, urutan aktivitas rekayasa perangkat lunak yang linear) untuk memvisualisasikan aliran proses keseluruhan dari proyek perangkat lunak. Namun, dalam setiap tahapan, tim melakukan iterasi untuk mencapai ketangkasan dan memberikan peningkatan perangkat lunak yang signifikan kepada pengguna akhir sesegera mungkin. Setiap iterasi AUP mencakup aktivitas berikut:
- Modeling. Untuk menjaga kelenturan, model UML yang mewakili domain bisnis dan masalah perlu dibuat dengan cukup baik agar tim dapat terus berlanjut. Hal ini disarankan oleh Scott Ambler dalam metodenya yang berfokus pada agilitas dalam rekayasa perangkat lunak.
- Implementation. Model diubah menjadi kode program.
- Testing. Mirip dengan XP, sebuah tim akan melakukan perancangan dan pelaksanaan serangkaian pengujian untuk menemukan kesalahan dan memastikan bahwa kode sumber telah memenuhi persyaratannya.
- Deployment. Seperti yang dibahas pada bab sebelumnya mengenai aktivitas proses generik, penerapannya dalam konteks ini difokuskan pada pengiriman peningkatan perangkat lunak dan mendapatkan umpan balik dari pengguna akhir.
- Configuration and project management. Dalam kerangka Agile Unified Process (AUP), manajemen konfigurasi membahas tentang bagaimana mengelola perubahan, mengendalikan risiko, dan mengontrol setiap produk kerja yang dihasilkan oleh tim yang berkelanjutan. Selain itu, manajemen proyek bertanggung jawab untuk memantau kemajuan tim dan mengkoordinasikan aktivitasnya.
- Environment management. Dalam hal manajemen lingkungan, tugasnya adalah mengoordinasikan infrastruktur proses yang meliputi standar, alat, dan teknologi pendukung lainnya yang tersedia untuk tim dalam menjalankan proyek.
Source: Pressman, Roger S. 2010. Software engineering : A Practitioner’s Approach (7th. Edition). New York: McGraw-Hill Higher Education.
Comments
Post a Comment