3.2.3 Software Project Tracking and Supervision (Software Project TRACKING AND OVERSIGHT)
The purpose of software project tracking and supervision is to establish an appropriate visibility of actual progress. In order to see the error between the development process and the project plan, allow the project manager or high-level manager to know the state of the software development process, Effective measures are taken when the software project is clearly deviated from the software plan. The basic process of tracking and monitoring of CMM repeated software projects can be shown in Figure 7. This process describes the software project group based on documentation estimates, commitments, and plans to track and review software outcomes, and adjust the plan according to the actual situation. Documentation software project plans are used as the basis for tracking software activities, understanding status, and correction programs. The project manager regularly forms project schedule reports based on the implementation of the project development plan, and compares the project development plan, and corrects the problem.
Figure 7: Software project tracking and planning basic flow chart
According to the flow of Figure 7, when performing actual project plan tracking and monitoring, you can take the following: 1. Project Manager The progress report of the project is prepared according to the actual implementation of the project. The item team member is then summoned to confirm and correct the progress report. 2. The project manager finds the gap and discovers the gap and records its records in accordance with the actual implementation, including: fees, progress, risk, personnel, resource conditions. 3. Review progress reports and issues reported by senior managers, and urges the project manager to fix the problems and risks of its planning and solving projects. 4. The documents applied in the actual project are: Project Tracking and Monitoring Process Definition, Project Progress Report, Project Progress Index Collection Guide.
The Lenovo Software Division regarding the software project plan has the following procedures:
1. Develop a project tracking plan. Its purpose is to make arrangements for the tracking and management activities of the project, the project manager is responsible, and its basis is a metrics and project plan. The plan first should specify the data item, collectors and acquisition time to collect. The acquired data items should include software scale, cost, progress, key computer resources, and risk tracking. In addition, the project manager should arrange the problem of the issue of the project case in tracking and monitoring programs. Finally, the project manager determines the frequency of the Project Status Report in "Tracking and Monitoring Plan", it is recommended to combine regular and event drivers. Tracking plans need to get the identity of all person in charge involved, and approved project tracking programs should be included in configuration management.
2. data collection. Its purpose is to collect data such as scale, cost, progress, critical computer resources and risk to analyze the status of the project. The personnel implementing include: data collectors, project managers and project group members. Its acquisition process is shown in Figure 8
All members of the project group record their own workload daily, fill in the "Workload Week"
"Workload Weekly"
Project manager and SQA personnel spot check, verify data timelyness and effectiveness
Data collector regularly collect data, fill in "project data summary table"
"Data Project Summary Table"
Project Manager Review "Project Data Summary Table"
Submit data analysts to submit audited "Project Data Summary Table"
Figure 8: Data acquisition flow chart
3. data analysis. Its purpose is to solve the problem based on the actual data obtained. Its primary activity is that project managers compare program data and thresholds in the actual data and thresholds in the project data summary, the size, workload, cost, key computer resources, progress and risk of management projects. The results of the analysis priority manager recorded in the Project Status Report, indicating the management activities and software engineering status of the project at this stage, pointing out the problem, and proposes a solution. 4. Project semester. Its purpose is to regularly exchange project status. Participated by all project group members. The primary agenda of the regular will be to check if the issues raised by the last discovery are resolved and then analyzed on the current and future possible status of the project.
5. Formal review. Its purpose is to review the overall situation of the project in milestones, organize relevant groups and users. The main activity of formally review is to convene a review meeting. The project manager introduced the progress of the project to the evaluation team, and the evaluation team made an overall evaluation of the project and made recommendations. The Secretary of the Conference fills in the "Review Report". 6. Modify the project development plan. Its purpose is to make the project plan more in line with the actual situation. The project manager is responsible, its main process is shown in Figure 9
The project manager puts forward the application and accepts the review
Project Manager Modify Project Plan
Submit the superior manager approval
Invites the affected group
Incorporate the modified project plan into configuration management
by
Fail
by
Figure 8: Flowchart of Modifying Project Development Plan
3.2.4 Software Quality Assurance
The purpose of software quality assurance is to provide management of software projects and visibility of products that are constructing. Software quality assurance involves reviewing and verifying software products and activities to verify the consistency of the processes and standards adopted with the project. The basic flow of software quality assurance can be shown in Figure 9. The process describes the formation and review of the software quality assurance program. SQA staff conduct quality assurance activities, discover problems, track problems, and eventually report execution to high-level leaders. Quality Assurance Program generally contains standards and software work products adopted by the project process.
Figure 9: Software quality assurance flowchart According to the flow shown above, the software quality assurance process can be determined as follows: 1. Project quality assurance staff to develop project quality assurance plan documentation and project quality assurance activities. 2. Quality assurance personnel by quality assurance manager or high-level manager designated projects. After the quality assurance personnel of the project, after the project development plan review, the quality assurance plan of the project was prepared, and submitted to the project manager and quality assurance manager or senior manager review. 3. Quality assurance personnel regularly audit the project executive activities, record problems that are inconsistent with the project process, and form a report. 4. Quality Guaranteed personnel organizes staff to review the output of work products to verify that it is consistent with the standards adopted by the project and forms a report. 5. Record the problem of auditing and review discovery to the project's problem tracking schedule, track and coordinate the solution to the problem, and report to the senior manager regularly.
6. Project managers or senior managers regularly check quality assurance personnel.
7. The documents applied in the actual project are: project quality assurance process definition, quality assurance plan, process audit report, software work product review report, quality assurance plan schedule, SQA problem tracking solution
The specific practices of the Lenovo Group Software Department have the following procedures:
1. Develop a SQA program. This activity requires "Project Report" as an input, and also refer to the data in the Project Plan. These include the following points: SQA responsibilities, resource requirements, SQA activity progress, review by SQA, used as project standards and procedures for SQA review bases, to discover the processing procedures for unqualified items, SQA program Review.
2. Execute the SQA program. Its main activities include: Check if the entry guidelines are met, the entered work products are correct, confirmed that the execution activities have the ability to perform activities, verify the work and plan of the work and plan, check whether the activities meet the activity guidelines, audit output The consistency of product and work products output at the precedence. During the review process, if you find that you don't meet the item, record it in the "Does Report" and processes in accordance with the flow of Figure 10.
Do not meet the report
Will not meet the subjects to the relevant responsible person
Responsible person solves the problem and feedback to SQA
SQA communicates with the project group, tracking non-compliance, review feedback
Close does not meet
Submit an elevation manager to help solve
Logout does not meet the item
pass the examination
Get resolution
Cannot solve
Figure 10: SQA group found that the processing workflow after the item
3. SQA work summary. After the project is over, SQA is summarized in two aspects. First, improve the work measure and lessons of SQA, and improve the work ability of the SQA group; the other is to evaluate the product. Finally, "SQA Summary Report" is generated.
3.2.5 Software Configuration Management (Software Configuration Management)
The purpose of software configuration management is to establish and maintain the integrity of products in software projects throughout the software lifecycle. It includes identifying the configuration of the software on a given time point, systematically controls the configured changes, and maintains integrity and trackability of the entire software lifecycle. Therefore, software configuration management can be divided into two aspects, one is the identification and management of the configuration item, and on the other hand is the change management. Its basic workflow is shown in Figure 11 and Figure 12:
Figure 11: Identification and management of configuration phase
Figure 12: Change management
According to the flow shown in Figures 11 and 12, the general method of software configuration management can be summarized:
1. Project Settings Configuration Managers, formulates the project configuration activity schedule based on the project plan to formulate the project configuration management plan document. 2. The project configuration management plan includes the following: Configuration Management Tools, Directory Structure, Identification Configuration Item, Configuration Item Name, Create Configuration Management Library, Baseline Management, Configuration Audit, Configuration Status Report, Change Management, and more. 3. Based on the appropriate timing (such as: Milestone or iteration end), the management manager is created at the appropriate timing (such as the milestone or iteration). It is a baseline that is responsible for backup and recovery. 4. Audit the project's configuration items and baseline regular (or milestones) based on the configuration management plan to verify that it is consistent with the project configuration plan or project development plan. 5. All change requests first proposed to the configuration management person, and the configuration management personnel analyzes the change request to determine its impact, organize the enclosure group. 6. Once the agreement is changed, the configuration item needs to be changed by the configuration administrator, and then the configuration item is changed, and the configuration management will be returned to the configuration management library. 7. Actively audit the configuration management of the SQA personnel. 8. Documents applied in the actual project include: Project Configuration Management Plan Develop Process Definition, Project Configuration Management Activity Process Download, Project Configuration Management Plan, Configuration Status Report, Baseline Audit Report, Configuration Item Change Application Form, Project Configuration Management Activity Schedule, Configuration Management Tools Operation Guide.
The specific practices of the Lenovo Group Software Department are:
1. SCM is ready to work. The SCM group develops an SCM program with the project manager. Then reviewed other groups and individuals to obtain approved SCM programs. Its content includes: SCM activity, document identification, time schedule, relevant resources, responsibilities, definitions of each software configuration item (SCI) to be designed, and SCI Change is the definition of each software configuration item (SCI) to be designed. In addition, the Division SCM supervisor needs to establish development libraries, controlled libraries, and product libraries for newly launched projects, assign corresponding user privileges for project team members.
2. The identification of the SCI. This activity occurs after the SCM program is approved. The SCI writer is identified according to the document specification developed in the SCM program.
3. The SCI will receive the control library. During software development, members of the project team submitted the product to the development library. After approval, transfer to the controlled library. Notify all the affected groups and individuals.
4. SCI change. The change of the SCI is divided into baseline changes and version changes. The flow of the baseline change is shown in Figure 13. During the basis of the baseline change, pay attention to lock the SCI that is changing.
Propose a change in personally estimated workload and schedule, fill in the change request, submit the project manager for approval
Change Request Submit SCCB and saves in a controlled library
SCCB review
Baseline change, establish a new version
Form a Change Request Review Meeting, and save this document in a controlled library
Approved
Figure 13: Baseline change workflow
If the change applied is version change, the project manager fills in the change request manual according to the range affected, and then the Change Review Conference is held by the SCCB.
5. Baseline audit. Its purpose is to maintain the status of the software configuration, so that it meets consistency, completeness, and traceability. Its content includes: verifying all SCI of the current baseline to the trackability of the corresponding item of the migration baseline, confirm that the current SCI correctly reflects the software requirements, audits the project work products in the three libraries, and fill in the report.
6. Configuring status records and reports. Its purpose is to provide comprehensive information about project progress in terms of management personnel and developers. Provide the current state and modification of the project configuration in a periodic or event-driven manner.
7. SCI backup. Refers to a backup of all SCI in the development library, controlled library, and product libraries to ensure the security of the three library information.
3.3 Correct understanding CMM evaluation
CMM is a guide to software companies to improve software process improvement, which guides how software companies improve, and is a gradually improved process. my country's software companies should put their goals in a planned process improvement, rather than cope with CMM grade assessment. The interests of CMM bring to enterprises are achieved by effective process improvements, rather than CMM grades. Simple pursuit of certification level, or "first certification, post improvement" practice, will only give the business order to an economic burden, and there is no practical effect.
The process improvement of CMM is a long-term process. It is necessary to have a whole plan and investment. It cannot only put the target in a limited level, and should adhere to the continuous improvement of ideas, and effectively implement process improvement to implementation.
CMM transitions from the level to the second level, about two years, and there are some assessments in the society, and the propaganda is extremely short-term help the company's certification through CMM. In this case, the company should continue to perform its own plan, effectively improve the level, etc., when it reaches or is very close to the CMM repeating level, starting to start certification. Simple authentication is meaningless to the company.
3.4 Conclusion
CMM depicts a "common sense engineering" path for software process improvement. Its maturity level, key process area, objectives and key practices have experienced extensive discussions and reviews within the software community. At the same time, CMM is neither a perfect and not tolerance, it just expresses a widely consistent opinion of the software community, and has become a useful tool for guiding improvements, which also helps small software organizations improve their process.
In this paper, the CMM specification and the method of implementing CMM second level are described in detail. CMM is a road with no end point. After implementing CMM second level, it should continue to move towards the third level and higher levels, constantly improve and improve process capabilities, and promote its own or even the entire software industry.
references:
1 University of Carnegie Mellon, USA. Ability Maturity Model (CMM): Software Process Improvement Guide: English. Beijing: People's Posts and Telecommunications Publishing House. October 2002
2 Lei Jianwen, Chen Zhenchong, Li Mingshu. CMM: Management and Improvement of Software Process. Beijing: Tsinghua University Press. September 2002
3 Viewpoint Studio. The road of CMM practice. Beijing: Machinery Industry Press. March 2003
4 Yang Yiping. Modern software engineering technology and CMM integration. Beijing: People's Posts and Telecommunications Press. November 2002
5 single silver roots, Wang An, Li Lian, software capability maturity model (CMM) and software development technology. Beijing: Beijing Aerospace University Press. May 2003 Jalote, P. With .CMM Practice Application ---- Infosys The company's software project implementation process. Hu Chunzhe and other translations. Beijing: Electronic Industry Press. August 2002
7 Mark C. Paulk. Using The Software CMM in Small Organizations. Http://www.tongtech.com/jsqy/yqxwview.asp?id=247
8 Liu Wenwei Ning, CMM Level 2 actual combat, http://www.51cmm.com/pubcmm/no104.htm
