問52
頻出度★★★
アプリケーションプログラムの規模を見積もるための基となる情報として, 最も適切なものはどれか。
平成23年度 特別試験 ITパスポート試験 問52
マネジメント系システム開発技術 › システム開発技術
This question's explanation and your answers so far.
解説
問 52
- ア
正解 The correct answer is ア. Estimation follows a fixed order: first estimate the size (how much program there will be to build), then divide it by productivity to obtain the effort (person-months), and then derive the period and the cost from the number of staff that can be assigned. The information used as the basis for a size estimate must therefore sit at the very front of this chain — that is, an externally visible measure of the specification, seen from the user's point of view, that can be counted even at the requirements-definition or external-design stage when not a single line of program has been written. The number of screens and the number of reports are exactly such a measure: once it is decided how many kinds of data the user enters and how many kinds of output the user receives, the approximate amount of processing to be built is also determined. The method that systematizes this idea is Function Point analysis (FP method), which is also listed in the glossary. In the FP method, the user functions of a system are classified into five types — external inputs (registering and updating data from screens and the like), external outputs (output of reports and aggregated results), external inquiries (search and query screens), internal logical files (collections of data held inside the system), and external interface files (data exchanged with other systems). The count of each type is weighted according to complexity and totaled, yielding a size indicator called the function point value. Screens correspond to external inputs and external inquiries, and reports correspond to external outputs, so the number of screens and the number of reports are direct material for this counting. The LOC method, which expresses size by the number of lines of source code, cannot produce a figure of high confidence until design and implementation have actually progressed; by contrast, the FP method can be counted from upstream specification documents alone, and it provides an objective measure that is not affected by the programming language or by who does the work. Therefore ア is correct.
Incorrectイ
The system development period is a schedule-level result obtained by dividing the effort derived from the size by the number of staff that can be assigned; it is a quantity fixed after the size. Using it as the basis for a size estimate reverses the cause-and-effect relationship. In practice a period is sometimes given first because of a delivery deadline, but the period in that case is a constraint, not information that expresses the amount of program to be built itself. Even for the same period of six months, the amount that can be built changes if more staff are assigned, so the size of a program cannot be determined from the period alone.
Incorrectウ
The system development effort is calculated as size ÷ productivity, a downstream quantity derived from the size. To produce the very size value you are trying to obtain, you would have to use as input an effort figure that cannot be computed without that size, so the logic becomes circular. Moreover, effort is expressed in units of workload such as person-months or person-days, and does not directly express the quantity of deliverables such as screens or reports. Effort is what you compute after receiving the result of the size estimate, not the information on which that estimate is based.
Incorrectエ
A programmer's years of experience is a factor that affects productivity — how much can be built per unit of effort — and it is information to take into account at the stage of converting size into effort. The amount of program to be built is itself determined by the requirements to be realized, and it does not increase or decrease depending on who is assigned. Whether an experienced member builds it or a newcomer does, the number of screens and the number of reports stay the same for the same specification, and so does the size; what changes is the effort and the period needed to finish. It therefore does not qualify as information that serves as the basis for a size estimate.
ここがポイント
- The order of estimation — derive in the order size (the amount of program to build) → effort (size ÷ productivity) → period and cost. The basis for a size estimate is therefore an externally visible measure of the specification that can be counted even in upstream processes where no code exists yet (number of screens, number of reports, and so on), while effort and period are result-side quantities derived from the size. Not getting this direction backwards is the heart of this question.
- Function Point analysis (FP method) — a method that classifies user functions into five types (external inputs, external outputs, external inquiries, internal logical files, external interface files), counts them, weights the counts by complexity, and totals them to compute the size. Because it can estimate from the number of screens and reports, it can be used at the requirements-definition stage, and it is not affected by the programming language or by the skill of the people assigned. Learn it in contrast with the LOC method, based on lines of source code, whose confidence rises only after design.
用語