Guidelines: Important
Decisions in Analysis & Design
Topics
- Decide How to Perform the Workflow
- Decide How to Use Artifacts
- Decide Which Reports to Use
- Decide How to Review
- Decide Whether to Generate Code
Decide How to Perform the
Workflow 
The following decisions should be made regarding the Analysis & Design discipline's workflow:
- Decide how to perform the workflow by looking at the Analysis & Design: Workflow. Study the diagram with its guard conditions, and the guidelines. Decide which workflow details to perform and in which order.
- Decide what parts of the Analysis & Design workflow details to perform. The following parts can be introduced relatively independently from the rest.
Part of workflow |
Comments |
|---|---|
| User interface design | Some projects decide to not design the user interface. One reason could be that the user interface is easy to develop. If you decide to not do user-interface design it means that you do not develop a Navigation Map and a User-Interface Prototype. |
| Database design | Only used if the entities are going to be stored in a database. If you decide against doing database design, it means that you do not develop any Data Model. |
| Real time, using Rational Rose RealTime | If you decide to not do this, it means that you do not develop artifacts such as Capsule and Protocol. |
- Decide when, during the project lifecycle, to introduce each part of the workflow. It is sometimes possible to wait until the Elaboration phase before introducing the Analysis & Design discipline. For example, if the development is in a well-understood domain, does not have demanding performance (or other non-functional) requirements, and will be based on a well-tried architecture, there is little need for prototyping during inception.
Document the decisions in the Development Case, under the headings Disciplines, Analysis & Design, Workflow .
Decide How to Use Artifacts
Make a decision about what artifacts to use and how to use each of them. The table below describes mandatory artifacts and those artifacts used only in certain cases. For more detailed information on how to tailor each artifact, and a discussion of the advantages and disadvantages of that specific artifact, read the section titled "Tailoring" for each artifact.
For each artifact, decide how the artifact should be used: Must, Should, Could or Won't. For more details, see the Guidelines: Classifying Artifacts.
| Artifact | Purpose |
Tailoring (Optional, Recommended) |
|---|---|---|
| Analysis model (Analysis class) | An analysis model is useful to better understand the requirements before making design decisions. On complex systems it may be maintained to provide a conceptual overview of the system. |
Optional On many projects, an initial Design Model is used in place of the Analysis Model. On projects which do create an Analysis Model, it is typically a temporary artifact which evolves into a design model. |
| Projects with a large and complex user-interface should consider user-interface design. |
Optional More informal user-interface design may be sufficient on smaller development efforts. |
|
| Design
model |
Most systems, even smaller systems, should be designed before being implemented in order to avoid costly rework due to design errors. Visual models allow the design to be easily communicated. Tools for forward engineering and reverse engineering can ensure consistency with the implementation model and save effort. |
Recommended for most projects. On smaller projects, the use of automated tools is not critical, but may have long term productivity benefits. |
|
|
Classes and packages are a basic part of any object-oriented design. Object-oriented design is the standard design approach used on most projects. |
Recommended for most projects. The main tailoring issues are deciding which stereotypes to use (this may be captured in the Design Guidelines). |
|
|
Provide the bridge from use cases to design. |
Recommended for most projects. |
|
|
Interfaces are typically used to define behavior independently from large-grained components that realize the behaviour. |
Recommended for most projects. Component-based design is becoming a standard design approach. |
|
|
Design Subsystems are used to encapsulate behavior inside a component that provides interfaces. It is used to encapsulate the interactions of classes and/or other subsystems. |
Recommended for most projects. Subsystems are often useful to raise the level of design abstraction. They make systems easier to be understood. |
|
|
May be useful for systems that respond to many external events. | Recommended for real-time systems. |
|
|
Required for real-time systems. | Recommended for real-time systems. |
|
|
May be useful for systems that require concurrency and are event-driven. Required for real-time systems. |
Recommended for real-time systems.. May be useful for systems that require concurrency and are event-driven. |
|
|
For real-time systems, but can be useful in modeling and designing any system that has a high degree of concurrency. |
Recommended for real-time systems. |
| Data model | Used to describe the logical and possibly physical structure of the persistent information. |
Recommended for projects that use a database. |
| Deployment Model | Shows the configuration of processing nodes at run-time, the communication links between them, and the component instances and objects that reside on them. |
Optional. Many systems have multiple processing nodes and therefore need to address the Deployment Model. It may, however, be captured as a section of the Software Architecture Document and does not need to exist as a separately identified artifact. |
| Architectural Proof-of-Concept | Used to determine whether there exists a solution that satisfies the architecturally-significant requirements. | Recommended for most projects.
Many projects will use an Architectural Proof-of-Concept to determine the feasibility of requirements. It may take many forms, for example:
|
| Reference Architecture | Reference Architectures speed up development and reduce risks by re-using proven solutions. |
Recommended for most projects. If suitable Reference Architecture material exists, it can dramatically speed up development and reduce risk. |
| Software Architecture Document (SAD) | The Software Architecture Document is used to provide a comprehensive architectural overview of the system. This overview is helpful to understand the system, and to capture key architectural decisions. |
Recommended for most projects. A high level overview of the software architecture is useful on all but the smallest systems. Complex systems typically require a greater level of detail and more views than smaller projects. |
| User-Interface Prototype | Used to expose and test functionality and usability before the real development starts. It is an effective means of validating the design before too much time is wasted. |
Recommended for most projects. |
Tailor each artifact to fit the needs of the project. For tailoring considerations, see the tailoring section of the artifacts' description page, or the steps described under the heading "Tailor Artifacts per Discipline" in the Activity: Develop Development Case.
Decide Which Reports to Use
The decision of which reports to use will depend on the reporting tools available to the project. If report generation tools are available, we recommend generating reports for model oriented artifacts, such as Design Classes, Use-Case Realizations. Existing reports in your RUP configuration are available from the artifact description pages or grouped under the relevant artifact in the treebrowser.
Decide How to Review
Decide on the review level for each artifact and capture it in the development case. See Guidelines: Review Levels for details. Decide how to review and approve the results of Analysis & Design, and to what extent the results will be reviewed.
The advantages of a design review are:
- It detects problems that are impossible, or very difficult, to detect in testing. For example, issues of style, and layout.
- It is a way to enforce a common modeling style and an opportunity for individuals to learn from each other.
- It detects those defects that wouldn't otherwise get detected until later in the project during tests.
The disadvantages of a design review are:
- It takes time and resources.
- It is easily misused if not managed well.
The factors that can be altered are review techniques, resources, and scope. The following are some examples of what you can decide to do on your project:
- Decide that local changes to a subsystem are reviewed only by one peer, who conducts an inspection and hands over the results on paper.
- Decide on which parts of the design will not be reviewed at all; for example, review only some classes for each member of the project and hope that this assures the style is of a similar quality to the rest of the results.
- Decide that the Software Architecture Document will be reviewed by customer during a separate meeting.
- Decide to use formal review meetings for changes in important interfaces; that is, interfaces that affect the work of several project members.
For more information about reviewing and different kinds of reviews, see Work Guideline: Reviews.
Decide Whether to Generate Code
The way you do design differs depending on whether you generate code from the design model or not. If you generate code, the design needs to be very detailed. On the other hand, if you do not generate code from the design, there is no need to be very detailed in the design. On the contrary, the details in the design have to be synchronized manually with the code.
