Guidelines: Important
Decisions in Environment
Topics
Decide How to Perform the
Workflow 
The following decisions should be made regarding the Environment discipline's workflow:
- Decide how to perform the workflow by looking at the Environment: 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 Environment workflow details to perform. In general, the artifacts in the Environment discipline are introduced as they are needed. For example, a Manual Styleguide is developed only if the project will develop End-User Support Material.
- Decide when, during the project lifecycle, to introduce each part of the workflow. More information look at Environment: Workflow. The Artifact: Development Process is always introduced in the beginning of a project, with Artifact: Development Case to document the detailed, project-specific, tailoring decisions. The other artifacts are introduced when they are needed.
Decide How to Use Artifacts
Decide which artifacts to use and how to use each of them. The table below describes those artifacts you must have and those used in some 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 have, Should have, Could have or Won't have. For more details, see Guidelines: Classifying Artifacts.
| Artifact | Purpose |
Tailoring (Optional, Recommended) |
|---|---|---|
| Development Process | Documents the development process configured for the project. Provides the team members with access to all relevant process guidance. | Recommended for all projects. |
| Development Case | This artifact fine-tunes the development process to meet the exact needs of the project, including details on which artifacts to produce, and when. |
Optional in small projects as the development process artifact can be sufficient. Recommended for medium to large projects. |
| Project Specific Guidelines | Project specific guidelines are appropriate whenever there are project-specific standards that must be followed, or good practices that need to be communicated. |
Recommended as applicable to project activities. Many projects will reuse guidelines rather than create their own. Small teams with experienced members and a shared philosophy may decide not to formally document some guidelines. The risk in this case is that standards and quality may drift over time. |
| Project-Specific Templates | Helps jump-start production of document centric and model centric artifacts and ensures consistency between artifacts. |
Recommended as applicable to project artifacts. |
| Development Infrastructure (including Tools) | This is the hardware and software tools used as part of development. | All projects will have a Development Infrastructure. Many projects will reuse an existing development infrastructure, rather than create their own. |
| Development-Organization Assessment | Used to guide the process engineer in tailoring a process for an organization. |
Optional. In large organizations, an assessment is usually critical to making good process-related decisions. |
| Manual Styleguide | Ensures consistent style and quality of end-user support material. |
Recommended for most projects with end-user support material. Many projects will reuse an existing styleguide rather than create their own. |
Tailor each artifact by performing the steps described in Activity: Develop Development Case, under the heading "Tailor Artifacts per Discipline".
