The following terms and abbreviations are defined with respect to their use with respect to Agile Modeling.

• Agile model.  A model that is just barely good enough.  This means that it fulfills its purpose and no more; is understandable to its intended audience; is simple; sufficiently accurate, consistent, and detailed; and investment in its creation and maintenance provides positive value to your project. 

• Agile Modeling (AM).  A practice-based methodology for effective modeling of software-based systems.

• Agile modeling session.  A modeling session where you follow the principles, and apply the practices, of AM.

• Analysis modeling session.  A modeling session where your focus is on fleshing out the requirements for your system.

• Analysis paralysis. The fear of moving forward until your models are perfect. 

• Analyst.  A developer responsible for working directly with project stakeholders to potentially gather/elicit information from them, document that information, and/or validate that information.

• API. Application programming interface.

• Architecture modeling session.  A modeling session where your focus is on identifying a high-level strategy for how your system will be built.

• Artifact.  A deliverable or work product.

• Baseline.  A tested and certified version of a deliverable representing a conceptual milestone which thereafter serves as the basis for further development and that can be modified only through formal change control procedures.  A particular version becomes a baseline when a responsible group decides to designate it as such.

• BDUF.  Big design up front.

• Behavioral requirement.  A category of requirements that describe how a user will interact with a system, how someone will use a system, or how a system fulfills a business function.

• Boundary object.  An object that represents user interface elements such as screens, reports, HTML pages, or emails

• Business rule. An operating principle or policy that your software must satisfy. 

• Cardinality. Represents the concept “how many?” in associations. 

• CASE. Computer-aided system engineering.

• CASE tool. Software that supports the creation and manipulation of models of software-oriented systems.

• Catalysis. A next generation software process for the systematic business-driven development of component-based systems.

• Change case.  An artifact used to describe a potential requirement for a system or a potential modification to existing requirements.

• Class diagram.  A UML diagram that depicts classes, their static inter-relationships (including inheritance, aggregation, and association), and the operations and attributes of those classes.  

• Class Responsibility Collaborator (CRC) card. A standard index card that has been divided into three sections, one indicating the name of the class that the card represents, one listing the responsibilities of the class, and the third listing the names of the other classes that this one collaborates with to fulfill its responsibilities.

• Class Responsibility Collaborator (CRC) model.  A collection of CRC cards.

• Cohesion. The degree of relatedness within an encapsulated unit (such as a component or a class).

• Collaboration diagram. A UML diagram that show instances of classes, their interrelationships, and the message flow between them.  Collaboration diagrams provide a birds-eye view of a collection of collaborating objects working together to fulfill a common purpose.

• Collaborative modeling tool.  A CASE tool that enables several developers to simultaneously work on one or models with real-time updates of those models.

• Collaborative writing tool.  A word processing tool that enables several people to simultaneously write a document with real-time updates of that document.

• Communication.  The act of transmitting information between individuals.

• Component diagram.  A UML diagram that depicts the software components of a system, their interfaces, and the relationships between the components. 

• Connascence.  Between two software elements, A and B, the property by which a change in A would require a change to B to preserve overall correctness within your system.

• Context model. A diagramshowing how your system fits into its overall environment.  It is common to develop high-level data flow diagrams or deployment diagrams for this.

• Contract model. A model that defines an agreement between two or more parties. A contract model is something that the parties should mutually agree to and mutually change over time if required.  Contract models are often required when an external group controls an information resource that your system requires, such as a database, legacy application or information service.

• Control object. An object that serves as the glue between boundary/interface objects and entity objects, implementing the logic required to manage the various objects and their interactions.

• Constraint. A restriction on the degree of freedom you have in providing a solution. 

• Cohesion. The degree of relatedness within an encapsulated unit (such as a component or a class).

• Data domain.  A collection of related data entities and the relationships between those entities.  Most data domains are based on a common theme or concept within your business domain, such as customer, account, brokerage, and insurance within a financial institution.

• Data model. A diagram that depicts data entities and their inter-relationships. 

• Data-flow diagram (DFD). A diagram that shows the movement of data between processes, entities, and data stores within a system.

• Death march.  A doomed software project, without any apparent hope of success, where the developers carry on anyway.

• Deliverable. An artifact that is delivered as part of your overall system.  Examples include source code, user documentation, and technical system documentation for operations and maintenance personnel.

• Deployment diagram. A diagram that depicts a static view of the run-time configuration of processing nodes and the components that run on those nodes. 

• Design modeling session. A modeling session where your focus is on identifying a detailed strategy for building a portion of your system.

• Developer.  Anyone directly involved in the creation of a software development artifact.  People in the roles of programmer, modeler, and tester are examples of developers.

• Development team.  Developers + active project stakeholders.

• Document. Any artifact external to source code whose purpose is to convey information in a persistent manner.  

• Documentation.  Persistent information written for people that describes a system, including both documents and comments in source code.

• Documentation handoff.  This occurs when one group or person provides documentation to another group or person.

• Domain model. A model depicting major business classes or entities and the relationships between them.  It is common to use a class diagram or data diagram for this purpose.

• Drawing tool.  A software tool that supports the ability to draw diagrams.  Drawing tools are effectively low-end CASE tools.

• DSDM. Dynamic Systems Development Method.

• Enterprise architectural modeling.  The act of creating and evolving models that depict the business and technical infrastructure of your organization.

• Enterprise requirementsmodeling.  The act of creating and evolving models that reflect the high-level requirements of your organization. 

• Entity object. An object that is typically found in your domain model, for example Order and Item in an inventory control system.

• Essential use-case.  A simplified, abstract, generalized use case that captures the intentions of a user in a technology and implementation independent manner.

• Essential user interface prototype.  A low-fidelity model of a portion of the user interface for a system in a technology independent manner.

• EUP. Enterprise Unified Process.

• Executable UML (xUML).  A strategy in which systems are modeled using the artifacts of the UML and a formal language such as the OCL from which working software is generated.

• Executive overview.  A definition of the vision for the system and a summary of the current cost estimates, predicted benefits, risks, staffing estimates, and scheduled milestones.

• Facilitator.  Someone responsible for planning, running, and managing modeling sessions.

• FDD. Feature-Driven Development.

• Flow chart.  A diagram depicting the logic flow of a business process or software operation.  Flow charts are a primary artifact of structured/procedural modeling.

• Glossary.  A collection of definitions of terms that are relevant to your project.

• Graphical user interface (GUI). A style of user interface composed of graphical components such as windows and buttons.

• Hardware node.  A computer, switch, printer, or other hardware device.

• Increment.  The difference between two releases of a system.

• Information radiator.  A display of information posted on the wall where passersby can see it.

• Interface.  In Java, a collection of zero or more operation signatures that a class implements in whole.

• Interface object.  See boundary object.

• IT. Information Technology.

• Iterate.  To move on to the next step/task, often in a repetitious manner taking small steps each time.

• Iteration.  A Unified Process term referring to a distinct sequence of activities with a baselined plan and valuation criteria resulting in a release (either internal or external).

• Ivory tower architecture.  An architecture developed in isolation from the developers, or teams of developers, responsible for following it.

• Joint application development (JAD). A structured, facilitated meeting in which modeling is performed by a group of people.  JADs are often held for gathering requirements or for modeling candidate architecture(s).

• KISS.  Keep it simple stupid.

• Landscape model.  See overview model.

• Layering.  The organization of software collections (layers) of classes or components that fulfill a common purpose.

• Major user interface element.  A large-grained item such as a screen, HTML page, or report.

• Message-invocation box. The long, thin, vertical boxes that appear on sequence diagrams which represent invocation of an operation on an object or class.

• Minor user interface element.  A small-grained item such as a user input field, menu item, list, or static text field.

• Model. An abstraction that describes one or more aspects of a problem or a potential solution addressing a problem. Traditionally, models are thought of as zero or more diagrams plus any corresponding documentation.  However non-visual artifacts such collections of CRC cards, a textual description of one or more business rules, or the structured English description of a business process are also considered to be models.

• Modeling session.  An activity where one or more people focus on the development of one or more models. 

• Multiplicity.  The UML combines the concepts of cardinality and optionality into the single concept of multiplicity.

• Network diagram.  A model that depicts the various types of hardware nodes and the interconnections between them. 

• Non-behavioral requirement.  A category of requirements that describe technical features of a system, features typically pertaining to availability, security, performance, interoperability, dependability, and reliability.

• Normalization (data).  A data modeling technique, the goal of which is to organize data elements in such a way that they are stored in one place and one place only.

• Normalization (object).  An object modeling technique, the goal of which is to organize behavior in such a way that it is implemented in one place and one place only.

• Note.  A modeling construct for adding free-form text to UML diagrams.

• Object Constraint Language (OCL).  The industry standard specification language defined by the Object Management Group (www.omg.org).

• Object lifeline.  Represents, in a sequence diagram, the life span of an object during an interaction.

• OOA&D.  Object-oriented analysis and design.  OOA&D should be considered activities, not phases.

• Optionality. Represents the concept “do you need to have it?” in associations.

• Operations documentation.  This documentation typically includes an indication of the dependencies that your system is involved with; the nature of its interaction with other systems, databases, and files; references to backup procedures; a list of contact points for your system and how to reach them; a summary of the availability/reliability requirements for your system; an indication of the expected load profile of your system; and troubleshooting guidelines.

• Organization chart.  A model that depicts the reporting structure between the people, positions, and/or teams within an organization. 

• Osmotic communication.  Indirect information transfer through overhearing conversations or simply noticing things happening around you.

• Overview diagram.  A high-level depiction of one aspect of your system’s architecture.  Any type of diagram, such as a UML class diagram or a data model, may be used as an overview diagram when appropriate for the given view.

• Phase modeling sessions. A modeling session where your focus is on creating models pertinent to the major phases of traditional development.  This includes but is not limited to requirements, analysis, architecture, and design modeling sessions.

• Physical prototype. A physical model of the actual environment in which a system is to be deployed. 

• PIG.  Process improvement group (the pun is intended).

• Process object.  See control object.

• Project overview.  A document that summarizes critical information such as the vision for the system, primary user contacts, technologies and tools used to build the system, the critical operating processes (some applicable to development, such as how to build the system and some applicable to production, such as how to back up data storage), and references to critical project artifacts such as the source code, the permanent models, and other documents.  This document serves as a starting point for anyone new to the team. 

• Project Stakeholder.  A direct user, indirect user, manager, senior manager, operations staff member, support (help desk) staff member, testers, developers working on other systems that integrate or interact with this one, or maintenance professionals potentially affected by the development and/or deployment of a software project.  For the sake of Agile Modeling developers working on the project shall be excluded whenever the term "project stakeholder" is used, even though they clearly have an important stake in the projects that they work on. 

• Release.  The deployment of a working version of a system.  Releases may be internal, available only to the development team, or external, available to some or all of the users for the system.

• Requirements document.  This document defines what the system will do, summarizing or composed of requirements artifacts such as business rule definitions, use cases, user stories, or essential user interface prototypes (to name a few). 

• Requirements modeling session.  A modeling session where your focus is on defining what your project stakeholders want your system to do.

• Requirements traceability matrix.  The artifact used to record traceability relations between artifacts.

• Robustness diagram. A model that depicts the major objects – classified into boundary/interface objects, entity objects, or control/process objects – that participate in fulfilling an actor’s interaction with a system as defined by a usage scenario. 

• RUP.  Rational Unified Process.

• Scribe.  A person responsible for recording information during a modeling session.

• SEPG.  Software engineering process group.

• Sequence diagram. A UML diagram used to explore the logic of usage scenarios. 

• Software development artifact.  See artifact.

• Source code.  A sequence of instructions, including comments describing those instructions, for a computer system.  Also known as program code, program source code, or simply as code.

• Specification language.  A style of writing, such as Object Constraint Language (OCL) and Structured English, used to describe logic in a structured/formal manner.

• SPI. Software process improvement.

• SRS. Software Requirements Specification.

• State chart diagram.  A UML diagram used to depict the various states that an object may be in and the transitions between those states.

• Stereotype.  A UML stereotype denotes a common usage of a modeling element.  Stereotypes are used to extend the UML in a consistent manner.

• Structure diagram.  A diagram that depicts the modules of procedure-based code and the invocation relationships between those modules.

• Structured English.  A traditional, easy to read, style of specification language.

• Support documentation.  This documentation includes training materials specific to support staff; all user documentation to use as reference when solving problems; a trouble-shooting guide; escalation procedures for handling difficult problems; and a list of contact points within the maintenance team. 

• System.  The software, documentation, hardware, middleware, installation procedures, and operational procedures.

• System documentation.  The purpose of this document is to provide an overview of the system and to help people understand the system.  Common information in this document includes an overview of the technical architecture, the business architecture, and the high-level requirements for the system. 

• System use case.  A use case in which high-level implementation decisions are reflected, such as the specific type of user interface and your physical environment.  

• Technical requirement. A requirement pertaining to a non-business-related aspect of your system, such as a performance-related issue, a reliability issue, or a technical environment issue. 

• Traceability.  The ease of which the features of one artifact – perhaps a document, model, or source code – are related/traced to the features of another.

• Truck insurance.  The assurance that if the development team leaves, or gets hit by a truck, that critical information about the project is left behind in the form of documentation. 

• Truck number.  An estimate of minimum number of people you would need to lose from your team before you find yourself in trouble (e.g. the number of people that would need to be hit by a truck).

• UML. Unified Modeling Language.

• UP. Unified Process.

• Usage scenario.  A description of a single path of logic through one or more use cases or user stories. 

• Use case.  A sequence of actions that provide a measurable value to an actor.  

• Use case diagram.  A UML diagram used to depict a collection of use cases, actors, their associations, and optionally a system boundary box. 

• Use case model.  The combination of one or more use case diagrams and the supporting use cases and actor definitions.

• User documentation.  Documents describing how to work with your system, including reference manuals, usage guides, support guides, and training materials. 

• User interface (UI).  The portion of software that a user directly interacts with. 

• User interface element.  See major user interface element and minor user interface element.

• User interface flow diagram. A diagram that enables you to model the high-level relationships between major user interface elements, depicting a birds-eye view of the user interface of your system. 

• User story.  A reminder to have a conversation with your project stakeholders that captures a behavioral requirement, a business rule, a constraint, or a technical requirement. 

• Version control tool. A software tool used to check in/out, define, and manage versions of project artifacts.

• Virtual meeting tool.  A tool that enables communication between several people in different physical locations.

• Work product.  A type of artifact, such as a model or project schedule, that you create during development that you may discard or evolve into an actual deliverable.

• Working software.  Software that has been tested, accepted by its users, and then released.

• XP. eXtreme Programming. 

• xUML. See Executable UML.

• YAGNI.  You Ain’t Gonna Need It Anyway.

Let Me Help

I actively work with clients around the world to improve their information technology (IT) practices as both a mentor/coach and trainer.  A full description of what I do, and how to contact me, can be found here.