Agile modelling (AM) adalah metodologi untuk pemodelan dan pendokumentasian sistem perangkat lunak berdasarkan praktik terbaik. Pengembangan Agile Modelling (AM) dipimpin oleh Scott Ambler dimulai pada musim gugur tahun 2000. Awalnya disebut Extreme Modelling (XM) tetapi saran Robert Cecil Martin diubah namanya menjadi Agile Modelling pada musim semi 2001. Buku Agile Modeling [1] diterbitkan pada tahun 2002 oleh John Wiley Press. Ia juga memiliki situs web promosi.[2]
Ada banyak situasi di mana praktisi perangkat lunak harus membangun sistem yang besar dan business-critical. Cakupan dan kompleksitas sistem tersebut harus dimodelkan sehingga semua konstituen dapat lebih memahami apa yang harus dicapai, masalah dapat dipartisi secara efektif di antara orang-orang yang harus menyelesaikannya, dan kualitas dapat dinilai saat sistem sedang direkayasa dan dibangun. Selama 30 tahun terakhir, berbagai macam metode pemodelan dan notasi rekayasa perangkat lunak telah diusulkan untuk analisis dan desain (baik tingkat arsitektur maupun komponen). Metode-metode ini pantas, tetapi terbukti sulit diterapkan dan menantang untuk dipertahankan (di banyak proyek). Bagian dari masalahnya adalah “bobot” atau "weight" dari metode pemodelan ini. Maksudnya adalah volume notasi yang diperlukan, tingkat formalisme yang disarankan, ukuran model untuk proyek-proyek besar, dan kesulitan dalam mempertahankan model saat terjadi perubahan. Namun pemodelan analisis dan desain memiliki manfaat besar untuk proyek-proyek besar, jika tidak ada alasan lain selain membuat proyek-proyek ini dapat dikelola secara intelektual.[3]
Di situs resmi Agile Modelling, Scott Ambler [4] menjelaskan Agile Modelling (AM) dengan cara berikut: "Agile Modeling (AM) adalah metodologi berbasis praktik untuk pemodelan dan dokumentasi yang efektif dari sistem berbasis perangkat lunak. Sederhananya, Agile Modeling (AM) adalah kumpulan nilai, prinsip, dan praktik untuk pemodelan perangkat lunak yang dapat diterapkan pada proyek pengembangan perangkat lunak secara efektif dan ringan. Model agile lebih efektif daripada model tradisional karena mereka hampir tidak bagus, mereka tidak harus sempurna."[3]
Agile Modelling mengadopsi semua nilai yang konsisten dengan agile manifesto . Filosofi agile modeling menyadari bahwa tim agile harus memiliki keberanian untuk membuat keputusan yang dapat menyebabkannya sebuah desain ditolak dan di-refactor. Tim juga harus memiliki kerendahan hati untuk mengakui bahwa teknolog tidak memiliki semua jawaban dan bahwa para pakar bisnis dan pemangku kepentingan lainnya harus dihormati dan dianut.[3]
Prinsip Agile Modelling
Meskipun Agile Modelling menyarankan beragam prinsip pemodelan “core” dan “supplementary”, yang membuat Agile Modelling menjadi unik adalah:[4]
Model with purpose
Pengembang yang menggunakan Agile Modelling harus memiliki tujuan spesifik (mis. Untuk mengkomunikasikan informasi kepada pelanggan atau untuk membantu memahami lebih baik beberapa aspek perangkat lunak) sebelum mempertimbangkan membuat model. Setelah tujuan untuk model diidentifikasi, jenis notasi yang akan digunakan dan tingkat perincian yang diperlukan akan lebih jelas.[4]
Use multiple models
Ada banyak model dan notasi yang dapat digunakan untuk menggambarkan perangkat lunak. Hanya sebagian kecil yang penting untuk sebagian besar proyek. Agile Modelling menyarankan bahwa untuk memberikan wawasan yang diperlukan, setiap model harus menyajikan aspek yang berbeda dari sistem dan hanya model-model yang memberikan nilai kepada audiens yang dituju yang harus digunakan.[4]
Travel Light
Saat pekerjaan rekayasa perangkat lunak berlangsung, simpan hanya modul yang akan memberikan nilai jangka panjang dan membuang sisanya. Setiap work product yang disimpan harus dipertahankan jika terjadi perubahan. Ini mewakili pekerjaan yang memperlambat tim. Ambler[4] mencatat bahwa “Setiap kali Anda memutuskan untuk menjaga model, Anda menukar ketangkasan (agility) untuk kenyamanan memiliki informasi yang tersedia untuk tim Anda secara abstrak (sehingga berpotensi memperpanjang komunikasi di dalam tim Anda serta dengan pemangku kepentingan proyek)."[4]
Content is more important than representation
Pemodelan harus menyertakan informasi kepada audiens yang dituju. Model yang sempurna secara sintaksis, yang memberikan sedikit konten bermanfaat tidak sama berharganya dengan model dengan notasi yang cacat yang tetap menyediakan konten yang berharga bagi pemirsanya.[4]
Know the models and the tools you use to create them
Pahami kekuatan dan kelemahan masing-masing model dan alat yang digunakan untuk membuatnya.[4]
Adapt Locally
Pendekatan pemodelan harus disesuaikan dengan kebutuhan tim agile[4].
Segmen utama dari komunitas rekayasa perangkat lunak telah mengadopsi Unified Modeling Language (UML) sebagai metode yang disukai untuk mewakili model analisis dan desain. Unified Process (UP) telah dikembangkan untuk menyediakan kerangka kerja untuk aplikasi UML. Scott Ambler[5] telah mengembangkan versi sederhana dari UP yang mengintegrasikan filosofi pemodelan agile-nya.[3]
- ^ Ambler, Scott. (2009). Agile modeling : effective practices for eXtreme programming and the unified process. J. Wiley & Sons. ISBN 9780471202820. OCLC 718657841.
- ^ "The Agile Modeling Home Page".
- ^ a b c d Pressman, Roger S. (2015). Software engineering : a practitioner's approach. McGraw-Hill Education. ISBN 9781259253157. OCLC 949696534.
- ^ a b c d e f g h i Ambler, S., “What Is Agile Modeling (AM)?” 2002, www.agilemodeling.com/index.htm.
- ^ Ambler, S., “The Agile Unified Process (AUP), 2006, available at www.ambysoft.com/unifiedprocess/agileUP.html.