Pengembangan perangkat lunak adaptif: Perbedaan antara revisi
Impor teks terkontrol dari Wikipedia bahasa Indonesia; revisi 27872141; atribusi sumber disertakan. |
Presentation V4: sitasi, referensi, Math, Wikimedia Commons, dan atribusi |
||
| Baris 1: | Baris 1: | ||
'''Pengembangan perangkat lunak adaptif''' () adalah pendekatan [[pemrograman ekstrem]] termodifikasi berupa model tangkas () yang paling banyak digunakan. ASD telah diusulkan oleh [[Jim Highsmith]] '''[Hig00]''' sebagai teknik untuk membangun [[perangkat lunak]] dan sistem yang kompleks. Landasan filsafai ASD berfokus pada kerja sama manusia dan penertiban diri tim. Highsmith berpendapat bahwa pendekatan pengembangan tangkas dan adaptif berlandaskan kerja sama adalah "sebanyak-banyaknya sumber perintah dalam interaksi kompleks sebagai disiplin dan rekayasa." Highsmith mengartikan siklus hidup ASD yang terdiri dari tiga tahap, spekulasi, kerja sama, dan pembelajaran. | '''Pengembangan perangkat lunak adaptif''' () adalah pendekatan [[pemrograman ekstrem]] termodifikasi berupa model tangkas () yang paling banyak digunakan.<ref>Muhammad Qureshi. ''An adaptive software development process model''. ''Advances in Engineering Software''. 2007.</ref> ASD telah diusulkan oleh [[Jim Highsmith]] '''[Hig00]''' sebagai teknik untuk membangun [[perangkat lunak]] dan sistem yang kompleks. Landasan filsafai ASD berfokus pada kerja sama manusia dan penertiban diri tim. Highsmith berpendapat bahwa pendekatan pengembangan tangkas dan adaptif berlandaskan kerja sama adalah "sebanyak-banyaknya sumber perintah dalam interaksi kompleks sebagai disiplin dan rekayasa." Highsmith mengartikan siklus hidup ASD yang terdiri dari tiga tahap, spekulasi, kerja sama, dan pembelajaran.<ref>Pressman, Roger S. [http://worldcat.org/oclc/949696534 Software engineering : a practitioner's approach]. McGraw-Hill Education. 2015. ISBN 9781259253157.</ref> | ||
== Siklus hidup ASD == | == Siklus hidup ASD == | ||
=== ''Speculate: Initiation and Planning'' === | === ''Speculate: Initiation and Planning'' === | ||
Ada lima langkah umum dalam "berspekulasi" meskipun kata "langkah" agak keliru, karena setiap langkah dapat direvisi beberapa kali selama fase inisiasi ''(initiation)'' dan perencanaan ''(planning)''. Pertama, inisiasi proyek melibatkan pengaturan misi dan tujuan proyek, memahami kendala, menetapkan organisasi proyek, mengidentifikasi dan menguraikan kebutuhan, membuat perkiraan ukuran dan ruang lingkup awal, dan mengidentifikasi risiko proyek utama. Karena kecepatan biasanya menjadi pertimbangan utama dalam menggunakan ASD, banyak data inisiasi proyek harus dikumpulkan dalam sesi awal JAD. Inisiasi dapat diselesaikan dalam upaya dua hingga lima hari terkonsentrasi untuk proyek berukuran kecil hingga menengah atau memakan waktu dua atau tiga minggu untuk proyek yang lebih besar. Selama sesi JAD, kebutuhan dikumpulkan secara cukup rinci untuk mengidentifikasi fitur dan menetapkan kerangka objek, data, atau model arsitektur lainnya. | Ada lima langkah umum dalam "berspekulasi" meskipun kata "langkah" agak keliru, karena setiap langkah dapat direvisi beberapa kali selama fase inisiasi ''(initiation)'' dan perencanaan ''(planning)''. Pertama, inisiasi proyek melibatkan pengaturan misi dan tujuan proyek, memahami kendala, menetapkan organisasi proyek, mengidentifikasi dan menguraikan kebutuhan, membuat perkiraan ukuran dan ruang lingkup awal, dan mengidentifikasi risiko proyek utama. Karena kecepatan biasanya menjadi pertimbangan utama dalam menggunakan ASD, banyak data inisiasi proyek harus dikumpulkan dalam sesi awal JAD. Inisiasi dapat diselesaikan dalam upaya dua hingga lima hari terkonsentrasi untuk proyek berukuran kecil hingga menengah atau memakan waktu dua atau tiga minggu untuk proyek yang lebih besar. Selama sesi JAD, kebutuhan dikumpulkan secara cukup rinci untuk mengidentifikasi fitur dan menetapkan kerangka objek, data, atau model arsitektur lainnya.<ref>Orr, Ken. [http://worldcat.org/oclc/26725304 The one minute methodology]. Dorset House. 1990. ISBN 093263317X.</ref> | ||
Selanjutnya, kotak waktu ''(time-box)'' untuk seluruh proyek ditetapkan berdasarkan ruang lingkup, kebutuhan set fitur, perkiraan, dan ketersediaan sumber daya yang dihasilkan dari pekerjaan inisiasi proyek. Berspekulasi tidak mengabaikan estimasi, itu hanya berarti menerima bahwa estimasi itu lemah. Langkah ketiga adalah memutuskan jumlah [[iterasi]] dan menetapkan kotak waktu untuk masing-masing. Untuk aplikasi kecil hingga menengah, iterasi biasanya bervariasi dari empat hingga delapan minggu. Beberapa proyek bekerja paling baik dengan iterasi dua minggu, sementara yang lain mungkin membutuhkan lebih dari delapan minggu (walaupun ini jarang terjadi). Ukuran proyek keseluruhan dan tingkat ketidakpastian adalah dua faktor yang menentukan panjang iterasi individu. | Selanjutnya, kotak waktu ''(time-box)'' untuk seluruh proyek ditetapkan berdasarkan ruang lingkup, kebutuhan set fitur, perkiraan, dan ketersediaan sumber daya yang dihasilkan dari pekerjaan inisiasi proyek. Berspekulasi tidak mengabaikan estimasi, itu hanya berarti menerima bahwa estimasi itu lemah. Langkah ketiga adalah memutuskan jumlah [[iterasi]] dan menetapkan kotak waktu untuk masing-masing. Untuk aplikasi kecil hingga menengah, iterasi biasanya bervariasi dari empat hingga delapan minggu. Beberapa proyek bekerja paling baik dengan iterasi dua minggu, sementara yang lain mungkin membutuhkan lebih dari delapan minggu (walaupun ini jarang terjadi). Ukuran proyek keseluruhan dan tingkat ketidakpastian adalah dua faktor yang menentukan panjang iterasi individu.<ref>Orr, Ken. [http://worldcat.org/oclc/26725304 The one minute methodology]. Dorset House. 1990. ISBN 093263317X.</ref> | ||
Setelah menetapkan jumlah iterasi dan jadwal untuk masing-masing, anggota tim mengembangkan tema atau tujuan untuk masing-masing iterasi. Seperti sama pentingnya untuk menetapkan tujuan proyek secara keseluruhan, setiap iterasi harus memiliki tema sendiri (ini mirip dengan ''Sprint Goal'' in Scrum). Setiap iterasi memberikan serangkaian fitur yang dapat dibuktikan ke proses tinjauan pelanggan, membuat produk terlihat oleh pelanggan. Di dalam iterasi, ''"builds"'' menghadirkan fitur-fitur kerja ke proses integrasi harian (atau lebih sering), menjadikan produk terlihat oleh tim pengembangan. Pengujian merupakan bagian integral dan berkelanjutan dari pengembangan fitur — bukan aktivitas yang dilakukan pada tahap akhir. | Setelah menetapkan jumlah iterasi dan jadwal untuk masing-masing, anggota tim mengembangkan tema atau tujuan untuk masing-masing iterasi. Seperti sama pentingnya untuk menetapkan tujuan proyek secara keseluruhan, setiap iterasi harus memiliki tema sendiri (ini mirip dengan ''Sprint Goal'' in Scrum). Setiap iterasi memberikan serangkaian fitur yang dapat dibuktikan ke proses tinjauan pelanggan, membuat produk terlihat oleh pelanggan. Di dalam iterasi, ''"builds"'' menghadirkan fitur-fitur kerja ke proses integrasi harian (atau lebih sering), menjadikan produk terlihat oleh tim pengembangan. Pengujian merupakan bagian integral dan berkelanjutan dari pengembangan fitur — bukan aktivitas yang dilakukan pada tahap akhir.<ref>Orr, Ken. [http://worldcat.org/oclc/26725304 The one minute methodology]. Dorset House. 1990. ISBN 093263317X.</ref> | ||
Pengembang dan pelanggan menetapkan fitur untuk setiap iterasi. Kriteria paling penting untuk penugasan fitur adalah bahwa setiap iterasi harus memberikan serangkaian fitur yang ''visible'' dan ''tangible'' kepada pelanggan. Dalam proses penugasan, pelanggan memutuskan prioritas fitur, menggunakan perkiraan fitur, risiko, dan informasi ketergantungan yang disediakan oleh tim pengembangan. ''Spreadsheet'' adalah alat yang efektif untuk perencanaan iterasi berbasis fitur. Pengalaman menunjukkan bahwa jenis perencanaan ini — dilakukan sebagai tim dan bukan oleh manajer proyek — memberikan pemahaman yang lebih baik tentang proyek daripada pendekatan berbasis tugas tradisional. Perencanaan berbasis fitur mencerminkan keunikan masing-masing proyek. | Pengembang dan pelanggan menetapkan fitur untuk setiap iterasi. Kriteria paling penting untuk penugasan fitur adalah bahwa setiap iterasi harus memberikan serangkaian fitur yang ''visible'' dan ''tangible'' kepada pelanggan. Dalam proses penugasan, pelanggan memutuskan prioritas fitur, menggunakan perkiraan fitur, risiko, dan informasi ketergantungan yang disediakan oleh tim pengembangan. ''Spreadsheet'' adalah alat yang efektif untuk perencanaan iterasi berbasis fitur. Pengalaman menunjukkan bahwa jenis perencanaan ini — dilakukan sebagai tim dan bukan oleh manajer proyek — memberikan pemahaman yang lebih baik tentang proyek daripada pendekatan berbasis tugas tradisional. Perencanaan berbasis fitur mencerminkan keunikan masing-masing proyek.<ref>Orr, Ken. [http://worldcat.org/oclc/26725304 The one minute methodology]. Dorset House. 1990. ISBN 093263317X.</ref> | ||
=== ''Collaborate: Concurrent Feature Develompent'' === | === ''Collaborate: Concurrent Feature Develompent'' === | ||
Sementara tim teknis menyediakan perangkat lunak yang berfungsi, manajer proyek memfasilitasi kolaborasi dan kegiatan pengembangan bersamaan. Untuk proyek yang melibatkan tim terdistribusi, berbagai mitra aliansi, dan pengetahuan yang luas, bagaimana orang berinteraksi dan bagaimana mereka mengelola ketergantungan adalah masalah penting. Untuk proyek yang lebih kecil di mana anggota tim bekerja dalam kedekatan fisik, kolaborasi dapat terdiri dari obrolan informal dan [[papan tulis]]. Namun, proyek yang lebih besar membutuhkan praktik tambahan, alat kolaborasi, dan interaksi manajer proyek. Kolaborasi, suatu tindakan penciptaan bersama, dipupuk oleh kepercayaan dan rasa hormat. Penciptaan bersama mencakup tim pengembangan, pelanggan, konsultan luar, dan vendor. Tim harus berkolaborasi dalam masalah teknis, kebutuhan bisnis, dan pengambilan keputusan yang cepat. | Sementara tim teknis menyediakan perangkat lunak yang berfungsi, manajer proyek memfasilitasi kolaborasi dan kegiatan pengembangan bersamaan. Untuk proyek yang melibatkan tim terdistribusi, berbagai mitra aliansi, dan pengetahuan yang luas, bagaimana orang berinteraksi dan bagaimana mereka mengelola ketergantungan adalah masalah penting. Untuk proyek yang lebih kecil di mana anggota tim bekerja dalam kedekatan fisik, kolaborasi dapat terdiri dari obrolan informal dan [[papan tulis]]. Namun, proyek yang lebih besar membutuhkan praktik tambahan, alat kolaborasi, dan interaksi manajer proyek. Kolaborasi, suatu tindakan penciptaan bersama, dipupuk oleh kepercayaan dan rasa hormat. Penciptaan bersama mencakup tim pengembangan, pelanggan, konsultan luar, dan vendor. Tim harus berkolaborasi dalam masalah teknis, kebutuhan bisnis, dan pengambilan keputusan yang cepat.<ref>Orr, Ken. [http://worldcat.org/oclc/26725304 The one minute methodology]. Dorset House. 1990. ISBN 093263317X.</ref> | ||
=== ''Learn: Quality Review'' === | === ''Learn: Quality Review'' === | ||
Belajar menjadi semakin sulit di lingkungan di mana mantra "lakukan dengan benar pertama kali" mendominasi dan perkembangan berlangsung secara linear ''([[Model Waterfall|waterfall)]]''. Jika orang terus dipaksa untuk melakukannya dengan benar, mereka tidak akan bereksperimen dan belajar. Dalam pengembangan ''waterfall'', setiap penyelesaian fase menghambat mundur karena tidak boleh ada kesalahan. Belajar dari kesalahan dan eksperimen mengharuskan anggota tim membagikan kode dan artefak yang diselesaikan sebagian lebih awal, untuk menemukan kesalahan, belajar dari mereka, dan mengurangi jumlah total pengerjaan ulang dengan menemukan masalah kecil sebelum menjadi masalah besar. Tim harus belajar membedakan antara pekerjaan jelek dan pekerjaan setengah jadi. Terdapat 4 kategori umum untuk hal yang harus dipelajari pada setiap iterasi pengembangan, yaitu kualitas hasil dari perspektif pelanggan, kualitas hasil dari perspektif teknikal, fungsi tim penyampaian dan tim praktik dimanfaatkan, dan status proyek. | Belajar menjadi semakin sulit di lingkungan di mana mantra "lakukan dengan benar pertama kali" mendominasi dan perkembangan berlangsung secara linear ''([[Model Waterfall|waterfall)]]''. Jika orang terus dipaksa untuk melakukannya dengan benar, mereka tidak akan bereksperimen dan belajar. Dalam pengembangan ''waterfall'', setiap penyelesaian fase menghambat mundur karena tidak boleh ada kesalahan. Belajar dari kesalahan dan eksperimen mengharuskan anggota tim membagikan kode dan artefak yang diselesaikan sebagian lebih awal, untuk menemukan kesalahan, belajar dari mereka, dan mengurangi jumlah total pengerjaan ulang dengan menemukan masalah kecil sebelum menjadi masalah besar. Tim harus belajar membedakan antara pekerjaan jelek dan pekerjaan setengah jadi. Terdapat 4 kategori umum untuk hal yang harus dipelajari pada setiap iterasi pengembangan, yaitu kualitas hasil dari perspektif pelanggan, kualitas hasil dari perspektif teknikal, fungsi tim penyampaian dan tim praktik dimanfaatkan, dan status proyek.<ref>Orr, Ken. [http://worldcat.org/oclc/26725304 The one minute methodology]. Dorset House. 1990. ISBN 093263317X.</ref> | ||
== Referensi == | == Referensi == | ||
<references /> | |||
< | |||
== Sumber dan atribusi == | == Sumber dan atribusi == | ||
Konten artikel ini diadaptasi dari [https://id.wikipedia.org/w/index.php?title=Pengembangan+perangkat+lunak+adaptif&oldid=27872141 Wikipedia bahasa Indonesia], revisi 27872141 (2025-09-23T02:10:24Z), yang tersedia berdasarkan lisensi Creative Commons Atribusi-BerbagiSerupa (CC BY-SA). Mohon gunakan konten ini secara bijak serta sesuai dengan ketentuan lisensi yang berlaku. | Konten artikel ini diadaptasi dari [https://id.wikipedia.org/w/index.php?title=Pengembangan+perangkat+lunak+adaptif&oldid=27872141 Wikipedia bahasa Indonesia], revisi 27872141 (2025-09-23T02:10:24Z), yang tersedia berdasarkan lisensi Creative Commons Atribusi-BerbagiSerupa (CC BY-SA). Mohon gunakan konten ini secara bijak serta sesuai dengan ketentuan lisensi yang berlaku. | ||
<!-- WIKI_UNISSULA_PRESENTATION_V4 --> | |||
Revisi terkini sejak 23 Agustus 2026 14.08
Pengembangan perangkat lunak adaptif () adalah pendekatan pemrograman ekstrem termodifikasi berupa model tangkas () yang paling banyak digunakan.[1] ASD telah diusulkan oleh Jim Highsmith [Hig00] sebagai teknik untuk membangun perangkat lunak dan sistem yang kompleks. Landasan filsafai ASD berfokus pada kerja sama manusia dan penertiban diri tim. Highsmith berpendapat bahwa pendekatan pengembangan tangkas dan adaptif berlandaskan kerja sama adalah "sebanyak-banyaknya sumber perintah dalam interaksi kompleks sebagai disiplin dan rekayasa." Highsmith mengartikan siklus hidup ASD yang terdiri dari tiga tahap, spekulasi, kerja sama, dan pembelajaran.[2]
Siklus hidup ASD
Speculate: Initiation and Planning
Ada lima langkah umum dalam "berspekulasi" meskipun kata "langkah" agak keliru, karena setiap langkah dapat direvisi beberapa kali selama fase inisiasi (initiation) dan perencanaan (planning). Pertama, inisiasi proyek melibatkan pengaturan misi dan tujuan proyek, memahami kendala, menetapkan organisasi proyek, mengidentifikasi dan menguraikan kebutuhan, membuat perkiraan ukuran dan ruang lingkup awal, dan mengidentifikasi risiko proyek utama. Karena kecepatan biasanya menjadi pertimbangan utama dalam menggunakan ASD, banyak data inisiasi proyek harus dikumpulkan dalam sesi awal JAD. Inisiasi dapat diselesaikan dalam upaya dua hingga lima hari terkonsentrasi untuk proyek berukuran kecil hingga menengah atau memakan waktu dua atau tiga minggu untuk proyek yang lebih besar. Selama sesi JAD, kebutuhan dikumpulkan secara cukup rinci untuk mengidentifikasi fitur dan menetapkan kerangka objek, data, atau model arsitektur lainnya.[3]
Selanjutnya, kotak waktu (time-box) untuk seluruh proyek ditetapkan berdasarkan ruang lingkup, kebutuhan set fitur, perkiraan, dan ketersediaan sumber daya yang dihasilkan dari pekerjaan inisiasi proyek. Berspekulasi tidak mengabaikan estimasi, itu hanya berarti menerima bahwa estimasi itu lemah. Langkah ketiga adalah memutuskan jumlah iterasi dan menetapkan kotak waktu untuk masing-masing. Untuk aplikasi kecil hingga menengah, iterasi biasanya bervariasi dari empat hingga delapan minggu. Beberapa proyek bekerja paling baik dengan iterasi dua minggu, sementara yang lain mungkin membutuhkan lebih dari delapan minggu (walaupun ini jarang terjadi). Ukuran proyek keseluruhan dan tingkat ketidakpastian adalah dua faktor yang menentukan panjang iterasi individu.[4]
Setelah menetapkan jumlah iterasi dan jadwal untuk masing-masing, anggota tim mengembangkan tema atau tujuan untuk masing-masing iterasi. Seperti sama pentingnya untuk menetapkan tujuan proyek secara keseluruhan, setiap iterasi harus memiliki tema sendiri (ini mirip dengan Sprint Goal in Scrum). Setiap iterasi memberikan serangkaian fitur yang dapat dibuktikan ke proses tinjauan pelanggan, membuat produk terlihat oleh pelanggan. Di dalam iterasi, "builds" menghadirkan fitur-fitur kerja ke proses integrasi harian (atau lebih sering), menjadikan produk terlihat oleh tim pengembangan. Pengujian merupakan bagian integral dan berkelanjutan dari pengembangan fitur — bukan aktivitas yang dilakukan pada tahap akhir.[5]
Pengembang dan pelanggan menetapkan fitur untuk setiap iterasi. Kriteria paling penting untuk penugasan fitur adalah bahwa setiap iterasi harus memberikan serangkaian fitur yang visible dan tangible kepada pelanggan. Dalam proses penugasan, pelanggan memutuskan prioritas fitur, menggunakan perkiraan fitur, risiko, dan informasi ketergantungan yang disediakan oleh tim pengembangan. Spreadsheet adalah alat yang efektif untuk perencanaan iterasi berbasis fitur. Pengalaman menunjukkan bahwa jenis perencanaan ini — dilakukan sebagai tim dan bukan oleh manajer proyek — memberikan pemahaman yang lebih baik tentang proyek daripada pendekatan berbasis tugas tradisional. Perencanaan berbasis fitur mencerminkan keunikan masing-masing proyek.[6]
Collaborate: Concurrent Feature Develompent
Sementara tim teknis menyediakan perangkat lunak yang berfungsi, manajer proyek memfasilitasi kolaborasi dan kegiatan pengembangan bersamaan. Untuk proyek yang melibatkan tim terdistribusi, berbagai mitra aliansi, dan pengetahuan yang luas, bagaimana orang berinteraksi dan bagaimana mereka mengelola ketergantungan adalah masalah penting. Untuk proyek yang lebih kecil di mana anggota tim bekerja dalam kedekatan fisik, kolaborasi dapat terdiri dari obrolan informal dan papan tulis. Namun, proyek yang lebih besar membutuhkan praktik tambahan, alat kolaborasi, dan interaksi manajer proyek. Kolaborasi, suatu tindakan penciptaan bersama, dipupuk oleh kepercayaan dan rasa hormat. Penciptaan bersama mencakup tim pengembangan, pelanggan, konsultan luar, dan vendor. Tim harus berkolaborasi dalam masalah teknis, kebutuhan bisnis, dan pengambilan keputusan yang cepat.[7]
Learn: Quality Review
Belajar menjadi semakin sulit di lingkungan di mana mantra "lakukan dengan benar pertama kali" mendominasi dan perkembangan berlangsung secara linear (waterfall). Jika orang terus dipaksa untuk melakukannya dengan benar, mereka tidak akan bereksperimen dan belajar. Dalam pengembangan waterfall, setiap penyelesaian fase menghambat mundur karena tidak boleh ada kesalahan. Belajar dari kesalahan dan eksperimen mengharuskan anggota tim membagikan kode dan artefak yang diselesaikan sebagian lebih awal, untuk menemukan kesalahan, belajar dari mereka, dan mengurangi jumlah total pengerjaan ulang dengan menemukan masalah kecil sebelum menjadi masalah besar. Tim harus belajar membedakan antara pekerjaan jelek dan pekerjaan setengah jadi. Terdapat 4 kategori umum untuk hal yang harus dipelajari pada setiap iterasi pengembangan, yaitu kualitas hasil dari perspektif pelanggan, kualitas hasil dari perspektif teknikal, fungsi tim penyampaian dan tim praktik dimanfaatkan, dan status proyek.[8]
Referensi
- ↑ Muhammad Qureshi. An adaptive software development process model. Advances in Engineering Software. 2007.
- ↑ Pressman, Roger S. Software engineering : a practitioner's approach. McGraw-Hill Education. 2015. ISBN 9781259253157.
- ↑ Orr, Ken. The one minute methodology. Dorset House. 1990. ISBN 093263317X.
- ↑ Orr, Ken. The one minute methodology. Dorset House. 1990. ISBN 093263317X.
- ↑ Orr, Ken. The one minute methodology. Dorset House. 1990. ISBN 093263317X.
- ↑ Orr, Ken. The one minute methodology. Dorset House. 1990. ISBN 093263317X.
- ↑ Orr, Ken. The one minute methodology. Dorset House. 1990. ISBN 093263317X.
- ↑ Orr, Ken. The one minute methodology. Dorset House. 1990. ISBN 093263317X.
Sumber dan atribusi
Konten artikel ini diadaptasi dari Wikipedia bahasa Indonesia, revisi 27872141 (2025-09-23T02:10:24Z), yang tersedia berdasarkan lisensi Creative Commons Atribusi-BerbagiSerupa (CC BY-SA). Mohon gunakan konten ini secara bijak serta sesuai dengan ketentuan lisensi yang berlaku.