Jump to content
 







Main menu
   


Navigation  



Main page
Contents
Current events
Random article
About Wikipedia
Contact us
Donate
 




Contribute  



Help
Learn to edit
Community portal
Recent changes
Upload file
 








Search  

































Create account

Log in
 









Create account
 Log in
 




Pages for logged out editors learn more  



Contributions
Talk
 



















Contents

   



(Top)
 


1 Core practices  



1.1  Documentation  





1.2  Modeling  







2 Limitations  





3 See also  





4 References  





5 External links  














Agile modeling






العربية
Bahasa Indonesia
Македонски
Nederlands
 

Edit links
 









Article
Talk
 

















Read
Edit
View history
 








Tools
   


Actions  



Read
Edit
View history
 




General  



What links here
Related changes
Upload file
Special pages
Permanent link
Page information
Cite this page
Get shortened URL
Download QR code
Wikidata item
 




Print/export  



Download as PDF
Printable version
 
















Appearance
   

 






From Wikipedia, the free encyclopedia
 


Agile modeling (AM) is a methodology for modeling and documenting software systems based on best practices. It is a collection of values and principles that can be applied on an (agile) software development project. This methodology is more flexible than traditional modeling methods, making it a better fit in a fast-changing environment.[1] It is part of the agile software development tool kit.

Agile modeling is a supplement to other agile development methodologies such as Scrum, extreme programming (XP), and Rational Unified Process (RUP). It is explicitly included as part of the disciplined agile delivery (DAD) framework. As per 2011 stats, agile modeling accounted for 1% of all agile software development.[2]

Agile modeling is one form of Agile model-driven engineering (Agile MDE), which has been adopted in several application areas such as web application development, finance, and automotive systems [3]

Core practices

[edit]

There are several core practices:

Documentation

[edit]
  1. Document continuously. Documentation is made throughout the life-cycle, in parallel to the creation of the rest of the solution.
  2. Document late. Documentation is made as late as possible, avoiding speculative ideas that are likely to change in favor of stable information.
  3. Executable specifications. Requirements are specified in the form of executable "customer tests", instead of non-executable "static" documentation.
  4. Single-source information. Information (models, documentation, software), is stored in one place and one place only, to prevent questions about what the "correct" version / information is.

Modeling

[edit]
  1. Active stakeholder participation. Stakeholders of the solution/software being modeled should be actively involved with doing so. This is an extension of the on-site customer practice from Extreme Programming.
  2. Architecture envisioning. The team performs light-weight, high-level modeling that is just barely good enough (JBGE) at the beginning of a software project so as to explore the architecture strategy that the team believes will work.
  3. Inclusive tools. Prefer modelling tools, such as whiteboards and paper, that are easy to work with (they're inclusive).
  4. Iteration modeling. When a requirement/work item has not been sufficiently explored in detail via look-ahead modeling the team may choose to do that exploration during their iteration/sprint planning session. The need to do this is generally seen as a symptom that the team is not doing sufficient look-ahead modeling.
  5. Just barely good enough (JBGE). All artifacts, including models and documents, should be just sufficient for the task at hand. JBGE is contextual in nature, in the case of the model it is determined by a combination of the complexity of whatever the model describes and the skills of the audience for that model.
  6. Look-ahead modeling. An agile team will look down their backlog one or more iterations/sprints ahead to ensure that a requirement/work item is ready to be worked on. Also called "backlog grooming" or "backlog refinement" in Scrum.
  7. Model storming. A short, often impromptu, agile modeling session. Model storming sessions are held to explore the details of a requirement or aspect of your design.
  8. Multiple models. Agile modelers should know how to create a range of model types (such as user stories, story maps, data models, Unified Modeling Language (UML) diagrams, and more) so as to apply the best model for the situation at hand.
  9. Prioritized requirements. Requirements should be worked on in priority order.
  10. Requirements envisioning. The team performs light-weight, high-level modeling that is JBGE at the beginning of a software project to explore the stakeholder requirements.

Limitations

[edit]

There is significant dependence on personal communication and customer collaboration. Agile modeling disciplines can be difficult to apply [citation needed]:

See also

[edit]

References

[edit]
  • ^ "State of Agile Development Survey Results, 2011". Archived from the original on 2015-07-17. Retrieved 2014-06-26.
  • ^ Alfraihi, Hessa Abdulrahman A.; Lano, Kevin Charles (January 2017). "The Integration of Agile Development and Model Driven Development: A Systematic Literature Review". The 5th International Conference on Model-Driven Engineering and Software Development: 451–458. doi:10.5220/0006207004510458. ISBN 978-989-758-210-3. S2CID 11369604.
  • [edit]
    Retrieved from "https://en.wikipedia.org/w/index.php?title=Agile_modeling&oldid=1184214283"

    Category: 
    Agile software development
    Hidden categories: 
    Articles with topics of unclear notability from November 2019
    All articles with topics of unclear notability
    Wikipedia articles with possible conflicts of interest from November 2019
    Articles lacking reliable references from November 2019
    All articles lacking reliable references
    Articles with multiple maintenance issues
    All articles with unsourced statements
    Articles with unsourced statements from October 2016
     



    This page was last edited on 9 November 2023, at 01:18 (UTC).

    Text is available under the Creative Commons Attribution-ShareAlike License 4.0; additional terms may apply. By using this site, you agree to the Terms of Use and Privacy Policy. Wikipedia® is a registered trademark of the Wikimedia Foundation, Inc., a non-profit organization.



    Privacy policy

    About Wikipedia

    Disclaimers

    Contact Wikipedia

    Code of Conduct

    Developers

    Statistics

    Cookie statement

    Mobile view



    Wikimedia Foundation
    Powered by MediaWiki