IEEE729-1983 specification
In the outcome of the formal meeting on software projects (including the various stages of documentation, code, etc. produced) presented to the user, customer or staff of the departments of software products for review and approval. The aim is to identify areas that may affect the quality of software products, development, maintenance and design flaws of the applicability of the environment, and to take remedial measures, as well as to identify possible improvements in performance, security and economic aspects.
The objective of the review
Make the appropriate checks at all stages of software development and testing, in favor of quality software product and process improvement.
Review stage
Requirements Review
"Software Requirements"
"Test Requirements"
Design Review
"Outline design"
"detailed design"
Code review
"Code norms"
Test Review
"Test Plan"
"Test Case Specification"
"Defect report specification"
definition
Review entry criteria
The assessment team leader was appointed.
Accreditation is defined in the relevant plan.
The product is ready to be reviewed.
Trained assessors review procedures.
Assessors should be trained in skills assessment questions.
Coordinators should have received formal training in how to perform the review, or should participate in the experience of several reviews.
"Project Plan" has been developed.
Peer review
Check the software work products created by colleagues of the work product, identifies product defects, and correct shortcomings.
Guidelines:
Review the product, rather than the review designer (the designer can not have any pressure).
The venue to have a good atmosphere.
Limit debate and refute (Accreditation Council not to solve the problem, but to find the problem).
Specify the scope of the problem, rather than solving the problems mentioned.
Display Record (preferably with blackboard, the issue at any time written on the blackboard).
The number of meetings should be better in a group of 5-9 people during the assessment.
When the group of assessors should be included in the assessment is the product of peer review. (Such as program design document review, reviewers should include other programmers).
When panellers group should include upstream and downstream of the art products are reviewed. (Eg review of programming documents, reviewers should include a detailed follow-up of designers and coders).
Former adhere to will be ready to work.
The necessary training for all reviewers.
Management Review
/ Product managers during the project management activities carried out by the software project evaluation, defect identification process, improve management activities.
Guidelines:
Review the product, rather than the review designer (the designer can not have any pressure).
Specify the scope of the problem, rather than solving the problems mentioned.
Reviewers who have the necessary training on review.
Reviewers have extensive experience in the field of assessment products.
Single Review
For simple work products are evaluated by a single reviewer, the identification of defective products, correct shortcomings.
Guidelines:
The overall evaluation of the situation and the progress of the project.
Evaluate the progress and status of personnel inside the group.
Evaluation of project quality control situation.
Problems encountered in evaluating progress of the project and propose solutions.
Evaluation of project risks that currently exist.
Evaluation of other cases (depending on the stage of the project may be).
Review of the general steps
Develop evaluation plans
Accreditation Preparation
Review meeting
To take action on the assessment results
Results of the review to be tracked until completion
Submission and archiving
Mistakes review
Participants do not understand the review
Not scheduled to review the project plan
Review meeting to discuss solutions to problems will become
Reviewers no prior knowledge of the evaluation work enough
Reviewers focus on non-substantive issues and
Ignore organizational details
Meeting time is too long
Risk Analysis
Too many tragic history tells us that the risk is everywhere, do not learn to control it, it will certainly be controlled.
Risk Classification
Too many tragic history tells us that the risk is everywhere, do not learn to control it, it will be under its control
Software Risk
This risk analysis is a major priority, depth testing to determine what software you want to test, test.
Planning risk
This risk is mainly to prevent unplanned affect the project schedule of events. For example, testers sudden departure led to a sudden demand for change understaffed and software.
Risk analysis process
The formation of a "brainstorming" group.
List all feature list software.
Determine the likelihood of a function failure.
Determining a function failure caused by the impact.
Quantify.
Calculated risk priority.
Review and modify the quantized values.
The features are prioritized.
Decided to "risk dividing line."
Determine measures to mitigate risks.