Chapter 7 Evaluation of Estimation and Status of Project Management
Problem
Incorrect estimate
Incorrect development process
Incorrect status report
It is difficult to get a good estimate:
1. Not understanding the software development and maintenance process
2. The impact on various technical and management is not very well understood
3. It is considered to be special, thus limiting the comparison between the project.
4. Lack of historical data that can be used to check the model
5. Lack of historical data for calibration
6. Define insufficient estimation targets
7. Insufficient estimation range specification
8. Not full of definitions and understandings based on the estimation
Test the status of the software system
For project status, the test is a simple point accumulation system for metric progress. This point accumulation system can compare the project management or account system that generates progress report. If the results obtained by the two progress metrics systems are very different, the testers have reason to question the results generated by the project management and account systems.
Overview of points cumulative tracking system
The increasing complexity of software systems and structural and modular design requirements are doubled, and the number of software elements that have been developed and faithd on the simulation program have increased. Increased elements, coupled with the "soft" milestone for metrics, making monitoring for software development and a large subjective color for future process time consumption, and often unreliable.
2. Typical performance metrics
Software development performance is usually measured by estimating the percentage of the task or by calculating the number of predefined milestones. In two ways, the progress of tasks and / or milestones is used as baselines of performance metrics.
Performance metrics should meet several criteria:
The first program must be objective. Should not make people directly related to the performance to estimate.
Second, the program should measure the performance of the real task (that is, the development of the software can be delivered). In addition, the solution given by the metrics should be good enough to measure the incremental progress based on the week or month, and because of the metric The object is the current state of development, so the metric should be sufficient to time.
The third program should be efficient and should be collected, compared, and reportable performance data with the final resources. Explain the results with the least amount of time.
3. How to use a point system
Point system is an extension of a milestone system that is automated
4. Many expansions can be made to the schemes described so far
The first is a method of joining the weight of the module and / or milestone. For those large programs that contain many modules, the module gives the same weights, and those applets that only have several modules may need to give modules. Different weights to get the full correct performance metrics.
The second extension is to add selection and sort options in the report generating program. Options allow users to select all items in files through some such as Workac package numbers, file numbers, software family components, or responsible analysts.
The third is to add the completed target date and the actual date for each module.
There are two benefits of using the date field: you can monitor the progress of each other, and you can save a history for later analysis. Reports of other attention can be generated by setting the date domain to selectively and can be sorted.
5. Scrolling baseline
Since the new item is continuously defined and it is added to the status file, the problem of scrolling baseline in the program's survival is caused. This has led to a change in baseline, resulting in completion of the percent independent of milestones. There is almost no new In the process of adding documents, the percentage correctly reflects the actual performance. In other cases, when the frequency of adding new items and the previously defined milestone are achieved, the progress of the report tends to be flat. In some cases In some cases. If the added item is more than the old item completed, the progress reflected in the report is the opposite.
6. Report
Some content rich details and overview reports can be generated from the data. Off course the most complete detail report is a list of all elements. Such a list may be useful for the detailed directory of the software item to be published, and may be in physical configuration It is used when audit.
7. Use the point system as test tools
The point method for tracking the software system can be used in three ways as follows.
1 Confirm that the project leader's software progress tracking result 2 Test Plan 3 Test Status Report
Chapter 8 Developing Test Plan
Objective: It is to describe all the tests to be completed, including completing the resources and progress required. The test plan should give the background information, testing of the test software, the target and risks of the test, and the selected test to be executed.
Problems involved:
1. There is not enough training 2. inconsistent views
3. Lack of testing tools
4. The management department lacks understanding / support for testing
5. Lack of intervention of consumers and users
6. There is not enough time to test
7. Excessively dependent on independent testers
8. Change too fast
9. The tester is in a state of being in advance.
10. Don't say no
Chapter 9 Demand Stage Test
It is recommended by the user to assume test responsibilities.
Basic goals:
1. Determine the need to represent the needs of users
2. Determine the need to define and documentation
3. Verification has solved business problems
4. Verify that the control needs have been specified
5. Verify that the process followed when obtaining a business solution is reasonable
6. Verify that it makes a reasonable choice for the most likely solutions
Implementation process
I. Task First Preparation Risk Matrix
Confirm risk group
1. Understand the user application
2. Understand the concept of risks
3. Have a recognition control capability
4. Familiarity with the risk of application system risks and information service services
5. Understand the concept and system design of information services
6. Learn about computer operating procedures
personnel:
Interior auditor
2. Venture consultant
3. Data processing personnel
4. Security
5. Computer operator
Identify risk
Determine control target
Identify control of each part of the system (only for design phase)
Determining the fullness of control
II. Analysis of test factors in the demand phase
1. Consistent demand and methodology (methodology test factors)
2. Definition of functional specifications (correctness test factors)
3. Determination of availability specifications (ease of use test factors)
4. Determination of Maintenance Specifications (Maintainability Test Factors)
5. Need to determine the portability (portability test factor)
6. Definition of system interface (coupling test factor)
7. Establishment of performance standards (Performance test factors)
8. Definition of operability needs (easy to operate test factors)
9. Determination of deviation (reliability test factor)
10. Definition of Authorization Rules (Authorized Test Factors)
11. Definition of file integrity requirements (file integrity test factors)
12. Reconstruction of demand definitions (audit tracking test factors)
13. Definition of failure effects (handling persistent test factors)
14. Pre-service level definition (service level testing factor)
15. Definition of access (security test factors)
Third. Task three execution demand
1. Establish basic rules in the first step
2. Second step selection group / notification participants
3. The third step project is expressed
4. Step 4 Problem / Expression
Chapter 10 Design Phase Test
Test process recommendation: Rating the design success factors, performing design reviews, and reviewing the results of the design.
Task 1 Junction Success Factor Score
Task 2 analysis test factors
Task 3 for design review
Task 4 review the deliverable
Chapter 11 Programming Phase Test
Task 1 on the program
Task 2 Analyze Programming Stage Test Factors
Task 3 performs peer review
Cover all code generation methods.
Chapter 12 performs testing and recording results
Target: Determine if the software system can run correctly in executable mode. Any deviation from the expected result should be fully recorded.
Problems involved:
1. Software is not in test mode
2. Insufficient time / resources
3. Will not find a major problem during the test
Task construct test data
The common scenarios that need to be tested are as follows:
Test of a normal transaction (to test the ability to handle valid data correctly, test files should include normal transactions)
Second to use invalid data (1 Enter alphanumeric characters when you want to enter numeric characters, and vice versa) using invalid account or identification number 3 using incomplete or unrelated data in a particular data domain, or completely ignore the data 4 When only positive numbers are input, it is also possible to enter illegal conditions 6 in the data domain with logical relationships 6 Enter the transaction code or number of inconsistencies or quantity inconsistencies established with the operation procedure or control table. The input will violate the law or Standard operation, accumulation, limited transactions or situations)
Three pairs of tests that violate established editing inspections (from system documentation, auditors should be able to identify what editing routines in computer programs that are tested, and then he should create test transactions that violate these editing checks to determine these editing routines. Is there really existence)
Test file process:
Identify test resources
2. Identify Test Situation 3. Sort Test Situation
4. Select the situation of the test
5. Determine the correct results
6. Create a test transaction
7. Documentation Test Situation
8. Execute test
9. Verification and correction
Task 2: Executive Test
1. Artificial, regression test and function test (reliability)
2. Consistency test (authorization)
3. Functional test (file integrity)
4. Functional test (audit tracking)
5. Restore test (continuity of test)
6. Pressure test (service level)
7. Consistency Test (Safety)
8. Test meet methodology
9. Functional test (correctness)
10. Manual support test (ease of use)
11. Review (maintainability)
12. Disaster Test (portability)
13. Function and regression test (coupling)
14. Consistency test (performance)
15. Operation test (easy to use)
Task three record test results
Chapter 13 Acceptance Test
Problems involved:
1. You must integrate the acceptance test to the entire development process.
2. The cost and time of the acceptance test will not be effective
3. The implementation of the project plan does not know the acceptance standard
4. Users do not have the skills required to execute the acceptance test
Task a definition acceptance standard
Task 2 to formulate acceptance plan
Task three execute the plan
Submission 1 Construction System Boundary Map
Submission 2 definition use case
Sub-task 3 development test case
Submission 4 gets the result of the acceptance
Task 4 make an acceptance decision
Chapter 14 Report Test Results
Target: Four questions
1. What is the status of the project?
2. What are the tests to do, what are you doing?
3. How will the system be executed in operation (how to reliability)?
4. When is the software system placed in the product state?
Problems involved:
1. The test results are not available when needed
2. The test information is not sufficient
3. Test status is not sent to the right person
Output:
Generate three types of reports:
Project status report
2. Intermediate Test Report
3. Final test report
Chapter 15 Test Software Installation
Task a: Installation test of the new system
Need test installation issues:
1. Install the correct and integrity check (reliability)
2. Prohibit Data Change (Authorization) in the installation process
3. Check for product document integrity.
4. Record of the installation of the audit trajectory
5. Pre-system integrity guarantee (continuity of processing)
6. Failure - Implementation of Safety Installation Plan (Severe Level)
7. Access control (security) during installation
8. The consistency of installation and methodology.
9. Implant the appropriate procedures and dates into the product
10. Distribution of availability guidelines.
11. Document complete (maintainability)
12. Document complete (portability)
13. Interface coordination (coupling)
14. Comprehensive performance monitoring
15. Implementation of operating procedures.
Task a change version of a B test software
The specific goals for installation changes are as follows:
1. Implant the application system
2. Evaluate the efficiency of change
3. Monitoring the correctness of change
4. Keep the latest system library
Task Second Monitoring Products
Task three-document file
Chapter 16 Test Software Change
aims:
1. Testing the problem before the change is implanted into the product
2. Repair the problem before the change is implanted
3. Test the integrity of the required training materials
Problems involved:
1. Will the plan test process?
2. Whether the training process is planned?
3. Will the system problem in the test?
4. Is there a training problem in the test?
5. Did you fix the discovered test and training issues before the implementation?
Task a formulation / update test plan
Task Second Development / Update Test Data
Task three test change control process
Task IV test
Task 5 Development / Update Training Materials
Software change feedback
1. Quantity of tests 2. Quantity of issues found during testing
3. Change size of the training manual
4. Training issues found during the test
5. Delay in test / training progress
6. Test / Training costs exceed
7. The number of training activities
Chapter 17 Evaluation Test Effectiveness
Task one to determine the evaluation target
Task 2 Determines metrics
Task three designated metrics
Task quall selection evaluation method
Mission 5 determines the required fact
Task Six Collection Evaluation Data
Task seven evaluation test validity
Part IV Special System and Application Test
Chapter 18 Test Customer / Server System
Evaluation Key Component
1. Customer is installed correctly
2. Customer / server system has appropriate security guarantees
3. Client data get appropriate protection
4. The client / server standard is used correctly.
Chapter 19 Tests Rapid Application Development System
Quick Application Development (RAD) is an effective software development method. In the case where the initial demand is not clear or the demand is changing during the development process. ARAD provides a systematic automation software development method. Ensure high quality software There is a sufficient software test as a guarantee.
characteristic:
Iterative
2. Evolution
3. RAD reviews with specific syntax
4. Have multiplexed components (libraries and retrieves)
5. Execute the code using the reusable component written by advanced language
6. Have a mature support environment
The RAD test method described during the test uses the RAD iterative characteristics. It also focuses on accessing the needs.
Chapter 20 Test the Original Documentation of System Documents
The document test method must be a conventional method that can be accepted by all organizations. As described below
Conventional vocabulary
2. Increase or decrease make it agree with the organization's documentation
3. Concrete the document test method make it more effective
Problem
1. Constrained for IT functions
2. Assist in developing resource plans and manage resources
3. Assist in developing security procedures and perform specific implementation
4. Assist the auditor evaluation application system
5. Improving the relevant knowledge of software development throughout the life cycle
6. Enhance the inside of the organization, buy and sellers (if the software has become goods) to understand and expect
7. Define the expected goals to determine the content submitted
8. Adjust your personal work within the organization
9. Provide basic training for software maintenance personnel
10. Submit the important technical documentation of the software development phase to the administrative person to illustrate the work that the work is in line with system requirements and requires continued provision of resources.
Task a measure of project document requirements
Task 2 Determines the document that must be generated
Task II determines the integrity of each document
Task 4 Determines if the project document is in line with the actual
Chapter 21 Tests WEB-based systems
Problems involved:
Browser compatibility
2. Functional correctness
3. Integrity
4. Availability
5. Security
6. Performance
7. Verify code
Task one choice web-based risk to the test plan
Task 2 choice web-based test
Task three choices of web systems-based testing tools
Task 4 executes the test of the Web system
Chapter 22 Tests the Software
Objective: It is the correctness of the operation with the least effort to maximize the operation.
Task a test business adaptability
Task second test operation adaptability
Task three testers adaptability
Task 4 Determines the acceptance test of software processing
Chapter 23 Testing Multi Platform Environment
Software running in a multi-platform environment must pass the following two tests: First, determine if the software takes a predetermined function, second, determine whether the software can complete these functions in the same way.
Task a definition platform configuration involved
Task two lists the required platform configuration
Task three evaluation test laboratory configuration
Task 4 lists the software components affected by the platform
Impact of the Task Fifth List Operating Interface Platform
Task Six Executive Test
Chapter 24 Security Test
This test process uses a tool to determine the point of the physical location or information system has the risk of intrusion, and there is no statistically accurately of the technology, but if these technologies use these technologies to resist intrusion, its reliability Still very high.
This test technology should build a two-dimensional matrix, one-dimensional representative of potential safety hazards, another dimension represents the intrusion point. Creating a matrix to evaluate the possibility of the system invading through these two-dimensional intersection. Once it is determined Most likely to be invaded, you can check the corresponding physical location or information system. Task a clear potential security hazard
Task two clear potential intrusion points
Task 3 creation of intrusion matrix
Task 4 clear high-risk intrusion
Task Wu Execution Safety Test
Chapter 25 Test Data Warehouse
Objective: Determine if the data warehouse activity can properly solve the problem associated with the data warehouse operation. Those activities should be able to ensure that the data warehouse has the correct infrastructure and controls the data to ensure that the data warehouse will be made destruction.
Task one measure quantity data warehouse
Data warehouse activity to be tested
Task three test data warehouse activity process
The fifth part creates a test document
Chapter 26 Creating a Test Document
The document has the following:
1. Check the correctness of the demand
2. Enhance user understanding of information services
3. Enhance user understanding of application systems
4. Adjust the test resource
5. Determine the risk of testing
6. Create a test transaction
7. Evaluation test results
8. Repeat the test system
9. Analytical testing effectiveness
Test plan documentation
Part 1: General information
Part II: Plan
Part III: Specifications and Evaluation
Part IV: Test Description
Test analysis report documentation
Part 1: General information
Part II: Test results and conclusions
Part III: Software Function Conclusion
Part 4: Analysis Summary
