The Design and Improvement of a Software Project Management System Based on CMMI ()
1. Introduction
Because of the complexity, large-scale and diverse projectors, the process of software manufacture urgently needs scientific management and definition. Meanwhile, the increased size of the project which leads to the exponential growth of the project data makes the traditional manual controlled project management methods appeared to be inadequate. The research on the new management system and new process is urgently needed to effectively enhance the company’s management capability [1]. These special requirements of the software industry promote the rapid development of enterprise project management tools.
CMMI can help enterprises to integrate their original independent functional system, to identify the goals and steps for process improvement, to strongly guide the quality control process, and to provide scientific and rational reference data used during the assessment of the current process [2,3]. Therefore, it is significant for a software enterprise on improving the project management and the efficiency of product development to make the CMMI theoretical system be well reflected in the project management tools and effectively assist the enterprise to improve management system and project development process.
2. The Basic Structure of CMMI
2.1. Capability Maturity Model of Integration (CMMI)
In 2003, Software Engineering Institute of Carnegie Mellon University (SEI) released the new generation version of Software Capability Maturity Model (SWCMM)-integrated Capability Maturity model (CMMI) based on the research of SW-CMM and combined with the development characteristics of today’s software industry. The biggest difference of CMMI and CMM is that more key practices of highly application values have been added to CMMI to perfect the process improvement.
5 maturity levels of CMMI are: Initial level, repeatable level, defined level, managed level and optimized level.
2.2. CMMI Three Level Process Areas
The CMMI process areas are divided into four categories: Process management, project management, engineering, support.
Compared with SW-CMM, following process areas are added to CMMI:
Process area added to Capability Maturity level 2: Measurement and analysis;
Process area added to Capability Maturity level 3: Requirements development, technical solutions, product integration, validation, decision analysis and solutions.
In order to meet CMMI Capability Maturity level 3, the process areas of CMMI levels 1, 2 and 3 are needed to be achieved in the same time.
The simplified model of SPP (Simplified Parallel Process) [4] has provided the software process implementers with 58 standard document templates as standard document used during the project implementation process. On the request of CMMI and combined with the characteristics of the staff in domestic software enterprises, the SPP model has divided into 20 kinds of SPP major roles. When using SPP, the enterprises can map the roles of SPP to the original positions in the enterprise or establish new positions based on SPP roles.
3. The Design of Software Project Management System Based on CMMI
3.1. Project Management System Workflow
Based on the relationship among the 3 level process areas of CMMI and the key practices set by CMMI level 3, combined with the original business structure of a software enterprise’s R & D department, we define a set of new project management system workflow which can both meet the CMMI level 3 specifications and realize smooth transition from current management system of the software R & D department, as shown in Figure 1.
3.2. The Entire Functional Structure of the Project Management System
The software project management system consists of project management functional area and system functional area. The project functional area consists of six modules: Project management module, project development module, technology support module, document management module, daily management module and employee management module. The system functional area consists of user management module, document management module and role management module.
3.3. The Design of Main Modules of the Software Project Management System Based on CMMI
According to the requirements of the entire project structure and CMMI 3, the system mainly consists of system management module, project management module, project development module, technology support module, document management module, staff management module and daily management module. The requirements of CMMI 3 are reflected during the realized process of each specific module.
3.3.1. Project Establishment Management
Project establishment management is the beginning of the system workflow as the product concept stage. Meanwhile, project establishment management belongs to project management in CMMI. The purpose of project establishment management is to adopt the project establishment proposal in keeping with the best interests for the agency and make the proposal become a formal project through project establishment management. Project establishment management can also avoid project establishment proposal be adopted without best interests for the agency and avoid wasting resources, money and time of the agency. The key practices of project establishment management stage of project management consist of project establishment proposal, project establishment evaluation and project preparation. Department managers and project managers are involved as staff roles in the project establishment management stage.
3.3.2. Project Planning
Project planning is in the product definition stage of the system workflow and belongs to project management in CMMI. Project planning is directly corresponded to the project planning process area (PP). The purpose of project planning is to draft an action programme (project plan) for project R & D and management, thus helping all relevant people work according to the plan orderly. The key practices of project planning stage of project management consist of project estimation, project plan
Figure 1. Project management system workflow.
making, project plan approval, etc. Department managers and project managers are involved as staff roles in the project planning stage.
3.3.3. Requirement Development
Requirement development crosses through the product concept stage and product definition stage of system workflow and belongs to project development in CMMI. Requirement development is directly corresponded to the requirement development process area (RD). The purpose of requirement development is to get the needs of user and define the requirements of the product through surveys and analysis. The key practices of requirement development consist of requirement validation, requirement traceability and requirement change control. Requirement analysts are mainly involved as staff roles in the requirement development stage.
3.3.4. System Design
System design is in the product development stage of the system workflow and is related to technology support area (TS) and product integration area (PI). It belongs to engineering. The task and purpose of system design is to design the system structure, user interface, database and modules of the software system in order to build bridge between requirements and codes and guide developers of software products to meet user’s requirements. The key practices of system design consist of system structure design, user interface design, database design and module design. System designers are involved as staff roles in the system design stage.
3.3.5. Coding and Testing
Coding and testing cross through the product development stage and product testing stage of system workflow. They are involved in technology support (TS), product integration (PI), verification (VER) and confirm (VAL) process areas. They belong to engineering in CMMI. Coding and testing write and test the codes of the whole system based on system design documents. The key practices of coding and testing consist of programming, code review unit testing, integration testing, defect management and error correction. System test is a final and fully test on the whole system to ensure the final system to meet product requirements and follow the system design. Coding controllers, coders, test controllers and testers are involved as staff roles in the coding and testing module.
Iteration and repeatability frequently exist in the coding and testing stage. It is difficult for the system to define the degree of task completion. In addition, the design of the module becomes more difficult because the specific arrangements and completion of coding and testing tasks (including code quality and required time, etc.) will be used as basis for scoring in staff scoring subsystem.
We have designed a judgment method for iterative task state, which is to set an information record for each coding or testing task to record and judge the current state of the coding or testing task. Then we set different time slices for the state of project task. We can judge the state of the coding or testing tasks by testing and calculating these time slices. At the same time, the system provides the coding controllers or test controllers with the entrance to subjective scoring, which help them to further understand the distribution of tasks of coders and testers.
3.3.6. Project Monitoring and Controlling
Project monitoring and controlling is in the project management stage and is related to project monitoring and controlling (PMC) and measurement and analysis (MA) process area. It belongs to project management and support. The key practices of project monitoring and controlling in SPP consist of project plan tracing, deviation controlling and project progress summary. Department managers and project managers are involved as staff roles in the project monitoring and controlling stage.
According to the analysis, the progress of the project has the following two characteristics: Firstly, the progress of the project is mainly reflected in the progress of the submitted documents, that is, the progress of the submitted document reflects the progress of the project; secondly, the documents submitted by the different modules are different, so we can represent the progress of each module based on the progress of the submitted document. We have designed two methods in figure to display and control the status of the project: “Figure of project progress—document submitted” and “figure of project progress—module progress”.
3.3.6.1. Figure of Project Progress—Document Submitted We analyzed 42 standard documents involved in the project development process to find out the dependencies among these documents and produce a figure of document dependency relationship, see Figure 2.
Figure 2 consists of two parts. One part is a list of document number from document 1 to document 42. The other part is a tree of document dependency relationship. The figures on each node of the tree represent the number of the corresponding document. The circle on the tail of the arrow represents the premise document. The arrow starts from the premise document and points to the next level document. If the document represented by the circle on the tail of the arrow did not pass the audit, then the document pointed by the arrow will be impossible to be approved.