Agile modeling: Perbedaan antara revisi

Konten dihapus Konten ditambahkan

Sebaris

Revisi terkini sejak 12 Januari 2023 13.34

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 ⁱ 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.

[1] Ambler, Scott. (2009). Agile modeling : effective practices for eXtreme programming and the unified process. J. Wiley & Sons. ISBN 9780471202820. OCLC 718657841.

[2] "The Agile Modeling Home Page".

[:0-3] Pressman, Roger S. (2015). Software engineering : a practitioner's approach. McGraw-Hill Education. ISBN 9781259253157. OCLC 949696534.

[:1-4] ^ ^a ^b ^c ^d ^e ^f ^g ^h ⁱ Ambler, S., “What Is Agile Modeling (AM)?” 2002, www.agilemodeling.com/index.htm.

[5] Ambler, S., “The Agile Unified Process (AUP), 2006, available at www.ambysoft.com/unifiedprocess/agileUP.html.

[1]

[2]

[3]

[4]

[5]

@@ Baris 1: / Baris 1: @@
-'''''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 <ref>{{Cite book|title=Agile modeling : effective practices for eXtreme programming and the unified process|url=http://worldcat.org/oclc/718657841|publisher=J. Wiley & Sons|date=2009|isbn=9780471202820|oclc=718657841|last=Ambler, Scott.}}</ref>diterbitkan pada tahun 2002 oleh John Wiley Press. Ia juga memiliki situs web promosi<ref>{{Cite web|url=http://www.AgileModeling.com/|title=The Agile Modeling Home Page|last=|first=|date=|website=|access-date=}}</ref>.
+'''''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 <ref>{{Cite book|title=Agile modeling : effective practices for eXtreme programming and the unified process|url=http://worldcat.org/oclc/718657841|publisher=J. Wiley & Sons|date=2009|isbn=9780471202820|oclc=718657841|last=Ambler, Scott.}}</ref> diterbitkan pada tahun 2002 oleh John Wiley Press. Ia juga memiliki situs web promosi.<ref>{{Cite web|url=http://www.AgileModeling.com/|title=The Agile Modeling Home Page|last=|first=|date=|website=|access-date=}}</ref>
-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<ref name=":0">{{Cite book|title=Software engineering : a practitioner's approach|url=http://worldcat.org/oclc/949696534|publisher=McGraw-Hill Education|date=2015|isbn=9781259253157|oclc=949696534|last=Pressman, Roger S.}}</ref>.
+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.<ref name=":0">{{Cite book|title=Software engineering : a practitioner's approach|url=http://worldcat.org/oclc/949696534|publisher=McGraw-Hill Education|date=2015|isbn=9781259253157|oclc=949696534|last=Pressman, Roger S.}}</ref>
 Di situs resmi ''Agile Modelling,'' Scott Ambler <ref name=":1">Ambler, S., “What Is Agile Modeling (AM)?” 2002, www.agilemodeling.com/index.htm.</ref> 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."<ref name=":0" />
-''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<ref name=":0" />.
+''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.<ref name=":0" />
 == Prinsip ''Agile Modelling'' ==
-Meskipun ''Agile Modelling'' menyarankan beragam prinsip pemodelan ''“core”'' dan ''“supplementary”,'' yang membuat ''Agile Modelling'' menjadi unik adalah<ref name=":1" />:
+Meskipun ''Agile Modelling'' menyarankan beragam prinsip pemodelan ''“core”'' dan ''“supplementary”,'' yang membuat ''Agile Modelling'' menjadi unik adalah:<ref name=":1" />
 '''''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<ref name=":1" />.
+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.<ref name=":1" />
 '''''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<ref name=":1" />.
+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.<ref name=":1" />
 '''''Travel Light'''''
@@ Baris 24: / Baris 24: @@
 '''''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<ref name=":1" />.
+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.<ref name=":1" />
 '''''Know the models and the tools you use to create them'''''
-Pahami kekuatan dan kelemahan masing-masing model dan alat yang digunakan untuk membuatnya<ref name=":1" />.
+Pahami kekuatan dan kelemahan masing-masing model dan alat yang digunakan untuk membuatnya.<ref name=":1" />
 '''''Adapt Locally'''''
@@ Baris 34: / Baris 34: @@
 Pendekatan pemodelan harus disesuaikan dengan kebutuhan tim ''agile''<ref name=":1" />''.''
-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<ref>Ambler, S., “The Agile Unified Process (AUP), 2006, available at www.ambysoft.com/unifiedprocess/agileUP.html.</ref> telah mengembangkan versi sederhana dari UP yang mengintegrasikan filosofi pemodelan ''agile''-nya<ref name=":0" />.
+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<ref>Ambler, S., “The Agile Unified Process (AUP), 2006, available at www.ambysoft.com/unifiedprocess/agileUP.html.</ref> telah mengembangkan versi sederhana dari UP yang mengintegrasikan filosofi pemodelan ''agile''-nya.<ref name=":0" />
 [[Kategori:Agile development methods]]