2.3.2 Artifacts

2.3.3 Notes on Artifacts

It contains a list all artifacts that you 'Won't' use and the motives behind your decision for not using them. 

It contains a reference to the project's Configuration Management Plan, which describes the configuration management strategy to be used when working on these artifacts. The CM Plan needs to allow developers to answer questions such as: 

When do I release my artifact? 

Where do I put my newly created or modified artifact?

Where do I find existing artifacts for the project?

If the Development Case is an organization-level development case, this is where you add notes on what each project needs to consider when they decide what to do with the artifact. Use the predefined table below as a starting point.] 

2.3.4 Reports

2.3.5 Notes on the Reports

2.3.6 Additional Review Procedures

2.3.7 Other Issues

2.3.8 Configuring the Discipline

2.4 Artifact Classification (to top)

An artifact is a deliverable of the process. It is often developed within one discipline, though there are exceptions. The artifacts are organized in the discipline where it's created. To describe how an artifact needs to be used, use the following classification scheme (see Guidelines: Classifying Artifacts for details): 

Must

Should

Could

Won't

2.5 Review Procedures (to top)

• Formal-External
• Formal-Internal
• Informal
• None

2.6 Sample Iteration Plans  (to top)

2.6.1 Inception Phase

2.6.2 Elaboration Phase

2.6.3 Construction Phase

2.6.4 Transition Phase

3. Disciplines (to top)

3.1 Business Modeling (to top)

3.1.1 Workflow

3.1.2 Artifacts

3.1.3 Notes on the Artifacts

3.1.4 Reports

3.1.5 Notes on the Reports

3.1.6 Additional Review Procedures

3.1.7 Other Issues

3.1.8 Configuring the Discipline

3.2 Requirements (to top)

3.2.1 Workflow

3.2.2 Artifacts

3.2.3 Notes on the Artifacts

3.2.4 Reports

3.2.5 Notes on the Reports

3.2.6 Additional Review Procedures

3.2.7 Other Issues

3.2.8 Configuring the Discipline

3.3 Analysis & Design (to top)

3.3.1 Workflow

3.3.2 Artifacts

3.3.3 Notes on the Artifacts

3.3.4 Reports

3.3.5 Notes on the Reports

3.3.6 Additional Review Procedures

3.3.7 Other Issues

3.3.8 Configuring the Discipline

3.4 Implementation (to top)

3.4.1 Workflow

3.4.2 Artifacts

3.4.3 Notes on the Artifacts

3.4.4 Reports

3.4.5 Notes on the Reports

3.4.6 Additional Review Procedures

3.4.7 Other Issues

3.4.8 Configuring the Discipline

3.5 Testing (to top)

3.5.1 Workflow

3.5.2 Artifacts

3.5.3 Notes on the Artifacts

3.5.4 Reports

3.5.5 Notes on the Reports

3.5.6 Additional Review Procedures

3.5.7 Other Issues

3.5.8 Configuring the Discipline

3.6 Deployment (to top)

3.6.1 Workflow

3.6.2 Artifacts

3.6.3 Notes on the Artifacts

3.6.4 Reports

3.6.5 Notes on the Reports

3.6.6 Additional Review Procedures

3.6.7 Other Issues

3.6.8 Configuring the Discipline

3.7 Configuration & Change Management (to top)

3.7.1 Workflow

3.7.2 Artifacts

3.7.3 Notes on the Artifacts

3.7.4 Reports

3.7.5 Notes on the Reports

3.7.6 Additional Review Procedures

3.7.7 Other Issues

3.7.8 Configuring the Discipline

3.8 Project Management (to top)

3.8.1 Workflow

3.8.2 Artifacts

3.8.3 Notes on the Artifacts

3.8.4 Reports

3.8.5 Notes on the Reports

3.8.6 Additional Review Procedures

3.8.7 Other Issues

3.8.8 Configuring the Discipline

3.9 Environment (to top)

3.9.1 Workflow

3.9.2 Artifacts

3.9.3 Notes on the Artifacts

3.9.4 Reports

3.9.5 Notes on the Reports

3.9.6 Additional Review Procedures

3.9.7 Other Issues

3.9.8 Configuring the Discipline

4.  Roles (to top)

To describe any changes in the set of roles. For example, it is common that you refine the role  Stakeholder into more than one role. 

To map job positions in the organization to the roles in the RUP. The reason for this is that in some development organizations there are job positions defined. If these job positions are commonly used and have a wide acceptance within the organization, it may be worth doing a mapping between the roles in the RUP, and the job positions in the organization. Mapping job positions to roles can make it easier for people in the organization understand how to employ the RUP. The mapping can also help people understand that roles are not job positions, which is a common misconception.]