Agile Software Development Review


Published on

Published in: Technology, Education
1 Like
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Agile Software Development Review

  1. 1. Agile Software Development Review Agile Modeling (AM) is a practice-based methodology for effective modeling and documentation of software- based systems. At a high level AM is a collection of best practices, depicted in the pattern language map below (click on the practice for information). At a more detailed level AM 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. Usage Modeling - Acceptance Tests User Interface Development A detailed agile SDLC. - Essential Use Cases - Features - Essential User Interface Prototype - System Use Cases - User Interface Flow Diagram - Usage scenario - User Interface Prototype - User Stories - UML Use Case Diagram Supplementary Requirements Detailed Structural Modeling Modeling - External Interface (EI) Specification - Business Rules - Physical Data Model (PDM) - Conceptual Cases - UML Class Diagram - Constraints - UML Object Diagram - Glossary - Technical Requirements Dynamic Object Modeling Conceptual Domain Modeling - UML Communication Diagram - Class Responsibility Collaborator (CRC) Cards - UML Composite Structure Diagram - Logical Data Model (LDM) - UML Interaction Overview Diagram - Object Role Model (ORM) Diagram - UML Sequence Diagram - Robustness Diagram - UML State Machine Diagram - UML Class Diagram - UML Timing Diagram Architectural Modeling Process Modeling - Change Cases - Data Flow Diagram (DFD) - Free Form Diagram - Flow Chart - Security Threat Modeling - UML Activity Diagram - UML Component Diagram - Value Stream Map - UML Deployment Diagram - Workflow diagram Copyright 2003-2005 - UML Package Diagram Scott W. Ambler
  2. 2. 1. Agile Requirements Modeling in a Nutshell Figure 1 depicts the Agile Model Driven Development (AMDD) lifecycle, which depicts how Agile Modeling (AM) is applied by agile software development teams. The critical aspects which we're concerned about right now are initial requirements modeling, iteration modeling, and model storming. The fundamental idea is that you do just barely enough modeling at the beginning of the project to understand the requirements for your system at a high level, then you gather the details as you need to on a just-in-time (JIT) basis. Figure 1. The AMDD lifecycle. 1.1 Initial Requirements Modeling At the beginning of a project you need to take several days to envision the high-level requirements and to understand the scope of the release (what you think the system should do). Your goal is to get a gut feel for what the project is all about, not to document in detail what you think the system should do: the documentation
  3. 3. can come later, if you actually need it. For your initial requirements model my experience is that you need some form of: 1. Usage model. As the name implies usage models enable you to explore how users will work with your system. This may be a collection of essential use cases on a Rational Unified Process (RUP) project, a collection of features for a Feature Driven Development (FDD) project, or a collection of user stories for an Extreme Programming (XP) project. 2. Initial domain model. A domain model identifies fundamental business entity types and the relationships between then. Domain models may be depicted as a collection of Class Responsibility Collaborator (CRC) cards, a slim UML class diagram, or even a slim data model. This domain model will contain just enough information: the main domain entities, their major attributes, and the relationships between these entities. Your model doesn’t need to be complete, it just needs to cover enough information to make you comfortable with the primary domain concepts. 3. User interface model. For user interface intensive projects you should consider developing some screen sketches or even a user interface prototype. What level of detail do you actually need? My experience is that you need requirements artifacts which are just barely good enough to give you this understanding and no more. For example, Figure 2 depicts a simple point- form use case. This use case could very well have been written on an index card, a piece of flip chart paper, or on a whiteboard. It contains just enough information for you to understand what the use case does, and in fact it may contain far too much information for this point in the lifecycle because just the name of the use case might be enough for your stakeholders to understand the fundamentals of what you mean. Figure 3, on the other hand, depicts a fully documented formal use case. This is a wonderful example of a well documented use case, but it goes into far more detail than you possibly need right now. If you actually need this level of detail, and in practice you rarely do, you can capture it when you actually need to by model storming it at the time. The longer your project team goes without the concrete feedback of working software, the greater the danger that you're modeling things that don't reflect what your stakeholders truly need. The urge to write requirements documentation should be transformed into an urge to instead collaborate closely with your stakeholders and then create working software based on what they tell you. Figure 2. A point-form use case. Name: Enroll in Seminar Basic Course of Action: • Student inputs her name and student number • System verifies the student is eligible to enroll in seminars. If not eligible then the student is informed and use case ends. • System displays list of available seminars. • Student chooses a seminar or decides not to enroll at all. • System validates the student is eligible to enroll in the chosen seminar. If not eligible, the student is asked to choose another. • System validates the seminar fits into the student’s schedule. • System calculates and displays fees • Student verifies the cost and either indicates she wants to enroll or not. • System enrolls the student in the seminar and bills them for it.
  4. 4. • The system prints enrollment receipt. Figure 3. A detailed use case. Name: Enroll in Seminar Identifier: UC 17 Description: Enroll an existing student in a seminar for which she is eligible. Preconditions: The Student is registered at the University. Postconditions: The Student will be enrolled in the course she wants if she is eligible and room is available. Basic Course of Action: 1. The use case begins when a student wants to enroll in a seminar. 2. The student inputs her name and student number into the system via UI23 Security Login Screen. 3. The system verifies the student is eligible to enroll in seminars at the university according to business rule BR129 Determine Eligibility to Enroll. [Alt Course A] 4. The system displays UI32 Seminar Selection Screen, which indicates the list of available seminars. 5. The student indicates the seminar in which she wants to enroll. [Alt Course B: The Student Decides Not to Enroll] 6. The system validates the student is eligible to enroll in the seminar according to the business rule BR130 Determine Student Eligibility to Enroll in a Seminar. [Alt Course C] 7. The system validates the seminar fits into the existing schedule of the student according to the business rule BR143 Validate Student Seminar Schedule. 8. The system calculates the fees for the seminar based on the fee published in the course catalog, applicable student fees, and applicable taxes. Apply business rules BR 180 Calculate Student Fees and BR45 Calculate Taxes for Seminar. 9. The system displays the fees via UI33 Display Seminar Fees Screen. 10. The system asks the student if she still wants to enroll in the seminar. 11. The student indicates she wants to enroll in the seminar. 12. The system enrolls the student in the seminar. 13. The system informs the student the enrollment was successful via UI88 Seminar Enrollment Summary Screen. 14. The system bills the student for the seminar, according to business rule BR100 Bill Student for Seminar. 15. The system asks the student if she wants a printed statement of the enrollment. 16. The student indicates she wants a printed statement. 17. The system prints the enrollment statement UI89 Enrollment Summary Report. 18. The use case ends when the student takes the printed statement. Alternate Course A: The Student is Not Eligible to Enroll in Seminars. A.3. The registrar determines the student is not eligible to enroll in seminars. A.4. The registrar informs the student he is not eligible to enroll. A.5. The use case ends. Alternate Course B: The Student Decides Not to Enroll in an Available Seminar B.5. The student views the list of seminars and does not see one in which he wants to enroll. B.6. The use case ends. Alternate Course C: The Student Does Not Have the Prerequisites C.6. The registrar determines the student is not eligible to enroll in the seminar he chose. C.7. The registrar informs the student he does not have the prerequisites. C.8. The registrar informs the student of the prerequisites he needs. C.9. The use case continues at Step 4 in the basic course of action. Requirements Artifacts Because there are several different types of requirements, some or all of which may be applicable to your project, and because each modeling artifact has it’s strengths and weaknesses, you will want to have several requirements modeling artifacts in your intellectual toolkit to be effective. Table 1 summarizes common artifacts for modeling requirements, artifacts that are described in greater detail in the article Artifacts for Agile Modeling. The type(s) of requirement that the artifact is typically used to model is indicated as well as a
  5. 5. potential “simple” tool that you can use to create the artifact (the importance of using simple tools was discussed earlier in the section Some Philosophy). Table 1. Candidate artifacts for modeling requirements. Artifact Type Simple Tool Description Acceptance Either FITNesse Describes an observable feature of a system which is of interest Test to one or more project stakeholders. Business rule Behavioral Index card A business rule is an operating principle or policy that definition your software must satisfy. Change case Either Index card Change cases are used to describe new potential requirements for a system or modifications to existing requirements. CRC model Either, Usually Index cards A Class Responsibility Collaborator (CRC) model is a Behavioral collection of standard index cards, each of which have been divided into three sections, indicating the name of the class, the responsibilities of the class, and the collaborators of the class. A class represents a collection of similar objects, a responsibility is something that a class knows or does, and a collaborator is another class that a class interacts with to fulfill its responsibilities. CRC models are used, during requirements modeling, for conceptual modeling which explores domain concepts and high-level relationships between them. Constraint Either Index card A constraint is a restriction on the degree of freedom you definition have in providing a solution. Constraints are effectively global requirements for your project. Data flow Behavioral Whiteboard A data-flow diagram (DFD) shows the movement of data diagram drawing within a system between processes, entities, and data stores. When modeling requirements a DFD can be used (DFD) to model the context of your system, indicating the major external entities that your system interacts with. Essential UI Either Post It notes and An essential user interface (UI) prototype is a low-fidelity prototype flip chart paper model, or prototype, of the UI for your system – it represents the general ideas behind the UI but not the exact details. Essential use Behavioral Paper A use case is a sequence of actions that provide a case measurable value to an actor. An essential use-case is a simplified, abstract, generalized use case that captures the intentions of a user in a technology and implementation independent manner. Feature Either, Usually Index card A feature is a “small, useful result in the eyes of the Behavioral client”. A feature is a tiny building block for planning, reporting, and tracking. It’s understandable, measurable, and do-able (along with several other features) within a two-week increment (Palmer & Felsing 2002). Technical Non-Behavioral Index card A technical requirement pertains to a non-functional requirement aspect of your system, such as a performance-related issue, a reliability issue, or technical environment issue. Usage Behavioral Index card A usage scenario describes a single path of logic through scenario one or more use cases or user stories. A use-case scenario could represent the basic course of action, the happy path, through a single use case, a combination of portions of the happy path replaced by the steps of one or more alternate paths through a single use case, or a path spanning several use cases or user stories. Use case Behavioral Whiteboard sketch The use-case diagram depicts a collection of use cases, diagram actors, their associations, and optionally a system boundary box. When modeling requirements a use case
  6. 6. diagram can be used to model the context of your system, indicating the major external entities that your system interacts with. User story Either Index card A user story is a reminder to have a conversation with your project stakeholders. User stories capture high-level requirements, including behavioral requirements, business rules, constraints, and technical requirements. An important thing to remember is that although there are several artifacts that you can potentially use for requirements gathering that doesn’t mean that you need to use all of them on any given project. You should understand when it is appropriate to use each artifact, knowledge that enables you to follow the practice Apply The Right Artifact(s) to your situation at hand. The underlying process often motivates artifact choice. On the home page I indicate that AM is used in conjunction with another software process, such as eXtreme Programming (XP) or the Unified Process (UP), whose scope is the full lifecycle. Very often the underlying process will prefer certain primary requirements artifact(s), in the case of XP user stories and for the UP use cases, an issue that you must consider when requirements modeling. See the articles AM and XP and AM and UP for further details. Some Potential Analysis Models Are the artifacts created taking an agile approach to analysis any different than the ones created as the result of traditional analysis? In a way they are. They are in fact the same types of artifacts, a use case diagram is a use case diagram after all, but the way in which they are created are different. The artifacts are created following the principles and practices of AM, they are just barely good enough and are often discarded so as to travel light. Table 1 lists common artifacts used during analysis modeling and suggests a simple tool with which you could create such an artifact. It is interesting to note that this list is meant to be representative, a more thorough list is presented in the article Artifacts for Agile Modeling and in the book Agile Modeling. Table 1. Candidate artifacts for analysis modeling. Artifact Simple Tool Description Activity Diagram Whiteboard UML activity diagrams are used during analysis modeling to explore the logic of a usage scenario (see below), system use case, or the flow of logic of a business process. In many ways activity diagrams are the object-oriented equivalent of flow charts and data-flow diagrams (DFDs). Class Diagram Whiteboard Class diagrams show the classes of the system, their inter-relationships (including inheritance, aggregation, and association), and the operations and attributes of the classes. During analysis you can use class diagrams to represent your conceptual model which depict your detailed understanding of the problem space for your system. Constraint Index card A constraint is a restriction on the degree of freedom you have in providing a solution. definition Constraints are effectively global requirements for your project. CRC model Index cards A Class Responsibility Collaborator (CRC) model is a collection of standard index cards, each of which have been divided into three sections, indicating the name of the class, the responsibilities of the class, and the collaborators of the class. Like class diagrams, CRC models are used during analysis modeling for conceptual modeling. Data flow diagram Whiteboard A data-flow diagram (DFD) shows the movement of data within a system between (DFD) processes, entities, and data stores. When analysis modeling a DFD can be used to model the existing and/or proposed business processes that your system will support. Entity/Relationship Whiteboard E/R diagrams show the main entities, their data attributes, and the relationships between (E/R) diagram those entities. Like class diagrams E/R diagrams can be used for conceptual modeling, in many ways E/R diagrams can be thought of as a subset of class diagrams. (data diagram) Flow chart Whiteboard Flow charts are used in a similar manner to activity diagrams.
  7. 7. Robustness Whiteboard Robustness diagrams can be used to analyze usage scenarios to identify candidate classes diagrams and major user interface elements (screens, reports, ...). Sequence diagram Whiteboard Sequence diagrams are used to model the logic of usage scenarios. Sequence diagrams model the flow of logic within your system in a visual manner, enabling you to both explore and validate your logic. State chart diagram Whiteboard State chart diagrams depict the various states, and the transitions between those states, that an entity exhibits. During analysis modeling state chart diagrams are used to explore the lifecycle of an entity that exhibits complex behavior. System use case Paper A use case is a sequence of actions that provide a measurable value to an actor. A system use case includes high-level implementation decisions in it. For example, a system use case will refer to specific user interface components – such as screens, HTML pages, or reports. System use cases will also reflect fundamental architectural decisions, such as the use of ATMs versus cell phones to access your bank account. UI prototype Whiteboard A user interface (UI) prototype models the user interface of your system. As a part of analysis modeling it enables you to explore the problem space that your system addresses in a manner that your project stakeholders understand. Remember, the user interface is the system to most people. Usage scenario Index card A usage scenario is exactly what its name indicates – the description of a potential way that your system is used. Use case diagram Whiteboard The use-case diagram depicts a collection of use cases, actors, their associations, and optionally a system boundary box. When analysis modeling a use case diagram can be used to depict the business functionality, at a high-level, that your system will support. It can also be used to depict the scope of the various releases of your system via the use of color or system boundary boxes. Design Throughout The Lifecycle Figure 1 depicts the generic agile software development lifecycle. For the sake of discussion, the important thing to note is that there is no design phase, nor a requirements phase for that matter, which traditionalists are familiar with. Agile developers will do some high-level architectural modeling during Iteration 0, also known as the warm-up phase, and detailed design during development iterations and even during the end game (if needed). Figure 1. The Agile SDLC. Architecture Design
  8. 8. Architecture provides the foundation from which systems are built and an architectural model defines the vision on which your architecture is based. The scope of architecture can be that of a single application, of a family of applications, for an organization, or for an infrastructure such as the Internet that is shared by many organizations. Regardless of the scope, my experience is that you can take an agile approach to the modeling, development, and evolution of an architecture. 1. Every system has an architecture. BUT, it may not necessarily have architectural models describing that architecture. For example, a small team taking the XP approach that is working together in the same room may not find any need to model their system architecture because everyone on the team knows it well enough that having a model doesn’t provide sufficient value to them. Or, if an architectural model exists it will often be a few simple plain old whiteboard (POW) sketches potentially backed by a defined project metaphor. This works because the communication aspects of XP, including pair programming and Collective Ownership, negate the need for architecture model(s) that need to be developed and maintained throughout the project. Other teams – teams not following XP, larger teams, teams where people are not co-located – will find that the greater communication challenges inherent in their environment requires them to go beyond word-of-mouth architecture. These teams will choose to create architectural models to provide guidance to developers as to how they should build their software. Fundamentally, the reason why you perform architectural modeling is to address the risk of members of your development team not working to a common vision. 2. Architecture scales agile. This is true of traditional techniques as well. Have a viable and accepted architecture strategy for a project is absolutely critical to your success, particularly in the complex situations which agile teams find themselves in at scale. Scaling issues include team size, regulatory compliance, distributed teams, system complexity, and so on. An effective approach to architecture enables you to address these scaling issues. 2. Architecture Throughout the Lifecycle The reality is that the development of architecture is very hard, an effort that is key to your success, and one that you’re not going to get right from the start. An iterative and incremental approach addresses the risk of an inadequate or inappropriate architecture by developing it a bit at a time, and only when you need it. There are four basic strategies for organizing agile teams at scale: 1. Architecture-driven approach. With this strategy you organize your subteams around the subsystems/ components called out in your architecture. This strategy works well when your architecture is of high quality (it's loosely coupled and highly cohesive) and the interfaces to the subsystems have been identified before the subteams really get going (the interfaces will evolve over time, but you want to get a good start at them initially). The challenge with this strategy is that it requires your requirements to be captured in a way which reflects the architecture. For example, if your architecture is based on large- scale business domain components then a requirement should strive to focus on a single business domain if possible. If your architecture is based on technical tiers -- such as a 3-tier architecture with user interface (UI), business, and data tiers -- then requirements should focus on a single tier if possible. 2. Feature-driven approach. With this strategy each subteam implements a feature at a time, a feature being a meaningful chunk of functionality to your stakeholders. I would apply this strategy in situation where the architecture exhibits a lot of coupling AND where you have sophisticated development practices in place. The challenge with this approach is that the subteams often need to access a wide range of the source code to implement the feature and thereby run the risk of collisions with other subteams. As a result these teams sophisticated change management, continuous integration, and potentially even parallel independent testing strategies in place (to name a few). 3. Open source approach. With this strategy one or more subsystems/components are developed in an open source manner, even if it is for a single organization (this is called internal open source). This strategy is typically used for subsystems/components which are extensively reused by many teams, for example a security framework, and which must evolve quickly to meet the changing needs of the other
  9. 9. systems accessing/using them. This strategy requires you to adopt tools and processes which support open source approaches. 4. Combinations thereof. Most agile teams at scale will combine the previous three strategies as appropriate. 6. The Agile Architecture Process Figure 3 depicts the process for architecture activities on an agile project. The core architecture team is responsible for envisioning the initial architecture then bringing it to the rest of the project team for feedback and subsequent evolution. To avoid an ivory tower architecture the members of the core architecture team will take active roles on the various subteams on the project, communicating the architecture to the subteams and working with them to prove portions of the architecture via concrete experiments. From the point of view of the development subteams the architects act as consultants whose expertise is the corporate architecture as well as active members of the subteam. The core architecture team should view the development subteams as their customers, as project stakeholders for their architecture, customers that will need help from them and who will have new requirements that necessitate change to the architecture. In short, the core architecture team should actively work with their project stakeholders, in this case the development subteams. Figure 3. Agile architecture process. The core architecture team will find that they need to get together occasionally to evolve the architecture as the project progresses, negotiating changes to the architecture and updating their architectural model(s), if any, as appropriate. These meetings will be frequent at the beginning of a project and will be needed less and less as the architecture solidifies. It will be common for members of the development subteams, who may not be members of the core architecture team, to attend some meetings to present information, perhaps they were involved with some technical prototyping and have findings to share with the architects. The best meetings are
  10. 10. short, often no more than half an hour in length, and are often held standing up around a whiteboard – everyone should come prepared to the meetings, willing to present and discuss their issues as well as to work together as a team to quickly come to resolutions. 7. Requirements-Driven Architecture Your architecture must be based on requirements otherwise you are hacking, it’s as simple as that. The practice Active Stakeholder Participation is critical to your success when it comes to identifying architectural requirements – remember, requirements come from project stakeholders, not developers. Good sources for technical architecture requirements will include your users and their direct management as they will often have some insight into technical requirements and constraints. Operations staff will definitely have requirements for you pertaining to your deployment architecture. The best sources for business-oriented requirements are exactly who you would expect – your users, their managers. Senior management within your organization will have insights that may lead to potential change cases for your system. As you would expect the practices Apply The Right Artifact(s) and Create Several Models in Parallel apply to your architectural requirements effort. When you are working on the technical aspects of your architecture you will want to base it on technical requirements, constraints, and possibly change cases. Similarly, when you are working on business aspects of your architecture, potentially identifying software subsystems or business components, you will likely need to focus on essential use cases or user stories that describe critical usage requirements and potentially the key business rules applicable to your system. A common mistake that architecture teams (or for smaller projects the architecture owner) will make is to ignore existing and pertinent artifacts, such as network or deployment diagrams that describe your organizations existing technical infrastructure, enterprise-level business models (use case models, process diagrams, workflow diagrams, corporate business rules, and so on), or corporate deployment standards (for workstations, branch offices, etc.) that your system is expected to conform to. Yes, the existing artifacts may be out of date or simply not apply to your effort, but you should at least make an effort to examine them and take advantage of the existing work wherever possible. A little bit of reading or discussion with the right people is likely to save you significant effort later on. In other words, don’t forget to reuse existing artifacts whenever possible. An important concept to understand about architectural modeling is that although it typically occurs early in your project it never occurs first. Fundamentally, you will always invest time identifying some requirements first. Anything else is hacking, and hacking certainly isn’t agile. 13. Take a Multi-View Approach Agile Modeling's Multiple Models principle advises you to recognize that because modern systems are complex that you will need to consider a range of views in your architecture. Although they take different approaches, a multi-view strategy is a fundamental concept in modern architectural frameworks such as the Zachman Framework, TOGAF, 4+1, and so on. Each of these frameworks have very good reasons for their choice of views, they all seem to work well in practice, they can all be approached in an agile manner, so my advice is to review your options and pick the architectural framework which best reflects the culture of your organization. My goal here isn't to propose yet another architecture framework, it is to make you aware of them and their underlying concepts. Figure 4 overviews the views and concerns which software/system architects need to be concerned about. Figure 4. Architectural views and concerns.
  11. 11. 14. How Does This Work? The architectural approach that I’ve described is markedly different that what a lot of organizations are currently doing today. Table 1 compares and contrasts the architectural practices that are commonly found in many organizations with their agile counterparts. Clearly, there’s a big difference. The agile approach works because of its focus on people working together effectively as a team. Agile Modeling recognizes that people are fallible, that they aren’t likely to get the architecture right to begin with and therefore need the opportunity for acting on feedback from implementation efforts. When agile architects are productive members of the development team, and when the development team has been involved with the architectural efforts to begin with, then comprehensive documentation isn’t needed by them, the navigation diagrams are sufficient (granted, when this is not the case documentation, hopefully minimal, may be required). Architecture reviews aren’t needed because the architecture is being proved through the concrete feedback of architectural prototyping/spikes and because people can see the architecture evolve because your models are displayed publicly for everyone to see. Agile architects have the courage to focus on solving today’s problem today and trusting that they can solve tomorrow’s problem tomorrow (Beck, 2000), and the humility to recognize that they cannot accurately predict the future and therefore choose not to overbuild their architectures. Table 1. Comparing Common and Agile Architectural Practices. Common Practice Agile Practice Architects are held in high esteem and are often placed, or even Agile architects have the humility to admit that they don’t walk on worse place themselves, on pedestals water Agile architects are active members of development teams, Architects are too busy to get their hands dirty with developing software where appropriate and acting as architectural development consultants to the team Agile architects have the humility to admit that they can’t predict Architecture models are robust to enable them to fulfill future the future and instead have the courage to trust they can solve requirements tomorrow’s problem tomorrow The goal is to develop a comprehensive architecture early in a You evolve your architecture incrementally and iteratively, project allowing it to emerge over time
  12. 12. Travel light and focus on navigation diagrams that overview your Well-documented architecture model(s) are required architecture, documenting just enough to communicate to your intended audience Architecture model(s) are communicated only when they are Architecture model(s) are displayed publicly, even when they are “suitable for public consumption” a work in progress, to promote feedback from others Architecture reviews are held to validate your model(s) before Architectures are proved through concrete experiments being put into use Model Type Simple Paper Whiteboard Software Acceptance Test FITNesse Business Rule Card Word Processor Change Case X Card Word Processor Class Responsibility Collaborator (CRC) model X Card Constraint Card Word Processor Contract model As Needed Data Flow Diagram (DFD) X CASE Domain Model X CASE Essential/Abstract Use Case X Flip chart X Word Processor Essential/Abstract User Interface Prototype X Flip chart Feature X Card Spreadsheet Free-Form Diagrams X X Diagramming Tool Diagramming or Flow Chart X CASE Glossary Card Word Processor Logical Data Model (LDM) CASE Network Diagram Diagramming Object Role Model (ORM) Diagram X Personas X Flip chart Word Processor Physical Data Model (PDM) CASE Robustness Diagram X Security Threat Model X System Use Case Word Processor Technical Requirement Card Word Processor
  13. 13. UML 2 Activity Diagram X CASE UML 2 Class Diagram X CASE UML 2 Communication/Collaboration Diagram X UML 2 Component Diagram X CASE UML 2 Composite Structure Diagram X UML 2 Deployment Diagram X CASE UML 2 Interaction Overview Diagram X UML 2 Object Diagram X UML 2 Package Diagram X CASE UML 2 Sequence Diagram X CASE UML 2 State Machine Diagram X CASE UML 2 Timing Diagram X CASE UML 2 Use Case Diagram X CASE Usage Scenario X Card Word Processor User Interface Flow Diagram (Storyboard) X Diagramming Prototyping tool or User Interface Prototype X IDE User Story X Card Spreadsheet Value Stream Map X Agile documents:  Maximize stakeholder investment  Are concise  Fulfill a purpose  Describe information that is less likely to change  Describe “good things to know”  Have a specific customer and facilitate the work efforts of that customer  Are sufficiently accurate, consistent, and detailed  Are sufficiently indexed
  14. 14.  Valid reasons to document:  Your project stakeholders require it  To define a contract model  To support communication with an external group  To think something through