Agile Modeling (AM) - Revision history

User at 00:04, 11 April 2023

2023-04-11T00:04:33Z

User: The LinkTitles extension automatically added links to existing pages (https://github.com/bovender/LinkTitles).

2021-02-06T13:39:55Z

The LinkTitles extension automatically added links to existing pages (https://github.com/bovender/LinkTitles).

User at 21:10, 28 November 2018

2018-11-28T21:10:57Z

User: Agile Modeling is a practice-based methodology for effective modeling and documentation of software-based systems.

2018-11-28T21:08:50Z

Agile Modeling is a practice-based methodology for effective modeling and documentation of software-based systems.

New page

Agile Modeling is a practice-based methodology for effective modeling and documentation of software-based systems. Simply put, Agile Modeling is a collection of values, principles, and practices for modeling software that can be applied on a software development project in an effective and light-weight manner. Agile Modeling is a supplement to other Agile Methodologies such as:
*Extreme Programming
*Select Perspective
*SCRUM<ref>Definition of Agile Modeling [^http://www.selectbs.com/process-maturity/what-is-agile-modeling|Selectbs]</ref>

The development of agile modeling was led by Scott Ambler starting in the autumn of 2000. It initially was called extreme modeling (XM) but at the suggestion of Robert Cecil Martin was renamed to AM in the spring of 2001.<ref>Historical background of Agile Modeling [https://en.wikipedia.org/wiki/Agile_modeling Wikipedia]</ref>

'''Agile Modeling Core Principles'''<ref>Agile Modeling Core Principles [https://www.umsl.edu/~sauterv/analysis/Fall2013Papers/Buric/agile-methodologies/agile-modeling.html umsl.edu]</ref><br />
*Model with a Purpose: Many developers worry about their work when they are creating models. What they are not doing is stepping back and asking why the're developing the models and who they are developing it for.
*Assume Simplicity: Keep models as simple as possible and assume the simplest solution is the best solution. Only model what you need today and trust that you can remodel later if needed.
*Embrace Change: Change happens on a project as understanding grows. Rather than fight changes to your models, accept them and have the courage to rebuild.
*Enabling the Next Effort is Your Secondary Goal: Others might need to extend or improve your project after you leave. Leave enough documentation and models to enable the next person or team to improve or make changes to the model.
*Incremental Change: It is very hard for a model to be complete the first time it's developed. Models change over time as the project develops. Always make small changes to models as required.
*Maximize Stakeholder Investment: The team must be in it to produce software to maximize return for the customer. The team must strive to develop software that meets the needs of the stakeholders.
*Multiple Models: There are many ways of modeling solutions; choose those that fit best according to the given situation.
*Quality Work: Nobody likes sloppy work. The people doing the work don't like it because it's something they can't be proud of, the people coming along later to refactor the work (for whatever reason) don't like it because it's harder to understand and to update, and the end users won't like the work because it's likely fragile and/or doesn't meet their expectations.
*Rapid Feedback: Getting quick feedback on the model will close the loop of understanding the model. The best process is to model a little, show the model for review and then model again. This insures accuracy of the model while increasing the developers own knowledge.
*Software is Your Primary Goal: Models are a means to the end; the en is to build software for your customer. Documentation and modeling must directly support the goal of software development.
*Travel Light: Traveling light means that you have just enough documentation about the models that you are developing. If it's too little documentation the developing team might loose its way; too much and the developing team will have forgotten that the primary goal is not writing documentation but software and building the right models.

'''Pros and Cons of Agie Modeling'''<ref>Pros and Cons of Agie Modeling [https://airbrake.io/blog/sdlc/agile-model Airbrake.io]</ref>

'''Pros of the Agile Model'''
*Emphasis of Modern Techniques: While a core value of the agile model places emphasis on people over technologies, stepping outside the realm of technologies themselves and into a pure focus on techniques brings about powerful, agile practices such as test-driven development, automated unit testing, refactoring, and iterative development.
*Highly Adaptive: As one of the fundamental agile values states, a key component to the agile model, and which partially makes it such a good launching pad for the entire software development life cycle, is the capability of the project to rapidly adapt to any necessary changes. Whether this is from rapid iterations informing the changing needs within the code or client feedback forcing a reshaping of the sign-up procedures, a properly Agile project is able to quickly and effectively change course as needed.
*Constant Customer Feedback: Although the constant communication with customers and clients requires a dedicated team member to take on this responsibility, it is a critical component to ensuring the success of the product from both a development perspective as well as from that of the client.
*Allows for Iterative Development: Common models like the Iterative Model are based on the fundamentals of the agile model, and for good reason: It allows the project to be started with relatively little upfront planning or cost. From these early components the project can evolve over time as new incremental iterations are made, constantly learning from past iterations and improving on them for future updates.

'''Cons of the Agile Model'''
*Potential for Increased Technical Debt: The concept of technical debt describes the act of implementing a solution that is easier to complete right now, in favor of the solution that may be better overall in the long run. Within the scope of the agile model, it is not uncommon for technical debt to begin to run rampant, as rapid development techniques and frequent iterations often mean developers feel hurried and thus forced to implement faster but generally less-than-ideal band-aids. This issue can largely be reduced by ensuring the team properly integrates refactoring, pair programming, and other techniques which emphasize collaboration amongst team members.
*Difficult to Make Additions Within an Iteration: Often referred to as use cases in other development models, a story in the agile model simply refers to a description of some new project requirements. When actively utilizing the agile model for an ongoing project, it can sometimes be difficult to implement a new story into the current iteration, since it forces backtracking and heavy mental overhead on how to implement the new requirements of this story into the existing iteration that has largely already being developed. In such cases, it is often necessary to delay the implementation of the new story until the next iteration comes about.
*Minimal Emphasis on Documentation: Unlike more traditional models like the Waterfall Model, the agile model largely forgoes initial efforts to heavily design and document the project requirements or scope, in favor of getting into the meat of the project and beginning that iterative process. This can be a challenge for some projects, particularly within development teams which may not be accustomed to this style of agile development and which may have more traditional experience instead.

'''Agile Modeling Best Practices'''<ref>Agile Modeling Best Practices [^http://www.agilemodeling.com/essays/introductionToAM.htm AM]</ref>
Another way to look at Agile Modeling is as a collection of best practices

[[File:Agile Modeling.jpg|300px|Agile Modeling]]<br />
source: [http://www.agilemodeling.com/essays/introductionToAM.htm Agile Modeling]

===References===
<references/>

===Further Reading===

@@ Line 1: / Line 1: @@
-Agile Modeling is a practice-based [[methodology]] for effective modeling and documentation of [[software]]-based systems. Simply put, Agile Modeling is a collection of values, principles, and practices for modeling software that can be applied on a software development project in an effective and light-weight manner. Agile Modeling is a supplement to other Agile Methodologies such as:
+'''Agile Modeling''' is a practice-based methodology for effective modeling and documentation of software-based systems. Simply put, Agile Modeling is a collection of values, principles, and practices for modeling software that can be applied to a software development project in an effective and lightweight manner. Agile Modeling is a supplement to other Agile Methodologies, such as:
 *Extreme Programming
 *Select Perspective
-*[[SCRUM]]<ref>Definition of Agile Modeling [^http://www.selectbs.com/process-maturity/what-is-agile-modeling|Selectbs]</ref>
+*SCRUM<ref>[http://www.selectbs.com/process-maturity/what-is-agile-modeling Definition of Agile Modeling]</ref>
-The development of agile modeling was led by Scott Ambler starting in the autumn of 2000. It initially was called extreme modeling (XM) but at the suggestion of Robert Cecil Martin was renamed to AM in the spring of 2001.<ref>Historical background of Agile Modeling [https://en.wikipedia.org/wiki/Agile_modeling Wikipedia]</ref>
+The development of agile modeling was led by Scott Ambler starting in the autumn of 2000. It initially was called extreme modeling (XM), but at the suggestion of Robert Cecil Martin was renamed AM in the spring of 2001.<ref>[https://en.wikipedia.org/wiki/Agile_modeling Historical background of Agile Modeling ]</ref>
-'''Agile Modeling Core Principles'''<ref>Agile Modeling Core Principles [https://www.umsl.edu/~sauterv/analysis/Fall2013Papers/Buric/agile-methodologies/agile-modeling.html umsl.edu]</ref><br />
+'''Agile Modeling Core Principles'''<ref>[https://www.umsl.edu/~sauterv/analysis/Fall2013Papers/Buric/agile-methodologies/agile-modeling.html Agile Modeling Core Principles]</ref><br />
-*[[Model]] with a Purpose: Many developers worry about their work when they are creating models. What they are not doing is stepping back and asking why the're developing the models and who they are developing it for.
+*Model with a Purpose: Many developers worry about their work when creating models. What they are not doing is stepping back and asking why they're developing the models and who they are developing them for.
 *Assume Simplicity: Keep models as simple as possible and assume the simplest solution is the best solution. Only model what you need today and trust that you can remodel later if needed.
 *Embrace Change: Change happens on a project as understanding grows. Rather than fight changes to your models, accept them and have the courage to rebuild.
-*Enabling the Next Effort is Your Secondary Goal: Others might need to extend or improve your project after you leave. Leave enough documentation and models to enable the next person or team to improve or make changes to the model.
+*Enabling the Next Effort is Your Secondary Goal: Others might need to extend or improve your project after you leave. Leave enough documentation and models to enable the next person or team to improve or change the model.
 *Incremental Change: It is very hard for a model to be complete the first time it's developed. Models change over time as the project develops. Always make small changes to models as required.
-*Maximize [[Stakeholder]] Investment: The team must be in it to produce software to maximize return for the [[customer]]. The team must strive to develop software that meets the needs of the stakeholders.
+*Maximize Stakeholder Investment: The team must be in it to produce software to maximize return for the customer. The team must strive to develop software that meets the needs of the stakeholders.
-*Multiple Models: There are many ways of modeling solutions; choose those that fit best according to the given situation.
+*Multiple Models: There are many ways of modeling solutions; choose the best fit according to the given situation.
-*[[Quality]] Work:  Nobody likes sloppy work. The people doing the work don't like it because it's something they can't be proud of, the people coming along later to refactor the work (for whatever reason) don't like it because it's harder to understand and to update, and the end users won't like the work because it's likely fragile and/or doesn't meet their expectations.
+*Quality Work:  Nobody likes sloppy work. The people doing the work don't like it because it's something they can't be proud of, and the people coming along later to refactor the work (for whatever reason) don't like it because it's harder to understand and to update. The end users won't like the work because it's likely fragile and/or doesn't meet their expectations.
-*Rapid [[Feedback]]: Getting quick feedback on the model will close the loop of understanding the model. The best [[process]] is to model a little, show the model for review and then model again. This insures accuracy of the model while increasing the developers own knowledge.
+*Rapid Feedback: Getting quick feedback on the model will close the loop of understanding the model. The best process is to model a little, show the model for review, and then model again. This ensures the accuracy of the model while increasing the developers' own knowledge.
 *Software is Your Primary Goal: Models are a means to the end; the en is to build software for your customer. Documentation and modeling must directly support the goal of software development.
-*Travel Light: Traveling light means that you have just enough documentation about the models that you are developing. If it's too little documentation the developing team might loose its way; too much and the developing team will have forgotten that the primary goal is not writing documentation but software and building the right models.
+*Travel Light: Traveling light means that you have just enough documentation about the models that you are developing. If it's too little documentation, the developing team might lose its way; too much and the developing team will have forgotten that the primary goal is not writing documentation but software and building the right models.
-'''Pros and Cons of Agie Modeling'''<ref>Pros and Cons of Agie Modeling [https://airbrake.io/blog/sdlc/agile-model Airbrake.io]</ref><br />
+'''Pros and Cons of Agie Modeling'''<ref>[https://airbrake.io/blog/sdlc/agile-model Pros and Cons of Agie Modeling]</ref><br />
 '''Pros of the Agile Model'''
-*Emphasis of Modern Techniques: While a core [[value]] of the agile model places emphasis on people over technologies, stepping outside the realm of technologies themselves and into a pure focus on techniques brings about powerful, agile practices such as test-driven development, automated unit testing, refactoring, and iterative development.
+*Emphasis of Modern Techniques: While a core value of the agile model places emphasis on people over technologies, stepping outside the realm of technologies themselves and into a pure focus on techniques brings about powerful, agile practices such as test-driven development, automated unit testing, refactoring, and iterative development.
-*Highly Adaptive: As one of the fundamental agile values states, a key component to the agile model, and which partially makes it such a good launching pad for the entire software development life cycle, is the capability of the project to rapidly adapt to any necessary changes. Whether this is from rapid iterations informing the changing needs within the code or client feedback forcing a reshaping of the sign-up procedures, a properly Agile project is able to quickly and effectively change course as needed.
+*Highly Adaptive: As one of the fundamental agile values states, a key component to the agile model, and which partially makes it such a good launching pad for the entire software development life cycle, is the capability of the project to rapidly adapt to any necessary changes. Whether this is from rapid iterations informing the changing needs within the code or client feedback forcing a reshaping of the sign-up procedures, a properly Agile project can quickly and effectively change course as needed.
-*Constant Customer Feedback: Although the constant communication with customers and clients requires a dedicated team member to take on this responsibility, it is a critical component to ensuring the success of the [[product]] from both a development perspective as well as from that of the client.
+*Constant Customer Feedback: Although constant communication with customers and clients requires a dedicated team member to take on this responsibility, it is a critical component to ensuring the success of the product from both a development perspective as well as from that of the client.
-*Allows for [[Iterative Development]]: Common models like the Iterative Model are based on the fundamentals of the agile model, and for good reason: It allows the project to be started with relatively little upfront planning or cost. From these early components the project can evolve over time as new incremental iterations are made, constantly learning from past iterations and improving on them for future updates.
+*Allows for Iterative Development: Common models like the Iterative Model are based on the fundamentals of the agile model. For good reason: It allows the project to be started with relatively little upfront planning or cost. From these early components, the project can evolve over time as new incremental iterations are made, constantly learning from past iterations and improving on them for future updates.
 '''Cons of the Agile Model'''
-*Potential for Increased Technical Debt: The concept of technical debt describes the act of implementing a solution that is easier to complete right now, in favor of the solution that may be better overall in the long run. Within the scope of the agile model, it is not uncommon for technical debt to begin to run rampant, as rapid development techniques and frequent iterations often mean developers feel hurried and thus forced to implement faster but generally less-than-ideal band-aids. This issue can largely be reduced by ensuring the team properly integrates refactoring, pair programming, and other techniques which emphasize [[collaboration]] amongst team members.
+*Potential for Increased Technical Debt: The concept of technical debt describes the act of implementing a solution that is easier to complete right now in favor of a solution that may be better overall in the long run. Within the scope of the agile model, it is not uncommon for technical debt to begin to run rampant, as rapid development techniques and frequent iterations often mean developers feel hurried and thus forced to implement faster but generally less-than-ideal band-aids. This issue can largely be reduced by ensuring the team properly integrates refactoring, pair programming, and other techniques emphasizing collaboration amongst team members.
-*Difficult to Make Additions Within an Iteration: Often referred to as use cases in other development models, a story in the agile model simply refers to a description of some new project requirements. When actively utilizing the agile model for an ongoing project, it can sometimes be difficult to implement a new story into the current iteration, since it forces backtracking and heavy mental overhead on how to implement the new requirements of this story into the existing iteration that has largely already being developed. In such cases, it is often necessary to delay the implementation of the new story until the next iteration comes about.
+*Difficult to Make Additions Within an Iteration: Often referred to as use cases in other development models, a story in the agile model simply refers to a description of some new project requirements. When actively utilizing the agile model for an ongoing project, it can sometimes be difficult to implement a new story into the current iteration since it forces backtracking and heavy mental overhead on how to implement the new requirements of this story into the existing iteration that has largely already been developed. In such cases, it is often necessary to delay the implementation of the new story until the next iteration comes about.
-*Minimal Emphasis on Documentation: Unlike more traditional models like the [[Waterfall Model]], the agile model largely forgoes initial efforts to heavily [[design]] and document the project requirements or scope, in favor of getting into the meat of the project and beginning that iterative process. This can be a challenge for some projects, particularly within development teams which may not be accustomed to this style of agile development and which may have more traditional experience instead.
+*Minimal Emphasis on Documentation: Unlike more traditional models like the Waterfall Model, the agile model largely forgoes initial efforts to heavily design and document the project requirements or scope in favor of getting into the meat of the project and beginning that iterative process. This can be a challenge for some projects, particularly within development teams that may not be accustomed to this style of agile development and which may have more traditional experience instead.
-'''Agile Modeling Best Practices'''<ref>Agile Modeling Best Practices [^http://www.agilemodeling.com/essays/introductionToAM.htm AM]</ref><br />
+'''Agile Modeling Best Practices'''<ref>[http://www.agilemodeling.com/essays/introductionToAM.htm Agile Modeling Best Practices ]</ref><br />
-Another way to look at Agile Modeling is as a collection of best practices
+Another way to look at Agile Modeling is as a collection of best practices.
 [[File:Agile Modeling.jpg|500px|Agile Modeling]]<br />
-source: [http://www.agilemodeling.com/essays/introductionToAM.htm Agile Modeling]
+source: Agile Modeling
-===References===
+== See Also ==
 <references/>
+__NOTOC__
 ===Further Reading===