Model Description

Scope

The Trillium Model covers all aspects of the software development life-cycle, most system and product development and support activities, and a significant number of related marketing activities.

Although Trillium has been designed to be applied to embedded software systems such as telecommunications systems, much of the model can be applied to other segments of the software industry such as Management Information Systems (MIS).

Many of the practices described in the model can be applied directly to hardware development.

Model Foundation

The Trillium Model is based on the Software Engineering Institute (SEI) Capability Maturity Model (CMM) version 1.1.

The architecture of the Trillium Model differs from the CMM version 1.1. The most significant differences are:

a model architecture based on roadmaps, rather than key process areas,
a product perspective, rather than software,
wider coverage of capability impacting issues, and
a customer focus, technological maturity, and a telecommunications orientation.

This version of the Trillium Model covers all SEI CMM v1.1 activities and abilities and some of the commitments, measurements and verifications (see Appendices for details of coverage).

In addition to the above, this version of the Model incorporates the intent of:

ISO 9001: 1994 International Standard,
ISO 9000-3: 1991 Guideline,
Bellcore TR-NWT-000179 Issue 2, June, 1993,
Bellcore TA-NWT-001315 Issue 1, December, 1993,
relevant parts of the Malcolm Baldrige National Quality Award, 1995 Award Criteria,
IEEE Software Engineering Standards Collection, 1993 Edition, and
the IEC Standard Publication 300: 1984.

The Trillium Model incorporates additional practices from the following topics:

Quality Management
Business Process Engineering
Technological Maturity
Development Environment
Systems Engineering
Co-Engineering
Concurrent Engineering
Reliability Engineering
Customer Support/Partnership
Usability Engineering

The Trillium Scale

The Trillium scale spans levels 1 through 5. The levels can be characterized in the following way:

Unstructured: The development process is adhoc. Projects frequently cannot meet quality or schedule targets. Success, while possible, is based on individuals rather than on organizational infrastructure. (Risk - High)
Repeatable and Project Oriented: Individual project success is achieved through strong project management planning and control, with emphasis on requirements management, estimation techniques, and configuration management. (Risk - Medium)
Defined and Process Oriented: Processes are defined and utilized at the organizational level, although project customization is still permitted. Processes are controlled and improved. ISO 9001 requirements such as training and internal process auditing are incorporated. (Risk - Low)
Managed and Integrated: Process instrumentation and analysis is used as a key mechanism for process improvement. Process change management and defect prevention programs are integrated into processes. CASE tools are integrated into processes. (Risk - Lower)
Fully Integrated: Formal methodologies are extensively used. Organizational repositories for development history and process are utilized and effective. (Risk - Lowest)

Architecture of the Trillium Model

The Trillium Model consists of Capability Areas, Roadmaps and Practices.

Capability Areas

There are 8 Capability Areas within the Trillium model. Each Capability Area contains practices at multiple Trillium levels. For example, Management spans levels 2 to 4 while Quality System spans levels 2 to 5. The span of each Capability Area is shown in the following table.

--------------------------------------------------------------------------
                                                 |  Contains practices   |
              Trillium capability area           |       at level        |
                                                 |  2  |  3  |  4  |  5  |
--------------------------------------------------------------------------
          Organizational Process Quality         |__X__|__X__|__X__|_____|
    Human Resource Development and Management    |__X__|__X__|__X__|_____|
                      Process                    |__X__|__X__|__X__|__X__|
                    Management                   |__X__|__X__|__X__|_____|
                      Quality                    |__X__|__X__|__X__|__X__|
            System Development Practices         |__X__|__X__|__X__|__X__|
              Development Environment            |__X__|__X__|__X__|__X__|
                 Customer Support                |__X__|__X__|__X__|_____|
--------------------------------------------------------------------------

Capability Profile

A profile of the Capability Areas is an important measure of a software development organization since it illustrates the relative areas of strength and weakness. The following figure shows a sample profile. As can be seen in this profile, organizations typically achieve some higher level practices without having completed all the practices at the lower levels (e.g., DE, QS).

Capability Level

To achieve a Trillium level, an organization must satisfy a minimum of 90% of the criteria in each of the 8 Capability Areas at that level. Levels 3, 4 and 5 require the achievement of all lower Trillium levels (i.e., levels cannot be skipped).

Roadmaps

Each Capability Area incorporates one or more roadmaps. A roadmap is a set of related practices that focus on an organizational area or need, or a specific element within the product development process. Each roadmap represents a significant capability for a software development organization.

Within a given roadmap, the level of the practices is based on their respective degree of maturity. The most fundamental practices are at a lower level whereas the most advanced ones are located at the higher level. An organization matures through the roadmap levels.

Lower level practices must be implemented and sustained for higher level practices to achieve maximum effectiveness.

The following table lists the roadmaps contained within each capability area, as well as the distribution of practices by maturity level and capability area.

------------------------------------------------------------------------------------------
    Trillium    |                                         |  Number of Practices  |       |
   Capability   |                Roadmaps                 |        by Level       |       |
     Areas      |                                         |  2  |  3  |  4  |  5  | Total |
================+=========================================+=====+=====+=====+=====+=======+
Organizational  | Quality Management                      | 10  | 20  |  5  |  0  |   35  |
Process Quality | Business Process Engineering            |     |     |     |     |       |
----------------+-----------------------------------------+-----+-----+-----+-----+-------+
Human Resource  | Human Resource Development and          |  9  | 42  |  1  |  0  |   52  |
Development and | Management                              |     |     |     |     |       |
Management      |                                         |     |     |     |     |       |
----------------+-----------------------------------------+-----+-----+-----+-----+-------+
Process         | Process Definition                      | 16  | 55  | 24  |  4  |   99  |
                | Technology Management                   |     |     |     |     |       |
                | Process Improvement & Engineering       |     |     |     |     |       |
                | Measurements                            |     |     |     |     |       |
----------------+-----------------------------------------+-----+-----+-----+-----+-------+
Management      | Project Management                      | 74  | 29  |  4  |  0  |  107  |
                | Subcontractor Management                |     |     |     |     |       |
                | Customer-Supplier Relationship          |     |     |     |     |       |
                | Requirements Management                 |     |     |     |     |       |
                | Estimation                              |     |     |     |     |       |
----------------+-----------------------------------------+-----+-----+-----+-----+-------+
Quality System  | Quality System                          | 14  | 15  |  2  |  2  |   33  |
----------------+-----------------------------------------+-----+-----+-----+-----+-------+
Development     | Development Process                     | 41  | 49  | 15  |  5  |  110  |
Practices       | Development Techniques                  |     |     |     |     |       |
                | Internal Documentation                  |     |     |     |     |       |
                | Verification & Validation               |     |     |     |     |       |
                | Configuration Management                |     |     |     |     |       |
                | Re-Use                                  |     |     |     |     |       |
                | Reliability Management                  |     |     |     |     |       |
----------------+-----------------------------------------+-----+-----+-----+-----+-------+
Development     | Development Environment                 |  4  |  6  |  1  |  1  |   12  |
Environment     |                                         |     |     |     |     |       |
----------------+-----------------------------------------+-----+-----+-----+-----+-------+
Customer Support| Problem Response System                 | 25  | 30  |  5  |  0  |   60  |
                | Usability Engineering                   |     |     |     |     |       |
                | Life-Cycle Cost Modelling               |     |     |     |     |       |
                | User Documentation                      |     |     |     |     |       |
                | Customer Engineering                    |     |     |     |     |       |
                | User Training                           |     |     |     |     |       |
----------------+-----------------------------------------+-----+-----+-----+-----+-------+
                                                   Total: | 193 | 246 | 57  | 12  |  508  |
-------------------------------------------------------------------------------------------

Relationship to other Standards

The following table provides a high level indication of the alignment of Trillium levels with key industry indicators and the standards which it encapsulates.

------------------------------------------------------------------------------------------
Key Industry   LEVEL 1  LEVEL 2          LEVEL 3                LEVEL 4        LEVEL 5
Indicators
------------------------------------------------------------------------------------------
Process        Ad-hoc   Project based    Organization-wide
Standards      None     IEEE(a),         SEI Level 3+,          SEI Level 4+,  SEI Level 5
                        SEI Level 2+     ISO 9001,
                        Bellcore         IEC 300c (system),
                        TR-NWT-          IEEE(b),
                        000179 (75%)     Bellcore
                                         TR-NWT-00179
Process        None     Unstructured     Deployed               Systematic
Improvement
------------------------------------------------------------------------------------------

(a): a. Stds. 730, 828, 830, 1016, 1028, 1058.1, 1063.
(b): b. Std. 1012.c. as applicable to the hardware component of a system

Achieving level 3 on the Trillium scale means that an organization meets the intent of the following:

SEI Level 3,
ISO 9001 (and the associated ISO 9000-3 Guidelines for Software),
IEC 300 for system,
IEEE Standards 730, 828, 830, 1012, 1016, 1028, 1058.1, 1063,
Bellcore TR-NWT-000179,
the relevant parts of the Malcolm Baldrige National Quality Award Criteria, and
additional Trillium practices not covered by these standards.

Meeting the requirements of a Trillium practice does not necessarily imply meeting all the requirements of the corresponding referenced standards or documents.

Note: The IEEE Software Engineering Standards are mostly oriented towards work products, e.g., software design description, project management plan. For the purpose of Trillium, these are used as guidelines only.

How Trillium Practices are Developed

The set of practices in the Trillium model is built using the following algorithm:

Practices are taken from the SEI CMM Version 1.1.
ISO 9001 and ISO 9000-3 clauses are mapped to this set of practices and where possible, practices are modified to integrate these requirements.
All remaining ISO 9001 and ISO 9000-3 clauses (i.e., which could not be mapped) are added to the set of practices.
Bellcore standards clauses are mapped to the practices generated by steps 1, 2 & 3. Where possible practices are modified to integrate these requirements.
All remaining Bellcore standards clauses (i.e., which could not be mapped) are added to the set of practices.
The same process is repeated with relevant portions of the Malcolm Baldrige National Quality Award Criteria.
Practices from IEC 300 are added.
References to relevant IEEE standards are added.
Trillium specific practices are added to provide coverage of additional areas important to the telecommunications industry. These are based on professional benchmarks generated through the consensus of subject matter experts and validated in a peer review process.

When practices are extracted from the CMM, or other standards, they go through the following transformation, if applicable:

The practice is generalized by either removing references to "software", or replacing them by "product and services" or "systems".
The practice is generalized by either removing references to "development", or replacing them by "development and support".
References to "group" or other specific organizational units are replaced by "function".
Indirect references to specific documents are replaced by references to a process (e.g., "quality plan" by "quality planning"), or to "documentation" or "information".

Practices are assigned to a given level based on the following general guidelines.

Practices that are considered fundamental for the successful conclusion of a development project are assigned to level 2.
Practices that are considered to be organization-wide in scope or fundamental to the continuous improvement of the development process are assigned to level 3.
Practices that deal with CASE technology or characterize advanced process maturity (e.g., change management, integration of defect prevention, statistical process control and advanced metrics) are generally assigned to level 4.
Level 5 typically deals with advancing technology as it applies to process automation, formal methodologies and strategic utilization of organization repositories.

Back to the Trillium home page.
[TOC]

To the detailed Trillium table of contents.
[TOC]

Back one chapter.
[TOC]

Forward one chapter.