Trillium Capability Areas, Roadmaps and Practices
Capability Area 6: Development Practices

This Capability Area covers the following 7 Roadmaps:

It addresses most of the processes, procedures and activities central to product development.

Roadmap 6.1: Development Process

Level 2

Implementation

6.1.2.1
Implementation activities (e.g., construction, coding) are conducted according to documented procedures [ISO 9000-3 5.6.3] [Trillium].

Funding

6.1.2.2
Adequate resources and funding are provided for performing the engineering tasks [SEI SPE Ability 1] [ISO 9001 4.1.2.2] [Trillium].

Level 3

Policy

6.1.3.1
The project follows a written organizational policy for performing development activities [SEI SPE Commitment 1] [Bellcore TR-NWT-000179 2.5.1-1 & 3.4.2-5,6,7,8,9,10 & 3.7.2-2].

Process

6.1.3.2
The organization's standard product development process defines the development methods to be used and the intermediate products generated during each development phase [ISO 9001 4.4.1] [ISO 9000-3 5.4.2.1, 5.4.3, 5.4.5 & 5.6.1] [Bellcore TR-NWT-000179 3.4-1 & 3.4.2-5 & 3.6-1 & 4.1.1-3 & 4.6-2,7] [Trillium] (Ref. IEEE Std. 1074).

6.1.3.3
The system requirements specification is reviewed and agreed formally [SEI SPE Activity 2].

6.1.3.4
The design specification is developed formally [SEI SPE Activity 3] [ISO 9001 4.4.4] [ISO 9000-3 5.6.2] [Bellcore TR-NWT-000179 3.6.1-1 & 3.6.2-1].

6.1.3.5
Code is developed formally according to a documented procedure to ensure that the design is met [SEI SPE Activity 4] [ISO 9000-3 5.6.3] [Bellcore TR-NWT-000179 3.6.1-1,2].

Product Architecture

6.1.3.6
The product development process requires the development of a well-defined and consistent product architecture [Roadmap Trillium 6.1.3.7].

6.1.3.7
The organization defines a group that owns and is accountable for the architecture of each product or product line throughout its entire life-cycle [Bellcore TR-NWT-000179 3.4.2-6,7,8,9] [Trillium].

Level 4

Process Model

6.1.4.1
A process model is maintained and used to evaluate the effect of process changes on the organization [Roadmap Trillium 6.1.3.2].

6.1.4.2
A process model is maintained and used to evaluate the effect of process changes on customer satisfaction [Roadmap Trillium 6.1.3.2].

Roadmap 6.2: Development Techniques

Level 2

High Level Languages

6.2.2.1
State of the practice high-level languages (e.g., PROTEL, C, Pascal, Ada) are used appropriately for all software products [Bellcore TR-NWT-000179 2.5.1-1] [Trillium].

Analysis and Design

6.2.2.2
Analysis and design (e.g., SA/SD, OOA/OOD) are done according to a documented procedure [ISO 9001 4.4.1] [Trillium].

Dependencies

6.2.2.3
The module, process and data dependencies are documented for the project [Bellcore TR-NWT-000179 3.6.2-1] [Trillium].

Level 3

Analysis and Design

6.2.3.1
Analysis and design (e.g., SA/SD, OOA/OOD,) are done formally according to a documented procedure [ISO 9000-3 5.6.2] [Bellcore TR-NWT-000179 3.6.2-1 & 3.10.3-4] [Trillium].

Performance Modeling

6.2.3.2
Modelling techniques are used to assess product performance during the product development process [Trillium].

Prototyping

6.2.3.3
Prototyping techniques are used to verify the correctness of critical specification items (e.g., user interface specification) with the customer [Trillium].

6.2.3.4
Prototyping techniques are used to explore design options and validate design decisions prior to implementation [Trillium].

Code Generation

6.2.3.5
Code skeletons are automatically generated from designs by CASE tools [Roadmap Trillium 6.2.3.1].

Code Metrics

6.2.3.6
Source code metrics (e.g., code complexity) are taken and compared to a predefined set of permissible values according to a documented procedure [Trillium].

Level 4

Formal Methods

6.2.4.1
Formal methods (e.g., VDM, Z, LOTOS) are used for the development of critical software components [Roadmap Trillium 6.2.3.1].

6.2.4.2
Proof of correctness is performed for critical software components [Roadmap Trillium 6.2.3.1].

CASE Tools

6.2.4.3
CASE tools are used to automatically generate prototypes and design specifications [Roadmap Trillium 6.2.3.5].

Design Metrics

6.2.4.4
Design complexity is measured and compared to the organizational baseline according to a documented procedure [Trillium].

Level 5

Constructive development

6.2.5.1
Constructive development methods (i.e., methods in which concrete intermediate products are constructed from abstract intermediate products) are used for most development tasks [Trillium].

Code Generation

6.2.5.2
The majority of source code (>80%) is automatically generated by CASE tools [Trillium].

Executable Generation

6.2.5.3
Executables are automatically generated by CASE tools [Trillium].

Roadmap 6.3: Internal Documentation

Level 2

Requirements

6.3.2.1
Requirements are documented according to a documented procedure [ISO 9001 4.4.1] [Bellcore TR-NWT-000179 3.4.2-9 & 4.2-1] (Ref. IEEE Std. 1016).

Design

6.3.2.2
Design is documented according to a documented procedure [Bellcore TR-NWT-000179 3.4.2-9 & 4.2-1] (Ref. IEEE Std. 1016).

Code

6.3.2.3
Code is documented according to a documented procedure [Bellcore TR-NWT-000179 3.4.2-9 & 4.2-1] [Trillium].

Test Cases

6.3.2.4
Test cases are documented according to a documented procedure [Bellcore TR-NWT-000179 3.4.2-9 & 3.7.2-5 & 4.2-1] (Ref. IEEE Std. 829).

Level 3

Development and Maintenance

6.3.3.1
The documentation that will be used to operate and maintain the product/service is developed and maintained according to the project's defined process [SEI SPE Activity 8] [ISO 9001 4.5.1, 4.5.2] [Bellcore TR-NWT-000179 3.4.2-9 & 3.7.2-2 & 4.2-1] [Trillium].

Requirements

6.3.3.2
Requirements are documented formally [Roadmap Trillium 6.3.2.1].

Design

6.3.3.3
The design is documented formally [Roadmap Trillium 6.3.2.2].

6.3.3.4
The rationale for all aspects of design is formally documented [Trillium].

Code

6.3.3.5
Code is documented formally [Roadmap Trillium 6.3.2.3].

Test Cases

6.3.3.6
Test cases are documented formally according to a documented procedure [Bellcore TR-NWT-000179 3.7.2-3] [Trillium].

Conformance to Standards

6.3.3.7
Conformance to requirement, design, coding, and test case standards is verified by a peer review process [ISO 9001 4.4.7] [Trillium].

Notation

6.3.3.8
The standard for requirements and design documents specifies the use of structured and formal notations where appropriate [Trillium].

Updates

6.3.3.9
When the product is modified (e.g., to correct a defect or add a feature) the requirements and design documents for affected units are updated if needed to reflect the change [Trillium].

Roadmap 6.4: Verification & Validation

Level 2

Planning

6.4.2.1
The verification and validation activities (e.g., testing, peer reviews) are formally planned and the plans are documented according to a documented procedure [SEI PR Activity 1] [ISO 9001 4.4.1, 4.4.8, 4.10.1, 4.11] [ISO 9000-3 4.1.1.2.2, 5.4.6, 5.7.1, 5.7.2] [Bellcore TR-NWT-000179 2.1.2-1 & 3.7-1 & 3.7.1-6 & 3.7.2-6 & 3.8-2] [Trillium] (Ref. IEEE Std. 1012).

Funding

6.4.2.2
Adequate resources and funding are provided for performing peer reviews on each work product to be reviewed [SEI PR Ability 1] [ISO 9001 4.1.2.2] [ISO 9000-3 4.1.1.2.2, 5.7.2] [Bellcore TR-NWT-000179 3.7.1-6 & 3.8-5].

Peer Reviews

6.4.2.3
Peer reviews are conducted on intermediate work products [ISO 9000-3 4.10.2, 5.4.6, 5.6.4] [Bellcore TR-NWT-000179 3.4.2-12 & 3.6.2-1& 3.7.2-6] [Trillium].

System Testing

6.4.2.4
System and acceptance testing are planned and performed formally to demonstrate that the product satisfies its requirements [SEI SPE Activity 7] [ISO 9001 4.4.1, 4.10.3, 4.10.4, 4.10.5] [ISO 9000-3 5.7.1, 5.7.3 & 5.8] [Bellcore TR-NWT-000179 3.7.1-1,8 & 3.7.2-7 & 3.8-1] (Ref. IEEE Std. 1012).

Operational Testing

6.4.2.5
Where testing under field conditions is required, the following are considered: the features to be tested, responsibilities of both parties, and post-test restoration of the user environment [ISO 9001 4.10.3, 4.10.4, 4.11] [ISO 9000-3 5.7.1, 5.7.3, 5.7.4, 5.7.5] [Bellcore TR-NWT-000179 3.7.1-1,8 & 3.8-3] [Trillium].

Regression Testing

6.4.2.6
Product areas that are impacted by any modifications are identified and retested [ISO 9001 4.10.3, 4.13.2] [ISO 9000-3 5.7.1, 5.7.3] [Bellcore TR-NWT-000179 3.7.1-1,4,8 & 3.7.2-3] [Trillium].

Level 3

Testing Process

6.4.3.1
All testing activities are performed according to the project's defined process [SEI SPE Activity 5] [ISO 9001 4.9, 4.11, 4.12] [ISO 9000-3 4.1.1.2.2, 5.4.6, 5.7.2] [Bellcore TR-NWT-000179 3.7.1-3,5,8,9 & 3.7.3-1 & 3.7.4.1,2 & 3.7.6-1 & 3.8-2 & 3.10.3-4] [Trillium].

6.4.3.2
Test documentation, test cases & testing procedures (e.g., unit, integration, system & regression testing) are developed and documented according to a documented procedure [Bellcore TR-NWT-000179 3.7.4.1,2] [ISO 9001 4.11] (Ref. IEEE Std. 1012 1.2(4), 3.5(1, 2 & 3)) (Ref. IEEE Std. 829) [Trillium].

Test Case Application

6.4.3.3
The application of test cases, principally for regression testing and where practical, is automated [ISO 9000-3 4.1.1.2.2] [Bellcore TR-NWT-000179 3.7.1-2,8] [Trillium].

Integration Testing

6.4.3.4
Integration testing activities are planned and performed according to the project's defined process [SEI SPE Activity 6] [Bellcore TR-NWT-000179 3.7.1-1,7,8 & 3.7.3-1] [Trillium].

Peer Reviews

6.4.3.5
Peer reviews are performed on all intermediate products according to a documented procedure [SEI PR Activity 2] [ISO 9001 4.4.6] [ISO 9000-3 5.4.6] [Bellcore TR-NWT-000179 3.4.2-12& 3.6.2-1] (Ref. IEEE 1012 figure 1 & table 1, Std. 1028) [Trillium].

V&V Results

6.4.3.6
Information on the results of peer reviews is recorded in an organizational repository [SEI PR Activity 3].

6.4.3.7
Data on defects identified during peer reviews, integration testing, system testing, operational testing and defects reported by customers are collected, documented, analyzed and tracked to closure [SEI SPE Activity 9] [ISO 9001 4.12, 4.13.1] [ISO 9000-3 5.7.3] (Ref. IEEE Std. 1012 3.5(3), 3.6 & 3.7) [Trillium].

V&V Efficiency

6.4.3.8
Verification and validation efficiency is measured and tracked according to a documented procedure [ISO 9001 4.12] [ISO 9000-3 5.7.3] [Bellcore TR-NWT-000179 3.7.1-9 & 3.7.2-1,4 & 3.7.4-3] [Trillium].

V&V Adequacy

6.4.3.9
Verification and validation adequacy (e.g., test coverage) is measured and tracked according to a documented procedure [ISO 9001 4.4.7, 4.4.8, 4.12] [ISO 9000-3 5.7.3] [Bellcore TR-NWT-000179 3.7.1-9 & 3.7.2-1,4] [Trillium].

Level 4

Test Case Generation

6.4.4.1
The generation of test cases is automated from requirements and designs [Trillium].

V&V Efficiency

6.4.4.2
Verification and validation efficiency goals are defined and monitored [Trillium].

V&V Adequacy

6.4.4.3
Verification and validation adequacy (e.g., test coverage,% NCSS inspected) goals are defined and monitored [Trillium].

Defect Density Analysis

6.4.4.4
Defect density is projected and compared with actuals [Trillium].

Roadmap 6.5: Configuration Management

Level 2

Scope

6.5.2.1
Source code is under Configuration Management (CM) control [Bellcore TR-NWT-000179 4.1.1-1 & 4.1.2-2,3] [Trillium].

6.5.2.2
All project and product (internal and external) documents are under CM control [ISO 9001 4.5.1, 4.5.2, 4.5.3] [ISO 9000-3 6.2.1, 6.2.3 & 6.2.4] [Bellcore TR-NWT-000179 4.1.1-1,3 & 4.1.2-1].

Function

6.5.2.3
A board having the authority for managing the project's product baselines (i.e., a product configuration control board - PCCB) exists or is established [SEI SCM Ability 1] [Trillium].

6.5.2.4
There is a function responsible for coordinating and implementing CM for the project [SEI SCM Ability 2] [IEEE Std. 828 2.2] [Trillium].

Funding

6.5.2.5
Adequate resources and funding are provided for performing the CM activities [SEI SCM Ability 3] [ISO 9001 4.1.2.2] [Bellcore TR-NWT-000179 4.1.3-5] [Trillium].

Planning

6.5.2.6
A CM plan is prepared for each project according to a documented procedure [SEI SCM Activity 1] [ISO 9000-3 6.1.1, 6.1.2, 6.1.3.1, 6.1.3.2] [Bellcore TR-NWT-000179 3.7.3-2 & 3.8-4 & 4.1.3-5 & 4.6-7] [Trillium].

6.5.2.7
A documented and approved CM plan is used as the basis for performing the CM activities [SEI SCM Activity 2] [ISO 9001 4.5.3, 4.8] [ISO 9000-3 6.1.1, 6.1.2, 6.1.3.1, 6.1.3.2] [Bellcore TR-NWT-000179 4.1.3-5] [Trillium].

Repository

6.5.2.8
A CM system is established as a repository for product baselines [SEI SCM Activity 3] [ISO 9000-3 6.1.3.1, 6.1.3.3].

6.5.2.9
The product repository ensures secure storage of configuration items (e.g., code units, design documents) and the secure and controlled retrieval of current and previous versions of configuration items [SEI SCM Activity 4] [Bellcore TR-NWT-000179 3.7.3-2 & 4.1.1-1,2 & 4.1.3-7 & 4.1.4-1,3].

6.5.2.10
The product repository ensures the secure and controlled retrieval of current and previous baselines [Bellcore TR-NWT-000179 4.1.4-1,2,3] [Trillium].

6.5.2.11
The status of configuration items/units is recorded according to a documented procedure [SEI SCM Activity 8] [ISO 9000-3 6.1.3.1, 6.1.3.3] [Bellcore TR-NWT-000179 4.1.3-2,3].

6.5.2.12
The product repository maintains records of the status and change history of all configuration items and baselines [Bellcore TR-NWT-000179 4.1.3-2,3,4] [Trillium].

Traceability

6.5.2.13
There is traceability between design specifications and source code and also between design specifications and integration test cases [ISO 9001 4.8] [ISO 9000-3 6.1.3.1] [Bellcore TR-NWT-000179 3.7.3-2 & 3.8-4 & 4.1.3-4] [Trillium].

Change Control

6.5.2.14
Change requests and problem reports for all configuration items/units are initiated, recorded, reviewed, approved and tracked according to a documented procedure [SEI SCM Activity 5] [ISO 9001 4.5.3] [ISO 9000-3 6.1.1, 6.1.3.3] [Bellcore TR-NWT-000179 4.1.1-1,3 & 4.1.2-1] [IEEE Std. 828 2.3.2].

6.5.2.15
Configuration items and baselines are changed formally according to a documented procedure [SEI SCM Activity 6] [ISO 9001 4.5.3] [ISO 9000-3 6.1] [Bellcore TR-NWT-000179 3.7.3-3 & 4.1.1-1,2,3 & 4.1.2-1] (Ref. IEEE Std. 730 3.4.2.6) (Ref. IEEE Std. 828 & 1052).

Baselines

6.5.2.16
Baseline(s) are created and released formally [SEI SCM Activity 7] [Bellcore TR-NWT-000179 4.1.3-1].

6.5.2.17
Product baseline audits are conducted according to a documented procedure [SEI SCM Activity 10] [Trillium].

Reporting

6.5.2.18
Standard reports documenting the CM activities and the contents of the product baselines are developed and made available to affected groups and individuals [SEI SCM Activity 9] [Trillium].

Level 3

Scope

6.5.3.1
Plans, descriptions, product test procedures, requirements specifications, design specifications, review results and test cases (e.g., integration, system, operation) are under CM control [SEI SPE Activity 10] [ISO 9001 4.11] [Bellcore TR-NWT-000179 3.7.3-1] [Trillium].

6.5.3.2
All development tools are under CM control [Trillium].

Traceability

6.5.3.3
There is full forward and backward traceability between all configuration items (e.g., design specification forward to code units, design specification backward to requirement specification) [Bellcore TR-NWT-000179 3.7.2-7] (Ref. IEEE Std. 1012).

Level 5

Scope

6.5.5.1
The complete development history (e.g., design decisions, design rationale) is captured and maintained under CM control [Roadmap Trillium 6.5.3.1].

Roadmap 6.6: Re-Use

This Roadmap covers practices that are related to reuse. A few practices have been taken from the "Reuse Adoption Guidebook", SPC-92051-CMC, version 02.00.05 November 1993.

Level 2

Cloning

6.6.2.1
Cloning (i.e., copying and modifying) of existing software units in new designs is tracked [Trillium].

6.6.2.2
Tools are provided to aid propagation of changes from one software unit to cloned units or to cloned from units [Trillium].

Third Party Components

6.6.2.3
Third-party components are selected, verified, validated and tracked formally according to a documented procedure [ISO 9000-3 6.8] [Bellcore TR-NWT-000179 4.6-7 & 4.8-1] [Trillium].

Level 3

Process

6.6.3.1
Standard reuse processes are defined and integrated with the organization's standard development process [SPC-92051-CMC PI-1] [Trillium].

6.6.3.2
Performance of the standard reuse processes is measured [SPC-92051-CMC CI-1] [Trillium].

6.6.3.3
Management and staff are aware of new and evolving technologies and standards that may affect their products and reusable assets [SPC-92051-CMC TI-1].

Cloning

6.6.3.4
Pre-developed and certified source code templates are provided in a template repository as a basis for cloning [Trillium].

Component Repository

6.6.3.5
Pre-developed and certified source code units are provided in a software component repository [Trillium].

Component Development

6.6.3.6
A component development function exists to develop, certify and maintain the items in the template and component repository [Trillium].

Component Re-Use

6.6.3.7
Specific steps are included in the organization's standard product development process for the purpose of maximizing component re-use [Trillium].

6.6.3.8
Re-use of pre-developed components is measured, encouraged, and rewarded by the organization's reward system [Trillium].

Re-Use Across the Product Line

6.6.3.9
Product line reuse strategies are developed to maximize the benefits of reuse over sets of related products [SPC-92051-CMC PD-2].

Level 4

Product Line Re-Use Process

6.6.4.1
Plans are established to systematically address weaknesses identified in the standard reuse processes [SPC-92051-CMC CI-2].

Pre-Developed Designs

6.6.4.2
Pre-developed and certified designs are provided in a software component repository for the use of developers [Trillium].

CASE Tool Support

6.6.4.3
CASE tools are provided to support re-use of software components in product developments [Trillium].

Factoring Re-Use into Product Costing

6.6.4.4
Product costing and funding strategies take into account expected costs and anticipated benefits of reuse over the product line [SPC-92051-CMC CP-3].

Level 5

CASE Tools

6.6.5.1
Knowledge based CASE tools are provided to automate re-use of components in new product developments [Trillium].

Roadmap 6.7: Reliability Management

Level 2

Planning

6.7.2.1
Product and service reliability and maintainability plans and objectives are established [Trillium] [IEC 300].

Availability Criteria

6.7.2.2
Product and system availability criteria are defined during the preparation of the requirements specification. They include but are not limited to failure definition/classification (e.g., critical, major, minor) and operational modes definition (e.g., nonstop, mission-oriented, batch) [Trillium] [IEC 300].

6.7.2.3
Software availability criteria are defined during the preparation of the requirements specification. They include but are not limited to product or system availability during enhancements and upgrades, failures, and the maximum number of failures allowed for the various classes of failure [Trillium].

Data

6.7.2.4
The following data is collected and analyzed prior to product release (Ref. IEEE Std. 982.1 & 982.2):

  1. Test Log (Test Execution Time),
  2. Failure Log (including failure classification), and
  3. Cumulative Execution Time per release.
6.7.2.5
The following field data is collected and analyzed (Ref. IEEE Std. 982.1 & 982.2):

  1. Cumulative Execution Time per release.
  2. Failure-related down time,
  3. Enhancement-related down time.

Level 3

Operational Profile

6.7.3.1
The Operational Profile is determined during the preparation of the requirements specification. The profile includes I/O Classes Definition and I/O Distribution per Class [Trillium].

Design

6.7.3.2
Product design guidelines consistent with reliability objectives are established and enforced [Trillium] [IEC 300].

6.7.3.3
FMECA and Fault Tree Analysis are performed on all critical modules (H/W, S/W) as part of the design activities and are part of the design reviews [Trillium] [IEC 300].

6.7.3.4
Reliability modelling influences the selection of design alternatives for non-software sub-systems, and at system level for software [Trillium] [IEC 300].

Reliability Growth Models

6.7.3.5
Reliability growth models are used for resources and/or schedule estimation using past project parameters (size, initial failure intensity and intensity decay parameters). These models are continually updated [Trillium].

6.7.3.6
Field reliability estimation is based on the determination of the testing acceleration factor and the reliability growth model [Trillium].

Level 4

Reliability Modeling

6.7.4.1
Reliability modelling influences software design alternative selection from both static code properties and dynamic code behavior data (in-line with re-use philosophy) i.e., Reliability Block Diagram, Markov modelling, Fault Tree Analysis, Strength-Stress Analysis, Stochastic Petri-Net Modelling [Trillium] [IEC 300].


[*] Back to the Trillium home page.
[TOC] To the detailed Trillium table of contents.
[TOC] Back to capability area 5.
[TOC] Forward to capability area 7.

[UHCL]