# Agile Modeling Home - The Agile Modeling (AM) Method > Markdown mirror of DialtoneApp's public top-site detail page for `agilemodeling.com`. URL: https://dialtoneapp.com/top-sites/agilemodeling.com/index.md Canonical HTML: https://dialtoneapp.com/top-sites/agilemodeling.com ## Summary - Domain: `agilemodeling.com` - Website: https://agilemodeling.com - Description: ai readable | score 20 | purchase read only - Label: ai_readable - Payment surface: Not available - Purchase boundary: read_only - Control boundary: unknown - Rank: 401173 ## robots ~~~text User-agent: * Disallow: /wp-admin/ Allow: /wp-admin/admin-ajax.php Disallow: /wp-content/uploads/wpo/wpo-plugins-tables-list.json Sitemap: https://agilemodeling.com/sitemap.xml Sitemap: https://agilemodeling.com/sitemap.rss ~~~ ## llms ~~~text Generated by All in One SEO v4.9.6.2, this is an llms.txt file, used by LLMs to index the site. # The Agile Modeling (AM) Method Effective Strategies for Modeling and Documentation ## Sitemaps - [XML Sitemap](https://agilemodeling.com/sitemap.xml): Contains all public & indexable URLs for this website. ## Pages - [Agile Modeling Home](https://agilemodeling.com/) - The Agile Modeling Mission is to share proven and effective strategies for modeling and documentation. - [Personas: An Agile Introduction](https://agilemodeling.com/artifacts/personas.htm) - Personas define archetypal users of a system, examples of the kind of people who interact with it. Personas enable you to contextualize other requirements. - [Active Stakeholder Participation: An Agile Core Practice](https://agilemodeling.com/essays/activestakeholderparticipation.htm) - Active stakeholder participation is the practice of readily including, and involving, stakeholders with both knowledge and decision making authority. - [The Values of Agile Modeling (AM)](https://agilemodeling.com/values.htm) - There are five values of Agile Modeling: communication, simplicity, feedback, courage, and humility. These values provide a basis for AM's principles. - [The Principles of Agile Modeling (AM)](https://agilemodeling.com/principles.htm) - Agile Modeling (AM) defines a collection of principles that set the stage for effective modeling and documentation practices on agile software teams. - [The Practices of Agile Modeling (AM)](https://agilemodeling.com/practices.htm) - The AM practices are organized into two types, core practices that are highly recommended and supplementary practices that you adopt as needed. - [UML Use Case Diagrams: Diagramming Guidelines](https://agilemodeling.com/style/usecasediagram.htm) - UML Use Case Diagrams: Diagramming Guidelines A use case diagram is "a diagram that shows the relationships among actors and use cases within a system. "Use case diagrams are often used to: Provide an overview of all or part of the usage requirements for a system or organization in the form of an essential model or a business model - [UML Stereotypes: Diagramming Style Guidelines](https://agilemodeling.com/style/stereotype.htm) - UML Stereotypes: Diagramming Style Guidelines A stereotype denotes a variation on an existing modeling element with the same form but with a modified intent. Stereotypes are effectively used to extend the UML in a consistent manner.Figure 1. Indicating stereotypes.Figure 2. A frame encompassing a sequence diagram. Name Stereotypes in and format. List Stereotypes Last. In Figure 1 the - [UML State Machine Diagrams: Diagramming Guidelines](https://agilemodeling.com/style/statechartdiagram.htm) - UML State Machine Diagrams: Diagramming Guidelines UML state machine diagrams, formerly called state chart diagrams in UML 1, depict the dynamic behavior of an entity based on its response to events, showing how the entity reacts to various events depending on the current state that it is in. Create a UML state machine diagram to explore the - [UML Sequence Diagrams: Diagramming Guidelines](https://agilemodeling.com/style/sequencediagram.htm) - UML Sequence Diagrams: Diagramming Guidelines UML Sequence diagrams are a dynamic modeling technique, as are collaboration diagrams and activity diagrams. UML sequence diagrams are typically used to: Validate and flesh out the logic of a usage scenario. A usage scenario is exactly what its name indicates - the description of a potential way that your system is used. The logic of - [UML Package Diagrams: Diagramming Guidelines](https://agilemodeling.com/style/packagediagram.htm) - UML package diagrams are composed only of packages and the dependencies between them. A package organizes model elements into groupings. - [UML Notes: Diagramming Style Guidelines](https://agilemodeling.com/style/note.htm) - UML notes are modeling constructs for adding textual information - such as a comment, constraint definition, or method body - to UML diagrams. - [UML Interfaces: Diagramming Style Guidelines](https://agilemodeling.com/style/interface.htm) - UML interfaces are collections of operation signatures and/or attribute definitions that ideally defines a cohesive set of behaviours. - [UML Frames: Diagramming Style Guidelines](https://agilemodeling.com/style/frame.htm) - UML frames are model constructs that encapsulate a collection of collaborating instances or refers to another representation of such. - [UML Deployment Diagram: Diagramming Guidelines](https://agilemodeling.com/style/deploymentdiagram.htm) - UML deployment diagrams show the hardware, the software installed on that hardware, and the middleware used to connect your system together. - [UML Component Diagram: Diagramming Guidelines](https://agilemodeling.com/style/componentdiagram.htm) - A UML component diagram shows the dependencies among software components, including the classifiers that specify them and the artifacts that implement them. - [UML Communication Diagram: Diagramming Guidelines](https://agilemodeling.com/style/collaborationdiagram.htm) - UML communication diagrams are used to explore the dynamic nature of your software. They show the message flow between objects in an OO application. - [UML Activity Diagram: Diagramming Guidelines](https://agilemodeling.com/style/activitydiagram.htm) - In many ways UML Activity diagrams are the object-oriented equivalent of flow charts and data-flow diagrams (DFDs). - [UML Class Diagrams: Diagramming Guidelines](https://agilemodeling.com/style/classdiagram.htm) - UML class diagrams show the classes of the system, their inter-relationships, and the operations and attributes of the classes. - [General Diagramming Guidelines](https://agilemodeling.com/style/general.htm) - The diagramming guidelines presented here are applicable to all types of diagrams and are not specific to a single type of diagram. - [Modeling Style Guidelines: Strategies for Better Diagrams](https://agilemodeling.com/style.htm) - Modeling style guidelines to improve the quality and readability of your software diagrams, making them easier to understand and to work with. - [User Stories: An Agile Introduction](https://agilemodeling.com/artifacts/userstory.htm) - User stories are very high-level definitions of a requirement, containing just enough information so that the developers can produce a reasonable estimate. - [User Interface Flow Diagrams (UI Storyboards): An Agile Introduction](https://agilemodeling.com/artifacts/uiflowdiagram.htm) - User interface-flow diagrams enable you to model the high-level relationships between major UI elements and thereby ask fundamental usability questions. - [User Interface (UI) Prototypes: An Agile Introduction](https://agilemodeling.com/artifacts/uiprototype.htm) - User interface (UI) prototyping is an iterative analysis technique in which users are actively involved in the mocking-up of the UI for a system. - [Usage Scenarios: An Agile Introduction](https://agilemodeling.com/artifacts/usagescenario.htm) - Usage scenarios describe real-world examples of how one or more people or organizations interact with a system. - [UML Use Case Diagrams: An Agile Introduction](https://agilemodeling.com/artifacts/usecasediagram.htm) - UML use case diagrams overview the usage requirements for a system. The diagrams are useful for presentations and the use cases capture the details. - [UML Timing Diagrams: An Agile Introduction](https://agilemodeling.com/artifacts/timingdiagram.htm) - Timing diagrams are used to explore the behaviors of one or more objects throughout a given period of time, particularly for embedded software development. - [UML State Machine Diagrams: An Agile Introduction](https://agilemodeling.com/artifacts/statemachinediagram.htm) - UML state machine diagrams depict the various states that an object may be in and the transitions between those states. Also called a state-transition diagram. - [UML Sequence Diagrams: An Agile Introduction](https://agilemodeling.com/artifacts/sequencediagram.htm) - UML sequence diagrams model the flow of logic within your system in a visual manner, enabling you both to document and validate your logic. - [UML Package Diagrams: An Agile Introduction](https://agilemodeling.com/artifacts/packagediagram.htm) - Packages are UML constructs that enable you to organize model elements into groups, making your UML diagrams simpler and easier to understand. - [UML Object Diagrams: An Agile Introduction](https://agilemodeling.com/artifacts/objectdiagram.htm) - UML 2 object diagrams, sometimes referred to as instance diagrams, are used for exploring "real world" examples of objects and the relationships between them. - [UML Interaction Overview Diagrams: An Agile Introduction](https://agilemodeling.com/artifacts/interactionoverviewdiagram.htm) - ML 2 interaction overview diagrams are variants on UML activity diagrams which overview control flow. - [UML Deployment Diagrams: An Agile Introduction](https://agilemodeling.com/artifacts/deploymentdiagram.htm) - UML deployment diagrams show the hardware, the software that is installed on that hardware, and the middleware used to connect the system. - [UML Composite Structure Diagrams: An Agile Introduction](https://agilemodeling.com/artifacts/compositestructurediagram.htm) - UML composite structure diagrams are used to explore run-time instances of interconnected instances collaborating over communications links. - [UML Component Diagrams: An Agile Introduction](https://agilemodeling.com/artifacts/componentdiagram.htm) - UML component diagrams are an architecture-level artifact, used to model the business software architecture, the technical software architecture, or both. - [UML Communication Diagrams: An Agile Introduction](https://agilemodeling.com/artifacts/communicationdiagram.htm) - UML communication diagrams show the message flow between objects in an OO application and also imply the basic associations (relationships) between classes. - [UML Class Diagrams: An Agile Introduction](https://agilemodeling.com/artifacts/classdiagram.htm) - UML class diagrams show the classes of the system, their interrelationships ( inheritance, aggregation, and association), and their operations and attributes. - [UML Activity Diagrams: An Agile Introduction](https://agilemodeling.com/artifacts/activitydiagram.htm) - UML activity diagrams are typically used for business process modeling or for modeling the logic captured by use case, usage scenario, or business rule. - [System Use Cases: An Agile Introduction](https://agilemodeling.com/artifacts/systemusecase.htm) - Use cases are a sequence of actions that provide a measurable value to an actor. System use cases include high-level implementation decisions. - [Security Threat Models: An Agile Introduction](https://agilemodeling.com/artifacts/securitythreatmodel.htm) - Security threat models enable you to understand a system's threat profile by examining it through the eyes of your potential foes. - [Robustness Diagrams: An Agile Introduction](https://agilemodeling.com/artifacts/robustnessdiagram.htm) - Robustness diagrams are basically simplified UML communication/collaboration diagrams that use intuitive graphical symbols to visualize use case logic. - [Quality of Service (QoS) Requirements: An Agile Introduction](https://agilemodeling.com/artifacts/technicalrequirement.htm) - A quality of service (QoS) requirement pertains to the technical constraints that your solution must fulfill. - [Physical Data Models (PDM)s: An Agile Introduction](https://agilemodeling.com/artifacts/physicaldatamodel.htm) - Physical data models capture the design the internal schema of a database, depicting the data tables, their data columns, and their relationships. - [Object Role Model (ORM) Diagrams: An Agile Introduction](https://agilemodeling.com/artifacts/ormdiagram.htm) - ORM diagrams are a straightforward and incredibly effective way to explore domain concepts with your stakeholders. - [Network Diagrams: An Agile Introduction](https://agilemodeling.com/artifacts/networkdiagram.htm) - Network diagrams are commonly used to depict hardware nodes as well as the connections between them. They are effectively high-level UML deployment diagrams. - [Low-Fidelity (Paper) User Interface Prototypes: An Agile Introduction](https://agilemodeling.com/artifacts/essentialui.htm) - A low-fidelity user interface prototype, also known as an abstract prototype or paper prototype, is a simple model, or prototype, of the UI for your system. - [Glossaries: An Agile Introduction](https://agilemodeling.com/artifacts/glossary.htm) - Glossaries are collections of defined terms. Every company has its own specialized jargon, and you need to understand it to communicate effectively. - [Free-Form Diagrams: An Agile Introduction](https://agilemodeling.com/artifacts/freeform.htm) - One of the most useful, and most common, type of model is a free-form diagram. - [Flow Charts: An Agile Introduction](https://agilemodeling.com/artifacts/flowchart.htm) - Flow charts are a modeling technique introduced in the 1940/50s and popularized for structured development in the 1970s as well as business modeling. - [Features: An Agile Introduction](https://agilemodeling.com/artifacts/feature.htm) - Features are small, client-valued functionality expressed in the form Action Subject Object. Features are very small and can be implemented within a few hours. - [Data Flow Diagram (DFD)s: An Agile Introduction](https://agilemodeling.com/artifacts/dataflowdiagram.htm) - Data flow diagrams (DFDs) show the flow of data from external entities into the system, how the data moved from one process to another, and its logical storage. - [Contract Models: Agile API Documentation](https://agilemodeling.com/artifacts/contractmodel.htm) - When you discover that your system requires access to an information resource then you need a "contract model", an external spec, in place to describe it. - [Constraints: An Agile Introduction](https://agilemodeling.com/artifacts/constraint.htm) - Constraints are effectively global requirements, such as limited development resources or a decision that restricts the way you develop a system. - [Class Responsibility Collaborator (CRC) Cards: An Agile Intro](https://agilemodeling.com/artifacts/crcmodel.htm) - A Class Responsibility Collaborator (CRC) model is a collection of CRC cards that capture the name of the class, it's responsibilities, and its collaborators. - [Change Cases: An Agile Introduction](https://agilemodeling.com/artifacts/changecase.htm) - Change cases describe a potential change to your existing requirements, indicating the likeliness and potential impact of that chang. - [Business Use Cases: An Agile Introduction](https://agilemodeling.com/artifacts/essentialusecase.htm) - A business use case, is a simplified, abstract, generalized use case that captures the intentions of a user in an implementation independent manner. - [Business Rules: An Agile Introduction](https://agilemodeling.com/artifacts/businessrule.htm) - Business rules define or constrain one aspect of your business that is intended to assert business structure or influence the behavior of your business. - [Acceptance Tests as Requirements Artifacts: An Agile Introduction](https://agilemodeling.com/artifacts/acceptancetests.htm) - Acceptance tests (also called Customer tests or Customer Acceptance Tests) describe stakeholder requirements that your system must conform to. - [Agile Models Distilled: Potential Artifacts for Agile Modeling](https://agilemodeling.com/artifacts.htm) - This page links to summary descriptions of a wide variety of types of agile models, categorizing them by their potential usage. - [Agile Modeling: Frequently Asked Questions (FAQ)](https://agilemodeling.com/faq.htm) - This page addresses frequently asked questions about the Agile Modeling (AM) method. - [XP and UML? Clearly the Wrong Question to be Asking](https://agilemodeling.com/essays/xpuml.htm) - Unified Modeling Language (UML) can be, and has been, applied effectively by Extreme Programming (XP) teams. - [Why Extend the UML Beyond Object and Component Technology?](https://agilemodeling.com/essays/extendingtheuml.htm) - Extending the UML beyond object and component technology is important to the IT industry because we need to be able to apply it for what we actually do. - [When Does(n't) Agile Modeling Make Sense?](https://agilemodeling.com/essays/whendoesamwork.htm) - Agile Modeling isn't going to work for everybody, it isn't a panacea that works in every situation, but it does work in the vast majority of cases. - [When Are(n't) You Agile Modeling (AM)?](https://agilemodeling.com/essays/whenareyouagilemodeling.htm) - One of the biggest challenges that agile development methods face is developers claiming to be following the method, when in reality they aren't. - [What Is(n't) Agile Modeling?](https://agilemodeling.com/essays/whatisam.htm) - Agile Modeling (AM) is a way of thinking (WoT) and a way of working (WoW) that is tailored into your existing process to improve modeling and documentation. - [Tips for Whiteboard Modeling](https://agilemodeling.com/essays/whiteboards.htm) - Whiteboards are commonly used to model software details. You will want to develop your own set of rules and guidelines for whiteboard modeling. - [The Product Owner Role: A Stakeholder Proxy for Agile Teams](https://agilemodeling.com/essays/productowner.htm) - The primary goal of a product owner is to represent the needs and desires of the stakeholder community to an agile delivery team, being the first source of information about the problem domain for the team. - [The Art of Stakeholder Presentations](https://agilemodeling.com/essays/presentations.htm) - Stakeholder presentations to stakeholders are a reality on most software initiatives, and agile models can and should be a part of your presentations. - [The Architecture Owner Role: How Architects Fit in on Agile Teams](https://agilemodeling.com/essays/architectureowner.htm) - Many agile teams find that they need someone in the role of "architecture owner", often the most technically experienced person on the team, who is responsible for facilitating the architectural modeling and evolution efforts. - [The Agile Modeling (AM) Logo](https://agilemodeling.com/essays/amlogo.htm) - Let's explore two important topics regarding the Agile Modeling logo: Using the AM Logo in Your Publication and the Symbolism Behind the AM Logo. - [Stakeholders of Software Development Teams](https://agilemodeling.com/essays/stakeholders.htm) - A stakeholder is anyone who is materially impacted by the outcome of an initiative. - [Software Modeling on Plain Old Whiteboards (POWs)](https://agilemodeling.com/essays/whiteboardmodeling.htm) - A "plain old whiteboard (POW)" is my favorite modeling tool. Whiteboards are the modeling tool with the greatest install base worldwide. - [Software Development Phases:Traditional Phases Make No Sense](https://agilemodeling.com/essays/phasesexamined.htm) - Instead of spending time in a "Requirements Phase", then a "Analysis Phase", then a "Design Phase" it is far more common to iterate back and forth between these activities. - [Single Source Information: An Agile Core Practice for Effective Documentation](https://agilemodeling.com/essays/singlesourceinformation.htm) - In agile software development you want to travel as light as possible, and the easiest way to do that is to choose the best artifact to record information. - [Reuse in Use-Case Models: Extends, Includes, and Inheritance](https://agilemodeling.com/essays/usecasereuse.htm) - Potential reuse can be model through four generalization relationships supported by UML use-case models: extends, includes, and inherits (UC and actor). - [Rethinking Modeling Sessions: Applying Agile WoT](https://agilemodeling.com/essays/modelingsessions.htm) - Modeling sessions are an important part of any software development effort because they provide an opportunity for people to collaborate together in order to communicate their needs, to come to a better understanding, and ideally to work towards a solution. - [Response to "Are You Passing The Requirements Buck"](https://agilemodeling.com/essays/passingthebuck.htm) - A discussion in 2003 regarding the realities of agile requirements modeling. - [Requirements Envisioning: An Agile Core Practice](https://agilemodeling.com/essays/initialrequirementsmodeling.htm) - A common agile practice is to perform some high-level requirements envisioning early in the lifecycle to come to a common understanding of the scope. - [Prioritized Requirements: An Agile Core Practice](https://agilemodeling.com/essays/prioritizedrequirements.htm) - Prioritized requirements: A critical strategy for developing high-value software is to implement the highest priority requirements first. - [Overcoming Requirements Modeling Challenges](https://agilemodeling.com/essays/requirementschallenges.htm) - There are common challenges, and potential solutions to address those challenges, that software teams face when it comes to requirements modeling. - [Obeya Room: Organizing an Agile Work Room](https://agilemodeling.com/essays/agilemodelingroom.htm) - An Obeya room, or agile modeling room, is a large space with lots of whiteboard (or blackboard) space upon which to sketch and share ideas. - [Model Storming: An Agile Core Practice](https://agilemodeling.com/essays/modelstorming.htm) - Model storming is just in time (JIT) modeling: you identify an issue which you need to resolve, you quickly form a group and the group explores the issue. - [Model Reviews: Best Practice or Process Smell?](https://agilemodeling.com/essays/modelreviews.htm) - A model review, also called a model walkthrough or inspection, is a validation technique in which your model is examined critically by a group of your peers. - [Model Driven Architecture (MDA): Are You Ready?](https://agilemodeling.com/essays/readyformda.htm) - The Object Management Group (OMG)'s Model-Driven Architecture (MDA), to be successful, requires that your organization overcomes many difficult challenges. - [Look-Ahead Modeling: An Agile Core Practice](https://agilemodeling.com/essays/modelahead.htm) - With look-ahead modeling you gather information, explore requirements, and think through the details before you implement the software. - [Lean/Agile Documentation: Strategies for Agile Teams](https://agilemodeling.com/essays/agiledocumentation.htm) - This is the original article about agile documentation for agile software development and the strategies to develop and evolve the documentation efficiently. - [Just Barely Good Enough (JBGE) Artifacts: An Agile Core Practice](https://agilemodeling.com/essays/barelygoodenough.htm) - Agile models and agile documents are sufficient for the task at hand, or as agilists like to say they are just barely good enough (JBGE). - [JBGE: When is an Artifact Just Barely Good Enough (JBGE)?](https://agilemodeling.com/essays/barelygoodenoughwhen.htm) - Artifacts, such as agile models and agile documents should be sufficient for the task at hand, and no more. They should be just barely good enough(JBGE). - [Iteration/Sprint Modeling: An Agile Core Practice](https://agilemodeling.com/essays/iterationmodeling.htm) - Sprint modeling is an important aspect of sprint planning, because to estimate each requirement you must understand the work required to implement it. - [Iterate To Another Artifact: How to Avoid Analysis Paralysis](https://agilemodeling.com/essays/iteratetoanotherartifact.htm) - The basic idea of the Iterate to Another Artifact practice is that if you find yourself stuck when working on one thing then stop and work on something else. - [It's "Use the Simplest Tool" not "Use Simple Tools"](https://agilemodeling.com/essays/simpletools.htm) - Agile Modeling's advice is to use the simplest tool that works for your context: often that is an inclusive tool such as paper or a whiteboard, but not always. - [Introduction to the Diagrams of UML 2.X](https://agilemodeling.com/essays/umldiagrams.htm) - Understanding the diagrams of UML is an important part of understanding object orientation. The UML defines the object modeling industry standard. - [Introduction to Agile Usability: User Experience on Agile Teams](https://agilemodeling.com/essays/agileusability.htm) - User experience (UX) and agile practitioners can and should actively find ways to work together and to learn from one another. This is how. - [Interviewing Tips and Techniques for IT Professionals](https://agilemodeling.com/essays/interviewing.htm) - Interviewing is a skill that takes years to master, one that is critical for eliciting requirements from your stakeholders. - [Initial Agile Envisioning: Get Going in the Right Direction](https://agilemodeling.com/essays/agile-envisioning.htm) - Agile teams, at least the disciplined ones, explicitly invest time in initiation activities including both requirements and architecture envisioning. - [Inclusive Modeling: User-Centered Approaches for Agile Software Development](https://agilemodeling.com/essays/inclusivemodels.htm) - The key to active stakeholder participation on agile software development teams is to adopt inclusive models that use simple tools and simple techniques. - [How the Agile Modeling Practices Fit Together](https://agilemodeling.com/essays/practicesfittogether.htm) - The practices of AM are synergistic because they support and sometimes even enable one another. They are generative because you can tailor them into your WoW. - [How Much Modeling Should You Do? Just Enough](https://agilemodeling.com/essays/barelygoodenoughhowmuch.htm) - "How much modeling should you do?" The quick answer is less than you likely think. The amount of modeling that you require depends on the context that you face. - [How Can Enterprise IT Professionals Be Agile?](https://agilemodeling.com/essays/enterpriseagility.htm) - The way that enterprise IT professionals organize themselves and work with their customers can and should be agile. - [Generalizing Specialists: Thrive in the Age of AI](https://agilemodeling.com/essays/generalizingspecialists.htm) - Generalizing specialists have one or more specialized skills, a general knowledge of their profession and business domain, and actively seek to gain new skills. - [From Extreme Modeling (XM) to Agile Modeling (AM)](https://agilemodeling.com/essays/namechange.htm) - As the result of several very good conversations, as of March 10 2001 eXtreme Modeling (XM) is renamed to Agile Modeling (AM). - [Executable Specifications: An Agile Core Practice](https://agilemodeling.com/essays/executablespecifications.htm) - With test-driven development (TDD) your tests effectively become executable specifications which are created on a just-in-time (JIT) basis. - [Examining the Model Driven Architecture (MDA)](https://agilemodeling.com/essays/mda.htm) - The Model-Driven Architecture (MDA) defines an approach to modeling that separates the specification of system functionality from the its implementation. - [Examining the Agile Cost of Change Curve](https://agilemodeling.com/essays/costofchange.htm) - In software development the cost of fixing errors increases exponentially the later they are detected in the development lifecycle . - [Examining the "Big Requirements Up Front (BRUF) Approach"](https://agilemodeling.com/essays/examiningbruf.htm) - BRUF is an approach where requirements for a software development project are described in detail up front. This proves to be a high-risk strategy. - [Enterprise Modeling Anti-Patterns: What to Watch Out For](https://agilemodeling.com/essays/enterprisemodelingantipatterns.htm) - There are several enterprise modeling anti-patterns that sound good in theory but in practice prove to be harmful, if not outright disastrous. - [Easing into Agile Modeling (AM)](https://agilemodeling.com/essays/easingintoam.htm) - It is clear that many people need a way to ease into AM slowly. I recommend you improve communication, keep it simple, and adopt evolutionary strategies. - [Document Late: An Agile Core Practice](https://agilemodeling.com/essays/documentlate.htm) - With "document late" youdefer the creation of all deliverable documentation as late as possible, creating them just before you need to actually deliver them. - [Document Continuously: An Agile Core Practice](https://agilemodeling.com/essays/documentcontinuously.htm) - If your goal is to have potentially shippable software every sprint then you will need to document continuously throughout the initiative. - [Defining "Agile Model": When Is a Model Agile?](https://agilemodeling.com/essays/whenisamodelagile.htm) - An agile model fulfills its purpose and no more; is understandable; is simple; sufficiently accurate, consistent, and detailed; and it provides positive value. - [Comparing the Various Approaches to Modeling in Software Development](https://agilemodeling.com/essays/modelingapproaches.htm) - There are many software modeling approaches, some of which involve software-based modeling tools but most apply simpler tools such as paper or whiteboards. - [Communication on Agile Software Teams](https://agilemodeling.com/essays/communication.htm) - This article explore the issues surrounding communication, and in particular focus on how to become more agile in your documentation efforts. - [Common Misconceptions Regarding Agile Modeling](https://agilemodeling.com/essays/misconceptions.htm) - There are several common misconceptions regarding Agile Modeling. This page hopefully clears them up. - [Big Modeling Up Front (BMUF) Anti-Pattern](https://agilemodeling.com/essays/bmuf.htm) - Big modeling up front (BMUF) is the desire to create comprehensive models of the requirements, architecture, and design for a system early in the lifecycle. - [Being Agile: Challenges to Becoming and Remaining Agile](https://agilemodeling.com/essays/remainingagile.htm) - It's easy to talk about "being agile", but to do so you must overcome common challenges to becoming, and then remaining, agile - [Be Realistic About the UML: It's Simply Not Sufficient](https://agilemodeling.com/essays/realisticuml.htm) - Unified Modeling Language (UML) defines industry standard notation and semantics for to build software using object-oriented (OO) or component-based technology. - [Approaches to Agile Model Driven Development (AMDD)](https://agilemodeling.com/essays/amddapproaches.htm) - For the sake of simplicity, there are three different categories of approaches for applying AMDD on teams: Manual Modeling, Agile CASE, and Agile MDA. - [Agile Works: Answering the Question "Where is the Proof?"](https://agilemodeling.com/essays/proof.htm) - There is overwhelming evidence that agile, particularly disciplined approaches to agile, work very well in practice. This article explores that evidence. - [Agile Software Development: A Definition](https://agilemodeling.com/essays/agilesoftwaredevelopment.htm) - Definitions of agile software development that go beyond "read the Agile Manifesto" are hard to come by. Until now. - [Agile Requirements Modeling: Strategies for Agile Teams](https://agilemodeling.com/essays/agilerequirements.htm) - Agile requirements modeling is a collaborative and evolutionary approach to eliciting, exploring, and capturing stakeholder requirements. - [Agile Requirements Modeling: An Example](https://agilemodeling.com/essays/agilerequirementsexample.htm) - Agile requirements modeling is a collaborative, evolutionary strategy. This page works through an example of how to apply such a strategy in practice. - [Agile Requirements Core Practices](https://agilemodeling.com/essays/agilerequirementsbestpractices.htm) - This page overviews a collection of core practices for agile requirements modeling on agile/Scrum software development teams. - [Agile Requirements Change Management](https://agilemodeling.com/essays/changemanagement.htm) - Agile software development teams embrace change, accepting the idea that requirements will evolve throughout an initiative. - [Agile Models: Potential Agile Modeling Artifacts](https://agilemodeling.com/essays/modelingtechniques.htm) - This page provides a brief summary of potential agile models that you may choose to apply when developing business application software. - [Agile Modeling: Where Do I Start?](https://agilemodeling.com/essays/wheredoistart.htm) - The quick answer to "Where do I start with Agile Modeling?" is "it depends". This article answers this question from the point of view of several team roles. - [Agile Modeling: An Introduction](https://agilemodeling.com/essays/introductiontoam.htm) - Agile Modeling (AM) is a collection of values, principles, and practices for modeling software in a collaborative and evolutionary manner. - [Agile Modeling Sessions: An Agile Core Practice](https://agilemodeling.com/essays/agilemodelingsession.htm) - An Agile Modeling session is a facilitated, collaborative, inclusive, and evolutionary approach to modeling or planning that has just enough formality. - [Agile Modeling References](https://agilemodeling.com/essays/references.htm) - A list of references used throughout the site. - [Agile Modeling Core Practices](https://agilemodeling.com/essays/bestpractices.htm) - The Agile Modeling (AM) core practices capture strategies around why you should model and even document, when to do so, and how much to do. - [Agile Modeling and eXtreme Programming (XP)](https://agilemodeling.com/essays/agilemodelingxp.htm) - Agile Modeling and eXtreme Programming (XP) Agile Modeling (AM) is a practices-based software process whose scope is to describe how to model and document in an effective and agile manner. On the AM home page I state that one of the goals of AM is to address the issue of how to apply modeling techniques on software - [Agile Modeling (AM) Glossary of Terms](https://agilemodeling.com/essays/glossary.htm) - The following terms and abbreviations are defined with respect to their use with respect to Agile Modeling. - [Agile Modelers: So You Want to Be An Agile Modeler?](https://agilemodeling.com/essays/personalitytraits.htm) - Modeling is a critical aspect of all agile methods, and being an agile modeler is an important aspect of key agile roles. - [Agile Model Driven Development (AMDD): The Key to Scaling Agile Software Development](https://agilemodeling.com/essays/amdd.htm) - Agile Model Driven Development (AMDD) is the agile version of MDD, an approach to software development where models are created before source code is written. - [Agile MDA: A Roadmap for Sophisticated Modeling Tools](https://agilemodeling.com/essays/agilemda.htm) - Agile MDA approach applies the concepts of Agile Model Driven Development (AMDD) to make the OMG's model-driven architecture (MDA) work in practice. - [Agile Legacy System Analysis and Integration Modeling](https://agilemodeling.com/essays/agilelegacyintegrationmodeling.htm) - Agile legacy system analysis takes a collaborative and evolutionary approach to explore and potentially document existing systems better understand them. - [Agile Design: Strategies for Agile Software Teams](https://agilemodeling.com/essays/agiledesign.htm) - Agile Design: Strategies for Agile Software Teams This article overviews design strategies for agile software development teams. These strategies are critical for scaling agile software development to meet the real-world needs of modern IT organizations. The Agile approach to design is very different than the traditional approach, and apparently more effective too. It is important to - [Agile Criteria: Determining Whether a Team is Agile](https://agilemodeling.com/essays/agilecriteria.htm) - The agile criteria for a team includes regular value production, continual validation, stakeholder involvement, self organization, and continual improvement. - [Agile Business Analysts: Rethinking the Role of Business Analysts](https://agilemodeling.com/essays/businessanalysts.htm) - Agile business analysts (agile BAs) work with stakeholders to explore and capture their needs so that they can be shared with software developers. - [Agile Architecture: Strategies for Scaling Agile Development](https://agilemodeling.com/essays/agilearchitecture.htm) - Agile architecture is a collaborative, evolutionary process performed at the last more responsible moment all throughout the lifecycle, not just upfront . - [Agile Architecture Envisioning: An Agile Core Practice](https://agilemodeling.com/essays/initialarchitecturemodeling.htm) - Agile architecture envisioning is the practice is to perform some high-level architectural modeling early in the lifecycle to identify an architecture strategy. - [Agile Analysis: Strategies for Agile Software Teams](https://agilemodeling.com/essays/agileanalysis.htm) - Agile analysis is highly collaborative and performed on a just-in-time (JIT) basis. Analysis is so important to agilists we do it every single day. - [Agile Modeling Essays and Articles](https://agilemodeling.com/essays.htm) - Agile Modeling Essays and Articles Table of Contents AM Overview Major Pages at this Site Adopting AM Agile Models AM in practice Practices, Patterns, and Anti-Patterns Topics in AM UML/MDA Other Translations Agile Modeling: An Overview Agile Model Driven Development (AMDD) How the AM Practices Fit Together An Introduction to Agile Modeling So You Want - [Agile Modeling (AM) Recommended Resources](https://agilemodeling.com/resources.htm) - Links to articles and books about Agile Modeling, agile software development, software modeling techniques, and other interesting resources. - [About The Agile Modeling Site: AgileModeling.com](https://agilemodeling.com/aboutam.htm) - This site describes the Agile Modeling (AM) methodology, which focuses on effective strategies for software modeling and documentation. - [The TAGRI (They Ain't Gonna Read It) Principle](https://agilemodeling.com/essays/tagri.htm) - The TAGRI principle: Wery little of the documentation which gets created during software development actually gets read by the actual target audience. - [The SWA Online Case Study](https://agilemodeling.com/essays/swaonline.htm) - The SWA Enterprises case study is used in the book Agile Modeling for an ongoing example. - [Feature Driven Development (FDD) and Agile Modeling](https://agilemodeling.com/essays/fdd.htm) - Feature-Driven Development (FDD) is a client-centric, architecture-centric, and pragmatic software process that can be enhanced with Agile Modeling strategies. - [Core Practices for Lean/Agile Documentation](https://agilemodeling.com/essays/agiledocumentationbestpractices.htm) - Agile documentation is written when that's the best option to add value, and even then the documentation is concise and the work streamlined. - [CRUFT: Calculating the Value of Documentation](https://agilemodeling.com/essays/cruft.htm) - The CRUFT formula captures how to calculate the value of a document, or in general, the value of an artifact. ## My Templates - [header-home](https://agilemodeling.com/?elementor_library=header-home) - [Default Kit](https://agilemodeling.com/?elementor_library=default-kit) - [footer](https://agilemodeling.com/?elementor_library=footer) - Facebook-f Twitter Youtube Copyright 2002-2022 Ambysoft Inc. This site owned by Ambysoft Inc. ## Elementor Header & Footer Builder - [footer](https://agilemodeling.com/elementor-hf/2113/) - About the AuthorScott W. Ambler is a data methodologist who works with organizations to help them improve their ways of working (WoW). Scott is an international keynote speaker, a trainer, the (co-)author of 31 books, the co-creator of the Disciplined Agile (DA) toolkit, and a former Vice President at PMI. Scott has earned two Master - [header_agilemodeling](https://agilemodeling.com/elementor-hf/header_agilemodeling/) - Menu Home Start Here An Introduction to Agile Modeling Agile Model Driven Development (AMDD) Agile Modeling: Core Practices Frequently Asked Questions (FAQ) Values of AM Principles of AM Practices of AM Core Practices Active Stakeholder Participation Agile Modeling Session Architecture Envisioning Document Continuously Document Late Executable Specifications Inclusive Tools and Techniques Iteration Modeling Just Barely ~~~ ## llms-full Not found.