問48
頻出度★★★
ファンクションポイント法の説明はどれか。
平成25年度 春期 ITパスポート試験 問48
マネジメント系システム開発技術 › システム開発技術
This question's explanation and your answers so far.
解説
問 48
- ア
正解 The correct answer is ア: “Estimates the development scale based on the number and difficulty of functions such as external inputs and external outputs.” The Function Point method (FP method) focuses on the functions that the software to be developed provides to its users, turns the amount of those functions into a number, and uses it to estimate the development scale. Specifically, the system's functions are classified and counted into types such as: “external inputs”, which receive data from screens or files; “external outputs”, which output data to reports, screens and the like; “external inquiries”, which search stored data and return a response; “internal logical files”, which are the collections of data held inside the system; and “external interface files”, which exchange data with other systems. Furthermore, even for a single external input, how easy it is to build differs depending on the number of data items handled and the number of files referenced, so weighted points are assigned according to a difficulty (complexity) rating such as simple, average, or complex, and these points are totaled to obtain the size in a unit called the function point. By multiplying the size obtained in this way by the productivity of the particular development language and development environment (the effort per function point), the estimate can be extended to effort, duration, and cost. Because the method is based on functions that are visible to the user, it is not easily affected by how the program is written or which language is adopted, an estimate can be made at an early stage such as requirements definition, and the basis of the estimate is easy to explain to users; these are its advantages. The description of the Function Point method that the question asks for is ア.
Incorrectイ
Estimating the scale based on the actual results of past similar projects describes analogy-based estimation (the analogy method), not the Function Point method. In analogy-based estimation, you select a past project whose purpose, scale, and business content resemble the current case, take its actual figures as the starting point, and then adjust by taking into account the differences from the current case (functions added or removed, the technology adopted, the skill level of the staff, and so on). If past results exist, a rough estimate can be produced in a short time; on the other hand, the accuracy of the estimate depends heavily on how much past data has been accumulated and on the experience of the person in charge, and the method has no objective procedure such as counting functions, so its way of thinking differs from the Function Point method, which computes the scale from the number and difficulty of functions.
Incorrectウ
Estimating effort based on the number of lines of source code describes the LOC method (also called the program step method or SLOC method), not the Function Point method. In the LOC method you predict the number of lines (steps) of the program to be written and multiply it by the productivity per line to obtain the effort; its characteristic is that it links easily to the amount of implementation work. However, the number of lines varies greatly with the programming language used, the development tools, and the way each programmer writes code, and at the design stage the line count itself is hard to predict accurately. By contrast, the Function Point method counts the amount of functionality provided to the user rather than how it is implemented, so it does not depend on the language or the implementation approach; that is the essential difference.
Incorrectエ
Breaking the project's work down into the most detailed task units, estimating the effort of each one, and stacking them up to obtain the whole describes bottom-up estimation (the build-up method), not the Function Point method. In this method, deliverables and tasks are subdivided hierarchically using a WBS (work breakdown structure), and the person in charge estimates the effort for each leaf task and aggregates the results; it makes omissions of work easy to prevent and its accuracy is high, but it cannot be used until the work content is concrete enough for a WBS to be drawn up, and the estimating work itself takes considerable effort. What it focuses on is “tasks”, not “the number and difficulty of functions”, and in that respect it differs from the Function Point method.
ここがポイント
- The Function Point method is an estimation technique that counts the number of user-visible functions, such as external inputs, external outputs, external inquiries, internal logical files, and external interface files, multiplies each by a weight according to its difficulty, and totals them to obtain the development scale. Its advantages are that it is not affected by the programming language or the implementation method, that an estimate can be made from an early stage such as requirements definition, and that the basis of the estimate is easy to explain to users.
- Learn the software development estimation techniques by contrasting them. The Function Point method derives the scale from the number and difficulty of functions; the LOC method (program step method) derives the effort from the number of lines of source code; analogy-based estimation estimates from the actual results of past similar projects; and bottom-up estimation (the build-up method) aggregates the effort of each task broken down in a WBS. If you keep in mind what each technique counts, you can tell from a description which technique it is.
用語