A Successful Practice of Applying Software Tools to CMMI

CMMI practices and experiences

A Successful Practiceof Applying SoftwareTools to CMMI Process Improvement

Hey-Chyi Young, Network Operations Department, Chunghwa Telecommunication LaboratoriesTse-Han Fang, Network Operations Department, Chunghwa Telecommunication LaboratoriesChung-Hua Hu, Network Operations Department, Chunghwa Telecommunication Laboratories

This paper describes a successful practice of CMMI process improvement taken by a pilot project of Chunghwa Telecom’s TOSST organization unit. The project team selects and integrates several commercial software tools to make substantial improvements on many important process areas defined in CMMI capability maturity level 2 & 3. This paper will first give a brief introduction of the project. And then it will explain the necessity of introducing software tools to process improvement. After that, the considerations of choosing tools are depicted in detail. Following that, the way of using tools in CMMI project management, engineering and support process areas is elaborately illustrated. Finally, the effectiveness of the practice is evaluated and then a conclusion is given.

1. Introduction

The famous Software Engineering Institute (SEI) has identified three major dimensions that an organization often focuses on to improve its business. As illustrated in Figure 1, the three dimensions are people, procedures

and methods, and tools and equipments. However, the “glue” to tie the triad together is process1. The SEI has also taken the process management premise, “the quality of

© 2006 Software Engineering Association of Taiwan

Journal of Software Engineering Studies, Vol. 1, No. 2, 78-95，December 2006

1 Mary Beth Chrissis, Mike Konrad, and Sandy Shrum, "CMMI Guidelines for Process Integrations and Product Improvement", p4, Addison-Wesley. 2005.

79

a system is highly influenced by the quality of the process used to acquire, develop, and maintain it”, and established the Capability Maturity Model Integration (CMMI) framework that emphas izes the deve lopment o f processes to improve product development and customer services in an organization. Due to the deep belief of this premise, the framework has been intensely promoted and quickly accepted worldwide.

Chunghwa Te lecom. Labora to r ies also recognize the importance of process improvement and began to introduce CMMI process model into the organization in recent years. Its Telecom Operations Support System Technology (TOSST) group passed the appraisal for CMMI Software/System Engineering maturity level 2 in January 2006. The ADSL Integrated Network Management System Project is a pilot project for CMMI-based process improvement. To make improvement activities solid and effective, the project team takes advantages of tools to eliminate the barriers. Several software tools were applied to fundamental project management, engineering, and supporting process areas. In the following sections, the necessity of tools is first discussed, and then the factors for choosing tools are explained. After that, the ways of how the pilot team utilizes tools in Project Planning (PP), Project Management and Control (PMC), Requirement Development (RD),

Requ i remen t Managemen t (REQM) , Technical Solutions (TS), Product Integration (PI), Verification (VER), Validation (VAL), Measurements and Analysis (MA), and Configuration Management (CM) process areas will be illustrated.

2. The pilot project

The project of ADSL Integrated Network Management System (ADSL INMS) is commissioned by the Network Division of Chunghwa Telecom’s Headquarters to develop ADSL Network Management Operat ions Support System (OSS) for managing the company’s ADSL network. As illustrated in Figure 2, the system shall provide a unitary user interface for ADSL network operators to manage a variety of multi-vendor DSLAM (Digital Subscriber Line Access Multiplexer) equipment installed throughout the country. Functions of this system shall cover network configuration auto-discovering, network activation, network testing, performance management, fault detection, alarm reporting, data collection and analysis…etc. Furthermore, the system shall interface with several other systems to support advanced service-layer applications such as ADSL service auto-provisioning, service problem management and service quality assurance.

This project adopts incremental system development life cycle. At its early stage,

A Successful Practice of Applying Software Tools to CMMI Process Improvement

Figure 1: The Three Critical Dimensions

80

i.e. 2000, the system managed only three kinds of DSLAM models. Afterwards, the number of managed DSLAM types and the supported functions are increasing yearly as the ADSL business grows and the network scale expands. There are twelve members in the project team. However, the scale of the developed and deployed system is quite large. By July 2006, the system has supported more than 4.7 million ADSL line ports all over the country.

3. Software Tools and CMMI Process Improvement

As defi ned in CMMI model, “Specifi c Goals (SG)” and “Generic Goals (GG)” are required model components. Goal achievement is used in appraisals as the basic upon which process area satisfaction and organizational maturity are determined. To achieve goals, “Specific Practices (SP)” and “Generic Practices (GP)” defined in CMMI model are expected to present in the planned and implemented processes. General outputs of these practices, called “Typical Work Product (TWP)”, are usually used as advantageous evidence for CMMI appraisal. Although CMMI model focuses on goal satisfaction and does

not emphasize or demand the use of tools, the utilization of tools is still a critical factor that relates to whether the improvement activities succeed or not. The reason is just like those shown in Figure 1: people, procedures/methods as well as tools are three major dimensions that deeply affect the results. Based on our experience, tools are not only important but also essential for seamlessly integrating different processes and quickly producing typical work products.

A number of studies [1][6][9] that describe how the software tools can be used to ease the adoption of CMMI can be found in the literature. The technical report cited in [1] points out the benefits to the CMMI process improvement by employing adequate and useful tools. For example, adequate tools are intended to effectively automate manual and error-prone tasks, facilitate and enforce management control activities, and eventually increase the efficiency of the process and improve the product quality. Regarding the selection of tools in order to involve most important activities of the CMMI process, the technical report suggests that the following kinds of tools might need to be evaluated and introduced:

H.C. Young et al.

User Authentication & Access ControlUser Authentication & Access Control

End User(Network Operator)

Alarm

Reporting

Status & Control

Network Fault

Detection

Performance

Monitoring

Traffic M

onitoring

Ticket M

anagement

Data Collection

Statistical Reports

Event D

etection

Integrated Management Operations System (OS)

Workstation

ATU-RCustomer Premises

Splitter ISPDSLAM

ATM SW

Configuration CommandScheduled Data CollectingEvent DetectingOn Demand Status QueryingOn Demand Testing

Configuration ResultsManagement DataEvent NotificationStatus ReportingTesting Result

MonitoringControllingTestingAlarm

Notifications

Network StatusEvent/Alarm NotificationsStatistical ReportsTesting Results

Ether SW/Router

Figure 2: The ADSL Integrated Network Management System Project

81

Planning tools

Requirement management tools

Visual modeling/Code development/User interface tools

Test tools

Change/Confi guration management tools

Quality assurance tools

CMMI model is quite comprehensive. It covers several bodies of knowledge and defined numerous process areas, specific and generic goals, specific and generic practices, as well as a lot of typical work products. It should be used to improve processes, increase product iv i ty and raise competitiveness of an organization. However, it might be infeasible if proper tools were not introduced into people’s daily

work. A common predicament of adopting CMMI activities in Oriental countries is that productivity is reduced instead due to both culture and lack of tools. Since without auxiliary tools, a lot of efforts might be shifted to prepare “typical work products” for CMMI appraisal. And this tends to cause resistance from people, which is usual ly a major obstacle to the way of improvement.

4. Concerns of the Selection of Software Tools

To avo id ge t t i ng in to the d i l emma mentioned above and make the process improvement take effect, ADSL INMS pilot project takes advantages of software tools. Selecting tools concerns about many issues from several aspects. They are listed in the following table.


Topics ConcernsWeighting of concerns in ADSL INMS project

Requirements of Process Improvement

What activities are required? How to simplify the activities and minimize the efforts with tools?

•• High

Function AdequacyWhich function of tool can be applied?Does the tool support suffi cient functions?What are the strength and the weakness of tool?

•••

High

Document Generation and Exporting Capability

What kinds of documented work products are required?Does the tool support functions to generate and export the required documentations?

•• Medium

Customization Capability

Which functions need to be customized?Does tool support function customization?How is the supported degree and fl exibility of customization?

•••

Medium

Statistics and Analysis Capability

How is the data statistics and analysis capability of the tool?Can the statistical data be exported?Are the statistics benefi cial to project?

•••

High

Integration Capability with Other Tools

Will too many tools be selected?How are the capability, the convenience and the correctness of data integration among different tools? How to integrate tools to conduct activities of different process areas?

••

• High

Data TransformationHow to transform existing data/work product into the repository of tool? Will data be lost during transformation?

•

•Medium

Effectiveness

Will tools do bring benefi ts and save efforts and time? Are the functions of tools too complicated and loosing its focus?Will the product quality increase by using tool?

••

•

High

Convenience Is the use of tools easy, convenient enough to become part of people’s daily life?

• High

Supporting How about the future technique and maintenance support of tools?

• Low

CostHow to get the tools? Self-developed or by procurement? How about the cost and budget for tools?

••

Low

Table 1: The Topics and Issues of Selecting Software Tools

82

The weighting of the considered items would be different according to the project objectives and the culture of organization. In this project, the use of software tools aims to get real data and make process improvement solid, therefore the fundamental principles are to simplify the activities and make them acceptable for people’s daily jobs. The complicated and tedious issues were clarifi ed based on these principles, and eventually some fascinating functions or features of tools need to be abandoned and too detailed

measurement statistics also need to be ignored. For ADSL INMS project, in addition to Microsoft Offi ce for basic word processing and Borland JBuilder for programming, several tools including Borland CaliberRM, Microsoft Project, Borland StarTeam and Mercury TestDirector are chosen according to the weighting priority of concern issues shown in the above table. The way of utilizing these tools is summarized in the following table.

Tool Applied Area Description Target Users

Microsoft Project Standard Edition

Project Planning

To defi ne work breakdown structure.To plan schedule and resources.To maintain the work dependences.To identify the critical path.

••••

Project Leader

Borland CaliberRM

Requirement Management

To record requirement change requests and the corresponding evaluations like impact analysis, estimated schedule and resources.To maintain bi-directional traceability between requirement change requests and requirement specifi cations.

•

•

Requirement Engineers

Requirement Specifi cations

To maintain requirement specifi cations and bi-directional vertical and horizontal traceability between requirements.

• Requirement Engineers

Design Specifi cations

To maintain design specifi cations, horizontal traceability between design specifi cations, and vertical traceability between design and requirement specifi cations.

• Design Engineers (System Engineers)

Measurement and Analysis

To provide data source for the measurements of requirements and requirement change ratio

• Measurement and Analysis Engineers

Borland StarTeam

Data Management To support centralized data management facility and repository for documentary materials.

• All Project Members

Project Management and Control

To maintain the list of tasks that require monitoring and control; the items include planned work, provisional tasks, PMC noncompliant issues and corrective actions.To trace the task progress and status.

•

•

All Project Members

Process and Product Quality Assurance

To maintain the list of PPQA non-compliant issues and corrective actions.To trace the progress and status of corrective actions.

•

•

All Project Members

Confi guration Management

To construct a confi guration management system to support CM activities.To maintain confi guration records and generate CM reports.

•

•

Confi guration Manager

Version ControlTo control source code and execution code versions.To package the product.

••

Version Controller

Implementation Flow Control

To maintain traceability among requirements, implementation requests, and the source code.To support implementation workfl ow.To trace implementation status.

•

••

Developers, Version Controller, Test Engineers

Timesheet/Man-hour Management

To support timesheet management functions for each individual.

• All Project Members


To provide data source for measurements of number of codes, man-hour statistics and product defects

• Measurement and Analysis Engineer

Mercury TestDirector

Test Specifi cations To maintain test plans, test cases, and the traceability between requirements and test cases.

• Design/System Engineers

Final Test To log test results, generate test reports, and analyze requirement coverage of test.

• Test Engineers

Project Management and Control

To identify inconsistence between requirements and work product.

• Project Leader


To provide data source for measurements of number of product inconsistence.

• Measurement and Analysis Engineer

Table 2: Tools Utilized by ADSL INMS Project

H.C. Young et al.

83

5. Customization and Integration of Software Tools

Tools are just tools. For tools to be effective, it is still necessary for them to be customized and integrated based on professional knowledge. The purpose o f cus tomizat ion is to le t too ls meet specific organizational procedures or data requirements. Usually the customization items include contents of datasheets, data-fields and format of statistical reports or exported documentation, workflow, and measurement and analysis functions…etc. Tools may support a variety of attractive functions, however, which functions can be applied for simplifying process activities and how to use them should be tried out and evaluated in advance. Besides, according to CMMI framework, there exists close relationships among CMMI process areas. Figure 3 shows an example demonstrating

the connections among CMMI engineering p r o c e s s a r e a s a n d a m o n g p r o j e c t management process areas respectively. Therefore, utilizing tools should also take care of the maintenance of inter-process relationships. But it should be understood that an all-round tool that would satisfy all different requirements from every aspect is actually not existent. So it is almost inevitable to take several tools for CMMI process improvement. And how to interpenetrate various tools would defi nitely be an important topic. In the following sections, more detailed information about how ADSL INMS project applies tools to process improvement with integration considerations will be illustrated.

6. Use of tools in Engineering Process Areas

From technica l v iewpoint , a ser ies of engineering stages is necessary to develop a product. They are comprised

Figure 3: Close Related Engineering and Project Management Process Areas


Source: Mary Beth Chrissis, Mike Konrad, and Sandy Shrum, "CMMI Guidelines for Process Integrations and Product Improvement", p61 and p67, Addison-Wesley. 2005.

84

of requirement development, requirement change management, product design, product implementation, product integration, product validation, product packaging and delivering...etc. The work products of each stage have tight relationship. As mentioned in CMMI model, a very important specific practice is to identify inconsistencies between project work and requirements2. Another related one is to maintain bidirectional traceability of requirements3. When the project scale is not small, these required practices are very difficult to accomplish if without tools. For ADSL INMS, there are at least 300 system requirements per

year; by using traditional documentation method, it is almost infeasible to correctively maintain the bi-directional traceability among work products of customer requirement s p e c i f i c a t i o n s , s y s t e m r e q u i r e m e n t specifications, design specifications, test cases, source code, and releases. In order to properly associate various work products, in addition to the originally used Borland JBuilder for system coding, ADSL INMS project selects another three kinds of commercial tools, i.e., Borland CaliberRM, Borland StarTeam and Mercury TestDirector for engineering processes. Figure 4 shows the way of how work products generated at different stages are linked together.

Trace to

Trace to

Select

Caliber RM[System Req]

Caliber RM[Req Change]

Trace to

Start Team (Req)Automatically,

PeriodicallyExport to

Start Team (CR)

Link to

Start Team (Source Code-File)

Link to

Caliber RM[Customer Req]

Caliber RM[Design Spec]

Trace to

Test Director[Requirement]

Test Director[Test Plan]

Test Director[Test Lab]

CoverExport

to

Generate

Requirement Test Coverage

Report

Test Report

SystemReq

Spec.

Design Spec

CustomerReq

Spec.

Req ChangeRecords

Version Controlled

SourceCode

Version Controlled

Release

Test SpecReport

Testing, Version Control

Figure 4: Associating the Work Products of Different Engineering Stages by Tools

H.C. Young et al.

Several kinds of technical specifications including customer requirements, system requirements, system design, as well as requirement change requests and defined work packages are recorded and stored in CaliberRM with different customized item types. Using “Traceability” function of CaliberRM, the bi-directional traceability among i tems may be establ ished and maintained easily. Figure 5 illustrates the use of CaliberRM.

Requirements stored in CaliberRM may be exported to TestDirector, which is a test management tool. And test plans that contain test cases with test steps are built and saved in TestDirector. The relationship between requirements and test cases are connected by “Test Coverage” function of TestDirector. For performing integration test, the target test cases are selected under a “Test Lab”, and the test result is logged for each test case. By checking test coverage

2 Defi ned in SP 1.5 of “Requirement Management ” Process Area. [8]3 Defi ned in SP 1.4 of “Requirement Management ” Process Area. [8]

85

Figure 5: Maintaining Technical Specifi cations and Corresponding Traceability

information, those requirements that do not pass the test can be quickly found out. Figure 6 is an example showing the test cases of a particular requirement and the corresponding test results.

As to StarTeam, it provides several build-in object types including “File”, “Requirement”, “Change Request (CR)” and “Task”. The relationship among different object instances may be associated by “Links” function. System requirements stored in CaliberRM

can be automatical ly and per iodical ly exported to StarTeam as “Requirement” objects. Following the rules defi ned by ADSL INMS project, prior to code implementation or bug fi x, an implementation “Change Request” object needs to be created and linked to the related “Requirement” objects. And whenever the source code is finished and passes unit test, it should be checked in to StarTeam as a “File” object and linked to the corresponding “Change Request” object. So, l inkages

Figure 6: Associating Requirements, Test Cases and Test Results by TestDirector


86

Figure 7: Using StarTeam “Change Request” to Control Implementation Workfl ow

H.C. Young et al.

between requirements and the source code are established indirectly. “Change Request” objects support workflow features. And they are utilized to control the implementation steps by customizing their workflow to meet project-defined procedures. Every instance of implementation needs to go through a complete sequence including coding, unit testing, alpha testing, beta testing, and

releasing...etc. Figure 7 demonstrates a customized “Change Request” form with its status change diagram described in the lower-left. In addition to those mentioned above, StarTeam also supports many configuration management functions like check in, check out, merging, labeling...etc., so it is used for version control of source code and release too.

As i l lustrated in Figure 4, the three major tools can generate and export many important and required work products with customized format. Therefore, engineers do not spend time on word processing and document formatt ing of technical specifi cations and reports. The overall fl ow of utilizing tools on CMMI engineering process areas are summarized as Figure 8.

7. Use of Tools in Project Management Process Areas

Pro jec t P lann ing (PP) and Pro jec t Monitoring and Control (PMC) are two major CMMI process areas of project management. Targets of project monitoring and control are those planned in project plan. Figure 9 explains how ADSL INMS team facilitates project management by tools. For project

p lanning, Microsof t Pro ject Standard Edition is used to define work breakdown structure, plan schedule and resource of work packages, and identify dependencies among tasks. Planned tasks with information of responsible person and schedule can be exported from Microsoft Project to StarTeam as “Task” objects of which data fields of planned information cannot be changed. These imported “Task” objects then can be used as project monitoring base. Moreover, other “Task” objects can also be created anytime for provisional assigned tasks or meeting resolutions that need follow-up.

StarTeam “Task” objects are customized t o a d d e x t r a d a t a f i e l d s f o r p r o j e c t monitoring and control. For ADSL INMS project, a customized “Task” object will reveal many information including task

87

Figure 8: The Overall Flow of Utilizing Tools on CMMI Engineering Process Areas

MS Project (mpp Project Plan)

Start Team (PMC Tasks)

Export to

Input Progress Data(In the view of mission)

Progress MAReports

WBS,Schedule,Resource

Assignment, Task Dependence,

Milestones

Start Team (Tasks)

Input Personal Working Records(in the view of individual Tasks)

Man-hour MA Reports

Personal WeeklyWork

Report

Figure 9: To Facilitate Project Management By Tools.


name, responsibility, planned start and end schedule, actual start and end schedule, est imated end schedule, work hours, comp le teness pe rcen tage , p rog ress description, review comments, and flag of corrective action for non-compliant issue ...etc. It is mandatory for ADSL INMS team members to input progress information of responsible tasks into the corresponding “Task” objects prior to monthly progress

review meeting. All “Task” objects can be catalogued in arranged StarTeam folders and make them easy to trace. Besides, customized filters for “Task” objects may be set to quickly find out the overall status and statistics of tasks. These features are illustrated in Figure 10, and are quite helpful for project leaders to monitor and control project work. “Task” objects are also exercised to report weekly timesheet of each

88

Figure 10: Utilizing StarTeam to Help Project Monitoring and Control

Figure 11: The Confi guration Management Scenario by Utilizing Tools

H.C. Young et al.

individual and generate personal weekly work report. These data are also used in man-hour measurements.

8. Use of Tools in Confi guration Management Process Areas

Configuration Management is one of CMMI support process areas. Its one specifi c practice is to establish a configuration management system4 that will include the storage media, the procedures, and the tools

for accessing confi guration items.

Figure 11 describes the way of how ADSL INMS project uses StarTeam to construct the configuration management system. First, StarTeam “Change Request” objects with workflow features are customized to support configuration management activities including requests for baseline establishment or baseline change, impact analysis of

4 Defi ned in SP 1.2 of “Confi guration Management ” Process Area. [8]

89

Figure 12: Confi guration Management System Constructed by StarTeam


change, review by Change and Confi guration Board (CCB), as well as requests for release. Once a “Change Request” object finishes the CM workflow and obtains the approval of basel ine establ ishment, the project configuration manager may check in the specifi ed confi guration item (with fi le format) to StarTeam. Configuration items stored in StarTeam cannot be accessed unless a request for check out is approved. And “Task” objects of StarTeam are customized again to support check out activities.

A sc reen snapsho t demons t ra t i ng the configuration management system constructed by StarTeam is shown as Figure 12. All established configuration items are listed on the upper-right panel. In front of the main frame, there is a customized “Change Request” object for baseline establishment request . A l l per fo rmed conf igura t ion management activities will leave records on the system automatically. These records can be inspected or exported as CM report anytime, and are very useful for confi guration audits5.

9. Use of Tools in Measurement and Analysis Process Areas

Measurement and Analysis is another critical CMMI support process area. Project-related statistics are very important support information for projects to improve their capability, since they are usually indicators of potential problems. Because measurement and analysis is essentially costly, principally it is not expected to get complete coverage. Once the objectives of measurement and analysis are clarified, how to collect data and perform measurement and analysis is often a tough issue. If the source data for measurement and analysis is gathered from people instead of systems, then it not only costs a lot of human efforts but the completeness, correctness and objectiveness of result statistics are questionable. To avoid this, as depicted in Figure 13, ADSL INMS project makes use of the tools mentioned in previous sections to generate MA reports. The data sources of these reports are the centralized repositories of tools. And the data is naturally derived from people’s daily activities that follow specified procedures and reflects the truth more. For ADSL INMS 5 Defi ned in SP 3.2 of “Confi guration Management ” Process Area. [8]

90

Start Team (Project Tasks)

Start Team (Daily Tasks)

Start Team (Source Code-File)

Caliber RM[Requirements]

Test Director[Requirement]

Test Director[Test Plan]

Test Director[Test Lab]

MA Report of Requirements

that did not pass test

Start Team (Change Request)

Start Team (PMC Tasks)

MA Report of Requirement &Requirement

Change

MA Report of Man-hour Statistics

MA Report of Work Progress

WeeklyWork Reports

MA Report ofNumber of

Codes

MA Report ofProductDefects

MA Report ofNon-compliant

Issues

Figure 13: Using Tools to Generate MA Reports

H.C. Young et al.

project, a variety of MA reports concerning project scale, product quality, resource usage and performance are supported.

Figure 14 is an example of customized MA report of project progress. The listed tasks are those defi ned using Microsoft Project and exported to StarTeam. As stated before, each individual is required to report the progress of assigned tasks in StarTeam. It results in that StarTeam can generate the MA report of overall project progress very quickly. Figure 15 shows the statistics of implementation change requests. It clearly depicts the current status of implementation activities by showing two-dimension distribution on status and engineers (including developers, testers, and version controllers) of all change requests. Figure 16 is another example of man-hour statistical report. It is generated by a self-developed function that has plugged into StarTeam platform. The report consists of each individual’s man-hour and distribution on work packages as well as the overall summarized information.

10. Effectiveness Evaluation

ADSL INMS project was initiated about six years ago, and at that time, Chunghwa

Telecom. Laboratories had got ISO 9001 certifi cate for a few years. Due to the lack of tools for conducting the ISO activities, most of the project staffs deeply thought that it was very time-consuming to manually generate ISO documentat ion, such as required development documents and the associated check-in/check-out/review/audit sheets. In terms of our practical experiences, it is almost infeasible for a large, practical software project to manually and yet eff iciently, maintain up to date bi-directional traceability relationships among various types of work products, such as requirement specifi cations and test specifi cations. This diffi cult situation would become more and more worse when a number of requirement changes need to be handled during the execution of the project. One reason is that project staffs always take much time to identify the corresponding r e q u i r e m e n t s p e c i f i c a t i o n , d e s i g n specifi cation, test case, and source code that affected by this requirement change. In our estimation, this may take at least one man-day for dealing with a requirement change if the tools are not adequately applied. It may also be very tedious and inefficient if the manual work mentioned above eventually becomes part of project staffs’ daily routines.

91

Figure 14: Customized MA Report of Project Progress

Figure 15: Distribution Statistics of Implementation Change Request

Figure 16: Using Customized Function to Generate Man-hour Statistical Report


92

By contrast, it only takes a few minutes nowadays for fi nding out the impact items of a requirement change by adopting tools.

To sum up, for ADSL INMS project, the benefits of applying software tools to CMMI process improvement are conspicuous. The project has successfully established its profi le that consists of many important measures l ike size of work product, requirement change rat io, product iv i t ies, cost and man-hour distribution on work packages, product quality, performance, configuration management activities, project monitoring and control activities, and even product effectiveness.

Figure 17 shows some stat is t ics of ADSL INMS profile. All the information is very helpful for identifying potential project problems so that further improvement may focus on the right things, as well as enhancing the ability and accuracy of project estimation in the future. Besides, using tools to maintain the list of planned work, assigned jobs, noncompliant issues and corrective actions does help project leader not miss any item that needs to be monitored. This apparently increases the completeness of project monitoring and control. As in the aspect of system engineering, the bi-directional traceability of work products at

Figure 17: ADSL INMS Project Profi le

H.C. Young et al.

2005 ADSL INMS Project Profi le

Distribution of Human

Resources(%)

1.1 Project Planning 9.21%

Project Name ADSL INMS

1.2 Project Monitoring& Control 8.14%

Project ID 9043 2.1 Requirement Development 10.70%

Progress(%) 100% 2.2 Design & Implementation

19.33%

Number of System Requirements 370 2.3 Integrated Testing 8.25%Number of Product Defects 71 2.4 Deployment 2.30%

Number of Corrective Defects 603.1 System Maintenance/Technical Consulting

19.56%

Number of Process Defects 23.2 Technical Supports for IP-DSLAM Procurement

1.99%

CPI 1 4. Technical Documentation

5.22%

Productivities

(by number of auto-activations)Unit: times/day

1366 5.1 Quality Assurance 0.30%

(by lines of source codes)Unit: lines/man-day

33 5.2 Measurements 0.62%

(by pages of technical documentations)Unit: pages/man-day

1 5.3 Confi guration Management 0.95%

(by number of operations supports)Unit: times/man-day

0.32

5.4 Training 6.34%5.5 R&D Environment Maintenance 2.04%

6.Others 5.03%

93

different stage may be established and kept, so affected items and impact of requirement changes can be easily identified and more accurately evaluated. In addition, alteration of technical specifications can be more simply conducted and traced, so the common situation of getting obsolete data in the past has been greatly improved. To sum up, CMMI process improvement activities taken with the assistance of tools have successfully built up data linkages, strengthened data updating and sharing channels, and provided a systematic way for project management. Making use of document exporting features of tools has also substantially released the load of preparing documentations for engineers. Due to these obvious advantages, the aversion of change from people is eliminated. The wholehearted support and participation of all members become an important motive power to make project progress. This success also lays a strong foundation for the organization moving toward CMMI maturity level 4 and level 5.

11. Conclusion

CMMI process improvement model is quite comprehensive. The number of expected practices and work products are tremendous. If no suitable tools and procedures to facilitate these, then in the long run the organization will face the problem of maintaining real and updated data. Once data could not reflect truth, meet timing, or satisfy completeness, process improvement cannot be solid. No tool support also tends to cause resistance and make it difficult to raise capability maturity level. Although tools are necessary, it would just like no tool if they were not appropriately utilized. Therefore, it is recommended the organization not only offer tools but also invest time and human resources in evaluating, selecting, integrating and customizing tools to meet specifi c organizational process requirements. To make process improvement feasible and lasting, it should be kept in mind that tools are aimed at simplifying the required individual’s da i l y ac t i v i t i es , so the se lec ted and

customized tools should be convenient and friendly for use too. Finally, it is emphasized that tools are not the total solution. Referring to Figure 1, procedures and people are also critical factors that will affect the results. In order to taste the sweet fruit, when conducting CMMI process improvement, the organization should not forget to pay attention to people as well as methods and procedures. On one hand, the organization should train related staffs with domain know-how about CMMI process, so that the staffs are well skilled and with shared vision. On the other hand, methods and procedures also need to be well defi ned, clear, complete, not too tedious, and easy to adopt.

AcknowledgementIn this paper, some figures illustrating

CMMI model are referenced from the book “CMMI Guidelines for Process Integration and Product Improvement”, written by Mary Beth Chrissis, Mike Konrad, Sandy Shrum, and published by Addison-Wesley. We would like to thank the authors for providing readers with such an excellent guiding book to CMMI framework. In addition, we would like to express our great appreciation to Dr. Chaw-kwei Hung, who is the CMMI consultant of Chunghwa Telecommunication Laboratories. For the past few years, Dr. Hung with wide and practical CMMI knowledge has been giving us many precious advices in process improvement. And we would also like to give thanks to all the team members of ADSL INMS project, they give their full support on the improvement activities and feed back many useful opinions and suggestions. Many of them have also devoted a lot of time to evaluating and customizing tools. Without their contribution, we could not have the successful and practical experience on applying tools to CMMI process improvement.

Reference[1] B i l l Cot t re l l , “Too ls and Process

Matur i ty ” , h t tp : / /www.saspin.org/Saspin_May2002_Cottrell.pdf, accessed 2006/11/8.


94

[2] Borland, Borland CaliberRM, http://www.borland.com/us/products/caliber/index.html, accessed 2006/8/19.

[3] Borland, Borland StarTeam, http://www.borland.com/us/products/starteam/index.html, accessed 2006/8/19.

[4] Borland, StarTeam 2005 and StarTeam 2 0 0 5 R e l e a s e 2 I n t e g r a t i o n s , h t t p : / / u s s v s - b e s 1 . b o r l a n d . c o m /We b D o w n l o a d / o u t c o m e _ p a g e s /st2005_Int_kdown.html, accessed 2006/8/19.

[5] Borland/TeraQuest, CMMI Staged M a t u r i t y L e v e l s , h t t p : / / w w w .t e r a q u e s t . c o m / C M M I / s t a t i c /CMMI%20Staged%20MainPage.html, accessed 2006/8/19.

[6] Carnegie Mellon Software Engineering Institute, CMMI Adoption Page, http://www.sei .cmu.edu/cmmi/adopt ion/adoption.html#learning, accessed 2006/11/8.

[7] Carnegie Mellon Software Engineering Institute, CMMI Main Page, http://www.sei.cmu.edu/cmmi/, accessed 2006/8/19.

[8] Carnegie Mellon University, Software Engineering Institute, CMMI-SE/SW/IPPD/SS, V1.1, 2002.

[9] Lisa K. Meisenbacher, “The Challenges of Tool Integration for Requirements Engineering”, Proceedings of SREP’05, 2005, pp. 188-191.

[10] Margaret K. Kulpa and Kent A. Johnson, Interpret ing the CMMI: A Process Improvement Approach, CRC Press LLC, 2003.

[11] Mary Beth Crhrissis, Mike Konrad, and Sandy Shrum, CMMI Guidelines for Process Integration and Product Improvement, Addison Wesley, 2005.

[12] Mercury, Mercury TestDirector, http://w w w. m e r c u r y. c o m / u s / p r o d u c t s /quality-center/testdirector/, accessed 2006/8/19.

[13] Mercury, TestDirector Add-ins, http://updates.merc-int.com/testdirector/td80/index.html, accessed 2006/8/19.

[14] Microsoft Office On Line, Microsoft Off i ce Pro jec t 2003, h t tp : / /www.microsoft.com/office/project/prodinfo/default.mspx, accessed 2006/8/19.

About the Author

Hey-Chyi Young Rece ived MS degree o f Compute r

Science from University of Texas at Austin, U.S.A. in 1990. Ms. Young currently works for the Network Operations Department of Chunghwa Telecommunication Laboratories, and is the Project Manager of “Network Management Technology” project. Her techn ica l in teres ts focus on network management technologies including Next Genera t ion Opera t ions Sys tems and Software (NGOSS), Telecommunication Management Network (TMN), IP-based Network Management , Open Sys tem Interconnection (OSI) Management...etc. as well as project management and system engineering technologies.

Tse-Han Fang Rece ived MS degree o f Compute r

Science from National Tsing Hua University, Taiwan in 1995. Mr. Fang currently works for the Network Operations Department of Chunghwa Telecommunication Laboratories. He is a Senior Engineer and responsible for the requirement analysis and system architecture design of ADSL INMS. His specialties are information technologies, s y s t e m e n g i n e e r i n g , a n d n e t w o r k management technologies.

Chung-Hua Hu Received PhD degree of Computer

Science from National Chiao Tung University, Taiwan in 1998. Mr. Hu currently works for the Network Operations Department o f C h u n g h w a Te l e c o m m u n i c a t i o n Laboratories. He is a Senior Engineer and his specialties are information technologies,

H.C. Young et al.

95

system engineering, and ADSL network management.


Documents

A Successful Practice of Applying Software Tools to CMMI