問35
頻出度★★★
ソフトウェア品質管理における考え方のうち, 適切なものはどれか。
平成24年度 春期 ITパスポート試験 問35
マネジメント系システム開発技術 › システム開発技術
This question's explanation and your answers so far.
解説
問 35
Incorrectア
The party that takes the lead in establishing quality management criteria is the project side that carries out development (the quality assurance department and the development department). The role of the user department is to present the required quality — what kind of quality it wants — and to review the criteria presented to it and agree to them; it does not itself define development-process management metrics such as bug density or test density. This choice confuses the role of establishing the criteria with the role of stating requirements and agreeing, so it is wrong.
- イ
正解 As a principle, quality management criteria should be put into a form that can be measured with numbers (quantified) as much as possible, so that anyone who measures reaches the same judgment. Metrics such as “bug density (number of defects detected ÷ size)”, “test density (number of test items ÷ size)”, “review finding density”, “test completion rate”, and “operating rate” are examples of this. Once the criteria are quantified, the gap from the target value can be judged on the spot, comparison across phases and across projects becomes possible, and target values can be reviewed on the basis of past results. Conversely, with only qualitative expressions such as “easy to understand” or “easy to use”, the evaluation depends on the subjective view of the person in charge, so it is impossible to judge objectively whether the quality has met the criteria, and impossible to link the result to improvement. Therefore イ, making the criteria manageable as quantitatively as possible, is appropriate.
Incorrectウ
Quality management does not end with the development phase; it continues throughout the entire software life cycle, including the operation and maintenance phase. Even after operation starts, figures such as the number of failures, the system operating rate, response time, and the number of inquiries are managed against the criteria, and those results are fed back into the quality targets of later modifications and of the next development project. This choice puts the operation and maintenance phase outside the scope, so it is wrong.
Incorrectエ
In design, construction (programming), unit testing, integration testing, and overall system testing, the content of the work differs, and so do the nature and the number of defects that can be detected in each. For example, the number of defects found in unit testing and the number found in overall system testing are inherently at completely different levels, so applying the same baseline value would judge a normal situation as abnormal, or conversely let an abnormality slip through. The correct way of thinking is not to use one uniform baseline value for the sake of easy management, but to set a baseline value suited to each process, phase by phase, so this choice is wrong.
ここがポイント
- Criteria for software quality management should be quantified (turned into measurable numerical metrics) as much as possible. Expressing them as numerical metrics such as bug density, test density, and review finding density makes objective evaluation, comparison, and improvement possible without being swayed by subjective views.
- Quality management is carried out not only in the development phase but across the whole life cycle including the operation and maintenance phase, and baseline values are set phase by phase to match the characteristics of each process. The criteria are established by the development and quality assurance side, while the user department is responsible for presenting the required quality and agreeing to it.
用語