A typical software development lifecycle requires the development, evolution, and management of things other than source files
such as requirements, models, graphics, change requests, schedules, tests, and so on. The term
artifact refers to the generalization of objects that can be versioned, branched, merged, etc.
StarTeam supports non-file artifact types directly, providing type-specific behavior for storage, versioning, merging and so forth.
All artifacts are versioned, and some are branchable.
The built-in artifact types supported by
StarTeam are summarized below:
- Folder
- Every view has one
root folder, which typically has a tree of subfolders beneath it. Folders are patterned from the file system concept of directories.
In many cases, you will want to create
StarTeam folders that mirror specific directory structures. However,
StarTeam folders can hold any kind of artifact, not just files. This concept may seem strange at first, but when you discover that
you can organize change requests, tasks, and other non-file artifacts the same way you organize files, you will find this
feature very powerful. Folders can branch, allowing the same folder to have different properties in each branch.
- File
- StarTeam allows you to store any kind of file: text or binary, authored or generated, small or very large. A few more features are
provided for text files such as
keyword expansion and
EOL conversion, but all file types otherwise are treated identically.
StarTeam allows single file revisions larger than 4GB. Files are branchable, allowing parallel version streams and merging.
- Change Request
- A
change request (CR) is a general artifact that can represent a defect, enhancement request, or another reason for a software change. Because
CRs are often the center of change management, the CR type is frequently extended with custom fields, custom GUI forms, and
workflow rules. CRs can branch, allowing parallel modifications to the same CR for separate activities such as fixing the
same defect in multiple releases. Using integration tools, you can import CRs from and keep them synchronized with other defect
management systems.
- Task
-
StarTeam
tasks are modeled after project management tasks: they can be arranged hierarchically to represent task decomposition, they can
be connected with predecessor/successor relationships, and they can be updated with progress units known as
work records. You can import tasks from a project management system such as Microsoft Project, update and maintain them via
StarTeam, and then synchronize them back to the original project source. In
StarTeam, tasks are versioned but they do not branch.
- Topic
- A
topic is very similar to a newsgroup message. Like newsgroup messages, topics can be organized into conversation threads. Because
topics are artifacts, they are versioned (but not branched) and are stored in the repository with other artifacts. This allows
you to capture more application lifecycle knowledge such as important discussions related to a design decision or a requirement
approval.
- Requirement
- If you do not have a formal requirements management (RM) tool,
StarTeam requirements provide a convenient, lightweight artifact with which requirements can be captured. Requirements can be arranged
hierarchically to represent decomposition, and they can be linked to other artifacts. Since requirements are independently-versioned
artifacts, they are more accessible than requirements buried in documents, which are versioned at the whole-document level.
If you use a requirements management system such as
Caliber, those “formal” requirements can be imported as
StarTeam requirements and organized together with other lifecycle artifacts. We provide integration tools to import, synchronize,
and even link artifacts between
StarTeam and
Caliber. Requirements do not branch.
- Audit
- An
audit is a read-only
change event artifact that is automatically generated for other artifact changes: add, modify, delete, move, label attach, link, etc.
Because audits are automatically generated and immutable, they are not really artifacts per se, but
StarTeam allows you to access them with similar GUI and SDK techniques as other artifacts, so you can think of them as read-only artifacts.
The generation of audits and the length of time that they are retained are configurable.
These artifacts are all bundled with
StarTeam, however you are not obligated to use them all. The code for each artifact type is encapsulated in a dynamically-loaded plug-in
module called a
server-side component (SSC). Each SSC is a code library suffixed with
.ssc that resides in the
StarTeam Server’s installation directory. If you rename an
.ssc module before the server starts, the corresponding artifact type will not be used. For example, if you want to use
StarTeam as a VCS only, just rename all
*.ssc modules except for
file.ssc.
Note: You always get folders, so there is no
.ssc module for it. Also, we recommend you keep
audit.ssc due to the value of the
change log represented by audit artifacts.