Artifact Model for Project Management

Concepts

This model is taken from a real project (its name will not be mentioned). It was created for the reason that due to the many processes from RUP and the company's processes, confusion arose in the following issues:

• what kind of results you need to get at the output,
• who is responsible for the artifact,
• which group should be responsible for it,
• what tools should be used,
• what are the relationships between artifacts and model elements,
• whether this RUP artifact is used in this project,
• on which iteration this artifact is created,
• what is the level of detail,
• how to associate the artifacts of an existing process with RUP artifacts,
• and so on

Attention!
This information refers to a project in which the RUP methodology was applied to most processes, but not to all, as there were additional processes and the Analysis and Design process was tailored to the specific project. This is not the final RUP model. Think of it only as an idea for a model that can be created for your project.

Introduction

In the first iteration, the process manager, along with the project manager and other collaborators, spent a lot of time determining which artifacts should be created and on which iterations. The level of detail for each artifact and group members was discussed. This was necessary to create an initial description of the project development process, as well as to enable the project manager to develop a plan for iterations of the project and estimate the time frame for implementation.

Problem

Our first problem was that while the planning was going on, the rest of the staff could not start working on the artifacts, but this problem is not related to the solution discussed here, it is characteristic only of some projects. This requires separate discussion.

After we carefully planned the creation of artifacts and explained them to the project manager, we published them in the description of the development process. It immediately became clear that many people misunderstand terms such as "Use Case" (precedent). Some thought it was a little oval scheme in Rose, others thought it was a Word document that contained only text, still others thought it was both, and some thought it was a model of all precedents.

There were other problems, for example, some did not understand the set of tools, where this or that artifact should be located, where it should be looked for, etc.

There was also confusion about who should be responsible for the artifacts, for their creation, for meeting deadlines, etc. Who to contact if something needs to be fixed or improved, etc.

There was also a serious problem with the slang names of artifacts, which were invented despite the fact that artifacts in RUP already have names.

Decision

The solution comes from the fact that since software must contain models and related concepts, so must the development process.

At first, many managers with an administrative bias, such as the project manager, programming manager, user representatives, etc., could not read UML (Unified Modeling Language) and did not even want to understand the model. But soon after some of the simplest concepts of class modeling were explained to them, they understood the meanings of the terms, understood the model, and were able to be responsible for their parts of the model.

Soon it was easy to find forgotten artifacts, to resolve conflicts over the fact that different groups are responsible for one artifact. As a result, we were able to iteratively update the description of the development process, publish the relationships between artifacts, and the distribution of responsibility–who is responsible for which artifact, all using the packages, class models, and operation diagrams described below.

Use

Using color, we specified which artifacts from RUP would be used, which might be used, and which would definitely not be used.
Green = used,
orange = possible,
red = none,
white = decides another group.

• The color of the package also indicated its origin - RUP or own.
• To designate <<artefact>>, <<group>>, << operation>> etc., a system of class designations with stereotypes was used.
• The class attribute fields were used to specify the tool in which the artifact should reside, such as ClearCase, Rose, Word, ReqPro, ClearQuest, Excel, and so on.
• The class attribute field was also used to identify the person responsible for the artifact (the owner of the artifact), responsible for its creation, and so on.
• The key indicated the color designation, how UML was read, and so on.

We had a key to indicate the type of artifact — a RUP artifact, a non-RUP artifact, or a mixed artifact.
We published this model using Rose on our Web site as part of our description of the development process.

Findings

Everyone found this model very useful, so we are going to improve RUP by proposing this model as an alternative form of documenting the description of the development process. If most other processes develop their own models, why not develop a separate model for project management?

Obviously, with the standard RUP model, a particular project can be adjusted to the RUP standard much faster. For small projects, a model is probably not needed at all. The solution to this issue also depends on how familiar the project team is with RUP.