Iterative development cycle class project version of the steps that

2010-10-09  来源:本站原创  分类:Development  人气:111 

Note: This is the previous article, go here and suffer brick archive

Iterative development cycle class project version of the steps that

A project started after the announcement of new projects (see Figure 1);

2, preparation of project plans;

3 Summary of requirements definition and design;

4 defines the priority of each requirement and incorporated into the version of planning;

5 The current version of the design of each requirement;

6, each needs the current version of the code and unit testing;

Each needs the current version 7 feet B verification;

8 CM submitted to the current version of the code related to each requirement into the test area (not controllable);

9 After the test area code compiled package into the test cycle (integration, validation and quasi-release test)

9.1 Test problem BUG found in a single;

9.2 to remain after the end of each round of tests specifically to amend the BUG, in the absence of exceptional circumstances, when the test is not allowed to modify BUG;

9.3 CM to submit one for each BUG involved in the testing area code (not controllable), the test area of the reservation code is the code after the last test (control part) and to change the code in this BUG (not controllable) merger, the purpose of this cycle is to focus on each test function changes, the functions have been verified as a secondary test points;

Testing has been extended to 9.4 to solve the BUG been dealt.

After testing the preparation of 10 user manual and installation manual

11, the first controlled release version of the project, (assuming the version V1.0), managed code has been verified from the test area code (see Figure 2)

11.1 If the V1.0 release to the customer, the customer needs to solve in V1.0 into the change process;

11.2 requirements analysis and design in the development of libraries to do, instead of V1.0 of the requirements and design documents, this is because changes in V1.0 the latest version at the same time to reflect on the development;

11.3 relevant staff to apply changes to V1.0 version of the code;

11.4 V1.0 Configuration Manager to pull from the controlled area code changes to the test area;

11.5 V1.0 version of the relevant personnel in the environment modify the code and submitted to the change area;

B 11.6 feet if necessary, then change the zone for validation;

11.7 Configuration Manager will submit the code developers to debug into the test zone area;

11.8 testers use V1.0 controlled environment (control part) and the change induced changes (not controllable) merge for testing to verify whether the changes meet the requirements;

11.9 If there is BUG

11.9.1 developer modify the code in the test area;

11.9.2 Extraction of configuration management code (non-controllable part) to debug the test section area;

11.9.3 testers continue to test until no BUG;

11.10 staffing upgrade package generated for publishing;

11.11 End of staffing to test the code into managed code to V1.0 (control part), the next change for V1.0 and V1.1 development and testing of the baseline.

12 preparation of the next version of program (assuming the current version V1.1), and proposed version needs to be achieved, including V1.0 changes (see Figure 3);

13 CM V1.0 controlled extraction of the current version of the test as a baseline to the test area (control part);

14, need some new definitions;

15, need the current version of each design;

16, need the current version of each code and unit testing;

The current version of 17 feet of each B-verification requirements;

18 CM each requirement to submit the current version of the code involved in the testing area (not controllable);

Package of 19 test areas after the code is compiled into the test cycle (integration, validation and quasi-release test), test environment may contain 2

19.1 If you need complete installation package, you need to merge V1.0 and V1.1 code to do the installation package;

19.2 If you need to upgrade packages, some of the changes made to the V1.1 upgrade package;

19.3 tests found a single problem BUG

19.4 After each round of testing to remain dedicated to amend the BUG, in the absence of exceptional circumstances, when the test is not allowed to modify BUG;

19.5 CM BUG single submit each code involved the testing area (not controllable), the test area of the reservation code is the last test (control part) of the code and change the code in this BUG (not controllable) merger, the purpose of this cycle is to focus on each test function changes, the functions have been verified as a secondary test points;

19.6 test has been extended to be addressed BUG been dealt.

After 20 test version of the user to modify the operation manual and installation manual

21 released V1.1 upgrade package or a full package

22 continues until the V1.2 version of the product cycle planning

22.1 Repeat for each version of the steps 12-21

22.2 11,12 Step Change

Iterative development cycle class project version of the steps that

Figure 1: no pre-release cycle steps:

Iterative development cycle class project version of the steps that

Figure 2: The cycle of steps after the release of version (change)

Iterative development cycle class project version of the steps that

Figure 3: the release of version cycle steps (tasks)

相关文章