Simplified application of CMMI5 in the project

Document directory

•  

Capacity Maturity Model Integration (Capability Maturity Model Integration) is too costly in small projects. Based on your experience in implementing cmmi5 and Its Application in actual projects, the implementation process and some documents of cmmi5 are simplified during the project implementation process. This streamlined process ensures the process specifications and quality trust while saving the project cost. The following is a brief introduction to the simplified application of cmmi5 in the project:

I. requirement and standard management

1. The test owner (or the specific requirement analysis owner) receives the gateway specification and new requirements from the mobile industry in a unified manner. The test owner will reply to the email after receiving the notice, forward specifications and new requirements to the Development Manager, Project Manager, relevant developers and testers, and commit to CVS;

2. After carefully reading the specifications and requirements, the test owner (or special requirement analysis owner) and project manager will study the specifications and new requirements and discuss the difficulties and doubts, sort out the key content and send it to the Development Manager, Project Manager, related developers and testers. At the same time, commit the content to CVS;

3. The Development Manager, Project Manager, test Manager, Requirement Analysis Manager, and related developers and testers hold meetings to discuss specifications, requirements, and key content, determine the specific meaning of the requirement and the final requirements and functional points;

4. The project manager Prepares the "requirement specification" and "function list" based on the specifications, requirements, and discussion results of the meeting, and the test owner (or special requirement analysis owner) check and modify the document, and then commit it to CVS;

5. The test Director (or a dedicated PPQA) confirms that all relevant documents have been reviewed and have been committed to CVS.

2. Project Plan and test plan

1. The development manager organizes a project plan seminar. At the seminar, the development managers evaluate the workload required by the modules they are responsible, determine the overall development plan, test plan and release time based on the workload and engineering requirements;

2. The project manager Prepares the project plan based on the estimated workload and engineering requirements, uses the CMMI5 overall test plan template, and appropriately crops and supplements it to prepare the project plan suitable for the project;

3. The test owner prepares the test plan based on the project plan and release time, uses the CMMI5 overall test plan template and appropriately crops and supplements it, and prepares the test plan suitable for the project;

4. After the project plan and test plan are compiled, the program will be sent to the Development Manager, Project Manager, related developers and testers, after reading the project plan and test plan, the Development Manager, Project Manager, and related developers and testers send suggestions and comments to the project manager and Test director by email, the Project Manager and test leader collect emails to modify and improve the project plan and test plan respectively, and reply to the emails to describe the changes to the project plan and test plan, if there is any dispute, hold a small meeting to discuss the objection. The modified project plan and test plan commit to CVS;

5. The test Director (or a dedicated PPQA) confirms that all relevant documents have been reviewed and have been committed to CVS.

Iii. development design and review

1. The Project Manager conceived the system design, and the project team members discussed the system design together, forming a clear idea for the design;

2. The project manager is responsible for preparing the summary design document and discussing the summary design with the Development Manager, Development Team members, and Test director;

3. After the outline design is complete, the Project Manager prepares detailed design documents, database design documents, and coding specifications. The module owner is responsible for preparing the module for detailed design;

4. After the design documents are prepared, send an email to the Development Manager, Project Manager, test Manager, related developers and testers;

5. The Development Manager, Project Manager, test Manager, relevant developers and testers should review the submitted Summary design documents and detailed design documents, send suggestions and comments to the module owner by email;

6. The module owner collects the modification suggestions in the email and modifies the design document. At the same time, the module owner replies to the email to describe the detailed design changes. After the modification, the detailed design commit is sent to CVS;
7. If there are disputes over the design or there is obviously unreasonable design, a small meeting should be held to discuss the objection to effectively resolve the differences arising from the design;

8. The test owner (or a dedicated ppqa) checks the detailed design plan for the final development modification and confirms that all documents have been committed to CVS.

Note: In a large project, the outline design must be completed before the detailed design is completed. In a small project or requirement, the outline design and detailed design can be tailored appropriately.

Iv. Test plan and review

1. In the design phase of the project, the testing Director prepares the overall testing scheme and performance testing scheme based on the standard documents, function lists, and summary documents;

2. After the test scheme is compiled, send an email to the Development Manager, Project Manager, related developers and testers;

3. The Development Manager, Project Manager, test Manager, related developers and testers review the submitted test scheme. The Development Manager and Project Manager review the overall test scheme, the module owner is responsible for reviewing the testing scheme of relevant modules or functions, and sending suggestions and opinions to the test owner by email;

4. The test owner collects the modification suggestions in the email and modifies the test solution. At the same time, the test owner replies to the email explaining the modification of the test solution. The modified test solution is commit to CVS;

5. The test Director (or a dedicated ppqa) checks the final modified test plan and confirms that all documents have been committed to CVS.

V. coding implementation and unit testing

1. After the detailed design of the product is completed, the development engineers code the product based on the design;

2. After coding, the Development Engineer prepares unit test cases and conducts unit test. After the unit test is completed, the Development Engineer submits the unit test report;

3. The project manager organizes code review for the code written by the Development Engineer based on the actual situation of the project, and records related questions;

4. After the product module unit test is completed, conduct product joint debugging tests between developers, modify the detected problems, and submit the joint debugging test report;

5. After the preliminary completion of the product, a product demonstration will be conducted before the test is submitted. The participants include the Development Manager, Project Manager, Test Director, Development Engineer, test engineer, pre-sales engineer and after-sales engineer, proposes improvement suggestions for the product during the demonstration;

6. The person in charge of each module changes the Code Review and problems found in the product display, and the relevant Code and documentation commit to CVS;

7. The project manager confirms the system after coding to ensure that the system submitted for testing is runable and the test owner (or specialized PPQA) make sure that all documents and code have been committed to CVS.

Vi. test design and review

1. In the project coding stage, after the test scheme is compiled, the test owner or relevant testers design the test cases according to the test scheme, standard document, function list, and detailed design;

2. Test Case design types include functional testing, boundary testing, exception testing, performance testing, and stress testing. In case design, apart from functional test cases, boundaries, exceptions, and performance should be considered as much as possible to discover more hidden problems;

3. When writing test cases, you can actively communicate with the development director or project manager about the areas or test focuses that have doubts. On the one hand, it helps design complete test cases, on the other hand, it also helps to further clarify coding ideas;
4. After the test case is compiled, send an email to the Development Manager, Project Manager, related developers and testers;

5. The Development Manager, Project Manager, related developers and testers review the submitted test cases. The Development Manager and Project Manager inspect the test cases in an overall manner, the module owner is responsible for checking the test cases he is responsible for, and sending suggestions and opinions to the test owner by email;

6. The Test director collects emails to modify and improve the test case, and replies to the email to explain the changes. If there is any dispute, a small meeting will be held to discuss the objection, the modified test case commit to CVS;

7. After the test cases are compiled, they need to be constantly improved. After new features or updates of software products are required, the test cases must be modified and updated. During the test, the design test cases are not considered weekly, the test cases need to be modified and improved. Software defects reported by the customer after the software is delivered and used, which are caused by vulnerabilities in the test cases and need to be improved;

8. The test Director (or a dedicated PPQA) checks the final modification test case and confirms that all documents have been committed to CVS.

VII. Test implementation

1. Prepare the relevant test environment (such as a server or database) one day before the code is submitted. After the code is submitted, the tester applies to the Build Master for packaging and builds the formal test environment, in order not to perform tests and ensure that products can be cross-platform, each tester should build a testing environment, and at least one tester should be responsible for each platform;

2. Perform a smoke test after the test environment is set up. If the smoke test passes, perform a detailed function test. Otherwise, the test is interrupted and the test is returned to the developer;

3. The tester tests the test cases one by one according to the predefined test plan and test plan. All phenomena and problems found during the test that are inconsistent with the expected objectives must be recorded in detail, fill in the test records to assist the development in tracking and modifying the problems found when necessary. If a major bug is found during the test or the test cannot continue due to some bugs, test interrupted and returned to development;

4. After each test stage is completed, the test owner summarizes the test results, analyzes the test results, and predicts the testing plan and number of bugs that may be introduced in the next stage, submit the "test phase analysis report" and send it to the Development Manager, Project Manager, related testers and developers;

5. The development manager should take appropriate measures and adjust relevant resources for the problems found in the testing stage analysis report to ensure the smooth development and testing of the next stage;

6. Developers modify bugs;

7. After the bug is modified, the developer performs a regression test on the tester. The modified software may still contain errors or even introduce new errors. Therefore, for the modified programs and documents, relevant tests must be re-performed according to the modified method and scope of impact;

8. After the product has complete functions, perform performance stress tests and optimize the performance based on the test results;

9. Confirm and test the product before the software is released;

10. When the testing product meets the product quality objectives and test quality objectives set forth in the test plan, organize the product release packages and prepare relevant documents, confirm the release packages and documents are complete, and then release the product.

8. Product Release

When the testing product meets the product quality objectives and test quality objectives set forth in the test plan, sort out the product release packages and prepare relevant documents, and perform a comprehensive validation test against the function list before release, release the product after confirming that the release package and documentation are complete. For new products, the necessary documents must include: (1) product installation operation manual; (2) Product White Paper; (3) Product Management and Maintenance Manual; (4) user operation manual; (5) Overall Test Report (6) performance test report.

9. Version Control

During the test, the software is packaged by the Build Master. After the new version of the software is released, it immediately controls the quality of the Code: (1) Build the Master to create a cvs tag for the new version of the source code to facilitate code rollback check out. For example, if the release version is IAGW1.0.0, a tag IAGW1.0.0 with the same name as the release version is also assigned to the software source code. One advantage of this is that, after modifying the concurrent deployment version based on the current software, if you need to check out the source code of a specific version, you can check out the code by using the tag of this version. You can modify the code on this version. (2) Build the Master to execute cvs lock on the source code of the newly released software. Developers are not allowed to open the commit source code after the software is released until there is a need to modify the new version and grant the commit permission to developers. The advantage of doing so is to avoid developers from arbitrarily modifying and commit source code, and ensure that the source code version on the source code server is consistent with the latest release version.

. Automatic Test

After the product is stable, you can develop an automatic testing tool. For stable features, you can use an automatic testing tool for testing. For new features, you can use manual testing and automated testing + manual testing, this greatly improves the test efficiency.

Summary: application promotion ideas and experiences

The overall idea is: first, conduct Requirement Analysis on the project. The effective requirement analysis methods include requirement analysts, project managers, development managers, and test owners who respectively read the specifications and original requirements, in particular, the demand analysis owner and the Project Manager need to conduct in-depth analysis and research on the needs, and then hold a meeting to discuss and eliminate misunderstandings and omissions in the requirements, after the discussion, write the function list instruction documents and requirement specification documents for review. For issues unclear in the specifications, the test owner (or the requirement analysis owner) communicate directly with the owner of the mobile general specifications to ensure that the project implementation and requirements are not inconsistent due to incorrect understanding of the specifications. After the requirement analysis is complete, write the project plan and test plan. The project plan and test plan will be discussed before preparation, and the module owner will estimate the workload, the issues and schedules that can be identified are determined in the discussion, and the project plan and test plan are developed based on the workload and engineering requirements. Development requires a brief design and a detailed design before coding. Before coding, development engineers should have a clear idea of the overall design architecture of the system and the modules they are responsible, after review, check whether the design of the module is reasonable. After coding is complete, the development must perform unit test and joint debugging test before submitting the test. The software submitted to the test is a runable product. During the testing process, in the project design or coding stage, the test leader tests and designs the project and guides the implementation of the test, many problems related to process and detail processing will be encountered during case writing. Discussions with developers will also help to detect problems and improve code in advance. In the test implementation phase, the tester records the detected problems and assists developers in solving the problems in a timely manner. The test owner records and analyzes the problems encountered during the test, after each stage is completed, submit the analyzed testing stage report. In the software testing stage report, summarize and analyze the problems found during the testing and propose solutions to these problems, make improvements and adjustments in subsequent development and testing to ensure that the project can be released on time and in good quality. In order to save resources, plans or designs are reviewed in the form of emails. For problems with strict divergence, organize a small meeting to discuss and effectively solve the problem, small seminars are an effective way to solve the problem. Any problem can be resolved through face-to-face communication. The Build Master is responsible for software management and version management to ensure that the software is well controlled. During the implementation of the entire project, a PPQA is required to inspect and supervise the process.

This streamlined implementation process not only ensures the quality of the software, but also reduces the implementation cost and is very easy to promote in team implementation. Throughout the process, the test owner is not only responsible for testing related tasks, but also responsible for requirement management, process tracking, coordination and communication (of course, it can also be held by the Project Manager or development manager), where testing promotes project development and implementation, and builds a bridge between development members and between development and testing, such a coordination and promotion promotes the smooth completion of the project, and is suitable for small teams from 5 to 20. However, this test and development model requires a high degree of responsibility and communication and coordination for the test owner, it also requires high business analysis capability and cmmi5 implementation experience.

 

Process Area

Maturity level/process area	Process Management	Project Management	Engineering	Support
Level 5-optimizing Emphasis on continuos Improvement (innovation)	21. Organizational Innovation & Deployment (OID)			22. Casual Analysis & resolution (CAR)
Level 4-quantitatively managed Process is measured and Statistically controlled	19. Organizational Process Performance (OPP)	20. Quantitative Project Management (QPM)
Level 3-defined Process characterized for Organization	8. Organizational Process Focus (OPF) 9. Organizational Process Definition (OPD) 10. organizational training (OT)	11. Integrated Project Management (IPM) 12. Risk Management (rskm)	13. requirment definition (RD) 14. Technical solutin (TS) 15. Product integration (PI) 16. Verification (VER) 17. validation (VAL)	18. demo-analysis & Resolution (DAR)
Level 2-managed Process characterized For projects		1. Project Planning (PP) 2. Project Monitoring And control (PMC) 3. Supplier Agreement Management (SAM)	4. requirment Management (Reqm)	5. Configuration Management (cm) 6. Process & Product Quality Assurance (ppqa) 7. Measurement & Analysis (MA)
Level 1-saved med

Reference http://www.bytewatch.com.cn/cmmi5/news_1223344039.html