Essential Information About Trillium Practices

Conventions

Each practice is uniquely numbered (e.g., 1.1.2.1) according to the following convention:

The following labels are used to provide traceability between Trillium practices and external references, source standards and practices:

SEI       Refers to an SEI CMM v1.1 practice
ISO       Refers to the ISO 9001 Standard or ISO 9000-3 Guideline
Bellcore  Refers to a Bellcore document
MB        Refers to the Malcolm Baldrige National Quality Award Criteria
IEC       Refers to an IEC Standard (i.e., IEC 300)
IEEE      Refers to an IEEE Software Engineering Standard
Trillium  Indicates a practice unique to Trillium which has undergone cus
          tomization in combining one or more of the above references
Roadmap   Indicates a practice that is traceable to the external references
Trillium  given above via another practice within the same roadmap which
          has explicit external references

Guidelines for Interpreting Practices

The intent of this section is to help the reader better understand the way the practices have been designed and worded.

Practices are described in three wording styles which are progressively more difficult to achieve. These styles are not another scale.

The three wording styles are:

Style 1: Something is done (informally).

This style is used to state that:

something is in place or exists,
an activity is performed informally within the organization, and/or

it is performed on a project by project basis.

The practice may or may not state who does the activity. Two examples of this style of practice are:

"1.1.2.1  The organization has a well-defined three-year  business plan
          [Bellcore TR-NWT-000179 3.4.3-4] [MB 3.0] [Trillium]"

"4.1.2.20 Project planning specifies and documents schedules, resources
          and approval  authorities  for  verification  and  validation
          activities [ISO 9001 4.4.2, 4.4.7, 4.4.8]  [ISO 9000-3 5.5.2]
	  [Trillium]"

Style 2: Something is done according to a documented procedure.

This style states that:

an activity is performed,
there is a written procedure explaining how to perform the activity,
the procedure is understood by the practitioners, and

the procedure is consistently used by the practitioners.

An example of Style 2 is:

"4.1.3.12 The project's development  risks  are  identified,  assessed,
          documented, and  managed  according to a documented procedure
	  [SEI CMM Activity 10]."

Style 3: Something is done formally.

This third style includes all the requirements of the second style and adds the following activities:

the content of intermediate product(s) is reviewed,
adherence to the written procedure is reviewed,
records of the review(s) are kept (e.g., review report),
all action items on the review report are tracked until closure, and

the practice is documented and uniformly applied across the organization.

For example:

"5.1.3.9 The  quality  system  is  reviewed   formally  at  appropriate 
         intervals  by  senior  management  to  ensure  its  continuing 
         suitability  and  effectiveness  [ISO 9001 4.1.3]  [ISO 9000-3 
	 4.1.13] [Bellcore TR-NWT-000179 2.1.1-2 & 4.4.3-1] [Trillium]"

Definitions

The definitions and terms found in Trillium are based on industry-wide accepted terminology. They can be found in the Glossary (see Appendices).

Where possible, the following order of precedence has been used:

ISO 8402:1991 Draft International Standard
ISO/IEC JTC1/SC7 Vocabulary
ISO/IEC JTC1/SC7 WG10 Vocabulary
Other sources (e.g., IEEE 610 Software Engineering Standards)

There are some instances where the order of precedence has not been respected. As an example of this, the definition of specification from IEEE 610 was used instead of the definition from ISO 8402:1991 as it was more suitable to the context of this document.

When a definition cannot be found in the preceding documents, other sources are used. Only when no definition can be found is a new definition created.

In the process of preparing for an assessment, it may be necessary to adapt or translate the Trillium terminology and definitions into the common language, culture and context of the organization. This is done to minimize the variation due to interpretation by participants. This must be done carefully to ensure that the scope and intent of each practice is not altered.

The definitions below can also be found in the Glossary. They are included in this section because they are crucial to understanding the Model.

Component:

One of the parts that make up a system. A component may be hardware or software and may be subdivided into other components (IEEE 610:1991).

Development:

All activities performed to create or enhance a product.

Function:

In management, a major activity or group of activities that are continuous. For example, the principle functions of management are planning, organizing, staffing, directing, and controlling.
In project management: an activity or set of activities that span the entire duration of a software project. Examples of project functions include configuration management, quality assurance, and project cost accounting.
In programming: a specific, identifiable task performed by one or more software components.

Intermediate Product:

An item which is produced during some phase of the software development process, and is an input product to a later phase, but is not provided to the user. Examples of intermediate products are: requirements specifications, design specifications, and test reports.

Organization:

A company, corporation, firm, enterprise or institution, or part thereof, whether incorporated or not, public or private, that has its own functions and administration (ISO 8402:1991).

Note: In the Trillium context, an assessment is generally applied to a complete organization, or part thereof, that is responsible for the development of a specific product.

Process:

A set of interrelated resources and activities which transform inputs into outputs. Resources may include personnel, facilities, equipment, technology and methodology (ISO 8402:1991).

Product:

The result of activities or processes. A product may include service, hardware, processed materials, software, or combination thereof (ISO 8402:1991).

Note: in the Trillium context, the customer perceives the product as a black box entity provided by the supplier. The customer sees only the interfaces which provide access to the product's operation. Generally the customer has no view of the internal components inside the black box.

Requirements:

An essential set of conditions that a system has to satisfy (ISO 2382-20:1991).

Software:

A set of programs, associated data, procedures, rules, documentation, and materials concerned with the development, use, operation, and maintenance of a computer system (CSA Q396:1989).

Note: in the Trillium context, this includes firmware regardless of its final manufactured form (e.g., PROM, Gate Array).

Specification:

A document that specifies, in a complete, precise, and verifiable manner, the requirements, design, behaviour, or other characteristics of a service, product, system or component, and, often, the procedures for determining whether these provisions have been satisfied (IEEE 610:1991).

System:

A collection of components organized to accomplish a specific function or set of functions (IEEE 610:1991).

Back to the Trillium home page.
[TOC]

To the detailed Trillium table of contents.
[TOC]

Back one chapter.
[TOC]

Forward to capability area 1.